Towards Dynamic Adaptation within an ESB-based
Service Infrastructure Layer
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
Service-oriented systems increasingly need to be self-adaptive in order to respond to dynamic business requirements and to satisfy quality of service conditions in a highly distributed context. Achieving such self-adaptive behavior requires a comprehensive approach throughout the different service-oriented architecture (SOA) layers to avoid, for example, conflicting adaptation actions. In turn, Enterprise Service Buses (ESBs) provide several out-of-the-box mediation features (e.g. message transformation, routing, monitoring) that enable adaptation at the infrastructure layer. However, dynamic adaptation (i.e. adaptation at runtime), a fundamental requirement in self-adaptive systems, is still an open issue in ESB-based platforms. This paper presents an approach that leverages ESBs mediation features to provide dynamic adaptation capabilities within an ESB-based service infrastructure layer. This work, which is based on concepts and frameworks defined within the S-Cube project, intends to be a step forward in developing a comprehensive approach to support self-adaptive service-oriented systems.
Categories and Subject Descriptors
D.2.11 [Software Architectures]: Service-oriented architectures (SOA), Patterns (e.g., client/server, pipeline, blackboard);
General Terms
Design, Management, Reliability
Keywords
self-adaptation, dynamic adaptation, enterprise service bus, service oriented architecture, mediation
1.
I!TRODUCTIO!
As software systems will increasingly operate in a highly dynamic world, they need adaptation capabilities to behave correctly despite unexpected changes in the execution environment. Such context motivates systems, especially service-oriented ones, to be self-adaptive [1]. Self-adaptation allows systems to automatically, autonomously and dynamically respond to changing conditions
which might include, among others, changes in business requirements and quality of service (QoS). This last issue becomes especially important in large scale service-oriented systems (e.g. e-government systems), where their massively distribution introduces numerous challenges in terms of performance, availability, reliability and security, among others. In order to realize self-adaptive behavior, systems have to be equipped with control loops that collect relevant information, from the system and its environment, and act accordingly [1]. In the context of the S-Cube project [2], adaptation in service-oriented architectures (SOAs) has been recognized as a crosscutting issue across the different SOA layers (i.e. the infrastructure layer, the composition layer and the business layer). The project is adopting a comprehensive approach to leverage the adaptation capabilities within each layer to provide overarching solutions [3]. This aims to avoid, for example, conflicting adaptation actions across SOA layers. Additionally, the S-Cube project has specified an integrated Adaptation and Monitoring Framework, which generalizes and broadens the state of the art in SOA adaptation. The framework specifies an overall adaptation process and defines key logical elements including Monitoring Mechanisms, Monitored Events, Adaptation Requirements, Adaptation Strategies and Adaptation Mechanisms [4].
In turn, Enterprise Service Buses (ESBs) are widely recognized as a mainstream middleware to support the service infrastructure layer of a SOA. ESBs provide a middle integration layer, with reusable integration and communication logic, which helps to address mismatches between services regarding communication protocols, message formats, and QoS, among others. Furthermore, propositions like the Internet Service Bus [5] aim to apply these technologies in large scale service oriented systems.
Rather than interacting directly, services communicate through the ESB by sending messages, which can be processed by mediations (e.g. message transformation, routing, monitoring). Mediations (also known as mediation flows) implement the integration and communication logic, and they are the means by which the ESB can ensure that services can connect successfully [6][7]. They aim to accomplish integration and operational requirements within the infrastructure, without involving business level processes. They are usually implemented, configured or customized by an integration expert in a slightly static way (e.g. configuration files). Mediations also provide the means to agilely react to different kinds of changes. For example, if a service modifies its location or its functional interface, an integration expert can configure a routing or a transformation in the ESB, respectively, to make these changes transparent to clients. [6]
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.
MONA '10, 01-DEC-2010, Ayia Napa, Cyprus
However nowadays, the implementation (or configuration) of ESB mediations is usually performed in static (i.e. not at runtime) ways. Therefore, current approaches do not support fully dynamic application of ESB mediation mechanisms (e.g. routing a request to the new location of a service) and require expert intervention to implement them.
This paper presents an approach that leverages ESBs mediation features as building blocks to provide dynamic adaptation capabilities within an ESB-based service infrastructure layer. The proposed approach takes as a basis concepts and frameworks defined within the S-Cube project, so that it can be extended with automatic and cross-layer mechanisms in order to support self-adaptation in service-oriented systems.
The remaining of this paper is organized as follows. Section 2 provides background on the S-Cube project and it presents some common ESB patterns. Section 3 presents some concrete adaptation requirements, showing how ESB mediation patterns can address them. Section 4 describes the proposed approach to achieve dynamic adaptation in ESBs by leveraging its mediation features. Section 5 presents related work. Finally, Section 6 presents conclusions and future work.
2.
BACKGROU!D
This section provides background on the monitoring and adaptation vision within the S-Cube project. It also describes some common ESB patterns identified elsewhere. Both works constitute the basis over which the proposed solution is built.
2.1
Monitoring and Adaptation in S-Cube
The Network of Excellence on Software Services and Systems (S-Cube) performs cross-discipline research to develop solutions for research challenges of next generation service-oriented systems. Research in S-Cube is organized around the S-Cube research framework which is presented in Figure 1. [3]
Figure 1. S-Cube Research Framework [3]
The key elements of the framework comprise the three traditional SOA layers (i.e. service infrastructure (SI), service composition and coordination (SCC), and business process management (BPM)) and three more elements which cover crosscutting issues throughout these layers (i.e. Service Monitoring and Adaptation (SAM), Service Quality Definition, Negotiation and Assurance (SQDNA) and Service Engineering and Design (SED)).
Specifically, the SI layer supports describing, publishing and discovering services, along with primitives for service communication. In addition, the SAM element deals with the cross-layer monitoring of service-oriented systems and its continuous adaptation. [3]
The overall approach of the S-Cube framework is that the traditional SOA layers offer capabilities (e.g. design, monitoring, adaptation) that can be exploited by the other elements of the framework, to define overarching principles and methodologies for addressing the identified crosscutting issues. [8]
In the context of the SAM activities, an integrated Adaptation and Monitoring (A&M) Framework has been defined. As shown in Figure 2, the framework provides a high level view of the key logical elements needed for adaptation in SOA and the dependencies among them. [4][9]
Figure 2. Adaptation and Monitoring Framework [4] Monitoring Mechanisms refer to any mechanism to check if the actual situation corresponds to the expected one. They are used to detect Monitored Events, which represent the fact that there is a difference with respect of the expected system state, functionality or environment. The Monitored Events trigger Adaptation Requirements which represent the need of changing the underlying system, in order to remove the differences between the actual situation and the expected one. Finally, Adaptation Strategies define the possible ways to achieve these requirements and they are realized by Adaptation Mechanisms. [4]
Although, the A&M Framework describes a standard sensing / planning / actuating control chain, its significance is in the very broad meaning of the different concepts, allowing a very general integration of a wide range of mechanisms, techniques and methodologies. [4]
2.2
ESB Patterns
ESB behavior can be characterized through different patterns. This section reviews connectivity patterns, which define high level integration styles, and mediation patterns, which state families of mediation operations. Both types of patterns will be used in the next sections to specify abstract ESB mechanisms.
2.2.1
Connectivity Patterns
Trough the experience gained in many real life implementations, in [10] the authors present a set of patterns which encapsulate the connectivity or mediation logic between a set of applications or services. From an overall integration architecture perspective, they have identified six categories of patterns.
Service virtualization patterns take an existing service and deploy a new virtual service in the ESB. These patterns introduce a point of mediation in the ESB which can be used to route, transform or normalize requests, among others.
Service enablement patterns address the problem of providing a service-oriented interface to functionality which does not have one. These patterns allow leveraging existing assets which might be implemented using diverse technologies across the enterprise.
Gateway patterns are used to apply a common set of mediations to all incoming and/or outgoing messages. For example, a security gateway might perform authentication, authorization or audit operations. After that, the request can be routed to the target service or to further mediations.
Message-based integration patterns are used to build and deploy infrastructure level message-based applications. Functionally, in some regards they correspond to the service virtualization patterns. However, they take a more producer-to-consumer approach instead of the provider-to-producer-to-consumer approach typically taken in SOA.
File processing patterns deal with providing a managed execution environment for the processing of local or remote files through the ESB.
Finally, event-driven integration patterns deal with distribution of events in real time and integration with complex event processing (CEP) engines. The event distributor pattern, for example, allows the distribution of events to multiple interested parties who register to be informed about published events based on a “topic”. The event extractor pattern, monitors interactions across the ESB and passes relevant events to a CEP engine. As well, the event reactor pattern extends the previous one by supporting a synchronous interaction with the CEP engine to be informed if the latest event has triggered a complex event. In this case, the mediation flow can react to it.
Figure 3 graphically presents some of these patterns.
Figure 3. Connectivity Patterns [10]
2.2.2
Mediation Patterns
Mediations are not formally restricted in their capabilities; however, there are a set of basic patterns that are seen repeatedly and have been documented elsewhere [6][11][12][13][14]. These patterns can be grouped in three main categories, i.e. intermediate routing, transformation and management.
Intermediate routing patterns dynamically determine the message path according to different factors. More concretely, a content-based router defines the message path based on its content and a recipient list (also known as distribute or clone) routes the message to a list of dynamically specified recipients. Other basic routing patterns include context-based router, load balancing router, aggregator, message filter (also known as validator), static router, dynamic router, splitter, resequencer and discovery. Transformation patterns deal with the runtime transformation of messages. In [11] the authors identify three types of
transformations: data model transformations, data format transformations and protocol bridging. Additionally, in [14] various transformation patterns are identified including envelop wrapper, content enrichment, content filter, claim check, normalize and canonical data model.
Management patterns are designed to provide monitoring solutions to the ESB infrastructure. In [14] various patterns are identified within this category including wire tap (also known as monitor or log), control bus, message store, message history, smart proxy, test message and channel purger.
Other patterns, not included in the above categories are the cache pattern [15][16], which provides a solution to reuse previous processing, and the asynchronous queuing pattern [11], which enables asynchronous message exchanges and increases the reliability of message transmissions.
These basic patterns can be combined to build more complex ones. For example, the Scatter-Gather [14] pattern can be implemented combining the recipient list and aggregator routing patterns, to maintain the overall message flow when a message is sent to multiple recipients which might send a response. As well, the routing slip pattern [14] (also known as itinerary based routing [17]) routes a message consecutively through a series of processing steps. Finally, the VETO pattern [17] is a common composed integration pattern that stands for Validate, Enrich, Transform and Operate (i.e. invoke the target service).
Figure 4 graphically shows some mediations patterns.
Figure 4. Mediation Patterns
2.3
Monitoring in ESB
Given its mediation role, the ESB is a suitable place to perform monitoring tasks. Indeed, most ESB products include built-in monitoring functionalities, which provide different kind of metrics for the deployed services. For example, response time and the number of successfully processed messages by a service are two commonly provided metrics [18]. Some ESB products also include functionalities to trigger alerts according to the values of these metrics [19][20].
Additionally, ESB products usually incorporate the implementation of some of the management mediation patterns presented in section 2.2.2 (e.g. wire tap). In this way, an integration expert can use them to monitor various aspects (e.g. message content) of the mediation flows and services execution. Finally, the built-in monitoring capabilities may be extended to provide additional monitoring capacities as presented in [18]. As well, CEP engines could be used to detect complex events or patterns based on the monitored information.
3.
Addressing SOA Adaptation Requirements
This section presents the application of the S-Cube Adaptation and Monitoring Framework (Section 2.1 and Figure 2) to an ESB-based SOA environment.
While the addressed Adaptation Requirements correspond to known issues that may occur in SOA configurations, Adaptation Mechanisms are based on ESB mediation features. In turn, Adaptation Strategies aim to represent technical approaches that cope with the Requirements using ESB capabilities. Furthermore, this section builds solutions to the adaptation problems by intensively exploiting the ESB service infrastructure layer.
3.1
Handling a Web Service Interface Change
Services evolution involves major challenges in highly-distributed service-oriented systems. Changes in the service functional interface, a usual evolution scenario, may consist of adding, removing or renaming operations and parameters. [21]
In order to detect Web Services interface changes, different Monitoring Mechanisms can be used. The most interesting are the new subscription features in UDDI v3 [22], which can be used to be notified of Web Services changes. Otherwise an inspection-based approach can be followed, either through an integration expert periodically accessing Web Services descriptions (e.g. WSDL [23]) and comparing the current descriptions with the previous accessed ones or automating these tasks.
In some cases, a Web Service interface change can be handled using the ESB mediation features. In this way, client applications remain unaware of the change and do not have to be modified. For example, if an input parameter is removed from one of the operations of a Web Service, a possible Adaptation Strategy is modifying subsequent service requests to comply with the new service interface (i.e. taking out the removed parameter). This strategy can be achieved in the ESB using different Adaptation Mechanisms, for example, applying a transformation to the request. Figure 5 shows the implementation of such mechanism using a mediation flow consisting of a content-based router (CBR), a content filter (CF) and a static router (SR).
Figure 5. Transforming a Service Request
The content-based router inspects the request (e.g. SOAP [24]) and, if the invoked operation is the modified one, it routes the request to the content-filter; otherwise, it routes the message to the service specific mediations. When the content filter receives the request, it performs the required transformation to take out the information of the removed parameter. This transformation could be specified by the integration expert using, for example, XSLT [25]. After that, the static router also routes the request to the service specific mediations.
However, if the interface change cannot be addressed by a transformation, an alternative Adaptation Strategy to handle this Adaptation Requirement is to invoke an equivalent service. In this case the integration expert needs to query the ESB registry in
order to discover an equivalent service. An Adaptation Mechanism to carry out this strategy is routing requests to the discovered service. This could require performing an extra transformation, in case the original service and the equivalent one do not share the same interface.
Figure 6 presents the adaptation mediations, consisting of a transformation (TR) and a static router (SR), to implement this mechanism when the services do not share the same interface.
Figure 6. Routing to an Equivalent Service
Finally, Figure 7 summarizes the mechanisms, events and strategies that deal with interface changes.
Figure 7. Dealing with a Web Service Interface Change
3.2
Reducing Response Time
Performance, and more concretely response time, is also a major concern in SOA. The massively distribution of service-oriented systems, the widely use of XML as message format, which involves packaging and parsing tasks, and the mediation operations that a message might undergo are some of the reasons which can cause a considerable overhead in the interactions between providers and consumers. [15]
Built-in ESB monitoring functionalities, which usually include an administrative console to analyze QoS metrics, are one of the Monitoring Mechanisms that an integration expert might leverage to detect response time issues. These features usually incorporate application programming interfaces (APIs) so they can be accessed programmatically. Equally, the expert might configure alerts, provided by some ESB products, in order to be informed of problems (e.g. if the response time of a service is not as expected) as soon as they occur.
When an ESB sits between service consumers and providers, there are various ways in which the response time might be improved. A possible Adaptation Strategy to handle this Adaptation Requirement is using information previously processed. This strategy is specially appropriated for services which only return data. Using a cache service [15] is one of the Adaptation Mechanisms to realize this strategy within an ESB infrastructure. Figure 8 shows a possible implementation of this Adaptation Mechanism using an ESB mediation flow. In this case, the integration expert detected that from 9:00 am to 11:00 am the response time of a service was higher than the expected. So, the mediation flow consists of a router and a cache service. If a
request arrives between 9:00 am and 11:00 am, the router routes the message to the cache; otherwise, it routes it to the service.
Figure 8. Using a Cache Service
An alternative Adaptation Strategy to the same requirement would be based on invoking an equivalent service with a better performance. As stated in section 3.1, an Adaptation Mechanism to carry out this strategy is routing the requests to an equivalent service. However, in this case, it is preferable that the original and the equivalent service share the same interface, in order to avoid additional transformations which might have side effects on performance.
Figure 9 presents a possible implementation of this last approach. Similarly to the previous example, the integration specialist detected some performance issues between 9:00 am and 11:00 am. Therefore, a mediation flow was implemented in the ESB consisting of a router which routes requests, arriving between 9:00 am and 11:00 am, to an equivalent service.
Figure 9. Routing to an Equivalent Service
Finally, Figure 10 summarizes the mechanisms, events and strategies that deal with reducing the response time.
Figure 10. Dealing with Response Time Issues
3.3
Other Adaptation Requirements
There are many other Adaptation Requirements that could be addressed using the ESB mediation features. This section briefly describes some of them.
Regarding services changes, other Adaptation Requirements that might arise are handling a change in the location of a service or handling the removal of a service from the service portfolio. A possible Adaptation Strategy to deal with them is invoking an equivalent service which, as stated in previous subsections, can be realized by routing service requests in the ESB.
Besides response time, there are others QoS factors that might presents issues in a SOA, including availability. Issues regarding availability can also be handled by invoking equivalent services. Additionally, another possible Adaptation Strategy is invoking a set of services to have more chances that one can response, increasing in this way the availability degree perceived by client
applications. This strategy can be realized in the ESB using the Scatter-Gather mediation pattern described in Section 2.2.2. Service Saturation, another commonly problem seen in a SOA, may be caused, for example, by peaks of transactions in certain times. An Adaptation Strategy to address this issue would be to invoke other services handling some of the requests through a load balancing approach. This strategy can be performed in the ESB using the load-balancing router mediation pattern. Another Adaptation Strategy to use in this case is differing calls to the service, in order to avoid sending more than a number of messages to the service during a period of time. This strategy can be executed in the ESB by using the asynchronous queuing mediation pattern. In order to choose one or other strategy to handle service saturation, one might take into account many factors, for example, the interaction patterns supported by the service (e.g. request/reply, one way).
4.
Achieving Dynamic Adaptation in ESBs
As presented in section 3, ESBs provide mediation capabilities that enable addressing various SOA Adaptation Requirements. However, although some of these adaptations actions are well known and have been effectively used in practice (e.g. cache), dynamic adaptation within ESBs largely remains an open issue. This section presents an approach to provide dynamic adaptation capabilities in an ESB-based service infrastructure layer. The proposed solution leverages the mediation features provided by ESBs and allows them to be applied dynamically at runtime. The general idea is to intercept all ESB messages, determine if an adaptation is required, and drive them through adaptation paths, which take the message through a series of mediations steps in order to carry out a specific Adaptation Strategy. Adaptation paths, which implement Adaptation Strategies (e.g. invoke equivalent service) using the available Adaptation Mechanisms (e.g. routing service requests), are dynamically created taking into account monitored data and services metadata. The proposed solution follows the key ideas of the S-Cube project by providing capabilities to enable cross-layer mechanisms to leverage them and handling the key logical elements of its A&M Framework.
4.1
Overall Approach
The solution assumes that services and applications communicate by sending messages through an ESB, applying the service virtualization or service enablement patterns described in Section 2.2.2. Additionally, services and applications may also be hosted by third-parties whose infrastructure does not support dynamic adaptation and over which there is no control.
The general idea to achieve dynamic adaptation is to process all ESB messages by means of an Adaptation Gateway within the ESB. The Adaptation Gateway aims to determine if an adaptation is required and to attach a dynamically generated Adaptation Path (AP) to the messages that have to be adapted (following the routing slip pattern). The AP contains all the required mediations steps (e.g. transformation, routing) that have to be consecutively executed to implement a specific Adaptation Strategy (e.g. invoke an equivalent service). Mediations steps can be, but are not restricted to, any of the basic mediation patterns described in Section 2.2.2. If an adaptation is required, the Adaptation Gateway drives the message to the first step in the AP. Otherwise the message follows its original path.
Figure 11 presents an example of this process.
Figure 11. Adaptation Example
In the example, a message sent by the client invocation follows the steps:
1. The message is created by a client and sent through the ESB in order to invoke a service.
2. The message is routed to the Adaptation Gateway. 3. The Adaptation Gateway, based on information provided
by other components, determines that an adaptation is required and attaches an AP to the message. In this case, the AP consists of two steps: a Transformation (TR) step and Static Router (SR) step
4. The Adaptation Gateway routes the message to the first step in the AP (the TR step).
5. The TR step performs the required transformation and removes itself from the message AP.
6. The TR step routes the message to the next step in the AP (the SR step).
7. The SR step removes itself from the AP.
8. The SR step routes the message to the service specific mediations.
9. Service specific mediations are performed. They might transform the message.
10. The message is routed to the service.
In order to know if an adaptation action is required and to obtain the APs, the Adaptation Gateway relies in a component named Adaptation Manager. The Adaptation Manager interacts with a global Service Adaptation and Monitoring (SAM) engine, to determine whether an adaptation action should be performed. Section 4.2 presents in more detail the interactions with this engine. As well, in order to obtain the APs that implement a specific Adaptation Strategy, the Adaptation Manager relies on a component named Adaptation Path Builder (APB). Section 4.3 describes in more detail Adaptation Strategies and how APs are dynamically created.
Cross-layer mechanisms, covering BPM and SCC layers (Figure 1) [3], would be addressed by integrating specialized tools (i.e. service composition and coordination, process management). Although enterprise platform middleware provides mechanisms that facilitate the integration of such specialized tools [17], these issues require a deeper analysis and extensive work.
4.2
Interactions with the SAM Engine
The SAM engine is the component (or group of components) that deals with adaptation using a comprehensive approach across the
SOA layers. In order to support this comprehensive approach, the proposed ESB-based service infrastructure layer interacts with this engine by providing monitoring and adaptation capabilities. Figure 12 presents the runtime interactions of the SAM engine with two of the components of the proposed solution: the Monitoring Manager and the Adaptation Manager.
Figure 12. Interactions with the SAM engine
The Monitoring Manager sends data monitored within the ESB by interacting with the different ESB Monitoring Mechanisms. This monitored information is provided in the form of topics to which the SAM engine can subscribe, leveraging in this way the implementation of the event distributor patter usually found in ESBs. In this way, the SAM engine can receive monitored data (e.g. response time values) and monitored events (e.g. interface changes). Complex events can also be detected and informed using, for example, CEP engines.
On the other side, the Adaptation Manager receives and stores adaptation directives in the form of Adaptation Strategies which have to be supported by the ESB-based service infrastructure layer. As stated before, these directives are then communicated to the Adaptation Gateway so they can be applied to subsequent requests/responses. Additionally, the Adaptation Manager can communicate with the SAM engine, in a request/reply fashion, in order to obtain adaptation actions when they depend on context or runtime values (e.g. the content of the request/response message). With these monitoring and adaptation capabilities, the SAM engine is able to implement automatic decision mechanisms to detect Monitored Events, trigger Adaptation Requirements, and select Adaptation Strategies. For example, if the number of messages sent to a service and its response time are increasing, a “service saturation” event can be triggered.
Even though the previous example only takes in consideration elements of the infrastructure layer, the monitoring and adaptation capabilities provided by the solution approach can be used to support cross-layer adaptation solutions, which constitutes a basis to achieve self-adaptation in SOA.
4.3
Adaptation Strategies
Within the proposed solution, Adaptation Strategies are implemented as ESB mediation flows (called Adaptation Paths) to which messages are dynamically routed in order to accomplish the required adaptations. The APs are dynamically built using as building blocks the Adaptation Mechanisms supported by the ESB-based infrastructure. These mechanisms include any of the mediation patterns described in Section 2.2.2 (e.g. transformation).
In order to implement an Adaptation Strategy, different APs might be built depending on various factors. For example, an AP for the “invoke an equivalent service” strategy will have a transformation step only if the request is being routed to a service with a different interface.
In order to support an Adaptation Strategy, an ESB-based service infrastructure has to specify the logic to implement all the possible APs for the given strategy. This logic can use various runtime factors (e.g. requested service) and other ESB services (e.g. Service Registry).
For example, Figure 13 presents a method which builds APs for the “invoke an equivalent service” strategy. The method receives the service for which the adaptation is required, discovers an equivalent service from the registry and adds a transformation step only if the interfaces of the services are not equal.
Figure 13. Building Adaptation Paths
Additionally, the ESB infrastructure has to support the mediation steps included in all the possible APs for the strategy. This mediation steps are supported in the ESB infrastructure by implementing static ESB mediations with two operations: perform the mediation and route to the next step in the AP, if any. As soon as an adaptation directive (i.e. Adaptation Strategy) for a service is received by the Adaptation Manager, the APB constructs the AP using the strategy specific logic. This AP is stored to be provided when a request arrives for the given service. Additionally, it can be periodically refreshed and have an expiration time.
Likewise, there are some situations in which the APs cannot be created, at least completely, until a request/response arrives. For example, if the construction logic depends on runtime information like the content of the message. In these cases, the building of the AP is delayed until this moment.
5.
RELATED WORK
Adaptation within the infrastructure layer has been addressed in areas like Grid Computing [26]. ESB-based approaches to implement dynamic adaptation allow performing adaptations even when services are hosted by third-parties. In these contexts, service can be deployed in infrastructures that might not support dynamic adaptation and over which there is no control.
Dynamic adaptation in ESBs has been recently addressed [27][28][29][30][31][32][33]. For example in [28] a framework to allow content-based intelligent routing is proposed. The framework allows choosing a suitable service provider for a request, and defines a mechanism to evaluate service availability and select services based on message content. However, the authors only focus on the routing capability and do not consider other ESB features that can be dynamically applied. In [31] the authors identify different types of service variability and, using the key features of ESBs, they present practical methods for
adapting services using an ESB. However, the authors focus on adapting services to different clients and do not analyze adaptations to address services changes. In [33] a practical framework for dynamic service composition is proposed. Concretely, the authors present the design of a dynamic composition handler for ESB-based services which allows service to be discovered, selected, composed and adapted at runtime. However, they do not focus either in addressing service changes. Additionally, neither of these works considers adaptation as a crosscutting issue across the different SOA layers.
6.
CO!CLUSIO!S A!D FUTURE WORK
While dynamic adaptation has been recognized as a fundamental feature in modern large-scale service-oriented systems, implementing these capabilities in the context of ESB-based systems largely remain an open issue. Nowadays, although ESBs’ mediation features allow addressing several SOA adaptation requirements, they are not executable dynamically or automatically. This restricts the rapid responsiveness of the system and the generality of the implementation mechanisms. This paper addressed these matters by proposing an approach to achieve dynamic adaptation in an ESB-based service infrastructure layer. The approach leverages ESBs mediation features as building blocks to dynamically create adaptation paths through which a message can be routed in order to perform the required adaptations. Additionally, the solution is based on the logical architecture defined within the S-Cube project and handles the key logical elements of its integrated A&M Framework. 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 will depend on the functionalities provided by the specific product and its general architecture. Currently, the approach is being implemented using the JBoss ESB [34] product.
The main contributions of this paper consist of describing an adaptation framework based on ESB capabilities and addressing some concrete Adaptation Requirements through ESB features. Furthermore, the current proposal could be further extended to use other types of Adaptation Mechanisms. For example, the adaptation of service specific mediation flows defined in a static way. As well, the adaptation of ESB system level parameters (e.g. number of threats to process requests). This aims to be a step forward in developing dynamic-adaptation capabilities in service-oriented systems, concretely in ESB-based ones. This work is currently being extended by specifying other Adaptation Strategies as well as by improving the dynamic overall approach. Future work would consist in dealing with the composition of adaptation paths when various Adaptation Requirements are triggered for a service, as well as with the cross-layer adaptability issues.
7.
REFERE!CES
[1] Di Nitto E, Ghezzi C, Metzger A, Papazoglou M, Pohl K. A journey to highly dynamic, self-adaptive service-based applications. Automated Software Engineering. 2008;15(3):313-341.
[2] Software Services and Systems Network (S-Cube).
[3] Metzger, A. Pohl, K. “Towards the Next Generation of Service-Based Systems: The S-Cube Research Framework,” in Advanced Information Systems Engineering, 2009, 11-16. [4] 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): 67-76.
[5] Donald F. Ferguson, Dennis Pilarinos, John Shewchuk. The Internet Service Bus. The Architecture Journal. Journal 13. Microsoft. 2007.
http://msdn.microsoft.com/en-gb/bb906065.aspx [Accessed: September 2010] [6] Schmidt M, Hutchison B, Lambros P, Phippen R. The
enterprise service bus: making service-oriented architecture real. IBM Syst. J. 2005;44(4):781-797.
[7] Michael Papazoglou, Web Services: Principles and Technology, 1st ed. (Prentice Hall, 2007).
[8] Pistore, M., Kazhamiakin, R., Bucchiarone, A., eds.: Integration Framework Baseline. SCube project deliverable (2009): CD-IA-3.1.1.
[9] Hielscher, J., Metzger, A., Kazhamiakin, R., eds.: Taxonomy of Adaptation Principles and Mechanisms. S-Cube project deliverable (2009): CD-JRA-1.2.2.
[10] Helen Wylie and Peter Lambros, “Enterprise Connectivity Patterns: Implementing integration solutions with IBM's Enterprise Service Bus products,” CT316, March 10, 2009. [11] Thomas Erl, SOA Design Patterns, 1st ed. (Prentice Hall
PTR, 2009).
[12] Colombe Hérault, Gaël Thomas, and Université Joseph Fourier, “Mediation and Enterprise Service Bus: A position paper,”. Procs. of the 1st Intl. Workshop on Mediation in Semantic Web Services (MEDIATE (2005).
[13] Donald Ferguson and Marcia Stockton, “SOA programming model for implementing Web services, Part 1: Introduction to the IBM SOA programming model,” CT316, June 14, 2005, http://www.ibm.com/developerworks/webservices/ library/ws-soa-progmodel/. [Accessed: September 2010] [14] Gregor Hohpe and Bobby Woolf, Enterprise Integration
Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Professional, 2003).
[15] Yan Fang R, Ru F, Zhong T, et al., “Cache mediation pattern specification: an overview,” CT316, May 30, 2006, http://www.ibm.com/developerworks/webservices/library/ws -soa-cachemed/ [Accessed: September 2010].
[16] Balasubramanian, Carlyle, Pautasso. “Response Caching Pattern” http://www.soapatterns.org/response_caching.php. [Accessed: September 2010]
[17] David Chappell, Enterprise Service Bus: Theory in Practice (O'Reilly Media, 2004).
[18] Yuan H, Choi SW, Kim SD. A Practical Monitoring Framework for ESB-Based Services. In: IEEE Congress on Services Part II, 2008. SERVICES-2.; 2008:49–56. [19] ESB Administration Guide. Chapter 6. Monitoring and
Management in the ESB. http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/5.0.0/html/Administration_Guide/. [Accessed: September 2010].
[20] Mule ESB Enterprise. Management Console. Monitoring and Management for Mule ESB.
http://www.mulesoft.com/downloads/management-console.pdf. [Accessed: September 2010].
[21] Papazoglou M. The challenges of service evolution. In: Advanced Information Systems Engineering.; 2008:1–15. [22] Luc Clement, Andrew Hately, Claus von Riegen, Tony
Rogers. OASIS. Universal Description Discovery & Integration (UDDI) 3.0.2. 2004.
http://www.uddi.org/pubs/uddi_v3.htm. [Accessed: September 2010].
[23] Christensen, E. Curbera, F. Meredith, G. Weerawarana, S. W3C. Web Services Description Language 1.1. 2001. http://www.w3.org/TR/wsdl. [Accessed: September 2010]. [24] Gudgin, M. Hadley, M. Noah Mendelsohn, Jean-Jacques
Moreau, Henrik Frystyk Nielsen, Anish Karmarkar, Yves Lafon. Simple Object Access Protocol (SOAP) 1.2. 2007. http://www.w3.org/TR/soap12-part1/. [Accessed: September 2010].
[25] James Clark, W3C. XSL Transformations. 1999. http://www.w3.org/TR/xslt. [Accessed: September 2010]. [26] Németh, Zsolt . eds.: Use Case Description and
State-of-the-Art. SCube project deliverable (2009): PO-JRA-2.3.1. [27] K. Lin. S. Chang. A service accountability framework for
QoS service management and engineering. Information Systems and e-Business Management 7, no.4 (2009):429– 446.
[28] Ziyaeva G, Choi E, Min D. Content-Based Intelligent Routing and Message Processing in Enterprise Service Bus. In: Hybrid Information Technology, International
Conference on.Vol 0. Los Alamitos, CA, USA: IEEE Computer Society; 2008:245-249.
[29] Bai X, Xie J, Chen B, Xiao S. DRESR: Dynamic Routing in Enterprise Service Bus. In: E-Business Engineering, IEEE International Conference on.Vol 0. Los Alamitos, CA, USA: IEEE Computer Society; 2007:528-531.
[30] Mi X, Tang X, Yuan X, Chen D, Luo X. Multifactor-Driven Hierarchical Routing on Enterprise Service Bus. Web Information Systems and Mining. 2009:328–336.
[31] La H, Bae J, Chang S, Kim S. Practical methods for adapting services using enterprise service bus. Web Engineering. 2007:53–58.
[32] Liu Y, Babar M, Gorton I. Middleware Architecture Evaluation for Dependable Self-managing Systems. Quality of Software Architectures. Models and Architectures. 2008:189–204.
[33] Chang SH, La HJ, Bae JS, Jeon WY, Kim SD. Design of a Dynamic Composition Handler for ESB-based Services. In: IEEE International Conference on e-Business Engineering, 2007. ICEBE 2007.; 2007:287–294.
[34] JBoss ESB. http://www.jboss.org/jbossesb/ [Accessed: November 2010]
