Multi-transmission interaction patterns

Description. A 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 stop; (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

Example.

• Order forecasting. As part of order forecasting, a buyer 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.

Issues/design choices.

• Party X should be capable of receiving multiple messages from party Y including ones that arrive simultaneously. The number of responses accepted will depend on a condition to be evaluated at runtime.
• As with the Racing Messages pattern, the messages to be received 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 is 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 condition.
• In the case where X determines when the multi-transmission should 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 rejected.

Solution. 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 (with 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), a 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 the case 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 activities.

Description. 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.

Examples.

• 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 in 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.

Issues/design choices

• There is a race between receiving a response and a timer.
• After a contingency request has been issued, it may be possible 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 well-understood and in 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).

Description. 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

Examples.

• Classical all-or-none atomicity. A business venture service 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 property 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 are one.
• Nested atomicity. A travel agent allows the booking of 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).

Issues/design choices.

• The exact number of parties to which the notification will be sent may be known at design time or at run-time.
• Specification for the minimum and maximum constraints should be supported.
• 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 interaction can 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 notification may be less than the number of parties that notifications were sent to.

Solution. 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 and BPEL.

Arguably, a solution could be crafted in BPEL by encoding the 2PC 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 is less 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.