Darren Wesemann Blog

The ESB’s reviewed by the customer were the following products: BEA AquaLogic, IBM Websphere Message Broker, oracle SOA Suite, Sonic Software SOA Suite and TIBCO Software BusinessWorks. The following are some of the notes I took as the customer described their findings, with emphasis on the differences between the ESB’s:

1. Transport: The BEA product is the only one that exclusively used JMS as the actual native bus transport, while IBM’s product allows for the user to define the transport, and multiple are available. Oracle is the only one that used HTTP as the bus transport, although it apparently uses in-memory transfer when it’s run in the same HTTP container. The rest (Sonic and TIBCO) use a proprietary transport layer native to their product.

2. Meta Data: The Oracle product is the only one that uses BPEL as it’s metadata layer for service orchestration, while the rest use other formats, most proprietary to their product.

3. Platform Flexibility: The Sonic and BEA products cannot be deployed on enterprise service platforms other than the ones they ship with, although Sonic requires only a JDK to run, IBM’s JDK 1.4. BEA’s product installs into a WebLogic Server container. Oracle’s product can install on several J2EE containers. I don’t remember what this customer uncovered as far as what platforms they were able to install TIBCO on, so if anyone has specific experience there, please feel free to comment on this blog entry.

4. Web Services Support: TIBCO’s web service container is Axis (with Tomcat), and it was very apparent to this customer that web services support was a separate service to the ESB. The other products they evaluated apparently had tighter integration with web services, and they didn’t appear as external. Sonic’s web services support was challenging for this customer because each web service needs to be configured with JMS endpoints and exist points, which are configured within a proprietary management console, which sets properties on steps within a service orchestration. Seams the two paradigms (JMS and Web Services) don’t really fit well within the Sonic ESB, according to the experience of this customer.

5. Protocols: All of the buses appeared to support HTTP and JMS, with a myriad of others supported, but not all the same ones. I didn’t write down the list, sorry. With all buses, some code had to be written with some protocols and databases accessed before the orchestration tool would be able to utilize them in a process. The main comment regarding protocols and connectors was that all products were very different.

6. XML: The BEA and TIBCO appeared to have their own XML parsers, while IBM uses XML4C, and Xerces is used by both Oracle and Sonic.

7. Visual tools: The customer indicated they liked the Oracle visual capabilities the best. They weren’t all that happy that BEA’s interface required XQuery/XPath knowledge during service orchestration. Although most appeared to rely on XPath, the details are hidden, making the orchestration a bit simpler. IBM’s tool requires schemas to be imported and message maps to be defined, although visually. Sonic’s UI requires XPath’s to be written from scratch.

8. Process Management: The customer was most pleased with BEA’s and TIBCO’s capabilities as it related to process management, debugging, and all aspects related to the runtime environment.

The main takeaway I got from the information this customer shared was just how different the ESB options are. Also, that most differences aren’t necessarily good vs. bad, but instead may appeal to one enterprise over another due to simply a better matching to the environment. Because SunGard is an application vendor, (and applications run on infrastructure chosen by our customers), the need for agnosticism from most platform components is clear. Our customers make platform decisions due to the various particulars of their environments, and we need to run applications (or composite solutions) on any combination of plumbing choices.