JP4334214B2 - 画像形成装置、アプリケーションプログラム及び記録媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
【０００２】
この発明は、コピー、プリンタ、スキャナおよびファクシミリなどの画像形成処理にかかるユーザサービスを提供する画像形成装置に搭載されるアプリケーションにおいて、コントロールサービスに対する処理を隠蔽してアプリケーションを効率良く開発することを可能とする技術に関する。
【従来の技術】
【０００３】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置（以下、「複合機」という。）が一般的に知られている。この複合機は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応する３種類のソフトウェアを設け、ソフトウェアの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００４】
このような従来の複合機では、プリンタ、コピー、スキャナおよびファクシミリ装置に対応するソフトウェアをそれぞれ別個に設けているため、各ソフトウェアの開発に多大の時間を要する。このため、出願人は、表示部、印刷部および撮像部などの画像形成処理で使用されるハードウェア資源を有し、プリンタ、コピーまたはファクシミリなどの各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、これらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットホームを備えた画像形成装置（複合機）を発明した。
【０００５】
この複合機によれば、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行うプラットホームを備えた構成とすることによって、ソフトウェア開発の効率化を図るとともに、装置全体としての生産性を向上させることが可能となる。
【特許文献１】
特開２００２−３４２１１９号公報
【発明が解決しようとする課題】
【０００６】
このような新規な複合機では、アプリケーションとコントロールサービスとを別個に設けているため、複合機の出荷後にユーザもしくは第三者であるサードベンダーが新規なアプリケーションを開発して複合機に搭載することが可能となっており、これにより多種多様な機能を提供することが可能となる。
【０００７】
このような新規な複合機は、アプリケーションと、アプリケーションの少なくとも２つが共通的に必要とするサービスを提供するコントロールサービスとを備えた特徴的な構成となっているため、新規アプリケーションを開発する場合には、各種コントロールサービスとのプロセス間通信を実現する処理をソースコードで記述する必要がある。しかしながら、このような処理は各コントロールサービスが提供する関数やメッセージなどを正確に把握した上で、あらかじめ規定された手順で記述しなければならないため、各コントロールサービスに対する処理の記述が困難であるという問題がある。このような新規アプリケーションの開発における課題は従来の構成の複合機には問題にならなかった新規な課題である。
【０００８】
また、各コントロールサービスとアプリケーションのインタフェースの全てを、新規アプリケーションを開発するサードベンダーなどの第三者に開示することは、プログラムの秘匿性の面から好ましくない。特に、複合機のシステムに大きく影響を与えるような箇所は第三者に対し隠蔽しておき、直接コントロールサービスに対してアクセスすることを回避することが、複合機のセキュリティ面および障害発生の未然防止の面から好ましい。
【０００９】
この発明は上記に鑑みてなされたもので、多数のプロセスが実行される画像形成装置で動作するアプリケーションとコントロールサービス間の複雑な処理を隠蔽することにより、新規アプリケーションの開発効率を向上させ、かつ、重要なインタフェースの秘匿性を確保することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムを複数搭載可能に構成された画像形成装置であって、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置、において実行される新規アプリケーションプログラムの実行形式プログラムをコンピュータが生成するための画像形成装置用アプリケーション生成方法であって、前記コンピュータが、ラッピング関数が記述された前記新規アプリケーションプログラムのソースファイルを記憶手段から読み出してコンパイルし、オブジェクトファイルを生成するコンパイルステップと、前記コンピュータが、前記ラッピング関数の処理内容が登録されたラッピング関数ライブラリを記憶手段から読み出し、当該ラッピング関数ライブラリと、前記オブジェクトファイルとをリンクして、前記新規アプリケーションプログラムの実行形式プログラムを生成するリンクステップとを含み、前記ラッピング関数は、前記画像形成装置で実行されることにより、前記画像形成装置を、前記複数のコントロールサービスプロセスのうちの予め定めたコントロールサービスプロセスの機能を利用するための処理を実行するラッピング手段として機能させることを特徴とする。
【００１１】
この発明によれば、コントロールサービスとの複雑な手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションを効率的に開発することができる。
【００１２】
また、この発明によれば、ラッピング関数が新規アプリケーションに代わってコントロールサービスとの処理を行うので、コントロールサービスとのインタフェースを隠蔽して、重要なインタフェースの秘匿性を確保することができる。
【００１３】
また、上記画像形成装置用アプリケーション生成方法において、前記ラッピング手段は、前記予め定めたコントロールサービスプロセスの機能を利用するためのプロセス間通信処理を実行することとすることができる。
【００１４】
この発明においては、コントロールサービスとのインタフェースで重要な部分を隠蔽することができ、他の部分を第三者に開示することができる。従って、インタフェースの重要度に応じた秘匿性を確保することができる。
【００１５】
また、前記ラッピング手段は、前記画像形成装置において、前記新規アプリケーションプログラムのプロセス内部で生成されたラッピングスレッドとして機能することとしてもよい。
【００１６】
この発明によれば、ラッピング関数が新規アプリケーションのプロセス内部で生成されたラッピングスレッドとして実行されるので、生成された新規アプリケーションのプロセス内部で、コントロールサービスとのプロセス間通信等の代行処理と他の処理とを並列実行した場合に、両処理の切り替え時間を短縮化することができる。
【００１７】
また、前記ラッピング手段は、前記予め定めたコントロールサービスプロセスから受信したイベントに対する応答処理を実行することとすることができる。
【００１８】
この発明によれば、イベントに対して応答が必要な特に複雑なコントロールサービスとのプロセス間通信の手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションをより効率的に開発することができる。
【００１９】
また、前記ラッピング手段は、前記画像形成装置のエンジン制御を行うエンジンコントロールサービスプロセスが提供するいずれの機能においても、当該機能を利用するためのプロセス間通信処理を実行することとしてもよい。
【００２０】
この発明によれば、エンジンコントロールサービスとのプロセス間通信の複雑な手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションをより効率的に開発することができる。
【００２１】
また、この発明によれば、画像形成装置の重要なエンジン部分を制御するエンジンコントロールサービスとのインタフェースを隠蔽することができ、特に重要なインタフェースの秘匿性を確保できるとともに、新規アプリケーションのプログラムミスによるエンジン障害を未然に防止することができる。
【００２２】
また、前記ラッピング手段は、前記画像形成装置のメモリ制御を行うメモリコントロールサービスプロセスが提供するいずれの機能においても、当該機能を利用するためのプロセス間通信処理を実行することとしてもよい。
【００２３】
この発明によれば、メモリコントロールサービスとのプロセス間通信の複雑な手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションをより効率的に開発することができる。
【００２４】
また、この発明によれば、画像形成装置の重要なメモリを制御するメモリコントロールサービスとのインタフェースを隠蔽することができ、特に重要なインタフェースの秘匿性を確保できるとともに、新規アプリケーションのプログラムミスによるメモリ障害を未然に防止することができる。
【００２５】
また、前記ラッピング手段は、前記画像形成装置のシステム制御を行うシステムコントロールサービスプロセスが提供する機能の中で、システム状態通知および電源状態に関する機能を利用するためのプロセス間通信処理を実行するようにしてもよい。
【００２６】
この発明によれば、複雑なシステム状態通知および電源状態に対するプロセス間通信の手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションをより効率的に開発することができる。
【００２７】
また、この発明によれば、画像形成装置の動作に大きく影響を及ぼすシステム状態通知および電源状態に関するシステムコントロールサービスとのインタフェースを隠蔽することができ、特に重要なインタフェースの秘匿性を確保できるとともに、新規アプリケーションのプログラムミスによる障害を未然に防止することができる。
【００２８】
また、前記ラッピング手段は、前記画像形成装置のネットワーク制御を行うネットワークコントロールサービスプロセスが提供する機能の中で、データ送信プロトコルを使用する機能を利用するためのプロセス間通信処理を実行するようにしてもよい。
【００２９】
この発明によれば、データ通信プロトコルを使用するプロセス間通信の複雑な手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションをより効率的に開発することができる。
【００３０】
また、前記ラッピング手段は、前記複数のコントロールサービスプロセスのうち、前記画像形成装置のオペレーションパネルを制御するオペパネコントロールサービスプロセス以外のコントロールサービスプロセスが提供する機能を利用するためのプロセス間通信処理を実行することとしてもよい。
【００３１】
この発明によれば、新規アプリケーションが頻繁に利用するオペレーションパネルとのインタフェースを第三者に開示しながら、他の複雑なインタフェースを隠蔽することができる。
【００３２】
また、前記ラッピング手段は、前記新規アプリケーションプログラムのプロセスと前記コントロールサービスプロセスとの間に介在して実行される仮想アプリケーションサービスプロセスに対するプロセス間通信処理を実行することとしてもよい。
【００３３】
本発明によれば、仮想アプリケーションサービスとのプロセス間通信の手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションをより効率的に開発することができる。
【００３４】
また、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムを複数搭載可能に構成された画像形成装置であって、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置、において実行される新規アプリケーションプログラムの実行形式プログラムをコンピュータに生成させるためのプログラムであって、
ラッピング関数が記述された前記新規アプリケーションプログラムのソースファイルを前記コンピュータの記憶手段から読み出してコンパイルし、オブジェクトファイルを生成するコンパイルステップと、前記ラッピング関数の処理内容が登録されたラッピング関数ライブラリを前記記憶手段から読み出し、当該ラッピング関数ライブラリと、前記オブジェクトファイルとをリンクして、前記新規アプリケーションプログラムの実行形式プログラムを生成するリンクステップとを前記コンピュータに実行させるプログラムであり、
前記ラッピング関数は、前記画像形成装置で実行されることにより、前記画像形成装置を、前記複数のコントロールサービスプロセスのうちの予め定めたコントロールサービスプロセスの機能を利用するための処理を実行するラッピング手段として機能させることを特徴とするプログラムとして構成することもできる。
【００３５】
また、本発明は、上記プログラムを記録したコンピュータ読み取り可能な記録媒体としてもよく、この記録媒体に更にラッピング関数ライブラリを記録してもよい。
【００３６】
また、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムを複数搭載可能に構成された画像形成装置であって、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置を、前記複数のコントロールサービスプロセスとのプロセス間通信を行うプロセス間通信手段、前記複数のコントロールサービスプロセスのうちの予め定めたコントロールサービスプロセスの機能を利用するためのプロセス間通信処理を前記プロセス間通信手段を用いて実行するラッピング手段、として機能させるプログラムとして構成することもできる。
【００３７】
また、本発明は、上記プログラムを記録したコンピュータ読み取り可能な記録媒体としてもよい。
【００３８】
また、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムを複数搭載可能に構成された画像形成装置であり、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置であって、前記複数のコントロールサービスプロセスとのプロセス間通信を行うプロセス間通信機能と、前記複数のコントロールサービスプロセスのうちの予め定めたコントロールサービスプロセスの機能を利用するためのプロセス間通信処理を前記プロセス間通信機能を用いて実行するラッピング機能を前記画像形成装置に実現させるための新規アプリケーションプログラムを備えたことを特徴とする画像形成装置として構成することもできる。
【００３９】
これにより、効率的に作成された高品質なアプリケーションを有する画像形成装置を提供することができる。
【００４０】
また、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムが複数搭載された画像形成装置であって、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置、において実行される新規アプリケーションプログラムの実行形式プログラムをコンピュータが生成するための画像形成装置用アプリケーション生成方法であって、前記コンピュータが、前記新規アプリケーションプログラムとは別の、前記複数のアプリケーションプログラムのうちのあるアプリケーションプログラムを呼び出すためのアプリ関数が記述された前記新規アプリケーションプログラムのソースファイルを記憶手段から読み出してコンパイルし、オブジェクトファイルを生成するコンパイルステップと、前記コンピュータが、前記アプリ関数の処理内容が登録されたアプリ関数ライブラリを前記記憶手段から読み出し、当該アプリ関数ライブラリと、前記オブジェクトファイルとをリンクして、前記新規アプリケーションプログラムの実行形式プログラムを生成するリンクステップを含み、前記アプリ関数は、前記画像形成装置で実行されることにより、前記画像形成装置を、前記あるアプリケーションプログラムを呼び出すアプリ呼び出し手段として機能させることを特徴とする画像形成装置用アプリケーション生成方法として構成することができる。
【００４１】
この発明によれば、コントロールサービスとのプロセス間通信は既存のアプリケーションを利用して実現され、プロセス間通信の複雑な手順を新規アプリケーションのソースコードに記述する必要がなく、新規アプリケーションを効率的に開発することができる。
【００４２】
また、前記アプリ呼び出し手段は、コピーアプリ、プリンタアプリ、ファックスアプリまたはスキャナアプリの中の一または二以上のアプリケーションプログラムを呼び出す処理を行うこととすることができる。
【００４３】
この発明によれば、新規アプリケーションにコピー機能、プリンタ機能、ファックス機能またはスキャナ機能を持たせる場合でも、各機能に対応したアプリケーションを介してコントロールサービスとプロセス間通信を行えるので、新規アプリケーション独自にコントロールサービスとのプロセス間通信の手順をソースコードに記述する必要がなく、新規アプリケーションを効率的に開発することができる。
【００４４】
また、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムが複数搭載された画像形成装置であって、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置、において実行される新規アプリケーションプログラムの実行形式プログラムをコンピュータに生成させるためのプログラムであって、前記新規アプリケーションプログラムとは別の、前記複数のアプリケーションプログラムのうちのあるアプリケーションプログラムを呼び出すためのアプリ関数が記述された前記新規アプリケーションプログラムのソースファイルを前記コンピュータの記憶手段から読み出してコンパイルし、オブジェクトファイルを生成するコンパイルステップと、前記アプリ関数の処理内容が登録されたアプリ関数ライブラリを前記記憶手段から読み出し、当該アプリ関数ライブラリと、前記オブジェクトファイルとをリンクして、前記新規アプリケーションプログラムの実行形式プログラムを生成するリンクステップとを前記コンピュータに実行させるプログラムであり、前記アプリ関数は、前記画像形成装置で実行されることにより、前記画像形成装置を、前記あるアプリケーションプログラムを呼び出すアプリ呼び出し手段として機能させることを特徴とするプログラムとして構成することもできる。また、このプログラムを記録した記録媒体を構成することもでき、この記録媒体にアプリ関数の処理内容が登録されたアプリ関数ライブラリを更に記録してもよい。
【００４５】
また、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムが複数搭載された画像形成装置であって、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置を、前記複数のアプリケーションプログラムのうちのあるアプリケーションプログラムを呼び出すアプリ呼び出し手段として機能させるプログラムとして構成することもできる。
【００４６】
また、本発明は、画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムが複数搭載された画像形成装置であり、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置であって、前記複数のアプリケーションプログラムのうちのあるアプリケーションプログラムを呼び出すアプリ呼び出し機能を前記画像形成装置に実現させる新規アプリケーションプログラムを備えたことを特徴とする画像形成装置として構成することもできる。
【発明の実施の形態】
【００４７】
以下に添付図面を参照して、本発明の好適な実施の形態を詳細に説明する。
【００４８】
（実施の形態１）
この発明の実施の形態１では、画像形成装置（以下、「複合機」という。）で動作させる新規アプリケーションを開発する場合、開発用ＰＣ（Personal Computer）によってアプリソースファイルを作成する。そして、アプリケーション開発のためにＣＤ−ＲＯＭなどの記録媒体で提供されるアプリ開発キットを開発用サーバにインストールして、作成したアプリソースファイルを、開発用サーバでコンパイル、リンクして複合機で実行可能なアプリケーションの実行形式ファイルを生成している。
【００４９】
図１は、実施の形態１である開発用サーバ１００のソフトウェア構成を示すブロック図である。この図１では、アプリ開発キットを開発用サーバ１００のハードディスク（ＨＤ）１３０にインストール済みの状態を示している。実施の形態１にかかる開発用サーバ１００は、複合機で動作させるための新規アプリケーションの新規アプリソースファイル１３２をコンパイルおよびリンクして、新規アプリケーションのプログラムであるアプリ実行形式ファイル１３４を生成するものである。実施の形態１にかかる開発用サーバ１００は、図１に示すように、デバッグ機能付きコンパイラ１１０と、リンカ１２０とから構成される。
【００５０】
デバッグ機能付きコンパイラ１１０は、ハードディスク（ＨＤ）１３０に格納されたアプリケーションのソースコードが記述された新規アプリソースファイル１３２を、コマンドの指定に従って、オブジェクトコードからなるオブジェクトファイルを生成するものである。デバッグ機能付きコンパイラ１１０は、図１に示すように、さらにコマンド解析部１１１と、構文解析部１１２と、タグ付加部１１３と、コード生成部１１４とから構成される。
【００５１】
ＨＤ（ハードディスク）１３０には、アプリケーション開発用のアプリ開発キット１３１がインストールされている。また、ＨＤ１３０にアプリケーションのＣ言語ソースコードが記述された新規アプリソースファイル１３２が格納される。この新規アプリソースファイル１３２は、開発用ＰＣでエディタによって作成され、開発用サーバ１００にコピーされる。
【００５２】
また、ＨＤ１３０には、デバッグ機能付きコンパイラ１１０によって、オブジェクトファイル１３３が生成され、さらにリンカ１２０によってアプリ実行形式ファイル１３４が生成される。
【００５３】
デバッグ機能付きコンパイラ１１０のコマンド解析部１１１は、ユーザからキーボードなどの入力装置によって入力されたコマンドのパラメータや構文の解析を行って、入力されたコマンドが文法的に正確か否かを判断するものである。
【００５４】
構文解析部１１２は、ＨＤ１３０に格納された新規アプリソースファイル１３２を入力して、新規アプリソースファイル１３２に記述されたＣ言語ソースコードを、Ｃ言語文法に従って解析し、導出木や構文木などを生成するものであり、通常のコンパイラにおける構文解析と同様の処理を行う。
【００５５】
タグ付加部１１３は、コマンドの指定によって、新規アプリソースファイル１３２に記述された関数の入口と出口にデバッグ用の検証コードであるタグを付加するものである。
【００５６】
コード生成部１１４は、構文解析され、必要に応じて検証コード（タグ）が付加された新規アプリソースファイル１３２から、オブジェクトコードからなるオブジェクトファイル１３３を生成するものである。
【００５７】
リンカ１２０は、コード生成部１１４によって生成されたオブジェクトファイル１３３と、アプリ開発キット１３１の中のコントロールサービス関数ライブラリ、標準関数ライブラリおよびコントロールサービスラッピング関数ライブラリとをリンク（結合）して、複合機およびコンピュータのＯＳ上で実行可能なアプリ実行形式ファイル１３４を生成するものである。
【００５８】
アプリ開発キット１３１は、ＣＤ−ＲＯＭまたはフレキシブルディスク（ＦＤ）などの記録媒体にインストール可能な形式で提供され、開発用サーバ１００のＨＤ１３０にインストールされる。この記録媒体のアプリ開発キット１３１の中には、図１に示すように、各コントロールサービスごとに提供するサービス関数を登録したコントロールサービス関数ライブラリ（たとえば、ＥＣＳ関数ライブラリ、ＭＣＳ関数ライブラリなど）と、ｓｔｒｃｐｙ，ｍｅｍｃｐｙなどのＣ言語標準関数を登録した標準関数ライブラリと、コントロールサービスラッピング関数ｗｒａｐｐｉｎｇ＿ｔｈｒｄを登録したコントロールサービスラッピング関数ライブラリと、アプリ登録のためのＡｐｌＲｅｇ関数、スレッド間通信で使用されるｓｅｎｄｍａｉｌ関数およびｒｃｖｍａｉｌ関数などを登録したユーティリティライブラリと、アプリケーションとコントロールサービスに共通で使用される関数宣言やメッセージ宣言が記述されているヘッダファイルと、デバッグ機能付きコンパイラと、リンカと、汎用ＯＳプログラムと、デバッガなどのデバッグ用ユーティリティとが含まれている。
【００５９】
コントロールサービスラッピング関数ライブラリは、コントロールサービスラッピング関数ｗｒａｐｐｉｎｇ＿ｔｈｒｄを登録したものである。コントロールサービスラッピング関数ｗｒａｐｐｉｎｇ＿ｔｈｒｄは、アプリケーション３３０がコントロールサービスと、ＡＰＩを利用した関数呼び出しまたはメッセージ送受信によるプロセス間通信を行う場合に、複雑な関数呼び出しやメッセージ送受信の手順を、アプリケーション３３０に代わって行うものである。コントロールサービスラッピング関数ｗｒａｐｐｉｎｇ＿ｔｈｒｄの詳細な処理については後述する。
【００６０】
上記デバッグ機能付きコンパイラ１１０の各部およびリンカ１２０は、このアプリ開発キットをインストールして実行したときに、ＲＡＭ２０３上に生成されて実行される。
【００６１】
なお、実施の形態１では、アプリ開発キットを記録媒体で提供することとしているが、また、このような実行可能な形式またはインストール可能な形式のファイルを、ネットワーク経由でダウンロードすることにより提供するように構成しても良い。
【００６２】
図２は、実施の形態１にかかる開発用サーバ、開発用ＰＣのハードウェア構成および開発環境を示すブロック図である。図２に示すように、この開発用サーバ１００は、ＣＰＵなどの制御装置２０４と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、ＨＤ１３０と、ディスプレイ装置などの表示装置２０２と、キーボードやマウスなどの入力装置２０１と、ＬＡＮボードやモデムなどの通信装置２０６と、フラッシュカードのリード／ライトを制御するフラッシュカードインタフェースやＣＤ−ＲＯＭのリード制御を行うＣＤドライブ装置などの外部記憶装置２０５とを備えており、ＰＣ（Personal Computer）、ワークステーションなどのコンピュータを利用した通常の構成である。
【００６３】
この開発用サーバ１００は、イーサネット（登録商標）２２０などのネットワークによって開発用ＰＣ２００と複合機３００に接続されており、ＬＡＮ環境が構築されている。開発用ＰＣ２００のハードウェア構成は、図２に示す通り、開発用サーバ１００と同様の構成となっている。複合機３００には、複合機の起動を制御したり、エラー表示のためのコンソールＰＣ２３０がケーブルによって接続されている。
【００６４】
次に、デバッグ対象である複合機３００について説明する。図３は、複合機３００の機能的構成を示すブロック図である。図３に示すように、複合機３００は、白黒ラインプリンタ（B&W LP）３０１と、カラーラインプリンタ（Color LP）３０２と、スキャナ、ファクシミリ、ハードディスク（ＨＤ）、メモリ、ネットワークインタフェースなどのハードウェアリソース３０３を有するとともに、プラットホーム３２０とアプリケーション３３０とから構成されるソフトウェア群３１０とを備えている。
【００６５】
プラットホーム３２０は、アプリケーション３３０からの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一または複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ（ＳＲＭ）３２３と、汎用ＯＳ３２１とを備えている。
【００６６】
コントロールサービスは、複数のサービスモジュールから形成され、ＳＣＳ（システムコントロールサービス）３２２と、ＥＣＳ（エンジンコントロールサービス）３２４と、ＭＣＳ（メモリコントロールサービス）３２５と、ＯＣＳ（オペレーションパネルコントロールサービス）３２６と、ＦＣＳ（ファックスコントロールサービス）３２７と、ＮＣＳ（ネットワークコントロールサービス）３２８とから構成される。なお、このプラットホーム３２０は、あらかじめ定義された関数により前記アプリケーション３３０から処理要求を受信可能とするアプリケーションプログラムインタフェース（ＡＰＩ）を有する。
【００６７】
汎用ＯＳ３２１は、ＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、プラットホーム３２０並びにアプリケーション３３０の各ソフトウェアをそれぞれプロセスとして並列実行する。
【００６８】
ＳＲＭ３２３のプロセスは、ＳＣＳ３２２とともにシステムの制御およびリソースの管理を行うものである。ＳＲＭ３２３のプロセスは、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４ Ｉ／Ｆ、ＲＳ２３２Ｃ Ｉ／Ｆなど）のハードウェア資源を利用する上位層からの要求に従って調停を行い、実行制御する。
【００６９】
具体的には、このＳＲＭ３２３は、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、ＳＲＭ３２３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容（例えば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。
【００７０】
ＳＣＳ３２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御などを行う。
【００７１】
ＥＣＳ３２４のプロセスは、白黒ラインプリンタ３０１、カラーラインプリンタ３０２、スキャナ、ファクシミリなどからなるハードウェアリソース３０３のエンジンの制御を行う。
【００７２】
ＭＣＳ３２５のプロセスは、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などを行う。
【００７３】
ＦＣＳ３２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供する。
【００７４】
ＮＣＳ３２８のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行う。具体的には、ftpd、httpd、lpd、snmpd、telnetd、smtpdなどのサーバデーモンや、同プロトコルのクライアント機能などを有している。
【００７５】
ＯＣＳ３２６は、オペレータ（ユーザ）と本体制御間の情報伝達手段となるオペレーションパネル（操作パネル）の制御を行う。ＯＣＳ３２６は、オペレーションパネルからキー押下をキーイベントとして取得し、取得したキーに対応したキーイベント関数をＳＣＳ３２２に送信するＯＣＳプロセスの部分と、アプリケーション３３０またはコントロールサービスからの要求によりオペレーションパネルに各種画面を描画出力する描画関数やその他オペレーションパネルに対する制御を行う関数などがあらかじめ登録されたＯＣＳライブラリの部分とから構成される。このＯＣＳライブラリは、アプリケーション３３０およびコントロールサービスの各モジュールにリンクされて実装されている。なお、ＯＣＳ３２６の全てをプロセスとして動作させるように構成しても良く、あるいはＯＣＳ３２６の全てをＯＣＳライブラリとして構成しても良い。
【００７６】
アプリケーション３３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ３１１と、コピー用アプリケーションであるコピーアプリ３１２と、ファクシミリ用アプリケーションであるファックスアプリ３１３と、スキャナ用アプリケーションであるスキャナアプリ３１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ３１５と、工程検査用アプリケーションである工程検査アプリ３１６とを有している。これらのアプリケーション３３０はいずれも複合機３００の起動時に初期化部（図示せず）によりプロセスとして生成され、動作する。
【００７７】
アプリケーション３３０の各プロセス、コントロールサービスの各プロセスは、関数呼び出しとその戻り値送信およびメッセージの送受信によってプロセス間通信を行いながら、コピー、プリンタ、スキャナ、ファクシミリなどの画像形成処理にかかるユーザサービスを実現している。
【００７８】
このように、実施の形態１にかかる複合機３００には、複数のアプリケーション３３０および複数のコントロールサービスが存在し、いずれもプロセスとして動作している。そして、これらの各プロセス内部には、一または複数のスレッドが生成されて、スレッド単位の並列実行が行われる。そして、コントロールサービスがアプリケーション３３０に対し共通サービスを提供しており、このため、これらの多数のプロセスが並列動作、およびスレッドの並列動作を行って互いにプロセス間通信を行って協調動作をしながら、コピー、プリンタ、スキャナ、ファクシミリなどの画像形成処理にかかるユーザサービスを提供するようになっている。そして、複合機３００には、サードベンダーなどの第三者がコントロールサービス層の上のアプリケーション層に新規なアプリケーション（新規アプリ３１７）を開発して搭載することが可能となっている。
【００７９】
図４は、図３に示した実施の形態１の複合機３００のハードウェア構成図である。図４に示すように、この複合機３００は、ＣＰＵ４０２、ＳＤＲＡＭ４０３、ＳＲＡＭ４０８、フラッシュメモリ４０４、フラッシュカードインタフェース部４０６およびＨＤ４０５などをＡＳＩＣ４０１に接続したコントローラボード４００と、オペレーションパネル４１０と、ファックスコントロールユニット（ＦＣＵ）４２０と、ＵＳＢ４３０と、ＩＥＥＥ1394 ４４０と、プリンタ４５０とから構成されている。オペレーションパネル４１０はＡＳＩＣ４０１に直接接続され、ＦＣＵ４２０、ＵＳＢ４３０、ＩＥＥＥ1394 ４４０およびプリンタ４５０はＰＣＩバスを介してＡＳＩＣ４０１に接続されている。
【００８０】
フラッシュカードインタフェース部４０６は、フラッシュカード４０７を挿入して、フラッシュカード４０７とデータのやりとりを行うインタフェースである。このフラッシュカードインタフェース部４０６によって、開発用サーバ１００で生成された新規アプリが記録されたフラッシュカード４０７を読み込むことができるようになっている。
【００８１】
フラッシュメモリ（以下、「フラッシュＲＯＭ」という。）４０４には、上述の各アプリ、プラットホーム３２０を構成する各コントロールサービスやＳＲＭ３２３の各プログラムが格納されている。
【００８２】
オペレーションパネル４１０は、利用者のキー入力、ボタン押下などのキー操作を入力する操作部と、ボタン、ウィンドウ、各種画面などの描画データを表示する表示部とから構成されている。
【００８３】
図５は、実施の形態１のアプリ開発キット１３１を利用して生成した新規アプリ３１７の実行時におけるプロセス内部と、ＥＣＳ３２４、ＭＣＳ３２５などのコントロールサービスのプロセスとの呼び出し関係を示す説明図である。図５に示すように、新規アプリ３１７のプロセス内部には、メインスレッド５０１と、ラッピングスレッド５０２と、プロセス間通信スレッド５０３の少なくとも３つのスレッドが生成されて動作する。
【００８４】
メインスレッド５０１は、新規アプリ３１７の全体処理を担うスレッドであり、新規アプリ３１７の開発は、このメインスレッド５０１として実行されるメイン関数ｍａｉｎをユーザが作成することである。
【００８５】
ラッピングスレッド５０２は、メインスレッド５０１により、コントロールサービスラッピング関数ｗｒａｐｐｉｎｇ＿ｔｈｒｄを発行することによって生成されるスレッドであり、各コントロールサービスに対するアクセスを、メインスレッド５０１に代わってＡＰＩを利用して行い、その処理結果をメインスレッド５０１に送信するものである。具体的な処理としては、各コントロールサービスが提供するサービス関数をＡＰＩを利用して呼び出したり、メッセージ送信などのプロセス間通信を行う。
【００８６】
プロセス間通信スレッド５０３は、各コントロールサービスからのイベントを受信して、受信したイベントを、ラッピングスレッド５０２に送信するものである。すなわち、プロセス間通信スレッド５０３によって受信したイベントは、本来メインスレッド５０１に送信すべきところ、実施の形態１では、ラッピングスレッド５０２に一旦送信してから、ラッピングスレッド５０２によって受信したイベントをメインスレッド５０１に送信したり、あるいはメインスレッド５０１に送信せずに、受信したイベントに対する応答処理をラッピングスレッド５０２で代行することとしている。
【００８７】
ここで、各スレッド間の通信は、メールボックスを介して行われる。あるスレッドで、メールボックスを指定して、ｓｅｎｄｍａｉｌ関数を発行したとき、指定されたメールボックスにデータが格納される。このとき、別のスレッドでｓｅｎｄｍａｉｌ関数で指定されたメールボックスを指定してｒｃｖｍａｉｌ関数を発行することにより、指定メールボックスに格納されたデータを取得できるようになっている。
【００８８】
図６は、メインスレッド５０１で実行される処理のＣ言語ソースコードを示す説明図である。なお、図６は一例を示すものであり、これに限定されるものではなく、開発する新規アプリ３１７の機能によって任意に定めることができる。また、図６はＣ言語ソースコードで示されているが、他の言語で生成しても良い。
【００８９】
メインスレッド５０１では、以下のような処理が実行される。言い換えると、ユーザは新規アプリ３１７のｍａｉｎの処理を、以下の処理が行われるように記述することにより新規アプリ３１７の開発を行う。まず、図６に示すように、ｗｒａｐｐｉｎｇ＿ｔｈｒｄによってラッピングスレッド５０２を生成する。なお、このｗｒａｐｐｉｎｇ＿ｔｈｒｄは、コントロールサービスラッピング関数ライブラリに登録されている。
【００９０】
次に、実際のアプリの処理として、以下の処理を記述する。ｗｈｉｌｅループの中で、ｒｃｖｍａｉｌ関数によりラッピングスレッド５０２からメールボックスＷＲＡＰ＿ＭＢを介してデータを取得する。ここで、引数ｉｄは、受信データを送信したコントロールサービスの識別子（例えば、プロセスＩＤなど）を示している。そして、ＳＣＳ３２２などのコントロールサービスごとに処理を記述する。図６の例では、ｉｄがＳＣＳ３２２の場合に、パラメータｐａｒａの解析、かかる解析に基づいてＡＰＩを利用したＯＣＳ３２６に対する関数呼び出しやメッセージ送信などの処理、あるいはアプリケーション起動に関する処理を、新規アプリ３１７の所望の機能に基づいて記述する。そして、ｗｈｉｌｅループを抜けた後に、複合機３００にアプリケーションの終了を通知し、これによりリソースが解放される。
【００９１】
ここで、図６の例では、ｗｈｉｌｅループの中には、ｉｄがＳＣＳの場合におけるＯＣＳ３２６に対する処理、アプリケーション起動に関する処理が記述されているが、他のＥＣＳ３２４、ＭＣＳ３２５などのコントロールサービスに対するＡＰＩを利用した処理は記述されていない。これは、ＥＣＳ３２４、ＭＣＳ３２５などのコントロールサービスに対するＡＰＩ処理は複雑であるため、後述するラッピングスレッドによって行っているためである。
【００９２】
図７は、プロセス間通信スレッド５０３で実行されるイベント受信処理の手順を示すフローチャートである。プロセス間通信スレッド５０３では、コントロールサービスからのイベント待ちとなっている。プロセス間通信スレッド５０３がイベントを受信すると（ステップＳ７０１）、イベントを発したコントロールサービスの識別子を「ｉｄ」に設定し（ステップＳ７０２）、ｓｅｎｄｍａｉｌ関数によって受信したイベントをメールボックスＸＣＳ＿ＭＢを介してラッピングスレッド５０２に送信する（ステップＳ７０３）。実際には、各コントロールサービスごとに、Ｒｅｓ＿ｅｃｓ（）、Ｒｅｓ＿ｍｃｓ（）、Ｒｅｓｃ＿ｓｃｓ（）などの関数を有し、各関数の中で、ｉｄに各発信元のコントロールサービスの識別子を設定したｓｅｎｄｍａｉｌ関数を発行している。
【００９３】
図８は、ラッピングスレッド５０２（ｗｒａｐｐｉｎｇ＿ｔｈｒｄ関数）で行われるラッピング処理の手順を示すフローチャートである。ラッピングスレッド５０２では、まずプロセス間通信スレッド５０３の生成およびスレッド間の通信に使用されるメールボックスＷＲＡＰ＿ＭＢ、ＸＣＳ＿ＭＢの作成を行う（ステップＳ８０１）。そして、ｒｃｖｍａｉｌ（ＸＣＳ＿ＭＢ，ｐａｒａ，ｉｄ）関数を発行し（ステップＳ８０２）、プロセス間通信スレッド５０３からコントロールサービスのプロセスからの受信イベントがメールボックスＸＣＳ＿ＭＢに存在しているか否かをチェックする（ステップＳ８０３）。
【００９４】
そして、メールボックスＸＣＳ＿ＭＢに受信イベントが存在しない場合には、処理を終了し、ラッピングスレッド５０２はスリープ状態となる。一方、ｒｃｖｍａｉｌ関数の発行の結果、メールボックスＸＣＳ＿ＭＢにコントロールサービスからの受信イベントが存在している場合には、その引数ｉｄに設定されている値からイベントの発信元のコントロールサービスを判断する（ステップＳ８０４）。
【００９５】
ｉｄによりイベント発信元のコントロールサービスがＳＣＳ３２２またはＯＣＳ３２６である場合には、ｉｄにＳＣＳまたはＯＣＳの識別子を設定して、ｓｅｎｄｍａｉｌ（ＷＲＡＰ＿ＭＢ，ｐａｒａ，ｉｄ）関数を発行し、受信イベントをそのままメインスレッド５０１にメールボックスＷＲＡＰ＿ＭＢを介して送信する（ステップＳ８０５）。これにより、メインスレッド５０１では、前述のｒｃｖｍａｉｌ（ＷＲＡＰ＿ＭＢ，ｐａｒａ，ｉｄ）によって受信イベントをそのままの形式で受信することになる。
【００９６】
一方、ステップＳ８０４において、イベント発信元のコントロールサービスがＳＣＳ３２２またはＯＣＳ３２６以外のコントロールサービス、すなわち、ＥＣＳ３２４、ＭＣＳ３２５、ＦＣＳ３２７またはＮＣＳ３２８である場合には、ｓｅｎｄｍａｉｌ関数で受信イベントをメインスレッド５０１に送信することは行わず、引数ｐａｒａに設定されたパラメタの解析を行う（ステップＳ８０６）。そして、ラッピングスレッド５０１内部で、受信イベントに対するコントロールサービスに対する処理（ＡＰＩを利用した関数呼び出しと戻り値受信、メッセージ送受信など）を実行する（ステップＳ８０７）。このようなラッピング処理を行うことにより、コントロールサービスに対するＡＰＩを利用した関数呼び出しやメッセージ送受信などの複雑な処理を、ユーザが作成するメインスレッド５０１のソースコードに記述する必要はなくなる。
【００９７】
このようなラッピング処理は、コントロールサービスごとにあらかじめ定められている。図９は、コントロールサービスごとに、ラッピング処理を行う機能、ラッピング処理を行わずにユーザに開示する機能と、全くユーザに開示しない機能とを示す説明図である。
【００９８】
図９に示すように、イベントの発信元コントロールサービスがＳＣＳ３２２の場合には、機器の状態通知や電源断通知のような電源関連に関する機能は、ユーザの誤ったコーディングより、複合機３００のシステムに悪影響を与えることを防止するため、ラッピングスレッド５０２によるラッピング処理を行い、機器の状態通知や電源断通知に関する具体的なイベントはメインスレッド５０１には送信されない。
【００９９】
例えば、複合機３００のカバーが空いている場合には、ＳＣＳ３２２でかかる状態を検知して、機器状態通知イベントを新規アプリ３１７のプロセス間通信スレッド５０３に送信する。プロセス間通信スレッド５０３では、このイベントをｒｃｖｍａｉｌ関数で受信して、メインスレッド５０１ではなく、ラッピングスレッド５０２にｓｅｎｄｍａｉｌ関数によって送信する。ラッピングスレッド５０２では、ＳＣＳ３２２からの危機状態通知イベントをｒｃｖｍａｉｌ関数で受信すると、ラッピングスレッド５０２内で、カバーオープンの旨のメッセージをオペレーションパネル４１０に表示すべくＯＣＳ３２６とプロセス間通信の処理を行う。従って、ユーザが作成するメインスレッド５０１のソースコードには、機器状態通知イベントの受信に伴うプロセス間通信の処理を記述する必要はない。電源断通知イベントに対しても、ラッピングスレッド５０２において同様の処理が行われる。
【０１００】
しかし、図９に示すように、アプリケーション起動に関する機能はラッピング処理を行わないため、アプリケーション起動に関するイベントはラッピングスレッド５０２からｓｅｎｄｍａｉｌ関数でそのままメインスレッド５０１に送信される。さらに、ＳＣＳ３２２と他のコントロールサービス間のプロセス間通信については、全くユーザに開示されない。
【０１０１】
図９に示すように、イベントの発信元コントロールサービスがＥＣＳ３２４、ＭＣＳ３２５およびＦＣＳ３２７の場合には、全ての機能に対しラッピングスレッド５０２によるラッピング処理を行うため、ＥＣＳ３２４とＭＣＳ３２５からのイベントはメインスレッド５０１に送信されることはない。例えば、受信イベントの発信元がＥＣＳ３２４の場合には、ＭＣＳ３２５に対するメモリ確保要求、ＳＲＭ３２３に対する資源獲得要求などのＡＰＩ関数呼び出しやこれらに関するメッセージの送受信がラッピングスレッド５０２内で実行される。また、受信イベントの発信元がＭＣＳ３２５の場合には、例えば、ＳＲＭ３２３に対する資源獲得要求などの関数呼び出しやこれに関するメッセージの送受信がラッピングスレッド５０２内で実行される。さらに、受信イベントの発信元がＦＣＳ３２７の場合は、例えば、ＥＣＳ３２４に対するジョブモード設定要求、ジョブ開始要求、ジョブクローズ要求などの関数呼び出しや、ジョブエンド通知などのメッセージ受信がラッピングスレッド５０２内で実行される。
【０１０２】
図９に示すように、イベントの発信元コントロールサービスがＮＣＳ３２８の場合には、データ送信プロトコルに関する処理をラッピングスレッド５０２で行う。例えば、ｈｔｔｐやｆｔｐの各プロトコルに関連する処理がラッピングスレッド５０２内で実行される。なお、発信元コントロールサービスがＮＣＳ３２８の場合、データ送信プロトコルに関する処理以外の処理は、全て非公開であり、メインスレッド５０１で行われることはない。
【０１０３】
図９に示すように、イベントの発信元コントロールサービスがＯＣＳ３２６の場合には、全ての機能をユーザに開示し、ラッピング処理は行わないため、ＯＣＳ３２６からのイベントは全てｓｅｎｄｍａｉｌ関数によってメインスレッド５０１にそのまま送信される。
【０１０４】
このように実施の形態１にかかるアプリ開発キット１３１のラッピング関数では、各コントロールサービスごとにラッピング処理を行う機能が定められている。なお、上述したラッピング処理を行う機能については、これに限定されるものではなく、他の機能をラッピング処理の対象とすることも可能である。
【０１０５】
上記の他の機能として、例えば、仮想アプリケーションサービス（以下、ＶＡＳと称する）がある。図１０にＶＡＳを含む場合の実行時の構成を示す。図１０に示すように、ＶＡＳ３４０は、アプリケーション３３０とプラットホーム３２０の間に配置される。
【０１０６】
ＶＡＳ３４０は、プラットホーム１２０の各種コントロールサービスあるいはそのＡＰＩが仕様変更などでバージョンアップされた場合に、バージョン差の生じたアプリケーションを再コンパイルすることなくそのまま関数呼び出しが行えるよう、バージョン差を吸収して整合性を保つと共に、コントロールサービスからのメッセージを取捨選択することによってプラットホーム３２０を隠蔽することができる機能を備えている。更に、各アプリが登録される際に、各アプリとコントロールサービスおよびＡＰＩのそれぞれのバージョンを検出し、その検出されたバージョン差がＶＡＳ３４０によってサポート可能な範囲か否かを判定して、その判定結果をアプリに通知することにより、アプリ動作前にバージョンが不整合かどうかが判明するバージョン管理機能も備えている。
【０１０７】
ＶＡＳ３４０は、アプリから見るとコントロールサービス層として認識されるので、これまでに説明したようなコントロールサービスに対する処理のラッピングと同様にして、ＶＡＳ３４０に対する処理のラッピングを行うことが可能である。
【０１０８】
次に、ラッピング関数を利用した新規アプリ３１７の生成処理について説明する。図１１は、開発用サーバ１００による新規アプリ生成処理の手順を示すフローチャートである。起動コマンドが入力されると、デバッグ機能付きコンパイラ１１０が起動し、コマンド解析部１１１によって入力されたコマンドの解析を行う（ステップＳ１００１）。具体的にはパラメータや構文の解析を行って、入力されたコマンドが文法的に正確か否かを判断する。
【０１０９】
次に、構文解析部１１２によって、新規アプリソースファイル１３２とインストール済みのアプリ開発キット１３１の中のヘッダファイルを読み込み（ステップＳ１００２）、新規アプリソースファイル１３２に記述されたＣ言語ソースコードの構文解析を行う（ステップＳ１００３）。具体的には、構文解析部１１２は、Ｃ言語ソースコードをＣ言語文法に従って解析し、導出木や構文木などを生成する。
【０１１０】
そして、コマンド解析部１１１によって、入力された起動コマンドにデバッグオプションが指定されているか否かを調べる（ステップＳ１００４）。そして、デバッグオプションが指定されている場合には、関数の入口と出口などにｐｒｉｎｔｆ文やａｓｓｅｒｔ文などのデバッグ用に変数や関数引数あるいは関数戻り値などを出力するための検証コードとしてのタグを付加する（ステップＳ１００５）。一方、デバッグオプションが指定されていない場合には、タグ付加の処理は行わず、通常のコンパイル処理を行う。
【０１１１】
次に、コード生成部１１４によってコード生成処理を行って、新規アプリのオブジェクトコードを生成し、オブジェクトファイル１３３としてＨＤ１３０に格納する（ステップＳ１００６）。そして、生成された新規アプリ３１７のオブジェクトファイル１３３と、アプリ開発キット１３１のコントロールサービス関数ライブラリ、標準関数ライブラリ、ラッピング関数ライブラリ、ユーティリティライブラリとをリンクして、アプリ実行形式ファイル１３４を生成する（ステップＳ１００７）。これにより、新規アプリ３１７が生成される。
【０１１２】
このように実施の形態１にかかるアプリ開発キット１３１を利用したアプリケーション生成方法では、ユーザが各コントロールサービスの機能の概略を把握しておけば、コントロールサービスラッピング関数ライブラリを使用することで、コントロールサービスとのプロセス間通信の複雑な手順を新規アプリ３１７のソースコードに記述する必要がなく、新規アプリケーションを効率的に開発することができる。
【０１１３】
また、実施の形態１にかかるアプリ開発キットを利用したアプリケーション生成方法では、ラッピング関数が新規アプリ３１７に代わってコントロールサービスとのプロセス間通信を行っているので、コントロールサービスとのインタフェースを隠蔽して、重要なインタフェースの秘匿性を確保することができる。
【０１１４】
なお、ラッピング関数は、コントロールサービスに対する処理を記述したものであれば、必ずしもスレッドとして実行されるものでなくてもよい。
【０１１５】
（実施の形態２）
実施の形態１にかかるアプリ生成方法では、アプリ開発キット１３１の中のコントロールサービスラッピング関数ライブラリを利用して新規アプリ３１７を生成することにより、生成された新規アプリ３１７のプロセス内部のラッピングスレッド５０２によってコントロールサービスに対する処理を隠蔽するラッピング処理を行っていたが、この実施の形態２にかかるアプリ生成方法では、アプリ開発キット１３１の中のアプリラッピング関数ライブラリを利用して新規アプリ３１７を生成することにより、コントロールサービスに対する処理を既存のアプリケーション３３０を利用して隠蔽するラッピング処理を行うものである。
【０１１６】
図１２は、実施の形態２にかかる開発用サーバ１００のＨＤ１３０に格納されるファイルを示す説明図である。実施の形態２にかかる開発用サーバ１００のＨＤ１３０には、実施の形態１の開発用サーバ１００と同様に、アプリ開発キット１１０１がインストールされ、新規アプリソースファイル１３２と、アプリのオブジェクトファイル１３３と、アプリ実行形式ファイル１３４とが生成される。
【０１１７】
アプリ開発キット１１０１は、実施の形態１のアプリ開発キット１３１と同様に、ＣＤ−ＲＯＭまたはフレキシブルディスク（ＦＤ）などの記録媒体にインストール可能な形式で提供され、開発用サーバ１００のＨＤ１３０にインストールされる。この記録媒体のアプリ開発キット１１０１の中には、図１２に示すように、コントロールサービス関数ライブラリと、標準関数ライブラリと、アプリ関数ライブラリと、ユーティリティライブラリと、ヘッダファイルと、デバッグ機能付きコンパイラと、リンカと、汎用ＯＳプログラムと、デバッグ用ユーティリティとが含まれている。ここで、コントロールサービス関数ライブラリ、標準関数ライブラリ、ユーティリティライブラリ、ヘッダファイル、デバッグ機能付きコンパイラ、リンカ、汎用ＯＳプログラム、デバッグ用ユーティリティは、実施の形態１におけるアプリ開発キット１３１に含まれているものと同様である。すなわち、実施の形態２にかかるアプリ開発キット１１０１は、アプリラッピング関数ライブラリが含まれている点が実施の形態１にかかるアプリ開発キット１３１と異なっている。
【０１１８】
アプリ関数ライブラリは、プリンタアプリ３１１を呼び出すプリンタ関数ｐｒｉｎｔａｐ（）と、スキャナアプリ３１４を呼び出すスキャナ関数ｓｃａｎａｐ（）と、コピーアプリ３１２を呼び出すコピー関数ｃｏｐｙａｐ（）と、ファックスアプリ３１３を呼び出すファックス送信関数ｆａｘａｐ＿ｓｅｎｄ（）およびファックス受信関数ｆａｘａｐ＿ｒｃｖ（）とを登録したものである。
【０１１９】
次に、アプリ関数ライブラリを利用した新規アプリ３１７の生成処理について説明する。図１３は、開発用サーバ１００による新規アプリ生成処理の手順を示すフローチャートである。起動コマンドの解析からオブジェクトファイル１３３の生成までの処理（ステップＳ１２０１〜Ｓ１２０６）は、実施の形態１のアプリ生成方法で説明した図１１におけるステップＳ１００１からＳ１００６までの処理と同様である。
【０１２０】
新規アプリ３１７のオブジェクトファイル１３３が生成されたら、生成されたオブジェクトファイル１３３と、アプリ開発キット１３１のコントロールサービス関数ライブラリ、標準関数ライブラリ、アプリ関数ライブラリ、ユーティリティライブラリとをリンクして、アプリ実行形式ファイル１３４を生成する（ステップＳ１２０７）。これにより、新規アプリ３１７が生成される。
【０１２１】
図１４は、アプリ関数ライブラリ１３０１とリンクして開発した新規アプリ３１７と既存のアプリケーション３３０、およびコントロールサービスの複合機３００内での関係を示すブロック図である。図１４に示すように、新規アプリ３１７のソースコードには、スキャナ機能を使用するためにスキャナ関数ｓｃａｎａｐ、印刷機能を使用するためにプリンタ関数ｐｒｉｎｔａｐ、コピー機能を使用するためにコピー関数ｃｏｐｙａｐ、ファックス送信機能を使用するためにファックス送信関数ｆａｘａｐ＿ｓｅｎｄ、ファックス受信機能を使用するためにファックス受信関数ｆａｘａｐ＿ｒｃｖが記述されている。
【０１２２】
これらの関数は全てアプリ関数ライブラリ１３０１に登録されており、アプリ関数ライブラリ１３０１は新規アプリ３１７にリンクされているため、新規アプリ３１７内のｓｃａｎａｐ関数呼び出しによりスキャナアプリ３１４が、ｐｒｉｎｔａｐ関数呼び出しによりプリンタアプリ３１１が、ｃｏｐｙａｐ関数呼び出しによりコピーアプリ３１２が、ｆａｘａｐ＿ｓｅｎｄ関数呼び出しおよびｆａｘａｐ＿ｒｃｖ関数呼び出しによりファックスアプリ３１３がそれぞれ呼び出され実行されることになる。
【０１２３】
これらの各アプリでは、ＥＣＳ３２４、ＭＣＳ３２５などのコントロールサービスのプロセスに対して複雑な手順のサービス関数呼び出しまたはメッセージ送受信によるプロセス間通信が行われる。このため、新規アプリ３１７のソースコードに、これらのプロセス間通信の手順を記述する必要はなく、各機能に応じたアプリ関数ライブラリ１３０１の関数呼び出しを行えばよい。
【０１２４】
すなわち、例えばスキャナ機能を使用する場合には、新規アプリ３１７の中でＥＣＳ３２４に対してジョブ生成要求、ジョブモード設定要求などの処理を、ＭＣＳ３２５に対してメモリ確保要求などの処理を記述しなければならないため、ＡＰＩを用意しているとはいっても、各コントロールサービスに対するプロセス間通信処理の記述に誤りが生じる可能性がある。実施の形態２にかかるアプリ生成方法により生成された新規アプリ３１７では、アプリ関数ライブラリ１３０１に登録された各関数を呼び出すことにより、各機能に対応したアプリが呼び出され、呼び出された各アプリ内でコントロールサービスとのプロセス間通信が実現される。従って、新規アプリにおけるコントロールサービスに対する処理のラッピングが実現され、新規アプリ３１７の開発を効率的に行うことができる。
【０１２５】
なお、実施の形態２では、生成した新規アプリ３１７からの既存アプリの呼び出しを同一複合機３００内で行うこととしているが、新規アプリ３１７からネットワーク経由で既存アプリの呼び出しを行うようにしても良い。例えば、ネットワーク接続された異なる複合機間で、一方の複合機の新規アプリ３１７から他方の複合機内の既存アプリを呼び出すように構成することができる。また、デバッグ環境として複合機３００にネットワーク接続されたコンピュータのハードディスクに新規アプリ３１７を格納し、当該コンピュータのハードディスクをＮＦＳ（ネットワークファイルシステム）によって複合機３００にマウントし、コンピュータ内の新規アプリ３１７からネットワーク経由で複合機３００内の既存アプリを呼び出すように構成することができる。このようなネットワーク経由での既存アプリの呼び出しは、例えばＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ：遠隔手続呼び出し）などの機能を利用することにより実現することができる。
【０１２６】
なお、コピー、スキャン、プリント等のイメージに関する処理をスレッドとして実行させるように新規アプリ３１７を構成することも可能である。この場合、イメージに関する処理を記述した関数を登録したイメージライブラリを新規アプリ３１７にリンクさせる。図１５に、新規アプリ３１７の実行時における構成を示す。
【０１２７】
図１５に示すように、新規アプリプロセス３１７は、複数のスレッドが並列実行されたマルチスレッド環境となっており、メインスレッド６１０とイメージライブラリスレッド６００が並列実行される。メインスレッド６１０は、新規アプリの処理（例えば文字認識処理）を実行するスレッドであり、このメインスレッド６１０がイメージライブラリを利用する。
【０１２８】
イメージライブラリスレッド６００は、イメージライブラリの各機能（関数）を提供するものであり、メインスレッド６１０によって起動される。このとき、イメージライブラリスレッド６００の内部には、イメージライブラリの中の各ライブラリに対応する複数のサブスレッドが起動される。すなわち、スキャンスレッド６０１、プリントスレッド６０２、ファイル操作スレッド６０３がサブスレッドとなる。また、新規アプリプロセスには、メールボックス６１１、メールボックス６１２、イベント取得ハンドラ（スレッド）６１３が起動される。
【０１２９】
メールボックス６１１は、メインスレッド６１０とイメージライブラリスレッド６００およびイベント取得ハンドラ６１３との通信に使用される。メールボックス６１２は、メインスレッド６１０とイメージライブラリスレッド６００の通信に使用される。イベント取得ハンドラ６１３は、ＥＣＳ３２４，ＭＣＳ３２５などのコントロールサービスのプロセスからのイベントメッセージを受信し、メールボックス６１１に書き込む機能を有している。
【０１３０】
メインスレッド６１０は、イメージライブラリスレッド６００に対する関数呼び出しのコマンドを、メールボックス６１１に入れる。また、コントロールサービス３２０からのイベントメッセージも、メールボックス６１１に入る。イメージライブラリスレッド６００は、メールボックス６１１に配信されるメッセージをｒｃｖ＿ｍｓｇ（）関数によって取得する。そして、メッセージの内容に基づき、サブスレッドがコントロールサービスとのプロセス間通信を行いながら必要な処理を実行する。
【０１３１】
なお、イメージライブラリスレッド６００は、メインスレッド６１０に対して、エラー情報、実行結果、途中経過などの通知をメールボックス６１２に入れる。メインスレッド６１０は、メールボックス６１２に配信されるメッセージをｒｃｖ＿ｍｓｇ（）関数によって取得し、メッセージの内容に対応した処理を実行する。
【０１３２】
このように、コントロールサービスとのプロセス間通信に係る複雑な処理は、イメージライブラリスレッド６００が行うので、新規アプリ開発に際しては、main関数の中にコントロールサービスとのプロセス間通信に係る複雑な処理を記述する必要がない。すなわち、ラッピングが実現される。
【０１３３】
なお、上記の例において、イメージライブラリの処理は必ずしもスレッド６００として実行させる必要はない。ラッピングさせたい処理の内容をライブラリとして準備し、ライブラリにおける関数を利用することにより新規アプリの開発を効率的に行うことが可能である。
【０１３４】
本発明は、上記の実施形態に限定されることなく、特許請求の範囲内で種々変更・応用が可能である。
【発明の効果】
【０１３５】
以上説明したように、本発明によれば、コントロールサービスとのプロセス間通信の複雑な手順を新規アプリケーションのソースコードに記述する必要がなくなり、新規アプリケーションを効率的に開発することができるという効果を奏する。
【図面の簡単な説明】
【図１】 実施の形態１の開発用サーバのソフトウェア構成を示すブロック図である。
【図２】 実施の形態１にかかる開発用サーバ、開発用ＰＣのハードウェア構成および開発環境を示すブロック図である。
【図３】 実施の形態１にかかる複合機の機能的構成を示すブロック図である。
【図４】 実施の形態１にかかる複合機のハードウェア構成図である。
【図５】 実施の形態１のアプリ開発キットを利用して生成した新規アプリのプロセス内部と、ＥＣＳ、ＭＣＳなどのコントロールサービスのプロセスとの呼び出し関係を示す説明図である。
【図６】 実施の形態１のアプリ開発キットを使用して生成された新規アプリのメインスレッドで実行される処理のＣ言語ソースコードを示す説明図である。
【図７】 実施の形態１のアプリ開発キットを使用して生成された新規アプリのプロセス間通信スレッドで実行されるイベント受信処理の手順を示すフローチャートである。
【図８】 実施の形態１のアプリ開発キットを使用して生成された新規アプリのラッピングスレッドで行われるラッピング処理の手順を示すフローチャートである。
【図９】 実施の形態１にかかる複合機において、コントロールサービスごとにラッピング処理を行う機能、ラッピング処理を行わずにユーザに開示する機能と、全くユーザに開示しない機能とを示す説明図である。
【図１０】 ＶＡＳ３４０を含む場合における複合機の実行時の構成を示す図である。
【図１１】 実施の形態１にかかる開発用サーバによる新規アプリ生成処理の手順を示すフローチャートである。
【図１２】 実施の形態２にかかる開発用サーバのＨＤに格納されるファイルを示す説明図である。
【図１３】 実施の形態２にかかる開発用サーバによる新規アプリ生成処理の手順を示すフローチャートである。
【図１４】 実施の形態２にかかるアプリ開発キットを使用して生成された新規アプリと既存のアプリケーションおよびコントロールサービスの複合機内での関係を示すブロック図である。
【図１５】 コピー、スキャン、プリント等のイメージに関する処理をスレッドとして実行させる場合における新規アプリの実行時の構成を示す図である。
【符号の説明】
１００ 開発用サーバ
１１０ デバッグ機能付きコンパイラ
１１１ コマンド解析部
１１２ 構文解析部
１１３ タグ付加部
１１４ コード生成部
１２０ リンカ
１３０ ハードディスク（ＨＤ）
１３１，１１０１ アプリ開発キット
１３２ 新規アプリソースファイル
１３３ オブジェクトファイル
１３４ アプリ実行形式ファイル
２０１，２１１ 入力装置
２０２，２１２ 表示装置
２０３，２１３ ＲＡＭ
２０４，２１４ 制御装置
２０５，２１５ 外部記憶装置
２０６，２１６ 通信装置
３００ 複合機
３０１ 白黒ラインプリンタ
３０２ カラーラインプリンタ
３０３ ハードウェアリソース
３１０ ソフトウェア群
３１１ プリンタアプリ
３１２ コピーアプリ
３１３ ファックスアプリ
３１４ スキャナアプリ
３１５ ネットファイルアプリ
３１６ 工程検査アプリ
３２０ プラットホーム
３２１ 汎用ＯＳ
３２２ ＳＣＳ
３２３ ＳＲＭ
３２４ ＥＣＳ
３２５ ＭＣＳ
３２６ ＯＣＳ
３２７ ＦＣＳ
３２８ ＮＣＳ
３３０ アプリケーション
３４０ 仮想アプリケーションサービス（ＶＡＳ）
４００ コントローラボード
４０１ ＡＳＩＣ
４０２ ＣＰＵ
４０３ ＳＤＲＡＭ（ＲＡＭ）
４０４ フラッシュメモリ（ＲＯＭ）
４０５ ＨＤ
４０６ フラッシュカードインタフェース部
４０７ フラッシュカード
４０８ ＳＲＡＭ
４１０ オペレーションパネル
４３０ ＵＳＢ
４４０ ＩＥＥＥ１３９４
４５０ プリンタ
６００ イメージライブラリスレッド
６０１ スキャンスレッド
６０２ プリントスレッド
６０３ ファイル操作スレッド
６１０ メインスレッド
６１１、６１２ メールボックス
６１３ イベント取得ハンドラ
１３０１ アプリ関数ライブラリ

