This chapter gives a brief overview of the components of a Jini system and the relationships between them.

1. Components
2. Service Registration
3. Client Lookup
4. Proxies
5. Server Structure
6. Client Structure
7. Summary

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 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).

The first stage is for the service to register itself with the lookup service/service locator. 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 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. Any suitable protocol may be used to do this, but in practice the implementations that you get of the lookup service (e.g from Sun) will probably use RMI.

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, probably 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

A server application will internally look like

prepare for discovery	Discovering a lookup service
discover a lookup service	Discovering a lookup service
create information about a service	Entry objects
export a service	Service registration
renew leasing periodically	Leasing

Internally a client will look like

A Jini system is made up of three parts

1. Service
2. Client
3. Service locator

A service and a client both possess a certain structure, which is detailed in the following chapters.