The Jini Technology Vision

Print-friendly Version

Articles Index Technology and the K Virtual Machine By Michael Deleo September 1999 This article describes a demonstration featuring 3Com Palm Pilots, Lego Mindstorm miniature tanks, and Jini technology presented at this year's JavaOne Developer Conference. This article explores some of the challenges solved by the demonstration developers with Jini technology and the K Virtual Machine (KVM). Computing technology has undergone dramatic changes over the past 35 years. Computers are smaller, faster, and more energy efficient. The power that once required a mainframe or minicomputer housed in a frigid, air-conditioned computer room is now contained in a small, consumer device you can carry in your shirt pocket. Such devices are finding their way into our everyday lives. As they do so, they contain increasing amounts of important, personal information. Small portable devices offer many benefits to users, but they present a new set of difficulties for developers. One difficulty is connecting these devices into a network. Small consumer devices demand a flexible, resilient networking architecture so that users can do things like use personal digital assistants to exchange information with existing networks and other computers. For the developer, the most noticeable difficulty is the scarcity of resources inherent in tiny consumer devices. Produced by the thousands (or even millions), these devices usually use low-cost, low-performance processors with minimal memory. Although this slimmed-down hardware translates into lower unit cost for the manufacturer and eventually the consumer, it ultimately puts the squeeze on the software developer. It forces the developer to write applications in languages such as C or assembler that will generate small, efficient programs. Unfortunately, "writing close to the hardware" means these applications have a lot of implementation dependencies. Application portability, code reuse, and, ultimately, the developer suffer. The K virtual machine (KVM) used with Jini connection technology provides excellent solutions to these problems. Jini technology provides a flexible, resilient network architecture to easily link together small computer devices onto a network. And KVM provides a Java

runtime environment tailor-made for small devices, making application portability and code reuse possible. This article presents the use of Jini technology and the KVM in a simple and concise manner. However, to understand the technical aspects of the article, you should be reasonably comfortable with the following technologies:

Java programming and debugging Network programming using sockets Java Remote Method Invocation (RMI)

You should also understand the C programming language at a basic level. Jini Connection Technology Jini Connection Technology provides networking mechanisms that let devices connect to one another to form an impromptu community -- a community that puts itself together without any planning, installation, or human intervention. Each device provides services that other devices in the community may use, in addition to its own interface. A service can be implemented anywhere in the community. Reliability and compatibility are ensured because each service provides everything needed to interact with it. K Virtual Machine The K virtual machine (KVM) is an entirely new Java runtime environment. Built from the ground up, it provides an extremely lean implementation of the Java virtual machine1 for devices with a small memory footprint. The core of the Java 2 Micro Edition (J2ME), the KVM works for 16/32-bit RISC/CISC microcontrollers with a miniscule total memory: a few hundred kilobytes at most; sometimes fewer than 128 Kbytes of RAM.

KVM and Jini Technology in Action

In his keynote speech to attendees at this year's JavaOne Developer Conference, James Gosling presented several Java technology demonstrations including a Jini Technology Tank Demo. In this demo, players using 3Com Palm Pilots played a robotic game of laser tag with remotely controlled miniature tanks built from a Lego Mindstorms Robotics Invention kit. The Palm Pilots and tanks were connected into an impromptu network using Jini connection technology. A simple Java applet executing in the Palm Pilots' KVM lets players maneuver their own tanks around obstacles, tag another tank, and move their tanks out of harm's way. Sounds like fun. But the demonstration represents many real world possibilities, especially applications that employ hand-held and other embedded devices, with different networking requirements. This article describes several of the more complicated technical challenges involved in building the demonstration. Each of the involved technologies and its use is explained. Where appropriate, Java source code samples are provided. The objective is to

show how Jini technology and KVM were used to handle this particular project. Another objective is to show their possible uses in developing and deploying applications for small consumer devices connected to a network.

Architectural Overview
Now for a look at the components that were used in the demonstration. The Hardware Network The diagram illustrates a network that includes Lego Mindstorms tanks, Palm Pilots, workstations, and other hardware components.

The workstation communicates with the tanks by infrared (IR) transmission. The workstation is connected to a device called an IR tower, which contains an IR transceiver. Each tank also has an IR transceiver, and each Palm Pilot sits in a HotSync cradle. A serial cable attached to the cradle connects a Palm Pilot to a terminal concentrator. A terminal concentrator provides a simple way of connecting several devices to a TCP/IP network. The concentrator connects to the workstations through an ethernet connection.

The Jini Network That's the hardware network. But there's also a Jini network that connects these devices so they can take advantage of each other's services as illustrated below. The illustration also provides links to full source code like that provided for the key components of the demonstration.

