(57)【要約】【課題】エラー発生時に必要なログファイルを出力するとともに、各フィルタを効率的に利用可能にすること。【解決手段】複数フィルタから構成されるフィルタパイプラインを処理するサーバＰＣ１０６のジョブ制御部４０２は、フィルタの処理が正常に終了したと判定した場合（Ｓ１１０３でＹｅｓの場合）、解放するフィルタを判断し（Ｓ１１０４）、該解放するフィルタと判断したフィルタを解放する（Ｓ１１０５）。例えば、該正常に終了したと判定したフィルタの１つ前のフィルタを解放するフィルタと判断して解放する。一方、フィルタの処理が正常終了しなかったと判定した場合（Ｓ１１０３でＮｏの場合）、ログファイルを出力するフィルタを決定し（Ｓ１１０７）、該決定したフィルタに対してログファイル出力を実行させる（Ｓ１１０８）。【選択図】図１１
2015212853.tif 000002
【特許請求の範囲】
【請求項１】
複数フィルタから構成されるフィルタパイプラインを処理する情報処理装置であって、
各フィルタの処理が正常に終了したか否かを判定する判定手段と、
前記判定手段によりフィルタの処理が正常に終了したと判定された場合に、解放するフィルタを判断する解放判断手段と、
前記解放判断手段により解放するフィルタと判断されたフィルタを解放する解放手段と、
前記判定手段によりフィルタの処理が正常終了しなかったと判定された場合に、ログファイルを出力するフィルタを決定する決定手段と、
前記決定手段によりログファイルを出力するフィルタと決定されたフィルタに対してログファイル出力を実行させる出力手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記解放判断手段は、前記正常に終了したと判定されたフィルタより所定数前段で処理された未解放のフィルタを、解放するフィルタと判断することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記所定数は「１」であることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記解放判断手段は、前記正常に終了したと判定されたフィルタより前段で処理され、該フィルタと出力フォーマットが異なる未解放のフィルタを、解放するフィルタと判断することを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記決定手段は、前記正常に終了しなかったと判定されたフィルタ、及び、該フィルタより前段で処理された未解放のフィルタを、ログファイルを出力するフィルタに決定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項６】
複数フィルタから構成されるフィルタパイプラインを処理する情報処理装置の制御方法であって、
各フィルタの処理が正常に終了したか否かを判定する判定ステップと、
前記判定ステップでフィルタの処理が正常に終了したと判定された場合に、解放するフィルタを判断する解放判断ステップと、
前記解放判断ステップで解放するフィルタと判断されたフィルタを解放する解放ステップと、
前記判定ステップでフィルタの処理が正常終了しなかったと判定された場合に、ログファイルを出力するフィルタを決定する決定ステップと、
前記決定ステップでログファイルを出力すると決定されたフィルタに対してログファイル出力を実行させる出力ステップと、
を有することを特徴とする情報処理装置の制御方法。
【請求項７】
コンピュータを、請求項１乃至５のいずれか１項に記載された手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数フィルタから構成されるフィルタパイプラインによりデータを変換する情報処理装置、情報処理装置の制御方法およびプログラムに関する。
【背景技術】
【０００２】
近年、ユーザ端末（クライアント）からのリクエストに基づいてＷｅｂサービス（サーバ）が印刷データを生成し、その印刷データをプリンタが受信し、印刷を実行する「クラウドプリントサービス」と呼ばれるＷｅｂサービスが登場してきている。クラウドプリントサービスは、ユーザ端末にプリンタ制御用のデバイスドライバプログラム（プリンタドライバ）をインストールする必要がなく、また、自分の要求する印刷がどこからでも依頼できるため、今後さらなる広がりを見せると考えられる。
【０００３】
クラウドプリントサービスを実現するためには、クラウド上で、印刷対象のドキュメントデータから各種プリンタに対応する印刷データへのデータ変換が必要となってくる。そこで、ＰＣ（パーソナルコンピュータ）などのユーザ端末で使用していたようなプリンタドライバをクラウド上のサーバにそのまま配置し、利用するプリンタに対応したプリンタドライバによってデータ変換を行う方式がある。
【０００４】
しかし、複数のプリンタドライバは内部処理が共通していることが多く、共通部分について重複してクラウドに保持することになる。そのため、プリンタドライバを構成する機能を共通化（以降の説明では共通化した機能をフィルタと称す）し、共通化した機能を組み合わせてデータ変換サービスを提供する方式が登場しつつある（例えば特許文献１〜３）。特許文献１では、「モノクロプリンタ」、「解像度３００ｄｐｉ以下」といったプリンタの特徴をもとに、フィルタの並び順を決定する技術を開示している。また、特許文献２では、複数のプリンタドライバの機能をＵＩとして表示し、ユーザからどの機能を使うかの指定を受け付ける。各機能をフィルタとし、パイプラインで接続することで画像処理を行う技術を開示している。また、特許文献３は、フィルタ＆パイプラインの一部の処理を別のＰＣで実施する技術を開示している。
【０００５】
上記のようなデータ変換サービスがＷｅｂサービスとして動作する際に、なんらかの問題（データ変換に失敗するなど）が発生することがある。そのような場合に備えて、データ変換サービスはログファイル（以下、単にログと呼ぶ）を残す必要がある。このログを解析することで、何が発生したかを把握し対策を施すことができるからである。しかしながら、データ変換サービスが大量のジョブを処理する場合に、すべてのログを都度ファイル出力すると、処理速度を低下させてしまうという問題がある。
【０００６】
この問題に対する従来技術として、特許文献４が挙げられる。特許文献４は、処理実行の際に、ログをメモリ上に蓄積しておき、エラー発生時にファイル化するものである。これにより通常時はファイル化しないため処理速度の低下を抑え、エラー発生時にのみ、ログファイルを取得することができる。
【０００７】
ところで、データ変換サービスは、ジョブを実行する際に、各機能（フィルタ）を連結させ、順次処理を実行していくことで最終的な出力ファイルを取得できる。その際、データ変換サービスは、各機能（フィルタ）をそれぞれ別のプロセス（マルチプロセス）上で動作させることが可能である。また、各機能のプロセスは、処理が完了した時点（一連のジョブが終了する前）で、直ちに別のジョブのために待機することができる。つまり、各フィルタは、オンデマンドで処理を実行し、処理終了後に直ちに別のジョブのために待機状態になることが可能である。これにより、複数のジョブを効率的に処理することができるのである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１３−２５４１５号公報
【特許文献２】特開２０１３−２５４１４号公報
【特許文献３】特開２００９−５４００３号公報
【特許文献４】特開２００５−１８３６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、このようにマルチプロセス上で各フィルタが動作する場合において、ある機能（フィルタ）がエラーを起こす原因は、前段に処理を実行したフィルタに問題があった可能性がある。そのため、エラー発生時は、当該フィルタ以外のフィルタのログファイルも出力する必要がある。
【００１０】
例えば、フィルタＡ、フィルタＢ、フィルタＣの順に処理を行うシステムを想定する。このシステムにおいて、フィルタＣでエラーが発生したとする。このような場合、フィルタＣが起こしたエラーは、前段フィルタ（フィルタＡ、もしくはフィルタＢ）の処理が原因の可能性がある。具体的には以下のような場合がある。
・前段フィルタで不正な処理が行われていた（ただし前段フィルタは正常終了）
・上記が引き金となり、後段フィルタにてエラーが発生する
このような場合に備えて、エラー発生フィルタ（フィルタＣ）のログファイルだけでなく、前段フィルタ（フィルタＢ、更にはフィルタＡ）のログファイルを取得する必要がある。
【００１１】
特許文献４の技術を用いれば、処理実行の際に、各フィルタがログをメモリ上に蓄積しておき、エラー発生時にファイル化することにより、通常時はファイル化しないため処理速度の低下を抑え、エラー発生時にのみログファイルを取得することができる。
【００１２】
一方、上記フィルタＡ、フィルタＢ、フィルタＣが、別々のプロセス上で動作している場合、各フィルタのプロセスは、処理が完了した時点で（一連のジョブが終了する前に）、後処理を実施（メモリに蓄積したログを解放）し、別のジョブのために待機できる。このように、処理が完了したフィルタを、直ちに待機モードに移行し、他のジョブを受け付けることで、システム全体を効率化することができる。
【００１３】
しかしながら、前述したようにエラー発生フィルタの前段フィルタのログを取得するためには、ジョブが完了するまで、各フィルタを待機モードに移行できない（メモリ上に蓄積したログを解放しないため）。しかし、ジョブが完了するまで各フィルタを待機モードに移行しないと、フィルタ利用の効率が落ちてしまう。このように、従来では、エラー発生時に前段フィルタのログファイルを出力することと、フィルタを効率的に利用することは、両立しなかった。よって、エラー発生時に必要なログファイルを出力するとともに、フィルタを効率的に利用するシステムが求められている。
【００１４】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、エラー発生時に必要なログファイルを出力するとともに、各フィルタを効率的に利用する仕組みを提供することである。
【課題を解決するための手段】
【００１５】
本発明は、複数フィルタから構成されるフィルタパイプラインを処理する情報処理装置であって、各フィルタの処理が正常に終了したか否かを判定する判定手段と、前記判定手段によりフィルタの処理が正常に終了したと判定された場合に、解放するフィルタを判断する解放判断手段と、前記解放判断手段により解放するフィルタと判断されたフィルタを解放する解放手段と、前記判定手段によりフィルタの処理が正常終了しなかったと判定された場合に、ログファイルを出力するフィルタを決定する決定手段と、前記決定手段によりログファイルを出力するフィルタと決定されたフィルタに対してログファイル出力を実行させる出力手段と、を有することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、エラー発生時に前段フィルタのログファイルを出力する事と、処理完了後に直ちに待機モードに移行する事とを両立することができる。これにより、エラー発生時に必要なログファイルを出力するとともに、各フィルタを効率的に利用することが可能になる。
【図面の簡単な説明】
【００１７】
【図１】本発明のクラウドプリントサービスのシステム構成図
【図２】印刷データ変換サービスが動作するサーバＰＣのハードウェア構成図
【図３】サーバＰＣ上で動作するソフトウェアを説明するブロック図
【図４】印刷データ変換サービスと関連するコンポーネント群を例示する構成図
【図５】フィルタの種類および並び順を定義した設定ファイルを例示する図
【図６】フィルタパイプラインによる処理の流れを例示する図
【図７】コンポーネント間のメッセージのやりとりを例示する模式図
【図８】サービスカタログの構成を例示する模式図
【図９】サービスインベントリーの構成を例示する模式図
【図１０】クエリーの処理の流れを例示するフローチャート
【図１１】データ変換処理の流れを例示するフローチャート
【発明を実施するための形態】
【００１８】
以下、本発明を実施するための形態について図面を用いて説明する。
【実施例１】
【００１９】
図１は、本発明の一実施例を示すクラウドプリントサービスのシステム構成図である。
印刷データの変換を依頼する依頼者１０１は、印刷データの変換要求を送出する機器として、パーソナルコンピュータ１０２、タブレットＰＣ１０３や携帯端末１０４などの機器を利用する。これらの機器は、依頼者１０１からの操作を受け付け、ネットワーク１０５上に存在する印刷データ変換サービスに対して印刷データの変換を依頼する。
【００２０】
印刷データ変換サービスは、サーバＰＣ１０６上でＷｅｌｌ−ｋｎｏｗｎのＵＲＬを公開している、いわゆるＷｅｂサービスとして動作しているプログラムである。サーバＰＣ１０６は、複数フィルタから構成されるフィルタパイプラインによりデータを変換する印刷データ変換サービスを提供する情報処理装置である。また、サーバＰＣ１０６上では、前記ＵＲＬに対して到着した依頼を印刷データ変換サービスに転送するＷｅｂサーバも動作している。
【００２１】
上記ＵＲＬへ到着する依頼は、通常多数になるため、単一のサーバＰＣ１０６では処理させず、複数のサーバＰＣ１０６に処理させる構成とする。従って、複数のサーバＰＣ１０６の前段にロードバランサー１０７を設置し、サーバＰＣ１０６それぞれに転送される依頼が均一に配分されるように構成する。
【００２２】
印刷データ変換サービスが提供するサービスは、依頼者１０１から受け付けたデータをプリンタ１０８で印刷できる形式に変換することである。依頼者１０１から受け付けるデータには、ドキュメント、画像ファイルなど各種のアプリケーションプログラムで作成されたフォーマットが存在する。一方、プリンタ１０８が印刷データとして受け付けるデータは、前述のフォーマットとは異なり、ＰＤＬ（Page Description Language)で記述されたデータや、印刷部数等の印刷を制御するためのデータとなっている。このように、依頼者１０１とプリンタ１０８の間には扱うデータ形式の差異が存在するために、その差異を埋めるプログラムが必要とされる。通常、この変換処理を行うのがプリンタドライバと呼ばれるプログラムである。プリンタドライバは、依頼者１０１が操作する前述のアプリケーションプログラムが動作しているＰＣ上で動作させることが通常である。
【００２３】
しかし、プリンタドライバの処理は比較的ＣＰＵ、メモリなどのリソースを必要とする重い処理であるため、特に依頼者１０１の操作するＰＣの保持するリソースが少ない場合には、ＰＣに大きな負荷がかかってしまう。タブレットＰＣ１０３や携帯端末１０４といった、リソースの比較的少ない端末からの印刷の需要が高まるにつれ、プリンタドライバの処理をインターネット上のサービスで行わせることの重要性が増している。
【００２４】
前述のパーソナルコンピュータ１０２、タブレットＰＣ１０３、携帯端末１０４は、依頼者１０１からの指示を受け付け、前述のＵＲＬに対して印刷データをプリンタ１０８で印刷できる形式に変換するように依頼を行う。この依頼に応じて、サーバＰＣ１０６上で動作している印刷データ変換サービスがデータ変換を行い、該変換後のデータが前述の端末に対して返送される。依頼者１０１から受け付ける指示によっては、変換後のデータは、印刷データ変換サービスがアクセス可能なファイルサーバＰＣ１０９で保管される場合もある。
【００２５】
＜ハードウェア構成＞
図２は、印刷データ変換サービスをはじめとするソフトウェア群が動作するサーバＰＣ１０６のハードウェア構成を例示する図である。
【００２６】
印刷データ変換サービスは、ＯＳ（オペレーティングシステム）上で動作するアプリケーションプログラムであり、ＨＤＤ（ハードディスクドライブ）２０２あるいはＲＯＭ２０３に格納されている。ＣＰＵ２０５がＯＳとアプリケーションプログラムをＨＤＤ２０２あるいはＲＯＭ２０３から読み出してＲＡＭ２０４にロードし、実行することで様々な処理が進行し印刷データ変換サービスとしての機能を実現する。
【００２７】
印刷データ変換サービスの処理結果はファイルとしてＨＤＤ２０２に格納され、あるいはデータとしてＲＡＭ２０４に記憶される。アプリケーションプログラムは、コンピュータに接続されている入力装置２０７から使用者の入力、各種センサの読み取り値を取得する。さらに、出力装置２０６に対して情報を出力し、処理結果を表示する。さらに、通信装置２０８を介してネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウェアは、バス２０１で互いに接続されていてアプリケーションプログラムから操作できるように構成されている。
【００２８】
なお、図２はサーバＰＣ１０６の代表的なハードウェア構成であり、サーバＰＣ１０６は、この構成に限定されるものではない。
【００２９】
＜ソフトウェア構成＞
図３は、印刷データ変換サービス３０１を含むソフトウェア群のサーバＰＣ１０６上での構成を例示するブロック図である。
【００３０】
Ｗｅｂサーバ３０２は、依頼者１０１が操作したパーソナルコンピュータ１０２上のアプリケーションからＨＴＴＰプロトコルで送信されたリクエストを受け取る。ロードバランサー１０７は、Ｗｅｂサーバ３０２の前段に位置し、複数のサーバＰＣ１０６上で動作しているＷｅｂサーバ３０２に振り分ける。この振り分け方式は種々知られており、その詳細は公知であるため説明を省略する。
【００３１】
ここで、サーバＰＣ１０６は、必ずしも物理的な一台のサーバＰＣを意味する必要はない。現時点で単一のＰＣ上に複数の仮想的なＰＣを出現させる仮想化技術が一般的となっており、ソフトウェアからみれば自身が動作しているオペレーティングシステムが仮想的に作り出されたものか否かは判別がつかないか、あるいは判別する必要がない。従って、本実施例のサーバＰＣ１０６は、「場合によっては仮想化されたＰＣ」を意味する場合もある。これ以降、「ＰＣ」という表現は物理的なＰＣと仮想化されたＰＣの両方を意味するものとして扱う。
【００３２】
アプリケーションサーバ３０３は、要求の送付先として指定されたＵＲＬを解析し、関連つけられている印刷データ変換サービス３０１を決定する。通常、Ｗｅｂサーバ３０２とアプリケーションサーバ３０３は、複数種のサービスを扱うことが可能であり、ＵＲＬから対応するサービスを特定して要求を振り分けることができる。本実施例では、その複数種のサービスの一つが、印刷データ変換サービス３０１であることを想定している。サーバＰＣ１０６上では、このサービスの他にもサービスが稼働しているが、印刷データ変換サービス３０１以外のサービスの説明は省略する。
【００３３】
印刷データ変換サービス３０１は、プロセスとして動作する。アプリケーションサーバ３０３は、複数の要求を並列実行させるために、印刷データ変換サービス３０１を複数起動し、各々に要求を振り分ける。アプリケーションサーバ３０３はさらに、印刷データ変換サービス３０１が動作する際に依頼者１０１からの一連の要求を特定するためのセッションを管理する。具体的には、アプリケーションサーバ３０３は、同一の依頼者１０１からの要求は同一の印刷データ変換サービス３０１に転送するセッション・アフィニティーを実現している。
【００３４】
なお、Ｗｅｂサーバ３０２、アプリケーションサーバ３０３、印刷データ変換サービス３０１は、各サーバＰＣ１０６のＣＰＵ２０５が、ＨＤＤ２０２等に格納されたプログラムを読み出して実行することで実現されるものである。
【００３５】
＜印刷データ変換サービス＞
図４は、印刷データ変換サービス３０１が依頼された印刷データを変換する際に利用するソフトウェアコンポーネント群の関連を説明する図である。なお、以下では、プロセスとして起動したコンポーネントのことを「コンポーネントプロセス」と記載する。なお、図４に示す構成は、各サーバＰＣ１０６のＣＰＵ２０５が、ＨＤＤ２０２等に格納されたプログラムを読み出して実行することで実現されるものである。
【００３６】
印刷データ変換サービス３０１は、先に説明したようにプロセスとして動作しており、変換処理をジョブ制御部４０２に委譲している。印刷データ変換サービス３０１は、ジョブ制御部４０２の代理としてのジョブ処理受け付け部４０１をロードしている。さらに、そのジョブ処理受け付け部４０１がＡＰＩ（Application Programming Interface）で提供している関数群を呼び出すことで変換処理の実行を依頼し、該変換処理の結果を受領する。
【００３７】
変換処理の実行の際に、印刷データ変換サービスは、ジョブ処理受け付け部４０１に対して処理対象のデータ一式を渡す。この処理対象のデータ一式をジョブと呼ぶ。ジョブは、変換されるべき対象データと、変換処理用の設定値などを、まとまりのある形式に束ねた「チケット」と呼ばれるデータ構造から構成される。
【００３８】
なお、ジョブ制御部４０２もまたプロセスとして動作しており、変換処理の受付のための通信インターフェイスを保持している。この通信インターフェイスへのジョブの依頼はＨＴＴＰプロトコルではなく、専用のプロトコルが用いられている。ジョブ処理受け付け部４０１のＡＰＩを呼び出す行為は、ジョブ制御部４０２が用意している変換処理受付用通信インターフェイスへのプロセス間通信として変換される。すなわち、印刷データ変換サービス３０１から見ると、変換処理は、ジョブ処理受け付け部４０１によって実行されているように見える。しかし実際には、変換処理は、ジョブ制御部４０２および後述する複数のフィルタ群、およびフィルタ群が利用するいくつかのコンポーネントの相互作用によって実現されている。
【００３９】
以下、図４に示すコンポーネントそれぞれの機能について説明し、続けて図６を用いてデータ変換処理の概要を説明する。
【００４０】
＜プロセス情報管理部＞
プロセス情報管理部４０３は、アプリケーションサーバ３０３が起動した時点で唯一起動している特殊なプロセスである。アプリケーションサーバ３０３上で動作しているオペレーティングシステム（ＯＳ）への設定により、ＯＳ起動時に自動的にプロセス情報管理部４０３のプロセスを起動するようになっている。
【００４１】
プロセス情報管理部４０３は、コンポーネントをプロセスとして起動する責務を担っている。さらに、プロセス情報管理部４０３は、他のコンポーネントからの求めに応じて別のコンポーネントのエンドポイントを返すという機能を提供する。エンドポイントとは、ＴＣＰ／ＩＰのリスンポートを指す。あるコンポーネントは、別のコンポーネントが公開しているエンドポイントを取得し、そのエンドポイントにアクセスすることで、そのコンポーネントが提供する機能を利用する。あるコンポーネントが他のコンポーネントのエンドポイントをプロセス情報管理部４０３に対して問い合わせる動作を"クエリー"と呼ぶこととする。
【００４２】
印刷データ変換サービス３０１を構成するコンポーネントのうち、ジョブ処理受け付け部４０１、ジョブ制御部４０２、フィルタ制御部４０４は、ログ出力部４０８が提供しているロギングデータをログファイルとして記録するサービスを利用することができる。そのため、ジョブ処理受け付け部４０１、ジョブ制御部４０２、フィルタ制御部４０４は、プロセス情報管理部４０３に対してログ出力部４０８のエンドポイントを得る目的でクエリーを行っている。
【００４３】
同様に、ジョブ処理受け付け部４０１は、ジョブ制御部４０２についてクエリーし、ジョブ制御部４０２は、フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７についてクエリーする。クエリーの処理の流れは、図７、図１０を用いて後述する。
【００４４】
＜クエリーの意義＞
コンポーネントが提供しているサービスは、ネットワークからアクセスできるエンドポイントとして、他のコンポーネントに公開される。具体的には、ＴＣＰ／ＩＰのアドレスとポート番号の組が、エンドポイントとして公開される。コンポーネントは、他のコンポーネントの提供するサービスＩ／Ｆを取得して利用する。複数種類のコンポーネントがプロセスとして複数存在し、かつ同一コンポーネントも同一ＰＣ上に複数存在する。従って、各コンポーネントが公開するサービスＩ／Ｆのポート番号は固定にすることができず、自ずと動的に生成せざるを得なくなる。動的に生成されたエンドポイントは、何らかの管理機構が無くては他から参照することはできない。この管理を担当するのがプロセス情報管理部４０３である。さらに、コンポーネントが、他のコンポーネントが動的に生成したエンドポイントを取得する手段が必要である。この手段がクエリーである。プロセス情報管理部４０３は、他コンポーネントからのクエリーに対して、要求されたコンポーネントのエンドポイントを回答する。
【００４５】
＜ジョブ制御部＞
ジョブ処理受け付け部４０１を介してジョブ実行を依頼されたジョブ制御部４０２は、ジョブに含まれている「ジョブ種別情報」をもとに、変換に必要なフィルタを選定する。必要なフィルタの組み合わせとその並び順は、例えば図５のような設定ファイルとしてジョブ制御部４０２で保持される。
【００４６】
図５は、必要なフィルタの組み合わせとその並び順を記載するための設定ファイルを例示する図である。
【００４７】
要素５０１は、ジョブ種別情報を記載するための要素である。要素５０１では、ｉｄ属性でジョブ種別情報を指定する。要素群５０２は、フィルタの組み合わせと並び順を記載するための要素である。要素５０２では、ｎａｍｅ属性でフィルタの種類を記載し、ｖｅｒｓｉｏｎ属性でどのバージョンのフィルタを使うのかを記載する。
【００４８】
要素群５０２は、要素の記載順でフィルタの並び順を規定する。要素群５０２の例では、ＦｉｌｔｅｒＡ、ＦｉｌｔｅｒＢ、ＦｉｌｔｅｒＣの順で処理が行われる。ジョブ制御部４０２は、ジョブに含まれているジョブ種別情報と一致する要素５０１を探索し、一致する要素５０１の下に書かれているフィルタの組み合わせと並び順を採用する。
【００４９】
また、要素群５０２には、各フィルタが処理可能な入力ファイルフォーマット及び、出力ファイルフォーマットが記載されている。例えば、図５（ａ）の５０２では、ＦｉｌｔｅｒＡが処理可能な入力ファイルフィーマットは、「ｊｐｇ」であり、出力ファイルフォーマットは「ｊｐｇ」であることを示している。また、ＦｉｌｔｅｒＢが処理可能な入力ファイルフィーマットは、「ｊｐｇ」であり、出力ファイルフォーマットは「ｐｄｆ」であることを示している。さらに、ＦｉｌｔｅｒＣが処理可能な入力ファイルフィーマットは、「ｐｄｆ」であり、出力ファイルフォーマットは「ｐｄｌ」であることを示している。「ｊｐｇ」はＪＰＥＧ形式を示し、「ｐｄｆ」はＰＤＦ（Portable Document Format）形式を示す。なお、パイプライン処理において、前段フィルタの出力ファイルフォーマットは、次フィルタが処理可能なファイルフォーマットである必要がある。
【００５０】
なお、必要なフィルタの組み合わせとその並び順は、ジョブ種別情報の代わりに、印刷データを解析して決定するようにしてもよい。その場合、印刷データの先頭から既定のサイズを読出し、その中に含まれている特徴的な内容から、印刷データの種類を判定する。例えば、ＪＰＥＧ形式や、ＰＤＦ形式のデータなどが入力データとしてジョブ制御部４０２に与えられる。ジョブ制御部４０２は、ジョブに含まれている変換先の印刷データ形式を取得し、変換元の印刷データ形式と変換先の印刷データ形式の両者が確定した時点で、この変換に必要なフィルタ群を選定する。
【００５１】
必要な複数のフィルタを選定したあとは、ジョブ制御部４０２は、これらフィルタをロードしているフィルタ制御部４０４を取得する。図４の例では、変換に必要なフィルタとして、フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７が選定され、それらがそれぞれフィルタ制御部４０４にロードされている。
【００５２】
ジョブ制御部４０２は、フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７との間で、パイプライン４０９と呼ばれるデータ転送チャネルを作成する。プロトコルとしては、例えばＴＣＰ／ＩＰを用いる。パイプライン４０９は、基本的に片方向にのみデータを転送する。この例では、ジョブ制御部４０２、フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７、ジョブ制御部４０２と一周するようにパイプライン４０９が構成される。また、ジョブ制御部４０２は、ジョブ処理受け付け部４０１との間にもパイプライン４０９を作成する。このようにパイプライン４０９を作成することで、ジョブ処理受け付け部４０１から印刷データが複数のコンポーネントを還流し、最後に変換が終了した形で再びジョブ処理受け付け部４０１に戻ってくる。
【００５３】
＜フィルタ、フィルタ制御部＞
フィルタは、データ変換処理のみを実装したライブラリーモジュールの形式で用意されている。フィルタ制御部４０４は、プロセスとして存在し、実行時に指定されたフィルタをロードする。フィルタ制御部４０４は、コントロールバス４１０への接続と、メッセージ送受信、ジョブ制御部４０２との通信、フィルタのログ出力のログ出力部４０８への転送などの処理を担当する。
【００５４】
＜ローカルログ出力部、ログ出力部＞
ローカルログ出力部４１１は、フィルタ制御部４０４のプロセス内にて動作することが可能である。各フィルタは、ログデータをローカルログ出力部４１１に対してＡＰＩを介して受け渡し、ローカルログ出力部４１１は、ログデータをメモリ上に蓄積しておく。そして、ローカルログ出力部４１１は、フィルタ制御部４０４から「ログファイル出力指示」を受け付けた時点で、メモリ上に蓄積してあるログデータをログファイルに出力する。
【００５５】
なお、ログデータをメモリ上に蓄積することなく逐次ログファイルに出力することも可能であるが、本実施例においては説明しない。また、ログファイルの出力パス等の設定は、ローカルログ出力部４１１が起動される際に渡されるコンフィギュレーションファイルで指定される。
【００５６】
ログ出力部４０８は、プロセスとしてコントロールバス４１０上に最低一つは存在する。各コンポーネントは、ログデータをログ出力部４０８に対してネットワークを介して送信し、ログ出力部４０８は、一定量のログデータが蓄積した時点でログデータをログファイルに出力する。なお、ログ出力部４０８は、ログデータを蓄積せずに逐次ログファイルに出力するようにしてもよい。ログファイルの出力パス等の設定は、ログ出力部４０８が起動される際に渡されるコンフィギュレーションファイルで指定される。
【００５７】
以下、ログ出力部４０８と、先に示したローカルログ出力部４１１との関係について述べる。フィルタ制御部４０４は、ローカルログ出力部４１１、あるいは、ログ出力部４０８のいずれか、または両方に対してログを出力することが可能である。しかし、本実施例では、フィルタ制御部４０４は、ログ出力部４０８への出力機能は使わず、ローカルログ出力部４１１への出力機能を使うこととして説明する。
【００５８】
＜データ変換処理の概要＞
図６は、ジョブ処理受け付け部４０１が印刷データ変換サービス３０１からジョブ処理を受け付けた後のデータ変換処理の概要を示す図である。図６に示す処理は、サーバＰＣ１０６のＣＰＵ２０５が、ＨＤＤ２０２等に格納されたプログラムを読み出して実行することで実現されるものである。
【００５９】
ジョブ処理受け付け部４０１は、印刷データ変換サービス３０１からジョブ処理を受け付けると、Ｓ６０１の処理を実行する。Ｓ６０１は、ジョブ処理受け付け部４０１が、ジョブ制御部４０２のクエリー要求を行う処理である。ジョブ処理受け付け部４０１は、プロセス情報管理部４０３にクエリー要求を行い、ジョブ制御部４０２のエンドポイントを取得する。なお、クエリーの処理の流れは図７、図１０を用いて後述する。
【００６０】
次に、Ｓ６０２において、ジョブ処理受け付け部４０１は、ジョブ制御部４０２に対してジョブ処理依頼を行う。この処理で、ジョブのデータが、ジョブ処理受け付け部４０１からジョブ制御部４０２に渡される。受け渡しには、ジョブのデータのパスで渡すようにしてもよいし、メモリやプロセス間通信で渡すようにしてもよい。上記ジョブ処理依頼を受けて、ジョブ制御部４０２は、Ｓ６０３の処理を行う。
【００６１】
Ｓ６０３は、ジョブ制御部４０２が、ジョブの内容をもとに、フィルタの種類、並び順を決定し、それらフィルタのクエリー要求を行う処理である。フィルタの種類、並び順に関しては、図５（ａ）、図５（ｂ）を用いて説明済みである。ジョブ制御部４０２は、プロセス情報管理部４０３に対して、各フィルタに対応するフィルタ制御部４０４についてのクエリー要求を行い、それぞれのエンドポイントを取得する。ここでは、フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７の順に処理を行うと決定したものとして説明をする。
【００６２】
Ｓ６０４は、パイプラインを生成する処理である。ジョブ制御部４０２は、各フィルタ制御部４０４に対して、パイプラインの生成を指示する。この指示を受けて、各フィルタ制御部４０４は、それぞれ隣り合うコンポーネントプロセスとのパイプラインを生成する。各フィルタ制御部４０４は、入力パイプラインからジョブが流れてくるのを待機し、ジョブ制御部４０２にパイプライン生成完了を通知する。
【００６３】
ジョブ制御部４０２は、各フィルタ制御部４０４に対してパイプラインの生成を指示する際に、ジョブ制御部４０２のサービスＩＦのエンドポイントも各フィルタ制御部４０４に通知する。フィルタ制御部４０４は、エラーが起こった際に、このジョブ制御部４０２のサービスＩＦを通じて、ジョブ制御部４０２にエラーを通知する。
【００６４】
Ｓ６０５は、データ変換処理である。ジョブ制御部４０２は、初段のフィルタ制御部４０４に接続されているパイプラインにデータを流す。フィルタＡ４０５は、フィルタ制御部４０４を通じてデータを受け取り、データ変換処理を行う。そして、フィルタＡ４０５は、フィルタ制御部４０４を通じて、フィルタＢ４０６と接続されているパイプラインにデータを流す。フィルタＢ４０６、フィルタＣ４０７でも同様にデータ変換処理が行われる。そして最終的に、フィルタＣ４０７から、フィルタ制御部４０４を通じて、ジョブ制御部４０２に変換後のデータが送信される。なお、各フィルタは、処理終了後、処理結果（正常終了、エラーが発生等）を、フィルタ制御部４０４を通じて、ジョブ制御部４０２へ通知する。Ｓ６０５の詳細については後述する。
【００６５】
Ｓ６０６は、ジョブ制御部４０２が、ジョブ処理受け付け部４０１に対して変換後のデータを返却する処理である。
【００６６】
＜コンポーネントの生成＞
以下、図７を参照して、コンポーネントの生成について説明する。
図７は、コンポーネントをプロセスとして生成するシーケンスを説明する図である。
【００６７】
図７（１）では、プロセス情報管理部４０３のみが存在する状況である。この状況は、図３においてサーバＰＣ１０６が起動した直後に相当する。この時点では、まだ印刷データ変換サービス３０１は起動していない想定である。プロセス情報管理部４０３は、単独でコントロールバス４１０に参加している状態である。
【００６８】
プロセス情報管理部４０３は、サービスカタログ７０１を保持している。サービスカタログ７０１は、例えば、サーバＰＣ１０６のＨＤＤ２０２にファイルとして保存され、プロセス情報管理部４０３によって読み込まれる。サービスカタログ７０１は、例えば図８に示すように、サーバＰＣ１０６上にインストールされているコンポーネントのリストから構成されている。
【００６９】
図８は、サービスカタログの概念を示す図である。
図８において、エントリー８０１は、サービスカタログのエントリーであり、コンポーネントごとに存在する。コンポーネント名８０２は、当該エントリー８０１のコンポーネント名である。サービスのバージョン８０３は、コンポーネントのバージョンを示す。なお、同一のコンポーネント名を持つコンポーネントであっても、そのバージョンが異なれば異なる機能を提供するため、サービスカタログ７０１上では、異なるエントリーとして扱われる。
【００７０】
ホスティングプロセスパス８０４は、コンポーネントのホスティングプロセスパスを示す。実行ファイルパス８０５は、ホスティングプロセスパス８０４がロードする実行ファイルパスを示す。コンフィギュレーションファイルパス８０６は、コンポーネントをプロセスとして起動したときに、プロセス情報管理部４０３からそのコンポーネントに渡されるコンフィギュレーションファイルのパスである。
【００７１】
起動モード８０７は、コンポーネントプロセスが、オンデマンドで起動するかホットスタンバイさせておくかを示す。起動モード８０７が「Ｏｎｄｅｍａｎｄ」の場合は、そのコンポーネントを指定したコンポーネントのクエリーがあった場合に当該コンポーネントプロセスを起動する。また、起動モード８０７が「ＨｏｔＳｔａｎｄｂｙ」の場合は、プロセス情報管理部４０３が起動する際に当該コンポーネントプロセスを起動する。
【００７２】
図８に示した例は、「フィルタＡ４０５」をロードするフィルタ制御部４０４、即ち、図４で説明したフィルタＡ４０５をロードしたフィルタ制御部４０４のカタログを指す。
【００７３】
図７（２）では、あるコンポーネントＡ７０２の起動モードがホットスタンバイ（ＨｏｔＳｔａｎｄｂｙ）に指定されているとした場合の例を示している。プロセス情報管理部４０３は、自身が起動したら、このサービスカタログ７０１を参照し、起動モードがホットスタンバイに指定されているコンポーネントＡ７０２を発見する。次に、プロセス情報管理部４０３は、サービスカタログ７０１からコンフィギュレーションファイルパス８０６を、起動引数に与えてコンポーネントＡ７０２をプロセスとして起動する。コンポーネントＡ７０２は起動し、コントロールバス４１０に接続する時点でユニークなＩＤを与えられる。このＩＤとしては、例えばＧＵＩＤを用いる。コンポーネントＡ７０２は、コンフィギュレーションファイルパス８０６からコンフィギュレーションファイル７０３を参照し、必要な初期値等を取り出し、その初期値を使って自身を初期化する。
【００７４】
図７（３）では、コンポーネントＡ７０２は、サービスを提供するために、ＴＣＰ／ＩＰのポートを取得し、サービスＩ／Ｆ７０４の待ち受けを開始する。コンポーネントＡ７０２は、これで他のコンポーネントへのサービスの提供の準備ができたため、コントロールバス４１０に自身のアドバタイズメッセージ７０５を作成して送信する。アドバタイズメッセージ７０５には、コンポーネントＡ７０２の名前、ＩＤ、バージョン、サービスＩ／Ｆ７０４のエンドポイント（アドレス、ポート番号）が記載されている。このアドバタイズメッセージ７０５は、プロセス情報管理部４０３宛てに送信される。アドバタイズメッセージ７０５は、コンポーネントが自身の起動完了とサービス提供開始を宣言する行為である。このアドバタイズメッセージ７０５の受信によって、プロセス情報管理部４０３は、コンポーネントＡ７０２の起動を確認し、かつサービスＩ／Ｆのエンドポイントを取得することができる。
【００７５】
図７（４）は、プロセス情報管理部４０３がコンポーネントＡ７０２からのアドバタイズメッセージ７０５を受信し、以降の管理のために管理テーブルであるサービスインベントリー７０６に登録を行った様子を表している。
【００７６】
図９は、サービスインベントリー７０６の内容を模式的に表す図である。
エントリー９０１は、サービスインベントリー７０６のエントリーである。コンポーネントプロセスごとのエントリー９０１が存在する。プロセス情報管理部４０３は、アドバタイズメッセージ７０５を受け取った時点で、サービスインベントリー７０６内にそのメッセージの送信元であるコンポーネントプロセスのエントリー９０１を作成する。そして、プロセス情報管理部４０３は、そのエントリー９０１内にメッセージの内容を記載する。具体的には、ＩＤ９０２、名前９０３、バージョン９０４、エンドポイント９０５に記載される。
【００７７】
状態９０６には、プロセス情報管理部４０３が後述するステートチェンジメッセージを受け取った際に、コンポーネントプロセスの状態を記録する。状態９０６は、「アイドリング」、「ビジー」という値を取り得る。「アイドリング」は、当該コンポーネントプロセスが処理受け付け可能な状態である。「ビジー」は当該コンポーネントプロセスが処理受け付け不可能な状態である。各コンポーネントプロセスが起動する際には「アイドリング」状態で起動する。
【００７８】
コンポーネントＡ７０２は、「アイドリング」状態で起動したら、自身をクエリーで検出されるようにするため、図７（５）に示すように、ステートチェンジメッセージ７０７をプロセス情報管理部４０３に対して送信する。ステートチェンジメッセージ７０７には、コンポーネントＡ７０２がアイドリング状態に遷移したことが記されている。このステートチェンジメッセージ７０７を受け取ったプロセス情報管理部４０３は、サービスインベントリー７０６のコンポーネントＡ７０２のエントリーを検索し、その状態９０６を、受け取った状態「アイドリング」状態に変更する。
なお、「ビジー」状態に関しては図７（８）で後述する。
【００７９】
図７（６）は、コンポーネントＡ７０２がコンポーネントＢ７０９を利用しようとして、プロセス情報管理部４０３に対して、クエリーメッセージ７０８を送信した様子を示している。このクエリーメッセージ７０８には、コンポーネントＢ７０９の名前と利用したいバージョンが記されている。あるコンポーネントは、複数のバージョンが作成され得る。同一の名前のコンポーネントが機能の違いにより複数作成されて異なるバージョンとして市場にリリースされる。従って、コンポーネントＡ７０２は、バージョン"2.0.0.1"の様に自分が利用したいコンポーネントＢ７０９のバージョンを指定してクエリーを行うことができる。もし、特定バージョンを利用する必要が無いならば、バージョン欄は空で指定する。
【００８０】
図７（６）の時点では、コンポーネントＢ７０９はまだ生成されていないため、プロセス情報管理部４０３は、クエリーメッセージ７０８に基づいて、コンポーネントＢ７０９を新たに生成する。図７（２）〜（４）で示したコンポーネントＡ７０２の生成手順と同様にコンポーネントＢ７０９が生成される。なお、プロセス情報管理部４０３におけるクエリーの処理の詳細は図１０を用いて後述する。
【００８１】
図７（７）は、プロセス情報管理部４０３がクエリーに対するレスポンスをコンポーネントＡ７０２にクエリーレスポンスメッセージ７１０として返却する様子を示している。クエリーレスポンスメッセージ７１０には、コンポーネントＢ７０９の名前、バージョン、サービスＩ／Ｆを示すエンドポイントが格納されている。
【００８２】
図７（８）は、クエリーレスポンスメッセージ７１０を受け取ったコンポーネントＡ７０２が、取得したコンポーネントＢ７０９のサービスＩ／Ｆ７１１を利用する様子を示している。コンポーネントによっては、サービスＩ／Ｆにアクセスして来る他のサービスからのサービス要求を同時に扱えるものと、そうでないものが存在する。例えば、ログ出力部４０８は、複数のサービスからのロギングデータを同時並行的に受け取り、ログファイルに記録していく能力を有する。一方、パイプラインを構成してジョブを変換するフィルタは、同時並行処理の能力をもたない。従って、コンポーネントＢ７０９が同時並行処理能力を持たないコンポーネントであるとすると、コンポーネントＡ７０２がアクセスしてきた時点で他のコンポーネントからの要求を受け付けられない状態、すなわちビジー状態に遷移する。この状態は、コンポーネントＡ７０２が明示的なアクセス終了をサービスＩ／Ｆを通じてコンポーネントＢ７０９に宣言するまで継続する。
【００８３】
コンポーネントＢ７０９は、ビジー状態に遷移したら、自身をクエリーで検出されないようにするため、図７（９）に示すように、ステートチェンジメッセージ７１２をプロセス情報管理部４０３に対して送信する。ステートチェンジメッセージ７１２には、コンポーネントＢ７０９がビジー状態に遷移したことが記されている。このステートチェンジメッセージ７１２を受け取ったプロセス情報管理部４０３は、サービスインベントリー７０６のコンポーネントＢ７０９のエントリーを検索し、その状態９０６を、受け取った状態「ビジー」状態に変更する。
【００８４】
コンポーネントＢ７０９の状態９０６が「ビジー」状態に変更になったため、プロセス情報管理部４０３は、以降、名前を指定したクエリーを受け取っても、そのコンポーネントＢ７０９のプロセスを選定することはなくなる。ただし、サービスインベントリー７０６には他のコンポーネントＢのプロセスが複数存在している可能性がある。それらのいずれかがビジー状態でなければ、「利用可能なコンポーネントＢ」としてクエリーの発行元のコンポーネントに返却される。複数の同一名とバージョンを持ったコンポーネントプロセス群からどのプロセスをクエリーの結果として選択するのかに関しては、例えば、最初に発見したプロセスを返却するようにする。もしくは、コンポーネントプロセスごとに、クエリー発行元のコンポーネントに返却された回数をカウントしておき、最もカウントの低いプロセスを返却するようにしてもよい。
【００８５】
コンポーネントＢ７０９は、アイドリング状態に遷移したら、自身をクエリーで検出されるようにするため、図７（１０）に示すように、ステートチェンジメッセージ７１３をプロセス情報管理部４０３に対して送信する。ステートチェンジメッセージ７１３には、コンポーネントＢ７０９がアイドリング状態に遷移したことが記されている。このステートチェンジメッセージ７１３を受け取ったプロセス情報管理部４０３は、サービスインベントリー７０６のコンポーネントＢ７０９のエントリーを検索し、その状態９０６を、受け取った状態「アイドリング」状態に変更する。
＜クエリーの処理詳細＞
図１０は、プロセス情報管理部４０３により実行されるクエリーの処理詳細を例示するフローチャートである。即ち、図１０に示す処理は、サーバＰＣ１０６のＣＰＵ２０５が、ＨＤＤ２０２等に格納されたプログラムを読み出して実行することで実現されるものである。
【００８６】
Ｓ１００１において、プロセス情報管理部４０３は、他のコンポーネントからクエリー要求を受け付ける。クエリーには、コンポーネントの名前と利用したいバージョンが含まれている。プロセス情報管理部４０３は、クエリー要求を受け付けると、Ｓ１００２に処理を進める。
【００８７】
Ｓ１００２では、プロセス情報管理部４０３は、サービスカタログ７０１を探索し、前記Ｓ１００１で受け付けたコンポーネント名とバージョンに対応するエントリー８０１が存在するか否かを判定する。そして、サービスカタログ７０１に対応するエントリー８０１が存在すると判定した場合（Ｓ１００２でＹｅｓの場合）、プロセス情報管理部４０３は、Ｓ１００３に処理を進める。一方、サービスカタログ７０１に対応するエントリー８０１が存在しないと判定した場合（Ｓ１００２でＮｏの場合）、プロセス情報管理部４０３は、Ｓ１００７に処理を進める。
【００８８】
Ｓ１００３では、プロセス情報管理部４０３は、ジョブ受け付け可能なコンポーネントプロセスが存在するか否かを判定する。プロセス情報管理部４０３は、サービスインベントリー７０６を探索し、前記Ｓ１００１で受け付けたコンポーネント名とバージョンに対応するエントリー９０１を探索する。そして、状態９０６が「アイドリング」のコンポーネントプロセスが１つ以上存在するか否かを判定する。
【００８９】
状態９０６が「アイドリング」のコンポーネントプロセスが１つ以上存在する場合には、ジョブ受け付け可能なコンポーネントが存在すると判定し（Ｓ１００３でＹｅｓと判定し）、プロセス情報管理部４０３は、Ｓ１００４に処理を進める。一方、状態９０６が「アイドリング」のコンポーネントプロセスが１つも存在しない場合には、ジョブ受け付け可能なコンポーネントが存在しないと判定し（Ｓ１００３でＮｏと判定し）、プロセス情報管理部４０３は、Ｓ１００５に処理を進める。
【００９０】
Ｓ１００４では、プロセス情報管理部４０３は、クエリー要求元に要求のあったコンポーネントプロセスのエンドポイントとして、前記Ｓ１００３で見つけたコンポーネントプロセスのうち１つをクエリー要求元にエンドポイントを通知する。なお、エンドポイント通知するコンポーネントプロセスは、一番初めに見つけたコンポーネントプロセスとしてもよいし、コンポーネントプロセスごとに、何回クエリー要求元にエンドポイントを返したかを、サービスインベントリー７０６に記憶しておき、最も回数の少ないコンポーネントプロセスのエンドポイントを通知するようにしてもよい。
【００９１】
また、Ｓ１００５では、プロセス情報管理部４０３は、クエリー要求のあったコンポーネントをプロセスとして起動する。次に、Ｓ１００６では、プロセス情報管理部４０３が、前記Ｓ１００５で起動したコンポーネントプロセスからアドバタイズメッセージ７０５を受け付ける。そして、アドバタイズメッセージ７０５を受け付けると、プロセス情報管理部４０３は、Ｓ１００４に処理を進め、前記Ｓ１００５で起動したコンポーネントプロセスのエンドポイントをクエリーの要求元に通知する。なお、図１０には記載していないが、アドバタイズメッセージ７０５が規定時間内にプロセス情報管理部４０３に到着しない場合、プロセス情報管理部４０３は、エラーと判別し、Ｓ１００７に処理を進めるようにしてもよい。
【００９２】
Ｓ１００７では、プロセス情報管理部４０３は、クエリー要求元にエラーを通知する。
以上がデータ変換サービスにおいて、プロセス情報管理部４０３が行うクエリーの処理の基本的な流れである。
【００９３】
＜データ変換処理（Ｓ６０５）の詳細＞
以下、図６のＳ６０５にて説明したデータ変換処理の詳細について、図１１を用いて説明する。なお、図６のＳ６０３、Ｓ６０４で説明したように、構築するフィルタパイプラインは、フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７から構成されるものとして説明をする（図４、図６参照）。
図１１は、図６のＳ６０５のデータ変換処理の流れを例示するフローチャートである。即ち、図１１に示す処理は、サーバＰＣ１０６のＣＰＵ２０５が、ＨＤＤ２０２等に格納されたプログラムを読み出して実行することで実現されるものである。
【００９４】
ジョブ制御部４０２は、図６のＳ６０４に示したパイプライン生成処理を完了すると、図１１の処理を開始する。Ｓ１１０１において、ジョブ制御部４０２は、図６のＳ６０２でジョブ受け付け部４０１から受け取った入力データ（及び設定ファイル）を、フィルタパイプラインに受け渡す。パイプライン上の各フィルタ制御部４０４は、順次処理を実行し、処理結果（正常に処理できたか、エラーとなったか）をジョブ制御部４０２へ通知し、ジョブ制御部４０２は、この処理結果を受信する（Ｓ１１０２）。
【００９５】
次に、Ｓ１１０３において、ジョブ制御部４０２は、フィルタ制御部４０４から受け取った処理結果に応じて、以降の処理を分岐する。ジョブ制御部４０２は、フィルタ制御部４０４から受け取った処理結果が正常終了であると判定した場合（Ｓ１１０３で「正常」の場合）、Ｓ１１０４に処理を進める。
【００９６】
Ｓ１１０４では、ジョブ制御部４０２は、「アイドリング状態へ移行可能なフィルタ」があるかどうか判断する。以下、具体的な判断方法を例示する。
ジョブ制御部４０２は、上記Ｓ１１０３で正常終了と判定したフィルタ制御部の１つ前（次のフィルタの処理が開始された場合には処理中のフィルタ制御部４０４の２つ前）のフィルタ制御部４０４を、順次「アイドリング状態へ移行可能なフィルタ」と判断する。即ち、上記Ｓ１１０３で正常終了と判定したフィルタ制御部４０４については、続くＳ１１０４では「アイドリング状態へ移行不可能なフィルタ」と判断し、まだ解放しない。
以下、図４で示した例（フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７から構成されるフィルタパイプライン）を用いて説明する。
【００９７】
・例えば、前記Ｓ１１０２で、フィルタＡ４０５から（フィルタ制御部４０４を介して）正常終了の処理結果通知を受けた場合、フィルタＡ４０５は先頭フィルタであるため、フィルタＡ４０５よりも１つ前のフィルタは存在しない。よって、この場合、Ｓ１１０４において、ジョブ制御部４０２は、「アイドリング」状態移行可能なフィルタはないと判断する。
・また、前記Ｓ１１０２で、フィルタＢ４０６から（フィルタ制御部４０４を介して）正常終了の処理結果通知を受けた場合、フィルタＢ４０６よりも１つ前のフィルタである「フィルタＡ４０５」が存在する。よって、この場合、Ｓ１１０４において、ジョブ制御部４０２は、フィルタＡ４０５を「アイドリング」状態移行可能なフィルタであると判断する。
・また、前記Ｓ１１０２で、フィルタＣ４０７から（フィルタ制御部４０４を介して）正常終了の処理結果通知を受けた場合、ジョブ制御部４０２は、フィルタＣ４０７はよりも１つ前のフィルタである「フィルタＢ４０６」が存在する。よって、この場合、Ｓ１１０４において、ジョブ制御部４０２は、フィルタＢ４０６を「アイドリング」状態移行可能なフィルタであると判断する。
【００９８】
前記Ｓ１１０４において、アイドリング状態へ移行可能なフィルタがないと判断した場合（Ｓ１１０４でＮｏの場合）、ジョブ制御部４０２は、そのままＳ１１０６に処理を進める。
【００９９】
一方、前記Ｓ１１０４において、アイドリング状態へ移行可能なフィルタがあると判断した場合（Ｓ１１０４でＹｅｓの場合）、ジョブ制御部４０２は、Ｓ１１０５に処理を進める。Ｓ１１０５では、ジョブ制御部４０２は、該当するフィルタ制御部４０４に対して、アイドリング状態へ移行するよう指示する。指示を受けたフィルタ制御部４０４は、ローカルログ出力部４１１のメモリ上に蓄積していたログを廃棄し、プロセス情報管理部４０３に「アイドリング」状態への変更通知（ステートチェンジメッセージ）を送信する。プロセス情報管理部４０３は、その変更通知を受け取り、サービスインベントリー７０６において当該コンポーネントプロセスの状態９０６を「アイドリング」に変更する。これにより、該当フィルタは、別の処理を受け付け可能な状態へ移行することができる。
【０１００】
次に、Ｓ１１０６において、ジョブ制御部４０２は、前記Ｓ１１０２で処理結果を送ってきたフィルタ制御部４０４がパイプラインの最終フィルタに対応するかどうか判断する。例えば、パイプライン生成処理（図６のＳ６０１）を行う際に参照した設定ファイル（例えば、図５（ａ）、図５（ｂ）の要素群５０２：フィルタの組み合わせと並び順が記載されたファイル）から最終フィルタであるかどうか判断する。
【０１０１】
そして、ジョブ制御部４０２は、前記Ｓ１１０２で処理結果を送ってきたフィルタ制御部４０４がパイプラインの最終フィルタでないと判断した場合（Ｓ１１０６でＮｏの場合）、Ｓ１１０２に処理を戻し、次のフィルタ制御部４０４からの処理結果を受信するまで待機する。そして、最終フィルタと判断されるまで、Ｓ１１０２〜Ｓ１１０５の処理を繰り返し行う。そして、前記Ｓ１１０２で処理結果を送ってきたフィルタ制御部４０４がパイプラインの最終フィルタであると判断した場合（Ｓ１１０６でＹｅｓの場合）、ジョブ制御部４０２は、Ｓ１１０９に処理を進める。
【０１０２】
Ｓ１１０９では、ジョブ制御部４０２は、後処理を実施して処理を終了する。具体的には、パイプラインの破棄や、まだ「アイドリング」状態となっていないフィルタ制御部４０４に対してアイドリング状態へ移行するよう指示する。プロセス情報管理部４０３は、フィルタ制御部４０４からの変更通知を受け取り、サービスインベントリー７０６において、当該コンポーネントプロセスの状態９０６を「アイドリング」に変更する。
【０１０３】
また、上記Ｓ１１０３において、フィルタ制御部４０４から受け取った処理結果がエラー終了であると判定した場合（Ｓ１１０３で「エラー発生」の場合）、ジョブ制御部４０２は、Ｓ１１０７に処理を進める。Ｓ１１０７では、ジョブ制御部４０２は、ログファイルを出力させるフィルタ制御部４０４を決定する。本実施例においては、パイプラインに組み込まれたフィルタ制御部４０４のうち、エントリー９０１内の状態９０６が「ビジー」状態のフィルタ制御部４０４をログファイル出力対象フィルタとして決定する。
【０１０４】
次に、Ｓ１１０８において、ジョブ制御部４０２は、ログファイル出力対象フィルタに対して、ログファイル出力指示を行う。該指示を受けたフィルタ制御部４０４は、ローカルログ出力部４１１のメモリ上に蓄積していたログを、ファイルとして出力する。そして、エラー発生によりジョブの継続処理は行えないと判断し、ジョブ制御部４０２は、後処理（Ｓ１１０９）へ処理を移行させる。
【０１０５】
なお、上記説明では、ジョブ制御部４０２が、正常終了と判定したフィルタ制御部の１つ前（次のフィルタの処理が開始された場合には処理中のフィルタ制御部４０４の２つ前）のフィルタ制御部４０４を「アイドリング状態へ移行可能なフィルタ」と判断する構成を説明した。しかし、「アイドリング状態へ移行可能なフィルタ」と判断するフィルタは、正常終了と判定したフィルタ制御部の１つ前に限定されるものではない。正常終了と判定したフィルタ制御部の２つ以上前のフィルタ制御部４０４を「アイドリング状態へ移行可能なフィルタ」と判断してもよい。即ち、ジョブ制御部４０２は、正常終了と判定したフィルタ制御部の所定数だけ前段処理されたフィルタ制御部４０４を「アイドリング状態へ移行可能なフィルタ」と判断するものとする。また、該解放するフィルタの判断（解放判断）は、上記正常終了と判定したフィルタの次のフィルタの処理が開始される前に行ってもよい。即ち、上記正常終了と判定したフィルタの次のフィルタの処理が開始される前に、該正常終了と判定したフィルタの所定数前段で処理された未解放のフィルタを解放するフィルタ（アイドリング状態へ移行可能なフィルタ）と判断してもよい。
【０１０６】
以上示したように、現在処理中のフィルタでエラーが発生した場合、該フィルタの所定数前（例えば１つ前）までのフィルタのログを取得することができ、且つ、それより前（例えば２つ以上前）のフィルタは次のジョブの受付が迅速に可能になる。
【実施例２】
【０１０７】
前述の実施例１では、図１１のＳ１１０４で、正常終了と判定したフィルタ制御部４０４の所定数前（例えば１つ前）のフィルタ制御部４０４を「アイドリング状態へ移行可能なフィルタ」と判断する例について説明した。実施例２では、他の判断方法について例示する。
【０１０８】
ジョブ制御部４０２は、図５（ａ）、図５（ｂ）で示した設定ファイルの要素群５０２を参照することで、各フィルタ制御部４０４の入出力ファイルフォーマットを把握している。実施例２では、これを利用して、「アイドリング状態へ移行可能なフィルタ」と判断する。ジョブ制御部４０２は、図１１のＳ１１０３で正常終了と判定したフィルタ制御部４０４の出力フォーマット（即ち、次のフィルタの処理が開始された場合には処理中のフィルタ制御部４０４の入力ファイルフォーマット）と、該正常終了と判定したフィルタ制御部４０４より前に既に処理済である前段のフィルタの出力ファイルフォーマットを比較する。そして、これが異なるファイルフォーマットであった場合に、該当する前段のフィルタ制御部４０４を「アイドリング状態へ移行可能なフィルタ」と判断する。即ち、上記Ｓ１１０３で正常終了と判定したフィルタ制御部４０４については、続くＳ１１０４では「アイドリング状態へ移行不可能なフィルタ」と判断し、まだ解放しない。
【０１０９】
＜例１＞
例１では、図４、図５（ａ）で示した例（フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７から構成されるフィルタパイプライン）を用いて説明する。
・例えば、図１１のＳ１１０２で、フィルタＡ４０５から（フィルタ制御部４０４を介して）正常終了の処理結果通知を受けた場合、ジョブ制御部４０２は、フィルタＡ４０５は先頭フィルタであるため、フィルタＡ４０５より前段で処理されたフィルタが存在しない。よって、この場合、「アイドリング」状態移行可能なフィルタはないと判断する。
【０１１０】
・また、図１１のＳ１１０２で、フィルタＢ４０６から（フィルタ制御部４０４を介して）正常終了の処理結果通知を受けた場合、ジョブ制御部４０２は、フィルタＢ４０６の出力ファイルフォーマットと、フィルタＢ４０６よりも前のフィルタ（フィルタＡ４０５）の出力ファイルフォーマットを比較する。図５（ａ）で示した例では、フィルタＡ４０５の出力ファイルフォーマットが「ｊｐｇ」であり、フィルタＢ４０６出力フォーマット「ｐｄｆ」と異なる。よって、この場合、フィルタＡ４０５を「アイドリング」状態移行可能なフィルタ判断する。
【０１１１】
・また、図１１のＳ１１０２で、フィルタＣ４０７から（フィルタ制御部４０４を介して）正常終了の処理結果通知を受けた場合、ジョブ制御部４０２は、フィルタＣ４０７の出力ファイルフォーマットと、フィルタＣ４０７よりも前のフィルタ（フィルタＡ４０５、フィルタＢ４０６）の出力ファイルフォーマットを比較する。図５（ａ）で示した例では、フィルタＡ４０５の出力ファイルフォーマットが「ｊｐｇ」であり、フィルタＣ４０７入力フォーマット「ｐｄｌ」と異なる。よって、この場合、フィルタＡ４０５を「アイドリング」状態移行可能なフィルタであると判断する。また、フィルタＢ４０６の出力ファイルフォーマット「ｐｄｆ」もフィルタＣ４０７出力フォーマット「ｐｄｌ」と異なる。よって、この場合、フィルタＢ４０６も「アイドリング」状態移行可能なフィルタであると判断する。
【０１１２】
＜例２＞
例２では、図４、図５（ｂ）で示した例（フィルタＡ４０５、フィルタＢ４０６、フィルタＣ４０７から構成されるフィルタパイプライン）を用いて説明する。
・例えば、図１１のＳ１１０２で、フィルタＡ４０５から（フィルタ制御部４０４を介して）処理結果通知を受けた場合、フィルタＡ４０５は先頭フィルタであるため、フィルタＡ４０５より前段で処理されたフィルタが存在しない。よって、この場合、ジョブ制御部４０２は、「アイドリング」状態移行可能なフィルタはないと判断する。
【０１１３】
・また、前記Ｓ１１０２で、フィルタＢ４０６から（フィルタ制御部４０４を介して）処理結果通知を受けた場合、ジョブ制御部４０２は、フィルタＢ４０６の出力ファイルフォーマットと、フィルタＢ４０６よりも前のフィルタ（フィルタＡ４０５）の出力ファイルフォーマットを比較する。図５（ｂ）で示した例では、両者とも「ｐｄｆ」である。よって、この場合、ジョブ制御部４０２は、「アイドリング」状態移行可能なフィルタはないと判断する。
【０１１４】
・また、前記Ｓ１１０２で、フィルタＣ４０７から（フィルタ制御部４０４を介して）正常終了の処理結果通知を受けた場合、ジョブ制御部４０２は、フィルタＣ４０７の出力ファイルフォーマットと、フィルタＣ４０７よりも前のフィルタ（フィルタＡ４０５、フィルタＢ４０６）の出力ファイルフォーマットを比較する。図５（ｂ）で示した例では、いずれも「ｐｄｆ」である。よって、この場合、ジョブ制御部４０２は、「アイドリング」状態移行可能なフィルタはないと判断する。
【０１１５】
また、上記解放するフィルタの判断（解放判断）は、上記正常終了と判定したフィルタの次のフィルタの処理が開始される前に行ってもよい。即ち、上記正常終了と判定したフィルタの次のフィルタの処理が開始される前に、該正常終了と判定したフィルタより前段で処理され、該フィルタと出力フォーマットが異なる未解放のフィルタを、解放するフィルタ（アイドリング状態へ移行可能なフィルタ）と判断してもよい。
【０１１６】
以上示したように、現在処理中のフィルタの入力フォーマットのデータを作成、編集したフィルタ（現在の処理中のフィルタに関係するフィルタ）のログを取得することができ、且つ、他のフィルタ（現在の処理中のフィルタに無関係なフィルタ）は次のジョブの受付が迅速に可能になる。
【０１１７】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
【０１１８】
（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【０１１９】
以上示したように、複数フィルタから構成されるフィルタパイプラインを処理するシステムにおいて、フィルタ処理が正常終了した場合、フィルタを解放するかどうかを判断し、該解放すると判断したフィルタのみ解放する。そして、フィルタでエラーが発生した場合に、解放されていない前段フィルタとエラー発生フィルタのログファイルを出力させる。なお、フィルタを解放するかどうかの判断方法の一例としては、該正常終了したフィルタの所定数前（例えば１つ前）のフィルタを解放すると判断する。また、該正常終了したフィルタより前段に処理され、該正常終了したフィルタと出力フォーマットの異なる未解放のフィルタを解放すると判断する。このような構成により、共通化した機能（フィルタ）の組み合わせ方を変え様々な処理を実現するシステムにおいて、エラー発生時に前段フィルタのログファイルを出力することと、処理完了後に直ちに待機モードに移行することを両立することができる。これにより、エラー発生時に必要なログファイルを出力するとともに、各フィルタを効率的に利用することが可能になる。
【符号の説明】
【０１２０】
１０６    サーバＰＣ
３０１    印刷データ変換サービス
４０１    ジョブ処理受け付け部
４０２    ジョブ制御部
４０３    プロセス情報管理部
４０４    フィルタ制御部
４０５〜４０７    フィルタ
４０８    ログ出力部
【図１】
2015212853.tif 000003
【図２】
2015212853.tif 000004
【図３】
2015212853.tif 000005
【図４】
2015212853.tif 000006
【図５】
2015212853.tif 000007
【図６】
2015212853.tif 000008
【図７】
2015212853.tif 000009
【図８】
2015212853.tif 000010
【図９】
2015212853.tif 000011
【図１０】
2015212853.tif 000012
【図１１】
2015212853.tif 000013