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.
Leasing
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.
Persistence
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.
Security
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).
Transactions
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.
Directions
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.
Availability
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 TECHNOLOGY
GRANTS THE ULTIMATE WISH
Jini
Architecture Overview
Will
Jini find Developer Support
The
skinny on Jini
Jini
in reality
GOSLING OUTLINES NEW DISTRIBUTED
JAVA ARCHITECTURE
Voyager
and Jini
Jini
FAQ