Enhancing BPMN 2.0 Support for Service Interaction Patterns

Dario Campagna, Carlos Kavka and Luka Onesti

Research and Development Department, ESTECO SPA, Area Science Park, Padriciano 99, Trieste, Italy

Keywords:

BPMN 2.0, Service Interaction Patterns.

Abstract:

Choreography modeling languages have emerged in the past years as a mean for capturing and managing

collaborative processes. The advancement of such languages let to the deﬁnition of the service interaction

patterns, a pattern-based framework for the benchmarking of choreography languages against abstracted forms

of representative scenarios. Service interaction patterns have been used to analyze the capabilities of different

languages. Since its introduction, no benchmark based on this framework has been performed on the Business

Process Model and Notation (BPMN) version 2.0. In this paper, we present an assessment of BPMN 2.0

support for service interaction patterns. We evidence the issues that limit the set of supported patterns, and

propose enhancements to overcome them.

1 INTRODUCTION

In the past years there has been much activity in

developing languages for Business Process Manage-

ment systems. In particular, languages suited for de-

scribing interaction behavior between different ser-

vices, i.e., for modeling service choreography, have

emerged as a key instrument for achieving integration

of business applications in a service-oriented archi-

tecture (SOA) setting. Examples of such languages

are Lets’Dance (Zaha et al., 2006), WS-CDL (W3C,

2005), and WS-BPEL (OASIS, 2007).

With the advancement of service choreography

languages came the need for consolidated insights

into the capability and exploitation of the resulting

standard speciﬁcations and associated implementa-

tions in terms of business requirements. In 2005, Bar-

ros et al. concluded that for service-oriented archi-

tectures to move forward, it was necessary to shift

from thinking in terms of request-response and buyer-

seller-shipper interaction scenarios into addressing

complex, large-scale, multi-party interactions in a

systematic manner. They thus presented in (Barros

et al., 2005b) a set of thirteen patterns of service in-

teractions, the service interaction patterns. These pat-

terns aim to contribute to the gathering of require-

ments needed to shed light into the nature of ser-

vice interactions in collaborative business processes,

where a number of parties, each with its own internal

processes, need to interact with one another accord-

ing to certain pre-agreed rules (Barros et al., 2005b).

The patterns capture different peculiar characteristics

of such collaborative processes. The number of in-

volved parties may be in the order of tens or even

hundreds, and thus the nature of interactions is rarely

only bilateral but rather multilateral. Furthermore, the

assumption of strict synchronization of all responses

before the next steps in a process breaks down due to

the independence of the parties. More realistically,

responses are accepted as they arrive. Also, while

it is conventional to think of multi-cast interactions

as a party sending a request to several other parties,

the reverse may also apply, several parties send mes-

sages from autonomous events to a party which corre-

lates these into a single request. Finally, not all inter-

actions in dynamic marketplaces follow a requester-

respondent-requester structure. Rather, a sender may

re-direct interactions to nominated delegates. Re-

ceivers may outsource requests, choosing to “stay in

the loop” and observe parts of responses. More gener-

ally, it may only be possibly to determine the order of

interaction at run-time, given, for example, the con-

tent of messages passed.

The collected service interaction patterns have

been derived and extrapolated from insights into real-

scale B2B transaction processing, use cases gath-

ered by standardization committees, generic scenar-

ios identiﬁed in industry standards, and case studies

reported in the literature. The patterns consolidate

recurrent scenarios and abstract them in a way that

provides reusable knowledge. They range from sim-

ple message exchanges to scenarios involving multi-

199

Campagna D., Kavka C. and Onesti L..

Enhancing BPMN 2.0 Support for Service Interaction Patterns.

DOI: 10.5220/0004989901990208

In Proceedings of the 9th International Conference on Software Engineering and Applications (ICSOFT-EA-2014), pages 199-208

ISBN: 978-989-758-036-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

ple participants and multiple message exchanges. On

the one hand, the service interaction patterns consoli-

date the nature of service interactions through gener-

alized functional classiﬁcation. On the other hand,

they clear the track for further and ongoing exten-

sions. These patterns allow the assessment of web

services standards, and the benchmarking of chore-

ography and orchestration languages, making it pos-

sible for SOA technologies to progress further (Barros

et al., 2005b).

Since their introduction, the service interaction

patterns have been used to evaluate different choreog-

raphy languages. In this paper, we focus on the latest

version of the Business Process Model and Notation,

i.e., BPMN version 2.0 (OMG, 2011), and present an

assessment of BPMN 2.0 collaboration diagrams sup-

port for the service interaction patterns.

The remainder of this paper is structured as fol-

lows. In Section 2 we recall some of the choreogra-

phy language analysis based on the service interaction

