JPH0926879A

JPH0926879A - 要求伝達方法及びそのネットワーク

Info

Publication number: JPH0926879A
Application number: JP7288874A
Authority: JP
Inventors: Richard Camagnoni Frank; フランク・リチャード・キャムパノーニ; Harden Coner Michael; マイケル・ハーデン・コナー; Vishwanas Heudri Lagu; ラグー・ヴィシュワナス・ヒュードリ; Gregori Smith Mark; マーク・グレゴリー・スミス
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1994-11-21
Filing date: 1995-11-07
Publication date: 1997-01-28
Anticipated expiration: 2015-11-07
Also published as: US6182154B1; JP3072709B2

Abstract

(57)【要約】【課題】異なるオブジェクト・リクエスト・ブローカに
書込まれたターゲット・オブジェクトに、要求者からの
要求を渡す。【解決手段】最初に、要求が呼出しオブジェクトから、
呼出しオブジェクトが書込まれる、通常は呼出しオブジ
ェクトのために遠隔オブジェクトに対する要求を処理す
る、オブジェクト・リクエスト・ブローカに渡される。
ターゲット・オブジェクトがオブジェクト・リクエスト
・ブローカにとって外部であるという判別に応答して、
ターゲット・オブジェクトが書込まれる外部オブジェク
ト・リクエスト・ブローカが探し出される。このブロー
カのプロトコルに従ってプロキシー・オブジェクトが生
成され、第１のアドレス空間に格納される。呼出しオブ
ジェクトにポインタが戻され、これにより呼出しオブジ
ェクトからターゲット・オブジェクトへの通信が、プロ
キシー・オブジェクトを介して設定できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、概してデータ処理
システムに関する。更に詳細に説明すれば、異なるアド
レス空間内のオブジェクト間の通信に関する。

【０００２】

【従来の技術】オブジェクト指向プログラミング（ＯＯ
Ｐ）は、オブジェクトと呼ばれるソフトウェア・モジュ
ールのより効率的な再利用とカストマイズを可能にする
ことにより、ソフトウェアの開発を促進する前途有望な
新しい技術として大いに推奨されてきた。オブジェクト
とは、データとメソッドの両方をカプセル化したソフト
ウェアの単位であり、ソフトウェアの保守と拡張を共に
容易にする構成である。その期待される将来性にも関わ
らず、オブジェクト指向テクノロジーは、主要な商用ソ
フトウェア製品での利用がやっと始まったばかりであ
る。

【０００３】ソフトウェア開発者は、ＯＯＰの使用にお
いていくつかの障害に直面している。その第１は、オブ
ジェクトの定義とそれらの動作に関してそれぞれ異なっ
た非互換のモデルを包含する、オブジェクト指向言語と
ツールキットの数の多さである。例えば、Ｓｍａｌｌｔ
ａｌｋなどの「純粋な」オブジェクト指向言語は、与え
られた実行時環境にある限り円滑に操作する。しかし、
外部環境と対話する場合、オブジェクトはオブジェクト
の提供するカプセル化と再利用の利点を維持しないデー
タ構造に格下げされる。Ｃ＋＋などのハイブリッド言語
は、実行時サポートをそれほど要求しないが、オブジェ
クトとそのクライアント間の緊密なバインドが必要であ
り、これは、オブジェクトに対して比較的小規模な変更
が行われたときでも、クライアント・プログラムを再コ
ンパイルする必要があることを意味する。要約すると、
１つの言語で開発されたオブジェクトは、別の言語では
ほとんど使用できない。

【０００４】システム・オブジェクト・モデル（ＳＯ
Ｍ）は、各種のオブジェクト指向方法の統合を意図して
設計されたオブジェクト指向テクノロジーである。ＳＯ
Ｍでは、オブジェクトのクラスのインターフェース、そ
れらがサポートするメソッド、戻りタイプ等がインター
フェース定義言語で指定される。オブジェクト・クラス
の実際の実施は、開発者が好む任意の言語、つまりＣな
どの手続き型言語でも書くことができる。したがって、
ＯＯＰの長所が非オブジェクト指向プログラミング言語
のプログラマにも拡張できる。ＳＯＭについての詳細
は、米国にて一緒に出願中であり一緒に番号を割当てら
れた出願、１９９２年５月４日、Ｍ．Ｃｏｎｎｅｒ、外
に対してファイルされた、通し番号０７／８０５，６６
８「ＬａｎｇｕａｇｅＮｅｕｔｒａｌＯｂｊｅｃｔ
ｓ」で説明されている。その内容は本文にも参考として
取入れられている。

【０００５】特定の標準アーキテクチャへの準拠を促す
各種の標準機関が存在する。これらの標準の１つが、オ
ブジェクト管理グループ（ＯＭＧ）及びＸ／Ｏｐｅｎが
公表した、共通オブジェクト・リクエスト・ブローカ・
アーキテクチャ（ＣＯＲＢＡ）である。このアーキテク
チャで説明されるオブジェクト・リクエスト・ブローカ
（ＯＲＢ）は、ＵＮＩＸ環境で作業する当事者には周知
の遠隔プロシージャ呼出し（ＲＰＣ）と類似している。
ＲＰＣと同様に、ＯＲＢは１つのアドレス空間で作業す
るプロセスが別のアドレス空間の他のプロセスと通信す
ることを可能にするメカニズムである。ＯＲＢは１つの
アドレス空間のオブジェクトからの呼出しを代行受信
し、これをネットワーク・プロトコルにカプセル化し、
別のアドレス空間にあるターゲット・オブジェクトのた
めにこの呼出しをデコードし、結果を呼出しオブジェク
トに戻す。オブジェクト・リクエスト・ブローカは、オ
ブジェクト指向プログラミングが提供する柔軟性と機能
のレベルを更に高めるように設計され、ＲＰＣをより進
歩させたものである。

【０００６】ＣＯＲＢＡはＯＲＢインターフェースを指
定するが、残念ながらＯＲＢがどのように機能するかに
ついてはほとんど指定しないので、ＣＯＲＢＡに準拠す
るＯＲＢを書くことは可能だが、これらのＯＲＢはお互
いに通信することができない。実際、これは例外と言う
よりむしろ通則である。出願者が知るところの５、６個
のＯＲＢ実施でも、他のＯＲＢに属するオブジェクトを
扱えるものは１つもない。そればかりか、どれ１つとし
て互いに通信できるＯＲＢはない。

【０００７】この発明は、理論的には数に制限のない、
任意に実施したオブジェクト・リクエスト・ブローカ同
士が互いに接続するためのメカニズムを提供するもので
ある。

【０００８】

【発明が解決しようとする課題】したがって、この発明
の目的は、異なるオブジェクト・リクエスト・ブローカ
に書込まれたターゲット・オブジェクトに、要求者から
の要求を伝達することにある。この発明の他の目的は、
ゲートウェイ・メカニズムに関連するオーバーヘッドを
最小化することにある。この発明の他の目的は、既存の
オブジェクト・リクエスト・ブローカ実施に対する変更
を必要最小限に抑えることにある。この発明の他の目的
は、要求者に対するゲートウェイ・メカニズムの透過性
を保持することにある。

【０００９】

【課題を解決するための手段】上記及びその他の目的
は、第１のアドレス空間の呼出しオブジェクトからの要
求を、別の０ＲＢに書込まれた第２のアドレス空間のタ
ーゲット・オブジェクトへ伝達するメカニズムにより達
成される。最初に、要求が呼出しオブジェクトから、呼
出しオブジェクトが書込まれる、オブジェクト・リクエ
スト・ブローカに伝達される。オブジェクト・リクエス
ト・ブローカは、通常は呼出しオブジェクトのために遠
隔オブジェクトに対する要求を処理する。ターゲット・
オブジェクトが、オブジェクト・リクエスト・ブローカ
にとって外部であるという判別に応答して、ターゲット
・オブジェクトが書込まれる外部のオブジェクト・リク
エスト・ブローカが探し出される。外部オブジェクト・
リクエスト・ブローカのプロトコルに従ってプロキシー
・オブジェクトが生成され、第１のアドレス空間に格納
される。呼出しオブジェクトにポインタが戻され、これ
により呼出しオブジェクトからターゲット・オブジェク
トへの通信がプロキシー・オブジェクトを介して設定で
きる。外部オブジェクト・リクエスト・ブローカを判別
するための推奨メカニズムは、個々の外部ＯＲＢ用のプ
ロキシー・オブジェクトを作成する、各プロキシー・マ
ネージャが複数登録される、プロキシー・マネージャ・
オブジェクトのマネージャである。プロキシー・マネー
ジャのマネージャは、ターゲット・オブジェクトを認識
するプロキシー・マネージャが見つかるまで、ターゲッ
ト・オブジェクト識別子を各プロキシー・マネージャに
繰返し渡す。認識したプロキシー・マネージャは、プロ
キシー・オブジェクトを作成する。推奨する具現化の１
つでは、プロキシー・マネージャのマネージャ及びそれ
に関連するプロキシー・マネージャをゲートウェイ・マ
シン上に配置し、ネットワーク全体にメカニズムを複製
するのではなく、単一の強力なサーバーにプロセスのオ
ーバーヘッドを限定する。

【００１０】

【発明の実施の形態】発明は、多数の異なるオペレーテ
ィング・システムの下で、各種のコンピュータまたはコ
ンピュータの集合体において実行される。コンピュータ
は、例えば、パーソナル・コンピュータ、ミニ・コンピ
ュータ、メインフレーム・コンピュータ、叉は他のコン
ピュータの分散ネットワークで稼働しているコンピュー
タとすることができる。特定のコンピュータの選択は、
ディスク及びディスク装置要件によってのみ制限される
が、ＩＢＭＰＳ／２（ＴＭ）コンピュータ・シリーズ
のコンピュータはこの発明で使用できる。ＩＢＭのＰＳ
／２シリーズのコンピュータの詳細については、Ｔｅｃ
ｈｎｉｃａｌＲｅｆｅｒｅｎｃｅＭａｎｕａｌＰ
ｅｒｓｏｎａｌＳｙｓｔｅｍｓ／２Ｍｏｄｅｌ５
０、６０ＳｙｓｔｅｍＩＢＭＣｏｒｐｏｒａｔｉ
ｏｎ、部品番号６８Ｘ２２２４、資料番号Ｓ６８Ｘ−２
２２４、及びＴｅｃｈｎｉｃａｌＲｅｆｅｒｅｎｃｅ
ＭａｎｕａｌＰｅｒｓｏｎａｌＳｙｓｔｅｍｓ／
２（Ｍｏｄｅｌ８０）ＩＢＭＣｏｒｐｏｒａｔｉｏ
ｎ、部品番号６８Ｘ２２５６、資料番号Ｓ６８Ｘ−２２
５４を参照されたい。ＩＢＭＰＳ／２パーソナル・コ
ンピュータが実行できるオペレーティング・システムの
１つは、ＩＢＭのＯＳ／２２．０（ＴＭ）であり、Ｉ
ＢＭＯＳ／２２．０オペレーティング・システムの
詳細については、ＯＳ／２２．０Ｔｅｃｈｎｉｃａ
ｌＬｉｂｒａｒｙ、ＰｒｏｇｒａｍｍｉｎｇＧｕｉｄ
ｅＶｏｌ．１、２、３バージョン２．００、資料番号
１０Ｇ６２６１、１０Ｇ６４９５、１０Ｇ６４９４を参
照されたい。

【００１１】上記に代わるものとして、コンピュータ・
システムはＡＩＸ（ＴＭ）オペレーティング・システム
上で稼働するＩＢＭＲＩＳＣＳｙｓｔｅｍ／６００
０（ＴＭ）ラインの中のコンピュータが使用できる。Ｒ
ＩＳＣＳｙｓｔｅｍ／６０００の各種のモデルについ
ては、例えばＲＩＳＣＳｙｓｔｅｍ／６０００、７０
７３ａｎｄ７０１６ＰＯＷＥＲｓｔａｔｉｏｎ
ａｎｄＰＯＷＥＲｓｅｒｖｅｒＨａｒｄｗａｒｅ
Ｔｅｃｈｎｉｃａｌｒｅｆｅｒｅｎｃｅ、資料番号Ｓ
Ａ２３−２６４４−００等のＩＢＭＣｏｒｐｏｒａｔ
ｉｏｎの多数の出版物で説明されている。ＡＩＸオペレ
ーティング・システムについては、ＧｅｎｅｒａｌＣ
ｏｎｃｅｐｔｓａｎｄＰｒｏｃｅｄｕｒｅ−−ＡＩ
ＸＶｅｒｓｉｏｎ３ｆｏｒＲＩＳＣＳｙｓｔ
ｅｍ／６０００、資料番号ＳＣ２３−２２０２−００、
及びＩＢＭＣｏｒｐｏｒａｔｉｏｎの他の出版物で説
明されている。

【００１２】図１に、システム装置１１、キーボード１
２、マウス１３、及びディスプレイ１４で構成されるコ
ンピュータ１０のブロック・ダイヤグラムを示す。シス
テム装置１１には、各種の構成要素が結合し、各種の構
成要素間の通信を実現する単一のシステム・バス叉は複
数のシステム・バス２１が含まれる。マイクロプロセッ
サ２２がシステム・バス２１と接続され、やはりシステ
ム・バス２１に接続された読取り専用メモリ（ＲＯＭ）
２３、及びランダム・アクセス・メモリ（ＲＡＭ）２４
にサポートされる。ＩＢＭＰＳ／２コンピュータ・シ
リーズのマイクロプロセッサは、３８６叉は４８６マイ
クロプロセッサを含むＩｎｔｅｌマイクロプロセッサ・
ファミリの１つである。但し、６８０００、６８０２
０、叉は６８０３０マイクロプロセッサ等のＭｏｔｏｒ
ｏｌａのマイクロプロセッサ・ファミリ、及びＩＢＭが
製造するＰｏｗｅｒＰＣチップ等の各種の縮小命令セッ
ト・コンピュータ（ＲＩＳＣ）マイクロプロセッサ、叉
は他にもＨｅｗｌｅｔｔＰａｃｋａｒｄ、Ｓｕｎ、Ｍ
ｏｔｏｒｏｌａ、及びこれらに限定せず他のものを含め
て、他のマイクロプロセッサが特定のコンピュータで使
用される場合がある。

【００１３】ＲＯＭ２３には、他のコードと一緒に対話
及びディスク装置及びキーボード等の基本的ハードウェ
ア操作を制御する、基本入出力システム（ＢＩＯＳ）が
含まれる。ＲＡＭ２４は、オペレーティング・システム
及びアプリケーション・プログラムがロードされるメイ
ン・メモリである。メモリ管理チップ２５は、システム
・バス２１に接続され、ＲＡＭ２４と、ハード・ディス
ク装置２６及びフロッピー・ディスク装置２７との間の
データの受渡しを含む、直接メモリ・アクセス操作を制
御する。同じようにシステム・バス２１と結合するＣＤ
ＲＯＭ３２は、大量のデータ、例えばマルチメディア
・プログラム叉はプレゼンテーション等を格納するため
に使用される。

【００１４】同様にこのシステム・バス２１と接続され
るものに、各種の入出力制御装置がある。これには、キ
ーボード制御装置２８、マウス制御装置２９、ビデオ制
御装置３０、及び音声制御装置３１がある。当然なが
ら、キーボード制御装置２８はキーボード１２のハード
ウェア・インターフェースを提供し、マウス制御装置２
９はマウス１３のハードウェア・インターフェースを、
ビデオ制御装置３０はディスプレイ１４のハードウェア
・インターフェースを、また音声制御装置３１はスピー
カー１５ａ及び１５ｂのハードウェア・インターフェー
スをそれぞれ提供する。トークン・リング・アダプタな
どの入出力制御装置４０は、ネットワーク４６を介して
他の同じような構成のデータ処理システムとの通信を可
能にする。

【００１５】発明の推奨される実施の１つは、一般的に
前述の説明のように構成された、１つ以上のコンピュー
タ・システムのランダム・アクセス・メモリ２４の中に
常駐する、命令４８〜５２のセットとして実施される。
コンピュータ・システムが要求するまでは、命令のセッ
トは別のコンピュータ・メモリ、例えばハード・ディス
ク装置２６の中、叉はＣＤ−ＲＯＭ３２で使用するため
の光ディスクなどの取外し可能メモリの中、またはフロ
ッピー・ディスク装置２７で使用するためのフロッピー
・ディスクの中に格納されている場合がある。ＯＲＢに
より一緒に結合されるメモリ・アドレス空間は、ネット
ワーク４６を介して通信する別のシステムに常駐させる
か、叉は図１に示したような単一コンピュータ・システ
ムのメモリ中の２つ以上のアドレス空間５３、５４にす
ることができる。

【００１６】ＯＭＧが公表した共通オブジェクト・リク
エスト・ブローカ・アーキテクチャ（ＣＯＲＢＡ）は、
定義されたオブジェクト指向インターフェースにより、
サービスの要求者、例えばクライアントをサービスの提
供者から分離することを目的とするオブジェクト・モデ
ルである。オブジェクト・リクエスト・ブローカ（ＯＲ
Ｂ）をＣＯＲＢＡ規定で実施することにより、開発者は
同様にＣＯＲＢＡ規定で書かれている多種類のオブジェ
クト・システムを統合することができる。個々のオブジ
ェクト・リクエスト・ブローカの構造の詳細について
は、オブジェクト管理グループ及びＸ／Ｏｐｅｎ（１９
９２）が発行した「ＴｈｅＣｏｍｍｏｎＯｂｊｅｃｔ
ＲｅｑｕｅｓｔＢｒｏｋｅｒ：Ａｒｃｈｉｔｅｃｔ
ｕｒｅａｎｄＳｐｅｃｉｆｉｃａｔｉｏｎ」の第３章
に説明がある。その内容は参考として本文に取入れられ
ている。ＣＯＲＢＡインターフェースは、ＯＲＢのすべ
てのオブジェクトで同じである操作、オブジェクトの特
定のタイプに固有の操作、及びオブジェクト実施の特定
のスタイルに固有の操作に分類される。これらのインタ
ーフェースには、動的呼出しインターフェース、ＩＤＬ
スタブ・インターフェース、ＯＲＢインターフェース、
ＩＤＬスケルトン・インターフェース、及びオブジェク
ト・アダプタ・インターフェースを含む。ＯＲＢは、ク
ライアント叉はサーバー・ベース、システム・ベース、
又はライブラリ・ベースにすることができる。ＯＲＢコ
アはＯＲＢの一部であり、クライアント・オブジェクト
からの要求をターゲット・オブジェクトに実際に転送す
る。クライアントとは、実行されるサービスを要求する
実体（Ｅｎｔｉｔｙ）である。ターゲット・オブジェク
トとは、サーバー・プロセスであることが多いが、要求
されたサービスを実行する実体である。

【００１７】ＣＯＲＢＡアーキテクチャの中心は、オブ
ジェクト・リクエスト・ブローカ（ＯＲＢ）である。Ｏ
ＲＢは、クライアントの要求を満足できるターゲット・
オブジェクトを検出し、ターゲット・オブジェクトに要
求を受取る準備をさせ、要求を満たすものを戻させる責
任がある。一般的に、クライアントは要求を発行するこ
とによりサービスを要求する。普通要求には、要求の中
の他のパラメータの値とともにオブジェクト参照が含ま
れ、これでサービスが要求されている特定のターゲット
・オブジェクトを指示する。ターゲット・オブジェクト
には、実際にサービスを実施するコード及びデータが含
まれる。ＯＲＢメカニズムは、他のオブジェクトとの間
で要求を出し、応答をやり取りするオブジェクトに影響
を与えない。異種分散環境の中の異なるアプリケーショ
ン及び異なるマシンは、理論的には複数のオブジェクト
・システム間で継ぎ目なしに相互接続できる。

【００１８】前述のように、ＯＲＢは特定の方法で実施
することを要求されるのではなく、むしろ「ＣＯＲＢＡ
準拠」であることが要求され、ＣＯＲＢＡアーキテクチ
ャの定義済みのインターフェースだけに適合しなければ
ならない。異なるＯＲＢ実施ではその選択が全く異な
り、このため本発明で解決すべき非互換性問題が発生す
る。

