Current P2P applications cannot rely upon the existence of anything more than basic networking and must re-create a P2P infrastructure on their own. How many HTTP servers, presence management frameworks, firewall subversion systems, and so on does a power P2P user have running on their desktop at any one point? While task-based silos are inevitable in the P2P space, a stack per application borders on the ridiculous.
Enter JXTA. JXTA is positioned as a peer-to-peer stack, a wafer-thin layer sitting on top of the operating system or virtual machine -- and below actual P2P services and applications. To visualize this, take a look at the figure below, "The JXTA Layer Cake." The idea is to provide P2P developers enough core functionality upon which to build, no matter the what the application. With JXTA in place, developers can safely assume that everything one needs for peer-to-peer interaction is on-board; much the same way as the Java Virtual Machine provides a core infrastructure and functionality from which to start.
So don't confuse JXTA with a network stack. JXTA explicitly assumes a networking layer beneath, provided by the "Any Peer" layer in our figure. The JXTA platform concerns itself with slightly higher level P2P-specific needs, mechanisms for establishing, joining, and leaving peer groups, inter-peer communication pipes, monitoring (access control, metering, etc), and security provisions.
|The JXTA Layer-Cake|
The JXTA stack can be thought of as a layer-cake with the JXTA core being only a thin layer somewhere in the middle. We'll work our way through the cake from the bottom up.
mores. JXTA's first demonstration service/application, the JXTA Shell is considered a reference peer service.
Project JXTA launches with the platform itself and some sample applications including the JXTA Shell, a rudimentary content management system (CMS), an GUI instant messenger cum file-sharing application, and is purported to soon be rolling out search functionality supplied by its acquisition of InfraSearch. Each serves as a reference implementation of the type of application one might build on top of the JXTA framework and, as such, are rather crude. At the time of this writing, the only well-baked of these is the JXTA Shell.
|Have you explored JXTA? Tell us your first impressions and let others know what you've learned so far.|
|Post your findings|
It's said that complex systems require simple underpinnings. JXTA aims to provide only dial-tone for P2P development, a thin stack of fundamental services for discovery, presence management, and communication. Whether or not they've succeeded in providing enough remains to be seen by adoption rate and developer feedback.
Initially working with a Technical Advisory Committee, Joy's Law ("Some of the best people work elsewhere") and the desire for decent uptake -- both inside and outside Sun -- informed the decision to open JXTA. Not only does the project borrow the Apache Open Source license, but adopts Apache's meritocratic development model. Perhaps responding to criticism of Sun's closed-source approach to Java, Joy says, "We don't want to paint the world; we're not here to try to get everyone in the world to license this technology like we're doing with Java."
JXTA is housed on jxta.org. Anyone may join the mailing lists and are allowed read-only access to the source code, binaries, and documentation. A governance process affords CVS "commit" privileges to valued contributors. While not strictly an organization and with no current "owner," the JXTA team looks to the community for proposals and guidance thereon.
So where does JXTA sit vis-à-vis the rest of the P2P and Web Services spaces?
Today's metric of basic interoperability is, of course, XML, and JXTA is chock full of it. Every peer, group, talk, message, and pipe advertisement is an XML document. As an example, here's an instant message advertisement for the author's online presence:
While SOAP/XML-RPC is usually associated with Web Services, I was nevertheless surprised to find little interest for it among the JXTA technical advisory committee or development team. These platform- and language-independent XML-based remote procedure calls would bring simple interoperability independent of the particular JXTA implementation. They would also afford JXTA some crossover with the Web Services space and their NET Effect initiative.
Where in the Sun universe is JXTA?
Sun has carefully branded JXTA a research project. Little is known or said about its relevance to the rest of Sun itself. Foremost, it's obviously a continuation of the Sun "The Network is the Computer" vision; one does wonder, however, how much interest in JXTA there is within Sun and whether or not it has an associated business model.
Q: What is Sun's business model for Project JXTA?
A: Sun's main focus is to develop innovative systems and software that support pervasive networking. Project JXTA provides added value by enabling our systems and software to become active peers in a peer-to-peer network as a complement to Sun's current client/server network solutions" [The JXTA FAQ]
With respect to Sun's NET Effect Web Services initiative, JXTA could most be a nice fit for peer/service as well as intercomponent communication. Perhaps JXTA will provide the glue at the juncture between P2P and Web Services.
Integration of the functionality found in the JXTA Shell into the Solaris command-line environment is, of course, a no-brainer. If JXTA gleans the kind of adoption the team is hoping for, I'd be surprised not to see a P2P enabled *nix shell.
At Sun's "The Net Effect: To Services and Beyond" rally in February, CEO Scott McNealy proclaimed that Sun is "happy being an infrastructure systems supplier" -- perhaps that should simply be "infrastructure supplier."
Microsoft .NET and HailStorm
The obvious, and to some most interesting, question is JXTA's position relative to Microsoft's .NET and HailStorm. On the face of it, the claimed positioning is quite similar, synthesized as: an open, platform- and language-independent framework for peer interaction and interoperable services.
Yet the comparison is more oaks-to-acorns than apples-to-apples. Microsoft focuses on integration with its Windows operating system and cloud of related products and services, owning everything from the roots to the leaves. While Hailstorm has the promise of individual providers of Web services, these "partners" are hardly loosely coupled plug-ins. To quote Dale Dougherty, "If it's a layer-cake, Microsoft sells cakes, not layers." And don't forget the centralized clump in Hailstorm's decentralized architecture, the Microsoft Passport service. A centralized authentication and presence management system, "Microsoft wants to own your identity and rent it back to you for a few bucks per month," as Clay Shirky once said.
Sun, on the other hand, shows its Unix lineage with an explicit architectural and philosophical vision of loosely coupled (read: piped), interchangeable parts. JXTA targets only a layer or three in the stack and provides only enough girth to get the job done. In JXTA, security, presence, services, applications--anything beyond core inter-peer juxtaposition--is a plug-in. In theory at least, Microsoft's Passport could be plugged right into JXTA as one possible authentication mechanism ;-)
Independent P2P Efforts
JXTA could most certainly provide a much needed P2P stack for some of the infrastructure common to the various independent efforts in the P2P or collaborative computing space. I'm thinking here of Gnutella, OpenNap, Groove, desktop Websites, and the like. Kelly Truelove of Clip2 delves into a comparison of JXTA and Gnutella in his article, The JuxtaNet, part of this Openp2p.com JXTA package.
JXTA is by no means the first P2P stack, nor will it be the last. But the project does take a first stab at what such a framework might look like. It's success lies in its moving from research to useable framework, adoption by developers and extension by the community.
Disclosure:Rael Dornfest has been a member of JXTA's Technical Advisory Committee during its pre-launch development.
Copyright © 2009 O'Reilly Media, Inc.