Addressing QoS Issues in Service Based Systems through an Adaptive ESB Infrastructure

Transcription

1 Addressing QoS Issues in Service Based Systems through an Adaptive ESB Infrastructure Laura González, Raúl Ruggia Laboratorio de Integración de Sistemas, Instituto de Computación, Facultad de Ingeniería, UdelaR. Julio Herrera y Reissig 565, CP 11300, Montevideo, Uruguay. {lauragon, ruggia}@fing.edu.uy ABSTRACT As service-based systems operate in an increasingly distributed and dynamic environment, addressing Quality of Service (QoS) issues at runtime has become an important and difficult to achieve challenge. The Enterprise Service Bus (ESB), one of the current preferred middleware technologies to support the development of service-based systems, provides built-in mediation capabilities (e.g. message transformation and routing) that allow addressing several QoS requirements. However, the configuration of these capabilities cannot usually be performed automatically at runtime, which restricts the rapid responsiveness of the system. This paper proposes ESB-based solutions to address QoS issues in servicebased systems. More specifically, the paper focuses on dealing with response time and service saturation issues. The solutions leverage ESB mediation capabilities and they can be automatically and dynamically applied at runtime. Additionally, the solutions are based on commonly supported ESB patterns, so they are likely to be applied in most ESB products. Categories and Subject Descriptors D.2.11 [Software Architectures]: Service-oriented architecture (SOA), Patterns (e.g., client/server, pipeline, blackboard); General Terms Design, Management, Reliability Keywords adaptation, enterprise service bus, service oriented architecture, mediation, quality of service 1. INTRODUCTION During the last years, Quality of Service (QoS) issues have gained a lot of attention among researchers and practitioners in the field of Service Oriented Computing (SOC), especially when dealing with dynamic application contexts. QoS is a set of non-functional properties (e.g. response time and availability) which can play an important role throughout the life-cycle of services. For example, QoS can be used for selecting among functionally equivalent services, at design or run time. [1] Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MW4SOC 11, December 12th, 2011, Lisbon, Portugal. Copyright 2011 ACM /11/12 $ Performance related aspects are usually considered in works which identify QoS properties [1][2][3]. In particular, response time refers to the time required to complete a service request, and maximum throughput is the maximum number of requests a service can process in a given time interval [2]. Addressing QoS issues at run time in service-based systems presents numerous challenges, given the highly distributed and dynamic environment in which these systems operate. In turn, not complying with QoS requirements can lead to unexpected results not only on the client side, but also on the service side. For instance, if a service is not responding in the required time, clients might fail to perform its business operations. On the other side, if a service receives more requests than the ones it can handle, the service might be saturated not being able to perform its work. In turn, Enterprise Service Buses (ESBs), which are widely recognized as a mainstream middleware to implement servicebased systems, provide different capabilities to address mismatches between services regarding communication protocols, message formats, and QoS, among others [4][5]. However, these capabilities are usually configured at design time, in a per-service basis and in a slightly static way (e.g. configuration files). This restricts the rapid responsiveness of the system and the generality of the implemented solutions. These limitations have been addressed in adaptive ESBs [6], which leverage ESB mediation capabilities and allow them to be configured and applied dynamically and automatically at runtime. This paper addresses QoS issues in service-based systems by using an adaptive ESB. It extends the proposal of [6] by: (i) identifying and describing a set of ESB mediation capabilities to deal with performance issues, (ii) proposing and specifying concrete strategies, based on the identified capabilities, to address response time and service saturation issues, and (iii) presenting and describing implementation aspects for the adaptive ESB. The proposed solutions are based on commonly supported ESB patterns, so they are likely to be applied in most ESB products. Additionally, as in [6], the proposals follow the generic adaptation process defined within the S-Cube Adaptation and Monitoring Framework [7]. This framework provides a high level view of the key logical elements needed for adaptation in service-based systems and the dependencies among them. It identifies Monitoring Mechanisms, which refer to any mechanism to check if the actual situation corresponds to the expected one. Monitoring Mechanisms are used to detect Monitored Events, which represent the fact that there is a difference with respect to the expected system state, functionality or environment. Monitored Events trigger Adaptation Requirements, which represent the need of changing the underlying system, in order to remove the

