When running Jini system, you are dealing with three main players: a service, a client, and a lookup service. The service could be something such as a printer, a toaster, a marriage agency, and so forth. The client would like to make use of this service, and the lookup service acts as a broker/trader/locator between the service and client. (The generic term for the lookup service seems to be settling on service cache manager.) An additional component is a network connecting all three main players, and this network will generally be running TCP/IP. (The Jini specification is fairly independent of network protocol, but the only current implementation is on TCP/IP.)
Code is moved around between these three pieces by marshaling the objects. Marshaling involves serializing the objects in such a way that they can be moved around the network, stored in a "freeze-dried" form and later reconstituted by using included information about the class files as well as instance data. This process is performed using Java's socket support to send and receive objects.
In addition, objects in one Java Virtual Machine (JVM) may need to invoke methods on an object in another JVM. Often this will be done using RMI, although the Jini specification does not require this, and there are many other possibilities.
Figure 1-3 shows the components of a Jini system discussed in this section.
