JP2006323500A - 管理方法及び管理装置 - Google Patents

Abstract

【課題】 アプリケーション・プログラムのライフサイクル管理を統一的に行うことができ、スキルを持たないオペレータでも操作ミスの起こる確率を低減させる。
【解決手段】 アプリケーション・プログラムのライフサイクルを管理する際に、アプリケーション・プログラムのインストール先が他の管理装置か否かを識別し、識別した結果に応じてアプリケーション・プログラムを自管理装置又は他の管理装置にインストールし、そのインストールしたアプリケーション・プログラムを自管理装置で管理する。
【選択図】 図５

Description

本発明は、アプリケーションを管理する技術に関する。

従来、コンピュータ・システムのサーバ上などでは、アプリケーション・プログラムを実行制御するものとして、フレームワーク、プラットフォーム、アプリケーションサーバもしくはプログラム・コンテナなどと呼ばれるものが多数存在する（ここでは、総称してフレームワークと呼ぶこととする）。

このフレームワークは、フレームワーク上で実行されるアプリケーション・プログラムのインストール、不要になったアプリケーション・プログラムのアンインストール、インストールしたアプリケーション・プログラムの実行、実行中のアプリケーション・プログラムの停止、インストールしたアプリケーション・プログラムの更新、といった実行制御を行う、いわゆる「アプリケーション・プログラムのライフサイクル管理機能」を有している。

また、これらの管理方法や各フレームワーク上にインストールされるアプリケーション・プログラムの形態はフレームワーク毎に異なっている。

代表的なフレームワークの例としては、非特許文献１及び非特許文献２がある。非特許文献１では、ＷＡＲ形式と呼ばれるアプリケーション・プログラムの配布形式があり、このＷＡＲファイルが特定のディレクトリに置かれると、新しいＷＡＲファイルが置かれたと認識し、実行できる形態に自動的に変換することによってインストールを実現している。また、この機構を利用してアプリケーション・プログラムのライフサイクルを管理するアプリケーションがサポートされており、リモートからアプリケーション・プログラムのインストール／アンインストール／起動／停止などが行えるようになっている。

また、非特許文献２では、バンドルと呼ばれるアプリケーション・プログラムの単位が定義されており、このバンドルを形成するバンドル・ファイルの形態も定義されている。これらのバンドルを対象としてライフサイクルの管理機能が提供されている。

一方、いわゆる「組み込み機器」と呼ばれる汎用コンピュータ以外のシステムにおいても、機器のハードウェア資源の高速化、大容量化に伴い、汎用コンピュータで開発された技術を組み込み機器で使用しようとするケースが増えている。
「The Apache Jakarta Tomcat 5.5 Servlet / JSP Container User Guide」Apache Project, 2004年 「OSGi Service Platform Specification Release 2」, OSGi, 2001

汎用のコンピュータ・システムのサーバにおいては、サーバのハードウェア及びソフトウェアの管理を行うオペレータは専門教育を受けており、フレームワーク毎にアプリケーション・プログラムの管理方法が異なっていても、対処し得るだけの技量を持ち合わせていることを仮定しても何ら問題にはならない。

一方、組み込み機器においては、機器を実際に管理するオペレータとして高い専門的なスキルを持つ人が任命されることを期待できない場合が殆どである。

従って、フレームワーク毎にアプリケーション・プログラムの管理方法が異なっている場合、不慣れで専門的な知識が欠如していることに起因する操作ミスなどが起きる確率が高くなることにより、システム全体が機能不全を起こす可能性が高くなるという問題点が存在する。また、たとえ、サーバの管理を行うオペレータといえども、操作ミスがないとは言い切れない。

また、アプリケーション・プログラムのライセンス管理やセキュリティチェックなどは、通常インストール時に行われることが多いため、フレームワーク毎にアプリケーション・プログラムのライフサイクル管理方法の一部であるインストール方式が異なると、複数のライセンス管理やセキュリティチェック機能をシステム内に設ける必要があり、ハードウェア資源の使用効率を下げてしまうという問題点も存在する。

また、フレームワーク毎にリモート管理するためのネットワーク進入口を外部に対して開いておかなければならず、外部からシステムに侵入するための経路が多くなってしまい、セキュリティ上の隘路になる危険性があるという問題点も有する。

本発明は、上記課題を解決するためになされたもので、アプリケーション・プログラムのライフサイクル管理を統一的に行うことができ、スキルを持たないオペレータでも操作ミスの起こる確率を低減させることを目的とする。

本発明は、管理装置にアプリケーションを管理する所定のフレームワークが存在し、前記所定のフレームワークが他のフレームワークのアプリケーションも管理する管理方法であって、アプリケーションのインストール先が前記所定のフレームワークか否かを識別する識別工程と、前記識別工程での識別結果に応じて前記アプリケーションを前記所定のフレームワークか前記他のフレームワークにインストールし、前記アプリケーションのライフサイクルを管理する管理工程とを有することを特徴とする。

また、本発明は、管理装置にアプリケーションを管理する所定のフレームワークが存在し、前記所定のフレームワークが他のフレームワークのアプリケーションも管理する管理装置であって、アプリケーションのインストール先が前記所定のフレームワークか否かを識別する識別手段と、前記識別手段での識別結果に応じて前記アプリケーションを前記所定のフレームワークか前記他のフレームワークにインストールし、前記アプリケーションのライフサイクルを管理する管理手段とを有することを特徴とする。

