JXTA is a Sun-sponsored Open Source project that is the very embodiment of the company's oft-repeated "the network is the computer" mantrum. The idea of the project is to allow different many computers and computer-like devices to share information directly instead of using a central server. And JXTA is starting to get used in practical ways, so this is not just hot air or a "someday" dream.
I listened to part of a Sun "executive briefing" and telephone press conference about JXTA on March 4, held to boast about the "million downloads" number and announce the relase of JXTA 2.0. Some of the reporters' questions showed that the JXTA P2P concept is not as well-understood as it could be. My favorite was the one about why one million downloads should be considered a big number when P2P programs like Napster and Gnutella and their many variants have had many, many millions of downloads. I could almost hear the expressions on the faces of the Sun people on the other end of the phone as they tried to explain that the number of downloads for an enterprise-oriented developer product like JXTA cannot rationally be compared with the number of downloads for an end-user "consumer" product like a music-sharing program.
Apparently the confusion came about from the fact that both Napster and JXTa do "peer to peer filesharing." Except JXTA does not have the same purpose as Napster, Gnutella or their workalikes. It is something entirely different.
P2P in the JXTA context
The idea behind JXTA is that you can use it to connect many small databases and files spread across many devices instead of holding all your information in a central database. "You" in this case may be a convenience store chain owner or franchisee, and this example is chosen because the National Association of Convenience Stores (NACS) is using JXTA because, as NACS CTO John Hervey puts it, "Project JXTA and
peer-to-peer enables us to create low cost networks at the convenience stores with no single point of failure."
In this context, it's not files on PCs that are shared P2P as much as sales records from gas pumps, POS terminals (computerized cash registers), and the other computers and computerlike devices that are used to run a modern convenience store. Every device can talk to every other device over an individual store's network, and that store's network can connect to suppliers' networks so that a sensor in the "regular" gas tank that detects a low fuel level can automatically signal a gasoline wholesaler to schedule a delivery, and if the low level in the gas tank doesn't correlate correctly with the number of gallons shown as pumped (and, hopefully, paid for), a technician can be sent out to decide whether the problem is with the sensors, the pump readings, or -- worst case -- a leaky underground tank.
With JXTA, all the data devices on the network can be polled at any time, without need for a central server to hold all the information (although one assumes a smart convenience store operator would keep data backups somewhere offsite instead of leaving all the gasoline sales data on the pump terminal where it could be destroyed by a drunk driver). This way, everyone who needs data from those pumps -- including the gasoline wholesaler and the technicians who watch for potential underground gas tank leaks -- gets up-to-the-second information instead of waiting for a central database somewhere to be updated.
Since JXTA is a framework, not a program in and of itself, it doesn't matter if all those devices are using different operating systems or if they're programmed in different languages.
This is the vision behind JXTA: total interoperability, combined with total connectivity.
Naturally, Sun hopes JXTA users find Sun hardware (and Sun pay-for software) to be the best selection for at least some of the infrastructure behind their JXTA networks, but Sun does not require any purchase in order to use JXTA, which is distributed under a mildly-customized version of the Apache license.
What about .NET? And backwards compatibility?
Sun's response is that JXTA was there first, and will work across all kinds of platforms. And JXTA is here today, and works fine with IPV4 and doesn't need to wait for IPV6 and isn't limited to C# (and/or Mono) or anything else proprietary or that isn't already in existence, ready to use, right now.
The biggest shakeup in JXTA is the release of JXTA 2.0, which is not -- repeat not -- backwards compatible with earlier versions. Sun's people say this was a community decision, not theirs; that this was a necessary move to offer more performance and scalability. The theory behind this break with the past, as I understand it, is that enough underlying architecture changes were required as a "futureproofing" move that it was better to look forward rather than backward, and that once you start to take this view it's easier to start with a fresh slate than to keep trying to accomodate legacy code. And, say some of the JXTA people, the migration is not much of a problem -- certainly a far smaller one than a similar one might be in a few years, when JXTA is developed even further and has more users and is part of even more sophisticated application than it is today.
Will the distributed data model take over corporate computing?
Probably not everywhere. And although the theory of having, for example, the mobile computer in every police car function as a full-time "peer" in a P2P crime information network sounds nice, reality is not that neat. What happens when the wireless connection from that car is degraded because it's in an underground parking garage or someplace else where it can't connect efficiently?
Obviously, there is going to have to be some sort of server setup somehwere that can function as a meta-peer for mobile/wireless devices that may not have total connectivity at all times. And even within a wired network, you don't want to bring a convenience store's network to a stop because the information from one POS terminal isn't availableto other devices.
In the end, JXTA and similar "enterprise P2P" concepts will probably grow steadily, and improve steadily, and allow lots of neat data manipulation tricks -- and business concepts built around those tricks -- that aren't available today.
But still, look for servers of some sort in the system, not only as "traffic guides" for data flowing from node to node in the P2P network, but also as "superpeer" data repositories and backups.
Not that this will necessarily bother Sun. Remember, they make servers, and even if "the network is the computer," I'm sure Sun will be happy if some of the machines on that network are nice, big, beefy Sun servers, even if many of them run Linux instead of Sun's beloved Solaris.