JP2013541069A - サービス・レジストリからのサービス展開のための方法、サービス・レジストリ、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】この実施形態は、サービス指向アーキテクチャ（ＳＯＡ）に合致するシステム内でのサービス・ベースの展開のための方法、システム、およびコンピュータ・プログラムに関する。
【解決手段】特に、これは、サービス指向アーキテクチャ・システム内でサービスを提供するためのシステム内のサービス・レジストリにより動作可能である方法、システム、およびコンピュータ・プログラムに関する。この方法は、このシステムにおいてサービス要求側からサービスの要求を受信するステップと、サービス・レジストリに登録されているサービスのステータスを調べるステップと、を含み、サービスが登録されたサービス・エンドポイントを有しないか、またはサービスの特性が既定の閾値未満であることに応答して、１つ以上のサービス・プロバイダまたは以降のサービス・レジストリに新しいサービスを提供する要求を送信し、既定の閾値に従うことと、サービス・プロバイダが既定の標準に従って新しいサービスを提供することに応答して、サービス・レジストリを新しいサービスによって更新して、サービスが利用可能であることをサービス要求側に応答することと、によって特徴付けられる。実施形態によって、要求側とプロバイダとの間の直接インタラクションおよびサービス管理レイヤを介した間接インタラクションの双方が可能となる。また、実施形態によって、サービス・プロバイダを仮想サーバとして提供可能となり、サービスを仮想アプリケーションとして提供可能となる。
【選択図】図４

Description

本発明は、サービス指向アーキテクチャ（ＳＯＡ：service oriented architecture）に基づいたシステム内でのサービスに基づいた展開のための方法および装置に関する。特に、これは、サービス・レジストリからサービス・エンドポイントの位置を特定するための方法および装置に関する。

サービス指向アーキテクチャ（ＳＯＡ）は、ビジネス主導ＩＴアーキテクチャ手法であり、ビジネス・プロセスの統合を、リンクされた反復可能なビジネス・タスクとして、またはサービス文書に規定されたサービスとしてサポートする。サービス文書はＳＯＡの基本的な構築ブロックであり、どのようにサービスを他のサービスと共に使用、アクセス、および管理可能であるかを規定する。サービス文書は、ＳＯＡライフ・サイクルの開発段階中に分析者、設計者、および開発者によって用いられて、再使用するサービスの位置を特定し、サービス・コンフィギュレーションに対する変更の影響を評価する。サービス文書は、メタデータ、オブジェクト、記述、エンティティ、およびアーチファクトとして様々に記述され、サービス記述およびサービス・エンドポイントを含むサービスに関する情報を保存する。サービス・エンドポイントは、サービスのための一意のコンピュータ・アドレス指定可能位置である。サービス文書は、ＳＯＡシステム内のサービス・レジストリに記憶される。サービス・エンドポイントを含む各サービス文書における情報は、シュレッディング（shredding）として知られるプロセスにおいてインデックスされる。全てのサービスおよびサービス・エンドポイントのリストを維持するためにサービス文書にインデックスすることは、オン・デマンド・サービスを維持することの一部である。サービス・レジストリの一例は、ＩＢＭ（Ｒ）ＷｅｂＳｐｈｅｒｅ（Ｒ）Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ ＆ Ｒｅｐｏｓｉｔｏｒｙである。レジストリは、サービス要求をルーティングするためにいくつかのエンドポイントが利用可能であることを強調することができる。要求が来ると、レジストリは、利用可能なサービス・アーキテクチャ・トポロジの知識を用いて、要求されたサービスが利用可能でないかまたは同意されたサービス・レベルに関する合意(service level agreement)以下で実行されていることを示す。ＩＢＭ及びＷｅｂＳｐｈｅｒｅは、世界中の多くの管轄区域で登録されたインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である。

米国特許第７，１７１，４７０Ｂ２号

登録されたサービス・エンドポイントを有するインストール済みのサービスは呼び出すことができるが、登録されたエンドポイントを有しないサービスを呼び出すことはできない。サービスは、サービス・プロバイダにおいてインストールされる際に、固定のまたは容易に利用可能なサービス・エンドポイントがサービス文書に規定されサービス・レジストリによってインデックスされている。しかしながら、多くのサービス・プロバイダは、固定のリソースを有し、低需要サービスよりも高需要サービスを優先させなければならない。従って、全てのサービスが同時に利用可能であるわけではない。

低需要サービスは、サービス・プロバイダからアンインストールし、サービス・プロバイダのアクティブなサービスから除去することができる。このサービスに関連付けられたいかなるサービス・エンドポイントもレジストリによって除去され、サービスはアーカイブされて、新しいサービス・エンドポイントを用いた再インストールおよびセットアップが必要であるようになっている。カスタマが、アンインストールされたサービスを要求し、サービスにおいて遅延または差異を経験しないことが有用であろう。低需要のまたはアンインストールされたサービスは、時として、レガシーまたは利用不足のサービスと称される場合がある。

サービス・プロバイダは、アンインストールの代わりに、低需要サービスの処理優先度を下げるか、または他の何らかの方法で低需要サービスに与える処理帯域幅を狭くする場合がある。これによって、サービス要求側が経験するサービス品質が低下し、サービス要求側の求めたサービスでないものになってしまう恐れがある。場合によっては、この品質低下はサービス契約の条項に反するものである。要求されたサービスの処理優先度が低下し、再度コンフィギュレーションを行う必要があった場合であっても、サービス要求側が所望の品質のサービスを受け、サービス品質の遅延または差異を経験しないことが有用であろう。

２００７年１月３０日の米国特許第７，１７１，４７０Ｂ２号（Ｄｏｙｌｅ，Ｒ．Ｐ．等の「Ｇｒｉｄ Ｓｅｒｖｉｃｅ Ｓｃｈｅｄｕｌｉｎｇ ｏｆ Ｒｅｌａｔｅｄ Ｓｅｒｖｉｃｅｓ ｕｓｉｎｇ Ｈｅｕｒｉｓｔｉｃｓ」は、要求されたトランザクションの少なくとも一部を処理するためにコンピューティング・グリッドにおいてサービス・インスタンスをスケジューリングする方法およびシステムを開示する。

従って、当技術分野において、前述の問題に対処することが必要とされている。

本発明の第１の態様によれば、請求項１から１０に記載されるようなサービス・レジストリ方法が提供される。

本発明の第２の態様によれば、請求項１１から２０に記載されるようなサービス・レジストリ・システムが提供される。

本発明の第３の態様によれば、請求項２１から３０に記載されるようなコンピュータ・プログラムが提供される。

好適な実施形態によるサービス・レジストリは、サービス（またはサービスの追加のインスタンス）がサービス・プロバイダにより利用可能となることを要求し、例えばサービスを含む仮想機械(virtual machine)画像を利用可能なハードウェア上に配置することによって、クラウド・コンピューティングによって提供することができる。レジストリに新しいサービス・エンドポイントを追加し、エンタープライズ・サービス・バス（ＥＳＢ）は（いずれかの既存のエンドポイントに加えて）新しいエンドポイントをルーティングすることができる。サービスを除去し、他のサービス向けにハードウェアを利用可能とする何らかのタイムアウトまたは使用値に達するまで、サービスは展開されたままである。サービス・プロバイダからサービス・エンドポイントが除去されたことをレジストリが発見した場合、サービス・エンドポイントはレジストリから除去される。

レジストリは、直接サービスを提供している管理者(administrators)によって、またはＳＯＡ管理アプリケーションの使用によって用いられる。管理者によりサービスが開始されると、管理者またはＳＯＡ管理アプリケーションが使用するため、エンドポイント情報がレジストリに自動的に配置される。エンドポイント情報は、他のタイプのエンドポイントおよびサービス・エンドポイントを含み、本発明では、サービス・エンドポイントが失われた場合に、他のタイプのエンドポイント情報を用いて新しいサービス・エンドポイントを入手または提供可能であることが認められる。他のタイプのエンドポイントは、一般にインターネット・プロトコル・アドレスであるサービス・エンドポイントよりも抽象的である。実施形態によって、他のタイプのエンドポイント情報が管理者または管理アプリケーションあるいはその両方に利用可能となる。

