Single-transmission bilateral interaction patterns
Pattern 1: Send.
Description. A party sends a message to another party.
Synonyms. Unicast; point-to-point send.
Solution. Comprehensive solutions to this pattern are part of many messaging programming interfaces and platforms. For instance, the Message Passing Interface (MPI) [Snir & Gropp 1998] supports send actions with reliable delivery in blocking or non-blocking mode.
In the field of web services, a distinction is made between the communication-related aspects of this pattern and its control-related aspects. The latter are determined by the executable language used to implement the service (e.g. a general-purpose procedural language or BPEL). Reliability is determined at the communication level whereas synchronization (i.e. the blocking vs. non-blocking distinction) is determined at the level of the executable language.
In WSDL 2.0, the send pattern surfaces as two Message Exchange Patterns (MEPs): out-only and robust out-only. In the out-only MEP a service sends exactly one message. In the Robust out-only MEP the service also sends one message, but the message may result in a fault message in response. The fault message is delivered to the initiator of the interaction. For example, a purchase order sent to a supplier may result in a fault message from the supplier to the effect that the customer ID does not match the customer name.
Reliable delivery is the realm of a yet-to-be-standardized specification. Such reliable messaging specification is expected to provide the building blocks to enable at-least once, at-most once, and exactly once delivery. It will also define elements to specify the reliability properties of service operations in its interface (e.g. in a WSDL description). It should be noted though that the distinction between blocking and non-blocking interaction mode is not in the scope of WSDL, as this is determined at the level of the executable language.
In BPEL, the pattern is encoded either as an invoke activity that produces no output, or as a reply activity. A reply activity is always related to a previous receive activity and is used to respond to a previously received request. In an invoke/reply activity, the identity of the counter-party is captured by an "endpoint reference" defined for example using WS-Addressing There is an indirect relationship between endpoint references and invoke/reply activities: Each invoke/reply activity is associated with a partner link and each partner link is associated with an endpoint. The association between a partner link and an endpoint is determined at runtime. Thus the counter-party does not need to be known at design time.
In the case of a reliable delivery, the invoke/reply activity is blocking. Once it is certain that delivery has occurred, the invoke/reply activity completes normally and the flow of execution proceeds. Alternatively, a fault will be raised if the message fails to be delivered within a specified timeframe or after an inactivity period (these parameters may be defined as reliability policy assertions). To deal with delivery failures, the invoke/reply activity should be embedded in a so-called "scope" to which a suitable "fault handler" should be attached.
A BPEL invoke activity may be related to a WSDL operation that may result in a fault message being returned by the counter-party. Again, to deal with such operation-defined faults, the invoke activity needs to be embedded in a scope with a corresponding fault handler. It can be noted that a reply activity cannot result in an operation-defined fault.
Pattern 2: Receive.
Description. A party receives a message from another party.
Solution. As for the send pattern, comprehensive built-in solutions to this receive pattern can be found in many messaging programming interfaces and platforms (e.g. MPI). Also as discussed in the previous pattern, web services standards and platforms separate the communication aspects of this pattern from the control aspects.
On the communication side, WSDL supports the pattern through two MEPs: in-only and robust in-only, depending on whether a fault message may be sent back to the sender or not. The receiver's capabilities in terms of reliable delivery (e.g. being able to ensure that duplicate messages are only processed once) are exposed as reliability policy assertions in a yet-to-be-standardized specification. Due to its stateless nature, WSDL cannot express under which conditions the message is consumed or discarded (e.g. it does not capture which message exchanges must have occurred before a given type of message can be consumed). The formulation of such preconditions is pushed to choreography and behavioral interface descriptions languages (e.g. WS-CDL and BPEL abstract processes). However, at the WSDL level it is possible to define fault messages that will be returned to the sender if a given message is discarded, for example because it arrives too late or too early in an interaction.
From the control perspective, the receive pattern can be treated either as an event that is produced when the message is ready for consumption, or as an action that checks if message has arrived, waits for the message if necessary (i.e. the execution is blocked), and eventually consumes the message. Accordingly, the receive pattern can be captured in BPEL either as an onEvent handler or as a receive action depending on whether the message receipt is non-blocking or blocking respectively. A receive activity blocks until the message is consumed. On the other hand, an onEvent handler is associated to a "scope" of the process and may be triggered anytime during the execution of the scope by a message event matching the handler, thus capturing a non-blocking receive. It can be noted that, in addition to the onEvent handler, BPEL provides another form of message event handler, namely onMessage handler. Handlers of this latter form are used as triggers within "pick" activities when an exclusive choice between multiple events needs to occur as in the "Racing messages" pattern exposed later.
Central to BPEL is the notion of process instance, i.e. an execution of a process definition that runs in its own memory space. An incoming message to be handled by a BPEL process may either trigger the creation of a new process instance, or it may be routed to an already running process instance based on the value of a correlation token contained in the message. Whether a message creates a new instance or is handled by an existing instance depends on the value of an attribute (namely createInstance) attached to the message event handler or receive action that is able to receive the type of message in question. Specifically, when a receive activity or message event handler has the createInstance attribute set to "yes", a message matching this handler/activity will not be consumed by a process instance, but rather by the process factory that will create a new process instance as a result.
When a message is targeted at a running process instance, if the process instance is not ready to consume the message upon arrival (i.e. there is no active receive action or message event handler capable of consuming that type of message), the message is stored until the process instance reaches a point where it can consume it. In theory, the message could be stored forever if the process instance completes without reaching such state. Thus a typical BPEL implementation would provide some "garbage collection" mechanism and discard messages that would otherwise never be consumed. BPEL regards this as an implementation issue. In particular, when messages are discarded in this way, BPEL does not stipulate that a "fault message" should be returned to the original sender to indicate that its message has been discarded.
Pattern 3: Send/receive.
Description. A party X engages in two causally related interactions: in the first interaction X sends a message to another party Y (the request), while in the second one X receives a message from Y (the response).
Solution. WSDL provides two MEPs corresponding to this pattern: out-in and out-optional in. The former corresponds directly to this pattern, while the latter corresponds to a combination of this pattern and the send pattern.
In BPEL, the pattern can be captured in two ways: (i) as a single invoke activity with both an input and an output, in which case the thread of execution is blocked until the response arrives; or (ii) as a combination of an invoke activity (without an output) and either a receive activity or an onEvent or onMessage handler referring to the same partner link, operation, and correlation set as the invoke activity. Through this latter option, it is possible to deal with the pattern in a non-blocking mode, in the sense that the thread of execution would not block between the send and the receive actions, and in addition (by using onEvent handlers) the message receipt itself is non-blocking. Also, if the send and receive parts of the pattern are realized separately, it is possible to determine the endpoint to which the initial message is sent at runtime (as explained in the solution of the Send pattern) and thus the counter-party does not need to be known at design time. Faults can be taken into account through scopes with associated fault handlers as mentioned in the Send and Receive patterns above.
Next: Single-transmission multilateral interaction patterns Up: Patterns
Site created and maintained by:
Alistair Barros, SAP, Brisbane Research Centre, alistair.barros at sap.com
Marlon Dumas, BPM Research Group, Queensland University of Technology, m.dumas at qut.edu.au
Arthur ter Hofstede, BPM Research Group, Queensland University of Technology, email@example.com
Part of a joint initiative by SAP and Queensland University of Technology, co-funded by Queensland State Government.