JP2000311094A

JP2000311094A - 遠隔オブジェクト間の通信方法

Info

Publication number: JP2000311094A
Application number: JP2000047304A
Authority: JP
Inventors: Armel Pietre; アルメル・ピエトル; Fabrice Banctel; フアブリス・バンクテル; Alexandre Feray; アレクサンドル・フエレ
Original assignee: Alcatel CIT SA; Alcatel SA
Current assignee: Alcatel CIT SA; Alcatel Lucent SAS
Priority date: 1999-02-25
Filing date: 2000-02-24
Publication date: 2000-11-07
Also published as: DE60036503D1; DE60036503T2; AU1943600A; ATE374398T1; EP1031926B1; CA2299663A1; FR2790351A1; EP1031926A1

Abstract

(57)【要約】【課題】ＯＲＢ分散オブジェクトマネージャーに基づ
く通信方法を提供すること。【解決手段】この通信方法は、第１のプロセスのオブ
ジェクトに関連したプロキシ／スタブタイプの代理エレ
メント対の第１の代理エレメントを修正し、第１の代理
エレメントは、所定のサービスに関係し、第１のプロセ
スのオブジェクトによって他のプロセスのオブジェクト
に送られた、メッセージを、第１のプロセスにおいて該
サービスに対応する呼出のマネージャーに送る。呼出マ
ネージャーは、受信したメッセージを管理し、各宛先プ
ロセスにおいて対応する受信マネージャーにメッセージ
のいくつかを送信する。メッセージと任意の結果は、呼
出マネージャーと受信マネージャーの間を、パケットで
送信される。クライアントマネージャーは、それを通過
するすべてのメッセージを修正することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、「オブジェクト要
求ブローカー（ＯＲＢ）分散オブジェクトマネージャ
ー」に基づいた遠隔オブジェクト間の通信方法に関す
る。

【０００２】

【従来の技術】特によく知られて広く用いられているＯ
ＲＢは「共通オブジェクト要求ブローカーアーキテクチ
ャ（ＣＯＲＢＡ）」と「分散コンポーネントオブジェク
トモデル（ＤＣＯＭ）」を含む。

【０００３】多くの適用例（アプリケーション）は、上
記の種類の環境を用いる。テレコミュニケーション用ま
たは輸送管理用の適用例、インテリジェントネットワー
クを構成する適用例等が、例として挙げられるであろう
適用例である。

【０００４】分散オブジェクト環境では、適用例は、ク
ライアントにサービスを提供するために、様々なサーバ
を使用することができる。クライアントプロセスは、サ
ービスを使用するプログラムであり、サーバプロセス
は、クライアントにサービスを提供するプログラムであ
る。クライアントプロセスのオブジェクトは、対応する
メッセージをサーバに送ることによって、サーバからの
サービスを要求することができる。サーバの対応するオ
ブジェクトは、サービスを実行し、適切である場合、要
求者に応答を返す。２つの遠隔オブジェクト間の通信
は、実際は、オブジェクト−オブジェクトプロトコルを
使う。

【０００５】図１は、このプロトコルの原則を示し、そ
れによって、クライアントプロセスＰＲＯＣＬＩＥＮＴ
のオブジェクトＯｂｊＣは、サーバプロセスの所定のサ
ーバオブジェクトに任意のサービスを要求する場合、対
応するメッセージは、オブジェクトの「代理（ｒｅｐｒ
ｅｓｅｎｔａｔｉｖｅ）エレメント」の対の間を通過す
る。クライアントオブジェクトとサーバーオブジェクト
と呼ばれる２つの遠隔オブジェクトに透過的な方法で、
対応するインタープロセスコールを管理するのは、この
オブジェクトの対である。

【０００６】たとえば、サーバプロセスのオブジェクト
ＯｂｊＡの場合、オブジェクトＯｂｊＡの代理エレメン
トＰｒｏｘｙ（Ａ）が、クライアントプロセスで作成さ
れ、それに対応する代理エレメントＳｔｕｂ（Ａ）が、
サーバプロセスで作成される。クライアントプロセスの
オブジェクトＯｂｊＣからサーバプロセスのオブジェク
トＯｂｊＡへのすべてのメッセージとそれらのメッセー
ジへの任意の応答（結果）は、オブジェクト−オブジェ
クトプロトコルのプロキシ／スタブ（Ｐｒｏｘｙ／Ｓｔ
ｕｂ）インタフェースを通過する。

【０００７】したがって、クライアントオブジェクトが
通信することを望むサーバプロセスの各オブジェクトに
対して、代理オブジェクトの対Ｐｒｏｘｙ／Ｓｔｕｂが
ある。この「プロキシ／スタブ」という用語は、ＤＣＯ
Ｍ環境の用語である。それは、ＣＯＲＢＡ環境の「スタ
ブ／スケルトン（Ｓｔｕｂ／Ｓｋｅｌｅｔｏｎ）」とい
う用語に対応する。ＤＣＯＭ用語は、以下で用いられる
が、当分野の技術者は、どのように以下の説明を当技術
分野で知られているＯＲＢに拡張するべきかを知ってい
るであろう。

【０００８】図１は、クライアントオブジェクトＯｂｊ
Ｃを介して、サーバープロセスのオブジェクトＯｂｊＡ
とＯｂｊＢによって提供された様々なサービスにそれぞ
れアクセスする、２つの代理エレメントの対Ｐｒｏｘｙ
（Ａ）／Ｓｔｕｂ（Ａ）及びＰｒｏｘｙ（Ｂ）／Ｓｔｕ
ｂ（Ｂ）を示す。

