detecting and resolving mismatches between provided behaviour
Post on 03-Feb-2022
13 Views
Preview:
TRANSCRIPT
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.
Mismatch Patterns for Web Services
- 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.
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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.
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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)
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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
Mismatch Patterns for Web Services
- 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.
Mismatch Patterns for Web Services
- 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.
Detecting Mismatch Patterns
- 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.
Detecting Mismatch Patterns
- 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.
Detecting Mismatch Patterns
- 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.
Detecting Mismatch Patterns
- 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
Resolving Mismatches
- 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
Resolving Mismatches
- 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.
Resolving Mismatches
- 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)
Resolving Mismatches
- 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;
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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)
Resolving Mismatches
- 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.
Resolving Mismatches
- 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.
Resolving Mismatches
- 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}
Resolving Mismatches
- 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)
Resolving Mismatches
- 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
Resolving Mismatches
- 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.
Resolving Mismatches
- 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)
Resolving Mismatches
- 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
Resolving Mismatches
- 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
Resolving Mismatches
- 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
Validation and Complete Example
- 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
Validation and Complete Example
- 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:
Validation and Complete Example
- 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.
Validation and Complete Example
- 69 -
StartReceive Order
RequestSend
Order Response
P3
P1
Start Send
Order RequestReceive
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.
Validation and Complete Example
- 70 -
StartReceive Order
RequestSend
Order Response
P3
P1
Order Request
End
Receive
Cancel Request
Send
Cancel Response
Receive SyncP2
Cancel Request Cancel ResponseOrder Response Sync
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
Validation and Complete Example
- 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 →;
Validation and Complete Example
- 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;
Validation and Complete Example
- 73 -
Start Send
Order RequestReceive
Order Response
Send
Cancel RequestP3
P1P2
Order Request
End
Receive
Cancel Response
Send Sync
Cancel Request Cancel ResponseOrder Response 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 ...”.
Validation and Complete Example
- 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).
Validation and Complete Example
- 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
Validation and Complete Example
- 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
Validation and Complete Example
- 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 -
Validation and Complete Example
- 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¨aftsprozesse – Modellierung und Verifikation mit Hilfe von Web Services. Dissertation, Humboldt-Universit¨at 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¨olzer 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 -
4.1 Description: This choreography allows for a buyer to send an order request message to the
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 -
4.3 Description: This choreography allows for a buyer to send an order request message to the
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
Order Response SyncOrder Request
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 -
5.1 Description: This choreography allows for a buyer to send an order request message to the
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
Order Response SyncOrder 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 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
Table 15 Results test case 2
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 -
Table 17 Results test case 4
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.
Table 18 Results test case 5
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.
Table 19 Results test case 6
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.
Table 20 Results test case 7
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
Table 21 Results test case 8
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
Table 22 Results test case 9
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.
Table 23 Results test case 10
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.
top related