この質問に対する回答が見つかりませんでした。そのため、これを開始します。
TibcoEMS対MSMQ対MQ。
これらの3つのテクノロジーはどのように比較されますか？どちらが優れており、どのようなシナリオでですか？具体的には、SOA環境（.NET + WCF）でこれらのいずれかを使用すると思います。この環境では、シナリオは時間の経過とともに成熟します。
パフォーマンスにもう1つ特別な関心がありますが、これは言及することが重要です。したがって、選択肢が与えられた場合、パフォーマンスは非常に優先されます。
わかりやすい比較表をいただければ幸いです。
ありがとう！
編集：
私は、パフォーマンスとスケーラビリティという2つのパラメータに集中しています。 スケーラビリティ-サポートされている同時ユーザー数の観点から、これらのテクノロジーはどのように比較されますか？より多くのユーザーをサポートできるのはどれですか？シナリオは重要ではありません。単純なキューなど、それらすべてでサポートされているシナリオを選択しましょう。 パフォーマンス-まったく同じシナリオで、どちらがより高速に実行されますか？
WCFを使用したい場合は、それらのどれよりも重要です。それらのほとんどは、直接APIを使用する場合にのみ取得されます。
MSMQ-すべてのWindowsインストールでインストールされるMSテクノロジ。これは、キューをサポートするトランスポートテクノロジーのみです。
Tibco EMS-キューとトピックの両方をサポートするTibcoテクノロジー（パブリッシュ/サブスクライブ）。これは高価であり、エンタープライズシナリオにより適しています。完全なSOAソリューション（Tibco ActiveMatrix製品スイート）を実装するには、おそらく他のTibcoツールとテクノロジーも必要になります。.NETとWCFは、Javaの世界向けに設計された、このインフラストラクチャに接続された唯一のアプリになります。Windows以外のプラットフォームでも動作し、Tibco Business Worksとともに、多くのLOBアプリケーションへのコネクタ（アダプタ）を提供します。Tibco製品のAPIは好きですが、ツールのUIは本当に好きではありません。
IBM MQ-キューをサポートするIBMテクノロジーであり、トピックをエミュレートします（パブリッシュ/サブスクライブ）。ここでも、メインフレームが関与するエンタープライズシナリオに適した高価な商用ソリューションであり、これがMQの最大の利点であり、「どこでも」実行されます。しかし、それは利点の終わりです。Javaと.NETの両方のAPIはひどいです。.NET APIにはバグがたくさんあり、期待どおりに機能しません。IBMは、クライアント・アプリケーションを異なるMQクライアントがインストールされているマシンなどに移動するときにひどい問題を引き起こす.NETライブラリーのバージョン管理を理解していません。
編集：
MQの問題についていくつか質問/コメントがありましたか？いくつかの例として、私のMQの質問を確認できます。すべての質問が実際に問題になるわけではありませんが、バグを直接指摘している質問はほとんどありません。これらの問題は、新しいMQクライアントバージョンですでに修正できますが、他に問題がないという意味ではありません。一般的に、MQ .NET APIは、これまで使用した中で最も苛立たしいライブラリであることがわかりました。これは、SharePointを嫌っていました。
一方、メッセージを送受信するだけで、特別なことをしたり、低レベルの機能を使用したりする予定がない場合は、問題ありません。最後に、APIはしばらくの間使用され、一般的なユースケースが機能するはずです-リグレッションバグをヒットするのに十分満足していない場合。
単純な統合シナリオの場合、つまり2つのアプリケーションがポイントツーポイントで相互作用する場合、違いはありません。アプリケーション内の各テクノロジーのサポートを確認することをお勧めします。そして、そのタイプのシナリオでは、メッセージング時間が主な問題であってはならないため、パフォーマンスについて心配する必要はありません。一方、実際の選択は、企業全体を統合するためのターゲットモデルに基づいて行われます。たとえば、-メディエーション機能を実行していますか-たとえば、データ変換、プロトコルマッピングなど-ポイントツーポイント方式でシステムを統合しますか、それともハブ/ ESBの導入を検討しますか？-統合シナリオのセキュリティの側面（承認、認証、監査、暗号化、証明書交換..。など）最後に、そのようなビジョンを持つことで、設計にどのような実際の制約があるかをよりよく理解できるようになります。個人的には、複雑な統合シナリオを期待しておらず、ソリューションにお金をかけたくない場合にのみ、WCFを選択します。そして、SOAの基盤を構築しているのであれば、IBMに行きます。定義されたスコープでJavaベースの統合を計画している場合は、Tibcoに移動します。
繰り返しになりますが、メインフレームが関与するエンタープライズシナリオにより適した高価な商用ソリューションです。
メインフレームについて言及した理由がわかりません。多くのMQエンタープライズのお客様はそれらを持っていません。
IBM MQ-キューをサポートするIBMテクノロジーであり、トピックをエミュレートします（パブリッシュ/サブスクライブ）
MQ v7.0.0（2008年リリース）以降では、ネイティブ機能としてpub / subトピックがサポートされており、エミュレーションは含まれていません。
Javaと.NETの両方のAPIはひどいです。
JavaおよびJMS用のMQクラスは、10年以上にわたって進化しており、何千もの企業で頻繁に使用されています。
.NET APIにはバグがたくさんあり、期待どおりに機能しません。
.Net APIは、MQのいくつかのメジャーリリースで7年以上使用されています。明らかなバグは今までに振り払われていたと思います。
私は、パフォーマンスとスケーラビリティという2つのパラメータに集中しています。
MQには無制限のスケーラビリティがあります。チューニングをしなくてもパフォーマンスはとても良いです。
MQは、多くのメインフレームと統合する必要がある場合にのみ最適です。Pub / Subの実装は不十分であり、多くのAPIは「使用するのが奇妙」です。
すべてのアプリケーションがWindowsの場合、MSMQは良い選択かもしれませんが、UnixまたはJavaの世界にブリッジすることは困難です。
Javaコミュニティ全体がJMSで標準化されているため、Windows以外のアプリケーションに接続する場合は、TIBCOEMSが適しています。