Message Exchange Patterns (MEPs)

Table of Contents

Overview

Message Exchange Patterns (MEPs) describe how systems may intercommunicate using unanimously understood mechanisms. Unless otherwise specified, MEPs describe logical patterns rather than strict physical ones:

• Logical MEPs: they establish how data is exchanged at a conceptual/use-case level. For example, a One-Way MEP establishes that there is “no response” after firing a request. However, if the message is delivered using, say, HTTP, there is effectively some form of response at the HTTP level. It just happens to be of no “use case” relevance.
• Physical MEPs: they establish how data is physically exchanged by computer systems. Within the physical layer, the distinction also varies according to the chosen layer. For example, if we consider the OSI model’s transport layer, UDP would be a One-way MEP whereas TCP can support the Request/Response MEP, but it is, in reality, a bidirectional stream.

This is a summary of the most common patterns:

Request/Response

The Request/Response Message Exchange Pattern (MEP) is that in which the consumer sends a request and waits for a response. This pattern may also be referred to as Request/Reply, In-Out (SOAP), and RPC.

A Request/Response MEP may be implemented in a synchronous, asynchronous, or polling fashion:

1. Synchronous Request/Response MEP: the consumer has to wait until the provider is able to produce a response or keep track of a communication stream.
2. Asynchronous Request/Response MEP: the consumer’s control flow is released right after issuing the request. The provider will produce the request in parallel and hand it over to the consumer once it is ready.
3. Polling Request/Response MEP: similarly to the previous MEP, the consumer’s code control flow is released right after issuing the request since the provider will produce the response asynchronously. However, the consumer has to check repeatedly (poll) the provider until the response becomes available.

Synchronous Request/Response MEP

Unless otherwise specified, the Request/Response MEP is assumed to be synchronous. This means that the consumer is blocked (it cannot resume its code flow) until the provider is able to produce a response.

In regular (non event-based) programming languages, all regular method/function invocations are, by definition, synchronous. The invoking code cannot continue unless the method or function returns a result.

A key aspect of the Synchronous Request/Response MEP is that both the consumer and the provider must be on-line until the response is fully streamed back to the consumer. Any interruption in between may result in the transaction’s data being lost forever. This is the nature of most HTTP-based communication and the reason why the concept of idempotency is so relevant in architectural styles such as REST.

An invocation to a synchronous API may be single-threaded blocking, single-threaded non-blocking or multi-threaded.

Blocking Single-threaded Invocation

This is the default invocation mode in which the consumer’s flow remains blocked until a response is returned. Unless the I/O driver supports an effective timeout mechanism, the consumer’s code becomes subordinate to the provider’s latency as well as to that of its supply chain.

Pseudocode example:

11. rate = provider.getExchangeRate(1.2, "USD","GBP")
22. ... flow is stuck here ...
33. print "The exchange rate is : " + rate

Non-blocking Single-threaded Invocation

In the case of a non-blocking invocation, the consumer may check the availability of response-data interactively and fetch data in chunks. This provides the following advantages:

• A timeout mechanism may be easily implemented to abort the request/response process if it exceeds a defined maximum time.
• Other pieces of code may be executed whilst the request and responses are being streamed—for example, displaying a progress bar.

Pseudocode example:

