JP2007299424A - オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合 - Google Patents

オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合 Download PDF

Info

Publication number
JP2007299424A
JP2007299424A JP2007190218A JP2007190218A JP2007299424A JP 2007299424 A JP2007299424 A JP 2007299424A JP 2007190218 A JP2007190218 A JP 2007190218A JP 2007190218 A JP2007190218 A JP 2007190218A JP 2007299424 A JP2007299424 A JP 2007299424A
Authority
JP
Japan
Prior art keywords
service
tpsp
resource
handle
resources
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2007190218A
Other languages
English (en)
Inventor
Gerd Breiter
ゲルト・ブライター
Jutta Dr Kreyss
ドクトア・ユッタ・クライス
Andrea Schmidt
アンドレア・シュミット
Tamar Eilam
タマー・アイラム
Sandra D Miller
サンドラ・ディー・ミラー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2007299424A publication Critical patent/JP2007299424A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Computer Hardware Design (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】複数のサード・パーティ・サービス・プロバイダ（ＴＰＳＰ）が、クライアントが要求したサービスへの可能な寄与として１つまたは複数のオンデマンド・サービス（ＴＰＳＰサービスと呼ぶ）の提供に関与する、方法およびシステムを提供する。
【解決手段】サービス・プロバイダ（ＳＰ）によって提供されるＴＰＳＰサービスの選択を容易にするために、メタサービス・セレクタ（ＭＳＳ）を呼び出して、最良のＴＰＳＰサービスを選択するステップ（７１０）と、ＴＰＳＰサービスのそれぞれの要求プロパティを照会する照会要求をＴＰＳＰに送信するステップ（７３０）と、所定の格付け（７８０）方式に従って、前記複数のＴＰＳＰから照会されたサービスのプロパティ情報を評価するステップ（７７５）と、ある特定のＴＰＳＰサービスを選択し、電子ネットワークを介してサービスをＳＰの要求するクライアントに提供するステップ（７８５）と、を提案する。
【選択図】図７

Description

本発明は、ネットワーク接続されたコンピュータ・アプリケーションの分野に関し、サービス・プロバイダからサービスを要求するクライアントへ、電子ネットワークを介してオンデマンド・サービスを提供する方法およびそれぞれのシステムであって、１つまたは複数のサード・パーティ・サービス・プロバイダ（ＴＰＳＰ）が、前記クライアントが要求したサービスへの寄与として１つまたは複数のオンデマンドＴＰＳＰサービスを提供することに関与する方法およびシステムに言及する。
本明細書においてＯＤＳと呼ばれるオンデマンド・サービス、またはこのようなＴＰＳＰサービスは、契約に基づいて所与のＴＰＳＰ加入者に提供されるどの種類の情報技術（ＩＴ）機能でもよい。契約は、明示的にも暗黙でも作成することができる。サービスは、使用量または料金に基づくモデルに対する一定の条件で、ＴＰＳＰ加入者に利用される。
オンデマンド計算機環境において、提供プロバイダは、そのプロバイダ自身または他のプロバイダによって提供されるオンデマンド・サービスの販売を望む。ＴＰＳＰサービスの統合は、以下の理由により、提供プロバイダに多大な事業機会を与える。
第１に、統合により、新しいオンデマンド・サービスを配信するための時間が大幅に削減される。第２に、プロバイダが、はるかに広範かつ豊かなオンデマンド・サービスの組を提供することが可能になり、したがって市場におけるプロバイダの注目度が増す。最後に、プロバイダは、ＴＰＳＰから得られるサービスに必要とされるリソースを維持するコストを被らなくてよいので、プロバイダの損害の恐れが大幅に低下する。
現況技術では、ＴＰＳＰサービスをプロバイダによる提供サービスに統合するには、多大な努力が要求される。標準化が行われていないので、ＴＰＳＰサービスはしばしば、提供プロバイダがこのようなサービスをそのプロバイダ自体の提供サービスに統合するときを厳守する必要がある、独占的なアクセス機構を有する。プロバイダが所有するリソース、またはＴＰＳＰからの遠隔サービスおよびリソースに対する共通のアクセス機構が存在しない。この複合性の結果、多くのプロバイダが、その提供サービスにＴＰＳＰサービスを全部は統合しないことを選択する。
エンド・ユーザの視点から見たオンデマンド・コンピューティングも、ＩＴ事業における非常に新しい機能である。名前が示すように、この手法は、ＩＴリソースを、実際に必要とされる規模で、企業が実際にどの事業目的も達成するためにこのようなリソースを使用する必要があるまさにその時点で使用できるようにすることを試みる。企業が、必要に応じてＩＴリソースを使用し、次いで、どの事業目標も達成することを可能にする。オンデマンド・サービスの適用が成功すると、サービスを要求する企業には、コストの節約になる。というのは、プロバイダが購入し、保持しているＩＴ機器は、サービスを要求する企業が、事業の性質に応じてやむを得ず、実際にはほとんど使われないこのようなＩＴ基盤を独自に購入した場合と比較してかなり簡素なものだからである。
この非常に新しい技術における現況技術は、ほとんど目にすることがない。インターネットのウェブ・サイトで入手可能な、
http://wwws.sun.com/software/sunone/innercircle/newsletter/feature0303.html、または
http://it.sun.com/eventi/jc03/pdf/parallela_7/giorno_28/N1_at_Java_Conference.pdf、および
http://docs.sun.com/db/doc/806-4777
において、オンデマンド・サービスの要件を最もよく満たすための方法を記述する、リソースの仮想化手法が開示されている。
以下の段落では、本発明の基礎として提示する必要がある、主要なすべての関与構成要素に関する現況技術による手法を説明する。
図１を参照すると、図１は、ＳＰのサービス環境の現況技術によるシステム、およびＳＰによって保持される複数のリソース・マネージャとの関係を示す概略図表示であり、各サービスは、本明細書においてＳＥとさらに呼ばれるサービス環境１０に直接関連づけられる。ＳＥは、サービスを遂行するのに必要な、複数のリソース１６３、１６５、１７３、１７５、１７７、１８３、１８５、またはこうしたリソースの何らかの集合体を表す。ＳＥは、必要とされるリソースを作成／管理／削除するためのオペレーショナル・データを、専用データベース１４ならびに１組のワークフロー１３中に含む。
リソース１６３、１６５、１７３、１７５、１７７、１８３、１８５は、ハードウェア・リソース、ソフトウェア・リソース、または記憶リソースのいずれでもよい。予め定義されたリソースの有用な組合せも、単一の複合リソースとみなすことができる。ハードウェア・リソースはたとえば、コンピューティング・ノード、スイッチなどのネットワーク・リソース、およびファイアウォールである。ソフトウェア・リソースは、アプリケーションなどである。
こうしたリソースはそれぞれ、本明細書においてＲＭとさらに呼ばれるリソース・マネージャ１６、１７、１８によって管理される。ＲＭは、同じタイプのリソースからなるプールを管理することができる。
リソース・ハンドルは、その集合体が参照符号１２で示され、リソース・インスタンス・サービスを識別し、サービス環境の、リソース・ハンドルの集合体中に保持される。
さらに図２を参照すると、図２は、ＳＰサービス環境と、ある特定のリソースへのアクセス権を有するある特定のリソース・マネージャとの間の、このような現況技術による相互動作の基本機能を示す現況技術の概略図表示であり、オンデマンド・サービスにおいて使用するための、ＳＥへのリソースの統合は、現況技術ではリソース・マネージャ（ＲＭ）１６を介して行われる。この統合の抽象レベルは、対処すべき問題の範囲に応じて、それぞれのリソース・マネージャ開発者によって選択することができる。
リソース・インスタンスとは、所定の時点で所望のサービスを遂行するために集められ、そのサービスに専用のリソースの特殊な組合せである。図２には、リソース・インスタンスは示していない。
各リソース・インスタンスは、たとえば図１に１６２で示した、上述したリソース・インスタンス・サービス（ＲＩＳ）によって制御される。ＲＩＳ１６２は、たとえば１６で示したＲＭによって作成される。リソース１６３およびＲＩＳ１６２は、プロバイダによって所有され、プロバイダの構内に保持される。ただし、リソース１６３およびＲＩＳ１６２は、ローカルでも、プロバイダが所有するいくつかの位置に分散してもよい。
当業読者に対して、本発明の目的を伝え、ＴＰＳＰサービス統合の複雑さおよび難しさを説明するために、現況技術の問題を説明する、起こり得る一般的なシナリオを検討する。
ＳＰが、ＯＤＳとして、Lotus（商標）WorkspaceMessaging製品によるウェブ・メール・サービスの提供を望んでいると仮定する。この提供プロバイダは、異なる３種類のウェブ・メール、すなわちプラチナ、ゴールド、およびシルバー・サービスの構築を望んでいる。こうした異なる３つのサービスは、各ユーザが利用可能な記憶容量、およびメールのバックアップ頻度によって変わる。たとえば、シルバー・ユーザは最大６０ＭＢ、ゴールド・ユーザは９０ＭＢ、プラチナ・ユーザは１２０ＭＢを得る。シルバー・ユーザのバックアップ頻度は月に一度であり、ゴールド・ユーザの場合は週に一度であり、プラチナ・ユーザの場合は１日に一度である。
プロバイダは、基盤、リソース、およびツールを有し、また、バックアップ・サービスを除く提供サービスの構成要素すべてを提供するのに必要な知識を有する。この点までは、プロバイダは、こうした３つ（ゴールド、プラチナ、シルバー）のサービスを提供するためであるとともに、バックアップ・サービスを除くサービスに対して課金を行うためのオンデマンド基盤のセットアップに関しては問題がない。このサービスは、このプロバイダの現在の専門技術の一部ではなく、このプロバイダは、社員の能力に対して投資することも、必要とされる記憶装置に投資することも希望しないものと仮定する。
この時点で、プロバイダは性急に、この機能を提供するＴＰＳＰサービスを探し、複数のＴＰＳＰサービスがある場合は、どのＴＰＳＰサービスを選択するか決定しようとする。
最後に、必要とされるバックアップ・サービスを提供する複数の、たとえば６個のＴＰＳＰがみつかる。おそらく、こうしたＴＰＳＰサービスは、独占的なインターフェースを有すると仮定することができる。このインターフェースをウェブ・メールを提供することに統合することはしたがって、必要とされる準備およびプログラミング作業のせいで、ＳＰにとって多大な労力となる。その結果、ＳＰは多くの場合、この労力を費やすことも、不都合には最良のサービス提供を選択することもできないと思われる。
http://wwws.sun.com/software/sunone/innercircle/newsletter/feature0303.html http://it.sun.com/eventi/jc03/pdf/parallela_7/giorno_28/N1_at_Java_Conference.pdf http://docs.sun.com/db/doc/806-4777
したがって、本発明の目的は、統合的な解決法のために、請求項１のプリアンブルによる、所望のＳＰサービスにとって最良のＴＰＳＰサービスを人間の介入なしに自動的にみつけるための方法を提供することである。
第１に、以下の開示は、ＳＰのサービス環境への、ＴＰＳＰサービスの全体的な「自動包含」を可能にするために行われる。
本発明の概念の基本的な利点によると、提供プロバイダにとって最大の利益は、遠隔リソースおよびサービスのカプセル化および自動的な統合から生じ、この統合は、この共通アクセス・インターフェースを提供するリソース・マネージャを介して、本発明によって最もよく提供される。
さらに、異なるＴＰＳＰサービスによって同様の機能を提供する１組のリソース・マネージャは、追加構成要素によって結合することができ、この追加構成要素は、リソース・マネージャによって提供されるこのＴＰＳＰサービスの組からの、１つのＴＰＳＰサービスの選択を処理する。この選択は、ＳＰによって指定された選択基準に準拠する。この選択については、第２の好ましい実施形態において後でより詳しく説明する。
有利には、前記汎用インターフェース定義は、ＳＰ側での、
ａ）前記ＴＰＳＰに対して、前記ＴＰＳＰサービス用ハンドルを要求するステップと、ｂ）前記ＴＰＳＰサービスを遂行するのに専用のリソース・インスタンス・サービス、へのハンドルを含む前記要求、への応答を受信するステップと、
ｃ）前記リソース・インスタンス・サービスによって定義されたリソース、を割り振るための割振り命令を発行するステップと、
ｄ）前記割り振られたリソースに関連づけられたアクセス・インターフェースを介して、前記ＴＰＳＰサービスを利用するステップと、
ｅ）前記使用済みリソースに対する割振り解除命令を発行するステップと
の実施を可能にする。
したがって、ＴＰＳＰ側での本発明の方法のそれぞれの相対部を含む、本発明の分散性により、前記汎用インターフェース定義は、ＴＰＳＰ側での、
ａ）前記ＳＰから、前記ＴＰＳＰサービス用ハンドルの要求を受信するステップと、ｂ）前記要求されたハンドルに関連づけられたリソース・インスタンス・サービスを作成するステップと、
ｃ）要求元ＳＰに、前記要求されたハンドルを発行するステップと、
ｄ）前記リソース・インスタンス・サービスによって定義されたリソース、を割り振るための割振り命令を受信するステップと、
ｅ）前記リソースが使用可能な場合、前記命令されたリソースを割り振るステップと、ｆ）前記割り振られたリソースに関連づけられたアクセス・インターフェースを介して、前記割り振られたリソースを使用するための使用コマンドを受信するステップと、ｇ）前記使用済みリソースに対する割振り解除命令を受信するステップと、
ｈ）前記使用済みリソースの割振りを解除するステップとの実施を可能にする。
こうすることによって、それ自体のサービス環境に含まれるオンデマンド・サービスを利用するときに必要とされる少なくとも基本的な特徴を含む効果的な共同が、ＳＰとＴＰＳＰとの間で可能になる。
さらに、前記汎用インターフェース定義が、リソースに登録するステップと、登録を解除するステップの実施をさらに可能にすると、より一層複雑な事業状況にまで利用分野が拡大され、そこでは、クライアントが所望のサービスを何らかの形で確保することを予約するのに慣れており、また、もしこのサービスを利用するのが非常に遅れる可能性がありそうなら、またはその可能性がある時、最終的な決定を行うことが望まれる。
さらに有利なことには、リソース・インスタンスが別のサービスを含む場合、本発明の原理は基本的に、第４、第５などのＳＰからの複数のサービスの連鎖を起こすために維持することができる。こうした後続のＴＰＳＰ間のサービスは、それぞれのリソース・マネージャを用いることによって、やはり含めることができる。
前記汎用インターフェース定義が、ＴＰＳＰで使用可能なリソースの可用性に関するＳＰ情報を開示するステップの実施を可能にする場合、ＳＰは、始めに、提供されるサービスを目にし、異なるプロバイダの提供サービスとおそらく比較する可能性があり、次いで、どのオンデマンド・サービスに加入するか決定する可能性がある。このことは、本発明の概念の有用性を高める。
上記の方法および方法のステップが、インターネットを介して利用可能となる、状態をもつウェブ・サービスとして実装されると、基本的に、サービス提供元の間での可能な選択範囲は急速に拡大すると思われ、多くの事業および企業において、本発明の手法の受入れが増すであろう。
上述したように、ＳＰのサービス環境への、ＴＰＳＰサービスの自動包含が可能になるので、本発明の以下の特徴が開示される。
本発明の上述した目的は、添付の独立請求項に記述する特徴によって達成される。本発明のさらに有利な構成および実施形態が、それぞれの下位請求項に記述される。ここで、添付の特許請求の範囲を参照する。
本発明の広範な態様によると、本明細書においてＭＳＳと短縮され、データ処理プログラムとして実装される、いわゆるメタサービス・セレクタを含む方法であって、類似したまたは同じ事業目的を包括するとともに、それぞれの１つまたは複数のＴＰＳＰによって電子ネットワークを介してＳＰに提供される複数の利用可能なＴＰＳＰサービスから、ある特定のＴＰＳＰサービスを選択する方法が開示され、前記方法は、ＳＰによって実施される以下のステップを特徴とする。
ａ）「メタリソース・マネージャ」と呼ばれＭＲＭと短縮される、たとえば後で説明するある特定の形のメタサービス・セレクタ（ＭＳＳ）を呼び出して、特定の評価属性および特定の何らかの評価アルゴリズムを参照する所与の評価体系に従って、最良のＴＰＳＰサービスを選択するステップ。
ｂ）以降で「サービス・プロパティ獲得要求」と呼ばれる照会要求を送信するステップ。この要求は、前記提供されるそれぞれのサービスのプロパティを所望する。すなわち、この要求は、照会されたサービスのプロパティ情報が、ＳＰ照会方法と前記ＴＰＳＰサービスとの間で合意されたインターフェース・データ体系に従ってフォーマットされた形で引き渡されることを求め、前記インターフェースは、たとえば「サービス・プロパティ獲得インターフェース」と呼ばれる。
ｃ）要求されたサービス・プロパティについての、照会された情報を受信するステップ。ｄ）所定の格付け方式に従って、前記複数のＴＰＳＰサービスから照会された情報をＭＳＳによって評価するステップ。
ｅ）ある特定のＴＰＳＰサービスを選択し、サービスを要求するクライアントに、電子ネットワークを介して提供するステップ。
本発明の方法全体が、ＳＰといくつかのＴＰＳＰとの間に分散されるので、本発明は「分散」性を有する。ＴＰＳＰで実施されるそれぞれの主なステップは、以下の通りである。
ａ）ＴＰＳＰサービスのそれぞれの要求プロパティをＴＰＳＰに照会する前記照会要求を受信するステップであって、照会されたサービスのプロパティ情報が、照会を行ったＳＰの要求と前記ＴＰＳＰサービスとの間で合意されたインターフェース・データ体系に従ってフォーマットされた形で引き渡されることを、照会要求が求めるステップ。
ｂ）照会側サービス・プロバイダに対して、照会された情報を回答するステップ。
本発明の方法は、特に、状態をもたない要求によって提供される単純な構造のＴＰＳＰサービスの供給に特に適合する。一部のストック・オプションの要求、最も安価な電話サービス提供元を介したインターネット電話、映像情報を含むインターネット・ベースの電話、インターネットを介した有料ＴＶなどが、その例である。
上記の「最良サービスの選択」は、基本的にメタサービス・セレクタ（ＭＳＳ）によって可能であり、ＭＳＳは、評価アルゴリズムおよび評価属性を参照する評価体系に従って、最良のＴＰＳＰサービスを選択するようにとの要求を受信する。ＭＳＳは、予め定義され合意された要求仕様形式に従って応答するようＴＰＳＰを促す照会要求を送信する。さらに、ＭＳＳは、実際の要求に従って自由に重みづけすることができる順位付けアルゴリズムによって、照会され受信されたＴＰＳＰサービスのプロパティ情報を処理する。
この全般的な手法の多大な利点は、電子ネットワークにおいて、ＳＰが、ある特定のＴＰＳＰサービスに対して最良の提供サービスを有するＴＰＳＰをみつけることを可能にするための、自動化された、実装が容易な手順が開示されることであり、この手順では、「最良」は、異なる優先事項に従って、自由に、非常に柔軟に定義することができる。したがって、短時間での自動的な選択は、「遅延結合」という特徴、すなわち、ＳＰが非常に「遅く」、すなわち、ＴＰＳＰサービスが実際に利用される直前に決定を行うことができる可能性を開拓する。
したがって、価格およびサービス品質情報を含む、ＳＰのサービス・プロパティを、人間の介入なく、短時間で、容易に、ある程度自動的に得ることができるので、要求される事業サービスの柔軟かつ素早いセットアップ、および要求される事業の変更に対する柔軟かつ素早い反応が得られる。
特許請求の範囲において用いられる「最良」という言葉は、サービス要求者が実際に必要とするものに応じて様々に定義することができ、たとえば、ある定義は、サービスの品質および安全性を重視し、別の定義は、サービスの価格をより重視することを理解されたい。
前記メタサービス・セレクタを実装する、基本的に２つの好ましい代替実施形態がある。第１は、インターフェースとして作用する包括リソース・マネージャ（ＧＲＭ）によって作成されたリソース・インスタンスを介して、オンデマンドＴＰＳＰサービスがカプセル化される場合である。これについては、第１の実施形態を参照して後でより詳しく説明する。本明細書において、ＴＰＳＰサービスは、ＳＰによって管理されＴＰＳＰによって開始されるリソース・インスタンス・サービスによって、ＳＰにもクライアントにも容易に利用可能になる。
第２の代替実施形態では、ＳＰと前記ＴＰＳＰとの間で合意されたインターフェース・データ体系が、要求されたＴＰＳＰサービスの部分であることを提案する。これについては、第２の好ましい実施形態において後でより詳しく説明する。
さらに有利には、照会要求が、ＴＰＳＰに関連する時間情報を指定すると、ユーザの要望が照会要求の中に一層完璧に反映されているので、本発明の方法により、一層の柔軟性および使いやすさが可能になり、エンド・ユーザであるサービス要求者は確実に利益を受けることができるという利点が生じる。
異なるタイプの時間情報の例には、以下のものがある。たとえば、ＴＰＳＰサービスを選択しなければならない時点を符号化するために、フラグを使うことができ、こうした時点は、たとえば以下の代替範囲中で変わり得る。
ａ）ＴＰＳＰサービスがＳＰによって提供される時点、
ｂ）ＳＰサービスのクライアントが、ＳＰサービスを購入したいという希望を宣言する時点であって、この宣言が、たとえばＳＰサービスに加入することによってＴＰＳＰサービスに向けられる時点、
ｃ）ＴＰＳＰサービスが初めて呼び出される時点であって、呼び出されたサービスが、要求の事業目的、即ち本明細書において「遅延結合」と呼ばれる特徴を受け取るために実際に利用される時点、または
ｄ）ＴＰＳＰサービスが呼び出される各時点。
本方法の実装アルゴリズムを含む本発明の方法ステップは、非常に高速に効率的に実施されるので、ＳＰが実際にＴＰＳＰサービスを要求する、ＴＰＳＰサービスの遅れた判定、すなわち遅延結合を実現することができる。したがって、ある特定のＴＰＳＰサービスに対して実際に決定を行う時間に関して、最大限の柔軟性が達成される。クライアントは、ＴＰＳＰサービスを提供することが高速に変化する状況において、この利点から多大な利益を受けることができる。
本発明を、例示のために説明するが、本発明は、図面の形に限定されるものではない。
図面全体を参照するが、ここでは特に、本発明による、ＳＰのサービス環境１０へのＴＰＳＰサービスの統合がどのようにして行われるかを全体的に表す図３を参照する。参照符号３０で示す、ＴＰＳＰからのリソースは、本発明に従って、ＳＰ側にあるサービス環境１０によって使用できることが当業者の読者には理解されよう。
リソースの供給を管理するとともに、ＴＰＳＰサービスの供給をカプセル化し管理するのに使うことができる、汎用の、すなわち「標準に準拠可能な」インターフェース層を有する、汎用リソース・マネージャ１６（図２を参照されたい）を採り入れた、本発明の基本的な手法を説明する。本発明のインターフェース層２０は有利には、標準に準拠することができ、プロバイダの計算機環境および提供サービスへのＴＰＳＰサービスの統合を大幅に容易にする。このことは、ＳＰ側に常駐するリソース１６３ならびにＴＰＳＰに常駐するＴＰＳＰリソース３０を囲む点線で示してある。この概略的な手法は、図４および図５に関連してさらに詳述する。
図４を参照すると、本発明の好ましい実施形態において、汎用リソース・マネージャ４０が、ＴＰＳＰ側での専用サーバ・システムとして実装され、リソース・マネージャ４０は、ＴＰＳＰからＳＰへのリソースの供給に適した、予め定義された何らかの機能を用いて、ＩＴ標準に最もよく従う、本発明のインターフェース４１を介して、図４に示していないいくつかのＳＰと通信することができる。この機能は好ましくは、図４の左側に示す、予め定義されたいくつかの方法を有するクラスとして実装することができる。１つの汎用リソース・マネージャ４０が、１つのタイプのリソースを担当する。リソース・マネージャ４０は、この汎用リソース・マネージャが担当するそのタイプのすべてのリソースを「知っている」。したがって、リソース・マネージャ４０は、管理しているタイプの１つのリソースが、必要とされるどの時間枠においても使用されないかどうか判定することができる。
この機能は、必須の関数および任意選択的な関数に分けることができるが、こうした関数は、サービスの供給を円滑にするので非常に好ましい。上述した機能は、各個別リソース・マネージャ１６、１７、１８（図１を参照されたい）によって提供されるべきである。その関数は、本発明と密接に関連する態様に言及するためにのみ、以下のように定義される。
作成関数４１０は、ある特定のサービスまたはある特定のリソース用の汎用リソース・インスタンス・サービス４２を作成し、サービス４２に対する参照を返す。この汎用リソース・インスタンス・サービス４２は、リソース・マネージャ４０によって管理されるタイプの専用リソースの管理を担当する。
削除関数４２０は、ある特定のリソースまたはある特定のサービス用の汎用リソース・インスタンス・サービス４２を削除する。
割振り関数４３０は、要求されたサービスまたはリソース用に必要とされるリソースを割り振る。この関数は、加入操作の呼出しに続いて使用することもできる。サービスまたはリソースは、両方の場合において、最終的に活動化され、使用される準備が整う。
割振り解除関数４５０は、上記のように以前割り振られたリソースまたはサービス用のリソースの割振りを解除するコールである。
加入取消し関数４６０は基本的に、加入関数の逆を表す。
可用性検出関数４７０は、ＴＰＳＰにおいて要求されたＴＰＳＰサービスを実行するのに必要とされる、使用可能な全リソースを探索する。この機能は、提供されるオンデマンド・サービスを実行するのに必要とされる、リソースの予約を必要とする。たとえば、ＲＭごとに使用可能なサービスが、関係データベース・アプリケーション中に列挙され保持される場合、関数４７０は、容易に実装することができる。
上記の機能により、本発明による汎用リソース・マネージャ４０は、汎用リソース・インスタンス・サービス４２をインスタンス化するのに必要とされる全管理関数を実施することができる。この汎用リソース・インスタンス・サービスは基本的に、ＴＰＳＰからのＴＰＳＰサービス４８を制御する。この制御は、リソース・アクセス・インターフェースとして図４に示す、各リソース・インスタンス・サービス４２中のそれぞれの汎用リソース・インスタンス・インターフェース４３、および通常使用インターフェース４４によって実現される。ＴＰＳＰからのリソースは、前記アクセス・インターフェースを介して、後で実際に使用される。
リソース・インスタンス・インターフェース４３が、専用リソースをセットアップするのに必要とされるリソース・マネージャ・インターフェース４１の割振り（４３０）および割振り解除コール（４５０）をマッピングするので、リソース・インスタンス・インターフェース４３とリソース・マネージャ・インターフェース４１の間の関係は特殊である。この関係は、たとえば、ｚＬｉｎｕｘにおけるリソースまたはデータベースとしてｚＬｉｎｕｘサーバ全体をセットアップする際の違いを包含する。割振りコール（４３０）は、選択されたリソースのインストールおよび構成をトリガする。
さらに、契約４６は、ＳＰが基本的にＴＰＳＰサービスに加入した時点で、ＳＰとＴＰＳＰとの間で締結されることに留意されたい。正しく契約するために、契約目的ならびにその背後にある会計および課金手順に対して、一義的なキーおよび加入者ＩＤを要求に含めることが推奨され、そうすることによって、ＴＰＳＰサービスに実際に登録されることが当業者には理解されよう。
作成、削除、可用性検出、加入、加入取消し、割振り、および割振り解除の関数を有する上述した機能は、前記ＳＰと前記ＴＰＳＰ ＳＰとの間で使用される汎用インターフェース定義を実現する好ましい方法を表す。この機能は、前記インターフェース定義の構文および意味が理解され、両方のプロバイダにおいて明白に適正に適用されるように、ＳＰとＴＰＳＰとの間で合意された形でプログラミングされる。
上述した関数とともに例示的に説明した意味をもつ、提案した汎用インターフェース定義は、要求されたサービスまたはＴＰＳＰサービスをＳＰのサービス環境にカプセル化できることが、当業者には想像できよう。このカプセル化は、ＴＰＳＰで使用可能なリソースを探し、このようなリソースを確保し、または実際の割振りおよびこのようなリソースまたはサービスを利用するために、プロバイダでもＴＰＳＰでも、基本的に手作業が必要ないことによる。ＳＰとＴＰＳＰとの間のワークフローの基本的に完全な自動化により、ＴＰＳＰによって提供されるリソースおよびサービスを元のＳＰのサービス環境に統合することが可能である。したがって、この元のＳＰは、このようなＴＰＳＰサービスから容易に利益を受けることができ、ＴＰＳＰサービスをそのＳＰ自体のクライアントに転送することができる。こうすることにより、ＳＰによる独自のサービス提供を容易に拡大することができる。
したがって、より一層有利なことには、ＴＰＳＰによって維持される前記汎用リソース・マネージャ４０は、標準的な構文および意味に従う。そうすることにより、ＴＰＳＰとＳＰとの間の対話は、より一層円滑になる。
さらに、４０で示す、上述したような、またはそれと同様の汎用リソース・マネージャ機能を、状態をもつウェブ・サービスとして実装することが有利である。この特徴は、インターネットを介したこの機能の使いやすさを開拓する。
さらに図５を参照し、本発明の方法の好ましい実施形態を以下で説明する。図５は、ＳＰ側（左）およびＴＰＳＰ側（右）それぞれの部分で実装される、発明性のある方法における制御フローを示す概略ブロック図表示を示す。
好ましい本実施形態は、上述した「可用性検出」関数４７０、ならびにやはり上述した加入関数４４０および加入取消し関数４６０の有利な、任意選択的な特徴を含む。当然ながら、ＳＰとＴＰＳＰとの間の基底ワークフローの多くの変形形態が存在することができ、こうした変形形態は、本発明の方法のそれぞれの使用に応じて推奨できることを理解されたい。
以下の例示的な使用において、図５の左列にその動作を示してあるＳＰは、図５に示していないどのエンド・クライアントにも、基本的にエンド・クライアントに対して既に提供していたｅメール・サービスへのアドオンとして、追加バックアップ・サービスを提供するために、ＴＰＳＰ（図５の右列）によって提供されるバックアップ用ＴＰＳＰサービスの使用を望む。ＳＰは、バックアップ・サービスを提供するのに必要とされる、それ自体のリソースもそれ自体の知識も有していないので、このバックアップ・サービスを、ＳＰ自体のメール・サービスに追加されるＴＰＳＰサービスとして購入することを望む。
ＴＰＳＰは、そのＴＰＳＰサービスを、たとえばインターネット・ポータルにおいて提供するものと仮定され、上述した汎用リソース・マネージャは、ＴＰＳＰのそれぞれのウェブ・サーバで実装されるものと仮定される。したがって、この場合、ＴＰＳＰサービスの提供および受入れは、状態をもつウェブ・サービスとして実現される。
第１のステップ５０５で、ＳＰは、ＴＰＳＰによって提供されるサービスの全提供を要求する。この要求は、ＴＰＳＰによって維持されるそれぞれのウェブ・サイトで、それぞれのボタンをクリックするだけで行われる。したがって、ステップ５１０で、ＴＰＳＰは、このような要求を受信し、それに応答して、ＴＰＳＰが要求元ＳＰに提供するサービスのすべてを示すために、上述した「作成」および「可用性検出」機能をトリガする。したがって、ステップ５１５で、各ＴＰＳＰサービスまたはＴＰＳＰサービスのパッケージが、適用するのに有用である場合、ＳＰに対して表示される。たとえば、一群のサービスに対して、それぞれの複数の単独サービスの合計と比較して大幅な価格低減を得ることができる場合があり得る。したがって、サービスは、何らかのサービスＩＤによって区別可能でなければならない。
図６で例示的かつ概略的に示すサービスＩＤは、例示的にはデータ・セット中に含まれ、さらに有利には、そのサービスまたはＴＰＳＰサービスの説明、使用した場合の時間ごとの利用料、要求したサービスを使用するためにＳＰと契約を締結するために、ＴＰＳＰ側に対して要求される他のすべての情報、および、要求元ＳＰが、ある特定のＴＰＳＰサービスに加入するかどうか決定する前に関心をもつと思われ得る他の記述情報を含む。付加情報は、本発明の方法の個々の使用およびアプリケーションに応じて追加することができる。図６のデータ・セットはしたがって、この状況において必要とされる基本情報を定義する象徴的な意味に理解されるべきである。
したがって、ステップ５２０で、ＴＰＳＰは、要求元ＳＰへの提供サービスとして、ＴＰＳＰサービスの集合体を発行する。ＳＰに提供されるＴＰＳＰサービスを説明する上述したデータ・セットは、いつからいつまでの間、それぞれのサービスが利用可能であるか、および任意選択的には、現況技術による予約／確保システムから公知であるような、それぞれの将来のタイム・スパンにおいてサービスを利用することに重大な関心を示しているＳＰが既に登録しているかどうかを伝えるデータ・フィールドをさらに含むことができることが追加されよう。ステップ５２５で、ＳＰは、利用可能なＴＰＳＰサービスについての必要なすべての情報を、ＴＰＳＰから受信する。この情報を与えられると、ＳＰは、提供されるＴＰＳＰサービスから１つまたは複数を選択するかしないかという決定を行うのに有用な、経済的側面、動作側面などに関する、必要とされるどの検討事項も考慮することができる。したがって、ＳＰは、ステップ５３０で、選択したある特定のＴＰＳＰサービスに対するハンドルを提供ＴＰＳＰに対して要求すると仮定することができる。ウェブ・サービス環境において、ハンドルの提供は、たとえば選択されたＴＰＳＰサービスを反転表示し印をつけることによって、現況技術における従来のやり方で実装される。この選択は、手順を継続し、かつ何らかの種類の予約もしくは確保またはこのサービスの実際上即座の利用を行う可能性を開拓するために、前記ＴＰＳＰサービスに対するハンドルの要求として、電子ネットワークを介して移送される。その実装については、後で説明する。
ステップ５３５で、ＴＰＳＰは、前記選択されたＴＰＳＰサービス用の前記ハンドルを求める要求を受信し、それに続くステップ５４０で、前記要求されたハンドルに関連づけられた、いわゆるリソース・インスタンス・サービスを作成する。この作成は、本発明の特定の有利な態様に従って行われる。前記リソース・インスタンス・サービスは、たとえば、前記リソースにそれぞれのＩＤタグを提供することによって、要求を遂行するのに使用される関連するすべてのハードウェアおよびソフトウェアを識別する情報構造を有する。
ＳＰによって提供されるメール・サービスという状況においてバックアップ用ＴＰＳＰサービスを実現する、上でさらに紹介した例示的な使用において、ＴＰＳＰは、何らかのハードウェア、すなわち、何らかの処理動力に動作可能に結合されたいくつかの記憶装置と、必要とされるバックアップ用ＴＰＳＰサービスを実施するそれぞれのソフトウェア・ソリューションとを確保しなければならない。したがって、どのハードウェア・ユニットおよびソフトウェア・ユニットも、このようなリソース・インスタンス・サービスにおいて扱うことができるそれぞれのＩＤをもつべきである。そうしたＩＤがこのようなリソース・インスタンス・サービスの記述に行き渡るように、形式用の標準を作成することが有用であることに留意されたい。
ＴＰＳＰが、それ自体のリソースを関係データベース中で管理する場合を考えると、このデータベースへのそれぞれの読出しアクセスは、ＴＰＳＰに対して利用可能なそれぞれの３つのリソースを選択するように実施されなければならない。
さらに、ＴＰＳＰは、要求されたサービス用のハンドルを生成する。このハンドルは、要求されたそれぞれのＴＰＳＰサービスの存続期間中、使用されると予期されるすべてのリソースを識別するのに必要なすべての情報を含む。したがって、所与のサービス・インスタンス用の基本的な識別項目を示す図６を参照すると、たとえばハンドルは、必要なすべてのハードウェア装置、ＴＰＳＰサービス環境内部でのネットワーク接続、サービスを実施するのに必要とされるソフトウェア・ライセンスなどを記述する、例示的な数である１５個のＩＤの集合体からなることができる。それぞれの選択可能なタイム・スパンにおいて、ＴＰＳＰのリソースのどれが使用可能であり、どれが使用可能でないか判定できるように、ＴＰＳＰはこうしたすべてのＩＤを管理することが要求されることが追加されよう。
次のステップ５４５で、要求されたＴＰＳＰサービス用に生成されたハンドルが、ＳＰに発行される。ＳＰは、このハンドル、たとえばＴＣＰ／ＩＰアドレス、およびパスワードを伴うユーザＩＤを、ＳＰ自体の要求への応答において受信し、受信したハンドルを、ＳＰ自体のサービス環境内部に格納する。したがって、ＳＰは、ステップ５５０で、ＴＰＳＰで専用の、ある特定のリソース・インスタンス・サービスの識別のためにこのハンドルを用いて、所望のＴＰＳＰサービスを実現することが可能である。
さらに、ステップ５５５で、ＳＰは、電子ネットワークと、前記ハンドルおよびしたがって前記上述したリソース・インスタンス・サービスによって定義されるリソースを割り振る上述したウェブ・サーバ・アプリケーションとを介して、割振り要求を発行する。ＴＰＳＰは、ステップ５６０で、上述したリソースを割り振る前記割振り命令を受信すると、会計および課金のための契約データを処理するために、その命令をそれぞれの契約データベースに格納する。
次に、ステップ５６５で、ＴＰＳＰは、割振りが行われるよう命令された所望の時点で、命令されたリソースが使用可能である場合、そのリソースを割り振る。
加入は、リソースを実際に割り振るよりずっと前に行うことができる。しかし、ＳＰによる割振りコールは、リソースを効率的に使用するためのＴＰＳＰサービスの利用と接近しているべきである。ステップ５７０で、ＳＰにそれぞれの割振り確認が発行され、必要とされるリソースの実際の使用を可能にする、必要とされるすべての付加情報を伴う。したがって、ＳＰ、またはそうすることが望ましい場合はエンド・クライアントから直接発行されたリモート・プロシージャ・コールを可能にするために、この確認メッセージ中にＵＲＬを追加することができる。クライアントとＳＰとの間の会計および課金手順は、本アプリケーションの直接の主題ではない。ただし、クライアントはＳＰのみを介して請求を受け、ＳＰはＴＰＳＰによって請求される解決法が好ましい。
次いで、ステップ５７２に従ってデータを受信し処理した後、ステップ５７５で、ＳＰは、割り振られたリソースに関連づけられたアクセス・インターフェースを介して、要求したＴＰＳＰサービスを利用する。説明のためにのみ挙げる例では、アクセス・インターフェースは、必要とされるリソースを実際に発見し、識別し、使用するのに十分な情報を含む。たとえば、ＴＣＰＩＰアドレス、メール・バックアップ・サーバ用ハードウェアＩＤ、およびバックアップを実施するためのコマンドが、前記アクセス・インターフェースにおいて定義されるべきである。
ステップ５８０で、ＴＰＳＰは、ＳＰによる加入使用量に関するデータを集める。使用量データに基づいて、ＴＰＳＰは、ＳＰに対して課金を行う。
要求されたリソースは、ＳＰとＴＰＳＰとの間の契約において合意された、加入時に定められたタイム・スパンの間に使用することができる。
最後に、ＳＰが、割り振られたリソースの使用を中止すると決定すると、ＳＰは、前記使用済みリソースに対するそれぞれの「加入取消し」命令を発行する（ステップ５８５を参照されたい）。この加入取消し命令は、ＴＰＳＰによって受信され、ＴＰＳＰは、ステップ５９０で、その加入取消し命令に対応する使用済みリソースの割振りを解除する。次いで最後に、ＴＰＳＰは、ステップ５９５で、リソースが割振り解除されたことをＳＰに確認し、この確認は、ステップ５９７で、ＳＰによって受信される。
最後に、オンデマンドＴＰＳＰサービス処理全体を完了し終了するために、ＴＰＳＰで、それぞれの課金および会計手順をトリガすることができる。
次に、図７を参照すると、図３〜６に従って自動的に含められた、提供される全サービスから「最良」のサービスを識別するためにサービス・プロバイダ側で実施される、本発明の方法の第１の好ましい実施形態における制御フローを示す概略ブロック図表示を示してある。この図は、図３〜６を参照して上述した構成要素に対するアドオン関数構成要素とみなすことができるので、図７の制御フローにおいて補充を行うべき位置を、図４において太い矢印で示してある。図４において、汎用リソース・マネージャ（ＧＲＭ）は、同様に示されるgetServicePropertiesと呼ばれる新しい関数４８０によって拡張される。
ＴＰＳＰサービスが、たとえば複数のＴＰＳＰによって複数回提供されるものと仮定する。こうしたＴＰＳＰサービスは、ステップ５５０を含む図５の制御フローで説明したように処理される。ここでの問題は、そのうちのどれが最良のＴＰＳＰサービスであるかをどのようにして決定するかである。前記ＴＰＳＰサービスのいずれかに確定的に加入する前に、本発明の実施形態によると、メタサービス・セレクタ（ＭＳＳ）によって最良のサービスが識別される。ＭＳＳは、後で「メタリソース・マネージャ」とも呼ばれ、その詳細を、図７を参照して以下に示す。
アプリケーション・プログラミング・インターフェース（ＡＰＩ）コール「GetBestService」が実施され、メタリソース・マネージャ（ＭＲＭ）によって実現される。このコールは、ステップ７１０で、以下の規則に従う、パラメータとしてのファイルを伴って、「GetBestServiceを呼び出す」。
ファイルは、タグ・ベースの言語、たとえばＸＭＬで書かれる。
このファイルは、ＭＲＭによって最良のサービスを決定するのに強く必要とされる情報を列挙する。ファイルは、たとえば、ＸＭＬで符号化することができる。この情報は、ＭＲＭがＴＰＳＰサービスのリソース・マネージャの呼出しを要求しなければならないＴＰＳＰサービスの属性と、どのＴＰＳＰサービスがＳＰの必要とするものに最も適合するかを決定するために、属性を入力として使用するアルゴリズムとを含む。属性は、有利には、ＴＰＳＰサービスによって返答されることが必須の属性と、任意選択によって返答されるべき属性とに分けられる。必須属性は、たとえば、サービス識別キー（ＩＤ）、サービス確保の利用可能性、および価格を求める。純粋に任意選択的には、返すことができる詳細は、たとえばＴＰＳＰサービスの信頼性特性を含む。
ＭＲＭがこの「GetBestService」コールとともに受信する入力ファイルは、前記属性それぞれに対して重みを列挙し、この重みは、ＳＰによって調整することが可能である。重みを有する全プロパティは、ＭＲＭによる最良のＴＰＳＰサービスの判定の間、検討される。さらに、ＸＭＬファイルのタイプおよび形式は、評価アルゴリズムに依存し、実装において定義される。
ＭＲＭは、ＸＭＬファイルが準拠しなければならないＸＭＬ体系を定義し所有する。このＸＭＬ体系は、最良のサービスの判定中に処理される属性の一覧に対して、最大限の柔軟性をもたらす。
さらに明らかに完全にするために、次に、上述したGetBestServiceコールで使用可能な例示的なＸＭＬファイルを、それ以上のコメントなしで示す。当業者には、簡単に目を通すだけで理解されよう。個別に削減可能なＴＰＳＰサービスの組をＳＰに供給する重みは、その時点で含められる。タグ付けされたすべての項目は、要求されたＲＭによって値に関連付けることができる変数名に対応する。重みの値は、ステップ７２０で削除され、その後、ステップ７３０で、競合するすべてのＲＭに送信される。
<servicetype>data backupservice<\service type>
<algorithm todetermine theservice>A* for data backup service<\algorithm to determine thebestservice>
<span of time foravailability> 4months <\span of time for availability>
<duration of serviceusage>02-01-04to 12-31-04<\duration of service usage>
<mandatory returneddetails>
<serviceid><\service id>
<availabilityofservice><weight> ko criterium <\weight><\availabilityofservice> <price><weight> high<\weight > <\price>
<backup speed><weight> medium<\weight> <\backup speed>
<availability ofbackuped data><weight> medium <\weight> <\availability of backuped data>
<\mandatory returneddetails>
<optional returneddetails>
<downtime ofservice> <weight>medium <\weight> <\downtime of service>
<maximal storagecapacity><weight> medium <\weight> <\maximum storagecapacity> <service isavailable> <\serviceis available>
<\optional returneddetails>
次いで、ＭＲＭによって、必要とされるサービスに近いＴＰＳＰサービスを提供することが知られているＴＰＳＰの各ＲＭが、ステップ７４０で、情報に対する要求と、ＴＰＳＰサービス・プロパティについての所望の詳細を指定する、添付されたＸＭＬファイルとを受信し読み込む。ＴＰＳＰサービス・プロパティに関する要求の受信、読込み、返答を包含するために、ＴＰＳＰサービスのＲＭは、「getServiceProperties」ＡＰＩによって強化されなければならない。ＴＰＳＰが、提供されるオンデマンド・サービス・プロパティについての合意された形式と、このプロパティを記述する方法とを定義する共用サービス・インターフェースをサポートすると仮定すると、ＴＰＳＰのＲＭは、ステップ７５０で、受信したＸＭＬファイルにサービス・プロパティを追加することが可能となる。
同様に、補完された例示的なＸＭＬファイルを以下に示す。
<servicetype>data backupservice<\service type>
<span of time foravailability> 4months <\span of time for availability>
<duration of serviceusage>02-01-04to 12-31-04<\duration of service usage>
<mandatory returneddetails>
<service id>07227768978973468<\service id>
<availability ofservice>
02-1-04 to 05-31-04,
04-1-04 to 07-31-04,
05-1-04 to 08-31-04,
07-1-04 to 10-31-04,
08-1-04 to 11-31-04,
00-1-04 to 12-31-04
<\availability ofservice>
<price> 0. 01 $per MB<\price>
<backup speed>20 MB per sec.<\backup speed>
<availability ofbackuped data> 12weeks <\availability of backuped data><\mandatory returneddetails>
<optional returneddetails>
<downtime ofservice> 1h per day<\downtime of service>
<maximal storagecapacity> 100 TeraByte <\maximum storage capacity>
<service isavailable> since01-01-03 <service is available>
<\optional returneddetails>
次いで、ステップ７６０で、ＴＰＳＰリソース・マネージャ（ＲＭ）は、補完されたＸＭＬフォームを要求元ＳＰのＭＲＭに返送する。
ＭＲＭは、ステップ７６５で、応答するすべてのＴＰＳＰのＲＭから返答を集め、ステップ７７０で、そうした返答をデータベースに格納する。したがって、次のステップ７７５で、ＴＰＳＰは、提供されるサービスのプロパティを含む返答を読み込み、返答の内容を「理解」し、順位付けをすることが可能になる。したがって、それぞれのプログラムにおける「GetBestService」コール中の評価アルゴリズムに従って評価アルゴリズムが実行され、ＴＰＳＰによって提供される重み付けの値を含む、予め定義された１組の基準に従って、派生したすべての情報を評価する。
ここで、ＭＲＭは、ステップ７８０で、格付けリストを生成する格付けアルゴリズムをセットアップし、たとえば、「最良」サービスをサービス・リストの最上位に置く。
その結果得られる、最上位のサービスが、所定の選択基準に従う最良のサービスであり、ステップ７８５で、格付けリストから最良のサービスを選択するのに、人間の介入は必要ない。最後に、ハンドル、すなわち、プログラムによる検出が可能な、最良のサービスに対する識別が、ステップ７９０で、ＭＲＭをコールしたプログラムに返される。
次いで、制御フローは、図５において上述したステップ５６０を継続して実施される。
次に、本発明の第２の代替実施形態をより詳しく説明する。この実施形態は、ＳＰとＴＰＳＰとの間で合意されたインターフェース・データ体系が、要求されたオンデマンド・サービス自体の一部であることを提案する。
図８は、やはり本発明の第２の実施形態によって対処される問題を示す高度な概略図表示である。本発明は、最良のサービスを選択した後で、どのようにしてＴＰＳＰからのリソース３０（図８の右側部分を参照されたい）を選択し、ＳＰのサービス環境１０に統合するかを定義する。
図９は、提供される全ＴＰＳＰサービスから「最良」のサービスをＭＲＭにより識別し、ＴＰＳＰサービス内のＲＭを用いてＴＰＳＰからのリソースをＳＰのサービス環境に統合するためにＳＰ側で実装される、上述した本発明の方法の第２の好ましい実施形態のための制御フローを示す概略ブロック図表示である。ここで、最良のサービスの選択、および選択したＴＰＳＰサービスの、ＳＰ環境への関連付けを実行することは、別個のアプリケーション・プログラミング・インターフェース（ＡＰＩ）として「getServiceProperties」機能を提供する、ＭＲＭ、およびＴＰＳＰ内の改良されたＲＭを求める。冗長な情報を避けるために、図９の記述は、ステップ７１０〜７９０に関して図７の記述を参照して行われ、最後に最良のサービス用のハンドル、すなわち、プログラムにより検出可能な識別が、ＭＲＭをコールしたプログラムに返され、その後に、ＳＰから割振り命令を受信するための図５のステップ５６０〜５９５の記述が続く。
上記の説明から、この例示的なワークフローで説明したワークフローは様々な修正の対象となり得ることが明らかである。ただし、こうした修正は、ＴＰＳＰサービスをＳＰのサービス環境にカプセル化し、そこから最良のものを自動的に選択する本発明の手法の一部をなす。
本発明は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組合せとして実現することができる。本発明によるツールは、１つのコンピュータ・システムにおいて集中方式で実現することも、相互接続されたいくつかのコンピュータ・システムに渡って異なる要素が存在する分散方式で実現することもできる。どの種類のコンピュータ・システムも、本明細書において説明した方法を実施するのに適合した他の機器も適している。ハードウェアおよびソフトウェアの一般的な組合せは、ロードされ実行されると本明細書で説明した方法を実施するようなコンピュータ・システムを制御するコンピュータ・プログラムを有する汎用コンピュータ・システムでよい。
本発明は、本明細書で説明した方法の実装を可能にする特徴すべてを備え、コンピュータ・システムに搭載されるとこうした方法を実施することができるコンピュータ・プログラム製品に組み込むこともできる。
本明細書の文脈におけるコンピュータ・プログラム手段またはコンピュータ・プログラムは、情報処理能力を有するシステムに、直ちに、あるいは、
ａ）別の言語、コード、もしくは注釈への変換、
ｂ）異なる素材の形での再製品化
の一方または両方が行われた後である特定の関数を実行させることを意図した、どの言語、コード、または注釈の形でも、１組の命令からなるどの表現も意味する。
ＳＰのサービス環境の現況技術によるシステム、およびＳＰによって保持される複数のリソース・マネージャと前記システムの関係を示す概略図表示である。 ＳＰサービス環境と、ある特定のリソースへのアクセス権を有するある特定のリソース・マネージャとの間での、現況技術による相互動作の基本機能を示す、このような現況技術の概略図表示である。 本発明が、図１および図２に示すＳＰのサービス環境にＴＰＳＰからのリソースを統合することによって対処される基本的な問題を示す高度な概略図表示である。 図３に反映される本発明の概念をより詳細に示す図である。 ＳＰ側（左）およびＴＰＳＰ側（右）それぞれの部分で実装される、発明性のある方法における制御フローを示す概略ブロック図表示である。 所与の例示的なサービス・インスタンス用の基本的な識別項目を示す概略ブロック図表示である。 図３〜６に従って自動的に含められた、提供される全サービスから「最良」のサービスを識別するためにサービス・プロバイダ側で実装される、本発明の方法の第１の好ましい実施形態における制御フローを示す概略ブロック図表示である。 本発明によって対処される問題を示す高度な概略図表示である。 提供される全ＴＰＳＰサービスから「最良」のサービスをＭＳＳにより識別し、ＴＰＳＰサービス内のＲＭを用いてＴＰＳＰからのリソースをＳＰのサービス環境に統合するためにＳＰ側で実装される、本発明の方法の第２の好ましい実施形態における制御フローを示す概略ブロック図表示である。
符号の説明
１０ サービス環境
１２ リソース・ハンドル
１３ ワークフロー
１６ リソース・マネージャ（ＲＭ）
１７ リソース・マネージャ
１８ リソース・マネージャ
２０ インターフェース層
３０ ＴＰＳＰのリソース、リソース
４０ 汎用リソース・マネージャ、リソース・マネージャ
４１ インターフェース、リソース・マネージャ・インターフェース
４２ 汎用リソース・インスタンス・サービス、リソース・インスタンス・サービス ４３ 汎用リソース・インスタンス・サービス・インターフェース、リソース・インスタンス・インターフェース
４４ 通常使用インターフェース
４６ 契約
４８ ＴＰＳＰサービス
１６２ リソース・インスタンス・サービス（ＲＩＳ）
１６３ リソース
１６５ リソース
１７３ リソース
１７５ リソース
１７７ リソース
１８３ リソース
１８５ リソース
４１０ 作成関数
４２０ 削除関数
４３０ 割振り関数、割振りコール
４５０ 割振り解除関数、割振り解除コール
４６０ 加入取消し関数
４７０ 可用性検出関数

Claims (12)

  1. サービス・プロバイダ（ＳＰ）からサービスを要求するクライアントへ、電子ネットワークを介してオンデマンド・サービスを提供する方法であって、 サード・パーティ・サービス・プロバイダ（ＴＰＳＰ）が、前記クライアントが要求したサービスへの寄与として１つまたは複数のオンデマンドＴＰＳＰサービス（４８）を提供することに関与し、 前記サービスを遂行するのに必要とされるリソース（１６３、１６５、１７３、１７５、１７７、１８３、１８５）に対して複数のハンドル（１２）を含める準備が整っているサービス環境（１０）であって、汎用インターフェース（４１）定義が、ＴＰＳＰとＳＰとの間で使用され、前記要求されたＴＰＳＰサービスを前記ＳＰの前記サービス環境（１０）にカプセル化するための予め定義された構文および意味を含む、サービス環境を操作することを特徴とする方法。
  2. 前記汎用インターフェース（４１）定義が、
    ａ） 前記ＴＰＳＰに対して、前記ＴＰＳＰサービス用ハンドルを要求するステップ（５０５）と、
    ｂ） 前記ＴＰＳＰサービスを遂行するのに専用のリソース・インスタンス・サービス、へのハンドルを含む前記要求、への応答を受信するステップ（５５０）と、
    ｃ） 前記リソース・インスタンス・サービスによって定義されたリソース、を割り振るための割振り命令を発行するステップ（５５５）と、
    ｄ） 前記割り振られたリソースに関連づけられたアクセス・インターフェースを介して、前記ＴＰＳＰサービスを利用するステップ（５７５）と、
    ｅ） 前記使用済みリソースに対する割振り解除命令を発行するステップ（５８５）との実施を可能にする、請求項１に記載の方法。
  3. 電子ネットワークを介して、サード・パーティ・サービス・プロバイダ（ＴＰＳＰ）から、予め定義されたＴＰＳＰサービスを要求するサービス・プロバイダ（ＳＰ）に対してＴＰＳＰサービスを提供する方法であって、 前記ＴＰＳＰサービスを遂行するのに必要とされるリソース（１６３、１６５、１７３、１７５、１７７、１８３、１８５）に対して複数のハンドル（１２）を提供する準備が整っているサービス環境（１０）であって、汎用インターフェース（４１）定義が、前記ＳＰと前記ＴＰＳＰとの間で使用され、前記要求されたＴＰＳＰサービスを前記ＳＰの前記サービス環境（１０）にカプセル化するための予め定義された構文および意味を含む、サービス環境を操作することを特徴とする方法。
  4. 前記汎用インターフェース定義が、
    ａ） 前記ＳＰから、前記ＴＰＳＰサービス用ハンドルの要求を受信するステップ（５１０）と、
    ｂ） 前記要求されたハンドルと前記ＴＰＳＰサービス用ハンドルとに関連づけられたリソース・インスタンス・サービス（１６２、１６４、１７２、１７４、１７６、１８２、１８４）を作成するステップ（４１０、５４０）と、
    ｃ） 前記要求元ＳＰに対し前記要求されたハンドルを発行するステップ（５４５）と、
    ｄ） 前記リソース・インスタンス・サービスによって定義されたリソース、を割り振るための割振り命令を受信するステップ（５６０）と、
    ｅ） 前記リソースが使用可能な場合、前記命令されたリソースを割り振るステップ（４３０、５６５）と、
    ｆ） 前記割り振られたリソースに関連づけられたアクセス・インターフェースを介して、前記割り振られたリソースを使用するための使用コマンドを受信するステップ（５８０）と、
    ｇ） 前記使用済みリソースに対する割振り解除命令を受信するステップ（５９２）と、
    ｈ） 前記使用済みリソースの割振りを解除するステップ（４５０、５９２）との実施を可能にする、請求項３に記載の方法。
  5. 前記汎用インターフェース（４１）定義が、リソースに登録する（４４０）ステップと、登録を解除する（４６０）ステップとの実施を可能にする、請求項２または請求項４に記載の方法。
  6. リソース・インスタンスが別のサービスを含む、請求項２または請求項４に記載の方法。
  7. 前記汎用インターフェース（４１）定義が、前記ＴＰＳＰで使用可能なリソースの可用性に関するＳＰ情報を開示するステップ（４７０、５１５）の実施を可能にする、請求項２または請求項４に記載の方法。
  8. 前記ステップが、インターネットを介して利用可能となる、状態をもつウェブ・サービスとして実施される、請求項４に記載の方法。
  9. 請求項１ないし８の一項に記載の方法のステップを実施する手段を有するコンピュータ・システム。
  10. データ処理システム内で実行させるためのコンピュータ・プログラムであって、
    ａ） 前記ＳＰから、前記ＴＰＳＰサービス用ハンドルの要求を受信するステップ（５１０）と、
    ｂ） 前記要求されたハンドルと前記ＴＰＳＰサービス用ハンドルとに関連づけられたリソース・インスタンス・サービス（１６２、１６４、１７２、１７４、１７６、１８２、１８４）を作成するステップ（４１０、５４０）と、
    ｃ） 前記要求元ＳＰに、前記要求されたハンドルを発行するステップ（５４５）と、 ｄ） 前記リソース・インスタンス・サービスによって定義されたリソース、を割り振るための割振り命令を受信するステップ（５６０）と、
    ｅ） 前記リソースが使用可能な場合、前記命令されたリソースを割り振るステップ（４３０、５６５）と、
    ｆ） 前記割り振られたリソースに関連づけられたアクセス・インターフェースを介して、前記割り振られたリソースを使用するための使用コマンドを受信するステップ（５８０）と、
    ｇ） 前記使用済みリソースに対する割振り解除命令を受信するステップ（５９２）と、
    ｈ） 前記使用済みリソースの割振りを解除するステップ（４５０、５９２）とのそれぞれをコンピュータ上でコンピュータ・プログラム・コード部分が実行される時に実施させる前記コンピュータ・プログラム・コード部分、を有する機能構成要素を備えるコンピュータ・プログラム。
  11. データ処理システム内で実行させるためのコンピュータ・プログラムであって、
    ａ） 前記ＳＰから、前記ＴＰＳＰサービス用ハンドルの要求を受信するステップ（５１０）と、
    ｂ） 前記要求されたハンドルと前記ＴＰＳＰサービス用ハンドルとに関連づけられたリソース・インスタンス・サービス（１６２、１６４、１７２、１７４、１７６、１８２、１８４）を作成するステップ（４１０、５４０）と、
    ｃ） 前記要求元ＳＰに、前記要求されたハンドルを発行するステップ（５４５）と、
    ｄ） 前記リソース・インスタンス・サービスによって定義されたリソース、を割り振るための割振り命令を受信するステップ（５６０）と、
    ｅ） 前記リソースが使用可能な場合、前記命令されたリソースを割り振るステップ（４３０、５６５）と、
    ｆ） 前記ＳＰによる加入使用量についてのデータを集めるステップ（５８０）と、
    ｇ） 前記ＳＰによる加入取消しを受信するステップ（５９２）と、
    ｈ） 前記使用済みリソースの割振りを解除するステップ（４５０、５９２）とのそれぞれをコンピュータ上でコンピュータ・プログラム・コード部分が実行される時に実施させる前記コンピュータ・プログラム・コード部分、を有する機能構成要素を備える、コンピュータ・プログラム。
  12. コンピュータ上で実行されると、請求項１ないし８のいずれか一項に記載の方法をコンピュータに実施させるコンピュータ可読プログラム手段を備える、コンピュータ使用可能媒体に格納されたコンピュータ・プログラム。
JP2007190218A 2003-12-19 2007-07-20 オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合 Pending JP2007299424A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP03104820 2003-12-19

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2004364205A Division JP4069114B2 (ja) 2003-12-19 2004-12-16 オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合

Publications (1)

Publication Number Publication Date
JP2007299424A true JP2007299424A (ja) 2007-11-15

Family

ID=34673616

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2004364205A Expired - Fee Related JP4069114B2 (ja) 2003-12-19 2004-12-16 オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合
JP2007190218A Pending JP2007299424A (ja) 2003-12-19 2007-07-20 オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2004364205A Expired - Fee Related JP4069114B2 (ja) 2003-12-19 2004-12-16 オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合

Country Status (6)

Country Link
US (1) US20050138187A1 (ja)
EP (1) EP1544774A1 (ja)
JP (2) JP4069114B2 (ja)
KR (1) KR100737301B1 (ja)
CN (1) CN100563234C (ja)
TW (1) TW200532480A (ja)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7962381B2 (en) * 2004-10-15 2011-06-14 Rearden Commerce, Inc. Service designer solution
US7925540B1 (en) 2004-10-15 2011-04-12 Rearden Commerce, Inc. Method and system for an automated trip planner
US7970666B1 (en) 2004-12-30 2011-06-28 Rearden Commerce, Inc. Aggregate collection of travel data
US8180796B1 (en) 2005-03-29 2012-05-15 Rearden Commerce, Inc. Supplier integration with services business language
US7706808B1 (en) 2005-07-07 2010-04-27 Rearden Commerce, Inc. One-click service status tracking and updates
US7742954B1 (en) * 2005-07-07 2010-06-22 Rearden Commerce, Inc. Method and system for an enhanced portal for services suppliers
US7707173B2 (en) * 2005-07-15 2010-04-27 International Business Machines Corporation Selection of web services by service providers
US20070078969A1 (en) * 2005-10-04 2007-04-05 Ngo Chuong N Composite communication service management
US9117223B1 (en) 2005-12-28 2015-08-25 Deem, Inc. Method and system for resource planning for service provider
FI20060425A0 (fi) * 2006-05-02 2006-05-02 First Hop Oy Toimintavalmiuksien välittäjä ja viestijärjestelmä
US8073719B2 (en) * 2006-06-30 2011-12-06 Rearden Commerce, Inc. System and method for core identity with personas across multiple domains with permissions on profile data based on rights of domain
US7941374B2 (en) * 2006-06-30 2011-05-10 Rearden Commerce, Inc. System and method for changing a personal profile or context during a transaction
US20080004980A1 (en) * 2006-06-30 2008-01-03 Rearden Commerce, Inc. System and method for regulating supplier acceptance of service requests
US20080004919A1 (en) * 2006-06-30 2008-01-03 Rearden Commerce, Inc. Triggered transactions based on criteria
US8095402B2 (en) * 2006-07-10 2012-01-10 Rearden Commerce, Inc. System and method for transferring a service policy between domains
CN101166181A (zh) * 2006-10-16 2008-04-23 琥珀技术有限公司 一种提供第三方服务的方法以及相应系统
US7734486B2 (en) * 2006-10-16 2010-06-08 Rearden Commerce, Inc. Methods and system for preferred vendor pre-transaction bidding
JP2008152509A (ja) * 2006-12-18 2008-07-03 Fujitsu Ltd Ｗｅｂサービス制御プログラム、Ｗｅｂサービス制御装置、Ｗｅｂサービス制御方法
JP4396948B2 (ja) * 2006-12-18 2010-01-13 富士通株式会社 Ｗｅｂサービス制御プログラム、Ｗｅｂサービス制御装置、Ｗｅｂサービス制御方法
JP2008152508A (ja) * 2006-12-18 2008-07-03 Fujitsu Ltd Ｗｅｂサービス制御プログラム、Ｗｅｂサービス制御装置、Ｗｅｂサービス制御方法、中継装置
US20080201432A1 (en) * 2007-02-16 2008-08-21 Rearden Commerce, Inc. System and Method for Facilitating Transfer of Experience Data in to Generate a New Member Profile for a Online Service Portal
JP5083311B2 (ja) * 2007-03-16 2012-11-28 富士通株式会社 制御プログラム、制御装置、制御方法、中継プログラム
US8336047B2 (en) * 2008-08-25 2012-12-18 International Business Machines Corporation Provisioning virtual resources using name resolution
US10552849B2 (en) 2009-04-30 2020-02-04 Deem, Inc. System and method for offering, tracking and promoting loyalty rewards
US8756323B2 (en) * 2010-11-26 2014-06-17 International Business Machines Corporation Semantic- and preference-based planning of cloud service templates
US8560106B2 (en) * 2010-11-30 2013-10-15 Applied Materials, Inc. Predictive maintenance for third party support equipment
CN102437958A (zh) * 2011-12-16 2012-05-02 北京邮电大学 服务调度方法及系统
US9705995B2 (en) * 2014-03-18 2017-07-11 Axis Ab Capability monitoring in a service oriented architecture
US9871857B2 (en) * 2015-04-29 2018-01-16 Microsoft Technology Licensing, Llc Optimal allocation of dynamic cloud computing platform resources
JP6922670B2 (ja) * 2017-11-08 2021-08-18 日本電信電話株式会社 リソース決定装置、リソース決定方法およびリソース決定処理プログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1049471A (ja) * 1996-08-06 1998-02-20 Fujitsu Ltd サーバ連携制御方法
JPH10232899A (ja) * 1996-12-17 1998-09-02 Fuji Xerox Co Ltd サービス連携方法とサービス連携装置およびそれらの実施に利用できるパーツ生成管理方法
JPH1115849A (ja) * 1997-06-26 1999-01-22 Fujitsu Ltd サーバ連携制御方法
JP2002358290A (ja) * 2001-03-19 2002-12-13 Toshiba Corp 情報処理サービス提供方法及びプログラム並びにシステム
JP2003122912A (ja) * 2001-10-17 2003-04-25 Hitachi Ltd 業務支援システム
JP2003150572A (ja) * 2001-11-19 2003-05-23 Mitsubishi Electric Corp 連携サービス保証システム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6566008B2 (en) * 1997-01-30 2003-05-20 Sanyo Electric Co., Ltd. Sealed alkaline storage battery
US6519571B1 (en) * 1999-05-27 2003-02-11 Accenture Llp Dynamic customer profile management
US6516350B1 (en) * 1999-06-17 2003-02-04 International Business Machines Corporation Self-regulated resource management of distributed computer resources
US6289382B1 (en) * 1999-08-31 2001-09-11 Andersen Consulting, Llp System, method and article of manufacture for a globally addressable interface in a communication services patterns environment
US6606744B1 (en) * 1999-11-22 2003-08-12 Accenture, Llp Providing collaborative installation management in a network-based supply chain environment
US20020040352A1 (en) * 2000-06-29 2002-04-04 Mccormick Eamonn J. Method and system for producing an electronic business network
EP1675070A3 (de) * 2000-07-14 2006-07-19 Voice.Trust Ag Verfahren und System zur Autorisierung einer kommerziellen Transaktion
US6681106B2 (en) * 2000-09-07 2004-01-20 Traq Wireless, Inc. System and method for analyzing wireless communication records and for determining optimal wireless communication service plans
US20020120554A1 (en) * 2001-02-28 2002-08-29 Vega Lilly Mae Auction, imagery and retaining engine systems for services and service providers
US20030217125A1 (en) * 2002-05-15 2003-11-20 Lucent Technologies, Inc. Intelligent end user gateway device

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1049471A (ja) * 1996-08-06 1998-02-20 Fujitsu Ltd サーバ連携制御方法
JPH10232899A (ja) * 1996-12-17 1998-09-02 Fuji Xerox Co Ltd サービス連携方法とサービス連携装置およびそれらの実施に利用できるパーツ生成管理方法
JPH1115849A (ja) * 1997-06-26 1999-01-22 Fujitsu Ltd サーバ連携制御方法
JP2002358290A (ja) * 2001-03-19 2002-12-13 Toshiba Corp 情報処理サービス提供方法及びプログラム並びにシステム
JP2003122912A (ja) * 2001-10-17 2003-04-25 Hitachi Ltd 業務支援システム
JP2003150572A (ja) * 2001-11-19 2003-05-23 Mitsubishi Electric Corp 連携サービス保証システム

Also Published As

Publication number Publication date
JP2005190478A (ja) 2005-07-14
JP4069114B2 (ja) 2008-04-02
KR20050062380A (ko) 2005-06-23
CN100563234C (zh) 2009-11-25
KR100737301B1 (ko) 2007-07-09
TW200532480A (en) 2005-10-01
EP1544774A1 (en) 2005-06-22
CN1630288A (zh) 2005-06-22
US20050138187A1 (en) 2005-06-23

Similar Documents

Publication Publication Date Title
JP4069114B2 (ja) オンデマンド基盤におけるサード・パーティのオンデマンド・サービスの動的遅延結合
US11157915B2 (en) Automatic creation and configuration of license models and policies
US20090182645A1 (en) Provisioning Web Services
KR101066659B1 (ko) 프로세스 흐름 및 코레오그래피 제어기를 웹 서비스로서 제시
US8762933B2 (en) Converting business process models to component models in a service oriented architecture domain
US20160358237A1 (en) Creating, Managing, and Provisioning Packages of Online Applications
CA2508336A1 (en) Networked computing using objects by permitting interactivity between at least two objects over a network
US7590709B2 (en) Search method and search broker
US20080255918A1 (en) Ontological representation of knowledge
US7231416B1 (en) System and method for the co-ordination and control of information supply using a distributed multi-agent platform
Meng et al. DynaFlow: a dynamic inter-organisational workflow management system
JP2007507028A (ja) ウェブ・サービス契約選択システム
Piccinelli Service provision and composition in virtual business communities
Paurobally et al. Developing agent Web service agreements
AU2012216248B2 (en) Exposing Process Flows and Choreography Controllers as Web Services
CN117729262A (zh) 一种网关服务编排方法、装置、设备及存储介质
Xu et al. Membership Portal and Service Provisioning System for an Infrastructure of Hubs: Managed e-Hub
Meyer et al. Reference Architecture: Requirements, Current Efforts and Design
Osman Web Services Hybrid Dynamic Composition Models for Enterprises
Ziegler et al. WS-Agreement Specification Version 1.0 Experience Document
KR20010113247A (ko) 웹사이트의 자동 회원등록 방법 및 웹사이트에서 제공하는데이터저장공간 연결 방법

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101005

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110308