JP4052901B2 - プロセス間通信機能を有する装置 - Google Patents

Description

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

Claims (18)

1. 実行する処理で使用されるハードウェア資源と、前記実行する処理に係るユーザサービスおよびコントロールサービスの処理を行う一または複数のプログラムとを有するプロセス間通信機能を有する装置であって、
   前記ユーザサービスおよびコントロールサービスのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、
   前記サーバプロセスのスレッドは、前記クライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数に対応する処理を実行するものであり、
   前記クライアントプロセスのスレッドは通信の動作主体であり、前記サーバプロセスのスレッドに対して個別にクライアントとしてサービスの提供を要求する際に関数呼び出しを行い、
   前記ユーザサービスおよび前記コントロールサービスは、前記クライアントプロセスとして動作するときに、前記サーバプロセスへの関数呼び出しに対する関数戻り値の受信を監視し、受信した関数戻り値を前記関数呼び出しを行ったスレッドに受け渡す、スレッドで実現されたクライアント監視手段と、
   前記サーバプロセスとして動作するときに、前記一又は複数のクライアントプロセスからの関数呼び出しを監視し、前記クライアントプロセスから関数呼び出しを受信したときに、呼び出された関数に対応した処理を関数ハンドラで実行するサーバ監視手段と
   を備えており、一のプロセスに一のサーバ監視手段と一又は複数のクライアント監視手段とを同時に起動可能であることを特徴とする装置。
2. 前記コントロールサービスは、前記ユーザサービスをクライアントプロセスとしたサーバプロセスとして動作して、前記ユーザサービスの少なくとも２つが共通的に必要とするサービスを定義した関数に対応する処理を実行するスレッドを有し、
   前記ユーザサービスのスレッドは、前記コントロールサービスにサービスの提供を要求する際に関数呼び出しを行うことを特徴とする請求項１記載の装置。
3. 前記コントロールサービスは、他のコントロールサービスをクライアントプロセスとしたサーバプロセスとして動作して、前記他のコントロールサービスの少なくとも２つが共通的に必要とするサービスを定義した関数に対応する処理を実行するスレッドを有しており、
   前記他のコントロールサービスのスレッドは、前記コントロールサービスにサービスの提供を要求する際に関数呼び出しを行うことを特徴とする請求項１又は２記載の装置。
4. 前記コントロールサービスは、前記サーバプロセスとして動作するとともに前記クライアントプロセスとして動作することを特徴とする請求項１乃至３いずれか一項記載の装置。
5. 前記クライアント監視手段は、関数の呼び出し後に関数戻り値待ち状態のスレッドの識別子を一時的に格納する関数戻り待ちキューをさらに備え、前記サーバプロセスから前記関数戻り値を受信したときに、受信した関数戻り値を、前記関数戻り待ちキューに格納された識別子の前記スレッドに送信することを特徴とする請求項１乃至４いずれか一項記載の装置。
6. 前記サーバプロセスおよび前記クライアントプロセスは、さらにイベントまたは通知に関するメッセージの送信，受信または送受信の何れかを行うことを特徴とする請求項１乃至５いずれか一項記載の装置。
7. 前記クライアント監視手段は、さらにサーバプロセスからのメッセージの受信を監視することを特徴とする請求項６記載の装置。
8. 前記クライアント監視手段は、受信したメッセージに基づいた処理を実行するメッセージハンドラをさらに備えたことを特徴とする請求項７記載の装置。
9. 前記サーバ監視手段は、さらにクライアントプロセスからのメッセージの受信を監視することを特徴とする請求項１記載の装置。
10. 前記サーバ監視手段は、受信したメッセージに基づいた処理を実行するメッセージハンドラをさらに備えたことを特徴とする請求項９記載の装置。
11. 実行する処理で使用されるハードウェア資源と、前記実行する処理に係るユーザサービスおよびコントロールサービスの処理を行う一または複数のプログラムとを有するプロセス間通信機能を有する装置であって、
    前記ユーザサービスおよびコントロールサービスのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一又は複数のスレッドを含むプロセスであり、
    前記コントロールサービスは、ネットワークに接続された他の装置で動作するクライアントプロセスに対するサーバプロセスとして動作し、サーバプロセスのスレッドとして前記他の装置のクライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数に対応する処理を実行するスレッドを有し、
    前記クライアントプロセスのスレッドは通信の動作主体であり、前記サーバプロセスのスレッドに対して個別にクライアントとしてサービスの提供を要求する際に関数呼び出しを行い、
    前記コントロールサービスは、前記クライアントプロセスとして動作するときに、前記サーバプロセスへの関数呼び出しに対する関数戻り値の受信を監視し、受信した関数戻り値を前記関数呼び出しを行ったスレッドに受け渡す、スレッドで実現されたクライアント監視手段と、
    前記サーバプロセスとして動作するときに、前記他の装置又は自装置の前記一又は複数のクライアントプロセスからの関数呼び出しを監視し、前記クライアントプロセスから関数呼び出しを受信したときに、呼び出された関数に対応した処理を関数ハンドラで実行するサーバ監視手段と
    を備えており、一のプロセスに一のサーバ監視手段と一又は複数のクライアント監視手段とを同時に起動可能であることを特徴とする装置。
12. 前記コントロールサービスの各プロセスが備える一または複数のスレッドは、前記他の装置のクライアントプロセスのスレッドに提供するサービスを実行することを特徴とする請求項１１記載の装置。
13. 前記サーバ監視手段は、さらに前記他の装置のクライアントプロセスからのメッセージの受信を監視することを特徴とする請求項１２記載の装置。
14. 前記コントロールサービスは、さらに前記他の装置のクライアントプロセスに対しメッセージを送信することを特徴とする請求項１１乃至１３いずれか一項記載の装置。
15. 前記コントロールサービスは、前記他の装置で動作するユーザサービスをクライアントプロセスとしたサーバプロセスとして動作することを特徴とする請求項１１乃至１４いずれか一項記載の装置。
16. 前記コントロールサービスは、前記他の装置で動作するコントロールサービスをクライアントプロセスとしたサーバプロセスとして動作することを特徴とする請求項１１乃至１５いずれか一項記載の装置。
17. 前記ユーザサービスは、前記他の装置で動作するコントロールサービスをサーバプロセスとしたクライアントプロセスとして動作することを特徴とする請求項１１乃至１６いずれか一項記載の装置。
18. 前記コントロールサービスは、前記他の装置で動作するコントロールサービスをサーバプロセスとしたクライアントプロセスとして動作することを特徴とする請求項１１乃至１７いずれか一項記載の装置。

Images