Four ESBs That Won't Cramp Your Style

An enterprise service bus should require minimal tech expertise and coding, yet in our lab test of eight ESBs, four products has us tied up in knots. The leaders on our shortlist excelled at mediation, transformation and orchestration.

Reader interest in enterprise service bus systems is on the upswing, so we set off on a collaborative journey with our sister publication, Network Computing, to gain hands-on insight. Our coverage focuses on service-oriented modeling, mapping and registry integration, while Network Computing's coverage concentrates on IT needs and concerns.

The team at Network Computing's Green Bay, Wis., business applications lab installed and tested ESB suites from eight vendors: BEA Systems, IBM, Cape Clear, Fiorano Software, Oracle, Sonic Software, Software AG and TIBCO. Some 13 vendors were invited to participate, but Microsoft, PolarLake, Sun Microsystems and WebMethods declined, and Iona's Artix 4 wasn't released until after testing was completed.

To evaluate the products, we built a service orchestration that demanded integration with Oracle9i, which contained inventory data, an external JMS queue to integrate with our manufacturing systems, an external .Net Web Service to kick off the shipping process and an e-mail server to notify customers of their order status. The orchestration required simple, content routing based on inventory level to determine the next service to which a message should be routed; it also involved mapping of data (transformations) from service to service within the orchestration. After extensive testing, we put four ESBs on our shortlist for their minimal technical and coding demands and their user-friendly transformation and service orchestration capabilities.

The Low-Demand Ideal

A solid SOA infrastructure requires both service enablement and service orchestration to properly enable service-oriented business applications and BPM (business process management). The ESB is the service-orchestration layer, providing support for arranging atomic services (the service-enablement layer) into business services for use at the business process layer. Those handling service enablement must have technical competency and be able to write code, but an ESB should let nontechnical, noncoding users realize the advantages of the SOA. Applying SOA principles means using an open-standards approach and metadata-based description of the orchestration, not a hard-coded, tightly coupled solution that destroys the agility promised by the SOA.

The best ESB implementation will require no domain expertise in specific technologies, such as JMS (Java Message Service) or other messaging technology, but will instead require only technical competency in SOA-based languages and technologies, such as WSDL, XPath, SOAP and WS-Security. Although a standards-based modeling language would be a boon, it isn't a requirement as long as the product requires no code and fulfills the basic functions of an ESB, such as routing, transformation, integration of services over multiple protocols and exposing orchestrated services as a Web Service over HTTP or JMS.

Tied Up In Details

You shouldn't need to know about the inner workings of the messaging bus to orchestrate messages. We were generally pleased with the level of abstraction provided by most of the products we tested, but were disappointed by the offering from Sonic Software in its decision to expose the orchestrator of services to a heavy dose of messaging terminology and configuration options. Not only were we required to understand the notion of JMS endpoints, we had to pay careful attention to its implementation of QoS (quality of service) imposed on those endpoints lest our orchestration be deemed improperly configured.

Although all the products required some sort of messaging backbone and generally defaulted to a message queue or JMS implementation (particularly products from vendors with a heavy investment in messaging, such as TIBCO and IBM), none of them exposed us to the mechanical details in such a heavy-handed way as Sonic did.

Several products (those from Software AG, Sonic and TIBCO) required that we know a lot more about the inner workings of a WSDL (Web Services Definition Language) file to expose orchestrated services as a Web Service than we consider appropriate. TIBCO's product didn't require that we modify its default values for port-type, message parts and bindings, but it did overwhelm us by showing us these nitty-gritty details, which might lead to the temptation to modify the values without the required know-how. We preferred the autoexposure capabilities of the suites from Oracle, BEA and CapeClear to the products that required us to build a WSDL (those from Fiorano, Software AG and Sonic) before exposing our service to the outside world. And we certainly weren't excited by Fiorano's inclusion of domain specific data — JMS headers — in the WSDL creation process.

Cramping on Code

A codeless approach is a must at the service orchestration layer, and we evaluated each ESB on its ability to orchestrate a simple composite service without requiring code.

Orchestrating services without code means that only metadata is required when moving services from one environment to another and, optimally, would provide interoperability between bus implementations. But interoperability requires an accepted, standard-based metadata language — something that isn't going to emerge any time soon. Although BPEL (Business Process Execution Language) is leading the pack as an interoperable metadata language to describe service orchestrations, it's problematic because it isn't a standard and the version that is expected to be adopted as a standard (2.0) is radically different from the current 1.1 spec.

Only Oracle and Cape Clear use BPEL 1.1 as their orchestration language of choice, with Fiorano and TIBCO offering secondary support as part of their offerings. IBM and BEA view BPEL as a business process layer language, and though that view is a bit forward looking — BPEL 2.0 is expected to address the lack of human workflow in the 1.1 spec, a requisite component of BPM systems — we see their point. But without BPEL or some other accepted standard, we're left with a wide variety of proprietary metadata descriptions for orchestrating services that can't be easily migrated from one system to another. The end result is vendor lock-in.

Even without a standards-based metadata language, most of the products tested do, in fact, offer a codeless service orchestration environment. BEA's AquaLogic Service Bus is not only codeless, but also client-free, requiring only a Web browser to orchestrate services comprised of both internal and external atomic services. Other codeless orchestration environments are currently — or will be this year — Eclipse-based plug-ins.

Not all products are codeless, nor are all products purely metadata based. Cape Clear's ESB 6.5, for example, relies on a code-generating, Eclipse-based design-time environment and requires that code and associated libraries (JAR files) be deployed en masse to its ESB server. Cape Clear also requires that some technology — such as RDBMSs and e-mail — be coded into a service before they can be included in an orchestration. Sonic's SOA Suite requires JavaScript to perform simple content-based routing within an orchestration, and IBM's Message Broker 6.0 requires ESQL (Extended SQL) or Java to include RDBMSs and e-mail in a service orchestration.

