JP2001222436A - リソースの自動化管理をサポートする方法、そのシステム、およびその記録媒体 - Google Patents

リソースの自動化管理をサポートする方法、そのシステム、およびその記録媒体

Info

Publication number
JP2001222436A
JP2001222436A JP2000384328A JP2000384328A JP2001222436A JP 2001222436 A JP2001222436 A JP 2001222436A JP 2000384328 A JP2000384328 A JP 2000384328A JP 2000384328 A JP2000384328 A JP 2000384328A JP 2001222436 A JP2001222436 A JP 2001222436A
Authority
JP
Japan
Prior art keywords
request
supporter
requests
resource
program
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.)
Pending
Application number
JP2000384328A
Other languages
English (en)
Inventor
Norbert Luntz
ドクター・ノルベルト・レンツ
Frank Milk
フランク・ミールケ
Ralph Teren
ラルフ・テレン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2001222436A publication Critical patent/JP2001222436A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

(57)【要約】 【課題】 自動化ソフトウェア構成のための要求スケジ
ューラを提供すること。 【解決手段】 本発明は、ユーザ・サイトでの要件セッ
トアップへのソフトウェアの適合の分野に関する。本発
明は、異種システム管理環境でのソフトウェアの自動的
構成に適する。具体的に言うと、本発明は、リソース
（１２、１４、１６）の自動化管理に関し、さらに具体
的には、ソフトウェア・プログラムの自動化構成に関す
る。基本的に、本発明は、要求を含むリポジトリ（１
８）にアクセスするステップと、前記要求を順序付け、
バンドルするなどの意味で前記要求を再編成するステッ
プと、たとえば前記要求のサービスを処理するサポータ
などのリソース管理プログラムを呼び出すステップとの
シーケンスを提案する。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、ユーザ・サイトで
の要件セットアップへのソフトウェアの適合の分野に関
する。具体的には、本発明は、相互依存するリソースの
自動化管理に関し、さらに具体的には、ソフトウェア・
プログラムの自動化構成に関する。
【０００２】
【従来の技術】本発明には、広範囲の使用法が含まれ
る。本発明の基本概念は、特定の度合まで利用すること
によって他のリソースの可用性の度合が影響を受けるリ
ソースに関して並列要求を管理する際の問題の解決に対
して、成功裡に適用することができる。その一例が、複
数の要求元の間で共用されるリソースの間の相互依存性
である。さらに、コンピュータ環境、特に、単一の機関
すなわちシステム・マネージャによって複数のリソース
要件を満足することが求められ、前記要件を満足するた
めに行われる作業が非常に複雑である状況に関係する、
多数の問題を解決することができる。複雑さは、複数の
異なる理由に基づく可能性があり、たとえば、１つの要
件の満足が、１つまたは複数の他の要件に影響し、質ま
たは量の判断基準の変更を引き起こす可能性がある。ま
たは、いわゆる「やり直し（ＵＮＤＯ）」すなわち、い
くつかの要件を満足する前に優勢であった状態の回復を
実行することの困難さである。
【０００３】したがって、潜在的な使用法の一例が、特
に別のプロセスを操作するためにあるプロセスの完了が
必要である時に、エンキュー・プロセスが最適化された
形でサービスされる形でリソースへのアクセスが管理さ
れるキュー管理である。
【０００４】しかし、使用法の特定の領域は、ソフトウ
ェア・プログラムの構成またはカスタマイズもしくはそ
の両方である。このソフトウェアという用語に含まれる
のは、明示的にすべての種類のソフトウェア、すなわ
ち、アプリケーション・プログラム、ミドルウェア・プ
ログラム、およびオペレーティング・システム・プログ
ラムである。この使用法の領域、具体的にはアプリケー
ション・プログラムは、本明細書では、従来技術とそれ
に関連する短所を議論するために使用される。
【０００５】しばしば、たとえばパーソナル・コンピュ
ータ、ワークステーション、または特にメインフレーム
・コンピュータなどの１つのハードウェア・システム
が、複数のビジネス・アプリケーション・プログラムを
ホストするように設計され、それを目的とする。
【０００６】一般に、たとえばユーザＩＤ、ＴＣＰ／Ｉ
Ｐアドレス、またはプリンタ、プロッタなどの異なる周
辺デバイスなどの論理システム・リソースまたは物理シ
ステム・リソースが、これらのプログラムによって、共
用される形で使用される。したがって、一般に、そのよ
うなプログラムは、カスタマイズされなければならな
い、すなわち、エンドユーザ・サイトで優勢な状況に適
合させなければならない。これは、使用されるコンピュ
ータのオペレーティング・システムによって使用される
システム変数の設定を実行することも必要とする。しか
し、異なるアプリケーション・プログラムが、システム
変数の異なる設定を必要とする場合がある。使用される
システム変数の種類によっては、誤った設定が、基礎と
なるコンピュータ・ハードウェアの正しい動作を損ねる
可能性があり、したがって、最終的にプログラムの打切
りを引き起こす可能性があり、これは、非分散ビジネス
・オペレーションにとって有害である。
【０００７】使用されるハードウェアの種類に応じて、
システム変数の数は、最新のオペレーティング・システ
ムを有するＰＣの場合の約百個から、クラスタ化された
メインフレーム・コンピュータ・システムのシステム環
境で定義される数十万個の範囲におよぶ。したがって、
ある程度の複雑さは、システム変数の数だけによって引
き起こされる可能性がある。
【０００８】従来技術のメインフレーム・コンピュータ
では、たとえばＩＢＭ ＯＳ／３９０製品の自動化カス
タマイズは、使用可能ではない。したがって、システム
管理者は、製品を手作業でカスタマイズしなければなら
ず、時には特殊なユーティリティの助けを借りるが、そ
の場合でも、オペレーティング・システムの基本的な部
分に関する詳細なノウ・ハウ、および、通常はオペレー
ティング・システムと１つまたは複数のアプリケーショ
ン・プログラムの間のある種の中間層を形成するいわゆ
るミドルウェア製品に関する詳細なノウ・ハウが必要で
ある。上で述べたシステム変数の特定の設定の間の相互
依存性が、非常に複雑になる可能性があり、関係する問
題に対する概観を保つ方法は、個人的すなわち、システ
ム管理者の個人的行動に依存する。したがって、アプリ
ケーション・プログラムの構成またはカスタマイズとい
う作業は、非常に困難である。
【０００９】Windows 98またはWindows NTなどの他のプ
ラットホームの場合、InstallShieldなどのスクリプト
主導のカスタマイズ・ステップが存在する。これらのス
クリプトは、エンドユーザが手作業で何かを行う必要を
なくすために提供される。これらのスクリプトは、前記
アプリケーション・プログラムを成功裡に始動し、使用
することができる形でコンピュータ・リソースをカスタ
マイズするために、アプリケーション・プログラムと共
に提供される。
【００１０】この手法の短所は、スクリプトで実行され
るすべてのステップを、アプリケーション・プログラマ
がプログラミングしなければならず、オペレーティング
・システムの詳細に関して詳しく知る必要があることで
ある。これらを１つのスクリプトに組み込むプロセス
は、特に障害の場合に、細分性がないので、信頼性およ
び有用性も制限する。
【００１１】
【発明が解決しようとする課題】したがって、本発明の
目的は、すべてが同一の管理単位をターゲットとする複
数の並列リソース要件を、たとえばシステム管理者の参
加を減らす、改良された形で管理できるようにする方法
およびシステムを提供することである。
【００１２】本発明のもう１つの目的は、アプリケーシ
ョン・プログラムの自動化構成または自動化カスタマイ
ズもしくはその両方のための方法およびシステムを提供
することである。
【００１３】本発明の前記目的は、同封の独立請求項に
記載された特徴によって達成される。本発明の他の有利
な配置および実施形態は、それぞれの従属請求項に記載
されている。
【００１４】
【課題を解決するための手段】明瞭さを高めるために、
本発明の範囲を正しく定義するために、本明細書で使用
するいくつかの特定の用語を定義する。
【００１５】本発明は、すべての種類のソフトウェアす
なわち、アプリケーション、ミドルウェア、およびオペ
レーティング・システム・ソフトウェアに適用される。
【００１６】複数のシステム・リソースを使用する、上
で述べたプログラムのいずれかを、本明細書では、それ
がシステム・リソースを使用する新しいソフトウェアを
活用する（exploit）ので、エクスプロイタ製品または
エクスプロイタ（たとえばアプリケーション・プログラ
ム）と称する。
【００１７】システム・リソースのサポータは、前記シ
ステム・リソースを管理するプログラム手段として理解
される。これは、前記特定のシステム・リソースを正し
く扱う方法の大量の知識を含むものと理解される。シス
テム・リソースの管理が非常に複雑な時には、前記知識
に、それぞれが前記リソースの異なる態様を管理するサ
ブタスクの知識および制御が含まれる。
【００１８】用語「バインド」は、エクスプロイタ製品
が使用可能になる形でエクスプロイタ製品をカスタマイ
ズするためにオペレーティング・システム内で変更しな
ければならないリソースの更新という意味で理解された
い。
【００１９】最も広い態様において、要求スケジューリ
ングという発明的概念を、サポータが管理するすべての
タイプのリソースの自動化管理をサポートするために使
用することができる。具体的に言うと、要求スケジュー
リングは、システム管理とソフトウェア製品のカスタマ
イズとに有利に適用することができる。
【００２０】最も一般的な態様によれば、発明的方法に
は、以下のステップが含まれる。それぞれが実行される
アクションまたは達成される所望の状態を定義する要求
を含むリポジトリにアクセスするステップであって、上
記状態が前記リソースのそれぞれに関連する、リポジト
リにアクセスするステップと、前記要求を再編成するス
テップと、前記要求のチェーンを処理するためにリソー
ス管理プログラム手段を呼び出すステップと。しかし、
サポータは、前記要求によるリソースの実際の処理を実
行する。
【００２１】基本的に、前記自動化管理には、前記要求
が順序付けられ、バンドル（bundle）されるなどの意味
で前記要求を再編成することと、リソース管理プログラ
ムすなわち、前記要求へのサービスを処理するための前
記上述のサポータを呼び出すことが含まれる。要求への
サービスをすることによってトリガされるアクション
は、広範囲に変化する可能性があることを理解された
い。
【００２２】要求に対処して、その基本的な機能の内容
および構造が問題のコンピュータ・システムによって維
持され管理されるサービスを提供することができる。そ
の例が、ファイルの更新、セキュリティ・データベース
内のユーザＩＤの作成である。より一般的な例が、デー
タベースからの情報の収集およびリポジトリへの結果の
書込、他のソフトウェア・プログラムの呼出し、特定の
機能性（電話のベルを鳴らすなど）を実行するための他
のハードウェア・デバイスのトリガ、または生産デバイ
スの始動である。
【００２３】上で述べた第２の問題の解決策は、エクス
プロイタ製品を起動するために確立しなければならない
オペレーティング・システム・リソースのリソース状態
を記述する、いわゆる要求定義によってカスタマイズ要
件を表すという手法によって定義される。
【００２４】本発明の一態様に従ってこれを達成するた
めに、たとえばＵＮＩＸ（登録商標）オペレーティング
・システムの／etcディレクトリに含まれる伝統的な構
成ファイルなど、それぞれが特定のオペレーティング・
システム・リソースの責任を負う他のプログラムをトリ
ガして、リソースの必要な状態が確実にセットされるよ
うにすることによって、実行可能ソフトウェアが、カス
タマイズ論理または構成論理もしくはその両方を実行す
ることが必要である。
【００２５】トリガをかけるソフトウェアは、発明的概
念の基本部分を形成し、本明細書では、これを要求スケ
ジューラと称する。トリガされるプログラムを、サポー
タまたはサポータ・プログラムと称する。
【００２６】アプリケーション・プログラムの自動化構
成をサポートする構成のために適用される本発明の基本
的な原理の１つが、要求が、たとえばＬＤＡＰ（Lightw
eight Directory Access Protocol）ベースのディレク
トリなど、顧客固有の環境情報を含むリポジトリ内で完
全に指定されることである。
【００２７】要求スケジューラおよびサポータ・プログ
ラムは、駆動システムで稼動して、特殊な場合として駆
動システム自体とすることのできるターゲット・システ
ム上のリソースを更新する。たとえば、駆動システム上
で要求スケジューラを稼動させるWindowsクライアント
がある場合に、そのWindowsクライアントは、サポータ
・プログラムにトリガをかけて、ＬＡＮサーバ（ターゲ
ット・システム）上のリソースを更新することができ
る。駆動システムがターゲット・システムと同一である
時の特殊な例として、要求スケジューラは、たとえばWi
ndowsクライアント上で稼動しており、したがって、Win
dowsクライアントのリソースを更新する。
【００２８】従来技術では、上で述べたスクリプトに、
どの種類の機能性を実行しなければならないかが記述さ
れる。これは、アプリケーション・プログラマが、この
領域で高い熟練レベルを有する必要があることを暗示す
る。このプログラマは、オペレーティング・システム・
リソースを操作して、プログラムが問題なく稼動し、他
のプログラムに影響しないようにするために必要な事前
条件を満足する方法を知らなければならない。
【００２９】それに対して、発明的プログラム・ツール
「RequestScheduler（要求スケジューラ）」の形の発明
的手法は、エクスプロイタ製品の所望の事前条件が何で
あるかを記述したエクスプロイタ要求をトリガする。本
発明によれば、オペレーティング・システム上でこれを
どのように満足するかという問題は、実装を行う前記サ
ポータ・プログラムによって解決され、これらのサポー
タ・プログラムは、発明的要求スケジューラによって駆
動されて、必要なリソースを変更する。
【００３０】したがって、要求スケジューラの実行は、
従来のスクリプト処理とは異なるパラダイムに基づく。
スクリプトには、特定のリソース状態をセットするため
に何をどのように行うかが記述されるが、発明的要求記
述では、どのリソース状態が必要であるかが記述され
（目的を行う方法ではなく目的だけが記述される）、し
たがって、要求は、スクリプトを記述するよりもはるか
に簡単に指定される。したがって、エクスプロイタ製品
のプログラマは、これ以上のオペレーティング・システ
ム固有の知識を必要とせず、第２に、エクスプロイタ製
品を構成しカスタマイズする作業が、エンドユーザから
隠蔽される。
【００３１】本発明を構成する一般的な態様を要約し
て、発明的要求スケジューラの個々の態様を反映する以
下の基本的な項目を、次に下に示す。
【００３２】１．要求スケジューラによって、要求スケ
ジューラとの均一な形の通信を得るためにサポータ・プ
ログラムが使用しなければならないアーキテクチャ的イ
ンターフェースが定義される。これによって、新しいサ
ポータ・プログラムを、要求スケジューラのコードを変
更せずに要求スケジューラにプラグ・インすることがで
きるという意味での拡張性が保証される。
【００３３】２．要求は、リポジトリから読み取られ、
要求スケジューラがサポータ・プログラムを呼び出す順
序を定義する静的順序関係に従ってソートされる。順序
付けは、要求自体の前にどの要求を実行しなければなら
ないかを記述する要求先行物属性に従って、要求スケジ
ューラによって行われる。エクスプロイタが、複数のサ
ポータに関する要求を有する時に、そのような静的サポ
ータ順序関係によって、すべての要求について各サポー
タを呼び出すことが可能になり、性能が改善される。先
行物属性による要求の順序付けによって、依存要求の実
行シーケンスを定義することが可能になる。
【００３４】３．各サポータは、記述されたリソース状
態を更新する責任を負う要求の順序付きチェーンを得
る。
【００３５】リソース状態記述に従うサポータによるリ
ソースの更新によって、実装の詳細が、エクスプロイタ
および製品ユーザから隠蔽される。エクスプロイタは、
その製品についてオペレーティング・システムの特定の
事前条件を実施する方法について心配する必要はなく、
事前条件が何であるかを定義するだけでよい。
【００３６】４．リポジトリ内で記述される要求は、異
なるエクスプロイタ製品に属することができる、すなわ
ち、要求スケジューラは、複数のエクスプロイタ製品を
構成し、それらを対応するサポータにスケジューリング
することができる。したがって、各サポータの要求チェ
ーンには、異なるエクスプロイタの要求が含まれる可能
性がある。発明的要求スケジューラの実行は、異なるエ
クスプロイタ製品のすべてを１回で構成することができ
るという意味で柔軟である。
【００３７】５．サポータ・プログラムの既知の特徴
は、それらが「羃等性」であることである。
【００３８】この用語によって、前記サポータが、それ
自体が責任を負うリソースを制御することと、サポータ
が複数回呼び出されることが可能であり、羃等性によっ
て引き起こされることであるが、変更すべきものがある
か否かを知ることを理解されたい。サポータ羃等性とい
うこのような特徴を、要求スケジューリングという発明
的概念と組み合わせて有利に利用することができる。こ
れによって、要求スケジューラが、より堅牢になり、実
装の詳細も隠蔽される。
【００３９】６．要求スケジューラは、サポータが、具
体的には既存の要求を詳細化するための、子要求を生成
できるようにする。これは、下でさらに説明するＥＶＡ
ＬＵＡＴＥ（評価）機能性を用いて行われる。子要求の
生成による要求の詳細化によって、要求定義を簡単に外
部化し、カプセル化することができるようになる。構成
される特定のシステムに応じて、サポータは、この機構
を使用して、それぞれがＢＩＮＤ（バインド）ステップ
の実行のサブゴールの責任を負う新しい要求を生成する
ことによって、要求の細分性を高めることができる。さ
らに、これによって、更新機能性の諸部分を他のサポー
タに委任することができるようになる。
【００４０】７．要求スケジューラは、要求スケジュー
ラ・ロギング機構をプロトコル実行フローから使用可能
にすることによって、サポータがＳＩＭＵＬＡＴＥ（シ
ミュレート）モードで稼動できるようにし、サポータに
よって何が行われたかを記述できるようにする。これ
は、シミュレート動作によってリソースが更新されるの
ではなく、どのサポータも、ＳＩＭＵＬＡＴＥモードが
オフにされた場合に行われるはずのものをログ・ファイ
ルに記述する、すなわち、現実が「シミュレート」され
ることを意味する。そのような要求のシミュレーション
によって、サポータが、実際にリソースを更新せずに、
どの種類の作業が行われるかをログ・ファイルに記入で
きるようになる。たとえば、セキュリティ管理者は、変
更を自動的に実行したくない場合に、リソース変更をシ
ミュレートし、その後、どのアクションが自動的に行わ
れるかについてログ・ファイルを検査することができ
る。その後、セキュリティ管理者は、アクションを自動
的または手動で行うか、リソース状態の更新を全く行わ
ないかを決定することができる。
【００４１】８．リソースの更新すなわち、下で説明す
る要求スケジューラ・オプションＢＩＮＤを用いる駆動
は、有利なことに、このリソースの活動化から分離され
る。したがって、要求スケジューラは、ＢＩＮＤ中にサ
ポータによって生成された活動化要求の実行のためのＡ
ＣＴＩＶＡＴＩＯＮ（活動化）機能性を有する。ＢＩＮ
ＤとＡＣＴＩＶＡＴＥの間の分離という前記発明的特徴
は、ユーザに両方を１ステップで実行することを強制し
ない。したがって、システム管理者がまずリソース更新
を検査することが有利に思える場合には、システム管理
者は、それを行った後にそのリソース更新を活動化する
ことができる。もう１つの長所は、互いに独立な異なる
２つの時点を、これらのタスクを行うのに使用すること
ができることである。
【００４２】９．「ＵＮＢＩＮＤ（バインド解除）実
行」という発明的特徴は、上で述べたＢＩＮＤ中に使用
される静的順序関係および要求の先行物順序付けに従っ
て、逆の順序で逆転された要求変更を用いてサポータを
トリガする。したがって、ＵＮＢＩＮＤは、新しい要求
として明示的に逆転を指定せずにリソース変更を自動的
に逆転する重要な機能である。ＢＩＮＤ機能からの要求
が使用され、逆実行は自動的に行われる。したがって、
システム管理者の作業が軽減される。
【００４３】１０．要求スケジューラは、ＢＩＮＤを用
いてサポータを呼び出す前に、ＣＨＥＣＫ＿ＢＩＮＤ
（バインド検査）を用いて各サポータを呼び出す。ＣＨ
ＥＣＫ＿ＢＩＮＤ中に、どのサポータもが、実際にＢＩ
ＮＤを行うすなわち、リソースを更新するために呼び出
される前に、事前条件を検査する機会を与えられる。本
発明の好ましい特徴によれば、ＣＨＥＣＫ＿ＢＩＮＤを
行う前に、必要な最小のバージョンのサポータがインス
トールされているかどうかが検査される。そうである場
合には、サポータが呼び出され、そうでない場合には、
バージョン不一致メッセージがログ・ファイルに書き込
まれ、要求スケジューラが終了する。このステップは、
ＡＣＴＩＶＡＴＥ（ＣＨＥＣＫ＿ＡＣＴＩＶＡＴＥ（活
動化検査））の場合にもあてはまる。
【００４４】ＢＩＮＤを用いてサポータを呼び出す前に
ＣＨＥＣＫ＿ＢＩＮＤ機能を用いて各サポータを呼び出
すことによって、すべてのサポータがエラーなしでリソ
ース更新を実行できる時に限って、実際のリソースに対
する更新が行われることが保証される。これによって、
ＢＩＮＤ中の障害の危険性が減るので、この複雑な動作
の信頼性が高まる。バージョン不一致検出アルゴリズム
も、品質の改善である。というのは、従来技術のシステ
ムでは、これらのバージョン不一致がシステム的には検
出されず、実行時に、非常に低水準のパラメータ・レベ
ルで不一致が存在する時に限って検出され、この不一致
は識別が非常に困難だからである。
【００４５】１１．サポータは、どの種類の機能性をサ
ポートするか、たとえば、活動化要求生成が不要である
場合に、要求スケジューラが機能ＡＣＴＩＶＡＴＥにつ
いてこのサポータを呼び出さない、などを決定すること
ができる。サポータによって実施される機能性の種類
は、サポータのサービス記述すなわち、リポジトリのう
ちで属性「supportType（サポート型）」を有する部分
で指定され、したがって、リポジトリにアクセスするこ
とによって、要求スケジューラからアクセス可能であ
る。したがって、ＰＲＩＭＥと称する初期設定などの、
要求スケジューラがサポートする他の機能性は、特定の
要求スケジューラ機能性のサポータ・プログラム設計に
よって提供されない場合にオンまたはオフに切り替える
ことができる。supportType属性の処理によって、特定
の種類の機能性を実施しないサポータの無用な呼出しが
防止される。したがって、これによって性能が高まる。
【００４６】１２．エンド・ユーザは、カスタマイズ・
プロセス中に、特に、これまでにＯＳ／３９０製品を構
成する自動ソリューションがなかったので、従来技術の
ＩＢＭ ＯＳ／３９０システムの場合に、要求スケジュ
ーラの実施形態から利益を得る。さらに、これはプラッ
トホーム独立機能であり、カスタマイズ・ステップの信
頼性および有用性が、従来技術のスクリプト・プログラ
ム、たとえば従来技術のＷＩＮＤＯＷＳ（登録商標）ベ
ース・システム用のInstallShield手法と比較した時の
要求の細分性によって改善される。
【００４７】１３．要求スケジューラは、有利なこと
に、標準Javaクラス・ローダを使用して、要求スケジュ
ーラが稼動しているのと同一システム上のサポータ・プ
ログラムを呼び出すように実施することができる。それ
にもかかわらず、サポータ・プログラムが要求スケジュ
ーラと異なるシステムに常駐することができるという長
所を有するリモート・クラス・ローダまたはJava ＲＭ
Ｉ（リモート・メソッド呼出し）も使用することがで
き、これは、要求スケジューラの設計が、異なるオペレ
ーティング・システムの利用を含めて、異なるシステム
でのインターオペラビリティに関してオープンであるこ
とを意味する。唯一の前提は、両方のシステムが同一の
リポジトリにアクセスできることである。
【００４８】１４．要求スケジューラは、システム・リ
ソースの更新以外の何かを実施するサポータ・プログラ
ムの実行のトリガをかけるのに使用することもできる。
要求スケジューラは、サポータが実行する作業の種類か
ら独立であるが、サポータ側でどのアクティビティをト
リガするものであっても要求を管理する。
【００４９】１５．ＸＭＬ（Extensible Markup Langua
ge）フォーマットで要求の実行シーケンスが保存される
ログ・ファイルを生成することが、問題領域を検出でき
ない場合の重要な長所である。ＸＭＬフォーマット自体
は、標準ソフトウェアを使用してその内容を簡単にブラ
ウズするために選択された。特に、トレースが設計のア
ーキテクチャ的部分であり、サポータ・プログラムが要
求スケジューラと同一のファイルをトレースできるとい
う事実が、問題の判定を助ける。
【００５０】本発明の重要な有利な特徴は、要求スケジ
ューリングの複雑な流れを、要求スケジューラおよびサ
ポータが使用することのできるロギング機能またはトレ
ーシング機能によって書き込むことができることであ
る。
【００５１】将来のサポータ・プログラムがそのコード
を要求スケジューラにプラグ・インすることができるよ
うにするための有利な設計の問題は、要求スケジューラ
とサポータ・プログラムの間の、呼出しおよび結果通知
のためのアーキテクチャ的インターフェースによって解
決される。
【００５２】要求スケジューラの現在の好ましい構造的
特徴を要約すると、要求スケジューラは、基本的に、入
力を得るための下記の２つのインターフェースを有す
る。
【００５３】第１に、コマンド・ライン呼出しインター
フェース、第２に、リポジトリへのアクセスである。コ
マンド・ライン・インターフェースは、手動でまたは、
たとえばWindowsNTシステム上などのＧＵＩ駆動ツール
によって、トリガすることができる。区別可能な名前を
介して、コマンド・ライン・インターフェースは、要求
を指定するエクスプロイタ・サービスおよび実行される
機能性（ＥＶＡＬＵＡＴＥ、ＢＩＮＤ、ＡＣＴＩＶＡＴ
Ｅ、ＵＮＢＩＮＤ）を指すbindConfiguration（バイン
ド構成）を参照する。これらは、要求スケジューラに与
えられる。駆動システムおよびターゲット・システムの
区別可能な名前も入力される。
【００５４】bindConfigurationを用いて、リポジトリ
内でエクスプロイタ・サービスごとに編成された要求
を、要求スケジューラによってメモリに読み取ることが
できる。要求スケジューラは、これらの要求を、サポー
タ固有のチェーンにグループ化し、これによって、各要
求が、サポータが実行の責任を負う「requestedService
（要求されたサービス）」属性によって定義される。こ
れは、要求スケジューラ設計の重要な特徴なので、以下
の例で、特にＩＢＭ Ｓ／３９０メインフレーム・テク
ノロジに関して説明する。
【００５５】２つのエクスプロイタ・サービスすなわ
ち、ParallelSysplex（並列シスプレックス）およびHom
eBanking（ホームバンキング）と称する、カスタマイズ
されるアプリケーション・プログラムまたは「製品」を
参照するbindConfigurationがあると仮定する。エクス
プロイタParallelSysplexは、サポータＲＡＣＦSecurit
y（ＲＡＣＦセキュリティ）およびそれ自体に対する要
求を定義する。エクスプロイタHomeBankingは、サポー
タＲＡＣＦSecurityに対する２つの要求とサポータParm
libに対する１つの要求を定義する。
【００５６】要求スケジューラは、すべての要求を見つ
け、これらを３つのチェーンに並べる。 ・３つの要求すなわちHomeBankingの２つとParallelSys
plexの１つを含むＲＡＣＦSecurityチェーン、 ・１つの要求を含むParmlibチェーン、 ・１つの要求を含むParallelSysplexチェーン。
【００５７】要求のチェーンが順序付けられるという事
実と、これを行う方法が、もう１つの重要な発明的特徴
である。サポータ順序関係は、リポジトリ内で定義さ
れ、サポータの実行シーケンスを表す。
【００５８】さらに、要求スケジューラには、要求の先
行物属性によって特定される先行物属性に従ってサポー
タ要求チェーンを順序付けるための順序付け機構が含ま
れる。同一の要求されたサービス名を有する別の要求へ
の参照を有する先行物属性によって参照される要求は、
要求チェーン内で、先行物属性を含む要求の前になる。
【００５９】さらに、要求スケジューラは、有利なこと
にモジュラー式に実施することができる。したがって、
要求スケジューラは、複数（本明細書では基本的に４
つ）の主機能を提供し、これらの機能は、ＥＶＡＬＵＡ
ＴＥ、ＢＩＮＤ、ＡＣＴＩＶＡＴＥ、およびＵＮＢＩＮ
Ｄの順で成功裡に実行されることが予定されている。し
たがって、要求スケジューラは、エクスプロイタ・サー
ビスをオペレーティング・システムに成功裡にバインド
するために３回呼び出すことができ、エクスプロイタ・
サービスをＵＮＢＩＮＤするために１回呼び出すことが
できる。
【００６０】要求スケジューラは、有利なことに、サポ
ータ・プログラムが要求スケジューラによって供給され
るＡＰＩにアクセスできるようにするSupporterObject
（サポータ・オブジェクト）を入力として用いてサポー
タ機能性を呼び出す。このSupporterObjectには、要求
チェーンとトレーシングおよびロギングに関する情報と
が含まれて、上で説明し、リポジトリの説明中でも説明
した静的順序関係に従って、サポータ・プログラムがこ
れらの機能を使用するのが簡単になっている。
【００６１】要求スケジューラのもう１つの重要な発明
的特徴が、実行シーケンスをＸＭＬログ・ファイルにロ
ギングすることである。これによって、要求スケジュー
ラおよびサポータ・プログラムが、そのアクティビティ
の一貫性のある実行シーケンスを生成でき、要求のシミ
ュレーションを可能にすることができるようになる。こ
こで、シミュレーションは、リソース内で要求を実行す
るのではなく、シミュレート・モードがオフに切り替え
られた場合に行われるはずのものを記述することを意味
する。
【００６２】エクスプロイタ要求のスケジューリングに
適用される発明的方法の４つの基本的な機能性を、次に
下に要約する。
【００６３】ＥＶＡＬＵＡＴＥ 要求スケジューラは、ＥＶＡＬＵＡＴＥを介して呼び出
された時に、リポジトリ・アクセス・メソッドを提供す
るサポータを呼び出して、既存のバインド要求の子とし
て新しいバインド要求を生成する。その機能性は、サポ
ータがエクスプロイタ要求を詳細化できるようにするた
めに設計された。この理由は、エクスプロイタ製品が、
サポータの詳細を知らず、それについて心配する必要が
ないことを意図されていることである。したがって、サ
ポータが、高水準要求を指定することを許容することが
提案される。これは、最終的にオペレーティング・シス
テムの詳細に依存する対応するサポータによって詳細化
することができる。言い換えると、ある種の要求カスケ
ードを確立することができる。成功裡の評価の後に、ユ
ーザは、リポジトリをブラウズして、前記カスケードに
よって生成された要求を再検討することができ、有利な
ことに、手動で実行される介入が可能であるのでそれら
を変更することができる。その後、要求スケジューラ
を、ＢＩＮＤを用いて呼び出して、生成されたバインド
要求を実行することができる。
【００６４】ＢＩＮＤ 要求スケジューラは、オプションＢＩＮＤを用いて呼び
出された場合に、まず、ＣＨＥＣＫ＿ＢＩＮＤと共に上
で説明した順序関係に従ってすべてのサポータを呼び出
す（上記１０．を参照されたい）。その後、サポータ
は、オプションＢＩＮＤによる要求の実行が失敗するか
否かを検証する責任を有する。すべてのサポータが、Ｏ
Ｋのリターン・コードを返す場合には、それらのサポー
タが、機能ＢＩＮＤと同一の順序で呼び出される。その
後、サポータは、要求のチェーンを介して作業し、リソ
ースを更新する。これらは、エクスプロイタ製品を始動
するためにそのエクスプロイタ製品を構成するのに必要
なリソースである。
【００６５】通常、リソースの更新は、オペレーティン
グ・システム内で更新をアクティブにするためには不十
分である。したがって、活動化の要求を、サポータ・プ
ログラムによって、ＥＶＡＬＵＡＴＥに使用されるもの
と同一の要求スケジューラ・インターフェースを用いて
作成されることができる。
【００６６】ＡＣＴＩＶＡＴＥ オペレーティング・システム内でリソース変更を活動化
するために、オプションＡＣＴＩＶＡＴＥを用いて要求
スケジューラを呼び出すことができる。その後、バイン
ディング中に生成された活動化要求のすべてが、ＢＩＮ
Ｄの場合と同一の形で、サポータが前記オプションＡＣ
ＴＩＶＡＴＥを用いて呼び出される順序関係に従って実
行される。サポータは、活動化要求を実行し、たとえ
ば、セット・コマンドを介してＯＳ／３９０ parmlibメ
ンバを活動化する。セット・コマンドの後に、変更され
たparmlibは、その変更されたパラメータが、たとえば
より多くの仮想記憶を定義するなど、オペレーティング
・システムに、今現在影響しているという意味で、アク
ティブになる。
【００６７】ＵＮＢＩＮＤ ＢＩＮＤ中に、１つの要求を実行できない場合には、bi
ndConfiguration全体を、成功裡にバインドすることが
できない。その場合、要求スケジューラは不成功に終了
する。要求が失敗するまでに成功裡に実行されたリソー
スの変更を除去しなければならない。したがって、オプ
ションＵＮＢＩＮＤを用いて要求スケジューラを呼び出
すことができ、このオプションは、サポータがＢＩＮＤ
と比較して逆の順序で呼び出され、要求チェーンも逆転
されることを強制する。
【００６８】
【発明の実施の形態】本発明を、アプリケーション・プ
ログラムの自動化構成のための要求スケジューラとして
の、前に述べたアプリケーションに関して詳細に説明す
る。本発明のこの好ましい態様は、例として示され、添
付図面の図の形状に制限されない。
【００６９】本発明の好ましい実施形態の以下の詳細な
説明について、ｎ個の複数のアプリケーション・プログ
ラムがメインフレーム上でホストされると仮定する。発
明的の長所は、前記複数のアプリケーション・プログラ
ムの並列構成要求という問題に直面する当業者によって
諒解されるであろう。
【００７０】本発明を構成する基本的な概念によれば、
前記複数のアプリケーション・プログラムは、オペレー
ティング・システムの観点からは、オペレーティング・
システムのリソースを利用するので、エクスプロイタＥ
１、Ｅ２、．．．、Ｅｎとみなされる。
【００７１】図１では、前記エクスプロイタまたはエク
スプロイタ製品が、枠１０によって囲まれており、これ
は、１つの同一のハードウェア・システムが１つの同一
のオペレーティング・システム・リソースと共にそれら
によってアクセスされることを示すことを目的とする。
【００７２】その一方で、前記オペレーティング・シス
テム・リソースは、図１の右側に、符号１２、１４、お
よび１６によって象徴的に示されている。
【００７３】エクスプロイタ製品をインストールする
か、その構成データを更新しなければならない時には、
エクスプロイタ製品Ｅ１、．．．、Ｅｎがオペレーティ
ング・システムのリソースに対する並列要求を有するの
で、その結果のシステム構成の変更が問題を引き起こす
可能性がある。
【００７４】本発明によれば、前記複数の要求が、要求
リポジトリ１８にバンドルされる。前記要求は、図１で
は一部だけが示されており、ｒ１１、ｒ１ｊ、．．．、
ｒｎ１、ｒｎｌによって示される。有利なことに、前記
要求は、ＸＭＬ言語を使用することによって定義され、
要求リポジトリは、ＬＤＡＰベースのディレクトリであ
る。したがって、通常のブラウザ・ツールを用いて、こ
れらの要求をシステム管理者に可視にすることができ
る。
【００７５】前記要求リポジトリ１８内では、要求が、
有利なことにツリー構造に格納される。一般に、各要求
は、前記要求を定義するために、関連する値を書き込ま
れなければならない１つまたは複数の属性を有する。た
とえば、システム内でのユーザの識別を保証する目的の
要求には、下記の属性および値を含めることができる。 要求属性 Objectclass: BindRequest BindRequest: Security1 ConfigurationId: ParallelSysplex RequestedService: RACFSecurity requestedSupportName: ASSURE_USER requestParameters: USERID=THEL requestParameters: GROUP=D1311 RequestStatus: REQUESTED ReturnCode: 0 ReasonCode: 0 minSupportVersion: 1.0
【００７６】有利なことに、たとえば指定された要求の
サービスがシステムの稼動に必要であるか、任意選択で
しかないかを指定する属性など、他の属性を追加するこ
とができる。上の要求定義は、オブジェクト指向プログ
ラミング言語で実施される一例としてのみ理解された
い。一般に、要求を定義する属性の型、数、および値
は、各要求に固有である。しかし、以下の属性は、基礎
となる実施形態に適用されるすべての要求に共通する。
【００７７】要求スケジューラによって呼び出されるサ
ポータ・プログラムの名前を指定するRequestedServic
e。
【００７８】たとえばユーザを保証することなど、要求
された機能性を定義することができる、requestedSuppo
rtName（要求されたサポート名）。
【００７９】ConfigurationId（構成ＩＤ）では、要求
を含むエクスプロイタ構成を識別する一意の文字列を定
義する。
【００８０】requestParameters（要求パラメータ）
は、サポータ固有であり、上の例では、特定のユーザ識
別子およびセキュリティ・サポートに関するグループを
記述する。
【００８１】requestStatus（要求状況）は、要求の現
在の状況を記述する。ＲＥＱＵＥＳＴＥＤ（要求済み）
は、要求を実行しなければならないことを意味する。他
の可能な値は、ＢＯＵＮＤ（バインド済み）、ＢＩＮＤ
＿ＦＡＩＬＥＤ（バインド失敗）、ＥＶＡＬＵＡＴＥＤ
（評価済み）、などである。
【００８２】minSupportVersion（最小サポート・バー
ジョン）には、要求の実行に必要な、サポータのバージ
ョンが含まれる。
【００８３】さらに、要求スケジューラすなわちあるプ
ログラム手段が、符号２０を用いて示されている。前記
要求スケジューラ２０は、読み書きのための標準化され
たインターフェース２２を介して前記要求リポジトリ１
８にアクセスすることができる。
【００８４】さらに、要求スケジューラは、要求を再編
成するが、これについては下でさらに詳細に説明する。
次に、前記要求スケジューラ２０と、複数のサポータＳ
１、Ｓ２、．．．、ＳＭの間に、要求スケジューラが前
記サポータを呼び出せるようにするために、標準化され
たインターフェース２４を設ける。要求スケジューラ２
０の仕事の１つが、図１でｒｉｋと示されている、それ
ぞれがそれぞれのサポータＳ１、．．．、ＳＭに関連す
るサブグループに要求を再編成することである。したが
って、要求のｍ個のチェーンが作成される。これには、
異なるエクスプロイタ製品から要求された複数の要求
を、要求スケジューラが１つの意味的単位として扱うこ
とができ、これによって、同一のリソースに対する単一
の要求の間の相互依存性および異なるリソースの間の相
互依存性の解決を軽減するという長所がある。
【００８５】左向きの矢印は、複数のサポータＳが、ア
クティビティおよびそれがシステム・リソースに及ぼす
影響を図１に示されていないログ・ファイルに報告する
ために、前記標準化されたインターフェースおよび要求
スケジューラを介して要求リポジトリ１８にデータを書
き込むことができることを示す。
【００８６】実際のオペレーティング・システム・リソ
ース１２、１４、および１６は、サポータのみによって
サービスされ、これは、前記サポータおよび前記リソー
スの間の矢印によって示される。
【００８７】共通サポータ／エクスプロイタ・リポジト
リ１７は、利用する製品が読み取るか、利用する製品を
構成するカスタマイズ製品がカスタマイズ中に読み取る
ことができる出力情報を生成するために、サポータが使
用することができる。特殊な事例として、要求リポジト
リおよび共通サポータ／エクスプロイタ・リポジトリ
を、同一の技術（たとえばＬＤＡＰベース・ディレクト
リ）内に統合することができる。
【００８８】本発明に従って複数の要求をバンドルし、
これらを再編成するという発明的手法は、有利なこと
に、複数のアプリケーション・プログラムすなわちエク
スプロイタ製品が、１つのハードウェア・システムにイ
ンストールされる状況で適用することができることに留
意されたい。というのは、この発明的概念によって、シ
ステム・リソースの要求された状態の効果を、システム
内で実際に実行する前に検査することが可能になるから
である。
【００８９】さらに、同一の状況で、「ＵＮＤＯ」機能
を実行することができ、これによって、オペレーティン
グ・システム・リソースの先行する変更の間にシステム
・リソースに対して行われたすべての変更が逆転され
る。
【００９０】ここで図２および図３を参照して、発明的
方法の複数の特徴を含む制御フローの総合的な概要を、
次に下でより詳細に説明する。
【００９１】必ずしも発明的概念を構成しない準備ステ
ップとして、最初のステップ２１０で、前記複数のアプ
リケーション・プログラムによって要求された並列要求
の適合を含むシステムのバインディングを準備する、す
なわち、バインド要求をリポジトリに格納する。
【００９２】その後、ステップ２２０で、発明的要求ス
ケジューラ・ツールを、ＥＶＡＬＵＡＴＥオプションを
介して呼び出す。この評価ステップによって、サポータ
が、それにあてられたそれぞれの要求の内容を読み取
り、その要求を詳細化するためにまだ行わなければなら
ない作業があるかどうかを判定することができるように
なる。そのような要求の詳細化を実現するために、サポ
ータ自体が、１つまたは複数の異なるサポータにあてら
れた要求を生成できるようにされる。これらの要求も、
要求リポジトリに格納される。
【００９３】評価ステップ中に、すべての要求がそれぞ
れのサポータによって処理され、評価ステップの終り
に、すべてのサポータが完全に処理されていることを理
解されたい。これは、複数のサポータを含む外側のプロ
グラム・ループと、１つのサポータにあてられたすべて
の要求を含む第２の内側ループで行われる。
【００９４】その後、ステップ２３０で、システム管理
者が要求リポジトリ１８をブラウズすることができ、こ
の早期の処理段階ですでに、衝突する要求を認識するこ
とができる。
【００９５】その後、ステップ２４０で、バインド実行
ステップを呼び出す。
【００９６】具体的には、バインド実行は、少なくとも
２つの異なる部分すなわち、ステップ２５０で実行され
る第１部分と、ステップ２５０に結果に依存して実行さ
れる２つの他のステップ２６０または２７０のいずれか
に分割される。
【００９７】具体的に言うと、ステップ２５０で、複数
の異なる要求の一貫性を検査する。検査とは、各サポー
タに、それにあてられたすべての要求をサービスできる
かどうかを尋ねることを意味する。この特徴によって、
有利なことに、単一の要求をサービスすることができな
い状況を認識し、それぞれの要求属性から、その要求が
必要であることがサポータに知らされる場合に、正しく
稼動するシステムを維持し、サービスすることのできな
い前記要求によって引き起こされるシステム問題の危険
性を回避するために、所期のシステム変更を停止するこ
とが可能になる。したがって、判断２５２は、前記要求
の一貫性がＯＫであるか否かをもたらす。ＮＯの分岐で
は、ステップ２５４で、システム変更を全く行わずに、
検査を簡単に終了することができる。したがって、シス
テムは変更されないままになる。しかし、ＹＥＳの分岐
では、システム管理者が、変更の実行を望むか、変更の
実行をシミュレートすることを望むかを尋ねられる。そ
の判断２５６を図２に示す。そのＹＥＳの分岐では、ス
テップ２６０で、システム・リソースに対する変更を行
うが、その変更は非アクティブに保たれる。しかし、ス
テップ２７０では、前記変更の実行が、シミュレートさ
れるだけになる。
【００９８】シミュレート・ポリシを用いて、エンドユ
ーザが、リソースに実際には影響せずにバインドまたは
活動化を実行することができる。というのは、このモー
ドでは、すべてのサポータが、リソースを更新するので
はなく、前記ログ・ファイルに実行の詳細を書き込むか
らである。したがって、シミュレートは、所望のシステ
ム変更が有用であるかどうかを検査するという前述の機
能以上のものである。というのは、この態様では、ツー
ルの回答がＹＥＳまたはＮＯだけになるからである。し
かし、シミュレーション・ステップでは、すべての詳細
をログ・ファイルからトレース・バックすることができ
る。
【００９９】その後、次のステップ２８０で、変更を行
った後に、システム管理者がすべての要求をもう一度ブ
ラウズし、制御することができる。
【０１００】その後、コマンド・ラインでＡＣＴＩＶＡ
ＴＥオプションを指定して発明的ツールを新たに呼び出
すことによって呼び出される次のステップ２９０で、行
われた変更の活動化手順が呼び出される。発明的方法の
相当な利益を反映して、このステップは、変更の実行後
のどの時点でも実行することができ、したがって、シス
テム管理者が自由に決定することができる。したがっ
て、活動化ステップは、ステップ２６０の実行の、たと
えば数週間または数ヶ月後に行うことができる。
【０１０１】ここで図３を参照すると、活動化の前に、
ステップ３００でもう一度要求の一貫性を検査する。そ
の後、ステップ３１０で、検査が成功であったか否かを
判定する。そうでない場合には、ステップ３２０で、潜
在的なエラーを手作業で訂正するために、ユーザがログ
・ファイルをブラウズし、編集できるようにする。その
後、もう一度一貫性検査を実行する。成功であった場合
には、ステップ３１０のＹＥＳの分岐で、ステップ３３
０で、ユーザが、活動化の実行を望むか、その代わりに
ステップ３３５で活動化のシミュレーションだけを望む
かを決定しなければならない。シミュレーションの場
合、有利なことに、要求の一貫性をもう一度検査するた
めに制御をステップ３００にフィード・バックするか、
その代わりに、エラーを手作業で訂正するためにステッ
プ３２０にフィード・バックする。ステップ３３０のＹ
ＥＳの分岐では、ステップ３４０で、活動化を実際に実
行する。具体的に言うと、ステップ２６０で行った変更
が活動化され、これは、アクティブ・システム・リソー
スの状態が、要求リポジトリ１８に格納された要求に従
って実際に変更されることを意味する。その後、ステッ
プ３５０で、ユーザが、成功裡の活動化について知らさ
れ、その後、このツールは終了する。
【０１０２】活動化要求のシミュレーションの挙動が、
バインド要求のシミュレーションと同一であることに留
意されたい。サポータは、実行を行わずに、活動化アク
ションの詳細をログ・ファイルに書き込む。
【０１０３】図２および図３に、全体的に、発明的要求
スケジューリング方法が、別々に処理でき呼び出すこと
ができるモジュールで構成されることを示す（ステップ
２２０、２４０、および２９０を参照されたい）。異な
るモジュールの処理は、この例では、コマンド・ライン
・インターフェースを介して行われる異なる呼出しオプ
ションを用いる発明的ツールの呼出しとして実施され
る。たとえばＧＵＩインターフェースなどの他のインタ
ーフェースまたはバッチ指向呼出しも、実施することが
できる。
【０１０４】ここで特に図４を参照して、サポータの実
行およびロギングを、１つのサポータの実行およびロギ
ングに必要なステップだけに関して詳細に説明する。サ
ポータの実行およびロギングの全体としての仕事は、有
利なことに、すべてのサポータを含むループで行われ
る。
【０１０５】最初のステップ５１０で、要求スケジュー
ラが、サポータを呼び出すために必要なデータ、具体的
にはサポータの名前、それを呼び出す方法、およびこの
説明には関係しない他の詳細情報を取り出すために、要
求リポジトリ１８にアクセスする。前記サポータ情報
は、要求リポジトリ１８からなるものとすることができ
るが、別の場所に配置することもできる。さらに、実際
に現在のループ実行に関係するサポータ・プログラムが
バインド要求にアクセスできるようにする準備をするた
めに、すべてのバインド要求を読み取る。
【０１０６】次のステップ５２０で、どの要求が操作さ
れ、どのサポータにあてられたかを追跡するために、そ
の後、すべての要求を、ログ・ファイルすなわち前に述
べたＸＭＬファイルに登録する。
【０１０７】その後、次のステップ５３０で、現在のル
ープ実行が関連するサポータの特定のエントリ・ポイン
トを実行する。活動化要求が実際に存在する場合（図３
のステップ３４０を参照されたい）、サポータは、シス
テム・リソースの事前定義された新しい状態を活動化す
るための実際の作業を実行する。サポータによって実行
されるすべてのアクションが、実行されるすべてのシス
テム変更の概要をシステム管理者が把握できるようにす
るために、ログ・ファイルに書き込まれる。
【０１０８】その後、次のステップ５４０で、要求実行
の結果を、要求の属性を定義する記憶構造に関連する記
憶位置に、要求状況を反映する戻りコードの形で書き込
む。したがって、「要求が成功裡に完了」または「要求
失敗」などのフラグが格納される。
【０１０９】その後、ステップ５５０で、要求スケジュ
ーラによって完全なロギングが実行される、すなわち、
前述のアクティビティを制御するのに必要とみなされる
すべての情報が、システム管理者によってトレース可能
にするためにログ・ファイルに書き込まれる。
【０１１０】その後、すべてのサポータが静的サポータ
順序関係に従って処理されるまで、残りのすべてのサポ
ータについて、ステップ５１０ないし５５０のシーケン
スを繰り返す。
【０１１１】前述の明細書で、本発明の特定の例示的実
施形態に関して本発明を説明した。しかし、請求項に記
載の本発明の広義の趣旨および範囲から逸脱せずに、そ
れに対してさまざまな修正および変更を行えることは明
白である。本明細書および図面は、したがって、制限的
な意味ではなく、例示的なものとみなされなければなら
ない。
【０１１２】本発明は、ハードウェア、ソフトウェア、
またはハードウェアおよびソフトウェアの組合せで実現
することができる。本発明による要求スケジューラ・ツ
ールは、１コンピュータ・システム内で集中化された形
で、または、異なる要素が複数の相互接続されたコンピ
ュータ・システムにまたがって配置される分散化された
形で実現することができる。あらゆる種類のコンピュー
タ・システムまたは本明細書に記載の方法を実行するた
めに適合された他の装置が、適する。ハードウェアおよ
びソフトウェアの通常の組合せは、ロードされ実行され
る時にコンピュータ・システムが本明細書に記載の方法
を実行するようにコンピュータ・システムを制御するコ
ンピュータ・プログラムを伴う汎用コンピュータ・シス
テムとすることができる。
【０１１３】本発明は、本明細書に記載の方法の実施形
態を可能にするすべての特徴を含み、コンピュータ・シ
ステムにロードされた時にこれらの方法を実行すること
ができる、コンピュータ・プログラム製品で実施するこ
ともできる。
【０１１４】この文脈でのコンピュータ・プログラム手
段またはコンピュータ・プログラムは、直接に、または ａ）別の言語、コード、または表記への変換と、 ｂ）異なる材料形態での再生産とのいずれかまたは両方
の後に、情報処理能力を有するシステムに特定の機能を
実行させることを目的とする命令の組の、いずれかの言
語、コード、または表記でのすべての表現を意味する。
【０１１５】まとめとして、本発明の構成に関して以下
の事項を開示する。
【０１１６】（１）サポータが所有するリソース（１
２、１４、１６）の自動化管理をサポートする方法であ
って、実行されるべきアクションまたは達成されるべき
所望の状態をそれぞれが定義する要求を含むリポジトリ
（１８）にアクセスするステップ（５１０）であって、
前記状態が、それぞれの前記リソース（１２、１４、１
６）に関連するステップと、前記要求を再編成するステ
ップ（５２０）と、前記要求のチェーンを処理するリソ
ース管理プログラム手段を呼び出すステップ（５３０）
とを含む方法。 （２）前記要求が、オペレーティング・システムによっ
て維持されるリソース（１２、１４、１６）の所望の状
態を定義し、前記方法が、前記リソースが前記要求に従
ってセットされることを保証するサポータ・プログラム
手段を呼び出す（２２０、２４０、２６０、２９０）ス
テップを含む、プログラムの自動化構成をサポートする
ために使用される、上記（１）に記載の方法。 （３）サポータ・プログラムの前記呼出しに、標準化さ
れたインターフェース（２４）を使用するステップを含
む、上記（１）ないし（２）のいずれか一項に記載の方
法。 （４）１つまたは複数の要求によって引き起こされる矛
盾について検査するステップ（２５０、３００）と、す
でに存在する要求の子要求として１つまたは複数の新し
い要求を生成するステップ（２２０）と、前記要求の実
行をシミュレートするステップ（２７０、３３５）と、
リソースの更新を実行し、活動化のための特別な要求を
生成するステップ（２６０）と、前記オペレーティング
・システムに更新を知らせるステップ（３４０）と、前
に行われた更新を逆転するステップとのうちの少なくと
も１つを含む、上記（１）ないし（３）のいずれか一項
に記載の方法。 （５）上記（１）ないし（４）のいずれかによる前記ス
テップの１つの実行の影響が前記リソースのそれぞれの
設定と共にロギングされる、ユーザ可読プロトコルを生
成するステップ をさらに含む、上記（１）ないし（４）のいずれか一項
に記載の方法。（６）上記（１）ないし（５）のいずれ
か一項に記載の方法によるステップをコンピュータに実
行させるように適合されたコード部分を含む、コンピュ
ータ・プログラム。 （７）コンピュータに上記（１）ないし（５）のいずれ
か一項の方法を実行させるプログラムを記録した、コン
ピュータ使用可能記録媒体。 （８）上記（１）ないし（５）のいずれか一項の方法を
実行するコンピュータ・システム。
【図面の簡単な説明】
【図１】発明的要求処理の概要と、これによる、関係す
る最も重要な要素を示す概略ブロック図である。
【図２】発明的方法の全体的な制御フローを示す概略ブ
ロック図である。
【図３】発明的方法の全体的な制御フローを示す概略ブ
ロック図である。
【図４】サポータの実行ステップおよびロギング・ステ
ップの詳細を示す概略図である。
【符号の説明】
１０ 枠 １２ オペレーティング・システム・リソース １４ オペレーティング・システム・リソース １６ オペレーティング・システム・リソース １７ 共通サポータ／エクスプロイタ・リポジトリ １８ 要求リポジトリ ２０ 要求スケジューラ ２２ インターフェース ２４ インターフェース
フロントページの続き (72)発明者 フランク・ミールケ ドイツ ディー−72184 オイティンゲン アム・ケッペル 15 (72)発明者 ラルフ・テレン ドイツ ディー−71034 ベーブリンゲン ハウザッハー・シュトラーセ 24

