CSC/ECE 517 Fall 2009/wiki2 16 tvhi: Difference between revisions
(42 intermediate revisions by the same user not shown) | |||
Line 9: | Line 9: | ||
== Terminology == | == Terminology == | ||
<b>• Service Oriented Architecture </b> - | <b>• Service Oriented Architecture (SOA)</b> - Service-Oriented Architecture (SOA) provides a set of principles of governing concepts used during phases of systems development and integration. | ||
<b>• Design Patterns </b> - | <b>• Design Patterns </b> - Design Patterns are the reusable solutions to generic software problems. | ||
<b>• Web Service </b> - Web Service is a software system designed to support interoperable machine-to-machine interaction over a network | |||
<b>• MVC Architecture </b> - Model, View Controller Architecture is one of the strongest Object Oriented Concepts which modularizes the code into three parts. | |||
<b>• Granularity </b> - Granularity is the amount of implementation details to be provided. It can be either fine or coarse. | |||
<b>• Encapsulation </b> - Encapsulation is hiding the implementation details and providing an interface for usage. | |||
<b>• Template </b> - Template (also known as <b><i>Design Template</i></b> is a component which can be used towards problem solving. It can be considered as a subset of Design Pattern. | |||
== Different Patterns used in SOA == | == Different Patterns used in SOA == | ||
There are four major | There are four major Traditional Design Patterns for web services:<br> | ||
'''1. Adapter - ''' | '''1. Adapter - ''' The reuse of technologies can significantly reduce the effort of many common software applications which would otherwise had to be implemented from scratch It is one the factors for the SOA design to be profitable. This design pattern transforms the existing class such that it matches the client’s requirement. The classes before the transformation are usually incompatible for inter-operation. Adapter design pattern provides the bridge between the existing technologies and new web services that need to be developed. | ||
The reuse of technologies can significantly reduce the effort of many common software applications which would otherwise had to be implemented from scratch It is one the factors for the SOA design to be profitable. This design pattern transforms the existing class such that it matches the client’s requirement. The classes before the transformation are usually incompatible for inter-operation. Adapter design pattern provides the bridge between the existing technologies and new web services that need to be developed. | |||
'''2. Façade - ''' In view of security, increase in network traffic and transaction management, providing a suitable granularity is essential in designing the services. If the services are very finely grained as in most of the implementation and operations are transparent, there can be many service requests for an operation thereby considerably increasing the network traffic. Façade design pattern circumvents this problem by providing a single upper layer function and encapsulating the lower levels. The implementation details are hidden from the client. | |||
'''3. Proxy - ''' As the name suggests, this pattern provides an alias or surrogate for another object. There can be many back end requests and implementing a service for each one of them can involve substantial time and effort. For instance in a banking application, the back end requests include authorization of the customer, not allowing withdrawal below a minimum threshold, money transfers etc. The proxy design pattern collects and consolidates these various messages into a single service and it then transfers this request to the appropriate back end service. There would be tremendous improvement in the performance while interacting with one service as compared to the interaction with a collection of services. Another important feature of proxy design pattern is that it simplifies the testing of a third party object which cannot be controlled otherwise as the proxy would replicate the object which has to be tested. | |||
''' | '''4. Controller - ''' This forms the core part in the MVC architecture. This is the logical connection and forms the interface between the model and the view. The data required by the application is present in the model. View handles the user interface. The design is very clear in this architecture in such that by just going through model’s public method list, the behavior and the logic that the controller should incorporate can be easily comprehended. There can be different controller and views for the same model. For instance, user and administrator can use the same model but have different functionality and hence different controllers and views. This design pattern can be used in SOA to encapsulate the business logic of the service and also provide some leverage for the existing MVC design architectures. | ||
However, there are many design patterns that are derived from the four mentioned above. The following figure depicts a typical web service and the design patterns involved. <br> | |||
[[Image:DesignPatternsSOA.gif|thumb|center|550px|alt=A snapshot of Design Patterns in a Web Service | This diagram has been taken from [[#References | {1}]]]] | |||
== Traditional Design Patterns == | == Traditional Design Patterns == | ||
Line 28: | Line 41: | ||
The book [[#References | [1]]] is considered to be the bible of Design Patterns. Not only is one of the oldest material on Design Patterns but the patterns described act as the baseline to the next generation patterns which are derived from them. Here is a brief list of all the traditional design patterns. | The book [[#References | [1]]] is considered to be the bible of Design Patterns. Not only is one of the oldest material on Design Patterns but the patterns described act as the baseline to the next generation patterns which are derived from them. Here is a brief list of all the traditional design patterns. | ||
<br> | |||
| [[Image:PatternClassification.jpg|thumb|center|550px|alt=A classification of traditional design patterns | The following diagram is taken from the book [[#References | {1}]]]] | ||
<br> | |||
As the figure suggests, design patterns can be classified into three patterns. First one is Creational Design Pattern which gives the blueprint of the system that is being designed using the pattern, that is how you want your system to look like. The next is Behavioral Design Pattern which basically gives the template of the control flow of the system. Third one is the Structural Design Pattern which has more to do with the environment that the system is expected to work in. | |||
*<i>Note - Please refer to the [[#References | References]] section has some articles which describe the Traditional Patterns as described in [[#References | [1]]] with examples. It is out of scope to be explained here. </i> | |||
== Similarities and Differences == | == Similarities and Differences == | ||
Line 39: | Line 57: | ||
== Example == | == Example == | ||
<b>A Simple Design Pattern Example</b> | |||
Consider the ''Job Search'' pattern that has been enormously used by a large audience. It is the most commonly adopted pattern by many companies. For viewers who are not aware of what we are talking about, here is the explanation in a nutshell. | |||
Suppose a person looking for a job logs on to a company called ABC, and clicks on the ''Job Openings'' link, he is directed to a ''Criteria Search'' page where he fills in the criteria based on which the application lists all the openings. The next thing he would do is go to another company's careers site and do the same thing. So, it is clear that every company would have a website which would list all the job openings and would take all the applications for the different positions listed. Hence, we can say that it is a pattern followed by every firm/organization/company for recruitment. So from the implementation perspective, what every organization requiring the ''Careers'' site would do is, use the common design pattern and customize it according to their requirements. Company ABC might not have branches anywhere else other than United States, so it will list all the US branches only and the user would choose the location only, while XYZ might have branches internationally and would have the user select the country and the location. | |||
<b>Different Design Patterns for the Messaging API/Protocol</b> (Patterns in Detail) | |||
This is one of the best example to depict the flexibility and the extensibility of SOA design patterns. As described in [[#References | [5]]], messaging is a protocol followed for the information exchange between a client and a server. The messaging API is basically composed of a series of Design Patterns. The seperate design pattern for each function of messaging makes the system less dependent and more fault tolerant. The following figure is the Design Patterns for Messaging API.<br> | |||
[[Image:Messaging.gif|thumb|center|550px|alt=Design Patterns for Messaging | This figure is taken from [[#References | {5}]]]] | |||
<br> | |||
As discussed in [[#References | [5]]], the different messaging patterns are Message Type Patterns, Message Channel Patterns, Service Consumer Patterns, Contract Patterns, Routing Patterns, Transformation Patterns and Message Construction Patterns. As the name suggests, every pattern does a unique function and together they form the Messaging Protocol/API. | |||
== Conclusion == | == Conclusion == | ||
Design patterns are a powerful architectural tool and can reduce the amount of time and effort of software applications considerably. But at the same time, the designer needs to be judicious to map the web service to be implemented to the appropriate design pattern. Failing to do so will not only add the up the wok but also result in erroneous implementation. It is never mandatory to use any of the patterns if they do not rightly fit. There could always be a simpler and better solution. | |||
== References == | == References == | ||
<b>For Beginners</b><br> | |||
1. Read [http://www.developer.com/design/article.php/3325211/What-Are-Design-Patterns.htm Basics of Design Patterns] | |||
2. Read [http://www.soapatterns.org/ Basics of SOA Patterns] | |||
<b>For Advanced Readers</b><br> | |||
1. <i>"Design Patterns: Elements of Reusable Object Oriented Software</i> by Gamma, E., Helm, R., Johnson, R. and Vlissides, Addison-Wesley, 1995. | |||
2. [http://www.eaipatterns.com/docs/SoaPatterns.pdf SOA Patterns – New Insights or Recycled Knowledge?] by Gregor Hohpe, Google | |||
3. The IBM RedBook on [http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf Patterns: Service-Oriented Architecture and Web Services] | |||
4. A paper on [http://www.computerworld.com/pdfs/oracle_soa_BestPractices_wp.pdf SOA Best Practices and Design Patterns] by John Fronckowiak. | |||
5. [http://msdn.microsoft.com/en-us/library/dd334420.aspx Messaging Patterns in SOA] | |||
6. [http://www.soapatterns.com/ SOA Design patterns] by Thomas Erl | |||
<b>For detailed study</b><br> | |||
1. Oracle [http://www.oracle.com/technologies/soa/center.html SOA Resource Center] | |||
2. [http://www.ibm.com/developerworks/patterns/ Patterns for e-business] |
Latest revision as of 02:35, 15 October 2009
Service Oriented Architecture(SOA) and Patterns
Introduction
During the past decade, SOA has been one of the favorite topics among the research community. There are many techniques and services which satisfy the business requirements when implemented stand alone. The challenge is the integration of these various services into a cohesive framework and translation into methodologies so that they can be used for software development. There are potential advantages of using standardized services such as providing high level abstractions to organize large scale applications in open environments, ensuring coordination and interoperation between the programmers. Moreover, generic tools can be developed based on the standards to control the entire software life cycle from design, development, testing, and deployment to maintenance.
Design Pattern on the other hand helps to build any system more efficiently reducing the time consumption and making the solution more generic. When it comes to common systems like banking or online admission form, it might feel like a lot of unnecessary rework where every bank has to build the system from the scratch. If there is a basic pattern that the bank could use and build its system on the top of that, it saves a lot of work. In terms of Services and Service Oriented Architecture, a design pattern could fall in any level of SOA architecture like business, application etc. Services can be developed using the different patterns available as protocols or APIs. In SOA, when designing a particular service, understanding these patterns can be a lot of help especially in the standardization of service. Any generic web service that has to be implemented can be mapped to one or more of these design patterns. Hence a thorough understanding of these patterns is essential before proceeding with the design of the services
Terminology
• Service Oriented Architecture (SOA) - Service-Oriented Architecture (SOA) provides a set of principles of governing concepts used during phases of systems development and integration.
• Design Patterns - Design Patterns are the reusable solutions to generic software problems.
• Web Service - Web Service is a software system designed to support interoperable machine-to-machine interaction over a network
• MVC Architecture - Model, View Controller Architecture is one of the strongest Object Oriented Concepts which modularizes the code into three parts.
• Granularity - Granularity is the amount of implementation details to be provided. It can be either fine or coarse.
• Encapsulation - Encapsulation is hiding the implementation details and providing an interface for usage.
• Template - Template (also known as Design Template is a component which can be used towards problem solving. It can be considered as a subset of Design Pattern.
Different Patterns used in SOA
There are four major Traditional Design Patterns for web services:
1. Adapter - The reuse of technologies can significantly reduce the effort of many common software applications which would otherwise had to be implemented from scratch It is one the factors for the SOA design to be profitable. This design pattern transforms the existing class such that it matches the client’s requirement. The classes before the transformation are usually incompatible for inter-operation. Adapter design pattern provides the bridge between the existing technologies and new web services that need to be developed.
2. Façade - In view of security, increase in network traffic and transaction management, providing a suitable granularity is essential in designing the services. If the services are very finely grained as in most of the implementation and operations are transparent, there can be many service requests for an operation thereby considerably increasing the network traffic. Façade design pattern circumvents this problem by providing a single upper layer function and encapsulating the lower levels. The implementation details are hidden from the client.
3. Proxy - As the name suggests, this pattern provides an alias or surrogate for another object. There can be many back end requests and implementing a service for each one of them can involve substantial time and effort. For instance in a banking application, the back end requests include authorization of the customer, not allowing withdrawal below a minimum threshold, money transfers etc. The proxy design pattern collects and consolidates these various messages into a single service and it then transfers this request to the appropriate back end service. There would be tremendous improvement in the performance while interacting with one service as compared to the interaction with a collection of services. Another important feature of proxy design pattern is that it simplifies the testing of a third party object which cannot be controlled otherwise as the proxy would replicate the object which has to be tested.
4. Controller - This forms the core part in the MVC architecture. This is the logical connection and forms the interface between the model and the view. The data required by the application is present in the model. View handles the user interface. The design is very clear in this architecture in such that by just going through model’s public method list, the behavior and the logic that the controller should incorporate can be easily comprehended. There can be different controller and views for the same model. For instance, user and administrator can use the same model but have different functionality and hence different controllers and views. This design pattern can be used in SOA to encapsulate the business logic of the service and also provide some leverage for the existing MVC design architectures.
However, there are many design patterns that are derived from the four mentioned above. The following figure depicts a typical web service and the design patterns involved.
Traditional Design Patterns
The book [1] is considered to be the bible of Design Patterns. Not only is one of the oldest material on Design Patterns but the patterns described act as the baseline to the next generation patterns which are derived from them. Here is a brief list of all the traditional design patterns.
As the figure suggests, design patterns can be classified into three patterns. First one is Creational Design Pattern which gives the blueprint of the system that is being designed using the pattern, that is how you want your system to look like. The next is Behavioral Design Pattern which basically gives the template of the control flow of the system. Third one is the Structural Design Pattern which has more to do with the environment that the system is expected to work in.
- Note - Please refer to the References section has some articles which describe the Traditional Patterns as described in [1] with examples. It is out of scope to be explained here.
Similarities and Differences
As discussed in the previous section, the traditional design patterns as described in 1 cover all the major templates that are needed to design any system. Similarly, design patterns used for SOA cover all the templates required to design any service. Hence we can consider the traditional design patterns to be a superset of the SOA patterns. The SOA patterns are called Architectural Patterns which comprise of all the design patterns for the overall composition of a service based solution as discussed in 2. Although most of the design patterns for SOA are derived from the traditional structural and behavioral patterns, there are some subtle differences between them.
Patterns like service discovery patterns and service interaction patterns are very specific to SOA or the service that is under the limelight. However, messaging patterns and workflow patterns can be used while designing any system while defining their process. The workflow pattern is derived from the traditional behavioral patterns. It is a combination of many behavioral patterns. However, workflow patterns are specific to the service also. It depends on the domain under question. For example, if we are designing a system that enables physics researchers to run their experiments online and analyse the data, then the workflow could be a combination of one or many templates (which again could be the one or more of which could be used to construct a workflow for chemists running the experiments. We can consider a workflow pattern to be a combination of Adapter, Facade and Controller patterns.
At a microscopic level, trying to spot the dissimilarities between the traditional and SOA design patterns would be unjust because the SOA patterns are derived from the traditional ones. SOA patterns are more specific to web services while the traditional ones can be considered as the primitive patterns which can be used and customized to create patterns specific to a domain.
Example
A Simple Design Pattern Example
Consider the Job Search pattern that has been enormously used by a large audience. It is the most commonly adopted pattern by many companies. For viewers who are not aware of what we are talking about, here is the explanation in a nutshell.
Suppose a person looking for a job logs on to a company called ABC, and clicks on the Job Openings link, he is directed to a Criteria Search page where he fills in the criteria based on which the application lists all the openings. The next thing he would do is go to another company's careers site and do the same thing. So, it is clear that every company would have a website which would list all the job openings and would take all the applications for the different positions listed. Hence, we can say that it is a pattern followed by every firm/organization/company for recruitment. So from the implementation perspective, what every organization requiring the Careers site would do is, use the common design pattern and customize it according to their requirements. Company ABC might not have branches anywhere else other than United States, so it will list all the US branches only and the user would choose the location only, while XYZ might have branches internationally and would have the user select the country and the location.
Different Design Patterns for the Messaging API/Protocol (Patterns in Detail)
This is one of the best example to depict the flexibility and the extensibility of SOA design patterns. As described in [5], messaging is a protocol followed for the information exchange between a client and a server. The messaging API is basically composed of a series of Design Patterns. The seperate design pattern for each function of messaging makes the system less dependent and more fault tolerant. The following figure is the Design Patterns for Messaging API.
As discussed in [5], the different messaging patterns are Message Type Patterns, Message Channel Patterns, Service Consumer Patterns, Contract Patterns, Routing Patterns, Transformation Patterns and Message Construction Patterns. As the name suggests, every pattern does a unique function and together they form the Messaging Protocol/API.
Conclusion
Design patterns are a powerful architectural tool and can reduce the amount of time and effort of software applications considerably. But at the same time, the designer needs to be judicious to map the web service to be implemented to the appropriate design pattern. Failing to do so will not only add the up the wok but also result in erroneous implementation. It is never mandatory to use any of the patterns if they do not rightly fit. There could always be a simpler and better solution.
References
For Beginners
1. Read Basics of Design Patterns
2. Read Basics of SOA Patterns
For Advanced Readers
1. "Design Patterns: Elements of Reusable Object Oriented Software by Gamma, E., Helm, R., Johnson, R. and Vlissides, Addison-Wesley, 1995.
2. SOA Patterns – New Insights or Recycled Knowledge? by Gregor Hohpe, Google
3. The IBM RedBook on Patterns: Service-Oriented Architecture and Web Services
4. A paper on SOA Best Practices and Design Patterns by John Fronckowiak.
6. SOA Design patterns by Thomas Erl
For detailed study
1. Oracle SOA Resource Center