Process Choreography Implementation:

After discussing the design of process choreographies, this section looks at the
implementation of choreographies. Behavioural interfaces serve as blueprints
for the internal realization of process orchestrations, because each process orchestration
needs to expose an externally visible behaviour that was specified
as the behavioural interface of the respective participant.
Assume that there is a set of behavioural interfaces compatible with each
other. These interfaces can now be refined to local process orchestrations. In
local process orchestrations, activities can be added or, in some cases, even
reordered, while the observable behaviour has to be preserved.
The relationship between the behavioural interface and the local process
orchestration needs to be investigated, so that the correctness of the overall
collaboration can be achieved. Each local process orchestration needs to be
consistent with the respective behavioural interface definition. This section
will introduce consistency criteria using a business-to-business collaboration
scenario the supplier to the buyer.
As in the example discussed above, the auction is not public, so that
only registered parties can participate. Therefore, suppliers need to request
permission to participate in the auction beforehand. Once the auction has
started, suppliers can place their bids. When the auction completes, the buyer
selects a supplier according to the lowest bid or according to some other
evaluation criterion. Finally, the goods are shipped and payment is processed.
In this sample scenario, there are two alternatives for selecting a shipper:
either the selected supplier determines the shipper that would deliver the
goods to the buyer, or the supplier provides a list of shippers with different
transportation costs and quality levels, from which the buyer can choose a
shipper.
Each participant role can be potentially played by several process participants.
Each of these process participants develops a process orchestration.
These process orchestrations need to be consistent with the behavioural interface
of the participant role. For instance, the process orchestration of supplier
Su1 needs to be consistent with the behavioural interface (or with the behavioural
interfaces) of the Supplier role.
Using consistency rules, each participant can check locally whether its local
business process orchestration fits its behavioural interface. If the behavioural
interfaces are compatible with each other and if, in addition, for each
participant, the internal business process orchestration is consistent with its
behavioural interface, then a successful collaboration between the process participants
is realized�additional checks involving the internal business process
orchestrations of the participants are then not required.
The behavioural interface of a participant role leaves room for multiple
process orchestrations, i.e., there are multiple process orchestrations consistent
with a given behavioural interface.

Service Interaction Patterns in business process:

choreographies are based on message exchange, and potentially many
participants interact in a choreography, while orchestrations are based on
control flow between the activities of a single process performed by a single
organization.
Service interaction patterns aim at filling this gap by proposing small granular
types of interactions that can be combined to process choreographies. As
with control flow patterns for process orchestrations, service interaction patterns
can also be used to benchmark languages for their ability to express
advanced conversations. Service interaction patterns can be classified according
to the following schemes.
� Number of participants involved: Bilateral interactions involve two participants,
whereas multilateral interactions involve more than two participants.
� Number of messages exchanged: Single transmission versus multi-transmission
interactions.
� Variations in message receiver : In case of two-way interactions, round-trip
interaction means that the receiver of the message is necessarily the same
as the sender, whereas routed interaction means that the receiver of the
message in general differs from the sender.
The Business Process Modeling Notation is used to provide graphical representations
of service interaction patterns. Since this notation is not specifically
tailored to the needs of service interaction patterns, the graphical representations
of the patterns are not complete. Together with the textual representation
of the patterns, the service interaction patterns are described properly.
Send
The send pattern represents a one-way interaction between two participants
seen from the perspective of the sender. There are different flavours of this
pattern, considering, for instance, the moment when the sender selects the
receiver: The receiver is known either at design time of the choreography or
only during the execution of a conversation.
Receive
The receive pattern also describes a one-way interaction between two participants,
but this time seen from the perspective of the receiver. In terms of
message buffering behaviour of the receiver, two cases can be distinguished.
Messages that are not expected are either discarded or stored until a later
point in time, when they can be consumed.
In the example shown in Figure 5.19 the facility management department
of a company receives a notification that the heating system in a building
does not work properly. The receipt of the message is represented by a start
message event. On occurrence of this event, a process orchestration is started
in the facility management that checks the heating system and tries to find
the source of the problem.
Send/Receive
In the send/receive pattern, a participant sends a request to another participant
who then returns a response message. Both messages belong to the same conversation. Since there could be several send/receive interaction instances
happening in parallel, corresponding requests and responses need to
be correlated.

Basic Control Flow Relating Interactions:

the basic execution constraints between

elementary interactions
are discussed.
As seen in the milestone example, a precedes

relationship between two
interactions means that an instance of the

target interaction can occur only
if the instance of the source interaction has

already occurred. If in a logistics
environment a delivery acknowledgment message

should be sent only after a
delivery notification has been received, a

precedes relationship between the
respective elementary interactions can be used

to represent this business rule.
An inhibits relationship indicates that an

instance of the target interaction
can occur only if no instance of the source

interaction has occurred yet. In
an example involving an order process, an

