動的クライアントとの統合

Question

私は建築設計の質問があります。当社は最近、ケースマネジメント用のCOTS（.NETベースの製品）を導入しました。この製品には洗練されたインテグレーションモジュールがあり、すべてのユーザーアクションでMQの完全な情報XMLを吐き出します。各XML要素には、変更された要素を知るために、追加、編集&削除フラグがあります。

これらのイベントを処理し、変更されたものを条件として複数の外部パートナーに送信するアプリケーションを作成する必要があります。各外部パートナーとのインターフェースは、必要なデータ、表現（XML、String、jsonなど）とプロトコル（SOAP、REST、MQ、DBコールなど）の点で異なります。

誰かがこのようなシステムをどのように設計し、どのような技術を使用することができるかに関する提案はありますか？ （FYI、既存のテクノロジースタックJava/JEE、Weblogic）。

PS。 私がこれに関して持っていた主な問題は、パートナーの1人がダウンしている場合、他のパートナーを拘束すべきではないということです。同時に、パートナーは単一の通知を失うことはありません。

ありがとうございます。

Answer 1

可能なアプローチ：

• COTSは、メッセージキューへのアプリケーションのイベントに関するメッセージを入れました。
• メッセージジェネレータコンポーネントはメッセージキューをリッスンし、現在既知のパートナーについてパートナーDBに照会します。各COTSメッセージについて、発生したことを通知するイベントメッセージがパートナーごとに生成されます。イベントには「配信済み」フラグもあります。したがって、基本的に、COTSで満たされたメッセージキューをN個のメッセージキューに変換します。各メッセージキューはパートナーごとに1つずつあります。イベントは不変オブジェクトでなければならず、リレーショナルDBまたはNoSQL DB（「メッセージDB」）に格納することができます。
• N以下のエンドポイントコンポーネントがアプリケーションサーバー内で実行されています。彼らはリクエストが到着すると、共通のコンポーネント（図の「Common Data Retrieval Concerns」）に新しいメッセージを要求します。 共通コンポーネントはメッセージDBを照会し、メッセージをJavaオブジェクトリストとして渡し、エンドポイントコンポーネントはシリアライゼーションを気にします。 一般的なコンポーネントは、パートナDBからの情報を使用して、承認に関心を持つ可能性があります。

注意：それらが正常に配信された場合、公開され共通コンポーネントなければならない唯一のフラグメッセージ。パートナーコンポーネントからの確認応答を待ちたいイベントがあります。 プロセス中にトランザクションのアトミックを保証することはできないため、パートナーのクライアントは重複に対して堅牢である必要があります。 お使いのサーバソフトウェアだけでなく、各クライアントは、各イベントのメッセージID（UUID）を管理する必要があります

• あなたの仕事は、イベントメッセージごとに固有のID

• あなたの仕事を生成する気にすることですパートナーは特定のIDで既にイベントを処理したかどうかを確認するルックアップテーブルを維持しています。