High–Available Enterprise JavaBeans Using Group ... - CiteSeerX

High–Available Enterprise JavaBeans Using Group Communication System Support Marcia Pasin1

Michel Riveill2*

Taisy Silva Weber

Instituto de Inform tica – Universidade Federal do Rio Grande do Sul Caixa Postal 15064 – CEP 91501–970 Porto Alegre – Brazil *

Universit de Nice – Sophia Antipolis Ecole Sup rieure en Sciences Informatiques 930 route des Colles – BP 145 – 06903 Sophia Antipolis Cedex – France

Abstract The Enterprise JavaBeans (EJB) architecture provides a structure to build scalable and distributed applications, based on transactions. Despite of the transactional service, if the server crashes, the EJB will be unavailable. The EJB could be recovered when the server restarts up. Its availability is restricted. High– available systems require fast recovery time that can be easily implemented using replication: if the current replica crashes there is another to replace it. Replicas require special protocols to synchronize them and group communication provides suitable primitives to develop reliable distributed applications as well synchronizing replicas even in presence of failures and client’s concurrent access. Although these computational models (group communication and transactional, that the EJB follows) are claimed to be opposite by some authors, others agree that it can be matched. In this paper we will show how a group communication system can allow an efficient and high–available EJB service using replicas. The replication approach is totally hidden to users and we expect to reduce the replication overhead using appropriate design decisions.

Keywords – Distributed systems, group communication, high–available service, Enterprise JavaBeans

1 Introduction The Enterprise Java Beans (EJB) [4] architecture is a server–side technology for developing and deploying components containing the business logic to enterprise distributed applications. EJB components are scalable, transactional and multi–user secure. The EJB specification describes a runtime environment and a programmer’s guide and user’s guide explaining how an EJB should be developed, deployed and used. The runtime environment is the EJB server, which provides access to EJB using an execution environment with transactional service, distribution mechanisms, persistence management and security. The specification allows users create its EJB applications, freeing them from low–level system these details. There are two kinds of EJB: session beans and entity beans. Session beans usually exist only for the duration of a single client–server session and are called transitory beans. A session bean executes operations such as calculations, FTP downloads or accessing a database for the client. Entity beans are persistent objects associated with a database. EJB use transactions to ensure that only consistent states take place despite of client’s concurrent access and failures. However, if the EJB server crashes the service will be unavailable because the objects’ state cannot be accessed. It will just be available when the EJB server restarts up. Transactions properties (atomicity, consistency, isolation and durability) are insufficient to provide a high–available service that requires replication. Replicating the service using multiples nodes provides another instance if the current replica was crashed.

1 2

Ph.D. student sponsored by CNPq/Brazil under grant 200594/00-1 work partially sponsored by the French Ministry of Research (RNTL project ARCAD)

Replication requires synchronizing replicas, even in the presence of client’s concurrent access and node crashes. It can be easily done using group communication primitives [3]. Although these computational models (group communication and transactional) seem to be opposite, we agree with some authors that believe that group communication and transactions can be matched [5, 6 and 7]. Our approach uses group communication to provide an efficient and high–available EJB service as a new property to the current EJB specification: the replication approach is hidden to users and the overhead, generated by the replica synchronization, is reduced using suitable design decisions. Our approach is based on a group communication primitive called total order multicast [3]. This primitive enables a client sending messages to a group of process (replicas), with the guarantee that all processes agree on the set and on the order that the messages will be delivered. Group communication primitives allow good throughput and response time under replicated database systems [7]. This is sufficient to justify using group communication support to implement replicated EJB. Group communication is not supported in EJB current specification: clients and EJB servers use point–to–point communication. An EJB is mainly composed by the EJB object, the interfaces (home and remote), classes and an instance (i.e., its state). All EJB are kept in and managed by containers. The objects and its structure, including the container, correspond to the replication unit (or replica for short). We believe that the whole object is a good replication unit because replicating just some components does not provide high availability and can decrease the performance to glue the components. We do not want to degrade excessively the expected performance of EJB applications neither change the conventional approach to generate such applications: the user can build its application in the usual way. The decision to use replicas is done when he or she starts several EJB server instances using multiple nodes in deployment time. The paper is organized as follows. In the section 2, we present the distributed system model and group communication concepts. In the section 3, we describe how the replicated EJB are been developed. In the section 4, we compare our work with other systems and briefly discuss correlated works. The paper ends with concluding remarks and research perspectives.

