本
エンタープライズ統合パターン
彼はメッセージ指向ミドルウェアの使用について話しているようです
考慮すべき点がいくつかあります
安全
別の不正なサービスがシステムの主要コンポーネントとして登録されるのを防ぐにはどうすればよいですか。サービスが本人であるかどうかを検証および検証する方法が必要になります。これは、PKIシステムを介して実行できます。システムが完全にイントラネットでホストされている場合は、これを行う必要がないシナリオがあります。その場合、ソーシャルエンジニアリングと不正な従業員が最大の脅威になります。
契約
クライアントはサービスとどのような契約を結びますか？メッセージはすべてXMLとしてシリアル化され、TextMessageとして送信されますか？純粋なバイトメッセージを使用する場合、サービスを複数のプラットフォームで実行する場合は、バイトの順序に注意する必要があります。
同期
ほとんどの開発者は、非同期メッセージを正しく理解して利用することができません。可能な場合は、「同期」メッセージを呼び出す方法を作成することが設計の最大の利益になる可能性があります。私は過去に、タイムアウトとreturnオブジェクトを使用してsendMessageAndWait（）メソッドを作成することでこれを行いました。メソッド内で、応答を受信するための一時的なトピックIDを作成し、そのリスナーを登録してから、ロックを使用して、一時的なトピックでメッセージが返されるのを待つことができます。
迷惑メッセージ
サービスが未承諾メッセージをクライアントに送信できるようにする場合はどうなりますか？サービスAで重大なイベントが発生し、クライアントまたは場合によってはWatchDogサービスに通知する必要があります。クライアントが会話を開始せずにクライアントと通信するサービスの共通通信チャネルに設計を登録できるようにします。
フェイルオーバー
クレジットカードを処理する重要なサービスがダウンした場合はどうなりますか？主要なインフラストラクチャが常に稼働していることを確認するには、フェイルオーバーおよびウォッチドッグサービスを実装する必要があります。レジストリ内にサービスのリストを登録すると、レジスタがプライマリサービスを提供し、プライマリが通信を停止した場合にセカンダリサービスにフォールバックできます。または、メッセージ指向ミドルウェアがラウンドロビンメッセージングを処理できる場合は、同じトピックにすべてのサービスを登録できる可能性があります。サービスがいつ終了したかを知る方法を作成することを検討してください。ほとんどのメッセージは非同期であるため、サービスがいつオフラインになったのかを判断するのは困難です。これは、ハートビートとウォッチドッグを使用して実行できます。
私は過去に、通信が必要な大規模システム用にこのタイプのシステムを数回作成しました。あなたや他の開発者がそのようなシステムの長所と短所を理解していれば、それは非常に強力で柔軟になる可能性があります。
私が提供できる最大のアドバイスは、他の開発者向けのツールキットを作成して、サービスの登録方法、フェイルオーバーの実装方法、またはクライアントからのメッセージへの応答方法について考える必要がないようにすることです。これらはあなたのシステムを殺し、他の人にそれが複雑すぎると言わせるようなものです。彼らにとって苦痛がないようにすることで、エンタープライズデザインパターンを理解することで開発者に負担をかけずに、システムを必要な方法で柔軟性と分離性で機能させることができます。
これは象牙の塔の建築家/建築ではありません。彼が「これがどのように行われるのか、今それを行って、私が正しいことを知っているので、それについて私に迷惑をかけないでください」と言ったとしたら、それはそうでしょう。本当にアンチパターンを参照したい場合は、キッチンシンクかもしれません。いや、考えてみると、流し台でもありません。
見つけたらコメントとして投稿してください。
アンチパターン