Lecture 10 - Message Exchange Patterns

1. Book Author: Nicolai M. Josuttis
Chapter Ten: Message Exchange Patterns
IT-Slideshares http://it-slideshares.blogspot.com/

2. 10.1 Introduction to MEPs
 There are different ways to exchange data between distributed systems.
 One fundamental approach to dealing with these differences is to
categorize the way chunks of data are exchange.
 These chunks of data are called messages.
 By categorizing different ways of exchanging messages , we get the so-
called message exchange patterns.
 MEPs define the sequence of messages in a service call or service operation,
specifying the order, direction and cardinality of those messages.
 Note :
 MEPs are general concepts to describe communications between different systems (or
nodes).

3. 10.2 Basic MEPs
 There are different approaches to categorizing MEPs.
 This section start with two basic patterns and explain some others
based on these patterns.

4. 10.2.1 Request / Response
 Probably the most importance pattern for SOA is request/response.
 In this pattern, the consumer send a request message to the service provider and waits for the provider to send
a response message (See Figure 10.1)
 From the consumer’s point of view , such a service call is like a remote procedure call (RPC) .
 The consumer is blocked until the response arrives.
 The Advantage of this pattern :
 Make code pretty simple.
 The response is delivered to the same process instance that trigger the initial request.
 The drawback of this pattern :
 You cannot do anything else while you are waiting for the response.
 If the provider is not available or something goes wrong , the consumer might never get the response and end up waiting
forever in a blocked state.
 Note that you might also arrange to do something else while waiting for the response.
 Request / Callback pattern. (Section 10.3.1)

5. 10.2.2 One-Way
 There is an alternative that ‘s even simpler from a consumer’s point of view : send a
message , and you’re done.
 This one-way pattern is often also called “fire and forget” (See Figure 10.2)
 The Request / Response pattern is just a composition of two one-way messages.
 However , this is not necessarily the case, for two reasons.
 From a consumer’s point of view, a combination of two one-way messages would lead to an
asynchronous or non-blocking request/response (or request/callback) pattern.
 From an infrastructure’s (ESB’s) point of view, sending two one-way messages would
require the sender of the first request to be able to receive the second one-way request
(which logically is the service provider’s response)

6. 10.2.3 Request/Response Versus Two One-
Way Messages.
 If the consumer process needs the response for its further processing, it is
importance that the response is delivered to the specific process instance that
performed the initial request (See Figure 10.3)
 Example :
 A CRM service might need to know about a customer’s actual payment behavior to
determine whether to allow a certain contract option.
 It calls a service of the billing system.
 It needs the response in order to continue to perform the initial service.
 So , it’s importance that the response is routed to the original CRM service instance
 In this case, the consumer must block and wait for the reply.

7. 10.2.3 Request/Response Versus Two One-
Way Messages.(Cont)
 With the specific initial consumer can continue to do its work without getting
the response, it is not important that the response be delivered to the process
instance that performed the initial request.
 You can consider the response message to be another service request back to
the system that initiated the first request (see Figure 10.4)
 Example :
 A CRM service might enable an invoice out-site the usual payment intervals.
 This service might send a corresponding request to the billing system.
 It might call another service in the CRM system to store the new invoice number and date there.

8. 10.2.3 Request/Response Versus Two One-
Way Messages.(Cont)
 Figure 10.5 shows the corresponding sequence diagram for this scenario.
 You can insert message queues in your infrastructure (ESB) , so that one a message
is sent it is persisted and can’t get lost.
 This is the core of message-oriented middleware (MOM) such as MQ and JMS.
 If you have no support for the request/response pattern in your infrastructure ,
you’ll have to program in the ability for the providing side of the requesting system
to find instance to deliver the response to.

9. 10.3 More Complicated MEPs
 There are many possible extensions to and variations of
these fundamental MEPs.
 This section will discuss some of the most typical ones.

10. 10.3.1 Request /Callback
 Often a process/thread needs some data or confirmation , but doesn’t need to be
blocked until it arrives  This pattern may be called non-blocking
request/response , asynchronous request/response , or just request/callback.
 The consumer might define a so-called “callback function” which is a function
/procedure that is called when the response arrives.
 Dealing with asynchronous responses usually leads to more complicated code.
 The response may return in a different order.  his is usually by introducing correlation
IDs that are passed with the requests and delivered with the responding replies.
 You have to make sure that the context for each response is still valid and contains all the
information required to process the response.
 You might have to deal with the fact that no responses arrive for some requests
 The big advantage of this kind of message exchange is that it introduces a form of
loose coupling :
 Service providers do not have to be available when requests are sent , and consumers can
continue to work while awaiting responses.
 Each approach has its pros and cons  It can be difficult to decide whether to use
synchronous or asynchronous request/response scenarios.

11. 10.3.2 Publish/ Subscribe
 One-way messages may be sent that do not require responses.
 To inform another system that something has happened or changed.
 These kind of message are often called notifications.
 Following the usual business process modeling is usually to send notifications.
 A general design that defines that a system must notify a specific other system when certain
condition arise.
 E.g : When a billing system has sent a new bill to a customer , a message may be sent to the CRM
system to inform CRM system about a new invoice number.
 This is another famous pattern that enables a system to register or subscribe for
certain notifications or event  This pattern is usually called the observer or
publish/subscribe pattern.
 In SOA infrastructure you often only see the second part of this pattern : The
notification.
 The subscription might be part of the business process modeling that leads to
service design.
 Note : at runtime , a one-way message is sent from the provider to each
consumer.

12. 10.4 Dealing with Reliability and Errors
 Here are some problems you might encounter when
something goes wrong.
 The service provider detects an error and sends back a
fault message instead of a typical response message.
 The service provider is unavailable and therefore cannot
receive the message.
 The transport layer for the message might not be
reliable.
 Messages might get lost over the network.
 Dealing with these situations can make message
exchange patterns a lot more complicated.

13. 10.4.1 Fault Messages
 If the service provider (or any other process receiving messages and sending responses)
detects an error, instead of sending back the usual response message , it will send back a
fault message (See Figure 10.6)
 Usually , you can define special attributes for these fault messages.
 Whether and how faults are handled in special cases has to do with the protocol you use.
 E.g
 Web Services allow you to specify and deal with special fault messages that are returned by
providers in the event that (expected and modeled) errors occur.

14. 10.4.2 Technical Errors
 If there is a technical problem that prevents a message from being delivered , the sender must be
notified.
 A message exchange that is reliable from both points of view must involve a double confirmation (See
Figure 10.7)
 With synchronous communications , these kinds of checks are usually part of the infrastructure.
 The sender of a message should get an appropriate exception if the message could not be delivered successfully.
 With asynchronous communication , things can become more complicated
 One typical approach is to persistently store all outgoing messages in a message queue , which tries to deliver
them at set intervals.
 Another typical way of dealing with these situations is to retry sending the message until a
corresponding response arrives. (View Note)

15. 10.5 Dealing with Different MEP Layers
 Message exchange pattern always depend on the characteristics of the transport
layer or protocol they use.
 But one layer above or below, things might look totally different .
 E.g :
 You can provide asynchronous message exchange patterns on synchronous protocols
,and vice versa.
 Even if your transport layer is not reliable , you still can provide an API with a
reliable interface (See Figure 10-8)

16. 10.5 Dealing with Different MEP Layers
 From a SOA point of view, the interesting issue is which MEPs the protocol supports and which MEPs
the APIs support.
 If the ESB is protocol driven , the consumer might be responsible for programming aspects such as retries.
 If the ESB is API-driven , however the infrastructure team is responsible for providing APIs for different MEPs.
 In this case , the SOA infrastructure might provide the ability to specify the number of retries and timeout period
between retries.
 Of course, things can become even more complicated.
 Example , a retry might be sent because the response took long to arrive , not because either the request or the
response was lost. In this case, the consumer will have to deal with multiple responses. (Figure 10.9)
 Idempotency is a major concern in this scenario.

17. 10.6 Event-Driven Architecture
 What is Event-Driven Architecture (EDA)?
 EDA is a software architecture pattern promoting the production, detection, consumption of,
and reaction to events.
 EDA is a technique to integrate components and applications by sending and receiving event
notifications.
 Emitting and consumption of events
 Publish-subscribe pattern
 Asynchronous processing
 De-coupling of supplier and consumer
 Non-deterministic behaviour
 What is an event ?
 ”...a notable thing that happens...”
 A message signifying that an identifiable event has happened
 Common event information
 Event type specific data
 Event instance specific data
 For example, an event notifying consumers that a barrier has been placed on a phone company
customer might result in all systems that deal with this customer disabling all functionality for
the customer.

18. 10.6 Event-Driven Architecture
 Basic Architecture
Event Processing
Rules
Publishing Event Processing Subscriber
Services Engine Services
Subscribe to event
Publish event
Event instance
Event instance
Event Subscriber
Event Publisher

19. 10.6 Event-Driven Architecture
 Event processing styles : there are these general styles of event processing : Simple
, stream, and complex and these styles are often used together in a mature event-
driven architecture.
 Simple event processing - Herein, a notable event in the system, initiates certain down
stream actions. For example, a simple alerting mechanism, or a message-based publish-
subscribe mechanism.
 Stream Events Processing – Herein, applications publish a stream of events to
subscribers based on ordinary and notable events. For example, RFID transmissions.
 Complex Events Processing – This is a more advanced form of events processing, and by
definition is a high-volume, programmatic analysis of events to identify patterns and
correlations across multiple heterogeneous event sources. This involves interpretation of
events, pattern definition and matching, in addition to correlation techniques. For
example, identification of suspicious transaction patterns in real-time, based on customer
transactions.
 EDA is the perfect answer for systems to operate in an unpredictable and
asynchronous environment.
 EDA designed systems facilitate more responsiveness to events that take
place in real life.
 EDA offers a high level of decoupling, and applications must be designed to respond to
and to publish events.

20. 10.6 Event-Driven Architecture
 The resulting process model
 The resulting process model of an EDA might be different from ( or a special case of)
the process model of SOA.
 Instead of composing basic services into composed service or process services, you get something
that can be called a “business process chain” (See Figure 10.10)

21. 10.7 Summary
 Services use different message exchange patterns (MEPs) that define the order,
direction, and cardinality of messages sent around until a specific service
operation is done.
 The basic MEPs are request/response and one-way. Also important are the
request/ callback (asynchronous or nonblocking request/response) and
publish/subscribe patterns, and higher patterns dealing with error handling.
 MEPs are layer-specific. For SOA, the MEPs on the protocol and API layers are
important.
 Events are a special type of one-way messages. They lead to event-driven
architecture (EDA), which can be considered a special case or supplementation
of SOA.
 One-way messages and events lead to (business) process chains, which is
another way of implementing business processes. Instead of orchestrated
services, where there is a central controller for the whole process, you get
choreographed services, where each service triggers the next step(s) of the
business process.