patterns. In Section 3, we evaluate BPMN 2.0 for its

pattern support, and point out issues that limit the set

of representable patterns. To overcome such issues,

we propose in Section 4 a set of enhancements for

BPMN 2.0. The paper conclusions are presented in

Section 5.

2 RELATED WORK

WS-BPEL (OASIS, 2007) has been the ﬁrst language

to be analyzed in terms of service interaction pat-

terns. In (Barros et al., 2005b; Barros et al., 2005a)

the authors show that WS-BPEL directly supports

Single Transmission Bilateral Interaction Patterns.

For Single Transmission Multilateral Interaction Pat-

terns, WS-BPEL imposes some restrictions to the

Send/Receive pattern and requires “house-keeping”

code for correlation and for capturing stop and suc-

cess conditions. Of Multi Transmission Interaction

Patterns, WS-BPEL provides support for two of the

three patterns. Lack of sufﬁcient transaction support

compromises a WS-BPEL solution for Atomic Mul-

ticast Notiﬁcation. All the Routing Patterns are sup-

ported with the exception of Dynamic Routing, which

is outside the scope of WS-BPEL.

In (Decker and Puhlmann, 2007) the authors show

that BPMN 1.0 directly supports only ﬁve of the thir-

teen service interaction patterns, and present exten-

sions for BPMN 1.0 that allow the representation of

multiple participants, correlation, and reference pass-

ing. They introduce the concept of participant set in

order to represent a set of participants of the same type

involved in the same conversation, and the concept of

reference to distinguish individual participant out of a

participant set. A reference is a special data object, it

can be connected to ﬂow objects via directed associa-

tions, and can be passed to other participants connect-

ing it to message ﬂows with undirected associations.

Thanks to these extensions, the number of patterns

supported by BPMN 1.0 increases to ten. Contingent

Request is only partially supported, while Dynamic

Routing is excluded from the analysis.

The BPMN 2.0 speciﬁcation extends the scope

and capabilities of BPMN 1.0 in several areas.

Among other improvements, it describes the execu-

tion semantics for all BPMN elements, deﬁnes an

extensibility mechanism for process model exten-

sions, and deﬁnes a choreography model. BPMN

2.0 choreographies are evaluated in (Cortes-Cornax

et al., 2011) by using an extended quality frame-

work, which includes the service interaction patterns.

Since the patterns only cover one perspective of the

requirements for choreography deﬁnition languages,

the framework also includes other perspectivespaying

special attention to graphical notations. The evalua-

tion identiﬁes a number of issues in BPMN 2.0 that af-

fects the perceptual discriminability of certain chore-

ography modeling constructs. To address these deﬁ-

ciencies, the authors propose the introduction of new

concepts in choreographydiagrams. Examples are the

concept of channel annotations, message multiplicity

for message ﬂows, and annotations for message ﬂows

to indicate which participant initiates a conversation.

In (Cortes-Cornax et al., 2012) the authors considered

a precise analysis of the support of the service inter-

action patterns in BPMN 2.0 as an important future

work. However, such a study is still missing.

3 PATTERN ANALYSIS

We present in this section an assessment of BPMN 2.0

support for the service interaction patterns introduced

by Barros et al. in (Barros et al., 2005b). This sec-

tion is organized by following the structure of (Barros

et al., 2005b). For each pattern, we present its de-

scription and issues, and propose a BPMN 2.0 imple-

mentation. The implementations and their semantics

are described in natural language. For most of the

patterns, we include a BPMN 2.0 graphical represen-

tation of the implementation. We provide no formal

validation of the proposed solutions, since the only

complete BPMN 2.0 semantics speciﬁcation is pre-

sented in (OMG, 2011) by using natural language.

As we will show, BPMN 2.0 directly supports the

Single Transmission Bilateral Interaction Patterns,

two of the three Single Transmission Multilateral In-

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

200

teraction Patterns, the Multi-responses pattern, and

two of the three Routing Patterns. With the addi-

tion of a BPMN 2.0 extension for collaborations and

message queuing, it is possible to support the One-

to-many Send/Receive pattern and the Contingent Re-

quests pattern too. The Atomic Multicast Notiﬁca-

tion pattern can only be partially supported. We ex-

cluded from this assessment the Dynamic Routing

pattern since its description is too imprecise, as al-

ready noted in (Decker et al., 2006a; Decker and

Puhlmann, 2007).

From now on, with the term party we indicate

a BPMN 2.0 participant instance, and with the term

parties we indicate a set of heterogeneous BPMN 2.0

participant instances, i.e., instances of one or more

BPMN 2.0 participants.

3.1 Single Transmission Bilateral

Interaction Patterns

Single transmission bilateral interaction patterns cor-

respond to elementary interactions where a party

