First of all we should define EIPs and why we should use them. As the name implies, these are tested solutions for specific design problems encountered during many years in the development of IT systems. And what is all the more important is that they are technology-agnostic which means it does not matter what programming language or operating system you use.
Patterns are divided into seven sections:

1. Messaging Systems,
2. Messaging Channels,
3. Message Constructions,
4. Message Routing,
5. Message Transformation,
6. Messaging endpoints,
7. System management.

The purpose of this article is to encourage you to use the patterns so I will discuss briefly only one or two such patterns from each of above sections. If you want to explore then further, visit http://www.eaipatterns.com/ or read Gregor Hohpe’s book mentioned in the introduction of this series.

Message Channel (from Messaging Systems)


A message channel is a logical channel which is used to connect the applications. One application writes messages to the channel and the other one (or others) reads that message from the channel. Message queue and message topic are examples of message channels.

Message Translator (from Messaging Systems)


Message translator transforms messages in one format to another. For example one application sends a message in XML format, but the other accepts only JSON messages so one of the parties (or mediator) has to transform XML data to JSON. This is probably the most widely used integration pattern.

Publish-Subscribe Channel (from Messaging Channels)

This type of channel broadcasts an event or notification to all subscribed receivers. This is in contrast with a point-to-point channel . Each subscriber receive the message once and next copy of this message is deleted from channel. The most common implementation of this patter is messaging topic.


Dead Letter Channel (from Messaging Channels)


The Dead Letter Channel describe scenario, what to do if the messaging system determines that it cannot deliver a message to the specified recipient. This may be caused for example by connection problems or other exception like overflowed memory or disc space. Usually, before sending the message to the Dead Letter Channel, multiple attempts to redeliver message are taken.

Correlation Identifier (from Message Construction)

Correlation Identifier gives the possibility to match request and reply message when asynchronous messaging system is used. This is usually accomplished in the following way:
Producer: Generate unique correlation identifier.
Producer: Send message with attached generated correlation identifier.
Consumer: Process messages and send reply with attached correlation identifier given in request message.
Producer: Correlate request and reply message based on correlation identifier.

Content-Based Router (from Message Routing)


Content-Based Router examines message contents and route messages based on data contained in the message.


Content Enricher (from Message Transformation)

Content Enricher as the name suggests enrich message with missing information. Usually external data source like database or web service is used.

Event-Driven Consumer (from Messaging Endpoints)

Event-Driver Consumer enables you to provide a action that is called automatically by the messaging channel or transport layer. It is asynchronous type of pattern because receiver does not have a running thread until a callback thread delivers a message.

Polling Consumer (from Messaging Endpoints)


Polling Consumer is used when we want receiver to poll for a message, process it and next poll for another. What is very important is that this pattern is synchronous because it blocks thread until a message is received. This is in contrast with a event-driven consumer. An example of using this pattern is file polling.

Wire Tap (from System Management)

Wire Tap copy a message and route it to a separate channel, while the original message is forwarded to the destination channel. Usually Wire Tap is used to inspect message or for analysis purposes.