JP6340786B2 - 情報処理システム、情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Description

本発明は情報処理の制御技術に関する。

Ｗｅｂ上で各種のサービス（Ｗｅｂサービス）を提供する手段として、ＳＯＡＰ（Simple Object Access Protocol）、ＲＥＳＴ（Representational State Transfer）と呼ばれる方式のＷｅｂＡＰＩ（Web Application Program Interface）が多く使われている。ＷｅｂＡＰＩのベースとなっているのはＨＴＴＰプロトコル（HyperText Transfer Protocol）での通信であり、サービス提供側はＨＴＴＰサーバとなってＷｅｂＡＰＩを提供し、サービス利用側はＨＴＴＰクライアントとなってそのＷｅｂＡＰＩを利用する。

一方、情報処理システムまたは情報処理装置の一例として、ＬＰ（Laser Printer）、ＭＦＰ（Multi Function Peripheral、Multi Function Printer）等の画像形成装置が挙げられる。この種の画像形成装置では、画面表示やキー入力の操作を行う部分を操作部として本体部（コントローラ、エンジン）から独立させ、本体部の負荷が高くても操作レスポンスを低下させないようにすることが考えられている。操作部にはAndroid（登録商標） OS等の独立したＯＳ（Operating System）が搭載され、本体部とは独立に動作する。

このような操作部を備えた画像形成装置内においても、前述したＲＥＳＴ方式のＷｅｂＡＰＩが用いられることが考えられ、操作部上のアプリ（アプリケーションプログラム）は、本体部が提供するＷｅｂＡＰＩを利用して機能を実現することになる。

クライアントからのリクエストに対して、サーバがレスポンスを返す、というのが一般的なＨＴＴＰ通信の基本である。そのため、ＨＴＴＰ通信では、サーバ側で任意のタイミングで発生した状態変化（イベント）をクライアント側に通知することが原理的にできないアーキテクチャとなっている。

従って、例えば、ＷｅｂＡＰＩで提供されるプリンタ印刷機能を利用するとき、クライアントがそのプリンタジョブ状態を知るためには、クライアントが定期的にジョブ状態取得ＡＰＩを呼び続けるなどする必要がある。

しかし、クライアントがジョブ状態変化の有無によらずジョブ状態取得をし続けるのは非常に非効率的である。そこで、ジョブ状態に変化があったときだけサーバからクライアントに対してジョブ状態を通知するといったイベント通知を実現するための仕組みが考えられる。

上述したような、ジョブ状態に変化があったときだけサーバからクライアントに対してジョブ状態を通知する仕組の場合、先にジョブ状態通知リクエストを送信し、その後にジョブ実行リクエストを送信することになる。

そのため、サーバはジョブ状態通知リクエストを受け付けたタイミングでは、その後にクライアントが要求するジョブ（例えば、ジョブを識別する情報）を特定できない。その結果、サーバは別のクライアントが実行したジョブの状態変化、すなわち、ジョブ状態通知リクエストをしたクライアントが望んでない状態変化まで通知してしまうという問題があった。

図１はジョブ状態通知リクエストに基づくジョブ状態通知の例を示す図であり、独立した操作部から本体部のＷｅｂサービスを利用する場合を示している。

図１において、操作部の操作部アプリＡから本体部のＷｅｂサービス提供モジュール群にジョブ状態通知リクエストを送信し（ステップＳ１）、続いて、ジョブＡについてのジョブ実行リクエストを送信する（ステップＳ２）。これにより、本体部のＷｅｂサービス提供モジュール群は、ジョブＡに状態変化があると操作部アプリＡにジョブＡの状態変化通知のレスポンスを送信する（ステップＳ３）。

一方、このタイミングで操作部アプリＢから本体部のＷｅｂサービス提供モジュール群にジョブＢについてのジョブ実行リクエストを送信し（ステップＳ４）、その後、ジョブＢに状態変化があると、本体部は操作部アプリＡにジョブＢの状態変化通知のレスポンスを送信してしまう（ステップＳ５）。なお、操作部アプリＢは状態通知リクエストを行っていないため、操作部アプリＢには状態変化通知のレスポンスは送信されない。

すなわち、ジョブ状態通知リクエストとジョブ実行リクエストはそれぞれ独立しており、サーバとなる本体部はそれぞれのクライアントを識別できないため、どのクライアントが実行リクエストしたジョブであるかによらず、ジョブ状態通知リクエストを行ったクライアントにあらゆるジョブの状態変化を通知してしまうことになる。

一方、特許文献１には、クライアントからのジョブ実行リクエストを受信した第一のサーバが第二のサーバにリクエストを委譲したジョブについて、クライアントがジョブキャンセルやジョブ状態取得などジョブ管理できるようにすることを目的とした技術が開示されている。すなわち、第二のサーバがクライアントに対して実行中ジョブを識別するＩＤをクライアントに送信し、クライアントはそのＩＤを指定して第二のサーバが実行するジョブを管理する。

しかし、ジョブ状態通知リクエスト時にクライアントが所望するジョブを識別するＩＤを指定できないような状況は考慮されておらず、上記の問題を解決することはできない。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ジョブ状態通知リクエストしたのと同一のクライアントが実行リクエストしたジョブの状態変化を通知することにある。

上記の課題を解決するため、本発明にあっては、第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムであって、前記第１の情報処理装置は、前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を発行する手段と、ジョブ状態通知のリクエストおよびジョブ実行のリクエストに前記識別情報の指定を付加して前記第２の情報処理装置に送信する手段であって、発行した前記識別情報を伴う、複数の前記クライアントに共通のジョブ状態通知のリクエストを前記第２の情報処理装置に送信する手段と、前記第２の情報処理装置から受信したジョブ状態通知のレスポンスを前記識別情報に基づいて要求元に振り分ける手段とを備え、前記第２の情報処理装置は、ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントにジョブ状態通知のレスポンスを送信する手段を備えるようにしている。

本発明にあっては、ジョブ状態通知リクエストしたのと同一のクライアントが実行リクエストしたジョブの状態変化を通知することができる。

