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

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 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 communicates with service via proxy

“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.