JPH10511794A - クライアント−サーバ環境用ブリッジ - Google Patents

Abstract

(57)【要約】 クライアント−サーバ分散コンピューティング環境においてクライアント（５３）とサーバ（５４）との間にソフトウェア・ブリッジ（３００）を設ける。このブリッジ（３００）は、クライアント（５３）に対するサーバ（５４）のインタフェースと、サーバ（５４）に対するクライアント（５３）のインタフェースとを提供する。ブリッジ（３００）は、クライアント（５３）とサーバ（５４）の間を流れる要求とそれに付随するデータのモニタまたはログのために使用され、たとえば問題判別の際に役立つ。ブリッジ（３００）はサーバ（５４）間の作業負荷分散にも使用される。ブリッジを使用してクライアント（５３）とサーバ（５４）の間のネットワーク接続を減らすこともできる。これらの利点はすべて、既存のクライアント（５３）コードまたはサーバ（５４）コードにまったく修正を加えずに得られる。

Description

【発明の詳細な説明】 クライアント−サーバ環境用ブリッジ発明の分野 本発明は、クライアント−サーバ環境における分散コンピューティングに関し 、具体的には前記環境におけるクライアントとサーバの間でのブリッジの使用に 係わる。発明の背景 オブジェクト指向プログラミングの概要 オブジェクト指向プログラミングが開発される以前に、構造化プログラミング と呼ばれるプログラミングの一形態が使用され、今でも広く使用されている。こ の技法では、まずさまざまな関数を定義し、次にプログラムがその定義された関 数を適切な時点で呼び出してアプリケーション・プログラムの全体的な目的を実 現することから成る。このような関数は、データを操作するために使用するメソ ッドを定義するが、データ自体は定義しない。構造化プログラミングはモジュー ル化手法の機会をもたらした。これは、メンテナンスやデバッグが難しい「スパ ゲッティ・コード」を克服する重要な改良であった。それにもかかわらず、構造 化プログラミングには、プログラムによってモデル化される世界における概念お よび実体と、プログラミング言語における概念との間の「意 味ギャップ」や、プログラム・コードのテキスト性、コード・モジュールの再使 用可能性の限界などいくつかの欠点も残されている。 その後、オブジェクト指向プログラミングと呼ばれる新しいプログラミング・ パラダイムが開発された。この技法では、関数を定義する代わりに、「クラス」 を定義する。クラス定義によって、そのクラスの任意のインスタンスが実行する ことができるメソッドと、そのクラスのインスタンスに含まれる属性（またはデ ータ）とを定義する。オブジェクトはクラスのメンバーであり、クラス定義で定 義されているメソッドを実際に実行することができる。オブジェクトは、クラス によって定義された各属性に付随する値を持つ。オブジェクトは、ゼロまたは１ 個以上の属性を持ち、そのオブジェクトに対して実行することができるゼロまた は１個以上のメソッドを持つ。 オブジェクトとのインタフェースは、メソッドを介して属性にアクセスするこ とができる方法である。そのクラスから導き出されるすべてのオブジェクトがそ のクラスのインタフェースを共有する。オブジェクトの実現部分はオブジェクト を呼び出すアプリケーションから隠蔽される。オブジェクトへのインタフェース が変わらない限り、アプリケーションに影響を与えることなく実現部分を完全に 変えることはできない。 オブジェクトが内部でどのように「見える」か、また内部 で何を「行う」かを記述する必要なしにオブジェクトの「外観」を記述するこの 技法を単純化した例として、また、そのようなオブジェクト指向プログラミング の重要な利点を例示するための例として、オブジェクト指向手法によってモデル 化することができる普通の家庭用トースタを考えてみる。外部「インタフェース 」は、トーストの所望の焼き加減を調節するパラメータを本質的に表すつまみと 、パンを入れるスロットと、トースタへの挿入とトースタの起動を行うレバーと から成る。重要な概念は、この種の家電製品のエンドユーザはそれを使用するた めにトースタの「内部」を知る必要がないことである。たとえば、熱が電気によ って供給されるのか、化学薬品やその他の手段によって供給されるのかを知る必 要はない。ユーザは上記の外面部と正しくインタフェースするだけでよい。 プログラミングにおけるこの進化の利点は、上記の例を続けて用いると、トー スタをモデル化するプログラミング・コードのモジュールであるオブジェクトの 設計者が、ユーザにとって内部が見えないために、たとえばユーザがそのオブジ ェタトを使用する能力に影響を与えることなくトースタの内部要素を改良するこ とに焦点を絞ることができ、効率を向上させることができることである。したが って、より抽象的に言うと、オブジェクト指向技法は本質的に、オブジェクトの インタフェースをオブジェクトの実現部分から分離する利点をもたらすものと見 なすことができる。ソフトウェア環境に おいては、それによって、外部の「つまみ」などやその予想される動作が変わら ない限り、アプリケーション・プログラム全体を書き直さなくてもオブジェクト の内部を書き直し、改良することができる。 本発明の理解を助けるオブジェクト技法に関するその他の一般的背景について は、デイビッドＡ．テイラー（Ｄａｖｉｄ Ａ．Ｔａｙｌｏｒ）による「Ｏｂｊ ｅｃｔ Ｏｒｉｅｎｔｅｄ Ｔｅｃｈｎｏｌｏｇｙ − Ａ Ｍａｎａｇｅｒ’ ｓ Ｇｕｉｄｅ」（ｃｏｐｙｒｉｇｈｔ １９９０，Ｓｅｒｖｉｏ Ｃｏｒｐｏ ｒａｔｉｏｎ）を参照されたい。 オブジェクト指向プログラミングの発展に伴い、様々な組織やソフトウェア会 社によっていくつかの「オブジェクト・モデル」がさらに改良され、開発された 。オブジェクトとその外部インタフェースを定義する方法が規定され、そのよう な様々なオブジェクト・モデルによって特にカプセル化と継承の特性が規定され た。ある程度の高レベルから見れば、これらの様々なオブジェクト・モデルはき わめて類似している。たとえば、システム・オブジェクト・モデル（ＳＯＭ）、 コモンＬｉｓｐオブジェクト・システム（ＣＬＯＳ）、Ｓｍａｌｌｔａｌｋ、お よびＣ＋＋などがある。本質的には、これらの様々なオブジェクト・モデルはオ ブジェクトが何であるかという問いに答える規則の集まりに過ぎず、より低レベ ルで検討するとそれぞれわずかに異なった答えが出る。たとえば、言語構文とカ プセル化および継承の機能はオブジェク ト・モデルによって異なる。 これらの相違の直接の結果として、異なるオブジェクト指向言語およびオブジ ェクト・モデルの使用可能性により生じる１つの問題は、そのような言語の混合 で書かれたオブジェクト・プログラム間のインターオペラビリティを実現するこ とができないことであった。この問題は、オブジェクト技法の重要な利点の１つ であるコードの再使用可能性に悪影響を与える。業界を悩ませるこの問題を解決 しようとして、委員会は共通オブジェクト要求ブローカ・アーキテクチャ（ＣＯ ＲＢＡ）に到達した。これには標準化インタフェース定義言語（ＩＤＬ）が含ま れていた。業界ではオブジェクトインタフェースをどのように規定するか、すな わち、オブジェクト・インタフェースを定義する標準に関して本質的に合意に達 し、その結果、１つのベンダーによって定義されたオブジェクトを他のベンダー が使用することが可能になった。「Ｔｈｅ Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅ ｑｕｅｓｔ Ｂｒｏｋｅｒ：Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ Ｓｐｅｃｉｆ ｉｃａｔｉｏｎ」（ＯＭＧ Ｄｏｃｕｍｅｎｔ Ｎｕｍｂｅr ９１．１２．１ Ｒｅｖｉｓｉｏｎｌ．１）を参照されたい。 オブジェクト要求ブローカ（ＯＲＢ） ＣＯＲＢＡアーキテクチャで記述されたオブジェクト要求ブローカ（ＯＲＢ） は、ＵＮＩＸオペレーティング・システ ム環境で作業をする人には周知のリモート・プロシージャ・コール（ＲＰＣ）に 似ている（ＵＮＩＸはＸ／Ｏｐｅｎ ＣＯ．Ｌｔｄ．によって独占的にライセン ス許諾される商標である）。 従来技術のシステムを第１図に示す。これは、クライアント／サーバ環境にあ る従来技術のオブジェクト要求ブローカを示すブロック図である。 このＯＲＢは２つの部分に分かれており、そのうちの部分５０はＯＲＢを使用 して各クライアントで実行され、部分５２はＯＲＢをサポートする各サーバで実 行される。ＲＰＣと同様に、ＯＲＢは１つのアドレス空間５３で稼働しているク ライアント・アプリケーション４８が別のアドレス空間５４のオブジェクト５１ と通信することができるようにする機構である。他方のアドレス空間５４、すな わちクライアント・アプリケーション４８が実行されているアドレス空間と同じ アドレス空間５３ではないアドレス空間にあるオブジェクト５１を「リモート」 オブジェクトと呼ぶ。クライアント・アプリケーション４８と同じアドレス空間 ５３にあるオブジェクトを「ローカル」オブジェクトと呼ぶ。ＯＲＢ５０は１つ のアドレス空間５３内のクライアント・アプリケーション４８からの呼出しを代 行受信し、それをネットワーク・プロトコルにカプセル化し、別のアドレス空間 ５４内のターゲット・オブジェクト５１に合わせて呼出しをデコードし、その結 果を呼び出し側クライアント・アプリケーション４８に返す 。これによって、一方のアドレス空間（ローカル）で稼働しているクライアント ・アプリケーション４８が他方のアドレス空間（リモート）内のオブジェクト５ １と通信することができる。ＯＲＢは、オブジェクト指向プログラミングによっ て得られる高度の柔軟性と能力を備えるように設計されている点で、ＲＰＣが改 良されたものである。プロキシ・オブジェクト４９の機能については後で詳述す る。 「オブジェクト・モデル」は様々な組織やソフトウェア会社によって開発され ている。オブジェクト・モデルはオブジェクトとその外部インタフェースの定義 の仕方を規定する。このようなオブジェクト・モデルの１つは、IBM Corporatio nのシステム・オブジェクト・モデル（ＳＯＭ）である。ＳＯＭでは、オブジェ クトを使用するすべてのアプリケーションはそれらのオブジェクトが入っている １つのアドレス空間内で実行される。ＳＯＭ内で作成されるものは、分散システ ム・オブジェクト・モデル（ＤＳＯＭ）と呼ばれるオブジェクト・クラスのフレ ームワークである。ＤＳＯＭでは、１つのアドレス空間内の（クライアントで稼 働している）アプリケーションは別のアドレス空間（サーバに属するアドレス空 間など）内のオブジェクトにアクセスすることができる。これらのアドレス空間 は同じシステムと異なるシステムのどちらにあってもよい。実際には、システム は同じプラットフォームで稼働している必要はない。たとえば、ＯＳ／２システ ム上のアドレス空間で稼働しているクライアント・アプリケー ションがＡＩＸ／６０００システム上のアドレス空間にあるオブジェクトにアク セスすることができ、その逆も可能である。ＳＯＭとＤＳＯＭの両方については 、IBM Corporationが発行している「ＳＯＭｏｂｊｅｃｔ：Ａ Ｐｒａｃｔｉｃ ａｌ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ ＳＯＭ ａｎｄ ＤＳＯＭ」（Ｃｏｐ ｙｒｉｇｈｔ １９９４，Ｏｒｄｅｒ ｎｏ．ＧＧ２４−４３５７−００）に記 載されている。 欧州特許出願第０５０１６１０号では、異なるプロセス内のオブジェクトが通 信することができるようにする機構が開示されている。通信アプリケーション・ プログラミング・インタフェース（ＡＰＩ）を使用するようにプログラムが明示 的に作成される。 上記のシステム・オブジェクト・モデル（ＳＯＭ）は、ＣＯＲＢＡとＩＤＬに 準拠した１つのオブジェクト・モデルである。準拠とは、ＳＯＭオブジェクトが ＣＯＲＢＡのセマンティクスに従っており、ＳＯＭオブジェクトがＩＤＬ構文で 定義されているという意味である。 ＤＳＯＭのフレームワークは、ターゲット・オブジェクトがインスタンス化さ れる場所やプラットフォームのタイプをクライアント・プログラマが知らなくて も済むようにするオブジェクト実現部を備える。このプロセス間通信に使用され る通信機構は、プログラマには見えないように完全に隠蔽される。 クライアント−サーバ・アーキテクチャ クライアント−サーバ・アーキテクチャでは、アプリケーション・プログラム は個別の構成要素として実行される個別のタスクに分けられる。各構成要素には クライアントまたはサーバの役割が割り当てられる。１つの構成要素は、ある目 的のためにはサーバの役割を果たし、他の目的のためにはクライアントの役割を 果たすことができる。各構成要素は独立して動作し、特定の責任を担う。クライ アントの役割が割り当てられた構成要素は、サーバ・プロセス内のオブジェクト に対するメソッド呼出しを行うことによって、サーバにサービスを要求する。サ ーバの役割が割り当てられた構成要素は、それらのメソッド呼出しを受け取り、 該当するオブジェクトに対してそれらのメソッド呼出しを行い、その結果をクラ イアントに返すことによってサービスを提供する。クライアントとサーバは事前 定義されたプロトコルを使用してメッセージを交換する。サーバは多くのクライ アントにサービスを提供することができ、クライアントは多くのサーバにサービ スを要求することができる。 このようなシステムでは、クライアントまたはサーバがその中に特定のコード を持っていない限り、サーバのクライアントによって行われた要求の監視やログ を行ったり、そのような要求に付随するデータの監視やログを行ったりすること ができない。問題判別のために、そのような要求の監視またはログを行うことが 望ましいと考えられる。 上述のシステムでは、サーバ間の作業負荷分散は、クライアントがクライアン ト自体内にそのような作業負荷分散機能を含むように設計されていない限り不可 能である。クライアント自体内にそのような作業負荷分散機能を組み込むことの 欠点は、クライアント内の各要求に付随するオーバーヘッドと、そのような作業 負荷分散機能を含む各クライアントに複雑さが生じることである。最高のパフォ ーマンスを提供するサーバを選定することによってクライアントの全体的なパフ ォーマンスを向上させるために、作業負荷分散が望ましい。 各クライアントと、そのクライアントがサービスを要求することができること が望ましい各サーバとの間に通信リンクを設ける必要がある。その結果、多数の クライアントと多数のサーバがあるシステムは著しく複雑化する。 背景技術 機能伝送によって、アプリケーション・プログラムはファイル制御要求を伝送 して他のシステムが所有しているファイルにアクセスすることができ、一時デー タ機能および一時記憶域機能を求める要求を伝送して他のシステム内の一時デー タ待ち行列および一時記憶待ち行列との間でデータの送受信を行うことができる 。また、ＳＮＡ ＬＵタイプ６プロトコルを実施する他のシステムでのトランザ クションの開始も可能にする。システム・プログラマは資源定義テーブルの項目 を使用して、指定資源がローカル（または要求側）システム 上ではなくリモート（または所有側）システム上にあるように指定することがで きる。機能伝送の使用は、要求側システムとリモートシステムの両方にとって透 過である。要求とそれに付随するデータの記録と監視が可能であるが、そのよう な監視機能を持たせたい各アプリケーションごとに別々に実施しなければならな い。機能伝送の詳細は、「ＣＩＣＳ／ＥＳＡ Ｖ４．１ Ｉｎｔｅｒｃｏｍｍｕ ｎｉｃａｔｉｏｎ Ｇｕｉｄｅ」（IBM Corporation発行、Ｃｏｐｙｒｉｇｈｔ １９７７、１９９４、Ｏｒｄｅｒ ｎｏ．ＳＣ３３−１１８１−００）に記載 されている。 プロキシを使用して、クライアントで稼働しているローカル・アプリケーショ ンからサーバ内のリモート資源にアクセスすることができる。プロキシとは、他 のオブジェクトの代わりとなり、そのメッセージを受信し、それらを何らかの方 法で処理することができる、第１図のプロキシ・オブジェクト４９のようなオブ ジェクトである。これには、メッセージを第１図の５１などのターゲット・オブ ジェクトに転送することが含まれることが多い。プロキシは、オブジェクト指向 プログラミングで周知であり、ＤＳＯＭ（分散システムオブジェクト・モデル） によって使用される。詳細については、ＳＯＭｏｂｊｅｃｔｓ Ｐｕｂｌｉｃａ ｔｉｏｎｓに含まれているＳＯＭｏｂｊｅｃｔｓ Ｄｅｖｅｌｏｐｅｒ Ｔｏｏ ｌｋｉｔ Ｕｓｅｒ'ｓ Ｇｕｉｄｅ Ｖｅｒｓｉｏｎ２．０（IBM Corporation 発行、Ｃｏｐｙｒｉｇｈｔ １９９４、Ｏ ｒｄｅｒ ｎｏ．Ｓ９６Ｆ−８６４９）を参照されたい。プロキシは、クライア ントからサーバに送られる要求メッセージを受け取り、サーバからクライアント に送られる戻りメッセージを受け取る。プロキシは、クライアントに宛てられた サーバからの非同期戻りメッセージを受け取ることはできない。プロキシは、一 般にサーバ内の単一のターゲット・オブジェクトに関連づけられ、単一のサーバ 内または複数のサーバ内の複数のオブジェクトに関連づけられることはない。 欧州特許出願第０５１８１９５号では、アプリケーション・プログラムにリン クされたライブラリ・ルーチンによって実施されるプラットフォーム独立アプリ ケーション・プログラミング・インタフェース（ＡＰＩ）が開示されている。ア プリケーション・プログラムはそのＡＰＩに合わせて特別に作成され、クライア ント・プロセスおよびサーバ・プロセスはＡＰＩを明示的に知ってそれを使用し なければならない。この実施態様の問題点は、クライアントとサーバにリダイレ クトがわからないようにクライアント−サーバ・フローを代行受信する透過的な 機構を備えないことである。 ＰＣＴ特許出願ＷＯ９５／１７７１８号では、オペレーティング・システムと 統合された、リモート・プロシージャ・コール（ＲＰＣ）とのオブジェクト指向 インタフェースが開示されている。クライアント・プログラムとサーバ・プログ ラムは、互いに通信するときにＲＰＣアプリケーション・プログラミング・イン タフェース（ＡＰＩ）を利用するように 特別に作成される。この実施態様も、クライアントとサーバにリダイレクトがわ からないようにクライアント−サーバ・フローを代行受信する透過的機構を備え ない。 ＰＣ Ｍａｇａｚｉｎｅ ｖ１３，ｎ１０（１９９４年５月３１日発行、Ｇａ ｇｎｏｎ Ｇ）の「Ｂｕｉｌｄｉｎｇ ａ ｂｅｔｔｅｒ ａｐｐ、ＳＱＬ ｓ ｔｙｌｅ」では、共通ＡＰＩを多くの異なるＡＰＩにマップすることができるよ うにする方法が開示されている。 ＤＢＭＳ，ｖ５，ｎ９（１９９２年８月発行、Ｒｏｔｉ Ｓ）の「ＳＱＬ＊Ｎ ＥＴ ｖｅｒｓｉｏｎ２：ｃｌｉｅｎｔ／ｓｅｒｖｅｒ ｎｅｔｗｏｒｋｉｎｇ ｉｓ ｅａｓｉｅｒ ｗｉｔｈ ＳＱＬ＊ＮＥＴ Ｖ２ ａｎｄ ｔｈｅ Ｍ ｕｌｔｉＰｒｏｔｏｃｏｌ Ｉｎｔｅｒｃｈａｎｇｅ」では、１つのＡＰＩから もう１つのＡＰＩに変換する中間構成要素が開示されている。この中間要素はそ れに対して要求される変換タスクを実行するように特別に作成される。この中間 要素がないと、その２つのＡＰＩに合わせて作成された構成要素は通信すること ができない。発明の開示 したがって、本発明は、分散オブジェクト指向コンピュータ・システムにおい てクライアントとサーバの間で使用するブリッジを提供する。このブリッジは、 サーバのインタフェースに対応するクライアントとのインタフェースと、クライ アントのインタフェースに対応するサーバとのインターネットとを定義する。 第１の実施例では、クライアントとサーバは非同期的に動作し、ブリッジはク ライアントおよびサーバから継承によって導き出され、ブリッジはサーバから継 承されたメソッドを上書きして、要求を行うクライアントの名前を記録し、その 要求をサーバに転送し、ブリッジはクライアントから継承したメソッドを上書き してクライアントに応答パラメータを転送する。 第２の実施例では、クライアントとサーバは同期して動作し、ブリッジは継承 によってサーバから導き出され、ブリッジはサーバから継承されたメソッドを上 書きしてサーバ上のメソッドを呼び出し、クライアントに応答パラメータを転送 する。 好ましい実施例では、ブリッジはクライアントとサーバとの間の要求とその要 求に付随するデータの監視と記録を行う手段をさらに含む。また、好ましい実施 例では、ブリッジは、サーバ間の作業負荷分散を行う手段をさらに含む。そのよ うな作業負荷分散は、応答時間を測定し、測定された応答時間に応じてサーバに クライアント要求を送ることによって行うことができる。他の好ましい実施例で は、ブリッジはｍ個のクライアントとｎ個のサーバ（ただしｎおよびｍは２以上 の整数）に接続され、ブリッジはネットワーク接続数をｎ＊ｍ個からｎ＋ｍ個に 減らす。 分散オブジェクト指向コンピュータ・システムはＣＯＲＢＡ準拠システムであ り、分散オブジェクト指向コンピュータ・システムはＤＳＯＭクラス・ライブラ リを使用することが好ましい。しかし、本発明はそのようなシステムでの応用や そのようなクラス・ライブラリの使用には限定されない。たとえば、分散オブジ ェクト指向システムはマイクロソフトのコンポーネント・オブジェクト・モデル （ＣＯＭ）に準拠していてもよい。また、分散オブジェクト環境としてＳｕｎＳ ｏｆｔから、およびＯＲＢプラスとしてヒューレット・パッカードＣｏ．から入 手可能な、分散オブジェクト管理機能（ＤＯＭＦ）を使用することもできる。 本発明は、分散クライアント−サーバ・コンピュータ・システムを稼働させる 方法であって、ブリッジのために、サーバのインタフェースに対応するクライア ントとのインタフェースを定義するステップと、クライアントのインタフェース に対応するサーバとのインタフェースを定義するステップとを含む方法も提供す る。 第１の実施例では、クライアントとサーバは非同期的に動作し、クライアント とのインタフェースを定義するステップが、クライアント・インタフェースをサ ーバから継承によって導き出すステップと、サーバから継承した方法を上書きし て、要求を行うクライアントの名前を記録し、その要求をサーバに転送するステ ップとを含み、サーバとのインタフェースを定義するステップが、前記サーバ・ インタフェースをク ライアントから継承によって導き出すステップと、前記クライアントから継承し たメソッドを上書きして前記クライアントに応答パラメータを転送するステップ とを含む。 第２の実施例では、クライアントとサーバは同期して動作し、クライアントと のインタフェースを定義するステップが、クライアント・インタフェースをサー バから継承によって導き出すステップと、サーバから継承したメソッドを上書き してサーバ上でメソッドを呼出し、クライアントに応答パラメータを転送するス テップとを含む。 本発明は、１つまたは複数のサーバと、１つまたは複数のクライアントと、前 述のブリッジとを含む分散オブジェクト指向コンピュータ・システムも提供する 。図面の簡単な説明 以下に本発明の実施例について例として添付図面を参照しながら説明する。 第１図は、クライアント／サーバ環境にある従来技術のオブジェクト要求ブロ ーカを示すブロック図である。 第２図は、本発明と共に使用するのに適した従来技術のコンピュータ・システ ムを示すブロック図である。 第３図は、非同期的に動作するように構成された従来技術のクライアントとサ ーバを含むシステムを、本発明のブリッジと共に示すブロック図である。 第４図は、従来技術のクライアントとサーバの非同期動作 を示す流れ図である。 第５図は、本発明による第３図のシステムの非同期動作を示す流れ図である。 第６図は、同期して動作するように構成された従来技術のクライアントとサー バを含むシステムを、本発明のブリッジと共に示すブロック図である。 第７図は、従来技術のクライアントとサーバの同期動作を示す流れ図である。 第８図は、本発明による第６図のシステムの同期動作を示す流れ図である。 第９図は、本発明によるブリッジを使用した複数のサーバ間の作業負荷分散を 示すブロック図である。 第１０図は、複数のクライアントと複数のサーバの従来技術の接続を示すブロ ック図である。 第１１図は、本発明によるブリッジを使用した複数のクライアントと複数のサ ーバとの接続を示すブロック図である。発明の詳細な説明 本発明を実施することができる適合するハードウェア 本発明は、いくつかの異なるオペレーティング・システム下にある様々なコン ピュータまたはコンピュータの集合上で実行することができる。コンピュータは 、たとえばパーソナル・コンピュータ、ミニ・コンピュータ、メインフレーム・ コンピュータ、または他のコンピュータの分散ネットワーク 内で稼働するコンピュータとすることができる。特定のコンピュータの選定はメ モリおよびディスクの必要記憶容量によってのみ限定されるが、本発明ではＩＢ Ｍ ＰＳ／２シリーズのコンピュータを使用することができる（ＩＢＭはIBM Co rporationの登録商標であり、ＰＳ／２は商標である）。ＩＢＭのＰＳ／２シリ ーズ・コンピュータの詳細については、Ｔｅｃｈｎｉｃａｌ Ｒｅｆｅｒｅｎｃ ｅ Ｍａｎｕａｌ Ｐｅｒｓｏｎａｌ Ｓｙｓｔｅｍ／２（Ｍｏｄｅｌ ８０） （ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ Ｐａｒｔ Ｎｏ．６８Ｘ ２２５６ Ｏｒ ｄｅｒ Ｎｕｍｂｅｒ Ｓ６８Ｘ−２２５４）を参照されたい。ＩＢＭ ＰＳ／ ２パーソナル・コンピュータで実行することができるオペレーティング・システ ムはＩＢＭのＯＳ／２ ２．０であり、ＩＢＭ ＯＳ／２ ２．０オペレーティ ング・システムの詳細については、ＯＳ／２ ２．０ Ｔｅｃｈｎｉｃａｌ Ｌ ｉｂｒａｒｙ，Ｐｒｏｇｒａｍｍｉｎｇ Ｇｕｉｄｅ Ｖｏｌ．１，２，３ Ｖ ｅｒｓｉｏｎ ２．００（Ｏｒｄｅｒ Ｎｏｓ．１０Ｇ６２６１，１０Ｇ６４９ ５、１０Ｇ６４９４）を参照されたい（ＯＳ／２はIBM Corporationの商標であ る）。 代替実施例では、コンピュータ・システムはＡＩＸオペレーティング・システ ム上で稼働するＩＢＭ ＲＩＳＣ Ｓｙｓｔｅｍ／６０００ラインのコンピュー タとすることができる（ＲＩＳＣ Ｓｙｓｔｅｍ／６０００およびＡＩＸはIBM Corporationの商標である）。ＲＩＳＣ Ｓｙｓｔｅｍ／６０ ００の様々なモデルについては、たとえばＲＩＳＣ Ｓｙｓｔｅｍ／６０００， ７０７３および７０１６ ＰＯＷＥＲｓｔａｔｉｏｎ ａｎｄ ＰＯＷＥＲｓｅ ｒｖｅｒ Ｈａｒｄｗａｒｅ Ｔｅｃｈｎｉｃａｌ Ｒｅｆｅｒｅｎｃｅ（Ｏｒ ｄｅｒ Ｎｏ．ＳＡ２３−２６４４−００）など、IBM Corporationの多くの刊 行物に記載されている（ＰＯＷＥＲｓｔａｔｉｏｎおよびＰＯＷＥＲｓｅｒｖｅ ｒはIBM Corporationの商標である）。ＡＩＸオペレーティング・システムにつ いては、Ｇｅｎｅｒａｌ Ｃｏｎｃｅｐｔｓ ａｎｄ Ｐｒｏｃｅｄｕｒｅ−− ＡＩＸ Ｖｅｒｓｉｏｎ３ ｆｏｒ ＲＩＳＣ Ｓｙｓｔｅｍ／６０００（Ｏｒ ｄｅｒ Ｎｏ．ｓｃ２３−２２０２−００）およびIBM Corporationのその他の 刊行物に記載されている。 第２図には、システム・ユニット１１と、キーボード１２と、マウス１３と、 表示装置１４を含むコンピュータ１０のブロック図が図示されている。システム ・ユニット１１は、１本または複数のシステム・バス２１を含み、システム・バ スには様々な構成要素が接続され、それによって様々な構成要素間の通信を行う 。マイクロプロセッサ２２がシステム・バス２１に接続され、やはりシステム・ バス２１に接続された読取り専用メモリ（ＲＯＭ）２３とランダム・アクセス・ メモリ（ＲＡＭ）２４によってサポートされている。ＩＢＭ ＰＳ／２シリーズ のコンピュータのマイクロプロセッサは、３８６または４８６マイクロプロセッ サを含むインテル・ ファミリのマイクロプロセッサのうちの１つである。しかし、６８０００、６８ ０２０、または６８０３０マイクロプロセッサなどのモトローラのマイクロプロ セッサ・ファミリや、ＰｏｗｅｒＰＣチップなどのＩＢＭ製の様々な縮小命令セ ット・コンピュータ（ＲＩＳＣ）マイクロプロセッサその他のマイクロプロセッ サ、またはヒューレット・パッカード、サン、モトローラおよびその他のマイク ロプロセッサなど、他のマイクロプロセッサもこの特定のコンピュータで使用す ることができる。 ＲＯＭ２３は、他のコードの他に、ライブ、キーボードなどの基本ハードウェ ア動作を制御する基本入出力システム（ＢＩＯＳ）を含む。ＲＡＭ２４は、オペ レーティング・システムとアプリケーション・プログラムがロードされるメイン ・メモリである。メモリ管理チップ２５がシステム・バス２１に接続され、ＲＡ Ｍ２４とハードウェア・ディスク・ドライブ２６とフロッピィ・ディスク・ドラ イブ２７との間のデータの受渡しを含む直接メモリ・アクセス操作を制御する。 システム・バス２１にはＣＤ ＲＯＭ３２も結合され、たとえばマルチメディア ・プログラムやプレゼンテーションなど大量のデータを記憶するために使用され る。 このシステム・バス２１には、様々な入出力コントローラ、キーボード・コン トローラ２８、マウス・コントローラ２９、ビデオ・コントローラ３０、および オーディオ・コントローラ３１も接続される。当然ながら、キーボード・コント ローラ２８はキーボード１２のハードウェア・インタフェース、マウス・コント ローラ２９はマウス１３のハードウェア・インタフェース、ビデオ・コントロー ラ３０は表示装置１４のハードウェア・インタフェース、オーディオ・コントロ ーラ３１はスピーカ１５ａおよび１５ｂのハードウェア・インタフェース機能を 備える。トークン・リンク・アダプタなどの入出力コントローラ４０によって、 他の同様に構成されたデータ処理システムとネットワーク４６を介して通信する ことができる。 本発明の好ましい実施例の１つでは、第１図を参照しながら前述した命令４８ 〜５２のセットが、大体前述のように構成された１つまたは複数のコンピュータ ・システムのランダム・アクセス・メモリ２４に入っている。この１組の命令は 、コンピュータ・システムが必要とするまで、たとえばハードウェア・ディスク ・ドライブ２６、または最終的にＣＤ−ＲＯＭ３２で使用される光ディスクまた は最終的にフロッピィ・ディスク・ドライブ２７で使用されるフロッピィ・ディ スクなどの取り外し可能メモリなど、別のコンピュータ・メモリに記憶すること ができる。ＯＲＢを使用して相互に結合されるメモリ・アドレス空間は、ネット ワーク４６を介して通信する別々のシステムに存在することもでき、第２図に示 すように１つのコンピュータ・システムのメモリ内の２つ以上のアドレス空間５ ３、５４とすることもできる。 ブリッジ 第３図を参照すると、本発明ではクライアント５３とサーバ５４の間にブリッ ジ３００を設ける。このブリッジ３００の目的は、サーバ５４に宛てられたクラ イアント５３からの要求を受け取り、その要求をサーバ５４に転送し、クライア ント５３に宛てられたサーバ５４からの応答を受け取り、その応答をクライアン ト５３に転送することである。ブリッジ３００は、サーバ５４のインタフェース に対応するクライアント５３とのインタフェースと、クライアント５３のインタ フェースに対応するサーバ５４とのインタフェースとを提供する。このようにし て、クライアント５３とサーバ５４のいずれもブリッジ３００の存在を判断する ことができず、両者ともブリッジが存在しないかのように動作する。 本発明の実施例について説明する。１つは非同期環境用で稼働し、１つは同期 環境で稼働するものである。非同期環境（第５図に示す）では、クライアント５ ３はサーバ５４からの応答を待つ間、他の処理を続ける。同期環境（第８図に示 す）では、クライアント５３はサーバ５４からの応答を待ってから処理を続ける 。 非同期環境 第３図を参照すると、非同期モードで動作するクライアントとサーバと共に使 用するブリッジ３００の構成要素が含まれている。クライアント５３、ブリッジ ３００、およびサー バ５４はすべて、ＤＳＯＭ用語で「サーバ・オブジェクト」と呼ばれるものを備 える。これらはそれぞれ、「クライアントのサーバ・オブジェクト」４０４、「 ブリッジのサーバ・オブジェクト」３０１、および「サーバのサーバ・オブジェ クト」５０１として図示されている。これらのオブジェクトを、サーバが実行す る機能やサーバ自体と混同してはならない。サーバ・オブジェクトとは、サーバ 内のオブジェクトを管理してクライアント・アプリケーションがサーバ内のオブ ジェクトの作成と破棄を行うことができるようにするオブジェクトである。サー バ・オブジェクトは、サーバ内のどのオブジェクトが要求を処理すべきかを識別 し、受信したそのサーバに対するそのような要求を、識別したオブジェクトにデ ィスパッチして実行させる。 クライアント５３は、クライアントのオブジェクト」４０３と呼ばれる少なく とも１つのオブジェクトを含む。このオブジェクトは、クライアントにおいてサ ーバ５４に対してサービスの提供を求める要求のイニシエータである。クライア ント・アプリケーション（図示せず）が「クライアントのオブジェクト」４０３ に対して呼び出しを行い、データに対する操作を実行する。これらの操作は、「 クライアントのオブジェクト」４０３自体内でローカルに行われるか、またはサ ーバ５４にサービスを要求する「クライアントのオブジェクト」４０３を使用し てリモートで行われる。サーバ５４は、「サーバのオブジェクト」５０３（サー バ・オブジェクトと 混同してはならない）と呼ばれる少なくとも１つのオブジェクトを含む。これは 、第１図および第２図を参照しながら前述したターゲット・オブジェクトに相当 する。これは、「クライアントのオブジェクト」４０３によって要求されたサー ビスを実際に提供するオブジェクトである。ブリッジ３００は、「ブリッジのオ ブジェクト」３０４と呼ぶオブジェクトを含み、ブリッジ自体の機能を備える。 プロキシ・オブジェクト クライアント５３、ブリッジ３００、およびサーバ５４はすべて、ＤＳＯＭ用 語でプロキシ・オブジェクトと呼ばれるものを備える。プロキシ・オブジェクト とは、リモート・ターゲット・オブジェクトの代わりをするローカルの代理であ る。プロキシ・オブジェクトは、ターゲット・オブジェクトのインタフェースを 継承し、それによって同じメソッドに応答する。プロキシ・オブジェクト上で呼 び出されたメソッドはローカルでは実行されず、実ターゲット・オブジェクトに 転送されて実行される。クライアントで稼働しているプログラムは、そのプログ ラムがそれに対して操作を行うサーバ内の各リモート・オブジェクトのローカル ・プロキシ・オブジェクトをクライアント内に常に有する。プロキシ・オブジェ クトはその内部に、ターゲット・オブジェクトが入っているサーバ内の記憶場所 を指すポインタを含む。プロキシ・オブジェクトは、リモート・オブジェクトに 対するメソッドを呼 び出すようにリモート・サーバに対して要求が行われると、ＤＳＯＭ実行時環境 によって作成される。 クライアント５３は、「ブリッジのサーバ・オブジェクト」３０１の代わりを するローカルにおける代理である「ブリッジのサーバ・プロキシ」（４０１）と 呼ぶプロキシ・オブジェクトを含む。クライアントは、これがサービスを提供す るサーバ内の「サーバのサーバ・オブジェクト］５０１の代理をするものとみな す。同様に、ブリッジ３００は、「サーバのサーバ・オブジェクト」５０１のロ ーカルにおける代理である「サーバのサーバ・プロキシ」３０２と呼ぶプロキシ ・オブジェクトを含む。前述のように「サーバ・オブジェクト」とは、サーバ内 のオブジェクトを管理するオブジェクトである。 クライアント５３は、「ブリッジのオブジェクト」３０４のローカルにおける 代理である「ブリッジのオブジェクト・プロキシ」４０２と呼ぶプロキシ・オブ ジェクトも含む。クライアントはこの代理を、サービスを提供するサーバ内のオ ブジェクト５０３であるとみなす。同様に、ブリッジ３００は、「サーバのオブ ジェクト」５０３のローカルの代理である「サーバの・オブジェクト・プロキシ 」３０３と呼ぶプロキシ・オブジェクトを含む。これらのプロキシは、クライア ント５３によって開始されるクライアント５３とサーバ５４との間の通信に使用 される。非同期システムでは、サーバ５４がクライアント５３宛ての応答を持っ ている場合、通信は サーバ５４によっても開始される。これらの通信は、サーバ５４がブリッジ３０ ０と通信することができるようにするサーバ内にある「ブリッジのオブジェクト ・プロキシ」５０２と、ブリッジ３００がクライアント５３と通信することがで きるようにするブリッジ３００内にある「クライアントのオブジェクト・プロキ シ」３０５とを使用して行われる。 上記の説明からわかるように、第３図でクライアント５３、ブリッジ３００、 およびサーバ５４を示す各ブロックの上部にあるオブジェクトとプロキシ・オブ ジェクトは、クライアントとブリッジによるオブジェクトの作成、破棄、および 探索に使用される。第３図でクライアント５３、ブリッジ３００、およびサーバ ５４を示す各ブロックの下部にあるオブジェクトとプロキシ・オブジェクトは、 クライアント５３とブリッジ３００とサーバ５４との間における通信プロセスに 使用される。 第４図に、非同期環境における従来技術のクライアントと従来技術のサーバと の間で従来技術のネットワークを介して行われる対話を示す。非同期環境では、 クライアントはサーバに対してサービスを提供するように求める要求を行うこと によってサーバとの通信を開始する。サーバはその要求に肯定応答し、クライア ントは他の処理を続ける。サーバは遅延後に要求を処理することができ、サーバ もその遅延の間に他の処理を実行することができる。サーバは要求を処理すると 、クライアントに応答を送ることによってクライアントとの 別の通信を開始する。この通信は、「サーバ」が「クライアント」に対して、前 の要求からの応答を受け入れるように求める要求を事実上行うことによって開始 される。このような状況では、「サーバ」と「クライアント」が逆の役割を持っ ていると見なすことができ、サーバはクライアントに対して応答を受け入れるよ うに要求する。非同期的に動作している場合にクライアントが「サーバ・オブジ ェクト」を必要とするのはこのためである。 ステップ３１０で、クライアントはサーバに対してサービスの提供を求める要 求を行う。この要求はステップ３２０でネットワークを介してサーバに送信され る。サーバはステップ３２２でクライアントに即時肯定応答を送信する。サーバ はステップ３３０でサービス要求を受け入れ、ステップ３３２でサービス要求を 処理する。サーバが要求を処理している間、クライアントはステップ３１２で他 の処理を行っている。サーバも、この要求を処理する前に他の要求を処理するこ とができる。ステップ３３２で要求の処理が完了すると、ステップ３３４でサー バはクライアントに応答３２４を送る。この応答はステップ３１４で受信され、 クライアントは処理を続ける。 第４図の非同期システムにブリッジを挿入した場合に行われる対話を第５図に 示す。ステップ３１０、３１２、および３１４での対話は第４図と同じであり、 ステップ３３０、３３２、および３３４でのサーバの対話も同じである。要求３ ２０、即時応答３２２、および応答３２４は、それに対応するクライアントとブ リッジとの間と、ブリッジとサーバとの間の応答に分割される。以下に、これら の対話に応答するブリッジの動作について述べる。ステップ３１０で要求３２０ Ａがクライアントからブリッジに送られる。ブリッジはステップ４１０でクライ アントに即時肯定応答３２２Ａを送り、ブリッジはサービス要求３２０Ａを受け 入れる。ブリッジは要求を処理する代わりに、ステップ４１２でクライアント名 を記録し、ステップ４１４で別途処理があればそれを実行する。 この別途処理は、クライアントからの要求またはそれに付随するデータに対し て実行することが望ましいものであればどのような別途処理でもよい。このよう な処理は、要求またはそれに付随するデータに変更を加えることもあれば、その まま変えない場合もある。このような処理の例としては次のような処理がある。 １．要求で詳述されているメソッドが、要求に付随するデータと等しいパラメー タを使用して呼び出されたことをログする。 ２．サーバ間の作業負荷分散を行うためにいくつかのサーバのうちのどのサーバ にこの要求を送るべきかを判断する処理を行い、その結果を使用して要求の送り 先を決める。 ３．要求を検査してどのサーバをクライアントが要求の送信先とみなしていたか を調べ、それからブリッジによってその サーバに送る。 ステップ４１６で、ブリッジはサービス要求３２０Ｂをサーバに転送する。サ ーバはステップ３３０で即時肯定応答３２２Ｂをブリッジに送る。サーバが要求 を処理している間、ブリッジはステップ４２０で他の処理を実行している。ステ ップ３３２でサーバによる要求の処理が完了すると、サーバはステップ３３４で ブリッジに応答３２４Ａを送る。この応答はステップ４３０で受け取られ、サー バからクライアントに返されるパラメータのログなどの別途処理があればそれが ステップ４３２でブリッジによって行われる。ブリッジは次にステップ４３４で クライアントに応答３２４Ｂを転送する。 ブリッジ（第３図の３００）はクライアント・オブジェクトおよびサーバ・オ ブジェクトから継承によって導き出される。これは、クライアント・オブジェク トとサーバ・オブジェクトの両方のインタフェース（すなわち全ての属性および メソッド）がブリッジによって継承されることを意味する。例１に、非同期シス テムの場合にブリッジがＩＤＬ言語でどのように定義されるかを示す。 例１−非同期ブリッジ・クラスの定義 同期環境 第６図を参照すると、同期モードで動作するクライアント５３とサーバ５４と 共に使用するブリッジ３００の構成要素が含まれている。ブリッジ３００とサー バ５４は「サーバ・オブジェクト」を含む。これらは、それぞれ「ブリッジのサ ーバ・オブジェクト」３０１と「サーバのサーバ・オブジェクト」５０１である 。サーバ５４は、「サーバのオブジェクト」５０３（サーバ・オブジェクトと混 同してはならない）と呼ぶ少なくとも１つのオブジェクトを含む。これが、クラ イアントによって要求されたサービスを実際に提供するオブジェクトである。ブ リッジ３００は、ブリッジ自体の機能を備える「ブリッジのオブジェクト」３０ ４と呼ぶオブジェクトを含む。 クライアント５３は、「ブリッジのサーバ・オブジェクト」３０１のローカル における代理である「ブリッジのサーバ・プロキシ」４０１と呼ぶプロキシ・オ ブジェクトを含む。クライアントは、これがサービスを提供するサーバ内の「サ ーバのサーバ・オブジェクト」５０１の代わりをするとみなす。同様に、ブリッ ジ３００は、「サーバのサーバ・オブジェクト」５０１のローカルにおける代理 である「サーバのサーバ・プロキシ」３０２と呼ぶプロキシ・オブジェクトを含 む。前述のように、「サーバ・オブジェクト」とはサーバ内のオブジェクトを管 理するオブジェクトである。 クライアント５３は、「ブリッジのオブジェクト」３０４のローカルの代理で ある「ブリッジのオブジェクト・プロキシ」４０２と呼ぶプロキシ・オブジェク トも含む。クライアントは、これがサービスを提供するサーバ内の「オブジェク ト」５０３の代わりをするとみなす。同様に、ブリッジ３００は、「サーバのオ ブジェクト」５０３のローカルにおける代理である「サーバのオブジェクト・プ ロキシ」３０３と呼ぶプロキシ・オブジェクトを含む。これらのプロキシは、ク ライアント５３によって開始されるクライアント５３とサーバ５４との間の通信 で使用される。 同期システムでは、クライアント５３によって通信が開始される。これらの通 信は、クライアント５３がブリッジ３００と通信することができるようにするク ライアント５３内にある「ブリッジのオブジェクト・プロキシ」４０２と、ブリ ッジ３００がサーバ５４と通信することができるようにするブリッジ３００内に ある「サーバのオブジェクト・プロキシ」３０３とを使用して行われる。 第６図からわかるように、クライアント５３、ブリッジ３００、およびサーバ ５４を示す各ブロックの上部にあるオブジェクトとプロキシ・オブジェクトは、 クライアントとブリッジによるオブジェクトの作成、破棄、および探索に使用さ れる。クライアント５３、ブリッジ３００、およびサーバ５４を示す各ブロック の下部にあるオブジェクトとプロキシ・オブジェクトは、クライアント５３とブ リッジ３００とサーバ５４との間の通信処理に使用される。 第７図に、同期環境において従来技術のクライアントと従来技術のサーバとの 間で従来技術のネットワークを介して行われる対話を示す。同期環境では、クラ イアントがサーバにサービスの提供を求める要求を行うことによってサーバとの 通信を開始する。サーバはその要求を処理し、要求の処理からの単純な戻りによ ってクライアントにその結果を返す。サーバはこの応答を戻すためにクライアン トとの通信を開始しない。クライアント５３は応答を、サーバ５４上で呼び出し たメソッドからの戻りパラメータを介して受け取るだけである。 従来技術のシステムでは、第４図を参照しながら前述した同期環境と非同期環 境における動作には相違点が２つある。第１の相違は、ステップ３１０でクライ アントがサービスを 求める要求を行った後、クライアントはステップ３１２で他の処理を実行せず、 ステップ５１０でサーバからの応答を待つことである。第２の相違点は、サーバ がステップ３２２でクライアントに対して即時肯定応答を送らないことである。 それ以外は、第７図に示す番号付きのステップは、第４図の対応する番号の付い たステップと同じである。 第７図の同期システムにブリッジを挿入した場合に行われる対話を第８図に示 す。ステップ３１０および３１４でのクライアントの対話は第７図と同じであり 、ステップ３３０、３３２、および３３４でのサーバの対話も同じである。要求 ３２０と応答３２４は、クライアントとブリッジとの間と、ブリッジとサーバと の間の対応する応答に分割される。以下に、これらの対話に応答するブリッジの 動作について述べる。 ステップ４１０で、ブリッジはサービス要求３２０Ａを受け入れる。ブリッジ はこの要求を処理する代わりに、ステップ４１２でクライアント名を記録し、別 途処理があればそれをステップ４１４で行う。この別途処理には、非同期環境に 関連して第５図を参照しながら前述した別途処理項目の一部または全部が含まれ る。ステップ４１６で、ブリッジはサービス要求をサーバに転送する。サーバが 要求を処理している間、ブリッジはステップ６１０でサーバからの応答を待つ。 ステップ３３２でサーバによる要求の処理が完了すると、サーバはステップ３３ ４でブリッジに応答３２４Ａを送る。こ の応答はステップ４３０で受け取られ、サーバからクライアントに返されたパラ メータのログなどの別途処理があればそれがステップ４３２でブリッジによって 行われる。ブリッジ３００は次にステップ４３４でクライアントに応答３２４Ｂ を返す。 上述の説明からわかるように、クライアントはブリッジと同期して動作し、し たがってクライアントがブリッジから見るインタフェースは、クライアントがサ ーバと直接通信している場合と同じである。ブリッジはサーバと同期して動作し 、したがってサーバがブリッジから見るインタフェースはサーバがクライアント と直接通信している場合と同じである。 ブリッジはサーバのみから導き出される。クライアント５３はサーバ５４上で メソッドを呼び出し、それと同じメソッド内の戻りパラメータを介して応答を受 け取るだけなので、明示的なクライアント・オブジェクトは不要である。別個の 通信がサーバ５４によって開始されることはない。同期システムの場合のオブジ ェクト３００の定義を例２に示す。 例２−同期ブリッジ・クラスの定義 以上、非同期動作と同期動作の両方の場合について、ブリッジの構造と定義を 定義した。いずれかの動作方法で使用するようにブリッジを定義したら、定義し たブリッジをクライアントとサーバの間に透過的に挿入し、それによってサーバ 作成要求が行われた場合にサーバ・オブジェクトの全インタフェースを備えたブ リッジが代わりに作成されるようにする必要がある。 クライアント５３とサーバはそれぞれのクライアント・クラスとサーバ・クラ スのインスタンスを含む。リモート・オブジェクトの検索、リモート・オブジェ クトのインスタンスの作成、およびリモート・オブジェクトに対するメソッドの 呼出しに使用可能な方法は様々ある。 典型的な従来技術の方法について、第１図に戻って参照しながら以下に説明す る。 １．ＤＳＯＭオブジェクト・マネージャ（ＳＯＭＤ ＯｂｊｅｃｔＭｇｒ）（５ ０にある）が、クライアントが初期設定 されたときに作成されているか、または、クライアント５３でオブジェクト要求 ブローカ５０の一部として使用可能なＳＯＭＤ Ｉｎｉｔ（）関数を呼び出すこ とによってこの時点で作成しなければならない。 ２．クライアント５３と共に使用する適切なオブジェクト・クラスのサーバ５４ を探し出すために、クライアント５３はＳＯＭＤＯｂｊｅｃｔ Ｍｇｒに対して メソッドを実行する。ＳＯＭＤＯｂｊｅｃｔ Ｍｇｒは、リモート・サーバ５４ 上の「サーバ・オブジェクト」（５２にある）のローカルにおける代理として、 クライアント５３内にプロキシ・オブジェクト（５０にある）を作成する。リモ ート・サーバ５４内には「サーバ・オブジェクト」はまだ存在しないことに留意 されたい。 ３．クライアント５３はサーバ・プロキシ・オブジェクトに対してＳｏｍｄＣｒ ｅａｔｅＯｂｊ（）メソッド呼出しを出す。このメソッド呼出しにはパラメータ として、クライアントが作成したいターゲット・オブジェクト５１のクラスが含 まれる。リモート・サーバとの通信が確立され、リモート・サーバ５４上で適切 なタラスの「サーバ・オブジェクト」（図示せず）が作成される。「サーバ・オ ブジェクト」（図示せず）が作成されると、その「サーバ・オブジェクト」は要 求されたクラスのターゲット・オブジェクト５１をサーバ５４自体内に作成する 。戻りパラメータの一部として、クライアント５３に情報が供給され、ターゲッ ト・オブジェクト５ １のプロキシ・オブジェクト４９を作成することができるようにする。 ４．これでクライアントはそのローカル・プロキシ・オブジェクト４９に対して メソッド呼出しを出すことができるようになり、それらのメソッドがターゲット ・オブジェクト５１で実行され、その結果がクライアント５３に返される。 「サーバ・オブジェクト」のクラスが複数ある場合がある。たとえば、プリン ト・サービスを提供するために使用されるサーバのクラスと、ファイル記憶サー ビスのためのクラスと、通信サービスのためのクラスがある場合がある。従来の 技術では、これらのクラスは本発明の支援なしに互いに通信する。 以下に、ブリッジをクライアントとサーバの間に透過的に挿入する方法につい て第３図を参照しなら説明する。 従来技術の各「サーバ・オブジェクト」クラスに対応するブリッジ・クラスを 作成する。「サーバのサーバ・オブジェクト」５０１は従来技術の「サーバ・オ ブジェクト」クラスのインスタンスである。「ブリッジのサーバ・オブジェクト 」３０１はデフォルト・サーバ・クラスのサブクラスである。上記の例では、プ リント・サービスの提供に使用するサーバのブリッジ・クラスと、ファイル記憶 サービスに使用されるブリッジ・クラスと、通信サービスに使用されるブリッジ ・クラスとがある。 各ブリッジ・サーバ・クラスの定義内の「サーバ・オブジ ェクト」（サーバ・クラスから継承される）を修正し、ブリッジ・サーバ・クラ スのメンバとして「ブリッジのサーバ・オブジェクト」３０１が作成されるとそ れにその修正が組み込まれるようにする。これらの修正はターゲット・オブジェ クトを作成するメソッドと、「サーバ・オブジェクト」が受け取ったメソッドを サーバ内のターゲット・オブジェクトにディスパッチするメソッドに加えられる 。 「サーバ・オブジェクト」５０３（ターゲット・オブジェクト）を作成する修 正されたメソッドは、サーバ内に「サーバのオブジェクト」５０３を作成するこ とを求めるクライアントからの要求を受け取って、「ブリッジ・オブジェクト」 ３０４をその場所に作成する。 「ブリッジのサーバ・オブジェクト」３０１が受け取ったメソッドをサーバ内 の「サーバのオブジェクト」５０３（ターゲット・オブジェクト）にディスパッ チする修正されたメソッドは、単にクライアント名を記録するだけで（第５図の ステップ４１２）、別途処理（第５図のステップ４１４）を行い、メソッドをオ ブジェクトにディスパッチする元のディスパッチ・メソッドを呼び出す。 前述の実施例の適用 第９図を参照すると、前述の本発明のブリッジ３００を使用して、１つのクラ イアント５３が複数のサーバ５４Ａ〜５４Ｄにサービスを要求することができる 。クライアント５３ は、要求が異なるサーバ５４Ａから５４Ｄで実行されていることがわからない。 ブリッジ３００は、要求を複数のサーバ５４Ａ〜５４Ｄのうちのどのサーバに宛 てて送るべきかを決定する。 クライアント５３でもサーバ５４Ａ〜５４Ｄでの追加のプログラミングを必要 とせずに、複数のサーバ５４Ａ〜５４Ｄのそれぞれの間における作業負荷分散を 実現することができる。作業負荷分散を実現する実施例では、ブリッジ３００は 「ラウンドロビン」アルゴリズムを使用する。このアルゴリズムでは、新しいク ライアント要求が出されるたびに次のサーバ５４Ａ〜５４Ｄに順に送られる。作 業負荷分散を実現する他の実施例では、各サーバ５４Ａ〜５４Ｄから入手した応 答時間を測定し、当業者に周知のより高度なアルゴリズムを使用して各サーバ５ ４Ａ〜５４Ｄ間で作業負荷を分散させる。この２つの実施例は両方とも、サーバ ５４Ａ〜５４Ｄとクライアント５３のいずれでもコードに修正をまったく加えず に実現することができる。 第１０図に、従来技術の方式で一緒に接続された３個のサーバ５４Ａ〜５４Ｃ に接続された３個のクライアント５３Ａ〜５３Ｃを示す。各クライアント５３Ａ 〜５３Ｃが各サーバ５４Ａ〜５４Ｃへの接続９０１〜９０９を有する。 第１１図を参照すると、前述の本発明のブリッジ３００を使用することによっ て、複数のサーバ５４Ａ〜５４Ｃに対してサービスを要求する複数のクライアン ト５３Ａ〜５３Ｃが 存在することが可能であり、その際、異なるサーバ５４Ａ〜５４Ｃ上で要求が実 行されていることやサーバ５４Ａ〜５４Ｃが他のクライアント５３Ａ〜５３Ｃの ための要求を処理していることは、クライアント５３Ａ〜５３Ｃのいずれにもわ からない。ブリッジ３００は、各クライアント５３Ａ〜５４Ｃからの各要求を、 複数のサーバ５４Ａ〜５４Ｃのうちのどのサーバに宛てて送るかを決定する。 すべての要求をブリッジ３００を介して経路指定することによって、ネットワ ーク内の接続が削減される。より一般的な態様では、ｎ個のクライアント５３と ｍ個のサーバ５４を有するシステムにおいて、接続数がｎ＊ｍ個からｎ＋ｍ個に 減少する。

