並行して、プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を呼び出し、最初の応答のみを使用します。
****************************************
>> 特定のシナリオにおける API 要件は、可能な限り最短時間で応答することです。
>> 最初にプライマリ環境で API を試し、次に DR 環境で API にフォールバックすることを提案するオプションでは、成功した応答が得られますが、少なくとも可能な限り応答は得られません。したがって、これは、特定の要件に対する実装の正しい選択ではありません。
>> プライマリ環境でのみ API を呼び出し、タイムアウトと再試行を追加することを提案する別のオプションでも、再試行時に成功した応答が得られる可能性がありますが、最小限の時間では成功しない可能性があります。したがって、これも、特定の要件に対する実装の正しい選択ではありません。
>> Scatter-Gather を使用してプライマリ環境の API と DR 環境の API を並行して呼び出すことを提案するもう 1 つのオプションでは、マージされた結果が返されるため、誤った API 応答が発生します。さらに、Scatter-Gather は並行して処理を実行しますが、これは真実ですただし、スコープ内のすべてのルートが完了した場合にのみスコープが完了します。したがって、繰り返しになりますが、特定の要件に対する実装の正しい選択ではありません。正しい選択は、プライマリ環境の API と DR 環境の API を並行して呼び出し、そのうちの 1 つから受け取った最初の応答のみを使用することです。

CloudHub でデプロイされた Mule と手動でプロビジョニングされたオンプレミス Mule を組み合わせて使用​​する
ランタイムは、MuleSoft がホストするプラットフォームのコントロール プレーンによって管理されます。
****************************************
特定のシナリオから得られる主な詳細:
>> 組織はクラウドベースのシステムとオンプレミスのシステムの両方を使用しています
>> オンプレミス システムには、組織のイントラネット内からのみアクセスできます。 上記の重要な詳細に基づいて、与えられた選択肢を評価してみましょう。
>> CloudHub にデプロイされた Mule ランタイムは、MuleSoft がホストするコントロール プレーンを使用してのみ制御できます。Private Cloud Edition のコントロール プレーンを使用して CloudHub Mule ランタイムを制御することはできません。したがって、これを示唆するオプションは無効です
>> MuleSoft がホストする Anypoint Platform によって管理される共有ワーカー クラウドで CloudHub にデプロイされた Mule ランタイムを使用することは、特定のシナリオと愚かな選択とはまったく無関係です。したがって、これを示唆するオプションは無効です
>> 外部ネットワークへのアクセスがなく完全に分離され、Anypoint Platform Private Cloud Edition コントロール プレーンによって管理される Mule ランタイムのオンプレミス インストールを使用すると、オンプレミス統合が機能します。ただし、外部アクセスがない場合、SaaS ベースのアプリとの統合は行えません。さらに、CloudHub でホストされるアプリは、SaaS ベースのアプリケーションとの統合に最適です。したがって、これが最善の方法であることを示唆するオプションです。
これらの混合/ハイブリッド統合をサポートするために Anypoint Platform を設定して使用する最良の方法は、CloudHub でデプロイされた Mule ランタイムと、MuleSoft がホストするプラットフォームのコントロール プレーンによって管理される手動でプロビジョニングされたオンプレミスの Mule ランタイムを組み合わせて使用​​することです。

プロセス層
****************************************
>> エクスペリエンス レイヤーは、エンド ユーザー エクスペリエンスの強化に特化しています。このレイヤーは、さまざまな API クライアント/コンシューマーのニーズを満たすためのものです。
>> システム層は本質的にモジュール式であり、バックエンド システムのさまざまな個別の機能を実装/公開する API 専用です
>> プロセス層は、1 つまたは複数のシステム層モジュラー API を呼び出すことによって、単純または複雑なビジネス オーケストレーション ロジックが記述される場所です。 したがって、プロセス層が正しい答えです。

