Jini and MindStorms

Jini [Jini] is another piece of Java technology in an apparently never-ending stream from Sun Microsystems. Jini offers ``network plug and play'', whereby devices or services can join a network, and immediately become part of a ``federation'' of other services. Clients wishing to use such services can be made aware of them joining the network federation and can start using them. Conversely, when a service leaves (say, by being switched off), then knowledge of this service will in time disappear from the federation so that no further attempts will be made to use it.

Jini is just one of a large number of distributed systems architectures, including industry pervasive systems such as CORBA and DCOM. It is distinguished from them by being based on Java, and deriving certain features specifically from this base. CORBA is trying to adopt some of these features in its newer versions, but must be limited in its success in this because of its heterogeneous base of languages and platforms.

JIni is also just one of the distributed systems architectures from Java at Sun [Java]. These include Enterprise Java Beans (EJB), Java Network Directory Information services (JNDI) and Java Dynamic Management Kit (JDMK). These are typically based on Java's TCP/IP networking mechanisms, and may use Remote Method Invocation (RMI).

Jini can deliver software services, which brings it into ``competition'' with these software-based architectures. The relation of Jini to these more enterprise-oriented architectures is yet to clarified.

Another target market for Jini is that of embedded and portable devices. This will allow printers, disk drives, toasters, refridgerators, etc, to become part of a Jini federation, as well as mobile PDA's. Connections to such devices may be made by ordinary TCP/IP networks, but may be based on emerging standards such as BlueTooth. Other vendors, such as Hewlett-Packard, as large-scale producers of embedded technology are proposing alternative standards such as Chai [Chai].

The ultimate success or failure of Jini will depend on commercial and political factors as much as on technological ones. This paper looks at the technical issues involved in building components into Jini services. Examples are given of how to make software services into Jini services. It will also be important to bring hardware devices into a Jini federation. The Lego MindStorms is a ``Robotics Invention System'' that was designed to be driven by Visual Basic OCX's. It is shown how this can be made into a Jini service without too much difficulty.

In a running Jini system, there are three main players. There is a service, such as a printer, a toaster, a marriage agency, etc. There is a client which would like to make use of this service. Thirdly, there is a lookup service (service locator) which acts as a broker/trader/locator between services and clients. There is an additional component, and that is a network connecting all three of these, and this network will generrally be running TCP/IP. (The Jini specification is fairly independent of network protocol, but the only current implementation is on TCP/IP.)

Code will be moved around between these three pieces, and this is done by serializing the objects (and marshalling them to allow storage without reconstitution), and using Java's socket support to send and receive objects. In addition, objects in one JVM (Java Virtual Machine) may need to invoke methods on an object in another JVM and this will typically be done using RMI (Remote Method Invocation), although the Jini specification does not require this (it may require RMI semantics, but not necessarily implementation).

Figure 1: Components of a Jini system

Movement of code is the main distinguishing feature of Jini which is not presently offered by the other commercial technologies. The platform independence of Java bytecodes is the factor in this that makes it useful. A technology such as CORBA will only export a reference to the service, and a proxy on the client side will use this to make remote calls. A CORBA proxy is ``thin'', as is a DCOM one. The code exported from a Jini service can be thin, but can also be as fat as needed. This gives rise to lots of interesting possibilities

• a service can ``export'' a user interface across the network, and this can be run by any client. The service could even export multiple interfaces (GUI, command-line, etc) for the client to choose between them.
• a proxy can start a transaction through a transaction server, so that the client and service can reliably negotiate payment for the service
• the proxy can run any other service needed to complete its task, such as getting more information from a local Web server. For example, it could query a local geographic database to discover how far the service is physically from the client (important for a printer!).

Service locators act as traders within Jini. They store information about services (as instances of Java objects) and clients can query the locators, getting these Java objects in return. Before a service can register itself with the locator, and before clients can query them, they must themselves first be found! They may be at fixed, known locations, in which case a unicast TCP connection may be made directly. Alternatively, they may need to be searched for. Jini supports unicast lookup for known locations, but also allows multicast search. Typically this is limited by a time-to-live (TTL) of 15, which will usually restrict the search to a local network.

Jini moves objects around in a serialised form. These have to be ``reconstituted'' on the client side as ``live'' objects. This means that the class files have to be available to the client. They cannot pre-exist on the client side, or there would be no point in having remote services. Instead, they will exist somewhere on the server side and will need to be downloaded as required. Typically this is done by making class files available from an HTTP server. Downloading files requires security permissions using the JDK 1.2 security model.

