JP4897872B2 - サービス・レジストリ、ならびに関連したシステムおよび方法 - Google Patents

Description

本発明は、サービス指向アーキテクチャに関する。特に本発明は、ＳＯＡ（ｓｅｒｖｉｃｅ−ｏｒｉｅｎｔｅｄ ａｒｃｈｉｔｅｃｔｕｒｅ）におけるサービス・レジストリの改善と、関連するサービス伝搬、照会、サービス呼び出し中のサービスの選択およびルーティングの方法の改善に関する。

ＳＯＡは、「サービス指向アーキテクチャ」の略称であり、独立し相互に協調するサブシステムまたはサービスのセットからアプリケーションを構成可能であることを表す。このようなアーキテクチャは、あらゆるサービスを独立させ、宣言される必要のあるインターフェースのみを他のサービスに通知する。ＳＯＡは、システム構築者が設計済み製品における依存関係を整理し、弱めることができるようにするだけではなく、開発環境内に整ったサービス・スイートも提供する。この方法を使用すると、例えば企業アプリケーションの集合体などの既存の要件をサポートすること、および、例えば電子商取引関連ソリューションの迅速なカスタマイズなど特有の商業上のニーズを満たすようにプラットフォームを拡大するための基盤を提供することができる。

ＳＯＡの基本的な配信形態として、ウェブ・サービスが日々広く使用されている。いわゆるウェブ・サービスは、企業により、その特有の商業上のニーズを満たすために公開されるオンライン・アプリケーション・サービスであり、これらのオンライン・サービスは、他の会社、および協力パートナーのアプリケーションが、ネットワーク（インターネット、企業内ネットワーク、および企業外ネットワークなどを含む）を介してアクセスおよび利用できる。ウェブ・サービスは、企業におけるフロー統合の効果的なメカニズムとして商業的に利用されており、ＮａｓｄａｑおよびＡｕｓｔｒａｌｉａ Ｓｔｏｃｋ Ｅｘｃｈａｎｇｅ Ｓｙｓｔｅｍなどがウェブ・サービスを使用する周知の例である。実際ウェブ・サービスは、単純な要求から複雑な商取引まで、あらゆる機能を実行できる。

どのＳＯＡまたはウェブ・サービスも、サービス要求元（またはサービス・コンシューマと呼ばれる）、サービス・プロバイダ、およびサービス・レジストリという３つの役割を備えている。図１に示されているアーキテクチャ１００は、サービス要求元１１０、サービス・プロバイダ１２０、およびサービス・レジストリ１３０を含む。

これらの中で、サービス・プロバイダ１２０は、有用なサービスを構築してそれに関するサービス・メタデータを確立し、次に、サービス要求元が１つ以上のサービス・レジストリ１３０のサービス・メタデータを照会するよう、メタデータを１つ以上のサービス・レジストリ１３０に公開する役割を持っている。メタデータは、サービスの機能的記述、非機能的記述、ポリシー、および関連データなどを含むと思われる。

サービス・レジストリ１３０は、ＳＯＡに関与するサービスのメタデータ・リポジトリであり、サービス・プロバイダ１２０がそこに公開するサービス・メタデータを保持および公表する役割を持っており、ローカル・サービス・レジストリ１３０の所有するサービス記述の照会をサービス要求元１１０が実行できるようにする。先行技術のＳＯＡでは、サービス・レジストリ１３０が、サービス要求元とサービス・プロバイダとの間の対話プロセスに関与する必要はない。

さらに、サービス要求元１１０とサービス・プロバイダ１２０との間に、ゲートウェイ、企業サービス・バス（ＥＢＳ：ｅｎｔｅｒｐｒｉｓｅ ｓｅｒｖｉｃｅ ｂｕｓ）など（図示せず）の何らかの中継器（ｉｎｔｅｒｍｅｄｉａｔｏｒ）がさらに提供されることもある。これら中継器は、サービス要求元１１０とサービス・プロバイダ１２０との間の簡素な要求‐応答配信機能を有する。

図１はさらに、ＳＯＡでは、サービス要求元１１０、サービス・プロバイダ１２０およびサービス・レジストリ１３０の間に、公開、検索（ｆｉｎｄ）およびバインド（ｂｉｎｄ）という３つの動作が含まれることを示しており、これらの動作が、ＳＯＡのそれぞれの役割間の規約を定義する。

今まで、上述のＳＯＡまたはウェブ・サービス・システムでは、サービス・レジストリは、統一的記述、発見および統合（ＵＤＤＩ：Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｉｓｃｏｖｅｒｙ ＆ Ｉｎｔｅｇｒａｔｉｏｎ）標準しか用いることができなかった。サービス・レジストリの販売業者（ＩＢＭ、Ｍｉｃｒｏｓｏｆｔ、ＳＵＮ、ＢＥＡ、Ｓｙｓｔｉｎｅｔなど）はどれも、その製品においてＵＤＤＩ３．０をサポートしている。ＵＤＤＩはＯＡＳＩＳによって定義された標準であり、その焦点は、
１）ビジネス、組織およびその他ウェブ・サービス・プロバイダ、
２）利用可能なウェブ・サービス、および
３）ウェブ・サービスへのアクセスに使用できる技術的インターフェース
の記述および発見をサポートするサービス・セットを定義することである。

ＵＤＤＩは、業界標準の共通のセットに基づき、ウェブ・サービスを基盤としたコンピュータ環境の基礎的なインフラストラクチャを提供する。しかし、ＵＤＤＩ標準を使用することで、サービスの制御および共有の点で、ＳＯＡまたはウェブ・サービスに技術的な制限がもたらされる。一方、サービス・メタデータの制御および管理について、ＵＤＤＩ標準の使用には次の欠点がある。

１）照会用の拡張可能なデータ・モデルおよび方法の欠如―――固定された形式のサービス・メタデータは、さらなる機能またはサービス固有の特性を加える必要性に応じることができなかった
２）サービス・ライフサイクル管理の欠如
３）サービス呼び出し中の実行時制御の欠如―――これは、既存のＳＯＡの三角形のアーキテクチャにおいて、サービス・レジストリはサービスの静的構成プロセスでのみその役割を果たすが、サービス実行時間中のサービス要求元とサービス・プロバイダとの間（ゲートウェイまたはＥＢＳなどを含む）の動的対話プロセスには関与しないことが原因である
４）機能拡張用メカニズムの欠如

他方では、現在のウェブ・サービスの広範な使用に伴い、種々の標準（例えばＷＳＲＰ、ｕＰｎＰなど）に準拠し洗練さを増すサービスが出現すると共に、サービスの数が増えている。したがって、同じくサービス・レジストリの数も急速に増加する。この状況では、関連したＵＤＤＩレジストリ間での情報共有が、ウェブ・サービス技術の発展を促進するための緊急の要件となる。

