Transcript Jini - MASTERRAGHU

JINI
Coordination-Based System
By
Anthony Friel * David Kiernan * Jasper Wood
Coordination-Based Systems
• If a distributed system
• New generation of
is seen as a collection
distributed systems
of processes a
that assume that the
coordination-based
components of the
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)
Design Goal
Coordination Model
Network
communications
Messages
Event Mechanism
Processes
Names
Naming Services
JINI
Tib/Rendezvous
Flexible Integration
Generative comms
Java RMI
Uncoupling processes
Publish/subscribe
Multicasting
Process specific
Call-back service
General purpose
Byte strings
Lookup service
Self-describing
Incoming messages
General purpose
Character strings
None
JINI vs Tib/Rendezvous (2)
JINI
Transactions
Tib/Rendezvous
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
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
• Lowest layer:
– JINI infrastructure
• Second Layer:
• Offers a small set
of features to
allow creation of
dispersed
applications
Can be
viewed as
a 3-layer
model
– general-purpose facilities
• Highest Layer:
– clients and servers
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
• What is the key to this
problem ? Tuples!
• Good efficient
distributed
implementation of a
JavaSpace has to solve
2 problems
• 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
• No conventional
naming service such as
is found in objectbased or distributed
file systems
• Though these can be
implemented in JINI
• JINI does provide
– JINI lookup service
– 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
• 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
• 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
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