The UCC group in the K2LAB research laboratory at DSV, Stockholm University are studying mobile agents for tying together work in a distributed environment. This has lead us to Java and Jini.
A number of Jini-based prototypes has been developed. These include an execution server (for mobile code), a locator service (for finding people), a blackboard messaging system (for agents), a remote launch control for applications and an LCD projector controller.
The execution service is a small Jini service which accepts other objects via RMI and gives them a thread of execution. This is one basic way of achieving mobile code in Java. Jini solves the basic problem of dynamically finding available execution services.
The locator service is a service centered around a database (Microsoft Access). Sensors update the database with location information, such as "User JOHN is logged in on workstation XYZZY". Sensor updates are encoded in HTTP GET-requests to a WWW server which update the database using the popular bridge Active Server Pages, VBscript and ODBC. The VBscript layer provides the interface definition for the sensors and isolates them the database implementation.
Clients of the locator service use Jini to discover the locator service and place their queries. Queries are restricted to the locator service's service interface which provides the bridge from Java RMI to JDBC and isolates the clients from the database implementation.
The Messenger agent employs execution services and the locator service to pass a message back and forth between two users. The originating user launches the agent with the payload which is a short text string. The Messenger agent contacts the locator service to determine where the receiver of the message is logged in. It then discovers an execution on the receiver's computer and moves there. The message is presented, the receiver types in a reply and the process is reversed.
The Interlocutor service acts as a blackboard messaging system for mobile agents. It is a Jini service which accepts registrations from clients and messages sent between them. Clients may register under a group name, an individual name or both. Messages can be sent to a group or to a list of individuals. Clients may also register a host and port number where they are listening for TCP connections (employing pre-arranged protocols). The Interlocutor service removes messages after a timeout period has expired. The payload of a message can be any serializable Java object.
This agent accepts a computer name and a command line, moves to the named computer and executes the command there. Before leaving the originating host, it examines the command line and loads any name which matches an existing file. Arriving on the host the agent downloads the files as temporary files, rewrites the original command to match the temporary filenames and executes the resulting command line.
The file starter service accepts a named array of bytes from a client, writes the bytes to a file and then attempts to launch the application appropriate for the filename. This is almost trivial on Windows 9x/NT/2K systems where the native association between filename extension and installed software can be easily exploited. Clients of the service see places where files can be dropped for presentation or editing.
Using the serial command specification of an ElectroHome EPS1024 projector and the javax.comm classes, a controller class for the projector was created. On this a command line interface was constructed which allows the projector to be controlled from a command prompt, locally or by using the remote command agent.
An general interface for video projectors was created on top of the specialized projector controller. This allows the ProjControl service to be reused against a variety of projectors. The general interface is thus quite simple:
All Jini services and clients are served by a HTTP server. Invoking computers only need to have Java 2, a policy file and a small jar (JarRunner.jar, available from Sun). This obviously requires that users have the URL to the HTTP server, and this is encoded in the command-files used to launch a particular agent, client or service.
An alternative to command-files would be to load and execute signed applets from the HTTP-server. Yet another option would be to provide users with pre-packaged jar-files which would take on the appearence of ordinary executable programs.