detecting and resolving mismatches between provided behaviour

TECHNISCHE UNIVERSITEIT EINDHOVEN Department of Mathematics and Computer Science,

Department Technology Management AND SAP Research Brisbane

Detecting and Resolving Mismatches Between Provided Behaviour

and Required Behaviour

by Marian Müllers

Supervisors:

dr. ir. R.M. Dijkman (TU/e) dr.ir. A.J. Mooij (TU/e)

dr. A. Barros (SAP)

Eindhoven, August 2008

Preface

III

Preface

This thesis marks the end of my Master program Business Information Systems at the

Eindhoven University of Technology. I truthfully enjoyed the life as a TU/e student including all

semesters I spent abroad. It all started with a semester in Istanbul, and fortunate as I am, it

ended with writing my thesis down under in cooperation with SAP Research. Experiencing the

freedom while driving on the Great Ocean Road, but also, reading scientific papers about Petri

Nets and bisimulation at Fiji’s most beautiful beaches, belong definitely to one of the

unforgettable things in my life. I hope I will be able to continue travelling after I become a young

professional.

The main audience of this thesis includes Remco Dijkman, Arjan Mooij and Marc Voorhoeve, as

they form the assessment committee of my graduation project. Additionally, this thesis is aimed

at information system communities and other institutions or researchers with interest in

service oriented design.

It is very difficult to finish a project without any help of others; this project is no different.

Therefore, I would like to take the opportunity and thank my supervisors Remco Dijkman and

Arjan Mooij for their supervision, and more importantly, for inspiring me when the risk of a

deadlock was nearby. Furthermore, I would like to thank Alistair Barros for his input and for

giving me the opportunity to work at SAP Research in Brisbane. I also would like to thank

Natalia Sidorova for taking the time for reading and evaluating my work. Last but not least, I

would like to thank María Dolores Lara Proaño for keeping me motivated and for accompanying

me during the long hours at the TU/e.

Eindhoven, 11 August 2008

Abstract

V

Abstract

In this thesis we concerned ourselves with problems that occur when parties collaborate in a

value chain, that standardizes collaboration protocols, while using the collaboration protocol

that they already have. The collaboration protocol of a party is called provided behaviour. The

standardized collaboration protocol of a party is called a required behaviour and the joined

required behaviours in a value chain are called a choreography.

We developed an approach for detecting and resolving mismatches between provided

behaviour and required behaviour. Mismatches need to be resolved because they indicate that

the collaboration protocol of one party contains behaviour that the other party does not expect.

This unexpected behaviour leads to interoperability issues, such as a deadlock. For detecting

and resolving mismatches we first defined a set of possible mismatches, so called mismatch

patterns, that could occur between the provided behaviour and required behaviour. Second, we

slightly altered an existing technique for detecting mismatch patterns between business

processes to make it usable for comparing web services. Third, we defined a mapping from

mismatch patterns to transformation rules. Finally, we used an existing technique for

generating an adapter based on the transformation rules. The transformation rules define the

allowed behaviour of an adapter. Consequently, the adapter handles all mismatches such that

the provided behaviour, together with the adapter, conforms to the required behaviour. For

validating our approach we used a set of choreographies provided by the XML common

business library (xCBL). During the validation process we applied our approach on ten pairs of

provided behaviour and required behaviour derived from the xCBL descriptions. In eighty

percent of the test cases we were able to generate an adapter. In almost sixty-five percent of

those cases the adapter solved all mismatches detected. In the other thirty-five percent new

mismatches were introduced, yet weak termination could be guaranteed by the adapter. In

twenty percent of the test cases we were not able to generate an adapter. It has to be noted that

we were not able to test some of the mismatch patterns, since they were not present in any of

the ten test cases.

Table of Contents

VII

Table of contents

List of Figures .................................................................................................................................................................... IX

List of Tables ...................................................................................................................................................................... XI

1 Introduction ................................................................................................................................................... - 1 -

1.1 Service Oriented Design ............................................................................................................ - 1 -

1.2 Example Scenario ......................................................................................................................... - 5 -

1.3 Objective .......................................................................................................................................... - 7 -

1.4 Approach ......................................................................................................................................... - 8 -

1.5 Contribution ................................................................................................................................... - 9 -

1.6 Thesis Structure ........................................................................................................................ - 11 -

2 Related Work .............................................................................................................................................. - 12 -

2.1 Mismatch Patterns .................................................................................................................... - 12 -

2.2 Detecting Mismatches ............................................................................................................. - 13 -

2.3 Resolving Mismatches ............................................................................................................. - 14 -

3 Mismatch Patterns for Web Services ................................................................................................ - 16 -

3.1 Mismatch Patterns .................................................................................................................... - 17 -

3.2 Relations between Mismatch Patterns ............................................................................ - 29 -

4 Detecting Mismatch Patterns ............................................................................................................... - 33 -

4.1 A Technique for Detecting Mismatch Patterns ............................................................. - 33 -

4.2 Discussion .................................................................................................................................... - 35 -

5 Resolving Mismatches ............................................................................................................................ - 38 -

5.1 Generating Adapters ................................................................................................................ - 38 -

5.2 Mapping Mismatch Pattern to Transformation Rules ............................................... - 41 -

5.3 Discussion .................................................................................................................................... - 63 -

6 Validation and Complete Example ..................................................................................................... - 65 -

6.1 Approach ...................................................................................................................................... - 65 -

6.2 Results ........................................................................................................................................... - 76 -

6.3 Discussion .................................................................................................................................... - 78 -

7 Conclusion and Future Work ............................................................................................................... - 79 -

7.1 Main Conclusion ........................................................................................................................ - 79 -

7.2 Discussion and Future Work ................................................................................................ - 80 -

References ................................................................................................................................................................... - 81 -

Appendix A. Order-management Choreographies ................................................................................ - 84 -

Appendix B. Detailed Validation Results ................................................................................................... - 91 -

List of Figures

IX

List of Figures

Figure 1-1 Example web service Y ....................................................................................................................... - 3 - Figure 1-2 Example web service X ....................................................................................................................... - 4 - Figure 1-3 web service x composed with web service y ............................................................................. - 4 - Figure 1-4 Order-management process choreography ............................................................................... - 6 - Figure 1-5 Provided behaviour of new buyer .................................................................................................. - 7 - Figure 1-6 Research model ...................................................................................................................................... - 9 - Figure 3-1 Skipped Activity .................................................................................................................................. - 18 - Figure 3-2 Extra activity ........................................................................................................................................ - 19 - Figure 3-3 Split activity .......................................................................................................................................... - 20 - Figure 3-4 Refined activity ................................................................................................................................... - 21 - Figure 3-5 Partly corresponding activities .................................................................................................... - 22 - Figure 3-6 Iterative vs. once-off occurrence ................................................................................................. - 23 - Figure 3-7 Different dependencies .................................................................................................................... - 24 - Figure 3-8 Activity at different moment ......................................................................................................... - 25 - Figure 3-9 Different conditions for occurrence ........................................................................................... - 26 - Figure 3-10 Conditions for occurrence less strict ....................................................................................... - 27 - Figure 3-11 Conditions for occurrence less strict (example II) ............................................................ - 28 - Figure 3-12 Hierarchy of mismatch patterns ............................................................................................... - 31 - Figure 3-13 extra activity, different dependencies or both? .................................................................. - 32 - Figure 4-1 Completion occurrence relation (Dijkman, 2008) ............................................................... - 34 - Figure 4-2 Different input dependencies (Dijkman, 2008) ..................................................................... - 35 - Figure 4-3 Different input conditions (Dijkman, 2008) ........................................................................... - 35 - Figure 4-4 interface problem ............................................................................................................................... - 36 - Figure 5-1 Web service adapter ......................................................................................................................... - 38 - Figure 5-2 Skipped “receive activity” (deferred choice) .......................................................................... - 43 - Figure 5-3 Skipped Send Activity (Branching) ............................................................................................. - 45 - Figure 5-4 Extra send Activity (deferred choice) ........................................................................................ - 47 - Figure 5-5 different conditions (send activities) ......................................................................................... - 50 - Figure 5-6 different conditions (receive activities) .................................................................................. - 51 - Figure 5-7 iterative send & receive activity................................................................................................... - 57 - Figure 5-8 Once-off send & receive activity................................................................................................... - 59 - Figure 5-9 Iterative receive & send activity .................................................................................................. - 60 - Figure 5-10 Once-off receive & send activity ................................................................................................ - 62 - Figure 5-11 .................................................................................................................................................................. - 63 - Figure 6-1 Validation approach: Difference analysis & adapter generation .................................... - 66 - Figure 6-2 Validation approach: Difference analysis between adapter & required behaviour - 66 - Figure 6-3 Deadlock scenario non-local choice ........................................................................................... - 67 - Figure 6-4 implicit synchronisation ................................................................................................................. - 69 - Figure 6-5 required behaviour of the supplier............................................................................................. - 70 - Figure 6-6 behaviour of the new supplier (provided behaviour) ........................................................ - 70 - Figure 6-7 Partner behaviour (Choreography 3.2) .................................................................................... - 73 - Figure 6-8 Running example: generated adapter ....................................................................................... - 74 - Figure 6-9 Provided behaviour + adapter ...................................................................................................... - 75 -

List of Tables

XI

List of Tables

Table 1 Sources of mismatch patterns ............................................................................................................. - 17 - Table 2 Truth table for occurrence of "Send Credit Response" ............................................................. - 28 - Table 3 Relations between mismatch patterns ............................................................................................ - 30 - Table 4 Elementary activities expressed as transformation rules (Gierds, Mooij & Wolf, 2008). ... - 39 - Table 5 skipped activity transformation rules ............................................................................................. - 45 - Table 6 Extra activity transformation rules .................................................................................................. - 48 - Table 7 Different conditions transformation rules..................................................................................... - 51 - Table 8 Split activity transformation rules .................................................................................................... - 53 - Table 9 Refined activity transformation rules ............................................................................................. - 53 - Table 10 Partly corresponding example ......................................................................................................... - 55 - Table 11 iterative vs. once of transformation rules ................................................................................... - 62 - Table 12 - Selected choreography pairs .......................................................................................................... - 77 - Table 13 overall result validation ...................................................................................................................... - 77 - Table 14 Results test case 1 ................................................................................................................................. - 91 - Table 15 Results test case 2 ................................................................................................................................. - 91 - Table 16 Results test case 3 ................................................................................................................................. - 91 - Table 17 Results test case 4 ................................................................................................................................. - 92 - Table 18 Results test case 5 ................................................................................................................................. - 92 - Table 19 Results test case 6 ................................................................................................................................. - 93 - Table 20 Results test case 7 ................................................................................................................................. - 93 - Table 21 Results test case 8 ................................................................................................................................. - 94 - Table 22 Results test case 9 ................................................................................................................................ - 94 - Table 23 Results test case 10 ............................................................................................................................... - 94 -

Introduction

- 1 -

1 Introduction

Nowadays, more and more companies are doing business with each other using web services.

The World Wide Web Consortium (W3C, 2008) defines a web service as a “software system

designed to support interoperable machine-to-machine interaction over a network”. Complete

value chains exist in which organizations are interacting with each other through web services.

For supporting this new way of doing business, Service Oriented Design has emerged. However,

all organizations have their own collaboration protocols and their own information systems.

Furthermore, requirements for a collaboration protocol can be rather different based on specific

information needs. All these differences, and the increasing need for collaboration through web

services, introduce interoperability issues between organizations. Therefore, the necessity for

standardized collaboration protocols has emerged.

This chapter first describes the basics of Service Oriented design and provides definitions of

terms that are used in this thesis. Section 1.2 introduces an example scenario in which a party

does not conform to the required behaviour. Then the objective of our research is formulated,

followed by a detailed description of the approach used. Finally, an overview of the structure of

this thesis is given.

1.1 Service Oriented Design

Service oriented Design (SoD) is used for supporting the implementation and execution of web

services (Dijkman & Dumas, 2004). SoD enables a model driven approach for developing

services and helps to verify whether services conform to their requirements. Dijkman & Dumas

(2004) distinguish between four viewpoints for SoD: the provided behaviour, the interface

behaviour, the choreography and the orchestration. In this research we will focus on the

choreography and provided behaviour views of SoD. In literature, provided behaviour is also

referred to as business protocol (Benatallah, Casati, Grigori, Motahari, Toumani, 2006). The

following terms related to SoD are used in this thesis:

Web service: A web services is a software system designed to support

interoperable machine-to-machine interaction over a network

(W3C, 2008).

Collaboration protocol: A collaboration protocol is a set of formal rules that describe the

format of messages and the sequence in which they are exchanged.

Introduction

- 2 -

Provided behaviour: Provided behaviour is a description of the collaboration protocol

used by a specific organisation.

Required behaviour: The required behaviour is a description of the standardized

collaboration protocol of a single party within the value chain.

Choreography: A choreography is a description of the standardized collaboration

protocols between all parties within a value chain.

We will use the Open Petri net language (Kindler, 1997) for modelling web services. The Open

Petri net language is based on normal Petri nets. It has additional interface places connected to

transitions that represent send and receive activities. In this research we add one restriction to

the Open Petri net language, that is: each transition is at most connected to one interface place.

Feature-complete translations exist from languages like WS-BPEL (Alves et al. 2007) to Petri

nets (Lohmann, Verbeek, Ouyang, Stahl & van der Aalst, 2007) and (Lohmann, Massuthe, Stahl &

Weinberg, 2008) as well as translations from Petri nets to WS-BPEL (Lohmann & Kleine). We

will use the ProM1 framework for detecting mismatches and the tool Fiona (Lohmann,

Massuthe, Stahl & Weinberg, 2008) for solving them. Using these tools is another reason for

choosing Petri nets as modelling language.

The web services modelled in this thesis have the following constructs:

A set of places, indicated with circles, including:

o Zero or more internal places;

o Zero or more interface places.

A set of transitions, indicated with squares, including:

o One or more communication transitions;

o Zero or more internal transitions.

A set of directed arcs that connect places and transitions;

An initial marking (one token on one internal place, called start place);

A final marking (one token on one internal place, called end place).

A token on the start place indicates that the web service is able to start the process by firing a

transition. A transition can be fired if all its input places contain a token. A Place from which an

arc directs to a transition is called an input place for that transition. If the transition is fired,

then a token is placed on all its output places. A place to which an arc directs from a transition is

called an output place for that transition. Internal transitions are only connected to internal

1 Both documentation and software can be downloaded from www.processmining.org.

Introduction

- 3 -

places and represent activities that do not involve sending or receiving a message. Internal

places represent the current status of the web service. Interface places represent input and

output buffers for messages. Sending or receiving messages is indicated by firing a

communication transition. Hence, two types of communication transition exist, send transitions

and receive transitions. Communication transitions are connected to internal places and to

interface places. When fired, send transitions consume tokens from internal places only, but put

tokens on interface places and internal places. Received transitions consume tokens from

internal places and interface places, but put tokens on internal places only. The marking of the

Open net indicates the status of a web service. For example, if the web service is able to receive

a certain message, then all input places of the corresponding receive transition contain a token.

A marking m’ is reachable from marking m if and only if, a sequence of firings from m to m’

exists. The final marking indicates that the web service is terminated successfully.

Figure 1-1 shows an example of a web service modelled in the Open Petri net notation. Web

service Y has six places, one start place “Start”, one end place “End”, two internal places “P1”

and “P2” and two interface places “A” and “B”. Furthermore, web service Y has three transitions,

two communication transitions, “Send A” and “Receive B”, and one internal transition “tau”. Tau

is used for representing internal transitions. Transitions that are not connected to interface

place are silent, because they cannot be observed by the other web service (van der Aalst &

Basten, 2002). Figure 1-2 shows another example of a web services. Web service X has five

places, one start place “Start”, one end place “End”, one internal place “P1” and two interface

places “A” and “B”. Web service X also has two communication transitions, one representing a

receive activity “Receive A” and one representing a send activity “Send B”.

Send AStart EndTau Receive BP1

BA

P2

Figure 1-1 Example web service Y

Introduction

- 4 -

BA

Receive AStart EndSend BP1

Figure 1-2 Example web service X

Two web services can be composed by merging the corresponding interface places. In the

composed system each web service keeps its own start place and end place. The initial marking

contains a token on both start places. Each merged interface place becomes an internal place.

Hence, the composed model does not have any interface places. Figure 1-3 shows the composed

web services X and Y.

Send AStart EndTau Receive BP1

BA

P2

Receive AStart EndSend BP1

Web service X

Web service Y

Figure 1-3 web service x composed with web service y

Composing two web services only makes sense if they can successfully collaborate with each

other. In this research we assume that two web services can collaborate successfully if the

composed Petri weakly terminates. Therefore we introduce the following definitions.

Deadlock: A deadlock is a marking/state in which no transition is enabled

and that is not the final marking.

Deadlock-free: A Petri net is deadlock free if no deadlock is reachable from the

initial marking.

Introduction

- 5 -

Weak termination: A Petri net is weakly terminating if from every reachable marking,

it is possible to reach the final marking.

Successful collaboration: Two composed web services can collaborate successfully if the

composition weakly terminates.

Behavioural properties such as deadlock freeness and weak termination can be tested on