2 Distributed system model and group communication concepts Group communication comprises both concepts [1]: reliability and membership. Reliability includes retransmission of missing messages, fragmentation of large messages into smaller ones and reassembly at the receiver's side, ordering of messages (FIFO order) and atomicity. This is implemented by the total order multicast and view synchronous multicast primitives [3]. Group membership includes knowledge of who the members3 of a group are and notification when a new member joins, or when an existing member leaves or has crashed. Group membership service handles process’ operations such as joining and to leaving a group, and ensures that processes agree on the current membership of the group. A process can leave a group by failure or by itself. In theory, group membership cannot be applied in asynchronous systems4 with even a single crash failure. In practice, this problem can be solved using a failure detector with weak completeness (every crashed member is eventually suspected by some other correct member5) and eventual weak accuracy (there is a time, after which, there is a correct member that is not fault– suspected) properties [3]. An underneath GCS (group communication system) [1] provides group communication primitives as well as fault–suspected members detection removing them from the group. To become a member, a process executes the join primitive. A member executes the leave primitive to leave a group. Each time a process join or leaves a group, a new view must be installed. A view is a distributed message that describes all group members. After a member leaves the group, it can 3 4 5

all groups are composed by components called members it cannot distinguish with accuracy between overload and faulty processes; the processes are assumed to be fault–suspected a correct member behaves according to its specification

rejoin the group executing the join primitive again. When a new view is about to be installed, the GCS automatically selects one of the group members to be the coordinator. The coordinator can multicast a view message to all members included in the new view. All members (servers) can provide the same service (to access or to update the same replicated objects in a fully–replicated database system) to non-members (clients). To enable read one write all replicas, strong consistency is required and can be applied using active replication or primary– backup replication [3]. Active replication is founded by all replicas playing the same rule. To execute a method, a process uses the total–order multicast primitive [3] to send an invocation to all replicas in the group. Each replica executes the local method and sends back their result to the requester that typically waits for the first answer. Failed replicas are transparent to the requester: they do not process anything and do not send results to clients. Determinism is the drawback of the active replication. It requires that, to the same input in the same order, replicas will produce the same output. The total–order multicast primitive assures determinism using the order and atomicity primitives. In the primary–backup (or passive) replication, requesters send their messages to a replica that is called primary. The primary executes the service and sends update’s messages (using multicast) to the other replicas that are called backups. To improve performance, the backups do not execute the invocation, but apply changes (i.e., updates) produced by the invocation execution at the primary. Typically, the primary waits for all backups’ answers and returns response to the requester. Determinism is not necessary on the execution of invocations because the primary orders all requests. However, if the primary crashes, backups must select a new primary and an inconsistent state can happen if the updates are not finished in all backups. The view synchronous multicast primitive [3] guarantees a consistent state to all replicas even in presence of failures. Mixing active replication and primary-backup replication The embedded GCS [1] uses closed groups6, which makes primary–backup replication more attractive than active replication. Active replication requires each process joining the group to request a service and after leaving the group, when the service is not more necessary. Joining and leaving is required because the requester must execute a private total order multicast primitive. Successive joins and leaves degrade the distributed system performance to install consecutive new views. In addition, if all requesters are maintained in the group, it can become difficult to be managed and the overhead is unavoidable. On the other hand, primary-backup replication can provide unacceptable response times, if the primary becomes a bottleneck. Optionally, both replication schemes can be mixed enabling the primary-backup to play the role but any replica can work as primary. This primary waits to all backups’ answers to send a result to the requester. The total order multicast primitive is required to assure order and atomicity of all delivered messages to members. Clients issue requests to members using point-to-point communication.

