All Buses Are Not Created Equal
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.
December 18th, 2006 at 1:23 pm
Some comments reg TIBCO
1. Transport
The comment about using a proprietary transport is
incorrect:
TIBCO BusinessWorks can be used with any transport layer
that the product supports (which is quite a few), but is
typically used with JMS. It should be noted that it is
compatible with most JMS servers on the market, but is
(naturally) mostly deployed on TIBCO EMS.
Regarding the “proprietary transport layer”; In addition
to JMS, BusinessWorks also support TIBCO Rendezvous as
the transport layer, which indeed is a proprietary TIBCO
messaging standard (it predates JMS).
2.TIBCO stores all configuration metadata in a repository
in XML.
The comment regarding Oracle is misleading; although they
use BPEL, Oracle relies heavily on extensions to compensate
for functionality not available in standard BPEL. The
resulting configuration data therefore is typically not
portable to any other vendors implementation of a BPEL
server.
3.TIBCO BusinessWorks is a pure J2SE implementation and only
requires a JDK to run (which is shipped with it). It is
certified to run on a number of platforms, including windows,
linux and most major unix platforms.
6.TIBCO uses an internally developed XML parser to provide
superior speed.
December 18th, 2006 at 1:23 pm
re: point 2
BPEL is fast becoming ORacle’s format. I agree we are sick of Oracle, their proprietary tendencies may not show int his case but I’ve got stories to tell you about Oracle’s indiduous practices …