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.
Subscribe to:
Posts (Atom)
