サービス・ファサード・パターンを使用することにより、サービス要求元と、アプリケーションによって提供される機能またはサービス対応でない機能との間の疎結合が提供されます。 疎結合により、プロバイダーの複雑さが隠され、標準 Web サービス・インターフェースが提供されます。
また、サービス・ファサード・パターンは、ロギングなどの、標準機能のアプリケーションのメディエーション・ポイントも導入します。エンタープライズ・アーキテクチャーがサービス指向アーキテクチャーに移行するときには、ビジネスの大部分を実行するもののサービス機能を持たない、既存のレガシー・システムに対応する必要がしばしば生じます。 こうしたアプリケーションがしばしば使用する機能は、サービスに対応した、より新しいソフトウェア・パッケージにアクセス可能でなければならないものの、アダプター、メッセージング、または他の非サービス指向統合技術を介さないとアクセスできません。
レガシー・アプリケーションは元々、サービス指向アーキテクチャー (SOA) 環境には適しておらず、こうしたシステムの変更には費用がかかり、高度なスキルを必要とします。 問題は、こうしたシステムを、より新しいサービス指向パッケージおよびアプリケーションと統合する方法を見つけることです。 特に、Web サービスで一般的に使用される同期 HTTP プロトコルと、レガシー・アプリケーションで頻繁に使用されるメッセージング・プロトコルとのブリッジを作成する必要があります。
このパターンが適しているのは、企業には SOA 環境の一部として要求元クライアントにサービス・インターフェースを提供する意志があっても、プロバイダー・アプリケーションをアップグレードしてサービス・インターフェースを提供するのが容易でない場合です。
このパターンは、プロバイダー・アプリケーションが XML インターフェースを提供し、クライアント・アプリケーションが Web サービスの呼び出しをサポートする場合に使用されます。 このパターンを拡張して、WebSphere MQ 経由の非 XML インターフェースによる、アプリケーションへのサービス・ファサードをサポートするよう変換することができます。