The JXTA Protocols

JXTA's designers chose to define the operations of the JXTA virtual network in terms of a set of protocols. A protocol, in essence, is a form of agreement in support of an activity. As long as all parties to an activity understand and follow the required protocols, the activity can take place. A corollary to that statement is that those protocols are the only thing each party has to understand to participate in the desired action.

In programming terminology, this means that if two peers want to participate on the JXTA network, the only thing they must have in common is an understanding of the protocols required for that participation. As far as JXTA is concerned, the peers might be implemented in different programming languages, run on different types of machines, or transmit messages through different network transport layer protocols (for example, TCP, HTTP, or Bluetooth). As long as the peers understand the JXTA protocols, they can become part of the JXTA virtual network and communicate with each other.

The JXTA protocols are expressed in terms of message exchanges. Regardless of what programming language a peer uses, at some point in the communication process, it must translate or bind JXTA messages to constructs in that programming language. Currently, several JXTA programming language bindings or JXTA bindings, for short exist or are being developed for Java, C, Objective C, Perl, Python, and Smalltalk, just to mention a few. The JXTA community actively develops new language bindings, so this list is growing.

From a programmer's viewpoint, a peer interacts with the JXTA system via an API provided by the JXTA bindings to the peer's programming language. An implementation of that API exposes the core functionality defined by the JXTA protocols as services a client can use to participate in P2P interactions. Because this book is about peer-to-peer programming in Java, we will only discuss the Java API to JXTA; other books and online resources provide descriptions of programming JXTA in other programming languages. Although the APIs to the JXTA protocols are different from programming language to programming language and it is indeed possible to design different APIs for a single language the JXTA protocols are defined via their message formats alone, and without reference to any specific programming language API.

The protocol specifications define JXTA messages in terms of XML data structures, as XML is a de facto standard for cross-platform representation of structured data. However, JXTA does not require that a peer have full XML-processing capability. Peers with limited resources, for example, might choose to precompile JXTA protocol exchanges into a binary representation. As long as those messages conform to the protocol specifications, that peer is able to participate on the JXTA network without having to process XML.

Although the JXTA specifications currently define seven protocols, a peer is not required to understand all seven to become part of the JXTA virtual network. Rather, the protocols define how a peer should act if it decides to implement the behavior defined by a protocol. Of course, the more protocols a peer supports, the fuller its participation in the JXTA network. In addition, a peer can also extend any of the existing protocols with new behavior.

Peer Resolver Protocol

The JXTA protocol messages form sets of query-response pairs: A peer sends a query, and some other peer sends a response to that query (see Figure 16.8). The format of the query and response messages are what the protocol specification defines. Responses to a query occur asynchronously in JXTA. The Peer Resolver Protocol (PRP) is the most fundamental JXTA protocol that specifies how a query is paired up with one or more responses.

Figure 16.8. The Peer Resolver Protocol: A query message is directed to a query handler. A peer that implements that handler might choose to process the query and respond. Processing a query can include any computation on the peer offering the query handler, and that computation might consume an arbitrary query string or document. Similarly, the processing of the query may result in an arbitrary string. Responses are matched up with queries by a service providing the PRP.

All other protocols needing a generic query-response mechanism rely on PRP. PRP helps standardize the formats of queries and query resolution. An implementation of PRP offers a generic query service to the JXTA network. With PRP, a query message is addressed not to a specific peer, but to a named query handler. A peer registers a query handler, and it can then answer queries addressed to that handler. Note, however, that a peer is not obligated to answer a query; also, answers as well as queries might be lost on the network because of network or peer failure.

The following XML schema defines the resolver query message:

 <xs:element name="ResolverQuery" type="jxta:ResolverQuery"/>  <xs:complexType name="ResolverQuery">     <xs:element name="Credential" type="xs:anyType" minOccurs="0"/>     <xs:element name="SrcPeerID" type="JXTAID"/>     <xs:element name="HandlerName" type="xs:string"/>     <xs:element name="QueryID" type="xs:string" minOccurs="0"/>     <xs:element name="Query" type="xs:anyType"/> </xs:complexType> 

As the schema definition shows, a query includes the sending peer's credential and peer ID, the name of the handler for the query, a unique query ID, as well as a chunk of free text that forms the body of the query. A peer that registers as a handler for the query can use the query text to perform some processing in order to determine a response.

