SOA in PracticeThe Art of Distributed System Design

Book Author: Nicolai M. JosuttisChapter Ten: Message Exchange Patterns

IT-Slideshares http://it-slideshares.blogspot.com/

10.1 Introduction to MEPsThere 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).

10.2 Basic MEPsThere are different approaches to categorizing MEPs.This section start with two basic patterns and explain some

others based on these patterns.

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)

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)

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.

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.

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.

10.3 More Complicated MEPsThere are many possible extensions to and

variations of these fundamental MEPs.This section will discuss some of the most typical

ones.

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.

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.

10.4 Dealing with Reliability and ErrorsHere 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.

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.

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)

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)

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.

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.

10.6 Event-Driven Architecture Basic Architecture

Publishing Services

Subscriber Services

Event Processing Rules

Event Processing Engine

Event PublisherEvent Subscriber

Subscribe to event

Event instance

Publish event

Event instance

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.

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)

10.6 Event-Driven Architecture

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.