JP5085831B2 - リクエストの集中及びロードバランシングのためのシステム及び方法 - Google Patents

Description

【０００１】
著作権通告
本明細書の一部は、著作権保護を受ける内容を含んでいる。著作権者は、特許明細書又は本発明開示のファクシミリ再生を、何人が行なうことも、それが、特許庁のファイル又は記録に現れる場合においは、なんら異議を有さないが、それ以外の場合には、如何なる場合も、全ての著作権を保有する。
【０００２】
本出願の特許請求の範囲は、西暦２０００年７月２７日付け米国特許出願第６０／２２１，０５７号であり、本明細書で参照される、仮出願「リクエスの集中及びロードバランシングのためのシステム及び方法」の優先権を主張する。
【０００３】
【産業上の利用分野】
本発明は、分散型コンピューティング環境に一般的に関する。特に、インターネットインターＯＲＢプロトコル（ＩＩＯＰ）環境内のオブジェクトリクエストブローカ（ＯＲＢ）の数を減少するためのシステム及び方法に関する。
【０００４】
【発明の背景】
分散型コンピューティングの分野において、マシンが互いに通信すること、又はマシンが、複数の分散型又はネット集中型アプリケーションを共有することを可能にするサーバアーキテクチャが存在する。これらアプリケーションの一つは、共通のオブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ）を含む。ＣＯＲＢＡは、オブジェクトコンピューティングで使用するための開発基準に向けられた独立グループであるオブジェクト管理グループ（ＯＭＧ）によって開発されたアーキテクチャデザイン仕様である。ＣＯＲＢＡ迎合システムの例は、ネットスケープＯＮＥ製品、及びＢＥＡシステムウェブロジックエンタープライズサーバを含む。
【０００５】
ＣＯＲＢＡは、インタフェース定義言語（ＩＤＬ）に対する仕様を提供する。この言語は、ソフトウエア開発者が、標準的な方法でそれらのオブジェクト指向アプリケーションに対するインタフェースを定義することを可能にする。ＩＤＬは、ＩＤＬの定義及び形態（タイプ）がＣ、Ｃ＋＋及びＪａｖａ（登録商標）を含む種々のプログラミング言語にマップされることを可能にするマッピングを含む。従って、ＣＯＲＢＡは、オリジナルプログラミング言語に独立してインタープリトされることができる「トランスペアレント」型アプリケーションを開発者が作り出すことを可能にする。開発者及び第三者のベンダーは、オブジェクトリクエストブローカ（ＯＲＢ）を介して他のオブジェクトと対話するオブジェクトを生成する。言語マッピングを使用して、開発者は、ＯＲＢが理解できるクライアント側「スタブ」及びサーバ側「スケルトン」を作り出すことができる。
【０００６】
ＣＯＲＢＡ２.０から、ＣＯＲＢＡ仕様は、ＯＲＢが互いにシームレスに通信することを可能にする方法を含んでいる。ＯＲＢの相互運用性アーキテクチャ、又はより詳細には、総称インターＯＲＢプロトコル（ＧＩＯＰ）基準は、ＯＲＢがネットワークに渡って作る一組のメッセージリクエストを定義する。ＧＩＯＰの種々のフレーバが存在し、各々は、特定のネットワーク送信に必要のことに対して調整される。ＯＭＧによって定義されたＧＩＯＰは３つの構成要素からなる。
【０００７】
共通データ表現 − ネットワークエージェント間で使用するための低レベル形態にＩＤＬ形態をマッピングする転送シンタックス。
【０００８】
ＧＩＯＰメッセージフォーマット − クライアントリクエスト、サーバリプライ（応答）、クライアントキャンセルリクエスト、クライアント位置決めリクエスト、サーバ位置決めリプライ、サーバクローズ接続、及びメッセージエラーを含む現在７つのフォーマットがある。
【０００９】
ＧＩＯＰメッセージ伝送前提 − 伝送は、接続指向であり、信頼性があり、バイトストリームと見ることができ、障害による接続損失に付いて理由のある通知を与え、そして、接続を開始するための転送モデルをＴＣＰ／ＩＰの一般的な接続モデルにマップすることができることを含む。
【００１０】
全てのＯＲＢが仕様によって使用することが出来る必要がある共通のＧＩＯＰ実装は、インターネットインターＯＲＢプロトコル（ＩＩＯＰ）である。ＩＩＯＰはＧＩＯＰメッセージをＴＣＰ／ＩＰにマップし、ＯＲＢがＴＣＰ／ＩＰネットワーク、例えば、インターネットを、通信バス又はバックボーンとして使用することを可能にする。図１のピラミッド構造を参照する。ピラミッドの最下位レベルに物理装置、例えば、ＭＡＣ（メディアアクセスコントロール）アドレスを有するイーサネット（登録商標）カードが存在する。この上に、イーサネット（登録商標）プロトコルが位置しており、これは、接続ベースのブロードキャストトポロジーを提供し、ここで、メッセージがコード化され、且つ衝突が解消される。次の層は、インターネットプロトコル（ＩＰ）であり、これは、インターネットを横断するパケットのフォーマットを特定し、且つ、ホストネーム及びＩＰアドレスをサポートする。ホストネームはＩＰがルート指定されることを可能にする。ＩＰの上は、伝送制御プロトコル（ＴＣＰ）であり、ポート番号及びパケットセグメント化及び存続時間の様な制御指令の機能を加える。これは、信頼性のある、ストリームベースの配送を可能にする。ＩＩＯＰはＴＣＰ上に構築される。ＩＩＯＰ上に、ＯＲＢレベルが位置し、これは、ＩＩＯＰリクエストをマーシャル（結集）する。ピラミッドの頂部には、アプリケーションレベル自体があり、これはオブジェクト実装及び他のＯＲＢオブジェクト、及びネーミングサービスの様なサービスを含む。
【００１１】
上述され且つ図２に更に示される様な分散型オブジェクトシステムにおいて、リクエスト５０はオブジェクトファンクション４２、４４、４６、４８を要求するプロセスとオブジェクトファンクション５２、５４、５６、５８を実施するプロセスとの間を行き来する。図２の例は、ｍ個のサーバに呼び掛けを行なうｎ個のクライアントを示す。この様なシステムでは、ｎ×ｍ個の接続が存在する場合に拡張性を達成することが困難である。ここで、ｎは一群のオブジェクトファンクションを要求するプロセスを表し、ｍはこの一群のオブジェクトファンクションを実施するプロセスを表している。このことは、「ファンナウト問題」として一般的に知られており、システムリソースが拡張性を可能にするのに十分であることを保証するのを困難する。コンセントレータプロセスを介してＩＩＯＰ／ＯＲＢドメイン又はオブェクト実装のグループへの要求が集中することを可能にする技術が存在する。この問題は、ドメイン内のオブジェクト実装からそのドメイン外の他のオブジェクト実装へ、反対方向に進んで、どの様にして拡張性を達成することが出来るかということである。
【００１２】
【発明の要約】
オブジェクトシステムにおける拡張性の問題に着目すると、本発明の実施の形態は、ネイティブクライアント及びネイティブクライアントとして活動するサーバが、リモートオブジェクトリファレンスに呼び掛けを行なうことを可能にする。リモートオブジェクトリファレンスに呼び掛けを行なうために必要な能力としては、拡張性、耐久性、外部のＯＲＢサーバに実装されるオブジェクトリファレンスへの呼び掛けを実施する機構として利用可能であり、リモートクライアントに実装される呼び掛け（クライアントコールバック）を実施する機構として利用可能であり、及びイベントをリモートクライアントに送る呼び掛けを実施する機構として利用可能であることがある。
【００１３】
本発明の一解法及び実施の形態は、ドメイン内からそのドメイン外部へ行くリクエストに対してインテリジェントコンセントレータプロセスを利用することにある。一つ以上のマスタープロセスは、リクエストを実際に取り扱うサブプロセスへ向かうリクエストをロードバランスする様に構成されている。マスタープロセスは、ロード（負荷）によって要求されると、サブプロセスを動的に加えることができる。更に、ドメイン内からの複数のリクエストが、そのドメイン外のオブジェクト実装へのリクエストに対して同じ実際の接続を使用することを保証することによって、マスタープロセスが、集中を許容することができる。これらのマスタープロセスの多重性は、マスタープロセスが死んだ場合の、故障復旧及び障害回復性を可能とする。
【００１４】
本発明の実施の形態は、ネイティブクライアント、及びクライアントとして機能するネイティブサーバの両方が、その実装がインターネットインターＯＲＢプロトコル（ＩＩＯＰ）ドメイン外に存在するオブジェクトリファレンスに呼び掛けを行なうことを可能にする。これは、リモートクライアントがイベントを受信し、リモートクライアントがコールバックを受信し、且つネイティブクライアント及びクライアントとして機能するサーバが、その実装がオブジェクトリクエストブローカ（ＯＲＢ）で構築されたリモートサーバ内のオブジェクトリファレンスに呼び掛けを行なうことを可能にする下層機構を提供する。
【００１５】
好適な実施の形態の詳細な記述
本発明の種々の実施の形態が、添付図面を参照して記述される。数々の定義が以下に与えられており、これらは、好適な実施の形態の議論に有効である。
クライアント／サーバ − クライアント又はサーバの何れか、又は両方として活動することができるマシン又はプロセス。
ドメイン − ユニットとして管理することができるマシン及びリソースの集まり。ドメインは、アプリケーションファンクション、セキュリティの必要性、又は、地理的位置に基づいて設定することができ、複数のアプリケーションが相互通信する状況で特に有用である。
ネイティブ − ドメイン内のクライアント又はサーバ。
コールバック − ＩＩＯＰリクエストがリモートクライアント内のオブジェクト実装に与えられる様に、（サーバとして機能する）リモートクライアントによって生成されたオブジェクトリファレンスに呼び掛けを行なう能力。
コールアウト − 或るリモートサーバに対するオブジェクトリファレンスを得、リクエストがリモートサーバに送られる様にそのオブジェクトリファレンスに呼び掛けを行なう能力。コールアウトはサーバとして機能するリモートクライアントに向かうもの（コールバック）又はリモートＯＲＢサーバへの向かうものとすることができる。
ＩＳＨ（ＩＩＯＰサーバハンドラ） − ＩＩＯＰメッセージをリモートクライアントから受信し、これをトンネルＧＩＯＰ（ＴＧＩＯＰ）メッセージとしてネイティブ（又はドメイン内）サーバに転送する構成を特に意味している。この構成要素は、リプライも受信し、それが適当なリモートクライアントに戻されることを確認する。本発明の一実施の形態において、ＩＳＨはネイティブクライアント／サーバからＴＧＩＯＰリクエストメッセージも受信し、ＩＩＯＰリクエストメッセージをリモートサーバに送る。この構成要素は、このリプライを受信し、それが適当なネイティブクライアント／サーバに戻されることを確実にする。
【００１６】
ＩＳＬ（ＩＩＯＰ サーバリスナー） − どのＩＳＨが、ネイティブサーバと特定のリモートクライアントとの対話を、扱うべきかを決める構成要素を意味する。ＩＳＬがＩＳＨに対する故障復旧及びネイティブオブジェクトへの接続のロードバランシングを扱う。本発明の或る実施の形態において、ＩＳＬは、ＩＳＨに接続されたクライアント内に位置していないオブジェクトリファレンスに対するリモートサーバとの特定の対話をどのＩＳＨが扱うかも決める。ＩＳＬは、同じリモートオブジェクトへの多重の呼び掛けに対する接続を集中する。
インバウントＩＩＯＰ − リモートサーバからドメイン内のネイティブクライアントへのＩＩＯＰリクエストを初期化することを示す従来技術で知られている概念。
アウトバウンドＩＩＯＰ − ドメイン内のネイティブクライアント、又はクライアントとして機能するサーバからそのドメイン内に無いリモートサーバへのＩＩＯＰリクエストを初期化する本発明の方法を意味している。
非対称ＩＩＯＰ − ＧＩＯＰの或るバージョンにおいて、ＩＩＯＰ接続は非対称、具体的には、クライアントのみがリクエストを送ることができ、サーバのみがそれらを受信することができる。サーバがリクエストをクライアント内のオブジェクトに送る必要がある場合、サーバからクライアントへの第２の接続を生成する必要がある。
双方向ＩＩＯＰ − クライアントとサーバとの間の接続が対称である。即ち、クライアントは、リクエストを接続上のサーバに送ることができ、サーバは、同じ接続上のクライアントによって輸出されたオブジェクトに、リクエストを送ることができる。
【００１７】
ＩＩＯＰ集中
図３は、本発明の典型的な集中プロセスを示す。現在のシステムは、インバウンドＩＩＯＰ集中用にのみ提供されているが、本発明は、アウトバウンドＩＩＯＰ集中用のサポートを追加する。図３に示される様に、ＩＳＨコンセントレータ６６は、複数のローカルクライアントからの接続を「集中」して、リモートクライアント／サーバ７０に要求される接続の数を減少して、単一サーバリンク６８に渡って動作する。幾つかのクライアントは、ＩＳＨと同じドメイン内に含まれ、プロセス間通信によって互いに通信する。ドメイン外のクライアント／サーバ（リモートクライアント／サーバ）は標準ＴＣＰ／ＩＰリンクを介してＩＳＨと通信する。
【００１８】
図４に図示される様に、本発明のＩＳＨコンセントレータの実施の形態は、図２に示されるシステムの拡張性を改良するのに使用される。ＩＳＨ９０は、アクティブな接続の数をｎ×ｍ個からｎ＋ｍ個に減少する。本発明の実施の形態において、メッセージキューは、直接リンクをリモートサーバに置き換えるために使用され、これは、アクティブな接続の数を丁度ｎ個に減少する。
【００１９】
アウトバウンドＩＩＯＰサポート
本発明の一つの実施の形態を含む例示的システムが図５に示される。図示される様に、幾つかのクライアントが一連のリモートサーバに呼び掛けを行なう。クライアントは、例えば、ネイティブＣ＋＋クライアント１０２、Ｊａｖａ（登録商標）クライシント１０４、通知サーバ１０６、又はクライアント１０８として機能するネイティブサーバとすることができる。リモートサーバは他のネイティブサーバ１１０、イベントに対して登録されたネイティブクライアント１１２、又は、非ネイティブＣＯＲＢＡ迎合ＯＲＢサーバ１１４とすることができる。クライアントの一つが、サーバに呼び掛けを行う時、ルーティングプロセスは、ＢＩＮＤサーバ１２２を呼ぶことにより、接続をＩＳＬに向ける。どのＩＳＨ１３０、１３２、又は１３４が接続を取り扱うのに最も好適であるかをＩＳＬは決定する。少なくとも一つのＩＳＨが従って要求されるが、多くのＩＳＨを使用することができる。何れのＩＳＨが宛て先サーバへの接続を現在取り扱っているかを先ずチェックして知り、ＩＳＬはそれへの接続を取り扱うＩＳＨを決定する。いずれもがこの様な接続を現在扱っていない場合、最小負荷のＩＳＨが選択される。この仕方で、ＩＳＬは、全ての利用可能なＩＳＨ間で増大する数の接続のロード（負荷）をバランスする様機能する。
【００２０】
ＩＳＨが選択されると１２６、クライアントは従ってそのＩＳＨ１２８を介してサーバに呼び掛けを行なう。クライアント及びＩＳＨは同じドメイン内にあり、それらは、トンネル化ＧＩＯＰ（ＴＧＩＯＰ）１３６を使用して、通信することができる。ＩＳＨは、ＴＣＰ／ＩＰ１３８を介してＩＩＯＰを使用して、ドメイン外のサーバと通信する。
【００２１】
本発明の実施の形態であるアウトバンウンドＩＩＯＰサポートは、ネイティブクライアント及びネイティブクライアントとして機能するサーバに、ドメインの外のリモートオブジェクトリファレンスに呼び掛ける能力を提供する。このことは、イベントが、イベントに対して登録されたリモートクライアントへ流れることができ、コールバックをリモートクライアントに対して行なうことができ、且つリモートサーバ内のオブジェクトにアクセスすることができることを意味している。
【００２２】
ＩＳＨに接続されたクライアントに含まれるオブジェクトに対する双方向ＩＩＯＰのサポート リモートＯＲＢが双方向ＧＩＯＰ１.２をサポートする場合、ＩＳＨは、接続されたクライアントとの間で、リクエストを送り且つリプライを受信するために同じ接続を利用することができる。
【００２３】
ＩＳＨに接続されたクライアントに含まれるオブジェクトに対する双方向様ＩＩＯＰのサポート ＯＲＢが双方向ＧＩＯＰ１.２をサポートしない場合、クライアントは、アプリケーションプログラムインタフェース（ＡＰＩ）を呼出して、クライアント内のリスニングホスト／ポートをＩＳＨに通知する。ＩＳＨは、第２の対にされるアウトバウンド接続を利用して、リクエストを接続されたクライアントに送り、且つこれからリプライを受信する。このアウトバウント接続は、入力（着信）接続と対にされる。クライアントがこの入力接続を切断する場合、アウトバウンド接続も同様に切断される。
【００２４】
ＩＳＨ又はネイティブクライアントに呼び掛けを行なうためのサポート このインフラストラクチャーは、クライアント情報に基づいて、ＩＳＨ又はネイティブクライアントへのルート決めをサポートする。ＯＲＢは、クライアント識別子情報をオブジェクトリファレンスに埋め込むように修正される。
【００２５】
ＩＳＨに接続されるクライアント内に含まれないオブジェクトに対する非対称アウトバウンドＩＩＯＰのサポート ＩＳＬは、同じリモートサーバに向かう異なるネイティブクライアント／サーバからのリクエストが同じ接続を介する集中を可能にする。ＩＳＬは、特定の接続が過大の負荷を得ない様にリクエストのロードバランスを行なうことを可能にする。
【００２６】
拡張性をサポートするために、ＩＳＬは、必要な時に追加ハンドラをスタートすることができる。そして、追加のＩＳＬ及び追加のＩＳＨを、増大したアウトバウンドＩＩＯＰトラフィックをサポートするように必要な時に加えることができる。
【００２７】
フレーバをサポートするために、複数のＩＳＨが、マシン上で、又はドメイン内でスタートアップすることができる。クライアントがＩＳＨを使用する試みが失敗する場合、オブジェクトリファレンス及びフレーバを他のＩＳＨに再バインドする試みが成される。
【００２８】
本発明の実施の形態の典型的な環境においては、システム管理者を、アウトバウンドＩＩＯＰサポート構成要素と直接相対話する唯一のユーザとすることができる。彼らは、正しいスタートアップパラメータで、ＩＳＬをブートして、オブジェクトに対するアウトバウンドＩＩＯＰが、接続されたクライアント内に位置しなくすることができる。ブートされたＩＳＬの数、及び種々のスタートアップパラメータは、インストール特定の仕事量の特徴に対して最も良い構成を得る様に、調整することができる。
【００２９】
アウトバウンドルーティング
アウトバウンドルーティングプロセス内の機能的特徴は、図６−９に示される。図６に示される様に、ＩＳＬ１６０及びＩＳＨ１６８（幾つかが例示目的のために示されているが、システムは一つのみのＩＳＨで作動することができる）は共有メモリ１６６を介して互いに通信する。本発明の或る実施の形態において、ＩＳＬは、リモートサーバへの接続に付いての情報を維持するための責任を有している。この様な接続の記録は、共有メモリ内に保持されている。ＩＳＨは、この情報を使用して、リモートサーバに呼び掛けを行なう。代わりに、ＩＳＨは、閉鎖又は破壊された接続を反映するために情報を更新することによって、共有メモリ内の情報をメンテナンスする。ＩＳＬは、更新された情報を次に使用して、呼び掛けに対する入力リクエストを旨く割り当てる。リモートサービスへの呼び掛けを求めるクライアントは、ルーティングコードを呼ぶ。ルーティングコードは、接続が既に存在するかを決めるために、ＩＳＬと対話する。もし、存在する場合は、情報を各ＩＳＨに受け流す。接続がまだ存在しない場合、ＩＳＬは新たな接続をサービスするＩＳＨを選択する。
【００３０】
図７は、ＩＳＬ１６０が、クライアントに対して広告するか又はクライアントに対して利用可能にするサービスの幾つかを示す。原理的に、クライアントは、ＩＳＬからのＢＩＮＤ（バインド）１６１又はＵＮＢＩＮＤ（アンバインド）１６２に対するルーティングコードを介して、要求を行なうことができる。エラールーチン１６３は、失敗した要求を扱うことができる。図８に示される様に、ルーティングコード１８０は、リモートサーバを考慮して、使用するのに適当なＩＳＨ１８８を決定するＩＳＬ１８４のＢＩＮＤに呼び掛けを行なう１８２。ＩＳＬ１８４は、この情報をクライアントに戻す１８６。この後、クライアントは特定されたＩＳＨに呼び掛けを行なう１８７。その後ＩＳＨはクライアントとサーバとの間での通信を扱う。図９に示される様に、クライアントがサーバインスタンスで終了するか１９０、又は、接続が切断されることが要求される時、アプリケーションはＩＳＬ１９４のＵＮＢＩＮＤに呼び掛けを行なう１９２。ＩＳＬは次に接続が切断したことを記録する１９６。一定期間の後、特定の接続に対するエントリがガーベッジコレクションプロセス中に共有メモリから除去される。
【００３１】
アウトバウンドＩＩＯＰ形態
３つの異なる形態のアウトバウンドＩＩＯＰ
・ 同じ接続を再使用する双方向アウトバウンドＩＩＯＰ
・ 第２の対にされる接続を介する双方向様アウトバウンドＩＩＯＰ
・ 第２の接続を介する非対称アウトバウンドＩＩＯＰ
【００３２】
双方向アウトバウンドＩＩＯＰ
本発明の実施の形態は、ＩＳＨ（図１０）に接続されるクライアント内に含まれるオブジェクトに対する双方向ＩＩＯＰに対するＩＳＬ／ＩＳＨ２２４、２２６、２２８を含む。クライアントＯＲＢが双方向ＧＩＯＰ１.２をサポートする場合、ＩＳＨは、接続されたクライアントへリクエストを送り、これからリプライを受信するために同じ接続を利用する。クライアント２２２は、オブジェクトリファレンスを生成して、ネイティブサーバに呼び掛けを行なう。クライアントＯＲＢは、接続がサービスコンテクストを使用する双方向であると識別する。サービスコンテクストは、メッセージと共にネイティブサーバ２３６に伝達する。オブジェクトリファレンスをマーシャル（結集）する時、ネイティブサーバは、サービスコンテクスト内のホスト／ポートをオブジェクトリファレンス内のホスト／ポートと比較する。それらが一致する場合、ＯＲＢは、ＩＳＨクライアント識別子及びルートを付けるのに必要な他のクライアント情報をオブジェクトリファレンス内のタグが付けられた構成要素に加える。このクライアント情報は、それが他のネイティブサーバに通過される時は常に、オブジェクトリファレンスと共に伝達する。
【００３３】
或るポイントにおいて、ネイティブサーバ又はネイティブクライアントはオブジェクトリファレンスに呼び掛けを行なう。ルーティングコードは、クライアント情報に与えられた適当なＩＳＨに呼び掛けを行なう。ＩＳＨは同じクライアント接続に渡ってリクエストをクライアントに送る。クライアントはこの方法を実行し、リプライをクライアント接続を介してＩＳＨに戻す。ＩＳＨはリプライを受信し、これをネイティブサーバに送る。
【００３４】
対にされる第２接続を介するアウトバウンドＩＩＯＰ
本発明は、ＩＳＨに接続されるクライアントに含まれるオブジェクトへの双方向様ＩＩＯＰに対するＩＳＨサポートを含む（図１１）。クライアントＯＲＢが双方向ＧＩＯＰ１.２をサポートしない場合、クライアントはＡＰＩルーチンを呼出して、ＩＳＨにクライアント内のリスニングポートを通知する。ＩＳＨは次に別の対にされるアウトバウンド接続を生成して、接続されたクライアントにリクエストを送り且つこれからリプライを受信する。
【００３５】
クライアントは、オブジェクトリファレンスを生成する。クライアントは次に、オブジェクトリファレンスを通してブートストラップを呼び出す。ＩＳＨは、相互運用可能なオブジェクトリファレンス（ＩＯＲ）からホスト／ポートを得、これをクライアントコンテクストに記憶する。クライアントはオブジェクトリファレンスを通してネイティブサーバに呼び掛けを行なう。ＩＳＨは、レジスタコールからホスト／ポートを含むサービスコンテキストを生成する。このサービスコンテクストは、ネイティブサーバへメッセージを伴って伝達する。オブジェクトリファレンスをアンマーシャル（分離）する時、ネイティブサーバはサービスコンテクスト内ホスト／ポートをオブジェクトリファレンス内のホスト／ポートと比較する。それらが一致する場合、ＯＲＢはオブジェクトリファレンス内のタグが付された構成要素に、ＩＳＨ ｉｄとクライアント情報を加える。このクライアント情報は、これが他のネイティブサーバに通過される時は常に、オブジェクトリファレンスと共に伝達する。
【００３６】
或るポイントで、ネイティブサーバ又はネイティブクライアントは、オブジェクトリファレンスに呼び掛けを行なう。ルーティングコードは、クライアント情報を通して適当なＩＳＨに呼び掛けを行なう。ＩＳＨはクライアントに対して第２の接続を生成する。ＩＳＨは、第２の接続を介して、リクエストをクライアントに送る。クライアントは、メソッドを実行し、リプライをクライアント接続を介してＩＳＨに戻す。ＩＳＨはリプライを受信し、これをネイティブサーバに送る。クライアントはＩＳＨから切断され、第２の接続も同様に切断される。
【００３７】
非対称アウトバウンドＩＩＯＰ
本発明の実施の形態は、ＩＳＨに接続されたクライアント中に含まれないオブジェクトへの非対称アウトバウンドＩＩＯＰに対するＩＳＬ／ＩＳＨサポートも含む（図１２）。ＩＳＬは、異なるネイティブクライアント／サーバからのリクエストが、同じリモートサーバに向かい同じ接続を通過する集中を許容する。ＩＳＬは、特定の接続が過負荷にならない様に、リクエストの負荷バランスを考慮することができる。サーバ２８０は、或るソースからオブジェクトリファレンスを得るが、ソースはネームサーバであることができ、または、ソースはクライアントを通過することができるが、クライアント内に位置してはいない。オブジェクトリファレンスは、ＩＳＨに接続されたクライアント内に位置していないので、出力コールは、双方向方法を使用して、行なうことはできない。
【００３８】
或るポイントにおいて、ネイティブサーバ又はネイティブクライアントは、オブジェクトリファレンスに呼び掛けを行なう。第１の呼び掛けの際、オブジェクトリファレンスには、ＩＳＨ ｉｄも、クライアント情報も含まれない。ルーティングコードは、オブジェクトキーを非ネイティブサーバオブジェクトリファレンスとして認識する。ＩＳＨ ｉｄ及びクライアント情報が渡されない場合、ルーティングコードは、ホスト／ポートを通過してＩＳＬ２２４内のサービスを呼び出す。ＩＳＬは、オブジェクトリファレンスとＩＳＨ２７２のクライアント情報を切り離す（アンバインドする）のに使用するために、サービス名を戻す。このクライアント情報は、ＩＳＨのクライアント情報であり、ＩＳＨに接続された何れのクライアントのクライアント情報ではない。
【００３９】
ＯＲＢは、オブジェクトリファレンスに呼び掛けを行なう。インフラストラクチャーはＩＳＨに呼び掛けを行なう。ＩＳＨは、クライアント情報から接続識別子を得、リクエストをクライアントに送るのにどの外出接続を使用するかを決定する２２６。何も接続されていない場合、ＩＳＨは、別の接続をホスト／ポートに生成する。ＯＲＢは、ＩＯＲ内のＩＩＯＰプロファイルのバージョンに対する適当なバージョンのＧＩＯＰを利用する。クライアントは、その方法を実行し、別の接続を介してリプライをＩＳＨに戻す。ＩＳＨは、リプライを受信し、それをネイティブサーバに送る。
【００４０】
プロセス フロー
以下は詳細なプロセスフロー記述であり、本発明の一実施の形態において、どの様に、クライアント、ＩＳＬ及びＩＳＨが対話するかを説明している。
【００４１】
ネイティブクライアントの観点から
オブジェクトリファレンスバインド時に、ＯＲＢはオブジェクトリファレンスがリモートであるかを決定する。そうであれば、ＯＲＢは、オブジェクトリファレンスからのクライアント情報（もしあれば）で初期化される。クライアント情報が存在しない場合、ＢＩＮＤフラグが特定される。そうでない場合、フラグは特定されない。
【００４２】
ルーティングコードは、リモートオブジェクトリファレンスを有するか否かを決める。
ＢＩＮＤフラグが存在する場合、ＢＩＮＤサービスを呼出し、戻されたＩＳＨクライアント情報及びＩＳＬ情報を共有メモリ内に記憶する。
ＢＩＮＤフラグが存在しない場合、クライアント情報を共有メモリ内に記憶する。
ルーティングコードは、クライアント識別子に対する共有メモリ内を見、それに呼び掛けを行なう。
接続が破壊される時、システムは、適当なエントリに対する共有メモリ内を見、そして、ＵＮＢＩＮＤを呼び出す。
一方で、ＩＳＬは、接続は閉鎖であることを共有メモリに記し、ＩＳＨが接続を閉鎖する。
【００４３】
ＩＳＨの観点から
ＩＳＨがクライアントｉｄを使用して呼び出される。
ＩＳＨがメッセージキューからメッセージを受信する。リクエストが、リプライに対して逆の方法で取り扱われる。
【００４４】
インフラストラクチャーは、ＩＳＨをクライアントに基づいた適当なコンテキストに切り換える。非対称アウトバウンドＩＩＯＰの場合、コンテキストはＩＳＨコンテキスト（０）であり、クライアントコンテキストではない。
【００４５】
ＩＩＯＰリクエストのコピーが作られ、ＩＩＯＰリクエストｉｄがユニークなｉｄで置き換えられる。リクエストは、このコンテキストに対する未処理のリクエストのリストに置かれる。
【００４６】
コンテキストがクライアントコンテキストである場合、コンテキストは双方向接続又は対にされる第２接続を有する。対にされる第２接続及び双方向接続がまだ存在しない場合は、一つの接続が生成される。ＩＩＯＰリクエストをクライアントに送るためにルーチンが呼び出される。接続が完了するまで、ルーチンがリクエストをバッファ記憶する。ＩＩＯＰリクエストをクライアントに送るためにルーチンが呼び出される。
【００４７】
コンテキストがＩＳＨコンテキストである場合、接続インデックスがアウトバウンド接続を決めるために使用される。接続が存在しない場合、一つの接続が生成される。ＩＩＯＰリクエストをクライアントに送るためにルーチンが呼び出される。接続完了されるまで、ルーチンはリクエストをバッファ記憶する。接続が存在する場合、ＩＩＯＰリクエストをクライアントに送るためにルーチンが呼び出される。
【００４８】
ＩＳＨがネットワーク及びメッセージキューイベントを取り扱う。リプライが接続から戻る時、未処理リクエストのリストが対応するリクエストに対して検索される。ＩＳＨはユニークなｉｄをオリジナルｉｄで置き換え、リプライをクライアントに送る。
【００４９】
ＩＳＬの観点から
ＩＳＬは、オブジェクトリファレンスへの第１の呼び掛けで呼び掛けられる。
サービスルーチンは、オブジェクトリファレンスをバインドするために呼び出される。パラメータは、ホスト、ポート及びクライアント識別子である。
ＩＳＬはホスト／ポートをハッシュし、ホスト／ポートが既に使用されているか否かを決定するためにデータ構造内を見る。使用中であり、且つ多重ユーザ制限にない場合、適当なＩＳＨクライアント識別子、ドメイン、クライアントプロセス識別子、クライアントキュー、ＩＳＬグループ及びサーバ識別子が戻される。
ユーザ多重化リファレンスカウントが増加される。
見出せず且つ現存するＩＳＨが接続を取り扱うことができる場合、現存するＩＳＨはリクエストを取り扱うように割り当てられる。適当なＩＳＨクライアントｉｄ、ドメイン、クライアントプロセス識別子、クライアントキュー、ＩＳＬグループ及びサーバ識別子が戻される。
ＩＳＨが接続を取り扱うことができない場合、新たなＩＳＨがスタートされる。
適当なＩＳＨクライアント識別子、クライアントプロセス識別子、クライアントキュー、ＩＳＬグループ及びサーバ識別子が戻される。
【００５０】
接続管理
接続管理は、クライアントとサーバとの間の接続を扱うためのプロセスであり、特に、現在使用されていないと評価した接続をどの様にしてシステムが扱うかのプロセスである。
【００５１】
本発明の目的の一つは、拡張性である。従って、アウトバウンド接続の数を最少にすることが望まれる。この理由のために、接続されているクライアント内に含まれるオブジェクトへの有効な機構に呼び掛けをおこなわせるために、システムは、双方向接続及び対にされる第２の接続をサポートする。これらの場合は、アウトバウンドＩＩＯＰトラフィックの大部分を含む。しかしながら、何処の顧客が、現在接続されているクライアントには含まれないオブジェクトリファレンスに呼び掛けを行なうことを望んでいるかのシナリオが依然として存在する。これは、外のＯＲＢサーバ；ネイティブドメインに接続され且つこれから切断されるクライアント／サーバ、又はネームサーバから得られる何らかのオブジェクトリファレンスとすることができる。オブジェクトリファレンスのこれらの形態をサポートするが、依然として拡張性を与えるために、システムは、これらのＴＣＰ／ＩＰ接続を呼出し側プロセスからＩＳＨへ再配置する。呼出し側（ネイティブクライアント又はネイティブサーバ）はＩＯＲに呼び掛けを行なう、ネイティブインフラストラクチャーがメッセージをＩＳＨに送るのに使用される。ＩＳＨは次にメッセージをＴＣＰ／ＩＰ接続を使用して、リモートサーバに送る。しかしながら、ＴＣＰ／ＩＰ接続が、最早実際の呼出し側プロセス内にないので、それらは、呼出し側（ネイティブクライアント又はネイティブサーバ）が存在する時には、自動的に切断されない。
【００５２】
（如何なる呼出し側によっても現在使用されていない）非対称アウトバウンドＩＩＯＰ接続は、呼出し側（ネイティブクライアント又はネイティブサーバ）が存在する場合は、切断されるべきである。これは、最後の呼出し側が存在した直後又はタイムアウト期間の後とすることができる。非対称アウトバウンドＩＩＯＰを管理するための異なる代替例が、以下のセクションに記述される。
【００５３】
リファレンスカウンティグ及びユーザ確認
この代替例は以下の様に作動する。
ネイティブクライアント又はネイティブサーバ（オブジェクトリファレンスのユーザ）は、オブジェクトリファレンスに呼び掛ける。
第１の呼び掛けで、ＯＲＢはＩＳＬ内のＢＩＮＤサービスにコール（呼出し）を行なう。このホスト／ポートに対するエントリが、共有メモリに加えられる。ユーザの識別子に対するエントリ（ネイティブクライアント識別子又はネイティブサーバグループ／サーバｉｄ）が共有メモリに加えられる。ＩＳＬは接続識別子（共有メモリ内のホスト／ポートエントリに対するマップ）及びリモートサーバへのＴＣＰ／ＩＰ接続を含むＩＳＨに対する適当なクライアント情報を戻す。
【００５４】
ＯＲＢは、クライアント情報を使用して、メッセージを適当なＩＳＨに送る。ＩＳＨは、接続識別子を使用して、どのアウトバウンドＩＩＯＰ接続が使用されるかを決定する。
ネイティブクライアント又はネイティブサーバは、オブジェクトリファレンスへの呼び掛けを達成する。各呼び掛けは、ＩＳＨに送られるメッセージをもたらす。
【００５５】
他のネイティブクライアントが、同じホスト／ポートエントリを有するオブジェクトリファレンスに呼び掛けを行なう場合、ＢＩＮＤは、第１のユーザと同じ接続識別子及び同じクライアント情報を戻す。ホスト／ポートのリファレンスカウントが増加される。第２のユーザ（ネイティブクライアント又はネイティブサーバ）の識別子に対するエントリが共有メモリに加えられる。
【００５６】
最終的に、第１及び第２ユーザはオブジェクトリファレンスを解放する。第１のユーザ解放はＵＮＢＩＮＤサービスへのコールである。ＵＮＢＩＮＤサービスは、ホスト／ポートエントリのリファレンスカウントを減少し、ユーザの識別子を除去する。第２のユーザ解放の際に、ホスト／ポートエントリのリファレンスカウントがゼロに減少される。ＩＳＬは、共有メモリからホスト／ポートエントリを除去し、（ホスト／ポートエントリとは異なる）接続エントリが閉鎖であることを共有メモリに記す。
【００５７】
ＩＳＨは、それが、共有メモリに接続エントリは閉鎖であると記されていることを知った時に、接続を閉鎖する。
ＩＳＨは接続エントリが未使用であると記す。
【００５８】
これは、ユーザが通常通り退出し且つオブジェクトリファレンスを解放する場合である。この場合は、オブジェクトリファレンスを解放することなしに退出するユーザ、及び、異常で退出するユーザを含む。最早必要の無い場合に、接続が解放されることを保証するために、この代替例は確認を使用する。その確認では、ＩＳＬは、接続のユーザの識別子を確認し、共有メモリ内にｉｄを記憶し、サーバが非アクティブであるかをチェックし、サーバが、ローカルマシン上にある場合に、ＩＳＬはタイムスタンプを比較して、ネイティブクライアントが依然として活動しているかを調べ、ローカルマシン上にない場合は、ネイティブクライアントがＩＳＬと同じマシン上にないことを確認するためにコールを使用する。
【００５９】
アンバインド（解放）を有さない非対称アウトバウンド接続タイムアウト
この代替例は、以下の様に作動する。
ネイティブクライアント又はネイティブサーバ（オブジェクトリファレンスのユーザ）はオブジェクトリファレンスに呼び掛ける。
【００６０】
第１の呼び掛けで、ＯＲＢは、ＩＳＬ内のＢＩＮＤサービスを呼び出す。このホスト／ポートに対するエントリは、共有メモリに加えられる。ＩＳＬは、接続識別子（共有メモリ内のホスト／ポートエントリ＋追加のジェネレーション／タイムスタンプフィールド）及びリモートサーバへのＴＣＰ／ＩＰ接続を含むＩＳＨに対する適当なクライアント情報を戻す。
【００６１】
ＯＲＢは、クライアント情報を使用して、メッセージを適当なＩＳＨに送る。ＩＳＨは、接続識別子を使用して、どのアウトバウンドＩＩＯＰソケットを使用するかを決める。（接続タイムアウトのために）接続識別子は最早有効ではなく、エラーが戻される。
【００６２】
ネイティブクライアント又はネイティブサーバが、連続して、オブジェクトリファレンスへの呼び掛けを達成する。各呼び掛けはＩＳＨに送られるメッセージを結果としてもたらす。
【００６３】
別のネイティブクライアントは、同じホスト／ポートでオブジェクトリファレンスに呼び掛けを行なう場合、ＢＩＮＤサービスは、第１の呼び掛けと同じ接続識別子及び同じクライアント情報を戻す。リファレンスカウンティングは、ホスト／ポートエントリで達成される。
【００６４】
最終的に、第１及び第２のユーザは、オブジェクトリファレンスを解放する。アンバインドサービスは呼び出されない。接続は、維持される。
【００６５】
各呼び掛けで、ＩＳＨは、接続のための共有メモリ内の活動タイムスタンプフィールドを更新する。通常ベースでは、ＩＳＬは、活動がユーザ特定の時間期間内で生じない場合、接続をタイムアウトする。ＩＳＬはその接続は閉鎖であると記し、ホスト／ポートエントリを除去する。ＩＳＨは、それが、接続が閉鎖されると記されていることを知ると、接続を切断する。ＩＳＨは、接続エントリに未使用であると示す。接続のユーザが死ぬか又はオブジェクトリファレンスを解放しない場合、接続は、それがアクティブである限り維持される。接続が特定の時間期間アクティブで無いと、その接続が切断される。オブジェクトリファレンスは依然として有効であるが、特定のタイムアウト期間内では使用されない場合がある。この場合、接続は切断され、ホスト／ポートエントリは除去される。ＩＳＨはリクエストを受信し、接続ｉｄを確認し、且つエラーを戻す。このエラーはＯＲＢにオブジェクトリファレンスを再バインドさせる。これは、ＩＳＬ ＢＩＮＤサービスへコールを呼び掛け、現存する接続が使用されるか、又は新たな接続を生成することができる。この再バインドはユーザに可視的である必要はない。
【００６６】
非対称アウトバウンド接続タイムアウトを有するリファレンスカウント
これは、代替例１及び２の組合せである。主な差異は、誰も接続を使用していないと、その接続が直ちに切断される点にある。
この代替例は以下の様に作動する。
【００６７】
ネイティブクライアント又はネイティブサーバ（オブジェクトリファレンスのユーザ）は、オブジェクトリファレンスに呼び掛けを行なう。
第１の呼び掛けの際に、ＯＲＢは、ＩＳＬ内のＢＩＮＤサービスを呼び出す。このホスト／ポートに対するエントリが共有メモリに加えられる。ＩＳＬは接続識別子（共有メモリ内のホスト／ポートエントリへのマップ＋追加のジェネレーション／タイムスタンプフィールド）及び適当なＩＳＨｉｄ及びクライアント情報を示す。この情報は、リモートサーバへのＴＣＰ／ＩＰ接続を含む。
【００６８】
ＯＲＢは、ＩＳＨｉｄ及びクライアント情報を使用して、メッセージを適当なＩＳＨに送る。ＩＳＨは、接続識別子を使用して、使用するアウトバウンドＩＩＯＰ接続を決める。接続識別子が（接続タイムアウトのために）最早有効でない場合、エラーが戻される。
【００６９】
ネイティブクライアント又はネイティブサーバは、オブジェクトリファレンスへの呼び掛けを達成する。各呼び掛けは、ＩＳＨへ送られるメッセージを結果としてもたらす。
【００７０】
他のネイティブクライアントが同じホスト／ポートでオブジェクトリファレンスに呼び掛けを行なう場合、ＢＩＮＤサービスは、第１の呼び掛けと同じ接続識別子及び同じクライアント情報を戻す。ホスト／ポートエントリのリファレンスカウントは増加される。
【００７１】
最終的に、第１及び第２のユーザはオブジェクトリファレンスを解放する。第１のユーザ解放は、ＵＮＢＩＮＤサービスへのコール（呼出し）を結果としてもたらす。このことは、ホスト／ポートエントリのリファレンスカウントを減少する。第２のユーザ解放の際、ホスト／ポートエントリのリファレンスカウントはゼロに減少される。ＩＳＬは、共有メモリからホスト／ポートエントリを除去し、接続は閉鎖と共有メモリに記す。
【００７２】
ＩＳＨは、それが、共有メモリで接続エントリは閉鎖されると記されていることを知る時に、接続を閉鎖する。
【００７３】
このことは、接続エントリが未使用であることを示している。
【００７４】
接続のユーザが死ぬか又は、オブジェクトリファレンスを解放しない場合、接続は、それがアクティブである限り維持される。接続が特定の時間期間に渡ってアクティブで無かった場合に、接続は切断される。オブジェクトリファレンスは依然として有効であるが、特定のタイムアウト期間内に使用されない場合がある。この場合、接続は切断され、ホスト／ポートエントリが除去される。以降の呼び掛けの際に、ＩＳＨはリクエストを受信し、接続識別子を確認し、エラーを戻す。このエラーは、ＯＲＢにオブジェクトリファレンスを再バインドさせる。これは、ＩＳＬ ＢＩＮＤサービスへコール（呼出し）を呼び掛け、現存する接続を使用すか、又は新たな接続を生成することができる。この再バインドは、ユーザに取って可視的である必要はない。
【００７５】
追加の特徴
コールアウトに対する双方向接続の使用
或るシナリオにおいて、クライアントは接続し、イベントへの永続的なサブスクリプション（申し込み）を生成し、そしてＩＳＨから切断する。クライアントはＩＳＨに再接続する時、クライアントは、その永続的なサブスクリプションに対するイベントを受け入れることを期待する。
【００７６】
本発明の或る実施の形態において、ＩＳＬは、現在の双方向接続に付いての情報を得、次に、ＩＯＲ内のホスト／ポートへの別の接続を生成する代わりに、現在の双方向接続を使用する。ＩＳＬに双方向接続を通知することにより、リソースのオプション的使用を可能にする。ＩＳＨはＩＳＬに双方向情報を通知する。このことは、接続生成及び除去に付いて共有メモリ又は特別のメッセージのロッキングを必要とする。
【００７７】
クライアント切断
図１３に示されるこのシナリオにおいて、クライアントはドメインから切断されるが、同じホスト及びポートで依然としてリスニングを行なう。このオブジェクトリファレンスは、切断されたクライアントのクライアント情報を含む。ＯＲＢが利用可能でないサービスに呼び掛けを行なう時、インフラストラクチャーはエラーを戻す。ＯＲＢは、このエラーを取扱い、且つオブジェクトリファレンスを再バインドする３０４。ＩＳＨが、リモートサーバへの新たな接続を生成するために、選択され、クライアント情報が更新される。
【００７８】
データ設計
ＩＳＬ及びＩＳＨはそれぞれがメモリ内に保持するデータを各々有する。ＩＳＬ及びＩＳＨは、ＩＳＬ及びＩＳＨの寿命に渡って永続されることを必要とする項目に対してメモリを共有する。ＩＳＬが死んで、再スタートする場合、ＩＳＬは、共有メモリに再び付随し、共有メモリ内に格納されたいかなる状態も回復することができる。
【００７９】
共有メモリ
ＩＳＬは、それが制御するＩＳＨとメモリを共有する。非対称アウトバウンドＩＩＯＰが利用可能な場合、追加のセクションが共有メモリテーブル内に存在する。このメモリは、ＩＳＬによって使用され、適当な集中及びロードバランスを行ない、又は、このメモリは、ＩＳＨが生成を必要としている接続のトラックを保持するためにＩＳＨによって使用される。ＩＳＬは共有メモリの一次ライターである。
【００８０】
ＩＳＨ故障
ＩＳＨは、共有メモリ内にある必要がないことに付いての情報を保持する必要がある。共有される必要がない情報の中に、現在の要求に付いての情報を維持するための領域、リクエストｉｄをクライアント（サーバ）にマップするための領域がある。ＩＳＬは、ＩＳＨを再スタートするための責務を負っている。ＩＳＬかＩＳＨを再スタートする時、死んだＩＳＨに対する古い共有メモリスロットをクリアーにし、ＩＳＨがＩＳＬの共有メモリに接続することを保証する。
【００８１】
クライアントは、故障したＩＳＨにバインドしたオブジェクトリファレンスに呼び掛けを行なう場合、エラーが発生する。呼出し側が再バインドし、ＩＳＨが呼び掛けを達成するために、選択される。これは、再スタートされたＩＳＨ又は他のＩＳＨであることができる。
【００８２】
ＩＳＬ故障
システム管理者が、推奨されたセッティングでＩＳＬをスタートする場合、ＩＳＬが最終的に再スタートする。
【００８３】
オブジェクトコードがサービスを呼び出すが、サーバを依然として選択していていない場合、別のＩＳＬが選択される。オブジェクトコードがサービスを呼び出し且つサービスを選択した場合、システムがエラーをクライアントに戻す。ＩＳＬが最終的に再スタートする時、ＩＳＬは、共有メモリに再結合する。
【００８４】
ネイティブクライアント（又はクライアントとして機能するサーバ）故障
ＩＳＬは、アウトバウンド接続のリストを周期的にスキャンする。接続が特定された時間期間内でアクティブとならない場合、対応するエントリは、解放され、アウトバウンド接続は切断される。このことによって、ネイティブクライアント又はサーバが故障する場合、ネイティブクライアント又はサーバによって生成されたアウトバウンド接続は常に切断されることが保証される。
【００８５】
ガーベッジコレクション（ゴミ収集）
共有メモリのある部分をクリーンナップすることができる「イベント」がある。
リモートサーバが故障する。ＩＳＨはエラーをクライアント（又は、多重クライアントが接続を使用した場合は複数のクライアント）に戻す。クライアントが退出し、且つＩＳＬに通知される時、適当なホスト及びポートスロット及び適当なクライアント識別子スロットが一掃される。
【００８６】
接続が管理者によって設定されたタイムアウトを越えたことを、ＩＳＨが理解する。対応するエントリが解放され、ソケットは閉鎖と記される。次の呼び掛けにおいて、エラーは呼出し側に戻される。ＯＲＢは、オブジェクトリファレンス再バイントする。新たな接続が生成され、呼び掛けが発生する。
【００８７】
ＩＳＨが死ぬ。ＩＳＬはＩＳＨを再スタートする。バウンドオブジェクトリファレンスへの次の呼び掛けの際に、エラーが発生する。呼び掛け側は、再バインドし、ＩＳＨが、呼び掛けを達成するために選択される。ＩＳＨに対する現存するエントリは共有メモリに残る。第１の呼び掛けの際、再スタートされたＩＳＨは、リモートサーバに接続される。
【００８８】
ＩＳＬが死ぬ。再スタート時に、ＩＳＬは、全てのＩＳＨをチェックし、何れの死んだＩＳＨに対するエントリーをクリーンナップする。
ＩＳＬがシャットダウンされる。ＩＳＬは、シャットダウンメッセージをＩＳＨに送る。ＩＳＬは共有メモリを除去する。
マシンは、その機能を停止する。ＩＳＬ及び全てのＩＳＨは、同じ時刻に死ぬ。共有メモリは消失する。
【００８９】
本発明の他の特徴、形態及び目的は、図面及び特許請求の範囲を閲覧することにより得ることができる。本発明の他の実施の形態を発展することができ、これらが本発明の精神及び範囲及び特許請求の範囲内に入ることが理解されるべきある。
【００９０】
工業利用性
本発明は、オブジェクト指向システム、特に、ｎ個のクライアントがｍ個のサーバに呼び掛けを行なうことができるＣＯＲＢＡ準拠システムの分野での特定の使用を含む。典型的には、これは、リクエストを扱うのにｎ×ｍ個の接続を要求する。記述される発明は、サーバにｎ個の接続のみをが存在することを可能にし、リソースの必要性を相当減少し、且つ拡張性を可能にする。本発明は、更に、多重インテリジェントマスターコンセントレータプロセスを可能にし、コンセントレータ故障を取扱い及び動的な拡張性を提供する。
【図面の簡単な説明】
【図１】 ＩＩＯＰ及びＯＲＢ層が、どの様に従来技術における他のネットワーク通信プロトコルに関係するかを図示している。
【図２】 従来公知のファンナウトを図示している。
【図３】 多重クライアントとサーバへのＴＣＰ／ＩＰとの間のインタフェースとしてどの様にＩＳＨを使用できるかを本発明の実施の形態に対して示す。
【図４】 ＩＳＬ／ＩＳＨコンセントレータは、ｎ個のクライアントをサービスするのに必要とされるサーバ接続の数を最小にするのにどの様にして使用することができるかを、本発明の実施の形態に対して示す。
【図５】 ＩＳＬ及び多重ＩＳＨサーバが種々のクライアント及びサーバ形態をサーブする本発明の実施の形態を図示する。
【図６】 ルーティングコードがどの様にしてＩＳＬ及びＩＳＨと対話するかを本発明の一実施例に対して示す。
【図７】 ＩＳＬ内に含まれるサービスを本発明の実施の形態に対して示す。
【図８】 ルーティング／バインディングプロセスにおける本発明のステップの実施の形態を示す。
【図９】 アンバインディングプロセスを本発明の実施の形態に対して示す。
【図１０】 双方向接続を使用する本発明のアウトバウンドＩＩＯＰの実施の形態を図示する。
【図１１】 対接続を使用する本発明のアウトバウンドＩＩＯＰの実施の形態を図示する。
【図１２】 非対称接続を使用する本発明のアウトバウンドＩＩＯＰの実施の形態を図示する。
【図１３】 クライアントが切断された後どの様にして双方向接続が回復するかを本発明の実施の形態に対して示す。