sends (receives) a message, and as a result expects a

reply (sends a reply). These patterns cover one-way

and round-trip non-routed bilateral interactions.

3.1.1 Send

Description. A party X sends a message to another

party.

Issues. The counter-party may or may not be known

at design time.

The Send interaction pattern can be modeled by using

in a participant X a send task that sends a message to

a participantY, as shown in Figure 1(a). If participant

Y has multiplicity greater than one (i.e., there may be

more than one instance of Y in execution at the same

time), then we can add to the sent message payload

a reference for Y, and use context-based correlation

in Y to route the message to the correct instance. It

is assumed that the sender gains knowledge about the

receiver reference and stores it in, e.g., a data object.

3.1.2 Receive

Description. A party X receives a message from an-

other party.

The Receive: interaction pattern can be modeled by

using in a participant X a receive task that receives

a message from a participant Y, as shown in Fig-

ure 1(b). If Y has multiplicity greater than one, then

we can use context-based correlation in X to accept

only messages from a particular instance of Y.

(a) Send pattern. (b) Receive pattern.

Figure 1: Single transmission bilateral interaction patterns.

3.1.3 Send/Receive

Description. A party X engages in two casually re-

lated interactions: in the ﬁrst interaction X sends

a message to another party Y, while in the second

one X receives a message from Y.

Issues. The counter-party may or may not be known

in advance. The outgoing and incoming messages

must be correlated.

The Send/Receive interaction pattern is depicted in

Figure 1(c). It can be modeled with a send task fol-

lowed by a receive task in a participant X. The former

task sends a message to a participant Y, the latter re-

ceives a message from Y. If Y has multiplicity greater

than one, then we can make use of context-based cor-

relation for communicating with the desired instance

of Y, and take advantage of key-based correlation to

correlate outgoing and incoming messages in X.

3.2 Single Transmission Multilateral

Interaction Patterns

Single transmission multilateral interaction patterns

cover non-routed interactions where a party may send

or receive multiple messages, but as part of different

interaction threads dedicated to different parties.

3.2.1 Racing Incoming Messages

Description. A party X expects to receive one among

a set of messages. Messages may be structurally

different and may come from different parties.

The way a message is processed depends on its

type and/or the party from which it comes.

EnhancingBPMN2.0SupportforServiceInteractionPatterns

201

The Racing Incoming Messages: interaction pattern

can be modeled by using in a participant X an event

based gateway connected to catch message events, as

depicted in Figure 2. Each catch message event re-

ceives messages of a certain type, or from a particular

participant.

Figure 2: Racing Incoming Messages pattern.

3.2.2 One-to-many Send

Description. A party X sends a message to several

other parties. All the messages have the same type

(although their contents may differ).

Issues. The number of parties to whom the message

is sent may or may not be known at design time.

Under the assumption that receiving parties are in-

stances of a single participant, this pattern can be

thought as variant of the Send pattern when partici-

pant Y has multiplicity greater than one. The pattern

can be modeled as shown in Figure 3(a). A parallel

multi-instance send task A in participant X receives as

input a data object collection containing references of

participant Y instances, and sends a message to each

of them. Context-based correlation can be used in Y

in order to route messages to the correct instances.

3.2.3 One-from-many Receive

Description. A party X receives several logically re-

lated messages arising from autonomous events

occurring at different parties. The arrival of mes-

sages needs to be timely so that they can be corre-

lated as a single logical request.

Issues. Since messages originate from autonomous

parties, a mechanism is needed to determine

which incoming messages should be grouped to-

gether.

Under the assumption that sending parties are in-

stances of a single participant, this pattern can be

viewed as a variant of the Receive pattern when the

sending participant Y has multiplicity greater than

one. The pattern can be modeled as depicted in

Figure 3(b). A loop receive task A with an inter-

rupting boundary timer event is used in participant

X to receive messages from participant Y instances.

Context-based correlation can be used in X to accept

only messages from certain instances of participantY.

(a) One-to-many Send. (b) One-from-many Re-

ceive.

Figure 3: One-to-many Send pattern and One-from-many

Receive pattern.

3.2.4 One-to-many Send/Receive

Description. A party X sends a request to several

other parties, which may be all identical or log-

ically related. Responses are expected within a

given time-frame. However, some responses may

not arrive within the time-frame and some parties

may even not respond at all.

Issues. The number of parties to which messages are

sent may or may not be knownat design time. Re-

sponses need to be correlated to their correspond-

ing requests.

A BPMN 2.0 representation of this pattern is shown

in Figure 4. We use in participant X a multi-

instance sub-process with an interrupting boundary

timer event, and whose loop data input is a data ob-

ject collection containing references to instances of a

participant Y. The sub-process contains a send task

