(57)【要約】【課題】複数のフィルタを用いて処理を実行する情報処理装置において、ログを安定的に取得しつつ、処理を高速に行うこと。【解決手段】情報処理装置は、機能に応じたフィルタを実行することによりパイプライン処理を行う。制御部は、第１モードにて複数のフィルタを同一のプロセスで動作させ、かつログデータを出力しない（Ｓ１１０３）。第１モードにおいて処理が正常に終了しなかった場合（Ｓ１１０４でエラー発生またはクラッシュ発生）、ログデータを出力する第２モードで処理が再実行される。エラーが発生した場合には、ログデータを出力するフィルタが限定される（Ｓ１１０５，Ｓ１１０６）。また、クラッシュ発生時に制御部は、フィルタ及びログ出力機能をそれぞれ別プロセスで動作させて処理を再実行し、ログデータを出力させる（Ｓ１１０８）。【選択図】  図１２
2015130075.tif 000002
【特許請求の範囲】
【請求項１】
機能に応じた複数のフィルタを実行することにより処理を行う情報処理装置であって、
前記複数のフィルタを同一のプロセスで、かつログデータを出力しない第１モードで実行する実行手段と、
前記第１モードにて前記複数のフィルタを用いた処理が正常に終了しなかった場合、前記複数のフィルタを複数のプロセスで、かつログデータを出力する第２モードで再実行する再実行手段と、を有することを特徴とする情報処理装置。
【請求項２】
前記実行手段は、前記第１モードにて前記複数のフィルタによるパイプライン処理を実行し、前記第１モードでのパイプライン処理が正常に終了しなかった場合、前記再実行手段は前記第２モードで前記パイプライン処理を再実行させ、ログデータが出力されることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第１モードでのパイプライン処理が正常に終了しなかった場合、前記複数のフィルタのうち、どのフィルタでエラーが発生したかを特定する特定手段を有することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記再実行手段は、前記特定手段が特定した前記フィルタに対して、ログデータを出力させる処理を行うことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記フィルタから取得したログデータをログファイルに出力するローカルログ出力部を有することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
機能に応じた複数のフィルタを実行することにより処理を行うコンピュータにおいて実行されるプログラムであって、
前記コンピュータに、
前記複数のフィルタを同一のプロセスで、かつログデータを出力しない第１モードで実行する実行工程と、
前記第１モードにて前記複数のフィルタを用いた処理が正常に終了しなかった場合、前記複数のフィルタを複数のプロセスで、かつログデータを出力する第２モードで再実行する再実行工程と、を実行させることを特徴とするプログラム。
【請求項７】
前記コンピュータに、
前記実行工程では、前記第１モードにて前記複数のフィルタによるパイプライン処理を実行させ、前記第１モードでのパイプライン処理が正常に終了しなかった場合、前記再実行工程では前記第２モードで前記パイプライン処理を再実行させ、ログデータが出力されることを特徴とする請求項６に記載のプログラム。
【請求項８】
前記コンピュータに、
前記第１モードでのパイプライン処理が正常に終了しなかった場合、前記複数のフィルタのうち、どのフィルタでエラーが発生したかを特定する特定工程を実行させることを特徴とする請求項７に記載のプログラム。
【請求項９】
前記コンピュータに、
前記再実行工程にて、前記特定工程で特定した前記フィルタに対して、ログデータを出力させる処理を実行させることを特徴とする請求項８に記載のプログラム。
【請求項１０】
前記コンピュータに、
前記フィルタから取得したログデータをログファイルに出力するローカルログ出力工程を実行させることを特徴とする請求項６乃至９のいずれか１項に記載のプログラム。
【請求項１１】
機能に応じた複数のフィルタを実行することにより処理を行う情報処理装置の制御方法であって、
前記情報処理装置により、
前記複数のフィルタを同一のプロセスで、かつログデータを出力しない第１モードで実行する実行工程と、
前記第１モードにて前記複数のフィルタを用いた処理が正常に終了しなかった場合、前記複数のフィルタを複数のプロセスで、かつログデータを出力する第２モードで再実行する再実行工程と、を有することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを変換する情報処理装置、情報処理方法、およびプログラムに関する。
【背景技術】
【０００２】
特許文献１は、「モノクロプリンタ」、「解像度300dpi以下」といった複数のフィルタを用いて画像データを変換する技術を開示する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−２５４１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に示すフィルタやフィルタに投入される画像データによっては、フィルタで正常に処理が完了しない可能性がある。正常に処理が完了しなかった場合に管理者や開発者は原因を特定する必要がある。よって、何らかの問題（データ変換の失敗等）が発生する場合に備えて、ログデータ（以下、単にログと呼ぶ）を残す方法について検討する。ログを残す場合にフィルタを実行するシステムが処理するすべてのジョブに対してログを出力する方法では、大量のジョブを処理すると処理速度を低下させてしまうという問題がある。即ち、ログ出力量と処理速度とはトレードオフの関係にある。
【０００５】
さらにシステムの高速化を実現するために、システムの複数のフィルタを一つのプロセス（シングルプロセス）で動作させる方法と、マルチプロセスで動作させる方法について検討する。シングルプロセスによる処理は、マルチプロセスによる処理よりも高いパフォーマンスを得ることが期待できる。その理由は、マルチプロセスの場合、プロセス間でデータをやり取りする場合にプロセス間通信が必要となるのに対し、シングルプロセスの場合には、コンポーネント間の関数呼び出しやメモリのやり取りで済むため、処理が高速となるからである。
しかし、シングルプロセスでは、いずれかのコンポーネントがクラッシュや無限ループに陥った場合に、システム全体のクラッシュまたは無限ループが問題となる。その場合、前述のようにログを残す構成にしたとしても、正常にログが出力されない可能性がある。これにより、正常にログが取得できずシステムの障害解析が困難になる可能性がある。
【０００６】
このようにシングルプロセスによる処理は高速であるがクラッシュ時にログが取れない可能性がある。他方、マルチプロセスによる処理はシングルプロセスに比較して低速であるが、可用性が高いため正常にログを取得できる可能性が高い。
【０００７】
よって本発明は、複数のフィルタを用いて処理を実行する情報処理装置において、ログを安定的に取得しつつ、処理を高速に行うことを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明に係る装置は、機能に応じた複数のフィルタを実行することにより処理を行う情報処理装置であって、前記複数のフィルタを同一のプロセスで、かつログデータを出力しない第１モードで実行する実行手段と、前記第１モードにて前記複数のフィルタを用いた処理が正常に終了しなかった場合、前記複数のフィルタを複数のプロセスで、かつログデータを出力する第２モードで再実行する再実行手段と、を有する。
【発明の効果】
【０００９】
本発明によれば、複数のフィルタを用いて処理を実行する情報処理装置において、ログを安定的に取得しつつ、処理を高速に行うことができる。
【図面の簡単な説明】
【００１０】
【図１】図２から図１２と併せて本発明の実施形態を説明するために、システム構成例を示す図である。
【図２】印刷データ変換サービスが動作するサーバのハードウェア構成を示す図である。
【図３】図２のサーバ上で動作するソフトウェアを説明する図である。
【図４】印刷データ変換サービスと関連するコンポーネント群を示す構成図である。
【図５】フィルタの種類および並び順を定義した設定ファイルを例示する図である。
【図６】データ変換処理例を示す図である。
【図７】データ変換処理の別例を示す図である。
【図８】コンポーネント間のメッセージの送受信を示した模式図である。
【図９】サービスカタログの構成例を示す模式図である。
【図１０】サービスインベントリの構成例を示す模式図である。
【図１１】クエリについて処理の流れを示すフローチャートである。
【図１２】本実施形態における処理全体の流れを示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態について、添付図面を参照して説明する。
図１は本実施形態に係るクラウドプリントサービスのシステム構成図である。
依頼者１０１は印刷データの変換を依頼する際、ＰＣ（パーソナルコンピュータ）１０２、タブレット１０３や携帯端末１０４等の機器を利用する。これらの機器は、依頼者１０１からの操作を受け付け、ネットワーク１０５上に存在する印刷データ変換サービスに対して印刷データの変換を依頼する。印刷データ変換サービスはサーバ１０６上で既知のURL（Uniform Resource Locator）を公開している、いわゆるWebサービスとして動作しているプログラムである。サーバ１０６上では前記URLに対する依頼を印刷データ変換サービスに転送するWebサーバが動作している。この依頼が多数である場合、単一のサーバ１０６が処理せず、複数のサーバ１０６を備えるサーバシステムが処理する構成となる。従って、複数のサーバ１０６の前段にロードバランサ１０７が設置され、各サーバ１０６に転送される依頼が均一に配分されるように構成される。
【００１２】
印刷データ変換サービスが提供するサービスは、依頼者１０１から受け付けたデータをプリンタ１０８で印刷できる形式に変換することである。依頼者１０１から受け付けるデータにはドキュメント、画像ファイル等、各種のアプリケーションプログラムで作成されたフォーマットが存在する。一方、プリンタ１０８が印刷データとして受け付けるデータは前述のフォーマットとは異なり、PDL（Page Description Language）で記述されたデータや、印刷部数等の印刷を制御するためのデータである。
【００１３】
このように、依頼者１０１とプリンタ１０８との間には扱うデータ形式に差異があるため、データ変換処理により差異をなくすプログラムが必要とされる。通常、このデータ変換処理を行うのがプリンタドライバと称するプログラムである。プリンタドライバは、依頼者１０１が操作するアプリケーションプログラムが動作しているＰＣ上で動作する。しかし、プリンタドライバの処理は、ＣＰＵ（中央演算処理装置）やメモリ等のリソースを必要とする、比較的に処理負担の大きい処理である。このため、依頼者１０１の操作するＰＣのリソースが十分でない場合には、印刷処理に時間がかかってしまう。タブレット１０３や携帯端末１０４といった、比較的リソースの少ない端末からの印刷の需要が高まるのに伴い、プリンタドライバの処理をインターネット上のサービスで行わせることの重要性が増している。ＰＣ１０２、タブレット１０３、携帯端末１０４は、依頼者１０１からの指示を受け付け、前述のURLに対して印刷データをプリンタ１０８で印刷できる形式に変換するように依頼する。依頼に応じてサーバ１０６上で動作している印刷データ変換サービスが生成した、変換後のデータは、依頼元の端末装置に対して返信される。依頼者１０１から受け付ける指示によっては、変換後のデータは印刷データ変換サービスがアクセス可能なファイルサーバ１０６で保管する場合もある。
【００１４】
次に、本実施形態に係るサーバのハードウェア構成を説明する。図２は印刷データ変換サービスのソフトウェア群が動作するサーバ１０６のハードウェア構成図である。図２は情報処理装置の基本的な構成だけを例示しており、機能に応じて各種デバイスが追加される。
印刷データ変換サービスはオペレーティングシステム（以下、ＯＳという）上で動作するアプリケーションプログラムであり、ＨＤＤ（ハードディスクドライブ装置）２０２またはＲＯＭ（リード・オンリ・メモリ）２０３に格納されている。ＣＰＵ２０５は、ＯＳとアプリケーションプログラムをＨＤＤ２０２またはＲＯＭ２０３から読み出し、ＲＡＭ２０４にロードして実行する。これにより、各種処理が進行し、印刷データ変換サービスの機能が実現される。処理結果は、ファイルとしてＨＤＤ２０２に格納されるか、またはデータとしてＲＡＭ（ランダム・アクセス・メモリ）２０４に記憶される。アプリケーションプログラムは、コンピュータに接続されている入力装置２０７から使用者の入力操作信号や各種センサの読み取り値を取得する。アプリケーションプログラムはさらに、出力装置２０６に対して情報を出力し、処理結果を表示デバイスに表示する。さらに、通信装置２０８を介してネットワークに接続された他のコンピュータや装置との間で通信処理が行われる。これらのハードウェア構成部はバス２０１で互いに接続されており、アプリケーションプログラムから操作可能である。
【００１５】
次に、図３を参照してソフトウェア構成を説明する。図３は、印刷データ変換サービス３０１を含むソフトウェア群がサーバ１０６上で動作する場合の構成例を示すブロック図である。
Webサーバ３０２は依頼者１０１が操作したＰＣ１０２上のアプリケーションから、HTTP（Hypertext Transfer Protocol）プロトコルで送信されたリクエストを受け取る。ロードバランサ１０７はWebサーバ３０２の前段に位置しており、複数のサーバ１０６上で動作しているWebサーバ３０２にリクエストを振り分ける。この振り分け方式の詳細は本発明に関係がないため、説明を省略する。
【００１６】
本実施形態において、サーバ１０６は必ずしも物理的な一台のマシンを意味しないことに注意を要する。単一のコンピュータ上に複数の仮想的なコンピュータを出現させる仮想化技術が一般的となっている。ソフトウェアからみた場合、自身が動作しているＯＳが仮想的に作り出されたものか否かは判別がつかないか、または判別の必要がない。従って、本実施形態のサーバ１０６は「仮想化されたコンピュータ」を意味する場合もある。これ以降、「コンピュータ」は、広義には物理的なマシンとしてのコンピュータ、および仮想化されたコンピュータの両方を意味するものとして扱う。
アプリケーションサーバ３０３は、要求の送付先として指定されたURLを解析し、関連付けられている印刷データ変換サービス３０１を決定する。通常、Webサーバ３０２とアプリケーションサーバ３０３は複数種類のサービスを扱うことが可能であり、URLから対応するサービスを特定して要求を振り分けることができる。本実施形態では複数種類のサービスの一つを、印刷データ変換サービス３０１と想定する。このサービスの他にもサービスが稼働しているが、本発明に直接関係ないので説明を省略する。
【００１７】
印刷データ変換サービス３０１はプロセスとして動作する。アプリケーションサーバ３０３は複数の要求を並列して実行させるために、複数の印刷データ変換サービス３０１を起動させ、各々に要求を振り分ける。アプリケーションサーバ３０３はさらに、印刷データ変換サービス３０１が動作する際、依頼者１０１からの一連の要求を特定する為のセッションを管理する。具体的には、同一の依頼者１０１からの要求については、同一の印刷データ変換サービス３０１に転送するセッション・アフィニティを実現している。
図４を参照して印刷データ変換サービス３０１について説明する。図４は、印刷データ変換サービス３０１が、依頼された印刷データを変換する際に利用するソフトウェアコンポーネント群の関連を説明する図である。なお、以下では、プロセスとして起動したコンポーネントを、「コンポーネントプロセス」という。
【００１８】
印刷データ変換サービス３０１はプロセスとして動作しており、変換処理をジョブ制御部４０２に委譲している。印刷データ変換サービス３０１は、ジョブ制御部４０２の代理としてのジョブ処理受け付け部４０１をロードしている。さらにジョブ処理受け付け部４０１がApplication Programming Interface（API）で提供している関数群を呼び出すことで変換処理の実行を依頼し、さらに結果を受領する。印刷データ変換処理の実行の際、印刷データ変換サービス３０１は、ジョブ処理受け付け部４０１に対して処理対象のデータ一式を渡す。この処理対象のデータ一式をジョブと呼ぶ。ジョブは、変換対象データと、変換処理用の設定値等をまとまりのある形式に束ねた「チケット」と呼ばれるデータ構造を有する。
ジョブ制御部４０２もまたプロセスとして動作しており、変換処理の受け付けの為の通信インターフェイスを保持している。通信インターフェイスへのジョブの依頼はHTTPプロトコルではなく、専用のプロトコルが用いられる。ジョブ処理受け付け部４０１のAPIを呼び出す処理は、ジョブ制御部４０２が用意している変換処理受付用通信インターフェイスへのプロセス間通信として行われる。すなわち、印刷データ変換サービス３０１にとって変換処理はジョブ処理受け付け部４０１によって実行されているように見える。しかし実際には、ジョブ制御部４０２および後述する複数のフィルタ群、並びにフィルタ群が利用するいくつかのコンポーネントの相互作用によって実現されている。
【００１９】
以下では、図４に示す各コンポーネントの機能について説明し、図６を参照してデータ変換処理の概要を説明する。先ず、プロセス情報管理部４０３を説明する。
プロセス情報管理部４０３は、アプリケーションサーバ３０３が起動した時点で唯一起動している特殊なプロセスである。アプリケーションサーバ３０３上で動作しているＯＳを設定し、ＯＳの起動時に自動的にプロセス情報管理部４０３のプロセスを起動させる処理が実行される。
【００２０】
プロセス情報管理部４０３はコンポーネントをプロセスとして起動する役割を担い、他のコンポーネントからの要求に応じて別のコンポーネントのエンドポイントを返す機能を提供する。エンドポイントとはTCP/IP（Transmission Control Protocol/Internet Protocol)のリスンポートを指す。あるコンポーネントは別のコンポーネントが公開しているエンドポイントを取得し、そのエンドポイントにアクセスすることでそのコンポーネントが提供する機能を利用する。あるコンポーネントが他のコンポーネントのエンドポイントをプロセス情報管理部４０３に対して問い合わせる動作を「クエリ」と呼ぶこととする。
【００２１】
印刷データ変換サービス３０１を構成するコンポーネントのうち、ジョブ処理受け付け部４０１、ジョブ制御部４０２、フィルタ制御部４０４は、ログ出力部４０８が提供しているログデータをログファイルとして記録するサービスを利用できる。例えば管理者や開発者はこうしたログファイルの解析結果により、何が発生したかを把握して対策を講じることができる。そのため、これらはプロセス情報管理部４０３に対してログ出力部４０８のエンドポイントを得る目的でクエリを行っている。同様にジョブ処理受け付け部４０１はジョブ制御部４０２をクエリし、ジョブ制御部４０２は、例えば第１フィルタ（フィルタA）４０５、第２フィルタ（フィルタB）４０６、第３フィルタ（フィルタC）４０７のクエリを行う。クエリの処理の流れについては図８および図１１を用いて後述する。
【００２２】
コンポーネントが提供しているサービスは、ネットワークからアクセスできるエンドポイントとして他のコンポーネントに公開される。具体的にはTCP/IPのアドレスとポート番号の組が公開される。コンポーネントは他のコンポーネントの提供するサービスI/F（インターフェイス）を取得して利用する。複数種類のコンポーネントがプロセスとして複数存在し、かつ同一コンポーネントも同一ＰＣ上に複数存在する。従って、各コンポーネントが公開するサービスI/Fのポート番号は固定値にすることができず、自ずと動的に生成せざるを得なくなる。動的に生成されたエンドポイントは、何らかの管理機構が無くては他から参照することはできない。この管理を担当するのがプロセス情報管理部４０３である。さらに、コンポーネントは、他のコンポーネントが動的に生成したエンドポイントを取得する手段が必要である。この手段がクエリである。プロセス情報管理部４０３は、他のコンポーネントからのクエリに対して、要求されたコンポーネントのエンドポイントを回答する。ジョブ処理受け付け部４０１を介してジョブ実行を依頼されたジョブ制御部４０２は、ジョブに含まれている「ジョブ種別情報」をもとに、変換に必要なフィルタを選定する。必要なフィルタの組み合わせとその並び順については、例えば設定ファイルとしてジョブ制御部４０２が保持する。
【００２３】
図５は、必要なフィルタの組み合わせ、およびその並び順を記述するための設定ファイルを例示する。ジョブ種別情報を記載するための要素５０１を示す。
id属性でジョブ種別情報が指定される。要素群５０２はフィルタの組み合わせと並び順を記述するための要素である。name属性によりフィルタの種類が記述され、version属性により特定されるバージョンのフィルタを使うことが記述される。要素群５０２は、要素の記述順でフィルタの並び順を規定する。図５に例示する要素群５０２の場合、Filter A、Filter B、Filter Cの順で処理が行われる。ジョブ制御部４０２は、ジョブに含まれているジョブ種別情報と一致する要素５０１を検索し、一致する要素５０１の下に記述されているフィルタの組み合わせと並び順を採用する。
なお、必要なフィルタの組み合わせおよびその並び順については、ジョブ種別情報の代わりに、印刷データを解析して決定してもよい。その場合、印刷データの先頭から既定のサイズを読出し、その中に含まれている特徴的な内容から印刷データの種類を判定する処理が実行される。例えば、JPEG（Joint Photographic Experts Group）形式や、PDF（Portable Document Format）形式のデータ等が入力データとして与えられる。次に、ジョブに含まれている変換先の印刷データ形式を取得し、変換元の印刷データ形式と変換先の印刷データ形式の両者が確定した時点で、この変換に必要なフィルタ群を選定する処理が行われる。
【００２４】
図４（Ａ）では、必要な複数のフィルタが選定された後、各フィルタがフィルタ制御部４０４にそれぞれロードされている状態を示す。図４（Ａ）の例では、変換に必要なフィルタとして、フィルタA４０５、フィルタB４０６、フィルタC４０７を例示する。各フィルタはそれぞれフィルタ制御部４０４にロードされている。
ジョブ制御部４０２はフィルタA４０５、フィルタB４０６、フィルタC４０７との間で、パイプライン４０９と呼ばれるデータ転送チャネルを生成する。プロトコルとしては、例えばTCP/IPを用いる。パイプライン４０９は基本的に一方向にのみデータを転送する。ジョブ制御部４０２、フィルタA４０５、フィルタB４０６、フィルタC４０７、ジョブ制御部４０２と、一巡するようにパイプライン４０９が構成される。また、ジョブ制御部４０２はジョブ処理受け付け部４０１との間にもパイプライン４０９を生成する。このようにパイプライン４０９の生成によってジョブ処理受け付け部４０１からの印刷データは複数のコンポーネントを還流し、最後に変換が終了した上で再びジョブ処理受け付け部４０１に戻ってくる。
【００２５】
また、ジョブ制御部４０２は、「複数のフィルタをロードしたフィルタ制御部４０４」をプロセス情報管理部４０３に対してクエリ可能である。図４（Ｂ）は、フィルタA４０５、フィルタB４０６、フィルタC４０７がすべて同じフィルタ制御部４０４内にロードされている例を示す。この場合、フィルタ制御部４０４は、図４（Ｂ）で示すようにローカルログ出力部４１１を保持することも可能である。各フィルタ（４０５、４０６，４０７）は、このローカルログ出力部４１１を介してログデータ（ロギングデータ）を出力可能である。
【００２６】
フィルタはデータ変換処理のみを実装したライブラリモジュールの形式で用意されている。フィルタ制御部４０４はプロセスとして存在し、実行時に指定されたフィルタをロードする。フィルタ制御部４０４はコントロールバス４１０への接続とメッセージ送受信、ジョブ制御部４０２との通信や、フィルタのログ出力をログ出力部４０８へ転送する処理等を担当する。
ローカルログ出力部４１１は、フィルタ制御部４０４のプロセス内にて動作可能である。各フィルタは、ログデータをローカルログ出力部４１１に対して、APIを介して受け渡す。ローカルログ出力部４１１は一定量のログデータが蓄積した時点でログファイルに出力する。ログデータを蓄積せずに逐次ログファイルに出力してもよい。ログファイルの出力パス等の設定については、ローカルログ出力部４１１が起動される際に渡されるコンフィギュレーションファイルで指定される。
【００２７】
ログ出力部４０８は、プロセスとしてコントロールバス４１０上に最低一つは存在する。各コンポーネントはログデータをログ出力部４０８に対して、ネットワークを介して送信する。ログ出力部４０８は一定量のログデータが蓄積した時点でログファイルに出力する。ログデータを蓄積せずに逐次ログファイルに出力してもよい。ログファイルの出力パス等の設定については、ログ出力部４０８が起動される際に渡されるコンフィギュレーションファイルで指定される。
コントロールバス４１０上のコンポーネントはジョブの実行中にログ出力を行う。ローカルログ出力部４１１が個別に出力を行ったのでは、ログファイルがフィルタ制御部４０４毎ごとに分かれてしまい、ログ解析が困難となってしまう。そこで、本実施形態では、ログ出力部４０８が一括してログファイルへの出力を行えるように構成されている。
【００２８】
次に、図６および図７を参照して、データ変換処理の概要を説明する。
図６は、ジョブ処理受け付け部４０１が印刷データ変換サービス３０１からジョブ処理を受け付けた後の、データ変換処理例を示す。
Ｓ６０１は、ジョブ処理受け付け部４０１がジョブ制御部４０２のクエリ要求を行う処理である。ジョブ処理受け付け部４０１は、プロセス情報管理部４０３にクエリ要求を行い、ジョブ制御部４０２のエンドポイントを取得する。Ｓ６０２は、ジョブ処理受け付け部４０１がジョブ制御部４０２に対してジョブ処理依頼を行う処理である。ここで、ジョブのデータが、ジョブ処理受け付け部４０１からジョブ制御部４０２に渡される。その際には、ジョブのデータのパスで渡すようにしてもよいし、メモリやプロセス間通信で渡してもよい。
【００２９】
Ｓ６０３は、ジョブ制御部４０２が、ジョブの内容に基づいて、フィルタの種類と並び順（図５参照）を決定し、それらフィルタのクエリ要求を行う処理である。ジョブ制御部４０２は、プロセス情報管理部４０３に対して、各フィルタに対応するフィルタ制御部４０４のクエリ要求を行い、それぞれのエンドポイントを取得する。ここでは、フィルタA４０５、フィルタB４０６、フィルタC４０７の順に処理を行うものとして説明する。
Ｓ６０４は、パイプラインを生成する処理である。ジョブ制御部４０２は、各フィルタ制御部４０４に対してパイプラインの生成を指示する。各フィルタ制御部４０４は、それぞれ隣り合うコンポーネントプロセスとのパイプラインを生成する。各フィルタ制御部４０４の入力パイプラインからジョブが流れてくるのを待機し、各フィルタ制御部４０４はジョブ制御部４０２にパイプラインの生成処理の完了を通知する。ジョブ制御部４０２は、各フィルタ制御部４０４に対してパイプラインの生成を指示する際、ジョブ制御部４０２のサービスI/Fのエンドポイントを各フィルタ制御部４０４に通知する。フィルタ制御部４０４はエラーが発生した際に、ジョブ制御部４０２のサービスI/Fを通じて、ジョブ制御部４０２にエラーを通知する。
【００３０】
Ｓ６０５はデータ変換処理である。ジョブ制御部４０２は、初段のフィルタ制御部４０４に接続されているパイプラインにデータを渡す。フィルタA４０５は、フィルタ制御部４０４を通じてデータを受け取り、データ変換処理を行う。次に、フィルタA４０５は、フィルタ制御部４０４を通じて、フィルタB４０６と接続されているパイプラインにデータを渡す。フィルタB４０６、フィルタC４０７でも同様にデータ変換処理が順次行われる。最終的に、フィルタC４０７から、フィルタ制御部４０４を通じて、ジョブ制御部４０２に変換後のデータが送信される。Ｓ６０６は、ジョブ制御部４０２が、ジョブ処理受け付け部４０１に対して変換後のデータを返信する処理である。
図６では、各フィルタをそれぞれフィルタ制御部４０４にロードする場合を例示している。
【００３１】
次に、図７を参照して、複数のフィルタを同一のフィルタ制御部４０４にロードする例を説明する。図６との相違点は、Ｓ６０３およびＳ６０４の各処理の内容である。Ｓ６０３−０１においてジョブ制御部４０２は、ジョブの内容をもとに、フィルタの種類および並び順を決定する。そして、ジョブ制御部４０２は、プロセス情報管理部４０３に対して、複数のフィルタをロードした１つのフィルタ制御部４０４のクエリ要求を行い、エンドポイントを取得する。これにより、フィルタA４０５、フィルタB４０６、フィルタC４０７をロードした１つのフィルタ制御部４０４を獲得することができる。
【００３２】
Ｓ６０４−０１は、パイプラインを生成する処理である。ジョブ制御部４０２は、１つのフィルタ制御部４０４に対してパイプラインの生成を指示する。図６のＳ６０４では、上述ように各フィルタ制御部４０４は、それぞれ隣り合うコンポーネントプロセスとのパイプラインを生成した。これに対して図７の、Ｓ６０４−０１にて、フィルタ制御部４０４はフィルタA４０５、フィルタB４０６、フィルタC４０７について、同一プロセス内でパイプラインを生成する。
【００３３】
次に、コンポーネントの生成について説明する。図８はコンポーネントをプロセスとして生成するシーケンスを説明した図である。
図８（Ａ）はプロセス情報管理部４０３のみが存在する状況を示す。この状況は、図３においてサーバ１０６が起動した直後の状態に相当する。この時点では、まだ印刷データ変換サービス３０１は起動していない。プロセス情報管理部４０３は単独でコントロールバス４１０に繋がっている状態である。
プロセス情報管理部４０３はサービスカタログ７０１を保持している。サービスカタログ７０１は、例えば、サーバ１０６のＨＤＤ２０２にファイルとして保存され、プロセス情報管理部４０３によって読み込まれる。図９にサービスカタログの概念図を示す。サービスカタログ７０１は、サーバ１０６上にインストールされているコンポーネントのリストから構成されている。
【００３４】
図９（Ａ）および（Ｂ）において、エントリ８０１は、サービスカタログのエントリであり、コンポーネントごとに存在する。コンポーネント名８０２は当該エントリのコンポーネント名である。サービスのバージョン８０３は、コンポーネントのバージョンを示す。同一の名称を持つコンポーネントであっても、そのバージョンが異なる場合がある。この場合、異なる機能を提供するためにサービスカタログ７０１上では異なるエントリとして扱われる。
ホスティングプロセスパス８０４は、コンポーネントのホスティングプロセスパスを示す。実行ファイルパス８０５は、ホスティングプロセスパス８０４がロードする実行ファイルパスを示す。コンフィギュレーションファイルパス８０６は、コンポーネントをプロセスとして起動したときに、プロセス情報管理部４０３からそのコンポーネントに渡されるコンフィギュレーションファイルのパスである。起動モード８０７は、コンポーネントプロセスが、オンデマンド（Ondemand）で起動するか、またはホットスタンバイ（HotStandby）させておくかを示す。起動モードがオンデマンドの場合、そのコンポーネントを指定したコンポーネントのクエリがあったときに当該コンポーネントプロセスが起動する。また、ホットスタンバイの場合、プロセス情報管理部４０３が起動する際に当該コンポーネントプロセスを起動させる。
【００３５】
図９（Ａ）は、「フィルタA４０５」をロードするフィルタ制御部４０４、即ち、図４（Ａ）で説明したフィルタA４０５をロードしたフィルタ制御部４０４のカタログを示す。一方、図９（Ｂ）は、フィルタＡ４０５、フィルタB４０６、フィルタC４０７を同一のプロセス上にロードするフィルタ制御部４０４のカタログを示す。即ち、図４（Ｂ）で説明したフィルタA４０５、フィルタB４０６、C４０７をロードした１つのフィルタ制御部４０４のサービスカタログである。
【００３６】
図８（Ｂ）は、あるコンポーネントA７０２の起動モードがホットスタンバイに指定されているとした場合を例示する。プロセス情報管理部４０３は自身が起動すると、サービスカタログ７０１を参照し、起動モードがホットスタンバイに指定されているコンポーネントA７０２を検索する。次にプロセス情報管理部４０３は、サービスカタログ７０１からコンフィギュレーションファイルパス８０６を、起動引数に与えてコンポーネントA７０２をプロセスとして起動させる。コンポーネントA７０２が起動し、コントロールバス４１０に接続する時点でユニークなID（識別情報）を与えられる。このIDとしては、例えばGUID（Globally Unique Identifier）を用いる。コンポーネントA７０２はコンフィギュレーションファイルパス８０６からコンフィギュレーションファイル７０３を参照して必要な初期値等を取得し、初期値を使って自身を初期化する。
【００３７】
図８（Ｃ）にて、コンポーネントA７０２がサービスを提供する為に、TCP/IPのポートを取得しサービスI/F７０４の待ち受けを開始した状態を示す。コンポーネントA７０２は、他のコンポーネントへのサービスの提供の準備ができたため、コントロールバス４１０に自身のアドバタイズメッセージ７０５を作成して送信する。アドバタイズメッセージ７０５には、コンポーネントA７０２の名称、ID、バージョン、サービスI/F７０４のエンドポイント（アドレス、ポート番号）が記載されている。このメッセージがプロセス情報管理部４０３宛てに送信される。アドバタイズメッセージ７０５の送信は、コンポーネントが自身の起動完了とサービス提供開始を宣言するために行われる。アドバタイズメッセージ７０５を受信したプロセス情報管理部４０３は、コンポーネントA７０２の起動を確認し、かつサービスI/F７０４のエンドポイントを取得することができる。
【００３８】
図８（Ｄ）は、プロセス情報管理部４０３がコンポーネントA７０２からのアドバタイズメッセージ７０５を受信し、以降の管理の為に管理テーブルであるサービスインベントリ７０６に登録を行った様子を表している。
図１０（Ａ）および（Ｂ）は、サービスインベントリ７０６の内容を模式的に表した図である。図１０（Ａ）は、図９（Ａ）で説明したフィルタ制御部４０４のサービスインベントリ７０６を示す。図１０（Ｂ）は、図９（Ｂ）で説明したフィルタ制御部４０４のサービスインベントリ７０６を示す。エントリ９０１はサービスインベントリ７０６のエントリである。コンポーネントプロセスごとにエントリ９０１が存在する。プロセス情報管理部４０３は、アドバタイズメッセージ７０５を受け取った時点で、サービスインベントリ７０６内にそのメッセージの送信元であるコンポーネントプロセスのエントリを作成する。そして、プロセス情報管理部４０３はエントリ９０１内にメッセージの内容を記載する。具体的には、ID９０２、名称９０３、バージョン９０４、エンドポイント９０５（アドレスおよびポート番号）が記載される。状態９０６には、プロセス情報管理部４０３が、後述するステートチェンジメッセージを受け取った際にコンポーネントプロセスの状態を記録する。状態９０６は「アイドリング」または「ビジー」という値をとり得る。「アイドリング」は、当該コンポーネントプロセスが処理受け付け可能な状態である。「ビジー」は、当該コンポーネントプロセスが処理受け付け不可能な状態である。各コンポーネントプロセスが起動する際には「アイドリング」状態で起動する。「ビジー」状態に関しては図８（Ｇ）を参照して後述する。
【００３９】
図８（Ｅ）は、コンポーネントA７０２がコンポーネントB７０９を利用しようとして、プロセス情報管理部４０３に対してクエリメッセージ７０８を送信した状態を示す。クエリメッセージ７０８には、コンポーネントB７０９の名称と利用したいバージョンが記載されている。あるコンポーネントは複数のバージョンが作成され得る。同一の名称のコンポーネントが機能の違いにより、複数作成されて異なるバージョンとして市場にリリースされる。従ってコンポーネントA７０２はバージョン“2.0.0.1”のように、自身が利用したいコンポーネントB７０９のバージョンを指定してクエリ要求を行うことができる。特定バージョンを利用する必要が無い場合には、バージョン欄は空欄で指定される。図８（Ｅ）に示す時点でコンポーネントB７０９はまだ生成されていない為、プロセス情報管理部４０３はコンポーネントB７０９を新たに生成する。図８（Ｂ）〜（Ｄ）で示したコンポーネントA７０２の生成手順と同様に、コンポーネントB７０９が生成される。プロセス情報管理部４０３におけるクエリの処理の詳細については、図１１を用いて後述する。
【００４０】
図８（Ｆ）は、プロセス情報管理部４０３がクエリに対するレスポンスをコンポーネントA７０２にクエリレスポンスメッセージ７１０として返信する状態を示す。クエリレスポンスメッセージ７１０には、コンポーネントB７０９の名称、バージョン、サービスI/Fを示すエンドポイントが含まれている。
図８（Ｇ）は、クエリレスポンスメッセージ７１０を受け取ったコンポーネントA７０２が取得したコンポーネントB７０９のサービスI/F７１１を利用する状態を示す。コンポーネントによっては、サービスI/Fにアクセスして来る他のサービスからのサービス要求を同時に扱えるものと、そうでないものが存在する。例えば、ログ出力部４０８は複数のサービスからのログデータを同時並行的に受け取ってログファイルに記録していく能力を有する。一方、パイプラインを構成してジョブを変換するフィルタは同時並行処理の能力をもたない。従って、コンポーネントB７０９が同時並行処理の能力を持たないコンポーネントである場合、コンポーネントA７０２がアクセスしてきた時点で他のコンポーネントからの要求を受け付けられないビジー状態に遷移する。
【００４１】
ビジー状態は、コンポーネントA７０２が明示的なアクセス終了を、サービスI/Fを通じてコンポーネントB７０９に宣言するまで継続する。コンポーネントB７０９はビジー状態に遷移したら、自身をクエリで検出されないようにする必要がある。図８（Ｈ）に示すように、コンポーネントB７０９はステートチェンジメッセージ７１２をプロセス情報管理部４０３に対して送信する。ステートチェンジメッセージ７１２には、コンポーネントB７０９がビジー状態に遷移したことが記載されている。ステートチェンジメッセージ７１２を受け取ったプロセス情報管理部４０３は、サービスインベントリ７０６のコンポーネントB７０９のエントリを検索し、その状態９０６を「ビジー」状態に変更する。コンポーネントB７０９の状態９０６が「ビジー」状態に変更されると、プロセス情報管理部４０３は以降、名称を指定したクエリを受け取ったとしても、そのコンポーネントB７０９のプロセスを選定することはなくなる。ただし、サービスインベントリ７０６には、他のコンポーネントBのプロセスが複数存在している可能性がある。それらのいずれかがビジー状態でなければ「利用可能なコンポーネントB」としてクエリの発行元のコンポーネントに返信される。複数の同一名称およびバージョンを持ったコンポーネントプロセス群から、どのプロセスをクエリの結果として選択するのかに関しては、例えば最初に発見されたプロセスを返信する方法がある。または、コンポーネントプロセスごとに、クエリ発行元のコンポーネントに返信された回数をカウントしておき、最もカウント値の低いプロセスを返信する方法を採用してもよい。
【００４２】
次に、図１１のフローチャートを参照して、クエリ処理の詳細を説明する。
Ｓ１００１でプロセス情報管理部４０３は、他のコンポーネントからクエリ要求を受け付ける。クエリには、コンポーネントの名称と、利用したいバージョンが含まれている。Ｓ１００２でプロセス情報管理部４０３は、サービスカタログ７０１を探索し、Ｓ１００１で受け付けたコンポーネント名とバージョンに対応するエントリ８０１が存在するか否かを判定する。当該エントリ８０１がサービスカタログ７０１に存在すると判定された場合、Ｓ１００３に処理を進めるが、存在しなければＳ１００７に移行する。
【００４３】
Ｓ１００３でプロセス情報管理部４０３はジョブ受け付け可能なコンポーネントプロセスが存在するか否かを判定する。プロセス情報管理部４０３は、サービスインベントリ７０６を探索し、Ｓ１００１で受け付けたコンポーネント名とバージョンに対応するエントリ９０１を探索する。そして、状態９０６が「アイドリング」であるコンポーネントプロセスが１つ以上存在するか否かを判定する処理が実行される。状態９０６が「アイドリング」であるコンポーネントプロセスが存在する場合には、Ｓ１００４に処理を進め、存在しなければＳ１００５に移行する。
【００４４】
Ｓ１００４でプロセス情報管理部４０３は、クエリ要求元に対して、要求のあったコンポーネントプロセスのエンドポイントを通知する。Ｓ１００４にて、検出されたコンポーネントプロセスのうちの１つについてクエリ要求元にエンドポイントを通知する処理が実行される。その際、最初に検出されたコンポーネントプロセスを返すように構成してもよい。または、コンポーネントプロセスごとに、何回クエリ要求元にエンドポイントを返したかを、サービスインベントリ７０６に記憶しておき、最も回数の少ないコンポーネントプロセスを返すように構成してもよい。
【００４５】
Ｓ１００５でプロセス情報管理部４０３は、クエリ要求のあったコンポーネントをプロセスとして起動する。次のＳ１００６でプロセス情報管理部４０３は、Ｓ１００５で起動したコンポーネントプロセスからアドバタイズメッセージ７０５を受け付ける。この処理後にＳ１００４に進み、Ｓ１００５で起動したコンポーネントプロセスをクエリの要求元に通知する。なお、図１１には記載していないが、アドバタイズメッセージ７０５が規定時間内にプロセス情報管理部４０３に到着しない場合、エラーと判別し、Ｓ１００７に進んでもよい。Ｓ１００７にて、プロセス情報管理部４０３はクエリ要求元に対してエラーを通知する。
【００４６】
以上に説明した、データ変換サービスの処理の基本的な流れを踏まえて、ジョブを実行する処理について、図１２のフローチャートを参照して説明する。
まず、ジョブ処理受け付け部４０１は入力データを受け付け、入力データをジョブ制御部４０２に送信する（Ｓ１１０１）。ジョブ制御部４０２は処理に必要なフィルタを特定する。本実施形態では、プロセス情報管理部４０３が起動させるプロセスを、フィルタA４０５、フィルタB４０６、フィルタC４０７、として説明する。ジョブ制御部４０２は、上記３つのフィルタを同一のプロセスで動作させたフィルタ制御部４０４に関し、プロセス情報管理部４０３に対してクエリを行う。クエリを受け付けたプロセス情報管理部４０３は、要求されたフィルタを起動させ、ジョブ制御部４０２はパイプラインを生成する（Ｓ１１０２）。これは図４（Ｂ）、図７で説明したパイプラインである。
【００４７】
次に、ジョブ制御部４０２は構築したパイプラインを用いて、「ログ出力なし」として、ジョブの実行をフィルタ制御部４０４に指示する。指示の方法としては、チケット（変換処理用の設定値等をまとまりのある形式に束ねた構造をもつデータ群）内に記述する方法等があるが、通知の方法は特に問わない。ジョブ制御部４０２は各フィルタを用いて、ログ出力なしでジョブを実行する（Ｓ１１０３）。
ジョブ制御部４０２は、ジョブが正常に実行されたかどうかを判断し（Ｓ１１０４）、判断結果に応じて３つに分岐して処理を切り替える。ジョブが正常に終了した場合、Ｓ１１０９へ移行し、クラッシュが発生した場合、Ｓ１１０７へ移行し、クラッシュ以外のエラーが発生した場合にはＳ１１０５へ移行する。
Ｓ１１０５でジョブ制御部４０２は、エラーが発生したフィルタを特定する。エラーが発生した場合、各フィルタがジョブ制御部４０２へエラーが発生したことを通知することで、ジョブ制御部４０２はエラーが発生したフィルタを特定できる。
【００４８】
次に、ジョブ制御部４０２はＳ１１０５で特定したフィルタに対してのみ、「ローカルログ出力あり（ローカルログ出力部４１１にてログを出力させるための指示）」として、ジョブの実行を指示する。この指示については、チケット内に記述する等の方法をとる（Ｓ１１０６）。その後、Ｓ１１０９に処理を進める。
Ｓ１１０４にてクラッシュが発生したと判断する方法は、各コンポーネント間（各プロセス間）において互いにパイプラインの切断を検知することにより問題の起きたコンポーネントを特定することで実現することができる。具体的には、プロセス間、例えばジョブ制御部４０２とフィルタ制御部４０４との間で定期的に生存確認のためのパケットを送り合う。パケットが途絶えたことをタイムアウトにより検知し、クラッシュが発生したことを把握できる。例えば、フィルタ制御部４０４からのパケットが途絶えた場合、ジョブ制御部４０２はフィルタ制御部がクラッシュしたと判断することができる。この場合、ジョブ制御部４０２は、複数のフィルタ（本例では３つのフィルタ）に対応する各フィルタ制御部４０４に関し、それぞれプロセス情報管理部４０３に対してクエリを行う。そして、クエリを受け付けたプロセス情報管理部４０３は、要求されたフィルタを起動させ、ジョブ制御部４０２はパイプラインを生成する（Ｓ１１０７）。これは図４（Ａ）、図６で説明したパイプラインである。
【００４９】
Ｓ１１０８にてジョブ制御部４０２は、Ｓ１１０５で特定したフィルタに対してのみ、「ログ出力あり（ログ出力部４０８にてログを出力させるための指示）」として、ジョブ実行を指示する。この指示については、チケット内に記述する等の方法をとる。その後、Ｓ１１０９に処理を進める。
Ｓ１１０９にて、ジョブ制御部４０２は後処理を実行して処理を終了する。後処理とは、具体的には、パイプラインの破棄や、プロセス情報管理部４０３に「アイドリング」状態への変更通知を行う処理である。プロセス情報管理部４０３は「アイドリング」状態への変更通知を受け取り、サービスインベントリ７０６において当該コンポーネントプロセスの状態９０６を「アイドリング」に変更する。
【００５０】
本実施形態に係る情報処理装置は、複数のフィルタを動作させてパイプライン処理を行う場合に、少なくとも第１モードおよび第２モードを有する。つまり、第１モードは、複数のフィルタを同一のプロセスで動作させ、かつログデータを出力しないモードである。第２モードは、第１モードで複数のフィルタを用いた処理が正常に終了しなかった場合、複数のフィルタを複数のプロセスで動作させ、かつログデータを出力するモードである。第１モードで複数のフィルタを実行する実行手段と、第２モードで複数のフィルタを再実行する再実行手段については同一の手段でもよいし、または異なる手段でもよい。
このように第１モードではログデータを出力しないが、同一のプロセス内でフィルタを動作させることにより、処理の高速性を維持できる。また、エラー発生時には、第２モードにてジョブを再実行してログデータを出力させることが可能となる。クラッシュ時にはフィルタを別プロセスで動作させ、かつ、別プロセスで動作するログ出力機構を用いることで、再実行時に安定してログデータを取得することができる。
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００５１】
４０２  ジョブ制御部
４０３  プロセス情報管理部
４０４  フィルタ制御部
４０５，４０６，４０７  フィルタ
４０９  ローカルログ出力部
【図１】
2015130075.tif 000003
【図２】
2015130075.tif 000004
【図３】
2015130075.tif 000005
【図４】
2015130075.tif 000006
【図５】
2015130075.tif 000007
【図６】
2015130075.tif 000008
【図７】
2015130075.tif 000009
【図８】
2015130075.tif 000010
【図９】
2015130075.tif 000011
【図１０】
2015130075.tif 000012
【図１１】
2015130075.tif 000013
【図１２】
2015130075.tif 000014