JP2015125740A - 情報処理装置、情報処理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】 出力用の画像データを生成する情報処理装置において、一つのフィルターのデータ変換の不具合により、データ変換全体に不具合が波及する可能性を低くすることを目的とする。
【解決手段】 画像を生成するための入力データを取得する取得手段と、
前記入力データを第一のプロセスで起動された第一のデータ変換フィルターでデータ変換して中間データを生成し、当該中間データを前記第一のプロセスとは異なる第二のプロセスで起動された第二のデータ変換フィルターでデータ変換して画像データを生成する変換手段と、前記画像データを出力する出力手段と、を有することを特徴とする。
【選択図】 図７

Description

本発明はデータを変換する情報処理装置、情報処理方法およびコンピュータプログラムに関する。

ユーザー端末（クライアント）からのリクエストに基づいてＷｅｂサービス（サーバー）が印刷データを生成し、その印刷データをプリンターが受信し、印刷を実行する「クラウドプリントサービス」と呼ばれるＷｅｂサービスが登場してきている。クラウドプリントサービスは、ユーザー端末にプリンター制御用のデバイスドライバプログラム（プリンタードライバー）をインストールする必要がなく、また、自分の要求する印刷がどこからでも依頼できるため、今後さらなる広がりを見せると考えられる。

クラウドプリントサービスを実現するためには、クラウド上で、印刷対象のドキュメントデータから各種プリンターに対応する印刷データへのデータ変換が必要となってくる。そこで、ＰＣ（パーソナルコンピュータ）などのユーザー端末で使用していたようなプリンタードライバーをクラウド上のサーバーにそのまま配置し、利用するプリンターに対応したプリンタードライバーによってデータ変換を行う方式がある。

しかし、複数のプリンタードライバーをクラウド上に置く場合、それぞれのプリンタードライバーは内部処理が共通していることが多いため、共通部分について重複してクラウドに保持することになる。そのため、プリンタードライバーを構成する機能を共通化（以降の説明では共通化した機能をフィルターとする）し、共通化した機能を組み合わせてデータ変換サービスを提供する方式が考えられる。

特許文献１には、入力データの変換を行うための複数のデータ変換フィルターを組み合わせて、プリンタードライバーの機能を実現することが開示されている。

特願２０１３−０９３８９０号公報

クラウド上におけるデータ変換処理の方法として、シングルプロセスで行う方法とマルチプロセスで行う方法と、がある。ここで、プロセスとは、ＯＳがコンピュータプログラムの処理を行う処理単位である。シングルプロセスで行う方法は、複数のデータ変換の処理を単一のプロセス内で行う方法である。一方、マルチプロセスで行う方法は、複数のデータ変換それぞれを、複数のプロセスに分けて行う方法である。

シングルプロセスによる処理は、マルチプロセスによる処理よりも一般に高いパフォーマンスを得ることができる。マルチプロセスの場合、プロセス間でデータをやり取りする場合にプロセス間通信が必要となるが、シングルプロセスの場合、プロセス間通信を行わずに、コンポーネント間の関数呼び出しやメモリのやり取りで済ませることができ、処理が高速になるからである。また、シングルプロセスはマルチプロセスよりも設計がシンプルになり、設計、実装の工数としても少なくすることができる。

特許文献１には、複数のデータ変換フィルターを組み合わせてプリンタードライバーの機能を実現する技術が開示されている。この複数のデータ変換フィルターの組み合わせによるデータ変換は、通常、上記の理由によりフィルター＆パイプラインの構造のシングルプロセスで行われる。

しかしながら、「クラウドプリントサービス」では２４時間３６５日に渡ってサービスを提供する必要があるため、その可用性が重視されるという面がある。

例えば、シングルプロセスで設計、実装を行った場合、いずれかのデータ変換のコンポーネントがクラッシュやハングアップに陥った場合に、システム（ユーザーシステム）全体を巻き込んでしまうことがある。システム全体を巻き込んでしまうと、データ変換モジュール全体がクラッシュまたはハングアップして、異常終了してしまうという可能性がある。ここで、ハングアップとは、無限ループ、デッドロック、無限再帰、循環参照などを原因として、ソフトウェアからの反応が停止した状態のことである。

また、異常終了の後、システムを再起動するための別なソフトウェアが必要となることもある。さらに、たとえ再起動できるとしても再起動するまでユーザーシステムが処理を行えないという課題もある。特に、データ変換フィルターの１つに品質の検証が十分でないソフトフェアが混じっていると、たびたびクラッシュまたはハングアップするという課題がある。

さらに、全体がクラッシュやハングアップすることによりログが取得できず障害解析が困難になるといった課題がある。

本願発明は、上記課題を鑑みてなされたものであり、画像データを生成する情報処理装置において、一つのデータ変換の不具合により、データ変換全体に不具合が波及する可能性を低くすることを目的とする。

画像を生成するための入力データを取得する取得手段と、前記入力データを第一のプロセスで起動された第一のデータ変換フィルターでデータ変換して中間データを生成し、当該中間データを前記第一のプロセスとは異なる第二のプロセスで起動された第二のデータ変換フィルターでデータ変換して画像データを生成する変換手段と、前記画像データを出力する出力手段と、を有することを特徴とする。

本発明によれば、出力用の画像データを生成する情報処理装置において、一つのデータ変換の不具合により、データ変換全体に不具合が波及する可能性を低くすることができる。

実施例１におけるクラウドプリントサービスのシステム構成図である。 実施例１における印刷データ変換サービスが動作するサーバーＰＣのハードウェア構成図である。 実施例１におけるサーバーＰＣ上で動作するソフトウェアを説明するブロック図である。 実施例１における印刷データ変換サービスと関連するコンポーネント群を示す構成図である。 実施例１におけるフィルターの種類および並び順を定義した設定ファイルの例である。 実施例１におけるフィルターンドパイプラインによる処理の流れを示したシーケンス図である。 実施例１におけるコンポーネント間のメッセージのやりとりを示した模式図である。 実施例１におけるサービスカタログの構成を示す模式図である。 実施例１におけるサービスインベントリーの構成を示す模式図である。 実施例１におけるクエリーの処理の流れを示したフローチャートである。 実施例１におけるフィルターがクラッシュした場合の処理の流れを示した図である。 実施例１におけるフィルターがハングアップした場合の処理の流れを示した図である。 実施例２におけるログ出力部を２つのグループで共有する場合の構成図である。 実施例２におけるログ出力部を個々のグループに割り当てる場合の構成図である。 実施例２における接続情報を割り当てる処理の流れを示した図である。 実施例２における接続情報が記載された設定ファイルの例である。 実施例２におけるジョブ制御部に接続情報を割り当てる処理の流れを示した図である。 実施例３におけるログ出力部を個々のグループに割り当てる場合の構成図である。 実施例３におけるグループ生成の処理の流れを示した図である。 実施例３におけるグループ削除の処理の流れを示した図である。 実施例４における印刷データ変換サービスと関連するコンポーネント群を示す構成図である。 初期値としてデータ変換フィルターに低い信頼度を設定したテーブルを示す図である。 データ変換フィルターに稼働実績が蓄積した後のテーブルを示す図である。 フィルター制御部の個数、各フィルターがロードされるフィルター制御部名の決定方法の模式図を示す図である。 フィルター制御部の個数、各フィルターがロードされるフィルター制御部名の決定方法のフローチャートを示す図である。 フィルターがクラッシュした場合の処理の流れを示した図である。 フィルターがハングアップした場合の処理の流れを示した図である。 サービス開始初期に正常終了する場合のデータ変換処理の流れを示したシーケンス図である。 稼働実績蓄積後に正常終了する場合のデータ変換処理の流れを示したシーケンス図である。 稼働実績を格納したテーブルを示す模式図である。 実施例５におけるサービス開始初期に正常終了する場合のデータ変換の処理の流れを示したシーケンス図である。 実施例５におけるフィルターがクラッシュした場合の処理の流れを示した図である。 実施例５におけるフィルターがハングアップした場合の処理の流れを示した図である。 稼働実績を格納したテーブルの変形例を示す図である。

（実施例１）
本実施例では、複数のデータ変換フィルターを用いたデータ変換の内、少なくとも一つのデータ変換処理を構成するコンポーネントを別プロセスとして起動し、実行する方法について説明する。

データ変換処理を構成する各コンポーネントを別プロセスとして起動することにより、クラッシュやハングアップが発生したとしても、システムを巻き込むことがなくなる。そのため、システムを再起動するための特別なソフトウェアも不要となる。図１は、複数の情報処理装置から構成される、本実施例におけるクラウドプリントサービスのシステム構成図である。クラウドプリントサービスとは、クライアントコンピュータなどの端末機器からの依頼に応じて、サーバー上のデータ変換サービスの変換により印刷用の画像データを生成するサービスである。生成された印刷用の画像データは、ネットワーク接続されたプリンターに出力され、印刷される。

印刷データの変換を依頼する依頼者１０１は、印刷データの変換要求を送出する機器として、パーソナルコンピュータ１０２、タブレットＰＣ１０３や携帯端末１０４などの機器を利用する。これらの機器は、依頼者１０１からの操作を受け付け、ネットワーク１０５上のサーバーに存在する印刷データ変換サービスに対して印刷データの変換を依頼する。印刷データ変換サービスはサーバーＰＣ１０６上で特定のＵＲＬを公開しているＷｅｂサービスとして動作しているプログラムである。サーバーＰＣ１０６上では前記ＵＲＬに対して到着した依頼を印刷データ変換サービスに転送するＷｅｂサーバーも動作している。一般的にＵＲＬへ到着する依頼は通常多数になるため、単一のサーバーＰＣ１０６では処理させず、複数のサーバーＰＣ１０６に処理させる構成になる。従って、複数のサーバーＰＣ１０６の前段にロードバランサー１０７を設置し、サーバーＰＣ１０６それぞれに転送される依頼が均一に配分されるように構成する。

印刷データ変換サービスが提供するサービスは、依頼者１０１から受け付けたデータをプリンター１０８で印刷できる形式に変換することである。依頼者１０１から受け付けるデータにはドキュメント、画像ファイルなど各種のアプリケーションプログラムで作成されたフォーマットが存在する。一方、プリンター１０８が印刷データとして受け付けるデータは前述のフォーマットとは異なり、ＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）で記述されたデータや、印刷部数等の印刷を制御するための印刷用の画像データとなっている。このように、依頼者１０１とプリンター１０８の間には扱うデータ形式の差異が存在する為に、その差異を埋めるプログラムが必要とされる。通常この変換処理を行うのがプリンタードライバーと呼ばれるプログラムである。プリンタードライバーは依頼者１０１が操作する前述のアプリケーションプログラムが動作しているＰＣ上で動作させることが通常である。しかし、プリンタードライバーの処理は、ＣＰＵ、メモリなどのリソースを多く必要とする重い処理であるため、依頼者１０１の操作するＰＣの保持するリソースが少ない場合には印刷処理が実用的でなくなる程時間のかかる処理になってしまう。タブレットＰＣ１０３や携帯端末１０４といった、リソースの比較的少ない端末からの印刷の需要が高まるにつれプリンタードライバーの処理をインターネット上のサーバーサービスで行わせることの重要性が増している。

前述のパーソナルコンピュータ１０２、タブレットＰＣ１０３、携帯端末１０４は、依頼者１０１からの指示を受け付け、前述のＵＲＬに対して印刷データをプリンター１０８で印刷できる形式に変換するように依頼を行う。依頼に応じてサーバーＰＣ１０６上で動作している印刷データ変換サービスが生成した変換後のデータは前述の端末に対して返送される。依頼者１０１から受け付ける指示によっては変換後のデータは印刷データ変換サービスがアクセス可能なファイルサーバＰＣ１０９で保管される場合もある。

＜ハードウェア構成＞
図２は印刷データ変換サービスをはじめとするソフトウェア群が動作するサーバーＰＣ１０６のハードウェア構成図である。

印刷データ変換サービスはＯＳ（オペレーティングシステム）上で動作するアプリケーションプログラムであり、ＨＤＤ２０２あるいはＲＯＭ２０３に格納されている。ＣＰＵ２０５がＯＳとアプリケーションプログラムをＨＤＤ２０２あるいはＲＯＭ２０３から読み出してＲＡＭ２０４にロードし、実行することで様々な処理が進行し印刷データ変換サービスとしての機能を実現する。処理結果はファイルとしてＨＤＤ２０２に格納され、あるいはデータとしてＲＡＭ２０４に記憶される。アプリケーションプログラムはコンピュータに接続されている入力装置２０７から使用者の入力、各種センサの読み取り値を取得する。さらに、出力装置２０６に対して情報を出力し、処理結果を表示する。さらに、通信装置２０８を介してネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウェアはバス２０１で互いに接続されていてアプリケーションプログラムから操作できるように構成されている。

＜ソフトウェア構成＞
図３は、印刷データ変換サービス３０１を含むソフトウェア群がサーバーＰＣ１０６上でどのように構成されているかを示すブロック図である。Ｗｅｂサーバー３０２は依頼者１０１が操作したパーソナルコンピュータ１０２上のアプリケーションからＨＴＴＰプロトコルで送信されたリクエストを受け取る。ロードバランサー１０７はＷｅｂサーバー３０２の前段に位置し、Ｗｅｂサーバー３０２の処理負荷などに基づいて、複数のサーバーＰＣ１０６上で動作しているＷｅｂサーバー３０２それぞれに対して受け取ったリクエストを振り分ける。この振り分ける方式は種々知られているが、ここでは説明を省略する。

ここで、サーバーＰＣ１０６は必ずしも物理的な一台のサーバーＰＣを意味する必要はない。現時点で単一のＰＣ上に複数の仮想的なＰＣを出現させる仮想化技術が一般的となっており、ソフトウェアからみれば自身が動作しているオペレーティングシステムが仮想的に作り出されたものか否かは判別がつかないか、あるいは判別する必要がない。

従って、本実施例におけるサーバーＰＣ１０６は「場合によっては仮想化されたＰＣ」を意味する場合もある。本記載以降、「ＰＣ」という表現は物理的なＰＣと仮想化されたＰＣの両方を意味するものとして扱う。

アプリケーションサーバー３０３は、要求の送付先として指定されたＵＲＬを解析し、関連つけられている印刷データ変換サービス３０１を決定する。印刷データ変換サービス３０１は、入力データを複数のデータ変換フィルターを用いてデータ変換し、出力用（印刷用）の画像データを生成するサービスである。尚、印刷データ変換サービス３０１の詳細な処理については、後述する。通常、Ｗｅｂサーバー３０２とアプリケーションサーバー３０３は複数種のサービスを扱うことが可能であり、ＵＲＬから対応するサービスを特定して要求を振り分けることができる。本実施例では、その複数種のサービスの一つが印刷データ変換サービス３０１である。通常、このサービスの他にもサービスは稼働しているが、本実施例の説明においては、印刷データ変換サービス３０１以外のサービスは省略する。

印刷データ変換サービス３０１は、サーバーＰＣ１０６で動作するＯＳ上のプロセスとして動作する。アプリケーションサーバー３０３は複数の要求を並列実行させるために、印刷データ変換サービス３０１を複数起動し、各々に要求を振り分ける。