ＵＤＤＩ規格の第３版の規定によれば、ＵＤＤＩレジストリ間での情報共有は、サービス・メタデータを複製すること、すなわち、インポート側がソース・レジストリからＵＤＤＩエンティティの全メタデータを得て、前記メタデータを目標レジストリ内に複製することによって実施される。ここでのインポート側とは、問い合わせＡＰＩまたはサブスクリプションＡＰＩを介して１つ以上のソース・レジストリからデータを読み出し、それを目標レジストリに公開するパブリッシャである。ＵＤＤＩにおいての情報共有に関する詳細情報については、ＵＤＤＩ Ｖｅｒｓｉｏｎ ３．０．２，ＵＤＤＩ Ｓｐｅｃ Ｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｔｔｅｅ Ｄｒａｆｔ，Ｄａｔｅｄ ２００４１０１９」を参照されたい。ＵＤＤＩレジストリ間でのサービス共有を複製によって実施するメカニズムには、次の欠点がある。

１）ＵＤＤＩレジストリのトポロジがインターネット・ドメインのものとは異なるため、すべてのインターネット自律システムにおいてサービス情報を操作することが難しい。
２）レジストリおよびＵＤＤＩエンティティの数が多くなるにつれ、１つのレジストリ内にすべてのエンティティの全メタデータを複製する記憶スペースが十分でなくなる。
３）エンティティの複製によって情報共有が実施された場合、異なるレジストリに登録されている同一エンティティの複製を同期させるメカニズムを欠く。
４）共有されるＵＤＤＩエンティティすべてを１つのＵＤＤＩレジストリに複製することはできないため、ＵＤＤＩクライアントは、目標のＵＤＤＩエンティティを探索するためにいくつかのＵＤＤＩレジストリに照会しなければならない。
５）レジストリの数が増え、ＵＤＤＩレジストリの一元化された位置情報がないため、クライアントがアクセス可能なレジストリすべてを検索してすべてを回るのは難しい（特に、計算能力および通信帯域幅が限られているクライアントに関して）。

上記の問題を考慮して、サービスの管理および共有に関する柔軟性および運用性が高まるよう、ＳＯＡまたはウェブ・サービスのサービス・レジストリを改善する必要がある。

したがって、本発明は、新たなサービス・レジストリ、サービス・レジストリを中心とするシステム・アーキテクチャ、サービスの伝搬および照会の方法、およびサービス呼び出し中のサービスの選択およびルーティングの方法を示す。本発明の根本的な概念は、サービス情報の分配されたインデックスおよび照会によりサービス・レジストリの機能を拡張することと、サービス・インデックスを（サービス・メタデータの代わりに）サービス・レジストリ間で複製することのみによってサービス共有を実現することと、サービス・レジストリをサービス要求元とサービス・プロバイダとの間の動的な実行中プロセスに関与させることによってサービスの実行時制御を実行することとにあり、それによって、ＵＤＤＩ標準の利用に起因する技術的な制限を打開する。

本発明の第１の態様によれば、ローカル・サービス・ドメインとリモート・サービス・レジストリとに接続されたサービス・レジストリが提供される。サービス・レジストリは、ローカル・サービス・ドメイン内のローカル・サービスを登録するローカル・サービス情報管理器と、ローカル・サービス情報管理器に接続され、ローカル・サービスのサービス・メタデータを記憶するローカル・サービス情報リポジトリとを備え、ローカル・サービス情報管理器とリモート・サービス・レジストリとに接続され、リモート・サービス・レジストリからリモート・サービス・インデックスを受信するリモート・サービス情報管理器と、前記リモート・サービス情報管理器に接続され、リモート・サービス・レジストリから受信されたリモート・サービス・インデックスを記憶するリモート・サービス情報リポジトリとを前記サービス・レジストリがさらに備えることを特徴とする。

本発明の第２の態様によれば、ＳＯＡフレームワークが提供される。ＳＯＡフレームワークは、上述のサービス・レジストリを含むメタ・サービス・ネットワークと、メタ・サービス・ネットワークと平行であり１つ以上のエンドポイントを含むサービス・ネットワークと、前記エンドポイント間に介在する１つ以上の中継器とを含む。前記１つ以上のエンドポイントは、直接かまたは前記１つ以上の中継器を介して、対応するサービス・レジストリと対話できる。

本発明の第３の態様によれば、サービス・レジストリ間でサービス情報を共有する方法が提供される。前記サービス・レジストリは、物理的または論理的に、あるいはその両方の形で相互接続されている。前記方法は、サービス・プロバイダのローカル・サービス・レジストリに前記サービス・プロバイダのサービス・メタデータを登録することと、前記ローカル・サービス・レジストリによって、前記サービス・メタデータ内のサービス・インデックスをリモート・サービス・レジストリへ伝搬することとを含む。

本発明の第４の態様によれば、サービス要求元が、サービス・レジストリのサービス情報を照会する方法が提供される。前記サービス・レジストリは、物理的または論理的に、あるいはその両方の形で相互接続されている。前記方法は、前記サービス要求元が、サービス情報についての問い合わせ要求をローカル・サービス・レジストリへ送信することと、前記サービス・レジストリが、１つ以上の目標リモート・サービス・レジストリに前記要求が届くまで、リモート・サービスのインデックスに基づき、関連する目標リモート・サービス・レジストリへ前記要求を転送することと、前記１つ以上の目標リモート・サービス・レジストリが、要求されたサービス・メタデータを、応答として前記ローカル・サービス・レジストリへ返送することと、前記ローカル・サービス・レジストリが、前記応答を前記サービス要求元へ送信することとを含む。

本発明の第５の態様によれば、サービス要求元がリモート・サービス・ドメイン内のサービスを呼び出す方法が提供される。前記方法は、前記サービス要求元が、リモート・サービス・ドメイン内のサービスを呼び出す要求を中継器へ送信し、中継器がローカル・サービス・レジストリへ要求を送信することと、前記ローカル・サービス・レジストリが、サービス・インデックスについて問い合わせることによってリモート・サービス・ドメインに要求を伝送することと、リモート・サービス・ドメインの中継器が、前記リモート・サービス・ドメインに関連したサービス・レジストリへ前記メッセージを送信することと、前記リモート・サービス・ドメインに関連したサービス・レジストリが、リモート・サービス・ドメインの中継器を介して前記サービス・プロバイダへ前記サービスを送信し、それによって前記サービス要求元に前記サービスを提供することとを含む。

本発明を使用することによって、サービス・レジストリに新たな効果および機能が与えられる。まず、各サービス・レジストリは、１つ以上の自律ドメイン（ａｕｔｏｎｏｍｏｕｓ ｄｏｍａｉｎ）を完全に制御できる。これは、サービス・レジストリの所有者（企業、組織または部門）にとって、サービス情報を保持するために便利である。次に、各サービス・レジストリは、ローカル・ドメイン内で静的および動的なサービス・メタデータ（ローカル・データおよびリモート・データ・インデックス）を管理する機能と、接続されているすべてのレジストリ内のサービス・メタデータについて問い合わせる機能と、サービス・ドメイン内またはサービス・ドメイン間で、サービス・レジストリを中心としてサービスの選択およびルーティングを実行する機能とを提供できる。

