| Throughout this book, integration patterns are often utilized to describe how concepts are put to use in an ESB. Some up-front explanations of the term "pattern" and this book's use of pattern notation are warranted. A pattern is a popular concept in software construction. The concept of using a pattern to build things actually originates from other engineering disciplines that predate computers and software, and was originally made popular by Christopher Alexander, author of A Pattern Language. When building a skyscraper, for example, there are certain repeatable methods to connect the steel girders. These methods can then be used in a larger architecture to form a building. Patterns for creating software architectures are similar, and have been explored in books such as Design Patterns by Erich Gamma, et al., and Patterns in Enterprise Application Architecture by Martin Fowler. More recently, the idea of messaging patterns has been popularized by Gregor Hohpe, et al., in Enterprise Integration Patterns, a great book that describes a series of integration patterns that are built upon low-level, message-oriented middleware. When building a service-oriented integration network using an ESB, there are certain ways to combine individual integration components for example, by using a data transformation service or content-based routing service to form repeatable and reusable patterns that can be built upon throughout the integration substrate. Chapter 11 conveys some examples of common integration patterns being used in ESB deployments today, and other chapters also explore ESB integration patterns in the context of the concepts being discussed. Although this book by no means covers all the patterns in use today, it should give you an idea of how an ESB can combine integration components to solve a variety of everyday integration problems. Refer to the links on this book's O'Reilly web page, http://www.oreilly.com/catalog/esb, for an ongoing list of ESB patterns, and for errata on the existing ones. A pattern description must follow certain conventions so that it is easily identifiable, easily understood, and easily communicated among engineers when discussing the larger issues that patterns can help to solve. This book uses the following form when describing patterns. (Some of this is borrowed from Alexander's, Hohpe's, and Fowler's books.)
- Pattern Name
-
The name of the pattern. This makes it easily identifiable and referenceable in other patterns, and helps to provide a vocabulary for engineers to use when discussing architectures that make use of patterns.
- Problem Statement
-
A summary of the problem that the pattern solves.
- Forces
-
Circumstances surrounding the problem that contribute to the need for the solution the pattern offers.
- Sketch
-
A drawing or diagram that illustrates the pattern in a simple, understandable form.
- Solution
-
A description of how the pattern solves the proposed problem.
- Alternative Approaches
-
Other approaches, which are often less than adequate, that could have been used to solve the problem.
- Variations
-
Alternate ways to apply or augment the pattern. Variations can also manifest themselves as choices that can be made in the makeup of the pattern, such as publish-and-subscribe versus point-to-point messaging models. Variations can often result in a whole new pattern with a unique name.
You won't necessarily find these as headings when reading through the patterns, but each pattern has these elements whenever possible. Diagramming Notations To describe the integration patterns used in this book, a simple set of glyphs were created to visually represent the different components of an ESB. These glyphs borrow from the work done by Gregor Hohpe, et al., in Enterprise Integration Patterns. These "Gregorgrams," as they have come to be known, are gaining rapid adoption in the industry as a means for describing messaging components and common integration patterns. This book uses some of the glyphs from Enterprise Integration Patterns, and also supplies a whole new set of glyphs that represent many of the higher-level concepts and constructs used by the ESB. There is a parallel between the icons in Enterprise Integration Patterns and the concepts they represent, and the icons in this book and the ESB concepts that they represent. Many of the integration patterns described in Enterprise Integration Patterns such as content-based routers, load-balanced queue receivers, or routing slips are implemented as custom messaging client code built on top of a messaging infrastructure. An ESB provides these same capabilities as built-in functionality, either as part of the bus directly or as an out-of-the-box service to be plugged into the bus. Therefore, the glyphs used in this book represent those pluggable services and are designed to be plugged together to form ESB diagrams. The diagrams can represent abstract pattern sketches or physical deployment characteristics, or can be a combination of both. A legend showing all the glyphs that were created for use by this book is shown in the included reference card. The glyphs in this book were designed with these goals in mind: To create a visual diagramming notation for explaining the core concepts of an ESB To allow you, the integration architect, to have a common means of designing your own integration patterns using an ESB To have a visual pattern language for documenting integration designs for legacy purposes
With these primary goals in mind, the icons also have these secondary uses: To show physical deployment characteristics of an ESB architecture To show message flow and business process routing for messages as they travel across an ESB To abstractly illustrate a pattern sketch for an integration environment, which describes the steps that a business message goes through as it travels across the various components of an automated business process
I plan to keep an updated set of these glyphs at http://www.oreilly.com/catalog/esb. They will be packaged as templates that can be plugged into Visio and PowerPoint so you can use them to diagram your own ESB architectures and integration patterns. Figure P-1 shows examples of using the glyphs to show the details of individual ESB components. This figure will be explained in more detail in Chapter 6. Figure P-1. Generic ESB endpoint 
These glyphs can be combined to show composite components, as illustrated in Figure P-2. Figure P-2. Diagramming notation used to show the subcomponents of a composite ESB service 
The diagramming notation can also be used to abstractly describe the components that make up an integration pattern, in the form of a pattern sketch. The particular pattern sketch convention was made popular by Enterprise Integration Patterns, and is akin to the way a rebus puzzle is formed. See Figure P-3. Figure P-3. Rebus puzzle 
When the rebus puzzle concept is applied to an integration pattern sketch, it can show the components that make up the pattern, and the steps that a message goes through as it follows the pattern (i.e., passes through the steps of a business process). This is illustrated in Figure P-4. Figure P-4. Abstract pattern sketch showing the components that make up an integration pattern and the stages of processing for a message 
These glyphs can also be used together to show illustrations of physical deployment characteristics. For example, Figure P-5 shows different types of applications being plugged into different ESB segments, which may be different departments or business units, or separated by geographic location. Figure P-5. An ESB diagram showing physical deployment characteristics of geographic separation, and different application endpoint types 
The notation can also be used to represent flow of data across an ESB, either as messaging distribution or as multiple steps in an ESB process flow, as illustrated in Figure P-6 and Figure P-7, respectively. Figure P-6. Diagramming notation showing publish-and-subscribe messaging across an ESB 
Figure P-7. Diagramming notation showing multiple steps in a process flow 
Finally, the visual representations of the abstract patterns, the process flow descriptions, and the physical characteristics of the bus and its components may be combined, as illustrated in Figure P-8. Figure P-8. Using the diagramming notation to describe the abstract pattern definition combined with the process flow definition 
Some of these diagrams may look complex at first; their meanings should become clearer when they are used to explain the concepts of the ESB throughout the book. Seeing the concepts illustrated in these diagrams will help you to understand what an ESB is, and how it is being used in real integration projects today. | 