Advertisment

Service Oriented Architecture

author-image
PCQ Bureau
New Update

If there's one word that has got vendors up on their toes and developers

geared up big time, it's SOA (Service Oriented Architecture); an approach that

has been around in different flavors for quite sometime. Now it is back with a

bang and looks like one of the enablers for betterment in a lot of solutions, be

it BPM, or Business Applications, or even Application and Data Integration. We

look at what's happening in SOA and the developments that will drive the SOA

world in the days ahead.

Advertisment

ESB



Enterprise Services Bus (ESB) is one component that has been central to the
entire SOA buzz. Not surprisingly, it has become a product that is being shelled

out by almost all vendors who have ventured into the SOA solutions provider

space. What makes ESB such a hyped thing after all? What do you need to consider

before deploying an ESB in your enterprise? Well, it's a lot different from

what is being perceived. ESBs mostly provide a middle layer between services and

their clients in SOA architecture. But that does not mean that every ESB being

rolled out is actually the solution you were looking for in your SOA

implementation.

Let's take a look at how one needs to evaluate the needs and products for

going the SOA way. Well the first and foremost step is to simply categorize what

the product is all about, to start with an ESB or an ESB-like product (we'll

talk a bit later about what we mean by ESB-like), application server,

integration server, orchestration/choreography or service management.

Advertisment

Now in case you find a vendor saying their product does all-believe us, he's

not the smartest one to implement your project, as some of the best products

would actually do only one of these. The whole ocean of definitions that have

cropped up for ESB is another pain as a client. Let's look into what really an

ESB should be and what it might actually be-as is the case with quite a few

ESB products. Your ESB should be able to abstract and manage services and not

just information that flows through components.

A product that does more of latter would be nothing more than a queue

assembled for information flow-that's not what SOA is all about. On the

other hand, if the ESB product is more about developing and deploying services,

and managing their participation in systems that are being executed or

implemented, then we have a product that is truly service oriented. So, in case

you come across a product that smells more like the former-do away with it for

your SOA dreams to materialize and be profitable to your organization.

Advertisment

SOA-The road ahead



About a year ago key players in the Indian arena had all geared up to the SOA
initiative in this country. Not much had come in over here as far as this

methodology is concerned, and there aren't many success stories for SOA in

this country yet. However, there are a few promising solutions based on SOA

cropping up.

Standards wars
In November 2005, the Open SOA collaboration

was initiated by a group of vendors such as BEA Systems, IBM, IONA,

Oracle, SAP AG and Sybase. By July 2006, osoa.org, the Open SOA

collaboration website, was launched for providing information on public

drafts, white papers and obtaining feedback. The collaboration had started

working on two major projects-Service Component Architecture (SCA) and

Service Data Objects (SDO). The drafts have matured a lot since November

last year. But the bigger question here is that OASIS (Organization for

Advancement of Structured Information Standards) has already released an

SOA standard, called SOA Reference Model and is on its way to finalizing

another 'Open' standard called SOA Adoption Blueprints. These specs

address almost similar issues. We wonder whether this will become an

example of too many cooks spoiling the broth! Do we need a flood of

standards for a technology that has not fully matured yet? We are not

trying to say that OSOA is uncalled for, but yes one would surely want to

know which specification to look into, when it comes to implementing an

SOA project based on open standards, as both bodies are working on what

they call 'open standards' for SOA.
Products
Some of the SOA products are centered



on ESB, while others have a complete package. Sonic Software has an ESB
solution called Sonic ESB, where as IBM also has a similar solution based

on Websphere. BEA has also rolled out Aqualogic Bus, their ESB product.

Similarly, other vendors such as Cape Clear Software have come up with



Cape Clear ESB. SAP provides SOA and


ESB solutions, largely built around their Netweaver platform.

Advertisment

And key players in the country have bagged quite a few SOA based projects.

In the days to come, SOA will boom further over here as much as any other

place, owing to the ease with which it can be adapted to any domain, be it

business applications such as CRMs, ERPs or daunting tasks such as EAI or Data

Integration. Added to this is the ability of SOA to leverage the existing 'legacy'

systems as services. Last year Sonic Software, Amber Point, BearingPoint and

Systinet announced a Service Oriented Architecture Maturity Model, which defined

maturity attainment in five stages. The first stage is Initial Services to

Optimized Business Services. IBM also released its own maturity model called the

Service Integration Maturity Model that classifies seven maturity levels,

addressing issues from IT infrastructure to business viewpoints.

From vendor specific SOA maturity models last year, SOA has graduated to an

open standard called SOA Reference Model, standardized by OASIS (Organization

for Advancement of Structured Information Standards) in Aug 2006. And that's

not enough, OASIS is on its way to finalizing the SOA Adoption Blueprints, an

initiative that started last year. 

Advertisment

This document will illustrate a set of example business profiles or 'adoption

blueprints' to show the practical deployment of services using SOA methods.

So, with open standards for implementation already finalized and an adoption

blueprint on its way, you can bank on this technology for your needs more

reliably. In the days to come, we expect SOA technologies to be the hottest one

to look for.

OASIS SOA Reference Model
It provides a technology and vendor neutral

description of SOA and architecture of SOA implementations in a generic

sense, that can be applied to any specific SOA project.

The reference model defines seven building blocks for

SOA implementations.

The first one is Service, which is defined in the

specification as an access enabler to a particular capability. In

implementation words, a service is the implementation of a key process, or

functionality in the organization. The spec similarly defines other

concepts such as visibility, execution context, service description,

interaction, real world effect and contract & policy.

OASIS SOA Blueprints



This specification, though still not standardized, provides a blueprint
for enterprises on how to go about the requirements and functional

adoption of SOA in their organization.

OASIS Semantic Execution Environment



This specification provides implementation guidelines for the environment
wherein Web Services used for SOA will be executed. Like SOA Blueprints

initiative, this one is also not standardized yet.

OSOA SCA Project



This project defines the Service Component Objects, viz. how to create the
components that will implement the services and how to assemble all the

service components to give a solution using different languages.

OSOA SDO Project



The SDO (Service Data Objects) defines what and how data is to be handled
from distributed and diverse resources for bringing them under a unified

semantic in SOA implementations
.

Advertisment