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.