CSC/ECE 517 Fall 2009/wiki2 16 rs: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 87: Line 87:
[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]
[http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]


examples for this pattern are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction
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.


[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]
[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]


examples for this pattern are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication
examples for this pattern are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction


[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]
[http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns]


examples for this pattern are Data Model Transformation,Data Format Transformation, Protocol Bridging
examples for this pattern are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication


[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]
[http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns]


examples for this pattern are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory
examples for this pattern are Data Model Transformation,Data Format Transformation, Protocol Bridging


[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]
[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]


examples for this pattern are
examples for this pattern are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory


=Example Design Patterns =
=Example Design Patterns =

Revision as of 04:27, 9 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

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?

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 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

examples for this pattern are Enterprise Inventory,Domain Inventory,Service Normalization,Logic Centralization, Service Layers Canonical Protocol,Canonical Schema

Logical Inventory Layer Patterns

examples for this pattern are Utility Abstraction,Entity Abstraction,Process Abstraction

Inventory Centralization Patterns

examples for this pattern are Process Centralization,Schema Centralization,Policy Centralization,Rules Centralization.

Inventory Implementation Patterns

examples for this pattern are Dual Protocols,Canonical Resources,State Repository,Stateful Services,Service Grid,Inventory Endpoint,Cross-Domain Utility Layer

Inventory Governance Patterns

examples for this pattern are Canonical Expression,Metadata Centralization,Canonical Versioning

Foundational Service Patterns

examples for this pattern are Functional Decomposition,Service Encapsulation,Agnostic Context,Non-Agnostic Context,Agnostic Capability

Service Implementation Patterns

examples for this pattern are Service Facade,Redundant Implementation,Service Data Replication,Partial State Deferral,Partial Validation,UI Mediator

Service Security Patterns

examples for this pattern are Exception Shielding,Message Screening,Trusted Subsystem ,Service Perimeter Guard

Service Contract Design Patterns

examples for this pattern are Decoupled Contract,Contract Centralization,Contract Denormalization,Concurrent Contracts,Validation Abstraction

Legacy Encapsulation Patterns

examples for this pattern are Legacy Wrapper, Multi-Channel Endpoint,File Gateway

Service Governance Patterns

examples for this pattern are Compatible Change,Version Identification,Termination Notification,Service Refactoring,Service Decomposition,Proxy Capability,Decomposed Capability,Distributed Capability

Capability Composition Patterns

examples for this pattern are Capability Composition,Capability Recomposition

Service Messaging Patterns

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

examples for this pattern are Agnostic SubController,Composition Autonomy,Atomic Service Transaction,Compensating ServiceTransaction

Service Interaction Security Patterns

examples for this pattern are Data Confidentiality, Data Origin Authentication, Direct Authentication, Brokered Authentication

Transformation Patterns

examples for this pattern are Data Model Transformation,Data Format Transformation, Protocol Bridging

Common Compound Design Patterns

examples for this pattern are Orchestration,Enterprise Service Bus,Service Broker,Canonical Schema Bus,Official Endpoint,Federated Endpoint Layer,Three-Layer Inventory

Example Design Patterns

Canonical protocol

the pattern described shows

Dual protocol

Protocol Bridging

UI Mediator

Service Facade

Adapter

Similarities and Differences

Conclusion

Glossary

References