A Look at Jini

Richard Chapman

Sept. 30, 1999

Jini Motivation

• Why must everyone be a sysadmin?

• Why can’t computers scale like the phone system: added complexity without added configuration work?

• Why can’t devices/services enter and leave the network without explicit reconfiguration?

Jini Goals

• Very robust software infrastructure• No configuration/administration

required • Software must be evolvable• Devices can form spontaneous

communities

Jini History

• Fulfillment of original Java goals of an environment for embedded systems (Oak, 1990)

• The word “Jini” does not stand for anything

• Went public too soon, NYT reporter John Markoff broke story in 1998

Jini is intended to be used by:

• Information appliances (thin clients, set top boxes, PDA’s)

• Desktop machines can benefit from a reduction in sysadmin duties

• Enterprise systems (servers) also benefit

Getting Jini

• Source code distributed under Sun community source license (open source)

• Need Java 2• Requires web server, RMI activation

daemon, lookup service• http://www.javasoft.com/products/

jini/

Networked vs Distributed Systems

• Move the data or move the code?• Conventional wisdom: since code has

to be compiled and installed, move the data, and call a routine on the remote machine

• Thus: make the remote function call look like a local function call as much as possible (RPC, CORBA, DCOM)

The network cannot be ignored

• Very high latency (orders of magnitude)

• High variability in latency (has a component failed or is the link just very slow?)

• New failure modes that do not exist on local machine (router down, nameserver crash, cable came loose)

Handling Partial Failures

• Partial Failures do not exist on local machines -- you know the state, for better or worse

• Partial failures arise when some, but not all hosts, receive a message from a sender

• May be difficult for sender to detect which hosts received message

Handling Partial Failures, Cont’d.

• Even if server can detect which hosts have not received a message, what does it do

• Can’t keep trying forever -- you run out of disk drives storing old messages you are trying to send

• Don’t want to give up and cut off the host that failed to get a message

Why CORBA isn’t enough

• Ignores network performance issues (makes remote call look like local call)

• An add-on to existing languages (not all machines implement C++ the same way)

• Example problems: endianness, size of int, float, char, etc.

Peter Deutch’s Seven Network Fallacies

• The network is reliable

• Latency is zero• Bandwidth is

infinite• The network is

secure

• Topology doesn’t matter

• There is one administrator

• Transport cost is zero

Jini adopts the programming model of

Java• One lanuage everywhere• Data in the same format everywhoere

(objects represented by bytecodes) • Strongly typed interfaces• Separate interface and

implementation• Plus: a distributed storage model

based on Linda (Gelernter, Yale)

Conventional wisdom is no longer valid.

• Code can easily move from machine to machine

• Servers can be dynamically updated

• Systems can evolve by updating interfaces with new code as needed, no need for recompilation

Strong typing is important

• In Java, an RMI defines the interface, while in CORBA, an IDL description is a wrapper around the interface

• Polymorphism works in RMI -- you can define subinterfaces; you can pass an ojbect of a subtype to remote server and the subtype methods are appropriately used (doesn’t work in CORBA).

Jini is built on Java RMI

• RMI = Remote Method Invocation

Public interface RemoteServer extends Remote {

public int getlength(String S) throws

RemoteException;

}

Java RMI, cont’d

• If you change the (Java) interface declaration in Java, you are really changing the way the interface works

• If you change the Java interface declaration in a CORBA system, you just break the interface, since the Java interface is generated automatically from the IDL description

Java RMI, cont’d

• Thus from a software engineering point of view, the CORBA implementation is more complicated and error-prone

• However, CORBA outperfromed RMI empirically (no longer true?)

• For enterprise solutions, CORBA is essential -- we will always need glue to connect heterogeneous systems

Strong typing, cont’d

• “Remoteness” is inherently part of the interface, not an implementation detail

• Every interface must extend java.rmi.remote

• Permits a reasonable definition of equality for remote objects -- you care if the remote objects are the same, not the local stubs

What Jini is not

• Jini is not a name server: lookup service is similar, but does more than provide references to objects

• Jini is not Java Beans: beans communication based on direct method invocation, not remote. Also, beans do not automatically become aware of each other as do Jini objects

What Jini is not, cont’d

• Jini is not Enterprise Java Beans: Enterprise Java Beans function across multiple address spaces well, but they put Java wrappers around legacy systems

• Jini is not RMI: built on top of RMI• Jini is not a distributed OS

Five Key Concepts of Jini

• Discovery• Lookup• Leasing• Remote Events• Transactions

Discovery

• Services=Devices or Software• Services collect themselves into

communities• The resources available to a community

are kept track of by a lookup service• No one-to-one mapping between

communities and lookup services• Discovery=finding available lookup

services

Discovery, cont’d

