Java Dynamic Networking with Jini Technology, Part 2

Having trouble keeping your distributed system up and running? Learn about the various mechanisms that Jini technology provides to support distributed component interactions.

by Jennifer Kotzen

Jan 31, 2005

Page 1 of 4

art 1 of this series began an introduction to Jini technology, an open software architecture that enables Java dynamic networking, which developers can use to create highly adaptive distributed systems. It briefly described the approach that Jini technology takes to tracking, selecting, and assembling services into a running system. Part 2 concludes the introduction with an overview of the various mechanisms that Jini technology provides to support distributed component interactions. It also identifies some common dynamic networking problems to which Jini technology is typically applied today.

Distributed Component Interactions
As any application developer knows, much of the work when coding a system involves coordinating the interactions of various system components and the flow of work through the system. This leaves developers to contend with a number of considerations: Will an event over here trigger a reaction over there? Or should component A make a proactive request for component B to perform some work? Should A wait for a response, or would it be better to communicate asynchronously? How should a transaction be structured so that multiple related operations either complete or fail in a consistent way? A sound distributed application architecture should provide support for such distributed component interactionsand Jini technology does.

Jini technology defines distributed transaction and event models for you, and also provides mechanisms that you can use to manage workflows, messaging, and shared memory needs in dynamic, distributed environments. Jini technology's component interaction models, as well as its service tracking, selection, and dynamic system assembly approaches, are designed around the fundamental notion that they will be used in dynamic, distributed environments. This means that they are designed to help you accommodate network inconsistencies that may manifest as partial failures or variable communications latencies, for example. Their design also follows suit with the technology's minimalist philosophythat is, the interaction models are generally specified as the smallest set of agreements needed to achieve a goal, enabling you to augment them with additional capabilities to best meet your application needs.

Jini Technology's Distributed Leasing Model
One of the most important differences between distributed and non-distributed systems is in the way that failures happen in them. In non-distributed systems, failures affect all system components simultaneously, and recovery of all components is also simultaneousthe system is either wholly running or completely failed. In distributed systems, the most common failure scenario is one in which some, but not all, system components cannot be accessed. This partial failure can be the result of a host machine failure, a network partition, a software failure, or simple neglect (say, for example, one component decides to cease responding to another component).

Jini technology introduced the concept of distributed leasing to help you address the resource management issues that partial failures present. Fundamentally, the leasing model enables distributed components to explicitly limit the duration of their agreed cooperation. This removes any possible ambiguity about when such agreements are terminated and thereby allows components to safely reclaim resources that had been associated with them.

How Leasing Works
Distributed leasing provides the mechanisms needed for two components to agree on an amount of time through which one will allocate resources on behalf of the other. For example, suppose you've written a Jini technology service. When your Jini technology service registers with a lookup service, a lease is used to establish an agreement about how long the lookup service will maintain a directory entry on behalf of your service. The resources being leased are those that the lookup service uses to maintain the service registration in its service directory. Since the resources belong to the lookup service, it grants the lease to your registering service.

The lease grantor establishes the duration of a lease, but it can be based on input that the lease requestor supplies. This means that the duration of each agreement can be specified independently, so you can tailor them individually to best meet the needs of each resource-leasing situation.

Leases can then be renewed, they can be canceled, or they can expire. The responsibility for initiating a lease renewal request belongs to the original lease requestor. In your example, if your service would like the lookup service to continue listing your service's availability, it must request that the lookup service renew its service registration lease before the time specified, as its original lease duration has passed.

A lease requestor can also cancel a lease at any time, thereby terminating the agreements represented in it. If a lease is neither renewed nor canceled before its specified duration time elapses, the lease automatically expires. In this case, as with a canceled lease, the lease grantor and lease requestor are both freed from obligations associated with the lease. In your example, if your service's registration lease terminates, either by being canceled or by expiring, the lookup service is no longer obligated to maintain a registration entry on behalf of your service. Both parties understand that, in this situation, the lookup service will release your service's registration and reclaim the resources that had been used to maintain it.

The Jini technology distributed leasing model operates effectively in partial failure scenarios. Partial failures simply result in lease expirations, which are managed according to well-understood lease terms. And, since lease grantors and the lease requestors both understand the terms of the lease, both are independently able to recognize and respond appropriately to a failure. Imagine the case of a network partition, where components that cannot communicate with one another are nonetheless both independently operational. The lease grantor and leaseholder both understand exactly when the agreement they share becomes void, and when both are free from their lease obligations. The expired lease also makes clear to both parties that, once the network is restored, the lease will need to be re-established.