サービス A は、請求書関連の処理専用の機能コンテキストを備えた SOAP ベースの Web サービスです。
サービス B は、データベースへの汎用データ アクセスを提供する REST ベースのユーティリティ サービスです。
このサービス構成アーキテクチャでは、サービス コンシューマ A が、請求書 XML ドキュメントを含む SOAP メッセージをサービス A に送信します (1)。次に、サービス A は請求書 XML ドキュメントをサービス B に送信し (2)、サービス B は請求書ドキュメントをデータベースに書き込みます (3)。
サービス利用者 A が請求書ドキュメントを表すために使用するデータ モデルは、XML スキーマ A に基づいています。
サービス A のサービス契約は、XML スキーマ B に基づいて請求書ドキュメントを受け入れるように設計されています。サービス B のサービス契約は、XML スキーマ A に基づいて請求書ドキュメントを受け入れるように設計されています。サービス B が請求書レコードを書き込む必要があるデータベースは、XML スキーマ B に基づいて請求書ドキュメントを受け入れるように設計されています。ビジネス文書全体を独自のカンマ区切り値 (CSV) 形式で保存します。
サービスで使用される XML スキーマに互換性がないため、サービス利用者 A からサービス B への請求書ドキュメントの送信は、現在のサービスを使用して行うことはできません。契約集中化パターンが適用され、ロジック集中化パターンが適用されていないと仮定すると、実行時のパフォーマンス要件を高めるロジックを追加せずに、サービス コンシューマ 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 はメッセージをサービス A (1) に送信し、サービス A はそのメッセージをサービス B (2) に転送します。サービス B はメッセージをサービス C (3) に転送し、サービス C は最終的にメッセージをサービス D (4) に転送します。ただし、サービス A、B、および C にはそれぞれ、メッセージの内容を読み取り、どの中間処理を実行するか、およびメッセージをどのサービスに転送するかを決定するロジックが含まれています。したがって、図に示されているのは、考えられるいくつかの実行時シナリオのうちの 1 つにすぎません。
現在、このサービス構成アーキテクチャは、1 つのメッセージの送信に関与できるサービスの数にもかかわらず、適切に機能しています。ただし、サービス A に新しいロジックが追加されており、実行時にサービス A がメッセージの転送先を決定するためにアクセスする必要がある新しいデータを取得するために、別のサービスを 1 つ構成する必要があることがわかります。追加サービスが関与すると、サービス構成が大きくなりすぎ、速度が遅くなります。
新しい要件に対応し、サービス構成メンバーの増加を回避しながら、サービス構成アーキテクチャを改善するにはどのような手順を実行できますか?

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

サービス 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 の繰り返しの呼び出しと、呼び出しごとに発生するメッセージ交換により、リソースを使いすぎています。
この問題を解決するにはどのような手順を実行できますか?

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

サービス A がサービス コンシューマ A (1) からメッセージを受信すると、そのメッセージはコンポーネント A によって処理されます。
このコンポーネントは最初にコンポーネント B (2) を呼び出します。コンポーネント B (2) は、メッセージの値を使用してデータベース A を照会し、追加のデータを取得します。次に、コンポーネント B は追加データをコンポーネント A に返します。その後、コンポーネント A はコンポーネント C を呼び出します (3)。コンポーネント C はレガシー システムの API と対話して新しいデータ値を取得します。その後、コンポーネント C はデータ値をコンポーネント A に返します。
次に、コンポーネント A は蓄積したデータの一部をコンポーネント D に送信し (4)、コンポーネント D はそのデータを特定のフォルダーに配置されるテキスト ファイルに書き込みます。コンポーネント D は、定期的にスケジュールされたバッチ インポートによってこのファイルが別のシステムにインポートされるまで待機します。インポートが完了すると、コンポーネント D は成功または失敗のコードをコンポーネント A に返します。コンポーネント A は最後に、これまでに収集されたすべてのデータを含む応答をサービス コンシューマ A (5) に送信し、サービス コンシューマ A はすべてのデータをデータベース B (6)。
コンポーネント A、B、C、および D は、サービス A サービス アーキテクチャに属します。データベース A、レガシー システム、およびファイル フォルダーは、IT 企業内の共有リソースです。
サービス A は、過去数年間で成長したサービス アーキテクチャを持つエンティティ サービスです。サービス インベントリ全体の再設計プロジェクトの結果、サービス A の動作を中断することなく、コンポーネント B、C、D によって提供されるロジックを 3 つの異なるユーティリティ サービスに分離するために、サービス A のサービス アーキテクチャを再検討するように求められます。これはサービス利用者 A に関係します。
これらの要件を満たすにはどのような手順を実行できますか?