携帯電話、携帯情報端末（ＰＤＡ）、テレビ用のセット・トップ・ボックスなどのコネクテッド・デバイスのためのコンピュータシステムは、より柔軟なものになりつつある。 最近のシステムでは、ソフトウェアをダウンロードして実行することが可能になっている。 ダウンロードされたソフトウェアは、完全に信頼できるとは限らず、既存の信頼できるソフトウェアとリソースを共有する場合もある。 したがって、信頼できないソフトウェアのアクセスを制限することにより、そのソフトウェアがシステムの動作を妨害することを防ぐために、様々な技術が提案および実施されている。 しかしながら、これらのシステムの目的は、ソフトウェア・コンポーネントが互いに通信することを可能にするという別の目標と対立するものである。

ソフトウェア・コンポーネントが互いに通信することを可能にするための周知の機構の１つとして、リモート・プロシージャ・コール（ＲＰＣ）が挙げられる。 この機構によると、あるホスト上で実行中のコンピュータプログラムが、別のホスト上でコードを実行させて、その結果を第１のプログラムに返させることが可能になる。 通例、ＲＰＣプロトコルは、分散コンピューティングのクライアントサーバモデルを実装するために用いられる。

様々なエディションのＪＡＶＡ（登録商標）プラットフォームが、オブジェクト間の通信のために、ＲＰＣを実行するためのリモートメソッド呼び出し（ＲＭＩ）として知られる機構を提供している。 ＲＭＩでは、リモートＪＡＶＡ（登録商標）オブジェクトのメソッドは、別のＪＡＶＡ（登録商標）仮想マシン（場合によっては、別のホスト上のもの）から呼び出し可能である。 図１に示すように、ＲＭＩ １００は、基本的に、ＪＡＶＡ（登録商標）仮想マシン（ＪＶＭ） Ａ １０２およびＪＶＭ Ｂ １０４の間の通信を可能にする。 ＪＶＭ Ａ １０２およびＪＶＭ Ｂ １０４は、同じ物理マシンで作動してもよいし、異なるマシンで作動して、ローカルエリアネットワーク（ＬＡＮ）、インターネットプロトコル（ＩＰ）ネットワーク接続、または、その他の通信媒体を介して接続されてもよい。 ＲＭＩ １００を実装するアプリケーショ・プログラム・インターフェース（ＡＰＩ）は、仮想マシン間の通信の詳細を取り扱う。

ＲＭＩは、異なるプロトコルでの異なるマシン間の通信のために必要なコンポーネントおよびセキュリティ手段をすべて備えるため、複雑になっており、ほとんどのコネクテッド・デバイスでは全く必要のない多くの特徴を提供することから、小型のデバイスにとっては扱いにくい場合がある。 したがって、ＲＭＩ ＡＰＩは、ＪＡＶＡ（登録商標）２プラットフォームのマイクロエディション（Ｊ２ＭＥ）のパーソナル・ベイシス・プロファイル（ＰＢＰ）には含まれていない。

ＪＡＶＡ（登録商標）アプリケーションのための従来のモデルは、所与の仮想マシンで実行中のアプリケーションが１つだけであることを想定しているため、そのアプリケーションは、自身が動作している仮想マシンの強制終了を含めて、自身のライフサイクルを完全に管理する。 典型的なコネクテッド・デバイスで利用可能な限られた処理リソースおよびメモリリソースに対応した上で、複数のプログラムを同時に実行させることを可能にするために、ＪＡＶＡ（登録商標）コミュニティプロセス（ＪＣＰ）は、Ｘｌｅｔと呼ばれるプログラミングモデルの利用を提案した。

Ｘｌｅｔは、インターネットウェブブラウザによって実行可能なアプレットや、ウェブサーバによって実行可能なサーブレットと同様のものであり、複数のＸｌｅｔが、１つのＪＶＭで同時に実行されることが可能であり、それらのライフサイクルは、他のプログラムによって管理可能である。 アプレットの場合には、他のプログラムとは、一般に、ウェブブラウザである。 ＪＶＭの１つのインスタンスで複数のプログラムを実行すると、仮想マシンの内部データ構造の一部を共有することにより、システム全体の性能および拡張性を向上させることができる。 Ｘｌｅｔは、スタンドアロンのアプリケーションマネージャによって管理されてよい。

１つのＪＶＭによって複数のＸｌｅｔを作動させることがでるため、ダウンロードされた悪質なＸｌｅｔによる害を受ける可能性のある複数組のＸｌｅｔを保護するための機構が必要となった。 そのため、論理仮想マシン（ＬＶＭ）の概念が生み出された。 ＬＶＭは、同じリソースまたはオブジェクトを共有する１または複数のプログラムからコードを参照するための機構を提供するリソースコンテキスト構造である。 ある特定のＬＶＭに関連スレッドを関連付けることにより、関連スレッドが（例えば、サービス妨害攻撃を起こすことにより）不正な動作をした際に、それらを一緒に終了できるようになる。

しかしながら、複数のＸｌｅｔを別々のＬＶＭに分離することによって保護することは、互いの通信を不可能することを意味するため、望ましくない。 したがって、別々のＬＶＭ、より一般的には、別々のリソースドメインから、複数のＸｌｅｔが互いに通信することを可能にするためのいくつかの機構が必要になった。 ２００４年１２月７日に発行された米国特許６，８２９，７２２は、複数のＸｌｅｔが別々のＬＶＭから互いに通信することを可能にするＸｌｅｔ間通信（ＩＸＣ）と呼ばれる方法を提供しており、この参照によって本明細書に組み込まれる。 この特許の出願時には、「Ｘｌｅｔ」という用語は、まだ作られていなかったため、その明細書では、Ｘｌｅｔを、一般に用いられていた「アプレット」という用語で呼んでいることに注意されたい。

ＩＸＣ ＡＰＩは、現在、Ｊ２ＭＥ ＰＢＰの一部である。 図２は、別々のＬＶＭにそれぞれ属する２つのＸｌｅｔ（すなわち、Ｘｌｅｔ Ａ １１２およびＸｌｅｔ Ｂ １１４）の間のＩＸＣ １１０を示す図である。 しかしながら、このＩＸＣ実装は、単一プロセスの複数仮想マシン（ＭＶＭ）パラダイムと呼ばれるものに限定される。 このパラダイムでは、各ＬＶＭ １１６および１１８は、単一プロセスＪＶＭ １２０で実行され、共通アドレス空間を共有する。 ＩＸＣ実装（図示せず）は、各ＬＶＭ間でインスタンスを共有するために共通アドレス空間を利用する。

Ｘｌｅｔを実行するための分離コンテキストは、現在、「アイソレート」と呼ばれている。 アイソレートの一実施例では、各アイソレートは、自身のプロセス内で実行されるため、自身のアドレス空間を有する。 これは、「複数プロセスのＭＶＭ」パラダイムと呼ばれてよい。 ＪＡＶＡ（登録商標）アプリケーションアイソレートＡＰＩは、ＪＡＶＡ（登録商標）仕様作成要求１２１（ＪＳＲ−１２１）で規定されている。 ＩＸＣのための以前の機構は、Ｘｌｅｔ間で共通アドレス空間を利用していたため、この新しいパラダイムでの実装は構造的に不可能であった。

