Performance Evaluation of Enterprise Service Buses towards Support of Service Orchestration

Transcription

1 Performance Evaluation of Enterprise Service Buses towards Support of Service Orchestration Themba Shezi, Edgar Jembere, and Mathew Adigun Abstract- The use of Enterprise Service Bus (ESB) as the cornerstone for system integrations has shown improvement in many aspect of business information systems, including paving a way for Service Oriented computing, reusability, business to business collaboration and standard based communication infrastructure. ESB as a concept defines set of capabilities which includes message routing, transformation, and service orchestration. However there exist different approaches towards achieving these capabilities. There is much ongoing research on architectural issues and enabling technologies for ESBs, but the body of knowledge regarding service automation and orchestration schemes needs some improvements. In this work we provide comparative performance evaluation of ServiceMix, Mule and JBoss ESB regarding service orchestration. The results showed that the use of Apache ODE as the orchestration engine gave ServiceMix an advantage over the other ESBs. Keywords Enterprise Service Bus, Service Oriented Architecture, Web Services and Service orchestration I. INTRODUCTION VER the past years organizations were required to cope O with rapidly changing market that includes new competitive pressure and threads which required information systems to respond quickly to support the new business models and requirements. With the changes becoming more and more frequent, organizations moved their information systems to fit in Service Oriented paradigm [1]. The use of Service Oriented Architecture (SOA) brings a number of benefits including cost-cutting initiatives by allowing business functions to be created in such a way that they can be reusable throughout the whole organization. In this way SOA act as a key enable for effective and efficient rapid application development. SOA is mainly driven by the use of open standards which includes Web Service technology [2]. Web services define business logic located anywhere and accessible through Internet protocols such as. A number of standards are contained in the Web Service technology. They include Web Service Definition Language (WSDL) which is an XML-based language for defining web services, Universal Description, Discovery and Integration (UDDI) which act as a repository for storing information about web services and SOAP which defines message structure for communication exchange over Themba Shezi is with the Department of Computer Science and Mobile e- Services in the University of Zululand, KwaDlangezwa 3886, South Africa ( mrtshezi@gmail.com). Edgar Jembere is with the Department of Computer Science and Mobile e- Services in the University of Zululand, KwaDlangezwa 3886, South Africa ( ejembere@gmail.com). Mathew Adigun is with the Department of Computer Science and Mobile e-services in the University of Zululand, KwaDlangezwa 3886, South Africa ( madigun@pan.uzulu.ac.za). the Internet. In most scenarios services are combined in a process to achieve a business objective. For defining these processes Web Service Business Process Execution Language (WS-BPEL) is used. SOA implementations that were based on only endpoints fall short of the key infrastructure to support data transformation, event handling, and durable messaging. These additional requirements to SOA led to what is known as Enterprise Service Bus (ESB) [3]. ESB is a standard based integration infrastructure that enables heterogeneous services and applications to interact by combining web service technology, messaging, intelligent routing, data transformation and service orchestration [2]. The industrial success of ESB technology led to many products being implemented and available as both open source and commercial ESBs. Selecting the ESB product that will suit all the integration needs of an organization is a challenging task because different approaches used by different products to achieve a certain ESB capability results to different performances [4]. In addition no single ESB is the best in all integration requirements, so the compromise is always needed [5]. Most of the works done to assist in ESB selection focus on evaluating out of the box ESB capabilities such as data transformation, routing and reliable messaging. In reality to achieve a complete SOA implementation external features are required in addition to ESB. For example UDDI and BPEL process support. The former is useful for service discovery and management, the latter enables the existing enterprise functions to be composed and reused to provide new business logic. Most ESBs provides add-ons for these features. As a consequence, the aim of this work is to provide an evaluation of Mule, ServiceMix and JBoss ESB towards support of WS-BPEL processes. More concretely the contribution of this work it two fold. Firstly we showed the method for adding external BPEL engine to support process definition and execution inside the ESB. Secondly we provided performance evaluation of these ESBs regarding service orchestration scenario. II. ESB TECHNOLOGIES ESB core capabilities are supported through a number of technologies. For web service integration Apache CXF, Axis and JBoss web services (JBoss WS) are most commonly supported technologies. As an important part of any ESB, data transformation is supported through the use of Extensible Stylesheet Language Transformations (XSLT) which enables XML based message transformation. In addition XQuery and XPath are query languages used to manipulate XML data. Message routing is supported through Enterprise Integration 260

