DYNAMIC SERVER
REPLICATION
This project will be able to dynamically replicate a given server object when
needed, as many times as is required, as well as shut down replicas when they
are no longer required, without client applications needing to be aware of the
replication that will take place.
The project will be in the form of a framework which an existing server, with some
amount of modification, will be able to attach to and make use of. The framework
will then take care of the replication process and the management of all
replicated servers, while maintaining data consistency.
The project will involve designing, implementing and testing the proposed
system, and writing a report about the project. The product of this project will be
a set of middleware objects forming an API which existing servers can use to
allow themselves to be dynamically replicated.
Many servers today need to give a highly available service – that is, be able to
service large amounts of clients quickly. A common solution to this problem is to
make copies of the server software and its data.
The number of these replicated servers is generally fixed, unless administrators
create a new clone (which involves shutting the system down while it is
reconfigured).
This means that server availability is sometimes still not high enough, even using
some replicas, and sometimes too high, such that some replicas are barely used.
In this latter scenario, where replicas are underused, this still impacts system
performance because these servers are still required to communicate with other
servers in the group.
The system proposed in this report intends to solve this problem by allowing
servers to be dynamically replicated in a running system, on demand, and for
servers to be shut down when not required, according to the amount of clients
connected at a particular time, the server load that clients are creating, and any
other factors that the server application may wish to take into account.
This project aims to produce a framework of components, an API, which server
applications can use to allow themselves to be replicated. The framework will
allow servers to specify the availability and speed of service they wish to provide
against the fault tolerance (data consistency) that they require.
The middleware will take these requests into account and replicate the server
when necessary, using methods appropriate to meet the requirements set by the
server application in terms of speed and data consistency. The process of
replication should not be visible to the client, allowing existing clients to connect
to servers without modification.
Server application objects in this system will be replicated on the same physical
computer. If there is sufficient time, a further aim is to allow replication on
different physical machines. This system will be implemented and tested as part
of the proposed project.

Replication
Replication is a well studied area of computing, with several established
architectures to solve the problem. These include gossip, Bayou, and the concepts
of read one/write all and passive and active replication.
Generally, the more highly available a replication model is, or the faster it needs to
process client transactions, the less fault tolerant it will become, where absolute
data consistency may be lost.
A general model of replication is shown in figure 1, and contains a client, front end
(FE), and three replica managers (RM). The client communicates only with the
front end, providing replication transparency. Each client has its own front end.
The replication technique then depends on how the replica managers are used,
and the communication semantics between the front end and the replica group
RM
Client FE
RM RM
Replication
The Proposed Project
The project aims to create a framework capable of dynamically replicating a given
server object. More detailed aims are given in the following subsection.
Core aims
• To develop reusable middleware that can dynamically replicate a server
application, provided that the server implements any necessary interfaces.
• The server environment will be dynamically reconfigured through replication
when needed. The deciding factors on when to create a replica of the server
should be modifiable by the server application.
• A server application using the framework should be able to set parameters for
replication in regard to the desired level of consistency against the level of
performance offered to clients.
• Replication should be transparent to the client; existing clients should be able
to be used with no modification. Their view will be of a single server object.
Desirable aims
• Support physically distributed server replicas (on different computers).
• Add a performance evaluation system, to report on relative
benefits/drawbacks of replication in fault tolerant and highly available
configurations, based on throughput and response time to clients.

APPROACH
An incremental approach will be taken to design and implement the proposed
system. A gossip style of system will be developed that supports a fixed number
of replicas, implementing fault tolerance in a fixed scheme. The gossip
architecture is the most flexible of the established algorithms for replication. It
can effectively imitate many other replication models.
When this system is completed, dynamic replication support will be added to the
framework, and servers will be able to set parameters for levels of fault tolerance
and performance, as well as options defining when the framework should create a
new replica or remove an existing one.
At this point, allowing different replication architectures will need to be
considered; the system will be adapted so that a separate module governs the
replication model, allowing different models to be added and used as necessary.
This approach has been chosen so that the core elements of the proposed
project can be implemented first, allowing a working system to be created early in
the implementation process. Additional services and objects may be added once
the main components of the framework are in place.
The Java technology RMI (Remote Method Invocation) will be used to implement
the distributed system. RMI is a framework from JavaSoft which allows methods
in distributed objects to be called as if they were residing in local memory,
handling sockets and issues of serialization of objects and other communication
tasks automatically
SYSTEM CONFIGURATION
HARDWARE CONFIGURATION
Processor - Pentium – IV
Speed - 2.4 Ghz
RAM - 256 MB
Hard Disk - 20 GB
Key Board - Standard Windows Keyboard
Mouse - Two or Three Button Mouse
Monitor - Color Monitor
SOFTWARE CONFIGURATION
Operating System - Windows 2000/XP
Front End - JAVA, JAVA RMI
Back End - MS-SQL Server
Connectivity - JDBC Connectivity
Web Design - HTML, JSP