2 differences between the actual situation and the expected one. Finally, the framework identifies Adaptation Strategies, which define the possible ways to achieve these requirements and they are realized by Adaptation Mechanisms. The rest of the paper is organized as follows. Section 2 describes the adaptive ESB infrastructure, over which this work is based. Section 3 identifies specific ESB mediation capabilities and, based on them, proposes and specifies strategies to deal with response time and service saturation issues. Section 4 presents implementation aspects and briefly describes the development of some prototypes. Section 5 presents related work. Finally, Section 6 presents conclusions and future work. 2. ADAPTIVE ESB INFRASTRUCTURE This section describes the adaptive ESB infrastructure proposed in [6], which provides dynamic and automatic adaptation at runtime, for service-based systems, using ESB mediation capabilities. 2.1 Overall Approach The solution assumes that services communicate by sending messages through the ESB applying the Service Virtualization pattern [8], which is commonly used in ESB-based solutions. This pattern takes an existing service and deploys a new Virtual Service in the ESB. A Virtual Service is a service (e.g. a Web Service) deployed within the ESB, which introduces a point of mediation for the real service and can be used, for example, to route or transform requests and responses, among others. It allows hiding different aspects of the real service, for instance, its location and interface. Additionally, for each supported mediation capability, the infrastructure handles an Adaptation Service, which performs a specific mediation operation (e.g. transformations). These Adaptation Services are generic in the sense that their behavior is not fully specified at design time, but it depends on run time information which is included in the messages. For instance, an Adaptation Service that performs transformations executes different transformation logics every time it processes a message. Moreover, the specific transformation logic for each message is included in the message itself. The general idea to achieve adaptation at runtime is to intercept all ESB messages and, if an adaptation is required for the invoked Virtual Service, drive them through Adaptation Flows. These flows, composed by Virtual and Adaptation Services, include all the mediations steps (e.g. transformations) required to carry out a specific Adaptation Strategy (e.g. invoke an equivalent service). Adaptation flows are implemented through ESBs message processing functionalities. Figure 1. Adaptive ESB infrastructure Figure 1 presents a general overview of the proposed solution where a client application invokes a virtual service (SRV), which virtualizes an external Web Service (Web Service 1). First, the client sends a message through the ESB (1) to invoke the Virtual Service (SRV). The message is intercepted by an Adaptation Gateway following the Gateway pattern [8], which is used to apply a common set of mediations to all incoming ESB messages. Given that there is an adaptation directive for the service SRV, the Adaptation Gateway attaches an Adaptation Flow to the message and routes it to the first step in the flow (2). This is done following the itinerary-based routing pattern [9], which determines the message destination based on an itinerary included in the message itself. In this case, the itinerary (i.e. Adaptation Flow) consists of an Adaptation Service, which performs a transformation (TRN), and a Virtual Service (SRV). Consequently, the message is routed to the TRN service which performs the required transformation (specified in the message) and routes the message (3) to the next step in the flow (SRV). Finally, the Virtual Service SRV invokes the external Web Service (4) and, eventually, a response is returned to the client. 2.2 Logical Architecture As shown in Figure 2, the adaptive ESB infrastructure extends an ESB platform with internal components (which allows the dynamic and automatic adaptation at run time within the ESB) and an Adaptation and Monitoring (AM) Engine (which supports the decision mechanisms within the adaptive infrastructure). Figure 2. Logical Architecture At run time, the Monitoring Manager sends monitored information (e.g. the average response time of services) to the AM Engine. This information is obtained by interacting with the ESB Monitoring Mechanisms. When the AM Engine receives the monitored information, it decides (based on rules and service metadata) if an adaptation directive should be created for a given service. If so, the directive is sent to the Adaptation Manager which stores it, so it can be attached in all the messages which are sent to invoke the given service. If an adaptation is required but a directive cannot be executed, given the current available resources (e.g. equivalent services), an alert is raised. The implementation of the decision mechanisms is out of the scope of this paper. Following the key ideas of the S-Cube project [10], the ESB provides monitoring and adaptation capabilities which can be leveraged by the AM Engine to implement overarching solutions. The AM engine deals with adaptation using a comprehensive approach across the different layers of a service-based system (service infrastructure layer, service composition layer and business process management). The AM engine could interact with an ESB and a WS-BPEL engine, to obtain monitored information from both components and implement Adaptation Strategies using the capabilities that both components provide.