本発明を使用することによって、サービス・ルーティング用の機能モジュールを展開する拡張可能なメカニズムが提供される。これは、サービスのルーティングおよび選択のために、アプリケーション・サーバのような機能拡張メカニズムを実現するだけではなく、外部システム（例えば、課金、商業ルール、セキュリティ、監視など）との接続も達成する。

さらに、本発明を使用することによってドメイン間接続を実現できる。これは、主に次の３つの点に反映される。まず、本発明におけるサービス・ドメインのトポロジは、より自然であり、企業または組織のアプリケーション・ドメインにマッピングできるインターネット自律システムのトポロジに似ている。次に、本発明では、すべてのレジストリは、サービス・メタデータの複製ではなく、インデックスによって関連付けられる。最後に、すべてのサービス要求元および中継器（ＥＳＢ、ＷＳゲートウェイなど）は、ローカル・サービス・ドメイン外のサービスに関して情報を有する必要がない。

添付の図面では、同じ複合部品に同一または類似の参照符号が利用される。

本発明の原理が、添付の図面を参照して以下に説明される。

本発明による新規なサービス・レジストリについて説明する前に、まず、前記サービス・レジストリが適用されるシステムの全体的なトポロジを知る必要がある。図２がトポロジの概略図である。このトポロジは、メタ・サービス・プレーン（またはメタ・サービス・ネットワークと呼ばれる）１０５およびサービス・プレーン（またはサービス・ネットワークと呼ばれる）１０６を含む。メタ・サービス・プレーン１０５は、いくつかのサービス・レジストリ１０１を含み、サービス・レジストリ１０１間の接続線は、それらが物理的または論理的に、あるいはその両方の形で相互接続されていることを示す。サービス・プレーン１０６は、楕円で囲まれたいくつかのサービス・ドメインＤ１〜Ｄ４を含むとよい。各サービス・ドメインＤ１〜Ｄ４は、いくつかのエンドポイント１０３および中継器１０２をさらに含み、サービス・プレーン１０６は、サービス・ドメインを形成しない単一のエンドポイントまたは中継器（図２に示されている、サービス・ドメインＤ２とＤ３との間の単一の中継器１０２）あるいはその両方をさらに含んでもよい。なお、図２は具体例であり、サービス・レジストリ１０１、中継器１０２、エンドポイント１０３、およびサービス・ドメイン１０４などの実際の数および接続方法に対する制限として理解されるべきではない。

図２に示されているトポロジでは、各サービス・レジストリ１０１は、ローカル・サービス・ドメインでのサービスの登録および伝搬、ならびにローカル・サービス情報の動的な追跡を行う役割を持ち、クライアント・ソフトウェア開発者およびサービス要求元からのサービス照会要求（目標サービスのメタ情報を得るための拡張可能な照会機能）に応答する役割を持ち、中継器１０２との連携に基づきサービスの選択およびルーティングを行う役割を持つ。サービス・レジストリ１０１同士は対話し、すべてのサービス・レジストリを合わせてメタ・サービス・プレーンが形成される。サービス・レジストリは、アプリケーション・ドメインの状態に基づき、例えばスター型構造、完全なメッシュ構造、スーパーピア・ベース構造、純ピア・ツー・ピア構造など、複数のトポロジを有してもよい。なお、前記サービス・レジストリ間にどのトポロジおよび接続メカニズムが導入されるかは、本発明の実装に関連しない。

サービス・プレーン内の、サービス・ドメインＤ１〜Ｄ４はそれぞれ、特定のサービス・レジストリに登録されるウェブ・サービスの論理セットである。サービス・ドメインは、明確な境界を備えたドメイン（インターネット・ドメインなど）とすることも、明確な境界のないドメイン（インターネット・ドメインの一部など）とすることもできるであろう。各サービス・レジストリはサービス・ドメインに対応するとよく、これは、サービス・レジストリの「ローカル・サービス・ドメイン」と呼ばれる。

サービス・ドメインにおいて、各中継器１０２は、サービス・レジストリ内またはサービス・レジストリ間での情報の転送および変換に使用され、サービス要求元とサービス・プロバイダとの間のサービス・ルーティングの経路を提供する。企業サービス・バス（ＥＢＳ：Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）またはサービス・ゲートウェイなどの要素が、前記中継器としての機能を果たすことができる。

各エンドポイント１０３は、メッセージ・イニシエータまたは最終届け先であり、サービス要求元およびサービス・プロバイダを含めばよい。

接続されているエンドポイントおよび中継器すべてが、メタ・サービス・プレーン１０５に平行なサービス・プレーン１０６を形成する。

以下、図３を参照して、本発明によるサービス・レジストリ２００の基本構造を下記で説明する。図３において、サービス・レジストリ２００は、ローカル・サービス・ドメイン１０６およびリモート・サービス・レジストリ２００’に接続されている。当然のことながら、明瞭になるよう、図３は１つのリモート・サービス・レジストリ２００’のみを示しているが、実際にはサービス・レジストリ２００は任意の数のリモート・サービス・レジストリに接続可能である。さらに、サービス・レジストリ２００は、ローカル・サービス情報管理器２０１、ローカル・サービス情報リポジトリ２０２、リモート・サービス情報管理器２０３およびリモート・サービス情報リポジトリ２０４を備える。図３に示されている構造を使用することによって、ローカル・サービスの登録、伝搬および更新のプロセス、ならびにサービスの要求および呼び出しのプロセスを、サービス・レジストリ２００において実行できる。

ローカル・サービスの登録、伝搬および更新のプロセスについては、ローカル・サービス情報管理器２０１がローカル・サービス・ドメイン１０６内のサービス・プロバイダまたは管理ツールに接続されており、その結果サービス・プロバイダまたは管理ツールは、（例えばＡＰＩを介して）ローカル・サービス情報管理器２０１にサービスを登録できる。ローカル・サービス情報管理器２０１はさらに、ローカル・サービス情報リポジトリ２０２に接続されており、その結果、一方では、ローカル・サービス・ドメイン内の登録されたサービス・メタデータをローカル・サービス情報リポジトリ２０２に記憶し、他方では、直接または間接的にローカル・サービスの実時間状態の動的な追跡を行い、ローカル・サービスが変化すると、ローカル・サービス情報リポジトリ２０２内の関連するサービス・メタデータを更新する。さらに、ローカル・サービス情報管理器２０１は、リモート・サービス情報管理器２０３にローカル・サービス情報およびその変更（例えばサービスの状態の変更）を通知するためにリモート・サービス情報管理器２０３にさらに接続されており、その結果、ローカル・サービス情報およびその更新は、直接接続されているその他すべてのサービス・レジストリ２００’へ伝搬される。ローカル・サービス情報の伝搬中、ローカル・サービス情報管理器２０１は、サービス・インデックスとして機能するのに適した情報をローカル・サービス・メタデータから抽出する。

