Not surprisingly, the topic of Enterprise Service Bus (ESB) has been a controversial one, extensively covered here on Loosely Coupled. Fortunately, vendors seem to agree on one thing: the enterprise service bus is necessary for efficiently constructing an SOA. Without such infrastructure, the promise of web services won't be fully realized and organizations won't benefit from the flexibility and cost savings they initially expected.

	express delivery
	• print  • comment
	An ESB that forces you to use yet another MOM implementation will merely add to the complexity of the architecture that must be managed. Christopher Warner is technical marketing manager and Olivier Moratin is product marketing manager at mainframe and XML integration vendor Software AG, which offers a range of XML business integration products for loosely coupled access to enterprise information, services and legacy resources.
	Glossary terms: ESB, MOM, SOA, orchestration, JMS, lookup tool Sponsored links: your text link here

Among the issues being debated is whether or not Message Oriented Middleware (MOM) should be built into the ESB, or merely used as an architectural component by the ESB. If you think of the ESB as something you build, the MOM piece is certainly part of the construction. We, however, think that, in order to Demystify the ESB, and understand it as a product, we need to declare its 'de-MOM-ification'. To put it more colloquially, "although one cannot choose one's parents, organizations buying an ESB should at least be able to choose their MOM."

The ESB debate between vendors (Software AG included) is also potentially confusing to buyers. For example, how can a vendor describe the ESB as an architecture when SOA is the architecture enabled by the ESB? As vendors of the ESB infrastructure, we should be focusing instead on building features critical to SOA.

Conversely, buyers of technology — such as enterprise architects — should put on their business 'gloves' and grasp the ESB concept by the 'handle' of how it helps materialize the business benefits of SOA.

In both cases, the MOM will quickly appear as playing a supporting role in the context of service oriented architecture, and not what defines an ESB. With this idea in mind, we suggest a few starting thoughts for those business-minded buyers and their potential vendor(s) ...

Business benefit #1: SOA and ESB decrease costs through reuse

The business value of SOA and Web services is to enable reuse of existing assets and lower integration costs through open standards and greater flexibility. Legacy integration is the perfect example. Organizations see SOA as a great opportunity to finally transform their monolithic mainframes into agile and graceful systems, and enable them for real-time information and event-driven architectures (EDA).

Organizations interested in SOA should think about how to get more value from all of their IT assets (including existing MOM platforms), either through service orientation or JMS support. An ESB that forces you to use yet another MOM implementation will merely add to the complexity of the architecture that must be managed. Companies already overwhelmed by integration silos will find little business value in implementing another MOM layer (or replacing old ones) to run their ESB — particularly when their existing products are running well and are opened up via standards.

Business benefit #2: Manage cost and risk through incremental implementation

The second business value of SOA is that it helps manage cost and risk by enabling construction of a strategic IT framework, while allowing incremental adoption and implementation. Specifically, a successful SOA is designed by IT and business users working closely together to define the services and business information models that will serve business users. Only then can the implementation phase begin in an incremental fashion, thanks to loose coupling and reuse.

However, to truly benefit from the incremental nature of web services, organizations must also ensure that the SOA backbone is distributed and able to scale organically with the size and performance requirements of the architecture. That is exactly where the enterprise service bus, as a product that doesn't itself include a MOM, can provide the biggest bang for the buck. Unlike other integration products, such as brokers, the ESB should offer standards-based, distributed, and scalable yet robust integration capabilities.

Business benefit #3: Helping IT focus on business challenges

A third benefit of SOA is its ability to alleviate the pain related to connecting proprietary systems and learning the intricacies of many diverse systems. Organizations willing to make their IT team more business focused should consider an ESB that can provide comprehensive orchestration, transformation and message enrichment (or mediation) capabilities in one single tool. With the elimination of low-level coding through an XML-driven graphical environment, integration architects can focus on delivering the processes, composite applications and information views that business users really need.

With respect to orchestration, potential ESB buyers should also remember that SOA, at least for now, is more than web services and BPEL orchestration. SOA adoption will also be incremental, and the ESB should be able to support other means of connecting to systems and data sources, for instance through JCA, JDBC and JMS. The JMS interface will allow guaranteed message delivery and long running processes via any existing MOM. In other words, the MOM is only an enabling piece of the architecture, not a feature requirement for an ESB.

Reaping the rewards

Unlike integration brokers and message-oriented middleware — which typically were implemented tactically and primarily addressed connectivity issues — the implementation of an enterprise service bus can add a lot more business value and have greater business implications:

• As part of an SOA implementation, organizations should view the ESB as the product and/or architecture reusing all types of existing infrastructures (including existing MOMs), and something that they should be able to extend gradually across all systems and partners.

• As the piece simplifying integration and allowing IT to focus on single views and processes, buyers should pay close attention to the ESB's orchestration and mediation capabilities — not only for the integration of web services but also for other existing IT assets such as MOMs.

The intensifying debate over various aspects of the ESB shows the de-MOM-ification of the ESB is on its way, with a stronger focus on orchestration and XML message handling. This is certainly better for architects who need to bridge existing silos, reuse legacy applications, reduce the complexity of their architecture and — finally — demonstrate that IT can more fully deliver business value.

More on this topic