Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

The skinny on Jini

Jini and JavaSpaces bring true distributed computing to Java

By Rawn Shah, JavaWorld.com, 08/01/98

By now you've read about Sun Microsystems's July 20 announcement of the release of Jini, its new technology for distributed computing. Sun released the specifications for Jini to the public, giving everyone the chance to delve into distributed programming.

To understand Jini, you'll need to know about JavaSpaces, because the two are carefully woven together. Further on in this article, you'll see that JavaSpaces is actually more important than Jini, but let's start at the beginning: What are these two technologies and what do they do?

• Jini provides the distributed system services for look-up, registration, and leasing
  
  
• JavaSpaces manages features such as object processing, sharing, and migration

JavaSpaces needs Jini to perform its functions. To use a military metaphor, Jini acts as a quartermaster allocating equipment and armaments to the JavaSpaces troops. The troops use the allocated equipment to carry out their orders in battle.

In this article, we'll provide an architectural overview of what Jini and JavaSpaces do and how they work together. Then we'll compare and contrast the Jini-JavaSpaces technology with similar technologies. And, finally, we'll explain how this technology can be used and where it will be most beneficial.

The details on Jini

As Sun puts it, Jini allows you to create a "federation" of devices and software components in a single distributed computing space. Although the components work together to serve a common goal, they're still identified as separate components on a network. The federation provides services that are accessed by the various devices and software components. By services we mean communication mechanisms, users, hardware devices, storage devices, calculators (i.e., for your spreadsheet), notepads (for your BBS), and so on. The various members of a Jini federation share their services to get a job done. They communicate with each other through a set of Java interfaces known as the service protocol, and they locate each other using a special look-up service. The look-up system works in a multipoint network environment and the different components are ordered in a hierarchy.

The low-level communications used by Jini is the Java Remote Method Invocation (RMI) API as specified in JDK 1.2. There are a few basic changes between RMI in JDK 1.1 and 1.2 that better support the Jini system, particularly object activation, and distributed garbage collection. Jini requires RMI in the new JDK. The current specification documentation is slightly off when it says "extended RMI"; there are no extensions to RMI specifically for Jini other than what is already in JDK 1.2.

Each component has an ACL (access control list) describing which other components are allowed access to it. The component that sends out a service request, known as the principal, communicates with other components needed to perform a service.

The look-up service, distributed security system, RMI 1.2, and the discovery protocol (to register or locate a service using the look-up service) together constitute the infrastructure component of Jini.

The leasing system
All services are granted as leases. Each service, when in use, is registered as being leased by another service. Leases can be exclusive or they can allow multiple requesting services to connect to a given service. Leases are time-dependent and have to be renewed upon expiration.

The transaction system
This transaction system is based on the common two-phased commit model. The system keeps records of the transaction environment before and after the transaction is processed so that it can be undone if necessary. The standard, however, does not indicate how this transaction system is implemented; that is left to the developer implementing the individual services.

The distributed event model
The distributed event model is an extension of the system used in JavaBeans. An event is a notification system for the services to indicate that an action is to be taken. The distributed event mechanism requires that Jini services register with others to receive notification. The Jini system handles the task of locating the services according to the hierarchy.

The leasing system, the transaction system, and the distributed events model together constitute the programming model for Jini. This, together with the infrastructure component and the services component describe the Jini component architecture. By itself, Jini works to create a sort of "plug-and-play" environment for all sorts of devices and software components on a network. JavaSpaces uses this architecture to create distributed computing systems.

JavaSpaces

JavaSpaces employs a simple mechanism for accessing and processing distributed objects. Simply said, a client application makes contact with a JavaSpaces server. The client asks for a certain type of object by sending a template describing what the object looks like. The space will then respond with the entry that best fits the template description. The client sends a read operation to make a copy of the entry within that space and work with it. Alternatively, the client can also do a take operation to take an existing entry from that space, effectively removing it from the list of entries. The client then processes the entry object as needed. Once completed, it can do a write operation to put that entry object back into the space, so that others can use it. If you have multiple clients looking for a particular entry, you may want to run notify to alert the system that you are waiting for the entry or to find out if someone else has written that entry.

That's it. A very simple concept in theory, but one that involves many services to handle the different parts. For example, each read, write, or take operation is a transaction and can be undone, so security is an issue. It's important to confirm that request clients have proper access rights to the entries. In addition, a mechanism needs to be in place to notify the different clients registered using the notify operation, and you need to be sure one client doesn't hog entries for itself. And guess what? Jini does it all.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.