JINI Coordination-Based System By Anthony Friel * David Kiernan * Jasper Wood

Coordination-Based Systems New generation of distributed systems that assume that the components of the system are distributed and that the problem lies in the coordination of the activities of the components If a distributed system is seen as a collection of processes a coordination-based system handles the communications and cooperation between the processes while the processes handle the computations

JINI as a Coordination System JINI is more than a coordination system Referred to as such because: –supports generative communications using ‘JavaSpaces’ –lets clients discover services when they become available –has distributed event and notification system JavaSpaces – shared database that stores tuples, provides temporal & referential uncoupling of processes

JINI vs Tib/Rendezvous (1) NoneLookup serviceNaming Services Character stringsByte stringsNames General purpose Processes Incoming messagesCall-back serviceEvent Mechanism Self-describingProcess specificMessages MulticastingJava RMINetwork communications Publish/subscribeGenerative commsCoordination Model Uncoupling processesFlexible IntegrationDesign Goal Tib/RendezvousJINI

JINI vs Tib/Rendezvous (2) Secure channelsBased on JavaSecurity No explicit support Recovery YesNoProcess groups Yes Reliable No Caching/Replication NoAs JavaSpace operations Locking Single processesMultiple processes MessagesMethod InvocationsTransactions Tib/RendezvousJINI

History From the people who brought you java… its JINI!

Coordination Model JavaSpaces provide temporal and referential uncoupling of processes Tuples are marshaled and stored in serialized form Each time the ‘write’ command is used on a tuple a marshaled copy is stored in the javaSpace as a tuple instance To read a tuple instance the process provides a tuple template to match against the instance stored in the javaSpace

Architecture Offers a small set of features to allow creation of dispersed applications Lowest layer: –JINI infrastructure Second Layer: –general-purpose facilities Highest Layer: –clients and servers Can be viewed as a 3-layer model

Communication Events –A client may access an event by registering with the object that owns the event –Client passes listener object –Registration leased, notifications expire –No delivery guarantees, sequence no –Client notified about particular object, passes template to id object it wishes to be notified about –First notified first to access, may remove object (read), hard to avoid

Processes (1) Implementation of a JavaSpace Good efficient distributed implementation of a JavaSpace has to solve 2 problems What is the key to this problem ? Tuples! Tuples typed Subspaces can be organised as hash tables

Processes (2) Processing on a multiprocessor Processing on a multicomputer

Processes (3) The inverse design

Processes (4) The 2 methods combined

Naming JINI does provide –JINI lookup service –leasing No conventional naming service such as is found in object- based or distributed file systems Though these can be implemented in JINI

JINI Lookup Service(1) Lookup Service JavaSpace Jini Lookup Service Registering Services

JINI Lookup Service(2) Service Identifier Service Item

JINI Lookup Service(3) Predefined Tuples

JINI Lookup Service(4) Can several Lookup Services co-exist? How is a Lookup Service looked up

Leasing A referenced object keeps track of who is referring to it This leads to what are known as reference lists Leases are used to keep the list short When a lease expires, a reference becomes invalid and is removed from the object’s reference list.

Synchronization JINI provides a number of mechanisms –JavaSpace includes the operations ‘read’ & ‘take’ –Transactions ‘read’ and ‘take’ are blocking operations They can be used to express many different synchronization patterns

Transactions Carry out operations on multiple objects Two phase commit protocol Set of interfaces The actual implementation is left to others Can be configured with default transaction manager The overall model of a transaction is shown below

Caching and Replication JINI provides no measures for caching or replication. This is left to applications that are built as part of the JINI-based system.

Fault Tolerance JINI itself has none except a transaction manager Components that implement JINI are expected to implement their own measures JINI communications is done using Java RMI which is seen to be reliable Research into adding fault tolerance has lead to the following two ideas –Incorporating fault tolerance into tuple spaces (such as JavaSpaces) –Grouping tuple space operations into transactions

Security JAAS - Java Authentication and Authorization Service Handles user authentication and authorization Separates client interface for these services from the actual services using the PAM JAAS is a java implementation of PAM JINI relies on Java RMI to provide its security JAAS has also been added to JINI

Summary Naming – yes Synchronization – sort of Caching – no Replication – nope Fault tolerance – not really Security – RMI will take care of it Basically : Awww! Can’t someone else do it