There are a large number of configuration issues that arise in this, and getting it right can be non-trivial. About 50% of the messages on the Jini mailing list are concerned with configuration problems.

It is becoming increasingly common to model an object-based application using a graphical representation such as UML. For example, suppose we have a smart version of ``cat'' which will display file contents based on an appropriate viewer for the file type. An object based model for this could look like

While this still has validity in the Jini, it is also necessary to model the distribution of services, which here would be as

Lego MindStorms (http://www.legomindstorms.com) is a ``Robotics Invention System'' which consists of a number of Lego parts and a microcomputer called the RCX, plus an infra-red transmitter (connected to the serial port of an ordinary computer) and various sensors and motors [Lego]. Using this, one can build an almost indefinite variety of Lego robots that can be controlled by the RCX. This computer can be sent ``immediate'' commands, or can have a (small) program downloaded and then run.

MindStorms is a pretty cool system, that can be driven at a number of levels. A primary audience for programming this is children, and there is a visual programming environment to help in this. This visual environment only runs on Windows or Macintosh machines which are connected to the RCX by their serial port and the infrared transmitter. Behind this environment is a Visual Basic set of procedures captured in an OCX, and behind that is the machine code of the RCX which can be sent as byte codes on the serial port.

A MindStorms robot can be programmed and run from an infrared transmitter attached to the serial port of a computer. There is no security or real location for the RCX: it will accept commands from any transmitter in range. We will assume a ``home'' computer for it.

There must be a way of communicating with this device. For a MindStorms robot this is by the serial port, but other devices may have different mechanisms. Communication may be by Java code or by native code. Even if Java code is used, at some stage it must drop down to the native code level in order to communicate with the device - the only question is whether you write the native code or someone else does it for you and wraps it up in Java object methods.

For the serial port, Sun has an extension package - the commAPI - to talk to serial and parallel ports (http://java.sun.com/products/javacomm/index.html) . This gives platform-independent Java code, and also platform specific native code libraries supplied as DLL's for Windows and Solaris. I am running Linux on my laptop, so I need a Linux version of the DLL. This has been made by Trent Jarvi (jarvi@ezlink.com), and can be found at http://jarvi.ezlink.com/rxtx/. The native code part of communicating to the device has been done for us, and it is all wrapped up in a set of portable Java classes.

The RCX expects particular message formats, such as starting with standard headers. A Java package to make this easier is available by Dario Laverde at http://www.escape.com/~dario/java/rcx. There are other packages that will do the same thing: see the ``Lego Mindstorms Internals'' page by Russell Nelson at http://www.crynwr.com/lego-robotics/ [Lego-internals].

With this as background, we can look at how to make an RCX into a Jini service. It will involve being able to construct an RCX program on a client and send this back to the server where it can be sent on to the RCX via the serial port. This will then allow a client to control a Mindstorms robot remotely. Actually, the Jini part is pretty easy - the hard part was tracking down all the bits and pieces needed to drive the RCX from Java. With your own lumps of hardware, the hard part will be writing the JNI and Java code to drive it.

On the service side, what this looks like is

For the client, what it knows of a Jini MindStorms service is supplied by a Java interface

package rcx.jini;

import net.jini.core.event.RemoteEventListener;

public interface RCXPortInterface extends java.io.Serializable {

    /** 
     * constants to distinguish message types
     */
    public final long ERROR_EVENT = 1;
    public final long MESSAGE_EVENT = 2;

    /**
     * Write an array of bytes that are RCX commands
     * to the remote RCX.
     */
    public boolean write(byte[] byteCommand) throws java.rmi.RemoteException;

    /**
     * Parse a string into a set of RCX command bytes
     */
    public byte[] parseString(String command) throws java.rmi.

    /**
     * Add a RemoteEvent listener to the RCX for messages and errors
     */
    public void addListener(RemoteEventListener listener) 
        throws java.rmi.RemoteException;

    /**
     * The last message from the RCX
     */
    public byte[] getMessage(long seqNo)
        throws java.rmi.RemoteException;

    /**
     * The error message from the RCX
     */
    public String getError(long seqNo)
        throws java.rmi.RemoteException;

} // RCXPortInterface

A client can prepare code as strings which can be turned into machine code by parseString(). This can then be sent to the RCX by write(). Messages back from the RCX are handled by the listener registered with addListener().

There is still much work that can be done with Jini and Mindstorms, such as

• Encapsulate client-side in a convenience class
• Make the ``Not Quite C'' RCX compiler available as a Jini service
• Make the RCX ``network aware'', by using e.g. an alternative O/S such as LegOS (for information on these two, see [Lego-internals])