JP5695420B2 - イベントによって駆動されるジョブの実行をスケジュールするための方法、システム、およびコンピュータ・プログラム - Google Patents

Description

本発明はデータ処理分野に関する。さらに具体的には、本発明はデータ処理システムにおけるジョブ実行のスケジューリングに関する。

作業負荷スケジューラ（もしくは単にスケジューラ）は、データ処理システムにおいて大量のジョブの実行を制御するため広く使われている。市販のスケジューラの一例として、ＩＢＭコーポレションによる「ＩＢＭ Ｔｉｖｏｌｉ（ＩＢＭ社の登録商標）作業負荷スケジューラ（ＴＷＳ：Ｔｉｖｏｌｉ Ｗｏｒｋｌｏａｄ Ｓｃｈｅｄｕｌｅｒ）」がある。

ジョブは、システムで実行可能な任意の種類の作業ユニットから成る。例えば、米国特許第７，１５０，０３７号に記載されているように、スケジューラは、（ネットワーク構成管理システム中の）ネットワーク・デバイスへの構成ファイルのダウンロードの制御に使われる。各構成ファイルは、対応するポリシーを検討して動的に生成され、これらポリシーは一つ以上のルールで形成されており、各ルールは、（インフラストラクチャ・データベース中の対応するネットワーク・デバイスをどのように識別するかを決めるための）条件と、（所望の構成パラメータをどのように設定するかを決めるための）アクションと、（ネットワーク構成の検証過程で、ルールと対応するネットワーク・デバイスの実際の構成との間の何らかの不一致をどう解釈するかを決めるための）検証とを含む。

典型的には、スケジューラは、中央のスケジューリング・サーバから、複数のワークステーション上のジョブの実行を制御し、各ジョブに対応するワークステーションは、静的に指定しておくか、あるいは、実行するジョブが依頼されたときに（必要な特性を有する利用可能な全ステーションから）動的に選定することができる。後者の対処法は、容易に拡大縮小が可能で信頼性の高いシステムの履行を可能にするばかりでなく、作業負荷バランシング技法を活用して、ワークステーションへのジョブの配分を最適化することができる。

ジョブの実行依頼は、所定の作業負荷プラン（または単にプラン）に従って制御される。そのプランは、時間的制約（すなわち、日付または時間あるいはその両方）に基づいてジョブの実行の流れを設定し、さらに、そのジョブの実行を（先行のジョブの完了など）特定の依存条件に条件付けることができる。

しかしながら、これらのスケジューラは、プランに定義されていないジョブの実行の制御には全く役立たない。このことは、あるジョブを実行する必要がアプリオリに分かっていない場合（例えば、特定のイベントの発生によってジョブ実行がトリガされる場合）には問題となる。

米国特許第７，１４６，３５０号

スケジュールされたベースで、またはイベントの発生に応じてタスクの実行を制御する一般的なアイデアは、米国特許第７，１４６，３５０号に記載されるように、非常に具体的な出願として既に提案されている。詳しくは、この文書は、企業の情報技術（ＩＴ：Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）インフラストラクチャを監査するためのシステムを開示している。このために、該システムのサーバは、ＩＴインフラストラクチャの個別のリソースの静的な査定または動的なアセスメント（対応するポリシーに定められたステップのシーケンスを含む）の実行を制御する。これらのアセスメントは、通例のように、年、日付、時刻の情報を備えたスケジューラを利用してトリガすることができる。これに換えて、同じアセスメントを、システムのノードで検知された所定のイベントによってトリガすることもできる。このためには、各ノードは、起こり得る全ての対象イベントをモニタする必要があり、かく得られた情報は、次いでさまざまなノードからサーバに収集される。しかしながら、これは（イベントを検知するための）ノードと（イベント情報を収集するための）サーバとのオーバーヘッドをもたらし、さらに、イベントを収集するための、ノードからサーバに送信される大量の情報により、ネットワーク・トラヒックの大幅な増加が生じる。

概していえば、本開示は、プランに従った、またはイベントに応じたジョブのスケジューリングのいずれをも支援することを狙いとしている。

詳しくは、本発明のいろいろな態様により、独立請求項に提示された対処法を提供する。従属請求項には本発明の有益な実施形態が記載されている。

さらに具体的には、本発明のある態様は、データ処理システムの（スケジューリング・サーバなどの）スケジューリング・エンティティの制御下で、該システムの（ワークステーションなどの）ターゲット・エンティティ上でのジョブ実行をスケジュールするための方法を提案する。該方法は、一連のジョブの実行の流れを定義するプランを設定するステップから開始される。該方法は、該プランに従い、選定されたターゲット・エンティティ上で実行するため、各ジョブの実行依頼をするステップへと続く。また、一連のルールも規定され、各ルールは、イベント・ターゲット・エンティティでのイベントに応じてアクション・ターゲット・エンティティ上で実行されるアクションを定義している。該方法は、次いで、各イベント・ターゲット・エンティティに対しルール中に定義されるイベント群を判定するステップを含む。かくして、各イベント・ターゲット・エンティティは対応するイベントを検知することが可能になる。これにより、対応するアクション・ターゲット・エンティティ上での各アクションの実行が、対応するイベントの検知に応じてトリガされる。

