Articles: Peer-to-Peer: From JMS to Project JXTA Part 2: Comparing the code

Print-friendly Version

Articles Index

This is the second of two articles that compare the peer-to-peer (P2P) features provided by the initial implementation of Project JXTA technology with those provided by the Java^TM Message Service (JMS). Part 1 introduced the concept of peer-to-peer computing and included some example code for a JMS application, JMSChat, to illustrate how you can develop a form of simple peer-to-peer application with existing messaging technology.

This article compares the JMSChat application with the Project JXTA myJXTA demonstration application. The comparison highlights some of the differences between a simple peer-to-peer application developed with existing messaging technology and a generic approach specifically intended for peer-to-peer network computing.

Before studying the code, let's review some obvious comparisons between JXTA technology and JMS, outlined in Table 1.

Terminology and Architectural Differences

For a meaningful comparison, you'll need to understand some differences in terminology between JXTA technology and JMS. Consider the components in a JXTA network, as they are common to many forms of P2P network implementation:

• Peers and peer groups
• Messages
• Pipes
• Services and applications
• Advertisements

We will now look at each component in turn to consider terminology and architectural differences.

Peers and Peer Groups

In a P2P network, a peer is an independent, asynchronous entity in the network that is identifiable by an associated peer ID.

JMS is used for enterprise messaging, which uses slightly different terminology to identify communicating entities. For example, JMS users are referred to generically as clients.

For the purposes of this article, peer-to-peer terminology will be used consistently, so please consider that each executing instance of the JMSChat and myJXTA applications represents one individual peer.

Table 2 outlines some of the differences between that way that Project JXTA and JMS support communication between peers.

Messages

All communication in a JXTA network is achieved by sending and receiving messages. A message is an ordered sequence of named and typed contents called message elements. Two representations exist for messages: XML and binary. JXTA uses a binary wire format that enables the transfer of any type of data (XML and binary). JXTA uses a mime-type element description to determine the most efficient way to transfer data from one peer to another one.

JMS messages consist of a standard header, properties (application-specific properties, standard properties, or provider-specific properties), and a body. JMS defines several types of message body to cover the majority of messaging styles.

Overall, JMS is not as interoperable as JXTA technology. The JMS specification requires that a JMS client must be able to accept messages created by a different JMS provider but not that two JMS providers can send messages directly to one another.

Pipes

JXTA communication is through pipes, which are the JXTA abstraction of network connections. Think of pipes as virtual communication channels to allow peers and services to exchange messages -- without needing to know the actual network addresses of the network destinations (endpoints) represented by the pipes.

JXTA assumes that there is software at each end of the pipe to send or receive, as well as to manage associated pipe message queues or streams. Although pipes are asynchronous, and hence easy to implement on top of message queues, message queues are optional.

Pipes offer both point-to-point and propagate modes of communication. A point-to-point pipe connects exactly two pipe endpoints together: an input pipe on one peer receives messages sent from the output pipe of another peer. A propagate pipe connects one output pipe to multiple input pipes, for one-to-many messaging.

You can build additional types of pipe services using the basic core pipes. A secure unicast pipe is a type of point-to-point pipe that provides a secure communication channel. In addition, the current Java implementation includes bidirectional pipes and bidirectional/reliable pipes.

JXTA does not require a centralized directory service for pipe binding. Pipe binding is done in a decentralized fashion through the resolver service. Pipes can dynamically rebind to a new peer endpoint every time a message is sent. Pipes can be disconnected and reconnected dynamically to different endpoints, caching and resynchronizing messages when the pipe is reconnected.

JMS does not handle connection caching and resynchronization. JMS communication uses the facilities of an asynchronous messaging system. The JMS API provides client interfaces tailored to two different messaging domains, the point-to-point domain and the publish and subscribe (pub/sub) domain. Each domain encapsulates the provider-specific addressing information within a Destination object. Destinations are JMS administered objects that are typically looked up through JNDI in order to provide portability.

• The destination for a point-to-point message is a message queue: each message is addressed to a specific queue and clients extract messages from the queue(s) that hold their messages. Each message has only one consumer.
  
  
• The destination for a publish and subscribe message is a topic: each message is addressed to a topic in a content hierarchy. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. Each message may have multiple consumers and the messaging system takes care of distributing the messages from a topic's multiple publishers to its multiple subscribers.

