特許 6061936 ロケーションニュートラルソフトウェアの需要増大に伴う展開に対するシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6061936

(24)【登録日】2016年12月22日

(45)【発行日】2017年1月18日

(54)【発明の名称】ロケーションニュートラルソフトウェアの需要増大に伴う展開に対するシステム及び方法

(51)【国際特許分類】

   G06F 13/00 20060101AFI20170106BHJP

【ＦＩ】

   G06F13/00 357Z

   G06F13/00 540E

【請求項の数】21

【全頁数】25

(21)【出願番号】特願2014-531916(P2014-531916)

(86)(22)【出願日】2012年9月19日

(65)【公表番号】特表2014-535085(P2014-535085A)

(43)【公表日】2014年12月25日

(86)【国際出願番号】US2012056018

(87)【国際公開番号】WO2013043665

(87)【国際公開日】20130328

【審査請求日】2015年7月30日

(31)【優先権主張番号】61/536,826

(32)【優先日】2011年9月20日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】514069414

【氏名又は名称】イーサワークス エルエルシー

【氏名又は名称原語表記】ＡＥＴＨＥＲＷＯＲＫＳ， ＬＬＣ

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】100161148

【弁理士】

【氏名又は名称】福尾 誠

(74)【代理人】

【識別番号】100169823

【弁理士】

【氏名又は名称】吉澤 雄郎

(72)【発明者】

【氏名】ロバート フランシス マキニス

【審査官】 新田 亮

(56)【参考文献】

【文献】 特表２０１０−５１１２３６（ＪＰ，Ａ）

【文献】 特開２００６−３１８４６９（ＪＰ，Ａ）

【文献】 Paul Watson et.al，An Architecture for the Dynamic Deployment of Web Services on a Grid or the Internet，Technical Report Series CS-TR-890，２００５年 ２月 １日，p.1-13，[online], [retrieved on 2016-06-23], Retrieved from the Internet:<URL:http://www.cs.ncl.ac.uk/publications/trs/papers/890.pdf>

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

１つ以上のウェブサービスを記憶するように構成されたサービスライブラリと、
ネットワークに接続され、前記サービスライブラリ内に記憶されたウェブサービスに対する展開要求を受信して遂行するようにした１つ以上のサービスホストであって、これら展開要求を遂行することに、１つ以上のウェブサービスの１つ以上のサービスエンドポイントをインスタンス化することが含まれるようにしている当該サービスホストと、
前記サービスホストに接続され、前記１つ以上のサービスホストに関連するデータを記憶するように構成されたホストディレクトリと、
前記１つ以上のサービスホストに関連する前記記憶されたデータに基づく応答を検索するために前記ホストディレクトリに問合せし、前記記憶されたウェブサービスに基づく応答を検索するために前記サービスライブラリに問合せし、前記検索された応答に基づく展開プランを発生させ、前記発生させた展開プランに基づく展開要求を前記１つ以上のサービスホストに送信するように構成されたマネージャと、
各サービスホストの前記サービスエンドポイントのエントリを登録するとともに維持し、前記ウェブサービスと、当該ウェブサービスが展開される前記サービスエンドポイントの対応する組との間のマッピングを記憶するように構成されたディレクトリを有するディスカバリサービスと、
サービスコンシューマエージェントと
を具え、
前記サービスコンシューマエージェントは、
コンシューマエージェントと、
前記コンシューマエージェントが結合されているポイントオブプレゼンスであって、前記ディスカバリサービスと通信するように構成されているとともに、１つ以上のサービスエンドポイントに結合されるように構成されている当該ポイントオブプレゼンスと
を有するウェブサービス提供システム。

【請求項2】

請求項１に記載のウェブサービス提供システムにおいて、前記サービスライブラリは更に、前記１つ以上のウェブサービスをパブリッシャから受信するように構成されているウェブサービス提供システム。

【請求項3】

請求項１に記載のウェブサービス提供システムにおいて、前記１つ以上のサービスホストは更に、前記ウェブサービスの利用に関する情報を前記マネージャに送信するように構成されているウェブサービス提供システム。

【請求項4】

請求項１に記載のウェブサービス提供システムにおいて、前記１つ以上のサービスホストは更に、前記１つ以上のサービスホストに関連するデータを前記ホストディレクトリに送信するように構成されており、前記１つ以上のサービスホストに関連する前記データには利用可能なリソースを含めるようにしたウェブサービス提供システム。

【請求項5】

請求項１に記載のウェブサービス提供システムにおいて、前記ディスカバリサービスは更に、前記ウェブサービスの１つに対応するＵＲＩを受信するとともに、この１つのウェブサービスが展開される前記サービスエンドポイントの１つに対応するＵＲＬを要求し且つ解決するように構成されているウェブサービス提供システム。

【請求項6】

１つ以上のウェブサービスをサービスライブラリ内に記憶させるステップと、
１つ以上のサービスホストに関連するデータをホストディレクトリ内に記憶させるステップと、
前記１つ以上のサービスホストの各々における１つ以上のサービスエンドポイントでの前記１つ以上のウェブサービスの展開を、マネージャにより、制御するステップと
を具えるウェブサービス提供方法において、
ウェブサービスの展開を制御する前記ステップが、
前記記憶されたウェブサービスに基づく応答を検索するために、前記サービスライブラリに問合せするステップと、
前記１つ以上のサービスホストに関連する前記記憶されたデータに基づく応答を検索するために、前記ホストディレクトリに問合せするステップと、
前記検索された応答に基づく展開プランを発生させるステップと、
展開要求を前記発生させた展開プランに基づく前記１つ以上のサービスホストに送信するステップと、
前記展開要求に応答して前記ウェブサービスのうちの１つのウェブサービスの前記１つ以上のサービスエンドポイントをインスタンス化するステップと、
各サービスホストの前記サービスエンドポイントのエントリを、ディレクトリを有するディスカバリサービス内に登録するとともに維持するステップと、
前記ディスカバリサービスにより、前記ウェブサービスと、当該ウェブサービスが展開される前記サービスエンドポイントの対応する組との間のマッピングを記憶するステップと、
コンシューマエージェントをポイントオブプレゼンスに結合するステップであって、前記コンシューマエージェントは前記ポイントオブプレゼンスに結合され、前記ポイントオブプレゼンスは、前記ディスカバリサービスと通信するとともに、１つ以上のサービスエンドポイントに結合される、結合するステップと、
を具えているウェブサービス提供方法。

【請求項7】

請求項６に記載のウェブサービス提供方法において、この方法が更に、前記サービスライブラリにおいてパブリッシャから前記１つ以上のウェブサービスを受信するステップを具えているウェブサービス提供方法。

【請求項8】

請求項６に記載のウェブサービス提供方法において、この方法が更に、前記ウェブサービスの利用に関する情報を前記１つ以上のサービスホストから前記マネージャに送信するステップを具えているウェブサービス提供方法。

【請求項9】

請求項６に記載のウェブサービス提供方法において、この方法が更に、前記１つ以上のサービスホストに関連する前記データを、前記１つ以上のサービスホストから前記ホストディレクトリに送信するステップを具え、前記１つ以上のサービスホストに関連する前記データは、利用可能なリソースを有するようにするウェブサービス提供方法。

【請求項10】

請求項６に記載のウェブサービス提供方法において、この方法が更に、前記ディスカバリサービスで、前記ウェブサービスの１つに対応するＵＲＩを受信するとともに、この１つのウェブサービスが展開される前記サービスエンドポイントの１つに対応するＵＲＬを要求し且つ解決するステップを具えているウェブサービス提供方法。

【請求項11】

コンシューマエージェントをポイントオブプレゼンスに結合するステップと、
所望のウェブサービスのＵＲＩに対応するサービスエンドポイントに対応するＵＲＬを解決するために、前記ポイントオブプレゼンスを介してディスカバリサービスと通信するステップと、
前記ポイントオブプレゼンスを前記サービスエンドポイントに結合するステップと
を具えるウェブサービス消費方法において、
前記ディスカバリサービスは、マネージャと通信するように構成され、このマネージャは、１つ以上のサービスホストに関連するホストディレクトリ内に記憶されたデータに基づく応答を検索するためにホストディレクトリに問合せし、サービスライブラリ内に記憶されたウェブサービスに基づく応答を検索するために前記サービスライブラリに問合せし、前記検索された応答に基づく展開プランを発生し、展開及び展開解除要求を前記発生させた展開プランに基づく１つ以上のサービスホストに送信するように構成され、１つのサービスホストは、前記サービスエンドポイントをインスタンス化するように構成されており、
前記ディスカバリサービスは、ディレクトリを有し、該ディレクトリは、各サービスホストの前記サービスエンドポイントのエントリを登録するとともに維持し、前記ウェブサービスと、当該ウェブサービスが展開される前記サービスエンドポイントの対応する組との間のマッピングを記憶するように構成されているウェブサービス消費方法。