したがって、サービス妨害攻撃を防止するために必要なセキュリティ手段を提供しつつ、Ｘｌｅｔ間のＲＰＣが、共通のＪＶＭにおける別々のアイソレートに配置されることを可能にする新しいＩＸＣ機構が必要とされている。 この新しい機構は、さらに、信頼性の高いガーベッジコレクションと、効率的な型検査とを提供することが好ましい。 さらに、ＩＸＣ実装は、アイソレート実装に対して最適化されることが好ましく、その場合、複数のアイソレートは、同一のマシン上であるが別々のアドレス空間に存在する。

概して、本発明は、これらの要求を満たすために、アイソレート間でのオブジェクト指向通信を実現する方法およびマシン読み取り可能な媒体を提供する。

本発明は、プロセス、装置、システム、デバイス、方法を含む数多くの態様で実施可能であることを理解されたい。 以下では、本発明のいくつかの実施形態について説明する。

一実施形態では、Ｘｌｅｔ間通信（ＩＸＣ）のために、結合されたオブジェクトのレジストリを管理するためのコンピュータによる方法およびマシン読み取り可能な媒体が提供されている。 エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合する要求が、第１のＸｌｅｔから受信される。 第１のＸｌｅｔによってエクスポートされたオブジェクトの数が、最大数と比較される。 エクスポートされたオブジェクトの数が、最大数よりも小さい場合には、エクスポートされたオブジェクトのオブジェクト名とリモート参照との結合が追加される。 エクスポートされたオブジェクトの数が、最大数よりも大きい場合には、要求は拒否される。

別の実施形態では、Ｘｌｅｔ間通信（ＩＸＣ）のための方法が提供されており、第１のアイソレート内の第１のＸｌｅｔからエクスポートされたオブジェクトへのリモート参照が、第１のアイソレートの外に位置するオブジェクトレジストリに送信される。 オブジェクトレジストリ内で、リモート参照と、エクスポートされたオブジェクトのオブジェクト名とが結合される。 オブジェクトレジストリは、エクスポートされたオブジェクトのリモート参照への要求を、第２のアイソレート内の第２のＸｌｅｔから受信する。 それに応じて、リモート参照が、第２のＸｌｅｔに転送される。 第２のＸｌｅｔのためにスタブオブジェクトが生成され、そのスタブは、エクスポートされたオブジェクトと通信を行う。 オブジェクトレジストリは、ある結合数に各Ｘｌｅｔを制限する。

さらに別の実施形態では、アイソレート間でのオブジェクト指向のＸｌｅｔ間通信（ＩＸＣ）のためのプログラム命令を有するコンピュータ読み取り可能な媒体が提供されている。 そのコンピュータ読み取り可能な媒体は、第１のＸｌｅｔからオブジェクトをエクスポートするためのプログラム命令であって、そのエクスポートは、エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合する要求を、第１のＸｌｅｔからオブジェクトレジストリに送信する動作を備えるプログラム命令と、エクスポートされたオブジェクトの数が、最大数よりも小さい場合に、エクスポートされたオブジェクトのオブジェクト名とリモート参照との結合をオブジェクトレジストリに追加するためのプログラム命令と、エクスポートされたオブジェクトの数が、選択された最大数以上である場合に、要求を拒否するためのプログラム命令と、を備える。

本発明の利点は、実施例を用いて本発明の原理を示すために添付の図面を参照しつつ行われる以下の詳細な説明から明らかになる。

本発明は、添付の図面を参照した以下の詳細な説明によって容易に理解可能であり、同じ符号は、構造上の同じ要素を示している。

以下の説明では、本発明の完全な理解を促すために、多くの詳細事項が具体的に示されている。 しかしながら、これらの具体的な詳細事項の一部またはすべてがなくとも、本発明を実現できることは、当業者にとって明らかである。 また、本発明を不必要にわかりにくくすることがないよう、周知のプロセス動作および実装の詳細事項の説明は省略してある。

本発明は、アイソレート間でのオブジェクト指向通信に関する。 アイソレートは、コンピュータシステム内の保護されたドメインであり、１または複数のスレッドを、そのシステムで作動する他の悪質なスレッドによる悪影響から保護する。 ＪＡＶＡ（登録商標）仕様作成要求１２１（ＪＳＲ−１２１）では、アイソレートは、スレッドとＪＡＶＡ（登録商標）仮想マシン（ＪＶＭ）との間の中間構造体として記載されている。 より具体的には、ＪＡＶＡ（登録商標）パーソナル・ベイシス・プロファイルのコンテキスト中のアイソレートは、アプリケーションまたはコンポーネントをカプセル化するアイソレートクラスのインスタンスであり、演算処理の分離を開始および停止するための手段を提供する。 例えば、アイソレートを用いて、同時実行を開始することができる。 ＪＶＭのように、アイソレートは、実行中の可能性がある任意の他のＪＡＶＡ（登録商標）プログラムと無関係に、与えられたクラスの「メイン」メソッドの実行を自身のシステムレベルのコンテキスト内で進めさせる。 このように、アイソレートは、スタティックまたはアプリケーションごとのランタイムオブジェクトを共有することから干渉がないことを保証する点でスレッドとは異なり、作成、開始、終了、監視、および、これら独立した動作との通信を行うアプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供する点でＪＶＭとは異なる。 アイソレートは、それらの中で作動するアプリケーションに対して透過的に作動してよい。 本開示では、「アイソレート」という用語は、単に、自身のプロセス内で実行されるために自身のアドレス空間を有する仮想マシン内の保護されたドメインを特定するために用いられてよい。

オブジェクト指向通信とは、ソフトウェアオブジェクト間の通信のことである。 ソフトウェアオブジェクトとは、実行可能なコードおよびデータを備えるソフトウェア構造体であり、変数内に保持される。 データは、オブジェクト内で保護されており、オブジェクトによって提供されるメソッドを用いてアクセス可能である。 それらのメソッドは、プロシージャを実行するために、他のオブジェクトによって呼び出すことが可能である。 それらのメソッドは、オブジェクトによって変数に提供されるインターフェースであってもよいし、呼び出し側のオブジェクトの代わりに動作を実行してもよい。 このように、オブジェクトメソッドは、プロシージャ言語の機能またはサブルーチンと同様のものである。 オブジェクト間の通信は、あるオブジェクトが第２のオブジェクトにメッセージを送って第２のオブジェクトのメソッドを呼び出すことによって起きる。 次いで、メソッドからの結果はすべて、呼び出し側のオブジェクトに返される。

