Hello,
What is the difference between the webMethods broker and typical messaging software such as MQSeries/Websphere MQ. Can the wM broker replace MOM or are they supposed to work in conjunction. any thoughts or ideas would be very useful.
Thanks,
Munna
Munna,
Yes the webMethods Broker is considered a “MOM” product. It is similar in functionality to WebSphere MQ. They do not work in conjunction. The Websphere MQ product is in pretty widespread use by itself as a standalone component. The webMethods Broker is typically used as part of the Integration Stack from webMethods which would include its Integration Server and associated adapters. IBM also has the additional stack(s) which sit on top of MQ.
The more advanced integration layer handles data enrichment, transformation, source and target connectivity via adapters etc. At this layer webMethods can interact with MQ via an MQ adapter that webMethods provides or via a JMS adapter that webMethods provides.
If you just need simple messaging then MQ does a very good job. If you need anything more than that I would highly recommend webMethods. Although IBM has the rest of the stack, it is not very well integrated and very difficult to use. All of the EAI vendors have built out their product line through acquisition of other vendors products. Some have been more successful than others with integrated those various products and presenting an unified integration suite. webMethods has made great strides in this area while in my opinion IBM is still struggling.
The Java Message Service (JMS) standard is a part of the J2EE spec that specifies how applications can exchange messages in either point-to-point fashion using JMS queues or in a publish/subscribe model using “topics”.
webMethods Broker has supported JMS since 2001, but the 6.5 version reportedly really cranks up the speed and adds some nice features such as message priorities.
There are many JMS providers, but only a few of them are truly enterprise-class in terms of scalability and reliability. Broker JMS is one of those.
I personally have worked with the Java API’s for MQSeries, Broker (native) and Broker JMS and find the native Broker Java API to be /b{much} easier to understand and to work with than either MQ or JMS.
Another major differentiator is that IMHO it takes a lot more up front administration to configure MQ than it does for Broker. With the greater queue visibility that is added into Broker Admin 6.5 you get both easier setup for Broker and the ability to look inside the “queues” that get created under the covers when you setup a Broker client group and client.
HTH,
Mark
Thank you all. Your thoughts on the MOM capabilities of wM have been truly enlightening. One of the things that I found confusing when comparing MQ and wM is that for configuring the former, MQ components need to be installed both on client and server machines, not so the case with wM Broker. I may be wrong here but I think, separation of client and server components in MQ was required to support message transparency from network protocols and different character set representations that may be used by client and server. Does wM provide platform independent messaging like MQ? For example, if a Windows machine (using ASCII char set) were to publish a document to the Broker, will a mainframe subscriber ( using EBCDIC char set) automatically subscribe to it without a wM Mainframe adapter explicitly having to do the translation between two char sets?
thanks,
Munna
Munna,
Each Broker Client only needs a client API to connect to a Broker on another server. The Broker itself must be installed and configured on a server accessible to the clients that need to communicate with it.
Broker client and Broker Admin client API’s are available in Java, C/C++ and ActiveX for a wide variety of hardware and OS combinations. The list of supported platforms can be found in the Broker 6.x documentation available on Advantage in the Bookshelf section.
Mark