Test driving ESBs: the winners are...

The folks at Intelligent Enterprise and Network Computing recently took test drives on eight brands of enterprise service buses, and came away generally satisfied with the performance of half of them.

Lori MacVittie writes that the team at Network Computing's 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. Microsoft, PolarLake, Sun Microsystems and WebMethods declined to participate, and Iona's Artix 4 wasn't released until after testing was completed.

Evaluation of the ESBs was based on "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," MacVittie said. "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." Each ESB was required to be both a consumer and producer of Web services.

And the winners are...

Gimme that envelope.

BEA AquaLogic Service Bus; Fiorano SOA 2006 Platform; Oracle SOA Suite; and TIBCO BusinessWorks 5.3.

Two best of breeds, and two infrastructure giants. A very representative mix.

What made these ESBs so special? The main things evaluators looked for was the ability to hide complexity under the covers. BEA AquaLogic, for example, provided autoxposure that eliminates WSDL effort, and "code-free browser-based operation."

Oracle also had autoexposure features that eliminates WSDL effort, and also visual mapping. Visual mapping was also the strength associated with Fiorano. TIBCO provides "effortless orchestration with minor tweaks." 

The main weaknesses of these lucky ESBs ranged from requirements for XQuery/XPath know-how (BEA), to "registry functionality not well integrated." (Oracle).

Now, there are plenty of voices in the industry that question why we should have ESBs at all.  But if you are looking to move to SOA on the ESB model, the ideal platform should offer agility, not fragility, MacVittie points out.

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

A solid ESB implementation should only require knowledge of SOA-based languages and technologies, not the messaging technology underneath. Plus, "you shouldn't need to know about the inner workings of the messaging bus to orchestrate messages," said MacVittie. "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."