本発明によれば、アプリケーション・プログラムのライフサイクル管理を統一的に行うことができ、オペレータの操作ミスが起こる確率を低減させることができる。

また、アプリケーション・プログラムのライセンス管理やセキュリティチェックを統合して行えるため、それらにかかるハードウェア資源を節約することができる。

更に、アプリケーション・プログラムをリモート管理するためのネットワーク進入口を一箇所に集約することができ、外部からの進入に対する防御を容易に行える。

更に、アプリケーション同士が連携して処理を行うような分散アプリケーションを統合的に管理できるため、アプリケーション・プログラムの開発においてアプリケーション・プログラム構成の自由度を増すことができる。

以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。

まず、図１を用いて複数のフレームワークが組み込まれた組み込み機器の構成及び動作について説明する。

図１は、一般的な組み込み機器の構成の一例を示す図である。図１において、１００はフレームワークが稼動する組み込み機器（以下、「機器」と略す）である。１０１は機器１００上で稼動するフレームワークとしてのフレームワークＡである。１０２はフレームワークＡ１０１上で管理されるアプリケーションとしてのアプリケーション群Ａである。１１０はフレームワークＡ１０１に対してアプリケーションの管理を指示するためのコンピュータＡである。１２０はコンピュータＡ１１０を経由してフレームワークＡ１０１にインストールされるアプリケーションＡである。

１０３はこの機器１００上で稼動するフレームワークとしてのフレームワークＢである。１０４はフレームワークＢ１０３上で管理されるアプリケーションとしてのアプリケーション群Ｂである。１３０はフレームワークＢ１０３に対してアプリケーションの管理を指示するためのコンピュータＢである。１４０はコンピュータＢ１３０を経由してフレームワークＢ１０３にインストールされるアプリケーションＢである。

これらのアプリケーション・プログラムの管理機能は、ＷＷＷ（World Wide Web）技術を使用してリモート（コンピュータＡ１１０又はコンピュータＢ１３０）から制御可能となっている。即ち、フレームワークが実際に起動されている機器とは異なるコンピュータで稼動するＷｅｂブラウザを使用して、リモートから機器内のフレームワークにアクセスし、フレームワーク上のアプリケーション・プログラムのライフサイクルを管理することができる。

図２は、Ｗｅｂブラウザによりコンピュータ上に表示される管理画面の一例を示す図である。この例は、コンピュータＡ１１０がフレームワークＡ１０１上でアプリケーション・プログラム群Ａ１０２を管理する際に、コンピュータＡ１１０上で稼動しているＷｅｂブラウザにより表示されるアプリケーション・プログラム管理画面である。

この管理画面からコンピュータＡ１１０のユーザが選択ボタン２０１によってアプリケーションが格納されているファイルを選択し、選択ボタン２０２によってライセンス情報を格納しているファイルを指定した後、インストールボタン２０３によってインストールを行うことができる。また、インストール済みのアプリケーション（アプリケーションＡ−２）を選択して起動２０４／終了２０５／更新２０６／アンインストール２０７などの実行制御を指示することができる。

一方、フレームワークＢ１０３は、コンピュータＢ１３０からＦＴＰ（File Transfer Protocol）を使用してフレームワークＢ１０３が設けている特定のディレクトリにアプリケーションＢ１４０を転送することによりアプリケーションのインストールを行う。また、アンインストールはインストールと同様に、ＦＴＰを使用して特定のディレクトリからファイルを削除することによって行う。

このように、同じシステム１００上のフレームワークでも、フレームワークＡ１０１とフレームワークＢ１０３とではアプリケーション・プログラムの管理方法が異なる。

尚、説明の便宜上コンピュータＡ１１０とコンピュータＢ１３０は別々のコンピュータになっているが、同じコンピュータで行っても良い。

［第１の実施形態］
次に、複数のフレームワークが稼働する機器においてアプリケーション・プログラムのライフサイクルを統一的に管理する方法について説明する。

図３は、第１の実施形態における組み込み機器の構成の一例を示す図である。尚、本発明は、組み込み機器に限定されるものではなく、他のネットワーク機器にも適用可能である。図３において、３０１は機器全体を制御する制御部である。３０２はデータや制御部３０１で実行されるソフトウェアを一時的に記憶しておくためのＲＡＭなどで構成される１次記憶部である。３０３はデータや制御部３０１で実行されるソフトウェアを恒久的に記憶しておくためのハードディスクなどで構成される２次記憶部である。３０４はユーザの指示や文字データや画像データを入力するためキーボード、マウス、タッチスクリーン、スキャナなどで構成される入力部である。３０５はオペレータへの指示やデータの内容を表示するためのディスプレーなどで構成される表示部である。３０６は他の機器と通信を行うためのＬＡＮなどで構成されるネットワーク部である。そして、３０７は各部を結合するためのバスである。

図４は、制御部３０１で実行されるソフトウェアの構成を階層的に示す図である。図４において、４０１はソフトウェアやハードウェア資源を管理するためのオペレーティングシステム（ＯＳ）である。４０２はアプリケーションの実行環境となるフレームワークのうち、オペレータからの指示を代表して受けるファサード（Facade）・フレームワークである。４０３はファサード・フレームワーク４０２上で実行されるファサード・フレームワークアプリケーション群である。