2 Patterns as defined in [6]. A wide variety of transport protocols are supported by ESBs, these include, FTP, TCP, UDP and JMS. There exist different JMS implementations which include Apache ActiveMQ, MuleMQ and JBossMQ. To support open standards some ESBs are based on Java Business Integration (JBI) specification. In JBI environment components are either Service Engines (SE) or Binding Components (BC). SE contains business logic and also other features such as transformation. BC enables connectivity to external services. At the heart of JBI is the Normalized Message Router (NMR) which facilitates communication between SE and BC. To support short and long running business processes, most ESBs have available API s for WS-BPEL. Different orchestration engines are supported for execution of these processes. They include Open ESB BPEL Engine, Apache ODE and JBoss RiftSaw Engine. III. RELATED WORKS ESBs share the same philosophy as Enterprise Application Integration (EAI) which is to provide integration of heterogeneous application. However, ESB since its invention has been popular due its capability of integrating infrastructure where concept of web service and SOA coalesce [7]. The performance of ESB products has been a focus of many researchers. Ueno and Tatsuburi in [8] proposed a method that allows performance and capacity of the ESB to be tested at planning stage before the actual deployment. Authors used response time, CPU utilization and throughput as their criteria to test their model. Brener proposed modeling performance of composite application using well-known SOA/ESB scenario called LoanBroker application. Author showed a method of evaluating performance of each service participating in a composite application using SOPM [9]. In these works performance of only one ESB is evaluated, no comparison made with the other ESBs. Researchers have attempted to fill this gab and ESBs have been evaluated in number of different integration scenarios. In these evaluations Researchers impose their own criteria to help reason on how close a particular ESB meets the required integration scenario. Performance of ESBs regarding Content-based routing, mediation and data transformation capabilities were evaluated in [10] [11]. Authors used XSLT for data transformation and XPath expression for content-based routing. In particular performance was based on load handling, throughput and response time. ServiceMix was rated as the better ESB when considering the performance criteria used. This is mainly due to the strong support of XML based messaging techniques that this ESB has. Other contenders included Mule, WSO2and. Another performance evaluation of ESBs regarding invocation of external secure web services through Apache ActiveMQ appears in [12]. Although research has been done to support ESB selection, but there is still a lot to be desired when considering complex scenario. For example, in real world scenario large organizations maintain a huge number of services that implements business logics. So to achieve a certain business objective, multiple services are composed to create a process. Service composition can be achieved either through service orchestration or choreography. Most ESBs provide API s to support BPEL standard which is the orchestration language for defining business processes. However their performances have never been evaluated. This work presents comparison of ESBs regarding service orchestration. More concretely, we used open source BPEL engine to provide runtime environment of the defined processes. IV. SERVICE ORCHESTRATION AND CHOREOGRAPHY In Service Oriented Computing there exist two approaches to service composition. Service Choreography is based on collaboration, all web services participating in a composition are equal, and there is no central control of the execution. Participants need to know exactly when to become active and who to collaborate with. On the other hand we have Service Orchestration which has central controller that coordinates invocation of different web services. In orchestration approach services have no information about other services and they are not aware that they are participating in a process. Service Orchestration is the most supported approach in ESBs, therefore it s the focus of this work. BPEL engines have been implemented to provide runtime execution of BPEL processes. The next subsection provides brief description of Apache ODE and Riftsaw BPEL engine. V. APACHE ODE AND JBOSS RIFTSAW There are a number of BPEL Engines available and they include Apache ODE, JBoss Riftsaw, Open ESB BPEL Engine, OW2 Orchestra and Petals BPEL Engine. This work focuses on Apache ODE and JBoss Riftsaw mainly because the ESBs under review have strong support for these engines. JBoss RiftSaw is a WS-BPEL engine optimized for JBoss Application server container. RiftSaw is based on Apache ODE. Natively it support JBossWS, however CXF can be supported as well. Apache ODE is an engine which executes one or more business processes defined in WS-BPEL language. Apache ODE support two communication layers, one based on Axis2 (specifically Web Services http transport) and the other based on JBI standard. It has compatibility with BPEL4WS 2.0 which includes WS-HumanTask with Apache HISE. Since RiftSaw Engine is based on Apache ODE, in this work Apache ODE was used with the aim of achieving similar performance measures. VI. MOTIVATING EXAMPLE In this section we describe a classical SOA/ESB example called LoanBroker application [6]. The aim is to evaluate performance of each ESB regarding service orchestration scenario. LoanBroker application models a real world scenario of a consumer looking for the best loan quote by consulting a number of banks as shown in Fig.1. Message flow as follows; 261

