Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
This series of articles describes the role of Java 2 Micro Edition (J2ME) devices in Peer-to-Peer (P2P) computing. We will take JXTA (visit www.jxta.org for details) as an example P2P network and show why, when, and how to use J2ME as a JXTA peer.
In the first article of this series, we will describe how JXTA has defined the functionality and characteristics of a virtual network topology that can work over any existing network technology (such as IEEE 802.11-based LANs, and the IP-based Internet). We will then discuss the special features that JXTA has achieved by defining a virtual network overlay on top of existing technologies.
The next step will be to describe how to connect small J2ME devices with limited capability (processing, memory, screen size, and MMI restraints) to a JXTA network. We will conclude this article by summarizing what JXTA and J2ME offer to Java Wireless programmers.
Functional Equivalence Among Peers
Compare the computing capabilities of today’s PCs with Web hosting servers of the early 90s, when the Internet was just beginning. Most readers will agree that today’s PCs are powerful enough to act as Web servers and handle moderate traffic requirements. This was not the case with the PCs of just over a decade ago.
The humble computing power of early-day PCs led to the idea of having Web servers and browser clients. Web servers were supposed to be power machines, capable of serving many browser clients simultaneously. Browser clients, on the other hand, were meant to run inside personal computers such as Intel’s 386- or 486-based machines.
With Pentium processors—a common thing inside today’s PCs and laptops—it is about time we consider Functional Equivalence in distributed computing. There will be no clients and servers in this model. Every node in the network will be a Peer, functionally equivalent to all the other peers.
What keeps you from hosting your Web site from your laptop? Why not deploy content management system in your PC and manage your own data and meta-data yourself for search queries coming across the Internet? A functionally equivalent distributed computing model will distribute the current load on central servers. For example, if your PC or laptop can manage your content and respond to search queries, the processing load on Internet search engines like Google will surely decrease.
Moreover, today’s search engines cannot be expected to become experts in every field. Therefore, this way we can expect better search services and more precise search results, because professionals in every field will be able to design meta-data structures and data classification schemes for their own fields of expertise.
But unfortunately, the traditional client/server model has deep roots in the HTTP-over-TCP-over-IP-based Internet of today. Before we can consider using a functionally equivalent model over the Internet, we have to check out some technical restraints of hosing Internet resources in mobile devices such as laptops and PDAs.
Early Versus Late Bindings
What happens when you type the name of a Web site in your browser’s address field? The Web server address (HTTP URL) such as http://www.Yahoo.com is translated to an IP address such as 168.127.47.8 by a Domain Name Service. The Internet protocol then makes a routing decision based on the IP address. Because the desired Web page is permanently (or statically) bound to the IP address, the IP address will lead you to the desired Web page.
This type of permanent, long-term binding between an HTTP URL and its IP address is referred to as a static, or an early, binding.
Early bindings form a simple and logical architecture, very similar to the address book in your e-mail program like Outlook. You only need to remember the friendly names of your friends and acquaintances; the e-mail program automatically finds the name from the address book, reads the corresponding e-mail address from there, and sends the e-mail for you.
This works fine primarily because people normally have long-term (early) bindings with their e-mail addresses; in other words, they don’t change their e-mail addresses every day.
What would happen if one of your friends changes his e-mail address several times every week? Sure enough, the address book idea will not work unless you come up with some mechanism for updating your address book often enough to catch your friend every time he changes his e-mail address. These types of dynamic bindings are referred to as late bindings.
You might argue that none of your friends is dynamic enough to change his e-mail address ever week, so an early-bound address book will work fine for you. However, today’s networks really are this dynamic, and they do change their network bindings and topology so often that you can hardly rely on an early-bound addressing and routing scheme.
Perhaps the most significant reason for having dynamic and therefore unreliable network topologies is the explosive growth in the use of connected wireless devices such as laptops, PDAs, and cell phones. As a device moves from one network domain to another, the network topology is expected to change.
If the mobile wireless device relies entirely on the conventional client/server model, Web servers hosted on permanent (static) IP addresses, and on search services such as Yahoo and Google, there is no need for functional equivalence and P2P architecture. However, if the device user wants to make the most of the device capabilities, the solution is P2P computing and functional equivalence.
JXTA has defined a so-called virtual network overlay to hide the unreliability of highly dynamic networks. Let’s see how.
JXTA—A Virtual Network
JXTA defines several types of resources; for example, network nodes (peers), peer groups, communication channels, pieces of data, and so forth.
Every node in a JXTA network is a peer. Every peer connected to JXTA network should have a unique identity, called a Peer ID. The peer ID will be dynamically (late) bound to its IP or TCP address by the JXTA network.
A peer group is a logical rather than a physical entity; it is formed by the grouping of peers sharing common interests. For example, there can be groups, one each for all the different types of music, so that music lovers can join groups according to their taste to discuss and exchange songs.
Peers are identified by their IDs in a JXTA network. Therefore, a peer group has no concern over the IP address currently used by any of its group members. This effectively hides the unreliability associated with the dynamic behavior and changing topology of interconnected networks.
Just as with peer groups, JXTA communication channels (called pipes) are also logical entities. A pipe is formed by a virtual path between two communication end points. Every peer will have at least one end point, which will be dynamically bound to the IP address the peer is using.
JXTA Rendezvous Peers
To compensate for the absence of a central service (such as a domain name server), a JXTA network uses the concept of rendezvous peers. Rendezvous peers are volunteers that have agreed to act as a meeting point for other peers. Naturally, rendezvous peers need to maintain a permanent (static) IP address, so that other peers can contact them to check the current bindings of dynamically (late) bound peer end points.
Rendezvous peers may also keep a record of other rendezvous peers. Therefore, if you know a rendezvous point and your friend also knows a rendezvous point, and the two rendezvous points know each other (directly or through other rendezvous points), you and your friend can find and reach each other.
The JXTA protocol implementation takes care of all this. Applications do not have to worry about these low-level details. They will just send search messages to the rendezvous points they know and the network will do what’s necessary by itself.
Note: It is natural to expect that more time will be needed to reach your friend if there are a lot of rendezvous points in between.
Advertisements and Search Messages
JXTA peers come to know about resources available (music peer groups, songs available for exchange, and so forth) through advertisements. JXTA advertisements are XML messages meant to publish the availability of specific resources.
We don’t intend to cover the details of JXTA XML formats in this article. However, to give the readers an idea about what JXTA advertisements look like, we have included an XML file in Listing 1, which is an advertisement for a pipe.
Listing 1—A Simple Pipe Advertisement
<?xml version="1.0"?><!DOCTYPE jxta:PipeAdvertisement><jxta:PipeAdvertisement xmlns_jxta="http://jxta.org"> <Id>A unique ID</Id> <Type>Type of the pipe e.g. Unicast or multicast</Type> <Name>Name of the pipe</Name></jxta:PipeAdvertisement>
Searching for Resources on a JXTA Network
JXTA search messages are also XML messages sent over the network. The JXTA search model is very different from popular Internet search services such as Google. There is neither a central search engine nor a central data repository anywhere over a JXTA network. Everything is distributed in the real sense, which means when a peer wants to search for some specific resource (perhaps his favorite star’s latest album), he will send a search message to the peers that he knows. A peer receiving the message will match the search criteria with resources under his or her control (for example, songs that he or she wants to share) or advertisements published by some other peer (such as an advertisement saying that the required song is available with a peer having a certain ID). If a match is found, the peer might want to respond with the details of successful search results.
If the receiving peer does not find a match, he will simply propagate the search message to other peers.
JXTA also defines a mechanism to kill messages after a certain time or after traveling a certain number of hops; otherwise, they will keep on traveling forever and ever.
J2ME as a JXTA Peer
Java 2 Micro Edition (J2ME) is a stripped-down version of Java, suitable for small devices with limited capabilities, such as cell phones. J2ME devices are expected to have limited capability. While considering J2ME as a JXTA peer, we need to consider the following important limitations of J2ME devices:
- J2ME does not have any XML processing API/classes. Therefore, JXTA’s XML processing requirements will be a bit tricky to manage. Third-party XML processing engines such as kXML (www.kXML.org) are available and can be used for XML processing in JXTA applications. However, it will be an application overhead, perhaps occupying too much of the device’s memory and processing time, not leaving enough memory for other processing requirements. It is reasonable to assume that J2ME will need to act as a JXTA peer without any XML assistance.
- J2ME only has an HTTP client and does not have an HTTP server. This means a J2ME device can only send HTTP requests but cannot open ports to listen for and receive incoming HTTP requests.
JXTA4J2ME
JXTA4J2ME is an API meant to connect J2ME devices to JXTA networks, while keeping in mind the above-mentioned technical restraints. We will now describe how JXTA4J2ME works.
To connect J2ME devices to JXTA networks, while living within the constraints mentioned above, JXTA4J2ME project designers decided to take some of the load off a J2ME-based JXTA application. JXTA4J2ME peers are given a reduced functionality as compared to a desktop peer, to match the capabilities of a J2ME device.
A J2ME-based JXTA peer only talks to a JXTA Relay (a message relaying peer), which in turn bears most of the message processing (such as XML authoring for advertisements, sending search messages across the JXTA network, and so forth) and relaying burden. A J2ME-based peer, together with a JXTA relay, is functionally equivalent to a normal JXTA peer. Therefore, a J2ME peer will act as an edge device, setting on the perimeter of a JXTA network.
Coordination between J2ME Edge Devices and JXTA Relays
Figure 1 illustrates how JXTA relays help J2ME-based edge devices interact with a JXTA network.
A J2ME peer will send HTTP request messages to a JXTA relay. The message will contain one or more Elements, where each element is composed of name-value pairs traveling as part of the HTTP request headers.
On receipt of an HTTP request from a J2ME peer, the JXTA relay will parse each name-value pair in the HTTP request, author XML messages according to the JXTA format, and relay the messages over the JXTA network.
When a JXTA relay receives a message from the JXTA network, and is destined for a J2ME peer, it will parse the XML format of the incoming message and author a corresponding HTTP response. However, a JXTA relay has no means to send the HTTP response back to the J2ME peer (recall that J2ME devices do not have HTTP server-side functionality, so they cannot open ports to listen to incoming request messages).
Therefore, a JXTA relay will wait for the J2ME peer to send an HTTP poll request and ask for a message in response to a previously sent request. When this happens, the JXTA relay will send the HTTP response back to the J2ME peer.
Naturally, we need a mechanism inside a J2ME peer that will keep on polling the JXTA relay for incoming messages.
The JXTA4J2ME implementation hides all this functionality from application developers, who only need to understand the architecture of this communication and are not required to know the implementation details.
JXTA4J2ME Classes
There are three classes in a JXTA4J2ME implementation:
- The PeerNetwork class handles connection to JXTA relays.
- The Element class handles the authoring and parsing of individual elements (essentially name-value pairs) of a JXTA message.
- The Message class handles the authoring and parsing of complete messages. This is essentially the task of putting the Element instances together into a Message object.
A single J2ME peer can maintain relationships with any number of JXTA relays. At the moment, the JXTA4J2ME implementation does not provide any mechanism to search for available JXTA relays. Therefore, an JXTA application making use of JXTA4J2ME implementation will need to know the address of a JXTA relay through some other means.
We can anticipate that some future JXTA4J2ME implementation will provide a means to automatically locate the available JXTA relays.
Conclusion: A Promise to the Wireless Java Programmer
Why does a Wireless Java developer need to use JXTA4J2ME? We can conclude the following points from this article:
- J2ME peers can act as edge devices in a JXTA network.
- By coordinating with JXTA relays, a J2ME peer can establish communication channels with desktop or other J2ME peers, join JXTA peer groups, search for specific resources over the network, and perform all other tasks that a normal desktop peer can perform.
- As long as a J2ME peer is able to maintain communication with one or more JXTA relays, the J2ME peer remains part of a virtual network that is independent from network topology. The mobile user carrying your JXTA4J2ME application can roam throughout the world; you don’t have to worry about the ever-changing network state. J2ME application developers can rely on the JXTA network to create value-added messaging applications such as games, wireless connectivity for workflow solutions, and so on.
- JXTA4J2ME hides all low-level implementation details (such as dealing with data formats and HTTP-specific issues) from application developers. High-level Wireless application developers can focus on their business logic and let JXTA4J2ME handle the nuts and bolts.
Next Time: The next article in this series will take this concept further and explain the details of designing wireless messaging applications using JXTA and J2ME.
Resources:
- 1. Visit the birthplace of JXTA.
2. Download the JXTA4J2ME documents and source code from http://jxme.jxta.org/servlets/ProjectHome
3. J2MEs official web site contains the latest on whats happening on this front.
4. Li, Sing “Early Adopter JXTA”. A good book on JXTA by Wrox.
5. Making P2P interoperable: The JXTA story. An article that describes the core building blocks of JXTA.
About the Author:
Bilal Siddiqui is an Electronics Engineer, an XML consultant, and theco-founder of WaxSys, a company focused on simplifying e-Business. Aftergraduating in Electronics Engineering from the University of Engineering andTechnology, Lahore, in 1995, he began designing software solutions forindustrial control systems. Later he turned to XML and used his experienceprogramming in C++ to build Web- and WAP-based XML processing tools,server-side parsing solutions, and service applications. He is a technologyevangelist and a frequently published technical author. Bilal has also contributed to a couple of books, namely Java P2P Unleashed and Web Services Business Strategies and Architectures. Readers may contact Bilal at bsiddiqui@waxsys.com.
