Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-15T01:23:10Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
==Traditional Web Application==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]

== SOA based Web Application==
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

Examples of usage of various patterns:

Service Facade Pattern: Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independant and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independantly but also allow the service facade component to utilise its logic.

Legacy Wrapper Pattern: If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functinality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

Decoupled contract Pattern: Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the probelm that arises is that the Data Controller is a standalone Java EJB([http://java.sun.com/products/ejb/ Enterprise JavaBeans]), while the Fines and Evaluation Service is standardized on the web services technology framework([http://en.wikipedia.org/wiki/XML XML] and [http://www.w3.org/TR/wsdl WSDL] schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independantly from its underlying service logic and can be used as a web service.

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-15T01:22:15Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
==Traditional Web Application==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]

== SOA based Web Application==
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

Examples of usage of various patterns:

Service Facade Pattern: Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independant and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independantly but also allow the service facade component to utilise its logic.

Legacy Wrapper Pattern: If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functinality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

Decoupled contract Pattern: Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the probelm that arises is that the Data Controller is a standalone Java EJB([http://java.sun.com/products/ejb/ Enterprise JavaBeans]), while the Fines and Evaluation Service is standardized on the web services technology framework([http://en.wikipedia.org/wiki/XML XML] and [http://www.w3.org/TR/wsdl WSDL] schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independantly from its underlying service logic and can be used as a web service.

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:10:41Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
==Traditional Web Application==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]

== SOA based Web Application==
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:09:49Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]

[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:09:25Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:09:08Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|500x500px|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:08:35Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|frame|alt=SOA based Web Application|500x500px|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|500x500px|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:08:17Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|120p|alt=SOA based Web Application|500x500px|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|500x500px|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:07:49Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|50p|alt=SOA based Web Application|500x500px|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|thumb|alt=Traditional Web Applicatioo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:07:08Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|50p|alt=SOA based Web Application|size=500x500px|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|thumb|alt=Traditional Web Applicatioo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:06:55Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|frame|alt=SOA based Web Application|size=500x500px|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|thumb|alt=Traditional Web Applicatioo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:06:32Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|frame|alt=SOA based Web Application|size=500x500|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|thumb|alt=Traditional Web Applicatioo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:06:17Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|thumb|alt=SOA based Web Application|size=500x500|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|thumb|alt=Traditional Web Applicatioo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:05:39Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|thumb|alt=SOA based Web Application|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|thumb|alt=Traditional Web Applicatioo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:03:18Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|50p|alt=Puzzle globe logo|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|50p|alt=Puzzle globe logo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T17:02:53Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|110p|alt=Puzzle globe logo|SOA based Web Application]] [[Image:traditionalWebApplication.jpg|110p|alt=Puzzle globe logo|Traditional Web Application]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-14T16:55:37Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 
[[Image:soa.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:traditionalWebApplication.jpg|frame|alt=Puzzle globe logo|Ruby Logo]]
== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which 'decouples an abstraction from its implementation'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>

File:TraditionalWebApplication.jpg

2009-10-14T16:51:05Z

Mpadaka:

File:Soa.jpg

2009-10-14T16:50:28Z

Mpadaka:

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T21:48:39Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientated (OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design explains how to effectively design an SOA using services, service components, and process flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services. For example, they help ensure
that this decomposition of one service into two or more does not impact the contract (technical interface) of the original service, thereby also avoiding impact to that service’s consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A key pattern frequently applied to the initial design of service architecture is the Service Façade. Inspired by the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core serivce logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. For example, translating one interface for a class into a compatible interface to allow classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T21:43:26Z

Mpadaka:

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientated (OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design explains how to effectively design an SOA using services, service components, and process flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to Composite Pattern (Traditional)</h4></li>

These patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services. For example, they help ensure
that this decomposition of one service into two or more does not impact the contract (technical interface) of the original service, thereby also avoiding impact to that service’s consumer programs.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

A key pattern frequently applied to the initial design of service architecture is the Service Façade. Inspired by the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core serivce logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. For example, translating one interface for a class into a compatible interface to allow classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface.

<li><h4>Non-agnostic Context Pattern (SOA) is similar to Mediator Pattern (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T20:23:32Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientated (OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design explains how to effectively design an SOA using services, service components, and process flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition]: These patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

[http://en.wikipedia.org/wiki/Composite_pattern Composite]: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

[http://www.soapatterns.org/service_facade.asp Service Facade]: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

[http://en.wikipedia.org/wiki/Facade_pattern Facade]: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper]: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic context]: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract]: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T20:20:37Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientated (OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design explains how to effectively design an SOA using services, service components, and process flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition]: These patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

[http://en.wikipedia.org/wiki/Composite_pattern Composite]: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T20:19:08Z

Mpadaka:

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientated (OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design explains how to effectively design an SOA using services, service components, and process flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: These patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T20:10:43Z

Mpadaka:

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientated (OO) concepts such as inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design explains how to effectively design an SOA using services, service components, and process flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia]
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T20:05:11Z

Mpadaka: /* SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design explains how to effectively design an SOA using services, service components, and process flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:58:26Z

Mpadaka:

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:56:42Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:56:25Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:55:56Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

 Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:55:42Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:53:35Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)></h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:52:38Z

Mpadaka: /* Differences between SOA design patterns and traditional patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns:
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose:
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide:
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns:
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns:
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below: 

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)></h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:52:02Z

Mpadaka:

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns --
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose --
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide --
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns --
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns --
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below: 

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)></h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:50:36Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns --
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose --
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide --
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns --
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns --
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below: 

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:49:47Z

Mpadaka: /* Similarities between traditional design patterns and the SOA design patterns */

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns --
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose --
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide --
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns --
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns --
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below: 

<li><h4>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</h4></li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li><h4>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</h4></li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li><h4>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</h4></li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li><h4>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</h4></li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:47:11Z

Mpadaka:

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns --
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose --
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide --
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns --
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns --
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h4>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h4></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:45:26Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>Aim of design patterns --
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What the design patterns expose --
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>Level of granularity that the design patterns provide --
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>Interaction provided in the patterns --
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns --
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h3>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h3></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:41:57Z

Mpadaka:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Service Oriented Architecture ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>What is the aim of design patterns --
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What do the design patterns expose --
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>What level of granularity do the design patterns provide --
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>How is interaction provided in the patterns --
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns --
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</li>

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

<li>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</li>

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

<li>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</li>

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

<li>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</li>

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

<li><h3>Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)</h3></li>

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T19:38:22Z

Mpadaka:

== Why do we need [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

 The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. 

== Let us define SOA ==

 [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
 

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. 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. 

== Design patterns ==

 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.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul>

== Role of design patterns in SOA ==

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. 

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns] || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] || These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns] || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] || These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] || These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns] || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns] || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns] || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] || These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] || These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns] || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] || These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns] || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns] || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] || These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| [http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns] || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}


 

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

