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

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(53 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==  The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA]  ==
<p> 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. </p>
== Service Oriented Architecture ==
== Service Oriented Architecture ==


Line 6: Line 10:
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. </p>
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. </p>


== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==
==Example for Traditional Design==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Design|700x800px|Traditional Design]]  


<p> 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. </p>
==Example for SOA Design==
[[Image:soa.jpg|120p|alt=SOA based Design|700x800px|SOA based Design]]


== Design patterns ==
== Design patterns ==


<p> 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.  
<p> 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>  
<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 typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
Line 20: Line 26:
== Role of design patterns in SOA ==
== Role of design patterns in SOA ==


<p>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. </p>
<p>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. </p>




Line 29: Line 35:
!Category !! Objective
!Category !! Objective
|-
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || 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.
|-
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| 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.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| 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.
Line 39: Line 45:
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || 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.
|-
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || 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.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || 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.
Line 45: Line 51:
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| 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.
|-
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
Line 69: Line 75:
== 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 ==
== 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.
[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. 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.
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.
 
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 ==
== Differences between SOA design patterns and traditional patterns ==


<ul>
<ul>
<li><b>Aim of design patterns</b> --
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
</li>
<li><b>What the design patterns expose</b> --
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>SOA patterns expose services
<br>GoF patterns expose methods
<br>GoF patterns expose methods
</li>
</li>
<li><b>Level of granularity that the design patterns provide</b> --
<li><b>Level of granularity that the design patterns provide:</b>  
<br>SOA patterns exhibit business-level granularity
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
</li>
<li><b>Interaction provided in the patterns</b> --
<li><b>Interaction provided in the patterns:</b>  
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
</li>
<li><b>Standards for patterns</b> --
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
Line 106: Line 110:
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:  
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><b>Capability Composition Pattern (SOA) is related to Composite Pattern (Traditional)</b></li>
<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.


<b>Capability Composition:</b> 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.
<b>Case study example</b>


<b>Composite:</b> 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.
For example, 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 independent 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 independently but also allow the service facade component to utilise its logic.


<li><b>Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)</b></li>
<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>


<b>Service Facade:</b> 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.
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.


<b>Facade:</b> 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,
<b>Case study example</b>
wrap a poorly-designed collection of APIs with a single well-designed API.


<li><b>Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)</b></li>
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 functionality 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.


<b>Legacy Wrapper:</b> 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.
<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.  


<b>Adapter:</b> 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 provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.


<li><b>Non-agnostic Context Pattern (SOA) is associated with Mediator Pattern (Traditional)</b></li>
SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.


<b>Non-Agnostic context:</b> 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.  
<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>


<b>Mediator:</b> 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.
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 '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.


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


<b>Decoupled Contract:</b> 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.  
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 problem 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 independently from its underlying service logic and can be used as a web service.


<b>Bridge:</b> 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 ==
== Resources ==
Line 141: Line 152:
<ul>
<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 - 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> 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.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html  SOA]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html  SOA]</li>
Line 148: Line 160:
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</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://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>
</ul>
</p>
</p>
Line 157: Line 170:
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</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>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>
</ul>
</p>
</p>

Latest revision as of 18:24, 15 October 2009

The need for 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

Service-Oriented Architecture (SOA) can be defined as an Architectural design pattern that concerns itself with defining loosely-coupled relationships between producers and consumers. A 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 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.

Example for Traditional Design

Traditional Design

Example for SOA Design

SOA based Design

Design patterns

A design pattern is a general reusable solution to a commonly occurring problem in software design.

  • It is a description or template for how to solve a problem that can be used in many different situations.
  • Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved.
  • 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.
  • 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.

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

Category Objective
Foundational Inventory Patterns These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
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.
Inventory Centralization Patterns These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
Inventory Implementation Patterns These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
Inventory Governance Patterns These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
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.
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.
Service Security Patterns These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
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.
Legacy Encapsulation Patterns These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
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.
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.
Service Messaging Patterns These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
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.
Service Interaction Security Patterns These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
Transformation Patterns These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
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 Gang of Four -- GoF patterns

Object oriented(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.

Differences between SOA design patterns and traditional patterns

  • Aim of design patterns:
    SOA patterns are more about Modeling, Design, Architecture
    GoF patterns are about Modeling, Design, Architecture and Programming
  • What the design patterns expose:
    SOA patterns expose services
    GoF patterns expose methods
  • Level of granularity that the design patterns provide:
    SOA patterns exhibit business-level granularity
    GoF patterns exhibit component/object-level granularity
  • 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
  • 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.

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)

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

  • Service Facade Pattern (SOA) is derived from Facade Pattern (Traditional)

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

    Case study example

    For example, 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 independent 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 independently but also allow the service facade component to utilise its logic.

  • Legacy Wrapper Pattern (SOA) is derived from Adapter Pattern (Traditional)

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

    Case study example

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

  • Non-Agnostic Context (SOA) is similar to Mediator Pattern (Traditional)

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

  • Decoupled Contract Pattern (SOA) is associated with Bridge Pattern (Traditional)

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

    Case study example

    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 problem that arises is that the Data Controller is a standalone Java EJB(Enterprise JavaBeans), while the Fines and Evaluation Service is standardized on the web services technology framework(XML and 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 independently from its underlying service logic and can be used as a web service.


    Resources

    Abbreviations

    Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_16_am&oldid=26394"