JP2010507158A

JP2010507158A - ウェブ・サービス環境における同期化ポリシー制御のための方法およびシステム

Info

Publication number: JP2010507158A
Application number: JP2009532806A
Authority: JP
Inventors: ヒントン、ヘザー、マリア; ミルマン、アイヴァン、マシュー
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2006-10-19
Filing date: 2007-10-18
Publication date: 2010-03-04
Anticipated expiration: 2027-10-18
Also published as: CN101523403A; WO2008046888A2; KR20090069280A; US20080098453A1; CN101523403B; US8291466B2; WO2008046888A3; JP5043950B2

Abstract

【課題】ウェブ・サービス環境における同期化ポリシー制御のための方法を提供する。
【解決手段】階層リソース・スペース内のウェブ・サービス・リソース・オブジェクトに関するポリシー制御は疎に結合されるため、ポリシー変更はオブジェクト全体にわたって適用および実施される。この技法により、異なるポリシーが非意図的に同じリソースに適用されない（たとえば、一方がウェブ・サービス・エントリ・レベルにあり、他方がリソース・レベルにある）ことが保証される。前述のようにオブジェクトを同期化することによって、アプリケーションを展開するエンティティとセキュリティ管理者とのいずれも、ウェブ・サービス環境内で発生する様々なタイプの要求間の相違を認識する必要がない。代表的な実施形態では、リソース・オブジェクトは、同期化ポリシー制御を提供するために階層リソース・スペース内でリンクされ、ここでポリシーは、監査ポリシー、サービス品質（ＱｏＳ）ポリシー、サービス内容合意書（ＳＬＡ）ポリシー、ガバナンス・ポリシー、コンプライアンス・ポリシー、パッチ管理／脆弱性管理ポリシー、ユーザ管理ポリシー、または権利管理ポリシーである。
【選択図】図６

Description

本発明は、一般に、ウェブ・サービスに基づくアクセスおよび他のポリシー制御に関する。

ウェブ・サービスとは、公衆インターフェースおよびバインディング（binding）がＸＭＬで定義および記述された、ＵＲＩによって識別されるソフトウェア・システムである。その定義は、他のソフトウェア・システムによって発見可能である。その後これらのシステムは、ウェブ・サービス定義によって規定された様式で、インターネット・プロトコルによって伝達されるＸＭＬに基づくメッセージを使用して、ウェブ・サービスと対話することができる。

通常、ウェブ・サービスは、そのサービス記述と呼ばれる標準の形式ＸＭＬ概念（notion）を使用して記述される。サービス記述は、通常、ウェブ・サービス記述言語（すなわちＷＳＤＬ）などのマシン処理可能なフォーマットに準拠する。ＷＳＤＬは、演算、転送プロトコル、およびロケーションを詳述する、メッセージ・フォーマットを含む、サービスと対話するために必要な公衆インターフェースを記述する。サポートされる演算およびメッセージは抽象的に記述され、具体的なネットワーク・プロトコルおよびメッセージ・フォーマットと結び付けられる。ウェブ・サービスに接続されたクライアント・プログラムは、ＷＳＤＬを読み取って、サーバ上で使用可能な機能を決定する。ウェブ・サービスを実行中のコンピューティング・エンティティは、所与の転送プロトコルを介したＸＭＬに基づくメッセージングを使用して、互いに通信する。メッセージは、通常、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）に準拠し、ＨＴＴＰを介して（公衆インターネットを介して）、または他の信頼できる転送機構（エンタープライズ・イントラネットを介した転送のための、ＩＢＭ（Ｒ）ＭＱＳｅｒｉｅｓ（Ｒ）技術およびＣＯＲＢＡなど）を介して、移動する。ウェブ・サービスは、サービスのインプリメンテーションの細部を隠すことで、それがインプリメンテーションされるハードウェアまたはソフトウェアとは無関係に、および、それが書き込まれるプログラミング言語とは無関係に、使用することが可能となる。これにより、ウェブ・サービスに基づくアプリケーションを、疎結合された（loosely-coupled）、コンポーネント指向の、相互技術のインプリメンテーションとすることが可能となり、かつ奨励される。ウェブ・サービスは、通常、特定のタスクまたはタスクのセットを履行する。それらを単独で、または他のウェブ・サービスと共に使用し、複雑な集約またはビジネス・トランザクションを実施することができる。ウェブ・サービスに接続されたクライアント・プログラムは、ＷＳＤＬを読み取って、サーバ上で使用可能な機能を決定する。

ウェブ・サービスの出現に伴い、コンピューティング・リソースは、インプリメンテーション中立的に露出される。たとえばエンタープライズＪａｖａＢｅａｎ、すなわち「ＥＪＢ」などの、再使用可能コード・コンポーネントについて考えてみる。通常、ＥＪＢは、メソッド呼び出し時のアクセス制御決定によって保護されている。しかしながら、ウェブ・サービスのように露出される場合、ＥＪＢはウェブ・サービスの名前、ポート、および動作によって定義され、動作は通常メソッドを表す。ウェブ・サービスが記述される（すなわち、ＷＳＤＬによって）方法により、この「動作」は、Ｃベース・リソース、ＣＩＣＳベース・リソースなどによって提供される同じ機能にも対応することができる。これは、言い換えれば、所与の機能が（ＥＪＢ、Ｃベース・リソース、ＣＩＣＳベース・リソース、またはその他のいずれでインプリメントされていようとも）単一のＷＳＤＬによって記述可能であるということである。リソース全体は抽象ＷＳＤＬによって記述され、各特定のインプリメンテーションはそのＷＳＤＬの具体的な結合によって記述される。

ＷＳＤＬのレベルで所与のリソースに（アクセス制御リスト、すなわちＡＣＬなどの）アクセス制御ポリシーを適用できること、すなわち、そのバック・エンド・インプリメンテーションに関係なく、同じアクセス制御ポリシーがリソースに適用されることが、知られている。こうしたポリシーは、通常、保護オブジェクト・スペースと呼ばれる仮想表現との関連において、リソースに適用される。保護オブジェクト・スペースとは、ドメインに属するリソースの論理および階層描写（portrayal）である。ＷＳＤＬレベルでのセキュリティ・ポリシーの適用は、アクセス制御に対する「最良の実施」手法と一致し、アクセス制御決定はできる限り「縁部」近くで実行されることが好ましい。しかしながら、この技法は、ウェブ・サービスを提供するエンティティが、２つの場所で、すなわち、ウェブ・サービス・エントリでの動作レベル決定と、アプリケーション・レベルでのメソッド・レベル決定とで実施される、同じ許可決定を有するという可能性を生じさせる。これにより、同じリソースに適用される２つの異なるアクセス・ポリシーが、一方のポリシーはウェブ・サービス／動作レベルで適用され、他方のポリシーはアプリケーション／ＥＪＢレベルで適用されるという可能性が生じる。したがって現時点では、潜在的な競合を避けるために、セキュリティ管理者がアクセス制御ポリシーを手動で追跡および管理しなければならない。

セキュリティに無関係な状況において、ならびに具体的には、所与のトランザクションがリソース・セットで複数の「接触」ポイントを有する（たとえば、ウェブ・サーバ、ウェブ・サービス、ウェブ・アプリケーション、ＭＱキューなど）場合、および、それらリソースのそれぞれが異なるエンティティによって構成および管理されるポリシー（たとえば監査ポリシー）を有する場合、ウェブ・サービス環境全体にわたって、同様の動作制約が存在する。

アクセス制御環境の場合と同様に、個々のポリシーは手動で追跡および管理され、それらはしばしば一貫性がない。