Claims (19)

1. ローカルクライアントアプリケーションがリモートサーバサービスを呼び出すことを可能にするための、分散型オブジェクト環境で使用するためのシステムであり、
   コンセントレータを備え、前記コンセントレータは、リモートサーバサービスを呼び出すための、ローカルクライアントアプリケーションからのリクエストを集約し、前記リモートサーバサービスを識別し、及び前記ローカルクライアントアプリケーションを前記リモートサーバサービスに動作可能に接続し、
   前記コンセントレータは、
   前記ローカルクライアントアプリケーションから前記リモートサーバサービスへの接続を扱う複数の接続ハンドラと、
   前記接続を扱うために前記複数の接続ハンドラのうちのどの接続ハンドラを使用するかを決めるリスナーと、
   前記リスナーと前記複数の接続ハンドラとの間の通信を可能にする共用メモリとを備え、前記共用メモリは、現在接続されているリモートサーバのリストを含み、
   前記リスナーは、
   ローカルクライアントのホスト、ポート及びクライアント識別子パラメータと一緒にオブジェクトリファレンスを集約する処理を実行するサービスルーチンを呼び出すステップと、
   前記オブジェクトリファレンスのホストまたはポートをハッシュすることにより当該ホストまたは当該ポートが既に使用されているか否かを決めるために前記共用メモリ内を検索するステップと、
   現存する接続ハンドラが前記接続を扱うことが出来る場合、前記リクエストを扱うために、前記現存する接続ハンドラを当該接続に割り当てるステップと、
   当該接続を扱うことのできる接続ハンドラが現存しない場合、前記リクエストを扱うために新たな接続ハンドラをスタートするステップとを実行する、システム。
