Overview of Jini

Jini is just one of a large number of distributed systems architectures, including industry-pervasive systems such as CORBA and DCOM. It is distinguished by being based on Java, and deriving many features purely from this Java basis. There are other Java frameworks from Sun which would appear to overlap Jini, such as the Java Application Frameworks. This tutorial does not delve much into the relationships between all these various systems, but the reader should be aware that Jini is only one competitor in a non-empty market. What will condition the success or failure of Jini is partly the politics of the market, but also (hopefully!) the technical capabilities of Jini, and this tutorial will deal with some of the technical issues involved in using Jini.

In a running Jini system, there are three main players. There is 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 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 be running TCP/IP and in particular Java's Remote Method Invocation (RMI) protocol.

The first stage is for the service to register itself with the lookup service. At this stage it cannot use RMI, because it has not yet located the lookup service! So it uses a special TCP protocol running (by default) on port 4160. Each lookup service will be listening on this port. When the lookup service gets a request on this port, it sends an object by RMI back to the service. This object, known as a registrar acts as a proxy to the lookup service, and runs in the service's JVM. Any requests that the service needs to make of the lookup service are made through this proxy registrar.

The service on the other hand, goes through the same mechanism to get a registrar from the lookup service. But this time it does something with this, which is to request the service to be copied across to it.

At this stage there is the original service running back on its host. There is a copy of the service stored in the lookup service, and there is a copy of the service running in the client's JVM. The client can make requests of its service object running in its own JVM.

How does this work if the service is actually a toaster, a printer, or controlling some piece of hardware? By the time it runs in the client's JVM, it may be a long way away from its hardware. In this case, rather than sending out a copy of the service itself, the service will send out a proxy, which will communicate back to the service using RMI. It will perform the same sort of activity as the lookup service when it sends out a registrar object. This will look like