【０００９】オブジェクト−オブジェクトプロトコル
は、サーバオブジェクトによって、クライアントオブジ
ェクトに送信されたメッセージにも、同様によく当ては
まる。ＯＲＢによってサポートされる「通知サービス」
は、クライアントプロセスのクライアントオブジェクト
が、サーバプロセスからの通知を受信することを登録す
ることを可能にする。上記種類の通知サービスの使用の
代表的な例は、クライアントがオブジェクトの特性の変
更についてアドバイスされることを望む、監視用の適用
例に関係する。オブジェクト−オブジェクトプロトコル
によれば、図２で示されるように、クライアントオブジ
ェクトは、サーバプロセスＰＲＯＳＥＲＶのオブジェク
トＯｂｊＡからの通知に対して、シンク（ｓｉｎｋ）オ
ブジェクトＳｉｎｋＣであることを登録した場合、その
サーバオブジェクトによってそのクライアントオブジェ
クトに送られた通知は、シンクオブジェクトの代理エレ
メントの対を介して送信される。その代理エレメントの
対は、サーバプロセスＰＲＯＳＥＲＶでのシンククライ
アントＳｉｎｋＣの代理エレメントＰｒｏｘｙ（Ｃ）
と、クライアントプロセスＰＲＯＣＬＩＥＮＴでの対応
する代理エレメントＳｔｕｂ（Ｃ）とを含む。

【００１０】サーバオブジェクトＯｂｊＡからシンクク
ライアントＳｉｎｋＣへの通知メッセージｎ（ｘ
ａ，．．．）は、代理エレメントＰｒｏｘｙ（Ｃ）に送
られ、その代理エレメントＰｒｏｘｙ（Ｃ）は、その通
知メッセージを、対応するクライアントＳｉｎｋＣの対
応する代理エレメントＳｔｕｂ（Ｃ）に送る。したがっ
て、その代理エレメントＳｔｕｂ（Ｃ）は、オブジェク
トＯｂｊＡとＳｉｎｋＣが、それらのそれぞれの位置を
知ることを必要としないで、その代理エレメントＳｔｕ
ｂ（Ｃ）にアドレス指定されている通知メッセージｎ
（ｘａ，．．．）を受信する。

【００１１】上記種類のオブジェクト−オブジェクトプ
ロトコルの利点は、オブジェクトが、メッセージを交換
するオブジェクトの位置を知る必要がないことである。
このプロトコルで、ＯＲＢは、オブジェクトの位置を隠
す。いわば、オブジェクトは、どこに位置しているとし
ても、オブジェクトへのアクセスをかなり単純化する。
これらの代理エレメントの対は、当分野の技術者によく
知られていて、ここでは、より詳細に説明しない。

【００１２】いくつかの適用例では、きわめて多数のメ
ッセージが、一方の方向でまたは他方の方向で、このプ
ロトコルにしたがって、交換されることができる。

【００１３】これには、多くの実施例がある。「ライフ
サイクルサービス」と呼ばれるサービスでは、サーバオ
ブジェクトがまだアベイラブルであるか、すなわち破壊
されていないか、または、ネットワークが故障していな
いかを、クライアントオブジェクトが発見することを可
能にし、メッセージは、この情報を必要とするすべての
サーバオブジェクトに関係しているすべてのクライアン
トオブジェクトよって、周期的に送られる。サーバプロ
セスがアンアベイラブルの場合、そのサーバプロセスの
すべてのサーバオブジェクトもアンアベイラブルであ
る。

【００１４】「識別サービス」では、クライアントオブ
ジェクトは、サーバオブジェクトが位置しているプロセ
スの名前を、クライアントオブジェクトに返すことを、
サーバオブジェクトに要求することができる。すべての
クライアントオブジェクトは、同じプロセス上にあるこ
のサーバオブジェクトのサービスを要求することができ
る。

【００１５】他の実施例、特に監視用の適用例で用いら
れる通知サービスに関する例では、システムの様々な装
置ユニットの特性（アクティビティ、ステータス）に関
係する非常に多数の通知メッセージがある。

【００１６】他の実施例には、サーバプロセスによって
実行されるサービスに加入するメッセージの例、たとえ
ば、通知チャンネルがある。クライアントプロセスは、
作成されると、一般的には、自身が含んでいるいくつか
のまたはすべてのオブジェクトを、１つまたは複数のサ
ーバプロセスに登録する。明らかに、きわめて多数の登
録メッセージがある。

【００１７】上記の実施例では、プロセス間のコール数
は、最適ではないことは、明らかである。コール数を減
らすことは、有益である。

【００１８】したがって、高価であるプロセス間のコー
ル数を減らすために、および通信を最適化するために、
グループでメッセージを送るように、２つのプロセス間
のメッセージをグループ化することは、有益である。

【００１９】上記の理由のために、いくつかのサービス
についてのメッセージは、集中化させられる。「集中化
サービス（ｃｏｎｃｅｎｔｒａｔｉｏｎｓｅｒｖｉｃ
ｅ）」は、それから、対応するサービスに加入している
プロセスからのすべてのメッセージを受信して処理す
る。たとえば、集中化サービスは、メッセージを修正
し、メッセージをフィルタリングして、周期的に宛先プ
ロセスに送ること等ができる。

【００２０】通知サービスを有する使用についての上記
の種類の通信方法は、図３で示される。上記の種類のプ
ロセスで、サーバプロセスのオブジェクトＯｂｊＢは、
宛先シンクオブジェクトＳｉｎｋＤを識別するパラメー
タ、一般的にはポインタｐＳｉｎｋＤを有する、オブジ
ェクトＯｂｊＢの通知メッセージを送らなくてはならな
い。オブジェクトＯｂｊＢは、ｎ（ｐＳｉｎｋＤ，ｘ
ｂ，．．．）タイプのメッセージを送り、シンクオブジ
ェクトＳｉｎｋＤは、ｎ（ｘｂ，．．．）タイプのメッ
セージを受信する。上記の種類のサービスで、オブジェ
クト−オブジェクトプロトコルの透過性（ｔｒａｎｓｐ
ａｒｅｎｃｙ）は、明らかに失われる。送信するオブジ
ェクトは、宛先オブジェクトに対するポインタを提供し
なくてはならない。

【００２１】集中化サービスは、したがって、オブジェ
クト−オブジェクトプロトコルの透過性の利点が失われ
る通信プロトコルにおけるもう１つの仲介者（ｉｎｔｅ
ｒｍｅｄｉａｒｙ）である。

【００２２】

【発明が解決しようとする課題】本発明の目的は、オブ
ジェクトが、前述の欠点を有していない遠隔オブジェク
ト間の通信方法を提供することである。

