View
218
Download
1
Embed Size (px)
Citation preview
Replication Framework for Jini Services
Reti di Calcolatori LSa.a. 2003-2004
Jonathan Cristoforetti160789
Objective
• Creation of a prototypical framework for the replication of Jini services which:– is reusable– is based on the passive replication
model– is coherent with the Jini vision
Passive replication model
• Passive replication model– Only one replica executes (Master)– Others act as stand-by copies (Slave)
• State synchronization:– Cold stand-by– Hot stand-by
The framework replication model
• Three main aspects must be defined:
– Logical topology
– Synchronization protocol
– Failure detection mechanism
Logical topology
• Replicas are organized in a logical chain
• Communication happens only between adjacent elements
Logical Topology (2)
• Replicas organize automatically using the Jini lookup service to discover the presence of a master
Master Slave 1
Slave 2
join
ack
join
Slave 1
join
ack
• Iterative join protocol to free the master quickly
State synchronization
• Checkpoint based• The Single Fault Assumption is made
TTR < (M)TBF• The first slave is hot stand-by, the
successive are cold stand-by:
State synchronization (2)
• The complete state is transferred during each synchronization and must be encapsulated into a serializable object:
Higher bandwidth consumption Looser coupling between the
service and the framework• no information about the state internal
representation is needed by the framework
Failure detection
• Heart-beat protocol– periodical invokation of a ping-like
method on the precedin element
• Fail-stop assumption on the failure behavior– if the method invokation succeds, the
replica is working correctly
Communication protocol
• Communication based on RMI
• Four methods define in an interface called IReplica:– join– ping– activate– synchronize
The framework
• Works with Jini services which use RMI for the communication between client and server
• Classic Jini service lookup and usage:
The framework (2)
• The master replica must register by the Jini registrar and be discoverable both by the other replicas and by the service clients
Dynamic Proxy• Java Object which implements one or more
interfaces defined at runtime
The framework (3)
• Given a service interface and the relative implementation class, the framework will:– export both the service and the IReplica
interface using JERI– Combine the two RMI proxies into a
dynamic proxy– Register such proxy by the Jini registrar
Dynamic Proxy
Service Registrar
MasterJini
Client
Replica
Service
Replica
Service
register
Lookup “Service”Replica
Service
Replica
Service
Dynamic Proxy
Service Registrar
Master Slave 1
Replica
Service
register
Lookup “IReplica”
Replica
Service
Replica
Service
Replica
Service
IReplicatedServiceCallbacks
• Interface that defines the interaction protocol between framework and service
• Two methods:– getState: to obtain the service state in
order to send it as an update– updateState: to synchronize the service
state after an updated state has been received
Service requirements
• To be used with the framework a service must:
1. Be an RMI based remote service.
2. Define a service interface.
3. Provide a service implementation.
4. Implement the callback interface.
Configuration file
• Written in XML, if defines the following:
1. The complete name of the service interface
2. The complete name of the service implementation
3. The frequency of state updates, expresses in the number of service invocations after which to synchronize.
Example Services
• Sequential Number service:– Method: sequentialNumber()– State: an integer
• Bank account service:– Methods:
• GetBalance(ID)• Deposit(ID, amount)• Withdraw(ID, amount)• Transfer(IDSource, IDDest, amount)
– State: an array of Account objects
JUnit testing
• Three automated tests for each service, executed with 3 replicas:
1. Execution of the service with no failures
2. Execution with failing masters
3. Execution with failing first slaves