Hello JXTA!

Want to build the next great peer-to-peer application? Sun Microsystem's 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 and 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 which is jxta.discovery.impl.service.DiscoveryService); 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 the net.jxta.peergroup.PeerGroup object.

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 getRemoteAdvertisements method 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 startApp 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 init method.