アプリケーションサーバー３０３はさらに、依頼者１０１からの一連の要求を特定する為のセッションを管理する。具体的には、同一の依頼者１０１からの要求は同一の印刷データ変換サービス３０１に転送するセッション・アフィニティーを実現している。

＜印刷データ変換サービス＞
図４は、印刷データ変換サービス３０１が依頼された印刷データを変換する際に利用するソフトウェアコンポーネント群およびその関連を説明する図である。なお、以下ではプロセスとして起動したコンポーネントのことを「コンポーネントプロセス」と記載する。

印刷データ変換サービス３０１は、先に説明したようにプロセスとして動作している。

以下に、図４を用いて、印刷データ変換サービス３０１が利用するソフトウェアコンポーネントそれぞれの概要について説明する。

＜ジョブ処理受け付け部４０１＞
ジョブ処理受け付け部４０１は、データを取得する取得手段として機能し、印刷データ変換サービスから処理対象のデータ一式を受け取るコンポーネントである。この処理対象のデータ一式をジョブと呼ぶ。ジョブは、変換されるべき対象データ（入力データ）と、変換処理用の設定値などをまとまりのある形式に束ねた「チケット」と呼ばれるデータ構造から構成される。尚、ジョブはネットワーク接続されたクライアントコンピュータなどの端末機器から取得されたものである。

ジョブ処理受け付け部４０１は、後述するジョブ制御部４０２の代理としてロードされる。そして、受け取ったジョブに基づき、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）で提供している関数群を呼び出すことで変換処理の実行を依頼する。変換処理後、変換処理の実行結果を受領する。

＜ジョブ制御部４０２＞
ジョブ制御部４０２は、ジョブ処理受け付け部４０１を介してジョブ実行を依頼され、ジョブに含まれている「ジョブ種別情報」をもとに、変換に必要なフィルターを選定するコンポーネントである。ジョブ制御部４０２は、プロセスとして動作し、ジョブ処理受け付け部４０１からの変換処理の受付の為の通信インターフェイスを保持している。

この通信インターフェイスへのジョブの依頼はＨＴＴＰプロトコルではなく、専用のプロトコルが用いられている。ジョブ処理受け付け部４０１のＡＰＩを呼び出す行為はジョブ制御部４０２が用意している変換処理受付用通信インターフェイスへのプロセス間通信として変換される。すなわち、印刷データ変換サービス３０１にとって変換処理はジョブ処理受け付け部４０１によって実行されているように見える。しかし、実際にはジョブ制御部４０２および後述する複数のフィルター群、およびフィルター群が利用するいくつかのコンポーネントの相互作用によって実現されている。

＜プロセス情報管理部４０３＞
プロセス情報管理部４０３は、各コンポーネントをプロセスとして起動する責務を担っているコンポーネントである。プロセスの起動は、起動可能なプロセス数、プロセスごとの常時起動の要否などからなるプロセス起動条件に基づき行われる。よって、プロセス情報管理部４０３は、プロセスの起動条件を取得する起動条件取得手段およびプロセスを起動させる起動手段として機能する。さらに、他のコンポーネントからの求めに応じて別のコンポーネントのエンドポイントを返すという機能を提供する。エンドポイントとはＴＣＰ／ＩＰのリスンポートを指す。あるコンポーネントは別のコンポーネントが公開しているエンドポイントを取得し、そのエンドポイントにアクセスすることでそのコンポーネントが提供するサービスを利用することができる。あるコンポーネントが他のコンポーネントのエンドポイントをプロセス情報管理部４０３に対して問い合わせる動作を“クエリー”と呼ぶ。

図４に示したように、複数種類のコンポーネントがプロセスとして複数存在し、かつ同一コンポーネントも同一ＰＣ上に複数存在する。従って、各コンポーネントが公開するサービスＩ／Ｆのポート番号は固定にすることができず、自ずと動的に生成せざるを得なくなる。動的に生成されたエンドポイントは何らかの管理機構が無くては他から参照することはできない。この管理を担当するのがプロセス情報管理部４０３である。さらに、コンポーネントが、他のコンポーネントが動的に生成したエンドポイントを取得する手段が必要である。この手段がクエリーである。

例えば、ログ出力部４０８は、ロギングデータをログファイルとして記録するサービスを提供し、ジョブ処理受け付け部４０１、ジョブ制御部４０２、フィルター制御部４０４は、このサービスを利用するためにログ出力部４０８のクエリーを行う。同様に、ジョブ処理受け付け部４０１はジョブ制御部４０２をクエリーし、ジョブ制御部４０２はフィルターＡ４０５、フィルターＢ４０６、フィルターＣ４０７をクエリーする。クエリーの処理の流れは、図７、図１０を用いて後述する。

プロセス情報管理部４０３はアプリケーションサーバー３０３が起動した時点で唯一起動している特殊なプロセスである。サーバーＰＣ１０６上で動作しているオペレーティングシステム（ＯＳ）を設定し、ＯＳ起動時に自動的にプロセス情報管理部４０３のプロセスを起動するようにする。

＜フィルター制御部４０４＞
フィルター制御部４０４は、プロセスとして動作し、実行時に指定されたデータ変換用のフィルターをロードするコンポーネントである。データ変換用のフィルターは、データ変換処理のみを実装したライブラリーモジュールの形式で用意されている。フィルター制御部４０４はコントロールバス４１０への接続とメッセージ送受信、ジョブ制御部４０２との通信、フィルターのログ出力のログ出力部４０８への転送などの処理を担当する。

フィルター制御部４０４は、第一のデータ変換フィルターとして機能するフィルターＡ４０５、第二の変換フィルターとして機能するフィルターＢ４０６、第三の変換フィルターとして機能するフィルターＣ４０７のデータ変換を制御する。第一のデータ変換フィルターのデータ変換により生成された中間データは、第二のデータ変換フィルターによりデータ変換され、第二のデータ変換フィルターのデータ変換により生成された中間データは、第三のデータ変換フィルターによりデータ変換される。フィルター制御部４０４のデータ変換により生成されたデータは、印刷用の画像データとなる。

＜ログ出力部４０８＞
ログ出力部４０８は、各コンポーネントがネットワークを介して送信したログを取得し、取得したログを蓄積するコンポーネントである。ログ出力部４０８は、プロセスとしてコントロールバス４１０上に最低一つは存在する。各コンポーネントはログデータをログ出力部４０８に対してネットワークを介して送信し、ログ出力部４０８が一定量のログデータが蓄積した時点でログファイルに出力する。ログデータを蓄積せずに逐次ログファイルに出力するようにしてもよい。

ログファイルの出力パス等の設定はログ出力部４０８が起動される際に渡されるコンフィギュレーションファイルで指定される。コントロールバス４１０上のコンポーネントはジョブの実行中にログ出力を行うが、それぞれのコンポーネントで個別にログ出力部を持ってしまうと、ログファイルがコンポーネントごとに分かれてしまい、ログの解析が困難となってしまう。そこで、本実施例では、ログ出力部４０８が一括してログファイルへの出力を行うようにしている。

＜コントロールバス＞
コントロールバス４１０は、上記の各コンポーネント間の通信チャネルである。このチャネルには、例えば、クエリー要求、クエリー要求に対するレスポンス、ハートビート、コンポーネントプロセスの状態変更通知などのメッセージが流れる。

コントロールバス４１０は、マルチキャスト通信を利用する。各コンポーネントプロセスは、同一のマルチキャスト用アドレスおよびポートを指定してコントロールバスに参加する。コントロールバスに参加しているコンポーネントがメッセージを流すと、参加している全コンポーネントプロセスにメッセージが届けられる。

＜データ変換処理の概要＞
次に、本実施例におけるデータ変換処理の概要について説明する。

まず、ジョブ処理受け付け部４０１を介してジョブ実行を依頼されたジョブ制御部４０２は、ジョブに含まれている「ジョブ種別情報」をもとに、変換に必要なフィルターを選定する。必要なフィルターの組み合わせとその並び順は、例えば設定ファイルとしてジョブ制御部４０２で保持する。

図５は、必要なフィルターの組み合わせとその並び順を記載するための設定ファイルの例である。要素５０１はジョブ種別情報を記載するための要素である。ｉｄ属性でジョブ種別情報を指定する。要素群５０２はフィルターの組み合わせと並び順を記載するための要素である。ｎａｍｅ属性でフィルターの種類を記載し、ｖｅｒｓｉｏｎ属性でどのバージョンのフィルターを使うのかを記載する。要素群５０２は、要素の記載順でフィルターの並び順を規定する。要素群５０２の例では、フィルターＡ、フィルターＢ、フィルターＣの順で処理が行われる。ジョブ制御部４０２は、ジョブに含まれているジョブ種別情報と一致する要素５０１を探索し、一致する要素５０１の下に書かれているフィルターの組み合わせと並び順を採用する。

なお、必要なフィルターの組み合わせとその並び順は、ジョブ種別情報の代わりに、印刷データを解析して決定するようにしてもよい。その場合、印刷データの先頭から既定のサイズを読出しその中に含まれている特徴的な内容から印刷データの種類を判定する。

例えば、ＪＰＥＧ形式や、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）形式のデータなどが入力データとして与えられる。次に、ジョブに含まれている変換先の印刷データ形式を取得し、変換元の印刷データ形式と変換先の印刷データ形式の両者が確定した時点で、この変換に必要なフィルター群を選定する。

必要な複数のフィルターを選定したあとはこれらフィルターをロードしているフィルター制御部４０４を取得する。図４の例では変換に必要なフィルターとして、フィルターＡ４０５、フィルターＢ４０６、フィルターＣ４０７が必要であり、それらはそれぞれフィルター制御部４０４にロードされている。

ジョブ制御部４０２はフィルターＡ４０５、フィルターＢ４０６、フィルターＣ４０７との間で、パイプライン４０９と呼ばれるデータ転送チャネルを作成する。プロトコルとしては例えばＴＣＰ／ＩＰを用いる。パイプライン４０９は片方向にのみデータを転送する。ジョブ制御部４０２、フィルターＡ４０５、フィルターＢ４０６、フィルターＣ４０７、ジョブ制御部４０２と一周するようにパイプライン４０９が構成される。また、ジョブ制御部４０２はジョブ処理受け付け部４０１との間にもパイプライン４０９を作成する。このようにパイプライン４０９を作成することで、ジョブ処理受け付け部４０１から印刷データが複数のコンポーネントを還流し、最後に変換が終了した形で再びジョブ処理受け付け部４０１に戻ってくる。以上が、本実施例におけるデータ変換処理の概要である。

＜データ変換処理フロー＞
続けて、図６を用いて、データ変換処理の具体的な処理フローを説明する。

図６は、ジョブ処理受け付け部４０１が印刷データ変換サービス３０１からジョブ処理を受け付けた後の、データ変換処理の概要を示したシーケンス図である。

Ｓ６０１は、ジョブ処理受け付け部４０１がジョブ制御部４０２のクエリー要求を行う処理である。ジョブ処理受け付け部４０１は、プロセス情報管理部４０３にクエリー要求を行い、ジョブ制御部４０２のエンドポイントを取得する。クエリーの処理の流れは図７、図１０を用いて後述する。

Ｓ６０２は、ジョブ処理受け付け部４０１がジョブ制御部４０２に対してジョブ処理依頼を行う処理である。ここで、ジョブのデータが、ジョブ処理受け付け部４０１からジョブ制御部４０２に渡される。ジョブのデータは、前述の通り、変換されるべき対象データ（入力データ）と、変換処理用の設定値などをまとまりのある形式に束ねた「チケット」と呼ばれるデータ構造から構成される。尚、本実施例における入力データは、例えば、ワードプロセッシング用のアプリケーションにより作成された文書データや、ドローイングソフトによって作成された画像データなどである。

受け渡しには、ジョブのデータのパスで渡すようにしても良いし、メモリやプロセス間通信で渡すようにしてもよい。

Ｓ６０３は、ジョブ制御部４０２が、ジョブの内容をもとに、フィルターの種類、並び順を決定し、それらフィルターのクエリー要求を行う処理である。フィルターの種類、並び順に関しては、図５を用いて説明済みである。ジョブ制御部４０２は、プロセス情報管理部４０３に対して、各フィルターに対応するフィルター制御部４０４のクエリー要求を行い、それぞれのエンドポイントを取得する。ここでは、フィルターＡ４０５、フィルターＢ４０６、フィルターＣ４０７の順に処理を行うと決定したものとして説明をする。尚、図４に示したように、フィルターＡ４０５、フィルターＢ４０６、フィルターＣ４０７それぞれのデータ変換処理は、互いに異なるプロセスのフィルター制御部によって処理される。互いに異なるプロセスで処理されることによって、一つのデータ変換フィルターの不具合がデータ変換フィルター全体に波及することを防止することが出来る。

Ｓ６０４は、パイプラインを生成する処理である。ジョブ制御部４０２は、各フィルター制御部４０４に対してパイプラインの生成を指示する。各フィルター制御部４０４は、それぞれ隣り合うコンポーネントプロセスとのパイプラインを生成する。パイプライン生成を完了した後、各フィルター制御部４０４はジョブ制御部４０２にパイプライン生成完了を通知し、各フィルター制御部４０４への入力パイプラインからジョブが流れてくるのを待機する。なお、ジョブ制御部４０２は、各フィルター制御部４０４に対してパイプラインの生成を指示する際に、ジョブ制御部４０２のサービスＩＦのエンドポイントも各フィルター制御部４０４に通知する。フィルター制御部４０４はエラーが起こった際に、このジョブ制御部４０２のサービスＩＦを通じて、ジョブ制御部４０２にエラーを通知する。

Ｓ６０５は、データ変換処理である。ジョブ制御部４０２は、ジョブのデータに含まれる入力データを取得する取得手段として機能し、初段のフィルター制御部４０４に接続されているパイプラインに入力データを送信する。フィルターＡ４０５（第一のデータ変換フィルター）は、フィルター制御部４０４を通じてデータを受け取り、データ変換処理を第一のプロセスで行う。そして、フィルターＡ４０５は、フィルター制御部４０４を通じて、フィルターＢ４０６（第二のデータ変換フィルター）と接続されているパイプラインにデータ（中間データ）を流す。フィルターＢ４０６、フィルターＣ４０７でも同様に、第一のプロセスとは異なる第二のプロセス、第二のプロセスでデータ変換処理が行われる。ここで、各フィルター群は、データ変換を行う変換手段として機能している。最終的に、フィルターＣ４０７から、フィルター制御部４０４を通じて、ジョブ制御部４０２に生成された変換後のデータが出力用の画像データとして送信される。ここで、出力用の画像データとは、例えば、プリンターなどで印刷可能な印刷用のビットマップデータなどである。

Ｓ６０６は、ジョブ制御部４０２が、ジョブ処理受け付け部４０１に対して変換後のデータを返却する処理である。

＜コンポーネントの生成＞
ここでは、コンポーネントの生成について説明する。図７はコンポーネントをプロセスとして生成するシーケンスを説明した図である。

