«Aspect-Oriented Web Service Composition with AO4BPEL Anis Charfi1, Mira Mezini Software Technology Group Darmstadt University of Technology ...»
Aspect-Oriented Web Service Composition with
Anis Charfi1, Mira Mezini
Software Technology Group
Darmstadt University of Technology
Abstract. Web services have become a universal technology for integration of
distributed and heterogeneous applications over the Internet. Many recent
proposals such as the Business Process Modeling Language (BPML) and the
Business Process Execution Language for Web Services (BPEL4WS) focus on
combining existing web services into more sophisticated web services.
However, these standards exhibit some limitations regarding modularity and flexibility. In this paper, we advocate an aspect-oriented approach to web service composition and present AO4BPEL, an aspect-oriented extension to BPEL4WS. With aspects, we capture web service composition in a modular way and the composition becomes more open for dynamic change.
Keywords: adaptive web service composition, aspect-oriented programming, separation of concerns, BPEL.
1 Introduction When the Web first emerged, it was mainly an environment for publishing data.
Currently, it is evolving into a service-oriented environment for providing and accessing not only static pages but also distributed services. The Web Services  framework embodies the paradigm of Service-Oriented Computing (SOC) . In this model, applications from different providers are offered as services that can be used, composed and coordinated in a loosely-coupled manner.
Web services are distributed autonomous applications that can be discovered, bound and interactively accessed over the Web. Although there can be some value in accessing a single web service, the greater value is derived from assembling web services into more powerful applications. Web service composition does not involve the physical integration of all components: The basic components that participate in the composition remain separated from the composite web service. As in Enterprise Application Integration (EAI), specifying the composition of web services means specifying which operations need to be invoked, in what order, and how to handle exceptional situations .
1 Supported by the German National Science Foundation (DFG) as part of the PhD program ”Enabling Technologies for Electronic Commerce” at Darmstadt University of Technology.
2 Anis Charfi, Mira Mezini Several composition languages have been proposed e.g., WSCI , BPML  and BPEL4WS . These languages are process-based and have their origins in Workflow Management Systems (WFMS) . A process defines the logical dependencies between the web services to be composed by specifying the order of interactions (control flow) and rules for data transfer between the invocations (data flow). In this paper, we identify two major problems of current composition languages.
The first problem concerns the modularity of the composition specification. A reallife composite web service usually offers several composite operations, each of which is specified as a business process that in turn aggregates other more elementary operations. Such hierarchical modularization of the composition specification according to the aggregation relationships between the involved business processes might not be the most appropriate modularization schema for some aspects of the composition that address issues such as classes of service, exception handling, access control, authentication, business rules, auditing, etc. The code pertaining to these concerns often does not fit well into the process-oriented modular structure of a web service composition, but rather cuts across the process boundaries. Without support for modularizing such crosscutting concerns  (this term is used to describe concerns whose implementation cuts across a given modular structure of the software) their specification is scattered around the processes and tangled with the specification of other concerns within a single process. This makes the maintenance and evolution of the compositions more difficult. When a change at the composition level is needed, several places are affected – an expensive and error-prone process.
The second problem that we identify with process-oriented composition languages concerns support for dynamic adaptation of the composition logic. Such languages assume that the composition logic is predefined and static, an assumption that does not hold in the highly dynamic context of web services. In fact, new web services are offered and others disappear quite often. In addition, the organizations involved in a web service composition may change their business rules, partners, and collaboration conditions. This motivates the need for more flexible web service composition languages, which support the dynamic adaptation of the composition.
In order to tackle these limitations, we propose to extend process-oriented composition languages with aspect-oriented modularity mechanisms. The aspectoriented programming (AOP for short) paradigm  provides language mechanisms for improving the modularity of crosscutting concerns. Canonical examples of such concerns are authorization and authentication, business rules, profiling, object protocols, etc. . The hypothesis underlying AOP is that modularity mechanisms so far support the hierarchical decomposition of software according to a single criterion, based e.g., on the structure of data (a.k.a. object-based decomposition) or on the functionality to be provided (a.k.a. functional decomposition). Crosscutting modularity mechanisms  supported by AOP aim at breaking with this tyranny of a single decomposition  and support modular implementation of crosscutting concerns. Furthermore, with support for dynamic weaving [11, 12, 13], aspects can be activated/deactivated at runtime. In this way, aspects can also be used to adapt the application’s behavior dynamically.
In this paper we present an aspect-oriented extension to BPEL4WS (BPEL for short) and show how this extension is useful for both improving the modularity of web service composition specifications and supporting dynamic adaptations of such Aspect-Oriented Web Service Composition with AO4BPEL 3 compositions. Our approach is not specific to BPEL, though, and can be applied to any process-oriented composition language that supports executable business processes. BPEL was chosen as the basis technology merely because it is becoming the standard language for web service composition.
The remainder of the paper is organized as follows. Sec. 2 gives a short overview of how web service compositions are expressed in BPEL and discusses the limitations of this approach. Sec. 3 gives an overview of our aspect-oriented extension to BPEL and discusses how the limitations identified in Sec. 2 are addressed by it. We report on related work in section 4. Sec. 5 concludes the paper.
2 Process-based Web Service Composition In this section, we shortly introduce web service composition with BPEL as a representative for process-oriented web service composition languages and then consider its limitations.
2.1 Introduction to BPEL4WS BPEL is a workflow-based composition language. In traditional workflow management systems, a workflow model represents a business process that consists of a set of basic and structured activities and the order of execution between them .
BPEL introduces control structures such as loops, conditional branches, synchronous and asynchronous communications. The building blocks of business processes are activities. There are primitive activities such as invoke and structured activities that manage the overall process flow and the order of the primitive activities. Variables and partners are other important elements of BPEL. Variables are used for data exchange between activities and partners represent the parties that interact with the process. Executable BPEL processes can run on any BPEL-compliant execution engine such as BPWS4J . The execution engine orchestrates the invocations of the partner web services according to the process specification.
For illustration, Listing 1 shows a simple BPEL process from . This process returns a string parameter back to the client whenever the operation echo is called. It consists of a sequence activity that contains two basic activities. The activity receive specifies that the process must wait until the client calls the operation echo. The activity reply specifies that the process has to send the message contained in the variable request to the client.
process name = “echoString” …/ variables variable name="request" messageType="StringMessageType"/ /variables partners partner name="caller" serviceLinkType="tns:echoSLT"/ /partners sequence name="EchoSequence" 4 Anis Charfi, Mira Mezini
2.2 Limitations of BPEL4WS BPEL exhibits two major shortcomings: (a) lack of modularity for modeling crosscutting concerns and (b) inadequate support for changing the composition at runtime. In the following we elaborate on each of them.
2.2.1 Lack of Modularity in Modeling Crosscutting Concerns. As already mentioned in the introduction, a hierarchical modularization of the web service composition according to the aggregation relationships between the involved business processes might not be the most appropriate modularization schema for aspects of the composition that address issues such as classes of service, exception handling, access control, authentication, business rules, auditing, etc. Let us illustrate by the example of a simple travel service shown in Figure 1 how the code pertaining to these concerns cuts across the process boundaries and is not modularized. Our example travel web service provides the operations getFlight and getHotel which are specified as BPEL business processes (schematically represented by the vertical bars in Figure 1). A production web service usually provides several composite operations targeting different market segments.
Now, let us consider auditing  - an essential part of any workflow management system concerned with monitoring response times, logging, etc. An organization that composes external partner services is interested in measuring the response times of its partners because the response time of its service depends on those of the partners. The code needed for performing various auditing tasks will be scattered around the processes for composite operations, tangled in all these places with other concerns pertaining to these operations. This is because BPEL does not provide means to express in a modular way (in a dedicated module) at which points during the execution of various processes of a composite web service to gather, what auditing information. The resulting composition definition becomes complex and difficult to reason about it.
Similar modularity deficiencies can also be observed if we consider the calculation of the price for using the composite travel service in Figure 1. The code for the price calculation can certainly be encapsulated in some externalized web service. Both operations getFlight and getHotel in Figure 1 do indeed share such a common billing web service, ws1. What is not encapsulated, though, is the decision about “where” and “when” to trigger the billing functionality, i.e., the protocol that needs to be established between the operations getFlight and getHotel and the billing service. The Aspect-Oriented Web Service Composition with AO4BPEL 5 code that is responsible for invoking the billing service is not modularized in one place: It crosscuts the modular process-based structure of the composition, as illustrated by the grey area cutting across the boundaries of the vertical bars (processes) in Figure 1. As a consequence, if the billing service ws1 is replaced by some other billing service ws2, or the billing policy changes, we would have to change both process specifications for getFlight and getHotel. The problem is much more critical if we have more than two composite operations, which is to be expected in real complex web services. In general, one has to find out all the code that pertains to a certain concern and change it consistently. This is unfortunate especially because business rules governing pricing policies can be expected to change often.
In general, business rules are typical examples of crosscutting concerns  in web service compositions. In the very competitive business context worldwide, business rules evolve very often (new partners, strategies…). Currently business rules are not well modularized in BPEL process specifications. Thus, when new business rules are defined, they get scattered over several processes. The resulting application is badly modularized, which hampers maintenance and reusability .
Again, the problem is that implementing business rules effects, in general, sets of points in the execution of the web services which transcend process boundaries. At present, BPEL does not provide any concepts for crosscutting modularity. This leads to tangled and scattered process definitions: One process addresses several concerns and the implementation of a single concern appears in many places in the process definition. If crosscutting concerns were well separated, process designers could concentrate on the core logic of process composition and process definitions become simpler. One would be able e.g., to exchange security policies without modifying the functional part (independent extensibility).
2.2.2 Changing the Composition at Runtime. When a BPEL process is deployed, the WSDL files of all the services participating in the composition must be known and once a process has been deployed, there is no way to change it dynamically. The only flexibility in BPEL is dynamic partner binding. This static view of the world is 6 Anis Charfi, Mira Mezini inherited from traditional workflow management systems from which the processoriented web service composition model emerged; WFMS exhibit a major deficiency, namely the inadequate support of evolutionary and on-the-fly changes demanded by practical situations .
However, web service compositions implement cross-organizational collaborations, a context in which several factors call for evolution of the composition, such as changes in the environment, technical advances like updating of web services, addition or removal of partner web services, and variation of nonfunctional requirements. Some of these changes require dynamic adaptation, i.e., the composition must be open for dynamic modification, which is not possible in BPEL.