【請求項12】

請求項１１に記載のウェブサービス消費方法において、前記ホストディレクトリは、前記１つ以上のサービスホストに関連するデータを記憶するように構成されているウェブサービス消費方法。

【請求項13】

請求項１１に記載のウェブサービス消費方法において、前記サービスディレクトリは、少なくとも前記所望のウェブサービスを記憶するように構成されているウェブサービス消費方法。

【請求項14】

実行時に１つ以上のコンピュータデバイスがウェブサービス提供方法を遂行するようにするコンピュータ実行可能命令を含む非一時的コンピュータ可読媒体であって、前記ウェブサービス提供方法は、
１つ以上のウェブサービスをサービスライブラリ内に記憶するステップと、
１つ以上のサービスホストに関連するデータをホストディレクトリ内に記憶させるステップと、
前記１つ以上のサービスホストの各々における１つ以上のサービスエンドポイントでの前記１つ以上のウェブサービスの展開を、マネージャにより、制御するステップと
を具えており、ウェブサービスの展開を制御する前記ステップが、
前記記憶されたウェブサービスに基づく応答を検索するために、前記サービスライブラリに問合せするステップと、
前記１つ以上のサービスホストに関連する前記記憶されたデータに基づく応答を検索するために、前記ホストディレクトリに問合せするステップと、
前記検索された応答に基づく展開プランを発生させるステップと、
展開要求を前記発生させた展開プランに基づく前記１つ以上のサービスホストに送信するステップと、
前記展開要求に応答して前記ウェブサービスのうちの１つのウェブサービスの前記１つ以上のサービスエンドポイントをインスタンス化するステップと、
各サービスホストの前記サービスエンドポイントのエントリを、ディレクトリを有するディスカバリサービス内に登録するとともに維持するステップと、
前記ディスカバリサービスにより、前記ウェブサービスと、当該ウェブサービスが展開される前記サービスエンドポイントの対応する組との間のマッピングを記憶するステップと、
コンシューマエージェントをポイントオブプレゼンスに結合するステップであって、前記コンシューマエージェントは前記ポイントオブプレゼンスに結合され、前記ポイントオブプレゼンスは、前記ディスカバリサービスと通信するとともに、１つ以上のサービスエンドポイントに結合される、結合するステップと
を具えているようにした非一時的コンピュータ可読媒体。

【請求項15】

請求項１４に記載の非一時的コンピュータ可読媒体であって、更に、前記サービスライブラリにおいてパブリッシャから前記１つ以上のウェブサービスを受信するステップを具えている非一時的コンピュータ可読媒体。

【請求項16】

請求項１４に記載の非一時的コンピュータ可読媒体であって、更に、前記ウェブサービスの利用に関する情報を前記１つ以上のサービスホストから前記マネージャに送信するステップを具えている非一時的コンピュータ可読媒体。

【請求項17】

請求項１４に記載の非一時的コンピュータ可読媒体であって、更に、前記１つ以上のサービスホストに関連する前記データを、前記１つ以上のサービスホストから前記ホストディレクトリに送信するステップを具え、前記１つ以上のサービスホストに関連する前記データは、利用可能なリソースを有するようにした非一時的コンピュータ可読媒体。

【請求項18】

請求項１４に記載の非一時的コンピュータ可読媒体であって、更に、前記ディスカバリサービスで、前記ウェブサービスの１つに対応するＵＲＩを受信するとともに、この１つのウェブサービスが展開される前記サービスエンドポイントの１つに対応するＵＲＬを要求し且つ解決するステップを具えている非一時的コンピュータ可読媒体。

【請求項19】

実行時に１つ以上のコンピュータデバイスがウェブサービス消費方法を遂行するようにするコンピュータ実行可能命令を含む非一時的コンピュータ可読媒体であって、前記ウェブサービス消費方法は、
コンシューマエージェントをポイントオブプレゼンスに結合するステップと、
所望のウェブサービスのＵＲＩに対応するサービスエンドポイントに対応するＵＲＬを解決するために、前記ポイントオブプレゼンスを介してディスカバリサービスと通信するステップと、
前記ポイントオブプレゼンスを前記サービスエンドポイントに結合するステップと
を具えており、
前記ディスカバリサービスは、マネージャと通信するように構成され、このマネージャは、前記１つ以上のサービスホストに関連するホストディレクトリ内に記憶されたデータに基づく応答を検索するためにホストディレクトリ問合せし、サービスライブラリ内に記憶されたウェブサービスに基づく応答を検索するために前記サービスライブラリに問合せし、前記検索された応答に基づく展開プランを発生し、展開及び展開解除要求を前記発生させた展開プランに基づく１つ以上のサービスホストに送信するように構成され、１つのサービスホストは、前記サービスエンドポイントをインスタンス化するように構成されており、
前記ディスカバリサービスは、各サービスホストの前記サービスエンドポイントのエントリを登録するとともに維持し、前記ウェブサービスと、当該ウェブサービスが展開される前記サービスエンドポイントの対応する組との間のマッピングを記憶するように構成されているディレクトリを有する
非一時的コンピュータ可読媒体。

【請求項20】

請求項１９に記載の非一時的コンピュータ可読媒体において、前記ホストディレクトリは、前記１つ以上のサービスホストに関連するデータを記憶するように構成されている非一時的コンピュータ可読媒体。

【請求項21】

請求項１９に記載の非一時的コンピュータ可読媒体において、前記サービスディレクトリは、少なくとも前記所望のウェブサービスを記憶するように構成されている非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サービス指向型コンピューティング（計算）、特にウェブ（Web）サービスアーキテクチャに関するものであるが、このウェブサービスアーキテクチャに限定されるものではない。

【0002】

[関連出願の相互参照]
本出願は、２０１１年９月２０日に出願された出願番号61/536,826の米国特許仮出願の優先権を主張するものであり、この米国特許仮出願の内容は、参考のために導入されるものである。

【背景技術】

【0003】

サービス指向型コンピューティング（Service-Oriented Computing；ＳＯＣ）は、柔軟で動的なビジネスプロセスと、組織化及びコンピューティングプラットフォームに及ぶアジャイルアプリケーションとを生ぜしめるように疎結合しうるサービス網へのアプリケーションコンポーネントのアセンブリを推進させるものである。サービス指向型コンピューティングは、密結合されたコンポーネントベースの分散システムを、サービス業務に対するアドレス指定、結合及び行使に対し同様な技術を用い得る広いサービス網に発展させる手法として出現している。

【0004】

サービス指向型コンピューティングによれば、自律性及び異質性への傾向を反映する新たなアーキテクチャを生ぜしめる方法を提供しうる。サービス指向型コンピューティングの柔軟で疎結合された処理を可能としうる分散型アーキテクチャは、サービス指向型アーキテクチャ（Service-Oriented Architecture;ＳＯＡ）称することができ、そのソフトウェアサービスが主要構成要素となる。ＳＯＡの指標特徴は、疎結合された自律性サービスと、マクロ（サービス）レベルでのコードの再利用の推進と、アーキテクチャのコンポーザビリティとの間の相互運用である。

【0005】

ＳＯＡは、３つのプライマリーエンティティ（基本的な実体）、すなわちプロバイダ、コンシューマ及びレジストリより構成することができる。プロバイダは、レジストリ中のサービスロケーション（サービス位置）をパブリッシュ（publish）でき、コンシューマは、プログラムするサービスを位置決めして起動するのにレジストリを用いることができる。ＳＯＡの実装により、サービスを記述するのに用いられる言語を特定し、サービスをパブリッシュするとともに発見する手段を提供し、プロトコルを決定するとともにこれらプロトコルとの相互作用を達成するのに用いられる通信機構を決定することができる。インターネット上でのソフトウェアサービスの展開が、“ウェブサービス”として総称的に知られているような一組（セット）の基準を用いて益々達成されるようになってきている。

【0006】

