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.

Implementation

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

JUnit results

Future developments

• Support for more policies defined via configuration files

• Support for partial state synchronization

• Support for active replication