Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series (Fowler))

by Hohpe Gregor

Name—This is an identifier for the pattern that indicates what the pattern does. We chose names that can easily be used in a sentence so that it is easy to reference the pattern’s concept in a conversation between designers.

Icon—Most patterns are associated with an icon in addition to the pattern name. Because many architects are used to communicating visually through diagrams, we provide a visual language in addition to the verbal language. This visual language underlines the composability of the patterns, as multiple pattern icons can be combined to describe the solution of a larger, more complex pattern.

Context—This section explains what type of work might make you run into the problem that this pattern solves. The context sets the stage for the problem and often refers ...

Problem—This explains the difficulty you are facing, expressed as a question. You should be able to read the problem statement and quickly determine if this pattern is relevant to your work. We’ve formatted the ...

Forces—The forces explore the constraints that make the problem difficult to solve. They often consider alternative solutions that seem promising but don’t pan out, wh...

Solution—This part explains what you should do to solve the problem. It is not limited to your particular situation, but describes what to do in the variety of circumstances represented by the problem. If you understand a pattern’s problem and solution, you understand the pattern. We’ve formatted the solution in the same style as the pr...

Sketch—One of the most appealing properties of the Alexandrian form is that each pattern contains a sketch that illustrates the solution. In many cases, just by looking at the pattern name and the sketch, you can understand the essence of the pattern. We tried to maintain this style by illustrating the sol...

Results—This part expands upon the solution to explain the details of how to apply the solution and how it resolves the forces. It also addresses new challenges that m...

Next—This section lists other patterns to be considered after applying the current one. Patterns don’t live in isolation; the application of one pattern usually leads you to new problems that are solved by other patterns. The relationships between patterns are wha...

The beauty in describing solutions as patterns is that it teaches you not only how to solve the specific problems discussed, but also how to create designs that solve problems the authors were not even aware of. As a result, these patterns for messaging not only describe messaging systems that exist today, but may also apply to new ones created well after this book is published.

When presenting example code, we focused on readability over runnability. A code segment can help remove any potential ambiguity left by the solution description, and many application developers and architects prefer looking at 30 lines of code to reading many paragraphs of text. To support this intent, we often show only the most relevant methods or classes of a potentially larger solution.

Enterprise integration solutions typically consist of a number of heterogeneous components spread across multiple systems. Likewise, most integration patterns do not operate in isolation but rely on other patterns to form a meaningful solution.

The pattern language in this book, as with any pattern language, is a web of patterns referring to each other. At the same time, some patterns are more fundamental than others, forming a hierarchy of big-concept patterns that lead to more finely detailed patterns.

The big-concept patterns form the load-bearing members of the pattern language. They are the main ones, the root patterns that provide the foundation of the language and support the other patterns.

Starting with a pattern in the middle of the language can be like starting to watch a movie that’s half over—you see what’s happening but don’t understand what it means.

Luckily, the pattern language is formed around the root patterns described earlier. These root patterns collectively provide an overview of the pattern language, and individually provide starting points for delving deep into the details of messaging. To get an overall survey of the language without reviewing all of the patterns, start with reviewing the root patterns

Keep in mind that when reading a pattern, if you’re in a hurry, start by just reading the problem and solution. This will give you enough information to determine if the pattern is of interest to you right now and if you already know the pattern.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

in an integrated enterprise application, groups no longer control a specific application because each application is now part of an overall flow of integrated applications and services.

six types of integration: • Information portals • Data replication • Shared business functions • Service-oriented architectures • Distributed business processes • Business-to-business integration

Information portals aggregate information from multiple sources into a single display to avoid having the user access multiple systems for information.

These two functions, service discovery and negotiation, are the key elements that make up a service-oriented architecture (SOA).

The core principle behind loose coupling is to reduce the assumptions two parties (components, applications, services, programs, users) make about each other when they exchange information.

“objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space”

Queuing requests inside the channel requires data to be chunked into self-contained messages so that the channel knows how much data to buffer and deliver at any one time. The two systems still depend on a common data format, but we can remove this dependency by allowing for data format transformations inside the channel. If the format of one system changes, we only have to change the transformer and not the other participating systems. This is particularly useful if many applications send data to the same channel.

Mechanisms such as a common data format, asynchronous communication across queuing channels, and transformers help turn a tightly coupled solution into a loosely coupled one.

Removing these dependencies between the systems makes the overall solution more tolerant to change, the key benefit of loose coupling. The main drawback of the loosely coupled approach is the additional complexity. This is no longer a 10-lines-of-code solution! Therefore, we use a message-oriented middleware infrastructure that provides these services for us.

