oreilly.comSafari Books Online.Conferences.
Articles Radar Books  

JXTA Takes Its Position

by Rael Dornfest
04/25/2001

Why JXTA?

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 Layer-Cake  

Architecture

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.

  • Hardware
    On the bottom is, of course, the hardware. JXTA is targeting not just the desktop PC, but anything that has an electronic pulse. One of their design goals was a platform thin and lightweight enough to bring P2P dial-tone to palmtops, set-tops, game consoles, cell phones, pagers, fridges, and so on.
  • Operating Environment or Virtual Machine
    Next floor up is the operating environment or virtual machine. It is important to note that while the implementation being made available on jxta.org rests on the JVM, this is but a reference implementation of the framework. The JXTA platform is fully expected to be implemented in C, Perl, Python, perhaps even Microsoft's Java-like C#. Both these layers are represented in the diagram as the "Any Peer" layer.
  • JXTA Technology Layer
    This is where JXTA's P2P voodoo happens.
    • Peer Groups provide facilities for group membership for reasons of communication, collaboration and sharing. Membership policies and methods of authentication/authorization are not defined in any overarching fashion, but delegated to the group itself.
    • Peer Pipes are interpeer communication channels similar to the *nix command-line concept of piping the output of one command as input to another. These pipes are unidirectional and may be dynamically coupled and uncoupled for flexible affiliation of peers. Piped messages, akin to ASCII strings in the *nix command-line world, are XML documents and so are platform, language, and protocol independent. One can just as easily push a SOAP or XML-RPC request through a pipe as "Hello, World!" This opens up doors for rather powerful application building and cross-over between peer-to-peer and the Web Services space with which they are usually associated.
    • Peer Monitoring is the traffic-cop of the core, handling authentication/authorization, metering, and so on.
  • Peer Services Layer
    Built on the JXTA core protocols' foundation, peer services are the building blocks of full-blown P2P applications. These are the analogues of individual commands in the *nix shell, the cats, greps, and mores. JXTA's first demonstration service/application, the JXTA Shell is considered a reference peer service.
  • Peer Applications Layer
    Here live the Gnutellas, Napsters, Grooves, Instant Messengers -- the P2P applications.

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.

Simplicity

Comment on this articleHave 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.

Openness

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.

Vis--vis

So where does JXTA sit vis--vis the rest of the P2P and Web Services spaces?

XML
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:

JXTA>cat adv0
<?xml version="1.0"?>

<!DOCTYPE jxta:PipeAdvertisement>

<jxta:PipeAdvertisement>
  <id>
    jxta://59616261646162614A787461503250333DA9279761254559B209922
    BACA69E1900000000000000000000000000000000000000000000000000000
    00000000301
  </id>
  <name>
    JxtaTalkUserName:rael
  </name>
</jxta:PipeAdvertisement>

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]

Related Articles:

Learning the JXTA shell

The JuxtaNet

JXTA Shell commands

Joy Announces JXTA

"Hello, JXTA!"


More from the OpenP2P.com

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.

Overall

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.



P2P Weblogs

Richard Koman Richard Koman's Weblog
Supreme Court Decides Unanimously Against Grokster
Updating as we go. Supremes have ruled 9-0 in favor of the studios in MGM v Grokster. But does the decision have wider import? Is it a death knell for tech? It's starting to look like the answer is no. (Jun 27, 2005)

> More from O'Reilly Developer Weblogs


More Weblogs
FolderShare remote computer search: better privacy than Google Desktop? [Sid Steward]

Data Condoms: Solutions for Private, Remote Search Indexes [Sid Steward]

Behold! Google the darknet/p2p search engine! [Sid Steward]

Open Source & The Fallacy Of Composition [Spencer Critchley]