「サービス・メタデータ」は、サービスを記述するメタデータ、例えば、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ：ウェブ・サービス定義言語）ベースの記述（動作、メッセージ形式などを含む）などのサービス・インターフェース記述を含むサービスの機能的説明、サービスの非機能的記述（例えば、サービスの所有者――――ＩＢＭ、ＸＳＤ（ＸＭＬ Ｓｃｈｅｍａ ｄｅｆｉｎｉｔｉｏｎ：ＸＭＬスキーマ定義）、サービスの位置―――北京）、サービス・ポリシー（例えばセキュリティ、トランザクションおよび信頼性のポリシーなど、ＷＳ‐Ｐｏｌｉｃｙ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｐｏｌｉｃｙ：ウェブ・サービス・ポリシー）のような標準に基づくサービス・ポリシー記述など）、およびその他のメタデータである。

「インデックス」または「サービス・インデックス」という用語は、ローカル・サービス・レジストリに記憶される、リモート・サービスに関する情報である。例えば、サービス・レジストリ２００および２００’は、互いのリモート・サービス・レジストリとしての機能を果たす。サービス・レジストリ２００は、サービス・レジストリ２００’のサービスに関してはサービス・インデックスのみを（サービス・メタデータの代わりに）記憶する。サービス・レジストリ２００’も、サービス・レジストリ２００のサービスに関してはサービス・インデックスのみを記憶する。

以下詳しく説明するように、インデックスまたはサービス・インデックスとなるのに適したメタデータ情報は、次に限定されるものではないが、ＷＳＤＬ記述、非機能的記述におけるサービス所有者またはサービスの位置など、およびインデックスとなるのに適した、サービス・メタデータの属性名、属性範囲、サービスの最終ホップ・アドレス（ｌａｓｔ ｈｏｐ ａｄｄｒｅｓｓ）などを含む。さらに、サービス・インデックスとして機能するメタデータ情報は、ローカル・サービス情報管理器２０１によって抽出されること、同じく、その他の適切な方法によって抽出されること、または、サービス登録中にサービス・プロバイダによって指定されることが可能である。

図４Ａは、本発明によるサービス・インデックスの例示的なデータ構造を示し、これは、属性名／型２８０、属性範囲２８１および最終ホップのアドレス２８２という少なくとも３つのフィールドを含む。前記インデックス表には、必要に応じてその他任意の必要なフィールドをさらに含めることができるということが分かる。

表１は、一連のインデックス表項目を記録する。メタデータ項目をインデックス付けに使用することができる。

表１において、属性範囲フィールドは、範囲内の単一の属性値または複数の属性値とすることができる。最終ホップ・アドレスは、ローカル・サービス・レジストリに関して、インデックス値の伝搬経路においての、最後のサービス・レジストリのアドレスと、対応する中継器／エンドポイントのアドレスとを示す。

引き続き図３を参照すると、ローカル・サービス情報リポジトリ２０２は、ローカル・サービス・ドメイン内のサービス・プロバイダのサービス・メタデータおよびその更新を記憶するように、ローカル・サービス情報管理器２０１と接続されている。

リモート・サービス情報管理器２０３は、例えばローカル・サービス情報管理器２０１からのイベントがトリガされると接続ポリシーに従って接続されているリモート・サービス・レジストリ２００’へローカル・サービス情報を伝搬するよう、ローカル・サービス情報管理器２０１に接続されている。リモート・サービス情報管理器２０３は、一方では、リモート・サービス・レジストリ２００’から送信されるリモート・サービス・インデックスを受信し、それを別のリモート・サービス・レジストリへ伝搬するよう、他方ではローカル・サービスに関係のある抽出されたサービス・インデックスを例えばリモート・サービス・レジストリ２００’へ伝搬するよう、リモート・サービス・レジストリ２００’にさらに接続されている。さらに、リモート・サービス管理器２０３は、受信されたリモート・サービス・インデックスをリモート・サービス情報リポジトリ２０４に記憶するよう、リモート・サービス情報リポジトリ２０４にさらに接続されている。

リモート・サービス情報リポジトリ２０４は、リモート・サービス・レジストリ２００’から伝搬されたサービス・インデックスを記憶するために使用される。

サービスの照会および呼び出しのプロセスにおいて中継器からサービス要求元により実行されたサービス要求を受信するように、ローカル・サービス情報管理器２０１およびリモート・サービス情報管理器２０３は、ローカル・サービス・ドメイン１０６内の中継器と接続されている。

中継器から要求を受信するのに応答して、ローカル・サービス情報管理器２０１およびリモート・サービス情報管理器２０３はそれぞれ、ローカル・サービス情報リポジトリ２０２およびリモート・サービス情報リポジトリ２０４から、サービス要求を満たすサービス・メタデータと、サービス・インデックスとを抽出し、それらを中継器へ返す。なお、本発明がリモート・サービスの呼び出しを改善しようとする一方、ローカル・サービスを呼び出すプロセスは先行技術に属するため、本発明は全般的にリモート・サービスだけがサービス要求を満たし得ると想定する。

図４Ｂは、さらなる細部を含むサービス・レジストリ２００の構造図を示す。サービス・レジストリ２００は、図３に示された要素に加え、基本接続ポリシー・リポジトリ２０５、レグレット部分（ｒｅｇｌｅｔ ｐｏｒｔｉｏｎ）２１０、および照会処理器（ｑｕｅｒｙ ｈａｎｄｌｅｒ）２０９をさらに備える。

基本接続ポリシー・リポジトリ２０５は、サービス・ドメイン（サービス・レジストリ）間の接続を確立するための基本ポリシーの記述を記憶するよう、リモート・サービス情報管理器２０３と接続されており、これに基づいて、サービス・レジストリまたは中継器は、どれと情報を交換可能かを判断することが可能である。前記接続ポリシーは、サービス・レジストリが物理的に相互接続されているかどうか、物理的に接続されているサービス・レジストリについてはその間で論理的に情報を共有できるかどうか、および、特別なサービス・レジストリに関しては特別な情報を遮断することが論理的に必要かどうかを規定できる。当然のことながら、サービス・レジストリ間の接続ポリシーの規定は、ＳＯＡシステムの知能および運用性をさらに改善できる。しかし、実際にはサービス・レジストリは、いかなる接続ポリシーも記憶する必要がないように、固定された接続関係に従うこともできる。

点線の四角形で囲まれたレグレット部分は、サービス・レジストリの機能を拡張するための部分であり、参照符号２０７およびレグレット・コンテナ（ｒｅｇｌｅｔ ｃｏｎｔａｉｎｅｒ）２０６により一律に表されるいくつかのレグレットを含む。