3 Using group communication to provide the high–available EJB service The standard EJB specification describes the client-server interaction with a non-replicated approach using RMI-IIOP (point–to–point communication). The client first creates a new context to lookup the EJB object with the help of a JNDI (Java Naming and Directory Interface) server. Given this context, the client accesses an EJB object using the home interface. Then the client can call the methods of the EJB object (placed in the server) using the remote interface. When all 6

closed groups require that all process – clients (requesters) and servers – must be group members to use group communication primitives and avoid that non-registered members access group private information and services

activities are completed, the client calls the destroy method – also through the home interface – which finishes the session [4]. In fact, the client’s stub issues the request because the remote approach is transparent. In the other side, the server’s skeleton receives the request and delivers it to the container that manages the EJB (which allows the service). When the service is done, the server’s skeleton gives back the result to the stub that delivers it to the client’s application (fig.1). If the server crashes, the service will be unavailable although the object’s state will be consistent (transactions provide it using the ACID properties).

Figure 1 – Message passing in the standard EJB service using RMI In the high-available service (or HA-EJB service), clients remain executing their requests using point-to-point communication (fig.2). The first contacted server works as primary server to this client and the other as backups. The skeleton of the primary server uses group communication primitives to forward the request to the backups. Only servers can use the GCS services.

Figure 2 – Message flow in the HA–EJB system, adapted from Pedone et al. [6] Primary–backup replication has the problem of primary’s failures, which is not transparent to the client and requires that the client’s stub contacts the JNDI to select a new primary. If the primary fails before that it forwards a client’s request to the backups, the client must reissue the request to the new primary. This primary will be excluded in the next view. If the primary fails after forwarding a client’s request, the termination property [3] of the total order multicast primitive assures the system progress. Clients detect not–suitable response times in the primary using timeouts and only issue and receive the standard EJB messages. Crash of a backup is totally transparent to the requester. Each client’s current primary server is undertaken to treat requests from different clients concurrently. The client just knows the address of the primary server provided by the JNDI. If the client requests a read method, the primary does the service and returns the response as the standard EJB service. Otherwise, if the client requests a write method (an update), the primary’s skeleton will turn aside to the local GCS to propagate the updates to the backups. To propagate updates, the immediate update technique is preferred by entity beans and the deferred update technique is preferred by session beans. In the deferred update technique the transactions are processed locally at one server and are forward to the backups at the commit time. The immediate update synchronizes every transaction across all servers. Although deferred update has advantages over immediate update [7] here the latter is preferred to entity beans because the

transactions that are executed by the primary can be propagated immediately to the backups. If the session beans are used, the propagation to the backups could be done when the client closes the session, at the commit time. 3.1 Target systems The HA–EJB service is been developed matching two OpenSource projects: JavaGroups [1] and JOnAS (Java Open Application Server) [2]. An OpenSource project has its source code available that can be changed. JavaGroups is based on IP multicast and implements reliability and group membership concepts. To send and receive messages using JavaGroups, a channel (or a group) must be created. The (micro) protocols of a channel are specified when the channel is created using an underlying protocol stack. Each protocol implements a specific property related with reliability or with membership (for example FIFO order). All messages sent to a channel traverse this stack. JOnAS is an implementation of EJB1.1 specification by Evidian. JOnAS is built on top of the JTM (JavaTM Transaction Manager), which manages distributed transactions using the two–phase commit protocol. The JTM may be distributed across one or more servers enabling a transaction to involve several beans placed on different servers. 3.2 Implementing the HA–EJB service Implementing the HA–EJB service requires changing the JOnAS source code to include group communication using the service provided by JavaGroups and developing a high available module or HA-EJB service (HA–EJB source in fig.3). The user builds its EJB (represented by EJB in fig.3) using the standard EJB specification but he must install, besides JOnAS, JavaGroups and HA–EJB service. To use the HA–EJB service, the user starts many instances of the replicated server (HA– EJB server) that automatically synchronize replicas and treat failures. The conventional JOnAS compiler, called GenIC [2], is normally used to generate the class that implements the remote interface and the class that implements the home interface, of a given object as well the javac to generate the other classes. GenIC javac