好適な実施形態および他の実施形態は、サービス・レジストリにおいて実現される。レジストリは間接レイヤ（a layer of indirection）を提供し、これによって呼び出しアプリケーションは必ずしもサービス・エンドポイントの位置を知っている必要がなくなる。間接レイヤは、エンタープライズ・サービス・バス（ＥＳＢ）上のサービス・アプリケーションによって用いられて、サービスの品質または負荷バランス等のサービス特徴に応じた異なるエンドポイントへのサービス要求の方向付けの管理を可能とする。

適切なサービス・エンドポイントが存在しない場合、または性能特徴が低すぎる場合、サービスの新しいインスタンスを提供するために要求が行われる。サービス・エンドポイントでない既存のエンドポイントの例は、必要に応じて仮想機械画像を提供するクラウド・ツールである。

サービス・エンドポイントが存在しない場合、新しいサービス・エンドポイント・インスタンスが提供されるまでレジストリは待機することができる。サービス・レジストリは、この新しいサービス・エンドポイントを要求側のアプリケーションに戻し、要求は新しいサービス・エンドポイントにルーティングされる。すでに利用可能なサービス・エンドポイントが存在する場合、要求は既存のサービス・エンドポイントにルーティングすることができるが、新しいサービス・エンドポイントが利用可能となった場合、今後の要求は、既存のサービス・エンドポイントに加えて新しいサービス・エンドポイントを利用することができる。

この解決策の利点として、サービスを効率的にアンインストールし、その後インストールすることができるので、サービス・プロバイダの利用可能なサービスからの低需要サービスをいっそう効率的に管理することができる。サービス使用が設定レベル未満に低下した場合またはタイムアウトに達した場合にはクラウド・サーバからサービス仮想機械画像を除去するように、展開されたサービス・インスタンスを監視することができる。

この解決策は、限られた数のサーバを有するがクラウド・リソースを用いてカスタマに多くのサービスを提供してサービスを拡大したいサービス・プロバイダにとって、特に有利である。かかるサービス・プロバイダは、多数のサービスのいずれか１つのホストとなり得る仮想エンドポイントを利用可能とすることができる。サービス・プロバイダは、サービス要求が受信された場合に単に新しいサービスを提供し、その後、使用レベルが低下した場合にサービスを除去する。これが意味するのは、サービス・プロバイダが、サービスのホストとなるために用いているクラウドの使用についてのみ支払いをすれば良いといことであり、従ってそれらのサーバのコストは固定されないことが確実となる。

これより添付図面を参照して一例としてのみ本発明の実施形態を説明する。

従来技術に従ったコンピュータ・システム・ノードのコンポーネントの図である。 従来技術に従った２つ以上のコンピュータ・システム・ノードを含むコンピュータ・ネットワーク環境のコンポーネントの図である。 本発明の好適な実施形態に従った、サービス・レジストリ、サービス要求側、およびサービス・プロバイダ間のインタラクションを示すＳＯＡシステムのコンポーネントの図である。 本発明のリソース・プロバイダの実施形態に従った、サービス・レジストリ、サービス要求側、サービス・プロバイダ、およびリソース・プロバイダ間のインタラクションを示すＳＯＡシステムのコンポーネントの図である。 本発明の実施形態に従ったサービス・レジストリのコンポーネントの図である。 本発明のクラウド実施形態に従った仮想化レイヤを示す。 本発明の好適な実施形態の方法のプロセス図である。 本発明の好適な実施形態の実行方法のプロセス図である。 本発明の好適な実施形態の補足的なレジストリ検索方法を示すプロセス図である。

図１を参照すると、従来技術に従ったコンピュータ・システム・ノード１０のコンポーネントの図が示されている。コンピュータ・システム・ノード１０は、コンピュータ・システム／サーバ１２を含み、これは多数の他の汎用または特殊用途コンピューティング・システム環境またはコンフィギュレーションと共に動作する。コンピュータ・システム／サーバ１２で用いるのに適切であり得る周知のコンピューティング・システム、環境、またはコンフィギュレーションあるいはそれら全ての例は、限定ではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント（thin client）、シック・クライアント（thick client）、ハンドヘルド・デバイス、またはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラマブル民生用電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上述のシステムまたはデバイスのいずれかを含む分散型クラウド・コンピューティング環境等を含む。

コンピュータ・システム／サーバ１２は、コンピュータ・システムにより実行されるプログラム・モジュール等のコンピュータ・システム実行可能命令の一般的なコンテキストにおいて記述することができる。一般に、プログラム・モジュールは、特定のタスクを実行するかまたは特定の抽象データ・タイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造等を含むことができる。

コンピュータ・システム／サーバ１２は、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境において具現化することができる。分散型クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ記憶デバイスを含むローカルおよび遠隔の双方のコンピュータ・システム記憶媒体に位置することができる。

図１に示すように、コンピュータ・システム・ノード１０におけるコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形態で示されている。コンピュータ・システム／サーバ１２のコンポーネントは、限定ではないが、１つ以上のプロセッサまたは処理ユニット１６と、システム・メモリ２８と、システム・メモリ２８を含む様々なシステム・コンポーネントをプロセッサ１６に結合するバス１８と、を含む。

バス１８は、多種多様なバス・アーキテクチャのいずれかを用いた、メモリ・バスまたはメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィック・ポート、およびプロセッサまたはローカル・バスを含むいくつかのタイプのバス構造のいずれかの１つ以上を表す。限定ではなく一例として、かかるアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ：Industry Standard Architecture）バス、マイクロチャネルアーキテクチャ（ＭＣＡ：Micro Channel Architecture）バス、拡張ＩＳＡ（ＥＩＳＡ：Enhanced ISA）バス、ＶＥＳＡ（VideoElectronics Standards Association）ローカル・バス、およびＰＣＩ（Peripheral Component Interconnects）バスを含む。

コンピュータ・システム／サーバ１２は典型的に、多種多様なコンピュータ・システム読み取り可能媒体を含む。かかる媒体は、コンピュータ・システム／サーバ１２によってアクセス可能であるいずれかの利用可能媒体とすることができ、揮発性および不揮発性媒体、着脱可能および着脱不可能媒体の双方を含む。

システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ）３０およびキャッシュ・メモリ３２あるいはその両方等、揮発性メモリの形態のコンピュータ・システム読み取り可能媒体を含むことができる。コンピュータ・システム／サーバ１２は更に、他の着脱可能／着脱不可能、揮発性／不揮発性コンピュータ・システム記憶媒体を含むことも可能である。一例に過ぎないが、着脱不可能、不揮発性磁気媒体（図示せず。典型的に「ハード・ドライブ」と呼ばれる）からの読み取りおよびそれに対する書き込みのために、記憶システム３４を設けることができる。図示しないが、着脱可能、不揮発性磁気ディスク（例えば「フレキシブル・ディスク」）からの読み取りおよびそれに対する書き込みのための磁気ディスク・ドライブ、ならびにＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体等の着脱可能、不揮発性光ディスクに対する読み取りまたはそれに対する書き込みのための光ディスク・ドライブを設けることができる。かかる例では、各々は１つ以上のデータ媒体インタフェースによってバス１８に接続することができる。以下で更に図示し記載するように、メモリ２８は、本発明の実施形態の機能を実行するように構成されたプログラム・モジュールのセット（例えば少なくとも１つ）を有する少なくとも１つのプログラムを含むことができる。

限定ではないが一例として、メモリ２８に、プログラム・モジュール４２のセット（少なくとも１つ）を有するプログラム／ユーティリティ４０を記憶することができ、更に、オペレーティング・システム、１つ以上のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データも記憶することができる。オペレーティング・システム、１つ以上のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データまたはそれらの何らかの組み合わせの各々は、ネットワーキング環境の実装を含むことができる。プログラム・モジュール４２は一般的に、本明細書に説明するような本発明の実施形態の機能および方法論あるいはその両方を実行する。