The response message format is as follows:

 <xs:element name="ResolverResponse" type="ResolverResponse"/>  <xs:complexType name="ResolverResponse">     <xs:element name="Credential" type="xs:anyType" minOccurs="0"/>     <xs:element name="HandlerName" type="xs:string"/>     <xs:element name="QueryID" type="xs:string" minOccurs="0"/>     <xs:element name="Response" type="xs:anyType"/> </xs:complexType> 

The response contains the credential of the responding peer, as well as a text element Response. We will shortly explore the API offered by the Java bindings to take advantage of the PRP.

The Query-Response Paradigm

JXTA requires two-way communication between peers a query is of little importance if the sender is not able to receive a reply because of network limitations. Although this requirement appears easy to satisfy, some networks, such as pager networks, support only one-way communication. Those networks are not able to participate in the PRP.

Because the PRP is a fundamental JXTA protocol in the sense that other protocols depend on it for query/response resolution, such limited peers are not able to participate in the JXTA virtual network. However, the requirement to support two-way communication does not exclude networks with highly asymmetric characteristics. For example, it might not be possible to directly contact a peer inside a firewall, but a network might provide a mechanism to contact that peer in some indirect way, such as through a gateway. As long as that is possible, the peer inside the firewall can participate in the JXTA protocols with peers outside of it.

Endpoint Routing Protocol

The Endpoint Routing Protocol (ERP) specifies message routing in JXTA. We earlier described how routing consists of constructing an ordered list of hops through which a message travels from a peer to its desired destination. Relay peers that offer routing capability perform this task. If a router receives a route query and knows the route to the requested destination, it answers that route request with a list of hops that constitute the route. The sender of that message will use the first address in that list and dispatch the message to it. Network changes can cause a route to become obsolete at any time during the message's transmission, necessitating the discovery of a new route. The following XML schema defines the structure of a route:

 <?xml version="1.0" encoding="UTF-8"?>  <jxta:EndpointRouter>         <Src> peer id of the source </Src>         <Dest> peer id of the destination </Dest>         <TTL> time to live </TTL>         <Gateway> ordered sequence of gateway </Gateway>         <...................>         <Gateway> ordered sequence of gateway </Gateway> </jxta:EndpointRouter> 

As the message winds its way through the network toward its destination, each peer it goes through leaves a trace on that message. Those traces enable routers to remember new routes to destinations. As more peers cache correct route information to a destination, the faster route discovery becomes. The trace information left by peers on a message is also useful to detect loops, or to detect duplicate messages by routers.

The following XML schema defines the route query message, and shows how route caching is controlled:

 <?xml version="1.0" encoding="UTF-8"?>  <jxta:EndpointRouterQuery>     <Credential> credential </Credential>     <Dest> peer id of the destination </Dest>     <Cached>        true: if the reply can be a cached reply        false: if the reply must not come from a cache     </Cached> </jxta:EndpointRouterQuery> 

In response to this message, a peer router that has the requested route information returns an answer conforming to the following format:

 <?xml version="1.0" encoding="UTF-8"?>  <jxta:EndpointRouterAnswer>         <Credential> credential </Credential>         <Dest> peer id of the destination </Dest>         <RoutingPeer>                Peer ID of the router that knows a route to DestPeer         </RoutingPeer>         <RoutingPeerAdv>                Advertisement of the routing peer         </RoutingPeerAdv>         <Gateway> ordered sequence of gateway </Gateway>         < ...................>         <Gateway> ordered sequence of gateway </Gateway> </EndpointRouterAnswer> 

By defining this somewhat cumbersome protocol, ERP's objective was to ensure a high degree of success in guiding a message to its destination, not to ensure efficiency in message transmission. Thus, more intelligent peers might implement specialized routing algorithms to optimize route discovery. Figure 16.9 illustrates ERP in action.

Figure 16.9. ERP discovers routes and aids in message delivery.

Peer Discovery Protocol

You might recall from earlier in this chapter that advertisements provide the mechanism to describe resources on the JXTA virtual network. The discovery of resources based on their advertisements is what the Peer Discovery Protocol (PDP) specifies. The query message for PDP offers three pieces of information:

• Advertisement type

• An XML key or tag name

• A value that must correspond to the XML key