【００２３】本発明は、ＯＲＢのオブジェクト−オブジ
ェクトプロトコルの機構を用いる。すなわち、それは、
ＯＲＢの内部の機構に入らず、オブジェクト−オブジェ
クトプロトコルの透過性を失わないで、メッセージの集
中化を可能にする通信プロトコルを提供することであ
る。

【００２４】

【課題を解決するための手段】ＯＲＢの上にとどまるこ
とによって、通信方法は、移植可能で有利である。すな
わち、いずれのＯＲＢにも適用できる。

【００２５】ＯＲＢ環境では、ＯＲＢに依存する従来の
技術で知られている機構を用いて、オブジェクト−オブ
ジェクトプロトコルのプロキシ／スタブタイプの代理エ
レメントを修正することは可能である。本発明は、各プ
ロセスで、中央に集中したサービスマネージャーによっ
て、メッセージを送信するこの特性を用いる。

【００２６】本発明によれば、したがって、マネージャ
ーオブジェクトは、所定のサービスに関連するメッセー
ジを集中化させる各プロセスで作成される。

【００２７】そのサービスのために、「呼出（ｃａｌｌ
ｉｎｇ）プロセス」での「呼出（ｃａｌｌｉｎｇ）マネ
ージャー」と「宛先（ｄｅｓｔｉｎａｔｉｏｎ）プロセ
ス」での「受信（ｒｅｃｅｉｖｉｎｇ）マネージャー」
が、作成される。

【００２８】代理エレメントの対は、その呼出プロセス
におけるそのサービスに対応する呼出マネージャーに、
呼出プロセスのプロキシタイプの代理エレメントによっ
て受信された関係しているサービスに関連するメッセー
ジの送信を可能にするように修正される。

【００２９】呼出マネージャーは、サービスの要求にし
たがって、メッセージを処理することができる。たとえ
ば、呼出マネージャーは、宛先プロセスにおける対応す
る受信マネージャー等にメッセージを送るために、メッ
セージをフィルタリングし、パラメータを修正し、メッ
セージを分類し、メッセージをグループ化することがで
きる。

【００３０】宛先プロセスの各受信マネージャーは、宛
先オブジェクトに、このように受信されたメッセージを
分配するか、または、各受信マネージャー自体で、対応
するサービスを提供することができる。

【００３１】したがって、本発明は、ＯＲＢ分散オブジ
ェクトマネージャーに基づいて、通信方法を提供する。
この通信方法では、メッセージが、代理エレメントの対
によって、第１のプロセスのオブジェクトから他のプロ
セスのオブジェクトに送信される。その際、代理エレメ
ントの各対が、呼出プロセスにおける第１の代理エレメ
ントと、他のプロセスにおける第２の代理エレメントと
を含む。そして、第１のプロセスの第１の代理エレメン
トは修正され、その結果、第１のプロセスの第１の代理
エレメントは、所定のサービスに関連し、第１のプロセ
スのオブジェクトによって、他のプロセスのオブジェク
トに送信された、メッセージを、第１のプロセスにおけ
る該所定のサービスに対応する呼出マネージャーへ送
る。呼出マネージャーは、こうして受信したメッセージ
を管理し、該メッセージのいくつかを、各宛先プロセス
において対応する受信マネージャーに送信する。

【００３２】上記の通信方法は、クライアントオブジェ
クトが、サーバオブジェクトにメッセージを送るサービ
スと、サーバオブジェクトが、クライアントオブジェク
トに通知メッセージを送るサービスにも、同様によく当
てはまる。

【００３３】他の本発明の目的は、クライアントプロセ
スのオブジェクトによって、サーバプロセスのアドレス
に送られた登録メッセージの数を減らすことである。こ
の目的のために、本発明は、オブジェクトの集合を含む
クライアントプロセスをサーバプロセスに登録する方法
を提供する。そのオブジェクトのそれぞれは、登録メッ
セージを送り、登録メッセージは、前に説明された通信
方法によって、サーバプロセスに通信される。

【００３４】本発明の他の特徴と本発明の利点は、実例
となる限定しない実施例のみによって、および、添付の
図面を参照して、与えられる以下の記述で説明される。

【００３５】

【発明の実施の形態】図４は、クライアントプロセスＰ
ＲＯＣＬＩＥＮＴ１のクライアントオブジェクトＯｂｊ
Ｃから、サーバプロセスＰＲＯＳＥＲＶ１のサーバオブ
ジェクトＯｂｊＡとＯｂｊＢに、所与のサービスＳＸに
対応するメッセージを送信するために、所定のサービス
ＳＸに適用された本発明の第１の実施形態に対応する。

【００３６】クライアントプロセスは、様々なクライア
ントオブジェクトを含むことができる。クライアントオ
ブジェクトが様々なサービスに対してそれらのクライア
ントオブジェクト上に登録する場合に作成されるプロキ
シ／スタブタイプの代理エレメントは、様々なクライア
ントオブジェクトの各々に対応する。

【００３７】図４に示した単純化された実施例では、単
一のクライアントオブジェクトＯｂｊＣがある。２つの
プロキシ／スタブタイプの代理エレメントの対、Ｐｒｏ
ｘｙ（Ａ）／Ｓｔｕｂ（Ａ）とＰｒｏｘｙ（Ｂ）／Ｓｔ
ｕｂ（Ｂ）が、前記クライアントオブジェクトＯｂｊＣ
に対して、この実施例では同じサーバプロセスＰＲＯＳ
ＥＲＶ１の一部であるサーバオブジェクトＯｂｊＡとＯ
ｂｊＢによって提供される様々なサービスにアクセスを
提供するために作成されている。