ジョブ状態通知リクエストに基づくジョブ状態通知の例を示す図である。 本発明の一実施形態にかかる画像形成装置のハードウェア構成例を示す図である。 ネットワーク構成例を示す図である。 画像形成装置のソフトウェア構成例を示す図である。 ＷｅｂＡＰＩの例を示す図である。 ＷｅｂＡＰＩによる印刷処理の例を示すシーケンス図である。 ＷｅｂＡＰＩによる状態通知の処理例を示すモジュール間コラボレーション図である。 ＷｅｂＡＰＩを利用するクライアントがジョブ実行・ジョブ状態通知をリクエストする処理例を示すシーケンス図である。 「/subscription/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。 「/printer/events/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。 「/printer/job/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。 ジョブ状態の例を示す図である。 実行中ジョブの状態が変化したときのサーバ側の処理例を示すフローチャートである。 ジョブ状態変化データの例を示す図である。 ＨＴＴＰ通信の例を示す図である。 ＨＴＴＰデータの構造を示す図である。 分割したレスポンスとＨＴＴＰデータの関係の例を示す図である。 データ書式の例を示す図である。 ＷｅｂＡＰＩによる状態通知の処理例を示すモジュール間コラボレーション図である。 「/printer/events/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。 実行中ジョブの状態が変化したときのサーバ側の処理例を示すフローチャートである。

以下、本発明の好適な実施形態につき説明する。なお、情報処理システムまたは情報処理装置として画像形成装置を例に説明するが、画像形成装置以外の情報処理システムまたは情報処理装置にも適用できることは言うまでもない。

＜構成＞
図２は本発明の一実施形態にかかる画像形成装置１のハードウェア構成例を示す図である。

図２において、画像形成装置１は、本体部（コントローラ、エンジン）２と操作部３とを備えている。操作部３は本体部２に有線路または無線路により接続される。

本体部２は、その時設定されている制御モードおよびホストコンピュータ４等からの制御コードに従って、ホストコンピュータ４からの印字データをビデオデータに変換し、プリンタエンジン２１２へ出力する機能を有している。また、本体部２は、スキャナエンジン２１３により原稿画像を読み込み、プリンタエンジン２１２に出力することでコピーを行ない、あるいは、読取画像をホストコンピュータ４等に出力する機能を有している。

操作部３は、タッチパネルを備え、独自のＯＳを搭載したコンピュータ装置である。

本体部２は、ＣＰＵ２０１とＲＡＭ２０２とＮＶ−ＲＡＭ２０３とプログラムＲＯＭ２０４とフォントＲＯＭ２０５とネットワークインタフェース２０６と操作部インタフェース２０７とプリンタエンジンインタフェース２０８とスキャナエンジンインタフェース２０９とＨＤＤ２１０とオプションＲＡＭ２１１とプリンタエンジン２１２とスキャナエンジン２１３とを備えている。

ＣＰＵ２０１は、ホストコンピュータ４等からのデータ（印字データ、制御データ）を処理する。

ＲＡＭ２０２は、ＣＰＵ２０１が処理する時のワークメモリ、ホストコンピュータ４等からのデータをページ単位に管理して一時記憶するバッファ、バッファに記憶されたデータを実際の印字パターンに変換しビデオデータを記憶するビットマップメモリ等に使われる。

ＮＶ−ＲＡＭ２０３は、電源を切っても保持したいデータを格納しておくための不揮発性ＲＡＭである。

プログラムＲＯＭ２０４は、本体部２内でのデータの管理や、周辺モジュールを制御するためのプログラムが格納されている。

フォントＲＯＭ２０５は、印字に使用されるさまざまな種類のフォントデータが格納されている。

ネットワークインタフェース２０６は、ホストコンピュータ４から画像形成装置１への制御信号やデータ、画像形成装置１からホストコンピュータ４へのステータス信号やデータインターフェースである。

操作部インタフェース２０７は、操作部３との間での制御信号やデータのインタフェースである。

プリンタエンジンインタフェース２０８は、プリンタエンジン２１２への制御信号やデータ、プリンタエンジン２１２からのステータス信号のインタフェースである。

スキャナエンジンインタフェース２０９は、スキャナエンジン２１３への制御信号、スキャナエンジン２１３からのステータス信号やデータのインタフェースである。

ＨＤＤ２１０は、大容量の記憶装置である。

オプションＲＡＭ２１１は、追加的に装着されるＲＡＭである。

プリンタエンジン２１２は、プリンタエンジンインタフェース２０８を介して与えられるビデオ信号および制御信号により感光体上に静電潜像を作り、現像し、また給紙部より転写紙を給紙し、転写および定着し、画像を形成する。

スキャナエンジン２１３は、原稿を光学的に読み取り、画像情報を出力する。

図３はネットワーク構成例を示す図である。

図３において、ネットワーク上には、複数のホストコンピュータ４Ａ、４Ｂ、４Ｃと画像形成装置１が接続されている。

画像形成装置１は、本体部２と操作部３とを備えている。操作部３は、本体部２との間で有線または無線で直接に接続されるほか、ネットワーク上のアクセスポイント（図示せず）を介して本体部２に接続することもできる。操作部３上のアプリは本体部２が提供するＷｅｂＡＰＩを使ってアプリの機能を実現する。

ホストコンピュータ４Ａ、４Ｂ、４Ｃは、画像形成装置１に対して印刷を要求したり、原稿の読取画像の送信を受けたりすることができるとともに、画像形成装置１（本体部２）の提供するＷｅｂＡＰＩを使ってＷｅｂサービスを利用することができる。

図４は画像形成装置１のソフトウェア構成例を示す図である。なお、操作部３上のアプリが本体部２の提供するＷｅｂサービスを利用するクライアントとなる場合を例として説明するが、操作部３上のアプリに限定されるものではなく、ホストコンピュータ４上のアプリ（ＰＣアプリ、サーバアプリ）等がクライアントとなってもよい。

