JP3605416B2 - クライアント−サーバ環境用ブリッジ - Google Patents
クライアント−サーバ環境用ブリッジ Download PDFInfo
- Publication number
- JP3605416B2 JP3605416B2 JP51173197A JP51173197A JP3605416B2 JP 3605416 B2 JP3605416 B2 JP 3605416B2 JP 51173197 A JP51173197 A JP 51173197A JP 51173197 A JP51173197 A JP 51173197A JP 3605416 B2 JP3605416 B2 JP 3605416B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- client
- bridge
- interface
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Description
発明の分野
本発明は、クライアント−サーバ環境における分散コンピューティングに関し、具体的には前記環境におけるクライアントとサーバの間でのブリッジの使用に係わる。
発明の背景
オブジェクト指向プログラミングの概要
オブジェクト指向プログラミングが開発される以前に、構造化プログラミングと呼ばれるプログラミングの一形態が使用され、今でも広く使用されている。この技法では、まずさまざまな関数を定義し、次にプログラムがその定義された関数を適切な時点で呼び出してアプリケーション・プログラムの全体的な目的を実現することから成る。このような関数は、データを操作するために使用するメソッドを定義するが、データ自体は定義しない。構造化プログラミングはモジュール化手法の機会をもたらした。これは、メンテナンスやデバッグが難しい「スパゲッティ・コード」を克服する重要な改良であった。それにもかかわらず、構造化プログラミングには、プログラムによってモデル化される世界における概念および実体と、プログラミング言語における概念との間の「意味ギャップ」や、プログラム・コードのテキスト性、コード・モジュールの再使用可能性の限界などいくつかの欠点も残されている。
その後、オブジェクト指向プログラミングと呼ばれる新しいプログラミング・パラダイムが開発された。この技法では、関数を定義する代わりに、「クラス」を定義する。クラス定義によって、そのクラスの任意のインスタンスが実行することができるメソッドと、そのクラスのインスタンスに含まれる属性（またはデータ）とを定義する。オブジェクトはクラスのメンバーであり、クラス定義で定義されているメソッドを実際に実行することができる。オブジェクトは、クラスによって定義された各属性に付随する値を持つ。オブジェクトは、ゼロまたは１個以上の属性を持ち、そのオブジェクトに対して実行することができるゼロまたは１個以上のメソッドを持つ。
オブジェクトとのインタフェースは、メソッドを介して属性にアクセスすることができる方法である。そのクラスから導き出されるすべてのオブジェクトがそのクラスのインタフェースを共有する。オブジェクトの実現部分はオブジェクトを呼び出すアプリケーションから隠蔽される。オブジェクトへのインタフェースが変わらない限り、アプリケーションに影響を与えることなく実現部分を完全に変えることはできない。
オブジェクトが内部でどのように「見える」か、また内部で何を「行う」かを記述する必要なしにオブジェクトの「外観」を記述するこの技法を単純化した例として、また、そのようなオブジェクト指向プログラミングの重要な利点を例示するための例として、オブジェクト指向手法によってモデル化することができる普通の家庭用トースタを考えてみる。外部「インタフェース」は、トーストの所望の焼き加減を調節するパラメータを本質的に表すつまみと、パンを入れるスロットと、トースタへの挿入とトースタの起動を行うレバーとから成る。重要な概念は、この種の家電製品のエンドユーザはそれを使用するためにトースタの「内部」を知る必要がないことである。たとえば、熱が電気によって供給されるのか、化学薬品やその他の手段によって供給されるのかを知る必要はない。ユーザは上記の外面部と正しくインタフェースするだけでよい。
プログラミングにおけるこの進化の利点は、上記の例を続けて用いると、トースタをモデル化するプログラミング・コードのモジュールであるオブジェクトの設計者が、ユーザにとって内部が見えないために、たとえばユーザがそのオブジェクトを使用する能力に影響を与えることなくトースタの内部要素を改良することに焦点を絞ることができ、効率を向上させることができることである。したがって、より抽象的に言うと、オブジェクト指向技法は本質的に、オブジェクトのインタフェースをオブジェクトの実現部分から分離する利点をもたらすものと見なすことができる。ソフトウェア環境においては、それによって、外部の「つまみ」などやその予想される動作が変わらない限り、アプリケーション・プログラム全体を書き直さなくてもオブジェクトの内部を書き直し、改良することができる。
本発明の理解を助けるオブジェクト技法に関するその他の一般的背景については、デイビッドA.テイラー（David A.Teylor）による「Object Oriented Technology−Ａ Manager's Guide」（copyright 1990,Servio Corporation）を参照されたい。
オブジェクト指向プログラミングの発展に伴い、様々な組織やソフトウェア会社によっていくつかの「オブジェクト・モデル」がさらに改良され、開発された。オブジェクトとその外部インタフェースを定義する方法が規定され、そのような様々なオブジェクト・モデルによって特にカプセル化と継承の特性が規定された。ある程度の高レベルから見れば、これらの様々なオブジェクト・モデルはきわめて類似している。たとえば、システム・オブジェクト・モデル（SOM）、コモンLispオブジェクト・システム（CLOS）、Smalltalk、およびＣ＋＋などがある。本質的には、これらの様々なオブジェクト・モデルはオブジェクトが何であるかという問いに答える規則の集まりに過ぎず、より低レベルで検討するとそれぞれわずかに異なった答えが出る。たとえば、言語構文とカプセル化および継承の機能はオブジェクト・モデルによって異なる。
これらの相違の直接の結果として、異なるオブジェクト指向言語およびオブジェクト・モデルの使用可能性により生じる１つの問題は、そのような言語の混合で書かれたオブジェクト・プログラム間のインターオペラビリティを実現することができないことであった。この問題は、オブジェクト技法の重要な利点の１つであるコードの再使用可能性に悪影響を与える。業界を悩ませるこの問題を解決しようとして、委員会は共通オブジェクト要求ブローカ・アーキテクチャ（CORBA）に到達した。これには標準化インタフェース定義言語（IDL）が含まれていた。業界ではオブジェクトインタフェースをどのように規定するか、すなわち、オブジェクト・インタフェースを定義する標準に関して本質的に合意に達し、その結果、１つのベンダーによって定義されたオブジェクトを他のベンダーが使用することが可能になった。「The Common Object Request Broker:Architecture and Specification」（OMG Document Number 91.12.1 Revision1.1）を参照されたい。
オブジェクト要求ブローカ（ORB）
CORBAアーキテクチャで記述されたオブジェクト要求ブローカ（ORB）は、UNIXオペレーティング・システム環境で作業をする人には周知のリモート・プロシージャ・コール（RPC）に似ている（UNIXはX/Open CO.Ltd.によって独占的にライセンス許諾される商標である）。
従来技術のシステムを第１図に示す。これは、クライアント／サーバ環境にある従来技術のオブジェクト要求ブローカを示すブロック図である。
このORBは２つの部分に分かれており、そのうちの部分50はORBを使用して各クライアントで実行され、部分52はORBをサポートする各サーバで実行される。RPCと同様に、ORBは１つのアドレス空間53で稼働しているクライアント・アプリケーション48が別のアドレス空間54のオブジェクト51と通信することができるようにする機構である。他方のアドレス空間54、すなわちクライアント・アプリケーション48が実行されているアドレス空間と同じアドレス空間53ではないアドレス空間にあるオブジェクト51を「リモート」オブジェクトと呼ぶ。クライアント・アプリケーション48と同じアドレス空間53にあるオブジェクトを「ローカル」オブジェクトと呼ぶ。ORB50は１つのアドレス空間53内のクライアント・アプリケーション48からの呼出しを代行受信し、それをネットワーク・プロトコルにカプセル化し、別のアドレス空間54内のターゲット・オブジェクト51のための呼出しをデコードし、その結果を呼び出し側クライアント・アプリケーション48に返す。これによって、一方のアドレス空間（ローカル）で稼働しているクライアント・アプリケーション48が他方のアドレス空間（リモート）内のオブジェクト51と通信することができる。ORBは、オブジェクト指向プログラミングによって得られる高度の柔軟性と能力を備えるように設計されている点で、RPCが改良されたものである。プロキシ・オブジェクト49の機能については後で詳述する。
「オブジェクト・モデル」は様々な組織やソフトウェア会社によって開発されている。オブジェクト・モデルはオブジェクトとその外部インタフェースの定義の仕方を規定する。このようなオブジェクト・モデルの１つは、IBM Corporationのシステム・オブジェクト・モデル（SOM）である。SOMでは、オブジェクトを使用するすべてのアプリケーションはそれらのオブジェクトが入っている１つのアドレス空間内で実行される。SOM内で作成されるものは、分散システム・オブジェクト・モデル（DSOM）と呼ばれるオブジェクト・クラスのフレームワークである。DSOMでは、１つのアドレス空間内の（クライアントで稼働している）アプリケーションは別のアドレス空間（サーバに属するアドレス空間など）内のオブジェクトにアクセスすることができる。これらのアドレス空間は同じシステムと異なるシステムのどちらにあってもよい。実際には、システムは同じプラットフォームで稼働している必要はない。たとえば、OS/2システム上のアドレス空間で稼働しているクライアント・アプリケーションがAIX/6000システム上のアドレス空間にあるオブジェクトにアクセスすることができ、その逆も可能である。SOMとDSOMの両方については、IBM Corporationが発行している「SOMobject:A Practical Introduction to SOM and DSOM」（Copyright 1994,Order no.GG24−4357−00）に記載されている。
欧州特許出願第0501610号では、異なるプロセス内のオブジェクトが通信することができるようにする機構が開示されている。通信アプリケーション・プログラミング・インタフェース（API）を使用するようにプログラムが明示的に作成される。
上記のシステム・オブジェクト・モデル（SOM）は、CORBAとIDLに準拠した１つのオブジェクト・モデルである。準拠とは、SOMオブジェクトがCORBAのセマンティクスに従っており、SOMオブジェクトがIDL構文で定義されているという意味である。
DSOMのフレームワークは、ターゲット・オブジェクトがインスタンス化される場所やプラットフォームのタイプをクライアント・プログラマが知らなくても済むようにするオブジェクト実現部を備える。このプロセス間通信に使用される通信機構は、プログラマには見えないように完全に隠蔽される。
クライアント−サーバ・アーキテクチャ
クライアント−サーバ・アーキテクチャでは、アプリケーション・プログラムは個別の構成要素として実行される個別のタスクに分けられる。各構成要素にはクライアントまたはサーバの役割が割り当てられる。１つの構成要素は、ある目的のためにはサーバの役割を果たし、他の目的のためにはクライアントの役割を果たすことができる。各構成要素は独立して動作し、特定の責任を担う。クライアントの役割が割り当てられた構成要素は、サーバ・プロセス内のオブジェクトに対するメソッド呼出しを行うことによって、サーバにサービスを要求する。サーバの役割が割り当てられた構成要素は、それらのメソッド呼出しを受け取り、該当するオブジェクトに対してそれらのメソッド呼出しを行い、その結果をクライアントに返すことによってサービスを提供する。クライアントとサーバは事前定義されたプロトコルを使用してメッセージを交換する。サーバは多くのクライアントにサービスを提供することができ、クライアントは多くのサーバにサービスを要求することができる。
このようなシステムでは、クライアントまたはサーバがその中に特定のコードを持っていない限り、サーバのクライアントによって行われた要求の監視やログを行ったり、そのような要求に付随するデータの監視やログを行ったりすることができない。問題判別のために、そのような要求の監視またはログを行うことが望ましいと考えられる。
上述のシステムでは、サーバ間の作業負荷分散は、クライアントがクライアント自体内にそのような作業負荷分散機能を含むように設計されていない限り不可能である。クライアント自体内にそのような作業負荷分散機能を組み込むことの欠点は、クライアント内の各要求に付随するオーバーヘッドと、そのような作業負荷分散機能を含む各クライアントに複雑さが生じることである。最高のパフォーマンスを提供するサーバを選定することによってクライアントの全体的なパフォーマンスを向上させるために、作業負荷分散が望ましい。
各クライアントと、そのクライアントがサービスを要求することができることが望ましい各サーバとの間に通信リンクを設ける必要がある。その結果、多数のクライアントと多数のサーバがあるシステムは著しく複雑化する。
背景技術
機能伝送によって、アプリケーション・プログラムはファイル制御要求を伝送して他のシステムが所有しているファイルにアクセスすることができ、一時データ機能および一時記憶域機能を求める要求を伝送して他のシステム内の一時データ待ち行列および一時記憶待ち行列との間でデータの送受信を行うことができる。また、SNA LUタイプ６プロトコルを実施する他のシステムでのトランザクションの開始も可能にする。システム・プログラマは資源定義テーブルの項目を使用して、指定資源がローカル（または要求側）システム上ではなくリモート（または所有側）システム上にあるように指定することができる。機能伝送の使用は、要求側システムとリモートシステムの両方にとって透過である。要求とそれに付随するデータの記録と監視が可能であるが、そのような監視機能を持たせたい各アプリケーションごとに別々に実施しなければならない。機能伝送の詳細は、「CICS/ESA V4.1 Intercommunication Guide」（IBM Corporation発行、Copyright 1977、1994、Order no.SC33−1181−00）に記載されている。
プロキシを使用して、クライアントで稼働しているローカル・アプリケーションからサーバ内のリモート資源にアクセスすることができる。プロキシとは、他のオブジェクトの代わりとなり、そのメッセージを受信し、それらを何らかの方法で処理することができる、第１図のプロキシ・オブジェクト49のようなオブジェクトである。これには、メッセージを第１図の51などのターゲット・オブジェクトに転送することが含まれることが多い。プロキシは、オブジェクト指向プログラミングで周知であり、DSOM（分散システムオブジェクト・モデル）によって使用される。詳細については、SOMobjects Publicationsに含まれているSOMobjects Developer Toolkit User's Guide Version2.0（IBM Corporation発行、Gopyright 1994、Order no.S96F−8649）を参照されたい。プロキシは、クライアントからサーバに送られる要求メッセージを受け取り、サーバからクライアントに送られる戻りメッセージを受け取る。プロキシは、クライアントに宛てられたサーバからの非同期戻りメッセージを受け取ることはできない。プロキシは、一般にサーバ内の単一のターゲット・オブジェクトに関連づけられ、単一のサーバ内または複数のサーバ内の複数のオブジェクトに関連づけられることはない。
欧州特許出願第0518195号では、アプリケーション・プログラムにリンクされたライブラリ・ルーチンによって実施されるプラットフォーム独立アプリケーション・プログラミング・インタフェース（API）が開示されている。アプリケーション・プログラムはそのAPIに合わせて特別に作成され、クライアント・プロセスおよびサーバ・プロセスはAPIを明示的に知ってそれを使用しなければならない。この実施態様の問題点は、クライアントとサーバにリダイレクトがわからないようにクライアント−サーバ・フローを代行受信する透過的な機構を備えないことである。
PCT特許出願WO95/17718号では、オペレーティング・システムと統合された、リモート・プロシージャ・コール（RPC）とのオブジェクト指向インタフェースが開示されている。クライアント・プログラムとサーバ・プログラムは、互いに通信するときにRPCアプリケーション・プログラミング・インタフェース（API）を利用するように特別に作成される。この実施態様も、クライアントとサーバにリダイレクトがわからないようにクライアント−サーバ・フローを代行受信する透過的機構を備えない。
PC Magazine v13,n10（1994年５月31日発行、Gagnon Ｇ）の「Building ａ better app、SQL style」では、共通APIを多くの異なるAPIにマップすることができるようにする方法が開示されている。
DBMS,v5,n9（1992年８月発行、Roti Ｓ）の「SQL＊NET version2:client/server networking is easier with SQL＊NET V2 and the MultiProtocol Interchange」では、１つのAPIからもう１つのAPIに変換する中間構成要素が開示されている。この中間要素はそれに対して要求される変換タスクを実行するように特別に作成される。この中間要素がないと、その２つのAPIに合わせて作成された構成要素は通信することができない。
発明の開示
したがって、本発明は、分散オブジェクト指向コンピュータ・システムにおいてクライアントとサーバの間で使用するブリッジを提供する。このブリッジは、サーバのインタフェースに対応するクライアントとのインタフェースと、クライアントのインタフェースに対応するサーバとのインタフェースとを定義する。
第１の実施例では、クライアントとサーバは非同期的に動作し、ブリッジはクライアントおよびサーバから継承によって導き出され、ブリッジはサーバから継承されたメソッドを上書き変更（override）して、要求を行うクライアントの名前を記録し、その要求をサーバに転送し、ブリッジはクライアントから継承したメソッドを上 書き変更してクライアントに応答パラメータを転送する。
第２の実施例では、クライアントとサーバは同期して動作し、ブリッジは継承によってサーバから導き出され、ブリッジはサーバから継承されたメソッドを上書き 変更してサーバ上のメソッドを呼び出し、クライアントに応答パラメータを転送する。
好ましい実施例では、ブリッジはクライアントとサーバとの間の要求とその要求に付随するデータの監視と記録を行う手段をさらに含む。また、好ましい実施例では、ブリッジは、サーバ間の作業負荷分散を行う手段をさらに含む。そのような作業負荷分散は、応答時間を測定し、測定された応答時間に応じてサーバにクライアント要求を送ることによって行うことができる。他の好ましい実施例では、ブリッジはｍ個のクライアントとｎ個のサーバ（ただしｎおよびｍは２以上の整数）に接続され、ブリッジはネットワーク接続数をｎ＊ｍ個からｎ＋ｍ個に減らす。
分散オブジェクト指向コンピュータ・システムはCORBA準拠システムであり、分散オブジェクト指向コンピュータ・システムはDSOMクラス・ライブラリを使用することが好ましい。しかし、本発明はそのようなシステムでの応用やそのようなクラス・ライブラリの使用には限定されない。たとえば、分散オブジェクト指向システムはマイクロソフトのコンポーネント・オブジェクト・モデル（COM）に準拠していてもよい。また、分散オブジェクト環境としてSunSoftから、およびORBプラスとしてヒューレット・パッカードCo.から入手可能な、分散オブジェクト管理機能（DOMF）を使用することもできる。
本発明は、分散クライアント−サーバ・コンピュータ・システムを稼働させる方法であって、ブリッジのために、サーバのインタフェースに対応するクライアントとのインタフェースを定義するステップと、クライアントのインタフェースに対応するサーバとのインタフェースを定義するステップとを含む方法も提供する。
第１の実施例では、クライアントとサーバは非同期的に動作し、クライアントとのインタフェースを定義するステップが、クライアント・インタフェースをサーバから継承によって導き出すステップと、サーバから継承したメソッドを上書き変更して、要求を行うクライアントの名前を記録し、その要求をサーバに転送するステップとを含み、サーバとのインタフェースを定義するステップが、前記サーバ・インタフェースをクライアントから継承によって導き出すステップと、前記クライアントから継承したメソッドを上書き変更して前記クライアントに応答パラメータを転送するステップとを含む。
第２の実施例では、クライアントとサーバは同期して動作し、クライアントとのインタフェースを定義するステップが、クライアント・インタフェースをサーバから継承によって導き出すステップと、サーバから継承したメソッドを上書き変更してサーバ上でメソッドを呼出し、クライアントに応答パラメータを転送するステップとを含む。
本発明は、１つまたは複数のサーバと、１つまたは複数のクライアントと、前述のブリッジとを含む分散オブジェクト指向コンピュータ・システムも提供する。
【図面の簡単な説明】
以下に本発明の実施例について例として添付図面を参照しながら説明する。
第１図は、クライアント／サーバ環境にある従来技術のオブジェクト要求ブローカを示すブロック図である。
第２図は、本発明と共に使用するのに適した従来技術のコンピュータ・システムを示すブロック図である。
第３図は、非同期的に動作するように構成された従来技術のクライアントとサーバを含むシステムを、本発明のブリッジと共に示すブロック図である。
第４図は、従来技術のクライアントとサーバの非同期動作を示す流れ図である。
第５図は、本発明による第３図のシステムの非同期動作を示す流れ図である。
第６図は、同期して動作するように構成された従来技術のクライアントとサーバを含むシステムを、本発明のブリッジと共に示すブロック図である。
第７図は、従来技術のクライアントとサーバの同期動作を示す流れ図である。
第８図は、本発明による第６図のシステムの同期動作を示す流れ図である。
第９図は、本発明によるブリッジを使用した複数のサーバ間の作業負荷分散を示すブロック図である。
第10図は、複数のクライアントと複数のサーバの従来技術の接続を示すブロック図である。
第11図は、本発明によるブリッジを使用した複数のクライアントと複数のサーバとの接続を示すブロック図である。
発明の詳細な説明
本発明を実施することができる適合するハードウェア
本発明は、いくつかの異なるオペレーティング・システム下にある様々なコンピュータまたはコンピュータの集合上で実行することができる。コンピュータは、たとえばパーソナル・コンピュータ、ミニ・コンピュータ、メインフレーム・コンピュータ、または他のコンピュータの分散ネットワーク内で稼働するコンピュータとすることができる。特定のコンピュータの選定はメモリおよびディスクの必要記憶容量によってのみ限定されるが、本発明ではIBM PS/2シリーズのコンピュータを使用することができる（IBMはIBM Corporationの登録商標であり、PS/2は商標である）。IBMのPS/2シリーズ・コンピュータの詳細については、Technical Reference Manual Personal System/2（Model 80）（IBM Corporation Part No.68X 2256 Order Number S68X−2254）を参照されたい。IBM PS/2パーソナル・コンピュータで実行することができるオペレーティング・システムはIBMのOS/2 2.0であり、IBM OS/2 2.0オペレーティング・システムの詳細については、OS/2 2.0 Technical Library,Programming Guide Vol.1,2,3 Version 2.00（Order Nos.10G6261,10G6495、10G6494）を参照されたい（OS/2はIBM Corporationの商標である）。
代替実施例では、コンピュータ・システムはAIXオペレーティング・システム上で稼働するIBM RISC System/6000ラインのコンピュータとすることができる（RISC System/6000およびAIXはIBM Corporationの商標である）。RISC System/6000の様々なモデルについては、たとえばRISC System/6000,7073および7016 POWERstation and POWERserver Hardware Technical Reference（Order No.SA23−2644−00）など、IBM Corporationの多くの刊行物に記載されている（POWERstationおよびPOWERserverはIBM Corporationの商標である）。AIXオペレーティング・システムについては、General Concepts and Procedure−−AIX Version3 for RISC System/6000（Order No.sc23−2202−00）およびIBM Corporationのその他の刊行物に記載されている。
第２図には、システム・ユニット11と、キーボード12と、マウス13と、表示装置14を含むコンピュータ10のブロック図が図示されている。システム・ユニット11は、１本または複数のシステム・バス21を含み、システム・バスには様々な構成要素が接続され、それによって様々な構成要素間の通信を行う。マイクロプロセッサ22がシステム・バス21に接続され、やはりシステム・バス21に接続された読取り専用メモリ（ROM）23とランダム・アクセス・メモリ（RAM）24によってサポートされている。IBM PS/2シリーズのコンピュータのマイクロプロセッサは、386または486マイクロプロセッサを含むインテル・ファミリのマイクロプロセッサのうちの１つである。しかし、68000、68020、または68030マイクロプロセッサなどのモトローラのマイクロプロセッサ・ファミリや、PowerPCチップなどのIBM製の様々な縮小命令セット・コンピュータ（RISC）マイクロプロセッサその他のマイクロプロセッサ、またはヒューレット・パッカード、サン、モトローラおよびその他のマイクロプロセッサなど、他のマイクロプロセッサもこの特定のコンピュータで使用することができる。
ROM23は、他のコードの他に、ディスク・ドライブ、キーボードなどの基本ハードウェア動作を制御する基本入出力システム（BIOS）を含む。RAM24は、オペレーティング・システムとアプリケーション・プログラムがロードされるメイン・メモリである。メモリ管理チップ25がシステム・バス21に接続され、RAM24とハード・ディスク・ドライブ26とフロッピィ・ディスク・ドライブ27との間のデータの受渡しを含む直接メモリ・アクセス操作を制御する。システム・バス21にはCD ROM32も結合され、たとえばマルチメディア・プログラムやプレゼンテーションなど大量のデータを記憶するために使用される。
このシステム・バス21には、様々な入出力コントローラ、キーボード・コントローラ28、マウス・コントローラ29、ビデオ・コントローラ30、およびオーディオ・コントローラ31も接続される。当然ながら、キーボード・コントローラ28はキーボード12のハードウェア・インタフェース、マウス・コントローラ29はマウス13のハードウェア・インタフェース、ビデオ・コントローラ30は表示装置14のハードウェア・インタフェース、オーディオ・コントローラ31はスピーカ15aおよび15bのハードウェア・インタフェース機能を備える。トークン・リンク・アダプタなどの入出力コントローラ40によって、他の同様に構成されたデータ処理システムとネットワーク46を介して通信することができる。
本発明の好ましい実施例の１つでは、第１図を参照しながら前述した命令48〜52のセットが、大体前述のように構成された１つまたは複数のコンピュータ・システムのランダム・アクセス・メモリ24に入っている。この１組の命令は、コンピュータ・システムが必要とするまで、たとえばハード・ディスク・ドライブ26、または最終的にCD−ROM32で使用される光ディスクまたは最終的にフロッピィ・ディスク・ドライブ27で使用されるフロッピィ・ディスクなどの取り外し可能メモリなど、別のコンピュータ・メモリに記憶することができる。ORBを使用して相互に結合されるメモリ・アドレス空間は、ネットワーク46を介して通信する別々のシステムに存在することもでき、第２図に示すように１つのコンピュータ・システムのメモリ内の２つ以上のアドレス空間53、54とすることもできる。
ブリッジ
第３図を参照すると、本発明ではクライアント53とサーバ54の間にブリッジ300を設ける。このブリッジ300の目的は、サーバ54に宛てられたクライアント53からの要求を受け取り、その要求をサーバ54に転送し、クライアント53に宛てられたサーバ54からの応答を受け取り、その応答をクライアント53に転送することである。ブリッジ300は、サーバ54のインタフェースに対応するクライアント53とのインタフェースと、クライアント53のインタフェースに対応するサーバ54とのインタフェースとを提供する。このようにして、クライアント53とサーバ54のいずれもブリッジ300の存在を判断することができず、両者ともブリッジが存在しないかのように動作する。
本発明の実施例について説明する。１つは非同期環境用で稼働し、１つは同期環境で稼働するものである。非同期環境（第５図に示す）では、クライアント53はサーバ54からの応答を待つ間、他の処理を続ける。同期環境（第８図に示す）では、クライアント53はサーバ54からの応答を待ってから処理を続ける。
非同期環境
第３図を参照すると、非同期モードで動作するクライアントとサーバと共に使用するブリッジ300の構成要素が含まれている。クライアント53、ブリッジ300、およびサーバ54はすべて、DSOM用語で「サーバ・オブジェクト」と呼ばれるものを備える。これらはそれぞれ、「クライアントのサーバ・オブジェクト」404、「ブリッジのサーバ・オブジェクト」301、および「サーバのサーバ・オブジェクト」501として図示されている。これらのオブジェクトを、サーバが実行する機能やサーバ自体と混同してはならない。サーバ・オブジェクトとは、サーバ内のオブジェクトを管理してクライアント・アプリケーションがサーバ内のオブジェクトの作成と破棄を行うことができるようにするオブジェクトである。サーバ・オブジェクトは、サーバ内のどのオブジェクトが要求を処理すべきかを識別し、受信したそのサーバに対するそのような要求を、識別したオブジェクトにディスパッチして実行させる。
クライアント53は、「クライアントのオブジェクト」403と呼ばれる少なくとも１つのオブジェクトを含む。このオブジェクトは、クライアントにおいてサーバ54に対してサービスの提供を求める要求のイニシエータである。クライアント・アプリケーション（図示せず）が「クライアントのオブジェクト」403に対して呼び出しを行い、データに対する操作を実行する。これらの操作は、「クライアントのオブジェクト」403自体内でローカルに行われるか、またはサーバ54にサービスを要求する「クライアントのオブジェクト」403を使用してリモートで行われる。サーバ54は、「サーバのオブジェクト」503（サーバ・オブジェクトと混同してはならない）と呼ばれる少なくとも１つのオブジェクトを含む。これは、第１図および第２図を参照しながら前述したターゲット・オブジェクトに相当する。これは、「クライアントのオブジェクト」403によって要求されたサービスを実際に提供するオブジェクトである。ブリッジ300は、「ブリッジのオブジェクト」304と呼ぶオブジェクトを含み、ブリッジ自体の機能を備える。
プロキシ・オブジェクト
クライアント53、ブリッジ300、およびサーバ54はすべて、DSOM用語でプロキシ・オブジェクトと呼ばれるものを備える。プロキシ・オブジェクトとは、リモート・ターゲット・オブジェクトの代わりをするローカルの代理である。プロキシ・オブジェクトは、ターゲット・オブジェクトのインタフェースを継承し、それによって同じメソッドに応答する。プロキシ・オブジェクト上で呼び出されたメソッドはローカルでは実行されず、実ターゲット・オブジェクトに転送されて実行される。クライアントで稼働しているプログラムは、そのプログラムがそれに対して操作を行うサーバ内の各リモート・オブジェクトのローカル・プロキシ・オブジェクトをクライアント内に常に有する。プロキシ・オブジェクトはその内部に、ターゲット・オブジェクトが入っているサーバ内の記憶場所を指すポインタを含む。プロキシ・オブジェクトは、リモート・オブジェクトに対するメソッドを呼び出すようにリモート・サーバに対して要求が行われると、DSOM実行時環境によって作成される。
クライアント53は、「ブリッジのサーバ・オブジェクト」301の代わりをするローカルにおける代理である「ブリッジのサーバ・プロキシ」（401）と呼ぶプロキシ・オブジェクトを含む。クライアントは、これがサービスを提供するサーバ内の「サーバのサーバ・オブジェクト」501の代理をするものとみなす。同様に、ブリッジ300は、「サーバのサーバ・オブジェクト」501のローカルにおける代理である「サーバのサーバ・プロキシ」302と呼ぶプロキシ・オブジェクトを含む。前述のように「サーバ・オブジェクト」とは、サーバ内のオブジェクトを管理するオブジェクトである。
クライアント53は、「ブリッジのオブジェクト」304のローカルにおける代理である「ブリッジのオブジェクト・プロキシ」402と呼ぶプロキシ・オブジェクトも含む。クライアントはこの代理を、サービスを提供するサーバ内のオブジェクト503であるとみなす。同様に、ブリッジ300は、「サーバのオブジェクト」503のローカルの代理である「サーバのオブジェクト・プロキシ」303と呼ぶプロキシ・オブジェクトを含む。これらのプロキシは、クライアント53によって開始されるクライアント53とサーバ54との間の通信に使用される。非同期システムでは、サーバ54がクライアント53宛ての応答を持っている場合、通信はサーバ54によっても開始される。これらの通信は、サーバ54がブリッジ300と通信することができるようにするサーバ内にある「ブリッジのオブジェクト・プロキシ」502と、ブリッジ300がクライアント53と通信することができるようにするブリッジ300内にある「クライアントのオブジェクト・プロキシ」305とを使用して行われる。
上記の説明からわかるように、第３図でクライアント53、ブリッジ300、およびサーバ54を示す各ブロックの上部にあるオブジェクトとプロキシ・オブジェクトは、クライアントとブリッジによるオブジェクトの作成、破棄、および探索に使用される。第３図でクライアント53、ブリッジ300、およびサーバ54を示す各ブロックの下部にあるオブジェクトとプロキシ・オブジェクトは、クライアント53とブリッジ300とサーバ54との間における通信プロセスに使用される。
第４図に、非同期環境における従来技術のクライアントと従来技術のサーバとの間で従来技術のネットワークを介して行われる対話を示す。非同期環境では、クライアントはサーバに対してサービスを提供するように求める要求を行うことによってサーバとの通信を開始する。サーバはその要求に肯定応答し、クライアントは他の処理を続ける。サーバは遅延後に要求を処理することができ、サーバもその遅延の間に他の処理を実行することができる。サーバは要求を処理すると、クライアントに応答を送ることによってクライアントとの別の通信を開始する。この通信は、「サーバ」が「クライアント」に対して、前の要求からの応答を受け入れるように求める要求を事実上行うことによって開始される。このような状況では、「サーバ」と「クライアント」が逆の役割を持っていると見なすことができ、サーバはクライアントに対して応答を受け入れるように要求する。非同期的に動作している場合にクライアントが「サーバ・オブジェクト」を必要とするのはこのためである。
ステップ310で、クライアントはサーバに対してサービスの提供を求める要求を行う。この要求はステップ320でネットワークを介してサーバに送信される。サーバはステップ322でクライアントに即時肯定応答を送信する。サーバはステップ330でサービス要求を受け入れ、ステップ332でサービス要求を処理する。サーバが要求を処理している間、クライアントはステップ312で他の処理を行っている。サーバも、この要求を処理する前に他の要求を処理することができる。ステップ332で要求の処理が完了すると、ステップ334でサーバはクライアントに応答324を送る。この応答はステップ314で受信され、クライアントは処理を続ける。
第４図の非同期システムにブリッジを挿入した場合に行われる対話を第５図に示す。ステップ310、312、および314での対話は第４図と同じであり、ステップ330、332、および334でのサーバの対話も同じである。要求320、即時応答322、および応答324は、それに対応するクライアントとブリッジとの間と、ブリッジとサーバとの間の応答に分割される。以下に、これらの対話に応答するブリッジの動作について述べる。ステップ310で要求320Aがクライアントからブリッジに送られる。ブリッジはステップ410でクライアントに即時肯定応答322Aを送り、ブリッジはサービス要求320Aを受け入れる。ブリッジは要求を処理する代わりに、ステップ412でクライアント名を記録し、ステップ414で別途処理があればそれを実行する。
この別途処理は、クライアントからの要求またはそれに付随するデータに対して実行することが望ましいものであればどのような別途処理でもよい。このような処理は、要求またはそれに付随するデータに変更を加えることもあれば、そのまま変えない場合もある。このような処理の例としては次のような処理がある。
1.要求で詳述されているメソッドが、要求に付随するデータと等しいパラメータを使用して呼び出されたことをログする。
2.サーバ間の作業負荷分散を行うためにいくつかのサーバのうちのどのサーバにこの要求を送るべきかを判断する処理を行い、その結果を使用して要求の送り先を決める。
3.要求を検査してどのサーバをクライアントが要求の送信先とみなしていたかを調べ、それからブリッジによってそのサーバに送る。
ステップ416で、ブリッジはサービス要求320Bをサーバに転送する。サーバはステップ330で即時肯定応答322Bをブリッジに送る。サーバが要求を処理している間、ブリッジはステップ420で他の処理を実行している。ステップ332でサーバによる要求の処理が完了すると、サーバはステップ334でブリッジに応答324Aを送る。この応答はステップ430で受け取られ、サーバからクライアントに返されるパラメータのログなどの別途処理があればそれがステップ432でブリッジによって行われる。ブリッジは次にステップ434でクライアントに応答324Bを転送する。
ブリッジ（第３図の300）は、以下の例１に示すように、クライアント・オブジェクトおよびサーバ・オブジェクトから継承によって導き出される。これは、クライアント・オブジェクトとサーバ・オブジェクトの両方のインタフェース（すなわち全ての属性およびメソッド）がブリッジによって継承されることを意味する。例１に、非同期システムの場合にブリッジがIDL言語でどのように定義されるかを示す。
例１−非同期ブリッジ・クラスの定義
//非同期ブリッジ・クラスを定義する
＃include"server_obj.idl"//サーバ・クラスの宣言
＃include"client_obj.idl"//クライアント・クラスの宣言
//上の２行ではサーバ・クラスとクライアント・クラスの両方のメソッドと属性が組み込まれる。
interface client_server_obj:client_obj,server_obj
//上記の行では、クライアント・クラスとサーバ・クラスの両方のすべての機能を有するものとして非同期ブリッジのインタフェースを定義する。
｛
同期環境
第６図を参照すると、同期モードで動作するクライアント53とサーバ54と共に使用するブリッジ300の構成要素が含まれている。ブリッジ300とサーバ54は「サーバ・オブジェクト」を含む。これらは、それぞれ「ブリッジのサーバ・オブジェクト」301と「サーバのサーバ・オブジェクト」501である。サーバ54は、「サーバのオブジェクト」503（サーバ・オブジェクトと混同してはならない）と呼ぶ少なくとも１つのオブジェクトを含む。これが、クライアントによって要求されたサービスを実際に提供するオブジェクトである。ブリッジ300は、ブリッジ自体の機能を備える「ブリッジのオブジェクト」304と呼ぶオブジェクトを含む。
クライアント53は、「ブリッジのサーバ・オブジェクト」301のローカルにおける代理である「ブリッジのサーバ・プロキシ」401と呼ぶプロキシ・オブジェクトを含む。クライアントは、これがサービスを提供するサーバ内の「サーバのサーバ・オブジェクト」501の代わりをするとみなす。同様に、ブリッジ300は、「サーバのサーバ・オブジェクト」501のローカルにおける代理である「サーバのサーバ・プロキシ」302と呼ぶプロキシ・オブジェクトを含む。前述のように、「サーバ・オブジェクト」とはサーバ内のオブジェクトを管理するオブジェクトである。
クライアント53は、「ブリッジのオブジェクト」304のローカルの代理である「ブリッジのオブジェクト・プロキシ」402と呼ぶプロキシ・オブジェクトも含む。クライアントは、これがサービスを提供するサーバ内の「オブジェクト」503の代わりをするとみなす。同様に、ブリッジ300は、「サーバのオブジェクト」503のローカルにおける代理である「サーバのオブジェクト・プロキシ」303と呼ぶプロキシ・オブジェクトを含む。これらのプロキシは、クライアント53によって開始されるクライアント53とサーバ54との間の通信で使用される。
同期システムでは、クライアント53によって通信が開始される。これらの通信は、クライアント53がブリッジ300と通信することができるようにするクライアント53内にある「ブリッジのオブジェクト・プロキシ」402と、ブリッジ300がサーバ54と通信することができるようにするブリッジ300内にある「サーバのオブジェクト・プロキシ」303とを使用して行われる。
第６図からわかるように、クライアント53、ブリッジ300、およびサーバ54を示す各ブロックの上部にあるオブジェクトとプロキシ・オブジェクトは、クライアントとブリッジによるオブジェクトの作成、破棄、および探索に使用される。クライアント53、ブリッジ300、およびサーバ54を示す各ブロックの下部にあるオブジェクトとプロキシ・オブジェクトは、クライアント53とブリッジ300とサーバ54との間の通信処理に使用される。
第７図に、同期環境において従来技術のクライアントと従来技術のサーバとの間で従来技術のネットワークを介して行われる対話を示す。同期環境では、クライアントがサーバにサービスの提供を求める要求を行うことによってサーバとの通信を開始する。サーバはその要求を処理し、要求の処理からの単純な戻りによってクライアントにその結果を返す。サーバはこの応答を戻すためにクライアントとの通信を開始しない。クライアント53は応答を、サーバ54上で呼び出したメソッドからの戻りパラメータを介して受け取るだけである。
従来技術のシステムでは、第４図を参照しながら前述した同期環境と非同期環境における動作には相違点が２つある。第１の相違は、ステップ310でクライアントがサービスを求める要求を行った後、クライアントはステップ312で他の処理を実行せず、ステップ510でサーバからの応答を待つことである。第２の相違点は、サーバがステップ322でクライアントに対して即時肯定応答を送らないことである。それ以外は、第７図に示す番号付きのステップは、第４図の対応する番号の付いたステップと同じである。
第７図の同期システムにブリッジを挿入した場合に行われる対話を第８図に示す。ステップ310および314でのクライアントの対話は第７図と同じであり、ステップ330、332、および334でのサーバの対話も同じである。要求320と応答324は、クライアントとブリッジとの間と、ブリッジとサーバとの間の対応する応答に分割される。以下に、これらの対話に応答するブリッジの動作について述べる。
ステップ410で、ブリッジはサービス要求320Aを受け入れる。ブリッジはこの要求を処理する代わりに、ステップ412でクライアント名を記録し、別途処理があればそれをステップ414で行う。この別途処理には、非同期環境に関連して第５図を参照しながら前述した別途処理項目の一部または全部が含まれる。ステップ416で、ブリッジはサービス要求をサーバに転送する。サーバが要求を処理している間、ブリッジはステップ610でサーバからの応答を待つ。ステップ332でサーバによる要求の処理が完了すると、サーバはステップ334でブリッジに応答324Aを送る。この応答はステップ430で受け取られ、サーバからクライアントに返されたパラメータのログなどの別途処理があればそれがステップ432でブリッジによって行われる。ブリッジ300は次にステップ434でクライアントに応答324Bを返す。
上述の説明からわかるように、クライアントはブリッジと同期して動作し、したがってクライアントがブリッジから見るインタフェースは、クライアントがサーバと直接通信している場合と同じである。ブリッジはサーバと同期して動作し、したがってサーバがブリッジから見るインタフェースはサーバがクライアントと直接通信している場合と同じである。
ブリッジはサーバのみから導き出される。クライアント53はサーバ54上でメソッドを呼び出し、それと同じメソッド内の戻りパラメータを介して応答を受け取るだけなので、明示的なクライアント・オブジェクトは不要である。別個の通信がサーバ54によって開始されることはない。同期システムの場合のオブジェクト300の定義を例２に示す。
例２−同期ブリッジ・クラスの定義
//同期ブリッジ・クラスを定義する
＃include"server_obj.idl"//サーバ・クラスの宣言
//上記の行ではサーバ・クラスのメソッドと属性が組み込まれる。
interface client_server_obj:client_obj,server_obj
//上記の行では、サーバ・クラスの機能を有するものとして同期ブリッジのインタフェースを定義する
｛
interface bridge_obj:server_obj
ブリッジの挿入
以上、非同期動作と同期動作の両方の場合について、ブリッジの構造と定義を定義した。いずれかの動作方法で使用するようにブリッジを定義したら、定義したブリッジをクライアントとサーバの間に透過的に挿入し、それによってサーバ作成要求が行われた場合にサーバ・オブジェクトの全インタフェースを備えたブリッジが代わりに作成されるようにする必要がある。
クライアント53とサーバはそれぞれのクライアント・クラスとサーバ・クラスのインスタンスを含む。リモート・オブジェクトの検索、リモート・オブジェクトのインスタンスの作成、およびリモート・オブジェクトに対するメソッドの呼出しに使用可能な方法は様々ある。
典型的な従来技術の方法について、第１図に戻って参照しながら以下に説明する。
1.DSOMオブジェクト・マネージャ（SOMD_ObjectMgr）（50にある）が、クライアントが初期設定されたときに作成されているか、または、クライアント53でオブジェクト要求ブローカ50の一部として使用可能なSOMD_Init（）関数を呼び出すことによってこの時点で作成しなければならない。
2.クライアント53と共に使用する適切なオブジェクト・クラスのサーバ54を探し出すために、クライアント53はSOMDObject_Mgrに対してメソッドを実行する。SOMDObject_Mgrは、リモート・サーバ54上の「サーバ・オブジェクト」（52にある）のローカルにおける代理として、クライアント53内にプロキシ・オブジェクト（50にある）を作成する。リモート・サーバ54内には「サーバ・オブジェクト」はまだ存在しないことに留意されたい。
3.クライアント53はサーバ・プロキシ・オブジェクトに対してSomdCreateObj（）メソッド呼出しを出す。このメソッド呼出しにはパラメータとして、クライアントが作成したいターゲット・オブジェクト51のクラスが含まれる。リモート・サーバとの通信が確立され、リモート・サーバ54上で適切なクラスの「サーバ・オブジェクト」（図示せず）が作成される。「サーバ・オブジェクト」（図示せず）が作成されると、その「サーバ・オブジェクト」は要求されたクラスのターゲット・オブジェクト51をサーバ54自体内に作成する。戻りパラメータの一部として、クライアント53に情報が供給され、ターゲット・オブジェクト51のプロキシ・オブジェクト49を作成することができるようにする。
4.これでクライアントはそのローカル・プロキシ・オブジェクト49に対してメソッド呼出しを出すことができるようになり、それらのメソッドがターゲット・オブジェクト51で実行され、その結果がクライアント53に返される。
「サーバ・オブジェクト」のクラスが複数ある場合がある。たとえば、プリント・サービスを提供するために使用されるサーバのクラスと、ファイル記憶サービスのためのクラスと、通信サービスのためのクラスがある場合がある。従来の技術では、これらのクラスは本発明の支援なしに互いに通信する。
以下に、ブリッジをクライアントとサーバの間に透過的に挿入する方法について第３図を参照しなら説明する。
従来技術の各「サーバ・オブジェクト」クラスに対応するブリッジ・クラスを作成する。「サーバのサーバ・オブジェクト」501は従来技術の「サーバ・オブジェクト」クラスのインスタンスである。「ブリッジのサーバ・オブジェクト」301はデフォルト・サーバ・クラスのサブクラスである。上記の例では、プリント・サービスの提供に使用するサーバのブリッジ・クラスと、ファイル記憶サービスに使用されるブリッジ・クラスと、通信サービスに使用されるブリッジ・クラスとがある。
各ブリッジ・サーバ・クラスの定義内の「サーバ・オブジェクト」（サーバ・クラスから継承される）を修正し、ブリッジ・サーバ・クラスのメンバとして「ブリッジのサーバ・オブジェクト」301が作成されるとそれにその修正が組み込まれるようにする。これらの修正はターゲット・オブジェクトを作成するメソッドと、「サーバ・オブジェクト」が受け取ったメソッドをサーバ内のターゲット・オブジェクトにディスパッチするメソッドに加えられる。
「サーバのオブジェクト」503（ターゲット・オブジェクト）を作成する修正されたメソッドは、サーバ内に「サーバのオブジェクト」503を作成することを求めるクライアントからの要求を受け取って、「ブリッジのオブジェクト」304をその場所に作成する。
「ブリッジのサーバ・オブジェクト」301が受け取ったメソッドをサーバ内の「サーバのオブジェクト」503（ターゲット・オブジェクト）にディスパッチする修正されたメソッドは、単にクライアント名を記録するだけで（第５図のステップ412）、別途処理（第５図のステップ414）を行い、メソッドをオブジェクトにディスパッチする元のディスパッチ・メソッドを呼び出す。
前述の実施例の適用
第９図を参照すると、前述の本発明のブリッジ300を使用して、１つのクライアント53が複数のサーバ54A〜54Dにサービスを要求することができる。クライアント53は、要求が異なるサーバ54Aから54Dで実行されていることがわからない。ブリッジ300は、要求を複数のサーバ54A〜54Dのうちのどのサーバに宛てて送るべきかを決定する。
クライアント53でもサーバ54A〜54Dでの追加のプログラミングを必要とせずに、複数のサーバ54A〜54Dのそれぞれの間における作業負荷分散を実現することができる。作業負荷分散を実現する実施例では、ブリッジ300は「ラウンドロビン」アルゴリズムを使用する。このアルゴリズムでは、新しいクライアント要求が出されるたびに次のサーバ54A〜54Dに順に送られる。作業負荷分散を実現する他の実施例では、各サーバ54A〜54Dから入手した応答時間を測定し、当業者に周知のより高度なアルゴリズムを使用して各サーバ54A〜54D間で作業負荷を分散させる。この２つの実施例は両方とも、サーバ54A〜54Dとクライアント53のいずれでもコードに修正をまったく加えずに実現することができる。
第10図に、従来技術の方式で一緒に接続された３個のサーバ54A〜54Cに接続された３個のクライアント53A〜53Cを示す。各クライアント53A〜53Cが各サーバ54A〜54Cへの接続901〜909を有する。
第11図を参照すると、前述の本発明のブリッジ300を使用することによって、複数のサーバ54A〜54Cに対してサービスを要求する複数のクライアント54A〜53Cが存在することが可能であり、その際、異なるサーバ54A〜54C上で要求が実行されていることやサーバ54A〜54Cが他のクライアント53A〜53Cのための要求を処理していることは、クライアント53A〜53Cのいずれにもわからない。ブリッジ300は、各クライアント53A〜54Cからの各要求を、複数のサーバ54A〜54Cのうちのどのサーバに宛てて送るかを決定する。
すべての要求をブリッジ300を介して経路指定することによって、ネットワーク内の接続が削減される。より一般的な態様では、ｎ個のクライアント53とｍ個のサーバ54を有するシステムにおいて、接続数がｎ＊ｍ個からｎ＋ｍ個に減少する。
本発明は、クライアント−サーバ環境における分散コンピューティングに関し、具体的には前記環境におけるクライアントとサーバの間でのブリッジの使用に係わる。
発明の背景
オブジェクト指向プログラミングの概要
オブジェクト指向プログラミングが開発される以前に、構造化プログラミングと呼ばれるプログラミングの一形態が使用され、今でも広く使用されている。この技法では、まずさまざまな関数を定義し、次にプログラムがその定義された関数を適切な時点で呼び出してアプリケーション・プログラムの全体的な目的を実現することから成る。このような関数は、データを操作するために使用するメソッドを定義するが、データ自体は定義しない。構造化プログラミングはモジュール化手法の機会をもたらした。これは、メンテナンスやデバッグが難しい「スパゲッティ・コード」を克服する重要な改良であった。それにもかかわらず、構造化プログラミングには、プログラムによってモデル化される世界における概念および実体と、プログラミング言語における概念との間の「意味ギャップ」や、プログラム・コードのテキスト性、コード・モジュールの再使用可能性の限界などいくつかの欠点も残されている。
その後、オブジェクト指向プログラミングと呼ばれる新しいプログラミング・パラダイムが開発された。この技法では、関数を定義する代わりに、「クラス」を定義する。クラス定義によって、そのクラスの任意のインスタンスが実行することができるメソッドと、そのクラスのインスタンスに含まれる属性（またはデータ）とを定義する。オブジェクトはクラスのメンバーであり、クラス定義で定義されているメソッドを実際に実行することができる。オブジェクトは、クラスによって定義された各属性に付随する値を持つ。オブジェクトは、ゼロまたは１個以上の属性を持ち、そのオブジェクトに対して実行することができるゼロまたは１個以上のメソッドを持つ。
オブジェクトとのインタフェースは、メソッドを介して属性にアクセスすることができる方法である。そのクラスから導き出されるすべてのオブジェクトがそのクラスのインタフェースを共有する。オブジェクトの実現部分はオブジェクトを呼び出すアプリケーションから隠蔽される。オブジェクトへのインタフェースが変わらない限り、アプリケーションに影響を与えることなく実現部分を完全に変えることはできない。
オブジェクトが内部でどのように「見える」か、また内部で何を「行う」かを記述する必要なしにオブジェクトの「外観」を記述するこの技法を単純化した例として、また、そのようなオブジェクト指向プログラミングの重要な利点を例示するための例として、オブジェクト指向手法によってモデル化することができる普通の家庭用トースタを考えてみる。外部「インタフェース」は、トーストの所望の焼き加減を調節するパラメータを本質的に表すつまみと、パンを入れるスロットと、トースタへの挿入とトースタの起動を行うレバーとから成る。重要な概念は、この種の家電製品のエンドユーザはそれを使用するためにトースタの「内部」を知る必要がないことである。たとえば、熱が電気によって供給されるのか、化学薬品やその他の手段によって供給されるのかを知る必要はない。ユーザは上記の外面部と正しくインタフェースするだけでよい。
プログラミングにおけるこの進化の利点は、上記の例を続けて用いると、トースタをモデル化するプログラミング・コードのモジュールであるオブジェクトの設計者が、ユーザにとって内部が見えないために、たとえばユーザがそのオブジェクトを使用する能力に影響を与えることなくトースタの内部要素を改良することに焦点を絞ることができ、効率を向上させることができることである。したがって、より抽象的に言うと、オブジェクト指向技法は本質的に、オブジェクトのインタフェースをオブジェクトの実現部分から分離する利点をもたらすものと見なすことができる。ソフトウェア環境においては、それによって、外部の「つまみ」などやその予想される動作が変わらない限り、アプリケーション・プログラム全体を書き直さなくてもオブジェクトの内部を書き直し、改良することができる。
本発明の理解を助けるオブジェクト技法に関するその他の一般的背景については、デイビッドA.テイラー（David A.Teylor）による「Object Oriented Technology−Ａ Manager's Guide」（copyright 1990,Servio Corporation）を参照されたい。
オブジェクト指向プログラミングの発展に伴い、様々な組織やソフトウェア会社によっていくつかの「オブジェクト・モデル」がさらに改良され、開発された。オブジェクトとその外部インタフェースを定義する方法が規定され、そのような様々なオブジェクト・モデルによって特にカプセル化と継承の特性が規定された。ある程度の高レベルから見れば、これらの様々なオブジェクト・モデルはきわめて類似している。たとえば、システム・オブジェクト・モデル（SOM）、コモンLispオブジェクト・システム（CLOS）、Smalltalk、およびＣ＋＋などがある。本質的には、これらの様々なオブジェクト・モデルはオブジェクトが何であるかという問いに答える規則の集まりに過ぎず、より低レベルで検討するとそれぞれわずかに異なった答えが出る。たとえば、言語構文とカプセル化および継承の機能はオブジェクト・モデルによって異なる。
これらの相違の直接の結果として、異なるオブジェクト指向言語およびオブジェクト・モデルの使用可能性により生じる１つの問題は、そのような言語の混合で書かれたオブジェクト・プログラム間のインターオペラビリティを実現することができないことであった。この問題は、オブジェクト技法の重要な利点の１つであるコードの再使用可能性に悪影響を与える。業界を悩ませるこの問題を解決しようとして、委員会は共通オブジェクト要求ブローカ・アーキテクチャ（CORBA）に到達した。これには標準化インタフェース定義言語（IDL）が含まれていた。業界ではオブジェクトインタフェースをどのように規定するか、すなわち、オブジェクト・インタフェースを定義する標準に関して本質的に合意に達し、その結果、１つのベンダーによって定義されたオブジェクトを他のベンダーが使用することが可能になった。「The Common Object Request Broker:Architecture and Specification」（OMG Document Number 91.12.1 Revision1.1）を参照されたい。
オブジェクト要求ブローカ（ORB）
CORBAアーキテクチャで記述されたオブジェクト要求ブローカ（ORB）は、UNIXオペレーティング・システム環境で作業をする人には周知のリモート・プロシージャ・コール（RPC）に似ている（UNIXはX/Open CO.Ltd.によって独占的にライセンス許諾される商標である）。
従来技術のシステムを第１図に示す。これは、クライアント／サーバ環境にある従来技術のオブジェクト要求ブローカを示すブロック図である。
このORBは２つの部分に分かれており、そのうちの部分50はORBを使用して各クライアントで実行され、部分52はORBをサポートする各サーバで実行される。RPCと同様に、ORBは１つのアドレス空間53で稼働しているクライアント・アプリケーション48が別のアドレス空間54のオブジェクト51と通信することができるようにする機構である。他方のアドレス空間54、すなわちクライアント・アプリケーション48が実行されているアドレス空間と同じアドレス空間53ではないアドレス空間にあるオブジェクト51を「リモート」オブジェクトと呼ぶ。クライアント・アプリケーション48と同じアドレス空間53にあるオブジェクトを「ローカル」オブジェクトと呼ぶ。ORB50は１つのアドレス空間53内のクライアント・アプリケーション48からの呼出しを代行受信し、それをネットワーク・プロトコルにカプセル化し、別のアドレス空間54内のターゲット・オブジェクト51のための呼出しをデコードし、その結果を呼び出し側クライアント・アプリケーション48に返す。これによって、一方のアドレス空間（ローカル）で稼働しているクライアント・アプリケーション48が他方のアドレス空間（リモート）内のオブジェクト51と通信することができる。ORBは、オブジェクト指向プログラミングによって得られる高度の柔軟性と能力を備えるように設計されている点で、RPCが改良されたものである。プロキシ・オブジェクト49の機能については後で詳述する。
「オブジェクト・モデル」は様々な組織やソフトウェア会社によって開発されている。オブジェクト・モデルはオブジェクトとその外部インタフェースの定義の仕方を規定する。このようなオブジェクト・モデルの１つは、IBM Corporationのシステム・オブジェクト・モデル（SOM）である。SOMでは、オブジェクトを使用するすべてのアプリケーションはそれらのオブジェクトが入っている１つのアドレス空間内で実行される。SOM内で作成されるものは、分散システム・オブジェクト・モデル（DSOM）と呼ばれるオブジェクト・クラスのフレームワークである。DSOMでは、１つのアドレス空間内の（クライアントで稼働している）アプリケーションは別のアドレス空間（サーバに属するアドレス空間など）内のオブジェクトにアクセスすることができる。これらのアドレス空間は同じシステムと異なるシステムのどちらにあってもよい。実際には、システムは同じプラットフォームで稼働している必要はない。たとえば、OS/2システム上のアドレス空間で稼働しているクライアント・アプリケーションがAIX/6000システム上のアドレス空間にあるオブジェクトにアクセスすることができ、その逆も可能である。SOMとDSOMの両方については、IBM Corporationが発行している「SOMobject:A Practical Introduction to SOM and DSOM」（Copyright 1994,Order no.GG24−4357−00）に記載されている。
欧州特許出願第0501610号では、異なるプロセス内のオブジェクトが通信することができるようにする機構が開示されている。通信アプリケーション・プログラミング・インタフェース（API）を使用するようにプログラムが明示的に作成される。
上記のシステム・オブジェクト・モデル（SOM）は、CORBAとIDLに準拠した１つのオブジェクト・モデルである。準拠とは、SOMオブジェクトがCORBAのセマンティクスに従っており、SOMオブジェクトがIDL構文で定義されているという意味である。
DSOMのフレームワークは、ターゲット・オブジェクトがインスタンス化される場所やプラットフォームのタイプをクライアント・プログラマが知らなくても済むようにするオブジェクト実現部を備える。このプロセス間通信に使用される通信機構は、プログラマには見えないように完全に隠蔽される。
クライアント−サーバ・アーキテクチャ
クライアント−サーバ・アーキテクチャでは、アプリケーション・プログラムは個別の構成要素として実行される個別のタスクに分けられる。各構成要素にはクライアントまたはサーバの役割が割り当てられる。１つの構成要素は、ある目的のためにはサーバの役割を果たし、他の目的のためにはクライアントの役割を果たすことができる。各構成要素は独立して動作し、特定の責任を担う。クライアントの役割が割り当てられた構成要素は、サーバ・プロセス内のオブジェクトに対するメソッド呼出しを行うことによって、サーバにサービスを要求する。サーバの役割が割り当てられた構成要素は、それらのメソッド呼出しを受け取り、該当するオブジェクトに対してそれらのメソッド呼出しを行い、その結果をクライアントに返すことによってサービスを提供する。クライアントとサーバは事前定義されたプロトコルを使用してメッセージを交換する。サーバは多くのクライアントにサービスを提供することができ、クライアントは多くのサーバにサービスを要求することができる。
このようなシステムでは、クライアントまたはサーバがその中に特定のコードを持っていない限り、サーバのクライアントによって行われた要求の監視やログを行ったり、そのような要求に付随するデータの監視やログを行ったりすることができない。問題判別のために、そのような要求の監視またはログを行うことが望ましいと考えられる。
上述のシステムでは、サーバ間の作業負荷分散は、クライアントがクライアント自体内にそのような作業負荷分散機能を含むように設計されていない限り不可能である。クライアント自体内にそのような作業負荷分散機能を組み込むことの欠点は、クライアント内の各要求に付随するオーバーヘッドと、そのような作業負荷分散機能を含む各クライアントに複雑さが生じることである。最高のパフォーマンスを提供するサーバを選定することによってクライアントの全体的なパフォーマンスを向上させるために、作業負荷分散が望ましい。
各クライアントと、そのクライアントがサービスを要求することができることが望ましい各サーバとの間に通信リンクを設ける必要がある。その結果、多数のクライアントと多数のサーバがあるシステムは著しく複雑化する。
背景技術
機能伝送によって、アプリケーション・プログラムはファイル制御要求を伝送して他のシステムが所有しているファイルにアクセスすることができ、一時データ機能および一時記憶域機能を求める要求を伝送して他のシステム内の一時データ待ち行列および一時記憶待ち行列との間でデータの送受信を行うことができる。また、SNA LUタイプ６プロトコルを実施する他のシステムでのトランザクションの開始も可能にする。システム・プログラマは資源定義テーブルの項目を使用して、指定資源がローカル（または要求側）システム上ではなくリモート（または所有側）システム上にあるように指定することができる。機能伝送の使用は、要求側システムとリモートシステムの両方にとって透過である。要求とそれに付随するデータの記録と監視が可能であるが、そのような監視機能を持たせたい各アプリケーションごとに別々に実施しなければならない。機能伝送の詳細は、「CICS/ESA V4.1 Intercommunication Guide」（IBM Corporation発行、Copyright 1977、1994、Order no.SC33−1181−00）に記載されている。
プロキシを使用して、クライアントで稼働しているローカル・アプリケーションからサーバ内のリモート資源にアクセスすることができる。プロキシとは、他のオブジェクトの代わりとなり、そのメッセージを受信し、それらを何らかの方法で処理することができる、第１図のプロキシ・オブジェクト49のようなオブジェクトである。これには、メッセージを第１図の51などのターゲット・オブジェクトに転送することが含まれることが多い。プロキシは、オブジェクト指向プログラミングで周知であり、DSOM（分散システムオブジェクト・モデル）によって使用される。詳細については、SOMobjects Publicationsに含まれているSOMobjects Developer Toolkit User's Guide Version2.0（IBM Corporation発行、Gopyright 1994、Order no.S96F−8649）を参照されたい。プロキシは、クライアントからサーバに送られる要求メッセージを受け取り、サーバからクライアントに送られる戻りメッセージを受け取る。プロキシは、クライアントに宛てられたサーバからの非同期戻りメッセージを受け取ることはできない。プロキシは、一般にサーバ内の単一のターゲット・オブジェクトに関連づけられ、単一のサーバ内または複数のサーバ内の複数のオブジェクトに関連づけられることはない。
欧州特許出願第0518195号では、アプリケーション・プログラムにリンクされたライブラリ・ルーチンによって実施されるプラットフォーム独立アプリケーション・プログラミング・インタフェース（API）が開示されている。アプリケーション・プログラムはそのAPIに合わせて特別に作成され、クライアント・プロセスおよびサーバ・プロセスはAPIを明示的に知ってそれを使用しなければならない。この実施態様の問題点は、クライアントとサーバにリダイレクトがわからないようにクライアント−サーバ・フローを代行受信する透過的な機構を備えないことである。
PCT特許出願WO95/17718号では、オペレーティング・システムと統合された、リモート・プロシージャ・コール（RPC）とのオブジェクト指向インタフェースが開示されている。クライアント・プログラムとサーバ・プログラムは、互いに通信するときにRPCアプリケーション・プログラミング・インタフェース（API）を利用するように特別に作成される。この実施態様も、クライアントとサーバにリダイレクトがわからないようにクライアント−サーバ・フローを代行受信する透過的機構を備えない。
PC Magazine v13,n10（1994年５月31日発行、Gagnon Ｇ）の「Building ａ better app、SQL style」では、共通APIを多くの異なるAPIにマップすることができるようにする方法が開示されている。
DBMS,v5,n9（1992年８月発行、Roti Ｓ）の「SQL＊NET version2:client/server networking is easier with SQL＊NET V2 and the MultiProtocol Interchange」では、１つのAPIからもう１つのAPIに変換する中間構成要素が開示されている。この中間要素はそれに対して要求される変換タスクを実行するように特別に作成される。この中間要素がないと、その２つのAPIに合わせて作成された構成要素は通信することができない。
発明の開示
したがって、本発明は、分散オブジェクト指向コンピュータ・システムにおいてクライアントとサーバの間で使用するブリッジを提供する。このブリッジは、サーバのインタフェースに対応するクライアントとのインタフェースと、クライアントのインタフェースに対応するサーバとのインタフェースとを定義する。
第１の実施例では、クライアントとサーバは非同期的に動作し、ブリッジはクライアントおよびサーバから継承によって導き出され、ブリッジはサーバから継承されたメソッドを上書き変更（override）して、要求を行うクライアントの名前を記録し、その要求をサーバに転送し、ブリッジはクライアントから継承したメソッドを上 書き変更してクライアントに応答パラメータを転送する。
第２の実施例では、クライアントとサーバは同期して動作し、ブリッジは継承によってサーバから導き出され、ブリッジはサーバから継承されたメソッドを上書き 変更してサーバ上のメソッドを呼び出し、クライアントに応答パラメータを転送する。
好ましい実施例では、ブリッジはクライアントとサーバとの間の要求とその要求に付随するデータの監視と記録を行う手段をさらに含む。また、好ましい実施例では、ブリッジは、サーバ間の作業負荷分散を行う手段をさらに含む。そのような作業負荷分散は、応答時間を測定し、測定された応答時間に応じてサーバにクライアント要求を送ることによって行うことができる。他の好ましい実施例では、ブリッジはｍ個のクライアントとｎ個のサーバ（ただしｎおよびｍは２以上の整数）に接続され、ブリッジはネットワーク接続数をｎ＊ｍ個からｎ＋ｍ個に減らす。
分散オブジェクト指向コンピュータ・システムはCORBA準拠システムであり、分散オブジェクト指向コンピュータ・システムはDSOMクラス・ライブラリを使用することが好ましい。しかし、本発明はそのようなシステムでの応用やそのようなクラス・ライブラリの使用には限定されない。たとえば、分散オブジェクト指向システムはマイクロソフトのコンポーネント・オブジェクト・モデル（COM）に準拠していてもよい。また、分散オブジェクト環境としてSunSoftから、およびORBプラスとしてヒューレット・パッカードCo.から入手可能な、分散オブジェクト管理機能（DOMF）を使用することもできる。
本発明は、分散クライアント−サーバ・コンピュータ・システムを稼働させる方法であって、ブリッジのために、サーバのインタフェースに対応するクライアントとのインタフェースを定義するステップと、クライアントのインタフェースに対応するサーバとのインタフェースを定義するステップとを含む方法も提供する。
第１の実施例では、クライアントとサーバは非同期的に動作し、クライアントとのインタフェースを定義するステップが、クライアント・インタフェースをサーバから継承によって導き出すステップと、サーバから継承したメソッドを上書き変更して、要求を行うクライアントの名前を記録し、その要求をサーバに転送するステップとを含み、サーバとのインタフェースを定義するステップが、前記サーバ・インタフェースをクライアントから継承によって導き出すステップと、前記クライアントから継承したメソッドを上書き変更して前記クライアントに応答パラメータを転送するステップとを含む。
第２の実施例では、クライアントとサーバは同期して動作し、クライアントとのインタフェースを定義するステップが、クライアント・インタフェースをサーバから継承によって導き出すステップと、サーバから継承したメソッドを上書き変更してサーバ上でメソッドを呼出し、クライアントに応答パラメータを転送するステップとを含む。
本発明は、１つまたは複数のサーバと、１つまたは複数のクライアントと、前述のブリッジとを含む分散オブジェクト指向コンピュータ・システムも提供する。
【図面の簡単な説明】
以下に本発明の実施例について例として添付図面を参照しながら説明する。
第１図は、クライアント／サーバ環境にある従来技術のオブジェクト要求ブローカを示すブロック図である。
第２図は、本発明と共に使用するのに適した従来技術のコンピュータ・システムを示すブロック図である。
第３図は、非同期的に動作するように構成された従来技術のクライアントとサーバを含むシステムを、本発明のブリッジと共に示すブロック図である。
第４図は、従来技術のクライアントとサーバの非同期動作を示す流れ図である。
第５図は、本発明による第３図のシステムの非同期動作を示す流れ図である。
第６図は、同期して動作するように構成された従来技術のクライアントとサーバを含むシステムを、本発明のブリッジと共に示すブロック図である。
第７図は、従来技術のクライアントとサーバの同期動作を示す流れ図である。
第８図は、本発明による第６図のシステムの同期動作を示す流れ図である。
第９図は、本発明によるブリッジを使用した複数のサーバ間の作業負荷分散を示すブロック図である。
第10図は、複数のクライアントと複数のサーバの従来技術の接続を示すブロック図である。
第11図は、本発明によるブリッジを使用した複数のクライアントと複数のサーバとの接続を示すブロック図である。
発明の詳細な説明
本発明を実施することができる適合するハードウェア
本発明は、いくつかの異なるオペレーティング・システム下にある様々なコンピュータまたはコンピュータの集合上で実行することができる。コンピュータは、たとえばパーソナル・コンピュータ、ミニ・コンピュータ、メインフレーム・コンピュータ、または他のコンピュータの分散ネットワーク内で稼働するコンピュータとすることができる。特定のコンピュータの選定はメモリおよびディスクの必要記憶容量によってのみ限定されるが、本発明ではIBM PS/2シリーズのコンピュータを使用することができる（IBMはIBM Corporationの登録商標であり、PS/2は商標である）。IBMのPS/2シリーズ・コンピュータの詳細については、Technical Reference Manual Personal System/2（Model 80）（IBM Corporation Part No.68X 2256 Order Number S68X−2254）を参照されたい。IBM PS/2パーソナル・コンピュータで実行することができるオペレーティング・システムはIBMのOS/2 2.0であり、IBM OS/2 2.0オペレーティング・システムの詳細については、OS/2 2.0 Technical Library,Programming Guide Vol.1,2,3 Version 2.00（Order Nos.10G6261,10G6495、10G6494）を参照されたい（OS/2はIBM Corporationの商標である）。
代替実施例では、コンピュータ・システムはAIXオペレーティング・システム上で稼働するIBM RISC System/6000ラインのコンピュータとすることができる（RISC System/6000およびAIXはIBM Corporationの商標である）。RISC System/6000の様々なモデルについては、たとえばRISC System/6000,7073および7016 POWERstation and POWERserver Hardware Technical Reference（Order No.SA23−2644−00）など、IBM Corporationの多くの刊行物に記載されている（POWERstationおよびPOWERserverはIBM Corporationの商標である）。AIXオペレーティング・システムについては、General Concepts and Procedure−−AIX Version3 for RISC System/6000（Order No.sc23−2202−00）およびIBM Corporationのその他の刊行物に記載されている。
第２図には、システム・ユニット11と、キーボード12と、マウス13と、表示装置14を含むコンピュータ10のブロック図が図示されている。システム・ユニット11は、１本または複数のシステム・バス21を含み、システム・バスには様々な構成要素が接続され、それによって様々な構成要素間の通信を行う。マイクロプロセッサ22がシステム・バス21に接続され、やはりシステム・バス21に接続された読取り専用メモリ（ROM）23とランダム・アクセス・メモリ（RAM）24によってサポートされている。IBM PS/2シリーズのコンピュータのマイクロプロセッサは、386または486マイクロプロセッサを含むインテル・ファミリのマイクロプロセッサのうちの１つである。しかし、68000、68020、または68030マイクロプロセッサなどのモトローラのマイクロプロセッサ・ファミリや、PowerPCチップなどのIBM製の様々な縮小命令セット・コンピュータ（RISC）マイクロプロセッサその他のマイクロプロセッサ、またはヒューレット・パッカード、サン、モトローラおよびその他のマイクロプロセッサなど、他のマイクロプロセッサもこの特定のコンピュータで使用することができる。
ROM23は、他のコードの他に、ディスク・ドライブ、キーボードなどの基本ハードウェア動作を制御する基本入出力システム（BIOS）を含む。RAM24は、オペレーティング・システムとアプリケーション・プログラムがロードされるメイン・メモリである。メモリ管理チップ25がシステム・バス21に接続され、RAM24とハード・ディスク・ドライブ26とフロッピィ・ディスク・ドライブ27との間のデータの受渡しを含む直接メモリ・アクセス操作を制御する。システム・バス21にはCD ROM32も結合され、たとえばマルチメディア・プログラムやプレゼンテーションなど大量のデータを記憶するために使用される。
このシステム・バス21には、様々な入出力コントローラ、キーボード・コントローラ28、マウス・コントローラ29、ビデオ・コントローラ30、およびオーディオ・コントローラ31も接続される。当然ながら、キーボード・コントローラ28はキーボード12のハードウェア・インタフェース、マウス・コントローラ29はマウス13のハードウェア・インタフェース、ビデオ・コントローラ30は表示装置14のハードウェア・インタフェース、オーディオ・コントローラ31はスピーカ15aおよび15bのハードウェア・インタフェース機能を備える。トークン・リンク・アダプタなどの入出力コントローラ40によって、他の同様に構成されたデータ処理システムとネットワーク46を介して通信することができる。
本発明の好ましい実施例の１つでは、第１図を参照しながら前述した命令48〜52のセットが、大体前述のように構成された１つまたは複数のコンピュータ・システムのランダム・アクセス・メモリ24に入っている。この１組の命令は、コンピュータ・システムが必要とするまで、たとえばハード・ディスク・ドライブ26、または最終的にCD−ROM32で使用される光ディスクまたは最終的にフロッピィ・ディスク・ドライブ27で使用されるフロッピィ・ディスクなどの取り外し可能メモリなど、別のコンピュータ・メモリに記憶することができる。ORBを使用して相互に結合されるメモリ・アドレス空間は、ネットワーク46を介して通信する別々のシステムに存在することもでき、第２図に示すように１つのコンピュータ・システムのメモリ内の２つ以上のアドレス空間53、54とすることもできる。
ブリッジ
第３図を参照すると、本発明ではクライアント53とサーバ54の間にブリッジ300を設ける。このブリッジ300の目的は、サーバ54に宛てられたクライアント53からの要求を受け取り、その要求をサーバ54に転送し、クライアント53に宛てられたサーバ54からの応答を受け取り、その応答をクライアント53に転送することである。ブリッジ300は、サーバ54のインタフェースに対応するクライアント53とのインタフェースと、クライアント53のインタフェースに対応するサーバ54とのインタフェースとを提供する。このようにして、クライアント53とサーバ54のいずれもブリッジ300の存在を判断することができず、両者ともブリッジが存在しないかのように動作する。
本発明の実施例について説明する。１つは非同期環境用で稼働し、１つは同期環境で稼働するものである。非同期環境（第５図に示す）では、クライアント53はサーバ54からの応答を待つ間、他の処理を続ける。同期環境（第８図に示す）では、クライアント53はサーバ54からの応答を待ってから処理を続ける。
非同期環境
第３図を参照すると、非同期モードで動作するクライアントとサーバと共に使用するブリッジ300の構成要素が含まれている。クライアント53、ブリッジ300、およびサーバ54はすべて、DSOM用語で「サーバ・オブジェクト」と呼ばれるものを備える。これらはそれぞれ、「クライアントのサーバ・オブジェクト」404、「ブリッジのサーバ・オブジェクト」301、および「サーバのサーバ・オブジェクト」501として図示されている。これらのオブジェクトを、サーバが実行する機能やサーバ自体と混同してはならない。サーバ・オブジェクトとは、サーバ内のオブジェクトを管理してクライアント・アプリケーションがサーバ内のオブジェクトの作成と破棄を行うことができるようにするオブジェクトである。サーバ・オブジェクトは、サーバ内のどのオブジェクトが要求を処理すべきかを識別し、受信したそのサーバに対するそのような要求を、識別したオブジェクトにディスパッチして実行させる。
クライアント53は、「クライアントのオブジェクト」403と呼ばれる少なくとも１つのオブジェクトを含む。このオブジェクトは、クライアントにおいてサーバ54に対してサービスの提供を求める要求のイニシエータである。クライアント・アプリケーション（図示せず）が「クライアントのオブジェクト」403に対して呼び出しを行い、データに対する操作を実行する。これらの操作は、「クライアントのオブジェクト」403自体内でローカルに行われるか、またはサーバ54にサービスを要求する「クライアントのオブジェクト」403を使用してリモートで行われる。サーバ54は、「サーバのオブジェクト」503（サーバ・オブジェクトと混同してはならない）と呼ばれる少なくとも１つのオブジェクトを含む。これは、第１図および第２図を参照しながら前述したターゲット・オブジェクトに相当する。これは、「クライアントのオブジェクト」403によって要求されたサービスを実際に提供するオブジェクトである。ブリッジ300は、「ブリッジのオブジェクト」304と呼ぶオブジェクトを含み、ブリッジ自体の機能を備える。
プロキシ・オブジェクト
クライアント53、ブリッジ300、およびサーバ54はすべて、DSOM用語でプロキシ・オブジェクトと呼ばれるものを備える。プロキシ・オブジェクトとは、リモート・ターゲット・オブジェクトの代わりをするローカルの代理である。プロキシ・オブジェクトは、ターゲット・オブジェクトのインタフェースを継承し、それによって同じメソッドに応答する。プロキシ・オブジェクト上で呼び出されたメソッドはローカルでは実行されず、実ターゲット・オブジェクトに転送されて実行される。クライアントで稼働しているプログラムは、そのプログラムがそれに対して操作を行うサーバ内の各リモート・オブジェクトのローカル・プロキシ・オブジェクトをクライアント内に常に有する。プロキシ・オブジェクトはその内部に、ターゲット・オブジェクトが入っているサーバ内の記憶場所を指すポインタを含む。プロキシ・オブジェクトは、リモート・オブジェクトに対するメソッドを呼び出すようにリモート・サーバに対して要求が行われると、DSOM実行時環境によって作成される。
クライアント53は、「ブリッジのサーバ・オブジェクト」301の代わりをするローカルにおける代理である「ブリッジのサーバ・プロキシ」（401）と呼ぶプロキシ・オブジェクトを含む。クライアントは、これがサービスを提供するサーバ内の「サーバのサーバ・オブジェクト」501の代理をするものとみなす。同様に、ブリッジ300は、「サーバのサーバ・オブジェクト」501のローカルにおける代理である「サーバのサーバ・プロキシ」302と呼ぶプロキシ・オブジェクトを含む。前述のように「サーバ・オブジェクト」とは、サーバ内のオブジェクトを管理するオブジェクトである。
クライアント53は、「ブリッジのオブジェクト」304のローカルにおける代理である「ブリッジのオブジェクト・プロキシ」402と呼ぶプロキシ・オブジェクトも含む。クライアントはこの代理を、サービスを提供するサーバ内のオブジェクト503であるとみなす。同様に、ブリッジ300は、「サーバのオブジェクト」503のローカルの代理である「サーバのオブジェクト・プロキシ」303と呼ぶプロキシ・オブジェクトを含む。これらのプロキシは、クライアント53によって開始されるクライアント53とサーバ54との間の通信に使用される。非同期システムでは、サーバ54がクライアント53宛ての応答を持っている場合、通信はサーバ54によっても開始される。これらの通信は、サーバ54がブリッジ300と通信することができるようにするサーバ内にある「ブリッジのオブジェクト・プロキシ」502と、ブリッジ300がクライアント53と通信することができるようにするブリッジ300内にある「クライアントのオブジェクト・プロキシ」305とを使用して行われる。
上記の説明からわかるように、第３図でクライアント53、ブリッジ300、およびサーバ54を示す各ブロックの上部にあるオブジェクトとプロキシ・オブジェクトは、クライアントとブリッジによるオブジェクトの作成、破棄、および探索に使用される。第３図でクライアント53、ブリッジ300、およびサーバ54を示す各ブロックの下部にあるオブジェクトとプロキシ・オブジェクトは、クライアント53とブリッジ300とサーバ54との間における通信プロセスに使用される。
第４図に、非同期環境における従来技術のクライアントと従来技術のサーバとの間で従来技術のネットワークを介して行われる対話を示す。非同期環境では、クライアントはサーバに対してサービスを提供するように求める要求を行うことによってサーバとの通信を開始する。サーバはその要求に肯定応答し、クライアントは他の処理を続ける。サーバは遅延後に要求を処理することができ、サーバもその遅延の間に他の処理を実行することができる。サーバは要求を処理すると、クライアントに応答を送ることによってクライアントとの別の通信を開始する。この通信は、「サーバ」が「クライアント」に対して、前の要求からの応答を受け入れるように求める要求を事実上行うことによって開始される。このような状況では、「サーバ」と「クライアント」が逆の役割を持っていると見なすことができ、サーバはクライアントに対して応答を受け入れるように要求する。非同期的に動作している場合にクライアントが「サーバ・オブジェクト」を必要とするのはこのためである。
ステップ310で、クライアントはサーバに対してサービスの提供を求める要求を行う。この要求はステップ320でネットワークを介してサーバに送信される。サーバはステップ322でクライアントに即時肯定応答を送信する。サーバはステップ330でサービス要求を受け入れ、ステップ332でサービス要求を処理する。サーバが要求を処理している間、クライアントはステップ312で他の処理を行っている。サーバも、この要求を処理する前に他の要求を処理することができる。ステップ332で要求の処理が完了すると、ステップ334でサーバはクライアントに応答324を送る。この応答はステップ314で受信され、クライアントは処理を続ける。
第４図の非同期システムにブリッジを挿入した場合に行われる対話を第５図に示す。ステップ310、312、および314での対話は第４図と同じであり、ステップ330、332、および334でのサーバの対話も同じである。要求320、即時応答322、および応答324は、それに対応するクライアントとブリッジとの間と、ブリッジとサーバとの間の応答に分割される。以下に、これらの対話に応答するブリッジの動作について述べる。ステップ310で要求320Aがクライアントからブリッジに送られる。ブリッジはステップ410でクライアントに即時肯定応答322Aを送り、ブリッジはサービス要求320Aを受け入れる。ブリッジは要求を処理する代わりに、ステップ412でクライアント名を記録し、ステップ414で別途処理があればそれを実行する。
この別途処理は、クライアントからの要求またはそれに付随するデータに対して実行することが望ましいものであればどのような別途処理でもよい。このような処理は、要求またはそれに付随するデータに変更を加えることもあれば、そのまま変えない場合もある。このような処理の例としては次のような処理がある。
1.要求で詳述されているメソッドが、要求に付随するデータと等しいパラメータを使用して呼び出されたことをログする。
2.サーバ間の作業負荷分散を行うためにいくつかのサーバのうちのどのサーバにこの要求を送るべきかを判断する処理を行い、その結果を使用して要求の送り先を決める。
3.要求を検査してどのサーバをクライアントが要求の送信先とみなしていたかを調べ、それからブリッジによってそのサーバに送る。
ステップ416で、ブリッジはサービス要求320Bをサーバに転送する。サーバはステップ330で即時肯定応答322Bをブリッジに送る。サーバが要求を処理している間、ブリッジはステップ420で他の処理を実行している。ステップ332でサーバによる要求の処理が完了すると、サーバはステップ334でブリッジに応答324Aを送る。この応答はステップ430で受け取られ、サーバからクライアントに返されるパラメータのログなどの別途処理があればそれがステップ432でブリッジによって行われる。ブリッジは次にステップ434でクライアントに応答324Bを転送する。
ブリッジ（第３図の300）は、以下の例１に示すように、クライアント・オブジェクトおよびサーバ・オブジェクトから継承によって導き出される。これは、クライアント・オブジェクトとサーバ・オブジェクトの両方のインタフェース（すなわち全ての属性およびメソッド）がブリッジによって継承されることを意味する。例１に、非同期システムの場合にブリッジがIDL言語でどのように定義されるかを示す。
例１−非同期ブリッジ・クラスの定義
//非同期ブリッジ・クラスを定義する
＃include"server_obj.idl"//サーバ・クラスの宣言
＃include"client_obj.idl"//クライアント・クラスの宣言
//上の２行ではサーバ・クラスとクライアント・クラスの両方のメソッドと属性が組み込まれる。
interface client_server_obj:client_obj,server_obj
//上記の行では、クライアント・クラスとサーバ・クラスの両方のすべての機能を有するものとして非同期ブリッジのインタフェースを定義する。
｛
同期環境
第６図を参照すると、同期モードで動作するクライアント53とサーバ54と共に使用するブリッジ300の構成要素が含まれている。ブリッジ300とサーバ54は「サーバ・オブジェクト」を含む。これらは、それぞれ「ブリッジのサーバ・オブジェクト」301と「サーバのサーバ・オブジェクト」501である。サーバ54は、「サーバのオブジェクト」503（サーバ・オブジェクトと混同してはならない）と呼ぶ少なくとも１つのオブジェクトを含む。これが、クライアントによって要求されたサービスを実際に提供するオブジェクトである。ブリッジ300は、ブリッジ自体の機能を備える「ブリッジのオブジェクト」304と呼ぶオブジェクトを含む。
クライアント53は、「ブリッジのサーバ・オブジェクト」301のローカルにおける代理である「ブリッジのサーバ・プロキシ」401と呼ぶプロキシ・オブジェクトを含む。クライアントは、これがサービスを提供するサーバ内の「サーバのサーバ・オブジェクト」501の代わりをするとみなす。同様に、ブリッジ300は、「サーバのサーバ・オブジェクト」501のローカルにおける代理である「サーバのサーバ・プロキシ」302と呼ぶプロキシ・オブジェクトを含む。前述のように、「サーバ・オブジェクト」とはサーバ内のオブジェクトを管理するオブジェクトである。
クライアント53は、「ブリッジのオブジェクト」304のローカルの代理である「ブリッジのオブジェクト・プロキシ」402と呼ぶプロキシ・オブジェクトも含む。クライアントは、これがサービスを提供するサーバ内の「オブジェクト」503の代わりをするとみなす。同様に、ブリッジ300は、「サーバのオブジェクト」503のローカルにおける代理である「サーバのオブジェクト・プロキシ」303と呼ぶプロキシ・オブジェクトを含む。これらのプロキシは、クライアント53によって開始されるクライアント53とサーバ54との間の通信で使用される。
同期システムでは、クライアント53によって通信が開始される。これらの通信は、クライアント53がブリッジ300と通信することができるようにするクライアント53内にある「ブリッジのオブジェクト・プロキシ」402と、ブリッジ300がサーバ54と通信することができるようにするブリッジ300内にある「サーバのオブジェクト・プロキシ」303とを使用して行われる。
第６図からわかるように、クライアント53、ブリッジ300、およびサーバ54を示す各ブロックの上部にあるオブジェクトとプロキシ・オブジェクトは、クライアントとブリッジによるオブジェクトの作成、破棄、および探索に使用される。クライアント53、ブリッジ300、およびサーバ54を示す各ブロックの下部にあるオブジェクトとプロキシ・オブジェクトは、クライアント53とブリッジ300とサーバ54との間の通信処理に使用される。
第７図に、同期環境において従来技術のクライアントと従来技術のサーバとの間で従来技術のネットワークを介して行われる対話を示す。同期環境では、クライアントがサーバにサービスの提供を求める要求を行うことによってサーバとの通信を開始する。サーバはその要求を処理し、要求の処理からの単純な戻りによってクライアントにその結果を返す。サーバはこの応答を戻すためにクライアントとの通信を開始しない。クライアント53は応答を、サーバ54上で呼び出したメソッドからの戻りパラメータを介して受け取るだけである。
従来技術のシステムでは、第４図を参照しながら前述した同期環境と非同期環境における動作には相違点が２つある。第１の相違は、ステップ310でクライアントがサービスを求める要求を行った後、クライアントはステップ312で他の処理を実行せず、ステップ510でサーバからの応答を待つことである。第２の相違点は、サーバがステップ322でクライアントに対して即時肯定応答を送らないことである。それ以外は、第７図に示す番号付きのステップは、第４図の対応する番号の付いたステップと同じである。
第７図の同期システムにブリッジを挿入した場合に行われる対話を第８図に示す。ステップ310および314でのクライアントの対話は第７図と同じであり、ステップ330、332、および334でのサーバの対話も同じである。要求320と応答324は、クライアントとブリッジとの間と、ブリッジとサーバとの間の対応する応答に分割される。以下に、これらの対話に応答するブリッジの動作について述べる。
ステップ410で、ブリッジはサービス要求320Aを受け入れる。ブリッジはこの要求を処理する代わりに、ステップ412でクライアント名を記録し、別途処理があればそれをステップ414で行う。この別途処理には、非同期環境に関連して第５図を参照しながら前述した別途処理項目の一部または全部が含まれる。ステップ416で、ブリッジはサービス要求をサーバに転送する。サーバが要求を処理している間、ブリッジはステップ610でサーバからの応答を待つ。ステップ332でサーバによる要求の処理が完了すると、サーバはステップ334でブリッジに応答324Aを送る。この応答はステップ430で受け取られ、サーバからクライアントに返されたパラメータのログなどの別途処理があればそれがステップ432でブリッジによって行われる。ブリッジ300は次にステップ434でクライアントに応答324Bを返す。
上述の説明からわかるように、クライアントはブリッジと同期して動作し、したがってクライアントがブリッジから見るインタフェースは、クライアントがサーバと直接通信している場合と同じである。ブリッジはサーバと同期して動作し、したがってサーバがブリッジから見るインタフェースはサーバがクライアントと直接通信している場合と同じである。
ブリッジはサーバのみから導き出される。クライアント53はサーバ54上でメソッドを呼び出し、それと同じメソッド内の戻りパラメータを介して応答を受け取るだけなので、明示的なクライアント・オブジェクトは不要である。別個の通信がサーバ54によって開始されることはない。同期システムの場合のオブジェクト300の定義を例２に示す。
例２−同期ブリッジ・クラスの定義
//同期ブリッジ・クラスを定義する
＃include"server_obj.idl"//サーバ・クラスの宣言
//上記の行ではサーバ・クラスのメソッドと属性が組み込まれる。
interface client_server_obj:client_obj,server_obj
//上記の行では、サーバ・クラスの機能を有するものとして同期ブリッジのインタフェースを定義する
｛
interface bridge_obj:server_obj
ブリッジの挿入
以上、非同期動作と同期動作の両方の場合について、ブリッジの構造と定義を定義した。いずれかの動作方法で使用するようにブリッジを定義したら、定義したブリッジをクライアントとサーバの間に透過的に挿入し、それによってサーバ作成要求が行われた場合にサーバ・オブジェクトの全インタフェースを備えたブリッジが代わりに作成されるようにする必要がある。
クライアント53とサーバはそれぞれのクライアント・クラスとサーバ・クラスのインスタンスを含む。リモート・オブジェクトの検索、リモート・オブジェクトのインスタンスの作成、およびリモート・オブジェクトに対するメソッドの呼出しに使用可能な方法は様々ある。
典型的な従来技術の方法について、第１図に戻って参照しながら以下に説明する。
1.DSOMオブジェクト・マネージャ（SOMD_ObjectMgr）（50にある）が、クライアントが初期設定されたときに作成されているか、または、クライアント53でオブジェクト要求ブローカ50の一部として使用可能なSOMD_Init（）関数を呼び出すことによってこの時点で作成しなければならない。
2.クライアント53と共に使用する適切なオブジェクト・クラスのサーバ54を探し出すために、クライアント53はSOMDObject_Mgrに対してメソッドを実行する。SOMDObject_Mgrは、リモート・サーバ54上の「サーバ・オブジェクト」（52にある）のローカルにおける代理として、クライアント53内にプロキシ・オブジェクト（50にある）を作成する。リモート・サーバ54内には「サーバ・オブジェクト」はまだ存在しないことに留意されたい。
3.クライアント53はサーバ・プロキシ・オブジェクトに対してSomdCreateObj（）メソッド呼出しを出す。このメソッド呼出しにはパラメータとして、クライアントが作成したいターゲット・オブジェクト51のクラスが含まれる。リモート・サーバとの通信が確立され、リモート・サーバ54上で適切なクラスの「サーバ・オブジェクト」（図示せず）が作成される。「サーバ・オブジェクト」（図示せず）が作成されると、その「サーバ・オブジェクト」は要求されたクラスのターゲット・オブジェクト51をサーバ54自体内に作成する。戻りパラメータの一部として、クライアント53に情報が供給され、ターゲット・オブジェクト51のプロキシ・オブジェクト49を作成することができるようにする。
4.これでクライアントはそのローカル・プロキシ・オブジェクト49に対してメソッド呼出しを出すことができるようになり、それらのメソッドがターゲット・オブジェクト51で実行され、その結果がクライアント53に返される。
「サーバ・オブジェクト」のクラスが複数ある場合がある。たとえば、プリント・サービスを提供するために使用されるサーバのクラスと、ファイル記憶サービスのためのクラスと、通信サービスのためのクラスがある場合がある。従来の技術では、これらのクラスは本発明の支援なしに互いに通信する。
以下に、ブリッジをクライアントとサーバの間に透過的に挿入する方法について第３図を参照しなら説明する。
従来技術の各「サーバ・オブジェクト」クラスに対応するブリッジ・クラスを作成する。「サーバのサーバ・オブジェクト」501は従来技術の「サーバ・オブジェクト」クラスのインスタンスである。「ブリッジのサーバ・オブジェクト」301はデフォルト・サーバ・クラスのサブクラスである。上記の例では、プリント・サービスの提供に使用するサーバのブリッジ・クラスと、ファイル記憶サービスに使用されるブリッジ・クラスと、通信サービスに使用されるブリッジ・クラスとがある。
各ブリッジ・サーバ・クラスの定義内の「サーバ・オブジェクト」（サーバ・クラスから継承される）を修正し、ブリッジ・サーバ・クラスのメンバとして「ブリッジのサーバ・オブジェクト」301が作成されるとそれにその修正が組み込まれるようにする。これらの修正はターゲット・オブジェクトを作成するメソッドと、「サーバ・オブジェクト」が受け取ったメソッドをサーバ内のターゲット・オブジェクトにディスパッチするメソッドに加えられる。
「サーバのオブジェクト」503（ターゲット・オブジェクト）を作成する修正されたメソッドは、サーバ内に「サーバのオブジェクト」503を作成することを求めるクライアントからの要求を受け取って、「ブリッジのオブジェクト」304をその場所に作成する。
「ブリッジのサーバ・オブジェクト」301が受け取ったメソッドをサーバ内の「サーバのオブジェクト」503（ターゲット・オブジェクト）にディスパッチする修正されたメソッドは、単にクライアント名を記録するだけで（第５図のステップ412）、別途処理（第５図のステップ414）を行い、メソッドをオブジェクトにディスパッチする元のディスパッチ・メソッドを呼び出す。
前述の実施例の適用
第９図を参照すると、前述の本発明のブリッジ300を使用して、１つのクライアント53が複数のサーバ54A〜54Dにサービスを要求することができる。クライアント53は、要求が異なるサーバ54Aから54Dで実行されていることがわからない。ブリッジ300は、要求を複数のサーバ54A〜54Dのうちのどのサーバに宛てて送るべきかを決定する。
クライアント53でもサーバ54A〜54Dでの追加のプログラミングを必要とせずに、複数のサーバ54A〜54Dのそれぞれの間における作業負荷分散を実現することができる。作業負荷分散を実現する実施例では、ブリッジ300は「ラウンドロビン」アルゴリズムを使用する。このアルゴリズムでは、新しいクライアント要求が出されるたびに次のサーバ54A〜54Dに順に送られる。作業負荷分散を実現する他の実施例では、各サーバ54A〜54Dから入手した応答時間を測定し、当業者に周知のより高度なアルゴリズムを使用して各サーバ54A〜54D間で作業負荷を分散させる。この２つの実施例は両方とも、サーバ54A〜54Dとクライアント53のいずれでもコードに修正をまったく加えずに実現することができる。
第10図に、従来技術の方式で一緒に接続された３個のサーバ54A〜54Cに接続された３個のクライアント53A〜53Cを示す。各クライアント53A〜53Cが各サーバ54A〜54Cへの接続901〜909を有する。
第11図を参照すると、前述の本発明のブリッジ300を使用することによって、複数のサーバ54A〜54Cに対してサービスを要求する複数のクライアント54A〜53Cが存在することが可能であり、その際、異なるサーバ54A〜54C上で要求が実行されていることやサーバ54A〜54Cが他のクライアント53A〜53Cのための要求を処理していることは、クライアント53A〜53Cのいずれにもわからない。ブリッジ300は、各クライアント53A〜54Cからの各要求を、複数のサーバ54A〜54Cのうちのどのサーバに宛てて送るかを決定する。
すべての要求をブリッジ300を介して経路指定することによって、ネットワーク内の接続が削減される。より一般的な態様では、ｎ個のクライアント53とｍ個のサーバ54を有するシステムにおいて、接続数がｎ＊ｍ個からｎ＋ｍ個に減少する。
Claims (5)
- 非同期的に動作するクライアント（53）およびサーバ（54）を含む分散オブジェクト指向コンピュータ・システムにおいて、前記クライアントと前記サーバとの間で使用するブリッジ（300）であって、
前記クライアントおよび前記サーバから継承によって導き出され；
サーバのインタフェース（303、503）に対応するクライアント・アドレス空間内にあるプロキシ・オブジェクト（402）とのインタフェース（402、304）と、クライアント・アドレス空間内にあるプロキシ・オブジェクト（402）のインタフェース（402、304）に対応するサーバとのインタフェース（303、503）と、クライアントのインタフェースに対応するサーバ・アドレス空間内にあるプロキシ・オブジェクト（502）とのインタフェース（304、502）と、サーバ・アドレス空間内にあるプロキシ・オブジェクト（502）のインタフェース（304、502）に対応するクライアントとのインタフェース（305、403）とを有し；
クライアント・アドレス空間内にあるプロキシ・オブジェクトとサーバとの間に透過的に挿入され；
前記サーバから継承したメソッドを上書き変更して要求を行うクライアントの名前を記録し、要求を前記サーバに転送し；
前記クライアントから継承したメソッドを上書き変更して前記クライアントに応答パラメータを転送するブリッジ。 - 同期的に動作するクライアント（53）およびサーバ（54）を含む分散オブジェクト指向コンピュータ・システムにおいて、前記クライアントと前記サーバとの間で使用するブリッジ（300）であって、
サーバのインタフェース（303、503）に対応するクライアント・アドレス空間内にあるプロキシ・オブジェクト（402）とのインタフェース（402、304）と、クライアント・アドレス空間内にあるプロキシ・オブジェクト（402）のインタフェース（402、304）に対応するサーバとのインタフェース（303、503）とを有し；
クライアント・アドレス空間内にあるプロキシ・オブジェクトとサーバとの間に透過的に挿入され；
前記サーバから継承したメソッドを上書き変更して前記サーバ上の前記メソッドを呼出し、前記クライアントに応答パラメータを返すブリッジ。 - 非同期的に動作するクライアント（53）およびサーバ（54）を含む分散クライアント−サーバコンピュータ・システムを動作させる方法であって、
前記クライアントと前記サーバとの間で使用するブリッジ（300）のために、前記サーバのインタフェース（303、503）に対応する、クライアント・アドレス空間内にあるプロキシ・オブジェクト（402）とのインタフェース（402、304）を前記サーバから継承によって定義するステップと、
前記ブリッジのために、クライアント・アドレス空間内にあるプロキシ・オブジェクト（402）のインタフェース（402、304）に対応する、前記サーバとのインタフェース（303、503）を前記クライアントから継承によって定義するステップと、
前記ブリッジのために、クライアントのインタフェースに対応するサーバ・アドレス空間内にあるプロキシ・オブジェクト（502）とのインタフェース（304、502）を前記クライアントから継承によって定義するステップと、
前記ブリッジのために、サーバ・アドレス空間内にあるプロキシ・オブジェクト（502）のインタフェース（304、502）に対応するクライアントとのインタフェース（305、403）を前記サーバから継承によって定義するステップと、
前記ブリッジをクライアント・アドレス空間内にある前記プロキシ・オブジェクトと前記サーバの間に透過的に挿入するステップと、
前記サーバから継承したメソッドを上書き変更して、要求を行うクライアントの名前を記録し、前記サーバに要求を転送するステップと、
前記クライアントから継承したメソッドを上書き変更して前記クライアントに応答パラメータを転送するステップとを含む方法。 - 同期的に動作するクライアント（53）およびサーバ（54）を含む分散クライアント−サーバコンピュータ・システムを動作させる方法であって、
クライアント・アドレス空間内にあるプロキシ・オブジェクト（402）とのインタフェース（402、304）がサーバのインタフェース（303、503）に対応し、サーバとのインタフェース（303、503）がクライアント・アドレス空間内にあるプロキシ・オブジェクト（402）のインタフェース（402、304）に対応するように、ブリッジ（300）のために、前記サーバからの継承によってインタフェースを定義するステップと、
前記ブリッジをクライアント・アドレス空間内にある前記プロキシ・オブジェクトと前記サーバの間に透過的に挿入するステップと、
前記サーバから継承したメソッドを上書き変更して、前記サーバ上で前記メソッドを呼出し、前記クライアントに応答パラメータを返すステップとを含む方法。 - １つまたは複数のサーバ（54）と、１つまたは複数のクライアント（53）と、前記請求項１または２に記載のブリッジ（300）とを含む分散オブジェクト指向コンピュータ・システム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9518871A GB2305270A (en) | 1995-09-15 | 1995-09-15 | Bridge for a client-server environment |
| GB9518871.0 | 1995-09-15 | ||
| PCT/GB1996/000247 WO1997010546A1 (en) | 1995-09-15 | 1996-02-07 | Bridge for a client-server environment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10511794A JPH10511794A (ja) | 1998-11-10 |
| JP3605416B2 true JP3605416B2 (ja) | 2004-12-22 |
Family
ID=10780751
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP51173197A Expired - Fee Related JP3605416B2 (ja) | 1995-09-15 | 1996-02-07 | クライアント−サーバ環境用ブリッジ |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5862328A (ja) |
| EP (1) | EP0850446B1 (ja) |
| JP (1) | JP3605416B2 (ja) |
| DE (1) | DE69606184T2 (ja) |
| GB (1) | GB2305270A (ja) |
| WO (1) | WO1997010546A1 (ja) |
Families Citing this family (59)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6052718A (en) * | 1997-01-07 | 2000-04-18 | Sightpath, Inc | Replica routing |
| NZ337772A (en) | 1997-03-12 | 2001-09-28 | Nomadix Inc | Nomadic translator or router |
| US6157960A (en) * | 1997-05-07 | 2000-12-05 | International Business Machines Corporation | Technique for programmatically creating distributed object programs |
| CA2204971A1 (en) * | 1997-05-09 | 1998-11-09 | Michael Cheng | Uniform access to and interchange between objects employing a plurality of access methods |
| EP0996906B1 (de) * | 1997-07-25 | 2001-10-24 | Siemens Aktiengesellschaft | Verfahren zur synchronisierten darstellung von netz-inhalten |
| EP0911727A3 (en) * | 1997-10-24 | 2002-08-14 | Sun Microsystems, Inc. | A method, apparatus, system and program product for a client-server environment |
| GB9725742D0 (en) * | 1997-12-04 | 1998-02-04 | Hewlett Packard Co | Object gateway |
| US6633922B1 (en) * | 1997-12-15 | 2003-10-14 | International Business Machines Corporation | Object access mechanism that dynamically switches between multiple distributed access models |
| US6003083A (en) * | 1998-02-19 | 1999-12-14 | International Business Machines Corporation | Workload management amongst server objects in a client/server network with distributed objects |
| JPH11338720A (ja) * | 1998-05-28 | 1999-12-10 | Nec Software Ltd | クライアントサーバ間通信制御方法及び装置及び記録媒体 |
| US6490623B1 (en) * | 1998-08-24 | 2002-12-03 | International Business Machines Corporation | System, method and computer readable code for encapsulating system, language and device independent communications socket functionality in a lightweight uniform communications object model |
| FR2784479B1 (fr) * | 1998-10-09 | 2000-11-17 | Bull Cp8 | Protocole d'echange interne de donnees entre applications d'un objet portatif multi-applications et objet portatif multi-applications correspondant |
| US20040154027A1 (en) * | 1998-10-14 | 2004-08-05 | Jean-Jacques Vandewalle | Method and means for managing communications between local and remote objects in an object oriented client server system in which a client application invokes a local object as a proxy for a remote object on the server |
| JP2003527763A (ja) * | 1998-10-16 | 2003-09-16 | シルバーストリーム・ソフトウェア・インコーポレーテッド | 分散オブジェクト・システム用の接続集線装置 |
| US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
| US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
| US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
| JP4745478B2 (ja) | 1999-01-29 | 2011-08-10 | キヤノン株式会社 | ネットワークプリントシステム及び情報処理装置及びその制御方法 |
| DE19910345A1 (de) * | 1999-03-09 | 2000-09-21 | Siemens Ag | Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Systems |
| AU3321600A (en) * | 1999-03-22 | 2000-10-09 | Interlink Computer Communications Ltd. | Automatic interface generation for an enterprise resource |
| US6370436B1 (en) * | 1999-03-26 | 2002-04-09 | Emware, Inc. | Distributed objects for a computer system |
| US6829642B1 (en) * | 1999-07-01 | 2004-12-07 | International Business Machines Corporation | Method and system for automatically and optimally selecting a TN3270 server in an internet protocol network |
| JP3461146B2 (ja) * | 1999-09-28 | 2003-10-27 | 株式会社ジャストシステム | 時間認証システム、ネットワークシステム、サーバ装置及びクライアント装置、並びに記録媒体 |
| WO2001031885A2 (en) | 1999-10-22 | 2001-05-03 | Nomadix, Inc. | Gateway device having an xml interface and associated method |
| EP1117035A1 (en) * | 2000-01-14 | 2001-07-18 | Sun Microsystems, Inc. | Runtime environment component services |
| EP1122644A1 (en) * | 2000-01-14 | 2001-08-08 | Sun Microsystems, Inc. | A method and system for dynamically dispatching function calls from a first execution environment to a second execution environment |
| EP1117220A1 (en) * | 2000-01-14 | 2001-07-18 | Sun Microsystems, Inc. | Method and system for protocol conversion |
| EP1117033A1 (en) * | 2000-01-14 | 2001-07-18 | Sun Microsystems, Inc. | Dynamic dispatch function |
| US20020004856A1 (en) * | 2000-03-29 | 2002-01-10 | Krishna Sudarshan | System and method of generating and using proxy beans |
| US7162542B2 (en) * | 2000-04-13 | 2007-01-09 | Intel Corporation | Cascading network apparatus for scalability |
| US6732175B1 (en) | 2000-04-13 | 2004-05-04 | Intel Corporation | Network apparatus for switching based on content of application data |
| US7146422B1 (en) | 2000-05-01 | 2006-12-05 | Intel Corporation | Method and apparatus for validating documents based on a validation template |
| EP1168752A1 (en) * | 2000-06-23 | 2002-01-02 | Matra Nortel Communications | Access control in client-sever systems |
| WO2002010917A1 (en) | 2000-07-27 | 2002-02-07 | Bea Systems, Inc. | System and method for concentration and load-balancing of requests |
| US7003481B2 (en) * | 2000-08-25 | 2006-02-21 | Flatrock Ii, Inc. | Method and apparatus for providing network dependent application services |
| US7032002B1 (en) * | 2000-09-06 | 2006-04-18 | Xanboo, Inc. | Service broker for processing data from a data network |
| US6950866B1 (en) * | 2000-12-19 | 2005-09-27 | Novell, Inc. | XML-based integrated services parsing |
| US20020103850A1 (en) * | 2001-01-31 | 2002-08-01 | Moyer Stanley L. | System and method for out-sourcing the functionality of session initiation protocol (SIP) user agents to proxies |
| JP2002237815A (ja) * | 2001-02-08 | 2002-08-23 | Pioneer Electronic Corp | ネットワークシステム、ネットワーク運用方法、仲介モジュール及び端末装置並びに情報記録媒体及びプログラム |
| US20020112013A1 (en) * | 2001-02-12 | 2002-08-15 | Fiona Walsh | Method for generating commercial email communications while preserving Internet privacy |
| US7958024B2 (en) | 2001-03-15 | 2011-06-07 | Versata Development Group, Inc. | Method and apparatus for processing sales transaction data |
| US7908304B2 (en) * | 2001-03-15 | 2011-03-15 | Versata Development Group, Inc. | Method and system for managing distributor information |
| US7925513B2 (en) * | 2001-03-15 | 2011-04-12 | Versata Development Group, Inc. | Framework for processing sales transaction data |
| US6915520B2 (en) * | 2001-04-06 | 2005-07-05 | Hewlett-Packard Development Company, L.P. | Java C++ proxy objects |
| US20020169863A1 (en) * | 2001-05-08 | 2002-11-14 | Robert Beckwith | Multi-client to multi-server simulation environment control system (JULEP) |
| US7904326B2 (en) | 2001-06-29 | 2011-03-08 | Versata Development Group, Inc. | Method and apparatus for performing collective validation of credential information |
| US7003570B2 (en) * | 2001-10-05 | 2006-02-21 | Bea Systems, Inc. | System for integrating java servlets with asynchronous messages |
| US7065541B2 (en) * | 2001-10-10 | 2006-06-20 | International Business Machines Corporation | Database migration |
| US6757899B2 (en) * | 2001-10-11 | 2004-06-29 | Harris Corporation | Dynamic CORBA gateway for CORBA and non-CORBA clients and services |
| US7096249B2 (en) * | 2002-03-29 | 2006-08-22 | Intel Corporation | Method and system for distributing applications |
| FR2852753B1 (fr) * | 2003-03-18 | 2005-06-03 | Twd Ind | Systeme de transmission de donnees client/serveur securise |
| US7424721B2 (en) * | 2003-05-19 | 2008-09-09 | Sun Microsystems, Inc. | Inter-object communication interface bridge |
| US7454758B2 (en) * | 2004-02-05 | 2008-11-18 | Aol Llc, A Delaware Limited Liability Company | Inter-process communication on a computer |
| US7444536B1 (en) | 2004-04-16 | 2008-10-28 | Sun Microsystems, Inc. | RMI-IIOP request failover mechanism |
| JP5025116B2 (ja) | 2005-10-25 | 2012-09-12 | キヤノン株式会社 | 情報処理装置及びその制御方法ならびにプログラム |
| DE112008002634T5 (de) * | 2007-09-27 | 2011-01-13 | Hilton, Ronald N., Holladay | Gerät, System und Verfahren zur systemübergreifenden Proxy-basierten Aufgabenentlastung |
| US11263286B2 (en) | 2019-12-23 | 2022-03-01 | Amadeus S.A.S. | System and method for legacy-based access to non-legacy data |
| EP3842959A1 (en) * | 2019-12-23 | 2021-06-30 | Amadeus S.A.S. | System and method for legacy-based access to non-legacy data |
| FR3105476B1 (fr) * | 2019-12-23 | 2022-12-09 | Amadeus | Système et procédé pour un accès basé sur un environnement d’exploitation hérité à des données non héritées |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69228621T2 (de) * | 1991-02-25 | 1999-07-22 | Hewlett-Packard Co., Palo Alto, Calif. | Objektorientiertes verteiltes Rechnersystem |
| JPH0778775B2 (ja) * | 1991-06-12 | 1995-08-23 | インターナショナル・ビジネス・マシーンズ・コーポレイション | アプリケーション・プログラム間における情報交換システム及び方法 |
| JP3055970B2 (ja) * | 1991-06-20 | 2000-06-26 | 富士通株式会社 | オブジェクト指向言語間インタフェース実現方法および装置 |
| DE69232164T2 (de) * | 1991-08-22 | 2002-07-18 | Sun Microsystems, Inc. | Netzwerkvideoanbietergerät und-verfahren |
| JPH05113959A (ja) * | 1991-10-23 | 1993-05-07 | Hitachi Ltd | リモ−トプロシジヤコ−ル要求代行処理方法および装置 |
| US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
| WO1994011810A1 (en) * | 1992-11-13 | 1994-05-26 | Microsoft Corporation | A method and system for marshalling interface pointers for remote procedure calls |
| US5452459A (en) * | 1993-01-08 | 1995-09-19 | Digital Equipment Corporation | Method and apparatus for allocating server access in a distributed computing environment |
| JPH06301618A (ja) * | 1993-04-15 | 1994-10-28 | Matsushita Electric Ind Co Ltd | 遠隔手続き呼び出し方法 |
| US6226690B1 (en) * | 1993-06-14 | 2001-05-01 | International Business Machines Corporation | Method and apparatus for utilizing proxy objects to communicate with target objects |
| US5491800A (en) * | 1993-12-20 | 1996-02-13 | Taligent, Inc. | Object-oriented remote procedure call networking system |
| JPH07225685A (ja) * | 1994-02-09 | 1995-08-22 | Hitachi Ltd | 分散オブジェクト指向システム構築方法 |
-
1995
- 1995-09-15 GB GB9518871A patent/GB2305270A/en not_active Withdrawn
-
1996
- 1996-02-07 EP EP96901892A patent/EP0850446B1/en not_active Expired - Lifetime
- 1996-02-07 WO PCT/GB1996/000247 patent/WO1997010546A1/en active IP Right Grant
- 1996-02-07 DE DE69606184T patent/DE69606184T2/de not_active Expired - Fee Related
- 1996-02-07 JP JP51173197A patent/JP3605416B2/ja not_active Expired - Fee Related
- 1996-09-06 US US08/709,087 patent/US5862328A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| GB9518871D0 (en) | 1995-11-15 |
| EP0850446A1 (en) | 1998-07-01 |
| DE69606184T2 (de) | 2000-07-13 |
| WO1997010546A1 (en) | 1997-03-20 |
| EP0850446B1 (en) | 2000-01-12 |
| DE69606184D1 (de) | 2000-02-17 |
| GB2305270A (en) | 1997-04-02 |
| US5862328A (en) | 1999-01-19 |
| JPH10511794A (ja) | 1998-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3605416B2 (ja) | クライアント−サーバ環境用ブリッジ | |
| Vinoski | CORBA: Integrating diverse applications within distributed heterogeneous environments | |
| Notkin et al. | Interconnecting heterogeneous computer systems | |
| US20020078255A1 (en) | Pluggable instantiable distributed objects | |
| Grimm et al. | System support for pervasive applications | |
| US6230160B1 (en) | Creating proxies for distributed beans and event objects | |
| US6487607B1 (en) | Methods and apparatus for remote method invocation | |
| US6263498B1 (en) | Method and apparatus for enabling server side distributed object modification | |
| US20020145924A1 (en) | System, method, and article of manufacture for using a replaceable component to select a replaceable quality of service capable network communication channel component | |
| US20030055862A1 (en) | Methods, systems, and articles of manufacture for managing systems using operation objects | |
| Bever et al. | Distributed systems, OSF DCE, and beyond | |
| Valetto et al. | Enveloping sophisticated tools into computer-aided software engineering environments | |
| Daniel et al. | Active COM: An inter-working framework for CORBA and DCOM | |
| Condie | Distributed Computing, Tomorrow's Panacea—an Introduction to Current Technology | |
| Shen | A CORBA facility for network simulation | |
| Kacsuk et al. | Network-based distributed computing (metacomputing) | |
| Leung et al. | DJM: a global distributed virtual machine on the Internet | |
| Depledge et al. | An open, distributable, three-tier client-server architecture with transaction semantics | |
| Froidevaux et al. | The mainframe as a high-available, highly scalable CORBA platform | |
| Truong et al. | Distributed Shell over Peer-to-Peer Networks. | |
| Shen | Discrete-event simulation on the Internet and the Web | |
| Díaz et al. | Designing distributed software with RT-CORBA and SDL | |
| Janson et al. | CORBA vs. DCOM | |
| Li | A Model of Real-time QoS | |
| Benns et al. | What's in the Middle? |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040806 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041004 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071008 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081008 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |