The public review of the manuscript for "SOA Design Patterns" has concluded !
Thank you to all that participated. 234 reviews were received and over 30 new patterns have been contributed, increasing the size of this book by over 50%. The second draft of the manuscript is currently in development.
SOA Design Patterns by Thomas Erl
For more information visit: www.soapatterns.com
Related Publications
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.
How can a reusable
business data architecture be established?
Problem
Creating data models
(schemas) in support of entity services can result in a series of service-specific
data models that introduce redundancy and are only useful to the services.
Solution
Establish an entity data
architecture that exists independently from the federated service endpoint layer,
so that it can be normalized and used by both services and other parts of the
enterprise.
Application
Entity-centric schemas are
defined and standardized separately in support of service layers but also in
support of generic data representation.
Impacts
Not all schemas will be
appropriate for all services, which may lead to performance trade-offs or the
need to introduce redundant data models.
Principles
Standardized Service
Contract, Service Abstraction
Architecture
Inventory
Status
Suspended
Contributor
Thomas Erl
Contributor Notes
Although
this technique is common when designing data architectures as independent
layers in support of entity service layers, this design pattern seems like more
of a mildly specialized implementation of the Schema Centralization pattern.
I’m not certain whether a separate pattern dedicated to entity schema
abstraction is warranted.