Example: Constructing a Retailer

Returning to our running example of the retailer. The full picture of the orchestration, with business rules, is depicted in Figure 4.8. In this figure three types of transitions are present, namely: transitions that indicate com-munication with services, transitions of the target protocol, and transitions specifying decisions made using business rules. For the business rules, the reject business rule is triggered three times. Each time the business rule is triggered, it is executed because more information is available for evaluating the condition. For the reject business rule, this happens after receiving the availability, after receiving the credibility and after receiving the shipment quote. The other business rule, the acceptance of an order, in contrast, is only triggered once.

All transitions of the target protocol are represented in the orchestrator therefore we can state that the orchestrator exerts the desired behavior. The specification of this orchestrator is given in Appendix D.

4.7 Discussion

In this chapter, we introduced our compose operator. Where traditional automatic composition processes only consist of business processes, we use additional business requirements such as business rules and policies. We

Figure 4.8: The Orchestration for the retailer

synthesize an orchestrator based on the business protocols published in the interfaces of the service providers. Our synthesis satisfies additional con-straints, such that the orchestrator can be employed using both synchronous and asynchronous communication semantics.

One of the distinctive features of our composition approach was the usage of business rules. By translating business rules to guarded automata, we are able to incorporate them in the synthesis process. We modeled each business rule as a separate GA. However, for the expression of more complex business constraints more complex GA’s can be used. If business rules are specified separately then the situation may occur that multiple rules can fire at the same time. If this situation is not desired then business rules should be glued together to form a single automaton, which represents the whole business logic.

A question or assumption that must be made for the orchestration is whether the names of the states and transitions of the different business pro-tocols (to be part of the composition) are unique for the whole orchestration.

For this dissertation, we assume that they are. In practical scenarios, it

suf-fices that the name of the state as well as the name of the peer is remembered along with the name of the state in the orchestrator. Uniqueness of names makes a difference for adaptation, as it is easier to localize changes when states or transitions are removed/added.

We advocate that the models of the components used for the construction of the orchestrator are kept for later reference, for instance keeping business rules in a rule management system. If business rules change in the organiza-tion then these changes are easily adapted in the orchestraorganiza-tion. Otherwise, there is the risk of creating one monolithic process where the origin of the business rules cannot be traced back.

Although we adhere to the synchronizability properties and thereby en-sure that our orchestrator can work with both synchronous as with asyn-chronous communication semantics; this in the end comes down to waiting for the other party to send a message (if this is indicated so by that party’s protocol). Extending this would imply further study in asynchronous com-munication semantics.

Automatically Adapting an Orchestrator

5.1 Introduction

In the previous chapter we described how to compose a service orchestrator.

This orchestration functions correctly given the properties for interoperabil-ity as well as for the business requirements, i.e., business rules and target business protocol. However, even if software could be free of defects in the beginning, it is not possible to use it forever without modification (Parnas, 1994). The environment of the orchestrator, consisting of other services and the organization, will change. In this chapter we present a method for deal-ing with evolvdeal-ing service providers. More specific, we describe how to adapt an orchestrator with as goal to maintain interoperability.

As services evolve, changes to the interface of that service are inevitable (see Chapter 1). By publishing a new version of the interface changes are presented, and thereby propagated, to its service clients. In our research, we study how to adapt to these changes in such a way that changes do not prop-agate further to connected services. This is called evolution transparency or interoperability preservation (Andrikopoulos et al., 2009).

Whether a change to the interface of a service results in incompatibilities and whether an incompatibility can be solved, depends on the flexibility of the orchestration. The flexibility of the orchestrator depends on three as-pects:

Partial usage of functionality: Ponnekanti & Fox (2004) show that in prac-tice changes to a service often do not directly result in incompatibilities because the functionality was not used. A change to the functionality of a service provider that is not used by the orchestrator has no impact on the orchestrator.

Redundancy of information: A change may have the result that certain information is no longer available to the orchestrator. As this infor-mation may need to be send to another service, this would result in an incompatibility. However, in an orchestration information can be provided by multiple messages and by multiple parties. Therefore if the required information is removed then there is a chance that this information is still provided by another message.

Bilateral business protocols: Bilateral protocols specify the ordering of mes-sages between one service provider and one service client. In our spec-ification of an orchestration we only use bilateral protocols. There-fore there are no (direct) dependencies between service providers of the orchestrator. Because there are no dependencies between service providers, the orchestrator is able to choose the order in which to in-voke these service providers.

In this chapter, we exploit each of these aspects in order to solve incom-patibilities. In Chapter 2 we discussed the structure of an abstract algorithm for adapting the retailer, re-illustrated in Algorithm 5.1. We describe in this chapter the details of this algorithm and discuss each of the functions.

We use the adaptation process (Algorithm 2.1) to structure this chapter.

We show how to detect changes and introduce the diff-operator in Section 5.2. Based on a change script we analyze whether changes are applicable (have impact) in Section 5.3. The decision process on how to adapt to any changes that have impact on the orchestrator is described in Section 5.4.

This section includes the definition of three change categories (non-effective, solvable and problematic) and our notion of an incompatibility. After this, we explain in Section 5.5 our prototype. We conclude this chapter in Section 5.6.

Parts of this chapter have been published in (Hiel & Weigand, 2009;

van den Heuvel et al., 2007).

Algorithm 5.1 Adaptation Process

c, problematic) //escalate: unsolvable problem else

update(α,BP) //adapt the orchestrator end if

end if