Services and Applications

A service is basically a form of application that is available to one or more clients. In a client/server network, services are provided by centralized servers, and clients request the service from a server. In a P2P network, every peer is an active participant where peers can request services from other peers, and/or provide services to other peers.

Both peers and peer groups can offer JXTA services. A service offered by an individual peer is a form of centralized service because if the peer is unavailable so is the service. A peer-group service is available from multiple peers within a peer group, which ought to enhance the availability and scalability of that service.

The JXTA core protocols allow for peer discovery, peer group formation, peer communication, peer monitoring, and security. The reference implementation of JXTA technology provides an implementation of the JXTA core protocols as core services to provide a platform on which to develop P2P applications:

• DiscoveryService to allow peers to discover other peers, peer groups, pipes, and services.
  
  
• MembershipService to determine which peers belong to a peer group and to handle peers leaving and joining a group.
  
  
• PipeService to provide communication between peers. The pipe service creates input and output pipes, and it sends and receives messages.
  
  
• ResolverService to allow peers to refer to other peers, peer groups, pipes, or services indirectly through a reference (known as a JXTA advertisement). The resolver provides a universal binding mechanism to perform any binding operations (DNS, socket binding, service location) found in traditional distributed systems. A single resolver protocol replaces multiple binding protocols (DNS, socket, directory, and so on).

On top of these JXTA core protocols you can develop JXTA services and applications.

For example, another service used by the myJXTA application is the RendezVousService for propagating messages within a peer group. A rendezvous peer is a special peer that can help a peer discover other peers in the network by storing the advertisements of the peers that it knows about. A rendezvous peer can also forward discovery requests to other rendezvous peers.

JXTA also defines an EndpointService to provide an API and environment to all endpoint protocols. This is available for applications that need to understand and control the topology of a JXTA network so, in general, applications are not expected to use this API. For an example of how you might use the EndpointService directly, check out GISP (Global Information Sharing Protocol), which uses EndpointService for its messaging.

JMS does not have the concept of services, but the JMS provider can be thought of as a form of service provider because it provides a message-exchange service that services requests from a JMS application. A JMS application consists of a set of application-defined messages and a set of clients that exchange them. The exchange of messages requires a JMS provider, such as an enterprise messaging system, which means that this approach is inherently centralized. Even so, it is possible to implement a form of peer-to-peer application, as demonstrated by the JMSChat chat application.

Advertisements

All resources in the JXTA network are represented by a metadata XML document called an advertisement. JXTA peers publish and discover advertisements representing other JXTA resources such as peers, peer groups, pipes, and codats (codat refers to any arbitrary binary content that can be either code or data).

JMS applications do not publish advertisements. A form of discovery is made possible because the JMS API uses the JNDI API for administration, and the JNDI API is layered over existing naming and directory services. The JMS API defines ConnectionFactories and Destinations as administered objects that are configured and placed in a JNDI naming context so that JMS clients can look up and use them. This makes JMS applications easy to deploy and administer.

JXTA provides a uniform way to represent any network resources, such as a peer, peer group, service, and pipe. Unlike JMS, JXTA does not require a separate mechanism to describe a service and a connection. The same advertisement abstraction is used for describing a service and connection.

Code Differences: JMSChat versus myJXTA

A good way to better appreciate the differences between Project JXTA and JMS is to study some example applications. I chose a chat application because Project JXTA already supplies a demonstration application called myJXTA that implements a set of common P2P applications including secure one-to-one chat, peer group chat, and file sharing. The code for myJXTA continues to evolve, thanks to members of the project JXTA community, so I suggest that you download the latest stable releases of the binaries, documentation, and source code from the Project JXTA download area. Note that the Project JXTA web site still contains some references to the former name of the myJXTA application, InstantP2P.

The first article in this series introduced a simple JMS chat application, JMSChat, for the exchange of messages between users. If you are not already familiar with JMSChat, you can skip ahead to the code for the JMSChat application, included later in this article.

For comparison purposes, this discussion concentrates on the differences between the implementation of the chat functions. I don't go into differences in user interface and certain features provided only in one application, such as the file-sharing feature of myJXTA.