図３は、アプリケーションマネージャ（図示せず）によってＪＶＭ １４０を用いてインスタンスを生成された第１のアイソレートＡ １３０および第２のアイソレートＢ １３２を含む２つのアイソレートの間でのＸｌｅｔ間通信（ＩＸＣ）のための構成の一例を示す図である。 各アイソレート１３０および１３２は、その中で実行されるＸｌｅｔ １３４および１３６をそれぞれ備える。 各Ｘｌｅｔは、１または複数のオブジェクト（図示せず）を備える。 ＪＶＭ １４０は、１つのマシン内に存在し、それぞれシステム内の別個のプロセスおよびアドレス空間で作動する各アイソレート１３０および１３２のための共通リソースを提供する。 ＪＶＭ １４０は、アイソレートを作成および破棄するためのアイソレートＡＰＩや、Ｘｌｅｔ Ａ １３４とＸｌｅｔ Ｂ １３６との間のＩＸＣ １３８を提供するＩＸＣ ＡＰＩなど、複数のＡＰＩを備える。 以下で詳細に説明するように、ＩＸＣ １３８は、Ｘｌｅｔ Ｂが、Ｘｌｅｔ Ａのオブジェクト内のメソッドを呼び出して応答を受け取ることを可能にする。 図３は、共通のＪＶＭ １４０を示しているが、Ｘｌｅｔ ＡとＸｌｅｔ Ｂとは、別個のＪＶＭに属してもよい。

本発明の様々な実施形態で、特定のＪＶＭおよびＪＡＶＡ（登録商標）プログラミング言語について言及しているが、本発明は、他のオブジェクト指向プログラミング言語や他の仮想マシンにも適用可能である。 したがって、ＪＡＶＡ（登録商標）への限定を意図していないことに注意されたい。 さらに、「Ｘｌｅｔ」という用語は、保護されたドメインまたは仮想マシンを他のアプリケーションと共有することが可能であり、アプリケーションマネージャなどの外部プログラムによってそのライフサイクルを管理できる種類のオブジェクト指向アプリケーションを示すよう意図されている。 本明細書で用いられている「Ｘｌｅｔ」という用語は、一般的なものであり、アプレット、サーブレット、および、他の類似のプログラミングモデルを含む。

図４は、本発明を実施できるデバイス１５０の一例を示す図である。 一実施形態では、デバイス１５０は、コネクテッド・デバイスであり、コネクテッド・デバイスとは、少なくとも時々、外部のネットワークやシステムに接続可能であることを意味する。 デバイス１５０は、少なくとも１つのプロセッサ１５２と、メモリ１５４と、ユーザインターフェース１５６と、入出力システム１５８とを備え、それらのコンポーネントは、データバス１６０を介して互いに通信する。 意図される用途に応じて、プロセッサ１５２は、シングルコア・プロセッサでもマルチコア・プロセッサでもよく、複数のプロセッサを備えてもよい。 プロセッサ１５２は、携帯情報端末や携帯電話などの携帯デバイスのために低電力に最適化されてもよいし、コンピュータワークステーションやサーバで見られるように、プロセッサ集中的な動作のために速度に最適化されてもよい。 デバイス１５０は、デバイスの使用方法に応じて、他のコンポーネント（図示せず）を備えてもよい。 例えば、デバイス１５０が携帯電話である場合には、音声通信用のコンポーネントを備えてよい。 デバイス１５０がテレビ用のセット・トップ・ボックスである場合には、受信機とビデオ処理回路とを備えてよい。

メモリ１５４は、ランダムアクセスメモリ（ＲＡＭ）の１つのブロックを備えてよく、すなわち、電源を切った際に情報を保持できない揮発性メモリであってよい。 あるいは、メモリ１５４は、揮発性ＲＡＭ、フラッシュメモリのような不揮発性ＲＡＭ、および／または、不揮発性の大容量ストレージなど、セグメントメモリまたは多層メモリであってもよい。 メモリ１５４は、さらに、デバイスの基本入出力システム（ＢＩＯＳ）、オペレーティングシステムのコンポーネント、および／または、様々なソフトウェアアプリケーションやユーティリティを格納するための読み出し専用メモリ（ＲＯＭ）を備えてもよい。 メモリ１５４は、デバイス１５０内に固定されてもよいし、取り外し可能であってもよい。 例えば、メモリ１５４は、「コンパクトフラッシュ（登録商標）」、「メモリースティック」、「ＳＤカード」という商標で販売されているメモリなど、取り外し可能な記憶装置であってよい。 メモリ１５４が、取り外し可能なメモリを備える場合には、コンピュータやネットワークなどの外部システム１６２を用いて、新しいソフトウェアをメモリ１５４に追加してもよい。 次いで、新しいソフトウェアは、プロセッサ１５２上で実行され、さらなる機能をデバイス１５０に提供してよい。

ユーザインターフェース１５６は、ユーザへの出力やユーザからの入力を実現するための様々な要素を備えてよい。 例えば、出力側では、ユーザインターフェース１５６は、携帯デバイス用の小型の液晶ディスプレイ（ＬＣＤ）と、スピーカとを備えてもよいし、コンピュータワークステーション用の高解像度ディスプレイを備えてもよい。 セット・トップ・ボックスでは、ユーザインターフェース１５６は、ビデオおよびオーディオ信号にアプリケーション情報を重ねることができるビデオおよびオーディオ出力を備えてよい。 入力側では、ユーザインターフェース１５６は、キーパッド、タッチスクリーン、フルサイズのキーボード、リモートコントロール、音声駆動、および／または、ユーザに双方向性を提供する任意の数の他のユーザ入力を備えてよい。

一実施形態では、デバイス１５０は、外部との通信を可能にする入出力システム１５８を備える。 具体的には、デバイス１５０は、ネットワーク、コンピュータシステム、または、他のデバイスなどの外部システム１６２に対して、常に接続されてもよいし、時々接続されてもよい。 特に、外部システム１６２は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、または、リモートコンピュータやインターフェースデバイスを含みうる。 ネットワークすなわち外部システム１６２は、実行可能なソフトウェアをデバイス１５０にダウンロードすることが可能である。

動作中に、ＪＶＭ １４０（図３）は、メモリ１５４にロードされ（もしくは、メモリ１５４内にすでに存在し）、プロセッサ１５２で実行される。 ＪＶＭ １４０は、メモリ１５４内に存在するＪＡＶＡ（登録商標）バイトコードを実行するための仮想マシンを提供する。 ＪＡＶＡ（登録商標）バイトコードは、ＪＶＭ １４０を用いて解釈またはジャスト・イン・タイム（ＪＩＴ）コンパイルされ、デバイス１５０に機能を提供する。 デバイス１５０は、例えば、他のＪＡＶＡ（登録商標）ソフトウェアをダウンロードして実行させるためのＪＡＶＡ（登録商標）ソフトウェアを備えてよい。 一実施形態では、ＪＶＭ １４０は、デバイスに機能を提供するＸｌｅｔをロード、起動、終了するためのアプリケーションマネージャを備える。

