SOA : Design Patterns : Foundational Service Design Patterns

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)

• If Service oriented design principles (http://oracle-bpel.blogspot.com/2010/04/soa-design-principles.html) can be applied to a meaningful extent then the logic can be encapsulated as a Service. 

Agnostic Context (Service Definition Pattern)


Non Agnostic Context (Service Definition Pattern)


Agnostic Capability (Service Definition Pattern)

SOA : Design Patterns : Inventory Centralization Design Patterns

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

SOA : Design Patterns : Service Governance Design Patterns

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

SOA : Design Patterns : Service Messaging Design Patterns

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

SOA : Design Patterns : Inventory Design Patterns

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

• Same as Service Modelling. http://oracle-bpel.blogspot.com/2010/04/soa-service-modelling.html 

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

SOA : Design Patterns : Legacy Encapsulation Design Patterns

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

SOA : Design Patterns : Service Contract Design Patterns

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

Validation Abstraction

SOA : Design Patterns : Service Implementation Patterns

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.

Service Facade

• If a Service Logic supports multiple Service Contracts then a Service Facade Logic helps to reduce the coupling between the Service Contracts and the Service Logic. This will help in the evolution of the Service Logic without affecting the Service Contracts as the Service Facade accommodates any changes.
• The Service Facade Logic is primarily responsible for providing intermediate processing logic in support of the core Service Logic.

Redundant Implementation

• Making multiple instances of the Service available so that it does not become a single point of failure.
• Clustering of nodes and routing through ESB solves this issue

Service Data Replication

• Requires replication of data so that it improves the Autonomy of the Service and improves the performance of the Service 

Partial State Deferral


Partial Validation


UI Mediator

SOA : Design Principles

The following service oriented principles should be applied to the extent possible so that the benefits of SOA can be realized.

1. Standardized Service Contracts

• A SOAP Web Service has the following as part of the contract
• WSDL
• XSD
• WS Policy
• SLA (Service Level Agreement)
• Service Contract is standardized through the application of design standards(contract first approach)
• Standardized naming conventions(expressive)
• Standardized data types(reduces the transformations between data types)

2. Loose Coupling

The different types of coupling are

• Logic-to-Contract Coupling
• Created when the "contract first" approach is followed
• Tight coupling of Service Logic on the Service Contract
• Positive
• Contract-to-Logic Coupling
• Created when the Service Contract is auto generated from the Service Logic
• The Service Contract is dependent on the underlying Service Logic
• Also, auto generation of schemas from the database tables
• Negative

3. Service Abstraction

• Hides the implementation details from the Service Consumers(to be hidden - includes technology, functional, programmatic logic and quality of service information)
• This provides the freedom to evolve the service implementation as required.

4. Service Reusability

• Services should contain and express agnostic logic so that they can be reused across the enterprise.
• Achieving this is very important as the ROI is highly dependent on the degree of reuse achieved
• Some of the design characteristics are
• The Service is defined by an agnostic functional context
• The Service Logic is highly generic
• The Service Contract is generic and extensible
• The Service Logic can be accessed concurrently

5. Service Autonomy

• The level of control over the underlying runtime execution environment.
• Task Services have less autonomy as they compose other services over which they have less control.

6. Service Statelessness

• Stateless Services
• Increase Service Scalability
• Increase Service Reusability
• Consume less computing resources
• Orchestrated Task Services are expected to be stateful
• Entity and Utility Services are generally stateless

7. Service Discoverability

• Services are supplemented with meta data by which they can be effectively discovered

8. Service Composability

• Services should be composable

SOA : Service Oriented Design

This is a gist of Service Oriented Design from the "SOA : Principles of Service Design" by Thomas Earl.

Design Phase

• The Service Oriented Design takes the service candidates and converts them to actual services by creating actual physical contracts.
• It is highly recommended that a high level service inventory be defined prior to creating physical contracts. 
• It is better to follow the waterfall approach in doing the upfront service analysis and service modelling to be followed by agile approach in implementing the services.
• "Contract First Design" is the ideal form of design where the service contract is created before developing the service logic.

SOA : Service Modelling

This is a gist from the "SOA : Principles of Service Design" by Thomas Earl.

Service Modeling, which is a sub process of service oriented analysis  produces conceptual service definitions called service candidates.

During Service Modelling, Services can be primarily classified as follows(Service Models)
1. Entity Services
2. Task Services
3. Utility Services

Entity Services

• Also called as business entity services 
• Represents a business centric service that models a business entity
• Considered to be a highly reusable service that can be composed by the business processes 

Task Services

• Models the business process 
• Typically this composes the entity services to accomplish the business process

Utility Services

• Non business centric services 
• Provides reusable services that do not have business logic
• Examples could be logging, notification, authorization, authentication, etc.