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,

SOA Governance and its challenges

By Sandrick Melbouci

From DSOFT Technologies

Introduction

Service Oriented Architecture enables enterprises to pursue business and technical strategies that promote the exposure of business functionality within and between enterprises in consistent, published, secure and contractual fashion.
However, Service Oriented Architecture is not a solution that comes in tidy box. It is more about new way of design, it is more about culture then it is about technology.
To ensure success of any SOA implementation, it is necessary to include some type of governance that define the policies and practices all services should follow.

Why some SOA implementations failed?

SOA Governance is probably the most talked and most delicate topics in SOA nowadays. About 5 to 6 years ago, many organizations approached SOA as implementing a web service. There was no attention to SOA Governance. This may be explained differently, but the situation reminds me of a practice of some IT managers – just get it to work and take a look at the design later. As we all know, any temporal fix becomes a permanent solution with consequences dealt with later at higher cost.
In one of the my consulting jobs, the organization thought that SOA was a new integration technology that will magically integrate all their existing assets. One of the managers asked me to start looking at the code to perform this funny integration. When I told him what SOA meant, he got a chock of his life. Without going into details, many organizations built hundreds of services/components and run into scalability, performance, manageability and integration problems.
One of the main reasons of this type of difficulties is that service-oriented, design, implementation was not governed at all or governed with traditional software development without any clues on service orientation [1] methodologies.
In this article, we will present SOA and its Governance policies to address these problems.

What is SOA?
Multiple definitions of SOA were presented in the literature, I will summarize some of them in here. SOA is architectural style who's goal is to achieve re-usability and loosely coupling paradigm among interacting agents. Within SOA, services are mechanisms by which needs and capabilities are brought together.
SOA operates in an integrated business-technical context as opposed to traditional business-IT separation.
Anne Thomas Manes from Burton Group said, “SOA is a style of systems architecture, not integration architecture. It’s about refactoring capabilities into services, not about integrating application silos”.

What is SOA Governance?
Governance is set of rules, policies and regulations under which an organization functions as well as the processes that ensure compliance. SOA governance refers to processes that ensures that services and applications are developed so that they are aligned with :

• Best practices
• Business requirements
• Laws
• SLAs
  

SOA Governance has two main component:

• Design Time Governance also called "SOA governance framework", captures information about the services and policies.
  
• Runtime Governance or sometimes called as "Service life cycle management", enforces the policies during the execution, management and service discovery.
  

The need for enterprise governance is business oriented to integrate business initiatives (supply chain, order management,...) with IT initiatives (EAI, Web service, ...). The companies needs to move from "develop now and integrate later" to "develop for integration". To ensure business continuity, reduce cost and complexity and limit corporate liability, the companies shall define the policies and procedures early in project life cycle to allow:

• Prevention of service proliferation and promote reuse
• Define Services with the right granularity
• Utilize a formal service description model with appropriate metadata
• Develop and implement best practices for interoperability
• Approach SOA on how it will be deployed and consumed
  
• Manage and monitor service health, performance and Quality of service
• Audit and measure compliance
  
• Define and manage Policies and contracts centrally
  
• Central registry-repository to describe all services and associated metadata
• Service mediation and discovery
  

Design Time Governance (Governance Framework)
There are mainly four phases to SOA governance framework: Plan, define, Enable and Measure.

• Plan Phase, the overall business and IT requirements are understood and documented
• Define Phase, the SOA governance approach is established based on corporate, enterprise and IT governance environments
• Deploy Phase, governance mechanisms are put into place, the organization is educated, and governance policies are deployed.
• Measure Phase, policy compliance and effectiveness are monitored and audited.

Runtime Governance Compliance (Service Lifecyle management)
The runtime governance encapsulate the phases to model, assemble and deploy. These 3 phases are broken into two separate facets:

• Service Development and Delivery Management
• Support Infrastructure and Management

Service Development and Delivery Management
Service Development and Delivery addresses the essential needs to govern the services development through the established governance framework. The areas of focus are mostly:

• Change and release management - What, When and by whom a service can be changed
• Requirements and Quality Management - Ensure services are developed in compliances with business requirements and compliance.
• Design and Construction - Ensure the best practices and design principles are appied for maximum.
• Asset reuse.
• Service Versioning
• Service Retirement
  
• Process Management - Continual auditing to make sure that the process is followed

Support Infrastructure and Management

Environment

• Distributed, cross-boundary services and access present security risks
• Rapid deployment and loose coupling of services
• Performance and prioritization of services

Service Security

• Need to manage identities and access control cross multiple platform, applications, business partners and entities
• Need for E2E security architecture that can be deployed and integrated with existing and disparate security models
• Need to define encryption policies
  
• Need to consistently enforce security policies

Service Management

• Federate identity and access control
• Secure services and applications
• Consistently enforce security policy

Service Virtualization

• Support scaling infrastructure resources
• Prioritize infrastructure across multiple services and/or business processes (composite/dynamic applications)
• Accelerate application performance by distributing the composites across multiple infrastructure resources.
  

Service Registry and Repository
Service Registry contains the policies, description and metadata for each service present in the enterprise. It provides a mechanism to find services and their metadata.



Conclusion
SOA governance requires policy control and audit framework that spans the security, service definition, identity domain, service consumption and people. A SOA governance framework requires some means to consistently define some policy and managing it through its lifecycle and provisioning from central accessible policy registry and enforcing its execution across distributed systems.
Enterprises will only benefit and further improve their competitive advantage and quality of service by utilizing an automated policy governance. By doing so, the organizations will be able to leverage both their IT assets and human capital.

By Sadi Melbouci

References:
[1] SOA Design Patterns, Thomas Erl, 2009
[2] SOA-RA public Review
[3] Reference Model Service Oriented Architecture
[4] Does web service make a service for SOA

Page Rank 4 in 60 days

How to accomplish google page rank 4 in 60 days?

By Sandrick (Sadi) Melbouci

At the end of this year - 2008, I got a nice christmas surprise. My site went from google rank 0 "zero" to 4 in 60 days.

My web site, Practice Management Software, was first crawled sometime in the end of October. I decided to increase the rank of my site and traffic with a minimum budget. I laid out a plan and below, I will discuss the tasks that I executed in the sequence that they appear.

Page Header Elements

Designed the pages to be SEO friendly with modern web page build design. Paid attention to the following:

- Page title

The name of web page has the name of the title

- Page header

The title has the first H1 header in the page

- Meta description

The page description has the title in it as the first sentence.

- Meta tag keyword

3 to 4 keywords per page.

Page Design

- Usage of CSS

Take advantage of modern web page design. Styles should be defined in a CSS document that references the elements, IDs, and classes in the XHTML document.

- Page size

Google only crawls the first 100k. Kept the page to less then 50k

- Eliminate Obsolete or deprecated HTML

Use modern design techniques and used proper combination of XHTML and CSS

Link popularity

- Submitted the site to the major search engines including Yahoo, Google, Altavista, ...etc

- Submitted the site to web directories: Yahoo, DMOZ, Allweb, BOTW ...etc, submitted the site to the correct caegories. This will provide one way link to your site.

- Started a blog and wrote articles on the subject related to my site.

- I commented on other blogs related to my site

- Added an RSS feed to my site

- Made the keywords as the anchors

- Finally, I have exchanged links with other sites on the same subject domain as my site. Making sure that the anchor in the link is one of my keywords.

Keyword Density

- I focused on 3 to 4 keywords per page that were defined in the keyword meta data header element.

- I wrote the text in the body for the potential customers describing my product without repeating too much the same keywords and used bold where needed.

- Put one keyword in alt image attribute and title

- Put one keyword in name and title of the link attribute

Advertising

I have noticed that some of the ads from Google and Yahoo advertised as content (This type of ad appear on some articles related to subject described in the ad). When these sites get crawled, The search engine counted it as one way link.

I guess this might be a temporal link but counts to increase both the organic and advertised traffic.

That's all. It worked like charm.

Medical Practice Software

Download Medical Practice Software