Single-transmission bilateral interaction patterns

Description. A party sends a message to another party.

Synonyms. Unicast; point-to-point send.

Example.

• An alerting service sends a reminder of an anniversary to a registered user.

Issues/design choices.

• The counter-party may or may not be known at design time. It may for example be selected at runtime from a list of possible parties, or retrieved from a local database, an LDAP registry or a UDDI directory. Reliable/guaranteed delivery may or may not be required. If reliable delivery is required, the send action may block until it is known that the message has been delivered, or it may be non-blocking. Also, in the case of reliable delivery the send action may result in a delivery fault.
• The message sent out may result in a fault message in response (not to be confused with a delivery fault as mentioned in the previous point).

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.

Description. A party receives a message from another party.

Example.

• A purchasing service receives a notification of delivery delay from a shipping service.

• The sender may require the receiver to support a reliable delivery protocol (e.g. provide receipt acknowledgments and discard duplicates).
• An incoming message may be received at a moment when the intended recipient is not ready to consume it. In this case, the message may be discarded (and a fault message sent back to the sender) or it may be placed in a queue with the expectation that it may be consumed in the future. If queuing is chosen, choices need to be made regarding queue management. For example: How long should a message be kept in a queue? Should there be a garbage-collection mechanism to clean the queue regularly, and if so, what criteria are used to discard messages?

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.

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

Synonyms: Request/response.

Example.

• A payment service sends a payment to a retail service provider who either sends back a message indicating that the payment details are invalid, or a receipt.

Issues/design choices.

• The counter-party may or may not be known in advance.
• The outgoing and incoming messages must be correlated. In other words, there is a common item of information in the request and the response that allows these two messages to be unequivocally related to one another.
• Either of the two interactions may result in a fault message in response.
• The sender may block a thread of execution to wait for the response or fault, or it may provide a single continuation for both the response and the fault or two separate continuations.

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.

Related patterns.

• Remote Procedure Call (RPC) (as presented for example in [Hohpe et al. 2003]). RPC refers to the ability for a process to invoke a procedure (or function) that will be executed (or evaluated) in another possibly remote process. When the remote procedure is invoked, parameter values are passed to it. The corresponding thread of execution blocks on the caller's process until the function/procedure has been executed/evaluated, and then the outputs are made available.
• Receive/send: This is the dual of the send/receive pattern: A party X engages in two causally related interactions: in the first interaction X receives a message from another party Y, while in the second one X sends a message to Y. For example, a supplier receives a request for quote and replies with a quote or a fault indicated that the request for quote is invalid. The issues and design choices associated to the receive/send pattern are analogue to those of the send/receive. The same holds for the solution: WSDL provides two MEPs corresponding to the receive/send pattern (in-out and in-optional out), while in BPEL this pattern is handled as a pair receive/reply action referring to the same partner link, operation, and correlation set.