例示的実施形態では、ウェブ・サービス環境における同期化ポリシー制御の方法には、トランザクション・リソース・セットについて階層リソース・スペースを生成するステップが含まれる。その後、階層リソース・スペース内の対応する要素間に、（たとえば視覚マッピング・ツールを使用して）１つまたは複数の疎結合のセットが定義される。これらの結合によって、マッピング規則のセットが定義される。マッピング規則は、階層リソース・スペース内の１つのオブジェクトにおける要素に対する変更が、階層リソース・スペース内の１つまたは複数の他のオブジェクトにおける要素に、影響を与えるかどうか、およびどのように影響を与えるかを、定義する。ランタイム時には、ポリシー管理ツールが監視される。リソース・スペース・オブジェクトの１つにおける要素に対してポリシー変更（たとえば更新）が発生した場合、この変更はマッピング規則に反して解析される。解析の結果として、所与のマッピング規則が関係する（implicate）場合、この変更は、他のリソース・スペース・オブジェクト内の対応する要素に適用される。変更は、一方向、または双方向（すなわち、制御変更が双方向に伝播される）とすることができる。

ポリシー制御は、監査ポリシー、サービス品質ポリシー、サービス内容合意書（ＳＬＡ）ポリシー、権利管理ポリシー、ガバナンス・ポリシー、コンプライアンス・ポリシー、パッチ管理／脆弱性管理ポリシー、ユーザ管理ポリシーなどを含む、任意のタイプとすることができるが、これらに限定されない。

上記では、本発明のより適切な特徴の一部について概説してきた。これらの特徴は、単なる例として解釈されるべきである。開示された発明を異なる様式で適用することによって、または、以下で説明される発明を修正することによって、多くの他の有益な結果を達成することができる。

次に、本発明およびその利点についてより完全に理解するために、添付の図面に関した以下の説明に言及する。

本発明が実装可能なウェブ・サービス環境を示す図である。ウェブ・サービスに関する代表的なアクセス・マネージャを示す図である。ウェブ・サービスに関する代表的なアクセス・マネージャを示す図である。ＷＳＤＬ文書の代表的部分を示す図である。代表的なウェブ・サービス保護オブジェクト・スペースを示す図である。代表的なＷＳＤＬバインディングを示す図である。アクセス・マネージャがＷＳＤＬからＷＳＤＬ保護オブジェクト・スペース（ＰＯＳ）を生成する方法を示す図である。代表的なリソース・レベル保護オブジェクト・スペース・フォーマットを示す図である。図６に示されたＷＳＤＬバインディングに関連付けられた、代表的なリソース・レベル保護オブジェクト・スペースを示す図である。アクセス・マネージャが、ＥＡＲなどのアプリケーション・サーバ・バックエンド・コードからリソース特有の保護オブジェクト・スペースを生成する方法を示す図である。ＷＳＤＬＰＯＳとリソース特有のＰＯＳとの間にマッピングが提供される方法を示す図である。ＷＳＤＬＰＯＳとリソース特有のＰＯＳとの間にマッピングが提供される方法を示す図である。実施形態に従ってマッピングが生成される方法を示す図である。本発明が実装可能な、階層リソース・スペースを示す図である。ウェブ・サービス環境において所与のトランザクションを完了するための、リソース・セットの可能な呼び出し順序を示す図である。リソース・オブジェクト・ペアに関連付けられた、図１４に示されたような階層リソース・スペースの監査ポリシー・インスタンスを示す図である。本発明の教示に従った、リソース・オブジェクトの監査ポリシー間のマッピングを示す図である。本発明が実装可能な、より複雑な階層リソース・スペースを示す図である。図１８の階層リソース・スペースにおける低レベル・リソース・オブジェクトのペアにまたがって、サービス品質ポリシーが同期化される方法を示す図である。図１８〜図１９に示されたウェブ・サービス環境において所与のトランザクションを完了するための、リソース・セットの可能な呼び出し順序を示す図である。本発明が実装可能な代表的なデータ処理システムを示すブロック図である。

周知のように、企業は、セキュリティ・ドメイン境界の内部で、およびこの境界をまたがって、異種環境をまたがるアプリケーションの統合を容易にするために、ウェブ・サービスを採用している。構造化情報標準促進協会（ＯＡＳＩＳ）では、近年、メッセージ保全性、機密性、識別伝播、および認証を提供するための拡張可能フレームワークを提供するために、様々なウェブ・サービス・セキュリティ（ＷＳＳ）標準を批准している。図１に示された典型的なシナリオでは、ＳＯＡＰメッセージは、ＳＯＡＰメッセージを処理し、場合によっては変換する、ゼロまたはそれ以上のＳＯＡＰ中間器１０４を備える、ＳＯＡＰメッセージ・パスに沿って、初期ＳＯＡＰ送信器１００から最終ＳＯＡＰ受信器１０２へと送信される。ここでのＳＯＡＰの使用は単なる例示的なものであって、本発明の範囲を制限するためであると解釈されるべきではなく、保護メッセージを転送するために使用される特定の移送メカニズムに依存しない。デバイス１００、１０２、および１０４は、エンティティが、公的にルーティングされたインターネット、イントラネット、エクストラネット、専用ネットワーク、あるいは任意の他の通信メディアまたはリンクなどの、ネットワークを介して互いに通信し合う、それぞれがハードウェアおよびソフトウェアを備えるデータ処理システムなどの、コンピューティング・エンティティである。以下で説明するように、データ処理システムは、通常、１つまたは複数のプロセッサ、オペレーティング・システム、アプリケーション・サーバ、１つまたは複数のアプリケーション、ならびに１つまたは複数のユーティリティを備える。所与のデータ処理システムは、システムが伝送の「送信側」にあるとみなされる場合、送信器または送信側エンティティとすることが可能であり、システムが「受信側」にあるとみなされる場合、受信器または受信側エンティティとすることが可能である。データ処理システム上のアプリケーションは、とりわけ、ＨＴＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬを含むが、これらに限定されない、ウェブ・サービスに対する固有のサポートを提供する。これらの技術および標準に精通しているものと想定される。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する他の情報は、これらの標準を発展および維持する責務を負うＷｏｒｌｄＷｉｄｅＷｅｂＣｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）から入手可能であり、ＨＴＴＰおよびＸＭＬに関する他の情報は、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）から入手可能である。

ＷＳＤＬは、定義セット、ルートでの定義要素、およびルート内部の追加定義セットを備える、ＸＭＬ文書である。サービスは、交換されるメッセージを記述するために使用されるデータ・タイプ定義を提供するｔｙｐｅと、伝送されているデータの抽象定義を表すｍｅｓｓａｇｅと、抽象操作のセットであるｐｏｒｔＴｙｐｅと、特定のｐｏｒｔＴｙｐｅによって定義される操作およびメッセージに関する具体的なプロトコルおよびデータ・フォーマット仕様を指定するｂｉｎｄｉｎｇと、関係ポートのセットを集約するために使用されるｓｅｒｖｉｃｅとを含む、要素セットを使用して定義される。したがってＷＳＤＬは、メッセージ上で動作する１つまたは複数のエンドポイントのセットを記述する。操作およびメッセージは抽象的に記述された後、具体的なネットワーク・プロトコルとバインディングされ、エンドポイントを作成するようにフォーマット化される。したがって、ＷＳＤＬの抽象部分はサービス・インターフェースを表し、通常は、ｔｙｐｅ、ｍｅｓｓａｇｅ、およびｐｏｒｔＴｙｐｅの要素を備え、ＷＳＤＬの具体的部分はサービス・インターフェースのサービス・インプリメンテーションを表し、通常は、ｓｅｒｖｉｃｅおよびｂｉｎｄｉｎｇの要素を含む。したがって、ｂｉｎｄｉｎｇ要素は、通常、「具体性」の概念が導入される場所である。具体的に言えば、天気予報ウェブ・サービスに関するこれらの要素のいくつかを示す代表的ＷＳＤＬの一部である、図２の例に示されるように、通常、これはＳＯＡＰバインディングおよび移送方法が定義される場所である。このＷＳＤＬは、いくつかの異なるバインディング、ならびにウェブ・サービスが取得されるＵＲＬ定義ＨＴＴＰアクセス可能リソースを含む。サービス要素内の情報を使用して、以下で説明するように、たとえば、特定のサービス名／アドレスの下にＷＳＤＬ（またはＷＳＤＬバインディング）に関するＰＯＳを懸垂することによって、ＷＳＤＬに関する保護オブジェクト・スペース（ＰＯＳ）を構築することができる。

ウェブ・サービス環境は、未許可での所与のリソースの使用を防止することを含む、リソースの未許可使用を防ぐコンポーネントである、アクセス・マネージャを含むシステム内で実装可能である。代表的なアクセス・マネージャは、Ｔｉｖｏｌｉ（Ｒ）ＡｃｃｅｓｓＭａｎａｇｅｒ製品であって、ＩＢＭ社から市販されており、図４に示されている。もちろん、この市販品の識別は、限定的なものとして採用されていることを意味するものではない。より広義には、このために、ポリシー／アクセス／サービス決定を提供する、任意のシステム、デバイス、プログラム、またはプロセスが使用可能である。好ましくは、アクセス・マネージャは、ＴｈｅＯｐｅｎＧｒｏｕｐの許可（ａｚｎ）ＡＰＩ標準に準拠する、アクセス制御機能を提供する。この技術標準は、アクセス制御機構が国際標準ＩＳＯ１０１８１−３に記載されたアーキテクチャ・フレームワークに準拠する、システム内でのアクセス制御に関する、汎用アプリケーション・プログラミング・インターフェースを定義する。フレームワークは、アクセス要求に関与するコンポーネントについて、（１）アクセス要求を提出するイニシエータ３００（要求が、実行される操作を指定する）と、（２）情報リソースまたはシステム・リソースなどのターゲット３０２と、（３）アクセス制御実施機能（ＡＥＦ）３０４と、（４）アクセス制御決定機能（ＡＤＦ）３０６という、４つのロールを定義する。図に示されるように、ＡＥＦは決定要求をＡＤＦに提出する。決定要求は、特定のアクセス要求が認可されるべきであるかまたは拒否されるべきであるかを問う。ＡＤＦは、データベース３０８に格納されたポリシーなどのセキュリティ・ポリシーに基づいて、アクセス要求が認可されるべきであるかまたは拒否されるべきであるかを決定する。コンポーネント３０４、３０６、および３０８は、アクセス・マネージャを備える。セキュリティ・ポリシーは、通常、アクセス制御リスト（ＡＣＬ）、保護オブジェクト・ポリシー（ＰＯＰ）、許可規則、および拡張属性の組み合わせを使用して、定義される。アクセス制御リストは、あるオブジェクト上でユーザおよびグループのセットが実行可能である、事前に定義されたアクションを指定する。たとえば、グループまたはユーザの特定のセットを、オブジェクトへの許可された読み取りアクセスとすることができる。保護オブジェクト・ポリシーは、すべてのユーザおよびグループに影響を与えるオブジェクトに関連付けられたアクセス条件を指定する。たとえば、指定された時間中にすべてのユーザおよびグループをオブジェクトにアクセスさせないようにする時刻制限を、オブジェクトに配置することができる。許可規則は、アクセスが許可されるかどうかを決定するために評価される、複雑な条件を指定する。この決定を行うために使用されるデータは、要求、現在の環境、または他の外的要因との関連に基づくことができる。たとえば、８時間の間に５回より多くオブジェクトを修正する要求は、拒否することができる。セキュリティ・ポリシーは、保護を必要とするそれらのリソースに、ＡＣＬ、ＰＯＰ、および許可規則を戦略的に適用することによって実装される。拡張属性は、第三者アプリケーション（外部許可サービスなど）によって読み取りおよび解釈可能な、オブジェクト、ＡＣＬ、またはＰＯＰ上に配置される追加の値である。アクセス・マネージャ許可サービスは、ＡＣＬ、ＰＯＰ、許可規則、および拡張属性に、要求ならびに特定の許可および条件を設定する、ユーザの信用証明に基づいて、リソースへのアクセスを許可または拒否するように決定する。

セキュリティ・ポリシーの目的は、最低限の管理努力によって、業務資産およびリソースを適切に保護することである。第１に管理者は、どのリソースを保護するべきであるかを定義する。これらのリソースは、ファイル、ディレクトリ、ネットワーク・サーバ、メッセージ、データベース、キュー、またはウェブ・リソースなどの、任意のタイプのデータ・オブジェクトとすることができる。その後、管理者は、どのユーザおよびユーザのグループが、これらの保護リソースへのアクセス権を有するべきかを決定する。別の方法として、管理者は、どのユーザの「ロール」がこれらの保護リソースへのアクセス権を有する（たとえば、所与の識別されたユーザが「銀行出納係」のロールを有することができる）べきであるかを決定することができる。管理者は、どのタイプのアクセスがこれらのリソースに対して許可されるべきかも決定する。最終的に管理者は、正当なユーザのみがそれらにアクセスできることを保証するために、これらのリソースに適切なセキュリティ・ポリシーを適用する。ドメイン内のオブジェクトへのアクセスは、保護オブジェクト・スペース内のオブジェクトにセキュリティ・ポリシーを適用することによって制御される。

当業者であれば周知のように、（図４に示されたような）アクセス・マネージャは、保護オブジェクト・スペース（すなわちＰＯＳ）と呼ばれる仮想表現を使用して、ドメイン内のリソースを表す。保護オブジェクト・スペースは、ドメインに属するリソースの論理的および階層的描写である。通常、保護オブジェクト・スペースの構造は、リソース・オブジェクトおよびコンテナ・オブジェクトという、２つのタイプのオブジェクトを備える。リソース・オブジェクトとは、ファイル、サービス、ウェブ・ページ、メッセージ・キューなどのような、ドメイン内の実際の物理リソースの論理的表現である。コンテナ・オブジェクトとは、リソース・オブジェクトを明確な機能領域に階層状にグループ化できる、構造的なコンポーネントである。セキュリティ・ポリシーは、どちらのタイプのオブジェクトにも適用可能である。保護オブジェクト・スペースは、ルート・コンテナ・オブジェクトを有する。ルート・コンテナ・オブジェクトの下には、１つまたは複数のコンテナ・オブジェクトが存在する。各コンテナ・オブジェクトは、リソースの関係セットからなるオブジェクト・スペースを表す。これらのリソースは、リソース・オブジェクトまたはコンテナ・オブジェクトとすることができる。セキュリティ・ポリシーを首尾よく実装するためには、異なるコンテンツ・タイプが論理的に編成されること（および、適切なＡＣＬ、ＰＯＰ、および許可規則が適用されること）が必要である。このタイプの階層保護オブジェクト・スペースの以前のインプリメンテーションは、別個であり、実際には互いに排他的な、これらの個々のコンテナ・オブジェクトに依拠している（たとえば、メッセージ・キュー・コンテナの下で管理されているリソースは、ウェブ・アプリケーション・コンテナの下でもアクセス不可能である）。

図５は、階層オブジェクトのセット、すなわち、ルート・オブジェクト４０２、１つまたは複数の関係ウェブ・サービスへの単一パスを維持するために便宜上使用されるコンテナ・オブジェクト４０４、ＷＳＤＬサービスを識別する１つまたは複数のサービス名オブジェクト４０６および４１６、ＷＳＤＬポート・タイプを識別する１つまたは複数のポート・タイプ・オブジェクト４０８、ならびに、ＷＳＤＬ指定の操作を識別する１つまたは複数の操作オブジェクト４１０を備える、サンプルの抽象ウェブ・サービス保護オブジェクト・スペース４００を示す。単なる例示のために、ポート・オブジェクト４０８は関連するＡＣＬ４１５を有し、操作オブジェクト４１０のうちのひとつも同様であって、すなわちＡＣＬ４１８を有する。２つのサービス４０６および４１６は、同じ全体タイプのサービス（たとえば株式市況サービス）の同様のインスタンス化とするか、または、図らずも同じ全体ポリシーが適用された完全に直交するサービスとすることが可能であり、このポリシーは、たとえばＡＣＬ４１５によって定義される。

