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