WebSphere Message Broker reviewed

Thanks to Google News Alerts, I found a very interesting article about WebSphere Message Broker (the review is at Network Computing, but I came across it via the Messaging Pipeline, a site I'd not been aware of before). It is particularly interesting because it is a review, and I don't think I've ever read a review of WMB before. The article is mostly positive, which is great. It also provides a few comparisons with aspects of competitive products, and I'm always grateful for the insight.

I'd like to make it clear that I am not an official spokesperson for the product, but as a consultant I have been using Broker in customer situations for over five years now. There are a couple of points in the article that I think are worth picking up:

• We rebranded MQSeries as part of the WebSphere family (WebSphere MQ) a few years ago - I think it is always worth getting this right.


• The article doesn't explicitly explain what the simple scenario that was being built actually did, so I can't really respond to the charge that a significant "depth and breath of knoweldge" was needed to build it.


• Message Broker's ability not to have to use XML for data parsing and transformation is, indeed, one of its greatest strengths. Not only that, it is worth adding that the broker uses just in time and partial parsing technology, which can significantly improve performance. What this means is that (unless otherwise configured) when a message arrives at a message flow, it is only parsed the first time that you address a field inside it. When that happens, the message is parsed to the point at which that field exists in the message, and no further. Of course, if you want to, you could tell the broker to parse and fully validate every field in the message before processing it in the flow - but you don't have to. Partial parsing is great for performance. Say you were routing a message on the contents of an XML element that existed in the first, say, 50 bytes of the message - you could do that without having to parse the whole ~200Kb document.


• The broker has a number of methods of transforming data - Java, XSLT, ESQL and drag-and-drop graphical mapping. The author of the article appears to refer to building a mapping, and having that generate the XSLT required. The article also suggests that there is no tooling for building an XSLT visually. Actually, our Rational tooling (on which the Broker toolkit is based) does provide exactly this function, and it sounds like the author used it... so I'm a bit confused here. As well as a graphical XSLT editor, the Eclipse editors provided with the Broker provide everything you'd expect for editing XSLT, like syntax colouring and context assist. It is possible that the XML development capabilities were not enabled, but it is a simple matter of switching them on via the toolkit preferences.


• The article mentions that in order to access a database for a simple lookup, ESQL or Java coding is required. In fact, the broker has a number of database nodes. These use the mapping technology to provide a drag-and-drop interface to database tables. You can even discover a schema from a datasource using the Data perspective in the IDE, import the table definition, and work directly with it in the database nodes. So, you could build a database lookup without using either Java or ESQL.

Overall, I enjoyed reading this review. There's much more about WebSphere Message Broker - IBM's Advanced ESB - over on IBM developerWorks.

I'll leave the inimitable Richard Brown to pipe up on the true meaning of orchestration, he seems to have things to say on the matter...

Technorati tags: IBM WebSphere MQ message broker ESB XML ESQL XSLT Rational