図５は、デバイス１５０上でＸｌｅｔを実行するためのハードウェアおよびソフトウェアの層１５５の一例を示す図である。 一番下のレベルには、コネクテッド・デバイス１５０が存在し、図４を参照して上述した様々なコンポーネントを備えている。 ハードウェア層の上には、ＢＩＯＳ／ＯＳ層１６０が存在する。 ＢＩＯＳおよびＯＳは、別個のソフトウェア層として存在してもよいし、一体化されてもよい。 それらは、一般に、より上位のソフトウェア層による呼び出しに応じて、ユーザインターフェースなどの様々なハードウェアコンポーネントを駆動する機能を有する。 ＢＩＯＳ／ＯＳ層１６０の上には、１または複数のＪＶＭ層１４０が存在する。 ＪＶＭ層１４０は、それぞれ、アプリケーションマネージャ１６５やＸｌｅｔ１３４、１３６などのアプリケーションソフトウェアを解釈および／またはコンパイル（例えばＪＩＴコンパイルなど）することにより実行するための独立したプラットフォームを提供する。 上述のように、ＪＶＭ層１４０は、アイソレート層１３２のインスタンスを生成して、保護された環境をＸｌｅｔ１３４および１３６に提供することもできる。

図６は、アイソレート間のＩＸＣの実装の一例を示す説明図１７０である。 このプログラミングモデルは、他のリモートメソッド呼び出しモデルとの共通点を有する。 説明のため、２つのアイソレート、すなわち、アイソレートＡ １７２とアイソレートＢ １７４が図示されている。 アイソレートＡ １７２は、デバイスで作動する他のＸｌｅｔに特定の機能を提供するＸｌｅｔ Ａ １８２を含む。 例えば、Ｘｌｅｔ Ａ １８２は、アドレス帳検索機能を提供してよく、その場合、Ｘｌｅｔ Ｂ １８４は、特定の個人の電話番号やＥメールアドレスを探すために、その機能にアクセスする必要がある。 Ｘｌｅｔ Ａ １８２およびＸｌｅｔ Ｂ １８４は、この通信のためのインターフェースについて合意する。 インターフェースは、例えば、クエリのための特定のパラメータと所望の応答のための特定の変数型とを備えた特定のメソッドを有する特定のオブジェクトであってよい。 Ｘｌｅｔ Ａ １８２は、Ｘｌｅｔ Ｂ １８４によって予期されたメソッドを有するオブジェクトＯＢＪ＿Ｃを提供する。

ＯＢＪ＿Ｃを他のＸｌｅｔに対して利用可能およびアクセス可能にするために、Ｘｌｅｔ Ａ １８２は、オブジェクトレジストリ１６６へのリモート参照を含むメッセージ１９２を送信する。 Ｘｌｅｔ １８２は、インフラストラクチャを維持するため、エクスポートしたばかりのＯＢＪ＿Ｃへの要求に応じることができる。 レジストリは、予期された位置に提供されるか、もしくは、システム上で作動するすべてのＸｌｅｔに利用可能にされる。 一実施形態では、レジストリ自体は、別のプロセスに存在するアプリケーションマネージャ１６５によってエクスポートされたリモートオブジェクトである。 この場合、レジストリへのリモート参照は、ＪＶＭ ＡＰＩによって定数として定義される。 Ｘｌｅｔ Ａ １８２によってオブジェクトレジストリ１６６に送信されたリモート参照は、オブジェクト名、オブジェクトへのリモート参照、および、オブジェクト記述を含む。 記述は、インターフェースの詳細を含んでもよいし、単に、ハッシュコードなど、これらの詳細の固有識別子を含んでもよい。 オブジェクトレジストリ１６６は、システム上のどこかに配置されたレジストリテーブル１７６を維持する。 レジストリテーブル１７６は、オブジェクト名とリモートオブジェクト参照とを関連付けたリストを含む。 したがって、レジストリテーブルは、エクスポートされたオブジェクトのオブジェクト名を、エクスポートされたオブジェクトへの参照に結合している。

一実施形態では、リモート参照は、４つのデータ要素、すなわち、エクスポート側Ｘｌｅｔの識別子と、エクスポート側Ｘｌｅｔのエンドポイント識別子と、エクスポートされたオブジェクトの識別子と、インターフェース記述子とを含む。 Ｘｌｅｔの識別子は、エクスポート側Ｘｌｅｔの名前であってよい。 Ｘｌｅｔのエンドポイント識別子は、どの通信プロセスを用いた場合でも、アドレスのポート番号または他の表現であってよい。 ポート番号は、例えば、Ｘｌｅｔの識別子と、エクスポートされたオブジェクトの識別子とによって、エクスポートされたオブジェクトへの呼び出しを転送できるエクスポートＪＶＭインスタンスの位置を特定してよい。 エクスポートされたオブジェクトの識別子は、エクスポートされたオブジェクトのオブジェクト名であってよい。 インターフェース記述子は、例えば、インターフェース名のリストを含み、さらに、各インターフェース名に対して、メソッド名に基づくコードと、メソッドに対するパラメータ型と、メソッドに対する戻り型とのリストを含んでよい。 コードは、例えば、ハッシュコードであってよく、ハッシュコードとは、可変調入力を代表する固定長コードである。 ハッシュコードの代わりに、メソッド名および型の全体を提供してもよい。 別の実施形態では、リモート参照は、インターフェース記述子を含まず、その代わりに、レジストリによって別個に登録されているインターフェース記述子へのアクセスに利用可能なインターフェース識別子を備える。 この情報の提供により、インポート側Ｘｌｅｔが、予期されたインターフェースの詳細を実際のインターフェースと比較して、リモートオブジェクトとの通信の前に一致を保証することが可能になる。 この比較は、本明細書では、「型検査」と呼ぶこととする。 これにより、リモート参照がシリアルで送信されるたびに、全部の型情報を送信する必要がなくなる。

Ｘｌｅｔ Ｂ １７４は、ＯＢＪ＿Ｃ １７８にアクセスしたい場合には、ＯＢＪ＿Ｃのインスタンスを要求するメッセージ１９４をオブジェクトレジストリ１６６に送信する。 レジストリ１６６は、レジストリテーブル１７６にアクセスし、その要求１９６を、結合されたリモート参照と照合する。

Ｘｌｅｔ Ｂ １８４は、リモート参照をインポートすると、スタブオブジェクト１８８を生成するスタブ生成のプロセスに進む。 スタブ生成は、ＪＶＭの一部であるＩＸＣ ＡＰＩによってオンザフライで実行される。 Ｘｌｅｔ Ｂ １８４から見ると、オブジェクトレジストリ１６６からリモートオブジェクトのインスタンスが要求されて、オブジェクトレジストリ１６６によって提供される。 しかしながら、実際には、スタブオブジェクト１８８は、元々のエクスポートされたオブジェクト１７８のシェルに過ぎず、そのオブジェクトへのプロキシとして動作する。 しかし、Ｘｌｅｔ Ｂ １８４が認識している限りは、Ｘｌｅｔ Ｂ １８４は、リモートオブジェクトの完全なインスタンスを有し、そのようにスタブオブジェクト１８８を扱うことができる。 しかしながら、呼び出しを内部で処理する代わりに、スタブオブジェクト１８８は、元々のエクスポートされたオブジェクト１７８への呼び出しを転送して、その結果をリモートのエクスポートされたオブジェクト１７８からＸｌｅｔ Ｂ １８４に渡す。

