Approaches to EJB Replication

1. Approaches to EJB Replication

2. Overview • J2EE architecture • EJB, components, services • Replication • Clustering, container, application • Conclusions • Advantages and disadvantages of approaches

3. J2EE Architecture (Multi tier approach) • The J2EE application model implements 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)

4. Application layer • 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. • 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.

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

6. Approaches to replication • Clustering – Application servers are replicated over different nodes with replication of backend database supported by propriety techniques. • Container – Replication mechanisms are introduced into the wrapper code generated by the container vendor’s tools. • Application – Replication mechanisms are deployed as EJBs. No alteration required to automatically generated code (wrapper code).

7. Typical Replication Scheme

8. Clustering • The clustering is the commonapproach 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 replicationmust be handled separately to that of application server replication by some propriety replication scheme provided by database vendors.

9. 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).

10. Container

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

12. Application (1) – Client interaction

13. Application (2) – Agreement on replicated databases

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

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

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