TibcoのEMS対MSMQ対MQ

Question

この質問の答えを見つけることができませんでしたので、これを開始したいと思います：

TibcoのEMS対MSMQ対MQ。

これら3つの技術はどのように比較されますか？ どちらが優れていて、どのようなシナリオがありますか？ 具体的には、シナリオが成熟するSOA環境（.NET + WCF）でこれらのいずれかを使用すると思います。

私はパフォーマンスに特に関心がありますが、それは言及することは重要です。したがって、選択肢があれば、パフォーマンスは非常に重要です。

私は鮮明な画像の比較表を持っていただければ幸いです。

ありがとうございます！

EDIT：パフォーマンスとスケーラビリティ：

Iは、2つのパラメータに集中しています。 スケーラビリティ - これらのテクノロジは、サポートされている同時ユーザー数とどのように比較されますか？より多くのユーザーをサポートできますか？シナリオは重要ではありません。すべてのシナリオでサポートされているシナリオを選択してみましょう。単純なキュー。 パフォーマンス - まったく同じシナリオでは、パフォーマンスは向上しますか？

Answer 1

WCFを使用したいのであれば、本当に重要です。ダイレクトAPIを使用している場合にのみ、それらのほとんどを取得します。

すべてのWindowsインストールでMSMQ - 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はありますか？いくつかの例として、my MQ questionsを確認することができます。すべての質問は実際問題ではありませんが、バグを直接指しているものはほとんどありません。これらの問題は、新しいMQクライアントのバージョンではすでに修正されている可能性がありますが、他のバージョンが存在しないことを意味するわけではありません。一般的に私はMQ .NET APIがこれまでに使用していた中で最も不満なライブラリであることを発見しました。

一方、メッセージを送受信する必要があり、特別な操作や低レベルの機能を使用する予定がない場合は、問題ありません。最後に、APIがしばらく使われています。あなたが回帰バグに遭遇するのに十分満足できるものでなければ、一般的な使用例がうまくいくはずです。

Answer 2

再びそれはメインフレームを使用すると、メインフレームを述べ、なぜわからない

を関与している企業のシナリオ のためのより適切な高価な商用ソリューションです。多くのMQエンタープライズ顧客にはそれらがありません。

IBM MQ - IBM技術はキューをサポートし、それはまた、何とか トピック（パブリッシュ/サブスクライブ）

（2008年発売）

のMQ V7.0.0をエミュレートし、以降のネイティブ機能として、パブ/サブトピックをサポートしていますエミュレーションは必要ありません。

Javaと.NETの両方のAPIはひどいです。

JavaおよびJMSのMQクラスは、10年以上に渡って発展しており、何千もの企業によって頻繁に使用されています。

.NET APIにはバグがあり、期待通りに機能しません。

.Net APIは、いくつかのメジャーリリースのMQより7年以上前からあります。明白なバグが今では揺らいでいたと思います。

パフォーマンスとスケーラビリティという2つのパラメータに集中しています。

MQには無制限のスケーラビリティがあります。チューニングをしなくてもパフォーマンスはとても良いです。

Answer 3

MQは、多くのメインフレームと統合する必要がある場合にのみ最適です。 Pub/Subは実装が不十分で、多くのAPIが「使用するのが奇妙」です。

すべてのアプリケーションがWindowsの場合、MSMQは良い選択かもしれませんが、UnixまたはJavaの世界に橋渡しするのは難しいでしょう。

Javaコミュニティ全体がJMSで標準化されているため、Windows以外のアプリケーションに接続する場合は、TIBCO EMSが適しています。

Answer 4

2つのアプリケーションがポイントツーポイントのやり方で対話する簡単な統合シナリオの場合、違いはありません。アプリケーション内の各テクノロジのサポートを確認することをお勧めします。また、このようなシナリオでは、メッセージングの時間が重要な問題ではないので、パフォーマンスについて心配するべきではありません。一方、実際の選択は、企業全体を統合するためのターゲットモデルに基づいています。例： - データ変換、プロトコルマッピングなどのメディエーション機能を実行していますか？ - ポイントツーポイント方式でシステムを統合するのか、ハブ/ ESBを検討することができますか？ - 統合シナリオ（認証、認証、監査、暗号化、証明書交換など）のセキュリティ面をカバーしますか？など） 最後に、そのようなビジョンを持つことは、あなたの設計にどのような実際の制約があるかをよりよく理解することになります。個人的には、複雑な統合シナリオを期待していない場合にのみ、私はWCFに行きたいと思います。私はソリューションにお金を費やすつもりはありません。私がSOAの基盤を構築しているなら、私はIBMに行くでしょう。定義されたスコープでJavaベースの統合を計画しているなら、Tibcoに行くでしょう。