followed by a receive task. Each instance of the sub-

process sends a message to an instance of Y (context-

based correlation is used inY), and then waits for a re-

sponse. Responses could be correlated to their corre-

sponding request by using key-based correlation in X.

However, BPMN 2.0 correlation works at process in-

stance level, i.e., we can only correlate a message to a

speciﬁc instance of a process. To support this pattern

we need to correlate received messages to a particular

instance of the sub-process, and this is not possible in

BPMN 2.0. To overcomethis limitation, we propose a

BPMN 2.0 extension for collaboration/conversations,

and a modiﬁcation of message correlation semantics,

which will be described in Section 4.

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

202

Figure 4: One-to-many Send/Receive pattern.

3.3 Multi Transmission Interaction

Patterns

Multi transmission interaction patterns are dedicated

to non-routed interactions in which a party sends (re-

ceives) messages to (from) the same party.

3.3.1 Multi-responses

Description. Party X sends a request to party Y, then

X receives any number of responses from Y until

no further responses are required. The trigger of

no further responses can rise from a temporal con-

dition, or be based on message content, which in

both cases can rise from either X or Y.

Figure 5 depicts a possible representation of this pat-

tern in BPMN 2.0. Participant X sends a message to

participant Y by using the send task D. Such message

is received in Y by the receive task A. Then, Y sends

messages to X by using the loop send task B. These

messages are received in X by the loop receive task E.

X stops receiving message as soon as either the inter-

rupting boundary timer event of E is triggered, or E

loop condition evaluates to false, or a message sent by

Y (by using the send task C) reaches the interrupting

boundary catch message event of E.

Figure 5: Multi-responses pattern.

3.3.2 Contingent Requests

Description. Party X makes a request to another

party Y. If X does not receive a response within

a certain time-frame, X sends a request to another

party Z, and so on.

Issues. After a contingency request has been issued,

it may be possible that a response arrives (late)

from a previous request.

Figure 6 depicts a possible representation of the

pattern (we assume that responding parties are in-

stances of the same participant). First, a task in X se-

lects a reference to an instance ofY from a data object

collection. Then, the send task A sends to the selected

Y instance a message (context-based correlation is

used in Y). Finally, the receive task B waits for a re-

sponse from Y. Context-based correlation is used in

X to accept only messages containing the selected Y

instance reference in their payloads. If no response is

received before the interrupting timer boundary event

is triggered, then another Y instance reference is se-

lected and processed as described. Responses that ar-

rive late from previous requests are discarded thanks

to context-based correlation.

Figure 6: Contingent Requests pattern, solution (1).

The just described implementation of the pattern

exploits one of the three available solutions to han-

dle the late response issue. The ﬁrst solution (1) is

to disallow late arrivals altogether, and receive only

the response of the current request. Another solution

(2) is to accept the ﬁrst response even if it is late and

stop outstanding requests. The last solution (3) is to

accept the ﬁrst arriving response, trigger the end of

outstanding request, but receive any further response

that arrives (before X terminates). The pattern does

not predispose which of the three solutions prevails.

Solution (1) is the one adopted in Figure 6.

To support solution (2) we modify the workﬂow

in Figure 6 adding to it a data object and a task C.

The resulting workﬂow is shown in Figure 7. We use

the new data object for context-based correlation in

X. We initialize this data object with some value, and

send this value in the payload of messages sent to Y

EnhancingBPMN2.0SupportforServiceInteractionPatterns

203

instances. Only messages from Y instances contain-

ing the chosen value in their payload are accepted in

X. As soon as a response is received by B, the task

C executes and changes the value of the new data ob-

ject. Any other message coming fromY instances will

then be discarded by context-based correlation. With

the workﬂow in Figure 7 we accept late responses,

but we may lose messages that arrive after the inter-

rupting boundary timer event has been triggered and

before the activation of B. Hence, the response we

receive in X may not be the ﬁrst sent from Y. To

avoid losing responses, we propose a modiﬁcation to

the message semantics. This modiﬁcation will be de-

scribed in Section 4.2.

Figure 7: Contingent Requests pattern, solution (2).

Solution (3) requires deep changes to the BPMN

2.0 message correlation mechanism in order to be im-

plemented. A precise analysis of such changes is out

of the scope of this assessment.

3.3.3 Atomic Multicast Notiﬁcation

Description. A party sends notiﬁcations to several

parties such that a certain number of parties are

required to accept the notiﬁcation within a cer-

tain time-frame. For example, all parties or just

one party are required to accept the notiﬁcation.

In general, the constraint for successful notiﬁca-

tion applies over a range between a minimum and

maximum number.

Issues. The constraint that all parties should have re-

ceived the notiﬁcation, means that if any one party

received the notiﬁcation, all the other parties also

