CASS

1. Introduction

The Context Aspect Sensitive Service (CASS) architecture takes advantage of a dynamic Aspect-Oriented Framework to provide an advanced Web Service composition and refinement environment. In this section, the authors briefly introduce Web Services and Web Service orchestration.

1.1 Service-Oriented Architecture

Service-Oriented Architecture (SOA) is an architectural style whose goal is to achieve loose coupling among interacting software entities, in order to facilitate the integration of software components into distributed applications. A service is defined as a piece of work performed by a service provider for the benefit of a service consumer, where service provider and service consumer are roles played by software entities. Loose coupling is obtained by limiting the size and complexity of the service interfaces, which should only encode generic semantics. Therefore, all application-specific semantics have to be encoded in descriptive messages. Second, in order to ensure interoperability, the messages have to be written in an open standard format that is understood by all parties, generally XML. Moreover, the message structure should be extensible to guarantee evolvability and an SOA must provide a discovery mechanism that enables services to be discovered, bound and interactively accessed.

1.2 Web Services

Web Services is a collection of SOA implementation technologies based on open standard and interfaces, including XML, SOAP, WSDL, and UDDI [1]. It is generally accepted that Web Services are an SOA implementation that exchange XML messages over an internet based transport protocol such as HTTP. SOAP is a lightweight XML-based information exchange protocol for Web Services. A SOAP message envelope describes what is in a message and how to process it. The SOAP encoding defines a set of rules for mapping programmatic types to XML. WSDL is an XML-based language for defining Web Services interfaces that describe them and specify how to access them. UDDI is an XML-based protocol for registering Web service descriptions, discover and retrieve them.

1.3 Grid Services

Using Web Services, clients do not need to have prior knowledge of services until they actually invoke them. However, Web Services have some major limitations such as being stateless and service life-cycle cannot be explicitly controlled through client interactions. Their lifetime is tied to the lifetime of their container. The Globus toolkit [2] for grid computing addresses those shortcomings and provides a flexible framework for the development of advanced applications based on Web Services. The Globus core mainly adds the following features to Web Services:

1. Lifecycle Management. Contrarily to Web Service, Grid Service instances can be created on demand through requests to a service instance factory.
2. 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. Service Data can be accessed directly through the service interface. Service Data is ideal to keep track of the context of a service instance.
3. Notification. The Globus Toolkit implements service notifications using the Observer design pattern. Notifications can be attached directly to service data.

1.4 Service Composition

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 Business Process Execution Language for Web Services (BPEL) [3]. The web service composition process typically relies on a centralized engine that coordinates the composed services according to the workflow specification. This type of service composition is also referred to as service orchestration. A service composition that involves multiple parties that collaborate to achieve a common goal is referred to as a service choreography. Web service composition languages provide a clear separation between the process logic and the Web services invoked. Business processes can themselves be exposed as Web service, enabling recusrsive composition. Web service composition languages need to maintain state across Web Service components and manage exceptions and transactional integrity. However, current orchestration languages suffer from the lack of support for the distribution of the orchestration logic. Work on decentralizing the orchestration of composite web services [17] demonstrated significant performance improvements in terms of increased throughput, scalability and response time, especially when asynchronous messaging is used. Moreover, business process languages target long term web service orchestrations. Some service collaborations only make sense in a particular context, and have a short life cycle. There is therefore a need for the dynamic deployment and refinement of short term orchestration mechanisms. Furthermore, languages such as BPEL tend to mix up the structure of the collaboration with its dynamic behavior. To achieve dynamic workflow specifications, the structure of the workflow should be cleanly separated from the workflow interaction specification. Finally, the hierarchical modularization of the composition specification does not allow the encapsulation of some aspects of the orchestration such as exception handling, authentication or business rules [18].

1.5 Aspect-Oriented Service Composition

This work proposes an Aspect-Oriented Web Service instance composition approach based on collaboration-based design. Section 2 introduces Context Aspect Sensitive Service and Service Refinement Layers. In Section 3, the support infrastructure is detailed, and the Web Service joinpoint metamodel is presented. Section 4 presents a methodology for the mapping of service collaboration patterns to their aspect implementation, and section 5 discusses service refinement layer composition. Finally, section 6 discusses related work and sections 7 summarizes the contributions of this work.