(57)【要約】      （修正有）【課題】分散環境を提供するプラットフォームを利用したサービスを提供する。【解決手段】画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する要求受信部１２０１と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、該取得したメッセージに基づく処理を行うバックエンド処理部１２０２と、前記バックエンド処理部は、前記記憶手段から取得したメッセージに対応するジョブのタスク実行状況を特定する特定手段と、前記特定手段によりタスク実行状況が特定されたジョブのタスク実行状況に応じたタスクサービスを、サービス提供装置が提供する複数のタスクサービスの中から選択し、前記特定手段によりタスク実行状況が特定されたジョブの処理を、該選択されたタスクサービスが実行するよう前記サービス提供装置に指示する指示手段とを有する。【選択図】図１２
2011192250.tif 000002
【特許請求の範囲】
【請求項１】
画像処理装置、分散環境を提供するプラットフォームシステム、ウェブサービスから構成されるクラウドコンピューティングシステムであって、
前記画像処理装置は、
ジョブを前記プラットフォームシステムへ送信する送信手段を有し、
前記プラットフォームシステムは、
要求受信プログラムの制御下にて、前記送信手段により送信されたジョブをキューに挿入する挿入手段と、
バックエンド処理プログラムの制御下にて、前記挿入手段によりキューに挿入されたジョブを取得し、該ジョブの処理状況を特定する特定手段と、
前記バックエンド処理プログラムの制御下にて、前記特定手段により特定された処理状況を基に、前記ウェブサービスが提供する複数のタスクサービスの中から、前記ジョブをタスク処理するタスクサービスを選択する選択手段とを有し、
前記選択手段により選択されたタスクサービスは、
前記ジョブのタスク処理を実行する実行手段を有し、
前記プラットフォームシステムは、
前記バックエンド処理プログラムの制御下にて、前記ジョブが前記実行手段によりタスク処理された結果に関する情報を前記タスクサービスから受信する受信手段を有し、
前記受信手段により受信された情報に基づき前記ジョブの処理が終了されたと判断した場合、前記要求受信プログラムの制御下にて、前記ジョブの処理の結果を前記画像処理装置が取得するために用いられる情報を前記画像処理装置へ送信することを特徴とするクラウドコンピューティングシステム。
【請求項２】
前記タスクサービスは、前記ジョブに関連するデータを取得するタスク処理を担当する取得タスクサービス、および前記データに対し指定された処理を実行するタスク処理を担当する処理タスクサービス、および前記画像処理装置が指定された処理の結果を取得するために用いられる情報を前記プラットフォームシステムへ送信するタスク処理を担当する送信タスクサービスを含み、
前記特定手段により前記ジョブが処理されていない状況と特定された場合、前記選択手段は前記取得タスクサービスを選択し、
前記特定手段により前記ジョブの処理が開始され、かつ指定された処理が実行されていない状況と特定された場合、前記選択手段は前記処理タスクサービスを選択し、
前記特定手段により指定された処理が実行された状況と特定された場合、前記選択手段は前記送信タスクサービスを選択することを特徴とする請求項１に記載のクラウドコンピューティングシステム。
【請求項３】
画像形成装置、およびウェブサービスと通信可能な分散環境を提供するプラットフォームシステムを制御する制御方法であって、
要求受信プログラムの制御下におけるジョブ受信手段は、前記画像形成装置からジョブを受信し、
バックエンド処理プログラムの制御下における特定手段は、前記ジョブ受信手段により受信されたジョブの処理状況を特定し、
前記バックエンド処理プログラムの制御下における選択手段は、前記特定手段により特定された処理状況を基に、前記ウェブサービスが提供する複数のタスクサービスの中から、前記ジョブをタスク処理するタスクサービスを選択し、
前記要求受信プログラムの制御下における受信手段は、前記選択手段により選択されたタスクサービスからタスク処理の結果に関する情報を受信し、
前記受信手段により受信された情報に基づき前記ジョブの処理が終了されたと判断した場合、前記ジョブの処理の結果を前記画像処理装置が取得するために用いられる情報を前記画像形成装置へ送信することを特徴とする制御方法。
【請求項４】
前記タスクサービスは、前記ジョブに関連するデータを取得するタスク処理を担当する取得タスクサービス、および前記データに対し指定された処理を実行するタスク処理を担当する処理タスクサービス、および前記画像処理装置が指定された処理の結果を取得するために用いられる情報を前記プラットフォームシステムへ送信するタスク処理を担当する送信タスクサービスを含み、
前記特定手段により前記ジョブが処理されていない状況と特定された場合、前記選択手段は前記取得タスクサービスを選択し、
前記特定手段により前記ジョブの処理が開始され、かつ指定された処理が実行されていない状況と特定された場合、前記選択手段は前記処理タスクサービスを選択し、
前記特定手段により指定された処理が実行された状況と特定された場合、前記選択手段は前記送信タスクサービスを選択する請求項３に記載の制御方法。
【請求項５】
前記バックエンド処理プログラムの制御下における計算手段は、前記タスクサービスがタスク処理を実行した回数と、前記タスクサービスがタスク処理を実行しタスク処理を失敗した回数とを基に、前記タスクサービスの失敗率を計算し、
前記要求受信プログラムの制御下におけるエラー送信手段は、前記計算手段により計算されたタスクサービスの失敗率が閾値を越えた場合、前記ジョブの処理を停止し、該ジョブの処理が失敗した旨を画像形成装置に送信すること特徴とする請求項３または４に記載の制御方法。
【請求項６】
画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、
前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部と、
前記バックエンド処理部の数を管理する管理手段とを利用するクラウドコンピューティングシステムであって、
前記バックエンド処理部は、
前記記憶手段から取得したメッセージに対応するジョブのタスク実行状況を特定する特定手段と、
前記特定手段によりタスク実行状況が特定されたジョブのタスク実行状況に応じたタスクサービスを、サービス提供装置が提供する複数のタスクサービスの中から選択し、前記特定手段によりタスク実行状況が特定されたジョブの処理を、該選択されたタスクサービスが実行するよう前記サービス提供装置に指示する指示手段とを有するクラウドコンピューティングシステム。
【請求項７】
前記画像形成装置から処理依頼されたジョブには、前記サービス提供装置が提供する複数のタスクサービスの内、利用するタスクサービスと該タスクサービスの実行順序が定められ、
前記特定手段は、定められたタスクサービスの内、前記ジョブがどこまでタスクサービスを利用したかを確認することで、前記タスク実行状況を特定する請求項６に記載のクラウドコンピューティングシステム。
【請求項８】
前記バックエンド処理部は
前記指示手段によりジョブの処理を実行するよう指示されたタスクサービスの品質が基準を満たしているか否かを判定する判定手段と、
前記判定手段により品質を満たしていないと判定された場合は、前記指示手段により指示されたジョブに対応するメッセージを前記記憶手段から削除するよう前記記憶手段に指示する削除指示手段とを有する請求項６または７に記載のクラウドコンピューティングシステム。
【請求項９】
前記品質とは、前記タスクサービスが処理したジョブの失敗した割合であることを特徴とする請求項８に記載のクラウドコンピューティングシステム。
【請求項１０】
前記要求受信部は、
前記削除指示手段によりメッセージが削除された場合は、前記画像形成装置に対してジョブが処理できなかった旨を送信する送信手段を有する請求項８または９に記載のクラウドコンピューティングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドコンピューティングシステム、クラウドコンピューティングシステムの制御方法に関するものである。
【背景技術】
【０００２】
インターネット技術を利用したコンテンツ管理システムが普及してきている。ユーザーは、クライアントコンピュータからインターネットを介してサーバーコンピュータが開設しているＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したいコンテンツを選択する。コンテンツ管理システムは、選択されたコンテンツをサーバーコンピュータに送信し、サーバーコンピュータは受信したコンテンツをユーザー側のクライアントコンピュータの画面上に表示されるように処理を行う。
【０００３】
特許文献１には、ユーザーがクライアントコンピュータの画面で閲覧したコンテンツをプリンタで印刷する方法が開示されている。この方法は、ユーザーが閲覧したコンテンツをサーバーコンピュータがプリンタで印刷できるようなデータに変換し、変換したデータをプリンタに送信する。プリンタは受信したデータを印刷する。
【０００４】
また、近年、サーバーコンピュータ側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）という技術が利用され始めている。
【０００５】
クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ変換やデータ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。
【０００６】
また、近年のオープン化の流れを受け、プラットフォームとして開発したシステムの上で、サービスアプリケーションを実行もしくは連携させるシステムが存在する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００２−３０４２７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ネットワークプリンティングシステムも同様に、プラットフォーム化したシステムが考えられる。
【０００９】
本発明では、分散環境を提供するプラットフォームを利用したサービスを提供することを目的とする。デバイスと、ウェブサービスと、分散環境を提供するプラットフォームとを連携させることを目的とする。プラットフォーム提供者、ウェブサービス提供者とが分業してサービスをデバイスに提供することを目的とする。本発明は上述の目的の内、少なくとも１つの目的を達成する。
【課題を解決するための手段】
【００１０】
本発明の一実施系に係るシステムは、画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部と、前記バックエンド処理部の数を管理する管理手段とを利用するクラウドコンピューティングシステムであって、前記バックエンド処理部は、前記記憶手段から取得したメッセージに対応するジョブのタスク実行状況を特定する特定手段と、前記特定手段によりタスク実行状況が特定されたジョブのタスク実行状況に応じたタスクサービスを、サービス提供装置が提供する複数のタスクサービスの中から選択し、前記特定手段によりタスク実行状況が特定されたジョブの処理を、該選択されたタスクサービスが実行するよう前記サービス提供装置に指示する指示手段とを有するクラウドコンピューティングシステム。
【発明の効果】
【００１１】
本発明によると、ユーザはデバイスから、分散環境を提供するプラットフォームを利用したサービスを利用することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例１におけるプリントシステム１０００の構成を示す図である。
【図２】本発明の実施例１における画像形成装置１０４の内部構成の詳細を示す図。
【図３】本発明の実施例１における情報処理装置１０６の内部構成の詳細を示す図。
【図４】本発明の実施例１におけるプリントシステム１０００を構成する各装置が持つ機能を示す図。
【図５】本発明の実施例１におけるプラットフォームシステム５００の詳細を示す図。
【図６】本発明の実施例１におけるキューメッセージ６００を示す図。
【図７】本発明の実施例１におけるジョブテーブル７００を示す図。
【図８】本発明の実施例１におけるサービステーブル８００を示す図。
【図９】本発明の実施例１におけるサービスシーケンステーブル９００を示す図。
【図１０】本発明の実施例１における一連の処理の流れを示すシーケンス図。
【図１１】本発明の実施例１における印刷アプリケーションによる印刷データ選択画面を示す図。
【図１２】本発明の実施例１におけるサービスが実装すべきインターフェースの構造図。
【図１３】本発明の実施例１におけるサービス品質統計テーブル１３００の一例を示す図。
【図１４】本発明の実施例２における一連の処理の流れを示すシーケンス図。
【図１５】本発明の実施例２におけるサービス品質判定処理のフローチャート。
【図１６】本発明の変化形におけるサービスが実装すべきインターフェースの構造図。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための最良の形態について、添付の図面を用いて説明する。始めに、本発明の各実施例で使用される用語の定義について説明する。
【００１４】
印刷データ処理とは、例えば、ユーザーが印刷したいコンテンツを、ＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）やプリンタと言った画像形成装置が印刷できるようなデータへ変換する処理のことを指す。
【００１５】
コンテンツとは、例えば、文書データ（例えば、テキスト）や、画像データ（例えば、ＢＭＰを始めとするラスタイメージ）等を組み合わせた電子データを指す。
【００１６】
印刷データとは、例えば、コンテンツを印刷データ処理によって変換処理したデータのことであり、ＰＤＬ（Ｐａｇｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）、ＰＤＦ（Ｐｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ）、ラスタイメージ等がある。
【実施例１】
【００１７】
実施例１におけるネットワークプリントシステム１０００を構成している各装置について、図１を参照して詳細に説明する。図１は、ネットワークプリントシステム１０００を構成している各装置が、ネットワーク１００を介して接続されている様子を示す図である。ネットワークシステムを構成している各装置とは、サーバーコンピュータ群１０２、文書サーバー１０３、画像形成装置１０４、クライアントコンピュータ１０５、文書取り出しサーバー１０７、文書変換サーバー１０８、印刷サーバー１０９である。なお、ネットワークプリントシステム１０００は、クラウドコンピューティングシステムとも呼称する。
【００１８】
ネットワーク１００は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、画像形成装置１０４とクライアントコンピュータ１０５が属するネットワーク１００からは、サーバーコンピュータ群１０２などが属するネットワーク１００と、ファイアウォールを越えて通信が可能となる。ネットワーク１００、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。実施例１の図１において、サーバーコンピュータ群１０２は、１台のサーバーとして示されているが複数台のサーバーコンピュータで構成されているものとする。
【００１９】
次に、図１のプリントシステムを構成している各装置の内部構成について詳細に説明する。始めに、画像形成装置１０４の内部構成について図２を用いて説明する。図２は、画像形成装置１０４の内部構成を示すブロック図である。
【００２０】
画像形成装置１０４は、画像処理ユニット２０１、印刷ユニット２０２、および読み込みユニット２０３から構成される。画像処理ユニット２０１は、ＣＰＵ２０４、直接記憶部２０５、間接記憶部２０６、ユーザーインターフェース２０７、外部インターフェース２０８から構成されている。
【００２１】
ＣＰＵ２０４は、所定のプログラムを実行し、画像処理装置１０４の各種制御を指示するユニットである。ＣＰＵ２０４は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）により実現される。直接記憶部２０５は、ＣＰＵ２０４がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２０４が実行するプログラムは直接記憶部２０５にロードされる。直接記憶部２０６は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）により実現される。間接記憶部２０６は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部２０６に記憶されている各種プログラムは、ＣＰＵ２０４がプログラムを実行する際に直接記憶部２０５へ移動する。間接記憶部２０６は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、または、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ２０４はマルチプロセッサでも良い。
【００２２】
ここで、プラットフォームプログラムを実行することにより実現される、プラットフォームについて詳細に説明する。プラットフォームの実現により、ユーザーが独自に開発した新しいアプリケーションを画像形成装置１０４上で実行できる他、画像形成装置１０４の操作画面をカスタマイズすることが可能になる。
【００２３】
プラットフォームの実現方法について説明する。ＣＰＵ２０４は、間接記憶部２０６に記憶されたプラットフォームプログラムを直接記憶部２０５に移動する。移動が完了するとＣＰＵ２０４は、プラットフォームプログラムを実行することができる状態になる。本発明の実施例１では、ＣＰＵ２０４がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０４のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。
【００２４】
プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本発明の実施例１において、プラットフォーム上には、印刷要求を受け付ける印刷ソフトウェアが動作している。印刷ソフトウェアは、ネットワークを介して接続されているデバイスから、例えば、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）と言った通信プロトコルによって印刷データを受信できる。印刷ソフトウェアは、受信した印刷データをファームウェアに送信し、印刷データを受信したファームウェアは、印刷データ処理を開始する。なお、印刷データが印刷データ処理をせずに印刷できるような形式であれば、ファームウェアは印刷データ処理を省く。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０４の制御を実現することができる。
【００２５】
アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部２０６に記憶されたアプリケーションプログラムを直接記憶部２０５に移動する。移動が完了すると、プラットフォームはアプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、プラットフォーム上でアプリケーションプログラムを実行し、サービスを提供できるプラットフォームの機能を、本発明の実施例１ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施例１で開示するフローチャートの各処理の一部を行うことが可能である。
【００２６】
ユーザーインターフェース２０７は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。外部インターフェース２０８は、外部装置からのデータの受信や外部装置へのデータの送信が可能となっている。例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０４は、ネットワーク１００、およびインターネット１０１を介して、クライアントコンピュータ１０５、サーバーコンピュータ群１０２等と通信可能である。
【００２７】
印刷ユニット２０２は、印刷データ処理された印刷データを記録媒体に印字する機能を持つ。読み込みユニット２０３は、原稿台の上に置かれた原稿を読み取り、原稿画像を生成する機能を持つ。本発明の実施例１における読み込みユニット２０３は、スキャナである。
【００２８】
２番目に、サーバーコンピュータ群１０２、文書サーバー１０３、クライアントコンピュータ１０５、文書取り出しサーバー１０７、文書変換サーバー１０８、印刷サーバー１０９を含む情報処理装置１０６の内部構成について図３を用いて説明する。図３は、情報処理装置１０６の内部構成を示すブロック図である。情報処理装置１０６は、ユーザーインターフェース３０１、ＣＰＵ３０２、直接記憶部３０３、間接記憶部３０４、外部インターフェース３０５から構成されている。
【００２９】
ユーザーインターフェース３０４は、ユーザーからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、マウス等を通してユーザーが入力した指示に応じた信号を受け付ける。
【００３０】
ＣＰＵ３０１は、所定のプログラムを実行し情報処理装置１０６の各種制御を指示するユニットである。ＣＰＵ３０１は、ＣＰＵにより実現される。直接記憶部３０２は、ＣＰＵ３０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ３０１が実行するプログラムは直接記憶部３０２にロードされる。直接記憶部３０２は、ＲＡＭで構成されている。間接記憶部３０３は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。間接記憶部３０３に記憶されている各種プログラムは、ＣＰＵ３０１がプログラムを実行する際に直接記憶部３０２へ移動する。間接記憶部３０３は、ＲＯＭ、または、ＨＤＤで構成されている。外部インターフェース３０５は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。
【００３１】
次に、本発明の実施例１のプリントシステム１０００における各装置が持つ機能について、図４を参照しながら詳細に説明する。図４は、プリントシステム１０００における各装置の機能を示すブロック図である。
【００３２】
始めに、サーバーコンピュータ群１０２の機能について説明する。実施例１におけるサーバーコンピュータ群１０２は、クラウドコンピューティングシステムの一例である。サーバーコンピュータ群１０２には、要求受信部４０１、バックエンド処理部４０２、テーブルストレージサービス４０３、ブロブストレージサービス４０４、キューストレージサービス４０５の機能がある。本発明の実施例１では、要求受信部４０１を持つサーバーコンピュータが少なくとも１台は存在する。また、バックエンド処理部４０２を持つサーバーコンピュータが少なくとも１台は存在する。また、テーブルストレージサービス４０３、ブロブストレージサービス４０４、キューストレージサービス４０５の各機能を持つサーバーコンピュータが少なくとも１台は存在する。上述の機能が夫々別のサーバーコンピュータ上にあっても問題はない。
【００３３】
要求受信部４０１は、クライアントコンピュータ１０５、または画像形成装置１０４から送られてきた処理依頼を受け付ける機能を提供する。バックエンド処理部４０２は、処理プログラムを用いて処理依頼に対する処理を行う機能を持つ。なお、この処理依頼とは、要求受信部４０１が受け付けた処理依頼を指す。バックエンド処理部４０２は、バックエンド処理部４０２を実行しているサーバーコンピュータの直接記憶部３０２に処理プログラムをロードし処理を行う。要求受信部４０１、およびバックエンド処理部４０２は、図３が示す間接記憶部３０３に保存されている要求受信プログラム、またはバックエンド処理プログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。要求受信部４０１、およびバックエンド処理部４０２の詳細については、後述する。
【００３４】
テーブルストレージサービス４０３は、バックエンド処理部４０２により実行される処理の経過状況を始めとする、各種ステータス情報を格納する機能を提供する。テーブルストレージサービス４０３は、図３で示す間接記憶部３０３に保存されているテーブルストレージサービスプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。また、データは間接記憶部３０３によって保管される。テーブルストレージサービス４０３の詳細については、後述する。
【００３５】
ブロブストレージサービス４０４は、バックエンド処理部４０２により処理された実行結果のデータを始めとする、各種データを保存しておく機能を提供する。ブロブストレージサービス４０４は図３で示す間接記憶部３０３に保存されているブロブストレージサービスプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。また、データは間接記憶部３０３によって保管される。ブロブストレージサービス４０４の詳細については、後述する。
【００３６】
キューストレージサービス４０５は、次の２つの機能を提供する。１つ目は、要求受信部４０１とバックエンド処理部４０２とが非同期でデータ通信可能とするための機能を持つ。２つ目は、キューに追加されているキューメッセージを不可視、または可視にする機能を持つ。なお、キューとは、キューストレージサービス４０５により実現される記憶機能であって、ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）と呼ばれるリスト構造によって実現される。
【００３７】
１つ目の機能について説明する。要求受信部４０１とバックエンド処理部４０２は次のような方法で通信を行う。始めに、ユーザーからの処理依頼を受けた要求受信部４０１は、ユーザーからの処理依頼に応じたキューメッセージと呼ばれるチケットを作成する。キューメッセージ６００は要求受信部４０１によってキューに格納される。バックエンド処理部４０２は、キューからキューメッセージ６００を取得する。バックエンド処理部４０２は、キューメッセージ６００を取得し、キューメッセージ６００を参照してユーザーからの処理依頼を処理する。これにより、ユーザーからの処理依頼を解決することになる。このように、キューサービス４０５を利用することで要求受信部４０１とバックエンド処理部４０２は非同期で通信を行うことが可能になる。１つ目の機能、および２つ目の機能のより詳細な説明については後述する。なお、キューストレージサービス４０５は、図３の間接記憶部３０３に保存されているキューストレージサービスプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。また、データは間接記憶部３０３によって保管される。
【００３８】
以上がサーバーコンピュータ群１０２の機能の説明になるが、上述の通り、より詳細な説明については後述する。
【００３９】
次に、文書サーバー１０３の機能について説明する。文書サーバー１０３は、文書リポジトリ４０６の機能を持つ。文書リポジトリ４０６は、図３で示す間接記憶部３０３によって実現される。例えば、文書リポジトリ４０６には、ユーザーがクライアントコンピュータ１０５、または画像形成装置１０４から印刷指示したコンテンツが保存されている。文書リポジトリ４０６に保存されているコンテンツは、予め保存されているコンテンツの他に次のようなコンテンツも保存されている。
【００４０】
そのコンテンツとは、ユーザーが後述するブラウザ４０７、またはデバイスブラウザ４０９を介してサーバーコンピュータ群１０２上のアプリケーションで作成したコンテンツである。これにより、サーバーコンピュータ群１０２上のアプリケーションを用いて作成したコンテンツであっても、クライアントコンピュータ１０５にアプリケーションをインストールすることなく容易に印刷できる。なお、上述のサーバーコンピュータ群１０２上のアプリケーションとは、文書作成アプリケーション、画像作成アプリケーション、帳票管理アプリケーション等を始めとする各種アプリケーションのことである。これらのアプリケーションは図３で示す間接記憶部３０３に保持されており、実行が指示されると直接記憶部３０２にロードされ、ＣＰＵ３０１により実行される。
【００４１】
次に、画像形成装置１０４について詳細に説明する。画像形成装置１０４には、デバイスブラウザ４０９、プラットフォームアプリケーション４０８の機能がある。デバイスブラウザ４０９は、ネットワーク１００を介して接続されているデバイス内に保存されているデータや情報をユーザーが閲覧することができる機能を持つ。デバイスブラウザ４０９は、図２で示す間接記憶部２０６に保存されているデバイスブラウザプログラムが、直接記憶部２０５にロードされ、ＣＰＵ２０４により実行されることで実現される。また、ユーザーは、デバイスブラウザ４０９を用いてコンテンツの印刷指示を出すことができる。印刷指示は、サーバーコンピュータ群１０２の要求受信部４０１へ送信される。デバイスブラウザ４０９は、例えば、Ｗｅｂブラウザである。
【００４２】
プラットフォームアプリケーション４０８は、各種サービスを提供する機能を提供する。プラットフォームアプリケーション４０８は、プラットフォーム上で動作するアプリケーションプログラムによって実現される。本発明の実施例１において、プラットフォームアプリケーション４０８は印刷ソフトウェアのサービスを提供する。上述の様に、このサービスは、受信した印刷データをファームウェアに送信することができる。また、このサービスは、要求受信部４０１に対して印刷データの生成が終了したかどうかの確認を行う。その際、このサービスは、要求受信部４０１が作成したジョブＩＤを基に生成確認を行う。
【００４３】
次に、クライアントコンピュータ１０５について詳細に説明する。クライアントコンピュータ１０５は、ブラウザ４０７の機能を提供する。ブラウザ４０７は、ネットワーク１００を介して接続されている、デバイス内に保存されたデータ、および情報をユーザーが閲覧することができる機能を提供する。図３で示す間接記憶部３０３に保存されているブラウザプログラムが、直接記憶部３０２にロードされて、ＣＰＵ３０１により実行されることで実現される。ブラウザ４０７は、例えば、Ｗｅｂブラウザである。
【００４４】
次に、文書取り出しサーバー１０７について詳細説明する。文書取り出しサーバー１０７は、文書取り出しサービス４１０の機能を提供する。文書取り出しサービス４１０は、図３で示す間接記憶部３０３に保存されている文書取り出しプログラムを、ＣＰＵ３０１が直接記憶部３０２に読みだして実行することで実現される。文書取り出しサービス４１０は、外部インターフェース３０５を通して受信した文書取り出し指示に従って、文書サーバー１０３にアクセスし、文書リポジトリ４０６に保存されているコンテンツを取得する機能を提供する。このように、文書取り出しサービス４１０は、ウェブサービスを提供する。
【００４５】
次に、文書変換サーバー１０８について詳細に説明する。文書変換サーバー１０８は、文書変換サービス４１１の機能を持つ。文書変換サービス４１１は、図３で示す間接記憶部３０３に保持されている文書変換プログラムを、ＣＰＵ３０１が直接記憶部３０２に読みだして実行することで実現される。文書変換サービス４１１は、外部インターフェース３０５を通して受信した文書変換指示に従って、指示されたデータ（コンテンツ）を所定のデータ形式に変換する機能を有する。本発明の実施例１における文書変換サービス４１１は、コンテンツをＰＤＦ（Ｐｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ）に変換する機能を持つ。このように、文書変換サービス４１１は、ウェブサービスを提供する。
【００４６】
最後に、印刷サーバー１０９について詳細に説明する。印刷サーバー１０９は、スプールサービス４１２の機能を持つ。スプールサービス４１２は、図３で示す間接記憶部３０３に保持されているスプールプログラムを、ＣＰＵ３０１が直接記憶部３０２に読みだして実行することで実現される。スプールサービス４１２は、外部インターフェース３０５を通して受信した指示に従って、指示されたデータを印刷させるために必要な属性（印刷優先度や、色味情報など）を生成・付与する機能を有する。このように、印刷サーバー１０９はウェブサービスを提供する。
【００４７】
以上が、本発明の実施例１のプリントシステム１０００における、各装置が持つ機能の説明になる。このように、文書取り出しサービス４１０は、ウェブサービスを提供する。
【００４８】
次に、サーバーコンピュータ群１０２のプラットフォームシステムについて図５を参照しながら詳細に説明する。図５は、プラットフォームシステム５００の各種機能を示した図である。図５において、サーバーコンピュータ群１０２内にある物理ハードウェア・リソースは、プラットフォームシステム５００を実現するために使用される。サーバーコンピュータ群１０２のプラットフォームシステム５００の利用者は、このサーバーコンピュータ群１０２内にある物理ハードウェア・リソースをコンピューティング・リソースとして使用できる。また、プラットフォームシステム５００は、分散環境を提供するシステムである。
【００４９】
サーバーコンピュータ群１０２のプラットフォームシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）５００は、次のような機能を提供する。ヴァーチャルマシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅｓ）５０１、および５０２。ファブリックコントローラ（Ｆａｂｒｉｃ  Ｃｏｎｔｒｏｌｌｅｒ）５０３。ロードバランサー（Ｌｏａｄ  Ｂａｌａｎｃｅｒ）５０４。キューストレージサービス（Ｑｕｅｕｅ）５０５。テーブルストレージサービス（Ｔａｂｌｅ）５０６。ブロブストレージサービス（Ｂｌｏｂ）５０７である。
【００５０】
サーバーコンピュータ群１０２上で実現されるプラットフォームシステム５００には、ヴァーチャルマシン５０１、５０２が複数存在する。ヴァーチャルマシンとは、仮想化技術によって物理的なサーバーコンピュータ群１０２を論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータのことである。この論理的なコンピュータの単位は、インスタンスとして数えられる。本発明の実施例１では、インスタンス数１つ（即ち、ヴァーチャルマシン１台）に対し、サーバーコンピュータ群１０２内の１台のサーバーコンピュータが割り当てられるものとする。
【００５１】
ヴァーチャルマシン５０１は、要求受信部（Ｗｅｂ  Ｒｏｌｅ  Ｉｎｓｔａｎｃｅ）５０９、要求受信部エージェント（Ａｇｅｎｔ）５１０で構成される。要求受信部５０９は、後述するロードバランサー５０４を介してユーザーからの処理依頼を受信する。また、要求受信部５０９は、キューストレージサービス５０５を介してバックエンド処理部５０２への処理依頼を送信する。要求受信部５０９の高い可用性を確保するために、外部ネットワークからの要求（ここではＨＴＴＰによる通信）は、ヴァーチャルマシン５０１の外部にあるロードバランサー５０４を通じて行われる。ロードバランサー５０４は、外部ネットワークからの要求を一元的に管理し、要求受信部５０９と同等な要求受信機能を有する複数のヴァーチャルマシンに対し、選択的に要求を転送するものである。要求受信部エージェント５１０は、ヴァーチャルマシン５０１の使用状況、要求受信部５０９の稼動状態、ヴァーチャルマシン５０１のリソースの使用状況、および要求受信部５０９のエラーを含む各種情報を収集する。そして、ファブリックコントローラ５０３に定期的に送信する。なお、ヴァーチャルマシン５０１は、図４で示す要求受信部４０１に相当する。ヴァーチャルマシン５０１は、要求受信プログラムによって実現され、ヴァーチャルマシン５０１の各種機能は要求受信プログラムの制御化にある。
【００５２】
要求受信部５０９、バックエンド処理部５１１の各インスタンスは、ファブリックコントローラ５０３によって管理されている。そのため、各インスタンスの拡張性と可用性が保証される。例えば、要求受信部５０９、またはバックエンド処理部５１１において、ある特定のインスタンスがサーバーの故障によって停止したとする。この場合、ファブリックコントローラ５０３は、要求受信部エージェント５１０、またはバックエンド処理部エージェント５１２から定期通知を受け取れなくなる。定期通知を受け取らなくなったファブリックコントローラ５０３は、新しいインスタンスに処理が委譲されるようにヴァーチャルマシンに指示を出す。つまり、新しいヴァーチャルマシンは、故障、もしくはそれに類似する事象によって起動できなくなったヴァーチャルマシンの代替として機能するのである。結果、処理を実行しているインスタンス数が一定に保たれるため、処理の遅延を抑えることができる。
【００５３】
ヴァーチャルマシン５０２は、バックエンド処理部（Ｗｏｒｋｅｒ  Ｒｏｌｅ  Ｉｎｓｔａｎｃｅ）５１１、バックエンド処理部エージェント（Ａｇｅｎｔ）５１２で構成される。バックエンド処理部５０２は、キューテーブル５０５を介して要求受信部５０９からの処理依頼を受信する。バックエンド処理部５１１は、キューサービス５０５を介して要求受信部５０９から受信した処理依頼を実行する。また、バックエンド処理部５１１は、スケールアウトする。スケールアウトとは、ヴァーチャルマシン５０２が増加し、バックエンド処理部５１１のインスタンスが増加すること指す。バックエンド処理部５１２のインスタンスが増加すると、バックエンド処理部１つ当たりのデータ処理量が減少する。これにより、ユーザーからの処理依頼に対する結果をより早く返すことができる。なお、スケールアウトの指示は、要求受信部５０９によって行われる。なお、ヴァーチャルマシン５０２は、図４で示すバックエンド処理部４０２に相当する。ヴァーチャルマシン５０２は、バックエンド処理プログラムによって実現され、ヴァーチャルマシン５０２の各種機能はバックエンド処理プログラムの制御下にある。
【００５４】
キューサービス５０５は、要求受信部５０９とバックエンド処理部５１１とが非同期でデータ通信するためのサービスを提供する。要求受信部５０９、およびバックエンド処理部５１１は、キューストレージサービス５０５に対し各種指示を出すことで、非同期でデータ通信する。これについて、具体的に説明する。要求受信部５０９がキューストレージサービス５０５に対して行う指示とは、キューメッセージの追加指示（挿入）である。バックエンド処理部５１１がキューストレージサービス５０５に対して行う指示とは、キューメッセージの取得指示、およびキューメッセージの削除指示である。
【００５５】
要求受信部５０９とバックエンド処理部５１１が非同期でデータ通信する一連の動作について説明する。要求受信部５０９は、ユーザーからの処理依頼に応じたキューメッセージ６００を作成し、キューメッセージ６００をキューに追加するようにキューストレージサービス５０５に追加指示を送信する。追加指示を受信したキューストレージサービス５０５は、キューにキューメッセージ６００を追加する。バックエンド処理部５１１は、キューメッセージ６００を取得するために、キューサービス５０５に取得指示を出す。取得指示を受けたキューストレージサービス４０５は、キューメッセージ６００と、キューメッセージ６００毎に固有に割り振られたメッセージＩＤと、ジョブＩＤとを取得指示に対するレスポンスとしてバックエンド処理部５１１に返す。メッセージＩＤとは、キューメッセージ６００を一意に定めるために、キューメッセージ６００毎に割り振られた固有の情報であり、処理が終了したバックエンド処理部５１１が、キューメッセージ６００を削除指示する際に使用する。ジョブＩＤは、実際に処理する内容を一意に定めるためのＩＤである。バックエンド処理部５１１は、処理依頼を完了すると、メッセージＩＤに対応するキューメッセージの削除指示をキューストレージサービス５０５に対して行う。削除指示を受けたキューストレージサービス５０５は、バックエンド処理部５１１が指示したメッセージＩＤに対応するキュースメッセージをキューから削除する。これにより、削除指示を出したバックエンド処理部５１１以外のバックエンド処理部５１１が同じキューメッセージを処理するという冗長な処理を防ぐことができる。
【００５６】
また、キューストレージサービス５０５は、キューに追加されているキューメッセージ６００を不可視、または可視にする機能を持つ。不可視とは、バックエンド処理部５１１がキューに追加されているキューメッセージ６００の取得要求をした場合に、キューストレージサービス５０５はバックエンド処理部５１１に対してキューメッセージ６００を渡さないことを指す。バックエンド処理部５１１がキューからキューメッセージ６００を取得すると、取得されたキューメッセージはキュースストレージサービス５０５によって不可視になる。不可視とは、バックエンド処理部５１１がキューに追加されているキューメッセージ６００の取得要求した場合に、キューストレージサービス５０５がバックエンド処理部５１１に対してキューメッセージを渡すことを指す。バックエンド処理部５１１に取得され不可視になっているキューメッセージは、処理を行っているバックエンド処理部５１１から処理結果が一定時間返ってこない場合にキューストレージサービス４０５によって可視になる。上述の可視とは、前述の可視のことを指す。これにより、バックエンド処理部５１１が異常終了し処理を継続できない場合でも自動的に処理がリトライされることになる。
【００５７】
テーブルストレージサービス５０６は、データ保存に利用されるストレージを提供する。テーブルストレージサービス５０６では、データをエンティティと型情報のプロパティを組み合わせた単純な形式でデータを保管する。
【００５８】
ブロブストレージサービス５０７は、データ保存に利用されるストレージを提供する。バイナリデータの集合を保存する機能を提供する。
【００５９】
次に、本発明の実施例１におけるキューメッセージ６００について説明する。図６は、キューメッセージの一例を示した図である。キューメッセージは、要求受信部５０９がバックエンド処理部５１１に依頼する処理の内容を記述したものである。
【００６０】
リクエスト６０１は、キューメッセージ６００を追加するキューストレージサービス５０５の場所を示している。ヘッダー６０２は、キューストレージサービス５０５へアクセスするための認証情報等を送信する。ここでの認証情報とは、キューストレージサービス５０５を利用するために必要な文字列のハッシュ値である。キューストレージサービス５０５は、このヘッダー情報を読み込んで内部に保持している文字列と比較することで認証を行い、ヘッダー６０２を含むキューメッセージ６００を受け入れることが可能であるか否かを判断する。次に、キューメッセージ６００のメッセージデータコンテンツ部分について説明する。メッセージデータコンテンツ部分は、ユーザーからの処理依頼に応じて決定される。＜ＭｅｓｓｇａＴｅｘｔ＞６０３は、ジョブＩＤを示している。図６の場合、ジョブＩＤは“ｐｋ０１｜ｊｏｂ０１”である。ジョブＩＤは、ユーザーからの処理依頼に応じて作成される一意な情報であり、上述のジョブＩＤのことである。
【００６１】
次に、本発明の実施例１におけるジョブテーブルについて説明する。ジョブテーブルでは、バックエンド処理部４０２にて実施する一連の処理をジョブとして管理し、それらジョブの内容や処理状況等のデータ（情報）を保持する。ジョブテーブルはテーブルストレージサービス５０６にて保持される。
【００６２】
図７は、実際に保持されるジョブテーブル７００を示す図である。ＥＴａｇ７０１は、テーブルストレージサービス５０６が自動的に設定する値で、列データが更新された際に一意の値が書き込まれる。テーブルより取得したデータを更新する際に、データ取得時のＥＴａｇ７０１の値と、データ更新時のＥＴｇａ７０１の値が異なる場合、他の処理プロセスによりテーブルが更新されたことが識別できる。
【００６３】
ＰａｒｔｉｔｉｏｎＫｅｙ７０２とＲｏｗＫｅｙ７０３にてテーブルの列を一意に識別するＩＤとなる。ジョブテーブル７００では、これら二つの値によりジョブが特定される。即ち、これら二つの値がジョブＩＤに相当する。なお、ＲｏｗＫｅｙ７０３のみで、ジョブＩＤを特定しても良い。
【００６４】
ＳｔａｒｔＴｉｍｅ７０４は、バックエンド処理部４０２により処理されるジョブの処理開始日時、ＥｎｄＴｉｍｅ７０５はジョブの処理終了日時が登録される。ジョブの開始前や終了前は初期値が設定される。
【００６５】
Ｓｔａｔｕｓ７０６は、ジョブ全体のステータスを保持する。ジョブのステータスは、ジョブの処理状況に応じて、Ｒｅａｄｙ（準備完了）、Ｐｒｏｃｅｓｓｉｎｇ（処理中）、Ｓｕｃｃｅｓｓ（成功）、Ｆａｉｌｕｒｅ（失敗）で管理される。ここで準備完了ステータス（Ｒｅａｄｙ）とは、要求受信部４０１がジョブテーブルにジョブを追加後、バックエンド処理部４０２がジョブを処理開始する前までの状態を示す。処理中ステータス（Ｐｒｏｃｅｓｓｉｎｇ）とは、バックエンド処理部４０２がジョブの処理を開始して、ジョブに定義された全てのタスクを処理し終わる、もしくは途中で処理に失敗するまでの状態を示す。成功ステータス（Ｓｕｃｃｅｓｓ）とは、バックエンド処理部４０２がジョブに定義された全てのタスクを処理し、そのすべてのタスク処理が成功した状態を示す。失敗ステータス（Ｆａｉｌｕｒｅ）とは、バックエンド処理部４０２がタスクを実行した結果、処理に失敗した状態、もしくはタスク実行前にサービスの品質が一定基準を満たしてないと判定された状態を示す。なお、上述の通り、１つのジョブは少なくとも１つ以上のタスクで構成されており、ジョブを構成する少なくともと１つ以上のタスク全てが処理されることで１つのジョブの処理が完了する。
【００６６】
ＤａｔａＩＤ７０７は、ジョブに関連付いたデータ、に対するＩＤを示している。データはブロブストレージサービス５０７にて保存されており、ブロブストレージサービス５０７内で一意の値となる。
【００６７】
ＬａｓｔＴａｓｋ７０８は、実行が完了したタスクの番号を記録する。ジョブは複数のタスクを順次処理することで成り立っている。ここで、タスクについて説明する。例えば、２つのタスクで構成されているジョブが存在するとする。このジョブを、仮にジョブＡと呼称する。ジョブＡは、２つのタスクで構成されている。ジョブＡは、１番目のタスクとして文書サーバー１０３からファイルを取得するタスク、２番目のタスクとしてデータをプリントスプーラサービス１０９に投入するタスクといった組み合わせで構成されている。なお、１番目のタスクをタスク１、２番目のタスクをタスク３と呼称する。この２つのタスクが順次実行されることでジョブＡは処理される。文書サーバー１０３からファイルを取得するタスクまで実行が終了すると、ＬａｓｔＴａｓｋ７０８には“１”が記録される。なお、タスクが何も実行完了していないときは“０”が記録される。また、データをプリントスプーラサービス１０９に投入するタスクまで実行が終了すると、ＬａｓｔＴａｓｋ７０８には“３”が記録される。また、ここでは記載しなかったが、本発明の実施例１では、次のようなタスクも存在する。即ち、１番目のタスクにより取得されたファイル（コンテンツ）を文書変換サーバー１０８に投入し、文書変換サーバー１０８によりコンテンツを変換させるタスクである。このタスクをタスク２と呼称する。タスク２の実行が終了すると、ＬａｓｔＴａｓｋ７０８には“２”が記録される。ＬａｓｔＴａｓｋ７０８を認することで、現在のタスク実行状況を特定することができる。なお、タスクには実行順序が定められており、ジョブＡを例に挙げれば、１番目のタスク、２番目のタスク、３番目のタスクと決められている。これは、後述するサービスシーケンステーブル９００で定められている。
【００６８】
ＬａｓｔＴａｓｋＲｅｓｕｌｔ７０９は最後に実行したタスクの処理結果を示す。タスクの処理結果は、Ｎｏｎｅ（タスク終了前の状態）、Ｓｕｃｃｅｓｓ（成功）、ＦａｉｌｕｒｅＲｅｔｒｙ（リトライ可能な失敗）、Ｆａｉｌｕｒｅ（失敗）で管理され、タスクは処理の結果を必ずいずれかの値で返す必要がある。処理が成功したときにはＳｕｃｃｅｓｓを返す。例えば、印刷サーバー１０９へ印刷データを登録する際、印刷サーバー１０９が一時的に高負荷状態で処理が完了できない場合、または、データ転送の通信が一時的に切断してしまった場合に、タスクは次のような値を返す。即ち、タスクは、再度処理を実行すれば成功する可能性が高い処理をＦａｉｌｕｒｅＲｅｔｒｙで返す。また、登録する印刷データが印刷サーバー１０９のサポートしていないフォーマットである、または印刷先の画像形成装置１０４を印刷サーバー１０９が認識していない場合のように、再度処理を実行しても成功しない場合には、Ｆａｉｌｕｒｅを返す。
【００６９】
ＬａｓｔＴａｓｋＴｒｙＣｏｕｎｔ７１０は最後に実行したタスクを何度実行したかを記録する。タスクがＦａｉｌｕｅｒＲｅｔｒｙ（リトライ可能な失敗）の処理結果で終了した場合にはそのタスクを再実行するが、その際、実行の回数を記録する。ＬａｓｔＴａｓｋＴｒｙＣｏｕｎｔ７１０が一定回数以上の数値になった場合、つまり繰り返しタスクの実行を再試行しても成功しなかった場合には、そのタスクはエラーとして制御される。
【００７０】
ＭａｘＴａｓｋ７１１はそのジョブにタスクが何個含まれるかを記録する。本発明の実施例１では、１から２０のタスクをジョブに含むことができる。なお、夫々のタスクを、タスク１、タスク２、タスク３等の様に、順番に呼称する。また、本発明の実施例１における、タスク１、タスク２、タスク３の夫々のタスクの処理の詳細については、上述した通りである。
【００７１】
Ｔａｓｋ１ＳｅｒｖｉｃｅＩＤ７１２からＴａｓｋ２０Ｐａｒａｍｅｔｅｒ７１７までがジョブに含まれるタスクに関する情報を管理する。Ｔａｓｋ１ＳｅｒｖｉｃｅＩＤ７１２は１番目に実行されるタスクを提供するサービスのＩＤを保持する。Ｔａｓｋ１Ｐａｒａｍｅｔｅｒ７１３はタスク１を実行する際にタスクに渡されるパラメータである。同様にＴａｓｋ２ＳｅｒｖｉｃｅＩＤ７１４、Ｔａｓｋ２Ｐａｒａｍｅｔｅｒ７１５は２番目に実行するタスクに関する情報であり、Ｔａｓｋ２０ＳｅｒｖｉｃｅＩＤ７１６、Ｔａｓｋ２０Ｐａｒａｍｅｔｅｒ７１７は２０番目に実行するタスクに関する情報である。このように２０個分のタスク情報が保持される。なお、本発明の実施例１では、２０設定したがタスク数の上限に関して特に制限はない。
【００７２】
次に、本発明の実施例１におけるサービステーブルについて説明する。サービステーブル８００では、タスクを提供するサービスの管理を行う。ジョブテーブル７００にも実行すべきサービスの情報が記載されているが、記載する目的は夫々以下の通りである。即ち、ジョブテーブル７００は、バックエンド処理部４０２がジョブの状態およびタスクの状態をタスクの実行前後のタイミングで書き込むためである。一方、サービステーブル８００は、プラットフォームシステム５００の提供者が、事前にサービス提供者から受け取ったサービスの定義を登録するものであり、状態情報の管理などは行わない。なお、サービス提供者とは、文書取り出しサーバー１０７、文書変換サーバー１０８、印刷サーバー１０９を利用したサービスを提供するユーザーのことを指す。即ち、本発明の実施例１では、タスク１、タスク２、タスク３を提供するユーザーのことである。サービステーブル８００は、テーブルストレージサービス５０６にて保持される。
【００７３】
図８は、サービステーブル８００を示す図である。ＥＴａｇ８０１は、ＥＴａｇ７０１と同様である。ＰａｒｔｉｔｉｏｎＫｅｙ８０２、およびＲｏｗＫｅｙ８０３によりテーブルの列を一意に識別するＩＤとなる。サービステーブルでは、ＰａｒｔｉｔｉｏｎＫｅｙ８０２はｓｅｒｖｉｃｅで固定値となり、ＲｏｗＫｅｙ８０３は後述するタスクサービスを識別するためのＩＤとして管理される。
【００７４】
ＵＲＩ８０４で、サービスが提供されているＷｅｂＳｅｒｖｉｃｅのＵＲＩを保持する。ここで管理されているＵＲＩに対してアクセスすることでサービスを利用することが可能となる。例えば、ＲｏｗＫｅｙ８０３がｓｅｒｖｉｃｅ０１を示しているタスクは、ＵＲＩ８０４を基に、文書取り出しサーバー１０７が提供する機能を利用することがわかる。
【００７５】
Ｔｙｐｅ８０５はサービスタイプを保持する。サービスタイプはＩｎ（入力サービス）、Ｐｉｐｅ（パイプサービス）、Ｏｕｔ（出力サービス）がある。入力サービスは、文書サーバー１０３からデータを取得するといった処理を行うサービスで、外部システムからデータを入力するサービスである。このサービスは、タスク１を実行することで実現される。パイプサービスは、文書データを印刷データに変換するといった処理を行うサービスで、データを加工するサービスである。このサービスは、タスク２を実行することで実現される。出力サービスは、データを印刷サーバーに投入するといった処理を行うサービスで、外部システムにデータを出力するサービスである。このサービスは、タスク３を実行することで実現される。なお、このように、Ｉｎ、Ｐｉｐｅ、Ｏｕｔに属する各種サービスを実現する機能をタスクサービスと呼称する。また、上述の通り各タスクサービスは、ＲｏｗＫｅｙ８０３により特定される。
【００７６】
Ａｔｔｒｉｂｕｔｅ８０６は、タスクサービスの属性情報を保持する。属性情報はタスクサービス毎に独自に定義した情報として登録される。例えば、文書サーバー１０３からデータを取得するタスクサービスでは、文書サーバー１０３のＵＲＩの情報を保持する。また、印刷サーバー１０９にジョブを投入するタスクサービスでは、印刷サーバーのＵＲＩの情報を保持する。
【００７７】
Ｖｅｒｉｆｉｃａｔｉｏｎ８０７は、そのサービスが本テーブルに登録される前にプラットフォーム提供ベンダーによって品質の検証がなされたかどうかを示すフラグが登録する。この値がＴＲＵＥであれば、登録前に品質の検証が行われたサービスであり、一定の品質が保証されたサービスであることを示す。この値がＦＡＬＳＥであれば、登録前に品質の検証が行われていない事をしめし、そのサービスの品質が未知数であることを示す。例えば、図８を参照すると、ＲｏｗＫｅｙ８０３がｓｅｒｖｉｃｅ０３のタスクサービスは、Ｖｅｒｉｆｉｃａｔｉｏｎ８０７がＴＲＵＥなので品質が保証されたサービスと言うことになる。その他のタスクサービスは、品質が保証されていない。即ち、Ｖｅｒｉｆｉｃａｔｉｏｎ８０７がＴＲＵＥになっているサービスは品質が保証されているので、プラットフォームシステム５００を有効に運用することが可能になる。なお、Ｖｅｒｉｆｉｃａｔｉｏｎ８０７がＴＲＵＥになっていないサービスは、プラットフォームシステム５００のリソースを無駄に利用する可能性や、プラットフォームシステム５００に対する攻撃を含むサービスである可能性もある。
【００７８】
次に、本発明の実施例１におけるサービスシーケンステーブルについて説明する。サービスシーケンステーブル９００では、サービスの処理順序の管理を行う。ジョブテーブル７００にもサービスの処理順序が記載されているが、記載する目的は夫々以下の通りである。即ち、ジョブテーブル７００は、バックエンド処理部４０２がタスクを処理順序どおりに実行した場合、タスク毎の状態や、次に実行すべきタスクの番号などをタスクの実行前後のタイミングで書き込み、夫々のタスクの状況を把握するためである。一方、サービスシーケンステーブル９００は、サービステーブル８００に登録済みの各種サービスがどのタスクサービスの組み合わせるかについて記載されたテーブルである。図９を用いて詳細に説明する。例えば、ＰａｒｔｉｔｉｏｎＫｅｙ９０２の値がｓｅｑｕｅｎｃｅ、ＲｏｗＫｅｙ９０３がｓｅｑ０１で特定されるジョブは、ＭａｘＴａｓｋ９０４から３つのタスクで構成されていることがわかる。また、前述のジョブは、Ｔａｓｋ１  ９０５、Ｔａｓｋ２  ９０６、Ｔａｓｋ３  ９０７から、夫々、ｓｅｒｖｉｃｅ０１、ｓｅｒｖｉｃｅ０２、ｓｅｒｖｉｃｅ０３で構成されていることがわかる。なお、Ｔａｓｋ１  ９０５、Ｔａｓｋ２  ９０６、Ｔａｓｋ３  ９０７で定義されている夫々のタスクサービスについては、サービステーブル８００を確認すれば、どのようなタスクサービスであるか特定することが可能である。
【００７９】
サービスシーケンステーブル９００は、テーブルストレージサービス５０６にて保持される。
【００８０】
図９は、サービスシーケンステーブル９００の一例を示した図である。Ｅｔａｇ９０１は、ＥＴａｇ７０１と同様である。ＰａｒｔｉｔｉｏｎＫｅｙ９０２とＲｏｗＫｅｙ９０３にてテーブルの列を一意に識別するＩＤとなる。サービスシーケンステーブルでは、ＰａｒｔｉｔｉｏｎＫｅｙ９０２はｓｅｑｕｅｎｃｅで固定値となり、ＲｏｗＫｅｙ９０３をシーケンスＩＤとして管理する。なお、シーケンスＩＤとジョブＩＤは異なるものである。シーケンスＩＤは、同じサービスを要求した処理依頼全てに対して共通のＩＤが割り振られるものである。しかし、ジョブＩＤは、要求したサービスが同じであっても、処理依頼１つ１つに対し固有に割り当てられるものであり、処理依頼を識別するための識別子として機能する。これにより、図７に登録されている夫々のジョブに必要となるタスクサービスを特定することができる。
【００８１】
ＭａｘＴａｓｋ９０４で、そのシーケンスに含まれるタスクの数を定義する。本実施例では１から２０のタスクをシーケンスに含むことができる。
【００８２】
Ｔａｓｋ１  ９０５からＴａｓｋ２  ９０９までがシーケンスに含まれるタスクに関する情報を管理する。Ｔａｓｋ１  ９０５は１番目に実行されるタスクを提供するサービス（タスクサービス）のＩＤを保持する。以降、同様にＴａｓｋ２  ９０６は２番目に実行するタスクに関する情報であり、Ｔａｓｋ２０  ９０９の２０番目に実行するタスクに関する情報までの２０個分のタスク情報を保持する。なお、上述の通り、本発明の実施例１では上限を２０としたが、タスク数の上限に関しては別の値でも良い。
【００８３】
次に、本発明の実施例１において、サービステーブル８００に登録されているタスクサービス、即ち、文書取り出しサービス４１０、文書変換サービス４１１、スプールサービス４１２が実装するインターフェースについて詳細な説明をする。
【００８４】
まず、タスクサービスは、ＩＮ  ／  ＰＩＰＥ  ／  ＯＵＴの３種類に分類され、夫々が決められたインターフェースを実装する。実装したタスクサービスにより担当する処理が異なる。
【００８５】
ＩＮタイプのタスクサービスは、図１２の（ａ）で図示されるインターフェースを有する必要があり、本発明の実施例１では文書取り出しサービス４１０が本インターフェースを実装している。
【００８６】
１２０１は、実行指示受付部１２０１で、バックエンド処理部４０２からタスクの実行指示の受付とパラメータの受け取りを行う。ここで言うパラメータとは、例えば、Ｔａｓｋ１Ｐａｒａｍｅｔｅｒ７１３である。また、実行指示を受けた実行指示受付部１２０１は、処理プログラム１２０２を実行し、処理プログラム１２０２の実行終了後にタスク終了通知をバックエンド処理部４０２に対して応答する。
【００８７】
処理プログラム１２０２は、特定の処理を行うよう決められた処理プログラムであり、ＩＮタイプの場合には、Ｗｅｂｓｅｒｖｉｃｅ内部でデータを生成するか、文書サーバー１０３のような外部サーバーからデータを取得するなどの処理を行う。また処理プログラム１２０２は、生成／取得したデータは出力データ保存部１２０３に保存し、実行結果（成功／失敗などの結果ステータス）は実行結果保存部１２０４に保存する。１２０３は、出力データ保存部であり、タスクを実行した結果出力されるデータが保持される領域である。１２０４は、実行結果保存部であり、タスクの実行結果（成功／失敗などの結果ステータス）が保持される領域である。
【００８８】
結果取得要求受付部１２０５は、バックエンド処理部４０２からの結果取得要求を受け付けて、出力データ保持部１２０３と実行結果保持部１２０４に保持されている情報を読み出し、バックエンド処理部４０２に対してデータを返す役割を担う。
【００８９】
属性取得要求受付部１２０６は、バックエンド処理部４０２からの属性取得要求に従って、適切な情報を属性情報保持部１２０７から取得し、そのサービスの属性を返す役割を担う。属性取得要求受付部１２０７は、サービスＩＤ、サービスタイプ、開発元ＩＤなどの情報を保有する。サービスＩＤとはサービステーブル８００に登録する際のサービスＩＤと同一で、サービスを一意に特定する情報である。サービスタイプとは、上述の通り、タスクサービスがＩＮ／ＰＩＰＥ／ＯＵＴのいずれに相当するかを表す情報である。開発元ＩＤは、タスクサービスの機能を開発した開発元を特定することが可能な情報である。即ち、これらタスクサービスを開発したユーザーを示している。ＩＮタイプのタスクサービスを取得タスクサービスと呼ぶ。
【００９０】
ＰＩＰＥタイプのタスクサービスは、図１２の（ｂ）で図示されるインターフェースを有する必要があり、本発明の実施例１では、文書変換サービス４１１が本インターフェースを実装している。
【００９１】
入力データ受付部１２０８は、バックエンド処理部４０２からの入力データ格納要求に基づいて送付されてきたデータを、入力データ格納部１２０９に格納する役割を担う。入力データ格納部１２０９は、タスクサービスに入力されたデータを保持する領域である。実行指示受付部１２１０は、実行指示受付部で、バックエンド処理部４０２からタスクの実行指示の受付とパラメータの受け取りを行う。また、実行指示を受けた１２１０は、処理プログラム１２１１を実行し、処理プログラム１２１１の終了後にタスク終了通知をバックエンド処理部４０２に対して応答する。
【００９２】
処理プログラム１２１１は、特定の処理を行うよう決められた処理プログラムであり、ＰＩＰＥタイプの場合には、入力データ格納部１２０９からデータを取得し、処理したデータを出力データ保存部１２１２に保存する処理を行う。また処理プログラム１２１１は、実行結果（成功／失敗などの結果ステータス）は実行結果保存部１２１３に保存する。結果取得要求受付部１２１４は、結果取得要求受付部１２０５と同等の機能を持つ。即ち、結果取得要求受付部１２１４は、バックエンド処理部４０２からの結果取得要求を受け付けて、出力データ保持部１２１２と実行結果保持部１２１３に保持されている情報を読み出し、バックエンド処理部４０２に対してデータを返す役割を担う。ＰＩＰＥタイプのタスクサービスを処理タスクサービスと呼ぶ。
【００９３】
ＯＵＴタイプのタスクサービスは、図１２の（ｃ）で図示されるインターフェースを有する必要があり、本発明の実施例１ではスプールサービス４１２が本インターフェースを実装している。入力データ受付部１２１７は、バックエンド処理部４０２からの入力データ格納要求に基づいて送付されてきたデータを、入力データ格納部１２１８に格納する役割を担う。入力データ格納部１２１８は、タスクサービスに入力されたデータを保持する領域である。
【００９４】
実行指示受付部１２１２は、バックエンド処理部４０２からタスクの実行指示の受付とパラメータの受け取りを行う。また、実行指示を受けた１２１９は、処理プログラム１２２０を実行し、処理プログラム１２２０の終了後にタスク終了通知をバックエンド処理部４０２に対して応答する。
【００９５】
処理プログラム１２２０は、特定の処理を行うよう決められた処理プログラムであり、ＯＵＴタイプの場合には、入力データ格納部１２１８からデータを取得し、処理したデータをスプールサービス４１２内で保存管理する処理を行う。また処理プログラム１２２０は、実行結果（成功／失敗などの結果ステータス）は実行結果保存部１２２１に保存する。
【００９６】
結果取得要求受付部１２２２は、バックエンド指示部からの結果取得要求を受け付けて、実行結果保持部１２２１に保持されている情報を読み出し、バックエンド処理部４０２に対してデータを返す役割を担う。ＯＵＴタイプのタスクサービスを送信タスクサービスと呼ぶ。
【００９７】
なお、上述した各タスクサービスの各種機能は、いずれも間接記憶部３０３に保存されたプログラムが、ＣＰＵ３０１により読みだされ実行されることで実現する。また、出力データ保存部１２０３、実行結果保存部１２０４、属性情報保持部１２０７は、いずれも直接記憶部３０２もしくは間接記憶部３０３に確保された領域である。また、入力データ格納部１２０９、出力データ保存部１２１２、実行結果保存部１２１３、属性情報保持部１２１６、入力データ格納部１２１８、実行結果保存部１２２０、属性情報保持部１２１４も同様である。なお、本発明の実施例１におけるＩＮ／ＰＩＰＥ／ＯＵＴの３種類のインターフェースは、プラットフォームシステム５００の開発元により公開されるオープンな仕様である。
【００９８】
この３種類のインターフェースを利用したサービスアプリケーションを開発した者は、プラットフォームシステム５００の開発元に依頼してサービステーブル８００、およびシーケンステーブル９００にそのサービスアプリケーションの情報を登録してもらう。これにより、プラットフォームシステム５００を介して画像形成装置１０４とサービスアプリケーションとが連携したサービスを、画像形成装置１０４のユーザーに対して提供することが可能となる。即ち、ＩＮ／ＰＩＰＥ／ＯＵＴのインターフェースを実装したＷｅｂｓｅｒｖｉｃｅを生成することで、プラットフォームシステム５００を利用でき、画像形成装置１０４にＷｅｂｓｅｒｖｉｃｅを提供することができるのである。結果、サービスアプリケーション開発者は、処理プログラム１２０２、１２１１、１２１３の夫々の内部構成（ノウハウ・技術）を公開せずに、画像形成装置１０４、プラットフォームシステム５００と連携動作させることが可能となる。
【００９９】
ここで、夫々のタスクサービスについてまとめる。ＩＮタイプは、サービス内部でデータを生成するか、文書サーバー１０３のような外部サーバーからデータを取得するなどプラットフォームシステム５００からの入力情報を必要としないタイプのサービスである。ＰＩＰＥタイプは、プラットフォームシステム５００から明示的に指定された入力データを処理し、その結果をプラットフォームシステム５００へ出力する事を前提としたタイプのサービスである。ＯＵＴタイプは、プラットフォームシステム５００から明示的に入力データを受け入れるタイプで、その結果はサービス内部で完結、もしくは外部サーバーへ送信するなど、プラットフォームシステム５００へ出力しない事を前提としたタイプのサービスである。
【０１００】
以上のように、ＩＮ／ＰＩＰＥ／ＯＵＴの３種類のタイプのサービスインターフェースを規定することで、次のような効果がある。即ち、アプリケーション提供者は、最初がＩＮ、最後がＯＵＴで、その間をＰＩＰＥでつなぐシーケンスを容易に設計し、アプリケーションから呼び出すことが可能となる。なお、タスクサービスを３種類のタイプに分けることにより、処理プログラムの流用性を高めることができる。
【０１０１】
以上までが、本発明の実施例１におけるプリントシステム１０００の構成に関する説明である。
【０１０２】
続いては、本発明の実施例１におけるプリントシステム１０００の処理の流れについて説明をする。図１０は、本発明の実施例１のプリントシステム１０００における全体の処理の流れを表したシーケンス図である。
【０１０３】
ユーザーが画像形成装置１０４のデバイスブラウザ４０９にて操作を開始するところから一連の処理が開始される。デバイスブラウザ４０９は要求受信部４０１にて動作する印刷アプリケーションと通信し印刷処理を行う。即ち、要求受信部４０１のその他の機能として、印刷を支援するための各種機能も実行する。図１１は、デバイスブラウザ４０９に表示される印刷画面を示す図である。図１１が示す画面は、要求受信部４０１にて動作する印刷アプリケーションが生成する。
【０１０４】
印刷先１１０１は、ユーザーが現在操作している画像形成装置１０４を一意に定めているデバイスＩＤが表示される。文書サーバー１１０２は、データを取得する文書サーバーのＵＲＬが表示される。本発明の実施例１では、サービステーブル８００のＡｔｔｒｉｂｕｔｅ８０６に登録されているデータが表示される。対象文書１１０３は、実際に印刷する文書のＩＤであり、ユーザーが入力する。本図の例ではｆｏｌｄｅｒ／ｆｉｌｅ．ｄｏｃという文書を印刷することになる。なお、この文書は、文書リポジトリ４０６により保持されている。印刷ボタン１１０４は、ユーザーが押下するとあらかじめ定義された印刷シーケンスを実行するよう指示が行われる。具体的には、印刷ボタン１１０４には、シーケンステーブル図９の９０３で定義されているシーケンスＩＤが割り当てられており、ボタン押下することでシーケンスＩＤが送信される仕組みになっている。
【０１０５】
例えば、ｓｅｑ０１が割り当てられている場合、ｓｅｑ０１に対応するタスクが実行されることになる。図１１で示す印刷ボタン１１０４が押下されると、デバイスブラウザ４０９は、要求受信部４０１に対して印刷指示要求を行う（Ｓ１００１）。この印刷指示要求には、対象文書１１０３に入力された文書ＩＤと、印刷先１１０１に表示されるデバイスＩＤ、および印刷ボタン１１０４に割り当てられたシーケンスＩＤがパラメータとして渡される（ジョブ受信）。
【０１０６】
印刷指示要求を受け付けた要求受信部４０１は、テーブルストレージサービス４０４に保持されているサービスシーケンステーブル９００に対して、シーケンスの取得要求を行う（Ｓ１００２）。シーケンス取得要求において、要求受信部４０１は、シーケンスＩＤをパラメータとしてテーブルストレージサービス４０４に渡す。テーブルストレージサービス４０４は、要求されたシーケンスＩＤのシーケンスデータを要求受信部４０１に返す（Ｓ１００３）。なお、シーケンスデータとは、サービスシーケンステーブル９００にて定義されている各種タスクの情報のことである。要求受信部４０１は、テーブルストレージサービス４０４に保持されているジョブテーブル７００に対して、ジョブ追加要求を行う（Ｓ１００４）。ジョブ追加要求において、要求受信部４０１は、パラメータとして、シーケンスデータ、および文書ＩＤ等のパラメータデータをテーブルストレージサービス４０４に渡す。
【０１０７】
テーブルストレージサービス４０４は、要求受信部４０１から渡されたパラメータを基にジョブの生成追加処理を行い、生成したジョブのＩＤを要求受信部４０１に返す（Ｓ１００５）。なお、生成したジョブのＩＤは、上述の通り、ＰａｒｔｉｔｉｏｎＫｅｙ７０２、ＲｏｗＫｅｙ７０３により特定される。要求受信部４０１は、キューストレージサービス４０５に対して、メッセージ追加要求を行う（Ｓ１００６）。メッセージ追加要求では、ステップＳ１００５で取得したジョブＩＤをパラメータとして渡す。キューストレージサービスはメッセージの追加処理を行う。なお、ここで言うメッセージとは上述したキューメッセージ６００のことであり、ジョブＩＤはキューメッセージ６００内の＜ＱｕｅｕｅＭｅｓｓａｇｅ＞６０３が示す値である。要求受信部４０１は、ステップＳ１００１の要求に対する応答として、ジョブＩＤをデバイスブラウザ４０９に対して送信する（Ｓ１００７）。以上で、ユーザーの印刷指示オペレーションは完了する。次にプラットフォームアプリケーション４０８が印刷データを取得する処理を説明する。
【０１０８】
ステップＳ１００７でジョブＩＤを取得したデバイスブラウザ４０９は、プラットフォームアプリケーション４０８に対して監視指示を行う（Ｓ１０５０）。この際、デバイスブラウザ４０９は、パラメータとしてジョブＩＤをプラットフォームアプリケーション４０８に渡す。プラットフォームアプリケーション４０８は、要求受信部４０１に対して印刷データを要求する（Ｓ１０５１）。印刷データの要求において、プラットフォームアプリケーション４０８は、パラメータとしてジョブＩＤとデバイスＩＤを要求受信部４０１に渡す。
【０１０９】
要求受信部４０１は、テーブルストレージサービス４０４に対して、ジョブ情報取得要求を行う（Ｓ１０５２）。ジョブ情報取得要求において、要求受信部４０１は、引数としてＳ１０５１で受け取ったジョブＩＤをテーブルストレージサービス４０４に渡す。テーブルストレージサービス４０４は、ジョブテーブル７００から、取得要求されたジョブＩＤに合致するジョブを探し、結果を要求受信部４０１へ応答する。要求受信部４０１は、ジョブ情報を取得し、ジョブのステータスを示すＳｔａｔｕｓ７０６から、ジョブ処理が継続中か完了しているかどうかを判断する。本発明の実施例１におけるｊｏｂ０１は、Ｓ１０５３の応答を受けた時点で処理継続中のため、要求受信部４０１は、プラットフォームアプリケーション４０８に対して印刷データなしの応答を行う（Ｓ１０５４）。
【０１１０】
プラットフォームアプリケーション４０８は、印刷データが取得できるまで繰り返し要求受信部４０１に対して印刷データ要求を行う。ステップＳ１０５５の印刷データ要求が繰り返しの要求である。ステップＳ１０５５の印刷データ要求、ステップＳ１０５６のジョブ情報要求の処理、ステップＳ１０５７のジョブ情報取得は、夫々、ステップＳ１０５１、ステップＳ１０５２、ステップＳ１０５３と同様の処理である。本発明の実施例１では、Ｓ１０５７の応答を受けた時点でのジョブ処理は完了状態のため、要求受信部４０１は、スプールサービス４１２に対して印刷データ取得要求を行う（Ｓ１０５８）。
【０１１１】
印刷データ取得要求において、要求受信部４０１は、パラメータとしてジョブＩＤとデバイスＩＤをスプールサービス４１２に渡す。スプールサービス４１２は、指定されたジョブＩＤ、およびデバイスＩＤに合致するデータの有無をチェックし、存在する場合は印刷データを要求受信部４０１に送信する（Ｓ１０５９）。スプールサービス４１２より応答を受けた要求受信部４０１は、プラットフォームアプリケーション４０８に印刷データの送信を行う（Ｓ１０６０）。プラットフォームアプリケーション４０８は、画像形成装置１０４の印刷ユニットにより、印字出力されるよう印刷データの処理を行う。
【０１１２】
以上が、画像形成装置１０４にてユーザーが印刷を依頼し、印刷結果が出力されるまでのフローである。引き続き、プラットフォームシステム５００と、各種Ｗｅｂｓｅｒｖｉｃｅの連携動作について説明する。
【０１１３】
バックエンド処理部４０２は、キューストレージサービス４０３に対して定期的にメッセージ取得要求を行う（Ｓ１０１１）。ステップＳ１０１１にてキューよりメッセージが取得できたら、バックエンド処理部４０２は、＜ＭｅｓｓａｇｅＴｅｘｔ＞６０３からジョブＩＤを取り出す。
【０１１４】
バックエンド処理部４０２は、テーブルストレージサービス４０４に対してジョブ・サービス情報取得要求を行う（Ｓ１０１２）。この時、テーブルストレージサービス４０４は、まずジョブテーブル７００より、ジョブＩＤに対応したジョブの情報を取得する。次に、テーブルストレージサービス４０４は、ジョブ情報より、次に実行すべきタスクに対応するタスクサービスのＩＤを取得しする。テーブルストレージサービス４０４は、取得したタスクサービスのＩＤを基に、サービステーブル８００からタスクサービスのＩＤに対応したサービス情報を取得する。テーブルストレージサービス４０４は、ジョブ・サービス情報をＳ１０１２の応答としてバックエンド処理部４０２に返す（Ｓ１０１３）。なお、次に実行すべきタスクは、最後に実施されたタスクの情報を確認することで特定することが可能である。
【０１１５】
バックエンド処理部４０２は、取得したジョブ情報・サービス情報を元にタスクの実行指示を行う（Ｓ１０１４）。タスクの実行時、バックエンド処理部４０２は、ジョブテーブル７００で管理されているパラメータを引数として渡す。本発明の実施例１においては、バックエンド処理部４０２は、文書取り出しサービス４１０の実行指示受付部１２０１に対してタスク実行指示を行う。タスク実行指示を受けた実行指示受付部１２０１は、処理プログラム１２０２を実行する。なお、処理プログラム１２０２で実行されるタスクは、文書リポジトリ４０６に対して文書取得要求を行う（Ｓ１０１５）。文書取得要求において文書取り出しサービス４１０は、パラメータとして文書ＩＤを文書リポジトリ４０６に渡す。文書リポジトリ４０６のＵＲＬや文書ＩＤは、ステップＳ１０１４にてバックエンド処理部４０２より渡されたパラメータの情報が元になっている。
【０１１６】
ステップＳ１０１５にて文書取得要求を受けた文書リポジトリ４０６は、文書取り出しサービス４１０における処理プログラム１２０２に対して、指定された文書ＩＤの文書データを返す（Ｓ１０１６）。処理プログラム１２０２は、受け取った文書データを出力データ保存部１２０３に保存する。また、処理プログラム１２０２は処理の実行結果（成功／失敗などの実行結果ステータス）を実行結果保存部１２０４に保存して、プログラムを終了する。処理プログラム１２０３が終了すると、実行指示受付部１２０１は、Ｓ１０１４の応答としてタスク終了通知をバックエンド処理部４０２に対して返す（Ｓ１０１７）。
【０１１７】
バックエンド処理部４０２は、文書取り出しサービス４１０における結果取得要求受付部１２０５に対して結果取得要求を行う（Ｓ１０１８）。結果取得要求受付部１２０５は、出力データ保存部１２０３に保存されている文書データと実行結果保存部１２０４に保存されている結果ステータスを読みだし、Ｓ１０１８の応答としてバックエンド処理部４０２に返す（Ｓ１０１９）。応答を受けたバックエンド処理部４０２は、文書保存にて文書データをブロブストレージサービス４０５に格納する（Ｓ１０２０）。さらに、バックエンド処理部４０２は、ジョブ情報更新にてテーブルストレージサービス４０４のジョブテーブル７００に対して、タスクの実行結果を反映する（Ｓ１０２１）。
【０１１８】
以上で、タスク１の処理が終了する。一連のタスク処理が終了したところでバックエンド処理部４０２は、次のタスク（タスク２）を実行するために、キューストレージサービス４０３に対してメッセージの追加と削除を行う。まず、バックエンド処理部４０２は、メッセージ追加要求にて、キューストレージサービス４０３に現在処理したジョブＩＤのメッセージを追加する（Ｓ１０２２）。これにより次に処理すべきタスクの処理依頼が行われたことになる。引き続きバックエンド処理部４０２は、ステップＳ１０２３のメッセージ削除要求にてキューストレージサービス４０３から、現在処理したメッセージを削除する。これにより、処理したタスクに対応したメッセージがキューより削除され、タイムアウトによる再実行処理が行われなくなる。
【０１１９】
引き続きタスクの実行のシーケンスを説明する。次は、タスク２による処理までを説明する。
【０１２０】
ステップＳ１０６０からステップＳ１０６３はステップＳ１０１０からステップＳ１０１３と同様の処理である。バックエンド処理部４０２は、取得したジョブ情報・サービス情報を基に、ブロブストレージサービス４０５から文書データの取得を行う（Ｓ１０６４）。本発明の実施例１において、バックエンド処理部４０２は、ステップＳ１０２０にて保存された文書を取得している。
【０１２１】
バックエンド処理部４０２は、文書変換サービス４１１の入力データ受付部１２０８に対して入力データ格納要求を実行する（Ｓ１０６５）。入力データ格納要求時、バックエンド処理部４０２は、Ｓ１０６４にて取得した文書データを引数として渡す。入力データ格納要求を受け取った入力データ受付部１２０８は、引数として渡された文書データを受け取り、入力データ保持部１２０９に格納する。バックエンド処理部４０２は、文書変換サービス４１１における実行指示受付部１２１０に対してタスク実行指示を行う（Ｓ１０６６）。タスク実行指示時、バックエンド処理部４０２は、ジョブテーブル７００で管理されているパラメータを引数として実行指示受付部１２１０に渡す。
【０１２２】
タスク実行指示を受けた実行指示受付部１２１０は、処理プログラム１２１１を実行する。処理プログラム１２１１が実行されると、入力データ格納部１２０９に格納されているデータに対して、定められたデータ変換処理を行い、変換結果を出力データ保存部１２０３へ保存する。本発明の実施例１では、Ｓ１０１５で取得したデータがワープロ文書などの業務アプリ文書であることを想定し、処理プログラム１２１１では前記業務アプリ文書を画像形成装置１０４が処理可能なデータ形式（ＰＤＦ）に変換する。
【０１２３】
また、処理プログラム１２１１は、処理の実行結果（成功／失敗などの実行結果ステータス）を実行結果保存部１２０４に保存して、プログラムを終了する。処理プログラムが終了すると、実行指示受付部１２１０は、Ｓ１０６６の応答としてタスク終了通知をバックエンド処理部４０２に対して返す（Ｓ１０６７）。
【０１２４】
バックエンド処理部４０２は、文書変換サービス４１１の結果取得要求受付部１２０５に対して、結果取得要求を行う（Ｓ１０６８）。結果取得要求受付部１２０５は、出力データ保存部１２０３に保存されているデータと実行結果保存部１２０４に保存されている結果ステータスを読みだし、Ｓ１０６８の応答としてバックエンド処理部４０２に返す（Ｓ１０６９）。応答を受けたバックエンド処理部４０２は、文書データをブロブストレージサービス４０５に格納する（Ｓ１０７０）。さらにバックエンド処理部４０２は、ジョブ情報更新において、テーブルストレージサービス４０４のジョブテーブル７００に対してタスクの実行結果を保存する（Ｓ１０７１）。以上で、タスク２の処理が終了する。
【０１２５】
一連のタスク処理が終了したところでバックエンド処理部４０２は、次のタスクを実行するためにキューに対してメッセージの追加と削除を行う。まず、バックエンド処理部４０２は、キューストレージサービス４０３に現在処理したジョブＩＤのメッセージを追加する（Ｓ１０７２）。これにより次に処理すべきタスクの処理依頼が行われたことになる。引き続きバックエンド処理部４０２は、キューストレージサービスより現在処理したメッセージを削除する（Ｓ１０７３）。これにより処理したタスクに対応したメッセージがキューより削除されタイムアウトによる再実行処理が行われなくなる。
【０１２６】
引き続きタスクの実行のシーケンスを説明する。次は、タスク３の処理の流れとなる。ステップＳ１０３０からステップＳ１０３３は、ステップＳ１０１０からステップＳ１０１３と同様の処理である。
【０１２７】
バックエンド処理部４０２は、取得したジョブ情報・サービス情報を基に、ブロブストレージサービス４０５から文書データの取得を行う（Ｓ１０３４）。本発明の実施例１では、ステップＳ１０７０にて保存された文書を取得している。
【０１２８】
バックエンド処理部４０２は、スプールサービス４１２における入力データ受付部１２０８に対して、入力データ格納要求を実行する（Ｓ１０４１）。入力データ格納要求時、バックエンド処理部４０２は、Ｓ１０３４で取得した文書データを引数として渡す。入力データ格納要求を受け取った入力データ受付部１２０８は、引数として渡された文書データを受け取り、入力データ保持部１２０９に格納する。バックエンド処理部４０２は、実行指示受付部１２１９に対しタスク実行指示を出す（Ｓ１０３５）。タスクの実行指示時には、ジョブテーブル７００で管理されているパラメータを引数として実行指示受付部１２１９に渡す。Ｓ１０３５におけるタスク実行指示は、スプールサービス４１２の実行指示受付部１２１２が受け取り、処理実行プログラム１２１３が実行される。処理プログラム１２１３が実行されると、入力データ格納部１２０９に格納されているデータが処理プログラム１２１３により取得される。そして、処理プログラム１２１３によって、画像形成装置１０４で印刷させるために必要な属性（印刷優先度や、色味情報など）が生成・付与される。
【０１２９】
本発明の実施例１では、スプールサービス４１２の処理実行プログラム１２１３は、印刷先のデバイスＩＤとジョブＩＤをパラメータとして受け取り、それらの値に関連づけて印刷データを管理する。また、処理プログラム１２１３は、処理の実行結果（成功／失敗などの実行結果ステータス）を実行結果保存部１２０４に保存して、プログラムを終了する。処理プログラムが終了すると、実行指示受付部１２１２は、Ｓ１０３５の応答としてタスク終了通知をバックエンド処理部４０２に対して返す（Ｓ１０３６）。バックエンド処理部４０２は、スプールサービス４１２の結果取得要求受付部１２１４に対して結果取得要求を行う（Ｓ１０３７）。結果取得要求受付部１２１４は、実行結果保存部１２０４に保存されている結果ステータスを読みだし、Ｓ１０３７の応答として結果ステータスをバックエンド処理部４０２に返す（Ｓ１０３８）。応答を受けたバックエンド処理部４０２は、ジョブ情報更新にてテーブルストレージサービス４０４に保持されているジョブテーブル７００に対して、タスクの実行結果を保存する（Ｓ１０３９）。
【０１３０】
以上で、タスク３の処理が終了する。本発明の実施例１では、印刷データの追加によりジョブが終了するため、一連のタスク処理が終了したところでバックエンド処理部４０２は、キューに対してメッセージの削除を行う。ステップＳ１０４０のメッセージ削除要求にてキューストレージサービスより現在処理したメッセージを削除する。これにより処理したタスクに対応したメッセージがキューより削除され、ジョブが終了する。
【０１３１】
以上が本発明の実施例１における、プリントシステム１０００の処理の流れである。本発明の実施例１により、図１２で示すインターフェースを実装することで、次のような効果がある。即ち、処理プログラム１２０２、１２１１、１２１３夫々のノウハウ・技術を公開せずとも、プラットフォームシステム５００に示すプラットフォームを利用した、画像形成装置１０４と連携するサービスを提供することが可能となる。
【実施例２】
【０１３２】
実施例１では、ジョブテーブル７００に登録されているサービスを単純に実行していた。しかし、サービスアプリケーションは、オープン化された仕様を基に作成されるため、その品質にばらつきがあるものと想定される。サービスが提供装置が提供するサービスが品質を満たさない場合、そのサービスは、プラットフォームシステム５００にリソースを無駄に消費させるだけでなく、画像形成装置１０４を利用するユーザに不快感を与える。なぜなら、複数回失敗するサービスが生成する結果は、ユーザの所望する結果でない可能性が高いからである。そこで一定の品質を満たさないようサービスアプリケーションの場合には、次のような対策をとる。即ち、サービスを実行しても失敗する可能性が高いため、あらかじめ品質の基準を満たさないサービスアプリケーションのタスクは実行せずにジョブ中止させ、プリントシステム１０００全体の品質を高める。これにより、ユーザは、所望するサービスを受け易くなり、プリントシステムの信頼度は高まる。
【０１３３】
本発明の実施例２では、図１３に示すようなサービス品質統計テーブル１３００を用意し、このテーブルの情報に基づいてタスクの実行の可否を行うようにする。
【０１３４】
まず、本発明の実施例２におけるサービス品質統計テーブル１３００について説明する。サービス品質統計テーブル１３００では、サービスが実行された結果の統計情報が管理されている。サービス品質統計テーブル１３００は、テーブルストレージサービス５０６にて保持されている。図１３は、サービス品質統計テーブル１３００を示す図である。
【０１３５】
Ｅｔａｇ１３０１は、ＥＴａｇ７０１と同様である。ＰａｒｔｉｔｉｏｎＫｅｙ１３０２とＲｏｗＫｅｙ１３０３にてテーブルの列を一意に識別するＩＤとなる。サービス品質統計テーブル１３００では、ＰａｒｔｉｔｉｏｎＫｅｙ９０２はサービスの開発元を一意に特定できる開発元ＩＤで、ＲｏｗＫｅｙ１３０３はタスクサービスを一意に特定できるサービスＩＤとして管理される。
【０１３６】
ＥｘｅｃＣｏｕｎｔ１３０４には、そのタスクサービスが何回実行されたかを表す数が格納される。ＥｒｒｏｒＣｏｕｎｔ１３０５には、タスクサービスを実行した際に何回エラーになったかを表す数が格納される。なお、本発明の実施例２においては、あらかじめ集計したデータを管理するようなテーブル構造としたが、毎回の実行結果を格納し、本情報を必要とする際もしくは直前に集計するようにしてもよい。
【０１３７】
本発明の実施例に２において、この統計情報の更新は、図１０のＳ１０２１にてジョブ情報を更新する際に行われる。具体的には、バックエンド処理部からＳ１０２１で更新するジョブ情報の一部としてタスクの実行結果も渡すが、この時テーブルストレージサービス４０４がサービス統計情報テーブルの情報も更新を行う。なお、統計情報を更新するタイミングは、ジョブ情報を更新する他のタイミングであっても良い。例えば、図１０のＳ１０７１や、Ｓ１０３９が挙げられる。また、ジョブ情報の更新については、図７のジョブテーブル７００を用いて説明した通りである。即ち、処理が失敗したタスク、およびジョブのカウントを上げる。
【０１３８】
その他、説明を行わなかったプリントシステム１０００の構成については、実施例１と同じである。
【０１３９】
本発明の実施例２では、シーケンス図１４で処理の流れを説明する。
【０１４０】
まず、図１４のＳ１００１からＳ１０１２までの処理は、図１０のＳ１００１からＳ１０１２までの処理と同じである。
【０１４１】
Ｓ１０１２にて、バックエンド処理部４０２は、ジョブ・サービス情報取得要求をテーブルストレージサービス４０４へ送る。具体的に、バックエンド処理部４０２は、ジョブの情報、タスクサービスの情報に加え、サービス品質統計情報の取得を要求する。具体的には、サービス品質統計テーブル１３００より、タスクサービスのＩＤに対応した統計情報（ＥｘｅｃＣｏｕｎｔ１３０４とＥｒｒｏｒＣｏｕｎｔ１３０５）を取得する。ＥｘｅｃＣｏｕｎｔ１３０４は、タスクの実行回数を、ＥｒｒｏｒＣｏｕｎｔ１３０５は、実行したタスクの失敗回数を示している。ジョブの情報、タスクサービスの情報については、上述した通りである。テーブルストレージサービス４０４は、ジョブの情報、サービスの情報、サービス品質統計情報をＳ１０１２の応答としてバックエンド処理部４０２へ返す（Ｓ１４０１）。Ｓ１４０１でサービス品質統計情報を取得したバックエンド処理部４０２は、取得した品質統計情報がある一定の基準を満たしているかどうかを判定する。
【０１４２】
図１５は、バックエンド処理部４０２がサービス品質統計情報を元に呼び出し対象のサービスが一定品質を満たしているかどうかを判定するロジックのフローチャートである。まずはＳ１５００にて、バックエンド処理部４０２がサービスのタイプを検出し、呼び出し先のサービスがＯＵＴタイプのタスクサービスか否かを判定する。このサービスタイプの検出については、バックエンド処理部４０２が属性取得要求受付部１２０６に対して要求を出し、属性取得要求受付部１２０６が属性情報保持部１２０７に保持されているサービスタイプを読み出して、応答することで実現する。サービスタイプを検出した結果、ＩＮＰＵＴサービスもしくはＰＩＰＥサービスだった場合には、Ｓ１５０１が実行される。
【０１４３】
本発明の実施例２における一定の基準とは、実行した回数のうちどれだけの割合で失敗したかを表す失敗率を基準とする。バックエンド処理部４０２は、Ｓ１４０１でこの失敗率を計算する。具体的には下記の数式を用いて失敗率を計算する。
失敗率＝ＥｒｒｏｒＣｏｕｎｔ（１３０５）÷ＥｘｅｃＣｏｕｎｔ（１３０４）×１００
次に、バックエンド処理部４０２は、バックエンド処理部４０２は失敗率が一定の基準値以内におさまっているのかどうかを判定する（Ｓ１５０２）。たとえば、基準値（閾値）を２割とすると、失敗率が２割未満であれば基準を満たすとみなし（Ｓ１５０３）、２割以上であれば満たさないとみなす（Ｓ１５０４）。
【０１４４】
一方、Ｓ１５００で呼び出し先サービスのタイプがＯＵＴタイプのタスクサービスだと判定された場合には、Ｓ１５０５が実行される。Ｓ１５０５では、バックエンド処理部４０２が呼び出し先サービスの開発元を検出する。このサービス開発元の検出については、バックエンド処理部４０２が属性取得要求受付部１２０６に対して要求を出し、属性取得要求受付部１２０６が属性情報保持部１２０７に保持されている開発元ＩＤを読み出して、応答することで実現する。検出した開発元ＩＤを元に、Ｓ１５０６にて、バックエンド処理部４０２が信頼性の高いベンダーかどうかの判定を行う。本判定処理は、まず図１３のサービス品質統計テーブルから開発元ＩＤを元に、その開発元が開発した全サービスのＥｒｒｏｒＣｏｕｎｔ（１３０５）の総計＝総実行回数と、ＥｘｅｃＣｏｕｎｔ（１３０４）の総計＝総失敗回数を算出する。さらに次の式に当てはめることで総失敗率を計算する。
総失敗率＝総失敗回数÷総実行回数×１００
Ｓ１５０６にて、バックエンド処理部４０２は上記により算出した総失敗率が一定の基準値以内におさまっているのかどうかを判定することで信頼性の高いベンダーかどうかを判定する。たとえば、基準値を２割とすると、失敗率が２割未満であれば基準を満たすとみなし（Ｓ１５０８）、２割以上であれば満たさないとみなす。基準を満たさないと判定された場合、バックエンド処理部４０２はＳ１５０７にてそのサービスがＶｅｒｉｆｉｃａｔｉｏｎ済みかどうかを判定する。ここでＶｅｒｉｆｉｃａｔｉｏｎ済みの場合には、一定品質を満たしているとみなし（Ｓ１５０８）、Ｖｅｒｉｆｉｃａｔｉｏｎ済みでない場合には一定品質を満たしていないとみなす（Ｓ１５０９）。
【０１４５】
基準を満たす場合には、シーケンス図１０で示す、Ｓ１０１４からＳ１０１９の処理が実行されるが、基準を見たさない場合には、シーケンス図１４のステップＳ１４０２としてジョブ情報の更新が実行される。バックエンド処理部４０２は、Ｓ１４０２でジョブ情報更新を行い、ジョブテーブルのステータス７０６をＦａｉｌｕｒｅ（失敗）に変更することでそのジョブが失敗した事をわかるようにする。即ち、そのジョブは失敗状態とみなされる。バックエンド処理部４０２はステップＳ１４０３のメッセージ削除要求にてキューストレージサービスより現在処理したメッセージを削除する。これにより、以後、本ジョブに対する処理が行われなくなる。以上が、一定品質を満たさないサービスの実行を回避するための流れになる。
【０１４６】
次に、プラットフォームアプリケーション４０８が印刷データを取得する処理について図１４を用いて説明する。まず、図１４のステップＳ１０５０からステップＳ１０５３までは、図１０のステップＳ１０５０からステップＳ１０５３までと同じ処理である。
【０１４７】
次に、要求受信部４０１は、Ｓ１０５３で取得したジョブのステータス７０６から処理が失敗していることが判断できる。このため、要求受信部４０１は、Ｓ１４０４でプラットフォームアプリケーション４０８に対してエラー通知の応答を行う（エラー送信）。エラー通知を受けたプラットフォームアプリケーション４０８は、処理を中断する。本発明の実施例２により、ある一定の品質を保てないサービスの実行を中断させることが可能になるため、システムの資源を効果的に利用することができる。
【０１４８】
〔変化形〕
本発明の各実施例では、図１２に示されるように、ＩＮ／ＰＩＰＥ／ＯＵＴのサービスごとにそれぞれ固有の役割を担う要求受付部を有していた。しかし、複数の要求受付部を統合するような形体でも構わない。例えば、図１６の（ａ）は、実行指示受付部１２０１と結果取得要求受付部１２０５の役割を、要求処理部１６０２へ、一つにまとめたものである。この場合、バックエンド処理部４０２でＳ１０１４のタスク実行指示が行われた結果、要求受付部１６０１が実行指示を受け取り、実行指示部１２０１の処理を実行し、続いて結果取得要求受付部１２０５の処理を行う。バックエンド処理部４０２は、Ｓ１０１４の応答としてＳ１０１９に相当する応答を受けることとなり、Ｓ１０１７およびＳ１０１８に相当する処理は実行されない。
【０１４９】
同様に図１６の（ｂ）は、入力データ受付部１２０８、実行指示受付部１２１０、結果取得要求受付部１２１４の役割を、要求処理部１６０２へ、一つにまとめたものである。この場合、バックエンド処理部４０２がＳ１０６５の処理を行うと、要求処理部１６０２は、入力データ受付部１２０８、実行指示受付部１２１０、結果取得要求受付部１２１４それぞれの処理を順次実行する。バックエンド処理部４０２は、Ｓ１０６５の応答としてＳ１０６９に相当する応答をうけ、Ｓ１０６６からＳ１０６８に相当する処理は実行されない。
【０１５０】
同様に図１６の（ｃ）は、入力データ受付部１２１７、実行指示受付部１２１９、結果取得要求受付部１２２２の役割を要求処理部１６０３一つにまとめたものである。この場合、バックエンド処理部４０２がＳ１０４１の処理を行うと、要求処理部１６０３は入力データ受付部１２１７、実行指示受付部１２１９、結果取得要求受付部１２２２それぞれの処理を順次実行する。バックエンド処理部４０２は、Ｓ１０４１の応答としてＳ１０３８に相当する応答をうけ、Ｓ１０３５からＳ１０３７に相当する処理は実行されない。
【０１５１】
上述の通り、図１２で示したＰＩＰＥ／ＯＵＴの要求処理部３つを図１６では１つにまとめたが、３つを２つにまとめる形にしても良い。即ち、次の要件を満たしていれば良い。その要件の一つ目が、プラットフォームシステム５００からＷｅｂｓｅｒｖｉｃｅに対してデータを送ることができる。二つ目が、プラットフォームシステム５００がＷｅｂｓｅｒｖｉｃｅからデータを取得することができるということである。本発明の各実施例のインターフェースを実装することで、これら２つの要件を満たしつつ、プラットフォームシステム５００側からは、Ｗｅｂｓｅｒｖｉｃｅに対して直接アクセスはできない。結果、サービスアプリケーション開発者側から見れば、自社のノウハウ・技術を公開せずに、プラットフォームシステム５００を利用することが可能である。
【０１５２】
また、プラットフォームシステム５００の提供者側から見れば、インターフェースを実装したサービスアプリケーションでなくては、プラットフォームシステム５００を利用できなくなるため、プラットフォームシステム５００の品質を一定に保つことが可能である。
【０１５３】
また、本発明の各実施例において、１つのインスタンス（ヴァーチャルマシン）は、１台のサーバーコンピュータ上で動作するものとした。しかし、これに限るものではない。例えば、サーバーコンピュータがマルチコアＣＰＵを搭載するのであれば、１コアに対し１つのインスタンスが実現される方法が考えられる。また、マルチスレッド対応のサーバーコンピュータであれば、１ＣＰＵが少なくとも１台以上（例えば、２台、３台等）のヴァーチャルマシンを実現することも可能である。このように、１つのインスタンスを実現するための方法に限定はなく、適宜変更可能なものである。
【０１５４】
また、本発明の各実施例における文書変換サービス４１１は、コンテンツをＰＤＦへの変換処理を行った。しかし、文書変換サービス４１１はコンテンツを別の形式へ変換しても良い。例えば、コンテンツを次に記載する複数の形式の内、少なくとも何れか１つの形式へ変換する機能を持たせることが可能である。その形式とは、ＰＳ（Ｐｏｓｔ  Ｓｃｒｉｐｔ）、ＰＣＬ（Ｐｒｉｎｔｅｒ  Ｃｏｎｔｒｏｌ  Ｌａｎｇｕａｇｅ）、ＸＰＳ（ＸＭＬ  Ｐａｐｅｒ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）を始めとするＰＤＬ（Ｐａｇｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）である。このように、文書変換サービス４１１は、変換する形式に関して特に限定はなく、適宜変更可能なものである。
【０１５５】
また、本発明の各実施例におけるタスクは、タスク１、タスク２、タスク３の３つであった。しかし、タスクの数はこれに限定されない。この際、ＰＩＰＥに属するタスクを増やすことによって、タスクサービス増やすことが可能となる。
【０１５６】
また、本発明の各実施例におけるタスクサービスは、３つのサービスタイプに分けられた。これは、本発明を実施する上で最良の形態であることから、このような限定を行った。理由として、サービスアプリケーションの開発者にとって、処理プログラムの流用性を高めることができるからである。即ち、別のサービスアプリケーションを開発する時に、処理プログラムを流用可能である。しかし、この効果を望まないのであれば、これに限定される必要はない。即ち、ＩＮ，およびＯＵＴに属するタスクを１ジョブに対し１つずつにする必要はなく、夫々複数存在しても良い。無論、どちらか一方のみ複数であっても良い。また、３つのサービスタイプは１つのサービスタイプに限定し、ＩＮ、ＰＩＰＥ、ＯＵＴを一まとめにしても良い。また、ＩＮ（入力）、ＰＩＰＥ（処理）、ＯＵＴ（出力）の３つのサービスタイプに分類したが、よりサービスタイプの粒度を細かくして４つ以上のサービスタイプに分けても構わない。
【０１５７】
また、本発明の各実施例では、サービスがＷｅｂＳｅｒｖｉｃｅで提供されており、提供されているアドレスをＵＲＩという形で管理されていた。しかし、サービスの提供方法はその他の方法でもよい。例えば、ＷｅｂＳｅｒｖｉｃｅではなく、ＲＥＳＴのＩ／Ｆでサービスが提供されても良いし、ＤＬＬのようなモジュールで提供されても良い。例えば、文書取り出しサービス４１０がＤＬＬとして提供されるのであれば、バックエンド処理部４０２に実行させれば良い。このＤＬＬを実行したバックエンド処理部４０２は、文書取り出しサービス４１０のように機能する。例えば、ＩＮタイプのＤＬＬを実行したバックエンド処理部４０２は、文書リポジトリが文書ファイルを取得する。これにより、タスクサービスの開発者は、タスクサービスを提供するためのサービス提供装置を構築する必要がなくなる。但し、この場合は、ある程度の自社のノウハウ・技術をプラットフォームシステム５００の提供者側に公開することにはなる。なお、ＵＲＩ等のアドレスは、プラットフォームシステム５００内のアドレスとなる。
【符号の説明】
【０１５８】
１０２  サーバーコンピュータ群
１０３  文書サーバー
１０４  画像形成装置
１０５  クライアントコンピュータ
１０７  文書取り出しサーバー
１０８  文書変換サーバー
１０９  印刷サーバー
１２０１  実行指示受付部
１２０２  処理プログラム
１２０３  出力データ保存部
１２０４  実行結果保存部
１２０５  結果取得要求受付部
１２０６  属性取得要求受付部
１２０７  属性情報保持部
【図１】
2011192250.tif 000003
【図２】
2011192250.tif 000004
【図３】
2011192250.tif 000005
【図４】
2011192250.tif 000006
【図５】
2011192250.tif 000007
【図６】
2011192250.tif 000008
【図７】
2011192250.tif 000009
【図８】
2011192250.tif 000010
【図９】
2011192250.tif 000011
【図１０】
2011192250.tif 000012
【図１１】
2011192250.tif 000013
【図１２】
2011192250.tif 000014
【図１３】
2011192250.tif 000015
【図１４】
2011192250.tif 000016
【図１５】
2011192250.tif 000017
【図１６】
2011192250.tif 000018