また、コンピュータ・システム／サーバ１２は、キーボード、ポインティング・デバイス、ディスプレイ２４等の１つ以上の外部デバイス１４、ユーザがコンピュータ・システム／サーバ１２とインタラクトすることを可能とする１つ以上のデバイス、コンピュータ・システム／サーバ１２が１つ以上の他のコンピューティング・デバイスと通信を行うことを可能とするいずれかのデバイス（例えばネットワーク・カード、モデム等）あるいはそれら全てと通信を行うことができる。かかる通信はＩ／Ｏインタフェース２２を介して行うことができる。更にコンピュータ・システム／サーバ１２は、ネットワーク・アダプタ２０を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、一般的なワイド・エリア・ネットワーク（ＷＡＮ）、または公衆回線（例えばインターネット）あるいはそれら全て等の１つ以上のネットワークと通信を行うことができる。図示するように、ネットワーク・アダプタ２０は、バス１８を介してコンピュータ・システム／サーバ１２の他のコンポーネントと通信を行う。図示しないが、コンピュータ・システム／サーバ１２と関連付けて他のハードウェアまたはソフトウェアのコンポーネントあるいはその両方を使用可能であることは理解されよう。限定ではないが、その例は、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部のディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイバル記憶システムを含む。

ここで図２を参照すると、従来技術の例示的なクラウド・コンピューティング環境５０が示されている。図示のように、クラウド・コンピューティング環境５０は１つ以上のクラウド・コンピューティング・ノード１０を含み、これらは、例えばパーソナル・デジタル・アシスタント（ＰＤＡ）または携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎあるいはそれら全て等のクラウド消費者によって用いられるローカル・コンピューティング・デバイスと通信を行うことができる。ノード１０は相互に通信可能である。それらは、プライベート(private)、コミュニティ、パブリック(public)、またはハイブリッド・クラウド、またはそれらの組み合わせ等の１つ以上のネットワークにおいて物理的にまたは仮想的にグループ化することができる（図示せず）。これによってクラウド・コンピューティング環境５０は、インフラストラクチャ、プラットフォーム、またはソフトウェアあるいはそれら全てをサービスとして提供することができ、クラウド消費者はそのためにローカル・コンピューティング・デバイス上でリソースを維持する必要はない。図２に示すコンピューティング・デバイス５４Ａ〜５４Ｎのタイプは例示を意図するだけであり、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、いずれかのタイプのネットワークまたはネットワーク・アドレス指定可能接続を介して（例えばウェブ・ブラウザを用いて）いかなるタイプのコンピュータ化デバイスとも通信可能であることは理解されよう。

図３を参照すると、本発明の好適な実施形態によるＳＯＡシステム３００のコンポーネント図が示されている。ＳＯＡシステム３００は、ユーザ・デバイス５４Ａならびに少なくとも２つのネットワーク３０１および３０６を含む。第１のネットワーク３０１は、少なくとも１つのサービス・プロバイダ３０２およびレジストリ３０４を含む。典型的に、第１のネットワーク３０１はエンタープライズ・ネットワークである。サービス・プロバイダ３０２は、例示的なマッピングおよびナビゲーション・サービス３１０を含む。第２のネットワーク３０６はサービス・プロバイダ３０８Ａ〜３０８Ｎを含む。レジストリ３０４はサービス・エンドポイント・エンジン５３２を含む。

クライアント・デバイス５４Ａとサービス・プロバイダ３０２または３０８Ａ〜３０８Ｎとの間の既知のインタラクションは次のように進む。クライアント・デバイス５４Ａはレジストリ３０４からサービスの使用を要求する。例えば、クライアント・デバイスはその位置のマップを要求することができる。レジストリ３０４は、例えばマッピングおよびナビゲーション・サービス３１０のような要求されたサービスを検索して位置を特定する。次いでレジストリは、位置を特定したサービスに関連付けられた１つ以上のサービス・エンドポイントを選択する。各サービス・エンドポイントは、少なくともインターネット・プロトコル（ＩＰ）・アドレスならびに任意にポート番号およびサービス・プロバイダ名を含み、サービス・プロバイダに対するＩＰサービス要求を可能とする。次いでレジストリ３０４は、サービス・エンドポイントを要求側のクライアント・デバイス５４Ａに返信し、クライアント・デバイス５４Ａは、提供されたサービス・エンドポイントの１つ以上を用いてサービス・プロバイダ３０２または３０８Ａ〜３０８Ｎからマッピング・サービスを要求する。レジストリ３０４は、レジストリ３０４と同一のドメインもしくはエンタープライズ（すなわち第１のネットワーク３０１）内にあるサービス・エンドポイントを供給することができ、または別のドメインもしくはエンタープライズ内にあるものを供給することができる。供給されたサービス・エンドポイントによって、クライアントはサービス・プロバイダからのサービスを独立して要求することができる。

レジストリ３０４がサービス要求のための適切なサービス・エンドポイントを見つけられない場合、問題が発生する。全ての実施形態は、レジストリの一部としてサービス・エンドポイント・エンジン５３２を提供して、レジストリにおいて見つからない場合にレジストリの外部で適切なサービス・エンドポイントを探し出す。全ての実施形態は、サービス・プロバイダおよび他のサービス・レジストリ（図３および図４には他のサービス・レジストリは示していない）から、サービス・エンドポイントを探し出す。また、レジストリ３０４にサービス・エンドポイントが存在しない場合は、他のサービス・エンティティとの通信によって、レジストリ３０４は、サービスが一時的にオフラインであるか、またはいかなるサービス・プロバイダによっても提供されていないかを確かめることができる。一時的にオフラインのサービスは、サービス・エンドポイントが失われたかまたはインストールされていないサービスである。サービスが一時的にオフラインである場合、レジストリ３０４はサービス・プロバイダにおいてサービスを利用可能に再確立しようとする。いったんサービス・プロバイダ３０２または３０８Ａ〜３０８Ｎが特定のサービスのためのサービス・エンドポイントを利用可能とすると、新たに利用可能となったサービス・エンドポイントは、初めてサービス・レジスタに登録され、またはレジストリ３０４によって再び登録され、次いでサービス要求側５４Ａに戻される。好適な実施形態において、サービス要求側５４Ａは、提供されたエンドポイントを用いてサービス・プロバイダと直接通信を行う。

図４を参照すると、本発明のサービス管理実施形態に従った完全なサービス管理を提供するＳＯＡシステム４００が示されている。ＳＯＡシステム４００は、ユーザ・デバイス５４Ａならびに少なくとも２つのネットワーク４０１および４０６を含む。第１のネットワーク４０１は、少なくとも１つのサービス・プロバイダ４０２と、レジストリ４０４と、リソース・プロバイダ４０５と、を含む。典型的に、第１のネットワーク４０１はエンタープライズネットワークである。第２のネットワーク４０６はサービス・プロバイダ４０８Ａ〜４０８Ｎを含む。レジストリ４０４はサービス・エンドポイント・エンジン５３２を含む。サービス・プロバイダ４０２は例示的なマッピングおよびナビゲーション・サービス４１０を含む。

この実施形態においては、完全なサービス管理は、レジストリ４０４がリソース・プロバイダ４０５とインタラクトして、例えばマッピング・サービスのようなサービスを提供することを含み、クライアントがサービス・プロバイダに関与する必要はない。クライアントはサービス・レジストリからサービスを要求し、次いでリソース・プロバイダがサービス・プロバイダからサービスを提供する。新たに発見されたサービス・エンドポイントがいったん登録されると、リソース・プロバイダ４０５がサービス・プロバイダ４０２または４０８Ａ〜４０８Ｎとインタラクトしてサービスを制御するために用いられる。リソース・プロバイダ４０５は、サービス・プロバイダ４０２または４０８Ａ〜４０８Ｎとサービス要求側５４Ａとの間の通信を行うためのプロキシとして機能する。リソース・プロバイダ４０５は、サービスの課金およびサービス品質の管理を含むサービスの完全サービス管理を可能とする。この実施形態では、サービス要求側５４Ａはサービス・プロバイダ４０２と直接に通信せず、サービス・プロバイダ４０２または４０８Ａ〜４０８Ｎの実際のエンドポイント・アドレスはサービス要求側５４Ａに知られていない。

図５を参照すると、本発明の実施形態に従ったサービス・レジストリ３０４（または４０４）のコンポーネント図が示されている。サービス・レジストリ３０４または４０４は、複数のサービス文書を記憶しており、これらの文書および対応するサービスに対するアクセスを可能とする。サービス文書はインデックスされ、インデックスはサービス・レジストリに記憶されて特定の特徴を有する具体的なサービスの位置特定を可能とする。サービス・レジストリは、サービスに関する情報のサブセットのインデックスであり（例えばサービス文書の位置および名前）、リポジトリ５１４における対応するサービス文書の位置特定およびアクセス（またはサービス・プロバイダにおける対応するサービスの位置特定）を可能とする。堅固に結合されたサービス・レジストリおよびリポジトリによって、サービス動作は、レジストリ内のインデックスされたサービス情報およびリポジトリ内の詳細なサービス情報の双方を用いることができる。一体型サービス・レジストリおよびリポジトリの一例は、ＩＢＭ ＷｅｂＳｐｈｅｒｅ＊ Ｒｅｇｉｓｔｒｙ ａｎｄ Ｒｅｐｏｓｉｔｏｒｙ（ＷＳＲＲ）である。

