In the dense forest of emerging computing trends, technologies, and hyped life-changing applications, there are two developments that stand taller than the rest. In isolation, these two trends are having a huge impact on users - both individuals and corporations. However, there is rich potential at the intersection of these two developments for a significant step forward in the way we use and implement computing devices and applications. These two trends are the ubiquity of mobile personal computing devices and the emergence of peer-to-peer computing architectures.
The proliferation of mobile computing devices hardly needs further documentation here - we're all aware of the sheer volume of mobile phones, PDAs, mobile pagers, and other assorted gadgetry that exists in the world. We watched as each "must-have" feature queued up to gain user acceptance. Some succeeded (SMS, e-mail pagers), some didn't (WAP, satellite phones), and for others the marketing guns are still firing in the battle for consumers (MMS, always-on networks, PDA phones). One thing is clear - devices with real computing power proliferate and are carried around by regular people. A top-of-the-range HP iPAQ (formerly Compaq iPAQ) PDA has 64MB of RAM and a 400MHz processor. This kind of hardware specification was typical for a PC purchased around the holiday season in 1999!
The emergence of peer-to-peer computing architectures has also been extensively documented. Systems such as Napster helped bring attention to the power of networks in which every node is a first-class citizen. This approach - building resilient, truly distributed systems that make effective use of processing power - is an excellent technical solution to difficult problems. More important, it can enable a genuinely new approach to application interaction. The mechanisms for discovering other nodes in a network, for interrogating those nodes to find out what services they provide, and for connecting to and using those services can all be revolutionized. The implications are far reaching, as evidenced by the visceral reaction of the music recording industry to Napster, et al.
The Java platform has an increasingly important role to play in many computing fields, not least of which is the field of distributed computing. In this article, I examine why ad hoc networks will be the key distributed systems paradigm in the near future - why they are in fact the first true distributed systems - and what role Java, particularly J2ME, will play in this new paradigm.
Why Is Ad Hoc Networking Useful?
Ad hoc networking can be defined as follows: a network formed without any central administration, and whose nodes can dynamically, arbitrarily, and continually connect and disconnect.
The single most important aspect of an ad hoc network is the absence of a central administration. This is more unusual than it sounds in a computing landscape dominated by servers - print, file, DNS, DHCP, application, Web, and so on. Taking the step to remove the central administration is both liberating and problematic. It gives us the freedom to create peer-to-peer networks on an ad hoc basis without the need for access points, base stations, or other infrastructure. On the other hand, we can no longer rely, for example, on central authorities to certify digital certificates - we must rely on some other mechanism to establish trust in an ad hoc network.
Our definition also points to other key aspects of ad hoc networks. The nodes must be able to connect dynamically - a network is not preformed and nodes can join and leave at any time. The nodes can connect arbitrarily to a network - that is, a node should not need (excessive) preconfiguration in order to take part in a network. Perhaps I'd like my PDA to form an ad hoc network with others that I meet at a conference.
Finally, ad hoc network nodes can continually connect and disconnect to and from a network - this is a natural thing for this network topology, and not an exceptional or error condition as is often the case in more sessile networks. Ad hoc network nodes are frequently mobile.
In addition to authentication, two other technical problems are accentuated in ad hoc networks - the "finding stuff" problem and routing. In any distributed system, a node needs to find another node that can provide some useful service to it. This is the "finding stuff" problem and it's usually solved with servers - DNS servers allow us to find Internet nodes using a friendly name; UDDI servers act as a Web-based repository of services. Without servers - i.e., in an ad hoc network - this problem is amplified. Likewise, routing information through an ad hoc network, particularly one consisting of mobile nodes, is a difficult problem. A node that's acting as a router might disconnect from the network at any time (it may go out of range). How does a network self-heal and allow seamless continuance of service in this scenario? Solving these challenges could yield a powerful and flexible network topology, a true distributed system.
There are many benefits that could accrue from such a distributed system. We could build networks more cheaply, because we don't need expensive server infrastructure. We could build networks that are more resilient. If each node acts as a peer, the network can heal as nodes drop out, thus providing increased quality of service. For users, simple ad hoc networks can form between their own personal devices - the so-called Personal Area Network (PAN) - or with nearby devices, and services may be accessed without a central infrastructure. I could share photos with a friend's device, pay for something in a vending machine using my phone, or buy a new stereo and have my universal remote connect automatically to it and configure it.
Ad Hoc Networking Technologies
Many physical networking technologies may be used to underpin an ad hoc network, though some are more suitable than others. Since nodes are frequently mobile, a wireless physical transport makes sense.
The wireless LAN technologies defined by the various IEEE 802.11 standards, also known as WiFi, are quickly becoming pervasive. The key protocols are 802.11b and 802.11a. The former operates in the Industrial, Scientific, and Medical (ISM) frequency band around 2.4GHz and delivers a transmission rate of 11Mbps. 802.11a gives a much higher data rate of 54Mbps and operates in the 5GHz band. In the second half of 2002, the vast majority of wireless LAN products on the market use the 802.11b standard. 802.11 slots neatly into the IEEE family of protocols as an alternative Media Access Control (MAC) layer; this means that things that work over Ethernet, such as TCP/IP, work with 802.11. This provides a reasonably seamless transition for existing applications and operating systems that need to "go wireless."
802.11 can operate either in Infrastructure Mode or Ad Hoc Mode. In the former, wireless nodes connect to a network through a WiFi access point, whereas in the latter, nodes may connect directly to each other without the need for an access point. Despite this, there are some aspects of 802.11 that detract from its suitability as an ad hoc networking technology.
As mentioned earlier, 802.11 is simply an alternative MAC layer for use over radio rather than wires. This benefit is in some ways a disadvantage though, since 802.11 networks tend to be just as ad hoc as fixed wired networks. Most of the protocols and applications that run over 802.11 networks are the same as those that run over wired Ethernet networks and are not particularly ad hoc (advances, such as Mobile IP, may improve this situation). Other downsides to 802.11 as an ad hoc networking technology include its relatively high-power consumption (a concern for small mobile devices, though less so for laptops) and the security problems that are beginning to be widely exploited. The 802.11 Wired Equivalent Privacy (WEP) security protocol has been largely discredited and does not provide adequate security. This may be a problem for ad hoc networks where "rogue" nodes may be within range. New developments, such as 802.1x and 802.11i, will address these issues.
The Bluetooth wireless standard, controlled by the Bluetooth SIG, also operates in the ISM frequency band. It's much less power hungry than WiFi, but it delivers a much lower transmission rate at 760Kbps. It was designed as a cable replacement technology and this is still its strongest role. However, it has certain characteristics that are ideal for ad hoc networking. Bluetooth supports device inquiry as a native feature, allowing a Bluetooth device to automatically discover other Bluetooth devices that are in range. This property makes Bluetooth well suited to self-healing networks or to systems containing nodes that want to detect and join networks in an ad hoc manner. Having discovered which devices are nearby, a Bluetooth application may then query the services that are supported by those devices. Using the Bluetooth Service Discovery Protocol, an application can search and browse the services provided by a remote device and query attributes about those services. These attributes can be used by the Bluetooth device to choose a suitable peer device and to configure itself to join the network.
Other physical transports worthy of mention here include Ultra Wideband (UWB) and proprietary protocols such as that used by Cybiko. UWB is inherently secure, requires very low power, and can achieve data rates up to 60Mbps. In February 2002, the Federal Communications Commission in the U.S. approved the commercial deployment of UWB (with limitations), and early development kits are now appearing. Cybiko is a wireless entertainment device aimed at young people and it supports multiplayer games, e-mail, messaging, etc. It's interesting from a technology perspective because it supports ad hoc routing. A device can communicate within another device that is out of range, as long as there's a path through one or more intermediate devices. This is a form of "mesh networking" for a specific problem domain - a topology that I'll return to later.
Using Java to Build Ad Hoc Networks
There are a number of Java standards that are particularly relevant to the emerging ad hoc networking topology. The Java API for Bluetooth Wireless Technology (JABWT) is crucial since it maps Java software constructs onto physical ad hoc constructs. JXTA, Jini, and JavaSpaces are good examples of software frameworks that have a good architectural fit with ad hoc networks. Finally, I'll examine the new Real-Time Specification for Java - a key step in the proliferation of Java, and its success in new networking topologies.
The Bluetooth specification is not an application programming interface (API)-based specification. Instead, it standardizes a set of protocol stack layers in such a way that the Protocol Data Units (PDUs) passed between stack layers and across the air are well defined and interoperable. This is perfectly appropriate for a wireless technology specification.
There are many implementations of the Bluetooth specification, or Bluetooth Stacks, available. Each of these stacks by necessity has its own proprietary API - usually a "C" API. An unfortunate side effect is the complexity involved in writing applications that use Bluetooth technology. A programmer's time will usually be taken up mastering the idiosyncrasies of the underlying Bluetooth stack API, figuring out how to initialize it, configure it, and coax it into providing the desired behavior. Some of the more mature commercial stacks provide some abstractions that aid usability, but these remain proprietary. The Java APIs for Bluetooth Wireless Technology (JABWT) for the first time provides a standard API for programming Bluetooth applications. Better still, this is a Java standard developed by the JSR-82 Expert Group. Motorola chaired this group, which also included Rococo Software, IBM, Nokia, and Ericsson. JABWT is an optional package layered on top of J2ME CLDC. Its current version is 1.0a, ratified in March 2002.
The JABWT APIs provide a number of key abstractions that simplify the tasks involved in building a Bluetooth application. In particular, they allow an application developer to initialize a stack, populate and read a service discovery database, perform device discovery, manage L2CAP and RFCOMM connections, manage Bluetooth security, and exchange OBEX data as efficiently and simply as possible. To achieve this, JABWT uses well-understood and widely used Java concepts, such as Listener classes for receiving asynchronous events and Universal Resource Locators (URLs) for identifying connection endpoints. The Input/Output (I/O) mechanism of the CLDC Generic Connection Framework (GCF) is extended by JABWT to include Bluetooth connection classes - RFCOMMConnection and L2CAPConnection. Since this is a standard networking framework used by all J2ME applications, programmers can quickly produce Java Bluetooth applications by applying existing techniques and design patterns.
This new standard is hugely important to the success of ad hoc networking. For the first time, it bridges the gap between a physical ad hoc technology, such as Bluetooth, and the richer, higher-level software frameworks provided by Java. It opens up the physical ad hoc capabilities of the new generation of mobile devices to the creative energies of the Java development community.
JXTA (pronounced "juxta" from "juxtapose") was launched by Sun in April 2001. It's a programming and computing platform designed to solve a number of problems in the area of peer-to-peer networking. Peer-to-peer networking is essentially another name for ad hoc networking. It's a networking topology whereby end-user devices are connected directly to other end-user devices, without going through a third-party "server," for the purposes of sharing some information or services. When we talk about peer-to-peer, we usually don't expect the nodes to be mobile. Although many such networks have emerged, no interoperable, platform-independent platform has existed on which to build these collaborative applications.
JXTA is such a platform. It's an open-source technology that addresses such issues as peer discovery, peer information sharing, peer membership, and asynchronous pipes. It proposes an XML-based approach to advertising peer resources. JXTA is neutral to the underlying transport, though it seems clear that short-range wireless technologies such as Bluetooth could play a key role in its success. A device using JXTA over Bluetooth could discover other local JXTA devices and form ad hoc, peer-to-peer networks with them to achieve some common collaborative goal, or share information or services. The next year is likely to be critical in the evolution of the JXTA framework - it will be important that the technology starts to find its way into some real peer-to-peer solutions. Until then, the jury is out.
Jini and JavaSpaces
Jini, officially launched in mid-2000, is a technology that may be used to federate groups of users and resources required by those users. It aims to allow a network to be more flexible and more easily administered, with resources being easily located by humans and computational clients. Jini provides framework components for managing federated services, such as a lookup service for locating services, a leasing capability for controlling use of services and security, and transaction capabilities for coherent interservice interactions.
Jini operates at a level of abstraction that makes it attractive to application developers who need to solve an application problem, rather than worry about underlying networking issues. It provides a paradigm that may be useful to Bluetooth applications, since it allows services to be loosely coupled, that is, Jini nodes and services may appear and disappear from a network as a natural consequence of its operation. This loose coupling of entities is an important quality in a mobile ad hoc network.
JavaSpaces is a Jini service. It provides the abstraction of a JavaSpace into which components known as "entries" can be put. An application may "find" these entries, it can "read" (passive) or "take" (destructive) entries, and it may write entries to a space. The JavaSpaces architecture includes a notification mechanism that notifies an application when an entry is written that matches some criteria. This form of abstraction is particularly useful for passing information from stage to stage in a workflow model, or for applications where redemption of some token is important - for example, redeeming a voucher with a service provider. Interestingly, JavaSpaces also provides a useful abstraction for layering over actual physical spaces. In a Bluetooth access point scenario, this may be useful as an application model for mapping zones or spaces in which access points are installed, and for specifying which services are available in which zones.
Both Jini and JavaSpaces are good examples of creative and elegant designs for Java software frameworks that are intended to provide rich abstractions to application programmers. They have characteristics that make them well suited to ad hoc networking applications - particularly the inherently loose coupling of objects. They're not without their drawbacks, though, as I'll examine shortly.
The Real-Time Specification for Java was developed under the Java Community Process and was released in January 2002. It defines a set of extensions to the Java Language Specification, the Java Virtual Machine Specification, and an API that enables the "creation, verification, analysis, execution, and management of Java threads whose correctness conditions include timeliness constraints (also known as real-time threads)." The specification defines an environment that retains the key portability and memory management benefits of Java, while emphasizing predictable execution as the top priority. This specification is an important development in the ongoing effort to encourage the proliferation of Java technology.
A recent article by Jim Turley, "Embedded Processors by the Numbers" (Embedded Systems Programming, Vol. 12, No. 5), claimed that if you round off the fractions, embedded systems consume 100% of the worldwide production of microprocessors. Given the number of processors in the average home (household appliances, remote controls, stereo equipment, games consoles) and car, this claim is probably reasonable. If two such devices need to form a network to share a service, an ad hoc network may result - for example, a universal remote control might "discover" the new TV you just bought and allow you to control it remotely. If Java is to be a credible platform for ad hoc networking, it's imperative that it can migrate onto embedded microprocessors. The importance of the new Real-Time Specification for Java is clear in this context.
Java Lip Service
For Java to be a credible platform for building ad hoc networking applications, it needs to jump a number of technical hurdles. For starters, Java needs to work on small devices. This has been comprehensively addressed by now, of course, as evidenced by the widespread deployment of mobile Java by companies such as Siemens, Motorola, Aplix, RIM, and Sharp. As an aside, there's a significant danger of the mobile Java standards fragmenting due to proprietary additions being made by various vendors. This has been driven by market necessity - the Java Community Process has struggled to keep pace with the shortened design cycle of modern gadgets. New standards, like MIDP 2.0, and "oversight" groups, such as the JSR-185 Expert Group, should help to address this problem (JSR-185 EG is tasked with providing an architectural description, reference implementation, and compatibility framework for "Java Technology for the Wireless Industry").
For ad hoc networking, though, it's not enough to be small. There are certain things that it's hard to live without when building full-featured distributed systems - Remote Method Invocation (RMI) and the Java Native Interface (JNI), both missing from J2ME's Connected Limited Device Configuration (CLDC), are chief among these. The absence of RMI is explained by the memory constraints of CLDC, which is reasonable. The downside is that "traditional" (i.e., non-Web service) applications involving rich object interaction are difficult to build; HTTP is not always a suitable transport for this type of application.
The absence of RMI has another impact that is perhaps less forgivable - Jini depends on RMI. Jini doesn't work with CLDC. This is a pity, since CLDC devices are exactly the kind of devices that could benefit from Jini's lookup architecture and code mobility. I'd like my mobile phone to be able to discover the nearest printer, query it to get a print driver, and then print my phone list or WAP page. If my phone runs CLDC, this isn't possible (though companies like Psinaptic are working to change that). Sun Microsystems are now positioning Jini as an architecture for building network-centric services, moving away from the promise of Jini in gadgets.
The omission of JNI from J2ME CLDC does not have the same direct impact on J2ME application programmers. The reason for its absence is, again, sensible. The CLDC security sandbox model requires that "the set of native functions accessible to the virtual machine is closed, meaning that the application programmer cannot download any new libraries containing native functionality or access any native functions that are not part of the Java libraries provided by CLDC, profiles, or manufacturer-specific classes" (from the CLDC specification). The implication of this for developers, though, is that they cannot access underlying native protocol stacks, such as Bluetooth, from Java. A developer may want to do this in order to access features that are integral to ad hoc networks - for example, to discover nearby Bluetooth devices and what service they provide.
The future of ad hoc networking is likely to be determined by the emergence of compelling use-cases. If ad hoc networking leads to faster, cheaper, or easier ways of carrying out tasks, or if it leads to new revenue opportunities for companies, then it will succeed as a topology.
Mesh networking seems well placed to satisfy some of these criteria. A mesh network is one in which every node may act as a router and repeater for every other node in the network. Taking this seemingly simple step allows true ad hoc networks to form wherever there are sufficient nodes. No infrastructure is required - the nodes are the infrastructure. In a busy urban environment, voice and data traffic could be routed from one device to another, even if those devices were not in range of each other, by hopping from device to device. This approach will probably either revolutionize the way networks work, or it will be buried by the infrastructural vested interests, such as wireless voice and data carrier companies.
Another development to watch is the likely spread of "residential gateways." Companies that already have equipment in consumers' homes - such as set-top-box manufacturers - are planning ways to extend the reach of functionality of such equipment. One way to do this is to allow set-top boxes to establish ad hoc networks with other equipment in the house (entertainment equipment, phones, children's toys, universal remotes, PCs, etc.). An ad hoc network that includes a set-top box connected to a high-bandwidth connection provides rich potential for new application types. Java will play an important role in this development, as it is central to emerging standards in the Digital TV area such as the Multimedia Home Platform (MHP) and the Open Cable Applications Platform (OCAP).
These developments and others that are beyond the scope of this article, such as JavaCard and OSGi , are pushing computer networking in new and exciting directions. Decentralized topologies are sure to be at the forefront and ad hoc networks built on Java infrastructure and running Java applications can play a crucial role.
Karl McCabe is chief technology officer at Rococo Software, a Dublin-based wireless Java company. Karl was formerly responsible for the development of the Java product line at IONA Technologies and he has worked in various technical roles at IONA and ICL. He has helped to build and deploy distributed systems for many Fortune 500 companies, and his current interest is in extending the reach of these systems out to mobile devices.