(57)【要約】【課題】複数のサーバからアクセスできるキューを利用して、クラスタ構成に対応したスケジューラと同等の機能を実現することが可能な情報処理システムを提供すること。【解決手段】サーバと、複数のサーバから共通に利用されるキューを備えたシステムであって、サーバは、キューを監視し、キューメッセージを取得する監視手段と、取得したキューメッセージを解析する解析手段と、解析手段による解析結果に基づき、タスクの実行要求を行う要求手段と、を有し、キューメッセージは、タイマー情報およびタスク情報を含み、解析手段は、タイマー情報からタスクを実行するか否かを判断し、タスクを実行すると判断した場合は、要求手段にタスクの実行要求を行うことを指示する、ことを特徴とする。【選択図】図１１
2016018396.tif 000002
【特許請求の範囲】
【請求項１】
サーバと、複数のサーバから共通に利用されるキューを備えたシステムであって、
前記サーバは、
前記キューを監視し、キューメッセージを取得する監視手段と、
取得した前記キューメッセージを解析する解析手段と、
前記解析手段による解析結果に基づき、タスクの実行要求を行う要求手段と、を有し、
前記キューメッセージは、タイマー情報およびタスク情報を含み、
前記解析手段は、前記タイマー情報からタスクを実行するか否かを判断し、
前記タスクを実行すると判断した場合は、前記要求手段に前記タスクの実行要求を行うことを指示する、ことを特徴とする情報処理システム。
【請求項２】
前記解析手段が前記タスクを実行しないと判断した場合に、前記キューメッセージの次の監視タイミングを前記キューに設定する設定手段を備えることを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記解析手段は、前記タイマー情報に含まれる前記タスクを実行する日時と現在日時とを比較し、前記実行する日時が現在日時に達していた場合に、前記タスクを実行すると判断することを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記解析手段が前記タスクを実行すると判断した場合に、前記設定手段は、前記キューメッセージが前記サーバとは異なる他のサーバから取得されないように、前記キューメッセージの次の監視タイミングを前記キューに設定することを特徴とする請求項２または３に記載の情報処理システム。
【請求項５】
前記設定手段は、前記キューメッセージの次の監視タイミングを前記キューに設定する際に、
現在日時から前記キューに予め設定された所定の間隔が経過した日時が前記タスクを実行する日時を過ぎる場合は、前記次の監視タイミングを前記タスクを実行する日時に設定し、
前記現在日時から前記キューに予め設定された所定の間隔が経過した日時が前記タスクを実行する日時を過ぎない場合は、前記次の監視タイミングを前記現在日時から前記キューに予め設定された所定の間隔が経過した日時に設定することを特徴とする請求項２ないし４のいずれか１項に記載の情報処理システム。
【請求項６】
前記タスクの実行要求に基づく処理が成功した場合に、前記キューから前記キューメッセージを削除するとともに次のキューメッセージを前記キューに登録する登録手段を備え、
前記処理が失敗した場合には、前記設定手段が再度、前記タスクが実行されるように前記キューメッセージの次の監視タイミングを前記キューに設定することを特徴とする請求項２ないし５のいずれか１項に記載の情報処理システム。
【請求項７】
前記タスクが印刷データを複数のデバイスへ配信する処理であるとき、前記登録手段は、前記複数のデバイスのうち処理が失敗したデバイスがある場合に、前記失敗したデバイスを対象とした再配信タスクおよび前記再配信タスクを行うまでの間隔の指定を含む新たなキューメッセージを前記キューに登録し、
前記処理が失敗したデバイスに前記再配信が行われることを前記デバイスの担当者に通知する通知手段を備えることを特徴とする請求項６に記載の情報処理システム。
【請求項８】
前記キューに重複するキューメッセージが存在する場合に、生成されているメッセージ数が所定数以上の場合に、前記キューから前記キューへの登録日時が古い前記キューメッセージを削除する制御手段を備えることを特徴とする請求項１ないし７のいずれか１項に記載の情報処理システム。
【請求項９】
キューメッセージを複数のサーバから共通に利用されるキューに登録する登録手段と、
前記キューを監視し、前記キューメッセージを取得する監視手段と、
取得した前記キューメッセージを解析する解析手段と、
前記解析手段による解析結果に基づき、タスクの実行要求を行う要求手段と、を有し、
前記キューメッセージは、タイマー情報およびタスク情報を含み、
前記解析手段は、前記タイマー情報からタスクを実行するか否かを判断し、
前記タスクを実行すると判断した場合は、前記要求手段に前記タスクの実行要求を行うことを指示する、ことを特徴とするサーバ。
【請求項１０】
情報処理システムの制御方法であって、
複数のサーバから共通に利用されるキューを監視し、キューメッセージを取得する監視工程と、
取得した前記キューメッセージを解析する解析工程と、
前記解析工程による解析結果に基づき、タスクの実行要求を行う要求工程と、を有し、
前記キューメッセージは、タイマー情報およびタスク情報を含み、
前記解析工程では、前記タイマー情報からタスクを実行するか否かを判断し、
前記タスクを実行すると判断した場合は、前記要求工程において前記タスクの実行要求を行うことを指示する、ことを特徴とする制御方法。
【請求項１１】
請求項１０に記載の制御方法をコンピュータに実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、サーバ、制御方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
コンピュータシステムでは、定期的にタスクを実行するためのモジュールとして、スケジューラ機能が用意されている。スケジューラはシステム上で常駐して動作しており、指定された日時や一定の期間に達すると、タスクを実行する機能である。特許文献１は、１台以上のサーバがそれぞれスケジューラを有するシステムを開示している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１２９３７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
大量の処理を行うシステムでは、複数のＷｅｂサーバやアプリケーションサーバを１台の情報処理装置として扱うクラスタ構成にする場合が多い。この場合、スケジューラもシステムとして提供する機能であるため、クラスタ構成に対応した複数のサーバに共通のスケジューラを有することが望ましい。しかし、クラスタ構成に対応したスケジューラは特定のアプリケーションサーバ上で動作するものに限定されており、他のアプリケーションサーバを利用する場合には、スケジューラをクラスタ構成にできないという課題がある。
【０００５】
本発明は、このような状況を鑑みてなされたものであり、例えば、複数のサーバからアクセスできるキューを利用して、クラスタ構成に対応したスケジューラと同等の機能を実現することが可能な情報処理システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明は、サーバと、複数のサーバから共通に利用されるキューを備えたシステムであって、サーバは、キューを監視し、キューメッセージを取得する監視手段と、取得したキューメッセージを解析する解析手段と、解析手段による解析結果に基づき、タスクの実行要求を行う要求手段と、を有し、キューメッセージは、タイマー情報およびタスク情報を含み、解析手段は、タイマー情報からタスクを実行するか否かを判断し、タスクを実行すると判断した場合は、要求手段にタスクの実行要求を行うことを指示する、ことを特徴とする。
【発明の効果】
【０００７】
本発明によれば、例えば、複数のサーバからアクセスできるキューを利用して、クラスタ構成に対応したスケジューラと同等の機能を実現することが可能な情報処理システムを提供することができる。
【図面の簡単な説明】
【０００８】
【図１】一実施形態に係る情報処理システムのネットワーク構成を示す図である。
【図２】一実施形態に係るサーバのハードウェア構成例を示す図である。
【図３】キューメッセージの生成から削除までの流れを説明する図である。
【図４】キューメッセージを操作するＡＰＩを説明する図である。
【図５】一実施形態に係る各装置のモジュール構成図である。
【図６】キュー監視モジュールの機能ブロック図である。
【図７】一実施形態におけるキューメッセージの例を示す図である。
【図８】キューメッセージの初期登録を説明するフローチャートである
【図９】キューメッセージ監視処理のシーケンス図である。
【図１０】キューメッセージ取得時の調整処理を説明する図である。
【図１１】キューメッセージ取得後の処理を説明するフローチャートである。
【図１２】一実施形態に係るシステムを利用した配信印刷の例を示した図である。
【図１３】配信印刷タスク処理を説明するフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明を実施するための形態について図面などを参照して説明する。
【００１０】
（第１実施形態）
図１は、本発明の一実施形態に係る情報処理システムのネットワーク構成を示す図である。２１０はインターネット、線２２０はネットワーク線を示している。２３０から２８０の各機器はネットワーク線２２０で相互に接続されて通信を行う。また、ネットワーク線２２０はインターネット２１０に接続されており、他の様々なネットワークに接続している。
【００１１】
ロードバランサ２３０はサーバコンピュータ（以下サーバと略称）２４０およびサーバコンピュータ２５０と接続している。サーバ２４０とサーバ２５０は同じ構成になっており、それぞれ図２で示す構成を備えている。ロードバランサ２３０はインターネット２１０から送られてきたリクエストをサーバ２４０とサーバ２５０に振り分け、処理の負荷分散をはかっている。サーバ２４０とサーバ２５０はさらに、データベース２６０、ストレージ２７０、キュー２８０と接続されており、通信を行う。
【００１２】
図２は、図１に示したサーバ２４０のハードウェア構成例を示す図である。サーバ２４０は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下Ｉ／Ｏと略称）インタフェース１０６、通信インタフェース１０７を備えている。また、サーバ２４０内の各構成要素はシステムバス１０１を介して互いに接続されている。ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）から構成される。記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＣＤ−ＲＯＭドライブ１１２、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）１１３がある。図２には示されていないが、記憶装置１０４としては、磁気テープドライブ、ＤＶＤドライブ、ＵＳＢメモリなども使用されることがある。
【００１３】
本実施形態に係るプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納した上で、ＣＰＵ１０２によって実行される。なお、本実施形態ではプログラムを記憶装置１０４から読み込む構成としているが、ＲＯＭ（不図示）から読み込んだり、通信インタフェース１０７を介して外部から読み込んだりする構成としてもよい。
【００１４】
ビデオインタフェース１０５は、ディスプレイ装置１１４への表示出力を制御する。ディスプレイ装置１１４には、ＣＲＴや液晶等の方式を用いたものがある。Ｉ／Ｏインタフェース１０６には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することによりサーバ２４０に対する動作指令等を行う。ポインティングデバイス１１６は、ディスプレイ装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ装置１１４は出力装置と入力装置を兼ねることになる。なお、サーバの形態によっては、表示出力機能が省かれている場合もある。
【００１５】
通信インタフェース１０７は、コンピュータネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、ＬＡＮやＷＡＮ、インターネットのような公衆回線等がある。また、通信インタフェース１０７は、ローカルプリンタ１１８などの他デバイスとの通信も行う。
【００１６】
なお、図１の例ではインターネット２１０に接続しているが、ＬＡＮやＷＡＮであっても構わない。また、サーバ２４０とサーバ２５０の２台に限らず、複数のサーバで構成されることもある。また、サーバは単体のコンピュータに限らず、ラックマウント型のシステムや仮想マシン上にあっても構わない。
【００１７】
サーバ２４０とサーバ２５０はクラスタ構成をとることもある。クラスタ構成とは複数のサーバが論理的に連結され、全体で１台のコンピュータであるかのように振舞うシステムである。サーバ２４０とサーバ２５０のクラスタ構成は、各々のサーバ上で動作するＷｅｂサーバプログラムがセッション情報を共有することで実現される。サーバ２４０とサーバ２５０が単独で存在する場合、ロードバランサ２３０がリクエストの振り分けを行うが、複数のリクエストにまたがる一連の処理は連続性を確保するため１台のサーバで担当しなければならなくなる。そのため、リクエスト単位での負荷分散ができなくなる。しかし、クラスタ構成をとれば、セッション情報が共有化されるため、複数のリクエストにまたがる一連の処理を複数のサーバで処理することができるようになり、リクエスト単位に負荷分散が可能となる。
【００１８】
また、システム全体で行うような処理を特定のサーバに担当させることも負荷分散ができず、システム全体としては効率的ではない。例えばデータベースやストレージ上のデータを定期的に整理するタスクや、データベースに格納された宛先に基づいて電子メールを配信するタスクなど、定期的なタスクを実行するスケジューラもこれに該当する。これらの定期的なタスクは、特定のサーバに依存する処理ではなく、システム全体として実行するタスクであるため、クラスタ構成に対応したスケジューラであることが望ましい。
【００１９】
本実施形態では、複数のサーバからアクセスが可能なキュー２８０を利用して、クラスタ構成に対応したスケジューラと同等の機能を搭載する方法について説明する。まず、本実施例の内容を説明する前に、図３と図４を用いて、図１のキュー２８０について説明する。キュー２８０は、メッセージを格納するメッセージキューである。図３は、キュー２８０におけるキューメッセージの生成から削除までの流れを説明する図である。図３（Ａ）において、線３００は時間軸をあらわしている。３０１はキュー２８０に対してキューメッセージの登録要求を行うことを示す。登録要求を受けるとキュー２８０は、キューメッセージ３０２を生成する。キューメッセージ３０２は削除要求が行われるまで生存し続けることになる。Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙ３０３は、生成されたキューメッセージが公開されるまでの間隔である。例えば、３０４はキューメッセージ取得要求を示しているが、キューメッセージ３０２が生成されていても公開前であるため、キューメッセージ３０２は取得されない。なお、Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙ３０３はメッセージ登録要求３０１の時に所定の間隔を設定することができる。公開されるとキューメッセージは取得が可能となる。メッセージ登録要求３０１からＤｅｌｉｖｅｒｙ  Ｄｅｌａｙ３０３の時間を経過すると、キューメッセージは公開される。従って、キューメッセージ取得要求３０５では、キューメッセージ３０２が取得されることになる。
【００２０】
Ｖｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔ３０６はキューメッセージを隠しておく間隔である。キューは複数のサーバから参照される。そのため、あるサーバがキューメッセージを取得した後、別のサーバが同じキューメッセージを取得してしまうと、そのキューメッセージに関するタスクが重複して実行されてしまうことになる。そのため、キューのシステムには一時的にキューメッセージを隠す機能がある。キュー２８０は、キューメッセージ取得要求３０５が行われたときに、キューメッセージ３０２を隠し、他のサーバがキューメッセージ３０２を取得できないようにする。キューメッセージ３０２はＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔ３０６の間隔が終わるまで取得することができなくなる。そのため、キューメッセージ取得要求３０７ではキューメッセージ３０２は取得されない。Ｖｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔ３０６の所定の間隔は、キュー２８０に設定されたデフォルト値に基づいて設定されるが、キューメッセージ取得要求３０５を行ったサーバが間隔を変更することもできる。
【００２１】
ここで、図４を用いてキューメッセージを操作するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）について説明する。４１０はキューメッセージの取得要求を行うＡＰＩである。キューメッセージが取得された場合、キューメッセージ情報４１１が返される。キューメッセージ情報４１１にはメッセージの内容やメッセージアクセスハンドルが含まれている。キューメッセージの削除要求４２０や、キューメッセージのＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔ変更要求４３０は、キューメッセージ情報４１１に格納されているメッセージアクセスハンドルを使って行う。つまり、図３（Ａ）のＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔ３０６の間、他サーバはキューメッセージ３０２にアクセスできないが、キューメッセージ３０２を取得したサーバだけはキューメッセージ３０２を操作できる。図３（Ａ）の３０８は、キューメッセージ３０２の削除要求である。キューメッセージの削除要求が行われると、キューメッセージ３０２は削除される。
【００２２】
一方、キューメッセージの削除要求が行われない場合を示したのが図３（Ｂ）である。キューメッセージの削除要求がないと、キューメッセージは取得とＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを繰り返しながらキューに存在し続ける。しかし、キューメッセージには生存可能期間があり、その期間を過ぎるとキューから削除されることになる。そのキューメッセージの生存可能期間がＲｅｔｅｎｔｉｏｎ  Ｐｅｒｉｏｄ３１１である。
【００２３】
図５は本実施形態に係る各装置のモジュール構成を示した図である。ロードバランサ２３０、サーバ２４０、サーバ２５０、キュー２８０の構成は、図１で示した通りである。サーバ２４０内には、Ｗｅｂサーバプログラム（以下Ｗｅｂサーバと略称）５０１とアプリケーションサーバプログラム（以下アプリケーションサーバと略称）５０２がインストールされている。Ｗｅｂサーバ５０１はＨＴＴＰ等のプロトコルに基づいて他のシステムと通信を行うプログラムである。アプリケーションサーバ５０２は、Ｗｅｂサーバ５０１から受け取ったリクエスト等に対して処理を行うプログラムである。サーバ２５０内にも同様にＷｅｂサーバ５１１、アプリケーションサーバ５１２がインストールされている。
【００２４】
アプリケーションサーバ５０２および５１２には、それぞれキュー監視モジュール５０３および５１３が搭載されている。キュー監視モジュール５０３とキュー監視モジュール５１３は同じモジュールである。キュー２８０にはキューメッセージ５２１が登録される。キュー監視モジュール５０３とキュー監視モジュール５１３が共通のキュー２８０のキューメッセージ５２１を監視し、キューメッセージを取得、内容の解析を行うことでスケジューラ機能を提供することになる。なお、キューメッセージ５２１は複数になることもある。また、サーバも２台に限らず、３台以上になる構成であっても構わない。
【００２５】
図６は、キュー監視モジュール５０３および５１３の機能ブロック図である。本機能ブロックはサーバ２４０やサーバ２５０内にあるアプリケーションサーバ５０２やアプリケーションサーバ５１２で実行される。キューアクセス部６０１（監視手段）はキュー２８０へのアクセスを行う。メッセージ作成部６０２（解析手段）はキュー２８０へ登録するキューメッセージ５２１を作成する。メッセージ解析部６０３はキューアクセス部６０１がキュー２８０から取得したキューメッセージ５２１の内容を解析する。スケジュール調整部６０４（設定手段）は、メッセージ解析部６０３の解析結果を受けてキュー２８０に登録されているキューメッセージ５２１の設定を調整する。イベント発生部６０５は、メッセージ解析部６０３で解析された結果、スケジュール実行時間に達していた場合にイベントを発生させる。イベントの発生を受けて、タスク実行依頼部６０６が他モジュールへのタスク実行を依頼する。即ち、イベント発生部６０５とタスク実行依頼部６０６は、タスクの実行要求を行う要求手段として機能する。
【００２６】
図７は、キューメッセージ５２１の例を示している。７００はキューメッセージのメッセージ文字列を表現しており、タイマー情報およびタスク情報を含む。具体的には、ＴａｓｋＮａｍｅは実行するタスクの名称である。キュー監視モジュール５０３、５１３はタスク名称に応じて実行するタスクを判断する。ＥｘｅｃｕｔｉｏｎＤａｔｅはスケジュールされた実行日時である。キュー監視モジュール５０３および５１３は、実行日時が現在日時を過ぎていた場合にイベントを発生させてタスクを実行する。ＲｅｇｉｓｔｅｒｅｄＤａｔｅはスケジュールの登録日時である。ＥｘｅｃｕｔｉｏｎＤａｔｅに設定したスケジュールされたキューメッセージを登録する際の日時である。ＱｕｅＲｅｇｉｓｔｅｒｅｄＤａｔｅはキューメッセージを登録する際の日時である。キューメッセージには図３の３１１で示したように生存期間が存在する。そのため、生存期間よりも長いスケジュールを行った場合、キューメッセージの削除および追加をしてリフレッシュする必要がある。ＲｅｇｉｓｔｅｒｅｄＤａｔｅはスケジュールされたキューメッセージを最初に登録した日時であり、一方、ＱｕｅＲｅｇｉｓｔｅｒｅｄＤａｔｅはキューメッセージをリフレッシュする際に更新される。ＥｘｅｃｕｔｅＣｏｕｎｔは実行回数を示す。キュー監視モジュール５０３および５１３は実行回数分のタスクを実行する。すなわち、タスク実行後、ＥｘｅｃｕｔｅＣｏｕｎｔをデクリメントして再び同じ期間でスケジュールされたキューメッセージを登録する。ＥｘｅｃｕｔｅＣｏｕｎｔが−１の場合は、継続して実行することを意味する。
【００２７】
図８は、キューメッセージの初期登録を説明するフローチャートである。キューメッセージの登録要求はシステムを最初に起動したとき等にキュー監視モジュールが行う。登録要求を行うのは１つのサーバのみであり、例えば、クラスタ構成のホストサーバが実行する方法が考えられる。キューメッセージの登録要求は、まず、キュー監視モジュールのメッセージ作成部６０２で設定ファイルの読み込みを行う（Ｓ８０１）。設定ファイルはスケジュール情報が記載されたファイルで、図１のサーバ２４０が登録を行う場合は、サーバ２４０内の記憶装置１０４、もしくは、ストレージ２７０、データベース２６０等に保管されている。次に設定ファイルの内容に従って、図７で示したキューメッセージとして登録すべき内容のメッセージデータを作成する（Ｓ８０２）。設定ファイルにはメッセージデータのＴａｓｋＮａｍｅ、ＥｘｅｃｕｔｉｏｎＤａｔｅ、ＥｘｅｃｕｔｅＣｏｕｎｔに相当するスケジュール情報が設定されている。ＥｘｅｃｕｔｉｏｎＤａｔｅは、設定ファイルに記載されたスケジュール情報に応じ、現在日時を考慮した上で決定される。次にＤｅｌｉｖｅｒｙ  Ｄｅｌａｙの調整を行う。Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙは図３の３０３で示したキューメッセージ公開までの間隔であり、実行日時がＤｅｌｉｖｅｒｙ  Ｄｅｌａｙよりも前にあると実行が遅れてしまうため調整が必要となる。キュー２８０にはＤｅｌｉｖｅｒｙ  Ｄｅｌａｙのデフォルト値Ｄｅｆａｕｌｔ  Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙが設定されており、キューメッセージ登録要求でＤｅｌｉｖｅｒｙ  Ｄｅｌａｙ値を設定しない場合は、デフォルト値が使われる。そこで、現在日時にＤｅｆａｕｌｔ  Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙの値を加算し、その日時が実行日時よりも後の場合には（Ｓ８０３）、Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙの値を実行日時までの間隔にする（Ｓ８０４）。そして、ＲｅｇｉｓｔｅｒｅｄＤａｔｅおよびＱｕｅＲｅｇｉｓｔｅｒｅｄＤａｔｅに現在日時を設定して（Ｓ８０５）、キュー２８０に対してキューメッセージの登録要求を出す（Ｓ８０６）。
【００２８】
図９は、キューメッセージ監視処理のシーケンス図で、キューメッセージ取得の大まかな流れと各モジュールの関係を示している。９１０はキュー監視モジュール５０３または５１３のライン、９２０はキュー２８０のラインである。９３０はタスク実行モジュールのラインでキューメッセージ５２１のＴａｓｋＮａｍｅによって示されたタスクを実行するモジュールを表している。タスク実行モジュールは、サーバ２４０やサーバ２５０内に存在するモジュールの場合もあれば、別システムに存在する場合もある。キュー監視モジュールのライン９１０からキューのライン９２０への処理はキューアクセス部６０１で実行され、キュー監視モジュールのライン９１０からタスク実行モジュールのライン９３０への処理はタスク実行依頼部６０６で実行される。
【００２９】
キュー監視モジュールはキューに対してポーリングを行い監視している。９１１、９１２はポーリングを行う同期メッセージで、キューメッセージの取得要求を行う。取得可能なキューメッセージが存在しなければ、キューメッセージは取得されない。図３で示したようにキューメッセージが生成されていたとしても取得されない場合がある。このようにキュー監視モジュールはポーリングを続け、取得可能なキューメッセージが発生した場合にキューメッセージが取得される。９１３はキューメッセージが取得されたケースであり、この場合、キュー監視モジュールはキューメッセージのＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを変更し（９１４）、実行日時に達していればタスク実行モジュールにタスクの実行を要求する（９１５）。なお、タスク実行要求９１５は、非同期メッセージの場合もある。タスク実行モジュールはタスク処理を行い（９３１）、キュー監視モジュールに応答を返す。キュー監視モジュールは応答を受信すると、完了したキューメッセージを削除し（９１６）、次のタスクのキューメッセージを登録する（９１７）。
【００３０】
図９でキューメッセージ取得の大まかな流れを説明したが、図１０、図１１でキューメッセージ取得時の詳細な処理について説明する。図１０はキューメッセージ取得時の調整処理を説明した図である。図３でキューメッセージのライフサイクルについて説明した通り、キューメッセージにはＤｅｌｉｖｅｒｙ  ＤｅｌａｙやＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔといった、キューメッセージが参照できない間隔が存在する。本実施例では、複数の監視モジュールが図９で示したポーリングを行ってキューを監視している。そのため、Ｄｅｌｉｖｅｒｙ  ＤｅｌａｙやＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを可能な限り長く設定し、キューメッセージの監視タイミングを調整することで無駄なキューメッセージの取得を行わないようにしている。しかし、スケジュールされた実行日時に処理が行われるためには、Ｄｅｌｉｖｅｒｙ  ＤｅｌａｙやＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを実行日時に合せて調整する必要がある。Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙの設定に関しては図８で示した通りである。
【００３１】
図１０は、図３と同様にキューメッセージのライフサイクルを示している。１００５は実行日時を示しており、実行日時１００５にキューメッセージを取得できるように、Ｄｅｌｉｖｅｒｙ  ＤｅｌａｙやＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを調整することになる。なお、実行日時１００５は、図７で示したキューメッセージのＥｘｅｃｕｔｉｏｎＤａｔｅに設定された値である。１００１でキューメッセージを取得した場合、Ｖｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔとして設定可能な最大値よりも実行日時までの間隔が長いため、Ｖｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔの最大値を設定する。キューメッセージを取得すると、解析処理を行う必要があるため、可能な限り長い値を設定したほうが無駄な処理を省くことができる。Ｖｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔの間隔が終わると１００３でキューメッセージの取得が行われる。ここで、実行日時１００５までの間隔はＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔの最大値よりも短いため、１００４のＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔは実行日時１００５までの間隔を設定する。このようにすることによって、実行日時１００５に次のキューメッセージ取得時１００６があり、タイミングよくタスクの実行ができる。
【００３２】
図１１はキュー監視モジュール５０３または５１３がキューメッセージ取得後に実行する処理を説明するフローチャートである。キューアクセス部６０１がキューメッセージを取得すると（Ｓ１１０１）、メッセージ解析部６０３がキューメッセージのＥｘｅｃｕｔｉｏｎＤａｔｅに設定された実行日時を参照し、現在日時が実行日時を過ぎているかどうかを確認する（Ｓ１１０２）。現在日時が実行日時を過ぎていた場合は、スケジュール調整部６０４がキューメッセージにＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを設定する（Ｓ１１０３）。Ｓ１１０３でＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを設定するのは、タスク処理を実行している間に、他のサーバがキューメッセージを取得しないようにするためであり、タスクの実行時間に応じて設定を行う。次にイベント発生部６０５がスケジュール実行日時に達した旨のイベントを発生し、タスク実行依頼部６０６がタスク処理の実行を依頼する（Ｓ１１０４）。タスク処理が成功すると次のタスクスケジューリングを行うことになり、タスク処理が失敗すると現タスクが再度、実行されるように次の監視タイミングの再調整を行うことになる（Ｓ１１０５）。タスク処理が成功すると、メッセージ解析部６０３がキューメッセージのＥｘｅｃｕｔｅＣｏｕｎｔを参照し、−１、すなわち継続して実行するタスクであれば（Ｓ１１０６）、次のタスクスケジュール用のメッセージデータを作成する（Ｓ１１０９）。ＥｘｅｃｕｔｅＣｏｕｎｔが−１以外の場合はＥｘｅｃｕｔｅＣｏｕｎｔをデクリメントし（Ｓ１１０７）、ＥｘｅｃｕｔｅＣｏｕｎｔが０より大きければ次のタスクスケジュール用のメッセージデータを作成する（Ｓ１１０９）。０以下の場合は取得したキューメッセージを削除する。キューメッセージを作成したら、キューアクセス部６０１が作成したキューメッセージを登録し（Ｓ１１１０）、取得したキューメッセージは削除する（Ｓ１１１１）。
【００３３】
Ｓ１１０２で現在日時が実行日時より前であった場合は、図３や図１０で説明したようにＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔ等の調整が必要になる。Ｓ１１０２で現在日時が実行日時より前であった場合、キューメッセージの保持期限に近づいているかを確認する（Ｓ１１１２）。キューメッセージの保持期限は、キューメッセージのＱｕｅＲｅｇｉｓｔｅｒｅｄＤａｔｅに図３のＲｅｔｅｎｔｉｏｎ  Ｐｅｒｉｏｄ３１１を加算した日時である。この日時から次の確認（監視）タイミングまでのバッファとなる期間、例えばＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔの最大値を差し引いた日時を現在日時が越えていなかった場合は、保持期限まで期間に余裕があるとみなす。保持期限まで期間に余裕がある場合は、現在日時にＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔの最大値を加算した日時と、実行日時を比較する（Ｓ１１１３）。実行日時のほうが短ければＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔを実行日時までの間隔に設定し（Ｓ１１１４）、長ければＶｉｓｉｂｉｌｉｔｙ  ＴｉｍｅｏｕｔをＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔの最大値に設定する（Ｓ１１１５）。そして、キューアクセス部６０１がキュー２８０に対してキューメッセージにＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔの変更要求を出す（Ｓ１１１６）。
【００３４】
Ｓ１１１２で保持期限まで期間に余裕がないと判断した場合は、図３（Ｂ）で説明したようにキューメッセージのリフレッシュ（更新）を行う必要がある。図８のキューメッセージ初期登録と同様に、現在日時にＤｅｆａｕｌｔ  Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙの値を加算し、その日時が実行日時よりも後の場合には（Ｓ１１１７）、Ｄｅｌｉｖｅｒｙ  Ｄｅｌａｙの値を実行日時までの間隔に設定する（Ｓ１１１８）。そしてＱｕｅＲｅｇｉｓｔｅｒｅｄＤａｔｅを現在日時に更新したメッセージデータを作成し（Ｓ１１１９）、キューメッセージの登録（Ｓ１１１０）と削除（Ｓ１１１１）を行ってリフレッシュする。なお、更新したキューメッセージを登録した後、旧メッセージの削除に失敗した場合や、キューメッセージがＶｉｓｉｂｉｌｉｔｙ  Ｔｉｍｅｏｕｔ等により参照できない状態の際に同じタスク情報を有するキューメッセージが複数作成されることがありうる。このように同じ種類のキューメッセージがキューに複数存在する（メッセージ数が所定数以上ある）場合に、例えばサーバが備えるＣＰＵ１０２が、キューに登録した日時（ＲｅｇｉｓｔｅｒｅｄＤａｔｅ）が古いキューメッセージを削除する制御を行ってもよい。
【００３５】
以上の処理を実行することによって、クラスタ構成のシステムにおいて、クラスタ構成に対応したスケジューラと同等の機能を実現することが可能となる。
【００３６】
次に、図１２、図１３を用いてタスク処理がエラーとなるケースの一例とその対応処理に関して説明する。図１２は、本実施形態に係るシステムを利用した配信印刷の例を示した図で、図１や図５で示した本システムにコピー機１２０１およびコピー機１２０２がネットワークを通じてつながっていることを示している。毎朝定時に各事業所のコピー機に対して掲示物データ（印刷データ）を配信、印刷を行うようにスケジュールされている。コピー機が起動していた場合は配信印刷のタスク処理が成功するが、コピー機が停止していた場合は配信印刷が失敗してしまう。しかし、タスク処理側で再処理を行っても失敗するだけであり、また、全てのコピー機が失敗したわけではないので、スケジュールされたタスクを再実行するわけにも行かない。またタスクを完了させて翌日の朝に配信印刷処理を実行するわけにも行かない。このようなケースの対応方法を示したのが、図１３の配信印刷タスク処理のフローチャートである。処理は本システムのサーバが備えるアプリケーションサーバが、配信対象のコピー機分行う（Ｓ１３０１）。アプリケーションサーバは、送信先等の情報が記載された設定ファイルを読み込み（Ｓ１３０２）、配信と印刷指示を行う（Ｓ１３０３）。印刷が成功したら次のコピー機の処理へうつる。印刷が失敗した場合は（Ｓ１３０４）、アプリケーションサーバが設定ファイルから再実行までの間隔の指定と担当者情報とを取得し（Ｓ１３０５）、再配信タスクのキューメッセージを作成して登録する（Ｓ１３０６）。さらに担当者へ再配信する旨のメールを送信する（通知を行う）（Ｓ１３０７）。担当者がコピー機を起動し、そのコピー機への再配信を行うことで処理が成功する。このように詳細なタスク情報とスケジュール調整を行ったキューメッセージを登録することで、エラー発生時のリカバリも可能となる。
【００３７】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そしてそのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
【００３８】
以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【符号の説明】
【００３９】
２４０    サーバ
２５０    サーバ
２８０    キュー
６０１    キューアクセス部
６０２    メッセージ解析部
６０５    イベント発生部
６０６    タスク実行依頼部
【図１】
2016018396.tif 000003
【図２】
2016018396.tif 000004
【図３】
2016018396.tif 000005
【図４】
2016018396.tif 000006
【図５】
2016018396.tif 000007
【図６】
2016018396.tif 000008
【図７】
2016018396.tif 000009
【図８】
2016018396.tif 000010
【図９】
2016018396.tif 000011
【図１０】
2016018396.tif 000012
【図１１】
2016018396.tif 000013
【図１２】
2016018396.tif 000014
【図１３】
2016018396.tif 000015