QUALITY REQUIREMENTS FOR SERVICE CHOREOGRAPHIES

Cesare Bartolini

, Antonia Bertolino

, Andrea Ciancone

, Guglielmo De Angelis

and

Raffaela Mirandola

CNR – ISTI, Pisa, Italy

Politecnico di Milano, Milano, Italy

Keywords:

Choreography, BPMN, Non-functional Requirements, MDE.

Abstract:

The growing interest in the Service-oriented Architecture paradigm carries along an increasing popularity

of choreographies, a ﬂexible form of service composition to manage interactions within a business process.

The BPMN provides and intuitive graphical notation to model choreographies, however there are aspects that

BPMN choreography diagrams are unable to display, related not to what the participants must do, but to how

they should do it. These non-functional requirements are usually expressed using separate, though connected,

models. This paper introduces Q4BPMN, an approach that aims at improving the expressiveness of choreogra-

phy diagrams by enhancing them with non-functional annotations. This way, the participants in the choreogra-

phy will be eased in knowing what is expected from them, and designers can exploit the underlying formalism

to support analysis and monitoring facilities.

1 INTRODUCTION

The Service-oriented Architecture (SOA) paradigm is

widely adopted for the development of software sys-

tems through the dynamic composition of network-

accessible loosely-coupled services. In SOA, the de-

velopment focus shifts from in-house custom design

and implementation of system components, to those

activities concerning the identiﬁcation, selection, and

composition of services offered by third parties. At

the same time, the environment in which software sys-

tems operate is highly changing and evolving; hence,

the service compositions should dynamically adapt,

while meeting both functional and non-functional re-

quirements concerning the required quality of service

(QoS) levels.

Whereas the orchestration composition (Peltz,

2003) connects services together using ad-hoc lan-

guage and execution engines, a service choreogra-

phy only describes the expected collaboration and

the messages exchanged among services. In the fol-

lowing, we will be referring to the notation for ser-

vice choreographies deﬁned by OMG in the stan-

dard Business Process Model and Notation (BPMN)

version 2.0 (Object Management Group, 2010). In

that speciﬁcation, a choreography establishes a “pro-

cedural contract” among the participating services,

but this deﬁnition only concerns functional aspects.

Given the increasing importance of quality aspects in

service-based systems, we claim that a choreography

speciﬁcation should also establish quality contractual

agreements, or Service Level Agreements (SLAs), at

the choreography level. Such SLAs would not en-

tail a speciﬁc concrete service, but rather the abstract

description of participants. In other words, SLAs at-

tached to a choreography description would postulate

the expected quality levels to be guaranteed between

participants playing the choreography roles. As intu-

itive and simple as such an idea is, we have not found

any proposal for it in the literature.

The current practice, in the presence of quality

constraints over a choreography, is to use the BPMN

language for functional speciﬁcation of actions ﬂow,

and, separately, other languages for the speciﬁcation

of existing quality constraints. Although this ap-

proach allows the speciﬁcation of the requirements to

be traced back to the functional speciﬁcation, such a

process requires to be managed by a modeling expert,

and does not make the SLAs immediately visible.

In this paper, we propose an approach to di-

rectly annotate the BPMN Choreography Diagram

with quality requirements the services entering the

choreography will have to abide by. The beneﬁt of

this improvement is twofold: on the one hand, the

143

Bartolini C., Bertolino A., Ciancone A., De Angelis G. and Mirandola R..

QUALITY REQUIREMENTS FOR SERVICE CHOREOGRAPHIES.

DOI: 10.5220/0003936401430148

In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST-2012), pages 143-148

ISBN: 978-989-8565-08-2

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

choreography designer can clearly and easily state

which are the requirements for the choreography and

its roles, at the same level of abstraction of the tasks’

ﬂow, and without the need to make use of separate

models; on the other hand, services willing to partic-

ipate as actors in the choreography are immediately

aware of what is requested from them. The annotated

choreography will then act as a binding contract be-

tween the entity managing the choreography and the

service providers acting in it.

In the following, we refer to the augmented BPMN

notation with its underlying implemented transforma-

tion as the Q4BPMN (Quality for BPMN) approach.

2 BACKGROUND

The work presented in this paper builds atop BPMN