図４において、本体部２は、サービス提供モジュール群２３０を構成するネットワーク管理モジュール２２５とＷｅｂサービス提供モジュール２２６と印刷管理モジュール２２７とシステム管理モジュール２２８とメモリ管理モジュール２２９とを備えている。また、本体部２は、サービス提供モジュール群２３０の各モジュールの機能を利用するプリンタジョブ管理モジュール２２２とコピージョブ管理モジュール２２３とスキャナジョブ管理モジュール２２４とを備えている。また、本体部２は、プリンタジョブ管理モジュール２２２が利用するＰＤＬ解析モジュール２２１を備えている。

操作部３は、操作部アプリ３０１〜３０３を備えている。操作部アプリ３０１〜３０３は、操作部３上で動作するアプリであり、ＪＡＶＡ（登録商標）やＡｎｄｒｏｉｄ（登録商標）ＳＤＫや本体部２が独自に提供するＡＰＩを利用して、様々な機能をもつアプリを開発することが可能である。なお、操作部アプリの数は図示のものに限定されるものではなく、１つでもよいし、４以上でもよい。ここでは、操作部アプリ３０１〜３０３は、Ｗｅｂサービスのクライアントとして動作するものとしている。

本体部２のＰＤＬ解析モジュール２２１は、画像形成装置１がホストコンピュータ４等から受信したＰＤＬデータを解析して印刷画像を生成するモジュールである。プリンタジョブ管理モジュール２２２よりＰＤＬデータを受け取り、プリンタジョブ管理モジュール２２２の仲介によりメモリ管理モジュール２２９から確保したメモリ上に印刷画像を生成することが主な責務である。また、印刷画像生成の際には機器構成情報、例えば、給紙トレイ・排紙トレイの構成や、給紙トレイ内の用紙サイズといった情報が必要になるが、これらの情報はプリンタジョブ管理モジュール２２２の仲介によりシステム管理モジュール２２８から得る。

プリンタジョブ管理モジュール２２２は、ＰＤＬ処理全般に関わる制御を行っており、主にＰＤＬ解析モジュール２２１側が必要とする処理を仲介して他モジュールに対して要求を行うモジュールである。ネットワーク管理モジュール２２５が受け取ったＰＤＬデータをＰＤＬ解析モジュール２２１へ受け渡す仲介、ＰＤＬ解析モジュール２２１に対しシステム管理モジュール２２８が管理する機器情報を取得する仲介、ＰＤＬ解析モジュール２２１がメモリ管理モジュール２２９から必要なメモリを確保する仲介、ＰＤＬ解析モジュール２２１が作成した印刷画像に関し印刷管理モジュール２２７に対する印刷要求の発行、といったことを行う。

コピージョブ管理モジュール２２３は、コピー処理全般に関する制御を行っており、サービス提供モジュール群２３０を利用してコピー機能を実現するのが主な責務である。

スキャナジョブ管理モジュール２２４は、スキャン処理全般に関する制御を行っており、サービス提供モジュール群２３０を利用してスキャナ機能を実現するのが主な責務である。

ネットワーク管理モジュール２２５は、ネットワークコントローラ（図示せず）の管理と、ネットワークコントローラから得られる受信データの処理を制御するモジュールである。ホストコンピュータ４からのデータ受信の際に欠かせない通信プロトコル（ｆｔｐやｌｐｒなど）を制御してネットワークコントローラからデータを受信し、他モジュールへ受信データを受け渡すことが主な責務である。Ｗｅｂサービス提供においては、クライアントからのＨＴＴＰ（ＲＥＳＴ）アクセスによるデータを受信し、Ｗｅｂサービス提供モジュール２２６に受け渡す。

Ｗｅｂサービス提供モジュール２２６は、ＲＥＳＴ／ＳＯＡＰ用のＨＴＴＰサーバとして動作し、クライアントに対してＷｅｂサービスを提供するモジュールである。様々な機能をＷｅｂサービスとして提供するために、画像形成装置１内の他のモジュールと連携する。例えば、プリンタ印刷機能を提供するためにはプリンタジョブ管理モジュール２２２と連携する。また、コピージョブ管理モジュール２２３、スキャナジョブ管理モジュール２２４と連携し、コピー機能、スキャナ機能をＷｅｂサービスとして提供する。なお、図には記載していないが、ファックス機能を実現するモジュールと連携してファックス機能をＷｅｂサービスとして提供することもできる。Ｗｅｂサービス提供モジュール２２６は、ＨＴＴＰクライアントからのリクエスト受信、クライアントへのレスポンス送信、サーバ・クライアント間で受け渡しするメッセージに含まれるＪＳＯＮ（JavaScript Object Notation）データのシリアライズ・デシリアライズなどが主な責務である。

印刷管理モジュール２２７は、ＰＤＬ解析モジュール２２１が生成した印刷画像の印刷処理に関する制御を行うモジュールである。メモリ管理モジュール２２９が管理するメモリ／外部記憶装置内に格納された印刷画像を、プリンタエンジンに印刷させるために必要な各種処理を実行するのが主な責務であり、給排紙命令の発行、後処理実行命令の発行、印刷に関わるエラー状態の検知と他モジュールへの通知などを行う。

システム管理モジュール２２８は、画像形成装置１の機器構成情報や機器状態を管理・制御するモジュールである。機器構成情報とは、給紙トレイや排紙トレイの着脱の情報や給紙トレイ内の用紙構成といった情報であり、機器状態とは、印刷中・待機中、ジャムや用紙切れなどのエラー発生中といった内容である。こうした情報を他モジュールへ通知する他、ユーザによる機器設定（設定により動作を変化させるカスタマイズ可能項目等）の管理が主な責務である。

メモリ管理モジュール２２９は、メモリおよび外部記憶装置を管理するモジュールであり、他モジュールの要求に基いてメモリおよび外部記憶装置の割り当て・解放を行うことが主な責務である。

サービス提供モジュール群２３０は、各種サービスを提供するモジュールの総称である。サービス提供モジュール群２３０の各モジュールは互いに通信をし合って画像形成装置１の基本動作を分担し、協力して上位層からの要求に対応する。

