Message Exchange Patterns

A service supports one or more message exchange patterns (MEPs), or kinds of interaction between requester and service. At this writing, only two elementary MEPs are widely used.

Figure 2.1 depicts a one-way pattern (sometimes called in-only or fire-and-forget), in which the requester invokes the service with a request (an input message) but does not receive a response.

Figure 2.1: One-way pattern

Figure 2.2 depicts a request-response pattern (sometimes called in-out), in which the requester invokes the service with a request and receives a response.

Figure 2.2: Request-response pattern

Two other elementary MEPs are uncommon but will be supported over time.

In a notification pattern (sometimes called out-only), the service submits a message in the absence of an ongoing conversation, as when a service sends news to a subscriber. Figure 2.3 illustrates this pattern.

Figure 2.3: Notification pattern

Figure 2.4 depicts a solicit-response pattern (sometimes called out-in), in which the service submits a notification to a requester and receives a response.

Figure 2.4: Solicit-response pattern

The following advanced features are available for the first two MEPs and will be available for the others in the future:

• A message in the returning direction can be optional.

• A service or requester can submit a fault message, which is data sent in response to a runtime error.

Synchronous and Asynchronous Communication

The request-response pattern and the solicit-response pattern represent synchronous communication, which means that the initiator of the message suspends processing until the initiator receives a response. In contrast, the one-way and notification patterns represent asynchronous communication, which means that the initiator of the message continues running the next coded statement, without suspending processing.

Callbacks

Assume that Service01 invokes Service02. To complete the interaction, Service02 may issue a callback, which is an invocation of an operation that can be provided by Service01. The invoked operation is called a callback operation, as shown in Figure 2.5.

Figure 2.5: Request and callback

Service02 could be a credit-rating service that can respond to a request for customer details only after an hour, while Service01 is a service that requests credit details. Service01 shouldn't wait for the details, because the wait would use memory and other resources. Instead, the overall business process can ensure that Service02 invokes a callback operation in Service01.

A callback doesn't necessarily involve asynchronous processing, although the two ideas often come together. Consider the following variations:

• Service01 requests a credit report and receives a confirmation of the request, then waits for the report as before.

• Service01 allows Service02 to issue synchronous callbacks that request additional details.

From a business point of view, a callback operation is like any other. Service01 can have multiple operations, and the callback operations in Service01 are those invoked by services that previously received requests from Service01.