JINI Coordination-Based System

1. JINICoordination-Based System By Anthony Friel * David Kiernan * Jasper Wood

2. 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 Coordination-Based Systems

3. 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 as a Coordination System

4. JINI Tib/Rendezvous Design Goal Flexible Integration Uncoupling processes Coordination Model Generative comms Publish/subscribe Network communications Java RMI Multicasting Messages Process specific Self-describing Event Mechanism Call-back service Incoming messages Processes General purpose General purpose Names Byte strings Character strings Naming Services Lookup service None JINI vs Tib/Rendezvous (1)

5. JINI Tib/Rendezvous Transactions Method Invocations Messages Multiple processes Single processes Locking As JavaSpace operations No Caching/Replication No No Reliable Yes Yes Process groups No Yes Recovery No explicit support No explicit support Security Based on Java Secure channels JINI vs Tib/Rendezvous (2)

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

7. 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 Coordination Model

8. 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 Architecture Can be viewed as a 3-layer model

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

10. 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 (1)

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

12. The inverse design Processes (3)

13. The 2 methods combined Processes (4)

14. 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 Naming

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

16. Service Identifier Service Item JINI Lookup Service(2)

17. Predefined Tuples JINI Lookup Service(3)

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

19. 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. Leasing

20. 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 Synchronization

21. 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 Transactions

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

23. 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 Fault Tolerance

24. 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 Security

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