例えば、これらのアクションは、プラン中に定義されていない追加的なジョブから成るものとすることができる。

提案された実装において、各（イベント）ワークステーションは、その中で実行される一つ以上の検知モジュールによる配置構造を展開することによって、対応するイベントを検知できるようにされる。

さらなる改良として、配置構造の展開は、該構造が当該ワークステーションで既に利用可能なその既存のバージョンと等しい場合には回避される。

この目的のため、配置構造の２つのバージョンのダイジェスト値を対比することができる。

本発明のある実施形態において、サーバは、各（イベント）ワークステーションから各イベントの通知を受信し、次いで、関連する（アクション）ワークステーションで実行するため対応するアクションの実行依頼をする。

この対処法をさらに改良する一つのやり方として、ルールをモニタし、その何らかの変更に応じてだけ前述のオペレーションを実施するようにすることがある。

さらなる向上策として、これらのオペレーションは、変更されたルールの影響を受ける（イベント）ワークステーションに対するものに限定される。

本発明の別の態様は、上記の方法を実施するためのコンピュータ・プログラムを提案する。

本発明の他のある態様は、対応するシステムを提案する。

本発明自体、並びにそのさらなる特質および利点は、全く非限定的な例示目的で示した以下の詳細な説明を、添付の図面と併せ読んで参照することにより最良に理解されよう。

本発明の実施形態による対処法が適用可能な、データ処理システムの概略ブロック図である。 該システムの典型的コンピュータの機能ブロック群を示す。 本発明の実施形態による対処法を実施するため使用できる、主要なソフトウエア・コンポーネント群を図示する。 本発明の実施形態による対処法の実施に関する処理作業の流れを表す図を示す。 本発明の実施形態による対処法の実施に関する処理作業の流れを表す図を示す。

ここで図１を参照すると、分散型アーキテクチャを有するデータ処理システム１００が図示されている。システム１００は、システム１００におけるジョブの実行を制御するため使われる、スケジューリング・サーバ（または単にサーバ）１０５を含む。通常、これらのジョブは、人件費またはコストの分析プログラムといった、バッチ型の（すなわち非双方向性の）アプリケーションから成る。これらジョブは、複数のターゲット・ワークステーション（または、単にワークステーション）１１０上で、サーバ１０５の制御の下に実行される。このために、サーバ１０５とワークステーション１１０とは、（例えばＬＡＮなどの）ネットワーク１１５を介して交信する。

図２に移ると、前述のシステムの汎用コンピュータ（サーバまたはワークステーション）が２００として表されている。コンピュータ２００は、（システム中のコンピュータ２００の実際の役割に応じて、適切にスケールされた構造を有する）システム・バス２０５に、相互並列に連結された、いくつかのユニットで形成される。詳しくは、一つ以上のマイクロプロセッサ（３Ｐ）２１０はコンピュータ２００のオペレーションを制御し、ＲＡＭ２１５は、マイクロプロセッサ２１０によって作業メモリとして直接使われ、ＲＯＭ２２０は、コンピュータ２００のブートストラップのための基本コードを格納する。いくつかの周辺ユニットが（それぞれのインタフェースを用いて）ローカル・バス２２５の周りに群がってこれに連結されている。具体的には、大容量記憶装置は一つ以上のハードディスク２３０から成り、ＣＤ−ＲＯＭ２４０を読み取るためのドライブ２３５がある。さらに、コンピュータ２００は、（例えば、キーボードおよびマウスなどの）入力ユニット２４５、および（例えば、モニタおよびプリンタなどの）出力ユニット２５０を含む。コンピュータ２００をネットワーク（図示せず）に連結するためにアダプタ２５５が使われている。ブリッジ・ユニット２６０は、システム・バス２０５をローカル・バス２２５にインタフェース接続している。各マイクロプロセッサ２１０およびブリッジ・ユニット２６０は、情報送信のためシステム・バス２０５へのアクセスを要求するマスタ・エージェントとして機能することができる。アービタ２６５は、相互排除によって、システム・バス２０５へのアクセス許可を管理する。

次に図３を考察すると、本発明の実施形態による対処法を実行するために使用可能な主要ソフトウエア・コンポーネント群が、その全体を参照番号３００として表されている。情報（プログラムおよびデータ）は、典型的には、ハードディスクに格納され、プログラムを実行しているときに、オペレーティング・システムおよび他のアプリケーション・プログラム（図示せず）と一緒に、各コンピュータの作業メモリに（少なくとも部分的に）ロードされる。これらプログラムは、最初に、例えばＣＤ−ＲＯＭから、ハードディスクにインストールされる。

