標準的なSOA実装は多数のサービスに依存しています。こうしたサービスを呼び出すにはサービスのロケーション（すなわち、サービスのエンドポイントアドレス）とバインディング（このエンドポイントに到達するためのトランスポートメカニズム）の知識がなければなりません。最も単純なケースでは、実装時にエンドポイントアドレスをハードコード化することが可能です。このアプローチをとると、ソリューションの実装とサービスのロケーションの間に緊密な結合（ロケーション結合）がもたらされます。エンドポイントアドレスを外に出し、コンフィギュレーションファイル.NET内に置くことにより、実装の状態を改善することができます。こうすればコードを全く修正せずに、アドレスを変更できます。しかし、消費者とサービスの数が増えるにつれて（その結果、コンフィギュレーションファイルも増大）、このオプションもスケーラビリティの問題に直面します。
エンドポイントアドレスと呼び出しポリシーに対するサービスクエリの問題を動的に解決することに特化したコンポーネント「サービスレジストリ」に依存することにより、この問題に対する極めて柔軟かつ維持しやすいソリューションがもたらされます。この場合、サービスレジストリには、各ロケーションでの呼び出しに関連したサービスのデプロイメント、ロケーション、ポリシーに関する全情報が含まれています。
サービスレジストリの概念は当初、Webサービスの全体的な構想の一部として導入されたものであり、UDDI（Universal Description, Discovery and Integration）レジストリをサービス消費者と供給者の間の「仲介者」（ブローカー）として定義しました。UDDIの責務は、消費者が必要とする機能性に基づき、サービス制作者の動的な選択を供給することと考えられました。その役割はイエローページの役割に似ていたのです。多数のベンダーや標準化団体から後押しがあったにもかかわらず、サービス仲介者としてのUDDI利用は決して成功しませんでした。今日のUDDI利用法の大多数はサービスWSDLファイルの参照に限定されており、消費者設計時に使われています。
サービスレジストリのさらに実用的な利用法は、たとえばJ2EE実装で広く使われているサービスロケーター・パターン[1]に類似した、サービス名（およびポリシー）に基づいたサービスエンドポイント／バインディングのランタイム検索です。この場合、（消費者）開発時にサービス定義（インタフェース）を利用可能で、レジストリの使用はサービスエンドポイントアドレスと動的バインディングのランタイム導出に限定されています。
本稿では、SOAソリューションの実装を単純化するために利用できるサービスレジストリの.NET実装を説明します。
続きをご覧になりたい方は、以下URLよりアクセスしてください。
http://www.infoq.com/jp/articles/net-service-registry
また、ガバナンスに関する他の記事をご覧になりたい方は、以下URLで表示される一覧からどうぞ。
http://www.infoq.com/jp/Governance