Tibco EMS vs. MSMQ vs. MQ [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 6 years ago.

Improve this 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?

Answer 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.

Answer 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.

Answer 3

Again it is expensive commercial solution more suitable for enterprise scenarios where mainframes are involved

Not sure why you mentioned mainframes. Many MQ enterprise customers don't have them.

IBM MQ - IBM technology supporting queues and it also somehow emulates topics (publish/subscribe)

MQ v7.0.0 (released 2008) and onwards supports pub/sub topics as a native feature, there is no emulation involved.

APIs for both Java and .NET are terrible.

The MQ Classes for Java and JMS have evolved over 10+ years and are used heavily by thousands of enterprises.

.NET API is full of bugs and it doesn't work as expected.

The .Net API has been around for 7+ years over a few major releases of MQ. I would imagine that the obvious bugs would have been shaken out by now.

I am concentrated on two parameters: performance and scalability.

MQ has unlimited scalability. Performance is very good even with no tuning.

Answer 4

MQ is best only if you need to integrate with lots of mainframes. Pub/Sub is implemented poorly and the many APIs are 'strange to use'.

If all your applications are Windows, MSMQ might be a good choice, but it will be difficult to bridge into Unix or Java worlds.

The whole Java community standardized on JMS so TIBCO EMS is a good choice if you ever want to connect non-Windows applications.