Enterprise Integration Patterns: Overview

I would like to cover an overview of the general concepts in Enterprise Integration Patterns in messaging systems. I will cover each topic in more detail in further posts, but lets start at the basics.

Figure 1: Message Router routes messages from input channel to one or more output channels

Firstly, where would you use these Integration Patterns? Well anytime you want to move information from one system to another you can use these patterns. These patterns are extremely useful if you have to access data that is contained in a legacy system or if one system is “sealed” and you cannot easily access it’s data (through API, database, etc).

The first challenge and the major selling point of Enterprise Integration is that you want the 2 or more systems to be as loosely coupled as possible i.e you don’t want one system having a direct reference to the other system. Why do you ask? Any change in business rules or the addition of additional recipients will result in code changes at numerous places. This makes it very inflexible.

There are two main flavors of messaging:

• Request/Reply: An example is you needing customer information that resides in different CRM system. A request message will be sent to the CRM requesting information. The CRM system will send a reply containing the information.
  
• One way: An example is that you have an event that occurred in your system that you want to broadcast to other systems. These systems do not have to acknowledge or reply to your broadcast.

Messaging consists out of a couple of main concepts:

• Channels: Messaging systems transmit data through a Message Channel – a virtual pipe that connects a sender and a receiver.
  
• Messages: Message is an atomic packet of data that can be transmitted on a channel.
  
• Pipes and Filters: Break up various operations between sender and receiver by chainging operations using pipes and filters.
  
• Routing: Router receives a message on input channel and determines how to navigate the channel topology and directs the message to the final receiver.
  
• Transformation: When applications do not agree on the format for piece of data, use a transformer to map one message type to another.
  
• Endpoints: An endpoint bridges the gap between how the application works and how the messaging system works

Thus to illustrate we can use the request reply example. An ordering system needs information stored in CRM system when placing orders. The ordering system would create a request message (CustomerId=1 request) and place this message on a channel (MSMQ as an example). The router will receive this message of the queue, determine the type of message and route it to the CRM system endpoint. The endpoint will receive the message and use a Channel Adapter (discussed in future post) to act as anti corruption layer and transform the message into an object the CRM system understands. The CRM system will process the message, retrieve the valid customer information and send that information via a response message to the Reply Address specified in the original request message. The route will pick up the reponse message, perform any needed operations on it and send it off to the ordering system endpoint.

In further posts I will go into detail on each of these topics by illustrating why they are important and when and where you will use them. I will also show a couple of different flavors on each of them.