【００１９】分散ＳＯＭ（ＤＳＯＭ）は、システム・オ
ブジェクト・モデル（ＳＯＭ）の拡張機能であり、本発
明を実施する推奨手段である。ＤＳＯＭは、一緒に出願
中であり、一緒に番号を割当てられた出願、１９９３年
６月１４日提出の通し番号０８／０７７，２１９、題目
「ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｆｏｒ
ＵｔｉｌｉｚｉｎｇＰｒｏｘｙＯｂｊｅｃｔｓ
ｔｏＣｏｍｍｕｎｉｃａｔｅｗｉｔｈＴａｒｇｅ
ｔＯｂｊｅｃｔｓ」に発表されている。その内容は本
文に参考として取入れられている。ＳＯＭ及びＤＳＯＭ
は、ＩＢＭＣｏｒｐｏｒａｔｉｏｎの出版物、「ＳＯ
ＭＯｂｊｅｃｔｓＤｅｖｅｌｏｐｅｒＴｏｏｌｋｉ
ｔ」、５９６Ｆ−８６４９−００でも説明されている。
ＳＯＭは、要求者プロセス叉はオブジェクトと同じアド
レス空間内に位置付けされたオブジェクトだけを利用す
る、要求者プロセス叉はオブジェクトを対象とする単一
アドレス空間オブジェクト・モデルである。ＤＳＯＭ
ＯＲＢ実施により、１つのアドレス空間内の要求者プロ
セス叉はオブジェクトは、他のアドレス空間に常駐する
ターゲット・オブジェクトの呼出しが可能になる。以降
の説明の大部分で「クライアント・オブジェクト」につ
いて述べているが、ＤＳＯＭを利用するため要求者が必
ずしもクライアント叉はオブジェクトである必要はな
い。例えば、別のサーバーにサービスの実行を要求する
サーバー・プロセスの場合もある。クライアント・オブ
ジェクトは、クライアント・オブジェクトと同じアドレ
ス空間に位置付けされた、ターゲット・オブジェクトを
アクセスする場合と同じ呼出しフォーマットを使用し
て、遠隔ターゲット・オブジェクトをアクセスする。Ｄ
ＳＯＭＯＲＢはクライアント・プロセス叉はオブジェ
クトからの呼出しをターゲット・オブジェクトに伝送
し、ターゲット・オブジェクトからの結果をクライアン
ト・オブジェクトに戻す。組込まれた実施例で示すよう
に、クライアント・オブジェクトがＯＲＢをアクセスす
る手段は、普通はローカル・アドレス空間に作成される
サロゲート（Ｓｕｒｒｏｇａｔｅ）、即ちプロキシー・
オブジェクトである。プロキシー・オブジェクトは、タ
ーゲット・オブジェクトよりずっと小さいことが多い。
これは、ターゲット・オブジェクトに対する要求者から
の呼出しを代行受信し、その呼出しをネットワーク・プ
ロトコルに再パッケージし、ネットワークを介してター
ゲット・オブジェクトとの間で呼出しの送信や検索を行
うことにより、ターゲット・オブジェクトと通信するメ
カニズムを提供する。

【００２０】ＯＲＢは、同じメモリ叉はマシン内のロー
カル・アドレス空間をブリッジするか、叉は分散環境内
で別のマシンの遠隔アドレス空間をブリッジすることが
できる。例えば、ＯＲＢ１がマシンＡ及びマシンＢのア
ドレス空間をブリッジできる。このように、同じオブジ
ェクト参照と通信メカニズムを使用する両方のマシン上
にオブジェクトがあり、ＯＲＢ１に従って実施されるオ
ブジェクト叉はクライアントのために、オブジェクト参
照をマシンＡからマシンＢへ自由に渡すことができる。
ＯＲＢ２もマシンＡ上で実施され、同じマシン内のアド
レス空間をブリッジするが、例えばマシンＢには実施さ
れないとする。本発明は、マシンＡのＯＲＢ２上で実施
されたクライアント・オブジェクトが、マシンＡまたは
ＢのＯＲＢ１上で実施されたオブジェクトと通信するた
めのメカニズムを提供する。

【００２１】本発明を使用して、ＯＲＢは第１のＯＲＢ
に従って実施された第１のアドレス空間内の１オブジェ
クトからの呼出しを、第２のＯＲＢに従って実施された
第２のアドレス空間内のターゲット・オブジェクトへ渡
すことができる。図２に示すように、本発明は、任意の
方法で実施れた、理論的には数に制限のないＯＲＢの相
互接続のための単一の統合フレームワークを提供する。
多数のＯＲＢが、特に大規模な分散システムで存在する
と考えられるが、図を簡単にするために、単一のアドレ
ス空間内に２つのＯＲＢ、１０１と１０３だけを表示す
る。これらのＯＲＢは、同じ叉は異なるマシン上に存在
する別のアドレス空間１０２、１０４と接続する。異な
るＯＲＢが同じアドレス空間に接続する場合もある。１
つのＯＲＢ１０１内で、複数のプロキシー・マネージャ
・オブジェクト１０５、１０７がＯＲＢの一部であり、
遠隔オブジェクト１１１のために、ローカル・プロキシ
ー・オブジェクト１０９を、個々プロキシー・マネージ
ャが関連するＯＲＢ内に生成する責任を負う。プロキシ
ー・マネージャ・オブジェクトのマネージャ１１５が、
プロキシー・マネージャ・オブジェクトを管理する。こ
こでも、図を単純にするために、プロキシー・マネージ
ャ・オブジェクトの１セットと、１つのプロキシー・オ
ブジェクト、及びターゲット・オブジェクトだけが表示
されている。図で示した具現化では、ＯＲＢ１０１に書
込まれたオブジェクトは、外部ＯＲＢに書込まれたオブ
ジェクトと通信する。これに代わる具現化では、他のＯ
ＲＢに書込まれたオブジェクトがこれらのＯＲＢにとっ
て外部であるオブジェクトと通信し、プロキシー・マネ
ージャのマネージャと複数のプロキシー・マネージャ・
オブジェクトの補足的セットが存在する。各ＯＲＢは、
そのＯＲＢが外部ＯＲＢに書込まれたオブジェクトとの
相互運用性を有する場合はセットを有する。そのセット
は、１つのプロキシー・マネージャ・オブジェクトを有
し、これは自身が通信したい各外部ＯＲＢに対応する。

【００２２】ＯＲＢは、そのプロキシー・マネージャが
作成したプロキシー・オブジェクト上にクライアント・
オブジェクトからのメソッド呼出しを受取り、そのＯＲ
Ｂに適した構文でクライアントの要求を再ディスパッチ
する。クライアントが出したメソッド呼出しは、ターゲ
ット・オブジェクトがネイティブＯＲＢに書かれたロー
カルであるか、叉は外部ＯＲＢに書かれた遠隔であるか
に関わらず、本質的には同じフォーマットである。した
がって、クライアントに対する透過性は本発明で保持さ
れる。プロキシーを作成することにより、クライアント
は自分がローカル・オブジェクトを呼出していると考え
る。ＯＲＢは要求を遠隔ターゲットに伝達するために必
要なすべてのメカニズムを処理する。推奨する具現化で
は、ＩＢＭＣｏｒｐｏｒａｔｉｏｎの分散システム・
オブジェクト・モデル（ＤＳＯＭ）が、ＯＲＢ間の相互
運用性を提供する。ＤＳＯＭは、一様なオブジェクト表
示を用いて、外部ＯＲＢを介してメッセージを送信する
ために必要な機能性をカプセル化する。プロキシー・オ
ブジェクトは、他のＯＲＢへの入口を提供するＯＲＢの
部分である。

【００２３】ＯＲＢ内の遠隔オブジェクトへの要求の処
理は、外部オブジェクトが検出されるまでは通常通り進
む。即ち、通常通りとはネイティブ・オブジェクトの場
合だが、遠隔オブジェクトについては、ネットワークを
介してターゲット・オブジェクトとの通信を処理するた
めにプロキシー・オブジェクトが作成される。各オブジ
ェクトはそのオブジェクトに固有な識別子と関連付けら
れている。ＯＲＢは、ターゲット・オブジェクトに対す
る呼出しの経路指定をするために、ターゲット・オブジ
ェクトの識別子を要求する。ある時点で、ＯＲＢはその
ドメイン内で始まったとは認識できないオブジェクト識
別子を受取る。外部オブジェクト参照を解決するため
に、ＯＲＢはプロキシー・マネージャ・オブジェクトの
マネージャ１１５を呼び出す。プロキシー・マネージャ
のマネージャ１１５は、他のＯＲＢのために使用可能な
プロキシー・マネージャ・オブジェクト１０５〜１０７
をポールし、オブジェクト参照を認識するものを検出す
る。適切なプロキシー・マネージャ１０７が検出される
と、外部ＯＲＢに関連付けられたプロキシー・マネージ
ャ１０７が、ターゲット・オブジェクト１１１用のプロ
キシー・オブジェクト１０９を作成し、ポインタ１１７
をプロキシー・マネージャのマネージャ１１５に戻す。
プロキシー・マネージャのマネージャ１１５はポインタ
１１７のコピーを呼出しルーチン１１９に戻す。次に呼
出しルーチン１１９は、オブジェクト・ポインタを適当
なオブジェクト参照アブストラクションと共に折返す。
プロキシー・マネージャは、エンティティが他のデータ
構造、ＡＰＩ、オブジェクト等の中で使用すべき表示に
従ってポインタをカプセル化する。プロキシー・オブジ
ェクト１０９上でメソッドが呼出されるときは常に、そ
のプロキシー・オブジェクト１０９に対応するＯＲＢが
これを受信し、適切な方法で処理する。「適切な方法」
とは、特定のＯＲＢ実施に準拠する方法、例えば、特定
のＯＲＢ実施が要求を処理する方法を意味する。