ウェブサービスはプラットフォーム非依存型基準、例えば、Ｗ３Ｃワーキンググループの取り組みにより開発された基準に基づくようにしうる。これらの基準は、プロトコルと、メッセージフォーマットと、サービス記述言語とを規定することができ、これらにより、クライアントと、異種のコンピューティングプラットフォームに関するサービスとの間の相互作用をインターネット上で達成するようにしうる。

【0007】

ウェブサービスにより導入される基準によれば、分散システムを、密結合された分散アプリケーションから、疎結合されたサービスシステムに発展させる手段を提供しうる。また、これらの基準は、良好に規定されたインターフェースを用いたメッセージの交換による異種のコンピューティングプラットフォーム間の相互運用を達成しうる。プラットフォーム非依存型ウェブサービス基準は、実装及びホスティング技術を抽出することにより、現存する異種サービスに対するアクセスを均質化するとともに、何れかの特定の実装又はホスティング技術を採用することを強要することなく新たなサービスを開発することを推進する手段を提供しうる。ウェブサービスモデルは広く採用されているが、その期待値は少なくとも２つの制約により弱められるおそれがある。

【0008】

第１に、ウェブサービスモデルが固定され、信頼性の高いホストとのネットワーク化された信頼性の高い環境に対してのみ適したものとなるおそれがある。従って、インターネット上でのホストのダイナミズム及び誤謬性を考慮しそこなうおそれがあり、ホスト障害に対して堅牢とすることを目的とするアプリケーションにおいて障害回復コードが幾つも存在するようになるおそれがある。第２に、サービスプロバイダの役割が過剰であり且つその仕様が曖昧であることが、独占所有権のある展開システムの開発や、ウェブサービスの使用が付随的なものにすぎない閉ざされた世界環境をもたらすおそれがある。これらの２つの欠点を抱えると、ウェブサービスモデルを広く採用することにより、ウェブサービスインターフェースをエクスポーズ（expose）するが、展開システム及びホスティング環境を必要とする点で殆ど両立しえないアプリケーションにより、ソフトウェアサービスのランドスケープが著しくポピュレートされるようになるおそれがある。

【発明の概要】

【発明が解決しようとする課題】

【0009】

従って、改良したウェブサービスアーキテクチャが必要となる。

【課題を解決するための手段】

【0010】

本発明の要旨の一態様では、ウェブサービス提供システムが、１つ以上のウェブサービスを記憶するように構成したサービスライブラリを設ける。ネットワークに接続される１つ以上のサービスホストは、サービスライブラリに記憶されるウェブサービスに対する展開及び展開解除要求を受信するとともに遂行するようにする。これら展開及び展開解除要求の遂行には、ウェブサービスの１つ以上のエンドポイントをインスタンス化することを含めることができる。サービスホストに接続されるホストディレクトリは、サービスホストに関連するデータを記憶するように構成する。マネージャは、ホストディレクトリ及びサービスライブラリに問合せし、展開プランを発生し、展開及び展開解除要求をサービスホストに送信するように構成する。

【0011】

本発明の一例においては、サービスライブラリは、ウェブサービスを、パブリッシャ（Publisher）から受信するように構成することができる。サービスホストは、ウェブサービスの利用に関する情報をマネージャに送信するようにしうる。サービスホストは、１つ以上のサービスホスト、例えば利用可能なリソース（資源）に関連するデータをホストディレクトリに送信しうる。

【0012】

本発明の一例では、ウェブサービス提供システムが、各サービスホストに対応するエンドポイントのエントリを登録するとともに維持するように構成しうるディレクトリを有するディスカバリサービスを具えるようにしうる。ディレクトリサービスは、ウェブサービスと、当該ウェブサービスが展開されるエンドポイントの対応する組との間のマッピングを記憶しうる。ディレクトリサービスは、ウェブサービスの１つに対応する統一資源識別子（ＵＲＩ）を受信するとともに、この１つのウェブサービスが展開されるエンドポイントの１つに対応するＵＲＬを要求し且つ解決するように構成しうる。

【0013】

本発明の要旨の他の態様では、ウェブサービス提供方法が、１つ以上のウェブサービスをサービスライブラリ内に記憶するステップと、１つ以上のサービスホストに関連するデータをホストディレクトリ内に記憶させるステップとを具えるようにする。このウェブサービス提供方法は、１つ以上のサービスホストの各々における１つ以上のサービスエンドポイントでの１つ以上のウェブサービスの展開及び展開解除を、マネージャにより、制御するステップを具えるようにする。ウェブサービスの展開及び展開解除を制御するこのステップは、ウェブサービスに関する情報及びサービスホストに関連するデータを検索するために、サービスライブラリ及びホストディレクトリに問合せするステップと、これら情報及びデータを用いて、展開プランを発生させるステップと、展開及び展開解除要求をサービスホストに送信するステップと、展開及び展開解除要求に応答してウェブサービスの１つ以上のサービスエンドポイントをインスタンス化するステップとを具えるようにしうる。

【0014】

本発明の要旨の更に他の態様では、ウェブサービス消費方法が、コンシューマエージェントをポイントオブプレゼンスに結合するステップを具えるようにする。ポイントオブプレゼンスは、所望のウェブサービスのＵＲＩに対応するサービスエンドポイントに対応するＵＲＬを解決するために、ディスカバリサービスと通信するようにしうる。ポイントオブプレゼンスはサービスエンドポイントに結合するようにしうる。ディスカバリサービスは、マネージャと通信するようにし、このマネージャは、ホストディレクトリ及びサービスライブラリに問合せし、展開プランを発生し、展開及び展開解除要求を１つ以上のサービスホストに送信するように構成する。

【図面の簡単な説明】

【0015】

【図1】本発明の要旨によるウェブサービスを提供するシステムの一実施例のサービスプロバイダ部分を示す線図である。

【図2】本発明の要旨によるウェブサービスを提供するシステムの一実施例のディスカバリサービス及びサービスプロバイダ部分を示す線図である。

【図3】本発明の要旨によるウェブサービスを提供及び消費するシステムの一実施例のサービスコンシューマ（消費者）、ディスカバリサービス及びサービスプロバイダを示す線図である。

【図4】本発明の要旨によるウェブサービスを提供及び消費する方法の一実施例を示す流れ図である。

【図5】本発明の要旨の一実施例による、サービスコンシューマとローカルのポイントオブプレゼンス（ＰＯＰ）との間の代表的な相互作用を示す線図である。

【図6】本発明の要旨の一実施例による、パブリッシャとサービスライブラリとの間の代表的な相互作用を示す線図である。

【図7】本発明の要旨の一実施例による、サービスホストとホストディレクトリとの間の代表的な相互作用を示す線図である。

【図8】本発明の要旨の一実施例による、ポイントオブプレゼンスとアクティブサービスディレクトリとの間の代表的な相互作用を示す線図である。

【図9】本発明の要旨の一実施例による、アクティブサービスディレクトリとマネージャとの間の代表的な相互作用を示す線図である。

【図10a】本発明の要旨の一実施例による、マネージャとサービスライブラリとの間の代表的な相互作用を示す線図である。

【図10b】本発明の要旨の一実施例による、マネージャとホストディレクトリとの間の代表的な相互作用を示す線図である。

【図10c】本発明の要旨の一実施例による、マネージャとサービスホストとの間の代表的な相互作用を示す線図である。

【図10d】本発明の要旨の一実施例による、マネージャとサービスホストとの間の代表的な相互作用を示す線図である。

【図10e】本発明の要旨の一実施例による、マネージャとアクティブサービスディレクトリとの間の代表的な相互作用を示す線図である。

【図11】本発明の要旨の一実施例によるエンドポイントの展開を示す線図である。

【図12】本発明の要旨の一実施例によるサービスの起動を示す線図である。

【図13】本発明の要旨の一実施例による需要増大に伴う動的展開を示す線図である。

【発明を実施するための形態】

【0016】

図面全体に亘って同じ参照符号は、特に注釈しない限り、図示の実施例における同様な機能、要素、コンポーネント（構成素子）又は部分を示すのに用いられているものである。更に、本発明の要旨を図面に関して詳細に説明するが、これは図示の実施例に関するものであり、本発明をこれらに限定するものではない。

【0017】

ここで用いる用語“アクタ”とは、アクションを起こす（処置を講じる）のに応答しうるエンティティを称しうるものである。例えば、アクタには自動コンピュータプログラムを含めることができる。或いはまた、“アクタ”は、コンピュータのオペレータにより制御するのに適したユーザインターフェースを有するコンピュータプログラムを称しうるものである。