3 1) Consumer sends loan request with loan amount to LoanBroker 2) LoanBroker sends request to to get credit profile 3) LoanBroker receives credit profile 4) LoanBroker sends request to Lender to determine the most appropriate lenders (banks) to contact based on consumer s credit profile and amount requested. 5) List of potential lenders are returned. 6) LoanBroker sends loan quote request to the potential lenders. 7) Each potential lender computes and return loan rate 8) Amongst the rates computed by potential lenders, the best rate is selected. 9) Best loan quote is returned to the consumer Consumer LoanBroker CreditAgency Lender GetLoanQoute (amount) getcreditprofile 2. CreditProfile SelectLenders(amount, CreditProfile) 5. ListLenders 6. GetLoanQoute(amount, CreditProfile) 7. LoanQoute Compute Rate GetLoanQoute(amount, CreditProfile) LoanQoute 9. Select Best Rate 8. LoanQoute Compute Rate VII. EXPERIMENTATION In order to carry out our performance evaluation of the three ESBs, we have implemented the LoanBroker application and used web service client to invoke and capture the performance measures. Performance was measured in terms of response time and throughput. The two tired architecture was configured with two i GHz Intel core processor machines running Windows 7 OS, and 3.0 GB of RAM connected using 10Mb/s switch. The first machine operated as the web service client that invokes LoanBroker service and measures response time, and throughput. We varied number of clients that concurrently invoke LoanBroker to capture ESB performance in different loads. Apache Jakarta-JMeter version was used as load generator Two ways in which service orchestration can be achieved in the ESB were considered. One consists of a direct service orchestration. With direct service orchestration LoanBroker service directly calls CreditAgency, Lender and the service. On the other hand we have BPEL defined process that executes using Apache ODE. The latter is quite useful because processes are defined using open standard (BPEL) to enable flexibility to change in future. In more details CreditAgency, Lender, 1, 2 and 3 were implemented as web services and deployed on Apache Tomcat 7.0 server so that they can be Fig 1 Sequence diagram for Loan Broker Application external to any ESB. The following subsections provide details on the configurations of these two methods considered A. Direct Service Orchestration The purpose of this experiment is to investigate performance of each ESB when considering direct service orchestration. In this test we modeled two type web services, complex and simple services. Complex service is a service which makes reference or calls other service(s). In this experiment we have only one such service and its hosted inside all ESBs using Apache CXF. Simple services are those services which cannot or does not need to be further decompose, typical because they are hosted externally. We have three such services in our experiment, and they are Credit Agency, Lender and service. The following sub sections provide detailed configurations for each ESB. 1) ServiceMix ESB ServiceMix is based on JBI specification and it uses the concept of Binding Components (BC) and Service Engines (SE). We configured BC to expose the CXF web service hosted inside ServiceMix. SOAP messages are exchanged between internal and external web services. Web service client send loan request and receive loan quote via protocol. 262

4 ServiceMix ESB BC CXF WS SE Lender our experiment we chose to keep it external as depicted in Fig. 5 below. ServiceMix ESB Apache ODE BC CXF SE Lender Fig 2 ServiceMix configuration for Direct Service Orchestration 2) Mule ESB Unlike ServiceMix which is based on JBI, Mule ESB uses Inbound and Outbound concepts. We have configured inbound endpoint to exposed CXF web service hosted in Mule over, essentially making it an server. To register external web services we have used CXF outbound and exchange SOAP messages. Mule ESB Fig 5 ServiceMix configuration for BPEL Orchestration 2) Mule ESB CXF outbound endpoint is used to bind our Loan process with components inside Mule. Same as the first scenario outbound was used to exposed web service Mule ESB Inbound CXF Outbound Apache ODE Lender Inbound CXF WS Lender Fig 3 Mule configuration for Direct Service Orchestration 3) JBoss ESB JBoss ESB uses the concept of ESB unaware and ESB aware messages. Each service describes Listeners which listen to external messages and list Actions which are inside the ESB and are executed sequentially. We configured an gateway to listen to messages thereby exposing CXF web service. SOAP processor used for processing SOAP messages to and from internal web services. JBoss ESB Fig 6 Mule configuration for BPEL Orchestration 3) JBoss ESB SOAP proxy was used to interact with the Loan process via SOAP over protocol. JBoss ESB has native support for JBoss RiftSaw. However for our experiments we used Apache ODE as depicted in the Fig. 7 below. JBoss ESB SOAP Proxy Apache ODE Lender Fig 7 JBoss configuration for BPEL Orchestration SOAP Processor JBoss WS Lender Fig 4 JBoss configuration for Direct Service Orchestration B. Service orchestration using Apache Ode Engine In this scenario, a process was defined using BPEL 2.0 design editor that use Apache Ode as runtime engine. We downloaded and configured WAR distribution of Apache ODE on Tomcat 7. 1) ServiceMix ESB To register web service exposed by PBEL process into ServiceMix, we have used CXF Service Engine. For ServiceMix we had an option of deploying JBI distribution of Apache ODE inside the ESB, however for fairness throughout VIII. PERFORMANCE ANALYSIS As previously described our performance measures entail average response time, and throughput. Average Response was calculated as the amount of time elapse from the moment the request was sent to the time a reply was received. Throughput was calculated as the number of successful transactions per second. In order to obtain the best results each test ran a minimum of 10 times each. More concretely, the first experiment consists of LoanBroker without using BPEL and the second deal with the use of BPEL A. First Experiment In section 7.1 we have described different configurations for the three ESBs in order to carry out service orchestration. Fig. 8 shows response time for each ESB given a number of concurrent requests. As we can observe that as number of requests increases all three ESBs maintained constant behavior 263

