Replication & EJB Graham Morgan

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

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.

EJB elements Bean Objects Remote interface Recently renamed Component Interface Home interface Container Services PersistenceTransaction Naming EJBObjects 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. 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. Container – implements required bean properties via the use of standard services (e.g., transactions). 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 their services. The Java Naming and Directory Interface TM

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.

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

A typical scenario of clients accessing non- replicated service ClientsBean Data store

Scenario 1 – Replicated data store. CleintsBean Data store 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. Naming service Naming service plays an important role in ensuring all clients have access to a single instance of the bean.

Scenario 2 – Replicated bean. ClientsBeans Data stores 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. Container A Container B Replicating beans over different containers and different machines is desirable. Require the replication of bean components (e.g., home interface).

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

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

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.

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.

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.