February 27, 2021
Hot Topics:

JXTA for Wireless Java Programmers

  • By Bilal Siddiqui
  • Send Email »
  • More Articles »

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:

  1. 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.

  2. 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 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.

Click here for a larger image.

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:

  1. The PeerNetwork class handles connection to JXTA relays.
  2. The Element class handles the authoring and parsing of individual elements (essentially name-value pairs) of a JXTA message.
  3. 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:

  1. J2ME peers can act as edge devices in a JXTA network.

  2. 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.

  3. 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.

  4. 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.


    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.

Page 2 of 2

This article was originally published on September 16, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date