gmake

gmake

–

–

–

Figure 3 – Integrating JOnAS and JavaGroups The HA–EJB server (specified in the GCServer.java file) extends the actual behavior of the non-replicated JOnAS EJB server (EJBServer.java) implemented in the JOnAS source. This has been done developing a new package called replication and inserting group communication concepts in the EJBServer.java file. Each time a new instance of a HA server is started, a new view is automatically installed by the GCS. To request a service, a client contacts one of the server instances (described in the jonas.properties file which is implemented by the JNDI) and this instance will forward client’s updates to the other group members. If one of the members crashes, it is removed from the group by the GCS.

4 Correlated works The site http://www.mgm–edv.de/ejbsig/ejbservers.html describes a list of several EJB server’s implementation that are available or in current development. This list represents a good report because it is used to promote and to advertise EJB servers. However, many of them are non– freeware systems and their source codes are not available. Some of these servers provide fault tolerance using transactional management (it means two–phase commit protocols). Group communication seems not to be used. Two–phase commit protocols are widely used to provide consistent states in distributed replicated databases. Theses protocols impose a substantial communication overhead to each transaction. Despite of this overhead, if the transaction coordinator fails, other processes may be unable to commit the last transaction and the entire system may be blocked until every failed process has recovered [7]. Three–phase commit protocols try to solve some availability problems of the two–phase commit protocols adding new communication rounds, i.e., more overhead. The three–phase commit protocol tolerates crash failures during its execution using a fail–stop failure model. Group communication primitives could provide several advantages over the n–phase commit protocols as treating a more non–restrictive failure model. Group communication follows distributed systems concepts which look for non–blocking protocols.

5 Concluding remarks and future works We are investigating how the EJB model can benefit from an underneath GCS. We aim to put together our experience with group communication programming and the EJB model in an efficient way. Despite of the transactional management, standard EJB does not provide a high available service that can be achieved using group communication. Group communication represents a convenient abstraction for synchronizing replicas and enables treating a non–restrictive failure model. Group communication looks for non–blocking protocols. In addition, performance and load balance are also required. To reach these goals, suitable design decisions were done such as using group communication only with servers and propagating only updates to backups. The first one avoids installing new views each time that a client requires a service and the second one provides good performance reducing the message passing. Presently, we are working in the implementation of the HA–EJB service. A performance study using this implementation will take into account different replica number and failure scenarios.

References [1] Ban, B. JavaGroups user’s guide. Department of Computes Science, Cornell University. August 1999. 73p. http://JavaGroups.sourceforge.net/ [2] Danes, A.; Dechamboux, P.; Riveill, M.; Vandome, G. Technologie base de composants EJB: exp rience et perspectives avec JOnAS. OCM 2000, Nantes, Mai 2000. http://www.objectweb.org/jonas/ [3] Guerraoui, R. and Schiper, A. Fault-Tolerance by replication in distributed systems. In Proc Conference on Reliable Software Technologies (invited paper), p. 38-57. Springer Verlag, LNCS 1088, June 1996. [4] Kassem, N. and Enterprise Team. Designing enterprise applications with the JavaTM 2 platform, Enterprise Edition. Version 1.0.1 – final release, Oct. 2000. 362p. [5] Little, M. C. and Shrivastava, S. K. Integrating group communication with transactions for implementing persistent replicated objects, Lecture Notes in Computer Science, vol. 1752, Springer– Verlag, pp. 238–253, 2000. [6] Pedone, F.; Guerraoui, R. Schiper, A. Exploiting atomic broadcast in replicated databases. Proceedings of EuroPar, Southampton, England, Sep. 1998. [7] Wiesmann, M.; Pedone, F.; Schiper, A.; Kemme, B. and Alonso, G. Understanding replication in databases and distributed systems. Proc. ICDCS 2000, pp.264–274, Taipei, Taiwan, R.O.C., April 2000.