一実施形態では、インポートされて、インポートされたオブジェクトの各々についてインポートおよびインスタンス生成された各オブジェクト型に対して、動的にスタブクラスを生成して、元々のエクスポートされたオブジェクトを参照する。 したがって、同じ型を有する複数のオブジェクトがインポートされる場合には、そのオブジェクト型に対するスタブクラスが一旦生成されると、その型のオブジェクトがインポートされるたびに、スタブのインスタンスが生成される。 スタブ生成の機構に関するさらなる詳細については、Ｗｉｌｌｉａｍ Ｆ． Ｆｏｏｔｅらに発行された米国特許６，８２９，７７２、Ｐｅｌｅｇｒｉ−Ｌｌｏｐａｒｔらに発行された米国特許５，９９９，９８８、および、Ｗｏｌｌｒａｔｈらに発行された米国特許６，９３８，２６３に開示されている。 一般的に、リモート・インターフェース・クラスは、インポート側にもエクスポート側にもロード可能である。 これは、インターフェース・クラスが、通常のクラスと同様に、「クラスパス上にある」ことを意味する。 インターフェース・クラスがロードされる際に、システムは、そのクラスを「イントロスペクト」して、その詳細（すなわち、メソッド、パラメータのリスト、および、戻り型）を見つけることができる。 次に、そのシステムは、スタブクラスを生成することができる。 この種のイントロスペクトのための機構は、ＪＡＶＡ（登録商標）では「リフレクション」と呼ばれる。 このように、インターフェース名から、インターフェース・クラスをロードして、そこから、スタブクラスでのインターフェースの再生に必要な情報をすべて抽出することができるため、リモート参照は、リモート・インターフェース名を含む。

Ｘｌｅｔ Ｂ １８４は、リモートオブジェクトをインポートすることによって新しいスタブを生成する際に、新しいクラス名をオンザフライで生成し、そのインスタンスを生成して、リモートのエクスポートされたオブジェクトを参照させる。 スタブオブジェクト１８８は、オブジェクト記述子によって定義されたインターフェースを実装する。 当業者にとって明らかなように、スタブ生成は、様々なＲＭＩ実装と同様に、従来のＩＸＣ実装において周知のプロセスである。

ＩＸＣ ＡＰＩは、スタブオブジェクト１８８が、実装固有であってよいデータパス１８０に沿って、エクスポートされたオブジェクト１７８へのメソッド要求を転送することを保証する。 例えば、データパス１８０は、オペレーティングシステム層およびハードウェア層によって提供された低レベルのプロセス間通信（ＩＰＣ）機構であってよい。 リモート参照は、そのリモートオブジェクトのアドレスに類似するエンドポイント１７９を定義する。 このように、オブジェクトレジストリ１６６は、そのエンドポイントによって同様にアクセスされる。 一実施形態では、エンドポイント１７９および１６９が、別々の転送機構（すなわち、別々のＩＰＣ機構）の上に実装可能なクラスに抽象化される。 別の実施形態では、それらのエンドポイントは、例えば、ポート番号を用いて、オペレーティングシステムに密接に結合される。

一実施形態では、Ｘｌｅｔ Ａ １８２からレジストリ１６６に送信されたリモート参照１８２は、エクスポートされたオブジェクトへの接触が可能なように、エクスポートされたオブジェクトに関する十分な情報を含むオブジェクトである。 一実施形態では、リモート参照オブジェクトは、ＪＡＶＡ（登録商標）オブジェクト直列化を用いて、エクスポートＸｌｅｔからレジストリに、レジストリからインポートＸｌｅｔに転送される。 オブジェクト直列化とは、ＪＶＭによって提供される機構であり、アイソレート間またはＪＶＭ間の転送のためにオブジェクトを一連の数（例えば、バイト列）に変換する。 別の実施形態では、オブジェクト記述子オブジェクトは、より低レベルのコマンド構造を利用するカスタムコードされたプロシージャを用いて転送される。 当業者にとって明らかなように、オブジェクトをデータに変換して、そのデータを仮想マシン（ＶＭ）のインスタンス間で送信するための様々な機構が利用可能である。

図７は、Ｘｌｅｔ ＡとＸｌｅｔ Ｂとの間のＩＸＣを開始するためのプロシージャを示すフローチャート２００である。 そのプロシージャは、開始ブロック２０２に示すように始まり、Ｘｌｅｔ Ａが、オブジェクトのリモート参照をオブジェクトレジストリに送信することによって、オブジェクトをエクスポートする動作２０４に進む。 動作２０６では、レジストリが、エクスポートされたオブジェクトのオブジェクト名をリモート参照に結合する。

リモート参照は、別のアイソレートのＸｌｅｔが、エクスポートされたオブジェクトに接触することを可能にするのに十分な情報を有する。 エクスポートされたオブジェクトのオブジェクト名をリモート参照に結合することで、別のアイソレート内のＸｌｅｔが、以下の動作で示すように、アクセスしたいエクスポートされたオブジェクトのオブジェクト名を提供することにより、リモート参照を取得することができるようになる。 別のＸｌｅｔから見ると、エクスポートされたオブジェクトは、リモートオブジェクトである。

動作２０８ないし２１２では、Ｘｌｅｔ Ｂが、リモートオブジェクトを「インポート」する。 動作２０８において、Ｘｌｅｔ Ｂは、Ｘｌｅｔ Ａによってエクスポートされたリモートオブジェクトへのリモート参照に対する要求をレジストリに送信する。 動作２１０において、レジストリは、Ｘｌｅｔ Ｂの要求に応じて、リモート参照を送信する。 動作２１２において、Ｘｌｅｔ Ｂは、リモート参照の型記述子を、予期されたインターフェース型と比較することにより、リモート参照の型検査を行い、それによって、リモートのエクスポートされたオブジェクトの型に関してＸｌｅｔ Ｂが内部に保持する意向が、リモートのエクスポートされたオブジェクトの実際の型と一致することを保証する。 型が一致しない場合には、エラーが生成される。 型が一致する場合、Ｘｌｅｔ Ｂは、リモートオブジェクトの型に対応するスタブオブジェクトを生成する。 前述のように、スタブオブジェクトは、実際のリモートオブジェクトへのプロキシであり、単に、リモートオブジェクトのインターフェースを実装し、呼び出しをリモートオブジェクトに転送して、リモートオブジェクトから結果を戻す。

動作２１４において、Ｘｌｅｔ Ｂは、ローカルスタブオブジェクト内のメソッドを呼び出す。 そのメソッドは、スタブオブジェクトによってリモートオブジェクトに転送される。 すべての結果が、スタブオブジェクトに戻され、次いで、スタブオブジェクトは、それらの結果をＸｌｅｔ Ｂに送り返す。 次いで、プロシージャは、終了ブロック２１６に示すように終了する。