かかる一体型のサービス・レジストリおよびリポジトリは、分離型のシステムに比べ、再使用によるビジネスの機敏さおよび回復力という利点を有する。一体化から、結合のゆるさ、高い柔軟性、良好なインターオペラビリティ、および良好な統制（governance）という更に別の利点も得られる。これらの利点は、サービス記述をそれらの実施から分離させ、サービスのライフ・サイクル全体を通してサービス記述を使用することによって与えられる。ＷＳＤＬ（ウェブ・サービス定義言語）、拡張可能ＸＭＬ（extensible mark-up language）スキーマ、ポリシまたはサービス・コンポーネント・アーキテクチャ（ＳＣＡ）文書等の規格に基づいたサービス・メタデータ・アーチファクトによって、サービスによって何が実行可能なのか、サービスをどのように呼び出すことができるか、または他のサービスによる実行が予想されることの技術的な詳細を捕捉する。これらのアーチファクトに意味論的な（Ｓｅｍａｎｔｉｃ）注釈および他のメタデータを関連付けて、どのように、いつ使用可能か、および何の目的に供するかに基づいてサービスの潜在的なユーザに見通しを与えることができる。

好適な実施形態は、ＩＢＭ ＷｅｂＳｐｈｅｒｅ Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ ａｎｄ Ｒｅｐｏｓｉｔｏｒｙに基づいたサービス文書のためのサービス・レジストリおよびリポジトリである。かかるサービス文書は、ある範囲のプロトコルを用いて多種多様なプログラミング・モデルに従って実装される従来のインターネット・サービスを含む。好適な実施形態はスタンドアロンのサービス・レジストリであるが、実施形態は、一体型サービス・レジストリを有する他のＳＯＡコンポーネントを含む場合もある。例えば、サービス・プロバイダは、レジストリ機能およびサービス・プロバイダ機能を可能とする一体型サービス・レジストリを有することができる。

好適な実施形態のサービス・レジストリ３０４（または４０４）は、Ｊａｖａ＊ Ｐｌａｔｆｏｒｍ、Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊａｖａ ＥＥ６）アプリケーションであり、ＩＢＭ ＷｅｂＳｐｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ ７上で動作し、バッキング・ストア（ｂａｃｋｉｎｇ ｓｔｏｒｅ）としてオブジェクト・データベースを用いてサービス・メタデータを維持する。サービス・レジストリは、ロールベース・アクセス制御(role-based access control)を利用して、サービス・レジストリおよびリポジトリが企業全体のアプリケーションとして展開された場合にロールベースのビューおよびアクセス制御をオンすることを可能とする。図５を参照すると、サービス・レジストリ３０４／４０４は、レジストリ・エンジン５１２、リポジトリ５１４、統制部５２０、分類部５２２、アクセス・コントローラ５２４、管理インタフェース５２６、ユーザ・インタフェース５２８、プログラミング・インタフェース５３０、サービス・エンドポイント・エンジン５３２を含む。

レジストリ・エンジン５１２は、サービス・メタデータのためのレジストリ機能およびリポジトリ機能の双方を提供する。リポジトリ機能によって、ユーザは、サービス記述を保持するサービス・メタデータ・アーチファクトを（リポジトリ５１４に）記憶し、管理し、照会することができる。レジストリ・エンジン５１２は、信頼性の高いデータ維持によってサービス・メタデータを含む文書を慎重に扱うだけでなく、例えばいくつかのサービス文書におけるポートおよびポート・タイプのようなそれらの文書の内容の詳細な表現を提供する。レジストリ・エンジン５１２は、得られた内容モデルの登録サービス宣言および要素を、ユーザが規定した特性、関係、および分類によって装飾するための対応をする。レジストリは、サービス・エンドポイントまたはサービス・インタフェース等のエンティティを見つけるために検索を行う場合にそれらの装飾を利用するユーザ・インタフェース５２８を提供する。

リポジトリ５１４に記憶された文書は、レジストリ・エンジン５１２によって変更の有無を監視される。サービス文書に対する変更がレジストリ・エンジン５１２によって検出された場合はいつでも、検証および通知機能を呼び出す。これら双方の種類の機能は拡張機構と考えられ、レジストリ・エンジン５１２が変更に対してどのように反応するかをカスタマイズするために用いることができる。検証機能は、内容に変更があった場合にレジストリ・エンジン５１２が実行するように記述することができる。例えば、検証機能はサービス規定の完全性についてチェックを行う。レジストリ・エンジン５１２は、通知プラグ・イン（図示せず）を含み、これはサービス・レジストリおよびリポジトリの内容の変更を伝達する通知の購読(subscription)機能を有する。

統制部５２０によって、レジストリ・エンジン５１２は多数の拡張可能な統制機能をサポートする。これらの機能は、統制されたエンティティについてのサービス・ライフ・サイクルをモデル化し、サービス状態間の有効な遷移を規定し、状態間の遷移を守るためにバリデータ(validators)を記述およびプラグ・インし、遷移の結果行われるアクション（通知アクション）を指定する能力を含む。統制部５２０は、内容に対する変更の影響を分析するためのインタフェースを提供し、かかる変更の監査を行う。

分類部５２２によって、サービス記述およびサービス規定の一部に、企業の語彙で注釈を付け、統制状態を捕捉することができる。サービス分類システムは、管理インタフェース５２６を用いてサービス・レジストリ内にロードされたウェブ・オントロジー言語（ＯＷＬ）文書において捕捉される。サービス・レジストリ・エンティティは、これらの分類システムからの値によって分類して、分類に基づいた照会を実行し、分類に基づいたアクセス制限を実行することができる。

アクセス・コントローラ５２４は、詳細なアクセス制御モデルをサポートし、これによって、どのユーザロールが対応したアーチファクトに対する特定のタイプのアクションを実行可能であるかを規定することができる。サービスの可視性はビジネス領域によって制限することができ、ユーザロールは一定のライフ・サイクル状態にサービスが遷移するのを制限することができる。これは、サービス・レジストリおよびリポジトリが提供するロールベース・アクセス制御に追加される。

管理インタフェース５２６は、他のリポジトリとの交換のためにリポジトリ内容のインポートおよびエクスポートをサポートし、コンフィギュレーションおよび基本的な管理のためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を提供する。これらは、アクセス・コントローラ５２４および分類部５２２とのインタラクションをサポートする。

ユーザ・インタフェース５２８は、サービス・レジストリおよびリポジトリとのユーザのインタラクションを可能とし、全てのユーザロールすなわち参照提供、閲覧、検索、公開、および注釈付け機能、ならびにインポート／エクスポートおよび影響分析等の統制アクティビティをサポートする。ユーザ・インタフェースは、様々なサード・パーティ・ツールのためのプラグ・インとして提供してインターオペラビリティをサポートすることができる。

プログラミング・インタフェース５３０は、標準的なＡＰＩを用いてレジストリ・エンジン５１２（例えばＪａｖａおよび標準的なＳＯＡプロトコル）とインタラクトする。プログラミング・インタフェース５３０は、生成、検索、更新、および削除（ＣＲＵＤ）等の基本的な動作、統制動作、および柔軟な照会機能のためのインタフェースを提供する。プログラミング・インタフェース５３０は、ＸＭＬデータ構造を用いてまたはサービス・データ・オブジェクト（ＳＤＯ）を用いることによって内容を伝達することができる。文書は、ユーザ・インタフェース５２８またはプログラミング・インタフェース５３０のいずれかを用いて、生成、検索、更新、および削除することができる。

サービス・エンドポイント・エンジン５３２は、サービス・エンドポイントについての要求を処理するための処理論理を含む。この処理論理は、サービス・エンドポイントが存在しない場合、または要求されたサービスの品質がサービス・エンドポイントにより提供されるサービスの品質と一致しない場合に、要求を処理する。サービス・エンドポイント・エンジン５３２が実行するプロセス・ステップについては、図７、図８、および図９の実施形態を参照して説明する。