【００３８】クライアントプロセスＰＲＯＣＬＩＥＮＴ
１は、さらに、サービスＳＸに対する呼出マネージャー
ＧＣＬＩＥＮＴ１を含む。呼出マネージャーは、クライ
アントプロセスのプロキシタイプの代理エレメントによ
って送信されたサービスＳＸに関連するメッセージを受
信する。メッセージが、サービスＳＸに関連しない場
合、第１のプロキシタイプの代理エレメントは、対応す
るスタブタイプの第２の代理エレメントにメッセージを
向けることによる標準的な方法で、または、対応するサ
ービスの呼出マネージャーへメッセージを再ルーティン
グすることによる本発明に従った特定の専門的な方法
で、動作することができる。サーバプロセスＰＲＯＳＥ
ＲＶ１は、様々な呼出プロセスの対応する呼出マネージ
ャーから（すなわち、同じサービスＳＸから）メッセー
ジを受信し、宛先サーバオブジェクトに分配する、サー
ビスＳＸの受信マネージャーＧＳＥＲＶ１を含む。

【００３９】オブジェクト−オブジェクトプロトコルの
標準のプロキシ／スタブタイプの代理エレメントは、ク
ライアントオブジェクトが、サーバオブジェクト上のサ
ービスに対して登録する場合に作成され、本発明による
サービスＳＸの呼出マネージャーとサーバマネージャー
の間の通信を可能にするために修正される。クライアン
トプロセスにおけるサービスの呼出マネージャーは、自
身が受信する各メッセージのために、宛先の遠隔サーバ
オブジェクトの識別パラメータだけではなく対応する受
信マネージャーの識別パラメータも知る必要がある。

【００４０】メッセージを送るクライアントオブジェク
トは、メッセージが呼出しているサーバオブジェクトの
位置を知らない。他方、各代理エレメントは、関連する
オブジェクトを介して、該代理エレメントが位置してい
るプロセスにおけるオブジェクトのアドレスを知ってい
る、または、発見することができる。このように、関係
しているプロセスにおけるスタブタイプの代理エレメン
トまたはそれに対応するサーバオブジェクトは、宛先サ
ーバオブジェクトの識別パラメータとそれに対応する受
信マネージャーの識別パラメータを知っている（また
は、発見することができる）。

【００４１】本発明の適用例の実際的な実施例では、し
たがって、サーバプロセスのスタブタイプの代理エレメ
ントは、各スタブタイプの代理エレメントが関連付けら
れているプロキシタイプの代理エレメントに、情報を送
るように修正される。それに応じて、図４でダッシュ線
の矢印によって示されるように、Ｐｒｏｘｙ（Ａ）／Ｓ
ｔｕｂ（Ａ）対の代理エレメントＳｔｕｂ（Ａ）は、代
理エレメントＰｒｏｘｙ（Ａ）に、関連するサーバプロ
セスのサーバオブジェクトＯｂｊＡ及び受信マネージャ
ーＧＳＥＲＶ１の識別パラメータｐＯｂｊＡ及びｐＧＳ
ＥＲＶ１を送る。その情報は、代理エレメントの対が作
成される場合またはその後に、送られる。

【００４２】発明の適用例のこの実施例では、プロキシ
／スタブゲートウェイは、呼出マネージャーと受信マネ
ージャーが通信するために必要とされる情報を、プロキ
シタイプのエレメントに送還するために用いられる。当
分野の技術者が、他の機構を適用する方法を知っている
であろうことに留意されたい。１つのそのような他の機
構の１つは、たとえば、共有されたリソースを用いて、
プロキシタイプのエレメントに、上記の情報を直接提供
するために、宛先サーバオブジェクトを使用する。

【００４３】本発明によれば、したがって、クライアン
トプロセスのプロキシタイプの代理エレメントは、サー
ビスＳＸに関連するメッセージを、対応する代理エレメ
ントＳｔｕｂに送信せずに、クライアントプロセスにお
けるそのサービスの呼出マネージャーに送信するように
修正される。各メッセージは、宛先オブジェクトの識別
パラメータとそれに対応する受信マネージャーの識別パ
ラメータを含む。

【００４４】それに応じて、クライアントオブジェクト
ＯｂｊＣが、サービスＳＸに関連するａ（ｘ，
ｙ，．．．）タイプのメッセージをサーバプロセスＰＲ
ＯＳＥＲＶ１のオブジェクトＯｂｊＡに送ることを望む
場合、対応するＰｒｏｘｙ（Ａ）は、前記ａ（ｘ，
ｙ，．．．）タイプのメッセージを、代理エレメントＳ
ｔｕｂ（Ａ）に直接送る代わりに、ａ（ｐＯｂｊＡ，ｐ
ＧＳＥＲＶＩ，ｘ，ｙ，．．．）タイプのメッセージ
を、クライアントプロセスにおけるサービスＳＸの呼出
マネージャーＧＣＬＩＥＮＴ１に送る。

【００４５】このように、クライアントプロセスにおけ
る呼出マネージャーは、クライアントプロセスのクライ
アントオブジェクトからのサービスＳＸに関連し、任意
のサーバプロセスの任意のサーバオブジェクトにアドレ
ス指定される、すべてのメッセージを受信する。

【００４６】クライアントプロセスにおける呼出マネー
ジャーは、関係しているサービスＳＸの要求に従って、
メッセージを処理することができる。前記呼出マネージ
ャーは、たとえば、メッセージをグループ化して送る際
の事前定義された方針にしたがって、各サーバプロセス
に、受信されたメッセージの対応するグループを送るた
めに、サーバプロセスに対して、メッセージをフィルタ
リングし、ソートし、グループ化することができる。

【００４７】このように、呼出マネージャーは、メッセ
ージを、パケットで非同期的に送ることができる。受信
マネージャーは、メッセージのパケットを受信した場
合、呼出マネージャーを解放する。その結果、呼出マネ
ージャーは、他のメッセージの管理に関係することがで
きる。呼出マネージャーがメッセージをパケットで送る
場合、その送信は、周期的であることが可能である。送
信が周期的である場合、その周期は、各呼出マネージャ
ーによって、または、受信マネージャーによって定義さ
れる周期である。

【００４８】周期的な送信は、たとえば、特定の数のメ
ッセージが受信された場合のような、特定のイベントに
よってトリガされた送信によって、補完されることがで
きる。

【００４９】メッセージは、また、識別サービスに対す
る本発明の適用例の実施例に関連して以下に説明される
ように、所定の基準にしたがって、メッセージのいくつ
かだけを送信するように、フィルタリングされることが
できる。