４０４はファサード・フレームワーク４０２を介してオペレータの指示を受けるフレームワークとしてのターゲット・フレームワークＡである。４０５はターゲット・フレームワークＡ４０４上で実行されるターゲット・フレームワークＡアプリケーション群である。４０６はターゲット・フレームワークＡ４０４と同様に、ファサード・フレームワーク４０２を介してオペレータの指示を受けるターゲット・フレームワークＢである。４０７はターゲット・フレームワークＢ４０６上で実行されるターゲット・フレームワークＢアプリケーション群である。４０８はオペレーティングシステム４０１上で稼動するその他のアプリケーション群である。

尚、ファサード・フレームワーク４０２、ターゲット・フレームワークＡ４０４とターゲット・フレームワークＢ４０６は、オペレーティングシステム４０１からは、その他のアプリケーション群４０８に属するアプリケーションと全く同等に扱われる。

第１の実施形態では、ファサード・フレームワーク４０２はOSGi Service Platform（以下、OSGiと略す）を拡張したものであるとして説明する。

また、ファサード・フレームワーク４０２は、Java言語（Javaは米国Sun Microsystems Inc. の登録商標である）によって構築され、各アプリケーションはバンドルと呼ばれ、アーカイブ・ファイル形式であるＪａｒ（Java ARchive）ファイルによって提供される。また、アプリケーションの一部の機能を他のアプリケーションに提供するためのサービス登録・検索・使用機能を有している。

これにより、特定のインタフェースを持ったサービスを検索し、利用することが可能となる。また、サービスの登録では、登録するサービスを規定する属性を合わせて登録することが可能で、その属性によって特定の属性値を持つサービスを検索して取得することができるように構成されている。尚、OSGiの詳細は非特許文献２に記載されており、ここでの説明は省略する。

図５は、ファサード・フレームワーク４０２とターゲット・フレームワークＡ４０４の関係を模式的に表した図である。図５において、５００は第１の実施形態における機器であり、図３に示す各部から構成されている。５１０はネットワーク部３０６を介して機器５００と接続されているコンピュータである。５２０はコンピュータ５１０の記憶装置に記憶され、ファサード・フレームワーク４０２を経由してターゲット・フレームワークＡ４０４にインストールされるターゲット・アプリケーションからなるアプリケーション・ファイルである。５３０はアプリケーション・ファイル５２０内に含まれ、ターゲット・フレームワークＡ４０４上で稼動するターゲット・アプリケーションである。

尚、ファサード・フレームワーク４０２とターゲット・フレームワーク４０４、４０６の夫々が異なる装置に備えられ、ある装置に備えられたファサード・フレームワーク４０２が、他の装置に備えられたターゲット・フレームワーク４０４又は４０６へターゲット・アプリケーションをインストールする場合にも、本発明は、適用可能である。

ここで、図６を用いて、第１の実施形態におけるアプリケーション・ファイル５２０の構造について説明する。

図６は、第１の実施形態におけるアプリケーション・ファイル５２０の構造の一例を示す図である。図６に示すように、アプリケーション・ファイル５２０は、ヘッダ部６０１とデータ格納部６０２とで構成されている。

ヘッダ部６０１は、アプリケーション・ファイルであることを示すマジック・ナンバー６１１と、ヘッダ部６０１の大きさを表すヘッダ部サイズ６１２と、アプリケーション・プログラムの各種属性を記述しているプログラム属性記述部６１３とで構成されている。ここで、プログラム属性記述部６１３は、図７に示すように、プログラム属性を表現するＪａｒファイルのマニフェストヘッダ形式により構成される。また、マニフェストヘッダでは、属性の名前とその値のペアとして属性値が記述される。

一方、データ格納部６０２はファサード・フレームワーク４０２が管理している秘密鍵によってのみ復号化されるように暗号化されている。そして、データ格納部６０２を復号化すると、ターゲット・フレームワークＡ４０４上で実行されるときに必要な属性を記述しているターゲット・フレームワーク用アプリケーション・ヘッダ部６２１とターゲット・フレームワーク上で実行するプログラム・データを格納しているプログラム・データ・アーカイブ部６２２とに分かれている。

図５に戻り、５４０はファサード・フレームワーク４０２上で実行されるファサード・フレームワークアプリケーション群４０３に属し、ターゲット・フレームワークＡ４０４に対してアプリケーションのライフサイクル管理を行うアプリケーション・マネージャＡである。また、５５０はファサード・フレームワーク４０２上で実行されるファサード・フレームワークアプリケーション群４０３に属し、ターゲット・フレームワークＢ４０６に対してアプリケーションのライフサイクル管理を行うアプリケーション・マネージャＢである。即ち、ターゲット・フレームワーク毎にアプリケーションのライフサイクル管理を行うアプリケーション・マネージャが存在する。

次に、図８を用いて、コンピュータ５１０のオペレータがターゲット・フレームワークＡ４０４にアプリケーション・ファイル５２０をインストールする際の処理について説明する。尚、アプリケーション・ファイル５２０と共にオペレータからはライセンス情報も同時に指定されているものとする。また、第１の実施形態で使用されるＷｅｂブラウザ上のユーザインタフェースは図２に示す管理画面と同じものが使われるものとする。

図８は、第１の実施形態におけるインストール処理を示すフローチャートである。まず、ステップＳ８０１において、コンピュータ５１０のオペレータがＷｅｂブラウザにより表示された機器５００におけるファサード・フレームワーク４０２の管理用ユーザインタフェースを介してファサード・フレームワーク４０２にアクセスし、アプリケーション・ファイル５２０をインストールするように指示する。

