final Year Projects, Final Year Projects in Chennai, Software Projects, Embedded Projects, Microcontrollers Projects, DSP Projects, VLSI Projects, Matlab Projects, Java Projects, .NET Projects, IEEE Projects, IEEE 2009 Projects, IEEE 2009 Projects, Software, IEEE 2009 Projects, Embedded, Software IEEE 2009 Projects, Embedded IEEE 2009 Projects, Final Year Project Titles, Final Year Project Reports, Final Year Project Review, Robotics Projects, Mechanical Projects, Electrical Projects, Power Electronics Projects, Power System Projects, Model Projects, Java Projects, J2EE Projects, Engineering Projects, Student Projects, Engineering College Projects, MCA Projects, BE Projects, BTech Projects, ME Projects, MTech Projects, Wireless Networks Projects, Network Security Projects, Networking Projects, final year projects, ieee projects, student projects, college projects, ieee projects in chennai, java projects, software ieee projects, embedded ieee projects, "ieee2009projects", "final year projects", "ieee projects", "Engineering Projects", "Final Year Projects in Chennai", "Final year Projects at Chennai", Java Projects, ASP.NET Projects, VB.NET Projects, C# Projects, Visual C++ Projects, Matlab Projects, NS2 Projects, C Projects, Microcontroller Projects, ATMEL Projects, PIC Projects, ARM Projects, DSP Projects, VLSI Projects, FPGA Projects, CPLD Projects, Power Electronics Projects, Electrical Projects, Robotics Projects, Solor Projects, MEMS Projects, J2EE Projects, J2ME Projects, AJAX Projects, Structs Projects, EJB Projects, Real Time Projects, Live Projects, Student Projects, Engineering Projects, MCA Projects, MBA Projects, College Projects, BE Projects, BTech Projects, ME Projects, MTech Projects, M.Sc Projects, Final Year Java Projects, Final Year ASP.NET Projects, Final Year VB.NET Projects, Final Year C# Projects, Final Year Visual C++ Projects, Final Year Matlab Projects, Final Year NS2 Projects, Final Year C Projects, Final Year Microcontroller Projects, Final Year ATMEL Projects, Final Year PIC Projects, Final Year ARM Projects, Final Year DSP Projects, Final Year VLSI Projects, Final Year FPGA Projects, Final Year CPLD Projects, Final Year Power Electronics Projects, Final Year Electrical Projects, Final Year Robotics Projects, Final Year Solor Projects, Final Year MEMS Projects, Final Year J2EE Projects, Final Year J2ME Projects, Final Year AJAX Projects, Final Year Structs Projects, Final Year EJB Projects, Final Year Real Time Projects, Final Year Live Projects, Final Year Student Projects, Final Year Engineering Projects, Final Year MCA Projects, Final Year MBA Projects, Final Year College Projects, Final Year BE Projects, Final Year BTech Projects, Final Year ME Projects, Final Year MTech Projects, Final Year M.Sc Projects, IEEE Java Projects, ASP.NET Projects, VB.NET Projects, C# Projects, Visual C++ Projects, Matlab Projects, NS2 Projects, C Projects, Microcontroller Projects, ATMEL Projects, PIC Projects, ARM Projects, DSP Projects, VLSI Projects, FPGA Projects, CPLD Projects, Power Electronics Projects, Electrical Projects, Robotics Projects, Solor Projects, MEMS Projects, J2EE Projects, J2ME Projects, AJAX Projects, Structs Projects, EJB Projects, Real Time Projects, Live Projects, Student Projects, Engineering Projects, MCA Projects, MBA Projects, College Projects, BE Projects, BTech Projects, ME Projects, MTech Projects, M.Sc Projects, IEEE 2009 Java Projects, IEEE 2009 ASP.NET Projects, IEEE 2009 VB.NET Projects, IEEE 2009 C# Projects, IEEE 2009 Visual C++ Projects, IEEE 2009 Matlab Projects, IEEE 2009 NS2 Projects, IEEE 2009 C Projects, IEEE 2009 Microcontroller Projects, IEEE 2009 ATMEL Projects, IEEE 2009 PIC Projects, IEEE 2009 ARM Projects, IEEE 2009 DSP Projects, IEEE 2009 VLSI Projects, IEEE 2009 FPGA Projects, IEEE 2009 CPLD Projects, IEEE 2009 Power Electronics Projects, IEEE 2009 Electrical Projects, IEEE 2009 Robotics Projects, IEEE 2009 Solor Projects, IEEE 2009 MEMS Projects, IEEE 2009 J2EE P

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

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

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