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.
Thursday, November 19, 2009
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.
Subscribe to:
Posts (Atom)