【手続補正書】 【提出日】１９９８年３月１１日 【補正内容】 請求の範囲 １．分散オブジェクト指向コンピュータ・システムにおいてクライアント（５３ ）とサーバ（５４）との間で使用するブリッジ（３００）であって、サーバのイ ンタフェースに対応するクライアント・アドレス空間内にあるプロキシ・オブジ ェクトとのインタフェースと、クライアント・アドレス空間内にあるプロキシオ ブジェクトのインタフェースに対応するサーバとのインタフェースとを有し、ク ライアント・アドレス空間内にあるプロキシ・オブジェクトとサーバとの間に透 過的に挿入されたブリッジ（３００）。 ２．前記クライアント（５３）と前記サーバ（５４）とが非同期的に動作し、 前記ブリッジがクライアントおよびサーバから継承によって導き出され、 前記ブリッジが前記サーバから継承されたメソッドを上書きして要求を行うク ライアントの名前を記録し、要求を前記サーバに転送し、 前記ブリッジが前記クライアントから継承したメソッドを上書きして前記クラ イアントに応答パラメータを転送する、請求項１に記載のブリッジ（３００）。 ３．前記クライアント（５３）と前記サーバ（５４）とが同期的に動作し、 前記ブリッジがサーバから継承によって導き出され、 前記ブリッジが前記サーバから継承したメソッドを上書きして前記サーバ上の 前記メソッドを呼出し、前記クライアントに応答パラメータを返す、請求項１に 記載のブリッジ（３００）。 ４．クライアント（５３）とサーバ（５４）の間の要求と前記要求に付随するデ ータの監視とログを行う手段をさらに含む、請求項１に記載のブリッジ。 ５．サーバ（５４）間の作業負荷分散を行う手段をさらに含む、請求項１に記載 のブリッジ（３００）。 ６．作業負荷分散を行う前記手段が応答時間を測定し、前記測定された応答時間 に応答してクライアント（５３）の要求をサーバ（５４）に宛てて送る、請求項 ５に記載のブリッジ（３００）。 ７．前記分散オブジェクト指向コンピュータ・システムがｍ個のクライアント（ ５３）とｎ個のサーバ（５４）（ただし、ｎおよびｍは２以上の整数である）と を含み、前記ｍ個のクライアントの各クライアントが前記ｍ個のサーバの各サー バに対してサービスを要求することができ、 前記ブリッジが前記ｍ個のクライアントと前記ｎ個のサーバとに接続され、 それによって前記ブリッジが前記ｍ個のクライアントと前記ｎ個のサーバとの 間の接続数をｎ＊ｍ個からｎ＋ｍ個に減少させる、請求項１に記載のブリッジ（ ３００）。 ８．オブジェクト間のインタフェースがＣＯＲＢＡインタフェースである、請求 項１ないし７のいずれか一項に記載のブリッジ（３００）。 ９．前記分散オブジェクト指向コンピュータ・システムがＤＳＯＭクラス・ライ ブラリを使用する、請求項８に記載のブリッジ（３００）。 １０．分散クライアント−サーバコンピュータ・システムを動作させる方法であ って、 クライアント・アドレス空間内にあるプロキシ・オブジェクト（５３）とのイ ンタフェースがサーバ（５４）のインタフェースに対応し、サーバとのインタフ ェースがクライアント・アドレス空間内にあるプロキシ・オブジェクトのインタ フェースに対応するように、ブリッジ（３００）のためにインタフェースを定義 するステップと、 前記ブリッジをクライアント・アドレス空間内にある前記プロキシ・オブジェ クトと前記サーバの間に透過的に挿入するステップとを含む方法。 １１．前記クライアント（５３）と前記サーバ（５４）とが非同期的に動作し、 インタフェースを定義する前記ステップが、 クライアントとの前記インタフェースをサーバから継承によって導き出すステ ップと、 前記サーバから継承したメソッドを上書きして、要求を行うクライアントの名 前を記録し、前記サーバに要求を転送す るステップと、 サーバとの前記インタフェースをクライアントから継承によって導き出すステ ップと、 前記クライアントから継承したメソッドを上書きして前記クライアントに応答 パラメータを転送するステップとを含む、請求項１１に記載の方法。 １２．前記クライアント（５３）と前記サーバ（５４）が同期的に動作し、イン タフェースを定義する前記ステップが、 前記インタフェースをサーバから継承によって導き出すステップと、 前記サーバから継承したメソッドを上書きして、前記サーバ上で前記メソッド を呼出し、前記クライアントに応答パラメータを返すステップとを含む、請求項 １１に記載の方法。 １３．１つまたは複数のサーバと、１つまたは複数のクライアント（５３）と、 前記請求項１ないし７のいずれか一項に記載のブリッジ（３００）とを含む分散 オブジェクト指向コンピュータ・システム。

