by Thomas Cottenier
Directed by Dr. Tzilla Elrad
This work is partially supported by CISE NSF grant No. 0137743.

ASCAS

New computing environment such as service-based pervasive and Grid environments require smooth collaboration and coordinated behavior within large scale heterogeneous distributed systems. Software entities need to be able to reconfigure themselves seamlessly and without user intervention to respond to changes in their environment or serve customized requests.

However, the potential system configurations needed in a particular context can hardly be anticipated beforehand. There is therefore a need for dynamic non-invasive approaches to system adaptation.

We propose a general Service-Oriented infrastructure we call ASCAS (Aspect-Sensitive Component Application Server) supporting runtime behavioral Web Service adaptation through Aspect-Oriented Programming techniques.

ASCAS proposes an original service deployment model, and provides the system ability of coping with unanticipated changes in the environment and to satisfy unanticipated requests.

Services can be adapted at runtime in unrestricted ways, as long as service interfaces are preserved. This limitation is imposed by hotswap as bytecode can only be modified at runtime as long as the class interfaces are maintained.

However, we would like to be able to extend a service interface with new methods, through aspect introduction, so that the implementation of those methods can be swapped at runtime. Therefore, those methods need to be deployed as introduction at deployment time. As they will only be woven into the service when the classes are loaded, we need to extend the tools used to generate SOAP tie classes to take service introduction into account.

In Axis SOAP, web service development typically proceeds as follow. After implementing the web service functionality, first, the WSDL definition file is generated by the java2WSDLtool. The service SOAP binding classes are then generated by the WSDL2Java tool.

When an aspect extends a service interface, the WSDL definition and the service stub classes need to be extended as well. Based on the Java2WSDL and WSDL2Java tools, we developed the stub aspect generation tools Aw2WSDL and WSDL2Aw.

Aw2WSDL is used to generate a XSL file from an aspect. The XSL is thereafter used to transform the initial WSDL file to the new extended service WSDL file. WSDL2Aw generates the stub class introduction aspects from the XSL file. Those aspects insert the extension methods into the service tie classes.

At deployment time, fine-grained composition of services is possible through the selection of service aspects that extend a core service. Aspects can be registered in a repository, so that they can be retrieved, and their platform specific implementation downloaded on demand. At run time, the implementation of the service methods implemented as aspect can be modified on the fly.

We proposed a general architecture for service-oriented environments that supports on the fly behavioral service adaptation, based on a dynamic aspect weaving framework. We developed theAw2WSDL and WSDL2Aw generation tools which allow us to extend Axis SOAP web service with fine-grained units of aspect behavior that can thereafter be adapted at runtime.

Aw2WSDL is used to generate a XSL file from an aspect, so that the service WSDL file is transformed according to the aspect extension. WSDL2Aw generates the stub class aspects corresponding to the service implementation aspects. Based on these tools, we where able to provide on-demand Grid Service instances refinement to serve customized requests. We also experienced that the development of Globus Grid Services in an aspect-oriented fashion leads to a more modular design, and allows non-invasive grid activation of web services.

• Presentation

Web Services

Web services aim at being building blocks for applications. Composite web services can be composed from multiple component web services given a workflow specification, in a language such as the BPEL.

The web service composition process typically relies on a centralized engine that orchestrates the composed services according to the workflow specification.

The BPEL process model is layered on top of the WSDL Web Service Definition. It defines peer-to-peer interaction and coordination between services described in WSDL.

BPEL has the limitation that is based on a centralized engine, which for some applications can become an important bottleneck.

Fig. 1 shows a simple sequential composition of two web service. To address scalability issues, we would like to be able to decentralize the composition, and alter the behavior of the web services so that synchronous RPC based calls are replaced by asynchronous messages that are directed to the right partner service, such as depicted in Fig. 2.

This can be seen as a refinement operation. The functionality of the web services remains unchanged, only the communication model is altered. It however requires changes that cannot be dealt with using superficial adaptation, such as provided by message handlers for example.

First, we implemented an aspect that intercepts synchronous calls, and makes them asynchronous. This aspect is applied to the composite web service. Second, we implemented a redirection aspect that intercept invocations and redirect the response to another service.

Using both those aspects, complex choreographies can easily be implemented in a decentralized way, without having to rely on a centralized engine.

Grid Services

• Reference implementations of Grid Services are tangled!

Web Services have the major limitation that their lifecycle can not be controlled through client interaction. When refining a Web Service, all user of that service are therefore affected by the adaptation.

The Open Grid Standard Architecture (OGSA) extends Web Services to Grid Services, in order to make them adequate for grid environments. OGSA is further specified by the Open Grid Standard Infrastructure (OGSI).The most important extension to Web Services is Grid Service support for stateful and transient services. Grid Service instances can be created on demand through requests to a service instance factory.

This model allows us to further extend service adaptation to service instance adaptation. When issuing an instance creation request, an instance specific adaptation request can be passed along to the system so that customized version of a service can be instantiated. Service can therefore be refined both at the service level and at the instance level.

We integrated the Globus Toolkit implementation of the OGSI specification to ASCAS. First, we extended the GridServiceFactory class to support instance specific refinement specification using the AspectWerkz API and the ASCAS generation tools.

Beside the capability of dynamically adapting grid service instances, we experienced that AOP techniques can greatly facilitates the development of Globus Grid Services, and lead to a more modular design. Intuitively, each feature OGSI adds to web service functionality crosscuts its implementation. By implementing those features as aspects, a web service can be grid-enable in a non-invasive way, through aspect weaving and corresponding WSDL XSL transformations. The OGSI Grid features mainly include:

Operation providers: Operation providers exploit the dynamic delegation model to plug the basic functionality of a Grid Service into a service implementation. The Service implementation needs to implement the methods of the OperationProvider interface.

Lifecycle Management: Transient service instance lifecycle are managed through callback methods. These methods are called at specific points during an instance lifetime (such as instance creation and destruction). The service implementation needs to implement the GridServiceCallback interface.

Service Data: Service Data is a structured collection of information that is associated to a Grid Service to classify and index them according to their characteristics. The creation of the Service Data Elements (SDE) takes place in callback methods.

Notification:The Globus Toolkit implements service notifications using the Subject-Observer design pattern. Observers don't subscribe to a whole service, but to a particular SDE in that service. Notification code has to be added invasively in each method to which observers may want to subscribe.

A simple transient Grid Service and supporting Service Data, Lifecycle management, notification capabilities and logging will have code associated to all of these concerns tangled within its functional code and the operation provider code.

We were able to cleanly encapsulate these features in generic aspects that can be specialized through aspect inheritance. As the core Grid Service code contains only the service functionality, Web Service Code can be reused as is, to implement Grid Services non-invasively.

Aspect-Sensitive Components

All potential component non-functional properties needed by third parties for late composition can not be anticipated beforehand, as they tend to be context-dependent. Moreover, those quality properties tend to be hard to modularize and can hardly be factored out of components. Developers therefore tend to embed non-functional properties within domain-specific frameworks and components.

We aim to take advantage of the expressive power of Aspect-Oriented Programming to modularize those concerns, so that both frameworks and components can be refined to satisfy specific requirements at deployment time, composition time as well as at runtime.

We claim that the key to the integration of Aspect-Oriented Software Development to Component-Based Software Engineering lies in the ability to derive and validate the specification of a component that has been subject to aspect weaving. By explicitly specifying the desired properties of components and aspects, we aim to increase the capability to reason about aspect weaving, so that the correctness of a refined component can be verified with respect to a specification.

• .pdf
• Presentation