composed services that are bounded (Massuthe & Wolf, 2007) and (Martens, 2003a).

1.2 Example Scenario

Several organizations dealing with supply chain standards, such as RosettaNet, ISO, SWIFT and

xCBL have defined their own choreography definitions. Choreographies are critical to

interoperability, since they exactly define how multiple organizations interact by specifying the

terms and relations of messages to be exchanged. Organizations that want to participate in the

value chain must conform to the required behaviour. The required behaviour is the part of the

choreography that describes the standardized collaboration protocol of a single party. In that

way all organizations that participate in the value chain help to realize the behaviour prescribed

by the choreography, preventing undesirable situations from occurring.

In what follows we give an example of an organizations that cannot collaborate successfully in a

standardized value chain due to mismatches between the provided behaviour and the required

behaviour. Figure 1-4 shows the required behaviour that all parties in the value chain must

adhere to, the so called choreography. The choreography depicts an order-management process

in which two potential partners, a buyer and a supplier, collaborate. The example choreography

presented here is in the Open Petri net notation (Kindler, 1997) and inspired by xCBL (2003).

First, the buyer initiates the order process by sending an order request message to the supplier.

The supplier sends exactly one order response message toward the buyer. Now, the buyer has

several options. If he is content with the response he can end the order process by sending an

confirmation message. On the other hand, in case he does not agree with the response, he can

either change the order or even cancel the order. After cancelling or changing the order, the

supplier has to send a cancel response message or a change response message, respectively. After

receiving the cancellation response, the buyer will end the order process. Also after receiving

the change response, the buyer ends the order process. The buyer cannot request another

Introduction

- 6 -

change since in this particular order-management process only one change per order is allowed.

Hence, the supplier will only respond once with a change response message.

Receive

Order RequestStart

EndSend

Order Response

Receive

ConfirmationP1

Order Response ConfirmationOrder Request

P2

P3Receive

Change Request

P4Receive

Cancel Request

Send

Change Response

Send

Cancel Response

Cancel

RequestChange

Request Change

Response

Cancel

Response

Send

Order RequestStart

EndReceive

Order Response

Send

Confirmation

P1 P2

P3Send

Change Request

P4Send

Cancel Request

Receive

Change Response

Receive

Cancel Response

Buyer

Supplier

Figure 1-4 Order-management process choreography

Now imagine a situation in which the collaboration protocol of a new buyer allows for sending

multiple change requests. Figure 1-5 shows the provided behaviour of such a buyer. If this

buyer would send a second change request, then he would wait endless for a second change

response, as the supplier will never send it. This situation is also called a deadlock. If a deadlock

can occur somewhere during the collaboration, then we say that these two parties cannot

successfully collaborate.

Another situation in which successful collaboration is affected is where the supplier sends

multiple order response messages. This can occur in situations in which the status of (a part of)

the order is not completely known initially, but becomes clear over time. The supplier would

send an updated order response at a later point in time. However, the buyer can only process

one order response as is described in the choreography. If a party sends a message that the

other party is not able to process, then we say that these two parties cannot successfully

collaborate with each other.

Introduction

- 7 -

Order Response SyncOrder RequestChange

RequestChange

Response

Send

Order RequestStart

End

Receive

Order Response

Send Sync

P1 P2 P3Send

Change Request

Receive

Change Response

Buyer

Cancel

Request

P4Send

Cancel Request

Cancel

Response

Receive

Cancel Response

Figure 1-5 Provided behaviour of new buyer

1.3 Objective

The main objective of this thesis is to develop a technique for detecting mismatches between the

required behaviour and the provided behaviour, which is also referred to as conformance

checking. Van der Aalst, Alves de Medeiros and Weijters (2006) define conformance checking as

the act of verifying whether one or more parties stick to the agreed-upon behaviour by

observing the actual behaviour. Conformance checking in the context of web services is in its

early stages. Current approaches feature only partial solutions and no well developed tools for

conformance checking exist. For instance, Alves de Medeiros, van der Aalst and Weijters (2008)

present an implementation for identifying process equivalence. However, their technique

focuses on finding equivalence expressed in percentages, rather than detecting certain

mismatches, and resolving those mismatches.

In this thesis we aim to develop a new technique for conformance checking that is able to detect

specific mismatches between provided behaviour and the required behaviour. Moreover, we do

not only aim to detect mismatches but also to point out precisely where in the process they

occur. However, the focus is limited to the behavioural aspects the collaboration protocol. We

do not address other aspects such as data inconsistencies between messages, formatting of

messages or technology used for sending and receiving messages. For research on

interoperability issues on a data level see for instance Ernst, Lencevicius and Perkins (2006).

We also want to develop a technique for solving the detected mismatches. For solving

mismatches we limit our scope to pairs of provided behaviour and required behaviour that are

similar. We motivate this decision by stating that it does not make sense to solve mismatches

Introduction

- 8 -

between completely different web services. In such cases we suggest to develop a new web

service from scratch.

We intend to implement the developed method in a software tool. This tool takes provided

behaviour and required behaviour as input and produces a set of identified mismatches as an

output. Subsequently, the output can be used for solving the mismatches. By using this tool a

business analyst could compare provided behaviour with the required behaviour and make

motivated alignments with respect to this provided behaviour where necessary. In short, our

objective can be formulated as follows.

Objective:

Develop a method for detecting and resolving behavioural mismatches between

choreographies and provided behaviour.

1.4 Approach

In order to achieve the main goal described in the previous section, the following sub questions

are formulated:

1. What is considered as a (relevant) mismatch?

a. Which mismatches are discussed in literature?

b. Which mismatches can be found by comparing choreographies and provided

behaviour?

2. How can mismatches be detected?

a. Which mismatch detection techniques are discussed in literature?

b. Which techniques discussed in literature are applicable/re-usable in the context of

choreographies?

c. If not, how can they be adapted to make them applicable?

3. How can detected mismatches be resolved?

a. Which techniques are used in similar situations?

b. Is full-automatic process alignment feasible and if not, is providing (several)

alignment suggestions sufficient?

Figure 1-6 represents the research model that is defined for this project. In short, the model can

be described as follows: An extensive literature study about choreographies, provided

behaviour, mismatch patterns, detection techniques and resolving techniques (I) will increase

the domain knowledge and provide several points of interest (II) which, then, can be used for

analysis (III) and the development of a new method for detecting mismatch patterns and

resolving those mismatches (IV).

Introduction

- 9 -

Figure 1-6 Research model

1.5 Contribution

By developing a method for conformance checking we aim to clearly indicate where and how

the provided behaviour violates the required behaviour described in the choreography.

Subsequently, we will solve the mismatches by generating adapters. The literature discussed

below focuses only on parts of the “conformance to choreography” aspect. In this thesis we

distinguish ourselves by providing an approach that covers the complete process, from

describing mismatch patterns to detecting them, and finally solving them.

Equivalence checking techniques in previous work (e.g. bisimulation) provide binary answers

only, i.e. two models are equal or unequal. In more recent work, Alves de Medeiros, van der

Aalst and Weijters (2008), present slightly more advanced techniques. However, they focus on

equivalence between processes expressed in percentages, rather than detecting certain

mismatch patterns, and resolving those mismatch patterns. Dijkman (2008) presents a set of

mismatch patterns and a technique for detecting these mismatch pattern. Nevertheless, he aims

on detecting mismatches between similar business processes rather than on web services. A

corollary of this is that both the set of mismatch patterns and the technique for detecting them

cannot be used for web service without any adaptations.

Introduction

- 10 -

Existing literature about solving mismatches only describes a classification of possible adapters

(Benatallah, Casati, Grigori, Motahari Nezhad, Toumani, 2005) or does not provide solutions for

all cases, such as missing messages (Dumas, Spork & Wang, 2006). Gierds, Mooij & Wolf (2008)

developed a technique for generating adapters automatically. Their technique relies on a set of

transformation rules that specify the allowed behaviour of an adapter. However, they do not

provide a technique for obtaining these transformation rules and simply assume that it is given.

Introduction

- 11 -

1.6 Thesis Structure

The remainder of this thesis is structured as follows.

Chapter 2 – Related Work – presents the state of the art work with respect to mismatch patterns,

detecting mismatches and resolving mismatches.

Chapter 3 – Mismatch Patterns for Web Services – answers the first research question by

providing a set of mismatch patterns that could be identified between provided behaviour

and required behaviour.,

Chapter 4 –Detecting Mismatch Patterns – answers the second research question and elaborates

on the technique that we use for detecting mismatches between provided behaviour and

required behaviour.,

Chapter 5 – Resolving Mismatches – answers the third research question by describing the

approach for resolving mismatches. It introduces a mapping from mismatch patterns to

transformation rules. This mapping can be used with existing techniques for generating

adapters that resolve the mismatches.

Chapter 6 – Validation and Complete Example –validates the whole process of detecting and

resolving mismatches. It also shows a running example of the entire process.

Chapter 7 – Conclusion and Future Work– discusses the validation results and relates them to

the contribution of this thesis. This chapter also gives an overview the limitations and

provides some directions for future work.

Appendix A – Order-management Choreographies – contains all chorography models that are

used during the validation process.

Appendix B – Detailed Validation Results – provides tables with more detailed validation results

of each test case.

Related Work

- 12 -

2 Related Work

This chapter gives a short overview of work that is related to our research. The first part

discusses literature related to mismatch patterns. The second part describes the findings on

detecting differences between two (process) models. The third part discusses literature related

to solving mismatches.

2.1 Mismatch Patterns

In order to identify differences between provided behaviour and the required behaviour

described by the choreography, we will concentrate on several frequently appearing mismatch

patterns. Defining specific mismatch patterns will not only simplify the detection part, but also

help with exactly indicating where certain differences occur. Furthermore, developing a method

for detecting mismatch patterns rather than random inconsistencies, will be of significant help

in the next step; resolving the detected mismatches.

Dumas, Spork & Wang (2006) describe mismatch patterns indirectly. In their work they address

the problem of interface service adaptation, i.e. how to adapt the interface of a service provided

in case it does not match the required or expected interface. In order to deal with the

mismatches they have introduced six transformation operators. Each transformation operator

solves a certain mismatch. However, they do not discuss situations such as missing messages.

Hence, the number of mismatch patterns that can be derived from the transformation operators

is rather limited.

Benatallah et al. (2005) also discuss web service adaptation in their research. They characterize

the web service adaptation problems by identifying and classifying different kinds of adaptation

requirements. They present mismatch patterns in the context of choreographies. Like Dumas et

al. (2006) they focus on developing adapters for web service integration, rather than identifying

all possible mismatch patterns. Therefore, their set of mismatch patterns is rather limited as

well.

So far, mismatch patterns are discussed most extensively by Dijkman (2007). In his work he

presents a collection of sixteen frequently occurring mismatches between similar business

processes. These mismatch patterns focus on identifying differences between activities of

processes, between the control flow relations and between the authorization of people to

Related Work

- 13 -

perform these activities. The business processes discussed by Dijkman (2007) do not include

communication activities like sending and receiving messages. However, this is an important

aspect of conformance checking in the context of choreographies as we are mainly interested in

successful collaboration between two parties. On the other hand, authorization mismatches like

“Single role vs. collection of roles” or “different collection of roles” as described by Dijkman

(2007) as well, are not of interest in this case since successful collaboration is not affected by

them in anyway. Moreover, choreographies do not include information considering

authorization issues or role assignment.

Similar to Dijkman (2007), Küster, Gerth, Förster & Engels (2008) describe differences between

process models of process aware information systems. For defining the differences they make

use of SESE fragments. A SESE fragment is a subgraph of the process model that contains a

single entry and en single exit Vanhatalo, V¨olzer & Leymann (2007). Küster, Gerth, Förster &

Engels (2008) discuss four generic fragment differences which can be split into more specific

differences. However, like Dijkman (2007), they also focus on business processes rather than

web services. Hence, they do not distinguish between send and receive activities.

2.2 Detecting Mismatches

A choreography describes a standardized collaboration protocol of multiple parties within a

value chain. For a party that wants to participate in this value chain, it is important to know

whether successful participation is possible (using its current collaboration protocol). This

means that this party wants to know whether, theoretically, the relevant part of the

choreography can be substituted by its own business protocol. Bordeaux, Sala, Berardi &

Mecella (2004) say that web service X is substitutable by web service Y if web service X can be

replaced by web service Y without introducing flaws into the system. From this definition we

can say that substitutability is related to detecting mismatches. It has to be noted that,

practically, we do not intend to substitute parts of the choreography. After all, the choreography

is a standard showing how the collaboration should be implemented, rather than an

implementation itself.

Currently, two kinds of approaches for substitutability checking of web services are discussed in

literature. One approach mainly focuses on compatibility checking, see for instance Brogi &

Popescu ( 2007), Martens (2003b), Martens (2005), Massuthe & Schmidt (2005), Bordeaux et

al. (2004), Foster et al. (2003) & Foster et al. (2004). Compatibility checking is testing whether

Related Work

- 14 -

two web services can collaborate successfully. That is to say, checking for deadlock freeness,

weak termination and alike. The other approach focuses on conformance checking, see for

instance Rozinat van der Aalst (2005), van der Aalst, Dumas, Ouyang, Rozinat & Verbeek

(2006), Alves de Medeiros, van der Aalst, Weijters (2008), van der Aalst, Alves de Medeiros,

Weijters (2007), Dijkman & Dumas (2004) and Tretmans (1996). Conformance checking is

verifying whether the provided behaviour conforms to a reference model. Dijkman & Dumas

(2004) present a technique for testing conformance between provided behaviour and a

choreography. However, their technique is based on bisimulation equivalence and therefore

also provides only limited feedback. Rozinat & van de Aalst (2005), van der Aalst, Dumas,

Ouyang, Rozinat & Verbeek (2006), Alves de Medeiros, van der Aalst, Weijters (2008), described

techniques for measuring the fitness and appropriateness between a process model and an

event log. Using their algorithm, a percentage of equivalence can be calculated rather than just a

binary answer. However, in case of low fitness only limited feedback is provided. Although, their

technique is able to indicate missing and remaining tokens in the process, they do not identify

the nature of the problem. Dijkman (2008) developed a technique to pinpoint differences

between process models. Although his work is very similar to our research, he does not include

conformance checking in the context of web services. A corollary of this is that the technique

cannot distinguish between send and receive activities, as they do not exist as such in business

processes.

2.3 Resolving Mismatches

Two main approaches exist for resolving mismatches. The first approach is to redesign the

implemented process. This approach has the drawback that it does not necessarily preserve

backward compatibility. The redesigned provided behaviour is tailored to the new standard

and, most likely, will not be able to continue successful collaboration with previous partners.

The other approach uses bridging mechanisms for solving the encountered mismatches.

Bridging mechanisms try to establish successful collaboration without changing the provided

behaviour. Dumas, Spork & Wang (2006), Benatallah, Casati, Grigori, Motahari Nezhad &

Toumani (2005) and Gierds, Mooij & Wolf (2008) call this kind of mechanism adapters or

mediators. The term adapter is used in the sequel. An adapter is a mechanism that bridges

incompatibilities of various aspects (format, semantics, behaviour, etcetera) between two

services (Gierds, Mooij & Wolf, 2008). If a web service uses an adapter, then this web service

communicates through the adapter with other web services. The purpose of the adapter is to

ensure successful collaboration between the two web services. This means that the two web

Related Work

- 15 -

services are compatible if the adapter is used, but they may be incompatible without the

adapter. The major benefit of using adapters for simulating the required behaviour is that an

organization does not have to redefine its process definition.

Dumas, Spork & Wang (2006), state that adapters should not add new send activities to a web

service. They state that adapters rather manipulate the existing activities in such a way that

successful collaboration can be achieved, for instance by changing the order of certain

messages. However, not all mismatches between the existing behaviour and the required

behaviour can be solved only by manipulating the existing behaviour. Therefore, in some cases

it is required to add send activities to the adapters. With the following scenario we want to

show that adding send activities to the adapter is reasonable in some cases. Imagine for instance

a hotel booking system that does not provide a response message after a booking request is

received. If sending the response message is required according to the choreography then this

functionality needs to be added to the web service. An adapter could create a response message

by using data from the booking request, such as the hotel name and the customers’ name. In this

case the response message contains default data and, thus, can be generated by the adapter.

Indeed, data that cannot be derived from other messages, such as passwords or personal data

cannot be generated by the adapter.

Mismatch Patterns for Web Services

- 16 -

3 Mismatch Patterns for Web Services

Before describing the mismatch patterns, it has to be noted that two different viewpoints can be

distinguished while seeking for mismatches between web services. The viewpoint defines from

which perspective the models are analyzed. The used viewpoint is quite important as it has

impact on presenting and resolving the mismatches found. In what follows, all mismatch

patterns are described from the perspective of the party that wants to participate in the value

chain, i.e. with a skipped activity we refer to the situation in which the provided behaviour,

rather than the required behaviour, fails to send or receive a certain message. Hence, adding

that particular activity to the provided behaviour would be a logical consequence for resolving

the mismatch. Note that an activity in this context corresponds to the execution of a specific

task, which is either sending or receiving a certain message. Analyzing the mismatch described

above from the perspective of the required behaviour would give the impression that the

skipped activity should be added to the choreography.