【００２４】遠隔オブジェクトとの通信に当たって要求
を処理するプロセスを、図３の流れ図に示す。ステップ
２００で遠隔オブジェクトの呼出しが、オブジェクト識
別子を含めてＯＲＢ実行時１０１で受信される。ステッ
プ２０１のテストは、オブジェクト識別子がネイティブ
ＯＲＢで認識されるかどうかを判別する。認識される場
合は、ローカル・プロキシー・マネージャがプロキシー
・オブジェクトを作成するステップ２０３に進む。この
プロセスの詳細は、図４を参照して説明する。

【００２５】ローカルＯＲＢがオブジェクト識別子を認
識しない場合、オブジェクトは別のＯＲＢに属する外部
オブジェクトである。ステップ２０５で、オブジェクト
識別子はプロキシー・マネージャのマネージャに渡され
る。プロキシー・マネージャのマネージャは、インスト
ールされたプロキシー・マネージャをステップ２０７で
繰返し照会し、ステップ２０９でオブジェクト識別子の
認識を行い、プロキシー・マネージャがオブジェクト識
別子を認識するか、叉はステップ２１１ですべてのプロ
キシー・マネージャがポールされるまで、これを繰返
す。オブジェクト識別子を認識したプロキシー・マネー
ジャはステップ２１３でプロキシー・オブジェクトを作
成し、プロキシー・マネージャのマネージャにポインタ
を戻す。インストールされたプロキシー・マネージャが
どれもオブジェクトを認識しない場合、これが未知のオ
ブジェクトであることを示すメッセージがステップ２１
５で戻る。プロセスがステップ２１７で終了する。

【００２６】プロキシー・マネージャによるプロキシー
・オブジェクトの作成プロセスを、図４に示す。ステッ
プ２５１で、ｘｘｘＣｌｉｅｎｔＰｒｏｘｙ、及びアブ
ストラクト・ターゲット・オブジェクトを親オブジェク
トとして持つ、クラス・オブジェクトが作成される。
「ｘｘｘ」文字は、ターゲット・オブジェクトのネイテ
ィブＯＲＢにより異なり、例えばＤＳＯＭＣｌｉｅｎｔ
Ｐｒｏｘｙ、ＤＯＭＦＣｌｉｅｎｔＰｒｏｘｙのように
なり、またそのプロキシーがどのＯＲＢのために作成さ
れるかを識別できることを示す。用語「アブストラクト
・ターゲット・オブジェクト」は、実際のターゲット・
オブジェクトへのインターフェースが入るターゲット・
オブジェクトの空の「シェル」を示すために使用され
る。ＳＯＭを使用するプロキシー・オブジェクトの導出
については、次に図６を参照して詳しく説明する。ステ
ップ２５３では、この新しく作成されるプロキシー・ク
ラス・オブジェクトのインスタンスであるプロキシー・
オブジェクトが作成される。ステップ２５５では、この
インスタンスのメソッド・テーブルがオーバーライドさ
れ、ターゲット・オブジェクトのメソッドに対するメソ
ッド・ポインタが、再ディスパッチ・スタブに置換わ
る。このステップについては、後で図７および８を参照
して詳しく説明する。最後にステップ２５７で、インス
タンスのポインタが呼出しプロセスに戻される。

【００２７】プロキシー・マネージャのマネージャを初
期化するプロセスを図５に示す。プロキシー・マネージ
ャのマネージャの役割は、ローカルＯＲＢにプロキシー
・マネージャを登録し、登録されたプロキシー・マネー
ジャを外部オブジェクト参照の認識のためにポールする
ことである。ステップ３００で、ＯＲＢはその初期化の
一部としてプロキシー・マネージャ・オブジェクトのマ
ネージャを検索する。ＡＰＩ呼出しが実行する初期化機
能は、ステップ３０１において、流れ図のステップで示
すようにプロキシー・マネージャのマネージャ上で実行
される。ステップ３０３では、プロキシー・マネージャ
のマネージャの構成ファイルが読取られる。構成ファイ
ルは、ロードされるプロキシー・マネージャ・ライブラ
リ・ファイルの名前を含む一連のレコードから成る。ス
テップ３０５で、構成ファイルの中の各レコードについ
て、ファイル・システム中で指定ファイルが検索され
る。ステップ３０７で、指定されたライブラリがロード
される。ステップ３０９で、ファイルの中のプロキシー
・マネージャ・コードが初期化され、プロキシー・マネ
ージャのマネージャに登録される。ステップ３１１で、
構成ファイルの中に他のプロキシー・マネージャ用のレ
コードがまだあるかどうか判別するテストが実行され
る。他にレコードがない場合、ステップ３１３でプロセ
スが終了する。

【００２８】上記の初期化の説明では、外部ＯＲＢのク
ライアント部分は、すでにローカル・マシンにインスト
ールされていると仮定している。これらのクライアント
部分は、ターゲット・マシン内に存在するＯＲＢの完全
な形を大幅に縮小したバージョンにすることが可能だ
が、最小限の外部ＯＲＢが、プロキシー・オブジェクト
が通信するローカル・マシン上に存在しなければならな
い。外部ＯＲＢの縮小されたクライアント部分が、関連
する個々のプロキシー・マネージャがインストールされ
るとき、叉はそこに組込まれるときと同時に、インスト
ールされる可能性がある。

【００２９】プロキシー・オブジェクトの導出を図６に
示す。ＤＳＯＭＯＲＢのクラス及びメソッドを示して
いる。他のＯＲＢ実現では、当然他のメソッド及びクラ
スが使用される。継承及びサブクラス化は、オブジェク
ト指向プログラミングに熟練している当業者には周知の
技術であり、適宜説明する以外、ここでは詳細は記載し
ない。すべてのＳＯＭオブジェクトは、すべての親オブ
ジェクトの親であるＳＯＭＯｂｊｅｃｔクラス３５０
から派生する。ＳＯＭＯｂｊｅｃｔ３５０はメソッド
のセット３５１を含み、このセットはＳＯＭＤｉｓｐａ
ｔｃｈを含む。ＳＯＭＯｂｊｅｃｔ中の他のメソッド
は、特定のＳＯＭＯｂｊｅｃｔクラスに関する情報の取
得、初期化、診断、デバッグ、及び他の目的に関連する
ものである。分散ＳＯＭオブジェクトはすべて、ＳＯＭ
Ｏｂｊｅｃｔ３５０の子であるＳＯＭＤＯｂｊｅｃｔ
クラス３５３のメンバーである。ＳＯＭＤＯｂｊｅｃ
ｔ３５３は、ＳＯＭＯｂｊｅｃｔ３５０からこれらの
メソッドをすべて継承し、更に他のメソッドのグループ
３５５を含めることによりサブクラス化される。

【００３０】ＳＯＭＯｂｊｅｃｔに追加される機能は、
ＣＯＲＢＡ規定により指定された機能であり、ＣＯＲＢ
Ａコンピュータ・オブジェクトに関連する。次に、プロ
キシー・クラス・オブジェクトＳＯＭＤＣｌｉｅｎｔＰ
ｒｏｘｙ３５７は、ＳＯＭＤＯｂｊｅｃｔ３５３の
子であり、ＳＯＭＯｂｊｅｃｔ３５０及びＳＯＭＤＯ
ｂｊｅｃｔのすべてのメソッドと、メソッド３５９の追
加グループを含む。ＳＯＭＤＣｌｉｅｎｔＰｒｏｘｙク
ラスに追加されたメソッド３５９は、プロキシー・クラ
スが関連する特定のＯＲＢに固有のものである。また、
ＳＯＭＤｉｓｐａｔｃｈメソッドが上書きされ、ＯＲＢ
にメソッド・テーブルではなくメッセージを送信する。
アブストラクト・ターゲット・オブジェクト・クラス３
６１は、基本的にはターゲット・オブジェクトとそのク
ライアント間のインターフェースである。ＳＯＭには、
インターフェース・リポジトリがあり、そこからターゲ
ット・オブジェクト・インターフェースを検索できる。
ＳＯＭコンパイラは、オブジェクトをコンパイルすると
きに、インターフェース情報をインターフェース・リポ
ジトリに配置する。更に、ＤＳＯＭＯＲＢがメソッド
呼出しのために、叉は他のプロセスのために新しいオブ
ジェクト参照を受取る場合、インターフェースがリポジ
ションに追加される。この分野で熟練している当業者な
ら、使用できるアブストラクト・ターゲット・オブジェ
クトを作成する他の方法を考案できるだろう。ＯＲＢ
ＴａｒｇｅｔＰｒｏｘｙ３６３のクラス・プロキシー
・オブジェクトが、ＳＯＭＤＣｌｉｅｎｔＰｒｏｘｙと
ＴａｒｇｅｔＯｂｊｅｃｔ３６１を親として作成され
る。このクラス・オブジェクトから、外部ＯＲＢ中の特
定のターゲット・オブジェクトのためにプロキシー・オ
ブジェクト・インスタンスが作成される。

【００３１】プロキシー・オブジェクト中のメソッド・
テーブルのオーバーライドについて、図７及び８を参照
して次に説明する。典型的なＳＯＭオブジェクト４００
を図７に示す。ＳＯＭオブジェクト４００は、ＳＯＭＤ
ｉｓｐａｔｃｈメソッドを介して動的にメソッドを呼出
すか、叉はメソッド・テーブル４０３を参照して静的に
呼出す。動的メソッド呼出しでは、実行時に作成され
る、即ちオブジェクトが書込まれた時点では予想されな
かったメソッドのために、新しいメソッド呼出し４０５
を作成し、ＳＯＭＤｉｓｐａｔｃｈメソッド４０１によ
り呼出すことが可能になり、柔軟性が高まる。メソッド
・テーブル４０３には、開発者に周知のコードのポイン
タが入り、オブジェクトが派生したＩＤＬソース・モジ
ュールに書込まれた静的バインディング４０１により定
義される。メソッド・テーブルの参照は、柔軟性には欠
けるが、動的メソッド呼出しプロセスより時間はかなり
速い。メソッド・テーブル中のポインタは、要求された
メソッドを実行する実現されたコード上で、メソッド呼
出し４０９の呼出しに使用される。

