JXTA Takes Its Position

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.

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.

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.

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?

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:

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.

Richard Koman's WeblogSupreme 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)