特許 6423645 画像形成装置およびリソース管理方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6423645

(24)【登録日】2018年10月26日

(45)【発行日】2018年11月14日

(54)【発明の名称】画像形成装置およびリソース管理方法およびプログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20181105BHJP

   H04N 1/00 20060101ALI20181105BHJP

【ＦＩ】

   G06F9/50 120A

   H04N1/00 C

【請求項の数】11

【全頁数】25

(21)【出願番号】特願2014-163049(P2014-163049)

(22)【出願日】2014年8月8日

(65)【公開番号】特開2016-38806(P2016-38806A)

(43)【公開日】2016年3月22日

【審査請求日】2017年8月4日

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100076428

【弁理士】

【氏名又は名称】大塚 康徳

(74)【代理人】

【識別番号】100112508

【弁理士】

【氏名又は名称】高柳 司郎

(74)【代理人】

【識別番号】100115071

【弁理士】

【氏名又は名称】大塚 康弘

(74)【代理人】

【識別番号】100116894

【弁理士】

【氏名又は名称】木村 秀二

(74)【代理人】

【識別番号】100130409

【弁理士】

【氏名又は名称】下山 治

(74)【代理人】

【識別番号】100134175

【弁理士】

【氏名又は名称】永川 行光

(72)【発明者】

【氏名】藤澤 邦匡

【審査官】 漆原 孝治

(56)【参考文献】

【文献】 特開２００７−０１１４９１（ＪＰ，Ａ）

【文献】 特開２００３−１２５１２２（ＪＰ，Ａ）

【文献】 特開２００３−３３０７３２（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

Ｈ０４Ｎ １／００

(57)【特許請求の範囲】

【請求項1】

アプリケーションプラットフォーム上にインストールされたそれぞれのアプリケーションから使用リソース宣言量を受信し、アプリケーション毎に前記使用リソース宣言量を保持する保持手段と、
アプリケーションからリソース取得ＡＰＩが呼び出されたことに応じて、前記アプリケーションが使用しているリソース量が前記使用リソース宣言量を超えているか否かを判定し、前記使用リソース宣言量を超えていると判定された場合は、前記アプリケーションに対してその旨を引き渡し、超えていないと判定された場合は、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すリソース管理手段と、
前記リソース管理手段と前記それぞれのアプリケーションとの間のインターフェースサービス手段と
を有し、
前記インターフェースサービス手段は、前記リソース管理手段が稼働している場合には前記リソース管理手段に対する参照を登録し、前記リソース管理手段が停止された場合には前記参照の登録を解除し、前記アプリケーションから前記リソース取得ＡＰＩが呼び出されたことに応じて、前記リソース管理手段に対する参照が登録されていれば、前記アプリケーションからの前記リソース取得ＡＰＩの呼び出しを前記リソース管理手段へとリダイレクトし、前記リソース管理手段に対する参照の登録が解除されていれば、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すことを特徴とする画像形成装置。

【請求項2】

前記保持手段は、さらに、前記それぞれのアプリケーションによるリソース使用量を、前記使用リソース宣言量に対応付けてリソースの種類ごとに管理し、
前記リソース管理手段は、呼び出された前記リソース取得ＡＰＩに応じたリソースの種類について、前記アプリケーションが使用しているリソース量が前記使用リソース宣言量を超えているか否かを判定し、
前記リソース管理手段はまた、前記リソースオブジェクトを引き渡す場合には、前記リソース生成により消費されたリソース量を、前記リソースの使用量に加算することを特徴とする請求項１に記載の画像形成装置。

【請求項3】

前記リソース管理手段は、前記リソース取得ＡＰＩが呼び出されたことに応じて、前記それぞれのアプリケーションが使用しているリソース量の総計が、前記アプリケーションプラットフォームにより提供できるリソース量の上限を超えているか否かを更に判定し、前記それぞれのアプリケーションが使用しているリソース量の総計が、前記アプリケーションプラットフォームにより提供できるリソース量の上限を超えていると判定された場合には、前記アプリケーションに対してその旨を引き渡すことを特徴とする請求項１または２に記載の画像形成装置。

【請求項4】

前記リソース管理手段はさらに、前記アプリケーションによるリソースの解放処理に応じて、指定されたリソースを解放し、解放したリソースの量を前記保持手段により保持された前記リソースの使用量から減じることを特徴とする請求項２又は３に記載の画像形成装置。

【請求項5】

前記リソース管理手段はさらに、前記アプリケーションによるリソースの使用に応じて、リソースの使用により消費されるリソース量を加えた当該リソースの使用量が、前記使用リソース宣言量を超えていない場合には、前記アプリケーションによるリソースの使用に応じてリソースを使用し、超えている場合にはその旨を前記アプリケーションに引き渡すことを特徴とする請求項１乃至４のいずれか一項に記載の画像形成装置。

【請求項6】

前記インターフェースサービス手段はさらに、前記リソース管理手段に対する参照の登録が解除されていれば、前記生成されたリソースオブジェクトで使用されたリソースの使用量の総計をアプリケーションごとに保持する手段を更に有し、
前記リソース管理手段は、稼働を再開した際には、前記保持されたリソースの使用量の総計を加えた現在のリソースの使用量が、前記使用リソース宣言量を超えているか否かを判定し、前記使用リソース宣言量を超えていると判定された場合は、前記アプリケーションに対してその旨を引き渡すことを特徴とする請求項１乃至５のいずれか一項に記載の画像形成装置。

【請求項7】

前記リソース管理手段および前記インターフェースサービス手段はともにそれぞれのプログラムをプロセッサで実行することで実現され、
前記リソース管理手段を実現するためのプログラムのインストールに際して、前記インターフェースサービス手段を実現するためのプログラムをさらにインストールするインストール手段を更に有することを特徴とする請求項１乃至６のいずれか一項に記載の画像形成装置。

【請求項8】

前記インストール手段は、前記リソース管理手段を実現するためのプログラムのインストールに際して、前記インターフェースサービス手段を実現するためのより新しいプログラムをインストールすることを特徴とする請求項７に記載の画像形成装置。

【請求項9】

前記リソース管理手段は、ファイルリソース、ソケットリソース、スレッドリソースの少なくともいずれかを含むことを特徴とする請求項１乃至８のいずれか一項に記載の画像形成装置。

【請求項10】

アプリケーションプラットフォーム上にインストールされたそれぞれのアプリケーションから使用リソース宣言量を受信し、アプリケーション毎に前記使用リソース宣言量を保持する保持手段と、
アプリケーションからリソース取得ＡＰＩが呼び出されたことに応じて、前記アプリケーションが使用しているリソース量が前記使用リソース宣言量を超えているか否かを判定し、前記使用リソース宣言量を超えていると判定された場合は、前記アプリケーションに対してその旨を引き渡し、超えていないと判定された場合は、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すリソース管理手段と、
前記リソース管理手段と前記それぞれのアプリケーションとの間のインターフェースサービス手段としてコンピュータを機能させるためのプログラムであって、
前記インターフェースサービス手段は、前記リソース管理手段が稼働している場合には前記リソース管理手段に対する参照を登録し、前記リソース管理手段が停止された場合には前記参照の登録を解除し、前記アプリケーションから前記リソース取得ＡＰＩが呼び出されたことに応じて、前記リソース管理手段に対する参照が登録されていれば、前記アプリケーションからの前記リソース取得ＡＰＩの呼び出しを前記リソース管理手段へとリダイレクトし、前記リソース管理手段に対する参照の登録が解除されていれば、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すことを特徴とするプログラム。

【請求項11】

アプリケーションプラットフォーム上にインストールされたそれぞれのアプリケーションから使用リソース宣言量を受信し、アプリケーション毎に前記使用リソース宣言量を保持する保持工程と、
アプリケーションからリソース取得ＡＰＩが呼び出されたことに応じて、前記アプリケーションが使用しているリソース量が前記使用リソース宣言量を超えているか否かを判定し、前記使用リソース宣言量を超えていると判定された場合は、前記アプリケーションに対してその旨を引き渡し、超えていないと判定された場合は、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すリソース管理工程と、
インターフェースサービス工程と
を有し、
前記インターフェースサービス工程では、前記リソース管理工程が稼働している場合には前記リソース管理工程に対する参照を登録し、前記リソース管理工程が停止された場合には前記参照の登録を解除し、前記アプリケーションから前記リソース取得ＡＰＩが呼び出されたことに応じて、前記リソース管理工程に対する参照が登録されていれば、前記アプリケーションからの前記リソース取得ＡＰＩの呼び出しを前記リソース管理工程へとリダイレクトし、前記リソース管理工程に対する参照の登録が解除されていれば、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すことを特徴とするリソース管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は画像形成装置およびリソース管理方法に関するものである。

