SOA is about business agility. One wayto achieve this kind of agility is to identify the business componentscore tothe business. Once these business components have been identified, thebusinessprocesses and services associated with these business components can beidentified and specified. Once these business processes and serviceshave beenidentified, business process decomposition reveals what reusable ITservicesare needed to provision these business processes and services. Theinput andoutput messages of these IT services and the domain objects that theseservicesmanipulate also need to be specified. From an IT perspective theseservices canbe modeled as use cases and the functional and nonfunctionalrequirements ofthese use cases can be traced (in a tool like Rational Requisite Pro).With allthe moving parts how can the complexity of this kind of environment bemanaged?In particular how can we build out these services to ensure that thenonfunctionalrequirements of these services are satisfied?
Patterns are a way to help manage thiscomplexity. Patterns are a repeatable solution to a problem in context,andtypically are described by a pattern specification. Patternspecificationsinclude a forces section which outlines when the pattern should beused.Feasibility for a solution is ultimately determined by nonfunctionalrequirements, examples of which are scalability, performance, security,transactionality, maintainability, and interoperability. By mappingthesenonfunctional requirements to the forces section in the patternspecification,we achieve traceability and accountability in terms of thearchitecturaldecisions
Cross a number of IBM SOA engagementswe have harvested four patterns to assist in SAO development andimplementationof services. Each of these SOA patterns satisfies certain nonfunctionalrequirements typical to an SOA application. Here is a list of thesepatternsand a brief description of the non functional requirements that theyeachaddress:
WSresponse template pattern provides service interface flexibility,interoperability and maintainability.
RequestorSide Caching pattern specification improves the serviceperformance.
- The Preferred DataSource Pattern is a micro flow patterns for service aggregation
AspectLogging pattern provides service invocation traceability.
Before we examine these patterns in detail it will helpful to consider an n-tier architecture as outlined below. A three-tier architecture will have a presentation tier, a business tier and persistence tier. In a SOA environment, when we are dealing with the implementation of reusable IT services, we can separate the business tier further into a service layer, a controller layer, and an entity/object management layer. This layering is shown in Figure 1. It will help to think about this layering in the context of a application server container.
The service layer is responsible for specifying the operation used in that service and content of the message used by these operations. It is also responsible for serializing and de-serializing message in and out of the container. The controller layer is responsible for implementing the business logic of the service and can achieve this by invoking other services, other controller or an entity management layer. The entity management layer is responsible for entity management and ensuring the transaction integrity of that object with in the container.
The WS response template can be applied to the service layer (other patterns, such as a WS security pattern, that directly impacts the service definition would be applied as this layer). The requester side caching pattern, is applied at the controller layer. The aspect logging pattern will also be applied at the controller layer. The preferred data source pattern, can be applied in the controller layer. The session facade, message facade, and the business delegate core Enterprise JavaBeans patterns belong in the controller tier whereas the data management pattern of the entity and data access object core Enterprise JavaBeans patterns belong in the Entity layer. Figure 1 shows where in the n-tier layered architecture for service implementation and where these patterns are applied.
If you want to find out more about this patterns, see the developWorks series on