A possible application for using the perspective of the choreography would be in the context of

standardization negotiation between multiple parties. In this case the standard can be fine-

tuned by testing it amongst multiple existing implementations, and hereby identifying and

resolving common differences. Many of the mismatches are caused due to differences between

dependencies of related mismatches. In this case, only direct preceding activities are considered

as dependent activities. Activity A is directly preceding activity B, iff (i) A is performed before B,

(ii) A is connected to B and (iii) there is no other activity between A and B. A final remark; due

to space limitations only the relevant parts of the choreography are shown in the example

figures below.


- 17 -

3.1 Mismatch Patterns

After analyzing the mismatch patterns described by Dijkman (2007), Dumas et al. (2006) and

Benatallah et al. (2005) we concluded that the patterns MP1-MP11 are of interest while testing

conformance to choreographies. Table 1 gives an overview of the sources of each mismatch

pattern. We are convinced of their relevance as they could be reproduced using the example

choreography described in the introduction. In Dijkman (2007) five additional patterns are

described. Those patterns are not included since they are irrelevant while testing conformance

to choreographies. The group of authorization mismatches does not influence successful

collaboration and is therefore not included in the mismatch collection. The “interchanged

activities” mismatch is not included as well. This mismatch describes the situation in which two

activities have the same effect, but obtained differently. One could interpret this mismatch as

two messages having a different data format, but serving the same purpose. Although this

mismatch is important in the context of choreographies as well, it does not represent a

behavioural mismatch and is therefore excluded from the collection.

Dijkman (2007) does not distinguish between send and receive activities. However, in the

context of web services it is important to differentiate between the two activities. We do not

explicitly distinguish between them for describing the mismatch patterns, since the nature of

both versions is similar. However, when resolving mismatches the version becomes important.

Consequently, both versions are thoroughly discussed in section 5.

Table 1 Sources of mismatch patterns Dijkman (2007) Dumas et al. (2006) Benatallah et al. (2005)

3.1 X X MP2 X* X X MP3 X X X MP4 X X X MP5 X MP6 X X MP7 X X MP8 X MP9 X MP10 X MP11 X MP12 X *Dijkman does not describe the mismatch patterns from a specific perspective. Therefore the “extra

activity” mismatch is already covered by the “skipped activity” mismatch and is not discussed explicitly.


- 18 -

MP1 Skipped activity: the skipped activity pattern describes the situation in which a send or

receive activity has to take place according to the choreography, but there is no related activity

represented in the provided behaviour. For instance, a seller might only allow indirect order

changes by cancelling the original order followed by a new order request. Figure 3-1 shows a

simplified version of the provided behaviour which does not include a change activity.

Figure 3-1 Skipped Activity


- 19 -

MP2 Extra activity: The extra activity is the opposite of the skipped activity, i.e. the provided

behaviour contains an activity whereas there is no related activity described in the

choreography. Some suppliers might only start processing an order after receiving a

confirmation message from the buyer. The confirmation may be needed in situations where the

seller cannot completely fulfil the order request, e.g. due to stock shortage. Therefore, the buyer

has to confirm the new quantities or delivery dates by sending a confirmation message. Figure

3-2 shows the provided behaviour and the relevant part of the choreography.

Figure 3-2 Extra activity


- 20 -

MP3 Split activity: the split activity mismatch describes a situation in which one send

activity or one receive activity in the choreography is related to a collection of send activities or

a collection of receive activities, respectively, in the provided behaviour. In this case, the single

activity is split into a collection of activities in the provided behaviour. E.g. the order request in

the choreography includes payment details whereas the payment details in the provided

behaviour are send separately after receiving the order response (Figure 3-3). This mismatch

might invoke MP2 (extra activity) as well since in some cases the buyer may require receiving a

confirmation message after the payment details are sent successfully. Special attention is

required as one activity may be split into multiple activities having an arbitrary number of

activities in between them. They do not necessarily need to be two sequential activities.

Send

Order RequestStart

EndReceive

Order ResponseSend

Payment DetailsP1

Order Response Payment DetailsOrder Request

P2

Send

Order RequestStart

Receive

Order ResponseP1

Order ResponseOrder Request

End

Provided Behaviour

Required Behaviour

Figure 3-3 Split activity


- 21 -

MP4 Refined activity: The opposite of the split mismatch is called refined activity. This

mismatch refers to a pattern in which one single activity in the provided behaviour corresponds

to a collection of activities in the choreography. We say that this activity is refined by a

collection of activities in the choreography. See Figure 3-4 for an example.

Receive

Credit RequestStart Send

Credit Check

P1

Credit CheckCredit Request

P2

Receive

Credit RequestStart

Send

VIS Check

P1

VIS CheckCredit Request

P4

Send

EVA Check

EVA Check

Provided Behaviour

Required Behaviour

P2

P3 Send

CKI Check

CKI Check

P5

P6

Figure 3-4 Refined activity


- 22 -

MP5 Partly corresponding activities: This mismatch is a special version of the refined

mismatch pattern. Activities are only partly corresponding if they partly represent the same

kind of messages and partly a different kind of message. For instance in Figure 3-5, the provided

behaviour sends one message containing the CKI & VIS check. The required behaviour on the

other hand, sends one message containing the CKI & EVA check, whereas the VIS check is

performed separately. This mismatch is different from the two previous mismatches (MP3 and

MP4) as there is no way to split nor merge the messages such that they exactly resemble each

other.

Receive

Credit RequestStart Send

CKI & VIS Check

P1

Credit CheckCredit Request

P2

Receive

Credit RequestStart

Send

VIS Check

P1

VIS CheckCredit Request

P4

Send CKI & EVA

Check

Credit Check

Provided Behaviour

Required Behaviour

P2P5

Figure 3-5 Partly corresponding activities


- 23 -

MP6 Iterative vs. once-off occurrence: this mismatch pattern reflects the situation in which

a send or receive activity in the choreography is part of a loop whereas it is not in the provided

behaviour, or the other way around. In the order-management process choreography as

described in the introduction, a buyer was allowed to change the order only once. However,

some buyers may have multiple change requests in their process. In this case the buyer is able

to change the order until he is satisfied with the order response. This type of mismatch is

illustrated in Figure 3-6 (only the relevant part is modelled).

Send

Change RequestP1

P2

Change ResponseChange Request

Send Change

RequestP1

Receive

Change ResponseP2

Change ResponseChange Request

P3

Provided Behaviour

Required Behaviour

Receive

Change Response

Figure 3-6 Iterative vs. once-off occurrence


- 24 -

MP7 Different dependencies: In this type of mismatch an activity in the provided behaviour

has a different dependent activity than the corresponding activity in the choreography. For

illustrating this mismatch, we use an extended version of the choreography described in the

introduction. This extended version has one additional participant, a shipper. In the

choreography, the order response is sent directly after receiving the credit check response. In

the provided behaviour of the new seller, on the other hand, the order response depends on the

shipping notification (see Figure 3-7).

Figure 3-7 Different dependencies

MP8 Additional or less dependency: An additional dependency is a special case of a

dependency mismatch. In this case, the activity in the provided behaviour has more

dependencies than the corresponding activity in the choreography. For example, recall the

provided behaviour and required behaviour presented in Figure 3-6. The activity “Send Change

Request” has “Receive Change Response” as an additional dependency. Obviously, this mismatch

may occur the other way around as well resulting in a “less dependency” mismatch.


- 25 -

MP9 Activities occur at different moments in process: This mismatch pattern describes

the case in which an activity is represented in both the choreography and in the provided

behaviour, but appear at a different moment in the process (their set of dependencies is

disjoint). Obviously, this mismatch implies that the different dependency mismatch occurs as

well. Although the activity is performed in both the provided behaviour and in the

choreography, the occurrence at a different moment could lead to a deadlock. E.g. in the

choreography, the seller sends a shipment notification and then, waits for the payment details.

The provided behaviour, on the other hand, requires the buyer to send the payment details first.

This situation is shown in Figure 3-8.

Receive

Payment DetailsStart

Send

Shipment NotificationP1

Shipment NotificationPayment Details

End

Send

Shipment NotificationStart

Receive

Payment DetailsP1

Payment DetailsShipment Notification

End

Provided Behaviour

Required Behaviour

Figure 3-8 Activity at different moment


- 26 -

MP10 Different conditions for occurrence: in some cases, two related activities have the

same set of dependencies but their conditions for occurrence differ. This mismatch only applies

if the actual set of dependencies is identical. Situations which include different dependencies as

well are already covered by MP7. Figure 3-9 shows an example of this kind of mismatch. “Credit

Response” has the same set of dependencies. However, the provided behaviour always requires

to receive the message “CKI Check” before sending the credit response. This is not the case in

the choreography as the EVA Check is a suitable alternative.

Receive

CKI Check

P1

CKI Check

P4

Receive

EVA Check

EVA Check

Provided Behaviour

Required Behaviour

P2

Receive

VIS Check

P5

VIS Check

Send

Credit Response

Credit Response

P6

Receive

CKI Check

P1

CKI Check

P3

Receive

EVA Check

EVA Check

Receive

VIS Check

P2P4

VIS Check

Send

Credit Response

Credit Response

P5

Figure 3-9 Different conditions for occurrence


- 27 -

MP11 Conditions for occurrence less strict: This mismatch is one of the two specializations

of MP10. A less strict condition for occurrence indicates that there are more situations in which

a certain activity can occur in the provided behaviour compared to the choreography, although

the set of dependencies is identical. Usually, this is caused due to a conflict in the type of

divergence of one branch into multiple branches (and join versus xor join). Figure 3-10 shows

an example of the mismatch pattern.

Provided Behaviour

Receive

CKI Check

CKI Check

P4

Receive

EVA Check

EVA Check

Receive

VIS Check

P3

VIS Check

Send

Credit Response

Credit Response

P6

Required Behaviour

Receive

CKI Check

CKI Check

P5

Receive

EVA Check

EVA Check

Receive

VIS Check

P4

VIS Check

Send

Credit Response

Credit Response

P8P2

P5

P6

P7

Figure 3-10 Conditions for occurrence less strict


- 28 -

The provided behaviour only requires one of the three tests, whereas all three tests are required

in the required behaviour. Therefore the conditions for occurrence are considered to be less

strict. This can easily be shown with the truth table as presented in Table 2.

Table 2 Truth table for occurrence of "Send Credit Response" CKI EVA VIS CKI v EVA v VIS CKI ^ EVA ^ VIS

0 0 0 0 0 0 0 1 1 0 0 1 0 1 0 0 1 1 - 0 1 0 0 1 0 1 1 0 - 0 1 0 1 - 0 1 1 1 - 1

The status of each message is either indicated with 1 (received) or 0 (not received). The four

cases denoted by a “-“ are impossible due to the definition of an xor-split. The fourth column

represents the situation of the provided behaviour of Figure 3-10. As can be seen, the credit

response message is sent in three out of eight cases. In the required behaviour on the contrary

(fifth column), only one out of eight cases enables the possibility for sending the credit response

message.

It has to be noted that this mismatch pattern can be slightly more complex than described

above. Figure 3-11 gives another example of provided behaviour causing a less strict condition

for occurrence. However, this mismatch is not exactly the same as the one presented in Figure

3-10. In this case only two out of three messages will be sent by the credit supplier, whereas in

the choreography example in Figure 3-10 all three are required.

Figure 3-11 Conditions for occurrence less strict (example II)


- 29 -

MP12 Conditions for occurrence stricter: This mismatch is also a specialization of MP10 and

can be considered as the opposite of MP11. A stricter condition for occurrence indicates that

there are fewer situations in which a certain activity can occur in the provided behaviour

compared to the choreography, although the set of dependencies is identical. Interchanging the

provided behaviour and required behaviour of Figure 3-10 would represent an example of this

mismatch.

3.2 Relations between Mismatch Patterns

Some of the mismatch patterns described in the previous section are related to each other.

Moreover, some mismatch patterns are very general whereas others can be quite expressive. A

general mismatch usually implies the presence of a more expressive mismatch as well. We

consider a mismatch to be more expressive if it reveals more information about the discrepancy.

An example of related mismatch patterns is the pair MP6 (Iterative vs. once-off) and MP7

(different dependencies). The iteration causes a different dependency relation for the direct

succeeding activity since the iteration does not exist in the other process. MP7 can be seen as a

quite general mismatch, whereas MP6 is more expressive. MP6 is considered to be more

expressive since it indicates the source of discrepancy (an iteration).

It has to be noted that relations between mismatches are not symmetric. That is to say, if MPx

implies the presence of MPy then MPy does not necessarily imply the presence of MPx as well.

For instance, occurrence of MP2 always implies occurrence of MP7. Nevertheless, the

occurrence of MP7 does not automatically mean that this is caused by MP2. As a result, we

distinguish two kinds of relations, namely:

1) If MPx then necessarily MPy;

2) If MPx then possibly MPy.

Table 3 represents the relation matrix of all mismatch patterns. Fields marked with an “X”

indicate that the mismatch in the top row always occurs in combination with the mismatch in

the column on the left. Fields marked with an “O” indicate that the mismatch in the top row

possibly occurs in combination with the mismatch in the left column. All fields in the diagonal,

from the top left to the bottom right, contain an “X”. This simply indicates that the occurrence of

each mismatch implies the occurrence of itself (as it has been detected already). Due to a

skipped activity or extra activity in one model, any direct succeeding activity in this model has a


- 30 -

different dependency. However, if the skipped/extra activity is performed last in the process

then there are no direct succeeding activities and, hence, no different or additional

dependencies. Therefore, a skipped activity and likewise extra activities possibly provoke either

of the mismatches MP7, MP8 or MP9. Conversely, a split activity and a partly corresponding

activity always provoke different dependencies as one activity is divided into multiple activities.

If the split activities are performed in parallel, then any direct succeeding activities will have

591additional dependencies as well. A refined activity always provokes different dependencies

since multiple activities are merged into a single activity. Depending on how (parallel or

sequential) the “unmerged” activities in the other process are modeled, this mismatch possibly

causes less dependencies. Iteration within a process exists if one activity is connected with any

of the preceding activities (or itself). Therefore this preceding activity always has different, and

even additional dependencies compared to the related activity in the other process, namely the

source activity of the iteration. Performing certain tasks in parallel rather then in a sequence is

another possible source of different and additional dependencies. Processes with parallel

activities always have activities with different dependencies compared to the equal processes

performed in a sequence, since the activity just after the and-join depends on at least two

activities just before the and join. All aforementioned mismatches possibly, if not always,

provoke different or additional dependencies. Therefore, if a different or additional dependency

is detected, we can assume that this is possibly caused by either of the aforementioned

mismatches. If the conditions of occurrence are either stricter (MP12) or less strict (MP11), then

they are obviously different as well and therefore both mismatches always provoke MP10.

However, if the conditions are different they do not necessarily need to be stricter as they can

be less strict as well, or neither as shown in MP10.

Table 3 Relations between mismatch patterns MPy

MPx 3.1 MP2 MP3 MP4 MP5 MP6 MP7 MP8 MP9 MP10 MP11 MP12

3.1 X O O O MP2 X O O O

MP3 X X O X MP4 X X O O MP5 X X O O MP6 X X X MP7 O O O O O O X O O MP8 O O O O O O X X O MP9 O O O O O X O X MP10 X O O MP11 X X MP12 X X

Legend: X: If MPx then necessarily MPy


- 31 -

O: If MPx then possibly MPy.

Indicating multiple mismatches in the same part of the model is confusing for the analyst and

has to be avoided. Therefore, only the most expressive mismatch should be presented toward

an analyst. The relations described in Table 3 are represented in the form of a hierarchy in

Figure 3-12. This hierarchy shows which mismatches are quite general (high in the hierarchy)

and which are more expressive (low in the hierarchy). The hierarchy can be read top-down

using the “if MPx then possibly MPy” relation, e.g. if MP7 then possibly {MP5, MP8, MP9} or if

MP10 then possibly {MP11, MP12}. Defining relations between mismatches has several

advantages. First, when a mismatch is located high in de hierarchy, only descendant mismatches

have to be checked as well (in the current part of the model). Secondly, if the mismatch found is

an end node it is not worthwhile to check for a more expressive mismatch as they do not exist

(in the current part of the model). These two properties imply that we only need to search for

the top level mismatches until one of them is detected. Then, analyse that part of the model in

detail to find more expressive mismatches.

MP2 MP4

MP10

MP8 MP9

MP7

MP5

MP5

MP6MP3MP1

MP12MP11

Figure 3-12 Hierarchy of mismatch patterns

Figure 3-13 shows an example situation in which multiple mismatches from the collection

above can be detected. First, MP7 occurs since “Order Response” in the provided behaviour

directly depends on “Payment Details” whereas “Order Request” is the direct dependent activity

in the choreography. Secondly, MP2 occurs as the provided behaviour has an extra activity,

namely: “Payment Details”. Now the question arises, which mismatch should be communicated

toward e.g. a business analyst? Consulting the hierarchy reveals that MP2 is the most expressive

mismatch and should therefore be used as feedback.


- 32 -

Figure 3-13 extra activity, different dependencies or both?

Detecting Mismatch Patterns

- 33 -

4 Detecting Mismatch Patterns

Dijkman (2008) has developed techniques for detecting mismatches between two different

