SOA Design Patterns

Presented by :Archana,Balaji,Deepthi,Ganesh,Micheal and Surpiya

References:

Book:

Thomas Erl, “SOA design patterns”, Prentice Hall, c2009

Research Paper:

Christian Mauro, Jan Marco Leimeister, Helmut Krcmar, “Service Oriented Device Integration – An Analysis of SOA Design Patterns”, 43rd Hawaii International Conference on System Sciences – 2010

Web:

http://soapatterns.org

Introduction to SOA Design Patterns

What is it?

•Proven solutions to common problems faced in the design of Service-Oriented Architecture.

•Describes how to solve a problem that can be used in many different situations.

•Design Patterns are time-tested solutions to recurring software design requirements.

Benefits:

•Scalability

•Extensibility

•Reusability

•High level abstraction

•Quick build times

List of SOA Design Patterns:

1.Foundational Service Patterns2.Service Implementation Patterns3.Service Contract Design Patterns4.Service Security Patterns5.Service Messaging Patterns6.Legacy Encapsulation Patterns 7.Composition Implementation Patterns8.Service Interaction Security Patterns9.Transformation Patterns10.Common Compound Design Patterns

Transformation PatternsWhen it comes to composing a solution out of services that belong to different domain inventories, some sort of transformation mechanisms may be required in order for the messages to be sent between different service inventories. Design patterns like the Data Model Transformation, the Data Format Transformation and the Protocol Bridging design patterns can be applied in order to address the different transformation requirements.

Data Model Transformation:

Problem:

•Service interoperability and service composition are hindered when services use incompatible schemas to represent same data.

Solution:

•To convert data between disparate schema structures, a data transformation technology can be used.

Data Format Transformation :

Problem:

•Data format disparity can bring about issues in accessing resources by services, and also incompatibility between a consumer and a target to invoke the service.

Solution:

•Translate one data format into another by introducing intermediary data format transformation logic.

Protocol Bridging:

Problem:

•Data exchange is not possible between services using different communication protocols or different versions of the same protocol.

Solution:

•Dynamically convert one protocol to another at runtime by introducing bridging logic to enable communication between different communication protocols .

Common Compound Design Patterns

A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns. Compound patterns are also about relationships, but in a different way. The patterns that comprise a compound pattern have a relationship with the compound pattern itself. Whether these patterns have dependencies with or impact each other is immaterial. When studying them as members of a compound pattern, we are only interested in the results of their combined application. Singled out in the next slide are some of the more common and important combinations of the patterns, each of which is classified as a compound design pattern.

•Orchestration

•Enterprise Serial Bus

•Service Broker

•Canonical Schema Bus

•Official Endpoint

•Federated Endpoint Layer

•Three Layer inventory

Orchestration provides effective maintenance and execution of parent business process logic.

ESB represents an environment designed to foster sophisticated interconnectivity between services.

Service Broker patterns add a great deal of flexibility to a service-oriented architecture implementation by performing more than one transformation function at the same time. 

Building upon the platform established by ESB, the Canonical Schema Bus positions entry points into the logic, data, and functions offered via the service bus environment as independently standardized service contracts. 

 

Official Endpoint helps us understand how Logic Centralization and Contract Centralization can be used together by applying them to the same service.

Federated Endpoint Layer represents the desired state of the external, consumer-facing perspective of a service inventory  by making it more easy and effective for the services to be repeatedly consumed and leveraged. 

The combined application of three service layer patterns results in the Three Layer Inventory, which brings about common layers of abstraction that have been proven to complement and support each other by establishing services with flexible variations of agnostic and non-agnostic functional contexts. 

Foundational Service Patterns

A set of basic design patterns that help establish fundamental service design characteristics. These patterns form the most basic application of service orientation.

Functional DecompositionProblem:

•A large business solution logic results in a self- contained application•reusability constraints.

Solution: •The problem can be broken down•the required solution logic can be decomposed into a corresponding set of smaller, related solution logic units.

Service Encapsulation

Problem: •Solution logic designed for a single application environment •is limited to interoperate with other parts of an enterprise.•cannot be leveraged with other sections of the enterprise.

Solution: •Solution logic can be encapsulated by a service

Agnostic Context

Problem: •Multi-purpose logic grouped together with single purpose logic•programs with little or no reuse potential •redundancy into an enterprise.

Solution:• Isolate logic that is not specific to one purpose into separate services.

Service Implementation Patterns

A collection of specialized design patterns that provide design solutions for a range of service architecture-specific issues.