【背景技術】

【0002】

現在の多機能周辺装置(MFP)はソリューションの実現のため、ドキュメントのコピーやスキャン、印刷といったMFPに組み込まれた機能以外のアプリケーションを実行する機能をもつものが増えてきている。多くのMFPではアプリケーション実行環境としてＪａｖａ（登録商標）の実行環境をもち、Ｊａｖａで記述されたアプリケーションを実行することができる。アプリケーション実行環境の例としてはキヤノンのMEAP等があげられる。PC上のＪａｖａアプリケーション場合には一つのＪａｖａプロセスは一つのアプリケーションを実行する。一方、MFPではCPUやメモリの制限のためOSGiフレームワークなどを使用して一つのＪａｖａのプロセスで複数のアプリケーションを実行するものが多い。OSGiフレームワークは一つのＪａｖａＶＭ上で複数のアプリケーションを実行するためのアプリケーションプラットフォームである。そのためMFP上で実行しているアプリケーションの一つにバグがありリソースリーク、例えばメモリリークを起こしている場合、OutOfMemoryError等のリソース不足によるエラーが発生しすべてのアプリケーションが停止してしまう可能性がある。また、リソース不足によるエラー、例えばOutOfMemoryError等のエラーはアプリケーションがリソースを要求したときに、割り当てられるリソースが無かった場合に発生するため、問題のないアプリケーションの実行中に発生することがある。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開2005-269439号公報

【特許文献2】特開2013-145503号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

そのためリソースリークを起こしているアプリケーションを特定することは困難であった。

【0005】

一方、特許文献１で示されているようにスレッド毎にリソースを計測する技術は存在した。しかし、特許文献１の図１３のように一つのスレッドが複数のアプリケーションのコードを実行するような場合にアプリケーション毎の使用リソースを計測することができなかった。

【0006】

さらに特許文献２のようにアプリケーション実行環境自体に修正を加えてリソース管理を行う技術は存在する。しかしメモリやCPU等のリソースが限られているMFPにおいてアプリケーション実行環境にリソース管理を追加する修正は困難である。

【0007】

本発明は上記従来例に鑑みて成されたもので、アプリケーション毎にリソースの管理をおこなうリソース管理装置及び方法を提供することを目的とする。さらに、リソースが限られているアプリケーション実行環境においてリソース管理を追加的に実施できる画像形成装置及び該装置によるリソース管理方法を提供することを目的とする。

【課題を解決するための手段】

【0008】

上記目的を達成するために本発明は以下の構成を有する。すなわち、アプリケーションプラットフォーム上にインストールされたそれぞれのアプリケーションから使用リソース宣言量を受信し、アプリケーション毎に前記使用リソース宣言量を保持する保持手段と、
アプリケーションからリソース取得ＡＰＩが呼び出されたことに応じて、前記アプリケーションが使用しているリソース量が前記使用リソース宣言量を超えているか否かを判定し、前記使用リソース宣言量を超えていると判定された場合は、前記アプリケーションに対してその旨を引き渡し、超えていないと判定された場合は、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すリソース管理手段と、
前記リソース管理手段と前記それぞれのアプリケーションとの間のインターフェースサービス手段と
を有し、
前記インターフェースサービス手段は、前記リソース管理手段が稼働している場合には前記リソース管理手段に対する参照を登録し、前記リソース管理手段が停止された場合には前記参照の登録を解除し、前記アプリケーションから前記リソース取得ＡＰＩが呼び出されたことに応じて、前記リソース管理手段に対する参照が登録されていれば、前記アプリケーションからの前記リソース取得ＡＰＩの呼び出しを前記リソース管理手段へとリダイレクトし、前記リソース管理手段に対する参照の登録が解除されていれば、前記アプリケーションプラットフォームに対してリソース生成を要求し、当該要求に応じて生成されたリソースオブジェクトを引き渡すことを特徴とする。

【発明の効果】

【0009】

本発明によれば、複数のアプリケーションを並列に動作させるアプリケーション実行環境で、アプリケーション毎のリソース管理が可能になる。また、リソースが限られているアプリケーション実行環境においてリソース管理の追加的な実施を容易に行える。

【図面の簡単な説明】

【0010】

【図1】システム構成図

【図2】ソフトウェア構成図

【図3】アプリケーションプラットフォーム構成図

【図4A】アプリケーションのＡＰＩ登録手順のフローチャート

【図4B】アプリケーションのＡＰＩ使用手順のフローチャート

【図5】リソースサービスの提供するＡＰＩを示す図

【図6】リソースサービスのソフトウェア構成図

【図7】アプリケーションファイルの構成図

【図8】リソースサービスのリソース量記憶部を示す図

【図9】サービスＡＰＩ部初期化処理のフローチャート

【図10A】リソース取得のフローチャート

【図10B】リソース取得のフローチャート

【図11】アプリケーションのファイル書き込みのフローチャート

【図12】実施例２のリソースサービスのプログラムを保持するＪａｒファイルの構造を示す図

【図13】実施例２のリソースサービスの起動処理のフローチャート

【図14】リソースサービスとＲＳＩサービスの機能の比較表を示す図

【図15A】実施例２のリソースサービスのソフトウェア構成図

【図15B】実施例２のリソースサービスのソフトウェア構成図

【図16】実施例２のリソース取得シーケンス図を示す図

【図17】ＲＳＩサービスのリソース使用量記憶テーブルを示す図

【図18】実施例３のＲＳＩサービスのリソース取得のフローチャート

【図19】実施例３リソースサービスのリソース量記憶部の更新処理のフローチャート

【発明を実施するための形態】

【0011】

［実施例１］
＜画像形成装置のハードウェア＞
図１は、たとえば多機能周辺装置などである画像形成装置１００のハードウェア構成を示すブロック図である。ＣＰＵ１０１は、画像形成装置１００のソフトウェアプログラムを実行し、装置全体の制御を行なうプロセッサあるいはコンピュータである。ＲＯＭ１０２は、リードオンリーメモリであり、装置のブートプログラムや固定パラメータ等が格納されている。ＲＡＭ１０３は、ランダムアクセスメモリであり、ＣＰＵ１０１が装置を制御する際に、一時的なデータの格納などに使用する。外部記憶装置１０４は、インストールされたアプリケーションやアプリケーションのデータや印刷データの格納など、様々なデータの格納に使用する。ＵＳＢＨ Ｉ／Ｆ制御部１０５はＵＳＢホストインターフェースを制御するためのものであり、さまざまなＵＳＢデバイスとの通信を制御する。スキャナＩ／Ｆ制御部１０６は、スキャナ１１１を制御する装置である。プリンタＩ／Ｆ制御部１０７は、プリンタ１１２を制御する装置である。ＮＶＲＡＭ１０８は、不揮発性のメモリでありアプリケーション管理装置の各種設定値が保存される。パネル制御部１０９は、操作パネル１１３を制御し、各種情報の表示、ユーザからの指示入力を行なうためのものである。ネットワークＩ／Ｆ制御部１１０は、ネットワーク１１５とのデータの送受信を制御する。バス１１４には、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、外部記憶装置１０４、ＵＳＢＨ Ｉ／Ｆ制御部１０５、スキャナＩ／Ｆ制御部１０６、プリンタＩ／Ｆ制御部１０７、ＮＶＲＡＭ１０８、パネル制御部１０９、ネットワークＩ／Ｆ制御部１１０が接続される。またバス１１４は、ＣＰＵ１０１からの制御信号や各装置間のデータ信号が送受信されるシステムバスである。ＩＣカードリーダ１１６は認証をおこなうためのＵＳＢデバイスである。

【0012】

＜画像形成装置のソフトウェア＞
画像形成装置１００は、例えばＯＳＧｉプラットフォームなどのアプリケーションプラットフォームを提供し、そのアプリケーションプラットフォーム上では、例えばＪＡＶＡ（登録商標）で記述した複数のアプリケーションプログラムをインストールし、並列に実行することが可能である。画像形成装置１００は、本明細書ではアプリケーションを管理する装置としての観点からアプリケーション管理装置とも呼ばれ、また、アプリケーションのリソース管理を行う装置としての観点からリソース管理装置と呼ばれる。

【0013】