5 regarding response time. This shows that increasing number of requests has little or no effect on response time. Therefore we can conclude that all ESBs scale well in this scenario. However ServiceMix and Mule achieved almost the same response time. The use of JBoss web service by JBoss ESB gave its disadvantage over others as they are based on CXF. Throughput is shown in Fig. 9 where all three ESBs started with low throughput at 50 requests. Constant behavior in all ESBs as the requests was from 100 to 200. ServiceMix had the best throughput of 4.5 TPS with 250 requests. Fig 8 Average Response time for Direct Service Orchestration Fig 11 Throughput for BPEL orchestration IX. CONCLUSION To achieve a typical business scenario an enterprise system need to invoke a number of services that may be located either internally or externally. Orchestration mechanisms are usually used to coordinate these invocations. Throughout this paper we provided a performance comparisons of the most popular open source ESBs regarding service orchestration, more specifically the use of Apache ODE. To mimic a real world scenario we modified LoanBroker application. Direct service orchestration allowed us to observe performance of ESBs without the effect of BPEL. However, state of the art motivates towards using BPEL standard to define and automate business processes. The results obtained on the BPEL scenario showed that ServiceMix performed well. The use of apache ODE gave it an advantage from other ESBs. Fig 9 Throughput for Direct Service Orchestration B. Second Experiment According to configurations on section 7.2, we have run the test using BPEL defined process that uses Apache ODE as orchestration engine. This configuration may favor ServiceMix in terms of performance mainly due to the strong support of Apache ODE that this ESB has. Unlike in the first experiment, response time considering BPEL scenario increased as the number on requests increases. A similar behavior in all the ESBs can be observed as depicted in Fig.10. However ServiceMix achieved the lowest response time followed by Mule then JBoss ESB. Considering throughput, we noted a similar behavior with that one for fist experiment. This means all ESB are consistent with the processing of the transactions. All ESBs achieve their highest throughput at 400 and their lowest at 50 requests as shown in Fig. 11. Fig 10 Average Response Time for BPEL orchestration REFERENCES [1] S. Ortiz, Getting on Board the Enterprise Service Bus, in IEEE Computer Archive, vol. 40, No. 4, April 2007, pp [2] M.P Papazoglou, P Traverso, S. Dustdar and F Leymann, Service- Oriented Computing: State of the Art and Research Challenges in IEEE Computer Archive, vol. 40, No 11, November 2007, pp [3] J Genender, The Buzz about Enterprise Service Bus (ESB) in Open Source enterprise Journal. January/February 2006, pp [4] T. Kruessmann, A. Koschel, M. Murphy, A. Trenaman, I. Astrova, High Availability: Evaluating Open Source Enterprise Service Buses in Proc. of the ITI 31st Int. Conf. on Information Technology Interfaces, Cavtat, Croatia, 2009, pp [5] D. Kusak, Comparison of Enterprise Application Integration Platforms, in Charles University in Prague, Department of Software Engineering. Master s Thesis, 2010 [6] G. Hohpe and B. Woolf, Enterprise Integration Patterns Book published by Addison Wesley [7] V. Issarny, N Georgantas, S. Hachem, A. Zarras, P. Vissiliadist, M. Autili, M. A Gerosa and A. B Hamida, Service-oriented middleware for future Internet: state of the art and research directions in J. Internet Service Applications, vol. 2, No. 1, May 2011, pp [8] K. Ueno and M. Tatsubori Early Capacity Testing of an Enterprise Service Bus in Proc. ICWS '06 Proceedings of the IEEE International Conference on Web Services, Chicago, USA, 2006, pp [9] P. Brebner, Service-Oriented Performance Modeling the MULE Enterprise Service Bus (ESB) Loan Broker Application in Proc. 35th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Australia, 2009, pp [10] A. P Ahuja and A. Patel, Enterprise Service Bus: A Performance Evaluation J. of Communications and Network, vol. 3, No. 3, August 2011, pp [11] S. Desmet, B. Volckaert, S. Van Assche, D. Van Der Weken, B. Dhoedt and F. De Turck, Throughput Evaluation of different Enterprise Service Bus Approaches in Proc. Conf. on Software Eng. Research and Practice (SERP 07), USA, 2007, pp [12] F. J Garcia-Jimenez, M.A Martinez-Carreras, A. F Gomez-Skarmeta, Evaluating Open Source Enterprise Service Bus in Proc. International Conference on E-Business Engineering, Spain, 2010, pp

