1. Replication Framework for Jini Services Reti di Calcolatori LS a.a. 2003-2004 Jonathan Cristoforetti 160789

2. 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

3. Passive replication model –Only one replica executes (Master) –Others act as stand-by copies (Slave) State synchronization: –Cold stand-by –Hot stand-by

4. The framework replication model Three main aspects must be defined: –Logical topology –Synchronization protocol –Failure detection mechanism

5. Logical topology Replicas are organized in a logical chain Communication happens only between adjacent elements

6. Logical Topology (2) Replicas organize automatically using the Jini lookup service to discover the presence of a master MasterSlave 1Slave 2 join ack join Slave 1 join ack Iterative join protocol to free the master quickly

7. 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:

8. 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

9. 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

10. Communication protocol Communication based on RMI Four methods define in an interface called IReplica: –join –ping –activate –synchronize

11. The framework Works with Jini services which use RMI for the communication between client and server Classic Jini service lookup and usage:

12. 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

13. 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

14. Dynamic Proxy register Lookup “Service”

15. Dynamic Proxy register Lookup “IReplica”

16. 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

17. 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.

18. 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.

19. Implementation

20. 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

21. 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

22. JUnit results

23. Future developments Support for more policies defined via configuration files Support for partial state synchronization Support for active replication