図２は画像形成装置１００のソフトウェア２００の構成を示す図である。ハードウェア２０１はアプリケーション管理装置のソフトウェアを実行する、例えば図１に示したＲＡＭ１０２やＣＰＵ１０１等である。ＯＳ２０２はプロセスの管理、メモリ管理、入出力管理を実行する。Nativeアプリ２０３は、コピー等、機器の基本的な機能を実現するプログラムである。ソフトウェア２００はＪａｖａＶＭ（Ｊａｖａ仮想マシン）２０４とプリケーションプラットフォーム２０５とから構成される。ＪａｖａＶＭ２０４はＪａｖａプログラムを実行する仮想マシンである。アプリケーションプラットフォーム２０５は単一のＪａｖａＶＭ上で少なくとも一つ以上のアプリケーションプログラムの起動、停止、インストール、アンインストールといったアプリのライフサイクルの管理をおこなうプログラムであり、たとえばＯＳＧｉプラットフォームなどである。アプリケーションＡ２０６、アプリケーションＢ２０７はアプリケーションプラットフォーム２０５上で動作するアプリケーションプログラムである。ＪａｖａＶＭ２０４は、アプリケーションプラットフォーム２０５およびアプリケーションＡ２０６、アプリケーションＢ２０７は一つのＪａｖａアプリケーション２０８として処理する。アプリケーションプラットフォーム２０５上で実行されるアプリケーションのひとつとして、後述するリソースサービスプログラムがある。ＰＣ２０９はアプリケーションプラットフォーム２０５とネットワーク１１５を経由して通信を行い、アプリケーションプラットフォーム２０５に対してアプリケーションプログラムの起動、停止、インストール、アンインストールの指示をおこなう。

【0014】

図３はアプリケーションプラットフォーム２０５の構成を示す図である。アプリケーションプラットフォーム２０５はアプリケーションプログラムの起動、停止、インストール、アンインストールといったアプリのライフサイクルの管理をおこなうアプリケーション管理部３０１と、サービスＡＰＩ管理部３０２とを持つ。サービスＡＰＩ管理部３０２はアプリケーションプラットフォーム上で動作するアプリケーションが公開する機能（すなわちサービス）を他のアプリケーションから使用できるようにするためのサービスＡＰＩ部３０６の生成を管理する。サービスＡＰＩ管理部３０２は、機能を提供するアプリケーションが公開するＡＰＩ３０３とそのアプリケーションの識別子３０４とから構成されるテーブル３０５をもつ。テーブル３０５には、例えば新たなアプリケーションがインストールされたときに、そのアプリケーションのアプリケーション識別子とサービスを特定するためのＡＰＩとが登録される。

【0015】

そして機能を利用するアプリケーションからの要求に対応するサービスＡＰＩ部３０６を、アプリケーションの識別子３０４で識別される機能を提供するアプリケーションから取得し、機能を利用するアプリケーションに渡す。サービスＡＰＩ部３０６は機能を使用するアプリケーションの識別子を保存するフィールド３０７と、一つ以上の機能を提供するアプリケーションが公開しているＡＰＩ３０８から構成される。機能を使用するアプリケーションはサービスＡＰＩ部３０６を取得し、サービスＡＰＩ部３０６に実装されているＡＰＩ３０８を呼び出すことにより機能を提供するアプリケーションの機能を使用する。機能を使用するアプリケーションがサービスＡＰＩ部３０６を呼び出すと、サービスＡＰＩ部３０６は、機能を使用するアプリケーションのアプリケーション識別子３０７を付加して機能を提供するアプリケーション本体の機能を実現するＡＰＩを呼び出す。このサービスＡＰＩを介したサービスの要求および提供の手順は、図４Ａ、図４Ｂを参照して後述する。

【0016】

図５は、本実施形態に係るリソースサービスが他のアプリケーションに提供するＡＰＩの表である。リソースサービスのサービスＡＰＩがこのＡＰＩを実装し、リソースサービスを使用するアプリケーションはこれらのＡＰＩを呼び出しリソースの取得、使用をおこなう。具体的には、ＡＰＩとして公開された各クラスのオブジェクトの、要求するサービスに応じたメソッドを呼び出す。図５のクラス欄はリソースサービスがアプリケーションに提供するクラスである。「ラップしているＪａｖａ標準クラス」欄は、RSFileクラス、RSFileInputStreamクラス、RSFileOutpuStreamクラス、RSSocketクラス、RSThreadクラスがそれぞれラップしているＪａｖａ標準クラス名である。メソッド欄はそれぞれのクラスのメソッドのうちリソースサービス特有の機能が実装されているメソッドである。なおＪａｖａ標準クラスをラップして定義されているクラスは、リソースサービスにより提供されるリソースオブジェクトであり、図５に示したメソッドは、ラップされたＪａｖａ標準クラスのメソッドのうち、リソースサービス特有の機能が実装されているメソッドである。説明欄は各クラスやメソッドが提供するリソースサービス特有の機能の説明である。

【0017】

機能提供アプリケーションが公開するＡＰＩは例えばクラスとメソッドの組み合わせなどで特定される。例えばResourceServiceクラスのgetFileメソッドは、"ResourceService.getFile"などと指定され、当該ＡＰＩが特定されて呼び出される。したがって、サービスＡＰＩ３０５には、図５に示したクラス名と当該クラスに属するメソッド名との組み合わせが登録されている。

【0018】

図５に示したＡＰＩは説明欄に記載した通りのサービスを提供する。たとえばResourceServiceクラスはアプリケーションがリソースサービス６０１に対してリソースの取得要求や解放要求等を行うためのクラスであり、Ｊａｖａ標準クラスをラップしていない。ResourceServiceクラスのgetFileメソッドは、ファイルリソースのリソースオブジェクトを取得するためのメソッドであり、RSfileクラスのインスタンス、すなわち確保したリソースのリソースオブジェクトを返す。ファイルオブジェクトはファイルリソースに相当する。getSocket、getThreadメソッドはそれぞれソケットオブジェクトおよびスレッドオブジェクトを取得するためのメソッドであり、それぞれたとえば通信リソースおよびコンピューティングリソースに相当する。

【0019】

このほかのクラスはリソースオブジェクトのクラスであり、Ｊａｖａ標準クラスをラップして定義されている。それぞれのクラスの説明は、当該クラスがラップしているＪａｖａ標準クラスのメソッドのうちリソースサービス特有の機能が実装されているメソッドである。ラップしているＪａｖａ標準クラスのメソッドと同じ処理を行うメソッドについては説明は省略した。たとえばRSfileクラスはJava.io.fileすなわちfileクラスをラップしており、deleteメソッドは、fileクラスのdeleteメソッドに加えて、削除したファイルサイズ分のストレージ使用量を、現在の使用量から減算する処理を実行する。このほかのfileクラスのメソッドについては、fileクラスと同様の処理が行われる。その他のクラス及びメソッドについての説明は省くが、上述した例と同様に図５を読めばよい。このため、リソースサービスを用いて生成したリソースオブジェクトは、リソースサービスを用いずに生成したリソース（Java標準のリソースオブジェクト）と同様に扱うことができる。

【0020】

＜サービスＡＰＩ登録処理＞
図４Ａは機能を公開するアプリケーション４０１がサービスＡＰＩ管理部３０２にＡＰＩを登録する処理を、図４Ｂは機能を使用するアプリケーションがサービスＡＰＩ部を取得する処理をそれぞれ示す図である。まず、図４Ａを参照してＡＰＩ登録処理について説明する。

【0021】

機能を公開する、すなわちサービスを提供するアプリケーション４０１がサービスＡＰＩ登録処理を開始する(Ｓ４０２)。機能を公開するアプリケーション４０１はサービスＡＰＩ管理部３０２に対してサービスＡＰＩ情報とアプリケーション識別子とを引数としてサービスＡＰＩ登録要求Ｃ４０４を出す(Ｓ４０３)。サービスＡＰＩ情報はサービスを特定するための識別名等の情報を含む。サービスＡＰＩ管理部３０２から登録通知Ｒ４０６が返ってくるとＳ４０９に遷移し、サービスＡＰＩ登録処理を終了する(Ｓ４０９)。エラー(Ｒ４０５)が返ってきたらエラー処理を行い(Ｓ４０８)、サービスＡＰＩ登録処理を終了する(Ｓ４０９)。

【0022】