A typical chat application should allow an individual peer to chat with another individual peer, and it should also allow one individual peer to chat with a group of peers. Both JXTA technology and JMS can implement such one-to-one and one-to-many exchanges, but differently.

The key difference is that JXTA is fully decentralized; it does not require a centralized message server as broker for every message sent. As no centralization is required, JXTA enables a greater level of scalability. Also, because messages are delivered directly to a peer, there is no chance that someone on the centralized server can forge or read the message sent, and so JXTA enables a higher level of security.

JMS does not directly support the concept of peers or peer groups. However, JMS provides access to an asynchronous messaging facility that you can use to implement a message-based chat facility with very little effort. You could implement a one-to-one chat facility using a message queue, provided by the JMS point-to-point (PTP) domain, but the sample application JMSChat uses the JMS pub/sub domain to provide a centralized location for the exchange of messages. In this way, the JMS provider allows peers (the JMSChat users) to chat one-to-one and one-to-many.

JXTA technology makes it easy to implement both forms of chat through the provision of peers, peer groups, and discovery capabilities:

• In a JXTA network, a peer group is a collection of peers that share resources and services. Peer groups are an essential mechanism in JXTA for scoping peer communication and message propagation. A JXTA application can spontaneously control the scoping of every message through the peer group context.
  
  
• A peer joins a peer group to use a particular service or application, in this case a chat application. The service or application may be running on all peers in the group, or just a few of them. In the case of myJXTA, the chat client runs on every peer that participates in the chat application.
  
  
• An individual JXTA peer is automatically a member of the universal peer group, NetPeerGroup. The myJXTA application uses the MembershipService that is provided in the reference implementation of the JXTA platform to implement the membership policy that allows a peer to establish an identity within a peer group.
  
  
• The JXTA platform provides discovery capabilities so that peers can find the service -- or another peer -- that interests them. The JXTA platform also provides firewall routing capabilities to take care of communication that needs to traverse a firewall.

JMSChat

The JMSChat client is a multithreaded Java program that uses a pub/sub topic for broadcasting messages to all subscribers to the topic. It creates the user interface and several threads; one to send messages, one to receive messages and one to update the user interface.

JMSChat sends messages on the publishing thread, as follows:

1. Performs a JNDI look up of the TopicConnectionFactory and topic
2. Creates a connection and session
3. Creates a TopicPublisher
4. Creates a TextMessage
5. Publishes messages to the topic
6. Closes the connection, which automatically closes the session and TopicPublisher

JMSChat receives messages on the subscribing thread, as follows:

1. Performs a JNDI look up of the TopicConnectionFactory and topic
2. Creates a connection and session
3. Creates a TopicSubscriber
4. Starts the connection, causing message delivery to begin
5. Listens for the messages published to the topic
6. Closes the connection, which automatically closes the session and TopicSubscriber

The complete application consists of the following code:

• JMSChat.java

• The chat client program is JMSChat.java.
  It creates the user interface and several threads: one to send messages, one to receive messages, and one to update the user interface.
   
• JMSChatThread.java
  The message sender or receiver thread is JMSChatThread.java.
  When running as a sender (publisher), it connects to a JMS topic and sends messages. When running as a receiver (subscriber), it connects to the same JMS topic and receives messages.
   
• ChatData.java
  The threads exchange information as control data implemented by ChatData.java.
  It provides the control data and access methods to allow the different threads to exchange information. For example, the user interface passes outbound messages to the sender thread to be forwarded to the JMS topic. Conversely, the receiver thread passes inbound message to the user interface to be displayed.
   
• CardPanel.java
  The user interface uses CardPanel.java.
  The log-in panel and chat panel are implemented as CardPanel objects to make it easy for the user interface to switch between the log-in panel and chat panel.

The JMSChat application shows that it is possible to create a simple peer-to-peer application with just a few JMS API calls, leaving the underlying messaging infrastructure to handle the communication between the end users.

Now that JMS is an integral part of the 1.3 release of the J2EE platform, it is possible to exploit functions provided by a J2EE-compliant product that are not available in JMS alone. For example, message sends and receives can participate in Java Transaction API (JTA) transactions.

As implemented, JMSChat has several limitations. Some limitations result from design decisions made to simplify the code for the example, and some result from limitations in the underlying technology:

• Messaging products are inherently asynchronous but, in order to simplify the code, JMSChat consumes messages synchronously because the receiver thread blocks until a message arrives. This is not a major limitation for JMSChat, as it uses separate threads for sending and receiving messages, but the code could be modified to consume messages asynchronously by adding a message listener, which is similar to an event listener. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener's onMessage method. For an example of a message listener, please see the pub/sub example in the JMS Tutorial.
  
  
• JMSChat does not incorporate any security features because JMS does not specify security mechanisms under client control (security is considered to be a JMS provider-specific feature). However, JMSChat could be extended to exploit the security features in the Java 2 Platform, Standard Edition.
  
  
• JMSChat uses the pub/sub messaging domain, which imposes some restrictions.
  • First, there is no logical distinction between one-to-one and group chat. As no security features are implemented in JMSChat, any number of peers can potentially access the chat topic and join an existing chat. As an alternative design, the point-to-point messaging domain could have been used for the one-to-one chat. With point-to-point messaging, each message has only one consumer.
  • Second, a timing dependency exists between publishers and subscribers. A subscriber can consume messages published only after subscribing to the topic, and the subscriber must be active to consume messages. The dependency makes sense for a chat application, as the subscribers see messages only while they are actively taking part in the chat, but it may not be suitable for other peer-to-peer applications. One alternative design is to use the point-to-point messaging domain because messages are retained on the message queue until they are consumed, and this removes the timing dependency. However, each message has only one consumer. This makes PTP a poor choice for the group chat, for example, as it potentially requires a message queue for every user. Another alternative is to use the pub/sub messaging domain with durable subscriptions. Durable subscriptions can receive messages sent while the subscribers are not active. They provide the flexibility and reliability of message queues but still allow messages to be sent to many recipients.
  
  
  
• One big disadvantage of the JMSChat application is that each peer (client) has no real knowledge of other peers. Instead of decentralized, peer-to-peer discovery, each peer needs to know the name of the JMS topic that provides the central point of communication between the peers. The JMSChat application uses a centralized service (JNDI look up) to locate objects.

In addition to the limitations of the JMSChat example application design, some limitations are inherent to JMS. JMS does not define an interoperable wire format for the exchange of messages between enterprises, nor does it specify a router-router API.

Overall, JMSChat is much more suitable as a chat facility within an enterprise than it is for use as an Internet-based peer-to-peer chat facility.

myJXTA

The JXTA demonstration application myJXTA implements a set of common peer-to-peer applications including secure one-to-one chat, group chat, and file sharing. It comes with a user guide that explains how to run the application, and so this discussion concentrates on the implementation.

The myJXTA application allows users to:

• Navigate through the JXTA network peer groups
• Create and join peer groups
• Join a peer group chat room
• Create a one-to-one chat session with another peer
• Search and share documents

The main routine of myJXTA constructs the GUI, and so the application behaves slightly differently depending on the target device (desktop or PDA). For comparison with JMSChat, this article assumes the myJXTA desktop GUI, but as I mentioned before this article doesn't really discuss the user interface differences.

The desktop version of the myJXTA application starts, as follows:

1. Calls the class constructor to construct the initial frame for the GUI.
   
   
2. Joins the world peer group, NetPeerGroup, by creating an instance of the net peer group, which is the first group instantiated after booting. This is achieved by calling the newNetPeerGroup method in the net.jxta.peergroup.PeerGroupFactory class. This creates a default platform peer group from which a new net peer group is instantiated. Note that the end user is prompted for initial configuration information when the application is started for the first time. The user can set some JXTA properties if they do not want to be prompted. This approach simplifies the method by which applications can start (bootstrap) the JXTA platform.
   
   
3. Registers a listener to listen for rendezvous events from the RendezVousService server.
   The RendezVousService is the JXTA service for propagating messages within a JXTA peer group. For example, a rendezvous peer helps a peer discover other peers.
   
   
4. Creates an instance of the PeerGroupManager class.
   This class is central to the myJXTA application as it manages peer and peer group discovery. As soon as the instance is created, it immediately starts the discovery of peers and peer groups in the NetPeerGroup. The instance maintains the list of groups that the peer is a member of. In particular, it keeps track of the currently selected peer group as services are defined on a group level.
   
   
