WebSphere Message Broker myths dispelled

Written by Chintan Rajyaguru

Wednesday, 13 May 2009 02:59

WebSphere Message Broker (or message broker for short) enjoys a second class citizen status to many developers and architects - specially those that come from WebSphere Application Server and/or J2EE background. It took me a long time, many discussions and bunch of stressful and often heated debates to convince one of my clients that the message broker is and can be used as an ESB and it will work just fine with WebSphere Process Server. If I had failed, they would have used WebSphere ESB for all interactions with process server and message broker for everything else, essentially resulting in 2 ESBs and potentially defeating the purpose of the ESB. And this is not the only time I have seen this.

What amazes me is not the fact that people don't like message broker. It's the reasons they give for not wanting to use it. In the rest of this blog entry, I am going to list those reasons, which are really myths, and dispel them.

Message broker has poor support for web service standards. WebSphere ESB has better support. If you are focused on standards based interactions using XML, SOAP and WS* then go with WebSphere ESB.

This is not true. Message broker supports web services standards as well as if not better than WebSphere ESB:

It has support for web services standards including Basic Profile 1.1, see this link.
In WS-* standards, it has support for WS-Addressing, see, http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac64300_.htm and WS-Security, see, http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac55630_.htm
On vanilla web services, message broker actually supports more SOAP processing nodes than WebSphere ESB. Broker soap nodes are listed at: http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ab00026_.ht
Message broker even supports SOAP/MTOM and integration with a registry such as WSRR
It has out of the box functionality to generate schema based messages from WSDL, which WebSphere ESB doesn’t
It even allows you to make any text based message a SOAP message, get SOAP envelop in or out, get SOAP body out and so on – WebSphere ESB supports this but it doesn't have this capability provided out of the box in the development tool (integration developer
It provides a lot of XML functionalities including XSLT that WebSphere ESB provides. See this link to get a high level idea http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac67160_.htm

Message broker requires you to use proprietary things like ESQL. So code developed in message broker code becomes proprietary. WebSphere ESB is based on J2EE and SCA (Service Component Architecture) those are both standards. Mediations developed for WebSphere ESB could be ported to another standard platform in the future

Again, this is not true.

You can use ESQL or Java in message broker. While ESQL is proprietary, Java is an open standard
While SCA is a standard and some vendors are implementing it, portability across containers is still a dream. Plus, not every vendor wraps mediations in an SCA component. Also, packaging of SCA components (in jar and ear files) appears to be specific to WebSphere ESB and process server. In some cases, you have to extend a com.ibm class or use a com.ibm class behind the scene (e.g. binding classes). The point isn't that SCA is bad. The point is, although SCA is a standard, use of SCA in WebSphere ESB doesn't make ESB code portable

If you have J2EE developer adoption of WebSphere ESB is easier than message broker.

This argument does hold some water. WebSphere ESB is built on top of WebSphere Application Server. It uses ear and jar as deployment artifacts, it uses EJB and Web projects behind the scene. However, you should keep in mind that there is a learning curve involved in using WebSphere ESB as well. I would agree that the learning curve for a J2EE developer on message broker would be steeper.

The point of this blog entry is not to say that message broker is better than WebSphere ESB. Nor that the message broker should be chosen over ESB. The intent is to dispel some myths so it is not discarded for wrong reasons.

Over to you

Do you use an ESB? Do you use a product or implement it as a pattern? Many companies have both WebSphere Message Broker and WebSphere ESB. If you work for one of those companies, how do you decide when to use which? Let me know in the comments below.

Comments

Add New