CASS

4. Service Interaction Models

4.1 Service Interaction Design Patterns

The use of design patterns considerably helps the development of Web Service. Moreover, some patterns directly apply to service orchestration. Both structural and behavior patterns can be applied to describe the interactions between service instances in the same way they are used to describe complex object interactions.
Work on aspect-orientation and object-oriented design patterns have shown the benefits of an AOP implementation on the flexibility (pattern plug in, plug out) and the modularity of pattern implementation.
Hanneman suggests that the implementation of some design patterns disappears when implemented with AspectJ [15]. This claim is based on the representation of the pattern. The class diagram of the pattern simply disappears, leaving only the core objects, while the pattern logic is completely modularized in the aspect. However, it is worth noting that the role diagram [16] of the patterns does not change, whether implemented in plain Java or in AspectJ. Role diagrams are described as follow (cf. Riehle [16]):

A role diagram describes how some collaborating objects, each one playing one or more roles, achieve a common goal [….] An object collaboration diagram can be viewed as a set of overlapping role diagrams. […]Role diagrams are more abstract than class diagrams. Role diagrams can be mapped on several class diagrams

Class diagrams represent the implementation of the design pattern - class inheritance helps us handle the pattern implementation more easily. They mix the actual problem solution in terms of the distribution of responsibilities between objects with efficient ways of implementing it. However, the mapping from role diagram to class diagram leads to tangled code – the pattern logic is scattered over the participating classes. We therefore use role diagrams to represent Aspect-Oriented implementation of collaborative design patterns.

4.2 Role Aspect Diagram

Role Aspect Diagrams are used to represent the aspect-oriented implementation of service interaction patterns. They illustrate the mapping from role diagrams to an aspect-oriented implementation. Aspect role diagrams are composed of role containers and aspects layers.
An aspect layer encapsulates a given collaboration between roles and illustrates the relationship between the advices and introductions that implement the collaborations. Role containers represent the service the aspect layer components are deployed in. Different role components may be deployed inside the same service. Pointcuts are located on the role components, as they represent the trigger events that initiate the collaboration.

While the aspect layers can reference the role container, the role containers never reference aspect layer components. This property is essential to achieve non-invasive deployment of collaboration and collaboration refinements.

4.3 Examples: atomic collaboration patterns

In this section, three atomic design patterns used in section 5 are introduced. Each pattern’s role diagram is illustrated, as well as its role aspect diagram, which represents its aspect-oriented implementation.

4.3.1 Composite – logical structure

The composite design pattern defines a hierarchical structure of services where individual services and composite services can be treated by client uniformly. Both individual and composite services expose the same service interface.
Using the CASS container, the composite pattern can be applied to web services dynamically to create a hierarchy of service instances that make sense in a given context. An example of such a hierarchical organization of services is a geographical partition of services that expose a search engine. Composite is a structural pattern. By separating its implementation from the web service interaction patterns, a better separation between composite web service structure and behavior is obtained.
The ‘parent’ role is implemented as an aspect introduction. Through the CASS dynamic interface extension mechanism, a web service instance can dynamically be assigned the responsibility of managing child services.

4.3.2 Chain of Responsibility – Dynamic Behavior

The Chain of Responsibility (CoR) pattern is a behavioral pattern that defines a chain of services. CoR allow us to dynamically define the receiver of service requests without the need for a service broker.
The predecessor role defines the successor of the service, while the successor role contains logic that defines the conditions under which the request should be handled or forwarded to the next service. In addition, the predecessor role contains a forwarding advice and a pointcut definition that is used to specify additional conditions under which a given request should be forwarded to the next service. When combined with context pointcuts, complex forwarding logic can be expressed concisely.
In our geographical partition of search engine services example, search request is first directed to the local search engine. When the search does not returns a result, or throws an exception, the request is forwarded to the next hierarchical level of services.

4.3.3 Observer – Exception Management

The Aspect-Oriented implementation of the observer pattern is actually much more powerful then the classic object-oriented implementation. Indeed, the observer has the capability to affect the control flow of the observed subject using an “around” advice. The observer can take the decision to disallow the subject to proceed with the execution of the observed event in a certain context. A service at a higher hierarchical level can observe its subordinates and interrupt their processing logic when necessary.
This mechanism is particularly useful for error handling. A manager service can observe a set of services and take over requests when errors are thrown.
The observer role is composed of a subject management introduction and a notification advice. The ability of the CASS container to react to remote joinpoints makes the observer service interaction pattern straightforward to implement. The observer role introduction manages its subjects by sending weaving requests that add or remove joinpoints on remote CASS containers.