なぜメッセージベースのシステムを使用するのでしょうか?

Question

メッセージベースのシステムを使用する動機は何ですか?

などのサービスバスについてよく見かけます。 Nサービスバス そして 大量輸送 そして、その基礎となる方法論の利点は何なのか疑問に思っています。

Answer 1

メッセージベースのシステムを使用することには複数の利点があります。

1. メッセージは、アプリケーション間で明確に定義されたテクノロジー中立のインターフェイスを形成します。
2. アプリケーションの疎結合を可能にします。
3. パフォーマンス、チューニング、スケーリングのための多くのオプション:
   • リクエスターとサービスプロセスを異なるハードウェアにデプロイする
   • 単一サーバーを共有する複数のリクエスタ
   • 複数のサーバーを共有する複数のリクエスタ
4. さまざまなメッセージング ミドルウェアは、アプリケーションから独立して共通のメッセージング パターンを実装します。
   • リクエスト/返信
   • ファイアアンドフォーゲットオフラインアップデート
   • 発行/購読
5. ミドルウェア製品の多くはメッセージ変換を処理します (例:SWIFT から SWIFTXML)。
6. ミドルウェア製品の多くは、1 つの大きなリクエストを複数の小さなリクエストに分解できます。
7. ほぼすべての製品が複数のプラットフォームをサポートしています。

ちなみに、この分野の市場リーダー 2 社は、Websphere MQ および関連製品を提供する IBM と、Enterprise Service Bus を提供する TIBCO です。

Answer 2

メッセージベースのアーキテクチャは、メッセージのプロデューサーとコンシューマーを時間と空間の両方で分離します。これには多くの利点があります。

• プロデューサーとコンシューマーは異なるマシン上で実行可能
• プロデューサーとコンシューマーは異なる時間に実行できます。
• プロデューサーとコンシューマーは、異なるハードウェア/ソフトウェア プラットフォーム上で実行できます (同じメッセージ プロトコルを理解する必要があるだけです)。
• 複数のプロデューサー/コンシューマーを調整するのは簡単です (例:Dave Markle が説明したように、複数のマシンを必要とする計算集約型のジョブの場合)
• サービスが一時的に利用できない場合の安定性が向上します（例:注文処理を行う場合、メッセージング システムを使用すると、注文の「ドロップ」を回避できます)

RPC スタイルの通信を行うと、これらの利点のほとんどが失われます (つまり、サービスの応答を待っている間にブロックした場合)

Answer 3

あなたが与えられたアイテム上で動作することができ、リソースのプール、そしてスケーラブルな方式で分散させる必要のある作業のリストを持っているときの一つのユースケースがある。

私はかつて私は3270個のスクリーンスクレーパー（すべての遅い）の数と、メインフレームの統合をしなければならなかったのプロジェクトを持っていました。私は一度にボックス上で開いて、これらのプロセスのほとんどで10を持つことができます。 、私はスクリーンスクレイプや更新にアカウントの数千を持っていたので、私はキューに仕事を入れて、私のマシン（私は約3 EMのを持っていた）だけで、メッセージキュー（MSMQ）をオフ作業項目をピックアップし、その画面スクレイピングをしましたそして、それはそれでした。それは良かったので、私は簡単に、新しいマシンをスピンアップ、または作業の流れを中断することなく、古いものを無効化することができます。

Answer 4

メリットは本当にダウンあなたのアプリケーションの部分を切り離すにあります。あなたはバスが設定している、そしてアプリケーションが追加されたら、あなたは簡単にあなたが他の部分に影響を与えないことを保証することができ、新しい作品を追加することによって、あなたのアプリケーションを拡張することができます。継続的に時間をかけてシステムに追加することのその非常に良い方法ます。

など。私たちはちょうど新しい部分を書いて、それをシステムに追加し、我々は新しい機能を追加したり、既存のものを変更したい場合は、このようなシステムは、各コマンドは、全体的なGUIへの一部として実装されています。それが呼び出されると、それは残りの依存関係はありません。それは私たちが非常に簡単に我々のアプリを拡張できることを意味します。また、我々はネットワーク上のノード間を通過するメッセージを持っている - 何かが1台のコンピュータに変更されますとき、彼らは自分自身を更新することができますので、メッセージは他のすべてに送信されます。私たちは、さまざまなイベントのための百の異なるメッセージを持っているので、我々はそれが反応に適切なメッセージに新しいサービスをドロップすることで、システムを拡張することができます。

メッセージパッシングアーキテクチャは、通常、あなたは簡単に新しいものを追加することができ、あなたが呼び出すことができる個別のサービスを持って、Webサービスと同じ機能を持っています。

（！そして高価な）

そのメッセージパッシングアーキテクチャが空想を必要と考えてはいけないミドルウェア製品しかし、Windowsはメッセージパッシングアーキテクチャ上で動作する - ウィンドウに渡されたすべてのWM_ *メッセージは、うまく。メッセージである、と私はと思います建築の最高の例を示している - システムのどの部分が他の部分について知っておく必要はありません、あなたが任意のダイアログ、などなどに好きなようにあなたに多くのコントロールを扱うことができるように無限に拡張することができます。

。

メッセージパッシングは、それがしっかりと一緒にあなたのアプリケーションを結合するよりも遅くなることができますが、それはあなたがすでにスクリプトまたは.NETアプリケーションを使用している場合は特に、今日それを使用しない理由の多くはありません、素晴らしいアーキテクチャです。

Answer 5

メッセージ指向のシステムは、統合問題の特定のクラスのために、一般的に良いです。他の選択肢は、RPCを介して統合と通信するアプリケーションまたはアプリケーションのために（おそらくベースのファイルまたはDB）共有データストアを有するものである。

これらの統合パターン上メッセージングの利点は、同じデータストアスキーマに両方のアプリケーションを結合されていない、あなたはより多くのアプリケーションは、より複雑な取得した（RPC統合シナリオをポイント・ツー・ポイントにアプリケーションを抱き合わせていないことです関与）。

また、非同期通信の利点とメッセージのルーティングおよび変換の可能性（電子メール対オンラインチャットのように）あります。

Answer 6

私は、C# とリモーティングを使用するシステム用の開発を支援しました。クライアント (サービスまたは GUI) は、カスタム データを含むメッセージを送信でき、受信者は、次回の接続時または即座にそれを受信します。その後、メッセージを処理できるようになります (負荷分散サービスの場合はメッセージの所有権を取得することにより)。また、長時間実行されているプロセスが終了したときに GUI を更新するためにも使用されました。

メッセージング システム自体には、各メッセージを処理する構成可能なパイプラインがありました。ここでは、私たちが開発したパイプラインのいくつかの例を示します。

• ストレージ (メッセージを作成/データベースに保存)
• ルーティング (メッセージをどこに送信する必要があるかを決定します)
• セキュリティ (クライアントが受信を許可されている場合に機能します)
• 削除 (メッセージをシステムから削除する必要がある場合に機能します。つまり、クライアントに通知され、メッセージがキャッシュから削除され、DB 内でフラグが付けられる必要があります)。
• TakeOwnership (所有されているメッセージのみを変更できるため、一度に 1 つのクライアントだけがメッセージの状態を変更できるようにする処理)

あなたの質問に答えると、メッセージング システムは、クライアントが誰であるかわからない、または気にしないときに情報を送信する優れた手段です。