Service

From Jini.org

From the Jini Architecture Specification:

The most important concept within the Jini architecture is that of a service. A service is an entity that can be used by a person, a program, or another service. A service may be a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user. Two examples of services are printing a document and translating from one word-processor format to some other.

Members of a Jini system federate to share access to services. A Jini system should not be thought of as sets of clients and servers, users and programs, or even programs and files. Instead, a Jini system consists of services that can be collected together for the performance of a particular task. Services may make use of other services, and a client of one service may itself be a service with clients of its own. The dynamic nature of a Jini system enables services to be added or withdrawn from a federation at any time according to demand, need, or the changing requirements of the workgroup using the system.

Jini systems provide mechanisms for service construction, lookup, communication, and use in a distributed system. Examples of services include: devices such as printers, displays, or disks; software such as applications or utilities; information such as databases and files; and users of the system.

Services in a Jini system communicate with each other by using a service protocol, which is a set of interfaces written in the Java programming language. The set of such protocols is open ended. The base Jini system defines a small number of such protocols that define critical service interactions.

In more pedestrian terms, a Jini service is usually code running under some JVM that is capable of being called remotely, by Jini clients or even by other services. Services that form a community and are capable of calling each other are said to form a djinn.

A service makes itself available to a djinn through two steps:

1. Exporting itself. This process creates a proxy object for the service which can be handed out to remote clients. The proxy encapsulates remote communication with the service, usually over some port, as well as the specific protocol used, such as RMI or JERI.
2. Joining a djinn by registering its proxy with lookup services such as Reggie. The service locates lookup services via unicast discovery or multicast discovery and supplies each one with its proxy. The lookup services are responsible for handing the proxy over to interested clients so that the service can be found and called.

Services can run under activation using an activation daemon such as Phoenix. Otherwise, they tend to each run in their own JVM.