The central element of the Jini network is the Jini lookup server. The lookup server can reside anywhere on the network that a suitable JVM exists, that is, one that supports the Java 2 platform and Java Remote Method Invocation. The lookup server manages a central registry of services that are available in the network. Also running in the workstation is a thin Java server process known as the "tank daemon". The tank daemon handles the low-level details of IR communication between a tank and a workstation. Because they don't run a Java virtual machine, the tanks need an intermediary to link them into the Jini network. This intermediary is called a "Jini proxy." This is a simple Java object that is instantiated by the tank daemon when a tank is switched on. Once a tank is turned on it can be commanded to do something by making a method call on the tank proxy object. The Palm Pilots also require a proxy object, the palm proxy, to become part of the Jini network. The palm proxy is also a Java object. It is instantiated by a server process called the "palm daemon." The palm daemon listens for connections from the Palm Pilot. When a tank proxy is created for a tank, the proxy can participate in a pair of Jini protocols called "discovery" and "join." These protocols help find one or more lookup servers for a device. The protocols also allow a device to upload its service interface to a lookup server. This makes the device's services available to other members of the Jini network. The palm proxies represent the Palm Pilot devices as clients in the Jini network. These proxies also participate in the discovery protocol in order to find lookup servers. Once a lookup service is found, the Palm proxy searches it for services that implement a "drivable" interface. When it finds an available tank proxy, the palm proxy downloads the tank service's interface from the lookup server. Then it can start making method calls on the tank proxy object. The lookup server uses a leasing mechanism to maintain a list of active services. After a service successfully uploads its interfaces to the lookup server, it receives a ServiceRegistration object. The ServiceRegistration object can then be used to get the Lease object. This object must be used to periodically renew a service's lease. If the service fails to renew its lease, it is dropped from the list of active services. This could happen, for example, if a tank is switched off or moved out of range of an IR tower. Eventually the tank's service lease expires. At that point, the tank is automatically removed from the Jini network.

Challenges and Solutions

Challenge #1 -- Communicating with a Lego Mindstorms Robotic Tank At the heart of the Lego Mindstorms Robotic Invention System is the RCX or "brick". The brick is a microcontroller that can receive data from various input sensors, process data, and signal motors to turn on and off. Furthermore, the brick is programmable -- you can write a sensing or control program on a workstation, compile it, and then download it by IR transmission to the tanks. This same communication mechanism can be used to communicate between an application and the brick. Using a serial connection, an application running on the workstation can send data to and receive data from the brick. Here's how the program communication with the tanks was set up:

A Java object was created to model the brick. A Java object and a supporting class were created to handle the low-level details of communicating with the brick.

We've provided a sample class, IRTest, that shows how to instatiate and use the brick object to communicate with the tank. The logic in IRTest mirrors some of the logic to the tank daemon. The Brick Object: The physical brick was modeled as a brick object. The brick object communicates with the serial port using the Java Communication API. This allows abstraction of the hardware and its low-level details, which in turn creates small, manageable objects. Ultimately, this approach creates an application with no particular operating system or hardware platform as its target. The IR Protocol Object: The IR Protocol Object uses the Java Communications API to handle low-level details of IR communication with the physical brick through the IR tower. A supporting class was created to assist the IRProtocol object in the asynchronous receipt of messages from the brick. The Lego Mindstorms Kit includes a sample graphical programming

environment designed for people with little or no software experience. This tool provides an easy way to create and install simple programs on the brick. However, the level of program flexibility and complexity was too limited for this project. To fill its needs, the team selected a software package called "Not Quite C" (NQC), developed by David Baum and available under the Mozilla Public License. NQC, a simple programming language with C-like syntax, available in binary form for Macintosh, Linux, and Windows, was used to create and install this application. As an example, we've provided the source code for the application we installed on the brick. Challenge #2 -- Developing a Remote Control Application The next challenge was to find a suitable client to control the Lego Mindstorms tanks. The hardware platforms to be used could not be determined ahead of time. Because of that we needed client software that could run on any platform with little or no modification. At that time, several companies, including Sun, were in the early stages of developing extremely small Java virtual machines for consumer devices. Among Sun Microsystems Laboratories research projects was the Spotless system, an experimental Java system for the Palm Connected Organizer. KVM technology, the perfect platform for the project's client, grew out of this system. A remote-control application written in the Java programming language and running in KVM for the Palm III and Palm V could later run on newer embedded devices without any code changes. The requirements were simple: A user would need the ability to move the tank forward, backward, turn left, right, or stop. This functionality mapped simply into a Java applet with buttons arranged much like the buttons on your television set's remote control. In response to each button click, the applet sends a single-byte command over a socket connection to a server process running on a networked workstation. Here is the source code. Challenge #3 -- Creating a Flexible, Multi-User Environment