3 3. ADDRESSING QOS ISSUES This section proposes and specifies Adaptation Strategies, based on ESB mediation capabilities, to deal with performance issues in service-based systems. First, Section 3.1 presents and describes the relevant ESB mediation capabilities to implement the proposed Adaptation Strategies. Then, Section 3.2 and Section 3.3 propose and specify concrete strategies to deal with response time and service saturation issues, respectively. Finally, Section 3.4 presents a summary of the proposed strategies and mechanisms. 3.1 Introduction ESB products natively include different mediation capabilities which are available as part of its execution environment. These capabilities can be configured according to specific requirements and can be combined creating mediation flows. In the context of the adaptive ESB infrastructure presented in Section 2, these mediation capabilities constitute the Adaptation Mechanisms, that are combined in mediation flows (called adaptation flows) to implement different Adaptation Strategies. Section identifies and describes the relevant Adaptation Mechanisms for this work. Then, Section presents the use of YAWL [11] to specify adaptation flows which, based on the identified Adaptation Mechanisms, implement the Adaptation Strategies proposed in Section 3.2 and Section Adaptation Mechanisms The Adaptation Mechanisms considered within this work correspond to ESB mediation capabilities. In order to identify, describe and provide a graphical representation for these mechanisms various sources were reviewed and analyzed. In particular, the Enterprise Integration Patterns described in [12], various works which identify ESB mediation patterns [4][6], the mediation capabilities provided by various ESB and integration products, and other related work on integration [13][14]. As in [14], adaptation mechanisms are described giving a general overview of their features, indicating the number of input / output messages, and specifying the additional required characteristics to fully describe their behavior. As well, a graphical representation for the mechanisms is provided. The transformation mechanism deals with the runtime transformation of messages. It receives one message and return another one, transformed according to a given transformation logic. Some examples of transformation types are data model transformation, data format transformation, content filter and content enrichment. The additional characteristic to fully determine its behavior is the transformation logic. The routing mechanism dynamically determines the message path according to different factors. It can be configured to have many target services, but only one is activated for a given message. The additional characteristics are the list of target services and a routing logic. Some examples of this mechanism are content-based routing (which determines the message path based on its content) and load-balancing routing (which determines the message path based on a load-balancing strategy, e.g. round-robin). The recipient list mechanism distributes a message to multiple services. In this way, this mechanism receives one message and returns multiple messages. To completely specify the behavior of this mechanism, the list of target services must be specified. The aggregator mechanism receives multiple messages containing an identifier in order to determine which ones are related. When a given set of messages is complete, a single message is returned consolidating the content of all the related messages. It requires the specification of two characteristics: a completion condition and an aggregation algorithm. The completion condition (e.g. "Wait for All", "Time Out", "First Bet") is used to determine when a given set of messages is complete. The aggregation algorithm (e.g. Select the best answer, Condense data ) specifies how the messages content is combined to produce a single message. The cache mechanism receives a request message and returns another message, which was previously stored and returned as a response for the given request. The additional required characteristic for this mechanism is the life time of the stored response messages. Finally, the delayer mechanism receives a message and delays its delivery for a given time interval. The additional characteristic to be specified for this mechanism is the delay time. Table 1 summarizes the described adaptation mechanisms and provides a graphical representation for them. Table 1. Summary of Adaptation Mechanisms Graphical Representation Transformation Routing Recipient List Aggregator Cache Delayer Input / Output Messages Additional Characteristics 1 / 1 Transformation Logic 1 / 1 Routing Logic, List of Possible Target Service 1 / N List of Target Services N / 1 Completion Condition, Aggregation Algorithm 1 / 1 Life Time 1 / 1 Delay Time Specifying Adaptation Flows with YAWL Most ESB products support creating mediation flows based on the capabilities they provide. However, the way in which these flows are specified is not uniform among different products. Some ESB products use graphical tools, others use configuration file and others use Domain Specific Languages (e.g. Integration Flow Language [15]). Given the lack of a standard or uniform way to specify adaptation flows, this paper uses YAWL (Yet Another Workflow Language) [11] which provides a product-agnostic way to specify these flows. An adaptation flow is represented as a YAWL Net in which each task correspond to the execution of a Virtual Service or an Adaptation Service. The tasks flows represent the possible paths a message can follow. The JOIN and SPLIT behavior of each task is determine by the number of input and output messages of the adaptation mechanism. Additionally, in order to graphically represent adaptation flows, the images presented in Table 1 are used to decorate the tasks of YAWL nets.

