Pattern 8: Multi-responses.
party X sends a request to another party Y.
Subsequently, X receives any number of responses from Y until no
further responses are required. The trigger of no further responses can
arise from a temporal condition or message content, and can arise from
either X or Y's side. Responses are no longer expected from Y after one
or a combination of the following events: (i) X sends a notification to
(ii) a relative or absolute deadline indicated by X; (iii) an interval
of inactivity during which X does not receive any response from Y; (iv)
a message from Y indicating to X that no further responses will follow.
From this point on, no further messages from Y will be accepted by X.
Synonyms. Streamed responses, message stream
- Order forecasting. As part of order forecasting, a
sends a request to a seller providing point-of-sale data, events
impacting on order forecast, e.g. new products, stores opening/close,
inventory strategy data and current inventory position (on hand, in
transit, on order). The seller provides response data as various
investigations make that data available. The investigations relate to
subcontractors in manufacturing and delivery, market studies
(historical demand data), and logistical delivery data (capacity
related, lead times, delivery operations schedules).
- News refresh. A goods deliverer provides an urgent
transportation service on behalf of suppliers to customers in a city.
For optimization of travel, it subscribes to a local traffic reporting
service provides its destination nodes (goods dispatch and customer
locations) and obtains regular feeds on traffic bottlenecks, until it
indicates that no feeds are required.
- Party X should be capable of receiving multiple messages
party Y including ones that arrive simultaneously. The number of
responses accepted will depend on a condition to be evaluated at
- As with the Racing Messages pattern, the messages to be
may be of different types. The way each received message is processed
depends on its type.
- As with the One-from-many Receive pattern, a stop condition
pertinent. However, unlike the One-from-many Receive, a success
condition does not apply since faults messages received by X are
treated individually just as "normal" messages. It is assumed that X
and Y establish an a priori understanding of the stop
- In the case where X determines when the multi-transmission
stop, there is an interval between the moment when X decides to stop
and the moment when Y becomes aware of this decision. During this
interval, Y may send messages that will then be rejected by X. Hence, a
mechanism should be in place for Y to know that its messages have been
As with the Racing messages pattern, the core of this pattern can be
captured in BPEL through a pick activity with one onMessage handler per
type of message expected (whether a normal message or a fault message).
To capture the fact that several messages may be accepted, the pick
activity must be embedded within a "while" activity. The encoding of
the stop condition depends on its nature as follows:
- If the stop condition is based on data available at the
receiver's side and/or messages' content, the stop condition can be
encoded as the exit condition of the while loop (like in the
One-from-many receive pattern).
- If the stop condition is an absolute or a relative deadline
respect to the beginning of the interaction), the while activity must
itself be embedded in a scope activity containing an onAlarm handler
corresponding to the deadline.
- If the stop condition corresponds to a period of inactivity
between responses, it can be captured as a branch in the pick activity
associated with an onAlarm handler capturing the maximum duration of
inactivity. If this branch is taken, the while loop is interrupted
(e.g. by setting an appropriate flag).
- If the stop condition is determined by the respondent (Y),
pre-agreed type of message will signal the end of the interaction to X
and thus the stop condition will be encoded as an onMessage handler
corresponding to this type of message.
In the case where the stop condition is determined by X, or in
where it is determined by Y but the underlying messaging infrastructure
or interaction policies do not guarantee ordered delivery of messages,
X should be able to return fault messages to Y for responses that are
ignored. In BPEL, this can be done by activating a thread of control
after bespoke while/scope activity mentioned above, which upon
receiving any of the expected types of messages from Y, will return a
fault message. This additional coding is necessary because in BPEL,
while it is possible to state that a process is expecting a type of
message from a given party, it is not possible to express that a
process expects not to receive a given type of message and that such
messages should be discarded and a fault returned to their sender. The
BPEL specification is silent as to what should be done with messages
that are received by a process but not consumed by any of its
Pattern 9: Contingent
A party X makes a request to another party Y. If
X does not receive a response within a certain timeframe, X
alternatively sends a request to another party Z, and so on.
Synonyms. Send with failovers.
- An online service supports document submissions to academic
conferences, tenders and grant/funding schemes. Applicants span
different geographic boundaries for the different applications. Large
bottlenecks are experienced near deadlines of especially high-volume
applications. Proposals can be directly uploaded wherein further
interactions are required to entry and validation of proposal details.
Alternatively, different servers are available in different geographic
localities for queue/forward of proposals to the central repository.
The validation steps of proposals take place once the proposal has been
forwarded (a notification is sent to the applicant to trigger this). In
first instance, the system attempts to submit the proposal for direct
upload to the central repository, but if this service is unavailable or
overloaded, it will try the "nearest: queuing service, and so on with
other queuing services.
- A travel agency allows contingent reservations of flights
particular situations - urgent requests and busy flight paths.
Customers nominate the preference of flight carriers. In order of
preference, reservations are sought in short-timeframes. If a
reservation is secured, the interaction ends.
- There is a race between receiving a response and a timer.
- After a contingency request has been issued, it may be
that a response arrives (late) from a previous request. This means that
more than one response may arrive; in all, as many responses may
potentially arrive as requests have been sent. The question is when to
accept a response if more than one request has been made and more than
one response arrives.
Solution. The first issue is generally
fact BPEL provides direct support for it through the pick construct
containing onMessage and onAlarm handlers. For the second issue,
several choices are available. One is to accept the first response even
if it is late and stop outstanding requests. Another is to accept the
first arriving response, trigger the end of outstanding requests, but
receive any further responses that arrive (before the "contingent send"
process terminates). Yet another possibility is to disallow late
arrivals altogether, and receive only the response of the current
request. For these choices, the pattern does not pre-dispose which
prevails. It is concerned with contingent sending only. In some
situations accepting late responses is desirable, while in others it
may cause problems of integrity in remote parties particularly if
requests are non-idempotent (involving database updates and extending
interactions even further with other parties).
Atomic multicast notification.
A party sends notifications to several parties
such that a certain number of parties are required to accept the
notification within a certain timeframe. For example, all parties or
just one party are required to accept the notification. In general, the
constraint for successful notification applies over a range between a
minimum and maximum number.
Synonyms. Transactional notification
- Classical all-or-none atomicity. A business venture
supports the process of business license applications for various small
business endeavors (e.g. opening a restaurant). After the steps of
obtaining and verifying application details, relevant agencies involved
in the approval or registration of the application are notified. All of
them must receive notification as there are inter-dependent aspects of
the application leading to cross-consultation. There may also be
competing applications for the same business (down to the same
location). Therefore, all agencies should receive the notification in a
timely fashion. In this example, the minimum and maximum equal the
number of all agencies notified.
- Exclusive choice. A legal firm has automated its
conveyance process for various loan types. The process utilizes a
number of search brokers who have the same level of service agreements
with the firm (service level agreements, e.g. cots model and timeliness
of response obligations). Each of the brokers competes for conveyance
applications. Therefore, only one of the notified brokers is selected,
namely the first to accept the request. The minimum and maximum both
- Nested atomicity. A travel agent allows the booking
both international and domestic travel requirements as part of
comprehensive travel packaging. Customers nominate their preferred
flight carriers as well as domestic requirements such as hotel
accommodation, local travel bookings/hire and reservations to key
attractions. In this example, each node in the international flight
path can be seen as atomic group, and within a group, the flight
carrier, booking agencies for local hotels, travel, care hire and so
on, identify the services contacted. The different groups can have
different minimum and maximum constraints depending on the domestic
requirements of the customer. However, all atomic groups need to
succeed in order for the interaction as a whole to succeed. (It should
be noted that an extension of this example could see further levels of
nesting within the atomic groups).
- The exact number of parties to which the notification will
sent may be known at design time or at run-time.
- Specification for the minimum and maximum constraints
- The constraint that all parties should have received the
notification, means that if any one party received the notification,
all the other parties also received it. Thus, some kind of
transactional support is required for this aspect of the interaction.
- Following from the above point, two steps in the
be seen, both of which need to be formalized. The first send-receive
establishes the intention to accept a request while the second acts of
the decision following an examination of received intentions - parties
are notified about whether they have been selected or not.
- The maximum number of parties required to accept the
may be less than the number of parties that notifications were sent to.
The central issue of this pattern (third issue above) clearly relates
to transactional atomicity. At present, BPEL does not provide support
for transactional atomicity. However, it does provide support for a
related notion, known as quasi-atomicity [Hagen
& Alonso 2000]
through the notion of compensation handler. Quasi-atomicity
refers to the ability to "undo" certain parts of a process execution.
Using this mechanism, the receiving parties, when they receive the
initial request, may actually perform the work associated with this
request. Later on during the second round, if the sender decides not to
proceed with the request to a given party, then that party may
compensate for the work that it had previously done. However, in
between these two rounds, the effects of the initial request would be
visible to other parties, thus violating the principle of atomicity
underlying this pattern. Supporting atomic interactions is the aim of a
dedicated WS specification known as WS-AtomicTransaction,
which provides a realization of the distributed two-phase commit (2PC)
protocol. However, this specification has not yet matured into a
standardization initiative and accordingly no links exist between it
Arguably, a solution could be crafted in BPEL by encoding the
protocol as a sequence of sub-interactions. For the first phase, a
PREPARE control message is sent to each party. Each receiver has a
separate process to deal with this message which eventually will send
back a READY control message to the initiator of the transaction. The
responses are tallied after the timeout to determine whether the
minimum and maximum constraints are satisfied. After this, the second
phase has a related set of processes for each party providing a COMMIT
(go-ahead and process the notification) or REJECT message. It should be
noted that different payloads may be included in the first and the
second phases. As part of the first phase of interactions, contacted
parties might only see a limited content of the message, enough to
decide whether they are ready to accept the request or not. In
the second phase, selected parties see all details needed to act
on the request.
If the maximum number of parties that are required to commit
than the total number of parties to which the request is sent, it is
necessary to introduce a "preference function". Where more parties than
the maximum allowed express interest to accepting the notification, the
requestor would select a subset of them, corresponding to the maximum
number allowed, using this preference function.
Next: Routing patterns
multilateral interaction patterns
Alistair Barros, SAP
Research Centre, alistair.barros at sap.com
Marlon Dumas, BPM
University of Technology
, m.dumas at
Arthur ter Hofstede, BPM
University of Technology
Part of a joint initiative by SAP
Queensland University of
co-funded by Queensland State Government.