4.5 Types of Patterns

Basic Patterns

Basic design patterns solve basic problems. Collectively, these patterns establish foundational underpinnings for the design of whatever architectural type (inventory, service, etc.) they may be related to. Basic patterns are therefore more common and easier to understand than specialized patterns. Despite their simplicity, however, their real life application can often be daunting. Studying these patterns can reveal some of the most significant platform shifts required by SOA and service-orientation.

The two pattern languages documented in this book consist solely of basic design patterns (which is why they are labeled as Òbasic design pattern languagesÓ). The fact that these basic patterns are organized into sequences makes them very suitable for learning purposes. In fact, you could consider these two patterns languages as fundamental SOA theory. They provide detailed insight into the distinct design characteristics, runtime dynamics, and governance issues of inventory and service designs.

Specialized Patterns

Design patterns that address problems specific to certain circumstances or requirements are considered specialized. Most of the patterns in this catalog fall under this category, although they are not explicitly classified as such.

The majority of design patterns in Chapters 6 and 8 in particular are specialized. These patterns essentially extend and build upon the foundation established by the design pattern languages in Chapters 5 and 7.

Canonical Patterns

Canonical design patterns propose that the best solution for a particular problem is to introduce a design standard. The successful application of this type of pattern results in a canonical convention that guarantees consistent design across different parts of an inventory or solution.

The canonical design patterns in this book are:

•     Canonical Protocol

•     Canonical Data Model

•     Canonical Interface Expression

•     Canonical Resources

Centralization Patterns

Centralization simply means limiting the options of something to one. Applying this concept in key parts of a service-oriented architecture establishes consistency and fosters standardization and compatibility and, ultimately, native interconnectivity.

The following centralization patterns are covered in the upcoming chapters:

•     Logic Centralization

•     Metadata Centralization

•     Process Centralization

•     Resource Centralization

•     Rules Centralization

•     Security Centralization

•     Schema Centralization

•     Contract Centralization

•     Policy Centralization

A common characteristic across centralization patterns is a trade-off between increased architectural harmony and increased governance and performance requirements. As explained shortly in the Measures of Pattern Application section, patterns can be applied to different extents. A key factor when assessing the application measure for centralization patterns is at what point the benefit outweighs the architectural impact.

Compound Patterns

Most patterns can be combined in creative ways to solve broader, more complex problems. Chapter 9 documents a collection of compound patterns that represent and describe common pattern combinations.