CSC/ECE 517 Fall 2009/wiki2 16 tvhi: Difference between revisions
Line 45: | Line 45: | ||
<br> | <br> | ||
[[Image:PatternClassification.jpg|thumb|center|550px|alt=A classification of traditional design patterns | The following diagram is taken from the book [[#References | 1]]]] | [[Image:PatternClassification.jpg|thumb|center|550px|alt=A classification of traditional design patterns | The following diagram is taken from the book [[#References | {1}]]]] | ||
== Similarities and Differences == | == Similarities and Differences == |
Revision as of 00:50, 10 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 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.
Note: This diagram has been taken from [1]
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.
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
Different Design Patterns for the Messaging API/Protocol
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.
Note:This figure is taken from [5]
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
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
7. Oracle SOA Resource Center