4 Figure 3 shows a YAWL net which represents an Adaptation Flow consisting of two Adaptation Services (using the delayer and transformation mechanisms) and one Virtual Service. Figure 3. Adaptation Flow as a YAWL Net 3.2 Strategies for Response Time Degradation Response time degradation is a major concern in service-based systems. The massively distribution of service-based systems, the widely use of XML as message format (which involves packaging and parsing tasks) and the mediation operations that a message can undergo are some of the reasons which can cause a considerable overhead in the interactions among services. [6] Generally, services response times are natively monitored in ESB products. Response time degradation can be detected based on this monitored information and, for example, Service Level Agreements (SLA). In turn, response time degradation can trigger the requirement to reduce the response time of a given service. Three possible Adaptation Strategies to achieve this requirement are: invoke an equivalent service, use previously stored information and distribute service requests to equivalent services Invoke an Equivalent Service This strategy consists in invoking an equivalent service, with a lower response time than the service for which the requirement was triggered. Figure 4 presents a possible implementation of this strategy using the routing and transformation mechanisms. time perceived by clients, this time has to be considered when selecting this strategy. Note that given a service with response time problems, the generic adaptation flow presented in Figure 4 can lead to various concrete adaptation flows, one for each equivalent service. In order to select the most suitable adaptation flow, many factors can be considered (e.g. QoS information of the equivalent services) Use Previously Stored Information This strategy consists in using as response for a given request, information which was previously sent and stored from other invocations. In this way, a client application receives a response without invoking the target service. This usually reduces response times. Figure 5 presents a possible implementation of this strategy using the routing and cache mechanisms. Figure 5. Use Previously Stored Information Similar to the previous strategy, messages are first processed by a routing mechanism which, according to different factors, can route the message to the invoked service (represented by the task SRV-1) or to the cache service (represented by the task CCH-1). Note that this strategy is suitable just for services which only return data Distribute Request to Equivalent Services This strategy consists in sending a request to a set of equivalent services, including the service for which a problem was detected, and return the response which arrives first. In this way, there is more chance that a response arrives on time. Figure 6 presents a possible implementation of this strategy using the recipient list, transformation and aggregator mechanisms. Figure 4. Invoke Equivalent Service When a message is sent to the ESB to invoke a service with a response time problem, the message is first processed by a routing mechanism which, according to different factors, can route the message to the invoked service (represented by the task SRV-1) or to an equivalent service (represented by the task SRV-2). For example, if the response time problem was detected for a given operation of a Web Service, the routing mechanism can perform a content-based routing according to the name of the invoked operation (usually included in SOAP messages). In this case, the message will be routed to an equivalent service only if the operation with problems is being invoked. When the equivalent service has a different interface (e.g. given by different WSDL files), transformation mechanisms might be needed in order to transform the request message (TRN-1) or the response message (TRN-2), to comply with the request expected by the service, or the response expected by the client, respectively. Automatic generation of adapters which transform messages to deal with this kind of incompatibilities has been addressed in proposals like [16], which also uses a mediation approach. Given that the required time to perform these transformations can have a considerable impact in the response Figure 6. Distribute Request to Equivalent Services Similar to the strategy described in Section 3.2.1, given that transformations might be required, the time needed to perform these transformations has to be considered. For this strategy, the completion condition for the aggregator mechanism is First Bet. Additionally, the aggregation algorithm for this mechanism is Select the best (first) answer. Note that the generic adaptation flow presented in Figure 6 can lead to various concrete adaptation flows, one for each possible sub-set of equivalent services. 3.3 Strategies for Service Saturation Services saturation is another major concern in service-based systems. This situation occurs when a service receives more requests than the ones it can handle, in a given time interval. This is caused, for example, by peaks of transactions in certain times.

