Post on 09-Jan-2016
description
JINICoordination-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 purposeGeneral purposeProcesses
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 supportNo explicit supportRecovery
YesNoProcess groups
YesYesReliable
NoNoCaching/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