6 Transfer Learning in Genetic Algorithms B.KOÇER and A. ARSLAN Abstract Transfer learning is an attempt in machine learning to improve performance of machine learning methods as good as human learning performance with the help of past knowledge. There are a lot of methods using transfer learning but some of them are hard to use and some of them are problem oriented and cannot be reused. Our goal is to develop a transfer learning method which can solve main problems of transfer leaning based on genetic algorithms. Keywords Genetic algorithms, lifelong learning, transfer learning. I. INTRODUCTION EARNING in real life is different from learning in L machine learning. In machine learning, learning begin in an isolated environment. There is a training data for each machine learning task and each task learns a mapping from its input to its output by using its training data. But in real life learning is very different. A human learns new task by combining information which he/she has given with its past knowledge. For example one who knows how to play pingpong can learn easier how to play tennis than one who has never played ping-pong. Transfer learning aims to achieve real life s knowledge transfer capabilities in machine learning. When a difficult task learned on a training data it should be able to use in a related task but most of time it s not so easy to use past knowledge in new but related task in machine learning. For example when a document classification task is learnt from newspaper documents it s too hard to use same classification on scientific documents. So to transfer knowledge between domains transfer learning methods can be used. There are two kinds of tasks in transfer learning. One of them is source tasks. Source tasks are classical machine learning tasks which have enough training data for example an indoor Wi-Fi localization task. For this kind of a task an office splits into fixed with and height cells and strength of Wi-fi spots are measured for some number of the cells. These measurements are used as training data to build a full mapping from Wi-fi spot signal strength to cell number which the receiver is on. The second kind of task in transfer learning is target task. This kind of tasks usually has insufficient training data due B.KOÇER. Research Assistant at Selcuk University Engineering Faculty Department of Computer Engineering, Konya, TURKEY, Tel: , bariskocer@selcuk.edu.tr A. ARSLAN. Research Assistant at Selcuk University Engineering Faculty Department of Computer Engineering, Konya, TURKEY, Tel: , ahmetarslan@selcuk.edu.tr difficulty of obtaining training data or something else. So these task need to transfer past knowledge from source tasks e.g. in indoor wi-fi localization task when a source task trained with enough training data, trained model can predict cell number which receiver is on but if receiver s signal strength is changed due temperature, humidity, moving objects etc. or receiver s hardware is changed all measurement should be done again? The indoor environment may be very large so re-measurement may need huge human effort. In this situation new mapping task can be done by a little training data with the help of past knowledge which obtained from source tasks. So this kind of mapping task which facilitates source task s knowledge is target task. There is several transfer learning methods provided for special problem domains. Lots of them domain oriented and reusability of acquired knowledge is too weak. Main difficulties which are met in transfer learning can be determined in three categories. 1. Determining source and target task s relatedness. If unrelated source task selected for transfer target task it may drop the performance of target task this situation is named as negative transfer. 2. Determining how many knowledge should be transferred from source task to target task. If too few knowledge transferred than it will not affect target task but if too much knowledge transferred then it may affect as negative transfer. 3. How to transfer the knowledge from source task to target task. This is maybe biggest problem in transfer learning. There are a lot of machine learning methods which modified for transfer learning. 4. How to reuse acquired knowledge again on similar target task. One who wants to use efficient transfer learning has to solve above problems. II. RELATED WORK There are several area which transfer learning methods applied to and several machine learning techniques which modified for transfer learning. Recently there are growing works on natural language processing and reinforcement learning, for example skill transfer [1], action schema transfer [2], control knowledge transfer [3]. Transfer learning methods are developed based on many main machine learning techniques like neural networks [4-6], Markov logic networks [7], hidden Markov model [8] and these transfer learning techniques are applied to text categorization [9], web page 265