5 Service requests (invocations) are also usually monitored in ESB products, so services saturation can be detected using this information and, for example, SLAs. Services saturation can trigger the requirement to reduce the requests that a service receive in a given time interval. Three possible Adaptation Strategies to achieve this requirement are: load balancing, defer service requests and use previously stored information Load Balancing One way to reduce the number of requests that a service receives in a given time interval, is to use a load-balancing strategy, for example, round-robin. In this way, the requests are balanced among the given service and a set of equivalent services. Figure 7 presents a possible implementation of this strategy using the routing and transformation mechanisms. Figure 7. Load Balancing Messages are first processed by a routing mechanism which, according to a load-balancing strategy, routes the message to the invoked service (represented by the task SRV-1) or to an equivalent service (represented by the tasks SRV-2 and SRV-3). Similar to the strategy described in Section 3.2.1, given that transformations might be required, the time needed to perform these transformations has to be considered. Note that the generic adaptation flow presented in Figure 7 can lead to various concrete adaptation flows, one for each possible sub-set of equivalent services Defer Service Requests Another way to reduce the number of requests that a service receives in a given time interval is to defer the requests. Figure 7 presents a possible implementation of this strategy using the delayer mechanism. Figure 8. Defer Service Requests This strategy has a clear impact in the response time perceived by client applications, so this is something to be considered when selecting this strategy Use Previously Stored Information Even though using previously stored information has traditionally been used to address response time issues, it can also be used to reduce the number of requests a service receives in a time interval. However, as stated before, this strategy is suitable just for services which only return data. 3.4 Summary Figure 9 summarizes, using the conceptual elements defined within the S-Cube Adaptation and Monitoring Framework, the strategies and mechanisms to address response time and service saturation issues. Figure 9. Summary of Strategies and Mechanisms It s important to note that this approach enables to model and to implement jointly different strategies to address QoS. This paper shows this with some already known mechanisms. 4. IMPLEMENTATION ASPECTS The implementation of the proposal is based on prototypes and has enabled to evaluate the feasibility of the approach as well as to identify and analyze key aspects. The approach to implement the adaptive ESB infrastructure consists in extending a general purpose ESB product, concretely JBossESB [17], with the components described in Section 2.2. This section presents some key implementation aspects for the Adaptation Gateway, Virtual Services and Adaptation Services and discusses the results. The implementation of Virtual Services is based on ESBs capabilities to consume external Web Services and to expose them as Web Services through the ESB. These capabilities are provided by most ESB products. In the JBossESB-based implemented prototypes this was done through the SOAPProxy component, which exposes an external Web Service through the ESB. The Adaptation Gateway, which has to intercept all messages sent to the ESB for invoking Virtual Services, was implemented creating an ESB Service, exposed through the Web Service technology. This service constitutes a single entry point to the ESB for all the invocations. The standard WS-Addressing was used to specify the service to be invoked. In turn, the implementation of Adaptation Services requires counting with the different adaptation mechanisms (e.g. routing), a way to build ESB services based on these mechanisms and a way to execute these services through an itinerary. Regarding adaptation mechanisms, transformations, routing, as well as the recipient list and aggregator mechanisms are natively provided by JBossESB. As well, they are also widely supported in other ESB products. However, given that the cache and delayer mechanisms are not usually included in a native way, their implementation would usually require an ad-hoc solution. In particular, the cache mechanism was successfully implemented for the JBossESB product following the guidelines presented in [18]. With respect to creating ESB services based on the previous mechanisms, the prototypes rely on the JBossESB mechanism. This consists of creating ESB Services as action pipelines, in which each action can perform a mediation operation (e.g. a transformation).