【００５０】同期送信プロセスも、対応する受信マネー
ジャーにメッセージを送るために用いられることがで
き、続いて、返される結果を待つ。

【００５１】したがって、本質的に本発明が適用される
サービスに依存している多くの実際の適用例が存在す
る。

【００５２】図４は、サービスＳＸへの本発明の適用例
を示す。サービスＳＸのために、クライアントオブジェ
クトは、サーバオブジェクトにメッセージを送る。関係
しているサービスに依存して、結果がクライアントオブ
ジェクトに返されるか否かが決まってもよい。

【００５３】関係しているサービスＳＸについて、返さ
れる結果がある場合、結果は、通常、呼出オブジェクト
への反転した送信経路をとる（ＯｂｊＡ→ＧＳＥＲＶ１
→ＧＣＬＩＥＮＴ１→Ｐｒｏｘｙ（Ａ）→ＯｂｊＣ）。
結果は、反対のプロセスを用いて、受信マネージャーと
呼出マネージャーによって、メッセージとほぼ同じ方法
で、処理される。受信マネージャーは、直接サーバオブ
ジェクトから結果を受信する。受信マネージャーは、結
果を、該結果が対応するメッセージにリンクし、分類
し、グループ化することができる。受信マネージャー
は、対応する呼出マネージャーへパケットで、該結果を
送ることができる。その呼出マネージャーは、対応する
クライアントオブジェクトに、該結果を分配する。送信
は、周期的であり、特定のイベントなどによってトリガ
される。マネージャーによるメッセージの管理でのすべ
ての前述の注目すべきことは、該メッセージに対応する
結果の管理にも、等しく当てはまる。

【００５４】マネージャーは、適当な結果である場合に
は、本発明による上記の方法で、メッセージを管理する
ために、適切なデータ構造（テーブル、スタックなど）
を用いる。

【００５５】このように、図４は、呼出マネージャーＧ
ＣＬＩＥＮＴ１によって管理されたテーブルの形でのデ
ータ構造Ｔａｂ_１を示す。いつでも、このデータ構造
は、関係している各受信のマネージャーに対する各宛先
オブジェクトによって受信されたメッセージのリストを
含む。この実施例では、呼出マネージャーＧＣＬＩＥＮ
Ｔ１は、ポインタＧＳＥＲＶ１によって識別された受信
マネージャーに対する２つのメッセージと、ポインタｐ
ＧＳＥＲＶ２によって識別された他の受信マネージャー
に対する１つのメッセージとを含んでいる。

【００５６】サーバのプロセスの受信マネージャーＧＳ
ＥＲＶ１は、それ自体、図４に示したデータ構造Ｔａｂ
_２のような、データ構造を管理しなければならない。受
信マネージャーＧＳＥＲＶ１は、受信したメッセージ
を、前記データ構造内に記憶する。特に、これは、受信
マネージャーＧＳＥＲＶ１が、宛先サーバオブジェクト
に対して受信したメッセージを分類し、該メッセージを
それらの宛先サーバオブジェクトに送ることを可能にす
る。前記データ構造は、受信マネージャーＧＳＥＲＶ１
が、任意の対応する結果を、対応する呼出マネージャー
に返すために、返事として受信する前記任意の対応する
結果を管理することも可能にする。

【００５７】このように、各マネージャーは、要求され
たように、１つまたは複数のデータ構造を管理する。各
マネージャーは、メッセージ、結果、たとえば、メッセ
ージ送信フラグ、結果待ちフラグなどのそれ自体の管理
に関する情報を、データ構造に記憶することができる。

【００５８】また、呼出マネージャーと受信マネージャ
ーは、メッセージおよび／または結果を送信する各ステ
ップにおいて、フィルタリングまたは圧縮のタイプの変
換を適用することができ、または、メッセージまたは対
応する結果の特定のパラメータを修正することができ
る。この機能は、通知サービスへの本発明の適用例の実
施例に関連して、以下で詳細に説明される。しかしなが
ら、前期機能は、一般にサービスの必要性のために、お
よび、プロセス間のコールを最適化するために、本発明
が適用するサービスのいずれかに用いられることができ
る。

【００５９】本発明による通信方法を実施することにお
いて、サーバプロセスの受信マネージャーは、それ自
体、対応するサービスを提供することができる。このよ
うに、サービスの集中化自体は、メッセージ（適用可能
である場合には、結果）の送信の集中化を補完すること
ができる。

【００６０】本発明のこの適用例は、一般的には「サー
バプロセス識別サービス」または「障害検出サービス」
のようなサービスに向けられる。クライアントオブジェ
クトは、自身がアドレス指定しているサーバオブジェク
トが位置するプロセスを発見するために、サーバプロセ
ス識別サービスを用いる。クライアントオブジェクト
は、自身がアドレス指定しているサーバオブジェクト
が、まだアベイラブルであるかどうか（すなわち、なく
なっていないかどうか）を、または、ネットワークが、
ダウンしていないのを発見するために、障害検出サービ
スを用いる。

【００６１】識別サービスの実施例をとれば、中央に集
中したオブジェクトは、各サーバオブジェクトの代わり
に、サービスをとてもよく提供することができる。この
ように、本発明のこの変形では、サービスは、受信マネ
ージャー自体によって提供される。それに応じて、サー
ビスの対応するコードは、各サーバオブジェクトにおい
てではなく、受信マネージャーにおいてだけ、実装され
なければならない。これは、非常に有利である。それ
は、また、クライアントオブジェクトに対して透過的な
方法で達成される。

【００６２】この識別サービスへの適用例では、いくつ
かのサービスが、プロセス間のコールをかなり減らす呼
出マネージャーにおいて中央に集中することもできる。
呼出マネージャーは、サーバプロセスの識別子を発見す
るにつれて、およびサーバプロセスの識別子を発見する
ときに、そのデータ構造に、サーバプロセスの識別子を
記憶することができる。このように、呼出マネージャー
が、すでに識別要求メッセージを受信するサーバプロセ
スの識別子を知っている場合、クライアントオブジェク
ト自体に、要求された結果を返す。したがって、求めら
れている各サーバプロセスのために、呼出マネージャー
は、受信する第１の要求に基づいて、１度だけ受信マネ
ージャーに対応する識別要求を送信する。