レグレット２０７は、サービスの選択およびルーティングの機能を容易に実行できるようにする任意の静的または動的なレグレットを含めばよい。例えば、それらは、サービス・レジストリ内に含まれるレグレットとすることも、外部システム２０８との対話によって実現されるレグレットとすることもできる（以下で説明されるとおり）。レグレット２０７は、ローカル・サービス・ドメインからサービス・ルーティング要求を受信し、特定の接続ポリシー（例えば、基本接続ポリシー・リポジトリ２０５内に記憶されているポリシーなど）に基づきローカル・サービス・ドメインへルーティング応答を返すことができる。レグレット２０７は、サービスの選択およびルーティング用の論理を実装することができるであろう。

前記レグレット２０７は、レグレット・コンテナ２０６内に展開され、そこにリストまたはメッシュを形成する。レグレット・コンテナ２０６は、レグレット２０７に実行時環境情報および文脈情報を提供する。例えば、実行時間中、レグレット・コンテナ２０６は、メッセージのソースおよび目標の情報を含んだ要求を中継器から受信する。その後、レグレット・コンテナ２０６は、基本接続ポリシーを照会し、サービスの選択およびルーティング用に関係のあるレグレット２０７をすべて呼び出す。最後に、レグレット・コンテナ２０６は、次ホップ・アドレス（ｎｅｘｔ ｈｏｐ ａｄｄｒｅｓｓ）を含んだ応答を返す。

外部システム２０８は、レグレット部分２１０と接続されており、サービスの選択およびルーティングの情報を提供することが可能であり、レグレット部分２１０（例えばレグレット２０７）からの情報を利用することも可能である。レグレット２０７は、関連する外部システム２０８の入り口を提供する。外部システム２０８の例には、次に限定されるものではないが、グローバル・セキュリティ・ポリシー用のセキュリティ・システム、商業用サービスの課金システム、ＱｏＳ用のネットワーク・トラフィック・システム、データ・マイニングおよび意思決定のための統計情報を必要とするＢＩシステム、サービス選択に基づくビジネス契約用のビジネス・ルール・システムなどが含まれる。

照会処理器２０９は、ローカル・サービス・レジストリに対する照会要求を処理するよう、ローカル・サービス情報管理器２０１およびリモート・サービス情報管理器２０３に接続されている。照会処理器２０９は、次の２つのモードで動作する。第１のモードでは、ローカル・サービス・ドメインからの要求が受信されると、照会処理器２０９はローカル・サービス情報管理器２０１およびリモート・サービス情報管理器２０３の両方にサービスを見つけるよう要求し、サービス要求元へ応答を送信する。第２のモードでは、他のレジストリからの要求が受信されると、照会処理器２０９はローカル・サービス情報管理器２０１に要求し、ローカル・サービス情報をサービス要求元へ返す。

本発明によるサービス登録、伝搬および照会のプロセスについて、図５Ａ、図５Ｂおよび図５Ｃを参照して以下で説明する。

サービス・レジストリによるローカル・サービスの登録および伝搬のプロセス
図５Ａにおいて、サービス・ドメインＮ内のサービス・プロバイダ９が、そのローカル・サービス・レジストリ５に登録され他のサービス・レジストリと共有されるべき新たなサービスを有すると仮定する。したがって、回線１．１（または１．１’）で、サービス・プロバイダ９のサービスが、そのサービス・レジストリ５に登録される。この登録は、異なる方法で実施することもできる。例えば、サービス・プロバイダもしくはサード・パーティがサービス・レジストリ５への登録を実行する（回線１．１が示すように）、または、サービス・レジストリ５がサービスを自動的に発見する（回線１．１’が示すように）などである。その後、回線１．２で、サービス・レジストリ５が、例えば、基本接続ポリシーに基づき、サービス・レジストリ５と接続されたリモート・サービス・レジストリへローカル・サービス・インデックスを伝搬する。

図５Ｂは例示的な伝搬経路であり、回線１．２の詳細を示す。図５Ｂにおいて、四角形は、参照符号１〜６により表されるサービス・レジストリを含んだメタ・サービス・プレーンを表す。例えばサービス・レジストリ１と２との間の実線は、サービス・インデックスが、サービス・レジストリ１からサービス・レジストリ２へ論理的に伝搬可能であることを表し、一方、例えばサービス・レジストリ２と３との間の点線は、サービス・インデックスがサービス・レジストリ２からサービス・レジストリ３へ論理的に伝搬可能でないことを表す。図５Ｂにおいて、サービス・プロバイダ９のサービスは、サービス・レジストリ５に登録され、リモート・サービス・レジストリ１〜４へ伝搬可能である。一例として、サービス・レジストリ５、３、１による伝搬のプロセスを挙げると、サービス・レジストリ３は、最終ホップ・アドレスがサービス・レジストリ５であると示すインデックスを受信し、一方、サービス・レジストリ１は、最終ホップ・アドレスがサービス・レジストリ３であると示すインデックスを受信する。

サービス要求元によるサービス・メタデータ要求プロセス
引き続き図５Ａを参照し、サービス・ドメイン１内のサービス要求元８が、特定のパラメータ（例えば最短サービス時間、最低サービス料など）を用いて、そのローカル・サービス・レジストリに、すべての利用可能なサービスについて照会すると仮定する。したがって、サービス要求元８は回線２．１で、サービス・レジストリ１へ照会要求を送信する。次に、サービス・レジストリ１は回線２．２で、インデックス表（および場合により所定の基本接続ルール）に基づき、要求を次ホップのサービス・レジストリに転送する。このステップが、関係のあるサービス・レジストリにおいて繰り返される。

図５Ｃは、回線２．２上の詳細な経路照会の例を示す。図５Ｃでは、図５Ｂのメタ・サービス・プレーンと同じメタ・サービス・プレーンが使用されている。照会要求を受信した後、サービス・レジストリ１は、要求を満たすサービス・インデックス内の最終ホップ・アドレスがサービス・レジストリ３である（つまり、サービス・インデックスがサービス・レジストリ３によって伝搬されている）ことを検出すると、次ホップにあるサービス・レジストリへ要求を転送することを決定する。その後、サービス・レジストリ３は、サービス・レジストリ１と同じ方法を使用して、次ホップにあるサービス・レジストリ５へ要求を転送することを決定する。サービス・レジストリ５が正に、要求を満たすサービス・インデックスが登録されているサービス・レジストリであると仮定する。その結果、動作は図５Ａの回線２．３に入る。

図５Ａ内の回線２．３でサービス・レジストリ５は、要求されたサービス・メタデータを、要求が転送される経路に沿ってサービス・レジストリ１へ送信する。最後に、応答を受信すると、サービス・レジストリは回線２．４で、応答をそのサービス要求元へ送信する。

本発明によるサービス呼び出し中のメッセージ伝送ルーティングおよび選択のプロセスについて、図６Ａおよび図６Ｂを参照して以下で説明する。明瞭にするため、図６Ｂでは、サービス・レジストリ間の接続、図６Ａに示されているプロセスに関係のあるエンドポイントと中継器との間の接続、およびそれらのサービス・レジストリとの接続は実線で表され、その他は点線で表される。さらに、二方向の矢印の左側にある参照番号は、中継器からサービス・レジストリへのアップリンク回線を表し、右側にある参照番号は、サービス・レジストリから中継器へのダウンリンク回線を表す。

図６Ａおよび図６Ｂにおいて、サービス・ドメインＤ１内のサービス要求元Ａが、サービス・ドメインＤ３内のサービス・プロバイダＧのサービスを取得することを求めると仮定する。したがって、回線３．１において、サービス・ドメインＤ１内のサービス要求元Ａがメッセージを中継器Ｂへ送信する。メッセージの目標アドレスは、サービス・ドメインＤ３内のサービス・プロバイダＧである。次に、中継器Ｂは回線３．２で、そのサービス・レジストリ１へルーティング要求を送信する。その後、サービス・レジストリ１は回線３．３で、サービス・インデックスの照会を行うことによって、要求のあて先である次ホップ・アドレス中継器（例えば、中継器Ｃ）を判断する。次に、サービス・レジストリ１は、中継器Ｂに次ホップ・アドレスを通知する。結果として、回線３．４で、中継器Ｂは中継器Ｃへメッセージを送信する。

本発明によれば、回線３．４は、メッセージが目標サービス・ドメインＤ３内の中継器Ｆに届くまでの中継器とサービス・レジストリとの間の一連の動作を含むとよい。回線３．４での具体的な動作について、図６Ｂを参照して以下で説明する。

回線３．４‐０で、中継器Ｂは、サービス・レジストリ１により返されたアドレスに基づき、要求を中継器Ｃへさらに送信する。次に、中継器Ｃは、要求の次ホップ・アドレス（例えば、異なるサービス・ドメインＤ４内の中継器Ｄ）を判断するよう、アップリンク回線３．４‐１を介して引き続きローカル・サービス・レジストリ１に照会する。要求の次ホップ・アドレスが、ダウンリンク回線３．４‐２を介して中継器Ｃへ返される。その後、中継器Ｃは、回線３．４‐３を介して中継器Ｄへ要求をさらに送信する。この段階で、中継器Ｄは、そのローカル・サービス・レジストリ５にアップリンク回線３．４‐４を介して照会を行う。サービス・レジストリ５は、要求の次ホップ・アドレス（例えば中継器Ｅなど）を判断すると、それをダウンリンク回線３．４‐５を介して中継器Ｄへ返す。その後、中継器Ｄは、要求を中継器Ｅへ送信し（回線３．４‐６）、中継器Ｅは、要求をそのローカル・サービス・レジストリ４へ送信する（回線３．４‐７）。サービス・レジストリ４は、次ホップ・アドレス（例えば中継器Ｆなど）を判断すると、それをダウンリンク回線３．４‐８を介して中継器Ｅへ返す。次に、中継器Ｅは、回線３．４‐９を介して目標サービス・ドメインＤ３内の中継器Ｆへ要求を送信する。そこで回線３．４での動作が完了する。その後のプロセスについて、図６Ａを参照して以下で引き続き説明する。

回線３．５が示すように、中継器Ｆはルーティング要求をサービス・レジストリ６へ送信し、その結果サービス・レジストリ６は、サービス・ドメインＤ３内の目標サービスを選択する。次に、中継器Ｆは、回線３．６で目標サービスのアドレスおよびメタデータを受信し、サービス・メッセージを適切な形式に変換する。さらに回線３．７で、中継器Ｆはサービス・プロバイダへメッセージを送信する。最後に、回線３．８が示すように、サービス・プロバイダＧは、サービスをサービス要求元Ａに提供する。

目標サービス・プロバイダＧは、多様な方法でサービス要求元Ａにサービスを提供する。例えば、サービス・プロバイダＧは、要求が伝送された方向に対して厳密に逆の方向で（すなわち、関連したすべての中継器およびサービス・レジストリを介して）サービス要求元Ａにサービスを提供することもできるであろうし、要求が伝送された方向に対し逆の方向であるが、サービス・プレーン内の中継器のみを介して（すなわち、サービス・レジストリを省略して）サービス要求元Ａにサービスを提供することも同じくできるであろう。当業者には周知のとおり、サービス・プロバイダＧは、他の方法を使用してサービスをサービス要求元Ａへ伝送することもできるが、本発明ではそれらを１つずつ記載はしない。

図７は、本発明による、サービス・レジストリによるサービスの登録および伝搬の方法を示す流れ図である。

この方法はステップ６００で開始し、次にステップ６１０へ進む。ステップ６１０において、サービス・プロバイダのサービス・メタデータが、そのローカル・サービス・レジストリに登録される。その後、ステップ６２０で、前記サービス・レジストリが、リモート・サービス・レジストリにサービス・インデックスを通知する。この方法は、ステップ６３０で終了する。

図８は、本発明による、サービス要求元によりローカル・サービス・レジストリに対してサービス・メタデータを照会する方法を示す。なお、本発明は主として、リモート・サービスの照会における改善に関係しており、結果的に、ローカル・サービス・メタデータを照会するケースは無視される。

この方法は、ステップ７００で開始し、次にステップ７１０へ進む。ステップ７１０において、サービス要求元は、サービス・メタデータ照会要求をローカル・サービス・レジストリへ送信し、例えば、特定の要件を満たす（例えばサービスの位置が「北京」であるなど）サービスを要求する。ステップ７２０で、前記サービス・レジストリは、リモート・サービス情報管理器によって保持されているサービス・インデックス表に照会を行うことによって、要件を満たすサービス・インデックスを検索し、インデックスにしたがって、次ホップのリモート・サービス・レジストリへ要求を転送する。続いて、サービス・インデックス内のサービスが属するリモート・サービス・レジストリに要求が転送されるまで、ステップ７２０における動作が繰り返される。その後、ステップ７３０で目標リモート・サービス・レジストリは、要求が伝送された経路に沿って、要求されたサービスのメタデータを応答として前記ローカル・サービス・レジストリへ返送する。さらに、ステップ７４０で、ローカル・サービス・レジストリは前記応答を前記サービス要求元に送信する。最後に、この方法はステップ７５０で終了する。

図９Ａは、本発明による、サービスのルーティングおよび選択の方法を示す。同じく、本発明は主として、リモート・サービス呼び出しにおける改善に関係するため、ローカル・サービスを呼び出すケースは無視される。

この方法は、ステップ８００で開始し、次にステップ８１０へ進む。ステップ８１０で、サービス要求元は、目標サービス・ドメイン内のサービスに関係のあるメッセージを中継器へ送信し、中継器は、それをさらにローカル・サービス・レジストリへ送信する。その後、ステップ８２０でローカル・サービス・レジストリは、目標サービス・ドメインのリモート・サービス・インデックスを照会することによって、目標サービス・ドメインに要求を届ける。ステップ８３０で、目標サービス・ドメイン内の中継器が、それに関連するサービス・レジストリへ前記メッセージを送信する。その後、目標サービス・ドメインに関連するサービス・レジストリが適切なサービスを選択し、それを目標ドメイン内の中継器を介して目標サービス・プロバイダへ送信し、その結果、ステップ８５０で、サービスがサービス要求元に提供される。最後に、この方法はステップ８６０で終了する。

