JP3689368B2

JP3689368B2 - Method of loading an application into a multi-application embedded system with data processing resources, corresponding system and execution method

Info

Publication number: JP3689368B2
Application number: JP2001539111A
Authority: JP
Inventors: ゴワール，クリスチヤン; ビヨン，ジヤン−ポール
Original assignee: ブル・セー・ペー・８
Priority date: 1999-11-17
Filing date: 2000-11-17
Publication date: 2005-08-31
Anticipated expiration: 2020-11-17
Also published as: FR2801118B1; BR0007569A; CN1341238A; CA2360431A1; HK1042151A1; HK1042151B; CN1162775C; FR2801118A1; US6983460B1; AR034105A1; JP2003515215A; WO2001037085A1; EP1147467A1

Description

【０００１】
本発明は、データ処理リソースを備えたマルチアプリケーション組込システムにアプリケーションをローディングする方法、対応する組込システム、および、対応する組込システムのアプリケーション実行方法に関する。
【０００２】
本発明は、特に、中間擬似コードと、関連する仮想マシンとを使用する、マルチアプリケーション携帯オブジェクトに組込されるシステムで、同じメモリスペースを共有するモジュール間の分離（ＰＡＲＥ−ＦＥＵ）の実施に関する。
【０００３】
「Ｓｕｎ」社により導入された「Ｊａｖａ」（商標）技術は、「Ｊａｖａ」オブジェクトと関連仮想マシンとに向けられたプログラミング言語に基づいたものである。この技術は、パワーＣＰＵと、メガバイト単位の大型メモリとを有する局またはＰＣ（パーソナル・コンピュータ）（以下、「Ｊａｖａ」プラットフォームとする）で開発された。
【０００４】
数年前から、「Ｊａｖａ」技術の概念が手直しされ、携帯オブジェクトに組込されるシステムで作動するように、たとえばクレジットカード、マイクロプロセッサを組み込んだＳＩＭマイクロモジュール（一般に、チップカードと呼ばれる）、ＧＳＭ（ＧｌｏｂａｌＳｙｓｔｅｍｆｏｒＭｏｂｉｌｅＣｏｍｍｕｎｉｃａｔｉｏｎ）携帯電話、ＰＣＭＣＩＡカード、あるいは他のあらゆる携帯端末のフォーマットに適合されてきた。以下、これらの携帯オブジェクトの任意の一つを示すためにカードという表現を用いることにする。これまではアセンブラとして構成されてきた組込システムのプログラミングは、今後、「Ｊａｖａ」のような高級プログラミング言語で可能となり、クライアントアプリケーションの開発を容易にし、また加速することができる。
【０００５】
携帯オブジェクトの組込システムに固有のこうした新しいタイプのプラットフォーム（以下、特別プラットフォームとする）は、従来のプラットフォームのサブアセンブリである。組込システムの環境を小さくしたことによって相違が生じている。一般に、図４ａに示したように、チップカード（１０）は、マイクロプロセッサ（１４）に接続された入出力システム（１１）と、揮発性のＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）（１２）と、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）（１３）からなる不揮発性メモリ（１５）と、フラッシュＲＡＭまたはＥＥＰＲＯＭ（ＥｌｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅＰｒｏｇｒａｍｍａｂｌｅＲｅａｄＯｎｌｙＭｅｍｏｒｙ）とを含む。これらの素子の集合が、接続ＢＵＳによりマイクロプロセッサに接続される。たとえば、チップカードは、最善の場合、既存の新しいコンポーネントを用いることによって、ＲＯＭと、３２キロバイトのＥＥＰＲＯＭと、２キロバイトのＲＡＭとを含む。
【０００６】
従来の「Ｊａｖａ」システムでは、アプリケーションは、局またはＰＣに書き込まれる。そのソースコードは、使用されているプラットフォームの装置コードとは独立した、「ＪａｖａＢｙｔｅＣｏｄｅ」と呼ばれる中間擬似コードでコンパイルされる。次に、アプリケーションは、ターゲットプラットフォームまたは従来の「Ｊａｖａ」プラットフォームにダウンロードされる。ロードされたアプリケーションは、様々なメソッドを擬似コードにコンパイルしたクラス、いわゆるクライアントクラスの集合からなり、アプリケーションプログラミングインターフェースまたはアプリケーションプログラミング用のインターフェースＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）でサポートされる。アプリケーションプログラミングインターフェースは、ユーザインターフェースを均質化し、エディタ、キーボードまたはプリンタなどを制御することができる。従来のプアラットフォームの仮想マシンは、擬似コードチェッカーと、ダイナミッククラスローダと、装置コードへの翻訳を可能にする擬似コードインタープリタと、セーフティ管理プログラムとを含む。
【０００７】
従来の仮想マシンと組込システムの仮想マシン（以下、特別仮想マシンとする）との主な相違は、組込システムの仮想マシンが、２個の別々の部分に分解されることにある。図４ｂによれば、仮想マシンは、コンバータ（３２）を含んで、オフプラットフォーム（「ｏｆｆ−ｐｌａｔｆｏｒｍ」）の仮想マシンと呼ばれる、特別プラットフォーム（４０）外の部分（３０）と、擬似コードインタープリタを含んで、組込（「ｏｎ−ｐｌａｔｆｏｒｍ」）仮想マシン（４１）と呼ばれる、特別プラットフォーム（４０）を構成するカード内の部分（４１）とを含む。
【０００８】
かくして、特別プラットフォームの場合、アプリケーションのソースプログラム（２１）は、書き込まれ、コンパイラ（２２）により中間擬似コードとしてコンパイルされ、中間擬似コードのチェッカー（３１）により従来の局（２０）でチェックされてから、同じ局（２０）または別の局に配置されるコンバータ（３２）によりコンバートされる。その後、アプリケーションは、場合によっては、署名装置（３４）を通過した後で、携帯オブジェクトまたは特別プラットフォーム（４０）の揮発性プログラマブルメモリ、場合によってはＥＥＰＲＯＭ（１５）にダウンロードされる。こうしたローディングは、ダウンローダと呼ばれるプラットフォーム外の部分（３３）と、ローダと呼ばれる特別プラットフォームの一部（４２）とを含むローダによって行われる。局用に従来のプラットフォームで存在するものとは異なり、オペレーティングシステム（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）（４８）を備えたＲＯＭに配置される特別プラットフォーム（４０）の仮想マシン（４１）は、中間擬似コードチェッカーを含むことができない。このチェッカーは、携帯オブジェクトにおいて格納およびまたは実行するのに重たすぎるからである。特別プラットフォーム（４０）はまた、ダイナミッククラスローダも含まない。実際、本発明のアプリケーション領域の場合、オフプラットフォームの仮想マシン（３０）で、チェッカー（３１）は、コンパイルされたクラスが適切に形成されているかチェックし、特別プラットフォームの記述に特別な言語侵入があるかどうかチェックする。コンバータ（３２）は、クラスをローディングし、参照を分解するために必要な作業を行う。コンバータは、クラスのスタティックリンキングを実施し、カードに既に存在するクラス、メソッドおよび属性（アトリビュート）へのシンボル参照を解明する。コンバータは、ストレージを配分し、クラスを示すためのデータ構造を生成し、スタティックまたはネイティブのメソッドおよび属性を生成し、スタティック変数を初期化する。
【０００９】
特別プラットフォームの実行環境（ＲｕｎｔｉｍｅＥｎｖｉｒｏｎｍｅｎｔまたはＲＥ）は、インタープリタと、ＡＰＩプラットフォームと、いわゆる固有またはスタティックな関連メソッド（４３）とに限られた、組込仮想マシン（「ｏｎ−ｐｌａｔｆｏｒｍ」）（４１）を含む。ＡＰＩプラットフォームは、システムクラスと呼ばれるクラス（４５）の集合を決定するＡＰＩ（４４）と、アプリケーションが実行環境（ＲＥ）とスタティックメソッド（４３）とにアクセスする呼び出し協定（ＣａｌｌＣｏｎｖｅｎｔｉｏｎ）とを含む。スタティックメソッド（４３）は、カードの入出力暗号メモリの割り当てサービスを実行する。
【００１０】
カード（４１）に組込された（ｏｎ−ｐｌａｔｆｏｒｍ）仮想マシンのインタープリタは、「Ｊａｖａ」言語をサポートする役割をし、中間擬似コードを命令毎に逐次読み込む。こうした中間擬似コードの各標準命令は、インタープリタによりマイクロプロセッサの言語で解釈されてから、マイクロプロセッサにより実行される。一般に、中間擬似コードの標準命令は、演算処理およびオブジェクト操作等の高級プログラミング言語を処理可能にする。オブジェクトの概念は、リスト、データリストまたは同等物等の情報オブジェクトに関する。アプリケーションのいわゆるクライアントクラス（４６）と、ＡＰＩのシステムクラス（４５）とは、全て同じメモリスペースにロードされ、クラステーブル（４７）を介して管理される。
【００１１】
仮想マシン（４１）は、また、クラスおよびオブジェクトを管理して、アプリケーション間の分離を遵守させることにより、属性、変数、またはフィールド（ｆｉｅｌｄｓ）とも呼ばれるデータの安全な共有を可能にする。
【００１２】
チップカードタイプの携帯オブジェクトの場合、特別プラットフォームのアプリケーションは、サービスまたは端末から送信される選択ＡＰＤＵ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）がカードによって受信される場合、実行環境（ＲＥ）により直接作動可能である。
【００１３】
同じメモリスペースを共有するコード部分の間でデータへのアクセスを制限するために、従来のプラットフォームで一般的に行われている方法の一つは、ソースコードで宣言される可視性（ＶＩＳＩＢＩＬＩＴＥ）の明確な制限に基づいている。図４ｃによれば、メソッド（ＮＭ１、ＮＭ２；ＮＭ３、ＮＭ４）と属性（ＮＡ１、ＮＡ２；ＮＡ３、ＮＡ４）とは、それぞれクラス（ＮＣＩ３、ＮＣＩ２）に封入されている。クラスは、それ自体が、それぞれ複数のクラスをまとめたパッケージ（パッケージ１；パッケージｎ）の一部をなす。クラスは、パッケージに対して、（ＮＣＩ１またはＮＣＩ２）のようにパブリック（ｐｕｂｌｉｃ）であっても、（ＮＣＩ３）のようにプライベート（ｐｒｉｖａｔｅ）であってもよく、後者の場合、これは、同じパッケージのクラスだけがこのクラスにアクセス可能であることを意味する。クラス（ＮＣＩ３）のメソッド（例ＮＭ２）およびデータ（例ＮＡ１）は、クラス（ＮＭ２、ＮＡ１）に対してプライベートとすることができ、クラス自体が、パッケージ（パッケージ１）に対してプライベートであり、あるいはパッケージ（たとえばＮＭ１、ＮＡ２）またはクラス（たとえばＮＭ４、ＮＡ４）に対してパブリックである。こうした可視性の制限により、同じ名前空間で保存される様々なパッケージの集合（パッケージ１、パッケージｎ）の間でアクセスをフレキシブルにすることができる。だが、幾つかの欠点がある。従来の、または特別プラットフォームは、サブパッケージの概念を持つことができない。大型アプリケーションのクライアントクラスは、仮想マシンに対してだけは異なるパッケージを示す、様々なサブパッケージの間に配分しなければならない。これらのサブパッケージ間でリソースを共有するには、リソースがパブリックであると必ず宣言されることにより、他のあらゆるパッケージが、リソースを表示できるようにしなければならない。従って、大型アプリケーションに対して異なるアプリケーションのパッケージを明白に組織化し、アプリケーション間の分離を得ることは難しい。
【００１４】
局では、従来のプラットフォームの場合、ソースプログラムで宣言されたような、リソースの守秘性の遵守は、ダイナミックチェックに基づいている。こうしたダイナミックチェックを実行するには、仮想マシンが、各クラス、メソッドまたは属性に対するアクセス制限の宣言に関するあらゆる情報を持っていなければならない。これは、オフプラットフォームの仮想マシンの中間擬似コードまたは予め接続されたバイトコードを使用する組込（ｏｎｐｌａｔｆｏｒｍ）仮想マシンで利用可能なメモリスペースの場合、使用できない。携帯オブジェクトの特別プラットフォームの場合、アクセス制限は、コンパイル時にスタティックにチェック可能であり、オフプラットフォーム部分のチェッカーにより再びチェック可能である。実際、携帯オブジェクトの特別プラットフォームにロードされるものは正しいと仮定される。なぜなら、特別プラットフォームでは、コンバート段階時の情報ロスのために如何なるチェックも実行できないからである。しかも、パッケージが、外部のソースから送られる新しいクラスにより拡張または修正されないようにすることが保証されないので、プライベートパッケージの使用に基づくあらゆる安全性が損なわれる。
【００１５】
従来のプラットフォームの仮想マシンにより得られる第二の手段は、名前空間の分離という概念である。従来のプラットフォームのダイナミックリンキング構成では、クラスは、標準ＡＰＩプラットフォームを形成するシステムクラスの領域を構成するものとして予め宣言された「クラスパス（ＣｌａｓｓＰａｔｈ）」と呼ばれるローカルファイルシステムのディレクトリから、あるいは、ローカルファイルシステムまたは遠隔サーバの他のディレクトリから、ロード可能である。「クラスパス」外部のアプリケーションのクライアントクラスは、特別にプログラムされたクラスローダによりローディングされなければならない。この特徴は、有資格ブラウザ「Ｊａｖａ」によりアプリケーション「Ｊａｖａ」のローディングのために特に使用される。従って、様々なソースから送られるアプリケーションは、異なるクラスローダによりローディングされる。一般にＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）と呼ばれる各ロケータに対して、特別クラスインスタンス「アプリケーションクラスローダ」が使用される。クラスの外部の名称は、「パッケージの名称」＋「クラスの名称」の組み合わせである。クラスがロードされると、内部クラステーブルに保存され、このクラスをロードするために使用されたクラスローダに関する参照が、クラスのパッケージ名の接頭辞に付加される。クラスの名称は、その場合、「クラスローダの参照」＋「パッケージの名称」＋「クラスの名称」となる。かくして、同じパッケージに属していると宣言される一方で異なるクラスローダによりローディングされるクラスを、仮想マシンは、同じパッケージに属するものとして認識しない。
【００１６】
参照の解明時に、クラスローダの通常のやり方は、まずシステムクラスでサーチし、失敗した場合には、ローダがクラスをローディング可能な領域にあるクラスファイルの中をサーチすることである。ローダのこの動作原理によれば、アプリケーションは、異なるクラスローダによりローディングされた別のアプリケーションのクライアントクラスに直接アクセスすることができない。アプリケーションは、クラスパスのパブリッククラスのあらゆるパブリックリソースにアクセス可能である。しかし、クラスパスのクラスは、「クラスパス」で規定されるパブリックタイプとしてコンバートすることによりアプリケーションのクライアントクラスインスタンスに参照できるにもかかわらず、アプリケーションのクラスに直接アクセスできない。アプリケーションは、クラスパスのシステムクラスパッケージあるいは、異なるクラスローダによりローディングされた他のあらゆるアプリケーションパッケージを拡張もしくは修正することができない。「Ｊａｖａ」言語により供給される完全な類型化に加えて、クラスの名称にクラスローダの参照を挿入することにより名前空間の分離を使用すると、アプリケーション間の有効な分離が得られる。スペース名の元々の分離機構により、新しいアプリケーションを容易にローディングすることができる。アプリケーションは、このために特別にプログラミングされて「クラスパス」に配置されたクラスを介してオブジェクトを交換可能である。アプリケーションは、このオブジェクトが「クラスパス」で規定されるパブリックタイプに変更できる場合、異なるクラスローダによりローディングされる別のアプリケーションから送られたオブジェクトを使用することができる。
【００１７】
残念ながら、従来の仮想マシンとそのダイナミックリンキングプロセスとに基づいた、こうした名称分離機構は、特別なプラットフォームでしか実行することができない。特別プラットフォームの仮想マシンは、ダイナミックリンキングを実行することができないので、これは、解明されない参照を持った従来の「Ｊａｖａ」プラットフォームのクラスファイルを保存可能にするメモリスペースを要する。特別プラットフォームでは、ＡＰＩのシステムクラスと、アプリケーションのクライアントクラスは、個々の名前空間で分離されない。
【００１８】
本発明の目的は、スタティックリンキングの構成が、オフプラットフォーム部分で実行される、二つの部分からなる仮想マシンを備えた組込システムの範囲で名称分離の長所を得る解決方法を提案することにある。
【００１９】
支払い端末、マルチアプリケーション端末等の組込システムの状況では、各種の支払いシステム（ビザ、マスターカード．．．）等の様々なソースから供給される「Ｊａｖａ」アプリケーションの間で高性能の分離を有することが必要である。そのため、様々なソースから送られるアプリケーションの間でフレキシブルな協働を可能にすることが有効である。組込システムはまた、新しいアプリケーションまたは新しいユーティリティモジュールあるいは更新を、既にローディングされたアプリケーションを妨害せずにダウンロードすることにより容易に更新されなければならない。
【００２０】
本発明の第一の目的は、アプリケーションどうしを協働可能にし、アプリケーションを発達させ、あるいは他のアプリケーションをローディング可能にしながら、アプリケーション間をしっかりと分離し、ローディング方法を提案することにある。
【００２１】
この目的は、アプリケーションのソースコードが書き込まれ、コンパイラにより擬似コードとしてコンパイルされ、チェッカーによりチェックされ、コンバータによりコンバートされ、ローダによりロードされる局から、中間擬似コードタイプの言語のインタープリタを含む仮想マシンと、アプリケーションプログラミングインターフェース（ＡＰＩ）とを備えた実行環境を有する本発明による組込システムに、アプリケーションをローディングする方法により達せられ、
コンバートが、組込システムの同じ名前空間に保存するように構成された、モジュールと呼ばれる複数のパッケージの集合のスタティックリンキングの実施を含み、各モジュールに識別子（ＭＩＤ）を割り当て、モジュールのクラスに含まれる各クラス、各メソッド、および各属性に参照番号を割り当て、
モジュールにリンキングされる擬似コードにおけるメソッドまたは属性の参照が、モジュールの内部または外部クラスの参照と、クラス番号と、メソッド番号または属性番号とを示すインジケータからなる３バイトで符号化され、
モジュールは、それぞれが一つのアプリケーションに対応するシステムクラスまたはサービスモジュールを含む一つまたは複数のアプリケーションプログラミングモジュール（ＡＰＩモジュール）であり、外部クラスの参照が、アプリケーションプログラミングインターフェースモジュールの参照として仮想マシンにより系統的に解釈されることを特徴とする。
【００２２】
別の特徴によれば、組込システムへのモジュールのロードが、モジュールの少なくとも一つの表示リストの記憶を含み、０〜ｎのリンカにより番号を１個のモジュールに関連づけて、リストに前記モジュールのインデックスを構成し、また、前記モジュールの識別子（ＭＩＤ）への表示リストのインデックスの関連付けを記憶するテーブルの記憶を含み、前記リストおよびテーブルが、不揮発性プログラマブルメモリからなり、擬似コードにおける外部モジュールの外部参照が、仮想マシンのインタープリタにより、モジュールのリストのインデックスと同等のモジュールへのアクセスインデックスを構成するものとして解釈される。
【００２３】
別の特徴によれば、ロードが、各モジュールに対して、モジュールのインデックスの参照を含む、そのクラスの表示リストの記憶を含み、各クラスに対して、属性およびメソッドの表示リストとを含む。
【００２４】
別の特徴によれば、モジュールが、単一のモジュールリストで参照され、システムクラスが、単一のＡＰＩモジュールに含まれ、擬似コードにおいてｎとは異なる外部クラスへのあらゆる参照が、前記ＡＰＩモジュールの参照として擬似装置により解釈される。
【００２５】
別の特徴によれば、クラスが、パブリックであると宣言され、あるいはプライベートパッケージとして宣言され、属性およびメソッドが、プライベートパッケージまたはプライベートクラスとして保護されると宣言され、クラスの番号順が、パブリッククラス、次いでプライベートパッケージクラスの順に行われ、属性またはメソッドの番号順が、プライベートパッケージおよびプライベートクラスとして保護されるパブリックの属性またはメソッドの順に、コンバータにより行われる。
【００２６】
別の特徴によれば、システムクラスが、別々にロード可能な複数のＡＰＩモジュールに含まれ、ローダが、モジュールの２個の表示リストと、一方がＡＰＩモジュールに、他方が非ＡＰＩモジュールに対応する２個の関連づけテーブルＭＩＤ／Ｉｍｉとを、不揮発性プログラマブルメモリに保持し、ローダが、特別モジュールのヘッダにおける性質に応じて、２個のリストのうちの一方にモジュールをロードし、モジュールリストのモジュールのあらゆる外部参照が、ＡＰＩモジュールのインデックスの参照として解釈される。
【００２７】
別の特徴によれば、モジュールのスタティックリンキングは、中間擬似コードにおける非ＡＰＩモジュールの外部クラスへの参照が、モジュールのヘッダのリストにおけるインデックスであるように行われ、その各入力が、参照されたＡＰＩモジュールの識別子（ＭＩＤ）であり、ターゲットプラットフォームへの前記モジュールのローディングが、ＡＰＩモジュールの関連づけテーブルの識別子（ＭＩＤ）から得られるＡＰＩモジュールのインデックス番号による、前記参照の代替を含む。
【００２８】
本発明の別の特徴は、対応する組込システムを提案することにある。
【００２９】
この目的は、仮想マシンと、アプリケーションプログラミングインターフェースを含むＡＰＩプラットフォームと、不揮発性のＲＯＭと、不揮発性のプログラマブルまたは修正可能なメモリと、ＲＡＭとを含む本発明による組込システムにより達成され、不揮発性のプログラマブルメモリが、システムクラスおよびサービスモジュールを含む少なくとも一つのＡＰＩモジュールと、モジュールにインデックスをつけた少なくとも一つのモジュール表示リストと、前記モジュールの識別子に表示リストのモジュールのインデックスを関連づけるテーブルとを含み、各モジュールは、クラスにインデックスが付けられていて各クラスがそのモジュールのインデックスの参照を有するクラス表示リストを含み、各クラスは、属性およびメソッドにインデックスを付けた属性およびメソッドの表示リストを含み、メソッドまたは属性の参照が、モジュールの内部または外部クラスの参照に対応する少なくとも３バイトで符号化され、モジュールの外部参照が、モジュールリストでＡＰＩモジュールのインデックスを構成し、クラス番号が、モジュールのクラスの表示テーブルにおけるクラスのインデックスに対応し、メソッドまたは属性の番号が、モジュールのクラスのメソッドまたは属性の表示テーブルにおけるメソッドまたは属性のインデックスに対応する。
【００３０】
別の特徴によれば、メソッドまたは属性への参照を符号化する３バイトの第一のバイトと、所定値ｎとを比較して、内部クラスに関するか、外部クラスに関するかを決定する比較手段を含む。
【００３１】
別の特徴によれば、システムの主要プログラムを含む主要モジュールを有する。
【００３２】
別の特徴によれば、クラスが、パブリックのクラス、次いでプライベートパッケージクラスの順にインデックスを付けられ、属性またはメソッドが、パブリックの属性またはメソッド、保護された属性またはメソッド、プライベートパッケージの属性またはメソッド、およびプライベートクラスの順にインデックスを付けられる。
【００３３】
別の特徴によれば、不揮発性のプログラマブルメモリが、システムクラスと、一方がＡＰＩモジュール用で他方が非ＡＰＩモジュール用の２個のモジュール表示リストと、主要モジュールとを含む複数のＡＰＩモジュールと、それぞれがモジュール表示リストに対応する２個のＭＩＤ／ＩＭｉ関連づけテーブルとを含む。
【００３４】
別の特徴によれば、主要モジュールを介してサービスモジュールのインスタンスを生成可能なメソッドを含む、ＡＰＩモジュールのアクセス管理者クラス「アクセス・マネジャー」を含み、前記クラスが、１個以上のインスタンスを有することを禁ずる保護を備える。
【００３５】
本発明の別の目的は、マルチアプリケーション組込システムに存在するアプリケーションの実行方法を提案することにある。
【００３６】
この目的は、中間擬似コードタイプの言語のインタープリタを含む仮想マシンと、アプリケーションプログラミングインターフェース（ＡＰＩ）とを備えた実行環境を有する、マルチアプリケーション組込システムのアプリケーションの実行方法により達成され、モジュールの内部クラスまたは外部クラスと、クラス番号と、メソッドまたは属性番号との参照に対応する少なくとも３バイトで符号化された、擬似コードにおけるメソッドまたは属性の参照を、モジュールリストで参照する、一つのアプリケーションに対応するサービスモジュールの中間擬似コードの実行時に、モジュールの外部参照が、仮想マシンにより、一つまたは複数のＡＰＩモジュールのリストのＡＰＩモジュールのインデックスの参照として解釈されることを特徴とする。
【００３７】
別の特徴によれば、識別子を有するサービスモジュールの実行要求を受信すると、実行環境が、システムの主要プログラムを含む主要モジュールの入力クラスにアクセスし、主要モジュールが、サービスモジュールへのアクセスを管理するＡＰＩモジュールの特別クラス「アクセス・マネジャー」のインスタンスをインストールし、このクラスのメソッドを使用することにより、モジュールが参照されるリストでモジュールのインデックスに識別子を関連づけるテーブルを介して、要求されたサービスモジュールの入力クラスのインスタンスを生成可能にし、インスタンスが、このメソッドにより主要プログラムに戻される。
【００３８】
本発明の他の特徴および長所は、添付図面に関してなされた以下の説明を読めば、いっそう明らかになるであろう。
【００３９】
図１〜３に関して、限定的ではないが、たとえばチップカードまたは同様の携帯オブジェクトからなる特別なタイプの組込システムで本発明を実施する場合の方法について説明する。バイトコード表示またはバイトコードタイプのプログラムは、あらゆる擬似コードまたは中間プログラムをカバーする。
【００４０】
携帯オブジェクトは、たとえばチップカードを構成し、図４ａ、４ｂに関して先に説明した構造と同様の構造を有し、特に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭを含む。特別プラットフォーム（６０）および従来の局（８０）を図１に示した。特別プラットフォーム（６０）は、ＲＯＭに、ＡＰＩ（６２）と、組込された（「オンプラットフォーム」）仮想マシン（６１）とを含む、実行環境（ＲＥ）を有する。特別プラットフォーム（６０）は、ＲＯＭおよびＥＥＰＲＯＭの集合を含むものとして図１に示されている。特別プラットフォーム（６０）は、特に、実行環境（ＲＥ）と、ＥＥＰＲＯＭに存在する素子とを含むことに留意されたい。携帯オブジェクトは、ＲＯＭに、オペレーティングシステム（６３）を有する。ＲＯＭに存在するＡＰＩ（６２）は、ＡＰＩプラットフォームの基本ＡＰＩを構成し、組込された仮想マシンと共にローディングされ、仮想マシンを作動する。
【００４１】
仮想マシンの携帯オブジェクト外の部分（９０）は、中間擬似コードチェッカー（９１）、コンバータ（９２）、および場合によっては署名装置（９４）を含む。署名装置は、チェッカーおよびコンバータによる通過を有効にするために署名を送る。この署名は、ロードの瞬間に携帯オブジェクトによりチェックされる。基本ＡＰＩを補完するためのアプリケーションまたは新しいＡＰＩのＥＥＰＲＯＭへのローディングは、ローダにより行われる。ローダは、ダウンローダ（９３）と呼ばれる、携帯オブジェクト外の仮想マシン（９０）にインストール可能な携帯オブジェクト外の部分と、ローダ（６８）と呼ばれる特別プラットフォーム部分との二つの部分から構成可能である。
【００４２】
第一の実施形態によれば、特別プラットフォーム（６０）は、ＡＰＩモジュール（６５）と主要モジュール（６６）との二つの特別モジュールを含む。他のモジュールは、サービスモジュール（６７）と呼ばれる。各モジュールは、同じ名前空間に保存されるパッケージの集合に対応する。ＡＰＩプラットフォームは、基本ＡＰＩ（６２）と、ＡＰＩモジュール（６５）またはＡＰＩプラットフォームモジュールを決定するシステムクラスの集合とをさす。主要モジュールは、主要プログラムを決定する主要クラスを含む。ＡＰＩモジュール（６５）を除いた各モジュールは、モジュールへのアクセスポイントを構成する「エントリークラスＥｎｔｒｙＣｌａｓｓ」と呼ばれる特定の単独クラスを有する。主要モジュールに対しては、この「エントリークラス」が主要クラス（ＣＰ）であり、「メイン」と呼ばれるスタティックメソッドを含むクラスである。サービスモジュールに対しては、パラメータのない構成だけを有し、ＡＰＩプラットフォームで決定される「サービス」と呼ばれる特別パブリックインターフェースをインプリメントするクラスである。アプリケーションのローディングは、サービスモジュールのローディングに対応する。各モジュールは、特別識別子を受信する。ＭＩＤと呼ばれるこのような特別識別子は、たとえば数、文字列、またはリストとすることができる。例として、識別子は文字列である。
【００４３】
特別プラットフォームの仮想マシンとは異なるダウンロード機構によりプラットフォームにロードされる場合、モジュールは０〜ｎの数を受信する。かくして、この協定によれば、最大でもｎ＋１個のモジュールが、特別プラットフォームに存在することができる。ローダ（６８）を備えるモジュールのダウンローダ（９３）は、新しいサービスモジュールのローディング時に、モジュールの表示リスト（ＴＲＭ）（６９）を保持する。モジュールに関連づけられる番号は、リスト内のこのモジュールのインデックス（ＩＭ）である。ローダ（６８）はまた、各モジュールの識別子（ＭＩＤ）にインデックス（ＩＭ）を関連づけるテーブル（７０）を保持する。ＡＰＩモジュールは、インデックスＩＭ_０に対して系統的に番号０を受信し、主要モジュールは、インデックスＩＭ_１に対して番号１を受信する。各モジュールのヘッダ（ｈｅａｄｅｒ）は、モジュールの性質が、「主要」モジュールであるか、「サービス」モジュールであるか、あるいは「ＡＰＩ」モジュールであるか決定する。
【００４４】
ローダ（６８）は、携帯オブジェクトに留まることを許可されたモジュール、すなわち、携帯オブジェクトが知っている署名を持つモジュールだけをロードすることができる。従って、ローダ（６８）は、受信モジュールの署名をチェックし、携帯オブジェクトの既知の署名と比較し、比較が否定的である場合はローディングをブロックする手段を含む。
【００４５】
一般に、上記の従来技術で規定されたように、アプリケーションのソースプログラム（８１）が書き込まれ、次いでコンパイラ（８２）によりコンパイルされてから、チェッカー（９１）によりチェックされる。
【００４６】
コンバータ（９２）でコンバータのリンカーと呼ばれるコンポーネントにより実施されるスタティックリンキングは、
−モジュールの各クラスに番号（ＮＣＩ）を、
−クラスの各メソッドのために番号（ＮＭ）を、
−クラスの各属性のために番号（ＮＡ）を、割り当てることによってシンボル参照を解明する。
【００４７】
これらの番号（ＮＣＩ、ＮＭ、ＮＡ）は０〜ｎであり、バイトで示すことができる。たとえば、各数は０〜２５５（ｎ＝２５５）である。クラスのメソッドまたは属性の参照は、このように、２バイトでモジュールのメソッドにリンキングされる擬似コードで符号化される。擬似コードは、これらの２バイトのクラス用「ＮＣＩ」、属性用「ＮＡ」、あるいはメソッド用「ＮＭ」を含む。
【００４８】
図３によれば、ＡＰＩモジュール（６５）、主要モジュール（６６）またはサービスモジュール（６７）の内部表示が、クラス表示リスト（ＴＲＣ）を含む。組込システム外でリンカーにより各クラスに関連づけられる番号（ＮＣＩ）は、クラス表示リスト（ＴＲＣ）におけるこのクラスの表示のインデックス（ＩＣｉ）である。各クラスはまた、モジュールのインデックス（ＩＭｉ）への参照を有する。同様に、各クラスの表示は、メソッド表示リスト（ＴＲＭｅ）と、クラスに属する属性表示リスト（ＴＲＡ）とを含む。組込システム外でリンカーにより各メソッドに関連づけられる番号（ＮＭ）は、メソッド表示リスト（ＴＲＭｅ）におけるこのメソッドの表示のインデックス（ＩＭｉ）であり、組込システム外でリンカーにより各属性に関連づけられる番号（ＮＡ）は、属性表示リスト（ＴＲＡ）におけるこの属性の表示のインデックス（ＩＡｉ）である。
【００４９】
たとえば、システムクラスが、従来のプラットフォームの「クラスパス」のクラスに対応するとき、モジュールが、その固有のクラスと、ＡＰＩプラットフォームのシステムクラスとだけを参照できるようにしようとする。本発明によれば、モジュールの内部クラスの参照と、システムクラス（またはモジュールの外部クラス）の参照とを区別可能にするために、内部（ＩＩ）または外部（ＩＥ）インジケータが、メソッドまたは属性の参照に付加される。解明される参照は、その場合、「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＭ」または「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＡ」の３バイトで符号化される。
【００５０】
上記の協定によれば、第一のバイト「ＩＥ／ＩＩ」の値ｎに対して、例では２５５であるこの値が、モジュールの内部参照「ＩＩ」に対応し、第一のバイトのための他のあらゆる値が、モジュールの外部参照「ＩＥ」に対応する。
【００５１】
携帯オブジェクト外の仮想マシン（９０）のコンバータ（９２）のリンカーは、擬似コード内に外部参照「ＩＥ」を持たないＡＰＩモジュール（６５）を第一にリンキングし、クラスとメソッドおよび属性とのシンボル名のプランに対応して、配置または構成を生成する。他のモジュールのリンキング時には、この配置を用いて、ＡＰＩモジュール（６５）のシステムクラスへの外部参照を設定する。
【００５２】
参照をエンコードする本発明のバイト協定によれば、ＡＰＩモジュールには最大で２５６（ｎ＋１）個のクラスがあり、各追加モジュールには２５６個のクラスがある。
【００５３】
サービスモジュールの実行時には、仮想マシン（６１）が、参照があるクラス「ＮＣＩ」を知って、擬似コードにおけるメソッド「ＮＭ」または属性「ＮＡ」を参照するとき、仮想マシンは、関与するモジュールのインデックス「ＩＭｉ」を直接見つけることができ、このモジュールは、外部参照（ＩＥ）または内部参照（ＩＩ）に対応する。サービスモジュールの擬似コードにあるあらゆる外部参照（ＩＥ）は、ＡＰＩモジュールの参照として仮想マシンにより系統的に解釈される。サービスモジュールまたは主要モジュールは、ＡＰＩモジュールのクラスを除いて、他のあらゆるモジュールのクラスを参照することができない。このＡＰＩモジュールのシステムクラスは、サービスモジュールまたは主要モジュールのクラスを参照することができない。第一のバイトに対して値ｎに対応するモジュールのクラスの内部参照は、モジュールに割り当てられる名前空間を先験的に知っている必要は少しもない。コンバート段階の時に固定名前空間を先験的に決定しないことにより、参照の解明を加速し、コンバート段階後のローディング時にモジュールの名前空間を決定することができる。仮想マシンは、擬似コードにおける属性またはメソッドの参照の解釈時に、連続した３個のインデックス「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＭ」または「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＡ」を使用する。モジュールのメモリスペースは決定されているので、インデックス「ＮＣＩ」は、モジュールのクラスリスト（ＴＲＭ）における所望の入力を決定し、次いで、最後のインデックス「ＮＭ」または「ＮＡ」画、メソッドリスト（ＴＲＭｅ）または属性リスト（ＴＲＡ）に所望の入力を与える。
【００５４】
ＡＰＩモジュールは、「アクセスマネジャー」クラスと呼ばれる特別クラス（６４）を含み、このクラスは、モジュールの識別子（ＭＩＤ）から、要求されたサービスモジュールの入力クラスのインスタンスオブジェクトを返す役割をする固有のメソッド（ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅ）を含む。このメソッドは、モジュールリスト（６９）で要求されるモジュールのインデックスを知るためにＭＩＤ／ＩＭｉ関連づけテーブル（７０）を使用し、次いで、このモジュールの入力クラスのインスタンスを生成し、このメソッドによってインスタンスを返す。本発明によれば、「ＡｃｃｅｓｓＭａｎａｇｅｒ」クラス（６４）は、このクラスが１個以上のインスタンスを有することを禁ずることからなるメソッドにより、設計上、保護される。固有のメソッド（ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅ）は、主要モジュールに含まれる主要プログラムに属する。携帯オブジェクトの使用時に最初に作動される主要モジュールは、１個のインスタンスと、１個の「アクセス・マネジャー」クラスとを生成するので、このモジュールは、ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅメソッドを使用可能であるが、他のあらゆるサービスに対しては、このメソッドを使用するための他のインスタンスの生成が禁じられる。
【００５５】
実行環境（ＲＥ）は、作動時に、従来のプラットフォームと同様に、主要モジュールの入力クラス（ＥＣ）にアクセスし、入力メソッド（メイン）を作動する。主要モジュールは、最初に作動されるので、他のあらゆるサービスより前に「アクセス・マネジャー」クラスのインスタンスをインストールする。何故なら、主要モジュールは、他のサービスを作動するために、アクセスクラスのこのようなインスタンスを既に持っていなければならないからである。
【００５６】
こうした単純な装置により、従来のプラットフォームの名前空間の概念に結合される保護効果を再生することができる。モジュールリストにサービスモジュールをローディングし、擬似コードにおける全ての外部参照の存在を仮想マシンがＡＰＩモジュールの参照として解釈するという簡単なことから、このモジュールは、他のモジュールから直接アクセスされることが全くなくなり、完全に分離される。
【００５７】
上記の第一の実施形態により、２つの部分からなる仮想マシンという状況で名前空間の分離により分離（ＰＡＲＥ−ＦＥＵ）が得られるいう長所が得られる。しかしながら、この実施形態は、フレキシブルでなく、次のような２つの欠点を有する。
【００５８】
第一に、既に予めリンキングされたモジュールにより、システムクラスのあらゆる修正または拡張が妨げられる。従来の「Ｊａｖａ」アーキテクチャは、追加モジュールの既にコンパイルされたクラスに影響を与えることなくＡＰＩプラットフォームのクラスを修正かつ拡張することができる。だが、上記の実施形態では、システムクラスのあらゆる修正は、異質のモジュールに対しては表示されないものであっても、ＡＰＩプラットフォームの構成を修正してしまい、構成の従来バージョンに既にリンキングされた各モジュールの、予めリンキングされた擬似コードを修正するので、従ってインタープリタを修正することが必要になる。
【００５９】
第二に、予めリンキングされたモジュールは、組込された様々なプラットフォームまたは端末間で携帯であると仮定されるので、これらのプラットフォームの各々が、ＡＰＩプラットフォームと同じ構成を持たなければならなくなり、あらゆる所有者の拡張使用が禁じられる。
【００６０】
これらの欠点を部分的に解消するために、第一の実施形態の変形実施形態は、配置の番号順において、最初にパブリッククラスがきて、プライベートパッケージクラスの前にくるように課すことからなる。さらに、パブリックのメソッドまたはパブリックの属性が、保護されるメソッドまたは属性と、プライベートパッケージおよびプライベートクラスにあるメソッドまたは属性の前に来る。これにより、ＡＰＩモジュール（６５）に新しいパブリッククラスを自由に付加することができる。
【００６１】
図２は、ＡＰＩプラットフォームを発展させることができる第二の実施形態を示す。ＡＰＩプラットフォームは、単一のＡＰＩモジュールから構成される代わりに、別々にロード可能な複数のＡＰＩモジュール（１００）から構成される。
【００６２】
この実施形態では、ダウンローダ（９３）と仮想マシンとが、１個につき１個ではなく、サービスモジュール（６７）および主要モジュール（６６）に対応して、ＡＰＩモジュールに対しては、リスト（１０１）および関連づけテーブル（１０２）、非ＡＰＩモジュールに対しては、リスト（１０３）および関連づけテーブル（１０４）の、２個のモジュールリストと、２個のＭＩＤ／インデックス関連づけテーブルとを共有している。
【００６３】
各モジュールは、そのヘッダに、性質を示すインジケータ「サービス」または「ＡＰＩ」を有し、ＡＰＩモジュールのリスト（１０１）または非ＡＰＩモジュールのリスト（１０３）にローダがモジュールをローディングできるようにする。このインジケータは、コンバータによるコンパイル段階の際に、モジュールのヘッダに配置される。
【００６４】
名前空間の分離からなる分離（ＰＡＲＥ−ＦＥＵ）は、非ＡＰＩモジュールの間にのみ存在する。サービスモジュールへのあらゆる外部参照は、ＡＰＩモジュールのリストのインデックスとして、組込された仮想マシンのインタープリタにより解釈される。
【００６５】
非ＡＰＩモジュールは、ｎ＝２５５の例では、０から最大２５５まで番号を付けられ、０は、たとえば主要モジュール（６６）のインデックスである。ＡＰＩモジュール（１００）は、０から最大２５４まで番号を付けられ、０は、たとえば、いわゆるプライマリＡＰＩモジュールのインデックスであり、あらゆる固有のメソッドを含む。上記の協定によれば、これにより、ＡＰＩプラットフォームでは、最大２５５（ｎ）個の異なるモジュールが容認される。擬似コードにおけるメソッドまたは属性の参照は、次のようになる。
【００６６】
「「ＩＥ／ＩＩ」「ＮＣＩ」「ＮＭ／ＮＡ」」
第一のバイトに対する値２５５（ｎ）は、第一の実施形態と同様に、モジュールの内部参照を示す。２５５とは異なる各値は、ＡＰＩプラットフォームのＡＰＩモジュールリストの、特別モジュール（１００）の外部参照を示す。
【００６７】
オフプラットフォームのリンカー（９２）によりリンキングが実施された後で、モジュールの擬似コードは、現行のモジュールをリンキングするために使用される参照モジュールリストを有するヘッダを含む。参照モジュールリストは、最大２５５個の入力を含み、各入力が、ＡＰＩモジュール（１００）の識別子（ＭＩＤ）に対応する。その場合、擬似コードにおける外部参照の第一のバイトは、このリストにおけるインデックスである。非ＡＰＩモジュールのプラットフォーム（６７、６６）にローディングする際、ＡＰＩモジュール（１００）に関連づけられるインデックス番号は知られているので、外部参照の第一の各バイトは、ＡＰＩモジュール（１００）のＭＩＤ−ＩＭｉ関連づけテーブル（１０２）を使用することにより、参照されたＡＰＩモジュールに関連づけられるインデックス番号に代えられる。こうした代替は、特別プラットフォームでローダ（６８）により実施される単独リンキング操作であり、ＭＩＤ／ＩＭｉ関連づけテーブル（１０２）は、このリンキング操作を実施するためにのみ使用される。
【００６８】
たとえば、サービスモジュール「ＴＥＳＴ」の擬似コードにおいて、ＡＰＩモジュールのクラス番号７のメソッド番号５を参照し、識別子（ＭＩＤ）が「Ｆ００」であるとする。さらに、「Ｆ００」が、サービスモジュール「ＴＥＳＴ」で参照された第四のＡＰＩ外部モジュールの識別子であるとする。その場合、擬似コードにおける参照は、３つの値３、７、５から構成される。
【００６９】
番号３は、擬似コードの冒頭に送られる、モジュールのヘッダに存在する参照モジュールリストにおいて、第四のインデックスに対応し、この入力の値は識別子（ＭＩＤ）「ＦＯＯ」である。ＡＰＩモジュール「ＦＯＯ」のローディング時に、内部インデックス３４が、ＡＰＩモジュールの関連づけテーブル（１０２）でターゲットプラットフォームに割り当てられたものと仮定する。その場合、ローダ（６８）は、関連づけテーブル（１０２）を用いて、サービスモジュール「ＴＥＳＴ」の擬似コードで参照を修正し、３４、７、５になるようにする。
【００７０】
モジュールの擬似コードの実行時に、モジュールの外部リファレンスは、仮想マシンにより、ＡＰＩモジュールテーブルにおける入力として系統的に解釈される。非ＡＰＩモジュールリストのモジュールは、互いに、またＡＰＩモジュールに対して、非表示である。こうした単純な装置により、従来のプラットフォームの名前空間の概念に結合される保護効果を再生することができる。非ＡＰＩモジュールリストにモジュールをローディングするという簡単なことによって、このモジュールは、他のモジュールから直接アクセスされることが全くなくなり、完全に分離される。
【００７１】
ＡＰＩモジュールのリスト（１０１）は、「ＡＰＩアクセス」モジュールと呼ばれる特別モジュール（１０５）を含む。このモジュールは、要求されたサービスモジュールの入力クラスのインスタンスオブジェクトを返す役割をする固有のメソッド（ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅ）を含む。このメソッドは、非ＡＰＩモジュールリスト（１０３）で要求されるサービスモジュールのインデックスを知るためにＭＩＤ／ＩＭｉ関連づけテーブル（１０４）を使用し、次いで、このモジュールの入力クラスのインスタンスを生成し、主要プログラムのメソッドにより、このインスタンスを返す。勧められる安全なやり方は、「アクセス・マネジャー」クラスから、設計者およびメソッドが保護されていると宣言される保護クラスを形成することにある。さらに、「ＡＰＩアクセス」モジュール（１０５）は、「アクセス・マネジャー」クラスが１個より多くのインスタンスを有することを禁ずることからなる保護を含む。このメソッドは、主要モジュール（６６）で得られる主要プログラム専用である。最初に作動される主要モジュールは、アクセスマネジャーモジュールのインスタンスを生成するので、このモジュールは、ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅメソッドを使用できるが、他のあらゆるサービスは、このメソッドを使用するための他のインスタンスの生成を禁じられる。かくして、主要モジュールは、サービスインスタンスを生成することができる。
【００７２】
「アクセス・マネジャー」クラスが１個のインスタンスしかもたないことを禁じることからなる、こうした保護を得るために、複数の方法が使用可能である。クラスの設計者は、たとえば既に一つが存在する場合、インスタンスの生成要求をブロック可能であり、安全例外をスタートする。実行環境（ＲＥ）は、動作上、主要モジュール（６６）の入力クラスにアクセスし、入力メソッド（メイン）を作動する。主要モジュールは、最初に作動されるので、他のあらゆるサービスの前に「アクセスマネジャー」クラスのインスタンスをインストールする。
【００７３】
サービスモジュールが、他のサービスモジュールを作動できるようにするために、こうした厳しい安全方策を変更して、ＡＰＩアクセスモジュール（１０５）の「アクセス・マネジャー」クラスにパブリッククラスを付加し、あらゆるモジュールがそこで要求を行えるようにしてもよい。これらのパブリッククラスは、特に、単一のインスタンスを得られるスタティックメソッドを含む。「アクセス・マネジャー」クラスのインスタンスオブジェクトにアクセスするモジュールは、別のサービスモジュールを作動し、これを使用することができるが、そのクラス、メソッドまたは属性を直接参照するには、仮想マシンによる参照が必要である。何故なら、擬似コードにおける全ての外部参照は、このモジュールの内部参照またはＡＰＩモジュールの外部参照であるからである。
【００７４】
この解決方法を簡単に実施するには、ＡＰＩモジュールの中で循環的な参照を持たないようにすることが必要である。従って、「に参照する（「ｒｅｆｅｒｓｔｏ」）」という関係の一時的な閉鎖は、モジュールセットで部分的に逆の成り立たない順序でなければならない。従って、コンバータ（９２）のリンカーにおいて、まだリンキングされていない最低限の素子を最初に処理することによってＡＰＩモジュールの構成を結合および生成するための簡単な政策を、コンバータ（９２）のリンカで設計することができる。ＡＰＩモジュールのダウンロードに対しても、部分的な順序に基づいた同じ政策に従うことができるので、モジュールＭのダウンロード時に、参照する全てのモジュールが既に全てダウンロードされており、それらに番号が割り当てられている。ターゲットプラットフォームにおける内部インデックスの割り当ては、ｎ次のＡＰＩにインデックスｎ−１を割り当てることにより、モジュールのローダ（６８）によってなされる。ＡＰＩモジュールは、それよりも大きいインデックスを持つ別のＡＰＩモジュールを参照することができない。
【００７５】
モジュールリスト（１０１、１０３）および関連づけテーブル（１０２、１０４）を二重にしたこのシステムの使用により、単一のＡＰＩモジュールを別々にロード可能な複数のＡＰＩモジュールにより簡単に代替可能である。単一のＡＰＩモジュールを複数のＡＰＩモジュールに代えることにより、既にロードされたモジュールの組立を変えずに、また分離により提供される安全性を変えずに、新しいモジュールでＡＰＩプラットフォームを拡張することができる。もちろん、この二つの実施形態は、相容れるものではない。モジュールは、実施形態のいずれかに対して特別に、予めリンキングされていなければならず、一方の実施形態に関する擬似コードは、他方の実施形態をインプリメントするプラットフォームではサポートされない。しかも、仮想マシンのインタープリタは、実施形態どうして異なる。第一の実施形態では、仮想マシンが、１個のリストと１個の関連づけテーブルだけを操作する。参照の第一のバイトは、仮想マシンにより、ｎに等しい全ての値に対して内部参照として解釈され、ｎとは異なる全ての値に対して単独ＡＰＩモジュールの外部参照として解釈される。第二の実施形態では、仮想マシンは、２個のリストと２個の関連づけテーブルとを操作する。擬似コードにおける参照の第一のバイトは、仮想マシンにより、ｎに等しい全ての値に対して内部参照として解釈され、ｎとは異なる全ての値は、ＡＰＩモジュールリストにおけるインデックスとして直接考慮される。二つの実施形態では、仮想マシンのインタープリタが、一つのメソッドまたは属性の参照を符号化した３バイトの第一のバイトと、所定値ｎとを比較し、モジュールの内部クラスに関するか、外部クラスに関するかを決定する。ＡＰＩモジュールの番号順は、ローディング次に決定され、それによって、最終的に、またきわめて簡単に、擬似コード内の外部参照を固定することができる。
【００７６】
使用されるメソッドおよび得られる安全性が全く異なるが、二つのタイプのモジュールを操作するために同じ機構が使用される。全てのモジュールは、クラスがシステムクラスであるのでＡＰＩモジュールに自由にアクセスできる。モジュールで構成されたアプローチの使用は、あらゆる直接アクセスからこれらのモジュールを保護する厳密な分離を得るために、サービスモジュールと共に使用される。
【００７７】
本発明による方法は、たとえば１６ｋｏのＲＯＭ、８ｋｏのＥＥＰＲＯＭ、２５６ｋのＲＡＭといった、リソースの小さいあらゆるタイプの形態オブジェトで実現可能である。
【００７８】
当業者が理解できる他の修正が、同様に、本発明の意図の一部をなす。
【図面の簡単な説明】
【図１】第一の実施形態による形態オブジェクトのローディングに必要な各種の素子を概略的に示す図である。
【図２】第一の実施形態による形態オブジェクトのローディングに必要な各種の素子を概略的に示す図である。
【図３】モジュールの内部を示す図である。
【図４ａ】チップカードの従来の構成を示す図である。
【図４ｂ】従来技術によりチップカードに組込した仮想マシンの構成に必要なシステムを示す図である。
【図４ｃ】アプリケーションのクラスの構造を示す図である。[0001]
The present invention relates to a method for loading an application into a multi-application embedded system having data processing resources, a corresponding embedded system, and an application execution method for the corresponding embedded system.
[0002]
The present invention relates in particular to the implementation of separation between modules sharing the same memory space (PARE-FEU) in a system embedded in a multi-application portable object that uses intermediate pseudo code and associated virtual machines. .
[0003]
The “Java” ™ technology introduced by the company “Sun” is based on a programming language directed to “Java” objects and associated virtual machines. This technology was developed by a station or PC (personal computer) (hereinafter referred to as a “Java” platform) having a power CPU and a large memory in megabytes.
[0004]
For several years, the concept of “Java” technology has been reworked, for example, credit cards, SIM micromodules incorporating microprocessors (generally called chip cards), to work with systems embedded in portable objects, It has been adapted to the format of GSM (Global System for Mobile Communication) mobile phones, PCMCIA cards, or any other mobile terminal. Hereinafter, the expression “card” will be used to indicate any one of these portable objects. The programming of the embedded system that has been configured as an assembler until now will be possible in a high-level programming language such as “Java” in the future, and the development of the client application can be facilitated and accelerated.
[0005]
These new types of platforms (hereinafter referred to as special platforms) that are unique to portable object embedded systems are subassemblies of conventional platforms. Differences have been made by reducing the embedded system environment. In general, as shown in FIG. 4a, a chip card (10) includes an input / output system (11) connected to a microprocessor (14), a volatile RAM (Random Access Memory) (12), a ROM ( A nonvolatile memory (15) including a read only memory (13), and a flash RAM or an EEPROM (electrically erasable programmable only memory). A collection of these elements is connected to the microprocessor by connection BUS. For example, chip cards best include ROM, 32 kilobytes of EEPROM, and 2 kilobytes of RAM by using existing new components.
[0006]
In a conventional “Java” system, the application is written to a station or PC. The source code is compiled with intermediate pseudo code called “Java Byte Code” that is independent of the platform device code used. The application is then downloaded to the target platform or the traditional “Java” platform. The loaded application is composed of a set of classes in which various methods are compiled into pseudo code, that is, a so-called client class, and is supported by an application programming interface or an application programming interface API (Application Programming Interface). The application programming interface can homogenize the user interface and control an editor, keyboard, printer, or the like. A conventional platform virtual machine includes a pseudo code checker, a dynamic class loader, a pseudo code interpreter that enables translation into device code, and a safety management program.
[0007]
The main difference between a conventional virtual machine and a virtual machine of an embedded system (hereinafter referred to as a special virtual machine) is that the virtual machine of the embedded system is decomposed into two separate parts. According to FIG. 4b, the virtual machine includes a converter (32), a part (30) outside the special platform (40), called an off-platform ("off-platform") virtual machine, and a pseudo code interpreter. And a part (41) in the card constituting the special platform (40), called an embedded ("on-platform") virtual machine (41).
[0008]
Thus, in the case of a special platform, the application source program (21) is written and compiled as intermediate pseudo code by the compiler (22) and checked by the intermediate pseudo code checker (31) at the conventional station (20). Are converted by a converter (32) located in the same station (20) or another station. The application is then downloaded to the volatile programmable memory, possibly EEPROM (15) of the portable object or special platform (40), possibly after passing through the signing device (34). Such loading is performed by a loader that includes an off-platform part (33) called a downloader and a special platform part (42) called a loader. Unlike what exists on a traditional platform for the station, the virtual machine (41) of the special platform (40) placed in ROM with the Operating System (48) includes an intermediate pseudo code checker I can't. This is because the checker is too heavy to store and / or execute on the portable object. The special platform (40) also does not include a dynamic class loader. In fact, in the case of the application domain of the present invention, in the off-platform virtual machine (30), the checker (31) checks that the compiled classes are properly formed and there is a special language intrusion in the description of the special platform. Check if there is. The converter (32) does the work necessary to load the class and resolve the reference. The converter performs static linking of classes and resolves symbol references to classes, methods and attributes that already exist on the card. The converter allocates storage, creates a data structure to indicate the class, creates static or native methods and attributes, and initializes static variables.
[0009]
A special platform execution environment (Runtime Environment or RE) is an embedded virtual machine ("on-platform") (41) limited to an interpreter, an API platform, and so-called specific or static related methods (43). including. The API platform includes an API (44) that determines a set of classes (45) called system classes, and a calling convention (Call Convention) in which an application accesses an execution environment (RE) and a static method (43). The static method (43) executes a card input / output encryption memory allocation service.
[0010]
The interpreter of the virtual machine (on-platform) embedded in the card (41) plays a role of supporting the “Java” language, and sequentially reads the intermediate pseudo code for each instruction. Each standard instruction of such intermediate pseudo code is interpreted by the interpreter in the language of the microprocessor and then executed by the microprocessor. In general, standard instructions in intermediate pseudo code enable processing of high-level programming languages such as arithmetic processing and object manipulation. The concept of objects relates to information objects such as lists, data lists or the like. The so-called client class (46) of the application and the system class (45) of the API are all loaded into the same memory space and managed via the class table (47).
[0011]
The virtual machine (41) also enables secure sharing of data, also referred to as attributes, variables, or fields, by managing classes and objects to ensure compliance between applications.
[0012]
In the case of a chip card type portable object, the application of the special platform can be directly operated by the execution environment (RE) when a selection APDU (Application Protocol Data Unit) transmitted from the service or the terminal is received by the card.
[0013]
In order to restrict access to data between code parts that share the same memory space, one of the methods commonly used on conventional platforms is the visibility (VISIBILITE) declared in the source code. Based on clear restrictions. According to FIG. 4c, the method (NM1, NM2; NM3, NM4) and the attribute (NA1, NA2; NA3, NA4) are enclosed in classes (NCI3, NCI2), respectively. The class itself forms a part of a package (package 1; package n) in which a plurality of classes are collected. A class may be public, such as (NCI1 or NCI2), or private, such as (NCI3), for the package, in the latter case this is the same package Means that only this class can access this class. The method (eg NM2) and data (eg NA1) of the class (NCI3) can be private to the class (NM2, NA1), the class itself is private to the package (package 1), Alternatively, it is public for the package (eg NM1, NA2) or class (eg NM4, NA4). Such visibility restrictions allow for flexible access between different sets of packages (package 1, package n) stored in the same namespace. But there are some drawbacks. Traditional or special platforms cannot have the concept of subpackages. Large application client classes must be distributed among the various subpackages, which show different packages only for virtual machines. To share resources between these subpackages, the resource must be declared public so that any other package can view the resource. Therefore, it is difficult to unambiguously organize different application packages for large applications and obtain separation between applications.
[0014]
In the bureau, in the case of conventional platforms, adherence to resource confidentiality, as declared in the source program, is based on dynamic checks. To perform such a dynamic check, the virtual machine must have all the information regarding the declaration of access restrictions for each class, method or attribute. This cannot be used in the case of memory space available in an off-platform virtual machine intermediate pseudocode or an on-form virtual machine using pre-connected bytecode. In the case of a special platform for mobile objects, access restrictions can be checked statically at compile time and again by an off-platform checker. In fact, it is assumed that what is loaded on the special platform of portable objects is correct. This is because the special platform cannot perform any checks due to information loss during the conversion stage. Moreover, any security based on the use of a private package is compromised because it is not guaranteed that the package will not be extended or modified by new classes sent from external sources.
[0015]
The second means obtained by the virtual machine of the conventional platform is the concept of name space separation. In the traditional platform dynamic linking configuration, classes are either from a local file system directory called “ClassPath” that has been previously declared to constitute the area of system classes that form the standard API platform, or locally. It can be loaded from a file system or other directory on the remote server. The client class of an application outside the “classpath” must be loaded by a specially programmed class loader. This feature is particularly used for loading the application “Java” by the qualified browser “Java”. Thus, applications sent from various sources are loaded by different class loaders. A special class instance “application class loader” is used for each locator generally called a URL (Uniform Resource Locator). The name outside the class is a combination of “package name” + “class name”. When a class is loaded, it is stored in an internal class table and a reference to the class loader used to load this class is added to the class package name prefix. In this case, the class name is “reference to class loader” + “package name” + “class name”. Thus, virtual machines do not recognize classes that are declared as belonging to the same package but loaded by different class loaders as belonging to the same package.
[0016]
When resolving a reference, the usual way for a class loader is to first search by system class, and if it fails, search the class file in an area where the loader can load the class. According to this operating principle of the loader, an application cannot directly access the client class of another application loaded by a different class loader. An application can access any public resource in the public class of the classpath. However, although the class of the class path can be referred to the client class instance of the application by converting it as a public type defined by the “class path”, the class of the application cannot be directly accessed. An application cannot extend or modify a system class package in the classpath or any other application package loaded by a different class loader. In addition to the complete typification provided by the "Java" language, using namespace separation by inserting class loader references into class names provides effective separation between applications. The original separation mechanism for space names allows easy loading of new applications. Applications can exchange objects through classes specially programmed for this purpose and placed in the “classpath”. An application can use an object sent from another application loaded by a different class loader if this object can be changed to a public type as defined in the “classpath”.
[0017]
Unfortunately, such name separation mechanisms, based on traditional virtual machines and their dynamic linking processes, can only be performed on special platforms. Since special platform virtual machines are not able to perform dynamic linking, this requires memory space that allows the storage of traditional “Java” platform class files with unresolved references. In the special platform, the API system class and the application client class are not separated by individual namespaces.
[0018]
The object of the present invention is to propose a solution in which the configuration of static linking obtains the advantages of name separation in the range of embedded systems with two-part virtual machines that are executed off-platform. .
[0019]
In the situation of embedded systems such as payment terminals, multi-application terminals, etc., there is a high-performance separation between "Java" applications supplied from various sources such as various payment systems (visas, master cards ...) It is necessary. Therefore, it is effective to enable flexible cooperation between applications sent from various sources. Embedded systems must also be easily updated by downloading new applications or new utility modules or updates without interfering with already loaded applications.
[0020]
A first object of the present invention is to propose a loading method by firmly separating applications while allowing applications to cooperate with each other, developing applications, or allowing other applications to be loaded.
[0021]
The purpose of this is to create a virtual machine containing an intermediate pseudo-code type language interpreter from a station where application source code is written, compiled by a compiler as pseudo code, checked by a checker, converted by a converter, and loaded by a loader And an embedded system according to the present invention having an execution environment with an application programming interface (API).
The conversion includes a static linking implementation of a collection of multiple packages called modules, configured to be stored in the same namespace of the embedded system, assigning each module an identifier (MID), and included in the class of modules Assign a reference number to each class, each method, and each attribute
A method or attribute reference in the pseudocode linked to the module is encoded with 3 bytes consisting of an indicator that indicates the internal or external class reference of the module, the class number, and the method number or attribute number,
A module is one or more application programming modules (API modules) each containing a system class or service module corresponding to one application, and references to external classes are systematized by the virtual machine as references to application programming interface modules. It is characterized by interpretation.
[0022]
According to another feature, loading a module into an embedded system includes storing at least one display list of modules, associating a number with one module by a 0-n linker, and listing the module in the list. A table storing an index and an association of a display list index to an identifier (MID) of the module, the list and table comprising non-volatile programmable memory, and the external module in pseudo code The external reference is interpreted by the virtual machine interpreter as constituting an access index to a module that is equivalent to the index of the list of modules.
[0023]
According to another feature, the load includes storage of a display list for that class, including a reference to the index of the module for each module, and a display list of attributes and methods for each class.
[0024]
According to another feature, a module is referenced in a single module list, a system class is contained in a single API module, and any reference to an external class different from n in the pseudo code is said API module As a reference to
[0025]
According to another feature, a class is declared public or declared as a private package, attributes and methods are declared protected as a private package or class, and the class number order is public class Then, in the order of the private package class, the numbering of the attributes or methods is done by the converter in the order of the public attributes or methods protected as private packages and private classes.
[0026]
According to another feature, the system class is included in a plurality of API modules that can be loaded separately, the loader corresponds to two display lists of modules, one corresponding to the API module and the other corresponding to the non-API module. The two association tables MID / Imi are held in the nonvolatile programmable memory, and the loader loads the module into one of the two lists according to the property in the header of the special module. Any external reference is interpreted as an API module index reference.
[0027]
According to another feature, the static linking of the module is done so that references to non-API module external classes in the intermediate pseudo code are indices in the list of module headers, each input of which is referenced API module identifier (MID), the loading of the module on the target platform includes an alternative to the reference by the API module index number derived from the API module association table identifier (MID).
[0028]
Another feature of the present invention is to propose a corresponding embedded system.
[0029]
This object is achieved by an embedded system according to the present invention comprising a virtual machine, an API platform including an application programming interface, a non-volatile ROM, a non-volatile programmable or modifiable memory, and a RAM. The programmable memory includes at least one API module including a system class and a service module, at least one module display list indexing the module, and a table associating the module identifier of the display list with the module identifier. Each module includes a class display list in which each class is indexed and each class has a reference to that module's index. Contains a display list of attributes and methods indexed, where a method or attribute reference is encoded with at least 3 bytes corresponding to a module internal or external class reference, and the module external reference is an API module in the module list The class number corresponds to the class index in the module class display table, and the method or attribute number corresponds to the method or attribute index in the module class method or attribute display table. .
[0030]
According to another feature, a comparison means for comparing a first byte of 3 bytes encoding a reference to a method or an attribute with a predetermined value n to determine whether it relates to an inner class or an outer class. Including.
[0031]
According to another characteristic, it has a main module containing the main program of the system.
[0032]
According to another feature, classes are indexed in the order of public classes, then private package classes, attributes or methods are public attributes or methods, protected attributes or methods, private package attributes or methods, And indexed in order of private class.
[0033]
According to another feature, a non-volatile programmable memory comprises a plurality of API modules including a system class, two module display lists, one for API modules and the other for non-API modules, and a main module; Each includes two MID / IMi association tables corresponding to the module display list.
[0034]
According to another feature, the API module includes an access manager class “access manager” that includes a method capable of instantiating a service module via the main module, the class having one or more instances. Provide protection that prohibits things.
[0035]
Another object of the present invention is to propose a method for executing an application existing in a multi-application embedded system.
[0036]
This object is achieved by a method for executing an application of a multi-application embedded system having an execution environment comprising a virtual machine including an intermediate pseudo-code type language interpreter and an application programming interface (API). Supports one application that references a method or attribute reference in pseudocode encoded in at least 3 bytes corresponding to a reference to a class or external class, class number and method or attribute number in the module list When executing the intermediate pseudo code of the service module, the external reference of the module is interpreted by the virtual machine as a reference of the index of the API module in the list of one or more API modules. That.
[0037]
According to another feature, upon receiving a request to execute a service module having an identifier, the execution environment accesses an input class of the main module including the main program of the system, and the main module manages access to the service module. Install an instance of the API module special class "Access Manager" and use the methods of this class to request the service module via a table that associates an identifier with the module index in the list in which the module is referenced Can be instantiated, and the instance is returned to the main program by this method.
[0038]
Other features and advantages of the present invention will become more apparent upon reading the following description made with reference to the accompanying drawings.
[0039]
1-3, a method for implementing the present invention in a special type of embedded system, for example, but not limited to, a chip card or similar portable object will be described. A bytecode display or bytecode type program covers any pseudocode or intermediate program.
[0040]
The portable object comprises, for example, a chip card and has a structure similar to that described above with reference to FIGS. 4a and 4b, and in particular includes RAM, ROM, EEPROM. A special platform (60) and a conventional station (80) are shown in FIG. The special platform (60) has an execution environment (RE) that includes an API (62) and an embedded ("on-platform") virtual machine (61) in ROM. The special platform (60) is shown in FIG. 1 as containing a collection of ROM and EEPROM. Note that the special platform (60) specifically includes an execution environment (RE) and elements present in the EEPROM. The portable object has an operating system (63) in ROM. The API (62) existing in the ROM constitutes the basic API of the API platform, is loaded together with the embedded virtual machine, and operates the virtual machine.
[0041]
The portion (90) outside the portable object of the virtual machine includes an intermediate pseudo code checker (91), a converter (92), and possibly a signature device (94). The signing device sends a signature to validate the passage by checkers and converters. This signature is checked by the mobile object at the moment of loading. An application for complementing the basic API or loading of a new API into the EEPROM is performed by a loader. The loader can be composed of two parts called a downloader (93) and a part outside the portable object that can be installed in the virtual machine (90) outside the portable object, and a special platform part called the loader (68).
[0042]
According to the first embodiment, the special platform (60) includes two special modules, an API module (65) and a main module (66). The other module is called the service module (67). Each module corresponds to a set of packages stored in the same namespace. The API platform refers to a basic API (62) and a set of system classes that determine an API module (65) or API platform module. The main module includes a main class that determines a main program. Each module except the API module (65) has a specific single class called “entry class Entry Class” that constitutes an access point to the module. For the main module, this “entry class” is a main class (CP), and is a class including a static method called “main”. For a service module, it is a class that has only a configuration without parameters and implements a special public interface called “service” determined by the API platform. Application loading corresponds to service module loading. Each module receives a special identifier. Such a special identifier called MID can be, for example, a number, a string or a list. As an example, the identifier is a character string.
[0043]
When loaded into the platform by a different download mechanism than a special platform virtual machine, the module receives a number between 0 and n. Thus, according to this agreement, at most n + 1 modules can be present on a special platform. The module downloader (93) with the loader (68) maintains a module display list (TRM) (69) when loading a new service module. The number associated with the module is the index (IM) of this module in the list. The loader (68) also maintains a table (70) that associates an index (IM) with the identifier (MID) of each module. API module is index IM ₀ Systematically receives the number 0 for the main module index IM ₁ The number 1 is received. The header of each module determines whether the nature of the module is a “main” module, a “service” module, or an “API” module.
[0044]
The loader (68) can only load modules that are allowed to remain on the portable object, i.e. modules with signatures known to the portable object. Accordingly, the loader (68) includes means for checking the signature of the receiving module, comparing it with the known signature of the portable object, and blocking loading if the comparison is negative.
[0045]
Generally, as specified in the above prior art, the application source program (81) is written and then compiled by the compiler (82) and then checked by the checker (91).
[0046]
The static linking performed by a component called the converter linker in the converter (92) is
-A number (NCI) for each class of modules,
-A number (NM) for each method in the class,
Resolve symbol references by assigning a number (NA) for each attribute of the class.
[0047]
These numbers (NCI, NM, NA) are 0-n and can be indicated in bytes. For example, each number is 0-255 (n = 255). References to class methods or attributes are thus encoded in pseudocode linked in 2 bytes to the module method. The pseudo code includes “NCI” for these 2-byte classes, “NA” for attributes, or “NM” for methods.
[0048]
According to FIG. 3, the internal display of the API module (65), main module (66) or service module (67) includes a class display list (TRC). The number (NCI) associated with each class by the linker outside the embedded system is the index (ICi) of the display of this class in the class display list (TRC). Each class also has a reference to the module index (IMi). Similarly, the display of each class includes a method display list (TRMe) and an attribute display list (TRA) belonging to the class. The number (NM) associated with each method by the linker outside the embedded system is the index (IMi) of the display of this method in the method display list (TRMe), and the number associated with each attribute by the linker outside the embedded system. (NA) is an index (IAi) of display of this attribute in the attribute display list (TRA).
[0049]
For example, when a system class corresponds to a class in the traditional platform “classpath”, the module attempts to reference only its own class and the system class of the API platform. According to the present invention, an internal (II) or external (IE) indicator is used to identify a method or attribute in order to be able to distinguish between a module internal class reference and a system class (or module external class) reference. Appended to the reference. The resolved reference is then encoded with 3 bytes of “IE / II”, “NCI”, “NM” or “IE / II”, “NCI”, “NA”.
[0050]
According to the agreement above, for the value n of the first byte “IE / II”, this value, which in the example is 255, corresponds to the internal reference “II” of the module, and for the first byte Any other value corresponds to the module's external reference “IE”.
[0051]
The linker of the converter (92) of the virtual machine (90) outside the portable object first links the API module (65) which does not have the external reference “IE” in the pseudo code, and class and method and attribute symbols. Generate an arrangement or configuration corresponding to the name plan. When linking other modules, this arrangement is used to set an external reference to the system class of the API module (65).
[0052]
According to the byte convention of the present invention for encoding references, the API module has a maximum of 256 (n + 1) classes, and each additional module has 256 classes.
[0053]
When the service module is executed, when the virtual machine (61) knows the class “NCI” with the reference and refers to the method “NM” or the attribute “NA” in the pseudo code, the virtual machine is indexed of the module involved. “IMi” can be found directly and this module corresponds to an external reference (IE) or internal reference (II). Any external references (IEs) in the service module pseudo code are systematically interpreted by the virtual machine as API module references. The service module or main module cannot refer to any other module class except the API module class. The system class of the API module cannot refer to the service module or the main module class. The internal reference of the module class corresponding to the value n for the first byte need not know a priori the namespace assigned to the module. By not determining the fixed namespace a priori during the conversion phase, reference resolution can be accelerated and the module namespace can be determined during loading after the conversion phase. The virtual machine uses three consecutive indexes “IE / II”, “NCI”, “NM” or “IE / II”, “NCI”, “NA” when interpreting attribute or method references in pseudo code. Since the memory space of the module has been determined, the index “NCI” determines the desired entry in the module's class list (TRM), and then the last index “NM” or “NA” picture, method list (TRMe) ) Or attribute list (TRA).
[0054]
The API module includes a special class (64) called the “access manager” class, which is a unique method that serves to return an instance object of the requested service module input class from the module identifier (MID). (GetServiceInstance). This method uses the MID / IMi association table (70) to know the index of the module requested in the module list (69), then creates an instance of the input class for this module, return. In accordance with the present invention, the “Access Manager” class (64) is protected by design with a method consisting of prohibiting the class from having one or more instances. The unique method (getServiceInstance) belongs to the main program included in the main module. The main module that is activated first when using a portable object creates one instance and one “access manager” class, so this module can use the getServiceInstance method, For any service, creation of other instances to use this method is prohibited.
[0055]
The execution environment (RE), when activated, accesses the input class (EC) of the main module and activates the input method (main), as in the conventional platform. Since the main module is activated first, it installs an instance of the “Access Manager” class before any other services. This is because the main module must already have such an instance of the access class in order to operate other services.
[0056]
Such a simple device can recreate the protective effect coupled with the concept of the namespace of the conventional platform. The service module is loaded into the module list and the virtual machine interprets the presence of all external references in the pseudocode as API module references, so this module is never directly accessed by other modules. , Completely separated.
[0057]
The first embodiment described above provides an advantage that separation (PARE-FEU) can be obtained by separation of name spaces in the situation of a virtual machine having two parts. However, this embodiment is not flexible and has the following two drawbacks.
[0058]
First, any pre-linked modules prevent any modification or extension of the system class. The conventional “Java” architecture can modify and extend the API platform classes without affecting the already compiled classes of the additional modules. However, in the above embodiment, any modification of the system class will modify the configuration of the API platform, even if it is not displayed for foreign modules, and each link already linked to the traditional version of the configuration. Since it modifies the pre-linked pseudo code of the module, it is therefore necessary to modify the interpreter.
[0059]
Secondly, since pre-linked modules are assumed to be portable between various embedded platforms or terminals, each of these platforms must have the same configuration as the API platform, Extended use by any owner is prohibited.
[0060]
In order to partially eliminate these drawbacks, a variant of the first embodiment consists of imposing the public class first and before the private package class in the order of the number of placements. In addition, public methods or public attributes come before protected methods or attributes and methods or attributes in private packages and classes. Thereby, a new public class can be freely added to the API module (65).
[0061]
FIG. 2 shows a second embodiment in which the API platform can be developed. Instead of being composed of a single API module, the API platform is composed of a plurality of API modules (100) that can be loaded separately.
[0062]
In this embodiment, the downloader (93) and the virtual machine correspond to the service module (67) and the main module (66) instead of one each, and for the API module, the list (101). For the association table (102) and the non-API module, the two module lists of the list (103) and the association table (104) and the two MID / index association tables are shared.
[0063]
Each module has an indicator “service” or “API” in its header that allows the loader to load the module into a list of API modules (101) or a list of non-API modules (103). This indicator is placed in the header of the module during the compilation phase by the converter.
[0064]
The separation consisting of namespace separation (PARE-FEU) exists only between non-API modules. Any external reference to the service module is interpreted by the embedded virtual machine interpreter as an index into the list of API modules.
[0065]
Non-API modules are numbered from 0 to a maximum of 255 in the n = 255 example, where 0 is the index of the main module (66), for example. The API module (100) is numbered from 0 to a maximum of 254, where 0 is, for example, the index of the so-called primary API module and includes any unique methods. According to the above agreement, this allows up to 255 (n) different modules on the API platform. A method or attribute reference in the pseudo code is as follows:
[0066]
"" IE / II "" NCI "" NM / NA ""
The value 255 (n) for the first byte indicates the internal reference of the module, as in the first embodiment. Each value different from 255 indicates an external reference of the special module (100) in the API module list of the API platform.
[0067]
After linking is performed by the off-platform linker (92), the module pseudo-code includes a header with a reference module list that is used to link the current module. The reference module list includes a maximum of 255 inputs, each input corresponding to an identifier (MID) of the API module (100). In that case, the first byte of the external reference in the pseudo code is the index in this list. Since the index number associated with the API module (100) is known when loading into the non-API module platform (67, 66), the first byte of the external reference is the MID- of the API module (100). By using the IMi association table (102), the index number associated with the referenced API module is substituted. Such an alternative is a single linking operation performed by the loader (68) on a special platform, and the MID / IMi association table (102) is only used to perform this linking operation.
[0068]
For example, in the pseudo code of the service module “TEST”, it is assumed that the method number 5 of the API module class number 7 is referred to and the identifier (MID) is “F00”. Further, it is assumed that “F00” is an identifier of the fourth API external module referred to by the service module “TEST”. In that case, the reference in the pseudo code consists of three values 3, 7, 5.
[0069]
The number 3 corresponds to the fourth index in the reference module list existing in the header of the module sent to the beginning of the pseudo code, and the value of this input is the identifier (MID) “FOO”. Assume that when loading the API module “FOO”, the internal index 34 has been assigned to the target platform in the API module association table (102). In that case, the loader (68) modifies the reference with the pseudo code of the service module “TEST” using the association table (102) so that it becomes 34, 7, and 5.
[0070]
During execution of the module pseudocode, the module's external reference is systematically interpreted as input in the API module table by the virtual machine. The modules in the non-API module list are hidden from each other and to the API modules. Such a simple device can recreate the protective effect coupled with the concept of the namespace of the conventional platform. By simply loading the module into the non-API module list, this module is never accessed directly from other modules and is completely separated.
[0071]
The list of API modules (101) includes a special module (105) called the “API access” module. This module includes a unique method (getServiceInstance) that serves to return an instance object of the input class of the requested service module. This method uses the MID / IMi association table (104) to know the index of the service module requested in the non-API module list (103), then instantiates the input class of this module and This instance is returned by the method of. The recommended safe practice is to form a protected class from the "Access Manager" class that declares the designers and methods protected. Furthermore, the “API access” module (105) has an “access manager” class. More than one Includes protection consisting of prohibiting having instances. This method is dedicated to the main program obtained in the main module (66). Since the first activated primary module creates an instance of the access manager module, this module can use the getServiceInstance method, but all other services are prohibited from creating other instances to use this method. It is done. Thus, the main module can create a service instance.
[0072]
Several methods can be used to obtain this protection, which consists in prohibiting the “access manager” class from having only one instance. The class designer, for example, can block an instance creation request if one already exists and start a safety exception. The execution environment (RE), in operation, accesses the input class of the main module (66) and activates the input method (main). Since the main module is activated first, it installs an instance of the “Access Manager” class before any other services.
[0073]
In order to allow service modules to work with other service modules, these strict safety measures are modified to add public classes to the “access manager” class of the API access module (105), where every module Requests may be made. These public classes include, among other things, static methods that can yield a single instance. A module that accesses an instance object of the "Access Manager" class can run and use another service module, but a direct reference to that class, method or attribute requires a reference by the virtual machine. is necessary. This is because all external references in the pseudo code are internal references of this module or external references of the API module.
[0074]
To easily implement this solution, it is necessary to avoid having circular references in the API module. Thus, the temporary closure of the relationship “refers to” must be in the reverse, partly reverse order, in the module set. Thus, in the converter (92) linker, a simple policy is designed in the converter (92) linker to combine and generate API module configurations by first processing the minimal elements that are not yet linked. can do. The same policy based on partial order can be followed for downloading API modules, so when downloading module M, all referenced modules are already downloaded, and numbers are assigned to them. Yes. The internal index assignment in the target platform is made by the module loader (68) by assigning the index n-1 to the nth order API. An API module cannot reference another API module with a larger index.
[0075]
By using this system with duplicated module lists (101, 103) and association tables (102, 104), a single API module can be easily replaced by multiple API modules that can be loaded separately. By replacing a single API module with multiple API modules, the API platform can be extended with new modules without changing the assembly of already loaded modules and without changing the security provided by separation. it can. Of course, the two embodiments are not compatible. Modules must be pre-linked specifically to any of the embodiments, and the pseudocode for one embodiment is not supported on the platform that implements the other embodiment. Moreover, the interpreter of the virtual machine differs depending on the embodiment. In the first embodiment, the virtual machine operates only one list and one association table. The first byte of the reference is interpreted by the virtual machine as an internal reference for all values equal to n and as a single API module external reference for all values different from n. In the second embodiment, the virtual machine operates two lists and two association tables. The first byte of reference in the pseudo code is interpreted by the virtual machine as an internal reference for all values equal to n, and all values different from n are considered directly as indexes in the API module list. In two embodiments, a virtual machine interpreter compares a first byte of 3 bytes that encodes a method or attribute reference with a predetermined value n and relates to an internal class of a module or to an external class. To decide. The order of the API modules is determined next to loading, so that external references in the pseudo code can be fixed finally and very simply.
[0076]
The same mechanism is used to operate the two types of modules, although the methods used and the resulting security are quite different. All modules have free access to the API module because the class is a system class. The use of a modular approach is used with service modules to obtain a strict separation that protects these modules from any direct access.
[0077]
The method according to the invention can be implemented with any type of form object with small resources, for example 16ko ROM, 8ko EEPROM, 256k RAM.
[0078]
Other modifications that can be understood by those skilled in the art are also part of the intent of the present invention.
[Brief description of the drawings]
FIG. 1 is a diagram schematically showing various elements necessary for loading a form object according to the first embodiment.
FIG. 2 is a diagram schematically showing various elements necessary for loading a form object according to the first embodiment.
FIG. 3 is a diagram showing the inside of a module.
FIG. 4a is a diagram showing a conventional configuration of a chip card.
FIG. 4b is a diagram showing a system necessary for the configuration of a virtual machine incorporated in a chip card according to the prior art.
FIG. 4c is a diagram showing the structure of an application class.

Claims

From the station where the application source code is written, compiled as pseudo code by the compiler (82), checked by the checker (91), converted by the converter (92), and loaded by the loader (93, 68), intermediate pseudo A method of loading an application into an embedded system having an execution environment with a virtual machine including an interpreter for a code type language and an application programming interface (API), comprising:
The conversion includes a static linking implementation of multiple sets of packages called modules, configured to be stored in the same namespace of the embedded system, assigning an identifier (MID) to each module by the converter, and assigning the module class Assign a reference number (NCI) to each class (NCI), each method (NM), and each attribute (NA) that enters
References to methods or attributes in pseudocode linked to modules include module internal class (II) or external class (IE) reference, class number (NCI), method number (NM) or attribute number (NA) Are encoded with 3 bytes consisting of an indicator indicating
The loaded modules are one or more application programming modules, each containing a system class or service module corresponding to one application, and the external class reference (IE) is a virtual machine as a reference to the application programming interface module. A method characterized by being interpreted by:

Load modules to the embedded system comprises a while the storage of the list (69,101,103) which represents the module number between index modules in the list of 0~n associated with the module by the linker (IMi) and including storage of tables (70, 102, 104) that store display module index associations of the identifiers (MIDs) of the modules, the lists and tables from a non-volatile programmable memory The external reference (IE) to the external module in the pseudo code is interpreted by the virtual machine interpreter as constituting an index equivalent to the index of the list of modules. Application to embedded system De way.

The load includes, for each module, storage of a display list of classes (TRC), including a reference to the index of the module, and for each class, storage of display lists of attributes (TRA) and methods (TRMe). The method of loading an application into the embedded system according to claim 2, wherein the application is loaded.

A module is referenced in a single module list, a system class is contained in a single API module, and any reference to an external class different from n in the pseudo code is interpreted by the virtual machine as a reference to the API module The method of loading an application into an embedded system according to claim 2, wherein:

A class is declared public or declared as a private package, attributes and methods are declared protected as private packages or private classes, and the class number order 5. The order of attributes or methods is performed by the converter (92) in order of public or private package protected and private class protected attributes or methods. To load an application into an embedded system.

The system class is contained in a plurality of API modules that can be loaded separately, and the loader (68) holds two display lists of the module and two association tables MID / Imi corresponding to the nonvolatile programmable memory. One for an API module and the other for a non-API module, where the loader is one of two lists depending on the nature of the module specified in the header, a list of API modules or a non-API module 3. A method for loading an application into an embedded system according to claim 2, wherein the module is loaded into a list of modules, and any external reference of a module in the module list is interpreted as a reference to an index of an API module.

Module static linking is performed by the loader, and the module pseudocode includes a header with a list of referenced modules used to link the current module, each entry in the list being an API module identifier ( corresponding to mID), reference to an external class non API module in the intermediate pseudocode is an index in the list, loading of non-API module to the target platform, the API module mID / IMi association table identifier (mID 7. The method of loading an application into an embedded system according to claim 6, including replacement of the reference by an API module index number obtained from (1).

An embedded system including a virtual machine, an API platform including an application programming interface, a nonvolatile ROM, a nonvolatile programmable or modifiable memory, and a RAM, wherein the nonvolatile programmable memory is a system class And at least one API module including the service module, at least one module display list (TRM) indexed to the module, and a table that associates the module index (IM) of the display list with the module identifier (MID). Each module includes a class display list (TRC) in which each class is indexed and each class has a reference to its index (IM), The class contains a display list of attributes (TRA) and methods (TRMe) indexing attributes and methods, where the method or attribute reference corresponds to the module's internal class (II) or external class (IE) reference The module external reference constitutes an API module index in the module list, the class number (NCI) corresponds to the class index in the module class display table, and the method (NM ) Or attribute (NA) number corresponds to the method or attribute index in the module class method or attribute display table.

Comparing means for comparing a first byte of 3 bytes that encodes a reference to a method or an attribute with a predetermined value n to determine whether it is related to an inner class or an outer class Item 9. The embedded system according to Item 8.

The embedded system according to claim 8, further comprising a main module including a main program of the system.

The class is indexed in the order of the public class, then the private package class, and the attributes or methods are public attributes or methods, protected attributes or methods, private package attributes or methods, and attributes or attributes in the private class. 9. The embedded system of claim 8, wherein the system is indexed in order of method.

A plurality of API modules including a system class and two module display lists (101, 103), one for the API module and the other for the non-API module and the main module, and two corresponding to the module display list The embedded system according to claim 11, characterized in that the non-volatile programmable memory includes the MID / IMi association table (102, 104).

It includes an access manager class “access manager” of the API module (105) including methods capable of instantiating a service module via a main module, and the class “access manager” is the class “access manager”. The embedded system of claim 10, comprising protection that prohibits having more than one instance.

A method for executing an application of a multi-application embedded system having an execution environment including a virtual machine including an interpreter of an intermediate pseudo code type language and an application programming interface (API), the module internal class (II) Or a reference to an external class (IE) and a method or attribute reference in pseudocode encoded with at least 3 bytes corresponding to the class number (NCI) and the method (NM) or attribute number (NA). When executing the intermediate pseudo code of the service module corresponding to one application that is referred to in the module list, the external reference of the module is referred to the API module index in the list of one or a plurality of API modules by the virtual machine. Is interpreted Te, it interpreted intermediate pseudocode method characterized in that it is executed by the microprocessor.

When the execution request of the service module having the identifier (MID) is received, the execution environment accesses the input class of the main module including the main program of the system, and the main module manages the special access to the service module. By installing an instance of the class "Access Manager" and using the methods of this class, the input class of the requested service module's input class is passed through a table that associates an identifier with the module's index in the list in which the module is referenced. 15. The application execution method of a multi-application embedded system according to claim 14, wherein an instance can be generated, and the instance is returned to the main program by the method.