Tibco EMS vs. MSMQ vs. MQ

Question

Could not find an answer on this question, so would like to initiate this:

Tibco EMS vs. MSMQ vs. MQ.

How do these 3 technologies compare? Which one is better and in which kinds of scenarios? Specifically, I think to use one of these in SOA environment (.NET + WCF), where the scenario will mature over time.

I have one additional specific interest in the performance, which is important to mention. So, if given a choice, performance is of a critical priority.

I would appreciate to have a comparison table for a clear picture.

Thanks!

EDIT:

I am concentrated on two parameters: performance and scalability. Scalability - how do these technologies compare in terms of supported concurrent users' count? which can support more users? scenario does not matter, let's choose the scenario which is supported by all them - e.g. simple queues. Performance - in exactly the same scenarios, which performs faster?

Solution 1

If you want to use WCF than non of them really matters. You will get most of them only when you use their direct API.

MSMQ - MS technology installed with every Windows installation. It is only transport technology with support for queues.

Tibco EMS - Tibco technology supporting both queues and topics (publish/subscribe). It is expensive and more suitable for enterprise scenarios. You will most probably need other Tibco tools and technologies as well to implement full SOA solution (Tibco ActiveMatrix product suite). .NET and WCF will be only apps connected to this infrastructure which is more designed for Java world. It runs on non Windows platforms as well and together with Tibco Business Works it offers connectors (adapters) to many LOB applications. I like APIs for Tibco products but I really don't like UIs of their tools.

IBM MQ - IBM technology supporting queues and it also somehow emulates topics (publish/subscribe). Again it is expensive commercial solution more suitable for enterprise scenarios where mainframes are involved - that is biggest MQ advantage - it runs "everywhere". But that is end of advantages. APIs for both Java and .NET are terrible. .NET API is full of bugs and it doesn't work as expected. IBM doesn't understand .NET libraries versioning which leads to terrible problems when moving your client application to machines with different MQ clients installed, etc.

Edit:

There were several question / comments about what problems MQ has? As few examples you can check my MQ questions. Not every question is actually an issue but you will find few of them pointing directly to bugs. Those issues can already be fixed in new MQ client versions but that doesn't mean there are no other. Generally I found MQ .NET API the most frustrating library I have ever used - it even beaten hated SharePoint.

On the other hand if you just need to send and receive some message and don't plan to do anything special or use low level features you should be OK. At the end the API is used for a while and common use cases should work - if you are not happy enough to hit regression bugs.

Solution 2

For a simple integration scenario - i.e. 2 applications interacting in a Point to point manner , no difference will be there. You would better check the support of each technology within your applications. And in that type of scenarios, you shouldn't be worried about performance as the messaging time shouldn't be the main issue. On the other hand, the real selection would be based on the target model for integrating your whole enterprise. For example, - Are you doing any mediation functions - e.g: data transformation, protocol mapping ...etc - Will you integrate systems in a point to point manner or you may consider having a Hub / ESB? - Will you cover security aspects in your integration scenario (Authorization, authentication, auditing, encryption, certificate exchange ...etc) Finally having such vision will give better understanding of what real constraints you've for your design. Personally, I would go for WCF only if I'm not expecting complex integration scenarios and I'm not willing to spend money on the solution. And I would go for IBM if I'm building a foundation for SOA. And will go to Tibco if I'm planning a Java based integration with a defined scope.

Comments

[Admin]

Thanks Ladislav, interesting answer. I would like to mention that the solution will be implemented in the enterprise world. Also, the company already owns EMS license, thus I just need to have a clear choice of "what" to choose and "why" to use it. Not very clearly understand the performance and scalability differences though.

[Ladislav Mrnka]

If you have EMS license there is no need to think about IBM solutions. Use EMS and use it directly through Tibco.EMS.dll library. There is WCF binding for EMS but that library is easier to use.

[Admin]

What about EMS vs MSMQ then? is EMS better anyway in such a case?

[Ladislav Mrnka]

Do you want to build only .NET to .NET / WinAPI solution or do you need enterprise level integration with Java world or perhaps with some mainframes? MSMQ is MS only technology. That selection strongly depends on your app. requirements and on IT culture / policy in your company. Introducing new technology (MSMQ) when similar (EMS) is already used in corporation is usually not welcome.

[Admin]

Well, this is .net technology oriented environment. However, the company uses both MSMQ and EMS for different solutions. In this case, I need to achieve maximum scalability and performance, and this is the only means of choice, not a technology. So, in terms of a scalability, how is MSMQ suited for numbers of concurrent users and the same for EMS? that's what is missing from my understandig. The same for performance - which can be faster for the exactly same scenarios?

[John Breakwell]

MSMQ: blogs.msdn.com/b/johnbreakwell/archive/2008/02/29/… blogs.msdn.com/b/johnbreakwell/archive/2006/09/18/…

[Ladislav Mrnka]

Looks like you are working for IBM... It doesn't matter how long API was evolved. It is simply not Java or .NET API but just rewritten C code and team responsible for .NET API development has indirectly confirmed this to me, they also confirmed several regression (or perhaps completely untested) buggy features in .NET API. It's also true that almost every .NET / Java developer I met counts IBM APIs and some servers as well as something they don't want to use again.

[Dave Ziegler]

"Pub/Sub is implemented poorly and the many APIs are 'strange to use'." Can you expand upon this comment, please?

[raffian]

@LadislavMrnka Does WebSphere MQ still have issues with .net client libraries?

[Ladislav Mrnka]

@raffian: I don't know. I didn't use them for almost an year but MQ libraries in general used to have quite poor quality.

[Ladislav Mrnka]

@raffian: I edited my answer and added linked some examples of issues I previously had.

[Axel Podehl]

Well, in TIBCO EMS, Pub/Sub was there from the beginning. But in WebSphere MQ, pub/sub is implemented on top of queueing. So the base architecture are queues, not topics. That means you have extra reads and writes that are not necessary with EMS.