＜ＷｅｂＡＰＩの例＞
画像形成装置１の本体部２は様々なＷｅｂサービスをＷｅｂＡＰＩにより提供している。例えば、コピー、プリンタ、スキャナなどのジョブを実行するＡＰＩや、それぞれのジョブの状態をクライアントに通知するＡＰＩがある。

図５は画像形成装置１の本体部２が提供するＷｅｂＡＰＩの例を示している。図示のＵＲＩ（Uniform Resource Identifier）とメソッドを用い、必要に応じてパラメータを指定することで、所定の処理のリクエストを行うことができる。

これらのＷｅｂＡＰＩを利用するクライアントは、ネットワーク接続されたホストコンピュータ４上のアプリケーションや操作部３上で動作する操作部アプリ３０１〜３０３など様々である。

＜印刷処理の動作例＞
図６はＷｅｂＡＰＩによる印刷処理の例を示すシーケンス図である。

図６において、ＨＴＴＰクライアントとなるホストコンピュータ４が印刷実行のＨＴＴＰリクエストを画像形成装置１に送信すると、本体部２のネットワーク管理モジュール２２５が受信する（ステップＳ１０１）。印刷実行のＨＴＴＰリクエストは、例えば、前述した"/printer/job/"というＵＲＩを指定して送信する。

ネットワーク管理モジュール２２５はＨＴＴＰリクエストを受け取ると、Ｗｅｂサービス提供モジュール２２６に印刷実行のリクエストを通知する（ステップＳ１０２）。

Ｗｅｂサービス提供モジュール２２６はリクエストに対応するモジュールに処理実行を通知する。この例では、プリンタジョブ管理モジュール２２２に印刷実行のリクエストを通知する（ステップＳ１０３）。より詳しくは、起動時のタイミング等においてＵＲＩとそれに対応するイベントハンドラを登録しておくことで、Ｗｅｂサービス提供モジュール２２６は委譲先となるモジュールを判断し、そのモジュールに通知を行う。

プリンタジョブ管理モジュール２２２は、印刷実行のリクエストに含まれるヘッダおよびボディを解析し（ステップＳ１０４）、ＰＤＬ解析モジュール２２１に画像生成を要求する（ステップＳ１０５）。

ＰＤＬ解析モジュール２２１から画像生成の終了のレスポンスがあると（ステップＳ１０６）、プリンタジョブ管理モジュール２２２は印刷管理モジュール２２７に印刷処理実行を指示する（ステップＳ１０７）。

印刷管理モジュール２２７から印刷処理の終了のレスポンスがあると（ステップＳ１０８）、プリンタジョブ管理モジュール２２２はＷｅｂサービス提供モジュール２２６にレスポンスとして結果を通知する（ステップＳ１０９）。

Ｗｅｂサービス提供モジュール２２６も同様にネットワーク管理モジュール２２５にレスポンスを通知し（ステップＳ１１０）、最終的にＨＴＴＰクライアントのホストコンピュータ４にＨＴＴＰレスポンスが通知される（ステップＳ１１１）。

ここでは、例としてプリンタでの印刷実行処理を示したが、その他の機能についてもＷｅｂサービス提供モジュール２２６が対応するモジュールに処理実行を通知することで実現される。

＜状態通知の動作例＃１＞
図７はＷｅｂＡＰＩによる状態通知の処理例を示すモジュール間コラボレーション図である。

図７において、操作部３の操作部アプリ３０１は、ＨＴＴＰクライアントとして、サーバとしての本体部２に対し、自身をサーバに識別させるためのクライアント識別ＩＤ（Subscribed_ID）の発行をリクエスト（クライアント識別ＩＤ発行リクエスト）する（ステップＳ１１）。本体部２のＷｅｂサービス提供モジュール２２６はネットワーク管理モジュール２２５を介してクライアント識別ＩＤ発行リクエストを受信すると、クライアント識別ＩＤを発行し、ネットワーク管理モジュール２２５を介して操作部３の操作部アプリ３０１にクライアント識別ＩＤをレスポンスする（ステップＳ１２）。

その後、操作部３の操作部アプリ３０１がジョブ状態通知リクエスト（ジョブ状態の通知をサーバに要求するメッセージ）を行う際（ステップＳ１３）、および、所定のジョブ（例えばジョブＡ）についてのジョブ実行リクエスト（ジョブの実行をサーバに要求するメッセージ）を行う際（ステップＳ１４）には、サーバから発行されたクライアント識別ＩＤを指定するようにする。

本体部２のＷｅｂサービス提供モジュール２２６は、ジョブ状態通知リクエストで指定されたクライアント識別ＩＤとジョブ実行リクエストで指定されたクライアント識別ＩＤが一致する場合のみ、ジョブ状態通知クライアントに状態変化を通知する。一致しない場合は、そのジョブの状態変化を通知しない。

ここでは、操作部アプリ３０１からのジョブ状態通知リクエスト（ステップＳ１３）で指定されたクライアント識別ＩＤと、同じく操作部アプリ３０１からのジョブ実行リクエスト（ステップＳ１４）で指定されたクライアント識別ＩＤが一致するものとすると、操作部アプリ３０１に状態変化を通知する（ステップＳ１５）。

一方、操作部アプリ３０２は、クライアント識別ＩＤを取得せず、また、ジョブ状態通知リクエストを行わずに、クライアント識別ＩＤを指定することなくジョブＢのジョブ実行リクエストを行ったとすると（ステップＳ１６）、操作部アプリ３０２に対しては状態変化の通知は行われない。また、操作部アプリ３０２がジョブ実行リクエストしたジョブＢの状態変化は、クライアント識別ＩＤにより紐付けられていないため、操作部アプリ３０１には通知されない。

このように、クライアント識別ＩＤによりサーバはジョブ状態通知リクエストとジョブ実行リクエストの要求元のクライアントを紐付けすることができるようになるので、ジョブ状態通知リクエストを行ったクライアントに対して、他のクライアントがジョブ実行リクエストを行ったジョブの状態変化を通知しないようにすることができる。