サービスＡＰＩ管理部３０２はサービスＡＰＩ登録要求Ｃ４０４を受けるとサービスＡＰＩおよびアプリケーションの登録処理を開始する(Ｓ４１６)。まず、Ｓ４１６で受信したＡＰＩ登録要求Ｃ４０４からサービスＡＰＩ情報とアプリケーション識別子とを取得する(Ｓ４１７)。次にテーブル３０５を検索し、Ｓ４１７で取得したサービスＡＰＩ情報がテーブル３０５に登録済みかを調べる(Ｓ４１８)。登録済みであれば機能を公開するアプリケーション４０１に対してエラーＲ４０５を返し(Ｓ４１９) 、サービスＡＰＩ登録処理を終了する(Ｓ４２２)。未登録であればＳ４１７で取得したサービスＡＰＩ情報とアプリケーション識別子とをテーブル３０５に登録する(Ｓ４２０)。さらに機能を公開するアプリケーション４０１に対して登録通知Ｒ４０６を返し(Ｓ４２１)、サービスＡＰＩ登録処理を終了する(Ｓ４２２)。本実施例ではリソースサービスがサービスを提供するアプリケーションとして図４Ａに示すサービスＡＰＩの登録処理を実行し、リソースサービスのサービスＡＰＩとリソースサービスのアプリケーション識別子の登録をおこなう。

【0023】

＜サービスＡＰＩ取得処理＞
次に図４Ｂを参照してサービスＡＰＩ部取得処理について説明する。機能を使用するアプリケーション４４０はサービスＡＰＩ部取得処理を開始する(Ｓ４３４)。次に使用したい機能を示すサービスＡＰＩ情報とアプリケーション４４０自身のアプリケーション識別子を引数にサービスＡＰＩ管理部３０２に対してサービスＡＰＩ部要求Ｃ４２３を出す(Ｓ４３５)。サービスＡＰＩ管理部３０２からサービスＡＰＩ部が取得できたかを調べる(Ｓ４３６)。エラーが返ってサービスＡＰＩ部を取得できなかった場合はエラー処理をおこない(Ｓ４３９)、サービスＡＰＩ部取得処理を終了する(Ｓ４３８)。サービスＡＰＩ部を取得できた場合はサービスＡＰＩ部を介してアプリ提供機能すなわち他のアプリケーションにより提供されるサービスを使用した処理を行い(Ｓ４３７)、サービスＡＰＩ部取得処理を終了する(Ｓ４３８)。リソースサービスを使用するアプリケーション４４０では、Ｓ４３７はリソースを取得、使用する処理となる。

【0024】

サービスＡＰＩ管理部３０２は機能を使用するアプリケーション４４０からサービスＡＰＩ部要求Ｃ４２３を受けるとサービスＡＰＩ部生成処理を開始する(Ｓ４２４)。アプリケーションＡＰＩ管理部３０２はサービスＡＰＩ部要求Ｃ４２３から、要求されたアプリケーションＡＰＩ情報を取得する(Ｓ４２５)。次にＳ４２５で取得したアプリケーションＡＰＩ情報をキーにテーブル３０５を検索し、存在しなければサービスＡＰＩ部要求Ｃ４２３を発行したアプリケーション４４０に対してエラーＲ４３３を通知し(Ｓ４３２)、サービスＡＰＩ部生成処理を終了する(Ｓ４３１)。存在すればアプリケーションＡＰＩ情報に対応するアプリケーション識別子を取得する(Ｓ４２７)。次にＳ４２７で取得したアプリケーション識別子で識別される、機能を公開しているアプリケーション４０１に対して機能を使用するアプリケーション４４０のアプリケーション識別子を引数にサービスＡＰＩ部生成要求Ｃ４１０を出す(Ｓ４２８)。サービスＡＰＩ部を含むサービスＡＰＩ部応答Ｒ４１５を受信すると、機能を使用するアプリケーション４４０にサービスＡＰＩ部Ｒ４３０を提供し(Ｓ４２９)、サービスＡＰＩ部取得処理を終了する(Ｓ４３１)。

【0025】

機能を公開しているアプリケーション４０１は、サービスＡＰＩ管理部３０２からサービスＡＰＩ部生成要求Ｃ４１０を受信したらサービスＡＰＩ部の生成処理を開始する(Ｓ４１１)。次にサービスＡＰＩ部生成要求Ｃ４１０から機能を使用するアプリケーション４４０のアプリケーション識別子を取得する(Ｓ４１２)。さらにサービスＡＰＩ部を生成し、Ｓ４１２で取得した、機能を使用するアプリケーション５０１のアプリケーション識別子をアプリケーション識別子保存フィールド３０７に保存し、サービスＡＰＩ部の初期化処理をおこなう(Ｓ４１４)。サービスＡＰＩ管理部３０２に対してサービスＡＰＩ部を返し(Ｒ４１４)、サービスＡＰＩ部生成処理を終了する(Ｓ４１４)。なお、本実施例ではサービスＡＰＩ部はオブジェクトであり、ステップＳ４１３におけるサービスＡＰＩ部の生成及び初期化は、サービスＡＰＩのインスタンスの生成及び初期化で実現される。したがってステップＳ４３７では、機能を使用するアプリケーション４４０は、生成されたオブジェクトの使用する機能に応じたメソッドを呼び出すことでＡＰＩを通じて供されるサービスを使用する。またステップＳ４１３の詳細は図９を参照して後述する。

【0026】

以上、図４Ａ，図４Ｂで説明した仕組みはたとえばＯＳＧｉプラットフォームで提供され、機能提供アプリケーション（サービスバンドル）の登録、及び機能利用アプリケーション（サービス消費バンドル）によるサービスＡＰＩ部の取得はＯＳＧｉで提供される機能で実現できる。

【0027】

＜リソースの取得の例＞
図６は、リソース管理に係るサービスを提供するプログラムであるリソースサービス６０１の構成と、リソースサービス６０１によるサービスを使用してリソースサービス６０１からリソースを取得するリソースサービス対応アプリケーション６０７の構成を示す図である。リソースサービス６０１からリソースを取得するアプリケーション６０７は使用するリソース量が宣言されているアプリケーション情報６０８とアプリの機能を実現するプログラム６０９とから構成される。プログラムはリソースサービス６０１から取得したリソースを使用した処理を実行する。

【0028】

リソースサービス６０１はアプリケーションプラットフォーム２０５上で動作するアプリケーションである。リソースサービス６０１は、アプリケーションから使用するリソースの宣言量を取得するアプリ宣言量取得部６０２、アプリ宣言量取得部６０２で取得したリソース量とアプリが使用しているリソース量とを、例えばアプリケーション識別子と関連付けるなどしてアプリ毎に記憶するリソース量記憶部６０３を持つ。さらにアプリ毎にリソースサービスのサービスＡＰＩ部６０４、アプリケーションに対してリソースを提供するかを判断するリソース管理部６０５、リソースを生成するリソース生成部６０６を持つ。サービスＡＰＩ部６０４は図３に示すサービスＡＰＩ部３０６に相当し、アプリケーションとの対応付けは、アプリケーション識別子３０７により実装される。

【0029】

アプリ宣言量取得部６０２はリソースサービス対応アプリケーション６０７からアプリケーション６０７が使用すると宣言したリソース量の情報を取得する(６１０)。
リソースサービス対応アプリケーション６０７はアプリケーションＡ用のリソースサービスＡＰＩ部を呼び出し、リソース取得要求(６１１)をおこなう。アプリケーションＡ６０７に割り当てられるリソースがある場合、リソースサービス６０１はアプリケーションＡ６０７にリソースを返す(６１２)。無い場合はエラーを返す(６１３)。

【0030】

＜アプリケーション情報＞
図７はリソースを取得するアプリケーション６０７を構成するアプリケーション情報６０８の詳細を示す図である。アプリケーション情報６０８にはアプリケーションの設定情報がキーとバリューのリストとして保存されている。使用リソース情報として使用するディスクサイズの最大値を示す最大ディスクサイズ７０１、使用するソケットの数の最大値を示す最大ソケット数７０２、使用するスレッドの数の最大値を示す最大スレッド数７０３、使用する開いたファイルの数の最大値を示す最大オープンファイル数７０４が、キーと対応する値のリストとして記述されている。もちろんこれらはリソースの一例であって、他のリソースについての最大値の宣言を含んでもよい。またアプリケーションの名称や識別ＩＤ（識別子）なども情報も記述されている。アプリケーション情報６０８は、たとえばＪａｖａ（登録商標）ではマニフェストに含まれている。

【0031】

