Master SOA Design
Pattern Catalog
|
|
"Introducing SOA Design Patterns", SOA World Magazine (PDF)
"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)
"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)
"Service Facade", InformIT (HTML)
"Non-Agnostic Context", InformIT (HTML)
"Domain Inventory", InformIT (HTML)
"Service Normalization", InformIT (HTML)
"Service Decomposition", InformIT (HTML)
"Canonical Schema", InformIT (HTML)
"Policy Centralization", InformIT (HTML)
|
|
|
Pattern Profiles
|
Home >
Pattern Profiles
|
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.
Relationships
The use of design patterns can tie into all aspects of design and architecture. It is important to understand the requirements and dependencies a pattern may have and the effects of its application upon other patterns. This section is therefore dedicated to documenting key pattern relationships. On this Web site pattern relationships are highlighted via the Related Patterns section on the bottom of each pattern page.
The content in this section is not exhaustive in that not all possible relationships a given design pattern can have are covered. This section highlights key relationships only, with an emphasis on how patterns support or depend on each other.
For an example of a relationship figure, see the Pattern Notation page.
Case Study Example
Almost all pattern profiles conclude with a case study example that demonstrates the sample application of a pattern in relation to the overall case study storylines.
|
|
|
