230 likes | 362 Views
Replication Framework for Jini Services. Reti di Calcolatori LS a.a. 2003-2004 Jonathan Cristoforetti 160789. 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.
E N D
Replication Framework for Jini Services Reti di Calcolatori LS a.a. 2003-2004 Jonathan Cristoforetti 160789
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
join Master ack join join Slave 1 ack Slave 1 Slave 2 Logical Topology (2) • Replicas organize automatically using the Jini lookup service to discover the presence of a master • 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
Lookup “Service” register Dynamic Proxy
Lookup “IReplica” register Dynamic Proxy
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: • Be an RMI based remote service. • Define a service interface. • Provide a service implementation. • Implement the callback interface.
Configuration file • Written in XML, if defines the following: • The complete name of the service interface • The complete name of the service implementation • 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: • Execution of the service with no failures • Execution with failing masters • Execution with failing first slaves
Future developments • Support for more policies defined via configuration files • Support for partial state synchronization • Support for active replication