図６を参照して、本発明の好適な実施形態のクラウド・コンピューティング環境が提供する仮想化抽象モデル・レイヤについて説明する。図６に示すコンポーネント、レイヤ、および機能は、例示のみを意図しており、本発明の実施形態はこれに限定されない。図示のように、以下のレイヤおよび対応する機能が提供される。すなわち、ハードウェアおよびソフトウェア・レイヤ６０、仮想化レイヤ６２、管理レイヤ６４、および作業負荷レイヤ６６である。

ハードウェアおよびソフトウェア・レイヤ６０は、ハードウェアおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例は、一例としてＩＢＭ ｚＳｅｒｉｅｓ＊システムがあげられるメインフレーム、一例としてＩＢＭ ｐＳｅｒｉｅｓ＊システムがあげられる縮小命令セット・コンピュータ（ＲＩＳＣ）・アーキテクチャ・ベースのサーバ、ＩＢＭ ｘＳｅｒｉｅｓ＊システム、ＩＢＭ ＢｌａｄｅＣｅｎｔｅｒ＊システム、記憶デバイス、ネットワークおよびネットワーキング・コンポーネントを含む。ソフトウェア・コンポーネントの例は、一例としてＩＢＭ ＷｅｂＳｐｈｅｒｅアプリケーション・サーバ・ソフトウェアがあげられるネットワーク・アプリケーション・サーバ・ソフトウェア、および一例としてＩＢＭ ＤＢ２＊データベース・ソフトウェアがあげられるデータベース・ソフトウェアを含む。

仮想化レイヤ６２は抽象化レイヤを提供し、ここから以下のような仮想エンティティの例を提供することができる。すなわち、仮想サーバ、仮想記憶、仮想プライベート・ネットワークを含む仮想ネットワーク、仮想アプリケーションおよびオペレーティング・システム、および仮想クライアントである。

好適な実施形態においては、サービス・レジストリ３０４およびリソースの提供は、クラウド・システムの管理レイヤ６４の一部である。管理レイヤ６４は更に、計測および価格付け、ユーザ・ポータル、およびサービス・レベル管理等の他の機能を含む。リソースの提供は、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソースおよび他のリソースの動的な調達を提供する。サービス・レジストリは、クラウド・システムにおいて用いられるコンピューティングおよび他のリソースのためのディレクトリを提供する。計測および価格付けは、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡を提供し、これらのリソースの消費について課金またはインボイス作成を提供する。一例では、これらのリソースはアプリケーション・ソフトウェア・ライセンスを含むことができる。ユーザ・ポータルは、消費者およびシステム管理者のためにクラウド・コンピューティング環境に対するアクセスを提供する。サービス・レベル管理は、要求されたサービス・レベルを満足させるようにクラウド・コンピューティング・リソースの割り当ておよび管理を提供する。

作業負荷レイヤ６６は、クラウド・コンピューティング環境を利用することができる機能性の例を提供する。このレイヤから提供可能である作業負荷および機能の例は、マッピングおよびナビゲーション、ソフトウェア開発およびライフ・サイクル管理、仮想クラスルーム教育配信、データ分析処理、トランザクション処理、およびモバイル・デスクトップを含む。ＳＯＡシステムでは、作業負荷レイヤにおける作業負荷はサービスとして実装される。

図７を参照すると、ＳＯＡシステム３００または４００においてサービス・エンドポイント・エンジン５３２および関連するコンポーネントの処理論理によって実行される好適な実施形態のプロセスが示されている。このプロセスは、適切な変更を行って少なくとも完全なサービス・リソースを提供する実施形態のために適合させることができる。このプロセスは、ＳＯＡシステムの主要コンポーネントに関して、特にサービス・レジストリに関して実行されるプロセス・ステップとして説明する。

ステップ７０２において、サービス要求側５４Ａはサービス・プロバイダにサービスを要求し、この要求をサービス・レジストリ３０４に送出する。例えば、作業負荷６６のいずれかのサービスである（図６を参照のこと）。

ステップ７０４において、サービス・レジストリ３０４は、リポジトリ５１４内でサービス要求に関連付けられたサービス・エンドポイントを検索するが、この実施形態により対処される問題に従い、ここでサービス・レジストリは関連付けられたサービス・エンドポイントを発見しない。

ステップ７０６において、レジストリ内で正確なサービス・エンドポイントの位置は特定されないが、要求されたサービスに関連付けられたサービス情報を用いてサービス・プロバイダの位置を特定する。関連付けたサービス情報が存在しない場合、デフォルトのサービス・プロバイダの位置を特定する。例えば、サービス・プロバイダの名前または汎用的な管理エンドポイント情報をリポジトリに記憶してサービス要求に関連付けることができる。いずれの場合であっても、ステップ７０６においてサービス・プロバイダの位置を特定するかまたは提供する。

ステップ７０８において、位置特定したかまたはデフォルトのサービス・プロバイダから、要求されたサービスのためのサービス・エンドポイントを要求する。

位置特定したかまたはデフォルトのサービス・プロバイダ３０８Ｎは、ステップ７１０においてサービス要求を受信し、ステップ７１２においてサービスをセットアップする。いったんセットアップしたら、サービス・プロバイダはセットアップしたサービスをサービス・エンドポイントに関連付ける。サービスは、すでにセットアップされており、サービス・レジストリが認識していなかった既存のサービス・エンドポイントを有する場合がある。サービスは、サービス・エンドポイントなしでセットアップされている可能性もあり、この場合サービス・プロバイダはサービス・エンドポイントをセットアップし関連付けるだけである。サービスがセットアップされていない場合、サービス・プロバイダは既知の位置でまたは未知の位置で仮想的にそれをセットアップする。仮想セットアップでは、管理レイヤ６４におけるリソース提供は、サーバ、記憶装置、ネットワーク、アプリケーション、およびクライアント、および作業負荷６６の必要な仮想化レイヤ・コンフィギュレーションをセットアップする。

サービス・エンドポイントが既存であった場合もそうでない場合も、これはステップ７１４においてレジストリ３０４に返信される。

ステップ７１６において、レジストリは、受信したサービス・エンドポイントに、サービス・レジストリに登録されたサービスを関連付ける。

ステップ７１８において、レジストリは、受信したサービス・エンドポイントをサービス要求側５４Ａに送信する。

この好適な実施形態においては、サービス要求側５４Ａは、受信したサービス・エンドポイントにおいてサービス・プロバイダ３０２Ｎからのサービスを要求する。

ステップ７２２において、サービス・プロバイダはサービス・エンドポイントにおいてサービス要求を受信し、サービス要求側５４Ａに対するサービス提供を開始する。

例えば、移動電話サービス要求側５４Ａは、サービス要求側が移動する際に、ＧＰＳ（Global Positioning System）データをログ記録することをマッピング・サービスに要求する。かかるＧＰＳデータ・ログ記録サービスの要求７０２がサービス・レジストリに対して行われるが、レジストリはこのサービスに関連付けられた特定のサービス・エンドポイントを発見しない。しかしながら、レジストリは、サービスに関連付けられたサービス名「ＧＰＳマッピング・サービス」およびサービス・プロバイダ「Ｔｅｌｅｍａｐｓ Ｌｏｇｇｅｒ」を発見する。ステップ７０８において、サービス・レジストリは「Ｔｅｌｅｍａｐｓ Ｌｏｇｇｅｒ」からサービス・エンドポイントを要求する。「Ｔｅｌｅｍａｐｓ Ｌｏｇｇｅｒ」は、サービス・エンドポイント要求を受信し、ステップ７１２において、例えばＩＰアドレス１９２．１６８．２．３およびポート１２００（１９２．１６８．２．３：１２００）のようなサービス・エンドポイントにおける「ＧＰＳマッピング・サービス」をセットアップまたは発見する。次いでステップ７１４において、「Ｔｅｌｅｍａｐｓ Ｌｏｇｇｅｒ」サービス・プロバイダは、サービス・エンドポイントをサービス・レジストリに返信する。サービス・レジストリ３０４は、１９２．１６８．２．３：１２００を「ＧＰＳマッピング・サービス」に関連付け、同一のサービス・エンドポイントを移動電話に返信する。次いでステップ７２０において、移動電話は、受信したサービス・エンドポイントを用いて「Ｔｅｌｅｍａｐｓ Ｌｏｇｇｅｒ」からのサービスを自由に要求する。Ｔｅｌｅｍａｐｓ Ｌｏｇｇｅｒは、サービス・エンドポイント１９２．１６８．２．３：１２００に要求された場合、「ＧＰＳマッピング・サービス」を提供する。例えば、サービスは、移動電話の地理的位置を示すマップ・データを送信し、マップ・データは移動電話によって移動電話の画面上に描画される。