以下、各部の詳細な処理について説明する。なお、以下の説明では、プリンタ印刷を実行し、実行中プリンタジョブ一覧を表示する操作部３の操作部アプリ３０１をクライアントの例として説明する。

また、全てのリクエストはネットワーク管理モジュール２２５を介してＷｅｂサービス提供モジュール２２６に伝えられ、またクライアントへのレスポンスはＷｅｂサービス提供モジュール２２６からネットワーク管理モジュール２２５を介してクライアントに送信される。ネットワーク管理モジュール２２５はリクエスト／レスポンスを仲介するだけの役割であるため、ネットワーク管理モジュール２２５を省略する。つまり、クライアントからのリクエスト受信、クライアントへのレスポンス送信は、Ｗｅｂサービス提供モジュール２２６が行うものとして説明する。

図８はＷｅｂＡＰＩを利用するクライアントがジョブ実行・ジョブ状態通知をリクエストする処理例を示すシーケンス図である。各リクエスト受信時のサーバ側の処理内容については順を追って説明する。

図８において、クライアントとしての操作部アプリ３０１は、まずジョブ状態通知の要求元を識別させるためのクライアント識別ＩＤを発行すべく「/subscription/リクエスト」をサーバとしての本体部２に送信する（ステップＳ１２０）。クライアントがＨＴＴＰリクエストするＵＲＩは例えば"http://（画像形成装置のＩＰアドレス）/subscription"のような形式となる。

図９は「/subscription/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。

図９において、Ｗｅｂサービス提供モジュール２２６は「/subscription/リクエスト」を受け付けると、他とは重複しないユニークなクライアント識別ＩＤ（Subscribed_ID）を発行し（ステップＳ１２１）、クライアント識別ＩＤを含めたレスポンスデータを生成し（ステップＳ１２２）、レスポンスをクライアントに送信する（ステップＳ１２３）。

クライアント識別ＩＤの採番方法は、１から順にインクリメントしていくなど、クライアント識別ＩＤが他と重複しない方法であればよい。また、クライアント識別ＩＤはアルファベットを含む文字列としてもよい。更に、「/subscription/リクエスト」は発行したクライアント識別ＩＤがユニークであることをサーバ側で保証するためだけのＡＰＩなので、クライアント同士で採番ルールを作るなど、クライアントが他とは重複しないユニークなクライアント識別ＩＤを保証できるのであれば、「/subscription/リクエスト」は不要としてもよい。

図８に戻り、クライアントとしての操作部アプリ３０１は、ジョブ実行を要求する前に「/printer/events/リクエスト」をサーバとしての本体部２に送信し（ステップＳ１３０）、ジョブの状態通知イベントを受信する準備をする。

「/printer/events/リクエスト」ではその要求元を識別するためにクライアント識別ＩＤをクエリパラメータとして指定する。クライアントがＨＴＴＰリクエストするＵＲＩは例えば"http://（画像形成装置のＩＰアドレス）/printer/events?subscribed_id=00001"のような形式となる。

図１０は「/printer/events/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。「/printer/events/リクエスト」によるジョブ状態通知では、レスポンスを分割して断続的に送信するレスポンス分割の方式を利用する。レスポンス分割については後述する。

図１０において、Ｗｅｂサービス提供モジュール２２６は「/printer/events/リクエスト」を受信すると、まずＵＲＩを解析し（ステップＳ１３１）、ジョブ状態通知リクエスト（例えば、/****/events/）であると判断すると、そのＨＴＴＰセッションとクエリパラメータで指定されたクライアント識別ＩＤとを合わせて対で保持する（ステップＳ１３２）。

次いで、ＵＲＩに対応するイベントハンドラであるプリンタジョブ管理モジュール２２２を呼び出す（ステップＳ１３３）。

プリンタジョブ管理モジュール２２２は内部で管理するジョブ状態通知要求フラグをＯＦＦ→ＯＮにする（ステップＳ１３４）。ジョブ状態通知要求フラグは、コピー、プリンタ、ファクシミリ等の機能毎に対応して設けられ、ジョブ状態通知を必要としない場合はＯＦＦ、必要とする場合はＯＮとするものである。なお、ジョブ状態通知要求フラグは、各クライアントに共通としてもよいし、各クライアント毎に別々に管理されてもよい。

そして、ジョブ状態通知リクエストに対するレスポンスのメッセージヘッダ部となるデータを生成し、Ｗｅｂサービス提供モジュール２２６を介してクライアントに送信する（ステップＳ１３５、Ｓ１３６）。レスポンスのヘッダ部にはそのメッセージが生成された日時やレスポンスのデータフォーマットなどの情報が含まれる。レスポンスのボディ部はジョブの状態に変化が発生したときに逐次送信するが、この時点ではジョブが存在しないのでまだ送信しない。

図８に戻り、クライアントとしての操作部アプリ３０１は、「/printer/job/リクエスト」をサーバとしての本体部２に送信し（ステップＳ１４０）、プリンタジョブ実行を要求する。クライアントがＨＴＴＰリクエストするＵＲＩは例えば"http://（画像形成装置のＩＰアドレス）/printer/job/"のような形式となる。

図１１は「/printer/job/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。

図１１において、Ｗｅｂサービス提供モジュール２２６は「/printer/job/リクエスト」を受信すると、まずＵＲＩを解析し（ステップＳ１４１）、イベントハンドラ登録されているプリンタジョブ管理モジュール２２２を呼び出す（ステップＳ１４２）。

プリンタジョブ管理モジュール２２２はリクエストのメッセージヘッダ部を解析して（ステップＳ１４３）、ヘッダ部にクライアント識別ＩＤがセットされている場合（ステップＳ１４３のＹＥＳ）、当該ジョブのジョブ情報の一部としてクライアント識別ＩＤを保持しておく（ステップＳ１４４）。ここで、クライアント識別ＩＤがセットされているジョブはジョブ状態変化通知要とし、セットされてないジョブはジョブ状態通知不要とする。ジョブ状態変化時の処理については後述する。

