サービス A は、サービス B に応答メッセージ (3) でデータをサービス A に返すように要求するメッセージ (2) を送信するタスク サービスです。受信した応答に応じて、サービス A は応答を必要としないメッセージをサービス C (4) に送信する必要がある場合があります。
サービス B に接続する前に、サービス A はまず自身のデータベース (1) からコード値のリストを取得し、次にこのデータを自身のメモリに配置する必要があります。サービス C にメッセージを送信する必要があることが判明した場合、サービス A はサービス B から受信したデータとコード値リストのデータを組み合わせて、サービス C に送信するメッセージを作成する必要があります。サービス C を呼び出す必要はないため、コード値を破棄することでタスクを完了できます。
サービス A とサービス C はサービス インベントリ A に存在します。サービス B はサービス インベントリ B に存在します。
サービス インベントリ A のサービスは、サービス インベントリ B のサービスとは異なる設計標準およびテクノロジに基づくサービス コントラクトを使用して設計されていることがわかります。その結果、サービス A は SOAP ベースの Web サービスであり、サービス B は SOAP ベースの Web サービスです。 JSON 形式のメッセージを交換する REST サービス。
したがって、サービス A とサービス B は現在通信できません。さらに、サービス C は、多くの同時サービス利用者によって頻繁にアクセスされる、不可知論的なサービスです。サービス C は頻繁に使用量のしきい値に達し、その間はサービス C を利用できなくなり、サービス C に送信されたメッセージは受信されません。
これらの問題を解決するにはどのような措置を講じることができますか?

別紙を参照してください。

サービス利用者 A は、ビジネス文書を含むメッセージをサービス A に送信します (1)。ビジネス ドキュメントはコンポーネント A によって受信され、コンポーネント A はビジネス ドキュメントをメモリに保持し、コピーをコンポーネント B に転送します (3)。コンポーネント B は、まずビジネス文書の一部をデータベース A に書き込みます (4)。次に、コンポーネント B はビジネス ドキュメント全体をデータベース B に書き込み、ビジネス ドキュメントのデータ値の一部をクエリ パラメーターとして使用して、データベース B から新しいデータを取得します (5)。
次に、コンポーネント B は新しい日付* をコンポーネント A に返します (6)。コンポーネント A はそれをメモリ内に保持している元のビジネス ドキュメントと結合し、結合されたデータをデータベース C に書き込みます (7)。サービス コンシューマ A によって呼び出されるサービス A のサービス機能には、同期の要求と応答のデータ交換が必要です。したがって、最後のデータベース更新の結果に基づいて、サービス A は成功または失敗コードを含むメッセージをサービス コンシューマ A に返します (8)。
データベース A と B は共有され、データベース C はサービス A サービス アーキテクチャ専用です。
このアーキテクチャにはいくつかの問題があります。コンポーネント A が (コンポーネント B の処理が完了するのを待機している間) メモリ内に保持する必要があるビジネス ドキュメントは、非常に大きくなる可能性があります。サービス A がこのデータをメモリ内に保持するために使用するランタイム リソースの量により、すべてのサービス インスタンスの全体的なパフォーマンスが低下する可能性があります。特に、サービス インスタンスが複数のサービス コンシューマによって同時に呼び出された場合に顕著です。さらに、データベース A は共有データベースであり、コンポーネント B への応答に時間がかかる場合があるため、サービス A がサービス コンシューマ A に応答するまでに長い時間がかかることがあります。現在、サービス コンシューマ A は応答を最大 30 秒待機します。 , その後、サービス A へのリクエストが失敗したものとみなされ、サービス A からの後続の応答メッセージは拒否されます。
これらの問題を解決するにはどのような措置を講じることができますか?

サービス A は、共有データベース (1) から定期的に複製されるデータを含むデータベースに汎用データ アクセス ロジックを提供するユーティリティ サービスです。標準化されたサービス契約の原則がサービス A の設計に適用されたため、そのサービス契約は完全に標準化されています。
サービス A のサービス アーキテクチャには 3 人のサービス コンシューマがアクセスしています。サービス コンシューマ A は、サービス A 実装の一部であるコンポーネントを直接呼び出すことでアクセスします (2)。サービス コンシューマ B は、そのサービス コントラクトにアクセスしてサービス A を呼び出します (3)。サービス コンシューマ C は、サービス A 実装の一部である複製されたデータベースに直接アクセスします (4)。
サービス コンシューマ A と C が、公開されたサービス A サービス コントラクトをバイパスする理由は、セキュリティ上の理由から、サービス A サービス コントラクトを構成する API の機能のサブセットへのアクセスが許可されていないためであると言われています。サービス A のアーキテクチャを変更して、否定的な形式の結合を回避しながら、これらのセキュリティ制限を適用するにはどうすればよいでしょうか?

サービス A は、タスクを完了するために一連のデータベースに対して一連の更新を実行する必要があるタスク サービスです。データベースの更新を実行します。サービス A は、それぞれが標準化されたデータ アクセス機能を提供する他の 3 つのサービスと対話する必要があります。
サービス A は最初の更新要求メッセージをサービス B に送信し (1)、サービス B は成功コードまたは失敗コードを含むメッセージで応答します (2)。次に、サービス A は 2 番目の更新要求メッセージをサービス C に送信し (3)、サービス C も成功コードまたは失敗コードを含むメッセージで応答します (4)。最後に、サービス A はサービス D に要求メッセージを送信し (5)、サービス D は成功コードまたは失敗コードのいずれかを含む独自のメッセージで応答します (6)。
サービス B、C、および D は、複数のサービス利用者によって再利用および共有される非依存型サービスです。これにより、サービス A のサービス利用者にとって、タスク全体の完了に時間がかかりすぎるため、許容できないパフォーマンスの低下が発生しました。あなたは、サービス A が一貫した予測可能なランタイム パフォーマンスを提供できるように、サービス構成アーキテクチャを強化するように求められました。さらに、新しいタイプのデータが 3 つのデータベースすべてに導入されることが通知されます。サービス間メッセージのデータに使用されるデータ モデルが同じになるように、このデータが標準化された方法で交換されることが重要です。
これらの要件を満たすにはどのような手順を実行できますか?

サービス A は、頻繁に変更されるデータ値を返す Get 機能を提供するエンティティ サービスです。
サービス コンシューマ A は、このデータ値 (1) を要求するためにサービス A を呼び出します。サービス A がこのリクエストを実行するには、データ値が保存されているデータベースと対話 (3、4) するユーティリティ サービスであるサービス B (2) を呼び出す必要があります。データ値が変更されたかどうかに関係なく、サービス B は最新の値をサービス A に返し (5)、サービス A は最新の値をサービス コンシューマ A に返します (6)。
データ値は、レガシー クライアント プログラムがデータベースを更新するときに変更されます (7)。この変化がいつ起こるかは予測できません。サービス A とサービス B は常に同時に利用できるわけではないことにも注意してください。
データ値が変更されるたびに、サービス コンシューマ A はできるだけ早くそれを受信する必要があります。したがって、サービス利用者 A は、図に示すメッセージ交換を 1 日に数回開始します。以前と同じデータ値を受信した場合、サービス A からの応答は無視されます。サービス A が更新されたデータ値を提供すると、サービス コンシューマ A はそれを処理してタスクを実行できます。
現在のサービス構成アーキテクチャは、サービス コンシューマ A によるサービス A の繰り返しの呼び出しと、呼び出しごとに発生するメッセージ交換により、リソースを使いすぎています。
この問題を解決するにはどのような手順を実行できますか?