The design of process choreographies involves a series of activities. In each
of these activities, artefacts are developed. These activities are described as
follows:
1. High-level Structure Design: In high-level choreography design, the participant
roles as well as their communication structures are identified. High
level structure design is conducted during the Participant identification
phase.
2. High-level Behavioural Design: High-level behavioural models specify the
milestones of the collaboration and the order in which the milestones
are reached. High-level behavioural design is done during the milestone
definition phase.
3. Collaboration Scenarios: High-level choreographies are refined by introducing
dedicated collaboration scenarios that relate the reaching of milestones
to the communication between process participants. Collaboration
scenarios are developed during the choreography definition phase, based
on the scenarios informally specified during scenario modelling.
4. Behavioural Interfaces: From these collaboration scenarios, for each participant
role, a behavioural interface is derived.
High-Level Design
High-level process choreography design involves structure design and behaviour
design. In high-level structure design, participant roles of the choreography
are defined, as part of the participant identification phase. Figure 5.5
shows a high-level structure diagram for participants involved in a bidding
scenario. This diagram identifies a seller, an auctioning service, and multiple
bidders as participants. It also shows that these participants are pairwise interconnected.
Therefore, any participant can interact directly with any other.
High-level behaviour design uses milestones that are achieved during the
collaboration; it is therefore part of the milestone definition phase. Each milestone
represents a state in the overall collaboration that has a business meaning,
represented by some business value. Milestones correspond to subgoals
reached during the collaboration on the way to reaching its ultimate goal.
For instance, the ultimate goal in the bidding scenario is that the offered
goods are sold, paid for, and delivered to the bidder with the highest bid. Several
intermediate steps can be distinguished: the initial setup of the auction,
the entry of potential bidders into the auction, the actual bidding process,
and the delivery and payment.
Sunday, October 4, 2009
Business Process Modeling Notation:
In this section, the Business Process Modeling Notation (BPMN), developed
under the coordination of the Object Management Group, is introduced. The
focus of this section is not a complete presentation of the standard, but a
discussion of the main concepts of business process diagrams expressed in the
Business Process Modeling Notation.
The intent of the Business Process Modeling Notation in business process
modelling is very similar to the intent of the Unified Modeling Language for
object-oriented design and analysis. To identify the best practices of existing
approaches and to combine them into a new, generally accepted language.
The set of ancestors of BPMN include not only graph-based and Petri-netbased
process modelling languages, but also UML activity diagrams and eventdriven
process chains.
While these modelling languages focus on different levels of abstraction,
ranging from a business level to a more technical level, the Business Process
Modeling Notation aims at supporting the complete range of abstraction levels,
including business levels and software technology levels. This goal is also
laid out in the standards document, which states, �The primary goal of BPMN
is to provide a notation that is readily understandable by all business users,
from the business analysts that create the initial drafts of the processes, to
the technical developers responsible for implementing the technology that will
perform those processes, and finally, to the business people who will manage
and monitor those processes.�
under the coordination of the Object Management Group, is introduced. The
focus of this section is not a complete presentation of the standard, but a
discussion of the main concepts of business process diagrams expressed in the
Business Process Modeling Notation.
The intent of the Business Process Modeling Notation in business process
modelling is very similar to the intent of the Unified Modeling Language for
object-oriented design and analysis. To identify the best practices of existing
approaches and to combine them into a new, generally accepted language.
The set of ancestors of BPMN include not only graph-based and Petri-netbased
process modelling languages, but also UML activity diagrams and eventdriven
process chains.
While these modelling languages focus on different levels of abstraction,
ranging from a business level to a more technical level, the Business Process
Modeling Notation aims at supporting the complete range of abstraction levels,
including business levels and software technology levels. This goal is also
laid out in the standards document, which states, �The primary goal of BPMN
is to provide a notation that is readily understandable by all business users,
from the business analysts that create the initial drafts of the processes, to
the technical developers responsible for implementing the technology that will
perform those processes, and finally, to the business people who will manage
and monitor those processes.�
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.
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)