次いで、プリンタジョブ管理モジュール２２２は、「/printer/job/リクエスト」のボディ部にセットされた、印刷データやカラー／モノクロや用紙サイズなどの印刷条件をＪＳＯＮ形式などあらかじめ決められたデータ構造に従ってジョブを実行する（ステップＳ１４５）。ジョブの実行の前後でジョブの状態が変化する。図１２はジョブ状態の例を示している。

図１１に戻り、プリンタジョブ管理モジュール２２２はレスポンスデータを生成し、Ｗｅｂサービス提供モジュール２２６に送信し（ステップＳ１４６）、Ｗｅｂサービス提供モジュール２２６はクライアントにレスポンスを送信する（ステップＳ１４７）。

図１３は実行中ジョブの状態が変化したときのサーバ側の処理例を示すフローチャートである。

図１３において、ジョブ状態が変化したとき、プリンタジョブ管理モジュール２２２はまずジョブ状態通知フラグがＯＮかどうかを判定し（ステップＳ１５１）、ＯＦＦの場合（ステップＳ１５１のＮＯ）は何もせず終了する。

ジョブ状態通知フラグがＯＮの場合（ステップＳ１５１のＹＥＳ）は、状態変化が発生したジョブのジョブ情報を参照し、クライアント識別ＩＤが保持されているかを判定する（ステップＳ１５２）。クライアント識別ＩＤが保持されていない場合（ステップＳ１５２のＮＯ）は、何もせず終了する。

クライアント識別ＩＤが保持されている場合（ステップＳ１５２のＹＥＳ）は、ジョブ状態変化データを生成し、Ｗｅｂサービス提供モジュール２２６に送信する（ステップＳ１５３）。図１４はジョブ状態変化データの例を示している。なお、図示の例ではジョブ状態変化データの形式はＪＳＯＮ形式としているが、任意の形式としてよい。

図１３に戻り、Ｗｅｂサービス提供モジュール２２６は、プリンタジョブ管理モジュール２２２からの状態変化通知を受信すると、ジョブ状態変化データからクライアント識別ＩＤを取り出し、取り出したクライアント識別ＩＤと一致するジョブ状態通知リクエストの要求元のクライアントだけにジョブ状態変化データを送信する（ステップＳ１５４）。

このようにして、ジョブ状態通知リクエストしたクライアントがジョブ実行リクエストしたジョブの状態通知レスポンス（イベント）のみを送信することができる。

＜分割レスポンスの動作例＞
ＷｅｂサービスはＨＴＴＰ通信によりサーバとクライアントで情報交換することが基本的な思想である。

図１５はＨＴＴＰ通信の例を示す図であり、ＨＴＴＰクライアントとサーバの間のＨＴＴＰ通信を模式的に表している。ＨＴＴＰ通信は、ＨＴＴＰクライアントからサーバに対してヘッダとボディから構成されるＨＴＴＰリクエストを送信し、サーバはＨＴＴＰクライアントに、同じくヘッダとボディから構成されるＨＴＴＰレスポンスを送信する。これにより、ＨＴＴＰクライアントとサーバの間で情報の送受信を行っている。図１６はＨＴＴＰデータの構造を示す図であり、ヘッダとボディを含んでいる。

ＨＴＴＰ通信のプロトコル上、常にＨＴＴＰクライアントからＨＴＴＰリクエストを出し、サーバはそのＨＴＴＰリクエストに応答することが基本原理である。通常は、ＨＴＴＰクライアントからのＨＴＴＰリクエストに対して、サーバがＨＴＴＰレスポンスを送信した時点で、リクエスト処理は完結し、その後、ＨＴＴＰクライアントがＨＴＴＰリクエストを出すまでは、サーバはＨＴＴＰクライアントに情報を伝えることはできない。

そこで、サーバからのＨＴＴＰレスポンスによりリクエスト処理が完結しないように、ＨＴＴＰレスポンスを分割して送信する。図１７は分割したレスポンスとＨＴＴＰデータの関係の例を示す図である。

サーバの状態変化を検出したいＨＴＴＰクライアントは、サーバに対して状態通知のＨＴＴＰリクエストを送信する。サーバは、ＨＴＴＰクライアントから接続された段階でまずヘッダ部分だけ応答する。通常、ヘッダにはデータサイズを示すContent-Lengthを記載することが一般的だが、今回は予め応答するデータサイズが分からない。したがって、Content-Lengthは記載せずにヘッダを応答することになる。なお、Content-Lengthを含まなくてもＨＴＴＰ仕様として問題はない。

その後、ボディ部分の送信処理はサーバで状態変化あるまで行わない。ＨＴＴＰクライアントはサーバからの応答待ちの状態になる。

サーバでエラー発生など何らかの状態変化が発生したタイミングで、状態変化を示すボディの一部をＨＴＴＰクライアントに送信する。ボディの一部の送信が完了しても、サーバは完了を送信しないため、ＨＴＴＰクライアント／サーバともにボディ部分の送受信中の状態を維持している。

これらの処理を、サーバの状態変化が発生する度に繰り返し実行することで、ＨＴＴＰクライアントのタイミングに依存しない状態通知が実現できる。

最終的にはヘッダとボディからなるＨＴＴＰプロトコルに従ったデータとなる。このことにより、一般的なＨＴＴＰ通信を行えるソフトウェアや動作環境で実現可能となる。

ＨＴＴＰクライアントは、一定期間にわたってサーバから応答が無い場合、通信を切断する場合がある。一定期間にわたってサーバで状態変化が発生しない場合は、サーバから状態変更なしを示すボディの一部を送信することで通信を維持することができる。

図１８はデータ書式の例を示す図である。

ＨＴＴＰでは、テキストデータ、画像データ、ＸＭＬ、ＪＳＯＮなど様々な種類のデータ送信が可能である。Ｗｅｂサービスの用途としては、最近はＪＳＯＮ形式でデータを送受信するケースが多い。