図７（Ａ）ではプロセス情報管理部４０３のみが存在する状況である。この状況は図３においてサーバーＰＣ１０６が起動した直後に相当する。この時点ではまだ印刷データ変換サービス３０１は起動していない想定である。プロセス情報管理部４０３は単独でコントロールバス４１０に参加している状態である。

プロセス情報管理部４０３はサービスカタログ７０１を保持している。サービスカタログ７０１とは、サーバーＰＣ１０６上にインストールされているコンポーネントのリストから構成されているカタログである。サービスカタログ７０１は、例えば、サーバーＰＣ１０６のＨＤＤ２０２にファイルとして保存され、プロセス情報管理部４０３によって読み込まれる。図８にサービスカタログの概念図を示す。

図８において、エントリー８０１は、サービスカタログのエントリーであり、コンポーネントごとに存在する。

コンポーネント名８０２は当該エントリーのコンポーネント名である。

サービスのバージョン８０３は、コンポーネントのバージョンを示す。同一の名前を持つコンポーネントであっても、そのバージョンが異なれば異なる機能を提供するためサービスカタログ７０１上では異なるエントリーとして扱われる。

実行ファイルパス８０４は、コンポーネントの実行ファイルパスを示す。

コンフィギュレーションファイルパス８０５は、コンポーネントをプロセスとして起動したときに、プロセス情報管理部４０３からそのコンポーネントに渡されるコンフィギュレーションファイルのパスである。

コンポーネントの終了条件８０６は、そのコンポーネントのプロセスが終了するための条件を示す。条件は時間やジョブ数で記述する。プロセス情報管理部４０３は、終了条件８０６の内容を起動したコンポーネントプロセスに渡す。終了条件８０６に関しては図７（Ｊ）にて後述する。

起動モード８０７は、コンポーネントプロセスが、オンデマンドで起動するかホットスタンバイさせておくかを示す。起動モード８０７がＯｎｄｅｍａｎｄの場合は、そのコンポーネントを指定したコンポーネントのクエリーがあった場合に当該コンポーネントプロセスを起動する。また、ＨｏｔＳｔａｎｄｂｙの場合はプロセス情報管理部４０３が起動する際に当該コンポーネントプロセスを起動する。

最大起動数８０８は、コンポーネントプロセスが最大何個まで起動できるかを示す。同種のコンポーネントプロセスを複数個起動しておくことで、例えばあるコンポーネントプロセスがクラッシュして再度起動している際に、同種の別のコンポーネントプロセスが処理を受け付けることが可能となる。なお、あるコンポーネントについて、起動モード８０７がＨｏｔＳｔａｎｄｂｙの場合には、プロセス情報管理部４０３が起動する際に、最大起動数８０８分だけのコンポーネントプロセスを起動する。また、あるコンポーネントの起動モード８０７がＯｎｄｅｍａｎｄの場合には、プロセス情報管理部４０３がクエリーを受け付け時に最大起動数８０８を超えない場合にコンポーネントプロセスを起動する。

図７（Ｂ）では、あるコンポーネントＡ７０２の起動モードがホットスタンバイ（ＨｏｔＳｔａｎｄｂｙ）に指定されているとした場合の例を示している。プロセス情報管理部４０３は自身が起動したら、このサービスカタログ７０１を参照し、起動モードがホットスタンバイに指定されているコンポーネントＡ７０２を発見する。次にプロセス情報管理部４０３は、サービスカタログ７０１からコンフィギュレーションファイルパス８０５と終了条件８０６を取得し、起動引数に与えてコンポーネントＡ７０２をプロセスとして起動する。コンポーネントＡ７０２は起動し、コントロールバス４１０に接続する時点でユニークなＩＤを与えられる。このＩＤとしては例えばＧＵＩＤ（Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）を用いる。コンポーネントＡ７０２はコンフィギュレーションファイルパス８０５からコンフィギュレーションファイル７０３を参照し、必要な初期値等を取り出し、その初期値を使って自身を初期化する。

図７（Ｃ）では、コンポーネントＡ７０２はサービスを提供する為に、ＴＣＰ／ＩＰのポートを取得しサービスＩ／Ｆ７０４の待ち受けを開始する。コンポーネントＡ７０２はこれで他のコンポーネントへのサービスの提供の準備ができたため、コントロールバス４１０に自身のアドバタイズメッセージ７０５を作成して送信する。アドバタイズメッセージ７０５にはコンポーネントＡ７０２の名前、ＩＤ、バージョン、サービスＩ／Ｆ７０４のエンドポイント（アドレス、ポート番号）が記載されている。このメッセージがプロセス情報管理部４０３宛てに送信される。アドバタイズメッセージ７０５はコンポーネントが自身の起動完了とサービス提供開始を宣言する行為である。このメッセージの受信によってプロセス情報管理部４０３はコンポーネントＡ７０２の起動を確認し、かつサービスＩ／Ｆのエンドポイントを取得することができる。

図７（Ｄ）は、プロセス情報管理部４０３がコンポーネントＡ７０２からのアドバタイズメッセージ７０５を受信し、以降の管理の為に管理テーブルであるサービスインベントリー７０６に登録を行った様子を表している。

図９はサービスインベントリー７０６の内容を模式的に表した図である。

図９において、エントリー９０１はサービスインベントリー７０６のエントリーである。コンポーネントプロセスごとのエントリー９０１が存在する。プロセス情報管理部４０３は、アドバタイズメッセージ７０５を受け取った時点で、サービスインベントリー７０６内にそのメッセージの送信元であるコンポーネントプロセスのエントリーを作成する。そして、プロセス情報管理部４０３はそのエントリー内にメッセージの内容を記載する。具体的には、ＩＤ９０２、名前９０３、バージョン９０４、エンドポイント９０５に記載される。

生存時間９０６は、コンポーネントプロセスが作成されてからの生存時間（秒数）が記録される。この生存時間は後述するハートビートメッセージ７０７の内容から作成される。

状態９０７には、プロセス情報管理部４０３が後述するステートチェンジメッセージを受け取った際にコンポーネントプロセスの状態を記録する。状態９０７は「アイドリング」「ビジー」「行方不明」という値を取り得る。「アイドリング」は、当該コンポーネントプロセスが処理受け付け可能な状態である。「ビジー」は当該コンポーネントプロセスが処理受け付け不可能な状態である。「行方不明」は当該コンポーネントプロセスが動作しているかどうかが不明な状態である。各コンポーネントプロセスが起動する際には「アイドリング」状態で起動する。「ビジー」状態に関しては図７（Ｈ）、「行方不明」状態に関しては図７（Ｅ）で後述する。

最終連絡時刻９０８は、プロセス情報管理部４０３がコンポーネントプロセスから最後に受け取ったメッセージの受け取り時刻を記録する。この実施例ではオペレーティングシステムから取得したシステム時刻が格納されている。通常、名前とバージョンが同一であるコンポーネントのプロセスは複数生成される。これらのサービスインベントリー７０６上のエントリー９０１は少なくとも互いに、ＩＤとＰｏｒｔ番号が異なった値になるため識別が可能である。

図７（Ｅ）ではコンポーネントＡ７０２からハートビートメッセージ７０７を受け取る状況を説明している。各コンポーネントは定期的にハートビートメッセージ７０７をプロセス情報管理部４０３宛てに送信するよう構成する。プロセス情報管理部４０３はこのメッセージを受け取ることにより送信元コンポーネントの生存を確認し、サービスインベントリー７０６の生存時間９０６と最終連絡時刻９０８を更新する。もし、コンポーネントからのハートビートメッセージ７０７が既定時間滞ると、プロセス情報管理部４０３はこのコンポーネントプロセスの状態９０７を「行方不明」に変更する。この状態でさらに既定時間ハートビートメッセージが滞ると、そのコンポーネントプロセスは自動的にサービスインベントリー７０６上からエントリーごと削除される。サービスインベントリー７０６上から削除されたコンポーネントプロセスはもはや他のコンポーネントからのクエリーに対して検索されなくなり、以てサービスを提供できなくなる。エントリーの削除は対象コンポーネントプロセスのＩＤを基に行われるため同一名称の他のコンポーネントプロセスのエントリーには影響を与えない。

図７（Ｆ）はコンポーネントＡ７０２がコンポーネントＢ７０９を利用しようとしてプロセス情報管理部４０３に対してクエリーメッセージ７０８を送信した様子である。このクエリーメッセージ７０８にはコンポーネントＢ７０９の名前と利用したいバージョンが記されている。あるコンポーネントは複数のバージョンが作成され得る。同一の名前のコンポーネントが機能の違いにより複数作成されて異なるバージョンとして市場にリリースされる。従ってコンポーネントＡ７０２はバージョン“２．０．０．１”の様に自分が利用したいコンポーネントＢ７０９のバージョンを指定してクエリーを行うことができる。もし、特定バージョンを利用する必要が無いならばバージョン欄は空で指定する。図７（Ｆ）の時点ではコンポーネントＢ７０９はまだ生成されていない為、プロセス情報管理部４０３はコンポーネントＢ７０９を新たに生成する。図７（Ｂ）〜（Ｄ）で示したコンポーネントＡ７０２の生成手順と同じようにコンポーネントＢ７０９が生成される。プロセス情報管理部４０３におけるクエリーの処理の詳細は図１０を用いて後述する。

図７（Ｇ）はプロセス情報管理部４０３がクエリーに対するレスポンスをコンポーネントＡ７０２にクエリーレスポンスメッセージ７１０として返却する様子である。クエリーレスポンスメッセージ７１０にはコンポーネントＢ７０９の名前、バージョン、サービスＩ／Ｆを示すエンドポイントが格納されている。

図７（Ｈ）はクエリーレスポンスメッセージ７１０を受け取ったコンポーネントＡ７０２が取得したコンポーネントＢ７０９のサービスＩ／Ｆ７１１を利用する様子である。コンポーネントによってはサービスＩ／Ｆにアクセスして来る他のサービスからのサービス要求を同時に扱えるものとそうでないものが存在する。例えば、ログ出力部４０８は複数のサービスからのロギングデータを同時並行的に受け取りログファイルに記録していく能力を有する。一方、パイプラインを構成してジョブを変換するフィルターは同時並行処理の能力をもたない。従って、コンポーネントＢ７０９が同時並行処理能力を持たないコンポーネントであるとすると、コンポーネントＡ７０２がアクセスしてきた時点で他のコンポーネントからの要求を受け付けられない状態すなわちビジー状態に遷移する。この状態はコンポーネントＡ７０２が明示的なアクセス終了をサービスＩ／Ｆを通じてコンポーネントＢ７０９に宣言するまで継続する。コンポーネントＢ７０９はビジー状態に遷移したら、自身をクエリーで検出されないようにするため、図７（Ｉ）に示すようにステートチェンジメッセージ７１２をプロセス情報管理部４０３に対して送信する。ステートチェンジメッセージ７１２にはコンポーネントＢ７０９がビジー状態に遷移したことが記されている。このメッセージを受け取ったプロセス情報管理部４０３はサービスインベントリー７０６のコンポーネントＢ７０９のエントリーを検索し、その状態９０７に受け取った状態を「ビジー」状態に変更する。さらに最終連絡時刻９０８も更新する。コンポーネントＢ７０９の状態９０７が「ビジー」状態に変更になった為、プロセス情報管理部４０３は以降、名前を指定したクエリーを受け取ってもそのコンポーネントＢ７０９のプロセスを選定することはなくなる。ただし、サービスインベントリー７０６には他のコンポーネントＢのプロセスが複数存在している可能性がある。それらのいずれかがビジー状態でなければ「利用可能なコンポーネントＢ」としてクエリーの発行元のコンポーネントに返却される。複数の同一名とバージョンを持ったコンポーネントプロセス群からどのプロセスをクエリーの結果として選択するのかに関しては、例えば最初に発見したプロセスを返却するようにする。もしくは、コンポーネントプロセスごとに、クエリー発行元のコンポーネントに返却された回数をカウントしておき、最もカウントの低いプロセスを返却するようにしてもよい。

図７（Ｊ）は終了条件８０６に達したコンポーネントＢ７０９が自ら終了する直前にＧｏｏｄｂｙｅメッセージ７１３を送信する様子を示したものである。Ｇｏｏｄｂｙｅメッセージを受け取ったプロセス情報管理部４０３はサービスインベントリー７０６のコンポーネントＢ７０９のエントリーを削除する。

各コンポーネントは終了条件８０６に達しているかを定期的に確認する。終了条件８０６は時間やジョブ数で指定し、終了条件８０６に指定された時間以上プロセスが起動しているか、終了条件８０６に指定されたジョブ数以上のジョブを処理した場合にプロセスを終了させる。ジョブ制御部４０２、フィルター制御部４０４は、定期的にリフレッシュさせるため、終了条件８０６として有限の時間、ジョブ数を指定する。ログ出力部４０８は常駐してログ出力依頼を受け付けるため、終了条件８０６として無限（もしくは非常に大きい値の）時間を指定する。ログ出力部４０８はジョブを処理しないため、終了条件８０６としてジョブ数は指定しない。

＜クエリーの処理詳細＞
図１０は、クエリーの処理詳細を示したフローチャートである。

Ｓ１００１は、プロセス情報管理部４０３が、他のコンポーネントからクエリー要求を受け付ける処理である。クエリーには、コンポーネントの名前と利用したいバージョンが含まれている。

Ｓ１００２は、プロセス情報管理部４０３が、サービスカタログ７０１を探索し、Ｓ１００１で受け付けたコンポーネント名とバージョンに対応するエントリー８０１が存在するかを判定する処理である。もし存在すればＳ１００３に進む。存在しなければＳ１００８に進む。

Ｓ１００３は、プロセス情報管理部４０３が、ジョブ受け付け可能なコンポーネントプロセスが存在するかを判定する処理である。プロセス情報管理部４０３は、サービスインベントリー７０６を探索し、Ｓ１００１で受け付けたコンポーネント名とバージョンに対応するエントリー９０１を探索する。そして、状態９０７が「アイドリング」のコンポーネントプロセスが１つ以上存在するかを判定する。もし存在する場合にはＳ１００４に進む。Ｓ１００４にて、ここで見つけたコンポーネントプロセスのうち１つを選択してクエリー要求元にエンドポイントを通知する。プロセスの選択方法としては、例えば、最初に見つけたコンポーネントプロセスを返すようにする。または例えば、コンポーネントプロセスごとに、何回クエリー要求元にエンドポイントを返したかをサービスインベントリー７０６に記憶しておき、最も回数の少ないコンポーネントプロセスを返すようにしてもよい。

Ｓ１００４は、プロセス情報管理部４０３が、クエリー要求元に要求のあったコンポーネントプロセスのエンドポイントを通知する処理である。

Ｓ１００５は、プロセス情報管理部４０３が、クエリー要求のあったコンポーネントの起動済みプロセス数がサービスカタログ７０１に記録されている最大起動数８０８未満かを判定する処理である。もし最大起動数８０８未満であればＳ１００６に進む。そうでなければＳ１００８に進む。

Ｓ１００６は、プロセス情報管理部４０３が、クエリー要求のあったコンポーネントをプロセスとして起動する処理である。