詳しくいえば、サーバ１０５は（例えば、前述のＴＷＳなどの）スケジューラ３０５を実行する。

スケジューラ３０５は、（例えば、ＸＭＬベースなどの、適切な制御言語で書かれた）作業負荷データベース３１５を維持するために使われる（ＴＷＳの「コンポーザ」のような）コンフィギュレータ３１０を含む。作業負荷データベース３１５は、スケジューラ３０５が利用可能な全ワークステーションの定義を収納しており、例えば、各ワークステーションは、（処理能力、メモリ・サイズ、オペレーティング・システムなどの）その物理的／論理的特性とともに（氏名、住所などといった）該ステーションにアクセスするための情報によって定義されている。また、作業負荷データベース３１５は、各ジョブのディスクリプタも含む。ジョブ・ディスクリプタは、呼び出し対象のプログラムを（それらの引き数および環境変数とともに）指定する。さらに、ジョブ・ディスクリプタは、ジョブが実行可能なワークステーションを、（それらの名前によって）静的に、あるいは（それらの特性によって）動的に示し出す。次いで、ジョブ・ディスクリプタは、そのジョブの実行に対する時間的制約（毎日か、毎週か、毎月か、その開始の最早時間または最遅時間、あるいは最大許容持続時間といった実行サイクルなど）を設定する。随意的に、ジョブ・ディスクリプタは、そのジョブの依存条件（すなわち、ジョブが開始可能となる前に満たされなければならない条件）を指定する。典型的な依存条件には、（他のジョブの正常終了など）シーケンス制約、または（操作者によるプロンプトへの応答の入力など）許可制約がある。一般に、ジョブ群はストリーム群に編成され、各ジョブ・ストリームは、所定の依存条件を順守しながら単一の作業単位として実行されるべき、（論理的に関連する）ジョブ群の順序付けられたシーケンスから成る。簡明化のため、以降、ジョブという用語は、単一のジョブあるいはジョブ・ストリームを表すため用いるものとする。また、作業負荷データベース３１５は、（類似の見積もり継続時間が推定可能な作業継続時間の記録など）該ジョブの過去の実行に関する統計情報も格納する。

（ＴＷＳの「マスタ・ドメイン・マネージャ」のような）プランナ３２０を使ってプランが生成され、その定義が（例えばＴＷＳの「シンフォニ」のような）制御ファイル３２５中に格納される。該プランは、必要とされるワークステーションの定義とともに、特定の産生周期（典型的には１日）におけるジョブのバッチの実行の流れを規定する。新規のプランは、通常、毎産生周期の前に自動的に生成される。このために、プランナ３２０は、作業負荷データベース３１５中の利用可能な情報を処理し、実行対象のジョブを選定してそれらを（それらの予想継続時間、時間的制約、および依存条件に従って）望ましいシーケンスに配列する。プランナ３２０は、（次の産生周期において）実行の対象となるジョブを加え、完了した（前回産生周期の）先在するジョブを除去することによって、該プランを生成する。さらに、正常完了しなかった、またはまだ実行されている、または実行を待っている前回産生周期のジョブは、（次回産生周期において実行するため）該プランの中に維持することができる。

（「ＴＷＳ」の「バッチマン」プロセスのような）ハンドラ３３０が、毎回の産生周期の初めにプランの実行を開始する。ハンドラ３３０は、可能な限り早く各ジョブの実行を依頼する。このために、ハンドラ３３０は、必要な特性を有する利用可能なワークステーションの中から（通常、負荷バランサ（図示せず）に提供された情報に従って）あるワークステーションを選定する。

これらジョブの実際の実行は、（「ＴＷＳ」の「ジョブマン」プロセスのような）対応するモジュール３３５によって管理される。このために、このエクゼキュタ３３５は、各ワークステーション１１０で作動されている実行エージェント３４０（一つだけが図示されている）とインタフェース接続している。

エージェント３４０は、エクゼキュタ３３５から受信した対応する命令に応じて、各ジョブの実行を進め、（例えば、ジョブが正常に終了したかどうか、その実際の継続時間などといった）その実行結果に関するフィードバック情報を返信する。実行された全てのジョブのフィードバック情報は、エクゼキュタ３３５からハンドラ３３０に渡され、該ハンドラはそれを（プランの全ジョブの現在状態のリアルタイムの状況を備えるため）制御ファイル３２５に入力する。産生周期の終了時に、プランナ３２０は、制御ファイル３２５にアクセスし、作業負荷データベース３１５中の実行済みジョブに関する統計情報を更新する。

