CASS

3. Support Architecture

3.1 CASS Container

The CASS container is implemented on top of the Globus [2] container for Grid Services so it can provide support for service life-cycle control and take advantage of service data notifications. While the CASS model aims at being platform independent, the current implementation is in Java. The dynamic AOP support is provided by the Aspectwerkz [12] weaver, but could very well be provided by another dynamic AOP framework, language or JVM extension.
Beside the capability to dynamically adapt grid service instances, we experienced that AOP techniques facilitate the development of Globus Grid Services, and lead to a modular design. Intuitively, each feature the toolkit adds to Web Service functionality crosscuts its implementation.
‘Gridifying’ introductions are used to implement specific interfaces needed by Globus so it can manage the service resources. Web Service implementations can therefore be deployed transparently in the Globus Grid environment. We were able to modularize service lifecycle management, service data and notification code in aspects, which makes those features transparently deployable through weaving and corresponding WSDL XSL transformations.
In addition to the features provided by Grid Services and the dynamic AOP support, the CASS container relies on the following three core components: the Service Joinpoint Manager, the Role Service Manager and the Context Propagation Manager. Figure 2 sketches those components. The components are themselves implemented as aspects. They can therefore be deployed transparently, without requiring any modification to the Globus core.

1. Service Joinpoint Manager. When remote pointcuts are triggered, the metadata of the joinpoint has to be passed to the host running the advice. In the case of synchronous pointcuts, the thread of execution also has to be blocked until the advice is executed on the remote host. The service joinpoint manager implements the mechanism that allows services to be in command of the control flow of subordinated services when ‘around’ advices are used in conjunction with remote pointcuts.

2. Role Service Manager. The role service manager keeps track of the roles currently assigned to a service instance and implements the mechanism that allow customized service instances to be deployed on demand. It also provides a watchdog against inconsistent behaviors that may result from incompatible role composition.

3. Context Propagation Manager. The context propagation manager keeps track of the context of service instances. The “context” concept allows generalizing the ‘cflow’ construct to distributed pointcuts. The context propagation manager ensures contexts are propagated along the joinpoints of a same interaction. It also includes a listener Introduction, so that the entities’ context can be remotely adapted by entities they depend on.

3.2 Service Joinpoint Manager

Remote pointcuts allow us to locally specify events of interest occurring on remote hosts. When the pointcut is triggered, the metadata of the joinpoint is passed to the local host and the corresponding advice is executed locally. We distinguish between synchronous and asynchronous remote pointcuts.
Asynchronous remote pointcuts are similar to regular notifications. Remote events trigger the execution of code on the side of listening parties. A difference is that the listeners can declare their interest in any remote event non-invasively, without requiring the remote party to explicitly implement notification code. The remote thread that triggers the pointcut does not wait for the advice to be executed. ‘Around’ advices cannot be bound to asynchronous pointcuts. Asynchronous pointcuts use the service data notification mechanism provided by Globus.
On the other hand, synchronous remote pointcuts are similar to remote procedure call, with the notable exception that the called party takes the initiative to deploy the calling mechanism. The remote thread that triggers the pointcut is blocked until the advice is executed. Advices have therefore the capability to alter the control flow of remote entities. For scalability reasons, asynchronous remote pointcuts should always be used when possible.
In mobile environments, the handles to services that participate in an interaction need to be discovered dynamically. We assume the entities publish the services they offer to a registry hierarchy, so that a classification attribute can be used in the remote pointcut specification.
The following aspect deployment descriptor specifies a synchronous remote pointcut on the ‘SubjectService’ host that triggers an update advice on host ‘ObserverService’. The pointcut specification relates to the service WSDL file of the service. For now, the model supports execution, call, exception and context pointcuts. The context pointcuts will be detailed in section 3.4.

Around advices associated to remote pointcuts allow services to be in command of the control flow of subordinated services. Figure 3 represents a pseudo sequence diagram of the remote joinpoint control flow management mechanism, for a ‘proceeding’ remote joinpoint.

3.3 Service joinpoint model

