WSO2 has recently published a library of documentation on the list of enterprise integration patterns (EIP) with WSO2 ESB.
The documentation comprehensively covers the complete domain, and each pattern is detailed with how they can be implemented with WSO2 ESB mediators, along with samples and images.
For example, the following is an extract from the Message Store EIP page, showing an example scenario with WSO2 ESB.
Each page is packed with a sample scenario, along with a sample implementation each, and makes developers life easy, both to learn the concepts in general, as well as to use WSO2 ESB to implement those in practice.
Following is the complete list of EIP library entries on WSO2 ESB documentation page.
Messaging Systems
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. |
Messaging Channels
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. |
Message Construction
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. | ||
How a message’s data format can be designed to allow for possible future changes. |
Message Routing
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 get a stream of related but out-of-sequence messages back into the correct order. | ||
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. |
Message Transformation
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. |
Messaging Endpoints
How to encapsulate access to the messaging system from the rest of the application. | ||
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. |
System Management
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. |
Comments