複数のＸｌｅｔが互いに通信することが可能な場合には、様々なセキュリティの問題が生じる。 「背景技術」において上述したように、問題の１つは、サービス妨害（ＤＯＳ）攻撃の可能性である。 システムが、悪質または有害なプログラムによる要求へのサービスに縛られすぎて、他のプログラムからの正当な要求へのサービスが不可能になることがある場合には、そのシステムは、悪質なコードによるＤＯＳ攻撃に対して脆弱である。 これが、システムの過負荷になり、正常な動作を妨げる場合がある。 図６および７を参照して上述したＩＸＣ実装では、悪質なＸｌｅｔが、多くのオブジェクトをエクスポートするための多くの要求を作成し、オブジェクトレジストリを飽和させて、他のＸｌｅｔによるオブジェクトレジストリの利用を妨害するという問題がある。

一実施形態では、かかるＤＯＳ攻撃は、任意の特定のＸｌｅｔからレジストリにおいて利用可能な結合の数を制限することによって防止される。 この方法では、レジストリは、各エクスポートＸｌｅｔに対して、エクスポートされたオブジェクトの数をカウントする。 いずれかのＸｌｅｔが、エクスポートされるオブジェクトの最大許容数に到達すると、以後の要求はすべて拒否される。

図８は、各Ｘｌｅｔに対する結合の数を制限するためのプロシージャの一例を示すフローチャート２２０である。 そのプロシージャは、開始ブロック２２２に示すように始まり、エクスポートされたオブジェクトのオブジェクト名をリモート参照と結合するための要求が受信される動作２２４に進む。 動作２２６において、オブジェクトレジストリは、要求側のＸｌｅｔについての結合オブジェクトのカウント数を、オブジェクトの最大許容結合数と比較する。 動作２２８において、結合されたオブジェクトの数に対するカウンタが、最大許容数未満であるか否かが判定される。 カウンタが最大値未満である場合には、プロシージャは動作２３０に進み、リモート参照およびオブジェクト名がレジストリテーブルに転送されて、カウンタが増分される。 次いで、プロシージャは、終了ブロック２３４に示すように終了する。 しかしながら、動作２２８において、カウンタが最大値以上であると判定された場合には、プロシージャは動作２３２に進み、要求は拒否される。 例えば、エクスポートされたオブジェクトの最大結合数に到達していることを示すエラーメッセージが、要求側のＸｌｅｔに送信される。 次いで、プロシージャは、終了ブロック２３４に示すように終了する。

図８に示したように、悪質なＸｌｅｔが偽の結合要求でオブジェクトレジストリに過負荷を掛けるという問題の起きる可能性は、各Ｘｌｅｔにとって利用可能な結合の数を制限することにより排除される。 例えば、その制限は、Ｘｌｅｔ当たり５０または１００の結合であってよい。 この数は、リソースの制限、および／または、特定の実装に特有の他の要素に応じて変更されてよい。 結合の制限は、各Ｘｌｅｔに対して定数であってもよいし、ある認証機構を備えることで、さらなる結合を必要とする既知の信頼できるＸｌｅｔが、制限を超えることができるようにしてもよい。 また、各Ｘｌｅｔでなく、各アイソレートに対して結合数を制限することも可能である。

エクスポート側Ｘｌｅｔが停止した場合には、エクスポートされたオブジェクトは、他のＸｌｅｔからの要求の処理に対して利用不可能になる。 したがって、レジストリテーブルを更新して、停止したＸｌｅｔに付属するエクスポートされたオブジェクトの喪失を反映することが重要である。 また、すべての対応するスタブオブジェクトを破棄できるように、リモートオブジェクトがもはや利用可能ではないことを、停止したＸｌｅｔからインポートしたオブジェクトを有するＸｌｅｔに対して通知することも有用である。 この動作により、メモリリソースを必要とする他のプロセスに、メモリリソースを再割り当てすることが可能となり、それは、しばしば、「ガーベッジコレクション」と呼ばれる。 Ｘｌｅｔプログラミングモデルでは、個々のＸｌｅｔのライフサイクルは、アプリケーションマネージャによって制御されてよく、アプリケーションマネージャは、システム上の様々なＸｌｅｔの状態を認識している。 Ｘｌｅｔと、それらのＸｌｅｔがインポートしたオブジェクトとのリストを保持することにより、レジストリは、対応するリモートオブジェクトの停止が原因で停止したインポート後のオブジェクトを有するＸｌｅｔに対してアプリケーションマネージャが通知する必要のある情報を、アプリケーションマネージャに提供することができる。

図９は、ガーベッジコレクションのプロシージャの一例を示すフローチャート２４０である。 そのプロシージャは、開始ブロック２４２に示すように始まり、アプリケーションマネージャが、特定のＸｌｅｔの停止に気付く動作２４４に進む。 Ｘｌｅｔは、単に、終了したことによって停止してもよいし、アプリケーションマネージャが、そのＸｌｅｔを強制終了したのであってもよい。 アプリケーションマネージャは、例えば、特定のＸｌｅｔが不正動作（例えば、システムリソースの過度の消費など）をしていると判定した場合に、ユーザの要求に応じてアプリケーションを強制終了することができる。 アプリケーションマネージャは、Ｘｌｅｔが停止したことに気付くと、動作２４６において、Ｘｌｅｔの停止をオブジェクトレジストリに通知するメッセージをオブジェクトレジストリに送信する。 一実施形態では、オブジェクトレジストリは、アプリケーションマネージャにとってローカルなオブジェクトであるため、そのメッセージは、単に、このためにオブジェクトレジストリによって提供されたメソッドを呼び出すことによって受け渡し可能である。

動作２４８において、オブジェクトレジストリは、メッセージに応えて、停止したＸｌｅｔによってエクスポートされたすべてのオブジェクトの結合を削除する。 停止したＸｌｅｔによってエクスポートされたオブジェクトは、本明細書では、停止オブジェクトと呼ぶこととする。 停止オブジェクトへのすべての結合を削除することに加えて、オブジェクトレジストリは、停止オブジェクトのいずれかをインポートしたＸｌｅｔすべてに対してメッセージを送信する。

動作２５０において、インポート側Ｘｌｅｔは、オブジェクトレジストリからのメッセージに応えて、停止オブジェクトに対応するスタブオブジェクトを破棄する。 次いで、プロシージャは、終了ブロック２５２に示すように終了する。 したがって、オブジェクトレジストリは、結合されたオブジェクトの各々について、結合されたオブジェクトをインポートしたＸｌｅｔのリストを保持する。 結合されたオブジェクトが停止すると、オブジェクトレジストリは、結合されたオブジェクトをインポートしたＸｌｅｔすべてに通知して、結合を削除することにより、メモリリソースなどのリソースを他のアプリケーションに対して解放することができる。

上述のように、図６ないし９は、中央オブジェクトレジストリを用いたＩＸＣの実装例の様々な態様を示している。 レジストリへのＤＯＳ攻撃を防ぐために、各Ｘｌｅｔは、オブジェクトレジストリによって、エクスポートされたオブジェクトについての選択された最大結合数に制限されてよい。 別の実施形態では、レジストリは、各アイソレートが、そのアイソレートからエクスポートされたオブジェクトのためのレジストリを保持するように分散される。

図１０は、ＩＸＣのための分散レジストリ３００の実装の一例を示す説明図である。 説明のため、２つのアイソレート、すなわち、アイソレートＡ ３１０とアイソレートＢ ３２０が図示されている。 アイソレートＡ ３１０はＸｌｅｔ Ａ ３１２を有し、アイソレートＢはＸｌｅｔ Ｂ ３２２を有する。 Ｘｌｅｔ Ｂ ３２２がＯＢＪ＿Ｃにアクセスするためには、まず、Ｘｌｅｔ Ａ ３１２が、ＯＢＪ＿Ｃ ３１６をエクスポートする必要がある。 これは、Ｘｌｅｔ Ａ ３１２が、単に、アイソレートＡ ３１０内に位置するエクスポート済みアイソレートレジストリＡ ３１４にＯＢＪ＿Ｃを追加することによって実現される。 各アイソレートは、例えば、アイソレートＢ ３２０が、エクスポート済みアイソレートレジストリＢ ３２４を含むように、エクスポート済みアイソレートレジストリを含む。 エクスポート済みアイソレートレジストリの各々は、そのアイソレート内のＸｌｅｔによってエクスポートされたオブジェクトのリストを含む。 したがって、エクスポート済みアイソレートレジストリＡ ３１４は、オブジェクトと、それらのオブジェクトに対応して結合されたリモート参照とのリストを含む。 Ｘｌｅｔ Ａは、オブジェクトＯＢＪ＿Ｃをエクスポートするために、それ以上のことをする必要はない。 アイソレートＡの外側のＸｌｅｔにとって、ＯＢＪ＿Ｃはリモートオブジェクトである。

Ｘｌｅｔ Ｂ ３２２は、ＯＢＪ＿Ｃをインポートするために、まず、レジストリプロキシ３３２に接触して、リモートオブジェクトＯＢＪ＿Ｃのリモート参照（Ｘｌｅｔ Ｂ ３２２はインスタンスとして認識する）を要求する。 一実施形態では、レジストリプロキシ３３２は、１組の特殊なコマンドを用いて実装される。 別の実施形態では、レジストリプロキシ３３２は、アプリケーションマネージャ３３０によって提供されるリモートオブジェクトであり、Ｘｌｅｔ Ｂを含む他のＸｌｅｙからＩＸＣによって接触される。 したがって、この場合、Ｘｌｅｔ Ｂは、ＯＢＪ＿Ｃをインポートするためにそのリモートオブジェクトに接触する前に、レジストリプロキシオブジェクトをインポートする必要がある。 Ｘｌｅｔが、確実にレジストリプロキシオブジェクトを見つけることができるように、レジストリプロキシへのリモート参照は、ＪＶＭによって提供された定数値である。 いずれの実施形態でも、Ｘｌｅｔ Ｂ ３２４は、ＯＢＪ＿Ｃへのリモート参照を取得することを要求するメッセージをレジストリプロキシ３３２に送信する。 この要求を満たすために、レジストリプロキシ３３２は、アプリケーションマネージャ３３０が保持するアイソレートテーブル３３４内のアイソレートのリストを参照し、各アイソレート内のエクスポート済みアイソレートレジストリ各々をポーリングして、求められている特定のオブジェクトが、そのアイソレート内に存在するか否かを判定する。 一実施形態では、このアイソレートの検索は、一貫した命名方式を用いて最適化されてよい。 例えば、各アイソレートは、エクスポートされたオブジェクトのオブジェクト名に固有のプレフィックスを添付して、求められているリモートオブジェクトと共通のプレフィックスを有するアイソレート内の最初に検索してもよい。

予期しない結果を招く場合があるため、Ｘｌｅｔが、検索中にオブジェクトをエクスポートすることを防ぐために、レジストリは、排他ロックを取得する。 レジストリプロキシがロックを制御する場合には、個々のＸｌｅｔは、エクスポート済みアイソレートレジストリの修正を防止される。 Ｘｌｅｔ Ａは、オブジェクトＯＢＪ＿Ｃをエクスポートすると、まず、排他ロックを取得して、レジストリプロキシが、そのオブジェクトを入手しないことを保証する。 レジストリプロキシ３３２は、ＯＢＪ＿Ｃに結合された検索対象のリモート参照を見つけると、エクスポート済みアイソレートレジストリからその参照を取得し、Ｘｌｅｔ Ｂ ３２２に渡して、Ｘｌｅｔ Ｂとのやり取りを完了し、排他ロックを解除する。 型検査が上述のように一致すると、Ｘｌｅｔ Ｂ ３２２は、リモートオブジェクトＯＢＪ＿Ｃ ３１６にインターフェース３４０を提供してＯＢＪ＿Ｃ ３１６への呼び出しを受け渡すスタブオブジェクト３２６を生成する動作に進む。

図１１は、Ｘｌｅｔ Ａ ３１２とＸｌｅｔ Ｂ ３２２との間のＩＸＣを実装するためのプロシージャの一例を示すフローチャート３５０である。 そのプロシージャは、開始ブロック３５２に示すように始まり、Ｘｌｅｔ Ａが、エクスポート済みアイソレートレジストリ内にＯＢＪ＿Ｃを入れることによりＯＢＪ＿Ｃをエクスポートする動作３５４に進む。 その後、動作３５６において、Ｘｌｅｔ Ｂが、アプリケーションマネージャによって提供されたレジストリプロキシからリモートオブジェクトを要求する。 動作３５８において、レジストリプロキシは、Ｘｌｅｔ Ｂからの要求に応じて、エクスポート済みアイソレートレジストリ内でＯＢＪ＿Ｃを検索する。 レジストリプロキシは、検索中に排他ロックの制御を取得して、エクスポート済みアイソレートレジストリが、検索中に修正されることを防止する。 動作３６０において、アイソレートＡ内のエクスポート済みアイソレートレジストリは、ＯＢＪ＿Ｃに対応するリモート参照で、レジストリプロキシからの要求に応答する。 動作３６２において、レジストリは、リモート参照をＸｌｅｔ Ｂに転送し、Ｘｌｅｔ Ｂは、リモート参照を型検査して、リモートオブジェクトＯＢＪ＿Ｃに対応するスタブオブジェクトを生成する。 動作３６４において、プロシージャは終了する。

分散レジストリモデルは、様々なアイソレートをポーリングするさらな工程を必要とするが、これは、各アイソレートが同じマシン上に存在する環境では許容可能なことである。 これは、レジストリがリモートオブジェクトと同じマシンに位置することができないために分散レジストリの検索が非常に長く掛かるＲＭＩプロトコルと異なる点である。 ＩＸＣモデルは、同じ物理マシン上のＸｌｅｔ間の通信に限定されているため、検索に関する遅延は、最小限であり、特定のＸｌｅｔが有しうるエクスポートされたオブジェクトの数に、いかなる制限もないという利点も提供する。

