Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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?
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.
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 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,
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
notify operation, and you need to be sure one client doesn't hog entries for itself. And guess what? Jini does it all.