Enterprise Application Integration (EAI) is key to connecting business applications with heterogeneous systems. Over the years, architects of integration solutions have invented their own blend of patterns in a variety of ways. But most of these architectures have similarities, initiating a set of widely accepted standards in architecting integration patterns. Most of these standards are described in the Enterprise Integration Patterns Catalog available at: http://www.eaipatterns.com/toc.html.
In this guide, we have shown how each pattern in the patterns catalog can be simulated using various constructs in WSO2 ESB 4.9.0. Click on a topic in the list below for details.
How one application communicates with another using messaging.
How two applications connected by a message channel exchange a piece of information.
How to perform complex processing on a message while maintaining independence and flexibility.
How to decouple individual processing steps so that messages can be passed to different filters depending on conditions.
How systems using different data formats communicate with each other using messaging.
How an application connects to a messaging channel to send and receive messages.
How the caller can be sure that exactly one receiver will receive the document or perform the call.
How the sender broadcasts an event to all interested receivers.
How the application sends a data item such that the receiver will know how to process it.
How a messaging receiver gracefully handles a message that makes no sense.
What the messaging system does with a message it cannot deliver.
How the sender ensures delivery of a message, even if the messaging system fails.
How to connect an application to the messaging system to send/receive messages.
How multiple messaging systems can be connected so that messages available on one are also available on the others.
An architecture enabling separate applications to work together in a decoupled fashion such that applications can be easily added or removed without affecting the others.
How messaging can be used to invoke a procedure in another application.
How messaging can be used to transfer data between applications.
How messaging can be used to transmit events from one application to another.
How an application that sends a message gets a response from the receiver.
How a replier knows where to send the reply.
How a requester that has received a reply knows which request the reply is for.
How messaging can transmit an arbitrarily large amount of data.
How a sender indicates when a message should be considered stale and therefore should not be processed.
|Format Indicator||How a message’s data format can be designed to allow for possible future changes.|
How to handle a situation when the implementation of a single logical function (such as an inventory check) is spread across multiple physical systems.
How a component avoids receiving uninteresting messages.
How to avoid the dependency of a router in all possible destinations, while maintaining its efficiency.
How to route a message to a list of dynamically specified recipients.
How to process a message if it contains multiple elements, each of which may have to be processed in a different way.
How to combine the results of individual but related messages so that they can be processed as a whole.
How to maintain the overall flow when processing a message consisting of multiple elements, each of which may require different processing.
|How to maintain the overall flow when a message needs to be sent to multiple recipients, each of which may send a reply.|
How to route a message consecutively through a series of steps when the sequence of the steps is not known at design time and may vary for each message.
How to route a message through multiple processing steps, when the required steps may not be known at design time and may not be sequential.
How to decouple the destination of a message from the sender and maintain central control over the flow of messages.
How to put a stream of related but out-of-sequence messages back into the correct order.
Currently, you can use this resequencing pattern only through the Management Console of WSO2 Enterprise Service Bus 4.9.0. In future, this will be implemented with Tooling support in latter WSO2 ESB versions.
How existing systems participate in a messaging exchange, which places specific requirements in the message format, such as message header fields or encryption.
How to communicate with another system if the message originator does not have all the required data items available.
How to simplify dealing with a large message when you are interested only in a few data items.
How to reduce the data volume of a message sent across the system without sacrificing information content.
How to process messages that are semantically equivalent but arrive in a different format.
How to minimize dependencies when integrating applications that use different data formats.
How to encapsulate access to the messaging system from the rest of the application.
|Messaging Mapper||How to move data between domain objects and the messaging infrastructure, while keeping the two independent of each other.|
How a client controls its transactions with the messaging system.
How an application consumes a message when the application is ready.
How an application automatically consumes messages as they become available.
How a messaging client processes multiple messages concurrently.
How multiple consumers on a single channel coordinate their message processing.
How a message consumer selects which messages to receive.
How a subscriber avoids missing messages while it is not listening for them.
|How a message receiver deals with duplicate messages.|
How an application designs a service to be invoked via both messaging and non-messaging techniques.
Removes unwanted messages, which can disturb tests or running systems, from a channel.
Administers a messaging system that is distributed across multiple platforms and a wide geographic area.
Routes a message through intermediate steps to perform validation, testing or debugging functions.
Lists all applications that the message passed through since its origination.
Reports against message information without disturbing the loosely coupled and transient nature of a messaging system.
Tracks messages on a service that publishes reply messages to the Return Address specified by the requester.
Ensures the health of message processing components by preventing situations such as garbling outgoing messages due to an internal fault.
Inspects messages that travel on a Point-to-Point Channel.