図１８（ａ）は通常のＨＴＴＰレスポンスにおいてＪＳＯＮ形式を用いた場合を示しており、ヘッダのContent-Typeにjsonが指定されている。ボディは全体がＪＳＯＮ形式で記述されている。

図１８（ｂ）は分割レスポンスにＪＳＯＮ形式を用いた場合を示しており、ボディの個々の部分データをＪＳＯＮ形式で記述し、区切り文字列（例えば、改行を２個）を付加している。この場合、ボディ全体はＪＳＯＮ形式とはならないため、ヘッダのContent-Typeはtext/plainとなっている。

ＨＴＴＰクライアントは部分データの個々を受信することに意味があるため、個々の部分データがＪＳＯＮ形式等の所定のデータ形式である方が、ＨＴＴＰクライアント側も処理が容易となる。

ＨＴＴＰクライアントは、ＨＴＴＰプロトコルに従い順次に受信データを読み出す。このとき、各データ部分の最後に付された区切り文字列により、個々の部分データを区別して読み出すことができる。

＜状態通知の動作例＃２＞
前述した状態通知の動作例＃１では、サーバ側がクライアント識別ＩＤ（Subscribed_ID）を発行し、クライアント識別ＩＤによりジョブ状態通知レスポンス（イベント）を振り分ける手法について説明した。しかし、前述した分割レスポンスを状態通知に用いる場合、状態通知のクライアント数に比例して生存期間の長いセッションの数が増加することになり、システムのリソース制約上、同時に接続可能なセッション数に上限がある場合には同時接続可能なセッション数を圧迫してしまうという問題がある。そこで、クライアント識別ＩＤの発行と状態通知レスポンス振り分けをクライアント側で実施し、サーバ・クライアント間のジョブ状態通知用のセッションを一本化するようにしている。

図１９はＷｅｂＡＰＩによる状態通知の処理例を示すモジュール間コラボレーション図である。操作部３には、ジョブ状態通知リクエストを取りまとめる役割のサービス提供モジュールである状態通知イベントディスパッチャ３１０が設けられている。

ジョブ状態通知を受け取りたい操作部アプリ３０１は、まず状態通知イベントディスパッチャ３１０にジョブ状態通知要求し（ステップＳ２１）、要求元の操作部アプリを識別するためのクライアント識別ＩＤ（Subscribed_ID）を発行してもらう。このとき、状態通知イベントディスパッチャ３１０はクライアント識別ＩＤとそれに対応する要求元の操作部アプリの情報を保持しておき、サーバ側の本体部２に複数の操作部アプリに共通のジョブ状態通知リクエストを送信する（ステップＳ２２）。

次いで、操作部アプリ３０１はクライアント識別ＩＤをリクエストヘッダに含めてジョブ実行リクエストする（ステップＳ２３）。

サーバ側は、リクエストされたジョブを実行し、ジョブ状態に変化が発生するときは、当該ジョブのクライアント識別ＩＤを含めたジョブ状態変化データを状態通知イベントディスパッチャ３１０に送信する（ステップＳ２４）。

状態通知イベントディスパッチャ３１０はジョブ状態変化データ内に含まれるクライアント識別ＩＤを取り出し、取り出したクライアント識別ＩＤに対応する要求元アプリである操作部アプリ３０１に状態変化データを送信する（ステップＳ２５）。

次にサーバ側の本体部２の動作について説明する。この動作例では、クライアント側がクライアント識別ＩＤを管理するので、サーバ側でクライアント識別ＩＤを発行する「/subscription/リクエスト」は不要である。従って、操作部アプリ３０１は、本体部２に対して「/printer/events/リクエスト」と「/printer/job/リクエスト」を送信する。

図２０は「/printer/events/リクエスト」受信時のサーバ側の処理例を示すフローチャートである。図１０に示した処理との違いは、Ｗｅｂサービス提供モジュール２２６がクライアント識別ＩＤと要求元とのセッションの紐付け情報を保持する処理（図１０のステップＳ１３２）がない点である。

「/printer/job/リクエスト」に対する動作は図１１に示したものと同様である。

図２１は実行中ジョブの状態が変化したときのサーバ側の処理例を示すフローチャートである。図１３に示した処理との違いは、Ｗｅｂサービス提供モジュール２２６がクライアントへの状態変化データ送信時（図２１のステップＳ１５５）にクライアント識別ＩＤを参照しない点である。

このようにして、サーバ・クライアント間のジョブ状態通知用セッションを一本化し、ジョブ状態通知クライアントがジョブ状態通知レスポンス（イベント）を要求元アプリに振り分けることができるようになる。

＜総括＞
以上説明したように、本実施形態によれば、ジョブ状態通知リクエストしたのと同一のクライアントが実行リクエストしたジョブの状態変化を通知することができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ 画像形成装置
２ 本体部
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＮＶ−ＲＡＭ
２０４ プログラムＲＯＭ
２０５ フォントＲＯＭ
２０６ ネットワークインタフェース
２０７ 操作部インタフェース
２０８ プリンタエンジンインタフェース
２０９ スキャナエンジンインタフェース
２１０ ＨＤＤ
２１１ オプションＲＡＭ
２１２ プリンタエンジン
２１３ スキャナエンジン
２２１ ＰＤＬ解析モジュール
２２２ プリンタジョブ管理モジュール
２２３ コピージョブ管理モジュール
２２４ スキャナジョブ管理モジュール
２２５ ネットワーク管理モジュール
２２６ Ｗｅｂサービス提供モジュール
２２７ 印刷管理モジュール
２２８ システム管理モジュール
２２９ メモリ管理モジュール
２３０ サービス提供モジュール群
３ 操作部
３０１〜３０３ 操作部アプリ
３１０ 状態通知イベントディスパッチャ
４、４Ａ〜４Ｃ ホストコンピュータ

特開２００７−０６６０８３号公報

Claims (11)