choreography diagrams. The purpose of a choreogra-

phy diagram is to give a very high-level overview on

how the various companies, business units, partners

etc. (depending on the actual scope of the business

process) relate among themselves. However, BPMN

“as is” does not cover non-functional properties.

An interesting related work remarking the need

to overcome such a lack of notation is (Boccia-

relli and D’Ambrogio, 2011). This paper intro-

duces PYBPMN (Performability-enabled BPMN), a

notation for the description of a business process in

terms of both functional and non-functional proper-

ties, speciﬁcally addressing the performance and reli-

ability characterization of a business process. In par-

ticular, PYBPMN is a lightweight BPMN extension

that addresses the speciﬁcation of both performance

and reliability properties of a business process.

Even though the approach in (Bocciarelli and

D’Ambrogio, 2011) and ours look similar, they actu-

ally differ for some relevant technical aspects. First

of all, the extension provided by PYBPMN only

involves those elements of BPMN modeling busi-

ness processes, those elements natively conceived and

used for modelling service orchestrations. Q4BPMN

allows to annotate service choreographies with non-

functional aspects to provide a binding contract be-

tween the entity managing the choreography and the

service providers acting in it; thus the BPMN model-

ing elements that Q4BPMN extends are not covered by

PYBPMN. Also, PYBPMN only deals with annota-

tions concerning performance and reliability proper-

ties, while Q4BPMN natively supports the deﬁnition

of both new quality properties, and new metrics eval-

uating them.

Our approach also relies on a language called

Property Meta-Model (PMM), which was deﬁned

for specifying observable properties of the system.

PMM (Di Marco et al., 2011; Bertolino et al., 2011)

describes a property that can be ABSTRACT, DE-

SCRIPTIVE, or PRESCRIPTIVE. An ABSTRACT

property indicates a generic property that doesn’t

specify a required or guaranteed value for an observ-

able or measurable feature of a system. A DESCRIP-

TIVE property represents a guaranteed/owned prop-

erty of the system. A PRESCRIPTIVE one indicates a

system requirement. In the two latter cases, the prop-

erty is deﬁned taking into account a relational opera-

tor with a speciﬁed value.

Properties are grouped into classes, differing on

which features of the system they address. In the no-

tation proposed in this research, the property class is

a feature that allows the classiﬁcation of the proper-

ties into several groups, which generally correspond

to the requirement types in the metamodel of some

languages designed for this purpose. With respect to

this work we will focus on the following classes of

properties that PMM deﬁnes: performance, security,

dependability (Di Marco et al., 2011).

Q4BPMN aims at leveraging the introduced non-

functional annotations to apply model transformation

methodologies for the generation of analysis-oriented

target models (including performance and reliability

models). A growing interest focuses on model-driven

development, starting from domain-speciﬁc source

models, possibly augmented with suitable annota-

tions. Many proposals focusing on a particular type

of source design-oriented model and a particular type

of target analysis-oriented model exist, with the for-

mer including, for example, UML, Message Sequence

Chart, Use Case Maps, formal or ADL languages,

and the latter including Petri nets, queueing networks,

layered queueing network, stochastic process alge-

bras, Markov processes (see (Balsamo et al., 2004;

Koziolek, 2010; Bartolini et al., 2006)). To have an

overview the topic, see for example the WOSP con-

ference series (ACM, 2011).

3 LINKING QUALITY

REQUIREMENTS IN

CHOREOGRAPHY DIAGRAMS

The idea envisioned in this paper aims at changing the

way a BPMN choreography diagram looks, to high-

light its quality requirements in addition to the work-

ﬂow and the interactions between the participating ac-

tors. Of course, this change is not supposed to be just

a fancy visual change, but its objective is to be an aid

for several of the stakeholders:

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

144

• the choreography designer will be facilitated in

expressing the quality requirements, without the

need to create a separate model for them;

• the service provider willing to participate in the

choreography under a speciﬁc role will have a

more immediate understanding of what is re-

quired on his/her part;

• the testers, monitors and in general all the stake-

holders in charge of verifying that the require-

ments are met will more efﬁciently compare the

requirements with the properties of the service

provided, and will thus be able to easily detect any

violations in the contract.

The proposed Q4BPMN annotation must therefore