オペレータの指示によってアプリケーション・ファイル５２０を受け取ったファサード・フレームワーク４０２は、そのアプリケーション・ファイル５２０のヘッダ部６０１のプログラム属性記述部６１３に記述されているマニフェストヘッダを解析し、アプリケーション・ファイル５２０のプログラム・データ・アーカイブ部６２２に格納されているプログラムを実行すべきフレームワークを取得する。

尚、ターゲットとなるフレームワークは、図７に示すように、ターゲット（target:）属性として記述されている。ここで、ターゲット属性が設定されていない場合、もしくはファサード・フレームワーク４０２が指定されている場合はファサード・フレームワーク４０２がターゲット・フレームワークとして認識される。ここでは、ターゲットとして、“Tomcat 5.5”が指定されており、ターゲットフレームワークＡ４０４を認識する。

次に、ステップＳ８０２において、ステップＳ８０１で取得したアプリケーション・ファイル５２０を実行するターゲット・フレームワークがファサード・フレームワーク４０２であるか否かを認識する。ここで、ターゲット・フレームワークがファサード・フレームワーク４０２である場合はステップＳ８０３へ進む。

このステップＳ８０３では、オペレータが指定し、コンピュータ５１０からファサード・フレームワーク４０２に送られてきたアプリケーション・ファイル５２０をファサード・フレームワーク４０２用のアプリケーションとしてインストールする。

このインストールの際に、アプリケーション・ファイル５２０のデータ格納部６０２に格納されているデータを秘密鍵によって復号化する。復号化されたデータは、ファサード・フレームワーク４０２用のアプリケーションであると仮定して、ファサード・フレームワーク４０２へのインストール処理を行う。

また、復号化されたデータがファサード・フレームワーク４０２のアプリケーションのフォーマットに則しているか否かを調べる処理は、ファサード・フレームワーク４０２の機能によって行う。更に、オペレータによって指定されたライセンス情報は、ファサード・フレームワーク４０２へのライセンス情報として設定される。

一方、ステップＳ８０２で、ファサード・フレームワーク４０２以外のフレームワークがターゲットであると認識した場合はステップＳ８０４へ進み、認識されたターゲット・フレームワーク用のアプリケーション・マネージャが存在するか否かを検索する。尚、ファサード・フレームワーク４０２とターゲット・フレームワークは異なる装置に備えられていても良い。

アプリケーション・マネージャは、図９に示すインタフェース（ApplicationManger）によるサービスを提供するものとして登録されている。また、アプリケーション・マネージャの属性として、対象としているフレームワークの識別子が“TargetFramework”属性として登録されている。

この例では、ターゲット・フレームワークが“Tomcat 5.5”であるとステップＳ８０１で認識されているので、ファサード・フレームワーク４０２本体が提供している、searchメソッドに、ApplicationManagerインタフェースの名前と属性値の検索式とをLDAP形式で以下のように指定すれば、“Tomcat 5.5”用のアプリケーション・マネージャを取得することができる。

ApplicationManager am = (ApplicationManager) framework_body.search( "com.canon.upd.ApplicationManager", "(TargetFramework=Tomcat 5.5)");
また、“Tomcat 5.5”用のアプリケーション・マネージャが登録されていない場合は、ヌル（null）が返されて登録されていないことを認識できるようになっている。

即ち、ターゲット・フレームワークＡ４０４が“Tomcat 5.5”であるとすると、上記の検索によってターゲット・フレームワークＡ４０４用のアプリケーション・マネージャを取得することができる。

ここで、ターゲット・フレームワーク用のアプリケーション・マネージャが取得できた場合はステップＳ８０６へ進み、取得できずヌル（null）が返ってきた場合はステップＳ８０５へ進む。

このステップＳ８０５では、アプリケーションのインストール先として指定されたターゲット・フレームワークに対応するアプリケーション・マネージャが登録されていないことを示すアラートページをコンピュータ５１０上のＷｅｂブラウザに表示することにより、オペレータにインストールに失敗したことを通知する。

また、ステップＳ８０４で、アプリケーションのインストール先として指定されたターゲット・フレームワークに対応するアプリケーション・マネージャが取得できた場合は、ターゲット・フレームワークＡ４０４用のアプリケーション・マネージャとしてのアプリケーション・マネージャＡ４０４が返されている。

そこで、アプリケーション・マネージャが存在する場合にはステップＳ８０６へ進み、アプリケーション・ファイル５２０からデータ格納部６０２を取り出し、秘密鍵によって復号化する。次に、復号化されたターゲット・アプリケーション５３０を入力ストリームとして開き、その引数としてアプリケーション・マネージャＡ５４０のinstallメソッドを呼び出し、ターゲット・フレームワークＡ４０４にインストールする。

この場合、ターゲット・フレームワークＡ４０４がTomcatであるため、入力ストリームによって渡されたデータをＷＡＲファイルとして特定のディレクトリに置くことによってインストール処理が行われる。

このターゲット・フレームワークＡ４０４へのインストールが終了すると、ターゲット・フレームワークＡ４０４上のターゲット・フレームワークＡアプリケーション群４０５内でインストールされたアプリケーションを一意に認識するためのアプリケーション識別子を含む図９に示すApplicationインタフェースを実装したオブジェクトが返される。

アプリケーション識別子はApplicationインタフェースのgetApplicationIDメソッドを呼び出すことによって取得できる。