【００６３】この適用例の実施例では、メッセージのパ
ケットが、マネージャーの間で、必ずしも送信されない
ことに留意されたい。すなわち、通信プロセスは、その
時、同期していることが可能であり、返される結果を待
つメッセージを送る各エレメントが含まれることに留意
されたい。すなわち、メッセージを送るクライアントオ
ブジェクトと、該メッセージを受信し、クライアントオ
ブジェクトに返信する結果を知らない場合、受信マネー
ジャーにメッセージを送信する呼出マネージャーとがあ
ることに留意されたい。

【００６４】図５は、他の種類のサービス、すなわち
「通知サービス」への本発明の適用例を示す。この場合
は、呼出マネージャーは、サーバプロセス内にあり、受
信マネージャーは、クライアントプロセス内にある。本
発明によれば、各サーバプロセス、それぞれのクライア
ントプロセスは、通知サービスのために、単一の呼出マ
ネージャー、それぞれの受信マネージャーを含んでい
る。各サーバプロセスは、その呼出マネージャーによっ
て、様々なクライアントプロセスに、通知を送ることが
できる。各クライアントプロセスは、その対応する受信
マネージャーによって、様々なサーバプロセスから、通
知を受信することができる。

【００６５】このように、図５に示した実施例では、サ
ーバープロセスＰＲＯＳＥＲＶ１には、通知サービスの
ために呼出マネージャーＧＮＳＥＲＶ１があり、クライ
アントプロセスには、受信マネージャーＧＮＣＬＩＥＮ
Ｔ１がある。

【００６６】呼出マネージャーは、すべての通知メッセ
ージを送るサーバプロセスのすべてのサーバオブジェク
トから、すべての通知メッセージを受信する。受信マネ
ージャーは、異なるプロセスの呼出マネージャーから通
知を受信することができる。受信マネージャーは、受信
した通知を、宛先を収集しているオブジェクトに分配す
る。より一般的には、メッセージ（または返された結
果）が、少なくとも２つのマネージャーの間にパケット
で送られるとすぐに、２つのプロセス間のこの独立性が
得られる。関係しているサービスの種類タイプに依存し
て、マネージャーのレベルにおいてだけ、または、送信
システムのすべてのレベルにおいて、非同期であること
が可能である。当分野での技術者は、この非同期性を導
入する標準的なテクニック（スレッド、割り込みなど）
を用いることができる。

【００６７】呼出マネージャーは、例えばおそらく事前
に変換を適用するパケットで宛先呼出マネージャーに送
るために、宛先クライアントオブジェクトに応じたその
サーバプロセスのサーバオブジェクトから、また、宛先
シンクオブジェクトに応じて各宛先プロセス毎に、受信
する様々な通知メッセージを分類しなくてはならない。
呼出マネージャーは、このために適切なデータ構造Ｔａ
ｂ_３を用いる（図５参照）。この例では、データ構造
は、３つのメッセージを含む。すなわち、クライアント
プロセスＰＲＯＣＬＩＥＮＴ１に対して、２つのメッセ
ージｍ１とｍ２がある。そのうち一方のメッセージｍ１
は、シンクオブジェクトＳｉｎｋＣに対するサーバオブ
ジェクトＯｂｊＡからのものであり、他方のメッセージ
ｍ２は、シンクオブジェクトＳｉｎｋＤに対するサーバ
オブジェクトＯｂｊＢからのものである。そして、メッ
セージｍ３は、クライアントプロセスＰＲＯＣＬＩＥＮ
Ｔ２のシンクオブジェクトＳｉｎｋＯに対するサーバオ
ブジェクトＯｂｊＡからのものであり、図示していな
い。

【００６８】サーバープロセスの呼出マネージャーは、
単一のコールにおけるパケットでメッセージを送るため
に、同じクライアントプロセスの対応する受信マネージ
ャーにアドレス指定されたメッセージをまとめるのが好
ましい。フィルタリングまたは圧縮機構のような変換
を、この段階において呼出マネージャーが送るメッセー
ジのパケットに適用することもできることが示された。
呼出マネージャーは、いくつかのパラメータを修正する
こともできる。

【００６９】たとえば、呼出マネージャーは、いくつか
の特性の最も新しい修正に対応するものだけを送信する
ことによって、メッセージをフィルタリングすることが
できる。この場合、呼出マネージャーは、より以前のメ
ッセージを削除する。呼出マネージャーは、それから、
その状態がフィルタリングが適用されたかどうかを示す
メッセージのフラグタイプパラメータを修正することが
できる。

【００７０】図５に示されるように、クライアントプロ
セスの受信マネージャーも、呼出マネージャーから受信
する通知メッセージ／シンクオブジェクトの対を記憶す
るデータ構造Ｔａｂ_４を管理することができる。受信マ
ネージャーは、関係しているオブジェクトへメッセージ
を分配する前に、メッセージを処理することおよび／ま
たはいくつかのメッセージパラメータを修正することも
できる。

【００７１】プロセスの呼出マネージャーまたは受信マ
ネージャーは、その管理を容易にするために、および一
般にサービスについての必要性のために、メッセージま
たは対応する結果のパラメータを修正することができる
ことが、すでに示された。マネージャーによって修正さ
れることができるパラメータの一実施例は、前に説明さ
れたフィルタリングフラグパラメータである。

【００７２】他の実施例は「キータイプパラメータ」に
関連している。多くの多様なメッセージを送るエレメン
トは、通常「キー割当て機構」を使用する。キーは、ロ
グオンする場合、クライアントによって割り当てられる
識別子である。キーは、通知において送信され、クライ
アントが、通知の対応する接続を識別することを可能に
する。

【００７３】本発明による方法においては、メッセージ
が、マネージャーによって集中化させられるので、マネ
ージャーは、それぞれがそれ自体のキー割当て機構を用
いる様々なエレメントによって送られたメッセージを受
信する。このように、各マネージャーは、同じキーを用
いるメッセージに出合うことができる。

