JP4620784B2 - 現存するｉｔリソース構造を自動的に複製する方法及びシステム - Google Patents
現存するｉｔリソース構造を自動的に複製する方法及びシステム Download PDFInfo
- Publication number
- JP4620784B2 JP4620784B2 JP2008551680A JP2008551680A JP4620784B2 JP 4620784 B2 JP4620784 B2 JP 4620784B2 JP 2008551680 A JP2008551680 A JP 2008551680A JP 2008551680 A JP2008551680 A JP 2008551680A JP 4620784 B2 JP4620784 B2 JP 4620784B2
- Authority
- JP
- Japan
- Prior art keywords
- resource
- configuration
- web service
- stateful web
- stateful
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000005516 engineering process Methods 0.000 abstract description 6
- 238000010367 cloning Methods 0.000 abstract description 4
- 238000007726 management method Methods 0.000 description 35
- 235000010627 Phaseolus vulgaris Nutrition 0.000 description 6
- 244000046052 Phaseolus vulgaris Species 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000003362 replicative effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 238000000547 structure data Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
- H04L41/0846—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on copy from other elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
- H04L41/0273—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
- Selective Calling Equipment (AREA)
Description
【技術分野】
【０００１】
本発明は、リソース（資源）が、ステートフル（通信状態を保持する）ウエブ・サービスとしてモデル化されるサービス指向のＩＴ（情報技術）リソース構造の分野に関し、更に具体的にいうならば、本発明は、現存するＩＴリソース環境を、これのリソースの接続形態（ｒｅｓｏｕｒｃｅ ｔｏｐｏｌｏｇｙ）を維持しながら自動的に複製（クローニング、ｃｌｏｎｉｎｇ）するための方法、システム及びコンピュータ・プログラム製品に関する。
【背景技術】
【０００２】
今日のＩＴリソース構造は、多数の、異種で且つ分散されたリソースからなる。オン・デマンドのＩＴ構造を作り出すためのキーは、共通で且つ標準型のインターフェイスを介してこれらのリソースを管理するための手段を与え、そしてリソース相互間に標準的型のインターオペラビリティ（複数の異なるものを接続したり組み合わせて使用したときにきちんと全体として正しく動作すること）を与えることである。ウエブ・サービス・リソース・フレームワーク（ＷＳ−ＲＦ、ウエブ・サービスを使用してステートフル・リソースにアクセスするための一連の使用を定義する）は、ウエブ・サービス・インターフェイスの背後に各種のリソース（資源）をカプセル化する技術である。特に、ＷＳ−ＲＦは、ＩＴリソースのステートフルな特性に集中する。例えば、オペレイティング・システム・リソースのステートは、システム内で現在動作中の処理の数、またはユーザによるログの数である。
【０００３】
ＷＳ−ＲＦに従うと、ＩＴ環境内の全てのステートフル・リソースは、ウエブ・サービス・インターフェイスを介して管理される。即ち、クライアントは、ウエブ・サービスのエンド・ポイント上のウエブ・サービス・コールを呼び出し、次いでこれらは、特定なステートフル・リソースにマップされる（図１参照）。仕様のＷＳ−ＲＦセット内で、ウエブ・サービス・ポートタイプの形の幾つかの標準のウエブ・サービス・インターフェースが規定され、これらは、ステートフル・リソースのウエブ・サービス・フロント・エンドにより与えられる。これらの標準のポートタイプは、例えば、リソースの寿命管理、リソース・ステートのクェリー（問い合わせ）、またはノーティフィケーション（通知）サポートに関係する。
【０００４】
ＷＳ−ＲＦで表現されたリソースのステートは、いわゆるリソース・プロパティ（性質を表すデータ）に記憶される。特定なリソースに対する全てのリソース・プロパティの総和は、ＷＳ−ＲＦにより規定される標準のウエブ・サービス・コールを介して検索されることができるリソース・プロパティ・ドキュメントーＸＭＬに含まれる。
【０００５】
ＩＴリソース構造内の全てのリソースは、ＷＳ−リソース・フレームワークに従ってＷＳ−リソースとしてモデル化される。即ち、リソースは、ステートフル・ウエブ・サービス・インターフェースの背後にカプセル化される。リソースは、例えば、コンピュータ若しくは記憶装置のような物理的なＩＴリソース、例えばオペレーティング・システム若しくはウエブ・サーバーのような論理的なソフトウエア・リソース、又は顧客の提示若しくは全体的なオン・デマンド・サービス環境のような論理的なビジネス指向のリソースを含むことができる（注、このようなオン・デマンド環境内のリソースは互いに関連されている）。これらの関係は、ステートフル・ウエブ・サービス関係としてモデル化され、そしてこれは、この関係に加わる全てのステートフル・ウエブ・サービスに対する参照を記憶する。これらの関係は誘導されることができる。従って、オン・デマンド環境は、グラフとしてみることができる。或る環境の最も一般的な形は、ツリー接続形態であり、これは、論理的なオン・デマンド・サービス（ＯＤＳ）リソースで始まる。この関係を介して、ツリーは、葉に対応する部分（最も一般的には物理的リソースである）まで辿る（ｔｒａｖｅｒｓｅ）ことができる。一般的に、オン・デマンド環境は、同方向性の関係及び循環的な関係を含む任意の接続形態を有することができる。又、このようなグラフは、適切なグラフ・アルゴリズムを使用して誘導されることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
初期の問題：
今日のＩＴ環境は、数十又は数百もの互いに異質なリソースがなっている。或る複雑なＩＴ環境を複製（ｃｌｏｎｅ）するためには、全体的なシステムの構成（コンフィグレーション）ステート（即ち、システムの接続形態、使用されるリソースの数及びタイプ（型）、個々のリソースの構成状態、リソース相互間の関係等）を取得し、次いで、同様なレイアウトを備える或る等価的な等しいＩＴシステムを例示化するために、上記取得したデータを使用することが必要である。リソース型若しくはベンダ固有のインターフェースを介して個々のリソースの構成状態を管理することが可能であるけれども、共通な標準的なインターフェースを介して全体のシステムの構成を管理することは不可能である。ＩＴ環境は、異なるバック・エンド（ユーザに見えない後方にあるシステム）によりホストされている多数の互いに異なる型のリソースならなることができる。例えばＷＳ−ＲＦのような技術が、これらのバック・エンドと標準の方式で通信する手段を与えたとしても、構成管理の問題は、ＷＳ−ＲＦまたは他のステートフル・ウエブ・サービスの仕様によりカバーされない。結果として、リソースの開発者は、リソース１件毎に構成管理を手動的に処理しなければならない。更に、個々のリソースの構成相互間の関係を管理する標準的な手段は、実現されていない。しかしながら、このような構成相互間の関係は、システムに亘る構成ビュー（コンフィギュレーショナル・ビュー）を与えるために要求される。
【０００７】
従来技術：
ＩＴリソース構造の最新の進展状況においては、リソース毎に構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）データをデータベースに記憶することが可能である。記憶されたデータは、リソースを規定されたステートに戻すために使用されることができる。ソフトウエア・オブジェクトのステート若しくはソフトウエア・オブジェクトの構成はそれぞれ、オブジェクト関係データベース内で持続的に維持されることができる。ＷＳ−ＲＦは、リソースのステートを反映するためにリソース・プロパティの概念を導入する。或る特定なリソースの全てのリソース・プロパティの組み合わせは、いわゆるリソース・プロパティ・ドキュメントに含まれる。このＸＭＬドキュメントは、ウエブ・サービス・コールを使用して検索されることができ、そしてＸＭＬデータベースに記憶されることができる。
【０００８】
伝統的なＩＴ基盤において、個々のリソースの構成データを記憶しそしてリソースの構成を回復することは可能であるけれども、サービス指向のステートフル・ウエブ・サービス環境において、全てのリソースに亘る構成の管理を達成する共通手段は現存していない。リソースのそれぞれの型は、適切な型特有の構成管理インターフェースを与える。ＷＳ−ＲＦに準拠するステートフル・リソースに対するリソース・プロパティ・ドキュメント（ＲｅｓｏｕｒｃｅＰｒｏｐｅｒｔｙＤｏｃｕｍｅｎｎｔ）の概念は、構成管理に対する必要性に対して十分でない。第１に、このようなリソース・プロパティ・ドキュメントに含まれるデータは、リソースの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）に関連していない（例えば、コンピュータ・リソースのＣＰＵコアの温度特性は、これの構成に関連しておらず、現状の負荷又は周囲温度により影響される）。第２に、リソースの構成を反映するデータは、リソース・プロパティ・ドキュメントを介して露出されない。
【０００９】
更に、システムに亘る構成記録を形成するために個々のリソースの構成データを関連づける機構は現存しない。上述の全ての態様は、自動型に或るＩＴシステムの複製を可能にするために解決される必要がある。
【００１０】
本発明の目的：
本発明は、従来技術の不利点を排除した、サービス指向のステートフル・ウエブ・サービス環境において現存するＩＴリソース構造を自動的に複製（クローン）するための方法、システム及びコンピュータ・プログラム製品を提供する。
【課題を解決するための手段】
【００１１】
本発明は、構成管理（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ）のための新たな構成を使用することにより、ステートフル・ウエブ・サービス環境におけるＩＴリソース構造を自動的に複製（クローン）するための方法、システム及びコンピュータ・プログラム製品を提供する。
【００１２】
この新たな手法は、各リソースの構成・ステートをステートフル・ウエブ・サービスとしてモデル化する。構成データは、このサービス・リソース・プロパティにより与えられる。異なる種々なリソースの構成相互間の関係は、ウエブ・サービス・インスタンス（データ）相互間の“ステートフル・ウエブ・サービス関係”としてモデル化される。これらの関係は、誘導される（ｎａｖｉｇａｔｅｄ）ことができ、これは、標準の方式で全体のシステムの構成を探求することを可能にする。
【００１３】
更に、新たなウエブ・サービス・インターフェースが、リソースをカプセル化するステートフル・ウエブ・サービスにより与えられる。このインターフェースは、２つの新たなオペレーションを与える。即ち、“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”は、開発者（ｅｘｐｌｏｉｔｅｒ）に、リソース及び関連するリソースの構成状態のスナップショットを取得させることができ、そして、“セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）は、リソースの構成状態を以前にセイブされたステートにセットすることを可能にする。“ゲットコンフィグレーション”の発動は、各リソースの構成状態を記憶する新たなステートフル・ウエブ・サービス・インスタンスの生成を生じる。この新たなウエブ・サービス・インターフェイスは、リソースの型毎に実装される。この新たなウエブ・サービス・インターフェイスを実装するために、任意のバック・エンド技術が使用されることができる。
【００１４】
本発明の上述の及び付加的な目的、特徴及び利点は、以下の詳細な説明において明らかになるであろう。
【００１５】
本発明の新規な特徴は添付の請求項に記載してある。しかしながら、本発明自体、好ましい仕様の態様、更なる目的及び本発明の利点は、図面と共に例示的な実施例についての以下の詳細な説明を参照することにより理解されるであろう。
【００１６】
本発明は、サービス指向アーキテクチャ（ＳＯＡ）の分野に関し、ここで、ＩＴリソースは、ステートフル・ウエブ・サービスとしてモデル化される。即ち、これらは、ステートフル・ウエブ・サービス・インターフェースの背後にカプセル化（ｅｎｃａｐｓｕｌａｔｅｄ）される。
【００１７】
リソースをステートフル・ウエブ・サービスとしてモデル化するための共通のパターンが図１に示されている。ステートフル・ウエブ・サービス（１）は、物理的又は論理的ＩＴリソース（２）に対するクライエント・フロント・エンドとして存在する。このステートフル・サービス（１）は、例えばＷｅｂｓｐｈｅｒｅアプリケーション・サーバーのようなウエブ・サービス・コンテナ（５）によりホストされる。基礎をなすリソースを備えるステートフル・サービスは、リソース・タイプに固有の通信プロトコル（３）（例えばＳＮＭＰ）を直接に支配し、又はこれは、リソースが直接的なインスツルメンテーションをサポートしていない場合にインスツルメンテーション・サーバー（４）によりリソースに接続する。
【００１８】
ステートフル・ウエブ・サービス（１）はステートフルであり、ここで、これは、基礎をなすリソースの現在のステートを反映し、即ち、クライアントは何時でもリソースのステートを問い合わせ又は変更でき、あるいはその両方を行うことができる。基礎をなすリソース（２）のステートにアクセスするために、ステートフル・サービス（１）は、（３）又は（４）を介してリソースと通信する。更に、ステート・データは、アプリケーション・サーバー（５）に取り付けられているデータベース（６）に記憶されることができる。ステートフル・サービス（１）は、例えば、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ(R) Ｂｅａｎｓ（ＥＪＢｓ）を使用してこのデータベースをアクセスすることができる。
【００１９】
クライアントは、例えばＨＴＴＰを介するＳＯＡＰのような標準のウエブ・サービス・プロトコル（８）を使用してステートフル・ウエブ・サービスをアクセスすることができる。各ステートフル・ウエブ・サービスは、クライアントにより呼び出されることができる１組のオペレーションを提供する多数のリソースタイプに固有のウエブ・サービス・インターフェース（ポートタイプ）（９）を提供する。例えば、或る１つのサーバ・リソースをカプセル化する１つのステートフル・ウエブ・サービスは、２つのオペレーション“スタート・サーバー（ｓｔａｒｔＳｅｒｖｅｒ）”及び“ストップ・サーバー（ｓｔｏｐＳｅｒｖｅｒ）”をインターフェースに与える。更に、各ステートフル・ウエブ・サービスは代表的には、インターフェイスに、リソース・ステートの問い合わせをさせる、即ちいわゆるリソース・プロパティを検索させる。
【００２０】
説明中のモデリング・パターンは、汎用アーキテクチャ・パターンである。可能な実装の標準は、ウエブ・サービス・リソース・フレームワーク（ＷＳ−ＲＦ）の仕様のセット又はＷＳ−ＲＦのトップで立ち上がるウエブ・サービス分散（Ｄｉｓｔｒｉｂｕｔｅｄ）管理の仕様セットの形で存在する。
【００２１】
ステートフル・サービスをアドレスするためのエンドポイント・リファレンス（応答を送るべき相手を示す）：
単純なＵＲＬによりアドレスされる標準の（ステートレス（通信状態を保持しない））ウエブ・サービスとは対照的に、ステートフル・ウエブ・サービスは、クライアントにステートフル・ウエブ・サービスの特定なインスタンスをアドレスさせることができる更に高度なアドレス機構を要求する。
【００２２】
このアドレス機構は、エンドポイント・リファレンスを使用させ、そしてＷＳ−アドレッシング・スタンダードで指定される。このようなエンドポイント・リファレンスは、オブジェクト指向のプログラミング言語において使用されているようなオブジェクト・リファレンス若しくはポインターと比較されることができる。これは、ウエブ・サービス・エンドポイントの位置についての情報（ＵＲＬの形）、及びステートフル・ウエブ・サービス・インプリメンテーション（実装）に、ウエブ・サービス・コールを或る特定なリソースにマップさせる追加の情報を含むエンティティである。エンドポイント・リファレンスを有するクライアントは、ステートフル・サービスの特定なインスタンス又は特定なリソースとそれぞれ通信することができる。
【００２３】
図２に示す次のリソース構造は、本発明を詳細に説明する例である。オペレーティング・システム・リソース（１）は、アプリケーション・サーバー・アプリケーション（２）及びデータベース・アプリケーション（３）をホストする。矢印（４）及び（５）は、オペレーティング・システム（１）とアプリケーション（２）及びデータ・ベース（３）との間に存在する“ホスト”関係を示し、この関係は読み出され、“オペレーティング・システム（１）はアプリケーション・サーバー（２）をホストし、そして、“オペレーティング・システム（１）はデータ・ベース（３）をホストする。構成（コンフィグレーション）のコンテキストに関連する次のリソース・プロパティがリソースに規定される。
オペレーティング・システム（１）：
− パッチレベル（ｐａｔｃｈＬｅｖｅｌ）（例えば、サービスパック（Ｓｅｒｖｉｃｅｐａｃｋ １）
− ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔｓ）
アプリケーション・サーバー・アプリケーション（２）：
− セキュリティポリシイ（例えばイネーブル若しくはディスエーブルされたセキュリティＰｏｌｉｃｙ）
− マックスコンカレントセッション（コンカレント・クライアント・セッションの最大数）
データベース・アプリケーション（３）：
− キャッシングストラテジィ
− コードセット （例えば、ユニコード ＵＴＦ−８）
【００２４】
上述のリソースのそれぞれは、ステートフル・ウエブ・サービス（７）、（１０）及び（１３）によりクライアントに露出される。これらのステートフル・サービスは、ウエブ・サーバー・コンテナとして働くアプリケーション・サーバー（６）によりホストされ、そしてリソースタイプ及びベンダー固有のリンク（１８）、（１９）及び（２０）を介して前記の各ＩＴリソースと通信する。更に、ステートフル・ウエブ・サービスのステート・データは、アプリケーション・サーバー（６）に取り付けられているデータベース（２１）に記憶されることができる。リソース（１）及び（２）の間の又はリソース（１）及び（３）の間の“ホスト”関係のそれぞれは、ステートフル・ウエブ・サービス関係（１６）及び（１７）により反映される。これらのステートフル・ウエブ・サービスをたどる（ｔｒａｖｅｒｓｅ）ことにより、ステートフル・サービス（７）により（又は、（７）により表されるＩＴリソースにより）ホストされた全てのステートフル・サービスを見出すことができる。ステートフル・サービスのそれぞれは、リソースの型に固有のインターフェイス（９）、（１２）及び（１５）を与える。オペレーション・システム・サービス（７）に対して、インターフェイス（９）は、例えば、オペレーション“スタート・アプリケーション・プロセス（ｓｔａｒｔＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓ）”又は“ストップアプリケーションプロセス（ｓｔｏｐＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓ）”からなる。アプリケーション・サーバー・サービス（１０）のインターフェイス（１２）は、例えば、“デプロイアプリケーション（ｄｅｐｌｏｙＡｐｐｌｉｃａｔｉｏｎ）”及び“アンデプロイアプリケーション（ｕｎｄｅｐｌｏｙＡｐｐｌｉｃａｔｉｏｎ）”を与える。データベース・サービス（１３）のインターフェイス（１５）は、オペレーション“クリエイト・テーブル（ｃｒｅａｔｅＴａｂｌｅ）”及び“デリートテーブル（ｄｅｌｅｔｅＴａｂｌｅ）”を与える。
【００２５】
リソース・タイプの固有のインターフェースに加えて、各ステートフル・ウエブ・サービスは又、本発明により提案された“構成管理”インターフェース（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｍｅｎｔ ｉｎｔｅｒｆａｃｅ）（８）、（１１）及び（１４）を与える。このインターフェースは、２つのオペレーション、即ち、“ゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）“及び”セットコンフィギュレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）“を提供する（ｏｆｆｅｒ）。オペレーティング・システム・サービスを指す（ポイントする）有効なエンドポイント・リファレンスを所有しているクライアント（２２）は、そのステートフル・サービスのウエブ・サービス・コール（２３）を呼び出すことができる。更に、関係（１６）又は（１７）をたどる（ｔｒａｖｅｒｓｅ）ことにより、クライアントは、アプリケーション・サービス・サーバー又はデータベース・サービスのエンドポイント・リファレンスを得ることができ、そして、これらのリソースのステートフル・ウエブ・サービス・コールを呼び出すことができる。
【００２６】
ＩＴリソース構造のコンフィグレーション（構成）・スナップショットの取得：
ＩＴリソース構造の構成（コンフィグレーション）（グラフでは、リソースの構成をノードとして含み、そしてこれらの構成相互間の関係をエッジとして含む）は、“構成管理”コンポーネント（２４）により制御される。このコンポーネントは、クライアントに、或る与えられたリソース構造の構成スナップショットの生成を開始させ、そして、それまでに得られた構成スナップショットに基づいてリソース構造を生成させる。
【００２７】
クライアント（２２）は、オペレーティング・システム・サービス／リソース（７）を指すエンドポイント・リファレンスを有する（注：表記“サービス／リソース”は、クライアントがサービス・フロント・エンドと通信しているが、論理的には、このサービスによりカプセル化されたリソース上で実際にはオペレーションしていることを意味する）。これは、オペレーティング・システム・サービス／リソース（７）をアンカー・ノードとして有するリソース構造のコンフィグレーション・スナップショットを得ることを要求する。この要求（２５）は、ステートフル・サービス（７）へのエンドポイント・リファレンスをパラメータとして有する。今や、構成管理（２４）は、与えられたエンドポイント・リファレンスを使用してサービス（７）の構成管理インターフェイス（８）をアクセスすることができる。これは、ウエブ・サービス・コール（２７）を生じることにより、オペレーティング・システム・サービス上のゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションを呼び出す。このオペレーションの間に、新たな“リソースコンフィグレーション（ｒｅｓｏｕｒｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）ウエブ・サービス・インスタンス（３１）が生成され（２９）、これは、オペレーティング・システム・サービスの構成（コンフィグレーション）を作る全ての項目を記憶する。このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、ウエブ・サービス・コンテナ（アプリケーション・サーバー）（３０）においてホストされる。コンフィグレーション・データ（構成データ）、即ち、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのプロパティは、アプリケーション・サーバーに備え付けられているデータベース（４３）に記憶される。例えば、このデータは、例えばＥｎｔｅｒｐｒｉｓｅ Ｊａｖａ(R) Ｂｅａｎｓ（ＥＪＢｓ）のような技術を使用してアクセスされることができる。アプリケーション・サーバー（３０）及び（６）は又同じでも良い。即ち、ＩＴリソースを表すステートフル・サービス及びリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの両方は、同じウエブ・サービス・コンテナによりホストされることができる。
【００２８】
新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）を指すエンドポイント・リファレンスは、構成管理に戻される（２８）。今や、構成管理（２４）は、ステートフル・ウエブ・サービスをたどることにより、リソースの構造をたどる。関係（１６）をたどることにより、構成管理は、ステートフル・サービス／リソース（１０）を見出す。これは、このサービスのゲットコンフィグレーションオペレーションを呼び出し、そして、アプリケーション・サーバー・サービス／リソース（１０）に関連する全てのコンフィグレーション・データ（構成データ）を記憶する新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）へのエンドポイント・リファレンスを得る。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）へのエンドポイント・リファレンスを受け取った後、構成管理は、２つのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）及び（３４）をステートフル・ウエブ・サービスの関係（４０）に関連づける（ａｓｓｏｓｉａｔｅ）。このことは、これらそれぞれの構成間のある関係にあるリソース構造のリソース相互間に存在する関係を反映する。結果として、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフが生成され、これは、リソースのグラフと同じ接続形態（ｔｏｐｏｌｏｇｙ）を有する。
【００２９】
同じステップが、ステートフル・サービス・リソース（１３）に対して繰り返される。即ち、サービス（１３）は、関係（１７）をたどることにより見出される。ゲットコンフィギュレーションが呼び出され、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３７）がサービス（１３）により生成され、（３７）のエンドポイント・リファレンスが構成管理に戻され、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）及び（３７）の間の関係（４１）が生成される。
【００３０】
コンフィギュレーション・スナップショットを得るプロセスの最後で、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフが存在し、これは、全体のソース・リソース構造のシステム構成（コンフィギュレーション）を表す。このグラフは、ノードとしての個別のリソースの構成及びエッジとしてのこれらの構成相互間の関係からなる。アンカー又はルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンスは、コンフィギュレーション・スナップショットを要求したクライアントに戻される（２６）。
【００３１】
リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス：
リソースのコンフィギュレーション（構成）・ステートを表す構成データは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶される。これらのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、これらが異なる型のリソース毎に固有である構成データを記憶するのでリソースの型に固有である。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、ゲットコンフィギュレーション・オペレーションの間に、ステートフル・サービス（或るリソースを表す）により生成される。実装（インプリメンテーション）は、リソースの型に固有であり、そして、或る与えられた型（タイプ）のリソースに対するステートフル・サービスの開発者（デベロッパー）によりに与えられなければならない。一般的に、この開発者は、どのような情報が、彼の型のリソースに対するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶される必要があるかを決定するための優れた知識を有している。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されたデータを或るリソース・インスタンスに適用させるセットコンフィギュレーションオペレーションの実装は、それぞれの開発者から与えられなければならない。その理由は、開発者が、構成データを正しく適用するに必要な優れた知識を有するからである。
【００３２】
上述のように、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、リソースの型に固有である。しかしながら、本発明は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのそれぞれにより与えられるべき最小のインターフェイス（オペレーションの組及びプロパティの組）を提案する。このようなサービスのそれぞれは、少なくとも次のような２つのプロパティを有する。
− ｒｅｓｏｕｒｃｅＴｙｐｅ（リソース・タイプ）：リソースコンフィギュレーション（ＲｅｓｏｕｒｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）が関連される（ａｓｓｏｃｉａｔｅｄ）リソースの型（タイプ）を特定し、この情報は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフから或るクローン（複製）リソース構造を生成するときに必要とされる。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス内に記憶された構成データは、ステートされた（ステートで特定された）型のリソースだけに適用される。
− タイムスタンプ：リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成されたとき、即ち、コンフィグレーション・スナップショットが得られたときのデータ及び時刻を特定する。これは、同じステートフル・リソース・インスタンスに対する幾つかのリソースコンフィグレーションを区別する。
【００３３】
更に、デフォルト・インターフェイスは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの前記プロパティを検索する手段を与えなければならない。
【００３４】
図３に示すリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対して、このデフォルト・インターフェイスは、（３２）、（３５）及び（３８）として示されている。このインターフェイスは、コンフィグレーション・スナップショットを取得して、そしてこれに基づいて１つの複製（クローン）リソース構造を生成するために本発明により提案される。
【００３５】
更に、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのそれぞれは、図３に示すリソースタイプに固有のインターフェース（オペレーションの組及びプロパティの組）（３３），（３６）及び（３９）を与える。このインターフェースにより与えられるオペレーションの組及びプロパティの組は、リソース・デベロッパーにより決定される。オペレーティング・システム・サービス／リソース（７）に関連するリソース・コンフィグレーション（３１）に対して、例えば、タイプに固有のプロパティは、“パッチレベル（ｐａｔｃｈＬｅｖｅｌ）”及び“ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）”を含む。或る型（タイプ）のリソースに対するセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションは又、タイプに固有であり、そしてリソース・デベロッパーにより実装されるので、或るリソースをカプセル化するステートフル・サービスの実装は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの型に固有のオペレーション及びプロパティを知っており、その結果、これはこの情報で働きそしてこれをリソース・インスタンスに適用することができる。
【００３６】
例えば、オペレーティング・システム・ステートフル・サービス上のセットコンフィグレーションを呼び出すとき、サービスは、構造データが、項目“パッチレベル（ｐａｔｃｈＬｅｂｅｌ）”及び項目”ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）“を含むことを知っており、そして、サービスは、これらの２つの項目をタイプ・オペレーティング・システムのリソースに如何に適用するかを知っている（例えば、パッチレベル・プロパティにより示された全てのパッチをインストールし、そしてユーザアカウント・プロパティにリストされている全てのユーザ・アカウントを生成する）。
【００３７】
以前に取得されたコンフィグレーション・スナップショットから複製（クローン）リソース構造を作り出す：
前項で説明したステップから、或るリソース構造のコンフィグレーション（構成）が取得された。この構成はグラフに記憶され、ここで、ノードは、個々のリソースの構成データを保持するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのインスタンスであり、そして、エッジは、これらの単一の構成相互間の関係であり、そして、元（オリジナル）のリソース構造のリソース相互間の関係を反映する。このコンフィグレーション（構成）グラフに基づいて、元のリソース構造の複製（クローン）と呼ばれる新たなリソース構造が生成されることができ、これは元のリソース構造と同じ構成（コンフィグレーション）及び接続形態（トポロジ）を有する。このプロセスが図４に示されている。クライアント（２２）は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）へのエンドポイント・リファレンス（５０）を有し、これは、元のリソース構造の構成（コンフィグレーション）全体を表すリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフのアンカー又はルート・ノードである。全てのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、ウエブ・サービス・コンテナ（３０）、即ちアプリケーション・サーバー内でホストされる。構成（コンフィグレーション）データは、アプリケーション・サーバーに備え付けられているデータベース（４３）に記憶され、そして例えばＥＪＢｓを使用してアクセスされることができる。
【００３８】
クライアントは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）を源とする構成（コンフィグレーション）グラフに含まれている情報に従って或るリソース構造を生成するために、構成管理（２４）に要求（５１）を出す。要求のパラメータは、リソース構造が生成されるべき場合、サービス（３１）のエンドポイント・リファレンス及びホスティング・インフラストラクチャ（基盤）（例えば、物理的及び論理的ＩＴリソースを備えるデータ・センター、リソース・レジストリィ、リソース・プール、リソース・ファクトリィ等）を含む。構成管理は、この構成を適用しようとしているリソースの型（タイプ）（例えばオペレーティング・システム）を知るために、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）に問い合わせる（５３）。この問い合わせは、各リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスにより実装されるデフォルトのリソースコンフィグレーション・インターフェイス（３２）に出される。リソースの型を得ると、構成管理は、ホスティング・インフラストラクチャ（基盤）における要求されたリソースのインスタンスを得ることができる（例えば、新たなリソースを生成し又はフリー・プールから１つのリソースを得る）。これは、ステートフル・サービス／リソース（５５）の生成を表す矢印（５４）により示されている。
【００３９】
ホスティング・インフラストラクチャ（基盤）のレイアウト及びリソースがこのインフラストラクチャにより管理されるやり方は、本明細書の範囲外である。一般的には、このようなインフラストラクチャは、新たなリソース・インスタンス及び利用可能なリソースのプールを生成するためにリソース及びファクトリィを見出すための多数のレジスタを含む。更に、インフラストラクチャは、ＩＴリソースに対するステートフル・ウエブ・サービス・フロント・エンド・インターフェースのためのコンテナとして働くウエブ・サービス・ホスティング環境（６６）（アプリケーション・サーバー）を含む。
【００４０】
タイプ・オペレーティング・システム・サーバーのステートフル・サービス（５５）は、アプリケーション・サーバー（６６）によりホストされ、そして、エンドポイント・リファレンスを介してアドレス可能である。“実（ｒｅａｌ）”のＩＴリソース（６８）に対する通信リンク（７１）は、リソース上のオペレーションを呼び出すために、又はステート・データを問い合わせるために存在する。更に、ステート・データは、データベース（６７）に記憶されることができる。
【００４１】
ステートフル・サービス／リソース（５５）の生成の後に、構成管理は、サービス（５５）の構成管理インターフェ−ス（５６）上のセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションを呼び出す。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）へのエンドポイント・リファレンスは、パラメータとして渡される。今や、オペレーティング・システム・サービス（５５）は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）に記憶されている構成（コンフィグレーション）データを自分自身へ又はＩＴリソース（６８）にそれぞれ適用することができる（即ち、“パッチレベル（ｐａｔｃｈＬｅｖｅｌ）”構成項目により示されるオペレーティング・システム・パッチ及び“ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）“構成項目内にリストされている生成されたユーザーアカウントをインストールする）。こうするために、オペレーティング・システム・サービス（５５）は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）のリソースタイプに固有のインターフェース（３３）上のオペレーションを呼び出し、そしてリソース・タイプに固有のコンフィグレーション（構成）・オプションの全てを検索する。このことは図４の矢印（７５）により示されている。構成管理（２４）が、サービス／リソース（５５）を生成しそして構成した後に、これは、個々のコンフィグレーション（構成）相互間のステートフル・ウエブ・サービス・リンクをたどることによりリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフをたどる。構成管理は、リンク（４０）をたどり、そしてリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）を見出す。再び、構成管理は、構成を適用するリソースの型（この例では”アプリケーション・サーバー・アプリケーション“）を知るために、デフォルト・インターフェース（３５）を使用する。次に、新たなステートフル・サービス／リソース・インスタンス（５８）”アプリケーション・サーバー“が、ホスティング基盤上に生成される。次いで、構成管理（２４）は、サービス（５８）のコンフィグレーション管理インターフェース（５９）上のセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）を呼び出し、そしてエンドポイント・リファレンスをリソースコンフィギュレーション（３４）に渡す。サービス（５８）は、リソース・タイプに固有の構成データ（これは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）のリソースタイプに固有のインターフェース（３６）を介して得られる）を自分自身へ又は”実（ｒｅａｌ）“のＩＴリソース（６９）へ適用する。次のステップにおいて、構成管理は、サービス・リソース（５５）及び（５８）の両方をホスト関係（６４）に関連づける。このような関係の生成は、ステートフル・ウエブ・サービス関係を使用する論理的に単純な生成であり、又はこれは、構成及びインストレーションステップを含むことができる。この例では、関係（６４）は、アプリケーション・サーバー・ソフトウエア（サーバー（５８）／リソース（６９）により表される）をオペレーティング・システム・イメージ（サービス（５５）／リソース（６８））にインストールすることにより生成されることができる。
【００４２】
今や、構成管理は、構成グラフをたどり続ける。これは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３７）を見出し、新たなサービス／リソース（６１）を生成し、この新たなリソースに構成を適用し、そして、新たなリソース（この例では“データベース・ソフトウエア”）及び以前に生成したオペレーティング・システム・サービス／リソースの間の関係（６５）を設立する。このプロセスの最後に、元のリソース構造と同じ構成及び接続形態を有する新たなリソース構造が生成される。
【００４３】
一般的に、構造グラフに従う複製（クローン）リソース構造の生成は、この例で概略的に説明したほど単純ではない。本当のシナリオでは、インストレーション及び構成ステップを或る順番で実行することが通常必要である（例えば、リソースＢの前にリソースＡを生成し、リソースＡ及びＢを結合し（即ち、関係を生成し）、次いで、構成データをリソースＡ及びＢに適用する）。ホスティング基盤及びリソースについて達成されるべき動作（ａｃｔｉｏｎ）の正しい順序を見出すことは、アルゴリズムのプランニングに依存しそして本発明の範囲外である。
【００４４】
デプロイメント（Ｄｅｐｌｏｙｍｅｎｔ）の考察：
図には、３つの個別的なアプリケーション・サーバーが、ソース・リソース（ｓｏｕｒｃｅ ｒｅｓｏｕｒｃｅ）構造のリソースをカプセル化するステートフル・ウエブ・サービス、複製（クローン）リソース構造のリソース及びリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するホスティング環境として示されている。このことは、ソース・システム、複製（クローン）システム及びリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスをホスティングするシステムが、異なる場所にある複数サイトにおいてデプロイ（ｄｅｐｌｏｙ，利用可能なように準備すること）され得ることを意味する。通信は、ネットワーク（できればインターネット）を介するウエブ・サービス・コールを使用してなされる。これは有効なシナリオであるけれども、全てのステートフル・ウエブ・サービスが１つのサイト又は１つのアプリケーション・サーバーにおいてホストされることが可能である。
【００４５】
構成管理（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｒ）は、ホスティング雰囲気上で意味を有しない個別のスタンドアローン・エンティティ（データの集まり）として示されている。１つの可能性は、構成管理をアプリケーション・サーバーの１つにおけるステートフル・サービスとしてデプロイすることである。更に、多数の構成管理（１つのサイトに１つ）を備えるデプロイメントのオプションを選択することもでき、ここで、１つの構成管理は、コンフィギュレーション・スナップショットを得るために使用され、他の構成管理は、複製（クローン）リソース構造を生成するために使用される。
【００４６】
本発明を説明する図１乃至図４に関して、本発明により提案される拡張は、（１）或るリソースをカプセル化するサービス上の２つの新たなオペレーション及び（２）タイプ・リソースコンフィグレーションの新たなステートフル・サービスを含むように説明される。
【００４７】
本明細書の次のパートにおいて、これらの２つの発明の拡張部についての更なる詳細を説明する。
【００４８】
或るリソースをカプセル化するステートフル・サービスのインターフェースは、２つのオペレーション、ゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィギュレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により拡張される。第１のオペレーションは、コーラー即ち呼び出し者（ｃａｌｌｅｒ）にリソースのオペレーションステートを検索させる。このステートは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのインスタンスに記憶され（以下を参照）、このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンスは、ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションにより戻される。第２のオペレーション、セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのエンドポイント・リファレンスを入力として得て、そしてこのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されている構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｄａｔａ）をステートフル・サービスによりカプセル化されているリソースに適用する。
【００４９】
前記２つのオペレーションによるステートフル・サービスの拡張（Ｅｘｔｅｎｄｉｎｇ）は下記を含む（リソース・デベロッパーとしてなされなければならない）：
（１） ２つの新たなオペレーション、ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により、サービス・デスクリプション（ＷＳＤＬ，ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｉｏｎ）を拡張（ｅｃｔｅｎｄ）する。
（２） 必要なビジネス・メソッド（ｂｕｓｉｎｅｓｓ ｍｅｔｈｏｄ）ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により、サービス・エンドポイント・インプリメンテーション（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）を拡張する。例えば、もしもサービスがＥＪＢステートフル・セッション・ビーン（ｂｅａｎ）を使用して実装される（ｉｍｐｌｅｍｅｎｔｅｄ）ならば、ビーンは、この２つの名前を備える２つのパブリック・メソッド（ｐｕｂｌｉｃ ｍｅｔｈｏｄ）により拡張されなければならない。
【００５０】
“ゲットコンフィグレーション”オペレーション：
ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）の実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、下記のタスクを実行しなければならない。
− カプセル化されたリソースの構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｄａｔａ）を記憶するためにリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの新たなインスタンスを生成する。このことは、このリソースに対するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのステートレス・ファクトリィ・オペレーションを呼び出すことにより行われる（下記参照）。新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンス（ＥＰＲ）が戻される。次いで、サービスは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスにデータを記憶するためにこのエンドポイント・リファレンス（ＥＰＲ）を使用することができる。
− （リソース管理を介して）カプセル化されたリソースから構成データを取りだし、そしてこの構成データを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶する。
− 及び／若しくは、サービスそれ自身のステート・データから構成データを取り出し、そしてこれを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶する。
− 及び／若しくは、１組の構成データ項目をプログラム的にコンパイルし、そしてこれを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶する。
− この新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（今や、これは複数リソースの全ての関連した構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｄａｔａ）を含んでいる）のＥＰＲをコーラー（ｃａｌｌｅｒ）に戻す。
【００５１】
セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーション：
セットコンフィグレーション・データの実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、以下に概略化されたタスクを実行しなければならない。
− このオペレーションに対してパラメータとして渡されたＥＰＲを使用して、関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスをコンタクトし、そしてこのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスから全ての構成データを検索する。
− 各構成データ項目を、カプセル化されたリソースに適用する。
＊リソースを構成（ｃｏｎｆｉｇｕｒｅ）するための適切なコマンドをリソース管理（ｒｅｓｏｕｒｃｅ ｍａｎａｇｅｒ）上で実行する。
＊リソース管理を介して構成データをリソースに記憶する。
− 及び／若しくは、構成データを自分自身に適用する（即ち、ステートフル・サービスはリソースをカプセル化する）−これはステートフル・サービス自体の変更の結果生じる構成データのためのものであり、そしてカプセル化されたリソースとの相互作用を要求しない。
【００５２】
新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス：
リソース・デベロッパ（ｄｅｖｅｌｏｐｅｒ）により与えられるべき本発明の他の実施例は、各リソースのための構成データを記憶するためにリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対する実装人工事実（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ａｒｔｉｆａｃｔｓ）である。
【００５３】
これらの人工事実（ａｒｔｉｆａｃｔｓ）は、下記を含む。
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（ＷＳＤＬ）のサービス記述（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｉｏｎ）
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するウエブ・サービス（ＷＳ）エンドポイント（例えば、ＷＳルータ・サーブレット）
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するＷＳエンドポイント・インプリメンテーション（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）（実行されたコード）
【００５４】
エンドポイント・インプリメンテーションは、例えば、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのステート・データを記憶するためにＥＪＢエントリィ・ビーンを使用するＥＪＢステートレス・セッション・ビーンの形で与えられることができる。このような実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、ステートフル・ウエブ・サービスに対する多くの可能性のうちのたった１つであることに注目されたい。
【００５５】
前記のように名付けられた人工事実の全ては、アプリケーション・サーバーにデプロイされる（ｄｅｐｌｏｙｅｄ）ことができるＥＡＲファイルにおいて互いにパッケージされることができる。クライアントの要求を受け取ると、サーバーは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するコードを実行することができる。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの１つのオペレーションは、リソースコンフィグレーション・ステートフル・ウエブ・サービスの新たなインスタンスをクライアントに生成させるステートレス・ファクトリィオペレーションである。かくして、このファクトリィ・オペレーションにより、リソースをカプセル化するステートフル・サービスは、これの“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーション（上記参照）内からリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成し、そしてこれの構成データを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶することができる。
【００５６】
リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの人工事実を含むＥＡＲファイルは、リソースをカプセル化するステートフル・サービスを含むＥＡＲファイルを保持している同じアプリケーション・サーバー上でデプロイされることができる。この場合、ステートフル・サービスは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成するときにローカル・アプリケーションと対話する。代わりに、リソースコンフィグレーションＥＡＲファイルは、遠隔にあるアプリケーション・サーバー上でデプロイされることができる。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの結果的なアドレス（即ち、リソースコンフィグレーション ＷＳ エンドポイントの関連ＵＲＬと組み合わされた遠隔にあるサーバーのアドレス）は、リソースをカプセル化するステートフル・サービスに知らされねばならない。
【００５７】
図５乃至図７を参照して、リソース構造を複製（クローニング）する本発明の方法の良好な実施例を詳細に説明する。本発明の方法は、次のような複数の処理ステップからなる。
リソース構造の構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）を得る（図５参照）、
リソース・コンフィグレーション・インスタンスを生成する（図６参照）、及び
構成グラフ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｇｒａｐｈ）からソース構造を生成する（図７参照）。
【００５８】
リソース構造の構成を得る詳細なフロー（図５参照）：
前提条件：
− クライアントはワーキングＩＴ環境を有し、ここでリソースはリソース・グラフに組織化されている）。
− クライアントは、リソースをカプセル化するステートフル・ウエブ・サービスへのエンドポイント・リファレンスを介して、リソースをアクセスできる。
− クライアントは、ルート・リソースへのＥＰＲを有する（即ち、グラフ内のリソースからす部手の他のリソースが、ステートフル・ウエブ・サービス関係を考察（ｔｒａｖｅｒｓｅ）することにより見出されることができる）。
− クライアントは、構成管理（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｒ）のアドレスを知っている。
フロー：
− クライアントは、構成管理（ＣＭ，ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｒ）を呼び出し、固有のルート・リソースを源とするリソース・グラフのコンフィグレーション・スナップショット（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｎａｐｓｈｏｔ）を得る要求を出し；ルート・リソースのＥＰＲがパラメータとして渡される（ｐａｓｓｅｄ）。
− 構成管理（ＣＭ）は，ルート・リソース上の“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”を呼び出す。
− リソースは、リソースに対する全ての構成データを記憶しているリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する。
− 現在処理されているリソースがルート・リソースであるので、生成されたリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲは、一時的に記憶され、そして後にクライアントに戻される。
（このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、ソース／リソース構造の全体の構造を表す構造のグラフのルート構造（ｒｏｏｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ）となる）。
− ＣＭは、関連するリソースに対するリソースを問い合わせる（これらの関連するリソースは、ステートフル・ウエブ・サービス関係を介し見出されることができる）；関連するリソースの組は戻される。
− もしも関連するリソースが見出されたならば、現在のリソースのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが一時的に記憶され、関連するリソース毎のリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成され（リソースの“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”オペレーションを呼び出すことにより）、新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、現在のリソースのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスとの関係において関連づけられる。
このことが、各リソース及びこれに関連するリソース毎に繰り返される。
− もしも複数のリソースの全体のグラフが考察され（ｔｒａｖｅｒｓｅｄ）そしてリソースのグラフと形態（ｔｏｐｏｌｏｇｙ）が同じであるリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフが生成されると、ルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲがクライアントに戻される。
【００５９】
事後条件：
− この段階で、クライアントは、全体のシステム構成（ｓｙｓｔｅｍ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を表すグラフの源となるルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
【００６０】
リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する詳細なフロー（図６参照）：
前提条件：
− ＩＴリソースは、ステートフル・ウエブ・サービス・インスタンスによりカプセル化されている。
− クライアントは、ステートフル・ウエブ・サービス・インスタンスを介してリソースにアクセスする。
− リソースの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、リソースに記憶されている構成データ、ステートフル・ウエブ・サービスのステート・データからなる。
− リソースをカプセル化しているステートフル・ウエブ・サービスは、リソースの構成データを記憶するために、タイプ（型）に固有のリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのアドレスを知っている。
フロー：
− “ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”オペレーションが呼び出される。
− ステートフル・ウエブ・サービスが、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのファクトリィ・オペレーション（ｆａｃｔｏｒｙ ｏｐｅｒａｔｉｏｎ）を呼び出すことにより、新たなリソースのタイプに固有のリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する。
− 新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲが一時的に記憶され、そして後にＣＭに戻される。
− リソースをカプセル化しているステートフル・ウエブ・サービスが、リソースの構成データを集める。
＊リソースから構成データを検索する。
＊ステートフル・ウエブ・サービスのステート自体に含まれている構成データを集める。
＊幾つかの構成データを“オン・ザ・フライ方式でコンパイルする（例えば、ターゲットのリソース上で後に実行され得る幾つかの構成スクリプト（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｃｒｉｐｔｓ）を生成する）。
− 構成データが、ウエブ・サービス・コールを介してリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶される。
− 新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲが、コーラー（呼び出し者、ｃａｌｌｅｒ）に戻される。
【００６１】
事後条件：
− リソースの完全な構成状態（ｃｏｎｆｉｇｕｒａｔｉｏｎａｌ ｓｔａｔｅ）を記憶している新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成されている。
− コーラー（ｃａｌｌｅｒ）は、このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
【００６２】
構成グラフ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｇｒａｐｈ）からＩＴリソース構成を生成する詳細なフロー（図７）：
前提条件：
− クライアントは、全体のシステム構成（ｓｙｓｔｅｍ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を表すグラフの源となるルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
− クライアントは、ターゲットのホスティング基盤（ｈｏｓｔｉｎｇ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に対する構成管理のアドレスを知っている、即ち、ホスティング基盤において、ターゲット・リソース構造が生成されるべきである（この構成管理及び基盤は、ソース・リソース構造と同じである）。
フロー：
− クライアントが、ＣＭ（構成管理）を呼び出し、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフに記憶されている構成データに従ってリソース構造を生成することを要求する。ルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲがパラメータとして渡される。
− ＣＭが、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが関連するリソースのタイプ（型）を検索する。
− ＣＭが、ホスティング基盤から適切なリソースの新たなインスタンスを要求する。
（例えば、ホスティング基盤が、リソース毎のフリー・プールを有し、プールは、ステートフル・ウエブ・サービス・インターフェイスを有するＩＴリソースを含む（本発明の範囲外）。
− ＣＭが、新たなリソースの“セットコンフィグレーション”を呼び出し、現在処理されつつあるリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲをリソースに渡す。
− このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されている構成データがリソースに適用される。
− ルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが処理されつつあるので、対応するルート・リソースのＥＰＲが一時的に記憶され、そして後にクライアントに戻される。
− 見出されたリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス毎に、ホスティング基盤から適切なタイプのリソースが得られ、構成がこのリソースに適用され、そして、新たなリソースと最後に生成された（即ち、親）リソースとの間の関係が設立される。
このことが、各リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス及びこれの関連する構成毎に繰り返される。
− もしも構成のグラフがたどられ終え（ｔｒａｖｅｒｓｅｄ）そして構成グラフと同じ形態（ｔｏｐｏｌｏｇｙ）を有するリソースのグラフが生成され終えたならば、ルート・リソースのＥＰＲがクライアントに戻される。
【００６３】
事後条件：
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフにより記述されているのと同じ形態（ｔｏｐｏｌｏｇｙ）及び構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）を備えるリソース構造が生成され終えている。
− リート・リソースのＥＰＲがクライアントに戻される。
− 今や、クライアントは、新たなリソース構造を使用することができ、複数のリソースが、ＥＰＲによりアドレスされるステートフル・ウエブ・サービスを介してアクセスされ、全てのリソースがルート・リソースで開始する複数の関係を考察（ｔｒａｖｅｒｓｅ）することにより見出されることができる。
【図面の簡単な説明】
【００６４】
【図１】ステートフル・ウエブ・サービスとしての１つのリソースを示す図である。
【図２】本発明に従って複製（クローン）されるべきＩＴリソースの例を示す図である。
【図３】図２に示されているＩＴリソース構造の構成スナップショットを得るための本発明の方法を示す図である。
【図４】図３に示されている以前に得られた構成スナップショットから１つの複製（クローン）ＩＴリソース構造を作り出すための本発明の方法を示す図である。
【図５】構成スナップショットを得るための本発明の良好な実施例のフロー・チャートを示す図である。
【図６】リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する本発明の良好な実施例のフロー・チャートを示す図である。
【図７】構成グラフからＩＴリソース構造を生成する本発明の良好な実施例のフロー・チャートを示す図である。
【符号の説明】
【００６５】
１ ステートフル・ウエブ・サービス
２ ＩＴリソース
３ 通信プロトコル
４ インスツルメント・サーバー
５ ウエブ・サービス・コンテナ
６ データベース
７ オペレーティング・システム・サービス／リソース
８ ウエブ・サービス・プロトコル
９ ウエブ・サービス・インターフェース
１０．１３ ステイフル・サービス
１１，１４ 構成管理インターフェース
１２，１５ インターフェース
１６，１７ 関係
１８，１９，２０ リンク
２１ データベース
２２ クライアント
２３ ウエブ・サービス・コール
２４ 構成管理
【０００１】
本発明は、リソース（資源）が、ステートフル（通信状態を保持する）ウエブ・サービスとしてモデル化されるサービス指向のＩＴ（情報技術）リソース構造の分野に関し、更に具体的にいうならば、本発明は、現存するＩＴリソース環境を、これのリソースの接続形態（ｒｅｓｏｕｒｃｅ ｔｏｐｏｌｏｇｙ）を維持しながら自動的に複製（クローニング、ｃｌｏｎｉｎｇ）するための方法、システム及びコンピュータ・プログラム製品に関する。
【背景技術】
【０００２】
今日のＩＴリソース構造は、多数の、異種で且つ分散されたリソースからなる。オン・デマンドのＩＴ構造を作り出すためのキーは、共通で且つ標準型のインターフェイスを介してこれらのリソースを管理するための手段を与え、そしてリソース相互間に標準的型のインターオペラビリティ（複数の異なるものを接続したり組み合わせて使用したときにきちんと全体として正しく動作すること）を与えることである。ウエブ・サービス・リソース・フレームワーク（ＷＳ−ＲＦ、ウエブ・サービスを使用してステートフル・リソースにアクセスするための一連の使用を定義する）は、ウエブ・サービス・インターフェイスの背後に各種のリソース（資源）をカプセル化する技術である。特に、ＷＳ−ＲＦは、ＩＴリソースのステートフルな特性に集中する。例えば、オペレイティング・システム・リソースのステートは、システム内で現在動作中の処理の数、またはユーザによるログの数である。
【０００３】
ＷＳ−ＲＦに従うと、ＩＴ環境内の全てのステートフル・リソースは、ウエブ・サービス・インターフェイスを介して管理される。即ち、クライアントは、ウエブ・サービスのエンド・ポイント上のウエブ・サービス・コールを呼び出し、次いでこれらは、特定なステートフル・リソースにマップされる（図１参照）。仕様のＷＳ−ＲＦセット内で、ウエブ・サービス・ポートタイプの形の幾つかの標準のウエブ・サービス・インターフェースが規定され、これらは、ステートフル・リソースのウエブ・サービス・フロント・エンドにより与えられる。これらの標準のポートタイプは、例えば、リソースの寿命管理、リソース・ステートのクェリー（問い合わせ）、またはノーティフィケーション（通知）サポートに関係する。
【０００４】
ＷＳ−ＲＦで表現されたリソースのステートは、いわゆるリソース・プロパティ（性質を表すデータ）に記憶される。特定なリソースに対する全てのリソース・プロパティの総和は、ＷＳ−ＲＦにより規定される標準のウエブ・サービス・コールを介して検索されることができるリソース・プロパティ・ドキュメントーＸＭＬに含まれる。
【０００５】
ＩＴリソース構造内の全てのリソースは、ＷＳ−リソース・フレームワークに従ってＷＳ−リソースとしてモデル化される。即ち、リソースは、ステートフル・ウエブ・サービス・インターフェースの背後にカプセル化される。リソースは、例えば、コンピュータ若しくは記憶装置のような物理的なＩＴリソース、例えばオペレーティング・システム若しくはウエブ・サーバーのような論理的なソフトウエア・リソース、又は顧客の提示若しくは全体的なオン・デマンド・サービス環境のような論理的なビジネス指向のリソースを含むことができる（注、このようなオン・デマンド環境内のリソースは互いに関連されている）。これらの関係は、ステートフル・ウエブ・サービス関係としてモデル化され、そしてこれは、この関係に加わる全てのステートフル・ウエブ・サービスに対する参照を記憶する。これらの関係は誘導されることができる。従って、オン・デマンド環境は、グラフとしてみることができる。或る環境の最も一般的な形は、ツリー接続形態であり、これは、論理的なオン・デマンド・サービス（ＯＤＳ）リソースで始まる。この関係を介して、ツリーは、葉に対応する部分（最も一般的には物理的リソースである）まで辿る（ｔｒａｖｅｒｓｅ）ことができる。一般的に、オン・デマンド環境は、同方向性の関係及び循環的な関係を含む任意の接続形態を有することができる。又、このようなグラフは、適切なグラフ・アルゴリズムを使用して誘導されることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
初期の問題：
今日のＩＴ環境は、数十又は数百もの互いに異質なリソースがなっている。或る複雑なＩＴ環境を複製（ｃｌｏｎｅ）するためには、全体的なシステムの構成（コンフィグレーション）ステート（即ち、システムの接続形態、使用されるリソースの数及びタイプ（型）、個々のリソースの構成状態、リソース相互間の関係等）を取得し、次いで、同様なレイアウトを備える或る等価的な等しいＩＴシステムを例示化するために、上記取得したデータを使用することが必要である。リソース型若しくはベンダ固有のインターフェースを介して個々のリソースの構成状態を管理することが可能であるけれども、共通な標準的なインターフェースを介して全体のシステムの構成を管理することは不可能である。ＩＴ環境は、異なるバック・エンド（ユーザに見えない後方にあるシステム）によりホストされている多数の互いに異なる型のリソースならなることができる。例えばＷＳ−ＲＦのような技術が、これらのバック・エンドと標準の方式で通信する手段を与えたとしても、構成管理の問題は、ＷＳ−ＲＦまたは他のステートフル・ウエブ・サービスの仕様によりカバーされない。結果として、リソースの開発者は、リソース１件毎に構成管理を手動的に処理しなければならない。更に、個々のリソースの構成相互間の関係を管理する標準的な手段は、実現されていない。しかしながら、このような構成相互間の関係は、システムに亘る構成ビュー（コンフィギュレーショナル・ビュー）を与えるために要求される。
【０００７】
従来技術：
ＩＴリソース構造の最新の進展状況においては、リソース毎に構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）データをデータベースに記憶することが可能である。記憶されたデータは、リソースを規定されたステートに戻すために使用されることができる。ソフトウエア・オブジェクトのステート若しくはソフトウエア・オブジェクトの構成はそれぞれ、オブジェクト関係データベース内で持続的に維持されることができる。ＷＳ−ＲＦは、リソースのステートを反映するためにリソース・プロパティの概念を導入する。或る特定なリソースの全てのリソース・プロパティの組み合わせは、いわゆるリソース・プロパティ・ドキュメントに含まれる。このＸＭＬドキュメントは、ウエブ・サービス・コールを使用して検索されることができ、そしてＸＭＬデータベースに記憶されることができる。
【０００８】
伝統的なＩＴ基盤において、個々のリソースの構成データを記憶しそしてリソースの構成を回復することは可能であるけれども、サービス指向のステートフル・ウエブ・サービス環境において、全てのリソースに亘る構成の管理を達成する共通手段は現存していない。リソースのそれぞれの型は、適切な型特有の構成管理インターフェースを与える。ＷＳ−ＲＦに準拠するステートフル・リソースに対するリソース・プロパティ・ドキュメント（ＲｅｓｏｕｒｃｅＰｒｏｐｅｒｔｙＤｏｃｕｍｅｎｎｔ）の概念は、構成管理に対する必要性に対して十分でない。第１に、このようなリソース・プロパティ・ドキュメントに含まれるデータは、リソースの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）に関連していない（例えば、コンピュータ・リソースのＣＰＵコアの温度特性は、これの構成に関連しておらず、現状の負荷又は周囲温度により影響される）。第２に、リソースの構成を反映するデータは、リソース・プロパティ・ドキュメントを介して露出されない。
【０００９】
更に、システムに亘る構成記録を形成するために個々のリソースの構成データを関連づける機構は現存しない。上述の全ての態様は、自動型に或るＩＴシステムの複製を可能にするために解決される必要がある。
【００１０】
本発明の目的：
本発明は、従来技術の不利点を排除した、サービス指向のステートフル・ウエブ・サービス環境において現存するＩＴリソース構造を自動的に複製（クローン）するための方法、システム及びコンピュータ・プログラム製品を提供する。
【課題を解決するための手段】
【００１１】
本発明は、構成管理（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ）のための新たな構成を使用することにより、ステートフル・ウエブ・サービス環境におけるＩＴリソース構造を自動的に複製（クローン）するための方法、システム及びコンピュータ・プログラム製品を提供する。
【００１２】
この新たな手法は、各リソースの構成・ステートをステートフル・ウエブ・サービスとしてモデル化する。構成データは、このサービス・リソース・プロパティにより与えられる。異なる種々なリソースの構成相互間の関係は、ウエブ・サービス・インスタンス（データ）相互間の“ステートフル・ウエブ・サービス関係”としてモデル化される。これらの関係は、誘導される（ｎａｖｉｇａｔｅｄ）ことができ、これは、標準の方式で全体のシステムの構成を探求することを可能にする。
【００１３】
更に、新たなウエブ・サービス・インターフェースが、リソースをカプセル化するステートフル・ウエブ・サービスにより与えられる。このインターフェースは、２つの新たなオペレーションを与える。即ち、“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”は、開発者（ｅｘｐｌｏｉｔｅｒ）に、リソース及び関連するリソースの構成状態のスナップショットを取得させることができ、そして、“セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）は、リソースの構成状態を以前にセイブされたステートにセットすることを可能にする。“ゲットコンフィグレーション”の発動は、各リソースの構成状態を記憶する新たなステートフル・ウエブ・サービス・インスタンスの生成を生じる。この新たなウエブ・サービス・インターフェイスは、リソースの型毎に実装される。この新たなウエブ・サービス・インターフェイスを実装するために、任意のバック・エンド技術が使用されることができる。
【００１４】
本発明の上述の及び付加的な目的、特徴及び利点は、以下の詳細な説明において明らかになるであろう。
【００１５】
本発明の新規な特徴は添付の請求項に記載してある。しかしながら、本発明自体、好ましい仕様の態様、更なる目的及び本発明の利点は、図面と共に例示的な実施例についての以下の詳細な説明を参照することにより理解されるであろう。
【００１６】
本発明は、サービス指向アーキテクチャ（ＳＯＡ）の分野に関し、ここで、ＩＴリソースは、ステートフル・ウエブ・サービスとしてモデル化される。即ち、これらは、ステートフル・ウエブ・サービス・インターフェースの背後にカプセル化（ｅｎｃａｐｓｕｌａｔｅｄ）される。
【００１７】
リソースをステートフル・ウエブ・サービスとしてモデル化するための共通のパターンが図１に示されている。ステートフル・ウエブ・サービス（１）は、物理的又は論理的ＩＴリソース（２）に対するクライエント・フロント・エンドとして存在する。このステートフル・サービス（１）は、例えばＷｅｂｓｐｈｅｒｅアプリケーション・サーバーのようなウエブ・サービス・コンテナ（５）によりホストされる。基礎をなすリソースを備えるステートフル・サービスは、リソース・タイプに固有の通信プロトコル（３）（例えばＳＮＭＰ）を直接に支配し、又はこれは、リソースが直接的なインスツルメンテーションをサポートしていない場合にインスツルメンテーション・サーバー（４）によりリソースに接続する。
【００１８】
ステートフル・ウエブ・サービス（１）はステートフルであり、ここで、これは、基礎をなすリソースの現在のステートを反映し、即ち、クライアントは何時でもリソースのステートを問い合わせ又は変更でき、あるいはその両方を行うことができる。基礎をなすリソース（２）のステートにアクセスするために、ステートフル・サービス（１）は、（３）又は（４）を介してリソースと通信する。更に、ステート・データは、アプリケーション・サーバー（５）に取り付けられているデータベース（６）に記憶されることができる。ステートフル・サービス（１）は、例えば、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ(R) Ｂｅａｎｓ（ＥＪＢｓ）を使用してこのデータベースをアクセスすることができる。
【００１９】
クライアントは、例えばＨＴＴＰを介するＳＯＡＰのような標準のウエブ・サービス・プロトコル（８）を使用してステートフル・ウエブ・サービスをアクセスすることができる。各ステートフル・ウエブ・サービスは、クライアントにより呼び出されることができる１組のオペレーションを提供する多数のリソースタイプに固有のウエブ・サービス・インターフェース（ポートタイプ）（９）を提供する。例えば、或る１つのサーバ・リソースをカプセル化する１つのステートフル・ウエブ・サービスは、２つのオペレーション“スタート・サーバー（ｓｔａｒｔＳｅｒｖｅｒ）”及び“ストップ・サーバー（ｓｔｏｐＳｅｒｖｅｒ）”をインターフェースに与える。更に、各ステートフル・ウエブ・サービスは代表的には、インターフェイスに、リソース・ステートの問い合わせをさせる、即ちいわゆるリソース・プロパティを検索させる。
【００２０】
説明中のモデリング・パターンは、汎用アーキテクチャ・パターンである。可能な実装の標準は、ウエブ・サービス・リソース・フレームワーク（ＷＳ−ＲＦ）の仕様のセット又はＷＳ−ＲＦのトップで立ち上がるウエブ・サービス分散（Ｄｉｓｔｒｉｂｕｔｅｄ）管理の仕様セットの形で存在する。
【００２１】
ステートフル・サービスをアドレスするためのエンドポイント・リファレンス（応答を送るべき相手を示す）：
単純なＵＲＬによりアドレスされる標準の（ステートレス（通信状態を保持しない））ウエブ・サービスとは対照的に、ステートフル・ウエブ・サービスは、クライアントにステートフル・ウエブ・サービスの特定なインスタンスをアドレスさせることができる更に高度なアドレス機構を要求する。
【００２２】
このアドレス機構は、エンドポイント・リファレンスを使用させ、そしてＷＳ−アドレッシング・スタンダードで指定される。このようなエンドポイント・リファレンスは、オブジェクト指向のプログラミング言語において使用されているようなオブジェクト・リファレンス若しくはポインターと比較されることができる。これは、ウエブ・サービス・エンドポイントの位置についての情報（ＵＲＬの形）、及びステートフル・ウエブ・サービス・インプリメンテーション（実装）に、ウエブ・サービス・コールを或る特定なリソースにマップさせる追加の情報を含むエンティティである。エンドポイント・リファレンスを有するクライアントは、ステートフル・サービスの特定なインスタンス又は特定なリソースとそれぞれ通信することができる。
【００２３】
図２に示す次のリソース構造は、本発明を詳細に説明する例である。オペレーティング・システム・リソース（１）は、アプリケーション・サーバー・アプリケーション（２）及びデータベース・アプリケーション（３）をホストする。矢印（４）及び（５）は、オペレーティング・システム（１）とアプリケーション（２）及びデータ・ベース（３）との間に存在する“ホスト”関係を示し、この関係は読み出され、“オペレーティング・システム（１）はアプリケーション・サーバー（２）をホストし、そして、“オペレーティング・システム（１）はデータ・ベース（３）をホストする。構成（コンフィグレーション）のコンテキストに関連する次のリソース・プロパティがリソースに規定される。
オペレーティング・システム（１）：
− パッチレベル（ｐａｔｃｈＬｅｖｅｌ）（例えば、サービスパック（Ｓｅｒｖｉｃｅｐａｃｋ １）
− ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔｓ）
アプリケーション・サーバー・アプリケーション（２）：
− セキュリティポリシイ（例えばイネーブル若しくはディスエーブルされたセキュリティＰｏｌｉｃｙ）
− マックスコンカレントセッション（コンカレント・クライアント・セッションの最大数）
データベース・アプリケーション（３）：
− キャッシングストラテジィ
− コードセット （例えば、ユニコード ＵＴＦ−８）
【００２４】
上述のリソースのそれぞれは、ステートフル・ウエブ・サービス（７）、（１０）及び（１３）によりクライアントに露出される。これらのステートフル・サービスは、ウエブ・サーバー・コンテナとして働くアプリケーション・サーバー（６）によりホストされ、そしてリソースタイプ及びベンダー固有のリンク（１８）、（１９）及び（２０）を介して前記の各ＩＴリソースと通信する。更に、ステートフル・ウエブ・サービスのステート・データは、アプリケーション・サーバー（６）に取り付けられているデータベース（２１）に記憶されることができる。リソース（１）及び（２）の間の又はリソース（１）及び（３）の間の“ホスト”関係のそれぞれは、ステートフル・ウエブ・サービス関係（１６）及び（１７）により反映される。これらのステートフル・ウエブ・サービスをたどる（ｔｒａｖｅｒｓｅ）ことにより、ステートフル・サービス（７）により（又は、（７）により表されるＩＴリソースにより）ホストされた全てのステートフル・サービスを見出すことができる。ステートフル・サービスのそれぞれは、リソースの型に固有のインターフェイス（９）、（１２）及び（１５）を与える。オペレーション・システム・サービス（７）に対して、インターフェイス（９）は、例えば、オペレーション“スタート・アプリケーション・プロセス（ｓｔａｒｔＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓ）”又は“ストップアプリケーションプロセス（ｓｔｏｐＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓ）”からなる。アプリケーション・サーバー・サービス（１０）のインターフェイス（１２）は、例えば、“デプロイアプリケーション（ｄｅｐｌｏｙＡｐｐｌｉｃａｔｉｏｎ）”及び“アンデプロイアプリケーション（ｕｎｄｅｐｌｏｙＡｐｐｌｉｃａｔｉｏｎ）”を与える。データベース・サービス（１３）のインターフェイス（１５）は、オペレーション“クリエイト・テーブル（ｃｒｅａｔｅＴａｂｌｅ）”及び“デリートテーブル（ｄｅｌｅｔｅＴａｂｌｅ）”を与える。
【００２５】
リソース・タイプの固有のインターフェースに加えて、各ステートフル・ウエブ・サービスは又、本発明により提案された“構成管理”インターフェース（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｍｅｎｔ ｉｎｔｅｒｆａｃｅ）（８）、（１１）及び（１４）を与える。このインターフェースは、２つのオペレーション、即ち、“ゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）“及び”セットコンフィギュレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）“を提供する（ｏｆｆｅｒ）。オペレーティング・システム・サービスを指す（ポイントする）有効なエンドポイント・リファレンスを所有しているクライアント（２２）は、そのステートフル・サービスのウエブ・サービス・コール（２３）を呼び出すことができる。更に、関係（１６）又は（１７）をたどる（ｔｒａｖｅｒｓｅ）ことにより、クライアントは、アプリケーション・サービス・サーバー又はデータベース・サービスのエンドポイント・リファレンスを得ることができ、そして、これらのリソースのステートフル・ウエブ・サービス・コールを呼び出すことができる。
【００２６】
ＩＴリソース構造のコンフィグレーション（構成）・スナップショットの取得：
ＩＴリソース構造の構成（コンフィグレーション）（グラフでは、リソースの構成をノードとして含み、そしてこれらの構成相互間の関係をエッジとして含む）は、“構成管理”コンポーネント（２４）により制御される。このコンポーネントは、クライアントに、或る与えられたリソース構造の構成スナップショットの生成を開始させ、そして、それまでに得られた構成スナップショットに基づいてリソース構造を生成させる。
【００２７】
クライアント（２２）は、オペレーティング・システム・サービス／リソース（７）を指すエンドポイント・リファレンスを有する（注：表記“サービス／リソース”は、クライアントがサービス・フロント・エンドと通信しているが、論理的には、このサービスによりカプセル化されたリソース上で実際にはオペレーションしていることを意味する）。これは、オペレーティング・システム・サービス／リソース（７）をアンカー・ノードとして有するリソース構造のコンフィグレーション・スナップショットを得ることを要求する。この要求（２５）は、ステートフル・サービス（７）へのエンドポイント・リファレンスをパラメータとして有する。今や、構成管理（２４）は、与えられたエンドポイント・リファレンスを使用してサービス（７）の構成管理インターフェイス（８）をアクセスすることができる。これは、ウエブ・サービス・コール（２７）を生じることにより、オペレーティング・システム・サービス上のゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションを呼び出す。このオペレーションの間に、新たな“リソースコンフィグレーション（ｒｅｓｏｕｒｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）ウエブ・サービス・インスタンス（３１）が生成され（２９）、これは、オペレーティング・システム・サービスの構成（コンフィグレーション）を作る全ての項目を記憶する。このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、ウエブ・サービス・コンテナ（アプリケーション・サーバー）（３０）においてホストされる。コンフィグレーション・データ（構成データ）、即ち、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのプロパティは、アプリケーション・サーバーに備え付けられているデータベース（４３）に記憶される。例えば、このデータは、例えばＥｎｔｅｒｐｒｉｓｅ Ｊａｖａ(R) Ｂｅａｎｓ（ＥＪＢｓ）のような技術を使用してアクセスされることができる。アプリケーション・サーバー（３０）及び（６）は又同じでも良い。即ち、ＩＴリソースを表すステートフル・サービス及びリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの両方は、同じウエブ・サービス・コンテナによりホストされることができる。
【００２８】
新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）を指すエンドポイント・リファレンスは、構成管理に戻される（２８）。今や、構成管理（２４）は、ステートフル・ウエブ・サービスをたどることにより、リソースの構造をたどる。関係（１６）をたどることにより、構成管理は、ステートフル・サービス／リソース（１０）を見出す。これは、このサービスのゲットコンフィグレーションオペレーションを呼び出し、そして、アプリケーション・サーバー・サービス／リソース（１０）に関連する全てのコンフィグレーション・データ（構成データ）を記憶する新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）へのエンドポイント・リファレンスを得る。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）へのエンドポイント・リファレンスを受け取った後、構成管理は、２つのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）及び（３４）をステートフル・ウエブ・サービスの関係（４０）に関連づける（ａｓｓｏｓｉａｔｅ）。このことは、これらそれぞれの構成間のある関係にあるリソース構造のリソース相互間に存在する関係を反映する。結果として、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフが生成され、これは、リソースのグラフと同じ接続形態（ｔｏｐｏｌｏｇｙ）を有する。
【００２９】
同じステップが、ステートフル・サービス・リソース（１３）に対して繰り返される。即ち、サービス（１３）は、関係（１７）をたどることにより見出される。ゲットコンフィギュレーションが呼び出され、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３７）がサービス（１３）により生成され、（３７）のエンドポイント・リファレンスが構成管理に戻され、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）及び（３７）の間の関係（４１）が生成される。
【００３０】
コンフィギュレーション・スナップショットを得るプロセスの最後で、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフが存在し、これは、全体のソース・リソース構造のシステム構成（コンフィギュレーション）を表す。このグラフは、ノードとしての個別のリソースの構成及びエッジとしてのこれらの構成相互間の関係からなる。アンカー又はルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンスは、コンフィギュレーション・スナップショットを要求したクライアントに戻される（２６）。
【００３１】
リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス：
リソースのコンフィギュレーション（構成）・ステートを表す構成データは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶される。これらのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、これらが異なる型のリソース毎に固有である構成データを記憶するのでリソースの型に固有である。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、ゲットコンフィギュレーション・オペレーションの間に、ステートフル・サービス（或るリソースを表す）により生成される。実装（インプリメンテーション）は、リソースの型に固有であり、そして、或る与えられた型（タイプ）のリソースに対するステートフル・サービスの開発者（デベロッパー）によりに与えられなければならない。一般的に、この開発者は、どのような情報が、彼の型のリソースに対するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶される必要があるかを決定するための優れた知識を有している。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されたデータを或るリソース・インスタンスに適用させるセットコンフィギュレーションオペレーションの実装は、それぞれの開発者から与えられなければならない。その理由は、開発者が、構成データを正しく適用するに必要な優れた知識を有するからである。
【００３２】
上述のように、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、リソースの型に固有である。しかしながら、本発明は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのそれぞれにより与えられるべき最小のインターフェイス（オペレーションの組及びプロパティの組）を提案する。このようなサービスのそれぞれは、少なくとも次のような２つのプロパティを有する。
− ｒｅｓｏｕｒｃｅＴｙｐｅ（リソース・タイプ）：リソースコンフィギュレーション（ＲｅｓｏｕｒｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）が関連される（ａｓｓｏｃｉａｔｅｄ）リソースの型（タイプ）を特定し、この情報は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフから或るクローン（複製）リソース構造を生成するときに必要とされる。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス内に記憶された構成データは、ステートされた（ステートで特定された）型のリソースだけに適用される。
− タイムスタンプ：リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成されたとき、即ち、コンフィグレーション・スナップショットが得られたときのデータ及び時刻を特定する。これは、同じステートフル・リソース・インスタンスに対する幾つかのリソースコンフィグレーションを区別する。
【００３３】
更に、デフォルト・インターフェイスは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの前記プロパティを検索する手段を与えなければならない。
【００３４】
図３に示すリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対して、このデフォルト・インターフェイスは、（３２）、（３５）及び（３８）として示されている。このインターフェイスは、コンフィグレーション・スナップショットを取得して、そしてこれに基づいて１つの複製（クローン）リソース構造を生成するために本発明により提案される。
【００３５】
更に、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのそれぞれは、図３に示すリソースタイプに固有のインターフェース（オペレーションの組及びプロパティの組）（３３），（３６）及び（３９）を与える。このインターフェースにより与えられるオペレーションの組及びプロパティの組は、リソース・デベロッパーにより決定される。オペレーティング・システム・サービス／リソース（７）に関連するリソース・コンフィグレーション（３１）に対して、例えば、タイプに固有のプロパティは、“パッチレベル（ｐａｔｃｈＬｅｖｅｌ）”及び“ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）”を含む。或る型（タイプ）のリソースに対するセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションは又、タイプに固有であり、そしてリソース・デベロッパーにより実装されるので、或るリソースをカプセル化するステートフル・サービスの実装は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの型に固有のオペレーション及びプロパティを知っており、その結果、これはこの情報で働きそしてこれをリソース・インスタンスに適用することができる。
【００３６】
例えば、オペレーティング・システム・ステートフル・サービス上のセットコンフィグレーションを呼び出すとき、サービスは、構造データが、項目“パッチレベル（ｐａｔｃｈＬｅｂｅｌ）”及び項目”ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）“を含むことを知っており、そして、サービスは、これらの２つの項目をタイプ・オペレーティング・システムのリソースに如何に適用するかを知っている（例えば、パッチレベル・プロパティにより示された全てのパッチをインストールし、そしてユーザアカウント・プロパティにリストされている全てのユーザ・アカウントを生成する）。
【００３７】
以前に取得されたコンフィグレーション・スナップショットから複製（クローン）リソース構造を作り出す：
前項で説明したステップから、或るリソース構造のコンフィグレーション（構成）が取得された。この構成はグラフに記憶され、ここで、ノードは、個々のリソースの構成データを保持するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのインスタンスであり、そして、エッジは、これらの単一の構成相互間の関係であり、そして、元（オリジナル）のリソース構造のリソース相互間の関係を反映する。このコンフィグレーション（構成）グラフに基づいて、元のリソース構造の複製（クローン）と呼ばれる新たなリソース構造が生成されることができ、これは元のリソース構造と同じ構成（コンフィグレーション）及び接続形態（トポロジ）を有する。このプロセスが図４に示されている。クライアント（２２）は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）へのエンドポイント・リファレンス（５０）を有し、これは、元のリソース構造の構成（コンフィグレーション）全体を表すリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフのアンカー又はルート・ノードである。全てのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、ウエブ・サービス・コンテナ（３０）、即ちアプリケーション・サーバー内でホストされる。構成（コンフィグレーション）データは、アプリケーション・サーバーに備え付けられているデータベース（４３）に記憶され、そして例えばＥＪＢｓを使用してアクセスされることができる。
【００３８】
クライアントは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）を源とする構成（コンフィグレーション）グラフに含まれている情報に従って或るリソース構造を生成するために、構成管理（２４）に要求（５１）を出す。要求のパラメータは、リソース構造が生成されるべき場合、サービス（３１）のエンドポイント・リファレンス及びホスティング・インフラストラクチャ（基盤）（例えば、物理的及び論理的ＩＴリソースを備えるデータ・センター、リソース・レジストリィ、リソース・プール、リソース・ファクトリィ等）を含む。構成管理は、この構成を適用しようとしているリソースの型（タイプ）（例えばオペレーティング・システム）を知るために、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）に問い合わせる（５３）。この問い合わせは、各リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスにより実装されるデフォルトのリソースコンフィグレーション・インターフェイス（３２）に出される。リソースの型を得ると、構成管理は、ホスティング・インフラストラクチャ（基盤）における要求されたリソースのインスタンスを得ることができる（例えば、新たなリソースを生成し又はフリー・プールから１つのリソースを得る）。これは、ステートフル・サービス／リソース（５５）の生成を表す矢印（５４）により示されている。
【００３９】
ホスティング・インフラストラクチャ（基盤）のレイアウト及びリソースがこのインフラストラクチャにより管理されるやり方は、本明細書の範囲外である。一般的には、このようなインフラストラクチャは、新たなリソース・インスタンス及び利用可能なリソースのプールを生成するためにリソース及びファクトリィを見出すための多数のレジスタを含む。更に、インフラストラクチャは、ＩＴリソースに対するステートフル・ウエブ・サービス・フロント・エンド・インターフェースのためのコンテナとして働くウエブ・サービス・ホスティング環境（６６）（アプリケーション・サーバー）を含む。
【００４０】
タイプ・オペレーティング・システム・サーバーのステートフル・サービス（５５）は、アプリケーション・サーバー（６６）によりホストされ、そして、エンドポイント・リファレンスを介してアドレス可能である。“実（ｒｅａｌ）”のＩＴリソース（６８）に対する通信リンク（７１）は、リソース上のオペレーションを呼び出すために、又はステート・データを問い合わせるために存在する。更に、ステート・データは、データベース（６７）に記憶されることができる。
【００４１】
ステートフル・サービス／リソース（５５）の生成の後に、構成管理は、サービス（５５）の構成管理インターフェ−ス（５６）上のセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションを呼び出す。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）へのエンドポイント・リファレンスは、パラメータとして渡される。今や、オペレーティング・システム・サービス（５５）は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）に記憶されている構成（コンフィグレーション）データを自分自身へ又はＩＴリソース（６８）にそれぞれ適用することができる（即ち、“パッチレベル（ｐａｔｃｈＬｅｖｅｌ）”構成項目により示されるオペレーティング・システム・パッチ及び“ユーザーアカウント（ｕｓｅｒＡｃｃｏｕｎｔ）“構成項目内にリストされている生成されたユーザーアカウントをインストールする）。こうするために、オペレーティング・システム・サービス（５５）は、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３１）のリソースタイプに固有のインターフェース（３３）上のオペレーションを呼び出し、そしてリソース・タイプに固有のコンフィグレーション（構成）・オプションの全てを検索する。このことは図４の矢印（７５）により示されている。構成管理（２４）が、サービス／リソース（５５）を生成しそして構成した後に、これは、個々のコンフィグレーション（構成）相互間のステートフル・ウエブ・サービス・リンクをたどることによりリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフをたどる。構成管理は、リンク（４０）をたどり、そしてリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）を見出す。再び、構成管理は、構成を適用するリソースの型（この例では”アプリケーション・サーバー・アプリケーション“）を知るために、デフォルト・インターフェース（３５）を使用する。次に、新たなステートフル・サービス／リソース・インスタンス（５８）”アプリケーション・サーバー“が、ホスティング基盤上に生成される。次いで、構成管理（２４）は、サービス（５８）のコンフィグレーション管理インターフェース（５９）上のセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）を呼び出し、そしてエンドポイント・リファレンスをリソースコンフィギュレーション（３４）に渡す。サービス（５８）は、リソース・タイプに固有の構成データ（これは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３４）のリソースタイプに固有のインターフェース（３６）を介して得られる）を自分自身へ又は”実（ｒｅａｌ）“のＩＴリソース（６９）へ適用する。次のステップにおいて、構成管理は、サービス・リソース（５５）及び（５８）の両方をホスト関係（６４）に関連づける。このような関係の生成は、ステートフル・ウエブ・サービス関係を使用する論理的に単純な生成であり、又はこれは、構成及びインストレーションステップを含むことができる。この例では、関係（６４）は、アプリケーション・サーバー・ソフトウエア（サーバー（５８）／リソース（６９）により表される）をオペレーティング・システム・イメージ（サービス（５５）／リソース（６８））にインストールすることにより生成されることができる。
【００４２】
今や、構成管理は、構成グラフをたどり続ける。これは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（３７）を見出し、新たなサービス／リソース（６１）を生成し、この新たなリソースに構成を適用し、そして、新たなリソース（この例では“データベース・ソフトウエア”）及び以前に生成したオペレーティング・システム・サービス／リソースの間の関係（６５）を設立する。このプロセスの最後に、元のリソース構造と同じ構成及び接続形態を有する新たなリソース構造が生成される。
【００４３】
一般的に、構造グラフに従う複製（クローン）リソース構造の生成は、この例で概略的に説明したほど単純ではない。本当のシナリオでは、インストレーション及び構成ステップを或る順番で実行することが通常必要である（例えば、リソースＢの前にリソースＡを生成し、リソースＡ及びＢを結合し（即ち、関係を生成し）、次いで、構成データをリソースＡ及びＢに適用する）。ホスティング基盤及びリソースについて達成されるべき動作（ａｃｔｉｏｎ）の正しい順序を見出すことは、アルゴリズムのプランニングに依存しそして本発明の範囲外である。
【００４４】
デプロイメント（Ｄｅｐｌｏｙｍｅｎｔ）の考察：
図には、３つの個別的なアプリケーション・サーバーが、ソース・リソース（ｓｏｕｒｃｅ ｒｅｓｏｕｒｃｅ）構造のリソースをカプセル化するステートフル・ウエブ・サービス、複製（クローン）リソース構造のリソース及びリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するホスティング環境として示されている。このことは、ソース・システム、複製（クローン）システム及びリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスをホスティングするシステムが、異なる場所にある複数サイトにおいてデプロイ（ｄｅｐｌｏｙ，利用可能なように準備すること）され得ることを意味する。通信は、ネットワーク（できればインターネット）を介するウエブ・サービス・コールを使用してなされる。これは有効なシナリオであるけれども、全てのステートフル・ウエブ・サービスが１つのサイト又は１つのアプリケーション・サーバーにおいてホストされることが可能である。
【００４５】
構成管理（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｒ）は、ホスティング雰囲気上で意味を有しない個別のスタンドアローン・エンティティ（データの集まり）として示されている。１つの可能性は、構成管理をアプリケーション・サーバーの１つにおけるステートフル・サービスとしてデプロイすることである。更に、多数の構成管理（１つのサイトに１つ）を備えるデプロイメントのオプションを選択することもでき、ここで、１つの構成管理は、コンフィギュレーション・スナップショットを得るために使用され、他の構成管理は、複製（クローン）リソース構造を生成するために使用される。
【００４６】
本発明を説明する図１乃至図４に関して、本発明により提案される拡張は、（１）或るリソースをカプセル化するサービス上の２つの新たなオペレーション及び（２）タイプ・リソースコンフィグレーションの新たなステートフル・サービスを含むように説明される。
【００４７】
本明細書の次のパートにおいて、これらの２つの発明の拡張部についての更なる詳細を説明する。
【００４８】
或るリソースをカプセル化するステートフル・サービスのインターフェースは、２つのオペレーション、ゲットコンフィギュレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィギュレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により拡張される。第１のオペレーションは、コーラー即ち呼び出し者（ｃａｌｌｅｒ）にリソースのオペレーションステートを検索させる。このステートは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのインスタンスに記憶され（以下を参照）、このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンスは、ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションにより戻される。第２のオペレーション、セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーションは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのエンドポイント・リファレンスを入力として得て、そしてこのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されている構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｄａｔａ）をステートフル・サービスによりカプセル化されているリソースに適用する。
【００４９】
前記２つのオペレーションによるステートフル・サービスの拡張（Ｅｘｔｅｎｄｉｎｇ）は下記を含む（リソース・デベロッパーとしてなされなければならない）：
（１） ２つの新たなオペレーション、ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により、サービス・デスクリプション（ＷＳＤＬ，ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｉｏｎ）を拡張（ｅｃｔｅｎｄ）する。
（２） 必要なビジネス・メソッド（ｂｕｓｉｎｅｓｓ ｍｅｔｈｏｄ）ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）及びセットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）により、サービス・エンドポイント・インプリメンテーション（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）を拡張する。例えば、もしもサービスがＥＪＢステートフル・セッション・ビーン（ｂｅａｎ）を使用して実装される（ｉｍｐｌｅｍｅｎｔｅｄ）ならば、ビーンは、この２つの名前を備える２つのパブリック・メソッド（ｐｕｂｌｉｃ ｍｅｔｈｏｄ）により拡張されなければならない。
【００５０】
“ゲットコンフィグレーション”オペレーション：
ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）の実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、下記のタスクを実行しなければならない。
− カプセル化されたリソースの構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｄａｔａ）を記憶するためにリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの新たなインスタンスを生成する。このことは、このリソースに対するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのステートレス・ファクトリィ・オペレーションを呼び出すことにより行われる（下記参照）。新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのエンドポイント・リファレンス（ＥＰＲ）が戻される。次いで、サービスは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスにデータを記憶するためにこのエンドポイント・リファレンス（ＥＰＲ）を使用することができる。
− （リソース管理を介して）カプセル化されたリソースから構成データを取りだし、そしてこの構成データを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶する。
− 及び／若しくは、サービスそれ自身のステート・データから構成データを取り出し、そしてこれを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶する。
− 及び／若しくは、１組の構成データ項目をプログラム的にコンパイルし、そしてこれを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶する。
− この新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（今や、これは複数リソースの全ての関連した構成データ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｄａｔａ）を含んでいる）のＥＰＲをコーラー（ｃａｌｌｅｒ）に戻す。
【００５１】
セットコンフィグレーション（ｓｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーション：
セットコンフィグレーション・データの実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、以下に概略化されたタスクを実行しなければならない。
− このオペレーションに対してパラメータとして渡されたＥＰＲを使用して、関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスをコンタクトし、そしてこのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスから全ての構成データを検索する。
− 各構成データ項目を、カプセル化されたリソースに適用する。
＊リソースを構成（ｃｏｎｆｉｇｕｒｅ）するための適切なコマンドをリソース管理（ｒｅｓｏｕｒｃｅ ｍａｎａｇｅｒ）上で実行する。
＊リソース管理を介して構成データをリソースに記憶する。
− 及び／若しくは、構成データを自分自身に適用する（即ち、ステートフル・サービスはリソースをカプセル化する）−これはステートフル・サービス自体の変更の結果生じる構成データのためのものであり、そしてカプセル化されたリソースとの相互作用を要求しない。
【００５２】
新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス：
リソース・デベロッパ（ｄｅｖｅｌｏｐｅｒ）により与えられるべき本発明の他の実施例は、各リソースのための構成データを記憶するためにリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対する実装人工事実（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ａｒｔｉｆａｃｔｓ）である。
【００５３】
これらの人工事実（ａｒｔｉｆａｃｔｓ）は、下記を含む。
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス（ＷＳＤＬ）のサービス記述（ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｉｏｎ）
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するウエブ・サービス（ＷＳ）エンドポイント（例えば、ＷＳルータ・サーブレット）
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するＷＳエンドポイント・インプリメンテーション（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）（実行されたコード）
【００５４】
エンドポイント・インプリメンテーションは、例えば、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのステート・データを記憶するためにＥＪＢエントリィ・ビーンを使用するＥＪＢステートレス・セッション・ビーンの形で与えられることができる。このような実装（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）は、ステートフル・ウエブ・サービスに対する多くの可能性のうちのたった１つであることに注目されたい。
【００５５】
前記のように名付けられた人工事実の全ては、アプリケーション・サーバーにデプロイされる（ｄｅｐｌｏｙｅｄ）ことができるＥＡＲファイルにおいて互いにパッケージされることができる。クライアントの要求を受け取ると、サーバーは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対するコードを実行することができる。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの１つのオペレーションは、リソースコンフィグレーション・ステートフル・ウエブ・サービスの新たなインスタンスをクライアントに生成させるステートレス・ファクトリィオペレーションである。かくして、このファクトリィ・オペレーションにより、リソースをカプセル化するステートフル・サービスは、これの“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）オペレーション（上記参照）内からリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成し、そしてこれの構成データを新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶することができる。
【００５６】
リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの人工事実を含むＥＡＲファイルは、リソースをカプセル化するステートフル・サービスを含むＥＡＲファイルを保持している同じアプリケーション・サーバー上でデプロイされることができる。この場合、ステートフル・サービスは、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成するときにローカル・アプリケーションと対話する。代わりに、リソースコンフィグレーションＥＡＲファイルは、遠隔にあるアプリケーション・サーバー上でデプロイされることができる。リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスの結果的なアドレス（即ち、リソースコンフィグレーション ＷＳ エンドポイントの関連ＵＲＬと組み合わされた遠隔にあるサーバーのアドレス）は、リソースをカプセル化するステートフル・サービスに知らされねばならない。
【００５７】
図５乃至図７を参照して、リソース構造を複製（クローニング）する本発明の方法の良好な実施例を詳細に説明する。本発明の方法は、次のような複数の処理ステップからなる。
リソース構造の構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）を得る（図５参照）、
リソース・コンフィグレーション・インスタンスを生成する（図６参照）、及び
構成グラフ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｇｒａｐｈ）からソース構造を生成する（図７参照）。
【００５８】
リソース構造の構成を得る詳細なフロー（図５参照）：
前提条件：
− クライアントはワーキングＩＴ環境を有し、ここでリソースはリソース・グラフに組織化されている）。
− クライアントは、リソースをカプセル化するステートフル・ウエブ・サービスへのエンドポイント・リファレンスを介して、リソースをアクセスできる。
− クライアントは、ルート・リソースへのＥＰＲを有する（即ち、グラフ内のリソースからす部手の他のリソースが、ステートフル・ウエブ・サービス関係を考察（ｔｒａｖｅｒｓｅ）することにより見出されることができる）。
− クライアントは、構成管理（ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｒ）のアドレスを知っている。
フロー：
− クライアントは、構成管理（ＣＭ，ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍａｎａｇｅｒ）を呼び出し、固有のルート・リソースを源とするリソース・グラフのコンフィグレーション・スナップショット（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｎａｐｓｈｏｔ）を得る要求を出し；ルート・リソースのＥＰＲがパラメータとして渡される（ｐａｓｓｅｄ）。
− 構成管理（ＣＭ）は，ルート・リソース上の“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”を呼び出す。
− リソースは、リソースに対する全ての構成データを記憶しているリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する。
− 現在処理されているリソースがルート・リソースであるので、生成されたリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲは、一時的に記憶され、そして後にクライアントに戻される。
（このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスは、ソース／リソース構造の全体の構造を表す構造のグラフのルート構造（ｒｏｏｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ）となる）。
− ＣＭは、関連するリソースに対するリソースを問い合わせる（これらの関連するリソースは、ステートフル・ウエブ・サービス関係を介し見出されることができる）；関連するリソースの組は戻される。
− もしも関連するリソースが見出されたならば、現在のリソースのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが一時的に記憶され、関連するリソース毎のリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成され（リソースの“ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”オペレーションを呼び出すことにより）、新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、現在のリソースのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスとの関係において関連づけられる。
このことが、各リソース及びこれに関連するリソース毎に繰り返される。
− もしも複数のリソースの全体のグラフが考察され（ｔｒａｖｅｒｓｅｄ）そしてリソースのグラフと形態（ｔｏｐｏｌｏｇｙ）が同じであるリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフが生成されると、ルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲがクライアントに戻される。
【００５９】
事後条件：
− この段階で、クライアントは、全体のシステム構成（ｓｙｓｔｅｍ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を表すグラフの源となるルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
【００６０】
リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する詳細なフロー（図６参照）：
前提条件：
− ＩＴリソースは、ステートフル・ウエブ・サービス・インスタンスによりカプセル化されている。
− クライアントは、ステートフル・ウエブ・サービス・インスタンスを介してリソースにアクセスする。
− リソースの構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、リソースに記憶されている構成データ、ステートフル・ウエブ・サービスのステート・データからなる。
− リソースをカプセル化しているステートフル・ウエブ・サービスは、リソースの構成データを記憶するために、タイプ（型）に固有のリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのアドレスを知っている。
フロー：
− “ゲットコンフィグレーション（ｇｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ）”オペレーションが呼び出される。
− ステートフル・ウエブ・サービスが、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのファクトリィ・オペレーション（ｆａｃｔｏｒｙ ｏｐｅｒａｔｉｏｎ）を呼び出すことにより、新たなリソースのタイプに固有のリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する。
− 新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲが一時的に記憶され、そして後にＣＭに戻される。
− リソースをカプセル化しているステートフル・ウエブ・サービスが、リソースの構成データを集める。
＊リソースから構成データを検索する。
＊ステートフル・ウエブ・サービスのステート自体に含まれている構成データを集める。
＊幾つかの構成データを“オン・ザ・フライ方式でコンパイルする（例えば、ターゲットのリソース上で後に実行され得る幾つかの構成スクリプト（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｃｒｉｐｔｓ）を生成する）。
− 構成データが、ウエブ・サービス・コールを介してリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶される。
− 新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲが、コーラー（呼び出し者、ｃａｌｌｅｒ）に戻される。
【００６１】
事後条件：
− リソースの完全な構成状態（ｃｏｎｆｉｇｕｒａｔｉｏｎａｌ ｓｔａｔｅ）を記憶している新たなリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成されている。
− コーラー（ｃａｌｌｅｒ）は、このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
【００６２】
構成グラフ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｇｒａｐｈ）からＩＴリソース構成を生成する詳細なフロー（図７）：
前提条件：
− クライアントは、全体のシステム構成（ｓｙｓｔｅｍ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を表すグラフの源となるルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲを有している。
− クライアントは、ターゲットのホスティング基盤（ｈｏｓｔｉｎｇ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に対する構成管理のアドレスを知っている、即ち、ホスティング基盤において、ターゲット・リソース構造が生成されるべきである（この構成管理及び基盤は、ソース・リソース構造と同じである）。
フロー：
− クライアントが、ＣＭ（構成管理）を呼び出し、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフに記憶されている構成データに従ってリソース構造を生成することを要求する。ルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスへのＥＰＲがパラメータとして渡される。
− ＣＭが、リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが関連するリソースのタイプ（型）を検索する。
− ＣＭが、ホスティング基盤から適切なリソースの新たなインスタンスを要求する。
（例えば、ホスティング基盤が、リソース毎のフリー・プールを有し、プールは、ステートフル・ウエブ・サービス・インターフェイスを有するＩＴリソースを含む（本発明の範囲外）。
− ＣＭが、新たなリソースの“セットコンフィグレーション”を呼び出し、現在処理されつつあるリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのＥＰＲをリソースに渡す。
− このリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されている構成データがリソースに適用される。
− ルート・リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが処理されつつあるので、対応するルート・リソースのＥＰＲが一時的に記憶され、そして後にクライアントに戻される。
− 見出されたリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス毎に、ホスティング基盤から適切なタイプのリソースが得られ、構成がこのリソースに適用され、そして、新たなリソースと最後に生成された（即ち、親）リソースとの間の関係が設立される。
このことが、各リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス及びこれの関連する構成毎に繰り返される。
− もしも構成のグラフがたどられ終え（ｔｒａｖｅｒｓｅｄ）そして構成グラフと同じ形態（ｔｏｐｏｌｏｇｙ）を有するリソースのグラフが生成され終えたならば、ルート・リソースのＥＰＲがクライアントに戻される。
【００６３】
事後条件：
− リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフにより記述されているのと同じ形態（ｔｏｐｏｌｏｇｙ）及び構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）を備えるリソース構造が生成され終えている。
− リート・リソースのＥＰＲがクライアントに戻される。
− 今や、クライアントは、新たなリソース構造を使用することができ、複数のリソースが、ＥＰＲによりアドレスされるステートフル・ウエブ・サービスを介してアクセスされ、全てのリソースがルート・リソースで開始する複数の関係を考察（ｔｒａｖｅｒｓｅ）することにより見出されることができる。
【図面の簡単な説明】
【００６４】
【図１】ステートフル・ウエブ・サービスとしての１つのリソースを示す図である。
【図２】本発明に従って複製（クローン）されるべきＩＴリソースの例を示す図である。
【図３】図２に示されているＩＴリソース構造の構成スナップショットを得るための本発明の方法を示す図である。
【図４】図３に示されている以前に得られた構成スナップショットから１つの複製（クローン）ＩＴリソース構造を作り出すための本発明の方法を示す図である。
【図５】構成スナップショットを得るための本発明の良好な実施例のフロー・チャートを示す図である。
【図６】リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する本発明の良好な実施例のフロー・チャートを示す図である。
【図７】構成グラフからＩＴリソース構造を生成する本発明の良好な実施例のフロー・チャートを示す図である。
【符号の説明】
【００６５】
１ ステートフル・ウエブ・サービス
２ ＩＴリソース
３ 通信プロトコル
４ インスツルメント・サーバー
５ ウエブ・サービス・コンテナ
６ データベース
７ オペレーティング・システム・サービス／リソース
８ ウエブ・サービス・プロトコル
９ ウエブ・サービス・インターフェース
１０．１３ ステイフル・サービス
１１，１４ 構成管理インターフェース
１２，１５ インターフェース
１６，１７ 関係
１８，１９，２０ リンク
２１ データベース
２２ クライアント
２３ ウエブ・サービス・コール
２４ 構成管理
Claims (11)
- 現存するＩＴリソース構造の各リソースがステートフル・ウエブ・サービスを介してアクセスされ、各ステートフル・ウエブ・サービスが、リソースの構成状態を問い合わせするために、又は前記リソース上のオペレーションをセット・アップするために、又は前記問い合わせ及び前記セット・アップの両方を行うために、リソースの型に固有のウエブ・サービスを提供し、各ステートフル・ウエブ・サービス・インターフェースがリソース及び関連するリソースの構成状態のスナップショットを取得するオペレーションである“ゲットコンフィグレーション”及びリソースの構成状態を以前にセイブされたステートにセットするオペレーションである“セットコンフィグレーション”を与えるインターフェイスを提供する、前記現存するＩＴリソース構造を、新たなＩＴリソース構造として自動的に複製する方法であって、
前記“ゲットコンフィグレーション”オペレーションを使用して、前記リソースにおけるリソース間の関係を有する各リソースの構成状態のスナップショットを取得して、そして各リソース毎に、前記構成状態を別個の“リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス”として記憶するステップと、
前記スナップショットを使用してグラフを自動的に作成するステップであって、前記グラフのノードが前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを表し、各リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが特定のリソースの構成情報のデータへのアクセスを与え、そして前記グラフのエッジが前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス相互間の関係を表す、前記ステップと、
前記グラフに基づいて、同じ形態のグラフ構造をもつ新たなＩＴリソース構造を生成し、そして前記オペレーション“セットコンフィグレーション”を使用して前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのそれぞれにより与えられた前記構成状態を前記新たなＩＴリソース構造のそれぞれの対応する前記リソースに適用するステップとを含む前記方法。 - 前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが割り当てられたプロパティ・リソース・タイプ、並びに前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成された日付及び時刻を特定するタイム・スタンプを与える、請求項１に記載の方法。
- 前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが割り当てられたリソースの構成状態を表すリソース・タイプ固有のプロパティを与える、請求項２に記載の方法。
- 前記スナップショットを得るステップ及び該スナップショットを使用してグラフを自動的に作成するステップが、
アドミニストレータにより特定されるルート・リソースで開始する上記ＩＴリソース構造をたどるステップと、
前記オペレーション“ゲットコンフィグレーション”を使用して前記ルート・リソースに対するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成するステップと、
前記ルート・リソースの関連するリソースを調べ、そして関連するリソース毎にリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成するステップと、
上記関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを、上記ルート・リソースに対するコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対して、オン・デマンド環境内のリソースの互いの関連である、ステートフル・ウエブ・サービス関係に関連づけるステップと、
前記ＩＴリソース構造のリソース毎に前記ステップを繰り返すステップとを含む、請求項１に記載の方法。 - 新たなＩＴリソース構造を生成するステップが、
アドミニストレータにより特定されたルート・リソースに対するコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスで開始するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフをたどるステップと、
割り当てられているリソースのタイプに対する前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを問い合わせるステップと、
リソース管理から前記タイプのリソースを要求するステップと、
前記オペレーション“セットコンフィグレーション”を呼び出すことにより、前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶された構成状態を前記リソースに適用するステップと、
前記関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを調べるステップと、
前記関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス毎のリソースを要求し、そして、前記それぞれのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されているそれぞれの構成を前記要求されたリソースに適用するステップとを含む、請求項１に記載の方法。 - 現存するＩＴリソース構造の各リソースがステートフル・ウエブ・サービスを介してアクセスされ、各ステートフル・ウエブ・サービスが、リソースの構成状態を問い合わせするために、又は前記リソース上のオペレーションをセット・アップするために、又は前記問い合わせ及び前記セット・アップの両方を行うために、リソースの型に固有のウエブ・サービスを提供し、各ステートフル・ウエブ・サービス・インターフェースがリソース及び関連するリソースの構成状態のスナップショットを取得するオペレーションである“ゲットコンフィグレーション”及びリソースの構成状態を以前にセイブされたステートにセットするオペレーションである“セットコンフィグレーション”を提供する、前記現存するＩＴリソース構造を、新たなＩＴリソース構造として自動的に複製するシステムであって、
前記“ゲットコンフィグレーション”オペレーションを使用して、前記リソースにおけるリソース間の関係を有する各リソースの構成状態のスナップショットを取得する手段、及び各リソース毎に、前記構成状態を別個の“リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス”として記憶する手段と、
前記スナップショットを使用してグラフを自動的に作成する手段であって、前記グラフのノードが前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのインスタンスを表し、各リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが特定のリソースの構成情報のデータへのアクセスを与え、そして前記グラフのエッジが前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス相互間の関係を表す、前記手段と、
前記グラフに基づいて同じ形態のグラフ構造をもつ新たなＩＴリソース構造を生成し、そして前記オペレーション“セットコンフィグレーション”を使用して前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのそれぞれにより与えられた前記構成状態を前記新たなＩＴリソース構造のそれぞれの対応する前記リソースに適用する手段とを含む前記システム。 - 前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが割り当てられたプロパティ・リソース・タイプ、並びに前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが生成された日付及び時刻を特定するタイム・スタンプを与える、請求項６に記載のシステム。
- 前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが、該リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスが割り当てられたリソースの構成状態を表すリソース・タイプ固有のプロパティを与える、請求項７に記載のシステム。
- 前記スナップショットを得る手段及び該スナップショットを使用してグラフを自動的に作成する手段が、
アドミニストレータにより特定されるルート・リソースで開始する上記ＩＴリソース構造をたどる手段と、
前記オペレーション“ゲットコンフィグレーション”を使用して前記ルート・リソースに対するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する手段と、
前記ルート・リソースの関連するリソースを調べ、そして関連するリソース毎にリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを生成する手段と、
上記関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを、上記ルート・リソースに対するコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに対して、オン・デマンド環境内のリソースの互いの関連である、ステートフル・ウエブ・サービス関係に関連づける手段と、
前記ＩＴリソース構造のリソース毎に前記手段のオペレーションを繰り返す手段とを含む、請求項６に記載のシステム。 - 新たなＩＴリソース構造を生成する手段が、
アドミニストレータにより特定されたルート・リソースに対するコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスで開始するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスのグラフをたどる手段と、
割り当てられているリソースのタイプに対する前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを問い合わせる手段と、
リソース管理から前記タイプのリソースを要求する手段と、
前記オペレーション“セットコンフィグレーション”を呼び出すことにより、前記リソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶された構成状態を前記リソースに適用する手段と、
前記関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスを調べる手段と、
前記関連するリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンス毎のリソースを要求し、そして、前記それぞれのリソースコンフィグレーション・ステートフル・ウエブ・サービス・インスタンスに記憶されているそれぞれの構成を前記要求されたリソースに適用する手段とを含む、請求項６に記載のシステム。 - コンピュータに請求項１乃至請求項５のいずれか１つに記載のステップを実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06100942 | 2006-01-27 | ||
| PCT/EP2006/070118 WO2007085336A1 (en) | 2006-01-27 | 2006-12-21 | Method, system and computer program product for automatically cloning it resource structures |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009524860A JP2009524860A (ja) | 2009-07-02 |
| JP4620784B2 true JP4620784B2 (ja) | 2011-01-26 |
Family
ID=38036368
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008551680A Expired - Fee Related JP4620784B2 (ja) | 2006-01-27 | 2006-12-21 | 現存するｉｔリソース構造を自動的に複製する方法及びシステム |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7747709B2 (ja) |
| EP (1) | EP1974498B1 (ja) |
| JP (1) | JP4620784B2 (ja) |
| CN (1) | CN101351992B (ja) |
| AT (1) | ATE435540T1 (ja) |
| DE (1) | DE602006007623D1 (ja) |
| WO (1) | WO2007085336A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9621420B2 (en) | 2011-12-21 | 2017-04-11 | International Business Machines Corporation | Network device configuration management |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ATE435540T1 (de) * | 2006-01-27 | 2009-07-15 | Ibm | Verfahren, system und computerprogrammprodukt zum automatischen klonen von it- betriebsmittelstrukturen |
| US8127270B1 (en) * | 2007-04-09 | 2012-02-28 | Cisco Technology, Inc. | Abstracting transformation for model driven architecture |
| JP2010524121A (ja) * | 2007-04-13 | 2010-07-15 | トムソン ライセンシング | システムソフトウェア製品化フレームワーク |
| US8095488B1 (en) | 2007-12-31 | 2012-01-10 | Symantec Corporation | Method and apparatus for managing configurations |
| US8051028B2 (en) * | 2007-05-31 | 2011-11-01 | Symantec Corporation | Method and apparatus for generating configuration rules for computing entities within a computing environment using association rule mining |
| US8583610B2 (en) * | 2008-03-04 | 2013-11-12 | International Business Machines Corporation | Dynamically extending a plurality of manageability capabilities of it resources through the use of manageability aspects |
| US8037289B1 (en) * | 2008-06-02 | 2011-10-11 | Symantec Corporation | Method and apparatus for cloning a configuration of a computer in a data center |
| GB2483568B (en) * | 2009-03-19 | 2014-06-11 | Fujitsu Ltd | Access control apparatus, information management apparatus, and access control method |
| US8533230B2 (en) * | 2009-06-24 | 2013-09-10 | International Business Machines Corporation | Expressing manageable resource topology graphs as dynamic stateful resources |
| US9122595B2 (en) * | 2012-01-13 | 2015-09-01 | NetSuite Inc. | Fault tolerance for complex distributed computing operations |
| US9003231B1 (en) | 2012-04-16 | 2015-04-07 | Google Inc. | System for instantiating service instances for testing in a known state |
| US9172621B1 (en) * | 2013-04-01 | 2015-10-27 | Amazon Technologies, Inc. | Unified account metadata management |
| WO2016004556A1 (zh) | 2014-06-17 | 2016-01-14 | 华为技术有限公司 | 业务流的处理方法、装置及设备 |
| EP4091076A4 (en) * | 2020-01-16 | 2024-02-14 | Southend Technologies, Inc. | AUTOMATED WEBSITE CREATION AND DEPLOYMENT |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1150360A (zh) * | 1995-11-07 | 1997-05-21 | 中国人民解放军信息工程学院 | 全分散复制式t型数字交换网络 |
| US7392391B2 (en) * | 2001-11-01 | 2008-06-24 | International Business Machines Corporation | System and method for secure configuration of sensitive web services |
| US20070220370A1 (en) * | 2006-01-12 | 2007-09-20 | International Business Machines Corporation | Mechanism to generate functional test cases for service oriented architecture (SOA) applications from errors encountered in development and runtime |
| ATE435540T1 (de) * | 2006-01-27 | 2009-07-15 | Ibm | Verfahren, system und computerprogrammprodukt zum automatischen klonen von it- betriebsmittelstrukturen |
-
2006
- 2006-12-21 AT AT06849413T patent/ATE435540T1/de not_active IP Right Cessation
- 2006-12-21 DE DE602006007623T patent/DE602006007623D1/de active Active
- 2006-12-21 WO PCT/EP2006/070118 patent/WO2007085336A1/en active Application Filing
- 2006-12-21 CN CN2006800496087A patent/CN101351992B/zh not_active Expired - Fee Related
- 2006-12-21 EP EP06849413A patent/EP1974498B1/en active Active
- 2006-12-21 JP JP2008551680A patent/JP4620784B2/ja not_active Expired - Fee Related
-
2007
- 2007-01-05 US US11/620,206 patent/US7747709B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9621420B2 (en) | 2011-12-21 | 2017-04-11 | International Business Machines Corporation | Network device configuration management |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1974498A1 (en) | 2008-10-01 |
| ATE435540T1 (de) | 2009-07-15 |
| CN101351992A (zh) | 2009-01-21 |
| EP1974498B1 (en) | 2009-07-01 |
| US20070198667A1 (en) | 2007-08-23 |
| DE602006007623D1 (de) | 2009-08-13 |
| JP2009524860A (ja) | 2009-07-02 |
| CN101351992B (zh) | 2012-06-13 |
| US7747709B2 (en) | 2010-06-29 |
| WO2007085336A1 (en) | 2007-08-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4620784B2 (ja) | 現存するｉｔリソース構造を自動的に複製する方法及びシステム | |
| CN109194506B (zh) | 区块链网络部署方法、平台及计算机存储介质 | |
| US11714665B2 (en) | Method and apparatus for composite user interface creation | |
| US20220070122A1 (en) | Method and Apparatus for Composite User Interface Generation | |
| US7562132B2 (en) | Method and system for restricting and enhancing topology displays for multi-customer logical networks within a network management system | |
| US8176484B2 (en) | One click deployment | |
| US7103647B2 (en) | Symbolic definition of a computer system | |
| US9847905B2 (en) | System and method for identity management providers in a cloud platform environment | |
| US8380785B2 (en) | Managing rule sets as web services | |
| CN105959168B (zh) | 网络复制的技术 | |
| US20020116454A1 (en) | System and method for providing communication among legacy systems using web objects for legacy functions | |
| US20080189713A1 (en) | System and Method for Performing Systems Management on IT-Resources Using Web Services | |
| CN113301116B (zh) | 微服务应用跨网络通信方法、装置、系统及设备 | |
| US20080189402A1 (en) | Method and Respective System for Performing Systems Management on IT-Resources Using Web Services | |
| JP2005505055A (ja) | モバイルウェブクライアントに対する方法、装置及びシステム | |
| JP2004533687A (ja) | コンピュータ・ネットワークにおけるサービスの動的配備 | |
| JP3307329B2 (ja) | ネットワーク構成管理対象アクセスシステム及び方法 | |
| US8655757B1 (en) | System and method for assigning a unique asset identity | |
| JP5886901B2 (ja) | 装置へのコンテンツの分配を管理するシステムと方法とプログラムを提供する記憶媒体 | |
| US8577761B1 (en) | System and method for dynamic offering topologies | |
| JP2002526858A (ja) | ソフトウェアシステム開発フレームワーク | |
| US9946585B1 (en) | System and method for asset module isolation | |
| US20060047781A1 (en) | Method and system for providing remote portal service modules | |
| Peris et al. | LCG-2 user guide | |
| US10346149B1 (en) | System and method for managing asset-side offering modules |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20090924 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20100616 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20100712 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100720 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101004 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20101026 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20101028 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131105 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |