High Availability: Evaluating Open Source Enterprise Service Buses

Transcription

1 High Availability: Evaluating Open Source Enterprise Service Buses Tobias Kruessmann SD & M, Berlin, Germany Arne Koschel University of Applied Sciences and Arts, Hannover, Germany Martin Murphy, Adrian Trenaman IONA Technologies Progress Company, Dublin, Ireland {martin.murphy Irina Astrova Institute of Cybernetics, Tallinn, Estonia Abstract. We evaluate three open source enterprise service buses (ESBs) Fuse, Mule and OpenESB, focusing on their support of high availability. Since high availability for the these ESBs relies on transactional Java messaging service (JMS) in a staged event driven architecture (SEDA), we review JMSs first. On this base, we evaluate and rate the ESBs on their support of both stateless and stateful services. We rated Fuse first, followed by Mule and OpenESB. Keywords. SOA, ESB, JMS, high availability, failover 1. Introduction An enterprise service bus (ESB) is one of the main technologies that enable implementation of service-oriented architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting services. It has become an extremely popular paradigm. The plain evidence of this fact is that over 80% of the business applications sold between 2005 and 2008 were based on the principles of SOA [1]. The main building blocks of SOA are services. Services are self-descriptive, selfcontained, platform-independent and openlyavailable units that interact over the network. In other words, a service is a unit of work performed by a service provider to achieve the desired end results for a service consumer. Services can be stateful or stateless. By stateful, we mean that the previous requests have an influence on processing the current request. In other words, the way how services will handle the current request depends on their state, which is available in the memory. By contrast, stateless services are not influenced by the previous requests, which can be sent to any service if the service is replicated. 2. Motivation Given the particular characteristics of SOA application and its environment, many organizations would like to evaluate ESBs, because this evaluation is less costly and time consuming than actually implementing the SOA application or even purchasing an ESB. In other words, the evaluation can help organizations to select an ESB. There are many different ESBs available in the market today, so selecting an ESB has become increasingly difficult. Not only are there many different factors to consider in this selection, but there is also a relationship between these factors and the requirements of a particular integration scenario. 3. Related work Evaluating ESBs is a challenging task because there are many pertinent criteria that can be considered in this evaluation. The pertinent criteria are those that lead to a well-reasoned conclusion about how closely a particular ESB meets the requirements of the SOA application environment, characterized in its entirety to 615 Proceedings of the ITI st Int. Conf. on Information Technology Interfaces, June 22-25, 2009, Cavtat, Croatia

2 include all aspects of user needs, budgets, hardware/software/staffing constraints, etc. Different researchers apply many different criteria for evaluation. (The list of criteria applied to compare open source ESBs are generally the same as those used to evaluate commercial ESBs.) By doing so, every researcher imposes their own lists of evaluation criteria. In these different lists, some criteria (e.g. price) keep reappearing, although their importance in the lists can differ. E.g. price may be unimportant when open source ESB are compared. Vollmer and Gilpin [2] proposed the idea of grouping the evaluation criteria into highlevel buckets. The idea has been followed by many other researchers who captured the evaluation criteria in lists of characteristics and their depending sub-characteristics, which in turn are assigned to weights and rates. Vollmer and Gilpin [2] evaluated eight commercial ESBs against more than 100 criteria, which were grouped into three high-level buckets: current offering, strategy and market pressure. Vollmer and Gilpin rated Cape Clear first, followed closely by BEA Aqualogic Service Bus. The other contenders included Fiorano, IBM WebSphere Enterprise Service Bus, IONA Artix, PolarLake, Software AG and Sonic. The ESB rates were based on provider surveys; ESB briefings, where providers discussed their visions and ESB strategy; and discussions with reference customers. Woolley [3] applied Vollmer and Gilpin s evaluation criteria to two open source ESBs Apache ServiceMix and MuleSource Mule. In addition, he included integration into the list of evaluation criteria. Integration is still a key criterion for evaluation of ESBs since there are so many legacy systems to wrap as part of SOA. Woolley rated MuleSource Mule first, followed by Fiorano. The other contenders included IBM WebSphere Enterprise Service Bus, BEA Systems Aqualogic Service Bus and Apache ServiceMix. The ESB rates were based upon information supplied by providers. Or this information was taken from other published studies. Desmet et al. [4] compared two open source ESBs MuleSource Mule and Apache ServiceMix, and two commercial ESBs BEA Aqualogic Service Bus and IBM WebSphere Enterprise Service Bus. They focused on performance. ESBs enable standard-based integration between loosely coupled applications. Though offering flexibility, ESBs (as the sole service-interconnecting information technology facility) may turn into a bottleneck if many processes with complicated messaging use it. In the worst case, mission-critical business processes might be paralyzed, which may have unforeseeable consequences for a service provider. Therefore, performance becomes an important criterion that has to be considered in the evaluation. Desmet et al. rated the open source ESBs first, followed by the commercial ESBs. (Since the commercial ESBs are built on top of an application server, they perform worse than the open source ESBs.) The ESB rates were based on the performance test results. One more evaluation of commercial ESBs is available from MacVittie [5]. His evaluation criteria included core bus features, integration and price. MacVittie rated BEA Aqualogic Service Bus first, followed closely by Oracle SOA Suite. The other contenders included TIBCO Software, Fiorano, Cape Clear, IBM WebSphere Enterprise Service Bus, Software AG and Sonic. The ESB rates were based upon information supplied by providers. Or this information was taken from other published studies. The previous evaluations provide interesting results. However: They often compare commercial ESBs only. They often set out too general evaluation criteria that are useful for categorizing ESBs or judging providers only. They lack some important evaluation criteria; e.g. high availability. High availability characterizes an ESB that is designed to avoid the loss of services, by reducing or managing failures as well as minimizing planned downtime for the ESB. High availability is of particular importance for many organizations, because failures lead to a loss of income, customer dissatisfaction and missed opportunities [6]. (In 2001, 25% of organizations said that failures cost them more than $250,000 per hour. And 8% said failures cost them more than $1,000,000 per hour [7].) As an attempt to fill gaps in the previous evaluations, we compared three open source ESBs, based on their support of high availability. 4. Evaluation criteria We used the following criteria to evaluate open source ESBs: 616

3 High availability of stateless services How does the ESB support high availability of stateless services? High availability of stateful services How does the ESB support high availability of stateful services? Extensibility How easy is it to extend the ESB with support for high availability? Failover How does the ESB support failover of services? 5. Java messaging services Since open source ESBs heavily rely on Java messaging service (JMS) in their support of high availability, we overview JMSs first, followed by the overview of ESBs Fuse Message Broker Fuse Message Broker [8] is based on Apache ActiveMQ. It supports high availability through a number of techniques. First, JMS clients utilize transparent failover techniques through a list of broker connection URLs. When the connection to the first broker fails, the client is transparently redirected to the second connection. The broker itself supports a number of master-slave configurations. In the shared nothing approach, the master and the slave continuously communicate to each other to ensure that all messages are replicated in queues across the both brokers. If the master goes down, clients will automatically be redirected to the slave, which will take on the role of master. The queue state is saved by each broker using a high-speed file-based journal; no database is required. This solution is ideal for commodity hardware. However, one drawback is that, on resumption of the master, human intervention is required to copy the state from the slave s file system back to the master. The shared file approach removes the problem of having to physically copy the promoted slave s state by using a reliable shared file system. On start-up, brokers compete for a file-system lock: the winner becomes the master and writes the queue and message state to the file system. When the master dies, the slave acquires the lock and becomes promoted. In the absence of shared file system, brokers can adopt the shared database approach to persistence, where the master and slave brokers compete for a lock on the database. Both the shared file and shared database approaches have a drawback in that slave instances operate in hot-backup mode, doing no work until the lock is released. However, brokers can be configured as a network of master-slave pairs, providing a scalable and highly available solution JBoss Messaging JBoss Messaging [9] is the successor of JBossMQ. It supports horizontal clustering, where messages get replicated to other nodes in the cluster. The key improvement provided by JBoss Messaging over JBossMQ is that it facilitates more than one active JMS broker, with transparent failover. JBoss Messaging should be deployed into the JBoss Application Server. Since this server is shipped with JBossMQ by default, the latter must be uninstalled before deploying JBoss Messaging. Clustering of queues and topics is achieved through the use of a shared database. By default, clustering is turned on in JBoss Messaging. But since the JBoss Application Server uses a local database system for persistence, the clustering feature has no effect; it is necessary to replace the local database with a shared database to enable clustering. JBoss Messaging utilizes a load balancer, which collects statistics on distributed queues on each node in a cluster. It can use this information to ensure that consumers are neither overloaded nor starved by the node they are attached to Joram Joram [10] supports high availability through horizontal clustering and heartbeat. A Joram cluster contains one active instance and two or more passive instances; a cluster must have at least three nodes, as at least two nodes need to be alive to elect a new active instance. The JMS messages are replicated to each passive instance. The JMS messages get saved in a local file on each node. This failover mechanism is transparent to Joram clients. 6. Open source enterprise service buses Organizations decide to select an open ESB for the following reasons: 617

4 Open source ESBs have no upfront licensing costs, thus allowing organizations to download an ESB and go. No purchase is required. (Prices for commercial ESBs range from $10,000 to $75,000 per server [2].) Commercial ESBs are too heavy and require too much infrastructure to set up before they can start. Open source ESBs have clean easy-tounderstand architecture and they support Java business integration (JBI). Open source ESBs can work with any web application server, including WebLogic, WebSphere and Oracle OC4J. Open source ESBs allow organizations to modify and extend code to meet the needs of their business [11]. The motivations that lead any particular organizations to select an open ESB may not fall neatly into one of these five categories. However, these reasons are typical. Selecting an open source ESB is not without drawbacks. E.g. open source ESBs typically have rudimentary tooling, monitoring and documentation compared to commercial ESBs [4, 11]. We selected the following open source ESBs for evaluation: Fuse, MuleService Mule and OpenESB. One more candidate could be Apache ServiceMix. But Fuse is utilizing ServiceMix. So its approach to high availability is similar to ServiceMix Fuse Fuse [8] is based on JBI. It supports two different approaches to high availability of stateless service. One is Fuse Message Broker, which allows services to be horizontally clustered. It is possible to register more than one service at a Fuse Message Broker and to have multiple instances of the service running. For each JMS broker instance, there have to be at least two service instances registered. These service instances have to run on different servers to guarantee high availability when a server fails. The detection of the different nodes in the cluster works automatically. If one of the nodes fails, it will be removed from the cluster. This way the approach to highly availability of stateless services works in Fuse. Another approach to stateless services is a pure transparent client. This approach works with a SOAP binding over HTTP. The client catches the failure of the connected server in an interceptor and handles the reconnection there. It is a static approach because the instances of the service have to be written in the WSDL file. In the client no connection exception has to be handled, because the reconnection to a different service instance happens in the interceptor. It is an active/active approach. This approach is supported with Fuse Service Framework. For stateful services, the approaches to stateless services have to be extended. High availability of stateful services could be implemented using a database, Java temporary cashing (JCACHE) or Terracotta. With this extension, all of the service nodes could have the same state information Mule Mule [12] relies on JMS for support of high availability. It supports a number of open source JMS brokers, including Fuse Message Broker, Joram and JBossMQ. In Mule, high availability of stateless services can be implemented by having redundant consumers listening in a queue. High availability of stateful services has to be extended within the universal message object (UMO) component. The extension of the UMO component to replicate the state information can use a database, JCACHE or Terracotta OpenESB OpenESB [13] is based on JBI. It supports high availability in two different ways. First, it may be deployed onto the J2EE Application Server. By default, an OpenESB download will be configured to run on the Glassfish Application Server and leverages the transactional and clustering capabilities of that server. However, OpenESB can also be deployed into JBoss and WebSphere. Second, OpenESB may be deployed in standalone mode and support high availability using JMS queues. Every component is redundant; queued JMS messages are replicated between different broker instances. When deployed into the Java J2EE Application Server, OpenESB may use any JMS broker that is registered with that server. However, in standalone mode OpenESB may 618

5 only use Sun Java System Message Queue; this is based on the JMS Broker originally shipped with Sun s (commercial) application server. This JMS broker supports high availability only through its commercial JMS solution (viz. Sun Java System Message Queue Enterprise Edition). There is no direct support for high availability of stateful services. However, the stateless concept can be extended with a new layer in order for the services to save the state information. 7. Testing failover We installed the ESBs on distributed servers and exercised their failover capabilities, by conducting the following tests: Killing the server process: In this test, the server process was killed (by executing a command kill -9 on the server side) to see how the cluster would react on the failure. Unplugging the network cable: In this test, the network cable of the server was unplugged to see how the cluster would react on the failure. Killing the master: In this test, the master was killed to see how the cluster would be reintroduced. Each of these tests simulated a failure caused by unplanned downtime Fuse Fuse with Fuse Message Broker. Testing of Fuse with Fuse Message Broker was somehow difficult because of some bugs in the failover mechanism. Moreover, the pure active/passive configuration of Fuse Message Broker has a disadvantage in that a failed active broker cannot be reintroduced. To reintroduce the old active broker, the new active broker has to be shutdown. In case of a failure of the active broker, it always means an outage of the service. The replicated information has to be copied manually. One slave can be attached to the active broker. The configuration with a shared file system of the JMS broker has a disadvantage in that a shared file system is always a single point of failure. Similarly, the JDBC configuration has a possible single point of failure because it is build on top of a database. Fuse with pure transparent client. The pure transparent client approach could handle all of the test scenarios. Since it is an active/active approach, the reintroduction is not a problem. The restarted service instance starts like a regular service. When the network cable was unplugged, the client reconnected to another service instance automatically. The pure transparent client approach worked fine for stateless services. It has an advantage in that a client reconnection happens in the client interceptor. Just the user exceptions have to be handled in the client code. This approach can relatively easy be extended for stateful services with another layer to replicate the state Mule Mule with Fuse Message Broker. Testing of Mule with Fuse Message Broker was similar to that of Fuse with Fuse Message Broker (see Section 7.1). Mule with JBossMQ. The failover mechanism worked fine. But every time when a JMS broker failed, so did a service. Since JBossMQ is active/passive clustered, Mule has to connect to the new active JMS broker instance after a failure of the old active instance. The reintroduction of a service in the cluster worked fine. But the reintroduction of a JMS broker did not work, because the Mule instances are bound to a specific JMS broker address. They do not recognize a new JMS broker instance. For both stateless and stateful services, this means that the service instances have to be restarted to use the newly introduced broker. A manual part is still necessary in the high availability configuration. This is a disadvantage because human interaction typically takes more time than an automatic detection of new instance of JMS broker. Our tests showed that a failed JMS broker cannot get reintroduced within Mule; instead services have to be restarted to reconnect to new instances. For stateful services, this is quite difficult, because all state information has to be replicated to the restarted instance. Mule with Joram. Mule using Joram as the JMS server is similar to the JBossMQ configuration. The problem with this configuration is that Mule does not support an automatic reconnection after a failure of a JMS broker. 619

6 The Joram failover mechanism worked fine. All registered service instances were active. In case of a failure of a service instance, the other service instances were still running OpenESB OpenESB approach to high availability could not be tested because the JMS server is a commercial product. 8. Conclusion Table 1 summarizes the evaluation results. These results can be used by organizations to select an ESB that best meets their business needs. Table 1. Summary of evaluation results Criterion Criterion weight Fuse rate Mule rate OpenESB rate High availability of stateless services High availability of stateful services Extensibility Failover n/a Total All weights are between 0 and 1. The sum of all weights is 1. By default, all weights are 0.25 so all criteria contribute equally. But organizations can change the weights to emphasize one criterion over another. E.g. because high availability is so important, we weighted this criterion higher. All rates are between 0 and 10. The total is the sum of all rates multiplied by the respective weights. The maximum total attainable is 10. All open source ESBs support high availability using the JMS approach. The drawback of this approach is that it does not support an automatic reconnection after the connection to a JMS server has been lost. If the JMS server fails, so does a service. Therefore, it is necessary to restart the service manually. Of the open source ESBs, Fuse is a bright spot. 9. Acknowledgements Irina Astrova s work was supported by the Estonian Centre of Excellence in Computer Science (EXCS) funded mainly by the European Regional Development Fund (ERDF). 10. References [1] Testing SOA Applications, 2007; , p q,00.htm [2] Vollmer K, Gilpin M. The Forrester Wave: Enterprise Service Bus, Q2 2006, 2006; 1, p,00.htm [3] Woolley R. Enterprise Service Bus (ESB) Product Evaluation Comparisons, 2006; dts.utah.gov/techresearch/researchservices/r esearchanalysis/resources/esbcompare pdf [4] Desmet S. et al. Throughput Evaluation of Different Enterprise Service Bus Approaches. Software Engineering Research and Practice; 2007, [5] MacVittie L. Review: ESB Suites; rintfullarticle.jhtml?articleid= [6] Weygant P. Clusters for High Availability - a Primer of HP-UX Solutions. Prentice Hall PTR, [7] Aggarwal N. et al. Configurable Isolation: Building High Availability Systems with Commodity Multi-core Processors; ganathan/papers/2007/2007_isca_isolation.p df. [8] Configuring and Running Fuse ESB, ide/index.htm [9] JBoss Messaging User s Guide, zone/docs/userguide SP3/html_single/index.htm [10] Joram User s Guide, [11] Zelenka A. Open Source ESBs for Application Integration (SOA Optional); redmonk.com/public/opensourceesbs.pdf [12]Mule User s Guide, SER/Clustering. [13] OpenESB JMS Binding Component User s Guide,