CSC/ECE 517 Fall 2009/wiki2 16 rs: Difference between revisions
| Line 202: | Line 202: | ||
Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential. | Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential. | ||
Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract. | Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way. | ||
=Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF= | =Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF= | ||
Revision as of 02:48, 10 October 2009
CSC/ECE 517 Fall 2009/wiki2 16 rs
SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. Research and report on what patterns have been proposed and are utilized within this domain. How do they differ from traditional design patterns proposed by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides? How are they similar?
Introduction
This article focuses on the design patterns which are proposed and utilized in the Service Oriented Architecture. As the SOA provides its services through the protocols and API, this article throws light on the design patterns that specifically provide services through protocols like Canonical protocol, Dual protocols and Protocol Bridging. In a broader perspective, other design patterns have been explained tersely. In addition to explanation of the SOA design patterns, this compares the SOA design patterns with the traditional design patterns proposed by the ‘Gang of Four’ (Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides) and comes up with the differences and similarities between them.
Service Oriented Architecture-An Overview
SOA-Definition
A Service Oriented Architecture is an architecture that provides collection of services. These services need to inter-operate with each other to provide the functionality. This architecture requires a loose coupling with operating systems and other technologies that form the basis of the application. The loose coupling between services is required because each interaction has to be independent of the other. The communication between services could be either simple data being passed or it could be either an activity coordinated between distinct entities or services. Some means of interoperability is required to provide the services in larger terms. Instead of defining the API, the SOA implements the interfaces using the protocols and functionality. SOA separates functions into unique entities or services, which are accessed in a network by the users to combine and reuse them to develop the applications.
Why SOA?
Various businesses in the field of Information Technology have to justify their projects with a return on their investments. This creates a pressure in Information Technology by making it a demanding field. Information Technology needs to have requirements in a way that it has to responsive and adapt to the changing requirements.
Information Technology companies must also be able to provide the services that are compatible with other services making it interoperable, thus creating dynamic services. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.
Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money. Service Oriented Architecture offers a solution to satisfy the above needs of the industry
SOA-Benifits
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.
When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include i) business services across several platforms ii) location independence iii) authentication as well as authorization support on different platforms iv ) loosely coupled approach, dynamic search and connectivity to other services.
Design Patterns in SOA
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be applied in different scenarios. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
Design patterns play a major role in SOA. The implementation and deployment of SOA designs provide different challenges during product development life cycle.Such challenges may make projects to be discontinued. Design patterns help in overcoming these problems by providing a solution to the problems posed. Each SOA design pattern provides a design solution in support of successfully applying service orientation and establishing a quality service-oriented architecture
Design Patterns proposed
The proposed Design Patterns for SOA fall in to following categories.They are listed below and corresponding patterns in each category are given.
Foundational Inventory Patterns
These design patterns focus on providing solutions to the problems like maximizing re-composition and avoiding redundant logic .
examples for this category are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema
Logical Inventory Layer Patterns
These design patterns provide the solution to the problem of how can business logic be separated, reused, and governed independently?
examples for this category are Utility Abstraction,Entity Abstraction,Process Abstraction
Inventory Centralization Patterns
These patterns focus on providing solution for aspect of governing business logic etc
examples for this category are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.
Inventory Implementation Patterns
These patterns help to solve implementation problems like limitations introduced by communication technology. Example like a single protocol may not accommodate all requirements etc
examples for this category are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer
The patterns deal with the governance problems caused by service contract within the same service inventory
examples for this category are Canonical Expression,Metadata Centralization,Canonical Versioning
The patterns proposed in this category focus on solving large business problems without having to build a stand alone solution.
examples for this category are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability
Service Implementation Patterns
The patterns in this category focus on improving the realiability and availability of the service
examples for this category are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator
The patterns proposed in this category deal with the problem of data encapsulation and security aspects.
examples for this category are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard
Service Contract Design Patterns
The patterns proposed in this category focus on providing solution for how to make the service contract suitable for all potential customers,make it aligned with other services etc
examples for this category are Decoupled Contract,Contract Centralization,Contract De normalization,Concurrent Contracts,Validation Abstraction
The patterns proposed deals with the problems in legacy systems like processing of data contained in flat files, redundancy resulting in delivery to multiple channels etc
examples for this category are Legacy Wrapper, Multi-Channel Endpoint,File Gateway
These patterns provide solution for problems like updating the customers with changed service so that they are not affected, modifications in service etc
examples for this category are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability
Capability Composition Patterns
The pattern proposed focuses on the problem of How can a service capability solve a problem that requires logic outside of the service boundary and How can the same capability be used to help solve multiple problems?
examples for this category are Capability Composition,Capability Recomposition
The patterns proposed in this category focus on setting up of message framework for transfer of data.
examples in this category are Service Messaging,Messaging Metadata,Service Agent,Intermediate Routing,State Messaging,Service Callback,Service Instance Routing,Asynchronous Queuing,Reliable Messaging,Event-Driven Messaging.
Composition Implementation Patterns
The patterns proposed in this category focus on problems during runtime like runtime activities that span multiple services fail, the parent business task is incomplete etc
examples for this category are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction
Service Interaction Security Patterns
The proposed patterns in this category are focused on security methods like encryption,decryption,authenticating the data,consumer and service
examples for this category are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication
The Patterns proposed in this category concrete on how data from one data model can be dynamically converted to comply to a different data model.
examples for this category are Data Model Transformation,Data Format Transformation, Protocol Bridging
Common Compound Design Patterns
A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns.
examples for this category are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory
Example Design Patterns
The following section describes five design patterns which are utilized in SOA.The described patterns provide the problem and corresponding solution
Canonical protocol
Problem: Services that support different communication technologies compromise interoperability, limit the quantity of potential consumers, and introduce the need for undesirable protocol bridging measures.
Solution: The architecture establishes a single communications technology as the sole or primary medium by which services can interact.
From the above figure it is observed that the services are delivered by three different communication technologies A,B and C.These services are made to conform to one centralized communications technology, making them technologically compatible.with this these services can be delivered to consumers without much difficulty
Dual protocol
Problem: Canonical Protocol requires that all services conform to the use of the same communications technology; however, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.
Solution: The service inventory architecture is designed to support services based on primary and secondary protocols.
Regardless of protocol, all services must invoke each other via their official service contracts (A, B). Bypassing the contract may seem convenient when the underlying service logic of the primary service supports the same protocol as the secondary service (C), but it is an anti-pattern that will eventually inhibit the application of this pattern and further weaken the overall service inventory foundation.
Protocol Bridging
Problem: Services using different communication protocols or different versions of the same protocol cannot exchange data.
Solution: Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.
From the above figure it can be noticed that the consumer programs interact with a middle-tier broker that provides protocol bridging features. Separate protocol adapters are used to translate the two incompatible protocols to the required SOAP version 1.2 over HTTP. The broker then transmits the messages to the service on behalf of the consumers.
UI Mediator
Problem: Because the behavior of individual services can vary depending on their design,runtime usage, and the workload required to carry out a given capability, the consistency with which a service-oriented solution can respond to requests originating from a user-interface can fluctuate, leading to a poor user experience.
Solution: Establish mediator logic solely responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic.
The mediator service (D) regularly updates the user interface while services A, B, and C work behind-the-scenes to complete the task
Service Facade
Problem: The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.
Solution: A service facade component is used to abstract a part of the service architecture with negative coupling potential.
Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.The objective of loose coupling is achieved by this process.the core logic abstraction is obtained by this way.
Similarities and Differences Between Patterns for SOA and Traditional pattens proposed by GoF
The Gang of Four(Gof) comprising of Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides have documented the design patterns that were followed by Software developers and architects in object oriented space. They have documented 23 design patterns which are collectively called as Traditional design patterns.
The design patterns in SOA are similiar in some aspects to the traditional patterns.They also differ from the traditional patterns. The similiarities and differences between them are provided in this section
Differences
The differences between the SOA design patterns and traditional design patterns have been come up based on the individual functionality that each pattern provide. Following are the differences,
1) The composite pattern organizes the objects in the manner to represent the part-whole hierarchies in a traditional two-tier hierarchy.
The agnostic sub-controller implements the service composability but it differs from the composite pattern in such a way that cross-entity functionality is abstracted and made accessible through the sub –controller capability.
For instance, the traditional composite pattern has the object representing a part-whole hierarchy as in the below figure of graphic class which has draw(). If we require a cross-entity functionality as in the below figure, we require a colored rectangle, we require the functionality fill() of color class. Hence the sub-controller module is created which has the functionality of different parents, thus making it reusable.
figure to illustrate above difference
2) The traditional bridge pattern separates the abstraction from its implementation in order to vary independently. Whereas the canonical protocol avoids the protocol bridging in such a way that there is a single communication technology through which the services can interact. In the below figure of bridge pattern, the relationship between the abstraction and implementor is bridge and it results the implementor to vary independently from the abstraction by having different ConcreteImplementor. The canonical protocol avoids the variation by having a single communication technology between different objects.
figure for above difference
Figure for Traditional bridge pattern
For canonical protocol refer to the explanation given in example design patterns
3) The traditional builder pattern decouples the construction of the object from its representation so that the same construction process can be used to develop different representations. The different representations (contracts) are addressed in SOA by the Concurrent Contracts with the application of Service-façade design pattern. With service-façade design pattern, an abstraction is created to support the interaction between different contracts. As a result, different contracts can be created for a single service. In the below figure, the conversion of the text document is separated from the reader of RTF document, so that the text document can be represented in different forms like ASCIIText, TeXText and TextWidget. The different representation is achieved by decoupling of construction and abstraction. In the case of concurrent contracts pattern, the different contracts or services (invoices) are created for different consumer through service-façade by creating a new abstraction.
Figure for Traditional Builder pattern
Figure for Concurrent pattern
Similarities
1) The Service-façade design pattern is similar to the façade (traditional) pattern in the manner that it implements the façade logic which is creating an abstraction for intra-communication within objects to the service architecture. The advantage by adding the façade logic to the service architecture is that it preserves the underlying logic from run-time changes.
2) The UI Mediator design pattern implements the mediator logic of traditional mediator pattern. The mediator logic aims to provide the user responses in a way that user understands, independently of what the underlying services perform.
3) The Intermediate routing pattern in SOA is similar to Decorator pattern (traditional) in the functionality that it adds the required logic at run-time. The decorator adds the additional functionality to the object at run-time. The intermediate routing pattern is about placing the routing logic to address the run-time scenarios.
4)The Capability Composition pattern in SOA implements the Composite pattern (traditional). The Capability Composition is about composing one or more capabilities outside the service’s context to address the large, complex problem.
5) The Decoupled Contract pattern implements the traditional Bridge pattern in the manner that service contract is separated from the implementation. The Bridge pattern decouples the abstraction from implementation to facilitate the variation of both (abstraction and implementation).
6) The Legacy Wrapper pattern is related to traditional Adapter pattern. The Legacy Wrapper pattern protects the legacy logic by providing a standard service that takes of protecting the legacy details by encapsulating, extraction or elimination. The encapsulation, extraction or elimination is done in order to change the service as the consumer requires it. This is related to adapter in a way that it converts the interface of one class to another as the client expects.
Summary
Glossary
1.Serive : "A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."
3.SOA :Service oriented Architecture
4.API :Application programming interface
5.SOAP :Simple Object Access Protocol
6.HTTP :Hypertext Transfer Protocol
7.GoF :Gang of Four
References
1.Design patterns for object oriented software