be supported by an underlying model, capable of

expressing the quality requirements. The annotated

BPMN model can be then used to derive different mod-

els using an MDE (France and Rumpe, 2007) ap-

proach. The so-obtained Q4BPMN model can be an-

alyzed to obtain information useful both to highlight

intrinsic features of the choreography and to detect

possible model criticalities. A model designer can

use the Q4BPMN information about quality require-

ments for tasks and participants to evaluate their im-

pact on the overall quality requirements. At the same

time, possible participants can use this information to

understand what is the quality level required oh their

part.

3.1 Q4BPMN Annotations

The annotations we introduce mostly concern chore-

ography tasks. A choreography task is not a task

in the traditional deﬁnition from programming lan-

guages, but rather an interaction between two or more

actors. A choreography task can generally be split

into a set of activities in an activity diagram, or a set

of tasks in a BPMN orchestration. This means the non-

functional requirements encompass not the single ac-

tivity executed by one of the partners, but their whole

interaction, including the whole set of messages ex-

changed between them. So, for example, if a require-

ment states that an activity has a maximum execu-

tion time of 100 ms, it means that the whole inter-

action must occur within that time, starting from the

instant the activity is ﬁred. However, it is also possi-

ble that an annotation is not related to an activity, but

to one of the roles participating in it. For instance,

if a speciﬁc service is expected to be very reliable, a

non-functional requirement could state the maximal

admissible rate for the failures the service can raise.

Finally, quality requirements might be related to

the whole choreography and not to a single task. In

this case, the requirement will involve the choreog-

raphy as a whole, which could mean that every sin-

gle task must be compliant with the requirement (in

case of requirements that are independent through-

out tasks, such as a speciﬁc security protocol), or that

there is no particular requirement on the single task,

as long as the whole choreography requirement is ful-

ﬁlled (as in the case of cumulating properties such as

response time).

Some additional information can be carried along

with the annotations. A quality requirement might

have an isHard attribute, representing the importance

of that requirement. An isHard attribute set to true

means that that is a hard requirement. Hard require-

ments are those that must necessarily be met by a ser-

vice willing to participate in the choreography, lest

it be rejected altogether. On the other hand, non-hard

requirements are called soft, and although they are not

strictly mandatory, the respect of these requirements

would constitute a preference criterion in the case of

two or more services applying for the same role.

3.2 Implementation within MagicDraw

The aforementioned quality annotations have been

successfully applied to a BPMN diagram inside the

commercial tool MagicDraw

. While there is cur-

rently no speciﬁc BPMN implementation to display

the annotations in a clear graphical format (an is-

sue which is currently being discussed with the Mag-

icDraw developers), the current implementation of

Q4BPMN is a UML proﬁle that implements the feature

of PMM (see Section 2), by deﬁning a set of stereo-

types and tagged-values for introducing the quality

requirements inside the BPMN diagram.

In the graphical view of the diagram, annotations

will be displayed inside the task boxes. The chore-

ography tasks will display the stereotype «Q4Task»

or «Q4Participants», and additional details will be

shown about the instance representing the require-

ment. The speciﬁc content of the requirement will

be expressed in an associated diagram.

To highlight a requirement meant for the whole

task, the task will be extended with the «Q4Task»

stereotype. Examples of the various annotation types

are shown in Figure 2, whereas Figure 3 contains

the details of the requirement. The Accept Re-

quest task shows an example of annotations relat-

ing to a choreography task. A requirement meant

only for a participant and not for the whole task,

on the other hand, will be shown by applying the

stereotype «Q4Participants», as shown in the Request

Taxi Service task. Quality requirements aimed at the

https://www.magicdraw.com/

QUALITYREQUIREMENTSFORSERVICECHOREOGRAPHIES

145

whole choreography are shown with the stereotype

«Q4Choreography». This kind of notation is also

extended to those choreography tasks representing a

sub-choreography.

In the properties of each requirement the (lack of)

presence of an isHard attribute shows if the require-

ment is (not) hard, in the meaning explained above.

Table 1 summarizes all Q4BPMN stereotypes and

their meaning on different BPMN elements.

Table 1: Stereotype summary.

Stereotype Target Meaning

«Q4Task» Loop task Every single execution of the

task must be executed under

