Join point model and pointcut language

Join point model

AO4BPEL supports two kinds of join points: activity join points, which cor- respond to the execution of BPEL activities, and internal join points, which correspond to internal points during the interpretation of messaging activities.

Internal join points capture well-defined points at the interpretation level rather than at the process level. The interpretation of a messaging activity is broken into several internal join points, which capture for instance the point where the outgoing SOAP message of an invoke activity will be sent out.

Internal join points allow the aspect to express statements such as ”before a SOAP message is sent out in the course of interpreting a messaging activity, get that message and do this and that ”. In this example, the internal join point is the point in the execution where a SOAP message of a messaging activity has been generated and it is about to be sent out.

Internal join points are especially relevant for capturing middleware concerns such as security [36] and reliable messaging [42]. More details on the usage of these join points for providing middleware support to BPEL processes will be given in Chapter 6.

A query-based pointcut language

In aspect-oriented programming languages such as AspectJ, pointcuts are de- fined by means of pointcut designators, which are predicates on join points. AspectJ provides a set of predefined pointcut designators such as call, which selects method call join points.

The pointcut language of AspectJ has three limitations: a) it does not pro- vide a general-purpose mechanism to relate different join points, b) it is not extensible, i.e., the user cannot define further pointcut designators, and c) it does not support semantic pointcuts [89, 117], i.e., it specifies how the interest- ing join points are implemented rather than what these join points are [74].

Query-based pointcut languages [74] solve these limitations by using query languages such as XQuery [190]. First, such languages allow a more precise spec- ification of the pointcuts because the semantics of query languages are generally clear. Second, they enable open pointcut languages, where users can define their own pointcut designators. Third, they support more semantic pointcuts by spec- ifying what the interesting join points are rather than how these join points are implemented [74].

AO4BPEL also uses a query-based pointcut language. As BPEL process definitions are XML documents, XPath [50] is a natural choice as pointcut language. AO4BPEL does not come with predefined pointcut designators, i.e., each XPath expression that selects BPEL activities is a valid pointcut.

The pointcuts can use the attributes of BPEL activities as predicates to choose relevant join points. For example, to refer to all invocations of the operation findAFlight, the pointcut can use the attribute operation of the invoke activity as shown below:

<pointcut>

//invoke[@operation=”findAFlight”] </pointcut>

This pointcut selects the invoke activities that have their operation attribute set to findAFlight in any BPEL process. This example shows that the point- cut language of AO4BPEL supports the selection of activities across different processes. Thus, this pointcut language provides sufficient support for quantifi- cation. To restrict the selection of join points to a given process, e.g., to the travel package process, one can use the following pointcut:

<pointcut>

/process [@name=”travelPackage”]//invoke[@operation=”findAFlight”] </pointcut>

It is also possible to define composite pointcuts by using the set operators of XPath such as the union operator and the intersection operator.

Cross-layer pointcuts

The pointcuts that result from combining process-level and interpretation-level pointcut designators intercept points in the execution of two different layers. Therefore, they are called cross-layer pointcuts.

In AO4BPEL, the pointcut element has a type attribute, which specifies whether the pointcut selects activity join points (the default) or internal join points. In addition, it has a designator attribute, which specifies the pointcut designator.

For capturing internal join points, AO4BPEL introduces two pointcut des- ignators: soapmessagein and soapmessageout. These pointcut designators are used together with pointcut designators that select messaging activities.

The soapmessagein pointcut designator works in conjunction with the ac- tivities invoke and receive. When used with invoke, it captures the join points where a SOAP message has been received by the engine as a response for an invoke. When used with receive, soapmessagein captures the join points where a SOAP message that matches a receive activity is received by the BPEL engine. The soapmessageout pointcut designator works in conjunction with invoke and reply. When used with reply, it captures the join points where the engine has generated the SOAP response message corresponding to that reply and will send it. When used with invoke, soapmessageout captures the join points where the engine has generated the SOAP request message corresponding to that invoke and will send it.

The pointcut shown below selects the internal join points, where the SOAP request message of the invoke activity, which calls the operation findAFlight, has been generated and is about to sent out.

<pointcut type=”internal” designator =”soapmessageout”> //invoke[@operation=”findAFlight”]

</pointcut>

Perspective-oriented pointcuts

The pointcut language described so far is activity-oriented. It covers only the functional and the behavioral workflow perspectives. Beyond these two per- spectives, AO4BPEL supports perspective-oriented pointcuts such as variable- oriented pointcuts (the informational perspective) and partner-oriented point- cuts (the operational and organizational perspectives).

A variable-oriented pointcut selects all activities that read or write a given process variable. In such pointcuts, the name attribute, which should be set to the name of the variable, is required and the access attribute is optional. For example, the following pointcut selects all activities that write the variable clientresponse.

<pointcut>

// variable [@name=”clientreponse” and @access=”write”] </pointcut>

A partner-oriented pointcut selects all interactions with a given partner. Thereby, one could specify whether data is sent to or received from that partner. In such pointcuts, the name attribute is required and the pattern attribute is optional. For example, the following pointcut selects all activities, in which the process interacts with the partner flightService and sends data to that partner.

<pointcut>

//partner [@name=”flightService” and @pattern=”send”] </pointcut>

The support for variable-oriented and partner-oriented pointcuts allows to specify the crosscutting structure of some concerns in a more natural and direct way. The variable-oriented pointcuts are better suited for data-related concerns such as persistence, whereas the partner-oriented pointcuts are better suited for concerns such as authorization and auditing.

Process-level and instance-level aspect deployment

AO4BPEL supports both process-level and instance-level aspect deployment. With process-level aspect deployment, which is the default case, the advice applies to all instances of a workflow process. With instance-level aspect de- ployment, the advice applies only to some workflow instances. The pointcut specifies whether the associated advice should be applied at the instance level by using the optional condition attribute of the pointcut element.

The support for instance-level deployment in AO4BPEL is especially useful when aspect activation depends on runtime data such as the value of some process variable. For example, in an extended version of the travel agency scenario, one could activate a different pricing aspect for each process instance according to the pricing strategy selected by the customer. Thereby, some discounts may be given depending on the customer identifier.

Instance-level aspect deployment is also needed when a car rental aspect should extend the travel package process with car rental propositions for some destinations only. Below is a pointcut that selects the reply activities in the workflow instances of the travel package process, in which the destination city is Tunis.

<pointcut condition=”getVariableData(’ clientrequest ’,’ destination ’) == ’Tunis’”> //process [@name=”travelPackage”]//reply[@operation=”getTravelPackage”]

</pointcut>