(57)【要約】【課題】Ｗｅｂサービスが冗長化されている場合でも、素早く作業データを消去することを目的とする。【解決手段】複数のモジュールが連携して実行するジョブを管理するジョブ管理手段と、複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、モジュールを識別するモジュール識別情報と、モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する記憶手段と、クラッシュデータに含まれるモジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、モジュール識別情報で識別されるモジュールを起動し、モジュールに対して作業データを削除させる制御手段と、を有することによって課題を解決する。【選択図】図７
2015130005.tif 000002
【特許請求の範囲】
【請求項１】
複数のモジュールが連携して実行するジョブを管理するジョブ管理手段と、
前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する記憶手段と、
前記クラッシュデータに含まれる前記モジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、前記モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、前記モジュール識別情報で識別されるモジュールを起動し、前記モジュールに対して作業データを削除させる制御手段と、
を有するサーバー装置。
【請求項２】
前記モジュールによって前記作業データが削除されたのち、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を前記クラッシュデータより削除する削除手段を更に有する請求項１記載のサーバー装置。
【請求項３】
前記制御手段は、前記クラッシュデータに含まれる前記モジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、前記モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、前記モジュール識別情報で識別されるモジュールが起動されているか否かを判定し、前記実行環境で前記モジュールが起動されていない場合は、前記実行環境で前記モジュールを起動し、前記モジュールに対して作業データを削除させ、前記実行環境で前記モジュールが起動されている場合は、前記モジュールに対して作業データを削除させる請求項１又は２記載のサーバー装置。
【請求項４】
前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを使用するダミーのジョブを発行するジョブ発行手段を更に有し、
前記制御手段は、前記ジョブ発行手段により発行された、前記クラッシュデータに含まれる前記モジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、前記モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、前記モジュール識別情報で識別されるモジュールを起動し、前記モジュールに対して作業データを削除させる請求項１乃至３何れか１項記載のサーバー装置。
【請求項５】
前記記憶手段は、前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶すると共に、前記モジュールと連携してジョブを実行していた前記モジュールよりも前段の処理に係るモジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する請求項１乃至４何れか１項記載のサーバー装置。
【請求項６】
前記記憶手段は、前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶すると共に、前記モジュールと連携してジョブを実行していたモジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する請求項１乃至４何れか１項記載のサーバー装置。
【請求項７】
複数のモジュールが連携して実行するジョブを管理するジョブ管理手段と、
前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する記憶手段と、
前記クラッシュデータに含まれる前記モジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、前記モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、前記モジュール識別情報で識別されるモジュールを起動し、前記モジュールに対して作業データを削除させる制御手段と、
を有するシステム。
【請求項８】
サーバー装置が実行する情報処理方法であって、
複数のモジュールが連携して実行するジョブを管理するジョブ管理ステップと、
前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する記憶ステップと、
前記クラッシュデータに含まれる前記モジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、前記モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、前記モジュール識別情報で識別されるモジュールを起動し、前記モジュールに対して作業データを削除させる制御ステップと、
を含む情報処理方法。
【請求項９】
システムが実行する情報処理方法であって、
複数のモジュールが連携して実行するジョブを管理するジョブ管理ステップと、
前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する記憶ステップと、
前記クラッシュデータに含まれる前記モジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、前記モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、前記モジュール識別情報で識別されるモジュールを起動し、前記モジュールに対して作業データを削除させる制御ステップと、
を含む情報処理方法。
【請求項１０】
コンピュータを、請求項１乃至６何れか１項記載のサーバー装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバー装置、システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
ユーザ端末からのリクエストによりＷｅｂサービスが印刷データを生成し、その印刷データを印刷装置で受信して処理し、印刷を実行するシステムが存在する。そのようなＷｅｂサービスの代表例は特許文献１に開示されている"ｃｌｏｕｄ  ｐｒｉｎｔ  ｓｅｒｖｉｃｅ"が知られている（以下略して"ＣＰＳ"と称する）。ＣＰＳは各プリンターベンダーに仕様を公開し、仕様に沿ったプリンターを開発してもらうことでサービスの急速な拡大と利用者への利便性の提供とを実現しようとするものである。特許文献１にはＣＰＳにおけるプリンターの登録及び選択、印刷データの生成に関する技術が開示されている。
特徴としてＣＰＳはプリンターベンダー毎に特有のページ記述言語やプリントデータフォーマットに従った印刷データを生成するのではない。ＣＰＳはベンダー非依存の統一的なフォーマットで印刷データを生成し、各プリンターにその印刷データを直接入力データとして受け取ってもらい印刷を実現する。ベンダー非依存の統一的なフォーマットとしてはＰｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ（ＰＤＦ）が挙げられている。この仕様に従えば、ＣＰＳはプリンターベンダー非依存の画一的な印刷データ生成を行うことができる。サービスの利用者にとってはどのようなベンダーのプリンターであろうがＣＰＳに準拠したプリンターであれば自分の要求する印刷がどこからでも依頼できて、かつ、印刷物を受け取れる利便性が得られる。
【０００３】
これまでプリンタードライバーはアプリケーションが出力するドキュメントをプリンターが理解できるＰＤＬで記述した印刷データに変換する処理を行ってきた。加えてプリンタードライバーはプリンターの特性、トナー、インク、記録紙等に応じて色味の調査や、印刷モードの選定等の処理も行っていた。ところが、プリンタードライバーは、ユーザ端末上で動作しなければならないため、少なからず端末のリソースを消費する。昨今、ユーザ端末はその形状をデスクトップ型のＰＣ、ノート型のＰＣからスレート（タブレット）型やスマートフォンまで広げている。端末形状は小型化しバッテリーの消費が大きな課題となっている。また多様化するこれらの端末のＯＳに追従してプリンタードライバーを提供していくことはプリンターベンダーにとっては大きな負担となっている。
このように、プリンタードライバーを不要とするＣＰＳはユーザとプリンターベンダーとの両者にとって一見、救世主となるように見える。しかし、実際には、プリンタードライバーが必要とされていた本質的な意義であるプリンターの機能と特性とを生かしたデータ変換はやはり必要あることには変わりはない。小型化するユーザ端末に関しプリンタードライバーを端末上で動作させることなく今までと同じ画質、機能を提供する方策としてプリンタードライバーをクラウド上で動作させる方法が実用となっている。プリンターベンダーは自社のプリンターのプリンタードライバーをＷｅｂサービスとして動作させるサービスを提供する。このことで、特許文献１に示すＣＰＳと同等の利便性とこれまでのプリンタードライバーが提供していたプリンターの特性とを生かした印刷データの生成を両立させようとしている。
【０００４】
Ｗｅｂサービス上で動作するサービスやプロセスはユーザ端末から入力された入力ファイルに対して処理を行う。入力ファイルと、その入力ファイルに対する処理内容と、の組をジョブと呼び、ジョブに対して処理を実行することを、ジョブを実行すると呼ぶ。Ｗｅｂサービス上で動作するサービスやプロセスは、ジョブの実行時に、処理途中のデータを作業ファイルとして保存し、作業ファイルを参照しながら処理を行う場合がある。入力ファイルは顧客データであり、入力ファイルから作成した作業ファイルも顧客データである。顧客データは顧客データ保護の観点で、消去が必須である。通常は、ジョブの実行が終了した際に作業ファイルが消去される。しかし、Ｗｅｂサービス上で動作するサービスやプロセスが作業途中にクラッシュした場合、作業ファイルが残る可能性がある。この問題に対する従来技術として、プロセスの連結情報を保持し、処理を引き継ぐ技術がある（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２０１１／０２９９１１０号明細書
【特許文献２】特開２００１−２６５６１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
Ｗｅｂサービスは、複数のＷｅｂサービスが連携して、１つの機能を実現する場合がある。また、各Ｗｅｂサービスは冗長化されており、別々の環境に複数存在させることが可能であることが一般的である。
特許文献２では、処理を引き継ぐプロセスを動作させる環境を特定していないため、クラッシュした環境とは別の環境で、処理を引き継ぐモジュールが起動された場合、クラッシュしたモジュールがクラッシュした環境に残した作業ファイルを消すことができない。
【０００７】
本発明は、Ｗｅｂサービスが冗長化されている場合でも、素早く作業データを消去することを目的とする。
【課題を解決するための手段】
【０００８】
そこで、本発明は、サーバー装置であって、複数のモジュールが連携して実行するジョブを管理するジョブ管理手段と、前記複数のモジュールのうちの一のモジュールがクラッシュしたことが検知された場合、前記モジュールを識別するモジュール識別情報と、前記モジュールの実行環境に関する実行環境情報と、を対応付けてクラッシュデータに記憶する記憶手段と、前記クラッシュデータに含まれる前記モジュール識別情報で識別されるモジュールを使用するジョブを受け取った場合、前記モジュール識別情報と対応付けられている実行環境情報で示される実行環境で、前記モジュール識別情報で識別されるモジュールを起動し、前記モジュールに対して作業データを削除させる制御手段と、を有する。
【発明の効果】
【０００９】
本発明によれば、Ｗｅｂサービスが冗長化されている場合でも、素早く作業データを消去することができる。
【図面の簡単な説明】
【００１０】
【図１】印刷データ変換システムのシステム構成の一例を示す図である。
【図２】サーバーＰＣ等のハードウェア構成の一例を示す図である。
【図３】印刷データ変換サービスを含む印刷データ変換システムのソフトウェアの一例を示す図である。
【図４】印刷データ変換サービスが依頼された印刷データを変換する際に利用するソフトウエアコンポーネント群の関連を説明するための図である。
【図５】作業ファイルの作成や参照、消去を説明する図である。
【図６】実施形態１におけるジョブを実行する情報処理の一例を示すフローチャートである。
【図７】実施形態１におけるＳ９０３の処理の詳細を示したフローチャートである。
【図８】クラッシュリストの一例を示した図である。
【図９】クラッシュリストを作成する情報処理の一例を示すフローチャートである。
【図１０】実施形態２におけるＳ９０３の処理の詳細を示したフローチャートである。
【図１１】クラッシュリストを作成する情報処理の一例を示すフローチャートである。
【図１２】クラッシュリストを作成する情報処理の一例を示すフローチャートである。
【図１３】クラッシュリストを作成する情報処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態について図面に基づいて説明する。
【００１２】
＜実施形態１＞
図１は、印刷データ変換システムのシステム構成の一例を示す図である。本実施形態では印刷データ変換サービスを例に説明を行うが、本実施形態に係る処理は印刷データ変換サービスに限定されるものではなく、各種フォーマット変換や、データ変換、データ処理に適用することができる。
印刷データの変換を依頼する依頼者５０は、印刷データの変換要求を送出する機器として、パーソナルコンピュータ２０、タブレットＰＣ３０、携帯端末４０等の機器を利用する。依頼者５０は、これらの機器の内部で動作しているアプリケーションを操作して、ネットワーク１０上に存在する後述する印刷データ変換サービス２１００に対して印刷データの変換を依頼する。印刷データ変換サービス２１００は、サーバーＰＣ８０上でＷｅｌｌ−ｋｎｏｗｎのＵＲＬを公開している、所謂Ｗｅｂサービスとして動作している。サーバーＰＣ８０上では前記ＵＲＬに対して到着した依頼を印刷データ変換サービス２１００に転送するＷｅｂサーバー４１００も動作している。ＵＲＬへ到着する依頼は通常多数になるため、単一のサーバーＰＣ８０では処理させず、複数のサーバーＰＣ８０に処理させる構成とされる。したがって、複数のサーバーＰＣ８０の前段にロードバランサー７０が設置され、各サーバーＰＣ８０に転送される依頼が均一に配分されるように構成されている。
【００１３】
印刷データ変換サービス２１００が提供するサービスは、依頼者５０が指定するデータをプリンター６０で印刷できる形式に変換することである。依頼者が指定するデータにはドキュメント、画像ファイル等、各種のアプリケーションで作成されたフォーマットが存在する。一方、プリンター６０が印刷データとして受け付けるデータは前述のフォーマットとは異なり、ＰＤＬで記述されたデータや、印刷部数等の印刷を制御するための命令とパラメータを備えたＰＪＬで記述されたデータとなっている。ＰＤＬは、Ｐａｇｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅの略である。また、ＰＪＬは、Ｐｒｉｎｔ  Ｊｏｂ  Ｌａｎｇｕａｇｅの略である。
このように、依頼者５０とプリンター６０との間には扱うデータ形式の差異が存在するために、その差異を埋めるアプリケーションが必要とされる。通常この変換処理を行うのがプリンタードライバーと呼ばれるアプリケーションである。プリンタードライバーは依頼者５０が操作するＰＣ上で動作させることが通常である。しかし、プリンタードライバーの処理は比較的、ＣＰＵ、メモリ等のリソースを必要とする重い処理であるため、依頼者５０の操作するＰＣの保持するリソースが少ない場合には印刷処理が実用的でなくなる程時間のかかる処理になってしまう。依頼者５０が操作する端末（パーソナルコンピュータ２０、タブレットＰＣ３０、携帯端末４０）等リソースの比較的少ない端末からの印刷の需要が高まるにつれプリンタードライバーの処理をインターネット上のサービスで行わせることの重要性が増している。
【００１４】
依頼者５０は前述の各種端末から前述のＵＲＬに対して印刷データをプリンター６０で印刷できる形式に変換するように依頼を行う。依頼に応じてサーバーＰＣ８０上で動作している印刷データ変換サービス２１００が生成した変換後のデータは前述の端末に対して返送される。ここで、依頼者５０の指示によっては変換後のデータは印刷データ変換サービス２１００がアクセス可能なファイルサーバＰＣ９０で保管される場合もある。
【００１５】
図２は、サーバーＰＣ８０等のハードウェア構成の一例を示す図である。
ＣＰＵ１００５は、システム制御部であり、サーバーＰＣ８０全体を制御する。
ＲＯＭ１００３は、プログラムや各種固定データを格納する
ＲＡＭ１００４は、ＳＲＡＭ、ＤＲＡＭ等で構成され、プログラム制御変数等を格納する。また、各種設定パラメータ、各種ワーク用バッファもＲＡＭ１００４に格納される。
ＨＤＤ１００２は、文書や画像等のファイルデータやプログラム等を格納する。
通信装置１００８は、サーバーＰＣ８０を、ネットワークを介して他の装置、又は機器等と接続するための装置であって、通信を制御する。
各ハードウェア構成は、バス１００１を介して互いに接続されている。
図２には図示していないがサーバーＰＣ８０のハードウェア構成として入力装置や出力装置を有していてもよい。
ＣＰＵ１００５がＲＯＭ１００３又はＨＤＤ１００２に記憶されているプログラムをＲＡＭ１００４に読み出し、処理を実行することによって、後述するサーバーＰＣ８０のソフトウェア構成の一部又は全て及び後述するフローチャートに係る処理等が実現される。
例えば、１又は複数のサーバーＰＣ８０のＣＰＵ１００５がプログラムに基づき処理を実行することによって、上述した印刷データ変換サービス２１００の機能等が実現される。
【００１６】
図３は、印刷データ変換サービス２１００を含む印刷データ変換システムのソフトウェアの一例を示す図である。
Ｗｅｂサーバー４１００は、依頼者５０が操作したパーソナルコンピュータ２０上のアプリケーションからＨＴＴＰプロトコルで送信されたリクエストを受け取る。
ロードバランサー７０は、Ｗｅｂサーバー４１００の前段に位置し、複数のサーバーＰＣ８０上で動作しているＷｅｂサーバー４１００に処理を振り分ける。
ここで、サーバーＰＣ８０は必ずしも物理的な一台のサーバーＰＣを意味する必要はない。現時点で単一のＰＣ上に複数の仮想的なＰＣを出現させる仮想化技術が一般的となっており、ソフトウェアからみれば自身が動作しているオペレーティングシステムが仮想的に作り出されたものか否かは判別がつかないか、或いは判別する必要がない。したがって、本実施形態におけるサーバーＰＣ８０は「場合によっては仮想化されたＰＣ」を意味する場合もある。これ以降、「ＰＣ」という表現は物理的なＰＣと仮想化されたＰＣとの何れかを意味するものとして扱う。
【００１７】
アプリケーションサーバー４２００は、要求の送付先として指定されたＵＲＬを解析し、関連付けられている印刷データ変換サービス２１００を決定する。通常、Ｗｅｂサーバー４１００とアプリケーションサーバー４２００とは複数種のサービスを扱うことが可能であり、ＵＲＬから対応するサービスを特定して要求を振り分けることができる。本実施形態ではその複数種のサービスの一つが印刷データ変換サービス２１００であることを想定している。このサービスの他にもサービスが稼働しているが本実施形態においては印刷データ変換サービス２１００以外のサービスは省略する。
印刷データ変換サービス２１００は、プロセスとして動作する。アプリケーションサーバー４２００は、複数の要求を並列実行させるために、印刷データ変換サービス２１００を複数起動し、各々に要求を振り分ける。
【００１８】
（印刷データ変換サービス）
図４は、印刷データ変換サービス２１００が依頼された印刷データを変換する際に利用するソフトウエアコンポーネント群の関連を説明するための図である。
印刷データ変換サービス２１００は、先に説明したようにプロセスとして動作しており、変換処理をジョブコントローラー２３００に委譲している。構成的には印刷データ変換サービス２１００がジョブコントローラー２３００の代理としてのプロキシーモジュール２２００をロードしている。更にそのプロキシーモジュール２２００がＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）で提供している関数群を呼び出すことで変換処理の実行を依頼し、更に結果を受領する。ここで、ジョブコントローラー２３００もまたプロセスとして動作しており、変換処理の受付のための通信インターフェイスを保持している。この通信インターフェイスへのジョブの依頼はＨＴＴＰプロトコルではなく、専用のプロトコルが用いられている。プロキシーモジュール２２００のＡＰＩを呼び出す行為はジョブコントローラー２３００が用意している変換処理受付用通信インターフェイスへのプロセス間通信として変換される。即ち、印刷データ変換サービス２１００にとって変換処理はプロキシーモジュール２２００によって実行されているように見える。しかし実際には変換処理はジョブコントローラー２３００及び後述する複数のフィルター群及びフィルター群が利用するいくつかのコンポーネントの相互作用によって実現されている。
ジョブコントローラー２３００は、ジョブ管理手段の一例である。
【００１９】
（ロケーター）
印刷データ変換サービス２１００を構成するコンポーネントの中でロケーター２５００は特別な役割を担っている。ロケーター２５００はアプリケーションサーバー４２００が起動した時点で唯一起動している特殊なプロセスである。ロケーター２５００の起動の方法はアプリケーションサーバー４２００上で動作しているＯＳによって種々の方法が存在する。例えば、Ｗｉｎｄｏｗｓ（登録商標）であれば"Ｗｉｎｄｏｗｓ  Ｓｅｒｖｉｃｅ"というシステム起動時に自動的に起動される特殊なプロセスとして実装することが可能である。Ｌｉｎｕｘ（登録商標）やＵｎｉｘ（登録商標）ではデーモンプロセスとして動作させることが可能である。
ロケーター２５００は、コンポーネントの生成の責務を担っている。更に、ロケーター２５００は、他のコンポーネントからの求めに応じて別のコンポーネントのアクセスポイントを返すという機能を提供する。アクセスポイントとはＴＣＰ／ＩＰのリスンポートを指す。あるコンポーネントは別のコンポーネントが公開しているアクセスポイントを取得し、そのアクセスポイントにアクセスすることでそのコンポーネントが提供する機能を利用する。あるコンポーネントが他のコンポーネントのアクセスポイントをロケーター２５００に対して問い合わせる動作を"ロケーションクエリー"或いは単に"クエリー"と呼ぶ。
【００２０】
印刷データ変換サービス２１００を構成するコンポーネントのうちプロキシーモジュール２２００、ジョブコントローラー２３００、フィルターホスト２４００はロガー２６００が提供しているロギングデータをログファイルとして記録するサービスを利用している。そのためロケーター２５００に対してロガー２６００のアクセスポイントを得る目的でクエリーを行っている。同様にプロキシーモジュール２２００は、ジョブコントローラー２３００をクエリーする。そして、ジョブコントローラー２３００は、フィルターＡ２７００、フィルターＢ２８００、フィルターＣ２９００をクエリーする。
クエリーの詳細は後述する。
【００２１】
（ジョブコントローラー）
プロキシーモジュール２２００を介してジョブ実行を依頼されたジョブコントローラー２３００は、ジョブ及びジョブに含まれている印刷データを解析して変換に必要なフィルターを選定する。ジョブコントローラー２３００は、印刷データの先頭から既定のサイズを読み出しその中に含まれている特徴的な内容から印刷データの種類を判定し、解析する。例えば、ＪＰＥＧ形式や、ＰＤＦ形式のデータ等が入力データとして与えられる。次に、ジョブコントローラー２３００は、ジョブに含まれている変換先の印刷データ形式を取得し、変換元の印刷データ形式と変換先の印刷データ形式との両者が確定した時点で、この変換に必要なフィルター群を選定する。必要なフィルターの組み合わせとその変換順番とは固定的な情報としてジョブコントローラー２３００に実装されている。
【００２２】
必要な複数のフィルターを選定したあとは、ジョブコントローラー２３００は、これらフィルターのクエリーを行う。この例では変換に必要なフィルターとして、フィルターＡ２７００、フィルターＢ２８００、フィルターＣ２９００が必要である。
ジョブコントローラー２３００は、フィルターＡ２７００、フィルターＢ２８００、フィルターＣ２９００との間で、パイプライン３０００と呼ばれるデータ転送チャネルを作成する。本実施形態では、パイプライン構成を用いて説明を行うが、本実施形態に係る処理は、プロセスが連携して動作する処理一般に適用することができる。
パイプライン３０００は、基本的に片方向にのみデータを転送する。ジョブコントローラー２３００→フィルターＡ２７００→フィルターＢ２８００→フィルターＣ２９００→ジョブコントローラー２３００と一周するようにパイプライン３０００が構成される。また、ジョブコントローラー２３００は、プロキシーモジュール２２００との間にもパイプライン３０００を作成する。このようにパイプライン３０００を作成することで、印刷データはプロキシーモジュール２２００から複数のコンポーネントを還流し、最後に変換が終了した形で再びプロキシーモジュール２２００に戻ってくる。
【００２３】
（フィルター）
フィルターは、データ変換処理を実装したプロセスとして存在する。フィルターは、データ変換処理以外に、コントロールバス５００２への接続、メッセージ送受信、ジョブコントローラー２３００との通信、フィルターのログ出力のロガー２６００への転送等の処理を行う。
（ロガー）
ロガー２６００は、プロセスとして同一のコントロールバス５００２上に最低一つは存在する。コントロールバス５００２上のコンポーネントはジョブの実行中にログ出力を行う。ログの出力対象としてはファイルが一般的であるが全てのコンポーネントが独立してログファイルの出力を行うとサーバーＰＣ８０上のファイルＩ／Ｏの発生回数が増大し印刷データ変換サービス２１００全体のパフォーマンスが低下してしまう。そこで、各コンポーネントはログデータをロガー２６００に対してネットワークを介して送りつける。そして、ロガー２６００が一定量のログデータが蓄積した時点でログファイルに出力することになっている。ログファイルの出力パス等の設定はロガー２６００が起動される際に渡されるコンフィギュレーションファイルで指定される。
ここで、パイプライン３０００を還流するデータについて説明する。このデータは「変換ジョブ」と呼ばれる。
【００２４】
（変換ジョブ）
変換処理はプロキシーモジュール２２００のＡＰＩを通じて依頼される際に、変換ジョブ（以降、単にジョブと称す）の形で引き渡される。ジョブは概念的には変換されるべき対象データと変換処理用の設定値等とをまとまりのある形式に束ねた「チケット」と呼ばれるデータ構造から構成される。ジョブには識別できるようにユニークな識別情報（ジョブＩＤ）が与えられる。生成されたジョブはファイルとしてＲＡＭ１００４又はＨＤＤ１００２等の記憶装置に格納される。また記憶装置から取り出す際にはジョブＩＤを指定してそのファイルを取得して内容を参照することができる。またジョブを破棄する行為はファイルの削除として実現される。ジョブはこの印刷データの内容を直接ファイル内に含むか或いはファイル化した印刷データのファイルパス等の参照情報を含んでいる。更にジョブは印刷を行わせるプリンター６０が処理できる印刷ファイル形式についての情報も含んでいる。更にジョブは印刷部数や印刷の面付指示等の印刷の処理方法を指定する印刷設定を含んでいる。以降ではジョブを処理する行為を「ジョブを実行する」と呼ぶ。
【００２５】
（印刷データ）
印刷データは、プリンターが理解可能な形式で作成され、その内容をプリンターのメモリを介してハードウエアロジックに与えることが可能なバイナリ形式のデータである。或いは、印刷データは、ファームウエアとして実装されている変換ロジックに与えて印刷エンジンが処理可能な形式に変換できる何らかの記述言語（ＰＤＬ）で記述されたデータである。
印刷データは図２のパーソナルコンピュータ２０、タブレットＰＣ３０や携帯端末４０等の機器内に保持されているファイルから、或いはメモリ内から変換要求に埋め込まれた形で取得される。或いは印刷データは図２のファイルサーバＰＣ９０に予め格納されているファイルへの参照（ＵＲＬ或いはファイルパス）が変換要求から取り出されてそのファイル内容が取得される。
ここで図４に立ち戻り、印刷データ変換サービス２１００を構成しているコンポーネント群が他のコンポーネントをクエリーする意義と手順とを説明する。
【００２６】
（クエリーの意義）
コンポーネントが提供しているサービスはネットワークからアクセスできるエンドポイントとして他のコンポーネントに公開される。より具体的にはＴＣＰ／ＩＰのアドレスとポート番号との組が公開される。コンポーネントは他のコンポーネントの提供するサービスＩ／Ｆを取得して利用する。複数種類のコンポーネントがプロセスとして複数存在し、かつ、同一コンポーネントも同一ＰＣ上に複数存在する。また、別のＰＣ上に存在することも可能である。図４の例では、印刷データ変換サービス２１００、ジョブコントローラー２３００、フィルターＡ２７００、ロケーター２５００、ロガー２６００がＰＣ１  ３１００に配置されている。そして、フィルターＢ２８００がＰＣ２  ３２００に、フィルターＣ２９００がＰＣ３  ３３００に配置されている。同一コンポーネントが同一ＰＣ上に複数存在することがあるため、各コンポーネントが公開するサービスＩ／Ｆのポート番号は固定にすることができず、自ずと動的に生成せざるを得なくなる。動的に生成されたエンドポイントは何らかの管理機構が無くては他から参照することはできない。この管理を担当するのはロケーター２５００である。更に、コンポーネントが他のコンポーネントの動的に生成されたエンドポイントを取得する手段が必要である。この手段がクエリーである。クエリーに回答するのはやはりロケーター２５００の役割である。
【００２７】
（コンポーネントの生成）
コンポーネントはロケーターによって、基本的に動的に生成される。
図５は、作業ファイルの作成や参照、消去を説明する図である。
図５の（ａ）の例では、ＰＣ１  ３１００で印刷データ変換サービス２１００、ジョブコントローラー２３００、フィルターＡ２７００、ロケーター２５００、ロガー２６００が動作している。
ジョブコントローラー２３００は、ジョブを取得し、フィルターＡ２７００、フィルターＢ２８００、フィルターＣ２９００を順に用いると判断したとする。
ジョブコントローラー２３００は、フィルターＡ２７００、フィルターＢ２８００、フィルターＣ２９００のクエリーを行う。
ロケーター２５００は、クエリー要求を受け、フィルターを起動するＰＣを決定し、フィルターを起動し、クエリーの回答を行う。図５の（ａ）の例では、ロケーター２５００は、フィルターＡ２７００をＰＣ１  ３１００で起動し、フィルターＢ２８００をＰＣ２  ３２００で起動し、フィルターＣ２９００をＰＣ３  ３３００で起動すると決定する。
ジョブコントローラー２３００は、フィルターＡ２７００、フィルターＢ２８００、フィルターＣ２９００の順にパイプラインを構築し、ジョブを実行する。
ロケーター２５００がフィルターをどこで起動するかの判断は、通常は現在ジョブを実行していない、空いているＰＣを使う、若しくは各ＰＣを順番に使う等の方法を用いる。通常時のフィルターを起動するＰＣの選択方法に関しては、本明細書の処理を制限するものではない。
【００２８】
ここで、フィルターＢ２８００がクラッシュしたと仮定する。フィルターＢ２８００がＰＣ２  ３２００のＨＤＤ１００２に作業ファイル８０００を作成しながら作業を行っていた場合、クラッシュしたことにより作業ファイル８０００が残る。作業ファイル８０００とは、ジョブの実行中にフィルターが一時的に作成するファイルである。例えば、フィルターがパイプラインから入力された入力データを一旦、ＨＤＤ１００２に保存し、保存したＨＤＤ１００２上のファイルを参照しながら、変換処理を行う場合、保存したＨＤＤ１００２上のファイルが作業ファイル８０００となる。通常時は、ジョブ終了時にフィルターが作業ファイル８０００を削除するが、クラッシュした場合は作業ファイル８０００の削除が行えない。
フィルターがクラッシュすると、ジョブを管理するジョブコントローラー２３００は、クラッシュを検知する。クラッシュの検知方法は後述する。ジョブコントローラー２３００は、フィルターＢ２８００がＰＣ２  ３２００のＨＤＤ１００２に残した作業ファイル８０００を削除したいが、ＰＣが違うので、削除できない。また、フィルターＢ２８００は独自に作業ファイル８０００を作成する場合があり、ジョブコントローラー２３００は、削除すべき作業ファイル８０００を知らない場合がある。
本実施形態では、削除すべき作業ファイル８０００を知っているフィルターＢ２８００を、クラッシュした環境であるＰＣ２  ３２００で起動させる。そして、フィルターＢ２８００が作業ファイル８０００を削除する。
ここで、クラッシュとは、例えば、予期せぬエラー等により突然終了すること等をいう。
【００２９】
図５の（ｂ）の例では、ジョブコントローラー２３００は、ジョブを取得し、フィルターＡ２７００、フィルターＢ２８００、フィルターＤ８１００を用いると判断したとする。フィルターＢ２８００は前のジョブでクラッシュしており、作業ファイル８０００が残っている。ロケーター２５００は、フィルターＢ２８００を前のジョブでクラッシュしたＰＣ２  ３２００で作業ファイル８０００を削除する起動方法で起動を行う。フィルターＢは、起動後、作業ファイル８０００を削除する。フィルターの起動方法には、作業ファイル８０００を削除する起動方法と作業ファイル８０００を削除しない起動方法とがある。作業ファイル８０００を削除する起動方法のときは、フィルターは、起動時に作業ファイル８０００を削除する。作業ファイル８０００を削除する起動方法はプロセス実行時の引数や、設定ファイル、若しくは、起動直後にロケーター２５００からフィルターのサービスＩ／Ｆ５００４に削除命令を送る等の方法で指示を行う。これにより、ロケーター２５００から作業ファイル８０００の削除の指示ができるようになる。
フィルターＡ２７００、フィルターＤ８１００は前回のジョブでクラッシュしておらず、作業ファイル８０００を残していないので、どのＰＣで起動するかの制限はつかない。フィルターＡ２７００、フィルターＤ８１００は前述のように通常時のフィルターを起動するＰＣの選択方法で起動する環境が決定される。この例では、ロケーター２５００は、フィルターＡをＰＣ３  ３３００、フィルターＤ８１００をＰＣ１  ３１００で起動している。
【００３０】
図６は、実施形態１におけるジョブを実行する情報処理の一例を示すフローチャートである。
プロキシーモジュール２２００は、入力データを受け付け、入力データをジョブコントローラー２３００に送信する（Ｓ９０１）。
ジョブコントローラー２３００は、必要なフィルターを特定する（Ｓ９０２）。本実施形態では、ロケーター２５００が起動するプロセスをフィルターとして説明する。
ジョブコントローラー２３００からのクエリーを受け付けたロケーター２５００は、フィルターを起動する環境（実行環境）を特定して、フィルターを起動する（Ｓ９０３）。ここで、環境とは、ＰＣのことである。Ｓ９０３の処理の詳細は、後述する図７に示す。
その後、ジョブコントローラー２３００は、パイプラインを作成し、各フィルターを用いて、ジョブを実行する（Ｓ９０４）。
【００３１】
図７は、実施形態１におけるＳ９０３の処理の詳細を示したフローチャートである。
ロケーター２５００は、ＲＯＭ１００３若しくはＨＤＤ１００２に保存されているクラッシュリスト１１０００を取得する（Ｓ１００１）。クラッシュリスト１１０００は、一度クラッシュしたフィルターと、そのフィルターがクラッシュしたときに動作していた環境と、を保持するリストである。クラッシュリスト１１０００には、クラッシュしたフィルター名とＵＲＬとの組がリストとして保持されている。クラッシュリスト１１０００の詳細は後述する図８に示す。クラッシュリスト１１０００は、クラッシュデータの一例である。
ロケーター２５００は、クラッシュリスト１１０００に含まれるフィルターを使用するか否かを判定する（Ｓ１００２）。
ロケーター２５００は、クラッシュリスト１１０００に含まれるフィルターを使用する場合（Ｓ１００２においてＹＥＳ）、処理をＳ１００３に進める。一方、ロケーター２５００は、クラッシュリスト１１０００に含まれるフィルターを使用しない場合（Ｓ１００２においてＮＯ）、処理をＳ１００７に進める。
【００３２】
Ｓ１００３において、ロケーター２５００は、クラッシュリスト１１０００に含まれる現在のジョブで使用するフィルターをクラッシュリスト１１０００に記載されている前記フィルターと組となる環境で起動する。
フィルターは作業ファイル８０００を削除する起動方法で起動され、クラッシュしたフィルターが残した作業ファイル８０００を削除する（Ｓ１００４）。
次に、ロケーター２５００は、クラッシュリスト１１０００から今回適用したクラッシュしたフィルターとＵＲＬとの組を消去する（Ｓ１００５）。クラッシュリスト１１０００に含まれる複数のフィルターを使用する場合も、ロケーター２５００は、各フィルターに対して同様の処理を行う。
次に、ロケーター２５００は、ジョブで使用する他のプロセスを通常起動する（Ｓ１００６）。ロケーター２５００は、プロセスの通常起動においては、前述した通常時のフィルターを起動するＰＣの選択方法等を用いる。通常時のプロセスを起動する環境の選択方法に関しては、本実施形態を制限するものではない。
一方、クラッシュリスト１１０００に含まれるプロセスを使用しない場合、Ｓ１００７において、ロケーター２５００は、全プロセスを通常起動する（Ｓ１００７）。
【００３３】
図８は、クラッシュリスト１１０００の一例を示した図である。
クラッシュリスト１１０００には、クラッシュしたフィルターの名前と、クラッシュした環境であるＵＲＬと、が記載される。クラッシュしたフィルターの名前はサービスインベントリーにおける名前である。ＵＲＬはサービスインベントリーにおけるＵＲＬである。なお、サービスインベントリーとはコンポーネントごとに作成され、コンポーネントがロケーターに送信するメッセージを転記したものである。例えば、フィルターＢ２８００がＰＣ２  ３２００でクラッシュした場合、フィルターＢ２８００の名前である"／ｓｙｓｔｅｍ／ＢＦｉｌｔｅｒ"と、ＰＣ２  ３２００のＵＲＬである"ＭｙＰＣ２．ｃｏｍ"と、が組となってリストに保存される。
名前は、モジュール識別情報の一例である。また、ＵＲＬは、実行環境情報の一例である。
クラッシュリスト１１０００では、名前と、ＵＲＬと、が対応付けて記憶されている。
これにより、ロケーター２５００は、クラッシュしたフィルターとクラッシュした環境との管理ができる。ロケーター２５００は、クエリーを受け付けた際、受け付けたクエリーに係るフィルターとクラッシュリスト１１０００とを照合する。そして、ロケーター２５００は、受け付けたクエリーに係るフィルターがクラッシュリスト１１０００に記載されていれば、そのフィルターをクラッシュリスト１１０００に記載された前記フィルターと組となる環境で起動する。クラッシュした環境で起動されたフィルターは、作業ファイル８０００を消す。このことで、作業ファイル８０００を削除することができる。
【００３４】
図９は、クラッシュリスト１１０００を作成する情報処理の一例を示すフローチャートである。図６との差分を説明する。
ジョブコントローラー２３００は、フィルターのプロセスのクラッシュを検知したかの判断を行う（Ｓ１２０１）。フィルターのプロセスがクラッシュすると、パイプラインが切れることにより、ジョブコントローラー２３００は、クラッシュを検知することができる。例えば、図５の（ａ）においてフィルターＢ２８００がクラッシュしたとすると、パイプラインでつながっているフィルターＣ２９００はパイプラインが切れたことを検知する。フィルターＣ２９００は、パイプラインが切れたことを検知すると、エラー状態と判断し、ジョブコントローラー２３００のサービスＩ／Ｆ５００４にエラー通知を行う。フィルターＣ２９００は、エラー通知の情報の中に、フィルターＣ２９００の前のフィルターがクラッシュしたという情報を入れる。このことで、パイプラインを構築したジョブコントローラー２３００は、クラッシュしたフィルターを特定できる。
クラッシュしたと判断した場合、ジョブコントローラー２３００は、ロケーター２５００のサービスＩ／Ｆ５００４にクラッシュしたプロセスとクラッシュした環境との情報を含んだエラー情報を通知する。このことにより、ジョブコントローラー２３００は、クラッシュしたプロセスとクラッシュした環境との組をクラッシュリスト１１０００に追加する（Ｓ１２０２）。このようにすることにより、ジョブコントローラー２３００は、クラッシュリスト１１０００を作成、又はクラッシュリスト１１０００に情報を追記することができる。
【００３５】
＜実施形態２＞
実施形態２では、クラッシュリスト１１０００に記載されたフィルターをフィルターと組となる環境で起動する際、既に前記環境で前記フィルターが起動されていた場合の処理を説明する。前述のように、フィルターは同一ＰＣ上に複数存在する場合がある。あるフィルターがクラッシュしても、元々複数のフィルターがその環境で立ち上がっていた場合、同じフィルターがその環境上に存在する場合がある。この場合、作業ファイル８０００を削除するためにはフィルターを新たに立ち上げるのではなく、既にあるフィルターを用いたほうが効率的である。以下、主に実施形態１に対する差分を説明する。
【００３６】
図１０は、実施形態２におけるＳ９０３の処理の詳細を示したフローチャートである。
クラッシュリストに含まれるフィルターを使用すると判断した場合（Ｓ１００２においてＹＥＳ）、ロケーター２５００は、処理をＳ１３０１に進める。
Ｓ１３０１において、ロケーター２５００は、クラッシュリスト１１０００に含まれるプロセスがクラッシュリスト１１０００に記載されている前記プロセスの組となる環境で既に起動しているかを判断する。ロケーター２５００は、起動しているコンポーネントを管理する、サービスインベントリーを保持している。ロケーター２５００は、サービスインベントリーを参照することで、クラッシュリスト１１０００に含まれるプロセスがクラッシュリスト１１０００に記載されている前記プロセスと組となる環境で既に起動しているかを判断する。ロケーター２５００は、既に起動していると判断した場合（Ｓ１３０１においてＹＥＳ）、処理をＳ１００４に進め、起動していないと判断した場合（Ｓ１３０１においてＮＯ）、処理をＳ１００３に進める。
Ｓ１００３において、ロケーター２５００は、クラッシュリスト１１０００に含まれる現在のジョブで使用するフィルターをクラッシュリスト１１０００に記載されている前記フィルターと組となる環境で起動する。そして、ロケーター２５００は、前記フィルターを、作業ファイル８０００を削除する起動方法で起動し、作業ファイル８０００を削除させる（Ｓ１００４）。
【００３７】
一方、クラッシュリストに含まれるプロセスがクラッシュリストに記載されている前記プロセスと組となる環境で起動していた場合、ロケーター２５００は、フィルターに作業ファイル８０００を削除させる（Ｓ１００４）。このとき、既に起動しているフィルターは、クラッシュしたジョブ実行時に残された作業ファイル８０００のみを削除する。より具体的に説明すると、ロケーター２５００は、既に起動しているフィルターのサービスＩ／Ｆ５００４に対して、作業ファイル８０００の削除命令とクラッシュしたジョブのジョブＩＤとを送信する。このことで、既に起動しているフィルターは、クラッシュしたジョブに関する作業ファイル８０００を特定し、削除する。フィルターは、ジョブＩＤごとにフォルダを作成し、そのフォルダに該当するジョブの作業ファイル８０００を保存する。このことで、フィルターは、ロケーター２５００からクラッシュしたジョブのジョブＩＤを受け取った際に、クラッシュしたジョブに関する作業ファイル８０００を特定し、特定した作業ファイル８０００のみを削除することができる。
本実施形態により、既にクラッシュリスト１１０００に記載された組となる環境で、クラッシュリスト１１０００に記載されたフィルターが起動されていた場合は、無駄にフィルターを起動することなく、作業ファイル８０００の削除を行うことができる。
【００３８】
＜実施形態３＞
実施形態３では、フィルターのクラッシュが検知された場合、フィルターが残した作業ファイル８０００を消すためのジョブを内部で発行する場合の処理を説明する。これにより、素早く作業ファイル８０００を削除することができる。以下、主に上述した実施形態に対する差分を説明する。
図１１は、実施形態３におけるクラッシュリストを作成する情報処理の一例を示すフローチャートである。
Ｓ１２０２においてクラッシュしたフィルターをクラッシュリスト１１０００に追加した後、ロケーター２５００は、作業ファイル８０００の削除用のジョブを発行する（Ｓ１４０１）。作業ファイル８０００の削除用のジョブとは、クラッシュリスト１１０００に記載されているフィルターを用いるジョブである。
Ｓ１４０１の処理は、ジョブ発行の処理の一例である。
【００３９】
例えば、図５の（ａ）において、フィルターＢ２８００がクラッシュしたとすると、フィルターＢ２８００とその環境との組がクラッシュリスト１１０００に登録される。作業ファイル８０００の削除用のジョブは、クラッシュリスト１１０００に記載されているフィルターＢ２８００を使用するジョブである。ジョブコントローラー２３００により前記ジョブが実行されると、フィルターＢ２８００は、ロケーター２５００によりクラッシュした環境で起動され、作業ファイル８０００を削除する。作業ファイル８０００の削除用のジョブは予め作成されたものであり、各フィルターは何も処理を行わないジョブである。通常のジョブでは、ジョブコントローラー２３００がパイプラインを構成するが、作業ファイル８０００の削除用のジョブは、パイプラインを構成しなくてもよい。ジョブコントローラー２３００は、パイプラインを構成せず、フィルターを起動させた時点で、ジョブの終了と判断する。これにより、クラッシュ後すぐにクラッシュしたフィルターが残した作業ファイル８０００を削除することができるようになる。
削除用のジョブは、ダミーのジョブの一例である。
本実施形態により、クラッシュの検知直後に作業ファイル８０００の削除用のジョブを実行することができ、素早く作業ファイル８０００を削除することができる。
【００４０】
＜実施形態４＞
実施形態４では、フィルターのクラッシュが検知された場合、クラッシュしたフィルターだけでなく、クラッシュしたフィルターより前につながっていたフィルターもクラッシュリストに入れる処理を説明する。クラッシュしたフィルター以前のフィルターが正しくない出力をし、それを入力としたフィルターがクラッシュした場合、正しくない出力をした前のフィルターも正常に動作していない可能性があり、作業ファイル８０００を残す場合がある。本実施形態では、パイプライン上でクラッシュしたフィルターより前につながっていた（前段の）フィルターもクラッシュリスト１１０００に入れることで、前のフィルターが作業ファイル８０００を残していた場合も、削除が可能となる。以下、主に上述した実施形態に対する差分を説明する。
【００４１】
図１２は、実施形態４におけるクラッシュリストを作成する情報処理の一例を示すフローチャートである。プロセスをフィルターとして説明する。
クラッシュを検知した場合（Ｓ１２０１においてＹＥＳ）、ジョブコントローラー２３００は、クラッシュしたフィルター以前のフィルターとクラッシュした環境との組をリストに追加する（Ｓ１５０１）。より具体的に説明すると、ジョブコントローラー２３００は、ロケーター２５００のサービスＩ／Ｆ５００４にクラッシュしたフィルター以前のフィルターとクラッシュした環境との情報を含んだエラー情報を通知する。ロケーター２５００は、この通知に基づき、クラッシュしたフィルター以前のフィルターとクラッシュした環境との組をクラッシュリスト１１０００に追加する。
次に、ロケーター２５００は作業ファイル８０００の削除用のジョブを発行する（Ｓ１４０１）。
【００４２】
例えば、図５の（ａ）において、フィルターＢ２８００がクラッシュしたとする。すると、パイプライン上でフィルターＢ２８００以前につながっている、フィルターＡ２７００とフィルターＡが動作している環境であるＰＣ１  ３１００との組とがクラッシュリスト１１０００に登録される。また、フィルターＢ２８００とフィルターＢが動作していた環境であるＰＣ２  ３２００との組がクラッシュリスト１１０００に登録される。これにより作業ファイル８０００の削除用のジョブは、クラッシュリスト１１０００に記載されているフィルターＡ２７００とフィルターＢ２８００とを使用するジョブとなる。このジョブが実行されると、フィルターＡ２７００とフィルターＢ２８００とはロケーター２５００によりクラッシュした環境で起動され、各々作業ファイル８０００を削除する。
本実施形態により、クラッシュしたフィルターだけでなく、異常な処理をした可能性があるパイプライン上で、クラッシュしたフィルターより前につながっていたフィルターが残した作業ファイル８０００も削除することができる。
【００４３】
＜実施形態５＞
実施形態５では、フィルターのクラッシュが検知された場合、クラッシュしたフィルターだけでなく、クラッシュしたジョブに使用したフィルター全てをクラッシュリスト１１０００に入れる場合の処理を説明する。フィルターがクラッシュすることで、システムが異常状態になり、全てのフィルターで正常な処理が行えず、作業ファイル８０００を削除できない場合がある。本実施形態では、クラッシュしたジョブに使用したフィルター全てをクラッシュリスト１１０００に入れることで、全てのフィルターが作業ファイル８０００を残していた場合も、削除することができる。
【００４４】
図１３は、実施形態５におけるクラッシュリストを作成する情報処理の一例を示すフローチャートである。プロセスをフィルターとして説明する。
クラッシュを検知した場合（Ｓ１２０１においてＹＥＳ）、ジョブコントローラー２３００は、クラッシュしたジョブで使用されたフィルターとクラッシュした環境との組をリストに追加する（Ｓ１６０１）。より具体的に説明すると、ジョブコントローラー２３００は、ロケーター２５００のサービスＩ／Ｆ５００４にクラッシュしたジョブで使用されたフィルターとクラッシュした環境との情報を含んだエラー情報を通知する。ロケーター２５００は、この通知に基づき、クラッシュしたジョブで使用されたフィルターとクラッシュした環境との組をクラッシュリスト１１０００に追加する。
次に、ロケーター２５００は作業ファイル８０００の削除用のジョブを発行する（Ｓ１４０１）。
【００４５】
作業ファイル８０００の削除用のジョブとは、クラッシュリストに記載されているフィルターを用いるジョブである。例えば、図５の（ａ）において、フィルターＢ２８００がクラッシュしたとすると、同一パイプライン上に存在する、フィルターＡ２７００とフィルターＡ２７００が動作していた環境であるＰＣ１  ３１００との組がクラッシュリスト１１０００に登録される。また、フィルターＢ２８００とフィルターＢ２８００が動作していた環境であるＰＣ２  ３２００との組と、フィルターＣ２９００とフィルターＣ２９００が動作していた環境であるＰＣ３  ３３００との組がクラッシュリスト１１０００に登録される。
削除用のジョブは、クラッシュリスト１１０００に登録されているフィルターＡ２７００とフィルターＢ２８００とフィルターＣ２９００とを使用するジョブである。ジョブが実行されると、フィルターＡ２７００とフィルターＢ２８００とフィルターＣ２９００とはロケーター２５００によりクラッシュした環境で起動され、各々作業ファイル８０００を削除する。
本実施形態により、クラッシュしたフィルターだけでなく、異常な処理をした可能性がある同一パイプライン上の全てのフィルターが残した作業ファイル８０００も削除することができる。
【００４６】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００４７】
以上、上述した各実施形態によれば、Ｗｅｂサービスが冗長化されている場合でも、素早く作業ファイル（作業データ）を消去することができる。
【００４８】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2015130005.tif 000003
【図２】
2015130005.tif 000004
【図３】
2015130005.tif 000005
【図４】
2015130005.tif 000006
【図５】
2015130005.tif 000007
【図６】
2015130005.tif 000008
【図７】
2015130005.tif 000009
【図８】
2015130005.tif 000010
【図９】
2015130005.tif 000011
【図１０】
2015130005.tif 000012
【図１１】
2015130005.tif 000013
【図１２】
2015130005.tif 000014
【図１３】
2015130005.tif 000015