The final challenge was connecting the tanks and the Palm Pilots into a flexible, dynamic network. The tanks had to be able to easily plug into the network, making their "drivable" services available. The Palm Pilot clients also needed to automatically connect to the network and find something to drive. Both devices needed to be easily removable from the network, at any time, without affecting the rest of the network. Jini technology was the obvious choice for addressing these challenges. The Jini lookup service provided a central registry of services for the networked devices. When switched on, the Lego tanks used the discovery and join protocol to find a lookup server and upload the tanks' service interface. Similarly, the Palm Pilot used the discovery protocol to find a lookup server and tanks. It then searched for a suitable, matching service interface. Sending and receiving messages to a single tank was reasonably straightforward. Communicating with several tanks simultaneously proved to be a bigger challenge. The tank daemon only lets a single device transmit at any given moment. If more than one device sends data via infrared at the same time, it results in collisions and a loss of data. To solve this problem, the tank daemon implements a protocol that allows multiple clients to communicate with individual tanks. The protocol used the brick object. An additional server process, the palm daemon, was developed to accept incoming socket connections from the Palm Pilots. To become part of a Jini network and make itself known to the rest of the network, a device or service must participate in the Jini discovery protocol. It must also register itself to a Jini lookup service. The Jini discovery protocol lets a device or service obtain a RMI reference to the lookup service. Once obtained, this reference lets the service register itself. The service can then be found and used by other members in the network. Smaller devices, like the Lego Mindstorms brick and the Palm Pilot, may not have a full-featured Java virtual machine, which supports advanced features, like RMI. In fact, many devices may not have a virtual machine at all. This does not mean, however, that these devices cannot take advantage of Jini technology. The only requirement is that there be a Java virtual machine somewhere on the network and that the devices can communicate with it. In this case, the tanks take advantage of a full JVM resident on a local workstation. At startup, the tanks announce

themselves, one at a time, to the tank daemon. The tank daemon gets the announcement and it creates a Jini proxy object. This proxy object represents the physical tank. The proxy participates in the Jini discovery and join protocol to find and register its interface to the Jini lookup server. This makes the tank's services available to other members of the network. The Palm Pilots, which have a Java virtual machine but no RMI, similarly connect themselves to the Jini network. After a reliable TCP/IP connection has been established over a serial line, the Palm Pilots use the KVM's socket class to connect to the Palm server process described earlier. As client socket connections are accepted, a palm proxy object is created. This object represents the Palm Pilot in the Jini network and participates in the discovery protocol to find a lookup server. Once the object finds the lookup server, it searches for an available tank. The tank's interface is then downloaded into the palm proxy's local virtual machine. Because the palm proxy has a basic understanding of the tank proxy's interface, it can map commands sent from the Java applet running on the Palm Pilot to method calls on the tank proxy. The tank proxy, in turn, forwards the transmitted commands to its associated specific tank.

Conclusion
Developing applications for embedded devices can be difficult. Limited computing resources and flexible networking requirements present interesting roadblocks for software developers to overcome. Jini technology and the K Virtual Machine helps developers get around these obstacles by letting them focus on application-level issues rather than low-level hardware and connectivity details.

The Achievements
The demonstration described in this article showed that the K Virtual Machine can be used in today's embedded devices to develop and deploy portable, real-world applications. It also showed that Jini technology gives developers a resilient and flexible networking fabric into which embedded devices can be easily woven.

Lessons Learned
The success of this project taught the developers of the demonstration several things:

Successful application developers will be those who write applications that run anywhere. Writing applications targeted for multiple hardware platform demands building in as few implementation details as possible. The K Virtual Machine lets you use the Java programming language to write reusable, maintainable objects for embedded devices. The ability to represent devices and services as objects is very important. The amount of information that can be stored on a given amount of silicon roughly doubles every year. This trend makes it possible to implement complex systems in single chips. These systems can be interconnected to form larger, more complex systems. In a Jini network, each of these devices and services is treated as an object -- an object that can be moved throughout the network. Developers no longer need to concern themselves with the complexity of a system but rather how objects interact.

While this project may appear to many to be a major undertaking, the developers involved in the project worked on the separate technologies, like the KVM and Jini technology, in distinct stages. Ultimately they built on the experience they gained from doing smaller sub-projects. At key points during the project, technologies and the understanding of those technologies were combined into something more complex. As a result we also learned the most important lesson of all: the best way to evolve a technology is to take on something small and do it very well. Download the Demonstration We've provided a compressed .tar file that contains all the files, including documentation, for recreating the demonstration. tankdemo.tar.gz (To download, hold down Shift key and click) More Information:

K Virtual Machine Jini Device Architecture Specification Lego Mindstorms Robotics Invention System Programming the Lego Brick Using NQC Palm Computing Platform Development Zone Jini Technology Architectural Overview Java Object Serialization Spotless System Page Lego Mindstorms Internals RCX Internals

_______ 1 As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.