received it. Thus, some kind of transactional sup-

port is required.

The main issue of this pattern relates to atomic trans-

actions. Atomic transactions have an all-or-nothing

property: the actions taken by a transaction partici-

pant prior to commit are only tentative (typically they

are neither persistent nor made visible outside the

transaction); if all participants were able to execute

successfully then transactions are committed; if a par-

ticipant aborts or does not respond at all, all trans-

actions are aborted. Web Service Atomic Transac-

tion (OASIS, 2009) is an OASIS standard that deﬁnes

protocols for atomic transactions, one of them is Two-

Phase Commit (2PC). The 2PC protocol coordinates

registered participants to reach a commit or abort de-

cision, and ensures that all participants are informed

of the ﬁnal result.

BPMN 2.0 provides built-in support for busi-

ness transaction through the notion of transaction

sub-process. A sub-process marked as transactional

means that its component activities must either all

complete successfully or the sub-process must be

restored to its original consistent state. However,

business transactions are usually not ACID transac-

tions coordinated via the 2PC protocol. The reason

is they fail the isolation requirement. In order to

isolate, or lock, the resource performing the com-

ponent activities of the transaction, the transaction

must be short-running, taking milliseconds to com-

plete. For business transactions it is not possible

to make that assumption. Business transactions are

long-running, and the resources associated with their

component tasks are not locked while the transaction

is in progress. Instead, each activity in the transaction

executes normally in its turn, but if the transaction as a

whole fails to complete successfully, each of its activ-

ities that has completed already is undone by execut-

ing its deﬁned compensating activity. Hence, BPMN

2.0 provides no support for atomic transactions, but

different workarounds can be provided for the Atomic

Multicast Notiﬁcation pattern. These workarounds

will be described in Section 4.3.

3.4 Routing Patterns

Routing patterns cover routed interactions, i.e., inter-

actions involving transfers of party references.

3.4.1 Request with Referral

Description. Party X sends a request to partyY indi-

cating that any follow-up should be sent to a num-

ber of other parties (Z

, Z

, . . . , Z

) depending on

the evaluation of a certain condition.

Issues. Party Y may or may not have a prior knowl-

edge of the identity of the other parties. The in-

formation transferred from X to Y must therefore

allow Y to interact with the other parties.

This pattern can be represented in BPMN 2.0 as

shown in Figure 8. A data object collection in par-

ticipant X contains references to instances of partici-

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

204

pant Z that should receive the follow-ups (we assume

that the referred parties are all instances of the same

participant). The data object collection is transferred

to participant Y through a message sent by the send

task A in X. The receive task B inY receives the mes-

sage from A, and stores its payload (i.e., the collection

of references) into a data object collection. Then, the

multi-instance send task C in Y sends a message to

each instance of Z referenced in the data object col-

lection (context-based correlation is used in Z).

Figure 8: Request with Referral pattern.

3.4.2 Relayed Request

Description. Party X makes a request to party Y

which delegates the request to other parties

, Z

, . . . , Z

). Z

, Z

, . . . , Z

then continue inter-

actions with X while Y observes a view of the in-

teractions including faults.

Issues. The delegated parties (Z

, Z

, . . . , Z

) may or

may not have prior knowledge of the identity of

the request originator, i.e., party X. The infor-

mation transferred from party Y to the delegated

parties must therefore allow these to fully identify

and interact with X.

Figure 9 depicts the BPMN 2.0 representation of this

pattern. The send task A in participant X sends a mes-

sage containing the reference of X in its payload to

participant Y. The message is received by an inter-

mediate catch message event and its payload is stored

into a data object. Subsequently, the multi-instance

send task C in Y sends a message containing the ref-

erence of X in its payload to each instance of partici-

pant Z referenced in a data object collection (context-

based correlation is used in Z, we assume that del-

egated parties are all instances of the same partici-

pant). Each message sent by task C reaches a dif-

ferent instance of the receive task E, that in its turn

transfers the payload into a data object. The send task

F and G in Z executes in parallel. The task F sends

messages to Y, allowing it to monitor interactions be-

tween Z and X through the loop receive task D. The

task G sends messages to the loop receive task B in

order to continue the interaction with the participant

X. Context-based correlation is used in X to receive

messages from the delegated parties.

Figure 9: Relayed Request pattern.

4 BPMN 2.0 ENHANCEMENTS

We describe in this section the proposed set of en-

hancements for BPMN 2.0 that improve its support

for service interaction patterns.

4.1 Initiator Extension

In this section, we introduce the concept of collab-

oration/conversation initiator, and modify the mes-

sage correlation semantics in order to move message

routing at the initiator level. Then, we show how

such extensions help supporting the One-to-many

Send/Receive pattern with the BPMN 2.0 workﬂow

