Advertisment

SOA: Riding The Enterprise Service Bus

author-image
DQI Bureau
New Update

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.

Advertisment

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.

Advertisment

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.

Advertisment
A service
infrastructure for SOA, including an enterprise-class services integration
layer-or Service Bus-enables the business to be more agile,
service-driven, and focused on efficiency

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.

Advertisment

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.

Advertisment

Dhruv Singhal

head-Professional Services, BEA Systems

maildqindia@cybermedia.co.in

Advertisment