(57)【要約】【課題】 構成管理のための新たな構成を使用することにより、ステイトフル・ウエブ・サービス環境におけるＩＴリソース構造を自動的に複製（クローン）するための方法、システム及びコンピュータ・プログラム製品を提供する。【解決手段】 この新たな手法は、各リソースの構成・ステイトをステイトフル・ウエブ・サービスとしてモデル化する。構成データは、このサービス・リソース・プロパティにより与えられる。異なる種々なリソースの構成相互間の関係は、ウエブ・サービス・インスタンス（データ）相互間の“ステイトフル・ウエブ・サービス関係”としてモデル化される。これらの関係は、誘導されることができ、これは、標準の方式で全体のシステムの構成を探求することを可能にする。更に、新たなウエブ・サービス・インターフェースが、リソースをカプセル化するステイトフル・ウエブ・サービスにより与えられる。このインターフェースは、２つの新たな動作を与える。即ち、“ゲットコンフィグレーション”は、開発者に、リソース及び関連するリソースの構成ステイトのスナップショットを取得させることができ、そして、“セットコンフィグレーション”は、リソースの構成ステイトを以前にセイブされたステイトにセットすることを可能にする。“ゲットコンフィグレーション”の発動は、各リソースの構成ステイトを記憶する新たなステイトフル・ウエブ・サービス・インスタンスの生成を生じる。この新たなウエブ・サービス・インターフェイスは、リソースの型毎に実装される。この新たなウエブ・サービス・インターフェイスを実装するために、任意のバック・エンド技術が使用されることができる。【選択図】図４
2009524860.tif 000002
【特許請求の範囲】
【請求項１】
現存するＩＴリソース構造の各リソースがステイトフル・ウエブ・サービスを介してアクセスされ、各ステイトフル・ウエブ・サービスが、割り当てられたリソースの構成ステイトを問い合わせするために、又は前記割り当てられたリソース上の動作をセット・アップするために、あるいは前記問い合わせ及び前記セット・アップの両方を行うために、リソースの型に固有のウエブ・サービスを提供し、各ステイトフル・ウエブ・サービス・インターフェースが動作“ゲットコンフィグレーション”及び“セットコンフィグレーション”を与えるインターフェイスを提供する、前記現存するＩＴリソース構造を自動的に複製する方法であって、
前記“ゲットコンフィグレーション”動作を使用して、他のリソースとの間である関係を有する各リソースの構成ステイトのスナップショットを取得して、そして各リソース毎に、前記構成ステイトを別個の“リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス”として記憶するステップと、
前記スナップショットを使用してグラフを自動的に作成するステップであって、前記グラフのノードが前記リソースコンフィグレーション・ステイトフル・ウエブ・サービスのインスタンスを表し、各リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが固有のリソースに対する構成データへのアクセスを与え、そして前記グラフのエッジが前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス相互間の関係を表す、前記ステップと、
前記グラフに基づいて新たなＩＴリソース構造を生成し、そして前記動作“セットコンフィグレーション”を使用して前記リソースコンフィグレーション・ステイトフル・ウエブ・サービスのインスタンスのそれぞれにより与えられた前記構成ステイトを前記新たなＩＴリソース構造のそれぞれのリソースに適用するステップとを含む前記方法。
【請求項２】
前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが割り当てられたプロパティ・リソース・タイプ、並びに前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが生成された日付及び時刻を同定するタイム・スタンプを与える、請求項１に記載の方法。
【請求項３】
前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが割り当てられたリソースの構成ステイトを表すリソース・タイプ固有のプロパティを与える、請求項２に記載の方法。
【請求項４】
前記スナップショットを得るステップ及び該スナップショットを使用してグラフを自動的に作成するステップが、
アドミニストレータにより同定されるルート・リソースで開始する上記ＩＴリソース構造をたどるステップと、
前記動作“ゲットコンフィグレーション”を使用して前記ルート・リソースに対するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成するステップと、
前記ルート・リソースの関連するリソースを調べ、そして関連するリソース毎にリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成するステップと、
上記関連するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを、上記ルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対してステイトフル・ウエブ・サービス関係に関連づけるステップと、
前記ＩＴリソース構造のリソース毎に前記ステップを繰り返すステップとを含む、請求項１に記載の方法。
【請求項５】
前記関連するリソースを調べるステップが、前記リソースをカプセル化するステイトフル・ウエブ・サービス間に存在するステイトフル・ウエブ・サービス関係を誘導することにより行われる、請求項４に記載の方法。
【請求項６】
新たなＩＴリソース構造を生成するステップが、
アドミニストレータにより同定されたルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスで開始するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフをたどるステップと、
割り当てられているリソースのタイプに対する前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを問い合わせるステップと、
リソース管理から前記タイプのリソースを要求するステップと、
前記動作“セットコンフィグレーション”を呼び出すことにより、前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶された構成ステイトを前記リソースに適用するステップと、
前記関連するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを調べるステップと、
前記関連するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス毎のリソースを要求し、そして、前記それぞれのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶されているそれぞれの構成を前記要求されたリソースに適用するステップとを含む、請求項１に記載の方法。
【請求項７】
前記動作“セットコンフィグレーション”が、前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのアドレスを入力パラメータとして取得して、前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶されている前記構成ステイトを読み出し、そしてこれをそれぞれのリソースに適用する、請求項５に記載の方法。
【請求項８】
前記ステイトフル・ウエブ・サービス・インスタンスが、エンドポイントリファレンスによりアドレスされる、請求項１に記載の方法。
【請求項９】
現存するＩＴリソース構造の各リソースがステイトフル・ウエブ・サービスを介してアクセスされ、各ステイトフル・ウエブ・サービスが、割り当てられたリソースの構成ステイトを問い合わせするために、又は前記割り当てられたリソース上の動作をセット・アップするために、あるいは前記問い合わせ及び前記セット・アップの両方を行うために、リソースの型に固有のウエブ・サービスを提供し、各ステイトフル・ウエブ・サービス・インターフェースが動作“ゲットコンフィグレーション”及び“セットコンフィグレーション”を与えるコンフィグレーション管理インターフェイスを提供する、前記現存するＩＴリソース構造を自動的に複製するシステムであって、
前記“ゲットコンフィグレーション”動作を使用して、他のリソースとの間である関係を有する各リソースの構成ステイトのスナップショットを取得する手段、及び各リソース毎に、前記構成ステイトを別個の“リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス”として記憶する手段と、
前記スナップショットを使用してグラフを自動的に作成する手段であって、前記グラフのノードが前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのインスタンスを表し、各リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが固有のリソースに対する構成データへのアクセスを与え、そして前記グラフのエッジが前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス相互間の関係を表す、前記手段と、
前記グラフに基づいて新たなＩＴリソース構造を生成し、そして前記動作“セットコンフィグレーション”を使用して前記リソースコンフィグレーション・ステイトフル・ウエブ・サービスのインスタンスのそれぞれにより与えられた前記構成ステイトを前記新たなＩＴリソース構造のそれぞれのリソースに適用する手段とを含む前記システム。
【請求項１０】
前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが割り当てられたプロパティ・リソース・タイプ、並びに前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが生成された日付及び時刻を同定するタイム・スタンプを与える、請求項９に記載のシステム。
【請求項１１】
前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが割り当てられたリソースの構成ステイトを表すリソース・タイプ固有のプロパティを与える、請求項１０に記載のシステム。
【請求項１２】
前記スナップショットを得る手段及び該スナップショットを使用してグラフを自動的に作成する手段が、
アドミニストレータにより同定されるルート・リソースで開始する上記ＩＴリソース構造をたどる手段と、
前記動作“ゲットコンフィグレーション”を使用して前記ルート・リソースに対するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成する手段と、
前記ルート・リソースの関連するリソースを調べ、そして関連するリソース毎にリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成する手段と、
上記関連するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを、上記ルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対してステイトフル・ウエブ・サービス関係に関連づける手段と、
前記ＩＴリソース構造のリソース毎に前記手段の動作を繰り返す手段とを含む、請求項９に記載のシステム。
【請求項１３】
新たなＩＴリソース構造を生成する手段が、
アドミニストレータにより同定されたルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスで開始するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフをたどる手段と、
割り当てられているリソースのタイプに対する前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを問い合わせる手段と、
リソース管理から前記タイプのリソースを要求する手段と、
前記動作“セットコンフィグレーション”を呼び出すことにより、前記リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶された構成ステイトを前記リソースに適用する手段と、
前記関連するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを調べる手段と、
前記関連するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス毎のリソースを要求し、そして、前記それぞれのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶されているそれぞれの構成を前記要求されたリソースに適用する手段とを含む、請求項９に記載のシステム。
【請求項１４】
コンピュータに請求項１乃至８のいずれか１つに記載のステップを実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース（資源）が、ステイトフル（通信状態を保持する）ウエブ・サービスとしてモデル化されるサービス指向のＩＴ（情報技術）リソース構造の分野に関し、更に具体的にいうならば、本発明は、現存するＩＴリソース環境を、これのリソースの接続形態（ｒｅｓｏｕｒｃｅ  ｔｏｐｏｌｏｇｙ）を維持しながら自動的に複製（クローニング、ｃｌｏｎｉｎｇ）するための方法、システム及びコンピュータ・プログラム製品に関する。
【背景技術】
【０００２】
今日のＩＴリソース構造は、多数の、異種で且つ分散されたリソースからなる。オン・デマンドのＩＴ構造を作り出すためのキーは、共通で且つ標準型のインターフェイスを介してこれらのリソースを管理するための手段を与え、そしてリソース相互間に標準的型のインターオペラビリティ（複数の異なるものを接続したり組み合わせて使用したときにきちんと全体として正しく動作すること）を与えることである。ウエブ・サービス・リソース・フレームワーク（ＷＳ−ＲＦ、ウエブ・サービスを使用してステイトフル・リソースにアクセスするための一連の使用を定義する）は、ウエブ・サービス・インターフェイスの背後に各種のリソース（資源）をカプセル化する技術である。特に、ＷＳ−ＲＦは、ＩＴリソースのステイトフルな特性に集中する。例えば、オペレイティング・システム・リソースのステイトは、システム内で現在動作中の処理の数、またはユーザによるログの数である。
【０００３】
ＷＳ−ＲＦに従うと、ＩＴ環境内の全てのステイトフル・リソースは、ウエブ・サービス・インターフェイスを介して管理される。即ち、クライアントは、ウエブ・サービスのエンド・ポイント上のウエブ・サービス・コールを呼び出し、次いでこれらは、特定なステイトフル・リソースにマップされる（図１参照）。仕様のＷＳ−ＲＦセット内で、ウエブ・サービス・ポートタイプの形の幾つかの標準のウエブ・サービス・インターフェースが規定され、これらは、ステイトフル・リソースのウエブ・サービス・フロント・エンドにより与えられる。これらの標準のポートタイプは、例えば、リソースの寿命管理、リソース・ステイトのクェリー（問い合わせ）、またはノーティフィケーション（通知）サポートに関係する。
【０００４】
ＷＳ−ＲＦで表現されたリソースのステイトは、いわゆるリソース・プロパティ（性質を表すデータ）に記憶される。特定なリソースに対する全てのリソース・プロパティの総和は、ＷＳ−ＲＦにより規定される標準のウエブ・サービス・コールを介して検索されることができるリソース・プロパティ・ドキュメントーＸＭＬに含まれる。
【０００５】
ＩＴリソース構造内の全てのリソースは、ＷＳ−リソース・フレームワークに従ってＷＳ−リソースとしてモデル化される。即ち、リソースは、ステイトフル・ウエブ・サービス・インターフェースの背後にカプセル化される。リソースは、例えば、コンピュータ若しくは記憶装置のような物理的なＩＴリソース、例えばオペレーティング・システム若しくはウエブ・サーバーのような論理的なソフトウエア・リソース、又は顧客の提示若しくは全体的なオン・デマンド・サービス環境のような論理的なビジネス指向のリソースを含むことができる（注、このようなオン・デマンド環境内のリソースは互いに関連されている）。これらの関係は、ステイトフル・ウエブ・サービス関係としてモデル化され、そしてこれは、この関係に加わる全てのステイトフル・ウエブ・サービスに対する参照を記憶する。これらの関係は誘導されることができる。従って、オン・デマンド環境は、グラフとしてみることができる。或る環境の最も一般的な形は、ツリー接続形態であり、これは、論理的なオン・デマンド・サービス（ＯＤＳ）リソースで始まる。この関係を介して、ツリーは、葉に対応する部分（最も一般的には物理的リソースである）まで辿る（ｔｒａｖｅｒｓｅ）ことができる。一般的に、オン・デマンド環境は、同方向性の関係及び循環的な関係を含む任意の接続形態を有することができる。又、このようなグラフは、適切なグラフ・アルゴリズムを使用して誘導されることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
初期の問題：
今日のＩＴ環境は、数十又は数百もの互いに異質なリソースがなっている。或る複雑なＩＴ環境を複製（ｃｌｏｎｅ）するためには、全体的なシステムの構成（コンフィグレーション）ステイト（即ち、システムの接続形態、使用されるリソースの数及びタイプ（型）、個々のリソースの構成ステイト、リソース相互間の関係等）を取得し、次いで、同様なレイアウトを備える或る等価的な等しいＩＴシステムを例示化するために、上記取得したデータを使用することが必要である。リソース型若しくはベンダ固有のインターフェースを介して個々のリソースの構成ステイトを管理することが可能であるけれども、共通な標準的なインターフェースを介して全体のシステムの構成を管理することは不可能である。ＩＴ環境は、異なるバック・エンド（ユーザに見えない後方にあるシステム）によりホストされている多数の互いに異なる型のリソースならなることができる。例えばＷＳ−ＲＦのような技術が、これらのバック・エンドと標準の方式で通信する手段を与えたとしても、構成管理の問題は、ＷＳ−ＲＦまたは他のステイトフル・ウエブ・サービスの仕様によりカバーされない。結果として、リソースの開発者は、リソース１件毎に構成管理を手動的に処理しなければならない。更に、個々のリソースの構成相互間の関係を管理する標準的な手段は、実現されていない。しかしながら、このような構成相互間の関係は、システムに亘る構成ビュー（コンフィギュレーショナル・ビュー）を与えるために要求される。
【０００７】
従来技術：
ＩＴリソース構造の最新の進展状況においては、リソース毎に構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）データをデータベースに記憶することが可能である。記憶されたデータは、リソースを規定されたステイトに戻すために使用されることができる。ソフトウエア・オブジェクトのステイト若しくはソフトウエア・オブジェクトの構成はそれぞれ、オブジェクト関係データベース内で持続的に維持されることができる。ＷＳ−ＲＦは、リソースのステイトを反映するためにリソース・プロパティの概念を導入する。或る特定なリソースの全てのリソース・プロパティの組み合わせは、いわゆるリソース・プロパティ・ドキュメントに含まれる。このＸＭＬドキュメントは、ウエブ・サービス・コールを使用して検索されることができ、そしてＸＭＬデータベースに記憶されることができる。
【０００８】
伝統的なＩＴ基盤において、個々のリソースの構成データを記憶しそしてリソースの構成を回復することは可能であるけれども、サービス指向のステイトフル・ウエブ・サービス環境において、全てのリソースに亘る構成の管理を達成する共通手段は現存していない。リソースのそれぞれの型は、適切な型特有の構成管理インターフェースを与える。ＷＳ−ＲＦに準拠するステイトフル・リソースに対するリソース・プロパティ・ドキュメント（ＲｅｓｏｕｒｃｅＰｒｏｐｅｒｔｙＤｏｃｕｍｅｎｎｔ）の概念は、構成管理に対する必要性に対して十分でない。第１に、このようなリソース・プロパティ・ドキュメントに含まれるデータは、リソースの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）に関連していない（例えば、コンピュータ・リソースのＣＰＵコアの温度特性は、これの構成に関連しておらず、現状の負荷又は周囲温度により影響される）。第２に、リソースの構成を反映するデータは、リソース・プロパティ・ドキュメントを介して露出されない。
【０００９】
更に、システムに亘る構成記録を形成するために個々のリソースの構成データを関連づける機構は現存しない。上述の全ての態様は、自動型に或るＩＴシステムの複製を可能にするために解決される必要がある。
【００１０】
本発明の目的：
本発明は、従来技術の不利点を排除した、サービス指向のステイトフル・ウエブ・サービス環境において現存するＩＴリソース構造を自動的に複製（クローン）するための方法、システム及びコンピュータ・プログラム製品を提供する。
【課題を解決するための手段】
【００１１】
本発明は、構成管理（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｍａｎａｇｅｍｅｎｔ）のための新たな構成を使用することにより、ステイトフル・ウエブ・サービス環境におけるＩＴリソース構造を自動的に複製（クローン）するための方法、システム及びコンピュータ・プログラム製品を提供する。
【００１２】
この新たな手法は、各リソースの構成・ステイトをステイトフル・ウエブ・サービスとしてモデル化する。構成データは、このサービス・リソース・プロパティにより与えられる。異なる種々なリソースの構成相互間の関係は、ウエブ・サービス・インスタンス（データ）相互間の“ステイトフル・ウエブ・サービス関係”としてモデル化される。これらの関係は、誘導される（ｎａｖｉｇａｔｅｄ）ことができ、これは、標準の方式で全体のシステムの構成を探求することを可能にする。
【００１３】
更に、新たなウエブ・サービス・インターフェースが、リソースをカプセル化するステイトフル・ウエブ・サービスにより与えられる。このインターフェースは、２つの新たな動作を与える。即ち、“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”は、開発者（ｅｘｐｌｏｉｔｅｒ）に、リソース及び関連するリソースの構成ステイトのスナップショットを取得させることができ、そして、“セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）は、リソースの構成ステイトを以前にセイブされたステイトにセットすることを可能にする。“ゲットコンフィグレーション”の発動は、各リソースの構成ステイトを記憶する新たなステイトフル・ウエブ・サービス・インスタンスの生成を生じる。この新たなウエブ・サービス・インターフェイスは、リソースの型毎に実装される。この新たなウエブ・サービス・インターフェイスを実装するために、任意のバック・エンド技術が使用されることができる。
【００１４】
本発明の上述の及び付加的な目的、特徴及び利点は、以下の詳細な説明において明らかになるであろう。
【００１５】
本発明の新規な特徴は添付の請求項に記載してある。しかしながら、本発明自体、好ましい仕様の態様、更なる目的及び本発明の利点は、図面と共に例示的な実施例についての以下の詳細な説明を参照することにより理解されるであろう。
【００１６】
本発明は、サービス指向アーキテクチャ（ＳＯＡ）の分野に関し、ここで、ＩＴリソースは、ステイトフル・ウエブ・サービスとしてモデル化される。即ち、これらは、ステイトフル・ウエブ・サービス・インターフェースの背後にカプセル化（ｅｎｃａｐｓｕｌａｔｅｄ）される。
【００１７】
リソースをステイトフル・ウエブ・サービスとしてモデル化するための共通のパターンが図１に示されている。ステイトフル・ウエブ・サービス（１）は、物理的又は論理的ＩＴリソース（２）に対するクライエント・フロント・エンドとして存在する。このステイトフル・サービス（１）は、例えばＷｅｂｓｐｈｅｒｅアプリケーション・サーバーのようなウエブ・サービス・コンテナ（５）によりホストされる。基礎をなすリソースを備えるステイトフル・サービスは、リソース・タイプに固有の通信プロトコル（３）（例えばＳＮＭＰ）を直接に支配し、又はこれは、リソースが直接的なインスツルメンテーションをサポートしていない場合にインスツルメンテーション・サーバー（４）によりリソースに接続する。
【００１８】
ステイトフル・ウエブ・サービス（１）はステイトフルであり、ここで、これは、基礎をなすリソースの現在のステイトを反映し、即ち、クライアントは何時でもリソースのステイトを問い合わせ又は変更でき、あるいはその両方を行うことができる。基礎をなすリソース（２）のステイトにアクセスするために、ステイトフル・サービス（１）は、（３）又は（４）を介してリソースと通信する。更に、ステイト・データは、アプリケーション・サーバー（５）に取り付けられているデータベース（６）に記憶されることができる。ステイトフル・サービス（１）は、例えば、Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ(R)  Ｂｅａｎｓ（ＥＪＢｓ）を使用してこのデータベースをアクセスすることができる。
【００１９】
クライアントは、例えばＨＴＴＰを介するＳＯＡＰのような標準のウエブ・サービス・プロトコル（８）を使用してステイトフル・ウエブ・サービスをアクセスすることができる。各ステイトフル・ウエブ・サービスは、クライアントにより呼び出されることができる１組の動作を提供する多数のリソースタイプに固有のウエブ・サービス・インターフェース（ポートタイプ）（９）を提供する。例えば、或る１つのサーバ・リソースをカプセル化する１つのステイトフル・ウエブ・サービスは、２つの動作“スタート・サーバー（ｓｔａｒｔＳｅｒｖｅｒ）”及び“ストップ・サーバー（ｓｔｏｐＳｅｒｖｅｒ）”をインターフェースに与える。更に、各ステイトフル・ウエブ・サービスは代表的には、インターフェイスに、リソース・ステイトの問い合わせをさせる、即ちいわゆるリソース・プロパティを検索させる。
【００２０】
説明中のモデリング・パターンは、汎用アーキテクチャ・パターンである。可能な実装の標準は、ウエブ・サービス・リソース・フレームワーク（ＷＳ−ＲＦ）の仕様のセット又はＷＳ−ＲＦのトップで立ち上がるウエブ・サービス分散（Ｄｉｓｔｒｉｂｕｔｅｄ）管理の仕様セットの形で存在する。
【００２１】
ステイトフル・サービスをアドレスするためのエンドポイント・リファレンス（応答を送るべき相手を示す）：
単純なＵＲＬによりアドレスされる標準の（ステイトレス（通信状態を保持しない））ウエブ・サービスとは対照的に、ステイトフル・ウエブ・サービスは、クライアントにステイトフル・ウエブ・サービスの特定なインスタンスをアドレスさせることができる更に高度なアドレス機構を要求する。
【００２２】
このアドレス機構は、エンドポイント・リファレンスを使用させ、そしてＷＳ−アドレッシング・スタンダードで指定される。このようなエンドポイント・リファレンスは、オブジェクト指向のプログラミング言語において使用されているようなオブジェクト・リファレンス若しくはポインターと比較されることができる。これは、ウエブ・サービス・エンドポイントの位置についての情報（ＵＲＬの形）、及びステイトフル・ウエブ・サービス・インプリメンテーション（実装）に、ウエブ・サービス・コールを或る特定なリソースにマップさせる追加の情報を含むエンティティである。エンドポイント・リファレンスを有するクライアントは、ステイトフル・サービスの特定なインスタンス又は特定なリソースとそれぞれ通信することができる。
【００２３】
図２に示す次のリソース構造は、本発明を詳細に説明する例である。オペレーティング・システム・リソース（１）は、アプリケーション・サーバー・アプリケーション（２）及びデータベース・アプリケーション（３）をホストする。矢印（４）及び（５）は、オペレーティング・システム（１）とアプリケーション（２）及びデータ・ベース（３）との間に存在する“ホスト”関係を示し、この関係は読み出され、“オペレーティング・システム（１）はアプリケーション・サーバー（２）をホストし、そして、“オペレーティング・システム（１）はデータ・ベース（３）をホストする。構成（コンフィグレーション）のコンテキストに関連する次のリソース・プロパティがリソースに規定される。
オペレーティング・システム（１）：
−  パッチレベル（ｐａｔｃｈＬｅｖｅｌ）（例えば、サービスパック（Ｓｅｒｖｉｃｅｐａｃｋ  １）
−  ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔｓ）
アプリケーション・サーバー・アプリケーション（２）：
−  セキュリティポリシイ（例えばイネーブル若しくはディスエーブルされたセキュリティＰｏｌｉｃｙ）
−  マックスコンカレントセッション（コンカレント・クライアント・セッションの最大数）
データベース・アプリケーション（３）：
−  キャッシングストラテジィ
−  コードセット  （例えば、ユニコード  ＵＴＦ−８）
【００２４】
上述のリソースのそれぞれは、ステイトフル・ウエブ・サービス（７）、（１０）及び（１３）によりクライアントに露出される。これらのステイトフル・サービスは、ウエブ・サーバー・コンテナとして働くアプリケーション・サーバー（６）によりホストされ、そしてリソースタイプ及びベンダー固有のリンク（１８）、（１９）及び（２０）を介して前記の各ＩＴリソースと通信する。更に、ステイトフル・ウエブ・サービスのステイト・データは、アプリケーション・サーバー（６）に取り付けられているデータベース（２１）に記憶されることができる。リソース（１）及び（２）の間の又はリソース（１）及び（３）の間の“ホスト”関係のそれぞれは、ステイトフル・ウエブ・サービス関係（１６）及び（１７）により反映される。これらのステイトフル・ウエブ・サービスをたどる（ｔｒａｖｅｒｓｅ）ことにより、ステイトフル・サービス（７）により（又は、（７）により表されるＩＴリソースにより）ホストされた全てのステイトフル・サービスを見出すことができる。ステイトフル・サービスのそれぞれは、リソースの型に固有のインターフェイス（９）、（１２）及び（１５）を与える。オペレーション・システム・サービス（７）に対して、インターフェイス（９）は、例えば、動作“スタート・アプリケーション・プロセス（ｓｔａｒｔＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓ）”又は“ストップアプリケーションプロセス（ｓｔｏｐＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓ）”からなる。アプリケーション・サーバー・サービス（１０）のインターフェイス（１２）は、例えば、“デプロイアプリケーション（ｄｅｐｌｏｙＡｐｐｌｉｃａｔｉｏｎ）”及び“アンデプロイアプリケーション（ｕｎｄｅｐｌｏｙＡｐｐｌｉｃａｔｉｏｎ）”を与える。データベース・サービス（１３）のインターフェイス（１５）は、動作“クリエイト・テーブル（ｃｒｅａｔｅＴａｂｌｅ）”及び“デリートテーブル（ｄｅｌｅｔｅＴａｂｌｅ）”を与える。
【００２５】
リソース・タイプの固有のインターフェースに加えて、各ステイトフル・ウエブ・サービスは又、本発明により提案された“構成管理”インターフェース（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｍｅｎｔ  ｉｎｔｅｒｆａｃｅ）（８）、（１１）及び（１４）を与える。このインターフェースは、２つの動作、即ち、“ゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）“及び”セットコンフィギュレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）“を提供する（ｏｆｆｅｒ）。オペレーティング・システム・サービスを指す（ポイントする）有効なエンドポイント・リファレンスを所有しているクライアント（２２）は、そのステイトフル・サービスのウエブ・サービス・コール（２３）を呼び出すことができる。更に、関係（１６）又は（１７）をたどる（ｔｒａｖｅｒｓｅ）ことにより、クライアントは、アプリケーション・サービス・サーバー又はデータベース・サービスのエンドポイント・リファレンスを得ることができ、そして、これらのリソースのステイトフル・ウエブ・サービス・コールを呼び出すことができる。
【００２６】
ＩＴリソース構造のコンフィグレーション（構成）・スナップショットの取得：
ＩＴリソース構造の構成（コンフィグレーション）（グラフでは、リソースの構成をノードとして含み、そしてこれらの構成相互間の関係をエッジとして含む）は、“構成管理”コンポーネント（２４）により制御される。このコンポーネントは、クライアントに、或る与えられたリソース構造の構成スナップショットの生成を開始させ、そして、それまでに得られた構成スナップショットに基づいてリソース構造を生成させる。
【００２７】
クライアント（２２）は、オペレーティング・システム・サービス／リソース（７）を指すエンドポイント・リファレンスを有する（注：表記“サービス／リソース”は、クライアントがサービス・フロント・エンドと通信しているが、論理的には、このサービスによりカプセル化されたリソース上で実際には動作していることを意味する）。これは、オペレーティング・システム・サービス／リソース（７）をアンカー・ノードとして有するリソース構造のコンフィグレーション・スナップショットを得ることを要求する。この要求（２５）は、ステイトフル・サービス（７）へのエンドポイント・リファレンスをパラメータとして有する。今や、構成管理（２４）は、与えられたエンドポイント・リファレンスを使用してサービス（７）の構成管理インターフェイス（８）をアクセスすることができる。これは、ウエブ・サービス・コール（２７）を生じることにより、オペレーティング・システム・サービス上のゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）動作を呼び出す。この動作の間に、新たな“リソースコンフィグレーション（ｒｅｓｏｕｒｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）ウエブ・サービス・インスタンス（３１）が生成され（２９）、これは、オペレーティング・システム・サービスの構成（コンフィグレーション）を作る全ての項目を記憶する。このリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスは、ウエブ・サービス・コンテナ（アプリケーション・サーバー）（３０）においてホストされる。コンフィグレーション・データ（構成データ）、即ち、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのプロパティは、アプリケーション・サーバーに備え付けられているデータベース（４３）に記憶される。例えば、このデータは、例えばＥｎｔｅｒｐｒｉｓｅ  Ｊａｖａ(R)  Ｂｅａｎｓ（ＥＪＢｓ）のような技術を使用してアクセスされることができる。アプリケーション・サーバー（３０）及び（６）は又同じでも良い。即ち、ＩＴリソースを表すステイトフル・サービス及びリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスの両方は、同じウエブ・サービス・コンテナによりホストされることができる。
【００２８】
新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）を指すエンドポイント・リファレンスは、構成管理に戻される（２８）。今や、構成管理（２４）は、ステイトフル・ウエブ・サービスをたどることにより、リソースの構造をたどる。関係（１６）をたどることにより、構成管理は、ステイトフル・サービス／リソース（１０）を見出す。これは、このサービスのゲットコンフィグレーション動作を呼び出し、そして、アプリケーション・サーバー・サービス／リソース（１０）に関連する全てのコンフィグレーション・データ（構成データ）を記憶する新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３４）へのエンドポイント・リファレンスを得る。リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３４）へのエンドポイント・リファレンスを受け取った後、構成管理は、２つのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）及び（３４）をステイトフル・ウエブ・サービスの関係（４０）に関連づける（ａｓｓｏｓｉａｔｅ）。このことは、これらそれぞれの構成間のある関係にあるリソース構造のリソース相互間に存在する関係を反映する。結果として、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフが生成され、これは、リソースのグラフと同じ接続形態（ｔｏｐｏｌｏｇｙ）を有する。
【００２９】
同じステップが、ステイトフル・サービス・リソース（１３）に対して繰り返される。即ち、サービス（１３）は、関係（１７）をたどることにより見出される。ゲットコンフィギュレーションが呼び出され、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３７）がサービス（１３）により生成され、（３７）のエンドポイント・リファレンスが構成管理に戻され、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）及び（３７）の間の関係（４１）が生成される。
【００３０】
コンフィギュレーション・スナップショットを得るプロセスの最後で、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフが存在し、これは、全体のソース・リソース構造のシステム構成（コンフィギュレーション）を表す。このグラフは、ノードとしての個別のリソースの構成及びエッジとしてのこれらの構成相互間の関係からなる。アンカー又はルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンスは、コンフィギュレーション・スナップショットを要求したクライアントに戻される（２６）。
【００３１】
リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス：
リソースのコンフィギュレーション（構成）・ステイトを表す構成データは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶される。これらのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスは、これらが異なる型のリソース毎に固有である構成データを記憶するのでリソースの型に固有である。リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスは、ゲットコンフィギュレーション動作の間に、ステイトフル・サービス（或るリソースを表す）により生成される。実装（インプリメンテーション）は、リソースの型に固有であり、そして、或る与えられた型（タイプ）のリソースに対するステイトフル・サービスの開発者（デベロッパー）によりに与えられなければならない。一般的に、この開発者は、どのような情報が、彼の型のリソースに対するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶される必要があるかを決定するための優れた知識を有している。リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶されたデータを或るリソース・インスタンスに適用させるセットコンフィギュレーション動作の実装は、それぞれの開発者から与えられなければならない。その理由は、開発者が、構成データを正しく適用するに必要な優れた知識を有するからである。
【００３２】
上述のように、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスは、リソースの型に固有である。しかしながら、本発明は、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのそれぞれにより与えられるべき最小のインターフェイス（動作の組及びプロパティの組）を提案する。このようなサービスのそれぞれは、少なくとも次のような２つのプロパティを有する。
−  ｒｅｓｏｕｒｃｅＴｙｐｅ（リソース・タイプ）：リソースコンフィギュレーション（ＲｅｓｏｕｒｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）が関連される（ａｓｓｏｃｉａｔｅｄ）リソースの型（タイプ）を同定し、この情報は、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフから或るクローン（複製）リソース構造を生成するときに必要とされる。リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス内に記憶された構成データは、ステイトされた（ステイトで特定された）型のリソースだけに適用される。
−  タイムスタンプ：リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが生成されたとき、即ち、コンフィグレーション・スナップショットが得られたときのデータ及び時刻を同定する。これは、同じステイトフル・リソース・インスタンスに対する幾つかのリソースコンフィグレーションを区別する。
【００３３】
更に、デフォルト・インターフェイスは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスの前記プロパティを検索する手段を与えなければならない。
【００３４】
図３に示すリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対して、このデフォルト・インターフェイスは、（３２）、（３５）及び（３８）として示されている。このインターフェイスは、コンフィグレーション・スナップショットを取得して、そしてこれに基づいて１つの複製（クローン）リソース構造を生成するために本発明により提案される。
【００３５】
更に、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのそれぞれは、図３に示すリソースタイプに固有のインターフェース（動作の組及びプロパティの組）（３３），（３６）及び（３９）を与える。このインターフェースにより与えられる動作の組及びプロパティの組は、リソース・デベロッパーにより決定される。オペレーティング・システム・サービス／リソース（７）に関連するリソース・コンフィグレーション（３１）に対して、例えば、タイプに固有のプロパティは、“パッチレベル（ｐａｔｃｈＬｅｖｅｌ）”及び“ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）”を含む。或る型（タイプ）のリソースに対するセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）動作は又、タイプに固有であり、そしてリソース・デベロッパーにより実装されるので、或るリソースをカプセル化するステイトフル・サービスの実装は、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスの型に固有の動作及びプロパティを知っており、その結果、これはこの情報で働きそしてこれをリソース・インスタンスに適用することができる。
【００３６】
例えば、オペレーティング・システム・ステイトフル・サービス上のセットコンフィグレーションを呼び出すとき、サービスは、構造データが、項目“パッチレベル（ｐａｔｃｈＬｅｂｅｌ）”及び項目”ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）“を含むことを知っており、そして、サービスは、これらの２つの項目をタイプ・オペレーティング・システムのリソースに如何に適用するかを知っている（例えば、パッチレベル・プロパティにより示された全てのパッチをインストールし、そしてユーザアカウント・プロパティにリストされている全てのユーザ・アカウントを生成する）。
【００３７】
以前に取得されたコンフィグレーション・スナップショットから複製（クローン）リソース構造を作り出す：
前項で説明したステップから、或るリソース構造のコンフィグレーション（構成）が取得された。この構成はグラフに記憶され、ここで、ノードは、個々のリソースの構成データを保持するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのインスタンスであり、そして、エッジは、これらの単一の構成相互間の関係であり、そして、元（オリジナル）のリソース構造のリソース相互間の関係を反映する。このコンフィグレーション（構成）グラフに基づいて、元のリソース構造の複製（クローン）と呼ばれる新たなリソース構造が生成されることができ、これは元のリソース構造と同じ構成（コンフィグレーション）及び接続形態（トポロジ）を有する。このプロセスが図４に示されている。クライアント（２２）は、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）へのエンドポイント・リファレンス（５０）を有し、これは、元のリソース構造の構成（コンフィグレーション）全体を表すリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフのアンカー又はルート・ノードである。全てのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが、ウエブ・サービス・コンテナ（３０）、即ちアプリケーション・サーバー内でホストされる。構成（コンフィグレーション）データは、アプリケーション・サーバーに備え付けられているデータベース（４３）に記憶され、そして例えばＥＪＢｓを使用してアクセスされることができる。
【００３８】
クライアントは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）を源とする構成（コンフィグレーション）グラフに含まれている情報に従って或るリソース構造を生成するために、構成管理（２４）に要求（５１）を出す。要求のパラメータは、リソース構造が生成されるべき場合、サービス（３１）のエンドポイント・リファレンス及びホスティング・インフラストラクチャ（基盤）（例えば、物理的及び論理的ＩＴリソースを備えるデータ・センター、リソース・レジストリィ、リソース・プール、リソース・ファクトリィ等）を含む。構成管理は、この構成を適用しようとしているリソースの型（タイプ）（例えばオペレーティング・システム）を知るために、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）に問い合わせる（５３）。この問い合わせは、各リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスにより実装されるデフォルトのリソースコンフィグレーション・インターフェイス（３２）に出される。リソースの型を得ると、構成管理は、ホスティング・インフラストラクチャ（基盤）における要求されたリソースのインスタンスを得ることができる（例えば、新たなリソースを生成し又はフリー・プールから１つのリソースを得る）。これは、ステイトフル・サービス／リソース（５５）の生成を表す矢印（５４）により示されている。
【００３９】
ホスティング・インフラストラクチャ（基盤）のレイアウト及びリソースがこのインフラストラクチャにより管理されるやり方は、本明細書の範囲外である。一般的には、このようなインフラストラクチャは、新たなリソース・インスタンス及び利用可能なリソースのプールを生成するためにリソース及びファクトリィを見出すための多数のレジスタを含む。更に、インフラストラクチャは、ＩＴリソースに対するステイトフル・ウエブ・サービス・フロント・エンド・インターフェースのためのコンテナとして働くウエブ・サービス・ホスティング環境（６６）（アプリケーション・サーバー）を含む。
【００４０】
タイプ・オペレーティング・システム・サーバーのステイトフル・サービス（５５）は、アプリケーション・サーバー（６６）によりホストされ、そして、エンドポイント・リファレンスを介してアドレス可能である。“実（ｒｅａｌ）”のＩＴリソース（６８）に対する通信リンク（７１）は、リソース上の動作を呼び出すために、又はステイト・データを問い合わせるために存在する。更に、ステイト・データは、データベース（６７）に記憶されることができる。
【００４１】
ステイトフル・サービス／リソース（５５）の生成の後に、構成管理は、サービス（５５）の構成管理インターフェ−ス（５６）上のセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）動作を呼び出す。リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）へのエンドポイント・リファレンスは、パラメータとして渡される。今や、オペレーティング・システム・サービス（５５）は、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）に記憶されている構成（コンフィグレーション）データを自分自身へ又はＩＴリソース（６８）にそれぞれ適用することができる（即ち、“パッチレベル（ｐａｔｃｈＬｅｖｅｌ）”構成項目により示されるオペレーティング・システム・パッチ及び“ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）“構成項目内にリストされている生成されたユーザーアカウントをインストールする）。こうするために、オペレーティング・システム・サービス（５５）は、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３１）のリソースタイプに固有のインターフェース（３３）上の動作を呼び出し、そしてリソース・タイプに固有のコンフィグレーション（構成）・オプションの全てを検索する。このことは図４の矢印（７５）により示されている。構成管理（２４）が、サービス／リソース（５５）を生成しそして構成した後に、これは、個々のコンフィグレーション（構成）相互間のステイトフル・ウエブ・サービス・リンクをたどることによりリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフをたどる。構成管理は、リンク（４０）をたどり、そしてリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３４）を見出す。再び、構成管理は、構成を適用するリソースの型（この例では”アプリケーション・サーバー・アプリケーション“）を知るために、デフォルト・インターフェース（３５）を使用する。次に、新たなステイトフル・サービス／リソース・インスタンス（５８）”アプリケーション・サーバー“が、ホスティング基盤上に生成される。次いで、構成管理（２４）は、サービス（５８）のコンフィグレーション管理インターフェース（５９）上のセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）を呼び出し、そしてエンドポイント・リファレンスをリソースコンフィギュレーション（３４）に渡す。サービス（５８）は、リソース・タイプに固有の構成データ（これは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３４）のリソースタイプに固有のインターフェース（３６）を介して得られる）を自分自身へ又は”実（ｒｅａｌ）“のＩＴリソース（６９）へ適用する。次のステップにおいて、構成管理は、サービス・リソース（５５）及び（５８）の両方をホスト関係（６４）に関連づける。このような関係の生成は、ステイトフル・ウエブ・サービス関係を使用する論理的に単純な生成であり、又はこれは、構成及びインストレーションステップを含むことができる。この例では、関係（６４）は、アプリケーション・サーバー・ソフトウエア（サーバー（５８）／リソース（６９）により表される）をオペレーティング・システム・イメージ（サービス（５５）／リソース（６８））にインストールすることにより生成されることができる。
【００４２】
今や、構成管理は、構成グラフをたどり続ける。これは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（３７）を見出し、新たなサービス／リソース（６１）を生成し、この新たなリソースに構成を適用し、そして、新たなリソース（この例では“データベース・ソフトウエア”）及び以前に生成したオペレーティング・システム・サービス／リソースの間の関係（６５）を設立する。このプロセスの最後に、元のリソース構造と同じ構成及び接続形態を有する新たなリソース構造が生成される。
【００４３】
一般的に、構造グラフに従う複製（クローン）リソース構造の生成は、この例で概略的に説明したほど単純ではない。本当のシナリオでは、インストレーション及び構成ステップを或る順番で実行することが通常必要である（例えば、リソースＢの前にリソースＡを生成し、リソースＡ及びＢを結合し（即ち、関係を生成し）、次いで、構成データをリソースＡ及びＢに適用する）。ホスティング基盤及びリソースについて達成されるべき動作（ａｃｔｉｏｎ）の正しい順序を見出すことは、アルゴリズムのプランニングに依存しそして本発明の範囲外である。
【００４４】
デプロイメント（Ｄｅｐｌｏｙｍｅｎｔ）の考察：
図には、３つの個別的なアプリケーション・サーバーが、ソース・リソース（ｓｏｕｒｃｅ  ｒｅｓｏｕｒｃｅ）構造のリソースをカプセル化するステイトフル・ウエブ・サービス、複製（クローン）リソース構造のリソース及びリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対するホスティング環境として示されている。このことは、ソース・システム、複製（クローン）システム及びリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスをホスティングするシステムが、異なる場所にある複数サイトにおいてデプロイ（ｄｅｐｌｏｙ，利用可能なように準備すること）され得ることを意味する。通信は、ネットワーク（できればインターネット）を介するウエブ・サービス・コールを使用してなされる。これは有効なシナリオであるけれども、全てのステイトフル・ウエブ・サービスが１つのサイト又は１つのアプリケーション・サーバーにおいてホストされることが可能である。
【００４５】
構成管理（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｒ）は、ホスティング雰囲気上で意味を有しない個別のスタンドアローン・エンティティ（データの集まり）として示されている。１つの可能性は、構成管理をアプリケーション・サーバーの１つにおけるステイトフル・サービスとしてデプロイすることである。更に、多数の構成管理（１つのサイトに１つ）を備えるデプロイメントのオプションを選択することもでき、ここで、１つの構成管理は、コンフィギュレーション・スナップショットを得るために使用され、他の構成管理は、複製（クローン）リソース構造を生成するために使用される。
【００４６】
本発明を説明する図１乃至図４に関して、本発明により提案される拡張は、（１）或るリソースをカプセル化するサービス上の２つの新たな動作及び（２）タイプ・リソースコンフィグレーションの新たなステイトフル・サービスを含むように説明される。
【００４７】
本明細書の次のパートにおいて、これらの２つの発明の拡張部についての更なる詳細を説明する。
【００４８】
或るリソースをカプセル化するステイトフル・サービスのインターフェースは、２つの動作、ゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィギュレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により拡張される。第１の動作は、コーラー即ち呼び出し者（ｃａｌｌｅｒ）にリソースの動作ステイトを検索させる。このステイトは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのインスタンスに記憶され（以下を参照）、このリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンスは、ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）動作により戻される。第２の動作、セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）動作は、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのエンドポイント・リファレンスを入力として得て、そしてこのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶されている構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｄａｔａ）をステイトフル・サービスによりカプセル化されているリソースに適用する。
【００４９】
前記２つの動作によるステイトフル・サービスの拡張（Ｅｘｔｅｎｄｉｎｇ）は下記を含む（リソース・デベロッパーとしてなされなければならない）：
（１） ２つの新たな動作、ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により、サービス・デスクリプション（ＷＳＤＬ，ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ）を拡張（ｅｃｔｅｎｄ）する。
（２） 必要なビジネス・メソッド（ｂｕｓｉｎｅｓｓ  ｍｅｔｈｏｄ）ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により、サービス・エンドポイント・インプリメンテーション（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）を拡張する。例えば、もしもサービスがＥＪＢステイトフル・セッション・ビーン（ｂｅａｎ）を使用して実装される（ｉｍｐｌｅｍｅｎｔｅｄ）ならば、ビーンは、この２つの名前を備える２つのパブリック・メソッド（ｐｕｂｌｉｃ  ｍｅｔｈｏｄ）により拡張されなければならない。
【００５０】
“ゲットコンフィグレーション”動作：
ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）の実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、下記のタスクを実行しなければならない。
−  カプセル化されたリソースの構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｄａｔａ）を記憶するためにリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスの新たなインスタンスを生成する。このことは、このリソースに対するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのステイトレス・ファクトリィ動作を呼び出すことにより行われる（下記参照）。新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンス（ＥＰＲ）が戻される。次いで、サービスは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスにデータを記憶するためにこのエンドポイント・リファレンス（ＥＰＲ）を使用することができる。
−  （リソース管理を介して）カプセル化されたリソースから構成データを取りだし、そしてこの構成データを新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶する。
−  及び／若しくは、サービスそれ自身のステイト・データから構成データを取り出し、そしてこれを新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶する。
−  及び／若しくは、１組の構成データ項目をプログラム的にコンパイルし、そしてこれを新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶する。
−  この新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（今や、これは複数リソースの全ての関連した構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｄａｔａ）を含んでいる）のＥＰＲをコーラー（ｃａｌｌｅｒ）に戻す。
【００５１】
セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）動作：
セットコンフィグレーション・データの実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、以下に概略化されたタスクを実行しなければならない。
−  この動作に対してパラメータとして渡されたＥＰＲを使用して、関連するリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスをコンタクトし、そしてこのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスから全ての構成データを検索する。
−  各構成データ項目を、カプセル化されたリソースに適用する。
＊リソースを構成（ｃｏｎｆｉｇｕｒｅ）するための適切なコマンドをリソース管理（ｒｅｓｏｕｒｃｅ  ｍａｎａｇｅｒ）上で実行する。
＊リソース管理を介して構成データをリソースに記憶する。
−  及び／若しくは、構成データを自分自身に適用する（即ち、ステイトフル・サービスはリソースをカプセル化する）−これはステイトフル・サービス自体の変更の結果生じる構成データのためのものであり、そしてカプセル化されたリソースとの相互作用を要求しない。
【００５２】
新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス：
リソース・デベロッパ（ｄｅｖｅｌｏｐｅｒ）により与えられるべき本発明の他の実施例は、各リソースのための構成データを記憶するためにリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対する実装人工事実（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ａｒｔｉｆａｃｔｓ）である。
【００５３】
これらの人工事実（ａｒｔｉｆａｃｔｓ）は、下記を含む。
−  リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス（ＷＳＤＬ）のサービス記述（ｓｅｒｖｉｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ）
−  リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対するウエブ・サービス（ＷＳ）エンドポイント（例えば、ＷＳルータ・サーブレット）
−  リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対するＷＳエンドポイント・インプリメンテーション（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）（実行されたコード）
【００５４】
エンドポイント・インプリメンテーションは、例えば、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのステイト・データを記憶するためにＥＪＢエントリィ・ビーンを使用するＥＪＢステイトレス・セッション・ビーンの形で与えられることができる。このような実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、ステイトフル・ウエブ・サービスに対する多くの可能性のうちのたった１つであることに注目されたい。
【００５５】
前記のように名付けられた人工事実の全ては、アプリケーション・サーバーにデプロイされる（ｄｅｐｌｏｙｅｄ）ことができるＥＡＲファイルにおいて互いにパッケージされることができる。クライアントの要求を受け取ると、サーバーは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに対するコードを実行することができる。リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスの１つの動作は、リソースコンフィグレーション・ステイトフル・ウエブ・サービスの新たなインスタンスをクライアントに生成させるステイトレス・ファクトリィ動作である。かくして、このファクトリィ動作により、リソースをカプセル化するステイトフル・サービスは、これの“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）動作（上記参照）内からリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成し、そしてこれの構成データを新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶することができる。
【００５６】
リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスの人工事実を含むＥＡＲファイルは、リソースをカプセル化するステイトフル・サービスを含むＥＡＲファイルを保持している同じアプリケーション・サーバー上でデプロイされることができる。この場合、ステイトフル・サービスは、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成するときにローカル・アプリケーションと対話する。代わりに、リソースコンフィグレーションＥＡＲファイルは、遠隔にあるアプリケーション・サーバー上でデプロイされることができる。リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスの結果的なアドレス（即ち、リソースコンフィグレーション  ＷＳ  エンドポイントの関連ＵＲＬと組み合わされた遠隔にあるサーバーのアドレス）は、リソースをカプセル化するステイトフル・サービスに知らされねばならない。
【００５７】
図５乃至図７を参照して、リソース構造を複製（クローニング）する本発明の方法の良好な実施例を詳細に説明する。本発明の方法は、次のような複数の処理ステップからなる。
リソース構造の構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）を得る（図５参照）、
リソース・コンフィグレーション・インスタンスを生成する（図６参照）、及び
構成グラフ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｇｒａｐｈ）からソース構造を生成する（図７参照）。
【００５８】
リソース構造の構成を得る詳細なフロー（図５参照）：
前提条件：
−  クライアントはワーキングＩＴ環境を有し、ここでリソースはリソース・グラフに組織化されている）。
−  クライアントは、リソースをカプセル化するステイトフル・ウエブ・サービスへのエンドポイント・リファレンスを介して、リソースをアクセスできる。
−  クライアントは、ルート・リソースへのＥＰＲを有する（即ち、グラフ内のリソースからす部手の他のリソースが、ステイトフル・ウエブ・サービス関係を考察（ｔｒａｖｅｒｓｅ）することにより見出されることができる）。
−  クライアントは、構成管理（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｒ）のアドレスを知っている。
フロー：
−  クライアントは、構成管理（ＣＭ，ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｍａｎａｇｅｒ）を呼び出し、固有のルート・リソースを源とするリソース・グラフのコンフィグレーション・スナップショット（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｓｎａｐｓｈｏｔ）を得る要求を出し；ルート・リソースのＥＰＲがパラメータとして渡される（ｐａｓｓｅｄ）。
−  構成管理（ＣＭ）は，ルート・リソース上の“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”を呼び出す。
−  リソースは、リソースに対する全ての構成データを記憶しているリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成する。
−  現在処理されているリソースがルート・リソースであるので、生成されたリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのＥＰＲは、一時的に記憶され、そして後にクライアントに戻される。
（このリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスは、ソース／リソース構造の全体の構造を表す構造のグラフのルート構造（ｒｏｏｔ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）となる）。
−  ＣＭは、関連するリソースに対するリソースを問い合わせる（これらの関連するリソースは、ステイトフル・ウエブ・サービス関係を介し見出されることができる）；関連するリソースの組は戻される。
−  もしも関連するリソースが見出されたならば、現在のリソースのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが一時的に記憶され、関連するリソース毎のリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが生成され（リソースの“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”動作を呼び出すことにより）、新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが、現在のリソースのリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスとの関係において関連づけられる。
このことが、各リソース及びこれに関連するリソース毎に繰り返される。
−  もしも複数のリソースの全体のグラフが考察され（ｔｒａｖｅｒｓｅｄ）そしてリソースのグラフと形態（ｔｏｐｏｌｏｇｙ）が同じであるリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフが生成されると、ルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのＥＰＲがクライアントに戻される。
【００５９】
事後条件：
−  この段階で、クライアントは、全体のシステム構成（ｓｙｓｔｅｍ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）を表すグラフの源となるルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
【００６０】
リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成する詳細なフロー（図６参照）：
前提条件：
−  ＩＴリソースは、ステイトフル・ウエブ・サービス・インスタンスによりカプセル化されている。
−  クライアントは、ステイトフル・ウエブ・サービス・インスタンスを介してリソースにアクセスする。
−  リソースの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、リソースに記憶されている構成データ、ステイトフル・ウエブ・サービスのステイト・データからなる。
−  リソースをカプセル化しているステイトフル・ウエブ・サービスは、リソースの構成データを記憶するために、タイプ（型）に固有のリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのアドレスを知っている。
フロー：
−  “ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”動作が呼び出される。
−  ステイトフル・ウエブ・サービスが、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのファクトリィ動作（ｆａｃｔｏｒｙ  ｏｐｅｒａｔｉｏｎ）を呼び出すことにより、新たなリソースのタイプに固有のリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成する。
−  新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのＥＰＲが一時的に記憶され、そして後にＣＭに戻される。
−  リソースをカプセル化しているステイトフル・ウエブ・サービスが、リソースの構成データを集める。
＊リソースから構成データを検索する。
＊ステイトフル・ウエブ・サービスのステイト自体に含まれている構成データを集める。
＊幾つかの構成データを“オン・ザ・フライ方式でコンパイルする（例えば、ターゲットのリソース上で後に実行され得る幾つかの構成スクリプト（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｓｃｒｉｐｔｓ）を生成する）。
−  構成データが、ウエブ・サービス・コールを介してリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶される。
−  新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのＥＰＲが、コーラー（呼び出し者、ｃａｌｌｅｒ）に戻される。
【００６１】
事後条件：
−  リソースの完全な構成ステイト（ｃｏｎｆｉｇｕｒａｔｉｏｎａｌ  ｓｔａｔｅ）を記憶している新たなリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが生成されている。
−  コーラー（ｃａｌｌｅｒ）は、このリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
【００６２】
構成グラフ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｇｒａｐｈ）からＩＴリソース構成を生成する詳細なフロー（図７）：
前提条件：
−  クライアントは、全体のシステム構成（ｓｙｓｔｅｍ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）を表すグラフの源となるルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
−  クライアントは、ターゲットのホスティング基盤（ｈｏｓｔｉｎｇ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に対する構成管理のアドレスを知っている、即ち、ホスティング基盤において、ターゲット・リソース構造が生成されるべきである（この構成管理及び基盤は、ソース・リソース構造と同じである）。
フロー：
−  クライアントが、ＣＭ（構成管理）を呼び出し、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフに記憶されている構成データに従ってリソース構造を生成することを要求する。ルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスへのＥＰＲがパラメータとして渡される。
−  ＣＭが、リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが関連するリソースのタイプ（型）を検索する。
−  ＣＭが、ホスティング基盤から適切なリソースの新たなインスタンスを要求する。
（例えば、ホスティング基盤が、リソース毎のフリー・プールを有し、プールは、ステイトフル・ウエブ・サービス・インターフェイスを有するＩＴリソースを含む（本発明の範囲外）。
−  ＣＭが、新たなリソースの“セットコンフィグレーション”を呼び出し、現在処理されつつあるリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのＥＰＲをリソースに渡す。
−  このリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスに記憶されている構成データがリソースに適用される。
−  ルート・リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスが処理されつつあるので、対応するルート・リソースのＥＰＲが一時的に記憶され、そして後にクライアントに戻される。
−  見出されたリソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス毎に、ホスティング基盤から適切なタイプのリソースが得られ、構成がこのリソースに適用され、そして、新たなリソースと最後に生成された（即ち、親）リソースとの間の関係が設立される。
このことが、各リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンス及びこれの関連する構成毎に繰り返される。
−  もしも構成のグラフがたどられ終え（ｔｒａｖｅｒｓｅｄ）そして構成グラフと同じ形態（ｔｏｐｏｌｏｇｙ）を有するリソースのグラフが生成され終えたならば、ルート・リソースのＥＰＲがクライアントに戻される。
【００６３】
事後条件：
−  リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスのグラフにより記述されているのと同じ形態（ｔｏｐｏｌｏｇｙ）及び構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）を備えるリソース構造が生成され終えている。
−  リート・リソースのＥＰＲがクライアントに戻される。
−  今や、クライアントは、新たなリソース構造を使用することができ、複数のリソースが、ＥＰＲによりアドレスされるステイトフル・ウエブ・サービスを介してアクセスされ、全てのリソースがルート・リソースで開始する複数の関係を考察（ｔｒａｖｅｒｓｅ）することにより見出されることができる。
【図面の簡単な説明】
【００６４】
【図１】ステイトフル・ウエブ・サービスとしての１つのリソースを示す図である。
【図２】本発明に従って複製（クローン）されるべきＩＴリソースの例を示す図である。
【図３】図２に示されているＩＴリソース構造の構成スナップショットを得るための本発明の方法を示す図である。
【図４】図３に示されている以前に得られた構成スナップショットから１つの複製（クローン）ＩＴリソース構造を作り出すための本発明の方法を示す図である。
【図５】構成スナップショットを得るための本発明の良好な実施例のフロー・チャートを示す図である。
【図６】リソースコンフィグレーション・ステイトフル・ウエブ・サービス・インスタンスを生成する本発明の良好な実施例のフロー・チャートを示す図である。
【図７】構成グラフからＩＴリソース構造を生成する本発明の良好な実施例のフロー・チャートを示す図である。
【符号の説明】
【００６５】
１  ステイトフル・ウエブ・サービス
２  ＩＴリソース
３  通信プロトコル
４  インスツルメント・サーバー
５  ウエブ・サービス・コンテナ
６  データベース
７  オペレーティング・システム・サービス／リソース
８  ウエブ・サービス・プロトコル
９  ウエブ・サービス・インターフェース
１０．１３  ステイフル・サービス
１１，１４  構成管理インターフェース
１２，１５  インターフェース
１６，１７  関係
１８，１９，２０  リンク
２１  データベース
２２  クライアント
２３  ウエブ・サービス・コール
２４  構成管理
【図１】
2009524860.tif 000003
【図２】
2009524860.tif 000004
【図３】
2009524860.tif 000005
【図４】
2009524860.tif 000006
【図５】
2009524860.tif 000007
【図６】
2009524860.tif 000008
【図７】
2009524860.tif 000009
【国際調査報告】
2009524860.tif 000010
2009524860.tif 000011