(57)【特許請求の範囲】
【請求項１】
複数のコンピュータ・システム・ノードを有するコンピュータ・システム・ネットワークにおけるコンピュータ・システム・ノード上でサーバ・コードの実行を指定するための方法であって、
クライアント・プログラムをクライアント・ノードで実行し、
クライアント・プログラムが、サーバ・コードの実行をリクエストし、
クライアント・サービス制御マネージャが、サーバ・コードを実行するためのリクエストに応じて、前記サーバ・コードが実行されるノードを決定し、および
クライアント・プログラムが、前記決定されたノードで、前記サーバ・コードの実行をリクエストする方法において、
前記サーバ・コードが実行されるノードを決定するステップが、
クライアント・プログラムからリクエストされるクライアント・ロケーション・コンテキストであって、前記クライアント・ロケーション・コンテキストを、クライアント・ノード、パーシステント・オブジェクト・データが配置されているノード、又は特定の名前をもつノードに選択的に設定して、前記サーバ・コードを実行するためのノードを指定するクライアント・ロケーション・コンテキストを決定し、
サーバ・プログラムから特定される一つ以上のサーバ・ロケーション・コンテキストであって、前記サーバ・ロケーション・コンテキストを、クライアント・ノード、クライアント・プログラムによって名前を付けられたノード、又はパーシステント・オブジェクト・データが配置されているノードの一つに設定して、前記サーバ・コードを実行することができるノードを指定する一つ以上のサーバ・ロケーション・コンテキストを決定し、
ネットワーク・サービス・コードが、前記クライアント・ロケーション・コンテキストおよび一つ以上の前記サーバ・ロケーション・コンテキストを評価して、前記サーバ・コードが実行されるノードを、前記クライアント・ノード、クライアントによって名前が付けられたノードおよびパーシステント・オブジェクト・データが記憶されるノードを含む複数のノードの内から決定することを特徴とするサブステップからなり、前記クライアント・ロケーション・コンテキストが、特定の名前をもつノードであると決定され且つ前記サーバ・ロケーション・コンテキストがクライアント・プログラムによって名前を付けられたノードであると決定される場合、サーバ・コードは特定の名前をもつノードで実行される方法。
【請求項２】
前記クライアント・ロケーション・コンテキストが、前記クライアント・ノード、パーシステント・オブジェクト・データが記憶されるノード、または名前をもつノードの内の選択された一つを指定する請求項１記載の方法。
【請求項３】
前記サーバ・ロケーション・コンテキストが、前記クライアント・ノード、パーシステント・オブジェクト・データが記憶されるノード、または名前をもつことが可能なノードを指定する請求項１に記載の方法。
【請求項４】
前記サーバ・コードが、セキュリティ・コンテキストを有しており、前記コンピュータ・システムが、パーシステント・レジストリを含み、前記サーバ・コード用のセキュリティ・コンテキスト仕様をパーシステント・レジストリ内に配置するステップを更に含む請求項１記載の方法。
【請求項５】
サーバ・プログラムが、前記サーバ・コードを実行することができる一つ以上のサーバ・ロケーション・コンテキストを特定するステップを更に有し、この特定するステップが、一つ以上のサーバ・ロケーション・コンテキスト仕様をパーシステント・レジストリ内に配置することを含む請求項１記載の方法。
【請求項６】
前記クライアント・ノードがクライアント・サービス制御マネージャを含み、
サーバ・ノードが、前記クライアント・サービス制御マネージャと通信するサーバ・サービス制御マネージャを含み、
前記サーバ・コードを前記決定されたノードで実行することをリクエストする前記ステップが、前記クライアント・サービス制御マネージャの制御の下で達成され、かつサーバ・サービス制御マネージャによってリクエストされ、および
前記サーバ・コードが実行されるノードを決定する前記ステップが、前記クライアント・サービス制御マネージャの制御の下で達成される請求項１記載の方法。
【請求項７】
前記クライアント・ロケーション・コンテキストおよび一つ以上のサーバ・ロケーション・コンテキストが、前記サーバ・コードが実行されるノードを決定する評価を行った後に、前記サーバ・コードが前記決定されたノードに位置していない時に、前記決定されたノードに前記サーバ・コードをダウンローディングするステップを更に含む請求項１記載の方法。
【請求項８】
オブジェクト・サーバ・コードの実行を介して、参照されたオブジェクトを起動するためのコンピュータ・システム・ノードを、前記参照されたオブジェクトの動作を実現するのに必要な時に、特定し、前記オブジェクト・サーバ・コードが前記オブジェクトの動作を実現し、ネットワークが、複数のコンピュータ・システム・ノードを有しているコンピュータ・システム・ネットワークにおける方法であり、この方法が、
クライアント・ノードでクライアント・プログラムを実行し、
このクライアント・プログラムの実行中に、オブジェクトを参照し、
前記参照されたオブジェクトの動作を実現するのに必要な時に、前記オブジェクト・サーバ・コードの実行を介して、前記参照されたオブジェクトを起動することをネットワーク・サービスがリクエストし、
前記参照されたオブジェクトを起動するための前記リクエストに応答して、前記参照されたオブジェクトの動作を実現するのに必要な時に、前記オブジェクト・サーバ・コードが実行されるノードをクライアント・サービス制御マネージャが決定し、
そして、
前記参照されたオブジェクトの動作を実現するのに必要な時に、前記決定されたノード上での前記サーバ・コードの実行を介して、前記決定されたノード上での前記参照されたオブジェクトの起動をクライアント・サービス制御マネージャがリクエストするステップから成る方法において、
前記参照されたオブジェクトの動作を実現するのに必要な時に、前記オブジェクト・サーバ・コードが実行されるノードを決定する前記ステップが、
クライアント・プログラムからリクエストされる、前記参照されたオブジェクト用のクライアント・ロケーション・コンテキストであり、前記クライアント・ロケーション・コンテキストが、クライアント・ノードと同じノードでの実行を指定するローカル・ロケーション・コンテキスト、及びクライアント・ノードと異なるノードでの実行を指定するリモート・ロケーション・コンテキストの内の一方からなり、かつ前記参照されたオブジェクトの動作を実現するのに必要な時に、オブジェクト・サーバ・コードを実行するノードを指定する前記クライアント・ロケーション・コンテキストを決定し、
サーバ・プログラムから特定される、前記オブジェクト・サーバ・コード用の一つ以上のサーバ・ロケーション・コンテキストであり、前記サーバ・ロケーション・コンテキストが、クライアント・ノードと同じノードでの実行を指定するローカル・ロケーション・コンテキスト、及びクライアント・ノードと異なるノードでの実行を指定するリモート・ロケーション・コンテキストの内の一方からなり、かつ前記オブジェクト・サーバ・コードを実行することができるノードを指定する前記サーバ・ロケーション・コンテキストを決定し、
そして
ネットワーク・サービス・コードは、前記参照されたオブジェクトの動作を実現するのに必要な時に、前記クライアント・ロケーション・コンテキストおよび一つ以上の前記サーバ・ロケーション・コンテキストを評価して、前記オブジェクト・サーバ・コードが実行されるノードを、前記クライアント・ノード、名前をもつノードおよびパーシステント・オブジェクト・データが記憶されるノードを含む複数のノードの内から決定する、サブステップからなる方法。
【請求項９】
前記参照されたオブジェクトの動作を実現するのに必要な時に、前記オブジェクト・サーバ・コードが実行されるノードを決定するために、前記クライアント・ロケーション・コンテキストおよび一つ以上のリモート・ロケーション・コンテキストを評価した後に、前記オブジェクト・サーバ・コードが前記決定されたノードに位置していない時に、前記オブジェクト・サーバ・コードを前記決定されたノードにダウンロードする請求項８記載の方法。
【発明の詳細な説明】
【０００１】
【技術分野】
この発明は、コンピュータ・ネットワークにおいて、コードをリモート（遠隔的）に実行するコンピュータ方法およびシステムに関する。具体的には、この発明は、ネットワークを事前に構成することなく、また、特定の位置（ロケーション）のクライアントの知識がなくてもコードをリモートに実行するための方法およびシステムに関する。
【０００２】
【発明の背景】
コンピュータ・ネットワーク環境下においては、プログラム・コード（単に「コード」ともいう）が実行される場所のロケーションの重要性が増加している。コードが、そのコードによって操作されるデータを記憶しているノードと同じノードで実行される場合に、コードはより効率的に実行される。従来のシステムにおいて、クライアント・プログラムが、ある特定のネットワーク・ノード上のサーバ・プログラムを実行したいときに、使用できる手法がいくつかある。一つの手法は、システム・アドミニストレータが、所望のネットワーク・ノードでサーバ・プログラムの実行を開始するものである。もう一つの手法は、システム・アドミニストレータまたはクライアント・プログラムが、ネットワーク・メッセージを所望のノードにリモートに送信し、サーバ・プログラムの実行を開始させるものである。他の手法は、デーモン・プロセスが、識別されたメッセージ・アドレスを有する所望のネットワーク・ノードで開始される。後に、クライアント・プログラムがこのメッセージ・アドレスにメッセージを直接または間接に送信すると、サーバ・プログラムが実際に実行される。このメッセージは、トリガのような役割を果たす。これらの従来の手法では、ネットワーク上のプログラムまたはユーザは、サーバ・プログラムを実行できる場所およびサーバ・プログラムの実行を開始する方法を予め知っている。
【０００３】
この発明は、以下に示すように、オブジェクト指向型のプログラミング手法を用いている。したがって、周知のオブジェクト指向型プログラミング手法の手短な概要について述べる。オブジェクト指向型プログラミング言語の２つの特徴は、データのカプセル化およびデータ型（データ・タイプ）の継承のサポートである。データのカプセル化は、関数およびデータの結合（束縛、バインド）と呼ばれる。継承は、あるデータ型を他のデータ型で宣言できることをいう。
【０００４】
プログラミング言語Ｃ++において、オブジェクト指向型の手法は、クラスを使用することによりサポートされている。クラスは、ユーザが定義する（ユーザ定義の）型（タイプ）である。クラスの宣言では、そのクラスのデータ・メンバおよび関数メンバが記述される。例えば、次の宣言は、CIRCLEという名前のクラスのデータ・メンバおよび関数メンバを定義している。
【０００５】
0003868013.tif 000002
【０００６】
変数ｘとｙは円の中心の位置を示すもので、変数radiusは円の半径を示すものである。これらの変数は、クラスCIRCLEのデータ・メンバと呼ばれる。関数drawは、指定された位置に指定された半径の円を描くユーザ定義の関数である。関数drawは、クラスCIRCLEの関数メンバと呼ばれる。クラスのデータ・メンバおよび関数メンバは、その関数がそのクラスのインスタンスに処理を施すという点において、ともに結び付けられている。クラスのインスタンスは、クラスのオブジェクトとも呼ばれる。
【０００７】
Ｃ++の構文において、次の文（ステートメント）は、クラスCIRCLE型のオブジェクトａおよびｂを宣言するものである。
【０００８】
CIRCLE  ａ，ｂ；
【０００９】
この宣言により、オブジェクトａおよびｂのメモリが割り当てられる。次の文は、オブジェクトａおよびｂのデータ・メンバにデータを割り当てるものである。
【００１０】
a.x   = 2;
a.y   = 2;
a.radius = 1;
b.x   = 4;
b.y   = 5;
b.radius = 2;
【００１１】
次の文は、オブジェクトａおよびｂによって定められた円を描くために使用される。
【００１２】
a.draw();
b.draw();
【００１３】
派生クラス（derived class ）は、その基底クラス（base class）の特徴（データ・メンバおよび関数メンバ）を継承するクラスである。例えば、次の派生クラスCIRCLE-FILL は、基底クラスCIRCLEの特徴を継承する。
【００１４】
0003868013.tif 000003
【００１５】
この宣言は、クラスCIRCLE-FILL が、その宣言に導入されたデータ・メンバおよび関数メンバ（すなわち、データ・メンバpattern および関数メンバfill）に加えて、クラスCIRCLEの全てのデータ・メンバおよび関数メンバを含むことを示している。この例では、クラスCIRCLE-FILL は、データ・メンバｘ、ｙ、radiusおよびpattern 、ならびに関数メンバdrawおよびfillを有する。クラスCIRCLE-FILL は、クラスCIRCLEの特徴を「継承する」（インヘリット：inherit ）と呼ばれる。他のクラスの特徴を継承するクラスが、派生クラス（例えば、CIRCLE-FILL ）である。他のクラスの特徴を継承しないクラスが、プライマリ（ルート）・クラス（例えば、CIRCLE）である。その特徴が他のクラスによって継承されるクラスが、基底クラスである（例えば、CIRCLEはCIRCLE-FILL の基底クラスである）。派生クラスは、複数のクラスの特徴を継承することもできる。すなわち、派生クラスは、複数の基底クラスをもつことができる。これは、多重継承と呼ばれる。
【００１６】
クラスは、その関数メンバが仮想的であるかどうかを指定することもできる。関数メンバが仮想的であることを宣言することは、派生クラスにおいて、同じ名前と型の関数によってその関数を上書き（オーバライド）できることを意味する。以下の例では、関数drawが、クラスCIRCLEおよびCIRCLE-FILL において仮想的に宣言されている。
【００１７】
0003868013.tif 000004
【００１８】
仮想関数が、インプリメンテーション（実現または実現したもの）を提供することなく宣言されると、その関数は純（ピュアな）仮想関数と呼ばれる。純仮想関数は、純指定子（スペシファイア：specifier ）“＝０”で宣言される仮想関数である。クラスが純仮想関数を指定すると、任意の派生クラスは、その関数メンバを呼び出す前に、その仮想関数メンバのインプリメンテーションを指定する必要がある。
【００１９】
オブジェクトにアクセスするために、Ｃ++言語には、ポインタ型のデータが用意されている。ポインタは、メモリにおけるオブジェクトのアドレス値を保持する。ポインタによって、オブジェクトは参照される。次の文は、クラスCIRCLE型のオブジェクトへのポインタである変数c-ptr の宣言を示している。変数c-ptr は、オブジェクトｃのアドレスを保持するようにセットされる。
【００２０】
CIRCLE  *c-ptr;
c-ptr = &c;
【００２１】
次の文は、オブジェクトａがクラスCIRCLE型のオブジェクトであることを、オブジェクトｂがクラスCIRCLE-FILL 型のオブジェクトであることをそれぞれ宣言している。
【００２２】
CIRCLE  a;
CIRCLE-FILL b;
【００２３】
次の文は、クラスCIRCLEで定義された関数drawを参照するものである。
【００２４】
a.draw();
【００２５】
以下の文は、クラスCIRCLE-FILL で定義された関数drawを参照するものである。
【００２６】
b.draw();
【００２７】
図１は、オブジェクトを表すために使用される典型的なデータ構造体を示すブロック図である。オブジェクトは、インスタンス・データ（データ・メンバ）とメンバ関数とから合成（混合）される。これらは、オブジェクトの振る舞いを実現する。オブジェクトを表現するために使用されるデータ構造体は、インスタンス・データ構造体101 、仮想関数テーブル102 、ならびに関数メンバ103 、104 および105 から構成されている。インスタンス・データ構造体101 は、仮想関数テーブル102 へのポインタおよびデータ・メンバを含んでいる。仮想関数テーブル102 は、そのオブジェクト用に定義された各仮想関数メンバ用のエントリを含んでいる。各エントリは、対応する関数メンバを実現するコードへの参照を含んでいる。このサンプルのレイアウトは、米国特許第5,297,284号「オブジェクト指向型プログラミング言語用仮想関数および仮想ベースクラスの実現およびポインタ設定方法」（A Method for Implementing Virtual Functions and Virtual Base Classes and Setting a This Pointer for an Object Oriented Programming Language ）で説明されたモデルと同じである。以下では、オブジェクトが、Ｃ++プログラミング言語によって定義されるクラスのインスタンスとして示される。もちろん、オブジェクトを他のプログラミング言語を用いて定義することは、この技術分野の専門家ならば容易に理解できるであろう。
【００２８】
オブジェクト指向型の手法を用いる利点として、データおよびコードの共有が容易になるということが挙げられる。特に、オブジェクト指向型手法は、混合（コンパウンド：compound）ドキュメント（コンパウンド・ドキュメント）の作成を容易にする。混合ドキュメントは、様々なコンピュータ・プログラムによって生成されたオブジェクトを含むドキュメントである（典型的には、オブジェクトおよびクラス型のデータ・メンバのみが混合ドキュメントに格納される）。例えば、スプレッドシート・プログラムが生成するスプレッドシート・オブジェクトを含んだワード・プロセッシング・ドキュメントは、混合ドキュメントである。ワード・プロセッシング・プログラムにより、ユーザは、ワード・プロセッシング・ドキュメント内にスプレッドシート・オブジェクト（例えば、セル）を組み込むことができる。スプレッドシート・オブジェクトの組み込みを可能にするために、ワード・プロセッシング・プログラムは、自身がスプレッドシート・オブジェクトの関数メンバを呼び出せるように、スプレッドシート・オブジェクトのクラス定義をもってコンパイルされる必要がある。任意のクラスのオブジェクトを混合ドキュメントに組み込むことを可能にするために、インタフェースが定義される。このインタフェースによって、ワード・プロセッシング・プログラムは、コンパイル時にクラス定義にアクセスする必要なく、オブジェクトにアクセスすることができる。抽象クラスは、インプリメンテーションを持たない少なくとも一つの仮想関数メンバ（純仮想関数メンバ）を有するクラスである。インタフェースは、データ・メンバを持たず、その仮想関数が全て純仮想関数である抽象クラスである。したがって、インタフェースは、２つのプログラムが通信するためのプロトコルを提供する。インタフェースは、典型的には、派生のために使用される。プログラムは、クラスを派生するインタフェースのインプリメンテーションを提供するクラスをインプリメント（実現）する。以下では、オブジェクトは、これらの派生したクラスのインスタンスとして生成される。
【００２９】
次のクラス定義は、インタフェースの定義の例である。この例では、説明を簡単にするために、ワード・プロセッシング・プログラムは、そのドキュメントに、オブジェクトの任意のクラスではなく、スプレッドシート・オブジェクトの組み込みを許容している。スプレッドシート・オブジェクトがどのようにインプリメントされているかに関わらず、このインタフェースを提供する任意のスプレッドシート・オブジェクトの組み込みが可能となる。さらに、ワード・プロセッシング・プログラムのコンパイルの前後を問わず、任意のスプレッドシート・オブジェクトの組み込みが可能となる。
【００３０】
0003868013.tif 000005
【００３１】
スプレッドシート・プログラムの開発者は、スプレッドシート・オブジェクトをワード・プロセッシング・ドキュメントに組み込むために、このインタフェースのインプリメンテーションを提供する必要がある。一般に、開発者は、このインタフェースから派生された、このインタフェースによって定義された各関数のコードを含むクラス定義を提供するであろう。
【００３２】
ワード・プロセッシング・プログラムが、スプレッドシート・オブジェクトを組み込むときに、このプログラムは、スプレッドシート・オブジェクト用のインタフェース（関数メンバ）をインプリメントするクラスのコードにアクセスする必要がある。このクラスのコードにアクセスするために、ユニークなクラス識別子が各インプリメンテーションに与えられる。例えば、マイクロソフト社によって開発されたスプレッドシート・オブジェクトをインプリメントするコードは、“MSSpreadsheet ”というクラス識別子をもつ。一方、他の会社によって開発されたスプレッドシート・オブジェクトをインプリメントするコードは、“LTSSpreadsheet”というクラス識別子をもつ。クラスをインプリメントするコードに各クラス識別子をマップする、各コンピュータ・システムにおけるパーシステント・レジストリ（persistent registry ）が保持されている。一般に、スプレッドシート・プログラムがコンピュータ・システムにインストールされるときに、スプレッドシート・オブジェクトのそのクラスを利用できるようにパーシステント・レジストリが更新される。スプレッドシートの開発者がインタフェースによって定義される各関数メンバをインプリメントし、パーシステント・レジストリが保持される限り、ワード・プロセッシング・プログラムは、開発者のスプレッドシート・オブジェクトのインスタンスをワード・プロセッシング・ドキュメントに組み込むことができる。ワード・プロセッシング・プログラムは、だれがそのオブジェクトをインプリメントしたか、そのオブジェクトがどのようにインプリメントされたかに関わらず、組み込まれたスプレッドシート・オブジェクトの関数メンバにアクセスする。
【００３３】
【発明の概要】
この発明の目的は、コンピュータ・ネットワークにおいて、リモートにコードを実行する方法およびシステムを提供することにある。
【００３４】
この発明の他の目的は、ネットワークを事前に構成することなく、また、クライアント・プログラムまたはユーザが、サーバ・コードまたはパーシステント・オブジェクト・データに関する情報を知ることなく、コードをリモートに実行する方法およびシステムを提供することにある。
【００３５】
この発明の他の目的は、サーバ・コードを実行するために、ローカル・コンテキストとリモート・コンテキストの双方を含む、異なるロケーション・コンテキストを特定する方法およびシステムを提供することにある。
【００３６】
この発明の他の目的は、特定されたオブジェクト・インスタンスのパーシステント・データ・ビットが格納されたサーバ・ノード上で、サーバ・コードを実行する方法およびシステムを提供することにある。
【００３７】
この発明の他の目的は、クライアント・アプリケーションがある特定のオブジェクトにアクセスした後に、サーバ・コードを実行する場所を決定するための方法およびシステムを提供することにある。
【００３８】
この発明の他の目的は、サーバ・プログラムによって特定されたロケーション・コンテキストとクライアント・プログラムによってリクエストされた望ましいロケーション・コンテキストとの間の裁定を行うための方法およびシステムを提供することにある。
【００３９】
この発明の他の目的は、サーバ・コードを実行するための望ましいセキュリティ・コンテキストを特定する方法およびシステムを提供することにある。
【００４０】
この発明の他の目的は、サーバ・コードをクライアント・プログラムと同じセキュリティ・コンテキストで実行すべきか、ある特定されたセキュリティ・コンテキストで実行すべきかを特定するための方法およびシステムを提供することにある。
【００４１】
これらの目的および他の目的は、以下に詳述するこの発明の説明によって、より明確になるであろう。また、これらの目的および他の目的は、リモートにコードを実行する方法およびシステムによって達成される。好ましい実施例においては、クライアント・プログラムは、オブジェクト・インスタンスまたはクラス・インスタンスへのアクセスをリクエストする。続いて、クライアント・サービス制御マネージャは、リクエストされたオブジェクトに対応するサーバ・コードを実行すべき場所を決定する。そして、クライアント・サービス制御マネージャは、このリクエストを別のネットワーク・ノードに転送するか、またはこのサーバ・コードをローカルに実行する。クライアント・サービス制御マネージャは、サーバ・プログラムが提供するロケーション・コンテキスト仕様およびクライアント・プログラム・リクエストによってリクエストされた任意のロケーション・コンテキストに基づいて、適切なサーバ・コードをスタートさせる場所を決定する。決定されたロケーションがリモート（遠隔地）である場合に、サーバ・サービス制御マネージャは、クライアント・サービス制御マネージャによって転送されたリクエストを受信し、サーバ・コードの実行（まだ実行されていないならば）を開始する。続いて、このサーバ・コードは、クライアント・プログラムによってリクエストされたオブジェクト・インスタンスまたはクラス・インスタンスを発見または生成する。続いて、このサーバ・コードは、リクエストされたオブジェクトのインタフェースをマーシャルし、マーシャルされたインタフェースを、サーバ・サービス制御マーシャルに送り返す。サーバ・サービス制御マネージャは、クライアント・サービス制御マネージャを介して、このマーシャルされたオブジェクトをクライアント・プログラムに転送する。
【００４２】
【実施例】
この発明は、ある特定のロケーション（位置）でサーバ・コードをリモートに実行するためのコンピュータ・システムにおける方法を提供するものである。サーバ・プログラムは、ある特定のクラス識別子に対応するオブジェクトを管理するためのサーバ・コードを提供する（サーバ・コードがオブジェクトのクラスの振る舞いをインプリメント（実現）する）ものである。サーバ・コードは、一または複数のインタフェースをインプリメントする。インプリメンテーション（実現ないし実現したもの）の部分が複数のクライアントによって共有されるシステムにおいて、クライアント・プログラムは、そのクライアント・プログラムの振る舞いをインプリメントすることを手助けするために、サーバ・プログラムからのサービスをリクエストする。典型的なオブジェクト指向型の環境において、サーバ・プログラムは、クライアント・プログラムによって呼び出され（起動され）、クライアント・プログラムがインプリメントするものの外部にあるオブジェクトを管理する。
【００４３】
混合（コンパウンド）ドキュメント・システムの場合に、クライアント・プログラムが混合ドキュメントをインプリメントし、サーバ・プログラムがその混合ドキュメント内に格納されている組み込まれた（すなわち、リンクされた）オブジェクトを管理するサーバ・コードを提供する。発明の背景の項で述べた例では、ワード・プロセッシング・プログラムがクライアント・プログラムであり、このプログラムは、混合ドキュメントをサポートする。組み込まれたスプレッドシート・オブジェクトは、スプレッドシート・プログラムによってサポートされ、操作される。このスプレッドシート・プログラムが、サーバ・プログラムである。
【００４４】
サーバ・プログラムは、ある特定のクラス識別子を、複数の形態（動的リンク・ライブラリ（“ＤＤＬ”：dynamic Link Library）または独立して実行できるコード（例えば、.EXEファイル）を含む）でインプリメントするコードを提供する。このコードが、これら以外の形態を取ることができるのはいうまでもない。この理由から、オブジェクトのクラスをサポートするために提供されるコードは、サーバ・プログラムではなく、サーバ・コードと呼ばれる。
【００４５】
この発明により、クライアント・プログラムおよびネットワーク・サービス（ネットワークの機能へのアクセスをサポートし、保持するコード）は、サーバ・コードを実行すべき場所の決定を、クライアント・プログラムがオブジェクトにアクセスするために実際にリクエストする時まで、遅らせることができる。アプリオリな構成（コンフィグレーション）に関する知識を、クライアント・プログラム、サーバ・コードまたはサーバ・コードの配置を担当するネットワーク・サービスに組み込む必要はない。特に、クライアント・プログラムがオブジェクトのアクセス・リクエストを出すと（これにより、ある特定のオブジェクトに関連したサーバ・コードを実行するリクエストを生成する）、その時に、ネットワーク・サービスは、サーバ・コードを実行するためのロケーションを決定する。ロケーションを決定するために、ネットワーク・サービスは、ロケーション・コンテキストを、システム定義のアルゴリズムに従って組み合わせる。このロケーション・コンテキストは、クライアント・プログラムがオブジェクトへのアクセス・リクエストで要求しているロケーション・コンテキストによって、サーバ・プログラムのクラス・コードがパーシステント・レジストリ（継続的に保持する登録簿）内で特定したものである。ロケーション・コンテキストは、サーバ・コードが実行されるべきロケーションを総括的に表したものである。ある特定のシナリオにおいて、どのサーバ・コードが実行されるかを決定するために、このロケーション・コンテキストは使用される。サーバ・プログラムは、サーバ・コードを異なるシナリオで実行するためのロケーション・コンテキストを特定することができる。異なるシナリオには、ある特定の名前をもったノード、クライアント・プログラムが実行されているノード、またはオブジェクト・データのパーシステント・ストレージが配置されているノードにおけるサーバ・コードの実行が含まれる。サーバ・プログラムの仕様と同様に、クライアント・プログラムは、ある特定のシナリオでサーバ・コードを実行するように、サーバ・コードにリクエストすることができる。例えば、サーバ・プログラムは、ある特定の名前をもったノードでサーバ・コードを実行するために、ロケーション・コンテキストの特定のみを行う。クライアント・プログラムは、クライアント・プログラムが実行されるノードで、サーバ・コードを実行するためのロケーション・コンテキストをリクエストする。続いて、ネットワーク・サービスは、サーバ・コードを実行するノードおよび実行すべきサーバ・コードを、特定されたロケーション・コンテキストおよびリクエストされたロケーション・コンテキストに基づいて決定する。
【００４６】
サーバ・コードのロケーションに加えて、サーバ・プログラムは、このプログラムが、ある特定のセキュリティ・コンテキストで実行されるサーバ・コードを所望することを、パーシステント・レジストリ内で指定することができる。セキュリティ・コンテキストは、コンピュータ・システムによって使用される。セキュリティ・コンテキストにより、あるコードのみが、アクセスが認められる前に定められたレベルの許可を要求されるデータ、コードおよびシステム・リソースにアクセスできることが確実にされている。実行すべきコードが、指定された適切な許可をもつセキュリティ・コンテキストを有するならば、プロテクトされたデータ、コードおよびリソースへのアクセスが認められる。セキュリティ・コンテキストの仕様は、一般にオペレーティング・システムに依存する。例えば、セキュリティ・コンテキストを、ユーザ・アカウント（ユーザＩＤ）およびパスワードとして見ることができる。セキュリティ・コンテキストの仕様をインプリメントする多くの方法がある。一実施例においては、サーバ・コードは、パーシステント・レジストリ内でユーザＩＤを、保護データベースに対応するパスワードをそれぞれ指定する。ネットワーク・サービスまたはクライアント・プログラムがサーバ・コードを実行するときに、パーシステント・レジストリおよび保護データベースの情報を使用し、ある特定のセキュリティ・コンテキストでサーバ・コードを実行する。
【００４７】
好ましい実施例においては、この発明の方法およびシステムは、中央処理装置、メモリおよび入出力装置を備えたコンピュータ・システム上で実現される。このような実施例において、サーバ・プログラムは、サーバ・コードの実行に関係した情報をパーシステント・レジストリ内で指定する。サーバ・コードを発見するための少なくとも一つのネットワーク・パスを指定することに加えて、サーバ・プログラムは、パーシステント・レジストリ内でロケーション・コンテキストを指定する。特に、サーバ・プログラムは、(1) クライアント・プログラムが内部プロセスのサーバ・コードを使用して実行されているノード（AT-CLIENT-DDL ロケーション・コンテキスト）、(2) クライアント・プログラムが独立して実行可能なサーバ・コードを使用して実行されているノード（AT-CLIENT 実行可能ロケーション・コンテキスト）、(3) オブジェクト・データのパーシステント・ストレージが配置されているノード（AT-BITS ロケーション・コンテキスト）、および(4) ある特定の名前をもつノード（AT-NAMED-NODE ロケーション・コンテキスト）で、サーバ・コードを実行するための一または複数のロケーション・コンテキストを指定する。第１に、AT-CLIENT-DDL ロケーション・コンテキストに対応して、サーバ・プログラムは、ＤＤＬの形態でサーバ・コードのロケーションを指定する。このロケーション・コンテキストにおいて、クライアント・プログラムがサーバ・コードの内部プロセスの実行をリクエストすると、ＤＤＬが、クライアント・プログラムの処理空間にロードされる。第２に、AT-CLIENT の実行可能ロケーション・コンテキストに対応して、サーバ・プログラムは、クライアント・プログラムと同じネットワーク・ノードでローカルにサーバ・コードを実行するために、独立して実行可能なコードのロケーションを指定する。第３に、AT-BITS ロケーション・コンテキストに対応して、サーバ・プログラムは、アクセスされるパーシステント・オブジェクト・データと同じネットワーク・ノードでリモートにサーバ・コードを実行するために、独立して実行可能なコードのロケーションを指定する。第４に、AT-NAMED-NODE ロケーション・コンテキストに対応して、サーバ・プログラムは、クライアントによって名前を付けられたネットワーク・ノードでリモートにサーバ・コードを実行するために、独立して実行可能なコードのロケーションを指定する。AT-CLIENT-DDL およびAT-CLIENT ロケーション・コンテキストは、これらのコンテキストがクライアント・ノードと同じノードでの実行を指定することから、ローカル・ロケーション・コンテキストと呼ばれる。AT-BITS およびAT-NAMED-NODE ロケーション・コンテキストは、リモート・ロケーション・コンテキストと呼ばれる。また、単一のAT-NAMED-NODE ロケーション・コンテキストの代わりに、他の実施例として、サーバ・プログラムが各名前をもつノード用の個別のロケーション・コンテキスト（またはそれらの組み合わせ）を指定することもできる。例えば、サーバ・プログラムは、一つのロケーション・コンテキストにおいて、ある特定のノードに存在することが知られている特定のハードウェアに特に向けられたサーバ・コードのロケーションを指定することができる。
【００４８】
クライアント・プログラムは、サーバ・プログラムと同様に、オブジェクトにアクセスするリクエストにおいて、どのようにオブジェクトにアクセスすることが好ましいかを指定する。すなわち、クライアント・プログラムは、AT-CLIENT-DDL 、AT-CLIENT 、AT-BITS またはある特定の名前をもつノードのいずれで、サーバ・コードを実行することが好ましいかを指定する。サーバ・プログラムと異なり、名前をもつノードのロケーション・コンテキストにリクエストするときに、クライアント・プログラムは、総称的なAT-NAMED-NODE インディケータではなく、ノードの特定の名前を指定する。サーバ・コードが実行されるべき場所を決定する機能をもつネットワーク・サービス・コードは、サーバ・プログラムがパーシステント・レジストリで指定したものと、クライアント・プログラムがリクエストしているものとの間で裁定を行う。
【００４９】
好ましい実施例においては、サーバ・プログラムは、パーシステント・レジストリにおいて、そのコードに望ましいセキュリティ・コンテキストを指定する。サーバ・プログラムは、オペレーティング・システムに依存した方法で、上述したように、一般にユーザＩＤとパスワードからなるセキュリティ・コンテキストを指定する。サーバ・プログラムは、パーシステント・レジストリにおいて、クライアント・プログラム・ユーザＩＤで実行することが好ましいか、ある特定のユーザＩＤで実行することが好ましいかを指定する。さらに、サーバ・プログラムは、使用することが望ましいユーザＩＤに対するパスワード（セキュリティ・コンテキスト）を、保護データベースに登録する。ネットワーク・サービス（またはクライアント・プログラム）が、サーバ・コードの実行を開始すると、サーバ・コードは、パーシステント・レジストリで指定されたセキュリティ・コンテキストで実行される。サーバ・プログラムが、「クライアントとしての」セキュリティ・コンテキストを指定しているならば、ネットワーク・サービスは、周知の手法を用いて、クライアント・プログラムの役割を演じる。このような手法の一つは、（任意のプログラムのアカウント情報をセットする機能をもつ）リモート・プロシジャ・コール・サーバに、（そのアカウント情報をクライアント・プログラム・アカウント情報にセットする）クライアント・プログラムの役を演じるようにリクエストすることを含み、サーバ・コードを実行させる。または、ネットワーク・サービスは、クライアント・プログラム・アカウント情報にセットされたそのアカウント情報により、新たなユーザ・プロセスをスタートさせ、サーバ・コードの実行を開始する新たなプロセスをリクエストすることができる。一方、サーバ・プログラムが、ある特定のユーザＩＤとして実行することが好ましいことを指定しているならば、ネットワーク・サービスは、保護データベースから対応するパスワードを得、この情報を用いてサーバ・コードの実行を開始する。望ましいサーバ・コードと通信していることを保証するクライアント・プログラムは、サーバ・プログラムによって指定されたセキュリティ・コンテキストでサーバ・コードを実行するための信頼性のあるプログラムまたはプロセスをリクエストすることができる。このようなメカニズムは、クライアント・プログラムがサーバ・コードの適正なバージョンと通信していることを保証する。
【００５０】
図２は、オブジェクトにアクセスするために使用されるクライアント・ノードおよびサーバ・ノードの全体構成を示すブロック図である。クライアント・ノード204 は、クライアント・プログラム201 、クライアント・サービス制御マネージャ202 および登録データベース203 を含んでいる。サーバ・ノード208 は、サーバ・サービス制御マネージャ206 、登録データベース207 およびサーバ・コード205を含んでいる。さらに、コンピュータ・システムは、ファイルにアクセスするためのネットワーク・ファイル・サービス、および特定されたコードもしくはデータのネットワーク・アドレスまたは指定されたノードのネットワーク・アドレスを決定するためのロケーション・サービスを含んでいる。好ましい実施例において、これらのサービスは、分散ファイル・システム（“ＤＦＳ”）209 によって提供される。これらのサービスを、他の方法（例えば、集中ファイル・システム・サーバ）によって提供することができるのはいうまでもない。
【００５１】
すなわち、好ましい実施例において、新しいオブジェクトまたは既存オブジェクトのいずれかにアクセスするために、クライアント・プログラム201 は、クライアント・プログラム起動リクエストをクライアント・サービス制御マネージャ202 に送信し、ある特定のクラス識別子に対応するオブジェクトを起動させる。クライアント・サービス制御マネージャ202 は、そのサービスが必要とされるときにクライアント・ノードで開始される個別のプロセスである。したがって、クライアント・プログラム201 は、ローカル・リモート・プロシジャ・コール（“ＲＰＣ”）・メカニズムを介して、クライアント・サービス制御マネージャ202 と通信する（「ローカルな」ＲＰＣコールとは、異なるプロセスではあるが、同じノードにおけるプロシジャの呼び出しをいう）。リクエストがあると、クライアント・サービス制御マネージャ202 は、登録データベース203 内の情報を捜し、起動リクエストに対応するサーバ・コードを実行するための望ましいロケーション・コンテキストを決定する。また、リクエストがあると、クライアント・サービス制御マネージャ202 は、ＤＦＳ209 に、ネットワーク・パス名を与えるサーバ・ノード・ネットワーク・アドレスを返すように依頼する。クライアント・サービス制御マネージャ202 が、どのネットワーク・ノードと通信すべきかを知ると、クライアント・サービス制御マネージャ202 は、標準ＲＰＣメカニズムを用いて、クライアント・プログラム起動リクエストに対応して決定されたノード上のサーバ・サービス制御マネージャ206 へ、リモート接続を確立する（クライアント・サービス制御マネージャ202 が、オブジェクト・サーバ・コード205 がローカルに実行される必要があると判断した場合には、クライアント・サービス制御マネージャ202 は、ローカルＲＰＣメカニズムを用いて、オブジェクト・サーバ・コード205 と直接通信する）。この通信において、クライアント・サービス制御マネージャ202 は、クライアント・プログラム起動リクエストの全情報をサーバ・サービス制御マネージャ206 に転送する。続いて、サーバ・サービス制御マネージャ206 は、登録データベース（およびおそらくＤＦＳ209 ）を調べ、適切なオブジェクト・サーバ・コード205 を発見する。続いて、サーバ・サービス制御マネージャ206 は、もし必要ならば、オブジェクト・サーバ・コード205 をスタートさせる。オブジェクト・サーバ・コード205 は、新たなまたは既存のオブジェクト・インスタンスを起動するのに必要ないかなるタスクをも実行する。最後に、オブジェクト・サーバ・コード205 は、オブジェクト・インスタンス・データ構造体へのポインタをパケットにマーシャルし（marshal ）、このパケットを、サーバ・サービス制御マネージャ206 およびクライアント・サービス制御マネージャ202 を介して、クライアント・プログラム201 に送信する。クライアント・プログラム201 は、ポインタをマーシャル解除し（unmarshal ）、続いてオブジェクト・サーバ・コードと直接通信することができる。
【００５２】
マーシャルおよびマーシャル解除は、プロセス間でオブジェクトへのポインタを渡す（パッシングする）ためのメカニズムである。これらについては、米国特許第5,511,197「リモート・プロシジャ・コールのためのインタフェース・ポインタのネットワーク・マーシャリング方法およびシステム」（A METHOD AND SYSTEM FOR NETWORK MARSHALLING OF INTERFACE POINTERS FOR REMOTE PROCEDURE CALLS）に示されている。この米国特許出願は、この特許出願の優先権主張の基礎となる米国特許出願と同時に出願されたものである。基本的に、アプリケーションは、プロセス間に渡って送信されるパケットに、インタフェースへのポインタをパッケージするためにマーシャルを使用する。パケットは、サーバ・ノードおよび応答通信用のプロセス（コールバック機能）を指定する情報を含んでいる。ポインタがマーシャルされると、スタブ・オブジェクトが、サーバ・プロセス内に生成される。このスタブ・オブジェクトは、オブジェクト・サーバ・コードの実際の関数メンバを呼び出す方法を知っている。クライアント・プロセスが、マーシャルされたインタフェース・ポインタを受信すると、このクライアント・プロセスは、ポインタをマーシャル解除し、それ自身のアドレス空間内にインタフェース・プロクシ・オブジェクト（インタフェース代理オブジェクト）を生成する。このプロクシ・オブジェクトは、そのインタフェースの全ての関数メンバの関数エントリ・ポイントを含んでいる。しかし、各関数のインプリメンテーションは、その呼び出しをスタブ・オブジェクトに単に転送するだけである。マーシャル・プロセスは、プロクシおよびスタブ・オブジェクトを生成し、今後の通信のためにそれらを接続する。
【００５３】
［クラス・インスタンスへのアクセス］
図３は、クラス・インスタンスにアクセスするための通信パスのフローチャートである。クライアント・プログラムは、クラス・インスタンスを任意の方法で使用することができる。典型的な例として、クライアント・プログラムは、このクラス・インスタンスを使用して、IClassFactory インタフェースを使用するそのクラスの別のインスタンス（オブジェクト）を生成する。IClassFactory インタフェースは、そのクラスのオブジェクトを生成する関数メンバCreateInstanceを提供する。このような全てのオブジェクトは、同じクラス識別子を有し、したがって同じクラス（オブジェクト・サーバ）・コードを共有する。このクラス・コードは、発明の背景の項で述べたように、オブジェクト・データを操作する関数メンバのインプリメンテーションを提供する。
【００５４】
図３は、４つの異なるプロセス（クライアント・プログラム301 、クライアント・サービス制御マネージャ306 （クライアントＳＣＭ）、サーバ・サービス制御マネージャ313 （サーバＳＣＭ）およびオブジェクト・サーバ・コード320 ）間における通信を示している。破線は、ノードの境界を示している。クライアント・プログラム301 およびクライアント・サービス制御マネージャ306 は、クライアント・ノードに存在する。サーバ・サービス制御マネージャ313 およびオブジェクト・サーバ・コード320 は、サーバ・ノードに存在する。図２の説明で述べたように、クライアント・プログラムは、クライアント・サービス制御マネージャ306 からクラス・オブジェクトの起動をリクエストする。クライアント・サービス制御マネージャ306 は、どのサーバ・サービス制御マネージャと通信すべきかを決定した後に、適切なサーバ・サービス制御マネージャ313 にこのリクエストを転送する。続いて、リクエストを転送されたサーバ・サービス制御マネージャ313 は、リクエストされたオブジェクト・サーバ・コードの実行を開始する。次に、オブジェクト・サーバ・コード320 は、リクエストされたオブジェクトのIClassFactory インタフェースを生成し、このインタフェースを、２つのサービス制御マネージャを介してクライアント・プログラム301 へ返す。
【００５５】
この説明は、決定されたサーバ・サービス制御マネージャが、遠隔のサーバ・ノードに存在することを仮定している。一方、クライアント・サービス制御マネージャ306 が、オブジェクト・サーバ・コード320 をクライアント・プログラム301 と同じノードで実行すべきと決定した場合には、クライアント・サービス制御マネージャ306 は、クライアント・プログラムのリクエストを転送する必要はない。この技術分野の専門家には、このようなオブジェクト・サーバ・コードのローカルな実行も、リモートの実行と同様に行われることが容易に分かるであろう。したがって、ここではその詳細な説明は省略する。
【００５６】
ステップ302 において、クライアント・プログラム301 は、関数StartObjectServer を呼び出す（起動する）ために、ローカルＲＰＣメカニズムを介して、クライアント・サービス制御マネージャ306 へリクエストを送信する。このＲＰＣリクエストを受信すると、クライアント・サービス制御マネージャ306 は、関数StartObjectServer を呼び出し、サーバ・コードを実行すべき場所を決定し、決定されたサーバへ適切なリクエストを送信する。ステップ307 において、関数StartObjectServer は、関数DetermineServer を呼び出し、パーシステント・レジストリのサーバ・コード・ロケーション・コンテキストの仕様と、クライアントがリクエストしたロケーション・コンテキスト（それがクライアント・プログラム・リクエストに示されているならば）との双方に基づいて、望ましいサーバ・ノードを決定する（この関数は、図４において詳細に説明する）。ステップ308 において、この関数は、決定されたサーバ・ノードが（クライアント・プログラム301 が実行されている）ローカル・ノードと同じかどうかを判定する。もし同じならば、関数の処理はステップ309 に進み、そうでなければステップ310 に進む。ステップ309 において、この関数は、ステップ314 〜316 と同様のステップを実行して、オブジェクト・サーバ・コードの処理をローカルにスタートさせる。ステップ309 において、この関数は、ローカルに実行されているオブジェクト・サーバ・コードに対してローカルＲＰＣコールを最後に実行する。ローカルに実行されているオブジェクト・サーバ・コードは、ローカルＲＰＣコールを、クライアント・サービス制御マネージャ306 に送信し、実行はステップ311 に進む。ステップ310 において、関数は、決定されたサーバ・ノード上で関数StartObjectServer を呼び出すためのリクエストを、リモートＲＰＣメカニズムを用いて送信する。関数StartObjectServer は、適切なサーバ・サービス制御マネージャにクライアント・プログラム・リクエストを転送する。関数StartObjectServer を呼び出すためのリクエストを受信すると、決定されたサーバ・ノード上のサーバ・サービス制御マネージャ313 は、関数StartObjectServer を呼び出す（起動する）。ステップ314 において、関数StartObjectServer は、すでに実行されている、リクエストされたクラス識別子のIClassFactory インタフェースのインスタンスがあるかどうかを判定する。もしあるならば、関数の処理はステップ319 に進み、そうでなければステップ315 に進む（オブジェクト・サーバ・コードが実行されるごとに、オブジェクト・サーバ・コードは、このコードが生成し管理することができるオブジェクトのクラスのそれぞれに対して、IClassFactory インタフェースのインスタンスを生成し、登録する）。関数StartObjectServer は、このインタフェースのインスタンスが登録されているならば、マーシャルされた形態であると仮定する。続いて、関数StartObjectServer は、このマーシャルされたインタフェースを検索し、ステップ319 においてマーシャルされたインタフェースを送信する。ステップ315 において、関数StartObjectServer は、実行すべきオブジェクト・サーバ・コードを識別するための現在のロケーション・コンテキストに対応するパーシステント・レジストリ情報を調べる。一実施例において、この情報は、ＤＤＬまたは独立して実行可能なコードをポイントするある特定のパス名である。この関数は、もし必要ならば、ＤＦＳを調べ、オブジェクト・サーバ・コードを実際に獲得する。ステップ316 において、関数StartObjectServer は、オブジェクト・サーバ・コード320 の実行を開始する。ステップ317 において、この関数は、オブジェクト・サーバ・コード320 にリクエストを送信し、ローカルＲＰＣメカニズムを用いて、RemCoActivateClassObject関数を呼び出す。リクエストが受信されると、オブジェクト・サーバ・コード320 は、関数RemCoActivateClassObjectを呼び出す。関数RemCoActivateClassObjectは、IClassFactory インタフェースのインスタンスを生成し、このインタフェースのマーシャルされたバージョンをサーバ・サービス制御マネージャ313 に返す。ステップ321 において、関数RemCoActivateClassObjectは、リクエストされたクラス識別子のIClassFactory インタフェースのインスタンスを生成する。ステップ322 において、この関数は、このIClassFactory インタフェースのインスタンスをパケットにマーシャルする。ステップ323 で、関数RemCoActivateClassObjectは、ローカルＲＰＣメカニズムを介して、サーバ・サービス制御マネージャ313 へこのパケットを返す。一方、関数StartObjectServer （サーバ・サービス制御マネージャ313 によって実行されている）は、ステップ318 で、マーシャルされたIClassFactory インタフェース・インスタンスを受信し、ステップ319 で、クライアント・サービス制御マネージャ306 に、このパケットを転送する。続いて、クライアント・サービス制御マネージャ306 によって実行される関数StartObjectServer は、マーシャルされたパケットを（リモートまたはローカルなサーバ・コードのいずれかから）ステップ311 で受信する。ステップ312 で、関数StartObjectServer は、マーシャルされたIClassFactory インタフェース・インスタンスを含むパケットを、ローカルＲＰＣメカニズムを介してクライアント・プログラム301 へ送信する。クライアント・プログラム301 が、関数CoGetClassObjectのステップ303 でこのパケットを受信すると、関数CoGetClassObjectは、ステップ304 で、このパケットをプロクシ・オブジェクト（代理オブジェクト：proxy object）にマーシャル解除する。このプロクシ・オブジェクトは、リクエストされたクラス識別子のIClassFactory インタフェースをインプリメントする。マーシャル解除の関数コールを通じて、このプロクシ・オブジェクトは、サーバ・ノード上の同じIClassFactory インタフェースに対応するスタブ・オブジェクトに接続される。ステップ305 で、関数CoGetClassObjectは、起動されたクラス・オブジェクトへのポイントを含むように示されたリターン・パラメータを、このプロクシ・オブジェクトへセットし、リターンする。
【００５７】
図４は、オブジェクト・サーバ・コードを実行するロケーションを決定する関数DetermineServer のフローチャートである。この関数は、クライアント・サービス制御マネージャ306 （図３）によって呼び出され、クライアント・プログラム起動リクエストに適切なサーバ・ノード・ネットワーク・アドレスをリターンする。サーバ・ノード・アドレスが受信されると、クライアント・サービス制御マネージャ306 は、クライアント・プログラム起動リクエストを、決定されたサーバ・ノード上にあるサーバ・サービス制御マネージャ313 に転送する。関数DetermineServer は、パーシステント・レジストリ内のサーバ・プログラムによって提供されるロケーション・コンテキスト仕様と、クライアント・プログラムによってリクエストされたロケーション・コンテキストと組み合わせ、これらに基づいて、リクエストされたサーバ・コードを実行するためのサーバ・ノードを選択する。この関数は、図５〜図15に示す表（後述）に基づいて、サーバ・ノードを選択する。この関数は、２つの入力パラメータと一つの出力パラメータを有する。クライアントの特定されたロケーション・コンテキストが、オリジナルのクライアント・プログラム起動リクエストで指定されたならば、パラメータclient-specified-ctxは、このロケーション・コンテキストを含んでいる。このパラメータの値には、AT-BITS 、AT-CLIENT-DLL 、AT-CLIENT またはある特定のサーバ・ノードの名前が含まれる。第２の入力パラメータは、ppath である。このppath は、オブジェクト・インスタンス・データへのネットワーク・パスがオリジナルのクライアント・プログラム起動リクエストから派生することができるならば、このパス名となる。出力パラメータp-serveraddrは、サーバ・ノードのネットワーク・アドレスへのポインタである。
【００５８】
関数DetermineServer は、パーシステント・レジストリ内のロケーション・コンテキスト情報をclient-specified-ctxパラメータと組み合わせための１セットのルールを用いて、サーバ・ノードを選択する。これらのルールについては、図５〜図15の説明において詳述する。ロケーション・コンテキストを組み合わせるための多くの選択可能なルールが他にあることは勿論である。また、AT-BITS 、AT-CLIENT-DLL 、AT-CLIENT およびAT-NAMED-NODE と異なるロケーション・コンテキストを定めることもできる。図５〜図15のテーブルは、クライアント・プログラムによって呼び出される特定の起動リクエスト、リクエストされたロケーション・コンテキスト、およびサーバ・プログラムによって特定されたロケーション・コンテキストに基づいて、どのサーバ・ノードが使用されるかを示している。図示するように、これらのテーブルには、どのサーバ・コードが実行されるべきかを決定するための４つの一般的なルールも組み込まれている。第１に、AT-BITS ロケーション・コンテキストが、サーバ・プログラムによって特定されると、このロケーション・コンテキストに対応するサーバ・コードは、オブジェクト・インスタンス・データ（bits）が配置されている場所でのみ実行されるのが好ましい。第２に、クライアント・プログラムがリモート・ロケーション・コンテキスト（例えば、AT-BITS またはある特定の名前をもつノード）をリクエストし、かつ、サーバ・プログラムがローカル・ロケーション・コンテキスト（例えば、AT-CLIENT またはAT-CLIENT-DDL ）を特定しているだけならば、ローカル・ロケーション・コンテキスト仕様は、リモートでの実行に使用されないのが好ましい。なぜならば、対応するサーバ・コードをリモートで実行できないからである（ローカル・コードは、ローカルでのみ実行されるのが好ましい）。第３に、クライアント・プログラムが、ローカル・ロケーション・コンテキスト（例えば、AT-CLIENT またはAT-CLIENT-DDL ）をリクエストすると、ローカル・ロケーション・コンテキストがサーバ・プログラムによって特定されていたならば、ローカル・ロケーション・コンテキストが使用されるのが好ましい。ローカル・ロケーション・コンテキストが特定されない場合には、AT-NAMED-NODE リモート・ロケーション・コンテキストがサーバ・プログラムによって特定されていたならば、このAT-NAMED-NODE リモート・ロケーション・コンテキストが使用されるのが好ましい。しかし、対応するサーバ・コードは、ローカルで実行される（AT-BITロケーション・コンテキストは、第１のルールが満足されないならば、ローカルな実行に使用されないのが好ましい）。第４に、クライアント・プログラムがロケーション・コンテキストをリクエストせず、かつ、サーバ・プログラムが一つのロケーション・コンテキストのみを指定しているならば、AT-BITS ロケーション・コンテキストに関する第１のルールに従って、このロケーション・コンテキストが使用されるのが好ましい。サーバ・プログラムが複数のロケーション・コンテキストを指定している場合に、図５〜図15に示すテーブルは、どのロケーション・コンテキストを使用すべきかを示している。
【００５９】
ステップ401 において、関数DeterminServerは、パーシステント・レジストリにあるロケーション・コンテキスト仕様、リクエストされたclient-specified-ctxロケーション・コンテキスト（存在するならば）、および図５〜図15に定められたルール表に基づいて、サーバ・ノードを選択する。ステップ402 において、この関数は、正当なロケーション・コンテキストがルール表を用いて派生されたかどうかを判定し、もしそうならば、ステップ403 に進み、そうでなければエラーを返す。ステップ403 において、関数は、AT-BITS ロケーション・コンテキストに対応するサーバ・ノードが選択されているかどうかを判定し、もしそうならばステップ404 に進み、そうでなければステップ407 に進む。ステップ404 で、関数は、ppath が指定されているかどうかを判定する。このppath は、リクエストされたオブジェクト・インスタンス・データへのネットワーク・パス名を示す。もしそうならば、関数はステップ405 に進み、そうでなければエラーを返す。ステップ405 で、関数は、ロケーション・サービス（ＤＦＳ）に、ノード名またはパス名のいずれかに基づいて、選択されたサーバ・ノードのネットワーク・アドレスを要求する。この場合に、関数は、ppath に基づいたネットワーク・アドレスを要求する。ステップ406 で、関数は、リターン・パラメータp-serveraddrを、ロケーション・サービスによって返されたネットワーク・アドレスにセットする。ステップ407 において、関数は、AT-NAMED-NODE ロケーション・コンテキストに対応するサーバ・ノードが選ばれているかどうかを判定し、もしそうならばステップ405 に進み、クライアントのリクエストされたノード名を使用し、そうでなければステップ408 に進む。ステップ408 で、関数は、AT-CLIENT またはAT-CLIENT-DDL ロケーション・コンテキストに対応するサーバ・ノードが選ばれているかどうかを判定し、もしそうならばステップ409 に進み、そうでなければエラーを返す。ステップ409 で、関数は、リターン・パラメータp-serveraddrをクライアント・ノードのネットワーク・アドレスにセットし、リターンする。
【００６０】
図５〜図15は、クライアント・プログラムによってリクエストされたロケーション・コンテキストによりパーシステント・レジストリ内で特定されたロケーション・コンテキスト情報を組み合わせるためのルールを定めた表である。各表は、ある特定のクライアント・プログラム起動リクエストおよびサーバ・プログラムによって指定された、ある特定のロケーション・コンテキストのセットを与えた場合の、サーバ・コードが実行されるのが好ましい一般的なノード・ロケーション、およびどのサーバ・コードが実行されるべきかを定めている。この一般的なノード・ロケーションは、クライアント・プログラムが実行されているノード、クライアント・プログラム起動リクエストによって指定されたノード、またはリクエストされたオブジェクトのパーシステント・データが格納されているノードでの実行に対応する。各表は、５つの列および複数の行からなる。第１列は、特定のクライアント・プログラム起動リクエスト、およびもしあるならばクライアント・プログラムのリクエストされたロケーション・コンテキストを示す。残りの列は、どのサーバ・コードを、ロケーション・コンテキスト仕様の全ての可能な組み合わせのどのノードで実行するかを示している。この実施例では、サーバ・プログラムによって指定可能な15個のロケーション・コンテキストの可能な組合せがある。各行は、指定されたロケーション・コンテキストの一つの可能な組合せを示している。サーバ・プログラムによって指定できる各ロケーション・コンテキスト用の別々の列がある。一行一列に対応する各セルは、サーバ・プログラムが、対応する列のロケーション・コンテキスト情報を指定しているかどうかを示している。これらの表において、第２列は、AT-CLIENT-DDL ロケーション・コンテキスト（IN-PROC ）に対応する。第３列は、独立して実行可能なコードのAT-CLIENT ロケーション・コンテキスト（LOCAL-SERVER）に対応する。第４列は、AT-NAMED-NODE ロケーション・コンテキスト（Named Node）に対応する。第５列は、AT-BITS ロケーション・コンテキスト（AT-BITS ）に対応する。パーシステント・レジストリに指定されたロケーション・コンテキストの与えられた組合せ（各行）に対して、セルが定められ、かつ、セルが、対応するロケーション・コンテキスト情報がサーバ・コードの発見に使用されるのが好ましいことを示すならば、そのロケーション・コンテキストに対応する一般的なノード・ロケーションは、サーバ・ノードとして選択される。与えられた組合せに対して、唯一のセルが定められ、かつ、このセルは、その対応するロケーション・コンテキストが使用されるのが好ましいことを示す。セルは、それが白色で示されているならば、定義されていることになる。セルがグレーで示されているならば、そのセルは、定義されていないことになる。セルに示された文字が“ＯＫ”ならば、そのセルは、その対応するロケーション・コンテキストが好ましく使用されることを示している。対応するロケーション・コンテキストが使用できることを示すために、他の文字（例えば、“runs at client”）を使用することもできる。一方、セルの文字が“FAIL”ならば、ロケーション・コンテキスト仕様のその特定の組合せおよびその特定のクライア��ト・リクエストに対して、対応するロケーション・コンテキストを使用しないことが好ましいことを示す。
【００６１】
例えば、図５の表は、クライアント・プログラム起動リクエストがCoGetClassObjectであり、かつ、クライアント・プログラムが起動リクエストのロケーション・コンテキストをリクエストしないときに、どのロケーション・コンテキストを使用すべきか（したがって、どのサーバ・ノードを使用すべきか）を定めている。パーシステント・レジストリのロケーション・コンテキスト仕様の全ての可能な組合せに対応する15個のルールが、第５行〜第19行、第２列から第５列に示されている。第５行〜第８行は、サーバ・プログラムが一だけのロケーション・コンテキストを指定している場合を示している。第５行で、サーバ・プログラムは、AT-BITS のロケーション・コンテキストの指定のみを行っている。この場合に、この表を用いてサーバ・ノードを選択するリクエストは、失敗（FAIL）に終わるであろう。なぜならば、最初に説明した一般のルールに従うと、AT-BITS 仕様は、好ましくは、オブジェクト・インスタンス・データが格納されているノードのサーバ・コードを実行するために使用されるだけであるからである。すなわち、CoGetClassObjectリクエストの場合に、オブジェクト・インスタンス・データはないからである。第６行では、サーバ・プログラムは、AT-NAMED-NODE 用のロケーション・コンテキストの指定のみを行っている。この場合、クライアント・ノードがサーバ・ノードとして選択され、AT-NAMED-NODE ロケーション・コンテキストに対応するサーバ・コード・ロケーション情報は、このクライアント・ノードで実行すべきサーバ・コードを指定する。第７行では、サーバ・プログラムは、AT-CLIENT （実行可能な）ロケーション・コンテキストに対するロケーション・コンテキストの指定のみを行っている。この場合、クライアント・ノードがサーバ・ノードとして選ばれ、AT-CLIENT ロケーション・コンテキストに対応するサーバ・コード・ロケーション情報は、クライアント・ノードで実行すべきサーバ・コードを指定する。第８行では、サーバ・プログラムは、AT-CLIENT-DLL ロケーション・コンテキストに対するロケーション・コンテキストの指定のみを行っている。この場合、クライアント・ノードがサーバ・ノードとして選ばれ、AT-CLIENT-DLL ロケーション・コンテキストに対応するサーバ・コード・ロケーション情報は、クライアント・ノードで実行すべきサーバ・コードを指定する。同様にして、第９行〜第19行は、サーバ・プログラムがパーシステント・レジストリの２つまたはそれ以上のロケーション・コンテキストを定めている場合を示している。各行には、使用するのに適切なロケーション・コンテキストとして好ましく選択される一つのセルがある。第５行を除く、このクライアント・プログラム起動リクエスト（CoGetClassObject）の全ての場合に、クライアント・ノードはサーバ・ノードとして選ばれる。文字が書かれたノードでは、対応するロケーション・コンテキスト情報は、クライアント・ノードで実行されるサーバ・コードを指定するために使用される。
【００６２】
図５と同様に、図６〜図９は、クライアントが、AT-CLIENT-DDL ロケーション・コンテキスト、AT-CLIENT ロケーション・コンテキスト、指定された（名前のもつ）ノード・ロケーション・コンテキスト、およびAT-BITS ロケーション・コンテキストをそれぞれリクエストしたときの、CoGetClassObject起動リクエストに対応するルールを定める表をそれぞれ示している。また、図５と同様に、図10〜図15は、クライアントが、ロケーション・コンテキストをリクエストしなかったとき、AT-CLIENT-DDL ロケーション・コンテキスト、AT-CLIENT ロケーション・コンテキスト、名前をもつノード・ロケーション、ノードがオブジェクト・インスタンス・パーシステント・データが格納されたノード（AT-BITS ノード）でもあるときの名前をもつノード・ロケーション・コンテキスト、およびAT-BITS ロケーション・コンテキストをそれぞれリクエストしたときに、CoGetPersistentInstance またはCoNewPersistentInstance 起動リクエストに対応するルールをそれぞれ定める表である。
【００６３】
［既存のオブジェクト・インスタンスへのアクセス］
図16は、既存のオブジェクトのある特定のインスタンスにアクセスする通信パスのフローチャートである。この通信パスは、クライアント・プログラムが既存のオブジェクト（を起動およびアクセスするために）へのバインド（束縛または結合：bind）を試みるときに出会う典型的なパスである。好まし実施例においては、クライアント・プログラム601 は、オブジェクト・インスタンス・データが格納されたストレージ・オブジェクトへのパス名またはポインタを、バインド・リクエストに指定する。このバインド・リクエストにより、システム提供の関数CoGetPersistentInstance が起動される。図16に示す通信パスは、異なる関数が起動され、かつ、オブジェクト・サーバ・コード620 がわずかに異なるタスクを実行する点を除いて、基本的には図３の説明で述べた通信パスと同じである。また、オブジェクト・サーバ・コード620 は、IClassFactory インタフェース・インスタンスをマーシャルされた形態で返す代わりに、リクエストされたインタフェース・インスタンスをマーシャルされた形態で返す。
【００６４】
特に、次のステップは、図３と異なる。ステップ602 において、クライアント・プログラム601 は、クライアント・サービス制御マネージャ606 の関数SvcActivateObject の呼び出しをリクエストする。クライアント・サービス制御マネージャ606 によって実行される関数SvcActivateObject は、StartObjectServer と類似のステップを実行する。しかし、サーバ・サービス制御マネージャ613 によって実行されるSvcActivateObject 関数は、StartObjectServer とはわずかに異なるタスクを実行する。予備的なステップとして、この関数は、ステップ614 で、リクエストされたオブジェクト・インスタンスがサーバ・ノードですでに実行中であるかどうかを判定する。好ましい実施例において、この関数は、実行中のオブジェクト表を見ることによりこの判定を行う。この表は、サーバ・マシン上で現在実行されているオブジェクトの全ての参照を含んでいる。関数が、そのオブジェクト（オブジェクト・サーバ・コード620 ）が実行中であると判定すると、関数は、オブジェクト・サーバ・コードをスタートさせるステップをスキップし、ステップ617 に進む。そうでなければ、関数は、ステップ615 および616 に進み、関数がオブジェクト・サーバ・コード620 の異なるエントリ・ポイントRemCoActivateObject を呼び出す点を除いて、図３の説明で述べたのと同じタスクを実行する。
【００６５】
関数RemCoActivateObject は、そのクラスのIClassFactory インタフェースの代わりに既存のオブジェクト・インスタンスのリクエストされたインタフェースを返す点を除いて、図３で述べた関数RemCoActivateClassObjectと同様のタスクを実行する。ステップ621 で、オブジェクトがすでに実行されている（そのインスタンス・データを暗示するものがすでにロードされている）ならば、関数はステップ625 に進み、そうでなければステップ622 に進む。ステップ622 において、関数は、リクエストされたクラス識別子に対応するIClassFactory インタフェースを発見する。ステップ623 で、関数は、このIClassFactory インタフェースを用いて、リクエストされたオブジェクトのインスタンスを生成する。ステップ624 において、関数は、クライアント・プログラム・リクエストで指定されたパスまたはストレージ・オブジェクトから、オブジェクト・インスタンス・データをロードする。ステップ625 で、関数は、リクエストされたインタフェースをパケットにマーシャルする。ステップ626 において、関数は、このパケットを、サーバ・サービス制御マネージャ613 に返す。このパケットは、図３に示すようにクライアント・プログラム601 に転送される。
【００６６】
［オブジェクト・インスタンスの生成およびアクセス］
図17は、オブジェクトのインスタンスの生成および生成されたオブジェクト・インスタンスのアクセスのための通信パスのフローチャートである。この通信パスは、異なるクライアント・プログラムおよびオブジェクト・サーバ・コードの関数が呼び出される点を除いて、図16に示すものと基本的に同じである。また、サーバ・サービス制御マネージャ713 とオブジェクト・サーバ・コード720 のいずれも、リクエストされたオブジェクトに対応する既存のインスタンスをチェックしない。なぜならば、この通信パスは、新しいインスタンスが各クライアント・プログラム・リクエスト用に生成されると仮定しているからである。一方、図３のように、関数SvcActivateObject は、リクエストされたクラス識別子に対応するIClassFactory の既存インスタンスをチェックし、サーバ・コードを不必要にスタートすることを回避する。もう一つの小さな相違点はステップ724 である。このステップ724 では、オブジェクトは、データをロードする代わりにデータ（もし提供されるならば）で初期化される。図17のステップ番号は、図16の同様のステップ番号に直接対応している。
【００６７】
［特定のセキュリティ・コンテキストでのサーバ・コードの呼び出し］
クライアント・プログラム・リクエストが、ある特定のオブジェクトまたはオブジェクト・クラスにアクセスするときに、図３、図16および図17に示すように、サーバ・サービス制御マネージャ（例えば、図17の713 ）またはクライアント・サービス制御マネージャは、もしローカルな実行が決定されているならば、図３、図16および図17のステップ16でサーバ・コードを呼び出すときに、パーシステント・レジストリのサーバ・プログラムによって指定されたセキュリティ・コンテキストを使用する必要がある。一実施例においては、サーバ・サービス制御マネージャは、安全なデータベースに格納されたパスワード情報を使用して、パーシステント・レジストリで指定されたユーザＩＤでサーバ・ノードにログ・オンする。続いて、サーバ・サービス制御マネージャは、そのセキュリティ・コンテキストのオブジェクト・サーバ・コードを実行する。セキュリティ・コンテキスト情報を記憶し、ある特定のコンテキストでオブジェクト・サーバ・コードを実行する多くの方法があることは、当業者ならば分かるであろう。他の実施例として、クライアント・プログラムが、そのプロセス環境を複製し（例えば、UNIXスタイルの環境における「フォーク」（fork）システム・コールを使用して）、サーバ・コードを実行することもできる。フォークされた（新しい）プロセスは、サーバ・コードを直接実行することもできるし、適切なユーザIDによりコンピュータ・システムにログ・オンし、サーバ・コードを実行することもできる。別の実施例として、各ロケーション・コンテキスト用に個別のセキュリティ・コンテキストを設けておくこともできる。
【００６８】
この発明を実施例により説明したが、この発明は、実施例に制限されるものではない。この発明の精神の範囲内での変更は、当業者ならば明らかであろう。この発明の範囲は、特許請求の範囲により定められる。
【図面の簡単な説明】
【図１】オブジェクトを表現するために使用される典型的なデータ構造体を示すブロック図である。
【図２】オブジェクトにアクセスするのに使用するクライアントノードおよびサーバノードの全体構成を示すブロック図である。
【図３】クラス・インスタンスにアクセスする通信パスのフローチャートである。
【図４】サーバ・コードを実行するためのロケーションを決定する関数DetermineServer のフローチャートである。
【図５】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図６】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図７】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図８】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図９】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図１０】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図１１】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図１２】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図１３】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図１４】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図１５】クライアント・プログラムによってリクエストされたロケーション・コンテキストを有するパーシステント・レジストリにおいて特定されたロケーション・コンテキスト情報を組み合わせるためのルールを規定する表である。
【図１６】既存オブジェクトの、ある特定のインスタンスにアクセスする通信パスのフローチャートである。
【図１７】オブジェクトのインスタンスを生成し、生成されたオブジェクト・インスタンスにアクセスするための通信パスのフローチャートである。
【符号の説明】
201 クライアント・プログラム
202 クライアント・サービス制御マネージャ
203 、207 登録データベース
204 クライアント・ノード
205 オブジェクト・サーバ・コード
206 サーバ・サービス制御マネージャ
208 サーバ・ノード
209 ロケーション・サービス／ファイル・サービス（ＤＦＳ）
【図１】
0003868013.tif 000006
【図２】
0003868013.tif 000007
【図３】
0003868013.tif 000008
【図４】
0003868013.tif 000009
【図５】
0003868013.tif 000010
【図６】
0003868013.tif 000011
【図７】
0003868013.tif 000012
【図８】
0003868013.tif 000013
【図９】
0003868013.tif 000014
【図１０】
0003868013.tif 000015
【図１１】
0003868013.tif 000016
【図１２】
0003868013.tif 000017
【図１３】
0003868013.tif 000018
【図１４】
0003868013.tif 000019
【図１５】
0003868013.tif 000020
【図１６】
0003868013.tif 000021
【図１７】
0003868013.tif 000022