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 page reviews the different service oriented architecture patterns proposed for protocols and compares them them with the corresponding patterns which were proposed for object oriented reuse.

Service Oriented Architecture-An Overview

SOA-Definition

A service-oriented architecture is essentially a collection of services. These services communicate with each other.The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation.Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

Why SOA?

Vast majority of Businesses working in the field of Information Technology have to justify their projects with a return on their investments. This puts Information Technology, as a field under enormous pressure. Information Technology must boast requirements that are increasingly responsive and flexible to the shifting needs of different Businesses.

Firms dealing with Information Technology must also be able to face the challenge of taking on an array of software systems that may or may not be compatible with one another. 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.SOA 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 offering business services across several platforms; providing location independence; providing authentication as well as authorization support on ever tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows that services do not have to be located on a particular system or network.

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 used in many different situations.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 made may SOA 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

Inventory Governance Patterns

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

Foundational Service Patterns

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

Service Security Patterns

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

Legacy Encapsulation Patterns

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

Service Governance Patterns

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

Service Messaging Patterns

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

Transformation Patterns

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

For example, a service can be built and implemented as a component, a SOAP-based Web service, or a REST service. Essentially, any implementation technology that can be used to create a distributed system may be suitable for service-orientation. Many of the design patterns in this catalog are not specific to any one of these three implementation mediums, but some are. Several examples are based on the use of SOAP-based Web services because this service implementation medium has been historically the most popular. This does not preclude you from applying the patterns with other suitable technologies. Some patterns in particular can be carried out with vendor-specific products and technologies that rely on alternative communication protocols and APIs that are not based on industry standards.

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 though still delivered by different projects via different vendor platforms A,B,C etc these services conform to one centralized communications technology, making them technologically compatible.

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.