As the pointcuts are expressed over the service definition, the joinpoint model provides information on the services interacting at that joinpoint. The advice attached to the joinpoint can access the service instance reference (an URI), the target service instance reference (another URI), the input message parameters, output message parameters or error messages in the form of a SOAP XML message. For example,

In addition, the WSDL definition of the target service is associated to the joinpoint, including the namespaces, the type schema, the input/output message definitions, the PortType and its operations and bindings. The joinpoint model also includes context information. A context is defined by an application specific XML Schema. The context propagation mechanism is described in the next section.

3.4 Context propagation

Sophisticated pointcuts were introduced by the Event-based AOP framework [13]. EAOP argues that AOP languages should provide support for declaring pointcut expressions that match a sequence of execution points instead of only a single event. By doing so, a cleaner separation between crosscut and action (advice) definition is obtained. Sophisticated crosscuts avoid having to add bookkeeping code into the advices that specify additional conditions under which code should or should not run. Indeed, such code is relevant to the definition of the crosscut, and not of the advice. Sophisticated pointcuts are particularly useful for discriminating contexts, and assign roles.
When deploying aspects across distributed containers, we cannot rely on system provided information to discriminate joinpoints contexts, such as the ‘cflow’ construct. Context information is crucial for the deployment of per-client context service adaptation aspects.
Figure 6 sketches the context propagation mechanism. Service 1 plays a role ($) that is dynamically deployed in a certain context. The “do_it” pointcut is triggered by the execution of a method exposed by an instance of service 3 occurring in the context of a call to a method of an instance of service 1.

The ‘context’ concept generalizes the ‘cflow’ construct for distributed pointcuts. Each service instance is associated a context description, which is a set of states, that conform to a context definition expressed as XML Schema. The context format is not imposed by the CASS container; it is specified by the application. It can be thought of as being distributed service data, that is attached to a collaboration rather than a specific service. The support container contains a context manager component that keeps track of the service instance contexts, and ensures the joinpoint context propagation. Within a collaboration layer, remote joinpoints inherit:

• The context of their service instance.
• The context of the other remote joinpoints they are in the control flow of.
• If the joinpoint is a role joinpoint, it inherits the context of the service instance it is attached to.

3.5 Role Service Manager

Customized web service can be instantiated on demand by sending weaving requests to the target web service environment. A customized service instance is then assembled through aspect weaving, deployed, and the endpoint URI for the new web service instance is returned. The Role Services implementation gets inserted into the service implementation through an aspect introduction and the target web service interface also has to be adapted to support the new role. Therefore, the web service specification (WSDL) and the SOAP binding classes have to be adapted accordingly. Instead of generating a new WSDL from the customized web service, we generate the new WSDL from the core web service specification and the role WSDL through XSL transformation. From the XSL file, we also automatically generated the aspect introductions adapting the SOAP binding classes. When dynamically extending a service interface, the customized service class needs to be loaded by a different class loader to avoid naming clashes. The adapted service therefore exists in a separate namespace. Figure 5 sketches the on-demand role service deployment.

Depending on the instance’s context, new roles are assigned to the instance through the role manager. It also provides a watchdog against inconsistent behaviors. This is a delicate problem because the infrastructure allows the transparent assignment of roles. The role service manager seeks to impose constraints on the roles in order to keep them consistent and impose priorities.

3.6 Service Interface Adaptation

Beside Role Service introduction, service interfaces can also be adapted to support different types of messaging.
Figure 6a shows a simple sequential composition of two web services. To address scalability issues, we may want to decentralize the composition and alter the behavior of the web services so that synchronous RPC based calls are replaced by asynchronous messaging. This is depicted in Figure 6b.

The CASS container supports a set of adapter aspects that allow synchronous RPC-based requests to be replaced by asynchronous messages. Redirection aspects can then be used to forward service invocation responds to other services. Moreover, synchronization aspects can be woven directly into the web services to meet a workflow specification.
As the messaging aspects modify the web service interface, the service WSDL and binding classes need to be adapted as well. The mechanism described in section 3.5 is also used for service interface adaptation.