Four ESBs That Won't Cramp Your StyleFour ESBs That Won't Cramp Your Style

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].