The message format is specified as follows:

 <xs:element name="DiscoveryQuery" type="jxta:DiscoveryQuery"/>  <xs:complexType name="DiscoveryQuery">         <xs:element name="Type" type="xs:string"/>         <xs:element name="Threshold" type="xs:unsignedInt" minOccurs="0"/>         <xs:element name="PeerAdv" type="xs:string" minOccurs="0"/>         <xs:element name="Attr" type="xs:string" minOccurs="0"/>         <xs:element name="Value" type="xs:string" minOccurs="0"/> </xs:complexType> 

The threshold attribute in the query message defines how many responses per peer we are expecting. The response message is as follows:

 <xs:element name="DiscoveryResponse" type="jxta:DiscoveryResponse"/>  <xs:complexType name="DiscoveryResponse">         <xs:element name="Type" type="xs:string"/>         <xs:element name="Count" type="xs:unsignedInt" minOccurs="0"/>         <xs:element name="PeerAdv" type="xs:anyType" minOccurs="0">                <xs:attribute name="Expiration" type="xs:unsignedLong"/>         </xs:element>         <xs:element name="Attr" type="xs:string" minOccurs="0"/>         <xs:element name="Value" type="xs:string" minOccurs="0"/>         <xs:element name="Response" type="xs:anyType" maxOccurs="unbounded">                <xs:attribute name="Expiration" type="xs:unsignedLong"/>         </xs:element> </xs:complexType> 

The response element in this message includes the advertisement that the JXTA peer located in response to the query, in addition to the responding peer's own advertisement. The message exchange defined by PDP represents the lowest-level discovery mechanism in JXTA. Applications can build higher-level discovery protocols based on PDP.

Rendezvous Protocol

By default, query messages only reach peers that share a physical network with the inquiring peer. The Rendezvous Protocol (RP) defines how queries propagate through rendezvous peers. The propagation scope for messages via the RP is limited to a set of peers that form a logical group, or peer group. (We will discuss peer groups shortly.) This scope is reflected in the advertisement message of a peer that announces itself as a rendezvous peer, as the following XML message from the JXTA specifications shows:

 <?xml version="1.0" encoding="UTF-8"?>  <jxta:RdvAdvertisement>         <Name> name of the rendezvous peer</Name>         <RdvGroupId> PeerGroup UUID </RdvGroupId>         <RdvPeerId>Peer ID of the rendezvous peer</RdvPeerId> </jxta:RdvAdvertisement> 

A peer discovers a rendezvous peer via this advertisement type and then connects to it. When a peer requests that connection, the rendezvous peer assigns a lease to the connection; the request for the connection includes the desired lease time. A rendezvous peer receives a message and propagates that message to other rendezvous peers it knows. The message format that controls that propagation assumes the following format:

 <xs:element name="RendezVousPropagateMessage"    type="jxta: RendezVousPropagateMessage"/ >  <xs:complexType name="RendezVousPropagateMessage">         <xs:element name="MessageId" type="xs:string"/>         <xs:element name="DestSName" type="xs:string"/>         <xs:element name="DestSParam" type="xs:string"/>         <xs:element name="TTL" type="xs:unsignedInt"/>         <xs:element name="Path" type="xs:anyURI" maxOccurs="unbounded"/> </xs:complexType> 

Pipe Binding Protocol

A pipe defines a communication channel between two peers. Each pipe has two ends: an input pipe and an output pipe, for receiving and sending messages through the pipe, respectively. The Pipe Binding Protocol (PBP) defines how a pipe's input and output ends bind to a peer's endpoint. JXTA defines different types of pipes, and a pipe's advertisement includes an indication of the pipe's type, in addition to its name and ID:

 <?xml version="1.0" encoding="UTF-8"?>  <jxta:PipeAdvertisement>         <Name> name of the pipe</Name>         <Id> Pipe Id </Id>         <Type> Pipe Type </Type> </jxta:PipeAdvertisement> 

The following message format defines a pipe binding request message:

 <xs:element name="PipeResolver" type="jxta:PipeResolver"/>  <xs:complexType name="PipeResolver">         <xs:element name="MsgType" type="xs:string"/>         <xs:element name="PipeId" type="JXTAID"/>         <xs:element name="Type" type="xs:string" minOccurs="0"/>         <xs:element name="Cached" type="xs:boolean" default="false" minOccurs="0"/>         <xs:element name="Peer" type="JXTAID" minOccurs="0"/>         <xs:element name="Found" type="xs:boolean" minOccurs="0"/>         <xs:element name="PeerAdv" type="xs:string" minOccurs="0"/> </xs:complexType> 

