Distributed Programming

It is envisioned that Jini technology will be used to build a wide variety of distributed systems. To facilitate this, Jini distributed programming adds functionality to the core Java platform for three types of distributed programming operations: leasing, distributed events, and distributed transactions. Each of these is defined below.

Leasing

In distributed systems, the concept of leasing is analogous to leasing a car. When you lease a car, you negotiate a certain amount of time to use the car. When the lease expires, you return the car, never having to worry about it again. Similarly, the leasing company does not need to worry about keeping records on you after you return the car (except, of course, for future marketing purposes). With 2.5 billion Java capable devices, naming services like today's DNS would quickly be overwhelmed and ad hoc distributed programming would not be possible. Jini objects, therefore, negotiate leases with each other that dictate how long they wish to use, or offer for use, a particular service. This negotiation takes place during the Discovery and Join process. Before a lease expires , a device must re-negotiate the lease or its connection becomes no longer valid. This solves the problem of distributed garbage collection on Lookup tables.

Distributed Events

In a single computer, the operating system can guarantee that events will be received in the same sequence as they were sent. In a distributed environment, however, events can possibly be received out of order or perhaps never received at all. To facilitate distributed events in a Java environment, Jini technology includes a Java API for facilitating distributed events. This API defines a event number and sequence for each distributed event. By comparing sequence numbers , the receiving party can thus determine if an event was received out of order or lost.

Distributed Transactions

Distributed transactions are nothing new to computer science. Mainframe software such as IBM's CICS and client-server software such as BEA's Tuxedo have provided transaction services such as two-phase commit for many years . In a distributed Java environment, however, sometimes what is required is a very lightweight two-phase commit. Simply put, a two-phase commit assures that all events in a distributed transaction occur before the transaction is actually committed. Furthermore, in a Jini environment, two-phase commit functionality must be provided without pre-loading specific transaction handling software. This is done in Jini via another simple Java API.

The Jini distributed transaction API enables any Jini object to start up a transaction manager that manages two-phase commit for its transactions. Every object that needs to participate in the transaction discovers the transaction manager via Discovery and Join and then registers with the transaction manager. In any transaction, if one of the participating objects does not complete an event in the transaction, this information is then communicated back to the transaction manager. The transaction manager then tells all the participating objects to roll back to the last well-known state in the transaction.