Approaches to EJB Replication

groundcombInternet and Web Development

Oct 31, 2013 (3 years and 11 months ago)

87 views

Approaches to EJB Replication

Overview


J2EE architecture


EJB, components, services


Replication


Clustering, container, application


Conclusions


Advantages and disadvantages of approaches


J2EE Architecture (Multi tier approach)


The J2EE application model implement
s

a multi
-
tier service in two
parts: business and presentation logic

supplied
by the developer, and
the standard system services provided by the J2EE platform
.



Components are located in the application server and provide the
business logic of an application (using a data store
accessed via EIS
to
enable persistence)

Application layer


Containers



Manages client/component communications and enhances
components, as specified by developers, with properties derived from
services. For example, containers may enhance a component with transaction
qualities.


Components



An Enterprise Java Bean (EJB) represents a component in the
J2EE architecture. An EJB may provide an interface for use by clients (made
available via container and naming service) that represent the business logic
of an application.


Services



Eases the development of applications by enhancing components
(via containers) with qualities derived from existing library code.


Server



Supports the execution of components
via the provision of a multi
-
process/threaded
environment (may run as a single process in some
vendor implementations) and mediates application
access to
services
.

EJBs


Session



Session beans are executed on behalf of a single
client and exist for the period of execution required to
satisfy a single client session.


Entity



Provides an object view of persistent data
associated with an application (stored in a database).
Persistence may be container managed (releasing
developer from integrating database related code in their
business logic) or explicitly managed by the entity bean
itself (requiring developer to describe database interaction
within their business logic).


Message Driven



Provides, with the aid of the Java
Messaging Service (JMS), asynchronous inter
-
EJB
communications.

Approaches to replication

1.
Clustering



Application servers are replicated
over different nodes with replication of backend
database supported by propriety techniques.

2.
Container



Replication mechanisms are
introduced into the wrapper code generated by the
container vendor’s tools.

3.
Application



Replication mechanisms are
deployed as EJBs. No alteration required to
automatically generated code
(wrapper code)
.


Typical Replication Scheme

Clustering


The clustering is the
common

approach

for application
server replication and is primarily used for load balancing.


A
Local Server Load Balancer (incorporating
Network
Address Translator (NAT)
)

distributes a client session to
a replica
.


NATs
must be

capable of
identifying when a replica has
failed

and
must

roll back a failed session, without the
knowledge of the client, and restart a client session on a
correctly functioning replica.



Database replication

must

be handled separately to that
of application server replication by some propriety
replication scheme provided by database vendors.


Clustering


some problems


Interaction across different application servers may result in multiple
session instances and undesired repeated database updates.


This problem would not arise if end
-
to
-
end transactions were used
across application servers (as session B would have rolled back and not
updated the database due to failure of application server R1).


Lack of end
-
to
-
end transactions and/or
JMS type bean interactions
may

result in an inability to
roll back some sessions (e.g., session B above).

Container

Container


some problems


Container tool suitable for producing the wrapper code for
“hooking” services into EJBs to enable replication are
required.


If the tool is to be written “from scratch” other services required by
an EJB must be considered.


Wrapper objects may be written with specific server types
and or services in mind.


This is not a problem in many cases as the container vendor and
the EJB server vendor are usually the same.

Application (1)


Client interaction

Application (2)


Agreement on replicated
databases

Application (3)


Agreement of third
party application servers


To prevent duplicate instantiation of sessions
,
a single EJB replica
should assume responsible for communications with EJBs that are
beyond the scope of the replication scheme
.


Without

the ability to intercept inter
-
EJB communications via wrapper
objects, the use of proxy objects is required


Application


some problems


The need for proxy objects increases the volume of EJBs
required.


Performance issues may be raised.


The deployment of a replication service becomes non
-
transparent to the developer.


In the container approach replication may be specified in the
deployment descriptor, it is now an application level issue.

Conclusions


Server approach


Easy to deploy and maintain.


Unable to satisfy application requirements when there is a lack of end
-
to
-
end transactions (possibly due to JMS and/or third party interaction).


Container approach


Can provide solutions to the problems encountered due to the lack of
end
-
to
-
end transactions exhibited by server approach.


Standard way of enhancing EJBs with services.


Application approach


As with container approach, may provide more appropriate solution than
server approach.


Difficult to ensure transparency of service and may be difficult to deploy
and maintain.



A major problem for all approaches is the lack of fail over
capabilities at the client side in Java RMI.


This is required to make replication scheme transparent.