the required circumstances.

The requirement is not related

to the whole execution of the

loop.

«Q4Task» Sequential

task

Every single instance of the

task must be executed under

the required circumstances.

The requirement is not related

to the whole execution of the

multi-instance task.

«Q4Task» Parallel task All instances of the task must

be executed under the required

circumstances. The require-

ment is therefore also related

to the whole execution of the

multi-instance task.

«Q4Task» Sub-

choreography

The whole sub-choreography

must be executed under the

circumstances mentioned

above.

«Q4Participants» Participant The participant must fulﬁll the

requirement. The requirement

is not task-wide.

«Q4Choreography» Start event The whole choreography must

be executed under the required

circumstances.

4 REFERENCE SCENARIO

Figure 1 shows a sample choreography, developed

using MagicDraw. The process depicted in there is

an excerpt from one of the demonstration scenar-

ios under development in the CHOReOS European

project

; it represents a taxi request to a system con-

nected to a number of taxi companies.

The process starts with a citizen requesting a taxi

using a Mobile Internet Device (MID participant).

Initially, the MID asks the requestor for conﬁrmation

about his or her need for transportation. Once the re-

questor has conﬁrmed that he or she is still in need,

http://www.choreos.eu/

Figure 1: Taxi request example.

the MID tries to forward the request to a taxi com-

pany. At this point, the taxi company can either ac-

cept or deny the request; in the latter case, the MID

will try to forward the request to another taxi com-

pany. As soon as a taxi is found, the MID will pro-

vide the details to the citizen, and when he or she is

on the taxi the route information will be sent to the

taxi navigation system.

This simple example hides some issues, not appar-

ent in the diagram, that should be taken into account

when deploying the system. For example, the MID

participant will expect the taxi company to respond

in a rather fast time. A taxi company should have a

minimum number of available taxis to be contacted.

There might be some requirements on the route set,

secure storage of requests, and so on. These require-

ments are additional to the system’s functionality, but

the diagram only displays the process ﬂow.

Figure 2 and Figure 3 show the quality require-

ments annotations in Q4BPMN applied to the referred

choreography.

The Conﬁrm taxi request task is a direct inter-

action between the MID and its owner, so it does

not have any speciﬁc requirement regarding perfor-

mances, security, or dependability. Request taxi ser-

vice, on the other hand, is surrounded by the follow-

ing contraints. First of all, the request should occur

in a limited time, say 5000 milliseconds: the citizen

might be in an urgent need of transportation, and sev-

eral companies might deny the request before he/she

can ﬁnd one which accepts it. However, a matter of

seconds is unlikely to be a problem, so this will be a

soft constraint.

The communication between the MID and the taxi

company should be encrypted, to protect both the cit-

izen from unauthorized access to personal informa-

tion, and the company from other companies inter-

cepting the call and “stealing” the customer.

The taxi company known to the MID is supposed

to have a minimum number of taxis among its assets.

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

146

Figure 2: Q4BPMN: Annotated choreography diagram.

For example, the company will be contacted if it has

a minimum of 20 functioning taxis at any time, and

possibly at least double that (these would be two sep-

arate requirements, one hard and one soft).

Also the Deny request task is supposed to happen

within a limited amount of time, such as 5000 mil-

liseconds, so that the MID can keep on contacting

other companies; but again, this will not be a hard

requirement. The same holds for Accept request.

Once the taxi company has accepted the request

and a car is going to pick up the customer, he or she

will need to be informed about the booking informa-

tion. For the aforementioned reasons, this communi-

cation must be encrypted in a secure way.

The Board taxi task must have a temporal require-

ment which represents the minimum time the taxi car

must wait, in case of the passenger not being present,

before being considered available again for another

request. Since this requirement deﬁnes a behaviour

that must be kept by a participant, it is a participant

requirement, not a task requirement. The maximum

delay time will be 15 minutes; after this, the request

is considered no longer valid.

Set route involves an interaction between the MID

and the taxi car’s navigation device. This involves a

communication that should (soft requirement) occur

on a protocol known by both devices (Bluetooth in our

example), therefore the MID and the taxi car must be

equipped with an interface compatible with that pro-

tocol. This implies that the communication will be se-

cure based on Bluetooth’s pairing procedure, so there

