«Aspect-Oriented Web Service Composition with AO4BPEL Anis Charfi1, Mira Mezini Software Technology Group Darmstadt University of Technology ...»
One might argue that if a runtime process change is required, we just have to stop the running process, modify the composition, and restart. This is actually the only way to implement such changes in BPEL. However, this is not always a feasible solution for several reasons. First, stopping a web service may entail a loss of customers. Second, especially in B2B scenarios, a composite operation may run very long, which may prevent us from stopping it. If we stop such a long-running transaction, we must roll back or compensate all previously performed activities.
Third, the modification of the composition schema on a case-by-case basis leads to all kinds of exceptions. Last but not least, several situations require runtime ad-hoc derivation from the original planned business process. In general, such derivations are necessary if users are involved in making decisions and also if unpredictable events occur . Such changes should affect only some process instances at runtime.
Assume that we want to add car rental to the composite operations getTravelPackage and getFlight. This way, when the client requests a flight or a travel package, she also gets propositions for car rental. One can also envisage Aspect-Oriented Web Service Composition with AO4BPEL 7 variations of this adaptation, where such an offer is only made to frequent customers or to those clients that have specified interest in the offer in their profiles. In this case, the adaptation should be effective only for specific business process instances.
It should be noted that the adaptations of the composition logic such as the one illustrated here require, in general, a semantic adaptation mechanism to bridge the compositional mismatch . In component composition languages  this kind of adaptation is enabled by glue code. Similarly, when we compose web services, we have to adapt their interfaces by writing glue code. BPEL supports only data adaptability by means of the assign activity. This activity allows one to create new messages or modify existing ones, using parts of other messages, XPath expressions, or literal values. Data adaptability deals with the structure of data. Glue code support is still missing in BPEL.
3 Aspect Oriented Web Service Composition
Aspect-Oriented Programming (AOP)  is a programming paradigm explicitly addressing the modularization of crosscutting concerns, which makes AOP the technology of choice to solve the problems discussed in Sec. 2. While it has been mostly applied to object-oriented programming, it is applicable to other programming styles , including the process-oriented style. We propose to use aspects as a complementary mechanism to process-oriented web service composition and argue that the definition of dynamic aspects at the BPEL level allows for more modularity and adaptability.
3.1 Introduction to Aspect-Oriented Programming
AOP introduces a new unit of modularity called aspect aimed at modularizing crosscutting concerns in complex systems. In this paper, we will use the terminology of AspectJ , the most mature AOP language today. In this terminology, there are three key concepts of AOP: join points, pointcuts and advice. Join points are points in the execution of a program . In object-oriented programs, examples of join points are method calls, constructor calls, field read/write, etc.
In order to modularize crosscuts, a means is needed to identify related join points.
For this purpose, the notion of a pointcut is introduced – a predicate on attributes of join points. One can select related method execution points, e.g., by the type of their parameters or return values, by pattern matching on their names, by their modifiers, etc. Similar mechanisms are available to select sets of related setter / getter execution points, sets of constructor calls / executions, exception handlers, etc. Current AOP languages come with predefined pointcut constructs (pointcut designators) in AspectJ.
Finally, behavioral effect at join points identified by a pointcut is specified in an advice. The advice code is executed when a join point in the set identified by the pointcut is reached. It may be executed before, after, or instead, the join point at hand, corresponding to before, after and around advice. The code specified in a before, respectively after advice is executed before, respectively after the join points in the 8 Anis Charfi, Mira Mezini associated pointcut have executed. With the around advice the aspect can control the execution of the original join point: It can integrate the further execution of the intercepted join point in the middle of some other code to be executed around it.
An aspect module consists in general, of several pointcut definitions and advice associated to them. In addition, it may define state and methods which in turn can be used in the advice code. Listing 2 shows a simple logging aspect in AspectJ, which defines a pointcut loggableMethods specifying where the logging concern should be integrated into the execution of the base functionality – in this case, the interesting join points are the executions (the call pointcut designator) of all public methods called bar, independent of the class they are defined in, their return type, as well as the number and type of the parameters (wildcards * and..). The aspect also defines an advice associated to the pointcut loggableMethods that prints out a logging message before any of the points in loggableMethods is executed. The advice specifies when and what behavior must execute at the selected join points.
Integrating aspects into the execution of the base functionality is called weaving. In static AOP approaches, as e.g., in AspectJ, at compile-time/load-time pointcuts are mapped to places in the program code whose execution might yield a join point at runtime. The latter are instrumented to add calls to advice and eventually dynamic checks that the identified places in code do actually yield a join point at runtime .
In dynamic AOP [11, 12, 13] languages, aspects can be (un)deployed at application runtime, the behavior of which can thus be adapted dynamically.
3.2 Overview of AO4BPEL
Here we present AO4BPEL, an aspect-oriented extension to BPEL4WS, in which aspects can be (un)plugged into the composition process at runtime. Since BPEL processes consist of a set of activities, join points in our model are well-defined points in the execution of the processes: Each BPEL activity is a possible join point.
Pointcuts in AO4BPEL are a means for referring to (selecting) sets of join points that span several business processes at which crosscutting functionality should be executed. The attributes of a business process or of a certain activity can be used as predicates to choose relevant join points. E.g., to refer to all invocations of a partner web service, we use the attributes partnerLink and portType of the activity invoke.
Since BPEL processes are XML documents, XPath  – a query language for XML documents – is a natural choice as the pointcut language. In an AO4BPEL aspect, the Aspect-Oriented Web Service Composition with AO4BPEL 9 element pointcut is an XPath expression selecting those activities where the execution of additional crosscutting functionality will be integrated. XPath provides logical operators, which can be used to combine pointcuts.
Like AspectJ, we support before, after and around advice. An advice in AO4BPEL is an activity specified in BPEL that must be executed before, after or instead of another activity. The around advice allows replacing an activity by another (dummy) activity. Sometimes we need to define some advice logic which cannot be expressed in BPEL4WS. One could use code segments in a programming language like Java in Collaxa’s JBPEL  for this purpose. However, this breaks the portability of BPEL processes, which is the reason for us to use what we call infrastructural web services.
Such services provide access to the runtime of the orchestration engine. We set up a Java code execution web service, which invokes an external Java method in a similar way to Java Reflection. Each code snippet that is required within an AO4BPEL advice can be defined as a static method in a Java class.
Figure 3 sketches the overall architecture of our aspect-aware BPEL orchestration engine. The system consists of five subcomponents: the process definition and deployment tool, the BPEL runtime, the aspect definition and deployment tool, the aspect manager, and the infrastructural services. The core components are the BPEL runtime and the aspect manager. The BPEL runtime is an extended process interpreter. It manages process instances, message routing and takes aspects into account. The aspect definition and deployment tool manages the registration and activation of aspects. The aspect manager controls aspect execution.
Fig. 3. Architecture of an aspect-aware web service composition system In our first implementation, we intend to support only invoke and reply join points because basic activities represent the interaction points of the composition with the external partners. The most straightforward way to implement a dynamic aspectaware orchestration engine is to extend the process interpreter function to check if there is an aspect before and after the interpretation of each activity. If this is the case, the aspect manager executes the advice and then returns control to the process interpreter. We believe that for the first prototype, the performance overhead induced by these local checks is negligible compared to the cost of interacting with an external web service.
10 Anis Charfi, Mira Mezini
3.3 Examples Revisited In this section, we show how the examples from Section 2 are modeled in AO4BPEL.
3.3.1 Modularizing Crosscutting Concerns. To illustrate the modularization of crosscutting concerns, consider the AO4BPEL aspect Counting in Listing 3 which collects auditing data: It counts how many times the operation searchFlight of Lufthansa has been invoked. The counting advice must execute after each call to that operation. Ideally, we have to save this information into a file in order to evaluate it later, i.e., we need to access the file system. This cannot be done in BPEL and some programming logic is necessary. The Java code execution web service comes into play here. This web service provides the operation invokeMethod which takes as parameters the class name, the method name, and the method parameters as strings. It supports only primitive parameter types i.e., integers and strings. When the process execution comes to a join point captured by the pointcut Lufthansa Invocations, the static method increaseCounter is called, which opens a file, reads the number of invocations, increments it and then saves the file to disk.
aspect name="Counting" partnerLinks partnerLink name="JavaExecWSLink" …/ /partnerLinks variables variable name="invokeMethodRequest" …/ /variables pointcutandadvice type="after" pointcut name="Lufthansa Invocations" //process//invoke[@portType ="LufthansaPT" and @operation ="searchFlight"] /pointcut advice sequence assign copy fromincreaseCounter/from to variable="invokeMethodRequest" part="methodName"/ /copy… /assign invoke partnerLink="JavaExecWSLink" portType="JavaExecPT" operation="invokeMethod" inputVariable="invokeMethodRequest"/ /sequence /advice /pointcutandadvice /aspect Listing. 3. The counting aspect This aspect shows how crosscutting concerns can be separated from the core of the composition logic. The monitoring functionality is not intertwined with the process definition. Moreover, we can define several monitoring aspects implementing different policies and weave the appropriate one according to the context.
Aspect-Oriented Web Service Composition with AO4BPEL 11 3.3.2 Changing the Composition. In Section 2, we wanted to add car rental business logic into the composite operations getTravelPackage and getFlight, and argued that such an adaptation cannot be performed dynamically with BPEL. For achieving the same goal in AO4BPEL, the administrator defines the aspect AddCarRental shown in Listing 4. This aspect declares a pointcut, which captures the accommodation procurement activity in the getTravelPackage and the flight procurement activity in getFlight. The car rental activity must be executed after the join point activities referred to by the pointcut (after advice). This aspect also declares partner links, variables, and assignment activities. The assign activity is required to transform the data returned by the operations getTravelPackage and getFlight.
aspect name="AddCarRental" partnerLinks partnerLink name="carRentalPortal" …/ /partnerLinks variables variable name="getCarRequest" …/ variable name="getCarResponse" …/ /variables pointcutandadvice type= "after" pointcut name="accommodation procurement" //process[@name="getTravelPrcs"]//sequence[@name="FlightHotel"] //invoke[@portType ="HotelPT" and @operation ="findRoom"] union //process[@name="getFlightPrcs"]//flow[@name="FlightSearchFlow"] /pointcut advice invoke partnerLink="CarRentPortal" portType="carRentPT" operation="getCar" inputVariable="getCarRequest" ouputVariable="getCarResponse"/ assign … /assign /advice /pointcutandadvice /aspect Listing. 4. The car rental aspect The administrator must register the aspect with the BPEL execution engine. During the registration, the aspect definition and deployment unit of our BPEL engine requests the programmer to input the WSDL and the port address of the car rental web service. This step also requires the partnerLinkTypes that are used by the aspect.
The aspect becomes active only after explicit deployment. The aspect activation can be performed dynamically while the respective process is running. This way, we apply the adaptation behavior at runtime.
One can conclude that this aspect tackles the problem outlined in Section 2. It allows for dynamic change. We specified the new business rule in a modular way as an aspect. If the business rules changes, we only have to activate/deactivate the appropriate aspect at execution time.
12 Anis Charfi, Mira Mezini
4 Related Work