IBM WebSphere Message Broker 6.0

ESB Suites In November we began our quest to find the ultimate ESB (enterprise service bus) suite by issuing an invitation to a dozen vendors. Eight took us up on our challenge and sent software to our Green Bay, Wis., business applications lab, home of our fictional widget maker, NWC Inc. Over the ensuing weeks, we posted regular updates from Lori MacVittie in NWC's Real-World Labs. We also made available our vendor invites, test plan and other materials from the testing process. Next week rolled out the individual product evaluations from our ESB vendor participants, including BEA, Cape Clear, Fiorano, IBM, Oracle, Sonic Software, Software AG and TIBCO. Now, see the final results as we reveal our Editor's Choice winner and post our market analysis and Interactive Report Card so you can build your own ESB shortlist.

IBM spent several years claiming enterprises didn't need an ESB, and then appeared on the scene with not one, but two, ESB products. IBM sent us the more flexible of its offerings, WebSphere Message Broker 6.0. The other IBM offering, WebSphere ESB, sounds more like BEA's AquaLogic, with a stronger focus on Web services orchestration and less on support for integration of conventional legacy protocols and data formats.

ebSphere Message Broker 6.0 is a C/C++ OS-native application that takes advantage of IBM's MQ Series messaging middleware. Each Broker requires an underlying MQ instance, which is used for management and deployment. WebSphere Message Broker takes advantage of MQ as the underlying mechanism for most management functions, including the deployment of orchestrated services from its Eclipse-based WebSphere Message Broker Toolkit.

We found little management is required for MQ, as it isn't needed for service orchestration. The deployment of the archive files containing service orchestrations, accomplished over MQ, was more reliable than the WebDAV- and Web-services-based deployment mechanisms of Software AG and Cape Clear, respectively.

WebSphere Message Broker persists the metadata describing the orchestration in a local database, Cloudscape or DB2 by default, but can be configured to use any number of supported RDBMSs, including Oracle and SQL Server. The configuration is read when the broker starts or when the configuration changes; while the broker is running, the configuration is cached in memory.