The Found and PeerAdv elements in this message are sent by the peer that was able to resolve the pipe's endpoint. We will see shortly how pipe endpoint resolution occurs via the Java API.

Peer Information Protocol

The Peer Information Protocol (PIP) fills a bit of a different role in the JXTA universe than the other protocols. Its purpose is to allow peers to exchange runtime information, such as a peer's uptime, or the number of messages a peer processed in a given period of time. That PIP exists in the JXTA specifications reveals the importance of such metadata about peers for the proper functioning of a P2P network. Tool vendors can use this protocol to hook network-monitoring software into peers and allow system administrators to track the performance of the JXTA network.

As it exists in the JXTA specifications, PIP is rather limited in the kinds of information it defines about a peer. In addition, some peers that claim to support PIP might only provide a partial set of that information. The idea behind PIP, though, is that implementers of this protocol can extend it with other sorts of information; because this protocol, as every other JXTA protocol, uses XML to define its message formats, extending PIP with new information is as easy as adding elements to an XML document. As it stands now, PIP's message format is as follows:

 <xs:element name="PeerInfoResponse" type="jxta:PeerInfoResponse"/>  <xs:complexType name="PeerInfoResponse">         <xs:element name="sourcePid" type="xs:anyURI"/>         <xs:element name="targetPid" type="xs:anyURI"/>         <xs:element name="uptime" type="xs:unsignedLong" minOccurs="0"/>         <xs:element name="timestamp" type="xs:unsignedLong" minOccurs="0"/>         <xs:element name="response" type="xs:anyType" minOccurs="0"/>         <xs:element name="traffic" type="jxta:piptraffic" minOccurs="0"/> </xs:complexType> <xs:complexType name="piptraffic">         <xs:element name="lastIncomingMessageAt" type="xs:unsignedLong" minOccurs="0"/>         <xs:element name="lastOutgoingMessageAt" type="xs:unsignedLong" minOccurs="0"/>         <xs:element name="in" type="jxta:piptrafficinfo" minOccurs="0"/>         <xs:element name="out" type="jxta:piptrafficinfo" minOccurs="0"/> </xs:complexType> <xs:complexType name="piptrafficinfo">         <xs:element name="transport" type="xs:unsignedLong" maxOccurs="unbounded">                <xs:attribute name="endptaddr" type="xs:anyURI"/>         </xs:element> </xs:complexType> 

Peer Groups and the Peer Membership Protocol

One of the most powerful aspects of JXTA is its capability to overcome the physical partitioning of a network. Peers can communicate on the JXTA network, even though they might reside on different sides of firewalls and NAT points, or use different network communication protocols. However, network partitioning in the physical world is useful for various reasons. For example, by using a set of private IP addresses behind a secure NAT point, a company's computers form a group inaccessible from the outside. The company can provide services on that private network, such as databases or application software, without having to be concerned about unauthorized access from the outside. JXTA offers the equivalent of network partitions in the form of peer groups.

Any sort of peer group can be created, each with a unique ID and a name. As other JXTA entities with IDs, each peer group has an advertisement. Peers that share a common interest join a peer group, and a peer may be a member of one or more groups. There are several reasons why a peer might want to become member of a group.

First, groups form a scoping environment for JXTA queries: When a peer propagates a query for an advertisement, that query will by default propagate only through peers that are members of the peer group in which message propagation commenced. Because of query propagation scoping, resources available to one peer in a group are accessible to other group members as well, facilitating resource sharing. Such resources include anything with an advertisement, such as pipes or other peers. Because pipes and message propagation are the mechanisms through which peers communicate, peers must belong to the same peer group to send messages to one another.

Second, peer groups outline security boundaries on the JXTA network. When a peer wants to join a peer group, it must apply for membership in that group. The Peer Membership Protocol (PMP) defines how a peer obtains group membership.