process models. Since the mismatch patterns used in Dijkman’s research are similar to our

mismatch patterns, we will apply his technique in the context of conformance checking. Section

4.1 describes the technique in more detail and section 4.2 discussed the relation of the

technique to web services.

4.1 A Technique for Detecting Mismatch Patterns

Dijkman (2008) has defined two different methods, one for detecting different input conditions

and one for detecting different input dependencies. The former one consists of six steps while

the latter one has one additional step. In both cases a process analyst has to indicate manually

the equivalences between tasks of the process models to be compared. A completion occurrence

relation has to be defined by the process analyst as well. This is needed because in the mismatch

detection algorithm the occurrence of single activities is compared rather than sets of activities.

Fortunately, in many cases defining the completion occurrence relation can be automated. For

instance, if a process analyst has indicated that task A and task B are equivalent, then obviously

their completion should coincide as well. Nevertheless, in some cases it is slightly more

complicated. Imagine a situation in which one task corresponds to a set of tasks in the other

process. If the set contains tasks that are performed sequential then the last task in the

sequence implies completion of the whole set. For example, completing task B in Figure 4-1.i

implies the completion of the set {A, B}. If the set contains a choice, then the completion of either

of the tasks corresponds to the completion of the entire set. For example, completing task B or

task C in Figure 4-1.ii corresponds to the completion of the set {A, B, C}. However, in case the set

contains parallelism then it is not possible to specify the occurrence relation. Therefore, special

stub-activities are added in those cases. For example, the completion of the set {A, B, C) in Figure

4-1.iii corresponds with the completion of the stub task.


- 34 -

i.

A BA

B

C

Stub

A

B

C

Stub

ii.

iii.

Figure 4-1 Completion occurrence relation (Dijkman, 2008)

After all relations are defined the following six steps are performed:

1. The algorithm defines equivalence classes for each task. An equivalence class is a set

consisting of a specific task including all tasks it is related to, using the equivalent

occurrence relation.

2. The trace set of each model is generated, indicated with Tr(P).

3. Every task in the trace set of both models is replaced by its equivalence class. The result is

indicated with [Tr(P)].

4. A set of input dependencies of every task in the model is derived, indicated with inp(x). The

set of input dependencies of a certain task contains that task itself and all tasks that directly

precede this task.

5. All tasks in inp(x) are then replaced with its equivalent class, indicated with [inp(x)].

6. The trace set is restricted to the set of input dependencies of the task to be compared,

resulting in a set xs for one process and ys for the other process.

Finally, for detecting different input conditions the two sets xs and ys have to be compared. For

detecting different input dependencies a seventh step has to be performed before comparing xs

and ys, namely removing all activities which are not in the equivalence class of tasks that

directly precede the task to be compared or other tasks in its equivalence class. If the two sets

are different then the two tasks have different input dependencies. Moreover, if one set includes

the other set then the corresponding task has additional input dependencies. If they are equal

then there are no different input dependencies. Figure 4-2 shows an example of how to compute

xs and ys for task C1 and task C2, respectively. Comparing xs and ys reveals that the sets are not

equal, assuming that A1 and A2, B1 and B2, and C1 and C2 have an equivalent occurrence

relation. Therefore C1 and C2 have different input dependencies.


- 35 -

Figure 4-2 Different input dependencies (Dijkman, 2008)

Figure 4-3 shows how to detect different input conditions between the tasks D1 and D2. Again,

A1 and A2, B1 and B2, and C1 and C2 have an equivalence occurrence relation. In the example xs

and ys are different, therefore the input conditions of D1 and D2 are different.

In the third step described above, finite state machines are used to avoid the problem of infinite

traces, see Dijkman (2008) for detailed information. An iterative vs. once-off difference between

two processes can be detected by considering the processes as directed graphs and then

comparing the sets of cycles of the graph.

Figure 4-3 Different input conditions (Dijkman, 2008)

4.2 Discussion

The differences analysis described above puts a token on each starting place, i.e. each place that

does not have incoming arcs, before starting the actual analysis. For modelling web services

normal Petri Nets are extended with interface places that model the communication with the

other party. When only one party from a choreography is modelled, then the interface places do

not have incoming arcs. The difference analysis cannot distinguish between interface places and

starting places and will add tokens on the interface places as well. However, adding tokens on

interface places has a negative effect on the result of the difference analysis.


- 36 -

The web service presented in Figure 4-4 is used for illustrating the problems that may occur.

The example model contains an iteration that allows for receiving multiple messages of type B.

For each received B, a response message of type C is sent to the other party. However, the

difference analysis will not detect the iteration. A token will be placed on interface place B and

interface place C before the actual analysis starts. The first time message B is received the token

on interface B will be consumed and no new token will be placed on interface B. Hence, a second

iteration is not possible according to the difference analysis. In practice however, this web

service is able to receive messages of type B until message D is sent. A second problem occurs

with iterations that contain send activities. Each time a send activity is performed a token will

be placed in the corresponding interface place. If the iteration can occur unlimited times then

the model would have an infinite state space. The current difference analysis cannot deal with

models containing an infinite state space.

To prevent the two aforementioned problems, all interface places are removed before

performing the difference analysis. Hereby multiple iterations are possible and the infinite state

space problem is avoided.

Send A

P3

Start

End

Receive B Send C

Receive D

P1

B CA D

P2

Figure 4-4 interface problem

Another issue of the difference analysis is that it cannot identify the activity type (send or

receive) involved in the mismatch. The difference analysis was developed with the intention to

detect differences between business processes rather than differences between web services.

Unlike web services, business processes do not contain send and receive activities.

Nevertheless, the activity type is important for solving mismatches found. There are several

opportunities for identifying the activity type.


- 37 -

It is common practice to indicate send activities with an exclamation mark and receive activities

with a question mark. These two identifiers can be used to reveal the activity type. Also the

words “send” and “receive” within the label of the activities can be used for deriving the activity

type. Furthermore, the direction of the arc connecting an activity to interface places can be used

for identifying the activity type. If the arcs points from the activity to the interface place then the

activity is a send activity. If the arc points from the interface place to the activity then the

activity is a receive activity. Hence, there are sufficient possibilities to derive the activity type

involved in mismatches found during the difference analysis. The latter approach is only

possible if the end place can be identified. The start place can be identified by its initial token.

The technique for detecting mismatches is based on the notion of completed trace equivalence.

Hence, mismatches that only occur when using stronger notions of equivalence cannot be

detected. Typically, these are differences with respect to the branching time. If such difference

exists, among others, between the provided behaviour and the required behaviour then Fiona

might considers the provided behaviour and partner behaviour as uncontrollable and cannot

generate an adapter. Detecting differences with respect to branching time is considered as

future work.

Resolving Mismatches

- 38 -

5 Resolving Mismatches

An organization that wants to participate in the value chain has to make sure that mismatches

that endanger successful collaboration are resolved. This chapter describes a technique for

generating adapters based on the mismatches found. Subsequently, the adapters can be used for

resolving the mismatches.

The approach discussed below requires, besides the provided behaviour, also the partner

behaviour for generating the adapter. This is not directly a limitation of our approach since we

are able to obtain the partner behaviour from the choreography as well. However, by using the

partner behaviour from the choreography, we are only able to guarantee successful

collaboration with partners that implement the behaviour as described in the choreography.

5.1 Generating Adapters

Gierds, Mooij & Wolf (2008) developed a technique for generating adapters. To construct an

adapter, basically, they first create a service that transforms messages according to a

specification of elementary activities. Then, they create a controller to manage the order in

which the transformation rules are applied and in which order generated messages are

forwarded. Figure 5-1 describes the functionality of an adapter graphically. The created service

together with the controller forms the adapter. In what follows, the approach is elaborated on.

Adapter

Provided

Behaviour

Controller

Service

Based on SEA

Partner

Behaviour

Figure 5-1 Web service adapter

The technique of Gierds, Mooij & Wolf (2008) for generating adapters relies on a specification of

elementary activities (SEA). The SEA is a set of transformation rules that define the allowed

behaviour of the adapter. Table 4 shows some examples of transformation rules that are


- 39 -

accepted as input for generating an adapter. In general, all rules in the form of X→ Y, where X

and Y can be any subset of a bigger set of messages, are accepted for generating an adapter.

Table 4 Elementary activities expressed as transformation rules (Gierds, Mooij & Wolf, 2008).

Nr. Name Transformation rule 1 2 3 4 5 6 7

Create A Copy A Consume A Transform A into B Split A into B, C, D Merge A, B, C into D Recombine A, B, C to D, E, F

→ A

A→ A, A

A→

A→B or A→A, B

A→B, C, D

A, B, C → D

A, B, C → D, E, F

Create: This transformation rule defines that the adapter is allowed to generate a

message.

Copy: This transformation rule defines that the adapter is allowed to copy a message

i.e. forward the message multiple times.

Consume: This transformation rule defines that the adapter is allowed to consume a

message, i.e. not forward a received message.

Transform: This transformation rule defines that the adapter is allowed to transform a

message into another message. The original message may or may not be

forwarded as well.

Split: This transformation rules defines that the adapter is allowed to split one

message into two or more messages.

Merge: This transformation rule defines that the adapter is allowed to merge two or

more messages into one message.

Recombine: This transformation rule defines that the adapter is allowed to combine multiple

messages with each other.

We would like to add another interpretation of the fourth transformation rule. Instead of

transforming messages, we will interpret this transformation rule as a dependency rule. That is,

upon receiving message A, consume this message and create message B. Another interpretation

will be; when receiving message A, then forward this message and create also message B.

Based on the SEA a service is created for transforming the messages. The service contains all

interface places of the provided behaviour and the partner behaviour. Incoming interface places

are used for receiving messages from the provided- or partner behaviour. Outgoing interface


- 40 -

places are used for forwarding messages to the provided- or partner behaviour. Hence, for

obtaining the interface places both services are required when generating the adapter.

Furthermore, the new service consists of three kinds of transitions:

Receive transitions for receiving messages on the incoming interface places.

Transitions that perform the actual transformations.

Send transitions for moving messages to the outgoing interfaces.

Every transition in the new service is monitored and/or triggered by the aforementioned

controller. Consequently, the new service has additional interface places for:

Notifying the controller about incoming messages;

Triggering the application of a transformation rule;

Acknowledging execution;

Triggering the delivery of an outgoing message.

The last step for generating an adapter is the creation of the controller. The controller schedules

the available activities, the execution of transformation rules and the forwarding of outgoing

messages. The controller is created by using the provided behaviour, the required behaviour

and the just created service. Furthermore, existing techniques, based on the concept of

controllability (Massuthe & Wolf, 2007) and (Martens, 2003), are used. By using these

techniques the created controller is most permissive. That is to say, the controller enforces

properties, including deadlock freeness, on the composed system with no unnecessary

restrictions. Hereby, the maximum communication capabilities between the provided behaviour

and partner behaviour are maintained.

Gierds, Mooij & Wolf (2008) do not discuss how to obtain the SEA and simply assume that it is

given. We state that the mismatch patterns, presented in section 3, can be used for generating

the SEA. In the following section we will present a mapping from mismatch patterns to

transformation rules. This mapping can be used for generating the SEA when detecting

mismatches. In section 6 we will use multiple test cases for validating our statement.


- 41 -

5.2 Mapping Mismatch Pattern to Transformation Rules

The following sub paragraphs show the mapping from mismatch patterns to transformation

rules. The language proposed by Gierds, Mooij & Wolf (2008) is used for specifying the

transformation rules.

5.2.1 Skipped activity

The skipped activity refers to the situation in which the provided behaviour does not contain an

activity that is described in the choreography. First, the provided behaviour can have a skipped

“send activity”. This means that the provided behaviour is not able to send a message which the

other party might expect to receive.

In this research we assume that an adapter can generate both control messages and messages

containing default data. This means that also skipped “send activities” are mapped to

transformation rules. Generating messages with data would mean that a send activity is added

to the adapter. Dumas, Spork & Wang (2006) argue that adding send activities is undesirable

from a software maintenance perspective, since changes to the functionality would require

developers to trace back which adaptors need to be changed. We do agree with their point of

view. Nevertheless, our aim is to provide a technique that is able to resolve as many mismatches

as possible. We leave the decision to make use of adapters that add send activities to developers

themselves.

The provided behaviour can also have a skipped “receive activity”. This means that the provided

behaviour is not able to receive a message that the other party might send to him. Below, both

situations are discussed in detail.

Skipped “receive activity”

The position of the skipped “receive activity” is of importance when mapping this mismatch to a

transformation rule. Two possible positions are distinguished; (1) skipped receive-activities

that are part of a sequence, and (2) skipped receive-activities that are part of a deferred choice.

If the skipped “receive activity” is part of a sequence, then the adapter needs to have an

interface to receive this message. Assuming that receiving message X is a skipped “receive

activity” and message X is not part of a deferred choice, then the following transformation rule

applies.

X →; (Consume message X)


- 42 -

This transformation rule states that the adapter is allowed to consume message X. For achieving

this behaviour, the adapter will be equipped with an interface place “X”, an activity called

“Receive X” and a transformation activity for consuming the message. Hence, the missing

activity is now provided by the adapter and not “skipped” anymore.

If the skipped “receive activity” is part of a deferred choice, then more action is required.

Assuming that receiving message X is a skipped “receive activity” and receiving X is part of a

deferred choice, then the following transformation rule applies.

{D} represents a set of transformation rules that is required to achieve successful termination in

the provided behaviour in case message X is sent by the partner behaviour. We elucidate this

mapping with an example. Consider the provided behaviour and required behaviour presented

in Figure 5-2. Both parties first send a message of type A and then wait for a response. However,

the provided behaviour is only able to process a response message of type B, whereas the

required behaviour is also able to receive a message of type C. In this case we say that message

B and C are part of a deferred choice. If the adapter only receives message C and does not take

other actions, then the provided behaviour would remain waiting for receiving message B.

Therefore, a default branch within the provided behaviour has to be selected such that the

provided behaviour is able to terminate properly as well. In this particular case receiving

message B in the provided behaviour is not part of a deferred choice. Hence, only one branch

exists, namely receiving message B. This branch is selected as default. This results in the

following SEA for the example presented in Figure 5-2.

SEA:

Since generating message B depends on receiving a message of type C, we can apply the

dependency rule we have introduced before.

If more messages are exchanged within the default path, then for each message a

transformation rule has to be generated. In case the provided behaviour also contains a

X→; (Consume message X) {D}

C → B; (Generate message B when receiving message C)

C→; → B;


- 43 -

deferred choice, the default branch has to be selected randomly or, preferably, manually by a

business analyst.

Send AStart Receive BP1

BA

End

Send AStart Receive CP1

CA

End

Receive B

B

Provided Behaviour

Required Behaviour

Figure 5-2 Skipped “receive activity” (deferred choice)

Skipped “send activity”

Similar to the skipped “receive activity”, the position of the skipped “send activity” is of

importance when mapping this mismatch to a transformation rule. Two possible positions are,

(1) skipped “send activities” that are part of a sequence, and (2) skipped “send activities” that

are part of a deferred choice.

If the skipped “send activity” is part of a sequence then an adapter can resolve this mismatch by

generating the message. For instance, if sending message X is a skipped “send activity” and

message X is not part of a deferred choice, then the following transformation rule applies.

This transformation rule states that the adapter is allowed to create message X. For achieving

this behaviour, the adapter will be equipped with an activity called “Send X” and an interface

place “X”. Hence, the missing activity is now provided by the adapter and not “skipped”

anymore.

→ X; (Generate message X)


- 44 -

If the skipped “send activity” is a response to receiving a particular message, then the

dependency rule can be applied. For instance, if sending message X is a response to receiving

message Y, then the following transformation rule applies.

This transformation rule states that after the adapter received message Y it has to forward this

message and generate message X. Note that receiving message Y may be a skipped activity as

well. In this case the transformation rule for the skipped “receive activity” can be merged with

the transformation rule for the skipped “send activity”.

If sending message X is part of a deferred choice, then it is not necessary to solve this mismatch

using an adapter. Consider for example the situation in Figure 5-3. The provided behaviour

responds with message B after receiving message A. The required behaviour, on the other hand,

is able to respond with message B and with message C. Since message C is part of the deferred

choice it is not necessary to resolve this mismatch. The provided behaviour simply never uses

the branch of sending message C. In this case, a skipped activity does not lead to incompatibility

from a behaviour point of view.

Y → X; (Consume message Y and generate message X)

Y → Y, X; (Forward message Y and generate message X)


- 45 -

Receive AStart Send BP1

BA

End

Receive AStart Send CP1

CA

End

Send B

B

Provided Behaviour

Required Behaviour

Figure 5-3 Skipped Send Activity (Branching)

All transformation rules that belong to the group “skipped activity” are summarized in Table 5.

Using these transformation rules an adapter for solving the corresponding mismatches can be

generated. {D} has to be substituted by all transformation rules that apply to the default path.

Table 5 skipped activity transformation rules

Activity Mismatch Rewrite rule Send X! Skipped send activity →X; Send X! Skipped send activity (as response to Y) Y→Y,X; Send X! Skipped send activity (deferred choice) None

Receive X Skipped receive activity X→; Receive X Skipped receive activity (deferred choice) X→;

{D } Receive Y Send X