11. request = provider.getExchangeRate(1.2,"USD",GBP")
22. while (!request.sendEOF)
33.    print "Sending request..."
44. end while
55. while (!request.receiveEOF)
66.    print "Receiving response...";
77. end while
88. print "The exchange rate is : " + request.response;

Multi-threaded Invocation

A multi-threaded invocation has the same advantages as the non-blocking one, except that the consumer code does not need to interact with the request object or functions to keep track of its progress. In this case, the invocation code runs as a parallel, independent process.

Pseudocode example:

11. define requestThread as Thread
22.    rate = provider.getExchangeRate(1.2, "USD","GBP")
33.    print "The exchange rate is : " + rate
44. end define
55.
66. run requestThread
77. ... continue flow  ...

Asynchronous Request/Response MEP

The asynchronous request/response MEP is an approach to create an external, logical request/response logical flow that is, in reality, implemented as a request/call-back interaction. This pattern may be referred to as “virtual synchronous” or “synch to asynch wrapper”.

This pattern is typical in the construction of web services that wrap legacy queue-based systems such as those based on IBM WebSphere MQ technology.

The main advantage of this approach is that the process of sending and receiving a request are decoupled. This allows the consumer to perform other activities in-between the message exchange.

The disadvantage is that a correlation identifier may be necessary and that the provider may require reliability features (such as message storage and fail/retry mechanisms) since the consumer may no longer be on-line when the provider has finished calculating the response.

Pseudocode example: no correlation identifiers are shown for simplicity.

 1 1. define onMessage (response)
 2 2.   rate = response    
 3 3. end define
 4 4. 
 5 5. provider.request.getExchangeRate(1.2, "USD","GBP")
 6 6. provider.callBack = onMessage    
 7 7. provider.invoke()
 8 8.
 9 9. while (rate == null) 
1010.   ... do something else ...
1111. end while
1212.
1313. print "The exchange rate is : " + rate

Explanation:

• Lines 1-3: Define call-back function onMessage
• Lines 5-6: Establish desired service and register call-back function
• Lines 9-11: Wait until a response (rate) is produced.

Polling Request/Response MEP

This pattern could be seen as a two–step process in which the first step consists of the One-Way MEP, and the second one of a regular Synchronous Request/Response MEP.

Unlike the asynchronous Request/Response MEP, the provider is unable to start a request towards the provider; instead, the consumer has to poll the provider regularly until a response becomes available. The use of a correlation identifier is almost mandatory since the consumer has to tell the provider the specific request in which it is interested.

Pseudocode example:

11. id = provider.requestExchangeRate(1.2, "USD","GBP")
22.    
33. while (rate == null) 
44.   rate = provider.requestExchangeResultForId(id)
55. end while

Request/Response in SOAP

This is how the Request/Response MEP is understood in SOAP:

One-Way

The One-Way Message Exchange Pattern (MEP) is that in which the consumer sends a one-off message to a provider with no expectation of a response. This pattern may also be referred to as Fire and Forget, In-Only (SOAP), and sometimes Queue based.

A One-way MEP may be implemented in asynchronous, asynchronous/verifiable or synchronous/reliable fashion:

• Asynchronous One-Way MEP: the “pure” fire and forget implementation of the pattern in which the consumer has no means to verify message arrival.
• Asynchronous/Verifiable One-Way MEP: a variation that allows the provider to communicate back to the consumer at a certain point to notify of the messages that have arrived.
• Synchronous/Reliable One-Way MEP: The delivery of a one-way message with an expected acknowledgement from the provider.

Asynchronous One-Way MEP

This is the “pure” fire and forget implementation of the pattern in which the consumer has no means to verify message arrival. The pattern is rarely implemented in such a crude fashion unless:

1. Only “statistical arrival” is important; for example, a requirement that says that only 80% of messages must arrive. Even so, a monitoring mechanism must still be in place to keep track of statistical data.
2. The message is delivered through a safe mechanism which “doesn’t drop messages”. In this case there is a form of middleware in place which acts as the actual consumer. Such a middleware layer would be, in reality, following the Asynchronous/Verifiable MEP.

Pseudocode example:

11. provider.submitExpenses("Slavoj Zizek", 4.50, "Pizza");
22. ... flow continues ...

Asynchronous One-Way/Verifiable MEP

This variation still has the advantage of the fire and forget aspect in the sense that the consumer does not need to wait for the provider for an acknowledgement. However, at some point in the future, the provider will contact the consumer to notify of the messages it has received.

This scheme permits the consumer to run a “reconciliation process” and send back those messages that have not been received by the provider.

Pseudocode example:

 1 1. define acknowledge (name) 
 2 2.   unverified.remove (name)
 3 3. end define
 4
 5 4. define retryUnverified as Thread
 6 5.   while (unverified.size > 0)
 7 6.      for all (name : unverified)
 8 7.         provider.invoke (name)
 9 8.      end for all          
10 9.   end while
1110. end define
1211.
1312. name = "Zizek" 
1413. provider.register (
1514.    name, 
1615.    submitExpenses("Zizek", 4.50, "Pizza")
1716. )
1817.   
1918. unverified.add (name)
2019. provider.invoke (name)
2120.  
2221. ... do more ...
2322. ... receive call backs to acknowledge ...
2423. 
2524. run retryUnverified

Explanation:

• Lines 1-3: Call-back function for the provider to notify of received messages.
• Lines 4-10: Message retry loop.
• Lines 12-16: Invocation registration (for future retrial if required).
• Lines 18-19: First one-off invocation.

Notes:

• Further code is required to tell the provider that “the consumer has received the acknowledgement” so that the provider does not keep insisting on the same already-verified messages.
• The “retryUnverified” thread would ideally be a worker thread which is running always in parallel. In certain designs there is no separation between the “send first message” and “retry” events; all invocations are produced by the same parallel working thread.

Synchronous One-Way/Reliable MEP

This is a logical One-way MEP which is implemented as a physical Request/Response MEP with the difference that the Response is only used to confirm (acknowledge) the message arrival and/or report a fault with it. The Response is not intended to carry “business data”.

Most HTTP-based One-way MEP implementations are, in fact, of this variety. A developer would need to disregard the HTTP specification to make either the provider or the consumer behave in a true fire and forget manner.

Let’s take a regular HTTP web service call as an example:

Request:

 1POST /ws/get HTTP/1.1
 2Accept: application/json
 3Content-Length: xxx
 4Content-Type: application/json
 5Host: ws.tesira.com
 6
 7{ 
 8    "name" : "Zizek",
 9    "amount": 4.5,
10    "description": "Pizza"
11}

Response:

1HTTP/1.1 200 OK
2Content-Type: application/json
3Content-Length: xxxx

The response, as such, is part of the HTTP specification and serves as a default acknowledgement device unless the developer decides to forgo it.

Other Classifications

The discussed variations discriminate the pattern based on how—if at all—message arrival is acknowledged. Alternatively, the One-Way MEP may be classified based on the number of recipients [2005-erl-soa]:

• Single-destination: one destination only.
• Multi-cast: a predefined set of destinations.
• Broadcast: all destinations in a given set.

One-Way in SOAP

This is how the One-Way MEP is understood in SOAP:

Publish/Subscribe

The Publish/Subscribe Message Exchange Pattern (MEP) is that in which consumers subscribe with providers to receive notifications. This pattern may also be referred to as Pub/Sub, Topic-based, and Subscription-based.

This pattern assumes the following roles and entities:

• Subscribers: the name given to the consumers that participate in the exchange.
• Publishers: the name given to the providers that participate in the exchange.
• Topic: the channel or category that consumers subscribe to and providers publish on.
• Subscription: the act of notifying the provider that the consumer is interested in messages published on a given topic.

Publish/Subscribe is typically implemented using the One-Way MEP in a bidirectional fashion; the consumer sends subscription messages to the provider and the provider sends topic-specific messages to the consumer. This pattern is similar to the Observer OOP pattern.

Pseudocode example:

1define onMessage (message)
2    if message.topic = "X" then
3        print "I got a new message: " + message.content   
4    end if
5end define
6
7provider.register = onMessage
8provider.subscribeToTopic("X")

Filtering

Topics are not the only means by which messages are grouped. Content-based filtering may be used to discriminate between relevant and irrelevant messages. Filtering may be consumer-side or provider-side.

Consumer-side Filtering

Advantages

The advantage of this approach is that the consumer may easily alter the type of messages it is interested in. For example, a news mobile application may receive all news but the user may initially select to view sports and weather news only. The user may decide to switch to finance news at a later time without the need to fetch new data from the provider—for example, when the user is on the underground train with no mobile reception.

Disadvantages

Consumer-side filtering is not truly a pattern, but the lack thereof. Thus, avoiding client-side filtering (or strict grouping by topic) is only feasible when the expected quantity and weight of the messages is reasonable in terms of scalability and bandwidth constraints.

Provider-side Filtering

Advantages

The consumer is relieved from implementing the filtering process. The required bandwidth and associated volumetrics only need to accommodate the messages that are relevant to the consumer.

Disadvantages

The provider has to be configured a priori with the required filters. It could be argued that a specific filter configuration would be, in effect, a topic. Alternatively, the consumer may be able to submit filter parameters interactively, but such feature may not be supported by the messaging framework in a native fashion.

Use of Specific One-Way Patterns

As we said before, the Publish/Subscribe MEP is typically implemented using the One-Way MEP. If the pure asynchronous One-Way MEP is chosen, certain limitations apply:

SOAP

In SOAP, the Publish/Subscribe MEP typically abides either to the WS-Eventing or the WS-Notification specifications.

Request/Call-back

The Request/Call-back Message Exchange Pattern (MEP) is that in which the consumer registers a call-back function with the provider. Such a function is normally used by the provider to notify the consumer when the request is completed; however, it may also carry additional data.

This pattern is a form of bidirectional One-Way MEP or Asynchronous Request/Reply. What makes it special is that the endpoint and/or function to be used by the provider is defined in an ad-hoc fashion at runtime rather than being defined in advance.

Pseudocode example:

1define myFunction
2    print "The food is ready"
3end define
4
5provider.cookFood(myFunction)

Before You Leave