Claims (13)

    【特許請求の範囲】
  1. 【請求項１】サポータが所有するリソースの自動化管理
    をサポートする方法であって、 実行されるべきアクションまたは達成されるべき所望の
    状態をそれぞれが定義する要求を含むリポジトリにアク
    セスするステップであって、前記状態が、それぞれの前
    記リソースに関連するステップと、 前記要求を再編成するステップと、 前記要求のチェーンを処理するリソース管理プログラム
    手段を呼び出すステップと、 を含む方法。
  2. 【請求項２】前記要求が、オペレーティング・システム
    によって維持されるリソースの所望の状態を定義し、前
    記方法が、 前記リソースが前記要求に従ってセットされることを保
    証するサポータ・プログラム手段を呼び出すステップを
    含む、プログラムの自動化構成をサポートするために使
    用される、請求項１に記載の方法。
  3. 【請求項３】サポータ・プログラムの前記呼出しに、標
    準化されたインターフェースを使用するステップを含
    む、請求項１ないし２のいずれか一項に記載の方法。
  4. 【請求項４】１つまたは複数の要求によって引き起こさ
    れる矛盾について検査するステップを含む、請求項１な
    いし３のいずれか一項に記載の方法。
  5. 【請求項５】すでに存在する要求の子要求として１つま
    たは複数の新しい要求を生成するステップを含む、請求
    項１ないし３のいずれか一項に記載の方法。
  6. 【請求項６】前記要求の実行をシミュレートするステッ
    プを含む、請求項１ないし３のいずれか一項に記載の方
    法。
  7. 【請求項７】リソースの更新を実行し、活動化のための
    特別な要求を生成するステップを含む、請求項１ないし
    ３のいずれか一項に記載の方法。
  8. 【請求項８】前記オペレーティング・システムに更新を
    知らせるステップを含む、請求項１ないし３のいずれか
    一項に記載の方法。
  9. 【請求項９】前に行われた更新を逆転するステップを含
    む、請求項１ないし３のいずれか一項に記載の方法。
  10. 【請求項１０】請求項１ないし９のいずれかによる前記
    ステップの１つの実行の影響が前記リソースのそれぞれ
    の設定と共にロギングされる、ユーザ可読プロトコルを
    生成するステップをさらに含む、請求項１ないし８のい
    ずれか一項に記載の方法。
  11. 【請求項１１】請求項１ないし１０のいずれか一項に記
    載の方法によるステップをコンピュータに実行させるよ
    うに適合されたコード部分を含む、コンピュータ・プロ
    グラム。
  12. 【請求項１２】コンピュータに請求項１ないし０のいず
    れか一項の方法を実行させるプログラムを記録した、コ
    ンピュータ使用可能記録媒体。
  13. 【請求項１３】請求項１ないし１０のいずれか一項の方
    法を実行するコンピュータ・システム。
