Java IoT Authors: Pat Romanski, Elizabeth White, Liz McMillan, Yeshim Deniz, Mehdi Daoudi

Related Topics: Java IoT

Java IoT: Article

Java and the Future of Ad Hoc Networking

Java and the Future of Ad Hoc Networking

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.

Real-Time Java
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.

Crystal Ball
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.

More Stories By Karl McCabe

Karl McCabe is Chief Technology Officer at Rococo Software, a Dublin-based wireless Java company. McCabe 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.

Comments (3)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
DSR is a supplier of project management, consultancy services and IT solutions that increase effectiveness of a company's operations in the production sector. The company combines in-depth knowledge of international companies with expert knowledge utilising IT tools that support manufacturing and distribution processes. DSR ensures optimization and integration of internal processes which is necessary for companies to grow rapidly. The rapid growth is possible thanks, to specialized services an...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...