図６は、（その一部が図２に示された）リソースのＷＳＤＬ表現のための保護オブジェクト・スペース・ツリー５００を示し、ここでリソースのインプリメンテーション（たとえばＥＪＢ対ＭＱキュー）は未知である。保護オブジェクト・スペース全体はルート５０２によって固定（anchor）され、ここでルート５０２は、ＭＱキュー用の保護オブジェクト・スペース５０４、ウェブ・アプリケーション用の保護オブジェクト・スペース５０６、ウェブ・サービス・コンテナ５０８、および管理コンテナ５１０を含む、いくつかの子を有する。ウェブ・サービス・コンテナ５０８の下には、「天気サービス」関連サービス用に定義された天気コンテナ５１２がある。このコンテナは、（この例では）天気予報サービスおよび予報加入サービスを表す、ＷＳＤＬ定義サービス５１４および５１６のペアを備えるように示される。コンテナ５１４および５１６が下にあるサブツリーは、単一のウェブ・サービス・コンテナ５１２によって表される２つの異なるサービスを示す。コンテナ５１８および５２０は天気予報サービス・コンテナ５１４の下にあり、リソースのウェブ・サービス定義セットの２つの異なるバインディング（ＨＴＴＰ対ＪＭＳ）を表す。コンテナ５２２は、予報加入サービス５１６に関するＳＭＴＰバインディングを示す。ＷｅａｔｈｅｒＦｏｒｅｃａｓｔＨＴＴＰコンテナ５１８は、ｇｅｔＴｏｄａｙＦｏｒｅｃａｓｔコンテナ５２４、ｇｅｔＷｅｅｋＦｏｒｅｃａｓｔコンテナ５２６、およびｇｅｔＤａｙＦｏｒｅｃａｓｔコンテナ５３２を含む、いくつかの操作コンテナを有する。ＷｅａｔｈｅｒＦｏｒｅｃａｓｔＪＭＳコンテナ５２０は、ＷｅａｔｈｅｒＳｅｒｖｉｃｅ＿Ｑキュー・コンテナ５２８を有し、それ自体はｇｅｔＴｏｄａｙＦｏｒｅｃａｓｔコンテナ５３４およびｓｅｔＴｏｄａｙＦｏｒｅｃａｓｔコンテナ５３８を有する。コンテナ５２４および５３４はおそらく同じリソースである。コンテナ５２２は予報加入コンテナ５３０を有し、それ自体はＳｕｂｓｃｒｉｂｅＴｏＦｏｒｅｃａｓｔ操作に関する子コンテナ５３６を有する。コンテナの多くは、５６０、５６２、および５６４などの関連ＡＣＬを有する。保護オブジェクト・スペース・ツリーの全ウェブ・サービス分岐に適用されるアクセス制御ＡＣＬ５６０は、ウェブ・サービス分岐のすべての子によって「継承」される。しかしながら、ウェブ・サービスの天気予報サービス・コンテナ５１４は、それ独自のＡＣＬ５６２を有すること、すなわち、保護オブジェクト・スペースのウェブ・サービス分岐に割り当てられたＡＣＬを継承しないことに、留意されたい。同様に、操作「ｇｅｔＴｏｄａｙＦｏｒｅｃａｓｔ」５２４はそれ独自のＡＣＬ５６４を有し、すなわち、保護オブジェクト・スペースの天気予報サービス・サブツリーに割り当てられたＡＣＬ５６２を継承しない。したがって、ＷＳＤＬ定義ウェブ・サービスのこの表現は、保護オブジェクト・スペース階層内のＡＣＬの表現および管理に関する最新の機能に従う。保護オブジェクト・スペースは、粗野なポリシーはサービス・インターフェース・レベルで適用され、細密なポリシーはサービス・インプリメンテーション・レベルで適用されるように、定義されることに留意されたい。

図７に示されるように、具体的なＷＳＤＬベースの保護オブジェクト・スペースは、アクセス・マネージャによって生成ならびに管理される。具体的には、アクセス・マネージャ６００は、アクセス・マネージャのアクセス制御決定機能に応答して、ウェブ・サービス特有のアクセス制御実施機能を提供する、関連するウェブ・サービス・セキュリティ管理コンポーネント６０２を有する。具体的には、ウェブ・サービス・セキュリティ管理コンポーネント６０２は、リソース（またはリソース・セット）のＷＳＤＬ記述を受け取り、具体的（サービス・インプリメンテーション）記述および抽象的（サービス・インターフェース）記述の両方を含む、ＷＳＤＬ記述全体を解析する。Ｔｉｖｏｌｉ（Ｒ）ＦｅｄｅｒａｔｅｄＩｄｅｎｔｉｔｙＭａｎａｇｅｒでは、「ｗｓｄｌ２ｔｆｉｍ」コマンドが、このオブジェクト・スペース作成を自動的に実行するが、ＷＳＤＬからの保護オブジェクト・スペースの作成は、任意の便利な方法で実行可能である。

通常、ウェブ・サービスは、必要なサービス機能を実行する１つまたは複数のバックエンド・アプリケーションを使用する。アプリケーション・レベル・リソースは、通常、関連する保護オブジェクト・スペースも有する。図８は、バックエンド・リソース・セットに関するサンプルのアプリケーション・サーバ・レベルの保護オブジェクト・スペース７００を示す。単なる例示として、図８に示された保護オブジェクト・スペース７００は、ＩＢＭ（Ｒ）社のＷｅｂＳｐｈｅｒｅ（Ｒ）アプリケーション・サーバに関するサンプルの保護オブジェクト・スペースを表すが、もちろん、このツリー構造のＰＯＳ表現が他のアプリケーション・サービス環境にも適用可能であることは明らかである。保護オブジェクト・スペース７００は、ルート・オブジェクト７０２（ＰＯＳの固定に使用される）、ウェブ・アプリケーション・サーバ・コンテナ７０４、展開リソース・オブジェクト７０６、ロール名オブジェクト７０８、アプリケーション名オブジェクト７１０、セル名オブジェクト７１２、ホスト名オブジェクト７１４、およびサーバ名オブジェクト７１６を含む。単なる例示として、ロール名オブジェクト７０８は関連ＡＣＬ７１８を有するように示されており、サーバ名オブジェクトも同様に、関連ＡＣＬ７２０を有する。この保護オブジェクト・スペースは、ＷｅｂＳｐｈｅｒｅアプリケーション・サーバ・ベースのリソースに関する展開オプションを反映するものであり、ここでは複数のロールが単一のＡＣＬ（たとえば７１８）で定義可能であり、所与のサーバがリソースをホストする場合によっては（たとえばＡＣＬ７２０で示されるように）このＡＣＬは無効となる可能性がある。

図９は、サンプルのアプリケーション・レベルＰＯＳのインスタンス化を示し、この例ではこれは単なる代表例であり、保護オブジェクト・スペース８００は、天気予報生成機能が（たとえばＥＪＢによって）管理されるバックエンド・アプリケーション・サーバに関連付けられる。このＰＯＳの例では、天気予報アプリケーション８０２／８０６には、予報者８０４または消費者８０８のロールのエンティティによって（ポリシー・コンプライアンスに従って）アクセス可能である。具体的には、予報者ロールの人物またはエンティティがアプリケーション８０２を介して天気予報を設定し、消費者ロールの人物またはエンティティがアプリケーション８０６を介して天気予報を取得する。

図１０に示されるように、アクセス・マネージャによってアプリケーション特有のＰＯＳが生成される。具体的には、アクセス・マネージャ９００は、ＥＡＲファイル９０４からツールに入力されるアプリケーション特有のＰＯＳ９０６を生成する、関連するマイグレーション・ツール９０２を有する。Ｔｉｖｏｌｉ（Ｒ）ＡｃｃｅｓｓＭａｎａｇｅｒでは、「ｍｉｇｒａｔｅＥＡＲ４」コマンドがこのオブジェクト・スペース作成を自動で実行するが、ＥＡＲ（または他のバックエンド・コード・コンポーネント）からの保護オブジェクト・スペースの作成は、任意の便利な様式で実行可能である。Ｔｉｖｏｌｉ（Ｒ）ＡｃｃｅｓｓＭａｎａｇｅｒｆｏｒＢｕｓｉｎｅｓｓＩｎｔｅｇｒａｔｉｏｎは、このオブジェクト・スペース作成をＭＱＳｅｒｉｅｓ（Ｒ）環境用に自動で実行する同様のツールを有する。マイグレーション・ツール９０２の操作の結果、図８に示されたような保護オブジェクト・スペースが発生する。

