WebサービスをラップするWebサービスに必要なエンタープライズアーキテクチャパターンとは何ですか？
サービス指向アーキテクチャー（SOA）の一部として、サードパーティのWebサービスからデータを取得するWebサービスを作成するように依頼されました。サードパーティのWebサービスの実装固有の詳細を非表示にし、返されたデータをマッピングして、サードパーティのサービスの実装の詳細が漏洩しないようにします。
SOAは初めてです。このプロジェクトを口語的に「a web service bridge」のように呼びます。
正しいSOAこれに対するエンタープライズアーキテクチャパターンの用語は何ですか？
エンタープライズアーキテクチャのパターンの多くが同じもの（サービスファサード？、メッセージブローカー？メッセージチャネル？プロキシ？）を記述しているように見えるので、私は非常に混乱しています。私は、必要な抽象化のレベルに完全には対応していないと思います。
質問によって、パターンには複数の側面があるため、1つのパターンを特定することはできません。サービスがどのように設計されているかによって、パターンは異なります。ただし、一般に、指定したのは包括的なService Abstractiondesign principal です。
また、ソフトウェアの一部は、特にWebサービスの範囲では、多くの場合、複数の設計パターンで構成されています。したがって、Webサービスは、Model-View-Controllerパターンを使用して設計できますが、さまざまなレイヤーに一連のアダプター、データマッパー（以下で説明）などがあります。それでもプロジェクトの重要な場合は、主要なビジネス価値を特定し、それを設計パターンにマッピングできます。したがって、以下で説明するすべてのパターンがenterprise設計パターンとみなされるとは限らない場合でも、サービスが何をするかを伝えるパターンを使用する方が便利です。必ずしもenterpriseデザインパターンであるかどうか。
あなたの質問で述べたことから、それはファサードまたはその特殊化Remoteファサード。その主な目的が基盤となるAPIを単純化し、複雑さを隠蔽することである場合はファサードになります（これはあなたが述べていることです）。さらに、リモートファサードは、問題がある場合は、2つのシステム間の呼び出しの数を減らすことも目的としています。
Adapterパターンは、通常、複数のアダプタが存在することを想定して設計されています（現在または将来）。したがって、一貫したインターフェースを提供し、基礎となるサービスでさまざまな操作を実行できるようにWebサービスを作成することが主な関心事である場合は、アダプターを設計しています。典型的な例は、新しいデプロイメントサービスを提供し、Compile()というメソッドを公開する場合です。 MSBuild用とnmake用の2つのアダプターを実装します。特定のプロジェクトが記述されているシステムに応じて、適切なアダプターを取得し、適切なコマンドを発行します。
同様のパターンは Data Mapper です。これは、一貫したデータ型のセットをさまざまな基礎となるデータストアのデータ型にマッピングします。サービスがUserIdフィールドをクライアントに公開していて、2つの異なるデータストアのUserNameおよびUserPrincipalフィールドにマップされている場合、これは次のようになります。見ています。必ずしも複数のデータストアがあることを意味するのではなく、その可能性を念頭に置いて設計していることを意味します。
Bridgeパターンは、抽象化とその実装がある場合に通常適用されますが、両方を変更する必要があります。通常、実装はアダプターパターンを使用して行われるため、最終的には一連のアダプターだけでなく、抽象化とそのサブクラスも作成されます。
Gatewayは、サービス間の一貫したインターフェースを提供するためのものです。したがって、REST APIを公開するwww.myservice.comを使用すると、さまざまなプロトコルを使用している可能性のある他のサービスが呼び出されます。クライアントが常にこれらのサービスのいずれかがプロトコルを変更することを決定した場合でも、同じインターフェイスを取得します。
あなたが説明しているのは、本質的には Adapter 設計パターンです。使用したい外部コンポーネントがありますが、その実装とインターフェースは企業内で使用したいものではありません。
ラッパーをWebサービスとして公開しているという事実は、パターンがまだ同じであるため、無関係です。基本的に、既存のサービスを新しいインターフェースでラップしています。