BPEL from CDL

WS-CDL and WS-BPEL both provide a way to describe how web services should collaborate. But the difference is that WS-CDL gives a global perspective the message exchange whilst the WS-BPEL provides a single participant's perspective.
As some are arguing I do not see a competition between these two specifications. Rather they must co-exist to describe services interactions properly.
Though, WS_CDL is designed to be used in conjunction with the WS-BPEL, one limitation of the WS-CDL specification is that a clear mapping with BPEL is missing. I agree that the intention of WS-CDL is not to be depend on WS=BPEL but there are advantages of having such a clear mapping.

1. Choreographies can be defined in WS-CDL first by business partners and then generate BPEL process stubs for each party
   
2. A party who’s having an internal business processes may need to publish the interface to its processes to attract business partners by generating the choreography. This could be done using a BPEL to CDL mapping.
   

From the engineering perspective such a mapping could be automated. Also such a defined approach would minimize the inconsistent mappings by different parties coming in to collaboration.
This paper presents how BPEL process definitions are derived from the global WS-CDL model. Authors have done this by defining a set of transformation rules.
For example

1. Each party participated in CDL choreography a separate BPEL stub is generated
   
2. One cdl:relationshipType maps to one bpel:partnerLinkType and the bpel:role with its bpel:portType is generated from the referenced cdl:roleType declaration
   
3. Generate separate property files for each cdl:roleType including only those bpel:properties that are relevant for a party.
   
4. BPEL basic activities are directly mapped to CDL basic activities
   
5. Work units in CDL are related to scopes in BPEL
   

The complete mapping is available in the section 5.
The paper addresses a much required issue by not altering the existing standards or without introducing new standard, which is a plus point. The approach seems straightforward and not requiring intermediated mapping like in the approach here[4] where the mapping is into Communicating Sequential Processes. Also authors have implemented a prototype of the mapping as a proof of concepts.
Saying that, one limitation of the paper is that there is no reference on how to verify the generated BPEL stubs over the original CDL. Generated stubs may be correct for the given example or could be verified manually for simple scenarios. But it is required to have a formal mechanism to verify more complex scenarios. That is not in future work section too. And the verification need to be integrated to the BPEL stub generation or it should be done after generating BPEL stubs but before the populating them with application logic.
Also it is not clear how the mapping from BPEL processes to CDL is done. Which also an interesting issue (as far as ROAD is concerned ). May be we might be able to complete that part. We can map several processes to a common choreography by projecting them over a ROAD Self Managed Composite. In other words by overlapping several processes we might be able to define the choreography. Syntactical transformations might use the same discussed in the paper. Sure need to think and discuss more about that.

Adaptive software systems and their challenges - Part II

In my previous blog, I categorized what are the challenges faced by different software systems at runtime. This time I’m going to talk about how to face those challenges.

From a reason to a challenge
The uncertainties I talked earlier are common in designing any kind of system. In early days it was considered a failure of a system as a result of such an uncertainty is OK. Many software systems gave above issues as excuses for the failure of software. For example a failure of a proper functioning of a particular networked application, due to limited bandwidth was considered to be normal. And users were too accepted such a failure. And usually seek the help of some expertise. The Geek who’s sitting in the dark room. But as the time passes software architects wanted to find solutions for such issues and minimize failures in fluctuating environments.

From challenge to solutions
On one hand there is a continuous improvement of resources such as more memory, more processing power and more bandwidth. But at the same phase, the software systems too evolved into digesting more resources.
On the other hand software designs too shoved some kind of adaptability. For example a failure in a transaction resulted in rollback of the transaction. Basically the software started to sense the environmental context it is operated in. Thereby adjust its internal properties to suit the context, to support continues availability of the software.
Parallel to these developments, different kind of programming languages too supported such adaptability. The awareness of the platform they are operated in is inbuilt to the language and reflected in the API.
Different tools were also developed to support the adaptability. As an example GPS sensor in mobile devices gives the developers the capability of sensing the geographical location of the device operated in.

Architecture based solutions
The approach taken by the ROAD framework described in details in the thesis, is an architectural approach to adaptive software applications rather than introducing strategies or mechanisms. The thesis introduces three kind of adaptation. (Section 2.1)
1.Evolutionary adaptation : Reproduces instances with variations
2.Ontogenic adaptation : Change the internal structure
3.Environmental manipulation: Change the environment