2. ローカルクライアントアプリケーションがリモートサーバ上のリモートサーバサービスを呼び出すことを可能にする分散型オブジェクト環境で使用するための方法において、
   前記ローカルクライアントアプリケーションからリモートサーバへの接続を扱うために、複数の接続ハンドラを準備するステップと、
   前記リモートサーバに接続されているコンセントレータが、リスナーとして、前記複数の接続ハンドラの内のどの特定の接続ハンドラが接続を扱うかを決めるステップとを含み、前記決めるステップは、
   ローカルクライアントのホスト、ポート及びクライアント識別子パラメータと一緒にオブジェクトリファレンスを集約する処理を実行するサービスルーチンを呼び出すことと、
   前記オブジェクトリファレンスのホストまたはポートをハッシュすることにより、当該ホストまたは当該ポートが既に使用されているか否かを決めるために、前記リスナーと前記複数の接続ハンドラとによって使用される共用メモリ内を検索することとを含み、前記共用メモリは、現在接続されているリモートサーバのリストを含み、
   現存する接続ハンドラが接続を扱うことが出来る場合、リクエストを扱うために、現存する接続ハンドラを当該接続に割り当て、
   接続を扱うことのできる接続ハンドラが現存しない場合、前記リクエストを扱うために新たなハンドラをスタートすることを含み、さらに、
   前記コンセントレータが、前記ローカルクライアントアプリケーションからのリクエストを集約するステップと、
   前記コンセントレータが、前記リモートサーバを識別するステップと、
   前記接続ハンドラが、前記ローカルクライアントアプリケーションを、前記リモートサーバに動作可能に接続することを含む、方法。
3. 前記コンセントレータが、前記リモートサーバが前記接続ハンドラに現在接続されているかを知るために、前記リスナーと前記接続ハンドラとで使用される共用メモリスペースを参照することを更に含む請求項２記載の方法。
4. 前記リモートサーバが、前記接続ハンドラに現在接続されていない場合、前記コンセントレータが、前記リモートサーバを前記接続ハンドラに接続し、且つ前記共用メモリを更新することを更に含む請求項３記載の方法。
5. 前記共用メモリを更新する前記ステップが、現在接続されている前記リモートサーバのリストを更新し、前記接続ハンドラが各接続を取り扱うことを特徴とする請求項４記載の方法。
6. 前記コンセントレータが、現在接続されているリモートサーバのリストを参照して、どの接続ハンドラが接続を扱うべきかを決め、前記接続ハンドラが共用メモリ内の各接続を扱うステップを更に含む請求項３記載の方法。
7. 多重接続ハンドラの一つを接続を扱うために使用することができる請求項２記載の方法。
8. ローカルクライアントアプリケーションがリモートサーバサービスを呼び出すことを可能にするための分散型オブジェクト環境で使用するためのシステムであって、
   前記ローカルクライアントアプリケーションからの前記リモートサーバサービスを呼び出すＩＩＯＰリクエストを集約するためのコンセントレータを具備し、前記コンセントレータが更に、
   前記ローカルクライアントアプリケーションから前記リモートサーバサービスへの接続を扱うための複数の接続ハンドラと、
   前記複数の接続ハンドラの内の接続を扱うための特定の接続ハンドラを決めるリスナーと、
   前記リスナーと前記複数の接続ハンドラとの間での通信を可能にする共用メモリを含み、前記共用メモリが現在接続されているリモートサーバのリストを含み、
   前記リスナーは、
   ローカルクライアントのホスト、ポート及びクライアント識別子パラメータと一緒にオブジェクトリファレンスを集約するためにサービスルーチンを呼び出すステップと、
   前記オブジェクトリファレンスのホストまたはポートをハッシュすることにより当該ホストまたは当該ポートが既に使用されているか否かを決めるために前記共用メモリ内を検索するステップと、
   現存する接続ハンドラが接続を扱うことが出来る場合、前記ＩＩＯＰリクエストを扱うために、前記現存する接続ハンドラを当該接続に割り当てるステップと、
   接続を扱うことのできる接続ハンドラが現存しない場合、前記ＩＩＯＰリクエストを扱うために新たなハンドラをスタートするステップとを実行する、システム。
9. 前記ローカルクライアントアプリケーションが、
   オブジェクトリファレンスを集約する時において、前記オブジェクトリファレンスがリモートであるかを決め、リモートである場合、ＯＲＢを、オブジェクトリファレンスからのクライアント情報で初期化するステップを実行し、前記クライアント情報が存在する場合にバインドフラグが設定され、
   前記ローカルクライアントアプリケーションは、さらに、
   前記バインドフラグが存在する場合、前記リモートサーバサービスを集約し、戻されたＩＳＨ（ＩＩＯＰ サーバハンドラ）クライアント情報及びリスナー情報を前記共用メモリに記憶するステップと、
   前記バインドフラグが存在しない場合、前記クライアント情報を前記共用メモリ内に記憶するステップと、
   クライアント識別子について前記共用メモリ内を検索し、そのクライアント識別子を呼び出すステップと、
   前記接続が切断された時、適当なエントリについて前記共用メモリ内を検索し、前記エントリを使用して、前記リモートサーバサービスを解放するステップとを実行する、請求項８記載のシステム。
10. 前記接続ハンドラが、
    メッセージキューから、前記ローカルクライアントアプリケーションと前記リモートサーバサービスとの通信のためにＯＲＢによって生成されるメッセージを受信するステップと、
    前記ローカルクライアントアプリケーションに基づいて、前記接続ハンドラをクライアントコンテキスト又はハンドラコンテキストに切り換えるステップと、
    ＩＩＯＰリクエストのコピーを作り、且つ当該ＩＩＯＰリクエストのオリジナルのＩＩＯＰリクエストｉｄを一義的なｉｄで置き換えるステップと、
    前記ＩＩＯＰリクエストをこのコンテキストに対する未処理リクエストのリストに置くステップと、
    前記コンテキストがクライアントコンテキストである場合で、且つ対の第２の接続及び前記接続が存在しない場合、一つの接続を生成し、ＩＩＯＰリクエストを前記ローカルクライアントアプリケーションに送るステップと、
    前記コンテキストが前記ハンドラコンテキストである場合、接続インデックスを使用して、アウトバウンド接続を決め、接続が存在しない場合、接続を生成し、ＩＩＯＰリクエストをローカルクライアントアプリケーションに送るステップと、
    リプライが接続から戻る時、対応するリクエストに対する未処理リクエストのリストを検索し、前記一義的なｉｄを前記オリジナルのＩＩＯＰリクエストｉｄで置き換え、前記リプライを前記ローカルクライアントアプリケーションに送るステップとを実行する、請求項８記載のシステム。