1. 第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムであって、
   前記第１の情報処理装置は、
   前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を発行する手段と、
   ジョブ状態通知のリクエストおよびジョブ実行のリクエストに前記識別情報の指定を付加して前記第２の情報処理装置に送信する手段であって、発行した前記識別情報を伴う、複数の前記クライアントに共通のジョブ状態通知のリクエストを前記第２の情報処理装置に送信する手段と、
   前記第２の情報処理装置から受信したジョブ状態通知のレスポンスを前記識別情報に基づいて要求元のクライアントに振り分ける手段と
   を備え、
   前記第２の情報処理装置は、
   ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントにジョブ状態通知のレスポンスを送信する手段
   を備えたことを特徴とする情報処理システム。
2. 請求項１に記載の情報処理システムにおいて、
   前記第２の情報処理装置は、
   前記第１の情報処理装置からのリクエストに応じて前記識別情報を発行する手段
   を備えたことを特徴とする情報処理システム。
3. 請求項１に記載の情報処理システムにおいて、
   前記第１の情報処理装置は、
   当該第１の情報処理装置内のクライアントからのリクエストに応じて前記識別情報を発行する手段
   を備えたことを特徴とする情報処理システム。
4. 請求項１乃至３のいずれか一項に記載の情報処理システムにおいて、
   前記第２の情報処理装置は、
   ジョブ状態通知の必要性の有無を示すフラグを保持する手段
   を備え、
   前記フラグの値に従ってジョブ状態通知を行うことを特徴とする情報処理システム。
5. 請求項１乃至４のいずれか一項に記載の情報処理システムにおいて、
   前記第２の情報処理装置が所定の情報処理を行う本体部であり、前記第１の情報処理装置が前記本体部に対する操作を受け付ける操作部である
   ことを特徴とする情報処理システム。
6. 第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置であって、
   前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を発行する手段と、
   ジョブ状態通知のリクエストおよびジョブ実行のリクエストに前記識別情報の指定を付加して前記第２の情報処理装置に送信する手段であって、発行した前記識別情報を伴う、複数の前記クライアントに共通のジョブ状態通知のリクエストを前記第２の情報処理装置に送信する手段と、
   前記第２の情報処理装置から受信したジョブ状態通知のレスポンスを前記識別情報に基づいて要求元のクライアントに振り分ける手段と、
   前記第２の情報処理装置から送信されるレスポンスであって、ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントに送信するジョブ状態通知のレスポンスを受信する手段と
   を備えたことを特徴とする情報処理装置。
7. 第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置であって、
   前記第１の情報処理装置から送信される、前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報の指定が付加された複数の前記クライアントに共通のジョブ状態通知のリクエストおよびジョブ実行のリクエストを受信する手段と、
   ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントにジョブ状態通知のレスポンスを送信する手段と
   を備え、
   前記第１の情報処理装置に前記ジョブ状態通知のレスポンスを前記識別情報に基づいて要求元のクライアントに振り分けさせることを特徴とする情報処理装置。
8. 第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置が実行する方法であって、
   前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を発行する工程と、
   ジョブ状態通知のリクエストおよびジョブ実行のリクエストに前記識別情報の指定を付加して前記第２の情報処理装置に送信する工程であって、発行した前記識別情報を伴う、複数の前記クライアントに共通のジョブ状態通知のリクエストを前記第２の情報処理装置に送信する工程と、
   前記第２の情報処理装置から受信したジョブ状態通知のレスポンスを前記識別情報に基づいて要求元のクライアントに振り分ける工程と、
   前記第２の情報処理装置から送信されるレスポンスであって、前記第２の情報処理装置が前記識別情報に基づいてジョブ状態通知のリクエストとジョブ実行のリクエストとを対応付けて管理し、ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントに送信するジョブ状態通知のレスポンスを受信する工程と
   を備えたことを特徴とする情報処理方法。
9. 第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置が実行する方法であって、
   前記第１の情報処理装置から送信される、前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報の指定が付加された複数の前記クライアントに共通のジョブ状態通知のリクエストおよびジョブ実行のリクエストを受信する工程と、
   ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントにジョブ状態通知のレスポンスを送信する工程と
   を備え、
   前記第１の情報処理装置に前記ジョブ状態通知のレスポンスを前記識別情報に基づいて要求元のクライアントに振り分けさせることを特徴とする情報処理方法。
10. 第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムの前記第１の情報処理装置を構成するコンピュータを、
    前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報を発行する手段、
    ジョブ状態通知のリクエストおよびジョブ実行のリクエストに前記識別情報の指定を付加して前記第２の情報処理装置に送信する手段であって、発行した前記識別情報を伴う、複数の前記クライアントに共通のジョブ状態通知のリクエストを前記第２の情報処理装置に送信する手段、
    前記第２の情報処理装置から受信したジョブ状態通知のレスポンスを前記識別情報に基づいて要求元のクライアントに振り分ける手段、
    前記第２の情報処理装置から送信されるレスポンスであって、ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントに送信するジョブ状態通知のレスポンスを受信する手段
    として機能させることを特徴とする情報処理プログラム。
11. 第１の情報処理装置から第２の情報処理装置に対してジョブ状態通知のリクエストを送信し、その後、前記第１の情報処理装置から前記第２の情報処理装置に対してジョブ実行のリクエストを送信し、前記第２の情報処理装置から前記第１の情報処理装置に対してジョブ状態通知のレスポンスを送信する情報処理システムの前記第２の情報処理装置を構成するコンピュータを、
    前記第１の情報処理装置から送信される、前記第１の情報処理装置内のクライアントからのリクエストに応じて、リクエスト送信元のクライアントを前記第２の情報処理装置に識別させる識別情報の指定が付加された複数の前記クライアントに共通のジョブ状態通知のリクエストおよびジョブ実行のリクエストを受信する手段、
    ジョブ状態変化が発生した場合に、該当するジョブのジョブ実行のリクエストに対応付けられたジョブ状態通知のリクエストの送信元のクライアントにジョブ状態通知のレスポンスを送信する手段として機能させ、
    前記第１の情報処理装置に前記ジョブ状態通知のレスポンスを前記識別情報に基づいて要求元のクライアントに振り分けさせることを特徴とする情報処理プログラム。

Images