本発明のある実施形態による対処法では、後記で詳細を説明するように、スケジューラ３０５は、対応するイベントに応じたジョブ実行（さらに一般的には、他の任意のアクションの実行）にも対応する。このために、各ワークステーションは、（例えば、カスタム化された構成ファイルを選択的に配置することによって）対象とするイベント、すなわち、それがワークステーションで発生すると対応するアクションの実行がトリガされるようなイベント、だけを検知できるようにされる。

このようにして、スケジューラは、どんなアクションも、それらの実行の必要がアプリオリに分かっていない場合でも、制御することができる。具体的には、これによりプランに定義されていないジョブの実行依頼が可能になる。いずれの場合でも、ワークステーションおよびサーバに対する最小のオーバーヘッドで所望の結果が達成され、さらに、ネットワーク・トラヒックの顕著な増加がもたらされることもない。

さらに具体的には、この図に示された実装において、エディタ３４５を使ってルール・リポジトリ３５０が維持される（望ましくは、その一切の更新を制御するため認証／許可メカニズムによって保護される）。リポジトリ３５０中の各ルールは、対応する（イベント）ワークステーションでのイベントの検知に応じて、対応する（アクション）ワークステーション上で実行されるアクションを定義する。いくつかの異なるイベントをサポートすることができ、例えば、そのイベント群を、ジョブに対するエラー状態の入力、ワークステーションのシャットダウン、ファイルの生成または削除などから成るものとすることができる。通常は、こういったアクションはジョブの実行の依頼から成る。この点に関して、このルールには、任意のジョブを、それがプランに含まれていなくても規定することが可能なことを強調しておく。また一方、例えば、ユーザへのｅメール通知、ワークステーションの電源オンなど、他のアクションもサポートすることができる。該システムのいずれかのコンピュータで、これらイベントを検知することができ、アクションを実行することができる。例えば、ジョブのステータスの変化に関するイベントは、サーバ自体によって検知される（この場合、サーバはワークステーションとしても作動している）。さらに、ジョブの実行依頼から成るアクション群は（必要な特性に従って）静的にあるいは動的に定義されたワークステーション上で実行することができる。

一連のプラグイン・モジュール（または単にプラグイン）が、イベントの検知および（ジョブの実行依頼とは異なった）アクションの実行のために備えられており、（イベント）プラグインの一例をファイル・スキャナとし、（アクション）プラグインの一例をｅメール・センダとすることができる。プランナ３２０は（イベントの検知および対応するアクションの実行に必要な情報を制御ファイル３２５に加えるため）ルール・リポジトリ３５０にアクセスする。

イベント・プラグイン・データベース３５５は、各イベントを、その検知のため対応するイベント・プラグインに関連付ける。モニタ３６０は、（例えば、変化が検知されたときは何時でも）リポジトリ３５０中のルールを処理する。さらに具体的には、モニタ３６０は、ルールの中で、各ワークステーションに対して定義されているイベントを判定する。次いで、モニタ３６０は、これらのイベントに関連する各イベント・プラグインに対する構成ファイルを（イベント・プラグイン・データベース３５５中の指定に沿って）生成する。該構成ファイルは、イベント・プラグインの構成パラメータを設定し、これらは該プラグインが所望のイベント（群）を検知することを可能にする。各ワークステーションに対する構成ファイルは、次いで（例えば、圧縮形式で）単一の構成アーカイブに組み合わされる。モニタ３６０は、かく得られた全ての構成アーカイブを、対応するリポジトリ３６５中に保存する。同時に、モニタ３６０は、（各構成アーカイブに１６または３２ビットの多項式を適用して）その巡回冗長コード（ＣＲＣ：Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｏｄｅ）を計算する。構成テーブル３７０は（モニタ３６０の制御の下に）各ワークステーションと、対応する構成アーカイブおよびそのＣＲＣとを関連付けるために使われる。

デプロイヤ３７５は、各ＣＲＣを（構成テーブル３７０の指定に沿って）対応するワークステーションに送信する。このために、デプロイヤ３７５は、制御ファイル３２５中のワークステーションの定義から必要な情報を読み出す。簡明化のため、前述と同じワークステーション１１０を参照すると、この情報はコントローラ３８０によって受信される。コントローラ３８０は、ワークステーション１１０にインストールされた、（イベントまたはアクションあるいはその両方の）プラグイン（３９０で表示）の現在の構成ファイル（３８５で表示）にアクセスする。受信されたＣＲＣが構成ファイル３８５のものと違っている場合、コントローラ３８０は、サーバ１０５から（デベロッパ３７５を介して）（新規の）構成アーカイブをダウンロードし、次いでこれにより構成ファイル３８５を更新する。望ましくは、サーバ１０５によって提供される構成アーカイブは、暗号化して保護され、その秘密性および完全性を確実にされる。