＜リソース量記憶部＞
図８はソース量記憶部６０３の詳細を示す図である。リソース量記憶部６０３はアプリケーション毎（すなわちアプリケーション名８０１毎）に、アプリケーションが宣言する宣言リソース量８０２と現在アプリケーションが使用しているリソース量８０３とを記憶している。宣言リソース量は、該当するアプリケーションのアプリケーション情報６０８から取得したリソース情報に含まれた各リソースの最大値である。たとえばアプリケーションＡに対しては、ファイルリソースとして２０ＭＢ、ファイルデスクリプタ（ファイルの識別子に相当する）が２０、ソケットリソースが１０、スレッドリソースが１０という各リソースの最大値が登録されている。さらにリソース管理部６０３には、リソースサービス６０１が提供可能な各リソースの最大値が登録されていてもよい。リソースサービス６０１が提供可能な各リソースの最大値は、あるいはリソース管理部６０５などに登録されていてもよい。リソースサービス６０１が提供可能な各リソースの最大値は、たとえばアプリケーションプラットフォーム２０５が提供できるリソースの限度に応じて、例えばリソースサービス６０１のインストール時に登録される。

【0032】

＜サービスＡＰＩ部初期化処理＞
図９はリソースサービス６０１のサービスＡＰＩ部が取得された時に実行されるサービスＡＰＩ部初期化処理Ｓ４１３の詳細を示す図であり、図４ＢのステップＳ４１３の詳細を示す。なおリソースサービスのサービスＡＰＩのうち、リソース要求のために呼び出すＡＰＩを特にリソース取得ＡＰＩと呼ぶことがある。サービスＡＰＩ部初期化処理が開始されると（Ｓ９０１）、リソースサービス６０１のアプリ宣言量取得部６０２は、サービスＡＰＩ部を取得しようとしているアプリケーション４４０のアプリケーション情報を取得する(Ｓ９０２)。Ｓ４４１で受信したサービスＡＰＩ部要求には、リソースサービス６０１を利用するアプリケーション４４０のアプリケーション識別子が含まれており、それによりアプリケーション４４０を特定できる。取得したアプリケーション情報は図７の７０１〜７０４のようなキーと値のリストとして取得される。

【0033】

Ｓ９０３〜Ｓ９０６では、Ｓ９０２で取得したアプリケーション情報に含まれたリストのすべての項目に対してＳ９０４〜Ｓ９０６の処理を行い、すべてのアプリケーション情報を対象としてチェックを行ったらループを抜け(Ｓ９０３)、リソースサービス６０１サービスＡＰＩ部初期化処理Ｓ４１３の処理を終了する。ループの内ではアプリケーション情報の名前を一つ取得する(Ｓ９０４)。次に取得したアプリケーション情報に含まれたキーが所定の使用リソース宣言量であるかを判断し(Ｓ９０５)、使用リソース宣言量であればＳ９０６に遷移する。Ｓ９０５で使用リソース宣言量でなければＳ９０３に遷移する。Ｓ９０６では取得したリソース量をソース量記憶部６０３に、アプリケーション８０１毎、かつリソース８０２毎に保存し(Ｓ９０６)、Ｓ９０３に遷移する。この手順により、サービスを利用するアプリケーションごとに、使用するリソースごとの上限を保存し、設定できる。使用リソース量８０３は初期化して０に設定しておく。

【0034】

＜リソース取得手順＞
図１０Ａ、図１０Ｂはアプリケーションがリソース取得要求をしたときにアプリケーション６０７、リソースサービスのＡＰＩ部６０４、リソースサービスのリソース管理部６０５の処理を示したものである。

【0035】

アプリケーションＡ６０７がリソースを使用する処理を開始（Ｓ１００１）する。アプリケーションＡ６０７はアプリケーションＡ用のリソースサービスのＡＰＩ部６０４の提供するＡＰＩ３０８を呼び出して（Ｃ１０３８）、リソース要求をおこなう（Ｓ１００２）。このときリソースサービスのＡＰＩ部６０４に伝える情報は取得したいリソースの種類と取得したいリソースの量である。

【0036】

アプリケーションＡ６０７はリソース要求に応じたリソースが取得できたかを判断し（Ｓ１００３）、要求したリソースが取得できればＳ１００４に遷移する。取得できなければＳ１００６に遷移する。アプリケーションＡ６０７は、要求したリソースを取得出来たら、取得したリソースを使用する処理を行う（Ｓ１００４）。Ｓ１００４が完了したらアプリケーションＡ用のリソースサービスのＡＰＩ部６０４のリソース解放ＡＰＩを呼び出し（Ｃ１０４１）、不要になったリソースの解放を要求し（Ｓ１００５）、リソース使用処理を終了する（Ｓ１００７）。

【0037】

このフローチャートでは取得したリソースの使用が終わったらすぐに解放しているが、取得したリソースを別の処理でも使用するのであれば別の処理で解放処理をしてもよい。
リソースの解放要求のときにリソースサービスのＡＰＩ部６０４に伝える情報は解放するリソースの種類と解放するリソースの量である。一方アプリケーションＡ６０７は要求したリソースを取得出来なかったらエラー処理（Ｓ１００６）を行い、リソース使用処理を終了する（Ｓ１００７）。

【0038】

アプリケーションＡ用のリソースサービスのＡＰＩ部６０４は、アプリケーションＡ６０７からリソース取得要求（Ｃ１０３８）を受けるとリソース取得処理を開始する（Ｓ１００８）。リソースサービスのＡＰＩ部６０４はリソース管理部６０５を呼び出して（Ｃ１０４２）、リソース要求をおこなう（Ｓ１００９）。このときリソース管理部６０５に伝える情報はＡＰＩが保持しているアプリケーションの識別子３０７とアプリケーションから渡された、取得したいリソースの種類と取得したいリソースの量である。

【0039】

要求に対する応答があればリソースサービスのＡＰＩ部６０４はリソースが取できたかを判断（Ｓ１０１０）し、リソースが取得できればＳ１０１１に遷移する。取得できなければＳ１０１２に遷移する。リソースサービスのＡＰＩ部６０４は要求したリソースを取得出来たらＳ１０１０で取得したリソースをアプリケーションＡに返し（Ｒ１０３９）、リソース取得処理を終了する（Ｓ１０１３）。リソースを取得できなければＳ１０１２でアプリケーションＡに対してエラーを返し（Ｒ１０４０）、リソース取得処理を終了する（Ｓ１０１３）。

【0040】

リソースサービスのＡＰＩ部６０４はアプリケーションＡからリソース解放要求（Ｃ１０４１）がくるとリソース解放処理を開始（Ｓ１０１４）する。ソースサービスのＡＰＩ部６０４はリソース管理部６０５に対してリソース解放要求（Ｃ１０４５）を行う（Ｓ１０１５）。このときリソース管理部６０５に伝える情報はＡＰＩが保持しているアプリケーションの識別子５２６とアプリケーションから渡された、解放するリソースの種類と解放するリソースの量である。次にソースサービスのＡＰＩ部６０４はリソース解放処理を終了する（Ｓ１０１６）。

【0041】

リソース管理部６０５はリソースサービスのＡＰＩ部６０４からリソース要求（Ｃ１０４２）がくるとリソース取得処理を開始する（Ｓ１０１７）。まずリソースサービスのＡＰＩ部６０４のリソース要求からリソースを使用するアプリケーション識別子を取得する（Ｓ１０１８）。次に要求リソースの種類を取得する（Ｓ１０１９）。さらに要求されたリソースの量を取得する（Ｓ１０２０）。次にリソース管理部６０５は、リソース量記憶部６０３からＳ１０１８で取得したアプリケーション識別子で識別されるアプリケーションの、Ｓ１０１９で取得したリソース種類の現在のリソース使用量８０３を取得する（Ｓ１０２１）。さらにリソース管理部６０５は、リソース量記憶部６０３からＳ１０１８で取得したアプリケーション識別子で識別されるアプリケーションの、Ｓ１０１９で取得したリソース種類の宣言リソース量８０２を取得する（Ｓ１０２２）。

【0042】

次にリソース管理部６０５は、Ｓ１０２１で取得したリソース使用量とＳ１０２０で取得した要求リソース量との合計がＳ１０２２で取得した宣言リソース量を超えているかを判定する（Ｓ１０２３）。越えていなければＳ１０２４に遷移する。越えていればエラー処理（Ｓ１０３０）に遷移しリソースサービスのＡＰＩ部にエラーを通知し（Ｒ１０４４）、リソース取得処理を終了する（Ｓ１０２９）。エラーの主旨は要求リソースを確保できない、というものである。

【0043】