図８に示されているステップ８２０では、図６Ａおよび図６Ｂに示されているように、複数のホップを介して目標サービス・ドメインに要求が転送される必要があることもある。

さらに、本発明の好適な実施形態によれば、レグレット部分を使用することによって、図９Ａに示されているサービス呼び出しプロセスの機能拡張を実行することができる。例えば、外部システムとの対話によってサービス要求に対し請求を行うレグレットを使用することによって、サービス呼び出しに対して請求することができる。この場合、ステップ８２０は、図９Ｂに示されている動作をさらに含む。

ステップ８２１で、ローカル・サービス・レジストリのレグレット部分は、サービス要求元から要求を受信する。ステップ８２２で、レグレット・コンテナは、一方では基本接続ポリシー・リポジトリから接続ポリシーを探索し、他方では、対応する請求レグレット（ｃｈａｒｇｉｎｇ ｒｅｇｌｅｔ）を呼び出す。ステップ８２３で、請求レグレットは、例えば請求に使用される対応する外部システムに接続することによって、サービス呼び出し要求の請求プロセスを実行する。その後、ステップ８２４で、請求が行われ特定の接続ポリシーを有する呼び出し要求が、ローカルおよびリモートのサービス情報管理器へ送信される。その結果、ステップ８２５で、ローカルおよびリモートのサービス情報管理器が、ステップ８２４に基づきサービス・インデックスの照会を続けることが可能であり、したがって、次ホップ・アドレス中継器が取得され、ステップ８２６でレグレット・コンテナを介して中継器へ返される。続いて、図９Ａに示されているその後のプロセスが、引き続き実行される。

上記の説明によれば、本発明は、サービス・レジストリ間でサービス・インデックスのみを（サービス・メタデータの代わりに）渡すことによって、ＵＤＤＩ標準の使用に由来する先行技術のＳＯＡまたはウェブ・サービスの制限を改善する。

さらに、当業者であれば当然のことであるが、本発明の実施形態は、方法、システムまたはコンピュータ・プログラム製品の形で提供できる。したがって、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはハードウェアとソフトウェアとの組み合わせの実施形態の形を採用できる。ハードウェアとソフトウェアとの典型的な組み合わせは、プログラムが読み込まれ実行されると、コンピュータ・システムを制御することによって上記の方法を実行可能である、コンピュータ・プログラムを備えた汎用コンピュータ・システムとすることができる。

本発明は、説明された方法を実施できるようにするすべての機能を含むコンピュータ・プログラム製品中に組み込まれることが可能である。前記コンピュータ・プログラム製品は、１つ以上のコンピュータ可読記憶媒体（次に限定されないが、ディスク記憶装置、ＣＤ−ＲＯＭ、光メモリなどを含む）に含まれ、前記コンピュータ可読記憶媒体内には、コンピュータ可読コードが含まれる。

上記では、本発明による方法、システムおよびコンピュータ・プログラム製品の流れ図またはブロック図、あるいはその両方を参照して本発明について説明している。当然のことながら、流れ図またはブロック図、あるいはその両方の中の各ブロック、およびその中の複数ブロックの組み合わせは、コンピュータ・プログラム・コマンドによって実現可能である。コマンドが（コンピュータのプロセッサまたは他のプログラマブル・データ処理デバイスによって）、流れ図またはブロック図、あるいはその両方で１つ以上のブロックに特定された機能を実現する装置をつくりだすように、これらのコンピュータ・プログラム・コマンドを、機械がつくり出されるよう汎用コンピュータのプロセッサ、専用コンピュータ、組み込みプロセッサ、またはその他のプログラマブル・データ処理デバイスに提供することが可能である。

これらのコンピュータ・プログラム・コマンドは、１つ以上のコンピュータの読み出し用メモリに記憶することもでき、各読み出し用メモリは、コンピュータまたはその他のプログラマブル・データ処理デバイスに、指定されたモードに従い機能するよう命令することができる。このようにして、コンピュータの読み出し用メモリに記憶されたコマンドは、流れ図またはブロック図、あるいはその両方の中の１つ以上のブロック内に特定された機能を実現する命令手段を含む工業製品をつくる。

コンピュータ・プログラム・コマンドは、前記コンピュータまたはその他のプログラマブル・データ処理デバイス上で一連の動作ステップを実行するように、１つ以上の前記コンピュータ、またはその他のプログラマブル・データ処理デバイスに読み込まれることも可能であり、そうすることで、コンピュータに実装されたプロセスをこれらデバイスのそれぞれにおいて実現できる。このようにして、これらのデバイス上で実行されるコマンドは、流れ図またはブロック図、あるいはその両方の中の１つ以上のブロック内に特定されたステップを提供する。

本発明を実施する好適な形態を参照しながら、本発明の原理について上記で説明した。しかし、これらの説明は具体例でしかなく、本発明に対するいかなる制限としても理解されてはならない。当業者であれば、同封の特許請求の範囲により定義される範囲から逸脱することなく、本発明を修正し、変形することができる。

先行技術のＳＯＡフレームワークの概略図である。 本発明によるサービス・レジストリを中心としたシステムのトポロジの概略図である。 本発明によるサービス・レジストリの基本構造である。 図４Ａは、本発明によるサービス・インデックスの例示的なデータ構造を示し、図４Ｂは、さらなる細部を含むサービス・レジストリの構造図を示す。 図５Ａは、本発明による、登録、伝搬、サービスについての問い合わせの組み合わせプロセスを示し、図５Ｂは例示的な伝搬経路を示し、図５Ｃは例示的な照会経路を示す。 図６Ａは、本発明による、サービス呼び出し中のメッセージ伝送ルーティングおよび選択のプロセスを示しており、図６Ｂは、図２のトポロジを基準にした図６Ａ内のプロセスの実行を示す概略図である。 本発明による、サービス・レジストリがサービスを登録および伝搬する方法を示す流れ図である。 本発明による、サービス要求元がローカル・サービス・レジストリのサービス・メタデータを照会する方法を示す。 図９Ａは、本発明による、サービスのルーティングおよび選択を実行する方法を示し、図９Ｂは、本発明の好適な実施形態による、サービスのルーティングおよび選択を実行する方法を示す。

Claims (13)