invoice should not be sent after an
order cancellation by the buyer has been

received.
Also, scenarios where two interactions inhibit

each other, i.e., an instance
where either one or the other interaction can

complete, are very common.
Consider, for instance, a travel agency that

either receives a confirmation
message from the customer or a cancellation

message from the airline. To
cater to these situations, a specific

notational element for vice-versa-inhibits
is introduced.
A weak precedes relationship means that an

instance of the target interaction
can occur only after the instance of the

source interaction has already
completed or was skipped. Imagine a project

management scenario where the
project leader expects status updates from a

subcontractor that are merged
into a status report for the employer.

However, in special cases the project
leader and the subcontractors can agree that

no status update is needed.
The lifecycle of interaction instances is

shown in Figure 5.37. Interaction
instances can be in the states initialized,

enabled, completed, and skipped. An
interaction instance becomes skipped if any of

the inhibiting instances has
completed.
An interaction instance becomes enabled if

there are no precedes or weak
precedes relationships targeting the

corresponding interaction or all preceding
instances are completed and all weakly

preceding instances have been
completed or were skipped.
An instance must execute, i.e., the actual

message exchange occurs, only
if it is enabled. After the message exchange,

the instance is in the completed
state. The conversation starts with the Seller

sending an Auction creation request
message to the Auctioning service. The

precedes relationship defines that, if
this message arrived, an Account creation

request message can be sent to the
Seller. Then, the Seller sends a Registration

info message to the Auctioning
service, which responds with an Registration

confirmation message.
The weak precedes relationship connecting the

last elementary interactions
defines that the Auctioning service can send

an Auction creation confirmation
to the Seller if it has either sent a

Registration confirmation message before or if

the sending of that message was skipped. The

latter is used to cater to
situations in which a Seller is already

registered at the Auctioning service.

Properties of Business Processes:

The investigation of properties of business

process models is an important
aspect of business process management. If a

certain property at the business
process model level can be shown, then all

process instances based on
that business process model expose this

property. In this chapter, the most
important properties for process models are

introduced and related to each
other.
While structural dependencies of processes are

important, dependencies
related to data processed during business

processes should be taken care of.
Structural properties of process models are at

the centre of attention; these
properties are neither application specific

nor domain specific. Conceptually,
the situation is similar to normalization in

database theory. If all tables in
a relational database schema are, for

instance, in third normal form, then
certain anomalies can no longer occur during

the run time of the database
applications.
Structural properties of business processes

have been investigated in the
context of Petri nets.
While soundness is an important criterion, it

appears to be too strong for
particular settings. Consequently, relaxed

soundness and weak soundness have
been introduced as less rigid properties that

are still helpful in analyzing business
process models.

Advanced Control Flow Relating Interactions;

In addition to the basic control flow

constructs, there are advanced control
flow constructs in Let�s Dance. Several

interactions can belong to a composite
interaction. None of the contained interaction

instances can become enabled
before the enclosing composite interaction

instance has become enabled, and
the composite interaction instance can only

complete after all contained interaction
instances have completed or been skipped.
Interactions can also be guarded, meaning that

at the moment an interaction
instance could become enabled, a guard

condition must be fulfilled. If this
condition is not fulfilled, the instance is

skipped. Finally, repetitions and parallel
branching with an unbounded number of branches

are modelled through
repeated interactions. There are four types of

repeated interactions, similar
to those in programming languages: while,

repeat, for each (sequential), and
for each (concurrent).
�For each� repetitions have an expression

attached that determines a collection
over which the repetition is performed. The

knowledge about how
many instances are to be created for this

interaction might be available at
design time or might be known only at run

time.
Repetitions can have stop conditions attached

to them. For instance, a
repeated receive interaction should be stopped

as soon as answers from ten
participants have arrived.
The expressions attached to guarded and

repeated interactions can be
written in plain English, as Let�s Dance is

not tied to any specific expression
language. However, it must be defined which

actor is going to check whether
a condition evaluates to true or which

collection results from a repetition
expression. This desired semantics of the

process choreography is expressed through
the inhibits relationship from the Order

Response interaction to the Cancel Order

interaction. If a cancellation is issued by

the buyer on time, the supplier
can decide whether it can still be cancelled

or not.
If cancellation is still possible, the

remaining order responses are skipped
and the buyer does not need to pay. In the

case where cancellation is not
possible, a corresponding rejection notice is

sent to the buyer and the buyer
has to pay for the order. The buyer notifies

the supplier through a payment
notice.

Advanced Service Composition:

So far, business process activities have been

described by simple terms. What
is actually meant by these terms, like

AnalzyeOrder, is determined by the
reader. The intention of the terms used by the

process designer and the semantics
associated with these terms by the process

participants is, hopefully,
similar.
To improve the understanding of business

process diagrams at a nontechnical
level, textual explanations are associated

with business process models,
expressed in, for instance, event-driven