【0018】

ここで用いる用語“インフラストラクチャ”とは、ここで述べる動作状態で存在するアーキテクチュアの構成要素を総称しうるものであり、これは如何なる特定の実装（インプリメンテーション）にも依存しないものである。

【0019】

ここで用いる用語“ウェブサービス”とは、ネットワークを通じたソフトウェアサービスの展開を称しうるものである。また、ここで用いる用語“ウェブサービス”はネットワークを通じたソフトウェアサービスの展開に限定されるものではない。その理由は、当業者にとって明らかなように、このようなサービスは、ローカルエリアネットワークＬＡＮ等のような他のネットワークにおいても展開させることができる為である。

【0020】

本発明の要旨に関連しているウェブサービスに対して、記述用としたある種類の基準（ＷＳＤＬ（Web Service Definition Language））と、広告（宣伝）及び発見用としたある種類の基準（ＵＤＤＩ（Universal Description, Discovery and Integration））と、通信用としたある種類の基準（ＳＯＡＰ（Simple Object Access Protocol））とを説明の目的で記載するが、本発明はこれらに限定されるものではない。当業者にとって明らかなように、ＲＥＳＴ（REpresentational State Transfer）のような他の適切な基準を用いることができ、本発明は以下の説明に限定されるものではない。

【0021】

ウェブサービスはＳＯＡＰを用いてメッセージの交換をする相互作用を行うことができる。ＳＯＡＰは、プログラミング言語及びプラットフォームに依存しないウェブサービスに対する通信プロトコルを規定するものであり、この通信プロトコルは広範囲の転送プロトコルに亘って用いることができる。例えば、ＳＯＡＰ over ＨＴＴＰは、ウェブサービスの定義を結合（バインディング）する基準プロトコルとして用いることができる。

【0022】

ＳＯＡＰメッセージには、メッセージに対する名前空間を規定する“エンベロープ”と称しうるouter ＸＭＬ要素と、メッセージングフレームワークに対する何らかの適切な拡張子を有する任意のヘッダ要素と、必要とするボディ要素とを含むことができる。ボディ要素は、情報を最終のＳＯＡＰレシーバに送信するが、この役割を越えて特定されず、明確な構造又は解釈も、なすべき何らかの処理を特定する手段もない機構を提供しうるものである。

【0023】

ＷＳＤＬは、ウェブサービスをＸＭＬで記述する用語である。サービスのコンポーネントインターフェース記述は、ウェブサービスエンドポイントを位置決めし、このエンドポイントに結合（バインド）し、このエンドポイントと相互作用させるのに必要とする情報を含めることができるＷＳＤＬ文書として実現しうる。ＷＳＤＬ文書は、ウェブサービスエンドポイントをこれらの動作に関して記述するＸＭＬ文書要素と、（型の定義を含む）各動作のパラメータ及び戻り値と、通信に用いるプロトコル及びデータバインディング（データ結合）から構成される。

【0024】

リクエスタエージェントソフトウェアは、例えば、特定の言語でプロキシ又は“スタブ”コードを生成させる自動コード生成ツールを用いてエンドポイントのＷＳＤＬ文書に対して記述しうる。これらは、ジャバ（Java）に対する“WSDL to Java”のようなスタンドアローンツールや、コードをPerl、Ｃ＋＋、Ｃ＃、ＰＨＰ、等で生成するジェネレータに対しプラグ接続可能なフレームワークを生じるビジュアルスタジオ（Visual Studio）及びエクリプス（Eclipse）におけるようなＩＤＥベースのものとすることができる。

【0025】

本発明の要旨の代表的な実施例を図１、図２、図３及び図４を参照して以下に記載するが、これらは説明の為のものであり、本発明を限定するものではない。

【0026】

代表的な実施例で図１を参照するに、ウェブサービスを提供するシステムにサービスプロバイダコンポーネント１１０を設けることができる。このサービスプロバイダコンポーネント１１０は、例えば、コンピュータプログラムで具現化しうる。コンピュータプログラムは、ＣＤ‐ＲＯＭ、ＤＶＤ、磁気ディスク、ＲＯＭ、ＲＡＭ、等のようなコンピュータ可読媒体に記憶させることができる。プログラムの命令は、例えば、ネットワーク又は分散コンピュータシステムに接続されたサーバのような１つ以上のコンピューティングデバイス内に含まれる１つ以上のプロセッサのメモリ内に読み込むことができる。実行に際し、プログラムはコンピューティングデバイスの種々のコンポーネントを制御することをプロセッサに命令することができる。プログラム中の一連の命令を実行することにより、ここに開示するある機能をプロセッサが遂行するようにするが、本発明の要旨の実装用のソフトウェア命令の代わりに又はこれと組み合わせて配線回路を用いることができる。従って、本発明の実施例は、ハードウェアとソフトウェアとの特定の如何なる組み合わせにも限定されるものではない。

【0027】

代表的な実施例では、サービスプロバイダコンポーネント１１０には、例えば、１つ以上のウェブサービスを記憶しうるように構成したサービスライブラリ１３０を設けることができる。このサービスライブラリ１３０は、例えば、パブリッシャ１６０に接続することができ、このパブリッシャ１６０はウェブサービスを記憶のためにサービスライブラリ１３０に対し“パブリッシュ”しうる。ネットワークに接続されたサービスホスト１４７は、サービスライブラリ１３０内に記憶されたウェブサービスに対する展開及び展開解除要求を受け且つ遂行するように適合させることができる。例えば、展開及び展開解除要求を遂行するのに、１つのウェブサービスの１つ以上のエンドポイント１４３のインスタンス化（具体化）を含めることができる。ホストディレクトリ１２０はサービスホスト１４７に接続することができ、１つ以上のサービスホスト１４７に関連するデータを記憶するように構成しうる。マネージャ１５０は、ホストディレクトリ１２０及びサービスライブラリ１３０に問合せ（クエリ）し、展開プランを発生させ、展開及び展開解除要求をサービスホスト１４７に送信することができる。

【0028】

サービスホスト１４７は、ウェブサービスの利用に関する情報をマネージャ１５０に送信するように構成しうる。サービスホスト１４７は、これらの利用可能なリソースに関連するデータをホストディレクトリ１２０に送信するように構成することもできる。

【0029】

この代表的な実施例では、ウェブサービス提供能力を、互いに独立した複数の役割に分割し、各アクタにとって必要とするドメインに関する知識の量を低減させ、ウェブサービスを提供するのに参加することに関する障壁を低下させることにより、ウェブサービスのライフサイクル中の参加者に対する複雑性を低減させることができる。例えば、ウェブサービスをパブリッシング、展開及びホスティングするタスクを個別的で独立する活動として処理しうる。従って、サービスプロバイダコンポーネント１１０を３つの個別的な“アクタ”、すなわちパブリッシャ１６０、マネージャ１５０及びサービスホスト１４７とみなすことができるが、このことは説明のためのものであり、本発明をこれに限定するものではない。その他に、２つのアーキテクチャエンティティ、すなわちサービスライブラリ１３０及びホストディレクトリ１２０と称するリポジトリが存在している。

【0030】

ウェブサービスプロバイダエージェントによる実装は、明示的に展開させるのに代えて、パブリッシャ１６０により記述しうるようにでき、この場合パブリッシャ１６０が、この実装をサービスライブラリ１３０と称するリポジトリ内に記憶させることによりインフラストラクチャ内に“パブリッシュ”する。この方法は、サービスの実証を実際の具現化から分離させることによるウェブサービスの展開に対する方法を表す。すなわち、ウェブサービスのライフサイクルを、その展開時ではなくそのパブリッシュ時から開始するようにしうる。

【0031】

インフラストラクチャに参加するために、サービスホスト１４７は、これらの利用可能なリソースを記述するとともにホストディレクトリ１２０と称するリポジトリに登録することにより、これらサービスホストの意思をホストのウェブサービスに登録しうる。サービスホスト１４７は、これらの利用可能なウェブサービス展開コンテナを表すとともに、パブリッシャ１６０のリスト、すなわちこれらサービスホストが展開しようとしているウェブサービスプロバイダエージェントによる実装を特定することができる。従って、サービスホスト１４７は、これらの静的に展開されるサービスを広告するのではなく、デマンドレベルが変化するのに対応させる必要がある際にマネージャ１５０により動的に消費（及びリクレイム）しうる潜在的なホスティングリソースの共用プールを結合するこれらのホスティング能力を広告することにより、インフラストラクチャに参加することができる。