また、オペレータによって指定されたライセンス情報は、アプリケーション・マネージャＡ５４０によってターゲット・フレームワークＡ４０４に通知され、ターゲット・フレームワークＡ４０４で使用される。

ファサード・フレームワーク４０２の本体に対して、取得したApplicaitonオブジェクトと、ターゲット・フレームワークの識別子（この例では“Tomcat 5.5”と言う文字列）を引数として拡張されたメソッドであるmakeBundleメソッドを呼び出すと、ファサード・フレームワーク４０２上にターゲット・フレームワークＡ４０４上にインストールされたアプリケーションを識別するための仮想的なアプリケーションが生成される。

以後のターゲット・フレームワークＡ４０４にインストールされたアプリケーションのライフサイクルの管理を、この仮想アプリケーションを対象とすることにより、あたかもファサード・フレームワーク４０２上のアプリケーションの管理を行っているかのように実行制御することができる。

上述したように、ターゲット・フレームワークＡ４０４へのアプリケーションのインストールが、オペレータから見ればファサード・フレームワーク４０２へのインストールであるかのように見せることができる。

次に、インストール以外の処理について説明する。インストール以外の各処理は大筋では同じであり、ここでは図１０を用いて、代表例として稼動しているアプリケーションを停止する処理について説明する。

図１０は、第１の実施形態におけるアプリケーションの停止処理を示すフローチャートである。上述したインストール処理と同様に、オペレータがコンピュータ５１０からファサード・フレームワーク４０２にアクセスし、Ｗｅｂブラウザ上にファサード・フレームワーク４０２のアプリケーション群４０３の管理画面を表示させる。そして、オペレータが表示された管理画面からアプリケーションを選択し、停止処理を行うことを指示するとステップＳ１００１へ進み、選択されたファサード・フレームワーク・アプリケーション群４０３内のアプリケーションが、ファサード・フレームワーク４０２自身のアプリケーションであるか、ターゲット・フレームワーク上のアプリケーションの仮想アプリケーションであるかを識別する。この識別処理は、図１１に示すアプリケーション属性オブジェクトに基づいて行う処理である。尚、ファサード・フレームワーク４０２とターゲット・フレームワークは異なる装置に備えられていても良い。

図１１は、ファサード・フレームワーク４０２で管理されるアプリケーション群４０３のアプリケーション属性オブジェクトの構成を示す図である。図１１に示すように、アプリケーション属性オブジェクトは、アプリケーションの実体が実行されるフレームワークを示すフレームワーク識別子１１０１、Applicationインタフェースのオブジェクトとして定義されアプリケーションを示すアプリケーション識別子１１０２、アプリケーションのライフサイクル上の状態を表すステータス１１０３、アプリケーションが実際に格納された場所をＵＲＬ情報として表す格納先１１０４、その他の属性１１０５を含む。また、ターゲット・フレームワーク上のアプリケーションに対する属性値は、アプリケーションがインストールされたとき（ステップＳ８０６）、取得したApplicationオブジェクトから各々取得して設定される。

尚、フレームワーク識別子１１０１が設定されていれば、指定されたアプリケーションは設定されている識別子を持つターゲット・フレームワーク上のアプリケーションであることを示し、設定されていなければ、ファサード・フレームワーク４０２上のアプリケーションであることを示す。

ステップＳ１００１でファサード・フレームワーク４０２上のアプリケーションである場合はステップＳ１００２へ、そうでない場合はステップＳ１００３へ進む。

このステップＳ１００２では、ファサード・フレームワーク４０２上で実際に稼動しているアプリケーションであるので、ファサード・フレームワーク４０２が元々備えているアプリケーション管理におけるアプリケーション停止処理を行う。

また、ステップＳ１００３では、アプリケーション属性オブジェクトのフレームワーク識別子１１０１によって選択されたアプリケーションが実際に稼動しているターゲット・フレームワークに対応するアプリケーション・マネージャを取得する。ここでの取得方法はステップＳ８０４で説明した通りである。

次に、ステップＳ１００４において、アプリケーション・マネージャを取得できたか否かを判定し、アプリケーション・マネージャを取得できた場合はステップＳ１００５へ、取得できない場合は、例外を発生して処理を終了する。

このステップＳ１００５では、ステップＳ１００３で取得したアプリケーション・マネージャに対してアプリケーション属性オブジェクトのアプリケーション識別子１１０２に格納されているアプリケーション識別子を引数として指定して、stopメソッドを呼び出すことにより、ターゲット・フレームワーク上で稼動している指定されたアプリケーションを停止する。

また同時に、ファサード・フレームワーク４０２上の仮想アプリケーションも停止状態になるようにステップＳ１００２へ進む。

以上のようにして、ターゲット・フレームワーク上のアプリケーションに関するライフサイクルの管理であっても、ファサード・フレームワーク４０２上のアプリケーションを管理しているかのようにオペレータに見せることができる。

尚、ファサード・フレームワーク４０２上のアプリケーションのアプリケーション属性オブジェクトは生成されると同時に、２次記憶部３０３に記憶され、その後、機器５００が起動されたときには２次記憶部３０３から読み込まれて復元されるものとする。

従って、一度ファサード・フレームワーク４０２を経由してインストールされたアプリケーションの情報は機器５００が起動される度に以前に機器５００が停止したときの状態で復元される。

このとき、ファサード・フレームワーク４０２の起動シーケンスにおいて、ファサード・フレームワーク４０２上の仮想アプリケーションに対して復元処理を行う場合は、以下の処理を行う。