プラグイン３９０は、サーバ１０５と情報を交換するため、エージェント３４０とインタフェース接続している。具体的には、エージェント３４０は、ワークステーション１１０で検知されたイベントをイベント・コレクタ３９１に通知する。望ましくは、ワークステーション１１０により提供されるイベントの通知は、暗号化して保護され、その秘密性および完全性を確実にされる。イベント・コレクタ３９１は、全ワークステーションで検知されたイベントの通知をイベント・コーリレータ３９２に渡す。イベント・コーリレータ３９２はルール・リポジトリ３５０にアクセスし、これらに応じて実行するアクションを（対応するワークステーションと併せ）決定する。特定のワークステーションで実行される各々のアクションについて、イベント・コーリレータ３９２は（これらの情報を手渡すことによって）ハンドラ３３０を呼び出す。ハンドラ３３０は、各アクションをその実行のため対応するアクション・プラグインに関連付けているアクション・プラグイン・データベース３９３にアクセスする。次いで、ハンドラ３３０は、実行対象のアクションに関連する（アクション・プラグイン・データベース３９３に示された）アクション・プラグイン（全体を３９４で表示）を呼び出す。各アクション・プラグインは、所望のワークステーション上での対応するアクションの実際の実行を管理する。このために、アクション・プラグイン３９４は、各々の関連ワークステーションで実行されている（図中の前述と同じワークステーション１１０に示されるような）エージェント３４０とインタフェース接続している。さらに、アクション・プラグイン３９４には、（例えば、ｅメールにより）ユーザへの通知を実施するようになされたモジュールを含めることもできる。

図４および５に移ると、前述のシステムでジョブの実行をスケジュールするため実施可能な、典型的プロセスの論理フローが、方法４００として表されている。

この方法は、サーバのスイムレーン中のスタート黒丸４０３から始まる。ブロック４０６において新規のプランが生成されると、プロセスはブロック４０９に移る。このフェーズにおいて、プランの定義（ジョブの実行の流れの明細、およびそれらの実行に必要なワークステーションの定義を含む）が生成され、制御ファイル中に格納される。

モニタが（対応するリポジトリに格納された）ルール中に何らかの変更を検知したとき、処理作業の流れはブロック４１２に移る。これに応じ、ブロック４１５において、プランが再生成され制御ファイル中に再配置されて、イベントが検知され、対応するアクションが実行されるワークステーションの定義が加えられる。

次いで、変更されているルールを処理するためのループ作業が行われ、このループは、ブロック４１８から始まり、変更されたあらゆるルールが（最初のものから一つずつ）識別される。ブロック４２１に進むと、（只今の）変更されたルール中に規定されたイベントに関連するイベント・プラグインが、イベント・プラグイン・データベースから抽出される。次に、ブロック４２４を参照すると、このイベント・プラグインが（検知対象イベントの表示を手渡すことによって）呼び出される。このようにして、該イベント・プラグインの構成ファイルが、（該イベント・プラグインが所望のイベントを検知できるように適切に設定された対応構成パラメータとともに）生成される。ルール中に示されたイベントを検知するワークステーションが、ブロック４３０において識別される。ブロック４３３へと続いて、かく得られた構成ファイルがこのワークステーションの構成アーカイブに加えられる。次いで、ブロック４３６において、次のルールが変更されているかどうかの判断をするための点検が行われる。変更されている場合、該方法はブロック４１８に戻り、該次の変更されたルールに対し、前述と同様のオペレーションを繰り返す。

これに対し、変更された全てのルールが処理済となったならば、上記で得られた新しい構成アーカイブの処理のためのさらなるループに入る。このループは、ブロック４３９から始まり、あらゆる（新規）構成アーカイブの（新しい）ＣＲＣが、最初のものから一つずつ計算される。ブロック４４２に進んで、新しいＣＲＣが、対応するワークステーションに送信される。これに応じ、ブロック４４５において、そのワークステーションは、現在自分にインストールされている構成ファイルの（旧）ＣＲＣを計算し、次いで、新しいＣＲＣが旧ＣＲＣと対比される。処理作業の流れは、この対比の結果に従ってブロック４４８において分岐する。新ＣＲＣが旧ＣＲＣと異なる場合、ワークステーションは、ブロック４５１において、サーバに新規の構成アーカイブを要求する。サーバのスイムレーンに戻り、ブロック４５４において、要求された新規構成アーカイブがワークステーションに送信される。ブロック４５７において、新規構成アーカイブがワークステーションに受信されたならば、その構成ファイルが抽出され該ワークステーションにインストールされる。次いで、該方法はサーバのスイムレーン中のブロック４６０に下りる。また、新ＣＲＣが旧ＣＲＣと等しい場合には、ブロック４４８から同じポイントに直接に到達する。この時点で、全ての新規の構成アーカイブが処理済みかどうかを判断するための点検が行われる。まだ残っていれば、該方法は、ブロック４３９に戻り、別の新規構成アーカイブに対し、前述と同じオペレーションを繰り返す。

