1
Modeling Service Orchestrations with
a Rule-enhanced Business Process Language
Milan Milanović1, Dragan Gašević2, Gerd Wagner3, Vladan Devedžić1

1University of Belgrade, Serbia
2Athabasca University, Canada
3Brandenburg Technical University at Cottbus, Germany

Abstract
Business process modeling has been a promising
direction in developing service compositions, in-
cluding both service orchestrations and choreo-
graphies. This paper fully focuses on the problem
of modeling service orchestrations. Despite many
promising aspects of using business process mod-
eling (BPM) languages for modeling service or-
chestrations, this paper aims to demonstrate that: i)
best practices (workflow patters) for control flows
(primary concern of service orchestrations) are
not fully covered in present languages; ii) com-
plete service compositions cannot be completely
generated from business process models; and iii)
BPM languages have limited support for
representing logical expressions, business vocabu-
laries, and business rules, which severely limits
their flexibility and expressivity. To address these
challenges, we have integrated business rule mod-
eling constructs of the REWERSE Rule Markup
Language (R2ML) with the Business Process
Modeling Notation (BPMN), resulting in our
rBPMN proposal.
1 Introduction
Various application areas (e.g., supply chain sys-
tems) with rapidly growing demands for collabo-
ration motivated a need for developing more flex-
ible software architectural styles. Service-oriented
architectures (SOAs) are considered a main con-

Copyright 2009 Milan Milanović, Dragan Gašević,
Gerd Wagner, and Vladan Devedžić. Permission to
copy is hereby granted provided the original copyright
notice is reproduced in copies made.
tender in this race by offering many important
characteristics such as stateless, loose-coupling,
reusability, and interoperability. Publishing and
discovery of services are the key prerequisites for
exchanging and integration of business logic of
potential collaborating parties. Once discovered,
the key challenge is to compose services in an or-
ganized whole which can accomplish requested
business goals and which follows business rules
and policies of collaborating parties.
Another key issue is the perspective to the
service composition. Service orchestrations and
choreographies are two widely recognized types
of service compositions. Service orchestrations
are mainly looking at the problem from the pers-
pective of one of the collaborating parties by fo-
cusing on the flow of control of the business
process at. Workflow patterns are best practices
and evaluation framework for comparison of or-
chestration languages. Service choreographies, on
the other hand, look at the composition from a
global perspective through the lenses of interac-
tion of services. Similar to workflow patterns,
service-interaction patterns are used as best prac-
tices for service choreographies and comparison
of choreography languages. In this paper, we pri-
marily focus on the problem of service orchestra-
tion, while about the problem of service choreo-
graphies we reported on elsewhere [12].
The research problem, which this paper looks
at, is related to the development of service orches-
trations. The use of business process modeling as
a basis for service composition, in general, and
orchestrations, in particular, is the most promising
research direction [31]. Modeling of service com-
positions is primarily based on the use of process-
oriented languages such as Business Process
70

2
Modeling Notation (BPMN). While the research
community provided many promising research re-
sults in the context of business process-oriented
modeling of service orchestrations, there are still
some key challenges open, which this paper tries
to address, namely: i) separation of business
process models from domain models and business
vocabularies. This causes the problems related the
generation of complete service descriptions and
service compositions from business process mod-
els. Basically, we need a way to connect business
vocabulary the business process is based on, and
definitions of message types used in a business
process; ii) lack of a formal language for defining
business conditions. Languages such as BPMN al-
low for defining conditions (e.g., for branching
decision points), but they do not define a executa-
ble condition language based on the underlying
business vocabulary; and iii) limited support for
dynamic changes of business processes. By em-
ploying rules in a process allows us to dynamical-
ly change the control flow of a process, and to en-
able defining processes in a declarative way, that
can be changed by changing only rules.
Research on integration of business rules
with business process modeling demonstrates
many benefits [4][7][15], which seem to be prom-
ising to address the abovementioned challenges.
Although there have been many attempts to inte-
grate business rules and languages, there has not
been a comprehensive solution that integrates four
main types of rules (reaction, production, integra-
tion and derivation) systematically by following
the principles of software language engineering.
To address this problem, we here propose an inte-
gration of a rule modeling language (R2ML –
REWERSE Modeling Language) with BPMN at
the level of their metamodels (Sect. 3). Once de-
fine, we will focus on how such a rule-enhanced
business process modeling language can be used
in modeling service orchestrations by analyzing
workflow patterns (Sect. 4) and concrete business
process scenarios (Sect. 5). Before concluding the
paper, we compare our proposal with the related
work in Sect. 6.
2 Background
In this section, we describe basic concepts of ser-
vice orchestrations, BPMN and R2ML languages,
as well as some aspects of integration of rules and
processes.
2.1 Service Orchestrations
There are presently two types of service composi-
tions: orchestrations and choreographies. In this
paper, our focus is on orchestrations. According
to the W3C’s Web service glossary: “An orches-
tration defines the sequence and conditions in
which one Web service invokes other Web ser-
vices in order to realize some useful function. I.e.,
an orchestration is the pattern of interactions that
a Web service agent must follow in order to
achieve its goal.” Orchestration is the interaction
between services at a message level controlled
from one party. That is, unlike choreographies
which look at the service interaction from a global
perspective, orchestrations represent a perspective
of one of the collaborating parties at a service
composition at hand. Such a business process can
result in a “long-lived, transactional, multistep
process model” [1]. There is presently a standard
for service orchestrations called Web Services
Business Process Execution Language (WS-
BPEL) language [1] or for short BPEL. In the
context of orchestration modeling, BPMN [13]
and UML activity diagrams are two typically ap-
proach. In fact, associated with the actual BPMN
specification at OMG, there is a partial mapping
defined between BPMN and BPEL.
2.2 Business processes: BPMN
BPMN is the OMG’s standard language for mod-
eling business processes [13]. Business process
models expressed in BPMN consist of a set of
modeling elements. BPMN includes three types of
`flow objects’ defining behavior: Events, Activi-
ties and Gateways (see Figure 1). Events can be
partitioned into three types, based on their posi-
tion in the business process: start events are used
to trigger processes; intermediate events can delay
processes, or they can occur during processes
[29]; and end events signal the termination of
processes. BPMN supports three types of activi-
ties: Process, Sub-Process and Task, where the
latest two have a graphical representation. Activi-
ties are represented by rectangles (with rounded
corners). Gateways are used for guiding, splitting
and merging control flow. The diamond shaped
gateways represent decisions, merges, forks, and
joins in the control flow. A gateway can be
thought of as a question that is asked at a point in
the process. BPMN has data- and event-based
XOR gateways, as well as, inclusive, parallel and
71