Skipped receive activity Skipped send activity (as response to Y)

Y → X;

5.2.2 Extra activity

The extra activity refers to the situation in which the provided behaviour contains an activity

that is not described in the choreography. First, the provided behaviour can have an extra “send

activity”. This means that the provided behaviour will send a message which the other party


- 46 -

might not be able to process. Second, the provided behaviour can have an extra “receive

activity”. This may result in a deadlock, since the provided behaviour will wait for a message

that the other party does not send. Below, the mapping from mismatch pattern on to

transformation rules for both situations is described.

Extra send activity

The position of the extra “send activity” is of importance when mapping this mismatch to a

transformation rule. The possible positions are similar as for the skipped activity, (1) extra

“send activities” that are part of a sequence, and (2) extra “send activities” that is part of a

deferred choice. The generated adapter needs to be able to consume the message in case the

extra “send activity” is part of a sequence. If sending message X is an extra activity and not part

of a deferred choice then the following transformation rule applies.

This transformation rule states that the adapter is allowed to consume message X. For achieving

this behaviour, the adapter will be equipped with an interface place “X”, an activity called

“Receive X” and a transformation activity for consuming the message. The other party will

consider this communication between the adapter and provided behaviour as an internal

activity, since the adapter does not forward message X. Hence, the extra “send activity” becomes

a silent activity and is not detected anymore as a mismatch. Nevertheless, an adapter consuming

a message needs to be used with caution. The message might contain important information

which is crucial for the overall process.

If the extra “send activity” is part of a deferred choice, then another solution should be applied.

Consider for example the provided behaviour and required behaviour presented in Figure 5-4.

Both parties first wait for receiving a message of type A. However, the provided behaviour is

able to send a response message of type B and type C, whereas the required behaviour is only

able to send a response message of type B. In this case, we say that message C is part of a

deferred choice in the provided behaviour. Generating an adapter that consumes message C is

not sufficient, assuming that the partner behaviour requires receiving message B for successful

termination. Identifying a default path could solve this issue (similar to a skipped “receive

activity” with branching). For solving the mismatch presented in Figure 5-4 the default path

would be sending message B. Therefore, the adapter has to generate message C after receiving

message B. Another possible option for solving this mismatch is to disable the extra “send

X →; (Consume message X)


- 47 -

activity”. By using this approach no adapter is needed. Disabling the extra “send activity” is a

more appropriate solution for this mismatch. Therefore, in this research it is assumed that extra

“send activities” that are part of a deferred choice can be disabled.

Receive Ap1 Send Bp2

BA

p3

Receive Ap1 Send Cp2

CA

p3

Send B

B

Provided Behaviour

Required Behaviour

Figure 5-4 Extra send Activity (deferred choice)

Extra “receive activity”

Having an extra “receive activity” means that this receive activity is not described by the

choreography. Hence, other parties will not send the message to be received. Not receiving a

certain message can result in a deadlock, for instance if that message is part of a sequence. If the

extra “receive activity” is part of a deferred choice then successful collaboration is not affected.

The additional branch is simply never enabled (also called dead activity). Similar to the extra

“send activity”, this part of the provided behaviour will be disabled. In case the extra “receive

activity” is part of a sequence, then an adapter could be used to create the message. For

instance, if receiving message X is an extra activity and is not part of a deferred choice, then the

following transformation rule applies.

→ X; (Generate message X)


- 48 -

This transformation rule states that the adapter is allowed to create message X. For achieving

this behaviour, the adapter will be equipped with an activity called “Send X” and an interface

place “X”. The interface of the adapter will be connected to the interface of the provided

behaviour. This means that the activity is not visible anymore to the partner behaviour. They

consider the communication between the adapter and provided behaviour as internal activities.

Hence, the extra “receive activity” becomes a silent activity and is not detected anymore as a

mismatch.

If receiving message X is a response to sending message Y, then this relation can be indicated by

using the following transformation rule.

All transformation rules that belong to the group “skipped activity” are summarized in Table 6.

Using these transformation rules an adapter for solving the corresponding mismatches can be

generated.

Table 6 Extra activity transformation rules

Activity Mismatch Rewrite rule Send X Extra Send Activity X→;

Send X Extra Send Activity (deferred choice) Disable branch Receive X Extra Receive Activity → X;

Receive X Extra Receive Activity (as response to Y) Y→ Y, X; Receive X Extra Receive Activity (deferred choice) Disable branch

5.2.3 Different Conditions

Different conditions can have multiple reasons. As is indicated in Figure 3-12 this mismatch

pattern may be caused by most other mismatches. However, when mapping this mismatch

pattern to transformation rules, we only consider the situation in which this mismatch is not

caused by other mismatches.

Different conditions for send activities

Figure 5-5 shows the situation in which an additional condition is not caused by other

mismatches. In the first model either message B or message C is sent to the other party after

receiving message A. In the second model message B and message C are both sent after

receiving message A. The tau transition is an internal transition, and therefore not considered

when analysing the two models.

Y → Y, X; (Forward message Y and generate message X)


- 49 -

Considering the first model as the provided behaviour and the second model as the required

behaviour results in the transformation rules shown below. In this case the activities send B and

send C have additional conditions compared to the equivalent activities in the required

behaviour.

These transformation rules state that the adapter is allowed to create message B and message C

depending on the message received. The adapter will contain a send activity for both messages,

including the corresponding interfaces. The controller of the adapter will make sure that the

right message is send at the right time.

Considering the first model as the required behaviour and the second model as the provided

behaviour results in different transformation rules. In this situation always both messages (B

and C) are sent by the provided behaviour to the other party. In this case the activities send B

and send C have less conditions compared to the equivalent activities in the required behaviour.

For solving this mismatch a business analyst has to choose which of the messages should be

forwarded by the adapter. The other message has to be consumed by the adapter. Assuming that

only message B should be forwarded results in the following transformation rule:

If the decision for forwarding either of the two messages is non-deterministic, then the

following transformation rule can be used:

B →; C →;

C →; (Consume message C)

B → B, C; (Forward message B and generate message C) C → C, B; (Forward message C and generate message B)


- 50 -

Receive AStartSend Bp2

CA

End

Send C

B

Receive AStart Send Bp2

A

End

B C

p4

p3tau

Send C p5

Provided Behaviour

Required Behaviour

Figure 5-5 different conditions (send activities)

Different conditions for receive activities

Figure 5-6 shows another situation in which a different condition is not caused by other

mismatches. In the first model either message B or message C needs to be received from the

other party after message A is sent. In the second model message B and message C need to be

received after sending message A. Considering the first model as the required behaviour and the

second model as the provided behaviour will result in the following transformation rules:

Also in this case, considering the first model as the provided behaviour and the second model as

the required behaviour results in different transformation rules. In this situation always both

messages (B and C) are sent by the other party. The provided behaviour, however, is only able

to consume either of the two messages. In this case, the business analyst has to choose which of

B → B, C; (Forward message B and generate message C) C → C, B; (Forward message C and generate message B)


- 51 -

the messages should be forwarded by the adapter. Assuming that message B should be

forwarded results in the following transformation rule.

Other solutions are that the adapter always forwards the first message it receives, evaluates

both messages and forwards either of them based on some predefined evaluation rules or

forwards either of the two non-deterministic.

Send AStartReceive Bp2

CA

End

Receive C

B

Send AStart Receive Bp2

A

End

B C

p4

p3tau

Receive C p5

Provided Behaviour

Required Behaviour

Figure 5-6 different conditions (receive activities) Table 7 Different conditions transformation rules

Activity Mismatch Rewrite rule Send X Send Y

Less conditions Less conditions

X →;

{ Y is selected as default}

Send X Send Y

Additional conditions Additional conditions

X → X, Y;

Y → Y, X

Receive X Receive Y

Less conditions Less conditions

X → X, Y;

Y → Y, X

Receive X Receive Y

Additional conditions Additional conditions

X →;

{ Y is selected as default}

C →; (Consume message C)


- 52 -

5.2.4 Split activity

A split activity in the provided behaviour can have two effects. First, the provided behaviour can

have a split “send activity”. This means that the provided behaviour will send multiple messages

whereas the standard requires to send the same information in one single message (Figure 3-3).

A split send activity can be solved by merging the multiple incoming messages into one outgoing

message. For instance, the provided behaviour sends messages X1 and X2. However, according to

the required behaviour only one single message of type X should be send. In this case, message

X1 and message X2 need to be merged into message X. The transformation rule for achieving this

behaviour is as follows:

This transformation rule states that the adapter is allowed to transform the messages X1 and X2

into message X. For achieving this behaviour, the adapter will be equipped with two receive

activities, namely “Receive X1” and “Receive X2”. Each activity has an interface that will be

connected to the provided behaviour. Hence, the partner behaviour will not be aware of those

activities anymore. Additionally, the adapter will have a transformation activity and an “Send X”

activity. The “Send X” activity will forward the transformed message to the partner behaviour.

This means that only the “Send X” activity will be visible for the partner behaviour. The original

send activities become silent activities and are not detected as mismatches again.

The provided behaviour can also have a split receive activity. This means that the provided

behaviour expects to receive multiple messages, whereas the standard requires to receive the

same information within one single message. A split receive activity can be solved by splitting

one incoming message into multiple outgoing messages. For instance, the provided behaviour

needs to receive message X only, whereas the required behaviour needs to receive message X1

and X2. The adapter needs to receive message X and split it into X1 and X2. The transformation

rule for achieving this behaviour is as follows. The adapter works in reverse compared to the

split “send activity”.

Before performing the difference analysis between the provided behaviour and required

behaviour, one has to indicate that a certain message from the required behaviour is split into

multiple messages in the provided behaviour. This mismatch cannot be detected automatically.

X → X1, X2; (split X into X1 and X2)

X1, X2 → X; (merge X1 and X2 into X)


- 53 -

In Table 8 it is assumed that a business analyst has indicated that message X is split into X1 and

X2.

Table 8 Split activity transformation rules

Activity Mismatch Rewrite rule Send X1 Send X2

Split send activity Split send activity

X1,X2 → X;

Receive X1 Receive X2

Split receive activity Split receive activity

X→X1, X2;

5.2.5 Refined activity

The refined activity is the opposite of the split activity. The provided behaviour can have a

refined send activity and a refined “receive activity”. If the provided behaviour sends a single

message whereas the standard requires sending multiple messages then this activity is a refined

“send activity”. A refined “send activity” can be resolved by splitting the refined message into

the required amount of messages. For instance, the provided behaviour sends message X

whereas the messages X1 and X2 are required according to the standard. The corresponding

transformation rule is:

A refined “receive activity” is similar. In this case, the provided behaviour expects to receive a

single message, whereas the standard requires receiving the same information in multiple

messages. The adapter needs to merge the two messages before forwarding them to the

provided behaviour. The corresponding transformation rule is:

Before performing the difference analysis between the provided behaviour and required

behaviour, one has to indicate that a certain message from the required behaviour is refined in

the provided behaviour. This mismatch cannot be detected automatically. In Table 9 it is

assumed that a business analyst has indicated that message X1 and X2 are refined into message

X.

Table 9 Refined activity transformation rules

Activity Mismatch Rewrite rule Send X Refined send activity X→X1, X2; Receive X1 Receive X2

Refined receive activity Refined receive activity

X1, X2→ X;

X1, X2 → X; (merge X1 and X2 into X)

X → X1, X2; (split X into X1 and X2)


- 54 -

5.2.6 Partly Corresponding

Also this mismatch requires different transformation rules depending on the activity type

involved (send or receive). Both situations are discussed in the coming section.

Partly corresponding send activity

Figure 3-5 shows an example of partly corresponding send activities. For solving this mismatch

first the incoming message has to be split into multiple outgoing messages. Thereafter,

messages that are not required have to be consumed by the adapter. For instance, the provided

behaviour sends one message of type X, but the standard requires to send message X1 and

message X2. However, message X can only be split into message X1, X2 and X3. Therefore, the

adapter needs to split X into three messages but only forward two of them. After receiving

message X, the adapter will split it into X1, X2 and X3. Then the adapter forwards X1 and X2, but

hides X3. The transformation rules to achieve this behaviour are as shown below.

By using these transformation rules the adapter will intercept the message X and transform it

into the message X1, X2 and X3. The adapter will have an interface to the partner behaviour for all

three messages. The interface for message X is marked as an internal activity since the partner

behaviour is not aware of it. Hence, the partly corresponding mismatch will be resolved by using

the adapter.

Partly corresponding receive activity

In case the mismatch involves receive activities, then the adapter should work in the reverse.

For instance, the provided behaviour receives one message of type X, but the standard requires

receiving message X1 and message X2. In this case the adapter needs to generate message X3 and

then merge it with X1 and X2 into message X. The transformation rules for achieving this

behaviour are:

By using these transformation rules the adapter will intercept the messages X1, X2 and X3 and

transform them into message X. Only message X will have an interface to the partner behaviour.

→ X3; (create X3)

X1, X2, X3 → X; (merge X1, X2 & X3 into X)

X → X1, X2, X3; (split X into X1, X2 & X3)

X3 →; (consume X3)


- 55 -

All other activities are marked as internal activities since the partner behaviour is not aware of

them. Hence, the partly corresponding mismatch will be resolved by using the adapter.

Table 10 Partly corresponding example

Activity Mismatch Rewrite rules Send X Partly corresponding send activity X→X1, X2 , X3;

X3→; Receive X Partly corresponding receive activity →X3;

X1, X2, X3→ X;

5.2.7 Iterative versus once of

When generating adapters for dealing with iterations it is very important to consider

synchronisation issues that might occur. For instance, if one party sends a certain message

multiple times to the other party, the other party needs to know when it has received all

messages and can continue with the process. Therefore, it is necessary to include a stop

condition into the iteration. Issues of web services involving multi message request-reply

conversations are thoroughly discussed in literature, see for instance (Mulyar, van der Aalst,

Aldred, & Russell, 2007), (Barros A., Dumas M & Hofstede A. ter., 2005) and (Barros A, Decker G.,

Dumas M., Weber F., 2007).

Message synchronisation or message correlation is out of the scope of this research. Moreover,

it is not our intention to improve current solutions or to present all possible existing solutions

to this problem. In this research it is assumed that in case of iteration synchronisation-messages

are always exchanged as well. For each iteration at least two synchronisation messages are

required. One for each message sent within the iteration and one for indicating the end of the

iteration.

Other possible solutions include property based synchronisation and time-interval based

synchronisation. In property based synchronisation the other party keeps accepting messages

until a certain property evaluates to true. This property can be a certain amount of messages, a

certain type of message or even a message containing specific content. The latter approach,

called time-interval based synchronisation, uses a time interval as a stop condition. The other

party accepts messages until a certain amount of time has expired. This approach does not

guarantee that all messages sent are received as well. The available time for receiving messages

could be expired before all messages are actually received.


- 56 -

Since in this research it is assumed that iteration requires the exchange of a synchronisation

message, always at least two activities are involved in the mismatch, one send activity and one

receive activity. Two factors are important when generating transformation rules for a

mismatch involving iteration. First, it is necessary to distinguish between the origin of the

mismatch. The mismatch can be caused by iteration in the provided behaviour, but also by

iteration in the required behaviour. Second, the activity type (send or receive) at the starting

point of the iteration is important when generating the transformation rules. Below the four

possible cases are discussed. It has to be noted that iteration also implies an additional-

dependency mismatch. In point of fact, the first activity in the iteration has the last activity of

the iteration as dependency, whereas this is not the case in the behaviour without iteration.

Since the additional dependency is caused by the iteration, it is neglected when creating the

SEA.

Iterative send & receive activity

If the provided behaviour sends multiple messages of the same type, whereas the required

behaviour is only able to send one message, then there is an iterative send mismatch. Due to

synchronisation issues, the provided behaviour requires to receive a response from the other

party for each message sent within the iteration. Hence, this mismatch also has an iterative

receive activity. If the send activity is the start of the iteration, then this mismatch is called

“iterative send & receive activity”.The provided behaviour also has to send a synchronisation

message to the other party for indicating the end of the iteration. Since the required behaviour

does not contain iteration it will most likely not provide this synchronisation message.

Therefore, in most cases this mismatch is accompanied by another mismatch; the extra “send

activity”. The transformation rules for this mismatch are generated using the mapping

described in Table 6.

Figure 5-7 shows an example of the mismatch. Both the provided behaviour and the required

behaviour start with sending message X. However, the provided behaviour is able to send

additional messages of type X. The required behaviour, on the other hand, ends the process after

sending the first message X. As can be seen in Figure 5-7, for each additional message X, the

provided behaviour waits for receiving synchronisation message Sx. For indicating the end of

iteration message Se is sent.


- 57 -

Send XStart Send Xp1

X SxX Se

p2

Receive Sx

Send Se End

Send XStartEnd

X

Provided Behaviour

Required Behaviour

Figure 5-7 iterative send & receive activity

Two possible solutions exist for this version of the iteration mismatch. Depending on the

situation either of the two solutions can be applied. In the first solution the adapter only

forwards the first message sent by the provided behaviour and consumes all other messages.

Furthermore, for each additional message sent, the adapter will generate a synchronisation

message and send it back to the provided behaviour. Assuming that message X is the send

