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.
After a buyer has submitted her order to a supplier, the supplier
sends back an order response for every item in the order. After all responses
have been sent, the order cannot be cancelled by the buyer.
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.
Sunday, December 20, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec M -- By Mathias Weske
Basic Control Flow Relating Interactions
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.
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.
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.
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.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec L -- By Mathias Weske
Modelling Interactions
The main focus of Let’s Dance is to capture interactions and their behavioural
dependencies. Elementary interactions are the building blocks by which complex
interaction rules can be defined.
An elementary interaction is a combination of a send activity model and
a receive activity model. An actor reference belonging to a role is given for
every activity model. This reference indicates which activity instances must
be performed by the same participant. Typically, there is only one participant
per role involved in a conversation. In these cases, the actor reference can be
omitted in the diagrams.
It defines an interaction
between a participant of role Seller and a participant of role Auctioning
Service. It also states that a message of type Auction creation request is sent
during the interaction.
At the right-hand side in that figure, a conditional elementary interaction
is shown. Conditional elementary interactions are valid only if the condition is
met. In the example shown, the Auctioning Service sends an Account creation
request message to the seller only if the seller is not registered.
The main focus of Let’s Dance is to capture interactions and their behavioural
dependencies. Elementary interactions are the building blocks by which complex
interaction rules can be defined.
An elementary interaction is a combination of a send activity model and
a receive activity model. An actor reference belonging to a role is given for
every activity model. This reference indicates which activity instances must
be performed by the same participant. Typically, there is only one participant
per role involved in a conversation. In these cases, the actor reference can be
omitted in the diagrams.
It defines an interaction
between a participant of role Seller and a participant of role Auctioning
Service. It also states that a message of type Auction creation request is sent
during the interaction.
At the right-hand side in that figure, a conditional elementary interaction
is shown. Conditional elementary interactions are valid only if the condition is
met. In the example shown, the Auctioning Service sends an Account creation
request message to the seller only if the seller is not registered.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec K -- By Mathias Weske
High-level Choreographies
In the design of high-level choreographies, a structural, role-based view and a
behavioural milestone view can be distinguished. Let’s Dance supports both
views. At the centre of attention are roles that describe the participants of a
process choreography; these roles are depicted as boxes. Typically, there is
at most one participant per role involved in a choreography. If potentially
multiple organizations of the same role participate, overlaid boxes are used to
represent such multiplicity, as shown for role B . Channels represent interaction dependencies between roles; they are depicted
as small circles on lines connecting the roles. In the figure, a channel
between roles A and B is shown. The meaning of such a channel is that participants
of roles that are connected through channels might interact. If on the other hand there is no channel between roles, then the participants cannot
interact • Part-of Relationship: One role is part of the other role. In this case, a
participant of the subrole is part of the participant of the super-role.
For instance, a car manufacturing company can be decomposed into a
number of production sites, warehouses, and management facilities. In
terms of interaction behaviour, interaction models assigned to the superrole
are assigned to one or several of the subroles in a refinement step. For
instance, a second company interacting with the car manufacturer might
in fact only be able to interact with the management division of the car
manufacturer.
• Specialization: A subrole can also be a specialization of the super-role. The
subroles therefore inherit the interaction behaviour of the super-role. If an
interaction is possible with a participant of the super-role, then such an
interaction must also be possible with the participants of all subroles.
As an example of role specialization, consider a super-role “Carrier” and
its specializations “Land Carrier” and “Air Carrier.”
Channels can be refined into message links. While channels are not directed,
message links are directed, because they describe the flow of a message
from a sender to a receiver. Message names need to be specified for every link,
A channel can be used to represent that a seller interacts with an auctioning
service. Different message links could then refine this channel. In this way,
it could be specified that an auction creation request link from the seller to the
auctioning service is available, as is a creation confirmation link in opposite
direction. The three roles Seller, Bidder, and Auctioning Service are interconnected
through channels. Furthermore, at most one seller, at most one auctioning
service, and potentially many bidders participate in a choreography instance Milestones represent goals and subgoals to be reached during the choreography,
and at the same time serve as synchronization points in the choreography.
Milestones in Let’s Dance are depicted by filled diamonds. For each
milestone, it can be specified which participants should be synchronized when
the milestone is reached.
Different control flow constructs are available to represent the dependencies
between milestones. At this point, we will only explain the semantics of
precedes relationships. The other relationship types will be introduced shortly.
If a milestone m1 precedes a milestone m2, then m1 has to be reached before
m2 can be reached. However, there is no guarantee that m2 will eventually be
reached once m1 has been reached.
In the design of high-level choreographies, a structural, role-based view and a
behavioural milestone view can be distinguished. Let’s Dance supports both
views. At the centre of attention are roles that describe the participants of a
process choreography; these roles are depicted as boxes. Typically, there is
at most one participant per role involved in a choreography. If potentially
multiple organizations of the same role participate, overlaid boxes are used to
represent such multiplicity, as shown for role B . Channels represent interaction dependencies between roles; they are depicted
as small circles on lines connecting the roles. In the figure, a channel
between roles A and B is shown. The meaning of such a channel is that participants
of roles that are connected through channels might interact. If on the other hand there is no channel between roles, then the participants cannot
interact • Part-of Relationship: One role is part of the other role. In this case, a
participant of the subrole is part of the participant of the super-role.
For instance, a car manufacturing company can be decomposed into a
number of production sites, warehouses, and management facilities. In
terms of interaction behaviour, interaction models assigned to the superrole
are assigned to one or several of the subroles in a refinement step. For
instance, a second company interacting with the car manufacturer might
in fact only be able to interact with the management division of the car
manufacturer.
• Specialization: A subrole can also be a specialization of the super-role. The
subroles therefore inherit the interaction behaviour of the super-role. If an
interaction is possible with a participant of the super-role, then such an
interaction must also be possible with the participants of all subroles.
As an example of role specialization, consider a super-role “Carrier” and
its specializations “Land Carrier” and “Air Carrier.”
Channels can be refined into message links. While channels are not directed,
message links are directed, because they describe the flow of a message
from a sender to a receiver. Message names need to be specified for every link,
A channel can be used to represent that a seller interacts with an auctioning
service. Different message links could then refine this channel. In this way,
it could be specified that an auction creation request link from the seller to the
auctioning service is available, as is a creation confirmation link in opposite
direction. The three roles Seller, Bidder, and Auctioning Service are interconnected
through channels. Furthermore, at most one seller, at most one auctioning
service, and potentially many bidders participate in a choreography instance Milestones represent goals and subgoals to be reached during the choreography,
and at the same time serve as synchronization points in the choreography.
Milestones in Let’s Dance are depicted by filled diamonds. For each
milestone, it can be specified which participants should be synchronized when
the milestone is reached.
Different control flow constructs are available to represent the dependencies
between milestones. At this point, we will only explain the semantics of
precedes relationships. The other relationship types will be introduced shortly.
If a milestone m1 precedes a milestone m2, then m1 has to be reached before
m2 can be reached. However, there is no guarantee that m2 will eventually be
reached once m1 has been reached.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec J -- By Mathias Weske
Let’s Dance
Petri nets were used to express process choreographies.
The main idea was to show the behavioural interfaces for the participants
of a process choreography and their interconnection using message flow. As
an alternative to modelling behavioural interfaces, languages for expressing
interaction models directly have been designed. The main difference to modelling
connected behavioural interfaces is that interactions are used as basic
building blocks for choreographies, and behavioural dependencies are defined
between these interactions.
Let’s Dance is a choreography language following this interaction-centric
approach. It is based on control flow patterns and service interaction patterns.
Control flow specification is the main focus, so the language abstracts
from concrete message formats. Let’s Dance comes with two different diagram
types for supporting high-level modelling of process choreographies through
milestones and for modelling detailed collaboration scenarios.
Petri nets were used to express process choreographies.
The main idea was to show the behavioural interfaces for the participants
of a process choreography and their interconnection using message flow. As
an alternative to modelling behavioural interfaces, languages for expressing
interaction models directly have been designed. The main difference to modelling
connected behavioural interfaces is that interactions are used as basic
building blocks for choreographies, and behavioural dependencies are defined
between these interactions.
Let’s Dance is a choreography language following this interaction-centric
approach. It is based on control flow patterns and service interaction patterns.
Control flow specification is the main focus, so the language abstracts
from concrete message formats. Let’s Dance comes with two different diagram
types for supporting high-level modelling of process choreographies through
milestones and for modelling detailed collaboration scenarios.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec I -- By Mathias Weske
Contingent Requests
In the contingent requests pattern, a participant sends a request to another
participant. If this participant does not answer within a given time, the request
is sent to a second participant. Again, if no response comes back, a third
participant is contacted, and so on. Delayed responses, i.e., responses arriving
after the time-out has already occurred, might or might not be discarded. If this employee does not accept the task on time, it is delegated
to another employee, and so on.
Atomic Multicast Notification
The atomic multicast notification pattern is explained as follows. A participant
sends out notifications to several other participants who have to accept the
notification. In specific cases, only one participant is required to accept it;
in other cases, a subset of the participants or all participants are required to
accept it.
Imagine a production scenario with just-in-time delivery of some of the
components while the remaining components are kept in stock. Sometimes,
some of the components are not delivered on time.
In order to avoid getting components out of different warehouses and piling
them in front of the production facilities, the availability of all needed
components is checked. Only if all of them are available are the components
ordered to the production facilities.
Request With Referral
The request with referral pattern is especially important in service-oriented
environments where a registry is in place that allows binding to services at run
time. But also simple types of dynamic behaviour can be represented by this
pattern, for instance, the transmission of a new collaboration partner during
an interaction. In particular, the request with referral pattern can be used if a participant
A sends a message to another participant B containing a reference to participant
C. Although B does not need to know C in advance, B can now interact
with C. This pattern describes the concept of link passing mobility. As an example of this pattern, consider a customer who buys a set of books
online. The bookstore redirects the customer’s Web browser to the Web page
of an external payment service. Conceptually, this means that the bookstore
refers the payment service to the customer, who can then use the service,
although the customer was not aware about this service beforehand.
Relayed Request
The relayed request pattern is common in emailing collaboration scenarios.
A participant A sends a request to another participant B who forwards it to
a third participant C who will actually interact with A. However, B always
gets copies of the messages exchanged in order to be able to observe the
conversation. As part of
a quality management program in the company and for legal reasons, all interactions
between the payroll services provider and the employees are being
tracked.
In the contingent requests pattern, a participant sends a request to another
participant. If this participant does not answer within a given time, the request
is sent to a second participant. Again, if no response comes back, a third
participant is contacted, and so on. Delayed responses, i.e., responses arriving
after the time-out has already occurred, might or might not be discarded. If this employee does not accept the task on time, it is delegated
to another employee, and so on.
Atomic Multicast Notification
The atomic multicast notification pattern is explained as follows. A participant
sends out notifications to several other participants who have to accept the
notification. In specific cases, only one participant is required to accept it;
in other cases, a subset of the participants or all participants are required to
accept it.
Imagine a production scenario with just-in-time delivery of some of the
components while the remaining components are kept in stock. Sometimes,
some of the components are not delivered on time.
In order to avoid getting components out of different warehouses and piling
them in front of the production facilities, the availability of all needed
components is checked. Only if all of them are available are the components
ordered to the production facilities.
Request With Referral
The request with referral pattern is especially important in service-oriented
environments where a registry is in place that allows binding to services at run
time. But also simple types of dynamic behaviour can be represented by this
pattern, for instance, the transmission of a new collaboration partner during
an interaction. In particular, the request with referral pattern can be used if a participant
A sends a message to another participant B containing a reference to participant
C. Although B does not need to know C in advance, B can now interact
with C. This pattern describes the concept of link passing mobility. As an example of this pattern, consider a customer who buys a set of books
online. The bookstore redirects the customer’s Web browser to the Web page
of an external payment service. Conceptually, this means that the bookstore
refers the payment service to the customer, who can then use the service,
although the customer was not aware about this service beforehand.
Relayed Request
The relayed request pattern is common in emailing collaboration scenarios.
A participant A sends a request to another participant B who forwards it to
a third participant C who will actually interact with A. However, B always
gets copies of the messages exchanged in order to be able to observe the
conversation. As part of
a quality management program in the company and for legal reasons, all interactions
between the payroll services provider and the employees are being
tracked.
Thursday, November 19, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec H -- By Mathias Weske
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.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.If, for instance, a procurement department requests quotes for different
items from different suppliers, the different request/response pairs belong to
different conversations. In this situation the procurement department must be
able to tell which quote belongs to which request.
Therefore, correlation information must be placed inside the messages.
For instance, the request could carry a request identifier which is then also
contained inside the response message.
Racing Incoming Messages
Racing incoming messages are common in business-to-business scenarios; this
pattern is described as follows: a participant is waiting for a message to arrive,
but other participants have the chance to send a message. These messages by
different participants “race” with each other. Only the first message arriving
will be processed.
The type of the message sent or the category the sending participant belongs
to can be used to determine how the receiver processes the message.
The remaining messages may be discarded or kept for later consumption.
This aspect is not covered by the racing incoming messages pattern.
One-To-Many Send
A participant sends out several messages to other participants in parallel. It
might be the case that the list of recipients is already known at design-time of
the choreography or, alternatively, the selection of the recipients takes place
in the course of the conversation
In the BPMN, this pattern is represented by a multiple instances task
that sends election notices to all voting citizens. In this case, each citizen is
represented by an individual pool.
However, we could have used a single pool and assigned the role citizen to
this pool. In this case, the sending of election notices would be a single send
activity, and the multiplicity would only be introduced by multiple citizen
roles. Since the first alternative captures the one-to-many send pattern more
appropriately, we have chosen this illustration alternative.
One-From-Many Receive
In the one-from-many receive pattern, messages can be received from many
participants. In particular, one participant waits for messages to arrive from
other participants, and each of these participants can send exactly one message.
Typically, the receiver does not know the number of messages that will
arrive, and stops waiting as soon as a certain number of messages have arrived
or a time-out occurs.
Imagine an auctioning scenario in which the bidders bid by sending a
message directly to the seller. Each bidder can send exactly one message. The
seller accepts these messages until the auction is over, and then decides on
the highest bid.
One-To-Many Send/Receive
In the one-to-many send/receive pattern, a participant sends out several requests
to different other participants and waits for responses. Typically, not all responses need to be waited for. The requester rather waits for a certain
amount of time or stops waiting as soon as enough responses have arrived.
A travel agency looks for the best offer for a flight on a certain route. The
agent therefore initiates requests and the airlines give their prices and current availability.
Multi-Responses
In the multiple responses pattern, a participant sends a request to another
participant who sends back multiple messages. An important question in this
scenario is how the requester knows that there are no more messages to be
expected.
One option would be that the messages contain information about whether
there will be more messages or not. Another option could be that the last
message is of a special type. Finally, also a time-out could be used to stop
waiting for further messages.
In a logistics scenario, the shipper sends status messages about the delivery
to the owner of the goods at the end of every day. As soon as the goods have
arrived at their destination a delivery notification is sent.
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.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.If, for instance, a procurement department requests quotes for different
items from different suppliers, the different request/response pairs belong to
different conversations. In this situation the procurement department must be
able to tell which quote belongs to which request.
Therefore, correlation information must be placed inside the messages.
For instance, the request could carry a request identifier which is then also
contained inside the response message.
Racing Incoming Messages
Racing incoming messages are common in business-to-business scenarios; this
pattern is described as follows: a participant is waiting for a message to arrive,
but other participants have the chance to send a message. These messages by
different participants “race” with each other. Only the first message arriving
will be processed.
The type of the message sent or the category the sending participant belongs
to can be used to determine how the receiver processes the message.
The remaining messages may be discarded or kept for later consumption.
This aspect is not covered by the racing incoming messages pattern.
One-To-Many Send
A participant sends out several messages to other participants in parallel. It
might be the case that the list of recipients is already known at design-time of
the choreography or, alternatively, the selection of the recipients takes place
in the course of the conversation
In the BPMN, this pattern is represented by a multiple instances task
that sends election notices to all voting citizens. In this case, each citizen is
represented by an individual pool.
However, we could have used a single pool and assigned the role citizen to
this pool. In this case, the sending of election notices would be a single send
activity, and the multiplicity would only be introduced by multiple citizen
roles. Since the first alternative captures the one-to-many send pattern more
appropriately, we have chosen this illustration alternative.
One-From-Many Receive
In the one-from-many receive pattern, messages can be received from many
participants. In particular, one participant waits for messages to arrive from
other participants, and each of these participants can send exactly one message.
Typically, the receiver does not know the number of messages that will
arrive, and stops waiting as soon as a certain number of messages have arrived
or a time-out occurs.
Imagine an auctioning scenario in which the bidders bid by sending a
message directly to the seller. Each bidder can send exactly one message. The
seller accepts these messages until the auction is over, and then decides on
the highest bid.
One-To-Many Send/Receive
In the one-to-many send/receive pattern, a participant sends out several requests
to different other participants and waits for responses. Typically, not all responses need to be waited for. The requester rather waits for a certain
amount of time or stops waiting as soon as enough responses have arrived.
A travel agency looks for the best offer for a flight on a certain route. The
agent therefore initiates requests and the airlines give their prices and current availability.
Multi-Responses
In the multiple responses pattern, a participant sends a request to another
participant who sends back multiple messages. An important question in this
scenario is how the requester knows that there are no more messages to be
expected.
One option would be that the messages contain information about whether
there will be more messages or not. Another option could be that the last
message is of a special type. Finally, also a time-out could be used to stop
waiting for further messages.
In a logistics scenario, the shipper sends status messages about the delivery
to the owner of the goods at the end of every day. As soon as the goods have
arrived at their destination a delivery notification is sent.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec G -- By Mathias Weske
Service Interaction Patterns
However, there are several differences between
process orchestrations and process choreographies that need specific consideration:
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.
However, there are several differences between
process orchestrations and process choreographies that need specific consideration:
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.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec F -- By Mathias Weske
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.
Figure 5.16 provides an overview of the participants in that scenario: a
Buyer—for instance, a car manufacturer—uses reverse auctioning for procuring
specific components. To ease the selection of an appropriate Supplier and
to manage the auction, the buyer outsources these activities to a dedicated
Auctioning Service. A Shipper is selected to transport the ordered goods from
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.
There can be several suppliers, shippers and—in
a generic setting—multiple buyers and auctioning services. In this figure, each
participant role is specified by a set of its behavioural interfaces, as discussed
in the previous section. These interfaces need to be compatible with each
other, so that the collaboration will be successful.
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.
In order to illustrate this, Figure presents three process orchestrations
for the buyer role in the reverse auctioning example, namely B1, B2, and B3.
While the structure of the process orchestrations is at first sight similar to the
behavioural interface, there are subtle differences between them.
First of all, the process orchestrations for participants B1 and B3 contain
additional internal activities. In B1, the buyer maintains a blacklist, consisting
of suppliers that have not been recommended for acceptance by an auctioning
service.
In B3, the received recommendation is stored in any case, represented by
the Store recommendation transition. Before the buyer decides whether to accept a supplier, the historical data is consulted, represented by the Look up
historical data transition.
Buyer B1 has the same set of communication places as the behavioural
interface of the Buyer role in Figure but different control flow. B2 and
B3 have different communication places than the behavioural interface. The
question now is whether any of these implementations is consistent with the
behavioural interface of the Buyer role.
The answer to this question depends on the consistency notion in place.
By common sense we can argue that all three local process orchestrations
are consistent with the behavioural interface of the buyer: B1 stores negative
recommendations in a blacklist, and it always follows the received recommendations
sent by the auctioning service. This realizes a behaviour that is
consistent with the interface, although not all possibilities of the buyer interface
are realized: B1 does not decide about accepting a seller on its own but
always follows the recommendation received.
Buyer B2 accepts every seller, so that the recommendations received are
discarded. We can argue that the behaviour of B2 is consistent with the buyer
interface, although not all behaviours are possible, i.e., B2 cannot reject a
seller.
B3 stores the recommendation received and makes an independent decision
about accepting a seller. We can argue that this behaviour is also consistent
with the buyer interface, because B3 can communicate as specified, at least
regarding recommendation and decision messages. However, B3 is not able to
receive a notification message. If we assume that this message is not essential
then also B3 is a valid implementation of the buyer interface.
This discussion shows that the decision on whether an implementation is
consistent with a behavioural interface is subject to consistency criteria. For
details on consistency in process choreographies, the reader is referred to the
bibliographical notes of this chapter.
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.
Figure 5.16 provides an overview of the participants in that scenario: a
Buyer—for instance, a car manufacturer—uses reverse auctioning for procuring
specific components. To ease the selection of an appropriate Supplier and
to manage the auction, the buyer outsources these activities to a dedicated
Auctioning Service. A Shipper is selected to transport the ordered goods from
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.
There can be several suppliers, shippers and—in
a generic setting—multiple buyers and auctioning services. In this figure, each
participant role is specified by a set of its behavioural interfaces, as discussed
in the previous section. These interfaces need to be compatible with each
other, so that the collaboration will be successful.
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.
In order to illustrate this, Figure presents three process orchestrations
for the buyer role in the reverse auctioning example, namely B1, B2, and B3.
While the structure of the process orchestrations is at first sight similar to the
behavioural interface, there are subtle differences between them.
First of all, the process orchestrations for participants B1 and B3 contain
additional internal activities. In B1, the buyer maintains a blacklist, consisting
of suppliers that have not been recommended for acceptance by an auctioning
service.
In B3, the received recommendation is stored in any case, represented by
the Store recommendation transition. Before the buyer decides whether to accept a supplier, the historical data is consulted, represented by the Look up
historical data transition.
Buyer B1 has the same set of communication places as the behavioural
interface of the Buyer role in Figure but different control flow. B2 and
B3 have different communication places than the behavioural interface. The
question now is whether any of these implementations is consistent with the
behavioural interface of the Buyer role.
The answer to this question depends on the consistency notion in place.
By common sense we can argue that all three local process orchestrations
are consistent with the behavioural interface of the buyer: B1 stores negative
recommendations in a blacklist, and it always follows the received recommendations
sent by the auctioning service. This realizes a behaviour that is
consistent with the interface, although not all possibilities of the buyer interface
are realized: B1 does not decide about accepting a seller on its own but
always follows the recommendation received.
Buyer B2 accepts every seller, so that the recommendations received are
discarded. We can argue that the behaviour of B2 is consistent with the buyer
interface, although not all behaviours are possible, i.e., B2 cannot reject a
seller.
B3 stores the recommendation received and makes an independent decision
about accepting a seller. We can argue that this behaviour is also consistent
with the buyer interface, because B3 can communicate as specified, at least
regarding recommendation and decision messages. However, B3 is not able to
receive a notification message. If we assume that this message is not essential
then also B3 is a valid implementation of the buyer interface.
This discussion shows that the decision on whether an implementation is
consistent with a behavioural interface is subject to consistency criteria. For
details on consistency in process choreographies, the reader is referred to the
bibliographical notes of this chapter.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec E -- By Mathias Weske
Compatibility
Process choreography design needs to ensure that the process orchestrations of
the participants play together well in the overall collaboration. Compatibility
is the ability of a set of participants to interact successfully according to a
given process choreography.
Unsuccessful interaction behaviour could arise, if, for instance, different
message formats were used in a collaboration and one participant does not
understand the content of a message sent by another participant.
Another source of incompatibility—which this section will focus on—is due
to wrong and misaligned interactions. If, for instance, a participant expects
a notification at some point in its process before it can proceed, and none
of the other participants sends such a notification message, then the process
cannot continue, so a deadlock situation emerges. Compatibility of interacting
processes aims at avoiding this type of undesired behaviour due to erroneous
interactions between process orchestrations.
The bidding example illustrates the different aspects of compatibility introduced
in this section. Figure shows an auctioning scenario with three
participants involved. A potential bidder must be accepted for participation
before she can place her bid. Therefore, the bidder first needs to send a Participation
request to the auctioning service.
As a response, the auctioning service can send an Acceptance notification
or a Rejection notification. In some cases, the seller is requested to make the
final decision on whether a bidder can be accepted. In order to perform this interaction, the auctioning service forwards the request of the bidder to the
seller. It might also give a recommendation for accepting the bidder. The seller
can send a notification about his decision back to the auctioning service.
The auctioning scenario depicted in Figure 5.10 represents the participants
by pools that interact by sending and receiving messages. However, the figure
does not show any behavioural dependencies between the different message
exchanges. Nevertheless, compatibility can be investigated based on this highlevel
representation of the scenario.
Different types of structural compatibility are introduced to describe structural
properties of process choreographies. A process choreography is structurally
compatible if messages that can be sent by a participant correspond to
messages that other participants can receive. This property makes sure that
all messages that are sent can actually be received by participants. However,
it does not rule out that participants can receive additional messages that
none of the partners can send.
Strong structural compatibility of a process choreography is given if, for
every message that can be sent there is a participant who can receive it, and
if for every message that can be received, there is a participant who can send
it. Because each message flow connects exactly two participants
strong structural compatibility is satisfied in this example.
Weak structural compatibility is given if all messages sent by participants
can be received by other participants. However, it is not required that all
messages that participants can ever receive will actually be sent by other
participants.
Since the individual process orchestrations have in most cases been developed
independently of each other, a complete structural match between
participants cannot always be achieved. The occurrence of weak structural
compatibility is more likely. In this case, all messages sent can be received,
but it is not required that for every message that can be received there be a
participant who can actually send such a message.
The rationale behind this definition is that the interaction can take place,
even though some participants are able to receive additional messages. It is
assumed that these messages are not essential for the overall process choreography.
This will be discussed in more detail below.
In an alternative setting, a new auctioning service, for example, always
forwards the request by the bidder to the seller without providing recommendations.
In this case the seller will never receive any recommendation.
However, if these recommendations are not essential for the seller process orchestration,
as the example indicates, the cooperation can still be successful.
This example is shown in Figure 5.11, disregarding the bidder, who remains
unchanged.
Unlike structural compatibility, behavioural compatibility considers behavioural
dependencies, i.e., control flow between interaction instances of a
conversation. Therefore, the process orchestrations of the interacting partners
are interconnected, and the resulting process structure is analyzed. Such
analysis requires a formal, unambiguous representation.
In an approach for checking behavioural compatibility by Martens (2003c),
process orchestrations are represented by a specific class of Petri nets, namely
workflow modules. Workflow modules are basically workflow nets with additional
communication places that are used to represent message flow between
participants.
Whenever a participant sends a message, the process orchestration of that
partner features a transition with an output communication place that can
hold messages sent. At the receiver side, the workflow module requires a
matching input communication place. This place is an input place of the
transition that receives the message.
Each process orchestration is represented by a workflow module that defines
its internal behaviour and its external communication behaviour. Workflow
modules are defined as follows:
Process choreography design needs to ensure that the process orchestrations of
the participants play together well in the overall collaboration. Compatibility
is the ability of a set of participants to interact successfully according to a
given process choreography.
Unsuccessful interaction behaviour could arise, if, for instance, different
message formats were used in a collaboration and one participant does not
understand the content of a message sent by another participant.
Another source of incompatibility—which this section will focus on—is due
to wrong and misaligned interactions. If, for instance, a participant expects
a notification at some point in its process before it can proceed, and none
of the other participants sends such a notification message, then the process
cannot continue, so a deadlock situation emerges. Compatibility of interacting
processes aims at avoiding this type of undesired behaviour due to erroneous
interactions between process orchestrations.
The bidding example illustrates the different aspects of compatibility introduced
in this section. Figure shows an auctioning scenario with three
participants involved. A potential bidder must be accepted for participation
before she can place her bid. Therefore, the bidder first needs to send a Participation
request to the auctioning service.
As a response, the auctioning service can send an Acceptance notification
or a Rejection notification. In some cases, the seller is requested to make the
final decision on whether a bidder can be accepted. In order to perform this interaction, the auctioning service forwards the request of the bidder to the
seller. It might also give a recommendation for accepting the bidder. The seller
can send a notification about his decision back to the auctioning service.
The auctioning scenario depicted in Figure 5.10 represents the participants
by pools that interact by sending and receiving messages. However, the figure
does not show any behavioural dependencies between the different message
exchanges. Nevertheless, compatibility can be investigated based on this highlevel
representation of the scenario.
Different types of structural compatibility are introduced to describe structural
properties of process choreographies. A process choreography is structurally
compatible if messages that can be sent by a participant correspond to
messages that other participants can receive. This property makes sure that
all messages that are sent can actually be received by participants. However,
it does not rule out that participants can receive additional messages that
none of the partners can send.
Strong structural compatibility of a process choreography is given if, for
every message that can be sent there is a participant who can receive it, and
if for every message that can be received, there is a participant who can send
it. Because each message flow connects exactly two participants
strong structural compatibility is satisfied in this example.
Weak structural compatibility is given if all messages sent by participants
can be received by other participants. However, it is not required that all
messages that participants can ever receive will actually be sent by other
participants.
Since the individual process orchestrations have in most cases been developed
independently of each other, a complete structural match between
participants cannot always be achieved. The occurrence of weak structural
compatibility is more likely. In this case, all messages sent can be received,
but it is not required that for every message that can be received there be a
participant who can actually send such a message.
The rationale behind this definition is that the interaction can take place,
even though some participants are able to receive additional messages. It is
assumed that these messages are not essential for the overall process choreography.
This will be discussed in more detail below.
In an alternative setting, a new auctioning service, for example, always
forwards the request by the bidder to the seller without providing recommendations.
In this case the seller will never receive any recommendation.
However, if these recommendations are not essential for the seller process orchestration,
as the example indicates, the cooperation can still be successful.
This example is shown in Figure 5.11, disregarding the bidder, who remains
unchanged.
Unlike structural compatibility, behavioural compatibility considers behavioural
dependencies, i.e., control flow between interaction instances of a
conversation. Therefore, the process orchestrations of the interacting partners
are interconnected, and the resulting process structure is analyzed. Such
analysis requires a formal, unambiguous representation.
In an approach for checking behavioural compatibility by Martens (2003c),
process orchestrations are represented by a specific class of Petri nets, namely
workflow modules. Workflow modules are basically workflow nets with additional
communication places that are used to represent message flow between
participants.
Whenever a participant sends a message, the process orchestration of that
partner features a transition with an output communication place that can
hold messages sent. At the receiver side, the workflow module requires a
matching input communication place. This place is an input place of the
transition that receives the message.
Each process orchestration is represented by a workflow module that defines
its internal behaviour and its external communication behaviour. Workflow
modules are defined as follows:
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec D -- By Mathias Weske
Collaboration Scenarios
Having identified the collaboration milestones, collaboration scenarios can be
addressed, as part of the choreography definition phase. In this phase, the
interactions needed to proceed from one milestone to another are specified.
One or several collaboration scenarios show the interactions and their dependencies
that need to occur between two milestones. To this end, interactions
between process participants serve as the building blocks for the resulting
collaboration scenarios.
Scenarios should be kept small, as it is easier to reach agreement on less
complex interaction behaviour. Additional scenario models might be introduced
to deal with special cases and exceptions.
An Auction creation
request initiates the conversation and, if not registered with the auctioning
service yet, the seller needs to be registered. Once the Auction creation confirmation
message is received by the seller, the Auction is set up milestone is
reached.
Notice that the Auction is set up milestone is the final milestone in this collaboration
scenario. Therefore, it is drawn in bold in Figure 5.8. However, this
milestone is an intermediate milestone in the high-level behavioural model, so
that it is drawn with a double border in Figure 5.6.
This example uses control flow patterns to express the relationships between
the interaction models. To this end, the interaction models between
participants can be represented as a specific kind of process, in which the
building blocks are interaction models, rather than business process activities,
as in process orchestrations.
Although scenario models define control flow between interactions, the
concrete message structures have not been addressed yet. Data interoperability
is an important aspect in process choreography projects. Therefore, data
models including possible data transformation rules need to be added. Once
these aspects are defined in sufficient detail, all artefacts are aggregated in
the final process choreography.
While the collaboration scenario depicted in Figure shows the milestones
and the resulting interactions, as well as their dependencies, the interfaces
of the individual participants need to be specified; these specifications
are called behavioural interfaces. A behavioural interface covers the individual
view of one specific participant in the process choreography; the internal
aspects of the own process orchestration, as well as the interactions involving
only other participants, are disregarded.
Behavioural interfaces consider parts of process orchestrations that exhibit externally visible behaviour, for instance, communication activities
and events that represent the sending or receiving of a message.
Having identified the collaboration milestones, collaboration scenarios can be
addressed, as part of the choreography definition phase. In this phase, the
interactions needed to proceed from one milestone to another are specified.
One or several collaboration scenarios show the interactions and their dependencies
that need to occur between two milestones. To this end, interactions
between process participants serve as the building blocks for the resulting
collaboration scenarios.
Scenarios should be kept small, as it is easier to reach agreement on less
complex interaction behaviour. Additional scenario models might be introduced
to deal with special cases and exceptions.
An Auction creation
request initiates the conversation and, if not registered with the auctioning
service yet, the seller needs to be registered. Once the Auction creation confirmation
message is received by the seller, the Auction is set up milestone is
reached.
Notice that the Auction is set up milestone is the final milestone in this collaboration
scenario. Therefore, it is drawn in bold in Figure 5.8. However, this
milestone is an intermediate milestone in the high-level behavioural model, so
that it is drawn with a double border in Figure 5.6.
This example uses control flow patterns to express the relationships between
the interaction models. To this end, the interaction models between
participants can be represented as a specific kind of process, in which the
building blocks are interaction models, rather than business process activities,
as in process orchestrations.
Although scenario models define control flow between interactions, the
concrete message structures have not been addressed yet. Data interoperability
is an important aspect in process choreography projects. Therefore, data
models including possible data transformation rules need to be added. Once
these aspects are defined in sufficient detail, all artefacts are aggregated in
the final process choreography.
While the collaboration scenario depicted in Figure shows the milestones
and the resulting interactions, as well as their dependencies, the interfaces
of the individual participants need to be specified; these specifications
are called behavioural interfaces. A behavioural interface covers the individual
view of one specific participant in the process choreography; the internal
aspects of the own process orchestration, as well as the interactions involving
only other participants, are disregarded.
Behavioural interfaces consider parts of process orchestrations that exhibit externally visible behaviour, for instance, communication activities
and events that represent the sending or receiving of a message.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec C -- By Mathias Weske
Process Choreography Design
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.
Each milestone can be identified by an expression that describes the state
reached in that milestone. The milestones of (a part of) the bidding scenario
are depicted in Figure 5.6, where expressions like Auction is set up and
Bidding phase is over are used. These expressions indicate states during the
collaboration that have a business meaning.
In that figure, milestones are defined by circles, where the initial milestone
has a single border, the intermediate milestones have double borders, and the
ultimate goal milestone has a bold border. This notation follows the BPMN,
where start events, intermediate events, and end events are drawn in the same
manner. Mapping milestones to events is valid, because reaching a milestone
effectively realizes an event. For instance, the completion of the bidding phase
can be represented by an event Bidding phase is over.
Milestones have dependencies with respect to other milestones. For instance,
the auction has to be set up before the bidding process can be finished.
During the bidding scenario, first the auction is set up, defining the
first milestone, Auction is set up. The next milestone, Bidding phase is over, is
reached when the bidding phase completes. Then there is an and split gateway,
so that the next milestones Goods are delivered and Payment is completed,
can be reached concurrently. If both milestones are reached, the auction can
complete, reaching the final milestone, Auction has finished successfully.
It might also happen that a milestone is not reached in a certain conversation.
This situation occurs in the bidding scenario, for instance, if no single
bid is placed during the auction. In this case, delivery and payment cannot
occur, and the conversation ends without the final goal being reached. This
negative outcome can be modelled by introducing new milestones, reflecting
the positive and negative outcome of the bidding phase, respectively.
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.
Each milestone can be identified by an expression that describes the state
reached in that milestone. The milestones of (a part of) the bidding scenario
are depicted in Figure 5.6, where expressions like Auction is set up and
Bidding phase is over are used. These expressions indicate states during the
collaboration that have a business meaning.
In that figure, milestones are defined by circles, where the initial milestone
has a single border, the intermediate milestones have double borders, and the
ultimate goal milestone has a bold border. This notation follows the BPMN,
where start events, intermediate events, and end events are drawn in the same
manner. Mapping milestones to events is valid, because reaching a milestone
effectively realizes an event. For instance, the completion of the bidding phase
can be represented by an event Bidding phase is over.
Milestones have dependencies with respect to other milestones. For instance,
the auction has to be set up before the bidding process can be finished.
During the bidding scenario, first the auction is set up, defining the
first milestone, Auction is set up. The next milestone, Bidding phase is over, is
reached when the bidding phase completes. Then there is an and split gateway,
so that the next milestones Goods are delivered and Payment is completed,
can be reached concurrently. If both milestones are reached, the auction can
complete, reaching the final milestone, Auction has finished successfully.
It might also happen that a milestone is not reached in a certain conversation.
This situation occurs in the bidding scenario, for instance, if no single
bid is placed during the auction. In this case, delivery and payment cannot
occur, and the conversation ends without the final goal being reached. This
negative outcome can be modelled by introducing new milestones, reflecting
the positive and negative outcome of the bidding phase, respectively.
Thursday, October 22, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec B -- By Mathias Weske
Development Phases
This section introduces the development of process choreographies, guided by
phases. The main goal of this section is to provide an understanding of the
concepts and artefacts involved in the design of process choreographies, rather
than on providing a reference methodology for choreography design These phases are organized into design phases and
implementation phases, shown in the upper and lower part of that figure,
respectively. There are three associated roles that represent the stakeholders
involved in choreography design and implementation. Based on the discussion
of these roles in Section 1.2, their specific responsibilities in the context of
process choreographies are highlighted.
Business engineers are mainly involved in the choreography design phases,
including scenario modelling, domain scoping, milestone definition, and participant
identification. Business engineers are responsible for business-related
aspects of the process choreography; they need to make sure that the collaboration
contributes to the goals of the enterprise, similarly to organizational
business processes.
System architects are responsible for the architectural aspects of the implemented
process choreography. This means that they are
involved in the design of process choreographies as well as in their implementation.
In particular, they are involved in the specification of the behavioural
interfaces, discussed later in this chapter.
Once the process choreography design is completed, developers are responsible
for realizing the process orchestrations in a way that the overall
business-to-business collaboration as specified in the process choreography is
realized. Behavioural interfaces are important artefacts for designing the individual
process orchestrations.
Based on this discussion of the stakeholders in process choreography design
and implementation, the phases are sketched.
Scenario modelling is at the heart of choreography design: scenarios describe
the overall setting and goals of the process choreography. They are also
useful for integrating the results of the other design phases. To model a particular
scenario, a domain in which the cooperation will take place needs to
be specified. This is performed during the domain scoping phase by business
engineers.
Formal notations are not required in scenario modelling and domain scoping,
so that the scenario and the domain can be described in a language that
allows expressing the relevant concepts. Depending on the specific setting of
the project, plain English text enriched with informally specified graphical
diagrams can be used.
The participant identification phase is devoted to defining different roles
of choreography participants. There are two options for doing this. These
roles are specified in a way that allows for the selecting of concrete process
participants on the basis of their properties as laid out in the participant roles.
In the context of process choreographies, the term process participant
refers to an organization, rather than to an individual. For instance, the role shipper can be played by multiple shipping companies, all of which are appropriate
for participation in the process choreography.
In the milestone definition phase, the participants define certain states of
the choreography in which the cooperation has achieved certain results, typically
characterized by intermediate products. These states are called milestones.
Milestones and their ordering describe behavioural aspects of the
choreography from a high level of abstraction.
In the message identification phase, the interactions in the scenario are
used to identify and design messages that realize the various interactions. This
phase has business aspects as well as technical aspects; it is therefore located
on the border of the design and implementation of process choreographies.
The design aspects include the business content of the messages, while the
implementation aspects include the technical realization of these messages
and concrete message formats.
Finally, the choreography definition phase combines the message identification
and the milestone definition phases of the modelled scenario. The
result of this phase is a detailed specification of the interactions between the
participants, the messages to realize the interactions, and the milestones that
are reached during the resulting conversation in the instance layer.
The choreography definition phase, just like the message identification
phase, includes business aspects as well as technical aspects. Unsuccessful
interaction behaviour would arise if, for instance, message formats were used
that one or more participants would not understand. To avoid this problem,
it is assumed that message formats as well as the semantics of the messages
are agreed upon by the participants.
Domain standards, like the ones mentioned above, are in place to provide
a common terminology, and, thereby, an understanding of the concepts
used. These standards are enhanced with technical information, so that data
structures and message formats are available. Business engineers, system architects,
and developers participate in choreography definition and message
identification.
In the lower part of Figure 5.4, the phases during implementation of
process choreographies are shown. Based on the choreography definition, behavioural
interfaces of all roles in the process choreography are defined. Behavioural
interfaces serve as blueprints for the design of the individual process
orchestrations realized by the participants of the process choreography.
This section introduces the development of process choreographies, guided by
phases. The main goal of this section is to provide an understanding of the
concepts and artefacts involved in the design of process choreographies, rather
than on providing a reference methodology for choreography design These phases are organized into design phases and
implementation phases, shown in the upper and lower part of that figure,
respectively. There are three associated roles that represent the stakeholders
involved in choreography design and implementation. Based on the discussion
of these roles in Section 1.2, their specific responsibilities in the context of
process choreographies are highlighted.
Business engineers are mainly involved in the choreography design phases,
including scenario modelling, domain scoping, milestone definition, and participant
identification. Business engineers are responsible for business-related
aspects of the process choreography; they need to make sure that the collaboration
contributes to the goals of the enterprise, similarly to organizational
business processes.
System architects are responsible for the architectural aspects of the implemented
process choreography. This means that they are
involved in the design of process choreographies as well as in their implementation.
In particular, they are involved in the specification of the behavioural
interfaces, discussed later in this chapter.
Once the process choreography design is completed, developers are responsible
for realizing the process orchestrations in a way that the overall
business-to-business collaboration as specified in the process choreography is
realized. Behavioural interfaces are important artefacts for designing the individual
process orchestrations.
Based on this discussion of the stakeholders in process choreography design
and implementation, the phases are sketched.
Scenario modelling is at the heart of choreography design: scenarios describe
the overall setting and goals of the process choreography. They are also
useful for integrating the results of the other design phases. To model a particular
scenario, a domain in which the cooperation will take place needs to
be specified. This is performed during the domain scoping phase by business
engineers.
Formal notations are not required in scenario modelling and domain scoping,
so that the scenario and the domain can be described in a language that
allows expressing the relevant concepts. Depending on the specific setting of
the project, plain English text enriched with informally specified graphical
diagrams can be used.
The participant identification phase is devoted to defining different roles
of choreography participants. There are two options for doing this. These
roles are specified in a way that allows for the selecting of concrete process
participants on the basis of their properties as laid out in the participant roles.
In the context of process choreographies, the term process participant
refers to an organization, rather than to an individual. For instance, the role shipper can be played by multiple shipping companies, all of which are appropriate
for participation in the process choreography.
In the milestone definition phase, the participants define certain states of
the choreography in which the cooperation has achieved certain results, typically
characterized by intermediate products. These states are called milestones.
Milestones and their ordering describe behavioural aspects of the
choreography from a high level of abstraction.
In the message identification phase, the interactions in the scenario are
used to identify and design messages that realize the various interactions. This
phase has business aspects as well as technical aspects; it is therefore located
on the border of the design and implementation of process choreographies.
The design aspects include the business content of the messages, while the
implementation aspects include the technical realization of these messages
and concrete message formats.
Finally, the choreography definition phase combines the message identification
and the milestone definition phases of the modelled scenario. The
result of this phase is a detailed specification of the interactions between the
participants, the messages to realize the interactions, and the milestones that
are reached during the resulting conversation in the instance layer.
The choreography definition phase, just like the message identification
phase, includes business aspects as well as technical aspects. Unsuccessful
interaction behaviour would arise if, for instance, message formats were used
that one or more participants would not understand. To avoid this problem,
it is assumed that message formats as well as the semantics of the messages
are agreed upon by the participants.
Domain standards, like the ones mentioned above, are in place to provide
a common terminology, and, thereby, an understanding of the concepts
used. These standards are enhanced with technical information, so that data
structures and message formats are available. Business engineers, system architects,
and developers participate in choreography definition and message
identification.
In the lower part of Figure 5.4, the phases during implementation of
process choreographies are shown. Based on the choreography definition, behavioural
interfaces of all roles in the process choreography are defined. Behavioural
interfaces serve as blueprints for the design of the individual process
orchestrations realized by the participants of the process choreography.
Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec A -- By Mathias Weske
Motivation and Terminology
In today’s business scenarios, companies increasingly join forces to combine
their services and products to provide added-value products to the market.
These products are typically realized by business processes, which in many
cases take advantage of the existing software infrastructures of the participating
companies.
Because business-to-business collaborations are quite complex, and any
failure in the collaboration might have an immediate effect on the operational
business of the company, the cooperation between companies should be designed
very carefully. Process choreographies can be used for this endeavour.
The requirements of process choreography development depend on the
number of interacting partners and the desired level of automation. In business
environments, where the cooperation of business partners is realized through
traditional means like fax messages being sent and read and understood by
humans, where humans can pick up the phone and settle any ambiguities,
detailed and formal process choreographies are not essential.
However, if the cooperation is to be realized—at least in part—by information
systems, so that a high level of automation is achieved, there need
to be unambiguous models that specify in detail the nature of the collaboration
of business partners in the context of a process choreography. These
considerations are illustrated by an example.
Consider a bidding scenario in which the owner of a car uses an auctioning
service to sell his car to the highest bidder. Potentially, thousands of people
can participate in the auction and place their bids. Such scenarios require
agreement on how the participants need to interact with each other in order
to avoid problems that could appear as the result of wrong interaction.
To illustrate the problems that could arise from erroneous interaction,
consider a collaboration involving process orchestrations run by two companies.
The first activity to be performed by Company 1 is receive activity A1.
This activity waits to receive a message sent by activity B2. Assuming that
communication is synchronous, i.e., the receive activity A1 is blocking, the
process orchestration run by Company 1 cannot proceed.
Analogously, Company 2 waits in activity A2 to receive a message from
activity C1 to be sent by Company 1. As a result, both process orchestrations
cannot proceed: they are stuck in a permanent deadlock situation. To avoid
these kinds of problems, the partners involved in a process choreography need
to agree on the process choreography.
The behaviours are valid because each
process instance will perform a set of activity instances before it completes.
Deadlock situations, infinite loops, and other types of undesired behaviour
cannot appear.
The problem encountered is due to links between send and receive activities
in the process orchestrations. As the example illustrates, the viewpoint of
an individual process orchestration does not suffice for reasoning about the
interaction between process orchestrations; a global view on the interactions
between process orchestrations is required.
At the metamodel level, the Process Choreography Metamodel is
shown which provides the concepts to express Process Choreographies at the
model level.
Concrete instances of process choreographies are called Process Conversations,
which appear at the instance level. A Process Choreography Language
provides constructs to express process choreographies based on a process
choreography metamodel.
Each interaction model is associated with two objects of the class Communication
Activity Model. Communication activity models are activity models
in process orchestrations that exhibit a communication behaviour by sending or receiving messages. For the time being we focus on simple interactions
involving two activities.
As with process orchestrations, we can distinguish between models and
instances. The term Process Conversation refers to the concrete messages that are exchanged
as specified in a given process choreography. Therefore, process choreographies
serve as conversation models. Each process conversation consists of
a set of Interaction Instances, each of which is the concrete realization of a
message exchange as specified by the associated interaction model. Each interaction
instance is associated with Communication Activity Instances, which
are the concrete activity instances that send and receive messages.
In today’s business scenarios, companies increasingly join forces to combine
their services and products to provide added-value products to the market.
These products are typically realized by business processes, which in many
cases take advantage of the existing software infrastructures of the participating
companies.
Because business-to-business collaborations are quite complex, and any
failure in the collaboration might have an immediate effect on the operational
business of the company, the cooperation between companies should be designed
very carefully. Process choreographies can be used for this endeavour.
The requirements of process choreography development depend on the
number of interacting partners and the desired level of automation. In business
environments, where the cooperation of business partners is realized through
traditional means like fax messages being sent and read and understood by
humans, where humans can pick up the phone and settle any ambiguities,
detailed and formal process choreographies are not essential.
However, if the cooperation is to be realized—at least in part—by information
systems, so that a high level of automation is achieved, there need
to be unambiguous models that specify in detail the nature of the collaboration
of business partners in the context of a process choreography. These
considerations are illustrated by an example.
Consider a bidding scenario in which the owner of a car uses an auctioning
service to sell his car to the highest bidder. Potentially, thousands of people
can participate in the auction and place their bids. Such scenarios require
agreement on how the participants need to interact with each other in order
to avoid problems that could appear as the result of wrong interaction.
To illustrate the problems that could arise from erroneous interaction,
consider a collaboration involving process orchestrations run by two companies.
The first activity to be performed by Company 1 is receive activity A1.
This activity waits to receive a message sent by activity B2. Assuming that
communication is synchronous, i.e., the receive activity A1 is blocking, the
process orchestration run by Company 1 cannot proceed.
Analogously, Company 2 waits in activity A2 to receive a message from
activity C1 to be sent by Company 1. As a result, both process orchestrations
cannot proceed: they are stuck in a permanent deadlock situation. To avoid
these kinds of problems, the partners involved in a process choreography need
to agree on the process choreography.
The behaviours are valid because each
process instance will perform a set of activity instances before it completes.
Deadlock situations, infinite loops, and other types of undesired behaviour
cannot appear.
The problem encountered is due to links between send and receive activities
in the process orchestrations. As the example illustrates, the viewpoint of
an individual process orchestration does not suffice for reasoning about the
interaction between process orchestrations; a global view on the interactions
between process orchestrations is required.
At the metamodel level, the Process Choreography Metamodel is
shown which provides the concepts to express Process Choreographies at the
model level.
Concrete instances of process choreographies are called Process Conversations,
which appear at the instance level. A Process Choreography Language
provides constructs to express process choreographies based on a process
choreography metamodel.
Each interaction model is associated with two objects of the class Communication
Activity Model. Communication activity models are activity models
in process orchestrations that exhibit a communication behaviour by sending or receiving messages. For the time being we focus on simple interactions
involving two activities.
As with process orchestrations, we can distinguish between models and
instances. The term Process Conversation refers to the concrete messages that are exchanged
as specified in a given process choreography. Therefore, process choreographies
serve as conversation models. Each process conversation consists of
a set of Interaction Instances, each of which is the concrete realization of a
message exchange as specified by the associated interaction model. Each interaction
instance is associated with Communication Activity Instances, which
are the concrete activity instances that send and receive messages.
Thursday, October 15, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec Z -- By Mathias Weske
Business Process Diagrams
The notational elements in business process diagrams are divided into four
basic categories, each of which consists of a set of elements.
Flow objects are the building blocks of business processes; they include
events, activities, and gateways. The occurrence of states in the real world that are relevant for business processes are represented by events. Activities
represent work performed during business processes. Gateways are used to
represent the split and join behaviour of the flow of control between activities,
events, and gateways.
Organizational aspects are represented in business process diagrams by
swimlanes. Swimlanes are restricted to a two-level hierarchy: pools and lanes.
Pools represent organizations that participate in the interaction of multiple
business processes, each of which is enacted by one organization. Lanes represent
organizational entities such as departments within a participating organization.
By drawing flow objects in swimlanes, the organizational entity
responsible for performing the specific objects can be represented graphically.
Artefacts are used to show additional information about a business process
that is “not directly relevant for sequence flow or message flow of the process”,
as the standard mentions. Data objects, groups, and annotations are supported
as artefacts. Each artefact can be associated with flow elements. Artefacts
serve only information purposes. The process flow is not influenced by
artefacts.
Data objects are represented simply by a name. The main purpose of data
object artefacts is documentation of the process. Using directed association
arcs, the modeller can represent the fact that a data object is used (or created/
modified) by an activity in the process. Paper documents and electronic
documents, as well as information on any type of medium; can be represented
by data objects.
Text annotations are used to document certain aspects of the business
process in textual form. The text is graphically associated with the object
in the business process diagram that the text explains. Group objects are
artefacts that are used to group elements of a process. Groups do not have a
formal meaning; they just serve documentation purposes. Groups may span
lanes and even pools.
Connecting objects connect flow objects, swimlanes, or artefacts. Sequence
flow is used to specify the ordering of flow objects, while message flow describes
the flow of messages between business partners represented by pools. Association
is a specific type of connecting object that is used to link artefacts to
elements in business process diagrams. The categories of notational elements
are shown Figure 4.78.
The core element set provides a small set of concepts and their graphical
representation for modelling business processes. The idea is to provide an
easy-to-use notation by concentrating on the main aspects of business process
modelling, without introducing complexity that might not be relevant.
The business process diagram shown represents a review
process for a scientific conference. The program committee chairperson is the
central role in the process; this role is represented by the PC Chair pool. There
are two additional roles involved, namely authors who submit their research
papers and reviewers who perform peer reviews for the submitted papers. Since the goal of this example is to introduce the core elements, simplifications
are in place: the business process model provides a simplified view of how
review processes are actually conducted. In addition, there are many authors
and there are also many reviewers. For convenience, just one author and one
reviewer are shown. As will be discussed below, situations in which multiple
participants are involved in the same role cannot be covered conveniently.
The pools in this example represent roles and not concrete participants in a
business process. Each role at run time has multiple concrete participants who
are actually involved in the business process instance. The BPMN standard
indicates that “a pool represents a participant in a process. It is also acts as a
“swimlane” and a graphical container for partitioning a set of activities from
other pools, usually in the context of B2B situations.”
The process starts when the PC Chair is asked to organize the scientific
program of a conference. This is reflected by the start event of the process at
the PC Chair. An event is something that ‘happens’ during the course of a
business process. These events affect the flow of the process and usually have
a cause (trigger) or an impact (result). Events are circles with open centres
to allow internal markers to differentiate different triggers or results.”
The activity enacted first is the publication of a call for papers with detailed
information on the conference, such as name and location, and also
information regarding the topics addressed by the conference. The receipt of
a message can be an event that is relevant for the process. This concept is
used in the sample process when the published call for papers activity sends
a message that the author receives. Receiving this message is represented by
the start event of the author process. The cause of this event is receiving the message and the effect is spawning the process. The same concept is used to
start the reviewer process in a later phase of the overall process.
Activities represent units of work that are actually conducted during the
course of the business process. The sample process contains, in the PC Chair
process, a set of activities that are enacted in sequence. The standard states
that “an activity is a generic term for work that a company performs. An
activity can be atomic or non-atomic (compound). The types of activities
that are a part of a process model are: process, subprocess, and task. Tasks
and subprocesses are rounded rectangles. Processes are either unbounded or
contained within a Pool.”
Business processes contain execution constraints between activities. The
simplest form of execution constraint is execution order. “A Sequence Flow is
used to show the order that activities will be performed in a process.”
More complex execution constraints are splits and joins of branches, where
different types of splits and joins are available. These structures are represented
by gateways. A gateway is graphically represented by a diamond. Split
nodes have multiple outgoing edges and join nodes have multiple incoming
edges. The notation for a gateway is identical to that for split and join nodes.
The split and join behaviour is represented only by the edges attached to
a gateway symbol. “A Gateway is used to control the divergence and convergence
of Sequence Flow. Thus, it will determine branching, forking, merging,
and joining of paths. Internal markers will indicate the type of behaviour
control.”
In the sample business process, the author pool contains a split gateway
and a join gateway. The split gateway evaluates the received notification information
and—in case the paper is accepted—triggers the preparation of the final version of the paper that will be printed in the conference proceedings.
In case the paper is rejected, the join gateway is triggered. To clarify the behaviour
of the split gateway, the outgoing sequence flows are associated with
the respective annotations.
The participants that cooperate in the context of a business process communicate
by sending and receiving messages. In business process diagrams,
messages are represented by message flow. Typically a message flow connects
an activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),
message flows can link pairs of flow objects, pools, and events. Detailed rules
on message flow connections are discussed below. “A Message Flow is used to
show the flow of messages between two participants that are prepared to send
and receive them. In BPMN, two separate Pools in the Diagram will represent
the two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour of
business processes (transaction groups, compensation flow, and cancellation)
will not be covered, because their semantics is not laid out in sufficient detail
and precision.
The notational elements in business process diagrams are divided into four
basic categories, each of which consists of a set of elements.
Flow objects are the building blocks of business processes; they include
events, activities, and gateways. The occurrence of states in the real world that are relevant for business processes are represented by events. Activities
represent work performed during business processes. Gateways are used to
represent the split and join behaviour of the flow of control between activities,
events, and gateways.
Organizational aspects are represented in business process diagrams by
swimlanes. Swimlanes are restricted to a two-level hierarchy: pools and lanes.
Pools represent organizations that participate in the interaction of multiple
business processes, each of which is enacted by one organization. Lanes represent
organizational entities such as departments within a participating organization.
By drawing flow objects in swimlanes, the organizational entity
responsible for performing the specific objects can be represented graphically.
Artefacts are used to show additional information about a business process
that is “not directly relevant for sequence flow or message flow of the process”,
as the standard mentions. Data objects, groups, and annotations are supported
as artefacts. Each artefact can be associated with flow elements. Artefacts
serve only information purposes. The process flow is not influenced by
artefacts.
Data objects are represented simply by a name. The main purpose of data
object artefacts is documentation of the process. Using directed association
arcs, the modeller can represent the fact that a data object is used (or created/
modified) by an activity in the process. Paper documents and electronic
documents, as well as information on any type of medium; can be represented
by data objects.
Text annotations are used to document certain aspects of the business
process in textual form. The text is graphically associated with the object
in the business process diagram that the text explains. Group objects are
artefacts that are used to group elements of a process. Groups do not have a
formal meaning; they just serve documentation purposes. Groups may span
lanes and even pools.
Connecting objects connect flow objects, swimlanes, or artefacts. Sequence
flow is used to specify the ordering of flow objects, while message flow describes
the flow of messages between business partners represented by pools. Association
is a specific type of connecting object that is used to link artefacts to
elements in business process diagrams. The categories of notational elements
are shown Figure 4.78.
The core element set provides a small set of concepts and their graphical
representation for modelling business processes. The idea is to provide an
easy-to-use notation by concentrating on the main aspects of business process
modelling, without introducing complexity that might not be relevant.
The business process diagram shown represents a review
process for a scientific conference. The program committee chairperson is the
central role in the process; this role is represented by the PC Chair pool. There
are two additional roles involved, namely authors who submit their research
papers and reviewers who perform peer reviews for the submitted papers. Since the goal of this example is to introduce the core elements, simplifications
are in place: the business process model provides a simplified view of how
review processes are actually conducted. In addition, there are many authors
and there are also many reviewers. For convenience, just one author and one
reviewer are shown. As will be discussed below, situations in which multiple
participants are involved in the same role cannot be covered conveniently.
The pools in this example represent roles and not concrete participants in a
business process. Each role at run time has multiple concrete participants who
are actually involved in the business process instance. The BPMN standard
indicates that “a pool represents a participant in a process. It is also acts as a
“swimlane” and a graphical container for partitioning a set of activities from
other pools, usually in the context of B2B situations.”
The process starts when the PC Chair is asked to organize the scientific
program of a conference. This is reflected by the start event of the process at
the PC Chair. An event is something that ‘happens’ during the course of a
business process. These events affect the flow of the process and usually have
a cause (trigger) or an impact (result). Events are circles with open centres
to allow internal markers to differentiate different triggers or results.”
The activity enacted first is the publication of a call for papers with detailed
information on the conference, such as name and location, and also
information regarding the topics addressed by the conference. The receipt of
a message can be an event that is relevant for the process. This concept is
used in the sample process when the published call for papers activity sends
a message that the author receives. Receiving this message is represented by
the start event of the author process. The cause of this event is receiving the message and the effect is spawning the process. The same concept is used to
start the reviewer process in a later phase of the overall process.
Activities represent units of work that are actually conducted during the
course of the business process. The sample process contains, in the PC Chair
process, a set of activities that are enacted in sequence. The standard states
that “an activity is a generic term for work that a company performs. An
activity can be atomic or non-atomic (compound). The types of activities
that are a part of a process model are: process, subprocess, and task. Tasks
and subprocesses are rounded rectangles. Processes are either unbounded or
contained within a Pool.”
Business processes contain execution constraints between activities. The
simplest form of execution constraint is execution order. “A Sequence Flow is
used to show the order that activities will be performed in a process.”
More complex execution constraints are splits and joins of branches, where
different types of splits and joins are available. These structures are represented
by gateways. A gateway is graphically represented by a diamond. Split
nodes have multiple outgoing edges and join nodes have multiple incoming
edges. The notation for a gateway is identical to that for split and join nodes.
The split and join behaviour is represented only by the edges attached to
a gateway symbol. “A Gateway is used to control the divergence and convergence
of Sequence Flow. Thus, it will determine branching, forking, merging,
and joining of paths. Internal markers will indicate the type of behaviour
control.”
In the sample business process, the author pool contains a split gateway
and a join gateway. The split gateway evaluates the received notification information
and—in case the paper is accepted—triggers the preparation of the final version of the paper that will be printed in the conference proceedings.
In case the paper is rejected, the join gateway is triggered. To clarify the behaviour
of the split gateway, the outgoing sequence flows are associated with
the respective annotations.
The participants that cooperate in the context of a business process communicate
by sending and receiving messages. In business process diagrams,
messages are represented by message flow. Typically a message flow connects
an activity of one participant to an activity or an event of another participant.
Depending on the kind of business process diagram (abstract or global),
message flows can link pairs of flow objects, pools, and events. Detailed rules
on message flow connections are discussed below. “A Message Flow is used to
show the flow of messages between two participants that are prepared to send
and receive them. In BPMN, two separate Pools in the Diagram will represent
the two participants (e.g., business entities or business roles).”
The notational elements of the BPMN regarding transactional behaviour of
business processes (transaction groups, compensation flow, and cancellation)
will not be covered, because their semantics is not laid out in sufficient detail
and precision.
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec Y -- By Mathias Weske
Process Instances
Dead path elimination is used to describe the execution semantics of process instances that are represented in graph-based languages.In this example, the Accept Credit activity can only be enabled after request approval has signalled its outgoing edge. If Request Approval is executed, then the signalling is true; otherwise, the edge is signalled false. Therefore,
after the Assess Risk activity has provided a high risk factor as output value,
Accept Credit cannot be started, at least not immediately after Assess Risk
terminates.
Since the risk is assessed to be high, the start condition of the Request
Approval activity is evaluated to true. This activity is started and approves
the credit request; this approval is represented by changing the value of the
risk factor from high to low. When the edge to the Accept Credit activity is
signalled, the start condition of that activity is evaluated to true, and the
credit is granted In this process instance,
Assess Risk determines a low risk factor, so Request Approval is not required.
In this case, the edge from Assess Risk to Request Approval is signalled false,
indicating that request approval is not required.
On receiving this signal, Request Approval immediately relays a false signal
to its outgoing edge, in this case, to the Accept Credit activity. Now all incoming
edges of the Accept Credit activity have been signalled, so that the start
condition can be evaluated. Since the risk factor is low, the start condition is
evaluated to true, so that the credit can be granted.
Discussion
Graph-based workflow languages are useful for implementing business processes,
in which process activities are realized by software systems. Just as procedures realized by software systems read input parameters on their start
and write output parameters on their termination, so do process activities in
graph-based workflow languages.
Data flow can be expressed well by relating output parameters of process
activities to input parameters of follow-up activities. Since control flow is
defined by edges between activities and start conditions of activities, basic
control flow patterns, such as sequence, splits, and joins can be expressed.
Graph-based workflow languages do not support arbitrary cycles, because
in cyclic process models, dead path elimination causes problems. Advanced
control flow patterns, such as multiple instances patterns or discriminator
pattern, are also not supported by graph-based workflow languages.
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.”
Dead path elimination is used to describe the execution semantics of process instances that are represented in graph-based languages.In this example, the Accept Credit activity can only be enabled after request approval has signalled its outgoing edge. If Request Approval is executed, then the signalling is true; otherwise, the edge is signalled false. Therefore,
after the Assess Risk activity has provided a high risk factor as output value,
Accept Credit cannot be started, at least not immediately after Assess Risk
terminates.
Since the risk is assessed to be high, the start condition of the Request
Approval activity is evaluated to true. This activity is started and approves
the credit request; this approval is represented by changing the value of the
risk factor from high to low. When the edge to the Accept Credit activity is
signalled, the start condition of that activity is evaluated to true, and the
credit is granted In this process instance,
Assess Risk determines a low risk factor, so Request Approval is not required.
In this case, the edge from Assess Risk to Request Approval is signalled false,
indicating that request approval is not required.
On receiving this signal, Request Approval immediately relays a false signal
to its outgoing edge, in this case, to the Accept Credit activity. Now all incoming
edges of the Accept Credit activity have been signalled, so that the start
condition can be evaluated. Since the risk factor is low, the start condition is
evaluated to true, so that the credit can be granted.
Discussion
Graph-based workflow languages are useful for implementing business processes,
in which process activities are realized by software systems. Just as procedures realized by software systems read input parameters on their start
and write output parameters on their termination, so do process activities in
graph-based workflow languages.
Data flow can be expressed well by relating output parameters of process
activities to input parameters of follow-up activities. Since control flow is
defined by edges between activities and start conditions of activities, basic
control flow patterns, such as sequence, splits, and joins can be expressed.
Graph-based workflow languages do not support arbitrary cycles, because
in cyclic process models, dead path elimination causes problems. Advanced
control flow patterns, such as multiple instances patterns or discriminator
pattern, are also not supported by graph-based workflow languages.
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.”
Sunday, October 4, 2009
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec X -- By Mathias Weske
Graph-Based Workflow Languag
In this section, a graph-based workflow language is introduced. This language
was developed in the context of a commercial workflow management system.
It exhibits a series of interesting concepts that are not addressed by the other
process languages discussed in this chapter. Explicit representation of data
dependencies between activities and dead path elimination as a technique to
describe the execution semantics of business processes.
Process Metamodel
To illustrate this modelling language, an example of a credit request process
is shown in Figure 4.72. The activities are shown as nodes of the graph,
control flow is represented by solid arcs, and dotted arrows indicate data flow.
Data flow, for instance, between activities Collect CreditInfo and Assess Risk
indicates that Assess Risk requires data that has been created or modified by
Collect CreditInfo.
The process starts with collecting credit information, followed by an assessment
of the credit risk. Then, either the credit is accepted or a request approval activity is started. The request approval activity determines the final
decision on the credit request; it either approves the credit or rejects it. In
any case, the requestor is informed by a notification message.
Data is covered by parameters of activities; each parameter has an associated
data type. Each activity has a set of input parameters and a set of
output parameters (might be empty). Whenever the output parameter of one
activity is used as an input parameter of another activity, a data flow occurs.
Transitive data flow is often not shown in process models.
Each control flow edge has an associated condition. This condition is evaluated
after the activity from which the control flow originates has terminated.
If the condition is evaluated to true, the edge is signalled, and the follow-up
activity can be started.
The execution semantics of process graphs is based on the signalling of
edges. There are two ways of signalling: true signalling and false signalling.
When an activity terminates, the conditions of its outgoing edges are evaluated.
For each edge that evaluates to true, the follow-up activity is signalled
true. For each edge that evaluates to false, the edge is signalled false.
When all incoming edges of an activity are signalled—i.e., each edge is
signalled true or false—the start condition of that activity is evaluated. The
start condition realizes the join behaviour of that node. If the start condition
of an activity evaluates to true, it is enabled. If it evaluates to false, the activity
is not enabled. In this case, all outgoing edges of this activity are signalled
false.
By using true and false signalling, the or join problem is solved, because
each incoming edge will be signalled eventually. This technique is called dead path elimination, because paths not taken in the execution of a process are
marked with the false signal; they are therefore somehow eliminated. Unfortunately,
dead path elimination only works in the absence of loops in process
models, but the iteration of activities guided by an exit condition is supported.
Each activity is associated with a start condition. This start condition is
evaluated if all incoming control flow edges have been signalled (either true or
false). The start condition uses this information as well as input parameters
received from previous activities to decide on the state transition. If the start
condition is evaluated to true. then the activity is enabled. If it is evaluated to
false, the activity is skipped and false signals are sent to each of its outgoing
edges, regardless of the conditions attached to these edges.
To illustrate these concepts, Figure 4.73 shows a refined version of the
process model shown above, which includes parameters, start conditions, and
data flow between process activities.
The Collect CreditInfo activity is responsible for providing information
about the credit, including customer information and the amount requested.
This information is stored in the output parameter CreditInfo of the Collect
CreditInfo activity. The Assess Risk activity takes the credit information as
input parameter and assesses the risk of granting the credit. The result of this
activity is stored in an output parameter RiskFactor that is made available
to the follow-up activities Accept Credit and Request Approval.
The use of start conditions can be illustrated in this example: the Request
Approval activity can be started if the credit amount is at least 10000 euros
and the risk factor is high. This start condition takes as input the risk factor
and the credit amount, values for both of which are provided to the Request
Approval activity by the output parameters of the Assess Risk activity.
The start condition of the AcceptCredit activity makes sure that it can
only be started if the credit amount is below 10000 euros or the risk factor
is low. The credit can also be accepted if the credit was approved by the
Request Approval activity. This information is made available to the Accept
Credit activity by the output parameter RiskFactor of Request Approval.
Depending on the particular implementation used to enact this process,
either data can be transferred between activities by the business process management
system, or references to data objects can be subject to data flow, so
that the system is not burdened with large amounts of data if complex data
needs to be transferred between process activities.
To organize these concepts, a workflow metamodel is shown in Figure 4.74.
The workflow class is the central class in the metamodel; it contains workflow
objects that can be either atomic or complex, and atomic workflows can
be executed either automatically or manually. This property of workflows is reflected
in the metamodel by complex and atomic as subclasses of the workflow
class. The workflow hierarchy is represented by the nesting class, an association
class that defines the relationship between a complex workflow and a
workflow, which can be complex or atomic. Atomic workflows are also called
activities.
In this section, a graph-based workflow language is introduced. This language
was developed in the context of a commercial workflow management system.
It exhibits a series of interesting concepts that are not addressed by the other
process languages discussed in this chapter. Explicit representation of data
dependencies between activities and dead path elimination as a technique to
describe the execution semantics of business processes.
Process Metamodel
To illustrate this modelling language, an example of a credit request process
is shown in Figure 4.72. The activities are shown as nodes of the graph,
control flow is represented by solid arcs, and dotted arrows indicate data flow.
Data flow, for instance, between activities Collect CreditInfo and Assess Risk
indicates that Assess Risk requires data that has been created or modified by
Collect CreditInfo.
The process starts with collecting credit information, followed by an assessment
of the credit risk. Then, either the credit is accepted or a request approval activity is started. The request approval activity determines the final
decision on the credit request; it either approves the credit or rejects it. In
any case, the requestor is informed by a notification message.
Data is covered by parameters of activities; each parameter has an associated
data type. Each activity has a set of input parameters and a set of
output parameters (might be empty). Whenever the output parameter of one
activity is used as an input parameter of another activity, a data flow occurs.
Transitive data flow is often not shown in process models.
Each control flow edge has an associated condition. This condition is evaluated
after the activity from which the control flow originates has terminated.
If the condition is evaluated to true, the edge is signalled, and the follow-up
activity can be started.
The execution semantics of process graphs is based on the signalling of
edges. There are two ways of signalling: true signalling and false signalling.
When an activity terminates, the conditions of its outgoing edges are evaluated.
For each edge that evaluates to true, the follow-up activity is signalled
true. For each edge that evaluates to false, the edge is signalled false.
When all incoming edges of an activity are signalled—i.e., each edge is
signalled true or false—the start condition of that activity is evaluated. The
start condition realizes the join behaviour of that node. If the start condition
of an activity evaluates to true, it is enabled. If it evaluates to false, the activity
is not enabled. In this case, all outgoing edges of this activity are signalled
false.
By using true and false signalling, the or join problem is solved, because
each incoming edge will be signalled eventually. This technique is called dead path elimination, because paths not taken in the execution of a process are
marked with the false signal; they are therefore somehow eliminated. Unfortunately,
dead path elimination only works in the absence of loops in process
models, but the iteration of activities guided by an exit condition is supported.
Each activity is associated with a start condition. This start condition is
evaluated if all incoming control flow edges have been signalled (either true or
false). The start condition uses this information as well as input parameters
received from previous activities to decide on the state transition. If the start
condition is evaluated to true. then the activity is enabled. If it is evaluated to
false, the activity is skipped and false signals are sent to each of its outgoing
edges, regardless of the conditions attached to these edges.
To illustrate these concepts, Figure 4.73 shows a refined version of the
process model shown above, which includes parameters, start conditions, and
data flow between process activities.
The Collect CreditInfo activity is responsible for providing information
about the credit, including customer information and the amount requested.
This information is stored in the output parameter CreditInfo of the Collect
CreditInfo activity. The Assess Risk activity takes the credit information as
input parameter and assesses the risk of granting the credit. The result of this
activity is stored in an output parameter RiskFactor that is made available
to the follow-up activities Accept Credit and Request Approval.
The use of start conditions can be illustrated in this example: the Request
Approval activity can be started if the credit amount is at least 10000 euros
and the risk factor is high. This start condition takes as input the risk factor
and the credit amount, values for both of which are provided to the Request
Approval activity by the output parameters of the Assess Risk activity.
The start condition of the AcceptCredit activity makes sure that it can
only be started if the credit amount is below 10000 euros or the risk factor
is low. The credit can also be accepted if the credit was approved by the
Request Approval activity. This information is made available to the Accept
Credit activity by the output parameter RiskFactor of Request Approval.
Depending on the particular implementation used to enact this process,
either data can be transferred between activities by the business process management
system, or references to data objects can be subject to data flow, so
that the system is not burdened with large amounts of data if complex data
needs to be transferred between process activities.
To organize these concepts, a workflow metamodel is shown in Figure 4.74.
The workflow class is the central class in the metamodel; it contains workflow
objects that can be either atomic or complex, and atomic workflows can
be executed either automatically or manually. This property of workflows is reflected
in the metamodel by complex and atomic as subclasses of the workflow
class. The workflow hierarchy is represented by the nesting class, an association
class that defines the relationship between a complex workflow and a
workflow, which can be complex or atomic. Atomic workflows are also called
activities.
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec W -- By Mathias Weske
N-out-of-M Join
The N-out-of-M join has M incoming branches, and the follow-up activity
is triggered once N branches have completed. This behaviour can in part be
expressed in YAWL by multiple instances, as shown in Figure 4.67. The idea
is to start M instances and to define a threshold of N instances, so once N
instances have completed, the multiple instances task completes.
While multiple instances can be used to represent an N-out-of-M join
with identical activities, this approach falls short of representing concurrent
branches comprised of different activities. Therefore, only a very specific type
of N-out-of-M join can be realized in YAWL using multiple instances. Hence,
the N-out-of-M join is not completely expressed, since it should be able to
synchronize different branches of a process and not only multiple instances of
a given task.
Multiple Instances Tasks
Yet Another Workflow Language is tailored towards supporting multiple instances
patterns. The multiple instances without synchronization pattern is
shown in Figure 4.68. In this example, A spawns two concurrent branches,
consisting of multiple instances of task B and a single instance of task C.
The multiple instances of task B are not synchronized, which means that
B cannot have outgoing edges, because outgoing edges would indicate that
the follow-up activity can only be started if the task instances of task B have
completed.
The multiple instances with design time knowledge is shown in Figure 4.69.
In this pattern, the number of instances of task B is known at design time.
Therefore, the multiple instances attributes of task B can be set accordingly.
By setting the minimum number of instances, the maximum number of
instances, and the threshold to n, where n is the number of required instances
of task B, this pattern can be realized. The control flow edge from B to C
indicates that C can only start when all instances of task B have completed.
If the number of instances is known only at run time, but before the first instance
of B starts, a function is required to determine the number of instances
of B, as shown in Figure 4.70. This difference with the previous pattern is reflected
by using q for the number of instances, where q is determined at run time of the process instance, but before the start of multiple instances task
B. For example, the number of line items in an order can be determined at
run time. In the example, q reflects this number, so that exactly q instances
of task B are performed.
Figure 4.71 shows multiple instances without a priori run time knowledge.
In this pattern, the number of instances of B becomes available only while
instances of task B run. This means that new instances of B need to be
created dynamically. Parameters q1 and q2, and also the threshold value, can
be subject to change while task instances run, providing maximum flexibility
in determining the number of instances of a multiple instances task.
Discussion
Yet Another Workflow Language has a number of advantages, but also some
drawbacks. The graphical representation of process models is closely related to workflow nets, so that people familiar with workflow nets can use YAWL
immediately.
The execution semantics of YAWL is well-specified by state transition
systems. The representation of executing tasks by state transition systems
combines state transition diagrams—to describe the dynamic behaviour of
process activities, as shown in Figure 3.10—with Petri net markings.
One of the conceptual issues when representing business process activities
by Petri nets is the timeliness of the transition firing. Business process activities
take time, they have a start, they are active for a time interval, before
they complete. In contrast to Petri nets, the durations of process activities
are well captured by state transition systems in YAWL. At the same time,
process instances are represented by tokens, similar to markings in Petri nets.
YAWL has excellent support for multiple instances patterns. The specification
of multiple instances actually goes one step ahead of the control flow
patterns in that it allows us to define a threshold of completed task instances.
The construct to model multiple instances tasks in YAWL is very useful and
has many applications in real-world business processes.
The semantics of multiple instances tasks is handled very well by state
transition systems in YAWL. The add transition allows the dynamic creation
of new task instances while task instances are active; the exit transition can
realize the threshold semantics by cancelling all remaining task instances when
the threshold number of completed instances has been reached.
The state transition systems also capture in a very elegant way composite
tasks. By recursively applying the concept, subprocesses can easily be attached
to composite tasks. The multiple-instances property is orthogonal to
tasks being composite, so that any composite task can at the same time have
multiple instances.
The remove function rem associated to tasks allows us defining regions
of the workflow specification from where to withdraw tokens when the task
completes. Conceptually it is rather simple to “remove tokens” from process
instances to cancel tasks. It becomes much harder, however, when we look at
the concrete realization of these tasks.
In real-world business processes, many tasks are realized by software systems.
Removing a token from a task means to cancel the invocation of the
system. If the software system has transactional capabilities then the transaction
can be aborted, rolling back the software system to a consistent state.
Not all software systems used in business processes are, however, are transactional. In this case, the software might have already performed its work
partially at the time, the token is removed. In such situations, it is unclear,
how the business process management system should behave. In many cases,
human involvement is required to solve the resulting problems manually.
We have already discussed in some detail the weaknesses of YAWL in
representing some advanced control flow patterns, including the discriminator
and the M-out-of-N join. Despite these drawbacks, YAWL is a well-designed
process modelling language that also comes with prototypical implementations
for modelling and enactment, as referenced in the bibliographical notes.
The N-out-of-M join has M incoming branches, and the follow-up activity
is triggered once N branches have completed. This behaviour can in part be
expressed in YAWL by multiple instances, as shown in Figure 4.67. The idea
is to start M instances and to define a threshold of N instances, so once N
instances have completed, the multiple instances task completes.
While multiple instances can be used to represent an N-out-of-M join
with identical activities, this approach falls short of representing concurrent
branches comprised of different activities. Therefore, only a very specific type
of N-out-of-M join can be realized in YAWL using multiple instances. Hence,
the N-out-of-M join is not completely expressed, since it should be able to
synchronize different branches of a process and not only multiple instances of
a given task.
Multiple Instances Tasks
Yet Another Workflow Language is tailored towards supporting multiple instances
patterns. The multiple instances without synchronization pattern is
shown in Figure 4.68. In this example, A spawns two concurrent branches,
consisting of multiple instances of task B and a single instance of task C.
The multiple instances of task B are not synchronized, which means that
B cannot have outgoing edges, because outgoing edges would indicate that
the follow-up activity can only be started if the task instances of task B have
completed.
The multiple instances with design time knowledge is shown in Figure 4.69.
In this pattern, the number of instances of task B is known at design time.
Therefore, the multiple instances attributes of task B can be set accordingly.
By setting the minimum number of instances, the maximum number of
instances, and the threshold to n, where n is the number of required instances
of task B, this pattern can be realized. The control flow edge from B to C
indicates that C can only start when all instances of task B have completed.
If the number of instances is known only at run time, but before the first instance
of B starts, a function is required to determine the number of instances
of B, as shown in Figure 4.70. This difference with the previous pattern is reflected
by using q for the number of instances, where q is determined at run time of the process instance, but before the start of multiple instances task
B. For example, the number of line items in an order can be determined at
run time. In the example, q reflects this number, so that exactly q instances
of task B are performed.
Figure 4.71 shows multiple instances without a priori run time knowledge.
In this pattern, the number of instances of B becomes available only while
instances of task B run. This means that new instances of B need to be
created dynamically. Parameters q1 and q2, and also the threshold value, can
be subject to change while task instances run, providing maximum flexibility
in determining the number of instances of a multiple instances task.
Discussion
Yet Another Workflow Language has a number of advantages, but also some
drawbacks. The graphical representation of process models is closely related to workflow nets, so that people familiar with workflow nets can use YAWL
immediately.
The execution semantics of YAWL is well-specified by state transition
systems. The representation of executing tasks by state transition systems
combines state transition diagrams—to describe the dynamic behaviour of
process activities, as shown in Figure 3.10—with Petri net markings.
One of the conceptual issues when representing business process activities
by Petri nets is the timeliness of the transition firing. Business process activities
take time, they have a start, they are active for a time interval, before
they complete. In contrast to Petri nets, the durations of process activities
are well captured by state transition systems in YAWL. At the same time,
process instances are represented by tokens, similar to markings in Petri nets.
YAWL has excellent support for multiple instances patterns. The specification
of multiple instances actually goes one step ahead of the control flow
patterns in that it allows us to define a threshold of completed task instances.
The construct to model multiple instances tasks in YAWL is very useful and
has many applications in real-world business processes.
The semantics of multiple instances tasks is handled very well by state
transition systems in YAWL. The add transition allows the dynamic creation
of new task instances while task instances are active; the exit transition can
realize the threshold semantics by cancelling all remaining task instances when
the threshold number of completed instances has been reached.
The state transition systems also capture in a very elegant way composite
tasks. By recursively applying the concept, subprocesses can easily be attached
to composite tasks. The multiple-instances property is orthogonal to
tasks being composite, so that any composite task can at the same time have
multiple instances.
The remove function rem associated to tasks allows us defining regions
of the workflow specification from where to withdraw tokens when the task
completes. Conceptually it is rather simple to “remove tokens” from process
instances to cancel tasks. It becomes much harder, however, when we look at
the concrete realization of these tasks.
In real-world business processes, many tasks are realized by software systems.
Removing a token from a task means to cancel the invocation of the
system. If the software system has transactional capabilities then the transaction
can be aborted, rolling back the software system to a consistent state.
Not all software systems used in business processes are, however, are transactional. In this case, the software might have already performed its work
partially at the time, the token is removed. In such situations, it is unclear,
how the business process management system should behave. In many cases,
human involvement is required to solve the resulting problems manually.
We have already discussed in some detail the weaknesses of YAWL in
representing some advanced control flow patterns, including the discriminator
and the M-out-of-N join. Despite these drawbacks, YAWL is a well-designed
process modelling language that also comes with prototypical implementations
for modelling and enactment, as referenced in the bibliographical notes.
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec V -- By Mathias Weske
Nested Processes
The approach of defining the execution semantics of process instances by
state transition diagrams can be extended conveniently to nested processes.
Figure 4.64 shows the extended state transition diagrams for composite tasks.
When an instance of a composite task is started, one token is put on the
exec state, indicating that the task instance is now running. The detailed
status of the subprocess is shown in the lower part of Figure 4.64. Starting
the task also puts a token in the initial condition of the subprocess, marked
by imap.
The ellipsis summarizes the state transition diagram of the subprocess
(without the initial and the final condition, of course). When the subprocess
terminates, the condition omap is reached, and the complete transition can
fire, completing an instance of the subprocess.
The extension of the state transition diagram to composite tasks is orthogonal
to multiple instances tasks, so that by adding an add transition,
multiple instances of composite tasks, and therefore also multiple instances of
subprocesses, can be represented properly.
The example discussed above is used to investigate the execution of composite
task F realized by the extended workflow net W2, shown in Figure 4.62.
A partial state transition diagram focusing on the state of the composite task
is shown in Figure 4.65.
When an instance of the composite task F is executed, a token is put on
the exec state of the state transition diagram of that task. In addition, the
subprocess needs to be started, represented by a token in the start condition
of the extended workflow net that F maps to; since map(F) = W2, a token is
put on i2, the start condition of W2.
The token at i2 enables the subprocess. The first task to execute is H.
The lower part of Figure 4.65 shows the state during the execution of the
subprocess where task H is currently executing. When H terminates, a token
is put on state cHI , so that the execution of the subprocess can continue with the multiple instances task I. This example shows quite well the recursive
application of state transition diagrams for composite tasks.
Advanced Control Flow Patterns
Having discussed how the execution semantics is specified, we can investigate
advanced control flow patterns.
Discriminator
The discriminator is a specific type of join node that uses the first signal it
receives for triggering the outgoing task. The other signals are ignored. When
signals have been received from all incoming branches, the discriminator resets
itself. The authors of Yet AnotherWorkflow Language propose to simulate this
behaviour of the discriminator pattern by an exclusive or join in combination
with a cancellation region in the way shown in Figure 4.66.
In this example, assume that tasks B, C, and D are active concurrently,
following the and split task A. Assuming that B completes first, the discriminator
fires, and E is triggered. Since E is an exclusive or join task, it can
be executed. Since a cancellation region is defined for E, E deletes all tokens
from the region. In this case, tokens are withdrawn from tasks C and D.
This simulation of the discriminator pattern with exclusive or join and
cancellation region is now evaluated with respect to the semantics of the
discriminator. The simulation exhibits significant semantic differences with
the specification of the discriminator. First of all, the discriminator does not
cancel running activities.
All activities on the incoming branches of the discriminator can complete
without disturbances; only their termination will be ignored. Secondly, the
cancellation of the activities takes place on the termination of the task instance
E. So the activities are cancelled not before E starts, but after E terminates.
As a result, the proposed representation of the discriminator pattern in YAWL
is not completely satisfying.
The approach of defining the execution semantics of process instances by
state transition diagrams can be extended conveniently to nested processes.
Figure 4.64 shows the extended state transition diagrams for composite tasks.
When an instance of a composite task is started, one token is put on the
exec state, indicating that the task instance is now running. The detailed
status of the subprocess is shown in the lower part of Figure 4.64. Starting
the task also puts a token in the initial condition of the subprocess, marked
by imap.
The ellipsis summarizes the state transition diagram of the subprocess
(without the initial and the final condition, of course). When the subprocess
terminates, the condition omap is reached, and the complete transition can
fire, completing an instance of the subprocess.
The extension of the state transition diagram to composite tasks is orthogonal
to multiple instances tasks, so that by adding an add transition,
multiple instances of composite tasks, and therefore also multiple instances of
subprocesses, can be represented properly.
The example discussed above is used to investigate the execution of composite
task F realized by the extended workflow net W2, shown in Figure 4.62.
A partial state transition diagram focusing on the state of the composite task
is shown in Figure 4.65.
When an instance of the composite task F is executed, a token is put on
the exec state of the state transition diagram of that task. In addition, the
subprocess needs to be started, represented by a token in the start condition
of the extended workflow net that F maps to; since map(F) = W2, a token is
put on i2, the start condition of W2.
The token at i2 enables the subprocess. The first task to execute is H.
The lower part of Figure 4.65 shows the state during the execution of the
subprocess where task H is currently executing. When H terminates, a token
is put on state cHI , so that the execution of the subprocess can continue with the multiple instances task I. This example shows quite well the recursive
application of state transition diagrams for composite tasks.
Advanced Control Flow Patterns
Having discussed how the execution semantics is specified, we can investigate
advanced control flow patterns.
Discriminator
The discriminator is a specific type of join node that uses the first signal it
receives for triggering the outgoing task. The other signals are ignored. When
signals have been received from all incoming branches, the discriminator resets
itself. The authors of Yet AnotherWorkflow Language propose to simulate this
behaviour of the discriminator pattern by an exclusive or join in combination
with a cancellation region in the way shown in Figure 4.66.
In this example, assume that tasks B, C, and D are active concurrently,
following the and split task A. Assuming that B completes first, the discriminator
fires, and E is triggered. Since E is an exclusive or join task, it can
be executed. Since a cancellation region is defined for E, E deletes all tokens
from the region. In this case, tokens are withdrawn from tasks C and D.
This simulation of the discriminator pattern with exclusive or join and
cancellation region is now evaluated with respect to the semantics of the
discriminator. The simulation exhibits significant semantic differences with
the specification of the discriminator. First of all, the discriminator does not
cancel running activities.
All activities on the incoming branches of the discriminator can complete
without disturbances; only their termination will be ignored. Secondly, the
cancellation of the activities takes place on the termination of the task instance
E. So the activities are cancelled not before E starts, but after E terminates.
As a result, the proposed representation of the discriminator pattern in YAWL
is not completely satisfying.
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec U -- By Mathias Weske
Process Instances
The discussion of state transition diagrams is extended from a localized view
of individual tasks to a process view. In order to do this, a number of definitions
are required. The first definition extends the compact representation
of extended workflow nets in a way that it syntactically complies with the
workflow net definition: wherever there is an arc connecting two tasks in an
extended workflow net, a new condition is added and the arcs are modified
accordingly.
Definition
Let N = (C, i, o, T, F, split, join, rem, nofi) be an extended
workflow net.
• Cext
N is an extended condition set, such that
Cext
= C [ {cij |(ti, tj) 2 F \ T × T}
The extended condition set and the extended flow relation are shown in
Figure 4.62. Observe that for each direct connection between tasks in the
original extended workflow net, one condition and the respective arcs are
added: Cext
1 = {i1, cAB, cBC, cCD, cCE, cCF , cDG, cEG, cFG, o1}.
The extended flow relation Fext
1 is given by the arrows in Figure 4.62. Analogously,
the extended condition set and the extended flow relation for W2 are
given by Cext
2 = {i2, cHI , o2} and Fext = {(i2,H), (H, cHI ), (cHI , I), (I, o2)}.
Since there are multiple process instances for which tasks are being executed,
the identity of these cases needs to be taken into account when describing
the state of tasks and their task instances. Therefore, the following
assumptions concerning process identifiers are made.
Each process instance has a unique case identifier.
Each task instance has a unique task instance identifier.
Identifiers are structured to allow for child/parent relationships. This
means that each task instance identifier can be associated with its process
instance or case.
I denotes the set of identifiers.
Based on case identifiers and the state transition system discussed above, a
workflow state can be characterized as a bag of tokens, where each token has
condition and a case identifier.
The discussion of state transition diagrams is extended from a localized view
of individual tasks to a process view. In order to do this, a number of definitions
are required. The first definition extends the compact representation
of extended workflow nets in a way that it syntactically complies with the
workflow net definition: wherever there is an arc connecting two tasks in an
extended workflow net, a new condition is added and the arcs are modified
accordingly.
Definition
Let N = (C, i, o, T, F, split, join, rem, nofi) be an extended
workflow net.
• Cext
N is an extended condition set, such that
Cext
= C [ {cij |(ti, tj) 2 F \ T × T}
The extended condition set and the extended flow relation are shown in
Figure 4.62. Observe that for each direct connection between tasks in the
original extended workflow net, one condition and the respective arcs are
added: Cext
1 = {i1, cAB, cBC, cCD, cCE, cCF , cDG, cEG, cFG, o1}.
The extended flow relation Fext
1 is given by the arrows in Figure 4.62. Analogously,
the extended condition set and the extended flow relation for W2 are
given by Cext
2 = {i2, cHI , o2} and Fext = {(i2,H), (H, cHI ), (cHI , I), (I, o2)}.
Since there are multiple process instances for which tasks are being executed,
the identity of these cases needs to be taken into account when describing
the state of tasks and their task instances. Therefore, the following
assumptions concerning process identifiers are made.
Each process instance has a unique case identifier.
Each task instance has a unique task instance identifier.
Identifiers are structured to allow for child/parent relationships. This
means that each task instance identifier can be associated with its process
instance or case.
I denotes the set of identifiers.
Based on case identifiers and the state transition system discussed above, a
workflow state can be characterized as a bag of tokens, where each token has
condition and a case identifier.
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec T -- By Mathias Weske
Simple Control Flow Patterns
We now discuss how YAWL supports control flow patterns. It is obvious that
the basic control flow patterns are directly supported. The sequence pattern
is shown in Figure 4.55, where two alternative representations are shown: in
extended workflow nets, the control flow edge can directly connect A and B, so
that the condition place can be dropped. Notice that these two representations
are equivalent, i.e., any extended workflow net with conditions connecting two
tasks can be transformed to an equivalent extended workflow net with direct
connections, and vice versa.
And split and and join patterns are shown in part (a) of Figure 4.56.
On completion of the split task A (split(A) = and), tasks B, C, and D are enabled, and the three tasks can be executed concurrently. The join task
E (join(E) = and) is enabled only if B, C, and D have been completed.
The exclusive or split shown in part (b) of that figure selects exactly one
alternative, so that E can start if exactly one branch is completed. In this
case, split(A)= join(E) = Xor.
Workflow specifications require additional information that allows evaluating
conditions to decide, for instance, which path in an exclusive or split
to take. These conditions, however, are not part of the formal specification of
workflow specifications in YAWL.
Figure 4.57 shows the inclusive or split. From a notation point of view,
the or split and the or join can be defined similarly to the other control flow
structures. However, the decision on when the or join is activated is complex.
These aspects will be discussed in more detail when the execution semantics
of YAWL is investigated.
Execution Semantics
The execution semantics in YAWL is defined by state transition systems.
Each workflow specification has a corresponding state transition system that describes the execution semantics of process instances based on that workflow
specification. The rules implemented in this state transition system are of
a generic nature, so that they can be applied to any workflow specification
expressed in YAWL.
The overall idea for expressing the execution semantics is that each task
is represented by an individual state transition diagram. A state transition
diagram of a task specifies its current state. The state of the process instance
is then represented by the combined state of all tasks involved in the process
instance plus conditions that are currently met at the process level.
Task Instances
State transition diagrams consist of conditions represented by circles and transitions
represented by rectangles. Since multiple instances tasks can take more
states than single instance tasks, single instance tasks are investigated first.
The state transition diagram for single instance tasks is shown in Figure 4.58.
In this section, task instances are investigated before state transition diagrams
at the process level are investigated. To stay in line with terminology
in YAWL, this section uses the term task instance, which describes the same
concept as the term activity instance this book has used so far.
The following conditions are available for a task instance:
enabled: Task instance is enabled, but not yet executing
exec: Task instance is currently executing
completed: Task instance is completed
active: Task instance is currently active
The execution semantics of a task instance is specified by the state transition
diagram shown in Figure 4.58. Despite the fact that transitions do not use Petri net transition semantics, it is appropriate to discuss the basic operation
of state transition diagrams with Petri net terminology.
When the task instance is entered, a token is put on the active and enabled
conditions. An enabled task instance can start. Once the start transition fires,
the task instance enters the exec condition.When the task instance completes,
it enters the completed condition; finally, the task instance is terminated by
firing the exit transition. Note that the active condition and the exit transition
are somewhat artificial for single instance tasks; their role will become clear
when multiple instances tasks are addressed.
To summarize, the state transitions for a task t have the following semantics.
The state transition enable checks the join condition of t; t might be
a join node of type And, Xor, or Or, as specified by join(t). When the enable
transition occurs, the input tokens as defined by the join condition are
removed from the input conditions of the task.
In case of a single instance task, one token is put in the active condition and
one token is put in the enabled condition. When the start transition occurs,
one token is removed from the enabled condition and one token is added to
the exec condition. The task instance is now executing. The termination of a
task instance is represented by the completed transition in the state transition
diagram. In this case, one token is removed from the exec condition and one
token is added to the completed condition.
The exit transition is specifically relevant for multiple instances tasks,
because it fires if the termination condition of a multiple instances task is met.
In case there is a cancellation region defined for task t, the exit transition also
removes tokens from the cancellation region of the workflow specification, as
defined by rem(t). Finally, the exit state transition generates tokens depending
on its split behaviour, defined by split(t) The state transition diagram for multiple instances tasks is shown in Figure
4.59. There is an additional state transition, add, that spawns new task
instances. Arcs drawn in bold indicate that multiple tokens can flow along
these arcs.
To discuss the execution semantics of a multiple instances task, the static
case is considered first. In this case, all task instances are created up front,
and no task instances can be added while instances of the task run. Consider
a multiple instances task with [4, 6, 4, s]: four to six task instances are created,
and the multiple instances task terminates when the threshold of four
instances that have completed is reached.
Consider a process instance in which the enable transition creates five
task instances by putting five tokens in the active condition and five tokens
in the enabled condition. For each token in the enabled condition, the start
transition can fire.
The termination of the overall task (completion of the required task instances)
is realized by the exit transition. Exit can fire if the threshold number
of tokens are in the completed condition, indicating the completion of a
sufficient number of task instances. Assuming four task instances have been
completed, the threshold value is reached, and the exit transition removes
four tokens from the completed condition and four tokens from the active
condition.
However, since five task instances have been started, there is one additional
task instance present. This task instance is represented by one token in the
active condition and one token in either the enabled or the exec condition.
This task instance might also have already entered the completed condition.
In the example shown in Figure 4.60, the task instance is still executing To implement a proper completion of the task, the exit transition needs
to delete all remaining tokens from the state transition system of the task. In
this case, two tokens that collectively represent the fifth (and not required)
task instance are removed, completing the task and all its task instances, of
which four have been performed completely.
In the example discussed, the number of task instances was statically defined,
so that the dynamic creation of new task instances was not possible. In
the following example, additional task instances can be created at run time.
Let [3, 10, 8, d] define the multiple instances property of the task. This means
that there are at least three instances, at most ten instances, and the threshold
is eight completed task instances.
Assume that three task instances are started up front. In this case, the
enable transition puts three tokens in the active condition and three tokens
in the enabled condition. The enabled task instances can start.
The dynamic creation of new task instances is represented by the state
transition add. As soon as there is one task instance in the active condition,
the add transition can fire. When it fires, an additional token is put in the
enabled and active conditions, representing the creation of a new task instance
at run time. In this way add realizes the dynamic creation of task instances at
run time. Using this feature, YAWL directly supports the multiple instances
without a priori run time knowledge control flow pattern, introduced in Section
4.1.
The other parts of the state transition system remain unchanged, so that
the originally created task instances and the dynamically created task instances
are handled equivalently: the exit transition can fire if there are a
sufficient number of completed task instances available, in this case, eight.
The actual trigger for creating new task instances is not in the scope of
the state transition system. It is assumed that the user or a software system
spawns new task instances as desired. The state transition system is capable
of monitoring the state of a task, including the states of its task instances.
We now discuss how YAWL supports control flow patterns. It is obvious that
the basic control flow patterns are directly supported. The sequence pattern
is shown in Figure 4.55, where two alternative representations are shown: in
extended workflow nets, the control flow edge can directly connect A and B, so
that the condition place can be dropped. Notice that these two representations
are equivalent, i.e., any extended workflow net with conditions connecting two
tasks can be transformed to an equivalent extended workflow net with direct
connections, and vice versa.
And split and and join patterns are shown in part (a) of Figure 4.56.
On completion of the split task A (split(A) = and), tasks B, C, and D are enabled, and the three tasks can be executed concurrently. The join task
E (join(E) = and) is enabled only if B, C, and D have been completed.
The exclusive or split shown in part (b) of that figure selects exactly one
alternative, so that E can start if exactly one branch is completed. In this
case, split(A)= join(E) = Xor.
Workflow specifications require additional information that allows evaluating
conditions to decide, for instance, which path in an exclusive or split
to take. These conditions, however, are not part of the formal specification of
workflow specifications in YAWL.
Figure 4.57 shows the inclusive or split. From a notation point of view,
the or split and the or join can be defined similarly to the other control flow
structures. However, the decision on when the or join is activated is complex.
These aspects will be discussed in more detail when the execution semantics
of YAWL is investigated.
Execution Semantics
The execution semantics in YAWL is defined by state transition systems.
Each workflow specification has a corresponding state transition system that describes the execution semantics of process instances based on that workflow
specification. The rules implemented in this state transition system are of
a generic nature, so that they can be applied to any workflow specification
expressed in YAWL.
The overall idea for expressing the execution semantics is that each task
is represented by an individual state transition diagram. A state transition
diagram of a task specifies its current state. The state of the process instance
is then represented by the combined state of all tasks involved in the process
instance plus conditions that are currently met at the process level.
Task Instances
State transition diagrams consist of conditions represented by circles and transitions
represented by rectangles. Since multiple instances tasks can take more
states than single instance tasks, single instance tasks are investigated first.
The state transition diagram for single instance tasks is shown in Figure 4.58.
In this section, task instances are investigated before state transition diagrams
at the process level are investigated. To stay in line with terminology
in YAWL, this section uses the term task instance, which describes the same
concept as the term activity instance this book has used so far.
The following conditions are available for a task instance:
enabled: Task instance is enabled, but not yet executing
exec: Task instance is currently executing
completed: Task instance is completed
active: Task instance is currently active
The execution semantics of a task instance is specified by the state transition
diagram shown in Figure 4.58. Despite the fact that transitions do not use Petri net transition semantics, it is appropriate to discuss the basic operation
of state transition diagrams with Petri net terminology.
When the task instance is entered, a token is put on the active and enabled
conditions. An enabled task instance can start. Once the start transition fires,
the task instance enters the exec condition.When the task instance completes,
it enters the completed condition; finally, the task instance is terminated by
firing the exit transition. Note that the active condition and the exit transition
are somewhat artificial for single instance tasks; their role will become clear
when multiple instances tasks are addressed.
To summarize, the state transitions for a task t have the following semantics.
The state transition enable checks the join condition of t; t might be
a join node of type And, Xor, or Or, as specified by join(t). When the enable
transition occurs, the input tokens as defined by the join condition are
removed from the input conditions of the task.
In case of a single instance task, one token is put in the active condition and
one token is put in the enabled condition. When the start transition occurs,
one token is removed from the enabled condition and one token is added to
the exec condition. The task instance is now executing. The termination of a
task instance is represented by the completed transition in the state transition
diagram. In this case, one token is removed from the exec condition and one
token is added to the completed condition.
The exit transition is specifically relevant for multiple instances tasks,
because it fires if the termination condition of a multiple instances task is met.
In case there is a cancellation region defined for task t, the exit transition also
removes tokens from the cancellation region of the workflow specification, as
defined by rem(t). Finally, the exit state transition generates tokens depending
on its split behaviour, defined by split(t) The state transition diagram for multiple instances tasks is shown in Figure
4.59. There is an additional state transition, add, that spawns new task
instances. Arcs drawn in bold indicate that multiple tokens can flow along
these arcs.
To discuss the execution semantics of a multiple instances task, the static
case is considered first. In this case, all task instances are created up front,
and no task instances can be added while instances of the task run. Consider
a multiple instances task with [4, 6, 4, s]: four to six task instances are created,
and the multiple instances task terminates when the threshold of four
instances that have completed is reached.
Consider a process instance in which the enable transition creates five
task instances by putting five tokens in the active condition and five tokens
in the enabled condition. For each token in the enabled condition, the start
transition can fire.
The termination of the overall task (completion of the required task instances)
is realized by the exit transition. Exit can fire if the threshold number
of tokens are in the completed condition, indicating the completion of a
sufficient number of task instances. Assuming four task instances have been
completed, the threshold value is reached, and the exit transition removes
four tokens from the completed condition and four tokens from the active
condition.
However, since five task instances have been started, there is one additional
task instance present. This task instance is represented by one token in the
active condition and one token in either the enabled or the exec condition.
This task instance might also have already entered the completed condition.
In the example shown in Figure 4.60, the task instance is still executing To implement a proper completion of the task, the exit transition needs
to delete all remaining tokens from the state transition system of the task. In
this case, two tokens that collectively represent the fifth (and not required)
task instance are removed, completing the task and all its task instances, of
which four have been performed completely.
In the example discussed, the number of task instances was statically defined,
so that the dynamic creation of new task instances was not possible. In
the following example, additional task instances can be created at run time.
Let [3, 10, 8, d] define the multiple instances property of the task. This means
that there are at least three instances, at most ten instances, and the threshold
is eight completed task instances.
Assume that three task instances are started up front. In this case, the
enable transition puts three tokens in the active condition and three tokens
in the enabled condition. The enabled task instances can start.
The dynamic creation of new task instances is represented by the state
transition add. As soon as there is one task instance in the active condition,
the add transition can fire. When it fires, an additional token is put in the
enabled and active conditions, representing the creation of a new task instance
at run time. In this way add realizes the dynamic creation of task instances at
run time. Using this feature, YAWL directly supports the multiple instances
without a priori run time knowledge control flow pattern, introduced in Section
4.1.
The other parts of the state transition system remain unchanged, so that
the originally created task instances and the dynamically created task instances
are handled equivalently: the exit transition can fire if there are a
sufficient number of completed task instances available, in this case, eight.
The actual trigger for creating new task instances is not in the scope of
the state transition system. It is assumed that the user or a software system
spawns new task instances as desired. The state transition system is capable
of monitoring the state of a task, including the states of its task instances.
Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec S -- By Mathias Weske
Temporal Aspects
Activities in workflow nets are represented by transitions. When a transition
fires, it withdraws tokens from its input places and puts tokens in its
output places, depending on the decision made by the transition. These steps
(withdrawing tokens, determining where to put tokens, and finally putting the
tokens) in Petri nets are represented by the firing of the transition, which does
not consume time. This assumption is in contradiction with activity instances,
which do take time. The processing of an insurance claim, the preparation of
a quote, and the checking of a warehouse inventory are activities that take
time.
The fact that activities take time is also reflected by the state transition diagram
of activities. In state transition diagrams, state transitions are triggered
by events. For instance, the completion of an enter customer order activity
enables a check inventory activity. This means that activity instances have
lifecycles that consist of a number of steps, from their instantiation, their enabling,
and their execution to their termination. In workflow nets, these steps
are not represented, because firing puts an activity from the enabled state
immediately into the terminated state.
This contradiction is partly solved in workflow management systems using
Petri nets. Assume that a business activity represented by a transition is
realized by invoking a piece of software. The invocation of the software is
often represented by the firing of the transition. However, software procedures
also take time. In addition, the follow-up activities should not be enabled
when the previous activity is started, but when it completes. If an activity is
implemented in software, then the follow-up activities should not be enabled
when the software is invoked, but after it has completed.
The timeliness of activity instances represented by workflow nets also implies
that no events can occur during an activity instance. In real-world business
processes, however, this is not true. Many things do happen during the
execution of a business process activity. For instance, while an inventory is being
checked, new items may enter the warehouse. These issues are not covered
by workflow nets; it is the responsibility of business process management tools
to solve issues that might result from these abstractions in workflow nets.
Yet Another Workflow Language
The motivation for the development of Yet Another Workflow Language
(YAWL) was the lack of a process language that directly supported all control
flow patterns. While it uses workflow nets as a major ingredient, the execution
semantics of process instances is specified by state transition systems and not
by Petri nets. In this section, YAWL and its support for control flow patterns,
as well as its execution semantics, are investigated.
While Petri nets provide a sound formalism for expressing most control
flow patterns, the following deficiencies have been identified that hamper the
expression of the full set of control flow patterns.
• Multiple Instances: Multiple instances patterns describe business processes
with multiple instances of specific activities. The number of activity instances
of one particular activity model might not be known at design time.
Petri nets do not provide adequate means to describe multiple instances
tasks.
• Advanced Synchronization Patterns: Petri nets can directly express and
split/join and exclusive or split/join using places, transitions and firing
rules of traditional Petri nets. Advanced synchronization patterns such as,
for instance, or split and or join and discriminator patterns, however,
cannot be conveniently expressed in Petri nets.
• Nonlocal Firing Behaviour: The enabling of activities in a business process
is based onlocal knowledge only. In the context of Petri nets, the presence
of tokens in the input places of a transition indicates activation of that
transition. In business processes, there are situations in which nonlocal
parts of the process are affected by a decision. For instance, the cancellation
pattern somehow vacuum-cleans defined parts of the Petri net when being
activated. If used to cancel a customer order, different activities in different
parts of the Petri net need to be cancelled in order to cancel the overall
customer order.
Activities in workflow nets are represented by transitions. When a transition
fires, it withdraws tokens from its input places and puts tokens in its
output places, depending on the decision made by the transition. These steps
(withdrawing tokens, determining where to put tokens, and finally putting the
tokens) in Petri nets are represented by the firing of the transition, which does
not consume time. This assumption is in contradiction with activity instances,
which do take time. The processing of an insurance claim, the preparation of
a quote, and the checking of a warehouse inventory are activities that take
time.
The fact that activities take time is also reflected by the state transition diagram
of activities. In state transition diagrams, state transitions are triggered
by events. For instance, the completion of an enter customer order activity
enables a check inventory activity. This means that activity instances have
lifecycles that consist of a number of steps, from their instantiation, their enabling,
and their execution to their termination. In workflow nets, these steps
are not represented, because firing puts an activity from the enabled state
immediately into the terminated state.
This contradiction is partly solved in workflow management systems using
Petri nets. Assume that a business activity represented by a transition is
realized by invoking a piece of software. The invocation of the software is
often represented by the firing of the transition. However, software procedures
also take time. In addition, the follow-up activities should not be enabled
when the previous activity is started, but when it completes. If an activity is
implemented in software, then the follow-up activities should not be enabled
when the software is invoked, but after it has completed.
The timeliness of activity instances represented by workflow nets also implies
that no events can occur during an activity instance. In real-world business
processes, however, this is not true. Many things do happen during the
execution of a business process activity. For instance, while an inventory is being
checked, new items may enter the warehouse. These issues are not covered
by workflow nets; it is the responsibility of business process management tools
to solve issues that might result from these abstractions in workflow nets.
Yet Another Workflow Language
The motivation for the development of Yet Another Workflow Language
(YAWL) was the lack of a process language that directly supported all control
flow patterns. While it uses workflow nets as a major ingredient, the execution
semantics of process instances is specified by state transition systems and not
by Petri nets. In this section, YAWL and its support for control flow patterns,
as well as its execution semantics, are investigated.
While Petri nets provide a sound formalism for expressing most control
flow patterns, the following deficiencies have been identified that hamper the
expression of the full set of control flow patterns.
• Multiple Instances: Multiple instances patterns describe business processes
with multiple instances of specific activities. The number of activity instances
of one particular activity model might not be known at design time.
Petri nets do not provide adequate means to describe multiple instances
tasks.
• Advanced Synchronization Patterns: Petri nets can directly express and
split/join and exclusive or split/join using places, transitions and firing
rules of traditional Petri nets. Advanced synchronization patterns such as,
for instance, or split and or join and discriminator patterns, however,
cannot be conveniently expressed in Petri nets.
• Nonlocal Firing Behaviour: The enabling of activities in a business process
is based onlocal knowledge only. In the context of Petri nets, the presence
of tokens in the input places of a transition indicates activation of that
transition. In business processes, there are situations in which nonlocal
parts of the process are affected by a decision. For instance, the cancellation
pattern somehow vacuum-cleans defined parts of the Petri net when being
activated. If used to cancel a customer order, different activities in different
parts of the Petri net need to be cancelled in order to cancel the overall
customer order.
Subscribe to:
Posts (Atom)
