CASS

5. Service Refinement Layer Composition

Because a business workflow language focuses on orchestrations from the perspective of a client application, it does not allow us the declare service interactions that are native to the nature of the accessed services. As a result, those collaborations have to be hard coded into the logic of web services, and get tangled with the service logic.
The following Aspect deployment descriptors are the equivalent of a BPEL description, but allow us to define much more advanced collaboration scenarios. First, the orchestration is decentralized and can be deployed dynamically on a per-instance basis. Second, it provides a clean separation between the various roles the service play. Finally, new types of collaboration patterns can easily be programmatically developed and incorporated into the system. However, the platforms need to be able to load the collaboration aspects in their respective aspect-language. To achieve full interoperability, the patterns and collaboration aspects need to be developed for each target platform. A Model- Driven Architecture approach seems suitable for that purpose.

5.1 ‘Bureaucracy’ Orchestration

By composing the structural composite pattern with the CoR and Observer patterns, we obtain a composite pattern that is close to the ‘Bureaucracy’ composite pattern [16] (except the bureaucracy also implements the Mediator patter for intra-hierarchy level communication). This pattern is particularly suited to coordinate the various services offered by a virtual organization, as the services offered tend to match the real world organization’s hierarchical organization. Each department of the organization might expose their resources through web services.
Fig. 11 illustrates the independent composition of the patterns presented in previous section. First, the composite pattern refinement layer encapsulates the logical structure of the organization. Second, the CoR pattern refinement layer encapsulates its dynamic behavior. Finally, the Observer pattern refinement layer encapsulates exception management. Because they are fairly independent, the composition is straightforward. The XML service refinement layer deployment descriptors are inspired from the aspect deployment descriptor provided by Aspectwerkz [12]. When combined with aspect-oriented implementations of generic service collaboration design pattern, they offer a declarative way to define a decentralized workflow specifications. Samples form the refinement layer specifications are reproduced in this section.  

5.1.1 Logical Structure

The following aspect deployment descriptor specifies service B has hierarchical control over service A and service C.

5.1.2 Dynamic Behavior

This aspect deployment descriptor specifies service C is the predecessor of service B in a chain of responsibility, and that is also the successor of another service (service D, but service C does not need to be aware of that).
The “advanced” pointcut specifies the situations for which request should be forwarded to the next handler ion the chain of responsibility. In this case, advanced searches should be forwarded to next hierarchical level.

5.1.3 Exception Management

The following aspect deployment descriptor specifies that web service C observes and controls service D and is itself observed and controlled by service B. The pointcut definition specifies a remote pointcut that is triggered when a exception is thrown during a search operation. The URI of service B is passed as a parameter, meaning service B will take care of handling the exception.

The complete service refinement layer deployment descriptor structure matches the role diagram structure of Figure 11. The descriptor can be viewed in the perspective of two different dimensions. The horizontal dimension specifies the role of each service instance in a given collaboration, while the vertical dimension captures the roles a given service instance assumes.
While the bureaucracy pattern is commonly deployed in practice in order to relate the services of a virtual organization, its structure and behavior are hard to describe in a business process language such as BPEL. As a result, the coordination logic tends to be hard coded into the service logic and ends up tangled with the service implementation.

5.2 Service Refinement Layer Composition

Service Refinement Layers can be developed independently and superimposed to a running system in order to adapt it to new requirements. However, it can be hard to evaluate the potential consequences of their mutual interactions, as well as their interaction with the core functionality. While the role manager might detect obvious inconsistencies, subtle interactions between the roles and the systems might still occur.
Moreover, services and components come with specifications and contracts that describe the behavior of the service and might give guarantees about the essential properties of a servicelike Quality of Service attributes. A vendor might sign its services guaranteeing they meet certain quality standards. The ability of Aspects to modify component behavior in uncontrolled ways is a serious brake to the integration of AOSD to Service-Oriented architectures and Component-Based engineering in general.
There is therefore a need to provide ways to assess and validate the impacts that aspect can have on component specifications. The problem is directly linked to the obliviousness of the system with respect to the superimposed collaborations layer. Validation of aspect weaving would require the core system to expose its essential desirable properties explicitly, so that the effects of aspects on those properties can be evaluated. The core system would have to compromise some obliviousness with respect to aspects, so that non-invasive changes can be validated. The authors think linguistic support might be needed for that purpose [21].