(57)【要約】【課題】集約されたウェブ・サービスで使用されるソフトウェア・リソースを提供するための方法、システム、およびコンピュータ・プログラムを開示する。【解決手段】開示された技法は、動的な実行時ウェブ・サービス統合環境において、異種のアイデンティティ・システムを接合できるようにするものである。これで、集約サービスのため、ならびにそのサブ・サービスのために、認証および許可を実行することができる。一例として、ＳＯＡＰ（「Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ」）メッセージを使用して、分散サービス間でアイデンティティ情報をリレーすることが可能であり、これによってＳＯＡＰメッセージ・ヘッダに信用証明を指定し、ＳＯＡＰメッセージ本文にサービス要求を指定することができる。
2005515540.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング・ネットワークにおいて集約サービスの１つまたは複数のソフトウェア・リソースを供給する方法であって、
前記集約サービスのプロビジョニング・インターフェースを定義するステップと、
前記プロビジョニング・インターフェースをサービス記述文書内に指定するステップと、
前記サービス記述文書に従って、前記集約サービスのユーザの信用証明を取得するステップと、
前記取得した信用証明を分析するステップと、
前記分析ステップによって指示される場合に、前記ユーザが前記集約サービスを実行できるようにするステップと、
を有する方法。
【請求項２】
前記サービス記述文書をレジストリに登録するステップをさらに有する、請求項１に記載の方法。
【請求項３】
前記集約サービスの前記１つまたは複数のソフトウェア・リソースのうちの少なくとも１つのプロビジョニング・インターフェースを定義するステップと、
前記少なくとも１つのソフトウェア・リソースのそれぞれについて、前記ソフトウェア・リソースによって実行されるサービスの前記プロビジョニング・インターフェースを、前記サービス記述文書内または１つまたは複数の他のサービス記述文書内に指定するステップと、
をさらに有する、請求項２に記載の方法。
【請求項４】
前記集約サービスの前記ユーザの信用証明を取得するステップが、前記サービス記述文書あるいは前記１つまたは複数の他のサービス記述文書に従って、前記少なくとも１つのソフトウェア・リソースに関する信用証明を取得するものでもあり、また、前記分析するステップによって指示される場合に、前記少なくとも１つのソフトウェア・リソースの前記プロビジョニング・インターフェースによって表される選択されたサービスを前記ユーザが実行できるようにする、ステップをさらに有する、請求項３に記載の方法。
【請求項５】
前記ユーザの動作特有の信用証明を取得するステップをさらに有し、選択されたサービスを前記ユーザが実行できるようにするステップが、前記選択されたサービスの前記動作特有の信用証明に依存するものである、請求項４に記載の方法。
【請求項６】
前記分析するステップが、前記信用証明の（１）認証および（２）許可のうちの少なくとも１つを有する、請求項４に記載の方法。
【請求項７】
同一性識別情報が、前記集約サービスの前記ソフトウェア・リソースによって実行される分散サービス間でプログラムに基づいてリレーされる、請求項１に記載の方法。
【請求項８】
前記プログラムに基づいてリレーするステップが、メッセージを送信するステップであって、前記メッセージがそのヘッダ内に前記信用証明を、またその本文内にサービス要求を指定する、ステップを有する、請求項７に記載の方法。
【請求項９】
前記メッセージがＳＯＡＰ（「簡易オブジェクト・アクセス・プロトコル」）メッセージである、請求項８に記載の方法。
【請求項１０】
前記サービス記述文書がマークアップ言語で指定される。請求項１に記載の方法。
【請求項１１】
前記マークアップ言語がウェブ・サービス記述言語（「ＷＳＤＬ」）である、請求項１に記載の方法。
【請求項１２】
前記レジストリが、標準化されたメッセージを使用してアクセスされるネットワーク・アクセス可能レジストリである、請求項２に記載の方法。
【請求項１３】
コンピューティング・ネットワークにおいて集約サービスの１つまたは複数のソフトウェア・リソースを供給するためのシステムであって、
前記集約サービスのプロビジョニング・インターフェースを定義するための手段と、
前記プロビジョニング・インターフェースをサービス記述文書内に指定するための手段と、
前記サービス記述文書に従って、前記集約サービスのユーザの信用証明を取得するための手段と、
前記取得した信用証明を分析するための手段と、
前記分析するための手段によって指示される場合に、前記ユーザが前記集約サービスを実行できるようにするための手段と、
を有するシステム。
【請求項１４】
コンピューティング・ネットワークにおいて集約サービスの１つまたは複数のソフトウェア・リソースを供給するためのコンピュータ・プログラムであって、１つまたは複数のコンピュータ可読媒体上で実施され、
前記集約サービスのプロビジョニング・インターフェースを定義するためのコンピュータ可読プログラム・コード手段と、
前記プロビジョニング・インターフェースをサービス記述文書内に指定するためのコンピュータ可読プログラム・コード手段と、
前記サービス記述文書に従って、前記集約サービスのユーザの信用証明を取得するためのコンピュータ可読プログラム・コード手段と、
前記取得した信用証明を分析するためのコンピュータ可読プログラム・コード手段と、
前記分析するためのコンピュータ可読プログラム・コード手段によって指示される場合に、前記ユーザが前記集約サービスを実行できるようにするためのコンピュータ可読プログラム・コード手段と、
を有する、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連発明）
本発明は、「Building Distributed Software Services as Aggregations of OtherServices」という名称の米国特許：整理番号ＲＳＷ９２００１０１８９（第０９／９５５７８８号）、「Programmatic Management of Software Resources in a Content FrameworkEnvironment」という名称の米国特許：整理番号ＲＳＷ９２００１０１９０（第０９／９５６２６８号）、および「Dynamic, Real-Time Integration of Software Resources throughServices of a Content Framework」という名称の米国特許：整理番号ＲＳＷ９２００１０１４４（第０９／９５６２７６号）に関し、これらはすべて、本願譲受人であるインターナショナル・ビジネス・マシンズ・コーポレーションに譲渡され、かつ２００１年９月１９日付で出願されたものである。これらの米国特許は、本明細書では「関連発明」と呼ばれる。
【０００２】
本発明はコンピュータ・ソフトウェアに関し、より詳細には、分散コンピューティング環境において集約サービスを供給するための技法を対象とするものである。
【背景技術】
【０００３】
近年、分散コンピューティング・ネットワークおよびネットワーク・コンピューティングの人気が急激に高まりつつあるが、その大きな要因は、「ワールド・ワイド・ウェブ」（または単に「ウェブ」）として知られる公衆インターネットおよびそのサブネットを、企業や一般消費者が使用する機会が増加したことにある。企業イントラネットおよびエクストラネットなどの、他のタイプの分散コンピューティング環境の人気も高まってきている。ソリューション・プロバイダが、改良型ウェブ・ベース・コンピューティングの供給に焦点を絞るにつれて、開発されるソリューションの多くが他の分散コンピューティング環境に適合するようになっている。したがって、本明細書でインターネットおよびウェブを参照するのは例示のためであって、限定するためではない。
【０００４】
分散コンピューティングで進歩してきた領域が、いわゆる「ウェブ・サービス」イニシアティブ（主導）である。このイニシアティブは、一般に、分散コンピューティングのための「サービス指向アーキテクチャ」とも呼ばれる。ウェブ・サービスは、インターネットにおいて分散アプリケーションを統合するために急速に台頭しつつある技術である。一般に、「ウェブ・サービス」とは、ネットワーク・アクセスが可能な動作の集まりを記述したインターフェースのことである。ウェブ・サービスは、特定のタスクまたはタスク・セットを実行する。それらウェブ・サービスは、相互に動作可能な方法で１つまたは複数の他のウェブ・サービスと協働し、複雑な作業フローまたは業務トランザクションのうちのそれらウェブ・サービスの部分を実行する。たとえば、複雑な購入注文トランザクションを完了するためには、注文会社側での発注サービス（すなわち、発注ソフトウェア）と、その業務パートナのうちの１つまたは複数での注文履行サービスとの間の対話を、自動化することが必要となる場合がある。
【０００５】
業界の専門家の多くは、サービス指向のウェブ・サービス・イニシアティブが、インターネットの次の発展段階となるであろうと考えている。ウェブ・サービスを使用すると、人間の介入を必要とせずに、ソフトウェアへの分散ネットワーク・アクセスがプログラム間の動作に幅広く利用できるようになるであろう。
【０００６】
ウェブ・サービスは、一般に、モデルを使用して構成されるものであり、このモデルでは、ネットワーク・アクセス可能サービスを提供する企業がネットワーク・アクセス可能レジストリにサービスを発行し、サービスを必要とする他の企業がレジストリを照会してサービスの可用性を知ることができる。このコンピューティング・モデルの参加者は、一般に（１）サービス・プロバイダ、（２）サービス要求者、および（３）サービス・ブローカと呼ばれる。これらの参加者と、参加者間でのメッセージ交換に関係する基本的な動作とが、図１に示されている。サービス・プロバイダ１００は使用可能なサービスを有するエンティティ（事業体、団体）であり、これらのサービスが発行される（１１０）レジストリは、サービス・ブローカ１２０によって維持される。サービス要求者１５０は、サービスを必要としてサービス・ブローカのレジストリを照会する（１４０）エンティティである。レジストリを使用して所望のサービスが見つかると、サービス要求者は、サービスを使用するために見つかったサービス・プロバイダにバインドする（１３０）。これらの動作は、人間の介入なしにプログラムに基づいて発生するように設計されているため、サービス要求者は特定のサービスを探し、そのサービスを実行時に動的に使用することができる。ウェブ・サービス・モデルは、理論上はどのようなタイプのコンピューティング・アプリケーションも使用することができる。ただし、現在、レジストリからアクセスできるウェブ・サービスは、「Ｈｅｌｌｏ，  Ｗｏｒｌｄ！」デモ・プログラムなどの比較的単純なプログラム、特定の郵便番号に関して現在の気温を調べるプログラム、通貨為替計算を実行するプログラムなどに限られている。
【０００７】
ウェブ・サービス作業が構築されている標準の主なセットには、ＨＴＴＰ（「ハイパーテキスト転送プロトコル」）、ＳＯＡＰ（「簡易オブジェクト・アクセス・プロトコル」）、および／またはＸＭＬ（「拡張可能マークアップ言語」）プロトコル、ＷＳＤＬ（「ウェブ・サービス記述言語」）、およびＵＤＤＩ（「ユニバーサル記述、ディスカバリ、およびインテグレーション」）が含まれる。ＨＴＴＰは、一般に、インターネットなどのＴＣＰ／ＩＰ（「伝送制御プロトコル／インターネット・プロトコル」）ネットワークを介してメッセージを交換するために使用される。ＳＯＡＰは、分散環境でメソッドを呼び出すためのメッセージを送信する際に使用される、ＸＭＬベースのプロトコルである。ＸＭＬプロトコルは、アプリケーション層転送プロトコルに関するワールド・ワイド・ウェブ・コンソーシアム（「Ｗ３Ｃ」）の仕様を発展させたものであり、アプリケーション間のメッセージングを可能とすることになり、ＳＯＡＰと収束（ｃｏｎｖｅｒｇｅ）することができる。ＵＤＤＩは、企業が自社のサービスをリストアップする際およびサービス要求者が特定のサービスを提供している企業を見つける際に使用することができる、ＸＭＬベースのレジストリ技法である。（ＳＯＡＰについての詳細は、インターネット上のhttp://www.w3.org/TR/2000/NOTE-SOAP-20000508から入手可能な、２０００年５月８日付Ｗ３Ｃノート「Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）  １．１」を参照のこと。）ＸＭＬプロトコルおよびＸＭＬプロトコル標準の作成に関する詳細は、http://www.w3.org/2000/xpを参照されたい。ＷＳＤＬ仕様には「Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ  （ＷＳＤＬ）１．１、２００１年３月１５日付Ｗ３Ｃノート」という名称が付けられており、インターネット上のhttp://www.w3.org/TR/2001/NOTE-wsdl-20010315で見ることができる。ＵＤＤＩに関する詳細は、「ＵＤＤＩ  Ｖｅｒｓｉｏｎ  ２．０  ＡＰＩ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ、２００１年６月８日ＵＤＤＩ公開ドラフト仕様」という名称が付けられており、インターネット上のhttp://www.uddi/org/specification.htmlで見ることができる。ＨＴＴＰは、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  ＦｏｒｃｅからのＲｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ（「ＲＦＣ」）２６１６に、「Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ−−ＨＴＴＰ／１．１」（１９９９年６月）という名称で記載されている。
【０００８】
これらの公開標準を使用してアプリケーションを統合するためには、いくつかのステップが必要である。ウェブ・サービスへのインターフェースは、サービスの呼出しに使用するメソッド名、メソッドの入出力パラメータおよびそれらのデータ・タイプ、等を含めて記述しなければならない。ＷＳＤＬ文書はこの情報を提供し、また、ＵＤＤＩ発行動作を使用して、ＵＤＤＩ仕様に従って実施されるレジストリに対して伝送される。いったんＵＤＤＩレジストリにサービスが登録されると、サービス要求者はＵＤＤＩ検索要求を発行して分散サービスを見つけることができる。この方法でサービスを見つけたサービス要求者は、次にＵＤＤＩバインド要求を発行するが、これは、ＷＳＤＬ文書からのサービス情報を使用して、要求者と見つかったサービスとを動的にバインドするものである。（これらのＵＤＤＩ動作については、図１で高水準で示されている。）ＳＯＡＰ／ＸＭＬプロトコルおよびＨＴＴＰメッセージは、一般に、ＷＳＤＬ文書およびＵＤＤＩ要求を伝送するために使用される。（以下、ＳＯＡＰについての言及は、ＸＭＬプロトコルの、意味的に同じ側面について、等価的に述べているとみなすものとする。さらに、本明細書での「ＨＴＴＰ」についての言及は、一般的な意味で、ＨＴＴＰと同様の機能について述べていることを意図するものであることに留意されたい。たとえばＵＤＤＩ動作の中には、ＨＴＴＰではなくＨＴＴＰＳを必要とするものがあり、ＨＴＴＰＳはＨＴＴＰのセキュリティ強化バージョンである。しかし、これらの相違点は本発明に直接関係するものではないため、以下でＨＴＴＰについて論じる際に区別はしない。）
【０００９】
ウェブ・サービスの目的は、１つまたは複数のリモート位置に常駐することのあるプログラム・コンポーネントが、たとえ異なるオペレーティング・システム上で実行され、要求者のものとは異なるプログラミング言語で作成されている場合であっても、それらのコンポーネントへのトランスペアレントなアクセスをサービス要求者に提供することである。ウェブ・サービスの基礎となるはずのこの目的、アーキテクチャ、および標準を定義するために、莫大な作業が行われてきたが、ウェブ・サービスを効果的かつ効率的に動作させるためには、なお多くの作業が残されている。
【００１０】
具体的に言えば、従来の方法で提供された多くのアプリケーション・サービスが、それらサービスを使用する前にユーザの認証および許可を必要とすることを考えてみる。この状況で、認証とは、実際にユーザがそうであると称している人物であると特定することを意味し、許可とは通常、このユーザのアクセス権が何であるか、あるいはこのユーザに特定のサービスまたはその機能へのアクセスが許可されているかどうかを特定することを意味する。ウェブ・サービス環境では、サービス・プロバイダが動的に配置されて特定のサービスを実行できることが目的である。複数のサービス・プロバイダが利用できる場合、これらのサービス・プロバイダのうちの特定の１つを、このプロバイダ・サービスの利用価格、このプロバイダ・サービスの応答時間保証、などといった基準に基づいて選択することができる。各プロバイダが、認証および許可情報に関する異なるフォーマット、ならびに認証および許可機能にアクセスするための固有の方法を有する可能性がある。本発明者が知るところでは、ウェブ・サービス環境において異種のアイデンティティ・システムを統合またはバインドするための技法はなく、これが、集約されたウェブ・サービスの使用を大幅に妨げるものとなるであろう。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、コンピューティング・ネットワークにおいて集約サービスを供給するための、方法、システム、およびコンピュータ・プログラムを提供するものである。
【課題を解決するための手段】
【００１２】
好ましい実施形態では、１つまたは複数のソフトウェア・リソースが集約サービスを供給し、この技法が、集約サービスのプロビジョニング（需要の変化に応じて柔軟に変更対応する）・インターフェースを定義するステップ、サービス記述文書においてプロビジョニング・インターフェースを指定するステップ、サービス記述文書に従って集約サービスのユーザの信用証明を取得するステップ、取得した信用証明を分析するステップ、ならびに分析によって示された場合はユーザに集約サービスの実行を許可するステップを有する。
【００１３】
さらにこの技法は、集約サービスの１つまたは複数のソフトウェア・リソースのうちの少なくとも１つのプロビジョニング・インターフェースを定義するステップ、ならびに、少なくとも１つのソフトウェア・リソースのそれぞれについて、ソフトウェア・リソースによって実行されるサービスのプロビジョニング・インターフェースを指定するステップ、を有することができる。この場合、集約サービスのユーザの信用証明を取得することに加えて、少なくとも１つのソフトウェア・リソースについても、サービス記述文書あるいは１つまたは複数の他のサービス記述文書に従って信用証明を取得することができる。その後ユーザは、同様にこれらの信用証明の分析によって示された場合、少なくとも１つのソフトウェア・リソースのプロビジョニング・インターフェースによって表された、選択されたサービスを実行できることが望ましい。
【００１４】
好ましい実施形態では、分析が、信用証明の（１）認証と（２）許可のうちの少なくとも１つを有する。
【００１５】
したがってアイデンティティ情報は、集約サービスのソフトウェア・リソースによって実行される分散サービス間でプログラムに基づいてリレー（中継）されることが可能である。好ましくは、プログラムに基づきリレーするステップが、メッセージのヘッダ中に信用証明を、さらにメッセージの本文中にサービス要求を、指定するメッセージを送信するステップを有することが望ましい。たとえばメッセージは、ＳＯＡＰ（「簡易オブジェクト・アクセス・プロトコル」）メッセージである場合がある。
【００１６】
マークアップ言語は、サービス記述文書を指定するために使用されることが望ましい。当該マークアップ言語は、ウェブ・サービス記述言語（「ＷＳＤＬ」）であることが望ましい。
【００１７】
当該技法は、サービス記述文書をレジストリに登録するステップをさらに有することが可能であり、このレジストリは、標準化されたメッセージを使用してアクセスされるネットワーク・アクセス可能レジストリである場合がある。
【００１８】
次に、本発明の好ましい実施形態について、以下の図面を参照しながら例示の目的で説明するが、図面全体を通じて同じ参照番号は同じ要素を示す。
【発明を実施するための最良の形態】
【００１９】
ウェブ・サービスには、全く異なるアプリケーションが今までには決してなかったような相互動作を可能にする見込みがあるため、企業システムの開放性および都市化を通じて、シームレスな高度に統合されたアプリケーションの新しい風を吹き込むことになる。ウェブ・サービスは、分散ソフトウェア・リソースをより広く入手可能とするものであり、ソフトウェアをサービスとしてマーケティングできるようにするものである。１つまたは複数のサービス・プロバイダからのサービスを動的に集約することで、それぞれの特定のユーザにとって現在関心のあるタスクまたはサービス、を実行するために必要な機能が、ユーザに提供される。これらの動的に統合されたサービスを効果的に使用するためには、それらサービスが使用する可能性のある異種のアイデンティティ（同一性識別）・システムに、自動的かつ動的にバインド（参加）できることが必要である。このバインドはリアルタイムに実行されなければならず、その結果、それらサービスの使用について、ユーザ（人間またはプログラムどちらか）がシームレスに認証および許可、すなわち「識別」されることが可能となる。さらに、特定のサービス（複数のサブ・サービスからなるサービスを含む）を通じてユーザが自分自身を繰り返し識別することが必要であると、ユーザをいらいらさせることになり、また時間の浪費および非効率的であるため、このシームレスな識別は単一のサイン・オンを使用して提供することが望ましい。本発明は、以下で説明するように、これらの要件の解決策を提供し、それを実行する中で、いくつかの公開された業界標準技術を活用するものである。
【００２０】
実施形態について詳細に論じる前に、本発明の好ましい実施形態を構築する基になる技術を含む背景情報について、少し再考しておくのが良いであろう。関連発明では、ウェブ・サービスを管理するため、ならびに、サービスを集約して新しいサービスを形成し、その後それらを展開することのできる集約ポイントを提供するための、技法が定義された。関連発明の好ましい実施形態は、ポータル・プラットフォームなどのコンテンツ・フレームワークを基に構築されているが、その理由は、この種のフレームワークが、コンテンツ管理のため、ならびに持続性、個人化、およびコード変換といったサービス・ホスティングのための、多くの組込みサービスを提供するものであるためである。関連発明で開示された技法は、このプラットフォームを拡張し、ウェブ・サービスの集約、展開、および管理に備えるようにするものである。モデル化合成ツールが開示されており、これを使用して集約サービスを定義することが可能であり、その後この集約サービスの定義に従い、ソフトウェア・リソースをプログラムに基づいて統合することができる。さらにこの集約サービスを、自動化された方法で管理することができる。
【００２１】
本発明は、当該関連発明の使用の結果もたらされる集約されたサービスを提供するための技法を定義するものである。これらの技法は、本発明の範囲を逸脱することなく、他の方法で作成された集約サービスにも適合することができる。さらに留意すべきことは、本明細書の議論は「集約」サービスの提供に関するものである一方で、集約サービスそれ自身は（サブ・サービスからなる）ウェブ・サービスであり、それ故、アトミック（一微小単位の）サービスとみなすことのできるそれらのウェブ・サービスで（そして、それ故にそれらウェブ・サービスは、集約の縮退のケースであり、集約された「サブ・サービス」の組が単一のメンバを有するのだが）、本発明が有利に使用できるものであるということである。
【００２２】
本発明（ならびに関連発明）の実施形態が実施可能な市販のポータル・プラットフォームの１つが、インターナショナル・ビジネス・マシンズ・コーポレーション（「ＩＢＭ」）のＷｅｂＳｐｈｅｒｅ（Ｒ）Ｐｏｒｔａｌ  Ｓｅｒｖｅｒ（「ＷＰＳ」）である。（「ＷｅｂＳｐｈｅｒｅ」はＩＢＭの登録商標である。）しかしながら、関連発明および本発明の考察はポータル・プラットフォームに関するものであるが、その発明概念は、類似した機能を提供しかつＷＰＳ以外のポータルにも適用可能な他のタイプのコンテンツ・フレームワークに適用することができるため、ポータルおよびそれらのポートレットの実例に対する参照は例示のために過ぎず、限定的なものではない。
【００２３】
関連発明によって可能とされる動的なウェブ・サービス実行時間の統合では、新しいウェブ・サービスを集約するための合成ツールを使用することができる。システム管理者（すなわち、サービスを合成する者または他の人物）は、この合成ツールを使用して、よりきめ細かなサービスからなる新しいサービスを定義することができる。他のサービスを構築する基となるきめ細かなサービスはローカルまたはリモートに常駐することが可能であり、関連発明の技法は、それらがローカルであるかリモートであるかに関わらずトランスペアレントな方法で、それらのサービスを参照すること、およびそれらのサービスを使用することを可能にするものである。きめ細かなサービスは、スクリプト・プログラム、Ｊａｖａ（ＴＭ）クラス、ＣＯＭクラス、ＥＪＢ（「Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ」（ＴＭ））、ストアド・プロシージャ、ＩＭＳまたは他のデータベース・トランザクション、レガシー・アプリケーション、その他を含む、任意の形式のプログラミング論理を含むことができる。（「Ｊａｖａ」および「Ｅｎｔｅｒｐｒｉｓｅ  ＪａｖａＢｅａｎｓ」は、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標である。）この方法で作成されたウェブ・サービスは、その後ポータル・プラットフォームによって自動的に管理することが可能であり、関連発明に記載されているように、帰納的方法で新しいウェブ・サービスを作成する際にも使用することができる。
【００２４】
関連発明は、ポートレットをポータル・インターフェースとして活用し、さらにリモート・ポートレット・インターフェースの概念（この概念はプログラムに基づいたポートレットに適用するように拡張される）に基づいて、ソフトウェア・リソースへのアクセスを可能にするようにも構築する。この方法で機能するポートレットは「ウェブ・サービス・インターメディアリ（ｉｎｔｅｒｍｅｄｉａｙ）」または「ウェブ・サービス・プロキシ」と呼ばれることがある。すなわち、関連発明は、ポートレットが、特定のサービスを要求するアプリケーションまたはソフトウェア・リソースと、そのサービスを提供するソフトウェア・リソースとの間の仲介者として動作できるようにする。特定の機能を実行するソフトウェア・リソースは、ウェブ・サービス・プロキシと静的に（たとえば開発時に）バインドすることが可能であるか、またはウェブ・サービス・プロキシを、（たとえば、実行時に評価された基準に基づいて）動的に選択されたソフトウェア・リソースとバインドすることができる。どちらの場合も、ポートレット・プロキシは要求メッセージを受け取り、自分がバインドされているソフトウェア・リソースにそれらを転送して、当該ソフトウェア・リソースは、要求された機能を完了すると、その応答をポートレット・プロキシに戻し、その後ポートレット・プロキシが要求者に応答を転送する。
【００２５】
集約サービスを実行するために呼び出されるソフトウェア・リソースは、プログラム間の対話用に設計することができるが、代替方法として、本質的に視覚的なものとすることもできる。たとえば視覚指向のリソースを、主としてプログラム間方式で動作するウェブ・サービスの実行中に呼び出すことができる。「プログラムに基づいたポートレット」という用語は、本明細書では一般に、基礎となるソフトウェア・リソースが視覚指向コードに関係するものであろうとなかろうと、関連発明および本発明に従ったポートレット・プロキシを言い表すものとして使用される。
【００２６】
関連発明に従って、ウェブ・サービス・プロキシとして構成されたポートレットを示すブロック図が、図２に示されている。これに示されるように、ポートレット・プロキシ２４０は、展開インターフェース２１０、システム・インターフェース２２０、および機能インターフェース２３０を含む。ポートレット・プロキシは、ポータル・プラットフォームと当該機能を実行するソフトウェア・リソース２５０との間の仲介者として動作するこれらのインターフェースを使用して、ポータル・プラットフォーム２００と通信する。それぞれの機能インターフェースの細部はソフトウェア・リソース２５０によって提供されるウェブ・サービスに固有であり、関連発明の一部を形成するものではない。しかし、関連発明は、ソフトウェア・リソース２５０の機能インターフェースをポートレット・プロキシのインターフェース２３０として使用可能にする。（ＷＳＤＬ定義およびＳＯＡＰサービスを使用して機能インターフェースを現すことは、関連発明で論じられたように、展開プロセス時にＩＢＭのＷｅｂ  Ｓｅｒｖｉｃｅｓ  Ｔｏｏｌｋｉｔ、すなわち「ＷＳＴＫ」などの市販のツールを使用して実施することができる。）
【００２７】
展開インターフェースおよびシステム・インターフェースについては、関連発明に詳細に記載されている。ここでは簡単に概説しておく。関連発明の好ましい実施形態によれば、展開インターフェースおよびシステム・インターフェースは、ウェブ・サービス・プロキシとして働く各ポートレットごとについて定義される（しかし代替の実施形態では、これらインターフェースのうちの一方または他方を実施することができる）。これらの新しいインターフェースは、それぞれ、展開ポート・タイプおよびシステム・ポート・タイプと呼ばれることもある。このように、関連発明に従ったポートレットは、ソフトウェア・リソースのポータル統合とサービスの対話および管理とに必要なポート・タイプ、を含むサービス・プロバイダ・タイプを定義する。（「ポート・タイプ」とは、当分野でポートレットの動作の仕様を示すために使用される用語であり、「サービス・プロバイダ・タイプ」とは、ポート・タイプの集まりを示すために使用される用語である。）
【００２８】
展開インターフェースは、ポートレット・プロキシ（すなわち、ポートレット・プロキシによって表される集約されたウェブ・サービス）を、後続のウェブ・サービス合成動作で関連発明に従って帰納的方法で使用できるようにするものである。たとえば、ポートレット「Ａ」の展開インターフェースは、ポートレットＡが他のポートレットと集約されて新しいウェブ・サービス「Ｚ」を形成するときに使用する、ポートレットＡに関する情報を提供する。関連発明に従ってウェブ・サービスＺに関する展開インターフェースを定義することによって、その後、サービスＺが他の新しいサービスを合成するために使用されるときに、ウェブ・サービスＺに関する情報を提供することができる。
【００２９】
システム・インターフェースは、ポートレットの（すなわち、ポートレット・プロキシによって表されるウェブ・サービスの）ポータル・プラットフォームによる実行時管理に使用される。システム・インターフェースを使用することにより、ポータル・プラットフォームが、イベントのログ、課金、およびウェブ・サービスの実行に関連する他のタイプの管理動作、といった機能を実行することができる。そのために、ポータル・プラットフォームとポートレット・プロキシとの間の双方向通信が使用される。
【００３０】
図３から図５は、それぞれ、展開インターフェース仕様およびシステム・インターフェース使用を示すＷＳＤＬ文書の例である。関連発明の好ましい実施形態によれば、展開ポート・タイプおよびシステム・ポート・タイプはＷＳＤＬ文書として表された後、レジストリに登録することができる。図３のＷＳＤＬ文書３００の３１０で示されるように、展開インターフェース例は「Deployment」と命名され、「getDisplayName」および「getDisplayIcon16x16」などの動作を含む（要素３３０を参照のこと）。これらの動作を使用して、たとえばウェブ・サービスの記述名を取り出すこと、およびウェブ・サービス合成ツールのパレット上に配置するためにウェブ・サービスを表すグラフィック・イメージを取り出すことができる。ＷＳＤＬ仕様によれば、サービスと通信するために使用される入力および出力のメッセージは「<message>」エレメント３２０で指定され、これらのメッセージによって使用されるパラメータは「<part>」要素として定義される。このように、このポート・タイプに関して指定される各動作の各メッセージについて、メッセージ要素が定義される。（ＷＳＤＬ文書に関する詳細は、ＷＳＤＬ仕様を参照されたい。）
【００３１】
図４のＷＳＤＬ文書３５０は、この例では「System」と命名されたシステム・インターフェースを定義する（要素３６０を参照のこと）。この例では、２つの文字列パラメータおよび日付パラメータを有する、「Event」と命名された複合データ・タイプが定義される（要素３７０を参照のこと）。このデータ・タイプは、たとえば監査ログ・ファイルに記録されるロギング・データを交換する場合に使用することができる。「logEvent」動作も定義され（要素３９０を参照のこと）、この例では、タイプがEventであるパラメータを有する「logEventReceive」メッセージ（要素３８０を参照のこと）を使用して呼び出される一方向動作である。さらにこの例は、２つのメッセージ「reportInput」および「reportOutput」を有する「reportUsage」動作を定義する。
【００３２】
本発明の好ましい実施形態は、集約されたウェブ・サービスに関するプロビジョニング情報を含めるために、展開インターフェースを拡張することができる。別の方法では、そのために本発明の範囲を逸脱することなく、別のプロビジョニング・インターフェースを定義することができる。プロビジョニング・インターフェース仕様の例５００が、図７から図１１に示されている。本明細書で開示されるように、プロビジョニング・ポート・タイプまたはインターフェースをＷＳＤＬ文書として表すことによって、ウェブ・サービスに関するプロビジョニング情報をプログラムに基づいてレジストリに登録することが可能であり、また、プロビジョニング・インターフェースに関する情報を見つけて、実行時にプログラムに基づいてバインドすることができる。
【００３３】
プロビジョニング・インターフェースが展開インターフェースの拡張として実施される場合、特定のウェブ・サービスに関するインターフェース仕様が、展開インターフェース定義の範囲内で、その動作をプロビジョニングなportType要素内に指定することが望ましい。たとえば、図３の展開インターフェース仕様３００を、展開portType要素を含めるように拡張することができる。次に図７から図１１を簡単に参照すると、このアプローチを用いる場合に（図３の要素３２０で示された）展開仕様に定義された他のメッセージに図７から図９に示されたメッセージ仕様例を追加することが可能であり、また、図１０および図１１に示されたような追加のportType要素を、展開動作に関するportType３３０と共に指定することができる。別の方法では、特にプロビジョニングのために別のＷＳＤＬ文書を提供することが可能であり、この別の文書はそれ自身の<types>要素、<schema>要素、その他を有する。この代替では、ＷＳＤＬ文書の<definitions>要素が、図７から１１のインターフェース仕様で示されたようなプロビジョニング・メッセージおよび動作からなるものとすることが可能である。
【００３４】
ＷＳＤＬ仕様によれば、ウェブ・サービスと通信するために使用される入力および出力のメッセージは、「<message>」要素で指定され、これらのメッセージによって使用されるパラメータは「<part>」要素として定義される。したがって、このポート・タイプのために指定された各動作の各メッセージについて、メッセージ要素が定義される。（ＷＳＤＬ文書に関する詳細は、ＷＳＤＬ仕様を参照されたい。）
【００３５】
関連発明で開示されたように、好ましくは有向グラフを使用して、他のウェブ・サービス（すなわちサブ・サービス）からなる集約ウェブ・サービスの実行に関係のある動作をモデル化する。選択されたポートレット動作がグラフのノード（節点）を表し、ノードをリンクするグラフ・エッジ（辺）が、１つのサービス動作またはプロセスから別のものへの潜在的な移行を表す。これらのサービス・リンクは、１つまたは複数の移行条件によって、また適用可能であればデータ・マッピング情報によっても、制限することが可能である。この条件は、どのような条件の下で、次のリンクされたサービスを呼び出すべきかを指定するものである。これらの条件は、以前のサービス呼出しの結果を使用して決定されることが多い。データ・マッピングとは、ポートレット・ポート・タイプ間の動作をリンクする能力、および１つの動作から別の動作へデータを転送する能力のことである。たとえば、データ・マッピング情報は、１つのサービスの出力パラメータが他のサービスの入力パラメータにマッピングされていることを示すことができる。
【００３６】
好ましくは、この有向グラフのサポートのためにウェブ・サービス・フロー言語（「ＷＳＦＬ」）が活用される。具体的には、有向グラフを使用するＷＳＦＬの永続的ストレージ技法および実行時評価技法をウェブ・サービス・スタックに追加して、サービス作成者によって作成されたグラフ上で動作させることができる。ＷＳＦＬの詳細な考察については、インターネット上のhttp://www- 4.ibm.com/software/solutions/webservices/pdf/WSFL.pdfでＩＢＭから入手可能なＦ．レイマン博士による「Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｆｌｏｗ  Ｌａｎｇｕａｇｅ  （ＷＳＦＬ  １．０）」（２００１年５月）という名称のＷＳＦＬ仕様を参照すると良いが、ここではあたかも全文が記載されたかのように参照により本明細書に組み込むものとする。
【００３７】
関連発明に開示されたようなサービス集約のためのウェブ・サービスのスタック方法の例については、図６を参照されたい。好ましくは、ウェブ・サービス・スタック４００が集約サービスの定義および実行のためにＷＳＦＬサービス・フロー・サポート４１０を使用し、また好ましくは、ＵＤＤＩを使用してサービス発見４２０およびサービス発行４３０が提供される。ウェブ・サービス・スタックは、サービス記述文書をサポートするためのＷＳＤＬ層４４０も有する。ＳＯＡＰを使用してＸＭＬベース・メッセージング４５０を提供することができる。ＨＴＴＰなどのプロトコル、ファイル転送プロトコル（「ＦＴＰ」）、電子メール、メッセージ・キューイング（「ＭＱ」）、およびその他を、ネットワーク・サポート４７０のために使用することができる。関連発明で論じたように、ＷＳＤＬは、ウェブ・サービスのポート・タイプを定義するため、およびこれらのポート・タイプの動作を呼び出す方法を定義するために使用され、さらにＷＳＤＬは、ウェブ・サービスを集約するため（および、それらのインターフェースを集約するため）に使用される。実行時に、ＵＤＤＩサービス発見プロセスを使用してサービスがレジストリ内で検索され、それらの持つＷＳＤＬ定義からの情報を使用してバインドされる。その後、ＷＳＦＬは実行時にこれらの（ポート・タイプ）定義を使用して、サービスを集約する。（動作の署名は通常、１対１で突き合されないため、ＷＳＦＬ仕様に定義された「プラグ・リンク」をプロキシ・モデルで使用して、関連発明に記載されたような単純な方法でインターフェースをマッピングし、それによって動作インターフェース間の対応関係を提供する。）関連発明は、このプラグ・リンク・メカニズムを、ウェブ・サービスを実施するためのポートレット・プロキシ統合の永続的な定義として開示している。
【００３８】
ウェブ・サービスとして展開されることになるソフトウェア・リソース用のソース・コードを作成する開発者は、そのサービスによって提供されることになる認証、許可、および／または構成の方法を指定する。その後、関連発明に記載されたようにサービスを集約することが可能であり、また本発明の技法を使用して集約サービスを供給することができる。たとえば、集約サービスが人間のユーザに電子メール・サービスを供給するように設計されると想定する。ユーザの電子メール・アカウントを確立するために、サブ・サービスを提供することができる。通常は、このアカウント確立のサブ・サービスには、ユーザのフルネーム、この人物に関連する電子メール・ユーザ識別子、この人物が自分の電子メール・アカウントにアクセスする際に使用するパスワード、そしておそらくは、このユーザの電子メール・メッセージにどのくらいのストレージが割り振られるべきかといった構成情報、などの入力情報が必要となる。（記憶されたパスワードを後でユーザ識別子と組み合わせて使用すれば、このユーザが、集約された電子メール・サービスの別のサブ・サービスを使用して自分の電子メール・メッセージにアクセスするときに、この人物を認証することができる。）アカウント確立サブ・サービスへの入力として、アクセス権情報を提供することもできる。たとえばシステム管理者であるユーザに、他のユーザのストレージ・スペースの割振り追加、他のユーザの電子メール削除、その他等の動作を実行するための追加のアクセス権を与えることができる。その後ＷＳＤＬ文書を使用して、各サブ・サービスによって提供される動作と、それらの動作を呼び出すために使用されるメッセージおよびパラメータとを定義することができる。
【００３９】
関連発明で論じられたように、ＷＳＤＬ文書の作成は、人間のユーザによって、またはプログラムに基づく動作を使用して、あるいはそれらを組み合わせることによって、実行することができる。（たとえば、人間のユーザに、ポート・タイプ名、名前スペース情報の場所、その他等の情報を供給するよう求める場合もあるが、プログラムに基づく動作は、ソフトウェア・リソースの公開方法に関する<operation>および<message>要素を生成する。ＩＢＭのＷＳＴＫは、既存のソフトウェア・リソース用のＷＳＤＬをプログラムに基づいて生成する際に使用できる市販製品の一例である。「getTemp」および「setTemp」動作を有する単純な天気予報サービス用のＷＳＤＬ文書をプログラムに基づいて生成する一例を示した、インターネット上のhttp://www-106.ibm.com/developerworks/webservices/library/ws-peer4でＩＢＭが公表している、Ｇ．グラス氏の「Ｔｈｅ  Ｗｅｂ  ｓｅｒｖｉｃｅｓ  （ｒ）ｅｖｏｌｕｔｉｏｎ：Ｐａｒｔ  ４，  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ）」（２００１年２月）を参照されたい。）
【００４０】
本発明に従って動的に統合されたサービスのアイデンティティ・システムを接合させるために、各サービスのプロビジョニング・インターフェースがＷＳＤＬ文書を使用してＵＤＤＩレジストリに発行される。その後、集約を有するサブ・サービスのインターフェースから手動でまたはプログラムに基づいて選択することによって、集約サービスのプロビジョニング・インターフェースを作成することが可能であり、また、ＷＳＤＬ文書をこの新しいプロビジョニング・インターフェース用に作成し、再帰的方法で発行することができる。
【００４１】
統合された認証および許可動作は、分散サービスの発見および呼び出しの両方の動的な性格によって、さらに困難なものとなっている。本明細書に開示された技法は、ウェブ・サービスの作業フローに関連して集約サービスを供給できるようにすることでこの困難に対処するものであり、動作はＷＳＤＬ文書を使用して識別され、作業フローの定義範囲内にあるＳＯＡＰメッセージを使用して呼び出される。
【００４２】
集約サービスは、公表されたそれらの動作に十分な信用証明を有するユーザがアクセスするのを制約し、公表された許可動作を使用してこれらの信用証明を首尾よく明示することができる。さらに、集約サービスに及ぶユーザ・プロファイルの作成を可能にすること、ならびにオプションで、対応するサービス動作を使用して、これらのユーザ・プロファイルを照会、変更、および／または削除できるようにすることも有利な場合がある。
【００４３】
次に、図７から図１１に示されたメッセージおよび動作のサンプルについて説明し、これらを使用して、分散コンピューティング環境において集約サービスの供給を本発明が可能にする方法を例示する。（当業者の一人であれば明らかなように、図７から図１１に示されたメッセージおよび動作ならびにそのパラメータは、例示のためにのみ示されたものである。実際のプロビジョニング・インターフェースは、本発明の範囲を逸脱することなく、他のメッセージおよび動作を含むことができる。）
【００４４】
「InResolveProvisioningIDRequest」メッセージ５０２は、特定の認証済みユーザまたはエンティティが誰であるか、を見るためのサービスを照会する際に使用することのできる、入力要求メッセージを示すものである。（以下、特に認められない限り、「ユーザ」という用語は、人間のユーザ、または自動化サービスなどのプログラムに基づいたエンティティに対して、等価に適用されるものと解釈することができる。）メッセージ仕様５０２は、この要求が文字列タイプである「authToken」と命名されたパラメータを取ることを宣言するものである。たとえば、ある人間のユーザが集約サービスに認証されており、当該集約サービスがその人間のユーザに関する認証トークン「Ｘ」を保持しているものと想定する。さらに、集約サービスが、この人間のユーザを特定のサブ・サービス「ServiceABC」に認識させる方法をプログラムに基づいて決定しようとしていると想定する。集約サービスは、そのユーザに関する情報を有するプロビジョニング・システムを見つける必要がある。メッセージ５０２および５０４を使用してこの機能を提供することが可能であり、トークン「Ｘ」が「ServiceABC」の「ResolveProvisioningID」動作に渡される（好ましくはＳＯＡＰメッセージを使用するが、これについては図１３および図１４を参照しながら説明する）。図１０に示されるように、「ResolveProvisioningID」５５２は、「InResolveProvisioningIDRequest」メッセージ（図７の要素５０２を参照）ならびに「OutResolveProvisioningIDResponse」（図７の要素５０４を参照）メッセージを有する動作である。「OutResolveProvisioningIDResponse」メッセージ５０４は、（文字列タイプの）「Identifier」と命名されたパラメータを戻すように定義される。好ましくは、戻される識別子はリモート・プロビジョニング・システムの識別子である。次にこの識別子を後続動作用の入力パラメータとして使用して（たとえば、以下で説明するメッセージ５０６、５１０、および５２６を参照）、場合に応じて、ユーザ・プロファイルまたはサービス構成情報を管理しているプロビジョニング・システムを指定することができる。
【００４５】
次に図１３および図１４を参照すると、本発明の好ましい実施形態が、ウェブ・サービス間の通信用にＳＯＡＰメッセージを使用している。ＳＯＡＰメッセージ７００の例は、従来技術に従ってヘッダにデジタル署名が記載されたＳＯＡＰエンベロープを有する。ヘッダ７１０およびデジタル署名７２０については、図１３を参照されたい。デジタル署名は、ＳＯＡＰメッセージ本文に記載されたサービス要求を提示する要求者の認証を行うのに使用することができる。メッセージ本文７３０および要求７４０については、図１４を参照されたい。このメッセージ例７００では、子要素<m:symbol>が値「IBM」を有するような「GetLastTradePrice」メッセージをメッセージ本体が指定する。これが株式相場サービスの呼出しであること、およびこのサービスがユーザの認証を必要とすることが推定できるため、ユーザのデジタル署名がＳＯＡＰヘッダに記載されている。（この方法でＳＯＡＰメッセージを使用することについての詳細は、インターネット上のhttp://www.w3.org/TR/SOAP-dsig/で見つけることのできる、「ＳＯＡＰ  Ｓｅｃｕｒｉｔｙ  Ｅｘｔｅｎｓｉｏｎｓ：Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅ（ＳＯＡＰセキュリティ拡張：デジタル署名）、２００１年２月６日付Ｗ３Ｃノート」を参照されたい。）
【００４６】
本実施形態は、集約されたウェブ・サービスのユーザを認証すること、それらユーザの許可を決定すること、および／または集約されたウェブ・サービスを構成すること、に関係する認証情報を伝達するために、このデジタル署名技法を活用するものである。
【００４７】
図７のプロビジョニング・インターフェース・メッセージの例についての考察に戻ると、「InResolveUsersRequest」メッセージ５０６は、特定サービスへのアクセスを許可されたユーザのセットを決定するために使用可能な入力要求メッセージを示す。この例では、照会されているサービスに認証トークンが渡され、好ましくは、このメッセージで情報要求者（すなわち、許可されたユーザ情報を要求している、プログラムに基づいたエンティティまたは人間のユーザ）を認証する働きをする。「provID」パラメータを使用して、サービス・プロバイダによって提供されているプロビジョニング・システムのアドレス（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ、すなわち「ＵＲＩ」のような）を提供することができる。サービスの「ResolveUsers」動作（図１０の要素５５４を参照のこと）が「InResolveUsersRequest」メッセージ５０６を受け取り、「OutResolveUsersResponse」メッセージ５０８で応答する。この例では、この出力メッセージ５０８は「UserSet」と命名された配列を戻すときに定義される。メッセージ５０８の部分要素内にある構文「SOAP-ENC」は名前空間の接頭辞（プリフィックス）であり、配列の定義を修飾するために使用される。（この出力配列は、おそらく、ＵＤＤＩを使用してバインドされ、また、ＳＯＡＰメッセージを使用して呼び出された、この「ResolveUsers」動作５５４を提供している特定サービス、が許可されたユーザを識別するものである。「ResolveUsers」動作が実行された場合、許可されたユーザを決定するようにプロビジョニング・システムに対して要求した可能性がある。）
【００４８】
「InCreateUserProfileRequest」メッセージ５１０は、ユーザ・プロファイルを作成する入力要求メッセージのインターフェースがどのように設計できるかを示す。他のメッセージ例の場合と同様に、リモート・サービスに渡された入力パラメータのうちの１つとして認証トークンを含めることが有益であるため、リモート・サービスは、情報要求者を認証することができ、また、この要求者は「InCreateUserProfileRequest」メッセージ５１０を公表する「CreateUserProfile」５５６サービスを使用するように許可されているのかどうかを判別することが可能である。「provID」パラメータを使用して、前述のように、ユーザのプロファイルがこのプロビジョニング・システムで格納されることになっている、ＵＲＩまたはプロビジョニング・システムの他のアドレスを提供することができる。好ましくは「userID」パラメータが、プロファイル作成の対象となっているユーザ（人間のユーザまたはプログラムに基づいたユーザ）を識別する。「password」パラメータを提供して、このユーザに関連するパスワードを確立することができる。（所望であれば、パスワード以外の信用証明をこの目的に使用することができる。）基礎となるサービスの必要性に応じて、ユーザのフルネームを「FullName」パラメータで渡すことができる。最後にこのメッセージ例では、ユーザのアクセス権が配列として提供される。「CreateUserProfile」動作５５６が「InCreateUserProfileRequest」メッセージ５１０を受け取り、「OutCreateUserProfileResponse」メッセージ５１２で応答する。この例では、この出力メッセージ５１２が、プロファイル作成が成功したか否かを示すブール代数値を戻す。
【００４９】
「InQueryUserProfileRequest」メッセージ５１４は、以前に格納したユーザ・プロファイルから情報を取り出すために使用される入力要求メッセージ用インターフェースの例を示す。メッセージ・パラメータは、情報要求者を認証するための認証トークン「authToken」と、プロファイルが格納されたプロビジョニング・システムを識別するためのプロビジョニング識別子「provID」と、プロファイル情報の要求元となっているユーザを識別するためのユーザ識別子「userID」とを含む。このメッセージ５１４が、入力インターフェースとして「QueryUserProfile」５５８サービスに提供され、この例の「OutQueryUserProfileResponse」メッセージ５１６が、ユーザのパスワード、フルネーム、およびアクセス権を、格納されたプロファイルから戻す。
【００５０】
「InUpdateUserProfileRequest」メッセージ５１８は「inCreateUserProfileRequest」メッセージ５１０に類似しており、この例では同じパラメータを使用する。「UpdateUserProfile」動作５６０は「InUpdateUserProfileRequest」メッセージ５１８を受け取り、「OutCreateUserProfileResponse」５１２に類似した「OutUpdateUserProfileResponse」メッセージ５２０で応答する。この例では、この出力メッセージ５１２が、プロファイル作成が成功したか否かを示すブール代数値を戻す。
【００５１】
「InDeleteUserProfileRequest」メッセージ５２２および「OutDeleteUserProfileResponse」メッセージ５２４が、「DeleteUserProfile」動作５６２の入力および出力インターフェースとして提供され（図１１を参照のこと）、「CreateUserProfile」動作５５６および「UpdateUserProfile」動作５６０でプロファイルを作成または更新することができるのと同様の方法で、ユーザのプロファイルを削除することができる。
【００５２】
これまでに説明したような認証および許可メッセージに加えて、集約されたウェブ・サービスの構成に関連するメッセージおよび動作を定義することも有用である。「SetConfigParameter」５６４および「GetConfigParameter」５６６の動作例が図１１に示されている。
【００５３】
「SetConfigParameter」５６４動作に関する入力メッセージの例が「InSetConfigParameterRequest」５２６であり、出力メッセージの例が「OutSetConfigParameterRequest」５２８である。この例の入力メッセージ５２６は、要求者に関する認証トークン「authToken」と、パラメータ値を格納すべきプロビジョニング・システムを識別するためのプロビジョニング識別子「provID」と、このパラメータを関連付けるべきユーザを識別するためのユーザ識別子「userID」と、構成パラメータの名前「parameterName」および値「parameterValue」と、を含む入力パラメータを有する。出力メッセージ５２８は、「SetConfigParameter」動作が成功したかどうかを示すブール代数値「result」を戻す。
【００５４】
「GetConfigParameter」５６６動作に関する入力メッセージの例が「InGetConfigParameterRequest」５３０であり、出力メッセージの例が「OutGetConfigParameterRequest」５３２である。この例の入力メッセージ５３０は、「parameterValue」パラメータが省略されている点を除いて「InSetConfigParameterRequest」メッセージ５２６のそれと同一の入力パラメータを有する。出力メッセージ５３２は、「parameterValue」パラメータを使用して、要求されたパラメータの値を戻す。
【００５５】
次に図１２を見ると、本発明の好ましい実施形態に従って、集約サービスと、ウェブ・サービスの作業フローに関連したそのサブ・サービスのアイデンティティおよび／または構成動作と、を実行するために使用可能な論理が示されている。
【００５６】
本発明に従って、集約サービスに「統合ログイン」またはシングル・サインオン機能を提供することが可能であり、これにより、集約サービスのプロビジョニング・インターフェースを使用して、集約サービス実行の最初にすべての必要な情報をユーザに請求することができる。（実行中に何らかの情報をユーザに要求する必要が生じることがあり、本発明がこうした要求を最小限に抑えられるものとみなされることは明らかであろう。）
【００５７】
集約サービスのＷＳＦＬ作業フローにおいて順番に定義された動作は、当該作業フロー定義に従って実行される。ユーザから取得されたログイン情報は、好ましくは、ログイン情報の個々の要素が関連するサブ・サービスによる使用のために「スタック」される。モジュールのスタッキングは、当分野では、シングル・サインオン機能を提供するアイデンティティ・システムおよび認証システムに精通した人々に知られている。スタッキングとは、暗号化鍵として「１次」パスワードを使用し、このようにして暗号化された情報が１つまたは複数の「２次」パスワードを有することである。スタッキング・プロセスが本発明で使用される場合、２次パスワードとはサブ・サービス用に使用されるパスワードであり、１次パスワードは集約サービスの範囲に適用されてこれら２次パスワードを保護する。ＷＳＦＬ定義に従って指定された順序でサブ・サービスが呼び出され、その後スタックされたパスワードがスタック解除されて、適切な認証または許可サブ・サービスに提示される。
【００５８】
このプロセスは図１２のブロック６００で開始され、ユーザ識別子およびパスワード（または同様のタイプの認証入力）が取得される。（本明細書で言及される「パスワード」とは、サポート可能な信用証明のタイプを限定することを意味するものではない。信用証明は、平文や、暗号化された文字列や、チケットや、およびＸ．５０９証明書などの公開鍵セキュリティ証明書、を含む多くの方法で提供することができる。）この認証情報を入力としてリモート・サービスに渡すことが可能であり、このサービスが認証動作を呼び出すと認証トークンを生成することになる（ブロック６１０）。
【００５９】
好ましくは、ブロック６１０で生成される認証トークンがＸＭＬフラグメントとして生成され、その後ＳＯＡＰメッセージ・ヘッダに含めることができる。この方法では、ウェブ・サービスにアクセスしたときにユーザ・アイデンティティがリレーされるようにすることができる。図１３および図１４のサンプルＳＯＡＰメッセージ７００の考察を参照すると、ＸＭＬ構文を使用してデジタル署名をＳＯＡＰヘッダに含める方法が示されている。（ここで示されるように、デジタル署名トークンは修飾された名前スペースを使用するため、先頭に文字「ｄｓ」が付く。）同様に、ＳＯＡＰヘッダを使用して、認証システムおよびポリシー・システムをサービス動作にバインドすることができる。好ましくは、ＷＳＤＬ記述が、ＳＯＡＰヘッダと本文との組合せとして動作をモデル化することができる。すなわち、アイデンティティの証明を必要とするすべての動作が、ユーザ信用証明の交換を必要とする。本明細書の例で使用されるＳＯＡＰセキュリティ拡張技法は、これがどのように達成できるかの一例である。Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（「ＳＡＭＬ」）、Ｇｅｎｅｒｉｃ  Ｓｅｃｕｒｉｔｙ  Ｓｅｒｖｉｃｅ（「ＧＳＳ」）ＡＰＩ、およびＣｏｍｍｏｎ  Ｓｅｃｕｒｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ（「ＣＳＩ」）アーキテクチャも、プリンシパルの信用証明の交換におけるセキュリティのための手段を提供するものである。（ＳＡＭＬのバージョンは、インターネット上のhttp://www.oasis-open.org/committees/security/docs/draft-sstc-saml-spec-00.PDFで見つけることのできる２００１年４月１１日付のＯＡＳＩＳドラフトに定義されている。ＧＳＳ−ＡＰＩは、２０００年１月付のＲＦＣ  ２７４３「Ｇｅｎｅｒｉｃ  Ｓｅｃｕｒｉｔｙ  Ｓｅｒｖｉｃｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ，  Ｖｅｒｓｉｏｎ  ２，  Ｕｐｄａｔｅ  １」に定義されている。ＣＳＩは、インターネット上のhttp://www.omg.org/cgi-bin/doc?ptc/2001-03-02で入手可能な「Ｃｏｍｍｏｎ  Ｓｅｃｕｒｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  Ｖ２  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」に定義されている。）
【００６０】
ブロック６００で取得された入力情報を使用してブロック６１０で生成されるトークンは、好ましくは集約サービスの様々なサブ・サービスに対してその後ユーザを識別させるのに使用することのできる、このユーザの代理として働くという点で、本明細書では「一般」認証トークンと呼ばれる。（言い換えれば、このトークンはどのような１つのサブ・サービスまたは動作に特有なものでもないことが望ましい。）
【００６１】
ブロック６２０のテストは、このユーザが（依然として）グローバルに（すなわち、集約サービスに関して）認証されているかどうかをチェックするものである。好ましい実施形態では、いったんユーザが認証されると、その人の信用証明が残りのフローに関する要求（すなわち、集約サービスに従った呼出し）に関連付けられる。しかし、図１２の論理は、たとえばフロー・モデルに指定された動作シーケンス中にログ・オフする可能性のあるユーザを反映するために、ブロック６２０でテストを複数回実行するように設計されている。テストの結果が否定的である場合、このユーザは集約サービスの操作を続行することができず、好ましくは障害コードが戻された（ブロック６４０）後、図１２のプロセスが終了する。テストの結果が肯定的である場合、プロセスはブロック６３０で続行され、（すなわち、ＷＳＦＬフロー・モデルに従って決定される、次に実行されることになるサービスについて）このユーザが確実にローカルであるかどうかがテストされる。このテストの結果が否定的である場合、制御はブロック６４０に移り、そうでない場合、制御はブロック６７０に移る。
【００６２】
ブロック６２５では、次に実行されることになる動作に関するスタックされたアイデンティティ情報が取り出される。この取り出された情報がこの次の動作の認証サービスに渡され、このサービスがこのアイデンティティ情報を使用して動作特有のトークンを生成する（または取り出す）。
【００６３】
ブロック６６０では、動作特有のトークンが、（図１３および図１４を参照しながら述べたように）ＳＯＡＰヘッダを使用して呼出し側に戻される。（図７から図９の応答メッセージには認証トークンを戻すことが示されていないが、所望であればこうしたトークンを追加することができることに留意されたい。）次にブロック６７０は、受け取った動作特有のトークンを使用して、ユーザの動作特有の許可を決定する。（ユーザは、特定クラスの動作に関する信用証明を決定するいくつかの役割を有することができる。一例として、マネージャである人物が、マネージャとしての自分の役割を果たしているときには自分の従業員の人事記録を閲覧することができるが、従業員としての自分の役割を果たしているときには、自分自身の人事記録を見るために同じ操作を使用することはできないものとすることがある。）ブロック６７０の許可呼出しは、好ましくは、ブロック６６０で受け取った動作特有のトークンを渡すためにＳＯＡＰヘッダも使用する。許可動作の結果が、集約サービスで次に実行されることになる動作についてユーザが許可されていることを示す場合、処理はブロック６８０に進む。（そうでない場合、エラーが生成されること、および／またはフローが異なる動作に進むことがある。特定の処理は実施によって異なることがあるため、図１２には示されていない。通常の当業者の１人であれば、どのようにして図１２に適切な論理を追加できるかが明らかになろう。）
【００６４】
ブロック６８０は、シーケンスの次の動作を呼び出す。この呼出しも、ユーザの信用証明が必要であれば、ブロック６６０で受け取った動作特有のトークンを渡すためにＳＯＡＰヘッダを使用することができる。（許可トークンがブロック６７０の処理の結果として受け取られる場合、ブロック６５０からのトークンに加えて、あるいはこのトークンの代わりに、その許可トークンを渡すことができる。）当該動作が完了した後、ブロック６９０が、このシーケンスにその他の動作があるかどうかをチェックする。動作がなければ、図１２の処理は終了する。そうでなければ、制御がブロック６２０に戻り、依然として集約サービスについてユーザが認証されているかどうかを判別する（上記で論じたように、その後、ブロック６３０で、次のサービスについてユーザが認証されているかどうかを判別することになる）。
【００６５】
これまで例証してきたように、本発明は、集約されたウェブ・サービスを提供するための有利な技法を提供するものである。好ましくは、ＳＯＡＰヘッダを使用してアイデンティティ情報がリレーされる。開示された技法は、ウェブ・サービスの動的な実行時統合環境において、異種のアイデンティティ・システムを接合できるようにするものである。公開標準が活用される。好ましい実施形態について説明する際に、特定の標準（ＷＳＦＬおよびＳＯＡＰなど）について参照してきたが、これは本発明の発明上の概念を例示するためのものである。本発明の範囲を逸脱することなく、類似の機能を提供するための代替手段を使用することができる。
【００６６】
当業者の１人であれば理解することになるように、本発明の実施形態は、方法、システム、またはコンピュータ・プログラムとして提供することができる。したがって本発明は、全体としてハードウェアの実施形態、全体としてソフトウェアの実施形態、または、ソフトウェア面とハードウェア面を組み合わせた実施形態の形を取ることができる。さらに本発明は、そこで実施されるコンピュータ使用可能プログラム・コードを有する、１つまたは複数のコンピュータ使用可能記憶媒体（ディスク・ストレージ、ＣＤ−ＲＯＭ、光ストレージ、およびその他を含むが、これらに限定されることはない）上で実施される、コンピュータ・プログラムの形を取ることができる。
【００６７】
以上、本発明について、本発明の実施形態に従った方法、装置（システム）、およびコンピュータ・プログラムの、フロー図および／またはブロック図を参照しながら説明してきた。フロー図および／またはブロック図のそれぞれのフローおよび／またはブロック、ならびに、フロー図および／またはブロック図中のフローおよび／またはブロックの組み合わせは、コンピュータ・プログラム命令によって実施することができる。マシンを製造するためにこれらのコンピュータ・プログラム命令を、汎用コンピュータ、特殊用途向けコンピュータ、埋め込み型プロセッサ、または他のプログラム可能データ処理装置のプロセッサに提供し、その結果、当該コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行される当該命令が、フロー図の１つまたは複数のフロー、および／またはブロック図の１つまたは複数のブロック、において、指定された機能を実施するための手段を作成することになる。
【００６８】
コンピュータまたは他のプログラム可能データ処理装置に対して特定の方法で機能するように指示することの可能なこれらのコンピュータ・プログラム命令を、コンピュータ読取り可能メモリに格納することも可能であり、その結果、コンピュータ読取り可能メモリに格納された命令が、フロー図の１つまたは複数のフロー、および／またはブロック図の１つまたは複数のブロック、において指定された機能を実施する命令手段を含む製品を形成することになる。
【００６９】
コンピュータ・プログラム命令を、コンピュータまたは他のプログラム可能データ処理装置上にロードし、コンピュータまたは他のプログラム可能装置上で一連の動作ステップを実行させてコンピュータ実施プロセスを生成することも可能であり、その結果、コンピュータまたは他のプログラム可能装置上で実行する命令が、フロー図の１つまたは複数のフロー、および／またはブロック図の１つまたは複数のブロックにおいて、指定された機能を実施するためのステップを提供することになる。
【００７０】
以上、本発明の好ましい実施形態について説明してきたが、いったん当業者が基本的な発明の概念を習得すれば、これらの実施形態における追加の変形および修正が可能であろう。したがって、添付の特許請求の範囲は、好ましい実施形態と、本発明の範囲内にあるすべてのこうした変形および修正との両方を含むものと解釈されるものとする。
【図面の簡単な説明】
【００７１】
【図１】従来技術に従ってサービス指向アーキテクチャの参加者および基本的動作を示す図である。
【図２】関連発明の好ましい実施形態に従ってウェブ・サービス・プロキシとして構成されたポートレットを示すブロック図である。
【図３】関連発明の好ましい実施形態に従って展開インターフェースを指定する、サンプルＷＳＤＬ文書のコンテンツを示す図である。
【図４】関連発明の好ましい実施形態に従ってシステム・インターフェースを指定する、サンプルＷＳＤＬ文書のコンテンツを示す図である。
【図５】関連発明の好ましい実施形態に従ってシステム・インターフェースを指定する、サンプルＷＳＤＬ文書のコンテンツを示す図である。
【図６】関連発明に開示された、サービス集約のためのウェブ・サービスのスタック方式を示す図である。
【図７】本発明の好ましい実施形態に従ってプロビジョニング・サービス・インターフェースを記述する、ＷＳＤＬ文書の断片を示す図である。
【図８】本発明の好ましい実施形態に従ってプロビジョニング・サービス・インターフェースを記述する、ＷＳＤＬ文書の断片を示す図である。
【図９】本発明の好ましい実施形態に従ってプロビジョニング・サービス・インターフェースを記述する、ＷＳＤＬ文書の断片を示す図である。
【図１０】本発明の好ましい実施形態に従ってプロビジョニング・サービス・インターフェースを記述する、ＷＳＤＬ文書の断片を示す図である。
【図１１】本発明の好ましい実施形態に従ってプロビジョニング・サービス・インターフェースを記述する、ＷＳＤＬ文書の断片を示す図である。
【図１２】本発明の好ましい実施形態を実施するために使用可能な論理を示すフロー図である。
【図１３】従来技術に従ってヘッダにデジタル署名が記載された、ＳＯＡＰエンベロープの例を示す図である。
【図１４】従来技術に従ってヘッダにデジタル署名が記載された、ＳＯＡＰエンベロープの例を示す図である。
【符号の説明】
【００７２】
１００  サービス・プロバイダ
１２０  サービス・ブローカ
１５０  サービス要求者
２００  ポータル・プラットフォーム
２１０  展開インターフェース
２２０  システム・インターフェース
２３０  機能インターフェース
２４０  ポートレット・プロキシ
２５０  ソフトウェア・リソース
４００  ウェブ・サービス・スタック
４１０  サービス・フロー
４２０  サービス発見
４３０  サービス発行
４４０  サービス記述
４５０  ＸＭＬベースのメッセージング
４７０  ネットワーク・サポート
【図１】
2005515540.tif 000003
【図２】
2005515540.tif 000004
【図３】
2005515540.tif 000005
【図４】
2005515540.tif 000006
【図５】
2005515540.tif 000007
【図６】
2005515540.tif 000008
【図７】
2005515540.tif 000009
【図８】
2005515540.tif 000010
【図９】
2005515540.tif 000011
【図１０】
2005515540.tif 000012
【図１１】
2005515540.tif 000013
【図１２】
2005515540.tif 000014
【図１３】
2005515540.tif 000015
【図１４】
2005515540.tif 000016
【国際調査報告】
2005515540.tif 000017
2005515540.tif 000018
2005515540.tif 000019