Claims (10)

1. 画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムを複数搭載可能に構成された画像形成装置であって、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備えた画像形成装置において実行されるアプリケーションプログラムであり、前記画像形成装置を、
   前記アプリケーションプログラムのメイン関数の処理を実行するメイン処理手段、
   前記複数のコントロールサービスプロセスとのプロセス間通信を行うプロセス間通信手段、
   前記複数のコントロールサービスプロセスのうちの予め定めたコントロールサービスプロセスの機能を利用するためのプロセス間通信処理を前記プロセス間通信手段を用いて実行するラッピング手段、として機能させるアプリケーションプログラムであって、
   前記ラッピング手段は、前記予め定めたコントロールサービスプロセスから受信したイベントに対する応答処理を実行し、前記予め定めたコントロールサービスプロセス以外のコントロールサービスプロセスからイベントを受信した場合には、前記応答処理を行わずに当該イベントを前記メイン処理手段に送信する、
   ことを特徴とするアプリケーションプログラム。
2. 前記ラッピング手段は、前記画像形成装置において、前記アプリケーションプログラムが実行されて生成されるプロセス内部でのラッピングスレッドとして機能することを特徴とする請求項１に記載のアプリケーションプログラム。
3. 前記ラッピング手段は、前記画像形成装置のエンジン制御を行うエンジンコントロールサービスプロセスが提供するいずれの機能においても、当該機能を利用するためのプロセス間通信処理を実行することを特徴とする請求項１又は２に記載のアプリケーションプログラム。
4. 前記ラッピング手段は、前記画像形成装置のメモリ制御を行うメモリコントロールサービスプロセスが提供するいずれの機能においても、当該機能を利用するためのプロセス間通信処理を実行することを特徴とする請求項１ないし３のうちいずれか１項に記載のアプリケーションプログラム。
5. 前記ラッピング手段は、前記画像形成装置のシステム制御を行うシステムコントロールサービスプロセスが提供する機能の中で、システム状態通知および電源状態に関する機能を利用するためのプロセス間通信処理を実行することを特徴とする請求項１ないし４のうちいずれか１項に記載のアプリケーションプログラム。
6. 前記ラッピング手段は、前記画像形成装置のネットワーク制御を行うネットワークコントロールサービスが提供する機能の中で、データ送信プロトコルを使用する機能を利用するためのプロセス間通信処理を実行することを特徴とする請求項１ないし５のうちいずれか１項に記載のアプリケーションプログラム。
7. 前記ラッピング手段は、前記複数のコントロールサービスプロセスのうち、前記画像形成装置のオペレーションパネルを制御するオペパネコントロールサービスプロセス以外のコントロールサービスプロセスが提供する機能を利用するためのプロセス間通信処理を実行することを特徴とする請求項１ないし６のうちいずれか１項に記載のアプリケーションプログラム。
8. 前記ラッピング手段は、前記アプリケーションプログラムが実行されて生成されるプロセスと前記コントロールサービスプロセスとの間に介在して実行される仮想アプリケーションサービスプロセスに対するプロセス間通信処理を実行することを特徴とする請求項１ないし７のうちいずれか１項に記載のアプリケーションプログラム。
9. 請求項１ないし８のうちのいずれか１項に記載のアプリケーションプログラムを記録したコンピュータ読み取り可能な記録媒体。
10. 画像形成処理で使用されるハードウェア資源とオペレーティングシステムとを備え、画像形成に関する処理を行うアプリケーションプロセスとして動作するアプリケーションプログラムを複数搭載可能に構成された画像形成装置であり、前記オペレーティングシステム上で動作し、複数の前記アプリケーションプロセスからアクセスされ、複数の前記アプリケーションプロセスで共通的に利用される機能を各アプリケーションプロセスに提供するコントロールサービスプロセスとして動作するコントロールサービスプログラムを複数備え、更にアプリケーションプログラムを備えた画像形成装置であって、当該アプリケーションプログラムは、前記画像形成装置を、
    前記アプリケーションプログラムのメイン関数の処理を実行するメイン処理手段、
    前記複数のコントロールサービスプロセスとのプロセス間通信を行うプロセス間通信手段、
    前記複数のコントロールサービスプロセスのうちの予め定めたコントロールサービスプロセスの機能を利用するためのプロセス間通信処理を前記プロセス間通信手段を用いて実行するラッピング手段、として機能させるアプリケーションプログラムであり、
    前記ラッピング手段は、前記予め定めたコントロールサービスプロセスから受信したイベントに対する応答処理を実行し、前記予め定めたコントロールサービスプロセス以外のコントロールサービスプロセスからイベントを受信した場合には、前記応答処理を行わずに当該イベントを前記メイン処理手段に送信する、
    ことを特徴とする画像形成装置。

Images