(57)【要約】【課題】可変性のあるアーキテクチャおよび多種多様な機能を実現できる情報処理装置を得ることを目的とする。【解決手段】情報処理を行う一または複数のプログラムとを有する情報処理装置であって、プログラムのそれぞれは、サーバプロセス２０２またはクライアントプロセス２０１として動作するプロセスであり、サーバプロセス２０２のスレッドは、クライアントプロセス２０１のスレッドに提供する一または複数のサービスを定義した関数を有しており、クライアントプロセス２０１のスレッドは、サーバプロセス２０２のスレッドにサービスの提供を要求する際に関数呼び出しを行うことにより上記課題を解決する。【選択図】図２
2006139776.tif 000002
【特許請求の範囲】
【請求項１】
情報処理を行う一または複数のプログラムを有する情報処理装置であって、
前記プログラムのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、
前記サーバプロセスのスレッドは、前記クライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数を有しており、
前記クライアントプロセスのスレッドは、前記サーバプロセスのスレッドにサービスの提供を要求する際に関数呼び出しを行うことを特徴とする情報処理装置。
【請求項２】
前記プログラムは、前記サーバプロセスへの関数呼び出しに対する関数戻り値を受信すると、受信した関数戻り値を前記関数呼び出しを行ったスレッドに受け渡すクライアント監視手段を備えたことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記クライアント監視手段は、スレッドで実現されることを特徴とする請求項２記載の情報処理装置。
【請求項４】
前記クライアント監視手段は、関数の呼び出し後に関数戻り値待ち状態のスレッドの識別子を一時的に格納する関数戻り待ちキューをさらに備え、前記サーバプロセスから前記関数戻り値を受信したときに、受信した関数戻り値を、前記関数戻り待ちキューに格納された識別子の前記スレッドに送信することを特徴とする請求項２又は３記載の情報処理装置。
【請求項５】
前記サーバプロセスおよび前記クライアントプロセスは、さらにイベントまたは通知に関するメッセージの送信，受信または送受信の何れかを行うことを特徴とする請求項２乃至４いずれか一項記載の情報処理装置。
【請求項６】
前記クライアント監視手段は、さらにサーバプロセスからのメッセージの受信を監視するものであることを特徴とする請求項５記載の情報処理装置。
【請求項７】
前記クライアント監視手段は、受信したメッセージに基づいた処理を実行するメッセージハンドラをさらに備えたことを特徴とする請求項６記載の情報処理装置。
【請求項８】
前記サーバプロセスは、前記クライアントプロセスからの関数呼び出しを監視するサーバ監視手段を備えたことを特徴とする請求項１乃至７いずれか一項記載の情報処理装置。
【請求項９】
前記サーバ監視手段は、複数のクライアントプロセスからの関数呼び出しを監視することを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記サーバ監視手段は、前記クライアントプロセスから関数呼び出しを受信したときに、呼び出された関数に対応した処理を実行する関数ハンドラを備えたことを特徴とする請求項８又は９記載の情報処理装置。
【請求項１１】
前記サーバ監視手段は、さらに前記クライアントプロセスからのメッセージの受信を監視することを特徴とする請求項８乃至１０いずれか一項記載の情報処理装置。
【請求項１２】
前記サーバ監視手段は、前記クライアントプロセスから受信したメッセージに基づいた処理を実行するメッセージハンドラをさらに備えたことを特徴とする請求項１１記載の情報処理装置。
【請求項１３】
情報処理を行う一または複数のプログラムとを有する情報処理装置であって、
前記プログラムのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、
前記サーバプロセスは、ネットワークに接続された他の情報処理装置で動作するクライアントプロセスに対するサーバプロセスとして動作し、サーバプロセスのスレッドとして前記他の情報処理装置のクライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数を有していることを特徴とする情報処理装置。
【請求項１４】
前記サーバプロセスが備える一または複数のスレッドは、前記他の情報処理装置のクライアントプロセスのスレッドに提供するサービスを実行することを特徴とする請求項１３記載の情報処理装置。
【請求項１５】
前記サーバプロセスは、前記他の情報処理装置のクライアントプロセスからの関数呼び出しを監視するサーバ監視手段を備えたことを特徴とする請求項１３又は１４記載の情報処理装置。
【請求項１６】
前記サーバ監視手段は、さらに前記他の情報処理装置のクライアントプロセスからのメッセージの受信を監視することを特徴とする請求項１５記載の情報処理装置。
【請求項１７】
前記サーバプロセスは、さらに前記他の情報処理装置のクライアントプロセスに対しメッセージを送信することを特徴とする請求項１３乃至１６いずれか一項記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に係り、特に複数のプロセスがプロセス間通信を行う情報処理装置に関する。
【背景技術】
【０００２】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置（以下、「複合機」という。）が一般的に知られている。この複合機は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応する３種類のソフトウェアを設け、ソフトウェアの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
従来の複合機では、内部にプリンタ、コピー、スキャナおよびファクシミリ装置に対応するソフトウェア（汎用ＯＳを含む）をそれぞれ別個に設ける構成となっており、各ソフトウェアの開発に多大の時間を要する。
【０００４】
このため、出願人は、ハードウェア・インターフェースをドライブするドライバと呼ばれるソフトウェア群と、メモリ／タイマなどの共通なハードウェア資産を効率良く使用するためのマネージャ・ソフトウェア群や各アプリケーションで共通に使用できるシステム・ユーティリティ・ソフトウェア群と、これらのドライバ・ソフトウェア群，マネージャ・ソフトウェア群，ユーティリティ・ソフトウェア群を使用するプリンタ／スキャナ／ＦＡＸ送信／ＦＡＸ受信などの実アプリケーションとを備えた複合機（例えば特許文献１又は特許文献２参照）を発明した。
【０００５】
しかしながら、特許文献１及び特許文献２に記載されている複合機は、ドライバ・ソフトウェア群，マネージャ・ソフトウェア群，ユーティリティ・ソフトウェア群がライブラリで構成されており、ハードウェア資源を実行制御する主体となり得なかった。
【０００６】
そこで、出願人は、表示部、印刷部および撮像部などの画像形成処理で使用されるハードウェア資源を有し、プリンタ、コピーまたはファクシミリなどの各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、これらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットホームを備えた複合機（例えば特許文献３参照）を発明した。
【０００７】
なお、ユーザサービスとはユーザに提供する画像形成に係るサービスをいう。また、コントロールサービスとはアプリケーションに画像形成に係るハードウェア資源を提供するサービスをいう。
【０００８】
この複合機によれば、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行うプラットホームを備えた構成とすることによって、ソフトウェア開発の効率化を図るとともに、装置全体としての生産性を向上させることが可能となる。
【特許文献１】特開平９−５１３９８号公報
【特許文献２】特開平９−９１１０２号公報
【特許文献３】特開２００２−８２８０６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
このような複合機では、アプリケーションの少なくとも２つが共通的に必要とするサービスを提供するコントロールサービスを有する構成となっているため、機能変更、機能追加、または将来的なハードウェア資源の追加、変更などに柔軟に対応すべく、アプリケーションごとあるいはコントロールサービスごとの追加、変更を容易に行えることが望まれる。また、複合サービスを提供する際に、各アプリケーションと各コントロールサービス間、あるいは各コントロールサービス間でサービスやデータの授受を円滑に行うことが必要となってくる。
【００１０】
すなわち、複合機は、プリンタ、コピー、ファクシミリ、スキャナなど多種の機能を備えたものであるが、その一部の機能に故障あるいは仕様変更などが生じた場合に、全てのアプリケーションまたは全てのコントロールサービスのモジュールを修正しなければならないと、作業の労力が過大となる。
【００１１】
また、将来的に、複合機に新たな機能を追加する場合でも一部の機能の追加のために全てのコントロールサービスや全てのアプリケーションのモジュール変更が必要となると、プログラム開発の労力が過大となってしまう。このため、複合機上で動作する各アプリケーションやコントロールサービスのモジュールは互いにサービスやデータの送受信を実現としながらも、モジュール間の独立性を維持していることが必要となってくる。
【００１２】
すなわち、アプリケーションや各コントロールサービスごとに独立性がないと、必要なアプリケーションや必要なコントロールサービスのみを提供することが困難となり、機能変更や機能追加などに柔軟に対応できるような複合機の構成に可変性を持たせることができない。
【００１３】
また、各アプリケーションや各コントロールサービスごとに独立性がないと、アプリケーションやコントロールサービスごとの設計および構築が困難になり、多種多様な機能を提供することができない。
【００１４】
この発明は上記に鑑みてなされたもので、可変性のあるアーキテクチャおよび多種多様な機能を実現できる情報処理装置を得ることを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するため、本発明は、情報処理を行う一または複数のプログラムを有する情報処理装置であって、前記プログラムのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、前記サーバプロセスのスレッドは、前記クライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数を有しており、前記クライアントプロセスのスレッドは、前記サーバプロセスのスレッドにサービスの提供を要求する際に関数呼び出しを行うことを特徴とする。
【００１６】
この本発明によれば、一または複数のプログラムの相互間で、関数呼び出しによるプロセス間通信を実現することができる。このため、各プログラムの間の独立性を維持しながら互いにサービスやデータの授受をプロセス間通信によって実現することができ、機能的に多様性のある情報処理装置を提供することができる。
【００１７】
また、プログラムの一部のモジュールにのみ変更がある場合や、必要に応じてプログラムを追加する場合でも、サーバプロセスとなるモジュール側で関数を実装し、クライアントプロセスとなるモジュール側で関数呼び出しを行うというインタフェースを確保しておけば、サービスやデータの授受が可能となる。
【００１８】
このため、プログラムの追加または変更を容易に実現することができ、可変性を持った情報処理装置を構成することができる。
【００１９】
さらに、プログラムのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作するプロセスであるため、複数のプログラムをそれぞれ別個のプロセスとして動作させることにより、他のプログラムのプロセスが停止した場合でも動作中の他のプロセスは影響を受けない。
【００２０】
このため、一部のプロセスが停止した場合でも他の複合サービスを続行して提供することができ、すべての複合サービスが提供不可能になることを防止することができる。
【００２１】
ここで、「サーバプロセス」とは、他のプロセスからの要求により、要求されたサービスを提供するプロセスをいい、サービスを提供する限り、どのプログラムもサーバプロセスとして動作することができる。
【００２２】
また、「クライアントプロセス」とは、このようなサーバプロセスからサービスの提供を受けるプロセスをいい、サービスの提供を受ける限り、どのプログラムもクライアントプロセスとして動作することができる。
【００２３】
「関数」とは、サーバプロセスに対するサービスの処理要求やサーバプロセスによる所定の設定値の設定要求に対し、サーバプロセス側で要求された処理や設定を実行するものである。
【００２４】
また、本発明は、情報処理を行う一または複数のプログラムとを有する情報処理装置であって、前記プログラムのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、前記サーバプロセスは、ネットワークに接続された他の情報処理装置で動作するクライアントプロセスに対するサーバプロセスとして動作し、サーバプロセスのスレッドとして前記他の情報処理装置のクライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数を有していることを特徴とする。
【００２５】
この本発明によれば、プログラムはネットワーク上の他の情報処理装置で動作するプロセスをクライアントとしたサーバプロセスとして関数呼び出しを利用したプロセス間通信を実現することができ、同一の情報処理装置内のプロセスだけでなく、ネットワーク上の情報処理装置に対してもサービスの提供が可能となり、多種多様な機能を実現することができる。
【００２６】
この本発明において、サーバプロセスとなるプログラムが動作している情報処理装置はプログラムを搭載可能であれば、その構成は限定されるものではない。すなわち、当該情報処理装置は、サービスを提供するプログラムが１つでも搭載されていれば良い。
【発明の効果】
【００２７】
本発明によれば、プログラムの間の独立性を維持しながら互いにサービスやデータの授受をプロセス間通信によって行うことができ、多種多様な機能を実現することが可能である。
【発明を実施するための最良の形態】
【００２８】
以下に添付図面を参照して、この発明にかかる画像形成装置の好適な実施の形態を詳細に説明する。
（実施の形態１）
図１は、この発明の実施の形態１である画像形成装置（以下、「複合機」という）の構成を示すブロック図である。図１に示すように、複合機は、白黒ラインプリンタ（B&W LP）１０１と、カラーラインプリンタ（Color LP）１０２と、スキャナ１０３と、ファクシミリ１０４などのハードウェアリソースなどを有するとともに、プラットホーム１２０とアプリケーション１３０とから構成されるソフトウェア群１１０を備えている。
【００２９】
プラットホーム１２０は、アプリケーション１３０からの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一または複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ（ＳＲＭ）１２３と、汎用ＯＳ１２１とを有する。
【００３０】
コントロールサービスは、複数のサービスモジュールから形成され、ＳＣＳ（システムコントロールサービス）１２２と、ＥＣＳ（エンジンコントロールサービス）１２４と、ＭＣＳ（メモリコントロールサービス）１２５と、ＯＣＳ（オペレーションパネルコントロールサービス）１２６と、ＦＣＳ（ファックスコントロールサービス）１２７と、ＮＣＳ（ネットワークコントロールサービス）１２８とから構成される。なお、このプラットホーム１２０は、あらかじめ定義された関数により前記アプリケーション１３０から処理要求を受信可能とするアプリケーションプログラムインタフェース（ＡＰＩ）を有する。
【００３１】
汎用ＯＳ１２１は、ＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、プラットホーム１２０並びにアプリケーション１３０の各ソフトウェアをそれぞれプロセスとして並列実行する。
【００３２】
ＳＲＭ１２３は、ＳＣＳ１２２とともにシステムの制御およびリソースの管理を行うものであり、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４  Ｉ／Ｆ、ＲＳ２３２Ｃ  Ｉ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停を行い、実行制御する。
【００３３】
具体的には、このＳＲＭ１２３は、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、ＳＲＭ１２３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容（たとえば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。
【００３４】
ＳＣＳ１２２はアプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御を行うものである。ＥＣＳ１２４は、白黒ラインプリンタ（B&W LP）１０１、カラーラインプリンタ（Color LP）１０２、スキャナ１０３、ファクシミリ１０４からなるハードウェアリソースのエンジンを制御するものである。
【００３５】
ＭＣＳ１２５は、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などを行うものである。ＯＣＳ１２６は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールである。
【００３６】
ＦＣＳ１２７は、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供するものである。ＦＣＳ１２７では、そのサブプロセスであるＦＣＵハンドラ１２９（ＦＣＵＨ）が起動される。このＦＣＵＨ１２９は、ＦＣＳ１２７からの指令によりファクシミリ送受信の際にファクシミリエンジンのデバイスドライバを制御するものである。
【００３７】
ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行うものである。
【００３８】
アプリケーション１３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１１１と、コピー用アプリケーションであるコピーアプリ１１２と、ファクシミリ用アプリケーションであるファックスアプリ１１３と、スキャナ用アプリケーションであるスキャナアプリ１１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ１１５と、工程検査用アプリケーションである工程検査アプリ１１６とを有している。
【００３９】
これらの各コントロールサービスとＳＲＭ１２３と各アプリとは、それぞれプロセスとして汎用ＯＳ上に生成されて実行される。各プロセス内部では、複数のスレッドが起動され、汎用ＯＳの管理下でこれらのスレッドのＣＰＵ占有時間を切り替えることにより並列実行が実現されている。各アプリプロセスと各コントロールサービスプロセスとは、後述するプロセス間通信によって各種メッセージやデータの送受信および関数呼び出しを行う。
【００４０】
図２は、実施の形態１の複合機上で動作するサーバプロセスとクライアントプロセスの関係を示すブロック図である。ここで、サーバプロセス２０２とは、クライアントプロセス２０１からの要求によりクライアントプロセス２０１に対しサービスを提供するプロセスをいう。クライアントプロセス２０１とは、サーバプロセス２０２に対して要求を行うことにより、サーバプロセス２０２からサービスの提供を受けるプロセスをいう。
【００４１】
実施の形態１の複合機では、上述のコピーアプリ１１２、プリンタアプリ１１１、スキャナアプリ１１４、ファックスアプリ１１３などのアプリケーションプロセス、およびＥＣＳ１２４、ＭＣＳ１２５、ＦＣＳ１２７、ＮＣＳ１２８などのコントロールサービスのプロセスが主としてクライアントプロセス２０１となり、コントロールサービスおよびＳＲＭ１２３のプロセスが主としてサーバプロセス２０２となる。
【００４２】
すなわち、各アプリがコントロールサービスからサービスの提供を受ける場合には、各アプリのプロセスがクライアントプロセス２０１として動作し、コントロールサービスがサーバプロセス２０２として動作する。また、コントロールサービス間でサービスの要求と提供を行う場合には、サービスの要求を行うコントロールサービスがクライアントプロセス２０１として動作し、サービスの提供を行うコントロールサービスがサーバプロセス２０２として動作する。
【００４３】
なお、これらの例に限られず、各アプリのプロセス、コントロールサービスのプロセス、ＳＲＭプロセスは、いずれもサーバプロセス２０２およびクライアントプロセス２０１となることができる。すなわち、これらのプロセスが、他のいずれかのプロセスに対しサービスを要求する場合にはクライアントプロセス２０１として動作する一方、他のプロセスからの要求によりサービスを提供する場合にはサーバプロセス２０２として動作することになる。
【００４４】
図２に示すとおり、これらのアプリ、コントロールサービスおよびＳＲＭ１２３のプロセスには、いずれも複数のスレッドが起動している。そして、各プロセスは、複数のスレッドを有することから、他のプロセスからの要求を受けた場合に、当該他のプロセスをクライアントプロセス２０１としたサーバプロセス２０２として動作するが、これと同時に、他のプロセスに対してサービスを要求する場合に当該他のプロセスをサーバプロセス２０２としたクライアントプロセス２０１として動作する。
【００４５】
また、各プロセスは、同時に複数のプロセスをクライアントプロセス２０１としたサーバプロセス２０２となることも可能である。さらに、各プロセスは、同時に複数のサーバプロセス２０２からのサービスの提供を受けるクライアントプロセス２０１となることも可能である。
【００４６】
図２に示す通り、クライアントプロセス２０１は、サーバプロセス２０２のサービスを要求するために、クライアントプロセス内のスレッドからサーバプロセス２０２に対して関数コールを行い、その関数戻り値を受信することによってプロセス間通信を行う。
【００４７】
また、クライアントプロセス２０１の各スレッドはメッセージをサーバプロセス２０２に送信することによってプロセス間通信を行う。一方、サーバプロセス２０２からクライアントプロセス２０１に対するプロセス間通信は、メッセージの送信のみで行われ、関数コールは行えないようになっている。
【００４８】
このため、サーバプロセス２０２となりうるＥＣＳ１２４、ＭＣＳ１２５、ＦＣＳ１２７、ＮＣＳ１２８などコントロールサービスおよびＳＲＭ１２３には、クライアントプロセス２０１に対して提供するサービスが、サービスごとの後述する関数ハンドラ４０３としてあらかじめ実装されている。これらのサービスの要求をクライアントプロセス２０１から行う場合には、サーバプロセス２０２に対して、サービスごとに関数を呼び出すことにより（関数コールを行うことにより）、サービスの提供を受けることが可能となっている。
【００４９】
ここで、「メッセージ」とは、主としてサーバプロセス２０２とクライアントプロセス２０１との間でイベントや通知を行う際に送信するものであり、一意的なメッセージＩＤ、メッセージ名、メッセージ方向、メッセージ内容を含むデータである。
【００５０】
メッセージ方向には、「ＩＮ」、「ＯＵＴ」、「ＳＥＬＦ」があり、「ＩＮ」がクライアントプロセス２０１からサーバプロセス２０２に対して送信するメッセージを意味し、「ＯＵＴ」がサーバプロセス２０２からクライアントプロセス２０１に対して送信するメッセージを意味する。また、「ＳＥＬＦ」は、自分自身のプロセスに対して送信するメッセージを意味する。
【００５１】
また、「関数」とは、クライアントプロセス２０１からサーバプロセス２０２に対して所定の処理要求を行ったり、所定の設定要求を行う際に発行するものであり、関数コールに対し戻り値を返すものである。
【００５２】
クライアントプロセス２０１のスレッドは、あらかじめサーバプロセス２０２から提供されている関数をコールする。関数コールを受けたサーバプロセス２０２は要求された関数に対応する処理を実行してその実行結果を関数戻り値としてクライアントプロセス２０１のクライアントディスパッチャ２０３へ送信する。また、関数戻り値は構造体となっており、かかる構造体に戻り値の他、関数を識別する関数ＩＤが含まれている。
【００５３】
クライアントディスパッチャ２０３は、サーバプロセス２０２からのＯＵＴ方向のメッセージまたは関数戻り値の受信を監視するスレッドである。クライアントプロセス２０１は、一つのサーバプロセス２０２につき一つのクライアントディスパッチャ２０３を起動してサーバプロセス２０２と通信する。クライアントプロセス２０１が複数のサーバプロセス２０２と通信する場合には、サーバプロセス２０２ごとに一つのクライアントディスパッチャ２０３を起動する。
【００５４】
図３はクライアントディスパッチャの詳細な構成を示す説明図である。クライアントディスパッチャ２０３は、そのスレッド上でメッセージハンドラ３０２、エラーハンドラ３０１およびデフォルトハンドラ３０３を起動する。
【００５５】
メッセージハンドラ３０２は、受信したメッセージに対する処理を行うものであり、メッセージＩＤごとに別個のメッセージハンドラ３０２が複数存在する。このためクライアントディスパッチャ２０３がメッセージを受信すると、受信したメッセージに含まれるメッセージＩＤを判断し、対応するメッセージＩＤのメッセージハンドラ３０２を呼び出すようになっている。メッセージハンドラ３０２の処理内容としては、例えば、メッセージの内容を関数コールを行ったスレッドに通知するなどの処理があるが、メッセージごとに異なった処理内容が定義されている。
【００５６】
エラーハンドラ３０１は、クライアントディスパッチャ２０３の実行中にエラーが発生した場合に呼び出され、ユーザにエラー通知を行うなどのエラー処理を行う。デフォルトハンドラ３０３は、対応するメッセージハンドラ３０２が登録されていないメッセージＩＤのメッセージを受信した時に呼び出され、メッセージをスレッドに通知するなどの処理を行う。
【００５７】
また、クライアントディスパッチャ２０３は、関数戻り待ちキュー３０４を保持しており、この関数戻り待ちキュー３０４を利用することによって関数戻り値および関数戻り待ち状態のスレッド３０５の管理を行っている。すなわち、クライアントプロセス２０１のスレッドは、サーバプロセス２０２に対し関数コールを行うが、関数コール後、関数戻り値を受信するまで関数戻り待ち状態となり以降の処理が中断される。
【００５８】
クライアントディスパッチャ２０３は、スレッド３０５から関数コールが行われると、そのスレッド３０５の識別子（スレッドＩＤなど）を関数の関数ＩＤとともに関数戻り待ちキュー３０４に登録する。そして、クライアントディスパッチャ２０３は、サーバプロセス２０２から関数戻り値を受信すると、その関数ＩＤをキーとして関数戻り待ちキュー３０４を検索し、受信した関数戻り値の受信を待って処理が中断されているスレッド３０５の識別子（スレッドＩＤなど）を検出する。そして、クライアントディスパッチャ２０３は検出された識別子（スレッドＩＤ）のスレッドに受信した関数戻り値を送信する。関数戻り値を受信したスレッドは戻り待ち状態を抜け、関数コール後の処理の続行が可能となる。クライアントディスパッチャ２０３は、このような戻り値の通知を、関数戻り値を受信するごとに行う。
【００５９】
サーバディスパッチャ２０４は、クライアントプロセス２０１のスレッドからの関数コールおよびＩＮ方向のメッセージを監視するスレッドである。１つのサーバディスパッチャ２０４は、クライアントディスパッチャ２０３と異なり、複数のクライアントプロセス２０１からの関数コールおよびメッセージを受信することができる。
【００６０】
図４はサーバディスパッチャ２０４の詳細な構成を示す説明図である。サーバディスパッチャ２０４は、そのスレッド上で、関数ハンドラ４０３、メッセージハンドラ４０２、エラーハンドラ４０１およびデフォルトハンドラ４０４を起動する。
【００６１】
関数ハンドラ４０３は、関数の具体的な処理を実行するものであり、関数ごとに複数存在する。サーバディスパッチャ２０４は、クライアントプロセス２０１から関数コールを受信すると、受信した関数に対応する関数ハンドラ４０３を起動し、関数ハンドラ４０３によってクライアントプロセス２０１が要求した処理を実行し、その関数戻り値をクライアントプロセス２０１のクライアントディスパッチャ２０３へ送信する。
【００６２】
メッセージハンドラ４０２は、受信したメッセージに対する処理を行うものであり、メッセージＩＤごとに複数存在する。サーバディスパッチャ２０４は、メッセージを受信すると受信したメッセージに含まれるメッセージＩＤを判断し、対応するメッセージＩＤのメッセージハンドラ４０２を呼び出すようになっている。メッセージハンドラ４０２の処理内容としては、例えば、メッセージの内容をスレッドに通知するなどの処理があるが、メッセージごとに異なった処理内容が定義されている。
【００６３】
エラーハンドラ４０１は、サーバディスパッチャ２０４の実行中にエラーが発生した場合に呼び出され、エラー通知などのエラー処理を行う。デフォルトハンドラ４０４は、対応するメッセージハンドラ４０２が登録されていないメッセージＩＤのメッセージを受信した時に呼び出され、メッセージをスレッドに通知するなどの処理を行う。
【００６４】
つぎに、実施の形態１の複合機１００で実際に行われるプリンタ動作、スキャナ動作、コピー動作およびファクシミリ送信動作におけるプロセス間通信について具体的に説明する。
【００６５】
まず、プリンタ動作におけるプリンタアプリ１１１、ＥＣＳ１２４、ＭＣＳ１２５、ＳＲＭ１２３のプロセス間通信について説明する。図５は、実施の形態１の複合機でプリンタ動作を行う場合のプリンタアプリ、ＥＣＳ、ＭＣＳ、ＳＲＭの各プロセス間のデータシーケンスを示す説明図である。図６は、各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【００６６】
図６に示すように、複合機１００にはプリンタアプリプロセス１１１、ＥＣＳプロセス１２４、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３が動作している。これらプロセスは、複合機１００の起動時に生成される。なお、図６にはプリンタ動作において使用されるプロセスのみを図示しており、実際には他のアプリプロセスおよび他のコントロールサービスのプロセスも複合機１００の起動時に生成される。
【００６７】
プリンタアプリプロセス１１１は、複合機の起動時に起動され、図６に示すようにプロセス内に複数のスレッドが起動している。プリンタアプリプロセス１１１は、ＥＣＳプロセス１２４をサーバプロセスとしたクライアントプロセスとなっており、このためＥＣＳプロセス１２４からのメッセージや関数戻り値を受信してプロセス内のスレッドに通知するクライアントディスパッチャがスレッドとして起動される。
【００６８】
ＥＣＳプロセス１２４は、プリンタ動作時には、プリンタアプリプロセス１１１をクライアントプロセスとしたサーバプロセスとなるとともに、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３をそれぞれサーバプロセスとしたクライアントプロセスとなる。このため、ＥＣＳプロセス１２４内にはプリンタアプリプロセス１１１からの関数コールおよびメッセージの受信とプリンタアプリプロセス１１１に対するメッセージおよび関数戻り値の送信を行うサーバディスパッチャのスレッドと、ＭＣＳプロセス１２５またはＳＲＭプロセス１２３からのメッセージおよび関数戻り値の受信および戻り値の管理を行うクライアントディスパッチャと、その他ジョブ制御およびエンジン制御に関する処理を行う複数のスレッドが動作している。
【００６９】
ＭＣＳプロセス１２５は、プリンタ動作時には、ＥＣＳプロセス１２４をクライアントプロセスとしたサーバプロセスとなるとともに、ＳＲＭプロセス１２３をサーバプロセスとしたクライアントプロセスとなる。このため、ＭＣＳプロセス１２５内にはＥＣＳプロセス１２４からの関数コールおよびメッセージの受信とＥＣＳプロセス１２４に対するメッセージおよび関数戻り値の送信を行うサーバディスパッチャのスレッドと、ＳＲＭプロセス１２３からのメッセージおよび関数戻り値の受信および戻り値の管理を行うクライアントディスパッチャと、その他、メモリ制御またはハードディスク制御に関する処理を行う複数のスレッドが動作している。
【００７０】
ＳＲＭプロセス１２３は、プリンタ動作時には、ＥＣＳプロセス１２４またはＭＣＳプロセス１２５をクライアントプロセスとしたサーバプロセスとなっている。ＳＲＭプロセス１２３内にはＥＣＳプロセス１２４またはＭＣＳプロセス１２５からの関数コールおよびメッセージの受信とＥＣＳプロセス１２４またはＭＣＳプロセス１２５に対するメッセージおよび関数戻り値の送信を行うサーバディスパッチャのスレッドと、その他、エンジン資源制御に関する種々の処理を行う複数のスレッドが動作している。
【００７１】
実施の形態１におけるプリンタアプリプロセス１１１では、ジョブ動作モード設定とジョブスタート要求の各関数コールを行う処理を一スレッドとしている。また、ＥＣＳプロセス１２４では、印刷枚数分繰り返しメモリ画像情報要求関数コールを行う処理を一スレッドとし、また資源獲得要求関数コールを行う処理を一スレッドとしている。ＭＣＳプロセス１２５では、メモリ取得要求関数コールを行う処理を一スレッドとしている。ただし、これらの各スレッドにおける処理は一例であり、各プログラムで任意に定めることができる。
【００７２】
ＰＣなどのホストからセントロＩ／Ｆ、ＵＳＢ  Ｉ／Ｆ、ネットワークＩ／Ｆなど経由して印刷要求１があると、その印刷要求１をＮＣＳプロセスが受けプリンタアプリプロセスに転送する（ステップＳ５０１）。プリンタアプリプロセス１１１は、ＮＣＳプロセスから印刷要求を受信すると新たなプリントジョブを生成し、スレッド１においてＥＣＳプロセス１２４に対してジョブ動作モード設定要求関数コールを行う（ステップＳ５０２）。
【００７３】
その後このスレッド１は関数戻り値の受信待ちとなり、クライアントディスパッチャによりスレッド１の識別子（スレッドＩＤ）が関数戻り待ちキューに登録される。ここで、ジョブ動作モードとは、スキャナ、プロッタ、フィニッシャなどを動作させるために必要なパラメータ群であり、印刷用紙サイズ、印刷部数、給紙トレイなどのプリンタ条件から生成されるジョブの動作条件を定めたものである。
【００７４】
なお、以降では説明の簡略化のため、サーバプロセスに関数コールを行って関数戻り待ち状態となったスレッドの識別子（スレッドＩＤ）が、クライアントディスパッチャによって、関数ＩＤとともに関数戻り待ちキューに登録されることを、単に「スレッドが関数戻り待ち状態になる」と表現する。
【００７５】
ＥＣＳプロセス１２４では、サーバディスパッチャがプリンタアプリプロセスからジョブ動作モード設定関数コールを受信して、ジョブ動作モード設定関数ハンドラをサーバディスパッチャのスレッド上で起動する。そして、ジョブ動作モード設定関数ハンドラにより新たに生成されたプリンタジョブに対して上述のジョブ動作モードを設定し、関数戻り値（例えば、正常またはエラー発生）をプリンタアプリプロセス１１１のクライアントディスパッチャへ送信する。
【００７６】
プリンタアプリプロセス１１１のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブ動作モード設定関数の関数戻り値を受信して、関数戻り待ちキューから関数戻り値待ちのスレッド１を検索して、ジョブ動作モード設定関数の戻り値を抽出してスレッド１に送信する。
【００７７】
なお、以降では説明の簡略化のため、クライアントディスパッチャによって、関数戻り待ち状態のスレッドの識別子（スレッドＩＤ）が関数戻り待ちキューから検索され、検索された識別子（スレッドＩＤ）のスレッドがクライアントディスパッチャから関数戻り値を受信することを、単に「スレッドがクライアントディスパッチャ経由で関数戻り値を受信する」と表現する。
【００７８】
スレッド１では、クライアントディスパッチャからジョブ動作モード設定の関数戻り値を受信すると、戻り待ち状態を抜け、ジョブの開始要求を行うため、ＥＣＳプロセス１２４に対しジョブスタート要求関数を呼び出し（ステップＳ５０３）、関数戻り待ち状態となる。
【００７９】
ＥＣＳプロセス１２４では、サーバディスパッチャがプリンタアプリプロセス１１１からジョブスタート要求関数コールを受信して、ジョブスタート要求関数ハンドラをサーバディスパッチャのスレッド上で起動し、ジョブスタート要求関数ハンドラによってジョブの開始処理を行って関数戻り値をプリンタアプリプロセス１１１のクライアントディスパッチャへ送信する。
【００８０】
プリンタアプリプロセス１１１のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブスタート要求関数の戻り値を受信して、スレッド１がクライアントディスパッチャ経由でジョブスタート要求関数の戻り値を受信する。
【００８１】
つぎに、ＥＣＳプロセス１２４では、メモリに格納されている印刷データを取得するためにスレッド３においてＭＣＳプロセス１２５に対してメモリ画像情報要求メッセージを送信する（ステップＳ５０４）。
【００８２】
ＭＣＳプロセス１２５では、サーバディスパッチャがＥＣＳプロセス１２４からメモリ画像情報要求メッセージを受信して、メモリ画像情報要求メッセージハンドラを起動する。そして、このメモリ画像情報要求メッセージハンドラによってメモリに格納されている画像データを取得して、画像データをＥＣＳプロセス１２４へ送信する（ステップＳ５０５）。
【００８３】
ＥＣＳプロセス１２４のクライアントディスパッチャは、ＭＣＳプロセス１２５から画像データを受信して、スレッド３へ受け渡す。かかるメモリ画像情報要求メッセージの送信および画像データの受信処理は、印刷ページが終了するまで繰り返し行われる（ステップＳ５０８、Ｓ５０９）。
【００８４】
一方、ＭＣＳプロセス１２５では、画像データのＥＣＳプロセス１２４への送信後、画像メモリを確保するためにスレッド５においてＳＲＭプロセス１２３に対してメモリ取得要求関数コールを行って（ステップＳ５０６）、戻り待ち状態となる。ＳＲＭプロセス１２３では、サーバディスパッチャがＭＣＳプロセス１２５からメモリ取得要求関数コールを受信し、メモリ取得要求関数ハンドラを起動して、このメモリ取得要求関数ハンドラによってプリント用に画像メモリを確保し、関数戻り値をＭＣＳプロセス１２５へ送信する。
【００８５】
ＭＣＳプロセス１２５のクライアントディスパッチャは、ＳＲＭプロセス１２３からメモリ取得要求関数の戻り値を受信して、スレッド５がクライアントディスパッチャ経由でこのメモリ取得要求関数の戻り値を受信する。
【００８６】
ＥＣＳプロセス１２４では、１ページ目の印刷データをＭＣＳプロセス１２５から受信した後、プリンタエンジン資源を取得するためにスレッド４において、ＳＲＭプロセス１２３に対して資源獲得要求関数コールを行って（ステップＳ５０７）、関数戻り待ち状態となる。ＳＲＭプロセス１２３では、サーバディスパッチャがＥＣＳプロセス１２４から資源獲得要求関数コールを受信して資源獲得要求関数ハンドラを起動し、資源獲得要求関数ハンドラによってプリンタエンジンを占有し、関数戻り値をＥＣＳプロセス１２４へ送信する。ＥＣＳプロセス１２４のクライアントディスパッチャは、ＳＲＭプロセス１２３から資源獲得要求関数の戻り値を受信して、スレッド４がクライアントディスパッチャ経由で資源獲得要求関数の戻り値を受信する。
【００８７】
ＥＣＳプロセス１２４のスレッド３では、メモリ画像情報要求メッセージ（ステップＳ５１１）に対する通知メッセージとして「画像なし」の応答メッセージを受信した場合には（ステップＳ５１２）、すべての印刷ページのプリントが終了したものと判断し、プリンタアプリプロセス１１１に対し、ジョブエンド通知メッセージを送信する（ステップＳ５１３）。プリンタアプリプロセス１１１では、クライアントディスパッチャがこのメッセージを受信してメッセージハンドラを起動し、メッセージハンドラによってジョブエンド通知メッセージをスレッド１へ通知する。
【００８８】
このようにプリンタ動作のプロセス間通信が行われるが、ここで、図５に示すように、印刷要求１に対するプリント処理中に、別の印刷要求２がＮＣＳからプリンタアプリプロセス１１１へ送信された場合について説明する。（ステップＳ５２１）。
【００８９】
このとき、プリンタアプリプロセス１１１、ＥＣＳプロセス１２４、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３で、上述した関数コールと同様のプロセス間通信が行われる（ステップＳ５２２、Ｓ５２３、Ｓ５２４）。
【００９０】
しかし、ＥＣＳプロセス１２４のスレッド７からＳＲＭプロセス１２３に対して資源獲得要求関数コールを行った場合（ステップＳ５２７）、現在プリンタエンジンが印刷要求１に対するプリント処理に占有されているため、ＳＲＭプロセス１２３は直ちに資源獲得要求関数の戻り値を返さない。このため、このスレッド７はしばらく関数戻り値待ちの状態となり、関数戻り待ちキューに登録された状態となる。そして、印刷要求１による占有からプリンタエンジンが解放された時点で、ＳＲＭプロセス１２３は資源獲得要求関数の戻り値をＥＣＳプロセス１２４に返し（ステップＳ５２８）、これにより、ＥＣＳプロセス１２４のスレッド７が、印刷要求２に対する処理を続行することになる。
【００９１】
なお、ここでは印刷要求２に対するプリンタジョブにおいて、プリンタエンジンの獲得ができない場合の例を説明した。この他、ＥＣＳプロセス１２４からＳＲＭプロセス１２３に対してメモリ取得要求関数コールを行ったときに、すでに印刷要求１に対するプリントジョブが原因でメモリ不足が生じ、印刷要求２のプリントジョブでメモリを取得できない場合には、メモリ取得要求関数コールを行ったスレッドが印刷要求１のプリンタ動作完了まで関数戻り待ち状態のまま待機し、印刷要求２に対するプリンタ動作が中断する。
【００９２】
次に、実施の形態１の複合機１００で行われるスキャナ動作において、スキャナアプリ１１４、ＥＣＳ１２４、ＭＣＳ１２５、ＳＲＭ１２３のプロセス間通信について具体的に説明する。図７は、実施の形態１の複合機でスキャナ動作を行う場合のスキャナアプリ、ＥＣＳ、ＭＣＳ、ＳＲＭの各プロセス間のデータシーケンスを示す説明図である。また、図８は、各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【００９３】
図８に示すように、複合機１００にはスキャナアプリプロセス１１４、ＥＣＳプロセス１２４、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３が動作している。これらのプロセスは、複合機１００の起動時に生成される。なお、図８にはスキャナ動作において使用されるプロセスのみを図示しており、実際には他のアプリプロセスおよび他のコントロールサービスのプロセスも複合機１００の起動時に生成される。
【００９４】
スキャナアプリプロセス１１４は、複合機の起動時に起動され、図８に示すようにプロセス内に複数のスレッドが起動している。スキャナアプリプロセス１１４は、ＥＣＳプロセス１２４をサーバプロセスとしたクライアントプロセスとなっており、このためＥＣＳプロセス１２４に対するクライアントディスパッチャのスレッドが起動している。
【００９５】
ＥＣＳプロセス１２４は、スキャナ動作時には、スキャナアプリプロセス１１４をクライアントプロセスとしたサーバプロセスとなるとともに、ＭＣＳプロセス１２５およびＳＲＭプロセス１２４をそれぞれサーバプロセスとしたクライアントプロセスとなる。このため、ＥＣＳプロセス１２４内にはスキャナアプリプロセス１１４に対するサーバディスパッチャのスレッドと、ＭＣＳプロセス１２５に対するクライアントディスパッチャのスレッドと、ＳＲＭプロセス１２３に対するクライアントディスパッチャのスレッドとその他ジョブ制御またはエンジン制御に関する処理を行う複数のスレッドが動作している。
【００９６】
ＭＣＳプロセス１２５は、スキャナ動作時には、スキャナアプリプロセス１１４およびＥＣＳプロセス１２４をクライアントプロセスとしたサーバプロセスとなる。このため、ＭＣＳプロセス１２５内にはスキャナアプリプロセス１１４およびＥＣＳプロセス１２４に対するサーバディスパッチャのスレッドとその他メモリ制御またはハードディスク制御に関する処理を行う複数のスレッドが動作している。
【００９７】
ＳＲＭプロセス１２３は、ＥＣＳプロセス１２４をクライアントプロセスとしたサーバプロセスとなり、このため、ＳＲＭプロセス１２３内にはＥＣＳプロセス１２４に対するサーバディスパッチャのスレッドとその他エンジン資源制御に関する処理を行う複数のスレッドが動作している。
【００９８】
実施の形態１におけるスキャナアプリプロセス１１４では、スキャナ動作時におけるジョブオープン要求関数とジョブ動作モード設定要求とジョブスタート要求の各関数コールを行う一連の処理、ファイル生成要求関数コールを行う処理、ファイル情報登録要求関数コールおよびファイルクローズ要求関数コールを行う処理をそれぞれ一スレッドとしている。
【００９９】
また、スキャナアプリプロセス１１４では、スキャンした画像の読み出し時におけるファイルオープン要求関数コール、作業領域確保要求関数コールおよびページオープン要求関数コールを行う処理、読み出し要求関数コールを行う処理、ページクローズ要求関数コールとページ削除要求関数コールと作業領域削除要求関数コールとファイルクローズ要求関数コールとファイル削除要求関数コールを行う一連の処理をそれぞれ一スレッドとしている。
【０１００】
ＥＣＳプロセス１２４では、資源獲得要求関数コールを行う処理、原稿枚数分繰り返してページ生成要求関数コールと原稿フィードインおよびページクローズ要求関数コールを行う一連の処理をそれぞれ一スレッドとしている。ただし、これらの各スレッドにおける処理は一例であり、各プログラムで任意に定めることができる。
【０１０１】
スキャナアプリプロセス１１４に対しスキャン要求があると、スキャナアプリプロセス１１４は、新たなスキャナジョブを生成し、スレッド１においてＥＣＳプロセス１２４に対してジョブオープン要求関数コールを行う（ステップＳ７０１）。その後このスレッド１は関数戻り待ち状態となり、クライアントディスパッチャによってスレッド１の識別子（スレッドＩＤ）が呼び出した関数の関数ＩＤとともに関数戻り待ちキューに登録される。
【０１０２】
また、スキャナアプリプロセス１１４では、これと並行してスレッド２によりＭＣＳプロセス１２５に対しファイル生成要求関数コールを行う（ステップＳ７０２）。その後このスレッド２は関数戻り待ち状態となり、同様にスレッド２の識別子（スレッドＩＤ）が関数戻り待ちキューに登録される。
【０１０３】
ＥＣＳプロセス１２４では、サーバディスパッチャがスキャナアプリプロセス１１４からジョブオープン要求関数コールを受信して、ジョブオープン要求関数ハンドラをサーバディスパッチャのスレッド上で起動する。そして、ジョブオープン要求関数ハンドラによりジョブをオープンして、関数戻り値をスキャナアプリプロセス１１４のクライアントディスパッチャへ送信する。
【０１０４】
一方、ＭＣＳプロセス１２５では、サーバディスパッチャがスキャナアプリプロセス１１４からファイル生成要求関数コールを受信して、ファイル生成要求関数ハンドラによって、スキャンした画像を一時的に格納するファイルをハードディスク上に生成して、関数戻り値をスキャナアプリプロセス１１４のクライアントディスパッチャへ送信する。
【０１０５】
スキャナアプリプロセス１１４のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブオープン要求関数の関数戻り値を受信するとともに、ＭＣＳプロセス１２５からファイル生成要求関数の戻り値を受信して、関数戻り値キューからジョブオープン要求関数戻り待ち状態のスレッド１とファイル生成要求関数戻り待ち状態のスレッド２を検出し、ジョブオープン要求関数の戻り値をスレッド１に送信し、ファイル生成要求関数の戻り値をスレッド２に送信する。
【０１０６】
スレッド１は、クライアントディスパッチャからジョブオープン要求関数の戻り値を受信すると戻り待ち状態を抜け、ジョブ動作モードの設定を行うため、ＥＣＳプロセス１２４に対しジョブ動作モード設定要求関数を呼び出し（ステップＳ７０３）、スレッド１は関数戻り待ち状態となる。
【０１０７】
ＥＣＳプロセス１２４では、サーバディスパッチャがスキャナアプリプロセス１１４からジョブ動作モード設定要求関数コールを受信して、ジョブ動作モード設定要求関数ハンドラによってスキャナジョブに上述のジョブ動作モードを設定して関数戻り値をスキャナアプリプロセス１１４のクライアントディスパッチャへ送信する。
【０１０８】
スキャナアプリプロセス１１４のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブ動作モード設定要求関数の戻り値を受信する。スレッド１はクライアントディスパッチャ経由でジョブ動作モード設定要求関数の戻り値を受信し、関数戻り待ち状態を抜ける。
【０１０９】
関数戻り待ち状態を抜けたスレッド１では、ジョブスタート要求関数コールをＥＣＳプロセス１２４に対して行い（ステップＳ７０４）、スレッド１が関数戻り待ち状態となる。ＥＣＳプロセス１２４では、サーバディスパッチャがジョブスタート要求関数コールを受信して、ジョブスタート要求関数ハンドラによってジョブの開始処理を行い、関数戻り値をスキャナアプリプロセス１１４のクライアントディスパッチャへ送信する。スキャナアプリプロセス１１４のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブスタート要求関数の戻り値を受信し、スレッド１がクライアントディスパッチャ経由でジョブスタート要求関数の関数戻り値を受信する。
【０１１０】
このとき、ＥＣＳプロセス１２４では、スキャナエンジンの資源格闘のため、スレッド３においてＳＲＭプロセス１２３に対して資源獲得要求関数コールを行い（ステップＳ７０５）、関数戻り待ち状態となる。またＥＣＳプロセス１２４では、これと並行してスキャン画像をページ単位で格納するメモリを確保するために、スレッド４においてＭＣＳプロセス１２５に対しページ生成要求関数コールを行い（ステップＳ７０６）、関数戻り待ち状態となる。この時点で、関数戻り待ちキューには、スレッド３とスレッド４の識別子（スレッドＩＤ）が呼び出した関数の関数ＩＤとともに格納される。
【０１１１】
ＳＲＭプロセス１２３では、サーバディスパッチャが資源獲得要求関数コールを受信して資源獲得要求関数ハンドラにより、スキャナエンジンを占有し関数戻り値をＥＣＳプロセス１２４へ送信する。ＭＣＳプロセス１２５では、サーバディスパッチャがページ生成要求関数コールを受信してページ生成要求関数ハンドラにより、１ページ分のメモリを確保し、確保したページをオープンし、関数戻り値をＥＣＳプロセス１２４へ送信する。
【０１１２】
ＥＣＳプロセス１２４のクライアントディスパッチャは、ＳＲＭプロセス１２３から資源獲得要求関数の戻り値を受信し、またＭＣＳプロセス１２５からページ生成要求関数の戻り値を受信する。そして、関数戻り待ち状態のスレッド３はクライアントディスパッチャ経由で資源獲得要求関数の戻り値を受信し、スレッド４もクライアントディスパッチャ経由でページ生成要求関数の戻り値を受信する。
【０１１３】
スレッド４は、関数戻り値を受信することによって戻り待ち状態を抜け、つぎにスキャナエンジンに対して原稿フィードインの指示メッセージを送信して（ステップＳ７０７）、スキャナによる原稿の読み取り動作を開始させる。１ページ分の原稿読み動作が終了すると、ＥＣＳプロセス１２４に対しスキャナエンジンからスキャン完了通知メッセージが送信されるので（ステップＳ７０８）、ＥＣＳプロセス１２４のスレッド４はこのスキャン完了通知メッセージを受信してＭＣＳプロセス１２５に対しページクローズ要求関数コールを行って（ステップＳ７０９）、戻り待ち状態となる。
【０１１４】
ＭＣＳプロセス１２５では、ページクローズ要求関数コールを受信すると、ページクローズ要求関数ハンドラによってメモリ上でオープンされている１ページ分の画像メモリをクローズして関数戻り値をＥＣＳプロセス１２４のクライアントディスパッチャへ送信する。
【０１１５】
ＥＣＳプロセス１２４のクライアントディスパッチャは、ページクローズ要求関数の戻り値を受信し、関数戻り待ち状態のスレッド４がクライアントディスパッチャ経由でページクローズ要求関数の戻り値を受信する。スレッド４では、これにより関数戻り待ち状態を抜け、上述のページ生成要求関数コールからページクローズ要求関数コールまでの処理（ステップＳ７０６〜Ｓ７０９）を原稿枚数分だけ繰り返し行う。
【０１１６】
原稿の最終ページのスキャンが終了すると、スキャナエンジンはスレッド４に対しスキャン処理完了通知メッセージを送信する（ステップＳ７１０）。スレッド４ではこのスキャン処理完了通知メッセージをスキャナアプリプロセス１１４に対して送信し（ステップＳ７１１）、さらにジョブエンド通知メッセージも送信する（ステップＳ７１２）。
【０１１７】
スキャナアプリプロセス１１４のクライアントディスパッチャは、スキャン処理完了通知メッセージとジョブエンド通知メッセージとを順にＥＣＳプロセス１２４から受信し、スレッド１に通知する。一方、スキャナアプリプロセス１１４のスレッド５は、ＭＣＳプロセス１２５に対してファイル情報登録要求関数コールを行って（ステップＳ７１３）、関数戻り待ち状態となる。
【０１１８】
ＭＣＳプロセス１２５では、サーバディスパッチャがファイル情報登録要求関数コールを受信すると、ファイル情報登録要求関数ハンドラによって、一時的に生成されたすべての原稿のスキャン画像が格納されているファイルに対し、ファイル名、格納先等のファイル情報を登録し、関数戻り値をスキャナアプリプロセス１１４のクライアントディスパッチャへ送信する。
【０１１９】
スキャナアプリプロセス１１４のスレッド５は、ファイル情報登録要求関数の戻り値をクライアントディスパッチャ経由で受信すると、ＭＣＳプロセス１２５に対しファイルクローズ要求関数コールを行って（ステップＳ７１４）、関数戻り待ち状態となる。ＭＣＳプロセス１２５では、サーバディスパッチャでこのファイルクローズ要求関数コールを受信し、ファイルクローズ要求関数ハンドラによってスキャン画像のファイルをクローズして関数戻り値をスキャナアプリプロセス１１４に送信する。スキャナアプリプロセス１１４は、このファイルクローズ要求関数の戻り値を受信することにより、スキャン処理が終了する。
【０１２０】
ついで、スキャナアプリプロセス１１４では、格納されているスキャン画像を読み出すため、次の処理を行う。まず、スレッド６において、ＭＣＳプロセス１２５に対し、スキャン画像のファイルをオープンするためのファイルオープン要求関数コール、作業メモリの確保のための作業領域確保要求関数コール、ページオープン要求関数コールを順次に行う（ステップＳ７１５〜Ｓ７１７）。なお、スレッド６は、上述と同様に、それぞれの関数コールを行った後、関数戻り待ち状態になり、関数戻り値の通知により、戻り待ち状態を抜け、次の関数コールを行う。
【０１２１】
ＭＣＳプロセス１２５のサーバディスパッチャは、スキャナアプリプロセス１１４のスレッド６からファイルオープン要求関数コール、作業領域確保要求関数コール、ページオープン要求関数コールを順に受信して、スキャン画像ファイルのオープン処理、作業メモリの確保処理、ページオープン処理をそれぞれ各関数ハンドラによって行って、各関数戻り値をスキャナアプリプロセス１１４に送信する。スキャナアプリプロセス１１４では、クライアントディスパッチャによりファイルオープン要求関数、作業領域確保要求関数、ページオープン要求関数の各戻り値を順に受信して、スレッド６がクライアントディスパッチャ経由で関数戻り値を受信する。
【０１２２】
また、スキャナアプリプロセス１１４では、スレッド７において、スキャン画像ファイルからの画像データの読み出しのために読み出し要求関数コールを行い（ステップＳ７１８）、スレッド７が関数戻り待ち状態になる。さらに、スレッド８において、ＭＣＳプロセス１２５に対しページクローズ要求関数コールを行い（ステップＳ７１９）、スレッド８は関数戻り待ち状態になる。
【０１２３】
ＭＣＳプロセス１２５では、スレッド６からの要求であるページオープン処理の終了後に、スキャナアプリプロセス１１４のスレッド７から読み出し要求関数コールを受信し、読み出し要求関数ハンドラによってスキャナ画像ファイルから画像データを読み出し、画像データとともに関数戻り値をスキャナアプリプロセス１１４へ送信する。スキャナアプリプロセス１１４では、スレッド７が読み出し要求関数の戻り値をクライアントディスパッチャ経由で受信することにより、関数戻り待ち状態を抜け、次の読み出し要求関数コールを行い、同様に関数戻り値を受信する。
【０１２４】
ＭＣＳプロセス１２５では、スレッド７からの要求である最後の読み出し要求処理が終了すると、スキャナアプリプロセス１１４のスレッド８から受信したページクローズ要求関数の関数ハンドラを起動して、オープンしているページデータのクローズ処理を行い、関数戻り値をスキャナアプリプロセス１１４へ送信する。スキャナアプリプロセス１１４では、スレッド８がページクローズ要求関数の戻り値をクライアントディスパッチャ経由で受信し、関数戻り待ち状態を抜ける。これにより、スレッド８では、ページ削除要求関数コール、作業領域削除要求関数コール、ファイルクローズ要求関数コール、ファイル削除要求関数コールを順に行う（ステップＳ７２０〜Ｓ７２３）。
【０１２５】
ＭＣＳプロセス１２５は、これらの関数コールを順に受信して、受信した関数コールに対応する関数ハンドラによってそれぞれ、ページデータの削除、作業メモリの削除、スキャン画像ファイルのクローズ、スキャン画像ファイルの削除の各処理を行って、各関数戻り値をスキャナアプリプロセス１１４に送信する。
【０１２６】
スキャナアプリプロセス１１４のスレッド８では、ＭＣＳプロセス１２５からの各関数戻り値をクライアントディスパッチャ経由で受信することにより、スキャン画像の読み出し処理が完了する。
【０１２７】
次に、実施の形態１の複合機１００で行われるコピー動作において、コピーアプリ１１２、ＥＣＳ１２４、ＭＣＳ１２５、ＳＲＭ１２３のプロセス間通信について具体的に説明する。図９は、実施の形態１の複合機でコピー動作を行う場合のコピーアプリ、ＥＣＳ、ＭＣＳ、ＳＲＭの各プロセス間のデータシーケンスを示す説明図である。また、図１０は、各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【０１２８】
図１０に示すように、複合機１００にはコピーアプリプロセス１１２、ＥＣＳプロセス１２４、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３が動作している。これらプロセスは、複合機１００の起動時に生成される。なお、図１０にはコピー動作において使用されるプロセスのみを図示しており、実際には他のアプリプロセスおよび他のコントロールサービスのプロセスも複合機の起動時に生成される。
【０１２９】
コピーアプリプロセス１１２は、複合機１００の起動時に起動され、図１０に示すようにプロセス内に複数のスレッドが起動している。コピーアプリプロセス１１２は、ＥＣＳプロセス１２４をサーバプロセスとしたクライアントプロセスとなっており、このためＥＣＳプロセス１２４に対するクライアントディスパッチャのスレッドが起動している。
【０１３０】
ＥＣＳプロセス１２４は、コピー動作時には、コピーアプリプロセス１１２をクライアントプロセスとしたサーバプロセスとなるとともに、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３をそれぞれサーバプロセスとしたクライアントプロセスとなる。このため、ＥＣＳプロセス１２４内にはコピーアプリプロセス１１２に対するサーバディスパッチャのスレッドと、ＭＣＳプロセス１２５に対するクライアントディスパッチャのスレッドと、ＳＲＭプロセス１２３に対するクライアントディスパッチャのスレッドとその他ジョブ制御およびエンジン制御に関する処理を行う複数のスレッドが動作している。
【０１３１】
ＭＣＳプロセス１２５は、コピー動作時には、ＥＣＳプロセス１２４をクライアントプロセスとしたサーバプロセスとなるとともに、ＳＲＭプロセス１２３をサーバプロセスとしたクライアントプロセスとなる。このため、ＭＣＳプロセス１２５内にはＥＣＳプロセス１２４に対するサーバディスパッチャのスレッドと、ＳＲＭプロセス１２３に対するクライアントディスパッチャのスレッドと、その他メモリ制御およびハードディスク制御に関する種々の処理を行う複数のスレッドが動作している。
【０１３２】
ＳＲＭプロセス１２３は、ＥＣＳプロセス１２４およびＭＣＳプロセス１２５をクライアントプロセスとしたサーバプロセスとなり、このため、ＳＲＭプロセス１２３内にはＥＣＳプロセス１２４およびＭＣＳプロセス１２５に対するサーバディスパッチャのスレッドとその他エンジンの資源制御に関する処理を行う複数のスレッドが動作している。
【０１３３】
実施の形態１におけるコピーアプリプロセス１１２では、コピー時におけるジョブオープン要求関数コールとジョブ動作モード設定関数コールとジョブスタート要求関数コールを行う一連の処理、ジョブクローズ要求関数コールを行う処理をそれぞれ一スレッドとしている。
【０１３４】
ＥＣＳプロセス１２４では、メモリ確保要求関数コールを行う処理、資源獲得要求関数コールを行う処理、原稿フィードイン処理をそれぞれ一スレッドとしている。ＭＣＳプロセス１２５では、メモリ取得要求関数コールを行う処理を一スレッドとしている。なお、コピー動作時においても、これら各スレッドにおける処理は一例であり、各プログラムで任意に定めることができる。
【０１３５】
コピー要求があると、コピーアプリプロセス１１２は、新たなコピージョブを生成し、スレッド１においてＥＣＳプロセス１２４に対してジョブオープン要求関数コールを行う（ステップＳ９０１）。これにより、スレッド１は関数戻り待ち状態となり、クライアントディスパッチャによってスレッド１の識別子（スレッドＩＤ）が呼び出したジョブオープン要求関数の関数ＩＤとともに関数戻り待ちキューに登録される。
【０１３６】
ＥＣＳプロセス１２４では、サーバディスパッチャがコピーアプリプロセス１１２からジョブオープン要求関数コールを受信して、ジョブオープン要求関数ハンドラをサーバディスパッチャのスレッド上で起動する。そして、ジョブオープン要求関数ハンドラによりコピージョブをオープンして、関数戻り値をコピーアプリプロセス１１２のクライアントディスパッチャへ送信する。
【０１３７】
コピーアプリプロセス１１２のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブオープン要求関数の戻り値を受信し、関数戻り値待ちキューから関数戻り待ち状態のスレッドを検索する。そして、検索されたスレッド１にジョブオープン要求関数の戻り値を送信する。
【０１３８】
スレッド１は、クライアントディスパッチャからジョブオープン要求関数の戻り値を受信すると、戻り待ち状態を抜け、ジョブ動作モードの設定を行うため、ＥＣＳプロセス１２４に対しジョブ動作モード設定関数コールを行い（ステップＳ９０２）、関数戻り待ち状態となる。
【０１３９】
一方、スレッド２はジョブスタート要求関数コールをＥＣＳプロセス１２４に対して行い（ステップＳ９０３）、関数戻り待ち状態となる。この時点では、関数戻り待ちキューにはスレッド１の識別子（スレッドＩＤ）がジョブ動作モード設定関数の関数ＩＤとともに登録され、またスレッド２の識別子（スレッドＩＤ）がジョブスタート要求関数の関数ＩＤとともにクライアントディスパッチャにより登録される。
【０１４０】
ＥＣＳプロセス１２４では、サーバディスパッチャがコピーアプリプロセス１１２からジョブ動作モード設定関数コールを受信して、ジョブ動作モード設定関数ハンドラによってコピージョブに上述のジョブ動作モードを設定して関数戻り値をコピーアプリプロセス１１２のクライアントディスパッチャへ送信する。また、サーバディスパッチャはジョブスタート要求関数コールを受信して、ジョブスタート要求関数ハンドラによってジョブの開始処理を行って関数戻り値をコピーアプリプロセス１１２のクライアントディスパッチャへ送信する。
【０１４１】
コピーアプリプロセス１１２のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブ動作モード設定関数とジョブスタート要求関数の戻り値をそれぞれ受信し、スレッド１がクライアントディスパッチャ経由でジョブ動作モード設定関数の戻り値を受信し、スレッド２もクライアントディスパッチャ経由でジョブスタート要求関数の戻り値を受信する。
【０１４２】
ＥＣＳプロセス１２４では、ジョブスタート要求関数の戻り値をコピーアプリプロセス１１２に送信すると、つぎにスキャン画像を格納するためのメモリを確保するために、スレッド３においてＭＣＳプロセス１２５に対し必要なサイズを指定したメモリ確保要求関数コールを行い（ステップＳ９０４）、関数戻り待ち状態となる。また、これと並行してスレッド４において、スキャナエンジンとプリンタエンジンの資源獲得のため、ＳＲＭプロセス１２３に対して資源獲得要求関数コールを行い（ステップＳ９０６）、関数戻り待ち状態となる。
【０１４３】
ＭＣＳプロセス１２５では、サーバディスパッチャがメモリ確保要求関数コールを受信すると、メモリ確保要求関数ハンドラによって指定されたサイズのメモリ上の領域を確保し、関数戻り値をＥＣＳプロセス１２４に送信する。一方、ＳＲＭプロセス１２３では、サーバディスパッチャが資源獲得要求関数コールを受信して資源獲得要求関数ハンドラにより、スキャナエンジンとプリンタエンジンとを占有し、関数戻り値をＥＣＳプロセス１２４へ送信する。
【０１４４】
ＥＣＳプロセス１２４のクライアントディスパッチャは、ＭＣＳプロセス１２５からメモリ確保要求関数の戻り値を受信するとともに、ＳＲＭプロセス１２３から資源獲得要求関数の戻り値を受信する。そして、スレッド３はクライアントディスパッチャ経由でメモリ確保要求関数の戻り値を受信し、スレッド４もクライアントディスパッチャ経由で資源獲得要求関数の戻り値を受信する。これにより、スレッド３とスレッド４は関数戻り待ち状態を抜ける。
【０１４５】
資源獲得要求関数の戻り値を受信してスキャナエンジンとプリンタエンジンとをコピージョブで占有すると、ＥＣＳプロセス１２４では、スレッド５においてスキャナエンジンに対して原稿フィードインを行い（ステップＳ９０７）、これによりコピー動作の原稿スキャン処理を開始する。
【０１４６】
スキャナエンジンでは原稿のスキャン処理が終了するとスキャン終了通知メッセージをＥＣＳプロセス１２４のスレッド５に送信し（ステップＳ９０８）、プリンタエンジンによってスキャン画像のプリント処理を開始する。そして、プリンタエンジンではスキャン画像のプリント処理が終了すると、ＥＣＳプロセス１２４のスレッド５に印刷終了通知メッセージを送信する（ステップＳ９１０）。
【０１４７】
ＥＣＳプロセス１２４では、スレッド５がスキャナエンジンからスキャン終了通知メッセージを受信すると、コピーアプリプロセス１１２に対しスキャン終了の旨のジョブエンド通知メッセージを送信する（ステップＳ９０９）。また、スレッド５がプリンタエンジンから印刷終了通知メッセージを受信すると、コピーアプリプロセス１１２に対し印刷終了の旨のジョブエンド通知メッセージを送信する（ステップＳ９１１）。
【０１４８】
コピーアプリプロセス１１２では、クライアントディスパッチャが２つのジョブエンド通知メッセージを受信して、メッセージハンドラを起動してスレッド２に各ジョブエンド通知メッセージを通知する。これにより、原稿１ページ分のコピー動作が完了する。
【０１４９】
複数枚の原稿のコピーを行う場合には、さらにＥＣＳプロセス１２４に対しジョブスタート要求関数コールを行うと（ステップＳ９１２）、上述と同様の動作がＥＣＳプロセス１２４、ＭＣＳプロセス１２５、ＳＲＭプロセス１２３、スキャナエンジンおよびプリンタエンジンで行われる（ステップＳ９１３〜Ｓ９１６）。すべての原稿のコピーが終了し、コピーアプリプロセス１１２が最後のジョブエンド通知メッセージを受信すると（ステップＳ９１７）、スレッド１はＥＣＳプロセス１２４に対しジョブクローズ要求関数コールを行う（ステップＳ９１８）。
【０１５０】
ＥＣＳプロセス１２４では、サーバディスパッチャによりこのジョブクローズ要求関数コールを受信してジョブクローズ要求関数ハンドラによってオープン状態にあるコピージョブをクローズし、その関数戻り値をコピーアプリプロセス１１２に送信する。
【０１５１】
コピーアプリプロセス１１２では、クライアントディスパッチャによって、ジョブクローズ要求関数の戻り値を受信し、戻り待ち状態となっているスレッド２がクライアントディスパッチャ経由でジョブクローズ要求関数の戻り値を受信し、コピー動作が完了する。
【０１５２】
ここで、上述したコピー動作中に、スキャン要求をスキャナアプリプロセス１１４が受信した場合には、次のような処理が行われる。たとえば、コピー動作においてＥＣＳプロセス１２４からＳＲＭプロセス１２３に対しスキャナエンジンとプリンタエンジンの資源獲得要求関数コールを行った後に、スキャナアプリプロセス１１４にスキャン要求があった場合を考える。
【０１５３】
この場合、上述した図７におけるスキャナ動作において、ＥＣＳプロセス１２４からＳＲＭプロセス１２３に対しスキャナエンジンの資源獲得要求関数コールが行われるが、スキャナエンジンがコピージョブで占有されているため、スキャナジョブで獲得することができない。
【０１５４】
このためスキャナジョブでは資源獲得要求関数の戻り値のＥＣＳプロセス１２４に対する送信を、コピージョブが完了し、スキャナエンジンが解放された後で行う。この間、スキャナジョブにおいて資源獲得要求関数コールを行ったスレッドは、関数戻り待ち状態となって待機していることになり、スキャナ動作がコピー動作完了まで中断されることになる。また、コピー動作中に、コピージョブでプリンタエンジンの占有がされた後に、プリンタアプリプロセス１１１にプリント要求があった場合にも、同様に、コピー動作完了までプリント動作は中断されることになる。
【０１５５】
なお、コピー動作中のスキャナ動作について、スキャナジョブでスキャナエンジンの獲得ができない場合の例をあげて説明したが、この他、スキャナジョブにおいてＥＣＳプロセス１２４からＭＣＳプロセス１２５に対し、ページ生成要求関数コールを行ったときに、コピージョブにおいてメモリ使用中のため、メモリ不足でぺージ生成をできないような場合にも、ページ生成要求関数コールを行ったスレッドが関数戻り待ち状態となって、コピー動作完了までスキャナ動作が中断する。
【０１５６】
次に、実施の形態１の複合機で行われるファクシミリ送信動作において、ファックスアプリ１１３、ＦＣＳ１２７、ＥＣＳ１２４、ＭＣＳ１２５、ＳＲＭ１２３のプロセス間通信について具体的に説明する。図１１は、実施の形態１の複合機でコピー動作を行う場合のファックスアプリ、ＦＣＳ、ＥＣＳ、ＭＣＳ、ＳＲＭの各プロセス間のデータシーケンスを示す説明図である。また、図１２は、各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【０１５７】
図１２に示すように、複合機１００にはファックスアプリプロセス１１３、ＦＣＳプロセス１２７、ＦＣＵＨプロセス１２９、ＥＣＳプロセス１２４、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３が動作している。これらプロセスは、複合機１００の起動時に生成されるようになっている。なお、図１２にはファックス送信動作において使用されるプロセスのみを図示しており、実際には他のアプリプロセスおよび他のコントロールサービスのプロセスも複合機の起動時に生成される。
【０１５８】
ファックスアプリプロセス１１３は、複合機１００の起動時に起動され、図１２に示すようにプロセス内に複数のスレッドが起動している。ファックスアプリプロセス１１３は、ＦＣＳプロセス１２７をサーバプロセスとしたクライアントプロセスとなっており、このためＦＣＳプロセス１２７に対するクライアントディスパッチャのスレッドが起動している。
【０１５９】
ＦＣＳプロセス１２７は、ファクシミリ送信動作時には、ファックスアプリプロセス１１３をクライアントプロセスとしたサーバプロセスとなるとともに、ＥＣＳプロセス１２４およびＦＣＵＨプロセス１２９をサーバプロセスとしたクライアントプロセスとなる。このため、ＦＣＳプロセス１２７内にはファックスアプリプロセス１１３に対するサーバディスパッチャのスレッドと、ＥＣＳプロセス１２４に対するクライアントディスパッチャのスレッドと、ＦＣＵＳプロセス１２９に対するクライアントディスパッチャのスレッドと、その他ファクシミリ通信制御に関する処理を行う複数のスレッドが動作している。
【０１６０】
ＦＣＵＨプロセス１２９は、ＦＣＳプロセス１２７のサブプロセスであり、ファクシミリ送信動作時に、ＳＲＭプロセス１２３およびＦＣＳ１２７をクライアントプロセスとしたサーバプロセスとなる。このため、ＦＣＵＨプロセス１２９内にはＳＲＭプロセス１２３およびＦＣＳ１２７に対するサーバディスパッチャのスレッドと、その他ファクシミリデバイスドライバに対する指令などの処理を行う複数のスレッドが動作している。
【０１６１】
ＥＣＳプロセス１２４は、ファクシミリ送信動作時には、ＦＣＳプロセス１２７をクライアントプロセスとしたサーバプロセスとなるとともに、ＭＣＳプロセス１２５およびＳＲＭプロセス１２３をそれぞれサーバプロセスとしたクライアントプロセスとなる。このため、ＥＣＳプロセス１２４内にはＦＣＳプロセス１２７に対するサーバディスパッチャのスレッドと、ＭＣＳプロセス１２５に対するクライアントディスパッチャのスレッドと、ＳＲＭプロセス１２３に対するクライアントディスパッチャのスレッドとその他ジョブ制御およびエンジン制御に関する処理を行う複数のスレッドが動作している。
【０１６２】
ＭＣＳプロセス１２５は、ファクシミリ送信動作時には、ＥＣＳプロセス１２４をクライアントプロセスとしたサーバプロセスとなるとともに、ＳＲＭプロセス１２３をサーバプロセスとしたクライアントプロセスとなる。このため、ＭＣＳプロセス１２５内にはＥＣＳプロセス１２４に対するサーバディスパッチャのスレッドと、ＳＲＭプロセス１２３に対するクライアントディスパッチャのスレッドと、その他メモリ制御およびハードディスク制御に関する処理を行う複数のスレッドが動作している。
【０１６３】
ＳＲＭプロセス１２３は、ＥＣＳプロセス１２４およびＭＣＳプロセス１２５をクライアントプロセスとしたサーバプロセスとなるとともに、ＦＣＵＨプロセス１２９をサーバプロセスとしたクライアントプロセスとなる。このため、ＳＲＭプロセス１２３内にはＥＣＳプロセス１２４およびＭＣＳプロセス１２５に対するサーバディスパッチャのスレッドと、ＦＣＵＨプロセス１２９をサーバプロセスとしたクライアントディスパッチャと、その他エンジン資源制御に関する処理を行う複数のスレッドが動作している。
【０１６４】
実施の形態１におけるファックスアプリ１１３では、送信スタート要求関数コールを行う処理、送信モード変更要求を行う処理をそれぞれ一スレッドとしている。ＦＳＣプロセス１２７では、ファックス送信動作時におけるジョブ動作モード設定関数コールとジョブスタート要求関数コールを行う一連の処理、スキャンパラメータ要求メッセージを受信してスキャンパラメータを送信する処理、ＥＯＭ（次ページ有り），ＥＯＦ（次ページ無し）などの次ページ情報メッセージを通知する処理をそれぞれ一スレッドとしている。
【０１６５】
ＥＣＳプロセス１２４では、メモリ確保要求関数コールと資源獲得要求関数コールを行う一連の処理、スキャン・フィードインプロセス生成指示メッセージを送信する処理をそれぞれ一スレッドとしている。ＭＣＳプロセス１２５では、メモリ確保要求関数コールを行う処理、その他メッセージを送信する処理を一スレッドとしている。
【０１６６】
ＳＲＭプロセス１２３では、フィードスタートメッセージとフィードイン終了メッセージとスタンプ実行指示メッセージを送信する一連の処理、スキャン・フィードインプロセス実行処理をそれぞれ一スレッドとしている。ＦＣＵＨ１２９では、ＥＯＭ，ＥＯＦなどの次ページ情報メッセージを送信する処理を一スレッドとしている。なお、ファクシミリ送信動作時においても、これら各スレッドにおける処理は一例であり、各プログラムで任意に定めることができる。
【０１６７】
ファクシミリ送信要求があると、ファックスアプリプロセス１１３は、新たなファクシミリ送信ジョブを生成し、スレッド１からＦＣＳプロセス１２７に対して送信スタート要求関数コールを行い（ステップＳ１１０１）、スレッド１が関数戻り待ち状態となる。ＦＣＳプロセス１２７では、サーバディスパッチャがファックスアプリプロセス１１３から送信スタート要求関数コールを受信して、送信スタート要求関数ハンドラを起動し、送信スタート要求関数ハンドラのスレッド３によってＭＣＳプロセス１２５に対してジョブ動作モード設定要求関数コールを行い（ステップＳ１１０２）、スレッド３が関数戻り待ち状態となる。
【０１６８】
ＥＣＳプロセス１２４では、サーバディスパッチャがＦＣＳプロセス１２７からジョブ動作モード設定要求関数コールを受信して、ジョブ動作モード設定要求関数ハンドラによってファクシミリ送信ジョブに上述の動作モードを設定して関数戻り値をＦＣＳプロセス１２７のクライアントディスパッチャへ送信する。
【０１６９】
ＦＣＳプロセス１２７のクライアントディスパッチャは、ＥＣＳプロセス１２４からジョブ動作モード設定要求関数の戻り値を受信し、スレッド３はクライアントディスパッチャ経由でこの戻り値を受信する。これにより、スレッド３は関数戻り待ち状態を抜け、ついでＥＣＳプロセス１２４に対しジョブスタート要求関数コールを行い（ステップＳ１１０３）、スレッド３は関数戻り待ち状態となる。
【０１７０】
このジョブスタート要求関数コールを受信したＭＣＳプロセス１２５は、ジョブスタート要求関数ハンドラによって、ＭＣＳ１２５に対しメモリ確保要求関数コールを行い（ステップＳ１１０４）、ＳＲＭプロセス１２３に対し資源獲得要求関数コールを行う（ステップＳ１１０６）。これらの関数コールを受信したＭＣＳプロセス１２５、ＳＲＭプロセス１２３の処理およびＥＣＳプロセス１２４における各関数の戻り値の受信に伴う処理は、コピー動作時の処理と同様であるので説明を省略する。
【０１７１】
ＥＣＳプロセス１２４では、スキャナエンジンの資源獲得関数の戻り値を受信したら、スレッド７においてＦＣＳプロセス１２７に対しスキャナパラメータ確定要求メッセージを送信する（ステップＳ１１０７）。ここで、スキャナパラメータとは、たとえばファイン、ノーマルなどのスキャン濃度や原稿サイズ等である。ＦＣＳプロセス１２７では、このスキャナパラメータ確定要求メッセージを受信すると、スレッド４においてスキャナパラメータをＥＣＳプロセス１２４に対してメッセージとして送信する（ステップＳ１１０８）。
【０１７２】
ＥＣＳプロセス１２４では、スキャナパラメータメッセージをサーバディスパッチャが受信して、スキャンパラメータ確定要求メッセージを送信したスレッド７に通知し、スレッド７はＳＲＭプロセス１２３に対してスキャン・フィードインプロセスの生成指示メッセージを送信する（ステップＳ１１０９）。ＳＲＭプロセス１２３は、スキャン・フィードインプロセスの生成指示メッセージを受信すると、スレッド１１によりスキャン・フィードインプロセスを生成して実行させる（ステップＳ１１１０）。
【０１７３】
ついでＦＣＵＨプロセス１２９に対して原稿のフィードインスタートメッセージを送信する（ステップＳ１１１１）。ＦＣＵＨプロセス１２９がフィードインスタートメッセージを受信して、原稿フィードインが開始され、これにより原稿のスキャンおよび指定宛先への送信が開始する。
【０１７４】
原稿のスキャンが開始されると、次ページの原稿があるか否かを示す、次ページ原稿有無通知メッセージがスキャナエンジンからＥＣＳプロセスに対して送信される。図１１の例では、次ページ原稿有通知メッセージが通知されている（ステップＳ１１１２）。そして、原稿のスキャンを終了すると、スキャナエンジンからＥＣＳプロセス１２４に対してスキャン終了メッセージが送信される（ステップＳ１１１３）。
【０１７５】
ＥＣＳプロセス１２４は、受信したスキャン終了メッセージを次ページ原稿有の旨とともにＦＣＳプロセス１２７へ送信する（ステップＳ１１１４）。一方、原稿スキャンが終了すると、ＳＲＭプロセス１２３はＦＣＵＨプロセス１２９に対してフィードイン終了を指示し（ステップＳ１１１５）、これにより原稿フィードインが終了する。
【０１７６】
ここで、ファックスアプリプロセス１１３がＦＣＳプロセス１２７に対して送信モード変更要求関数コールを行った場合には（ステップＳ１１０５）、ＥＣＳプロセス１２４は、スレッド６においてスキャンパラメータ確定要求メッセージをＦＣＳプロセス１２７に対して送信し、これに対し上述のようにＦＣＳプロセス１２７は、スキャンパラメータメッセージをＥＣＳプロセス１２４に送信する（ステップＳ１１１８）。ＥＣＳプロセス１２４では、スキャンパラメータメッセージを受信すると、次ページ目のスキャン・フィードインプロセスの実行をＳＲＭプロセス１２３に指示して、実行が開始する（ステップＳ１１１９、Ｓ１１２０）。
【０１７７】
一方、１ページの指定宛先へのファクシミリ送信が完了すると、ＦＣＳプロセス１２７は、スレッド５においてＥＯＭメッセージ（異なる送信モードで次ページ有り）をＦＣＵＨプロセス１２９へ送信し（ステップＳ１１２１）、これを受信したＦＣＵＨプロセス１２９はスレッド１３によりＥＯＭを指定宛先へ送信する（ステップＳ１１２２）。
【０１７８】
ＦＣＵＨプロセス１２９が指定宛先から受信正常の通知を受けた場合には（ステップＳ１１２３）、ＳＲＭプロセス１２３に対して送信成功メッセージを送信し（ステップＳ１１２４）、これを受信したＳＲＭプロセス１２３はＥＣＳプロセス１２４に対してプロセス正常終了メッセージを送信する（ステップＳ１１２５）。さらにこれを受信したＥＣＳプロセス１２４はＦＣＳプロセス１２７に対し１ページ目のスキャン処理完了通知メッセージを送信する（ステップＳ１１２６）。そして、送信成功メッセージを受信したＳＲＭプロセス１２３は指示により、送信日時、発信元等のスタンプを指定宛先へ送信する旨をスキャナエンジンに指示する（ステップＳ１１２７）。
【０１７９】
ＳＲＭプロセス１２３は、２ページ目の原稿のフィードインを開始するため、ＦＣＵＨプロセス１２９に対して原稿のフィードインスタートメッセージを送信する（ステップＳ１１２８）。ＦＣＵＨプロセス１２９はフィードインスタートメッセージを受信して、原稿フィードインが開始され、これにより２ページ目の原稿のスキャンおよび指定宛先への送信が開始する。
【０１８０】
原稿のスキャンが開始されると、次ページ原稿有無通知メッセージがスキャナエンジンからＥＣＳプロセスに対して送信され、図１１の例では、次ページ原稿有無通知メッセージが通知され、ＥＣＳプロセス１２４のスレッド９に通知されている（ステップＳ１１２９）。そして、原稿のスキャンが終了すると、スキャナエンジンからＥＣＳプロセス１２４に対してスキャン終了メッセージが送信される（ステップＳ１１３０）。
【０１８１】
ＥＣＳプロセス１２４のスレッド９は、受信したスキャン終了メッセージを次ページ原稿無の旨とともにＦＣＳプロセス１２７へ送信する（ステップＳ１１３１）。一方、スキャンが終了すると、ＳＲＭプロセス１２３ではスレッド１３がＦＣＵＨプロセス１２９に対してフィードイン終了を指示し（ステップＳ１１３２）、これにより原稿フィードインが終了する。
【０１８２】
２ページの指定宛先へのファクシミリ送信が完了すると、ＦＣＳプロセス１２７では、スレッド５がＥＯＦメッセージ（次ページ無し）をＦＣＵＨプロセス１２９へ送信し（ステップＳ１１２４）、これを受信したＦＣＵＨプロセス１２９はスレッド１３によりＥＯＦを指定宛先へ送信する。
【０１８３】
ＦＣＵＨプロセス１２９が指定宛先から受信正常の通知を受けた場合には（ステップＳ１１３５）、スレッド１３によりＳＲＭプロセス１２３に対して送信成功メッセージを送信し（ステップＳ１１３６）、これを受信したＳＲＭプロセス１２３は、スレッド１２によりＥＣＳプロセス１２４に対してプロセス正常終了メッセージを送信する（ステップＳ１１３７）。
【０１８４】
さらにこれを受信したＥＣＳプロセス１２４は、スレッド９によりＦＣＳプロセス１２７に対し２ページ目のスキャン処理完了通知メッセージを送信する（ステップＳ１１３８）。また、送信成功メッセージを受信したＳＲＭプロセス１２３は、スレッド１２により、送信日時、発信元等のスタンプの指定宛先へ送信の指示を行う（ステップＳ１１３９）。
【０１８５】
そして、ＥＣＳプロセス１２４は、ＦＣＳプロセス１２７にジョブエンド通知メッセージを送信し（ステップＳ１１４０）、ＦＣＳプロセス１２７では、このジョブエンド通知メッセージをクライアントディスパッチャで受信することにより全ての原稿のファックス送信動作が完了する。
【０１８６】
このように、実施の形態１の複合機では、各アプリプロセスなどクライアントとなるプロセスが、ＥＣＳプロセス、ＭＣＳプロセス、ＳＲＭプロセスなどのサーバとなるプロセスに対し、関数コールによってサービスを要求し、またメッセージの送受信を行うことでプロセス間通信を実現することができる。このため、アプリケーション１３０とプラットホーム１２０という特殊な構成を有する複合機において、複合サービスという多種多様な機能を実現することができる。
【０１８７】
また、実施の形態１の複合機では、関数コールによるサービス要求の結果としての関数戻り値をクライアントディスパッチャにより監視して受信することにより、プロセス内のスレッド間の同期制御を容易に行うことができる。このため、アプリプロセス、複数のコントロールサービスの一部のモジュールのみに変更がある場合でも、関数コールとその関数戻り値の制御を確実に設計しておけば他のプロセスとのインタフェースの変更は不要となるので、各アプリごと、各コントロールサービスごとの機能変更などに対応することが容易に行え、複合機の構成に可変性を持たせることが可能となる。
【０１８８】
さらに、実施の形態１の複合機では、スレッドにより並列実行を可能としながら、スレッドに親和性のある関数コールとその関数戻り値の制御によりプロセス間通信におけるスレッド間の同期制御を行っているので、並列処理の切り替え時のオーバヘッドを極力少なくして、複合サービス提供時の処理速度を向上させることができる。
（実施の形態２）
実施の形態１にかかる複合機１００では、サーバプロセスとクライアントプロセスとの関係を概念的に説明した。そこで、この実施の形態２では、サーバプロセスおよびクライアントプロセスをより具体的に説明する。なお、実施の形態２にかかる複合機１００の構成は、図１と同様であるため説明を省略する。
【０１８９】
図１３は、実施の形態２の複合機１００上で動作するサーバプロセスとクライアントプロセスの関係を詳細に示すブロック図である。ここで、クライアントプロセス１６００は、サーバプロセス１６１０，１６２０に対して要求を行うことにより、サーバプロセス１６１０，１６２０からサービスの提供を受ける例えばＳＣＳ１２２などのプロセスをいう。また、サーバプロセス１６１０，１６２０は、クライアントプロセス１６００からの要求によりクライアントプロセス１６００に対しサービスを提供する例えばＥＣＳ１２４などのプロセスをいう。
【０１９０】
図１３に示すとおり、クライアントプロセス１６００には複数のスレッド１６０１が起動している。クライアントプロセス１６００は、複数のスレッド１６０１を有することから、複数のサーバプロセス１６１０，１６２０に対して同時にサービスを要求できる。
【０１９１】
また、クライアントプロセス１６００は、サーバプロセス１６１０，１６２０のサービスを要求するために、スレッド１６０１からサーバプロセス１６１０，１６２０に対して関数コールを行い、その関数戻り値を受信することによってプロセス間通信を行う。
【０１９２】
クライアントプロセス１６００のスレッド１６０１は、あらかじめサーバプロセス１６１０，１６２０から提供されている関数をコールする。関数は、クライアントスタブ１６０２に定義されている。また、クライアントディスパッチャ１６０３は関数戻り値の受信を監視するスレッドである。
【０１９３】
クライアントプロセス１６００は、サーバプロセス１６１０，１６２０ごとにクライアントディスパッチャ１６０３を起動してサーバプロセス１６１０，１６２０と通信する。そして、関数コールを受けたサーバプロセス１６１０，１６２０は要求された関数に対応する処理を以下のように実行する。
【０１９４】
例えばサーバプロセス１６１０のサーバディスパッチャ１６１１は、サーバスケルトン１６１２にコーディングされている複数のスレッド１６１３から、要求された関数に対応するスレッド１６１３を選択する。ここで選択されるスレッド１６１３は、実施の形態１で説明した関数ハンドラ４０３に相当する。サーバプロセス１６１０のスレッド１６１３は、要求された処理を実行してその実行結果を関数戻り値としてクライアントプロセス１６００に送信する。
【０１９５】
次に、実施の形態２にかかるクライアントプロセス１６００と、サーバプロセス１６１０，１６２０とを生成する生成方法について説明する。図１４は、実施の形態２のクライアントプロセスとサーバプロセスとを生成する画像形成装置用通信プログラム生成装置（以下、「スタブジェネレータ」という。）の機能的構成を示すブロック図である。スタブジェネレータは、メッセージファイルからヘッダと、クライアントスタブと、サーバスケルトンを自動生成するものである。
【０１９６】
図１４に示すように、スタブジェネレータは、メッセージファイル１７０１を入力する入力部１７０２と、メッセージファイル１７０１に記述された内容の構文チェックを行う構文解析部１７０３と、メッセージファイル１７０１の記述内容から、ヘッダ１７０６とクライアントスタブ１７０７と、サーバスケルトン１７０５とを生成してハードディスク等の記憶媒体に格納するコード生成部１７０４とを備えている。
【０１９７】
まず、スタブジェネレータに入力されるメッセージファイル１７０１と、スタブジェネレータで生成されるヘッダ１７０６、クライアントスタブ１７０７およびサーバスケルトン１７０５について説明する。
【０１９８】
メッセージファイル１７０１は、プロセス間通信の通信内容をＣ言語などのソースコードで記述したソースファイルである。図１５は、メッセージファイルの記述例を示す説明図である。図１５に示すように、メッセージファイル１７０１には、別のメッセージファイルや、Ｃ言語記述のインクルードヘッダを宣言するインクルード宣言と、サーバプロセスとクライアントプロセスの間で送受信するメッセージを記述したメッセージ記述と、クライアントプロセスからサーバプロセスに対して発行する関数の宣言などが記述されている。
【０１９９】
メッセージは、主としてサーバプロセスとクライアントプロセスとの間でイベ
ントや通知を行う際に発行するものであり、メッセージファイル１７０１のメッセージ記述としては、メッセージ名と、メッセージＩＤと、メッセージ方向、メッセージ内容を記述するようになっている。
【０２００】
メッセージ方向には、「ＩＮ」、「ＯＵＴ」、「ＳＥＬＦ」がある。「ＩＮ」は、クライアントプロセスからサーバプロセスに対して送信するメッセージを意味する。「ＯＵＴ」は、サーバプロセスからクライアントプロセスに対して送信するメッセージを意味する。また、「ＳＥＬＦ」は自分自身のプロセスに対して送信するメッセージを意味する。
【０２０１】
関数は、クライアントプロセスからサーバプロセスに処理要求や設定要求を行
う際に発行するものである。メッセージファイル１７０１の関数宣言には、関数名と、関数の型と、引数のみを記述し、関数の処理内容は記述しないようになっている。
【０２０２】
クライアントスタブ１７０７は、クライアントプログラムから呼び出される関数のサーバプロセスに対する発行を記述したソースファイルである。クライアントスタブ１７０７をコンパイルしてライブラリ化し、クライアントプログラムとリンクすることにより、クライアントプログラムからの関数コールがクライアントスタブ１７０７を介してサーバプロセスへ発行されるようになっている。
【０２０３】
図１６はスタブジェネレータにより生成されるクライアントスタブ１７０７の一例を示す説明図である。図１６に示すように、クライアントスタブ１７０７には、後述するサーバスケルトン１７０５に登録された関数ハンドラを呼び出すことにより、関数コールが行われるようになっている。サーバスケルトン１７０５は、クライアントスタブ１７０７から呼び出された関数ハンドラとメッセージハンドラを登録したソースファイルである。
【０２０４】
図１７は、スタブジェネレータにより生成されるサーバスケルトン１７０５の一例を示す説明図である。図１７に示すように、サーバスケルトン１７０５にはクライアントスタブ１７０７に記述された関数に対応した関数ハンドラが登録されている。
【０２０５】
関数ハンドラでは引数の受け渡し部のみが記述され、処理内容を記述する実装記述部は空欄の状態で生成されている。この実装記述部には、クライアントプログラムからクライアントスタブ１７０７を介して発行される関数の処理内容を、サーバプログラムの開発者が自在に記述できるようになっている。ヘッダ１７０６は、サーバスケルトン１７０５とクライアントスタブ１７０７で共通の定義、宣言などを記述したソースファイルである。
【０２０６】
図１８はスタブジェネレータにより生成されるヘッダ１７０６の一例を示す説明図である。図１８に示すように、ヘッダ１７０６には、メッセージファイル１７０１に記述されたインクルード宣言、メッセージＩＤ、メッセージの構造体などのメッセージ宣言、関数宣言および関数ハンドラ宣言などが記述された状態で生成されるようになっている。
【０２０７】
次に、スタブジェネレータによるサーバスケルトン１７０５、クライアントスタブ１７０７およびヘッダ１７０６の生成処理について説明する。図１９は、サーバスケルトン、クライアントスタブおよびヘッダの生成処理のフローチャートである。
【０２０８】
スタブジェネレータの構文解析部１７０３は、メッセージファイル１７０１に記述された関数宣言、メッセージ定義、インクルード宣言、Ｃ言語記述の文法チェックを行い（ステップＳ１８０１）、さらにメッセージファイル１７０１に定義されている関数名およびメッセージ定義の中のメッセージＩＤ、メッセージ名の一意性の判断を行う（ステップＳ１８０２）。
【０２０９】
そして、関数宣言、メッセージ定義、インクルード宣言の記述に文法エラーがあった場合、あるいは関数名、メッセージＩＤ、メッセージ名のいずれかが重複している場合には、ユーザに構文エラーである旨のメッセージを通知し処理を終了する（ステップＳ１８０３、Ｓ１８０４）。
【０２１０】
構文解析後、コード生成部１７０４は、メッセージファイル１７０１の記述内容から、ヘッダ１７０６と、サーバスケルトン１７０５と、クライアントスタブ１７０７を生成する。具体的には、メッセージファイル１７０１のインクルード宣言とＣ言語記述とをヘッダ１７０６にそのまま転記し、メッセージファイル１７０１のメッセージ定義に記述されているメッセージ構造体をヘッダ１７０６にコピーする（ステップＳ１８０５）。
【０２１１】
また、コード生成部１７０４は、メッセージファイル１７０１の関数宣言から関数ハンドラ名を自動生成し（例えば、関数名ａｂｃの場合、関数ハンドラ名をａｂｃ＿ｈａｎｄｌｅｒとして生成する）、生成された関数ハンドラ名をサーバスケルトン１７０５内に登録する。
【０２１２】
そして、関数ハンドラの処理内に、引数受け渡しの記述を行うとともに、戻り値領域の生成システムコールの発行を記述する。関数ハンドラの実際の処理内容を記述する実装記述部の欄を空欄とし、その実装記述部の後に、戻り値送信と戻り値領域解放の各システムコールの発行を記述する（ステップＳ１８０６）。
【０２１３】
また、コード生成部１７０４は、メッセージファイル１７０１に記述された関数宣言ごとに、関数名と引数の記述をクライアントスタブ１７０７に登録し、その関数の処理内に、関数コールメッセージ生成コールと関数ハンドラの呼び出しと戻り値解放の各システムコールを記述する（ステップＳ１８０７）。なお、関数ハンドラ呼び出しには、発行した関数の戻り値の待ち受ける関数戻り値待ちシステムコールが内部的に発行されるようになっている。
【０２１４】
このようにスタブジェネレータにより、クライアントスタブ１７０７とサーバスケルトン１７０５とヘッダ１７０６を生成したら、次にサーバオブジェクトおよびクライアントオブジェクトを完成させる。
【０２１５】
サーバプログラムの開発者は、サーバスケルトン１７０５の関数ハンドラの実装記述部（空欄）に、関数ハンドラで行うべき処理内容をエディタなどを利用して記述し、サーバスケルトン１７０５をヘッダ１７０６とともにコンパイルしてサーバスタブオブジェクトを生成する。また、サーバスケルトン１７０５に登録した関数ハンドラを宣言するとともに、クライアントプロセスとの間でメッセージファイル１７０１に記述されたメッセージの送受信を行うメッセージハンドラ、エラー処理を行うエラーハンドラ、サーバの初期化、サーバディスパッチャ起動等のシステムコールの発行を記述したサーバソースファイルを作成してコンパイルし、サーバスタブオブジェクトとリンクして、サーバプログラムを完成させる。
【０２１６】
一方、クライアントスタブ１７０７はヘッダ１７０６とともにコンパイルしてクライアントスタブオブジェクトを生成する。サーバプロセスごとにクライアントスタブオブジェクトを生成し、生成した複数のクライアントスタブオブジェクトをライブラリとする。
【０２１７】
また、関数の発行、関数ハンドラの宣言、エラー処理を行うエラーハンドラの宣言、クライアントプロセスとの間でメッセージファイル１７０１に記述されたメッセージの送受信を行うメッセージハンドラ、およびクライアントプロセスの初期化やクライアントディスパッチャ起動等のシステムコールの発行を記述したクライアントプログラムを作成してコンパイルし、スタブのライブラリとリンクすることによりクライアントプログラムを完成させる。
【０２１８】
図２０は、クライアントプログラムから関数コールを行った場合におけるサーバプログラムとの呼び出しおよび応答のシーケンスを示す説明図である。なお、サーバプログラムとクライアントプログラムは実際は実行可能形式のオブジェクトファイルであるが、図２０では、説明の都合上いずれもソースコードで表示している。
【０２１９】
クライアントプログラムからサーバプログラムに対して、たとえばＯｐｅｎ関数をコールすると、クライアントスタブオブジェクトで定義されたＯｐｅｎが呼び出される（ステップＳ１９０１）。そして、このスタブのＯｐｅｎの処理の中で、Ｏｐｅｎの関数ハンドラＯｐｅｎ＿ｈａｎｄｌｅｒがサーバプログラムに対してコールされる（ステップＳ１９０２）。
【０２２０】
サーバプログラムでは、クライアントスタブオブジェクトから関数ハンドラＯｐｅｎ＿ｈａｎｄｌｅｒの発行を受け取って、サーバスタブオブジェクトに登録されているＯｐｅｎ＿ｈａｎｄｌｅｒの実装記述部に記述されている処理を実行し（ステップＳ１９０３）、その実行結果をクライアントスタブへ戻り値として返す（ステップＳ１９０４）。クライアントプログラムでは、この戻り値をクライアントスタブから受け取って（ステップＳ１９０５）、次の処理へ移行する。
【０２２１】
このように実施の形態２のスタブジェネレータでは、メッセージファイル１７０１に関数宣言を記述することによりクライアントスタブ１７０７とサーバスケルトン１７０５を容易に生成することができる。しかも生成されるサーバスケルトン１７０５の実装記述部は空欄となっているので、プログラム開発者は必要に応じて関数の処理内容を容易に変更するができる。
【０２２２】
このため複合機１００に可変性をもたせることができるとともに、多種多様な機能を実現させることができる。さらに、サードベンダーなどの他社がクライアントプログラムの開発を行う場合でも、クライアントプログラムには提供される関数コールを記述するだけでプロセス間通信が可能となるので、内部の通信プロトコルの隠蔽性を保つことが可能となる。
【０２２３】
また、実施の形態２のスタブジェネレータでは、プロセス間通信を関数コールで実現しているので、ジョブの並列実行をスレッドで実現した場合でも、高速なプロセス間通信が可能となる。また、関数からの戻り値によってスレッド間の同期をとることができるので、同期のための処理プログラムを別途作成する必要がなくなり、プログラム開発の労力を低減することができる。
（実施の形態３）
実施の形態１にかかる複合機１００は、クライアントプロセスとなるアプリプロセスが、サーバプロセスとなる各コントロールサービスと同一複合機内部で動作していた。この実施の形態３にかかる複合機１００は、ネットワークに接続された他の複合機のアプリプロセスをクライアントプロセスとして各コントロールサービスがサービスを提供するものである。
【０２２４】
図２１は、実施の形態３にかかる複合機の構成を示すブロック図である。図２１に示すように、実施の形態３では複数の複合機１３００ａ，１３００ｂがＬＡＮなどのネットワーク１３４０によって接続された構成となっている。なお、図２１では、２台の複合機１３００ａ，１３００ｂがネットワーク１３４０で接続された構成となっているが、３台以上の複合機をネットワーク１３４０で接続した構成でもよい。
【０２２５】
図２１に示すように、ネットワーク１３４０上の各複合機１３００ａ，１３００ｂは、実施の形態１の複合機と同様の構成となっている。このため、これらの構成について詳細な説明は省略する。
【０２２６】
実施の形態３の複合機では、実施の形態１と同様に、主としてコピーアプリ１３１２、プリンタアプリ１３１１、スキャナアプリ１３１４、ファックスアプリ１３１３などのアプリケーションのプロセス、およびＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロールサービスのプロセスが、コントロールサービスまたはＳＲＭ１３２３をサーバプロセスとしたクライアントプロセスとなるが、さらにネットワークに接続された他の複合機内部で動作しているＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロールサービスをサーバプロセスとしたクライアントプロセスとなる。
【０２２７】
また、実施の形態３の複合機では、実施の形態１と同様に、主としてＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロールサービスおよびＳＲＭ１３２３のプロセスが、アプリケーションのプロセスまたはコントロールサービスもしくはＳＲＭ１３２３のプロセスをクライアントプロセスとしたサーバプロセスとなるが、さらにネットワークに接続された他の複合機内部で動作しているコピーアプリ１３１２、プリンタアプリ１３１１、スキャナアプリ１３１４、ファックスアプリ１３１３などのアプリケーションのプロセスをクライアントプロセスとしたサーバプロセスにもなる。
【０２２８】
実施の形態３の複合機におけるこれらサーバプロセスとクライアントプロセスの関係、およびサーバプロセス、クライアントプロセスの各構成は実施の形態１の複合機で説明した図２および図３と同様であるので詳細な説明は省略する。
【０２２９】
各コントロールサービスとＳＲＭ１３２３と各アプリとは、実施の形態１の複合機１００と同様に、それぞれプロセスとして汎用ＯＳ上に生成されて実行される。各プロセス内部には、複数のスレッドが起動され、汎用ＯＳの管理下でこれらのスレッドのＣＰＵ占有時間を切り替えることにより並列実行が実現されている。
【０２３０】
また、実施の形態３の複合機１３００ａ，１３００ｂでは、アプリケーションなどのクライアントプロセスは、コントロールサービスなどのサーバプロセスのサービスを要求するために、クライアントプロセス内のスレッドからサーバプロセスに対して関数コールを行い、その関数戻り値を受信すること、およびスレッドからメッセージをサーバプロセスに送信することによってプロセス間通信を行う。そして、さらにネットワーク上の他の複合機で動作するサーバプロセスに対して関数コールおよびメッセージの送信も行えるようになっている。
【０２３１】
一方、コントロールサービスなどのサーバプロセスでは、クライアントプロセスに対するプロセス間通信はメッセージの送信のみで行われる。さらにサーバプロセスでは、ネットワーク上の他の複合機で動作するプロセスをクライアントプロセスとして、このネットワーク上のクライアントプロセスに対してメッセージの送信も可能となっている。
【０２３２】
クライアントプロセスで起動されるクライアントディスパッチャは実施の形態１の複合機１００と同様の構成をしており、さらにネットワーク１３４０に接続された他の複合機からの関数戻り値およびＯＵＴ方向のメッセージの受信も監視している。
【０２３３】
このため、ネットワーク上の他の複合機のプロセスとプロセス間通信を行えるように、クライアントプロセスから発行する関数の形式およびメッセージの形式は、ネットワークアドレスなどの情報を指定できるような形式で提供される。
【０２３４】
サーバプロセスで起動されるサーバディスパッチャも、実施の形態１の複合機１００におけるサーバプロセスと同様の構成をしているが、さらにネットワーク１３４０に接続された他の複合機で動作するクライアントプロセスのスレッドからの関数コールおよびＩＮ方向のメッセージも監視している。
【０２３５】
サーバプロセスでは、関数コールをサーバディスパッチャで受信したときに実行される関数ハンドラが、ネットワーク１３４０上のクライアントプロセスに関数戻り値を返すために、関数コールしたプロセスの存在する複合機のネットワークアドレスなどを指定できるようになっている。また、サーバプロセスから送信するメッセージもネットワークアドレスなどを指定できるようになっている。
【０２３６】
次に、このように構成された実施の形態３にかかる複合機１３００ａ，１３００ｂにおいて、ネットワーク１３４０上の異なる複合機を利用してプリント動作を行う場合のプロセス間通信について説明する。図２２は、実施の形態３のネットワークに接続された２つの複合機を利用してプリンタ動作を行う場合のプリンタアプリ、ＥＣＳのプロセス間のデータシーケンスを示す説明図である。
【０２３７】
プリンタアプリプロセス１３１１が印刷要求を受信した場合には（ステップＳ１４０１）、実施の形態１において図５を用いて説明したとおり、複合機１３００ａのプリンタアプリプロセス１３１１のスレッドがＥＣＳプロセス１３２４に対して、ジョブ動作モード設定関数コールとジョブスタート要求関数コールを順次行う。
【０２３８】
実施の形態３では、このとき、複合機１３００ａのプリンタアプリプロセス１３１１が、ネットワーク１３４０を介して接続された他の複合機１３００ｂのネットワークアドレスを指定し、ジョブ動作モード設定関数コールとジョブスタート要求関数コールを行っている（ステップＳ１４０２、Ｓ１４０４）。
【０２３９】
これにより、ジョブ動作モード設定関数コール、ジョブスタート要求関数コールは、自己の複合機１３００ａのＥＣＳプロセス１３２４ではなく、ネットワークアドレスで指定された複合機１３００ｂのＥＣＳプロセス１３２４に対して送信される。そして、それぞれの関数コールを行ったスレッドは関数戻り待ち状態になる。
【０２４０】
複合機１３００ｂのＥＣＳプロセス１３２４では、サーバディスパッチャがネットワーク１３４０を介してジョブ動作モード設定関数コール、ジョブスタート要求関数コールをそれぞれ受信し、各関数ハンドラによってプリンタジョブの動作モード設定、プリンタジョブの開始処理を行う。そして、ジョブ動作モード設定関数の戻り値およびジョブオープン関数の戻り値を、複合機１３００ａのネットワークアドレスを指定して送信する（ステップＳ１４０３、Ｓ１４０５）。
【０２４１】
複合機１３００ａのプリンタアプリプロセス１３１１では、クライアントディスパッチャによって複合機１３００ｂのＥＣＳプロセス１３２４からのジョブ動作モード設定関数の戻り値およびジョブオープン関数の戻り値を受信する。そして、実施の形態１の複合機と同様に、関数戻り待ち状態のスレッドを関数戻り待ちキューから抽出して、ジョブ動作モード設定関数の戻り値とジョブオープン関数の戻り値のそれぞれを抽出されたスレッドに送信する。
【０２４２】
これ以降のＥＣＳプロセス１３２４、ＭＣＳプロセス１３２５、ＳＲＭプロセス１２３との間のプロセス間通信は同一複合機内部で行われるものであり、実施の形態１で説明したプリンタ動作と同様である。これにより、複合機１３００ａにおける印刷要求に対して、実際のプリント処理が複合機１３００ｂで行われることになる。
【０２４３】
複合機１３００ｂにおけるプリント処理が終了すると、複合機１３００ｂのＥＣＳプロセス１３２４はジョブエンド通知メッセージをプリンタアプリプロセスに送信する。このとき、ＥＣＳプロセス１３２４のサーバディスパッチャは、ネットワーク１３４０上の複合機１３００ａのネットワークアドレスを指定してジョブエンド通知メッセージを送信する（ステップＳ１４０６）。
【０２４４】
複合機１３００ａのプリンタアプリプロセス１３１１では、クライアントディスパッチャによって、ネットワークを介して送信されてきたジョブエンド通知メッセージを受信し、これによりプリンタ動作を完了する。
【０２４５】
このように、実施の形態３では、ネットワークに接続された複合機１３００ａで動作するアプリプロセスと、複合機１３００ｂで動作するＥＣＳプロセス１３２４との間でプロセス間通信を行って、複合機１３００ａで発生した要求に対しネットワーク１３４０上の他の複合機１３００ｂでプリント処理を行えるので、要求の生じた複合機のみならずネットワーク上の複合機を利用して多種多様な機能を実現することができる。
【０２４６】
例えば、複合機１３００ａで印刷要求が生じたときに、複合機１３００ａのプリンタエンジンが他のジョブに占有されている場合には、プリンタアプリプロセスでこれを判断してＥＣＳプロセス１３２４に対する関数コールをネットワーク１３４０上の他の複合機１３００ｂのＥＣＳプロセス１３２４への関数コールへ切り替える等の処理を行えば、プリント開始までに時間を要することを防止でき、ユーザビリティの向上を図ることができる。
【０２４７】
なお、実施の形態３では、プリンタ動作の例をあげてネットワーク１３４０に接続された２つの複合機１３００ａ，１３００ｂにおけるプロセス間通信について説明したが、スキャナ動作、コピー動作、ファクシミリ送信動作においても、複合機１３００ａ内のスキャナアプリプロセス１３１４、コピーアプリプロセス１３１２、ファックスアプリプリセス１３１３と、ＥＣＳプロセス１３２４とのプロセス間通信もプリンタ動作の場合と同様に行われる。
【０２４８】
また、実施の形態３の複合機１３００ａ，１３００ｂでは、アプリプロセスとＥＣＳプロセス１３２４とネットワーク１３４０を介したプロセス間通信に説明したが、アプリプロセスとＥＣＳプロセス１３２４以外のコントロールサービスおよびシステムリソースマネージャ（ＳＲＭ）１３２３のプロセス間通信も、アプリプロセスとＥＣＳプロセス１３２４間の通信と同様に行われる。
【０２４９】
さらに、実施の形態３の複合機１３００ａ，１３００ｂでは、アプリプロセスとネットワーク１３４０上の別の複合機内のＥＣＳプロセス１３２４とが直接プロセス間通信を行っているが、ＮＣＳ１３２８を介して異なる複合機のアプリプロセスとＥＣＳプロセス１３２４とが通信を行うように構成しても良い。
【０２５０】
すなわち、ＮＣＳ１３２８において、アプリプロセスからの関数コールやメッセージを一旦受信して、ネットワーク１３４０上の他の複合機１３００ｂのネットワークアドレスを指定した上で、関数コールやメッセージを複合機１３００ｂのＮＣＳプロセス１３２８へ送信するように構成することも可能である。
【０２５１】
この場合には、アプリプロセスやＥＣＳプロセス１３２４において、ネットワークアドレスに関する処理の追加が不要となり、モジュール間の独立性がより高まるので、複合機により可変性を持たせることができるという利点がある。
（実施の形態４）
実施の形態３にかかる複合機１３００ａ，１３００ｂでは、ネットワーク１３４０に接続された他の複合機のアプリプロセスをクライアントプロセスとして各コントロールサービスがサービスを提供していた。この実施の形態４にかかる複合機は、ネットワークに接続された他の複合機のコントロールサービスをクライアントプロセスとして、各コントロールサービスがサービスを提供するものである。
【０２５２】
実施の形態４では、図２１に示す実施の形態３の複合機１３００ａ，１３００ｂと同様に、複数の複合機がＬＡＮなどのネットワーク１３４０によって接続された構成となっている。実施の形態４におけるネットワーク１３４０上の各複合機１３００ａ，１３００ｂは、実施の形態１の複合機と同様の構成であるため、これらの構成について詳細な説明は省略する。
【０２５３】
実施の形態４の複合機では、実施の形態１と同様に、主としてコピーアプリ１３１２、プリンタアプリ１３１１、スキャナアプリ１３１４、ファックスアプリ１３１３などのアプリケーションプロセス、およびＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロールサービスのプロセスが、コントロールサービスまたはＳＲＭ１３２３をサーバプロセスとしたクライアントプロセスとなるが、さらにネットワークに接続された他の複合機内部で動作しているＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロールサービスをサーバプロセスとしたクライアントプロセスとなる。
【０２５４】
また、実施の形態４の複合機では、実施の形態１と同様に、主としてＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロールサービスおよびＳＲＭ１３２３のプロセスが、アプリケーションサービスまたはコントロールサービスもしくはＳＲＭ１３２３をクライアントプロセスとしたサーバプロセスとなるが、さらにネットワークに接続された他の複合機内部で動作しているコントロールサービスをクライアントプロセスとしたサーバプロセスにもなる。
【０２５５】
実施の形態４の複合機１３００ａ，１３００ｂにおけるこれらサーバプロセスとクライアントプロセスの関係、およびサーバプロセス、クライアントプロセスの各構成は実施の形態１の複合機で説明した図２および図３、および実施の形態３と同様であるので詳細な説明は省略する。
【０２５６】
実施の形態４の複合機１３００ａ，１３００ｂでは、コントロールサービスがクライアントプロセスとなる場合に、他のコントロールサービスなどのサーバプロセスのサービスを要求するために、クライアントプロセス内のスレッドからサーバプロセスに対して関数コールを行い、その関数戻り値を受信すること、およびスレッドからメッセージをサーバプロセスに送信することによってプロセス間通信を行う。そして、さらにネットワーク１３４０上の他の複合機で動作する他のコントロールサービスまたはＳＲＭ１３２３などのサーバプロセスに対して関数コールおよびメッセージの送信も行えるようになっている。
【０２５７】
コントロールサービスなどのクライアントプロセスで起動されるクライアントディスパッチャは、実施の形態３の複合機１３００ａ，１３００ｂと同様に、ネットワーク１３４０に接続された他の複合機で動作するコントロールサービスまたはＳＲＭ１３２３（サーバプロセス）からの関数戻り値およびＯＵＴ方向のメッセージの受信も監視している。
【０２５８】
このため、ネットワーク１３４０上の他の複合機のプロセスとプロセス間通信を行えるように、クライアントプロセスから発行する関数の形式およびメッセージの形式は、ネットワークアドレスなどの情報を指定できるような形式で提供される。
【０２５９】
サーバプロセスで起動されるサーバディスパッチャも、実施の形態３の複合機１３００ａ，１３００ｂにおけるサーバプロセスと同様に、ネットワーク１３４０に接続された他の複合機で動作するクライアントプロセスのスレッドからの関数コールおよびＩＮ方向のメッセージも監視している。
【０２６０】
実施の形態４においても、サーバプロセスおよびクライアントプロセスとなるＥＣＳ１３２４、ＭＣＳ１３２５、ＦＣＳ１３２７、ＮＣＳ１３２８などのコントロールサービスおよびＳＲＭ１３２３では、関数コールをサーバディスパッチャで受信したときに実行される関数ハンドラが、関数コールしたクライアントプロセスの存在する複合機のネットワークアドレスなどを指定できるようになっている。また、サーバプロセスから送信するメッセージもネットワークアドレスなどを指定できるようになっている。
【０２６１】
次に、このように構成された実施の形態４にかかる複合機１３００ａ，１３００ｂにおいて、ネットワーク１３４０上の異なる複合機を利用してファクシミリ送信動作を行う場合のプロセス間通信について説明する。図２３は、実施の形態４のネットワークに接続された２つの複合機を利用してファクシミリ送信動作を行う場合のＦＣＳとＥＣＳとＭＣＳのプロセス間のデータシーケンスを示す説明図である。
【０２６２】
ＦＣＳプロセス１３２７がファックスアプリプロセス１３１３から送信スタート要求を受信した場合には（ステップＳ１５０１）、複合機１３００ａのＦＣＳプロセス１３２７のスレッドが、ネットワーク１３４０に接続された他の複合機１３００ｂのネットワークアドレスを指定して、ジョブ動作モード設定関数コールとジョブスタート要求関数コールを順次行う（ステップＳ１５０２、Ｓ１５０４）。
【０２６３】
これにより、ジョブ動作モード設定関数コール、ジョブスタート要求関数コールは、ネットワークアドレスで指定された複合機１３００ｂで動作するＥＣＳプロセス１３２４に対してネットワークを介して送信される。
【０２６４】
複合機１３００ｂのＥＣＳプロセス１３２４では、サーバディスパッチャがネットワーク１３４０を介してジョブ動作モード設定関数コール、ジョブスタート要求関数コールをそれぞれ受信し、各関数ハンドラによってプリンタジョブの動作モード設定、プリンタジョブの開始処理を行う。そして、ジョブ動作モード設定関数の戻り値およびジョブオープン関数の戻り値を、複合機１３００ａのネットワークアドレスを指定して送信する（ステップＳ１５０３、Ｓ１５０５）。
【０２６５】
複合機１３００ａのＦＣＳプロセス１３２７では、クライアントディスパッチャによって複合機１３００ｂのＥＣＳプロセス１３２４からのジョブ動作モード設定関数の戻り値およびジョブオープン関数の戻り値を受信する。そして、実施の形態１の複合機と同様に、関数戻り待ち状態のスレッドを関数戻り待ちキューから抽出して、ジョブ動作モード設定関数の戻り値とジョブオープン関数の戻り値のそれぞれを抽出されたスレッドに送信する。
【０２６６】
複合機１３００ｂのＥＣＳプロセス１３２４は、ＭＣＳプロセス１３２５に対してメモリ確保要求関数コールを行い（ステップＳ１５０５）、またＳＲＭプロセス１２３に対してスキャナエンジンの資源獲得要求関数コールを行う（ステップＳ１５０６）。かかる関数コールに対するＭＣＳプロセス１３２５およびＳＲＭプロセス１３２３の処理は、実施の形態１で説明したとおりである。
【０２６７】
複合機１３００ｂのＥＣＳプロセス１３２４では、スキャナエンジンの資源獲得関数の戻り値を受信したら、複合機１３００ａのネットワークアドレスを指定したスキャンパラメータ要求メッセージを、複合機１３００ａのＦＣＳプロセス１３２７にネットワークを介して送信する（ステップＳ１５０７）。
【０２６８】
複合機１３００ａのＦＣＳプロセス１３２７では、このスキャナパラメータ確定要求メッセージを受信すると、スキャナパラメータのメッセージを、複合機１３００ｂのネットワークアドレスを指定することにより、複合機１３００ｂのＥＣＳプロセス１３２４に対してネットワークを介して送信する（ステップＳ１５０８）。ＥＣＳプロセス１３２４では、サーバディスパッチャがスキャナパラメータメッセージをネットワークを介して受信する。
【０２６９】
これ以降のプロセス間通信は、同一複合機１３００ｂ内部で行われるものであり、実施の形態１で説明したファクシミリ送信と同様である。これにより、複合機１３００ａにおけるファクシミリ送信スタート要求に対して、複合機１３００ｂでファクシミリ送信が行われることになる。複合機１３００ｂにおけるスキャンおよびファクシミリ送信処理が終了すると、複合機１３００ｂのＥＣＳプロセス１３２４のサーバディスパッチャは、ネットワーク１３４０上の複合機１３００ａのネットワークアドレスを指定してスキャン終了通知メッセージを複合機１３００ａのＦＣＳプロセス１３２７に送信する（ステップＳ１５０９）。
【０２７０】
複合機１３００ａのＦＣＳプロセス１３２７では、クライアントディスパッチャによって、ネットワーク１３４０を介して送信されてきたスキャン終了通知メッセージを受信し、これによりファクシミリ送信動作を完了する。
【０２７１】
このように、実施の形態４の複合機では、ネットワークに接続された複合機１３００ａで動作するＦＣＳプロセス１３２７と、複合機１３００ｂで動作するＥＣＳプロセス１３２４との間でプロセス間通信を行って、複合機１３００ａで発生した要求に対しネットワーク１３４０上の他の複合機１３００ｂでファクシミリ送信処理を行えるので、要求の生じた複合機のみならずネットワーク１３４０上の複合機を利用して多種多様な機能を実現することができる。
【０２７２】
例えば、複合機１３００ａでファクシミリ送信要求が生じたときに、複合機１３００ａのファクシミリエンジンがファクシミリ受信ジョブに占有されている場合には、ＦＣＳプロセス１３２７でこれを判断してＥＣＳプロセス１３２４に対する関数コールをネットワーク１３４０上の他の複合機１３００ｂのＥＣＳプロセス１３２４への関数コールへ切り替える等の処理を行えば、ファクシミリ送信を直ちに行うことができ、複合機のユーザビリティの向上を図ることができる。
【０２７３】
なお、実施の形態４では、ファクシミリ送信動作の例をあげてネットワーク１３４０に接続された２つの複合機１３００ａ，１３００ｂにおけるプロセス間通信について説明したが、スキャナ動作、コピー動作、プリント動作においても、複合機１３００ａ内のコントロールサービスと複合機１３００ｂ内のコントロールサービスのプロセス間通信も同様に行われる。
【０２７４】
また、実施の形態４の複合機では、ＦＣＳプロセス１３２７とＥＣＳプロセス１３２４とのネットワーク１３４０を介したプロセス間通信に説明したが、他のコントロールサービス間のネットワーク１３４０を介したプロセス間通信も、ＦＣＳプロセス１３２７とＥＣＳプロセス１３２４の通信と同様に行われる。
【０２７５】
さらに、実施の形態４の複合機では、ＦＣＳアプリプロセス１３２７とネットワーク１３４０上の別の複合機内のＥＣＳプロセス１３２４とが直接プロセス間通信を行っているが、この場合も、ＮＣＳプロセス１３２８を介して異なる複合機のコントロールサービス間の通信を行うように構成しても良い。
【０２７６】
以上、実施の形態１〜４の複合機において使用した関数、メッセージはすべて一例であり、とくにこれらに限定されるものではなく、任意の関数やメッセージを定義して使用することができる。
【０２７７】
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。
【図面の簡単な説明】
【０２７８】
【図１】この発明の実施の形態の画像形成装置（複合機）の構成を示すブロック図である。
【図２】実施の形態１の複合機におけるサーバプロセスとクライアントプロセスの関係を示すブロック図である。
【図３】実施の形態１の複合機で動作するクライアントプロセスの構成を示すブロック図である。
【図４】実施の形態１の複合機で動作するサーバプロセスの構成を示すブロック図である。
【図５】実施の形態１の複合機でプリンタ動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間のデータシーケンスを示す説明図である。
【図６】実施の形態１の複合機でプリンタ動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【図７】実施の形態１の複合機でスキャナ動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間のデータシーケンスを示す説明図である。
【図８】実施の形態１の複合機でスキャナ動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【図９】実施の形態１の複合機でコピー動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間のデータシーケンスを示す説明図である。
【図１０】実施の形態１の複合機でコピー動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【図１１】実施の形態１の複合機でファクシミリ送信動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間のデータシーケンスを示す説明図である。
【図１２】実施の形態１の複合機でファックス送信動作を行う場合のアプリケーション、コントロールサービスおよびシステムリソースサービスの各プロセス間の関数およびメッセージの送受信の関係を示す説明図である。
【図１３】実施の形態２の複合機１００上で動作するサーバプロセスとクライアントプロセスの関係を詳細に示すブロック図である。
【図１４】実施の形態２のクライアントプロセスとサーバプロセスとを生成する画像形成装置用通信プログラム生成装置（スタブジェネレータ）の機能的構成を示すブロック図である。
【図１５】メッセージファイルの記述例を示す説明図である。
【図１６】スタブジェネレータにより生成されるクライアントスタブの一例を示す説明図である。
【図１７】スタブジェネレータにより生成されるサーバスケルトンの一例を示す説明図である。
【図１８】スタブジェネレータにより生成されるヘッダの一例を示す説明図である。
【図１９】サーバスケルトン、クライアントスタブおよびヘッダの生成処理のフローチャートである。
【図２０】クライアントプログラムから関数コールを行った場合におけるサーバプログラムとの呼び出しおよび応答のシーケンスを示す説明図である。
【図２１】実施の形態２にかかる複合機の構成を示すブロック図である。
【図２２】実施の形態２のネットワークに接続された２つの複合機を利用してプリンタ動作を行う場合のプリンタアプリとＥＣＳプロセス間のデータシーケンスを示す説明図である。
【図２３】実施の形態３のネットワークに接続された２つの複合機を利用してファクシミリ送信動作を行う場合のＦＣＳとＥＣＳとＭＣＳのプロセス間のデータシーケンスを示す説明図である。
【符号の説明】
【０２７９】
１００，１３００ａ，１３００ｂ    複合機
１０１，１３０１    白黒ラインプリンタ
１０２，１３０２    カラーラインプリンタ
１０３，１３０３    スキャナ
１０４，１３０４    ファクシミリ
１１０，１３１０    ソフトウェア群
１１１，１３１１    プリンタアプリ
１１２，１３１２    コピーアプリ
１１３，１３１３    ファックスアプリ
１１４，１３１４    スキャナアプリ
１１５，１３１５    ネットファイルアプリ
１１６，１３１６    工程検査アプリ
１２０，１３２０    プラットホーム
１２１，１３２１    汎用ＯＳ
１２２，１３２２    ＳＣＳ
１２３，１３２３    ＳＲＭ
１２４，１３２４    ＥＣＳ
１２５，１３２５    ＭＣＳ
１２６，１３２６    ＯＣＳ
１２７，１３２７    ＦＣＳ
１２８，１３２８    ＮＣＳ
１２９，１３２９    ＦＣＵＨ
１３０，１３３０    アプリケーション
２０１，１６００    クライアントプロセス
２０２，１６１０，１６２０    サーバプロセス
２０３，１６０３    クライアントディスパッチャ
２０４，１６１１    サーバディスパッチャ
１６０１，１６１３，１６２３    スレッド
１６０２    クライアントスタブ
１６１２，１６２２    サーバスケルトン
【図１】
2006139776.tif 000003
【図２】
2006139776.tif 000004
【図３】
2006139776.tif 000005
【図４】
2006139776.tif 000006
【図５】
2006139776.tif 000007
【図６】
2006139776.tif 000008
【図７】
2006139776.tif 000009
【図８】
2006139776.tif 000010
【図９】
2006139776.tif 000011
【図１０】
2006139776.tif 000012
【図１１】
2006139776.tif 000013
【図１２】
2006139776.tif 000014
【図１３】
2006139776.tif 000015
【図１４】
2006139776.tif 000016
【図１５】
2006139776.tif 000017
【図１６】
2006139776.tif 000018
【図１７】
2006139776.tif 000019
【図１８】
2006139776.tif 000020
【図１９】
2006139776.tif 000021
【図２０】
2006139776.tif 000022
【図２１】
2006139776.tif 000023
【図２２】
2006139776.tif 000024
【図２３】
2006139776.tif 000025