図８を参照すると、本発明の好適な実施形態の実行方法８００の図が示されている。方法７００と同様に、方法８００も、適切な変更を行って完全なサービス・リソース提供実施のために適合させることができる。このプロセスは、ＳＯＡシステムの主要コンポーネントに関して、特にサービス・レジストリに関して実行されるプロセス・ステップとして説明する。

ステップ８０２において、サービス要求側５４Ａは、規定の性能レベルを有するサービスをサービス・プロバイダに要求し、この要求をサービス・レジストリ３０４に送出する。

ステップ８０４において、サービス・レジストリ３０４は、リポジトリ５１４内で規定の性能レベルを有しサービス要求に関連付けられたサービス・エンドポイントを検索するが、この実施形態により対処される問題に従い、ここではサービス・レジストリはかかる関連付けられたサービス・エンドポイントを発見しない。

サービスを提供するが必要な性能レベルでない１つ以上のサービス・エンドポイントが位置特定されると、これらのサービス・プロバイダは潜在的なサービス・プロバイダ・リストにリスト化される。サービス・エンドポイントを有しない、要求されたサービスに関連付けられたサービス・プロバイダが位置特定されると、これらのサービス・プロバイダも潜在的なサービス・プロバイダ・リストにリスト化される。ステップ８０６において、潜在的なサービス・プロバイダ・リスト内のものから第１のサービス・プロバイダを選択する。この選択は、必要な性能レベルに対するサービス性能の近さに基づいている。任意に、サービス・エンドポイントを有するサービス・プロバイダは、有しないものよりも選択の優先度が高い。関連付けられたサービス情報が存在しない場合、デフォルトのサービス・プロバイダを選択する。

ステップ８０８において、選択したサービス・プロバイダから、要求されたサービスのためのサービス・エンドポイントを要求する。

ステップ８１０において、選択したかまたはデフォルトのサービス・プロバイダ３０８Ｎはサービス要求を受信し、必要なサービス性能を提供することができる場合は、ステップ８１２において、規定のサービス性能を有するサービスのためのサービス・エンドポイントをセットアップする。サービス・プロバイダがサービス性能を提供することができない場合、要求は断られ、サービス・レジストリはステップ８０６において別のサービス・プロバイダを選択する必要がある。サービス・プロバイダがサービスを提供可能である場合、サービスはサービス・エンドポイントを用いてすでにセットアップされている場合があるが、適正な性能レベルを得るために追加のコンフィギュレーションが必要である。サービスは、正しいサービス性能レベルですでにセットアップされているが、サービス・エンドポイントを有しない場合がある。この場合、サービス・プロバイダは、ステップ８１４において関連するサービス・エンドポイントをセットアップし、これを返信するだけで良い。サービスがまだセットアップされていない場合、サービス・プロバイダは既知の位置でまたは未知の位置で仮想的にこれをセットアップする。サービス・エンドポイントが既存であった場合でもそうでない場合でも、ステップ８１４においてこれはレジストリ３０４に返信される。

次いでステップ８１６において、レジストリは、受信したサービス・エンドポイントに、規定の性能レベルを有する登録済みのサービスを関連付ける。

次いでステップ８１８において、レジストリは受信したサービス・エンドポイントをサービス要求側５４Ａに送信する。

この実施形態では、ステップ８２０において、サービス要求側５４Ａは、受信したサービス・エンドポイントにおいてサービス・プロバイダ３０８Ｎからのサービスを要求する。この実施形態では、サービス・エンドポイントを規定の性能レベルに関連付けているので、第２の要求で規定の性能レベルを要求する必要がない。他の実施形態では、所与のサービス・エンドポイントにおけるサービスは、サービス要求側からの要求に基づいて様々な性能レベルを有することが考えられる。

サービス・プロバイダは、サービス・エンドポイントにおいてサービス要求を受信し、ステップ８２２において、サービス要求側に対するサービス提供を開始する。

例えば、移動電話サービス要求側５４Ａは、サービス要求側が移動して、ＧＰＳデータをログ記録することをマッピング・サービスに要求し、１秒またはもっと短い更新を要求する。この例では、１秒の更新では我々の要求側デフォルトＧＰＳサービスは除外される。かかるＧＰＳデータ・ログ記録サービスの要求８０２がサービス・レジストリにされるが、レジストリはこのサービスに関連付けられた特定のサービス・エンドポイントを発見しない。しかしながら、レジストリは、その精度が０．８秒更新である特性を有する「ユーロＧＰＳマッピング・サービス」という名前のサービスを発見し、レジストリは０．８秒が１秒よりも短いことを理解する。従って、サービス・プロバイダ「Ｅｕｒｏ Ｍａｐ Ｌｏｇｇｅｒ」がサービスに関連付けられる。ステップ８０８において、サービス・レジストリは「Ｅｕｒｏ Ｍａｐ Ｌｏｇｇｅｒ」からサービス・エンドポイントを要求する。「Ｅｕｒｏ Ｍａｐ Ｌｏｇｇｅｒ」は、サービス・エンドポイント要求を受信し、ステップ８１２において、セットアップを行い、または、例えばＩＰアドレス２１４．１６８．２．３およびポート２４００（２１４．１６８．２．３：２４００）のようなサービス・エンドポイントにおける「ユーロＧＰＳマッピング・サービス」を発見する。次いでステップ８１４において、「Ｅｕｒｏ Ｍａｐ Ｌｏｇｇｅｒ」サービス・プロバイダは、サービス・エンドポイントをサービス・レジストリに返信する。サービス・レジストリ３０４は、２１４．１６８．２．３：２４００を「ユーロＧＰＳマッピング・サービス」に関連付け、同一のサービス・エンドポイントを移動電話に返信する。次いでステップ８２０において、移動電話は、受信したサービス・エンドポイントを用いて「Ｅｕｒｏ Ｍａｐｓ Ｌｏｇｇｅｒ」からのサービスを自由に要求する。Ｅｕｒｏ Ｍａｐｓ Ｌｏｇｇｅｒは、サービス・エンドポイント２１４．１６８．２．３：２４００に要求された場合、「ユーロＧＰＳマッピング・サービス」を提供する。例えば、サービスは、移動電話の地理的位置を示すマップ・データを送信し、マップ・データは移動電話によって移動電話の画面に描画される。

図９を参照すると、本発明のサービス・レジストリ・プロキシ実施形態の検索方法９００の図が示されている。方法７００および８００と同様に、方法９００も、適切な変更を行って完全なサービス・リソース提供実施形態のために適合させることができる。このプロセスは、ＳＯＡシステムの主要コンポーネントに関して、特にサービス・レジストリに関して実行されるプロセス・ステップとして説明する。

サービス要求側５４Ａは、第１のサービス・レジストリ３０４Ａからのサービスをサービス・プロバイダに要求する。

ステップ９０４において、サービス・レジストリ３０４Ａは、リポジトリ５１４内でサービス要求に関連付けられたサービス・エンドポイントを検索するが、この実施形態により対処される問題に従い、ここで第１のサービス・レジストリ３０４Ａは関連付けられたサービス・エンドポイントを発見しない。

関連付けられたサービス情報が存在しない場合、以前の実施形態に従ってデフォルトのサービス・プロバイダを位置特定することができる。この実施形態では、サービス・レジストリ３０４Ａは、デフォルトのサービス・プロバイダを用いるか、または要求を以降のサービス・レジストリに転送するかを決定する。サービス・レジストリは、位置特定したサービス・プロバイダの各々について適合度（relevance）の値を発生する検索アルゴリズムを用い、この適合度が閾値未満であると共に問い合わせる第２のまたはそれ以降のサービス・レジストリがある場合には、ステップ９０８においてサービス・レジストリ３０４Ａは第２の（またはそれ以降の）サービス・レジストリ３０４Ｂからサービス・プロバイダを要求する。また、第１のサービス・レジストリが位置特定したサービス情報も第２の（またはそれ以降の）レジストリに送信して、第２の（またはそれ以降の）レジストリがサービス・プロバイダを選択した際に一つにまとめたサービス情報を用いることを可能とする。

