以下に添付図面を参照して、この発明にかかる画像形成装置およびプロセス間通信方法の好適な実施の形態を詳細に説明する。
(実施の形態1)
図1は、この発明の実施の形態1である画像形成装置(以下、「複合機」という)の構成を示すブロック図である。図1に示すように、複合機100は、白黒ラインプリンタ(B&W LP)101と、カラーラインプリンタ(Color LP)102と、スキャナ103と、ファクシミリ104と、ハードディスク装置(HDD)105と、ネットワークインタフェース106などのハードウェアリソースを有するとともに、プラットホーム120とアプリケーション130とから構成されるソフトウェア群110を備えている。
プラットホーム120は、アプリケーション130からの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一または複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ(SRM)123と、汎用OS121とを有する。
コントロールサービスは、複数のサービスモジュールから形成され、SCS(システムコントロールサービス)122と、ECS(エンジンコントロールサービス)124と、MCS(メモリコントロールサービス)125と、OCS(オペレーションパネルコントロールサービス)126と、FCS(ファックスコントロールサービス)127と、NCS(ネットワークコントロールサービス)128とから構成される。
なお、このプラットホーム120は、あらかじめ定義されたメソッドにより前記アプリケーション130から処理要求を受信可能とするアプリケーションプログラムインタフェース(API)を有する。
汎用OS121は、UNIX(登録商標)などの汎用オペレーティングシステムであり、プラットホーム120並びにアプリケーション130の各ソフトウェアをそれぞれプロセスとして並列実行する。
SRM123は、SCS122とともにシステムの制御およびリソースの管理を行うものであり、スキャナ部やプリンタ部などのエンジン、メモリ、HDDファイル、ホストI/O(セントロI/F、ネットワークI/F、IEEE1394 I/F、RS232C I/Fなど)のハードウェア資源を利用する上位層からの要求にしたがって調停を行い、実行制御する。
具体的には、このSRM123は、要求されたハードウェア資源が利用可能であるか(他の要求により利用されていないかどうか)を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、SRM123は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容(たとえば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など)を直接実施している。
SCS122は、アプリ管理、操作部制御、システム画面表示、LED表示、リソース管理、割り込みアプリ制御を行うものである。ECS124は、白黒ラインプリンタ(B&W LP)101、カラーラインプリンタ(Color LP)102、スキャナ103、ファクシミリ104からなるハードウェアリソースのエンジンを制御するものである。
MCS125は、画像メモリの取得および解放、HDDの利用、画像データの圧縮および伸張などを行うものである。OCS126は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールである。
FCS127は、システムコントローラの各アプリ層からPSTN/ISDN網を利用したファクシミリ送受信、BKM(バックアップSRAM)で管理されている各種ファクシミリデータの登録/引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのAPIを提供するものである。FCS127には、そのサブプロセスであるFCUハンドラ(FCUH)129が起動される。このFCUH129は、FCS127からの指令によりファクシミリ送受信の際にファクシミリエンジンのデバイスドライバを制御するものである。
NCS128は、ネットワークI/Oを必要とするアプリケーション130に対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーション130に振り分けたり、アプリケーション130からデータをネットワーク側に送信する際の仲介を行うものである。
アプリケーション130は、ページ記述言語(PDL)、PCLおよびポストスクリプト(PS)を有するプリンタ用のアプリケーションであるプリンタアプリ111と、コピー用アプリケーションであるコピーアプリ112と、ファクシミリ用アプリケーションであるファックスアプリ113と、スキャナ用アプリケーションであるスキャナアプリ114と、ネットワークファイル用アプリケーションであるネットファイルアプリ115と、工程検査用アプリケーションである工程検査アプリ116とを有している。
これらの各コントロールサービスとSRM123と各アプリケーション130とは、一または複数のメソッドを有するオブジェクトであり、このオブジェクトを起動することによりそれぞれプロセスとして汎用OS121上に生成されて実行される。そして、各プロセス内部には、複数のスレッドが起動され、汎用OS121の管理下でこれらのスレッドのCPU占有時間を切り替えることにより並列実行が実現されている。このため、プロセス切り替えによる並列実行と比較して、並列実行時の処理速度の向上が図られている。
各アプリプロセスと各コントロールサービスプロセスとは、メソッドの実行によるプロセス間通信によってメッセージの送受信が行われる。図2は、実施の形態1の複合機上で動作するサーバプロセスとクライアントプロセスの関係を示すブロック図である。ここで、サーバプロセス202とは、クライアントプロセス201からの要求によりクライアントプロセス201に対しサービスを提供するプロセスをいう。クライアントプロセス201とは、サーバプロセス202に対して要求を行うことにより、サーバプロセス202からサービスの提供を受けるプロセスをいう。
実施の形態1の複合機100では、上述のコピーアプリ112、プリンタアプリ111、スキャナアプリ114、ファックスアプリ113などのアプリケーション130のプロセス、およびECS124、MCS125、FCS127、NCS128などのコントロールサービスのプロセスが主としてクライアントプロセス201となり、コントロールサービスおよびSRM123のプロセスが主としてサーバプロセス202となる。
すなわち、各アプリケーション130がコントロールサービスからサービスの提供を受ける場合には、各アプリケーション130のプロセスがクライアントプロセス201として動作し、コントロールサービスがサーバプロセス202として動作する。また、コントロールサービス間でサービスの要求と提供を行う場合には、サービス要求を行うコントロールサービスがクライアントプロセス201として動作し、サービス提供を行うコントロールサービスがサーバプロセス202として動作する。
なお、これらの例に限られず、各アプリケーション130のプロセス、コントロールサービスのプロセス、SRMプロセス123は、いずれもサーバプロセス202およびクライアントプロセス201となることができる。
すなわち、これらのプロセスは、他のいずれかのプロセスに対しサービスを要求する場合にクライアントプロセス201として動作する一方、他のプロセスからの要求によりサービスを提供する場合にサーバプロセス202として動作することになる。
これらのアプリケーション130、コントロールサービスおよびSRM123のプロセスには、いずれも複数のスレッドが起動している。このため、他のプロセスからの要求を受けた場合には、当該他のプロセスをクライアントプロセス201としたサーバプロセス202として動作するが、これと同時に、他のプロセスに対してサービスを要求する場合に当該他のプロセスをサーバプロセス202としたクライアントプロセス201として動作する。
また、各プロセスは、同時に複数のプロセスをクライアントプロセス201としたサーバプロセス202となることも可能である。さらに、各プロセスは、同時に複数のサーバプロセス202からのサービスの提供を受けるクライアントプロセス201となることも可能である。
図2に示す通り、クライアントプロセス201は、サーバプロセス202のサービスを要求するために、クライアントプロセス201内のスレッドからサーバプロセス202に対してサービス要求メッセージを送信するサービス要求メソッドを実行する。
このサービス要求メッセージを受信したサーバプロセス202は、サービス実行メソッドを実行する。このサービス実行メソッドは、クライアントプロセス201から要求されたサービスを実行し、その実行結果を実行結果メッセージとして要求元のクライアントプロセス201に送信するメソッドである。
図2の例では、クライアントプロセス201がサービスAの提供を受けるために、サービスA要求メソッドを実行してサービスA要求メッセージをサーバプロセス202に送信している。そして、サーバプロセス202がこのサービスA要求メッセージを受信すると、サービスA実行メソッドを実行する。サーバプロセス202は、サービスA実行メソッドの実行により、(1)サービスAの処理を実行し、ついで、(2)サービスAの実行結果をサービスA実行結果メッセージとしてクライアントプロセス201に送信する。
このように、サーバプロセス202とクライアントプロセス201のプロセス間通信は、メソッド実行によるサービス要求メッセージの送信、メソッド実行によるサービスの提供およびサービス実行結果メッセージ送信という一連の処理によって実現されている。
図3は、各アプリケーションおよび各コントロールサービスのオブジェクトであらかじめ定義されているメソッドを示す説明図である。図3に示すように、各オブジェクトには、主としてクライアントプロセス201となったときにサーバプロセス202に対しサービスの提供を依頼するためにサービス要求メッセージを送信するサービス要求メソッドと、クライアントプロセス201からのサービス要求メッセージを受信してサーバプロセス202として動作するときにサービス提供の処理を実行しその実行結果メッセージを要求元のクライアントプロセス201に送信するサービス実行メソッドとが定義されている。
例えば、ECS124のオブジェクトでは、サービス要求メソッドとしてメモリ画像情報取得要求メソッド、メモリ確保要求メソッド、資源獲得要求メソッドなどが登録されており、一方、サービス実行メソッドとして、ジョブ動作モード設定メソッド、ジョブスタートメソッド、ジョブオープンメソッドおよびジョブクローズメソッドなどが登録されている。
なお、ジョブ動作モード設定メソッド、ジョブスタートメソッド、ジョブオープンメソッドおよびジョブクローズメソッドは、それぞれクライアントプロセス201からジョブ動作モード設定要求メッセージ、ジョブスタート要求メッセージ、ジョブオープン要求メッセージ、ジョブクローズ要求メッセージを受信したときに実行される。
また、プリンタアプリ111のオブジェクトには、サービス要求メソッドとしてジョブ動作設定要求メソッド、ジョブスタート要求メソッドなどが登録されている。なお、図3に示す他のコントロールサービスやSRM123、および他のアプリケーション130の各オブジェクトについても同様にサービス要求メソッドとサービス実行メソッドが登録されている。
つぎに、実施の形態1の複合機100で実際に行われるプリンタ動作の一例について説明する。図4は、実施の形態1の複合機でプリンタ動作を行う場合のプリンタアプリ、ECS、MCS、SRMの各プロセス間のデータシーケンスを示す説明図である。
複合機100は、プリンタアプリプロセス111、ECSプロセス124、MCSプロセス125およびSRMプロセス123が動作している。これらのプロセスは、複合機100の起動時に生成されるようになっている。
プリンタアプリプロセス111は、プロセス内に複数のスレッドが起動している。プリンタアプリプロセス111は、ECSプロセス124をサーバプロセス202としたクライアントプロセス201となる。ECSプロセス124は、プリンタ動作時にプリンタアプリプロセス111をクライアントプロセス201としたサーバプロセス202となるとともに、MCSプロセス125およびSRMプロセス123をそれぞれサーバプロセス202としたクライアントプロセス201となる。
MCSプロセス125は、プリンタ動作時にECSプロセス124をクライアントプロセス201としたサーバプロセス202となるとともに、SRMプロセス123をサーバプロセス202としたクライアントプロセス201となる。SRMプロセス123は、プリンタ動作時にECSプロセス124またはMCSプロセス125をクライアントプロセス201としたサーバプロセス202となっている。
PCなどのホストからセントロI/F、USB I/F、ネットワークI/Fなど経由して印刷要求があると、その印刷要求をNCSプロセス128が受信してプリンタアプリプロセス111に転送する(ステップS401)。
プリンタアプリプロセス111は、NCSプロセス128から印刷要求を受信すると新たなプリンタジョブを生成し、ジョブ動作モード設定要求メソッドを実行して、ECSプロセス124に対してジョブ動作モード設定要求メッセージを送信する(ステップS402)。ここで、ジョブ動作モードとは、スキャナ、プロッタ、フィニッシャなどを動作させるために必要なパラメータ群であり、印刷用紙サイズ、印刷部数、給紙トレイなどのプリンタ条件から生成されるジョブの動作条件を定めたものである。
ECSプロセス124は、プリンタアプリプロセス111からジョブ動作モード設定要求メッセージを受信すると、ジョブ動作モード設定実行メソッドを実行し、新たに生成されたプリンタジョブに対して上述のジョブ動作モードを設定して、その実行結果メッセージをプリンタアプリプロセス111に送信する。
プリンタアプリプロセス111は、ECSプロセス124からジョブ動作モード設定の実行結果メッセージを受信すると、ジョブの開始要求を行うため、ジョブスタート要求メソッドを実行して、ECSプロセス124に対しジョブスタート要求メッセージを送信する(ステップS403)。
ECSプロセス124は、プリンタアプリプロセス111からジョブスタート要求メッセージを受信すると、ジョブスタート実行メソッドを起動し、ジョブの開始処理を行ってその実行結果メッセージをプリンタアプリプロセス111に送信する。プリンタアプリプロセス111は、ECSプロセス124からジョブスタートの実行結果メッセージを受信する。
つぎに、ECSプロセス124は、メモリに格納されている印刷データを取得するために、メモリ画像情報要求メソッドを実行し、MCSプロセス125に対してメモリ画像情報要求メッセージを送信する(ステップS404)。
MCSプロセス125は、ECSプロセス124からメモリ画像情報要求メッセージを受信すると、メモリ画像情報実行メソッドを起動する。そして、MCSプロセス125はメモリに格納されている画像データを取得して、画像データを実行結果メッセージとともにECSプロセス124へ送信する(ステップS405)。ECSプロセス124は、メモリ画像情報要求メッセージの送信および画像データの受信処理を、印刷ページが終了するまで繰り返し行う(ステップS408、S409)。
MCSプロセス125は、画像データのECSプロセス124への送信後、画像メモリを確保するためにメモリ取得要求メソッドを実行し、SRMプロセス123に対してメモリ取得要求メッセージを送信する(ステップS406)。SRMプロセス123では、MCSプロセス125からメモリ取得要求メッセージを受信すると、メモリ取得実行メソッドを実行し、プリント用に画像メモリを確保し、その実行結果メッセージをMCSプロセス125へ送信する。
ECSプロセス124は、1ページ目の印刷データをMCSプロセス125から受信した後、プリンタエンジン資源を取得するために、資源獲得要求メソッドを実行して、SRMプロセス123に対して資源獲得要求メッセージを送信する(ステップS407)。SRMプロセス123は、ECSプロセス124から資源獲得要求メッセージを受信すると資源獲得実行メソッドを実行し、プリンタエンジンを占有し、その実行結果メッセージをECSプロセス124へ送信する。
ECSプロセス124は、メモリ画像情報要求(ステップS411)に対する実行結果メッセージとして「画像なし」の応答を受信した場合(ステップS412)に、すべての印刷ページのプリントが終了したものと判断し、ジョブエンド通知メソッドを実行して、プリンタアプリプロセス111に対してジョブエンド通知メッセージを送信する(ステップS413)。プリンタアプリプロセス111では、このジョブエンド通知メッセージを受信することによりプリント終了を検知する。
次に、実施の形態1の複合機100で実際に行われるスキャナ動作の一例について説明する。図5は、実施の形態1の複合機でスキャナ動作を行う場合のスキャナアプリ、ECS、MCS、SRMの各プロセス間のデータシーケンスを示す説明図である。
複合機100は、スキャナアプリプロセス114、ECSプロセス124、MCSプロセス125およびSRMプロセス123が動作している。これらのプロセスは、複合機の起動時に生成されるようになっている。
スキャナアプリプロセス114は、プロセス内に複数のスレッドが起動している。スキャナアプリプロセス114は、ECSプロセス124をサーバプロセス202としたクライアントプロセス201となっている。ECSプロセス124は、スキャナ動作時にスキャナアプリプロセス114をクライアントプロセス201としたサーバプロセス202となるとともに、MCSプロセス125およびSRMプロセス124をそれぞれサーバプロセス202としたクライアントプロセス201となる。MCSプロセス125は、スキャナ動作時にスキャナアプリプロセス114およびECSプロセス124をクライアントプロセス201としたサーバプロセス202となる。SRMプロセス123は、ECSプロセス124をクライアントプロセス201としたサーバプロセス202となる。
スキャナアプリプロセス114に対しスキャン要求があると、スキャナアプリプロセス114は、新たなスキャナジョブを生成し、ジョブオープン要求メソッドを実行して、ECSプロセス124に対してジョブオープン要求メッセージを送信する(ステップS501)。
ECSプロセス124では、スキャナアプリプロセス114からジョブオープン要求メッセージを受信すると、ジョブオープン実行メソッドを実行し、ジョブのオープン処理を行い、その実行結果メッセージをスキャナアプリプロセス114に送信する。
スキャナアプリプロセス114は、ECSプロセス124からジョブオープンの実行結果メッセージを受信すると、つぎにファイル生成要求メソッドを実行して、MCSプロセス125に対しファイル生成要求メッセージを送信する(ステップS502)。MCSプロセス125では、スキャナアプリプロセス114からファイル生成要求メッセージを受信すると、ファイル生成実行メソッドを実行し、スキャンした画像を一時的に格納するファイルをHDD上に生成して、その実行結果メッセージをスキャナアプリプロセス114に送信する。
スキャナアプリプロセス114は、ファイル生成の実行結果メッセージを受信すると、ジョブ動作モードの設定を行うため、ジョブ動作モード設定要求メソッドを実行し、ECSプロセス124に対しジョブ動作モード設定要求メッセージを送信する(ステップS503)。
ECSプロセス124は、スキャナアプリプロセス114からジョブ動作モード設定要求メッセージを受信すると、ジョブ動作モード設定実行メソッドを実行し、スキャナジョブに上述のジョブ動作モードを設定して、その実行結果メッセージをスキャナアプリプロセス114に送信する。
ついで、スキャナアプリプロセス114は、ジョブスタート要求メソッドを実行して、ジョブスタート要求メッセージをECSプロセス124に対して送信する(ステップS504)。ECSプロセス124は、ジョブスタート要求メッセージを受信すると、ジョブスタート要求実行メソッドを実行して、ジョブの開始処理を行い、その実行結果メッセージをスキャナアプリプロセス114に送信する。
一方、ECSプロセス124は、スキャナエンジンの資源獲得のため、資源獲得要求メソッドを実行し、SRMプロセス123に対して資源獲得要求メッセージを送信する(ステップS505)。SRMプロセス123は、資源獲得要求メッセージを受信すると資源獲得実行メソッドを実行して、スキャナエンジンを占有し、その実行結果メッセージをECSプロセス124へ送信する。
つぎに、ECSプロセス124は、スキャン画像をページ単位で格納するメモリを確保するために、ページ生成要求メソッドを実行して、MCSプロセス125に対しページ生成要求メッセージを送信する(ステップS506)。MCSプロセス125は、ページ生成要求メッセージを受信すると、ページ生成実行メソッドを実行して1ページ分のメモリを確保し、確保したページをオープンし、その実行結果メッセージをECSプロセス124へ送信する。
ECSプロセス124は、ページ生成の実行結果メッセージを受信すると、原稿フィードイン要求メソッドを実行し、スキャナエンジンに対して原稿フィードインの指示メッセージを送信して(ステップS507)、スキャナによる原稿の読み取り動作を開始させる。
1ページ分の原稿読み動作が終了すると、ECSプロセス124に対しスキャナエンジンからスキャン終了通知メッセージが送信されるので(ステップS508)、ECSプロセス124はこのスキャン終了通知メッセージを受信する。ECSプロセス124は、スキャン終了通知メッセージを受信すると、ページクローズ要求メソッドを実行して、MCSプロセス124に対しページクローズ要求メッセージを送信する(ステップS509)。
MCSプロセス125は、ページクローズ要求メッセージを受信すると、ページクローズ実行メソッドを実行して、メモリ上でオープンされている1ページ分の画像メモリをクローズし、その実行結果メッセージをECSプロセス124に送信する。
ECSプロセス124は、上述のページ生成要求メッセージの送信からページクローズ要求メッセージの送信までの処理(ステップS506〜S509)を原稿枚数分だけ繰り返し行う。原稿の最終ページのスキャンが終了すると、ECSプロセス124に対しスキャナエンジンからスキャン処理完了通知メッセージが送信される(ステップS510)。
ECSプロセス124は、スキャン処理完了通知メッセージを受信すると、スキャン完了通知メッセージをスキャナアプリプロセス114に対して送信し(ステップS511)、さらにジョブエンド通知メソッドを実行してジョブエンド通知メッセージも送信する(ステップS512)。
スキャナアプリプロセス114は、スキャン処理完了通知メッセージとジョブエンド通知メッセージとを順にECSプロセス124から受信する。一方、スキャナアプリプロセス114は、ファイル情報登録要求メソッドを実行して、MCSプロセス125に対してファイル情報登録要求メッセージを送信する(ステップS513)。
MCSプロセス125は、ファイル情報登録要求メッセージを受信すると、ファイル情報登録実行メソッドを実行して、一時的に生成されたすべての原稿のスキャン画像が格納されているファイルに対し、ファイル名、格納先等のファイル情報を登録し、その実行結果メッセージをスキャナアプリプロセス114に送信する。
スキャナアプリプロセス114は、ファイル情報登録の実行結果メッセージを受信すると、ファイルクローズ要求メソッドを実行して、MCSプロセス125に対しファイルクローズ要求メッセージを送信する(ステップS514)。MCSプロセス125では、ファイルクローズ要求メッセージを受信すると、ファイルクローズ実行メソッドを実行して、スキャン画像のファイルをクローズし、その実行結果メッセージをスキャナアプリプロセス114に送信する。スキャナアプリプロセス114は、ファイルクローズの実行結果メッセージを受信することによって、スキャン処理を終了する。
ついで、スキャナアプリプロセス114は、格納されているスキャン画像を読み出すため、次の処理を行う。まず、スキャナアプリプロセス114はファイルオープン要求メソッドを実行して、MCSプロセス125に対しスキャン画像のファイルをオープンするためのファイルオープン要求メッセージを送信する。また、スキャナアプリプロセス114は作業領域確保要求メソッドの実行による作業メモリの確保のための作業領域確保要求メッセージの送信、ページオープン要求メソッドの実行によるページオープン要求メッセージを順次に送信する(ステップS515〜S517)。
MCSプロセス125は、スキャナアプリプロセス114からファイルオープン要求メッセージ、作業領域確保要求メッセージ、ページオープン要求メッセージを順に受信して、ファイルオープン実行メソッドの実行によるスキャン画像ファイルのオープン処理、作業領域確保実行メソッドの実行による作業メモリの確保処理およびページオープン実行メソッドの実行によるページオープン処理をそれぞれ行って、各処理の実行結果メッセージをスキャナアプリプロセス114に送信する。
スキャナアプリプロセス114は、スキャン画像ファイルからの画像データの読み出しのために読み出し要求メソッドを実行し、読み出し要求メッセージをMCSプロセス125に送信する(ステップS518)。
さらに、スキャナアプリプロセス114は、ページクローズ要求メソッドを実行して、MCSプロセス125に対しページクローズ要求メッセージを送信する(ステップS519)。
MCSプロセス125は、ページオープン処理の終了後に、スキャナアプリプロセス114から読み出し要求メッセージを受信し、読み出し実行メソッドを実行してスキャナ画像ファイルから画像データを読み出し、画像データとともにその実行結果メッセージをスキャナアプリプロセス114に送信する。スキャナアプリプロセス114は、画像データの読み出しに関する実行結果メッセージを受信すると、次の読み出し要求メッセージをMCS125に送信し、その実行結果メッセージを受信する。
MCSプロセス125は、最後の読み出し処理の終了後にスキャナアプリプロセス114からページクローズ要求メッセージを受信すると、ページクローズ実行メソッドを実行して、オープンしているページデータのクローズ処理を行い、その実行結果メッセージをスキャナアプリプロセス114に送信する。
スキャナアプリプロセス114は、ページクローズの実行結果メッセージを受信すると、MCS125に対してページ削除要求メッセージ、作業領域削除要求メッセージ、ファイルクローズ要求メッセージ、ファイル削除要求メッセージを順に送信する(ステップS520〜S523)。
MCSプロセス125は、ページ削除要求メッセージ、作業領域削除要求メッセージ、ファイルクローズ要求メッセージ、ファイル削除要求メッセージを順に受信して、そのメッセージに対応する実行メソッドによって、ページデータの削除、作業メモリの削除、スキャン画像ファイルのクローズ、スキャン画像ファイルの削除の各処理を行って、各処理の実行結果メッセージをスキャナアプリプロセス114に送信する。スキャナアプリプロセス114がMCSプロセス125から各処理の実行結果メッセージを受信することにより、スキャン画像の読み出し処理が完了する。
次に、実施の形態1の複合機100で実際に行われるコピー動作の一例について説明する。図6は、実施の形態1の複合機でコピー動作を行う場合のコピーアプリ、ECS、MCS、SRMの各プロセス間のデータシーケンスを示す説明図である。
複合機100は、コピーアプリプロセス112、ECSプロセス124、MCSプロセス125およびSRMプロセス123が動作している。これらのプロセスは、複合機100の起動時に生成されるようになっている。また、これらのプロセスは、プロセス内に複数のスレッドが起動された状態となっている。
コピーアプリプロセス112は、ECSプロセス124をサーバプロセス202としたクライアントプロセス201となっている。ECSプロセス124は、コピー動作時にコピーアプリプロセス112をクライアントプロセス201としたサーバプロセス202となるとともに、MCSプロセス125およびSRMプロセス123をそれぞれサーバプロセス202としたクライアントプロセス201となる。
MCSプロセス125は、コピー動作時にECSプロセス124をクライアントプロセス201としたサーバプロセス202となるとともに、SRMプロセス123をサーバプロセス202としたクライアントプロセス201となる。SRMプロセス123は、ECSプロセス124およびMCSプロセス125をクライアントプロセス201としたサーバプロセス202となる。
コピー要求があると、コピーアプリプロセス112は、新たなコピージョブを生成し、スキャナ動作の場合と同様に、ECSプロセス124に対してジョブオープン要求メッセージ、ジョブ動作モード設定要求メッセージおよびジョブスタート要求メッセージの送信を行う(ステップS601〜S603)。これらの要求メッセージを受信したECSプロセス124の動作については、上述したスキャナ動作の場合と同様であるため説明を省略する。
ECSプロセス124では、ジョブスタートの実行結果メッセージをコピーアプリプロセス112に送信すると、つぎにスキャン画像を格納するためのメモリを確保するために、メモリ確保要求メソッドを実行し、MCSプロセス125に対し必要なサイズを指定したメモリ確保要求メッセージを送信する(ステップS604)。
MCSプロセス125では、メモリ確保要求メッセージを受信すると、メモリ確保実行メソッドを実行して、指定されたサイズのメモリ上の領域を確保するためのメモリ取得要求メソッドを実行し、SRM123に対してメモリ取得要求メッセージを送信する(ステップS605)。SRM123は、メモリ取得要求メッセージを受信すると、メモリ取得実行メソッドを実行して、メモリ上に指定されたサイズの領域を占有して、その実行結果メッセージをMCSプロセス125に送信する。
メモリ取得の実行結果メッセージを受信したMCSプロセス125は、受信した実行結果メッセージをメモリ確保の実行結果メッセージとしてECSプロセス124に送信する。ついで、メモリ確保の実行結果メッセージを受信したECSプロセス124は、スキャナエンジンとプリンタエンジンの資源獲得のため、資源獲得要求メソッドを実行して、SRMプロセス123に対して資源獲得要求メッセージを送信する(ステップS606)。
SRMプロセス123は、資源獲得要求メッセージを受信すると、資源獲得実行メソッドを実行してスキャナエンジンとプリンタエンジンとを占有し、その実行結果メッセージをECSプロセス124に送信する。
ECSプロセス124は、SRMプロセス123から資源獲得の実行結果メッセージを受信して、スキャナエンジンとプリンタエンジンとをコピージョブで占有すると、原稿フィードイン要求メソッドを実行し、スキャナエンジンに対して原稿フィードインの指示メッセージを送信して(ステップS607)、原稿のスキャン処理を開始させる。
スキャナエンジンは、原稿のスキャン処理が終了すると、スキャン終了通知メッセージをECSプロセス124に送信し(ステップS608)、プリンタエンジンにスキャン画像のプリント処理を開始させる。そして、プリンタエンジンはスキャン画像のプリント処理が終了すると、ECSプロセス124に印刷終了通知メッセージを送信する(ステップS610)。
ECSプロセス124は、スキャナエンジンからスキャン終了通知メッセージを受信すると、ジョブエンド通知メソッドを実行してコピーアプリプロセス112に対しスキャン終了の旨のジョブエンド通知メッセージを送信する(ステップS609)。また、ECSプロセス124はプリンタエンジンから印刷終了通知メッセージを受信すると、ジョブエンド通知メソッドを実行してコピーアプリプロセス112に対し印刷終了の旨のジョブエンド通知メッセージを送信する(ステップS611)。コピーアプリプロセス112は2つのジョブエンド通知メッセージを受信することにより、原稿1ページ分のコピー動作が完了する。
複数枚の原稿のコピーを行う場合には、さらにECSプロセス124に対しジョブスタート要求メッセージを送信する(ステップS612)。これにより、上述と同様の動作がECSプロセス124、MCSプロセス125、SRMプロセス123、スキャナエンジンおよびプリンタエンジンで行われる(ステップS613〜S616)。すべての原稿のコピーが終了し、コピーアプリプロセス112が最後のジョブエンド通知メッセージを受信すると(ステップS617)、コピーアプリプロセス112はジョブクローズ要求メソッドを実行して、ECSプロセス124に対しジョブクローズ要求メッセージを送信する(ステップS618)。
ECSプロセス124は、ジョブクローズ要求メッセージを受信すると、ジョブクローズ実行メソッドを実行して、オープン状態にあるコピージョブをクローズし、その実行結果メッセージをコピーアプリプロセス112に送信する。コピーアプリプロセス112がECSプロセス124からジョブクローズの実行結果メッセージを受信することにより、コピー動作が完了する。
次に、実施の形態1の複合機100で実際に行われるファクシミリ送信動作の一例について説明する。図7は、実施の形態1の複合機でファクシミリ送信動作を行う場合のファックスアプリ、FCS、ECS、MCS、SRMの各プロセス間のデータシーケンスを示す説明図である。
複合機100は、ファックスアプリプロセス113、FCSプロセス127、FCUHプロセス129、ECSプロセス124、MCSプロセス125およびSRMプロセス123が動作している。これらプロセスは、複合機100の起動時に生成されるようになっている。また、これらのプロセスは、プロセス内に複数のスレッドが起動された状態となっている。
ファックスアプリプロセス113は、FCSプロセス127をサーバプロセス202としたクライアントプロセス201となっている。FCSプロセス127は、ファクシミリ送信動作時にファックスアプリプロセス113をクライアントプロセス201としたサーバプロセス202となるとともに、ECSプロセス124およびFCUHプロセス129をサーバプロセス202としたクライアントプロセス201となる。
FCUHプロセス129は、FCSプロセス127のサブプロセスであり、ファクシミリ送信動作時に、SRMプロセス123およびFCS127をクライアントプロセス201としたサーバプロセス202となる。ECSプロセス124は、ファクシミリ送信動作時にFCSプロセス127をクライアントプロセス201としたサーバプロセス202となるとともに、MCSプロセス125およびSRMプロセス123をそれぞれサーバプロセス202としたクライアントプロセス201となる。
MCSプロセス125は、ファクシミリ送信動作時に、ECSプロセス124をクライアントプロセス201としたサーバプロセス202となるとともに、SRMプロセス123をサーバプロセス202としたクライアントプロセス201となる。SRMプロセス123は、ECSプロセス124およびMCSプロセス125をクライアントプロセス201としたサーバプロセス202となるとともに、FCUHプロセス129をサーバプロセス202としたクライアントプロセス201となる。
ファクシミリ送信要求があると、ファックスアプリプロセス113は、新たなファクシミリ送信ジョブを生成し、送信スタート要求メソッドを実行して、FCSプロセス127に対して送信スタート要求メッセージを送信する(ステップS701)。
FCSプロセス127は、ファックスアプリプロセス113から送信スタート要求メッセージを受信すると、送信スタート実行メソッドを実行する。この送信スタート実行メソッドは、ジョブ動作モード設定要求メソッドを実行してECSプロセス124に対してジョブ動作モード設定要求メッセージを送信する(ステップS702)。また、送信スタート実行メソッドはジョブスタート要求メソッドを実行してECSプロセス124に対してジョブスタート要求メッセージを送信する(ステップS703)。
なお、ジョブ動作モード設定要求メッセージおよびジョブスタート要求メッセージを受信したECSプロセス124の動作は、前述したスキャナ動作の場合と同様であるので説明を省略する。
ジョブスタート要求メッセージを受信してジョブ開始処理を行ったECSプロセス124は、ついでメモリ確保要求メソッドを実行して、MCS125に対しメモリ確保要求メッセージを送信する(ステップS704)。このメモリ確保要求メッセージを受信したMCSプロセス125は、メモリ取得要求メソッドを実行してメモリ取得要求メッセージをSRMプロセス123に対して送信する(ステップS705)。
また、ECSプロセス124は、スキャナエンジンおよびファクシミリエンジンの獲得のため、資源獲得要求メソッドを実行して、SRMプロセス123に対し資源獲得要求メッセージを送信する(ステップS706)。
なお、これらのメッセージを受信したMCSプロセス125、SRMプロセス123の処理およびECSプロセス124における処理は、コピー動作時の処理と同様であるので説明を省略する。
ECSプロセス124では、スキャナエンジンの資源獲得の実行結果メッセージを受信したら、スキャンパラメータ確定要求メソッドを実行して、FCSプロセス127に対しスキャンパラメータ確定要求メッセージを送信する(ステップS707)。
ここで、スキャンパラメータとは、たとえばファイン、ノーマルなどのスキャン濃度や原稿サイズ等である。FCSプロセス127は、このスキャンパラメータ確定要求メッセージを受信すると、スキャンパラメータ確定実行メソッドを実行して、ECSプロセス124に対してスキャンパラメータをメッセージとして送信する(ステップS708)。
ECSプロセス124では、スキャンパラメータメッセージを受信すると、SRMプロセス123に対してスキャン・フィードインプロセスの生成を指示するため、スキャン・フィードインプロセス指示メソッドを実行してスキャン・フィードインプロセス指示メッセージを送信する(ステップS709)。
SRMプロセス123は、スキャン・フィードインプロセス指示メッセージを受信すると、スキャン・フィードインプロセス実行メソッドを実行して、スキャン・フィードインプロセスを生成する(ステップS710)。ついでフィードインスタート要求メソッドを実行して、FCUHプロセス129に対して原稿のフィードインスタート要求メッセージを送信する(ステップS711)。FCUHプロセス129がフィードインスタート要求メッセージを受信すると、原稿フィードインが開始され、これにより原稿のスキャンおよび指定宛先への送信が開始される。
原稿のスキャンが開始されると、次ページの原稿があるか否かを示す、次ページ原稿有無通知メッセージがスキャナエンジンからECSプロセス124に対して送信される。図7では、次ページ原稿有通知メッセージが通知されている(ステップS712)。そして、原稿のスキャンが終了すると、スキャナエンジンからECSプロセス124に対してスキャン終了メッセージが送信される(ステップS713)。
ECSプロセス124は、受信したスキャン終了メッセージを次ページ原稿有の旨とともにFCSプロセス127へ送信する(ステップS714)。一方、原稿スキャンが終了すると、SRMプロセス123はフィードイン終了要求メソッドを実行し、FCUHプロセス129に対してフィードイン終了を指示して(ステップS715)、原稿フィードインを終了させる。
ユーザの指示などにより、ファックスアプリプロセス113が送信モード変更要求メソッドを実行して、FCSプロセス127に対して送信モード変更要求メッセージを送信した場合は(ステップS716)、ECSプロセス124は、スキャンパラメータ確定要求メソッドを実行して、スキャンパラメータ確定要求メッセージをFCSプロセス127に対して送信する。これに対し上述のようにFCSプロセス127は、スキャンパラメータメッセージをECSプロセス124に送信する(ステップS718)。
ECSプロセス124は、スキャンパラメータメッセージを受信すると、スキャン・フィードインプロセス指示メソッドを実行し、次ページ目のスキャン・フィードインプロセスの実行をSRMプロセス123に指示してスキャン・フィードインプロセスを開始する(ステップS719、S720)。
一方、1ページの指定宛先へのファクシミリ送信が完了すると、FCSプロセス127は、EOMメッセージ(異なる送信モードで次ページ有り)をFCUHプロセス129へ送信し(ステップS721)、これを受信したFCUHプロセス129はEOMを指定宛先へ送信する(ステップS722)。
FCUHプロセス129が指定宛先から受信正常の通知を受けた場合には(ステップS723)、SRMプロセス123に対して送信成功メッセージを送信し(ステップS724)、これを受信したSRMプロセス123がECSプロセス124に対してプロセス正常終了メッセージを送信する(ステップS725)。
さらに、プロセス正常終了メッセージを受信したECSプロセス124は、スキャン処理完了通知メソッドを実行して、FCSプロセス127に対し1ページ目のスキャン処理完了通知メッセージを送信する(ステップS726)。
そして、送信成功メッセージを受信したSRMプロセス123は、スタンプ実行要求メソッドを実行して、送信日時、発信元等のスタンプを指定宛先へ送信する旨をスキャナエンジンに指示する(ステップS727)。
SRMプロセス123は、2ページ目の原稿のフィードインを開始するため、フィードインスタート要求メソッドを実行し、FCUHプロセス129に対して原稿のフィードインスタート要求メッセージを送信する(ステップS728)。FCUHプロセス129はフィードインスタート要求メッセージを受信して、原稿フィードインが開始され、これにより2ページ目の原稿のスキャンおよび指定宛先への送信が開始する。
原稿のスキャンが開始されると、次ページ原稿有無通知メッセージがスキャナエンジンからECSプロセス124に対して送信される。、図7では、次ページ原稿無通知メッセージが通知され、ECSプロセス124に通知されている(ステップS729)。そして、原稿のスキャンが終了すると、スキャナエンジンからECSプロセス124に対してスキャン終了メッセージが送信される(ステップS730)。
ECSプロセス124は、受信したスキャン終了メッセージを次ページ原稿無の旨とともにFCSプロセス127へ送信する(ステップS731)。一方、スキャンが終了すると、SRMプロセス123はフィードイン終了要求メソッドを実行して、FCUHプロセス129に対してフィードイン終了メッセージを送信し(ステップS732)、これにより原稿フィードインを終了させる。
2ページの指定宛先へのファクシミリ送信が完了すると、FCSプロセス127はEOPメッセージ(次ページ無し)をFCUHプロセス129へ送信し(ステップS733)、これを受信したFCUHプロセス129がEOPを指定宛先へ送信する(ステップS734)。
指定宛先から受信正常の通知を受けた場合(ステップS735)、FCUHプロセス129はSRMプロセス123に対して送信成功メッセージを送信し(ステップS736)、これを受信したSRMプロセス123が、ECSプロセス124に対してプロセス正常終了メッセージを送信する(ステップS737)。
さらにプロセス正常終了メッセージを受信したECSプロセス124は、FCSプロセス127に対し2ページ目のスキャン処理完了通知メッセージを送信する(ステップS738)。また、送信成功メッセージを受信したSRMプロセス123は、スタンプ実行要求メソッドを実行して、送信日時、発信元等のスタンプの指定宛先へ送信の指示を行う(ステップS739)。そして、ECSプロセス124は、ジョブエンド通知メソッドを実行して、FCSプロセス127にジョブエンド通知メッセージを送信する(ステップS740)。FCSプロセス127は、このジョブエンド通知メッセージを受信することにより全ての原稿のファクシミリ送信動作を完了する。
このように実施の形態1の複合機100では、各アプリプロセスなどクライアントプロセス201となるプロセスが、ECSプロセス124、MCSプロセス125、SRMプロセス123などのサーバプロセス202となるプロセスに対し、メソッド実行によるメッセージ送信を行ってサービスの要求を行い、サーバプロセス202がメソッド実行によりサービスの提供および実行結果メッセージのクライアントプロセス201に対する送信を行うことでプロセス間通信を実現しているので、アプリケーション130とプラットホーム120という特殊な構成を有する複合機100において、簡易な手法によって多種多様なユーザサービスの機能を提供することができる。
また、各アプリケーション130,各コントロールサービスおよびSRM123のそれぞれはメソッドを有するオブジェクトである。したがって、アプリケーション130やコントロールサービスの一部のモジュールにのみ変更がある場合や、必要に応じてコントロールサービス、アプリケーション130を適宜、追加したとしても、サーバプロセス202となるモジュール側でメッセージを受信したときにサービス処理を実行するメソッドを実装し、クライアントプロセス201となるモジュール側でサービス要求メッセージを送信するメソッドを実装するというインタフェースを確保しておけば、サービスやデータの授受が可能となるため、各アプリや各コントロールサービスの追加または変更などのソフトウェア開発効率を向上させることができ、画像形成装置を可変性を持った構成とすることができる。
さらに、各コントロールサービスのそれぞれは、メソッドを有するオブジェクトであるため、各オブジェクトのデータの隠蔽を図ることができ、アプリケーション130の開発をサードベンダなどの外部に委託した場合でも、コントロールサービスの内容の隠蔽した状態とすることができる。
(実施の形態2)
実施の形態1にかかる複合機100では、サーバプロセスとクライアントプロセスとの関係を概念的に説明した。そこで、この実施の形態2では、サーバプロセスおよびクライアントプロセスをより具体的に説明する。なお、実施の形態2にかかる複合機100の構成は、図1と同様であるため説明を省略する。
図8は、実施の形態2の複合機100上で動作するサーバプロセスとクライアントプロセスの関係を詳細に示すブロック図である。ここで、クライアントプロセス1600は、サーバプロセス1610,1620に対して要求を行うことにより、サーバプロセス1610,1620からサービスの提供を受ける例えばSCS122などのプロセスをいう。
また、サーバプロセス1610,1620は、クライアントプロセス1600からの要求によりクライアントプロセス1600に対しサービスを提供する例えばECS124などのプロセスをいう。
図8に示すとおり、クライアントプロセス1600には複数のスレッド1601が起動している。クライアントプロセス1600は、複数のスレッド1601を有していることから、複数のサーバプロセス1610,1620に対して同時にサービスを要求できる。
また、クライアントプロセス1600は、サーバプロセス1610,1620のサービスを要求するために、スレッド1601からサーバプロセス1610,1620に対して関数コールを行い、その関数戻り値を受信することによってプロセス間通信を行う。
クライアントプロセス1600のスレッド1601は、あらかじめサーバプロセス1610,1620から提供されている関数をコールする。関数は、クライアントスタブ1602に定義されている。また、クライアントディスパッチャ1603は関数戻り値の受信を監視するスレッドである。
クライアントプロセス1600は、サーバプロセス1610,1620ごとにクライアントディスパッチャ1603を起動してサーバプロセス1610,1620と通信する。そして、関数コールを受けたサーバプロセス1610,1620は要求された関数に対応する処理を以下のように実行する。
例えばサーバプロセス1610のサーバディスパッチャ1611は、サーバスケルトン1612にコーディングされている複数のスレッド1613から、要求された関数に対応するスレッド1613を選択する。ここで選択されるスレッド1613は、実施の形態1で説明した関数ハンドラ403に相当する。サーバプロセス1610のスレッド1613は、要求された処理を実行してその実行結果を関数戻り値としてクライアントプロセス1600に送信する。
次に、実施の形態2にかかるクライアントプロセス1600と、サーバプロセス1610,1620とを生成する生成方法について説明する。図9は、実施の形態2のクライアントプロセスとサーバプロセスとを生成する画像形成装置用通信プログラム生成装置(以下、「スタブジェネレータ」という。)の機能的構成を示すブロック図である。スタブジェネレータは、メッセージファイルからヘッダと、クライアントスタブと、サーバスケルトンを自動生成するものである。
図9に示すように、スタブジェネレータは、メッセージファイル1701を入力する入力部1702と、メッセージファイル1701に記述された内容の構文チェックを行う構文解析部1703と、メッセージファイル1701の記述内容から、ヘッダ1706とクライアントスタブ1707と、サーバスケルトン1705とを生成してハードディスク等の記憶媒体に格納するコード生成部1704とを備えている。
まず、スタブジェネレータに入力されるメッセージファイル1701と、スタブジェネレータで生成されるヘッダ1706、クライアントスタブ1707およびサーバスケルトン1705について説明する。
メッセージファイル1701は、プロセス間通信の通信内容をC言語などのソースコードで記述したソースファイルである。図10は、メッセージファイルの記述例を示す説明図である。図10に示すように、メッセージファイル1701には、別のメッセージファイルや、C言語記述のインクルードヘッダを宣言するインクルード宣言と、サーバプロセスとクライアントプロセスの間で送受信するメッセージを記述したメッセージ記述と、クライアントプロセスからサーバプロセスに対して発行する関数の宣言などが記述されている。
メッセージは、主としてサーバプロセスとクライアントプロセスとの間でイベ
ントや通知を行う際に発行するものであり、メッセージファイル1701のメッセージ記述としては、メッセージ名と、メッセージIDと、メッセージ方向、メッセージ内容を記述するようになっている。
メッセージ方向には、「IN」、「OUT」、「SELF」がある。「IN」は、クライアントプロセスからサーバプロセスに対して送信するメッセージを意味する。「OUT」は、サーバプロセスからクライアントプロセスに対して送信するメッセージを意味する。また、「SELF」は自分自身のプロセスに対して送信するメッセージを意味する。
関数は、クライアントプロセスからサーバプロセスに処理要求や設定要求を行
う際に発行するものである。メッセージファイル1701の関数宣言には、関数名と、関数の型と、引数のみを記述し、関数の処理内容は記述しないようになっている。
クライアントスタブ1707は、クライアントプログラムから呼び出される関数のサーバプロセスに対する発行を記述したソースファイルである。クライアントスタブ1707をコンパイルしてライブラリ化し、クライアントプログラムとリンクすることにより、クライアントプログラムからの関数コールがクライアントスタブ1707を介してサーバプロセスへ発行されるようになっている。
図11はスタブジェネレータにより生成されるクライアントスタブ1707の一例を示す説明図である。図11に示すように、クライアントスタブ1707には、後述するサーバスケルトン1705に登録された関数ハンドラを呼び出すことにより、関数コールが行われるようになっている。サーバスケルトン1705は、クライアントスタブ1707から呼び出された関数ハンドラとメッセージハンドラを登録したソースファイルである。
図12は、スタブジェネレータにより生成されるサーバスケルトン1705の一例を示す説明図である。図12に示すように、サーバスケルトン1705にはクライアントスタブ1707に記述された関数に対応した関数ハンドラが登録されている。
関数ハンドラでは引数の受け渡し部のみが記述され、処理内容を記述する実装記述部は空欄の状態で生成されている。この実装記述部には、クライアントプログラムからクライアントスタブ1707を介して発行される関数の処理内容を、サーバプログラムの開発者が自在に記述できるようになっている。ヘッダ1706は、サーバスケルトン1705とクライアントスタブ1707で共通の定義、宣言などを記述したソースファイルである。
図13はスタブジェネレータにより生成されるヘッダ1706の一例を示す説明図である。図13に示すように、ヘッダ1706には、メッセージファイル1701に記述されたインクルード宣言、メッセージID、メッセージの構造体などのメッセージ宣言、関数宣言および関数ハンドラ宣言などが記述された状態で生成されるようになっている。
次に、スタブジェネレータによるサーバスケルトン1705、クライアントスタブ1707およびヘッダ1706の生成処理について説明する。図14は、サーバスケルトン、クライアントスタブおよびヘッダの生成処理のフローチャートである。
スタブジェネレータの構文解析部1703は、メッセージファイル1701に記述された関数宣言、メッセージ定義、インクルード宣言、C言語記述の文法チェックを行い(ステップS1801)、さらにメッセージファイル1701に定義されている関数名およびメッセージ定義の中のメッセージID、メッセージ名の一意性の判断を行う(ステップS1802)。
そして、関数宣言、メッセージ定義、インクルード宣言の記述に文法エラーがあった場合、あるいは関数名、メッセージID、メッセージ名のいずれかが重複している場合には、ユーザに構文エラーである旨のメッセージを通知し処理を終了する(ステップS1803、S1804)。
構文解析後、コード生成部1704は、メッセージファイル1701の記述内容から、ヘッダ1706と、サーバスケルトン1705と、クライアントスタブ1707を生成する。具体的には、メッセージファイル1701のインクルード宣言とC言語記述とをヘッダ1706にそのまま転記し、メッセージファイル1701のメッセージ定義に記述されているメッセージ構造体をヘッダ1706にコピーする(ステップS1805)。
また、コード生成部1704は、メッセージファイル1701の関数宣言から関数ハンドラ名を自動生成し(例えば、関数名abcの場合、関数ハンドラ名をabc_handlerとして生成する)、生成された関数ハンドラ名をサーバスケルトン1705内に登録する。
そして、関数ハンドラの処理内に、引数受け渡しの記述を行うとともに、戻り値領域の生成システムコールの発行を記述する。関数ハンドラの実際の処理内容を記述する実装記述部の欄を空欄とし、その実装記述部の後に、戻り値送信と戻り値領域解放の各システムコールの発行を記述する(ステップS1806)。
また、コード生成部1704は、メッセージファイル1701に記述された関数宣言ごとに、関数名と引数の記述をクライアントスタブ1707に登録し、その関数の処理内に、関数コールメッセージ生成コールと関数ハンドラの呼び出しと戻り値解放の各システムコールを記述する(ステップS1807)。なお、関数ハンドラ呼び出しには、発行した関数の戻り値の待ち受ける関数戻り値待ちシステムコールが内部的に発行されるようになっている。
このようにスタブジェネレータにより、クライアントスタブ1707とサーバスケルトン1705とヘッダ1706を生成したら、次にサーバオブジェクトおよびクライアントオブジェクトを完成させる。
サーバプログラムの開発者は、サーバスケルトン1705の関数ハンドラの実装記述部(空欄)に、関数ハンドラで行うべき処理内容をエディタなどを利用して記述し、サーバスケルトン1705をヘッダ1706とともにコンパイルしてサーバスタブオブジェクトを生成する。また、サーバスケルトン1705に登録した関数ハンドラを宣言するとともに、クライアントプロセスとの間でメッセージファイル1701に記述されたメッセージの送受信を行うメッセージハンドラ、エラー処理を行うエラーハンドラ、サーバの初期化、サーバディスパッチャ起動等のシステムコールの発行を記述したサーバソースファイルを作成してコンパイルし、サーバスタブオブジェクトとリンクして、サーバプログラムを完成させる。
一方、クライアントスタブ1707はヘッダ1706とともにコンパイルしてクライアントスタブオブジェクトを生成する。サーバプロセスごとにクライアントスタブオブジェクトを生成し、生成した複数のクライアントスタブオブジェクトをライブラリとする。
また、関数の発行、関数ハンドラの宣言、エラー処理を行うエラーハンドラの宣言、クライアントプロセスとの間でメッセージファイル1701に記述されたメッセージの送受信を行うメッセージハンドラ、およびクライアントプロセスの初期化やクライアントディスパッチャ起動等のシステムコールの発行を記述したクライアントプログラムを作成してコンパイルし、スタブのライブラリとリンクすることによりクライアントプログラムを完成させる。
図15は、クライアントプログラムから関数コールを行った場合におけるサーバプログラムとの呼び出しおよび応答のシーケンスを示す説明図である。なお、サーバプログラムとクライアントプログラムは実際は実行可能形式のオブジェクトファイルであるが、図15では、説明の都合上いずれもソースコードで表示している。
クライアントプログラムからサーバプログラムに対して、たとえばOpen関数をコールすると、クライアントスタブオブジェクトで定義されたOpenが呼び出される(ステップS1901)。そして、このスタブのOpenの処理の中で、Openの関数ハンドラOpen_handlerがサーバプログラムに対してコールされる(ステップS1902)。
サーバプログラムでは、クライアントスタブオブジェクトから関数ハンドラOpen_handlerの発行を受け取って、サーバスタブオブジェクトに登録されているOpen_handlerの実装記述部に記述されている処理を実行し(ステップS1903)、その実行結果をクライアントスタブへ戻り値として返す(ステップS1904)。クライアントプログラムでは、この戻り値をクライアントスタブから受け取って(ステップS1905)、次の処理へ移行する。
このように実施の形態2のスタブジェネレータでは、メッセージファイル1701に関数宣言を記述することによりクライアントスタブ1707とサーバスケルトン1705を容易に生成することができる。しかも生成されるサーバスケルトン1705の実装記述部は空欄となっているので、プログラム開発者は必要に応じて関数の処理内容を容易に変更するができる。
このため複合機100に可変性をもたせることができるとともに、多種多様な機能を実現させることができる。さらに、サードベンダーなどの他社がクライアントプログラムの開発を行う場合でも、クライアントプログラムには提供される関数コールを記述するだけでプロセス間通信が可能となるので、内部の通信プロトコルの隠蔽性を保つことが可能となる。
また、実施の形態2のスタブジェネレータでは、プロセス間通信を関数コールで実現しているので、ジョブの並列実行をスレッドで実現した場合でも、高速なプロセス間通信が可能となる。また、関数からの戻り値によってスレッド間の同期をとることができるので、同期のための処理プログラムを別途作成する必要がなくなり、プログラム開発の労力を低減することができる。
(実施の形態3)
実施の形態1にかかる複合機100では、オブジェクトのメソッドを利用したプロセス間通信を行うものであったが、この実施の形態3にかかる複合機100は、さらにエージェントの機能を利用したものである。
図16は、実施の形態3にかかる複合機の構成を示すブロック図である。図16に示すように、実施の形態3の複合機100は、エージェントアプリ117をアプリケーション層に備えている点が実施の形態1の複合機100と異なる。このため、他の構成については説明を省略する。なお、実施の形態3にかかる複合機100はネットワークインタフェース106によってLANなどのネットワークに接続された状態となっている。
エージェントアプリ117は、ネットワークを介して受信したエージェントの内容を解釈して実行するアプリケーションであり、本発明におけるエージェント処理手段を構成する。ここで、エージェントとは、ユーザに代行して自らの環境を自律的に判断して能動的に動作したり、ネットワークを通じて移動するプログラムである。
エージェントを用いることで、ネットワークの負荷を軽減したり、ネットワークを常に占有する必要がなくなる。また、連続的な処理を効率的に行うことができる。なお、エージェントの動作および利点については、以下に示す例で詳細に説明する。また、エージェントアプリ117としては、例えば、telescriptコマンドを解釈することができるtelescriptエンジンなどを用いることができる。
具体的には、エージェントアプリ117は、ネットワークに接続された他の複合機やPCから送信されてきたエージェントをNCS128を介して受信し、その内容に一または複数のサービス要求が含まれている場合、その内容から要求のあったサービスごとに必要なコントロールサービスやアプリケーション130を判断して選定し、選定されたコントロールサービスやアプリケーション130に対してサービス要求を行う。
また、エージェントアプリ117は、受信したエージェントに含まれるサービス要求に必要なコントロールサービスやアプリケーション130が自己の複合機100内部で正常に動作しているか否かを判断し、正常動作していない場合(存在しない場合も含む)には、ネットワーク上の他の複合機100を自律的に検索して、当該他の複合機100にエージェントを送信する。
エージェントを受信した他の複合機100は、エージェントアプリ117によって、サービスごとに必要なコントロールサービスやアプリケーション130の選定とサービス要求、および必要なコントロールサービスやアプリケーション130の正常動作の調査を行う。このため、サービスに必要なコントロールサービスやアプリケーション130が正常動作していない限り、エージェントはネットワーク内の複合機を順に移動していく。
ここで、サービス要求に必要なモジュールとは、例えばプリント要求についてはプリンタアプリ111、ECS124、MCS125およびSRM123であり、ファクシミリ送信要求についてはファックスアプリ113、FCS127、ECS124、MCS125およびSRM123である。
次に、実施の形態3にかかる複合機100によるエージェント機能を利用したプロセス間通信について説明する。なお、実施の形態3にかかる複合機100において、複合機100内部で動作するプロセス間の通信は、実施の形態1の複合機100と同様に、オブジェクトのメソッド実行によるメッセージ送信によって実現されている。
図17は、このエージェント機能を複合機に適用した場合のユーザのPCと複合機のやりとりの例を示す模式図である。図19は、複合機100aにおけるプロセス間通信の流れを示す説明図である。ここでは、LANなどのネットワーク901にPC900および複数の複合機100a,100b,100cが接続されているものとする。また、各複合機100a,100b,100cは図16に示した構成を有するものとする。
また、PC900はエージェントの送信を行うエージェントエンジン902が搭載されている。なお、複合機100a,100b,100cは、エージェントアプリ117がエージェントエンジン902に相当する。
図17に示すように、PC900のエージェントエンジン902によって、エージェントが複合機100aに対して送信される。このエージェントには、複数のサービス要求を記述することができる。このように複数のサービス要求が記述されたエージェントは、エージェントを受信する複合機(あるいは、さらにネットワーク上の他の複合機にエージェントが移動した場合には、その移動先の複合機)に対し、記述された複数のサービス要求を連続的に実行させることを指示している。
図17の例では、「ファイル転送 X to PC」および「プリント X」という2つのサービス要求がプログラム形式で一つのエージェントに記述されている。ここで、「ファイル転送 X to PC」は、複合機100aのHDD105に格納されているファイルXのPC900へのファイル転送要求を示している。また、「プリント X」は、ファイルXのプリント要求を示している。従って、図17に示す例のエージェントは、エージェントを受信する複合機に対して、「ファイルXをPC900にファイル転送し、次にファイルXをプリントする」ことを指示したものである。
複合機100aでは、PC900からのエージェントをNCS128で受信して(ステップS1101)、エージェントアプリ117へ送信する(ステップS1102)。
エージェントアプリ117は、受信したエージェントに記述されたサービス要求の内容から、まずファイル転送に必要なネットファイルアプリ115とMCS125を選定する。また、エージェントアプリ117は、受信したエージェントの内容から、プリント機能に必要なプリンタアプリ111とECS124とMCS125とSRM123とを選定する。
そして、エージェントアプリ117は、ファイル転送のためネットファイル115に対して、HDD105に格納されているファイルXをPC900にファイル転送する旨のサービス要求を行う(ステップS1103)。
ネットファイルアプリ115は、このサービス要求を受信すると、MCS125からHDD105にアクセスして(ステップS1104、S1105)、ファイルXを読み出し、メモリなどに一時的に格納しておく。ネットファイルアプリ115は、読み出しの実行結果をエージェントアプリ117に通知する(ステップS1111)。
また、エージェントアプリ117は、プリンタアプリ111に対して、読み出したファイルXをカラーラインプリンタ102または白黒プリンタ101でプリントする旨の要求を行う(ステップS1106)。
プリンタアプリ111は、このプリント要求を受信すると、実施の形態1でプリント動作で説明した手順で、ECS124、MCS125、SRM123間のプロセス間通信を行って(ステップS1107、S1108、S1109)、ファイルXをプリントする(ステップS1110)。そして、プリンタアプリ111は、エージェントアプリ117にプリント実行結果を通知する(ステップS1112)。
つぎに、エージェントアプリ117は、2つの実行結果を追加したエージェントとメモリに一時的に格納されているファイルXを、NCS128によってネットワーク上のPC900に送信する(ステップS1113,S1114)。
ここで、エージェントアプリ117を利用しなかった場合の処理について説明しておく。図18は、エージェント機能を利用しない場合のユーザのPCと複合機のやりとりの例を示す模式図である。
図18に示すように、エージェントアプリ117がない場合には、ユーザはPC900から「ファイルXのファイル転送」と「ファイルXのプリント」という2つの要求を別々に複合機100aに送信しなければならない。また、各要求に対する応答も別個に受信されることになる。このため、効率的なサービスの提供を受けられないばかりか、ネットワークにアクセスする回数も4回と多くなってしまう。
これに対し、図17に示すようにエージェントを利用した場合には、PC900のユーザは「ファイルXのファイル転送とプリント」という2つの要求を一つのエージェントで行えば、エージェントアプリ117によって、必要なアプリ、コントロールサービスが自律的に判断されて各要求に対するサービスの提供を効率的に受けることができる。このため、ネットワークにアクセスする回数も、最初のサービス要求送信時と、最後の実行結果通知およびファイル転送時の2回だけですむので、ネットワークにかかる負荷も軽減する。
つぎに、エージェントを利用してネットワークに接続された複数の複合機の間でプロセス間通信を行う場合について説明する。図20は、エージェント機能を複数の複合機に適用した場合のユーザのPCと複合機のやりとりの例を示す模式図である。
図20に示すように、LANなどのネットワークにはPC900と複数の複合機100a,100b,100cが接続されている。複合機100a,100bおよび100cは、いずれも図16に示した構成を有しており、従ってエージェントアプリ117を備えている。また、PC900にはエージェントの送信を行うエージェントエンジン902が搭載されている。
図20に示すように、エージェントにはサービス要求コマンドが記述されている。このようにサービス要求コマンドが記述されたエージェントは、エージェントを受信した複合機で記述されているサービス要求コマンドのサービス要求が実行可能か否かを調べ、実行可能である場合にサービス要求を行い、実行不可能である場合にネットワークに接続された他の複合機にエージェントを移動(送信)させて、移動先の複合機でサービス要求が実行可能か否かを調べる旨を示したものである。
図20のエージェントの例では、サービス要求コマンドとして「ファクシミリ送信」が指定されているので、エージェントを受信した複合機100aで「ファクシミリ送信」が実行可能か否かを調べ、実行可能である場合には「ファクシミリ送信」のサービス要求を行い、実行不可能である場合にはネットワークに接続された他の複合機100b,100cなどにエージェントを送信して、移動先の複合機で複合機100aと同様に処理を行うことを指示している。
なお、図20のエージェントの例では、サービス要求コマンドを一つしか指定していないが、複数のサービス要求コマンド指定しても良い。この場合には、指定された複数のサービス要求コマンドに対して順次上記と同様の処理が行われることになる。
また、図20のエージェントの例では、サービス要求コマンドしか記述されておらず、この場合、サービス要求が実行できないと判断された場合に自律的にネットワーク内の他の複合機にエージェントが移動することを示しているが、エージェントにおいて、サービス要求コマンドの行の下に、さらに例えば「複合機100aのネットワークアドレス→複合機100bのネットワークアドレス→複合機100cのネットワークアドレス」などを記述して、ネットワーク内で移動する複合機およびエージェントが移動する順番を指定しても良い。
この場合には、複合機100aでサービス要求が実行できない場合に、エージェントが自律的に複合機100b、ついで複合機100cに移動することを示したこととなる。
なお、エージェントは、PC900のエージェントエンジン902によって、例えばtelescriptのGOコマンドを実行することにより複合機100aに送信される。
複合機100aはこのエージェントをNCS128で受信して、エージェントアプリ117へ送信する。エージェントを受信したエージェントアプリ117はエージェントの内容を解釈し、まずファクシミリ送信に必要なファックスアプリ113、FCS127、ECS124、MCS125およびSRM123の各プロセスが正常に動作しているか否かを調査する。
ここで、正常動作の調査は、たとえばエージェントアプリ117から各プロセスに対してアクセスし、アクセスに対する応答があった場合に正常動作していると判断するように構成すれば良い。
そして、ファックスアプリ113、FCS127、ECS124,MCS125およびSRM123のすべてが正常動作している場合は、これらのプロセスを選定し、ファックスアプリ113に対してファクシミリ送信要求を送信する。この場合は、実施の形態1で説明したファクシミリ送信動作の手順と同様の処理が行われる。
しかし、ファックスアプリ113、FCS127、ECS124,MCS125およびSRM123のいずれかが異常であると判断された場合は、次のような処理を行う。ここでは、ECSプロセス124が異常であった場合を考える。
このとき、エージェントアプリ117は、動作が異常であるプロセスのプロセス名と自己のネットワークアドレスなどの情報をエージェントに追加する。そして、ネットワーク901内の複合機を自律的に検索し、最初に発見された複合機(図12の例では複合機100b)にエージェントを送信する。
複合機100bでは、エージェントアプリ117によって複合機100aから送信されてきたエージェントを受信する。そして、複合機100aのエージェントアプリ117と同様にエージェントの内容を解釈し、ファクシミリ送信に必要なプロセスであって、かつエージェントに記述された、複合機100aで動作が異常なプロセスおよびそのプロセスから呼び出されるプロセスであるECS124、MCS125およびSRM123が正常に動作しているか否かを調査する。そして、ECS124、MCS125およびSRM123のいずれもが正常であれば、その旨のメッセージをエージェントに追加して複合機100aに対して送信する。
複合機100aのエージェントアプリ117は、複合機100bからのエージェントを受信すると、複合機100a内のファックスアプリ113とFCS127とを選定するとともに、ECS124、MCS125、SRM123については複合機100b内のものを選定する。これにより、ファクシミリ送信は、ECSプロセス124が正常に動作している複合機100bから行われる。
複合機100aでプロセスの選定が終了したら、ファクシミリ送信処理を次のように実行する。図22は、複合機100aおよび複合機100bにおけるプロセス間通信の流れを示すデータシーケンス図である。
複合機100aのエージェントアプリ117は、ファックス送信要求メッセージを、複合機100a内のファックスアプリ127に送信する(ステップS1400)。ファックスアプリ127は、ファックス送信要求メッセージを受信すると、送信スタート要求メソッドを実行して、FCSプロセス127に送信スタート要求メッセージを送信する(ステップS1401)。
複合機100aのFCSプロセス127がファックスアプリプロセス113から送信スタート要求メッセージを受信した場合には、送信スタートメソッドを実行して、ジョブ動作モード設定要求メッセージをエージェントに追加する。そして、エージェントアプリ117によって複合機100bのネットワークアドレスにエージェントを送信する(ステップS1402)。これにより、ジョブ動作モード設定メッセージは、エージェントによってネットワークアドレスで指定された複合機100bに送信される。
複合機100bでは、エージェントアプリ117によってエージェントを受信して、エージェントに記述されているジョブ動作モード設定要求メッセージをECSプロセス124に送信する(ステップS1403)。複合機100bのECSプロセス124は、ジョブ動作モード設定要求メッセージを受信すると、ジョブ動作モード設定メソッドを実行してプリンタジョブの動作モード設定を行い、実行結果メッセージをエージェントに追加してエージェントアプリ117によってエージェントを複合機100aに送信する(ステップS1404)。
複合機100aは、複合機100bからのエージェントをエージェントアプリ117で受信して、エージェントに記述されている実行結果メッセージをFCSプロセス127に送信する(ステップS1405)。FCSプロセス127は実行結果メッセージを受信すると、ジョブスタート要求メソッドを実行してジョブスタート要求メッセージをエージェントに追加する。そして、エージェントアプリ117によって複合機100bにエージェントを送信する(ステップS1406)。
複合機100bでは、エージェントアプリ117によってエージェントを受信して、エージェントに記述されているジョブスタート要求メッセージをECSプロセス124に送信する(ステップS1407)。複合機100bのECSプロセス124はジョブスタート要求メッセージを受信すると、ジョブスタートメソッドを実行して、プリンタジョブの開始処理を行い、その実行結果メッセージをエージェントに追加してエージェントアプリ117によってエージェントを複合機100aに送信する(ステップS1408)。
複合機100aでは、複合機100bからのエージェントをエージェントアプリ117で受信して、エージェントに記述されている実行結果メッセージをFCSプロセス127に送信する(ステップS1409)。
一方、複合機100bでは、ECSプロセス124がメモリ確保要求メソッドを実行して複合機100b内のMCSプロセス125に対してメモリ確保要求メッセージを送信する(ステップS1410)。また、スキャナエンジンの資源獲得のため、資源獲得要求メソッドを実行して、複合機100b内のSRMプロセス123に対して資源獲得要求メッセージを送信する(ステップS1411)。かかるメッセージの受信に対するMCSプロセス125およびSRMプロセス123の処理は、実施の形態1で説明した動作と同様であるため説明を省略する。 複合機100bのECSプロセス124は、資源獲得の実行結果メッセージを受信したら、スキャンパラメータ確定要求メソッドを実行してスキャンパラメータ確定要求メッセージをエージェントに追加して、エージェントアプリ117によってエージェントを複合機100aに送信する(ステップS1412)。
複合機100aでは、エージェントアプリ117によってエージェントを受信して、エージェントに記述されているスキャンパラメータ確定要求メッセージをFCSプロセス127に送信する(ステップS1413)。FCSプロセス127は、このスキャンパラメータ確定要求メッセージを受信すると、スキャンパラメータのメッセージをエージェントに追加して、エージェントアプリ117によってエージェントを複合機100bに送信する(ステップS1414)。複合機100bは、複合機100aから送信されたエージェントをエージェントアプリ117によって受信して、エージェントに記述されたスキャンパラメータメッセージをECSプロセス124に送信する(ステップS1415)。
これ以降のプロセス間通信は、同一複合機100bの内部で行われるものであり、実施の形態1で説明したファクシミリ送信動作と同様であるため説明を省略する。これにより、複合機100aにおけるファクシミリ送信スタート要求に対して、複合機100bでファクシミリ送信が行われることになる。
複合機100bにおけるスキャンおよびファクシミリ送信処理が終了すると、複合機100bのECSプロセス124は、スキャン終了通知メッセージをエージェントに追加し、エージェントアプリ117によってこのエージェントを複合機100aに送信する(ステップS1416)。複合機100aでは、このエージェントをエージェントアプリ117によって受信し、エージェントに記述されたスキャン終了通知メッセージをFCSプロセス127に送信する(ステップS1417)。
そして、複合機100aでは、エージェントアプリ117によってファクシミリ送信の実行結果をエージェントに追加して、このエージェントを複合機100bに送信する(ステップS1418)。複合機100bのエージェントアプリ117は、このエージェントを受信してPC900に転送する(ステップS1419)。エージェントがPC900で受信されることによって、ファクシミリ送信動作を完了する。
なお、この実施の形態3では、複合機100bにおいて必要なプロセスが正常動作している場合について説明したが、複合機100bでも必要なプロセスに異常があった場合には、エージェントアプリ117によってエージェントはネットワーク上の他の複合機、例えば複合機100cに送信され、上述の複合機100bにおける処理と同様の処理が行われる。
また、実施の形態3の複合機100a,100bでは、ECSプロセス124が正常動作していない場合を例にあげて説明したが、他のコントロールサービスあるいはアプリケーションのプロセスに異常があった場合あるいは存在しない場合も同様の処理が行われる。この場合、コントロールサービスは存在するが、エージェントアプリ117を除いたアプリケーションが存在しない複合機であってもよい。
ここで、エージェントアプリ117を利用しなかった場合の処理について説明しておく。図21は、エージェント機能を利用しない場合のユーザのPCから複合機100a,100bに対するファックス送信要求のやりとりの例を示す模式図である。
図21に示すように、ユーザがPC900から複合機100aに対して、(1)ファックス送信要求を行った場合で、ECS124など必要なプロセスが正常動作していない場合には、複合機100aからPC900に対して、(2)ファクス送信不可の応答メッセージが送信される。
このため、ユーザはPC900から別の複合機100bに対して、(3)ファックス送信要求を行う必要がある。複合機100bにおいてファックス送信に必要なプロセスがすべて正常動作している場合には、ファックス送信が行われ、複合機100bからPC900に対して、(4)完了通知が送信されてくるが、複合機100bでもファックス送信が不可能な場合にはユーザはさらに別の複合機に対してファックス送信要求を行う必要があり、ユーザの操作がきわめて煩雑なものとなる。また、ファックス送信要求を繰り返し行えば、それだけPC900と複合機100a,100b間のネットワーク901の占有が生じてしまい、ネットワーク負荷も過大なものとなる。
これに対し、図20に示す実施の形態3の複合機100aのようにエージェントとエージェントアプリ117を使用した場合には、PC900のユーザはファックス送信要求が記述された1つのエージェントを、複合機100aに対して1回だけ送信するだけで、たとえ複合機100aがファックス送信が不可能な状態であっても、上述のようにエージェントアプリ117が自律的にファックス送信可能な複合機をネットワーク内で自律的に検索して、検索された複合機100bによってファックス送信を行うようになっているので、多種多様な複合機のサービスをユーザに効率的に提供することができる。
また、PC900と複合機100a,100b間のネットワークのアクセス回数も、最初のサービス要求送信時と、最後の完了通知の2回だけですむので、ネットワークにかかる負荷も軽減することとなる。
なお、実施の形態3の複合機100a,100bでは、本発明のエージェント処理手段としてエージェントアプリ117を設けているが、エージェント処理手段に相当するプロセスを、アプリケーション層ではなくコントロールサービス層に設けても良い。この場合、既存のコントロールサービスとは別個に、例えばエージェントコントロールサービスを設けてエージェント処理手段を構成する他、例えば、SCS122などの既存のコントロールサービスのプロセスにエージェント処理を行うスレッドを設ける構成としてもよい。
また、実施の形態3において、図17および図20で示したエージェントの内容は、一例を示すものであり、複合機100の構成および機能、またはネットワーク901の構成などにより任意に記述することが可能である。また、エージェントの記述形式も、実施の形態3のエージェント例に限定されるものではなく、PC900のエージェントエンジン902やエージェントアプリ117の種類によって任意の形式とすることが可能である。
本発明は、具体的に開示された実施の形態に限定されるものでなく、本発明の範囲内で種々の変形や変更が可能である。