【００３２】メソッド・テーブルは、多くのオブジェク
ト指向言語において、メソッド呼出しをメソッド機能を
実施するコードと関連付けるメカニズムとして使用され
る。メソッドがオブジェクト上で呼出されると、オブジ
ェクト指向実行時はメソッド・テーブルをチェックし
て、そのメソッドの実施（ｉｍｐｌｅｍｅｎｔａｔｉｏ
ｎ）が格納されている場所を検索し、このコードを実行
する。メソッド・テーブルを使用する利点は、メソッド
・テーブルの参照箇所を元の実施から新しい実施に変更
するだけで、メソッドの実施を簡単に変更できる点であ
る。これは、例えばオブジェクトをサブクラス化すると
きに、いかに多くのオブジェクト指向言語がメソッド実
施のオーバーライドをサポートするかということであ
る。メソッド・テーブルは、メソッド呼出しの結果とし
て実行されるコードを選択するために使用するデータ構
造である。実行プロセスのこの選択は、メソッド・ディ
スパッチと呼ばれる。

【００３３】図８では、ＳＯＭＤｉｓｐａｔｃｈメソッ
ドは、メソッド呼出しをメソッド・テーブルへではなく
ＯＲＢ実施へ伝達するように、プロキシー・オブジェク
ト４１０の中でオーバーライドされる。図８に示すよう
に、プロキシー・オブジェクトを作成するために、メソ
ッド・テーブルにいくつか興味深い変更が実施されてい
る。特に、プロキシー・オブジェクトが、アプリケーシ
ョン・プログラミング・インターフェースの観点から
は、ターゲット・オブジェクトであるかのように作成さ
れる。但し、メソッドがプロキシー・オブジェクト上で
呼出される場合、この呼出しは代行受信され、ローカル
に実行される代わりにネットワークを介してターゲット
・オブジェクトに伝達される。これは、ターゲット・オ
ブジェクトのメソッド用のプロキシー・オブジェクトの
メソッド・テーブル４１３を、ｓｏｍＤｉｓｐａｔｃｈ
と呼ばれる、ルーチンを参照する再ディスパッチ・スタ
ブと呼ばれる新しい参照で上書きすることにより実施で
きる。このルーチンには、メソッド呼出しを再パッケー
ジし、これをネットワークを介してターゲット・オブジ
ェクトに送信するコードが入っている。

【００３４】図９は、第１のアドレス空間のクライアン
ト・オブジェクトから第２のアドレス空間のターゲット
・オブジェクトに対する、本発明に即した呼出しのフロ
ーチャートである。プロキシー・オブジェクトが作成さ
れ、プロキシー・オブジェクトのポインタがクライアン
トに戻ると、クライアントはステップ４５１でプロキシ
ー上のメソッドを呼び出すことを決める。前述のよう
に、クライアント・オブジェクトは、ターゲット・オブ
ジェクトのローカル・コピーを呼出しているように見え
る。ステップ４５３では、メソッド呼出しがメソッド・
テーブル及びプロキシー・オブジェクトからＳＯＭＤｉ
ｓｐａｔｃｈメソッドへ宛先変更される。ＳＯＭＤｉｓ
ｐａｔｃｈメソッドは、クライアントが常駐するＯＲＢ
及びアドレス空間からのメッセージを、ターゲット・オ
ブジェクトが検出されるＯＲＢ及びアドレス空間へ経路
指定することを可能にする。ステップ４５５では、ＳＯ
ＭＤｉｓｐａｔｃｈメソッドが、適切なＯＲＢ呼出しを
介して呼出しを経路指定する。例えば、ＳＯＭＤｉｓｐ
ａｔｃｈは、ＣＯＲＢＡが定義する動的統合インターフ
ェースを使用して、外部ＯＲＢ中の遠隔オブジェクト上
でメソッドを実行できる。ステップ４５７では、ターゲ
ット・オブジェクトがクライアントの要求を受領し、そ
の要求を実行し、結果をＯＲＢに戻す。プロキシー・オ
ブジェクトは、ターゲット・オブジェクトの処理結果を
クライアントに戻す。

【００３５】図５に示したプロキシー・マネージャ・オ
ブジェクトのマネージャの初期化では、プロキシー・マ
ネージャの登録は構成ファイル内のハード・コーディン
グに依存する。このような具現化では、構成ファイルは
新しいＯＲＢ及びプロキシー・マネージャ用に更新する
か、または構成ファイルが作成された時点で、開発者に
周知であったＯＲＢ及びプロキシー・マネージャに限定
する必要があるであろう。本発明はここでも、プロキシ
ー・マネージャをプロキシー・マネージャ・オブジェク
トのマネージャに登録する動的メソッドを包含してい
る。図１０のステップ４７５に示すように、ローカルＯ
ＲＢ実行時が、プロキシー・マネージャのマネージャ上
で動的ロード・メソッドを呼出す。この処理は、部分的
にはプロキシー・マネージャのマネージャに、新しいプ
ロキシー・マネージャ実施ライブラリ用のクラス名、及
び完全に修飾したファイル名を渡すことによって達成さ
れる。次に、ステップ４７７でプロキシー・マネージャ
のマネージャは、実施ライブラリをロードし、新しいプ
ロキシー・マネージャ・クラスを作成する。ステップ４
７９で、プロキシー・マネージャのマネージャは新しい
プロキシー・マネージャ・クラスのインスタンスを作成
する。ステップ４８１で、プロキシー・マネージャのマ
ネージャは、新しいプロキシー・マネージャを現在イン
ストールされているプロキシー・マネージャのリストに
登録する。

【００３６】本発明の第２の具現化を図１１に示す。こ
こでは、プロキシー・マネージャのマネージャ及び個々
の外部ＯＲＢに対するプロキシー・マネージャのセット
がゲートウェイ・マシン上に置かれる。ネイティブＯＲ
Ｂ及び外部ＯＲＢの両方からの複数のクライアント・マ
シンが、他のＯＲＢに対する通信サービスのためにゲー
トウェイ・マシンを呼出すことができる。この設計の利
点は、一般的に強力なコンピュータ・システムであるゲ
ートウェイ・サーバーに、ローカライズされたメソッド
に関連するオーバーヘッドを受持たせることである。相
対的に資源が少ないクライアント・マシンは、各マシン
のプロキシー・マネージャのマネージャ、及びプロキシ
ー・マネージャ・オブジェクトに関連するオーバーヘッ
ドを招くことなく、他のＯＲＢと通信するためにゲート
ウェイ・マシンを呼出すことができる。上記の具現化で
は、コーディングの変更に関して相対的にローカライズ
された影響をＯＲＢに与える一方で、各プロキシー・マ
ネージャ及びプロキシー・オブジェクトはシステム性能
に累積的効果をもたらす。第１の具現化では、プロキシ
ー・マネージャのマネージャ及びプロキシー・マネージ
ャのセットは、各ＯＲＢのマシン毎に別々に必要にな
る。ゲートウェイの概念では、複数のＯＲＢが最小量の
オーバーヘッドで通信することを可能にするために、単
一のＯＲＢ内でただ一つのゲートウェイ・マシンが、外
部ＯＲＢ用のＭＰＭ及び複数のプロキシー・マネージャ
を持つだけでよい。また、第１の具現化では、各マシン
は外部ＯＲＢクライアント・ソフトウェアをインストー
ル叉はロードする必要がある。第２の具現化では、ゲー
トウェイ・マシンだけが外部ＯＲＢソフトウェアを必要
とする。第２の具現化の短所は、２つのプロキシー・オ
ブジェクトを使用して要求をクライアントからターゲッ
ト・オブジェクトに渡すと、性能が幾らか失われる点で
ある。

【００３７】図１１では、第１のＯＲＢ５００が、ゲー
トウェイ・マシンのアドレス空間５０１、及びクライア
ント・マシン５０３のアドレス空間に存在する。図を簡
単にするために、ネイティブの単一のクライアントだけ
図示するが、このようなクライアントが多数ゲートウェ
イと結合することが可能であり、実際に結合するだろ
う。クライアント・マシンに常駐するクライアント・オ
ブジェクト５０２が、遠隔マシンのアドレス空間５０７
の第２のＯＲＢ５０５に書込まれた、ターゲット・オブ
ジェクト５０４からのサービスを要求する。ここでも、
複数のＯＲＢ及びターゲット遠隔マシン・オブジェクト
がゲートウェイ・マシンに結合するが、図には示さな
い。ターゲット・オブジェクト５０４に対する呼出し５
０９に応答して、クライアント・マシンのＯＲＢ５００
は、プロキシー・マネージャのマネージャ・プロキシー
５１１（ＭＰＭプロキシー）を作成し、ＭＰＭプロキシ
ーへのポインタ５１３をクライアント・オブジェクトに
戻す。ＭＰＭプロキシー５１１は、これ以前の呼出しに
応答してすでに作成されている場合があり、その場合は
ポインタが直ちに戻される。クライアント・オブジェク
ト５０２はＭＰＭプロキシー５１１を介して、オブジェ
クト参照をゲートウェイ・マシンのアドレス空間５０１
の中の、プロキシー・マネージャのマネージャ５１５に
渡す。これに応答して、プロキシー・マネージャのマネ
ージャ５１５は、外部オブジェクト参照を理解するプロ
キシー・マネージャ５２１を検出するまで、プロキシー
・マネージャ５１７、５１９、５２１に照会する。この
プロキシー・マネージャ５２１は、ターゲット・オブジ
ェクト５０４との通信を達成するための、ユニバーサル
・オブジェクト・エンカプセレータ・プロキシー（ＵＯ
Ｅプロキシー）５２３を作成する。ＵＯＥプロキシーの
ポインタがクライアント・マシンの中のＯＲＢに渡され
る。このＯＲＢはクライアントＵＯＥプロキシー・オブ
ジェクト５２５、及び要求しているクライアント・オブ
ジェクト５０２へのポインタを作成する。クライアント
５０２は、クライアントＵＯＥプロキシー５２５、及び
ＵＯＥプロキシー５２３を介してターゲット・オブジェ
クト５０４と通信する。