仮想アプリケーションのアプリケーション属性オブジェクトで記憶されているアプリケーションの状態と、各ターゲット・フレームワーク上のアプリケーションの状態が異なる場合、ファサード・フレームワーク４０２上の仮想アプリケーションの状態と合うように対応するアプリケーション・マネージャを経由してターゲット・フレームワーク上のアプリケーションの状態を変更する。

例えば、ファサード・フレームワーク４０２上では起動状態であるように記憶されているにもかかわらず、ターゲット・フレームワーク上では起動していないような場合、アプリケーション・マネージャのstartメソッドにより起動状態に変更する。

［第２の実施形態］
次に、図面を参照しながら本発明に係る第２の実施形態について詳細に説明する。尚、第２の実施形態における機器及びソフトウェアの構成は、第１の実施形態と同様であり、その説明は省略する。また、ファサード・フレームワークとターゲット・フレームワークは異なる装置に備えられていても良い。

第２の実施形態で第１の実施形態と異なるのは、機器５００が起動されたときのファサード・フレームワーク４０２とアプリケーション・マネージャの処理である。

機器５００が起動され、それに伴いファサード・フレームワーク４０２が起動されると、ファサード・フレームワーク・アプリケーション群４０３の初期化を行う。その際に、仮想アプリケーションであるアプリケーション属性オブジェクトのフレームワーク識別子が設定されている場合は（ステップＳ１００１のＹＥＳ）、アプリケーションの再構成を行わずファサード・フレームワーク４０２上のアプリケーションとして再生しない。

また、この時点で再生しないのではなく、仮想アプリケーションの場合、２次記憶部３０３へのアプリケーション属性オブジェクトの格納を行わないことでも同様の効果が得られる。

一方、アプリケーション・マネージャがファサード・フレームワーク４０２によって起動される時に、アプリケーション・マネージャの管理対象となっているターゲット・フレームワークに問い合わせ、ターゲット・フレームワーク上で稼動しているアプリケーションのアプリケーション識別子のリストを取得する。

取得したリスト上のアプリケーション識別子を使用して、仮想アプリケーションをファサード・フレームワーク４０２上で生成する。この際の処理は第１の実施形態のステップＳ８０６に記述されているものと同じである。

このようにして、ターゲット・フレームワーク上のアプリケーション管理をファサード・フレームワーク４０２のアプリケーションを管理しているかのように行うことができる。

［第３の実施形態］
次に、図面を参照しながら本発明に係る第３の実施形態について詳細に説明する。尚、第３の実施形態における機器及びソフトウェアの構成は、第１の実施形態と同様であり、その説明は省略する。また、ファサード・フレームワークとターゲット・フレームワークは異なる装置に備えられていても良い。

第３の実施形態で使用するアプリケーション・ファイルの形式を図１２に示す。図１２に示すように、アプリケーション・ファイルは、ファサード・フレームワーク４０２を含む複数のターゲット・フレームワーク上で稼動するアプリケーションを一つのファイルにまとめたものになっている。アプリケーション・ファイルは、ヘッダ部１２０１とデータ格納部１２０２とで構成されている。ヘッダ部１２０１は、アプリケーション・ファイルであることを示すマジック・ナンバー１２１１、ヘッダ部の大きさを表すヘッダ部サイズ１２１２、アプリケーション・プログラムの各種属性を記述しているプログラム属性記述部１２１３とで構成されている。尚、プログラム属性記述部１２１３は、プログラム属性を表現する、図１３に示すようなＸＭＬデータにより構成される。

更に、データ格納部１２０２はファサード・フレームワーク４０２が管理している秘密鍵によってのみ復号化されるように暗号化されている。データ格納部１２０２を復号化すると、各ターゲット・フレームワーク用のアプリケーションであるプログラム片１２２０の列として構成されている。各プログラム片１２２０は、プログラム片１２２０のサイズ１２２１、プログラム片識別子１２２２、対象となるターゲット・フレームワークで実行されるときに必要な属性を記述しているターゲット・フレームワーク用アプリケーション・ヘッダ部１２２３、ターゲット・フレームワーク上で実行するプログラム・データを格納しているプログラム・データ・アーカイブ部１２２４から構成されている。

ここで、図１４を用いて第３の実施形態においてアプリケーションをインストールする際の処理について説明する。第３の実施形態では、ファサード・フレームワーク４０２上のアプリケーションは図１５に示すApplicationAttributeオブジェクトを属性として持つものとする。

図１４は、第３の実施形態におけるインストール処理を示すフローチャートである。まず、ステップＳ１４０１において、第１の実施形態と同様に、オペレータの指示によってアプリケーション・ファイル５２０を受け取ったファサード・フレームワーク４０２は、そのアプリケーション・ファイル５２０のヘッダ部１２０１のプログラム属性記述部１２１３に記述されているＸＭＬ文書を解析する。同時に、データ格納部１２０２の復号化を行う。

各プログラム片１２２０の情報は、図１３に示すプログラム属性記述例のように、portionタグによって記述されている。プログラム片１２２０のプログラム・データ・アーカイブ部１２２４に格納されているアプリケーション・プログラムを実行すべきターゲット・フレームワークはportionタグのtarget属性として記述されている。また、target属性が設定されていない場合或いはファサード・フレームワーク４０２が指定されている場合は、ファサード・フレームワーク４０２をターゲット・フレームワークとして認識する。potionタグのid属性としてプログラム片１２２０の識別子が指定され、プログラム片識別子１２２２と比較することにより、ターゲット・フレームワークに対応するプログラム片１２２０を特定する。ここで、全てのプログラム片情報はプログラム片リストとして登録する。