The approach taken in the ROAD framework is based on the ontogenic adaptation, where the system itself regulates its internal structure based on the fluctuations in the environment. The system changes can be seen in two ways.

1.Indirection of instantiation: Changes to the elements, which the system is built upon. This includes replacements, modifications to the elements.
2.Indirection of association: Changes to the relationships of the elements within the system.

The ROAD framework considers such a system as an organisation, which consists of different roles with different responsibilities. Roles are assigned by role players and changed according to the environment they are operated on. Also new roles can be introduced and old roles can be discarded as well.
In my opinion the approach is a success due to following reasons.

1.Loosely coupled roles and role-players allow more freedom in instantiation, thereby allowing easier adaptation. Different players can be allocated to different to a particular role of the system depending on the environment change.
2.The recursive structure makes the design very simple and thus can be applied in very complex software requirements. In ROAD a system is consist of element which are intern similar systems. Just like in OOP where properties of an object or a class instance can also be another object.
3.A system is self-managed so as its elements are.

Make it adaptive, but avoid the complexity

That’s where the ROAD heading
One of the major challenges to be faced in designing adaptive software systems is the how to avoid the complexity. A complex design is always hard to develop and then very hard to maintain.
The complexity of such a system arises due to following reasons, which are in turn challenges to be faced by software architects.

1. How to represent changing requirements at runtime?
   
2. How to account for computational and network contexts at runtime?
   
3. How to manage the system in a distributed architecture
   

Changing requirements

As we studied in our Software Engineering lectures, it is better to separate the user requirements from the design itself, to make it more maintainable. The design itself shows very little evidence about the exact requirements and most of the time is developed using set of interfaces and abstract functions. Requirements or the awareness of the run time environment is kept separate.
But the problem with this approach when it comes to adaptive systems is that it is necessary to know these requirements and make it available within the software itself. Java like languages tries to make the implementation to be separated by the specification using interfaces. But there are limitations in this approach too

1. No mechanism to update interfaces at runtime
   
2. Only functional requirements can be met
   
3. Requirements are related to entity. Not the context in which they are applied to
   

Computational and network contexts at runtime
At the end the designed software executes on a physical computers or a network. The challenge posed by adaptive systems is how to identify the computational context in which operates on. This is further complicated by the fact that these contexts need to be account both for entities and for the composite as a whole.

Distributed/Open architecture
Though there are many attempts to go for a common middle ware standard, there is still no such. So the system needs to work with heterogeneous components in a distributed architecture.
So the question is how to find answers to these inherent challenges at the same time avoiding the complexity?

ROAD Framework
Role Oriented Adaptive Design is or ROAD in short is an attempt to answer the questions mentioned above. ROAD framework is based on the view that adapting the relationships among entities rather than entities it self. To put in another way adaptation is a property of the relationship rather than a property of an entity.

Key concepts

1. Role: Description of the behavior of a functional entity
   
2. Functional Entity : Role players such as services, objects and components
   
3. Contracts: Connectors between roles.
   
4. Organizer: A role that create/destroy roles.
   
5. Self Managed Composite: A set of roles and contracts manages internally by an organizer.
   
6. Management Interface: The interface of the SMC (Self Managed Composite) to the external world.
   

In my view the power behind the RODE framework is the separation of roles from its role player and the concept of self managed composites. All contracts are internal to the SMC, avoiding the complexity of the design.
Note that such a composite system can again be an entity which plays a role of another global SMC.

Let’s see how above challenges are met in ROAD framework

Facing Challenge #1:
The organizer manages the contracts rather than functional entities. Functional entities are bound to play the roles which can be reconfigured at run time depending on the changing requirements. New roles and contract may create depending on the requirements. Also the Manager binds the functional role players to its roles.

Facing Challenge #2:
As the runtime environment changes, the framework allows to add/drop roles or assign/replace/remove role players. The contract oriented nature facilitates such, without actually damaging the initial design.

Facing Challenge #3:
ROAD doesn’t require the knowledge of entities. Thus entities in heterogeneous technologies can interact and be managed.

More details can be found in this paper