1. ローカル・サービス・ドメインと、リモート・サービス・レジストリとに接続されたサービス・レジストリであって、
   前記ローカル・サービス・ドメイン内のローカル・サービスを登録するローカル・サービス情報管理器と、
   前記ローカル・サービス情報管理器に接続され、前記ローカル・サービスのサービス・メタデータを記憶するローカル・サービス情報リポジトリと、
   を備え、前記サービス・レジストリが、
   前記ローカル・サービス情報管理器と、前記リモート・サービス・レジストリとに接続され、前記リモート・サービス・レジストリからリモート・サービス・インデックスを受信するリモート・サービス情報管理器と、
   前記リモート・サービス情報管理器に接続され、前記リモート・サービス・レジストリから受信された前記リモート・サービス・インデックスを記憶するリモート・サービス情報リポジトリと、
   をさらに備えることを特徴とする、サービス・レジストリ。
2. 前記ローカル・サービス情報管理器は、前記ローカル・サービスの実時間状態を動的に追跡し、前記ローカル・サービスにおける変化に応答して前記ローカル・サービス情報リポジトリを更新する手段をさらに備える、請求項１に記載のサービス・レジストリ。
3. 前記ローカル・サービス情報管理器は、前記ローカル・サービスのサービス・メタデータ内のサービス・インデックスと、その更新とを、前記リモート・サービス情報管理器へ伝送する手段をさらに備え、前記リモート・サービス情報管理器は、前記ローカル・サービスの前記サービス・メタデータ内の前記サービス・インデックスと、その前記更新とを、前記リモート・サービス・レジストリへ伝搬する手段をさらに備える、請求項１または２に記載のサービス・レジストリ。
4. 前記リモート・サービス情報管理器は、前記ローカル・サービス・ドメイン内の中継器にさらに接続されており、リモート・サービス・ドメイン内の特定のサービスを呼び出すためにサービス要求元によって実行された要求を前記中継器から受信し、前記要求が転送されるべき次ホップ中継器のアドレスを、前記特定のサービスのサービス・インデックスに従って取得し、前記要求を前記中継器へ返す手段を備える、請求項１に記載のサービス・レジストリ。
5. 前記ローカル・サービス情報管理器または前記リモート・サービス情報管理器、あるいはその両方へ前記中継器からの前記要求が送信される前に、前記要求に対応するレグレット機能を実行するよう、前記ローカル・サービス情報管理器または前記リモート・サービス情報管理器、あるいはその両方に接続されたレグレット部分
   をさらに備える、請求項４に記載のサービス・レジストリ。
6. 前記レグレット部分は、１つ以上のレグレットと、レグレット・コンテナとを備え、
   前記レグレット・コンテナは、前記レグレットに実行時環境情報および文脈情報を提供し、前記中継器から前記要求を受信し、基本ポリシーを照会して関係のあるすべてのレグレットを呼び出し、さらにサービス・インデックス情報を前記中継器へ返すために使用され、
   前記１つ以上のレグレットは、前記中継器から受信される前記サービス要求の前記対応するレグレット機能を実行し、続いて、前記ローカル・サービス情報管理器または前記リモート・サービス情報管理器、あるいはその両方に前記サービス要求を提供するよう、前記レグレット・コンテナに関連付けられている、
   請求項５に記載のサービス・レジストリ。
7. 前記レグレット部分は、外部システムにさらに接続されており、前記外部システムにとっての前記サービス・レジストリへの入り口として使用され、前記外部システムは、グローバル・セキュリティ・ポリシー用のセキュリティ・システム、商業用サービスの課金システム、ＱｏＳ用のネットワーク・トラフィック・システム、データ・マイニングおよび意思決定のための統計情報を必要とするＢＩシステム、サービス選択に基づくビジネス契約用のビジネス・ルール・システムのうち、少なくとも１つを備える、請求項６に記載のサービス・レジストリ。
8. 前記リモート・サービス情報管理器に接続され、前記サービス・レジストリ間で確立された接続の基本ポリシーの記述を記憶する基本接続ポリシー・リポジトリ
   をさらに備える、請求項１に記載のサービス・レジストリ。
9. 前記ローカル・サービス情報管理器またはリモート・サービス・インデックス管理器、あるいはその両方に接続され、前記サービス・レジストリに対するサービス情報照会要求を処理する照会処理器をさらに備える、請求項１に記載のサービス・レジストリ。
10. 前記照会処理器は、以下の２つの動作モードを有し、
    第１のモードでは、ローカル・サービス・ドメインからの前記サービス情報照会要求が受信されると、前記ローカル・サービス情報管理器または前記リモート・サービス・インデックス管理器、あるいはその両方に、前記サービスを見つけるよう要求して、前記サービス要求元へ応答を送信し、
    第２のモードでは、前記リモート・サービス・レジストリからの要求が受信されると、前記ローカル・サービス情報管理器に要求し、前記ローカル・サービス情報を前記リモート・サービス・レジストリへ返す、
    請求項９に記載のサービス・レジストリ。
11. 前記ローカル・サービス情報管理器は、前記ローカル・サービスのサービス・メタデータからサービス・インデックスを抽出する手段をさらに備える、請求項１０に記載のサービス・レジストリ。
12. サービス・レジストリ間で情報を共有する方法において、
    ローカル・サービス・ドメインと、リモート・サービス・レジストリとに接続されたサービス・レジストリであって、（１）前記ローカル・サービス・ドメイン内のローカル・サービスを登録するローカル・サービス情報管理器と、（２）前記ローカル・サービス情報管理器に接続され、前記ローカル・サービスのサービス・メタデータを記憶するローカル・サービス情報リポジトリとを備える、前記サービス・レジストリにおいて、前記方法は、
    前記ローカル・サービス情報管理器と、前記リモート・サービス・レジストリとに接続された、リモート・サービス情報管理器が、前記リモート・サービス・レジストリからリモート・サービス・インデックスを受信するステップと、
    前記リモート・サービス情報管理器に接続された、リモート・サービス情報リポジトリが、前記リモート・サービス・レジストリから受信された前記リモート・サービス・インデックスを記憶するステップと、
    を含むことを特徴とする、前記方法。
13. サービス・レジストリ間で情報を共有するためのコンピュータ・プログラムにおいて、前記コンピュータ・プログラムは、コンピュータを、
    ローカル・サービス・ドメインと、リモート・サービス・レジストリとに接続されたサービス・レジストリであって、
    前記ローカル・サービス・ドメイン内のローカル・サービスを登録するローカル・サービス情報管理器と、及び、
    前記ローカル・サービス情報管理器に接続され、前記ローカル・サービスのサービス・メタデータを記憶するローカル・サービス情報リポジトリと、
    を備える、前記サービス・レジストリ、
    前記ローカル・サービス情報管理器と、前記リモート・サービス・レジストリとに接続され、前記リモート・サービス・レジストリからリモート・サービス・インデックスを受信するリモート・サービス情報管理器、及び、
    前記リモート・サービス情報管理器に接続され、前記リモート・サービス・レジストリから受信された前記リモート・サービス・インデックスを記憶するリモート・サービス情報リポジトリ、としてそれぞれ動作させる、
    ことを特徴とする、前記コンピュータ・プログラム。

Images