1. No category

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 Patterns
2. Service Implementation Patterns
3. Service Contract Design Patterns
4. Service Security Patterns
5. Service Messaging Patterns
6. Legacy Encapsulation Patterns
7. Composition Implementation Patterns
8. Service Interaction Security Patterns
9. Transformation Patterns
10. Common Compound Design Patterns
Transformation Patterns
When 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 Decomposition
Problem:
•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 architecturespecific issues.
Service Façade
Problem:
•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 Implementation
Problem:
•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 Replication
Problem :
•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 Patterns
Contract 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 Patterns
Patterns 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 Messaging
Problem:
•Services requiring persistent connection - >Tight coupling.
Solution:
•Interaction of services via messaging-based technology.
State Messaging
Problem:
•If state information is maintained between message exchanges -> performance burden.
Solution :
•State is not retained in memory.
•Instead temporarily delegated to messages.
Service Callback
Problem:
•Service needs to respond through multiple messages ->synchronous communication not possible
Solution:
•Asynchronous communication with a callback address to respond.
Event Driven Messaging
Problem :
•Events occurring within the functional boundary ->Consumers is unable to learn/monitor the events
Solution :
•Consumer establishes himself as a subscriber to the service
Reliability Messaging
Problem :
•Service messaging not guaranteed when using unreliable protocols
Solution:
•Intermediate reliability mechanism standard.
Legacy Encapsulation Patterns
Multi-channel end point
Problem:
•Legacy systems lead to redundancy when using multiple channels
Solution :
•Intermediate service acts as a central contact point exposing a standardized architecture.
File Gateway pattern
Problem:
•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.