JP2000384328A 1999-12-30 2000-12-18 リソースの自動化管理をサポートする方法、そのシステム、およびその記録媒体 Pending JP2001222436A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP99126199.1 1999-12-30
EP99126199 1999-12-30

Publications (1)

Publication Number Publication Date
JP2001222436A true JP2001222436A (ja) 2001-08-17

Family

ID=8239769

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000384328A Pending JP2001222436A (ja) 1999-12-30 2000-12-18 リソースの自動化管理をサポートする方法、そのシステム、およびその記録媒体

Country Status (3)

Country Link
US (1) US7051092B2 (ja)
JP (1) JP2001222436A (ja)
CN (1) CN1171145C (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9886271B2 (en) 2013-03-28 2018-02-06 Fujitsu Limited Change method, apparatus, and recording medium

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8234650B1 (en) 1999-08-23 2012-07-31 Oracle America, Inc. Approach for allocating resources to an apparatus
US8032634B1 (en) 1999-08-23 2011-10-04 Oracle America, Inc. Approach for allocating resources to an apparatus based on resource requirements
US7703102B1 (en) 1999-08-23 2010-04-20 Oracle America, Inc. Approach for allocating resources to an apparatus based on preemptable resource requirements
US8179809B1 (en) 1999-08-23 2012-05-15 Oracle America, Inc. Approach for allocating resources to an apparatus based on suspendable resource requirements
US8019870B1 (en) * 1999-08-23 2011-09-13 Oracle America, Inc. Approach for allocating resources to an apparatus based on alternative resource requirements
US20040172398A1 (en) * 2001-04-09 2004-09-02 Klaus Albert Method, databank system and computer program product for designing a technical facility
US8631013B2 (en) 2003-04-16 2014-01-14 The Mathworks, Inc. Non-intrusive data logging
US7512613B2 (en) 2003-04-16 2009-03-31 The Mathworks, Inc. Non-intrusive data logging
US20050015340A1 (en) * 2003-06-27 2005-01-20 Oracle International Corporation Method and apparatus for supporting service enablers via service request handholding
US8584129B1 (en) * 2004-02-20 2013-11-12 Oracle America, Inc. Dispenser determines responses to resource requests for a single respective one of consumable resource using resource management policy
US9245236B2 (en) 2006-02-16 2016-01-26 Oracle International Corporation Factorization of concerns to build a SDP (service delivery platform)
US9038082B2 (en) * 2004-05-28 2015-05-19 Oracle International Corporation Resource abstraction via enabler and metadata
US9565297B2 (en) 2004-05-28 2017-02-07 Oracle International Corporation True convergence with end to end identity management
US8966498B2 (en) * 2008-01-24 2015-02-24 Oracle International Corporation Integrating operational and business support systems with a service delivery platform
US8838794B2 (en) * 2004-06-30 2014-09-16 International Business Machines Corporation Method, system and program product for simulating activity in a server environment
US8271955B1 (en) 2004-07-23 2012-09-18 Green Hille Software, Inc. Forward post-execution software debugger
US8136096B1 (en) 2004-07-23 2012-03-13 Green Hills Software, Inc. Backward post-execution software debugger
US7653899B1 (en) 2004-07-23 2010-01-26 Green Hills Software, Inc. Post-execution software debugger with performance display
US8015552B1 (en) 2004-07-23 2011-09-06 Green Hills Software, Inc. Post-execution software debugger with coverage display
US8132159B1 (en) 2004-07-23 2012-03-06 Green Hills Software, Inc. Post-execution software debugger with event display
JP4728020B2 (ja) * 2005-03-17 2011-07-20 日立オートモティブシステムズ株式会社 車両制御用ソフトウェア及び車両制御装置
US20070101256A1 (en) * 2005-11-01 2007-05-03 Charles Simonyi Perfect source control
US7552044B2 (en) * 2006-04-21 2009-06-23 Microsoft Corporation Simulated storage area network
US8887133B2 (en) * 2006-04-28 2014-11-11 Bmc Software, Inc. Bi-directional communication between change management tool and implementation tools
US8914493B2 (en) * 2008-03-10 2014-12-16 Oracle International Corporation Presence-based event driven architecture
US8065661B2 (en) 2006-08-29 2011-11-22 Sap Ag Test engine
US7823124B2 (en) 2006-08-29 2010-10-26 Sap Ag Transformation layer
US7831637B2 (en) 2006-08-29 2010-11-09 Sap Ag System on the fly
US7912800B2 (en) * 2006-08-29 2011-03-22 Sap Ag Deduction engine to determine what configuration management scoping questions to ask a user based on responses to one or more previous questions
US8131644B2 (en) 2006-08-29 2012-03-06 Sap Ag Formular update
US7908589B2 (en) 2006-08-29 2011-03-15 Sap Ag Deployment
US7831568B2 (en) 2006-08-29 2010-11-09 Sap Ag Data migration
US7827528B2 (en) * 2006-08-29 2010-11-02 Sap Ag Delta layering
US9654515B2 (en) * 2008-01-23 2017-05-16 Oracle International Corporation Service oriented architecture-based SCIM platform
US8090848B2 (en) 2008-08-21 2012-01-03 Oracle International Corporation In-vehicle multimedia real-time communications
US8135659B2 (en) 2008-10-01 2012-03-13 Sap Ag System configuration comparison to identify process variation
US8396893B2 (en) 2008-12-11 2013-03-12 Sap Ag Unified configuration of multiple applications
US8255429B2 (en) 2008-12-17 2012-08-28 Sap Ag Configuration change without disruption of incomplete processes
CN101771678B (zh) * 2008-12-31 2014-04-16 华为技术有限公司 一种管理视图及视图触发的方法及装置
US9229738B2 (en) * 2009-06-19 2016-01-05 International Business Machines Corporation Software development tool for providing user context information to improve message quality at development time
US9269060B2 (en) 2009-11-20 2016-02-23 Oracle International Corporation Methods and systems for generating metadata describing dependencies for composable elements
US9503407B2 (en) * 2009-12-16 2016-11-22 Oracle International Corporation Message forwarding
US9509790B2 (en) 2009-12-16 2016-11-29 Oracle International Corporation Global presence
JP5713007B2 (ja) 2010-03-30 2015-05-07 日本電気株式会社 プログラム処理方法、プログラム処理装置、およびコンピュータプログラム
US7925874B1 (en) * 2010-05-18 2011-04-12 Kaspersky Lab Zao Adaptive configuration of conflicting applications
US8661120B2 (en) * 2010-09-21 2014-02-25 Amazon Technologies, Inc. Methods and systems for dynamically managing requests for computing capacity
CN103677754A (zh) * 2012-09-21 2014-03-26 国际商业机器公司 用于优化应用程序的并行构建的方法和系统
US20150161123A1 (en) * 2013-12-09 2015-06-11 Microsoft Corporation Techniques to diagnose live services
CN106547654A (zh) * 2015-09-21 2017-03-29 中兴通讯股份有限公司 一种自动化测试方法及装置
CN109508231B (zh) * 2018-11-17 2020-09-18 中国人民解放军战略支援部队信息工程大学 异构多模处理器的等价体间的同步方法及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5058044A (en) * 1989-03-30 1991-10-15 Auto I.D. Inc. Automated maintenance checking system
US5987611A (en) * 1996-12-31 1999-11-16 Zone Labs, Inc. System and methodology for managing internet access on a per application basis for client computers connected to the internet
EP0996886B1 (en) * 1997-07-25 2002-10-09 BRITISH TELECOMMUNICATIONS public limited company Software system generation
US6115646A (en) * 1997-12-18 2000-09-05 Nortel Networks Limited Dynamic and generic process automation system
US6148324A (en) * 1998-01-05 2000-11-14 Lucent Technologies, Inc. Prioritized load balancing among non-communicating processes in a time-sharing system
US6434631B1 (en) * 1999-10-15 2002-08-13 Lucent Technologies Inc. Method and system for providing computer storage access with quality of service guarantees

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9886271B2 (en) 2013-03-28 2018-02-06 Fujitsu Limited Change method, apparatus, and recording medium

Also Published As

Publication number Publication date
US20010054091A1 (en) 2001-12-20
US7051092B2 (en) 2006-05-23
CN1302014A (zh) 2001-07-04
CN1171145C (zh) 2004-10-13

Similar Documents

Publication Publication Date Title
JP2001222436A (ja) リソースの自動化管理をサポートする方法、そのシステム、およびその記録媒体
US10324690B2 (en) Automated enterprise software development
US9063725B2 (en) Portable management
US7451403B1 (en) System and method for developing user interfaces purely by modeling as meta data in software application
US11709766B2 (en) Mocking robotic process automation (RPAactivities for workflow testing
WO2021076310A1 (en) Systems and methods for cross-platform scheduling and workload automation
CN101384995A (zh) 应用服务器中的管理自动化
US11604627B2 (en) Systems and methods for on-demand provisioning of robotic process automation environments
KR20230001491A (ko) 가상 머신들, 세션들, 및 컨테이너들에 대한 웹 기반 로보틱 프로세스 자동화 설계자 시스템들 및 자동화들
US20220197249A1 (en) Dynamic Cloud Deployment of Robotic Process Automation (RPA) Robots
JP2023070148A (ja) ロボティックプロセスオートメーション（ｒｐａ）ロボットをリソースへ動的にバインドさせるためのシステムおよび方法
US10489196B1 (en) Job scheduler for remote maintenance of servers and workstations
US20160170739A1 (en) Alter application behaviour during runtime
KR20220007496A (ko) 제1 세션에서 실행되고 있는 프로세스의 제2 세션에서 실행되고 있는 로봇 프로세스 자동화 로봇을 통한 자동화
CA3220687A1 (en) Software updater
Horuk et al. Automatic and portable cloud deployment for scientific simulations
US20220091908A1 (en) Filter instantiation for process graphs of rpa workflows
Bukovics Hosting the Workflow Runtime
Juneau et al. Working with Servlets and Applets
Lhotka Reporting and batch processing
Hemedinger Not Just for Scheduling: Donig More with SAS Enterprise Guide Automation
Jahn et al. Plux. Net-A dynamic Plug-in Platform for Desktop and Web Applications in. Net.
Oberortner et al. Designing the Architecture of Clotho 3.0: An Interactive Pattern Story
Bogoda Applicability of agent technology for software release management
White et al. Workflows in Windows Azure

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20040907

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20041206

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20051018