ステップ９１０において、第２の（またはそれ以降の）サービス・レジストリ３０４Ｂは、レジストリ内でサービス要求に関連付けられたサービス・エンドポイントを検索する。正確な一致が発見された場合には、サービス・エンドポイントを第１のサービス・レジストリ３０４Ａに返信し、プロセスはステップ９２０に継続する。正確な一致が発見されない場合、ステップ９１２において、第２のサービス・レジストリは位置特定したサービス・プロバイダまたはデフォルトのサービス・プロバイダを選択する。第２のサービス・レジストリ３０４Ｂは、検索の適合度に基づいて以降のサービス・レジストリを選択することができるが、これは図示しない。

ステップ９１４において、選択したサービス・プロバイダから、要求されたサービスのためのサービス・エンドポイントを要求する。

選択したサービス・プロバイダ３０８Ｎは、サービス要求を受信してサービスをセットアップする。いったんセットアップされると、サービス・プロバイダはサービスをサービス・エンドポイントに関連付ける。サービス・エンドポイントは第２のサービス・レジストリ３０４Ｂに返信される。

次いでステップ９１６において、第２のサービス・レジストリ３０４Ｂは、受信したサービス・エンドポイントに登録済みのサービスを関連付ける。

次いでステップ９１８において、第２のサービス・レジストリ３０４Ｂは、受信したサービス・エンドポイントを第１のサービス・レジストリ３０４Ａに送信する。

ステップ９２０において、第１のサービス・レジストリ３０４Ａは、受信したサービス・エンドポイントに登録済みのサービスを関連付ける。

ステップ９２２において、第１のサービス・レジストリ３０４Ａは、受信したサービス・エンドポイントをサービス要求側５４Ａに送信する。

サービス要求側５４Ａは、受信したサービス・エンドポイント（図示せず）においてサービス・プロバイダ３０２Ｎからのサービスを要求する。サービス・プロバイダは、サービス・エンドポイントにおいてサービス要求を受信し、サービス要求側に対するサービス提供を開始する（図示せず）。

要約すると、サービス指向アーキテクチャ（ＳＯＡ）に合致するシステム内でのサービス・ベースの展開のための方法、システム、およびコンピュータ・プログラムについて説明した。この方法、システム、およびコンピュータ・プログラムは、サービス指向アーキテクチャ・システム内でサービスを提供するためのシステム内のサービス・レジストリにより動作可能であり、このシステムにおいてサービス要求側からサービスの要求を受信するステップと、サービス・レジストリに登録されているサービスのステータスを調べるステップと、を含み、サービスが登録されたサービス・エンドポイントを有しないか、またはサービスの特性が既定の閾値未満であることに応答して、１つ以上のサービス・プロバイダまたは以降のサービス・レジストリに新しいサービスを提供する要求を送信し、サービス・プロバイダが新しいサービスを提供することに応答して、サービス・レジストリを新しいサービスによって更新して、サービスが利用可能であることをサービス要求側に応答することと、によって特徴付けられる。これらの実施形態によって、要求側とプロバイダとのインタラクション間の直接インタラクションおよびサービス管理レイヤを介した間接インタラクションの双方が可能となる。また、これらの実施形態によって、サービス・プロバイダを仮想サーバとして提供可能となり、サービスを仮想アプリケーションとして提供可能となる。

更に別の実施形態
本発明の好適な実施形態の方法の全てまたは一部は、この方法のステップを実行するように構成された論理要素を含む１つの論理装置または複数の論理装置において適切かつ有用に具現化することができること、ならびに、かかる論理要素はハードウェア・コンポーネント、ファームウェア・コンポーネント、またはそれらの組み合わせを含むことができることは、当業者には明らかであろう。

本発明の好適な実施形態に従った論理構成の全てまたは一部は、この方法のステップを実行する論理要素を含む論理装置において適切に具現化することができること、ならびに、かかる論理要素は、例えばプログラマブル論理アレイまたは特定用途向け集積回路における論理ゲート等のコンポーネントを含むことができることは、当業者には明らかであろう。かかる論理構成は更に、固定または送信可能キャリア媒体を用いて記憶および送信可能な、例えば仮想ハードウェア記述子言語を用いて、かかるアレイまたは回路において一時的または永久的に論理構造を確立するための可能化要素（enabling element）において具現化することも可能である。

また、上述の方法および構成は、１つ以上のプロセッサ（図には示していない）上で動作するソフトウェアにおいて完全にまたは部分的に適切に実行可能であること、ならびに、このソフトウェアは、磁気ディスクまたは光ディスク等のいずれかの適切なデータ・キャリア（これも図には示していない）上で搬送される１つ以上のコンピュータ・プログラム要素の形態で提供可能であることは認められよう。データ送信のためのチャネルは同様に、全ての記述の記憶媒体、および有線または無線の信号搬送媒体等の信号搬送媒体を含むことができる。

本発明は更に、コンピュータ・システムと共に用いるためのコンピュータ・プログラムとして適切に具現化することができる。かかる実施は、一連のコンピュータ読み取り可能命令を含むことができ、この命令は、例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、もしくはハードディスクのようなコンピュータ読み取り可能媒体等のタンジブルな媒体上に固定されているか、またはモデムもしくは他のインタフェース・デバイスを用いて、限定ではないが光もしくはアナログ通信ラインを含むタンジブルな媒体上で、または限定ではないがマイクロ波、赤外線、もしくは他の伝送技法を含む無線技法を用いてインタンジブルに（intagibly）コンピュータ・システムに送信可能である。一連のコンピュータ読み取り可能命令は、本明細書に前述した機能性の全てまたは一部を具現化する。

かかるコンピュータ読み取り可能命令は、多くのコンピュータ・アーキテクチャまたはオペレーティング・システムと共に用いるための多数のプログラミング言語で記述することができることは、当業者には認められよう。更に、かかる命令は、限定ではないが、半導体、磁気、もしくは光を含む現在もしくは今後のいずれかのメモリ技術を用いて記憶するか、または限定ではないが光、赤外線、もしくはマイクロ波を含む現在もしくは今後のいずれかの通信技術を用いて送信することができる。かかるコンピュータ・プログラムは、例えばシュリンクラップソフトウェアのような、印刷文書または電子文書が添付された着脱可能媒体として分配可能であるか、または、例えばシステムＲＯＭもしくは固定ディスク上のように、コンピュータ・システムにプリロードされるか、インターネットもしくはワールド・ワイド・ウェブのようなネットワーク上でサーバもしくは電子掲示板から配布可能であることが考えられる。

代替案においては、本発明の好適な実施形態は、サービスを展開するコンピュータ実装方法の形態で実現可能である。この方法は、コンピュータ・プログラム・コードを展開させ、コンピュータ・インフラストラクチャにおいて展開されてそこで実行された場合にコンピュータ・システムにこの方法の全てのステップを実行させるように動作する方法を含む。

更に別の代替案においては、本発明の好適な実施形態は、機能データを有するデータ・キャリアの形態で実現可能である。前記機能データは、コンピュータ・システムにおいてロードされてそれによって動作されると前記コンピュータ・システムがこの方法の全てのステップを実行することを可能とする機能コンピュータ・データ構造を含む。

本発明の範囲から逸脱することなく、前述の例示的な実施形態に多くの改良および変更を実施可能であることは、当業者には明らかであろう。

注記
＊ＢｌａｄｅＣｅｎｔｅｒ＊、ＤＢ２、ＩＢＭ、Ｌｏｔｕｓ、Ｔｉｖｏｌｉ、ｐＳｅｒｉｅｓ、ＷｅｂＳｐｈｅｒｅ、ｘＳｅｒｉｅｓおよびｚＳｅｒｉｅｓは、米国または他の国々あるいはその両方におけるインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標または商標である。
＊＊Ｊａｖａおよび全てのＪａｖａベースの商標およびロゴは、オラクルまたはその関連会社あるいはその両方の商標または登録商標である。

Claims (31)

