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:
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment