Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 3. Introducing Enterprise Integration Patterns
Abstract
The Apache Camel’s Enterprise Integration Patterns are inspired by a book of the same name written by Gregor Hohpe and Bobby Woolf. The patterns described by these authors provide an excellent toolbox for developing enterprise integration projects. In addition to providing a common language for discussing integration architectures, many of the patterns can be implemented directly using Apache Camel’s programming interfaces and XML configuration.
3.1. Overview of the Patterns
Enterprise Integration Patterns book
Apache Camel supports most of the patterns from the book, Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.
Messaging systems
The messaging systems patterns, shown in Table 3.1, “Messaging Systems”, introduce the fundamental concepts and components that make up a messaging system.
Icon | Name | Use Case |
---|---|---|
| How can two applications connected by a message channel exchange a piece of information? | |
| How does one application communicate with another application using messaging? | |
| How does an application connect to a messaging channel to send and receive messages? | |
| How can we perform complex processing on a message while still maintaining independence and flexibility? | |
| How can you decouple individual processing steps so that messages can be passed to different filters depending on a set of defined conditions? | |
| How do systems using different data formats communicate with each other using messaging? |
Messaging channels
A messaging channel is the basic component used for connecting the participants in a messaging system. The patterns in Table 3.2, “Messaging Channels” describe the different kinds of messaging channels available.
Icon | Name | Use Case |
---|---|---|
| How can the caller be sure that exactly one receiver will receive the document or will perform the call? | |
| How can the sender broadcast an event to all interested receivers? | |
| What will the messaging system do with a message it cannot deliver? | |
| How does the sender make sure that a message will be delivered, even if the messaging system fails? | |
| What is an architecture that enables separate, decoupled applications to work together, such that one or more of the applications can be added or removed without affecting the others? |
Message construction
The message construction patterns, shown in Table 3.3, “Message Construction”, describe the various forms and functions of the messages that pass through the system.
Icon | Name | Use Case |
---|---|---|
| How does a requestor identify the request that generated the received reply? | |
| How does a replier know where to send the reply? |
Message routing
The message routing patterns, shown in Table 3.4, “Message Routing”, describe various ways of linking message channels together, including various algorithms that can be applied to the message stream (without modifying the body of the message).
Icon | Name | Use Case |
---|---|---|
| How do we handle a situation where the implementation of a single logical function (for example, inventory check) is spread across multiple physical systems? | |
| How does a component avoid receiving uninteresting messages? | |
| How do we route a message to a list of dynamically specified recipients? | |
| How can we process a message if it contains multiple elements, each of which might have to be processed in a different way? | |
| How do we combine the results of individual, but related messages so that they can be processed as a whole? | |
| How can we get a stream of related, but out-of-sequence, messages back into the correct order? | |
| How can you maintain the overall message flow when processing a message consisting of multiple elements, each of which may require different processing? | |
How do you maintain the overall message flow when a message needs to be sent to multiple recipients, each of which may send a reply? | ||
| How do we route a message consecutively through a series of processing steps when the sequence of steps is not known at design-time, and might vary for each message? | |
How can I throttle messages to ensure that a specific endpoint does not get overloaded, or that we don’t exceed an agreed SLA with some external service? | ||
How can I delay the sending of a message? | ||
How can I balance load across a number of endpoints? | ||
How can I use a Hystrix circuit breaker when calling an external service? New in Camel 2.18. | ||
How can I call a remote service in a distributed system by looking up the service in a registry? New in Camel 2.18. | ||
How can I route a message to a number of endpoints at the same time? | ||
How can I repeat processing a message in a loop? | ||
How can I sample one message out of many in a given period to avoid overloading a downstream route? |
Message transformation
The message transformation patterns, shown in Table 3.5, “Message Transformation”, describe how to modify the contents of messages for various purposes.
Icon | Name | Use Case |
---|---|---|
| How do I communicate with another system if the message originator does not have all required data items? | |
| How do you simplify dealing with a large message, when you are interested in only a few data items? | |
| How can we reduce the data volume of messages sent across the system without sacrificing information content? | |
| How do you process messages that are semantically equivalent, but arrive in a different format? | |
How can I sort the body of a message? |
Messaging endpoints
A messaging endpoint denotes the point of contact between a messaging channel and an application. The messaging endpoint patterns, shown in Table 3.6, “Messaging Endpoints”, describe various features and qualities of service that can be configured on an endpoint.
Icon | Name | Use Case |
---|---|---|
How do you move data between domain objects and the messaging infrastructure while keeping the two independent of each other? | ||
| How can an application automatically consume messages as they become available? | |
| How can an application consume a message when the application is ready? | |
| How can a messaging client process multiple messages concurrently? | |
| How can multiple consumers on a single channel coordinate their message processing? | |
| How can a message consumer select which messages it wants to receive? | |
| How can a subscriber avoid missing messages when it’s not listening for them? | |
How can a message receiver deal with duplicate messages? | ||
| How can a client control its transactions with the messaging system? | |
| How do you encapsulate access to the messaging system from the rest of the application? | |
| How can an application design a service to be invoked by various messaging technologies as well as by non-messaging techniques? |
System management
The system management patterns, shown in Table 3.7, “System Management”, describe how to monitor, test, and administer a messaging system.
Icon | Name | Use Case |
---|---|---|
| How do you inspect messages that travel on a point-to-point channel? |