Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

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.

Table 3.1. Messaging Systems
Icon	Name	Use Case
	Figure 5.1, “Message Pattern”	How can two applications connected by a message channel exchange a piece of information?
	Figure 5.2, “Message Channel Pattern”	How does one application communicate with another application using messaging?
	Figure 5.3, “Message Endpoint Pattern”	How does an application connect to a messaging channel to send and receive messages?
	Figure 5.4, “Pipes and Filters Pattern”	How can we perform complex processing on a message while still maintaining independence and flexibility?
	Figure 5.7, “Message Router Pattern”	How can you decouple individual processing steps so that messages can be passed to different filters depending on a set of defined conditions?
	Figure 5.8, “Message Translator Pattern”	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.

Table 3.2. Messaging Channels
Icon	Name	Use Case
	Figure 6.1, “Point to Point Channel Pattern”	How can the caller be sure that exactly one receiver will receive the document or will perform the call?
	Figure 6.2, “Publish Subscribe Channel Pattern”	How can the sender broadcast an event to all interested receivers?
	Figure 6.3, “Dead Letter Channel Pattern”	What will the messaging system do with a message it cannot deliver?
	Figure 6.4, “Guaranteed Delivery Pattern”	How does the sender make sure that a message will be delivered, even if the messaging system fails?
	Figure 6.5, “Message Bus Pattern”	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.

Table 3.3. Message Construction
Icon	Name	Use Case
	the section called “Overview”	How does a requestor identify the request that generated the received reply?
	Section 7.3, “Return Address”	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).

Table 3.4. Message Routing
Icon	Name	Use Case
	Section 8.1, “Content-Based Router”	How do we handle a situation where the implementation of a single logical function (for example, inventory check) is spread across multiple physical systems?
	Section 8.2, “Message Filter”	How does a component avoid receiving uninteresting messages?
	Section 8.3, “Recipient List”	How do we route a message to a list of dynamically specified recipients?
	Section 8.4, “Splitter”	How can we process a message if it contains multiple elements, each of which might have to be processed in a different way?
	Section 8.5, “Aggregator”	How do we combine the results of individual, but related messages so that they can be processed as a whole?
	Section 8.6, “Resequencer”	How can we get a stream of related, but out-of-sequence, messages back into the correct order?
	Section 8.14, “Composed Message Processor”	How can you maintain the overall message flow when processing a message consisting of multiple elements, each of which may require different processing?
	Section 8.15, “Scatter-Gather”	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?
	Section 8.7, “Routing Slip”	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?
	Section 8.8, “Throttler”	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?
	Section 8.9, “Delayer”	How can I delay the sending of a message?
	Section 8.10, “Load Balancer”	How can I balance load across a number of endpoints?
	Section 8.11, “Hystrix”	How can I use a Hystrix circuit breaker when calling an external service? New in Camel 2.18.
	Section 8.12, “Service Call”	How can I call a remote service in a distributed system by looking up the service in a registry? New in Camel 2.18.
	Section 8.13, “Multicast”	How can I route a message to a number of endpoints at the same time?
	Section 8.16, “Loop”	How can I repeat processing a message in a loop?
	Section 8.17, “Sampling”	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.

Table 3.5. Message Transformation
Icon	Name	Use Case
	Section 10.1, “Content Enricher”	How do I communicate with another system if the message originator does not have all required data items?
	Section 10.2, “Content Filter”	How do you simplify dealing with a large message, when you are interested in only a few data items?
	Section 10.4, “Claim Check EIP”	How can we reduce the data volume of messages sent across the system without sacrificing information content?
	Section 10.3, “Normalizer”	How do you process messages that are semantically equivalent, but arrive in a different format?
	Section 10.5, “Sort”	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.

Table 3.6. Messaging Endpoints
Icon	Name	Use Case
	Section 11.1, “Messaging Mapper”	How do you move data between domain objects and the messaging infrastructure while keeping the two independent of each other?
	Section 11.2, “Event Driven Consumer”	How can an application automatically consume messages as they become available?
	Section 11.3, “Polling Consumer”	How can an application consume a message when the application is ready?
	Section 11.4, “Competing Consumers”	How can a messaging client process multiple messages concurrently?
	Section 11.5, “Message Dispatcher”	How can multiple consumers on a single channel coordinate their message processing?
	Section 11.6, “Selective Consumer”	How can a message consumer select which messages it wants to receive?
	Section 11.7, “Durable Subscriber”	How can a subscriber avoid missing messages when it’s not listening for them?
	Section 11.8, “Idempotent Consumer”	How can a message receiver deal with duplicate messages?
	Section 11.9, “Transactional Client”	How can a client control its transactions with the messaging system?
	Section 11.10, “Messaging Gateway”	How do you encapsulate access to the messaging system from the rest of the application?
	Section 11.11, “Service Activator”	How can an application design a service to be invoked by various messaging technologies as well as by non-messaging techniques?