説明された一実施形態によれば、ウェブ・サービスに関するアクセス制御（抽象ＷＳＤＬ定義に基づいて制御を行う）は、ＷＳＤＬ定義保護オブジェクト・スペースに関して定義され、したがって、好ましくはバインディング・レベルごとに、それらの定義から導出された具体的なＷＳＤＬバインディングと疎結合される。次にこのＷＳＤＬ定義ＰＯＳは、リソース特有の保護オブジェクト・スペース定義とバインディングされる。この疎結合は、抽象ＷＳＤＬバインディングの保護オブジェクト・スペースへの変更（たとえば更新）が、アプリケーション特有の保護オブジェクト・スペースに移行的に適用できるように利用される。適切であれば、リソース特有の保護オブジェクト・スペースへの変更を、ＷＳＤＬの保護オブジェクト・スペースに適用することができる。したがって、本実施形態によれば、結合は一方向（通常はＷＳＤＬＰＯＳからリソース・レベルＰＯＳへ）または双方向（ＷＳＤＬＰＯＳからリソース・レベルＰＯＳへ、およびその逆）とすることができる。この技法は、異なるセキュリティ・ポリシーが非意図的に同じリソースに適用されない（たとえば、一方がウェブ・サービス／操作レベルにあり、他方がアプリケーション／ＥＪＢレベルにある）ことを保証するものであることを理解されよう。前述のように保護オブジェクト・スペースを同期化することによって、アプリケーションを展開するエンティティとセキュリティ管理者とのいずれも、ウェブ・サービス要求とアプリケーション要求との相違を認識する必要がない。

図１１は、前述の技法を例として示す。図を見ればわかるように、ウェブ・サービス・コンテナ１００２は天気予報サービスＷＳＤＬＰＯＳ１００６を含み、これがリソース・インプリメンテーション１００８のＨＴＴＰバインディングを含み、これが１０１０、１０１２、および１０１４などのウェブ・サービス操作を含む。これは、前述の図６と同様である。さらに図１１には、その保護オブジェクト・スペースを備えたウェブ・アプリケーション・サーバ・コンテナ１０２０も示され、これが２つのロール１０２４および１０３０、すなわち予報者ロールおよび消費者ロールを含む。これらのロールは、図９で前述したように、ｓｅｔＦｏｒｅｃａｓｔ１０２６およびｇｅｔＦｏｒｅｃａｓｔ１０２８のアプリケーションにアクセスすることができる。これらのアプリケーションは、ＷＳＤＬ保護オブジェクト・スペースの一部として露出されるアプリケーションと同様であるが、それらの間に、これらリソース上でＡＣＬの統合管理を可能にする論理接続は存在しない。たとえば、ＡＣＬ１０１６、１０１８、１０３４、および１０３６が同じリソースに関連していることを保証する方法はなく、関連している場合、それらを管理するための一貫した方法はない。各ＡＣＬは、独立に管理しなければならないそれ独自のエンティティである。

この問題の解決策が図１２に示される。具体的には、図１２は、１つまたは複数の疎結合のセットが達成された場合、これが、これらの異種と思われる保護オブジェクト・スペース全体にわたってＡＣＬおよびポリシーの一貫した管理を提供する方法を示す。具体的には、天気サービス１００６に関するＷＳＤＬＰＯＳ１００６が、コネクタのセット１０４０および１０４２を介して、アプリケーション・サーバＰＯＳ１０２０にマッピングされている。もちろん、コネクタの数は単なる例示的なものである。この例では、コネクタ１０４０は、ＷＳＤＬ１０００における天気予報ＨＴＴＰ操作１００８が、ＰＯＳ１００２内のｓｅｔＦｏｒｅｃａｓｔアプリケーション１０２６と相関する、関連する予報者グループの許可を有することを示す。同様に、コネクタ１０４２は、ＷＳＤＬ１０００におけるｇｅｔＴｏｄａｙＦｏｒｅｃａｓｔ操作１０１４が、ＰＯＳ１００２内のｇｅｔＦｏｒｅｃａｓｔｓアプリケーション１０２８と相関する、関連する消費者ユーザの許可を有することを示す。これらの疎結合に基づいて、ＷＳＤＬ１０００内の天気予報ＨＴＴＰ操作１００８に適用されたＡＣＬに対するいかなる許可された変更も監視され、ＰＯＳ１００２内のｓｅｔＦｏｒｅｃａｓｔアプリケーション１０２６に適切にマッピングされ、同様に、ＷＳＤＬ１０００内のｇｅｔＴｏｄａｙＦｏｒｅｃａｓｔ操作１０１４に適用されたＡＣＬに対するいかなる許可された変更も監視され、ＰＯＳ１００２内のｇｅｔＦｏｒｅｃａｓｔアプリケーション１０２８に適切にマッピングされる。このように、保護オブジェクト・スペースは、一貫した同期化様式で更新される。アクセス制御ポリシーは、実行される要求タイプ（ウェブ・サービス要求であるか、アプリケーション特有の要求であるか）に関係なく維持される。

このようにして、前述の技法は、所与の許可決定が、通常、いくつかの場所、たとえばウェブ・サービス・エントリで、および所与のバックエンド・アプリケーション内で実装される、ウェブ・サービス環境において、同期化アクセス制御を提供するための方法を提供する。概括すると、同期化アクセス制御の方法は、図１３に示されたプロセス・ステップを含む。この方法は、ステップ１１００で、ＷＳＤＬからウェブ・サービス保護オブジェクト・スペースを生成することによって開始される。ステップ１１０２では、アプリケーション特有の保護オブジェクト・スペースが、アプリケーション・コード・ベース（エンタープライズ・アーカイブ・ファイル（ＥＡＲ）など）から生成される。ステップ１１００および１１０２はオフラインで実施することができる。これらのステップについては、上記で、高水準で説明および図示してきており、たとえば図７および図１０を参照されない。次にステップ１１０４では、保護オブジェクト・スペース内の対応するオブジェクト間で、１つまたは複数の結合のセットが定義される。もちろん、保護オブジェクト・スペース全体にわたってどのオブジェクトが結合されるかの識別は、必然的に、オブジェクト・スペース内に定義された様々な操作および方法、ならびにそれらに関連付けられたセキュリティ・ポリシーに依存することになる。これらの結合は、プログラムに基づいて、またはユーザによって直接、たとえば、様々な商用ソースから入手可能であるような視覚マッピング・ツールを使用して、またはＥｃｌｉｐｓｅソフトウェア開発環境などのオープン・ソース・プロジェクトを介して、定義することができる。マッピング規則のセットは、定義済み結合に関連付けられる。マッピング規則を表す便利な方法は、ＸＡＣＭＬまたはＷＳ−ＰｏｌｉｃｙなどのＸＭＬに基づくポリシー言語を使用することである。したがって、図１２の例では、マッピング規則は、ＷＳＤＬＰＯＳ内のｇｅｔＴｏｄａｙＦｏｒｅｃａｓｔ操作への変更が、アプリケーション特有のＰＯＳ内のｇｅｔＦｏｒｅｃａｓｔアプリケーションに関係することを示し、同様にマッピング規則は、他の識別された結合に対して定義される。マッピング規則は、一方の保護オブジェクト・スペース内の要素への変更が、他方の保護オブジェクト・スペース内の要素に影響を与えるかどうか、および影響を与える方法を、定義する。１つまたは複数のオブジェクト結合が作成されると、変更に関して保護オブジェクト・スペースを監視することによって、および、それらの更新を疎結合を介して選択的に伝播することによって、セキュリティ・ポリシー同期化が自動的に実行される。このため、各ＰＯＳがそれらをリスナ（listener）またはフィルタと関連付ける。同期化方法は、ステップ１１０６で、アクセス制御への更新のために待機する。ＷＳＤＬＰＯＳ上に配置されたＡＣＬへの任意の更新が、ステップ１１０８で方法をトリガし、マッピング規則のセットに対する変更を解析する。所与のマッピング規則が関係する場合、セキュリティ・ポリシーの変更は、他の保護オブジェクト・スペース内の対応するオブジェクトに適用される。これがステップ１１１０である。マッピング規則が関係しない場合、変更は伝播されない。マッピング規則は、どの変更が一方向（単方向）であり、どの変更が双方向（両方向）であるかを、定義する。前述のように、変更は、一方向（たとえば、具体的なＷＳＤＬ保護オブジェクト・スペースへの変更がアプリケーション特有の保護オブジェクト・スペースに伝播されるが、その逆はない）とするか、または双方向（すなわち、アクセス制御変更が両方向に伝播される）とすることができる。これにより、発明の方法の基本的処理が完了する。

