JP3986721B2 - ソフトウェア・モジュール動的交換方法及びソフトウェア・モジュール動的交換プログラム記録媒体 - Google Patents
ソフトウェア・モジュール動的交換方法及びソフトウェア・モジュール動的交換プログラム記録媒体 Download PDFInfo
- Publication number
- JP3986721B2 JP3986721B2 JP2000011473A JP2000011473A JP3986721B2 JP 3986721 B2 JP3986721 B2 JP 3986721B2 JP 2000011473 A JP2000011473 A JP 2000011473A JP 2000011473 A JP2000011473 A JP 2000011473A JP 3986721 B2 JP3986721 B2 JP 3986721B2
- Authority
- JP
- Japan
- Prior art keywords
- class
- application
- program
- core
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はネットワークに接続されているデバイスで動作するアプリケーションの実行に必要なモジュールを、同じくネットワークに接続されている遠隔の端末から交換するための、ソフトウェアモジュールの交換方式に関するものである。
【０００２】
【従来の技術】
デバイスと端末がネットワークに接続されていて、デバイス上のソフトウエアモジュールを端末から交換する典型的な従来のシステム構成として、特開平１１−４５１７４号公報に示されたものを図１０に示す。
図において、１１１はデバイス本体、１１２は端末、１１３はデバイス本体１と端末２が接続されているネットワーク、１１４はデバイス本体１１１上で動作するアプリケーション、１２０はアプリケーション１１４を実行するためのプラットフォーム（ＯＳ）、１１５はアプリケーション１１４の機能を実現するアプリケーション・クラス（ファイルＡ，Ｂ，Ｃ）、１１６はアプリケーション・クラス１１５の管理や交換を行うコアクラス（コピーフィルタ）、１１７はアプリケーション・クラス１１５のロードを行うアプリケーション・クラス・ローダ、１１８はコアクラスの機能を実現するサブコアモジュール、１２１はコアクラス１１６及びそこで使用されている各サブコアモジュール１１８のロードを行うコアクラス・ローダである。
デバイス本体１１１で動作するアプリケーション１１４のバージョンアップを行うために、アプリケーション・クラス１１５を新しいモジュールに交換する場合、そのアプリケーション・クラス１１５の交換はモジュール交換機能を持つコアクラス１１６にあるアプリケーション・クラス・ローダ１１７を通してロードされ、交換が行われる。
【０００３】
以下に、上述した内容を図１０に基づいて具体的に説明する。
まず、プラットフォーム１２０はアプリケーション１１４を起動するために、コアクラス・ローダ１２１を使用してコアクラス１１６とアプリケーション・クラス・ローダ１１７と各サブコアモジュール１１８のロードを行い、その後コアクラス１１６を起動する。
起動されたコアクラス１１６はアプリケーション１１４の機能を実行するために、アプリケーション・クラス・ローダ１１７を使用して、アプリケーション・クラス１１５をロードし、更に、その動作を開始させる。
アプリケーション・クラス１１５の交換を行う場合、コアクラス１１６は、各アプリケーション・クラス１１５を停止させ、再びアプリケーション・クラス・ローダ１１７を使用して新しいアプリケーション・クラス１１５をロードし、更にその動作を開始させる。このように、アプリケーション・クラス・ローダ（リネーム部）がＯＳとは関係なく起動し、アプリケーション・クラスを交換する場合が説明されているが、他の先行例ではＯＳ側からロードモジュールを（交換）起動するので、交換のためにはＯＳを一度、止めてから行うことが必要である。
【０００４】
しかし上記のアプリケーション・クラス１１５の交換は、コアクラス１１６とその構成要素の一つであるアプリケーション・クラス・ローダ１１７を用いて行うことができるが、コアクラス１１６の機能のバージョンアップを行いたい場合、コアクラス１１６と、コアクラス１１６で使用するモジュールアプリケーション・クラス・ローダ１１７及びサブコアモジュール１１８はプラットフォーム（仮想ＯＳ）１２０にあるコアクラス・ローダ１２１でロードされているために、プラットフォーム１２０を再起動し直して、もう一度コアクラス・ローダ１２１で新しいモジュール（コアクラス）がロードされるか、またはプラットフォーム１２０でモジュールの交換がサポートされる必要がある。
通常はプラットフォーム１２０でモジュールの交換がサポートされていないので、コアクラス１１６またはアプリケーション・クラス・ローダ１１７を交換するためには、一度システムを止めて、プラットフォームを再起動する必要がある。こうしてシステムを止めない範囲に交換限度を定めると、アプリケーション１１４でバージョンアップできるものはアプリケーション・クラス１１５のみとなり、またはアプリケーション・クラス１１５の交換処理の起動さえもコアクラス１１６の機能範囲内に制限されてしまう。
【０００５】
【発明が解決しようとする課題】
以上のように従来の構成では、機能モジュールの動作中に交換はできても、メインコアモジュールや機能モジュールローダの動作中の交換はできないという課題があった。
【０００６】
本発明は上記の課題を解決しようとするもので、ＯＳ等のベーシック側からアプリケーション・プログラムを止めないで、つまりデバイスを動作中にも機能モジュールや、コアクラスの交換を可能にする。
【０００７】
【課題を解決するための手段】
この発明に係るソフトウェア・モジュール動的交換装置は、アプリケーションを搭載するデバイスでは、
プログラム構成として、アプリケーション・モジュールとしてのアプリケーション・クラスまたはアプリケーション・クラスを交換するコアクラス自体に、自身の更新を基本側に要求する交換要求ステップを設けたプログラムとし、
各プログラムをロードするプラットフォーム側に、この交換要求を受けて、対応する新規バージョンをロードするコアクラス・ローダを備えて、
このコアクラス・ローダを搭載するベースクラスのプログラムに新規バージョンをロード後に、アプリケーションに動作を起動する開始ステップを組み込んだ。
【０００８】
また更に、デバイスには、外部からの新規アプリケーション・モジュールまたは新規コアクラスを受ける記憶部分を備えて、交換に先立って外部から交換用の新規アプリケーション・モジュールまたは新規コアクラスを記憶するようにした。
【０００９】
この発明に係るソフトウェア・モジュール動的交換方法は、デバイス上にアプリケーション・プログラム（以下アプリケーション）を展開して動作する構成において、
アプリケーション・モジュールとしてのアプリケーション・クラスまたはアプリケーション・クラスを交換するコアクラス自体に、自身の更新を基本側に要求する交換要求ステップと、
各プログラムをロードするプラットフォーム側に、この交換要求を受けて、対応する新規バージョンをロードするステップと、ロード後に、アプリケーションに動作を起動する開始ステップを備えた。
【００１０】
また更に、ロードするステップでは、交換要求に基づいて、アプリケーション・モジュールと、コアクラスの双方を同時に交換するようにした。
【００１１】
また更に、交換要求は、デバイスが接続するインタフェースを通じてアプリケーションで検出するようにした。
【００１２】
この発明に係るソフトウェア・モジュール動的交換方法記録媒体は、デバイス上にアプリケーション・プログラムを展開して動作する計算機に対して、
アプリケーション・モジュールとしてのアプリケーション・クラスまたはアプリケーション・クラスを交換するコアクラス自体に、自身の更新を基本側に要求する交換要求ステップと、
上記各プログラムをロードするプラットフォーム側に、この交換要求を受けて、対応する新規バージョンをロードするステップと、ロード後に、アプリケーションに動作を起動する開始ステップを媒体に記載した。
【００１３】
【発明の実施の形態】
実施の形態１．
メインコアモジュール等、アプリケーション側のモジュールまたはコアの交換を仮想ＯＳ側からの処理によってのみ行うのではなく、ＯＳ等の基本プログラム側に代わって擬似的に行う手段（プログラム、ステップ）を挿入、組み込むことで、ＯＳ側を止めないで動的に交換を可能にする。文書作成プログラムや、スプレッドシートのようにＯＳを一旦止めて更新が可能なアプリケーションもあるが、オンライン機器、制御用機器組み込みのアプリケーションであると、いったんのＯＳ等のベーシック側を停止することが望ましくない場合がある。
【００１４】
図１は本発明の実施の形態１におけるプログラムの階層を説明する図である。図において新規な要素は、コアクラスとそれに搭載されるクラスのロードと起動を行うベースクラス１８と、それに搭載し、コアクラス１６及びアプリケーション・クラス・ローダ１７等をＯＳの動作中にＯＳに代わってロードする代替コアクラス・ローダである。その他の要素として、１１はデバイス本体、１２は端末、１３はデバイス本体１１と端末１２が接続されているネットワーク、１４はデバイス本体１１上で動作するアプリケーション、１５はアプリケーション１４の機能を実現するためのアプリケーション・クラス、１６はアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラス（図示しない）の管理、交換およびアプリケーション・クラス１５への処理の開始を要求するコアクラス、１７はアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスのロードを行うアプリケーション・クラス・ローダ、２０はプラットフォームとしてのJavaVM、２１は各種クラス（ベースクラス１８および代替コアクラス・ローダ１９以外は図示しない）のロードを行うベースクラス・ローダである。本システムではプラットフォームとしてJavaを想定した場合について記述するが、同じ動作をする他のプラットフォームを使用してもよい。
【００１５】
なお、具体的にアプリケーション・クラスを交換する場合の例として以下がある。アプリケーションの交換の場合にはデバイスの種類に対応するので、例えば、
１−１）監視カメラ的には縦、横への方向変化およびズームなどができるが、交換前の監視カメラ用制御アプリケーションではズーム機能しかサポートしていないような場合、このアプリケーションを交換することによって縦、横への方向変更機能を追加する。（デバイスの機能にアプリケーションが追いついていない場合）。また、今までは監視カメラの映像は監視カメラ用制御アプリケーションで圧縮率の低い方式で圧縮して配信していたが、このアプリケーションを圧縮率の高い方式で圧縮できるアプリケーションと交換することによって監視カメラの映像をビットレートを変えることなしに品質よく配信できる、または同じ品質の映像を低ビットレートで配信することができるようになる（デバイスの機能とは関係しない）。
１−２）冷蔵庫用制御アプリケーションの温度調整機能の部分をより効率よく行うことができるものに交換する。
１−３）自販機制御用アプリケーションで、今までは端末側から自販機にアクセスすることによって、情報がとれるようになっていたが、自販機側から端末に通知できる機能を追加したアプリケーションに変更することによって、例えば、商品がなくなりそうな場合にそのことを通知したり、釣銭が切れた場合や、その日の売り上げなどを通知できるようになる。
【００１６】
また、コアクラスを変換する場合の例として以下がある。
２−１）今まではアプリケーション・クラスをロードする際には、一度デバイスにクラスのファイルをダウンロードしてから交換を行っていたが、コアクラスのバージョンアップと交換により、ネットワークを通して直接クラスをロードできるようになれば、デバイスではクラスのファイルを格納しておく分のリソースを節約できる。
２−２）アプリケーション・クラスの管理方式を変更したコアクラスのバージョンアップを行う。
【００１７】
以下、図２を用いてアプリケーション１４が起動するまでの処理について説明する。
まず、アプリケーション１４を起動させるために、プラットフォームとしてのJavaVM２０がシステムクラス・ローダ２１を使用して、ベースクラス１８をロードする。またベースクラス１８で使用されている代替コアクラス・ローダ１９もロードする。さらにベースクラス１８の起動用メソッドを呼び出し、アプリケーション１４を起動させる（ステップＳ１、以下ステップを省略）。この処理はJavaVM２０内で行われている処理なので、プラットフォーム依存であるが、概要的には上述した処理が行われる。
【００１８】
ベースクラス・ローダ２１でロードされたクラスはJavaVM２０を再起動しない限り再ロードされることはないので、ベースクラス・ローダ２１でロードされたクラスは動的には交換を行うことができない。しかし、ベースクラス１８の機能は自分自身の交換を行わなくても良いように、図３に示すように単純な機能しかない。図３は、図１のJavaVM２０とコアクラス１６の間に新しく設けた単純機能のベースクラス１８と代替コアクラス・ローダの具体構成を示す図である。特にＳ４１、Ｓ４３と、Ｓ４５、Ｓ４６の処理を組み込んだ部分が重要である。この例ではコアクラス１６およびコアクラス１６で使用されるクラスのロードとコアクラス１６への処理の開始要求のみを行う。また、デバイスのＯＳに代ってアプリケーション１４からのアプリケーション更新要求を受ける機能を持つが、この説明は後に更新動作で説明する。
次に、JavaVM２０によって起動されたベースクラス１８は、代替コアクラス・ローダ１９のインスタンスを作成し（Ｓ２）、これを使用して、コアクラス１６およびコアクラス１６で使用されるクラスのロードを行う（Ｓ３）。この例ではコアクラス１６で使用されるクラスは、アプリケーション・クラス・ローダ１７のみである。上記新規要素を構成することで、Ｓ２とＳ３のステップが余分にいることになるが、これは後の更新動作のために有効なステップとなる。
【００１９】
以下にコアクラス１６とコアクラスで使用されるクラスのロード処理について、Ｓ３の詳細を図４を用いて説明する。ベースクラスのロード処理については、プラットフォーム依存なので、ここではプラットフォームとしてJavaを使用した場合のベースクラスのロード処理について説明する。
まず、代替コアクラス・ローダ１９がコアクラス１６のバイトコードを取り出す際、バイトコードをローカルから取り出すのか、それともリモートから取り出すのかを決定する（Ｓ４）。ローカルかリモートかを判断する方法としては、クラス名はアプリケーション側で指定することができるので、例えば、リモートにあるWebサーバからバイトコードを取り出すような場合、ロードするクラス名を“http://ホスト名/クラス名”のように指定することによって行うことができる。ロードされるバイトコードは実際には“クラス名.class“というファイル名であるので、取り出す際には”http://ホスト名/クラス名“の最後に”.class“を付けたURLで、目的とするバイトコードを提供するWebサーバに要求することによって行う。この場合上記URLでバイトコードを取れるようにバイトコードを提供するWebサーバを設定しておく必要がある。
【００２０】
次に代替コアクラス・ローダ１９は既にバージョンアップされたデータがローカルのバッファにファイルとして取り込まれている場合には、そのローカルにあるファイルから（Ｓ５）、オンラインでリモートから取り出す場合は、上述したようにHTTPを使用してネットワーク経由でWebサーバからバイトコードを取り出す（Ｓ６）。ここでリモートからの取り出しの場合にはURLからクラス名の部分を取り出しておく（Ｓ７）。
次に、先ほど取り出したバイトコードをJavaVM２０で用意されているメソッドを使用してクラスに変換し（Ｓ８）、これを、クラス名をキーとして格納し（Ｓ９）、このクラスを要求もとに返す（Ｓ１０）。これでＳ３は終了する。
【００２１】
なお、格納しておいたクラスは、同じクラスに対して要求があった場合に、もう一度バイトコードの取り出しを行うことなしにクラスを返すために使用する。これらの処理はリモートからバイトコードを取り出す際にクラス名の前に“http://ホスト名/”を付けて代替コアクラス・ローダ１９に要求する以外は、Javaで通常用いられる方法で行うことが出来る。
さらに、JavaVM２０で用意されているバイトコードをクラスにするメソッドを使用した際に、そのクラスで使用されるクラスのロードが要求されるので、上述した方法と同じようにクラスのロードを行う。ただし、このロード要求はJavaVM２０から要求されるので、クラス名の前にに“http://ホスト名/”が付けられて指定されることはない。このため取り出すべきバイトコードがローカルにあるのかリモートにあるのかを判断することができないので、今までにリモートから取り出したバイトコードがあるかをチェックし（Ｓ１１）、ある場合には、このリモートの位置からバイトコードの取り出しを試みる。ここで取り出しに成功したかのチェックを行い（Ｓ１２）、もし取り出しに失敗した場合にはローカルからバイトコードの取り出しを行う。
この処理をクラスの中で他のクラスが呼ばれなくなるまで繰り返す。以上のようにクラスのロード処理を行う。なおこの処理は以後に記述されるクラスロードにおいても同じ処理を行う。
【００２２】
次に、図２に戻り、ベースクラス１８はコアクラス１６のインスタンスを作成し、この作成したインスタンスに対してコアクラス１６で定義されている処理開始用メソッドを呼び出す（Ｓ１３）。この後、ベースクラス１８はコアクラス１６への処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。
ベースクラス１８では代替コアクラス・ローダ１９でコアクラス１６およびコアクラス１６で使用されるクラスをロードしたことにより、代替コアクラス・ローダ１９でロードされたこれらのクラスは代替コアクラス・ローダ１９のインスタンスを再生成して、再ロードされることにより、クラスの交換が可能になる。クラスの再ロードは上述したクラスのロード処理と同じ方法で行う。
次に、ベースクラス１８によって開始されたコアクラス１６は、アプリケーション・クラス・ローダ１７のインスタンスを作成し（Ｓ１４）、これを使用して、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスのロードを行う（Ｓ１５）。ロード処理については代替コアクラス・ローダ１９での処理と同様である。
【００２３】
次に、コアクラス１６はアプリケーション・クラス１５のインスタンスを作成し、この作成したインスタンスに対してアプリケーション・クラス１５で定義されている処理開始用メソッドを呼び出す（Ｓ１６）。このメソッド呼び出しの際にパラメータとしてコアクラス１６自身を設定しておく。これはコアクラス１６およびコアクラス１６で使用されるクラスのクラス交換要求をアプリケーション・クラス１５から受け取るためである。この後、コアクラス１６はアプリケーション・クラス１５の処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。コアクラス１６ではアプリケーション・クラス・ローダ１７でアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスをロードしたことにより、アプリケーション・クラス・ローダ１７でロードされたこれらのクラスはアプリケーション・クラス・ローダ１７のインスタンスを再生成して、再ロードされることにより、クラスの交換が可能になる。クラスの再ロードは上述したクラスのロード処理と同じ方法で行う。
次に、コアクラス１６によって開始されたアプリケーション・クラス１５はアプリケーション１４で提供する機能の処理を行う。この処理に関してはここでは関係ないので省略する。
【００２４】
以上がアプリケーション１４の立ち上げまでの処理であり、以下に図５を用いて、重要であるＯＳ動作を止めないで行えるクラス交換処理について説明する。アプリケーション１４で監視していて、モジュールの交換要求があると、その内容によりアプリケーション・クラスの交換であれば図２のＳ１４へ、コアクラスの交換であればＳ２へ割り込んで、以後の交換動作を行う。
クラスの交換は上述したように、アプリケーション・クラス・ローダ１７でロードされたアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスと代替コアクラス・ローダ１９でロードされたコアクラス１６およびコアクラス１６で使用されるクラスに対して行うことができる。そして、コアクラス１６レベルの交換であっても、上述のパラメータ設定をしてコアクラス１６がアプリケーション・クラス１５から受け取り、プラットフォームではなくてベースクラス１８に伝えることで、ベースクラス１８の起動がかかる。すなわち、新規に挿入したベースクラス１８と代替コアクラス・ローダ１９がＯＳに代わる交換動作を行うことになる。
【００２５】
図６にアプリケーション・クラスの詳細な構成例を示す。図６において、２２は端末１２からの要求を受け取るための要求受付部、２３は要求受付部２２で受け取った端末１２からの要求がどのような要求であるかを調査する要求調査部、２４は要求調査部２３の調査から得られた要求に応じたサービスの実行と現在実行されているサービス数の管理等を行うサービス実行管理部、２５は端末１２からの要求に応じたサービスを行う各種サービス、２６はクラスの交換処理を行うサービスであるクラス交換サービス、２７はクラス交換要求がどのようなクラス交換であるかを調査するためのクラス交換要求調査部、２８はクラス交換要求のパラメータに新しいクラスのバイトコードが含まれていた場合に、このバイトコードをローカルにある古いバイトコードに上書きするバイトコード保存部、２９は端末１２への応答を返すための応答部、３０はアプリケーション・クラス１５またはコアクラス１６にクラスの再ロードを要求するためにクラス再ロード要求を出すためのクラス再ロード要求部、３１はクラス再ロード要求を受け取り、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの再ロードのための処理を行うアプリケーション・クラス再ロード処理部である。
【００２６】
まず、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスを交換する場合について説明する。
アプリケーション・クラス１５は、端末１２からの要求を要求受付部２２を使用して待っている（Ｓ１７）。次に、端末１２から要求が送られてきたら、この要求を要求調査部２３で調査する（Ｓ１８）。ここで端末１２がWebブラウザであり、アプリケーション１４がWebサーバであった場合には、端末１２からの要求としては図７のようになり、メソッドとリクエストURIを調査することによってどのサービスが要求されているのかを選択することができる。例えばメソッドが“GET”で、リクエストURIが“/default.html”であった場合は、Webサーバ上のルートにある“default.html”というファイルの内容を返すサービスであるし、またメソッドに“POST”、リクエストURIに“/servlet/ExchangeClass”と設定することによってクラスの交換要求であるとすることができる。もちろん上記以外の方法でリクエストを設定してもよい。
次に、サービス実行管理部２４では、要求調査部２３で上述したような調査から得られた要求に応じたサービスを実行する。サービスに関してはCGIプログラムであってもよいし、サーブレットであってもかまわなく、サービスが実行できるようなものであればどのようなものでもかまわない。
【００２７】
この場合は要求としてクラス交換要求を想定しているので、クラス交換サービス２６を開始させる（Ｓ１９）。
次に、クラス交換サービス２６ではクラス交換要求調査部２７を使用して、さらにこのクラス交換要求がアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの交換であるか、またはコアクラス１６およびコアクラス１６で使用されるクラスの交換であるかを調査する（Ｓ２０）。調査方法としては上述したように端末からの要求がHTTP要求であるような場合には、例えばアプリケーション・クラス１５の交換であれば、リクエストURIの部分を“/servlet/ExchangeApplicationClass”とし、またコアクラス１６の交換であれば“/servlet/ExchangeCoreClass”というように設定することによって行うことができる。ここでは、調査した結果がアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの交換であるとする。
次に、交換を行うクラスがローカルに存在するクラスである場合は、クラス交換要求にパラメータとして交換するクラスの新しいバイトコードを添付しておく。これも端末１２からの要求がHTTP要求である場合には、バイトコードをエンティティボディの部分に設定する。
【００２８】
次に、クラス交換サービス２６では、この新しいバイトコードを、バイトコード保存部２８を使用し、ローカルに存在する古いバイトコードに上書きする（Ｓ２１）。
一方、交換するクラスがリモートに位置するクラスである場合には、クラスの交換を行いたいユーザが、リモートに位置する古いバイトコードを新しいバイトコードで上書きしておき、パラメータなしでクラス交換要求を出す。
次に、クラス交換サービス２６では、応答部２９で端末１２に応答を返す（Ｓ２２）。上述したように、端末１２との通信にHTTPを使用している場合には図８に示す応答を返す。例えばこれまでの処理に成功していて、これからクラスの交換を行うような場合には、ステータスコードに“200”、ヘッダに“Content-Type:text/plain”、メッセージボディに“これからクラス交換を行います。”などを設定して、端末１２に送る。
次に、クラス交換サービス２６ではクラス再ロード要求部３０を使用し、アプリケーション・クラス１５にクラス再ロード要求を出し、自分自身の処理を終了させる。クラス再ロード要求としては、ただ単にメソッドの呼び出しでもかまわないし、他の方法を使用してもかまわない。ここではメソッド呼び出しとする。
次に、アプリケーション・クラス１５では、アプリケーション・クラス再ロード処理部３１で、このクラス再ロード要求を受け取る。上述したようにクラス再ロード要求がメソッドの呼び出しである場合は、アプリケーション・クラス再ロード処理部がこのメソッドになる。
【００２９】
次に、アプリケーション・クラス１５では、要求受付部２２で行っている端末１２からの要求受付を停止するよう要求受付部２２に要求する（Ｓ２３）。この要求もただ単にメソッド呼び出しでもよいし、他の方法を使用してもよい。
次に、要求受付部２３では停止要求に基づき、端末１２からの要求受付を停止する。停止する方法としてはただ単に要求を待つループを抜けるだけで行うこともできるし、他の方法で停止してもよい。
次に、アプリケーション・クラス１５では、サービス実行管理部２４を使用して現在アプリケーション・クラス１５上で動作している他のサービス２５がある場合には、このサービスが終了するのを待つ（Ｓ２４）。上述したように、アプリケーション１４がWebサーバである場合には、サービス２５は端末１２に応答を返した後にサービスが終了する。
次に、実行中のアプリケーションのサービス２５が全て終了したら、アプリケーション・クラス１５は、自分自身の処理を終了させる。
【００３０】
コアクラス１６ではアプリケーション・クラス１５の処理開始用メソッドを呼び出した後、このメソッド呼び出しに対する応答が返ってくるのを待ち続けているため、アプリケーション・クラス１５の処理が終了した場合、コアクラス１６に制御が返ってくる。
次に、コアクラス１６では、後述するコアクラス終了フラグをチェックし（Ｓ２６）、このフラグが立っていなければ、アプリケーション・クラス・ローダ１７のインスタンスを再生成して、この新たに作成したアプリケーション・クラス・ローダ１７のインスタンスを使用して、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスのロードを行う。
もしコアクラス終了フラグが立っていた場合の処理については、後述するコアクラス１６およびコアクラス１６で使用されるクラスの交換で説明する。
そして、アプリケーション１４の起動処理と同様に、コアクラス１６で、アプリケーション・クラス１５のインスタンスを作成し、この作成したインスタンスに対して、アプリケーション・クラス１５で定義されている処理開始用メソッドを呼び出し、また処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。このようにしてアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの交換を行う。
【００３１】
次に、もう１つの重要な動作であるコアクラス１６およびコアクラス１６で使用されるクラスを交換する場合について説明する。
各処理に関しては特に記述がない限り、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスを交換する場合で説明した方法と同じである。
まず、アプリケーション・クラス１５は、端末１２からの要求を要求受付部２２を使用して待っている（Ｓ１７）。端末１２から要求が送られてきたら、要求調査部２３で調査する（Ｓ１８）。
次に、サービス実行管理部２４では、この場合は要求としてクラス交換要求であるので、クラス交換サービス２６を開始させる（Ｓ１９）。
次に、クラス交換サービス２６ではクラス交換要求調査部２７を使用して、アプリケーション・クラス１５レベルの交換であるか、またはコアクラス１６およびコアクラス１６で使用されるクラスの交換であるかを調査する（Ｓ２０）。ここでは、調査した結果がコアクラス１６およびコアクラス１６で使用されるクラスの交換であるとする。
次に、交換を行うクラスがローカルに存在するクラスである場合は、クラス交換要求にパラメータとして交換するクラスの新しいバイトコードを添付しておき、クラス交換サービス２６では、この新しいバイトコードを、ローカルに存在する古いバイトコードに上書きする（Ｓ２１）。交換するクラスがリモートに位置するクラスである場合には、ユーザがリモートに位置する古いバイトコードを新しいバイトコードで上書きしておき、パラメータなしでクラス交換要求を出す。クラス交換サービス２６では、応答部２９で端末１２に応答を返した後（Ｓ２２）、上述のアプリケーション・クラス１５レベルの交換と同様、自分自身の処理を終了させる。
【００３２】
図９にコアクラス１６の構成を示す。図９において、３２はクラス再ロード要求を受け取り、コアクラス１６およびコアクラス１６で使用されるクラスの再ロードのための処理を行うコアクラス再ロード処理部、３３はアプリケーション・クラス１５にクラスの再ロードを要求するためにクラス再ロード要求を出すためのアプリケーション・クラス再ロード要求部である。
コアクラス１６では、コアクラス再ロード処理部３２で、クラス再ロード要求を受け取る。上述したようにクラス再ロード要求がメソッド呼び出しであった場合は、コアクラス再ロード処理部がこのメソッドになる。
次に、コアクラス１６では、アプリケーション・クラス１５が終了した際に、コアクラス１６自身も終了するようにコアクラス終了フラグを立てる（Ｓ２５）。
次に、コアクラス１６では、アプリケーション・クラス再ロード要求部３３を使用してアプリケーション・クラス１５にクラスの再ロード要求を送る。上述したようにクラス再ロード要求としては、ただ単にメソッドの呼び出してもかまわないし、他の方法を使用してもかまわない。ここではメソッド呼び出しとする。
次に、アプリケーション・クラス１５では、アプリケーション・クラス再ロード処理部３１で、このクラス再ロード要求を受け取る。そして端末１２からの要求受付を停止するよう要求受付部２２に要求し（Ｓ２３）、現在アプリケーション・クラス１５上で動作している他のサービス２５がある場合には、このサービスが終了するのを待つ（Ｓ２４）。更に実行中のアプリケーションのサービス２５が全て終了したら、アプリケーション・クラス１５は、自分自身の処理を終了させる。
【００３３】
コアクラス１６では、アプリケーション・クラス１５の処理開始用メソッドを呼び出した後、このメソッド呼び出しに対する応答が返ってくるのを待ち続けているため、アプリケーション・クラス１５の処理が終了した場合、コアクラス１６に制御が返ってくる。
次に、コアクラス１６では、コアクラス終了フラグが立っているかをチェックする（Ｓ２６）。この場合上述したようにコアクラス再ロード処理部３２でコアクラス終了フラグを立てているので、コアクラス１６自身の処理を終了させる。
ベースクラス１８では、コアクラス１６の処理開始用メソッドを呼び出した後、このメソッド呼び出しに対する応答が返ってくるのを待ち続けているため、コアクラス１６の処理が終了した場合、ベースクラス１８に制御が返ってくる。即ちＳ２６のチェックにより図２のＳ２に戻ることになる。
そこで、もう１つの重要な動作であるベースクラス１８では、代替コアクラス・ローダ１９のインスタンスを再生成して、Ｓ３でこの新たに作成した代替コアクラス・ローダ１９のインスタンスを使用して、コアクラス１６およびコアクラス１６で使用されるクラスのロードを行う。そして、アプリケーション１４の起動処理と同様にコアクラス１６のインスタンスを作成し、この作成したインスタンスに対して、コアクラス１６で定義されている処理開始用メソッドを呼び出し、また処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。
さらにコアクラス１６で上述したアプリケーション１４の立ち上げ時と同じ処理を行い、アプリケーション・クラス１５を開始させる。このようにしてコアクラス１６およびコアクラス１６で使用されるクラスの交換を行う。
以上のような方式により、コアクラス１６およびコアクラス１６で使用されるクラスの交換が行えるようになり、デバイス１１上のアプリケーション１４の機能を構成するクラスの全ての交換が可能になる。
【００３４】
【発明の効果】
以上のようにこの発明によれば、アプリケーション側からの交換要求を受けて新規モジュールを交換する代替コアクラス・ローダ、ベースクラスを備えたので、ＯＳを止めないでも、プラットフォーム側に代わってコアクラスまたはアプリケーション・クラスを交換できる効果がある。
【図面の簡単な説明】
【図１】 本発明の実施の形態１におけるプログラム構造を示す図である。
【図２】 実施の形態１におけるアプリケーション起動までの動作フロー図である。
【図３】 実施の形態１におけるベースクラスの内容の具体例を示す図である。
【図４】 図２におけるＳ３の詳細動作フロー図である。
【図５】 実施の形態１におけるモジュールの交換要求に基づく動作を示すフロー図である。
【図６】 アプリケーション・クラスの詳細構成例を示す図である。
【図７】 実施の形態１における端末からの交換要求のフォーマット例を示す図である。
【図８】 実施の形態１における交換要求に対する端末への応答フォーマット例を示す図である。
【図９】 コアクラスの構成例を示す図である。
【図１０】 従来のモジュール交換を行う装置構成を示す図である。
【符号の説明】
１１ デバイス、１２ 端末、１３ ネットワーク、１４ アプリケーション、１５ アプリケーション・クラス、１６ コアクラス、１７ アプリケーション・クラス・ローダ、１８ ベースクラス、１９ 代替コアクラス・ローダ、２０ ＪａｖａＶＭ（プラットフォーム）、２１ ベースクラス・ローダ、２２ 要求受付部、２３ 要求調査部、２４ サービス実行管理部、２５ 各種サービス、２６ クラス交換サービス、２７ クラス交換要求調査部、２８ バイトコード保存部、２９ 応答部、３０ クラス再ロード部、３１ アプリケーション・クラス再ロード部、３２ コアクラス再ロード処理部、３３ アプリケーション・クラス再ロード要求部、Ｓ２ コアクラス・ローダのインスタンスの作成ステップ、Ｓ３ コアクラスとコアクラスで使用するクラスのロードステップ、Ｓ１３コアクラスのインスタンスの生成と開始指示ステップ、Ｓ１４ アプリケーション・クラス・ローダのインスタンス生成ステップ、Ｓ１５ アプリケーション・クラスとアプリケーション・クラスで使用するクラスのロードステップ、Ｓ１６ アプリケーション・クラスのインスタンス生成と開始指示ステップ、Ｓ１８ 端末からの要求調査ステップ、Ｓ１８ｂ クラス交換の要求かの判断ステップ、Ｓ２０ｂ コアクラス交換かの判断ステップ。
【発明の属する技術分野】
本発明はネットワークに接続されているデバイスで動作するアプリケーションの実行に必要なモジュールを、同じくネットワークに接続されている遠隔の端末から交換するための、ソフトウェアモジュールの交換方式に関するものである。
【０００２】
【従来の技術】
デバイスと端末がネットワークに接続されていて、デバイス上のソフトウエアモジュールを端末から交換する典型的な従来のシステム構成として、特開平１１−４５１７４号公報に示されたものを図１０に示す。
図において、１１１はデバイス本体、１１２は端末、１１３はデバイス本体１と端末２が接続されているネットワーク、１１４はデバイス本体１１１上で動作するアプリケーション、１２０はアプリケーション１１４を実行するためのプラットフォーム（ＯＳ）、１１５はアプリケーション１１４の機能を実現するアプリケーション・クラス（ファイルＡ，Ｂ，Ｃ）、１１６はアプリケーション・クラス１１５の管理や交換を行うコアクラス（コピーフィルタ）、１１７はアプリケーション・クラス１１５のロードを行うアプリケーション・クラス・ローダ、１１８はコアクラスの機能を実現するサブコアモジュール、１２１はコアクラス１１６及びそこで使用されている各サブコアモジュール１１８のロードを行うコアクラス・ローダである。
デバイス本体１１１で動作するアプリケーション１１４のバージョンアップを行うために、アプリケーション・クラス１１５を新しいモジュールに交換する場合、そのアプリケーション・クラス１１５の交換はモジュール交換機能を持つコアクラス１１６にあるアプリケーション・クラス・ローダ１１７を通してロードされ、交換が行われる。
【０００３】
以下に、上述した内容を図１０に基づいて具体的に説明する。
まず、プラットフォーム１２０はアプリケーション１１４を起動するために、コアクラス・ローダ１２１を使用してコアクラス１１６とアプリケーション・クラス・ローダ１１７と各サブコアモジュール１１８のロードを行い、その後コアクラス１１６を起動する。
起動されたコアクラス１１６はアプリケーション１１４の機能を実行するために、アプリケーション・クラス・ローダ１１７を使用して、アプリケーション・クラス１１５をロードし、更に、その動作を開始させる。
アプリケーション・クラス１１５の交換を行う場合、コアクラス１１６は、各アプリケーション・クラス１１５を停止させ、再びアプリケーション・クラス・ローダ１１７を使用して新しいアプリケーション・クラス１１５をロードし、更にその動作を開始させる。このように、アプリケーション・クラス・ローダ（リネーム部）がＯＳとは関係なく起動し、アプリケーション・クラスを交換する場合が説明されているが、他の先行例ではＯＳ側からロードモジュールを（交換）起動するので、交換のためにはＯＳを一度、止めてから行うことが必要である。
【０００４】
しかし上記のアプリケーション・クラス１１５の交換は、コアクラス１１６とその構成要素の一つであるアプリケーション・クラス・ローダ１１７を用いて行うことができるが、コアクラス１１６の機能のバージョンアップを行いたい場合、コアクラス１１６と、コアクラス１１６で使用するモジュールアプリケーション・クラス・ローダ１１７及びサブコアモジュール１１８はプラットフォーム（仮想ＯＳ）１２０にあるコアクラス・ローダ１２１でロードされているために、プラットフォーム１２０を再起動し直して、もう一度コアクラス・ローダ１２１で新しいモジュール（コアクラス）がロードされるか、またはプラットフォーム１２０でモジュールの交換がサポートされる必要がある。
通常はプラットフォーム１２０でモジュールの交換がサポートされていないので、コアクラス１１６またはアプリケーション・クラス・ローダ１１７を交換するためには、一度システムを止めて、プラットフォームを再起動する必要がある。こうしてシステムを止めない範囲に交換限度を定めると、アプリケーション１１４でバージョンアップできるものはアプリケーション・クラス１１５のみとなり、またはアプリケーション・クラス１１５の交換処理の起動さえもコアクラス１１６の機能範囲内に制限されてしまう。
【０００５】
【発明が解決しようとする課題】
以上のように従来の構成では、機能モジュールの動作中に交換はできても、メインコアモジュールや機能モジュールローダの動作中の交換はできないという課題があった。
【０００６】
本発明は上記の課題を解決しようとするもので、ＯＳ等のベーシック側からアプリケーション・プログラムを止めないで、つまりデバイスを動作中にも機能モジュールや、コアクラスの交換を可能にする。
【０００７】
【課題を解決するための手段】
この発明に係るソフトウェア・モジュール動的交換装置は、アプリケーションを搭載するデバイスでは、
プログラム構成として、アプリケーション・モジュールとしてのアプリケーション・クラスまたはアプリケーション・クラスを交換するコアクラス自体に、自身の更新を基本側に要求する交換要求ステップを設けたプログラムとし、
各プログラムをロードするプラットフォーム側に、この交換要求を受けて、対応する新規バージョンをロードするコアクラス・ローダを備えて、
このコアクラス・ローダを搭載するベースクラスのプログラムに新規バージョンをロード後に、アプリケーションに動作を起動する開始ステップを組み込んだ。
【０００８】
また更に、デバイスには、外部からの新規アプリケーション・モジュールまたは新規コアクラスを受ける記憶部分を備えて、交換に先立って外部から交換用の新規アプリケーション・モジュールまたは新規コアクラスを記憶するようにした。
【０００９】
この発明に係るソフトウェア・モジュール動的交換方法は、デバイス上にアプリケーション・プログラム（以下アプリケーション）を展開して動作する構成において、
アプリケーション・モジュールとしてのアプリケーション・クラスまたはアプリケーション・クラスを交換するコアクラス自体に、自身の更新を基本側に要求する交換要求ステップと、
各プログラムをロードするプラットフォーム側に、この交換要求を受けて、対応する新規バージョンをロードするステップと、ロード後に、アプリケーションに動作を起動する開始ステップを備えた。
【００１０】
また更に、ロードするステップでは、交換要求に基づいて、アプリケーション・モジュールと、コアクラスの双方を同時に交換するようにした。
【００１１】
また更に、交換要求は、デバイスが接続するインタフェースを通じてアプリケーションで検出するようにした。
【００１２】
この発明に係るソフトウェア・モジュール動的交換方法記録媒体は、デバイス上にアプリケーション・プログラムを展開して動作する計算機に対して、
アプリケーション・モジュールとしてのアプリケーション・クラスまたはアプリケーション・クラスを交換するコアクラス自体に、自身の更新を基本側に要求する交換要求ステップと、
上記各プログラムをロードするプラットフォーム側に、この交換要求を受けて、対応する新規バージョンをロードするステップと、ロード後に、アプリケーションに動作を起動する開始ステップを媒体に記載した。
【００１３】
【発明の実施の形態】
実施の形態１．
メインコアモジュール等、アプリケーション側のモジュールまたはコアの交換を仮想ＯＳ側からの処理によってのみ行うのではなく、ＯＳ等の基本プログラム側に代わって擬似的に行う手段（プログラム、ステップ）を挿入、組み込むことで、ＯＳ側を止めないで動的に交換を可能にする。文書作成プログラムや、スプレッドシートのようにＯＳを一旦止めて更新が可能なアプリケーションもあるが、オンライン機器、制御用機器組み込みのアプリケーションであると、いったんのＯＳ等のベーシック側を停止することが望ましくない場合がある。
【００１４】
図１は本発明の実施の形態１におけるプログラムの階層を説明する図である。図において新規な要素は、コアクラスとそれに搭載されるクラスのロードと起動を行うベースクラス１８と、それに搭載し、コアクラス１６及びアプリケーション・クラス・ローダ１７等をＯＳの動作中にＯＳに代わってロードする代替コアクラス・ローダである。その他の要素として、１１はデバイス本体、１２は端末、１３はデバイス本体１１と端末１２が接続されているネットワーク、１４はデバイス本体１１上で動作するアプリケーション、１５はアプリケーション１４の機能を実現するためのアプリケーション・クラス、１６はアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラス（図示しない）の管理、交換およびアプリケーション・クラス１５への処理の開始を要求するコアクラス、１７はアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスのロードを行うアプリケーション・クラス・ローダ、２０はプラットフォームとしてのJavaVM、２１は各種クラス（ベースクラス１８および代替コアクラス・ローダ１９以外は図示しない）のロードを行うベースクラス・ローダである。本システムではプラットフォームとしてJavaを想定した場合について記述するが、同じ動作をする他のプラットフォームを使用してもよい。
【００１５】
なお、具体的にアプリケーション・クラスを交換する場合の例として以下がある。アプリケーションの交換の場合にはデバイスの種類に対応するので、例えば、
１−１）監視カメラ的には縦、横への方向変化およびズームなどができるが、交換前の監視カメラ用制御アプリケーションではズーム機能しかサポートしていないような場合、このアプリケーションを交換することによって縦、横への方向変更機能を追加する。（デバイスの機能にアプリケーションが追いついていない場合）。また、今までは監視カメラの映像は監視カメラ用制御アプリケーションで圧縮率の低い方式で圧縮して配信していたが、このアプリケーションを圧縮率の高い方式で圧縮できるアプリケーションと交換することによって監視カメラの映像をビットレートを変えることなしに品質よく配信できる、または同じ品質の映像を低ビットレートで配信することができるようになる（デバイスの機能とは関係しない）。
１−２）冷蔵庫用制御アプリケーションの温度調整機能の部分をより効率よく行うことができるものに交換する。
１−３）自販機制御用アプリケーションで、今までは端末側から自販機にアクセスすることによって、情報がとれるようになっていたが、自販機側から端末に通知できる機能を追加したアプリケーションに変更することによって、例えば、商品がなくなりそうな場合にそのことを通知したり、釣銭が切れた場合や、その日の売り上げなどを通知できるようになる。
【００１６】
また、コアクラスを変換する場合の例として以下がある。
２−１）今まではアプリケーション・クラスをロードする際には、一度デバイスにクラスのファイルをダウンロードしてから交換を行っていたが、コアクラスのバージョンアップと交換により、ネットワークを通して直接クラスをロードできるようになれば、デバイスではクラスのファイルを格納しておく分のリソースを節約できる。
２−２）アプリケーション・クラスの管理方式を変更したコアクラスのバージョンアップを行う。
【００１７】
以下、図２を用いてアプリケーション１４が起動するまでの処理について説明する。
まず、アプリケーション１４を起動させるために、プラットフォームとしてのJavaVM２０がシステムクラス・ローダ２１を使用して、ベースクラス１８をロードする。またベースクラス１８で使用されている代替コアクラス・ローダ１９もロードする。さらにベースクラス１８の起動用メソッドを呼び出し、アプリケーション１４を起動させる（ステップＳ１、以下ステップを省略）。この処理はJavaVM２０内で行われている処理なので、プラットフォーム依存であるが、概要的には上述した処理が行われる。
【００１８】
ベースクラス・ローダ２１でロードされたクラスはJavaVM２０を再起動しない限り再ロードされることはないので、ベースクラス・ローダ２１でロードされたクラスは動的には交換を行うことができない。しかし、ベースクラス１８の機能は自分自身の交換を行わなくても良いように、図３に示すように単純な機能しかない。図３は、図１のJavaVM２０とコアクラス１６の間に新しく設けた単純機能のベースクラス１８と代替コアクラス・ローダの具体構成を示す図である。特にＳ４１、Ｓ４３と、Ｓ４５、Ｓ４６の処理を組み込んだ部分が重要である。この例ではコアクラス１６およびコアクラス１６で使用されるクラスのロードとコアクラス１６への処理の開始要求のみを行う。また、デバイスのＯＳに代ってアプリケーション１４からのアプリケーション更新要求を受ける機能を持つが、この説明は後に更新動作で説明する。
次に、JavaVM２０によって起動されたベースクラス１８は、代替コアクラス・ローダ１９のインスタンスを作成し（Ｓ２）、これを使用して、コアクラス１６およびコアクラス１６で使用されるクラスのロードを行う（Ｓ３）。この例ではコアクラス１６で使用されるクラスは、アプリケーション・クラス・ローダ１７のみである。上記新規要素を構成することで、Ｓ２とＳ３のステップが余分にいることになるが、これは後の更新動作のために有効なステップとなる。
【００１９】
以下にコアクラス１６とコアクラスで使用されるクラスのロード処理について、Ｓ３の詳細を図４を用いて説明する。ベースクラスのロード処理については、プラットフォーム依存なので、ここではプラットフォームとしてJavaを使用した場合のベースクラスのロード処理について説明する。
まず、代替コアクラス・ローダ１９がコアクラス１６のバイトコードを取り出す際、バイトコードをローカルから取り出すのか、それともリモートから取り出すのかを決定する（Ｓ４）。ローカルかリモートかを判断する方法としては、クラス名はアプリケーション側で指定することができるので、例えば、リモートにあるWebサーバからバイトコードを取り出すような場合、ロードするクラス名を“http://ホスト名/クラス名”のように指定することによって行うことができる。ロードされるバイトコードは実際には“クラス名.class“というファイル名であるので、取り出す際には”http://ホスト名/クラス名“の最後に”.class“を付けたURLで、目的とするバイトコードを提供するWebサーバに要求することによって行う。この場合上記URLでバイトコードを取れるようにバイトコードを提供するWebサーバを設定しておく必要がある。
【００２０】
次に代替コアクラス・ローダ１９は既にバージョンアップされたデータがローカルのバッファにファイルとして取り込まれている場合には、そのローカルにあるファイルから（Ｓ５）、オンラインでリモートから取り出す場合は、上述したようにHTTPを使用してネットワーク経由でWebサーバからバイトコードを取り出す（Ｓ６）。ここでリモートからの取り出しの場合にはURLからクラス名の部分を取り出しておく（Ｓ７）。
次に、先ほど取り出したバイトコードをJavaVM２０で用意されているメソッドを使用してクラスに変換し（Ｓ８）、これを、クラス名をキーとして格納し（Ｓ９）、このクラスを要求もとに返す（Ｓ１０）。これでＳ３は終了する。
【００２１】
なお、格納しておいたクラスは、同じクラスに対して要求があった場合に、もう一度バイトコードの取り出しを行うことなしにクラスを返すために使用する。これらの処理はリモートからバイトコードを取り出す際にクラス名の前に“http://ホスト名/”を付けて代替コアクラス・ローダ１９に要求する以外は、Javaで通常用いられる方法で行うことが出来る。
さらに、JavaVM２０で用意されているバイトコードをクラスにするメソッドを使用した際に、そのクラスで使用されるクラスのロードが要求されるので、上述した方法と同じようにクラスのロードを行う。ただし、このロード要求はJavaVM２０から要求されるので、クラス名の前にに“http://ホスト名/”が付けられて指定されることはない。このため取り出すべきバイトコードがローカルにあるのかリモートにあるのかを判断することができないので、今までにリモートから取り出したバイトコードがあるかをチェックし（Ｓ１１）、ある場合には、このリモートの位置からバイトコードの取り出しを試みる。ここで取り出しに成功したかのチェックを行い（Ｓ１２）、もし取り出しに失敗した場合にはローカルからバイトコードの取り出しを行う。
この処理をクラスの中で他のクラスが呼ばれなくなるまで繰り返す。以上のようにクラスのロード処理を行う。なおこの処理は以後に記述されるクラスロードにおいても同じ処理を行う。
【００２２】
次に、図２に戻り、ベースクラス１８はコアクラス１６のインスタンスを作成し、この作成したインスタンスに対してコアクラス１６で定義されている処理開始用メソッドを呼び出す（Ｓ１３）。この後、ベースクラス１８はコアクラス１６への処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。
ベースクラス１８では代替コアクラス・ローダ１９でコアクラス１６およびコアクラス１６で使用されるクラスをロードしたことにより、代替コアクラス・ローダ１９でロードされたこれらのクラスは代替コアクラス・ローダ１９のインスタンスを再生成して、再ロードされることにより、クラスの交換が可能になる。クラスの再ロードは上述したクラスのロード処理と同じ方法で行う。
次に、ベースクラス１８によって開始されたコアクラス１６は、アプリケーション・クラス・ローダ１７のインスタンスを作成し（Ｓ１４）、これを使用して、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスのロードを行う（Ｓ１５）。ロード処理については代替コアクラス・ローダ１９での処理と同様である。
【００２３】
次に、コアクラス１６はアプリケーション・クラス１５のインスタンスを作成し、この作成したインスタンスに対してアプリケーション・クラス１５で定義されている処理開始用メソッドを呼び出す（Ｓ１６）。このメソッド呼び出しの際にパラメータとしてコアクラス１６自身を設定しておく。これはコアクラス１６およびコアクラス１６で使用されるクラスのクラス交換要求をアプリケーション・クラス１５から受け取るためである。この後、コアクラス１６はアプリケーション・クラス１５の処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。コアクラス１６ではアプリケーション・クラス・ローダ１７でアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスをロードしたことにより、アプリケーション・クラス・ローダ１７でロードされたこれらのクラスはアプリケーション・クラス・ローダ１７のインスタンスを再生成して、再ロードされることにより、クラスの交換が可能になる。クラスの再ロードは上述したクラスのロード処理と同じ方法で行う。
次に、コアクラス１６によって開始されたアプリケーション・クラス１５はアプリケーション１４で提供する機能の処理を行う。この処理に関してはここでは関係ないので省略する。
【００２４】
以上がアプリケーション１４の立ち上げまでの処理であり、以下に図５を用いて、重要であるＯＳ動作を止めないで行えるクラス交換処理について説明する。アプリケーション１４で監視していて、モジュールの交換要求があると、その内容によりアプリケーション・クラスの交換であれば図２のＳ１４へ、コアクラスの交換であればＳ２へ割り込んで、以後の交換動作を行う。
クラスの交換は上述したように、アプリケーション・クラス・ローダ１７でロードされたアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスと代替コアクラス・ローダ１９でロードされたコアクラス１６およびコアクラス１６で使用されるクラスに対して行うことができる。そして、コアクラス１６レベルの交換であっても、上述のパラメータ設定をしてコアクラス１６がアプリケーション・クラス１５から受け取り、プラットフォームではなくてベースクラス１８に伝えることで、ベースクラス１８の起動がかかる。すなわち、新規に挿入したベースクラス１８と代替コアクラス・ローダ１９がＯＳに代わる交換動作を行うことになる。
【００２５】
図６にアプリケーション・クラスの詳細な構成例を示す。図６において、２２は端末１２からの要求を受け取るための要求受付部、２３は要求受付部２２で受け取った端末１２からの要求がどのような要求であるかを調査する要求調査部、２４は要求調査部２３の調査から得られた要求に応じたサービスの実行と現在実行されているサービス数の管理等を行うサービス実行管理部、２５は端末１２からの要求に応じたサービスを行う各種サービス、２６はクラスの交換処理を行うサービスであるクラス交換サービス、２７はクラス交換要求がどのようなクラス交換であるかを調査するためのクラス交換要求調査部、２８はクラス交換要求のパラメータに新しいクラスのバイトコードが含まれていた場合に、このバイトコードをローカルにある古いバイトコードに上書きするバイトコード保存部、２９は端末１２への応答を返すための応答部、３０はアプリケーション・クラス１５またはコアクラス１６にクラスの再ロードを要求するためにクラス再ロード要求を出すためのクラス再ロード要求部、３１はクラス再ロード要求を受け取り、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの再ロードのための処理を行うアプリケーション・クラス再ロード処理部である。
【００２６】
まず、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスを交換する場合について説明する。
アプリケーション・クラス１５は、端末１２からの要求を要求受付部２２を使用して待っている（Ｓ１７）。次に、端末１２から要求が送られてきたら、この要求を要求調査部２３で調査する（Ｓ１８）。ここで端末１２がWebブラウザであり、アプリケーション１４がWebサーバであった場合には、端末１２からの要求としては図７のようになり、メソッドとリクエストURIを調査することによってどのサービスが要求されているのかを選択することができる。例えばメソッドが“GET”で、リクエストURIが“/default.html”であった場合は、Webサーバ上のルートにある“default.html”というファイルの内容を返すサービスであるし、またメソッドに“POST”、リクエストURIに“/servlet/ExchangeClass”と設定することによってクラスの交換要求であるとすることができる。もちろん上記以外の方法でリクエストを設定してもよい。
次に、サービス実行管理部２４では、要求調査部２３で上述したような調査から得られた要求に応じたサービスを実行する。サービスに関してはCGIプログラムであってもよいし、サーブレットであってもかまわなく、サービスが実行できるようなものであればどのようなものでもかまわない。
【００２７】
この場合は要求としてクラス交換要求を想定しているので、クラス交換サービス２６を開始させる（Ｓ１９）。
次に、クラス交換サービス２６ではクラス交換要求調査部２７を使用して、さらにこのクラス交換要求がアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの交換であるか、またはコアクラス１６およびコアクラス１６で使用されるクラスの交換であるかを調査する（Ｓ２０）。調査方法としては上述したように端末からの要求がHTTP要求であるような場合には、例えばアプリケーション・クラス１５の交換であれば、リクエストURIの部分を“/servlet/ExchangeApplicationClass”とし、またコアクラス１６の交換であれば“/servlet/ExchangeCoreClass”というように設定することによって行うことができる。ここでは、調査した結果がアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの交換であるとする。
次に、交換を行うクラスがローカルに存在するクラスである場合は、クラス交換要求にパラメータとして交換するクラスの新しいバイトコードを添付しておく。これも端末１２からの要求がHTTP要求である場合には、バイトコードをエンティティボディの部分に設定する。
【００２８】
次に、クラス交換サービス２６では、この新しいバイトコードを、バイトコード保存部２８を使用し、ローカルに存在する古いバイトコードに上書きする（Ｓ２１）。
一方、交換するクラスがリモートに位置するクラスである場合には、クラスの交換を行いたいユーザが、リモートに位置する古いバイトコードを新しいバイトコードで上書きしておき、パラメータなしでクラス交換要求を出す。
次に、クラス交換サービス２６では、応答部２９で端末１２に応答を返す（Ｓ２２）。上述したように、端末１２との通信にHTTPを使用している場合には図８に示す応答を返す。例えばこれまでの処理に成功していて、これからクラスの交換を行うような場合には、ステータスコードに“200”、ヘッダに“Content-Type:text/plain”、メッセージボディに“これからクラス交換を行います。”などを設定して、端末１２に送る。
次に、クラス交換サービス２６ではクラス再ロード要求部３０を使用し、アプリケーション・クラス１５にクラス再ロード要求を出し、自分自身の処理を終了させる。クラス再ロード要求としては、ただ単にメソッドの呼び出しでもかまわないし、他の方法を使用してもかまわない。ここではメソッド呼び出しとする。
次に、アプリケーション・クラス１５では、アプリケーション・クラス再ロード処理部３１で、このクラス再ロード要求を受け取る。上述したようにクラス再ロード要求がメソッドの呼び出しである場合は、アプリケーション・クラス再ロード処理部がこのメソッドになる。
【００２９】
次に、アプリケーション・クラス１５では、要求受付部２２で行っている端末１２からの要求受付を停止するよう要求受付部２２に要求する（Ｓ２３）。この要求もただ単にメソッド呼び出しでもよいし、他の方法を使用してもよい。
次に、要求受付部２３では停止要求に基づき、端末１２からの要求受付を停止する。停止する方法としてはただ単に要求を待つループを抜けるだけで行うこともできるし、他の方法で停止してもよい。
次に、アプリケーション・クラス１５では、サービス実行管理部２４を使用して現在アプリケーション・クラス１５上で動作している他のサービス２５がある場合には、このサービスが終了するのを待つ（Ｓ２４）。上述したように、アプリケーション１４がWebサーバである場合には、サービス２５は端末１２に応答を返した後にサービスが終了する。
次に、実行中のアプリケーションのサービス２５が全て終了したら、アプリケーション・クラス１５は、自分自身の処理を終了させる。
【００３０】
コアクラス１６ではアプリケーション・クラス１５の処理開始用メソッドを呼び出した後、このメソッド呼び出しに対する応答が返ってくるのを待ち続けているため、アプリケーション・クラス１５の処理が終了した場合、コアクラス１６に制御が返ってくる。
次に、コアクラス１６では、後述するコアクラス終了フラグをチェックし（Ｓ２６）、このフラグが立っていなければ、アプリケーション・クラス・ローダ１７のインスタンスを再生成して、この新たに作成したアプリケーション・クラス・ローダ１７のインスタンスを使用して、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスのロードを行う。
もしコアクラス終了フラグが立っていた場合の処理については、後述するコアクラス１６およびコアクラス１６で使用されるクラスの交換で説明する。
そして、アプリケーション１４の起動処理と同様に、コアクラス１６で、アプリケーション・クラス１５のインスタンスを作成し、この作成したインスタンスに対して、アプリケーション・クラス１５で定義されている処理開始用メソッドを呼び出し、また処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。このようにしてアプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスの交換を行う。
【００３１】
次に、もう１つの重要な動作であるコアクラス１６およびコアクラス１６で使用されるクラスを交換する場合について説明する。
各処理に関しては特に記述がない限り、アプリケーション・クラス１５およびアプリケーション・クラス１５で使用されるクラスを交換する場合で説明した方法と同じである。
まず、アプリケーション・クラス１５は、端末１２からの要求を要求受付部２２を使用して待っている（Ｓ１７）。端末１２から要求が送られてきたら、要求調査部２３で調査する（Ｓ１８）。
次に、サービス実行管理部２４では、この場合は要求としてクラス交換要求であるので、クラス交換サービス２６を開始させる（Ｓ１９）。
次に、クラス交換サービス２６ではクラス交換要求調査部２７を使用して、アプリケーション・クラス１５レベルの交換であるか、またはコアクラス１６およびコアクラス１６で使用されるクラスの交換であるかを調査する（Ｓ２０）。ここでは、調査した結果がコアクラス１６およびコアクラス１６で使用されるクラスの交換であるとする。
次に、交換を行うクラスがローカルに存在するクラスである場合は、クラス交換要求にパラメータとして交換するクラスの新しいバイトコードを添付しておき、クラス交換サービス２６では、この新しいバイトコードを、ローカルに存在する古いバイトコードに上書きする（Ｓ２１）。交換するクラスがリモートに位置するクラスである場合には、ユーザがリモートに位置する古いバイトコードを新しいバイトコードで上書きしておき、パラメータなしでクラス交換要求を出す。クラス交換サービス２６では、応答部２９で端末１２に応答を返した後（Ｓ２２）、上述のアプリケーション・クラス１５レベルの交換と同様、自分自身の処理を終了させる。
【００３２】
図９にコアクラス１６の構成を示す。図９において、３２はクラス再ロード要求を受け取り、コアクラス１６およびコアクラス１６で使用されるクラスの再ロードのための処理を行うコアクラス再ロード処理部、３３はアプリケーション・クラス１５にクラスの再ロードを要求するためにクラス再ロード要求を出すためのアプリケーション・クラス再ロード要求部である。
コアクラス１６では、コアクラス再ロード処理部３２で、クラス再ロード要求を受け取る。上述したようにクラス再ロード要求がメソッド呼び出しであった場合は、コアクラス再ロード処理部がこのメソッドになる。
次に、コアクラス１６では、アプリケーション・クラス１５が終了した際に、コアクラス１６自身も終了するようにコアクラス終了フラグを立てる（Ｓ２５）。
次に、コアクラス１６では、アプリケーション・クラス再ロード要求部３３を使用してアプリケーション・クラス１５にクラスの再ロード要求を送る。上述したようにクラス再ロード要求としては、ただ単にメソッドの呼び出してもかまわないし、他の方法を使用してもかまわない。ここではメソッド呼び出しとする。
次に、アプリケーション・クラス１５では、アプリケーション・クラス再ロード処理部３１で、このクラス再ロード要求を受け取る。そして端末１２からの要求受付を停止するよう要求受付部２２に要求し（Ｓ２３）、現在アプリケーション・クラス１５上で動作している他のサービス２５がある場合には、このサービスが終了するのを待つ（Ｓ２４）。更に実行中のアプリケーションのサービス２５が全て終了したら、アプリケーション・クラス１５は、自分自身の処理を終了させる。
【００３３】
コアクラス１６では、アプリケーション・クラス１５の処理開始用メソッドを呼び出した後、このメソッド呼び出しに対する応答が返ってくるのを待ち続けているため、アプリケーション・クラス１５の処理が終了した場合、コアクラス１６に制御が返ってくる。
次に、コアクラス１６では、コアクラス終了フラグが立っているかをチェックする（Ｓ２６）。この場合上述したようにコアクラス再ロード処理部３２でコアクラス終了フラグを立てているので、コアクラス１６自身の処理を終了させる。
ベースクラス１８では、コアクラス１６の処理開始用メソッドを呼び出した後、このメソッド呼び出しに対する応答が返ってくるのを待ち続けているため、コアクラス１６の処理が終了した場合、ベースクラス１８に制御が返ってくる。即ちＳ２６のチェックにより図２のＳ２に戻ることになる。
そこで、もう１つの重要な動作であるベースクラス１８では、代替コアクラス・ローダ１９のインスタンスを再生成して、Ｓ３でこの新たに作成した代替コアクラス・ローダ１９のインスタンスを使用して、コアクラス１６およびコアクラス１６で使用されるクラスのロードを行う。そして、アプリケーション１４の起動処理と同様にコアクラス１６のインスタンスを作成し、この作成したインスタンスに対して、コアクラス１６で定義されている処理開始用メソッドを呼び出し、また処理開始用メソッド呼び出しに対する応答が返ってくるのを待ち続ける。
さらにコアクラス１６で上述したアプリケーション１４の立ち上げ時と同じ処理を行い、アプリケーション・クラス１５を開始させる。このようにしてコアクラス１６およびコアクラス１６で使用されるクラスの交換を行う。
以上のような方式により、コアクラス１６およびコアクラス１６で使用されるクラスの交換が行えるようになり、デバイス１１上のアプリケーション１４の機能を構成するクラスの全ての交換が可能になる。
【００３４】
【発明の効果】
以上のようにこの発明によれば、アプリケーション側からの交換要求を受けて新規モジュールを交換する代替コアクラス・ローダ、ベースクラスを備えたので、ＯＳを止めないでも、プラットフォーム側に代わってコアクラスまたはアプリケーション・クラスを交換できる効果がある。
【図面の簡単な説明】
【図１】 本発明の実施の形態１におけるプログラム構造を示す図である。
【図２】 実施の形態１におけるアプリケーション起動までの動作フロー図である。
【図３】 実施の形態１におけるベースクラスの内容の具体例を示す図である。
【図４】 図２におけるＳ３の詳細動作フロー図である。
【図５】 実施の形態１におけるモジュールの交換要求に基づく動作を示すフロー図である。
【図６】 アプリケーション・クラスの詳細構成例を示す図である。
【図７】 実施の形態１における端末からの交換要求のフォーマット例を示す図である。
【図８】 実施の形態１における交換要求に対する端末への応答フォーマット例を示す図である。
【図９】 コアクラスの構成例を示す図である。
【図１０】 従来のモジュール交換を行う装置構成を示す図である。
【符号の説明】
１１ デバイス、１２ 端末、１３ ネットワーク、１４ アプリケーション、１５ アプリケーション・クラス、１６ コアクラス、１７ アプリケーション・クラス・ローダ、１８ ベースクラス、１９ 代替コアクラス・ローダ、２０ ＪａｖａＶＭ（プラットフォーム）、２１ ベースクラス・ローダ、２２ 要求受付部、２３ 要求調査部、２４ サービス実行管理部、２５ 各種サービス、２６ クラス交換サービス、２７ クラス交換要求調査部、２８ バイトコード保存部、２９ 応答部、３０ クラス再ロード部、３１ アプリケーション・クラス再ロード部、３２ コアクラス再ロード処理部、３３ アプリケーション・クラス再ロード要求部、Ｓ２ コアクラス・ローダのインスタンスの作成ステップ、Ｓ３ コアクラスとコアクラスで使用するクラスのロードステップ、Ｓ１３コアクラスのインスタンスの生成と開始指示ステップ、Ｓ１４ アプリケーション・クラス・ローダのインスタンス生成ステップ、Ｓ１５ アプリケーション・クラスとアプリケーション・クラスで使用するクラスのロードステップ、Ｓ１６ アプリケーション・クラスのインスタンス生成と開始指示ステップ、Ｓ１８ 端末からの要求調査ステップ、Ｓ１８ｂ クラス交換の要求かの判断ステップ、Ｓ２０ｂ コアクラス交換かの判断ステップ。
Claims (5)
- ネットワーク接続デバイスの内部に記憶されて動作するアプリケーション・プログラムであって、該アプリケーション・プログラムは、コンピュータ・システムの基盤となるソフトウェアであるプラットホームにより起動されるアプリケーション・プログラムであり、該アプリケーション・プログラムは、
１）アプリケーションの機能を実現するソフトウェアであるアプリケーション・クラス・プログラムと、
２）上記アプリケーション・クラス・プログラムをロードするアプリケーション・クラス・ローダを中に含んで、上記アプリケーションの機能に依存しない共通的な機能を実現するソフトウェアであるコアクラス・プログラムと、
３）上記コアクラス・プログラムをロードする代替コアクラス・ローダを中に含んで、上記プラットホームの起動と共にプロットホームによりロードされて起動されるベースクラス・プログラムと、を含み、
上記ベースクラス・プログラムに含まれる代替コアクラス・ローダは、上記プラットホームが動作中に、上記コアクラス・プログラムの更新要求を受付け、更新されたコアクラス・プログラムをロードすることを特徴とするソフトウェア・モジュール動的交換方法。 - アプリケーション・クラス・プログラムと、コアクラス・プログラムとの更新要求があると、該アプリケーション・クラス・プログラムの更新をアプリケーション・クラス・ローダによるロードで行い、上記コアクラス・プログラムの更新を代替コアクラス・ローダによるロードで行うことを特徴とする請求項１記載のソフトウェア・モジュール動的交換方法。
- コアクラス・プログラムの更新要求が、ネットワークに接続されたリモートの装置からの更新されたコアクラス・プログラムで更新する要求であると、代替コアクラス・ローダは、該指定されたリモートの装置から該当する上記更新されたコアクラス・プログラムを得ることを特徴とする請求項１記載のソフトウェア・モジュール動的交換方法。
- アプリケーション・クラス・プログラムは、該アプリケーション・クラス・プログラムを構成するモジュール・プログラムの更新要求を調査する要求調査部のプログラムを含み、該要求調査部のプログラムは、更新要求されたモジュール・プログラムに対応するプログラムの更新を行うことを特徴とする請求項１記載のソフトウェア・モジュール動的交換方法。
- ネットワーク接続デバイスの内部に記憶されて動作するアプリケーション・プログラムであって、該アプリケーション・プログラムは、コンピュータ・システムの基盤となるソフトウェアであるプラットホームにより起動されるアプリケーション・プログラムであり、該アプリケーション・プログラムは、
１）アプリケーションの機能を実現するソフトウェアであるアプリケーション・クラス・プログラムと、
２）上記アプリケーション・クラス・プログラムをロードするアプリケーション・クラス・ローダを中に含んで、上記アプリケーションの機能に依存しない共通的な機能を実現するソフトウェアであるコアクラス・プログラムと、
３）上記コアクラス・プログラムをロードする代替コアクラス・ローダを中に含んで、上記プラットホームの起動と共にプラットホームによりロードされて起動されるベースクラス・プログラムと、を含み、
上記ベースクラス・プログラムに含まれる代替コアクラス・ローダは、上記プラットホームが動作中に、上記コアクラス・プログラムの更新要求を受付け、更新されたコアクラス・プログラムをロードする機能を持ち、
上記アプリケーション・プログラムを、計算機の入力装置が読取り、計算機が実行可能なプログラムとして記録したソフトウェア・モジュール動的交換プログラム記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000011473A JP3986721B2 (ja) | 2000-01-20 | 2000-01-20 | ソフトウェア・モジュール動的交換方法及びソフトウェア・モジュール動的交換プログラム記録媒体 |
| US09/635,795 US6675381B1 (en) | 2000-01-20 | 2000-08-11 | Software-module dynamic loader, a software-module dynamic loading method and a medium storing the software-module dynamic loading method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000011473A JP3986721B2 (ja) | 2000-01-20 | 2000-01-20 | ソフトウェア・モジュール動的交換方法及びソフトウェア・モジュール動的交換プログラム記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001202248A JP2001202248A (ja) | 2001-07-27 |
| JP3986721B2 true JP3986721B2 (ja) | 2007-10-03 |
Family
ID=18539328
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000011473A Expired - Lifetime JP3986721B2 (ja) | 2000-01-20 | 2000-01-20 | ソフトウェア・モジュール動的交換方法及びソフトウェア・モジュール動的交換プログラム記録媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6675381B1 (ja) |
| JP (1) | JP3986721B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7281047B2 (en) * | 2001-01-16 | 2007-10-09 | Cognos Incorporated | System and method for automatic provision of an application |
| US20020147971A1 (en) * | 2001-02-15 | 2002-10-10 | Adams James Andrew | Object-oriented class loading system and method |
| US6971001B1 (en) * | 2001-05-17 | 2005-11-29 | Accenture Global Services Gmbh | General and reusable components for defining net-centric application program architectures |
| US7073171B2 (en) * | 2003-02-28 | 2006-07-04 | Bea Systems, Inc. | EJB implementation class loading with removed dependencies with ability to replace EJB implementation class without full redeployment |
| DE10335989B4 (de) * | 2003-08-01 | 2019-07-11 | Kw-Software Gmbh | Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung |
| US7587708B2 (en) * | 2004-07-20 | 2009-09-08 | International Business Machines Corporation | Method for testing converted source code |
| US7930693B2 (en) * | 2005-04-04 | 2011-04-19 | Cisco Technology, Inc. | Method and system for accessing and launching a java based applet as a locally installed application |
| US7765537B2 (en) * | 2005-11-21 | 2010-07-27 | International Business Machines Corporation | Profiling interface assisted class loading for byte code instrumented logic |
| JP4467624B2 (ja) | 2008-03-24 | 2010-05-26 | 富士通株式会社 | ソフトウェアアップデート管理プログラム、ソフトウェアアップデート管理装置、およびソフトウェアアップデート管理方法 |
| CN103077033B (zh) * | 2012-08-20 | 2016-08-24 | 南京南瑞继保电气有限公司 | 一种优化组态系统 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09292980A (ja) | 1996-04-25 | 1997-11-11 | N T T Data Tsushin Kk | ファイル配布システム |
| US6175855B1 (en) * | 1996-12-20 | 2001-01-16 | Siemens Aktiengesellschaft | Method for instantiating a class having different versions |
| US5974428A (en) * | 1997-08-29 | 1999-10-26 | International Business Machines Corporation | Method and apparatus for class version naming and mapping |
| JPH11145174A (ja) | 1997-11-10 | 1999-05-28 | Sony Corp | 半導体装置およびその製造方法 |
| US6496871B1 (en) * | 1998-06-30 | 2002-12-17 | Nec Research Institute, Inc. | Distributed agent software system and method having enhanced process mobility and communication in a computer network |
| US6279030B1 (en) * | 1998-11-12 | 2001-08-21 | International Business Machines Corporation | Dynamic JAVA™ class selection and download based on changeable attributes |
| CA2255042C (en) * | 1998-11-30 | 2004-04-13 | Leonard W. Theivendra | Class loader |
| US6272674B1 (en) * | 1998-12-14 | 2001-08-07 | Nortel Networks Limited | Method and apparatus for loading a Java application program |
| US6507946B2 (en) * | 1999-06-11 | 2003-01-14 | International Business Machines Corporation | Process and system for Java virtual method invocation |
-
2000
- 2000-01-20 JP JP2000011473A patent/JP3986721B2/ja not_active Expired - Lifetime
- 2000-08-11 US US09/635,795 patent/US6675381B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6675381B1 (en) | 2004-01-06 |
| JP2001202248A (ja) | 2001-07-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8015560B2 (en) | Apparatus and method for managing application in incorporated equipment | |
| CN102279765B (zh) | 预编译托存托管代码 | |
| US8458727B2 (en) | Asynchronous client to server updates | |
| JP5052955B2 (ja) | アプリケーションの高可用運用方法、オンラインバージョン変更方法及び計算機システム | |
| CA2605120C (en) | Method and system for hosting and executing a component application | |
| US6871223B2 (en) | System and method for agent reporting in to server | |
| US8307058B2 (en) | Apparatus, method, and computer program product for processing information | |
| EP2328088A1 (en) | Home network system, gateway device, and firmware update method | |
| EP1669866A2 (en) | Management method for managing software module and information processor | |
| JP2008269323A (ja) | 情報処理装置、配信方法、その方法を実行する制御プログラム | |
| JP3986721B2 (ja) | ソフトウェア・モジュール動的交換方法及びソフトウェア・モジュール動的交換プログラム記録媒体 | |
| WO2011060735A1 (zh) | 微件Widget调用的方法、装置和系统 | |
| US20090138548A1 (en) | Apparatus, method, and computer program product for processing information | |
| JP2003022189A (ja) | 分散ネットワークコンピューティングシステム | |
| KR101482149B1 (ko) | 어플리케이션 실행 장치, 그 방법 및 그 방법이 기록된 컴퓨터로 판독 가능한 기록 매체 | |
| JPH1021060A (ja) | プログラム自動更新処理機能を有する通信システムおよびプログラム更新処理を実行するプログラムを備えた記録媒体 | |
| US7860987B2 (en) | Apparatus for providing service in response to user request and method therefor | |
| JP2009020609A (ja) | 画像形成装置、プログラム制御方法及びプログラム | |
| CN109597659A (zh) | 图像形成设备及其控制方法 | |
| JP4976329B2 (ja) | 追加プログラムを実行可能な装置、障害解析支援方法、及び障害解析支援プログラム | |
| JP2002095071A (ja) | ネットワークシステム及び機器制御方法 | |
| JP4738556B2 (ja) | 分散運用システムおよび記録媒体 | |
| JP2019070884A (ja) | 情報処理装置 | |
| JP2012212462A (ja) | アプリケーションの高可用運用方法、オンラインバージョン変更方法及び計算機システム | |
| KR101460515B1 (ko) | 어플리케이션 실행 장치, 그 방법 및 그 방법이 기록된 컴퓨터로 판독 가능한 기록 매체 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040514 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040608 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20041018 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061220 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070123 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070312 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070417 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070608 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070710 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070711 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100720 Year of fee payment: 3 |