Ｓ１００７は、プロセス情報管理部４０３が、Ｓ１００６で起動したコンポーネントプロセスからアドバタイズメッセージ７０５を受け付ける処理である。この処理の後にＳ１００４に進み、Ｓ１００６で起動したコンポーネントプロセスをクエリーの要求元に通知する。なお、図１０には記載していないが、アドバタイズメッセージ７０５が規定時間内にプロセス情報管理部４０３に到着しない場合、エラーと判別し、Ｓ１００８に進むようにしてもよい。

Ｓ１００８は、プロセス情報管理部４０３が、クエリー要求元にエラーを通知する処理である。

＜クラッシュ発生時＞
図１１は、フィルターＡとフィルターＢとでデータ変換処理を行う場合において、クラッシュが発生した際の処理の流れを示した図である。ここでは、フィルターＡ、フィルターＢの間でパイプラインが接続されており、フィルターＡの処理結果をフィルターＢが受け取るものとして説明する。

Ｓ１１０１は、フィルターＡが起動する処理である。

Ｓ１１０２は、フィルターＡがパイプライン生成を行う処理である。フィルターＡはジョブ制御部４０２から依頼を受け付け、パイプライン生成を行う。図６ではＳ６０４に相当する。

Ｓ１１０３は、フィルターＡがデータ変換処理スレッドにて、ジョブのデータ変換を行う処理である。図６ではＳ６０５に相当する。図１１では、フィルターＡはデータ変換処理中にクラッシュしている。

Ｓ１１０４は、フィルターＢが起動する処理である。

Ｓ１１０５は、フィルターＢがパイプラインを生成する処理である。図６のＳ６０４で先述したとおり、ここでフィルターＢはジョブ制御部４０２のサービスＩＦのエンドポイントを受け取る。

Ｓ１１０６は、フィルターＢがデータ変換を行う処理である。フィルターＢはパイプラインからデータが送信されてくるのを待機する。

Ｓ１１０７は、フィルターＢがフィルターＡのパイプラインの切断を検知する処理である。具体的には、フィルターＡ、フィルターＢ間で定期的に生存確認のためのパケットを送り合い、パケットが途絶えたことをタイムアウトにより検知する。

Ｓ１１０８は、フィルターＢが、パイプライン切断を示すログメッセージを、ログ出力部４０８に対して出力依頼する処理である。ログ出力部４０８は、このメッセージを受信し、ログファイルにパイプライン切断された旨を追記する。

Ｓ１１０９は、フィルターＢが、ジョブ制御部４０２にエラー通知を行う処理である。エラー通知の際は、ジョブ制御部４０２のサービスＩＦのエンドポイントを通じてエラーを通知する。

Ｓ１１１０は、フィルターＢが行う後処理である。具体的にはパイプラインの破棄や、プロセス情報管理部４０３に「アイドリング」状態への変更通知を行う。プロセス情報管理部４０３はその変更通知を受け取り、サービスインベントリー７０６において当該コンポーネントプロセスの状態９０７を「アイドリング」に変更する。

以上のように、フィルターＡがクラッシュした場合であっても、他のコンポーネント（フィルターＢ、ジョブ制御部、ジョブ処理受け付け部）はクラッシュせずに、パイプラインが切断した旨をログファイルに残すことができる。

＜ハングアップ発生時＞
図１２は、フィルターにてハングアップが発生した際の処理の流れを示した図である。図１１と同様に、フィルターＡ、フィルターＢの間でパイプラインが接続されており、フィルターＡの処理結果をフィルターＢが受け取るものとして説明する。

Ｓ１２０１は、フィルターＡが起動する処理である。ここでは、プロセス情報管理部４０３から終了条件８０６が渡される。

Ｓ１２０２は、データ変換処理スレッドにおいて、フィルターＡがパイプライン生成を行う処理である。

Ｓ１２０３は、ジョブのデータ変換を行う処理である。この処理の途中でフィルターＡがハングアップに陥るものとする。

Ｓ１２０４は、Ｓ１２０１で受け取った終了条件８０６の時間を待機する処理である。図１２ではフィルターＡのデータ変換処理がハングアップしているケースを想定しているため、終了条件８０６に指定された時間が経過し、まだデータ変換処理スレッドが終了しないためＳ１２０５に進む。もし、データ変換処理スレッドが終了していた場合には、フィルターＡは必要な後処理を行い、当該プロセスを終了する。

Ｓ１２０５は、フィルターＡが、ハングアップに陥った旨を示すログメッセージを、ログ出力部４０８に対して出力依頼する処理である。

Ｓ１２０６は、フィルターＡが、プロセスを強制終了する処理である。

Ｓ１２０７は、フィルターＢが起動する処理である。

Ｓ１２０８は、データ変換処理スレッドにおいて、フィルターＡがパイプライン生成を行う処理である。

Ｓ１２０９は、フィルターＢがデータ変換を行う処理である。フィルターＢはパイプラインからデータが送信されてくるのを待機する。

Ｓ１２１０は、フィルターＢがジョブ中止指示を受信する処理である。ジョブ制御部４０２は、タイマーを持ち、ジョブの処理が所定時間以上かかる場合には、各フィルター制御部４０４に対してジョブ中止指示を送信する。フィルターＢはジョブ中止指示を受信し、ジョブ処理を終了する。

Ｓ１２１１は、フィルターＢが、ジョブ中止指示によりジョブを中止した旨を示すログメッセージを、ログ出力部４０８に対して出力依頼する処理である。

Ｓ１２１２は、フィルターＢが、ジョブ制御部４０２に対してエラー通知を行う処理である。

Ｓ１２１３は、フィルターＢが行う後処理である。

以上のように、フィルターＡがハングアップに陥った場合であっても、他のコンポーネントはハングアップに陥らずに、ハングアップした旨や、フィルターＢがジョブ中止した旨をログファイルに残すことができる。

（実施例２）
実施例１で説明したシステムは、各コンポーネントから依頼されたログを一つのファイルに出力するように構成されている。しかし、図１３に示すように、１つのＰＣ上に複数のユーザーシステムが存在するケースも考えられる。たとえば、印刷データ生成用のユーザーシステムと、スキャン画像処理用のユーザーシステムが存在するようなケースが考えられる。以下では、各ユーザーシステムにひもづくコンポーネント群を「グループ」と表現する。図１３は、１つのＰＣ上に、２つのユーザーシステムが存在する場合のコンポーネントの関係性を示した図である。

１３０１は、印刷データ生成用サービス１３０１である。また、１３０２は、スキャン画像処理用サービス１３０２である。図１３に示す通り、一般的に、２つのグループにおいて、プロセス情報管理部４０３とログ出力部４０８とは共有されている。また、すべてのコンポーネントプロセスが共通のコントロールバス４１０に接続されている。

この場合、各グループに属するコンポーネントプロセスが一つのログ出力部４０８にログ出力すると、すべてのグループのコンポーネントのログが一つのログファイルに出力される。このような場合、ログの可読性の低下を招くことがある。また、ログ出力部４０８がクラッシュした場合に、双方のグループにおいてログが残せなくなってしまう。

＜グループごとのコンポーネントの関連＞
そこで、本実施例では、図１４のようにグループごとにログ出力部４０８を用意する仕組みを提供する。具体的には、クエリーを行う際のコントロールバスへの接続アドレスおよびポートを、プロセスごとに排他的に割り当てる処理を行う。

図１４では図示していないが、複数のプロセスをサービスごとにグループ分けするグループ設定手段が存在し、印刷データ生成用サービスとスキャン画像処理用サービスとのそれぞれに含まれるプロセスをグループ分けする。グループ分けされたプロセスは、他のグループからは排他的に制御される。

図１４は、本実施例におけるグループごとのコンポーネントの関連を示した図である。

印刷データ生成用サービス用のログ出力部１４０１、プロセス情報管理部１４０３、コントロールバス１４０５を用意する。また、スキャン画像処理用サービス用のログ出力部１４０２、プロセス情報管理部１４０４、コントロールバス１４０６を用意する。
以下で、図１４のコンポーネントプロセス群を構成するための処理について述べる。

＜ジョブ処理受け付け部にコントロールバスへの接続アドレスおよびポートを割り当てる処理＞
図１５は、ジョブ処理受け付け部にコントロールバスへの接続情報（アドレスおよびポート）を割り当てる処理を示した図である。

本実施例では、起動する予定のジョブ処理受け付け部のプロセス数と同数のプロセス情報管理部のプロセスをあらかじめ起動しておく必要がある。本実施例ではジョブ処理受け付け部を２つ起動する想定のため、プロセス情報管理部のプロセスも２つ起動する。

本実施例では、グループＡとグループＢとに分け、それぞれに属するコンポーネントには、Ａ、Ｂを付記して記載する。図１５では、その２つのプロセス情報管理部のプロセスを、それぞれ「プロセス情報管理部Ａ」「プロセス情報管理部Ｂ」と記載している。それぞれのプロセス情報管理部には、コントロールバスへの接続情報が書かれた設定ファイルを読み込ませる必要がある。

図１６（Ａ）および図１６（Ｂ）は、プロセス情報管理部Ａ、プロセス情報管理部Ｂがそれぞれ読み込む設定ファイルである。図１６（Ａ）、図１６（Ｂ）において、接続情報１６０１、接続情報１６０２は、コントロールバスへの接続情報である。ここでは、プロセス情報管理部Ａはアドレス“２２５．０．０．０”、ポート”５４５６７”で、プロセス情報管理部Ｂはアドレス“２２５．０．０．０”、ポート”５４５６９”でコントロールバスに接続することとなる。

実施例１では、プロセス情報管理部４０３はＯＳによって起動するようＯＳに設定しておく必要がある、ということを先述した。本実施例においては、プロセス情報管理部のプロセスごとに異なる設定ファイルを読み込むようＯＳ上で設定しておく。

図１５において、Ｓ１５０１は、プロセス情報管理部Ａが起動し、図１６（Ａ）に示す設定ファイルを読み込む処理である。プロセス情報管理部Ａは、読み込んだコントロールバスへの接続情報をＲＡＭ２０４に記憶する。プロセス情報管理部Ｂに関しても同様に、図１６（Ｂ）に示す設定ファイルを読み込む。

Ｓ１５０２は、プロセス情報管理部Ａがログ出力部のプロセスを起動する処理である。このプロセスをログ出力部Ａとする。ここではログ出力部がホットスタンバイで起動する場合を想定している。同様に、プロセス情報管理部Ｂに関してもログ出力部のプロセスを起動する。このプロセスをログ出力部Ｂとする。

Ｓ１５０３は、ジョブ処理受け付け部のプロセスのうち１つが起動し、初期化を行う処理である。このプロセスを図１５では、ジョブ処理受け付け部Ａと記載している。

Ｓ１５０４は、ジョブ処理受け付け部Ａが図１６（Ｃ）に示す設定ファイルを読み込む処理である。図１６（Ｃ）は、ジョブ処理受け付け部のプロセスが読み込む設定ファイルであり、利用可能なコントロールバスの接続情報が記載されている。本実施例では２つのジョブ処理受け付け部のプロセスが立ち上がる想定のため、２つの接続情報が、接続情報１６０３、接続情報１６０４として記載されている。

Ｓ１５０５は、ジョブ処理受け付け部Ａが図１６（Ｃ）の内容をもとに、未使用の接続情報を取得する処理である。ジョブ処理受け付け部Ａは、接続情報１６０３、接続情報１６０４を上から順に他のジョブ処理受け付け部のプロセスから利用されていないかを確認する。具体的には、例えばＯＳの機能としてミューテックスが提供されている場合には、接続情報の上から順に、この接続情報から生成される文字列でミューテックスオブジェクトの作成を試みる。もし作成できた場合は、その接続情報は他のジョブ処理受け付け部のプロセスから利用されていないため、その接続情報をＲＡＭ２０４に記憶する。もし作成できない場合は、次の接続情報についてミューテックスオブジェクトの作成を試みる。もし、すべての接続情報についてミューテックスオブジェクトが作成できない場合は、そのジョブ処理受け付け部のプロセスを利用するユーザーシステムに対してエラーを返す。Ｓ１５０５では、ジョブ処理受け付け部Ａは接続情報１６０３すなわち、“２２５．０．０．０”、ポート”５４５６７”を記憶したものとする。

なお、ミューテックスオブジェクトを作成する際の文字列としては、ジョブ処理受け付け部のプロセス間に共通の規則に従っていれば良く、例えば「ＪｏｂＲｅｃｅｉｖｅｒ＿（アドレス）＿（ポート番号）」といった文字列を生成する。

Ｓ１５０６は、ジョブ処理受け付け部Ａが接続情報１６０３を使ってコントロールバスに接続し、ログ出力部のクエリー要求を行う処理である。このクエリー要求は、同じ接続情報を使っているプロセス情報管理部Ａにのみ届く。プロセス情報管理部Ａは、Ｓ１５０７にてクエリーを受け付け、自身が管理しているログ出力部Ａのエンドポイントをジョブ処理受け付け部Ａに返却する。ジョブ処理受け付け部Ａはログ出力部Ａのエンドポイントを取得し、記憶する。

Ｓ１５０８は、ジョブ処理受け付け部Ａがログ出力部Ａに対してログ出力依頼を行う処理である。ここでは例えば初期化が完了した旨を示すメッセージを送信依頼する。Ｓ１５０９にて、ログ出力部Ａがログ出力依頼を受け付け、そのメッセージをログファイルに追記する。

以上のように、ジョブ処理受け付け部Ａに、コントロールバスの接続情報が割り当てられることで、同様の接続情報を利用しているプロセス情報管理部Ａとログ出力部Ａを利用できるようになる。別のジョブ処理受け付け部のプロセスが起動する場合には、Ｓ１５０５にてジョブ処理受け付け部Ａとは別の接続情報１６０４が割り当てられ、プロセス情報管理部Ｂとログ出力部Ｂが利用できるようになる。

＜ジョブ制御部の接続情報割り当ての流れ＞
次に、ジョブ制御部Ａにコントロールバスへの接続情報を割り当てる処理の流れを、図１７を用いて説明する。図１７は、図１６から続く処理の流れとなっている。

ジョブ処理受け付け部Ａはユーザーシステムからジョブを受け付けると、Ｓ１７０１にて、ジョブ制御部Ａのクエリー要求を行う。Ｓ１７０２にて、プロセス情報管理部Ａがクエリー要求を受け付け、ジョブ制御部Ａのプロセスを起動する。

このとき、起動オプションとして、プロセス情報管理部Ａが持つコントロールバスへの接続情報１６０１をジョブ制御部Ａに渡す。

Ｓ１７０３は、ジョブ制御部Ａが起動し、初期化を行う処理である。

Ｓ１７０４は、ジョブ制御部Ａが接続情報１６０１を使ってコントロールバスに接続し、ログ出力部Ａのクエリー要求を行う処理である。このクエリー要求は、同じ接続情報を使っているプロセス情報管理部Ａにのみ届く。プロセス情報管理部Ａは、Ｓ１７０５にてクエリーを受け付け、自身が管理しているログ出力部Ａのエンドポイントをジョブ制御部Ａに返却する。ジョブ制御部Ａはログ出力部Ａのエンドポイントを取得し、記憶する。

