1 / 23

Replication Framework for Jini Services

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.

ailish
Download Presentation

Replication Framework for Jini Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. Lookup “Service” register Dynamic Proxy

  15. Lookup “IReplica” register Dynamic Proxy

  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: • Be an RMI based remote service. • Define a service interface. • Provide a service implementation. • Implement the callback interface.

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

  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: • Execution of the service with no failures • Execution with failing masters • 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

More Related