次に、ステップＳ１４０２において、ステップＳ１４０１で作成したプログラム片リストを用いて各プログラム片の処理を行う。未処理のプログラム片をリストから抽出し、未処理のプログラム片があればステップＳ１４０３へ進み、プログラム片情報リストから取得したプログラム片情報からターゲット・フレームワーク情報を取得する。そして、ステップＳ１４０４において、ステップＳ１４０３で取得したターゲット・フレームワーク情報が設定されていないか、即ち、ファサード・フレームワーク４０２がターゲットか否かを判定する。ここで、ファサード・フレームワーク４０２がターゲットであればステップＳ１４０５へ進み、対象となるプログラム片のプログラム・データ・アーカイブ部１２２４に格納されているプログラムをファサード・フレームワーク４０２用のアプリケーションとしてインストールする。このとき、インストールされたアプリケーションのアプリケーション属性を管理するものとしてApplicationAttributeオブジェクトが生成される。

また、ファサード・フレームワーク４０２がターゲットでなければステップＳ１４０６へ進み、第１の実施形態におけるインストール処理のステップＳ８０４と同様に処理を行い、対象となるターゲット・フレームワーク用のアプリケーション・マネージャを取得する。アプリケーション・マネージャの取得に必要な情報はプログラム片情報から取得する。尚、ファサード・フレームワーク４０２とターゲット・フレームワークは異なる装置に備えられていても良い。

ここで、アプリケーション・マネージャが取得できず、ヌルが返ってきた場合はステップＳ１４０７へ進み、アプリケーションのインストール先として指定されたターゲット・フレームワークに対応するアプリケーション・マネージャが登録されていないことを示すアラートパネルをコンピュータ５１０上のＷｅｂブラウザに表示することにより、オペレータにインストールに失敗したことを通知して処理を終了する。

また、アプリケーション・マネージャが取得できた場合はステップＳ１４０８へ進み、プログラム片のプログラム・データ・アーカイブ部１２２４のデータを入力ストリームとして開き、引数としてアプリケーション・マネージャのinstallメソッドを呼び出して、ターゲット・フレームワークへのインストールを行う。ターゲット・フレームワークへのインストールが終了すると、ターゲット・フレームワークにインストールされたアプリケーションを一意に認識するためのアプリケーション識別子を含む図９に示すApplicationインタフェースを実装したオブジェクトが返される。アプリケーション識別子はApplicationインタフェースのgetApplicationIDメソッドを呼び出すことによって取得できる。

アプリケーションリスト（JavaのVectorオブジェクトとして生成する）が生成されていない場合は生成する。ターゲット・フレームワークへインストールした結果として返されたApplicationオブジェクトをアプリケーションリストに登録する。

一方、ステップＳ１４０２において、プログラム片が残っていない場合にはステップＳ１４０９へ進み、ステップＳ１４０５にてファサード・フレームワーク４０２上のアプリケーションがインストールされていればステップＳ１４１１へ、インストールされていなければステップＳ１４１０へ進む。

このステップＳ１４１０では、ファサード・フレームワーク４０２上に仮想アプリケーションを生成し、アプリケーション情報オブジェクトを生成する。このとき、アプリケーション属性を管理するものとしてApplicationAttributeオブジェクトが生成される。

次に、ステップＳ１４１１において、ステップＳ１４０５でファサード・フレームワーク４０２にアプリケーションをインストールした際に生成されたApplicationAttributeオブジェクト又はステップＳ１４１０にて仮想アプリケーションと共に生成されたApplicationAttributeオブジェクトにステップＳ１４０８にてターゲット・フレームワークにインストールしたアプリケーションの情報を登録してあるアプリケーションリストをframeworkListフィールドに設定する。

このようにして、複数のターゲット・フレームワークに向けたアプリケーションを内包したアプリケーション・ファイル５２０が指定された場合、各々のターゲット・フレームワークへのインストールを完了すると共に、それらの代表としてファサード・フレームワーク上にアプリケーション情報オブジェクトを生成する。

尚、第３の実施形態では、１つのアプリケーション・ファイル５２０内に格納されているプログラム片は関係があるものとして管理しているが、全く関係ないものとして各アプリケーション片に対して仮想アプリケーションを生成して別のものとして管理することもできる。

次に、インストール以外の処理について説明する。インストール以外の各処理は大筋では同じであり、ここでは図１６を用いて、代表例として停止処理について説明する。

図１６は、第３の実施形態におけるアプリケーションの停止処理を示すフローチャートである。上述したインストール処理と同様に、オペレータがコンピュータ５１０からファサード・フレームワーク４０２にアクセスし、Ｗｅｂブラウザ上にファサード・フレームワーク４０２のアプリケーション群４０３の管理画面を表示させる。そして、オペレータは表示された管理画面でアプリケーションを選択し、停止処理を行なうことを指示するとステップＳ１６０１へ進み、指定されたファサード・フレームワーク・アプリケーション群４０３内のアプリケーションからApplicationAttrribtueを取り出し、そのApplicationAttributeオブジェクトのframeworkListを取得し、VectorオブジェクトからFrameworkProgramオブジェクトを取り出す。

