|
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.3 Inventory Structure Design Patterns
|
Inventory Structure Design Patterns
Once the inventory boundary is determined, the complexion and organization of the inventory itself needs to be defined on a fundamental level. The next set of patterns helps define the underlying inventory structure by establishing basic service boundaries and classifications.
The Service Normalization and Logic Centralization patterns shown in Figure 5.x influence the inventory structure by requiring that future services be in alignment with each other and that future agnostic services in particular be positioned as the sole endpoint for the logic they represent.
The three abstraction patterns establish standardized service layers within the inventory, resulting in the creation of logical intra-inventory domains that themselves can be relatively independently evolved. This can lead to somewhat of a loose coupling between the domains represented by the abstracted service layers.
There is no proposed sequence when it comes to the application of the three abstraction patterns. At the architectural definition stage, these patterns simply establish the layers that will be modeled based on whatever methodology is employed by the project team.
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.
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?
|
|
|
|
Prev | Next
|
|
|