当業者であれば、前述の技法が、保護オブジェクト・スペース全体にわたってＡＣＬ変更を伝播するために使用するのみに限られないことを理解されよう。より一般的には、この技法を使用して、第１の保護オブジェクト・スペースおよび第２の保護オブジェクト・スペースにわたり、（ＡＣＬ、ＰＯＰ、許可規則、または拡張属性のいずれかとして実装された）任意のセキュリティ・ポリシーを同期化するために使用可能であり、その逆もまた真である。さらにこの技法は、（ユーザの加入パラメータに基づいて）同期化されたアクセス・ポリシーを提供するために、ウェブ・サービス環境で使用することも可能である。一般に、この技法は、２つまたはそれ以上の任意の階層オブジェクト・スペースにわたって、それらオブジェクト・スペースが何を表すかに関わらず、自動的に同期化するために使用可能である。必要なものは、オブジェクト結合を定義するため、所与のオブジェクト属性への変更を監視するため、マッピング規則のセットに対する変更を解析するため、およびその変更を伝播するための、ツールのみである。

本発明に従って、前述のアクセス制御関連の技法は、１つまたは複数のセキュリティに無関係な状況において同期化された制御を提供するように拡張される。これらの状況はかなり変化する可能性があるが、一般には、ウェブ・サービス環境において、所与のトランザクションが、所与のポリシーを実施するためのオプションが存在する複数の「接触」ポイント（通常はリソース・セット）を含むシナリオに関係する。ポリシーのタイプはかなり変化する可能性があり、代表的な例には、監査ポリシー、サービス品質（ＱｏＳ）ポリシー、サービス内容合意書（ＳＬＡ）ポリシー、権利管理ポリシー、ガバナンス・ポリシー、コンプライアンス・ポリシー、パッチ管理／脆弱性管理ポリシー、ユーザ管理ポリシーなどが含まれるが、これらに限定されない。

セキュリティに無関係な状況では、「保護オブジェクト・スペース」の概念は「階層リソース・スペース」として一般化することが可能であり、これは本明細書で使用される場合、ウェブ・サービス環境における所与のサービス・トポロジの視覚表現を言い表す。階層リソース・スペースの例について、以下で説明する。保護オブジェクト・スペースと同様に、階層リソース・スペースは、通常、典型的にはドメインに属する、リソースの論理および階層描写を備える。スペースの構造は、リソース・オブジェクトおよびコンテナ・オブジェクトを備えることもできる。前述のように、リソース・オブジェクトとは、サーバ、サービス、ウェブ・アプリケーション、メッセージ・キューなどのような、ドメイン内の実際の物理リソースの論理的表現である。コンテナ・オブジェクトとは、リソース・オブジェクトを明確な機能領域に階層状にグループ化することができる、構造的なコンポーネントである。図１４は、ルート１２００によって固定された代表的な階層リソース・スペースであり、ここでルート１２００は、ＭＱキュー・オブジェクト１２０２、ウェブ・アプリケーション・オブジェクト１２０４、ウェブ・サービス・オブジェクト１２０６、および管理コンテナ１２０８を含む、いくつかの子を有する。監査マネージャ・ツールを使用して、所与の監査ポリシーを定義し、１つまたは複数のこれらのオブジェクトに適用することができる。同様に、サービス品質管理ツールを使用して、所与のサービス品質ポリシーを定義し、これを１つまたは複数のオブジェクトに適用することが可能であり、他のタイプのポリシーについても同様に可能である。ＱｏＳ管理用の代表的なツールには、たとえば、ＳＯＡ／ＲｅａｌＴｉｍｅＴｒａｎｓａｃｔｉｏｎのためのＴｉｖｏｌｉＣｏｍｐｏｓｉｔｅＡｐｐｌｉｃａｔｉｏｎＭａｎａｇｅｒが含まれる。もちろん、所与のポリシーを首尾よく実装するためには、異なるオブジェクトおよびそれらのタイプが論理的に編成されること（および、適切なポリシー関係規則が適用されること）が必要である。このタイプの階層リソース・スペースの以前のインプリメンテーションは、別個であり、実際には互いに排他的な、これらの個々のコンテナまたはリソース・オブジェクトに依拠している（たとえば、メッセージ・キュー・コンテナの下で管理されているリソースは、ウェブ・アプリケーション・コンテナの下でもアクセス不可能である）。

次に、本発明について、監査ポリシー制御を含む例を挙げて説明する。ウェブ・サービス環境における所与のトランザクションが、トランザクションを完了するために所与の様式で呼び出される必要がある複数のリソースを含むこと、および、それらリソースの１つまたは複数がそれらに関連付けられた監査ポリシーを有することが、想定される。図１５は、こうしたシナリオの１つを示し、これは単なる代表的な１つの可能なリソース順序であり、ここでトランザクションは、ウェブ・サーバ１３００からウェブ・サービス１３０２へ、ウェブ・アプリケーション１３０４へ、ＭＱキュー１３０６へと進む。このトランザクションが階層リソース・スペースによって表される場合、結果として生じるスペースは図１６に示されるようになる可能性がある。図からわかるように、この階層リソース・スペースは、ウェブ・サーバ１２１０が追加されていること以外は図１４に示されたものと同様である。図１６のウェブ・サーバ１２１０は、図１５のサーバ１３００に対応する。図１６にも見られるように、ウェブ・アプリケーション・オブジェクト１２０４はそれらを監査ポリシーＡ（参照番号１２１２）と関連付けているが、ウェブ・サーバ・オブジェクトはそれらを監査ポリシーＢ（参照番号１２１４）と関連付けている。これは、複数の監査ポリシーが複数のオブジェクトに適用される方法の例である。本発明によれば、これらのポリシー（単一ポリシーの別々のインスタンスとみなすことができる）は、図１７に示されるように、結合１２１６を介して同期化される。図中の「Ｕ」は、セット「合併（union）」機能を示すように意図されていることに留意されたい。これはもちろん、ポリシーが結合または接合される方法が任意の特定の技法に限定されないことを、単に表しているだけである。したがって、ポリシーのタイプおよび同期化の方向は、特定のアプリケーションまたはウェブ・サービス環境によって、必要に応じて定義することができる。この例では、監査ポリシーに関して、所与のキューは、縁部（ウェブ・サーバ）で監査される可能性のあるよりも多くの情報を監査するように要求する可能性があり、結果として、より一般的な監査ポリシー（合併接合）をウェブ・サーバで実施すべきである。アクセス制御に関連して前述したように、結合は、プログラムに基づいて、またはユーザによって直接、たとえば視覚マッピング・ツールを使用して、定義することができる。さらに好ましくは、マッピング規則のセットは定義された結合に関連付けられる。マッピング規則を表すための便利な方法は、ＸＡＣＭＬまたはＷＳ−ＰｏｌｉｃｙなどのＸＭＬに基づいたポリシー言語を使用することである。結合は一方向または双方向とすることができる。いずれのケースでも、結合は、ウェブ・アプリケーション・サーバ（監査ポリシーＡ）が必要とする監査ポリシーを、ウェブ・サーバ（監査ポリシーＢ）が必要とする監査ポリシーに追加する。この例示的実施形態では、結合は、合併または「接合」を介して実行される。通常、ポリシー伝播は合併を介して実施されるが、これは本発明の要件ではない。結合は、ウェブ・アプリケーションによるアクションに関する包括的なエンドツーエンド監査報告を構築するために必要なすべてを、ウェブ・サーバが監査しないことを保証する。ウェブ・アプリケーションが後に、収集する必要のある情報を緩和する場合、ウェブ・サーバでこの変更を更新することが可能であり、２つのポリシーの合併も緩和することができる。監査ポリシーＢそれ自体が、監査ポリシーＡによって緩和されてきた情報を必要とする場合、引き続きウェブ・サーバによってログされることになる。

