CASS

2. Context Aspect Sensitive Services

With web services and peer-to-peer systems, distributed applications are becoming more dynamic. In service-oriented environments, distributed components do not know much about their functionality and access methods at runtime. They can therefore hardly anticipate the functionality requirements of all their client applications. There is therefore a need for methods to customize distributed service components based on applicationspecific requirements.
Service composition is a way to generate custom behavior. However, the current composition mechanisms do not provide appropriate customization capability. In order to successfully provide on demand customization through compositional techniques, context-dependent behavior needs to be modularized in separated units of encapsulations.
As noted in various research [6,7,8,9], those units of reuse tend to be hard to modularize in regular components that could be exposed as web services. Instead, they tend to cut across classes and components, and are therefore good candidates for aspects. The authors introduce Context Aspect Sensitive Services (CASS) as the natural core decomposition modules in service-oriented architectures. A CASS behaves as black-box component with respect to other CASS’s, but exposes potentially important joinpoints to service refinement layers. A Service Refinement Layer encapsulates distributed aspects that cut across service container boundaries. They modularize the structure and the collaborative behavior of composite web services, and support client context dependent service adaptations. Context Aspect Sensitive Services and Service Refinement Layers can be instantiated on demand to offer customized or context-dependent composite services. At instantiation time, CASS’ can be assigned roles in unanticipated collaborations.
Service refinement layers are inspired from Collaboration-Based Design techniques, which are introduced in the next section.

2.1 Collaboration-Based Design

Aside class/component-based decomposition, Collaboration- Based Design advocates decomposing applications into a set of collaboration layers. A collaboration layer defines how each actor contributes to a given task or feature. It captures the protocols objects should implement to fulfill an interaction. A role specifies the responsibilities the core object should take up in order to take part in the interaction. Collaborations can be instantiated more than once, and the same object can play different roles. If the collaborations are fairly independent, systems can be built incrementally by composing independently defined collaborations layers.
In Object-Oriented languages, roles and collaborations mostly remain design-time concepts and do not exit as separate entities at runtime. In order to be able to dynamically deploy or refine collaborations, they imperatively need to keep existing as identifiable entities at runtime. The following approaches aim at modularizing roles and collaborations in Object-Oriented languages.
The role object design pattern [4] implements Collaboration- Based Design by using the decorator design pattern. Role instances can dynamically be attached to core objects. Thus, the role object design pattern supports context dependent service instance refinement. Yet, it does not provide a way to encapsulate collaborations. The limitations of the pattern are well known. First of all, because role and core object are two different entities, the pattern suffers from object identity problems. Secondly, all role-specific public methods need to be provided in the interface of the core object, which leads to bloated interfaces and tight coupling. Finally, roles are not composable.
Mixin layers [6] aim at modularizing collaborations. Mixin layers encapsulate a hierarchy of Mixins, and seek to refine a collection of collaborating classes. Roles are assigned to objects by inserting their class as Mixins into a hierarchy of collaboration specific classes. They offer a non-invasive solution for the implementation of large-scale refinements. However, Mixin layers operate at the class level. As such, they don’t allow refinement of interactions at the instance level.
Lasagne [7] and the Delegation Layers [8] approaches achieve dynamic collaboration composition and refinement at the instance level through layers that respectively encapsulate object wrappers or delegation objects. These approaches offer a scalable solution to the management of collective object behavior in the presence of simultaneous client-specific views. Yet, these approaches introduce tight coupling. Mixins, wrappers and delegation objects are assigned individually on a per-instance base. It should be possible to assign collaboration roles on a perprofile and per-context basis, without having to reference instance handles explicitly.
Troughs an abstract class graph traversal approach, Adaptable Plug-and-Play Components (APPC) [9] provide a structurally generic way to encapsulate collaborations. However, APPC’s work on the class level and do not allow per-instance refinements.
Aspect-Oriented implementation of the Role Object Pattern [10] and of Collaboration-Based Design in general [11] show a more direct mapping from roles to implementation. The reliance on template-like mechanisms (Mixin) is removed. The advantage an aspect-oriented language offers over the listed approaches is the capability to do quantification. The context in which a particular role should be assigned to a particular instance can therefore be specified in a very flexible way, without having to enumerate those explicitly on a per-instance base. The ability to do quantification allows aspect-oriented approaches to achieve some level of structural genericity. Collaborating roles can be encapsulated in a single aspect, thereby providing an interesting construct for the encapsulation of a complete collaboration.
The authors propose to implement on-the-fly web service instance composition and refinement using a Collaboration-based Design approach implemented using dynamic AOP technology.

2.2 Service Instance Refinement

In a distributed computing context, a client/server relationship between peers can be designed as a collaboration layer that encapsulates both the client and server code. By dynamically composing layers of client/server relationships, the resulting service provided by an entity can be refined on demand, according to a specific context of the interaction. The authors propose to implement declarative orchestrations such as specified in BPEL by instantiating generic collaboration aspects through aspect deployment descriptors. In order to apply Collaboration-Based Design to Web Service Instances, an appropropriate role and collaboration model needs to be defined. The authors identify the following requirements:

1. Encapsulation of context-specific collective behavior. The most variable elements are not the services themselves, but their interactions. There is therefore a need for reusable units of encapsulation that have the ability to capture complex interactions that cut across service structures and heterogeneous containers.

2. Non-invasive refinement. The refinement of a client/server relationship needs to be non-invasive. It cannot require changes to the implementation of the initial service as this might interfere with interactions the service has with other entities, which do not require the refinement. Therefore, the composition of collaboration layers has to be strictly additive.

3. Client-context dependent service refinement. The same service instance might need to simultaneously offer customized services to other entities, adapted to their profile and their context.

4. Loose-coupling between entities. Service refinement layers may not break the loose coupling requirements of serviceoriented architectures and need to accommodate platform heterogeneity.

Taking up these issues simultaneously is not an easy task. While the relation between objects and collaboration roles has been studied thoroughly, a key challenge is to ensure loose coupling between the entities taking part in collaborations while encapsulating heterogeneous interaction-specific features. The authors’ position is that the aptitude to use quantification when assigning roles to collaborating entities might play an essentialrole in providing a scalable solution. In order to tackle those requirements, the CASS model relies on the following constructs:

1. Role Services. Role Services are full fledged web services that aim at being deployed into other services in order to support a given collaboration. They encapsulate the role of a target service in a collaboration and can be deployed on demand in a service instance. They allow services to dynamically assume unanticipated roles.

2. Remote Joinpoints. Remote pointcuts [14] identify pointcuts on a remote hosts. In the context of CASS’, remote joinpoints require a meta-model that applies to Web service instances. The authors put an emphasis on the capability of services to be in command of the control flow of subordinated services through remote pointcuts associated to ‘around’ advices.

3. Remote Advice Weaving. The CASS container exposes its underlying weaving interface as a Web Service. Advices and, to a certain extent, pointcuts can therefore be dynamically plugged in and out.

Encapsulating collaborations that cut across container boundaries presents an important challenge because of the heterogeneity of system platforms, middleware and programming languages. One side of the interaction needs to be specified in a platform independent way.
For service refinement layers, the refinement is implemented in the language of the target service. The client side of the refinement only specifies the conditions under which the refinement is triggered and can be defined with respect of events exposed by the service in a WSDL description. In the case of client notification refinements, the client side is implemented in the language of the client, while the notification specification is expressed with respect to an abstract definition. The prerequisite is that events of interests are somehow exposed using a language independent representation (WSDL), that can be bound to the concerned entities when needed.