6 Finally, the capability to execute services through an itinerary attached to the messages is not always supported in ESB products. For instance, the Microsoft ESB Toolkit [19] provides this functionality out-of-the-box, but JBossESB does not natively include it. However, an initial solution was prototyped in JBossESB by implementing each Adaptation Service using two actions: the first one executes the mediation operation over the message, and the second one routes the message to the next step in the itinerary. The current implementation enabled to evaluate the functional feasibility of using a general purpose ESB to implement the proposed approach. Although some key functions (e.g. the cache mechanism) are not usually provided by these products, implementing them was also feasible. As the used features are mostly implemented in ESB products, these results are also applicable to other ones. Concerning performance and workload, current prototypes do not enable to analyze these aspects and are part of ongoing work. Nevertheless, according to the proposed architecture (Figure 2), decision mechanisms would be executed in a specific component devoted to perform an efficient event and rule processing. Some currently considered options are using an specialized Complex Event Processing engine and rule processing mechanisms (e.g. Drools Fusion [20]). 5. RELATED WORK As stated before, ESBs provide various mediation capabilities which can be used to build mediation flows in order to facilitate the integration and communication between services. However, current ESB products usually support applying these mediation capabilities in a static and manual way, which restricts the rapid responsiveness of the system. This limitation has been identified in various works which propose leveraging ESB capabilities in a more dynamic and automatic way, in particular, to deal with QoS issues. ESB routing capabilities have been addressed in several works proposing solutions to enable dynamic routing. Dynamic routing usually refers to the fact that the possible paths that a message can follow in the ESB are not known at design time. In [21], the authors define a mechanism to route messages based on different factors including services availability. Likewise, in [22] the authors propose selecting services taking into account the results gathered by a testing mechanism which measures different QoS factors, like response time. In [23], the authors propose a dynamic and reliable routing mechanism which selects, at runtime, a list of possible target services to which route a particular request. If the routing to a service fails, the service is marked as inactive so it is not selected anymore as a possible target service. Finally, in [24] the limitation of the static configuration of load-balancing ESB mechanisms is identified. The authors propose solutions to select services at runtime applying different load-balancing strategies, like round-robin and least-loaded. Leveraging ESB mediation capabilities has been also proposed in other works [25][26][27]. One of the most recent [28] proposes an Adaptive ESB as part of an Adaptive SOA platform [29]. The Adaptive ESB focus on adapting service compositions selecting at runtime the services invoked by them. Services selection is based on past invocation and QoS values. Although these works address the problems of dynamic and automatic adaptation within the ESB, in particular to deal with QoS issues, they use a limited number of ESB mediation capabilities and the mediation flows a message can follow is determine at design time. In turn, the solution proposed in this paper makes use of other mediation capabilities (e.g. cache and delayer) and can be extended with other ones. Additionally, unlike other existing proposals, it enables to select at runtime the concrete mediation flow a message can follow, enabling to apply different strategies when a problem is detected (e.g. regarding response time). However, this work is largely compatible with existing proposals and various valuable ideas were taken from previous works including the routing table proposed in [22] and the dynamic mediation capabilities (e.g. dynamic wire tap) proposed in [23]. 6. CONCLUSIONS AND FUTURE WORK While QoS management has been recognized as an essential feature in dynamic SOC contexts, its realization using ESB-based systems largely remains an open issue. In addition, although ESBs mediation capabilities allow addressing several adaptation requirements to cope with QoS issues, they are not executable dynamically or automatically. This motivates using adaptive platforms, which provide much more sophisticated capabilities to achieve automatic changes on the middleware layer (e.g. an ESB). This paper addressed these issues by proposing an approach based on an adaptive ESB infrastructure. The approach leverages ESBs mediation capabilities to dynamically and automatically create adaptation flows through which a message is routed in order to perform the required adaptations. Given that the solution is based on commonly supported ESB patterns, it is likely to be applied in most ESB products. However, the implementation complexity of the solution depends on the functionalities provided by the specific product and its general architecture. Currently, the approach is being implemented using the JBossESB product. The followed approach to address QoS issues has several advantages. Firstly, mediation flows provide a high level mechanism to specify the adaptation strategies. Second, the specification based on YAWL enables a formal treatment of such strategies. Finally, as ESB platforms possess a number of features to address QoS issues, they provide the means to implement a variety of QoS mechanisms in a mainstream infrastructure layer. Conversely, several aspects remain to be solved including the selection of the most suitable adaptation flow and the execution of various adaptation flows when invoking a service. These issues pose relevant challenges to address in future works. The main contributions of this work consist of the definition and specification of mechanisms to address QoS issues within a general purpose middleware platform, focusing on response time and service saturation problems. In addition, as the specification is based on mediation flows that abstract general purpose ESB operations, it enables a wide application. This aims to be a step forward in developing dynamic and automatic adaptation capabilities in service-based systems which run over an ESB infrastructure, concretely addressing QoS. This work is currently being extended by specifying and prototyping different Adaptation Strategies as well as by improving the dynamic overall approach. Future work would consist in dealing with QoS taking into account service compositions and the execution of multiple services, which would