【００３８】図１２は、第２の具現化のプロセスを示
す。ステップ６００で、クライアント・オブジェクトか
らＯＲＢに対する、外部オブジェクト識別子を含む呼出
しの結果、ゲートウェイでのＭＰＭプロキシー・オブジ
ェクトのインストール及びＭＰＭの初期化が決定する。
ステップ６０１で、ターゲット・オブジェクトがＯＲＢ
にとってネイティブかどうかを決定するオブジェクトが
作られる。ネイティブの場合、クライアント・マシンの
ＯＲＢはＯＲＢのプロキシー・マネージャを有するか、
叉は有しない場合は、ネイティブ・オブジェクト用の自
身のプロキシーをステップ６０３で作成できると仮定さ
れる。この処理はステップ６０５で終了する。次に、ス
テップ６０７で、ＭＰＭプロキシーが存在するかどうか
を判別するテストが実行される。ＭＰＭプロキシーによ
り、クライアント・マシンの要求者は、まるでクライア
ント・マシンにゲートウェイＭＰＭが常駐しているかの
ように、要求を透過的にゲートウェイＭＰＭに送ること
ができる。ＭＰＭプロキシーが存在する場合、ステップ
６１３でプロキシー・マネージャのマネージャがすでに
ゲートウェイ・マシンにインストールされているかどう
か判別するテストが実行される。ＭＰＭプロキシーが存
在しない場合、ステップ６０１のクライアント・システ
ムのネイティブＯＲＢが、構成ファイルからＭＰＭのオ
ブジェクト参照を読取る。ステップ６１１で、クライア
ント・システムは、プロキシー・マネージャのマネージ
ャのプロキシー・オブジェクトのローカル・コピーを作
成する。ＭＰＭプロキシーの作成プロセスは、上記の説
明のようにするか、叉はオブジェクト参照に応答してオ
ブジェクトを戻す、ＣＯＢＲＡ指定のストリング・ツー
・オブジェクト（Ｓｔｒｉｎｇ−ｔｏ−ｏｂｊｅｃｔ）
メソッドに従って実行できる。ＭＰＭプロキシーがイン
ストールされ、ＭＰＭプロキシーへのポインタがクライ
アントに戻される。ステップ６１５で、プロキシー・マ
ネージャのマネージャの初期化が呼出される。このプロ
セスは、基本的には図５のステップ３０３から３１３ま
での繰返しであり、ゲートウェイ・マシンのクライアン
ト・アドレス空間の外で実行される。

【００３９】ステップ６１７で、クライアント・マシン
のクライアント・オブジェクトが、ネイティブＯＲＢに
対して外部である、ターゲット・オブジェクト識別子を
含むメソッドを呼出す。ターゲット・オブジェクト識別
子は、ＭＰＭプロキシーを介してゲートウェイのプロキ
シー・マネージャのマネージャに渡される。ステップ６
１９では、ＵＯＥプロキシーの作成の中でターゲット・
オブジェクト識別子が認識される。このプロセスは、基
本的には図３のステップ２０７〜２１３と似ているが、
ローカルではなくゲートウェイ・マシン上で実行される
点が異なる。ゲートウェイ・マシンにＵＯＥが作成され
ると、ステップ６２１でポインタがクライアント・マシ
ンのネイティブＯＲＢに送り戻される。ステップ２１３
では、ネイティブＯＲＢがクライアント・マシン中にク
ライアント・プロキシーを作成し、クライアント・プロ
キシーを指すポインタを、元の要求を出したクライアン
ト・オブジェクトに渡す。

【００４０】ステップ６２５では、クライアントがクラ
イアント・プロキシー上でメソッドを呼出す。ステップ
６２７で、クライアント・プロキシー中のＳＯＭＤｉｓ
ｐａｔｃｈが、クライアント及びゲートウェイ・マシン
のネイティブＯＲＢ実行時を介して、遠隔ＵＯＥプロキ
シー上に呼出されたメソッドをリダイレクトしている。
ＵＯＥプロキシー中で、ＳＯＭＤｉｓｐａｔｃｈプロセ
スは、ゲートウェイ・マシン内のネイティブＯＲＢ、及
びターゲット・マシン内の外部ＯＲＢを介して、遠隔タ
ーゲット・オブジェクト上にメソッドを呼び出す（ステ
ップ６２９）。ステップ６３１では、ターゲット・オブ
ジェクトが要求を実行し、結果をＵＯＥプロキシーに戻
す。ステップ６３３でＵＯＥプロキシーが結果をクライ
アント・プロキシーに戻し、クライアント・プロキシー
はステップ６３５でクライアント・オブジェクトに結果
を戻す。ステップ６３７でプロセスが終了する。

【００４１】前述のように、第２の具現化の他の利点
は、外部ＯＲＢに書込まれたクライアント・マシン上の
要求者オブジェクトが、ゲートウェイ・マシンを呼出し
て外部ターゲット・オブジェクト識別子を弁別できる点
である。派生する唯一のオーバーヘッドは、認識されな
かった場合に、ターゲット・オブジェクト識別子をゲー
トウェイ・マシンに送るコードが必要な点である。図１
３では、ステップ６１５で示したように、外部ＯＲＢが
ターゲット・オブジェクト識別子を弁別できず、これを
ゲートウェイＯＲＢに送っている。ステップ６５１で、
ターゲット・オブジェクト識別子が、ゲートウェイＯＲ
Ｂに対してネイティブかどうか判別される。ネイティブ
である場合、通常のプロキシー・オブジェクトがステッ
プ６５３で作成され、そのプロキシー・オブジェクトへ
のポインタが外部ＯＲＢに送り戻される。このときはプ
ロセスはステップ６５５で終了する。しかし、ターゲッ
ト・オブジェクトがゲートウェイＯＲＢにとってネイテ
ィブではない場合、ステップ６５７でターゲット・オブ
ジェクト識別子が、ゲートウェイのプロキシー・マネー
ジャのマネージャに渡される。既に説明したように、ス
テップ６５９で認識及びＵＯＥプロキシーの作成が行わ
れる。ステップ６６１で、外部ＯＲＢにポインタが伝達
され、外部ＯＲＢは、ステップ６６３でプロキシー・オ
ブジェクトを作成する。これに代わる外部ＯＲＢ中の他
の通信手段では、外部ＯＲＢ中の要求者が直接ＵＯＥプ
ロキシーと対話できる場合がある。

【００４２】ステップ６６５では、外部要求者が外部プ
ロキシー及び外部クライアント上でメソッドを呼出す。
ステップ６６７では、外部ＯＲＢを介して外部プロキシ
ーがＵＯＥプロキシー上でメソッドを呼出す。ステップ
６６９で、ＵＯＥプロキシーはターゲット・オブジェク
ト上にメソッドを呼出す。ステップ６７１で、ターゲッ
ト・オブジェクトは要求を実行し、結果をＵＯＥプロキ
シーに戻す。ステップ６７３で、ＵＯＥプロキシーは結
果を外部プロキシーに戻し、ステップ６７５で外部プロ
キシーは結果を外部ＯＲＢの外部クライアントに戻す。
プロセスはステップ６７７で終了する。

【００４３】

【発明の効果】本発明は、次のような利点を有する。Ｏ
ＲＢ実施に対する影響が小さくてローカル化されてい
る。ＯＲＢ実施毎に、ネイティブ・オブジェクト参照を
認識し、ターゲット・オブジェクトのためのプロキシー
を作成できる、プロキシー・マネージャを備える。推奨
する具現化では、ＳＯＭがプロキシー・オブジェクトの
動的作成に必要なすべてのサポートを提供する。各実施
が、遠隔メソッド再ディスパッチのためのメカニズムを
実現するサポート・クラスを備える。推奨する具現化で
は、遠隔メソッド再ディスパッチのためのサポート・ク
ラスがＳＯＭＤＯｂｊｅｃｔから派生する。実施毎に外
部オブジェクト参照を認識し、これを弁別のためにプロ
キシー・マネージャのマネージャに渡せなければならな
い。これは、ネイティブＯＲＢトランスポート、オブジ
ェクト参照フォーマット、及びメッセージ・フォーマッ
トに影響しない。相互接続するＯＲＢの数に関係なく、
ゲートウェイ・フレームワークが１つだけ必要である。

【００４４】本発明をその特定の具現化を参照しながら
提示し説明したが、本発明の意図と範囲を逸脱すること
なく、フォーム及び詳細について前述の及びその他の変
更が実施される場合があることは、この分野で熟練して
いる当業者には理解されるだろう。