11. 前記ローカルクライアントアプリケーションが実行されるクライアント装置は、ネイティブＣ＋＋クライアント、Ｊａｖａクライアント、通知サービス、又はクライアントとして機能するネイティブサーバの何れか一つである請求項８記載のシステム。
12. 前記リモートサーバサービスが実行される装置が、ネイティブサーバ、イベントに対して登録されたネイティブクライアント、又は非ネイティブＣＯＲＢＡ−迎合ＯＲＢサーバの何れか一つである請求項８記載のシステム。
13. ローカルクライアントアプリケーションがリモートサーバサービスに呼び掛けを行うことを可能にする分散型オブジェクト環境で使用するための方法において、
    ローカルクライアントアプリケーションからリモートサーバサービスへの接続を扱うために、複数の接続ハンドラが準備するステップと、
    リスナーが、前記複数の接続ハンドラの内のどの特定の接続ハンドラが接続を扱うかを決めるステップと、
    前記リスナーが、リモートサーバサービスを呼び出す、ローカルクライアントアプリケーションからのリクエストを集約するステップとを含み、前記集約するステップは、
    リモートサーバサービスを識別するステップと、
    ローカルクライアントアプリケーションを、前記特定の接続ハンドラを介して前記リモートサーバサービスに作動的に接続するステップとを含み、
    前記リスナーが追加のステップを実行し、前記追加のステップは、
    ローカルクライアントのホスト、ポート及びクライアント識別子パラメータと一緒にオブジェクトリファレンスを集約するためにサービスルーチンを呼び出すステップと、
    前記オブジェクトリファレンスのホストまたはポートをハッシュすることにより当該ホストまたはポートが既に使用されているか否かを決めるために、前記リスナーと前記複数の接続ハンドラとの間の通信を可能にする共用メモリ内を検索するステップと、
    現存する接続ハンドラが接続を扱うことが出来る場合、前記リクエストを扱うために、前記現存する接続ハンドラを当該接続に割り当てるステップと、
    接続を扱うことのできる接続ハンドラが現存しない場合、前記リクエストを扱うために新たな接続ハンドラをスタートするステップとを含む、方法。