1. サービス指向環境内でサービスを提供するための、前記環境におけるサービス・レジストリによって動作可能な方法であって、
   前記環境においてサービス要求側からサービスの要求を受信するステップと、
   前記サービス・レジストリに登録されている前記要求されたサービスの詳細を調べるステップと、
   を含み、
   前記要求されたサービスが登録されていないことに応答して、１つ以上のサービス・プロバイダに新しいサービスを提供するよう要求を送信することと、、
   サービス・プロバイダが前記新しいサービスを提供することに応答して、前記サービス・レジストリを前記新しいサービスによって更新して、前記サービスが利用可能であることを前記サービス要求側に応答することと、
   によって特徴付けられる、方法。
2. 前記サービス要求側が必要なサービス標準を含み、前記サービスが登録されているが前記必要な標準を有しないことに応答して、１つ以上のサービス・プロバイダに前記必要な標準を有するサービスを提供するよう要求を送信することと、
   サービス・プロバイダが、前記必要な標準を有するサービスを提供することに応答して、前記サービス・レジストリを前記新しいサービスおよびサービス標準によって更新することと、
   を含む、請求項１に記載の方法。
3. 前記サービス標準は、サービス特性が必要な閾値を満足させることである、請求項２に記載の方法。
4. 前記サービス特性が、
   前記サービスを実行する速度、
   前記サービスのコスト、または
   提供するサービス・インスタンスの数、
   の１つ以上である、請求項３に記載の方法。
5. 前記要求されたサービスが登録されていないことに応答して、１つ以上の以降のサービス・レジストリに前記サービスのためのサービス・プロバイダを提供するよう前記サービス要求を送信することを更に含む、請求項１、２、または３に記載の方法。
6. 前記１つ以上の以降のサービス・レジストリに、位置特定されたサービス情報を送信して、前記１つ以上の以降のサービス・レジストリが、以前に位置特定されたサービス情報およびそれ以降に位置特定されたサービス情報を用いてサービス・プロバイダを選択することを可能とする、請求項５に記載の方法。
7. 前記サービス要求側と前記サービス・プロバイダとの間に介在するサービス管理層を更に含み、前記サービス要求側が前記サービス・プロバイダの実際のサービス・エンドポイントを受信せずに前記サービス管理層を介して前記サービスを用いる、請求項１から６のいずれか１項に記載の方法。
8. 前記サービス要求側が前記サービス・エンドポイントを受信し、直接前記サービス・プロバイダからの前記サービスを要求する、請求項１から６のいずれか１項に記載の方法。
9. 前記サービス・プロバイダが仮想サーバとして提供される、請求項１から８のいずれか１項に記載の方法。
10. 前記サービスが仮想アプリケーションとして提供される、請求項１から９のいずれか１項に記載の方法。
11. サービス指向アーキテクチャ・システム内でサービスを提供するための、前記システムにおけるサービス・レジストリであって、
    前記システムにおいてサービス要求側からサービス要求を受信するための手段と、
    前記サービス・レジストリに登録されている前記サービスのステータスを調べるための手段と、
    を含み、
    前記ステータスが既定の標準未満であることに応答して、１つ以上のサービス・プロバイダに前記既定の標準に従って新しいサービスを提供するよう要求を送信するための手段と、
    サービス・プロバイダが前記既定の標準に従って前記新しいサービスを提供することに応答して、前記サービス・レジストリを前記新しいサービスによって更新して、前記サービスが利用可能であることを前記サービス要求側に応答するための手段と、
    によって特徴付けられる、サービス・レジストリ。
12. 前記既定の標準は、前記サービスが登録されたサービス・エンドポイントを有することである、請求項１１に記載のサービス・レジストリ。
13. 前記既定の標準は、サービス特性が閾値を満足させることである、請求項１１に記載のサービス・レジストリ。
14. 前記サービス特性が、
    前記サービスを実行する速度、
    前記サービスのコスト、
    提供するサービス・インスタンスの数、または
    前記サービスの他のいずれかの可変特性、
    の１つ以上である、請求項１３に記載のサービス・レジストリ。
15. 前記ステータスが既定の標準を満足させていないことに応答して、１つ以上の以降のサービス・レジストリに前記サービスのためのサービス・プロバイダを提供するよう要求を送信することを更に含む、請求項１１、１２、または１３に記載のサービス・レジストリ。
16. 前記１つ以上の以降のサービス・レジストリに、位置特定されたサービス情報を送信して、前記１つ以上の以降のサービス・レジストリが、一つにまとめたサービス情報を用いてサービス・プロバイダを選択することを可能とする、請求項１５に記載のサービス・レジストリ。
17. 前記サービス要求側と前記サービス・プロバイダとの間に介在するサービス管理層を更に含み、前記サービス要求側が前記サービス・プロバイダの実際のサービス・エンドポイントを受信せずに前記サービス管理層を介して前記サービスを用いる、請求項１１から１６のいずれか１項に記載のサービス・レジストリ。
18. 前記サービス要求側が前記サービス・エンドポイントを受信し、直接前記サービス・プロバイダからの前記サービスを要求する、請求項１１から１６のいずれか１項に記載のサービス・レジストリ。
19. 前記サービス・プロバイダが仮想サーバとして提供される、請求項１１から１８のいずれか１項に記載のサービス・レジストリ。
20. 前記サービスが仮想アプリケーションとして提供される、請求項１１から１９のいずれか１項に記載のサービス・レジストリ。
21. サービス指向アーキテクチャ・システム内でサービス・レジストリを動作させ、前記システムにおいてサービスを管理するための、コンピュータ読み取り可能コードを含むコンピュータ・プログラムであって、前記コンピュータ読み取り可能コードが、コンピュータ・システム上にロードされて実行された場合に、
    前記システムにおいてサービス要求側からサービス要求を受信するステップと、
    前記サービス・レジストリに登録されている前記サービスのステータスを調べるステップと、
    を実行し、
    前記ステータスが既定の標準未満であることに応答して、１つ以上のサービス・プロバイダに前記既定の標準に従って新しいサービスを提供するよう要求を送信することと、
    サービス・プロバイダが前記既定の標準に従って前記新しいサービスを提供することに応答して、前記サービス・レジストリを前記新しいサービスによって更新して、前記サービスが利用可能であることを前記サービス要求側に応答することと、
    によって特徴付けられる、コンピュータ・プログラム。
22. 前記既定の標準は、前記サービスが登録されたサービス・エンドポイントを有することである、請求項２１に記載のコンピュータ・プログラム。
23. 前記既定の標準は、サービス特性が閾値を満足させることである、請求項２１に記載のコンピュータ・プログラム。
24. 前記サービス特性が、
    前記サービスを実行する速度、
    前記サービスのコスト、
    提供するサービス・インスタンスの数、または
    前記サービスの他のいずれかの可変特性、
    の１つ以上である、請求項２３に記載のコンピュータ・プログラム。
25. 前記ステータスが既定の標準を満足させていないことに応答して、１つ以上の以降のサービス・レジストリに前記サービスのためのサービス・プロバイダを提供するよう要求を送信することを更に含む、請求項２１、２２、または２３に記載のコンピュータ・プログラム。
26. 前記１つ以上の以降のサービス・レジストリに、位置特定されたサービス情報を送信して、前記１つ以上の以降のサービス・レジストリが、一つにまとめたサービス情報を用いてサービス・プロバイダを選択することを可能とする、請求項２５に記載のコンピュータ・プログラム。
27. 前記サービス要求側と前記サービス・プロバイダとの間に介在するサービス管理層を更に含み、前記サービス要求側が前記サービス・プロバイダの実際のサービス・エンドポイントを受信せずに前記サービス管理層を介して前記サービスを用いる、請求項２１から２６のいずれか１項に記載のコンピュータ・プログラム。
28. 前記サービス要求側が前記サービス・エンドポイントを受信し、直接前記サービス・プロバイダからの前記サービスを要求する、請求項２１から２６のいずれか１項に記載のコンピュータ・プログラム。
29. 前記サービス・プロバイダが仮想サーバとして提供される、請求項２１から２８のいずれか１項に記載のコンピュータ・プログラム。
30. 前記サービスが仮想アプリケーションとして提供される、請求項２１から２９のいずれか１項に記載のコンピュータ・プログラム。
31. コンピュータ読み取り可能媒体上に記憶され、デジタル・コンピュータの内部メモリにロード可能なコンピュータ・プログラムであって、前記プログラムがコンピュータ上で実行されると請求項１から１０のいずれかの方法を実行するためのソフトウェア・コード部分を含む、コンピュータ・プログラム。

Images