Loose coupling provides important benefits such as flexibility and scalability, but it introduces a more complex programming model and can make designing, building, and debugging solutions more difficult.

In order to connect two systems via an integration solution, a number of issues have to be resolved. These functions make up what we call middleware—the glue that sits between applications.

Inside this channel, we place a message—a snippet of data that has an agreed-upon meaning to both applications that are to be integrated. This piece of data can be very small, such as the phone number of a single customer that has changed, or it can be very large, such as the complete list of all customers and their associated addresses.

Because the internal data format of an application can often not be changed, the middleware needs to provide some mechanism to convert one application’s data format in the other’s format. We call this step translation.

A Channel Adapter (127) is a component that can attach to an application and publish messages to a Message Channel (60) whenever an event occurs inside the application. With some Channel Adapters (127), the application may not even be aware of the presence of the adapter. For example, a database adapter may add triggers to specific tables so that every time the application inserts a row of data, a message is sent to the Message Channel (60). Channel Adapters (127) can also work in the opposite direction, consuming messages off a Message Channel (60) and triggering an action inside the application in response.

channels carrying canonical messages are named after the intent of the message without any prefix: for example, NEW_ORDER.

The New Order message itself is designed as a Document Message (147). The intent of the message is not to instruct the receiver to take a specific action, but rather to pass a document to any interested recipient, who is free to decide how to process the document.

Activity diagrams have relatively simple semantics and are a good tool to depict processes that include parallel activities. The notation is very simple; sequential activities are connected by simple arrows. Parallel activities are connected by a thick black bar representing fork and join actions. A fork action causes all connected activities to start simultaneously, while the join action continues only after all incoming activities have been completed.

A Content-Based Router (230) is a component that consumes a message and publishes it, unmodified, to a choice of other channels based on rules coded inside the router. The Content-Based Router (230) is equivalent to the branch in a UML activity diagram.

Using both a Splitter (259) and an Aggregator (268), we can logically separate the message flow for individual order items from the flow for a complete order.

When designing an Aggregator (268), we have to make three key decisions: • Which messages belong together (correlation)? • How do we determine that all messages are received (the completeness condition)? • How do we combine the individual messages into one result message (the aggregation algorithm)?

A Content Enricher (336) is a component that adds missing data items to an incoming message. In our case, the Content Enricher (336) adds a unique order ID to the message.

Now, the Message Store (555) is responsible for maintaining data related to the new message as well as the progress of the message within the process. This data gives us enough information to use the Message Store (555) to determine the next required steps in the process rather than connecting components with fixed Message Channels (60).

A Process Manager (312) is a central component that manages the flow of messages through the system.

The Process Manager (312) provides two main functions: • Storing data between messages (inside a “process instance”) • Keeping track of progress and determining the next step (by using a “process template”)

This architecture turns the individual systems (e.g., the inventory systems) into shared business functions that can be accessed by other components as services, thus increasing reuse and simplifying maintenance. The services can be wired together via a message flow (for example, using a Composed Message Processor (294) to check inventory status for each order item) or orchestrated via a Process Manager (312).

The new architecture exposes all services to a common services bus so that they can be invoked from any other component.

Each request-reply service also needs to support the concept of a Return Address (159). A Return Address (159) allows the caller (the service consumer) to specify the channel where the service should send the reply message. This is important to allow the service to be reused in different contexts, each of which may require its own channel for reply messages.

This form of Shared Database (47) is the simplest and most efficient approach, and we are always ensured that the Web interface displays the most current status. The potential downside of this approach is that the Web interface is tightly coupled to the database, a trade-off that we are willing to take.

The Smart Proxy (558) can store information from the request message (e.g., the Return Address [159] specified by the requestor) and use this information to process the reply message, (e.g., route it to the correct reply channel). A Smart Proxy (558) is also very useful to track quality of service (e.g., response times) of an external service.

Whenever the address information changes in the Web interface, we propagate the changes to all interested systems using a Publish-Subscribe Channel (106).

Because we are dealing with multiple types of addresses (shipping and billing addresses), we need to make sure that only the right type of address is stored in each system. We need to avoid sending an address change message to the shipping system if the address is a billing address. We accomplish this by using Message Filters (237) that pass only messages matching certain criteria (see figure).

We also use Message Translators (85) to translate the generic Address Change message into the specific message format used by the applications. In this case, we do not have to use a Message Translator (85) for the Web interface because we define the Canonical Data Model (355) as equal to the format of the Web interface application. This could limit our flexibility if we want to introduce other ways of changing addresses in the future, but for now it is sufficient.