14. 前記ローカルクライアントアプリケーションが追加のステップを実行し、前記追加のステップは、
    オブシェクトリファレンスを集約する時に、オブジェクトリファレンスがリモートであるか否かを決定し、リモートである場合、ＯＲＢをオブジェクトリファレンスからのクライアント情報で初期化するステップを含み、前記クライアント情報が存在する場合にバインドフラグが設定され、
    前記追加のステップは、さらに、
    前記バインドフラグが現存する場合、前記リモートサーバサービスを集約し、戻されたＩＳＨクライアント情報及びリスナー情報を前記共用メモリ内に記憶するステップと、
    前記バインドフラグが現存しない場合、前記クライアント情報を前記共用メモリ内に記憶するステップと、
    クライアント識別子に付いて前記共用メモリ内を検索し、クライアント識別子に呼び掛けを行うステップと、
    前記接続が切断される時、適当なエントリに付いて共用メモリ内を検索し、そして前記エントリを使用して、前記リモートサーバサービスを解放するステップとを含む、請求項１３記載の方法。
15. 前記接続ハンドラが追加のステップを実行し、前記追加のステップは、
    メッセージキューから、前記ローカルクライアントアプリケーションと前記リモートサーバサービスとの通信のためにＯＲＢによって生成されるメッセージを受信するステップと、
    前記ローカルクライアントアプリケーションに基づいて、前記接続ハンドラをクライアントコンテキスト又はハンドラコンテキストの何れかに切り換えるステップと、
    ＩＩＯＰリクエストのコピーを作り、そしてオリジナルのＩＩＯＰリクエストｉｄを一義的なｉｄで置き換えるステップと、
    前記ＩＩＯＰリクエストを、このコンテキストに対する未処理リクエストのリストに置くステップと、
    前記コンテキストがクライアントコンテキストである場合で、且つ、対にされる第２の接続及び接続が依然として存在しない場合、接続を生成し、前記ＩＩＯＰリクエストをローカルクライアントアプリケーションに送るステップと、
    前記コンテキストがハンドラコンテキストである場合、接続インデックスを使用してアウトバウンド接続を決定し、接続が存在しない場合、接続を生成し、前記ＩＩＯＰリクエストを前記ローカルクライアントアプリケーションに送るステップと、
    リプライが、接続から戻される時、対応するリクエストに対する未処理リクエストのリストを検索し、前記一義的なｉｄをオリジナルのリクエストｉｄで置き換え、前記リプライを前記ローカルクライアントアプリケーションに送り戻すステップとを含む、請求項１３記載の方法。