message with iteration, the transformation rules for the first solution are as follows. Note that

the missing synchronisation messages are not included below. The corresponding

transformation rule will be generated using the mapping for extra activities.

The second solution uses the collapse operator described by (Dumas, Spork & Wang, 2006). The

adapter will receive all messages of the same type, merge them and then forward the merged

message. The adapter will forward the merged message after the adapter receives the

synchronisation message of the provided behaviour. Also in this case, the adapter will generate

a synchronisation message for every message sent within the iteration and send this to the

X → X; {Forward the first message}

X →; {Consume all other messages of type X}


- 58 -

provided behaviour. In case the second solution is applied other transformation rules need to be

generated. Unfortunately, the current set of transformation rules proposed by Gierds, Mooij &

Wolf (2008) do not allow for specifying this behaviour. Therefore, we propose new

transformation rules for this scenario.

The first rule indicates that the first message received by the adapter should be stored in a

buffer message. The second rule indicates that each subsequent message Xi (1<i<∞) should be

merged with the current buffer message B. The last rule indicates that after receiving the

synchronisation message the merged buffer message should be forwarded as message X to the

other party.

Once-off send & receive activity

This mismatch is the inverse of the iterative send & receive activity. In this case, the provided

behaviour sends a certain message once whereas in the required behaviour it is possible to send

the message multiple times. This mismatch can have two reasons.

First, the required behaviour simply allows for sending multiple messages of the same type. In

this case the provided behaviour always performs the iteration just once and no adapter is

needed for solving the iteration. Second, the one message send by the provided behaviour

corresponds to multiple messages covered by the iteration of the required behaviour. In this

case, the mismatch is similar to the refined send activity and the transformation rules of Table 9

could be applied. In case the message has to be split, a business analyst has to indicate the

quantity of messages the original message should be split into. If the quantity is dynamic, i.e. it

differs for each specific case, then this mismatch cannot be solved using our approach.

Moreover, the difference analysis cannot distinguish between the two causes of the mismatch.

Therefore, a business analyst is required to indicate the cause manually.

Figure 5-8 shows an example of this version of the iterative versus once-off mismatch. The

provided behaviour only sends message X once, whereas the required behaviour is able to send

message X multiple times. Note that both synchronisation messages are skipped activities.

X1 → B; (Store the first message X1 in a temporary buffer message)

Xi, B → B; (Merge all subsequent messages to the buffer message)

S, B→ X; (Transform the buffer message B into X when receiving the synchronisation

message S)


- 59 -

Therefore the corresponding transformation rules will be generated using the mapping

described in Table 5.

Send XStart Send Xp1

X SxX Se

p2

Receive Sx

Send Se End

Send XStartEnd

X

Provider Behaviour

Required Behaviour

Figure 5-8 Once-off send & receive activity

Iterative receive & send activity

This mismatch describes a situation in which the provided behaviour is able to receive multiple

messages of the same type, whereas according to the required behaviour only one message

should be received. This implies that also just one message should be send by the counter party

according to the required behaviour. Similar to the once-off send & receive activity, this

mismatch may have two reasons.

First, the provided behaviour simply allows for receiving multiple message of the same type. In

this case, the mismatch does not have direct consequences on the interoperability between the

two parties. However, implicitly this mismatch probably causes interoperability since

synchronisation messages will not be sent in the required behaviour, although expected in the

provided behaviour. These extra synchronisation messages in the provided behaviour will be

detected as “extra “send activity”” and be dealt with accordingly. Second, the one message send

by the counter party may be split into multiple messages and then forwarded to the provided


- 60 -

behaviour. In this case the mismatch is similar to the split send activity and the transformation

rules of Table 8 apply. Also, the mismatch cannot be solved if the quantity is dynamic.

Figure 5-9 shows an example of the mismatch. Both the provided behaviour and the required

behaviour start with receiving message X. However, the provided behaviour is able to process

additional messages of type X. The required behaviour, on the other hand, ends the process after

sending the first message X. As can be seen in the figure, for each additional message X, the

provided behaviour responds by sending a synchronisation message Sx. For indicating the end

of iteration message Se is sent. The two synchronisation messages are resolved by using the

transformation rules for extra activities.

Receive XStart Receive Xp1

X SxX Se

p2

Send Sx

Receive Se End

Send XStartEnd

X

Provider Behaviour

Required Behaviour

Figure 5-9 Iterative receive & send activity

Once-off receive & send activity

This mismatch refers to the situation in which the provided behaviour is only able to receive a

certain message once, whereas the required behaviour is able to receive that same message

multiple times. This means that the other party will be able to send multiple messages.


- 61 -

Resolving this mismatch is similar to resolving an iterative send & receive activity. First, the

adapter could forward the first message sent by the other party and consume all subsequent

messages. Second, the adapter could merge all messages into a single message and pass this

merged message on to the provided behaviour. Assuming that message X is the receive message

with iteration, the transformation rules for the first solution are as follows.

Since this situation is similar to the iterative send activity, there is no existing transformation

rule for merging an unbound amount of messages into a single message. The same

transformation rules as introduced for the iterative send activity can be used.

Figure 5-10 shows an example of this version of the iterative versus once-off mismatch. The

provided behaviour is only able to receive message X once, whereas the required behaviour is

able to receive message X multiple times. For each additional message the required behaviour

waits for receiving a synchronisation message Sx. Note that the synchronisation message for

indicating the end of the iteration is a skipped activity and not part of the iteration mismatch

itself. The corresponding transformation rules for the skipped activity will be generated using

the mapping described in Table 5.

X1 → B; (Store the first message X1 in a temporary buffer message)

Xi, B → B; (Merge all subsequent messages to the buffer message)

S, B→ X; (Transform the buffer message B into X when receiving the synchronisation

message S)

X → X; (Forward the first message)

X→ ; (Consume all other messages of type X)


- 62 -

Receive XStart Receive Xp1

X SxX Se

p2

Send Sx

Receive Se End

Receive XStartEnd

X

Provided Behaviour

Required Behaviour

Figure 5-10 Once-off receive & send activity Table 11 iterative vs. once of transformation rules

Activity Mismatch Rewrite rule Send X iterative send activity X → X;

X→; Send X Once-off send activity (deferred

choice) None

Send X Once-off send activity →X; Receive X

Once-off receive activity

X → X; X→;

Receive X iterative receive activity →X; Receive X iterative receive activity

(deferred choice) None


- 63 -

5.3 Discussion

Gierds, Mooij & Wolf (2008) extended the tool Fiona (Lohmann, Massuthe Stahl and Weinberg,

2008) with the technique they developed for generating adapters. When creating an adapter

Fiona only checks whether the composed net is deadlock free. Hence, weak termination is not

guaranteed by using Fiona only. However, other tools such as WOMBAT4WS (Martens & Moser,

2006) provide efficient implementations for checking whether the composed net weakly

terminates.

A limitation of using the approach of Gierds, Mooij & Wolf (2008) is that we can only guarantee

successful collaboration with parties that implement the behaviour as described in the

choreography. This limitation is a consequence of using the partner behaviour for creating the

adapter. Moreover, mismatches cannot be solved if no partner behaviour is available.

The technique of Gierds, Mooij & Wolf (2008) relies on an asynchronous model of message

passing while the technique for detecting mismatches relies on models describing business

processes. Due to differences between the two models some of the detected mismatches cannot

be solved. See for example the scenario in Figure 5-11. The provided behaviour first sends

message A before sending message B. The required behaviour on the other hand, first sends

message B and then message A. This difference is detected as a mismatch when using the

technique of Dijkman (2008). However, due to the asynchronous property, Fiona does not

consider this situation as a problem. Hence, the adapter generated by Fiona does simply

forward both messages and the mismatch remains also after an adapter is created. Since this

mismatch does not affect successful collaboration, we consider this situation only as a minor

drawback of our approach. Nevertheless, we think it is useful to detect this mismatch and

provide feedback to a business analyst.

Figure 5-11


- 64 -

The technique for detecting mismatches is based on the notion of completed trace equivalence.

Hence, mismatches that only occur when using stronger notions of equivalence cannot be

detected. Typically, these are differences with respect to the branching time. If such difference

exists, among others, between the provided behaviour and the required behaviour then Fiona

might considers the provided behaviour and partner behaviour as uncontrollable and cannot

generate an adapter. Detecting differences with respect to branching time is considered as

future work.

Validation and Complete Example

- 65 -

6 Validation and Complete Example

In this chapter the techniques for detecting and resolving mismatches are validated. The goal of

this validation is to show that (1) we are able to detect mismatches described in section 3 by

using the approach of section 4, (2) we are able to map the mismatches to a set of

transformation rules by using the approach of section 5.2, (3) we are able to create an adapter

for solving the mismatches by using the approach of section 5.1. By using the approach of

section again 4 we show that the mismatches are indeed solved. Furthermore, we present a

complete example of our approach for detecting and resolving mismatches.

For validating our approach, seven different versions of order-management choreographies

from xCBL (xCBL, 2003) are used as required behaviour, but also as provided behaviour. xCBL is

the result of collaboration between Commerce One® and other XML standards bodies, e-

commerce enterprises, and hardware and software vendors including, Microsoft, SAPMarkets,

and Sun Microsystems (xCBL, 2008). Besides document definitions for e-commerce

applications, xCBL also provides possible order-management choreographies that could be

implemented between two trading partners. All choreographies are described in Appendix A in

Petri Net notation and in natural language.

During the validation process multiple choreography pairs are selected from the entire set

described by xCBL. For each pair, the process selected first is treated as provided behaviour and

the second as required behaviour. Both processes are also treated the other way around, the

first process as required behaviour and the second as provided behaviour. In total ten pairs of

provided behaviour and required behaviour are used in the validation process. The approach is

described in detail and elucidated with a running example in section 6.1. The overall test results

are presented in section 6.2., and conclusions are drawn in section 6.3.

6.1 Approach

The validation process consists of five main steps. First, suitable test models for provided

behaviour and required behaviour are obtained from the textual description. Second, mismatch

patterns are detected between the provided behaviour and the required behaviour by using the

approach of section 4. Third, using the mapping described in section 5.1 the corresponding SEA

is created. Fourth, the SEA is used as input for generating adapters using the technique

developed by Gierds, Mooij & Wolf (2008). Finally, the approach of section 4 is used again to


- 66 -

test whether mismatch patterns are still detected between the required behaviour and the

provided behaviour including the adapter. Figure 6-1 shows a graphical overview of step two,

three and four. Figure 6-2 shows a graphical overview of step five.

Choreography

Difference

Analysis (2)

Adapter

Generation (4)

Required (Partner) Behaviour

Required BehaviourProvided Behaviour

Mismatches(3)

SEA

Adapter

Figure 6-1 Validation approach: Difference analysis & adapter generation

Choreography

Required (Partner) Behaviour

Required BehaviourProvided Behaviour

Adapter

Difference

Analysis (5)

Figure 6-2 Validation approach: Difference analysis between adapter & required behaviour

6.1.1 Step 1: Obtaining models for validation

xCBL describes the choreographies in natural language rather than in a formal language. For

detecting mismatch patterns the choreographies are translated to the Petri Net notation.

However, translating the textual description to the Petri Net notation is not straightforward as

the textual descriptions may be ambiguous. For instance, the xCBL descriptions state that an

order may be cancelled as long as the order is active. However, they do not provide a clear


- 67 -

definition of an active order. They state that trading partners may use their own definitions of

an active order.

Another problem of the textual description is the so called non-local choice problem. The

choreography describes a global decision within the process, namely ending the process or

cancelling the order. However, in the implementation this leads to two local decisions that can

be made independently by the two communicating parties, the supplier and the buyer.

Performing the tau transition corresponds to ending the process. The tau transition is required

due to the limitation of one end place per web service. For instance, in Figure 6-3 the following

non-local choice problem occurs. The process starts after the buyer sent an order request to the

supplier. When receiving the order request the supplier responds with an order response

message. Now the buyer can either end the process, or decide to cancel the order. If he decides

to send the cancel request he waits for receiving a cancel response. A deadlock occurs if the

supplier would have ended the process while the buyer sent a cancel request. The buyer would

wait for receiving a cancel response, but never receive it. Therefore, successful collaboration

cannot be guaranteed.

StartReceive Order

RequestSend

Order Response

P3

P1

Start Send

Order RequestReceive

Order Response

Send

Cancel RequestP3

P1P2

Supplier

Buyer

Order Request

End

End

Receive

Cancel Request

Send

Cancel Response

Receive

Cancel Response

tau

tauP2

Cancel RequestCancel

ResponseOrder

Response

Figure 6-3 Deadlock scenario non-local choice

A survey about none local choice is done by Mooij and Goga (2005). They state that the

following three main views of non-local choice exist in literature:


- 68 -

Faulty description: redefine the description without non-local choice.

Implicit synchronization: non-local choice nodes implicitly specify additional

synchronization. Hence, additional synchronisation messages are required to obtain an

implementation.

Implied behaviour: non-local choice nodes contain behaviour that must be added in any

implementation that contains at least the intended behaviours. This additional

behaviour must be revealed and included.

While translating the textual choreography description to Petri Nets, it is assumed that non-

local choice nodes implicitly specify additional synchronisation. Other solutions for the non-

local choice problem exist as well. However, dealing with non-local choice issues in

choreography descriptions is out of the scope of this research. For more detailed material

discussing the non-local choice problem we refer to Ben-Abdallah and Leue (1997) and Mooij,

Goga and Romijn (2005). Applying the solution of implicit synchronisation to the example in

Figure 6-3 would mean that a synchronisation message should be exchanged for ending the

process. This will ensure that both parties cannot make different local branching decisions and,

thus, can collaborate successfully. Figure 6-4 shows the same choreography including

synchronisation messages. Now, the combined behaviour is deadlock free as well, due to the

synchronisation message sent before ending the process.


- 69 -

StartReceive Order

RequestSend

Order Response

P3

P1

Start Send


Order Response

Send

Cancel RequestP3

P1P2

Buyer

Order Request

End

End

Receive

Cancel Request

Send

Cancel Response

Receive

Cancel Response

Send Sync

Receive SyncP2

Cancel Request Cancel ResponseOrder Response Sync

Supplier

Figure 6-4 implicit synchronisation

In what follows choreography 3.2 and choreography 2.2 (see Appendix A) are used as running

example to elucidate the validation process. In the running example choreography 3.2 is treated

as the required behaviour and choreography 2.2 is treated as provided behaviour. This means

that the behaviour of the supplier and the buyer from choreography 3.2 is considered as the

standard that other parties have to implement. In the running example we are about to show, it

is assumed that a new supplier wants to participate in the value chain. Therefore, the behaviour

of the supplier of choreography 3.2 is used for the differences analysis.

Figure 6-5 shows the required behaviour of the supplier of choreography 3.2. The supplier waits

until he receives an order request from a buyer. After receiving the order request, the supplier

sends an order response back to the buyer. Then the supplier waits for receiving a

synchronisation message for ending the process or for a cancel request. If a cancel request is

sent by the buyer, then the supplier replies with an order response message.


- 70 -

StartReceive Order

RequestSend

Order Response

P3

P1

Order Request

End

Receive

Cancel Request

Send

Cancel Response

Receive SyncP2


Figure 6-5 required behaviour of the supplier

Choreography 2.2 is considered as the provided behaviour in the running example. This means

that the behaviour of the supplier in choreography 2.2 is considered as the new party that wants

to participate in the value chain. This new supplier (Figure 6-6) is only able to receive an order

request and to respond by sending an order response message. The behaviour shown in Figure

6-6 is used as second model for the differences analysis.

StartReceive Order

RequestSend

Order ResponseP1

Order Request

End

Order Response

Figure 6-6 behaviour of the new supplier (provided behaviour)

When comparing Figure 6-5 and Figure 6-6, one can notice that the required behaviour is

slightly more complex than the provided behaviour. This is due to the fact that the required

behaviour allows for cancelling an order, whereas this is not possible in the provided behaviour.

6.1.2 Step 2: Detecting mismatches

The approach of section 4 is used for detecting mismatches between the provided behaviour

and the required behaviour. As discussed in section 3.4 all interface places are removed from

both models in Figure 6-5 and Figure 6-6 before testing for differences. Three mismatches are


- 71 -

detected during the differences analysis of the running example. All three mismatches belong to

the group “skipped activity”.

Skipped Receive Activity: “Receive Cancel Request” Skipped Receive Activity: “Receive Sync” Skipped Send Activity: “Send Cancel Response”

The first two mismatches are of the type Skipped Receive Activity. These mismatches indicate

that the provided behaviour is not able to receive a certain message. In the running example the

provided behaviour is not able to receive a cancel request or a Sync message from the other

party. The third mismatch is a skipped “send activity”. This mismatch indicates that the

provided behaviour is not able to send a certain message that the other party might expect to

receive. When comparing the required behaviour (Figure 6-5) and the provided behaviour

(Figure 6-6) one can notice that the provided behaviour indeed is not able to receive a cancel

request and sync message, and is also not able to send a cancel response.

As the mismatches already indicate, the new supplier is not able to collaborate successfully with

a partner from the choreography. The provided behaviour is not able to receive messages that

potential buyers are likely to send. The mismatches found are used in step three for generating

the SEA.

6.1.3 Step 3: Generating the SEA