Claims (1)

1. 【特許請求の範囲】 １．分散オブジェクト指向コンピュータ・システムにおいてクライアント（５３ ）とサーバ（５４）の間で使用するブリッジ（３００）であって、サーバのイン タフェースに対応するクライアントとのインタフェースとクライアントのインタ フェースに対応するサーバとのインタフェースとを有し、クライアントとサーバ の間に透過的に挿入されるブリッジ。 ２．前記クライアント（５３）と前記サーバ（５４）とが非同期的に動作し、 前記ブリッジがクライアントおよびサーバから継承によって導き出され、 前記ブリッジが前記サーバから継承されたメソッドを上書きして要求を行うク ライアントの名前を記録し、要求を前記サーバに転送し、 前記ブリッジが前記クライアントから継承したメソッドを上書きして前記クラ イアントに応答パラメータを転送する、請求項１に記載のブリッジ（３００）。 ３．前記クライアント（５３）と前記サーバ（５４）とが同期的に動作し、 前記ブリッジがサーバから継承によって導き出され、 前記ブリッジが前記サーバから継承したメソッドを上書きして前記サーバ上の 前記メソッドを呼出し、前記クライアントに応答パラメータを返す、請求項１に 記載のブリッジ（３ ００）。 ４．クライアント（５３）とサーバ（５４）の間の要求と前記要求に付随するデ ータの監視とログを行う手段をさらに含む、請求項１に記載のブリッジ。 ５．サーバ（５４）間の作業負荷分散を行う手段をさらに含む、請求項１に記載 のブリッジ（３００）。 ６．作業負荷分散を行う前記手段が応答時間を測定し、前記測定された応答時間 に応答してクライアント（５３）の要求をサーバ（５４）に宛てて送る、請求項 ５に記載のブリッジ（３００）。 ７．前記分散オブジェクト指向コンピュータ・システムがｍ個のクライアント（ ５３）とｎ個のサーバ（５４）（ただし、ｎおよびｍは２以上の整数である）と を含み、前記ｍ個のクライアントの各クライアントが前記ｍ個のサーバの各サー バに対してサービスを要求することができ、 前記ブリッジが前記ｍ個のクライアントと前記ｎ個のサーバとに接続され、 それによって前記ブリッジが前記ｍ個のクライアントと前記ｎ個のサーバとの 間の接続数をｎ＊ｍ個からｎ＋ｍ個に減少させる、請求項１に記載のブリッジ（ ３００）。 ８．前記分散オブジェクト指向コンピュータ・システムがＣＯＲＢＡ準拠システ ムである、請求項１ないし７のいずれか一項に記載のブリッジ（３００）。 ９．前記分散オブジェクト指向コンピュータ・システムがＤ ＳＯＭクラス・ライブラリを使用する、請求項８に記載のブリッジ（３００）。 １０．分散クライアント−サーバ・コンピュータ・システムを動作させる方法で あって、 クライアント（５３）とのインタフェースがサーバ（５４）のインタフェース に対応し、サーバとのインタフェースがクライアントのインタフェースに対応す るように、ブリッジ（３００）のためにインタフェースを定義するステップと、 前記ブリッジを前記クライアントと前記サーバの間に透過的に挿入するステッ プとを含む方法。 １１．前記クライアント（５３）と前記サーバ（５４）とが非同期的に動作し、 インタフェースを定義する前記ステップが、 クライアントとの前記インタフェースをサーバから継承によって導き出すステ ップと、 前記サーバから継承したメソッドを上書きして、要求を行うクライアントの名 前を記録し、前記サーバに要求を転送するステップと、 サーバとの前記インタフェースをクライアントから継承によって導き出すステ ップと、 前記クライアントから継承したメソッドを上書きして前記クライアントに応答 パラメータを転送するステップとを含む、請求項１１に記載の方法。 １２．前記クライアント（５３）と前記サーバ（５４）が同 期的に動作し、インタフェースを定義する前記ステップが、 前記インタフェースをサーバから継承によって導き出すステップと、 前記サーバから継承したメソッドを上書きして、前記サーバ上で前記メソッド を呼出し、前記クライアントに応答パラメータを返すステップとを含む、請求項 １１に記載の方法。 １３．１つまたは複数のサーバと、１つまたは複数のクライアント（５３）と、 前記請求項１ないし７のいずれか一項に記載のブリッジ（３００）とを含む分散 オブジェクト指向コンピュータ・システム。