メッセージベースのパッシングシステムの場合、「メッセージデザインパターン」は何ですか。
ダイレクトメッセージを制限する（つまり、特定の宛先）
長いカスケードチェーンは避けてください（つまり、MsgAにMsgB、MsgCなどで反応します）
システムに「ハートビート」メッセージを表示する
他の例？
20843 次
5 に答える
10
メッセージベースのシステムを実装している場合は、標準的なリソースを読んで、メッセージングアーキテクチャに関する洞察を得ることをお勧めします。エンタープライズ統合パターン： Gregor Hohpe y Bobby Woolfによるメッセージングソリューションの設計、構築、および展開。
各パターンの簡単な要約は、http：//www.eaipatterns.com/toc.htmlでオンラインで 入手できます。ページの最後に、2つのケーススタディがあります。
この本は素晴らしいリソースであり、それを解決するための戦略の優れた分析とともに、これまで想像もしていなかった問題や状況を見つけることができます。
于 2009-10-26T13:11:46.993 に答える
8
エンタープライズ統合パターンごとに、著者のGregorHohpeとBobbyWoolfは、次の6つのカテゴリにグループ化された60を超えるメッセージングパターンを文書化しました。
メッセージ構築
メッセージ：メッセージチャネルで接続された2つのアプリケーション間で情報を交換するには、メッセージシステムがメッセージチャネルを介して送信できるデータレコードであるメッセージに情報をパッケージ化します。
コマンドメッセージ：メッセージングを使用して別のアプリケーションでプロシージャを呼び出すには、コマンドメッセージを使用してプロシージャを確実に呼び出します。
ドキュメントメッセージ：メッセージングを使用してアプリケーション間でデータを転送するには、ドキュメントメッセージを使用してデータ構造を確実に転送します。
イベントメッセージ：メッセージングを使用してあるアプリケーションから別のアプリケーションにイベントを送信するには、イベントメッセージを使用して、アプリケーション間の信頼性の高い非同期イベント通知を行います。
要求-応答：アプリケーションがメッセージを送信したときに受信者から応答を取得するには、それぞれ独自のチャネルで要求-応答メッセージのペアを送信します。
差出人住所：返信メッセージの送信先を返信者に通知するには、要求メッセージに差出人住所を含める必要があります。
相関識別子：リクエスターが要求と応答を照合できるようにするには、各応答メッセージに相関識別子が含まれている必要があります。これは、メッセージ応答の対象となる要求を示す一意の識別子です。
メッセージシーケンス：メッセージングを介して任意の量のデータを送信するには、データをチャンクに分割してメッセージシーケンスとして送信し、各メッセージにシーケンス識別フィールドのマークを付けます。
メッセージの有効期限：メッセージが古くなったと見なされて処理されない場合を示すには、メッセージの有効期限を設定して、メッセージの実行可能期間の制限時間を指定します。
フォーマットインジケーター：メッセージのデータフォーマットを設計して、将来の変更を可能にするために、フォーマットインジケーターを含めて、メッセージが使用しているフォーマットを指定できるようにします。
メッセージルーティング
パイプとフィルター：独立性と柔軟性を維持しながらメッセージに対して複雑な処理を実行するには、パイプとフィルターのアーキテクチャスタイルを使用して、大きな処理タスクを、チャネル（パイプ）。
メッセージルーター：個々の処理ステップを分離して、一連の条件に応じてメッセージを異なるフィルターに渡すことができるようにするには、1つのメッセージチャネルからのメッセージを消費して別のメッセージチャネルチャネルに再発行する特別なフィルターであるメッセージルーターを挿入します。一連の条件に応じて。
コンテンツベースのルーター：単一の論理機能（在庫チェックなど）の実装が複数の物理システムに分散している状況を処理するには、コンテンツベースのルーターを使用して、メッセージのコンテンツに基づいて各メッセージを正しい受信者にルーティングします。
メッセージフィルター：コンポーネントが興味のないメッセージを受信しないようにするには、特別な種類のメッセージルーターであるメッセージフィルターを使用して、一連の基準に基づいてチャネルから不要なメッセージを削除します。
ダイナミクスルーター：効率を維持しながら、ルーターがすべての可能な宛先に依存しないようにするには、参加先からの特別な構成メッセージに基づいて自己構成できるルーターであるダイナミックルーターを使用します。
受信者リスト：動的に指定された受信者のリストにメッセージをルーティングするには、各受信者のチャネルを定義します。次に、受信者リストを使用して着信メッセージを検査し、目的の受信者のリストを決定して、リスト内の受信者に関連付けられているすべてのチャネルにメッセージを転送します。
スプリッター：メッセージに複数の要素が含まれている場合にメッセージを処理するには、各要素を異なる方法で処理する必要がある場合があります。スプリッターを使用して、複合メッセージを一連の個別のメッセージに分割します。各要素には、1つのアイテムに関連するデータが含まれます。
アグリゲーター：個々の関連メッセージの結果を組み合わせて全体として処理できるようにするには、ステートフルフィルターであるアグリゲーターを使用して、関連メッセージの完全なセットが受信されるまで個々のメッセージを収集および保存します。次に、アグリゲーターは個々のメッセージから抽出された単一のメッセージを公開します。
リシーケンサー：関連しているがシーケンス外のメッセージのストリームを正しい順序に戻すには、ステートフルフィルターであるリシーケンサーを使用してメッセージを収集および並べ替え、指定された順序で出力チャネルに公開できるようにします。 。
構成されたメッセージプロセッサ：複数の要素で構成されるメッセージを処理するときに全体的なメッセージフローを維持するには、それぞれが異なる処理を必要とする場合があります。構成されたメッセージプロセッサを使用して複合メッセージを処理します。構成されたメッセージプロセッサは、メッセージを分割し、サブメッセージを適切な宛先にルーティングし、応答を1つのメッセージに再集約します。
Scatter-Gather：メッセージを複数の受信者に送信する必要がある場合に全体的なメッセージフローを維持するには、それぞれが応答を送信する可能性があります。複数の受信者にメッセージをブロードキャストし、応答を再集約するScatter-Gatherを使用します。単一のメッセージ。
ルーティングスリップ：ステップのシーケンスが設計時に不明であり、メッセージごとに異なる可能性がある場合に、一連の処理ステップを介してメッセージを連続してルーティングするには、各メッセージにルーティングスリップを添付して、処理ステップのシーケンスを指定します。各コンポーネントを、ルーティングスリップを読み取り、メッセージをリスト内の次のコンポーネントにルーティングする特別なメッセージルーターでラップします。
プロセスマネージャー：必要なステップが設計時に不明であり、連続していない可能性がある場合に複数の処理ステップを介してメッセージをルーティングするには、中央処理装置であるプロセスマネージャーを使用して、シーケンスの状態を維持し、次のステップを決定します中間結果に基づく処理ステップ。
メッセージブローカー：メッセージの宛先を送信者から切り離し、メッセージのフローを一元管理するには、複数の宛先からメッセージを受信し、正しい宛先を決定し、メッセージを正しいチャネルにルーティングできる中央のメッセージブローカーを使用します。
メッセージ変換（翻訳）
メッセージトランスレータ：異なるデータ形式を使用するシステムがメッセージングを使用して相互に通信できるようにするには、他のフィルタまたはアプリケーション間で特別なフィルタであるメッセージトランスレータを使用して、あるデータ形式を別のデータ形式に変換します。
エンベロープラッパー：既存のシステムが、メッセージヘッダーフィールドや暗号化などのメッセージ形式に特定の要件を課すメッセージング交換に参加できるようにするには、エンベロープラッパーを使用して、メッセージングインフラストラクチャに準拠したエンベロープ内にアプリケーションデータをラップします。宛先に到着したら、メッセージのラップを解除します。
コンテンツエンリッチャー：メッセージの発信者が必要なデータ項目をすべて利用できない場合に別のシステムと通信するには、専用のトランスフォーマーであるコンテンツエンリッチャーを使用して外部データソースにアクセスし、情報が不足しているメッセージを補強します。
コンテンツフィルター：大きなメッセージの処理を簡素化するために、少数のデータアイテムのみに関心がある場合は、コンテンツフィルターを使用して、メッセージから重要でないデータアイテムを削除し、重要なアイテムのみを残します。
クレームチェック：情報コンテンツを犠牲にすることなくシステム全体に送信されるメッセージのデータ量を減らすには、メッセージデータを永続ストアに保存し、クレームチェックを後続のコンポーネントに渡します。これらのコンポーネントは、クレームチェックを使用して、保存されている情報を取得できます。
ノーマライザー：意味的に同等であるが異なる形式で到着するメッセージを処理するには、ノーマライザーを使用して、結果のメッセージが共通の形式と一致するように、カスタムメッセージトランスレーターを介して各メッセージタイプをルーティングします。
正規データモデル：さまざまなデータ形式を使用するアプリケーションを統合する際の依存関係を最小限に抑えるために、特定のアプリケーションから独立した正規データモデルを設計します。この一般的な形式でメッセージを生成および消費するように各アプリケーションに要求します。
メッセージングエンドポイント
メッセージエンドポイント：アプリケーションをメッセージングチャネルに接続してメッセージを送受信するには、メッセージングシステムのクライアントであるメッセージエンドポイントを使用します。このクライアントを使用して、アプリケーションはメッセージを送受信できます。
メッセージングゲートウェイ：アプリケーションの残りの部分からメッセージングシステムへのアクセスをカプセル化するには、メッセージングゲートウェイを使用します。これは、メッセージング固有のメソッド呼び出しをラップし、ドメイン固有のメソッドをアプリケーションに公開するクラスです。
メッセージングマッパー：ドメインオブジェクトとメッセージングインフラストラクチャの間でデータを移動し、2つを互いに独立させたままにするには、メッセージングインフラストラクチャとドメインオブジェクト間のマッピングロジックを含む別のメッセージングマッパーを作成します。オブジェクトもインフラストラクチャも、メッセージングマッパーの存在についての知識を持っていません。
トランザクションクライアント：クライアントtpがメッセージングシステムとのトランザクションを制御できるようにするには、トランザクションクライアントを使用します。クライアントがトランザクション境界を指定できるように、メッセージングシステムとのクライアントのセッションをトランザクションにします。
ポーリングコンシューマー：アプリケーションの準備ができたときにアプリケーションがメッセージを消費できるようにするには、アプリケーションでポーリングコンシューマーを使用する必要があります。ポーリングコンシューマーは、メッセージを受信するときに明示的に呼び出しを行います。
イベントドライバーコンシューマー：アプリケーションがメッセージを利用可能になったときに自動的に消費できるようにするには、アプリケーションはイベントドリブンコンシューマーを使用する必要があります。イベントドリブンコンシューマーは、チャネルで配信されるときにメッセージが自動的に渡されます。
競合するコンシューマー：メッセージングクライアントが複数のメッセージを同時に処理できるようにするには、単一のチャネル上に複数の競合するコンシューマーを作成して、コンシューマーが複数のメッセージを同時に処理できるようにします。
メッセージディスパッチャー：単一チャネル上の複数のコンシューマー間でメッセージ処理を調整するには、チャネルからのメッセージを消費してパフォーマーに配信するメッセージディスパッチャーをチャネル上に作成します。
選択的コンシューマー：メッセージコンシューマーが受信するメッセージを選択できるようにするには、コンシューマーを選択的コンシューマーにします。これは、チャネルによって配信されるメッセージをフィルタリングして、基準に一致するメッセージのみを受信するようにします。
耐久性のあるサブスクライバー：メッセージをリッスンしていないときに欠落しているメッセージをサブスクライブしないようにするには、耐久性のあるサブスクライバーを使用して、サブスクライバーが切断されている間に公開されたメッセージをメッセージングシステムに保存させます。
べき等受信者：メッセージ受信者が重複メッセージを処理できるようにするには、受信者をべき等受信者、つまり同じメッセージを複数回安全に受信できるように設計します。
Service Activator：さまざまなメッセージングテクノロジと非メッセージング技術の両方を介して呼び出されるアプリケーションサービスを作成するには、チャネル上のメッセージをアクセスされているサービスに接続するServiceActivatorを設計します。
メッセージングチャネル
メッセージチャネル：あるアプリケーションがメッセージングを使用して別のアプリケーションと通信できるようにするには、メッセージチャネルを使用してアプリケーションを接続します。一方のアプリケーションはチャネルに情報を書き込み、もう一方のアプリケーションはチャネルからその情報を読み取ります。
ポイントツーポイントチャネル：発信者が1人の受信者だけがドキュメントを受信したり、通話を実行したりできるようにするには、ポイントツーポイントチャネルでメッセージを送信します。これにより、1人の受信者だけが特定のメッセージを受信できるようになります。
パブリッシュ/サブスクライブチャネル：送信者が関心のあるすべての受信者にイベントをブロードキャストできるようにするには、特定のイベントのコピーを各レシーバーに配信するパブリッシュ/サブスクライブチャネルでイベントを送信します。
データ型チャネル：受信者がデータ項目の処理方法を認識できるようにアプリケーションがデータ項目を送信できるようにするには、データ型ごとに個別のデータ型チャネルを使用して、特定のチャネルのすべてのデータが同じ型になるようにします。
無効なメッセージチャネル：メッセージング受信者が意味のないメッセージの受信を適切に処理できるようにするには、受信者は不適切なメッセージを、受信者が処理できなかったメッセージ用の特別なチャネルである無効なメッセージチャネルに移動する必要があります。
デッドレターチャネル：メッセージングシステムがメッセージを配信できない、または配信すべきではないと判断した場合、メッセージをデッドレターチャネルに移動することを選択できます。
保証された配信：メッセージングシステムに障害が発生した場合でもメッセージが確実に配信されるようにするには、保証された配信を使用してメッセージを永続化し、メッセージングシステムがクラッシュしてもメッセージが失われないようにします。
チャネルアダプタ：アプリケーションをメッセージングシステムに接続してメッセージを送受信できるようにするには、アプリケーションのAPIまたはデータにアクセスし、このデータに基づいてチャネルでメッセージを公開できるチャネルアダプタを使用します。アプリケーション内で機能を呼び出します。
メッセージングブリッジ：複数のメッセージングシステムの接続を許可して、一方で使用可能なメッセージをもう一方でも使用できるようにするには、メッセージングシステム間の接続であるメッセージングブリッジを使用して、システム間でメッセージを複製します。
メッセージバス：個別のアプリケーションを連携させることができるが、アプリケーションを他のアプリケーションに影響を与えることなく簡単に追加または削除できるように分離された方法で、これらのアプリケーション間のミドルウェアを接続し、を使用して連携できるようにするメッセージバスです。メッセージング。
システム管理（監視）
コントロールバス：複数のプラットフォームと広い地理的領域に分散されたメッセージングシステムを効果的に管理するには、コントロールバスを使用してエンタープライズ統合システムを管理します。コントロールバスは、アプリケーションデータで使用されるのと同じメッセージングメカニズムを使用しますが、メッセージフローに関連するコンポーネントの管理に関連するデータを送信するために別々のチャネルを使用します。
迂回：検証、テスト、またはデバッグ機能を実行するための中間ステップを介してメッセージをルーティングするには、コントロールバスを介して制御されるコンテキストベースのルーターを使用して迂回を構築します。1つの状態では、ルーターは着信メッセージを追加の手順でルーティングし、もう1つの状態では、メッセージを宛先チャネルに直接ルーティングします。
ワイヤータップ：ポイントツーポイントチャネルで送信されるメッセージを検査するには、メインチャネルとセカンダリチャネルに各着信メッセージを公開するチャネルに単純な受信者リストを挿入します。
メッセージ履歴：疎結合システムでのメッセージのフローを効果的に分析およびデバッグするには、メッセージ履歴をメッセージに添付します。メッセージ履歴は、メッセージが発信されてから通過したすべてのアプリケーションのリストです。
メッセージストア：メッセージングシステムの緩く結合された一時的な性質を乱すことなくメッセージ情報に対してレポートするには、メッセージストアを使用して中央の場所にある各メッセージに関する情報をキャプチャします。
スマートプロキシ：リクエスターが指定した差出人アドレスに返信メッセージを公開するサービスでメッセージを追跡するには、スマートプロキシを使用して、元のリクエスターから提供された差出人アドレスを保存し、スマートプロキシのアドレスに置き換えます。サービスが応答メッセージを送信するとき、それを元の差出人アドレスにルーティングします。
テストメッセージ：内部障害が原因でコンポーネントが送信メッセージを文字化けさせるのを防ぐには、テストメッセージを使用してメッセージ処理コンポーネントの正常性を確認します。
Channel Purger：テストや実行中のシステムの邪魔にならないように、チャネル上の「残りの」メッセージを削除するには、ChannelPurgerを使用してチャネルから不要なメッセージを削除します。
于 2018-10-18T20:21:10.573 に答える
7
重要なものはすべて、エンタープライズ統合パターンの本にあります。見てみな。
于 2009-10-26T13:02:00.630 に答える
5
べき等メッセージ処理を優先する：「二重借方」を発生させることなく、重複メッセージが許容されます。
大きなメッセージは避けてください-「手荷物チェック」イディオムを好む
メッセージの順序付けの要件を回避する-インフラストラクチャの負担を大幅に簡素化する
于 2009-10-26T13:03:46.167 に答える
5
メッセージングデザインパターン（MDP）とパターンの実装-プログラムのパターン言語に関する第17回会議（PLoP 2010）で公開されました。
概要
情報の交換（つまりメッセージング）は、自然と人工のプロセスに固有の部分です。メッセージングは、私たちの周りの世界の至る所にあります。従来のソフトウェア方法論とコンポーネント技術はメッセージングを見落としているため、不完全なモデルを提供します。一方、メッセージングパラダイムと関連するメッセージングデザインパターン（MDP）は、このギャップに対処し、現実世界のより完全で正確なモデルを提供します。その結果、ソフトウェアエンジニアリングのプロセスと手法が大幅に改善されます。ソフトウェアを設計および製造する際には、ソフトウェアコンポーネントだけでなく、これらのエンティティ間で交換されるメッセージングの観点からも考慮する必要があります。カプセル化、デカップリング、および再利用性が向上し、複雑さが軽減されます。このペーパーでは、メッセージングデザインパターンを使用して、Gang of Fourデザインパターン（GoF）、データアクセスオブジェクト（DAO）、J2EEデザインパターンなどの他のよく知られたデザインパターンを実装または実装する方法についても説明します。ほとんどのデザインパターンは、あるレベルでは、参加者間で情報を交換する責任があることに注意してください。全体的な設計とUMLダイアグラムは単純化および合理化されており、理解と実装が容易になっています。結果として得られるソフトウェアの設計と実装も、より堅牢で簡単です。MDPを使用して実装されたデザインパターンは、完全な分散コンポーネントモデルの基盤として、リモートコンポーネント/サービスへの透過的で安全なアクセスを提供するために再利用できます。参加者間で情報を交換する責任があります。全体的な設計とUMLダイアグラムは単純化および合理化されており、理解と実装が容易になっています。結果として得られるソフトウェアの設計と実装も、より堅牢で簡単です。MDPを使用して実装されたデザインパターンは、完全な分散コンポーネントモデルの基盤として、リモートコンポーネント/サービスへの透過的で安全なアクセスを提供するために再利用できます。参加者間で情報を交換する責任があります。全体的な設計とUMLダイアグラムは単純化および合理化されており、理解と実装が容易になっています。結果として得られるソフトウェアの設計と実装も、より堅牢で簡単です。MDPを使用して実装されたデザインパターンは、完全な分散コンポーネントモデルの基盤として、リモートコンポーネント/サービスへの透過的で安全なアクセスを提供するために再利用できます。
于 2010-12-20T02:36:32.323 に答える