In the third step the SEA is created. The SEA is generated according to the mapping described in

section 5.2. All three mismatches in the running example belong to the group “skipped

activities”. The transformation rules for this group are shown in Table 5 of section 5.2.1. The

first mismatch detected is the skipped “receive activity” “Receive Cancel Request”. Two possible

mappings exist for a skipped “receive activity”. Since the provided behaviour ends the process

after sending the order response, no default path needs to be selected. Therefore the mapping of

row three in Table 5 is applied for this mismatch, resulting in the following transformation rule:

The second mismatch detected is the skipped “receive activity” “Receive Sync”. The same

reasoning as for the first mismatch applies, resulting in the following transformation rule:

Sync →;

Cancel Request →;


- 72 -

The third mismatch is the skipped “send activity” “Send Cancel Response”. This mismatch has

three possible transformation rules. In this case the mapping of row five in Table 5 applies, since

the skipped “send activity” is a response to a skipped “receive activity”. Therefore the

transformation rules of both mismatches are merged to the following transformation rule:

By combining the transformation rules the following SEA is created. This SEA is used in step

four for generating the adapter.

6.1.4 Step 4: Generating the adapter

In the fourth step, the adapter for solving the mismatches is generated. Gierds, Mooij & Wolf

(2008) extended the tool Fiona (Lohmann, Massuthe Stahl and Weinberg, 2008) with the

technique they developed for generating adapters. Fiona requires three input files for

generating an adapter; the provided behaviour, the partner behaviour and a specification of

elementary activities (SEA). The provided behaviour and the SEA are obtained from the second

and third step respectively. The partner behaviour (the buyer in this case) is obtained from the

choreography. Figure 6-7 shows the partner behaviour used in the running example. This

partner behaviour is derived from the upper part of choreography 3.2 (see Appendix A). The

buyer initiates the process by sending an order request. Hereafter he waits for receiving an

order response. After receiving the order response message the buyer can decide to either end

the process or to cancel the order. If the buyer decided to send a cancel request, he then waits

for the cancel response of the supplier. The buyer sends a synchronisation message when he

decides to end the process.

Cancel Request → Cancel Response;

Sync →;

Cancel Request → Cancel Response;


- 73 -

Start Send


Order Response

Send

Cancel RequestP3

P1P2

Order Request

End

Receive

Cancel Response

Send Sync


Figure 6-7 Partner behaviour (Choreography 3.2)

Figure 6-8 shows the generated adapter when using Figure 6-6 and Figure 6-7 as input models

in combination with the SEA generated in step three. As can be seen, the order request message

from the buyer is received by the adapter and passed on to the supplier. The order response

message from the supplier is also received by the adapter and passed on to the buyer. The

cancel request message is transformed into a cancel response message and sent back to the

buyer. The adapter does not pass the cancel request message on to the supplier, since he is not

able to receive this message. When the buyer sends the Sync message then this message is also

eaten by the adapter. The adapter can be simplified by applying Petri Net reduction rules.

This running example is a good example for showing that adapters can actually generate

message containing data. The provided behaviour does not contain any option for cancelling an

order. This either means that cancelation has to be done via some other means of

communication (phone, e-mail, etc.) or that the provided behaviour does not allow for

cancelling at all. If the latter is the case, then the generated cancel response could always

contain a rejection message. Otherwise, the cancel response could contain a message in the sort

of “We are not able to process your cancellation, please contact us via ...”.


- 74 -

Figure 6-8 Running example: generated adapter

Step 5: Testing for mismatches again

In the fifth step the adapter is connected to the provided behaviour and compared with the

required behaviour again. The adapter is connected by performing the following three steps:

1. Merge interface places of the provided behaviour with the corresponding interface

places of the adapter.

2. Mark the merged interface places as normal places

3. Mark all transitions that are not directly connected to interface places as silent.

Figure 6-9 shows the model of the provided behaviour of Figure 6-6 connected to the adapter

presented in Figure 6-8. All activities, except the five activities connected to interfaces to the

buyer, are marked as silent. Activities that are not connected to an interface place are marked as

silent since they cannot be observed by the partner behaviour (van der Aalst & Basten, 2002).


- 75 -

Figure 6-9 Provided behaviour + adapter

The following three mismatches are still detected after performing the differences analysis with

the required behaviour (Figure 6-5) and the provided behaviour + adapter (Figure 6-9) as input:

Additional dependencies: “Receive Cancel Request” from required behaviour has

additional dependencies on “Send Order Response”.

Additional dependencies: “Receive Sync” from required behaviour has additional

dependencies on “Send Order Response”.

Different conditions: “Send Cancel Response” from provided behaviour has additional

conditions characterized by “Receive Cancel Request”.

As can be seen all three mismatches of the group “skipped activity” are resolved by the adapter.

Nonetheless, three new mismatches have been introduced. The first mismatch states that the

receive cancel request activity from the required behaviour has an additional dependency on

“send order response”. This additional dependency is caused by the send order response

message. This mismatch is detected since the generated activity “receive cancel request” from

the adapter does not have “send order response” as input dependency. This mismatch cannot be

solved using the current possibilities for adapter generation. No transformation rule exist for

defining requirements, such as dependencies, for receiving messages. The second mismatch is

also of the group “additional dependencies”. The same reasoning as for the first mismatch holds

for this mismatch.

The third mismatch belongs to the group “different conditions”. This mismatch is strongly

related to the first two mismatches. To clarify this mismatch, please recall that the difference


- 76 -

analysis, performed in step two, detected two skipped receive-activities. In the required

behaviour those two skipped receive-activities were part of a deferred choice. With the current

transformation rules it is not possible to specify this behaviour when generating an adapter. The

adapter generates two independent activities for each skipped activity. Hence, resolving two

skipped activities that are part of deferred choice, always introduces a different-condition

mismatch.

The three mismatches described above do not restrict the provided behaviour with

functionality. The provided behaviour is able to send and receive all messages as required by

the choreography. Moreover, the fact that an adapter can be generated shows us that the

composition of the provided behaviour, adapter and partner behaviour is deadlock free (Gierds,

Mooij & Wolf, 2008). Without the SEA created in step three it is not possible to create an

adapter. Hence, successful collaboration was not guaranteed without adapter.

6.2 Results

Appendix A shows the source choreographies from xCBL used for the validation process. All

choreographies describe order management business processes and consist of two parties, a

buyer and a supplier. The numbers assigned to the choreographies correspond to the

paragraphs of the source document (xCBL, 2003). They mainly differ with respect to the

behaviour they allow. The first number of the choreography also gives an indication of the

complexity of the communication process. Choreographies starting with a two, exchange at

most two messages and do not contain deferred choices or iteration. Choreographies starting

with a five, on the other hand, exchange up to seven times as many messages and include

deferred choices and iterations. In all test cases the view of the supplier is used. That is to say, it

is assumed that a new supplier is planning to participate in the value chain described by the

choreography. Nevertheless, the same approach could be applied to the behaviour of the buyer.

Ten choreography pairs, presented in Table 12, were selected for the validation process. Four

choreography pairs with low complexity and six choreography pairs with higher complexity

were selected. Because of the scope of this research (comparing web services that are similar)

we did not select choreographies with very low complexity (starting with a two) together with

choreographies with very high complexity (starting with a five). Although detecting mismatches

between them is possible, trying to solve those mismatches with an adapter would not always

make sense. Choreographies starting with a five exchange up to seven times as many messages


- 77 -

as choreographies starting with a two. Finding an appropriate threshold for the decision

whether to use an adapter for solving the mismatches or to create an entire new model is future

work.

Table 12 - Selected choreography pairs

Test case Provided behaviour Required behaviour #1 2.2 2.1 #2 2.1 2.2 #3 2.3 2.2 #4 2.2 2.3 #5 2.2 3.2 #6 3.2 2.2 #7 4.1 4.3 #8 4.3 4.1 #9 5.1 3.2

#10 3.2 5.1

Table 13 shows the overall results of the validation process. The table consists of four columns.

The first column gives a description of the measured entity. The second column, called W/A,

indicates the number of mismatches detected without adapter. The third column, called A,

indicates the number of mismatches detected with adapter. The fourth column, called N/M,

indicates the number of mismatches that could not be mapped to transformation rules. The

table is elaborated on in section 6.3. Appendix B gives an overview of all test results of the

validation process. For each test case the mismatches detected without adapter are indicated,

the generated SEA is provided and the mismatches detected with the adapter are given.

Table 13 overall result validation

Description W/A A N/M Total number of pairs “provided behaviour” and “required behaviour” for which at least one mismatch could be detected.

10 5 2

Total number of pairs “provided behaviour” and “partner behaviour” without deadlock and with weak termination.

1 8 2

Skipped Activity 8 0 0 Extra Activity 8 0 0 Split Activity 0 0 0 Refined Activity 0 0 0 Additional dependencies 5 7 3 Different Conditions 0 2 0 Partly corresponding 0 0 0 Different moment 0 0 0 Iteration versus once-off 4 0 0 Total number of mismatches 25 9 3 Total number of mismatches introduced by the adapter - 9 -


- 78 -

6.3 Discussion

In Table 13 is shown that twenty-two out of twenty-five mismatches could be mapped to

transformation rules. In two test cases three mismatches were encountered of the group

“additional dependencies” that are not covered by any of the mappings described in 5.2. Hence,

we were not able to generate an adapter for solving these mismatches.

All twenty-two mismatches could be resolved using an adapter. Nonetheless, the adapter

introduced nine new mismatches. Seven belong to the group “additional dependencies” and two

to the group “different conditions”. Rewrite rules cannot specify dependencies between

activities, and therefore cause the nine new mismatches.

In five out of ten test cases all mismatches were resolved using an adapter. In three other test

cases, although mismatches were still detected, successful collaboration with the partner

behaviour could be established. Without the adapters the three web services contained a

deadlock when composed with the required partner behaviour. Since the adapter is generated

using the partner behaviour of the choreography, deadlock freeness can only be guaranteed

with buyers in the value chain that implement exactly the behaviour described by the

choreography. However, some buyers may also use adapters when collaborating with suppliers.

Hence, using the partner behaviour for solving the mismatches is a limitation of our approach.

To conclude: in eighty percent of the test cases we were able to generate an adapter. In almost

sixty-five percent of those cases the adapter solved all mismatches detected. In the other thirty-

five percent new mismatches were introduced, yet weak termination could be guaranteed by

the adapter. It has to be noted that we were not able to test some of the mismatch patterns,

since they were not present in any of the ten test cases.

Conclusion and Future Work

- 79 -

7 Conclusion and Future Work

In what follows a conclusion will be given in which the main findings of this thesis are

summarized. This concluding chapter is divided into two sections. The first section provides an

answer to the research questions formulated in section 1.3, the second section discusses the

anticipated contributions and provides suggestions for future work.

7.1 Main Conclusion

Existing literature only focuses on partial solutions for detecting and resolving mismatches,

such as describing possible adapters, generating adapters, describing mismatch patterns

etcetera. Furthermore, most approaches for detecting mismatches only provide limited

feedback (yes/no answers or answers in percentages). Only very recent work provides more

sophisticated techniques for detecting and indicating mismatch patterns. However, these

techniques are tailored to business processes rather than web services. Business processes do

not distinguish between send and receive activities. This distinction is important for solving the

mismatches. In this thesis we distinguish ourselves by providing an approach that covers the

complete process of detecting and resolving mismatches in the context of web services.

We developed a technique for detecting and resolving mismatches between provided behaviour

and required behaviour. Our approach extended existing techniques for detecting mismatch

patterns in the context of business processes. For solving the mismatches we defined a mapping

from mismatch patterns to transformation rules. Subsequently, this mapping is used for

generating adapters that solve the mismatches. Our approach is supported by tools for detecting

the mismatches (ProM) and generating the adapter (Fiona). We aim to integrate the mapping,

described in section 5.2, into ProM as well.

We validated our approach by comparing ten pairs of provided behaviour with its

corresponding choreography. In total twenty-two mismatches were detected. In eighty percent

of the test cases we were able to generate an adapter. In almost sixty-five percent all

mismatches could be solved. In the other thirty-five percent new mismatches were introduced,

yet weak termination between the provided behaviour and the partner behaviour could be

achieved. In two test cases we were not able to solve the mismatches.

Conclusion and Future Work

- 80 -

7.2 Discussion and Future Work

The approach for detecting and resolving mismatches described in thesis has some limitations.

By focussing on these limitations, the approach could be further improved. Therefore, we

suggest the following topics for further research.

The main limitation of our approach is that the partner behaviour is required for generating the

adapter. In the context of our research this is not an issue since the partner behaviour is also

described in the choreography. In practice there may be some situations in which the partner

behaviour is not accessible. Furthermore, we are only able to guarantee that the adapter can

successfully collaborate with that specific partner behaviour. In case the partner behaviour also

uses an adapter, interoperability may be affected. Therefore, we propose to research the

possibilities to generate adapters purely on the provided behaviour and required behaviour.

A second limitation of our research is that we have not proven that our set of mismatch patterns

is exhaustive. Hence, we cannot guarantee that two processes conform to each other in case no

mismatches are found. Moreover, we know that mismatches with respect to branching time

cannot be detected. However, by using the partner behaviour when creating the adapter, we are

able to check whether weak termination is possible. Detecting differences with respect to

branching time is considered as future work.

A third limitation is that in three cases the adapter solved the detected mismatches, but also

created new ones. The new mismatches are introduced since the adapter generation technique

assumes asynchronous communication, whereas the detection technique is based on completed

trace equivalence. Despites these mismatches, weak termination could be achieved.

A fourth limitation is that our approach for solving mismatches could not be validated for all

mismatch patterns since some of them did not appear in any of the ten test models. Moreover,

the preference was to use provided behaviour and required behaviour from a real life case.

However, no provided behaviour describing an order-management process in practice could be

obtained. In future research web services from practice should be obtained for a case study with

a larger amount of models. While performing the case study with a larger amount of models,

Future research should also try to find an appropriate threshold for the decision whether to

create an adapter or to create an entire new web service.

Appendix

- 81 -

References

Aalst W.M.P. van der & Basten T.,(2002), Inheritance of workflows: an approach to tackling problems related to change, Theoretical Computer Science,270,1--2", 125--203.

Aalst, W.M.P. van der, Dumas M., Ouyang C., Rozinat A. Verbeek, H.M.W. (2006). Choreography

conformance checking : an approach based of BPEL and Petri Nets In F. Leymann, W. Reisig, S.R. Thatte, W.M.P. van der Aalst, Dagstuhl Seminar Proceedings (The Role of Business Processes in Service Oriented Architectures, Vol. 6291). Dagstuhl: Internationales Begegnungs- und Forschungszentrum für Informatik.

Aalst W.M.P. van der, Alves de Medeiros A.K.,.Weijters A.J.M.M. (2006), Process Equivalence in

the Context of Genetic Mining, BPM Centre Report BPM-06-15, BPMcenter.org, 2006. Alves de Medeiros A.K., Aalst W.M.P. van der and Weijters A.J.M.M., (2008). Quantifying process

equivalence based on observed behavior Data & Knowledge Engineering, 64(1): 55-74, 2008. © Elsevier B.V.

Alves A. et al. Web Services Business Process Execution Language Version 2.0. OASIS Standard,

11 April 2007, OASIS, April 2007. Barros A, Decker G., Dumas M., Weber F. (2007): Correlation Patterns in Service-Oriented

Architectures. FASE 2007: 245-259 Barros A., Dumas M & Hofstede A.H.M. ter. (2005). Service Interaction Patterns, In Proceedings

of the 3rd International Conference on Business Process Management, Nancy, France, Springer Verlag, pp. 302-318.

Ben-Abdallah H. and Leue S. (1997). Syntactic detection of process divergence and nonlocal

choice in Message Sequence Charts. In Tools and Algorithms for the Construction and Analysis of Systems, number 1217 in LNCS, pages 259-274.

Benatallah B., Casati F., Grigori D., Motahari Nezhad H. R., Toumani.F (2005). Developing

Adapters for Web Services Integration. In Proceedings of the 17th International Conference on Advanced Information System Engineering, CAiSE 2005, Porto, Portugal, pages 415–429. Springer

Benatallah B, Casati F, Toumani F (2006), Representing, analysing and managing web service

protocols, Data & Knowledge Engineering, v.58 n.3, p.327-357 Bordeaux L., Sala G., Berardi D., Mecella M. (2004), When are two web services compatible, TES-

2004, 15-28, Berlin. Brogi A., Popescu R. (2007). Service adaptation through trace inspection. International Journal

of Business Process Integration and Management, Vol. 2, No. 1, 2007. Inderscience Enterprises Ltd..

Dumas M., Spork M., and Wang K. (2006). Adapt or Perish: Algebra and Visual Notation for

Service Interface Adaptation. Proceedings of the 4th International Conference on Business Process Management (BPM), Vienna, Austria, Springer Verlag.

Appendix

- 82 -

Dijkman R.M. (2007). Mismatch Patterns in Similar Business Processes. BETA Working Paper WP-202, Eindhoven University of Technology, Eindhoven, The Netherlands.