【００７４】本発明は、それから、それ自体の受信した
メッセージを使用するために、各呼出マネージャーまた
は受信マネージャーに、キー割当て機構を提供する。図
６に示した実施例では、受信マネージャーは、クライア
ントプロセスの呼出マネージャーＧＣＬＩＥＮＴ１から
サーバオブジェクトＯｂｊＡに対するメッセージを受信
する。該メッセージは、ａ（ｐＯｂｊＡ，Ｘ，Ｙ，ｋｅ
ｙ１，．．．）というタイプのメッセージである。該メ
ッセージにおいて、ｋｅｙ１が、呼出マネージャーＧＣ
ＬＩＥＮＴ１によって割り当てられた対応するキーであ
る。

【００７５】受信マネージャーは、別のクライアントプ
ロセスの呼出マネージャーＧＣＬＩＥＮＴ２から同じサ
ーバオブジェクトＯｂｊＡに対する別のメッセージを受
信する。このメッセージは、ｋｅｙ１が、呼出マネージ
ャーＧＣＬＩＥＮＴ２によって割り当てられたキーであ
るａ（ｐＯｂｊＡ，Ｘ，Ｙ，ｋｅｙ１，．．．）という
タイプのである。ｋｅｙ１が、呼出マネージャーＧＣＬ
ＩＥＮＴ２によって割り当てられたキーである。

【００７６】受信マネージャーは、そのメッセージを受
信する場合、それ自体の割当て機構（たとえば、メッセ
ージの到着のオーダーによる）を用いて、新しいキーを
割り当てることができる。したがって、受信マネージャ
ーは、各メッセージにおいて受信したキーを、自身が割
り当てる新しいキーに置き換える。受信マネージャー
は、データ構造Ｔａｂ_６において、新しいキーとオリジ
ナルで受信したキーとの間の対応関係を保持することが
でき、その結果、呼出マネージャーに、オリジナルのキ
ーを有する任意の対応する結果を返すことができる。し
たがって、図５に示した実施例においては、第１のメッ
セージの新しいキーは、ｋｅｙ_ｓ１であり、第２のメッ
セージの新しいキーは、ｋｅｙ_ｓ２である。したがっ
て、一般的に言って、呼出マネージャーまたは受信マネ
ージャーは、メッセージのパラメータまたは対応する結
果のパラメータを修正することができる。

【００７７】ある場合には、本発明の通信方法が、呼出
プロセスと宛先プロセスを独立させることに留意された
い。通知サービスの実施例で、図５に示した対応する送
信システムを考慮すると、オブジェクトが通知メッセー
ジを送る場合、それを受信するのは、サーバプロセスに
おける対応する呼出マネージャーである。それから、サ
ーバプロセスは、他のタスクを行うためにサーバーオブ
ジェクトを解放する。呼出マネージャーが、受信マネー
ジャーに通知メッセージのパケットを送ることを決める
場合、受信マネージャーは、該パケットを受信し、すぐ
に呼出マネージャーを解放する。そして、受信マネージ
ャーは、他のパケット及び他の呼出マネージャーなどを
扱うことができる。最終的に、受信マネージャーが、ク
ライアントオブジェクトにメッセージを分配する場合、
該メッセージが受信されるとすぐに、クライアントオブ
ジェクトは、受信マネージャーを解放する。

【００７８】本発明による、様々な適用形態と変形形態
が、純粋な実例によって説明された通信方法では、呼出
オブジェクトは、呼出マネージャーが用いられているこ
とを知らない。そして、当てはまる場合、宛先オブジェ
クトは、受信マネージャーによって呼ばれていることを
知らない。

【００７９】たとえば、サーバオブジェクト上で個別の
テストを行うために、システムが、標準的なプロキシ／
スタブ対を用いて、いつでも通信の標準的な形式に戻る
ことができることに留意されたい。呼出プロセスで要求
されることは、再びＰｒｏｘｙタイプの代理エレメント
を修正し、その結果、Ｐｒｏｘｙタイプの代理エレメン
トが、再び対応するＳｔｕｂタイプの代理エレメントに
メッセージを送信するようにすることだけである。本発
明による通信方法は、したがって、逆にすることが可能
である。

【００８０】通話マネージャーと受信マネージャーの間
の通信が、オブジェクト−オブジェクトプロトコルの標
準的なプロキシ／スタブ対のスキームを用いることがで
きることに留意されたい。前記通信は、図４と図５に示
したように、ＯＲＢ上にまたはオペレーティングシステ
ムで提供された共有リソースＲを使うこともできる。共
有リソースは、メモリ、ネットワーク接続などである。

【００８１】最終的に、本発明の通信方法は、ＯＲＢの
内部の機構を使わないで、移植可能にする、すなわち、
いずれのＯＲＢにも使用できるようにする。

【００８２】前記通信方法は、各サービスに対するプロ
セス間のコールの数を減らす。前記通信方法は、変換
（フィルタリング、圧縮）の有無にかかわらず、メッセ
ージのパケットを送る機構によって、適用可能である場
合は、サービスそれ自体を中央に集中することによっ
て、オブジェクト−オブジェクトプロトコルの透過性を
失うことなく前記サービスに適用される。

【００８３】ある場合には、たとえば通知サービスの場
合では、呼出プロセスと宛先プロセスを独立させるのが
有利である。なぜなら、この場合、通信サービスが、プ
ロセスを非同期にするからである。

【００８４】実際は、本発明による通信方法は、実施に
かなりの自由度を持たせ、該通信方法が、様々な潜在的
な適用例に適合されることを可能にする。

【００８５】特に、サーバープロセスを用いて、クライ
アントプロセスのオブジェクトの登録を可能にする本発
明の方法を用いることが可能である。登録は、サーバプ
ロセスが、登録されたオブジェクトに、前に参照された
通知メッセージを送ることができるようにする。同じサ
ーバプロセスと共に登録することを望んでいるクライア
ントプロセスの中のオブジェクトの数は、一般的に非常
に多い。したがって、基礎をなしている通信手段（特に
データ処理ネットワーク）に負荷をかけ過ぎないため
に、登録メッセージの数を減らすことが必要である。