In essence, the application is similar to someone applying for membership in a professional organization. An applicant initiates the process by filling out an application form with some basic information, such as job history and educational background. Because many professional organizations require a minimal education level or job history from candidates, the organization's membership committee then evaluates the application, possibly confirming the information the applicant provided. After that information has been verified, the applicant is qualified to join. At that point, the applicant joins by paying the initial membership dues and signing a membership form. Thereafter, the new member receives a membership card, verifying his standing as the organization's member.

The JXTA PMP outlines a similar protocol, consisting of an application phase and a joining phase. Figure 16.10 illustrates the process of joining a JXTA peer group. Each peer group operates a service implementing PMP. When a peer applies for group membership, it specifies its credentials, in addition to a reference to the authenticator capable of verifying those credentials. The group's membership service then uses that information to verify the peer's identity via the specified authenticator. That verification might take any form, including contacting third-party components, such as a centralized database, or asking a peer to answer an arbitrary set of questions. After the peer prequalifies for group membership in this manner, it can request to join the group. Joining results in a credential issued by the membership service. That credential will thereafter be used in all peer operations requiring group membership, such as accessing services and other resources specific to a group.

Figure 16.10. Joining a JXTA peer group.

Finally, JXTA groups provide mechanisms for peers to monitor other peers sharing a peer group. In that way, JXTA peer groups define a monitoring environment as well.

Figure 16.11 gives an overview of the manner in which peer groups impose a virtual partitioning on a network. The driver in the automobile accesses a network via a handheld device. The network provider offers various services, and those services are usable by anyone belonging to the provider's peer group (gas station locator, weather service). In addition, the mobile user created his own secure peer group to share notes from a business meeting with the company's sales representatives on the road, and with a partner company's employees. Finally, the user is also a member of his corporation's secure internal peer group, enabling him to use services offered by the company (employee directory, factory floor status reporting, and a printer).

Figure 16.11. Virtual network partitioning via peer groups.

The JXTA specifications define two kinds of peer groups: a Platform Peer Group and a Standard Peer Group. By default, every peer is a member of the Platform, or World Peer Group, and joins that group when the peer boots up. The World Peer Group defines implementations of the basic JXTA protocols, such as the membership, discovery, and resolver protocols. Peer groups form a parent-child hierarchy. All the services available in a parent group are also available in child groups.

By virtue of membership in the World Peer Group, every peer on the global JXTA network can potentially communicate with every other peer. The Standard Peer Group, in turn, can be used to implement user-defined peer groups (to provide a scoping, security, or monitoring environment).

JXTA Services

The JXTA protocols are definitions of abstract behavior, by means of the message formats that pass between peers. In order for the peers to participate in the JXTA virtual network, they must have implementations of those protocols available, and exposed via an application programmer's interface (API). JXTA protocol implementations are services. Services also include software components that support activities other than the core JXTA protocols, and which are available for other peers to use. Those services rely on the core JXTA service implementations. Higher-level JXTA-based applications depend on an increasingly higher-level service layer. Figure 16.12 illustrates that structure.

Figure 16.12. Three layers of JXTA services. The core layers implement the fundamental JXTA protocols. Those services in turn are employed by a higher-level service layer. Finally, applications take advantage of those services to interoperate on the JXTA network.

As any other JXTA resource, services assume unique identifiers, and announce their presence via JXTA advertisements. If a service is capable of communicating with other peers via JXTA pipes, its advertisement might include the communication pipes' advertisements as well.

Because services have IDs and corresponding advertisements, service discovery is similar to peer discovery: A peer issues a query for a specific service. That query, in turn, propagates through the peer group via the rendezvous network until rendezvous peers locate an advertisement for the specified service. At that point, the service's advertisement is returned to the requestor, causing that advertisement to be cached by rendezvous peers along its way. The service advertisement could contain the advertisement of a pipe described in the service's advertisement. The requestor peer can invoke the service through that pipe.

Although pipes are the JXTA-specified means of peer-to-peer message passing, JXTA does not prescribe how a service should be invoked: Any service invocation is possible, including opening direct socket connections to the service, performing remote method invocations (RMI) on a remote service object, or simply sending messages to the target peer formatted in accord with the Simple Object Access Protocol (SOAP) document model.

To support flexible service invocation, some services might specify a proxy object: An object that represents the service on the JXTA network, and has the capability to communicate to other network resources, some of which might not be accessible via JXTA communication mechanism. This proxy-based service invocation is similar to Jini's service proxies, which are free to choose any communication mechanism to connect to other network resources. Figure 16.13 illustrates some of the ways a peer can invoke a service.

