|
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
|
Introduction
The patterns in this chapter are fundamental to defining a service-oriented architectural model with an emphasis on service inventory architecture. The design problems solved structure the architecture for the sole purpose of establishing a flexible and agile environment suitable for solution logic designed in accordance with the service-orientation paradigm.
As shown in Figure 5.x, there is a natural application sequence that assembles all of these patterns into a formal design pattern language, as follows:
|
1.
|
Inventory Context Design Patterns – The context of the planned technology architecture is established first because it can enable or inhibit the realization of subsequent patterns.
|
|
2.
|
Inventory Boundary Design Patterns – The scope of an architecture is subsequently defined by identifying the boundary of its corresponding inventory and related characteristics.
|
|
3.
|
Inventory Structure Design Patterns – The high-level structure and the overall complexion of the inventory itself is then determined, which further influences the requirements that the architecture implementation will need to fulfill.
|
|
4.
|
Inventory Standardization Design Patterns – Key inventory-wide design standards are established to ensure a baseline level of service interoperability.
|
The design patterns within a given group are explained at the beginning of each of the upcoming sections.
The list below provides an overview of all the design patterns in this chapter.
Business-Driven Context
How can a technology architecture be designed to remain in alignment with changing business goals and
requirements?
|
|
Vendor-Agnostic Context
How can a technology architecture be designed to avoid inhibiting dependencies on proprietary vendor platforms?
|
|
Enterprise Inventory
How can services be delivered to maximize recomposition?
|
|
Domain Inventory
How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?
|
|
Service Normalization
How can an inventory be designed to avoid redundant service logic?
|
|
Logic Centralization
How can the misuse of redundant service logic be avoided?
|
|
Utility Abstraction
How can common utility logic be separated, reused, and independently governed?
|
|
Entity Abstraction
How can agnostic business logic be separated, reused, and governed independently?
|
|
Process Abstraction
How can non-agnostic process logic be separated and governed independently?
|
|
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
|
|
|