Ｓ１７０６は、ジョブ制御部Ａがログ出力部Ａに対してログ出力依頼を行う処理である。ここでは例えばジョブ受け付け可能となった旨を示すメッセージを送信依頼する。Ｓ１７０７にて、ログ出力部Ａがログ出力依頼を受け付け、そのメッセージをログファイルに追記する。

ここでは、ジョブ制御部Ａにコントロールバスへの接続情報を割り当てる方法を説明したが、ジョブ制御部Ａがフィルター制御部Ａのプロセスをクエリーする際も同様の方法で接続情報が割り当てられる。

以上のように、ジョブ処理受け付け部Ａが利用するジョブ制御部Ａや、さらにそのジョブ制御部Ａが利用するフィルター制御部Ａに、共通のコントロールバスへの接続情報が割り当てられる。

結果的に、そのグループで共通のログ出力部Ａプロセスを利用することが可能となる。

（実施例３）
本実施例も実施例２と同様に、グループごとにログ出力部を割りあてる方法を提供する。

本実施例では、起動する予定のジョブ処理受け付け部のプロセス数と同数のプロセス情報管理部のプロセスをあらかじめ起動しておくようＯＳに設定しておく必要があった。そのため、ユーザーシステムの数が想定よりも多くなった場合には、再度設定を行わなければならない。また、図１６に示した設定ファイルの内容も修正しなければならない。

本実施例では、図１８に示すように、一つのプロセス情報管理部１４０３のみを起動し、プロセス情報管理部１４０３でグループを管理させる方法を提供する。図１８は、プロセス情報管理部１４０３でグループを管理する場合のコンポーネント構成を示した図である。なお、コントロールバス１４０５もグループで共通のものを用いる。

＜グループ生成の流れ＞
図１９は、グループ生成の流れを示した図である。

ここでは、あらかじめプロセス情報管理部１４０３のプロセスが起動しており、印刷データ生成用サービス１３０１がジョブ処理受け付け部４０１をロードした状態から説明する。本実施例においても、実施例２と同様に、図１９では、ジョブ処理受け付け部が動作するプロセスをジョブ処理受け付け部Ａと記載している。

Ｓ１９０１は、ジョブ処理受け付け部Ａが初期化を行う処理である。

Ｓ１９０２は、ジョブ処理受け付け部Ａが、プロセス情報管理部１４０３にグループ生成依頼を行う処理である。Ｓ１９０３にて、プロセス情報管理部１４０３はその依頼を受け付け、グループＩＤを生成し、ＲＡＭ２０４に記憶し、そのグループＩＤをジョブ処理受け付け部Ａに通知する。ここで、プロセス情報管理部１４０３は、グループの設定を行うグループ設定手段として機能する。実施例２と同様に、グループ分けされたプロセスは、他のグループからは排他的に制御される。

グループＩＤは例えばＧＵＩＤなどユニークな文字列を用いるが、ここでは便宜的に００１というグループＩＤが生成されたものとして説明を続ける。また、以下ではグループＩＤの００１という値を「グループＩＤ：００１」と記載する。ジョブ処理受け付け部ＡはそのグループＩＤをＲＡＭ２０４上に例えばリスト形式で記憶する。

Ｓ１９０４は、ジョブ処理受け付け部Ａが、ログ出力部Ａのクエリーを要求する処理である。このとき、ジョブ処理受け付け部Ａは、グループＩＤとして００１を指定してクエリー要求を行う。Ｓ１９０５にて、プロセス情報管理部１４０３はそのクエリー要求を受け付ける。プロセス情報管理部１４０３は、ジョブ処理受け付け部Ａから指定されたグループＩＤに所属する起動済みコンポーネントプロセスがあるか否かを確認する。本実施例では、図９に示すサービスインベントリー７０６において、各コンポーネントプロセスのグループＩＤも記録する。プロセス情報管理部１４０３は、サービスインベントリー７０６を探索し、指定されたグループＩＤに所属する「アイドリング」状態のプロセスが存在すれば、そのエンドポイントをジョブ処理受け付け部Ａに返却する。もし、存在しなければ、クエリー要求のあったコンポーネントをプロセスとして起動する。この実施例では、指定されたグループＩＤに所属する「アイドリング」状態のログ出力部Ａのプロセスが存在しなかったケースを想定しており、プロセス情報管理部１４０３はログ出力部Ａをプロセスとして起動する。このプロセスをログ出力部Ａとする。プロセス情報管理部１４０３は、ログ出力部Ａを起動する際、起動オプションとしてグループＩＤ：００１を渡す。プロセス情報管理部１４０３は、起動したログ出力部Ａからのアドバタイズメッセージ７０５を受け取ると、サービスインベントリー７０６の対応するエントリーを作成し、ログ出力部ＡがグループＩＤ：００１に所属している旨を記録する。

なお、本実施例でも実施例１と同様にコンポーネントごとの最大起動数８０８を設定できるようにしてもよい。その場合、グループごとに最大起動数を設定できるようにしてもよい。

Ｓ１９０６は、ジョブ処理受け付け部Ａが、ジョブ制御部Ａのクエリーを要求する処理である。このとき、ジョブ処理受け付け部Ａは、グループＩＤとして００１を指定してクエリー要求を行う。Ｓ１９０７にて、プロセス情報管理部１４０３はそのクエリー要求を受け付ける。受け付けた後の処理は、Ｓ１９０５と同様のため省略する。この実施例では、プロセス情報管理部１４０３は、起動オプションとして、グループＩＤ：００１を指定して、ジョブ制御部４０２のプロセスを起動する。起動したプロセスをジョブ制御部Ａとする。

Ｓ１９０８は、ジョブ制御部Ａが、自身を初期化する処理である。

Ｓ１９０９は、ジョブ制御部Ａが、グループＩＤ：００１を指定してログ出力部Ａのクエリーを要求する処理である。Ｓ１９１０で、プロセス情報管理部１４０３はそのクエリー要求を受け付ける。ここでは、グループＩＤ：００１に所属するログ出力部４０８すなわちログ出力部Ａが存在するため、プロセス情報管理部１４０３そのエンドポイントをジョブ制御部Ａに返却する。

Ｓ１９１１は、ジョブ制御部Ａがログ出力部Ａに対してログ出力依頼を行う処理である。Ｓ１９１２は、ログ出力部Ａがログ出力依頼を受け付け、そのメッセージをログファイルに追記する。

＜グループ削除の流れ＞
図１８において、印刷データ生成用サービス１３０１は通常、システムに常駐しサービスを提供するが、例えば、動作しているサーバーのメンテナンスのためシャットダウンが必要なケースが存在する。以下では、印刷データ生成用サービス１３０１のプロセスがシャットダウンし、グループを削除する処理の流れを説明する。

図２０はグループ削除処理の流れを説明した図である。ここでは、ジョブ処理受け付け部Ａ、プロセス情報管理部Ａ、ジョブ制御部Ａ、フィルター制御部Ａ、ログ出力部Ａのそれぞれのプロセスが起動しており、すべて同じグループＩＤ：００１に所属しているものとする。また、ジョブ処理はすべて完了した状態とする。

Ｓ２００１は、ジョブ処理受け付け部Ａが、グループＩＤ：００１を指定して、グループ削除依頼をする処理である。

Ｓ２００２で、プロセス情報管理部１４０３は、グループ削除依頼を受け付け、設定されたグループを削除する削除手段として機能し、グループのリストからグループＩＤ：００１を削除する。

Ｓ２００３は、ジョブ処理受け付け部Ａが行う終了処理である。

Ｓ２００４は、ジョブ制御部Ａおよびフィルター制御部Ａが終了条件チェックを行う処理である。ジョブ制御部４０２およびフィルター制御部Ａが起動したときにプロセス情報管理部１４０３から渡された終了条件８０６をもとに、終了すべきかどうかをチェックする。ジョブ制御部Ａおよびフィルター制御部Ａは終了条件を満たしていた場合はプロセスを終了する。終了条件を満たしていない場合は一定時間後に再度終了条件を確認する。

Ｓ２００５は、ログ出力部Ａが終了条件チェックを行う処理である。本実施例においては、ログ出力部Ａは、他のコンポーネントプロセスからのログ出力依頼が所定時間なかった場合にプロセスを終了する。

図１９ではジョブ制御部ＡがグループＩＤ：００１に所属するログ出力部Ａを取得する方法を説明した。また、図２０を用いてグループを削除する処理についても説明した。

ジョブ制御部Ａがフィルター制御部Ａのプロセスをクエリーする際も図１９と同様の処理が行われる。つまり、プロセス情報管理部１４０３は、フィルター制御部ＡをグループＩＤ：００１に所属させる。また、そのフィルター制御部ＡもグループＩＤ：００１に所属するログ出力部Ａをクエリーし、利用することができるようになる。以上のように、グループで共通のログ出力部Ａプロセスを利用することが可能となる。

（実施例４）
上記実施例においては、複数のデータ変換フィルターによる処理それぞれを異なるプロセスで実行することにより、一部のデータ変換フィルターの不具合がシステム全体に波及する可能性を低くした。

上記実施例の通り、複数のデータ変換それぞれを異なるプロセスで実行すれば、一部のデータ変換フィルターの不具合がシステム全体に波及する可能性を低くすることが出来る。しかし、複数のデータ変換を単一のプロセスで実行するよりも実行速度が低下することがある。これは、プロセス間通信の頻度が高まり、プロセス間通信の処理による遅延が発生するためである。本実施例では、複数のデータ変換フィルターそれぞれの信頼度に基づき、異なるプロセスで実行するデータ変換フィルターを選択する。本実施例の技術では、データ変換フィルターそれぞれの信頼度に基づいて、異なるプロセスで実行するデータ変換フィルターを選択することにより、データ変換の処理速度の維持と一部のデータ変換フィルターの不具合の波及の防止とを両立させることが出来る。

以下、本実施例の詳細について説明する。

図２１は、本実施例における印刷データ変換サービス３０１が依頼された印刷データを変換する際に利用するソフトウェアコンポーネント群の関連を説明する図である。

以下に、図２１を用いて、印刷データ変換サービス３０１が利用するソフトウェアコンポーネントそれぞれの概要について説明する。尚、図２１におけるソフトウェアコンポーネント群の関連は、実施例１における図４とほぼ同様である。ここでは、実施例１における図４と異なる点について説明する。

実施例１における図４と異なる点は、稼働実績蓄積部４１１が追加されていることである。以下、本実施例における稼働実績蓄積部４１１の詳細について説明する。

＜稼働実績蓄積部＞
稼働実績蓄積部４１１はプロセスとしてコントロールバス４１０上に存在する。
稼働実績蓄積部４１１は、ＲＡＭ２０４上に、図２２に示すような稼働実績を格納したテーブルを保持する。図２２では、各データ変換フィルターは信頼度が低いとしている。

このテーブルは、稼働実績蓄積部４１１を起動時に外部設定ファイルから読み込まれ、終了時に外部設定ファイルへ書き出される。

テーブルはフィルター名１３０１、バージョン１３０２、処理ジョブ数１３０３、異常終了回数１３０４、信頼度１３０５、判定閾値１３０６の項目を有する。フィルター名１３０１にはデータ変換モジュールにて使用されるフィルターの名前、バージョン１３０２には各フィルターのバージョンが保持されている。また、処理ジョブ数１３０３には各フィルターが処理したジョブの回数、異常終了回数１３０４には各フィルターが異常終了した回数、信頼度１３０５には各フィルターの信頼度、判定閾値１３０６には信頼度の判定に用いる閾値が保持されている。

本実施例では、データ変換モジュールのサービス開始時の初期設定では、図２２に示すように、処理ジョブ数１３０３および異常終了回数１３０４は全て「０」、信頼度１３０５は全て「低」に設定されている。

稼働実績蓄積部４１１は、ジョブ制御部４０２から問い合わせを受けた各フィルターの信頼度を、ジョブ制御部４０２へ回答する機能を有する。

稼働実績蓄積部４１１は、ジョブ制御部４０２から、「ジョブ終了通知」および「異常終了フィルター通知」を受けると、稼働実績を格納したテーブルを更新する。具体的には、「ジョブ終了通知」を参照して、ジョブで変換に用いた各フィルターの処理ジョブ数１３０３をそれぞれ１カウントアップする。また、「異常終了フィルター通知」を参照して、異常終了したフィルターの異常終了回数１３０４を１カウントアップする。

稼働実績蓄積部４１１は、このテーブルを参照して、信頼度を判定し、信頼度１３０５を上書きする。信頼度の判定方法については次に説明する。

＜信頼度の判定方法＞
稼働実績蓄積部４１１は、フィルターの信頼度を、予め定められた信頼度判定式を用いて信頼度判定値を算出する。信頼度判定式の例を以下に示す。
信頼度判定値＝処理ジョブ数／（異常終了回数＋１） （１）
稼働実績を格納したテーブルの値から式（１）を用いて算出した信頼度判定値が、判定閾値１３０６以上であれば信頼度「高」と判定し、判定閾値１３０６より小さければ信頼度「低」と判定する。

図２３に、稼働実績が蓄積した後のテーブルの一例を示す。フィルターＡは、処理ジョブ数１３０３は５００００、異常終了回数１３０４は２であるため、信頼度判定値は５００００／３となり、判定閾値１００００以上であるため、信頼度は「高」と判定される。また、フィルターＺは、処理ジョブ数１３０３は１０、異常終了回数１３０４は０であるため、信頼度判定値は１０／１となり、判定閾値１００００より小さいため、信頼度は「低」と判定される。

ここで、式（１）の分母を（異常終了回数 ＋１）としているのは、フィルターＺのように、処理ジョブ数１３０３が少なく、異常終了回数が０のフィルターが、信頼度「高」と判定されるのを防ぐためである。

＜ジョブ制御部４０２＞
ジョブ制御部４０２は、実施例１におけるジョブ制御部４０２と同様の機能を有する。

ただし、本実施例におけるジョブ制御部４０２は、ジョブに含まれているジョブ種別情報と一致する要素５０１を探索し、一致する要素５０１の下に書かれている各フィルターの信頼度を、前述の稼働実績蓄積部４１１へ問い合わせる。稼働実績蓄積部４１１から回答があった各フィルターの信頼度をもとに、フィルター制御部４０４の個数および、各フィルターがロードされるフィルター制御部名を決定する。決定方法については図２４および図２５を用いて後述する。決定したフィルター制御部４０４の個数は設定ファイルの要素５０１のＦｉｌｔｅｒ Ｈｏｓｔ ｎｕｍ属性へ、各フィルターがロードされるフィルター制御部名を要素５０２のＦｉｌｔｅｒ Ｈｏｓｔ ｎａｍｅ属性へ上書きする。

なお、変換に用いるフィルター制御部４０４の個数および、フィルターの種類と並び順と各フィルターがロードされるフィルター制御部名は、ジョブ種別情報の代わりに、印刷データを解析して決定するようにしてもよい。

