6. Contextual Aspect-Sensitive Services

n SOAP-based service architectures, non functional concerns, coordination and activity lifecycle are implemented by deploying message handlers within a handler chain. Message handlers intercept messages between the point they enter the container and the point at which the service provider is invoked.

The handler chain is therefore the right place to enforce additional constraints on service invocations, and to modify the control and data flow of service compositions. In order to support dynamic refinement, dynamic message interception needs to be supported. ECF uses an Aspect-Oriented Programming (AOP) language to weave composition logic at the level of the message processing engine. Service requests and responses are filtered and matched against a regular expression that specifies which messages should be intercepted, under which conditions. ECF uses the Contextual Aspect-Sensitive Service (CASS) [9,10,11] distributed pointcut language to specify the locus of activity superimposition.

CASS is a distributed aspect platform for service-oriented environments. A CASS pointcut expression defines a set of message interceptors that are responsible for intercepting the messages that match a message pattern expression. SOAP messages are intercepted at the level of the SOAP message processing engine, both at the client and the service side. CASS includes a rich set of mechanisms to transform, compose, synchronize and multicast the intercepted messages to remote service methods, which play the role of aspect advices. The platform also includes a native context propagation mechanism. Contexts are declared at the pointcut level. Each time an event triggers a contextual pointcut, the intercepted message is wrapped into a CASS envelope that includes a context description. ECF associates a collaboration activity to each of those contexts. Finally, CASS supports the runtime extension of entity interfaces. Role services are services that aim at being deployed in association with other services in order to support a new interaction pattern. The role extension mechanism essentially solves an entity identity problem. A role that is associated to an entity can be referenced using the handle of the service it is attached to. These constructs allow CASS to implement collaboration activity superimposition. An interaction can be augmented at runtime by a new interaction contribution, by binding a service method to an intercepted message before, around or after it is allowed to proceed.

This section presents the CASS language constructs, and establishes their relationship with the Petri net model introduced in the previous section.

6.1 Control flow Refinement Constructs

essages are intercepted at the level of the message processing engine. The current CASS implementation acts upon the Axis [17] engine. Apache eXtensible Interaction System (Axis) is an implementation of the Simple Object Access Protocol (SOAP). The Axis engine processes incoming and outgoing messages by invoking a chain of handlers that manipulate an object called message context. Global axis message handlers perform some SOAP specific processing such as serialization, message dispatching or routing. Service-specific message handlers perform tasks that enforce the nonfunctional properties of the messages that flow through the container such as authentication, encryption or session and persistency management.

CASS uses a standard aspect-oriented programming language to intercept the message context at different points of the handler chain. The current CASS implementation uses the AspectWerkz [19] framework, but any other AOP language or framework could have been used. When a message matches a regular expression defined in a pointcut expression, message processing is interrupted, and the CASS interception subsystem takes control over the message.

CASS pointcut expressions represent a set of activities. The CASS pointcut interpreter translates a declarative pointcut expression that is defined with respect of WSDL definitions into local aspects that acts upon the message handlers. The code sample of Fig. 5 defines a pointcut on calls to operations of the “Math- Service” on IIT application servers. It represents all the activities that start when an operation is called on the MathService and terminate when a response is returned. The use of variables in CASS specification enables the runtime evolution of aspects, as well as topology independent definitions. It also avoids having to hardcode service references into choreography specifications.

The action to be performed on an intercepted message is specified in advice definitions that are bound to the pointcut expressions. Advice definitions specify the host, service and operation to which the intercepted message must be dispatched. Advice definitions can be composed and bound to multiple pointcut expressions. 3 different types of actions can be performed. An activity creation advice, denoted by ->A starts a new activity A but does not wait until the activity completes. An activity termination advice, denoted by <-A, waits until activity A terminates. An activity creation/ termination advice, denoted by <-> A, starts a new activity A and waits until it terminates. Activities can be refined at 3 different points in their lifecycle:

Before refinement. In terms of activities, the following before refinement expression is interpreted as “before activity S.a, activate activity A, and wait until it terminates”.

In terms of service composition, it can be interpreted as a service refinement refD(S,TSi,Sa), where the input transition TSi is expanded into service Sa when the a operation is invoked in service S. The before keyword is annotated with the id of the control domain that executes the refinement. If the refinement is applied to a client-side pointcut expression, the control domain is the controller of the input transition of the service (similar to a ‘call’ pointcut in aspect languages). If the refinement is applied to a service side pointcut expression, the control domain is the controller of the input transition of the service (similar to an ‘execution’ pointcut in aspect languages).
After refinement. In terms of activities, the following after refinement expression is interpreted as “after activity S.a, wait until activity A terminates”.
Around refinement. In terms of activities, the following around refinement expression is interpreted as “instead of activity S.a, activate activity A and activate activity S.a when a special transition called ‘proceed’ occurs within activity A”.