• Several discovery protocols• Multicast finds nearby lookup

services (on the same LAN)• Multicast Announcement declares

that a new lookup service has started up

• Unicast used to talk to a particular lookup service

Lookup

• Lookup server does more than nameserver

• Nameserver provides pointers to objects when given names

• Lookup server does that also, plus supports searching for services that meet certain criteria, e.g. those that have a particular Java type

Lookup cont’d

• Lookup returns a service item when queried successfully.

• Service item contains proxy object (local stub for remote object) and attributes that describe the service

Lookup, cont’d

Lookup service

Service item

Proxy

attribute

attribute Service item

Lookup, cont’d

• Downloadable proxy provided with each service item

• When any entity wants to use your service it downloads the proxy and runs it -- the proxy handles sending the remote server the necessary pieces

• Proxy can be used as a secure, network-aware device driver

Proxy scenarios

• Proxy may perform the service by itself, without any remote method invocation

• Proxy may be an RMI stub that knows how to talk to a remote service (e.g. IMAP mail server)

• Proxy uses private communication protocol to talk to legacy (non-Java) systems.

Using a Jini Service

Lookup service

Downloads proxy

Service Client

Client communicateswith service viaproxy

“How does client x know to call method y?”

• Objects must have some understanding of the services they are going to use

• Industry will have to define a common set of standards for interfaces to things like cell phones, printers, scanners, digital cameras

• My opinion: these interfaces will need updating, and may prove to be Jini’s undoing

Leasing

• Suppose a service provider dies at some point

• How do you keep dead services from accumulating in the lookup servers over time

• Solution: a service is only provided for a certain amount of time unless the provider re-registers it (renews the lease)

Leasing, cont’d

• No sysadmin needs to comb through the lookup service database to remove long-dead services

• Cleans up partial failures• Similarly, resource is not granted

to a consumer for indefinite period, but “leased” for a finite time

Leasing, cont’d

• Consumer must renew the lease if the resource continues to be needed

• Unreliable code thus does not do permanent damage -- after a while the resource is freed automatically

• No maintenance required of persistent storage

Third party leasing

• Jini leases can be negotiated by a third party

• Example: long-lived but rarely active process such as monthly disk backup routine

• Example: process that does not want to be bothered with extra code complexity of lease management

Delegation

• Similar to Java Beans delegation• Allows events to be handled by a

third party rather than the actual object to which the event was sent

Lease mechanics

• Discovery returns an object that implements lookup interface (called ServiceRegistrar)

• Server calls method register() of ServiceRegistrar with service item object as argument -- describes the service to be registered

Lease mechanics, cont’d

• Client calls ServiceRegistrar lookup() method to find if a service meeting its’ criteria is registered.

• Service registrar returns a service item object, whose proxy is then used to access object

• Lease is handled by an argument to register, which says how long (long int) the server plans to provide the service

Lease mechanics, cont’d

• Only one round of negotiation needed for a lease

• Lease done in terms of duration, not absolute time

• Leasing is not garbage collection

Events

• Used for asynchronous notification• Event is an object containing

information about external state change the recipient may be interested in

• Same as Java Foundation Classes and Java Beans model of events

Remote Events

• Remote events may not arrive in order sent

• Remote events may not arrive at all• Remote events more expensive to

send than local events• What does sender do if receiver has

crashed -- keep trying? How long?

Remote Events, cont’d

• Example: want to print an image taken with a digital camera to a printer

• Suppose digital camera is connected to network and there are no printers (want to “grey out” the print button on camera GUI)

• When a printer is connected, the cameras should be notified

Remote events, cont’d

• RemoteEventListener() is a remote interface used by objects waiting for events

• Method notify() invoked via RMI by objects that want to send events

• Very simple: one class, one interface, one method. Contrast to Java Foundation Classes

• Jini can implement generic 3rd party event listeners (hard in JFC).

Remote Events, contd

• Process interested in receving events leases that service just like any other

• Hence if a service dies, it is not sent events forever, only until its lease expires

Transactions

• Used to handle partial failures -- gives a way of deducing state of the system after a partial failure

• Used to guarantee data integrity( atomicity, consistency, isolation, durability)

Two-phase commit

• Transaction manager collects all constituent operations of a transaction

• Participants go to pre-commit status (compute all results they would compute if transaction were successful, but do not make them permanent)

• Send acknowledgement of successful transition to pre-commit status back to transaction manager

Two-phase commit, cont’d

• If any participant fails, transaction manager instructs all components to abort, else notifies all to commit

• State of all components of system is predictable in the presence of failures

Jini implementation of two-phase commit

• All participants implement TransactionParticipant interface.

• Three methods: prepare(), commit() abort()

• Jini transaction manager doesn’t care how the participants implement the methods, it just steps through the protocol.