【００８６】本発明の方法は、このために用いられるこ
とができる。すなわち、各登録メッセージは、関連した
代理エレメント（Ｐｒｏｘｙ（Ａ））によって、呼出マ
ネージャーに送られる。呼出マネージャーは、それか
ら、単一の登録メッセージで、サーバプロセスに、登録
要求に関連するすべてのデータを送信することができ
る。

【図面の簡単な説明】

【図１】クライアントプロセスからサーバプロセスに、
メッセージを送信するオブジェクト−オブジェクトプロ
トコルの使用方法を示す図である。

【図２】サーバープロセスからクライアントプロセス
に、通知メッセージを送信するオブジェクト−オブジェ
クトプロトコルの使用方法を示す図である。

【図３】従来の技術の中央に集中された通知サービスに
よって、クライアントとサーバプロセスの間で交換され
るメッセージの管理を示す図（逆方向もまた同様）であ
る。

【図４】本発明による通信方法によるクライアントプロ
セスとサーバプロセスの間で交換されるメッセージの管
理を示す図である。

【図５】通知サービスに適用された、本発明の通信方法
によるメッセージの管理を示す図である。

【図６】メッセージパラメータを修正する機構を示す図
である。

【符号の説明】

ＯｂｊＡ、ＯｂｊＢ、ＯｂｊＣオブジェクトＳｔｕｂ（Ａ）、Ｓｔｕｂ（Ｂ）、Ｓｔｕｂ（Ｃ）、Ｓ
ｔｕｂ（Ｄ）、Ｐｒｏｘｙ（Ａ）、Ｐｒｏｘｙ（Ｂ）、
Ｐｒｏｘｙ（Ｃ）、Ｐｒｏｘｙ（Ｄ）代理エレメントＳｉｎｋＣ、ＳｉｎｋＤシンクオブジェクトＰＲＯＳＥＲＶサーバプロセスＰＲＯＣＬＩＥＮＴクライアントプロセス

───────────────────────────────────────────────────── フロントページの続き (72)発明者アレクサンドル・フエレフランス国、75013・パリ、リユ・ボビロ・33

Claims

【特許請求の範囲】

【請求項１】メッセージが、代理エレメントの対を介
して、第１のプロセスのオブジェクトから他のプロセス
のオブジェクトに送信される、ＯＲＢ分散オブジェクト
マネージャーに基づく通信方法であって、代理エレメントの対の各々が、呼出プロセスにおける第
１の代理エレメントと、他のプロセスにおける第２の代
理エレメントとを含み、前記第１のプロセスの第１の代理エレメントが修正さ
れ、その結果、前記第１のプロセスの第１の代理エレメ
ントが、所定のサービスに関連し、前記第１のプロセス
のオブジェクトによって他のプロセスのオブジェクトに
送信された、メッセージを、前記第１のプロセスにおけ
る所定のサービスに対応する呼出マネージャーへ送信
し、前記呼出マネージャーが、こうして受信したメッセージ
を管理し、メッセージのいくつかを、各宛先プロセスに
おける対応する受信マネージャーに送信する通信方法。
【請求項２】各修正された第１の代理エレメントが、
宛先プロセスにおける対応する受信マネージャーの識別
パラメータおよび宛先オブジェクトの識別パラメータを
備えた、前記所定のサービスに関連するメッセージを、
対応する呼出マネージャーに送信する請求項１に記載の
通信方法。
【請求項３】前記識別パラメータが、前記第１の代理
エレメントに関連付けられた第２の代理エレメントまた
は前記宛先オブジェクトによって、前記第１の代理エレ
メントに提供される請求項２に記載の通信方法。
【請求項４】宛先プロセスの受信マネージャーが、呼
出マネージャーから受信したメッセージを、該宛先プロ
セスの関係しているオブジェクトに送信する請求項１に
記載の通信方法。
【請求項５】前記受信マネージャーが、関係している
呼出マネージャーに転送する、メッセージに応答する結
果を受信する請求項４に記載の通信方法。
【請求項６】前記受信マネージャーが、それ自体で、
メッセージに対して、対応するサービスを提供し、適用
可能である場合、対応する結果を関係している呼出マネ
ージャーに返す請求項１に記載の通信方法。
【請求項７】メッセージおよび／または対応する結果
が、代理エレメントの対によって、呼出マネージャーと
受信マネージャーの間で、送信される請求項１に記載の
通信方法。
【請求項８】メッセージが、呼出マネージャーと受信
マネージャーの間で、共有されたリソースを用いて、送
信される請求項１に記載の通信方法。
【請求項９】呼出マネージャーまたは受信マネージャ
ーが、メッセージのパラメータおよび／または対応する
結果を修正する請求項１に記載の通信方法。
【請求項１０】メッセージおよび／または対応する結
果が、事前の変換をともなって、または事前の変換をと
もなわずに、前記呼出マネージャーと前記受信マネージ
ャーの間で、パケットで送信される請求項１に記載の通
信方法。
【請求項１１】前記パケットが、前記呼出マネージャ
ーまたは前記受信マネージャーによって定義された周期
にしたがって、周期的に送信される請求項１０に記載の
通信方法。
【請求項１２】パケットの送信が、特定のイベントの
発生によってもトリガされる請求項１１に記載の通信方
法。
【請求項１３】前記呼出プロセスがクライアントプロ
セスであり、前記宛先プロセスがサーバプロセスであ
る、サービスに適用された請求項１に記載の通信方法。
【請求項１４】前記呼出プロセスがサーバプロセスで
あり、前記宛先プロセスがクライアントプロセスであ
る、サービスに適用された請求項１に記載の通信方法。
【請求項１５】ＯＲＢ環境が、ＣＯＲＢＡ環境である
請求項１に記載の通信方法。
【請求項１６】ＯＲＢ環境が、ＤＣＯＭ環境である請
求項１に記載の通信方法。
【請求項１７】各オブジェクトが登録メッセージを送
信する、オブジェクトの集合を含むクライアントプロセ
スを、サーバプロセスに登録する方法であって、前記登録メッセージが、請求項１から１６のいずれかの
請求項に記載の方法によって、前記サーバプロセスに通
信される方法。