Hello JXTA!by Raffi Krikorian
Want to build the next great peer-to-peer application? Sun
juxtapose group has anticipated your
move. Foreseeing waves of companies and developers building
peer-to-peer applications, Sun has released its open source platform
juxtapose (JXTA) to make building distributed processes easier.
JXTA isn't a library of code that can be used to enable P2P applications; rather, it's a set of protocols that can be implemented in any language that will allow distributed client interoperability. It provides a platform to perform the most basic functionality required by any P2P application: peer discovery and peer communication.
As part of its open source release, Sun is distributing a preliminary Java binding for JXTA with the goal of having early-adopter engineers create simple P2P applications in Java. Sun's binding isn't complete, however; interfaces, implementations, and protocols are bound to change. Sun welcomes others to suggest changes as part of releasing JXTA as a open source project. So there's no excuse to avoid writing a 'Hello JXTA World' application in order to become familiar with JXTA.
JXTA 1, 2, 3...
At its core JXTA is simply a protocol for inter-peer communication. Each peer is assigned a unique identifier (peer ID). Each peer belongs to one or more peer groups in which the peers cooperate and function similarly and under a unified set of capabilities and restrictions. JXTA provides protocols for the basic functions -- create groups, find groups, join and leave groups, monitor groups, talk to other groups and peers, share content and services -- all of which are performed by publishing and exchanging XML advertisements and messages between peers.
Conceptually, each peer in JXTA abstracts three layers: the core layer, the services layer, and the applications layer. The core layer is responsible for managing the JXTA protocol; it should encapsulate the knowledge of all basic P2P operations. The core creates an addressing space separate from IP addresses by providing each peer its own unique peer ID, while also boot-strapping each peer into a peer group. Through protocols which the core knows how to implement, a JXTA peer can locate other peers and other peer groups to join (in a secure, authenticated manner, if so desired). The core layer can also open a pipe, a very simple one-way message queue, to another peer or group of peers. By using pipes, distinct parties can communicate with each other. The details of the core itself aren't of much concern to application developers; core development is like application server development, both of which functionality upon which application writers can rely.
The services layer serves as a place for common functionality which more than one, but not necessarily every, P2P program might use. For example, Sun has released a Content Management System (CMS) service that's implemented as a JXTA service. CMS provides a generic way for different applications to share files on JXTA peers so that decentralized Gnutella-like searchs may be performed against all of them. Once specific content has been located, the CMS provides ways for peers to download content. So the services layer provides library-like functionality which JXTA applications can control via logic located in application layer.
The third layer is where the P2P application truly lives. The upper layer might host a UI, so that the user can control different services, or it might be where the logic of an autonomous application operates. For example, a simple chat program can be built on this layer, making use of both the service and the core layer to allow people to send messages back and forth to each other. P2P applications should be fairly easy to build once a developer is familiar with JXTA, as the platform provides the basic peer-to-peer framework.
Whirlwind tour of the JXTA Java Binding
Sun's preliminary Java binding offers a set of Java classes that
implement the JXTA protocol and hooks into itself via a default set of
objects and services. The code contains two main packages,
net.jxta.impl. The former
encompasses all the JXTA-Java binding nterfaces, while the latter
contains the implementations of those interfaces. The mechanism to
discover other peers and peer groups is abstracted into the
net.jxta.discovery.Discovery class (the implementation of
the factory to create pipes is located in the
net.jxta.pipe.Pipe class (the implementation of which is
net.jxta.impl.pipe.PipeService), and so on. These
services handle the core protocols and are available via method calls
In order to publish advertisements for peers, peer groups, pipes,
and so on, you must first create the advertisement with the
net.jxta.document.AdvertisementFactory factory. Then all
the bean-type methods can be set before the advertisement is published
in the Discovery service. Along with publishing advertisements, the
Discovery service can be used to discover advertisements located in
other hosts. Calling the
sends a query either to a specific peer or to the peer group as a
whole, and the results will be added to the cache of advertisements
maintained by the local binding. Calling the
getLocalAdvertisements method will query the local cache
for the advertisements.
All JXTA applications and services follow a simple life cycle. The
init method is the first to be called; it is handed an advertisement
net.jxta.document.Advertisement) and information about
the peer group it has booted into
net.jxta.peergroup.PeerGroup). The advertisement is
dependent on what is booting within the platform: if initializing a
service, then a service advertisement
net.jxta.protocol.ServiceAdvertisement) is passed to it.
When booting an application, the group's peer group advertisement
net.jxta.protocol.PeerGroupAdvertisement) is handed to
it. Once initialization has finished, the
method is invoked, which is the signal to begin. At
startApp, most applications will spawn a thread in which
to run application code. A
stopApp method must also be
implemented to give the platform a way to end the program cleanly. (In
future Java bindings, the program may not be allowed to access the
platform after a given timeout if it cannot handle the
stopApp method properly.)
The binding requires a little more of services. Services need to
expose to applications and other services their methods, which is
accomplished by way of a Java interface returned by the
getInterface method. This interface contains methods
that can be called upon the service; or listeners can be registered
for asynchronous events. The interface must extend
net.jxta.service.Service. In practice, a proxy that
implements a shared interface with the service is preferred. Using a
proxy allows exposure only of the methods in the interface, hiding the
other methods in the service. A service also needs to be able to
return its advertisement for publication. In practice, this
advertisement is initially passed to the service as part of its