Replication EJB Graham Morgan EJB goals Ease development

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. • Java. Beans are components but differ from EJBs as containers and “higher level” documentation are not addressed by Java. Beans specification. – Java. Beans 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.

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 Bean Objects Home interface 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 Remote interface Recently renamed Component Interface Persistence Naming Transaction Services The Java Naming and Directory Interface. TM 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.

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 Data stores C 1 Object C 2 C 1 Objects Data stores C 2 C 3 End-to-end transaction Replicated objects and data stores - can still commit if a replica succeeds.

A typical scenario of clients accessing nonreplicated service Clients Bean Data store

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

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

Initial implementation – concentrating on the beans. Client access issues: Parse the EJBobject code (via tool or manually) and insert replication mechanism that intercepts client request and provides required replication scheme. EJBObjects Client request Bean Objects (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. R 1 Administration issues: Inter-object group communications R 2 (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.

Providing a replication enabled container EJBObject Bean M 1 –interception of original client request. M 2 – required message passing for ensuring replication policy. M 3 M 1 M 3 – further message passing to fulfill requirements. Container M 2 Transactions Naming Group Comms Services EJB Server 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.