Service FaçadeProblem:

•The coupling of the core service logic and implementation resources •Negatively impact service consumers.

Solution: •A service facade component is used to abstract a part of the service architecture.

Redundant ImplementationProblem:

•A service that is being actively reused may introduce a potential single point of failure •May jeopardize the reliability

Solution:•Reusable services can be deployed by providing redundant implementations •Failover support.

Service Data ReplicationProblem :

•Services exhibit autonomy when requiring access to shared data sources.Solution:

•Services can have their own dedicated databases •Replication to shared data sources.

Service Contract Design PatternsContract design patterns for providing the required services

Contract Centralization

Problem:

• Consumer programs access the service resources using different entry points.

• Implementation dependencies.

Solution:

• Limit the access to service logic.

• Avoid implementation coupling.

Contract Denormalization

Problem:

• There are services with strictly normalized contracts

• Functional and performance demands on the consumer program.

Solution:

• Multiple capabilities are used to express the core functions in different ways for different types of consumer programs.

Service Security PatternsPatterns for handling threats associated with exposing functionality on potential hostile networks.

Message Screening

Problem:

• An attacker can transmit messages with malicious to a service or eavesdrop on a particular data.

• Undesirable behavior in the performance of the system.

Solution:

• The service is provided with special screening routines

Trusted Subsystems

Problem:

• A consumer may access backend resources of a service directly.

• He can compromise the integrity of the resources.

Solution:

• The services use their own credentials for authentication and authorization.

• Customers are prevented from accessing the backend resources.

Service Messaging Patterns

Service MessagingProblem:

•Services requiring persistent connection - >Tight coupling.Solution:

•Interaction of services via messaging-based technology.

State MessagingProblem:

•If state information is maintained between message exchanges -> performance burden.Solution :

•State is not retained in memory.•Instead temporarily delegated to messages.

Service CallbackProblem:

•Service needs to respond through multiple messages ->synchronous communication not possible Solution:

•Asynchronous communication with a callback address to respond.

Event Driven MessagingProblem :

•Events occurring within the functional boundary ->Consumers is unable to learn/monitor the eventsSolution :

•Consumer establishes himself as a subscriber to the service

Reliability MessagingProblem :

•Service messaging not guaranteed when using unreliable protocols Solution:

•Intermediate reliability mechanism standard.

Legacy Encapsulation Patterns

Multi-channel end pointProblem:

•Legacy systems lead to redundancy when using multiple channels Solution :

•Intermediate service acts as a central contact point exposing a standardized architecture.

File Gateway patternProblem:

•Flat files need to processed individually but legacy systems are not capable of invoking services Solution:

•File gateway logic acts as a mediator between a service and a flat-file-based legacy system .

Composition Implementation Patterns

Address implementation-level issues of composite services.Eg: Runtime service activity management.

Agnostic Sub-Controller

Problem:

•Service compositions are configured specific to a parent task.

•Inhibiting reuse potential exist within the composition logic.

Solution:

•Abstract reusable, cross-entity composition logic.

•Use sub-controller capability to access the parent / also independently automate a smaller tasks.

Atomic Service Transaction

Problem:

•Multiple services fails thereby parent business tasks is incomplete.

•Compromise the integrity of solution & architecture.

Solution:

•If the parent business task cannot be successfully completed, resets all action & changes.

Compensating Service Transaction

Problem:

•Uncontrolled runtime exceptions in single service can jeopardize many.

•Performance and scalable issue.

Solution:

•Use compensating routines are introduced to solve runtime exceptions.

•Thereby reduce resource locking and memory consumption.

Service Interaction Security Patterns

Focus on applying security at the message level.Data Confidentiality

Problem:

•Data is required to pass through one service to other.

•Transport-layer protocols allow messages to be intercepted and viewed by intermediaries.

Solution:

•Message contents are encrypted

•Ensuring that only intended recipients can access the protected data.

Data Origin Authentication

Problem: Need to prevent an attacker from manipulating messages in transit between client & services.

Solution: Message can be digitally signed to ensure it has not been tampered during transit.

Direct Authentication

Problem: Client should be authenticated before offering service by the service provider.

Solution: Service provider authenticate against identity store within it service.

Brokered Authentication

Problem:

•When clients & services do not trust each other.

•When clients are required to access multiple services as part of the same runtime activity.

Solution:

•Use an authentication broker with a centralized identity store.

•Consumer can get the token from this store to get the access from the multiple services.