Jini and JavaSpaces Overview
| Sun Microsystems' Jini promotes a Java-based interface to network services. The architecture is based on distributed services that are capable of discovery using restricted multicast and directed unicast messaging. (Jini and JavaSpaces concepts are discussed in more detail in Chapter 14, "Jini and JavaSpaces," and Chapter 15, "P2P Jini and JavaSpaces.") Jini DefinedThe notion of a service is fundamental to Jini. Jini services are usually manifested as Java objects that expose an interface that conforms to the Jini specification. The type of the service determines the interfaces that make up that service. Jini services advertise their operations by registering an object with a Jini-compliant lookup service. Service registration is at the core of building the Jini network community. RMI and Mobile CodeA primary difference between Jini and other solutions is its capability to move code around the network. Because it uses RMI and object serialization, it is able to download code on demand. There is no human intervention required in the process. This has some distinct advantages over other systems being defined. The client of a service does not need the software installed prior to running the application. As long as the client can attain the interface to the service, it can execute the code. Software agent technology, especially mobile agents, can benefit from the framework Jini has established. Lookup and DiscoveryEvery Jini community must have at least one registry or lookup service available. The lookup service (LUS) for Jini can be compared to:
Each of these systems provides a mechanism for resolving a name to an information processing location. Each system takes a different approach and extends the functionality in different ways. For instance, RMI maps a name (String) to an object. DNS maps host names to IP addresses, and UDDI provides a directory to register a Web service. The lookup service enables service-using entities to register and find services that meet specific criteria. The lookup service provides functions similar to a yellow page service. To Jini, the lookup service is just another service on the network, albeit an important one. The lookup service is what in effect bootstraps the Jini network. Services register with the lookup service, and applications find services of interest using the lookup service. After a service is found, an application can invoke the methods that the service exposes through its public interface. LeasingOne of the concepts introduced in Jini is the concept of resource leasing, or time-based resource allocation. The leasing of resources has direct implications on the programming model used and the services that must be implemented to support a Jini network. Leasing implies that nothing is permanent in the Jini system. You must renew leases and renew interest in resources in order for them to remain active and available. Otherwise, they will be purged from the network by their removal from the lookup service. Imagine how much friendlier the Web would be if bad or invalid links were just magically purged or disappeared! There is a lease renewal service defined as a helper service in the Jini framework that renews interest in resources for you. This is another service that enables disconnected clients and minimizes the amount of development work required by developers that use the Jini model. JavaSpaces DefinedJavaSpaces is an example of a Jini service that runs on the Jini network and is closely tied to the Jini architecture. JavaSpaces was heavily influenced by the concept of a tuple space, which was first described in 1982 in a programming language called Linda. The concept is based on a shared-memory. Communication between distributed processes is provided through this shared-memory. Any number of processes can communicate without requiring prior knowledge of process location or how many processes might actually be "listening." Programs read, write, and take tuples from this shared workspace. Peer-to-peer systems have already demonstrated the need for a distributed network of loosely coupled collaborating processes. These processes require identity, task management, and coordination. JavaSpaces provides a lightweight implementation of persistence that can aid in implementing a collective memory. Distributed StorageWith JavaSpaces, distributed processes communicate by reading and writing entries into a space. The JavaSpace API provides an event notification mechanism, which enables processes to register for notification, when a specific object is written to a space. A space is defined by JavaSpaces as a shared, network-accessible repository for objects. This shared repository can persist objects written to a space beyond the lifetime of the process that created them. Spaces provide reliable storage for objects and support leases. Objects in a space are located via associative lookup, as opposed to more traditional keys or identifiers. When you read or take an object from a space, a local copy of the object is created. As with any other local object, you can modify its public fields and invoke its methods. In addition, JavaSpaces supports transactions for single operations, such as writing an object to a single space, as well as multiple operations over one or more spaces. JavaSpaces' strength lies in its capability to simplify the programming required to coordinate distributed communication and parallel processing. Devices and ServicesAs mentioned previously, Jini is based on services that are available on a network. Jini blurs the distinction between hardware and software. This might have contributed to the initial "technology for intelligent devices" mantra that was echoed so strongly in most publications defining Jini. But at the core, Jini is about services. It is about delivering services regardless of the platform. Whether the code is burnt into a device or deployed on a farm of servers is not the issue. The intent is that services are not limited to traditional platforms. The Jini design recognizes the emergence of devices as the next logical platform for executing networked application code. P2P ApplicabilityDynamic discovery enables peers and services to find each other. It allows for the quick formation of groups and communities sharing a common interest. However, speed of assembly must be tempered with network integrity. Jini uses a combination of unicast and multicast protocols to dynamically discover services on the network. There is the notion of a well-behaved service that implements these protocols in a specific manner. The intent is to ensure broadcast storms do not occur, and that there is a higher level of resiliency in the network. Resource conservation will be required in any system that needs to scale dynamically. Whether it is enforced explicitly in the API and/or implicitly through rules of engagement remains unknown. Applications that use broadcast techniques to discover peers can contribute to serious network congestion when traffic does not get distributed appropriately. There is no clear winner is this space. However, the key components of the Jini framework are dynamic service discovery and the controlled formation of communities. Jini is Java-based. Interfaces define the services and the protocols in the Jini network. Jini does not support the notion of XML being fundamental to the process of defining and accessing services on the network. In terms of the other solutions, Jini appears to be the maverick. Jini relies on the richness of type semantics. There is also the belief that these type definitions and the ease with which they support subtyping (inheritance) resembles the way we build systems. Systems can evolve as the technology evolves. The other approaches rely on XML definitions or APIs that limit the systems' adaptability to change. JavaSpaces provides a collective memory, which could provide rendezvous peers capable of supporting identity and presence services. JavaSpaces clusters could also be used to scale systems and provide fault resiliency. |