これに対し、産生周期が始まりプランが開始される場合は、処理作業の流れはブロック４６３に下りる。該プランのあらゆるジョブが（その時間的制約および依存条件に沿って）実行可能になり次第、該方法は、ブロック４６６からブロック４６９に移り、このフェーズにおいて（必要な特性を備えた利用可能なワークステーションの中から）選定されたステーションで実施するため、該ジョブが実行依頼される。上記に応じて、ブロック４７２において、簡明化のため前述と同じものを使って表された（選定された）ワークステーション上で、ジョブが実行される。ブロック４７５へと続いて、ワークステーションは、（ジョブの実行の結果に関する）フィードバック情報をサーバに返信する。サーバのスイムレーンのブロック４７８に移り、該フィードバック情報が制御ファイルに入力される。

簡明化のため前述と同じものを使って表した汎用的（イベント）ワークステーションが、そのプラグインの構成ファイル中に指示されたイベントの一つを検知したときは何時においても、全くの非同期的な形で作業の流れはブロック４８１に移る。上記に応じ、ブロック４８４において、該ワークステーションは該イベントをサーバに通知する。次にサーバのスイムレーン中のブロック４８５に移ると、ルール・リポジトリから抽出されたルールに従い、このイベントに応じて実行される一切のアクションが（対応するワークステーションと併せ）決定される。このために、イベント・コーリレータは、単にルール群を調べればよい（その各々があるイベントに対応するアクションの実行を定義している）。加えて、イベント・コーリレータは、（例えば、相異なるイベント群の検知に応じてある一つのアクションの実行が定義されている、などといった）ルール群の間の関係を調べることもできる。ブロック４８７へと続いて、サーバは、対応する（簡明化のため上記と同じものを使って表された）ワークステーションに各アクションの実行を依頼する。このために、ハンドラは（アクション・プラグイン・データベース中に指示された）対応するアクション・プラグインを呼び出す。また、同時に、サーバは、対応する通知を（例えば、ｅメールを使ってワークステーション１１０のユーザに）送信することができる。

上記に応じて、ブロック４９０において、該アクションが、ワークステーションで（実行エージェントまたは対応するアクション・プラグインを使って）実行される。ブロック４９３へと続いて、前述のごとく、ワークステーションが（アクションの実行結果に関する）フィードバック情報をサーバに返信する。サーバのスイムレーンのブロック４９６へと移行し、該フィードバック情報は上記のように制御ファイル中に入力される。その後、作業の流れは、白／黒同心のストップ円形４９９において終了する。

当然ながら、ローカルのまたは特定の要求事項を満たすため、当業者は、前述の対処法に多くの論理的または物理的あるいはその両方の変更および変形を加えることができる。もっと明確にいえば、本発明について、その好適な実施形態を参照しながらある程度の特殊性を持たせて説明してきたが、その形態および細部に対する、さまざまな省略、代替および変更、さらには他の実施形態が可能なことを理解すべきである。具体的に、提案された対処法は、より徹底した理解を提供するため前述の説明に記載した（数値例などの）特定の細目がなくても実施できよう。反対に、不必要な細目によって説明がを分かりにくくしないため、よく知られた特質を省略または簡略化することもできたであろう。さらに、開示した本発明の一切の実施形態に関連して説明した特定の構成要素または方法ステップあるいはその両方は、一般的設計上の選択事項として他の任意の実施形態への組み込みが可能であること、が明示的に意図されている。

具体的には、提案された対処法は（類似のステップを使用、非必然的な一部のステップを削除、またはさらなる随意的ステップを付加した）同等な方法を使っても実行できるようになっている。さらに、これらのステップは、（少なくとも部分的に）違った順序で、または同時に、または交互的に実施することができる。

加えて、同じ対処法を、他の任意の作業負荷スケジューラ（または同等なアプリケーション）に適用することができる。殊に、上記の説明において、非双方向性ジョブを参照にしているが、これは範囲限定として意図されてはいない。実際上は、同じ対処法を使って（例えば、双方向性ジョブなど）任意の種類の作業ユニットをスケジュールすることができる。同様に、計画についても、例えば、任意の追加または別の時間的制約または依存条件に基づき（さらにはワークステーション間の動的な関係に基づいて）違ったやり方で定義または生成あるいはその両方を行うことができる。さらに、（例えば、統計的方法によってジョブの実行を一様に配分するなど）他の任意の規準を用いてジョブの実行依頼のためワークステーションを選定することができる。

