SOA: Riding The Enterprise Service Bus

Whichever way you lean, right now, it seems that just about everyone is

talking about Service Oriented Architecture (SOA). More and more organizations

are looking to Web services and SOA to better align IT and business, and at the

same time help them to address multiple, complex challenges-ranging from

increased scrutiny of IT investment with an emphasis on cost containment; a

shift away from automation in the back office to collaboration with customers,

partners, and suppliers in the front office; to tackling the proliferation of

standards-based commodity platforms.

Whatever the challenge, SOA organizes the discrete functions contained in

enterprise applications into interoperable, standards-based 'services' that

can be combined and reused quickly to meet business needs. By organizing

enterprise IT around services instead of applications, SOA helps companies

improve productivity, enable faster time to service and increase agility to

respond to changing business conditions. And it's happening now. According to

Forrester, 77% of large enterprises, 51% of medium enterprises, and 46% of small

enterprises are actively implementing SOA.

In adopting a SOA strategy, IT is not going to 'rip and replace' its

existing infrastructure due to cost and complexity. Instead, it will try to

extend existing business applications by exposing them as services so they can

be used in other business processes and applications. As a result, core to the

success of SOA is having an integration layer that supports dynamic interactions

across services in a heterogeneous environment. The integration layer must

accommodate the one constant in IT-change. It must support the continual

evolution of existing services and the rapid addition of new services as the

business grows to address new customers, partners and business imperatives,

while insulating the service consumers from changes at the service endpoints.

The service layer must be designed to eliminate the need to manage interactions

between services from the service endpoints themselves. That way, services can

evolve without causing breaking points inherent in point-to-point

implementations. Today, this integration layer is referred to as the Enterprise

Service Bus (ESB).

ESBs deliver the key capabilities that enable services to interact

dynamically: a service registry for publishing services, service versioning, and

message brokering, dynamic routing and transformation between services. ESBs are

expected to support message and transport security as well. They typically act

as distributed intermediaries, enabling the policies associated with routing

rules, transformations, security and access to be abstracted from the endpoints.

And, just like SOA, ESBs are a reality. Forrester estimates that about a third

of the US infrastructure decision-makers plan to increase the scope of ESB

deployment in the next 12 months.

ESB Versus the Rest



So how does an ESB compare with other infrastructure integration layers? Web

services, firstly, add a layer of abstraction, using open standards to provide

access to applications in a way that is easy to understand and use. However, Web

services alone are insufficient for general integration projects. Web services

standards lack specifications for management of reliability and security. They

also do not provide the general-purpose mediation and process management

required to bridge the gaps between the needs of Web service consumers and the

capabilities of Web service producers.

Application Platform Suites (APS) suffer similar drawbacks. These are

difficult to deploy or re-configure across various servers in a distributed

network. An APS provides visibility and management for business processes

running in a single server or a cluster of like servers. It cannot though

provide a unified view or manage processes running across heterogeneous servers,

or servers in a distributed environment. As a result, environments such as .NET

and the EJB container in J2EE are poorly suited to the task of managing

significant numbers of dynamically configured services in an enterprise SOA.

Unlike an APS, the ESB service container allows the selective deployment of

mediation services exactly when and where you need them, and nothing more. In

contrast, you have to install an entire application server stack everywhere and

an individual piece of integration functionality is needed. This results in

unnecessarily high costs for licensing, installation, and cost of ownership over

time.

Third, traditional EAI products were specifically designed for application

integration. They performed application-to-application mapping in a

hub-and-spoke model, which concentrates too much complexity at a single point

for integration of more than a handful of applications. In development, it is

too expensive and impractical to staff a project with IT professionals, the EAI

product and in the semantic details of all the applications to be integrated. In

deployment, scaling an EAI product's centralized hub-and-spoke architecture to

accept additional duties requires excessive computing resource in a single

server or cluster of like servers run in a single LAN segment

An Agile Infrastructure



While many infrastructure solutions are described as ESBs today, not all

address the needs of service integration in a heterogeneous IT environment. ESBs

must enable service interactions between services running on a variety of

application platforms, including legacy stacks, .Net, J2EE, and other widely

adopted technologies. In a SOA, services are designed as consumers, accessing

and consuming the value of other services. The ESB needs to shield the service

consumers and providers from complexities arising from differences in

implemented transport protocols and message formats. The ESB is designed to

remove the difficulty of translating between what one service 'speaks' and

what another service 'speaks'-dynamically transforming between the

different service endpoints using interoperable standards such as XQuery.

Bringing it all Together



Over time, the service infrastructure implementations, which succeed will be

those that provide capabilities that are integrated from both a development and

a management perspective; but that are also open and extensible through

established standard protocols and interfaces. Core to these successful

implementations will be a unified service metadata repository, which underpins

all infrastructure capabilities.

An ESB represents the direct route to competitive advantage as a

service-driven enterprise. Forrester sees two clear segments in the ESB market.

Firstly, the 'ESB Suites' segment, which is defined as the 'keep it

simple' buyer. ESB Suites are defined as ESBs with optional components for

service orchestration, service management, and partner collaboration delivered

as suites. Secondly, the 'Comprehensive ESB Suite' market, which is defined

as the 'I want it all now' buyer. Comprehensive ESB Suites are full-service

integration suites that encompass all of the ESB suite features plus support for

human workflow, vertical industry solutions, portals, rules engines, and more.  

Deploying SOA through a service infrastructure layer is a technical reality

today, but make certain your ESB supports extensive heterogeneity and integrated

manageability in a unified solution. You'll regret it if you don't.

Dhruv Singhal



head-Professional Services, BEA Systems



maildqindia@cybermedia.co.in