【0032】

マネージャ１６０は、（いつでも０個以上のエンドポイント１４０を存在させうる）単一のウェブサービスのプロビジョニング（提供）レベルを管理する責任を負う場合がある。マネージャ１６０は、展開を成立させるために、最初にサービスライブラリ１３０及びホストディレクトリ１２０に問合せし、次いでウェブサービスの実装を適切に有能であるサービスホスト１４７と組合せることにより展開計画を立てるようにしうる。このマネージャ１６０は、展開要求をサービスホスト１４７に送信し（ステップ４３３）、これによりこのサービスホスト１４７がウェブサービスのエンドポイント１４０をインスタンス化する（又は要求を拒否する）責任を負う場合がある。サービスホスト１４７は、これらのドメイン内で展開される各ウェブサービスのエンドポイントの利用に関する情報を各ウェブサービスのマネージャ１５０に提供しうる。マネージャ１５０はこの利用データを用いて、これらが管理するウェブサービスが必要とするプロビジョニングレベルに関して決定を行うことができる。

【0033】

代表的な他の実施例で図２を参照するに、ウェブサービスを提供するシステムには、ディスカバリサービスコンポーネント２１０を設けることができる。このディスカバリサービスコンポーネント２１０は、例えば、サービスプロバイダコンポーネント１１０と同様に、コンピューティングデバイスで実行されるコンピュータプログラムで構成することができる。このコンピューティングデバイスは、インターネットのようなネットワークを介してサービスプロバイダコンポーネント１１０に結合された、このサービスプロバイダコンポーネント１１０のコンピューティングデバイスとは異なる物理的に分離したデバイスとすることができる。或いはまた、ディスカバリサービスコンポーネント２１０をホスティングするコンピューティングデバイスは、サービスプロバイダコンポーネント１１０をホスティングするコンピューティングデバイスと同じにすることができる。特に、これらのコンピューティングデバイス及びここに記載する全ての他のコンピューティングデバイスは、本発明の精神及び範囲内で単一のデバイス、デバイスの集合、ネットワーク等として構成しうる。

【0034】

ディスカバリサービスコンポーネント２１０には、アクティブサービスディレクトリ２２０を設けることができる。このアクティブサービスディレクトリ２２０は例えば、サービスライブラリ１３０内に記憶されたウェブサービスと、ウェブサービスが展開されているエンドポイント１４３の対応する組との間のマッピングを記憶するように構成しうる。

【0035】

アクティブサービスディレクトリ２２０は、単一のウェブサービスとこのウェブサービスの一組の能動的なエンドポイント１４３との間のマッピングを保持しうる。アーキテクチュアにおける中心となるエンティティ、すなわちアクティブサービスディレクトリ２２０に保持された集合的なマッピングにより、全ての参加者の見通しからのインフラストラクチャの現在の状態を表すことができる。全てのインフラストラクチャの参加者はアクティブサービスディレクトリ２２０に頼ることにより所望のウェブサービスのエンドポイント１４３を位置決めしうる為、このディレクトリは、現在展開されているエンドポイントを有さないウェブサービスに対する自動展開処理を開始するようにしうる。

【0036】

アクティブサービスディレクトリ２２０は、ウェブサービスのアクティブなエンドポイント１４３を加え、除去し及び検索する動作を提供しうる（ステップ４５０）。アクティブサービスディレクトリ２２０が特定のウェブサービスのアクティブなエンドポイントに対する検索要求を受けるが、このようなエントリが存在しない場合には、アクティブサービスディレクトリ２２０は積極的に位置決めして、要求されたウェブサービスのマネージャ１５０に情報提供する。マネージャは、前述した展開処理を用いて新たなエンドポイント１４３の展開を動的に開始しうる。このマネージャ１５０は、これが管理するウェブサービスの新たに展開される如何なるエンドポイント１４３にも対する全てのアクティブサービスディレクトリ２２０のエントリを挿入及び維持するために応答しうる。例えば、ウェブサービスに対するデマンドがゼロに減少する場合には、マネージャ１５０は、展開されるエンドポイント１４３の１つ（又は全て）を展開解除することを決定することができる。エンドポイント１４３が展開解除された場合には、マネージャ１５０はこのエンドポイントのエントリをアクティブサービスディレクトリ２２０から除外し、このディレクトリが更新状態を保ち、インフラストラクチャの現在の状態をできるだけ正確に反映するようにしうる。

【0037】

代表的な更に他の実施例で図３を参照するに、ウェブサービスを提供するシステムにはサービスコンシューマコンポーネン３１０を設けることができる。このサービスコンシューマコンポーネン３１０は、例えば、サービスプロバイダコンポーネント１１０と同様に、コンピューティングデバイスで実行されるコンピュータプログラムで構成することができる。このコンピューティングデバイスは、インターネットのようなネットワークを介してサービスプロバイダコンポーネント１１０に結合された、このサービスプロバイダコンポーネント１１０のコンピューティングデバイスとは異なる物理的に分離したデバイスとすることができる。或いはまた、サービスコンシューマコンポーネント３１０をホスティングするコンピューティングデバイスは、サービスプロバイダコンポーネント１１０をホスティングするコンピューティングデバイスと同じコンピューティングデバイスの部分にすることができる。

【0038】

サービスコンシューマコンポーネント３１０には、コンシューマエージェント３２０とポイントオブプレゼンス３３０とを設けることができる。ディスカバリサービスコンポーネント２１０は、例えば、サービスライブラリ１３０内の１つ以上のウェブサービスに対応するＵＲＩを受信し、存在する場合には展開されたウェブサービスのエンドポイント１４３に対応する１つ以上のＵＲＬを要求するとともにこれを解決するように構成することができる。特定のウェブサービスの複数の実装を、ある実施例と関連してサービスライブラリ１３０に対しパブリッシュしうる。これらの実装の各々は、同じＵＲＩに対応する。特定のウェブサービスは、例えば、多数の異なる言語を用いるか、又は１つ以上の異なる展開環境を要求するか、或いはこれらの双方を行って実装することができる。これらの実装の各々は、サービスライブラリ１３０内に記憶させることができるとともに、同じＵＲＩに対応させることができ、しかもこれらの実装の各々により同じインターフェースを実装し、特定の実装の何れか１つに対する呼出しにより同じ返答をもたらし得るようにする。コンシューマエージェント３２０はポイントオブプレゼンス３３０に結合させることができる。ポイントオブプレゼンス３３０はディスカバリサービスコンポーネントと通信することができるとともに、ＵＲＬを用いてエンドポイント１４３に結合させることができる。このポイントオブプレゼンス３３０は、サービスロケーションに関して抽象化するとともにコンシューマエージェント３２０のビューを維持し、これによりウェブサービスのインスタンス化へのコンシューマエージェントに対するゲートウェイとして作用するように構成することができる。

【0039】

この代表的な実施例に関してここに開示する技術では、ウェブサービスを記述するのにＵＲＬを用いる必要がないようにする。その理由は、ＵＲＬは時間と共に無効となるおそれがある為である。その代り、如何なる時点でも０個以上のアクティブエンドポイントを有しうるサービスを抽象的に記述するＵＲＩでウェブサービスを識別しうるようにする。サービスコンシューマコンポーネント３１０では、サービスエンドポイント１４３に対する位置決め及び結合のタスクをサービスコンシューマコンポーネントの代わりに遂行する機構を導入することにより、これらのタスクを取除くことができる。

【0040】

この技術によれば、起動要求に含まれるＵＲＩからライブエンドポイントＵＲＬを透過的に解決しうるウェブサービスの消費に対し制限されたメディエーションフレームワークを提供しうる。このフレームワークは、上述したように且つ図３に示すように、アーキテクチュアである“ポイントオブプレゼンス”のインスタンス化へのゲートウェイとして作用しうるサービスコンシューマコンポーネント３１０に存在するプロキシ機構として実現しうる。コンシューマエージェント３２０のソフトウェアは、このローカルのポイントオブプレゼンス３３０に結合されるとともに、所望のウェブサービスのＵＲＩを用いてウェブサービスの動作を呼出すように書き表すことができる。ポイントオブプレゼンス３３０は、ウェブサービスのアクティブエンドポイントのリストをアクティブサービスディレクトリ２２０から検索し、使用するエンドポイントを選択し、サービスコンシューマコンポーネント３１０のために必要な動作を呼出し、何らかの結果を戻すことにより、ＵＲＩからＵＲＬを透過的に解決するために応答しうるようにできる。また、これは、ウェブサービスが展開されるサービスホスト１４７及びこれらウェブサービスの不履行を透過的に検出及び回復させたり、（ローカルポリシーに応じて）他のエンドポイント１４３を再試行することによりこれらの不履行を積極的に回復させたりするように応答しうるようにもすることができる。回復不能なエラーはサービスコンシューマコンポーネント３１０に戻し、インフラストラクチャのリソースが利用可能であると仮定して、現在では要求を満足できないということを表すようにすることができる。