Figure 16.13. A sampling of service invocation methods: (a) Query/response message, (b) TCP sockets, (c) service proxies.

PeerGroup Services

JXTA provides for high service availability by having certain services belong, not to a single peer, but to the whole peer group. In essence, several peers implement the service, and those implementations are deemed equivalent by the JXTA system; that is, they have the same IDs and advertisements. A peer requesting a peer group service can use any of those service instances. The services implementing the core JXTA protocols are peer group services.

Note that JXTA does not provide for load balancing or service fail-over. If a peer providing a peer group service fails, the client of a service on the failed peer must discover a new instance of the service. If the failed peer contains data that was modified in the course of using that service, that data will not be available on other peers running instances of the service, unless an application developer built data replication into his JXTA service implementation. The concept of a peer group service is illustrated in Figure 16.14.

Figure 16.14. Peer group services.

JXTA Modules

In locating and interacting with other services, JXTA aims to facilitate peer-to-peer computing across a diversity of language and execution environments. A module denotes a chunk of functionality (code) available to JXTA peers in a peer group. JXTA uses the concept of module IDs and advertisements to define services and service types.

In JXTA, you can locate a service based on its abstract behavior, a particular specification or wire protocol for that service, or an implementation of a specification. An underlying assumption is that you have some prior knowledge to construct a query for any of those advertisements. That prior knowledge typically means knowing the IDs for a module's class, spec, or implementation, respectively.

An identifier for an API, or some local behavior, is the module's class ID, which also includes a base class ID, declaring what class this module specializes (extends). Services available in a group are defined by a set of module class IDs. Different groups might use specifications of common classes which are not network-compatible, but the local APIs for those classes will be similar, if their module class IDs are identical. Combining the peer group's ID with the module's class ID uniquely identifies a service.

When constructing a JXTA service, you would normally describe what other JXTA services your service depends on based on those services' module class IDs. To draw a comparison to Java classes, a module class is somewhat analogous to a Java interface a Java interface also defines some local behavior, but how that behavior might be accessed over the network is specific to an implementation of that interface. (Keep in mind that JXTA module classes are not specified in the Java programming language, but by abstract IDs and advertisements.)

Module class IDs are advertised by module class advertisements. A module class advertisement provides a description of what a module class ID means. These advertisements are meant for programmers who want to create modules offering the abstract behavior designated by the module's class ID. It does not specify how to invoke the service.

There can be many embodiments of a module class, each of which is termed a module specification, or module spec. A module specification represents network behavior, or wire protocols, that a module might embed. Module specs with identical Module Spec IDs are network-compatible.

A module spec advertisement provides the description of the protocol defined by the module spec. Although a module class defines a service's dependency on some abstract behavior, a module spec designates dependency on a given specification for that behavior. As such, module spec advertisements might also describe how to access a module. Similar to module class advertisement, module spec advertisements are also chiefly aimed at a programmer implementing a specification.

Using a module's spec ID, an implementation of that module can be located in the peer group. These implementations themselves are defined by module implementation IDs. Module implementation IDs are advertised via module implementation advertisements. This type of advertisement might provide a complete URI to the code and JAR files needed to execute the implementation, in addition to other descriptive elements; a peer could use those URIs to download the needed code. The module spec ID on which an implementation is based is also included.

The relationship between the different module IDs and advertisements is depicted in Figure 16.15. Note that JXTA does not mandate that a module's implementation be available locally to a peer. Rather, using information in the module implementation advertisement, a peer can download pieces of code (JAR files) needed to instantiate and invoke a service. How a peer might download that code is not specified by JXTA the peer could use HTTP, FTP, or any other network protocol. A peer might even use the Java mobile object paradigm specified in RMI.

Figure 16.15. Modules define some behavior in JXTA. Module class IDs denote local behavior (an API), module spec IDs designate network behavior, and module implementation IDs describe the implementation of a specification.

In summary, to find a module, you'd need to know the module's class ID, spec ID, or implementation ID, depending on whether you're looking for some abstract behavior, a specific wire protocol to access that behavior, or an implementation. In the next section, you will see an example of defining a service's module class and spec, and specifying an input pipe in the module spec advertisement through which other peers can send messages.