7 lead to considering more complex strategies. Additionally, a detailed analysis of performance and overhead impacts, would include the exploration of emerging tools for processing rules and events in the context of ESBs. 7. REFERENCES [1] C. Cappiello et al., A quality model for service monitoring and adaptation, Workshop on Monitoring, Adaptation and Beyond (MONA+), Madrid, Spain, pp , [2] D. A. Menascé, QoS Issues in Web Services, IEEE Internet Computing, vol. 6, pp , Nov [3] E. Kim et al., Web Services Quality Factors, OASIS. [Online]. Available: [Accessed: Jul-2011]. [4] Schmidt M, Hutchison B, Lambros P, Phippen R. The enterprise service bus: making service-oriented architecture real. IBM Syst. J. 2005;44(4): [5] Michael Papazoglou, Web Services: Principles and Technology, 1st ed. (Prentice Hall, 2007). [6] L. González and R. Ruggia, Towards dynamic adaptation within an ESB-based service infrastructure layer, in Proceed. of the 3rd International Workshop on Monitoring, Adaptation and Beyond - MONA '10, pp , [7] Raman Kazhamiakin, Adaptation and Monitoring in S- Cube: Global Vision and Roadmap, Proceedings of the Workshop on Monitoring, Adaptation and Beyond (MONA+), Madrid, Spain. (June 2009): [8] Enterprise Connectivity Patterns: Implementing integration solutions with IBM's Enterprise Service Bus products, 10- Mar [9] D. Chappell, Enterprise Service Bus: Theory in Practice. O'Reilly Media, [10] A. Metzger and K. Pohl, S-Cube: Enabling the Next Generation of Software Services, in Web Information Systems and Technologies, 2009, pp [11] A. H. M. T. Hofstede, W. M. P. V. D. Aalst, M. Adams, and N. Russell, Modern Business Process Automation: YAWL and its Support Environment, 1st ed. Springer, [12] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, [13] H. A. Sleiman, A. W. Sultán, R. Z. Frantz, and R. Corchuelo, Towards Automatic Code Generation for EAI Solutions using DSL Tools. [14] T. Scheibler and F. Leymann, A Framework for Executable Enterprise Application Integration Patterns, in Enterprise Interoperability III, 2008, pp [15] Integration Flow Language. [Online]. ew. [Accessed: Jul-2011]. [16] Y. Taher, A. Aït-Bachir, M. Fauvet, and D. Benslimane, Diagnosing Incompatibilities in Web Service Interactions for Automatic Generation of Adapters, in 2009 International Conference on Advanced Information Networking and Applications, pp , [17] JBoss ESB - JBoss Community. [Online]. [Accessed: Aug-2011]. [18] R. Yan Fang et al., Cache mediation pattern specification: an overview, 30-May [Online]. -soa-cachemed/. [Accessed: Jul-2011]. [19] Microsoft BizTalk Server ESB Guidance. [Online]. [Accessed: Aug-2011] [20] Drools Fusion. [Online]. [Accessed: Sep-2011] [21] G. Ziyaeva, E. Choi, and D. Min, Content-Based Intelligent Routing and Message Processing in Enterprise Service Bus, in Hybrid Information Technology, International Conference on, vol. 0, pp , [22] X. Bai, J. Xie, B. Chen, and S. Xiao, DRESR: Dynamic Routing in Enterprise Service Bus, in E-Business Engineering, IEEE International Conference on, vol. 0, pp , [23] B. Wu, S. Liu, and L. Wu, Dynamic Reliable Service Routing in Enterprise Service Bus, in Proceedings of the 2008 IEEE Asia-Pacific Services Computing Conference, pp , [24] A. Jongtaveesataporn and S. Takada, Enhancing enterprise service bus capability for load balancing, WSEAS Transactions on Computers, vol. 9, pp , Mar [25] S. H. Chang, H. J. La, J. S. Bae, W. Y. Jeon, and S. D. Kim, Design of a Dynamic Composition Handler for ESB-based Services, in IEEE International Conference on e-business Engineering, ICEBE 2007, pp , [26] H. La, J. Bae, S. Chang, and S. Kim, Practical methods for adapting services using enterprise service bus, Web Engineering, pp , [27] M. Panahi, K. Lin, Y. Z. 0001, S. Chang, J. Zhang, and L. Varela, The LLAMA Middleware Support for Accountable Service-Oriented Architecture, in ICSOC, pp , [28] T. Masternak et al., ESB-Modern SOA Infrastructure, SOA Infrastructure Tools, Concepts And Methods, Poznan University of Economics Press, Dec [29] K. Zielinski et al., Adaptive SOA Solution Stack, IEEE Transactions on Services Computing, vol. 99, no. 1, 2011.