Dijkman R.M., and Dumas M. (2004) Service-oriented Design: a Multi-viewpoint Approach. In J. Yang and C. Bussler (guest eds.): International Journal of Cooperative Information Systems (IJCIS), Special Issue on Service Oriented Modelling 13(4), pp. 337-368

Dijkman R.M (2008). Diagnosing Differences between Business Process Models. Accepted for

Publication in: Proceedings of the 6th International Conference on Business Process Management (BPM), Milan, Italy

Ernst M.D., Lencevicius R. and Perkins J. H. (2006), Detection of web service substitutability and

composability In WS-MaTe 2006: International Workshop on Web Services — Modeling and Testing, (Palermo, Italy), June 9, 2006, pp. 123-135.

Foster H, Uchitel S, Magee J, Kramer J (2004), Compatibility Verification for Web Service

Choreography. In Proc. ICWS, pages 738--741. IEEE. Foster H., Uchitel S., Magee J., Kramer J.(2003), Model-based Verification of Web Service

Compositions. In Proc. of the 18th IEEE International Conference on Automated Software Engineering (ASE'03), pages 152--163, Canada.

Gierds C., Mooij A.J. and Karsten W. (2008), Specifying and generating behavioral service

adapters based on transformation rules, 2008 International Organization for standardization (ISO), ISO20022: UNIversal Financial Industry

message scheme, retrieved September 2007, http://www.iso20022.org/ Kindler E., (1997), A compositional partial order semantics for Petri net components. In Proc.

ICATPN, volume 1248 of LNCS, pages 235–252. Küster J. M., Gerth C., Förster A., and Engels G..(2008) Detecting and Resolving Process Model

differences in the Absence of a Change Log. In: Proceedings of the 6th International Conference on Business Process Management (BPM), Milan, Italy, 2008.

Lohmann N. and Kleine J. (2008), Fully-automatic Translation of Open Workflow Net Models

into Human-readable Abstract BPEL Processes. In Proc. Modellierung, volume P-127 of Lecture Notes in Informatics (LNI), pages 57–72, March 2008.

Lohmann N., Massuthe P., Stahl C. and D. Weinberg (2008). Analyzing interacting WS-BPEL

processes using flexible model generation. Data Knowl. Eng., 64(1):38–54. Lohmann N., Verbeek H.M.W., Ouyang C., Stahl C., and Aalst W.M. P. van der. Comparing and

Evaluating Petri Net Semantics for BPEL. Computer Science Report 07/23, Eindhoven University of Technology, 2007.

Martens A. (2005) Analyzing Web Service based Business Processes. In: Proc . of int. Conf. On

Fundamental Approaches for Software Engineering. Lecture Notes in Computer Science, Vol. 3442. Springer-Verlag.

Martens A. (2003b),On Compatibility of Web Services. Petri Net Newsletter 65 12-20

Appendix

- 83 -

Martens A., (2003a). Verteilte Geschäftsprozesse – Modellierung und Verifikation mit Hilfe von Web Services. Dissertation, Humboldt-Universität zu Berlin.

Martens A. and Moser S.(2006). Diagnosing SCA components using wombat. In Proc. BPM,

volume 4102 of LNCS, pages 378–388, 2006. Massuthe P, Schmidt K. (2005), Operating Guidelines – an Automata-Theoretic Fundation for the

Service-Oriented Architecture, IN: preecedings of the IEEE int. Conf. On Quality Software, 452-457.

Massuthe P. and Wolf K.,(2007) An Algorithm for Matching Non-deterministic Services with

Operating Guidelines. IJBPIM, 2(2):81–90. Mooij A. and Goga N. (2005). Dealing with non-local choice in IEEE 1073.2's standard for remote

control, In proceedings of the 4th international SDL And MSC workshop: system analysis and modelling (SAM 2004), LNCS 3319, pages 257--270. Springer-Verlag.

Mooij A., Goga N. and Romijn J. (2005), Non-local choice and beyond: intricacies of MSC choice

nodes, In proceedings of the 8th international conference on Fundamental Approaches to Software Engineering (FASE 2005), LNCS 3442, pages 273--288. Springer-Verlag.

Mulyar N., Aalst W.M.P. van der, Aldred L. & Russell N (2007). Service Interaction Patterns: A

Configurable Framework. BPM Center Report BPM-07-07, BPMcenter.org Object Management Group, (OMG, 2006). Business Process Modeling Notation (BPMN). Version

1 - Final Adopted Specification, www.bpmi.org, August, 2007. RosettaNet Standards, retrieved September 2007, http://portal.rosettanet.org/cms/sites/

RosettaNet/Standards/index.html. Rozinat A, Aalst W.M.P. van der, (2005). Conformance testing: measuring the alignment between

event logs and process models., Beta Working Paper Series (Rep. No. WP 144), 59 pp. Society for Worldwide Interbank Financial Telecommunication (SWIFT), retrieved September

2007, http://www.swift.com/index.cfm?item_id=60395. Tretmans J. (1996), Conformance testing with labelled transition systems: implementation

relations and test generation, Computer Networks and ISDN Systems, v.29 n.1, p.49-79 Vanhatalo J., Völzer H., and Leymann F. (2007). Faster and More Focused Control-Flow Analysis

for Business Process Models Through SESE Decomposition. In ICSOC 2007, volume 4749 of LNCS, pages 43–55. Springer, 2007.

World Wide Web Consortium (W3C), retrieved July 2008

http://www.w3.org/TR/ws-gloss/#webservice XML Common Business Library website (xCBL), retrieved July 2008,

http://www.xcbl.org/about.shtml XML Common Business Library order-management choreography, (xCBL, 2003), Order

Management Choreographies version 1, retrieved July, 2008, http://www.xcbl.org/ xcbl40/documentation/view/OrderManagementChoreographies.rtf

Appendix

- 84 -

Appendix A. Order-management Choreographies

Appendix A describes the choreographies used in the validation process. The choreographies

are obtained from the XML common business library. xCBL is an XML component library for

business-to-business e-commerce. The numbers between brackets in the caption of the figures

correspond to the paragraphs of the source document (xCBL, 2003).

xCBL describes the choreographies in a natural language rather than in a formal language. This

causes problems, such as non-local choices, when modelling the choreographies in a formal

language. Nevertheless, when translating the choreographies the original description was

implemented as much as possible. The textual descriptions accompanying the figures below are

only slightly altered from the original description (xCBL, 2003). Synchronisation messages are

added to prevent the non-local choice problems.

2.1 Description: This choreography allows for a buyer to send an Order request message to the

supplier with no Order Response message returned by the supplier to the buyer.

Receive

Order RequestStart

End

Order Request

Send

Order RequestStart

End

Buyer

Supplier

Order Only (2.1)

Appendix

- 85 -

2.2 Description: This choreography allows for a buyer to send an Order message to the

supplier and the supplier returns one and only one Order Response message.

Receive

Order RequestStart

Send

Order ResponseP1

Order ResponseOrder Request

Send

Order RequestStart Receive

Order Response

P1

Buyer

Supplier

End

End

Order with order response (2.2)

Appendix

- 86 -

2.3 Description: This choreography allows for a buyer to send an order request message to the

supplier and receive multiple order responses. After receiving an order request the supplier

responds with one or more order response messages. Every additional order response message

needs to be confirmed by the buyer by sending a synchronisation message to the supplier. After

all required order response messages are sent, the supplier is able to end the process by

sending a synchronisation message to the buyer.

Receive

Order RequestStart

End

Send

Order Response

Send Sync2

P1

Order Response Sync2Order Request

P2 P3

Receive Sync

Order ResponseSync

Send

Order RequestStart

End

Receive

Order Response

Receive Sync2

P1 P2 P3Receive Order

Response

Send Sync

Buyer

Supplier

Send Order

Response

Order with cancel and multiple responses (2.3)

Appendix

- 87 -

3.2 Description: This choreography allows for a buyer to send an Order message to the

supplier and then cancel the order after receiving an Order Response to the original order. Once

the cancel request is sent, the supplier should not respond with an order response message, and

only provide a cancel response message. The buyer has to send a synchronisation message if he

decides not to cancel the order.

Receive

Order RequestStart

EndSend

Order ResponseReceive

Payment DetailsP1

Order Response Payment DetailsOrder Request

P2

P3Receive

Cancel Request

Send

Cancel Response

Cancel

Request Cancel

Response

Send

Order RequestStart

EndReceive

Order Response

Send

Payment DetailsP1 P2

P3Send

Cancel RequestReceive

Cancel Response

Buyer

Supplier

Order with order response and cancel (3.2)

Appendix

- 88 -


supplier and receive one and only one order response. Once the order response has been

received, the buyer is optionally able to send one and only one change request. For the one

change request sent to the supplier, the supplier will provide one change response. If the buyer

decides not to change the order, he then shall send a synchronisation message to finish the

process.

Receive

Order RequestStart

EndSend

Order Response

Receive Sync

P1

Order Response SyncOrder Request

P2 P3Receive

Change Request

Send

Change Response

Change

Request Change

Response

Send

Order RequestStart

EndReceive

Order Response

Send Sync

P1 P2 P3Send

Change RequestReceive

Change Response

Buyer

Supplier

Order with order response and change order (4.1)

Appendix

- 89 -


supplier and receive one and only one order response. Once the order response has been

received, the buyer is optionally able to send one or more change request messages. For each

change request message sent to the supplier, the supplier will provide one change response

message. If the buyer does not want to change the order, he then shall send a synchronisation

message to end the process.

Receive

Order RequestStart

End

Send

Order Response

Receive Sync

P1


P2 P3Receive

Change Request

Send

Change Response

Change

RequestChange

Response

Send

Order RequestStart

End

Receive

Order Response

Send Sync

P1 P2 P3Send

Change Request

Receive

Change Response

Buyer

Supplier

Order with order response and multiple change order (4.3)

Appendix

- 90 -


supplier and receive one and only one order response message. In addition, this choreography

allows for one change request per original order, and also allows for the cancellation of the

original order. This choreography requires for orders to be sent and responded to, but does not

require for Orders to be changed or cancelled, it just allows for them to be supported during

runtime.

When the buyer has received the order Response, the buyer is optionally able to send a

synchronisation message and end the Order process because he is satisfied with the order

response. However, if the buyer is not satisfied with the order response he can send one and

only one change request or can decide to cancel the order.

For the one change request sent to the supplier, the supplier will provide one and only one

change response. If a cancel request is sent by the buyer, then the supplier will provide one and

only one cancel response.

Receive

Order RequestStart

EndSend

Order ResponseReceive SyncP1


P2

P3Receive

Change Request

P4Receive

Cancel Request

Send

Change Response

Send

Cancel Response

Cancel

RequestChange

Request Change

Response

Cancel

Response

Send

Order RequestStart

EndReceive

Order Response

Send SyncP1 P2

P3Send

Change Request

P4Send

Cancel Request

Receive

Change Response

Receive

Cancel Response

Buyer

Supplier

Order with order response, change order and cancel order (5.1)

Appendix

- 91 -

Appendix B. Detailed Validation Results

Table 14 Results test case 1

Test case #1: View from supplier Provided behaviour: 2.2 Required behaviour: 2.1 Mismatches detected: Extra Send Activity: “Send Order Response” SEA generated: Order Response → Mismatches detected with adapter:

None

Extra Info All mismatches could be solved with the adapter


Test case #2: View from supplier Provided behaviour: 2.1 Required behaviour: 2.2 Mismatches detected: Skipped Send Activity: “Send Order Response” SEA generated: Sending the order response depends on receiving an

Order request. This is reflected by the SEA created:

Order Request → Order Response Mismatches detected with adapter:

None

Extra Info All mismatches could be solved with the adapter Table 16 Results test case 3

Test case #3: View from supplier Provided behaviour: 2.3 Required behaviour: 2.2 Mismatches detected: Extra Send Activity: “Send Sync2”

Extra Receive Activity: “Receive Sync” Iterative versus once of: “Send Order Response” from provided behaviour has an additional normalized cycle. Additional Dependency: “Send Order Response” from provided behaviour has additional dependencies on “send Order Response”

SEA generated: Option 1 (forward 1st response, consume others): Sync2 →;

→ Sync;

Order Response →; Mismatches detected with adapter:

All mismatches could be solved with the adapter.

Extra Info Adapter cannot merge an unbound number of messages.

Appendix

- 92 -


Test case #4: View from supplier Provided behaviour: 2.2 Required behaviour: 2.3 Mismatches detected: Skipped Send Activity: “Send Sync2”

Skipped Receive Activity: “Receive Sync” once of versus iterative: “Send Order Response” from required behaviour has an additional normalized cycle. Additional Dependency: “Send Order Response” from required behaviour has additional dependencies on “send Order Response”

SEA generated: →;Sync2 Mismatches detected with adapter:

Option 1 (extra branch not disabled): Additional dependencies: “Send Order Response” from required behaviour has additional dependencies on “Send Order Response” Additional dependencies: “Receive Sync” from required behaviour has additional dependencies on “Send Order Response” Additional dependencies: “Send Sync2” from required behaviour has additional dependencies on “Send Order Response” once of versus iterative: “Send Order Response” from required behaviour has an additional normalized cycle. Option 2 (extra branch disabled): Additional dependencies: “Send Sync2” from required behaviour has additional dependencies on “Send Order Response”

Extra Info The required behaviour has a deferred choice. In option 2 “Send Sync2” was selected as default path. Therefore , all activities in the other branch were marked as tau, resulting in less mismatch detections.


Test case #5: View from supplier Provided behaviour: 2.2 Required behaviour: 3.2 Mismatches detected: Skipped Receive Activity: “Receive Cancel Request”

Skipped Send Activity: “Send Cancel Response”

Appendix

- 93 -

Skipped Receive Activity: “Receive Sync”

SEA generated: Cancel Request → Cancel Response; Sync →;

Mismatches detected with adapter:

“Receive Cancel Response” from the required behaviour has additional dependencies on “Send Order Response” “Receive Sync” from required behaviour has additional dependencies on “Send Order Response” “Send Cancel Response” has different conditions.

Extra Info It is not possible to indicate dependencies of messages that are part of an deferred choice. Therefore those mismatches are still detected.


Test case #6: View from supplier Provided behaviour: 3.2 Required behaviour: 2.2 Mismatches detected: Extra Receive Activity: “Receive Cancel Request”

Extra Send Activity: “Send Cancel Response” Extra Receive Activity: “Receive Sync”

SEA generated: Order Response → Order Response, Sync; Mismatches detected with adapter:

None

Extra Info The provided behaviour has a deferred choice for two extra receive-activities. the “Receive Sync” activity was selected as default and the “Receive Cancel Request” activity was disabled and marked as silent.


Test case #7: View from supplier Provided behaviour: 4.1 Required behaviour: 4.3 Mismatches detected: Iterative versus once-off: required behaviour has the

additional (normalized) cycle [Send Change Response, Receive Change Request]#[Send Change Response, Receive Change Request][] Additional dependencies: “Receive Change Request” from required behaviour has additional dependencies on “Send Change Response”. Additional dependencies: “Receive Sync” from required behaviour has additional dependencies on “Send Change Response”.

SEA generated: - Mismatches detected with -

Appendix

- 94 -

adapter: Extra Info No existing mapping yet


Test case #8 View from supplier Provided behaviour: 4.3 Required behaviour: 4.1 Mismatches detected: Iterative versus once-off: provided behaviour has the

additional (normalized) cycle [Send Change Response, Receive Change Request]#[Send Change Response, Receive Change Request] Additional dependencies: “Receive Change Request”' from provided behaviour has additional dependencies on “Send Change Response” Additional dependencies: “Receive Sync” from provided behaviour has additional dependencies on “Send Change Response”

SEA generated: - Mismatches detected with adapter:

-

Extra Info No existing mapping yet


Test case #9: View from supplier Provided behaviour: 5.1 Required behaviour: 3.2 Mismatches detected: Extra Activity: “Receive Change Request”

Extra Activity: “Send Change Response” SEA generated: Disable branch starting from the “Receive Change

Request” activity. Mismatches detected with adapter:

None

Extra Info The provided behaviour contains an extra “receive activity” resulting in a deferred choice. Since the other party will never send this message, the extra “receive activity” will be a dead activity of the deferred choice. Therefore the extra “receive activity” is disabled and marked as silent.


Test case #10: View from supplier Provided behaviour: 3.2 Required behaviour: 5.1 Mismatches detected: Skipped Activity (deferred choice): “Receive Change

Request” Skipped Activity: “Send Change Response”

Appendix

- 95 -

SEA generated: Change Request → Change Response, S; Mismatches detected with adapter:

Additional conditions: “Send Change Response” from required behaviour has additional conditions characterized by EMPTY Additional dependencies: “Receive Sync” from required behaviour has additional dependencies on “Send Order Response” . Additional dependencies: “Receive Cancel Request” from required behaviour has additional dependencies on “Send Order Response”. Additional dependencies: “Receive Change Request” from required behaviour has additional dependencies “Send Order Response”. Additional dependencies; 'Send Cancel Response” from provided behaviour has additional dependencies on “Receive Order Request”.

Extra Info The business analyst has to indicate a default path for the provided behaviour, in case the alternative path is chosen by the partner. This is to ensure proper termination of the provided behaviour. For this specific case choosing the path of the “Sync” message is most logical.

detecting and resolving mismatches between provided behaviour

Documents