ENTERPRISE INTEGRATION PATTERNS

Have each application produce files containing information that other applications need to consume.

Integrate applications by having them store their data in a single shared database.

Develop each application as a large-scale object or component with encapsulated data. Provide an interface to allow other applications to interact with the running application.

Use messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats.

Connect the applications using a Message Channel, where one application writes information to the channel and the other one reads that information from the channel.

Package the information into a Message, a data record that the messaging system can transmit through a message channel.

Use the Pipes and Filters architectural style to divide a larger processing task into a sequence of smaller, independent processing steps (Filters) that are connected by channels (Pipes).

Insert a special filter, a Message Router, which consumes a Message from one Message Channel and republishes it to a different Message Channel channel depending on a set of conditions.

Use a special filter, a Message Translator, between other filters or applications to translate one data format into another.

Connect an application to a messaging channel using a Message Endpoint, a client of the messaging system that the application can then use to send or receive messages.

Send the message on a Point-to-Point Channel, which ensures that only one receiver will receive a particular message.

Send the event on a Publish-Subscribe Channel, which delivers a copy of a particular event to each receiver.

Use a separate Datatype Channel for each data type, so that all data on a particular channel is of the same type.

The receiver should move the improper message to an Invalid Message Channel, a special channel for messages that could not be processed by their receivers.

When a messaging system determines that it cannot or should not deliver a message, it may elect to move the message to a Dead Letter Channel.

Use Guaranteed Delivery to make messages persistent so that they are not lost even if the messaging system crashes.

Use a Channel Adapter that can access the application's API or data and publish messages on a channel based on this data, and that likewise can receive messages and invoke functionality inside the application.

Use a Messaging Bridge, a connection between messaging systems, to replicate messages between systems.

Structure the connecting middleware between these applications as a Message Bus that enables them to work together using messaging.

Use a Command Message to reliably invoke a procedure in another application.

Use a Document Message to reliably transfer a data structure between applications.

Use an Event Message for reliable, asynchronous event notification between applications.

end a pair of Request-Reply messages, each on its own channel.

The request message should contain a Return Address that indicates where to send the reply message.

Each reply message should contain a Correlation Identifier, a unique identifier that indicates which request message this reply is for.

Whenever a large set of data may need to be broken into message-size chunks, send the data as a Message Sequence and mark each message with sequence identification fields.

Set the Message Expiration to specify a time limit how long the message is viable.

Design a data format that includes a Format Indicator, so that the message specifies what format it is using.

Use a Content-Based Router to route each message to the correct recipient based on message content.

Use a Dynamic Router, a Router that can self-configure based on special configuration messages from participating destinations.

Define a channel for each recipient. Then use a Recipient List to inspect an incoming message, determine the list of desired recipients, and forward the message to all channels associated with the recipients in the list.

Use a Splitter to break out the composite message into a series of individual messages, each containing data related to one item.

Use a stateful filter, an Aggregator, to collect and store individual messages until a complete set of related messages has been received. Then, the Aggregator publishes a single message distilled from the individual messages.

Use a stateful filter, a Resequencer, to collect and re-order messages so that they can be published to the output channel in a specified order.

After all items have been verified we want to pass the validated order message to the next processing step.

Use a Scatter-Gather that broadcasts a message to multiple recipients and re-aggregates the responses back into a single message.

Attach a Routing Slip to each message, specifying the sequence of processing steps. Wrap each component with a special message router that reads the Routing Slip and routes the message to the next component in the list.

Use a central processing unit, a Process Manager, to maintain the state of the sequence and determine the next processing step based on intermediate results.

Use a central Message Broker that can receive messages from multiple destinations, determine the correct destination and route the message to the correct channel.

Use a Envelope Wrapper to wrap application data inside an envelope that is compliant with the messaging infrastructure. Unwrap the message when it arrives at the destination.

Use a specialized transformer, a Content Enricher, to access an external data source in order to augment a message with missing information.

Use a Content Filter to remove unimportant data items from a message leaving only important items.

Store message data in a persistent store and pass a Claim Check to subsequent components. These components can use the Claim Check to retrieve the stored information.

Use a Normalizer to route each message type through a custom Message Translator so that the resulting messages match a common format.

Design a Canonical Data Model that is independent from any specific application. Require each application to produce and consume messages in this common format.

Use a Messaging Gateway, a class than wraps messaging-specific method calls and exposes domain-specific methods to the application.

Create a separate Messaging Mapper that contains the mapping logic between the messaging infrastructure and the domain objects. Neither the objects nor the infrastructure have knowledge of the Messaging Mapper's existence.

Use a Transactional Client—make the client’s session with the messaging system transactional so that the client can specify transaction boundaries.

The aplication should use a Polling Consumer, one that explicitly makes a call when it wants to receive a message.

The application should use an Event-Driven Consumer, one that is automatically handed messages as they’re delivered on the channel.

Create multiple Competing Consumers on a single channel so that the consumers can process multiple messages concurrently.

Create a Message Dispatcher on a channel that will consume messages from a channel and distribute them to performers.

Make the consumer a Selective Consumer, one that filteres the messages delivered by its channel so that it only receives the ones that match its criteria.

Use a Durable Subscriber to make the messaging system save messages published while the subscriber is disconnected.

Design a receiver to be an Idempotent Receiver--one that can safely receive the same message multiple times.

Design a Service Activator that connects the messages on the channel to the service being accessed.

Use a Control Bus to manage an enterprise integration system. The Control Bus uses the same messaging mechanism used by the application data, but uses separate channels to transmit data that is relevant to the management of components involved in the message flow.

Construct a Detour with a context-based router controlled via the Control Bus. In one state the router routes incoming messages through additional steps while in the other it routes messages directly to the destination channel.

Insert a simple Recipient List into the channel that publishes each incoming message to the main channel and a secondary channel.

Attach a Message History to the message. The Message History is a list of all applications that the message passed through since its origination.

Use a Message Store to capture information about each message in a central location.

Use a Smart Proxy to store the Return Address supplied by the original requestor and replace it with the address of the Smart Proxy. When the service sends the reply message route it to the original Return Address.

Use Test Message to assure the health of message processing components.

Use a Channel Purger to remove unwanted messages from a channel.