|
Introduction to SOA Types & Design Patterns
|
|
Read the article "Introducing SOA Design Patterns" from the
June 2008 SOA World Magazine (High-Res PDF).
|
|
|
PLEASE NOTE
The content on this page is from the first draft of the manuscript for the upcoming book "SOA Design Patterns" by Thomas Erl. This version of the manuscript was authored in September, 2007. Since then, the manuscript has undergone significant content and structural changes as a result of an industry-wide review in which hundreds of SOA practitioners participated in addition to SOA vendors and experts from the design patterns community.
You are welcome to use the information on this page for research purposes, but you should assume that most of it will change in the final release of the "SOA Design Patterns" book.
Note also, that as a result of an industry-wide call for participation from December 2007 to February 2008, over 30 new design patterns have been contributed to this book. As they become finalized and are incorporated by the author, concise descriptions will be published on this site, and full descriptions with examples will be made available in the final, printed book.
Due to the volume of new content and changes, the release of the "SOA Design Patterns" book has been postponed to October, 2008. To learn more about the book, visit www.soapatterns.com. To be notified of updates to this site, use the notification form.
|
|
|
Chapter 5: Basic Service Inventory Design Pattern Language
|
Home >
Chapter 5 Overview >
5.4 Inventory Standardization Design Patterns
|
Inventory Standardization Design Patterns
As mentioned in Chapter 4, SOAGlossary.com defines design patterns and design standards as two separate but related parts of a typical design framework. A design pattern provides a proven solution to a common design problem and a design standard is a mandatory convention applied across multiple systems. Whereas a design pattern is industry-recognized, a design standard is internal and specific to an IT enterprise.
Even though they are distinct, design standards are a lot like design patterns. In fact, design standards can be seen as “pre-solving” specific design issues in order to ensure consistent system designs. It is therefore not uncommon for a design pattern to become the basis of design standard, which is essentially what this group of patterns is all about.
These next three patterns do not just propose possible solutions to common problems, they propose that to solve this set of specific problems, the solutions themselves must become actual design standards.
The pattern application sequence displayed above suggests that Canonical Protocol be applied prior to the Canonical Data Model pattern because the communications technology used represents the fundamental medium by which data (and associated data models) are delivered and processed. Canonical Interface Expression refines the service contract in support of the Service Discoverability design principle, and is therefore the final pattern in this pattern language.
Note that although conceptually similar, the three abstraction patterns are documented separately because each corresponds to a specific type of fundamental service logic for which an abstraction layer can be established individually.
This section covers the following design patterns:
Canonical Protocol
How can services be designed to avoid protocol bridging?
|
|
Canonical Data Model
How can services be designed to avoid data model transformation?
|
|
Canonical Expression
How can service contracts be consistently understood and interpreted?
|
|
|
|
Prev | Next
|
|
|