described in Section 3.2.4.

Business processes typically can run for days or

even months, requiring asynchronous communication

via messages. Moreover, many instances of a partic-

ular process will typically run in parallel, e.g., many

instances of an order process, each representing a par-

ticular order. Correlation is used to associate a partic-

ular message to an ongoing conversation between two

particular process instances. BPMN 2.0 allows using

existing message data for correlation purposes, rather

than requiring the introduction of technical correla-

tion data (OMG, 2011).

The concept of correlation facilitates the associ-

ation of a message to a process instance send task

EnhancingBPMN2.0SupportforServiceInteractionPatterns

205

(throw message event) or receive task (catch message

event) often in the context of a conversation, which is

also known as instance routing. This association can

be viewed at multiple levels, namely the collabora-

tion (conversation), choreography, and process level.

However, the actual correlation happens during run-

time (e.g., at the process level). Correlations describe

a set of predicates on a message (generally on the pay-

load) that need to be satisﬁed in order for that mes-

sage to be associated to a distinct process instance

send task (throw message event) or receive task (catch

message event).

In plain key-based correlation, messages that are

exchanged within a conversation are logically corre-

lated by means of one or more common correlation

keys. A correlation key represents a composite key

out of one or many correlation properties. A corre-

lation property essentially speciﬁes an extraction ex-

pressions atop a message. At run time, the ﬁrst sent or

received message in a conversation populates at least

one of the correlation key instances. If a follow-up

message derives a correlation key instance, where that

correlation key had previously been initialized within

the conversation, then the correlation key value in the

message and conversation must match. For example,

let us suppose to have participant X and Y involved

in a conversation with a message ﬂow going from a

send task in X to a receive task in Y, and a message

ﬂow going from a send task in Y to a receive task in

X. When the send task of the i-th instance of X sends

a message, a correlation key is instantiated from the

message payload. When the receive task of the i-th

instance of X receives a message from Y, a correla-

tion key instance is derivedfrom the receivedmessage

payload, and checked against the previously instanti-

ated correlation key. If the two key instances match,

then the received message is accepted. Otherwise, it

is discarded by the i-th instance of X.

Key-based correlation allows one to route mes-

sages to receive tasks (or catch message events) in

speciﬁc process instances, based on messages pay-

loads. In some cases, this may be not enough.

For example, in the workﬂow for the One-to-many

Send/Receive pattern depicted in Figure 4, we want

the task B to receive a message that correlates with

the one sent by the task A. Hence, we want to route

messages from Y to the task B in speciﬁc instances of

the multi-instance sub-process in X.

BPMN 2.0 does not provide a way to indicate

which element (e.g., participant, activity, etc.) in-

volved in a conversation initiates the communication.

Such information can be useful to better understand

the sequence of interactions determined by message

ﬂows in a conversation. Moreover, the knowledge of

the conversation initiator is fundamental for moving

message correlation to a level different from the one

of process instances. We propose a BPMN 2.0 exten-

sion, called initiator, which allows one to specify the

of the element initiating a conversation.

The following is the XSD schema for the initiator

extension.

<xsd:schema ...>

<xsd:element name="initiator"

type="tInitiator"/>

<xsd:complexType name="tInitiator">

<xsd:attribute name="initiatorId"

type="xsd:string"

use="required"/>

</xsd:complexType>

</xsd:schema>

The initiator element can be used to specify the

initiator of a collaboration as shown below.

<bpmn:definitions ...>

...

<bpmn:extension mustUnderstand="false"

definition="esteco:initiator"/>

...

<bpmn:collaboration ...>

<bpmn:extensionElements>

<esteco:initiator initiatorId="_11"/>

</bpmn:extensionElements>

...

</bpmn:collaboration>

...

</bpmn:definitions>

In key-based correlation, correlation key instances

are associated to conversation instances. A conversa-

tion instance is associated to the process instances that

it involves. We propose to associate conversation in-

stances to their initiators. Thanks to this association, a

received message can be routed to a speciﬁc initiator

instance. The modiﬁed key-based correlation mech-

anism works as follows. When a message is sent by

an initiator instance, a correlation key is instantiated

and associated to the corresponding conversation in-

stance. When a message reaches the initiator, the cor-

relation key instance derived from the message pay-

load is matched with correlation key instances associ-

ated to conversationinstances. If a match is found, the

message is routed to the initiator instance associated

to the matching conversation.

Let us now consider the One-to-many

Send/Receive workﬂow depicted in Figure 4.

The initiator in the conversation between X and Y is

the sub-process in X. At run-time, for each message

sent by task A, a correlation key is instantiated and

associated to an instance of the conversation. Each

sub-process instance is associated to a different

conversation instance. Each message sent by Y