バックエンド システムからの分離を限定的に行う実用的なアプローチが適切とみなされる場合。
****************************************
データ モデルの選択に関する一般的なガイダンス:
>> エンタープライズ データ モデルが使用されている場合、システム API の API データ モデルはそのエンタープライズ データ モデルのデータ型を利用する必要があり、対応する API 実装はエンタープライズ データ モデルのこれらのデータ型とネイティブ データ モデルの間で変換する必要があります。バックエンド システムの。
>> エンタープライズ データ モデルが使用されていない場合は、各システム API を有界コンテキストに割り当てる必要があります。システム API の API データ モデルは、対応する有界コンテキスト データ モデルのデータ型を利用し、対応する API 実装は、対応する有界コンテキスト データ モデル間で変換する必要があります。これらのデータ型は、境界コンテキスト データ モデルとバックエンド システムのネイティブ データ モデルから取得されます。このシナリオでは、境界コンテキスト データ モデルのデータ型は純粋にビジネス特性の観点から定義されており、通常はバックエンド システムのネイティブ データ モデルとは関連しません。言い換えれば、翻訳の労力は膨大になる可能性があります。
>> エンタープライズ データ モデルが使用されておらず、クリーンな境界コンテキスト データ モデルの定義が多大な労力を要すると考えられる場合、システム API の API データ モデルは、バックエンド システムのデータ タイプをほぼミラーリングするデータ タイプを使用する必要があります。バックエンド システムと同じセマンティクスと命名が行われ、軽くサニタイズされ、特定のシステム API の機能に必要なすべてのフィールドが公開されますが、それ以上ではなく、REST 規約がうまく利用されています。
後者のアプローチ、つまり、基本的にバックエンド システムの API データ モデルをミラーリングする API データ モデルをシステム API で公開する方法では、それ自体では、システム API 層を介してバックエンド システムから満足のいく分離が提供されません。
特に、バックエンド システムを「スワップアウト」するには、通常、そのバックエンド システムの前にあるすべてのシステム API を大幅に変更し、したがって、それらのシステム API に依存するすべてのプロセス API の API 実装を大幅に変更する必要があります。これは、現在新しいバックエンド システムの前面にあるシステム API の API データ モデルの形式で、以前のバックエンド システムのデータ モデルの寿命を延ばすことが望ましくないためです。
したがって、このアプローチに従ったシステム API の API データ モデルは、バックエンド システムが置き換えられたときに変更する必要があります。
一方で：
>> これは非常に実用的なアプローチであり、バックエンド システムに直接アクセスする場合に比べて追加されるオーバーヘッドが比較的少ないです
>> API クライアントをデータ モデルの外部のバックエンド システムの複雑さ (プロトコル、認証、接続プーリング、ネットワーク アドレスなど) から分離します。
>> 通常の API ポリシーをシステム API に適用できるようにします
>> システム API の RAML 定義で公開することにより、バックエンド システムと対話するための API データ モデルを明示的かつ可視化します。
>> バックエンド システム データ モデルからのさらなる分離は、プロセス API 層の API 実装で発生します。

手動でプロビジョニングされた顧客ホスト型ランタイム プレーンと顧客ホスト型コントロール プレーン
****************************************
質問に示されたシナリオから考慮すべき重要な要素が 2 つあります。
>> 会社では、データとメタデータの両方を企業ファイアウォール内に配置する必要があります。
>> 会社は顧客がホストするインフラストラクチャを使用したいと考えています。
クラウド (Mulesoft がホストするクラウド、または Azure、AWS などの顧客独自のクラウド) を直接または間接的に扱う展開モデルでは、少なくともメタデータを共有する必要があります。
顧客がホストするランタイムプレーンに Mule ランタイムを配置することで、アプリケーションデータをファイアウォール内で制御できます。しかし、Mulsoft がホストする/クラウドベースのコントロール プレーンを使用する場合、コントロール プレーンには企業ファイアウォールの外側に送信される少なくともある程度の最低限のメタデータが必要です。
データとメタデータの両方を企業ファイアウォール内に置くという顧客の要件は非常に明確であるため、顧客はできるだけ早く本番環境に移行したいと考えていますが、残念ながらセキュリティ要件の性質上、次のような選択肢しかありません。手動でプロビジョニングされた顧客ホスト型のランタイム プレーンと顧客ホスト型のコントロール プレーンを使用します。