About a year ago, I wrote about how to think about a monitoring solution in the SOA/BPM world . The focus was on the holistic thought process for an enterprise wide monitoring strategy. My experience at the time was (and still is) that IT often doesn't understand the difference between reporting and monitoring. A monitoring solution often gets picked just because it sounds like a cool new technology (not to mention it makes the resume attractive) and business likes to idea of having pretty looking dials, charts and graphs.

Monitoring and reporting are two different concepts. A business solution may utilize both to satisfy the business requirements. Keep in mind the following differences between them when picking one versus the other:

• Reporting is a data driven solution, which shows information about the business. This makes the report a snapshot of some business information at a given point in time. On the other hand, a monitoring solution is an event based solution, which shows what is happening during business execution. This makes monitoring solution a 'view' into the business. The view is not a time based snapshot. It tells you what is happening now
• A report largely shows historical data. It's the information after the fact whereas a monitoring solution can show current information, historical information and even trends
• A report tends to be static. There are solutions where business users can generate ad-hoc reports. However, these ad-hoc reports merely given enhanced filtering or query capabilities on the business data. Monitoring, on the other hand, is much more dynamic. It allows insight into the business from different perspectives. Depending on the solution used, it can even allow the business to reshuffle things and dynamically change business process to respond to the monitored events. For example, a monitoring solution can keep an eye on the number of claims arriving in a particular processing center. If the number goes beyond certain threshold the business can route new claims to a different processing center on the fly
• The only source of information for reports is database. In case of monitoring, the information being monitored does come from the database from technical perspective but the source of that information could be an event generated by anything: a business object, a system, an application or even an entity external to the organization

Now that we know the difference between reporting and monitoring, next time we will look at an example requirement and decide whether reporting or monitoring makes the most sense.

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.

The world was a happy place when ESB was a pattern. We implemented the bus pattern using a combination of tools and technologies. Now, ESB is a product. And, if you are using IBM products, you have two of them: WebSphere Message Broker and WebSphere ESB.

Here is how webster.com defines 'bus': (1) a set of parallel conductors in a computer system that forms a main transmission path (2) a spacecraft or missile that carries one or more detachable devices (as warheads). Extending the thought to enterprise architecture, it is easy to infer that the bus should be used as the transmission path or as a carrier (typically of a message) to integrate separate systems. However, since we have ESB as a product, people throw it in anytime two systems or even two services have to talk. Here are some inappropriate uses of an ESB product:

• Exposing a service using an ESB because the method signature in the EJB is not web service compatible
• Using ESB because there is a need to send a copybook, a proprietary XML or any other message format and you don't want your application to be tightly coupled to that format
• Using ESB between different layers of the application
• Using ESB because some architect decided to use canonical message format

I am not saying having ESB as a product is a bad idea but just because we have a product, we often fail to analyze the architectural need for an ESB. This leads to product first and architecture second approach, which is a bad idea. This is specially important for an ESB because it usually ends up being a central piece to which everything is connected. A bad ESB architecture will negatively impact everything that is connected to it.

In my opinion, when you have identified the need for a bus, it is often helpful to think what kind of bus you need.

• Do you need to expose business services through the bus? You need a service bus
• Do you need to send and receive messages, and in the process, need to validate, route or transform them? You need a messaging bus
• Do you have too many applications talking to one another directly resulting in an integration spaghetti? You need an integration bus
• Do you have too many sources of data in different shape, form and structure? Do you have large amounts of data moving between places but you need to improve the quality of the data before it can be delivered to the target? You need a data bus. Although the data bus is not a widely recognized concept, as an architect who comes from the middleware background, it helps me to think in terms of data bus so I can recommend a data integration solution as opposed to building services that simply move data around

Once you know what kind of bus you need, you can identify the technology that supports the bus and once the technology is known, you can select the product. This approach will lead to a more appropriate selection of the product that implements the bus pattern. There is an excellent redbook, which addresses this topic. It explains how the bus can be implemented as a pattern using different products. I can't find it anymore on ibm.com/redbooks.

I can see why it is assumed that the WebSphere Business Modeler (WBModeler) is a tool for the business users. I can also see why it has to be available on windows platform. What bothers me though is that the tool is not available on Linux or any other platform for that matter. Do technical people or anybody using Linux not need the tool? Well, I certainly did and I didn't want to install windows on vmware just so I can use WBModeler. Neither do I have access to a windows machine to remote desktop into it.

I refused to accept the limitation. So, first I tried to launch installation using launchpad.sh script, which failed right away. Next, I tried to understand what launchpad.bat was doing and followed its steps but that didn't work either. Then I thought, "At the end of the day, WBModeler is just eclipse with some plugins. If I can install it as eclipse, may be I can use it on Linux." So, I decided to use IBM installation manager and make WBModeler a repository from where the installation manager could access the files. I set an eclipse repository in the installation manager by pointing it to the diskTag.inf file in the installation image. As soon as I clicked Install, Bingo! The installation manager recognized that WBModeler Advanced version was available for installation. I installed it right away on my openSUSE 11.1.

But the joy didn't last long. I launched the tool and specified the workspace directory but didn't see all the options in the menu. There were blank spaces in the File > New menu. When I found and launched business modeling project, I got errors that suggested various osgi and eclipse classes were not found. I did some debugging but soon realized that the task of running WBModeler on Linux might be more complex than I originally thought. For now, I have accepted the defeat, uninstalled the tool and hoping and praying that some day it will be available on the Linux platform. If someone has done this successfully, please feel free to drop me a line. In the mean time, I don't expect IBM to make the tool work on Linux. It takes customers not developers for something like this to happen.