提案された対処法を、他の任意の種類のルール（またはポリシー）を用いて実施し、対応するイベントに応じて実行されるアクションを定義することができる。さらに、前述のイベントおよびアクションは単なる例示であって、これらは、限定的な見方で解釈されるものではない。例えば、（基本的な）ルールを（ＯＲ、ＡＮＤなどといった）任意の論理演算子を使い（複雑な）ルールに組み上げて、イベントの任意の組合せに応じたアクション群の（さらには相異なるワークステーション群においての）実行を定義することができる。同様に、これらルールは（同じイベントに基づくより多くのルールを統合することによって）複数の（基本的）アクションから成る（複雑な）アクションを、さらにはそれぞれが複数の（基本的）ワークステーションから成る（複雑な）エンティティ群上で実行することを定義できよう。あるいは、イベントを他のルールの所産から成るものとすることができ、さらに、そのアクションを、時間的制約または依存条件あるいはその両方で条件付けることもできる。

上記の通知が、追加のまたは異なるユーザに送信され、それらがＳＭＳなどで行われる場合も同様な対処策が適用される。本発明の異なる実施形態において、これらアクションは、ジョブ、通知、または他の任意の所定の種類のオペレーションだけから成るものとすることができる。当然ながら、ルールに関する情報を取り込むための計画の再生成の必要性は厳格なものではない。

構成ファイル（および構成アーカイブ）が、例えば、イベント・プラグインに所望の挙動を実行させる命令だけから成る、同等な構造で置き換えられた場合でも同様な対処策が適用される。同様に、構成ファイルは、他の任意の仕方で（例えば、ソフトウエア配送インフラストラクチャを利用することによって）関連するワークステーションに展開することができる。

また、提案された対処法の基本的な実装において、構成ファイルを無差別に全ワークステーションに分配することも可能である。

さらに、ＣＲＣを別な種類（例えば、ＣＲＣ−４）とすることができ、これを、ハッシュ値による、構成アーカイブの単純なチェックサムで、あるいはさらに一般的には、はるかに短い形式の、構成アーカイブを表す他の任意のダイジェスト値によって代替することができる。しかしながら、こういったことは、いずれも（例えば、全ワークステーションの実際の状態についての情報を集中的に維持することによる）サーバ上での構成アーカイブの選択的展開の直接的管理を妨げるものではない。

提案された対処法のある一般的な改良策は、各（イベント）ワークステーションが、各イベントをサーバを経由せずに対応する（アクション）ワークステーションに直接通知することも可能にする。例えば、これをあらゆるイベントに対して行うことも、あるいは、対応するイベントが検知されたのと同じワークステーションでアクションが実行される場合に限って実施することもできる。

要求に応じ（ルールのモニタリングが一切なくとも）所望された構成ファイルの配置を実行させる機能可能性は本発明の範囲内である。

また、どの場合でも、簡易化された実装においては、ルールの一切の変更について全てのワークステーションに対し構成ファイルを再生成（および展開）することも可能である。

プログラム（それを使って本発明の各実施形態を実行できる）が違った仕方で構造化されている場合、あるいは、追加のモジュールまたは機能が設けられている場合でも同様な対処策が適用される。さらに、メモリ構造を他の種類とすることができ、あるいは同等なエンティティ（必ずしも物理的記憶媒体から成る必要はない）で置き換えることができる。どの場合についても、上記プログラムは、例えば、外部のまたは常駐のソフトウエア、ファームウエア、あるいはマイクロコード（オブジェクト・コード、または、例えばコンパイルまたは翻訳対象の、ソース・コードのいずれでも）など、任意のデータ処理システムによってまたはそれと関連させて使用するのに適した任意の形式とすることができる。さらに、該プログラムを任意のコンピュータ可用媒体で提供することが可能で、この媒体は、該プログラムを包含、格納、通信、伝播、または移送するのに適した任意のエレメントとすることができる。例えば、該媒体は、電子的、磁気的、光学的、赤外的、あるいは半導体の種類とすることができ、かかる媒体の例には、（該プログラムを事前ロードした）固定ディスク、リムーバブル・ディスク、テープ、カード、配線、ファイバ、無線接続、ネットワーク、放送電波などがある。どの場合でも、本発明の実施形態による対処法は（例えば、半導体材料のチップ中に集積された）ハードウエア構造、あるいはソフトウエアおよびハードウエアの組合せに実装するのに適している。また、提案された対処策を（インターネットなどの）ネットワークを介してアクセスするサービスとして展開が可能なことも容易に分かることである。

提案された方法は（例えば、ローカル・ネットワークなどに基づく）異なったアーキテクチャを有する、または同等なユニットを含むシステムで実施することができる。さらに、各コンピュータには（実行中に大容量記憶装置へのアクセスを低減するため、プログラムまたはその一部を一時的に格納するキャッシュ・メモリなどの）類似のエレメントを含めることができる。いずれの場合も、上記コンピュータを、（ＰＤＡ、携帯電話など）任意のコード実行エンティティ、または（多層サーバ・アーキテクチャ、グリッド・コンピューティング・インフラストラクチャなどといった）それらの組合せで置き換えることが可能である。

Claims (7)