5. Schedules the run method on a WorkerThread so that it will be run as soon as time is available. The run method proceeds, as follows:
   • Waits for a connection to be established to a RendezVousService server. This is achieved by calling the waitForRendezVous method in the net.jxta.instantp2p.PeerGroupManager class to block until a rendezvous peer is found and the connection to the service has been established.
   • Calls the setUp method to set up the main frame of the GUI. This includes calling the layoutComponents method which creates the Messaging panel for the chat, the GroupMessaging panel for the group chat, and the instance of the Chat class (the instance of the Chat class is created in the GroupMessaging constructor).

Once the application has displayed the main GUI frame, nearly all of the remaining processing is driven by events. For more information on the overall implementation of myJXTA, please refer to the detailed description of the source code on the Project JXTA web site.

Now let's focus on the myJXTA chat functionality. In terms of implementation, the myJXTA chat code is packaged in two classes, Chat and GroupChat, and in one interface, MessageBoard.

The interface, net.jxta.instantp2p.MessageBoard, mainly takes care of displaying messages on the GUI. The myJXTA GUI creates two panels that implement the MessageBoard interface: a Messaging panel for the Chat class, and a GroupMessaging panel for the GroupChat class.

The net.jxta.instantp2p.Chat class allows the user to perform a secure one-to-one chat with another peer in the current peer group. To help you understand the description of this class, please bear in mind that JXTA pipes are the core objects for exchanging messages; each chat user (peer) is represented by a pipe advertisement, and the pipe advertisement is then used by the pipe service to create associated input and output pipe endpoints.

A JXTA secure pipe uses a JXTA Transport Layer Security (TLS) virtual transport to establish a secure end-to-end connection between two peers. Secure pipes uniquely enable secure message exchange between peers even if the message has to be relayed by a relay peer -- even if the two communicating peers are behind firewalls. The relay peer does not decrypt the message; it just forwards the binary-encrypted message to its destination, so JXTA enables true peer-to-peer, end-to-end security.

The methods of most interest in the Chat class are:

• Chat constructor which creates a new chat instance.

  The constructor is passed the PeerGroupManager instance that contains the group and peer information, and the MessageBoard instance for displaying the chat results.

  The Chat constructor does the following:

  1. Calls the Discover class constructor so that the peer will start to discover its peers by searching for pipe advertisements of other peers within the peer group.
     
     
  2. Starts a new thread to perform the remaining steps (3 to 9) in the background.
     
     
  3. Registers itself as a listener to be informed if the currently selected peer or peer group changes.
     
     
  4. Obtains the PeerGroup for the current peer group.
     
     
  5. Obtains the PipeService for the current peer group.
     
     
  6. Obtains the DiscoveryService for the current peer group.
     
     
  7. Calls the login method to publish the pipe advertisement.
     
     
  8. Calls the getPipePresence method to establish the user's presence within the current peer group and maintain the "buddy list" of pipe advertisements for other users.
     
     
  9. Enters a loop to wait for, and process, messages.
     This is achieved by calling the waitForMessage method in the net.jxta.impl.endpoint.EndpointReceiveQueue class, which is the JXTA reference implementation of a queuing mechanism. Whenever a message is available, the waitForMessage method returns it and it is then forwarded to the peer that this peer is chatting to (the target peer). This is achieved by calling the sendMessage method in the net.jxta.instantp2p.OnlineBuddy class. The message is sent down the output pipe for the target peer.
  
  
  
• login method which calls the runChatServer method to initiate a chat, as follows:
  
  
  1. Calls the findUser method to search for an existing pipe advertisement for the current peer. The findUser method attempts to find a user locally first, then tries searching the remote advertisements using the DiscoveryService. If no pipe advertisement is found, the runChatServer method creates a pipe advertisement for the input pipe.
     
     
  2. Publishes the pipe advertisement remotely.
     
     
  3. Calls the Pipe service to actually create the input pipe so that messages can be received on this pipe.
     
     
  4. Calls probeUser to add a user to the buddy list of known peers.
  
  
  