Object orientation (OO) brought in concepts of inheritance, encapsulation, and polymorphism that could be applied to define relationships between classes. With the prevalence of the use of OO in the programming world, developers and architects started noticing some patterns that can be applied to the usage of OO principles to solve similar types of problems. The patterns depicted the deconstruction of a problem into multiple class entities, together with their interrelationships using the basic concepts of OO, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. Whereas in OO the first-class constructs were objects and classes, the next-generation methodology for building software applications was called component-based development (CBD). In CBD, the first-class constructs were components, where a component was defined by its external specification, which could be used without any knowledge of its internal implementation. As such, the same external specification could be implemented in different programming language (for example, Java, C#). The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of OO principles.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions. Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components.

The main first-class constructs in an SOA are services, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA. Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li>What is the aim of design patterns --
 SOA patterns are more about Modeling, Design, Architecture
 GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li>What do the design patterns expose --
 SOA patterns expose services
 GoF patterns expose methods
</li>
<li>What level of granularity do the design patterns provide --
 SOA patterns exhibit business-level granularity
 GoF patterns exhibit component/object-level granularity
</li>
<li>How is interaction provided in the patterns --
 SOA patterns interact at the service-level, inter-service via service requests
 GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li>Standards for patterns --
 SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
 GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>



==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)

Capability Composition: these patterns provide the means by which to assemble and compose together the service logic. These patterns are the means by which service logic is aggregated to solve one or more larger problems. When you require access to logic that falls outisde a service's boundary, capability logic within the service composes one or more capabilities in other services.

