(57)【要約】      （修正有）【課題】マルチキャスト通信を用いた複数のコンポーネントを互いに連結させて動作させ、印刷装置に出力可能な形式にデータを変換する方法を提供する。【解決手段】動作するＰＣ毎に異なるマルチキャストアドレスとポート番号を使用するか否かの指示手段、起動時に前記指示を受けてマルチキャストアドレスとポート番号をランダムに選定するアドレスおよびポート選定手段、前記選定手段によって決定したマルチキャストアドレスとポート番号で特定されるマルチキャスト通信に参加し特定の名称のコンポーネントが同一マルチキャスト通信に参加しているか否かを検出する手段、前記アドレスおよびポート選定手段が選定したアドレスとポート番号を設定ファイルに出力する出力手段から構成される印刷システム。【選択図】図１
2017004072.tif 000002
【特許請求の範囲】
【請求項１】
複数の機能コンポーネント（２２００，２３００，２５００、２６００、２７００、２８００，２９００）を独立したプロセスとして実行し、マルチキャスト通信を用いたコントロールバス（５００２）で互いに連携させ以ってサービスを提供するサービス（２１００）であって以下の手段を有するもの：
・動作するＰＣ毎に異なるマルチキャストアドレスとポート番号を使用するか否かの指示手段（S００１）
・起動時に前記指示を受けてマルチキャストアドレスとポート番号をランダムに選定するアドレスおよびポート選定手段（S００５）
・前記選定手段によって決定したマルチキャストアドレスとポート番号で特定されるマルチキャスト通信に参加し特定の名称のコンポーネントが同一マルチキャスト通信に参加しているか否かを検出する手段（S００６、S００７）
・前記アドレスおよびポート選定手段が選定したアドレスとポート番号を設定ファイルに出力する出力手段（S００８）
【請求項２】
複数の機能コンポーネント（２２００，２３００，２５００、２６００、２７００、２８００，２９００）を独立したプロセスとして実行し、マルチキャスト通信を用いたコントロールバス（５００２）で互いに連携させ以ってサービスを提供するサービス（２１００）であって以下の処理ステップを有するもの：
・動作するＰＣ毎に異なるマルチキャストアドレスとポート番号を使用するか否かの指示ステップ（S００１）
・起動時に前記指示を受けてマルチキャストアドレスとポート番号をランダムに選定するアドレスおよびポート選定ステップ（S００５）
・前記選定手段によって決定したマルチキャストアドレスとポート番号で特定されるマルチキャスト通信に参加し特定の名称のコンポーネントが同一マルチキャスト通信に参加しているか否かを検出するステップ（S００６、S００７）
・前記アドレスおよびポート選定手段が選定したアドレスとポート番号を設定ファイルに出力する出力ステップ（S００８）
【請求項３】
コンピュータが読出し可能な記憶媒体に記録された制御コードであり、複数の機能コンポーネント（２２００，２３００，２５００、２６００、２７００、２８００，２９００）を独立したプロセスとして実行し、マルチキャスト通信を用いたコントロールバス（５００２）で互いに連携させ以ってサービスを提供するサービス（２１００）およびそのサービスが以下の処理ステップを有するもの：
・動作するＰＣ毎に異なるマルチキャストアドレスとポート番号を使用するか否かの指示ステップ（S００１）
・起動時に前記指示を受けてマルチキャストアドレスとポート番号をランダムに選定するアドレスおよびポート選定ステップ（S００５）
・前記選定手段によって決定したマルチキャストアドレスとポート番号で特定されるマルチキャスト通信に参加し特定の名称のコンポーネントが同一マルチキャスト通信に参加しているか否かを検出するステップ（S００６、S００７）
・前記アドレスおよびポート選定手段が選定したアドレスとポート番号を設定ファイルに出力する出力ステップ（S００８）
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷装置に出力可能な形式にデータを変換するデータ変換サービスに関する。
【背景技術】
【０００２】
ユーザ端末からのリクエストによりWebサービスが印刷データを生成し、その印刷データを印刷装置で受信して処理し、印刷を実行するシステムが存在する。そのようなWebサービスの代表例は特許文献１に開示されている“cloud print service”が知られている（以下略して“CPS“と称する）。CPSは各プリンターベンダーに仕様を公開し、仕様に沿ったプリンターを開発してもらうことでサービスの急速な拡大と利用者への利便性を実現しようとするものである。
【０００３】
特許文献１には、CPSにおけるプリンターの登録と選択、印刷データの生成に関する技術が開示されている。特徴として、CPSはプリンターベンダー毎に特有のページ記述言語（PDL）やプリントデータフォーマットに従った印刷データを生成するのではなく、ベンダー非依存の統一的なフォーマットで印刷データを生成し、各プリンターにその印刷データを直接入力データとして受け取ってもらい印刷を実現する点にある。
【０００４】
ベンダー非依存の統一的なフォーマットとしてはPortable Document Format(PDF)が挙げられている。この仕様に従えば、CPSはプリンターベンダー非依存の画一的な印刷データ生成を行うことができる。サービスの利用者にとってはどのようなベンダーのプリンターであろうがCPSに準拠したプリンターであれば自分の要求する印刷がどこからでも依頼できてかつ印刷物を受け取れる利便性が得られる。
【０００５】
これまでプリンタードライバーはアプリケーションプログラムが出力するドキュメントをプリンターが理解できるPDLで記述した印刷データに変換する処理を行ってきた。加えてプリンターの特性、トナー、インク、記録紙などに応じて色味の調整や、印刷モードの選定などの処理も行っていた。ところが、プリンタードライバーはユーザ端末上で動作していた為、少なからず端末のリソースを消費する。昨今、ユーザ端末はその形状をデスクトップ型PC、ノート型のPCからスレート（タブレット）型やスマートフォンまで広げている。端末形状は小型化しバッテリーの消費が大きな課題となっている。また多様化するこれらの端末のOSに追従してプリンタードライバーを提供していくことはプリンターベンダーにとっては大きな負担となっている。
【０００６】
このように、プリンタードライバーを不要とするCPSはユーザとプリンターベンダーの両者にとって一見、救世主となるように見える。しかし、実際には、プリンタードライバーが必要とされていた本質的な意義であるプリンターの機能と特性を生かしたデータ変換はやはり必要あることには変わりはない。小型化するユーザ端末とプリンタードライバーを端末上で動作させることなく今までと同じ画質、機能を提供する方策としてプリンタードライバーをクラウド上で動作させる方法が実用となっている。プリンターベンダーは自社のプリンターのプリンタードライバーをWebサービスとして動作させるサービスを提供することで、特許文献１に示すCPSと同等の利便性とこれまでのプリンタードライバーが提供していたプリンターの特性を生かした印刷データの生成を両立させようとしている。プリンタードライバーをWebサービス化する方法にはそれまでとは異なる新たな要件が課されることになる。
【０００７】
第一にWebサービスには高可用性が求められる。従ってWebサービスを構成するプログラムにメモリリークがあれば長期に渡る稼働でWebサービスが稼働するサーバー全体の稼働に影響を与えることになる。メモリリークに対する対策はWebサービスの必須要件となっている。対策の一つとして、Webサービスを複数の機能コンポーネントに分割し、各々のコンポーネントを独立したプロセスとして動作させることにする。機能コンポーネントは、その機能の複雑度やプログラムコードの量、処理内容における例外処理の発生頻度によってメモリリークの発生量に差があることが経験的に知られている。メモリリークの発生量が多いあるいは発生しやすい機能コンポーネントに対しては高頻度で再起動を行いリークの解消を図り、以てサーバー全体のリーク量の増加を抑え、Webサービスの高可用性を図る対策が考えられる。
【０００８】
さらにWebサービス化されたプリンタードライバーをクラウドサービスとして動作させる運用も進んでいる。この運用はWebサービスのホスティングに関する部分を専用に提供する事業者に委託するというビジネス形態である。ホスティングに必要なハードウエア、OS、仮想サーバー、ロードバランシング機能を事業者からIaaS(Infrastructure as a Service)として購入して利用することになる。この利用形態ではWebサービスを提供する事業者はそのサービスの開発に専念することができる。
【０００９】
不特定多数のクライアントからのアクセスに備えることが見込まれるWebサービスでは主流な運用形態となってきている。このような運用形態をとるWebサービスにあってはアクセス負荷の分散（ロードバランシング）が必須である。具体的には高負荷時であっても応答性の低下を避けるための施策として複数のサーバーを負荷に応じて動的に追加（スケールアウト）して要求をそれらの間で分散させる。
【００１０】
スケールアウトで追加されるサーバーは通常は物理サーバーではなく、仮想サーバーである。これは物理ＰＣ上に複数の仮想的なＰＣを構築し、各仮想ＰＣ上では予め作成してあるサーバーイメージファイルをロードして実行することで、同一内容のサーバーＰＣを複数起動させる技術によって提供される。このサーバーイメージファイルは仮想サーバーを起動した後にＯＳおよびその上で動作させるアプリケーションプログラム一切をインストールしさらに必要な設定を施して動作準備ができた仮想サーバーを作り上げた時点でそのＯＳも含めたメモリイメージをファイル化することで得られる。
【００１１】
ファイル化されたメモリイメージは別の仮想サーバー上にロードすると、内容が同一の仮想サーバーの複製が起動できることになる。この技術によりスケールアウトが管理者の手動に拠らないで自動的に迅速に行われることが可能となる。スケールアウトはスケールインと共に仮想サーバーのロードバランス機能として提供される。ここで重要なのは、各仮想サーバーの作成と起動時にはインストール作業は実行されないということである。すなわち、インストール時に動作するインストーラープログラムの働きに依存して行っていた処理のうち、ＰＣ毎のユニーク性を作り出すような処理（例えばＰＣ毎に異なる名称をもつファイルを作成するなど）は実行できないということを意味する。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許出願公開第２０１１／０２９９１１０号明細書
【非特許文献】
【００１３】
【非特許文献１】Oracle(R) Coherence開発者ガイド(https://docs.oracle.com/cd/E26853 01/coh.371/b65026/cluster setup.htm)
【発明の概要】
【発明が解決しようとする課題】
【００１４】
マルチキャスト通信を用いて複数のコンポーネントを互いに連結させて動作させるシステムとして構成されたWebサービスをスケールアウト・スケールイン機能が提供されている仮想サーバー上で動作させる場合には問題が発生する。
【００１５】
マルチキャスト通信を用いて複数のコンポーネントを互いに連結させて動作させるシステムの例は非特許文献１にみられる。この例におけるシステムでも、動作させる環境によってはマルチキャストアドレスが複数のＰＣで同一になる可能性が指摘されている。
【００１６】
しかしその解決方法としては、コンフィギュレーションファイルにユニークなマルチキャストアドレスとポート番号を管理者の手によって固定的に設定することが求められているのみである。この回避方法では前述したようにオートスケールアウト/オートスケールインが行われる仮想サーバー上ではコンフィギュレーションファイルは同一内容で複製されて利用されるため起動される仮想サーバー毎にマルチキャストアドレスを個別に変更することが不可能である。従って、非特許文献１のシステムにおいてはマルチキャスト通信そのものの利用を行わなくするという選択しかとれない。
【００１７】
本発明は、このような課題を鑑みてなされたものであり、複数の仮想サーバー上で同一のコンフィギュレーションファイルが複製されて利用される状況であってかつ、それらのサーバー毎に異なるマルチキャストアドレスとポート番号を与える必要がある場合には、仮想サーバー毎に異なるマルチキャストアドレスとポート番号が設定されるシステムが求められる。さらにシステムには前述の様にインストーラープログラムに依存することが不可能であるため、インストーラーの力を借りることなく、マルチキャストアドレスとポート番号を設定する手段が求められる。
【課題を解決するための手段】
【００１８】
本発明においては以下の手段を用いて課題を解決する。
・動作するＰＣ毎に異なるマルチキャストアドレスとポート番号を使用するか否かの指示手段
・起動時に前記指示を受けてマルチキャストアドレスとポート番号をランダムに選定するアドレスおよびポート選定手段
・前記選定手段によって決定したマルチキャストアドレスとポート番号で特定されるマルチキャスト通信に参加し特定の名称のコンポーネントが同一マルチキャスト通信に参加しているか否かを検出する手段
・前記アドレスおよびポート選定手段が選定したアドレスとポート番号を設定ファイルに出力する出力手段
【発明の効果】
【００１９】
複数の機能コンポーネントをバスによって連携させることによってサービスを提供するように構成された分散サービスであって、以下の効果をもたらす。該分散サービスを動作させるサーバーＰＣがオートスケールアウトおよびオートスケールイン機能を備えた仮想サーバーであっても所望の動作が行える。すなわち、異なる仮想サーバーを跨いだ分散サービスコンポーネントの配置を行わせたくない場合にも起動された仮想サーバー毎に該分散サービスを独立して稼動させ、ある仮想サーバーのスケールインによる消滅の影響を受けることがない運用が可能となる。
【図面の簡単な説明】
【００２０】
【図１】ロケーターの起動時処理のフローチャートである。
【図２】プリントシステムおよびその利用者（印刷依頼者）の関係を示すユースケース図である。
【図３】サーバーPC上で動作するソフトウエアを説明するブロック図である。
【図４】印刷データ変換サービスとそれが依存するコンポーネント群を示す図である。
【図５】コントロールバスが複数のサーバーＰＣを跨いで共有される状況を示す図である。
【図６】印刷データ変換サービスが動作するサーバーPCのハードウエア構成図である。
【図７】コンポーネント群と対応するコンフィギュレーションファイルの関係を示す図である。
【図８】各コンポーネント用のコンフィギュレーションファイルの内容を示す図である。
【発明を実施するための形態】
【００２１】
以下、本発明を実施するための形態を図面に基づいて説明する。
【実施例１】
【００２２】
図２は本発明の第一の実施例である印刷データ変換サービスとその依頼者から成る構成図である。
【００２３】
ドキュメントから印刷データへの変換を依頼する依頼者（５０）は変換要求を送出する機器として、パーソナルコンピュータ（２０）、タブレットPC（３０）や携帯端末（４０）などの機器を利用する。依頼者（５０）はこれらの機器の内部で動作しているアプリケーション（不図示）を操作して、ネットワーク（１０）上に存在する印刷データ変換サービス（２１００）に対してドキュメントから印刷データへの変換を依頼する。印刷データ変換サービス（２１００）はサーバーPC（８０）上でWell-knownのURLを公開している、いわゆるWebサービスとして動作しているプログラムである。サーバーPC（８０）上では前記URLに対して到着した依頼を印刷データ変換サービス（２１００）に転送するWebサーバー（４１００）も動作している。URLへ到着する依頼は通常多数になるため、単一のサーバーPC（８０）では処理させず、複数のサーバーPC（８０）に処理させる構成とする。従って、複数のサーバーPC（８０）の前段にロードバランサー（７０）を設置し各サーバーPC（８０）に転送される依頼が均一に配分されるように構成する。
【００２４】
印刷データ変換サービス（２１００）が提供するサービスは、依頼者（５０）が指定するデータをプリンタ（６０）で印刷できる形式に変換することである。依頼者が指定するデータにはテキストドキュメント、画像ファイルなど各種のアプリケーションプログラムで作成されたフォーマットが存在する。一方、プリンタ（６０）が印刷データとして受け付けるデータは前述のフォーマットとは異なり、PDLで記述されたデータや、印刷部数等の印刷を制御するための命令とパラメータを備えたPJL( Print Job Language )で記述されたデータとなっている。このように、依頼者（５０）とプリンタ（６０）の間には扱うデータ形式の差異が存在する為に、その差異を埋るプログラムが必要とされる。通常この変換処理を行うのがプリンタードライバーと呼ばれるプログラムである。プリンタードライバーは依頼者（５０）が操作する前述のアプリケーションプログラムが動作しているPC上で動作させることが通常である。しかし、プリンタードライバーの処理は比較的CPU、メモリなどのリソースを必要とする重い処理であるため、依頼者（５０）の操作するPCの保持するリソースが少ない場合には印刷処理が実用的でなくなる程時間のかかる処理になってしまう。依頼者（５０）が操作する端末（パーソナルコンピュータ（２０）、タブレットPC（３０）や携帯端末（４０））などリソースの比較的少ない端末からの印刷の需要が高まるにつれプリンタードライバーの処理をインターネット上のサービスで行わせることの重要性が増している。
【００２５】
依頼者（５０）は前述の各種端末から前述のURLに対して印刷データをプリンタ（６０）で印刷できる形式に変換するように依頼を行う。依頼に応じてサーバーPC（８０）上で動作している印刷データ変換サービス（２１００）が生成した変換後のデータは前述の端末に対して返送される。依頼者（５０）の指示によっては変換後のデータは印刷データ変換サービス（２１００）がアクセス可能なファイルサーバーPC（９０）で保管される場合もある。
【００２６】
図６は印刷データ変換サービス（２１００）をはじめとするソフトウエア群が動作するコンピュータのハードウエア構成図である。印刷データ変換サービス（２１００）はＯＳ（オペレーティングシステム）上で動作するアプリケーションプログラムであり、ＨＤＤ（１００２）あるいはＲＯＭ（１００３）に格納されている。ＣＰＵ（１００５）がＯＳとアプリケーションプログラムをＨＤＤ（１００２）あるいはＲＯＭ（１００３）から読み出してＲＡＭ（１００４）にロードし、実行することで様々な処理が進行しプリントサービスサーバとしての機能を実現する。処理結果はファイルとしてＨＤＤ（１００２）に格納され、あるいはデータとしてＲＡＭ（１００４）に記憶される。アプリケーションプログラムはコンピュータに接続されている入力装置（１００７）から使用者の入力、各種センサの読み取り値を取得する。さらに出力装置（１００６）に対して情報を出力し、処理結果を表示する。さらに、通信装置（１００８）を介してネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウエアはコントロールバス（１００１）で互いに接続されていてアプリケーションプログラムから操作できるように構成されている。
【００２７】
図３は印刷データ変換サービス（２１００）を含むソフトウエア群がサーバーPC（８０）上でどのように構成されているかを示すブロック図である。Webサーバー（４１００）は依頼者（５０）が操作したパーソナルコンピュータ（２０）上のアプリケーションからHTTPプロトコルで送信されたリクエストを受け取る。ロードバランサー（７０）はWebサーバー（４１００）の前段に位置し、複数のサーバーPC（８０）上で動作しているWebサーバー（４１００）に振り分ける。この振り分ける方式は種々知られているがその詳細は本発明には関係がないため説明を省略する。
【００２８】
ここで、サーバーPC（８０）は必ずしも物理的な一台のサーバーPCを意味する必要はない。現時点で単一のPC上に複数の仮想的なPCを出現させる仮想化技術が一般的となっており、ソフトウエアからみれば自身が動作しているオペレーティングシステムが仮想的に作り出されたものか否かは判別がつかないか、あるいは判別する必要がない。従って本発明におけるサーバーPC（８０）は「場合によっては仮想化されたPC」を意味する場合もある。これ以降、「PC」という表現は物理的なPCと仮想化されたPCの両方を意味するものとして扱う。
【００２９】
アプリケーションサーバー（４２００）は要求の送付先として指定されたURLを解析し、関連つけられている印刷データ変換サービス（２１００）を決定するソフトウエアである。通常Webサーバー（４１００）とアプリケーションサーバー（４２００）は複数種のサービスを扱うことが可能であり、URLから対応するサービスを特定して要求を振り分けることができる。本実施例ではその複数種のサービスの一つが印刷データ変換サービス（２１００）であることを想定している。このサービスの他にもサービスが稼働しているが発明の説明においては印刷データ変換サービス（２１００）以外のサービスは省略する。
【００３０】
印刷データ変換サービス（２１００）は単一のプロセスではなく、複数プロセスが共同して動作することでサービスを提供する形態をとっている。以下では「印刷データ変換サービス」という場合にはこれら複数のプロセスを総称していることに留意してもらいたい。ロケーター（２５００）とロガー（２６００）は印刷データ変換サービス（２１００）とは独立して存在するプロセスである。アプリケーションサーバー（４２００）は複数の要求を並列実行させるために、印刷データ変換サービス（２１００）を複数起動し、各々に要求を振り分ける。この場合でも、ロケーター（２５００）とロガー（２６００）は各々一個のプロセスとして存在している。アプリケーションサーバー（４２００）はさらに、印刷データ変換サービス（２１００）が動作する際に依頼者（５０）からの一連の要求を特定する為のセッションを管理する。具体的には、同一の依頼者（５０）からの要求は同一の印刷データ変換サービス（２１００）に転送するセッション・アフィニティーを実現している。
【００３１】
（ロケーター）
印刷データ変換サービス（２１００）を構成するコンポーネント群が利用するロケータ（２５００）は特別な役割を担っている。ロケータ（２５００）はアプリケーションサーバー（４２００）が起動した時点で既に起動している特殊なプロセスである。ロケーター（２５００）の起動の方法はサーバーPC（８０）上で動作しているオペレーティングシステム（OS）によって種々の方法が存在する。例えば、Windowsであれば”Windows Service”というシステム起動時に自動的に起動される特殊なプロセスとして実装することが可能であり、Linux やUnixではデーモンプロセスとして動作させることが可能である。起動時には図８に示すようなＸＭＬ形式のコンフィギュレーションファイル（２００）を起動時パラメータとして与えられて起動する。
【００３２】
ロケーター（２５００）はコンポーネントの生成の責務を担っている。この場合も、図７に示すように他のコンポーネント群（２０２）を起動する際の起動時パラメータとしてそれぞれのコンポーネント用のコンフィギュレーションファイル（２０１）を与えて起動する。これらの各コンポーネント用のコンフィギュレーションファイル（２０１）にはコンポーネント依存の設定値が記載されているほか、後述するコントロールバスを特定するマルチキャストアドレスとポート番号が記載されている。
【００３３】
ロケータ（２５００）は更に他のコンポーネントからの求めに応じて別のコンポーネントのアクセスポイントを返すという機能を提供する。アクセスポイントとはTCP/IPのリスンポートを指す。あるコンポーネントは別のコンポーネントが公開しているアクセスポイントを取得し、そのアクセスポイントにアクセスすることでそのコンポーネントが提供する機能を利用する。
【００３４】
（ロガー）
ロガー（２６００）はプロセスとして同一コントロールバス（５２００）上に一つ存在する。コントロールバス（５２００）上のコンポーネントはジョブの実行中にログ出力を行う。ログの出力対象としてはファイルが一般的であるが、すべてのコンポーネントが独立してログファイルの出力を行うとサーバーPC（８０）上のファイルI/Oの発生回数が増大し印刷データ変換サービス（２１００）全体のパフォーマンスが低下してしまう。そこで、各コンポーネントはログデータをロガー（２６００）に対してネットワークを介して送りつけ、ロガー（２６００）が一定量のログデータの蓄積時点でログファイルに出力することになっている。ログファイルの出力パス等の設定はロガー（２６００）が起動される際に渡されるコンフィギュレーションファイルで指定される。
【００３５】
（印刷データ変換サービス）
図４は印刷データ変換サービス（２１００）の動作に関連するソフトウエアコンポーネント群の関連を説明する図である。印刷データ変換サービス（２１００）は先に説明したように複数のプロセスの共同体として動作している。その構成要素は印刷サービスゲートウェイ（２１１０）、プロキシーモジュール（２２００）、フィルターホスト（２４００）と各種フィルター群（２７００，２８００，２９００）となっている。ここでは説明の為に各種フィルターは3種類示してあるが、実際には多くのフィルターが存在しており、さらにその組み合わせは固定化されておらず、生成される印刷データ変換サービス（２１００）毎に異なるフィルターが使用される可能性がある。
【００３６】
（印刷サービスゲートウェイ）
印刷データ変換サービス（２１００）に対するサービス依頼を受け付けるのはプロセスとして存在する印刷サービスゲートウェイ（２１１０）であり、その起動はアプリケーションサーバー（４２００）が行う。印刷サービスゲートウェイ（２１１０）はプロキシーモジュール（２２００）をロードし、Application Programming Interface(API)で提供している関数群を呼び出すことで変換処理の実行を依頼し、さらに結果を受領する。
【００３７】
（プロキシーモジュール）
印刷データ変換処理の依頼窓口として機能する。提供しているAPIを通じてサービスの依頼を受けてジョブの内容を後段のジョブコントローラー（２３００）に送信する。さらにジョブの処理結果をョブコントローラー（２３００）から受信し前記APIを通じて印刷サービスゲートウェイ（２１１０）に返却する。
【００３８】
（ジョブコントローラー）
プロキシーモジュール（２２００）を介してジョブ実行を依頼されたジョブコントローラ（２３００）はジョブ定義ファイル、プリントチケット、印刷データを解析して変換に必要なフィルターを選定する。次に、ジョブに含まれている変換先の印刷データ形式を取得し、変換元の印刷データ形式と変換先の印刷データ形式の両者が確定した時点で、この変換に必要なフィルター群を選定する。必要なフィルターの組み合わせとその変換順番は固定的な知識としてジョブコントローラ（２３００）に実装されている。
【００３９】
必要な複数のフィルターを選定したあとはこれらフィルターをロードしているフィルターホスト（２４００）を取得する。この例では変換に必要なフィルターとして、フィルターA（２７００）、フィルターB(２８００)、フィルターC（２９００）が必要であり、それらはそれぞれフィルターホスト（２４００）にロードされている。
【００４０】
ジョブコントローラ（２３００）はフィルターA（２７００）、フィルターB(２８００)、フィルターC（２９００）との間で、パイプライン（３０００）と呼ばれるデータ転送チャネルを作成する。パイプライン（３０００）は基本的に片方向にのみデータを転送する。ジョブコントローラー（２３００）→フィルターA（２７００）→フィルターB(２８００) →フィルターC（２９００）→ジョブコントローラ（２３００）と一周するようにパイプライン（３０００）が構成される。また、ジョブコントローラ（２３００）はプロキシーモジュール（２２００）との間にもパイプライン（３０００）を作成する。このようにパイプライン（３０００）を作成することで、プロキシーモジュール（２２００）から印刷データが複数のコンポーネントを還流し、最後に変換が終了した形で再びプロキシーモジュール（２２００）に戻ってくる。
【００４１】
（フィルター、フィルターホスト）
フィルターはライブラリーモジュールの形式で用意されている。フィルターホスト（２４００）はプロセスとして存在し、実行時に指定されたフィルターをロードする。
【００４２】
フィルターホスト（２４００）はコントロールバス（５００２）への接続とメッセージ送受信、パイプライン（３０００）の生成と接続、ジョブコントローラ（２３００）との通信、フィルターのログ出力のロガー（２６００）への転送などの処理を担当する。フィルターはフィルターホスト（２４００）が用意したパイプライン（３０００）からデータを読み出し、必要な変換処理を施した上で再びパイプライン（３０００）に書き込む処理を行う。フィルター内において前段コンポーネントからのパイプラインを特に入力パイプライン（５）と呼び、次段コンポーネントへのパイプラインを特に出力パイプライン（６）と呼ぶ。
【００４３】
（コントロールバス）
コンポーネントが提供しているサービスはネットワークからアクセスできるエンドポイントとして他のコンポーネントに公開される。具体的にはTCP/IPのアドレスとポート番号の組が公開される。コンポーネントは他のコンポーネントの提供するサービスI/Fを取得して利用する。複数種類のコンポーネントがプロセスとして複数存在し、かつ同一コンポーネントも同一PC上に複数存在する。従って、各コンポーネントが公開するサービスI/Fのポート番号は固定にすることができず、自ずと動的に生成せざるを得なくなる。動的に生成されたエンドポイントは何らかの管理機構が無くては他から参照することはできない。この管理を担当するのはロケーター（２５００）である。
【００４４】
さらに、コンポーネントが他のコンポーネントの動的に生成されたエンドポイントを取得する手段が必要である。この手段がクエリーである。クエリーに回答するのはやはりロケーター（２５００）の役割である。例えばプロキシーモジュール（２２００）はジョブの実行の為にジョブコントローラー（２３００）をクエリーしてそのサービスI/Fを取得しなければならない。同様にジョブコントローラー（２３００）は複数のフィルターホスト（２４００）をクエリーして取得しなければならない。印刷データ変換サービス（２１００）が複数のコンポーネントの連携として構成されていることを思い出して欲しい。「連携」の意味する具体的な処理はこのクエリーによって取得したサービスI/Fに対して要求を送信することにあたる。クエリーはマルチキャスト通信チャネルを通じて送信される通信パケットである。そのパケットは問い合わせたいコンポーネントの名前と利用したいバージョンが記されているＸＭＬ形式のデータである。
【００４５】
マルチキャスト通信に使用されるアドレスおよびポート番号は各コンポーネントの起動時に参照するコンフィギュレーションファイルに記載されることになっている。起動されたコンポーネントはマルチキャストグループに参加することで、全コンポーネントと通信が可能な状態になる。異なるＰＣ上で動作するコンポーネント群であっても、マルチキャスト通信に使用するアドレスとポートの組が同一であれば、これらは同一のマルチキャストグループに属することになる。つまり、コントロールバス（５００２）が複数のＰＣを跨って形成されることが可能である。
【００４６】
（マルチキャスト通信アドレスの変更）
各コンポーネントが起動時に参照するコンフィギュレーションファイルにはマルチキャストアドレスとポート番号の組が記載されている。このファイルには規定の値が選定されてインストールセットとして提供されている。インストールされるＰＣ毎にマルチキャストアドレスを変更する必要があるならば管理者が任意のアドレスとポート番号を選定してコンフィギュレーションファイルの該当部分を上書きして利用することができる。
【００４７】
（複数ＰＣでのコントロールバスの共有）
複数のＰＣ上に印刷データ変換サービス（２１００）を構成するコンポーネント群をインストールしかつこれらの複数ＰＣ間で同一マルチキャストアドレスを使用してコンポーネント群を起動させると図５に示すようにひとつの印刷データ変換サービス（２１００）が２つのＰＣ上のコンポーネント群の連携として構成されることが可能となる。このような構成はＣＰＵ使用率が比較的高いフィルター群のみを能力の高い特定のＰＣに限定して起動させるなどの意図的なコンポーネントの配置を行う際に用いることができる。しかし、この様な複数ＰＣに跨るコンポーネントの連携は別の問題を生じさせる。すなわち、一旦連携が開始され印刷データ変換サービス（２１００）か稼動している期間はコンポーネントが動作しているＰＣはネットワークからの切断やシャットダウンが許されないという制約が生じる。通常、稼動しているＰＣのシャットダウン時にはシステム管理者が介在することが必要とされるため、頻繁なシャットダウンは行われることはない。
【００４８】
（仮想サーバー機能）
しかし、クラウド上のシステムとして印刷データ変換サービス（２１００）を動作させようとする場合には、仮想サーバー機能をサービスとして提供するベンダーからIaaS(Infrastructure as a Service)機能を購入して利用することが通常となる。この様な仮想サーバー機能では負荷分散機能としてのオートスケールアウト、オートスケールインが提供される。図３においては負荷の増大が検出されるとサーバーＰＣ（８０）が自動的に作成され（オートスケールアウト）、逆に負荷が低減するとサーバーＰＣがシャットダウンされる（オートスケールイン）。オートスケールアウト時には作成されるサーバーＰＣにはOSはもとより、インストール済みのアプリケーション全てが複製された状態で起動する。その後、起動したサーバーＰＣはロードバランサー（７０）に登録されて稼動を始める。
【００４９】
新たに起動したサーバーＰＣ上では既存のサーバーＰＣ上に存在するコンフィギュレーションファイルと同一のファイル内容を持つファイルが存在する。従ってロケーター（２５００）が動作を開始し、図５に示すように既存のコントロールバス（５００２）が複数のサーバーＰＣをまたいで共有される状態に至る。このまま、複数のサーバーＰＣ上を跨ったコントロールバスではコンポーネントが生成され印刷データ変換サービス（２１００）もまた複数のサーバーＰＣ上を跨った状態で形成され稼動する。オートスケールアウト、オートスケールインはロードバランサー（７０）を通過するリクエストの時間当たりの量に応じて自動的に実行されるため、リクエストが減少した時点でスケールイン対象となったサーバーＰＣ（８０）上で稼動していたコンポーネント群は動作中に消滅する可能性がある。つまり、本システムにおける複数のサーバーＰＣを跨いだコントロールバス（５００２）の運用は、スケールインを管理者による手動で行う場合は問題がないがオートスケールイン機能とは排他的でなければならないことになる。
【００５０】
（オートスケールイン機能との排他の実現）
印刷データ変換サービス（２１００）はインフラとして提供されている仮想サーバーの負荷分散機能の特にオートスケールアウト、オートスケールイン機能に依存してコントロールバス（５００２）の振る舞いを変更する必要がある。そのため、オートスケールイン機能を利用する場合には、各コンポーネントが起動時に参照するコンフィギュレーションファイル（２００、２０１）に設定を行い、複数のサーバーＰＣ上を跨ったコントロールバスの生成を禁止しなければならない。以下では、印刷データ変換サービス（２１００）がオートスケールイン機能を提供している仮想サーバー上で動作する場合について説明を行う。
【００５１】
（ロケーターの起動時処理）
複数のサーバーＰＣ上を跨ったコントロールバスの生成を禁止する為の設定はシステム管理者が図７のロケーター用コンフィギュレーションファイル（２００）の該当箇所を設定することで行う。具体的には、図８に示すコンフィギュレーションファイルの“AcrossMachineBorder”タグの値を”false”にする。ロケーター用コンフィギュレーションファイル（２００）はサーバーＰＣに少なくとも一度はインストールされる。インストールされたサーバーＰＣが稼動し、ロケーター（２５００）は印刷データ変換サービス（２１００）の最初のプロセスとしてコンフィギュレーションファイル（２００）を伴って起動される。プロセスの初期化処理の一環として図１に示すLocator起動時処理が実行される。
【００５２】
ステップＳ００１において起動時に与えられたロケーター用コンフィギュレーションファイル（２００）から図８に示す”ControlBus“タグが検索されその子要素である“AcrossMachineBorder”タグの値が取得される。この値の内容によって以降の処理が分岐する。
【００５３】
ステップＳ００２は「コントロールバスがサーバーＰＣを跨いで利用可能」であることを意味する値が設定されているか否かを判定する。これは“AcrossMachineBorder”タグの値が”true”であるか比較することと等価である。この判定においてYesと判定された場合には続くステップＳ００３に進み、ロケーター用コンフィギュレーションファイル（２００）からマルチキャストアドレスとポート番号が取得される。図８における”Address”タグの値がアドレスであり”Port”タグの値がポート番号である。その後、ステップＳ００４に進み取得したアドレスとポート番号を用いてコントロールバスへ接続し、起動時処理を終了する。
【００５４】
ステップＳ００２における判定がＮｏとなる場合には処理はステップＳ００５に分岐する。このステップではロケーター用コンフィギュレーションファイル（２００）からマルチキャストアドレスとポート番号を取得することは行わず、両者を選定する処理を行う。マルチキャストアドレスは例えばIpV4においては、239.0.0.0〜239.255.255.255の範囲のアドレス値からランダムに選択する。ポート番号も定められた範囲の数値のなかからランダムに選択して使用する。アドレスとポート番号はこのステップＳ００５で起動初期化時に選定されて使用されるため、他のシステムが使用するマルチキャストアドレスと競合する可能性は低いが、確認の為に続くステップＳ００６において競合を検出する。
【００５５】
ステップＳ００６では選択されたマルチキャストアドレスとポート番号を用いてコントロールバスに接続する。もし、別のＰＣで既に同一のアドレスとポート番号を用いたコントロールバスが稼動しているならば、そのバス上にはロケーター（２５００）が起動しているはずである。そこでそのロケーターのLookupを試行する。Lookupはコントロールバス上のコンポーネントに与えられた識別子であるノードＩＤを問い合わせるコマンドパケットを送出してその応答を受け取る処理である。Lookupパケットはコントロールバス上の全コンポーネントに対して送出される。同パケット内には対象となるコンポーネントのサービス名が記載されている。先に説明したクエリーがサービス名を指定してそのサービスが持つサービスI/Fアドレスを取得する処理であったのに対し、このLookupはそのサービスが持つノードＩＤを取得するために用いられる。ロケーター（２５００）はサービスI/Fを備えていないために、クエリーの対象にはなり得ない。代わりにLookupパケットに応答してもらうことでその存在を確認しようとする意図がある。
【００５６】
ステップＳ００７において応答を一定時間待つ。もし規定時間内に応答があれば、既にそのコントロールバスアドレスは別のPC上のロケーター（２５００）によって作成されていることを意味し、それはマルチキャストアドレスとポート番号が競合していることを意味する。そのため別のアドレスとポート番号を選択するようステップＳ００５に戻る。ステップＳ００７で一定時間内にLookupの応答が得られない場合には、選定したマルチキャストアドレスとポートは他のＰＣでは使用されていなかったものと判断しステップＳ００８に進む。ステップＳ００８では選定したマルチキャストアドレスとポートをそのＰＣ上で起動する全てのコンポーネント用のコンフィギュレーションファイル（２０１）に記載して初期化処理を終了する。
【符号の説明】
【００５７】
１  データ変換処理部、２  データフラグメント格納制御部、
３  処理可能フラグメント情報格納部、４  データフラグメント格納部、
５  入力パイプライン、６  出力パイプライン、７  フィルター、
８  処理可能タイプ設定手段、９  データフラグメント取得手段、１０  ネットワーク、
２０  ＰＣ、３０  タブレットＰＣ、４０  携帯電話、５０  印刷依頼者、
６０  プリンター、７０  ロードバランサー、８０  サーバーＰＣ、
９０  ファイルサーバー、２００  ロケーター用コンフィギュレーションファイル、
２０１  各コンポーネント用コンフィギュレーションファイル、
２０２  各コンポーネント、１００１  コントロールバス、
１００２  ＨＤＤ（ハードディスクドライブ）、
１００３  ＲＯＭ（リードオンリーメモリ）、
１００４  ＲＡＭ（ランダムアクセスメモリ）、
１００５  ＣＰＵ（セントラルプロセッシングユニット）、
１００６  出力装置、１００７  入力装置、１００８  通信装置、
２１００  印刷データ変換サービス、２１１０  印刷サービスゲートウェイ、
２２００  プロキシーモジュール、２３００  ジョブコントローラー、
２４００  フィルターホスト、２５００  ロケーター、２６００  ロガー、
２７００  ＰＤＬＦｉｌｔｅｒ（Ｆｉｌｔｅｒ  Ａ）、
２８００  ＬａｙｏｕｔＦｉｌｔｅｒ（Ｆｉｌｔｅｒ  Ｂ）、
２９００  Ｆｉｌｔｅｒ  Ｃ、３０００  パイプライン、
４１００  Ｗｅｂサーバー、４２００  アプリケーションサーバー、
５００２  コントロールバス
【図１】
2017004072.tif 000003
【図２】
2017004072.tif 000004
【図３】
2017004072.tif 000005
【図４】
2017004072.tif 000006
【図５】
2017004072.tif 000007
【図６】
2017004072.tif 000008
【図７】
2017004072.tif 000009
【図８】
2017004072.tif 000010