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.