【0041】

ポイントオブプレゼンス３３０は、サービスロケーションに関して抽象化しうるとともに、依然としてコンシューマ３１０のビューをシステム上に維持することができる。例えば、ディベロッパーがウェブサービスを、これが現在展開されているか展開されていないかに拘らず、プログラミングするようにすることにより、コンシューマエージェント３２０のアプリケーションを簡単化することができる。更に、ディスカバリサービスコンポーネント２１０との相互作用を必要とする全てのタスクを消費する為、ポイントオブプレゼンス３３０は、インフラストラクチュアで用いられる特定の標準バージョン（例えば、ＵＤＤＩバージョン）に関して抽象化層を提供しうる。これにより、標準の発展に直面して陳腐化することに対する障壁を提供しうるとともに、コンシューマエージェントのアプリケーションを、異なる標準を用いている環境間でのポータブルアプリケーションとすることができる。

【0042】

代表的な更に他の実施例で図４を参照するに、ウェブサービスを提供する方法には、１つ以上のウェブサービスをサービスライブラリ内に記憶するステップ（ステップ４１０）を設けることができる。サービスライブラリは例えば、パブリッシュされたウェブサービスをパブリッシャから受信しうる（ステップ４１１）。１つ以上のサービスホストに関連するデータは、ホストディレクトリ内に記憶させることができる（ステップ４２０）。例えば、ホストディレクトリは、サービスホストに関連するデータ、例えば、サービスホストがホスティングをしようとしているパブリッシャからの利用可能なリソースに関するデータを受信することができる（ステップ４２２）。マネージャは、各サービスホストにおけるサービスエンドポイントに関するウェブサービスの展開及び展開解除を制御しうる（ステップ４３０）。例えば、マネージャは、ウェブサービスに関する情報及びサービスホストに関連するデータを検索するためにサービスライブラリ及びホストディレクトリに問合せしうる（ステップ４３１）。次いで、マネージャは、ウェブサービスに関する情報及びサービスホストに関連するデータを用いて展開プランを発生させることができる（ステップ４３２）。次いで、マネージャは、展開及び展開解除要求をサービスホストに送信しうる（ステップ４３３）。次いで、サービスホストは展開要求に応答してウェブサービスをインスタンス化するか（ステップ４３４）、又は展開解除要求に応答してウェブサービスをインスタンス化解除しうる。利用データ及びその他の情報はサービスホストからマネージャにフィードバックすることができる（ステップ４４０）。

【0043】

マネージャは、ウェブサービスを展開するエンドポイントに関する情報を、アクティブサービスディレクトリを含むディスカバリサービスコンポーネントに送信しうる（ステップ４５０）。サービスコンシューマは、ＵＲＩ要求を、例えばローカルのポイントオブプレゼンスを介してディレクトリサービスに送信しうる（ステップ４６０）。このディレクトリサービスはマネージャと関連して、ＵＲＩ要求に応答してＵＲＬ応答を生じることができ（ステップ４７０）、サービスコンシューマは所望のウェブサービスをホスティングするエンドポイントに結合しうるようになる。

【0044】

ここに開示するシステムのあるコンポーネント間の代表的な相互作用に関し図５〜図１０を参照して以下に記載するが、これは説明の目的のためであり、本発明をこれに限定するものではない。

【0045】

本発明の要旨の実施例によれば、図５を参照するに、サービスコンシューマ３１０は、必ずしもウェブサービスのエンドポイントと直接相互作用する必要はない。例えば、サービスコンシューマ３１０は、ローカルのポイントオブプレゼンス３３０に結合させ、その動作を起動させることができる。ＰＯＰはサービスコンシューマ３１０とコロケートすることができる。すなわち、コンシューマエージェント３２０は、例えば、プロトコル、ホスト名及びローカルＵＲＩのポートが付されたウェブサービスのＵＲＩへの静的な結合を達成させるように書き表すことができる。

【0046】

例えば、ＵＲＩ“ServiceA”により識別されるウェブサービスの動作“ｘ”を起動することを図５に示す。コンシューマエージェントのアプリケーションはＰＯＰに結合させ、その動作を起動させることができ、次いでこのＰＯＰが要求されたウェブサービスのエンドポイントを位置決めすることができる。ＰＯＰは、ＵＲＩ“ServiceA”をパラメータとして有する“findAll”動作（“全てを見い出せ”という動作）を起動させることにより検索要求をアクティブサービスディレクトリ２２０に送信することができるとともに、“ServiceA”（５４１、５５１及び５５２）の現在能動的であるアクティブエンドポイント５４０及び５５０を記述しているサービスインスタンスディスクリプタのリストを受信しうる。ＰＯＰは、エンドポイントに接続してサービスコンシューマのために動作“ｘ”を起動する前に、どのエンドポイントを選択するかのローカルポリシーをユーザに供給することができる。この動作の結果をＰＯＰに戻し、最終的にコンシューマエージェント３２０のアプリケーションに戻すことができる。

【0047】

本発明の要旨の実施例によれば、図６を参照するに、パブリッシャ１６０は、ウェブサービスの実装をパブリッシュ及びアンパブリッシュ（パブリッシュ解除）するためにサービスライブラリ１３０と相互作用するサービスコンシューマとしうるが、必ずしもこのようにする必要はない。パブリッシャ１６０には、他のサービスコンシューマ（例えば、３１０）と同様に、コンシューマエージェント６１０及びポイントオブプレゼンス６２０を設け、外部の如何なるウェブサービスとも直接相互作用する必要がないようにし、その代りローカルのポイントオブプレゼンス６２０を介して所望の動作を起動させるようにすることができる。

【0048】

例えば、（サービスインプリメンテーションディスクリプタで記述された）ウェブサービスの実装をパブリッシュするために、パブリッシャ１６０をローカルのポイントオブプレゼンス６１０に結合させ、所望のサービスインプリメンテーションディスクリプタを有するサービスライブラリ１３０の“publishServiceImplementation”（サービスインプリメンテーションをパブリッシュせよ）の動作を起動しうる。インプリメンテーション（実装）がパブリッシュされると、このインプリメンテーションが直ちに使用しうるようになり、需要を満足させるのに必要な可能なサービスホスト上で展開しうるようになる。

【0049】

本発明の要旨の実施例によれば、図７を参照するに、サービスホスト１４７は、サービスプロバイダの役割に寄与することと、サービスコンシューマとしても作用することとの双方を達成するようにしうるが、必ずしもこのようにする必要はない。サービスホスト１４７には、他のサービスコンシューマ（例えば、３１０）と同様に、コンシューマエージェント７１０及びローカルのポイントオブプレゼンス７２０を設けることができる。このサービスホスト１４７自体には、例えば、ホストディスクリプタを用いてホストディレクトリ１３０を記述することによりこのホストディレクトリ１３０を登録し、このサービスホスト１４７が、ローカルのポイントオブプレゼンス７２０に結合され、ホストディレクトリ１３０の“addAuthorizedPublisher”（認可されたパブリッシャを加える）の動作を起動するようにしうる。従って、ローカルのポイントオブプレゼンス７２０を介してサービスホスト１４７を動作させることにより登録処理を遂行でき、同じ起動処理をインフラストラクチュアにより全てのサービスコンシューマに提供しうる。登録時には、サーバホストのホストディスクリプタを、需要を満足させるのに必要なものとして消費する準備のあるホスティングリソースの共用プールに加えることができる。

【0050】

本発明の要旨の実施例によれば、図８を参照するに、何れかのサービスコンシューマ３１０と関連するポイントオブプレゼンス３３０は、サービスコンシューマ３１０のためのウェブサービスに関し位置決めし、結合し、動作を起動しうるトランスペアレントのエンドポイントレゾリューション及び障害回復システムとしうる。例えば、ウェブサービスのアクティブインスタンスを位置決めするために、ポイントオブプレゼンスを“アクティブサービスディレクトリ”８１０と称するウェブサービスと相互作用させ、ウェブサービスのＵＲＩをパラメータとして有するその“findOne”動作（“１つを見い出せ”という動作）又は“findAll”動作（“全てを見い出せ”という動作）の何れかを起動させるようにする。

