EIP / Message Store

MessageStore? †

一言要約 †

Message Historyで特徴を述べたが、疎結合のアーキテクトの原理がソリューションの中に柔軟さを持たせるが、統合ソリューションの動的なふるまいに理解を深めるのが難しくなる。

Problem †

どうやって疎結合にメッセージングシステムの一時的な機能を邪魔することなく、メッセージ情報に対してレポートさせることができるか？

詳細 †

メッセージングを強力にする多くのプロパティはもまた、扱うのを難しくすることができる。 非同期メッセージングは配信を保証するが、メッセージが配信されるであろとき保証されない。 多くの実践的なアプリケーションにとって、システムのレスポンスタイムはクリティカルになるかもしれない。また、非同期メッセージングを個々にそれぞれのメッセージを扱う一方、複数のメッセージにまたがる情報は、（例えば、ある時間の間隔内でシステムを通過するメッセージの数）とてもやくに立たせることができる。

Message Historyパターンは、 メッセージの"ソース”を教えることができる便利さを解説する。 このデータから、興味のあるメッセージスループットや実行時間の統計を取り出すことができる。 ただ欠点は、情報、それぞれの個々のメッセージの中に含まれていることだ。 多くのメッセージにまたがって広がるため、この情報をに対して報告する簡単な方法はない。 またメッセージのライフタイムもとても短くできる。 一度メッセージは消費されると、Message Historyはもう利用できなくなるだろう。 意味のあるレポートするために、メッセージデータを永続的に、中央の場所に、保存する必要がある。

Messege Storeを利用するとき、メッセージングのインフラの非同期の性質のメリットがある。 メッセージをチャンネルに送る時、メッセージの複製を、MessageStore?によって集めるための特別なチャンネルに送る。 これは、コンポーネント自身によって行うことができし、また、Wire Tap をチャンネルに登録することができる。 Control Bus の一部として、メッセージのコピーを運ぶセカンダリのチャンネルを 考えることができます。 'fire-and-forget'モードによって、第２のメッセージを送信することは、メインアプリケーションのメッセージの流れを遅くしないだろう。 しかしながら、ネットワークトラフィックが増える。 これにより完全なメッセージを保存できないかもしれない。 だが、メッセージIDや、メッセージがタイムスタンプと結合されて送られるチャンネルのように、後の分析でいくつかのキーフィールドは、必要とされる。

どれくらい詳細に保存するかは、実際に重要な検討事項である。

反発力は、ネットワークトラフィックとMessageStore?の ストレージのキャパシティである。 たとえ、全てのメッセージデータを保存しても、レポーティング能力は、未だに限定的になっているかもしれない。 メッセージは、典型的に、同じメッセージのヘッダー構造を共有する。 だが、メッセージの本文は、各メッセージの種類によって、異なっている構造になっており、外のアプリケーションによって、アクセスることが難しくなる。(例えば、メッセージの本文は、シリアライズ化されたJavaObject?を含んでいるかもしれない。) これは、メッセージの本文に含まれたデータ要素に対して、レポートすることを難しくする。

メッセージの本文の中にあるデータは、各メッセージの種類によって、異なったフォーマット化をすることができるため、異なるストレージオプションで検討する必要がある。もし各メッセージの種類の内部データ構造とマッチさせるために分けられたストレージスキーマを生成すると、メッセージ内容にインデックスを適用して複雑な検索を行うことができる。

Message Store はとても大きくなるかもしれない。パージするメカニズムを導入する必要がでてくるだろう。このメカニズムは、より古いメッセージログをデータベースにバックアップするために移動させ同時にそれらを消す。

例：商用のEAI Tools †

担当者のつぶやき †

みんなの突っ込み †