ジョブ制御部４０２は、ＲＡＭ２０４上に、「フィルター変換完了数」を記録する機能を有する。この「フィルター変換完了数」はジョブの処理中に、クラッシュやハングアップなどの異常終了が発生した場合に、異常終了したフィルターを判定するために用いる。この「フィルター変換完了数」を記録する処理について説明する。ジョブ制御部４０２は、初段のフィルター制御部４０４に接続されているパイプラインにデータを流した後、「フィルター変換完了数」を０に初期化する。その後、フィルター制御部４０４から「フィルター変換完了通知」を受け取るたびに、「フィルター変換完了数」を１カウントアップする。「フィルター変換完了通知」については後述する。

ジョブ制御部４０２は、ジョブの処理が正常に完了した際には、稼働実績蓄積部４１１へ「ジョブ終了通知」を送信する。「ジョブ終了通知」には、そのジョブで変換に用いた各フィルターのフィルター名およびバージョンが記述されている。

ジョブ制御部４０２は、ジョブの処理中に異常終了が発生した場合は、異常終了したフィルターを判定し、稼働実績蓄積部４１１へ「ジョブ終了通知」および「異常終了フィルター通知」を送信する。「異常終了フィルター通知」には、異常終了したフィルターのフィルター名およびバージョンが記述されている。異常終了が発生した際の処理は、図２６、図２７を用いて後述する。

＜フィルター制御部の個数、各フィルターがロードされるフィルター制御部名の決定方法＞
設定ファイルと稼働実績蓄積部４１１から回答があった各フィルターの信頼度をもとに、フィルター制御部４０４の個数および、ロードされるフィルター制御部名を決定し、設定ファイルを上書きする方法について詳述する。

図２４で示すように、フィルターＡからフィルターＦまで６種類のフィルターが順番に処理され、各フィルターの信頼度がそれぞれ１４０１の場合について説明する。隣り合うフィルターの信頼度が「高」「高」の場合には同一プロセス、「低」「低」、「低」「高」、「高」「低」の場合には別プロセスとなるように、フィルター制御部の個数１４０３、各フィルターがロードされるフィルター制御部名１４０２を決定する。フィルター制御部名１４０２が同一に決定されたフィルター（この例では、フィルターＡとフィルターＢ、フィルターＥとフィルターＦ）は同一プロセスとして処理される。

図２５のフローチャートを用いて処理を説明する。

まず、Ｓ１４０１において、ジョブ制御部４０２が、設定ファイルと稼働実績蓄積部４１１から回答があった各フィルターの信頼度をもとに、フィルター種類とその信頼度を処理順に並べる。

Ｓ１４０２において、ジョブ制御部４０２が、１番目のフィルター（この例ではフィルターＡ）をロードするフィルター制御部名をフィルター制御部１と決定し、設定ファイルの要素５０２のＦｉｌｔｅｒ Ｈｏｓｔ ｎａｍｅ属性へ上書きする。

Ｓ１４０３において、ジョブ制御部４０２が、パラメータの初期値をｍ＝２、ｎ＝１と設定する。ここで、各パラメータは下記を意味する。
ｍ：フィルターを処理順に並べた場合のフィルターの順番を示すパラメータ
ｎ：フィルター制御部名およびフィルター制御部の個数を決定する際に使用するパラメータ
次に、Ｓ１４０４において、ジョブ制御部４０２が、隣り合うフィルターのプロセスを結合するか否かを判定する。具体的には、隣り合うｍ−１番目のフィルターとｍ番目のフィルターの信頼度が、「高」「高」であれば、フィルターのプロセスを結合すると判定しＳ１４０６へ進む。また、「高」「低」、「低」「高」、または「低」「低」であればプロセスは結合しないと判定しＳ１４０５へ進む。図２４に記載の例では、ｍ−１番目のフィルターＡが「高」、ｍ番目のフィルターＢが「高」であるため、プロセスを結合すると判定し、Ｓ１４０６へ進む。

Ｓ１４０６において、ジョブ制御部４０２が、ｍ番目のフィルター（ここではフィルターＢ）をロードするフィルター制御部名をフィルター制御部ｎ（ここでは、フィルター制御部１）と決定する。また、決定したフィルター制御部名を設定ファイルの要素５０２のＦｉｌｔｅｒ Ｈｏｓｔ ｎａｍｅ属性へ上書きする。

Ｓ１４０７において、ジョブ制御部４０２が、ｍ＜Ｍであるか否かを判定し、ｍ＜Ｍである場合はＳ１４０８へ進み、ｍ＜Ｍでない場合はＳ１４０９へ進む。ここで、Ｍはこのジョブで用いるフィルターの数（ここでは６個）を意味する。 この例では、ｍ＝２＜６であるため、Ｓ１４０８へ進む。

Ｓ１４０８において、ジョブ制御部４０２が、パラメータｍの値を１カウントアップする（ここでは，ｍ＝３となる）。次に、Ｓ１４０４において、ジョブ制御部４０２が、隣り合うフィルターのプロセスを結合するか否かを判定する。図２４に記載の例では、ｍ−１番目のフィルターＢが「高」、ｍ番目のフィルターＣが「低」であるため、プロセスは結合しないと判定しＳ１４０５へ進む。

Ｓ１４０５において、ジョブ制御部４０２が、パラメータｎの値を１カウントアップする（ここではｎ＝２となる）。

Ｓ１４０６において、ジョブ制御部４０２が、ｍ番目のフィルター（ここではフィルターＣ）をロードするフィルター制御部名をフィルター制御部ｎ（ここでは、フィルター制御部２）と決定する。また、決定したフィルター制御部名を設定ファイルの要素５０２のＦｉｌｔｅｒ Ｈｏｓｔ ｎａｍｅ属性へ上書きする。

Ｓ１４０４からＳ１４０８の処理をｍ＜Ｍではなくなるまで繰り返す。

Ｓ１４０９において、ジョブ制御部４０２が、ジョブ制御部の個数をｎ個（図２４の例では４個）と決定し、設定ファイルの要素５０１のＦｉｌｔｅｒ Ｈｏｓｔ ｎｕｍ属性へ上書きする。

また、フィルター制御部４０４は、自身がロードしたフィルターが、ジョブの処理を完了した際に、ジョブ制御部４０２へ「フィルター変換完了通知」を送る。１つのフィルター制御部４０４が複数のフィルターをロードしている場合には、複数のフィルターそれぞれが順次ジョブの処理を完了するたびに、ジョブ制御部４０２へ「フィルター変換完了通知」を送る。

ジョブのデータの末尾には、データ末尾を示す終端判別データが含まれており、フィルター制御部４０４は、その終端判別データを識別することにより、各フィルターがジョブの処理を完了したと判断することができる。

＜正常終了する場合のデータ処理＞
図２８は、ジョブ処理受け付け部４０１が印刷データ変換サービス３０１からジョブ処理を受け付けた後の、データ変換処理の概要を示したシーケンス図である。

Ｓ６０１は、ジョブ処理受け付け部４０１がジョブ制御部４０２のクエリー要求を行う処理である。ジョブ処理受け付け部４０１は、プロセス情報管理部４０３にクエリー要求を行い、ジョブ制御部４０２のエンドポイントを取得する。

Ｓ６０２は、ジョブ処理受け付け部４０１がジョブ制御部４０２に対してジョブ処理依頼を行う処理である。ここで、ジョブのデータが、ジョブ処理受け付け部４０１からジョブ制御部４０２に渡される。受け渡しには、ジョブのデータのパスで渡すようにしても良いし、メモリやプロセス間通信で渡すようにしてもよい。

Ｓ６０３は、ジョブ制御部４０２が、動作実績蓄積部４１１のクエリー要求を行う処理である。ジョブ制御部４０２は、プロセス情報管理部４０３にクエリー要求を行い、動作実績蓄積部４１１のエンドポイントを取得する。

Ｓ６０４は、ジョブ制御部４０２が、ジョブのデータに含まれているジョブ種別情報を基に、このジョブで用いる各フィルターの信頼度を稼働実績蓄積部４１１へ問い合わせる。ここでは、ジョブ種別は「プリントサービスＡ用変換」として説明する。ジョブ制御部４０２は、「プリントサービスＡ用変換」と一致する、設定ファイル（図５）の要素５０１を探索する。そして、探索して一致した要素５０１の下に書かれている各フィルター（ここではフィルターＡ、フィルターＢ、フィルターＣ）の信頼度を、稼働実績蓄積部４１１へ問い合わせる。その際、各フィルターのフィルター名、バージョン、およびジョブ制御部４０２のサービスＩＦのエンドポイントも稼働実績蓄積部４１１へ通知する。

Ｓ６０５は、稼働実績蓄積部４１１が、問い合わせを受けた各フィルターの信頼度を、ジョブ制御部４０２のサービスＩＦを通じて、ジョブ制御部４０２へ回答する。データ変換モジュールのサービス開始時の初期設定では、稼働実績を格納したテーブルの信頼度１３０５は全て「低」に設定されているため、フィルターＡ、フィルターＢ、フィルターＣの信頼度は全て「低」と回答する。

Ｓ６０６は、ジョブ制御部４０２が、各フィルターの信頼度をもとに、フィルター制御部４０４の個数および、各フィルターがロードされるフィルター制御部名を決定する。また、決定したフィルター制御部４０４の個数は設定ファイル（図５）の要素５０１のＦｉｌｔｅｒ Ｈｏｓｔ ｎｕｍ属性へ、各フィルターがロードされるフィルター制御部名を要素５０２のＦｉｌｔｅｒ Ｈｏｓｔ ｎａｍｅ属性へ上書きする。ここでは、フィルター制御部４０４は３個、フィルターＡ４０５はフィルター制御部１、フィルターＢ４０６はフィルター制御部２、フィルターＣ４０７はフィルター制御部３にロードされるように上書きする。

Ｓ６０７は、ジョブ制御部４０２が、プロセス情報管理部４０３に対して、設定ファイル（図５）にもとづき各フィルターに対応するフィルター制御部４０４のクエリー要求を行い、それぞれのエンドポイントを取得する。ここでは、フィルターＡ４０５をロードしたフィルター制御部１、フィルターＢ４０６をロードしたフィルター制御部２、フィルターＣ４０７をロードしたフィルター制御部３のエンドポイントを取得する。

Ｓ６０８は、パイプラインを生成する処理である。ジョブ制御部４０２は、各フィルター制御部４０４に対してパイプラインの生成を指示する。各フィルター制御部４０４は、それぞれ隣り合うコンポーネントプロセスとのパイプラインを生成する。パイプライン生成を完了した後、各フィルター制御部４０４はジョブ制御部４０２にパイプライン生成完了を通知し、各フィルター制御部４０４への入力パイプラインからジョブが流れてくるのを待機する。なお、ジョブ制御部４０２は、各フィルター制御部４０４に対してパイプラインの生成を指示する際に、ジョブ制御部４０２のサービスＩＦのエンドポイントも各フィルター制御部４０４に通知する。フィルター制御部４０４はエラーが起こった際に、このジョブ制御部４０２のサービスＩＦを通じて、ジョブ制御部４０２にエラーを通知する。また、フィルター制御部４０４は、自身がロードしたフィルターが、ジョブの処理を完了した際に、このジョブ制御部４０２のサービスＩＦを通じて、ジョブ制御部４０２に「フィルター変換完了通知」を通知する。

Ｓ６０９は、データ変換処理である。ジョブ制御部４０２は、初段のフィルター制御部１に接続されているパイプラインにデータを流した後、「フィルター変換完了数」を０に初期化する。フィルター制御部１はデータを受け取り、フィルターＡを用いてデータ変換処理を行う。そして、フィルター制御部１は、フィルター制御部２と接続されているパイプラインにデータを流した後、ジョブ制御部４０２へ「フィルター変換完了通知」を送信する。ジョブ制御部４０２は、「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。フィルター制御部２、フィルター制御部３でも同様にデータ変換処理が行われる。最終的に、フィルター制御部３から、ジョブ制御部４０２に変換後のデータが送信される。

Ｓ６１０は、ジョブ制御部４０２が、ジョブ処理受け付け部４０１に対して変換後のデータを返却する処理である。

Ｓ６１１は、ジョブ制御部４０２が、稼働実績蓄積部４１１へ「ジョブ終了通知」を通知する。「ジョブ終了通知」には、そのジョブで変換に用いた各フィルターのフィルター名およびバージョンが記述されている。

Ｓ６１２は、稼働実績蓄積部４１１が、ジョブ制御部４０２から「ジョブ終了通知」を受けて、図２２に示すような稼働実績を格納したテーブルを更新する。具体的には、「ジョブ終了通知」を参照して、ジョブで変換に用いた各フィルターの処理ジョブ数１３０３を、それぞれ１カウントアップする。ここでは、フィルターＡ、フィルターＢ、フィルターＣの処理ジョブ数１３０３をそれぞれ１カウントアップする。

Ｓ６１３は、稼働実績蓄積部４１１が、稼働実績を格納したテーブルが更新されるたびに、更新されたフィルターの信頼度の判定を行い、信頼度１３０５を上書きする。

＜クラッシュした場合の処理＞
図２６は、データ変換処理中にクラッシュが発生した際の処理の流れを示した図である。図２８で説明した処理フローのＳ６０７以降の処理で、クラッシュが発生した場合の処理フローである。ここでは、フィルターＡをロードしたフィルター制御部１がデータ変換を行う際にクラッシュしたものとして説明する。

Ｓ１１０１は、フィルターＡをロードしたフィルター制御部１が起動する処理である。図２８ではＳ６０７に相当する。

Ｓ１１０２は、フィルター制御部１がパイプライン生成を行う処理である。フィルター制御部１はジョブ制御部４０２から依頼を受け付け、パイプライン生成を行う。図２８ではＳ６０８に相当する。

Ｓ１１０３は、フィルター制御部１がフィルターＡを用いてデータ変換処理スレッドにて、ジョブのデータ変換を行う処理である。図２６では、フィルターＡをロードしたフィルター制御部１がデータ変換処理中にクラッシュしている。

Ｓ１１０４は、フィルターＢをロードしたフィルター制御部２が起動する処理である。

Ｓ１１０５は、フィルター制御部２がパイプラインを生成する処理である。図２８のＳ６０８で先述したとおり、ここでフィルター制御部２はジョブ制御部４０２のサービスＩＦのエンドポイントを受け取る。

Ｓ１１０６は、フィルター制御部２がフィルターＢを用いてデータ変換を行う処理である。フィルター制御部２はパイプラインからデータが送信されてくるのを待機する。

Ｓ１１０７は、フィルター制御部２がフィルター制御部１のパイプラインの切断を検知する処理である。具体的には、フィルター制御部１、フィルター制御部２間で定期的に生存確認のためのパケットを送り合い、パケットが途絶えたことをタイムアウトにより検知する。

Ｓ１１０８は、フィルター制御部２が、パイプライン切断を示すログメッセージを、ログ出力部４０８に対して出力依頼する処理である。ログ出力部４０８は、このメッセージを受信し、ログファイルにパイプライン切断された旨を追記する。

Ｓ１１０９は、フィルター制御部２が、ジョブ制御部４０２にエラー通知を行う処理である。エラー通知の際は、ジョブ制御部４０２のサービスＩＦのエンドポイントを通じてエラーを通知する。

Ｓ１１１０は、フィルター制御部２が行う後処理である。具体的にはパイプラインの破棄や、プロセス情報管理部４０３に「アイドリング」状態への変更通知を行う。プロセス情報管理部４０３はその変更通知を受け取り、サービスインベントリー７０６において当該コンポーネントプロセスの状態９０７を「アイドリング」に変更する。

