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: Foundational Service Patterns Service Implementation Patterns Service Contract Design Patterns Service Security Patterns Service Messaging Patterns Legacy Encapsulation Patterns Composition Implementation Patterns Service Interaction Security Patterns Transformation Patterns 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 : 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. Translate one data format into another by introducing intermediary data format transformation logic. Protocol Bridging: Data exchange is not possible between services using different communication protocols or different versions of the same protocol. 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 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 logic can be encapsulated by a service Agnostic Context Multi-purpose logic grouped together with single purpose logic programs with little or no reuse potential redundancy into an enterprise. 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ç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 A service that is being actively reused may introduce a potential single point of failure May jeopardize the reliability 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. 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 There are services with strictly normalized contracts Functional and performance demands on the consumer program. 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 A consumer may access backend resources of a service directly. He can compromise the integrity of the resources. The services use their own credentials for authentication and authorization. Customers are prevented from accessing the backend resources.

Service Messaging Patterns Problem: Services requiring persistent connection - >Tight coupling. Solution: Interaction of services via messaging-based technology. State Messaging If state information is maintained between message exchanges -> performance burden. Solution : State is not retained in memory. Instead temporarily delegated to messages. Service Callback Service needs to respond through multiple messages ->synchronous communication not possible Asynchronous communication with a callback address to respond.

Legacy Encapsulation Patterns 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 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 Intermediate service acts as a central contact point exposing a standardized architecture. File Gateway pattern Flat files need to processed individually but legacy systems are not capable of invoking services 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 Multiple services fails thereby parent business tasks is incomplete. Compromise the integrity of solution & architecture. If the parent business task cannot be successfully completed, resets all action & changes. Compensating Service Transaction Uncontrolled runtime exceptions in single service can jeopardize many. Performance and scalable issue. 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 When clients & services do not trust each other. When clients are required to access multiple services as part of the same runtime activity. 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.