|
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 6: Architectural Design Patterns
|
Home >
Chapter 6 Overview
|
Introduction
This chapter provides a set of patterns that address specific, yet still common design issues that pertain to the definition of service-oriented technology architecture implementations based on all of the architectural types established in Chapter 3.
Unlike the sequence-based structure of the pattern language in Chapter 5, these design patterns are presented in alphabetical order for reference purposes.
The design issues addressed by these patterns vary in both scope and complexity. While several provide techniques for overcoming design problems related to common architecture constraints (such as legacy encapsulation and infrastructure limitations), others introduce important architectural layers that build upon the foundation established by the Basic Inventory Architecture Pattern Language.
Note that several of these design patterns make reference to service design patterns covered in subsequent chapters. If you are new to SOA and service-orientation, you would benefit from reading through the service design pattern language in Chapter 7 prior to continuing.
The list below provides an overview of all the design patterns in this chapter.
|
|
|
Agnostic Sub-Controller
How can agnostic, cross-entity composition logic be separated, reused, and governed independently?
|
|
Asynchronous Queuing
How can a service and its consumers accommodate isolated failures and avoid unnecessarily locking resources?
|
|
Canonical Resources
How can unnecessary service resource design disparity be avoided?
|
|
Composition Autonomy
How can compositions be implemented to minimize loss of autonomy?
|
|
Cross-Domain Utility Layer
How can redundant utility logic be avoided across domain service inventories?
|
|
Cross-Service Transaction
How can a transaction be propagated across messaging-based services?
|
|
Data Format Transformation
How can services interact with programs that communicate with different data formats?
|
|
Data Model Transformation
How can services interoperate when using different data models for the same type of data?
|
|
Dual Protocols
How can an inventory be standardized and not limited to a single communications protocol?
|
|
Event-Driven Messaging
How can service consumers be automatically notified of runtime service events?
|
|
Intermediate Routing
How can dynamic runtime factors affect the path of a message?
|
|
Inventory Endpoint
How can a collection of services be shielded from external access while still offering their capabilities to external consumers?
|
|
Message-Level Security
How can message content be secured throughout a service activity?
|
|
Messaging Metadata
How can services be designed to consume activity state data at runtime?
|
|
Metadata Centralization
How can service metadata be centrally published and governed?
|
|
Partial State Deferral
How can services be designed to optimize resource consumption while still remaining stateful?
|
|
Process Centralization
How can abstracted business process logic be centrally governed?
|
|
Protocol Bridging
How can a service exchange data with consumers that use different communication protocols?
|
|
Redundant Implementation
How can the reliability and availability of a service be increased?
|
|
Reliable Messaging
How can a service communicate reliably with consumers when implemented in an unreliable environment?
|
|
Rules Centralization
How can business rules be abstracted and centrally governed?
|
|
Security Centralization
How can security-related logic be abstracted and centrally maintained?
|
|
Service Agent
How can event-driven logic be separated and governed independently?
|
|
Service Data Replication
How can service autonomy be preserved when services require access to shared data sources?
|
|
Service Messaging
How can services interoperate without forming persistent, tightly coupled connections?
|
|
State Repository
How can service state data be persisted for extended periods without consuming service runtime resources?
|
|
Stateful Services
How can service state data be persisted and managed without consuming service runtime resources?
|
|
|
| Prev | Next
|
|
|