Ｓ１０２４ではリソース量記憶部６０３から、Ｓ１０１９で取得したリソース種類の、全アプリケーションによるリソース使用量の合計を取得する（Ｓ１０２４）。次にリソース管理部６０５は、Ｓ１０２４で取得した合計量とＳ１０２０で取得した要求リソース量との合計がアプリケーションプラットフォーム２０５の提供するリソース量を超えているかを判定する（Ｓ１０２５）。アプリケーションプラットフォーム２０５の提供するリソース量は例えば予め与えられ、リソース管理部６０５が保持ししている。越えていたらエラー処理（Ｓ１０３０）に遷移し、リソースサービスのＡＰＩ部にエラーを通知し（Ｒ１０４４）、リソース取得処理を終了する（Ｓ１０２９）。越えていなければＳ１０２６に遷移する。

【0044】

Ｓ１０２６でリソース管理部６０５は、リソース量記憶部６０３のＳ１０１８で取得したアプリケーション識別子で識別されるアプリケーションのＳ１０１９で取得したリソース種類のリソースの使用量８０３に、Ｓ１０２０で取得した要求リソース量を加算する。次にリソース管理部６０５はリソース生成部６０６から要求されたリソースを生成するようアプリケーションプラットフォームに要求する（Ｓ１０２７）。リソースが生成されたらリソース管理部６０５はＳ１０２８でリソースサービスのＡＰＩ部６０４に対して要求されたリソースを返して（Ｒ１０４３）、リソース取得処理を終了する（Ｓ１０２９）。リソースを返すとは、たとえば生成したリソースにアクセスするための情報（パス名等）を返すことである。リソースとは、画像形成装置における処理のために利用可能なハードウェアあるいはソフトウェアの要素を指すが、リソースサービスはそのうちの図５に示したようなリソースを管理対象としている。具体的にはストレージのリソースとしてファイル、通信のリソースとしてソケット、コンピューティングリソースとしてスレッド等である。またリソースオブジェクトとは、アプリケーションプラットフォーム上で実行されるアプリケーション（リソースサーバを含む）からみたリソースの抽象化ということができ、たとえば確保したリソースを示す情報を、リソースに対する処理を示すメソッド等とともにカプセル化したものである。あるいはリソースはリソースオブジェクトによりあらわされるとも言いえる。

【0045】

リソース管理部６０５は、リソースサービスのＡＰＩ部６０４からリソース解放要求（Ｃ１０４５）がくるとリソース解放処理を開始する（Ｓ１０３１）。リソースサービスのＡＰＩ部６０４のリソース解放要求からリソースを使用していたアプリケーションの識別子を取得する（Ｓ１０３２）。次に解放されるリソースの種類を取得する（Ｓ１０３３）。さらに解放されるリソースの量を取得する（Ｓ１０３４）。次にリソース管理部６０５はＳ１０３３で指定されたリソースを解放する（Ｓ１０３５）。リソース管理部６０５は、リソースの解放時にはリソースの要求と同様の要領で、アプリケーションプラットフォームに対して取得済みのリソースの解放を要求する。それにより指定されたリソースが解放される。Ｓ１０３６でリソース管理部６０５はリソース量記憶部６０３のＳ１０３２で取得したアプリケーション識別子で識別されるアプリケーションのＳ１０３３で取得したリソース種類のリソースの使用量８０３からＳ１０３５で取得した要求リソース量を減算する。Ｓ１０３７でリソース管理部６０５はリソース解放処理を終了する。

【0046】

リソースの要求は、たとえばＪａｖａであれば、要求されたリソースオブジェクト（のインスタンス）を生成すればよい。より具体的には、ステップＳ１００２では、必要なリソースのオブジェクトのインスタンスを、リソースサービスのサービスＡＰＩ部を用いて生成させる。リソースオブジェクトのコンストラクタが呼び出されることで、リソース管理部６０５と、アプリケーションプラットフォームあるいはＪａｖａＶＭ等は、図１０Ｂに示したようにリソースオブジェクトを生成する。生成されるリソースオブジェクトは、図５に示すように、Ｊａｖａ標準クラスをラップするよう定義されたオブジェクトである。したがって、得られたリソースの扱いは、通常のＪａｖａにおけるリソースと同様であってよい。たとえば、アプリケーションプラットフォームはリソース生成を要求されると、リソースを確保して確保したリソースを特定するための情報を要求元に返す。もちろんこれは一例である。リソースを特定するための情報がリソース要求のパラメータとして与えられている場合もある。リソースの解放は、たとえば図５のＪａｖａのファイルオブジェクトであればdeleteメソッド、ファイルインプットストリームオブジェクト、ファイルアウトプットストリームオブジェクト、ソケットオブジェクトであればcloseメソッドを呼び出す。スレッドオブジェクトは、特に解放を要求しなくともよい。

【0047】

＜リソースの利用時におけるリソース管理＞
図１１はファイル書き込みの時のアプリケーション、リソースサービス６０１の処理を示したものである。なおファイルへの書き込みは、書き込みの都度リソースを消費する。そのため図１０Ａ、図１０Ｂに示したようなリソース要求時ではなく、書き込み時にリソースの使用量の総計が所定の上限値を超えていないか判定する必要がある。ファイル書き込み時の使用リソース量の判定および更新を図１１の手順で実行する。

【0048】

アプリケーションがファイル書き込み処理を開始する（Ｓ１１０１）。まずアプリケーションはリソースサービスに対してファイルオープン要求を行う（Ｓ１１０２）。ファイルオープン要求Ｃ１１０８を受けたリソースサービス６０１は、アプリケーションのファイルディスクプリタ使用量およびファイルディスクプリタ宣言量からファイルがオープン可能であるかを判定する（Ｓ１１０９）。オープン可能であればアプリケーション６０８にファイルオブジェクトを返す（Ｒ１１１０）。オープン可能でなければアプリケーション６０８にエラーを返す（Ｒ１１１１）。ファイルリソースの取得手順は図１０Ａ、図１０Ｂで説明した通りである。

【0049】

アプリケーションはリソースサービスからファイルオブジェクトが取得できたかを判定し（Ｓ１１０３）、取得できたらＳ１１０４に遷移する。取得できなければＳ１１０８に遷移してエラー処理を行ったのちファイル書き込み処理を終了する（Ｓ１１０７）。ファイルオブジェクトが取得できる場合、アプリケーションはリソースサービス６０１にファイルへのデータ書き込み要求をおこなう（Ｓ１１０４）。アプリケーション６０８からデータ書き込み要求Ｃ１１１２を受けたリソースサービス６０１は、アプリケーションのストレージ使用量とストレージ宣言量からファイル書き込みが可能であるかを判定する（Ｓ１１１３）。ファイル書き込み可能であればファイルへのデータの書き込みをおこないアプリケーションにデータ書き込み成功を返す（Ｒ１１１４）。ファイル書き込み不可能であればアプリケーションにエラーを返し（Ｒ１１１５）。

【0050】

アプリケーションはリソースサービス６０１でファイル書き込みができたかを判定し（Ｓ１１０５）、書き込みができていればＳ１１０６に遷移する。できていなければＳ１１０９に遷移してエラー処理を行ったのちファイル書き込み処理を終了（Ｓ１１０７）する。
アプリケーションは書き込むべきデータすべてを書き込んだかを判定する（Ｓ１１０６）。書き込んでいればＳ１１０７に遷移しファイル書き込み処理を終了する。書き込んでいなければＳ１１０４に遷移して書き込み処理を継続する。図１１の手順で、特にステップＳ１１０４、Ｓ１１１３によりファイル書き込み時にもファイルリソースの使用量がリソース量記憶部６０３に反映される。

【0051】

前述のようにＪａｖａでは、リソースサービスの機能はサービスＡＰＩ部を介して提供され、ＡＰＩ部は例えば図５に示すクラス及びメソッドで特定される。たとえばステップＳ１１０２でファイルリソースを獲得するためには、ResourceServiceクラスのgetFileメソッドを呼び出して、ファイルのリソースオブジェクトすなわちRSFileクラスのインスタンスをリソースサービスに生成させる。これは図１０Ａ、図１０Ｂの手順で示されたとおりである。また、ファイルへのデータ書き込み時には、例えば図５のRSFileOutputStreamクラスのインスタンスをまず生成する。図１１においては、RSFileOutputStreamクラスのインスタンスの生成は、ステップＳ１１０３でＹｅｓと判定された直後に、ステップＳ１１０２で生成したファイルオブジェクトをパラメータとして行われる。これにより生成されるRSFileOutputStreamクラスのオブジェクトは、生成されたファイルオブジェクトの出力ストリームとして関連付けられる。そして、ステップＳ１１０４では、生成したRSFileOutputStreamクラスのオブジェクトのwriteメソッドを呼び出して書き込みを行う。このとき書き込まれるストレージサイズにより、リソース量記憶部６０３を参照して使用量が上限を超えないかをステップＳ１１１３で判定している。上限を超えているか否かの判定は、図１０Ｂと同様に、ファイル書き込みを行うアプリケーション（サービスを利用するアプリケーション）が宣言したストレージ使用量の上限のみならず、全アプリケーションにより使用されているストレージサイズが、画像形成装置１００により提供可能なストレージサイズの上限とも比較される。また書き込みを行う際には、リソース量記憶部６０３のストレージ使用量を更新する。

