This chapter gives a brief overview of the components of a Jini system and the relationships between them.
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 Enterprise Beans. 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 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 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/service locator. 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 (Java Virtual Machine). Any requests that the service needs to make of the lookup service are made through this proxy registrar.
What the service does with the registrar is to register
the service with the lookup service. This involves taking a copy of the
service, and storing it on the lookup:
The client on the other hand, goes through the same mechanism
to get a registrar from the lookup service. But this time it
does something different 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 appears we have a
chicken-and-egg situation: how does the proxy find its service?
Use a Jini lookup? No, when the proxy is created it is ``primed''
with its own service's location so that when run it can find its
own ``home''.
This will look like
