Replication & EJB

1. Replication & EJB Graham Morgan

2. EJB goals • Ease development of applications • Hide low-level details such as transactions. • Provide framework defining the handling of clients, servers and components. • Promote a standard way for client/server applications to be built. • EJB components should run in any EJB-compliant server. • JavaBeans are components but differ from EJBs as containers and “higher level” documentation are not addressed by JavaBeans specification. • JavaBeans are accommodated by infrastructures supported by vendors (e.g., drag and drop development environments (such as Delphi).

3. Components, containers, servers • Component • Java class that implements “business logic”. • Container • Hosts components (possibly multiple instances). Enhances components with services such as transactions and persistence (depending on the requirements of the components). • For example, if transaction is to be aborted the container assumes responsibility for the abort. • Server • Hosts containers. Makes available services to containers.

4. EJBObjects – delegates client requests to EJB instances. Wrapper functions may allow container to provide additional services (e.g., transactions). RMI used to enable client communication. Generated automatically by vendor tools. EJB elements Home interface – provides lifecycle type services on a per class basis and lookup methods for locating existing beans within a container. Implementation generated by vendor tools. EJBObjects Container – implements required bean properties via the use of standard services (e.g., transactions). Container Bean Objects Home interface Container vendor – provides deployment tools to automatically generate EJBObjects to enable successful integration of beans with required services. Naming - consists of an API and an SPI (Service Provider Interface). The SPI enables a variety of naming and directory services to be plugged in transparently, allowing the Java application using the API of the JNDI technology to access theirservices. Remote interface Recently renamed Component Interface Persistence Transaction Naming Services The Java Naming and Directory InterfaceTM

5. Exploiting mechanisms provided by transaction and group services for replication of beans. • Transaction service • Recovery – ensure shared information on stable store is manipulated consistently despite failures. • Concurrency control – a replica group may be locked for write access only. Assuming deterministic machine approach to replication, states of replicas will not deviate. • Group service • Failure suspicion – identifying failure and making it possible to reattempt an aborted transaction in a transparent manner to the client. • Atomic multicast – ensuring all or zero members of a replica group receive a multicast. Required to ensure all members of a group are write locked.

6. C1 C1 C2 C3 C2 Replication & transactions Objects Data stores Data stores Object End-to-end transaction Replicated objects and data stores - can still commit if a replica succeeds.

7. A typical scenario of clients accessing non-replicated service Clients Bean Data store

8. Naming service Scenario 1 – Replicated data store. Cleints Bean Availability is limited as availability of service dependent on availability of single bean. When bean fails another entity bean may be instantiated (possibly on another server if required) to continue serving clients. Data store Naming service plays an important role in ensuring all clients have access to a single instance of the bean.

9. Scenario 2 – Replicated bean. Clients Beans Possibility of speedier reply to client as availability higher. Opportunity for greater number of entity replicas than data stores. Transaction may commit as long as a bean succeeds. Data stores Container A Replicating beans over different containers and different machines is desirable. Require the replication of bean components (e.g., home interface). Container B

10. R1 R2 Initial implementation – concentrating on the beans. • Client access issues: • alter the EJBobject code (client side) to enable automatic reissue of bind request to naming service if current object binding fails or • enable multicast (transparent to client application) of client request to all replicas. Requires callback to client when group membership changes occur. Parse the EJBobject code (via tool or manually) and insert replication mechanism that intercepts client request and provides required replication scheme. EJBObjects Bean Objects Client request • Administration issues: • replication requirements may be described in a beans deployment descriptor. • containers providing replication schemes may provide a tool allowing the management of a system during runtime. Inter-object group communications

11. Providing a replication enabled container EJBObject Bean M1 –interception of original client request. M2 – required message passing for ensuring replication policy. M3 – further message passing to fulfill requirements. M3 M1 Container M2 Transactions Group Comms We assume EJB server resides on a single node and has access to services to ensure replication policies may be achieved. Naming Services EJB Server

12. Bean location and discovery issues • To ensure success of replication scheme all elements of EJB (including clients) must have access to a highly available naming service. • Clients may need to rebind when failure occurs and this is not possible if failure occurs in the naming service and naming service is single point of failure. • Naming service itself requires replication over a number of nodes. • This is complicated by the presence of the home interface which is designed for locating specific instances of beans in containers. • Agreement must be reached on what beans to interact with. For example, assume passive replication (primary and backups). Naming service must always provide name of the same primary to all clients.

13. Other considerations • How do we handle beans that make use of asynchronous messaging? • Example - when a client buys a book, an inventory bean could notify an ordering bean of a low stock situation. This notification may be asynchronous, freeing the client from having to wait while reordering operation completes. • How do we generate the code? • There needs to be some tool that provides code/wrapper objects for replicated beans. In essence, we provide a replication enabled container. However, how do we provide administrative support at run-time for our service? • Do we treat entity and session beans differently? • Entity beans are long lived persistent components that may have many clients whereas session beans are short lived non-persistent components that exist on a per-client basis.

14. Conclusions • Good opportunity to exploit both transactions and group communications to provide replication at the component level. • Bean location and discovery looks to be a problem. • Will have to automatically generate code “container style”. • Providing runtime administration support does not look easy. • Require further investigation into specific replication schemes (active & passive). • Providing EJB replication appears to be more challenging that first thought.