【0052】

以上のようにして、本実施形態では、リソースの取得時、解放時、またファイルリソースについては書き込み時に、リソース使用量が上限を超えないか、アプリケーションごとにチェックすることができる。さらに、リソースの管理をリソースサービスという、プラットフォーム上で実行される外付けアプリケーションにより行うことができ、リソース管理の容易性および柔軟性を向上させている。さらに、リソースサービスに適合していないアプリケーションであっても、アプリケーションプラットフォームが提供するリソースを従来通り利用することができる。

【0053】

［実施例２］
実施例１のリソースサービス６０１はアプリケーションプラットフォーム２０５上で動作する一アプリケーションであるため、ユーザがＰＣ２０９からアプリケーションプラットフォーム２０５に対してリソースサービス６０１の停止を指示することができる。リソースサービス６０１が停止するとリソースサービスがアプリケーションに対して提供している機能も使用できなくなるため、リソースサービスを使ってリソースの取得・利用を行っているアプリケーションは動作できなくなる。実施例２のリソースサービスはリソースサービスが停止されたときにもアプリケーションの動作は継続できるリソースサービスである。

【0054】

図１２は実施例２のリソースサービスのプログラムを保持するＪａｒファイル１２０１の構造を示している。リソースサービスのＪａｒファイル１２０１はリソースサービスの設定情報を保持するマニフェスト領域１２０２、プログラムコードを保持するプログラムファイル領域１２０３、リソースサービスが使用するデータを保持するデータ領域１２０４から構成される。さらに、リソースサービスのデータ領域１２０４にはデータの一つとしてリソースサービスインターフェースサービス（以後ＲＳＩサービス）のプログラムを保持するＪａｒファイル１２０５が保持されている。ＲＳＩサービスのＪａｒファイル１２０５はＲＳＩサービスの設定を保持するマニフェスト領域１２０６、ＲＳＩサービスのプログラムコードを保持するプログラムファイル領域１２０７から構成される。ＲＳＩサービスはリソースサービスからリソース管理機能を除いたアプリケーションである。

【0055】

図１４は実施例１のリソースサービスと実施例２のＲＳＩサービスの機能の比較を示したものである。リソースサービスもＲＳＩサービスもアプリケーションがリソース取得をおこなうためのＡＰＩを提供するサービスＡＰＩ部をもつ。
リソースサービスはリソース管理機能を持つがＲＳＩサービスは持たない。
リソースサービスもＲＳＩサービスもリソースの生成を行うリソース生成機能を持つ。
ＲＳＩサービスは自身にリソースサービスを登録するリソースサービス登録インターフェースをもつがリソースサービスは持たない。
ＲＳＩサービスはリソース管理機能を持たないためリソースサービスにくらべ非常に小さいプログラムサイズである。
ＲＳＩサービスはリソース管理機能を持たないため使用するメモリ等のリソースもリソースサービスにくらべ非常に小さい。
リソースサービスはアプリケーショプラットフォームによってインストールされる、一方、ＲＳＩサービスはリソースサービスによってインストールされる。
リソースサービスはアプリケーションプラットフォーム２０５によってアンインストールされるが、ＲＳＩサービスはアンインストールされることがない。

【0056】

＜本実施例のリソースサービス起動手順＞
図１３はアプリケーションプラットフォーム２０５によって実施例２のリソースサービスが起動された時および、停止された時のフローチャートである。リソースサービスはプリケーションプラットフォーム２０５から起動指示を受けると起動処理を開始する（Ｓ１３０１）。

【0057】

リソースサービスはアプリケーションプラットフォーム２０５にＲＳＩサービスがインストールされているかを調べる（Ｓ１３０２）。インストールされていなければＳ１３０３に遷移する。インストールされていればＳ１３０６に遷移する。Ｓ１３０３でリソースサービスはリソースサービスのＪａｒファイル１２０１からＲＳＩサービスのＪａｒファイル１２０５を取り出す（Ｓ１３０３）。リソースサービスはＳ１３０３で取りだしたＲＳＩサービスのＪａｒファイル１２０５をアプリケーションプラットフォームにインストールする（Ｓ１３０４）。さらにアプリケーションプラットフォームに対してＲＳＩサービスの起動を指示し（Ｓ１３０５）、Ｓ１３１１に遷移する。

【0058】

Ｓ１３０６でリソースサービスはインストールされているＲＳＩサービスのバージョンを取得する（Ｓ１３０６）。次にリソースサービスのＪａｒファイル１２０１からＲＳＩサービスのＪａｒファイル１２０５を取り出す（Ｓ１３０７）。Ｓ１３０７で取得したＲＳＩサービスのＪａｒファイルのマニフェスト領域１２０６からＲＳＩサービスのバージョンを取得する（Ｓ１３０８）。Ｓ１３０８で取得したＲＳＩサービスのバージョンがＳ１３０６で取得したＲＳＩサービスのバージョンよりも新しければＳ１３１０に遷移し、新しくなければＳ１３１１に遷移する。

【0059】

Ｓ１３１１でリソースサービスはＳ１３０７で取得したＲＳＩサービスのＪａｒファイルを使ってアプリケーションプラットフォーム２０５にインストールしＲＳＩサービスのアップデートをおこない（Ｓ１３１０）、Ｓ１３１１に遷移する。Ｓ１３１１でリソースサービスは自身の初期化処理を実行する（Ｓ１３１１）。次にＲＳＩサービスに対してリソースサービスの登録処理をおこない（Ｓ１３１２）、リソースサービスの起動処理を終了する（Ｓ１３１３）。

【0060】

リソースサービスはプリケーションプラットフォーム２０５から停止指示を受けると停止処理を開始する（Ｓ１３１４）。次にＲＳＩサービスに登録してあるリソースサービスの登録解除処理（Ｓ１３０５）をおこなう。さらにリソースサービス自身の停止処理（Ｓ１３１６）を実行して停止処理を終了する（Ｓ１３１７）。Ｓ１３１４〜Ｓ１３１７のリソースサービス停止処理のなかでＲＳＩサービスの停止処理行わないため、リソースサービスを停止、アンインストールをしてもＲＳＩサービスは停止、アンインストールされない。

【0061】

＜リソースサービスの構成＞
図１５Ａは、本実施例のリソースサービス６０１、ＲＳＩサービス１５０１が起動している時のシステムの構成を示し、図１５Ｂはリソースサービス６０１が停止しＲＳＩ１５０１サービスのみが起動しているときのシステムの構成を示したものである。リソースサービス６０１が起動している場合、ＲＳＩサービスはリソースサービスの起動処理のＳ１３１３で登録されたリソースサービスの参照１５０８を持っている。アプリケーション６０７からＲＳＩサービス１５０１に対するリソース取得、使用要求１５０３はリソースサービスの参照１５０８で識別されるリソースサービス６０１に対して転送され、リソースサービス６０１によりリソースの取得、使用が実行される。リソースサービスによるリソースの管理は、実施例１の図１０Ａ、図１０Ｂ、図１１とおなじ要領で実行される。

【0062】

一方、リソースサービス６０１が起動していない場合はＲＳＩサービス１５０１がリソースの取得、使用をおこなう。これにより、リソースサービス対応アプリケーションは、リソースサービスが稼働中であるか否かにかかわらず同じサービスＡＰＩでリソースの要求および使用を行うことができる。

【0063】

＜リソース取得処理のシーケンス＞
図１６はリソースサービス６０１が起動している時、していない時のリソース取得処理のシーケンスを示したものである。ＲＳＩサービス１５０１は起動時にアプリケーションプラットフォーム２０５のサービスＡＰＩ管理３０２に対して自身をリソースサービスとして登録している。

【0064】

アプリケーション６０７はアプリケーションプラットフォーム２０５を使用してＲＳＩサービス１５０１にサービスＡＰＩ部取得要求を出す（１６０１）。ＲＳＩサービス１５０１はリソースサービスのサービスＡＰＩ部を生成して、アプリケーション６０７にリソースサービスのサービスＡＰＩ部を返す（１６０３）。

【0065】

