"Jini Coordination Based System"
JINI Coordination-Based System By Anthony Friel * David Kiernan * Jasper Wood Coordination-Based Systems • New generation of • If a distributed system distributed systems is seen as a collection that assume that the of processes a components of the coordination-based system handles the system are distributed communications and and that the problem cooperation between lies in the coordination the processes while the of the activities of the processes handle the components 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) JINI Tib/Rendezvous Design Goal Flexible Integration Uncoupling processes Coordination Model Generative comms Publish/subscribe Network Java RMI Multicasting communications 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 (2) JINI Tib/Rendezvous Transactions Method Invocations Messages Multiple processes Single processes Locking As JavaSpace No operations Caching/Replication No No Reliable Yes Yes Process groups No Yes Recovery No explicit support No explicit support Security Based on Java Secure channels History From the people who brought you java… its JINI! Coordination Model • JavaSpaces provide • To read a tuple instance temporal and referential the process provides a uncoupling of processes tuple template to match • Tuples are marshaled against the instance stored in the javaSpace 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 Architecture • Lowest layer: – JINI infrastructure • Second Layer: • Offers a small set – general-purpose facilities of features to • Highest Layer: allow creation of – clients and servers dispersed applications 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 • What is the key to this JavaSpace problem ? Tuples! • Good efficient • Tuples typed distributed implementation of a • Subspaces can be JavaSpace has to solve organised as hash 2 problems tables Processes (2) • Processing on a multiprocessor • Processing on a multicomputer Processes (3) • The inverse design Processes (4) • The 2 methods combined Naming • No conventional naming service such as is found in object- based or distributed file systems • JINI does provide • Though these can be – JINI lookup service implemented in JINI – leasing 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 • When a lease expires, a reference becomes • This leads to what are invalid and is removed known as reference from the object’s lists reference list. • Leases are used to keep the list short Synchronization • JINI provides a number • ‘read’ and ‘take’ are of mechanisms blocking operations – JavaSpace includes the • They can be used to operations ‘read’ & express many different ‘take’ synchronization – Transactions patterns Transactions • Carry out operations on multiple objects • The overall model of a • Two phase commit transaction is shown protocol below • Set of interfaces • The actual implementation is left to others • Can be configured with default transaction manager 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 • Research into adding except a transaction fault tolerance has lead manager to the following two • Components that ideas implement JINI are – Incorporating fault expected to implement tolerance into tuple their own measures spaces (such as JavaSpaces) • JINI communications – Grouping tuple space is done using Java operations into RMI which is seen to transactions be reliable Security • JINI relies on Java RMI to provide its security • JAAS has also been added to JINI • 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 Summary • Naming – yes Basically : • Synchronization – sort of • Caching – no Awww! • Replication – nope Can’t someone else • Fault tolerance – not really do it • Security – RMI will take care of it