【００４５】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００４６】（１）第１のアドレス空間の要求者から
第２のアドレス空間のターゲット・オブジェクトへ要求
を伝達する方法であり、（ａ）要求者から、要求者が書
込まれているネイティブ・オブジェクト・リクエスト・
ブローカへ要求を渡すステップと、（ｂ）ターゲット・
オブジェクトが、ネイティブ・オブジェクト・リクエス
ト・ブローカにとって外部であるという判別に応答し
て、ターゲット・オブジェクトが書込まれている外部オ
ブジェクト・リクエスト・ブローカを検出するステップ
と、（ｃ）第１のアドレス空間中の外部オブジェクト・
リクエスト・ブローカに書込む，プロキシー・オブジェ
クトを生成するステップと、（ｄ）プロキシーを介し
て、要求者オブジェクトからターゲット・オブジェクト
への通信を設定するステップとを具備する，要求伝達方
法。（２）前記検出ステップが、ターゲット・オブジェク
トの外部オブジェクト・リクエスト・ブローカが、プロ
キシー・マネージャの１つにより認識されるまで、それ
ぞれの外部オブジェクト・リクエスト・ブローカに対応
するプロキシー・オブジェクトをそれぞれが生成する、
一連のプロキシー・マネージャに繰返し要求を伝達する
ステップを有し、前記生成ステップが認識したプロキシ
ー・マネージャにより達成される、（１）に記載の要求
伝達方法。（３）コンピュータ・ネットワーク内のアドレス空間
の間で要求を伝達する方法であり、（ａ）ネットワーク
と結合した第１のコンピュータ・システム内の第１のア
ドレス空間に共に存在する、要求者からネイティブ・オ
ブジェクト・リクエスト・ブローカへ要求を渡すステッ
プと、（ｂ）要求のターゲット・オブジェクトがネイテ
ィブ・リクエスト・ブローカにとって外部であるという
判別に応答して、ターゲット・オブジェクトが書込まれ
る外部オブジェクト・リクエスト・ブローカを検出する
ステップと、（ｃ）ネットワークに結合された第２のコ
ンピュータ・システムの第２のアドレス空間に共に存在
する、外部オブジェクト・リクエスト・ブローカ、及び
ターゲット・オブジェクトと通信するために、第１のア
ドレス空間にプロキシー・オブジェクトを生成するステ
ップと、（ｄ）プロキシー・オブジェクトを介して、要
求者から外部オブジェクト・リクエスト・ブローカ、及
びターゲット・オブジェクトへの通信を設定するステッ
プで構成される、要求伝達方法。（４）前記検出ステップが、ターゲット・オブジェク
トの外部オブジェクト・リクエスト・ブローカが、プロ
キシー・マネージャの１つにより認識されるまで、それ
ぞれの外部オブジェクト・リクエスト・ブローカに対応
するプロキシー・オブジェクトをそれぞれが生成する、
一連のプロキシー・マネージャに繰返し要求を引渡すス
テップを含み、前記生成ステップが認識したプロキシー
・マネージャにより達成される、（３）に記載の要求伝
達方法。（５）前記検出及び生成ステップが、ゲートウェイ・
コンピュータ・システム上の第３のアドレス空間で達成
され、且つプロキシー・マネージャのセットがそのアド
レス空間に存在し、第１のコンピュータ・システム、第
２のコンピュータ・システム、及びゲートウェイ・コン
ピュータ・システムがネットワークにより一緒に結合す
る、（４）に記載の要求伝達方法。（６）前記第１及び第２のアドレス空間が１つのコン
ピュータ・システムにあり、一連のプロキシー・マネー
ジャが第１のアドレス空間にある、（２）に記載の要求
伝達方法。（７）前記繰返し引渡すステップが、第３のアドレス
空間中のプロキシー・マネージャ・オブジェクトのマネ
ージャにより達成され、更に（ａ）ネイティブ・オブジ
ェクト・リクエスト・ブローカにより、第１のアドレス
空間中にプロキシー・マネージャのプロキシー・オブジ
ェクトのマネージャを生成し、プロキシー・マネージャ
のプロキシー・オブジェクトのマネージャが要求者オブ
ジェクトと、プロキシー・マネージャ・オブジェクトの
マネージャとの間の通信を設定するステップと、（ｂ）
認識したプロキシー・マネージャにより生成されたプロ
キシー・オブジェクトへのポインタを、第１のアドレス
空間のネイティブ・オブジェクト・リクエスト・ブロー
カに渡すステップと、（ｃ）前記第１のアドレス空間に
生成されたプロキシー・オブジェクトが、要求者プロキ
シー・オブジェクトであり、且つ要求者からプロキシー
及びターゲット・オブジェクトへの通信が、要求者プロ
キシー・オブジェクトを介して設定される、（５）に記
載の要求伝達方法。（８）要求伝達方法であり、（ａ）第２のアドレス空
間の外部要求者から、第２の要求を第３のアドレス空間
のネイティブ・リクエスト・ブローカへ渡すステップ
と、（ｂ）第２の要求のターゲット・オブジェクトが、
ネイティブ・リクエスト・ブローカにとって外部である
という判別に応答して、第２の要求のターゲット・オブ
ジェクトが書込まれる、第２の外部オブジェクト・リク
エスト・ブローカを検出するステップと、（ｃ）ネット
ワークに結合されたコンピュータ・システムの１つのア
ドレス空間に共に存在する、第２の外部オブジェクト・
リクエスト・ブローカと、第２の要求のターゲット・オ
ブジェクトと通信するために、第３のアドレス空間に第
２のプロキシー・オブジェクトを生成するステップと、
（ｄ）第２のプロキシー・オブジェクトを介して、外部
要求者から第２の外部オブジェクト・リクエスト・ブロ
ーカ、及び第２の要求のターゲット・オブジェクトへの
通信を設定するステップを更に具備する、（５）に記載
の要求伝達方法。（９）要求伝達方法であり、（ａ）
第２のアドレス空間の外部要求者から、第２の要求を
第３のアドレス空間のネイティブ・リクエスト・ブロー
カへ渡すステップと、（ｂ）第２の要求のターゲット・
オブジェクトがネイティブ・リクエスト・ブローカにと
ってネイティブであるという判別に応答して、ネットワ
ークに結合されたコンピュータ・システムのアドレス空
間中の、第２の要求のターゲット・オブジェクトと通信
するために、第３のアドレス空間に第２のプロキシー・
オブジェクトを生成し、ネイティブ・リクエスト・ブロ
ーカにより実行される処置を生成するステップと、
（ｃ）第２のプロキシー・オブジェクトを介して、外部
要求者から第２の要求のターゲット・オブジェクトへの
通信を設定するステップを更に具備する、（５）に記載
の要求伝達方法。（１０）要求が、個々のコンピュータ・システム内の
アドレス空間の間で渡されるコンピュータ・ネットワー
クであり、（ａ）ネットワークに結合された第１のコン
ピュータ・システムの第１のアドレス空間に共に存在す
る、要求者及びネイティブ・オブジェクト・リクエスト
・ブローカと、（ｂ）ネットワークに結合された第２の
コンピュータ・システムの第２のアドレス空間に共に存
在する、外部オブジェクト・リクエスト・ブローカ及び
ターゲット・オブジェクトと、（ｃ）１つのアドレス空
間内、及びネットワーク内の複数のアドレス空間の間で
要求を渡す通信手段と、（ｄ）ネイティブ・リクエスト
・ブローカにとって外部であるターゲット・オブジェク
トに対する要求を要求者が出すときに使用される、ター
ゲット・オブジェクトが書込まれる、外部オブジェクト
・リクエスト・ブローカを検出する手段と、（ｅ）外部
オブジェクト・リクエスト・ブローカ及びターゲット・
オブジェクトと通信するための、第１アドレス空間のプ
ロキシー・オブジェクトとを具備し、（ｆ）前記要求者
から外部オブジェクト・リクエスト・ブローカ及びター
ゲット・オブジェクトへの通信が、プロキシー・オブジ
ェクトを介して設定される、コンピュータ・ネットワー
ク。（１１）前記検出手段が、ターゲット・オブジェクト
の外部オブジェクト・リクエスト・ブローカがプロキシ
ー・マネージャの１つにより認識されるまで、それぞれ
の外部オブジェクト・リクエスト・ブローカに対応する
プロキシー・オブジェクトをそれぞれが生成する、一連
のプロキシー・マネージャに繰返し要求を渡す、プロキ
シー・マネージャ・オブジェクトのマネージャを更に具
備する、（１０）に記載のネットワーク。（１２）前記プロキシー・オブジェクトが、一連のプ
ロキシー・マネージャにより生成される、（１０）に記
載のネットワーク。（１３）プロキシー・マネージャのマネージャ及び一
連のプロキシー・マネージャが常駐する、ゲートウェイ
・コンピュータ・システム上の第３のアドレス空間を更
に具備し、第１のコンピュータ・システム、第２のコン
ピュータ・システム、及びゲートウェイ・コンピュータ
・システムがネットワークにより一緒に結合される、
（１１）に記載のネットワーク。（１４）ネットワークであり、（ａ）第３のアドレス
空間中に、認識するプロキシー・マネージャにより生成
されたゲートウェイ・プロキシー・オブジェクトを更に
具備し、（ｂ）前記第１のアドレス空間に生成されたプ
ロキシー・オブジェクトが要求者プロキシー・オブジェ
クトであり、且つ要求者からゲートウェイ・プロキシー
及びターゲット・オブジェクトへの通信が要求者プロキ
シー・オブジェクトを介して設定される、（１２）に記
載のネットワーク。（１５）ネットワークであり、（ａ）第３のアドレス
空間内のプロキシー・マネージャのマネージャに第２の
要求を渡す第４のアドレス空間内の外部要求者と、
（ｂ）ネットワークに結合されたコンピュータ・システ
ムの第５のアドレス空間に共に存在する、第２の外部オ
ブジェクト・リクエスト・ブローカ、及び第２の要求の
ターゲット・オブジェクトと通信する、一連のプロキシ
ー・マネージャの１つにより第３のアドレス空間に生成
された第２のプロキシー・オブジェクトとを更に具備す
る、（１２）に記載のネットワーク。

【図面の簡単な説明】

【図１】本発明の解説に従って構成されるコンピュータ
・システムを示す。

【図２】いくつかのアドレス空間にあるプロキシー・オ
ブジェクト・マネージャ、及び関連モジュールを示す。

【図３】プロキシー・オブジェクト管理プロセスの流れ
図である。

【図４】プロキシー・オブジェクト生成の流れ図であ
る。

【図５】プロキシー・マネージャ・オブジェクトのマネ
ージャの初期設定の流れ図である。

【図６】プロキシー・オブジェクトの導出を示す。

【図７】オーバーライドされたｓｏｍＤｉｓｐａｔｃｈ
のないＳＯＭオブジェクトを示す。

【図８】オーバーライドされたｓｏｍＤｉｓｐａｔｃｈ
のあるプロキシー・オブジェクトを示す。

【図９】第１のアドレス空間のクライアント・オブジェ
クトから、第２のアドレス空間のターゲット・オブジェ
クトへの呼出しのフローチャートである。

【図１０】プロキシー・マネージャの登録を示す。

【図１１】本発明の第２の具現化を示す。

【図１２】本発明の第２の具現化における、第１のアド
レス空間のクライアント・オブジェクトから、第２のア
ドレス空間のターゲット・オブジェクトへの呼出しのフ
ローチャートである。

【図１３】第２の具現化における、外部要求者からゲー
トウェイ・マシンへの呼出しのフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (72)発明者マイケル・ハーデン・コナーアメリカ合衆国78759、テキサス州オースチン、ウォルヒル・レイン 4416 (72)発明者ラグー・ヴィシュワナス・ヒュードリアメリカ合衆国78758、テキサス州オースチン、シーダー・ベン・ドライブナンバー406 2015 (72)発明者マーク・グレゴリー・スミスアメリカ合衆国78759、テキサス州オースチン、シエラ・オークス 10615

Claims

【特許請求の範囲】