process chains. In case there are
ambiguities in a process model or certain

process parts are not clear, the
process participant can ask the process

designer about the intended meaning.
The process designer will explain the

rationale, and the process participant
will comprehend. In some cases, these

discussions might lead to a refinement
of the process model, since the process

participant might have identified an
unclear and ambiguous part in the process

model.
In this book we are very much interested in

business processes that are
enacted in software. Services can only be

composed in a correct way, if they
operate on the same domain concepts. For

instance, a service that returns
customer data can be combined with a service

that takes customer data as
input. In this case, they both operate on the

same domain concept, i.e., the
customer.
As discussed in Section 7.3, WSDL provides a

syntactic interface description
language, detailling the data types of input

and output parameters. Since
the Web services that contribute to a service

composition have most likely
been developed independently of each other,

the data types of these services
will, in most cases, not match.
Typically, these syntactic differences are

identified and the resulting problems
are solved by system architects and software

developers, using, for instance,
data mapping techniques. If compositions

involving many services need
to be developed, considerable overhead can be

expected due to heterogeneous
data types used by the Web services.
A simple example shows that syntactic

integration is not sufficient for
integrating services with each other. We

assume that a certain product needs
to be purchased and that there are two

services that return the price of the
product. Assume also that the product can be

identified by a unique product
identifier.
A price-finding application invokes the

services with the identifier of the
desired product. Both services return values.

Assume the textual descriptions
of these services indicate that the services

return the price in euros. Note that
this information about the currency is not

available from the return parameter
price of the service in WSDL file.
Even parameter names like europrice do not

help much, since the user of
the service cannot be sure that the price is

really in the euros currency.
There might be additional semantic differences

in the data returned by
services. Assume that one service returns 120

and the other service returns
118. Since the concept of price is not agreed

upon by the providers of the
services, the following issue might occur. The

price 120 includes value-added
tax, VAT, while the price 118 does not.
As a result, the price that appears to be

lower turns out to be higher
because it does not include VAT. Due to the

different semantics of the return
parameters, the price-finding application

returns a wrong result. This problem
is due to the missing semantics comparability

of the two services. Since at a
software layer there are few options for

asking the service provider about the
exact semantics of their services�as at the

application process level�this is
a severe problem.

Data Dependencies in Properties of Business Processes:

Application data are an integral part of

business processes. Data can be created,
modified, and deleted during the execution of

business processes. Since
business processes consist of a set of

activities that are related, these activities
operate on an integrated set of application

data.
Data in business process models has two

aspects, both of which need to
be covered:
� Data that activity instances manipulate by

invoking applications or services.
� Data dependencies between process

activities.
The former issue is dealt with in the

operations subdomain. In service-oriented
systems architectures, for instance, the

parameters of service invocations are
specified, so that data can be communicated

correctly with software systems
at run time.
At the process level, data dependencies

between process activities is typically
described by data flow. An example of data

flow in a business process in
the financial sector is given. A credit

approval business process contains activities
to enter a credit request, to assess the risks

of granting the credit, and
to inform the customer about the decision made

by the financial institution.
The activities of this process model operate

on case data, in particular,
the credit request. The credit request can be

represented by a record data
type with fields for the name and address of

the credit requester, the amount
requested, and other information, such as the

risk related to granting the
credit.
There are data dependencies between the

activities mentioned. The Collect
Credit Info activity is the first activity

performed. Only when this data
is available, can the risk be assessed in the

Assess Risk activity, the final
decision be made(Decide), and the requestor be

notified (Notify). Therefore,
the ordering of the activities in the business

process is strongly related to the
data dependencies of the activities.
The process model is illustrated in Figure

6.1, using a graph-based process
language that explicitly represents input and

output parameters of activities
This diagram shows that data dependencies have

implications on the ordering
of activities in the process: the Assess Risk

activity can be started only
when the credit information is available.

Since this data object is provided as
output parameter CreditInfo of the Collect

Credit Info activity, this activity
needs to complete before the risk can be

assessed, implying an ordering
between these activities.
These considerations hold only if it is

assumed that an activity instance
requires its input parameters at the start. If

this constraint is relaxed and
input parameters can be consumed after an

activity instance has started,
then in a process with a data flow A ! B, B

can actually start before A
terminates. At some point�when the input

values are required�B needs to
wait for A to deliver the required data.
This assumption can also be relaxed at the

producer side of data. If we
allow activities to generate data while they

are running, then the generated
data can be taken by the follow-up activity,

so that activities can execute
concurrently, realizing a data value stream

between them.
While most workflow management systems assume

that input data is available
up front and that only on completion, does an

activity instance write
output data values, some approaches, for

instance, the BPMN, relax this assumption.
The use of data dependencies for process

enactment control will be discussed
in more detail in the context of case handling

in Section 7.5, where
data dependencies�and not the process

structures�are the driving force for
process control.