Composite: the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)

Service Facade: Service facade logic is primarily responsible for providing supplemental, intermediate processing logic in support of the core serivce logic. This helps a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently.

Facade: A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use and understand, since the facade has convenient methods for common tasks. A facade can make code that uses the library more readable, reduce dependencies of outside code on the inner workings of a library,
wrap a poorly-designed collection of APIs with a single well-designed API.

Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)

Legacy Wrapper: Legacy systems must often be encapsulated by services established by proprietary component APIs. The resulting technical interface is frequently fixed and no - customizable. Because the contract is pre-determined by the product vendor on constrained by the legacy component APIs, it is not compliant with contract design standards. Such a non-standard wrapper service can be repalced by or wrapped with a standardized service contract that extracts ecapsulates and possibly eliminates legacy technical details from the contract.

Adapter: the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)

Non-Agnostic context: When applying service orientation , there is more emphasis on abstracting and positioning solution logic that is agnostic to business tasks and processes. Thus non-agnostic logic gets filtered out and often encapsulated by software programs that are peripherals (not part of the service inventory). Non-agnostic context patterns have logic that is suitable for service encapsulation and can be located within services that reside as official members of a service inventory.

Mediator: This pattern provides a unified interface to a set of interfaces in a subsystem. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes. With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)

Decoupled Contract: Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of servies is inhibited because they can only be used by the consumer programs compatible with their technology. Decoupled Contract patterns enable the service contract to be physically decoupled from its implementation. It allows the service contract to be created as a physically seperate part of the overall service implementation.

Bridge: The bridge is a deisgn pattern meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does varies. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> Text - SOA Design Patterns by Thomas Erl </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
</ul>



== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T19:08:59Z

Mpadaka: /* '''Project Environments Suited to Each''' */

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

===Purely Object Oriented===

:Ruby does not have primitives. everything, including integers are full fledged objects.
:'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

:With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

:'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

:'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

:Statically typed languages tend to be more verbose.

:'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

:'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

:Ruby and Python are flexible with respect to syntax. For example,

:'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

:'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

:'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

:Ruby and Python allow you to define default values to method arguments while Java does not.

:'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

:Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

:'''Java''':
:If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

:'''Python''':
:Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

:Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

:'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

:'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T19:07:48Z

Mpadaka:

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

===Purely Object Oriented===

:Ruby does not have primitives. everything, including integers are full fledged objects.
:'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

:With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

:'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

:'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

:Statically typed languages tend to be more verbose.

:'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

:'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

:Ruby and Python are flexible with respect to syntax. For example,

:'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

:'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

:'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

:Ruby and Python allow you to define default values to method arguments while Java does not.

:'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

:Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

:'''Java''':
:If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

:'''Python''':
:Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

:Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

:'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

:'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

:Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

:Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

:Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T19:06:43Z

Mpadaka: /* Purely Object Oriented */

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

'''Purely Object Oriented'''

:Ruby does not have primitives. everything, including integers are full fledged objects.
:'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

:With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

:'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

:'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

:Statically typed languages tend to be more verbose.

:'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

:'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

:Ruby and Python are flexible with respect to syntax. For example,

:'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

:'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

:'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

:Ruby and Python allow you to define default values to method arguments while Java does not.

:'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

:Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

:'''Java''':
:If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

:'''Python''':
:Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

:Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

:'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

:'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

:Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

:Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

:Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T19:04:07Z

Mpadaka: /* Purely Object Oriented */

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

===Purely Object Oriented===

:Ruby does not have primitives. everything, including integers are full fledged objects.
:'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

:With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

:'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

:'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

:Statically typed languages tend to be more verbose.

:'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

:'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

:Ruby and Python are flexible with respect to syntax. For example,

:'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

:'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

:'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

:Ruby and Python allow you to define default values to method arguments while Java does not.

:'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

:Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

:'''Java''':
:If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

:'''Python''':
:Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

:Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

:'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

:'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

:Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

:Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

:Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T19:03:18Z

Mpadaka:

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

===Purely Object Oriented===

:Ruby does not have primitives. everything, including integers are full fledged objects.
:'''Ruby''':
<pre>
: 0.zero? This evaluates to a true
: 1.zero? This evaluates to a false
</pre>

===Typed features===

:With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

:'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

:'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

:Statically typed languages tend to be more verbose.

:'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

:'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

