OBJS Technical Note

A Rough Guide To Sun's Jini

Paul Pazandak
Object Services and Consulting, Inc.
August 1998

The purpose of Jini is to provide a communications infrastructure to enable services (users, software, and hardware resources) to become accessible and leaseable from without, within and between Jini (service) federations. At its core, Jini defines a small set of extensible components and corresponding protocols which facilitate the implementation of a basic Jini system. The core components include support for service discovery and lookup, distributed events, transactions, leasing, security, and simple persistence. The component APIs and accompanying protocols are low-level and require extending for application implementation.

This description has been significantly limited primarily to provide a quick overview of Jini (so many details have not been discussed). See the Jini site for the specifications describing Jini in greater detail.

The Jini Federation

The Jini architecture describes a set of core components, or tools, and interfaces which will facilitate the implementation of service-centric communications layers over intranets and the internet. This communications layer can be organized as federations of federations, where a federation is composed of between one to roughly 1000 services. While these services are logically organized as a federation, they will likely be physically distributed across many servers and devices. The existence and membership of each federation is maintained by a lookup service. The lookup service, in part, is a service trader or yellow pages which maintains the service interface descriptions for the services in the federation. In addition, in conjunction with the service advertisements, it also persistently stores java-based service-specific proxies which are downloaded and then used to communicate with the individual federation services. It is solely from this perspective that Jini supports code migration. Finally, the lookup service may contain entries to other Jini lookup services (for hierarchiical lookup), as well as to other naming or directory services. It is this capability which enables federations to be composed. Service entries are added to and removed from the lookup service using a discovery protocol (via RMI, like all other Jini components).

Jini Components and Interfaces

As Jini is likely to evolve, we can only say that the current components of Jini provide service discovery and lookup, distributed events, transactions, leasing, security, and simple persistence. This is the core functionality useful to all services.


The distributed leasing specification describes a set of interfaces and protocols to support the negotiation for, and time-based allocation of, resources. Any object or component implementing these interfaces can offer resources for negotiated periods of time. When a lease expires it is terminated. But prior to termination a lease may be renewed. The leasing API is used by the JavaSpaces, Transaction, and Distributed Events specifications.

Lookup and Discovery

As described above, the discovery and lookup functionality is the primary activity of every Jini federation. A discovery protocol is used to dynamically add and remove service advertisements and corresponding service proxy objects. The lookup service protocol provides a means to locate a desired service based upon some set of descriptors (including object type), optionally returning service proxy objects to communicate with the advertised service.

Service advertisements in the lookup service are leased via the distributed leasing service, and deactivate (unless renewed) after the lease period has expired.


Distributed persistence is described by the JavaSpaces specification. A JavaSpaces server provides, optionally distributed transaction-based, concurrent access to a simple distributed object persistent store. Alternatively, it can be used as a front-end to object and relational DBMSs. It may also provide transient, or non-persistent, data management (guaranteeing data integrity until application termination or system crash). A JavaSpaces server is used by each federation's lookup service to store service advertisements and their proxies. Using distributed events support, notifications can be sent out when entries are written to the server which match a specified template. Entries in a JavaSpaces server are leased; and, as described below, notifications are also leased. JavaSpaces has been influenced by the Linda project and is based upon Tuple space.

Finally, entries and objects in the server are strongly typed Java objects, so their methods can be executed by the server.


The ability to control operations within a Jini system can be regulated by an extended version of the Java platform's security model (augmented with distributed security features), which is based upon principals and object- or service-specific access control lists. No detailed documentation for security, beyond the basic Java security API, was made available.

Distributed Events

The distributed event and notification specification describes an extended, distributed, version of the JavaBeans event model. The basic protocol allows objects to register interest in events generated by other objects, and to receive notifications when those events occur. Central to this extended JavaBeans event model is that registering objects may use third party objects to provide notification management features. When interesting events occur, the third party objects are notified (in lieu of the registering objects). These objects, in turn, manage how the registering objects are eventually notified. Such management may include providing delivery guarantees, storing and forwarding, filtering, and other event processing. This mechanism also allows chaining of third party objects, providing additional flexibility.

Distributed notifications are leased. Therefore, when a lease is up, the associated event registration can be garbage collected.

Unlike JavaBeans, this event model also supports distributed event notification via RMI. In addition, as part of registering for an event, an object can be included that should be returned with the event notification.

No reliability or timeliness of notification delivery is provided, but is assumed to be provided through the various objects involved if necessary (such as the third party objects described above).


The transaction specification describes an extensible distributed two-phase commit protocol and associated semantics for distributed, and possibly nested, transactions. The two principle object types required for every transaction are a single transaction manager, and one or more (potentially distributed) participants. The transaction specification describes the transaction protocol and the manager oversees each transaction, communicating (via RMI) with its participants regarding the transaction's status and outcome.  However, the ACID properties of a transaction must be built into the participating objects, so they have the flexibility to implement them as appropriate to the situation, and the responsibility to ensure that they are not violated. Basic capabilities to recovery from crashes is also supported.

When a transaction is created a lease object must be provided. If the transaction does not commit by the end of the lease, the transaction manager will abort it.


While the Jini specifications describe the core component of a Jini system, it is primarily composed of interfaces and not implementation -- some is Sun's responsibility to finish, the rest is left to individual implementations, or commercial Jini component implementations. Further, it does not describe and only loosely constrains the implementation of any other services which may become part of a Jini federation. So, for example, while the core of Jini uses RMI for communication, the services (such as service - proxy communication) may use alternative protocols.

While the Jini interfaces are still expected to evolve for some time, I believe that most of the Jini-related activity inside and outside of Sun will focus on defining service-specific interfaces and toolkits.


From the Jini FAQ:

Source to be on web Q4 this year.

Q: How will Jini technology be licensed?

A: To drive innovation for the vision of Jini and to gain
   rapid acceptance in the market the Jini source code will be
   open to the developer community, similar to Netscape's
   Mozilla model and Linux's GPL. To guarantee
   compatibility and quality a mark for commercial products
   is being considered. The specific details around the
   licensing model are still being finalized. A draft of the
   proposed license will be available in August.

Some References

Jini Specs

Sun to let Jini spec out of the bottle


Jini Architecture Overview

Will Jini find Developer Support

The skinny on Jini

Jini in reality


Voyager and Jini

Jini FAQ