The theme of Accenture chief technology officer Don Rippert's recent interview that the full potential of SOA is still five years away. However, buried in the interview was simple assertion--that the use of an Enterprise Service Bus (ESB) is step three out of four steps to realize the full potential of an ESB. The steps in Don Rippert's model are:
- Use of eXtensible Markup Language (XML) to use application interfaces in a more standard way.
- Taking some business processes and turning them into web services.
- Introduction and full use of the enterprise service bus.
- The generation of Business Process Execution Language(BPEL) --the ability through business processing modelling tools and BPEL to create different application behaviour without changing the software
Mr. Rippert stated in the interview that many organizations have an ESB but have yet to make full use of it. He further stated that most companies are still in phase one. This positioning for ESB lies in contrast to statements made by Burton Group analyst Anne Thomas Manes in a recent discussion on the Service Orientated Architecture(sic) Yahoo Group. Anne says:
...an ESB is not on my list if the few "basic components" that I recommend for getting started with SOA. In fact, I discourage people from starting with an ESB. An ESB does not encourage good SOA behavior. ESBs are essentially integration systems, not SOA systems. SOA is about tearing down application silos, but integration systems reinforce those silos.
Referencing her book, she goes on to mention that the basic components include:
- One or more service platforms (e.g., .NET, a Java EE app server, etc.)
- An SOA management solution
- A registry
- An XML gateway if services will be exposed outside the firewall
Referencing an earlier posting from a group member, she says:
"...an ESB is especially good for bridging to legacy applications, and therefore it is a useful component in a services infrastructure. Many ESBs also support reliable messaging, asynchronous messaging, and pub/sub exchange patterns. These capabilities can also be pretty useful--but probably not in the initial stages of a SOA project. (Every organization has lots of projects to choose from that don't require these capabilities.) At a later stage in a SOA project, you might also want an orchestration engine, and most ESBs supply one--but that definitely isn't where an organization should start a SOA initiative. All of these capabilities are things that you don't need when first getting started. Therefore an ESB should be a later-stage purchase."
This seems to fit with Mr. Rippert's view that many organizations have ESB already, but have not made full use of it. Ms. Manes's comments also serve to help define the field of ESB and it's appropriate set of capabilities by suggesting features that many ESBs support.
According to the Wikipedia definition of ESB, an ESB has the following features:
- it is an implementation of Service Oriented Architecture
- it is usually operating system and programming language agnostic; it should work between Java and .Net applications, for example
- it uses XML (eXtensible Markup Language) as the standard communication language.
- it supports Web services standards
- it supports messaging (synchronous, asynchronous, point-to-point, publish-subscribe)
- it includes standards-based adapters (such as J2C/JCA) for supporting integration with legacy systems
- it includes support for service orchestration & choreography
- it includes intelligent, content-based routing services (itenerary routing)
- it includes a standardized security model to authorize, authenticate, and audit use of the ESB
- it includes transformation services (often via XSLT) between the format of the sending application and the receiving application, to facilitate the transformation of data formats and values
- it includes validation against schemas for sending and receiving messages
- it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
- it can conditionally route or transform messages based on a non-centralized policy - meaning that no central rules engine needs to be present
- it is monitored for various SLA (Service-Level Agreement) thresholds message latency and other characteristics described in a Service Level Agreement
- it (often) facilitates "service classes," responding appropriately to higher and lower priority users
- it supports queuing, holding messages if applications are temporarily unavailable
- it is comprised of selectively deployed application adapters in a (geographically) distributed environment
This wikipedia definition concedes that "the exact definition of an ESB varies".
Both Ms. Manes and Mr. Rippert seem to agree that an ESB is useful and represent a later stage set of functions for SOA deployments. The wikipedia definition can serve as a starting point for discussion about how this useful technology is defined.
In the ensuing discussion, please focus on the definition of an ESBrather than on the views of the industry experts cited in the article.