:Ruby and Python are flexible with respect to syntax. For example,

:'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

:'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

:'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

:Ruby and Python allow you to define default values to method arguments while Java does not.

:'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

:Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

:'''Java''':
:If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

:'''Python''':
:Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

:Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

:'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

:'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

:Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

:Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

:Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T19:02:42Z

Mpadaka:

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

:===Purely Object Oriented===

:Ruby does not have primitives. everything, including integers are full fledged objects.
:'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

:With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

:'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

:'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

:Statically typed languages tend to be more verbose.

:'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

:'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

:Ruby and Python are flexible with respect to syntax. For example,

:'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

:'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

:'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

:Ruby and Python allow you to define default values to method arguments while Java does not.

:'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

:Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

:'''Java''':
:If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

:'''Python''':
:Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

:Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

:'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

:'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

:Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

:Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

:Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T19:01:59Z

Mpadaka:

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

1===Purely Object Oriented===

:Ruby does not have primitives. everything, including integers are full fledged objects.
:'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

:With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

:'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

:'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

:Statically typed languages tend to be more verbose.

:'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

:'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

:Ruby and Python are flexible with respect to syntax. For example,

:'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

:'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

:'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

:Ruby and Python allow you to define default values to method arguments while Java does not.

:'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

:Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

:'''Java''':
:If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

:'''Python''':
:Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

:Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

:'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

:'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

:Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

:Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

:Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T18:59:07Z

Mpadaka:

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

1===Purely Object Oriented===

:Ruby does not have primitives. everything, including integers are full fledged objects.
'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

Statically typed languages tend to be more verbose.

'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

Ruby and Python are flexible with respect to syntax. For example,

'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

Ruby and Python allow you to define default values to method arguments while Java does not.

'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

'''Java''':
If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

'''Python''':
Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T18:55:34Z

Mpadaka:

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide [http://www.rubycentral.com/pickaxe/irb.html interactive shells] (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs (Integrate Development Environments) are available for Python, including GUI (Graphical User Interface) debuggers. A [http://www.gnu.org/software/gdb/ gdb]-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [http://en.wikipedia.org/wiki/Model–view–controller MVC (Model-View-Controller)] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

===Purely Object Oriented===

Ruby does not have primitives. everything, including integers are full fledged objects.
'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

Statically typed languages tend to be more verbose.

'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

Ruby and Python are flexible with respect to syntax. For example,

'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

Ruby and Python allow you to define default values to method arguments while Java does not.

'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

'''Java''':
If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

'''Python''':
Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]

CSC/ECE 517 Fall 2009/wiki1a 11 f1,

2009-09-16T18:49:53Z

Mpadaka:

Ruby and Python are both scripting languages whose popularity has sky rocketed in recent years. Both languages are
[http://en.wikipedia.org/wiki/High_level_language High-Level], [http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) Garbage-collected], and [http://en.wikipedia.org/wiki/Dynamically_typed#Dynamic_typing Dynamically-typed]. Both provide an interactive shell, standard libraries, and persistence support. So, what are the differences?
[[Image:ruby.jpg|frame|alt=Puzzle globe logo|Ruby Logo]] [[Image:python.jpg|frame|alt=Puzzle globe logo|Python Logo]]

Points of comparison:
* Language Features: Ruby vs Python
* Programming environments
* Features exclusive to each of Ruby and Python
* Advantages of Ruby/Python over statically typed languages such as Java
* Project environments suited to each

=='''Language Features: Ruby vs Python'''==

===Access Protection ===

Ruby supports private, protected and public types of access (like java)to the elements of a class. By default all methods are public except the initialize method and all instance variables are private. One of the differences of Ruby compared to Python is that Ruby keeps all of its instance variables completely private to the class and only exposes them through accessor methods (attr_writer, attr_reader, etc).

Python's property descriptors are similar, but come with a trade-off in the development process. If one begins in Python by using a publicly exposed instance variable and later changes the implementation to use a private instance variable exposed through a property descriptor, code internal to the class may need to be adjusted to use the private variable rather than the public property. Ruby removes this design decision

===Functions and methods ===

In Ruby, the part which is different from Python is the fact that all operations are messages to objects. There are no separate
functions and methods; all of them are methods.

'''Ruby''':
<pre>
string = 'Hello world'
puts string.count('o'), string.length # prints 2, 11
</pre>
In Python, there are separate methods and functions as shown in the example below.

'''Python''':
<pre>
string = 'Hello world'
print string.count('o'), len(string) # prints 2, 11 – why not string.len()?
</pre>

===Ruby has reference to class in class body ===

'''Ruby''':
<pre>
class MyClass
initialize_magick()
end
</pre>
Rubys variant is cleaner, as the magic stuff is done in the class definition, so you see that it’s being done when you look at the class.

'''Python''':
<pre>
class MyClass:
pass
initialize_magick(MyClass)
</pre>
But it’s really not a big deal, because calling the initialise method after the class or as a decorator is really not a major drawback.

=== Self Reference ===

In Python, one needs to write ''self'' as the first parameter of a method definition (alike Perl). Furthermore, Python doesn’t require the variable name to be self. In Ruby, ''self'' is automatically available in a similar fashion as in C++.

Additionally, the method call ''self.method'' can be shortened to ''method'', as ''self'' is the default receiver.

=== Ruby continuations vs Python Generators ===

[http://www.stackless.com/spcpaper.htm Continuation] is a "pointer" to the current position in your program, including calling stack and all variables. You can reuse that pointer to "go back in time" when needed. Continuations are useful when it comes to ''usecases''.
<pre>
def loop
cont=nil
for i in 1..4
puts i
callcc {|continuation| cont=continuation} if i==2
end
return cont
end
</pre> 

Python doesn't support full continuations or even co-routines; instead it supports "generator" functions which create a kind of limited co-routine.
A [http://www.stackless.com/spcpaper.htm generator] in python is implemented as a special syntax for creating an instance of an iterator object, which returns the values returned by the "function" definition you provide. Python generators are easy and clean.
The equivalent code for the above code segment, in python is

<pre>
from generator_tools import copy_generator

def _callg(generator, generator_copy=None):
for _ in generator: # run to the end
pass
if generator_copy is not None:
return lambda: _callg(copy_generator(generator_copy))

def loop(c):
c.next() # advance to yield's expression
return _callg(c, copy_generator(c))

if __name__ == '__main__':
def loop_gen():
i = 1
while i <= 4:
print i
if i == 2:
yield
i += 1

c = loop(loop_gen())
print("c:", c)
for _ in range(2):
print("c():", c())
</pre>

===Indentation===

Python uses whitespace indentation, rather than curly braces or keywords, to delimit statement blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.
On the other hand, ruby doesn't need any indentation although it can be optionally used for clarity.

=== Other Differences ===

{| class="wikitable" border="1"
|-
! Feature
! Ruby
! Python
|-
| Higher-Order Functions
| Implemented with procedure objects
| Implemented as lambda expressions
|-
| Arrays and hashes
| supports Arrays and associative arrays (Hash)
| has Lists and Tuples which are the same as arrays.

|-
| Memory management
| has a mark and sweep garbage collector
| has a reference counting garbage collector.

|-
| Parallel assignment
| claims to do Operating System independent threading.
| Threading available on many common platforms with some threading support

|-
| Package support
| Not available
| Available

|}

== '''Programming Environments''' ==

===Development Environments===

Both languages provide interactive shells (type "python" or "irb") and high-level [http://www.ibm.com/developerworks/library/l-pypers.html persistence] support. Multiple IDEs are available for Python, including GUI debuggers. A gdb-style debugger is available for each language. Python has a RefactoringBrowser, BicycleRepairMan. RubyLanguage now has a [http://www.kmc.gr.jp/proj/rrb/index-en.html RubyRefactoringBrowser]

Both languages are supported by Emacs modes. Python can be used as an elisp replacement - see Pymacs. The current Ruby implementation is closely tied to Unix, making Windows performance and ports to new platforms problematic. There is an Eclipse [http://en.wikipedia.org/wiki/Integrated_development_environment IDE] for Ruby. RubyCocoa adds support for Ruby to ProjectBuilder/ExCode on MacOsx.

===Web Programming Environments ===

Both Ruby and Python have a large number of web programming environments/ application frameworks. They are exhaustively listed and compared [http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python here]. For brevity, we compare ruby's [http://en.wikipedia.org/wiki/Ruby_on_rails Ruby on Rails] with python's [http://en.wikipedia.org/wiki/Django_(web_framework) Django]. The need was to compare two frameworks which were developed independent of each other and not based or influenced on the other. Hence the choice of django was made, as other web python frameworks like pylons and web2py are based on rails.

Django is a complete Python web application framework while rails is an agile web programming environment built in Ruby which greatly simplifies [[w:http://en.wikipedia.org/wiki/Model–view–controller MVC]] framework development. Ruby OO programming topics in conjunction with various Rails recipes are considered a much lighter, simpler and faster development experience than other current enterprise frameworks provided today.

The table below compares them.

{| class="wikitable" border="1"
|-
! Feature
! Ruby on Rails
! Django
|-
| Language
| Ruby
| Python
|-
| Ajax
| Prototype, script.aculo.us
| Yes
|-
| MVC framework
| ActiveRecord, Action Pack
| Yes
|-
| MVC Push/Pull
| Push
| Push
|-
| i18n & l10n?
| Localization, Plug-in
| Yes
|-
| ORM
| ActiveRecord
| Django ORM
|-
| Testing framework(s)
| Unit Tests, Functional Tests and Integration Tests
| Yes
|-
| DB migration framework(s)
| Yes
| No (plugin exists, might be merged into trunk when more stable and feature complete)
|-
| Security Framework(s)
| Plug-in
| ACL-based
|-
| Template Framework(s)
| Yes
| Yes
|-
| Caching Framework(s)
| Yes
| Yes
|-
| Form Validation Framework(s)
| Yes
| Yes
|}

=='''Features exclusive to each of Ruby and Python'''==

===Python Advantages===

* Python has multiple inheritance
* Python has docstrings : Docstrings makes it possible to attach documentation directly to the classes and methods. That’s a nice documentation plus, and makes things like the Python interpreters ''help()'' function really useful.

===Ruby Advantages===

* Ruby blocks are much more powerful than Python lambdas and they are integrated pervasively into the language. They also allow interaction between the block and the container.
* Metaprogramming (modifying classes on the fly) is easier in Ruby than in Python. Interestingly, in the Ruby community this is considered a powerful feature and used frequently, whereas the Python community tends to think of it as a last resort.
* Ruby is very good at creating domain-specific mini-languages. This is a consequence of the easy metaprogramming and optional parentheses on function calls.

=='''Advantages of Ruby/Python over statically typed languages such as Java'''==

The term [http://en.wikipedia.org/wiki/Dynamic_programming_language Dynamic language] refers to high level programming language that allows the programmer to modify the code during run time. The modifications may include addition of new blocks of code or modifications to objects during execution or changing the type of objects. Statically typed languages such as Java or C# have these operations performed during compile-time as opposed to run-time. further Ruby and Python are dynamically typed; type checking is performed at run-time and typing isn't enforced as strictly as it is in a statically typed language. For example, if an object being passed as an argument to a function doesn't match the type of the argument, but does have a method that matches what is being called, program execution runs normally. This isn't the case in a statically typed language where programmers should declare the types they intend a method or function to use and the compiler will not permit the programmer to ignore this type.

Advantages of a dynamic language are many.

*Dynamic languages are compatible over many platforms.

*Dynamic languages emphasize on the code instead of the structure/ architecture of code. So coding is easier when you don't have to worry about syntax errors and adhering to the language specifications.

*Dynamic code can be written much faster than static code.

*[http://www.ibm.com/developerworks/linux/library/l-metaprog1.html Metaprogramming] is easier in a dynamic language. Dynamic languages are suitable if you are working on a template system, or a [http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Domain Specific Language (DSL)], a [http://en.wikipedia.org/wiki/Automatic_programming Code Generator], a [http://en.wikipedia.org/wiki/Parsing Parser] or other type of application that can build applications. While Static languages can do these things, it takes a lot more effort to achieve it when compared to a dynamic language.

However, a word of warning when starting out using a dynamic language: Dynamic languages put more of a responsibility on the developer when coding. Instead of having a structured syntax that makes sure that the programmer does not make blatant errors, the onus is on the programmer himself. Also, Dynamic languages have a lot of built in shortcuts that ends up revealing code that is not really readable for a beginner.

To aid in understanding how '''Ruby (or Python)''' are better than a static language such as '''Java''', consider the examples below:

===Purely Object Oriented===

Ruby does not have primitives. everything, including integers are full fledged objects.
'''Ruby''':
<pre>
0.zero? This evaluates to a true
1.zero? This evaluates to a false
</pre>

===Typed features===

With Static typing in Java and C#, programmers should declare the types they want a method or function to use while with Ruby you don't declare types for variables or functions. In Ruby objects are strongly and dynamically typed.

'''Java''':
<pre>
int val1=5;
String value=String.valueOf(val1);
if(value.equals("5"))
</pre>

'''Python''':
<pre>
val1=5
value=str(val1)
if value == "5"
</pre>

===Verbosity===

Statically typed languages tend to be more verbose.

'''Java''':
<pre>
import java.io.*;
BufferedReader file1=new BufferedReader(new FileReader(Filename));
</pre>

'''Python''':
<pre>
file=open(Filename);
</pre>

===Relaxed syntax===

Ruby and Python are flexible with respect to syntax. For example,

'''Ruby''':
<pre>
cat = Cat.new
cat = Cat.new()
cat = Cat.new();
</pre>

===More compact code===

'''Java''':
<pre>
for (int i = 0; i < 100; i++)
{}
</pre>

'''Ruby''':
<pre>
100.times { |i| }
</pre>

===Default Arguments===

Ruby and Python allow you to define default values to method arguments while Java does not.

'''Ruby''':
<pre>
def calc_cube(x=2,y=3)
val=x**y
end
</pre>

===Checked Exceptions ===

Checked exceptions force every method to deal with (catching or throwing) all exceptions that its child calls or may call.

'''Java''':
If in the program, a method calls run as follows, A1() -> A2() -> A3() -> A4() and if A4() throws an Exception, and it is caught by A1(), then A2(), A3() must also throw the same Exception.

'''Python''':
Exceptions propagate upwards and A2() and A3() do not need to throw the Exception.

===Duck Typing===

Ruby doesn't care about an object's class, just whether it has a method of the name used in the method call. For this reason, the dynamic approach has earned the name duck typing.

'''Ruby''':
<pre>
class Duck
def sound
puts "Quack"
end
end

Class Frog
def sound
puts "Croak"
end
end

def noises(duck)
duck.sound
end

duckA=Duck.new
frogB=Frog.new

noises(frogB)
</pre>

'''Result''':
<pre>
"Croak"
</pre>

=='''Project Environments Suited to Each'''==

Python is useful for rapid prototyping, [http://en.wikipedia.org/wiki/Scripting_language Web Scripting], [http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238 XML processing], database applications, [http://en.wikipedia.org/wiki/Graphical_user_interface GUI applications], scientific computations. Python can be used for large and complex software systems. YouTube, for instance, runs mainly on Python, and it is preferred language at organizations including Google, NASA and Industrial Light and Magic. Specialized Python libraries and frameworks exist for scientific programming, data manipulation, Web services, XML interchange and many other things.

Ruby is useful for typical scripting language applications such as text processing and [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212571,00.html middleware programs]. It is suitable for small, ad-hoc scripting tasks that previously may have been solved with Perl. Ruby has first-class [http://www.zytrax.com/tech/web/regex.htm regular expressions], which makes text processing scripts easy to write. Ruby is also suitable for larger software systems. It’s most successful application is in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] web framework. Websites like Twitter and Hulu use the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework] in production environments.

Ruby can also be used as a high-level [http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp API] [http://www.knowlesys.com/articles/web-data-extraction/wrapper_definition.htm wrapper] (or domain-specific language) around some C library. Other uses for Ruby is in test/behavior driven development and when you need to create an "internal" domain-specific language.

=='''References'''==

*[http://ruby.about.com/od/beginningruby/a/WhatIsRuby.htm What Is Ruby?]

*[http://blog.ianbicking.org/ruby-python-power.html Ruby, Python, "Power"]

*[http://python.about.com/od/gettingstarted/ss/whatispython_3.htm What is Python?]

*[http://johan.kiviniemi.name/blag/ruby-vs-python/ Ruby vs. Python Johan Kiviniemi's series of tubes]

*[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby (programming language)]

*[http://www.c2.com/cgi/wiki?PythonVsRuby Python Vs Ruby]

*[http://www.zdnetasia.com/techguide/webdev/0,39044903,62057667,00.htm Making the case for dynamic languages]