Overview

The simplest way to describe a pattern is that it provides a proven solution to a common problem individually documented in a consistent format and usually as part of a larger collection.

The notion of a pattern is already a fundamental part of everyday life. Without acknowledging it each time, we naturally use proven solutions to solve common problems each day. Patterns in the IT world that revolve around the design of automated systems are referred to as design patterns.

Design patterns are helpful because they:

• represent field-tested solutions to common design problems
• organize design intelligence into a standardized and easily “referencable” format
• are generally repeatable by most IT professionals involved with design
• can be used to ensure consistency in how systems are designed and built
• can become the basis for design standards
• are usually flexible and optional (and openly document the impacts of their application and even suggest alternative approaches)
• can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied)
• can sometimes be applied prior and subsequent to the implementation of a system
• can be supported via the application of other design patterns that are part of the same collection
• enrich the vocabulary of a given IT field because each pattern is given a meaningful name

Furthermore, because the solutions provided by design patterns are proven, their consistent application tends to naturally improve the quality of system designs.

Note that even though design patterns provide proven design solutions, their mere use cannot guarantee that design problems are always solved as required. Many factors weigh in to the ultimate success of using a design pattern, including constraints imposed by the implementation environment, competency of the practitioners, diverging business requirements, and so on. All of these represent aspects that affect the extent to which a pattern can be successfully applied.

Pattern Notation

The SOA design patterns catalog uses a simple notation to consistently represent different types of patterns.

Pattern Symbols

When working with SOA design patterns, slightly different symbols are used to represent:

• a design pattern
• a compound design pattern
• a group of related design patterns

Additionally, colors are incorporated to indicate if a displayed design pattern is just being referenced and not actually discussed, versus one that is the current topic of discussion.

These symbols are used throughout the SOA Design Patterns book, especially in pattern relationship diagrams. On this Web site you will notice them primarily when compound patterns are discussed.

Pattern Figures

The aforementioned pattern symbols are used in the following three primary types of diagrams:

• proposed pattern application sequences
• pattern relationships
• compound pattern hierarchies

Let’s take a closer look at each of these three primary diagram types:

Pattern Application Sequence Figures

When documenting recommended pattern application sequences, groups of related patterns and for individual patterns belonging to a particular group are displayed as follows:

Pattern Relationship Figures

Each pattern is documented with a inter-pattern relationships diagram, as shown here:

A style convention applied to all pattern relationship diagrams is the use of color, as follows:

• Each pattern relationship diagram explores the relationships of one pattern. Therefore, that design pattern is highlighted in red, as per the previously established symbol notation.
• Pattern relationships are documented in a unidirectional manner. For relationships where the pattern currently being discussed affects or relates to other patterns, a red line is used along with an arrow pointing to the other pattern. When the relationship line documents how other patterns relate to the current pattern, the lines are green, and the arrows are reversed.

Note that directionality of relationships is preserved in different diagrams. For example, the green relationship line emitting from Service Normalization and pointing to Logic Centralization in the preceding figure would be reversed (and colored red) in the pattern relationship figure for the Service Normalization pattern. Note that pattern relationship diagrams are provided in the book only.

Compound Pattern Hierarchy Figure

Compound patterns are comprised of combinations of design patterns. When illustrating a compound pattern, a hierarchical representation is usually required, where the compound pattern name is displayed at the top, and the patterns that comprise the compound are shown underneath.

These types of diagrams can be considered simplified relationship figures in that they only identify which patterns belong to which compound, without getting into the details of how these patterns relate.

Pattern Profile

In addition to the pattern name and the name of its contributor(s), each of the patterns in this catalog is described using a consistent profile format and structure based on the following parts:

• Requirement
• Icon
• Summary Table
• Principles
• Architecture
• Problem
• Solution
• Application
• Impacts
• Relationships
• Case Study Example

The following sections describe each part of a pattern profile individually. Note that as per Prentice Hall publishing requirements, only the Requirement, Icon, Summary Table, a sample figure, and links to related patterns are published for each pattern on this Web site for patterns that are part of the master catalog. The detailed sections, case study examples, relationship diagrams, and additional supplementary content are provided in the book. Because candidate patterns are published for review purposes, more detailed information is sometimes made available.

Requirement

A requirement is a concise, single-sentence statement that presents the fundamental requirement addressed by the pattern in the form of a question. Every pattern description begins with this statement.

An example of a requirement statement:

How can a service be designed to minimize the chances of capability logic deconstruction?

Icon

Each pattern description is accompanied by an icon image that acts as a visual identifier.

An example of a pattern icon:

The icons are displayed together with the requirement statements in each pattern profile as well as on the inside book cover.

Summary Table

Following the requirement statement, a summary table is displayed, comprised of statements that collectively provide a concise synopsis of the pattern for quick reference purposes.

The following parts of the profile are summarized in this table:

• Problem
• Solution
• Application
• Impacts

Additionally, the profile table provides references to related service-orientation design principles and service-oriented architectural types via the following sections:

• Principles
• Architecture

The parts of the pattern description not represented in the summary table are the Relationships and Case Study Example sections.

Problem

The issue causing a problem and the effects of the problem are described in this section, which is typically accompanied by a figure that further illustrates the “problem state.” It is this problem for which the pattern is expected to provide a solution. Often included with problem descriptions are common circumstances that can lead to the problem (also known as “forces”).

Solution

This represents the design solution proposed by the pattern to solve the problem and fulfill the requirement. Often the solution is a short statement followed by a diagram that concisely communicates the final solution state. “How-to” details are not provided in this section but are instead located in the Application section.

Application

This part is dedicated to describing how the pattern can be applied. In can include guidelines, implementation details, and sometimes even a suggested process.

Impacts

Most patterns come with trade-offs. This section highlights common consequences, costs, and requirements associated with the application of a pattern and may also provide alternatives that can be considered.

Note that these consequences are common but not necessarily predictable. For example, issues related to common performance requirements are often raised; however, these issues may not impact an environment with an already highly scalable infrastructure.

SOA Patterns and Application Technologies

It is important to view and position SOA as an architectural model that is neutral to any one technology platform and service-orientation as a paradigm that is neutral to any distributed implementation medium. By doing so, you have the freedom to continually pursue the strategic goals associated with SOA and service-orientation by leveraging on-going technology advancements.

For example, a service can be built and implemented as a component, a SOAP-based Web service, or a REST service. Essentially, any implementation technology that can be used to create a distributed system may be suitable for service-orientation. Many of the design patterns in this catalog are not specific to any one of these three implementation mediums, but some are. Several examples are based on the use of SOAP-based Web services because this service implementation medium has been historically the most popular. This does not preclude you from applying the patterns with other suitable technologies. Some patterns in particular can be carried out with vendor-specific products and technologies that rely on alternative communication protocols and APIs that are not based on industry standards.

When deciding on what technologies to use for a given pattern, it can be helpful to take some of the standards-related patterns into account, such as Canonical Protocol, Dual Protocols, Canonical Resources, and Canonical Schema. These types of patterns can provide regulatory guidance to help you establish some baseline criteria for technology selection.

To view the Design Patterns text list click here.