generates a correlation key instance that is matched

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

206

with the correlation key instances of conversation

instances. When a match is found, the message is

routed to the sub-process instance associated to the

matching conversation, and received by the correct

instance of task B.

4.2 Message Queuing

In section 3.3.2 we proposed a BPMN 2.0 representa-

tion of Contingent Requests when the ﬁrst response is

accepted even if it is late (see Figure 7). This repre-

sentation has a ﬂaw, i.e., late responses may be lost.

In order to overcome this limitation, we propose

the introduction of message queuing. That is, each

message directed to a receive task or catch message

event in a process, is stored in a queue when it cannot

be received (e.g., when the receive task to which it is

directed to is not yet active). As soon as a receive task

or catch message event becomes active, it looks for

messages in the message queue.

Thanks to message queuing, responses that reach

participant X when the receive task B in Figure 7 is

not yet active are not lost. Let us suppose a mes-

sage fromY reaches X just after the interrupting timer

boundary events of B has been triggered. The mes-

sage is stored in a queue for task B. After the selec-

tion of the next Y reference and the execution of A, B

becomes active and immediately receives the message

that was previously stored in the queue.

4.3 Workarounds for Atomic

Transactions

As we already pointed out in Section 3.3.3, BPMN

2.0 provides no support for atomic transactions. Nev-

ertheless, different workarounds can be provided for

the Atomic Multicast Notiﬁcation pattern.

The ﬁrst workaround consists in enforcing quasi-

atomicity (Hagen and Alonso, 2000). Quasi-atomicity

is related to the ability to undo certain parts of a pro-

cess execution. Using this mechanism, receiving par-

ties can perform the work associated to received re-

quests, and compensate for it in case of failure. How-

ever, the effect of the performed work is visible to

other parties, thus violating the principle of atomic-

ity. Quasi-atomicity can be enforced in BPMN 2.0

by exploiting its built-in support for business trans-

actions. Each receiving party can use a transaction

sub-process to perform the work associated to the re-

ceived request. Activities within the transaction that

need to be undone if the transaction fails can be con-

nected with their respective compensating activities

by using compensating boundary events. Figure 10

depicts an example of usage of such BPMN 2.0 ele-

ments. Participant Y executes a transaction through a

transaction sub-process. The transaction only consists

of a task A connected to its respective compensating

activity. After the execution of the transaction sub-

process, Y awaits for an “Ok” or a “Fail” message. If

a “Fail” message is received, the compensation event

“Undo Transaction”, targeted to the transaction sub-

process, triggers the compensating activity of A and

rolls back the transaction to its initial state.

Figure 10: Example of usage of transaction sub-process,

compensating activity, and compensation events.

The second workaround is a BPMN 2.0 encoding

of the 2PC protocol as a sequence of sub-interactions,

in a way similar to the one proposed in (Barros et al.,

2005b). In the ﬁrst phase, a “prepare” message is

sent from the coordinating party to each receiving

party. Each receiver deals with this message with

a separate sub-process, which eventually will send

back a “ready” message to the coordinator. After

the timeout, the responses are counted to determine

whether the minimum and maximum constraint are

satisﬁed. Then, the second phase has a related set of

sub-processes for each party providing a “commit” or

“reject” message. Different payloadsmay be included

in the ﬁrst and second phase messages. As part of

the ﬁrst phase of interactions, contacted parties might

only see a limited content of the message, enough to

decide whether they are ready to accept the request

or not. In the second phase, selected parties see all

details needed to act on the request. Transaction sub-

processes, compensating activities, and compensation

events may be used to enforce quasi-atomicity in the

second phase.

The third workaround consists in using a variant

of the One-to-many Send/Receive pattern with a com-

pletion condition at the notifying side, as proposed

in (Decker and Puhlmann, 2007).

EnhancingBPMN2.0SupportforServiceInteractionPatterns

207

5 CONCLUSIONS

In this paper, we investigated BPMN 2.0 collabora-

tion diagram support for the service interaction pat-

terns (Barros et al., 2005b), and proposed a set of en-

hancements to broaden it.

We assessed that BPMN 2.0 directly supports nine

of the thirteen patterns, i.e., the three Single Transmis-

sion Bilateral Interaction Patterns, Racing Incoming

Messages, One-to-many Send, One-from-many Re-

ceive, Multi-responses, Request with Referral, and

Relayed Request. Standard BPMN 2.0 supports Con-

tingent Requests when we choose to disallow late re-

sponses altogether. The BPMN 1.0 extensions pre-

sented in (Decker and Puhlmann, 2007) are not nec-

essary in BPMN 2.0, since it supports multiple par-

ticipants and message correlation out of the box, and

since reference passing (Decker and Puhlmann, 2007)