前述のように、階層リソース・スペース内の所与のオブジェクトは、それらに関連付けられた任意数の異なるポリシーを有することができる。概括すると、当業者であれば、本発明の方法をウェブ・サービス環境で使用し、問題のポリシーに依存して、同期化監査ポリシー、同期化サービス品質制御、同期化サービス・レベル制御、同期化権利管理制御などのうちの１つまたは複数を提供できることを理解されよう。それぞれの場合、および前述の様式では、好ましくは本発明を使用し、１つまたは複数のオブジェクト結合を定義するステップと、所与のオブジェクト属性に対する変更を監視するステップと、マッピング規則のセットに対する変更を解析するステップと、その後必要に応じて変更を伝播するステップとの、基本ステップを使用して、階層リソース・スペース内の任意の２つまたはそれ以上のリソース・オブジェクトにわたって（あるいは、異なるスペースにおける２つまたはそれ以上のリソースまたはコンテナ・オブジェクトにわたって）、こうした同期化が自動的に提供される。このようにして、複数のトランザクション接触ポイントにわたり、トランスペアレントな自動化様式で、ウェブ・サービス環境内で所与のポリシーが実施される。

もちろん、本発明は、より細密なレベルでポリシー（またはポリシー・インスタンス）を定義する階層リソース・スペース内で、実装可能である。図１８は、１つのこうした階層リソース・スペースを示す。このスペース内で、ルート１５００は、ＭＱキュー・コンテナ１５０２、ウェブ・アプリケーション・コンテナ１５０４、ウェブ・サービス・コンテナ１５０６、およびウェブ・サーバ・コンテナ１５０８という、子を有する。ＭＱキューはそれらを、リソース・オブジェクト１５１０および１５１２によって表されるような、キューＡおよびＢと関連付ける。ウェブ・アプリケーション・コンテナ１５０４はそれらを、リソース・オブジェクト１５１４および１５１６によって表されるような、アプリケーションＡおよびＢと関連付ける。ウェブ・サービス・コンテナ１５０６は、それらを他のサービス・コンテナ・オブジェクト１５１８と関連付け、これはそれらを、リソース・オブジェクト１５２０および１５２２によって表されるような、サービスＡおよびＢと関連付ける。最終的に、ウェブ・サーバ・コンテナ１５０８はそれらを、リソース・オブジェクト１５２４おおび１５２６によって表されるような、サーバＡおよびＢと関連付ける。したがってこの例では、複数のウェブ・サーバ／サービス／アプリケーション／キューなどが存在し、そのすべてを同じリソース・スペース内で導出することができる。さらに、図からわかるように、オブジェクト・スペースはツリー階層に基づくウェブ・サービス・トポロジの表現を提供する。図２０（図１５の単純なケースと同様）は、このより複雑なサービス・トポロジに関する代表的なトランザクション・フローを示し、１つまたは複数のトランザクションをリソースのセット全体にわたって呼び出すことができる方法を再度示している。たとえば図２０では、１つのトランザクション・フローがサーバＢ１６０２からウェブ・アプリケーションＢ１６０４を介し、サービスＢ１６０６を介し、キューＡ１６０８を介して進行する。本発明を使用すると、その後、１つまたは複数のポリシーまたはポリシー・インスタンスがオブジェクト・コンテナおよびリソース全体にわたって管理（すなわち同期化）される。

したがって、たとえば図１９に示されるように、サーバＢリソース・オブジェクト１５２６がそれらをサービス品質（ＱｏＳ）ポリシー１５２８と関連付けていること、およびアプリケーションＢリソース・オブジェクト１５１６がＱｏＳポリシー１５３０を有することを仮定してみる。本発明に従い、（図２０に示されるような）代表的なトランザクション・フローを見ると、前述の様式でＱｏＳポリシーを同期化するためにこれらのオブジェクト間に結合１５３２が提供される。

以上、本発明について、ウェブ・サーバ／アプリケーション／サービス／キューなどのリソース・オブジェクトに関連して説明してきたが、これは限定的なものではない。所与のリソース・オブジェクトまたはコンテナは、データベース・リソース、メインフレーム・リソース、アプリケーション・リソース（アクセス制御マネージャ、識別マネージャ、プロビジョニング（provisioning）マネージャ、ポリシー・マネージャ）、などを備えることができる。

前述の技法は、すべてのタイプのポリシーに適用可能である。特定のポリシーが実装される方法は、こうしたメカニズムおよびプロセスが当分野では周知であるため、本発明の範囲外である。したがって、たとえばＴｉｖｏｌｉＩｎｔｅｌｌｉｇｅｎｔＯｒｃｈｅｓｔｒａｔｏｒ／ＰｒｏｖｉｓｉｏｎｉｎｇＭａｎａｇｅｒなどの製品を使用して、階層リソース・スペース内の１つまたは複数のコンポーネントを「接触させる」（構成する）ことが可能であり、こうしたツールは、１つまたは複数のポリシーを定義、管理、および制御するために使用される。これまで説明してきたように、本発明はこうした製品／ツールを拡張し、ウェブ・サービス環境における１つまたは複数のトランザクション・リソース全体にわたって、ポリシーの同期化および自動調整を容易にするものである。通常、これらのポリシーは、前述の様式で、すなわち、階層リソース・スペースなどの視覚表現を介して１つまたは複数のマッピングを適用し、その後これをプログラムに基づいて実施することによって、調整される。周知のように、こうした表現は、インフラストラクチャ全体（またはその一部）に関するネットワーク・トポロジから、周知のツールを使用して生成可能である。

図２１は、保護オブジェクト・スペースの結合を定義するため、セキュリティ・ポリシーにおける変更を監視するため、および、必要に応じて保護オブジェクト・スペースを更新するために使用する、代表的なデータ処理システム１７００を示す。プログラム・コードの格納あるいは実行またはその両方に好適なデータ処理システム１７００は、システム・バス１７０５を介してメモリ要素と直接または間接的に結合された、少なくとも１つのプロセッサ１７０２を含むことになる。メモリ要素は、プログラム・コードの実際の実行中に使用されるローカル・メモリ１７０４と、大容量ストレージ１７０６と、実行中の大容量ストレージからコードを取り出さなければならない回数を減少させるために少なくとも一部のプログラム・コードの一時ストレージを提供する、キャッシュ・メモリ１７０８とを、含むことができる。入力／出力すなわちＩ／Ｏデバイス（キーボード１７１０、ディスプレイ１７１２、ポインティング・デバイス１７１４などを含むが、これらに限定されない）を、介在するＩ／Ｏコントローラ１７１６を通じて直接または間接的に、システムに結合することができる。データ処理システムを他のデータ処理システムまたはデバイスに結合できるようにするために、介在する専用または公衆ネットワーク１７２０を通じて、ネットワーク・アダプタ１７１８をシステムに結合することもできる。