リソースサービスが起動している場合、アプリケーション６０７はリソースサービスのサービスＡＰＩ部１５０２に対してリソース取得、使用要求をだす（１６０４）。リソースサービスのサービスＡＰＩ部１５０２はステップＳ１６０４で出された要求をＲＳＩサービス１５０１に転送する（１６０５）。

【0066】

ＲＳＩサービス１５０１は１６０５の要求をリソースサービス参照（１５０８）に登録されているリソースサービス６０１に転送する（１６０６）。リソースサービス６０１はリソース管理処理とリソース生成、使用処理をおこない（１６０７）、ＲＳＩサービス１５０１に返す（１６０８）。ＲＳＩサービス１５０１はリソースサービスのサービスＡＰＩ部１５０２に処理を返す（１６０９）。リソースサービスのサービスＡＰＩ部１５０２はアプリケーション６０７に処理を返す（１６１０）。

【0067】

一方リソースサービスが起動していないとリソースサービス参照（１５０８）にはリソースサービスが登録されていない。その場合にも、アプリケーション６０７はリソースサービスのサービスＡＰＩ部１５０２に対してリソース取得、使用要求をだす（１６１１）。リソースサービスのサービスＡＰＩ部１５０２は１６１１の要求をＲＳＩサービス１５０１に転送する（１６１２）。

【0068】

ＲＳＩサービス１５０１はＪａｖａの標準のリソース生成、使用ＡＰＩを使用してリソース生成、使用処理をおこない（１６１３）、リソースサービスのサービスＡＰＩ部１５０２に処理を返す（１６１４）。リソースサービスのサービスＡＰＩ部１５０２はアプリケーション６０７に処理を返す（１６１５）。

【0069】

以上の構成及び手順により、ＲＳＩサービス１５０１はいったん実行されると停止することなく稼働し、リソースサービスが稼働中であれば要求をリソースサービスへとリダイレクトする。このため、ＲＳＩサービスの対応アプリケーションは、リソースサービスが実行中であるか否かにかかわらずＲＳＩサービスのサービスＡＰＩを介してリソースの取得および使用を行うことができる。

【0070】

［実施例３］
実施例２のリソースサービスではリソースサービスが停止していてもリソースサービス対応アプリケーションが実行可能であった。しかし、後からリソースサービスが起動した場合、リソースサービスはリソースサービスが起動するまでにアプリケーションが取得したリソースの管理をすることができなかった。実施例３のリソースサービスのＲＳＩサービスはＲＳＩサービスが起動していてかつ、リソースサービスが起動していないときに使用リソースの計測のみをおこなうＲＳＩサービスである。

【0071】

図１７は実施例３のリソースサービス６０１のＲＳＩサービスがもつリソース使用量を記憶するテーブル１７０１である。アプリケーション識別子１７０２とそのアプリケーションが使用しているリソース量１７０３を記憶している。

【0072】

図１８はリソースサービスのＡＰＩ部１５０２からＲＳＩサービス１５０１に対してリソース要求があった場合の処理を示す図である。ＲＳＩサービス１５０１はリソースサービスのＡＰＩ部１５０２からリソース要求がくるとリソース取得処理を開始する（Ｓ１８０１）。リソースサービスのＡＰＩ部１５０２のリソース要求からリソースを使用するアプリケーションの識別子を取得する（Ｓ１８０２）。次に要求リソースの種類を取得する（Ｓ１８０３）。さらに要求されたリソースの量を取得する（Ｓ１８０４）。次にＲＳＩサービス１５０１はリソース使用量を記憶するテーブル１７０１からＳ１８０２で取得したアプリケーション識別子で識別されるアプリケーションのＳ１８０３で取得したリソース種類のリソースの使用量１７３を取得する（Ｓ１８０５）。さらにテーブル１７０１のＳ１８０２で取得したアプリケーション識別子で識別されるアプリケーションのＳ１８０３で取得したリソース種類のリソースの使用量１７０３にＳ１８０４で取得した要求リソース量を加算、更新する（Ｓ１８０６）。次にＲＳＩサービス１５０１はＪａｖａの標準ＡＰＩを使用してリソースサービスのＡＰＩ部１５０２から要求されたリソースを生成する（Ｓ１８０７）。リソースが生成されたらリにＲＳＩサービス１５０１はＳ１０２８でリソースサービスのＡＰＩ部１５０２に対して要求されたリソースを返して（Ｓ１８０８）リソース取得処理を終了する（Ｓ１８０９）。

【0073】

＜リソースサービス起動処理＞
図１９はＲＳＩサービス１５１０が起動している状態でリソースサービス６０１が起動したとき、ＲＳＩサービス１５０１がおこなうリソースサービス登録処理とリソースサービス６０１のリソース量記憶部６０３の更新処理のフローチャートである。アプリケーションプラットフォーム２０６によってリソースサービス６０１の起動が指示されると、リソースサービス６０１は起動処理（Ｓ１３０１）を開始する。次に初期化処理（Ｓ１９０２）をおこなう。Ｓ１９０２はＳ１３０２〜Ｓ１３１１の処理を含む。次にＲＳＩサービス１５０１のリソースサービス登録要求（Ｃ１９０２）をおこない（Ｓ１３１２）、リソースサービスの起動処理を終了する（Ｓ１３１３）。

【0074】

ＲＳＩサービス１５１０はリソースサービス登録要求（Ｃ１９０２）を受け取るとリソースサービス登録処理とリソース量記憶部６０３の更新処理を開始する（Ｓ１９０３）。まず、リソースサービス６０１の参照を保存する（Ｓ１９０４）。次にＲＳＩサービス１５１０が持っているリソース使用量のテーブル１７０１に登録されているすべてのアプリに対してＳ１９０６〜Ｓ１９１２の処理を繰り返す（Ｓ１９０５）。

【0075】

ＲＳＩサービス１５１０はまずテーブルから一つのレコードを取得しそのレコードのアプリケーション識別子（１７０２）を取得する（Ｓ１９０６）。次にＳ１９０６で取得した識別子のアプリケーションの使用リソース宣言６０８を取得する（Ｓ１９０７）。次にリソースサービス６０１のリソース量記憶部６０３のＳ１９０６で取得した識別子のアプリケーションのレコードの宣言リソース量８０２をＳ１９０７で取得した使用リソース宣言６０８で更新する（Ｓ１９０８）。テーブル１７０１からＳ１９０６で取得した識別子のアプリケーションのリソース使用量１７０３を取得する（Ｓ１９０９）。Ｓ１９０７で取得した使用リソース宣言値６０８とＳ１９０９で取得したリソース使用量１７０３の比較を行う（Ｓ１９１０）。使用量のほうが大きい場合エラー処理（Ｓ１９１２）を行いＳ１９０５に戻る。使用量が宣言量以下の場合、リソースサービスのリソース記憶部のＳ１９０６で取得した識別子のアプリケーションの使用リソース量８０３をＳ１９０９で取得した使用リソース量１７０３で更新（Ｓ１９１１）してＳ１９０５に戻る。

【0076】

エラー処理Ｓ１９１２では該当するアプリケーションを停止してもよいし、余分に使用しているリソースを強制的に解放してもよい。

【0077】

Ｓ１９０５でテーブル１７０１に登録されているすべてのアプリケーションに対して処理が終了したらリソースサービス登録処理とリソース量記憶部６０３の更新処理を終了（Ｓ１９１３）しリソースサービス６０１に処理を返す（Ｒ１９１４）。

【0078】

上記構成及び手順により本実施例では、リソースサービスが稼働していなくともＲＳＩサービスによりアプリケーションごとのリソースの使用量を管理する。さらにリソースサービスが開始あるいは再開された際に、ＲＳＩサービスにより管理されたアプリケーションリソース使用量を、アプリケーションごとに宣言されたリソースの上限値と比較し、上限を超えていないか判定する。さらに、リソース量記憶部６０３を更新することで、リソースサービスが中断していた間のリソースの消費も含めて管理することができる。

【符号の説明】

【0079】

２０４ ＪａｖａＶＭ、２０５ アプリケーションプラットフォーム、６０１ リソースサービス、６０２ アプリ宣言量取得部、６０３ リソース量記憶部、６０４ リソースサービスＡＰＩ部、６０５ リソース管理部、６０６ リソース生成部、６０７ リソースサービス対応アプリ、６０８ 使用リソース宣言、６０９ リソース使用プログラム

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10A】

【図10B】

【図11】

【図12】

【図13】

【図14】

【図15A】

【図15B】

【図16】

【図17】

【図18】

【図19】