ウェブ・サービス契約選択システム
【課題】
ネットワークを介して提供されるべきウェブ・サービスのようなサービスに対するサービス要求者およびサービス提供者の間の契約を定義する契約データを処理するための方法およびシステムを提供する。
【解決手段】
サービス消費者（ＳＣ）を結合する多数の有効な契約が存在するときのウェブ・サービスの処理を改善するために、前記サービスに対するリクエストに前記契約データを含めて、サービス提供者が前記多数の有効な契約から特定の契約を評価（ステップ１３３０）および選択（ステップ１３４０）することを可能にし、消費者の要求事項に最もよく適合するようにすることが提案される。
ネットワークを介して提供されるべきウェブ・サービスのようなサービスに対するサービス要求者およびサービス提供者の間の契約を定義する契約データを処理するための方法およびシステムを提供する。
【解決手段】
サービス消費者（ＳＣ）を結合する多数の有効な契約が存在するときのウェブ・サービスの処理を改善するために、前記サービスに対するリクエストに前記契約データを含めて、サービス提供者が前記多数の有効な契約から特定の契約を評価（ステップ１３３０）および選択（ステップ１３４０）することを可能にし、消費者の要求事項に最もよく適合するようにすることが提案される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク・コンピュータ通信の分野に関し、特に、ネットワークを介して提供されるべきウェブ・サービスのようなサービスに関してサービス要求者およびサービス提供者の間の契約を定義する契約デーを処理するための方法およびシステムに関するものである。
【背景技術】
【０００２】
ウェブ・サービスは、アクセスされるべきソフトウェア・コンポーネントを記述するための技法、これらのコンポーネントをアクセスするための方法、および関連のサービス提供者の識別を可能にする発見方法を定義する。ウェブ・サービスは、プログラミング言語、プログラミング・モデル・ニュートラル、およびシステム・ソフトウェア・ニュートラルである。この点について、２つの従来技術のウェブ・サービス標準が関連している。それらは、従来技術における関連の問題に取り込まれるために下記のように簡単に概説および論評されている。
【０００３】
先ず、シンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol - ＳＯＡＰ）が、サービス提供者とサービス要求者との間でメッセージを交換する手段を提供する。ＳＯＡＰは、基本となる搬送プロトコルとは無関係であり、ＳＯＡＰペイロードをＨＴＴＰ、ＦＴＰ、ＪＭＳ、および他のプロトコル上で搬送することは可能である。
【０００４】
図１は、ＨＴＴＰ ＰＯＳＴリクエストによって搬送されるＳＯＡＰの例を示す。ＨＴＴＰメッセージは、クライアントからサーバへのリクエストおよびサーバからクライアントへの応答を含む。両方のタイプのメッセージ（リクエスト・メッセージおよび応答メッセージ）は、開始行、ゼロまたはそれ以上のヘッダ・フィールド（「ヘッダ」としても知られている）、ヘッダ・フィールドの終わりを表すエンプティ行、およびメッセージ本体から成る。
【０００５】
ＨＴＴＰリクエスト・メッセージの構造が図２に示される。そのメッセージの第１行は、リソースに適用されるべき方法、リソースの識別標識、および使用中のＨＴＴＰプロトコル・バージョンを指定する。ＨＴＴＰプロトコルは、ＧＥＴ、ＨＥＡＤ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＰＲＡＣＥ、ＣＯＮＮＥＣＴ、ＯＰＴＩＯＮＳのような多数の要求方法を定義する。その方法は、リソースに関して遂行されるべきオペレーションを表す。リクエストを供給されるリソースは、一様リソース識別標識（Uniform Resource Identifier）であるリクエストＵＲＩによって識別される。画一的なリソース識別標識は、リソースを（名前、ロケーション、アドレス、または他の任意の特性を介して）識別する簡単にフォーマットされたストリングである。例えば、ＨＴＴＰを介してネットワーク・リソースを位置指定するために使用される周知のＨＴＴＰ ＵＲＬスキームはリソースＵＲＩを含む。ｈｔｔｐＵＲＬに対するスキーム特有のシンタックスおよびセマンティクスは下記のようである。
http_URL= “http:” “//”host [“:”port][request-uri]
ポートがエンプティであるかまたは与えられない場合、ポート８０が仮定される。セマンティクスは、識別されたリソースが、そのホストのそのポートにおけるＴＣＰ接続に関して聴取するサーバに設けられ、リクエストＵＲＩがリソースを識別するということである。リクエストＵＲＩに対するシンタックスおよびセマンティクスは下記のようである。
Request-uri= abs_path [“?”query-string]
なお、abs_pathはリソースの識別標識であり、照会ストリング（query string）は、リクエストを処理するために使用することができる任意の種類の情報である。
【０００６】
ヘッダ・フィールドは、リクエストまたは応答に関連したメタ情報を搬送する。
【０００７】
ＨＰＰＴメッセージのメッセージ本体は、リクエストおよび応答に関連したエンティティ本体を搬送するために使用される。
【０００８】
図２に示されたメッセージ本体は、図３に示されるような構造を有する実際のＳＯＡＰメッセージを含む。エンベロープ・セクション内では、いわゆるＳＯＡＰヘッダを構成する多数のヘッダ・フィールド１、...ｎが定義され、そのＳＯＡＰヘッダに続いて、第２の多数のいわゆる本体フィールド１、...ｎを含む実際のＳＯＡＰ本体が後続する。
【０００９】
ネットワークを介して、例えば、ＨＴＴＰのような搬送プロトコルによって搬送されたＳＯＡＰメッセージの全体構造が、図１乃至図３の集合体として図４に示される。
【００１０】
図１は、ＨＴＴＰ ＰＯＳＴコマンドによって搬送されるＳＯＡＰの例を示す。ＨＴＴＰリクエスト方法はＰＯＳＴであり、リソースＵＲＩは、リクエストが意図しているリソースを識別する絶対的パスである“/StockQuote”である。リソースＵＲＩは、キュー・ストリングを含まない。
【００１１】
ＳＯＡＰの他に、従来技術には上記第２の関連のウェブ・サービス標準がある。ウェブ・サービス記述言語（ＷＳＤＬ）は、ドキュメント指向ペイロードまたはリモート・プロシージャ・コール（ＲＰＣ）ペイロードを含むメッセージに関するエンドポイント・オペレーションのセットとしてウェブ・サービスを記述するためのＸＭＬドキュメントである。いわゆるサービス・インターフェースは、メッセージ構造および簡単なメッセージ交換のシーケンス（または、ＷＳＤＬ用語における「オペレーション」）によって抽象的に定義される。しかも、それらは、エンドポイントを定義するために具体的なネットワーク・プロトコルおよびデータ終了フォーマットにバインドされる。関連する具体的なエンドポイントが、抽象的なエンドポイント（サービス）を定義するために束ねられる。
【００１２】
ＷＳＤＬは、サービス呼び出しのために使用されるプロトコル・バインディングとは異なるサービス・インターフェース定義をサポートする。ＷＳＤＬは、単一のサービスに対して複数のバインディングを可能にする。サービス・インターフェース定義およびアクセス・バインディングは、サービスの機能性を具現化したものとも異なる。サービス要求者は、通常、対応するＷＳＤＬからウェブ・サービスに対するクライアント・スタブ・コードを生成する。サービスのＷＳＤＬは、通常、サービス提供者から要求される。クライアント・スタブ・コードは、エンドポイントをアドレスするための正しいメッセージ構造および正しいデータ・エンコーディングを作成するために必要なロジックを実装する。サービスの定義、バインディング、および実装の間に差異が存在するので、或る定義およびバインディングのために作成されたクライアント・スタブ・コードは、通常、コード変更を必要とすることなく、単に別のエンドポイント・アドレスを使用することによって、種々のエンドポイントをアドレスすることができる。図５およびそれの続きである図６は、更に詳細な例示的ＷＳＤＬドキュメントを当業者に開示するために示される。
【００１３】
ウェブ・サービスの重要な特徴は、それらが要求・応答方式に従ってステートレスであることである。ステートレス・サーバは、以前のいずれのリクエストにも無関係の独立したトランザクションとして各リクエストを扱うサーバである。これは、進行中の対話に対処するために記憶装置を割り当てる必要がないため、あるいはトランザクション途中でクライアントが消滅した場合にそれを解放することに煩わされる必要がないため、サーバの設計を簡単にする。欠点は、各リクエストに多くの情報を含む必要があること、およびこの余分な情報がいつもサーバによって解釈される必要があることである。
【００１４】
上記の種類の電子通信が行われる場合の制約条件を説明したが、従来技術の欠点を次に説明することにする。
【００１５】
ウェブ・サービスの商業的使用は、サービス提供者とサービス要求者との間に締結された契約に基づく。そのような契約は、ウェブ・サービスまたはウェブ・アプリケーションを使用および規定するための条件に関する同意を表す。契約の詳細は、そのサービスの請求書を作成するための条件、即ち、価格、更に詳細な方法でサービスの所望の質を指定するサービス・レベル、並びにサービス要求者およびサービス提供者の両方にとって非常にクリティカルである更なる情報を指定することが可能である。基本的には、従来のビジネスには、契約の範囲または契約の数に関する制限はない。１つの契約が複数のサービスを含んでもよく、１つのサービスが、すべて同時に有効な複数の契約に含まれてもよい。
【００１６】
典型的な従来のシナリオでは、２つの当事者、即ち、本願ではサービス要求者またはＳＣと呼ばれるサービス消費者が通信を行うか、または、３つの当事者が、即ち、サービス要求者、上記の契約を管理するサービス提供者およびＳＳと呼ばれるサービス供給者が、ウェブ・サービス通信を構成する。なお、サービス供給者は、時には要求者に見えないままでサービスを実際に遂行する。
【００１７】
上記のウェブ・サービス機構に関して詳述した、そのような従来技術に関する唯一の開示文献は、２００２年にwww.alphaworks.com. の下に６０日の試行期間中に入手し得た「IBMWeb Services Toolkit」および「Emerging Technologies Toolkit」として発行されている。
【００１８】
「契約サービス（Contract Service）」と呼ばれ、本発明に関するほとんどの技術的特徴を含むソフトウェア・コンポーネントに関するショート・レビューは次のようなことを示している。
【００１９】
その契約サービスは、サービス提供者とサービス要求者との間の関係を扱うものである。それは、サービス提供者とサービス・ハブとの間の契約のタイプ（デプロイメント契約、プロバイダ契約としても知られている）およびサービス要求者とサービス・ハブとの間の契約のタイプ（使用契約）に関する情報を提供する。使用契約は、サービス・ハブを介して提供された任意のサービスを任意に組み合わせたオペレーションに加入するために用いることができる。使用契約は、サービスに対するコールを課金する方法（時間、使用回数、使用量等による課金）および加入したサービス・オペレーションがクライアントにとってどのくらいの費用になるかというような情報を含む。各使用契約に対して、契約サービスは使用されるべき支払方法およびレーティング・モデル、その契約に関する有効日を定義する。契約は、両当事者（サービス・ハブおよびサービス提供者／供給者）のその契約に対するデジタル署名を任意選択的に記憶してもよい。ウェブ・サービス・ツールキットと共に出荷されるユーティリティ・サービス・デモでは、そのデモと共に供給されるユーティリティ・サービス・ポータルを介して契約サービスに、契約が加えられる。有効な契約は、サービス要求者がサービスを使用できるようになる前にサービス・ハブとそのサービス要求者との間では準備のできた状態になければならない。
【００２０】
契約サービスは、次のようなＷＳＤＬ定義のオペレーションをサポートする。
・ 契約を作成するための createContract
・ 契約モデルを読み取るための getContractModel
・ 契約の現状態を読み取るための getContractState
・ 契約の現状態を更新するための updatetContractState
・ 契約のタイプを読み取るための getContractType
・ 契約のプロパティをセットするための setContractProperty
・ 契約のプロパティを読み取るための getContractProperty
・ 所与のサービス消費者にとって有効な使用契約を検索するための getUsageContractsForValidForIdentity。
【００２１】
サービス・リクエストがサーバに到達するとき，上記の契約サービスは、サービス・リクエストの実行前に、契約がそのリクエストに関連していることをチェックする。１つの契約しか存在せず、基礎となるサービスが複数レベルのサービスの質に分化する可能性のない単一の方法で遂行され得る限り、如何なるそれ以上の問題なしにサービスを提供することが可能である。
【００２２】
しかし、ウェブ・サービスの絶えず増加する申し出および使用のために、それらのウェブ・サービスは多種の品質レベルに分かれている。それぞれのサービス提供者がそれらのレベルにおけるサービスを提供することが可能である。例えば、より長い「サービス提供時間」に比べてそのサービスを更に高価にするサービスを非常に速く提供することが可能である。あるいは、サービスによって与えられた情報は多少精巧であってもよく、従って、サービス要求者に多少詳細なものを、例えば、経済的な情報システムのそれぞれ変化する内容を与えることが可能である。従って、それぞれの複数の契約または契約属性はサービス提供者およびサービス要求者の間で有効であり、それらを拘束する。この状況において、即ち、複数の契約または契約属性が関連し、有効である場合、上記の契約サービスは、リクエストのために使用されるべき実際の契約を選択しなければならず、あるいは単一の契約がサービスの種々の品質レベルに対するそれぞれの契約属性を指定する場合に実際の契約属性を使用しなければならない。選択された契約または契約属性は、現在のサービス・リクエストに対する現在の条件、例えば、上述のようなオペレーションの価格を指定する。
【００２３】
ネットワークを介して送られたリクエストが如何なる種類の契約明細または契約関連の情報を含まないとき、従来技術におけるサービス要求者サイドのクライアントは、そのような複数の契約状況における特定のサービス・リクエストに関して使用すべき実際の契約を選択することができず、そのクライアントは選択のプロセスに影響を与えることができない。換言すれば、リクエストが提供され、それが実際に要求者のためのものである的確な条件が、従来技術では当事者でないものによって、即ち、サービス提供者によって選択される。この欠点は、特に、ＵＤＤＩ、ＷＳＩＬ、ＷＳＤＬ、ＳＯＡＰのような既存のウェブ・サービス・プロトコル標準が、オペレーションまたはサービス・リクエストに対する契約を選択するための如何なる方法も考慮していないという事実に基づいている。
【００２４】
この問題の不満足な処理を行うことは、サービス提供者が実際の契約または実際の契約属性を選択するが、要求者がその契約に影響力を持たないことを意味し、あるいは、同じサービスに対する各粒状的な品質レベルに関しては別の契約が定義され、従って、１つの同じサービスが論理的および形式的にそれぞれのサービスに分裂することを意味する。しかし、これは、サービス消費者に対するマン・マシン・インターフェースを複雑にし、使用を難しくする。
【非特許文献１】「IBM Web Services Toolkit」under www.alphaworks.com.
【非特許文献２】「Emerging TechnologiesToolkit」under www.alphaworks.com.
【発明の開示】
【発明が解決しようとする課題】
【００２５】
従って、本発明の目的は、「特許請求の範囲」の請求項１の前文に記載の方法に対する改良を施すことにより、上記の欠点を回避または少なくとも減じさせることにある。
【課題を解決するための手段】
【００２６】
本発明のこの目的は、「特許請求の範囲」の従属項に記載された特徴によって達成される。本発明の更なる利点および実施例はそれぞれの従属項に示される。「特許請求の範囲」の記載を参照してほしい。
【００２７】
本発明の基本的な局面によれば、「特許請求の範囲」の請求項１の前文において定義された方法は、サービスを要求するリクエストの中に所与のサービス明細の選択を契約データが指定することをそのリクエスト内に含むステップによって更に改善される。
【００２８】
本発明のこの一般的な特徴によって、サービス提供者サイドに存在する契約サービス・ソフトウェア・コンポーネントは、それがそのリクエストからそのような契約データを抽出し、所定のルールに従ってそれを評価して、サービス提供者が上記の契約データの助けによって要求したサービスの質を、サービス提供者が正確に規定することを可能にする。
【００２９】
本発明の望ましい特徴によれば、上記契約データは、クライアント・サイドおよびサーバ・サイドの両方に存在し且つ上記契約データを含むそれぞれのソフトウェア・インターフェースを介して処理される。上記インターフェースは、使用中の搬送プロトコルの定義、使用中のメッセージング・プロトコルの定義、および使用中の関連ポートに関する定義のそれぞれを含む。勿論、そのようなソフトウェア・インターフェースは、そのようなサービスが更なる開発のためにやがて変更されることがあり得るので、サービスのタイプおよびバージョンのそれぞれに従ってプログラムされ、管理されなければならない。
【００３０】
更に、本発明の更なる望ましい局面によれば、上記契約データは、ウェブ・サービス・リクエスト・メッセージのヘッダ・フィールド内で処理されることがあり得る。
【００３１】
この場合、リクエスト評価ソフトウェア・コンポーネントは、勿論、そのようなヘッダ・フィールド内容を抽出しなければならず、従って、それぞれのプログラミングを必要とする。
【００３２】
本発明のほとんどの好適な局面によれば、上記契約データは、それぞれのサービス・リクエストのエンドポイント明細から成り、それの一部として処理される。この特徴は、クライアントおよびサービス要求者がサービス・リクエストに対する１つまたは複数の契約を選択することを可能にする方法を定義し、一方、既存のウェブ・サービス・プロトコルおよびインフラストラクチャは変更なしに使用することが可能である。
【００３３】
サービス・リクエストを構成し且つクライアントによってサーバに送られたメッセージ自体は、１つまたは複数の契約を選択するためにサーバによって使用されるそのような情報を含む。
【００３４】
更に、契約選択パラメータは、基本的には契約の内容または特定の契約を識別するメタデータを参照することも可能である。内容は、サービスの質が直接に処理されるとき、例えば、サービス・パフォーマンス条件またはサービス内容条件が以下のように例示的に定義されるときに参照される。
（ａ）サービスの価格＜一定の上限価格、例えば１０ＵＳＤ、または
（ｂ）０.５秒よりも小さいかまたは等しい応答時間、または
（ｃ）９０％よりも大きいサービスの可用性、または
（ｄ）提供されたサービスの複雑性を、例えば、一方では短い要約のような情報として、または、他方では詳細な報告書として、処理する別の基準。
【００３５】
上記の意味での契約メタデータに関する例は、例えば、複数の(例えば３０個の)識別文字から成る独特のＩＤに従って契約が指定されるときである。
【００３６】
更に、本発明の望ましい局面によれば、上記の契約選択基準の組み合わせがサービス消費者(要求者)によって指定され得るし、サービス提供者によって提示され得ることは留意すべきである。１つの例は、上記の（ａ）ＡＮＤ（ｂ）ＯＲ（ａ）ＡＮＤ（ｃ）という要件と結合されたリクエスト指定契約ＩＤ「hhffkk-rrsslloo-ooddggjj-idghwelf-oodbmmss」である。
【００３７】
「特許請求の範囲」の記載から明らかなように、本発明は、ソフトウェア／ハードウェア・システムを要求者および提供者の間に分散したものと見なすことができる。特に、提供者サイドは、サービス提供者（サービス・ハブとも呼ばれる）およびサービス供給者と共に前述したように、２つ以上の別の機関に分裂することも可能である。上記分散性質のために、サーバ部分およびクライアント部分のそれぞれに対して「特許請求の範囲」の特定の請求項が存在する。これは、提供者サイトまたは要求者サイトにおける複数の単一ハードウェア・システム上に本発明の機能を分散する可能性も含む。例えば、本発明の方法の要求者サイトまたは提供者サイトそれぞれのステップは、インターセプタ・コンピュータにおいて部分的または全体的に具現化することが可能である。なお、インターセプタ・コンピュータは、実際の各データベース・アプリケーションを含む専用のサーバ・システムに着信メッセージが実際に送られる前に、その着信メッセージをインターセプトおよび処理するための企業のファイアウォール概念で統合されたゲートウェイ・コンポーネントとして配列される。
【００３８】
本発明の第１の利点は、クライアントが契約の選択を可能にされ、従って、所望のサービスに対する条件の選択を可能にされることである。契約選択を指定するパラメータはサービス・リクエストを構成するリクエスト・メッセージの一部であるので、本発明は、ステートレス・ウェブ・サービスに十分に適している。
【００３９】
本発明は、既存の標準的なウェブ・サービス・プロトコルを使用し、それをてこ入れする。最も望ましい特徴によれば、それは既存のウェブ・サービス・インフラストラクチャの拡張を必要とせず、そのウェブ・サービス・インフラストラクチャおよびサービスの実施の両方にとって透明である。従って、それは、例えば、.NET および JAVA ウェブ・サービスのような異種の環境に十分適している。従って、種々の契約フィーチャおよびその代替に基づいた広範な種々のサービスが、その場合にサービス・インターフェースを変更することなく、ネットワークを介して行われる。その場合、契約データは、上記の最も好適な代替方法であるサービス・リクエストのエンドポイント明細の一部として処理される。この場合、サービス・インターフェース（ハードウェアでもソフトウェアでもない）は変更される必要がなく、ネットワークを介して送られたすべてのメッセージが従来技術におけるクライアント・プロキシを形成するための標準およびツールに依然として準拠し、クライアント・アプリケーション・プログラミング・インターフェース（ＡＰＩ）が依然として使用可能である。
【００４０】
メッセージの「エンドポイント」という用語は、メッセージを送るまたは受け取るリソース（任意の種類のハードウェアまたはソフトウェア・リソース）を表す。リクエストの「エンドポイント」という用語は、リクエストを送るまたはリクエストを受け取って処理することを意図されたリソースを表す。「エンドポイント明細」という用語は、そのようなリソースの識別標識を表す。任意の種類のエンドポイント明細の表示が可能である。一般には、エンドポイント明細は、ＨＴＴＰ−ＵＲＬまたはリクエスト−ＵＲＩとして示される。図１は、リクエスト−ＵＲＩ“/StockQuote”として示されたエンドポイント明細を含む。
【００４１】
ウェブ・サービスに関して、エンドポイントは、特定のフォーマットのメッセージを受け取るか、またはリクエストおよび応答メッセージの特定のフォーマットにより特徴付けられた特定のオペレーション、特定のデータ・エンコーディング、および特定のネットワーク・プロトコルを実現するリソースである。一般に、エンドポイントは、プロトコル・レベルのエンドポイント・アドレス、例えば、ＨＴＴＰ−ＵＲＬまたはリクエスト−ＵＲＩによって指定される。
【００４２】
「ステートレス」リクエストは、リクエストが別のトランザクションとして処理され、如何なる他の（以前または将来の）リクエストにも関係ないことを意味する。一般に、リクエストはサーバによって処理され、応答は直ちに戻され、しかる後このリクエストに関連したサーバに関するすべての情報が削除される。換言すれば、サーバは、リクエストが処理された後はそのリクエストの状態を保存しない。
【発明を実施するための最良の形態】
【００４３】
次に、本発明の方法およびシステムの好適な実施態様を説明する。ここでは、本発明の契約システムのランタイム動作、即ち、サービス・リクエストが処理されるときの動作に焦点が置かれる。
【００４４】
基本的には、契約システムは、次のようなものでなければならない。
（１）実際の着信サービス・リクエストが少なくとも１つの有効な契約に適合することを検証する。
（２）その契約によって指定された、このサービス・リクエストに対する使用条件を検索する。
【００４５】
本発明による契約システムは任意の契約タイプをサポートすることが可能である。各契約は１つの契約タイプのインスタンスである。種々の契約タイプが同じデータ・モデルに基づいている。即ち、すべての契約が状態（有効、無効、または削除済み）、契約タイプおよび契約ドキュメントを示す参照付を含む。これは、個々の契約データ、即ち、契約項目、即ち、サービス・オペレーションと、それを使用するための契約条件（terms and conditions）を含むＸＭＬ構造であってもよい。契約ドキュメントの書式は契約タイプに依存する。
【００４６】
説明の便宜上、１つの契約タイプだけを更に詳しく説明する。タイプ「用途」という契約、即ち、使用契約は、１つのサービス消費者と１つのサービス提供者との間の同意を表す。
【００４７】
各使用契約は、サービス消費者の特有のアイデンティティと関連している。典型的なシナリオでは、契約システムはサービス提供者のサイドに立っており、従って、サービス提供者のアイデンティティは使用契約に明示的には含まれていないが、暗示的に示される。
【００４８】
サービス提供者は、サービス消費者が有効な使用契約によってカバーされたサービス・オペレーションを単に呼び出すことができることを保証するために契約システムを使用する。消費者が１つのサービス・オペレーションに対して複数の有効な契約を持つことができるといことは留意すべきである。
【００４９】
使用契約は、契約名、消費者即ちサービス要求者のアイデンティティ・キー、開始日、および終了日を含む。それは、サービス・オペレーションのキーおよび関連するレーティングのキーを指定する１つまたは複数のサービス・エレメントを含む。この例では、サロゲート・キーが使用されるが、実際の実施方法次第で、他のタイプのキーも使用可能である。レーティング・モデルは、サービス・オペレーションに対するコールがどのように（時間、使用の数等によって）課金されるべきか、および参加したサービス・オペレーションがその消費者に対してどのくらいの費用をかけるべきか、を指定する。これは、下記の表１から生じる。
【表１】
【００５０】
このサンプルの契約タイプのほかに、この基本的アーキテクチャは他の契約タイプを容易に加えることを可能にする。他のタイプの契約はサービス属性の質、即ち、応答時間、可用性等を指定することも可能である。
【００５１】
以下には、２つの典型的なランタイム・シナリオが示され、サービス消費者、サービス提供者、およびサービス供給者の間の相互作用が示される。上記のシナリオが始まる前では、懸案の契約は多くの方法を通して、例えば、「伝統的な」成文の書面を通して締結され得るので、その契約を作成する方法は本発明の範囲に入らないが、サービスが要求される前には１つまたは複数の有効な契約が準備のできた状態にあるものと考えられることに留意すべきである。
【００５２】
図７を参照すると、ＳＳと略記されるサービス供給者がＳＣと略記されるサービス消費者にサービスを提供するというシナリオが開示される。ＳＰと略記されるサービス提供者は、本発明の主要なソフトウェア・コンポーネントを含む契約管理インフラストラクチャを実現している。
【００５３】
この結果、次のような相互作用が生じる。その相互作用は、この実施例によれば、それぞれのプログラム・モジュールにおいて当事者Ａ、Ｂ、およびＣにより使用される本発明の各方法の「ステップ」として実施される。図面に示されるように、下記のステップが遂行される。
【００５４】
ステップ６１０：ＳＳによって提供されるビジネス・サービスを呼び出すために、ＳＣがサービス・リクエストを開始する。
【００５５】
ステップ６２０：ＳＰによって提供される契約システムおよびインフラストラクチャ・サービスを使用するために、ＳＳがＳＰにサービス・リクエストを送る。特に、この実施例では、契約システム・サービスは契約サービスを含み、インフラストラクチャは計量サービスおよびプロファイリング・サービスである。
【００５６】
ステップ６３０：ＳＰが、要求された契約システムおよびインフラストラクチャ・サービスを遂行する、例えば、有効な契約が得られることを確認し、計量イベントを開始し、ＳＰに状態を戻す。
【００５７】
ステップ６４０：ＳＳが、要求されたサービスを遂行し、十分な計量イベントを生成するためにＳＰを呼び出す。
【００５８】
ステップ６５０：ＳＳが、サービス結果を表すデータをＳＣに送る。
【００５９】
ステップ６２０の実施は図８に更に詳細に示される。サービス提供者は、破線の枠で示されたアプリケーション・サーバを実現する。そのアプリケーション・サーバは、サービス・リクエストのためのランタイム環境、例えば、Apache Axis のようなウェブ・サービス・ランタイム環境、を具現化するサーブレット７１を含む。
【００６０】
アプリケーション・サーバは、参照符号７２、７４、７６によって示された複数のハンドラ・コンポーネントも含む。これらのハンドラは、リモート・サーバにおいて、例えば、更なるウェブ・サービスとして実現可能であるインフラストラクチャ・コンポーネントＦ〜Ｈのローカル実施を実現する。ハンドラ７２、７４、７６は、リモート・サービスとのコミュニケーションを処理することを必要とするローカル機能を提供する。
・ プロファイル・ハンドラ７２は、要求者のアイデンティティを検証するために外部のプロファイル・サービスを使用する。
・ 契約ハンドラ７４は、契約状態および契約有効性を検証するために外部の契約サービスを使用する。
・ 計量ハンドラ７６は、十分な計量イベント（開始イベント、終了イベント、アドホック・イベント、取消しイベント等）を生成する。
【００６１】
コンポーネント７１，７２，７６（サーブレットおよびハンドラ）は、共用メモリ環境において動作し、共用データを通してコミュニケーションを行う。サーブレット７１は、ハンドラが正しい順序で呼び出されることを保証する。次に、インフラストラクチャ・サービスを説明する。
【００６２】
プロファイル・サービス（７２Ａ）は、基本的には、上記の従来技術において得られるものとして使用することが可能である。
【００６３】
プロファイル・サービスは、名前、アドレス、ユーザＩＤ等のようなユーザ・プロファイル情報に対するアクセスを提供する。実施方法次第で、これは、多くの情報を含むように拡張することが可能である。プロファイル・サービスは、プロファイル情報を保存、削除、および取得するために使用することが可能である。他のサービスが正しく働くためには、ビジネス・サービスのすべてのユーザがプロファイル・サービスによってプロファイルを割り当てられなければならない。プロファイルは、ユーザ・インターフェースを使用することによって、またはプロファイルを保持するＸＭＬファイルを直接に編集することによって、事前に作成することが可能である。このプロファイル・サービスは、Tivoli Identity Manager のような任意の他のアイデンティティ・システムによって置換されることもあり得る。
【００６４】
契約サービス７４Ａは本発明の契約コンセプトを具現化し、下記のようなＷＳＤＬ定義のオペレーションをサポートする。
・ createContract– 契約を作成する
・ getContractModel– 契約の情報および内容を検索する
・ getContractState– 契約の実際の状態を得る
・ updateContractState – 契約の状態（例えば、有効、無効）をセットする
・ getUsageContractsForValidForIdentity -所与のサービス消費者にとって有効な使用契約を検索する。
【００６５】
計量サービス７６Ａが後述のように計量イベントを受取り、それらの計量イベントを永続的に記憶し、要求時に計量イベントを検索する。この好適な実施例によれば、特定のサービスを使用して特定のクライアントに対する使用レポートを作るために、契約サービス７４からの契約情報と関連して計量サービスを使用することが可能である。契約サービスおよび計量サービスが直接に相互作用しないことは留意すべきである。
【００６６】
計量サービス７６Ａは下記の３つのタイプのオペレーションをサポートする。
・ recordMeterEvent– １つの計量イベントを保存する
・ recordMeterEvents– 複数の計量イベントを保存する
・ getMeterEvents– 計量サービスから複数の計量イベントを検索する。
【００６７】
計量イベントは、コールされたサービスのサービス名およびオペレーション名、タイムスタンプ、およびリクエストを処理するために使用される契約のＩＤを含む。計量イベントはタイプによって変わり、従ってサービス・コールを課金する種々の方法が可能である。
・ サービスに対するアクセスが、そのサービスを遂行するために使用された時間の量だけ課金されるとき、開始／終了イベントが使用される。
・ サービスがアクセスされる回数だけまたは回数以外の他のいずれかに基づいてアクセスが課金されるとき、アドホック・イベントが使用される。
【００６８】
上記のほかに、更に下記の２つのタイプのイベントが使用可能である。
（ａ）イベントを取消すために使用され、既に計量サービスに送られている「取消し済み」というイベント、および
（ｂ）イベントのタイプがサービス要求者によって供給されなかったときに使用される「未知」というイベント。
【００６９】
上記のソフトウェア・コンポーネントの間の相互作用は下記のようになる。
ステップ７１０：サーブレット７１が、サービス供給者によって開始されたサービス・リクエストを受取り、メッセージ・コンテキストを抽出し、それを次のハンドラ・コンポーネント上に送る。
ステップ７２０：共用のデータ・オブジェクトであるメッセージ・コンテキストが次に続くハンドラ・コンポーネントに送られる。ハンドラはメッセージ・コンテキストを拡張／修正し、それをそのチェーンにおける次のハンドラ上に送る。
ステップ７３０：プロファイル・ハンドラ７２が、サービス供給者のアイデンティティをチェックするために、それぞれのデータ・ベース・アプリケーションを含む外部のプロファイル・サービス７２Ａへのサービス・リクエストを開始する。
ステップ７４０：プロファイル・サービス７２がアイデンティティ・チェック結果をＳＰのプロファイル・ハンドラに戻す。
ステップ７５０：契約ハンドラが、対応する契約を識別および有効化するために外部の契約サービス７４Ａをコールする。それは、「getUsageContractsForValidForIdentity」オペレーションをコールし、プロファイル・サービス結果から得られたサービス消費者アイデンティティを送る。本発明に従って、契約サービス７４Ａがこのアイデンティティに対する１つの有効な契約を選択する。その選択はサービス消費者アイデンティティのみに基づくだけである。即ち、サービス消費者またはいずれかの他のコンポーネントがその選択に影響を与えるための手段、例えば、複数の矛盾した有効な契約の間で優先順位を指定するための手段は従来技術には、存在しないということに留意すべきである。
ステップ７６０：契約サービス７４Ａが契約状態および有効性をＳＰの契約ハンドラに戻す。有効な契約が見つからない場合、例外が生じる。
ステップ７７０：ビジネス・サービス・コールの状態を反映する計量イベントを生成するために、計量ハンドラ７６が外部の計量サービス７６Ａを呼び出す。
ステップ７８０：計量ハンドラがその更新されたメッセージ・コンテキストをサーブレットに戻す。
ステップ７９０：サーブレット７１が初期サービス・コール(リクエスト)の結果をサービス供給者に戻す。
【００７０】
別のシナリオでは、図９および図１０に関して、サービス提供者がサービス消費者にサービスを提供する。サービス・リクエストを満たすために、サービス提供者はサービス供給者からのサービスを要求する。特に、
ステップ８１０：ＳＣがＳＰからのビジネス・サービスを要求する。
ステップ８２０：ＳＰが契約システムおよびインフラストラクチャ・サービスを使用して、有効な契約が得られることを確認し、開始計量イベントを起動し、しかる後、ＳＳからのサービスを要求する。
ステップ８３０：ＳＳがサービスを遂行し、結果をＳＰに戻す。
ステップ８４０：ＳＰが終了計量イベントを生成し、ビジネス・サービス結果をＳＣに戻す。
【００７１】
図１０に関連して、本発明の実施方法を示し、説明することにする。サービス提供者は、図７および図８に関連して上述したようにアプリケーション・サーバを実現する。従って、次に主としてその相違点を説明する。
【００７２】
この特定の実施例によれば、サービス・ハンドラ９０が外部のビジネス・サービスを呼び出す。そのビジネス・サービスはサービス供給者（ＳＳ）によって提供される。
【００７３】
コンポーネント・サーブレット９１およびハンドラ７２、７４、７６（図１０の右縁参照）が再び共用メモリ環境において実行され、共用データを介してコミュニケーションを行う。サーブレット９１は、シナリオ２における特定の相違点から生じる、図８における上述したサーブレットに対するそれぞれの相違点のみを有し、ハンドラが正しい順序で呼び出されることを保証する。
【００７４】
ビジネス・ウェブ・サービス９２は、サービス供給者によって提供される外部のサーバ・コンポーネントである。それは、要求されたサービス・コールを遂行するためにステップ９１０において呼び出される。
【００７５】
これらのコンポーネント間の相互作用は次のようになる。
ステップ９１０：サーブレット９１が、サービス消費者(ＳＣ)により発せられたサービス・リクエストを受取り、メッセージ・コンテキストを抽出し、それを後続のハンドラ・コンポーネント上に送る。
ステップ７２０〜７７０：上記のシナリオ１を参照。
ステップ９８０：サービス・ハンドラ９０がその要求されたビジネス・サービス９２を呼び出し、その結果生じたサービス応答でもってメッセージ・コンテキストを更新する。
ステップ９８５：それをサービス・ハンドラ９２に戻す。
ステップ９９０：サービス・ハンドラがその更新されたメッセージ・コンテキストをサーブレット９１に戻す。
ステップ９９５：サーブレット９１が初期コールの結果をサービス消費者に戻す。
【００７６】
本発明によれば、契約選択データを組み込んだ、本発明の好適なメッセージ交換によるロジックを示す図１１を参照すると、契約情報が、サービス・リクエストのエンドポイント明細の一部としてクライアント・サイド、即ちサービス消費者、によってエンコードされる(ステップ１３００参照)。エンドポイントは、展開されたウェブ・サービスをサーバにおいて呼び出すことができるアドレスである。通常、それはＵＲＬを含む。サービス・リクエスト・メッセージはエンドポイントの明細を含む。
【００７７】
照会ストリング部分はメッセージの処理または経路指定のどちらにも影響を与えない。それは、これがサーブレット・エンジン、ＳＯＡＰサーバ、または如何なる従来技術のコンポーネントによってもサービス実施方法を見出すことに適するとは考えられないためである。従って、契約情報をそこに含むことが望ましい。
【００７８】
そこで、クライアント・ステップ１３０５において、前記契約選択データ、例えば、契約識別標識として働く整数、によって強化されたＳＯＡＰリクエストがサーバ・サイドに送られる。
【００７９】
次に、ステップ１３１０において、提供者サイトにおけるアプリケーション・サーバがそのリクエストを受取り、ステップ１３２０ではそれにより契約選択情報を受取り、ステップ１３３０において、そのリクエストの照会ストリングから契約選択情報を評価する。それによって、サーバは所望のサービスに対する所望の契約を決定することができ(ステップ１３４０)、上記の照会ストリングからデータおよびパラメータを契約が指定することによって詳述のようにサービスを呼び出すことができる。
【００８０】
更に、ステップ１３５０において、それぞれのサービスがアセンブルされ、それぞれのＳＯＡＰ応答メッセージが生成されて(ステップ１３５０) クライアントに送られる。クライアントは、ステップ１３６０においてそのメッセージを受け取る。
【００８１】
更に、以下は、ウェブを介した契約選択という本発明のコンセプトに留意すべきである。契約選択パラメータは、契約サービスのようなウェブ・サービス管理コンポーネントによって作成される契約識別標識のような契約メタデータ、または契約内容を参照することが可能である。価格、サービスの質等のような契約によってカバーされるすべての変数を、内容関連の契約選択パラメータにおいて参照することが可能である。契約の選択に関する複雑な条件を作成するために、種々の契約選択パラメータを結合することが可能である。
【００８２】
単一または複数の結合された契約選択パラメータは、サービス要求者およびサービス提供者の両方にとって理解可能な文法に適応するテキスト・ストリングとして表すことが可能である。本発明は、いずれの文法によっても使用することが可能である。例えば、契約選択パラメータは、特定のＸＭＬスキーマに基づいてＸＭＬ言語で表すことが可能である。ＸＭＬデータはストリングとしてエンコードされるので、エンドポイント・アドレス・エンコーディングの本発明の特徴は、この契約情報をサービス・リクエスト・メッセージに有利に組み込むために使用することが可能である。
【００８３】
本発明の使用に関する１つの例示的ケースでは、サービス要求者はサービス・リクエストに対する価格限界を設定することを望む。従って、サービス要求者は、価格に対する上限を表す条件を表す適当なパラメータ（「price<$10」）を選択し、このパラメータをサービス・リクエストに含める。このパラメータは契約の内容を参照することが、契約ＩＤによって契約を明確に選択するものではない。
【００８４】
本発明の特定の実施例では、このパラメータは、下記のようにＸＭＬ言語でエンコードすることが可能である。
<contract>
<price>
<max>
10
</max>
</price>
</contract>
【００８５】
都合のよいことに、契約選択パラメータは、エンドポイント・アドレスの照会ストリングの一部として下記のようにエンコードすることが可能である。
String
endpoint=address+”<contract><price><max>10</max></price></contract>”
【００８６】
サーバは、サービス要求者にとって有効であり且つ所与のパラメータに対応する条件を満たす契約を選択する。
【００８７】
この例では、図７乃至図１０に関連して上述したアプリケーション・サーバであるサーバがその有効な契約の内容を検索し、契約条件に従って仮定の価格を計算し、この価格を価格限界と比較する。それによって、サーバは多くの適格な契約を決定する。複数の契約が適格となる場合、サーバは、これまで説明した発明概念に容易に追加し得る任意の更なるロジックに従って１つを選択する。適格となる契約がない場合、サーバはエラーを表すために例外を生じる。
【００８８】
下記の擬似コードの例は、固定の契約要素および可変の契約要素に関する条件を評価することによってサーバ・ロジックを具現化する。固定の要素は、リクエストの時間または内容に依存しない。それの例は、メタデータ要素（例えば、契約ＩＤ）および固定の価格である。可変の要素は、時刻またはサービス・リクエストに依存する。例えば、サービス価格はリクエスト・メッセージにおける時間または他の入力パラメータに依存する。固定の要素に関する条件はデータベース照会において統合することが可能であるが、可変の要素に関する条件は、契約を評価することおよび変数を計算することによってチェックされる必要がある。
【００８９】
Pseudocode-begin（擬似コード始まり）:
Get contract info from request message（リクエスト・メッセージから契約情報を得る）;
Getcontract selection parameters (CSP) from contact info（契約情報から契約選択パラメータ（ＣＳＰ）を得る）;
Getfixed and variable conditions from CSP（固定および可変の条件をＣＳＰから得る）
Selectcontracts from database, which（データベースから契約を選択する）
1)are valid for the requester identity（その契約は要求者アイデンティティにとって有効である）
AND
2) satisfy the fixed conditions（その契約は固定の条件を満たす）;
Ifno contracts are available exit with error（契約が使用可能でない場合、エラーでもって終わる）；
Checkthe variable conditions for each of the available contracts by reading thecontracts content and by dynamically evaluating the variables（契約内容を読むことおよび変数を動的に評価することによって各使用可能な契約に対する可変の条件をチェックする）；
Ifmore than one contract satisfies the conditions, then perform further logic toselect one (e.g. Random selection, take first one) （複数の契約が条件を満たす場合、１つを選択するために更なるロジック（例えば、最初の１つを取るランダム選択）を遂行する）；
Ifno contract satisfies the conditions exit with error（条件を満たす契約がない場合、エラーでもって終了する）；
Pseudocode-end（擬似コード終り）
【００９０】
この擬似コードは、契約サービスでは、上述の getUsageContractsForValidForIdentity オペレーションであるいはそれとは別に１つまたは複数の異なるオペレーションで実現することが可能である。
【００９１】
本発明は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの結合によって実現することが可能である。本発明によるツールは、１つのコンピュータ・システムにおいて集中態様で、または幾つもの相互接続されたコンピュータ・システムにまたがって種々の要素が分布する分散態様で実現することが可能である。本願において開示された方法を実行するように適応した任意の種類のコンピュータ・システムまたは他の装置が適する。ハードウェアおよびソフトウェアの典型的な結合は、ロードおよび実行時に上記の方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを有した汎用コンピュータ・システムであってもよい。
【００９２】
上記の方法の実施を可能にするすべてのフィーチャを含み、コンピュータ・システムにロードされるとき、これらの方法を実行することができるコンピュータ・プログラムに本発明を組み込むことも可能である。
【００９３】
本願の関連におけるコンピュータ・プログラム手段またはコンピュータ・プログラムは、特定の機能を直接に、または
（ａ）他の言語、コード、または表記法への変換、
（ｂ）異なる具体的な形体における複製
のいずれかまたは両方の後、情報処理機能を有するシステムに特定の機能を遂行させることを意図された命令のセットの、任意の言語、コード、または表記法における任意の表現を意味する。
【図面の簡単な説明】
【００９４】
【図１】ＨＴＴＰ ＰＯＳＴリクエスト・メッセージに含まれた従来技術のＳＯＡＰリクエスト・メッセージを示すコード・セクション表示である。
【図２】従来技術のＨＴＴＰリクエストの構造を示すコード・セクション表示である。
【図３】従来技術のＳＯＡＰメッセージの詳細構造を示すコード・セクション表示である。
【図４】ＨＴＴＰ ＰＯＳＴリクエスト・メッセージに含まれた従来技術のＳＯＡＰメッセージの全体構造を示すコード・セクション表示である。
【図５】ウェブ・サービスを記述するために使用された従来技術の例示的ＷＳＤＬドキュメントのセクションを示すコード・セクション表示である。
【図６】図５のコード・セクション表示に連続する部分である。
【図７】本発明の方法の好適な実施例による、サービス消費者、サービス供給者、およびサービス提供者の間の関係を表す概略図である。
【図８】図７に示されたシナリオで使用される主要な構成要素の概略図である。
【図９】本発明の方法の更なる好適な実施例による、サービス消費者、サービス供給者、およびサービス提供者の間の関係を表す概略図である。
【図１０】図９に示されたシナリオで使用される主要な構成要素の概略図である。
【図１１】本発明によって提供される好適な方法に従って遂行される契約選択パラメータを含むメッセージ交換における制御フローおよびそれの関連ステップを示すブロック図である。
【技術分野】
【０００１】
本発明は、ネットワーク・コンピュータ通信の分野に関し、特に、ネットワークを介して提供されるべきウェブ・サービスのようなサービスに関してサービス要求者およびサービス提供者の間の契約を定義する契約デーを処理するための方法およびシステムに関するものである。
【背景技術】
【０００２】
ウェブ・サービスは、アクセスされるべきソフトウェア・コンポーネントを記述するための技法、これらのコンポーネントをアクセスするための方法、および関連のサービス提供者の識別を可能にする発見方法を定義する。ウェブ・サービスは、プログラミング言語、プログラミング・モデル・ニュートラル、およびシステム・ソフトウェア・ニュートラルである。この点について、２つの従来技術のウェブ・サービス標準が関連している。それらは、従来技術における関連の問題に取り込まれるために下記のように簡単に概説および論評されている。
【０００３】
先ず、シンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol - ＳＯＡＰ）が、サービス提供者とサービス要求者との間でメッセージを交換する手段を提供する。ＳＯＡＰは、基本となる搬送プロトコルとは無関係であり、ＳＯＡＰペイロードをＨＴＴＰ、ＦＴＰ、ＪＭＳ、および他のプロトコル上で搬送することは可能である。
【０００４】
図１は、ＨＴＴＰ ＰＯＳＴリクエストによって搬送されるＳＯＡＰの例を示す。ＨＴＴＰメッセージは、クライアントからサーバへのリクエストおよびサーバからクライアントへの応答を含む。両方のタイプのメッセージ（リクエスト・メッセージおよび応答メッセージ）は、開始行、ゼロまたはそれ以上のヘッダ・フィールド（「ヘッダ」としても知られている）、ヘッダ・フィールドの終わりを表すエンプティ行、およびメッセージ本体から成る。
【０００５】
ＨＴＴＰリクエスト・メッセージの構造が図２に示される。そのメッセージの第１行は、リソースに適用されるべき方法、リソースの識別標識、および使用中のＨＴＴＰプロトコル・バージョンを指定する。ＨＴＴＰプロトコルは、ＧＥＴ、ＨＥＡＤ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＰＲＡＣＥ、ＣＯＮＮＥＣＴ、ＯＰＴＩＯＮＳのような多数の要求方法を定義する。その方法は、リソースに関して遂行されるべきオペレーションを表す。リクエストを供給されるリソースは、一様リソース識別標識（Uniform Resource Identifier）であるリクエストＵＲＩによって識別される。画一的なリソース識別標識は、リソースを（名前、ロケーション、アドレス、または他の任意の特性を介して）識別する簡単にフォーマットされたストリングである。例えば、ＨＴＴＰを介してネットワーク・リソースを位置指定するために使用される周知のＨＴＴＰ ＵＲＬスキームはリソースＵＲＩを含む。ｈｔｔｐＵＲＬに対するスキーム特有のシンタックスおよびセマンティクスは下記のようである。
http_URL= “http:” “//”host [“:”port][request-uri]
ポートがエンプティであるかまたは与えられない場合、ポート８０が仮定される。セマンティクスは、識別されたリソースが、そのホストのそのポートにおけるＴＣＰ接続に関して聴取するサーバに設けられ、リクエストＵＲＩがリソースを識別するということである。リクエストＵＲＩに対するシンタックスおよびセマンティクスは下記のようである。
Request-uri= abs_path [“?”query-string]
なお、abs_pathはリソースの識別標識であり、照会ストリング（query string）は、リクエストを処理するために使用することができる任意の種類の情報である。
【０００６】
ヘッダ・フィールドは、リクエストまたは応答に関連したメタ情報を搬送する。
【０００７】
ＨＰＰＴメッセージのメッセージ本体は、リクエストおよび応答に関連したエンティティ本体を搬送するために使用される。
【０００８】
図２に示されたメッセージ本体は、図３に示されるような構造を有する実際のＳＯＡＰメッセージを含む。エンベロープ・セクション内では、いわゆるＳＯＡＰヘッダを構成する多数のヘッダ・フィールド１、...ｎが定義され、そのＳＯＡＰヘッダに続いて、第２の多数のいわゆる本体フィールド１、...ｎを含む実際のＳＯＡＰ本体が後続する。
【０００９】
ネットワークを介して、例えば、ＨＴＴＰのような搬送プロトコルによって搬送されたＳＯＡＰメッセージの全体構造が、図１乃至図３の集合体として図４に示される。
【００１０】
図１は、ＨＴＴＰ ＰＯＳＴコマンドによって搬送されるＳＯＡＰの例を示す。ＨＴＴＰリクエスト方法はＰＯＳＴであり、リソースＵＲＩは、リクエストが意図しているリソースを識別する絶対的パスである“/StockQuote”である。リソースＵＲＩは、キュー・ストリングを含まない。
【００１１】
ＳＯＡＰの他に、従来技術には上記第２の関連のウェブ・サービス標準がある。ウェブ・サービス記述言語（ＷＳＤＬ）は、ドキュメント指向ペイロードまたはリモート・プロシージャ・コール（ＲＰＣ）ペイロードを含むメッセージに関するエンドポイント・オペレーションのセットとしてウェブ・サービスを記述するためのＸＭＬドキュメントである。いわゆるサービス・インターフェースは、メッセージ構造および簡単なメッセージ交換のシーケンス（または、ＷＳＤＬ用語における「オペレーション」）によって抽象的に定義される。しかも、それらは、エンドポイントを定義するために具体的なネットワーク・プロトコルおよびデータ終了フォーマットにバインドされる。関連する具体的なエンドポイントが、抽象的なエンドポイント（サービス）を定義するために束ねられる。
【００１２】
ＷＳＤＬは、サービス呼び出しのために使用されるプロトコル・バインディングとは異なるサービス・インターフェース定義をサポートする。ＷＳＤＬは、単一のサービスに対して複数のバインディングを可能にする。サービス・インターフェース定義およびアクセス・バインディングは、サービスの機能性を具現化したものとも異なる。サービス要求者は、通常、対応するＷＳＤＬからウェブ・サービスに対するクライアント・スタブ・コードを生成する。サービスのＷＳＤＬは、通常、サービス提供者から要求される。クライアント・スタブ・コードは、エンドポイントをアドレスするための正しいメッセージ構造および正しいデータ・エンコーディングを作成するために必要なロジックを実装する。サービスの定義、バインディング、および実装の間に差異が存在するので、或る定義およびバインディングのために作成されたクライアント・スタブ・コードは、通常、コード変更を必要とすることなく、単に別のエンドポイント・アドレスを使用することによって、種々のエンドポイントをアドレスすることができる。図５およびそれの続きである図６は、更に詳細な例示的ＷＳＤＬドキュメントを当業者に開示するために示される。
【００１３】
ウェブ・サービスの重要な特徴は、それらが要求・応答方式に従ってステートレスであることである。ステートレス・サーバは、以前のいずれのリクエストにも無関係の独立したトランザクションとして各リクエストを扱うサーバである。これは、進行中の対話に対処するために記憶装置を割り当てる必要がないため、あるいはトランザクション途中でクライアントが消滅した場合にそれを解放することに煩わされる必要がないため、サーバの設計を簡単にする。欠点は、各リクエストに多くの情報を含む必要があること、およびこの余分な情報がいつもサーバによって解釈される必要があることである。
【００１４】
上記の種類の電子通信が行われる場合の制約条件を説明したが、従来技術の欠点を次に説明することにする。
【００１５】
ウェブ・サービスの商業的使用は、サービス提供者とサービス要求者との間に締結された契約に基づく。そのような契約は、ウェブ・サービスまたはウェブ・アプリケーションを使用および規定するための条件に関する同意を表す。契約の詳細は、そのサービスの請求書を作成するための条件、即ち、価格、更に詳細な方法でサービスの所望の質を指定するサービス・レベル、並びにサービス要求者およびサービス提供者の両方にとって非常にクリティカルである更なる情報を指定することが可能である。基本的には、従来のビジネスには、契約の範囲または契約の数に関する制限はない。１つの契約が複数のサービスを含んでもよく、１つのサービスが、すべて同時に有効な複数の契約に含まれてもよい。
【００１６】
典型的な従来のシナリオでは、２つの当事者、即ち、本願ではサービス要求者またはＳＣと呼ばれるサービス消費者が通信を行うか、または、３つの当事者が、即ち、サービス要求者、上記の契約を管理するサービス提供者およびＳＳと呼ばれるサービス供給者が、ウェブ・サービス通信を構成する。なお、サービス供給者は、時には要求者に見えないままでサービスを実際に遂行する。
【００１７】
上記のウェブ・サービス機構に関して詳述した、そのような従来技術に関する唯一の開示文献は、２００２年にwww.alphaworks.com. の下に６０日の試行期間中に入手し得た「IBMWeb Services Toolkit」および「Emerging Technologies Toolkit」として発行されている。
【００１８】
「契約サービス（Contract Service）」と呼ばれ、本発明に関するほとんどの技術的特徴を含むソフトウェア・コンポーネントに関するショート・レビューは次のようなことを示している。
【００１９】
その契約サービスは、サービス提供者とサービス要求者との間の関係を扱うものである。それは、サービス提供者とサービス・ハブとの間の契約のタイプ（デプロイメント契約、プロバイダ契約としても知られている）およびサービス要求者とサービス・ハブとの間の契約のタイプ（使用契約）に関する情報を提供する。使用契約は、サービス・ハブを介して提供された任意のサービスを任意に組み合わせたオペレーションに加入するために用いることができる。使用契約は、サービスに対するコールを課金する方法（時間、使用回数、使用量等による課金）および加入したサービス・オペレーションがクライアントにとってどのくらいの費用になるかというような情報を含む。各使用契約に対して、契約サービスは使用されるべき支払方法およびレーティング・モデル、その契約に関する有効日を定義する。契約は、両当事者（サービス・ハブおよびサービス提供者／供給者）のその契約に対するデジタル署名を任意選択的に記憶してもよい。ウェブ・サービス・ツールキットと共に出荷されるユーティリティ・サービス・デモでは、そのデモと共に供給されるユーティリティ・サービス・ポータルを介して契約サービスに、契約が加えられる。有効な契約は、サービス要求者がサービスを使用できるようになる前にサービス・ハブとそのサービス要求者との間では準備のできた状態になければならない。
【００２０】
契約サービスは、次のようなＷＳＤＬ定義のオペレーションをサポートする。
・ 契約を作成するための createContract
・ 契約モデルを読み取るための getContractModel
・ 契約の現状態を読み取るための getContractState
・ 契約の現状態を更新するための updatetContractState
・ 契約のタイプを読み取るための getContractType
・ 契約のプロパティをセットするための setContractProperty
・ 契約のプロパティを読み取るための getContractProperty
・ 所与のサービス消費者にとって有効な使用契約を検索するための getUsageContractsForValidForIdentity。
【００２１】
サービス・リクエストがサーバに到達するとき，上記の契約サービスは、サービス・リクエストの実行前に、契約がそのリクエストに関連していることをチェックする。１つの契約しか存在せず、基礎となるサービスが複数レベルのサービスの質に分化する可能性のない単一の方法で遂行され得る限り、如何なるそれ以上の問題なしにサービスを提供することが可能である。
【００２２】
しかし、ウェブ・サービスの絶えず増加する申し出および使用のために、それらのウェブ・サービスは多種の品質レベルに分かれている。それぞれのサービス提供者がそれらのレベルにおけるサービスを提供することが可能である。例えば、より長い「サービス提供時間」に比べてそのサービスを更に高価にするサービスを非常に速く提供することが可能である。あるいは、サービスによって与えられた情報は多少精巧であってもよく、従って、サービス要求者に多少詳細なものを、例えば、経済的な情報システムのそれぞれ変化する内容を与えることが可能である。従って、それぞれの複数の契約または契約属性はサービス提供者およびサービス要求者の間で有効であり、それらを拘束する。この状況において、即ち、複数の契約または契約属性が関連し、有効である場合、上記の契約サービスは、リクエストのために使用されるべき実際の契約を選択しなければならず、あるいは単一の契約がサービスの種々の品質レベルに対するそれぞれの契約属性を指定する場合に実際の契約属性を使用しなければならない。選択された契約または契約属性は、現在のサービス・リクエストに対する現在の条件、例えば、上述のようなオペレーションの価格を指定する。
【００２３】
ネットワークを介して送られたリクエストが如何なる種類の契約明細または契約関連の情報を含まないとき、従来技術におけるサービス要求者サイドのクライアントは、そのような複数の契約状況における特定のサービス・リクエストに関して使用すべき実際の契約を選択することができず、そのクライアントは選択のプロセスに影響を与えることができない。換言すれば、リクエストが提供され、それが実際に要求者のためのものである的確な条件が、従来技術では当事者でないものによって、即ち、サービス提供者によって選択される。この欠点は、特に、ＵＤＤＩ、ＷＳＩＬ、ＷＳＤＬ、ＳＯＡＰのような既存のウェブ・サービス・プロトコル標準が、オペレーションまたはサービス・リクエストに対する契約を選択するための如何なる方法も考慮していないという事実に基づいている。
【００２４】
この問題の不満足な処理を行うことは、サービス提供者が実際の契約または実際の契約属性を選択するが、要求者がその契約に影響力を持たないことを意味し、あるいは、同じサービスに対する各粒状的な品質レベルに関しては別の契約が定義され、従って、１つの同じサービスが論理的および形式的にそれぞれのサービスに分裂することを意味する。しかし、これは、サービス消費者に対するマン・マシン・インターフェースを複雑にし、使用を難しくする。
【非特許文献１】「IBM Web Services Toolkit」under www.alphaworks.com.
【非特許文献２】「Emerging TechnologiesToolkit」under www.alphaworks.com.
【発明の開示】
【発明が解決しようとする課題】
【００２５】
従って、本発明の目的は、「特許請求の範囲」の請求項１の前文に記載の方法に対する改良を施すことにより、上記の欠点を回避または少なくとも減じさせることにある。
【課題を解決するための手段】
【００２６】
本発明のこの目的は、「特許請求の範囲」の従属項に記載された特徴によって達成される。本発明の更なる利点および実施例はそれぞれの従属項に示される。「特許請求の範囲」の記載を参照してほしい。
【００２７】
本発明の基本的な局面によれば、「特許請求の範囲」の請求項１の前文において定義された方法は、サービスを要求するリクエストの中に所与のサービス明細の選択を契約データが指定することをそのリクエスト内に含むステップによって更に改善される。
【００２８】
本発明のこの一般的な特徴によって、サービス提供者サイドに存在する契約サービス・ソフトウェア・コンポーネントは、それがそのリクエストからそのような契約データを抽出し、所定のルールに従ってそれを評価して、サービス提供者が上記の契約データの助けによって要求したサービスの質を、サービス提供者が正確に規定することを可能にする。
【００２９】
本発明の望ましい特徴によれば、上記契約データは、クライアント・サイドおよびサーバ・サイドの両方に存在し且つ上記契約データを含むそれぞれのソフトウェア・インターフェースを介して処理される。上記インターフェースは、使用中の搬送プロトコルの定義、使用中のメッセージング・プロトコルの定義、および使用中の関連ポートに関する定義のそれぞれを含む。勿論、そのようなソフトウェア・インターフェースは、そのようなサービスが更なる開発のためにやがて変更されることがあり得るので、サービスのタイプおよびバージョンのそれぞれに従ってプログラムされ、管理されなければならない。
【００３０】
更に、本発明の更なる望ましい局面によれば、上記契約データは、ウェブ・サービス・リクエスト・メッセージのヘッダ・フィールド内で処理されることがあり得る。
【００３１】
この場合、リクエスト評価ソフトウェア・コンポーネントは、勿論、そのようなヘッダ・フィールド内容を抽出しなければならず、従って、それぞれのプログラミングを必要とする。
【００３２】
本発明のほとんどの好適な局面によれば、上記契約データは、それぞれのサービス・リクエストのエンドポイント明細から成り、それの一部として処理される。この特徴は、クライアントおよびサービス要求者がサービス・リクエストに対する１つまたは複数の契約を選択することを可能にする方法を定義し、一方、既存のウェブ・サービス・プロトコルおよびインフラストラクチャは変更なしに使用することが可能である。
【００３３】
サービス・リクエストを構成し且つクライアントによってサーバに送られたメッセージ自体は、１つまたは複数の契約を選択するためにサーバによって使用されるそのような情報を含む。
【００３４】
更に、契約選択パラメータは、基本的には契約の内容または特定の契約を識別するメタデータを参照することも可能である。内容は、サービスの質が直接に処理されるとき、例えば、サービス・パフォーマンス条件またはサービス内容条件が以下のように例示的に定義されるときに参照される。
（ａ）サービスの価格＜一定の上限価格、例えば１０ＵＳＤ、または
（ｂ）０.５秒よりも小さいかまたは等しい応答時間、または
（ｃ）９０％よりも大きいサービスの可用性、または
（ｄ）提供されたサービスの複雑性を、例えば、一方では短い要約のような情報として、または、他方では詳細な報告書として、処理する別の基準。
【００３５】
上記の意味での契約メタデータに関する例は、例えば、複数の(例えば３０個の)識別文字から成る独特のＩＤに従って契約が指定されるときである。
【００３６】
更に、本発明の望ましい局面によれば、上記の契約選択基準の組み合わせがサービス消費者(要求者)によって指定され得るし、サービス提供者によって提示され得ることは留意すべきである。１つの例は、上記の（ａ）ＡＮＤ（ｂ）ＯＲ（ａ）ＡＮＤ（ｃ）という要件と結合されたリクエスト指定契約ＩＤ「hhffkk-rrsslloo-ooddggjj-idghwelf-oodbmmss」である。
【００３７】
「特許請求の範囲」の記載から明らかなように、本発明は、ソフトウェア／ハードウェア・システムを要求者および提供者の間に分散したものと見なすことができる。特に、提供者サイドは、サービス提供者（サービス・ハブとも呼ばれる）およびサービス供給者と共に前述したように、２つ以上の別の機関に分裂することも可能である。上記分散性質のために、サーバ部分およびクライアント部分のそれぞれに対して「特許請求の範囲」の特定の請求項が存在する。これは、提供者サイトまたは要求者サイトにおける複数の単一ハードウェア・システム上に本発明の機能を分散する可能性も含む。例えば、本発明の方法の要求者サイトまたは提供者サイトそれぞれのステップは、インターセプタ・コンピュータにおいて部分的または全体的に具現化することが可能である。なお、インターセプタ・コンピュータは、実際の各データベース・アプリケーションを含む専用のサーバ・システムに着信メッセージが実際に送られる前に、その着信メッセージをインターセプトおよび処理するための企業のファイアウォール概念で統合されたゲートウェイ・コンポーネントとして配列される。
【００３８】
本発明の第１の利点は、クライアントが契約の選択を可能にされ、従って、所望のサービスに対する条件の選択を可能にされることである。契約選択を指定するパラメータはサービス・リクエストを構成するリクエスト・メッセージの一部であるので、本発明は、ステートレス・ウェブ・サービスに十分に適している。
【００３９】
本発明は、既存の標準的なウェブ・サービス・プロトコルを使用し、それをてこ入れする。最も望ましい特徴によれば、それは既存のウェブ・サービス・インフラストラクチャの拡張を必要とせず、そのウェブ・サービス・インフラストラクチャおよびサービスの実施の両方にとって透明である。従って、それは、例えば、.NET および JAVA ウェブ・サービスのような異種の環境に十分適している。従って、種々の契約フィーチャおよびその代替に基づいた広範な種々のサービスが、その場合にサービス・インターフェースを変更することなく、ネットワークを介して行われる。その場合、契約データは、上記の最も好適な代替方法であるサービス・リクエストのエンドポイント明細の一部として処理される。この場合、サービス・インターフェース（ハードウェアでもソフトウェアでもない）は変更される必要がなく、ネットワークを介して送られたすべてのメッセージが従来技術におけるクライアント・プロキシを形成するための標準およびツールに依然として準拠し、クライアント・アプリケーション・プログラミング・インターフェース（ＡＰＩ）が依然として使用可能である。
【００４０】
メッセージの「エンドポイント」という用語は、メッセージを送るまたは受け取るリソース（任意の種類のハードウェアまたはソフトウェア・リソース）を表す。リクエストの「エンドポイント」という用語は、リクエストを送るまたはリクエストを受け取って処理することを意図されたリソースを表す。「エンドポイント明細」という用語は、そのようなリソースの識別標識を表す。任意の種類のエンドポイント明細の表示が可能である。一般には、エンドポイント明細は、ＨＴＴＰ−ＵＲＬまたはリクエスト−ＵＲＩとして示される。図１は、リクエスト−ＵＲＩ“/StockQuote”として示されたエンドポイント明細を含む。
【００４１】
ウェブ・サービスに関して、エンドポイントは、特定のフォーマットのメッセージを受け取るか、またはリクエストおよび応答メッセージの特定のフォーマットにより特徴付けられた特定のオペレーション、特定のデータ・エンコーディング、および特定のネットワーク・プロトコルを実現するリソースである。一般に、エンドポイントは、プロトコル・レベルのエンドポイント・アドレス、例えば、ＨＴＴＰ−ＵＲＬまたはリクエスト−ＵＲＩによって指定される。
【００４２】
「ステートレス」リクエストは、リクエストが別のトランザクションとして処理され、如何なる他の（以前または将来の）リクエストにも関係ないことを意味する。一般に、リクエストはサーバによって処理され、応答は直ちに戻され、しかる後このリクエストに関連したサーバに関するすべての情報が削除される。換言すれば、サーバは、リクエストが処理された後はそのリクエストの状態を保存しない。
【発明を実施するための最良の形態】
【００４３】
次に、本発明の方法およびシステムの好適な実施態様を説明する。ここでは、本発明の契約システムのランタイム動作、即ち、サービス・リクエストが処理されるときの動作に焦点が置かれる。
【００４４】
基本的には、契約システムは、次のようなものでなければならない。
（１）実際の着信サービス・リクエストが少なくとも１つの有効な契約に適合することを検証する。
（２）その契約によって指定された、このサービス・リクエストに対する使用条件を検索する。
【００４５】
本発明による契約システムは任意の契約タイプをサポートすることが可能である。各契約は１つの契約タイプのインスタンスである。種々の契約タイプが同じデータ・モデルに基づいている。即ち、すべての契約が状態（有効、無効、または削除済み）、契約タイプおよび契約ドキュメントを示す参照付を含む。これは、個々の契約データ、即ち、契約項目、即ち、サービス・オペレーションと、それを使用するための契約条件（terms and conditions）を含むＸＭＬ構造であってもよい。契約ドキュメントの書式は契約タイプに依存する。
【００４６】
説明の便宜上、１つの契約タイプだけを更に詳しく説明する。タイプ「用途」という契約、即ち、使用契約は、１つのサービス消費者と１つのサービス提供者との間の同意を表す。
【００４７】
各使用契約は、サービス消費者の特有のアイデンティティと関連している。典型的なシナリオでは、契約システムはサービス提供者のサイドに立っており、従って、サービス提供者のアイデンティティは使用契約に明示的には含まれていないが、暗示的に示される。
【００４８】
サービス提供者は、サービス消費者が有効な使用契約によってカバーされたサービス・オペレーションを単に呼び出すことができることを保証するために契約システムを使用する。消費者が１つのサービス・オペレーションに対して複数の有効な契約を持つことができるといことは留意すべきである。
【００４９】
使用契約は、契約名、消費者即ちサービス要求者のアイデンティティ・キー、開始日、および終了日を含む。それは、サービス・オペレーションのキーおよび関連するレーティングのキーを指定する１つまたは複数のサービス・エレメントを含む。この例では、サロゲート・キーが使用されるが、実際の実施方法次第で、他のタイプのキーも使用可能である。レーティング・モデルは、サービス・オペレーションに対するコールがどのように（時間、使用の数等によって）課金されるべきか、および参加したサービス・オペレーションがその消費者に対してどのくらいの費用をかけるべきか、を指定する。これは、下記の表１から生じる。
【表１】
【００５０】
このサンプルの契約タイプのほかに、この基本的アーキテクチャは他の契約タイプを容易に加えることを可能にする。他のタイプの契約はサービス属性の質、即ち、応答時間、可用性等を指定することも可能である。
【００５１】
以下には、２つの典型的なランタイム・シナリオが示され、サービス消費者、サービス提供者、およびサービス供給者の間の相互作用が示される。上記のシナリオが始まる前では、懸案の契約は多くの方法を通して、例えば、「伝統的な」成文の書面を通して締結され得るので、その契約を作成する方法は本発明の範囲に入らないが、サービスが要求される前には１つまたは複数の有効な契約が準備のできた状態にあるものと考えられることに留意すべきである。
【００５２】
図７を参照すると、ＳＳと略記されるサービス供給者がＳＣと略記されるサービス消費者にサービスを提供するというシナリオが開示される。ＳＰと略記されるサービス提供者は、本発明の主要なソフトウェア・コンポーネントを含む契約管理インフラストラクチャを実現している。
【００５３】
この結果、次のような相互作用が生じる。その相互作用は、この実施例によれば、それぞれのプログラム・モジュールにおいて当事者Ａ、Ｂ、およびＣにより使用される本発明の各方法の「ステップ」として実施される。図面に示されるように、下記のステップが遂行される。
【００５４】
ステップ６１０：ＳＳによって提供されるビジネス・サービスを呼び出すために、ＳＣがサービス・リクエストを開始する。
【００５５】
ステップ６２０：ＳＰによって提供される契約システムおよびインフラストラクチャ・サービスを使用するために、ＳＳがＳＰにサービス・リクエストを送る。特に、この実施例では、契約システム・サービスは契約サービスを含み、インフラストラクチャは計量サービスおよびプロファイリング・サービスである。
【００５６】
ステップ６３０：ＳＰが、要求された契約システムおよびインフラストラクチャ・サービスを遂行する、例えば、有効な契約が得られることを確認し、計量イベントを開始し、ＳＰに状態を戻す。
【００５７】
ステップ６４０：ＳＳが、要求されたサービスを遂行し、十分な計量イベントを生成するためにＳＰを呼び出す。
【００５８】
ステップ６５０：ＳＳが、サービス結果を表すデータをＳＣに送る。
【００５９】
ステップ６２０の実施は図８に更に詳細に示される。サービス提供者は、破線の枠で示されたアプリケーション・サーバを実現する。そのアプリケーション・サーバは、サービス・リクエストのためのランタイム環境、例えば、Apache Axis のようなウェブ・サービス・ランタイム環境、を具現化するサーブレット７１を含む。
【００６０】
アプリケーション・サーバは、参照符号７２、７４、７６によって示された複数のハンドラ・コンポーネントも含む。これらのハンドラは、リモート・サーバにおいて、例えば、更なるウェブ・サービスとして実現可能であるインフラストラクチャ・コンポーネントＦ〜Ｈのローカル実施を実現する。ハンドラ７２、７４、７６は、リモート・サービスとのコミュニケーションを処理することを必要とするローカル機能を提供する。
・ プロファイル・ハンドラ７２は、要求者のアイデンティティを検証するために外部のプロファイル・サービスを使用する。
・ 契約ハンドラ７４は、契約状態および契約有効性を検証するために外部の契約サービスを使用する。
・ 計量ハンドラ７６は、十分な計量イベント（開始イベント、終了イベント、アドホック・イベント、取消しイベント等）を生成する。
【００６１】
コンポーネント７１，７２，７６（サーブレットおよびハンドラ）は、共用メモリ環境において動作し、共用データを通してコミュニケーションを行う。サーブレット７１は、ハンドラが正しい順序で呼び出されることを保証する。次に、インフラストラクチャ・サービスを説明する。
【００６２】
プロファイル・サービス（７２Ａ）は、基本的には、上記の従来技術において得られるものとして使用することが可能である。
【００６３】
プロファイル・サービスは、名前、アドレス、ユーザＩＤ等のようなユーザ・プロファイル情報に対するアクセスを提供する。実施方法次第で、これは、多くの情報を含むように拡張することが可能である。プロファイル・サービスは、プロファイル情報を保存、削除、および取得するために使用することが可能である。他のサービスが正しく働くためには、ビジネス・サービスのすべてのユーザがプロファイル・サービスによってプロファイルを割り当てられなければならない。プロファイルは、ユーザ・インターフェースを使用することによって、またはプロファイルを保持するＸＭＬファイルを直接に編集することによって、事前に作成することが可能である。このプロファイル・サービスは、Tivoli Identity Manager のような任意の他のアイデンティティ・システムによって置換されることもあり得る。
【００６４】
契約サービス７４Ａは本発明の契約コンセプトを具現化し、下記のようなＷＳＤＬ定義のオペレーションをサポートする。
・ createContract– 契約を作成する
・ getContractModel– 契約の情報および内容を検索する
・ getContractState– 契約の実際の状態を得る
・ updateContractState – 契約の状態（例えば、有効、無効）をセットする
・ getUsageContractsForValidForIdentity -所与のサービス消費者にとって有効な使用契約を検索する。
【００６５】
計量サービス７６Ａが後述のように計量イベントを受取り、それらの計量イベントを永続的に記憶し、要求時に計量イベントを検索する。この好適な実施例によれば、特定のサービスを使用して特定のクライアントに対する使用レポートを作るために、契約サービス７４からの契約情報と関連して計量サービスを使用することが可能である。契約サービスおよび計量サービスが直接に相互作用しないことは留意すべきである。
【００６６】
計量サービス７６Ａは下記の３つのタイプのオペレーションをサポートする。
・ recordMeterEvent– １つの計量イベントを保存する
・ recordMeterEvents– 複数の計量イベントを保存する
・ getMeterEvents– 計量サービスから複数の計量イベントを検索する。
【００６７】
計量イベントは、コールされたサービスのサービス名およびオペレーション名、タイムスタンプ、およびリクエストを処理するために使用される契約のＩＤを含む。計量イベントはタイプによって変わり、従ってサービス・コールを課金する種々の方法が可能である。
・ サービスに対するアクセスが、そのサービスを遂行するために使用された時間の量だけ課金されるとき、開始／終了イベントが使用される。
・ サービスがアクセスされる回数だけまたは回数以外の他のいずれかに基づいてアクセスが課金されるとき、アドホック・イベントが使用される。
【００６８】
上記のほかに、更に下記の２つのタイプのイベントが使用可能である。
（ａ）イベントを取消すために使用され、既に計量サービスに送られている「取消し済み」というイベント、および
（ｂ）イベントのタイプがサービス要求者によって供給されなかったときに使用される「未知」というイベント。
【００６９】
上記のソフトウェア・コンポーネントの間の相互作用は下記のようになる。
ステップ７１０：サーブレット７１が、サービス供給者によって開始されたサービス・リクエストを受取り、メッセージ・コンテキストを抽出し、それを次のハンドラ・コンポーネント上に送る。
ステップ７２０：共用のデータ・オブジェクトであるメッセージ・コンテキストが次に続くハンドラ・コンポーネントに送られる。ハンドラはメッセージ・コンテキストを拡張／修正し、それをそのチェーンにおける次のハンドラ上に送る。
ステップ７３０：プロファイル・ハンドラ７２が、サービス供給者のアイデンティティをチェックするために、それぞれのデータ・ベース・アプリケーションを含む外部のプロファイル・サービス７２Ａへのサービス・リクエストを開始する。
ステップ７４０：プロファイル・サービス７２がアイデンティティ・チェック結果をＳＰのプロファイル・ハンドラに戻す。
ステップ７５０：契約ハンドラが、対応する契約を識別および有効化するために外部の契約サービス７４Ａをコールする。それは、「getUsageContractsForValidForIdentity」オペレーションをコールし、プロファイル・サービス結果から得られたサービス消費者アイデンティティを送る。本発明に従って、契約サービス７４Ａがこのアイデンティティに対する１つの有効な契約を選択する。その選択はサービス消費者アイデンティティのみに基づくだけである。即ち、サービス消費者またはいずれかの他のコンポーネントがその選択に影響を与えるための手段、例えば、複数の矛盾した有効な契約の間で優先順位を指定するための手段は従来技術には、存在しないということに留意すべきである。
ステップ７６０：契約サービス７４Ａが契約状態および有効性をＳＰの契約ハンドラに戻す。有効な契約が見つからない場合、例外が生じる。
ステップ７７０：ビジネス・サービス・コールの状態を反映する計量イベントを生成するために、計量ハンドラ７６が外部の計量サービス７６Ａを呼び出す。
ステップ７８０：計量ハンドラがその更新されたメッセージ・コンテキストをサーブレットに戻す。
ステップ７９０：サーブレット７１が初期サービス・コール(リクエスト)の結果をサービス供給者に戻す。
【００７０】
別のシナリオでは、図９および図１０に関して、サービス提供者がサービス消費者にサービスを提供する。サービス・リクエストを満たすために、サービス提供者はサービス供給者からのサービスを要求する。特に、
ステップ８１０：ＳＣがＳＰからのビジネス・サービスを要求する。
ステップ８２０：ＳＰが契約システムおよびインフラストラクチャ・サービスを使用して、有効な契約が得られることを確認し、開始計量イベントを起動し、しかる後、ＳＳからのサービスを要求する。
ステップ８３０：ＳＳがサービスを遂行し、結果をＳＰに戻す。
ステップ８４０：ＳＰが終了計量イベントを生成し、ビジネス・サービス結果をＳＣに戻す。
【００７１】
図１０に関連して、本発明の実施方法を示し、説明することにする。サービス提供者は、図７および図８に関連して上述したようにアプリケーション・サーバを実現する。従って、次に主としてその相違点を説明する。
【００７２】
この特定の実施例によれば、サービス・ハンドラ９０が外部のビジネス・サービスを呼び出す。そのビジネス・サービスはサービス供給者（ＳＳ）によって提供される。
【００７３】
コンポーネント・サーブレット９１およびハンドラ７２、７４、７６（図１０の右縁参照）が再び共用メモリ環境において実行され、共用データを介してコミュニケーションを行う。サーブレット９１は、シナリオ２における特定の相違点から生じる、図８における上述したサーブレットに対するそれぞれの相違点のみを有し、ハンドラが正しい順序で呼び出されることを保証する。
【００７４】
ビジネス・ウェブ・サービス９２は、サービス供給者によって提供される外部のサーバ・コンポーネントである。それは、要求されたサービス・コールを遂行するためにステップ９１０において呼び出される。
【００７５】
これらのコンポーネント間の相互作用は次のようになる。
ステップ９１０：サーブレット９１が、サービス消費者(ＳＣ)により発せられたサービス・リクエストを受取り、メッセージ・コンテキストを抽出し、それを後続のハンドラ・コンポーネント上に送る。
ステップ７２０〜７７０：上記のシナリオ１を参照。
ステップ９８０：サービス・ハンドラ９０がその要求されたビジネス・サービス９２を呼び出し、その結果生じたサービス応答でもってメッセージ・コンテキストを更新する。
ステップ９８５：それをサービス・ハンドラ９２に戻す。
ステップ９９０：サービス・ハンドラがその更新されたメッセージ・コンテキストをサーブレット９１に戻す。
ステップ９９５：サーブレット９１が初期コールの結果をサービス消費者に戻す。
【００７６】
本発明によれば、契約選択データを組み込んだ、本発明の好適なメッセージ交換によるロジックを示す図１１を参照すると、契約情報が、サービス・リクエストのエンドポイント明細の一部としてクライアント・サイド、即ちサービス消費者、によってエンコードされる(ステップ１３００参照)。エンドポイントは、展開されたウェブ・サービスをサーバにおいて呼び出すことができるアドレスである。通常、それはＵＲＬを含む。サービス・リクエスト・メッセージはエンドポイントの明細を含む。
【００７７】
照会ストリング部分はメッセージの処理または経路指定のどちらにも影響を与えない。それは、これがサーブレット・エンジン、ＳＯＡＰサーバ、または如何なる従来技術のコンポーネントによってもサービス実施方法を見出すことに適するとは考えられないためである。従って、契約情報をそこに含むことが望ましい。
【００７８】
そこで、クライアント・ステップ１３０５において、前記契約選択データ、例えば、契約識別標識として働く整数、によって強化されたＳＯＡＰリクエストがサーバ・サイドに送られる。
【００７９】
次に、ステップ１３１０において、提供者サイトにおけるアプリケーション・サーバがそのリクエストを受取り、ステップ１３２０ではそれにより契約選択情報を受取り、ステップ１３３０において、そのリクエストの照会ストリングから契約選択情報を評価する。それによって、サーバは所望のサービスに対する所望の契約を決定することができ(ステップ１３４０)、上記の照会ストリングからデータおよびパラメータを契約が指定することによって詳述のようにサービスを呼び出すことができる。
【００８０】
更に、ステップ１３５０において、それぞれのサービスがアセンブルされ、それぞれのＳＯＡＰ応答メッセージが生成されて(ステップ１３５０) クライアントに送られる。クライアントは、ステップ１３６０においてそのメッセージを受け取る。
【００８１】
更に、以下は、ウェブを介した契約選択という本発明のコンセプトに留意すべきである。契約選択パラメータは、契約サービスのようなウェブ・サービス管理コンポーネントによって作成される契約識別標識のような契約メタデータ、または契約内容を参照することが可能である。価格、サービスの質等のような契約によってカバーされるすべての変数を、内容関連の契約選択パラメータにおいて参照することが可能である。契約の選択に関する複雑な条件を作成するために、種々の契約選択パラメータを結合することが可能である。
【００８２】
単一または複数の結合された契約選択パラメータは、サービス要求者およびサービス提供者の両方にとって理解可能な文法に適応するテキスト・ストリングとして表すことが可能である。本発明は、いずれの文法によっても使用することが可能である。例えば、契約選択パラメータは、特定のＸＭＬスキーマに基づいてＸＭＬ言語で表すことが可能である。ＸＭＬデータはストリングとしてエンコードされるので、エンドポイント・アドレス・エンコーディングの本発明の特徴は、この契約情報をサービス・リクエスト・メッセージに有利に組み込むために使用することが可能である。
【００８３】
本発明の使用に関する１つの例示的ケースでは、サービス要求者はサービス・リクエストに対する価格限界を設定することを望む。従って、サービス要求者は、価格に対する上限を表す条件を表す適当なパラメータ（「price<$10」）を選択し、このパラメータをサービス・リクエストに含める。このパラメータは契約の内容を参照することが、契約ＩＤによって契約を明確に選択するものではない。
【００８４】
本発明の特定の実施例では、このパラメータは、下記のようにＸＭＬ言語でエンコードすることが可能である。
<contract>
<price>
<max>
10
</max>
</price>
</contract>
【００８５】
都合のよいことに、契約選択パラメータは、エンドポイント・アドレスの照会ストリングの一部として下記のようにエンコードすることが可能である。
String
endpoint=address+”<contract><price><max>10</max></price></contract>”
【００８６】
サーバは、サービス要求者にとって有効であり且つ所与のパラメータに対応する条件を満たす契約を選択する。
【００８７】
この例では、図７乃至図１０に関連して上述したアプリケーション・サーバであるサーバがその有効な契約の内容を検索し、契約条件に従って仮定の価格を計算し、この価格を価格限界と比較する。それによって、サーバは多くの適格な契約を決定する。複数の契約が適格となる場合、サーバは、これまで説明した発明概念に容易に追加し得る任意の更なるロジックに従って１つを選択する。適格となる契約がない場合、サーバはエラーを表すために例外を生じる。
【００８８】
下記の擬似コードの例は、固定の契約要素および可変の契約要素に関する条件を評価することによってサーバ・ロジックを具現化する。固定の要素は、リクエストの時間または内容に依存しない。それの例は、メタデータ要素（例えば、契約ＩＤ）および固定の価格である。可変の要素は、時刻またはサービス・リクエストに依存する。例えば、サービス価格はリクエスト・メッセージにおける時間または他の入力パラメータに依存する。固定の要素に関する条件はデータベース照会において統合することが可能であるが、可変の要素に関する条件は、契約を評価することおよび変数を計算することによってチェックされる必要がある。
【００８９】
Pseudocode-begin（擬似コード始まり）:
Get contract info from request message（リクエスト・メッセージから契約情報を得る）;
Getcontract selection parameters (CSP) from contact info（契約情報から契約選択パラメータ（ＣＳＰ）を得る）;
Getfixed and variable conditions from CSP（固定および可変の条件をＣＳＰから得る）
Selectcontracts from database, which（データベースから契約を選択する）
1)are valid for the requester identity（その契約は要求者アイデンティティにとって有効である）
AND
2) satisfy the fixed conditions（その契約は固定の条件を満たす）;
Ifno contracts are available exit with error（契約が使用可能でない場合、エラーでもって終わる）；
Checkthe variable conditions for each of the available contracts by reading thecontracts content and by dynamically evaluating the variables（契約内容を読むことおよび変数を動的に評価することによって各使用可能な契約に対する可変の条件をチェックする）；
Ifmore than one contract satisfies the conditions, then perform further logic toselect one (e.g. Random selection, take first one) （複数の契約が条件を満たす場合、１つを選択するために更なるロジック（例えば、最初の１つを取るランダム選択）を遂行する）；
Ifno contract satisfies the conditions exit with error（条件を満たす契約がない場合、エラーでもって終了する）；
Pseudocode-end（擬似コード終り）
【００９０】
この擬似コードは、契約サービスでは、上述の getUsageContractsForValidForIdentity オペレーションであるいはそれとは別に１つまたは複数の異なるオペレーションで実現することが可能である。
【００９１】
本発明は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの結合によって実現することが可能である。本発明によるツールは、１つのコンピュータ・システムにおいて集中態様で、または幾つもの相互接続されたコンピュータ・システムにまたがって種々の要素が分布する分散態様で実現することが可能である。本願において開示された方法を実行するように適応した任意の種類のコンピュータ・システムまたは他の装置が適する。ハードウェアおよびソフトウェアの典型的な結合は、ロードおよび実行時に上記の方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを有した汎用コンピュータ・システムであってもよい。
【００９２】
上記の方法の実施を可能にするすべてのフィーチャを含み、コンピュータ・システムにロードされるとき、これらの方法を実行することができるコンピュータ・プログラムに本発明を組み込むことも可能である。
【００９３】
本願の関連におけるコンピュータ・プログラム手段またはコンピュータ・プログラムは、特定の機能を直接に、または
（ａ）他の言語、コード、または表記法への変換、
（ｂ）異なる具体的な形体における複製
のいずれかまたは両方の後、情報処理機能を有するシステムに特定の機能を遂行させることを意図された命令のセットの、任意の言語、コード、または表記法における任意の表現を意味する。
【図面の簡単な説明】
【００９４】
【図１】ＨＴＴＰ ＰＯＳＴリクエスト・メッセージに含まれた従来技術のＳＯＡＰリクエスト・メッセージを示すコード・セクション表示である。
【図２】従来技術のＨＴＴＰリクエストの構造を示すコード・セクション表示である。
【図３】従来技術のＳＯＡＰメッセージの詳細構造を示すコード・セクション表示である。
【図４】ＨＴＴＰ ＰＯＳＴリクエスト・メッセージに含まれた従来技術のＳＯＡＰメッセージの全体構造を示すコード・セクション表示である。
【図５】ウェブ・サービスを記述するために使用された従来技術の例示的ＷＳＤＬドキュメントのセクションを示すコード・セクション表示である。
【図６】図５のコード・セクション表示に連続する部分である。
【図７】本発明の方法の好適な実施例による、サービス消費者、サービス供給者、およびサービス提供者の間の関係を表す概略図である。
【図８】図７に示されたシナリオで使用される主要な構成要素の概略図である。
【図９】本発明の方法の更なる好適な実施例による、サービス消費者、サービス供給者、およびサービス提供者の間の関係を表す概略図である。
【図１０】図９に示されたシナリオで使用される主要な構成要素の概略図である。
【図１１】本発明によって提供される好適な方法に従って遂行される契約選択パラメータを含むメッセージ交換における制御フローおよびそれの関連ステップを示すブロック図である。
【特許請求の範囲】
【請求項１】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスと関連した契約データを処理するための方法であって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ、ＳＳ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）サービスを要求するリクエストに含まれた前記契約データを受け取るステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記契約選択パラメータを評価するステップと、
（ｃ）前記評価および更なる選択ロジックに従って１つの特定の契約を選択するステップと、
（ｄ）前記特定の契約に従ってサービスを提供するステップと、
を含むことを特徴とする方法。
【請求項２】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスと関連した契約データを処理するための方法であって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）前記契約データを作成するステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記サービスに対するリクエストに前記契約データを含めるステップと、
（ｃ）ネットワークを介して前記サービスに対するリクエストを発生するステップと、
（ｄ）前記選択に従ってサービスを受け取るステップと、
を含むことを特徴とする方法。
【請求項３】
前記契約データが、前記契約データを含むように適応したソフトウェア・インターフェースを介して処理され、
前記ソフトウェア・インターフェースが、使用中の搬送プロトコルの定義、使用中のメッセージング・プロトコルの定義、および使用中の関連ポート・タイプに関する定義を含む、
請求項１または２に記載の方法。
【請求項４】
前記契約データがウェブ・サービス・リクエストのヘッダ・フィールド内で処理される、請求項１または２に記載の方法。
【請求項５】
前記契約データが各サービス・リクエストのエンドポイント明細の一部として処理される、請求項１または２に記載の方法。
【請求項６】
前記契約選択パラメータがＳＯＡＰ標準に適応したＳＯＡＰメッセージの形で搬送される、請求項１または２に記載の方法。
【請求項７】
複数の契約選択パラメータが単一のサービス・リクエストにおいて結合される、請求項１または２に記載の方法。
【請求項８】
前記契約選択パラメータが、特定の契約を識別するメタデータを含む、請求項１または２に記載の方法。
【請求項９】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスに関連した契約データを処理するためのサービス提供者コンピュータ・サーバ・システムであって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ、ＳＳ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）サービスを要求するリクエストに含まれた前記契約データを受け取るステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記契約選択パラメータを評価するステップと、
（ｃ）前記評価および更なる選択ロジックに従って１つの特定の契約を選択するステップと、
（ｄ）前記特定の契約に従ってサービスを提供するステップと、
を遂行するための機能的コンポーネントを含むことを特徴とするサービス提供者コンピュータ・サーバ・システム。
【請求項１０】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスに関連した契約データを処理するためのサービス要求者コンピュータ・サーバ・システムであって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）前記契約データを作成するステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記サービスに対するリクエストに前記契約データを含めるステップと、
（ｃ）ネットワークを介して前記サービスに対するリクエストを発生するステップと、
（ｄ）前記選択に従ってサービスを受け取るステップと、
を遂行するための機能的コンポーネントを含むことを特徴とするサービス要求者コンピュータ・サーバ・システム。
【請求項１１】
コンピュータ・プログラム・コード部分を含み、データ処理システムにおいて実行するためのコンピュータ・プログラムであって、前記コンピュータ・プログラム・コード部分がコンピュータにおいて実行されるとき、請求項１乃至８のいずれかに記載の方法における各ステップを遂行するためのコンピュータ・プログラム。
【請求項１２】
コンピュータ可読プログラム手段を含むコンピュータ使用可能な媒体に記憶されたコンピュータ・プログラムであって、前記コンピュータ・プログラムがコンピュータ上で実行されるとき、請求項１乃至８のいずれかに記載の方法をコンピュータに遂行させるためのコンピュータ・プログラム。
【請求項１】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスと関連した契約データを処理するための方法であって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ、ＳＳ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）サービスを要求するリクエストに含まれた前記契約データを受け取るステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記契約選択パラメータを評価するステップと、
（ｃ）前記評価および更なる選択ロジックに従って１つの特定の契約を選択するステップと、
（ｄ）前記特定の契約に従ってサービスを提供するステップと、
を含むことを特徴とする方法。
【請求項２】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスと関連した契約データを処理するための方法であって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）前記契約データを作成するステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記サービスに対するリクエストに前記契約データを含めるステップと、
（ｃ）ネットワークを介して前記サービスに対するリクエストを発生するステップと、
（ｄ）前記選択に従ってサービスを受け取るステップと、
を含むことを特徴とする方法。
【請求項３】
前記契約データが、前記契約データを含むように適応したソフトウェア・インターフェースを介して処理され、
前記ソフトウェア・インターフェースが、使用中の搬送プロトコルの定義、使用中のメッセージング・プロトコルの定義、および使用中の関連ポート・タイプに関する定義を含む、
請求項１または２に記載の方法。
【請求項４】
前記契約データがウェブ・サービス・リクエストのヘッダ・フィールド内で処理される、請求項１または２に記載の方法。
【請求項５】
前記契約データが各サービス・リクエストのエンドポイント明細の一部として処理される、請求項１または２に記載の方法。
【請求項６】
前記契約選択パラメータがＳＯＡＰ標準に適応したＳＯＡＰメッセージの形で搬送される、請求項１または２に記載の方法。
【請求項７】
複数の契約選択パラメータが単一のサービス・リクエストにおいて結合される、請求項１または２に記載の方法。
【請求項８】
前記契約選択パラメータが、特定の契約を識別するメタデータを含む、請求項１または２に記載の方法。
【請求項９】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスに関連した契約データを処理するためのサービス提供者コンピュータ・サーバ・システムであって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ、ＳＳ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）サービスを要求するリクエストに含まれた前記契約データを受け取るステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記契約選択パラメータを評価するステップと、
（ｃ）前記評価および更なる選択ロジックに従って１つの特定の契約を選択するステップと、
（ｄ）前記特定の契約に従ってサービスを提供するステップと、
を遂行するための機能的コンポーネントを含むことを特徴とするサービス提供者コンピュータ・サーバ・システム。
【請求項１０】
インフラストラクチャにおけるネットワークを介して提供されるべきサービスに関連した契約データを処理するためのサービス要求者コンピュータ・サーバ・システムであって、それぞれのサービス明細を有するサービスに対して複数のバインディング契約がサービス提供者（ＳＰ）およびサービス要求者（ＳＣ）の間に存在し、
（ａ）前記契約データを作成するステップであって、前記契約データが前記複数の契約から少なくとも１つのサービス契約を選択するための契約選択パラメータを含む、ステップと、
（ｂ）前記サービスに対するリクエストに前記契約データを含めるステップと、
（ｃ）ネットワークを介して前記サービスに対するリクエストを発生するステップと、
（ｄ）前記選択に従ってサービスを受け取るステップと、
を遂行するための機能的コンポーネントを含むことを特徴とするサービス要求者コンピュータ・サーバ・システム。
【請求項１１】
コンピュータ・プログラム・コード部分を含み、データ処理システムにおいて実行するためのコンピュータ・プログラムであって、前記コンピュータ・プログラム・コード部分がコンピュータにおいて実行されるとき、請求項１乃至８のいずれかに記載の方法における各ステップを遂行するためのコンピュータ・プログラム。
【請求項１２】
コンピュータ可読プログラム手段を含むコンピュータ使用可能な媒体に記憶されたコンピュータ・プログラムであって、前記コンピュータ・プログラムがコンピュータ上で実行されるとき、請求項１乃至８のいずれかに記載の方法をコンピュータに遂行させるためのコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２００７−５０７０２８（Ｐ２００７−５０７０２８Ａ）
【公表日】平成１９年３月２２日（２００７．３．２２）
【国際特許分類】
【出願番号】特願２００６−５２７４０５（Ｐ２００６−５２７４０５）
【出願日】平成１６年９月１６日（２００４．９．１６）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５２２００
【国際公開番号】ＷＯ２００５／０２９３７７
【国際公開日】平成１７年３月３１日（２００５．３．３１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成１９年３月２２日（２００７．３．２２）
【国際特許分類】
【出願日】平成１６年９月１６日（２００４．９．１６）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５２２００
【国際公開番号】ＷＯ２００５／０２９３７７
【国際公開日】平成１７年３月３１日（２００５．３．３１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]