will not be a separate requirement for encryption.

In the annotated example, quality requirements

are provided also for the choreography as a whole.

Speciﬁcally, we assumed that a MID cannot fail more

than 4 times per 1000 operations; while the depend-

ability requirement for the Destinator Device is set

to 5 failures over 1000 operations. With respect to

the whole choreography, this example assumes that

global execution must complete in 20 minutes, and

that the choreography is considered dependabile if it

fails no more than once every 100 enactments. Even

though Figure 3 shows the speciﬁcations of such qual-

ity requirements, due to space limitations, images de-

tailing their annotation have been omitted.

5 CONCLUSIONS

This work supports the adoption of non-functional

annotations within a BPMN choreography diagram.

The paper discusses how all stakeholders can beneﬁt

form such annotations : the choreography designers,

the service providers interested in playing a role, the

monitors, and so on. Then, it details some types of

non-functional annotations, retrieving them from pre-

vious literature, and provides a possible implementa-

tion of the approach.

There is currently no graphical notation which al-

lows to easily distinguish the annotations from the

tasks. An ongoing collaboration with NoMagic aims

at improving the implementation and the frontend to

annotate the diagram, possibly adopting the Magic-

Draw Open API (No Magic, Inc., 2011).

A useful improvement to this work would be to

leverage MDE techniques to automatically derive dif-

ferent quality models starting from BPMN models of

the system. Thus, existing analysis methodologies

concerning performance, reliability and security, for

example (Balsamo et al., 2004; Becker et al., 2009;

Woodside et al., 2005; ACM, 2011), in turn may be

readily applied “as is”.

QUALITYREQUIREMENTSFORSERVICECHOREOGRAPHIES

147

Figure 3: Q4BPMN: Speciﬁcations of the quality requirements.

ACKNOWLEDGEMENTS

This paper is supported by the the European Project

FP7 IP 257178: CHOReOS, and partially by the Eu-

ropean Project FP7 NoE 256980: NESSoS.

REFERENCES

ACM (1998-2011). Proc. of ICPE/WOSP series.

Balsamo, S., Di Marco, A., Inverardi, P., and Simeoni, M.

(2004). Model-based performance prediction in soft-

ware development: A survey. IEEE TSE, 30(5):295–

310.

Bartolini, C., Bertolino, A., De Angelis, G., and Lipari, G.

(2006). A uml proﬁle and a methodology for real–time

systems design. In Proc. of eµ-SEAA, pages 108–115.

IEEE.

Becker, S., Koziolek, H., and Reussner, R. (2009). The Pal-

ladio component model for model-driven performance

prediction. Journal of Systems and Software, 82(1):3–

22.

Bertolino, A., Calabrò, A., Lonetti, F., Di Marco, A., and

Sabetta, A. (2011). Towards a model-driven infras-

tructure for runtime monitoring. In Proc. of SERENE,

pages 130–144. Springer.

Bocciarelli, P. and D’Ambrogio, A. (2011). A BPMN exten-

sion for modeling non functional properties of busi-

ness processes. In Proc. of TMS-DEVS, pages 160–

168. SCS.

Di Marco, A., Pompilio, C., Bertolino, A., Calabrò, A.,

Lonetti, F., and Sabetta, A. (2011). Yet another meta-

model to specify non-functional properties. In Proc.

of QASBA, pages 9–16. ACM.

France, R. B. and Rumpe, B. (2007). Model-driven devel-

opment of complex software: A research roadmap. In

Briand, L. C. and Wolf, A. L., editors, Proc. of ICSE-

FOSE, pages 37–54.

Koziolek, H. (2010). Performance evaluation of

component-based software systems: A survey. Per-

form. Eval., 67(8):634–658.

No Magic, Inc. (2011). OPEN API v. 17.0.1 user guide.

Object Management Group (2010). Business Process

Model and Notation (BPMN) Version 2.0.

Peltz, C. (2003). Web services orchestration and choreog-

raphy. Computer, 36(10):46–52.

Woodside, M., Petriu, D. C., Petriu, D. B., Shen, H., Israr,

T., and Merseguer, J. (2005). Performance by uniﬁed

model analysis (PUMA). In Proc. of WOSP, pages

1–12. ACM.

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

148