【請求項１】第１のアドレス空間の要求者から第２の
アドレス空間のターゲット・オブジェクトへ要求を伝達
する方法であり、（ａ）要求者から、要求者が書込まれているネイティブ
・オブジェクト・リクエスト・ブローカへ要求を渡すス
テップと、（ｂ）ターゲット・オブジェクトが、ネイティブ・オブ
ジェクト・リクエスト・ブローカにとって外部であると
いう判別に応答して、ターゲット・オブジェクトが書込
まれている外部オブジェクト・リクエスト・ブローカを
検出するステップと、（ｃ）第１のアドレス空間中の外部オブジェクト・リク
エスト・ブローカに書込む，プロキシー・オブジェクト
を生成するステップと、（ｄ）プロキシーを介して、要求者オブジェクトからタ
ーゲット・オブジェクトへの通信を設定するステップと
を具備する，要求伝達方法。
【請求項２】前記検出ステップが、ターゲット・オブ
ジェクトの外部オブジェクト・リクエスト・ブローカ
が、プロキシー・マネージャの１つにより認識されるま
で、それぞれの外部オブジェクト・リクエスト・ブロー
カに対応するプロキシー・オブジェクトをそれぞれが生
成する、一連のプロキシー・マネージャに繰返し要求を
伝達するステップを有し、前記生成ステップが認識した
プロキシー・マネージャにより達成される、請求項１に
記載の要求伝達方法。
【請求項３】コンピュータ・ネットワーク内のアドレ
ス空間の間で要求を伝達する方法であり、（ａ）ネットワークと結合した第１のコンピュータ・シ
ステム内の第１のアドレス空間に共に存在する、要求者
からネイティブ・オブジェクト・リクエスト・ブローカ
へ要求を渡すステップと、（ｂ）要求のターゲット・オブジェクトがネイティブ・
リクエスト・ブローカにとって外部であるという判別に
応答して、ターゲット・オブジェクトが書込まれる外部
オブジェクト・リクエスト・ブローカを検出するステッ
プと、（ｃ）ネットワークに結合された第２のコンピュータ・
システムの第２のアドレス空間に共に存在する、外部オ
ブジェクト・リクエスト・ブローカ、及びターゲット・
オブジェクトと通信するために、第１のアドレス空間に
プロキシー・オブジェクトを生成するステップと、（ｄ）プロキシー・オブジェクトを介して、要求者から
外部オブジェクト・リクエスト・ブローカ、及びターゲ
ット・オブジェクトへの通信を設定するステップで構成
される、要求伝達方法。
【請求項４】前記検出ステップが、ターゲット・オブ
ジェクトの外部オブジェクト・リクエスト・ブローカ
が、プロキシー・マネージャの１つにより認識されるま
で、それぞれの外部オブジェクト・リクエスト・ブロー
カに対応するプロキシー・オブジェクトをそれぞれが生
成する、一連のプロキシー・マネージャに繰返し要求を
引渡すステップを含み、前記生成ステップが認識したプ
ロキシー・マネージャにより達成される、請求項３に記
載の要求伝達方法。
【請求項５】前記検出及び生成ステップが、ゲートウ
ェイ・コンピュータ・システム上の第３のアドレス空間
で達成され、且つプロキシー・マネージャのセットがそ
のアドレス空間に存在し、第１のコンピュータ・システ
ム、第２のコンピュータ・システム、及びゲートウェイ
・コンピュータ・システムがネットワークにより一緒に
結合する、請求項４に記載の要求伝達方法。
【請求項６】前記第１及び第２のアドレス空間が１つ
のコンピュータ・システムにあり、一連のプロキシー・
マネージャが第１のアドレス空間にある、請求項２に記
載の要求伝達方法。
【請求項７】前記繰返し引渡すステップが、第３のア
ドレス空間中のプロキシー・マネージャ・オブジェクト
のマネージャにより達成され、更に（ａ）ネイティブ・オブジェクト・リクエスト・ブロー
カにより、第１のアドレス空間中にプロキシー・マネー
ジャのプロキシー・オブジェクトのマネージャを生成
し、プロキシー・マネージャのプロキシー・オブジェク
トのマネージャが要求者オブジェクトと、プロキシー・
マネージャ・オブジェクトのマネージャとの間の通信を
設定するステップと、（ｂ）認識したプロキシー・マネージャにより生成され
たプロキシー・オブジェクトへのポインタを、第１のア
ドレス空間のネイティブ・オブジェクト・リクエスト・
ブローカに渡すステップと、（ｃ）前記第１のアドレス空間に生成されたプロキシー
・オブジェクトが、要求者プロキシー・オブジェクトで
あり、且つ要求者からプロキシー及びターゲット・オブ
ジェクトへの通信が、要求者プロキシー・オブジェクト
を介して設定される、請求項５に記載の要求伝達方法。
【請求項８】要求伝達方法であり、（ａ）第２のアドレス空間の外部要求者から、第２の要
求を第３のアドレス空間のネイティブ・リクエスト・ブ
ローカへ渡すステップと、（ｂ）第２の要求のターゲット・オブジェクトが、ネイ
ティブ・リクエスト・ブローカにとって外部であるとい
う判別に応答して、第２の要求のターゲット・オブジェ
クトが書込まれる、第２の外部オブジェクト・リクエス
ト・ブローカを検出するステップと、（ｃ）ネットワークに結合されたコンピュータ・システ
ムの１つのアドレス空間に共に存在する、第２の外部オ
ブジェクト・リクエスト・ブローカと、第２の要求のタ
ーゲット・オブジェクトと通信するために、第３のアド
レス空間に第２のプロキシー・オブジェクトを生成する
ステップと、（ｄ）第２のプロキシー・オブジェクトを介して、外部
要求者から第２の外部オブジェクト・リクエスト・ブロ
ーカ、及び第２の要求のターゲット・オブジェクトへの
通信を設定するステップを更に具備する、請求項５に記
載の要求伝達方法。
【請求項９】要求伝達方法であり、（ａ）第２のアドレス空間の外部要求者から、第２の
要求を第３のアドレス空間のネイティブ・リクエスト・
ブローカへ渡すステップと、（ｂ）第２の要求のターゲット・オブジェクトがネイテ
ィブ・リクエスト・ブローカにとってネイティブである
という判別に応答して、ネットワークに結合されたコン
ピュータ・システムのアドレス空間中の、第２の要求の
ターゲット・オブジェクトと通信するために、第３のア
ドレス空間に第２のプロキシー・オブジェクトを生成
し、ネイティブ・リクエスト・ブローカにより実行され
る処置を生成するステップと、（ｃ）第２のプロキシー・オブジェクトを介して、外部
要求者から第２の要求のターゲット・オブジェクトへの
通信を設定するステップを更に具備する、請求項５に記
載の要求伝達方法。
【請求項１０】要求が、個々のコンピュータ・システ
ム内のアドレス空間の間で渡されるコンピュータ・ネッ
トワークであり、（ａ）ネットワークに結合された第１のコンピュータ・
システムの第１のアドレス空間に共に存在する、要求者
及びネイティブ・オブジェクト・リクエスト・ブローカ
と、（ｂ）ネットワークに結合された第２のコンピュータ・
システムの第２のアドレス空間に共に存在する、外部オ
ブジェクト・リクエスト・ブローカ及びターゲット・オ
ブジェクトと、（ｃ）１つのアドレス空間内、及びネットワーク内の複
数のアドレス空間の間で要求を渡す通信手段と、（ｄ）ネイティブ・リクエスト・ブローカにとって外部
であるターゲット・オブジェクトに対する要求を要求者
が出すときに使用される、ターゲット・オブジェクトが
書込まれる、外部オブジェクト・リクエスト・ブローカ
を検出する手段と、（ｅ）外部オブジェクト・リクエスト・ブローカ及びタ
ーゲット・オブジェクトと通信するための、第１アドレ
ス空間のプロキシー・オブジェクトとを具備し、（ｆ）前記要求者から外部オブジェクト・リクエスト・
ブローカ及びターゲット・オブジェクトへの通信が、プ
ロキシー・オブジェクトを介して設定される、コンピュ
ータ・ネットワーク。
【請求項１１】前記検出手段が、ターゲット・オブジ
ェクトの外部オブジェクト・リクエスト・ブローカがプ
ロキシー・マネージャの１つにより認識されるまで、そ
れぞれの外部オブジェクト・リクエスト・ブローカに対
応するプロキシー・オブジェクトをそれぞれが生成す
る、一連のプロキシー・マネージャに繰返し要求を渡
す、プロキシー・マネージャ・オブジェクトのマネージ
ャを更に具備する、請求項１０に記載のネットワーク。
【請求項１２】前記プロキシー・オブジェクトが、一
連のプロキシー・マネージャにより生成される、請求項
１０に記載のネットワーク。
【請求項１３】プロキシー・マネージャのマネージャ
及び一連のプロキシー・マネージャが常駐する、ゲート
ウェイ・コンピュータ・システム上の第３のアドレス空
間を更に具備し、第１のコンピュータ・システム、第２
のコンピュータ・システム、及びゲートウェイ・コンピ
ュータ・システムがネットワークにより一緒に結合され
る、請求項１１に記載のネットワーク。
【請求項１４】ネットワークであり、（ａ）第３のアドレス空間中に、認識するプロキシー・
マネージャにより生成されたゲートウェイ・プロキシー
・オブジェクトを更に具備し、（ｂ）前記第１のアドレス空間に生成されたプロキシー
・オブジェクトが要求者プロキシー・オブジェクトであ
り、且つ要求者からゲートウェイ・プロキシー及びター
ゲット・オブジェクトへの通信が要求者プロキシー・オ
ブジェクトを介して設定される、請求項１２に記載のネ
ットワーク。
【請求項１５】ネットワークであり、（ａ）第３のアドレス空間内のプロキシー・マネージャ
のマネージャに第２の要求を渡す第４のアドレス空間内
の外部要求者と、（ｂ）ネットワークに結合されたコンピュータ・システ
ムの第５のアドレス空間に共に存在する、第２の外部オ
ブジェクト・リクエスト・ブローカ、及び第２の要求の
ターゲット・オブジェクトと通信する、一連のプロキシ
ー・マネージャの１つにより第３のアドレス空間に生成
された第２のプロキシー・オブジェクトとを更に具備す
る、請求項１２に記載のネットワーク。