CSC/ECE 517 Fall 2009/wiki2 16 tvhi
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 -
• Design Patterns -
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.
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.
The following diagram is taken from the book [1].
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.