And though all the products provide the means to end up with a SOAP-accessible Web Service from an orchestration, not all are as seamless as the automatic service enablement of orchestrations from BEA, Cape Clear and Oracle. Most products require you to add this capability to an orchestration, which in turn registers the service as available for external consumption. The process by which an orchestration is enabled as a Web Service varies from product to product, but all involve the generation of a WSDL and only one (Software AG's Enterprise Service Integrator) lets you define WS-Security requirements during that process.

A Transforming Experience

Messages entering the ESB are certain to leave at some point, but they aren't necessarily going to be in the same format as the original request. A purchase order entering the bus contains data that must be routed to both manufacturing and shipping, but it's likely that the amount and format of that data is different for both systems. That requires transformation, and in an XML world that means XPath and XSLT.

In the ideal orchestration scenario, you'd create a connection between the input document and exit point on the bus. Next, you'd define the transformation required by matching data from the input document to the data required in the output document. The XPath expressions required to select the appropriate data from the input document would be generated automatcially, as would the XSL that moves the data from the input to the output document. But that's the ideal world.

Depending on your definition of "code," you might not be all that pleased with IBM's WebSphere Message Broker, Sonic Software's SOA Suite and Software AG's ESI, all of which require manual creation of XSLT or XPath expressions, or both, depending on the situation. All the other products we tested provide some visual method of creating XPath expressions and more often than not automatically generate the XSLT required to map data from one step to another in the orchestration. In fact, mapping data from one step to another generally involves a drag-and-drop paradigm — dragging an input field and dropping it on the desired output field — in which the system generates the appropriate XPath expressions and XSL to select the input data and copy it into the target field.

Using Sonic's product, we had to construct an XPath query and add all the appropriate namespaces to the proper step in the process just to map the "PROD_NO" value from the inbound XML document to the database parameter necessary to execute a lookup on the inventory table. Although the XPath query requirement was common, the addition of namespaces — including the default SOAP namespaces — was frustrating, as was Sonic's solution of cutting-and-pasting the appropriate XPath expression from a tree-based view of the data to complete the mapping process.

IBM's product would generate the XSL for us, but we first had to define message maps between the data using a drag-and-drop paradigm. However, with IBM's solution, message maps are tied to specific messages rather than steps in the orchestration. Although IBM's method provides a more loosely coupled service orchestration, it requires much more up-front work in determining the exact messages that will be required by each step in the process — in effect tightly coupling a message to a step. Any change in the underlying service that might affect the message would require a new transformation, which would mean deploying a new package to the broker.

Fiorano's Mapper was perhaps the most elegant of all mapping solutions and closest to our ideal, providing a completely visual mechanism for defining XPath expressions and including XSL functions to transform data from step to step. Oracle and Cape Clear likewise provide visual methods, but fell short of Fiorano's more thorough and easy-to-use offering. BEA's product was an enigma. Its solution in general was the most abstracted from nitty-gritty details, but its mapping solution still requires a good understanding of XQuery/XPath, something we aren't comfortable requiring of service orchestrators.

Fragile, Not Agile

Services must be registered to be orchestrated. Products use a variety of mechanisms to provide this registration, ranging from embedded UDDI registries (as in the products from BEA, Cape Clear, Fiorano, Oracle and Software AG) to proprietary mechanisms (those from IBM, Sonic Software and TIBCO). Not surprisingly, a number of vendors — including BEA, Fiorano and Oracle — resell the popular Systinet Business Service Registry. IBM doesn't take advantage of a registry at all at design time, except to allow the import of external Web Services. In fact, that was the only way we could find to integrate our external Web service into our orchestration using IBM's product, which made things completing implementation of our scenario quite difficult overall.

Most products that take advantage of a registry during design time also use it effectively at run-time, with the exception of Software AG's product. Constructing a loosely coupled architecture requires the use of the registry at run-time to ensure that the service is up-to-date. Without consulting a registry at run-time, it would be necessary to redeploy all dependent orchestrations if a single service changes. That's not agile, that's fragile, and it's something that must be addressed if enterprises expect to realize the benefits of a true SOA infrastructure.

The Limber Leaders

After months of testing, we put the suites from BEA, Fiorano, Oracle and TIBCO on our ESB shortlist. Although there were some quirks with Fiorano's surrounding the exposure of orchestrated services as Web Services, generally speaking it held its own in impressive company. The products from Oracle and BEA were by far the closest implementations of what we expected to see from an ESB, with TIBCO's needing only a few tweaks here and there to reach the same level of effortless orchestration of services offered by the two software giants.

Lori MacVittie is a Network Computing senior technology editor. She has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].

ESBs Put to the Test

We installed each of the eight enterprise service buses on identical machines and attempted to orchestrate a business service to perform order fulfillment. The scenario was designed to evaluate core ESB capabilities, such as transformation, protocol support, orchestration and content routing. Our deployment choices also let us test the mechanisms provided by each ESB suite for configuring foreign JMS servers, which helped us better understand each underlying architecture.

Where BPEL 1.1 support was offered (very limited in our evaluation), we exported and imported between products to evaluate compatibility. We also examined the integration features available for common needs, such as database and application integration. Products varied widely in this last respect, confirming the current perception that ESB is an emerging technology that has yet to be clearly defined.

We required each ESB to be both a consumer and producer of Web Services, and we used the development of services and inclusion of external services to evaluate integration and use of a registry/ repository. Although our coverage here focuses on service-oriented modeling, mapping and registry integration aspects of ESBs, more technical, IT-oriented detail is offered in Network Computing's March 16 review.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
More Insights
Copyright © 2021 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service