【0051】

アーキテクチュアのインスタンス化に関与するためには、ローカルのポイントオブプレゼンスがアクティブサービスディレクトリの少なくとも１つのエンドポイント８１０の予備知識を有するようにしうる。アクティブサービスディレクトリの如何なる他のエンドポイントも、ウェブサービスのＵＲＩ“Active Service Directory”の下でアクティブサービスディレクトリ２２０内にリストアップすることができるとともに、“findOne”及び“findAll”動作を用いて位置決めすることができる。ＰＯＰは、失敗時に使用するために、アクティブサービスディレクトリの他のエンドポイントのリストを検索し且つ記憶させるようにすることができる。

【0052】

本発明の要旨の実施例によれば、図９を参照するに、アクティブサービスディレクトリ２２０が、ゼロのアクティブエンドポイントを有するウェブサービスに対する検索要求を受信すると、このウェブサービスのマネージャ１５０のインスタンスを位置決めしてエンドポイントを展開しうるようにする。アクティブサービスディレクトリ２２０は、そのローカルのポイントオブプレゼンスに結合し、且つ最初に要求されたウェブサービスに対し応答しうるマネージングエントリ９２０のＵＲＩを用いてアクティブサービスディレクトリ“findOne”又は“findAll”動作を起動することにより、独自の検索機能を利用することができる。このＵＲＩは、例えば、“Manager ”のＵＲＩを要求されたウェブサービスのＵＲＩに連結させてパターン“WebServiceURI_ManagerURI”が得られるように構成することができる。アクティブサービスディレクトリは、“Manager”インターフェースを実装するウェブサービスのエンドポイントを記述するサービスインスタンスディスクリプタ（ServiceInstanceDescriptor）を返信することができる。

【0053】

マネージャ１５０は、これらが管理しているウェブサービスのディレクトリの記録を維持する責任を負う場合がある為、マネージャ１５０は、これらが展開している如何なるエンドポイントの記録をも、アクティブサービスディレクトリ２２０内に挿入しうるようにする。マネージャ１５０は、この動作を、例えば“requestFirstInstance”（“第１のインスタンスを要求せよ”）の起動により遂行し、展開及び登録処理の全体が成功裏に終了された場合には“true”を返信し、その他の場合には“false”を返信する。“false”を返信する“requestFirstInstance”動作は、システムが現在の状況にあると、ウェブサービスの新たなインスタンスを展開することができないということを表すことができる。この状態は、要求中のエンティティ（すなわち、サービスコンシューマ）に返信しうる回復不能なエラーを表しうる。動作により“true”を返信する場合には、アクティブサービスディレクトリ２２０は最初に要求された検索動作を再遂行し、新たに挿入されたサービスインスタンスディスクリプタを要求中のエンティティに返信することができる。

【0054】

本発明の要旨の実施例によれば、図１０を参照するに、マネージャ１５０は、以下に例示的な説明するように（この説明に限定されない）、サービスライブラリ１３０、ホストディレクトリ１２０、１つ以上のサービスホスト１４７及びアクティブサービスディレクトリ２２０を有する種々のコンポーネントと通信することができる。例えば、図１０ａを参照するに、マネージャ１５０は、展開されるウェブサービスの一組の実装を検索するためにサービスライブラリ１３０の動作を起動することができる。これらの実装の各々を、サービスインプリメンテーションディスクリプタで記述することができる。すなわち、このディスクリプタのエレメントを後にマネージャ１５０により用いて、展開用の適切な候補の実装を選択することができる。

【0055】

同様に図１０ｂを参照するに、マネージャ１５０は、展開処理中にホストディレクトリ１２０の動作を起動することができる。マネージャ１５０は、ホストディレクトリ１２０を用いて、指示されている（例えば、固有のパブリッシャＩＤにより指示されている）パブリッシャ１６０によりパブリッシュされたウェブサービスの実装を展開しようとしているサービスホスト１４７を識別する一組のホストディスクリプタを検索することができる。マネージャ１５０は、サービスライブラリ１３０から検索されたサービスインプリメンテーションディスクリプタと、ホストディレクトリ１２０から検索されたホストディスクリプタとを比較して、ローカルポリシーに基づく適切な候補の展開プランを作成することができる。プランが選択されると、マネージャ１５０は選択されたサービスホスト１４７と連絡し、展開処理を開始することができる。

【0056】

図１０ｃを参照するに、マネージャ１５０は、（ホストディスクリプタで記述された）選択したサービスホスト１４７における展開に対し（サービスインプリメンテーションディスクリプタで記述された）適切なウェブサービスの実装を選択した後に、ホストディスクリプタに含まれるサービスホスト１４７に結合しうるとともに“展開”（“deploy”）動作を直接起動しうる。展開が成功すると、サービスホスト１４７は、新たに展開したウェブサービスのエンドポイントを記述するサービスインスタンスディスクリプタをマネージャ１５０に返信しうる。マネージャ１５０は次いで、このサービスインスタンスディスクリプタをアクティブサービスディレクトリ２２０内に登録し、展開処理を終了させることができる。

【0057】

図１０ｄを参照するに、上述したこととは相違し、サービスホスト１４７はこれらのドメイン（例えば、これらの制御下にあるコンテナ）内で展開される各ウェブサービスのエンドポイントに対し、利用データをそのウェブサービスのマネージングエントリに報告しうる。サービスホスト１４７はローカルのポイントオブプレゼンス７２０に結合しうるとともに、“Manager”のＵＲＩをデータが報告されているウェブサービスのＵＲＩに連結させる（例えば、“WebServiceURI_ManagerURI”を得る）ことにより識別されるウェブサービスの“reportUsageData”動作（“利用データを報告せよ”の動作）を起動しうる。この“reportUsageData”動作は、この特定のウェブサービスに対する利用データを次に報告するまでサービスホスト１４７が待つ必要がある時間長を表す数値を返信しうる。サービスホスト１４７のローカルポリシーは、（ワーキングメモリのようなローカルのリソースコンテナのために）利用データが要求よりも早期に返信されることを指示しうる。要求された期間よりもかなり遅くデータを返信させることにより、サービスホスト１４７に関する問題、すなわちサービスの利用可能性を有効に管理するためにマネージャ１５０が決定しうる情報に関する問題があることをマネージャ１５０に指示することができる。

【0058】

図１０ｅを参照するに、ウェブサービスのマネージャ１５０がこのウェブサービスのエンドポイントを成功裏に展開又は展開解除すると、アクティブサービスディレクトリ２２０内にエンドポイントリファレンスを加えるか又はこのアクティブサービスディレクトリ内のエンドポイントリファレンスを除去することができる。マネージャ１５０は、ローカルのポイントオブプレゼンスに結合し且つ適切なサービスインスタンスディスクリプタを用いてアクティブサービスディレクトリ２２０のウェブサービスの“addActiveService”動作（“アクティブサービスを加えよ”という動作）又は“removeActiveService”動作（“アクティブサービスを除去せよ”という動作）を起動することができる。

【0059】

例えば、マネージャ１５０は、これらが管理するウェブサービスのアクティブサービスディレクトリのエントリを維持する責任がある場合がある。サービスプロバイダの責任を満足させる全てのエンティティのうち、マネージャ１５０はこれらの各々が管理するウェブサービスの正確な公的な記録を、維持する上で最も関心があるものとみなしうる。その理由は、ウェブサービスのプロビジョニングレベルを管理するこれらの責任を履行する場合に決定する上でより重要な情報となりうる正確な利用データをこれらに与えることができる為である。

【0060】

以下の実施例により本発明を更に説明する。この実施例の使用は例示的なものであり、本発明又は如何なる例示用語の範囲及び意味を制限するものではない。同様に、本発明はここに開示する如何なる特定の好適実施例に限定されるものでもない。実際に、本発明の多くの変形例は、本明細書を読んだ当業者にとって明らかである。本発明は、特許請求の範囲の権利となる全等価範囲とともにこの特許請求の範囲により理解すべきである。

【0061】

本例では、図１１、図１２及び図１３を参照するに、前述した代表的なコンポーネントの相互作用を、“DayTime”（“デイタイム”）と称するウェブサービスを提供及び起動するためのエンドポイント展開、サービスの起動及び需要増大に伴う動的展開に対する単一ステップとして用いて、手続きを説明する。

【0062】

新たなウェブサービスのエンドポイントの展開は、図１１におけるように、マネージャ１５０により実行しうる。マネージャ１５０は、新たな“DayTime”ウェブサービス１１００のエンドポイント１１２０を使用可能にするために、サービスライブラリ１３０、ホストディレクトリ１２０、１つ以上のサービスホスト１４７及びアクティブサービスディレクトリ２２０と相互作用する。

【0063】

説明のためで本発明を限定するものではないが、新たなウェブサービスのエンドポイントを展開するために、マネージャ１５０は最初に有効な展開プラン（例えば、ホストディスクリプタ内に記述された“機能”と整合した“要求”を有するサービスインプリメンテーションディスクリプタを具える展開プラン）を作成及び選択しうる。マネージャ１５０は、サービスライブラリ１３０にコンタクト（連絡）し且つ“DayTime”ウェブサービスのパブリッシュされた全ての実装の組を検索することから開始しうる。返信される各実装は、サービスインプリメンテーションディスクリプタ１１３０であって、その各々が“パブリッシャＩＤ”（“PnblisherID”）のエレメント１１３１を有している当該サービスインプリメンテーションディスクリプタにより記述しうる。マネージャ１５０は、各実装に対し、パブリッシャＩＤ１１３１を用いてホストディレクトリ１２０とコンタクトするとともに、特定のパブリッシャにより書表されているプロバイダエージェントアプリケーションを展開しようとしているサービスホストの組を検索することができる。マネージャ１５０は次いで、有効な展開プランの組を作成するとともに、ローカルポリシーに基づく候補の中から１つを選択することができる。マネージャ１５０は次いで、展開プランを実行し、選択されたホストディスクリプタ１１５０により記述されたサービスホスト１４０にコンタクトさせ、選択されたサービスインプリメンテーションディスクリプタ１１３０でその“展開”動作を起動させることができる。展開が成功すると、目標とするサービスホスト１４７は、エンドポイント１１２０を記述するサービスインスタンスディスクリプタ１１６０をマネージャ１５０に返信しうる。マネージャ１５０は、サービスインスタンスディスクリプタ１１６０をアクティブサービスディレクトリ２２０内に挿入することにより展開を終了させることができる。新たに展開されるエンドポイントがアクティブサービスディレクトリ２２０内にリストアップされると、これを展開し、位置決めする準備状態にあり、その動作をサービスコンシューマにより起動されるものとみなしうるものである。

【0064】

図１２を参照するに、サービスコンシューマ３１０によるサービス起動には、ローカルのポイントオブプレゼンス３３０における結合及び起動用のウェブサービス動作を含めることができる。ローカルのポイントオブプレゼンス３３０は、起動要求を受信するのに応答して、目標のウェブサービスのアクティブエンドポイントを位置決めするとともに、サービスコンシューマのために要求された動作、例えば、“DayTime”ウェブサービス１１１０の “getTime”（“ゲットタイム”）動作を起動する。

【0065】

ローカルのポイントオブプレゼンス３３０は、コンシューマエージェント３２０のアプリケーションから起動要求を受信すると、最初に、到来する要求から所望のウェブサービスＵＲＩ１２１０を抽出しうる。ポイントオブプレゼンス３３０がエンドポイントキャッシュを実装する場合には、このポイントオブプレゼンスは最初に、以前に検索したエンドポイントのリストを局部的に検査しうる。このようなエントリが存在しない場合には、アクティブサービスディレクトリ２２０を用いて新たなリストを検索しうる。エンドポイントのリストが検索されると、ポイントオブプレゼンスは、ローカル選択ポリシーに応じて使用するための１つを選択しうる。次に、ポイントオブプレゼンス３３０は、（メッセージに対する可能な変更を含む）起動要求を準備し、選択されたウェブサービスのエンドポイントに結合し、起動要求を送付する。起動が何らかの理由で失敗すると、残りのアクティブエンドポイントに対し同じ処置を試みることができ、全てのエンドポイントが利用できないと分かると、一般的なエラーをサービスコンシューマ３１０に返信しうる。起動が成功すると最初に、サービスコンシューマ３１０に返信して起動処理を結論付ける前に、（この場合もメッセージに対する変更を含むことのできる）結果の応答を準備しうる。

【0066】

図１３を参照するに、需要増大に伴う動的システムでは、例えば、現在アクティブエンドポイントが存在しないウェブサービスの動作の起動を含む現存の又は予期される事象に応答してエンドポイントの展開を生ぜしめることができる。このような状況では、図１１及び図１２を参照して上述した要旨を遂行しうる。例えば、アクティブサービスディレクトリ２２０が“DayTime”ウェブサービス１１１０の全てのエンドポイントに対する要求を受信すると、このアクティブサービスディレクトリは、現在何も展開されていないことを見つけることができる。このように、アクティブサービスディレクトリ２２０は、要求されたウェブサービスの第１のインスタンスの展開を、このウェブサービスのマネージャ１５０とコンタクトするとともに“requestFirstInstance”動作（“第１のインスタンスを要求せよ”という動作）を起動することにより（必ずしも成立されないが）開始しうる。この時点で、展開処理を上述したようにして実行しうる。すなわち、マネージャ１５０が“requestFirstInstance”動作から戻されると、アクティブサービスディレクトリ２２０は検索を再実行するとともに、新たに展開されたエンドポイント１１２０に対するリファレンスと、インフラストラクチュア中に現在利用できるリソースがあるものとした場合に所定時に要求を満足し得ないということを表すエラーとの何れかを返信することができる。

【0067】

説明したように、ウェブサービスを展開しうるようにするためには、マネージャ１５０はこのウェブサービスに対し現在展開するようにする必要はない。ウェブサービスとして実装が行なわれ、一般的又はカスタムとした或いはまたその双方としたサービス特有のマネージャの実装がサービスライブラリ１３０内にパブリッシュされた場合には、マネージャがこれらの特定のウェブサービスを管理するのに用いるのと同じ展開機構を用いて、ウェブサービスのマネージャを展開及び管理することができる。この再帰的でコラプシブルなモデルは、ウェブサービスインフラストラクチュアが、需要を満足するのに充分なウェブサービスのエンドポイントを提供するように“ワウンドアップ”（“wound up”）となり、しかも需要がゼロに減少する場合にゼロのリソース消費の状態に“ワウンドダウン”（“wound down”）となるようにしうる。

【0068】

幾つかの実施例と関連して上述したように、幾つかのコンポーネント、例えば、１１０、２１０及び３１０には、種々の機能を実行するためにコンピュータ、プロセッサ、回路網、モバイル機器、クラスタ又はその他のハードウェアを設けうる。更に、本発明の要旨の幾つかのエレメントは、コンピュータ可読媒体に記録しうるとともに実行した際にプロセッサが幾つかの機能を実行するようにするコンピュータ可読コードで構成することができる。これらの実施例では、コンピュータが、ウェブサービスの提供及び消費の双方又は何れか一方を達成してこのようなサービスをネットワーク、例えば、インターネットを介して提供するシステム及び方法を可能にする際の重要な役割を奏する。例えば、コンピュータ、プロセッサ、メモリ、記憶装置及びネットワークハードウェアの存在により、ウェブサービスの環境を展開、消費及び管理するとともに、コンシューマの測定需要に基づいてリソースを動的に適用及び再要求する能力を提供するものである。

【0069】

更に、幾つかの実施例と関連して上述したように、幾つかのコンポーネントは、例えば、ネットワーク、例えば、インターネットを介して幾つかの他のコンポーネントと通信しうる。明確に上述していないが、本発明の要旨は、送信及び受信を含む各トランザクションの両側を含むようにするものである。上述した特徴事項に関して、あるコンポーネントが他のコンポーネントに送信、供給又は利用しうるようにする場合には、他のコンポーネントは明瞭に述べられているか否かを受信又は取得することを、当業者は容易に理解しうるものである。

【0070】

本発明の要旨の範囲は、ここに記載した特定の実施例により限定されるものではない。実際に、ここに述べた実施例以外の本発明の要旨の変形例は、上述した記載及び添付図面から当業者にとって明らかとなるものである。このような変形例も特許請求の範囲に入るものである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10a】

【図10b】

【図10c】

【図10d】

【図10e】

【図11】

【図12】

【図13】