Ｓ１１１１は、ジョブ制御部４０２が、フィルター制御部１へ入力データを送信する。図２８ではＳ６０９の「入力データ送信」に相当する。

Ｓ１１１２は、ジョブ制御部４０２が、フィルター変換完了数を０に初期化する。図２８ではＳ６０９の「フィルター変換完了数初期化 」に相当する。

Ｓ１１１３は、ジョブ制御部４０２が、フィルター制御部２からエラー通知を受け、設定ファイル（図５）およびフィルター変換完了数を参照し、クラッシュしたフィルターを判定する。ここでは、フィルター変換完了数は０となっており、設定ファイル項目５０２の１番最初のフィルターＡがクラッシュしたと判定する。

Ｓ１１１４は、ジョブ制御部４０２が、稼働実績蓄積部４１１へ「ジョブ終了通知」および「異常終了フィルター通知」を通知する。「ジョブ終了通知」には、そのジョブで変換に用いた各フィルターのフィルター名およびバージョンが記述されている。「異常終了フィルター通知」には、クラッシュしたフィルターのフィルター名およびバージョンが記述されている。

Ｓ１１１５は、稼働実績蓄積部４１１が、ジョブ制御部４０２から「ジョブ終了通知」および「異常終了フィルター通知」を受けて、図２２に示すような稼働実績を格納したテーブルを更新する。具体的には、「ジョブ終了通知」を参照して、ジョブで変換に用いた各フィルターの処理ジョブ数１３０３を、それぞれ１カウントアップする。こここでは、フィルターＡ、フィルターＢ、フィルターＣの処理ジョブ数１３０３をそれぞれ１カウントアップする。また、「異常終了フィルター通知」を参照して、クラッシュしたフィルターの異常終了回数１３０４を１カウントアップする。ここでは、フィルターＡの異常終了回数１３０４を１カウントアップする。

Ｓ１１１６は、稼働実績蓄積部４１１が、更新された各フィルターの信頼度の判定を行い、信頼度１３０５を上書きする。

以上のように、フィルター制御部１がクラッシュした場合であっても、他のコンポーネント（フィルター制御部２、ジョブ制御部４０２、ジョブ処理受け付け部）はクラッシュせずに、パイプラインが切断した旨をログファイルに残すことができる。また、稼働実績を蓄積することができる。

この例では、フィルター制御部１がクラッシュし、その次のコンポーネントプロセスであるフィルター制御部２がパイプラインの切断を検知し、エラー通知を行う例を示した。同様に、フィルター制御部２がクラッシュした場合はフィルター制御部３、フィルター制御部３がクラッシュした場合はジョブ制御部４０２がパイプラインの切断を検知し、エラー通知を行えばよい。つまり、クラッシュしたフィルター制御部の次のコンポーネントプロセスがパイプラインの切断を検知し、エラー通知を行えばよい。

＜ハングアップした場合の処理＞
図２７は、データ変換処理中にハングアップが発生した際の処理の流れを示した図である。図２８で説明した処理フローのＳ６０７以降の処理で、ハングアップが発生した場合の処理フローである。ここでは、フィルターＡをロードしたフィルター制御部１がデータ変換を行う際に、ハングアップしたものとして説明する。

Ｓ１２０１は、フィルターＡをロードしたフィルター制御部１が起動する処理である。ここでは、プロセス情報管理部４０３から終了条件８０６が渡される。

Ｓ１２０２は、データ変換処理スレッドにおいて、フィルター制御部１がパイプライン生成を行う処理である。

Ｓ１２０３は、フィルター制御部１がフィルターＡを用いて、ジョブのデータ変換を行う処理である。この処理の途中でフィルターＡがハングアップに陥るものとする。

Ｓ１２０４は、フィルターＢをロードしたフィルター制御部２が起動する処理である。

Ｓ１２０５は、データ変換処理スレッドにおいて、フィルター制御部２がパイプライン生成を行う処理である。

Ｓ１２０６は、フィルター制御部２がフィルターＢを用いてデータ変換を行う処理である。フィルター制御部２はパイプラインからデータが送信されてくるのを待機する。

Ｓ１２０７は、フィルター制御部２がジョブ制御部４０２から送信されたジョブ中止指示を受信し、ジョブ処理を終了する。

Ｓ１２０８は、フィルター制御部２が、ジョブ中止指示によりジョブを中止した旨を示すログメッセージを、ログ出力部４０８に対して出力依頼する処理である。

Ｓ１２０９は、フィルター制御部２が、ジョブ制御部４０２に対してエラー通知を行う処理である。

Ｓ１２１０は、フィルター制御部２が行う後処理である。

Ｓ１２１１は、ジョブ制御部４０２が、フィルター制御部１へ入力データを送信する。図２８ではＳ６０９の「入力データ送信」に相当する。

Ｓ１２１２は、ジョブ制御部４０２が、フィルター変換完了数を０に初期化する。図２８ではＳ６０９の「フィルター変換完了数初期化」に相当する。

Ｓ１２１３は、ジョブ制御部４０２がジョブ中止指示を送信する。ジョブ制御部４０２は、タイマーを持ち、ジョブの処理が所定時間以上かかる場合には、各フィルター制御部４０４に対してジョブ中止指示を送信する。

Ｓ１２１４は、ジョブ制御部４０２が、設定ファイル（図５）およびフィルター変換完了数を参照し、ハングアップしたフィルターを判定する。ここでは、フィルター変換完了数は０となっており、設定ファイル項目５０２の１番最初のフィルターＡがハングアップと判定する。

Ｓ１２１５は、ジョブ制御部４０２が、稼働実績蓄積部４１１へ「ジョブ終了通知」および「異常終了フィルター通知」を通知する。「ジョブ終了通知」には、そのジョブで変換に用いた各フィルターのフィルター名およびバージョンが記述されている。「異常終了フィルター通知」には、ハングアップしたフィルターのフィルター名およびバージョンが記述されている。

Ｓ１２１６は、稼働実績蓄積部４１１が、ジョブ制御部４０２から「ジョブ終了通知」および「異常終了フィルター通知」を受けて、図２２に示す稼働実績を格納したテーブルを更新する。具体的には、「ジョブ終了通知」を参照して、ジョブで変換に用いた各フィルターの処理ジョブ数１３０３を、それぞれ１カウントアップする。こここでは、フィルターＡ、フィルターＢ、フィルターＣの処理ジョブ数１３０３をそれぞれ１カウントアップする。また、「異常終了フィルター通知」を参照して、ハングアップしたフィルターの異常終了回数１３０４を１カウントアップする。ここでは、フィルターＡの異常終了回数１３０４を１カウントアップする。

Ｓ１２１７は、稼働実績蓄積部４１１が、更新された各フィルターの信頼度の判定を行い、信頼度１３０５を上書きする。

以上のように、ジョブ制御部１がハングアップに陥った場合であっても、他のコンポーネントはハングアップに陥らずに、ハングアップした旨や、ジョブ制御部２がジョブ中止した旨をログファイルに残すことができ、また、稼働実績を蓄積することができる。

＜稼働実績蓄積後の処理＞
稼働実績が蓄積した後のテーブルが、図２３で示す値となっている場合に、ジョブ種別「プリントサービスＡ用変換」のジョブを処理する例について、図２９を用いて説明する。

図２８と同一処理については同一符号とし、説明を省略する。

Ｓ１５０１は、稼働実績蓄積部４１１が、問い合わせを受けた各フィルターの信頼度を、ジョブ制御部４０２のサービスＩＦを通じて、ジョブ制御部４０２へ回答する。フィルターＡの信頼度は「高」、フィルターＢの信頼度は「高」、フィルターＣの信頼度は「低」と回答する。

Ｓ１５０２は、ジョブ制御部４０２が、各フィルターの信頼度をもとに、フィルター制御部４０４の個数および、各フィルターがロードされるフィルター制御部名を決定する。また、決定したフィルター制御部４０４の個数は設定ファイル（図５）の要素５０１のＦｉｌｔｅｒ Ｈｏｓｔ ｎｕｍ属性へ、各フィルターがロードされるフィルター制御部名を要素５０２のＦｉｌｔｅｒ Ｈｏｓｔ ｎａｍｅ属性へ上書きする。

ここでは、フィルター制御部４０４は２個、フィルターＡ４０５はフィルター制御部１、フィルターＢ４０６はフィルター制御部１、フィルターＣ４０７はフィルター制御部２にロードされるように上書きする。

Ｓ１５０３は、ジョブ制御部４０２が、プロセス情報管理部４０３に対して、設定ファイル（図５）にもとづき各フィルターに対応するフィルター制御部４０４のクエリー要求を行い、それぞれのエンドポイントを取得する。ここでは、フィルターＡ４０５およびフィルターＢ４０６をロードしたフィルター制御部１、フィルターＣ４０７をロードしたフィルター制御部２のエンドポイントを取得する。

Ｓ１５０４は、データ変換処理である。ジョブ制御部４０２は、初段のフィルター制御部１に接続されているパイプラインにデータを流した後、「フィルター変換完了数」を０に初期化する。フィルター制御部１は、フィルターＡを用いてデータ変換処理を行う。フィルター制御部１は、フィルターＡを用いたデータ変換処理が完了したらジョブ制御部４０２へ「フィルター変換完了通知」を送信する。ジョブ制御部４０２は、「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。フィルター制御部１は、フィルターＢを用いてデータ変換処理を行う。そして、フィルター制御部１は、フィルター制御部２と接続されているパイプラインにデータを流した後、ジョブ制御部４０２へ「フィルター変換完了通知」を送信する。

ジョブ制御部４０２は、「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。

続いて、フィルター制御部２は、フィルターＣを用いてデータ変換処理を行う。フィルターＣを用いたデータ変換処理が完了したらジョブ制御部４０２へ「変換後データ」「フィルター変換完了通知」を送信する。

ジョブ制御部４０２は、「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。

以上説明したように、信頼度が「高」であるフィルターＡとフィルターＢは、同一のプロセスで処理され、プロセス間通信が発生しないため、パフォーマンスの劣化を抑制することができる。また、信頼度が「低」あるフィルターＣは別プロセスで処理されるため、可用性も確保することができる。

なお、稼働実績蓄積部４１１において稼働実績を蓄積し、その稼働実績から各フィルターの信頼度を判定する方法を説明したが、ジョブ制御部４０２が予め各フィルターの信頼度を示す情報を設定ファイルに保持しても良い。信頼度の低いフィルターがあらかじめ分かっている場合には、ジョブ制御部４０２が各フィルターの信頼度を示す情報を設定ファイルに保持することで、サービス開始時から可溶性を確保するとともにパフォーマンスの劣化を抑制することができる。

また、信頼度判定式には式（１）を用いたが、これに限るものではない。例えば、信頼度判定式に、式（２）に示すようなＭＴＢＦ（平均故障間隔）を用いても良い。
信頼度判定値＝システムの稼働時間／異常終了回数 （２）
また、異常終了したフィルターを判定する例として、ジョブ制御部４０２が、フィルター制御部４０４から「フィルター変換完了通知」を受け取り、「フィルター変換完了数」を更新する方法を示したが、これに限るものではない。例えば、フィルター制御部４０４が、異常終了したフィルターを判定し、そのフィルター種別をダンプファイルとして書き出す機能を有し、ジョブ制御部４０２がそのダンプファイルを参照して、「異常終了フィルター通知」を送信してもよい。

また、上記においては１つのジョブの処理を完了するたびに、稼働実績を更新する例を示したが、これに限るものではない。例えば、１つのジョブに、複数の変換対象である入力データが含まれる場合には、入力データの処理を完了するたびに稼働実績を更新するようにしてもよい。例えば、変換対象である入力データのデータ量が大きく、ある単位で分割して処理する場合には、その分割された単位の処理が完了するたびに稼働実績を更新するようにしてもよい。

また、稼働実績が更新されるたびに、信頼度を判定する例を示したが、これに限るものではない。例えば、処理ジョブ数１３０３が、一定数（例えば１０００回）増加するたびに信頼度を判定するようにしてもよい。

また、１つのジョブ毎に、フィルター制御部の個数、各フィルターがロードされるフィルター制御部名の決定し、フィルター制御部のクエリー（起動）を行ったが、これに限るものではない。例えば、「ジョブ種別情報」が同一であるジョブが続く場合には、フィルター制御部の個数、各フィルターがロードされるフィルター制御部名の決定およびフィルター制御部のクエリー（起動）は１度のみとしてもよい。「ジョブ種別情報」が同一であるジョブを処理する間も稼働実績の蓄積は行い、異常終了が発生した場合はフィルター制御部の個数、各フィルターがロードされるフィルター制御部名の決定およびフィルター制御部のクエリー（起動）を行えばよい。

（実施例５）
実施例４における「クラウドプリントサービス」のサービス開始時は、データ変換処理を構成する各コンポーネントを別プロセスとして起動する。起動後、各フィルターがクラッシュやハングアップした回数などを記録した稼働実績を蓄積し、稼働実績を基に信頼度を判定する。そして、所定値よりも信頼度が高いフィルターは、信頼度「高」として同一プロセスで起動し、所定値よりも信頼度が低いフィルターは、信頼度「低」として別プロセスで起動する。

しかし、実施例４における方法では、サービス開始初期、全てのコンポーネントが別プロセスとして処理されるため、パフォーマンスが劣化してしまう場合がある。

そこで、本実施例では、「クラウドプリントサービス」のサービス開始時は、データ変換処理を構成する各フィルターを同一プロセスとして起動する。その後、各フィルターがクラッシュやハングアップした回数などを記録した稼働実績を蓄積する。各フィルターの処理ジョブ数が、予め定められた一定数（２００００回）を超えた以降から、稼働実績を基に信頼度を判定し、信頼度が高いフィルターは同一プロセスとして起動し、信頼度が低いフィルターは別プロセスとして起動する方法について説明する。

このように処理することで、サービス開始初期は、パフォーマンス劣化を最小限にして稼働実績を蓄積することができ、稼働実績蓄積後は、可用性を確保した上でパフォーマンスの劣化を抑制することができる。

ハードウェア構成、ソフトウェア構成、各コンポーネントの機能は、実施例４と共通のため、同一符号とし説明を省略する。

「クラウドプリントサービス」のサービス開始時は、データ変換処理を構成する各フィルターを同一プロセスとして起動するため、稼働実績が蓄積したテーブルは、図３０で示すように、信頼度１３０５は全て「高」に設定する。

＜正常終了する場合のデータ変換処理＞
図３１を用いて説明する。実施例１で説明した図２８と同一の処理については、同一符号とし、説明を省略する。

Ｓ１６０１は、稼働実績蓄積部４１１が、問い合わせを受けた各フィルターの信頼度を、ジョブ制御部４０２のサービスＩＦを通じて、ジョブ制御部４０２へ回答する。フィルターＡの信頼度は「高」、フィルターＢの信頼度は「高」、フィルターＣの信頼度は「高」と回答する。