• sendMessageToPeers method which sends a message to a listening peer. The message is constructed and enqueued on the message queue so that the waitForMessage method (called in the run method) will return and the message will be forwarded to the target peer on the output pipe.
  The message is enqueued by calling the push method in the net.jxta.impl.endpoint.EndpointReceiveQueue class, which is the JXTA reference implementation of a queuing mechanism.
  
  
• startChat method which starts a chat when the end user selects a peer from the list displayed on the GUI.
  If the peer is already an active user (that is, an OnlineBuddy object exists for that peer), the information required for the chat already exists. Otherwise no one can chat with that peer, and so the probeUser method is called to add the peer to the buddy list.

The net.jxta.instantp2p.GroupChat class allows the user to perform a group chat with other peers in the current peer group, and every peer in the current peer group can join in the group chat.

From an implementation perspective, the GroupChat class is very similar to the Chat class. For example, the GUI panel looks very similar, and the constructor, login and run methods perform essentially the same functions as the corresponding methods in the Chat class. The group chat uses pipes and message queues in much the same way as the one-to-one chat.

There are a few minor differences. A group chat is not secure because it specifies a pipe type of PropagateType in order to propagate messages to multiple peers, as opposed to the pipe type of UnicastSecureType that is used by the one-to-one chat. However, as the net.jxta.pipe.PipeService class supports both types of pipe (and a third type, UnicastType, for an unsecure, unicast pipe), it minimizes the code differences within the chat classes.

Overall, myJXTA is suitable for use both as an Enterprise as well as an Internet-based peer-to-peer chat facility. The myJXTA application also serves as a good introduction to the JXTA platform. As well as providing a reasonably sophisticated chat facility, it also demonstrates how to use some of the services provided by the reference implementation of the JXTA platform, such as the pipe service.

Conclusion

These two articles introduce the concept of peer-to-peer computing and compare the facilities provided by JMS and JXTA technology when implementing a simple peer-to-peer chat application.

The JMSChat application demonstrates that JMS can be used to provide a simple form of peer-to-peer application. The peer-to-peer facilities are provided by an enterprise messaging system, so it is possible to implement only a centralized form of peer-to-peer application with JMS. Further, JMS is best suited for use within an enterprise as it does not provide certain functions that are necessary for Internet-based peer-to-peer exchange. For example, JMS does not define an interoperable wire format for the exchange of messages between enterprises, nor does it specify a router-router API. In particular, JMS does not specify security mechanisms under client control, and security is considered to be a JMS provider-specific feature.

Overall, JMS simplifies the development of message-based, enterprise applications. Although not explicitly designed for peer-to-peer networking, JMS may be an appropriate choice when implementing certain forms of peer-to-peer applications within an enterprise, particularly when the solution incorporates other J2EE features.

The myJXTA application demonstrates that you can use JXTA technology to provide a variety of peer-to-peer capabilities, not just the chat functions discussed in this article. Project JXTA takes a generic approach to peer-to-peer by defining a set of protocols that allow any device on the network to communicate and collaborate. JXTA technology also includes security features not addressed with JMS. For example, Project JXTA has a security module for the exchange of public keys among peers, and applications can plug in their own security components. JXTA technology provides broader functionality than JMS and is suitable for both Enterprise and Internet-based peer-to-peer as the JXTA core can provide peer connection through firewalls, NATs (Network Address Translators) and proxies. Although Project JXTA technology is still in the relatively early stages of development, the list of projects hosted on the Project JXTA web site demonstrates that JXTA technology is already being used to develop a wide variety of services and applications.

JXTA is developed as an open-source project, and all the source is available to community members on the Project JXTA web site. JXTA is fully leveraging the JXTA open-source community to review code, add new features and find and fix problems.

In conclusion, anyone interested in building and deploying interoperable, peer-to-peer services and applications across the Internet is encouraged to download the reference implementation of the JXTA platform and start investigating the various projects (applications, demos and services) that are hosted on the Project JXTA web site.

For more information

Project JXTA web site
JXTA resource web site
Project JXTA download area
Project JXTA Tutorials
Description of myJXTA code
J2EE
JMS
JMS Tutorial

About the Author

Alan Beecraft is a Software Engineer in the Sun Developer Network (SDN) group at Sun Microsystems.

Have a question about Java programming? Use Java Online Support.