Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.
Functional Decomposition (Service Identification Pattern)
- Decomposes the business processes/tasks/problems to smaller ones
- Applies the separation of concerns
- Helps greatly in Service Analysis and Service Modelling
Service Encapsulation (Service Identification Pattern)
Agnostic Context (Service Definition Pattern)
Non Agnostic Context (Service Definition Pattern)
Agnostic Capability (Service Definition Pattern)
Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.
Process Centralization
Schema Centralization
Policy Centralization
Rules Centralization
Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.
Compatible Change
- This is the most frequently applied pattern once the Service is in maintenance phase.
- The intent should be to make the change backward compatible to the existing Service Consumers.
- Addition of new optional elements in the Schema is a Compatible change
- Similarly any new operations, renaming, adding more messages, policy changes have to be reviewed to make the changes compatible.
Version Identification
- Design the versioning of the service contract in such a way that the compatible and non compatible changes are expressed clearly to the service consumers.
- The typical convention is the decimal format with major and minor versions.
Termination Notification
- The scheduled expiry of service or operations can be expressed through Termination Notification.
- This can be expressed through WS Policy language through ignorable assertions
Service Refactoring
Service Decomposition
Proxy Capability
- When an existing Service has to be decomposed to multiple fine grained services then the original contract is still used as a Proxy so that the existing service Consumers can still be serviced while the new Service Consumers will start using the new decomposed Services.
Decomposed Capability
Distributed Capability
Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.
Since all the below patterns are incorporated by the SOAP Web Service and current Enterprise Service Buses they are not being elaborated here.
Service Messaging
Messaging Metadata
Service Agent
Intermediate Routing
State Messaging
Service Callback
Service Instance Routing
Asynchronous Queuing
Reliable Messaging
Event Driven Messaging
Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.
Enterprise Inventory
- Services developed in an enterprise are maintained in an Enterprise Service Inventory.
- This helps in standardized contracts, avoids creation of redundant services and easy governance.
Domain Inventory
- When Enterprise Inventory is not possible, then multiple Domain Inventories are created.
- The boundary of domain inventory needs to be carefully established. The boundary could be functional.
- Governance is established at the domain inventory level.
Service Normalization
- This pattern normalizes the existing Services that have overlapping functional boundaries.
- This is done by applying Logic Centralization and Service Abstraction
Logic Centralization
- This pattern targets the creation of Agnostic Service that have a clearly defined boundary.
- Helps in reuse and composability of these Services
Service Layers
Canonical Protocol
- Standardizes the transport and communication protocols for all services in the inventory.
- This is to enable reusability and composability (avoiding the costly protocol bridging)
- Example: WSDL, Schema, Policy, Transport(HTTP), Communication(SOAP) versions.
Canonical Schema
- Standardizes the schema definitions in a service inventory.
- This avoids data model transformation, redundant data definitions and helps in governance
Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.
Legacy Wrapper
- Legacy systems expose the access through wrapper services which do not have a standardized contract and have tight contract to logic coupling and little abstraction.
- This is fixed by wrapping the legacy system with a new legacy wrapper service that has a standardized contract, loose coupling and abstraction.
Multi-Channel Endpoint
File Gateway
Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.
Decoupled Contract
- A contract created by "contract first" approach decouples the Service Contract from the Service Logic.
Contract Centralization
- Service Contract has to be the sole point to access the Service Logic
Contract Denormalization
Concurrent Contracts