分散レジストリモデルは、さらに、ガーベッジコレクションを簡略化する可能性がある。 典型的な例では、アイソレートごとに１つのＸｌｅｔのみが存在する。 Ｘｌｅｔが停止すると、アイソレートが終了して、エクスポート済みアイソレートレジストリは、アイソレートと共に消滅する。 したがって、この状況でＸｌｅｔが停止した場合には、レジストリの項目を削除するさらなる動作は必要ない。 アイソレート内に２以上のＸｌｅｔが存在する場合には、Ｘｌｅｔは、正常に停止すると、自身をシャットオフするプロシージャを呼び出す。 そのプロシージャは、シャットダウンされるＸｌｅｔに関連するすべての項目を削除するためのエクスポート済みアイソレートレジストリへの呼び出しを含む。 Ｘｌｅｔが、ロックした場合（例えば、無限ループに入ってリソースを消費し尽くした場合）には、アイソレート内で動作する他のＸｌｅｔを含めて、アイソレート全体がシャットダウンされる。 これは、同様に、エクスポート済みアイソレートレジストリを削除する。

停止したＸｌｅｔまたは停止しかけのＸｌｅｔからオブジェクトをインポートした他のアイソレートのＸｌｅｔへの通知に関しては、２つの方法がある。 第１の方法は、図９を参照して上述した方法と同様の積極的な方法であり、アプリケーションマネージャが、停止したＸｌｅｔまたは停止しかけのＸｌｅｔからオブジェクトをインポートした各Ｘｌｅｔに対して、リモートオブジェクトがもはや存在しないことを通知して、対応するスタブオブジェクトを破棄するよう指示する。 この通知は、すべてのＸｌｅｔへのブロードキャストメッセージであってもよいし、停止したＸｌｅｔまたは停止しかけのＸｌｅｔからオブジェクトをインポートしたＸｌｅｔのみを対象したブロードキャストメッセージであってもよい。 別の実施形態では、現存しないインポートされたオブジェクトのガーベッジコレクションのための反応性の方法と呼んでよい方法で、インポート側のＸｌｅｔは、リモートオブジェクトへの接触を試みるまで、リモートオブジェクトの停止を通知されない。

図１２は、現存しないインポートされたオブジェクトのガーベッジコレクションのための反応性の方法を示すフローチャート３７０である。 そのプロシージャは、開始ブロック３７２に示すように始まり、Ｘｌｅｔ Ｂが、そのローカルスタブオブジェクト内のメソッドを呼び出す動作３７４に進む。 動作３７６において、ローカルスタブオブジェクトは、アイソレートＡ内のリモートオブジェクトへの呼び出しを転送する。 動作３７８に示すように、リモートオブジェクトが存在するか否かによって、次の動作が決まる。 リモートオブジェクトが存在する場合には、プロシージャは、リモートオブジェクトが要求を処理して結果を返す動作３８０に進む。 次いで、動作３８２において、ローカルスタブオブジェクトは、その結果をＸｌｅｔ Ｂに渡す。 次いで、プロシージャは、終了ブロック３８８に示すように終了する。

Ｘｌｅｔのシャットダウンもしくはアイソレートのシャットダウンのために、リモートオブジェクトがもはや存在しない場合には、動作３８４において、スタブオブジェクトは、リモートオブジェクトが見つからないことを示すエラーを受信する。 このエラーは、ＩＸＣ ＡＰＩによって実装された低レベルのＩＰＣ機構によって受け渡されてよい。 あるいは、そのエラーは、タイムアウト・エラーに応答して生成されてもよい。 スタブオブジェクトは、このエラーを受信すると、動作３８６において、そのエラーをＸｌｅｔ Ｂに受け渡して、停止する。 スタブオブジェクトは、自身を終了してもよいし、Ｘｌｅｔがスタブオブジェクトからエラーを受信した時に、Ｘｌｅｔによって終了されてもよい。 次いで、プロシージャは、終了ブロック３８８に示すように終了する。

両方のＸｌｅｔが同じマシン上に存在するため、Ｘｌｅｔ間で信頼性の高い通信が実現される。 したがって、ＩＸＣプロトコルは、アイソレートによって提供された保護ドメインによって促進されたセキュリティを損なうことなく、Ｘｌｅｔ間の通信での必要性を満たす単純でありながら堅固なＩＸＣインフラストラクチャを提供することにより、この信頼性を活用するよう設計される。

上述の実施形態に関して、本発明は、コンピュータシステムに格納されたデータを含む様々なコンピュータによる動作を用いてよいことを理解されたい。 これらの動作は、物理量の物理的な操作を必要とするものである。 これらの量は、必ずとは限らないが、格納、転送、結合、比較、および、その他の操作が可能な電気信号または磁気信号の形態をとるのが通常である。 さらに、実行される操作は、生成、特定、決定、または、比較などの用語で呼ばれることが多い。

本明細書に記載され、本発明の一部を形成する動作は、有用なマシン動作である。 本発明は、また、これらの動作を実行するためのデバイスまたは装置に関する。 この装置は、必要とされる目的に応じて特別に構築されてもよいし、コンピュータに格納されたコンピュータプログラムによって選択的に起動または構成される汎用コンピュータであってもよい。 特に、本明細書の教示に従って書かれたコンピュータプログラムと共に、様々な汎用マシンを使用してもよいし、必要な動作を実行するために、より特殊化された装置を構築する方が好都合な場合もある。

また、本発明は、 有形のコンピュータ読み取り可能な媒体上のコンピュータ読み取り可能なコードとして実施されてもよい。 有形のコンピュータ読み取り可能な媒体は、データを格納して、その後に、コンピュータシステムによって読み出し可能である任意のデータ記憶装置である。 有形のコンピュータ読み取り可能な媒体の例としては、ハードディスク、ネットワーク接続ストレージ（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、および、その他の光学的または非光学的なデータ記憶装置が挙げられる。 有形のコンピュータ読み取り可能な媒体は、コンピュータ読み取り可能なコードを分散的に格納および実行できるように、ネットワークに接続されたコンピュータシステム上に分散されてもよい。

以上では、理解を促す目的で本発明を詳細に説明したが、添付した特許請求の範囲の範囲内で、変更および変形が可能であることは明らかである。 したがって、上述した実施形態は、例示を目的としたものであって限定的ではなく、本発明は、本明細書に記載の詳細事項に限定されず、添付した特許請求の範囲および等価物の範囲内で変形されてよい。

リモートメソッド呼び出しのための従来の構成の一例を示す図である。

Ｘｌｅｔ間通信（ＩＸＣ）のための従来の構成の一例を示す図である。

アイソレート間のＩＸＣのための構成の一例を示す図である。

本発明を実施できるデバイスの一例を示す図である。

デバイス上でＸｌｅｔを実行するためのハードウェアおよびソフトウェアの層の一例を示す図である。

アイソレート間のＩＸＣの実装の一例を示す説明図である。

ＩＸＣを実装するプロシージャの一例を示すフローチャートである。

各Ｘｌｅｔに対する結合の数を制限するためのプロシージャの一例を示すフローチャートである。

ガーベッジコレクションのプロシージャの一例を示すフローチャートである。

ＩＸＣのための分散レジストリの実装の一例を示す説明図である。

２つのＸｌｅｔの間のＩＸＣを分散レジストリによって実装するためのプロシージャの一例を示すフローチャートである。

現存しないインポートされたオブジェクトのガーベッジコレクションのための反応性の方法を示すフローチャートである。