In terms of service composition, it can be interpreted as a service refinement refD(fer(S,i) ,i, ref(Sa, proceed, S)). The refined service is collapsed into the identity service I, which is in turn refined into service ref(Sa, proceed, S), which represents a refinement of service A, whose ‘proceed’ operation is expanded into the original service S. The ‘proceed’ operation has the same signature as the refined operation. If the ‘proceed’ operation is not executed within the refinement activity, the initial activity is not executed at all.

The code sample of Fig 6 illustrates a simple CASS redirection aspect. A call to ‘MathService’ on the IIT server is replaced by a call to the same service on an alternate server. Such aspects can be used to implement load-balancing and fault tolerance refinements.

In CASS, composition units are defined by composing pointcuts and advices. Composite activity creation structures are defined by composing advices. The par advice composition keyword spawns or terminates one or more activities executing concurrently.

The exclusive choice activity composition structure is defined using a similar notation with the choice keyword: choiceF(->S1.b,->S2.c). The following code samples shows how the parallel composition unit is defined in CASS.

<pointcut name="MathServiceAdd"/> <parallel name="beforeaddflow" bind-to="MathServiceAdd" type="after"> <advice name="add80" /> <advice name="add81" /> </parallel>

Composite activity termination structures are defined by composing pointcut expressions. The afterF(parF(<-S1.b, <-S2.c)) pointcut composition expression is triggered after the activity composed of activities S1.b and S2.c terminates. It is a join pointcut. The discriminator activity termination structure has a similar notation using the disc keyword. The discriminator waits for the termination of one of the composed activities before activating the activity advice .The following code samples shows how the join composition unit is defined in CASS.

6.2 Data Flow Refinement Constructs

S-CDL is not designed to enable choreographies to be specified from existing WSDL Web Service interfaces. It merely declares a choreography of operations that can be specified in some WSDL once the choreography is implemented. The ECF targets the runtime deployment of new choreographies. Hence, the CASS pointcut expressions are defined with respect of existing WSDL interfaces. In multi-party peerto- peer interaction scenario, an arbitrary set of interfaces does not necessarily lead to a possible collaboration. CASS therefore supports a message transformation component, the transformation unit, whose role is to adapt the process messages to existing WSDL’s. Transformation units can transform both the structure and the content of the intercepted messages. It uses XSLT to generate a new SOAP message that conforms to the interface of the remote method interface. The XSL templates used for the transformation are part of the CASS composition specification. The adaptation component makes it possible for remote service methods to process a wide range of intercepted messages. Transformation units can also maintain state within collaboration activities and buffer messages. Those variables can be used within the XSL templates, to transform messages according to the state of the collaboration activity, or to aggregate messages.

6.3 Context Propagation

horeographies are defined and deployed by the domain of control that takes advantage of the added value resulting from the choreography (just as for BPEL master/ slave choreographies). The composition should therefore only apply to interactions that are part of the collaboration activities of the choreography. Hence, there is a need for a mechanism to unambiguously discriminate interactions according to the collaboration activities they take part in. CASS passes collaboration activity contexts (CAC) in the header of messages. Context propagation allows pointcuts to be defined on a per-activity basis and enable concurrent service customization [14]. CAC’s are propagated along the interactions of an activity by keeping a CAC reference within the server message processing threads. The activity context uniquely defines the scope of a collaboration activity.

When a message comes in at the server listening port, it is dispatched to a message handler thread. The thread inspects the message and executes the corresponding message handlers, before executing the service implementation. When a message is intercepted, the composition logic is executed within the thread of the message handler chain. If the composition logic results in the invocation of another service, the invocation message is assigned the same activity contexts then the incoming message. The activity context is also propagated to new threads that are spawned by composition units. Message can be assigned several contexts. Activity contexts allow message correlation. Correlated messages are part of the same collaboration activity.

Fig. 4. Collaboration Context Propagation

New activity contexts are declared at the pointcut level. A contextual pointcut defines the set of message processing points where new collaboration activities start. Each time an event triggers a contextual pointcut, the intercepted message is assigned a new CAC. The CAC carries the following information:

Collaboration activity name. The context name is the name of the collaboration activity. It is the name of the pointcut that defines the context.
Collaboration activity id. A different id is attributed to each context joinpoint instance. It the instance reference of the collaboration activity.
Joinpoint callback. The URI of the callback interface of the joinpoint that started the collaboration activity instance. The joinpoint callback is used to terminate a collaboration activity at the point at which it started. It can be used to implement transaction compensation.
Collaboration activity data. The data associated to the activity. The context data can also be maintained by an external service. In the later case, only a URI to the service data is propagated. Composition and transformation units can access the activity data and edit it to update the state of the collaboration activity.