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