16. 前記ローカルクライアントアプリケーションが、ネイティブＣ＋＋クライアント、Ｊａｖａクライアント、通知サービス、又はクライアントとして機能するネイティブサーバの内の何れかであることを特徴とする請求項１３記載の方法。
17. リモートサーバが、ネイティブサーバ、イベントに対して登録されたネイティブクライアント、又は非ネイティブＣＯＲＢＡ−迎合ＯＲＢサーバの何れかである請求項１３記載の方法。
18. ローカルクライアントアプリケーションがリモートサーバサービスに呼び掛けることを可能にするための、分散型オブジェクト環境で使用するためのシステムであり、
    ローカルクライアントアプリケーションから前記リモートサーバサービスを呼び出すリクエストを集約するコンセントレータを備え、前記コンセントレータは、
    前記ローカルクライアントアフリケーションからリモートサーバサービスへの接続を扱う複数の接続ハンドラ、
    前記複数の接続ハンドラの内の接続を扱う特定の接続ハンドラを決めるリスナー、及び
    前記リスナーと前記複数の接続ハンドラとの間の通信を可能にする共用メモリを含み、前記共用メモリが現在接続されているリモートサーバのリストを含み、前記接続ハンドラが各接続を扱い、
    前記リスナーは、
    ローカルクライアントのホスト、ポート及びクライアント識別子パラメータと一緒にオブジェクトリファレンスを集約するためにサービスルーチンを呼び出すステップと、
    前記オブジェクトリファレンスのホストまたはポートをハッシュすることにより、前記オブジェクトリファレンスのホストまたはポートが既に使用されているか否かを決めるために前記共用メモリ内を検索するステップと、
    ユーザ多重化リファリンスカウントを増加するステップと、
    現存する接続ハンドラが接続を扱うことが出来る場合、前記リクエストを扱うために、前記現存する接続ハンドラを前記接続に割り当てるステップと、
    接続を扱うことのできる接続ハンドラが現存しない場合、前記リクエストを扱うために新たな接続ハンドラをスタートするステップとを実行する、システム。
19. ローカルクライアントアプリケーションがリモートサーバサービスに呼び掛けを行なうことを可能にする分散型オブジェクト環境で使用するための方法において、
    リスナーが、前記ローカルクライアントアプリケーションから前記リモートサーバサービスへの接続を扱うために、複数の接続ハンドラを準備するステップと、
    前記リスナーが、前記複数の接続ハンドラの内のどの特定の接続ハンドラが接続を扱うかを決めるステップと、
    前記リスナーが、前記リモートサーバサービスを呼び出す前記ローカルクライアントアプリケーションからのリクエストを集約するステップとを含み、前記集約するステップは、
    前記リモートサーバサービスを識別するステップと、
    前記ローカルクライアントアプリケーションを、前記特定の接続ハンドラを介して前記リモートサーバサービスに動作可能に接続するステップとを含み、
    前記リスナーが追加のステップを実行し、前記追加のステップは、
    ローカルクライアントのホスト、ポート及びクライアント識別子パラメータと一緒にオブジェクトリファレンスを集約するためにサービスルーチンを呼び出すステップと、
    前記オブジェクトリファレンスのホストまたはポートをハッシュすることにより、前記オブジェクトリファレンスのホストまたはポートが既に使用されているか否かを決めるために、前記リスナーと前記複数の接続ハンドラとによって使用される共用メモリ内を検索するステップとを含み、前記共用メモリは、現在接続されているリモートサーバのリストを含み、
    ユーザ多重化リファリンスカウントを増加するステップと、
    現存する接続ハンドラが接続を扱うことが出来る場合、前記リクエストを扱うために前記現存する接続ハンドラを前記接続に割り当てるステップと、
    接続を扱うことのできる接続ハンドラが現存しない場合、前記リクエストを扱うために新たなハンドラをスタートするステップとを含む、方法。

Images