FOUNDATIONS OF DISTRIBUTED SYSTEMS

Aim:

The purpose of this assignment is to exemplify and explore some important issues of replication. This assignment requires an understanding of the basics of remote procedure calling and replication.

Method: students will attempt this assignment individually.

In Assignment, we have implemented a Tram Tracking service using a model similar to the one shown in the following diagram:

In this assignment you will extend the Assignment 1 model above to support active replication. For that purpose, this assignment requires you to add:

a) Three Replica Manager (RM) for the server component that tracks locations of trams and

b) A server Front End (FE) with which Tram clients will communicate using RMI. The FE will forward remote method calls to all available RMs and forward results back to Tram clients using RMI.

The new system architecture is shown in the following diagram:

Front End (FE) hides replication management from the client, communicates with one or more Replica Managers, provides replication transparency. Each RM is a replication of the Tram Tracking server, process incoming requests independently but identically.

System requirements:

- The Trams will only communicate with the server Front End via RMI using the Remote interface shown in the diagram above.

- The system consists of three Replica Managers. Each RM is a replication of the Tram Tracking server to provide communication with server FE via RMI using the same Remote interface shown in the diagram above.

o In this assignment, FE and RMs are all running on localhost, but at different ports (in reality, they can run on different servers having different IP addresses and ports)

- The FE must always be running and at least one RM will be running at any given time to provide fault tolerance.

- When a Tram makes a remote method call to the server Front End:

1. FE will first call a listTramService() method to find out which RM is running. The results of this listTramService() call should also be printed out on the Console of the FE, for example: RM1 on | RM2 off | RM3 on.

2. For each RM that is running, the FE will call the corresponding remote method on that RM, passing the input Message object and receiving a return Message object from that RM. Then the FE will forward that returned Message object to the Tram client. All of this will be performed using RMI as shown in the above diagram.

- While the system is running, at most 2 RMs can be killed and the system should continue simulating the tram movement as usual.

What to demonstrate

Demos will be running in Week 11 and 12 in the labs. No concurrency control needs to be implemented, so users can interfere with each other's operations in a way that leads to error conditions, as allowed by the Unix file system.

You need to demonstrate the system with one server FE, three RMs and several Trams running at the same time. You will need to show service continuity in presence of failure: two RMs will be killed and the system should continue simulating the tram movement.

Acronyms: Replica Manager (RM), Server Front End (FE), Tracking Service (TS)

Server Components

- Implementation of 3 Replica Manager classes

o Alternatively, you can have 3 RM objects created from the same RM class running on 3 different RMI registries
- Implementation of the Server Front End class
- The FE object and the 3 RM objects must be registered on different RMI registries running on localhost but at different ports

o totally 4 RMI registries will be used, one registry for the FE to register and each RM registers to a different registry
- The listTramService() method is implemented as a local method in the FE class (5 marks)
- The FE will not do any major Tram Tracking task. FE will only do the following tasks: listTramService
(check which RM is available), multicast remote method requests to available RM, send returned results to

Tram clients
- All the tasks in FE (for example identify the registry, identify the remote servers, checking which RM and
server are working/not working) are separated into methods. (5 marks)

Client Component
- Many instances of the Tram class can be run simultaneously using multithreading (between each update
request, each tram client sleeps for a time interval that randomly varies between 10 to 20 seconds) (5 marks)
- Tram clients only communicate with the Server Front End (5 marks)

Functionalities
- Each RM can be started and stopped when your application is running without interrupting your application (all Exceptions are caught correctly)

o While the system is running, at most 2 RMs can be killed and the system should continue simulating the tram movement as usual.

- Whenever a Tram client invokes a remote method on the FE, the FE will first invoke its listTramService() method locally to find out which RM is running. The results of this listTramService() call must be printed out on the Console of the FE, for example: RM1 on | RM2 off | RM3 on.

- After running the listTramService(), for each RM that is running, the FE will call the corresponding remote method on that RM, passing the input Message object and receiving a return Message object from that remote method call. So FE will multicast remote method calls to all available remote RM objects. Then the FE will forward only one returned Message object to the Tram client.

Other Requirements

- Methods in the Remote interfaces only accept input arguments of type Message and return an object of type Message. Marshalling and unmarshalling operations must be applied as in Assignment 1

- All exceptions are caught and handled correctly. At least the following types of exception must be caught: RemoteException, NotBoundException, Exception.

- All source codes are given detailed comments and formatted properly