ここで、FrmeworkProgramオブジェクトを全て取り出し済みの場合はステップＳ１６０２へ進み、ファサード・フレームワーク４０２が元々備えているアプリケーション管理におけるアプリケーション停止処理を行う。

また、FrmeworkProgramオブジェクトを全て取り出していない場合はステップＳ１６０３へ進み、ステップＳ１６０１で取り出されたFrmeworkProgramオブジェクトからターゲット・フレームワーク識別子であるframeworkIdフィールドの値を取得し、それによって選択されたターゲット・フレームワークに対応するアプリケーション・マネージャを取得する。この取得方法は第１の実施形態と同様であり、その説明は省略する。尚、ファサード・フレームワーク４０２とターゲット・フレームワークは異なる装置に備えられていても良い。

次に、ステップＳ１６０４において、アプリケーション・マネージャを取得することができたか否かを判定し、取得できなかった場合は、例外を発生して処理を終了する。また、取得できた場合はステップＳ１６０５へ進み、ステップＳ１６０３で取得したアプリケーション・マネージャに対してFrmaeworkProgramオブジェクトのapplicationIdフィールドに格納されているアプリケーション識別子を引数として指定してstopメソッドを呼び出し、ターゲット・フレームワーク上で稼動している指定されたアプリケーションを停止させる。

以上のように、１つのアプリケーション・ファイル５２０に格納されている異なるフレームワーク上のアプリケーションもファサード・フレームワーク４０２上で行われるアプリケーションのライフサイクル管理に連動してライフサイクルの管理を行うことが可能となる。

また、上述の実施形態では、１つのアプリケーション・ファイル５２０に格納されていることが連携するための条件となっているが、別々にインストールされたアプリケーションをインストール後にグルーピングしてファサード・フレームワーク４０２上のアプリケーションに集約して同様の効果を得るように構成することも可能である。

尚、本発明は複数の機器（例えば、ホストコンピュータ，インタフェース機器，リーダ，プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用しても良い。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。

この場合、記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

このプログラムコードを供給するための記録媒体としては、例えばフロッピー（登録商標）ディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

更に、記録媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

一般的な組み込み機器の構成の一例を示す図である。 Ｗｅｂブラウザによりコンピュータ上に表示される管理画面の一例を示す図である。 第１の実施形態における組み込み機器の構成の一例を示す図である。 制御部３０１で実行されるソフトウェアの構成を階層的に示す図である。 ファサード・フレームワーク４０２とターゲット・フレームワークＡ４０４の関係を模式的に表した図である。 第１の実施形態におけるアプリケーション・ファイル５２０の構造の一例を示す図である。 第１の実施形態におけるプログラム属性の記述例を示す図である。 第１の実施形態におけるインストール処理を示すフローチャートである。 第１の実施形態におけるインタフェースの一例を示す図である。 第１の実施形態におけるアプリケーションの停止処理を示すフローチャートである。 ファサード・フレームワーク４０２で管理されるアプリケーション群４０３のアプリケーション属性オブジェクトの構成を示す図である。 第３の実施形態で使用するアプリケーション・ファイルの形式を示す図である。 第３の実施形態におけるプログラム属性の記述例を示す図である。 第３の実施形態におけるインストール処理を示すフローチャートである。 第３の実施形態におけるApplicationAttributeオブジェクトの一例を示す図である。 第３の実施形態におけるアプリケーションの停止処理を示すフローチャートである。

Claims (9)

1. 管理装置にアプリケーションを管理する所定のフレームワークが存在し、前記所定のフレームワークが他のフレームワークのアプリケーションも管理する管理方法であって、
   アプリケーションのインストール先が前記所定のフレームワークか否かを識別する識別工程と、
   前記識別工程での識別結果に応じて前記アプリケーションを前記所定のフレームワークか前記他のフレームワークにインストールし、前記アプリケーションのライフサイクルを管理する管理工程とを有することを特徴とする管理方法。
2. 前記管理工程は、前記アプリケーションのインストール先にかかわらず、該アプリケーションのライフサイクルを同等に管理することを特徴とする請求項１記載の管理方法。
3. 前記管理工程は、前記アプリケーションのインストール先が前記他のフレームワークの場合、前記アプリケーションの仮想アプリケーションを生成し、該仮想アプリケーションを管理することを特徴とする請求項１記載の管理方法。
4. 前記インストールでは、インストール時に暗号化されているアプリケーションを復号化することを特徴とする請求項１記載の管理方法。
5. 前記インストールでは、ライセンス情報を併せてインストールし、
   前記管理装置は、前記ライセンス情報に基づいて前記アプリケーションを実行制御することを特徴とする請求項１記載の管理方法。
6. 前記管理工程は、別々のフレームワークで稼動する複数のアプリケーションをグループ化して管理することを特徴とする請求項２記載の管理方法。
7. 管理装置にアプリケーションを管理する所定のフレームワークが存在し、前記所定のフレームワークが他のフレームワークのアプリケーションも管理する管理装置であって、
   アプリケーションのインストール先が前記所定のフレームワークか否かを識別する識別手段と、
   前記識別手段での識別結果に応じて前記アプリケーションを前記所定のフレームワークか前記他のフレームワークにインストールし、前記アプリケーションのライフサイクルを管理する管理手段とを有することを特徴とする管理装置。
8. 請求項１記載の管理方法をコンピュータに実行させるためのプログラム。
9. 請求項８記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images