JXTA-A Messaging System for Wireless Java
In the first article of this series, we discussed JXTA, J2ME, and the way these two technologies cooperate with each other. We briefly introduced the JXTA architecture and the idea of J2ME devices acting as JXTA edge peers. We concluded by summarizing what this combination of technologies offers to a Java developer.
This article will take the concept further and explain how J2ME devices will use the services and features offered by JXTA to become part of a heterogeneous messaging system consisting of desktops, PDAs, cell phones, and other devices.
We will start by presenting the basic requirements and characteristics of a messaging architecture. We then will demonstrate how Java caters to messaging requirements. We will also show how JXTA4J2ME implementation provides a simple and easy to use high-level interface for messaging application developers.
To elaborate the basic features of messaging, let us consider a common, real-life scenario. Imagine how people talk to each other, either face to face or on the phone.
In this type of live conversation, when one person is talking, the other person is supposed to be listening (and not doing something else) and when one stops talking, the other person is supposed to say something, almost immediately, in response.
Therefore, a telephonic or face to face conversation is real time and synchronized in the sense that each person expects an almost immediate response from the other end. While talking on phone, you cannot delay your response even for a few minutes.
This inherent notion of engaging the two parties in real time is referred to as synchronous communication. Web browsing is also synchronous in nature, just like telephonic conversation. You click on a link and expect the Web server to respond almost immediately, thus engaging the Web browser and the server in real time, at least temporarily.
Now compare this with the dialog that takes place through an exchange of letters or e-mail. What happens when you check your mail in the morning? Normally, you would sort and prioritize incoming mail, write immediate replies to urgent ones, and defer the ones less urgent or less important. A significant characteristic of this type of dialog is that the two communicating parties are hardly ever engaged in real time. When one person is writing an e-mail, the intended recipient is doing something else. Similarly, when the recipient is preparing the response, the sender is busy elsewhere.
We refer to this communication mechanism as asynchronous communication. Messaging systems rely on asynchronous communication. When we talk about messaging, we are actually referring to communication thats occur without ever engaging the communicating parties in real time. This is the biggest fundamental difference between Web browsing and messaging.
It's very logical to conclude that messaging is much more flexible than synchronous communication. You might have read auto-response e-mails from busy professionals and business executives saying something like "Thanks for your e-mail. I will get back to you as soon as possible. If you need my urgent attention, you can reach me at the phone number given below, but rest assured YOU WILL GET A BETTER RESPONSE BY E-MAIL". This is a direct result of the inherent flexibility of asynchronous communication; it allows all concerned parties to act according to their own priorities and convenience.
The same is true about the software components of server side e-commerce solutions (for example, Web Service components). It is easier to build flexible e-commerce solutions using the messaging style of communication rather than using simple client/server synchronous messaging.
Let's see how Java caters to messaging requirements.
Messaging Architecture in Enterprise Java
Java 2 Enterprise Edition (J2EE) version 1.3 includes a messaging API called Java Messaging Service (JMS). Enterprise Java developers can use JMS to build messaging applications that are portable across the different J2EE implementations.
JMS uses the concept of clients and providers. Any messaging application that uses the JMS API is called a JMS client. A JMS provider, on the other hand, is the implementation of the JMS API that will handle all the messaging nuts and bolts needed by a JMS client.
Logically, there are two types of messaging clients: message producers and message consumers. Message producers will author (create or produce) messages, which consumers will receive (consume). A JMS client application will normally have the capability to act both as a message producer and a consumer.
JMS clients (producers and consumers) can use two styles of messaging to communicate with each other through JMS: point-to-point and publishing/subscribing.
Point-to-point messaging is employed when the exchange of messages simply occurs between two communicating parties. A message producer will send messages to a message queue. The queue is the place where the intended recipient (message consumer) will look for his incoming messages.
On the other hand, the publishing/subscribing style of messaging is like a broadcast and is based on topics. A message producer will post his message to a topic. Message consumers who have interest in that topic will subscribe to it to receive all messages posted to that topic.
A JMS provider is responsible for administering queues and topics. A JMS client application does not have to cater to the low-level details (such as how to store/maintain the list of topics and the list of subscribers to each topic) and will simply call methods of the JMS API to utilize the services of a JMS provider.
We do not want to go further into the details of JMS architecture and therefore we have included a link to a collection of articles on JMS in the resources section at the end of this article. Curious readers may follow the link to get complete details of the JMS API.
The point here is that JMS provides comprehensive features that can be used to build reliable messaging applications. However, a JMS provider implementation is a heavy-weight component. It is interesting to note that a J2ME device is too humble in capabilities to host a JMS provider.
So, what if you want to use a J2ME device to act as a JMS client?
A natural solution is to distribute the JMS provider functionality in such a way that only a skeleton high-level abstraction is necessary to be hosted inside the J2ME device. This will leave the heavy lifting for some server that will host the JMS provider. However, doing this will raise the issue of how to connect a mobile wireless device to the server.
Recall what we discussed about early versus late bindings in part 1 of this series of articles. It is not possible to use a simple early-bound mechanism to connect to mobile wireless devices that keep on changing their network bindings.
JXTA4J2ME: A Messaging Solution
Well, JXTA4J2ME is the perfect solution to this problem. Following is a point-wise analysis to support our claim:
- liJXTA4J2ME provides a skeleton, small-footprint API, suitable to be hosted in a J2ME device. JXTA4J2ME can connect to JXTA relays. The relay provides all heavy lifting functionality, such as XML authoring and processing.
- The JXTA virtual network overlay solves the problems associated with early bindings. The JXTA4J2ME peer only needs to connect to ANY relay (that is in turn connected to the JXTA network of rendezvous peers) and the network will automatically adjust itself to the changes in network topology.
- The JXTA set of protocols provides both types of messaging features that we discussed above (point-to-point and publishing/subscribing). For example, a JXTA unicast pipe connects two end points for a simple point-to-point message exchange. On the other hand, a JXTA propagate pipe is used to accomplish broadcasting of messages to all interested peers. Moreover, the act of joining a peer group is inherently similar to subscribing to a JMS topic.