Composition mechanism

The composition mechanism of AO4BPEL has three major tasks. First, it ex- tends the activity lifecycle of the BPEL engine with dynamic checks for aspects. Second, it decides at all these checks whether there is a pointcut that matches the current activity. Third, if a matching pointcut is found, the composition mechanism ensures the execution of the respective advice.

Modification of the activity lifecycle

The activity lifecycle denotes the different states in which an activity can be dur- ing its execution. The BPWS4J engine follows an activate-enable-run-complete lifecycle [61] as shown in Figure 5.2.

In this lifecycle, an activity starts running (the running state) once two things happen: The activity receives control from its enclosing activity (the activate state) and its incoming links fire positively so that the join condition evaluates to true. When a fault occurs, the activity enters the disabled state and can be revived later. To support loops, an activity that is in the completed state can be revived.

Figure 5.2 shows the points in the activity lifecycle where dynamic checks for aspects are integrated. These checks depend on the advice types. For the advice types before and around, checks are performed when the activity goes from the state enabled to the state running. For the after advice, checks are performed when the activity exits the state complete.

Figure 5.2 also shows the internal points during the execution of messaging activities where additional checks are integrated. These checks affect not only the BPEL engine but also the underlying SOAP engine.

Checks for the advice types before soapmessageout and around soapmes- sageout are done after the generation of the outgoing SOAP message of the current messaging activity. Checks for the advice types after soapmessagein and around soapmessagein are done after receiving an incoming SOAP message that matches the current messaging activity.

For the composition mechanism of AO4BPEL, the process meta model con- structs of BPEL such as join conditions, transition conditions, and links are irrelevant because the composition mechanism is embedded in the orchestra- tion engine itself, as opposed to composition mechanisms that are based on the process transformation approach such as the work presented in [26]. What mat- ters for the composition mechanism of AO4BPEL is that an activity, which is matched by a pointcut, is currently being executed.

Pointcut matching

At all points where checks for aspects are performed, the composition mecha- nism has to decide whether there is a pointcut (and an associated advice) that matches the current activity. The pointcut matching process in the AO4BPEL engine consists of three steps.

In the first step, variable-oriented and partner-oriented pointcuts are trans- formed into activity-oriented pointcuts. This step is necessary because the pointcuts should match points in the execution of activities (and not partners or variables).

default activate enabled running complete disabled revive _revive disable disable _disable disable before/around advice after advice SOAP request send/receive SOAP response running state (messaging activities) before/around soapmessageout after/around soapmessagein

Figure 5.2: Advice weaving and the activity lifecycle

After that, the pointcut matcher proceeds with the second step and checks whether one of the activity-oriented pointcut expressions matches the current activity. Thereby, two implementation approaches are possible.

In the first approach, pointcut matching can be implemented by evaluating the XPath pointcut expressions for each activity that is executed by the BPEL engine. That is, the pointcut matcher retrieves all pointcut expressions that are defined in the deployed aspects, and evaluates each of them against the XML process document, in which the current activity is defined. Then, the pointcut matcher compares the element name and the attributes of each matching XML node with the type and attributes of the current activity. This approach requires costly XPath evaluations of all pointcut expressions for each BPEL activity.

In the second approach, which is implemented by the AO4BPEL engine, a fast match pass is used to improve performance. In this approach, pointcut matching is done in two phases 2a and 2b.

In the phase 2a, the pointcut matcher evaluates pointcut expressions only when a new process or aspect is deployed or undeployed. This evaluation, which uses Xalan-J [6], operates on the XML process documents and returns a set of matching XML nodes for each pointcut expression. These nodes are comparable with the join point shadows in the AspectJ implementation [96]. For each pointcut, the meta-data of the returned activity nodes (e.g., activity type, activity name, attribute names and their values) is stored in some internal data structure.

In the phase 2b, the pointcut matcher compares the metadata of the cur- rent activity with the meta-data stored in the internal data structure without performing any costly XPath evaluations.

If the pointcut is a dynamic pointcut, i.e., it specifies an instance selection condition, the pointcut matcher performs the third step of the pointcut match- ing process and evaluates that condition against the current process instance.

This step is comparable with the dynamic tests (residues) in the AspectJ imple- mentation [96]. If the pointcut does not specify an instance selection condition, this third step is skipped.

Advice execution

In case a pointcut match is found for the current activity, the aspect runtime has to execute the respective advice activity. If the current join point activity is matched by more than one pointcut, the aspect runtime has to determine the order in which the advice should be executed.

If the advice have different types, the aspect runtime executes them in the order defined in Section 5.2.2. If the advice have the same type, the aspect runtime executes them depending on the values of the order attributes of the respective advice elements. If no order is defined, the aspect runtime executes them according to their order of deployment: the first deployed aspect will be executed first and so on.

Since the advice activity is a BPEL activity, the aspect runtime can delegate the execution of that activity to the BPEL interpreter. Thereby, two steps are necessary before the BPEL interpreter can execute the advice activity.

First, special AO4BPEL constructs need to be resolved. If the advice uses context collection variables such as ThisJPInVariable, this construct should be replaced by the name of the input variable of the join point activity. If the advice uses some parts of the reflective variable ThisJPActivity, these parts should be set to the corresponding reflective information of the join point activity.

For example, recall the logging aspect that was mentioned in Section 5.2.2. The pointcut of this aspect selects two reply activities in the flight process and in the travel package process. The advice of this aspect uses the reflective variable ThisJPActivity to log the name of the join point activity.

<copy>

<from variable=”ThisJPActivity” part=”name”/> <to variable =”logVar” part=”activityName”/> </copy>

In this example, the aspect runtime should set the parts of the variable ThisJPActivity differently depending on the current join point activity. That is the part name will be set once to the name of the reply activity of the travel package process and once to the name of the reply activity of the flight process. The resolution of context collection constructs and reflective constructs is implemented as follows: whenever the advice uses a context collection or reflec- tion construct, the aspect runtime collects the context data of the current join point (meta-data of the activity and its parent process, the input and output variables used by the activity, etc). Then, the aspect runtime uses the collected data to resolve the special constructs.

Second, aspect-local declarations for partners and variables are added to the parent process of the current join point activity. In this way, the advice activities that use the variables and partners that are defined in the process can be executed by the BPEL engine as if they were activities of the process.

After these two steps, the aspect runtime delegates the execution of the advice activity to the BPEL interpreter and coordinates that execution with the process execution as follows.

• If the advice is a before (resp. before soapmessageout) or after advice (resp. after soapmessageout), the process execution is suspended until the advice activity completes. After that, the process proceeds with the suspended activity.

• If the advice type is around (resp. around soapmessageout) and the advice does not use the proceed activity, the process execution is suspended until the advice activity completes. After that, the join point activity skips the running state to avoid executing the join point activity and goes to the complete state.

• If the advice type is around (or around soapmessageout) and the advice uses the proceed activity, the process execution is suspended until the completion of the child activities of the advice that are defined before the proceed activity. Then, the join point activity executes. After that, the child activities of the advice that are defined after the proceed activity execute.