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