Ｓ１６０２は、ジョブ制御部４０２が、各フィルターの信頼度をもとに、フィルター制御部４０４の個数および、各フィルターがロードされるフィルター制御部名を決定する。また、決定したフィルター制御部４０４の個数は設定ファイル（図５）の要素５０１のＦｉｌｔｅｒ Ｈｏｓｔ ｎｕｍ属性へ、各フィルターがロードされるフィルター制御部名を要素５０２のＦｉｌｔｅｒ Ｈｏｓｔ ｎａｍｅ属性へ上書きする。ここでは、フィルター制御部４０４は１個、フィルターＡ４０５はフィルター制御部１、フィルターＢ４０６はフィルター制御部１、フィルターＣ４０７はフィルター制御部１にロードされるように上書きする。

Ｓ１６０３は、ジョブ制御部４０２が、プロセス情報管理部４０３に対して、設定ファイル（図５）にもとづき各フィルターに対応するフィルター制御部４０４のクエリー要求を行い、それぞれのエンドポイントを取得する。ここでは、フィルターＡ４０５、フィルターＢ４０６、フィルターＣ４０７をロードしたフィルター制御部１のエンドポイントを取得する。

Ｓ１６０４は、データ変換処理である。ジョブ制御部４０２は、初段のフィルター制御部１に接続されているパイプラインにデータを流した後、「フィルター変換完了数」を０に初期化する。フィルター制御部１は、フィルターＡを用いてデータ変換処理を行う。フィルター制御部１は、フィルターＡを用いたデータ変換処理が完了したらジョブ制御部４０２へ「フィルター変換完了通知」を送信する。ジョブ制御部４０２は、「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。フィルター制御部１は、フィルターＢを用いてデータ変換処理を行う。フィルター制御部１は、フィルターＢを用いたデータ変換処理が完了したらジョブ制御部４０２へ「フィルター変換完了通知」を送信する。ジョブ制御部４０２は、「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。フィルター制御部１は、フィルターＣを用いてデータ変換処理を行う。

フィルター制御部１は、フィルターＣを用いたデータ変換処理が完了したらジョブ制御部４０２へ「変換後データ」「フィルター変換完了通知」を送信する。ジョブ制御部４０２は、「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。

Ｓ１６０５は、稼働実績蓄積部４１１が、各フィルターの処理ジョブ数が、予め定められた一定数（２００００回）を超えた以降、稼働実績を格納したテーブルが更新されるたびに、更新されたフィルターの信頼度の判定を行い、信頼度１３０５を上書きする。

以上説明したように、サービス開始初期は、信頼度が「高」であるフィルターＡとフィルターＢとフィルターＣは、同一のプロセスで処理されプロセス間通信が発生しないため、パフォーマンスの劣化を最小限するとともに、稼働実績を蓄積ことができる。また、稼働実績蓄積後は、可用性を確保した上でパフォーマンスの劣化を抑制することができる。

＜クラッシュ発生時＞
図３２は、データ変換処理中にクラッシュが発生した際の処理の流れを示した図である。図２９で説明した処理フローのＳ６０７以降の処理で、クラッシュが発生した場合の処理フローである。

ここでは、フィルターＡ、フィルターＢ、フィルターＣをロードしたフィルター制御部１がデータ変換を行う際に， フィルターＡの変換を完了し、フィルターＢの変換処理中にクラッシュしたものとして説明する。

実施例４で説明した図２６と同一処理については同一符号とし、説明を省略する。

Ｓ１７０１は、フィルター制御部１がフィルターＡを用いてデータ変換処理スレッドにて、ジョブのデータ変換を行う処理である。

Ｓ１７０２は、フィルター制御部１が、フィルターＡを用いたデータ変換処理が完了したらジョブ制御部４０２へ「フィルター変換完了通知」を送信する。

Ｓ１７０３は、フィルター制御部１が、フィルターＢを用いてデータ変換処理スレッドにて、ジョブのデータ変換を行う処理である。図３２では、フィルターＢを用いたデータ変換処理中にクラッシュしている。

Ｓ１７０４は、ジョブ制御部４０２が、フィルター制御部１から「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。ここでは、「フィルター変換完了数」は１に更新される。

Ｓ１７０５は、ジョブ制御部４０２が、フィルター制御部１のパイプラインの切断を検知する処理である。具体的には、フィルター制御部１、ジョブ制御部４０２間で定期的に生存確認のためのパケットを送り合い、パケットが途絶えたことをタイムアウトにより検知する。

Ｓ１７０６は、ジョブ制御部４０２が、パイプライン切断を示すログメッセージを、ログ出力部４０８に対して出力依頼する処理である。ログ出力部４０８は、このメッセージを受信し、ログファイルにパイプライン切断された旨を追記する。

Ｓ１７０７は、ジョブ制御部４０２が、設定ファイル（図５）およびフィルター変換完了数を参照し、クラッシュしたフィルターを判定する。ここでは、フィルター変換完了数は１となっており、設定ファイル項目５０２の２番目のフィルターＢがクラッシュしたと判定する。

Ｓ１７０８は、稼働実績蓄積部４１１が、更新された各フィルターの処理ジョブ数が、予め定められた一定数（２００００回）を超えた場合に、信頼度の判定を行う。

各フィルターの処理ジョブ数１３０３が、予め定められた一定数（２００００回）を超えた場合は、稼働実績を基に信頼度を判定し、信頼度１３０５を上書きする。つまり、各フィルターの処理ジョブ数１３０２が、予め定められた一定数（２００００回）以下である場合は、信頼度判定は行わないため、信頼度１３０５は初期値である「高」となっている。

以上のように、フィルター制御部１がクラッシュした場合であっても、他のコンポーネント（ジョブ制御部４０２、ジョブ処理受け付け部）はクラッシュせずに、パイプラインが切断した旨をログファイルに残すことができる。また、稼働実績を蓄積することができる。

＜ハングアップ発生時＞
図３３は、データ変換処理中にハングアップが発生した際の処理の流れを示した図である。図２９で説明した処理フローのＳ６０７以降の処理で、ハングアップが発生した場合の処理フローである。

ここでは、フィルターＡ、フィルターＢ、フィルターＣをロードしたフィルター制御部１がデータ変換を行う際に， フィルターＡの変換を完了し、フィルターＢの変換処理中にハングアップしたものとして説明する。

実施例４で説明した図２７と同一処理については同一符号とし、説明を省略する。

Ｓ１８０１は、フィルター制御部１がフィルターＡを用いてデータ変換処理スレッドにて、ジョブのデータ変換を行う処理である。

Ｓ１８０２は、フィルター制御部１が、フィルターＡを用いたデータ変換処理が完了したらジョブ制御部４０２へ「フィルター変換完了通知」を送信する。

Ｓ１８０３は、フィルター制御部１が、フィルターＢを用いてデータ変換処理スレッドにて、ジョブのデータ変換を行う処理である。図３３では、フィルターＢを用いたデータ変換処理中にハングアップに陥るものとする。

Ｓ１８０４は、ジョブ制御部４０２が、フィルター制御部１から「フィルター変換完了通知」を受け取ると、「フィルター変換完了数」を１カウントアップする。ここでは、「フィルター変換完了数」は１に更新される。

Ｓ１８０５は、ジョブ制御部４０２が、設定ファイル（図５）およびフィルター変換完了数を参照し、ハングアップしたフィルターを判定する。ここでは、フィルター変換完了数は１となっており、設定ファイル項目５０２の２番目のフィルターＢがハングアップしたと判定する。

Ｓ１８０６は、稼働実績蓄積部４１１が、更新された各フィルターの処理ジョブ数が、予め定められた一定数（２００００回）を超えた場合に、信頼度の判定を行う。

各フィルターの処理ジョブ数１３０３が、予め定められた一定数（２００００回）を超えた場合は、稼働実績を基に信頼度を判定し、信頼度１３０５を上書きする。つまり、各フィルターの処理ジョブ数１３０３が、予め定められた一定数（２００００回）以下である場合は、信頼度判定は行わないため、信頼度１３０５は初期値である「高」となっている。以上のように、フィルター制御部１がハングアップした場合であっても、他のコンポーネント（ジョブ制御部４０２、ジョブ処理受け付け部）はハングアップせずに、パイプラインが切断した旨をログファイルに残すことができる。また、稼働実績を蓄積することができる。

以上説明したように処理することで、サービス開始初期は、パフォーマンスの劣化を最小限にして稼働実績を蓄積することができ、稼働実績蓄積後は、可用性を確保した上でパフォーマンスの劣化を抑制することができる。

（実施例６）
実施例４、５では稼働実績蓄積部４１１が、図２２、図２３、図３０で示すように、「フィルター名１３０１」「バージョン１３０２」毎の動作実績を格納したテーブルを保持する例を説明した。

しかし、同じフィルターＣでも、ジョブ種別「プリントサービスＡ用変換」では異常終了し易いが、ジョブ種別「プリントサービスＣ用変換」では異常終了しないといった動作実績となることが考えられる。

例えば、ジョブ種別「プリントサービスＡ用変換」における、前処理のフィルターＢの出力値が、フィルターＣで許容される入力形式に合致しておらず、かつ、フィルターＣにおける入力値チェックが正しく実装されておらず異常終了する。しかし、種別「プリントサービスＣ用変換」における、前処理のフィルターＺの出力値は、フィルターＣ、で許容される入力形式に合致しており、問題無く動作するといった場合である。

このような場合に、「フィルター名１３０１」「バージョン１３０２」毎の動作実績を基に信頼度を判定することは適切ではない。すなわち、ジョブ種別「プリントサービスＣ用変換」において、フィルターＣは、一度も異常終了したことが無いのに、別プロセスで処理されてしまうことになる。そのため、パフォーマンスが劣化してしまうという問題がある。

そこで、本実施例では、稼働実績蓄積部４１１が、「ジョブ種別」「フィルター名１３０１」「バージョン１３０２」毎に、稼働実績を格納したテーブル保持するように変更する。その他の処理は、実施例４と同様であるため、説明を省略する。

このようにすることで、ジョブ種別「プリントサービスＣ用変換」においては、フィルターＣ、バージョン１．０．０．０は、信頼度「高」と判定され同一プロセスで処理されるため、パフォーマンス劣化は発生しない。

なお、図３４の１９０２で示すように、稼働実績蓄積部４１１が、「前処理のフィルターと後処理のフィルターの順列」毎に、動作実績を格納したテーブル保持するように変更しても、同様の効果を得ることができる。

１９０３の列は前処理のフィルターのフィルター名を示し、１９０４の列は前処理のフィルターのバージョンを示し、１９０５の列は後処理のフィルターのフィルター名を示し、１９０６の列は後処理のフィルターのバージョンを示している。１９０７の行は、フィルターＢが処理され、次にフィルターＣが処理される場合の稼働実績を示している。また、１９０７の行は、ジョブ制御部４０２から入力データが入力され、フィルターＡがジョブの一番初めに処理する場合の稼働実績を示している。

尚、上記実施例における各処理は、各処理を行うためのコンピュータプログラムが格納された記録媒体から、一般的なパーソナルコンピュータがコンピュータプログラムを読み取り、実行することによっても達成することが可能である。

Claims (18)

1. 画像を生成するための入力データを取得する取得手段と、
   前記入力データを第一のプロセスで起動された第一のデータ変換フィルターでデータ変換して中間データを生成し、当該中間データを前記第一のプロセスとは異なる第二のプロセスで起動された第二のデータ変換フィルターでデータ変換して画像データを生成する変換手段と、
   前記画像データを出力する出力手段と、
   を有することを特徴とする情報処理装置。
2. 前記出力手段で出力される前記画像データは、印刷用の画像データであることを特徴とする請求項１に記載の情報処理装置。
3. 前記取得手段は、前記入力データをネットワーク接続されたクライアントコンピュータから取得し、
   前記出力手段は、前記画像データをネットワーク接続されたプリンターに出力することを特徴とする請求項１もしくは２のいずれか１項に記載の情報処理装置。
4. プロセスの起動条件を取得する起動条件取得手段と、
   前記プロセスの起動条件に基づき、前記第一のプロセスと前記第二のプロセスとを起動させる起動手段と、を更に有することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記プロセスの起動条件は、起動可能なプロセス数と、プロセスごとの常時起動の要否との少なくともいずれか一つであることを特徴とする請求項４に記載の情報処理装置。
6. 前記第一のデータ変換と前記第二のデータ変換それぞれのログを出力するログ出力部を更に有することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記情報処理装置で実行する複数のプロセスをグループ分けするグループを設定するグループ設定手段と、
   前記グループごとに設定された複数のログ出力部と、を有することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
8. 前記複数のログ出力部は、それぞれ排他的にログを出力することを特徴とする請求項７に記載の情報処理装置。
9. 前記グループ設定手段は、前記複数のログ出力部それぞれに問い合わせるための接続情報を排他的に制御することを特徴とする請求項７もしくは８のいずれか１項に記載の情報処理装置。
10. 前記グループ設定手段で設定されたグループを削除する削除手段を更に有することを特徴とする請求項７乃至９のいずれか１項に記載の情報処理装置。
11. 前記変換手段は、
    前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとの信頼度が共に所定値よりも高い場合は、前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとのデータ変換を同一のプロセスで行い、
    前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとの少なくとも一つの信頼度が前記所定値よりも低い場合は、前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとのデータ変換それぞれを異なるプロセスで行うことを特徴とする請求項１に記載の情報処理装置。
12. 前記データ変換の稼働実績に基づき、前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとの信頼度を設定する設定手段を更に有することを特徴とする請求項１１に記載の情報処理装置。
13. 前記データ変換の異常終了回数に基づき、前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとの信頼度を設定する設定手段を更に有することを特徴とする請求項１１もしくは１２のいずれか１項に記載の情報処理装置。
14. 初期の設定においては、前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとの信頼度は前記所定値よりも高く設定されていることを特徴とする請求項１１乃至１３のいずれか１項に記載の情報処理装置。
15. 初期の設定においては、前記第一のデータ変換フィルターと前記第二のデータ変換フィルターとの信頼度は前記所定値よりも低く設定されていることを特徴とする請求項１１乃至１３のいずれか１項に記載の情報処理装置。
16. 前記信頼度は、ジョブ種別ごとに設定されていることを特徴とする請求項１１乃至１５のいずれか１項に記載の情報処理装置。
17. 取得手段が、画像を生成するための入力データを取得する取得工程と、
    変換手段が、前記入力データを第一のプロセスで起動された第一のデータ変換フィルターでデータ変換して中間データを生成し、当該中間データを前記第一のプロセスとは異なる第二のプロセスで起動された第二のデータ変換フィルターでデータ変換して画像データを生成する変換工程と、
    出力手段が、前記画像データを出力する出力工程と、
    を有することを特徴とする情報処理方法。
18. コンピュータを、
    画像を生成するための入力データを取得する取得手段と、
    前記入力データを第一のプロセスで起動された第一のデータ変換フィルターでデータ変換して中間データを生成し、当該中間データを前記第一のプロセスとは異なる第二のプロセスで起動された第二のデータ変換フィルターでデータ変換して画像データを生成する変換手段と、
    前記画像データを出力する出力手段と、を有することを特徴とする情報処理装置として機能させるためのコンピュータプログラム。

Images