Lost in Time!!!: An Introduction to Pattern-based SOA Solutions

This article is targeting enterprise architects who are building SOA-based solutions. It describes how generic patterns are mapped to WSO2 products for implementation.

Date: Wed, 31st Aug, 2011
Level: Introductory
Reads: 960 Comments: 0 | Login or register to post comments

Asanka Abeysinghe
Director, Solutions Architecture
WSO2

Introduction

Patterns are essential ingredients for architects when building solutions since patterns make solutions more stable as well as clean. It is important to pick the correct pattern based on the problem or the use-case that is implemented by a solution. This article provides the approach to pick the correct patterns and shows how architects can implement it using middleware. WSO2 SOA-based middleware platforms provide end-to-end middleware functionality for architects to build solutions, so this article is mainly focusing on SOA patterns and WSO2 middleware products.
In this article we will be discussing three interrelated patterns individually and look at how we are going to use them in a solution to solve a business problem.

Applies To

WSO2 ESB	4.0.0
WSO2 Carbon	3.2.0
Environment	Tested on Mac OS X 10.7.1 (Lion), JDK 1.6.0_26

Table of Contents

Business Architecture
Solution Architecture: Identified Patterns
Solution Architecture
Application Architecture and Product Mapping
Reference Implementation
Conclusion

Business Architecture

Figure -1 Current Architecture

Company XYZ got a SOA-based application system running. Architects in the company are looking to re-architect the system to address new business and technical requirements. Current architecture contains a bunch of services and one single service to address external user requirements. Business requirements are identified during the new architecture phase to divide these large services into small services and make multiple development groups to develop and maintain the services.
Consumers are already using the services and business groups see a business challenge here. Even the architecture changes by dividing a single service to multiple services. Service contract provided to the consumers cannot change.

We will look at what the patterns useful to find a solution are for the above business problem.

Solution Architecture: Identified Patterns

Functional Decomposition
Functional decomposition brings the modular development in to services, and makes a service to solve a single business problem. Traditional Web services use to implement most of the business logic in a single Web service. When moving to the next-generation Web services, we need to apply basic design principles to divide a single Web service into multiple services - this has became a practice.

Figure -2 Functional Decomposition (Services)

This will allow the service implementation to be done in parallel by different groups and make each group own the services.
If we look at the service development and definition methodology as Web services, each decomposition service will have its own contract that contains the operations to expose the functionality. Most of the time all the services will use a common datamodel so will share the schemas, but it is an optional requirement that each service can use it’s own schemas.
Process Centralization

Process centralization pattern creates an abstract layer by hiding the internal implementation of services. This is useful for the service consumers to have a single API layer to invoke the services as well as to reduce the complexity of actual services.

Figure -3 Process Centralization

This pattern provides flexibility for the architects and developers to design services by looking at the technical aspects of the services. It provides the business aspects of the services by using the process centralization.
Multiple services canbe aggregated as a single service. Also, the complexity of the actual services can be reduced by having an abstract service, aggregated service as well as the abstract service can be kept public by making the actual business services private.
When we map process centralization with Web services, an aggregated contract will be used to represent as a pubic service or an API for public access.
Intermediate Routing
Intermediate routing pattern implements routing messages (by identifying message delivery paths) based on message content or runtime attributes. Delivery paths can be define in the design time or compute during runtime.
Message content can be a specific value or combination of values in the message body; runtime attributes can be the value(s) from message header or any runtime condition happens during message arrival.

Figure -4 Intermediate Routing

If the service implementation is done using Web services using SOAP binding for communications, header based routing can be done using transport level headers or SOAP headers. Content-based routing can be done using the content in the SOAP body. Service consumer, timestamp, a computation, computed dispatching URLs can be taken as examples of runtime attributes. It is not a must to use SOAP messages for routing. Both header and content-based routing can be applied for other message formats, including binary messages.

Solution Architecture

Defining the solution architecture becomes easy in this case because we have already identified the patterns to be applied to the solution. By using functional decomposition larger backend services can be divided into child services and handed over to relevant development and operation teams to develop and maintain.

Figure -5 Solution Architecture

A bus architecture with an ESB (Enterprise Service Bus) will be used to do the process centralization and provide a common service endpoint for the consumers to look-up the services and invoke. Routing capabilities provided by the ESB can be used to implement the intermediate routing based on the message content and message properties.

Application Architecture and Product Mapping

A service container and an ESB are required for this application implementation. WSO2 Application Server and WSO2 ESB are two possible and better candidates.

Figure -6 Application Architecture

Application architecture will look like the above diagram with WSO2 middleware products. Addition to the ESB and Application Server, Governance Registry has introduced as a repository to store the service artifacts like service contracts and policies.
Reference Implementation

As a reference implementation, SimpleStockQuote delivered with WSO2 ESB has divided into two services "SimpleStockQuoteServiceOne" and "SimpleStockQuoteServiceTwo". The mortivation here is to devide the quote related operations into one service and order placement related services into another service. In a production system "SimpleStockQuoteServiceOne" can be named as MarketDataService and SimpleStockQuoteServiceTwo as OrederManagementService.
Sample service consumer sends messages using SOAP over HTTP and the client has enabled WS-Addresing. WSO2 ESB does address-based routing by considering the operation name stored as an addressing header (wsa-action:) and dispatch to the relevant service that holds the operation. Routine done by using a switch-case statement.

To setup the sample and run, please refer the instructions described in Readme file inside the sample archive (ws-a-route-sample-zip) attached with the article.
Conclusion
Patterns are useful asserts for architects to define the blueprints and implement solutions. Identifying correct patterns and implementing them using a supported framework is a challenge. This article provides a pragmatic approach by identifying a set of patterns for a given business problem and shows how to apply them and implement using the WSO2 middleware platform.

References

[1] SOA Patterns

[2] Functional Decomposition

[2] Process Centralization

[3] Intermediate Routing

[4] WSO2 ESB

[5] WSO2 Application Server

[6] WS-Addressing

Author

Asanka Abeysinghe, Director- Solutions Architecture, WSO2, asankaa AT wso2 DOT com