Methodology to Deliver Service Oriented Architecture

By Sandrick Melbouci
From
DSOFT Technologies


A- Introduction
The technology has become an essential basic capabilities to create value proposition that distinguish the business in the marketplace.  Enterprises need to be able to bridge between the business and the technical world.  IT infrastructure should be aligned with business structure so that it can easily adapt to meet the business needs. One way of achieving this objective is through Service Oriented Architecture, SOA.
In Order to effectively deliver standardized services, it is recommended that organizations adopt methodology and processes specific to SOA consisting of structured analysis and design.
This article outlines a methodology to deliver service oriented architecture by applying service orientation principles to shape a solution in certain way with certain goals in mind to produce a blueprint of individually distributed unit.

Let's start with some definitions on SOA.

B- SOA Definitions

- What is Service-Oriented Architecture
SOA represents an architectural model that aims to enhance the agility and cost effectiveness of an enterprise while reducing the burden on IT and on the overall organization. It accomplishes this by positioning services as the primary mean by which the solution is represented.

- What is a Service
A service is unit of solution to which service orientation principle has been applied to a meaningful extent. It is the application of service-orientation principles that distinguishes a unit as a service compared to logic that may exist as an object or component.
A Service is comprised of a set of functions and capabilities related to its context.
Service Inventory is an independent standardized and governed collection of services.
A collection of inventories create a Domain Inventory.

- What are the Characteristics of SOA

1. Business Driven
2. Vendor Neutral
3. Enterprise Centric
4. Composition Centric

- Goals Of Service-Oriented Architecture
stating the common goals and benefits of SOA and these goals must be viewed within strategic context of the organization.

1. Increase Interoperability
2. Increased federation
3. Increase Vendor Diversification
4. Increase Business and technology Domain Alignment
5. Increased ROI
6. Increased Organizational Agility
7. Reduce IT burden

- Principles of Service Oriented Design

1. Standard Service Contract
   
2. Service Loose Coupling
3. Service Abstraction
4. Service Re-Usability
5. Service Autonomy
6. Service Statelessness
7. Service Discoverability
8. Service Composition

C- How to deliver SOA
Service Oriented Architecture is an architectural style. One of the methods to deliver SOA is explained in details by Thomas Erl in [1]. we will try to summarize this methodology that is simple and can also be integrated with TOGAF, FEA or any other Enterprise Architecture Framework. However, TOGAF failed to address SOA as an architecture style, some adjustments to TOGAF first four phases are required to deliver SOA.
We will explain the delivery of SOA through two main phases:
- Service Oriented Analysis
- Service Oriented Design

Before we start on the details of the analysis and design, let's address what approach to use:

-Delivery Approach
There are two delivery approaches, top down and bottom up. When starting  SOA within an organization with an objective of business - IT alignment, we recommend Top-Down approach.
We will list the pros and cons for each method.

• Top- Down

PROS
- Advocates the completion of an inventory analysis prior to the physical design, development, and delivery of services.
- Define blueprint Service Inventory
- Reduce the burden of governance
CONS
- Increase Of cost and Effort

• Bottom Up
  

PROS
- Tactically focused in that it makes the fulfilment of immediate business requirements a priority and the prime objective of the project
CONS
- Increase Cost of Maintenance, Refactoring and versioning
- Increase Effort of Governance
- Shorter life span

- Service-Oriented Analysis
Service Oriented Analysis represents the early stage in SOA and the first phase in service delivery cycle. It is a process that often begins with information gathering. This is accomplished iteratively and usually once for each business process.
This phase is accomplished jointly by business architects and technology architects to guarantee a higher degree of business-IT alignment. Iterations through analysis and modelling result in service candidates.
These Services are classified into Service Layers:

Service Entity (Product, Customer, Service, Invoice ...)
Service Task (Order Management, Business processing)
Service Utility (Non Business Centric, )

Analysis

• Perform Service Oriented Analysis

1. Define Analysis Scope to establish the boundary of the analysis
2. Identify Affected Systems
3. Perform Service Modelling

• Define Enterprise Business Model:

1. Define the scope
2. Accurately express the functions to be implemented

• Define Technology Architecture
  

1. Define initial architecture platform
2. Identify Architecture Constraints
3. Refine the architecture for each iteration
   

• Define Service Inventory BluePrint

1. Identify service inventory boundaries
2. Produce service candidates for this inventory

Within this step, the service conceptualization starts. It identifies service capability candidates. This phase also identifies service assembled into composed services. Basically, a business process is decomposed into granular functions and then services are assessed into groups of services that are specific or agnostic to the current business process. Below are the steps to perform this phase. This phase results with final version of capabilities of service candidates.

1. Decompose Business Process
2. Filter Unsuitable Steps
3. Identify Agnostic Service Candidates
4. Identify Process Specific Logic
5. Apply Service Orientation Principles
   
6. Identify Candidate for Service Composition
7. Analyze Processing Requirements
8. Identify Utility Service Capability Candidates
9. Define Utility Service Candidates
10. Apply Service Orientation
11. Revise Candidate Service Composition
12. Revise Capability Candidate Grouping

After applying the above steps, the service capability candidates will results in the following groupings.

1. Entity Services
2. Utility Services
3. Task Services
4. Orchestrated Task Services

Service Oriented Design
All the work put into the analysis phase resulted in set of service candidates that the design phase will take as input. Every service candidate is considered as starting point for service oriented design. It is recommended that the sequence of the design goes from the most independent service to the least independent:

• Design Entity Services
• Design Utility Services
• Design Task Services
• Design Orchestrated Services

During this phase, many considerations are taken into consideration to output a service contract in support to standards, principles and constraints. It is important to remember that a single service can provide a collection of capabilities. They are grouped together because they relate to a functional context established by the service.
When building the services as Web Services, this will require a definition of an XML schema to support the data type and structures to be exchanged. A WSDL is then built around the XML schema adjusted by the application of SOA principles and design patterns.
For Orchestrated services, it involves a composition of services and outputs WS-PBEL process definition.
Service-orientation places an unprecedented emphasis on reuse. I would like to quote Thomas Erl [1] book "By establishing a service inventory with a high percentage of reusable and agnostic services, we are now positioning those services as the primary means by which the solution logic they represent can and should be accessed. we make a very deliberate move away from the silos in which applications previously existed. Because we want to share reusable logic whenever possible, we automate existing, new, and augmented business processes through service composition. This results in a shift where more and more business requirements are fulfilled not by building or extending applications, but by simply composing existing services into new composition configurations. When compositions become more common, the traditional concept of an application or a system or a solution actually begins to fade, along with the silos that contain them".

- Design Challenges
Significant amount of services within the inventory can ultimately be comprised of agnostic services capable of fulfilling requirements for multiple potential service consumers. Although this can establish a highly normalized and streamlined architecture, it can also introduce an increased level of complexity for both the architecture as well as individual service designs. We will list few challenges that the design shall address and there are many other things that should be addressed but we will not address them in this article.
- Performance requirements & scalability
- Single point of failure resulting from excessive use of a service
- Service Contract Versioning
- Authentication
- How can service logic be positioned as enterprise resource
- Service Normalization / denormalization

 It is important  to position SOA as an architecture model that is Vendor neutral or even Technology neutral. By doing, we position the enterprise to pursue and leverage on-going technology advancements. Many  SOA design patterns help address these common issues and for each SOA design principle there are set of patterns that can be applied to successfully achieve the objectives of each principle.
In the beginning of this article we listed  a list of Service Orientation Principles, that should be applied to a business capability to shape it as Service. For each of these principles, we will apply a set of SOA design patterns to satisfy it.
We will list a set of design patterns that can be applied to satisfy each principle and produce individual logic units that can be qualified as services. The design pattern are shown in ITALIC. There are off course more design patterns and each project is different, I will list the design patterns we applied in our project at DSOFT SYSTEMS.

• Standard Service Contract: Services within the same inventory are in compliance with the same contract design standards. The following design patterns needs to be applied to get a Standard Service Contract: Canonical Protocol, Canonical Schema, Canonical Versioning, Concurrent Contract, Contract Centralization, Contract Normalization, Contract De normalization, Composition Autonomy, Agnostic capability, Proxy Capability

• Service Loose Coupling: Service Contract requires a low consumer coupling and themselves decoupled from their surrounding environment. The following dessign pattern help achieve this objective: Asynchronous queuing, Decoupled Contract, Data Format Transformation, Event Driven Messaging, Service Facade, Proxy Capability
  

• Service Abstraction: Information about service is published in the contract. The contract only contains essential information about the service. Utility Abstraction, Service Perimeter Guard, Service Refactoring,  Validation Abstraction.
  
• Service Re-Usability: Services contain agnostic logic and are positioned to be re-usable enterprise resources. These design patterns help achieve this requirement: Agnostic Capability and context, Capability Composition, Consurrent Contract, Logic and Rules Centralization,  Service Layers.

• Service Autonomy: Services shall run in their own environment and exercise a control over the underlying runtime execution environment. Canonical Resource, Distributed Capability, Service Normalization, Capability Recomposition.
  
• Service Statelessness: Services shall optimize resource consumption by deferring the management of state information.  Asynchronous queuing,  Atomic Service Transaction,Service Grid, Service Instance Routing.
  

• Service Discoverability: Services comes with metadata by which they are be discovered and interpreted. Canonical Expression, Metadata Centralization.
  

• Service Composition: Service composed of sequence of other service to form a new service. The following design patterns help to guide how to achieve this objective. Decomposed capability, Agnostic capability, Brokered Authentication, Capability Composition, Data Confidentiality, Dual Protocol, Reliable Messaging.
  

Standardization
It can be a straight-forward process to create these standards to support SOA, incorporating them into an IT culture already set in its ways can be demanding to say the least. The introduction of design standards implies a need to enforce them, SOA governance and its challenges addresses how governance of SOA.


How to choose the Technology
As we apply these design patterns to achieve SOA goals expressed in the beginning of this article, we started with a list of technologies that included weblogic/Aqualogic, Mule, Spring, JBoss Enterprises Suite ...etc. We proceeded by elimination and narrowed the choice of tools and technologies to a small set that can help us achieve our objective in optimized and timely manner. For instance, for service composition, there are many vendors offering what we wanted at different costs and we narrowed it to two: Mule ESB and JBOSS ESB. We did choose JBoss ESB because it is well integrated with JBPM and JBoss rules to implement the rules centralization and achieve a higher level of orchestration.
In conlusion, I would like to insist that the choice of technology should be based on the goals that must be achieved and dictated by the business which are:

1. Increase Interoperability
2. Increased federation
3. Increase Vendor Diversification
4. Increase Business and technology Domain Alignment
5. Increased ROI
6. Increased Organizational Agility
7. Reduce IT burden

By Sadi Melbouci

References:
[1] Thomas Erl, SOA Principles of Service Design,