1. コンピュータの処理により、データ処理システムのターゲット・エンティティ上でのジョブの実行を、前記システムのスケジューリング・エンティティの制御の下でスケジューリングする方法（４００）であって、
   前記コンピュータの処理により、一連のジョブの実行の流れを定義するプランを設定するステップ（４０６〜４０９）と、
   前記コンピュータの処理により、前記プランに従って、選定されたターゲット・エンティティ上で実行するため各ジョブを実行依頼するステップ（４６６〜４７５）と、
   を含み、
   前記コンピュータの処理により、各々が、イベント・ターゲット・エンティティでのイベントに応じてアクション・ターゲット・エンティティ上で実行されるアクションを定義する、一連のルールを規定するステップ（４１２〜４１５）と、
   前記コンピュータの処理により、各イベントに対し前記ルール中に定義されている前記イベントを判定するステップ（４３０）と、
   前記コンピュータの処理により、各イベント・ターゲット・エンティティが対応するイベントを検知できるようにするステップ（４１８〜４５７）と
   前記コンピュータの処理により、前記対応するイベントの前記検知に応じて、対応するアクション・ターゲット・エンティティ上での各アクションの前記実行をトリガするステップ（４８１〜４９３）と、をさらに含むことを特徴とし、
   各イベント・ターゲット・エンティティが前記対応するイベントを検知できるようにする前記ステップ（４１８〜４５７）は、
   前記イベント・ターゲット・エンティティで作動する少なくとも一つの検知モジュールに対する構成ファイルを生成するステップ（４３３）であって、前記構成ファイルは、前記少なくとも一つの検知モジュールに前記イベントをモニタさせる、前記ステップ（４３３）と、
   前記構成ファイルを前記イベント・ターゲット・エンティティに展開するステップ（４３９〜４５７）とを含み、
   前記構成ファイルを前記イベント・ターゲット・エンティティに展開するステップ（４３９〜４５７）は、
   前記構成ファイルが、前記イベント・ターゲット・エンティティに既に展開されているその既存のバージョンと等しい場合は、前記構成ファイルの前記展開を回避するステップ（４３９〜４５１）を含み、
   前記イベント・ターゲット・エンティティへの前記構成ファイルの前記展開を回避する前記ステップ（４３９〜４５１）は、
   前記構成ファイルを表現するダイジェスト値を生成するステップ（４３９）と、
   前記ダイジェスト値を前記イベント・ターゲット・エンティティに送信し（４４２）、前記イベント・ターゲット・エンティティに、前記ダイジェスト値を前記構成ファイルの前記既存のバージョンを表現する既存のダイジェスト値と対比させ（４４５）、前記対比の否定的結果に応じてだけ、前記スケジューリング・エンティティからの前記構成ファイルの前記展開を要求する（４５１）ステップを含む、前記方法（４００）。
2. 前記アクションの少なくとも一つは、前記プランに定義されていない追加的ジョブを、前記対応するアクション・ターゲット・エンティティ上で実行するため、実行依頼するステップを含む、請求項１に記載の方法（４００）。
3. 前記対応するイベントに応じ、前記対応するアクション・ターゲット・エンティティ上での各アクションの前記実行をトリガする前記ステップ（４８１〜４９３）は、
   前記対応するイベント・ターゲット・エンティティから前記イベントの通知を受信するステップ（４８４）と、
   前記イベントに対し前記ルール中に定義されている各アクションおよび前記対応するアクション・ターゲット・エンティティを識別するステップ（４８５）と、
   識別された各アクションを、前記対応するアクション・ターゲット・エンティティ上で実行するため、実行依頼をするステップ（４８７）と、
   を含む、請求項１または請求項２に記載の方法（４００）。
4. 前記ルールをモニタするステップ（４１２）と、各イベント・ターゲット・エンティティに対し前記ルール中に定義されている前記イベントを判定する前記ステップ（４３０）と、各イベント・ターゲット・エンティティが、前記ルールの各々の変更に応じ実行される前記対応するイベントを検知できるようにするステップ（４１８〜４５７）と、
   をさらに含む、請求項１から請求項３のいずれかに記載の方法（４００）。
5. 前記イベント・ターゲット・エンティティのうち、前記変更されたルールに対応し影響を受けるものを識別するステップ（４３０）と、各イベント・ターゲット・エンティティに対し前記ルール中に定義されている前記イベントを判定する前記ステップ（４３０）と、各イベント・ターゲット・エンティティが、前記影響を受けるイベント・ターゲット・エンティティに限定されている前記対応するイベントを検知できるようにするステップ（４１８〜４５７）と、
   をさらに含む、請求項４に記載の方法（４００）。
6. データ処理システム（１０５）に、請求項１から請求項５のいずれかに記載の方法（４００）を実行させるためのコンピュータ・プログラム（３００）。
7. 請求項１から請求項５のいずれかに記載の方法（４００）の各ステップを実施するための手段（３００）を含むシステム（１０５）。

Images