本発明は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはハードウェアおよびソフトウェアの両方の要素を含む実施形態の形を取ることができる。好ましい実施形態では、発明の変形は、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されない、ソフトウェア内に実装される。さらに前述のように、本発明は、コンピュータまたは任意の命令実行システムによって、あるいはそれらに関連して使用するためのプログラム・コードを提供する、コンピュータ使用可能またはコンピュータ読み取り可能メディアからアクセス可能な、コンピュータ・プログラム製品の形を取ることができる。本説明のために、コンピュータ使用可能またはコンピュータ読み取り可能メディアは、命令実行のシステム、装置、またはデバイスによって、あるいはそれらに関連して使用するためのプログラムの包含、格納、通信、伝播、または移送が可能な、任意の装置とすることができる。メディアは、電子、磁気、光、電磁、赤外線、または半導体のシステム（あるいは装置またはデバイス）、あるいは伝播メディアとすることができる。コンピュータ読み取り可能メディアの例には、半導体またはソリッド・ステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛性磁気ディスク、および光ディスクが含まれる。光ディスクの現行の例には、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク読み取り／書き込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが含まれる。

前述の機能、すなわち、結合の定義、ポリシー更新の監視、および階層リソース・スペース全体にわたる変更の伝播のうちの、１つまたは複数は、サービスとして実装することもできる。

上記では、本発明の特定の実施形態によって実行される特定順序の操作について説明しているが、代替実施形態が異なる順序で操作を実行すること、特定の操作を組み合わせること、特定操作を重複させることなどが実行可能であるため、こうした順序は例示的なものであることを理解されたい。本明細書における所与の実施形態の参照は、説明された実施形態が特定の機能、構造、または特徴を含むことが可能であることを示すが、あらゆる実施形態が必ずしも特定の機能、構造、または特徴を含むとは限らない。

最終的に、システムの所与のコンポーネントについて、別々に説明してきたが、当業者であれば、所与の命令、プログラム・シーケンス、コード部分などで機能の一部を組み合わせるかまたは共有できることを理解されよう。

以上、発明者等の発明について説明してきたが、以下に特許請求の範囲を記載する。

Claims

ウェブ・サービス環境において同期化ポリシー制御を提供するための方法であって、
階層リソース・スペース内の第１のオブジェクト表現を監視するステップと、
前記第１のオブジェクト表現に関するポリシー規則における変更に応答して、前記変更を、前記階層リソース・スペース内の対応する第２のオブジェクトに関するポリシー規則に自動的に適用するステップと、
を含む、方法。
前記ポリシー規則が、
ａ）監査ポリシーと、
ｂ）サービス品質ポリシーと、
ｃ）サービス内容合意書（ＳＬＡ）ポリシーと、
ｄ）権利管理ポリシーと、
のうちの１つまたは複数に関連付けられる、請求項１に記載の方法。
前記第２のオブジェクト内のポリシー規則における変更に応答して、前記変更を前記第１のオブジェクトに選択的に再伝播するステップをさらに含む、請求項１または２に記載の方法。
前記階層リソース・スペース内の前記第１のオブジェクトを、前記階層リソース・スペース内の前記第２のオブジェクトに関連付ける、少なくとも１つのマッピングを定義するステップをさらに含む、請求項１、２、または３に記載の方法。
前記階層リソース・スペース内の前記第１および第２のオブジェクトのそれぞれが、ウェブ・サーバ・オブジェクト、ウェブ・サービス・オブジェクト、ウェブ・アプリケーション・オブジェクト、およびキュー・オブジェクトのうちの１つである、請求項４に記載の方法。
リソース・スペースの第１の部分および前記リソース・スペースの第２の部分と関連付けた、ウェブ・サービス環境においてポリシー制御を提供するための、コンピュータ実施方法であって、
前記リソース・スペースの前記第１の部分内のオブジェクトを、前記リソース・スペースの前記第２の部分内のオブジェクトにマッピングするステップと、
前記第１のオブジェクトに関連付けられた所与のポリシーに対する変更に応答して、前記変更を、前記第２のオブジェクトに関連付けられた所与のポリシーに自動的に適用するステップと、
を含む、コンピュータ実施方法。
前記ポリシーが、監査ポリシー、サービス品質ポリシー、サービス内容合意書（ＳＬＡ）ポリシー、ガバナンス・ポリシー、コンプライアンス・ポリシー、パッチ管理／脆弱性管理ポリシー、ユーザ管理ポリシー、および権利管理ポリシーのうちの１つである、請求項６に記載のコンピュータ実施方法。
前記リソース・スペースが階層状であり、前記マッピング・ステップが、前記階層リソース・スペース内で前記第１のオブジェクトを前記第２のオブジェクトに関連付ける、請求項６または７に記載のコンピュータ実施方法。
前記第２のオブジェクトに関連付けられた所与のポリシーに対する変更に応答して、前記変更を、前記第１のオブジェクトに関連付けられた所与のポリシーに選択的に適用するステップをさらに含む、請求項６、７、または８に記載のコンピュータ実施方法。
ウェブ・サービス環境において同期化制御を提供するためのコンピュータ実施方法であって、
第１のオブジェクト・スペース内のオブジェクトを第２のオブジェクト・スペース内のオブジェクトに関連付けるステップであって、前記第１のオブジェクト・スペースがウェブ・サービス表現に関連付けられ、前記第２のオブジェクト・スペースが前記ウェブ・サービスを実装するために必要なリソースに関連付けられた、関連付けるステップと、
オブジェクト属性に対する変更に関して前記第１のオブジェクト・スペースを監視するステップと、
オブジェクト属性に対する変更を検出すると、前記変更が前記第１のオブジェクト・スペース内の前記オブジェクトに関連付けられているかどうかを判別するステップと、
前記変更が前記第１のオブジェクト・スペース内の前記オブジェクトに関連付けられている場合、前記第１および第２のオブジェクト・スペースが引き続き同期化されるように、前記変更を前記第２のオブジェクト・スペース内の前記オブジェクトに伝播するステップと、
を含み、
オブジェクト属性に対する前記変更が、監査ポリシー、サービス品質ポリシー、サービス内容合意書（ＳＬＡ）ポリシー、ガバナンス・ポリシー、コンプライアンス・ポリシー、パッチ管理／脆弱性管理ポリシー、ユーザ管理ポリシー、および権利管理ポリシーのうちの１つと関連付けられる、コンピュータ実施方法。
階層リソース・スペースを有するウェブ・サービス環境において同期制御を提供するためのコンピュータ実施方法であって、
前記階層リソース・スペース内の所与のオブジェクトを関連付けるステップと、
少なくとも１つの所与のポリシーに関して、前記所与のオブジェクトの同期化を自動的に維持するステップと、
を含み、
前記所与のポリシーが、監査ポリシー、サービス品質ポリシー、サービス内容合意書（ＳＬＡ）ポリシー、ガバナンス・ポリシー、コンプライアンス・ポリシー、パッチ管理／脆弱性管理ポリシー、ユーザ管理ポリシー、および権利管理ポリシーのうちの１つである、コンピュータ実施方法。
コンピュータ読み取り可能プログラムを有するコンピュータ使用可能メディアを備えるコンピュータ・プログラムであって、前記コンピュータ読み取り可能プログラムは、コンピュータ上で実行された場合、
リソース・スペースを監視するステップと、
前記リソース・スペース内の第１のオブジェクトに関するポリシー制御規則における変更に応答して、前記変更を、前記リソース・スペース内の対応する第２のオブジェクトに関するポリシー制御規則に自動的に適用するステップと、
を、前記コンピュータに実行させ、
前記ポリシー規則が、監査ポリシー、サービス品質ポリシー、サービス内容合意書（ＳＬＡ）ポリシー、ガバナンス・ポリシー、コンプライアンス・ポリシー、パッチ管理／脆弱性管理ポリシー、ユーザ管理ポリシー、および権利管理ポリシーのうちの１つに関連付けられる、コンピュータ・プログラム。