- IBM's ESB product is WebSphere Message Broker (not completely true - it is our high-end, advanced ESB product)
- IBM says an ESB should be based on open standards
- WMB is based on "MQSeries" (a name we stopped using for the product about four years ago, but I'll let that pass), so can't claim to be based on open standards
- the implication being that IBM is hypocritical.
Funnily enough, while Broker does prereq WebSphere MQ, the last two customers I've worked with have had no interest in using MQ itself. Recently I used the TCP/IP nodes with version 5 of the product.
Even more recently, I've used the new JavaCompute node in version 6 to make an IP connection to a proprietary backend system. This system accepts XML over an IP socket. I wrapped the backend with message flows to provide a service interface that could be called either with SOAP over HTTP, or using XML over JMS. We chose to use JMS instead of HTTP for scalability purposes - as it happens, we can scale Message Broker extremely effectively using MQ clustering. Customers are often not particularly interested in this aspect of the system, but we are using JMS as a standard messaging API and the fact that MQ is underneath it is fairly circumstantial.
Much more interesting is the article that Richard B accidentally linked from his blog entry the first time he posted it - this article in CCR2 journal - which talks about the flexibility of Message Broker. I'm excited about WebSphere ESB, but I'm very proud of Message Broker - this comment from the article is spot on:
As an advanced ESB, IBM WebSphere Message Broker provides message transformation and universal connectivity, whether applications comply with standards or not. In addition, WebSphere Message Broker maximizes scalability and throughput. Often, WebSphere ESB works well in individual lines of business while WebSphere Message Broker mediates centrally, near mainframe applications and data.