can be modeled by using data objects/data inputs/data

outputs, messages, and context-based correlation.

We proposed three enhancements to broaden

BPMN 2.0 support for service interaction patterns.

The ﬁrst is an extension called initiator that together

with a modiﬁcation of the key-based message corre-

lation semantics allows the representation of the One-

to-many Send/Receive pattern. The second enhance-

ment consists in the use of message queues to sup-

port the Contingent requests pattern when we choose

to accept the ﬁrst response even if it is late and stop

outstanding requests. The last enhancement is a set

of workarounds for Atomic Multicast Notiﬁcation.

Thanks to these enhancements, BPMN 2.0 supports

eleven of the thirteen patterns.

Future work will include the study of BPMN 2.0

extensions to further improve the Contingent request

pattern support. We also plan to evaluate BPMN 2.0

as a whole, comparing and combining our results with

the ones presented in (Cortes-Cornax et al., 2011).

Moreover, we consider a π-calculus formalization of

the BPMN 2.0 semantics as an important future work.

Such a formalization would make it possible for a

formal validation of the proposed pattern represen-

tations, since a π-calculus formalization of the ser-

vice interaction patterns has already been presented

in (Decker et al., 2006b).

ACKNOWLEDGEMENTS

The authors thank the reviewers for the very useful

comments that have contributed to enhance the paper.

REFERENCES

Barros, A., Dumas, M., and Hofstede, A. (2005a). Ser-

vice Interaction Patterns. In Business Process Man-

agement, volume 3649 of Lecture Notes in Computer

Science, pages 302–318. Springer Berlin Heidelberg.

Barros, A., Dumas, M., and Hofstede, A. (2005b). Ser-

vice Interaction Patterns: Towards a Reference Frame-

work for Service-based Business Process Interconnec-

tion. Technical Report FIT-TR-2005-02, Faculty of IT,

Queensland University of Technology.

Cortes-Cornax, M., Dupuy-Chessa, S., and Rieu, D. (2012).

Choreographies in BPMN 2.0: New Challenges and

Open Questions. In Proceedings of the 4th Central-

European Workshop on Services and their Compo-

sition, ZEUS-2012, volume 847 of CEUR Workshop

Proceedings, pages 50–57.

Cortes-Cornax, M., Dupuy-Chessa, S., Rieu, D., and Du-

mas, M. (2011). Evaluating Choreographies in BPMN

2.0 Using an Extended Quality Framework. In Busi-

ness Process Model and Notation, volume 95 of Lec-

ture Notes in Business Information Processing, pages

103–117. Springer Berlin Heidelberg.

Decker, G., Overdick, H., and Zaha, J. M. (2006a). On the

Suitability of WS-CDL for Choreography Modeling.

In Proceedings of Methoden, Konzepte und Technolo-

gien f¨ur die Entwicklung von dienstebasierten Infor-

mationssystemen, EMISA 2006.

Decker, G. and Puhlmann, F. (2007). Extending BPMN for

Modeling Complex Choreographies. In Proceedings

of the 2007 OTM Confederated international confer-

ence on On the move to meaningful internet systems:

CoopIS, DOA, ODBASE, GADA, and IS - Volume Part

I, OTM’07, pages 24–40. Springer-Verlag.

Decker, G., Puhlmann, F., and Weske, M. (2006b). Formal-

izing Service Interactions. In Dustdar, S., Fiadeiro,

J., and Sheth, A. P., editors, Business Process Man-

agement, volume 4102 of Lecture Notes in Computer

Science, pages 414–419. Springer Berlin Heidelberg.

Hagen, C. and Alonso, G. (2000). Exception handling in

workﬂow management systems. IEEE Transaction on

Software Engineering, 26(10):943–958.

OASIS (2007). Web Services Business Process Ex-

ecution Language Version 2.0. http://docs.oasis-

open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html.

OASIS (2009). Web Services Atomic Transaction (WS-

AtomicTransaction) Version 1.2. http://docs.oasis-

open.org/ws-tx/wstx-wsat-1.2-spec-os/wstx-wsat-

1.2-spec-os.html.

OMG (2011). Business Process Model

and Notation (BPMN) Version 2.0.

http://www.omg.org/spec/BPMN/2.0.

W3C (2005). Web Services Choreography Description Lan-

guage Version 1.0. http://www.w3.org/TR/ws-cdl-10/.

Zaha, J., Barros, A., Dumas, M., and Hofstede, A. (2006).

Let’s Dance: A Language for Service Behavior Mod-

eling. In On the Move to Meaningful Internet Systems

2006: CoopIS, DOA, GADA, and ODBASE, volume

4275 of Lecture Notes in Computer Science, pages

145–162. Springer Berlin Heidelberg.

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

208