The algorithms described in this and the previous chapter were implemented in a prototype. The prototype was used to generate all change and adap-tation scripts presented in this thesis. This prototype serves as a proof-of-concept implementation of a manager for tackling interoperability problems.
Through this implementation we show that our framework can be used to develop model-based adaptive behavior in services.
The prototype contains two functionalities, namely composition and adap-tation. The architecture for service composition is illustrated in Figure 4.2 and described in Algorithm 3. The architecture for the second functionality, adaptation of an orchestrator, is shown in Figure 5.12. In Figure adaptation is illustrated with references to the related algorithms. Given a changed service, the prototype creates the change script as described in Algorithm 6, performs an impact analysis (shown in Algorithm 7), and based on the changes that have an impact, and attempts to construct an adaptation script by remapping (Algorithm 9), reordering (Algorithm 10) and recomposition (Algorithm 11).
removeTrans(sh3,getAccCredib,sb4);
removeTrans(sb4,accCredib,sb3);
addTrans(sb1,getCCCredib,sb2);
addTrans(sb2,ccCredib,sb3);
removeState(sb2);
addState(sb4);
removeMsg(Retailer,Bank,getAccCredib);
removeMsg(Bank,Retailer,accCredib);
addMsg(Retailer,Bank,getCCCredib);
addMsg(Bank,Retailer,ccCredib);
removeType(GetAccCredib,);
removeType(AccCredib,);
addType(GetCCCredib,,);
addType(creditcard,,/GetCCCredib);
addType(number,int,/GetCCCredib/creditcard);
addType(expiryMonth,int,/GetCCCredib/creditcard);
addType(CCCredib,,);
addType(balance,int,/CCCredib);
removeMap(/GetAccCredib/bankaccount/accountID,/order/payment/
bankaccount/accountID);
removeMap(/GetAccCredib/bankaccount/accountType,/order/payment/
bankaccount/accountType);
addMap(/GetCCCredib/creditcard/number,/order/payment/creditcard/
number);
addMap(/GetCCCredib/creditcard/expiryMonth,/order/payment/creditcard/
expiryMonth);
Figure 5.11: Adaptation Script for replacing the bank’s path
Figure 5.12: Architecture
The prototype is built on top of a extended version of the Web Service Analysis Toolkit (WSAT) by Fu et al. (2004e). This toolkit provides the means to analyze composite Web services by translating BPEL via Guarded Automata into Promela, the language for the model checker SPIN (Holz-mann, 2004). For our purposes we used and extended the functionality the authors implemented for Guarded Finite State Automata, as well as the properties they defined for supporting asynchronous communication seman-tics.
A distinction is made between a bottom-up and a top-down specification.
Top down means that an orchestration is specified as one business process where all services are integrated. On the other hand, the bottom up per-spective specifies an orchestration as a collection of services. In our work we study changes in services and how these affect an orchestrator, therefore we prefer the bottom-up approach. The grammar in Figure 5.13 specifies the bottom-up perspective, the top-down perspective is given in (Fu, 2004).
In Figure 5.13 the italic words are grammar constructs (terminals or non-terminals), the non-italic words represent text used in the specification files.
The syntax defined by the grammar in Figure 5.13 was used to define all input: services (Appendix A), business rules and target protocol (Ap-pendix C) as well as for the output namely the newly composed or adapted orchestrator (Appendix D).
Spec → { Schema , Peerset }
Schema → Schema{ PeerList{ StringList }, TypeList{ MSLList }, MessageList{ MessageList }}
MessageList → Message | Message , MessageList Message → name { source –> destination : type } Peerset → Peer | Peer , Peerset
Peer → name { States{ StringList } , InitialState{ StringList }, FinalStates{ StringList } ,
TransitionRelation{ TransitionList }}
TransitionList→ Transition | Transition , TransitionList
Transition → name { source –> destination : message , Guard } Guard → Guard{ XPathExp => Update }
Update → name { AssignList }
AssignList → Assign | Assign , AssignList Assign → XPathExp := XPathExp
Figure 5.13: Syntax of Service Orchestrations
5.6 Discussion
In this chapter, we described our approach for dealing with changes in busi-ness protocols of service providers. We showed how changes are captured in a change script, how to determine whether changes are applicable, and we introduced three operators, to (semi-)automatically solve any solvable change.
The three operators utilize all the flexibility that an orchestration may have. The remap operator identifies incompatibilities and solves those in-compatibilities if data is provided in the same structure. The reordering operator determines whether incompatibilities can be solved by looking at alternative orchestrators that use the same set of messages (functionalities), and provides an adaptation script for those that can be solved. The
recom-position operator solves incompatibilities that require alternative paths and alternative service providers in the orchestration.
Although in this chapter we only adapted the orchestrator to changes in versions of the same service provider, our approach, without modification, can also be applied when a service is replaced by another. Instead of compar-ing versions, a new service is given as input and the result is an adaptation script that indicates whether the orchestrator can be adapted such that it uses this new service.
A limitation of our approach is that we tackle one change at a time.
In other words, if a queue of change notifications would exists then our ap-proach would try to tackle them one at a time. However in some cases it may require tackling multiple notifications at the same time to solve all incompat-ibilities. For instance, if a new legislation rule (such as the Sarbanes-Oxley Act (2002)) applies to multiple providers at once, then they may require ad-ditional messages that other providers deliver. However, since our approach tackles only one change a time, it will not find a solution in this situation.
Note that although we employed a formal approach, we did not provide complexity results. It is our goal to show that our approach works and is correct, and not to illustrate how much computation is needed to realize it.
Our work shows that adaptation works correctly, future work will have the task of making it more efficient.
Related Work
6.1 Introduction
In this thesis, we study service adaptation. We split related work into three categories, namely work on service adaptation in general, conceptual work (ASOA), and applied work on interoperability. Table 6.1 maps the distin-guished fields of knowledge described in this chapter to these three categories.
Furthermore, Table 6.1 describes which sections of this chapter are most rel-evant to which other chapter(s) in this thesis.