(57)【要約】      （修正有）【課題】Ｘｌｅｔ間通信（ＩＸＣ）のために、結合されたオブジェクトのレジストリを管理するためのコンピュータによる方法。【解決手段】エクスポートされたオブジェクト名をリモート参照と結合する要求が、第１のＸｌｅｔから受信される。第１のＸｌｅｔによってエクスポートされたオブジェクトの数が、最大数と比較される。エクスポートされたオブジェクトの数が、最大数よりも小さい場合には、エクスポートされたオブジェクト名とリモート参照との結合が追加される。エクスポートされたオブジェクトの数が、最大数よりも大きい場合には、要求は拒否される。【選択図】図３
2007128507.tif 000002
【特許請求の範囲】
【請求項１】
Ｘｌｅｔ間通信（ＩＸＣ）のために、結合されたオブジェクトのレジストリを管理するためのコンピュータによる方法であって、
エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合する要求を、第１のＸｌｅｔから受信する工程と、
前記第１のＸｌｅｔによってエクスポートされたオブジェクトの数を、最大数と比較する工程と、
前記エクスポートされたオブジェクトの数が、前記最大数よりも小さい場合に、前記エクスポートされたオブジェクトの前記オブジェクト名と前記リモート参照との結合を追加する工程と、
前記エクスポートされたオブジェクトの数が、前記最大数以上である場合に、前記要求を拒否する工程と、を備える、方法。
【請求項２】
請求項１に記載の方法であって、前記要求は、リモート参照オブジェクトを含み、前記受信工程は、ＪＡＶＡ（登録商標）オブジェクト直列化によって前記リモート参照オブジェクトを受信する工程を備える、方法。
【請求項３】
請求項１に記載の方法であって、さらに、
前記エクスポートされたオブジェクトの前記リモート参照への要求を、第２のＸｌｅｔから受信する工程と、
前記第２のＸｌｅｔからの前記要求の受信に応じて、前記第２のＸｌｅｔに前記リモート参照を送信する工程と、を備える、方法。
【請求項４】
請求項３に記載の方法であって、前記リモート参照は、別のアイソレートのＸｌｅｔが、前記エクスポートされたオブジェクトに接触することを可能にするのに十分な情報を備える、方法。
【請求項５】
請求項３に記載の方法であって、前記リモート参照は、さらに、前記エクスポートされたオブジェクトの型を示すインターフェース記述子を備える、方法。
【請求項６】
請求項１に記載の方法であって、さらに、
Ｘｌｅｔが停止した場合に、前記停止したＸｌｅｔによってエクスポートされたオブジェクトの結合を削除する工程と、
前記停止したＸｌｅｔをインポートしたＸｌｅｔを特定する工程と、
前記停止したＸｌｅｔをインポートした前記Ｘｌｅｔに、前記停止したＸｌｅｔによってエクスポートされた前記オブジェクトが停止したことを通知する工程と、を備える、方法。
【請求項７】
Ｘｌｅｔ間通信（ＩＸＣ）のためのコンピュータによる方法であって、
第１のアイソレート内の第１のＸｌｅｔからエクスポートされたオブジェクトへのリモート参照を、前記第１のアイソレートの外に位置するオブジェクトレジストリに送信する工程と、
前記オブジェクトレジストリ内で前記リモート参照と前記エクスポートされたオブジェクトのオブジェクト名とを結合する工程と、
前記エクスポートされたオブジェクトの前記リモート参照への要求を、第２のアイソレート内の第２のＸｌｅｔから送信する工程と、
前記要求に応じて、前記第２のＸｌｅｔに前記リモート参照を転送する工程と、
前記第２のＸｌｅｔのためのスタブオブジェクトのインスタンスを生成する工程と、を備え、前記スタブオブジェクトは、前記エクスポートされたオブジェクトと通信を行い、
前記オブジェクトレジストリは、選択された結合数に各Ｘｌｅｔを制限する、方法。
【請求項８】
請求項７に記載の方法であって、前記リモート参照は、オブジェクトであり、Ｘｌｅｔ間で送信され、前記オブジェクトレジストリは、ＪＡＶＡ（登録商標）オブジェクト直列化を用いる、方法。
【請求項９】
請求項７に記載の方法であって、さらに、
前記エクスポートされたオブジェクトによって提供されたインターフェースが、前記第２のＸｌｅｔによって予期されたインターフェースと一致することを保証するために、前記リモート参照を型検査する工程と、
前記予期されたオブジェクトが、以前にインポートされていない型を有する場合に、前記インターフェースのためのスタブクラスを生成する工程と、を備え、前記スタブオブジェクトのインスタンスを生成する工程は、前記スタブクラスのインスタンスを生成する工程を備える、方法。
【請求項１０】
請求項７に記載の方法であって、さらに、
Ｘｌｅｔが停止した場合に、前記停止したＸｌｅｔによってエクスポートされたオブジェクトの結合を削除する工程と、
前記停止したＸｌｅｔによってエクスポートされたオブジェクトをインポートしたＸｌｅｔを特定する工程と、
前記停止したＸｌｅｔによってエクスポートされた前記オブジェクトに対応するスタブオブジェクトを破棄する工程と、を備える、方法。
【請求項１１】
請求項７に記載の方法であって、前記オブジェクトレジストリは、アプリケーションマネージャによってエクスポートされたオブジェクトであり、前記リモート参照を送信する工程は、ＩＸＣを用いて前記リモート参照を前記オブジェクトレジストリに送信する工程を備える、方法。
【請求項１２】
請求項７に記載の方法であって、前記リモート参照は、エクスポート側Ｘｌｅｔ識別子と、エクスポート側Ｘｌｅｔエンドポイント識別子と、インターフェース記述子と、を備える、方法。
【請求項１３】
請求項１２に記載の方法であって、前記インターフェース記述子は、前記エクスポートされたオブジェクトによって提供されたインターフェースの型を示し、前記型は、メソッド名と、各メソッドに対する少なくとも１つのパラメータ型と、各メソッドに対する戻り型と、を備える、方法。
【請求項１４】
請求項１３に記載の方法であって、さらに、
以前にインポートされたオブジェクトの中で同じ型を有するオブジェクトがない場合に、前記型に対応するスタブクラスを生成する工程を備え、前記スタブオブジェクトのインスタンスを生成する工程は、前記スタブクラスのインスタンスを生成する工程を備える、方法。
【請求項１５】
アイソレート間でのオブジェクト指向のＸｌｅｔ間通信（ＩＸＣ）のためのプログラム命令を有するコンピュータ読み取り可能な媒体であって、
第１のＸｌｅｔからオブジェクトをエクスポートするためのプログラム命令であって、前記エクスポートは、前記エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合する要求を、前記第１のＸｌｅｔからオブジェクトレジストリに送信する工程を備えるプログラム命令と、
前記第１のＸｌｅｔによってエクスポートされたオブジェクトの数を、最大数と比較するためのプログラム命令と、
前記エクスポートされたオブジェクトの数が、前記最大数よりも小さい場合に、前記エクスポートされたオブジェクトの前記オブジェクト名と前記リモート参照との結合を前記オブジェクトレジストリに追加するためのプログラム命令と、
前記エクスポートされたオブジェクトの数が、前記選択された最大数以上である場合に、前記要求を拒否するためのプログラム命令と、を備える、コンピュータ読み取り可能な媒体。
【請求項１６】
請求項１５に記載のコンピュータ読み取り可能な媒体であって、前記要求は、リモート参照オブジェクトを備え、前記受信は、ＪＡＶＡ（登録商標）オブジェクト直列化によって前記リモート参照オブジェクトを受信する工程を備える、コンピュータ読み取り可能な媒体。
【請求項１７】
請求項１５に記載のコンピュータ読み取り可能な媒体であって、さらに、
前記エクスポートされたオブジェクトの前記リモート参照への要求を、第２のＸｌｅｔから前記オブジェクトレジストリに送信するためのプログラム命令と、
前記第２のＸｌｅｔからの前記要求に応じて、前記第２のＸｌｅｔに前記リモート参照を送信するためのプログラム命令と、
前記エクスポートされたオブジェクトに対応するスタブオブジェクトのインスタンスを生成するためのプログラム命令と、を備える、コンピュータ読み取り可能な媒体。
【請求項１８】
請求項１７に記載のコンピュータ読み取り可能な媒体であって、さらに、
前記エクスポートされたオブジェクトによって提供されたインターフェースが、前記第２のＸｌｅｔによって予期されたインターフェースと一致することを保証するために、前記リモート参照を型検査するためのプログラム命令を備える、コンピュータ読み取り可能な媒体。
【請求項１９】
請求項１７に記載のコンピュータ読み取り可能な媒体であって、前記リモート参照は、別のアイソレートのＸｌｅｔが、前記エクスポートされたオブジェクトに接触することを可能にするのに十分な情報を備える、コンピュータ読み取り可能な媒体。
【請求項２０】
請求項１９に記載のコンピュータ読み取り可能な媒体であって、前記リモート参照は、エクスポート側Ｘｌｅｔ識別子と、エクスポート側Ｘｌｅｔエンドポイント識別子と、インターフェース記述子と、を備える、コンピュータ読み取り可能な媒体。
【請求項２１】
請求項２０に記載のコンピュータ読み取り可能な媒体であって、さらに、
以前にインポートされたオブジェクトの中で同じインターフェース記述子を有するオブジェクトがない場合に、前記インターフェース記述子に対応するスタブクラスを生成するためのプログラム命令を備え、前記スタブオブジェクトのインスタンスを生成するためのプログラム命令は、前記スタブクラスのインスタンスを生成する、コンピュータ読み取り可能な媒体。
【請求項２２】
請求項１５に記載のコンピュータ読み取り可能な媒体であって、さらに、
Ｘｌｅｔが停止した場合に、前記停止したＸｌｅｔによってエクスポートされたオブジェクトの結合を削除するためのプログラム命令と、
前記停止したＸｌｅｔをインポートしたＸｌｅｔを特定するためのプログラム命令と、
前記停止したＸｌｅｔをインポートした前記Ｘｌｅｔに、前記停止したＸｌｅｔによってエクスポートされた前記オブジェクトが停止したことを通知するためのプログラム命令と、を備える、コンピュータ読み取り可能な媒体。
【請求項２３】
請求項１５に記載のコンピュータ読み取り可能な媒体であって、前記オブジェクトレジストリは、アプリケーションマネージャによってエクスポートされたオブジェクトであり、前記リモート参照を送信する動作は、ＩＸＣを用いて前記リモート参照を前記オブジェクトレジストリに送信する動作を備える、コンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
携帯電話、携帯情報端末（ＰＤＡ）、テレビ用のセット・トップ・ボックスなどのコネクテッド・デバイスのためのコンピュータシステムは、より柔軟なものになりつつある。最近のシステムでは、ソフトウェアをダウンロードして実行することが可能になっている。ダウンロードされたソフトウェアは、完全に信頼できるとは限らず、既存の信頼できるソフトウェアとリソースを共有する場合もある。したがって、信頼できないソフトウェアのアクセスを制限することにより、そのソフトウェアがシステムの動作を妨害することを防ぐために、様々な技術が提案および実施されている。しかしながら、これらのシステムの目的は、ソフトウェア・コンポーネントが互いに通信することを可能にするという別の目標と対立するものである。
【０００２】
ソフトウェア・コンポーネントが互いに通信することを可能にするための周知の機構の１つとして、リモート・プロシージャ・コール（ＲＰＣ）が挙げられる。この機構によると、あるホスト上で実行中のコンピュータプログラムが、別のホスト上でコードを実行させて、その結果を第１のプログラムに返させることが可能になる。通例、ＲＰＣプロトコルは、分散コンピューティングのクライアントサーバモデルを実装するために用いられる。
【０００３】
様々なエディションのＪＡＶＡ（登録商標）プラットフォームが、オブジェクト間の通信のために、ＲＰＣを実行するためのリモートメソッド呼び出し（ＲＭＩ）として知られる機構を提供している。ＲＭＩでは、リモートＪＡＶＡ（登録商標）オブジェクトのメソッドは、別のＪＡＶＡ（登録商標）仮想マシン（場合によっては、別のホスト上のもの）から呼び出し可能である。図１に示すように、ＲＭＩ １００は、基本的に、ＪＡＶＡ（登録商標）仮想マシン（ＪＶＭ） Ａ １０２およびＪＶＭ Ｂ １０４の間の通信を可能にする。ＪＶＭ Ａ １０２およびＪＶＭ Ｂ １０４は、同じ物理マシンで作動してもよいし、異なるマシンで作動して、ローカルエリアネットワーク（ＬＡＮ）、インターネットプロトコル（ＩＰ）ネットワーク接続、または、その他の通信媒体を介して接続されてもよい。ＲＭＩ １００を実装するアプリケーショ・プログラム・インターフェース（ＡＰＩ）は、仮想マシン間の通信の詳細を取り扱う。
【０００４】
ＲＭＩは、異なるプロトコルでの異なるマシン間の通信のために必要なコンポーネントおよびセキュリティ手段をすべて備えるため、複雑になっており、ほとんどのコネクテッド・デバイスでは全く必要のない多くの特徴を提供することから、小型のデバイスにとっては扱いにくい場合がある。したがって、ＲＭＩ ＡＰＩは、ＪＡＶＡ（登録商標）２プラットフォームのマイクロエディション（Ｊ２ＭＥ）のパーソナル・ベイシス・プロファイル（ＰＢＰ）には含まれていない。
【０００５】
ＪＡＶＡ（登録商標）アプリケーションのための従来のモデルは、所与の仮想マシンで実行中のアプリケーションが１つだけであることを想定しているため、そのアプリケーションは、自身が動作している仮想マシンの強制終了を含めて、自身のライフサイクルを完全に管理する。典型的なコネクテッド・デバイスで利用可能な限られた処理リソースおよびメモリリソースに対応した上で、複数のプログラムを同時に実行させることを可能にするために、ＪＡＶＡ（登録商標）コミュニティプロセス（ＪＣＰ）は、Ｘｌｅｔと呼ばれるプログラミングモデルの利用を提案した。
【０００６】
Ｘｌｅｔは、インターネットウェブブラウザによって実行可能なアプレットや、ウェブサーバによって実行可能なサーブレットと同様のものであり、複数のＸｌｅｔが、１つのＪＶＭで同時に実行されることが可能であり、それらのライフサイクルは、他のプログラムによって管理可能である。アプレットの場合には、他のプログラムとは、一般に、ウェブブラウザである。ＪＶＭの１つのインスタンスで複数のプログラムを実行すると、仮想マシンの内部データ構造の一部を共有することにより、システム全体の性能および拡張性を向上させることができる。Ｘｌｅｔは、スタンドアロンのアプリケーションマネージャによって管理されてよい。
【０００７】
１つのＪＶＭによって複数のＸｌｅｔを作動させることがでるため、ダウンロードされた悪質なＸｌｅｔによる害を受ける可能性のある複数組のＸｌｅｔを保護するための機構が必要となった。そのため、論理仮想マシン（ＬＶＭ）の概念が生み出された。ＬＶＭは、同じリソースまたはオブジェクトを共有する１または複数のプログラムからコードを参照するための機構を提供するリソースコンテキスト構造である。ある特定のＬＶＭに関連スレッドを関連付けることにより、関連スレッドが（例えば、サービス妨害攻撃を起こすことにより）不正な動作をした際に、それらを一緒に終了できるようになる。
【０００８】
しかしながら、複数のＸｌｅｔを別々のＬＶＭに分離することによって保護することは、互いの通信を不可能することを意味するため、望ましくない。したがって、別々のＬＶＭ、より一般的には、別々のリソースドメインから、複数のＸｌｅｔが互いに通信することを可能にするためのいくつかの機構が必要になった。２００４年１２月７日に発行された米国特許６，８２９，７２２は、複数のＸｌｅｔが別々のＬＶＭから互いに通信することを可能にするＸｌｅｔ間通信（ＩＸＣ）と呼ばれる方法を提供しており、この参照によって本明細書に組み込まれる。この特許の出願時には、「Ｘｌｅｔ」という用語は、まだ作られていなかったため、その明細書では、Ｘｌｅｔを、一般に用いられていた「アプレット」という用語で呼んでいることに注意されたい。
【０００９】
ＩＸＣ ＡＰＩは、現在、Ｊ２ＭＥ ＰＢＰの一部である。図２は、別々のＬＶＭにそれぞれ属する２つのＸｌｅｔ（すなわち、Ｘｌｅｔ Ａ １１２およびＸｌｅｔ Ｂ １１４）の間のＩＸＣ １１０を示す図である。しかしながら、このＩＸＣ実装は、単一プロセスの複数仮想マシン（ＭＶＭ）パラダイムと呼ばれるものに限定される。このパラダイムでは、各ＬＶＭ １１６および１１８は、単一プロセスＪＶＭ １２０で実行され、共通アドレス空間を共有する。ＩＸＣ実装（図示せず）は、各ＬＶＭ間でインスタンスを共有するために共通アドレス空間を利用する。
【００１０】
Ｘｌｅｔを実行するための分離コンテキストは、現在、「アイソレート」と呼ばれている。アイソレートの一実施例では、各アイソレートは、自身のプロセス内で実行されるため、自身のアドレス空間を有する。これは、「複数プロセスのＭＶＭ」パラダイムと呼ばれてよい。ＪＡＶＡ（登録商標）アプリケーションアイソレートＡＰＩは、ＪＡＶＡ（登録商標）仕様作成要求１２１（ＪＳＲ−１２１）で規定されている。ＩＸＣのための以前の機構は、Ｘｌｅｔ間で共通アドレス空間を利用していたため、この新しいパラダイムでの実装は構造的に不可能であった。
【００１１】
したがって、サービス妨害攻撃を防止するために必要なセキュリティ手段を提供しつつ、Ｘｌｅｔ間のＲＰＣが、共通のＪＶＭにおける別々のアイソレートに配置されることを可能にする新しいＩＸＣ機構が必要とされている。この新しい機構は、さらに、信頼性の高いガーベッジコレクションと、効率的な型検査とを提供することが好ましい。さらに、ＩＸＣ実装は、アイソレート実装に対して最適化されることが好ましく、その場合、複数のアイソレートは、同一のマシン上であるが別々のアドレス空間に存在する。
【発明の開示】
【００１２】
概して、本発明は、これらの要求を満たすために、アイソレート間でのオブジェクト指向通信を実現する方法およびマシン読み取り可能な媒体を提供する。
【００１３】
本発明は、プロセス、装置、システム、デバイス、方法を含む数多くの態様で実施可能であることを理解されたい。以下では、本発明のいくつかの実施形態について説明する。
【００１４】
一実施形態では、Ｘｌｅｔ間通信（ＩＸＣ）のために、結合されたオブジェクトのレジストリを管理するためのコンピュータによる方法およびマシン読み取り可能な媒体が提供されている。エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合する要求が、第１のＸｌｅｔから受信される。第１のＸｌｅｔによってエクスポートされたオブジェクトの数が、最大数と比較される。エクスポートされたオブジェクトの数が、最大数よりも小さい場合には、エクスポートされたオブジェクトのオブジェクト名とリモート参照との結合が追加される。エクスポートされたオブジェクトの数が、最大数よりも大きい場合には、要求は拒否される。
【００１５】
別の実施形態では、Ｘｌｅｔ間通信（ＩＸＣ）のための方法が提供されており、第１のアイソレート内の第１のＸｌｅｔからエクスポートされたオブジェクトへのリモート参照が、第１のアイソレートの外に位置するオブジェクトレジストリに送信される。オブジェクトレジストリ内で、リモート参照と、エクスポートされたオブジェクトのオブジェクト名とが結合される。オブジェクトレジストリは、エクスポートされたオブジェクトのリモート参照への要求を、第２のアイソレート内の第２のＸｌｅｔから受信する。それに応じて、リモート参照が、第２のＸｌｅｔに転送される。第２のＸｌｅｔのためにスタブオブジェクトが生成され、そのスタブは、エクスポートされたオブジェクトと通信を行う。オブジェクトレジストリは、ある結合数に各Ｘｌｅｔを制限する。
【００１６】
さらに別の実施形態では、アイソレート間でのオブジェクト指向のＸｌｅｔ間通信（ＩＸＣ）のためのプログラム命令を有するコンピュータ読み取り可能な媒体が提供されている。そのコンピュータ読み取り可能な媒体は、第１のＸｌｅｔからオブジェクトをエクスポートするためのプログラム命令であって、そのエクスポートは、エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合する要求を、第１のＸｌｅｔからオブジェクトレジストリに送信する動作を備えるプログラム命令と、エクスポートされたオブジェクトの数が、最大数よりも小さい場合に、エクスポートされたオブジェクトのオブジェクト名とリモート参照との結合をオブジェクトレジストリに追加するためのプログラム命令と、エクスポートされたオブジェクトの数が、選択された最大数以上である場合に、要求を拒否するためのプログラム命令と、を備える。
【００１７】
本発明の利点は、実施例を用いて本発明の原理を示すために添付の図面を参照しつつ行われる以下の詳細な説明から明らかになる。
【００１８】
本発明は、添付の図面を参照した以下の詳細な説明によって容易に理解可能であり、同じ符号は、構造上の同じ要素を示している。
【発明を実施するための最良の形態】
【００１９】
以下の説明では、本発明の完全な理解を促すために、多くの詳細事項が具体的に示されている。しかしながら、これらの具体的な詳細事項の一部またはすべてがなくとも、本発明を実現できることは、当業者にとって明らかである。また、本発明を不必要にわかりにくくすることがないよう、周知のプロセス動作および実装の詳細事項の説明は省略してある。
【００２０】
本発明は、アイソレート間でのオブジェクト指向通信に関する。アイソレートは、コンピュータシステム内の保護されたドメインであり、１または複数のスレッドを、そのシステムで作動する他の悪質なスレッドによる悪影響から保護する。ＪＡＶＡ（登録商標）仕様作成要求１２１（ＪＳＲ−１２１）では、アイソレートは、スレッドとＪＡＶＡ（登録商標）仮想マシン（ＪＶＭ）との間の中間構造体として記載されている。より具体的には、ＪＡＶＡ（登録商標）パーソナル・ベイシス・プロファイルのコンテキスト中のアイソレートは、アプリケーションまたはコンポーネントをカプセル化するアイソレートクラスのインスタンスであり、演算処理の分離を開始および停止するための手段を提供する。例えば、アイソレートを用いて、同時実行を開始することができる。ＪＶＭのように、アイソレートは、実行中の可能性がある任意の他のＪＡＶＡ（登録商標）プログラムと無関係に、与えられたクラスの「メイン」メソッドの実行を自身のシステムレベルのコンテキスト内で進めさせる。このように、アイソレートは、スタティックまたはアプリケーションごとのランタイムオブジェクトを共有することから干渉がないことを保証する点でスレッドとは異なり、作成、開始、終了、監視、および、これら独立した動作との通信を行うアプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供する点でＪＶＭとは異なる。アイソレートは、それらの中で作動するアプリケーションに対して透過的に作動してよい。本開示では、「アイソレート」という用語は、単に、自身のプロセス内で実行されるために自身のアドレス空間を有する仮想マシン内の保護されたドメインを特定するために用いられてよい。
【００２１】
オブジェクト指向通信とは、ソフトウェアオブジェクト間の通信のことである。ソフトウェアオブジェクトとは、実行可能なコードおよびデータを備えるソフトウェア構造体であり、変数内に保持される。データは、オブジェクト内で保護されており、オブジェクトによって提供されるメソッドを用いてアクセス可能である。それらのメソッドは、プロシージャを実行するために、他のオブジェクトによって呼び出すことが可能である。それらのメソッドは、オブジェクトによって変数に提供されるインターフェースであってもよいし、呼び出し側のオブジェクトの代わりに動作を実行してもよい。このように、オブジェクトメソッドは、プロシージャ言語の機能またはサブルーチンと同様のものである。オブジェクト間の通信は、あるオブジェクトが第２のオブジェクトにメッセージを送って第２のオブジェクトのメソッドを呼び出すことによって起きる。次いで、メソッドからの結果はすべて、呼び出し側のオブジェクトに返される。
【００２２】
図３は、アプリケーションマネージャ（図示せず）によってＪＶＭ １４０を用いてインスタンスを生成された第１のアイソレートＡ １３０および第２のアイソレートＢ １３２を含む２つのアイソレートの間でのＸｌｅｔ間通信（ＩＸＣ）のための構成の一例を示す図である。各アイソレート１３０および１３２は、その中で実行されるＸｌｅｔ １３４および１３６をそれぞれ備える。各Ｘｌｅｔは、１または複数のオブジェクト（図示せず）を備える。ＪＶＭ １４０は、１つのマシン内に存在し、それぞれシステム内の別個のプロセスおよびアドレス空間で作動する各アイソレート１３０および１３２のための共通リソースを提供する。ＪＶＭ １４０は、アイソレートを作成および破棄するためのアイソレートＡＰＩや、Ｘｌｅｔ Ａ １３４とＸｌｅｔ Ｂ １３６との間のＩＸＣ １３８を提供するＩＸＣ ＡＰＩなど、複数のＡＰＩを備える。以下で詳細に説明するように、ＩＸＣ １３８は、Ｘｌｅｔ Ｂが、Ｘｌｅｔ Ａのオブジェクト内のメソッドを呼び出して応答を受け取ることを可能にする。図３は、共通のＪＶＭ １４０を示しているが、Ｘｌｅｔ ＡとＸｌｅｔ Ｂとは、別個のＪＶＭに属してもよい。
【００２３】
本発明の様々な実施形態で、特定のＪＶＭおよびＪＡＶＡ（登録商標）プログラミング言語について言及しているが、本発明は、他のオブジェクト指向プログラミング言語や他の仮想マシンにも適用可能である。したがって、ＪＡＶＡ（登録商標）への限定を意図していないことに注意されたい。さらに、「Ｘｌｅｔ」という用語は、保護されたドメインまたは仮想マシンを他のアプリケーションと共有することが可能であり、アプリケーションマネージャなどの外部プログラムによってそのライフサイクルを管理できる種類のオブジェクト指向アプリケーションを示すよう意図されている。本明細書で用いられている「Ｘｌｅｔ」という用語は、一般的なものであり、アプレット、サーブレット、および、他の類似のプログラミングモデルを含む。
【００２４】
図４は、本発明を実施できるデバイス１５０の一例を示す図である。一実施形態では、デバイス１５０は、コネクテッド・デバイスであり、コネクテッド・デバイスとは、少なくとも時々、外部のネットワークやシステムに接続可能であることを意味する。デバイス１５０は、少なくとも１つのプロセッサ１５２と、メモリ１５４と、ユーザインターフェース１５６と、入出力システム１５８とを備え、それらのコンポーネントは、データバス１６０を介して互いに通信する。意図される用途に応じて、プロセッサ１５２は、シングルコア・プロセッサでもマルチコア・プロセッサでもよく、複数のプロセッサを備えてもよい。プロセッサ１５２は、携帯情報端末や携帯電話などの携帯デバイスのために低電力に最適化されてもよいし、コンピュータワークステーションやサーバで見られるように、プロセッサ集中的な動作のために速度に最適化されてもよい。デバイス１５０は、デバイスの使用方法に応じて、他のコンポーネント（図示せず）を備えてもよい。例えば、デバイス１５０が携帯電話である場合には、音声通信用のコンポーネントを備えてよい。デバイス１５０がテレビ用のセット・トップ・ボックスである場合には、受信機とビデオ処理回路とを備えてよい。
【００２５】
メモリ１５４は、ランダムアクセスメモリ（ＲＡＭ）の１つのブロックを備えてよく、すなわち、電源を切った際に情報を保持できない揮発性メモリであってよい。あるいは、メモリ１５４は、揮発性ＲＡＭ、フラッシュメモリのような不揮発性ＲＡＭ、および／または、不揮発性の大容量ストレージなど、セグメントメモリまたは多層メモリであってもよい。メモリ１５４は、さらに、デバイスの基本入出力システム（ＢＩＯＳ）、オペレーティングシステムのコンポーネント、および／または、様々なソフトウェアアプリケーションやユーティリティを格納するための読み出し専用メモリ（ＲＯＭ）を備えてもよい。メモリ１５４は、デバイス１５０内に固定されてもよいし、取り外し可能であってもよい。例えば、メモリ１５４は、「コンパクトフラッシュ（登録商標）」、「メモリースティック」、「ＳＤカード」という商標で販売されているメモリなど、取り外し可能な記憶装置であってよい。メモリ１５４が、取り外し可能なメモリを備える場合には、コンピュータやネットワークなどの外部システム１６２を用いて、新しいソフトウェアをメモリ１５４に追加してもよい。次いで、新しいソフトウェアは、プロセッサ１５２上で実行され、さらなる機能をデバイス１５０に提供してよい。
【００２６】
ユーザインターフェース１５６は、ユーザへの出力やユーザからの入力を実現するための様々な要素を備えてよい。例えば、出力側では、ユーザインターフェース１５６は、携帯デバイス用の小型の液晶ディスプレイ（ＬＣＤ）と、スピーカとを備えてもよいし、コンピュータワークステーション用の高解像度ディスプレイを備えてもよい。セット・トップ・ボックスでは、ユーザインターフェース１５６は、ビデオおよびオーディオ信号にアプリケーション情報を重ねることができるビデオおよびオーディオ出力を備えてよい。入力側では、ユーザインターフェース１５６は、キーパッド、タッチスクリーン、フルサイズのキーボード、リモートコントロール、音声駆動、および／または、ユーザに双方向性を提供する任意の数の他のユーザ入力を備えてよい。
【００２７】
一実施形態では、デバイス１５０は、外部との通信を可能にする入出力システム１５８を備える。具体的には、デバイス１５０は、ネットワーク、コンピュータシステム、または、他のデバイスなどの外部システム１６２に対して、常に接続されてもよいし、時々接続されてもよい。特に、外部システム１６２は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、または、リモートコンピュータやインターフェースデバイスを含みうる。ネットワークすなわち外部システム１６２は、実行可能なソフトウェアをデバイス１５０にダウンロードすることが可能である。
【００２８】
動作中に、ＪＶＭ １４０（図３）は、メモリ１５４にロードされ（もしくは、メモリ１５４内にすでに存在し）、プロセッサ１５２で実行される。ＪＶＭ １４０は、メモリ１５４内に存在するＪＡＶＡ（登録商標）バイトコードを実行するための仮想マシンを提供する。ＪＡＶＡ（登録商標）バイトコードは、ＪＶＭ １４０を用いて解釈またはジャスト・イン・タイム（ＪＩＴ）コンパイルされ、デバイス１５０に機能を提供する。デバイス１５０は、例えば、他のＪＡＶＡ（登録商標）ソフトウェアをダウンロードして実行させるためのＪＡＶＡ（登録商標）ソフトウェアを備えてよい。一実施形態では、ＪＶＭ １４０は、デバイスに機能を提供するＸｌｅｔをロード、起動、終了するためのアプリケーションマネージャを備える。
【００２９】
図５は、デバイス１５０上でＸｌｅｔを実行するためのハードウェアおよびソフトウェアの層１５５の一例を示す図である。一番下のレベルには、コネクテッド・デバイス１５０が存在し、図４を参照して上述した様々なコンポーネントを備えている。ハードウェア層の上には、ＢＩＯＳ／ＯＳ層１６０が存在する。ＢＩＯＳおよびＯＳは、別個のソフトウェア層として存在してもよいし、一体化されてもよい。それらは、一般に、より上位のソフトウェア層による呼び出しに応じて、ユーザインターフェースなどの様々なハードウェアコンポーネントを駆動する機能を有する。ＢＩＯＳ／ＯＳ層１６０の上には、１または複数のＪＶＭ層１４０が存在する。ＪＶＭ層１４０は、それぞれ、アプリケーションマネージャ１６５やＸｌｅｔ１３４、１３６などのアプリケーションソフトウェアを解釈および／またはコンパイル（例えばＪＩＴコンパイルなど）することにより実行するための独立したプラットフォームを提供する。上述のように、ＪＶＭ層１４０は、アイソレート層１３２のインスタンスを生成して、保護された環境をＸｌｅｔ１３４および１３６に提供することもできる。
【００３０】
図６は、アイソレート間のＩＸＣの実装の一例を示す説明図である。このプログラミングモデルは、他のリモートメソッド呼び出しモデルとの共通点を有する。説明のため、２つのアイソレート、すなわち、アイソレートＡ １７２とアイソレートＢ １７４が図示されている。アイソレートＡ １７２は、デバイスで作動する他のＸｌｅｔに特定の機能を提供するＸｌｅｔ Ａ １８２を含む。例えば、Ｘｌｅｔ Ａ １８２は、アドレス帳検索機能を提供してよく、その場合、Ｘｌｅｔ Ｂ １８４は、特定の個人の電話番号やＥメールアドレスを探すために、その機能にアクセスする必要がある。Ｘｌｅｔ Ａ １８２およびＸｌｅｔ Ｂ １８４は、この通信のためのインターフェースについて合意する。インターフェースは、例えば、クエリのための特定のパラメータと所望の応答のための特定の変数型とを備えた特定のメソッドを有する特定のオブジェクトであってよい。Ｘｌｅｔ Ａ １８２は、Ｘｌｅｔ Ｂ １８４によって予期されたメソッドを有するオブジェクトＯＢＪ＿Ｃを提供する。
【００３１】
ＯＢＪ＿Ｃを他のＸｌｅｔに対して利用可能およびアクセス可能にするために、Ｘｌｅｔ Ａ １８２は、オブジェクトレジストリ１６６へのリモート参照を含むメッセージ１９２を送信する。Ｘｌｅｔ １８２は、インフラストラクチャを維持するため、エクスポートしたばかりのＯＢＪ＿Ｃへの要求に応じることができる。レジストリは、予期された位置に提供されるか、もしくは、システム上で作動するすべてのＸｌｅｔに利用可能にされる。一実施形態では、レジストリ自体は、別のプロセスに存在するアプリケーションマネージャ１６５によってエクスポートされたリモートオブジェクトである。この場合、レジストリへのリモート参照は、ＪＶＭ ＡＰＩによって定数として定義される。Ｘｌｅｔ Ａ １８２によってオブジェクトレジストリ１６６に送信されたリモート参照は、オブジェクト名、オブジェクトへのリモート参照、および、オブジェクト記述を含む。記述は、インターフェースの詳細を含んでもよいし、単に、ハッシュコードなど、これらの詳細の固有識別子を含んでもよい。オブジェクトレジストリ１６６は、システム上のどこかに配置されたレジストリテーブル１７６を維持する。レジストリテーブル１７６は、オブジェクト名とリモートオブジェクト参照とを関連付けたリストを含む。したがって、レジストリテーブルは、エクスポートされたオブジェクトのオブジェクト名を、エクスポートされたオブジェクトへの参照に結合している。
【００３２】
一実施形態では、リモート参照は、４つのデータ要素、すなわち、エクスポート側Ｘｌｅｔの識別子と、エクスポート側Ｘｌｅｔのエンドポイント識別子と、エクスポートされたオブジェクトの識別子と、インターフェース記述子とを含む。Ｘｌｅｔの識別子は、エクスポート側Ｘｌｅｔの名前であってよい。Ｘｌｅｔのエンドポイント識別子は、どの通信プロセスを用いた場合でも、アドレスのポート番号または他の表現であってよい。ポート番号は、例えば、Ｘｌｅｔの識別子と、エクスポートされたオブジェクトの識別子とによって、エクスポートされたオブジェクトへの呼び出しを転送できるエクスポートＪＶＭインスタンスの位置を特定してよい。エクスポートされたオブジェクトの識別子は、エクスポートされたオブジェクトのオブジェクト名であってよい。インターフェース記述子は、例えば、インターフェース名のリストを含み、さらに、各インターフェース名に対して、メソッド名に基づくコードと、メソッドに対するパラメータ型と、メソッドに対する戻り型とのリストを含んでよい。コードは、例えば、ハッシュコードであってよく、ハッシュコードとは、可変調入力を代表する固定長コードである。ハッシュコードの代わりに、メソッド名および型の全体を提供してもよい。別の実施形態では、リモート参照は、インターフェース記述子を含まず、その代わりに、レジストリによって別個に登録されているインターフェース記述子へのアクセスに利用可能なインターフェース識別子を備える。この情報の提供により、インポート側Ｘｌｅｔが、予期されたインターフェースの詳細を実際のインターフェースと比較して、リモートオブジェクトとの通信の前に一致を保証することが可能になる。この比較は、本明細書では、「型検査」と呼ぶこととする。これにより、リモート参照がシリアルで送信されるたびに、全部の型情報を送信する必要がなくなる。
【００３３】
Ｘｌｅｔ Ｂ １７４は、ＯＢＪ＿Ｃ １７８にアクセスしたい場合には、ＯＢＪ＿Ｃのインスタンスを要求するメッセージ１９４をオブジェクトレジストリ１６６に送信する。レジストリ１６６は、レジストリテーブル１７６にアクセスし、その要求を、結合されたリモート参照と照合する。
【００３４】
Ｘｌｅｔ Ｂ １８４は、リモート参照をインポートすると、スタブオブジェクト１８８を生成するスタブ生成のプロセスに進む。スタブ生成は、ＪＶＭの一部であるＩＸＣ ＡＰＩによってオンザフライで実行される。Ｘｌｅｔ Ｂ １８４から見ると、オブジェクトレジストリ１６６からリモートオブジェクトのインスタンスが要求されて、オブジェクトレジストリ１６６によって提供される。しかしながら、実際には、スタブオブジェクト１８８は、元々のエクスポートされたオブジェクト１７８のシェルに過ぎず、そのオブジェクトへのプロキシとして動作する。しかし、Ｘｌｅｔ Ｂ １８４が認識している限りは、Ｘｌｅｔ Ｂ １８４は、リモートオブジェクトの完全なインスタンスを有し、そのようにスタブオブジェクト１８８を扱うことができる。しかしながら、呼び出しを内部で処理する代わりに、スタブオブジェクト１８８は、元々のエクスポートされたオブジェクト１７８への呼び出しを転送して、その結果をリモートのエクスポートされたオブジェクト１７８からＸｌｅｔ Ｂ １８４に渡す。
【００３５】
一実施形態では、インポートされて、インポートされたオブジェクトの各々についてインポートおよびインスタンス生成された各オブジェクト型に対して、動的にスタブクラスを生成して、元々のエクスポートされたオブジェクトを参照する。したがって、同じ型を有する複数のオブジェクトがインポートされる場合には、そのオブジェクト型に対するスタブクラスが一旦生成されると、その型のオブジェクトがインポートされるたびに、スタブのインスタンスが生成される。スタブ生成の機構に関するさらなる詳細については、Ｗｉｌｌｉａｍ  Ｆ．Ｆｏｏｔｅらに発行された米国特許６，８２９，７７２、Ｐｅｌｅｇｒｉ−Ｌｌｏｐａｒｔらに発行された米国特許５，９９９，９８８、および、Ｗｏｌｌｒａｔｈらに発行された米国特許６，９３８，２６３に開示されている。一般的に、リモート・インターフェース・クラスは、インポート側にもエクスポート側にもロード可能である。これは、インターフェース・クラスが、通常のクラスと同様に、「クラスパス上にある」ことを意味する。インターフェース・クラスがロードされる際に、システムは、そのクラスを「イントロスペクト」して、その詳細（すなわち、メソッド、パラメータのリスト、および、戻り型）を見つけることができる。次に、そのシステムは、スタブクラスを生成することができる。この種のイントロスペクトのための機構は、ＪＡＶＡ（登録商標）では「リフレクション」と呼ばれる。このように、インターフェース名から、インターフェース・クラスをロードして、そこから、スタブクラスでのインターフェースの再生に必要な情報をすべて抽出することができるため、リモート参照は、リモート・インターフェース名を含む。
【００３６】
Ｘｌｅｔ Ｂ １８４は、リモートオブジェクトをインポートすることによって新しいスタブを生成する際に、新しいクラス名をオンザフライで生成し、そのインスタンスを生成して、リモートのエクスポートされたオブジェクトを参照させる。スタブオブジェクト１８８は、オブジェクト記述子によって定義されたインターフェースを実装する。当業者にとって明らかなように、スタブ生成は、様々なＲＭＩ実装と同様に、従来のＩＸＣ実装において周知のプロセスである。
【００３７】
ＩＸＣ ＡＰＩは、スタブオブジェクト１８８が、実装固有であってよいデータパス１８０に沿って、エクスポートされたオブジェクト１７８へのメソッド要求を転送することを保証する。例えば、データパス１８０は、オペレーティングシステム層およびハードウェア層によって提供された低レベルのプロセス間通信（ＩＰＣ）機構であってよい。リモート参照は、そのリモートオブジェクトのアドレスに類似するエンドポイント１７９を定義する。このように、オブジェクトレジストリ１６６は、そのエンドポイントによって同様にアクセスされる。一実施形態では、エンドポイント１７９および１６９が、別々の転送機構（すなわち、別々のＩＰＣ機構）の上に実装可能なクラスに抽象化される。別の実施形態では、それらのエンドポイントは、例えば、ポート番号を用いて、オペレーティングシステムに密接に結合される。
【００３８】
一実施形態では、Ｘｌｅｔ Ａ １８２からレジストリ１６６に送信されたリモート参照１８２は、エクスポートされたオブジェクトへの接触が可能なように、エクスポートされたオブジェクトに関する十分な情報を含むオブジェクトである。一実施形態では、リモート参照オブジェクトは、ＪＡＶＡ（登録商標）オブジェクト直列化を用いて、エクスポートＸｌｅｔからレジストリに、レジストリからインポートＸｌｅｔに転送される。オブジェクト直列化とは、ＪＶＭによって提供される機構であり、アイソレート間またはＪＶＭ間の転送のためにオブジェクトを一連の数（例えば、バイト列）に変換する。別の実施形態では、オブジェクト記述子オブジェクトは、より低レベルのコマンド構造を利用するカスタムコードされたプロシージャを用いて転送される。当業者にとって明らかなように、オブジェクトをデータに変換して、そのデータを仮想マシン（ＶＭ）のインスタンス間で送信するための様々な機構が利用可能である。
【００３９】
図７は、Ｘｌｅｔ ＡとＸｌｅｔ Ｂとの間のＩＸＣを開始するためのプロシージャを示すフローチャート２００である。そのプロシージャは、開始ブロック２０２に示すように始まり、Ｘｌｅｔ Ａが、オブジェクトのリモート参照をオブジェクトレジストリに送信することによって、オブジェクトをエクスポートする動作２０４に進む。動作２０６では、レジストリが、エクスポートされたオブジェクトのオブジェクト名をリモート参照に結合する。
【００４０】
リモート参照は、別のアイソレートのＸｌｅｔが、エクスポートされたオブジェクトに接触することを可能にするのに十分な情報を有する。エクスポートされたオブジェクトのオブジェクト名をリモート参照に結合することで、別のアイソレート内のＸｌｅｔが、以下の動作で示すように、アクセスしたいエクスポートされたオブジェクトのオブジェクト名を提供することにより、リモート参照を取得することができるようになる。別のＸｌｅｔから見ると、エクスポートされたオブジェクトは、リモートオブジェクトである。
【００４１】
動作２０８ないし２１２では、Ｘｌｅｔ Ｂが、リモートオブジェクトを「インポート」する。動作２０８において、Ｘｌｅｔ Ｂは、Ｘｌｅｔ Ａによってエクスポートされたリモートオブジェクトへのリモート参照に対する要求をレジストリに送信する。動作２１０において、レジストリは、Ｘｌｅｔ Ｂの要求に応じて、リモート参照を送信する。動作２１２において、Ｘｌｅｔ Ｂは、リモート参照の型記述子を、予期されたインターフェース型と比較することにより、リモート参照の型検査を行い、それによって、リモートのエクスポートされたオブジェクトの型に関してＸｌｅｔ Ｂが内部に保持する意向が、リモートのエクスポートされたオブジェクトの実際の型と一致することを保証する。型が一致しない場合には、エラーが生成される。型が一致する場合、Ｘｌｅｔ Ｂは、リモートオブジェクトの型に対応するスタブオブジェクトを生成する。前述のように、スタブオブジェクトは、実際のリモートオブジェクトへのプロキシであり、単に、リモートオブジェクトのインターフェースを実装し、呼び出しをリモートオブジェクトに転送して、リモートオブジェクトから結果を戻す。
【００４２】
動作２１４において、Ｘｌｅｔ Ｂは、ローカルスタブオブジェクト内のメソッドを呼び出す。そのメソッドは、スタブオブジェクトによってリモートオブジェクトに転送される。すべての結果が、スタブオブジェクトに戻され、次いで、スタブオブジェクトは、それらの結果をＸｌｅｔ Ｂに送り返す。次いで、プロシージャは、終了ブロック２１６に示すように終了する。
【００４３】
複数のＸｌｅｔが互いに通信することが可能な場合には、様々なセキュリティの問題が生じる。「背景技術」において上述したように、問題の１つは、サービス妨害（ＤＯＳ）攻撃の可能性である。システムが、悪質または有害なプログラムによる要求へのサービスに縛られすぎて、他のプログラムからの正当な要求へのサービスが不可能になることがある場合には、そのシステムは、悪質なコードによるＤＯＳ攻撃に対して脆弱である。これが、システムの過負荷になり、正常な動作を妨げる場合がある。図６および７を参照して上述したＩＸＣ実装では、悪質なＸｌｅｔが、多くのオブジェクトをエクスポートするための多くの要求を作成し、オブジェクトレジストリを飽和させて、他のＸｌｅｔによるオブジェクトレジストリの利用を妨害するという問題がある。
【００４４】
一実施形態では、かかるＤＯＳ攻撃は、任意の特定のＸｌｅｔからレジストリにおいて利用可能な結合の数を制限することによって防止される。この方法では、レジストリは、各エクスポートＸｌｅｔに対して、エクスポートされたオブジェクトの数をカウントする。いずれかのＸｌｅｔが、エクスポートされるオブジェクトの最大許容数に到達すると、以後の要求はすべて拒否される。
【００４５】
図８は、各Ｘｌｅｔに対する結合の数を制限するためのプロシージャの一例を示すフローチャート２２０である。そのプロシージャは、開始ブロック２２２に示すように始まり、エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合するための要求が受信される動作２２４に進む。動作２２６において、オブジェクトレジストリは、要求側のＸｌｅｔについての結合オブジェクトのカウント数を、オブジェクトの最大許容結合数と比較する。動作２２８において、結合されたオブジェクトの数に対するカウンタが、最大許容数未満であるか否かが判定される。カウンタが最大値未満である場合には、プロシージャは動作２３０に進み、リモート参照およびオブジェクト名がレジストリテーブルに転送されて、カウンタが増分される。次いで、プロシージャは、終了ブロック２３４に示すように終了する。しかしながら、動作２２８において、カウンタが最大値以上であると判定された場合には、プロシージャは動作２３２に進み、要求は拒否される。例えば、エクスポートされたオブジェクトの最大結合数に到達していることを示すエラーメッセージが、要求側のＸｌｅｔに送信される。次いで、プロシージャは、終了ブロック２３４に示すように終了する。
【００４６】
図８に示したように、悪質なＸｌｅｔが偽の結合要求でオブジェクトレジストリに過負荷を掛けるという問題の起きる可能性は、各Ｘｌｅｔにとって利用可能な結合の数を制限することにより排除される。例えば、その制限は、Ｘｌｅｔ当たり５０または１００の結合であってよい。この数は、リソースの制限、および／または、特定の実装に特有の他の要素に応じて変更されてよい。結合の制限は、各Ｘｌｅｔに対して定数であってもよいし、ある認証機構を備えることで、さらなる結合を必要とする既知の信頼できるＸｌｅｔが、制限を超えることができるようにしてもよい。また、各Ｘｌｅｔでなく、各アイソレートに対して結合数を制限することも可能である。
【００４７】
エクスポート側Ｘｌｅｔが停止した場合には、エクスポートされたオブジェクトは、他のＸｌｅｔからの要求の処理に対して利用不可能になる。したがって、レジストリテーブルを更新して、停止したＸｌｅｔに付属するエクスポートされたオブジェクトの喪失を反映することが重要である。また、すべての対応するスタブオブジェクトを破棄できるように、リモートオブジェクトがもはや利用可能ではないことを、停止したＸｌｅｔからインポートしたオブジェクトを有するＸｌｅｔに対して通知することも有用である。この動作により、メモリリソースを必要とする他のプロセスに、メモリリソースを再割り当てすることが可能となり、それは、しばしば、「ガーベッジコレクション」と呼ばれる。Ｘｌｅｔプログラミングモデルでは、個々のＸｌｅｔのライフサイクルは、アプリケーションマネージャによって制御されてよく、アプリケーションマネージャは、システム上の様々なＸｌｅｔの状態を認識している。Ｘｌｅｔと、それらのＸｌｅｔがインポートしたオブジェクトとのリストを保持することにより、レジストリは、対応するリモートオブジェクトの停止が原因で停止したインポート後のオブジェクトを有するＸｌｅｔに対してアプリケーションマネージャが通知する必要のある情報を、アプリケーションマネージャに提供することができる。
【００４８】
図９は、ガーベッジコレクションのプロシージャの一例を示すフローチャート２４０である。そのプロシージャは、開始ブロック２４２に示すように始まり、アプリケーションマネージャが、特定のＸｌｅｔの停止に気付く動作２４４に進む。Ｘｌｅｔは、単に、終了したことによって停止してもよいし、アプリケーションマネージャが、そのＸｌｅｔを強制終了したのであってもよい。アプリケーションマネージャは、例えば、特定のＸｌｅｔが不正動作（例えば、システムリソースの過度の消費など）をしていると判定した場合に、ユーザの要求に応じてアプリケーションを強制終了することができる。アプリケーションマネージャは、Ｘｌｅｔが停止したことに気付くと、動作２４６において、Ｘｌｅｔの停止をオブジェクトレジストリに通知するメッセージをオブジェクトレジストリに送信する。一実施形態では、オブジェクトレジストリは、アプリケーションマネージャにとってローカルなオブジェクトであるため、そのメッセージは、単に、このためにオブジェクトレジストリによって提供されたメソッドを呼び出すことによって受け渡し可能である。
【００４９】
動作２４８において、オブジェクトレジストリは、メッセージに応えて、停止したＸｌｅｔによってエクスポートされたすべてのオブジェクトの結合を削除する。停止したＸｌｅｔによってエクスポートされたオブジェクトは、本明細書では、停止オブジェクトと呼ぶこととする。停止オブジェクトへのすべての結合を削除することに加えて、オブジェクトレジストリは、停止オブジェクトのいずれかをインポートしたＸｌｅｔすべてに対してメッセージを送信する。
【００５０】
動作２５０において、インポート側Ｘｌｅｔは、オブジェクトレジストリからのメッセージに応えて、停止オブジェクトに対応するスタブオブジェクトを破棄する。次いで、プロシージャは、終了ブロック２５２に示すように終了する。したがって、オブジェクトレジストリは、結合されたオブジェクトの各々について、結合されたオブジェクトをインポートしたＸｌｅｔのリストを保持する。結合されたオブジェクトが停止すると、オブジェクトレジストリは、結合されたオブジェクトをインポートしたＸｌｅｔすべてに通知して、結合を削除することにより、メモリリソースなどのリソースを他のアプリケーションに対して解放することができる。
【００５１】
上述のように、図６ないし９は、中央オブジェクトレジストリを用いたＩＸＣの実装例の様々な態様を示している。レジストリへのＤＯＳ攻撃を防ぐために、各Ｘｌｅｔは、オブジェクトレジストリによって、エクスポートされたオブジェクトについての選択された最大結合数に制限されてよい。別の実施形態では、レジストリは、各アイソレートが、そのアイソレートからエクスポートされたオブジェクトのためのレジストリを保持するように分散される。
【００５２】
図１０は、ＩＸＣのための分散レジストリ３００の実装の一例を示す説明図である。説明のため、２つのアイソレート、すなわち、アイソレートＡ ３１０とアイソレートＢ ３２０が図示されている。アイソレートＡ ３１０はＸｌｅｔ Ａ ３１２を有し、アイソレートＢはＸｌｅｔ Ｂ ３２２を有する。Ｘｌｅｔ Ｂ ３２２がＯＢＪ＿Ｃにアクセスするためには、まず、Ｘｌｅｔ Ａ ３１２が、ＯＢＪ＿Ｃ ３１６をエクスポートする必要がある。これは、Ｘｌｅｔ Ａ ３１２が、単に、アイソレートＡ ３１０内に位置するエクスポート済みアイソレートレジストリＡ ３１４にＯＢＪ＿Ｃを追加することによって実現される。各アイソレートは、例えば、アイソレートＢ ３２０が、エクスポート済みアイソレートレジストリＢ ３２４を含むように、エクスポート済みアイソレートレジストリを含む。エクスポート済みアイソレートレジストリの各々は、そのアイソレート内のＸｌｅｔによってエクスポートされたオブジェクトのリストを含む。したがって、エクスポート済みアイソレートレジストリＡ ３１４は、オブジェクトと、それらのオブジェクトに対応して結合されたリモート参照とのリストを含む。Ｘｌｅｔ Ａは、オブジェクトＯＢＪ＿Ｃをエクスポートするために、それ以上のことをする必要はない。アイソレートＡの外側のＸｌｅｔにとって、ＯＢＪ＿Ｃはリモートオブジェクトである。
【００５３】
Ｘｌｅｔ Ｂ ３２２は、ＯＢＪ＿Ｃをインポートするために、まず、レジストリプロキシ３３２に接触して、リモートオブジェクトＯＢＪ＿Ｃのリモート参照（Ｘｌｅｔ Ｂ ３２２はインスタンスとして認識する）を要求する。一実施形態では、レジストリプロキシ３３２は、１組の特殊なコマンドを用いて実装される。別の実施形態では、レジストリプロキシ３３２は、アプリケーションマネージャ３３０によって提供されるリモートオブジェクトであり、Ｘｌｅｔ Ｂを含む他のＸｌｅｙからＩＸＣによって接触される。したがって、この場合、Ｘｌｅｔ Ｂは、ＯＢＪ＿Ｃをインポートするためにそのリモートオブジェクトに接触する前に、レジストリプロキシオブジェクトをインポートする必要がある。Ｘｌｅｔが、確実にレジストリプロキシオブジェクトを見つけることができるように、レジストリプロキシへのリモート参照は、ＪＶＭによって提供された定数値である。いずれの実施形態でも、Ｘｌｅｔ Ｂ ３２４は、ＯＢＪ＿Ｃへのリモート参照を取得することを要求するメッセージをレジストリプロキシ３３２に送信する。この要求を満たすために、レジストリプロキシ３３２は、アプリケーションマネージャ３３０が保持するアイソレートテーブル３３４内のアイソレートのリストを参照し、各アイソレート内のエクスポート済みアイソレートレジストリ各々をポーリングして、求められている特定のオブジェクトが、そのアイソレート内に存在するか否かを判定する。一実施形態では、このアイソレートの検索は、一貫した命名方式を用いて最適化されてよい。例えば、各アイソレートは、エクスポートされたオブジェクトのオブジェクト名に固有のプレフィックスを添付して、求められているリモートオブジェクトと共通のプレフィックスを有するアイソレート内の最初に検索してもよい。
【００５４】
予期しない結果を招く場合があるため、Ｘｌｅｔが、検索中にオブジェクトをエクスポートすることを防ぐために、レジストリは、排他ロックを取得する。レジストリプロキシがロックを制御する場合には、個々のＸｌｅｔは、エクスポート済みアイソレートレジストリの修正を防止される。Ｘｌｅｔ Ａは、オブジェクトＯＢＪ＿Ｃをエクスポートすると、まず、排他ロックを取得して、レジストリプロキシが、そのオブジェクトを入手しないことを保証する。レジストリプロキシ３３２は、ＯＢＪ＿Ｃに結合された検索対象のリモート参照を見つけると、エクスポート済みアイソレートレジストリからその参照を取得し、Ｘｌｅｔ Ｂ ３２２に渡して、Ｘｌｅｔ Ｂとのやり取りを完了し、排他ロックを解除する。型検査が上述のように一致すると、Ｘｌｅｔ Ｂ ３２２は、リモートオブジェクトＯＢＪ＿Ｃ ３１６にインターフェースを提供してＯＢＪ＿Ｃ ３１６への呼び出しを受け渡すスタブオブジェクト３２６を生成する動作に進む。
【００５５】
図１１は、Ｘｌｅｔ Ａ ３１２とＸｌｅｔ Ｂ ３２２との間のＩＸＣを実装するためのプロシージャの一例を示すフローチャート３５０である。そのプロシージャは、開始ブロック３５２に示すように始まり、Ｘｌｅｔ Ａが、エクスポート済みアイソレートレジストリ内にＯＢＪ＿Ｃを入れることによりＯＢＪ＿Ｃをエクスポートする動作３５４に進む。その後、動作３５６において、Ｘｌｅｔ Ｂが、アプリケーションマネージャによって提供されたレジストリプロキシからリモートオブジェクトを要求する。動作３５８において、レジストリプロキシは、Ｘｌｅｔ Ｂからの要求に応じて、エクスポート済みアイソレートレジストリ内でＯＢＪ＿Ｃを検索する。レジストリプロキシは、検索中に排他ロックの制御を取得して、エクスポート済みアイソレートレジストリが、検索中に修正されることを防止する。動作３６０において、アイソレートＡ内のエクスポート済みアイソレートレジストリは、ＯＢＪ＿Ｃに対応するリモート参照で、レジストリプロキシからの要求に応答する。動作３６２において、レジストリは、リモート参照をＸｌｅｔ Ｂに転送し、Ｘｌｅｔ Ｂは、リモート参照を型検査して、リモートオブジェクトＯＢＪ＿Ｃに対応するスタブオブジェクトを生成する。
【００５６】
分散レジストリモデルは、様々なアイソレートをポーリングするさらな工程を必要とするが、これは、各アイソレートが同じマシン上に存在する環境では許容可能なことである。これは、レジストリがリモートオブジェクトと同じマシンに位置することができないために分散レジストリの検索が非常に長く掛かるＲＭＩプロトコルと異なる点である。ＩＸＣモデルは、同じ物理マシン上のＸｌｅｔ間の通信に限定されているため、検索に関する遅延は、最小限であり、特定のＸｌｅｔが有しうるエクスポートされたオブジェクトの数に、いかなる制限もないという利点も提供する。
【００５７】
分散レジストリモデルは、さらに、ガーベッジコレクションを簡略化する可能性がある。典型的な例では、アイソレートごとに１つのＸｌｅｔのみが存在する。Ｘｌｅｔが停止すると、アイソレートが終了して、エクスポート済みアイソレートレジストリは、アイソレートと共に消滅する。したがって、この状況でＸｌｅｔが停止した場合には、レジストリの項目を削除するさらなる動作は必要ない。アイソレート内に２以上のＸｌｅｔが存在する場合には、Ｘｌｅｔは、正常に停止すると、自身をシャットオフするプロシージャを呼び出す。そのプロシージャは、シャットダウンされるＸｌｅｔに関連するすべての項目を削除するためのエクスポート済みアイソレートレジストリへの呼び出しを含む。Ｘｌｅｔが、ロックした場合（例えば、無限ループに入ってリソースを消費し尽くした場合）には、アイソレート内で動作する他のＸｌｅｔを含めて、アイソレート全体がシャットダウンされる。これは、同様に、エクスポート済みアイソレートレジストリを削除する。
【００５８】
停止したＸｌｅｔまたは停止しかけのＸｌｅｔからオブジェクトをインポートした他のアイソレートのＸｌｅｔへの通知に関しては、２つの方法がある。第１の方法は、図９を参照して上述した方法と同様の積極的な方法であり、アプリケーションマネージャが、停止したＸｌｅｔまたは停止しかけのＸｌｅｔからオブジェクトをインポートした各Ｘｌｅｔに対して、リモートオブジェクトがもはや存在しないことを通知して、対応するスタブオブジェクトを破棄するよう指示する。この通知は、すべてのＸｌｅｔへのブロードキャストメッセージであってもよいし、停止したＸｌｅｔまたは停止しかけのＸｌｅｔからオブジェクトをインポートしたＸｌｅｔのみを対象したブロードキャストメッセージであってもよい。別の実施形態では、現存しないインポートされたオブジェクトのガーベッジコレクションのための反応性の方法と呼んでよい方法で、インポート側のＸｌｅｔは、リモートオブジェクトへの接触を試みるまで、リモートオブジェクトの停止を通知されない。
【００５９】
図１２は、現存しないインポートされたオブジェクトのガーベッジコレクションのための反応性の方法を示すフローチャート３７０である。そのプロシージャは、開始ブロック３７２に示すように始まり、Ｘｌｅｔ Ｂが、そのローカルスタブオブジェクト内のメソッドを呼び出す動作３７４に進む。動作３７６において、ローカルスタブオブジェクトは、アイソレートＡ内のリモートオブジェクトへの呼び出しを転送する。動作３７８に示すように、リモートオブジェクトが存在するか否かによって、次の動作が決まる。リモートオブジェクトが存在する場合には、プロシージャは、リモートオブジェクトが要求を処理して結果を返す動作３８０に進む。次いで、動作３８２において、ローカルスタブオブジェクトは、その結果をＸｌｅｔ Ｂに渡す。次いで、プロシージャは、終了ブロック３８８に示すように終了する。
【００６０】
Ｘｌｅｔのシャットダウンもしくはアイソレートのシャットダウンのために、リモートオブジェクトがもはや存在しない場合には、動作３８４において、スタブオブジェクトは、リモートオブジェクトが見つからないことを示すエラーを受信する。このエラーは、ＩＸＣ ＡＰＩによって実装された低レベルのＩＰＣ機構によって受け渡されてよい。あるいは、そのエラーは、タイムアウト・エラーに応答して生成されてもよい。スタブオブジェクトは、このエラーを受信すると、動作３８６において、そのエラーをＸｌｅｔ Ｂに受け渡して、停止する。スタブオブジェクトは、自身を終了してもよいし、Ｘｌｅｔがスタブオブジェクトからエラーを受信した時に、Ｘｌｅｔによって終了されてもよい。次いで、プロシージャは、終了ブロック３８８に示すように終了する。
【００６１】
両方のＸｌｅｔが同じマシン上に存在するため、Ｘｌｅｔ間で信頼性の高い通信が実現される。したがって、ＩＸＣプロトコルは、アイソレートによって提供された保護ドメインによって促進されたセキュリティを損なうことなく、Ｘｌｅｔ間の通信での必要性を満たす単純でありながら堅固なＩＸＣインフラストラクチャを提供することにより、この信頼性を活用するよう設計される。
【００６２】
上述の実施形態に関して、本発明は、コンピュータシステムに格納されたデータを含む様々なコンピュータによる動作を用いてよいことを理解されたい。これらの動作は、物理量の物理的な操作を必要とするものである。これらの量は、必ずとは限らないが、格納、転送、結合、比較、および、その他の操作が可能な電気信号または磁気信号の形態をとるのが通常である。さらに、実行される操作は、生成、特定、決定、または、比較などの用語で呼ばれることが多い。
【００６３】
本明細書に記載され、本発明の一部を形成する動作は、有用なマシン動作である。本発明は、また、これらの動作を実行するためのデバイスまたは装置に関する。この装置は、必要とされる目的に応じて特別に構築されてもよいし、コンピュータに格納されたコンピュータプログラムによって選択的に起動または構成される汎用コンピュータであってもよい。特に、本明細書の教示に従って書かれたコンピュータプログラムと共に、様々な汎用マシンを使用してもよいし、必要な動作を実行するために、より特殊化された装置を構築する方が好都合な場合もある。
【００６４】
また、本発明は、コンピュータ読み取り可能な媒体上のコンピュータ読み取り可能なコードとして実施されてもよい。コンピュータ読み取り可能な媒体は、データを格納して、その後に、コンピュータシステムによって読み出し可能である任意のデータ記憶装置である。また、コンピュータ読み取り可能な媒体は、コンピュータコードを具現化した電磁気の搬送波を含む。コンピュータ読み取り可能な媒体の例としては、ハードディスク、ネットワーク接続ストレージ（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、および、その他の光学的または非光学的なデータ記憶装置が挙げられる。コンピュータ読み取り可能な媒体は、コンピュータ読み取り可能なコードを分散的に格納および実行できるように、ネットワークに接続されたコンピュータシステム上に分散されてもよい。
【００６５】
以上では、理解を促す目的で本発明を詳細に説明したが、添付した特許請求の範囲の範囲内で、変更および変形が可能であることは明らかである。したがって、上述した実施形態は、例示を目的としたものであって限定的ではなく、本発明は、本明細書に記載の詳細事項に限定されず、添付した特許請求の範囲および等価物の範囲内で変形されてよい。
【図面の簡単な説明】
【００６６】
【図１】リモートメソッド呼び出しのための従来の構成の一例を示す図である。
【図２】Ｘｌｅｔ間通信（ＩＸＣ）のための従来の構成の一例を示す図である。
【図３】アイソレート間のＩＸＣのための構成の一例を示す図である。
【図４】本発明を実施できるデバイスの一例を示す図である。
【図５】デバイス上でＸｌｅｔを実行するためのハードウェアおよびソフトウェアの層の一例を示す図である。
【図６】アイソレート間のＩＸＣの実装の一例を示す説明図である。
【図７】ＩＸＣを実装するプロシージャの一例を示すフローチャートである。
【図８】各Ｘｌｅｔに対する結合の数を制限するためのプロシージャの一例を示すフローチャートである。
【図９】ガーベッジコレクションのプロシージャの一例を示すフローチャートである。
【図１０】ＩＸＣのための分散レジストリの実装の一例を示す説明図である。
【図１１】２つのＸｌｅｔの間のＩＸＣを分散レジストリによって実装するためのプロシージャの一例を示すフローチャートである。
【図１２】現存しないインポートされたオブジェクトのガーベッジコレクションのための反応性の方法を示すフローチャートである。
【図１】
2007128507.tif 000003
【図２】
2007128507.tif 000004
【図３】
2007128507.tif 000005
【図４】
2007128507.tif 000006
【図５】
2007128507.tif 000007
【図６】
2007128507.tif 000008
【図７】
2007128507.tif 000009
【図８】
2007128507.tif 000010
【図９】
2007128507.tif 000011
【図１０】
2007128507.tif 000012
【図１１】
2007128507.tif 000013
【図１２】
2007128507.tif 000014
【外国語明細書】
1. TITLE OF THE INVENTION
Object Oriented Communication Between Isolates
2. DETAILED DESCRIPTION OF THE INVENTION
Background 
[01]Computer systems for connected devices such as cell phones, personal data assistants (PDAs) and set top boxes for televisions are becoming more flexible.  Newer systems allow software to be downloaded and executed.  The downloaded software may not be entirely trustworthy and yet may share resources with existing, trusted software.  Various techniques have been proposed and implemented to therefore restrict the access of untrusted software to prevent it from disrupting the operation of the system.  However, the purpose of these systems is at odds with another goal of allowing software components to communicate with one another.
[02]One known mechanism for allowing software components to communicate with one another is the Remote Procedure Call (RPC).  This mechanism allows a computer program running on one host to cause code to be executed on another host and return the results to the first program.  Typically, RPC protocols are used to implement a client-server model of distributed computing.
[03]Various editions of the JAVA(trademark) Platform provide a mechanism known as Remote Method Invocation (RMI) for performing an RPC to communicate between objects.  In  RMI, the methods of remote JAVA(trademark) objects can be invoked from another Java virtual machine, possibly on a different host.   As depicted in Figure 1, RMI 100 essentially allows communication between JAVA(trademark) Virtual Machine (JVM) A 102, and JVM B 104.  JVM A 102 and JVM B 104 may be running on the same physical machine, or may be running on different machines and connected over a local area network (LAN) or an Internet Protocol (IP) network connection or other communication medium.  The application program interface (API) that implements RMI 100 handles the details of the communication between virtual machines.
[04]Because RMI includes all the necessary components and security measures for communicating between different machines over different protocols, RMI is complex and can be unwieldy for small devices, as RMI provides many features that are simply not needed in most connected devices.  Therefore, the RMI API is not included in the Personal Basis Profile (PBP) for JAVA(trademark) 2 Platform Micro Edition (J2ME).
[05]The conventional model for JAVA(trademark) applications assumes that only one application is executing in a given virtual machine, and this application is in complete control of its lifecycle, which can include killing the virtual machine it is running in.  To accommodate the limited processing and memory resources available in the typical connected device and yet allow multiple programs to run concurrently, the JAVA(trademark) Community Process (JCP) has proposed the use of a programming model referred to as Xlets.
[06]Xlets are similar to applets, which can be run by an Internet web browser, or servelets, which can be run by a web server, in that a plurality of Xlets can run at the same time in a single JVM, and their lifecycle can be controlled by another program.  In the case of applets, the other program is generally a web browser.  Running multiple programs in a single instance of a JVM can improve overall system performance and scalability by sharing some of the virtual machine's internal data structures.  Xlets may be managed by a stand-alone application manager.
[07]Since a plurality of Xlets may be operated by a single JVM, a mechanism was deemed necessary to protect sets of Xlets that may be harmed by a malicious downloaded Xlet.  Thus, the concept of a Logical Virtual Machine (LVM) was developed.  The LVM is a resource context structure that provides a mechanism for referencing the code from one or more programs that share the same resource or object.  Associating related threads with a particular LVM allows the related threads to be terminated together when they start to misbehave, e.g., by causing a denial of service attack.
[08]However, protecting Xlets by separating them into different LVMs meant placing them out of communication with each other, which is undesirable.  Therefore, some mechanism was required to permit Xlets to communicate to each other from between different LVMs or, more generically, resource domains.  United States Patent 6,829,772, issued December 7, 2004 and hereby incorporated by reference, presents a method now referred to as Inter-Xlet Communication (IXC) that allows Xlets to communicate with each other from different LVMs.  It should be noted that, when that patent was filed, the term "Xlet" had yet to be coined and so Xlets are referred to therein by the term "applets," which was used generically.
[09]The IXC API is now part of the J2ME PBP.  Figure 2 represents IXC 110 between two Xlets, Xlet A 112 and Xlet B 114, which each reside in different LVMs.  However, this IXC implementation is limited to what is referred to as a single-process, multi-virtual machine (MVM) paradigm.  In this paradigm, each LVM 116, 118 is executed in a single process JVM 120 and shares a common address space.  The IXC implementation(not shown) takes advantage of the common address space for sharing instances between each LVM.
[10]An isolation context for executing Xlets is now termed "isolate."  In one realization of isolates, each isolate runs in its own process and therefore has its own address space.  This may be referred to as the "multiple process, MVM" paradigm.  The JAVA(trademark) Application Isolate API is defined in JAVA(trademark) Specification Request 121 (JSR-121).  Because the previous mechanism for IXC relied on a common address space among Xlets, it is not structurally possible to implement in this new paradigm.
[11]Thus, a new IXC mechanism is needed that will provide required security measures to prevent denial of service attack, while at the same time permit RPCs between Xlets located in different isolates on a common JVM.  The new mechanism should also provide reliable garbage collection and efficient type checking.  Furthermore, the IXC implementation should be optimized for an isolate implementation wherein isolates exist on the same machine, but in separate address spaces.
Summary 
[12]Broadly speaking, the present invention fills these needs by providing a method and machine readable media providing object oriented communication between isolates.
[13]It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, or a method.  Several inventive embodiments of the present invention are described below.
[14]In one embodiment, a computer implemented method and machine readable media for managing a registry of bound objects for inter-Xlet communication (IXC) is provided.  A request from a first Xlet to bind an exported object name with a remote reference is received.  A number of objects exported by the first Xlet is compared with a maximum number.  If the number of objects exported is less than the maximum number then a binding is added for the exported object name and the remote reference.  If the number of objects exported is greater than the maximum number, then the request is denied.
[15]In another embodiment, a method for inter-Xlet communication (IXC) is provided in which a remote reference to an exported object from a first Xlet in a first isolate to an object registry located outside the first isolate.  The remote reference is bound to a name of the exported object in the object registry.  A request is received by the object registry from a second Xlet in a second isolate for the remote reference of the exported object.  In response, the remote reference is forwarded to the second Xlet.  A stub object is generated for the second Xlet, the stub being in communication with the exported object.  The object registry limits each Xlet to a number of bindings.
[16]In yet another embodiment, a computer readable media having program instructions for object oriented inter-Xlet communication (IXC) between isolates is provided.  The computer readable media comprises program instructions for exporting an object from a first Xlet, the exporting comprising sending a request from the first Xlet to an object registry to bind a name of the exported object with a remote reference, program instructions for comparing a number of objects exported by the first Xlet with a maximum number, program instructions for adding a binding to the object registry for the name of the exported object and the remote reference when the number of objects exported is less than the maximum number, and program instructions for denying the request when the number of objects exported is not less than the selected maximum number.
[17]The advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
[18]The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, and like reference numerals designate like structural elements.
Detailed Description
[19]In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention.  However, it will be apparent to one skilled in the art that the present invention may be practiced without some of these specific details.  In other instances, well known process operations and implementation details have not been described in detail in order to avoid unnecessarily obscuring the invention.
[20]This invention relates to object-oriented communication between isolates.  An isolate is a protected domain within a computer system that protects one or more threads from being adversely affected by other, potentially malicious, threads operating on the system.  In the JAVA(trademark) Specification Request 121 (JSR-121), an isolate is described as a construct midway between threads and JAVA(trademark) Virtual Machines (JVMs).  More specifically, an isolate in the context of the JAVA(trademark) personal basis profile, is an instance of the Isolate class, which encapsulates an application or component, and provides the means to start and stop an isolated computation.  For example, isolates can be used to initiate concurrent execution.  Like JVMs, they cause execution of a "main" method of a given class to proceed within its own system-level context, independently of any other JAVA(trademark) programs that may be running.  Thus, isolates differ from threads by guaranteeing lack of interference due to sharing statics or per-application run-time objects (such as the Abstract Window Toolkit thread and shutdown hooks), and they differ from JVMs by providing an Application Programming Interface (API) to create, start, terminate, monitor, and communicate with these independent activities.  Isolates may operate transparently to the application operating within them.  For the purpose of this disclosure, the term "isolate" may be simply used to identify a protected domain in a virtual machine, that runs in its own process and therefore has its own address space.
[21]Object oriented communication refers to communication between software objects.  A software object is a software construct comprising executable code and data, which is held in variables.  The data is protected within the object and can be accessed using methods provided by the object.  The methods can be invoked by other objects to carry out a procedure.  The methods can be interfaces provided by the object to the variables or they can carry out operations on behalf of the calling object.  In this way, object methods are similar to functions or subroutines in procedural languages.  Communication between objects occurs by one object sending a message to a second object to invoke a method in the second object.  Any result from the method is then returned to the invoking object.
[22]Figure 3 shows an exemplary configuration for inter-Xlet communication (IXC) between isolates in which a first isolate A 130, and a second isolate B 132 are instantiated by an application manager (not shown) using JVM 140.  Each isolate 130, 132 has an Xlet 134, 136 executing within it.  Each Xlet comprises one or more objects (not shown).  JVM 140 exists within a single machine and provides common resources for each isolate 130, 132, each operating in a separate process and address space within the system.  JVM 140 includes a plurality of APIs, including an isolate API for creating and destroying isolates, and an IXC API providing IXC 138 between Xlet A 134 and Xlet B 136.  As will be described in more detail below, IXC 138 allows Xlet B to invoke a method in an object of Xlet A, and receive a response.  While Figure 3 shows a common JVM 140, it is also possible for Xlet A and Xlet B to reside in separate JVMs.
[23]It will be noted that, while various embodiments of the invention mention in particular JVM and the JAVA(trademark) programming language, the invention may be ported to other object-oriented programming languages and other virtual machines.  It is therefore should not be construed as being limited to JAVA(trademark).  Furthermore, the term, "Xlet" is intended to refer to a type of object-oriented application that can share a protected domain or virtual machine with other applications, and whose lifecycles may be managed by an external program, such as an application manager.  The term "Xlet" as used herein is generic and includes applets and servelets, as well as other analogous programming models.
[24]Figure 4 shows an exemplary device 150 in which the invention may be implemented.  In one embodiment, device 150 is a connected device, which means it may be connected to an external network or system at least occasionally.  Device 150 comprises at least one processor 152, memory 154, a user interface 156, and an input/output system 158, which are all in communication with each other via data bus 160.  Depending on the intended application, processor 152 may be a single core or multi-core processor and may comprise multiple processors.  Processor 152 may be optimized for low power consumption for hand-held devices such as personal data assistants and mobile telephones, or may be optimized for speed for processor-intensive activities, as would be found in a computer workstation or server.  Device 150 may include other components (not shown) depending on the intended use of the device.  For example, if device 150 is a cell phone, it may include voice communication components.  If device 150 is a television set top box, it may include a receiver and video processing circuitry.
[25]Memory 154 may comprise a single block of randomly-accessible memory (RAM), which may be volatile, such that it cannot retain information when power is disconnected.  Alternatively, memory 154 may comprise segmented or multi-layer memory including volatile RAM, non-volatile RAM, such as FLASH memory, and/or non-volatile mass storage.  Memory 154 may furthermore include read-only memory (ROM) for storing the device's basic input/output system (BIOS), operating system components, and/or various software applications and utilities.  Memory 154 may be fixed within device 150 or may be removable.  For example, memory 154 may include removable storage devices such as that sold under the trademarks "COMPACTFLASH" "MEMORY STICK" and "SD CARD".  If memory 154 includes removable memory, new software may be added to memory 154 using an outside system 162 such as a computer or network.  The new software may then be executed on processor 152 to provide device 150 with additional functionality.
[26]User interface 156 may comprise various elements for providing output to a user and input from a user.  For example, on the output side, user interface 156 may comprise a small liquid crystal display (LCD) for a portable device and a speaker, or a high-resolution display for a computer workstation.  For a set-top box, the user interface 156 may include a video and audio outputs that could overlay application information on top of a video and audio signal.  On the input side, user interface 156 may include a keypad, touchscreen, a full-sized keyboard, a remote control, voice activation, and/or any number of other user inputs that provide user interactivity.
[27]In one embodiment, device 150 includes input/output system 158, which provides communication to the outside world.  Specifically, device 150 may be continuously or occasionally connected to outside system 162, which may be a network, computer system, or other device.  In particular, outside system 162 could comprise a local area network (LAN) a wide area network (WAN) such as the Internet, or a remote computer or interface device.  Network or outside system 162 is capable of downloading executable software to device 150.
[28]In operation, JVM 140 (Figure 3) is loaded into (or already resides) in memory 154 and is executed in processor 152.  JVM 140 provides a virtual machine for executing JAVA(trademark) bytecode, which also resides in memory 154.  The JAVA(trademark) bytecode is interpreted or just-in-time (JIT) compiled using JVM 140 to provide functionality to device 150.  Device 150, may, for example, include JAVA(trademark) software for downloading other JAVA(trademark) software and cause the other software to be executed.  In one embodiment, JVM 140 includes an application manager for loading, starting, and ending Xlets, which provide functionality to the device.
[29]Figure 5 shows exemplary hardware and software layers 155 for executing Xlets on device 150.  At the lowest level is connected device 150 hardware, which includes various components discussed above with respect to Figure 4.  Above the hardware layer is a BIOS/OS layer 160.  The BIOS and OS may exist as separate software layers or may be integrated and are generally responsible for driving various hardware components such as the user interface etc. in response to calls by higher software layers.  Above BIOS/OS layer 160 are one or more JVM layers 140. The JVM layers 140 each provide an independent platform for executing, by interpreting and/or by compiling, e.g., JIT compiling, application software such as Application Manager 165 or Xlets 134, 136.  As described above, JVM layers 140 can also instantiate isolate layers 132 to provide a protected environment for Xlets 134, 136.
[30]Figure 6 presents a schematic diagram illustrating an exemplary implementation of IXC between isolates.  This programming model has commonalities to other remote method invocation models.  For illustration purposes, two isolates, isolate A 172 and isolate B 174 are shown.  Isolate A 172 contains an Xlet A 182 that provides certain functionality to other Xlets operating in the device.  For example, Xlet A 182 may provide an address book look-up functionality, which Xlet B 184 needs to access to find the phone number or email address of a particular individual.  Xlet A 182 and Xlet B 184 agree on an interface for this communication.  The interface may be, for example, a particular object having a particular method with particular parameters for a query, and a particular variable type for the desired response.  Xlet A 182 provides an object OBJ_C having the necessary methods expected by Xlet B 184.
[31]To make OBJ_C available and accessible to other Xlets, Xlet A 182 sends a message 192 containing a remote reference to object registry 166.  Xlet A 182 maintains the infrastructure so it can answer requests on OBJ_C that it just exported.  The registry is provided in an expected location or is otherwise made available to all Xlets operating on the system.  In one embodiment, the registry is itself a remote object exported by application manager 165, which exists in a different process.  In this case, the remote reference to registry is defined as a constant by the JVM API.  The remote reference sent by Xlet A 182 to object registry 166 contains a name of the object a remote reference to the object, and a description of the object.  The description can include details of the interface or just a unique identifier of these details, such as a hash code.  Object registry 166 maintains a registry table 176, which is located somewhere on the system.  The registry table 176 is contains a list of names and associated remote object references.  The registry table therefore binds the name of each exported object to a reference to the exported object.
[32]In one embodiment, the remote reference includes 4 data elements: an exporting Xlet identifier, an exporting Xlet endpoint identifier, an exported object identifier, and an interface descriptor.  The Xlet identifier may be a name of the exporting Xlet.  The Xlet endpoint identifier may be a port number or other representation of an address using whatever communication process is implemented.  The port number, for example, may identify the location of the exporting JVM instance which can then forward calls to the exported object by the Xlet identifier and exported object identifier.  The exported object identifier may be a name of the exported object.  The interface descriptor may include, for example, a list of interface names, and for each interface name, a list of codes based on a method name, parameter type(s) for the method, and return type for the method.  The codes may be, for example, hash codes, which are fixed-length codes representative of variable-length inputs.  Instead of hash codes, the entire method name and types may be provided.  In another embodiment, the remote reference does not include an interface descriptor and instead includes an interface identifier which can be used to access an interface descriptor, which is separately registered by the registry.  The provision of this information allows importing Xlets to compare details of the expected interface with the actual interface, thereby ensuring a match prior to communicating with remote object.  This comparison is be referred to herein as "type checking."  This avoids having to transmit the full type information every time a remote reference is transmitted in serialized form.
[33]When Xlet B 174 wishes to access OBJ_C 178, it sends a message 194 to object registry 166 requesting an instance of OBJ_C.  Registry 166 accesses registry table 176 and matches the request with the bound remote reference.
[34]When Xlet B 184 imports the remote reference, it goes through a process of stub generation to generate stub object 188.  Stub generation is performed on the fly by the IXC API, which is part of the JVM.  From the standpoint of Xlet B 184, an instance of a remote object is requested from and is provided by object registry 166.  In reality, however, stub object 188 is only a shell of the original exported object 178 and operates as a proxy to that object.  As far as Xlet B 184 is aware however, it has a full instance of the remote object, and can treat stub object 188 as such.  However, instead of processing calls internally, stub object 188 forwards calls to the original exported object 178 and passes the result from remote exported object 178 to Xlet B 184.
[35]In one embodiment, a stub class is generated dynamically for each object type that is imported and instantiated for each imported object to refer to the original exported object.  Thus, if multiple objects are imported having the same type, the stub class for that object type generated once, and then an instance of the stub is instantiated each time an object of that type is imported.  Additional details as to the mechanics of stub generation is provided in United States Patent 6,829,772, issued to William F. Foote et al., U.S. Patent 5,999,988 issued to Pelegri-Llopart et al., and U.S. Patent 6,938,263 issued to Wollrath et al..  In general terms, the remote interface classes are loadable on both the importing and the exporting side.  This means that the interface classes are "on the classpath," just like a normal class.  When an interface class is loaded, the system can "introspect" the class and find its details, i.e., the methods, parameter lists, and return types.  It can then generate the stub class. The mechanism for this sort of introspection is called "reflection" in JAVA(trademark).  Thus, the remote reference includes the names of the remote interfaces, since from the interface names, you can load the interface classes, and from there extract all the information you need to reproduce the interface in the stub class.
[36]When Xlet B 184 imports a remote object thereby generating a new stub, it generates a brand new class name on the fly, instantiates it and makes it refer to the remote exported object.  Stub object 188 implements the interface defined by the object descriptor.  Those skilled in the art will recognize that stub generation is a process that is well known in previous IXC implementations as well as various RMI implementations.
[37]The IXC API ensures that stub object 188 forwards method requests to the exported object 178 along some data path 180, which can be implementation-specific.  For example, data path 180 may be a low level inter-process communication (IPC) mechanism provided by the operating system and hardware layers.  The remote reference defines an endpoint 179 which is analogous to an address of that remote object.  In this way, object registry 166 is likewise accessed by its endpoint 169.  In one embodiment, endpoints 179, 169, are abstracted to a class that can be implemented on top of different transfer mechanisms, i.e., different IPC mechanisms.  In another embodiment, the endpoints are closely bound to the operating system, e.g., using port numbers.
[38]In one embodiment, remote reference 182 sent from Xlet A 182 to registry 166 is an object that contains sufficient information regarding the exported object such that the exported object can be contacted.  In one embodiment, the remote reference object travels from the exporting Xlet to the registry and from the registry to the importing Xlet using JAVA(trademark) object serialization, which is mechanism provided by the JVM to convert an object into a series of numbers, e.g., a byte array, for transmission between isolates or JVM instances.  In another embodiment, the object descriptor object travels using a custom-coded procedure utilizing a lower level command structure.  Persons skilled in the art will understand the various mechanisms available for converting an object into data and transmitting that data between virtual machine (VM) instances.
[39]Figure 7 shows a flow chart 200 representing a procedure for initiating IXC between an Xlet A and an Xlet B.  The procedure begins as indicated by starting block 202 and proceeds to operation 204 wherein Xlet A exports an object by sending a remote reference of the object to an object registry.  In operation 206, the registry binds the exported object name to the remote reference.
[40]The remote reference has sufficient information to enable an Xlet in a different isolate to contact the exported object.  By binding the name of the exported object to the remote reference, an Xlet in a different isolate can retrieve the remote reference by providing the name of the exported object that the Xlet wants to access, as illustrated by the following operations.  From another Xlet's perspective, the exported object is a remote object.
[41]In operations 208 through 212, Xlet B "imports" the remote object.  In operation 208, Xlet B sends a request to the registry for a remote reference to the remote object exported by Xlet A.  In operation 210, the registry sends the remote reference in response to Xlet B's request.  In operation 212, Xlet B type-checks the remote reference by comparing a type descriptor in the remote reference to the expected interface type, thereby ensuring that Xlet B's notion of the type of the remote exported object, which Xlet B retains internally, is consistent with the actual type of the remote exported object.  If the types do not match, an error is generated.  If the types match, then Xlet B generates a stub object corresponding to the type of the remote object.  As mentioned earlier, the stub object is a proxy to the actual remote object, and merely implements the interface of the remote object and forwards calls to and returns results from the remote object.
[42]In operation 214 Xlet B invokes a method in the local stub object, which is forwarded by the stub object to the remote object.  Any results are returned to the stub object, which then passes them back to Xlet B.  The procedure then ends as indicated by ending block 216.
[43]There are various security concerns that are raised when Xlets are permitted to communicate with each other.  One concern, mentioned in the Background section above, is the possibility of a denial of service (DOS) attack.  A system is vulnerable to a DOS attack by malicious code when it can be so tied up in servicing requests by the malicious or malignant program that it cannot service legitimate requests from other programs.  This can overload the system and prevent normal operation.  In the IXC implementation described above with reference to Figures 6 and 7, one concern is that a malicious Xlet could make numerous requests to export numerous objects, causing the object registry to fill up thus prohibiting other Xlets from utilizing the object registry.
[44]In one embodiment, such a DOS attack is prevented by limiting the number of bindings available in the registry from any particular Xlet.  In this scheme, the registry maintains a count of the number objects exported for each exporting Xlet.  If any Xlet reaches its maximum allowed number of exported objects, then any additional requests are denied.
[45]Figure 8 shows a flowchart 220 representing an exemplary procedure for limiting a number of bindings for each Xlet.  The procedure begins as indicated by starting block 222 and flows to operation 224 wherein a request to bind a name of an exported object with a remote reference is received.  The object registry compares a count of bound objects for the requesting Xlet with a maximum number of allowed bound objects in operation 226.  In operation 228, it is determined whether the counter for the number of bound objects is below the maximum allowed number.  If the counter is less than the maximum, then the procedure flows to operation 230 wherein the remote reference and object name is forwarded to the registry table and the counter incremented.  The procedure then ends as indicated by ending block 234.  However, if, at operation 228, it is determined that the counter is not less than the maximum, then the procedure flows to operation 232 wherein the request is denied.  For example, an error message is sent to the requesting Xlet that indicates a maximum number of bound exported objects has been reached.  The procedure then ends as indicated by ending block 234.
[46]As illustrated by Figure 8, the potential problem of a malicious Xlet overloading the object registry with bogus binding requests is eliminated by limiting a number of a available bindings for each Xlet.  An example limit might be 50 or 100 bindings per Xlet.  This number may vary depending on resource limitations and/or other considerations specific to the particular implementation.  The binding limit may be a constant value for each Xlet, or there may be some authentication mechanism whereby known trusted Xlets that require additional bindings can exceed the limit.  It is also possible to limit the number of bindings for each isolate, rather than for each Xlet.
[47]When an exporting Xlet dies, the exported objects cease to be available for processing requests from other Xlets.  It therefore becomes important to update the registry table to reflect the loss of the exported objects attached to the dead Xlet.  It is also helpful to notify Xlets that have imported objects from the dead Xlet to be informed that the remote object is no longer available so that any corresponding stub objects can be destroyed.  This operation allows memory resources to be reallocated to other processes that require it and is often referred to "garbage collection."  In the Xlet programming model, the lifecycle of individual Xlets may controlled by the application manager, which remains aware of the state of the various Xlets on the system.  By maintaining a list of Xlets and objects that those Xlets have imported, the registry can provide the application manager with the information it needs to inform Xlets that have imported objects that have died of the death of the corresponding remote objects.
[48]Figure 9 shows a flowchart 240 that depicts an exemplary garbage collection procedure.  The procedure begins as indicted by starting block 242 and proceeds to operation 244 wherein the application manager notices that a particular Xlet has died.  The Xlet may have died by simply ending or the application manager may have killed it.  The application manager can kill applications in response to a user's request, for example, or when it determines that a particular Xlet is misbehaving, e.g., by consuming too many system resources.  When the application manager notices that the Xlet has died, it proceeds to operation 246 wherein it sends a message to the object registry informing the object registry that the Xlet has died.  In one embodiment, the object registry is an object that is local to the application manager and therefore the message may be passed simply by invoking a method provided by the object registry for this purpose.
[49]In operation 248, the object registry responds to the message by removing the bindings of any objects exported by the dead Xlet.  The objects exported by the dead Xlet are referred to herein as dead objects.  In addition to removing any bindings to dead objects, the object registry sends a message to all the Xlets that imported any of the dead objects.
[50]In operation 250, the importing Xlets respond to the message from the object registry by destroying stub objects corresponding to the dead objects.  The procedure then ends as indicated by ending block 252.  The object registry therefore maintains a list of Xlets for each bound object that have imported the bound object.  When the bound object dies, it can notify all the Xlets that have imported the bound object, and remove the binding, thereby freeing up resources such as memory resources for other applications.
[51]As described above, Figures 6-9 present various aspects of an exemplary implementation of IXC that relies on a central object registry.  To prevent DOS attacks on the registry, each Xlet may be limited by the object registry to a selected maximum number of exported object bindings.  In an alternative embodiment, the registry is distributed so that each isolate maintains a registry for objects exported from that isolate.
[52]Figure 10 shows a schematic diagram of an exemplary implementation of a distributed registry 300 for IXC.  For illustration purposes, two isolates are shown labeled isolate A 310 and isolate B 320.  Isolate A 310 has an Xlet A 312 and isolate B has an Xlet B 322.  For Xlet B 322 to access OBJ_C, Xlet A 312 must first export OBJ_C 316. Xlet A 312 does this by simply adding it to exported isolate registry A 314 located in isolate A 310.  Each isolate contains an exported isolate registry, as shown by way of example where isolate B 320 contains an exported isolate registry B 324.  Each exported isolate registry contains a list of objects exported by Xlets in that isolate.  Thus, exported isolate registry A 314 contains a list of objects and corresponding remote references bound to those objects.  Xlet A does not need to do anything further to export the object OBJ_C.  To Xlets outside Isolate A, OBJ_C is a remote object.
[53]For Xlet B 322 to import OBJ_C, it first contacts registry proxy 332 to request a remote reference, what Xlet B 322 will perceive as an instance, of the remote object OBJ_C.  In one embodiment, the registry proxy 332 is implemented using a set of specialized commands.  In another embodiment, the registry proxy 332 is a remote object provided by application manager 330 and is contacted by IXC from other Xlets including Xlet B.  In this case, Xlet B therefore must import the registry proxy object prior to contacting it to obtain import OBJ_C.  To ensure that Xlets can find the registry proxy object, the remote reference to the registry proxy is a constant value provided by the JVM.  In either embodiment, Xlet B 324  sends a message to registry proxy 332 requesting that it retrieve a remote reference to OBJ_C.  To fulfill this request, registry proxy 332 refers to a list of isolates in isolate table 334 maintained by application manager 330, and polls each exported isolate registry in each isolate to find out if the particular object being sought is in that isolate.  In one embodiment, this search of the isolates may be optimized using a consistent naming scheme.  For example, each isolate may attach a unique prefix to the names of exported objects allowing the registry proxy to first search in the isolates having a prefix in common with the remote object being sought.
[54]To prevent Xlets from exporting objects during a search, which could lead to unexpected results, the registry obtains an exclusive lock.  When the registry proxy controls the lock, individual Xlets are prevented from modifying the exported isolate registries.  When Xlet A exports object OBJ_C, it first obtains the exclusive lock or to ensure the registry proxy does not have possession of it.  Once the registry proxy 332 finds the searched remote reference bound to the OBJ_C, it retrieves the reference from the exported isolate registry, passes it to Xlet B 322 to complete the transaction with Xlet B, and releases the exclusive lock.  If the type-checking matches as described above, Xlet B 322 proceeds to generate stub object 326 which provides the interface for remote object OBJ_C 316 and passes calls to OBJ_C 316.
[55]Figure 11 shows a flowchart 350 illustrating an exemplary procedure for implementing IXC between Xlet A 312 and Xlet B 322.  The procedure begins as indicated by start block 352 and proceeds to operation 354 wherein Xlet A exports OBJ_C by entering it into the exported isolate registry.  In operation 356, at some later time, Xlet B requests the remote object from the registry proxy which is provided by the application manager.  In operation 358, the registry proxy, in response to the request from Xlet B, searches exported isolate registries for OBJ_C.  The registry proxy obtains control of an exclusive lock during the search, to prevent the exported isolate registries from being modified during the search.  In operation 360, the exported isolate registry in isolate A responds to the request from the registry proxy with the remote reference corresponding to OBJ_C.  In operation 362, the registry forwards the remote reference to Xlet B, which type-checks the remote reference and generates a stub object corresponding to remote object OBJ_C.
[56]Although the distributed registry model requires the additional steps of polling the various isolates, this is acceptable in an environment where each isolate exists on the same machine.  This is unlike RMI protocols where registry may not be located on the same machine as the remote objects which would make a search of a distributed registry prohibitively long.  Since the IXC model is limited to providing communication between Xlets on the same physical machine, the delay associated with the search would be minimal and provide the added advantage of no arbitrary limits on the number of exported objects a particular Xlet can have.
[57]The distributed registry model also potentially simplifies garbage collection.  In the typical case, there will only be one Xlet for each isolate.  When that Xlet dies, the isolate shuts down and the exported isolate registry disappears with the isolate.  Thus, no additional steps are required to remove the registry entries when an Xlet dies in this circumstance.  In cases where there is more than one Xlet in an isolate, when the Xlet dies gracefully, it calls a procedure to shut itself off and that will include a call to the exported isolate registry to remove any entries relating to the Xlet being shut down.  If an Xlet locks up, e.g., goes into an infinite loop and gobbles up resources, the entire isolate is shut down, including other Xlets operating in that isolate.  This removes the exported isolate registry as well.
[58]As for notifying Xlets in other isolates that have imported objects from a dead or dying Xlet, there are two approaches.  The first approach is a proactive approach similar to the method discussed above with reference to Figure 9 wherein the application manager notifies each Xlet that has imported objects from the dead or dying Xlet that the remote objects no longer exist, prompting the corresponding stub objects to be destroyed.  This notification could be a broadcast message to all Xlets, or targeted to only those Xlets that have imported objects from the dead or dying Xlet.  In another embodiment, in what may be termed a reactive approach to garbage collection of defunct imported objects, the importing Xlets are not notified of the deaths of the remote object until the Xlet attempts to contact the remote object.
[59]Figure 12 shows a flowchart 370 illustrating a reactive approach to garbage collection of defunct imported objects.  The procedure begins as indicated by starting block 372 and proceeds to operation 374 wherein Xlet B invokes a method in its local stub object.  In operation 376, the local stub object forwards the call to the remote object in isolate A.  As shown by operation 378, what happens next depends on whether the remote object exists.  If the remote object exists, the procedure proceeds to operation 380 wherein the remote object processes the request and returns a result.  Then, in operation 382, the local stub object passes the result to Xlet B.  The procedure then ends as shown by ending block 388.
[60]If the remote object no longer exists, either because the Xlet shut down or the isolate shut down, then the stub object receives an error indicating that the remote object was not found in operation 384.  This error could be passed by the low level IPC mechanism implemented by the IXC API.  Alternatively, it could be generated in response to a time-out error.  When the stub object receives this error, it passes it to Xlet B and dies in operation 386.  The stub object may terminate itself or be terminated by the Xlet when the Xlet receives the error from the stub object.  The procedure then ends as indicated by ending block 388.
[61]Because both Xlets are on the same machine, communication between Xlets is reliable.  The IXC protocol is therefore designed to leverage this reliability by providing a simple yet robust IXC infrastructure that satisfies the need for communication between Xlets, without compromising the security fostered by the protected domain provided by the isolates.
[62]With the above embodiments in mind, it should be understood that the invention can employ various computer-implemented operations involving data stored in computer systems.  These operations are those requiring physical manipulation of physical quantities.  Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared and otherwise manipulated.  Further, the manipulations performed are often referred to in terms such as producing, identifying, determining, or comparing.
[63]Any of the operations described herein that form part of the invention are useful machine operations.  The invention also relates to a device or an apparatus for performing these operations.  The apparatus can be specially constructed for the required purpose, or the apparatus can be a general-purpose computer selectively activated or configured by a computer program stored in the computer.  In particular, various general-purpose machines can be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
[64]The invention can also be embodied as computer readable code on a computer readable medium.  The computer readable medium is any data storage device that can store data, which can be thereafter be read by a computer system.  The computer readable medium also includes an electromagnetic carrier wave in which the computer code is embodied.  Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes and other optical and non-optical data storage devices.  The computer readable medium can also be distributed over a network-coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
[65]Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims.  Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
3. BRIEF DESCRIPTION OF THE DRAWINGS
[66]
Figure 1 shows an exemplary prior art configuration for remote method invocation (RMI).
Figure 2 shows an exemplary prior art configuration for inter-Xlet communication (IXC).
Figure 3 shows an exemplary configuration for IXC between isolates.
Figure 4 shows an exemplary device in which the invention may be implemented. 
Figure 5 shows exemplary hardware and software layers for executing Xlets on a device.
Figure 6 presents a schematic diagram illustrating an exemplary implementation of IXC between isolates.
Figure 7 shows a flowchart illustrating an exemplary procedure implementing IXC.
Figure 8 shows a flowchart representing an exemplary procedure for limiting a number of bindings for each Xlet. 
Figure 9 shows a flowchart that depicts an exemplary garbage collection procedure. 
Figure 10 shows a schematic diagram of an exemplary implementation of a distributed registry for IXC. 
Figure 11 shows a flowchart illustrating an exemplary procedure for implementing IXC between two Xlets with a distributed registry. 
Figure 12 shows a flowchart illustrating a reactive approach to garbage collection of defunct imported objects.
1.  A computer-implemented method for managing a registry of bound objects for inter-Xlet communication (IXC), the method comprising:
receiving a request from a first Xlet to bind an exported object name with a remote reference;
comparing a number of objects exported by the first Xlet with a maximum number;
adding a binding for the exported object name and the remote reference when the number of objects exported is less than the maximum number; and
denying the request when the number of objects exported is not less than the  maximum number.
2.  The method of claim 1, wherein the request comprises a remote reference object, the receiving comprising receiving the remote reference object by JAVA(trademark) Object Serialization.
3.  The method of claim 1, further comprising:
receiving a request from a second Xlet for the remote reference of the exported object;
sending the remote reference to the second Xlet in response to the receiving of the request from the second Xlet.
4.  The method of claim 3, wherein the remote reference includes sufficient information to enable an Xlet in a different isolate to contact the exported object.
5.  The method of claim 3 wherein the remote reference further includes an interface descriptor that is representative of a type of the exported object.
6.  The method of claim 1, further comprising:
when an Xlet dies, removing bindings for objects exported by the dead Xlet;
identifying Xlets that imported the dead Xlet; and
communicating to the Xlets that imported the dead Xlet that the objects exported by the dead Xlet have died.
7.  A computer-implemented method for inter-Xlet communication (IXC), the method comprising:
sending a remote reference to an exported object from a first Xlet in a first isolate to an object registry located outside the first isolate;
binding the remote reference with a name of the exported object in the object registry;
sending a request from a second Xlet in a second isolate for a remote reference of the exported object;
responding to the request by forwarding the remote reference to the second Xlet;
instantiating a stub object for the second Xlet, the stub object being in communication with the exported object; and wherein
the object registry limits each Xlet to a selected number of bindings.
8.  The method of claim 7, wherein the remote reference is an object and is transmitted between Xlets and the object registry using JAVA (trademark) Object Serialization.
9.  The method of claim 7, further comprising:
type checking the remote reference to ensure that an interface provided by the exported object matches an expected interface that is expected by the second Xlet; and
generating a stub class for the interface when the exported object is of a type that has not previously been imported wherein the instantiating the stub object comprises instantiating an instance of the stub class.  
10.  The method of claim 7, further comprising:
removing bindings for objects exported by a dead Xlet when the dead Xlet dies;
identifying Xlets that imported objects exported by the dead Xlet; and
destroying stub objects corresponding to the objects exported by the dead Xlet.
11.  The method of claim 7, wherein the object registry is an object exported by an application manager, the sending a remote reference comprising using IXC to send the remote reference to the object registry.
12.  The method of claim 7, wherein the remote reference includes an exporting Xlet identifier, an exporting Xlet endpoint identifier, and an interface descriptor.
13.  The method of claim 12, wherein the interface descriptor represents a type of an interface provided by the exported object, the type including a method name, at least one parameter type and a return type for each method.
14.  The method of claim 13, further comprising:
generating a stub class corresponding to the type when there has been no previous objects imported having an identical type, wherein the instantiating the stub object comprises instantiating an instance of the stub class.  
15.  A computer readable media having program instructions for object oriented inter-Xlet communication (IXC) between isolates, the computer readable media comprising:
program instructions for exporting an object from a first Xlet, the exporting comprising sending a request from the first Xlet to an object registry to bind a name of the exported object with a remote reference;
program instructions for comparing a number of objects exported by the first Xlet with a maximum number;
program instructions for adding a binding to the object registry for the name of the exported object and the remote reference when the number of objects exported is less than the maximum number; and
program instructions for denying the request when the number of objects exported is not less than the selected maximum number.
16.  The computer readable media of claim 15, wherein the request comprises a remote reference object, the receiving comprising receiving the remote reference object by JAVA(trademark) Object Serialization.
17.  The computer readable media of claim 15, further comprising:
program instructions for sending a request from a second Xlet to the object registry for the remote reference of the exported object; and
program instructions for sending the remote reference to the second Xlet in response to the request from the second Xlet; and 
program instructions for instantiating a stub object corresponding to the exported object.
18.  The computer readable media of claim 17, further comprising:
type checking the remote reference to ensure that the interface provided by the exported object matches the interface expected by the second Xlet.  
19.  The computer readable media of claim 17, wherein the remote reference includes sufficient information to enable an Xlet in a different isolate to contact the exported object.
20.  The computer readable media of claim 19 wherein the remote reference includes an exporting Xlet identifier, an exporting Xlet endpoint identifier, and an interface descriptor.
21.  The computer readable media of claim 20, further comprising:
program instructions for generating a stub class corresponding to the interface descriptor when no object having an identical interface descriptor has been previously imported; and wherein the program instructions for instantiating the stub object instantiate an instance of the stub class.
22.  The computer readable media of claim 15, further comprising:
program instructions for removing bindings for objects exported by a dead Xlet when the dead Xlet dies;
program instructions for identifying Xlets that imported the dead Xlet; and
program instructions for informing the Xlets that imported the dead Xlet that the objects exported by the dead Xlet have died.
23.  The computer readable media of claim 15 wherein the object registry is an object exported by an application manager, the sending a remote reference comprising using IXC to send the remote reference to the object registry.
1. ABSTRACT
A computer implemented method and machine readable media for managing a registry of bound objects for inter-Xlet communication (IXC) is described.  A request from a first Xlet to bind an exported object name with a remote reference is received.  A number of objects exported by the first Xlet is compared with a maximum number.  If the number of objects exported is less than the maximum number then a binding is added for the exported object name and the remote reference.  If the number of objects exported is greater than the maximum number, then the request is denied.
2. REPRESENTATIVE DRAWING
Fig. 3
2007128507.tif 000015
2007128507.tif 000016
2007128507.tif 000017
2007128507.tif 000018
2007128507.tif 000019
2007128507.tif 000020
2007128507.tif 000021
2007128507.tif 000022
2007128507.tif 000023
2007128507.tif 000024
2007128507.tif 000025
2007128507.tif 000026