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>
Requirements and Test Management kit
IE 7
Firefox 2.0
