サービス・プロキシー・パターン

このパターンを使用すると、サービスの間接化の段階が 1 つ追加され、サービス要求元とサービス・プロバイダーとの間の分離が最大になります。

最も基本的な形では、サービス・プロキシー・パターンはサービス実装の実際の場所を隠します。 このパターンは、アクセス制御、要求のトラッキング、および監査の管理ポイントを設ける面でも特別な価値があります。

サービス・プロキシー・アーキテクチャーの図

コンテキスト

クライアントはサービス上の操作を呼び出す必要があります。サービスが存在するエンドポイントのアドレス、または実際のエンドポイントのアドレスは変わる可能性があるため、クライアントはサービスに直接アクセスしてはなりません。 実際のエンドポイントのアドレスは、サービスへのアクセスを制御できるようにするために隠されています。

問題

どのようにして、サービスが存在するエンドポイントの実アドレスを公開せずに、制御された方法でクライアントがサービスを使用できるようにするか。

選択についてのガイダンス

以下のような場合に、このパターンを使用します。

サービスが組織や部門の境界を超えて公開される場合、セキュリティー、監査証跡の保守、信頼性、サービス品質、および通信の互換性といった問題を考慮する必要があります。

サービスのデプロイメントの柔軟性を保持することは望ましいことです。例えば、サービスを別のサーバーに移動しても、サービスのエンドポイントのアドレスが変わっていないように見せることで、サービスのどのクライアントにも影響が及ばないようにできます。

サービスでサポートされるプロトコル・バインディングが、特定のクライアントのセットにとって適切でないことがあります。 必要なプロトコルをサポートするようにサービスを変更することは 1 つの解決策ですが、この解決策が望ましくない、あるいは不可能な場合も少なくありません。

サービスの本当の場所を隠し、すべてのクライアントが特定の制御点を介して間接的にサービスにアクセスしなければならないようにすることもできます。 サービスの実際の場所を隠すことによって、監査機能または追加のクライアント認証検査を追加できるようになります。

ソリューション

ターゲット・サービスは、同じインターフェースを実装するエンタープライズ・サービス・バス (ESB) メディエーションをデプロイすることによって隠されます。 このメディエーションは、すべての要求を実際のサービス・プロバイダーに転送する仮想サービスまたはプロキシーとして機能します。 クライアントには、サービスの実際のプロバイダーであるように見える仮想サービスのみが表示されます。

仮想サービスは、実際のサービスによってサポートされるバインディングに対して、異なるプロトコル・バインディングのセットをサポートし、必要なプロトコル変換をメディエーションの一部として提供する場合があります。

最も簡単な形では、メディエーションは各要求を、事前構成されたエンドポイント・アドレスに転送します。 より柔軟なアプローチでは、サービス・レジストリーへの照会を使用して実アドレスを判別し、後続の要求で使用するためにこの値をキャッシングします。

仮想サービスあるいはメディエーションは、多数の追加機能を実装します。典型的な実装では、メディエーションは各要求を監査目的でログに記録します。 さらに、仮想サービスは追加レベルのアクセス制御を提供して、それぞれの着信要求に関連する資格情報を検査する場合もあります。 より高度な実装として、異なるセキュリティー・ドメイン間の ID マッピングを提供するというものもあります。