JPH09506725A

JPH09506725A - オブジェクト指向ルール・ベース・プロトコル・システム

Info

Publication number: JPH09506725A
Application number: JP7516725A
Authority: JP
Inventors: ペタス，クリストファー，イー．
Original assignee: オブジェクトテクノロジーライセンシングコーポレイション
Priority date: 1993-12-17
Filing date: 1994-04-11
Publication date: 1997-06-30
Anticipated expiration: 2021-11-01
Also published as: EP0726004B1; DE69405405T2; EP0726004A1; CA2178583A1; DE69405405D1; WO1995017062A1; JP3839472B2; AU6702494A; US5548726A

Abstract

(57)【要約】オブジェクト指向ルール・ベース・プロコトル・システムが開示されている。マルチノード・クライアント・サーバ・ネットワークでは、クライアント・ノードは、ネットワークの各ノードに置かれている通信ディレクトリ・サービスを通してリモート・サービスへのアクセスを得ている。通信ディレクトリ・サービスはツリー構造を含んでおり、そこに既存のディレクトリ・サービスや他のネットワーク・サービスを追加することが可能になっている。ツリー構造は複数のノードをもち、その各々はそのアクションが基礎となるサービスによってサポートされていれば、関連のディレクトリ・サービスを照会(query)し、ブラウズ(browse)する特定のメソッドを含んでいる。通信ディレクトリ・サービスはさらに、ネットワーク上で提供される各サービスに関連づけられたサービス・オブジェクトをストアする共用ライブラリを含んでいる。サービス・オブジェクトの方は、サービス交換アドレスと通信リンク構成情報を含んでいる。リモート・サービスをアクセスしようとするクライアントは、適当なサービス・オブジェクトを通信ディレクトリ・サービスから検索し、そのサービス・オブジェクトを使用して通信パスをセットアップする。

Description

【発明の詳細な説明】オブジェクト指向ルール・ベース・プロトコル・システム著作権表記本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁に記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではない。その他の権利を一切所有することを明示に留保する。発明の分野本発明は一般的には分散コンピュータ・ネットワークに関し、より具体的には分散ネットワーク・ディレクトリとネーミング・サービスに対するルール・ベース・プロトコル処理に関する。発明の背景パーソナル・コンピュータやミニ・コンピュータなどの、独立型でローカル化されたデータ処理デバイスによるデータ処理が急成長していることに伴って、データ・ネットワークは物理的に切り離されたデバイスを互いに結合し、ネットワークに接続された種々のデバイス間でディジタル通信を行なうことを可能にするまで発展している。ネットワークには、ローカル・エリア・ネットワーク(local area network - ＬＡＮ）と広域ネットワーク（wide area network - ＷＡＮ）を含めて、数種類のものがある。ＬＡＮは限定エリア・ネットワークであり、ＬＡＮに接続されたデータ・デバイスは同一建物内に置かれているのが一般である。代表的なＬＡＮは同軸ケーブルや撚り対線(twisted pair)のように、種々のコンピュータ、サーバ、プリンタ、モデム、その他のディジタル・デバイスを互いに結合する伝送媒体から構成されている。これらのデバイスは「ノード」と総称され、各々はノードを一意的に識別するアドレスで伝送媒体に接続され、データをあるノードから別のノードへルート(route)するために使用されている。資源とサービスを提供するノードは「サーバ(server)」ノードと呼ばれ、これらの資源とサービスを利用するノードは「クライアント(client)」ノードと呼ばれている。ＷＡＮはもっと大きなエリアを取り囲んでいるのが一般で、電話回線などのコモン・キャリア接続を含んでいる場合もある。ＬＡＮとＷＡＮは、様々な構成で互いに結合されて、異なる建物やロケーション間を結んでいる場合や、大陸全体に渡っている場合もある「エンタープライズ」ネットワークを構築することがよくある。エンタープライズ・ネットワークが便利である理由には、いくつかある。このネットワークは資源共用を可能にする。つまり、プログラム、データおよび機器は、資源とユーザの物理的ロケーション（所在）に関係なく、ネットワークに接続されたすべてのノードが利用できる。また、エンタープライズ・ネットワークでは、複数のデータ・ソースを重複して使用可能にしておくことにより信頼性も得られる。例えば、重要なデータ・ファイルは複数のストレージ（記憶）デバイスに複製しておくことができるので、例えば、機器障害が原因でファイルの１つが使用不能になっても、重複ファイルを使用することができる。エンタープライズ・ネットワークの最も重要な特徴の１つは、ネットワークに接続されたユーザのすべてに大規模で、高度のサービス・セットを妥当なコストで提供できる能力をもっていることである。しかし、ユーザがネットワークの潜在能力を活用するためには、ユーザはネットワーク資源を識別し、そこに位置づけて、アクセスできなければならない。ネットワークが小規模のときは、使用できる資源に位置づけて、アクセスすることは比較的単純であるが、ネットワークは成長して大きくなり、現在では、非常に大規模なネットワークが多数存在する。何千のノードからなるネットワークは普通であり、何百万のノードからなるネットワークが出現する見通しもある。大規模ネットワークの例として、INTERNET（インターネット）ネットワークがあるが、これは大きな公共機関や私企業で利用されている。この種のネットワークがもつ能力の多くは、ユーザが使用できる機能にユーザが気づいていないか、あるいは機能にアクセスする方法が困難であるか、紛らわしいという単純な理由で未使用のままになっている。その結果、ユーザがネットワーク資源に位置づけて、アクセスするのを容易にするために、多くの既存ネットワークは現在では、ユーザから資源識別子または資源名を受け取り、所望のネットワーク資源に対応するネットワーク・アドレスに位置づけるネットワーク・ディレクトリまたはネーミング・サービスを利用している。例えば、入力される識別子または名前は「記述的」にすることができ、他の資源と区別できるだけの十分な属性を記述することにより資源を指定する。このような記述名はネットワークをサーチして、ある特定基準に一致する資源を探し出す人間のユーザにとっては非常に役立つが、これらの名前は最大のコンピューティング資源も必要とし、効率よく分散化することが困難である。現在、このような記述名サービスに関する標準がいくつか存在する。例えば、国際電信電話諮問委員会(Consultative Committee on Informational Telephony and Telegraphy -ＣＣＩＴＴ）および国際標準化機構(International Standards Organization - ＩＳＯ）は、X.500と呼ばれる記述名サービスに関する規格を開発した。ネーミングとディレクトリ・サービス（これらは以下「ディレクトリ・サービス」と総称することにする）は、現在種々の方法で実現されている。最も単純な実現方法では、名前および対応するネットワーク・アドレスのリストを収めておくために、ローカル・サーバ・ノードに置かれている単一の集中型データベースを使用している。このようなローカル化ディレクトリ・サービスの例は図１に示されている。図１は、複数のクライアント・ノード１０６，１０８，１２０，１２２，１２８よりなる「クライアント−サーバ」構成に配置されたコンピュータ・ネットワークを示している。これらのクライアント・ノードは、例えば、ワークステーション、パーソナル・コンピュータ、ミニコンピュータまたは他のコンピューティング・デバイスになっており、そこではアプリケーション・プログラムが実行され、リンク１０２，１１０，１１６，１２６，１３６を含む種々のネットワーク・リンクを通して相互に通信し、またノード１００，１１２，１２４，１３２，１３８などのサーバ・ノードと通信している。サーバ・ノードには、クライアント・ノードの全部または一部にサービスまたはサービス・セットを提供できる専用化ハードウェア・デバイスとソフトウェア・プログラムが置かれている。クライアント・ノードは、サーバ・ノードから提供される種々のネットワーク・サービスのユーザである。代表例として、集中型ディレクトリ・サービス・データベース１０４は、ノード１００のような、サーバ・ノードの１つに置かれている。クライアント・ノード、例えば、クライアント・ノード１０８は、サーバ・ノード１００と接続し、資源識別子または資源名を入力し、関連サービスのネットワーク・アドレスを検索することによりディレクトリ・サービスにアクセスすることができる。従来のデータベース手法によると、クライアント・ノードはデータベース上をサーチして特定の資源に位置づけることが可能になっている。さらに、多くのディレクトリ・サービスは部分名記述、「ワイルドカード(wild card)」およびプレースホルダ(placeholder)を使用してブラウズ(browse)することをサポートしている。単一データベースによるこの種の集中型ディレクトリ・サービスは、ネットワーク・アドレスが少数である小規模ネットワークでは有効である。しかし、大規模ネットワークでは、すべての資源識別子を中央の一か所に置いておくことは事実上不可能である。さらに、単一データベースはネットワーク全体を使用不能にできる単一の障害ポイントを表わす。さらに、集中型データベースは貧弱なパフォーマンスという欠点をしばしばもつ。例えば、クライアント１０８のようなローカル・クライアントがサーバ１００と接続してデータベース１０４をアクセスすることは比較的効率的であるが、クライアント１２０のようなリモート・クライアントは、「ゲートウェイ」リンク１１６と共に、いくつかのサーバ１２４，１１２を経由してリンクしなければならないので、大量のネットワーク・オーバヘッドが発生し、システム全体のアクセス「コスト」が高くなる。リモート・アクセスの試みが多くなると、ディレクトリ・サービス・プロバイダはネットワーク全体にわたって直ちに処理ボトルネックと通信ボトルネックになってしまう。上記問題を解消するために、データベース・データを複数のロケーションに分散化する別の従来手法が開発されている。このようなシステムが図２に概略図的に示されている。図２はクライアント・サーバ型のネットワークを示しているが、これは図１に示したものと似ている。具体的には、これらの２つの図で対応するエレメントは対応する参照符号が付いている。例えば、図１のクライアント１０８は図２のクライアント２０８と類似している。これらの２つのネットワークの違いは、ディレクトリ・サービス・データベースがいくつかのサーバ・ノードに重複して置かれていることである。例えば、サーバ・ノード２００には、サーバ・ノード２１２（データベース２１４）、サーバ・ノード２３２（データベース２３０）およびサーバ・ノード２２４（データベース２１８）と同じように、ディレクトリ・サービス・データベース２０４が置かれている。データを重複してデータベースの各々に置いておく従来方法はいくつか知られている。あるシステムでは、各資源識別子を個別的に重複して各データベースに置いている。他のシステムでは、データベース全体を重複している。さらに、他のシステムでは、個別的ノードを重複するか、あるいはデータベースをなんらかの方法で分割して重複を制限している。図２に示す分散システムは、集中型データベースに関連する問題を防止している。データは重複されているので、障害ポイントは一か所でない。また、データは近くのサーバ・ノードで通常使用可能であるので、「リモート」クライアント・ノードというものがなく、ネットワーク・オーバヘッドが大幅に軽減されている。しかるに、分散システムには独自の問題がある。例えば、複数のソースがデータベースを更新する可能性のあるときは、なんらかの方法を使用してデータ整合性(data consistency)を保証しなければならない。あるシステムでは、データ整合性を保つために、データのすべてのコピーが従来のデータベース・システムと同じように、緊密に同期を保つようにしている。他のシステムでは、従来の同時実行調停方式(concurrency arbitration scheme)を用いてデータ保全性(data in tegrity)を保証している。このようなネーミングおよびディレクトリ・サービスは、同じアクセス方式とプロトコルがネットワーク全体にわたって適用されるような同種ネットワークでは効果的である。この場合には、整合性のある名前とルールのセットが開発されて、種々の資源の位置づけとアクセスを比較的容易にできる。しかし、多くの大規模ネットワークは異種ネットワークである。つまり、ネットワークは、ワーク・ステーション、パーソナル・コンピュータ、ミニコンピュータ、スーパコンピュータ、メインフレームといったように、多種類の異なるコンピュータを含んでいるだけでなく、ネットワーク自体は、「ゲートウェイ」と呼ばれるインタフェースを通して互いに結合された多数の独立型小規模ネットワークから構成されている。これらの小規模ネットワークは独自のアクセス方式とプロトコルをもっていることがある。さらに、これらの大規模ネットワークの異種構造と編成は、共通の方式とプロトコルを指図できる中央制御と管理には力を貸さない。互いに結合された小規模ネットワーク群から構成された多数の大規模ネットワークでは、基礎となる個別ネットワークの各々は、特定のプロトコルを使用する独自の異なるディレクトリ・サービスをもっている。このタイプのネットワークでは、ユーザは各ネットワーク・ディレクトリ・サービス・プロトコルに精通している必要があり、サーチがあるネットワークから次のネットワークへ実行されるとき、あるプロトコルから別のプロトコルへ移る必要がある。その結果、このような異種ネットワークでは、ネットワーク資源をアクセスすることを困難にしている主要問題の１つは、詳細および、これらの個別ネットワークの各々にアクセスするときに関連するプロトコルにユーザがとらわれることなく、異種ネットワーク上で動作可能なネットワーク資源の整合性のあるグローバル・アクセス可能なディレクトリが欠如していることに起因している。今日のネットワーキング・サービスは種々のプロトコル・システムをもっている。従来技術では、アプリケーションは、ネットワーキングのプロトコル・アーキテクチャに関する詳細情報を含んでいなければならなかった。この要件がアプリケーションを特定のプロトコルに結びつけていた。アプリケーションはソース・コードを変更しないとプロトコルの変更をサポートできないために、これはネットワークを動的に構成することを妨げていた。以上に鑑みて、本発明の目的はアプリケーションがサービスのタイプと品質を指定できるようにすることである。発明の概要本発明の一実施例によれば、ルール・ベース・プロトコル選択メカニズムが該当のプロトコル構成をサービスのタイプと品質に基づいて選択することにより、上述した問題を解決し、上述した目的を達成している。各プロトコル・ファミリごとに、ルール・セットが定義され、サービスのタイプと品質を特定の共通プロトコル・セットに変換するようにしている。図面の簡単な説明本発明の上記およびその他の利点は、添付図面と関連して以下の説明を参照することによりもっと理解しやすくなる。添付図面において、図１は、ローカル・ディレクトリ・サーバを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。図２は、分散ディレクトリ・サーバを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。図３は、本発明によるオブジェクト指向印刷インタフェースが動作しているコンピュータ・システム、例えば、パーソナル・コンピュータ・システムを示す概略ブロック図である。図４は、本発明による通信ディレクトリ・サービスを取り入れているクライアント・サーバ・ネットワークを示す概略ブロック図である。図５は、国際標準化機構の７層モデルに準拠して２ノード構造間でデータを伝送するために使用される従来のプロトコル・スタックの詳細を示す概略ブロック図である。図６は、通信ディレクトリ・サービスの主要コンポーネントを示す概略図である。図７は、種々のディレクトリ・サービスと他のネットワーク・サービス上でブラウズを可能にするディレクトリ・ツリーのセットアップ例を示す概略図である。図８はサーバ・ノードの主要コンポーネントを示す概略ブロック図であり、サービス・プログラムが通信ディレクトリ・サービスとやりとりする様子を示している。図９は、新サービスをネットワーク上で使用可能にするときに伴うステップを示す簡略フローチャートである。図１０は、サービス・オブジェクトをアクチベートするためにサービス・プログラムによって実行されるステップを示す展開されたフローチャートである。図１１は、クライアント・ノードの主要コンポーネントを示す概略図であり、アプリケーション・プログラムが通信ディレクトリ・サービスとやりとりしてサービスをアクセスする様子を示している。図１２は、ネットワーク上で使用可能なサービスをアクセスするときに伴うステップを示す簡略フローチャートである。図１３は、サービス・オブジェクトをアクチベートするためにサービス・プログラムによって実行されるステップを示す展開されたフローチャートである。実施例の詳細な説明本発明は、好ましくは、ＩＢＭ（登録商標）PS/2（登録商標）またはアップル（登録商標）マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータに常駐したオペレーティング・システムを背景に実施される。図３は代表的なハードウェア環境を示しもので、本発明によるコンピュータ３００の代表的なハードウェア構成を示していてる。コンピュータ３００は中央処理ユニット３０２によって制御されるが、このユニットは従来のマイクロプロセッサにすることが可能である。いくつかの他のユニットはすべてがシステム・バス３０８を介して相互に接続され、特定のタスクを成し遂げるために用意されている。特定のコンピュータは、図３に示すユニットの一部だけを備えていたり、図示していない付加的な構成要素を含んでいたりする場合があるが、大部分のコンピュータは、少なくとも図示のユニットを含んでいる。具体的には、図３に示すコンピュータ３００は、情報の一時記憶域のためのランダム・アクセス・メモリ（ＲＡＭ）３０６、コンピュータの構成と基本的操作コマンドの永久記憶装置のためのリードオンリ・メモリ（ＲＯＭ）３０４、およびディスク・ユニット３１３やプリンタ３１４などの周辺デバイスを、それぞれケーブル３１５と３１２でバス３０８に接続するための入出力（Ｉ／Ｏ）アダプタ３１０を含んでいる。ユーザ・インタフェース・アダプタ３１６も提供されているが、これはキーボード３２０などの入力デバイス、およびマウスやスピーカ、マイクロホンを含む他の公知インタフェース・デバイスをバス３０８に接続するためのものである。ビジュアル出力は、バス３０８をビデオ・モニタなどのディスプレイ・デバイス３２２に接続しているディスプレイ・アダプタ３１８から提供される。ワークステーションは、常駐のアップル・システム／７（登録商標）オペレーティング・システムなどのオペレーティング・システムを有し、それにより制御と調整をされている。好適実施例では、本発明は、オブジェクト指向プログラミング技法を用いてＣ ++プログラミング言語で実現されている。Ｃ++はコンパイル型言語である。つまり、プログラムは人間が読むことのできるスクリプト(script)で書かれ、このスクリプトはコンパイラと呼ばれる別のプログラムに渡される。コンパイラはマシン可読(machine-readable)の数値コードを生成し、このコードはコンピュータにロードされ、コンピュータによって直接に実行される。以下で説明するように、Ｃ++言語はいくつかの特徴をもっている。これらの特徴によると、ソフトウェア開発者は他の人が書いたプログラムを容易に使用できると共に、プログラム再使用の管理を強化してプログラムの破壊や誤った使い方を防止することができる。Ｃ++言語は周知であり、この言語を詳しく説明した論文や文献は多数利用可能である。さらに、Ｃ++コンパイラは、Borland International，Inc.、Microsoft C orporation などの数社から市販されている。そのために、混乱を避けるために、ここでは、Ｃ++言語の詳細とＣ++コンパイラの操作について詳しく説明することはしないことにする。この分野に精通した当業者ならば理解されるように、オブジェクト指向プログラミング（Object-Oriented Programming - ＯＯＰ）技法は、「オブジェクト」の定義、生成、使用、消滅を含む。これらのオブジェクトはデータ・エレメント (data element - データ要素)と、データ・エレメントを操作するルーチン、または、関数(function)とからなるソフトウェア・エンティティ(software entity )である。データおよび関連の関数は、エンティティとしてソフトウェアによって取り扱われ、あたかも単一のアイテムであるかのように生成し、使用し、削除することができる。データと関数は共に、データ・エレメントで表わすことができるその特性と、そのデータ操作関数で表わすことができるその動作(behavior) により、どのような実世界のエンティティでもオブジェクトにほとんどモデル化させることができる。このようにして、オブジェクトは人やコンピュータなどの具体物をモデル化することも、数や幾何学的デザインなどの抽象的概念をモデル化することもできる。それ自体はオブジェクトではないが、実際のオブジェクトの構築方法をコンパイラに指示するテンプレートの働きをする「クラス」を作成することにより、オブジェクトは定義される。クラスは、例えば、データ変数の個数とタイプおよびデータを操作する関数におけるステップを指定することができる。オブジェクトは、実際には、「構築子(constructor)」と呼ばれる特殊な関数を使用してプログラムの中で生成される。このコンストラクタは、対応するクラス定義と、オブジェクト生成の間オブジェクトを構築するために用意される引数などの対応する追加情報を使用する。同じように、オブジェクトは「消滅子(destructor)」と呼ばれる特殊な関数によって消滅される。オブジェクトはそのデータを操作しその関数を呼び出す(invoke)することにより使用できる。オブジェクト指向プログラミング技法の主な利点は３つの主要原理である、カプセル化(encapsulation)、多様性(polymorphism)および継承(inheritance)によるものである。具体的には、オブジェクトは、内部データ構造および内部関数のすべてまたは一部を隠蔽するように、または、カプセル化するように設計することができる。もっと具体的に説明すると、プログラム設計期間に、プログラム開発者は、データ変数のすべてまたは一部および関連の関数のすべてまたは一部が、「プライベート(private)」、または、そのオブジェクト自身だけに使用されるものと考えられるようなオブジェクトを定義することができる。他のデータまたは関数は、「公開(public)」、または、他のプログラムが使用できるものと宣言することができる。他のプログラムによるプライベート変数へのアクセスは、あるオブジェクトのプライベート・データをアクセスする公開関数を、そのオブジェクトのために定義することにより制御することができる。公開関数は、プライベート・データと「外部」世界との間の、制御された整合性のあるインタフェースとなっている。プライベート変数を直接にアクセスするプログラム・コードを書くようなことをすると、コンパイラはプログラムのコンパイル時にエラーを発生し、このエラーが起こると、コンパイル・プロセスは停止し、プログラムの実行を妨げる。多様性とは、全体的フォーマット（形式）は同じであるが、取り扱うデータが異なっているオブジェクトと関数が異なった働きをして、整合性のある結果を作り出すようにする概念である。例えば、加算(addition)関数は、変数Ａプラス変数Ｂ(A＋B)と定義することができ、ＡとＢが数であるか、文字であるか、またはドルとセントであるかに関係なく、同じフォーマットを使用することができる。しかし、加算を実行する実際のプログラム・コードは、ＡとＢを含む変数のタイプによって大幅に異なることがある。多様性は、変数の各タイプ（数と文字とドル）ごとに１つといったように、３つの別々の関数定義を書くことを認める。関数を定義したあと、プログラムは、その共通フォーマット(A＋B)によって加算関数をあとで参照することができ、コンパイル時には、Ｃ++コンパイラは３つの関数のどれが実際に使用されているかを、変数のタイプを調べることにより決定する。そのあと、コンパイラは正しい関数コードを代入する。多様性は、類似の結果を作り出す類似の関数がプログラム・ソースの中で「グループ化」されて、より論理的で明確なプログラムの流れを作り出すことを認める。オブジェクト指向プログラミングの基礎となる第３の原理は継承であり、これは、プログラム開発者が既存のプログラムを容易に再使用できるようにし、ソフトウェアを初めから作成することを回避させる。継承の原理によると、ソフトウェア開発者は、クラス（およびそのクラスからあとで作成されるオブジェクト）を相互に関係づけて宣言することができる。具体的には、クラスは他の基底クラス(base class)のサブクラスとして指定することが可能である。サブクラスは、その関数がサブクラスにあらわれるかのようにその基底クラスの公開関数のすべてを「継承」し、アクセスする。あるいはまた、サブクラスは継承した関数の一部または全部をオーバライド(override)することこともできるが、同じフォーマットをもつ新しい関数を定義するだけで継承関数の一部または全部を変更することも可能である（オーバライドまたは変更を行っても、基底クラスの関数は変更されず、サブクラスでの関数の使い方が変更されるだけである）。別のクラスの機能の一部を（選択的に変更を加えて）もつ新しいサブクラスを生成すると、ソフトウェア開発者は既存のコードを開発者独自の要求に合わせてカストマイズすることが容易になる。オブジェクト指向プログラミングは他のプログラミングの概念を大幅に改善しているとはいえ、特に、変更の対象となる既存のソフトウェア・プログラムが使用可能でない場合には、それでもなお、プログラム開発に大量の時間と作業量が必要となっている。その結果、従来のアプローチでは、オブジェクトと雑多な追加ルーチン群を生成する、事前に定義され、相互に関連をもつクラス群をプログラム開発者のために用意しているが、これらはすべてが、共通に出くわすタスクを特定の環境で実行することを目的としている。このような事前定義のクラスとライブラリは、「アプリケーション・フレームワーク(application framework) 」と呼ばれているのが代表的であり、基本的には、稼働アプリケーションのためのプレハブ構造(pre-fabricated structure)を提供している。例えば、ユーザ・インタフェースのアプリケーション・フレームワークには、ウィンドウやスクロールバー、メニューなどを生成する事前定義のグラフィック・インタフェース・オブジェクト群が用意され、これらのグラフィック・インタフェース・オブジェクトに対するサポートが用意され、その「デフォルト（省略時）」の動作(behavior)が用意されている場合がある。アプリケーション・フレームワークはオブジェクト指向の技法に基づいているので、事前定義のクラスを基底クラスとして使用することができ、また、組み込まれたデフォルトの動作を開発者が定義したサブクラスによって継承し、これらを変更またはオーバライドすることにより、開発者はフレームワークを拡張し、特定の専門知識分野においてカストマイズした解決手法を生成することができる。このオブジェクト指向による解決手法が、従来のプログラミングに比べて大きな利点となっているのは、プログラマはオリジナル・プログラムを変更するのではなく、むしろオリジナル・プログラムの能力を拡張するからである。さらに、開発者がコードの層全体にわたって盲目的に作業しないのは、フレームワークにはアーキテクチャ上のガイダンスとモデリングが用意されており、それと同時に、開発者は問題領域に特有の特定のアクションを供給することから解放されるからである。必要とされるシステムのレベルおよび解決しようとする問題の種類に応じて、アプリケーション・フレームワークは多種類のものが使用可能である。フレームワークのタイプは、ユーザ・インタフェースの開発を支援するハイレベル・アプリケーション・フレームワークから、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的システム・ソフトウェア・サービスを提供する低レベル・フレームワークまでの範囲にわたっている。市販されているアプリケーション・フレームワークの例を挙げると、MacApp(Apple)、Bedrock(Symantec) 、OWL(Borland)、NeXT Step App Kit(NeXT)、Smalltalk-80 MVC(ParcPlace)などがある。アプリケーション・フレームワークによる解決手法では、カプセル化、多様性、および継承のすべての原理をオブジェクト層に利用し、他のプログラミング技法を大幅に改善しているが、いくつかの困難な問題も起こっている。これらの困難な問題は、開発者が自身のオブジェクトを再使用することは容易であるが、他のプログラムによって生成されたオブジェクトを開発者が使用することが困難であることから起こっている。さらに、アプリケーション・フレームワークはモノリシック(monolithic)・オペレーティング・システムに上乗せされた１つまたは２つ以上のオブジェクト「層」から構成されているのが一般であり、オブジェクト層に柔軟性がある場合であっても、面倒な手続型コール(procedural call)を通して、基礎となるオペレーティング・システムと直接にやりとりする必要がしばしば起こっている。アプリケーション・フレームワークがアプリケーション・プログラム用のプレハブ機能を開発者のために用意しているのと同じように、好適実施例に含まれているようなシステム・フレームワークは、開発者が変更またはオーバライドすることによりカスマイズした解決手法を作成できるシステム・レベルのサービス用のプレハブ機能を提供することができ、従来のアプリケーション・フレームワーク・プログラムで必要であった面倒な手続型コールを避けることができる。例えば、アプリケーション・プログラムによって生成された印刷可能情報の、自動ページ付け、プリプリント処理およびページ構成の土台を提供できる印刷フレームワークについて考えてみることにする。アプリケーション・ソフトウェア開発者がこれらの機能を必要とするときは、通常は、その機能を提供するための特定のルーチンを書く必要があった。これをフレームワークを使用して行う場合は、開発者は最終的出力の特性と動作を用意するだけでよいのに対し、フレームワークは、これらのタスクを実行する実際のルーチンを提供する。好適実施例では、フレームワークの概念を取り入れ、アプリケーションとオペレーティング・システムを含むシステム全体にこの概念を適用している。商業ベースまたは企業の開発者、システム・インテグレータ、またはＯＥＭにとっては、このことは、MacAppなどのフレームワークに関して上述した利点のすべてが、テキストやユーザ・インタフェースなどの事物についてアプリケーション・レベルにおいてのみならず、プリント、グラフィックス、マルチメディア、ファイル・システム、入出力（Ｉ／Ｏ）、テストなどのサービスについてはシステム・レベルでも梃入れできることを意味する。図４は、本発明の主題である本発明の通信ディレクトリ・サービスを提供している、図１と図２に示すクライアント−サーバ・ネットワークの概要を示す図である。図２と図４を比較すると分かるように、全体的ネットワーク構成はどちらのネットワークの場合も同じであるが、本発明の通信ディレクトリ・サービスが図４に示すように使用されるときは、ノードはすべてが通信ディレクトリ・サービス（ＣＤＳ）・モジュールを含んでいる。具体的には、サーバ・ノード４００，４１２，４２４，４３２，４３８は、それぞれ本発明の通信ディレクトリ・サービス・モジュール４０５，４１３，４２５，４３０，４３９を含んでいる。さらに、サーバ・ノードはいずれかが、あるいはすべてが従来のディレクトリ・サービス４０４，４１４，４１８，４３０をそれぞれ含むことも可能である。従来のディレクトリ・サービスは、通信ディレクトリ・サービスと区別するために、以下では物理ディレクトリ・サービスと呼ぶことにする。サーバ・ノードに加えて、クライアント・ノード４０６，４０８，４２０，４２２，４２８（それぞれＤＣＳ４０７，４０９，４２１，４２３，４２９）の各々も、通信ディレクトリ・サービスを含んでいる。以下で詳しく説明するように、図４に示すようなエンタープライズ・ネットワークでは、あるノードから別のノードへ送られる情報は、一般に離散的メッセージまたは「パケット」に分割され、これらのパケットは事前定義のプロトコルに従ってノード間で伝送される。ここで言う「プロトコル」とは、別々のノードがどのようにサポートされて、相互にやりとりするかを定義したルール（規則）またはプロシージャ（手順）の集まりからなっているものである。設計の複雑さを軽減するために、大部分のネットワークは一連の「層」または「レベル」で編成されるので、あるノードから別のノードへ渡される情報が層から層へ伝送されるようになっている。各層内では、あらかじめ定義したサービスまたはオペレーションが実行され、層はあらかじめ定義されたプロトコルに従って相互に通信し合っている。層化的な設計の目的は、ある層が、標準化インタフェースを通して他の層へ選択されたサービスを提供することを可能にすると共に、ある層内の実際のインプリメンテーション（実装）の詳細が他の層から見えないようにすることである。以下で詳しく説明するように、クライアント・ノードとサーバ・ノードはどちらも、通信ディレクトリ・サービス・モジュールと共同作用してネットワーク層を構成し、ネットワーク層の方は、クライアントとサーバ間の接続のタイプとパラメータを、提供されるサービスのタイプに従って制御する。ネットワーク・アーキテクチャ（ネットワークで使用される層とプロトコルの集まりの全体名）を標準化する試みとして、一般化されたモデルが国際標準化機構（ＩＳＯ）によって提案されているが、これは現在使用されている種々のプロトコルを国際的に標準化する第一歩となるものである。このモデルは、開放型システム間相互接続（open sytems interconnection - ＯＳＩ）参照モデルと呼ばれているが、これは他のシステムとの通信用に「開放」されているシステムの相互接続を扱っているためである。提案されたＯＳＩモデル案は７層からなり、（相互に作用し合う順に）「物理」層、「データリンク」層、「ネットワーク」層、「トランスポート」層、「セッション」層、「プレゼンテーション」層、「アプリケーション」層と名づけられている。ＯＳＩモデルの目的は、各層内で処理されるプロセスを標準化することである。ＯＳＩモデルによれば、物理層で実行されるプロセスは、未処理(raw)データ・ビットの通信チャネル上の伝送を扱っている。データ・リンク層で実行されるプロセスは未処理データ・ビット・ストリームを操作し、それを見かけ上伝送エラーのないデータ・ストリームに変換する。後者のタスクは伝送データをデータ・フレームに分割し、そのあとにエラーを検出または訂正するエラー訂正メカニズムを付けてフレームを順次に伝送することにより行われる。ネットワーク層プロセスは、データ・パケットをデータ・ソースからデータ・デスティネーションへどのようにルートする(route)かを、ネットワークを通る多数の代替経路から１つを選択することにより判断する。トランスポート層プロセスの機能は、セッション層からデータ・ストリームを受け取り、それをもっと小さな単位に分割し（必要な場合）、その小さな単位をネットワーク層へ渡し、順序エラー、重複または紛失データなしで、デスティネーションに正しくすべて到着したことを保証する適当なメカニズムを提供することである。セッション層プロセスは、異なるマシンにいるユーザが相互間で「セッション」または「会話(dialogue)」を確立することを可能にする。セッションは通信し合うノード間で通常データのトランスポートを可能にするが、ある種のアプリケーションでは、会話制御、トークン管理と同期化などの機能強化サービスも提供する。プレゼンテーション層は要求頻度の高いある種の共通機能を実行して、例えば、データを標準フォーマットへのコード化、暗号化と解読の実行、その他の機能の実行といった、一般的解決法を見つけることを保証する。最後に、アプリケーション・プロトコル層は、データベース・アクセス、ファイル転送などの、共通に必要になる種々のプロトコルを含んでいる。例えば、図５は、ＯＳＩ標準の７層アーキテクチャに準拠して２つのノード間を接続するために使用される従来技術のプロコトル・スタックを示す図である。ＯＳＩ標準によれば、ノードの各プロトコル・スタックは７層からなっている。例えば、クライアント・ノード４０８のスタック５２８は、アプリケーション層５００、プレゼンテーション層５０２、セッション層５０４、トランスポート層５０６、ネットワーク層５０８、データリンク層５１０および物理層５１２からなっている。これらの層の各々のオペレーションと目的は前述した通りである。同様に、サーバ・ノード４３２のスタック５３２は層５１４〜５２６からなっている。実際のデータ通信は２つの物理層５１２と５２６間でデータ・リンク５３０を通して行われるが、スタックが図５に示すような配置になっているときは、各層は、ある層と同じレベルにある層である「ピア(peer)」と通信していると考えることができる。例えば、アプリケーション層５００と５１４は、情報が層５０２〜５１２のすべてを通過し、データ・リンク５３０を経由し、層５１６〜５２６を通って戻る場合でも、直接に通信していると考えることができる。同様に、プレゼンテーション層５０２と５１６はピアツーピア(peer-to-peer)で通信することができる。図５に示すようなプロトコル・スタックは、複数のデータ・バッファを使用して実現されているのが代表的である。各データ・バッファは、そこで処理が行われるプロトコル層を構成している。ある層で処理が完了したあと、データを別のバッファへ転送して、別の層に従ってさらに別の処理を行うことができる。本発明がもつ一側面によれば、ネットワーク内でピアツーピア通信を制御するプロトコル・スタックは、通信ディレクトリ・サービスにストアされたスタック定義によって構成される。これらのスタック定義は、ネットワークで使用できる各サービス・タイプと関連づけることできるので、アプリケーション・プログラムからのサービス要求に応答してプロトコル・スタックを動的に構成することができるようになっている。通信ディレクトリ・サービスの詳細図は図６に示されている。モジュールは３つの主要コンポーネントからなっている。ネットワークから提供される物理ディレクトリ・サービスと他のサービスの各々を、従来のツリー探索手法を用いて位置づけることを可能にする階層ディレクトリ・ツリー６０２と、クライアントがあらかじめ指定した通信リンク上にリモート・サーバ・ノードからのデータを要求できるようにする動的再構成可能スタックをプログラミングするために使用されるスタック定義オブジェクトの集まり６０４と、「サービス・オブジェクト」の集まり６０６とである。各サービス・オブジェクトは、ネットワーク上で使用できる１つのサービスと関連づけられ、そのサービスが使用可能なネットワーク・アドレスまたは交換アドレスと、スタック定義オブジェクト６０４の１つまたは２つ以上へのリファレンス（参照）６０８とを含んでいる。以下で詳しく説明するように、これらのサービス・オブジェクトの１つへのリファレンスは、対応するサービスへのアクセスを望んでいるアプリケーション・プログラムによって取得される。このリファレンスで識別されたオブジェクトにおける情報は、通信経路をセットアップするために再構成可能スタックへ送られる。スタック定義６０４の各々は、各層で実行される処理と層間の相互作用を指定している層定義の集まりからなっている。スタック定義は、通信リンクがネットワーク・システムにインストールされるときに定義される。具体的には、スタック定義はシステム上の異種通信リンクごとに用意される。通信ディレクトリ・サービス６００には、ネットワーク上のユーザにとってそのオペレーションを特に便利なものにする特徴がほかにもいくつかある。具体的には、ディレクトリ・サービスは使用可能なサービスとディレクトリ・サービスに関する情報を、一連のオブジェクトとしてディレクトリ・ツリーにストアする。さらに、通信ディレクトリ・サービス内のストアされたライブラリはオブジェクトを含んでいるので、アプリケーション・プログラムとサービス・プログラムは共に、オブジェクトを通して通信ディレクトリ・サービスと直接に通信することができる。通信ディレクトリ・サービスはノードの各々に存在するので、クライアントはどのディレクトリ・サービス・サーバともディレクトリ・サービスを使用する前に接続する必要はない。そのかわり、オブジェクト自体がインタフェースとなるからである。さらに、サービス・オブジェクト６０６のような、あらかじめ定義されたオブジェクトの使用は、アプリケーション・プログラムが所望するサービスとの通信をオープンすることができる簡単な方法を提供する。アプリケーション・プログラムが実際の経路構造の詳細について気にする必要なしに、サービス・オブジェクトはネットワーキング・サービスへ直接に送られて通信経路をオープンできる。さらに、既存の物理ディレクトリ・サービスはいずれも、ディレクトリ・ツリー６０２のノード・オブジェクトにカプセル化されているので、物理ディレクトリ・サービスはクライアント・アプリケーションから完全に隠蔽され、クライアント・アプリケーションは、整合性のあるプロトコルとフィーチャ・セット(fea ture set)を使用して本発明の通信ディレクトリ・サービスと相互作用することができる。通信ディレクトリ・サービスに見られるディレクトリ・ツリー６０２の詳細図は図７に示されている。以下で詳しく説明するように、ディレクトリ・ツリーは単純なサーチ（探索）コマンドを使用して走査することができ、完全なブラウズ機能はワイルドカードとプレースホルダを使用により得られる。ディレクトリ・ツリーは、サーチの結果としてオブジェクトが返され、返されたオブジェクトのタイプがオブジェクトを返したディレクトリ部分のインプリメンテーションによって決定されるように設計されている。ディレクトリ・ツリーのサーチから返されるオブジェクトの例としては、リモート・サービスと接続するために使用される情報を含んでいる、図６に示すサービス・オブジェクト６０６へのリファレンス、ユーザに関するセキュリティと認証情報を含んでいるプリンシプル(princip le)オブジェクト、ユーザに関する情報のコレクションを含んでいる「ビジネスカード」およびプログラム開発者がディレクトリ・ツリーに追加できる他のクラスがある。ディレクトリ・ツリーは、図７に示すような単一階層ツリーの編成になっている。なお、図７に示すツリー構成は単なる例示であり、本発明の範囲と原理から逸脱することなく実際のツリー構成は図示の構成と大幅に異なることがある。ツリー内のノードの各々は"namespace" オブジェクトによって形成される。 namespace オブジェクトは他のnamespace オブジェクトを参照することも、またはサービスや他の物理ディレクトリ・サービスを直接に参照することもできる。ディレクトリ・ツリーの究極的なルートはルートnamespace オブジェクト７００である。ツリーのノードを形成するルートnamespace オブジェクト７００と他の namespace オブジェクトは、走査してノード・メンバを見つけることができる従来のツリー構造に挿入される。ルートnamespace オブジェクト７００のように、各ノード・オブジェクトは、ディレクトリ・サーチを容易にするメソッドを含んでいる。具体的には、これらのメソッドとしては、ディレクトリ内のすべてのエントリにわたってイテレータ (iterator)を返すサーチ・メソッド、namespace が参照しているエントリを返すメソッド、および与えられたプロパティ式にマッチするエントリを返すメソッドがある。下位レベル・ディレクトリ・ノードからルートnamespace を得るための別のメソッドを含めることも可能である。図７に示すツリー・ディレクトリでは、究極的なノードまたは「リーフ(leaf) 」ノードは物理ディレクトリ・サービスと他の使用可能ネットワーク・サービスである。これらのリーフ・ノードはnamespace オブジェクトでもあるので、これらには、関連ディレクトリ・プロトコルを返すメソッド、および物理ディレクトリと相互作用してディレクトリをサーチまたはブラウズするメソッドを含めることが可能である。リーフ・ノードの各々は関連サービスに合わせて個別に書かれたメソッドを含んでいるので、これらのメソッドは、関連サービスに含まれるプロトコル問題(protocol issue)を取り扱って、ユーザが、どのディレクトリ・サービスが含まれているかを問わず、整合性のある方法で通信ディレクトリ・サービスと相互作用できるようにする。例えば、図７において３つのノード７０４，７０６，７０８は、３つの別々の物理ディレクトリ・サービスと相互作用している。４番目のノード７１０もあるが、このノードは「ネーティブ」namespace ノードと名づけられている。この最後のノードはネットワークから提供されるサービスの各々へのリファレンスを含んでいる。以下で詳しく説明するように、各サービスをユーザが使用できるようにするために、これはネーティブnamespace ７１０に「登録」される。 namespace に「登録(registration)」するとは、サービスへのリファレンスを、ディレクトリを走査する人により見つけることができるディレクトリに挿入することである。基本的には、登録は、関連サービス・オブジェクトをストリーム化して、照会によってそれを見つけることができるネーティブnamespace に入れておくことからなる。サービスを登録することのほかに、リーフ・ノードに常駐したディレクトリまたは物理ディレクトリ・サービスの中のサービスを「パブリッシュ(publish)」することも可能である。パブリッシュと登録との違いは、パブリッシュでは、サービスに関する限定された情報がディレクトリ・ノードに挿入されることである。この限定された情報は、例えば、サービス名、サービスのタイプおよび接続アドレスで構成することができる。本発明の好適実施例では、ネーティブ(native) namespaceがパブリケーション(publication)を取り扱う。つまり、サービス・エンティティがネーティブnamespace に登録されるとき、ネーティブnamespace はそのエンティティを他のどのnamespace でパブリッシュするかを決定し、その決定に応じてパブリケーションを指示する。完全なブランチ機能を提供するためには、namespace ７０２のような中間name space を、ルートnamespace ７００とリーフ・ノード７０４〜７１０との間に挿入することが可能である。中間namespace は他のnamespace を参照している。前述したように、本発明の通信ディレクトリ・サービスはサービス・プログラムとアプリケーション・プログラムの両方と相互作用して、クライアントとサーバとの間で必要な通信リンクを透過的に(transparently)セットアップする。この相互作用では、サービス提供者による通信ディレクトリ・サービスにおけるサービス・オブジェクトの生成と、サーバ・ノードにおけるプロトコル・スタックの構成を含む。サービスのアクセスを所望するクライアントは関連サービス・オブジェクトを検索し、それを使用してプロトコル・スタックをクライアント・ノードに構成して通信リンクをセットアップする。図８〜図１０は、サーバ・ノードで稼働しているサービス・プログラムによって実行されて、クライアント・ノードで実行されているアプリケーション・プログラムにより使用できるように新しいサービスをネットワーク上で使用可能にするオペレーションを説明したものである。図８は、新サービスの生成とアクチベーションに含まれるサーバ・ノード・プログラムの部分を示す概略ブロック図である。図９は、サービス・プログラム、本発明の通信ディレクトリ・サービスおよびノード・ネットワーキング・サービスの間で相互作用して、新サービスを確立し、適当な通信リンク上で動作するようにネットワーキング・サービスを構成する手順を示したフローチャートである。図１０は、関連サービス・ブロックをアクチベートすることによって新サービスをアクチベートする様子を示す詳細ブロック図である。もっと具体的に説明すると、図８は、サービスをリモート・クライアントに提供するときのサーバ・ノードの基本的構成を示している。サーバ・ノードは共通エリア、または、システム・アドレス空間８００をもつ構成になっており、このアドレス空間には、オペレーティング・システム・プログラムと、システムで実行されるサービス・アプリケーションによって使用される種々の共有ライブラリが置かれている。具体的には、システム・アドレス空間８００には、通信ディレクトリ・サービス８０４およびネットワーキング・サービス・プログラムとライブラリ８１６が含まれる。サーバ・ノードには、独自のアドレス空間８１０で実行されるサービス・プログラムも置かれている。以下で説明するように、サービス・プログラム８０６は通信ディレクトリ・サービス８０４と相互作用してサービス・オブジェクトを作成し、これは通信ディレクトリ・サービス８０４に置かれる。このサービス・オブジェクトはこのシステム内の他のノードすべてに分散(distribute)されるので、ネットワーク上のクライアントのすべてに対してローカル・ベースでの使用ができる。サービス・オブジェクトはネットワーキング・サービス８１６を構成するための適当なスタック定義を含んでいるので、アプリケーション・プログラムは通信ディレクトリ・サービスと共に、以前にストアした定義を用いて構築の詳細においてクライアント・アプリケーション・プログラムの必要なしに、通信経路をセットアップすることができる。図９を参照して説明すると、新サービスの生成はステップ９００からスタートして、ステップ９０２へ進む。ステップ９０２で、サービス・プログラムの開発者は、新サービスに適当な構成パラメータを含んでいる新サービス・オブジェクトの生成を動作可能にする。これは、ディレクトリ・サービスに置かれているサービス・オブジェクト・クラスをサブクラス化することにより行うことができる。具体的には、新サービス・オブジェクト・クラスを生成するために、サービス・プログラム開発者はそのサービスの一意的な名前(unique name)、サービスのタイプ、およびオプションとして、サービスをアクセスするとき使用できる種々の通信リンク・タイプを指定する。通常のオブジェクト指向プログラミング言語のオペレーションによれば、このサブクラス化情報はコンパイル時にサービス・プログラム・コードに含まれる。従って、サービス・プログラム８０６が適当なサーバ・ノードのサービス・プログラム・アドレス空間８１０にインストールされているときは、サービス・オブジェクト・サブクラスの構築子(constructor) は、コールされて、ステップ９０４（図９）に示すようにサービス・オブジェクトを通信ディレクトリ・サービス８０４に構築することができる。構築子をコールする過程で、サービス情報のタイプと品質は、図中に矢印８０２で示すように通信ディレクトリ・サービスに渡される。前述したように、通信ディレクトリ・サービス８０４は、共用ライブラリに置かれているスタック定義の集まりを含んでいる。これらのスタック定義は、通信リンクが定義され、特定のトランスポート・メカニズムと関連づけられる時に生成される。スタック定義はそれぞれ層定義の集まりからなっている。層定義は、各層におけるデータの処理と層間の相互作用を制御する。各スタック定義は、トランスポート層から物理層までのスタックを完全に定義している（これらの層の詳細は上述した通りである）。新サービス・オブジェクトを作成する過程で、通信ディレクトリ・サービス８０４はサービス・プログラムから提供されたサービス情報のタイプと品質を使用してセッション層を構築し、ストアされた通信スタック定義を参照する適当なリファレンスを、ステップ９０６に示すように含む。新サービスをアクセスするために２つ以上の通信リンクが使用できるときは、適当なスタック定義が新サービス・オブジェクトの中で参照され、セッション層が構築されて、必要とするサービスのタイプや通信リンクの可用性などの種々の基準に基づいて通信リンクの１つが選択される。以上のように、新しく作成されたサービス・オブジェクトはセッション層と、トランスポート層から物理層までのスタックを定義している適当なスタック定義を含んでいる。このサービス・オブジェクトは通信ディレクトリ・サービスにストアされる。なお、この時点では、どのサービス・アドレスまたは交換アドレスもサービス・オブジェクトに提供されていない。これはサービス・オブジェクトが生成されても、アクティブでないからである。従って、サービス・オブジェクトは、サービス・プログラムがサーバ・ノードにインストールされているときはいつでも生成できるが、サービス・プログラムは下述する以降のステップがとられるまでアクチベートされない。もっと具体的に説明すると、新サービスをアクチベートするために、サービス・プログラムは、ステップ９０８に説明されているように、ストアされたサービス・オブジェクトをネットワーキング・サービス８１６内の動的再構築可能スタック（ＤＲＰＳ）８８２へ送るように通信ディレクトリ・サービス８０４に指示する。サービス・オブジェクトがどのようにＤＲＰＳへ転送されるかは図８に示されている。具体的には、サービス・プログラム８０６は、まず、サービス・プログラム・インタフェース８２８を独自のアドレス空間８１０に生成する。サービス・プログラムとサービス・プログラム・インタフェースとの間の通信は図中に矢印８０８で示されている。サービス・プログラム・インタフェース８２８の方は構成データ・ストリーム８１４を生成し、これは、ネットワーキング・サービス８１６に常時使用できるように置かれているサーバ・インタフェース８１８へデータをストリーム化して送ることができる。次に、サービス・プログラム８０６は、ネットワーク構成データを含んでいるサービス・オブジェクトを検索する。この構成データは、矢印８１２で示すように通信ディレクトリ・サービスからサービス・プログラム・インタフェース８２８へ渡される。そのあと、構成データは矢印８１４で示すように、ストリーム化されてシステム・アドレス空間８００へ送られる。次に、ステップ９１０に示すように、サービス・プログラムがサービス・オブジェクトをアクチベートすると、サービス交換アドレスが通信ディレクトリ・サービス８０４に戻される。アクチベーション・シーケンスの詳細は図１０に示すフロー・チャートに示されている。具体的には、アクチベーション・シーケンスはステップ１０００からスタートし、ステップ１００２へ進む。ステップ１００２で、通信ディレクトリ・サービス８０４は、そのサービスが適当なものであれば、基礎となる物理ディレクトリ・サービス上のサービスをパブリッシュすることよりサービスを使用可能にする。このパブリケーションはサービスの名前を、ある場合には、サービス・アドレスを基礎となるディレクトリ・サービスに登録することからなる。次に、ルーチンはステップ１００４へ進み、そこでサービスが通信ディレクトリ・サービスに登録される。前述したように、この登録はサービス・オブジェクトをストリーム化して、通信ディレクトリ・サービスのネーティブnamespaceノードに入れることを含む。この時点で、サービスへのリファレンスがＣＤＳディレクトリ・ツリーに追加されるので、サービスはユーザがツリーを走査することにより位置づけられることができる。次に、ステップ１００６において、サービス・プログラム８０６からネットワーキング・サービス８１６内のサーバ・インタフェース８１８に渡されたスタック定義リファレンスは、ＤＲＰＳ８２２を再構成するときに使用されるスタック定義をセットアップするために使用される。ステップ１００８で、生成されたスタック定義はＤＲＰＳに渡される（このオペレーションは図中に矢印８２０で示されている）。この時点で、サービス・オブジェクト内の情報はセッション層８２３をセットアップするためにも使用される。ステップ１０１０において、ＤＲＰＳ８２２内のセッション層８２３の交換アドレス、またはネットワーク・アドレスは、通信ディレクトリ・サービス８０４に返される。具体的には、ネットワーキング・サービス８１６は、セッション層のセットアップ時にセッション層アドレスをＤＲＰＳ８２２から得る。このアドレスはサービス・インタフェース８１８を経由し、構成データストリーム８１４を通してサービス・プログラム・インタフェース８２８へ返される。最後に、交換アドレスがデータストリーム８１２を通して通信ディレクトリ・サービス８０４へ返される。この交換アドレスは、前述したように、通信ディレクトリ・サービス８０４に置かれている関連サービス・オブジェクトにストアされるので、あとでクライアント・プログラムにより検索されるようになっている。この時点で、アクチベーションは完了し、図１０に示すアクチベーション・ルーチンはステップ１０１２で終了する。ステップ９１２で、交換アドレスは通信ディレクトリ・サービスに返され、サービス・アクチベーション・ルーチンはステップ９１４で終了する。別のデータストリームもこの時点でサービス・プログラムによってセットアップされるので、そのあとで、クライアント・ノードがサーバ・ノードからのサービスを要求したとき、入来するサービス要求を受け取ることができる。具体的には、物理通信リンク８２４経由で到着したサービス要求データは、セッション層８２３をサービス・プログラム・インタフェース８２８にリンクしている別の要求データ・ストリーム８２６を通して、構成されたＤＲＰＳ８２２へ渡される。サービス・プログラム・インタフェース８２８の方は要求をデータストリーム８０８を通してサービス・プログラム８０６へ転送(forward)する。応答情報はサービス・プログラム８０６により、データ・ストリーム８０８、サービス・プログラム・インタフェース８２８、要求データストリーム８２６、ＤＲＰＳ８２２、および物理通信リンク８２４を経由してクライアント・ノードへ返される。新しいサービスがローカル通信ディレクトリ・サービスに追加されたあと、他のノードに置かれているコピーを更新しなければならない。この更新は従来と同じように行われる。例えば、取外し可能ディスク上のコピーをすべてのノードに定期的に分散することも可能である。しかし、通信ディレクトリ・サービスのコピーを分散する、もっと好ましい方法は、更新を受け取ったローカル・ノードがその更新情報を他のすべてのノードにブロードキャスト（同報通信）することである。このブロードキャストを成し遂げるために、ブロードキャスト・メッセージは、プロトコル・スタックのすべてをあらかじめ定められたデフォルト・プロトコルにセットさせる特殊なヘッダを含んでいる。このようにすると、ブロードキャスト・メッセージはすべてのノードで受信されることが可能になる。図１１から図１３までは、クライアント・アプリケーションが通信ディレクトリ・サービスと協調してリモート・サービスをアクセスするとき必要になるステップを示している。具体的には、図１１はリモート・サービスをアクセスするときに必要となる、クライアント・ノードの適当なセクションを示している。サーバ・ノード側と同じように、クライアント・ノードにはシステム・アドレス空間１１１０があり、このアドレス空間には本発明の通信ディレクトリ・サービス１１１２とネットワーキング・サービス１１１８が含まれている。アプリケーション・プログラム１１００は、独自のアプリケーション・アドレス空間１１０４で実行する。アプリケーション・プログラム１１００、ディレクトリ・サービス１１１２およびネットワーキング・サービス１１１８の相互作用は、図１２と図３に示すフローチャートに詳しく説明されている。具体的に説明すると、クライアント・サービス・アクセス・ルーチンはステップ１２００からスタートし、ステップ１２０２へ進む。ステップ１２０２に示すように、クライアントは通信ディレクトリ・サービスと相互作用して、通信ディレクトリ・サービスにストアされたサービス・オブジェクトの１つへのリファレンスを受け取る。この相互作用は図１１に矢印１１０６で示されている。前述したように、この相互作用には、通信ディレクトリ・サービス１１１２に置かれたディレクトリ・ツリー上をユーザがサーチするときは、ユーザを直接に必要とすることがある。あるいはまた、この相互作用は、介入するアプリケーション・プログラムを必要とし、通信ディレクトリ・サービスと共同作用して例えば、ドキュメント・アイコンをサービス・アイコン上にドラッグするといったように、目に見える形でサービスを選択する場合もある。いずれの場合も、ステップ１２０４に従い、通信ディレクトリ・サービス１１１２で識別されたサービス・オブジェクトへのリファレンスが、矢印１１０８に示すようにアプリケーション・プログラム１１００へ返される。これを受けて、アプリケーション・プログラムは、構成データをネットワーク・サービス１１１８へ送る準備としてクライアント・インタフェース・オブジェクト１１２６を生成する。サービス・オブジェクト・リファレンスは、通信ディレクトリ・サービス１１１２により構成データ・ストリーム１１１４を通してクライアント・インタフェース１１２６へ渡される。クライアント・インタフェース１１２６からは、構成データは構成データ・ストリーム１１１６上でストリーム化されて、ネットワーキング・サービス１１１８に置かれたサーバ・インタフェース・オブジェクト１１２０へ送られる。サービス・インタフェース・オブジェクト１１２０は、システム・ブートアップ時にネットワーキング・サービス１１１８が作成されるとき作成され、ネットワーキング・サービスに永続的に常駐する。ステップ１２０６に従い、アプリケーション・プログラム１１００はサービス・オブジェクト・リファレンスをアクチベートする。図１３は、サービス・オブジェクト・リファレンスをアクチベートするときのステップを示す詳細図である。具体的には、アクチベーション・ルーチンはステップ１３００からスタートし、ステップ１３０２へ進む。ステップ１３０２において、サービス・オブジェクト・リファレンスは、適当であれば、基礎となる物理ディレクトリ・サービスのどれかで解決される。この解決は、サービス・オブジェクトに置かれたサービス名を使用して基礎となるディレクトリ・サービス上をサーチし、ネットワーク・アドレスを得ることにより行われる。あるいはまた、サービス・リファレンスが通信ディレクトリ・サービス１１１２のネーティブnamespace に登録されていれば、サービス・アドレスまたはサービス交換はサービス・オブジェクト・リファレンスから直接に得ることができる。ステップ１３０４において、サービス・オブジェクトに含められたスタック定義は、サービス・インターフェース１１２０とネットワーキング・サービス１１１８によって使用され、ＤＲＰＳ１１２４を構成するようにプロトコル・スタック層がセットアップされる。次に、ステップ1３０６で、生成されたスタック定義は矢印１１２２で示すようにＤＲＰＳに渡される。これらのスタック定義は、要求と応答データをアプリケーション・プログラム１１００とリモート・サービス（図１１には示されていない）との間で送る準備として、ＤＲＰＳ１１２４をセットアップし、通信リンクを構成する。次に、ステップ１３０８において、ＤＲＰＳ１１２４内のセッション層１１２３のアドレスはサーバ・インタフェース１１２０に返される。そのあと、アクチベーション・ルーチンはステップ１３１０で終了する。図１２のステップ１２０８へ戻り、サーバ・インタフェース１１２０は、セッション層１１２３のアドレスを、サービス・オブジェクト・レファレンスから得たリモート・サービス交換と入れ替えて、リモート・サービス交換（ステップ１２０８に示すように）を、構成データ・ストリーム１１１６、クライアント・インタフェース１１２６およびデータ・パス(data path)１１０２を経由してアプリケーション・プログラム１１００に返す。このように、アプリケーション・プログラムはリモート・サービスと通信するときは、通信ディレクトリ・サービスからネットワーキング・サービスへ渡されたリモート・サービス・アドレスを使用する。ステップ１２１０に示すように、サービス要求をアプリケーション・プログラム１１００からリモート・サービスへ送るように、別のデータ・パスがセットアップされる。この別のデータ・パスは、データ・パス１１０２、クライアント・インタフェース１１２６およびＤＲＰＳ１１２４のセッション層１１２３を含んでいる。ステップ１２１２に従って、要求情報は物理通信リンク１１３０を経由してリモート・サービス・ロケーションへ送出される。応答情報は、ＤＲＰＳ１１２４、データ・ストリーム１１２８、クライアント・インタフェース１１２６およびデータ・パス１１０２を経由してアプリケーション・プログラム１１００に返される。そのあと、サービス要求ルーチンはステップ１２１４で終了する。以上、本発明の特定実施例に限定して説明してきたが、本発明は種々態様に変更および改良することにより、本発明の利点の一部または全部を達成できることは勿論である。従って、請求の範囲は、本発明の精神と範囲に属するかぎり上記の変更および改良を包含することを目的としている。

【手続補正書】特許法第１８４条の８【提出日】１９９６年１月２日【補正内容】明細書オブジェクト指向ルール・ベース・プロトコル・システム著作権表記本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁に記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではない。その他の権利を一切所有することを明示に留保する。発明の分野本発明は一般的には分散コンピュータ・ネットワークに関し、より具体的には分散ネットワーク・ディレクトリとネーミング・サービスに対するルール・ベース・プロトコル処理に関する。発明の背景パーソナル・コンピュータやミニ・コンピュータなどの、独立型でローカル化されたデータ処理デバイスによるデータ処理が急成長していることに伴って、データ・ネットワークは物理的に切り離されたデバイスを互いに結合し、ネットワークに接続された種々のデバイス間でディジタル通信を行なうことを可能にするまで発展している。ネットワークには、ローカル・エリア・ネットワーク(local area network - ＬＡＮ)と広域ネットワーク（wide are anetwork - ＷＡＮ）を含めて、数種類のものがある。ＬＡＮは限定エリア・ネットワークであり、ＬＡＮに接続されたデータ・デバイスは同一建物内に置かれているのが一般である。代表的なＬＡＮは同軸ケーブルや撚り対線(twisted pair)のように、種々のコンピュータ、サーバ、プリンタ、モデム、その他のディジタル・デバイスを互いに結合する伝送媒体から構成されている。これらのデバイスは「ノード」と総称され、各々はノードを一意的に識別するアドレスで伝送媒体に接続され、データをあるノードから別のノードへルート(route)するために使用されている。資源とサービスを提供するノードは「サーバ(server)」ノードと呼ばれ、これらの資源とサービスを利用するノードは「クライアント(client)」ノードと呼ばれている。ＷＡＮはもっと大きなエリアを取り囲んでいるのが一般で、電話回線などのコモン・キャリア接続を含んでいる場合もある。 Alok Sinha著「クライアント−サーバ・コンピューティング」（Client-Serve r Computing）という文献には、クライアント−サーバ・コンピューティング・テクノロジの一般的概念が開示されている。この文献では、基本的パラダイム、業界の見通し、テクノロジ、接続インタフェース、およびデータベース・インタフェースとグラフィカル・インタフェースを含む将来の可能性が議論されている。この文献はクライアント−サーバ・テクノロジの適度に詳しい概要書である。 C．Tschudin 著「フレキシブル・プロトコル・スタック」(Flexible Protocol Stacks)という文献はフレキシブル・スタックの実現可能性について検討し、「プロトコル・スタックが動的に再構成されたとき起こる、いくつかの基本的問題を実験する」ためのテスト・システムを開示している。この文献は、「スタック構築手法を探すためにもっと研究が必要である」こと、およびもっとテストとデバッギングが必要であることを指摘している。この文献はフレキシブル・プロトコルの可能性を考慮しているが、他方では、「そのようなプロトコル環境が実現可能であるかどうかという問題が残っている」こと、および「現在の研究水準では、任意のプロトコル・スタックを取り扱うために必要な手法と、かかる環境を実現するために必要な手法の知識が不十分である」ことを認めている。最後に、この文献は、「そのような一般的プロトコル環境を有することを期待する前に、実行状態(running)のプロトコル・スタックの管理に関する理解がもっと必要である」と述べている。ＬＡＮとＷＡＮは、様々な構成で互いに結合されて、異なる建物やロケーション間を結んでいる場合や、大陸全体に渡っている場合もある「エンタープライズ」ネットワークを構築することがよくある。エンタープライズ・ネットワークが便利である理由には、いくつかある。このネットワークは資源共用を可能にする。つまり、プログラム、データおよび機器は、資源とユーザの物理的ロケーション（所在）に関係なく、ネットワークに接続されたすべてのノードが利用できる。また、エンタープライズ・ネットワークでは、複数のデータ・ソースを重複して使用可能にしておくことにより信頼性も得られる。例えば、重要なデータ・ファイルは複数のストレージ（記憶）デバイスに複製しておくことができるので、例えば、機器障害が原因でファイルの１つが使用不能になっても、重複ファイルを使用することができる。発明の概要本発明の一実施例によれば、ルール・ベース・プロトコル選択メカニズムが該当のプロトコル構成をサービスのタイプと品質に基づいて選択することにより、上述した問題を解決し、上述した目的を達成している。各プロトコル・ファミリごとに、ルール・セットが定義され、サービスのタイプと品質を特定の共通プロトコル・セットに変換するようにしている。図面の簡単な説明本発明の上記およびその他の利点は、添付図面と関連して以下の説明を参照することによりもっと理解しやすくなる。添付図面において、図１は、ローカル・ディレクトリ・サービスを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。図２は、分散ディレクトリ・サーバを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。図３は、ルール・ベース・プロトコル選択メカニズムが動作しているコンピュータ・システム、例えば、パーソナル・コンピュータ・システムを示す概略ブロック図である。図４は、ルール・ベース・プロトコル選択メカニズムを取り入れているクライアント・サーバ・ネットワークを示す概略ブロック図である。図５は、国際標準化機構の７層モデルに準拠して２ノード構造間でデータを伝送するために使用される従来のプロトコル・スタックの詳細を示す概略ブロック図である。図６は、通信ディレクトリ・サービスの主要コンポーネントを示す概略図である。図７は、種々のディレクトリ・サービスと他のネットワーク・サービス上でブラウズを可能にするディレクトリ・ツリーのセットアップ例を示す概略図である。図８はサーバ・ノードの主要コンポーネントを示す概略ブロック図であり、サービス・プログラムが通信ディレクトリ・サービスとやりとりする様子を示している。図９は、新サービスをネットワーク上で使用可能にするときに伴うステップを示す簡略フローチャートである。図１０は、サービス・オブジェクトをアクチベートするためにサービス・プログラムによって実行されるステップを示す展開されたフローチャートである。図１１は、クライアント・ノードの主要コンポーネントを示す概略図であり、アプリケーション・プログラムが通信ディレクトリ・サービスとやりとりしてサービスをアクセスする様子を示している。図１２は、ネットワーク上で使用可能なサービスをアクセスするときに伴うステップを示す簡略フローチャートである。好適実施例では、フレームワークの概念を取り入れ、アプリケーションとオペレーティング・システムを含むシステム全体にこの概念を適用している。商業ベースまたは企業の開発者、システム・インテグレータ、またはＯＥＭにとっては、このことは、MacAppなどのフレームワークに関して上述した利点のすべてが、テキストやユーザ・インタフェースなどの事物についてアプリケーション・レベルにおいてのみならず、プリント、グラフィックス、マルチメディア、ファイル・システム、入出力（Ｉ／Ｏ）、テストなどのサービスについてはシステム・レベルでも梃入れできることを意味する。図４は、図１と図２に示すクライアント−サーバ・ネットワークにおいて、通信ディレクトリ・サービスが提供されているものを示す概要図である。図２と図４を比較すると分かるように、全体的ネットワーク構成はどちらのネットワークの場合も同じであるが、通信ディレクトリ・サービスが図４に示すように使用されるときは、ノードはすべてが通信ディレクトリ・サービス（ＣＤＳ）モジュールを含んでいる。具体的には、サーバ・ノード４００，４１２，４２４，４３２，４３８は、それぞれ通信ディレクトリ・サービス・モジュール４０５，４１３，４２５，４３０，４３９を含んでいる。さらに、サーバ・ノードはいずれかが、あるいはすべてが従来のディレクトリ・サービス４０４，４１４，４１８，４３０をそれぞれ含むことも可能である。従来のディレクトリ・サービスは、通信ディレクトリ・サービスと区別するために、以下では物理ディレクトリ・サービスと呼ぶことにする。サーバ・ノードに加えて、クライアント・ノード４０６，４０８，４２０，４２２，４２８（それぞれＣＤＳ４０７，４０９，４２１，４２３，４２９）の各々も、通信ディレクトリ・サービスを含んでいる。以下で詳しく説明するように、図４に示すようなエンタープライズ・ネットワークでは、あるノードから別のノードへ送られる情報は、一般に離散的メッセージまたは「パケット」に分割され、これらのパケットは事前定義のプロトコルに従ってノード間で伝送される。ここで言う「プロトコル」とは、別々のノードがどのようにサポートされて、相互にやりとりするかを定義したルール（規則）またはプロシージャ（手順）の集まりからなっているものである。設計の複雑さを軽減するために、大部分のネットワークは一連の「層」または「レベル」で編成されるので、あるノードから別のノードへ渡される情報が層から層へ伝送されるようになっている。各層内では、あらかじめ定義したサービスまたはオペレーションが実行され、層はあらかじめ定義されたプロトコルに従って相互に通信し合っている。層化的な設計の目的は、ある層が、標準化インタフェースを通して他の層へ選択されたサービスを提供することを可能にすると共に、ある層内の実際のインプリメンテーション（実装）の詳細が他の層から見えないようにすることである。以下で詳しく説明するように、クライアント・ノードとサーバ・ノードはどちらも、通信ディレクトリ・サービス・モジュールと共同作用してネットワーク層を構成し、ネットワーク層の方は、クライアントとサーバ間の接続のタイプとパラメータを、提供されるサービスのタイプに従って制御する。ネットワーク・アーキテクチャ（ネットワークで使用される層とプロトコルの集まりの全体名）を標準化する試みとして、一般化されたモデルが国際標準化機構（ＩＳＯ）によって提案されているが、これは現在使用されている種々のプロトコルを国際的に標準化する第一歩となるものである。通信ディレクトリ・サービス６００には、ネットワーク上のユーザにとってそのオペレーションを特に便利なものにする特徴がほかにもいくつかある。具体的には、ディレクトリ・サービスは使用可能なサービスとディレクトリ・サービスに関する情報を、一連のオブジェクトとしてディレクトリ・ツリーにストアする。さらに、通信ディレクトリ・サービス内のストアされたライブラリはオブジェクトを含んでいるので、アプリケーション・プログラムとサービス・プログラムは共に、オブジェクトを通して通信ディレクトリ・サービスと直接に通信することができる。通信ディレクトリ・サービスはノードの各々に存在するので、クライアントはどのディレクトリ・サービス・サーバともディレクトリ・サービスを使用する前に接続する必要はない。そのかわりオブジェクト自体がインタフェースとなるからである。さらに、サービス・オブジェクト６０６のような、あらかじめ定義されたオブジェクトの使用は、アプリケーション・プログラムが所望するサービスとの通信をオープンすることができる簡単な方法を提供する。アプリケーション・プログラムが実際の経路構造の詳細について気にする必要なしに、サービス・オブジェクトはネットワーキング・サービスへ直接に送られて通信経路をオープンできる。さらに、既存の物理ディレクトリ・サービスはいずれも、ディレクトリ・ツリー６０２のノード・オブジェクトにカプセル化されているので、物理ディレクトリ・サービスはクライアント・アプリケーションから完全に隠蔽され、クライアント・アプリケーションは、整合性のあるプロトコルとフィーチャ・セット(feature set)を使用して通信ディレクトリ・サービスと相互作用することができる。通信ディレクトリ・サービスに見られるディレクトリ・ツリー６０２の詳細図は図７に示されている。以下で詳しく説明するように、ディレクトリ・ツリーは単純なサーチ（探索）コマンドを使用して走査することができ、完全なブラウズ機能はワイルド・カードとプレースホルダを使用により得られる。ディレクトリ・ツリーは、サーチの結果としてオブジェクトが返され、返されたオブジェクトのタイプがオブジェクトを返したディレクトリ部分のインプリメンテーションによって決定されるように設計されている。ディレクトリ・ツリーのサーチから返されるオブジェクトの例としては、リモート・サービスと接続するために使用される情報を含んでいる、図６に示すサービス・オブジェクト６０６へのリファレンス、ユーザに関するセキュリティと認証情報を含んでいるプリンシプル(pri nciple)オブジェクト、ユーザに関する情報のコレクションを含んでいる「ビジネスカード」およびプログラム開発者がディレクトリ・ツリーに追加できる他のクラスがある。ディレクトリ・ツリーは、図７に示すような単一階層ツリーの編成になっている。なお、図７に示すツリー構成は単なる例示であり、本発明の範囲と原理から逸脱することなく実際のツリー構成は図示の構成と大幅に異なることがある。ツリー内のノードの各々は"namespace" オブジェクトによって形成される。namespace オブジェクトは他のnamespace オブジェクトを参照することも、またはサービスや他の物理ディレクトリ・サービスを直接に参照することもできる。ディレクトリ・ツリーの究極的なルートはルートnamespace オブジェクト７００である。ツリーのノードを形成するルートnamespace オブジェクト７００と他のnamespace オブジェクトは、走査してノード・メンバを見つけることができる従来のツリー構造に挿入される。ステップ１０１０において、ＤＲＰＳ８２２内のセッション層８２３の交換アドレス、またはネットワーク・アドレスは、通信ディレクトリ・サービス８０４に返される。具体的には、ネットワーキング・サービス８１６は、セッション層のセットアップ時にセッション層アドレスをＤＲＰＳ８２２から得る。このアドレスはサービス・インタフェース８１８を経由し、構成データストリーム８１４を通してサービス・プログラム・インタフェース８２８へ返される。最後に、交換アドレスがデータストリーム８１２を通して通信ディレクトリ・サービス８０４へ返される。この交換アドレスは、前述したように、通信ディレクトリ・サービス８０４に置かれている関連サービス・オブジェクトにストアされるので、あとでクライアント・プログラムにより検索されるようになっている。この時点で、アクチベーションは完了し、図１０に示すアクチベーション・ルーチンはステップ１０１２で終了する。ステップ９１２で、交換アドレスは通信ディレクトリ・サービスに返され、サービス・アクチベーション・ルーチンはステップ９１４で終了する。別のデータストリームもこの時点でサービス・プログラムによってセットアップされるので、そのあとで、クライアント・ノードがサーバ・ノードからのサービスを要求したとき、入来するサービス要求を受け取ることができる。具体的には、物理通信リンク８２４経由で到着したサービス要求データは、セッション層８２３をサービス・プログラム・インタフェース８２８にリンクしている別の要求データ・ストリーム８２６を通して、構成されたＤＲＰＳ８２２へ渡されるサービス・プログラム・インタフェース８２８の方は要求をデータストリーム８０８を通してサービス・プログラム８０６へ転送(forward)する。応答情報はサービス・プログラム８０６により、データ・ストリーム８０８、サービス・プログラム・インタフェース８２８、要求データストリーム８２６、ＤＲＰＳ８２２、および物理通信リンク８２４を経由してクライアント・ノードへ返される。新しいサービスがローカル通信ディレクトリ・サービスに追加されたあと、多のノードに置かれているコピーを更新しなければならない。この更新は従来と同じように行われる。例えば、取外し可能ディスク上のコピーをすべてのノードに定期的に分散することも可能である。しかし、通信ディレクトリ・サービスのコピーを分散するもっと好ましい方法は、更新を受け取ったローカル・ノードがその更新情報を他のすべてのノードにブロードキャスト（同報通信）することである。このブロードキャストを成し遂げるために、ブロードキャスト・メッセージは、プロトコル・スタックのすべてをあらかじめ定められたデフォルト・プロトコルにセットさせる特殊なヘッダを含んでいる。このようにすると、ブロードキャスト・メッセージはすべてのノードで受信されることが可能になる。図１１から図１３までは、クライアント・アプリケーションが通信ディレクトリ・サービスと協調してリモート・サービスをアクセスするとき必要になるステップを示している。具体的には、図１１はリモート・サービスをアクセスするときに必要となるクライアント・ノードの適当なセクションを示している。サーバ・ノード側と同じように、クライアント・ノードにはシステム・アドレス空間１１１０があり、このアドレス空間には通信ディレクトリ・サービス１１１２とネットワーキング・サービス１１１８が含まれている。アプリケーション・プログラム１１００は、独自のアプリケーション・アドレス空間１１０４で実行する。アプリケーション・プログラム１１００、ディレクトリ・サービス１１１２およびネットワーキング・サービス１１１８の相互作用は、図１２と図３に示すフローチャートに詳しく説明されている。次に、ステップ１３０８において、ＤＲＰＳ１１２４内のセッション層１１２３のアドレスはサーバ・インタフェース１１２０に返される。そのあと、アクチベーション・ルーチンはステップ１３１０で終了する。図１２のステップ１２０８へ戻り、サーバ・インタフェース１１２０は、セッション層１１２３のアドレスを、サービス・オブジェクト・レファレンスから得たリモート・サービス交換と入れ替えて、リモート・サービス交換（ステップ１２０８に示すように）を、構成データ・ストリーム１１１６、クライアント・インタフェース１１２６およびデータ・パス(data path)１１０２を経由してアプリケーション・プログラム１１００に返す。このように、アプリケーション・プログラムはリモート・サービスと通信するときは、通信ディレクトリ・サービスからネットワーキング・サービスへ渡されたリモート・サービス・アドレスを使用する。ステップ１２１０に示すように、サービス要求をアプリケーション・プログラム１１００からリモート・サービスへ送るように、別のデータ・パスがセットアップされる。この別のデータ・パスは、データ・パス１１０２、クライアント・インタフェース１１２６およびＤＲＰＳ１１２４のセッション層１１２３を含んでいる。ステップ１２１２に従って、要求情報は物理通信リンク１１３０を経由してリモート・サービス・ロケーションへ送出される。応答情報は、ＤＲＰＳ１１２４、データ・ストリーム１１２８、クライアント・インタフェース１１２６およびデータ・パス１１０２を経由してアプリケーション・プログラム１１００に返される。そのあと、サービス要求ルーチンはステップ１２１４で終了する。請求の範囲１．複数の異種通信リンク（３１６，３１５，３６６）を介してクライアント・ノード（４０６，４０８，４２０，４２２，４２８）をサーバ・ノード（４００，４１２，４２４，４３２，４３８）に接続するマルチノード・コンピュータ・ネットワーク・システム（図４）であって、該コンピュータ・ネットワーク・システムは複数のノードと、各ノードごとに少なくとも１つのプロセッサ（３０２）と、該少なくとも１つのプロセッサに接続され、該プロセッサの制御下に置かれているメモリ（３０４，３０６，３１３）とを備えているものにおいて、前記コンピュータ・ネットワーク・システムが、（ａ）前記複数の異種通信リンクはサービスのタイプとサービスの品質（９０６）によって区別されていて、サービスの該タイプと該品質は前記メモリにストアされており、（ｂ）前記クライアント・ノードと前記サーバ・ノードとの間で該通信リンク上をデータを伝送するための複数のプロトコルを備え、（ｃ）該メモリは第１プログラム・ロジック（１１００）および第２プログラム・ロジック（１１１０）とを含んでいて、該第１プログラム・ロジックは該サーバ・ノードとの接続を要求するためのもので、該接続はサービスの該タイプとサービスの該品質に依存しており、該第２プログラム・ロジックは前記複数のプロトコルの少なくとも１つおよび該複数のリンクの少なくとも１つをサービスの該タイプとサービスの該品質に基づいて識別するためのものであることを特徴とするマルチノード・コンピュータ・ネットワーク・システム。２．クライアント−サーバ・システム（図４）のクライアント・ノード（図１１）であって、該クライアント−サーバ・システムは分散コンピュータ・ネットワークを含み、該ネットワークはリモート・プロシージャ・コール（ＲＰＣ）サービス（１１１２，８０４，８０６）を備えており、該ＲＰＣサービスはＲＰＣプロトコルを通してアクセスされ、前記クライアント・ノードは通信媒体（８２４，１１３０）を介してサーバ・ノード（図８）と相互接続されて該クライアント・サーバ・ネットワークを形成しており、該クライアント・ノードはプロセッサ（３０２）と、該プロセッサによってアクセス可能なメモリ（３０４，３０６，３１３）と、複数のサービス・パケットを処理するための第１プログラム・ロジック（１１２６）であって、該第１プログラム・ロジックはアプリケーション・プログラム（１１００）に含まれ、該アプリケーション・プログラムは前記メモリに置かれているものと、前記パケットを前記通信媒体を利用して送受信するためのネットワーク・アダプタと、該メモリに置かれていて前記アダプタとの間で該パケットを受け渡しするための第２プログラム・ロジック（１１１８）とを備えているものにおいて、前記クライアント・ノードは、（ａ）該メモリに置かれていて前記プロセッサを制御するための第３プログラム・ロジックであって、該第３プログラム・ロジックはオブジェクト指向オペレーティング・システムであるものと、（ｂ）前記オペレーティング・システムにストアされたデータと関数から該アプリケーション・プログラムによって生成されたコーラ・オブジェクト（１１０６）であって、該第２プログラム・ロジックは該コーラ・オブジェクトに応答して、前記ＲＰＣプロトコルに従って該パケットをカプセル化して、該第１プログラム・ロジックが該サーバ・ノードのディスパッチャ・オブジェクトに置かれている関連サービス（８３６）をコールすることを可能にするものと、（ｃ）垂直方向にリンクされた複数のプロトコル層オブジェクトを含む動的構成可能プロトコル・スタック（１１２４）であって、該プロトコル・スタックは該アダプタと相互作用して該アダプタを経由して該通信媒体上を該パケットを転送するように構成されているものと、（ｄ）該アプリケーション・プログラムと該プロトコル・スタックとの間に同期データ・ストリーム・トランザクションを確立するリモート・ストリーム・オブジェクト（１１２８）であって、該リモート・ストリーム・オブジェクトとプロトコル・スタックは共同作用して該クライアント・ノード内に通信データ・パスを完成するものとを備えていることを特徴とするクライアント・ノード。３．前記垂直方向にリンクされた複数のプロトコル層オブジェクトは、前記クライアント・ノードで実行される前記アプリケーション・プログラムに固有である上位プロトコル層オブジェクト（５００，５０２）および、該クライアント・ノードで実行される他のアプリケーション・プログラム相互間で共用される下位プロトコル層オブジェクト（５０４，５０６，５０８，５１０，５１２）とを含むことを特徴とする請求項２に記載のクライアント・ノード。４．前記上位プロトコル層は前記アプリケーション・プログラムと前記パケットを交換するアプリケーション層オブジェクト（５００）を含むことを特徴とする請求項３に記載のクライアント・ノード。５．前記上位プロトコル層は前記パケットをあらかじめ決めたフォーマットで前記下位プロトコル層オブジェクトに提示するプレゼンテーション層オブジェクト（５０２）を含むことを特徴とする請求項４に記載のクライアント・ノード。６．前記アプリケーション層オブジェクトおよび前記プレゼンテーション層オブジェクトは該クライアント・ノードのプロセス・アドレス空間（１１０４）に置かれていることを特徴とする請求項５に記載のクライアント・ノード。７．前記コーラ・オブジェクトおよび前記アプリケーション・プログラムは前記プロセス・アドレス空間にさらに置かれていることを特徴とする請求項６に記載のクライアント・ノード。８．前記下位プロトコル層オブジェクトおよび前記オペレーティング・システムは該クライアント・ノードのシステム・アドレス空間（１１１０）に置かれていることを特徴とする請求項７に記載のクライアント・ノード。９．前記リモート・ストリーム・オブジェクトは前記プロセス・アドレス空間と前記システム・アドレス空間との間での前記パケットの提示の整合性のあるフォーマットを保証する第４プログラム・ロジックを含むことを特徴とする請求項８に記載のクライアント・ノード。１０．前記リモート・ストリーム・オブジェクトは前記クライアント・ノードと前記サーバ・ノードとの間に短期的同期トランザクションを確立する要求／応答モデル・オブジェクト（１１２８）と長期的同期トランザクションにわたって該ノードをバインドする部分的リモート・オペレーション・サービス・エレメント・モデル・オブジェクトの１つを備えたことを特徴とする請求項９に記載のクライアント・ノード。１１．マルチノード・コンピュータ・ネットワーク・システム（図４）内で複数の異種通信リンク（３１６，３１５，３６６）を通してクライアント・ノード（４０６，４０８，４２０，４２２，４２８）をサーバ・ノード（４００，４１２，４２４，４３２，４３８）に接続する方法であって、前記複数のリンクは複数のノード間を接続し、前記複数のノードの各々は少なくとも１つのプロセッサ（３０２）を備えており、該方法は、（ａ）サービスのリンク・タイプとサービスのリンク品質を該複数のリンクの各々と関連づけるステップ（８０２，９０２，９０４）と、（ｂ）所望のサービス・タイプおよび所望のサービス品質を指定するステップ（１２０６）と、（ｃ）少なくとも１つのプロトコルおよび少なくとも１つのリンクを、前記サービスのリンク・タイプと前記サービスのリンク品質から前記所望のサービス・タイプと前記所望のサービス品質に基づいて識別するステップ（１３０４）と、（ｄ）前記少なくとも１つのプロトコルと前記少なくとも１つのリンクを使用して前記クライアント・ノードと前記サーバ・ノードとの間に接続を確立するステップ（１２１０）とを備えたことを特徴とする方法。１２．クライアント−サーバ・システム（図４）内でクライアント・ノード（図１１）をサーバ・ノード（図８）に接続する方法であって、該クライアント−サーバ・システムは分散コンピュータ・ネットワークを含み、該ネットワークはリモート・プロシージャ・コール（ＲＰＣ）サービス（１１１２，８０４，８０６）を含み、該ＲＰＣサービスはＲＰＣプロトコルを使用してアクセスされ、前記クライアント・ノードは通信媒体（８２４，１１３０）を介して前記サーバ・ノードと相互接続されて該クライアント−サーバ・システムを形成しており、該クライアント・ノードはプロセッサ（３０２）と、該プロセッサによってアクセス可能なメモリ（３０４，３０６，３１３）と、複数のサービス・パケットを処理するための第１プログラム・ロジック（１１２６）であって、該第１プログラム・ロジックはアプリケーション・プログラム（１１００）内に含まれていて、該アプリケーション・プログラムは前記メモリに置かれているものと、前記パケットを前記通信媒体を利用して送受信するネットワーク・アダプタと、該メモリに置かれていて該パケットを前記アダプタとの間で転送するための第２プログラム・ロジック（１１１８）と、該プロセッサを制御するオブジェクト指向オペレーティング・システム（１１１０）であって、該オペレーティング・システムは第３プログラム・ロジックを含んでいて、該オペレーティング・システムは該メモリに置かれているものとを備えており、該方法は、（ａ）該オペレーティング・システム内に含まれているデータおよび関数から該第１プログラム・ロジックによってコーラ・オブジェクトを構築するステップ（１２０２）と、（ｂ）前記コーラ・オブジェクトを前記第２プログラム・ロジックに提示するステップ（２１０４）と、（ｃ）前記第２プログラム・ロジックは該コーラ・オブジェクトの前記提示に応答して、該パケットを前記ＲＰＣプロトコルに従ってカプセル化し、該第１プログラム・ロジックが該サーバ・ノードのディスパッチャ・オブジェクトに置かれている関連のオブジェクト（８３６）をコールすることを可能にするステップと、（ｄ）垂直方向にリンクした複数のプロトコル層オブジェクトから動的構成可能プロトコル・スタック（図１３、１１２４）を構築するステップであって、該プロトコル・スタックは該アダプタと相互作用して該パケットを該アダプタを経由して該通信媒体上を転送するように構成されているものと、（ｅ）該アプリケーション・プログラムと該プロトコル・スタックとの間に同期データストリーム・トランザクションを確立するリモート・ストリーム・オブジェクト（１１２８）を構築するステップであって、該リモート・ストリーム・オブジェクトおよび該プロトコル・スタックは共同作用して該クライアント・ノード内に通信データ・パスを完成するものとを備えたことを特徴とする方法。１３．前記動的構成可能プロトコル・スタックを構築するステップは、（ｄ１）前記クライアント・ノードで実行される前記アプリケーション・プログラムに固有である上位プロトコル層オブジェクトをアセンブルし、（ｄ２）該クライアント・ノードで実行される他のアプリケーション・プログラム相互間で共用される下位プロトコル層オブジェクトをアセンブルすることを備えたことを特徴とする請求項１２に記載の方法。１４．前記上位プロトコル層オブジェクトをアセンブルするステップは、前記パケットを前記アプリケーション・プログラムと交換するアプリケーション層オブジェクトを含むことをさらに備えたことを特徴とする請求項１３に記載の方法。１５．前記上位プロトコル層オブジェクトをアセンブルするステップは、前記パケットをあらかじめ決めたフォーマットで前記下位プロトコル層オブジェクトに提示するプレゼンテーション層オブジェクトを含むことをさらに備えたことを特徴とする請求項１４に記載の方法。１６．前記アプリケーション層オブジェクト、前記プレゼンテーション層オブジェクト、前記コーラ・オブジェクトおよび前記アプリケーション・プログラムは前記クライアント・ノードの前記プロセス・アドレス空間に置かれており、前記下位プロトコル層オブジェクトおよび前記オペレーティング・システムは該クライアント・ノードのシステム・アドレス空間に置かれており、該方法は、該プロセス・アドレス空間と該システム・アドレス空間との間で前記パケットの前記提示の整合性のあるフォーマットを前記リモート・ストリーム・オブジェクトが保証することをさらに備えたことを特徴とする請求項１５に記載の方法。１７．前記リモート・ストリーム・オブジェクトは前記クライアント・ノードと前記サーバ・ノードとの間に短期的同期トランザクションを確立する要求／応答モデル・オブジェクトと長期的同期トランザクションにわたって該ノードをバインドする部分的リモート・オペレーション・サービス・エレメント・モデル・オブジェクトの１つを備えたことを特徴とする請求項１６に記載の方法。【手続補正書】特許法第１８４条の８【提出日】１９９６年１月１１日【補正内容】完全なブランチ機能を提供するためには、namespace ７０２のような中間name space を、ルートnamespace ７００とリーフ・ノード７０４〜７１０との間に挿入することが可能である。中間namespace は他のnamespace を参照している。前述したように、本発明の通信ディレクトリ・サービスはサービス・プログラムとアプリケーション・プログラムの両方と相互作用して、クライアントとサーバとの間で必要な通信リンクを透過的に(transparently)セットアップする。この相互作用では、サービス提供者による通信ディレクトリ・サービスにおけるサービス・オブジェクトの生成と、サーバ・ノードにおけるプロトコル・スタックの構成を含む。サービスのアクセスを所望するクライアントは関連サービス・オブジェクトを検索し、それを使用してプロトコル・スタックをクライアント・ノードに構成して通信リンクをセットアップする。図８〜図１０は、サーバ・ノードで稼働しているサービス・プログラムによって実行されて、クライアント・ノードで実行されているアプリケーション・プログラムにより使用できるように新しいサービスをネットワーク上で使用可能にするオペレーションを説明したものである。図８は、新サービスの生成とアクチベーションに含まれるサーバ・ノード・プログラムの部分を示す概略ブロック図である。図９は、サービス・プログラム、通信ディレクトリ・サービスおよびノード・ネットワーキング・サービスの間で相互作用して、新サービスを確立し、適当な通信リンク上で動作するようにネットワーキング・サービスを構成する手順を示したフローチャートである。図１０は、関連サービス・ブロックをアクチベートすることによって新サービスをアクチベートする様子を示す詳細ブロック図である。もっと具体的に説明すると、図８は、サービスをリモート・クライアントに提供するときのサーバ・ノードの基本的構成を示している。サーバ・ノードは共通エリア、または、システム・アドレス空間８００をもつ構成になっており、このアドレス空間には、オペレーティング・システム・プログラムと、システムで実行されるサービス・アプリケーションによって使用される種々の共有ライブラリが置かれている。具体的には、システム・アドレス空間８００には、通信ディレクトリ・サービス８０４およびネットワーキング・サービス・プログラムとライブラリ８１６が含まれている。サーバ・ノードには、独自のアドレス空間８１０で実行されるサービス・プログラムも置かれている。以下で説明するように、サービス・プログラム８０６は通信ディレクトリ・サービス８０４と相互作用してサービス・オブジェクトを作成し、これは通信ディレクトリ・サービス８０４に置かれる。このサービス・オブジェクトはこのシステム内の他のノードすべてに分散(dis tribute)されるので、ネットワーク上のクライアントのすべてに対してローカル・ベースでの使用ができる。サービス・オブジェクトはネットワーキング・サービス８１６を構成するための適当なスタック定義を含んでいるので、アプリケーション・プログラムは通信ディレクトリ・サービスと共に、以前にストアした定義を用いて構築の詳細においてクライアント・アプリケーション・プログラムの必要なしに、通信経路をセットアップすることができる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．複数の異種通信リンクを経由してクライアント・ノードをサーバ・ノードに接続するマルチノード・コンピュータ・ネットワーク・システムであって、該コンピュータ・ネットワーク・システムは、（ａ）複数のノードと、（ｂ）ノードごとに少なくとも１つのプロセッサと、（ｃ）前記少なくとも１つのプロセッサに接続され、該プロセッサの制御下に置かれているメモリと、（ｄ）前記複数のノードを接続するネットワークとを備え、（ｅ）サービスのタイプと品質を前記メモリにストアされた情報に基づいて決定し、（ｆ）少なくとも１つのプロトコルをサービスのタイプと品質に基づいて識別することを特徴とするマルチノード・コンピュータ・ネットワーク・システム。２．クライアント−サーバ・システムのクライアント・ノードを分散コンピュータ・ネットワーク上でリモート・プロシージャ・コール（ＲＰＣ）サービスを利用して実現する装置であって、該クライアント・ノードは通信媒体を介してサーバ・ノードと相互接続されてクライアント−サーバ・ネットワークを構成し、該クライアント・ノードは、（ａ）サービス要求パケットを生成するアプリケーション・プログラムであって、該アプリケーション・プログラムは前記クライアント・ノードのメモリにストアされているものと、（ｂ）通信チャネル上でパケットを送受信するネットワーク・アダプタと、（ｃ）アプリケーション・プログラムと前記アダプタとの間でパケットを転送するように動作するプロセッサと、（ｄ）メモリにストアされていて、前記プロセッサのオペレーションを制御するオブジェクト指向オペレーティング・システムと、（ｅ）前記オペレーティング・システムにストアされたデータと関数から前記アプリケーション・プログラムによって生成されたコーラ(caller)・オブジェクトであって、該コーラ・オブジェクトは、サーバのディスパッチャ・オブジェクトに置かれている関連のサービスをコールすることによってＲＰＣプロトコルに従ってパケットを出すように前記プロセッサに指示するものと、（ｆ）ネットワーク・アダプタと相互作用して、パケットをアダプタとの間でパケットを受け渡しするように構成された動的構成可能プロトコル・スタックを提供するように編成された垂直方向にリンクした複数のプロトコル層オブジェクトと、（ｇ）前記アプリケーション・プログラムと前記プロトコル・スタックとの間に同期データ・ストリーム・トランザクションを確立するリモート・ストリーム・オブジェクトであって、該リモート・ストリーム・オブジェクトと該プロトコル・スタックは前記クライアント・ノード内の通信データ・パスを完成するように動作するものとを具備していることを特徴とする装置。３．垂直方向にリンクした前記複数のプロトコル層オブジェクトは、前記クライアント・ノードで実行される前記アプリケーション・プログラムに固有の上位プロトコル層オブジェクトと、前記ノードで実行される他のアプリケーション・プログラム相互間で共用される下位プロトコル層オブジェクトとを含むことを特徴とする請求項２に記載の装置。４．前記上位プロトコル層は、前記アプリケーション・プログラムとの間でパケットを交換するアプリケーション層オブジェクトを含むことを特徴とする請求項３に記載の装置。５．前記上位プロトコル層は、パケットをあらかじめ決めたフォーマットで前記下位プロトコル層オブジェクトへ提示するプレゼンテーション層オブジェクトを含むことを特徴とする請求項４に記載の装置。６．前記アプリケーション層オブジェクトおよび前記プレゼンテーション層オブジェクトは前記クライアント・ノードのプロセス・アドレス空間に置かれていることを特徴とする請求項５に記載の装置。７．前記コーラ・オブジェクトおよび前記アプリケーション・プログラムはさらに前記プロセス・アドレス空間に置かれていることを特徴とする請求項６に記載の装置。８．前記下位プロトコル層オブジェクトおよび前記オペレーティング・システムは前記クライアント・ノードのシステム・アドレス空間に置かれていることを特徴とする請求項７に記載の装置。９．リモート・ストリーム・オブジェクトは、前記プロセス・アドレス空間と前記システム・アドレス空間との間でパケットを提示するときの整合性のあるフォーマットを保証することを特徴とする請求項８に記載の装置。１０．前記リモート・ストリーム・オブジェクトは、前記クライアント・ノードとサーバ・ノードとの間に短期的同期トランザクションを確立する要求／応答モデル・オブジェクトと、長期的同期トランザクションにわたって該ノードをバインドする部分的リモート・オペレーション・サービス・エレメント・モデル・オブジェクトの１つを含むことを特徴とする請求項９に記載の装置。１１．マルチノード・コンピュータ・ネットワーク・システムを動作可能にして、ノードごとに少なくとも１つのプロセッサをもつ複数のノード間を接続する複数の異種通信リンクを経由してクライアント・ノードをサーバ・ノードに接続する方法であって、（ａ）前記複数のノードを前記通信リンクに接続してネットワークを構成するステップと、（ｂ）サービスのタイプと品質をストアされた情報に基づいて決定するステップと、（ｃ）少なくとも１つのプロトコルをサービスのタイプと品質に基づいて識別するステップとを含むことを特徴とする方法。１２．クライアント−サーバ・システムのクライアント・ノードを分散コンピュータ・ネットワーク上でリモート・プロシージャ・コール（ＲＰＣ）サービスを利用して実現する方法であって、該クライアント・ノードは通信媒体を介してサーバ・ノードと相互接続されてクライアント−サーバ・ネットワークを構成し、該クライアント・ノードは、（ａ）サービス要求パケットを生成するアプリケーション・プログラムであって、該アプリケーション・プログラムは前記クライアント・ノードのメモリにストアされているものと、（ｂ）通信チャネル上でパケットを送受信するネットワーク・アダプタと、（ｃ）アプリケーション・プログラムと前記アダプタとの間でパケットを転送するように動作するプロセッサと、（ｄ）メモリにストアされていて、前記プロセッサのオペレーションを制御するオブジェクト指向オペレーティング・システムと、（ｅ）前記オペレーティング・システムにストアされたデータと関数から前記アプリケーション・プログラムによって生成されたコーラ・オブジェクトであって、該コーラ・オブジェクトは、サーバのディスパッチャ・オブジェクトに置かれている関連のサービスをコールすることによってＲＰＣプロトコルに従ってパケットを出すように前記プロセッサに指示するものと、（ｆ）ネットワーク・アダプタと相互作用して、パケットをアダプタとの間でパケットを受け渡しするように構成された動的構成可能プロトコル・スタックを提供するように編成された垂直方向にリンクした複数のプロトコル層オブジェクトと、（ｇ）前記アプリケーション・プログラムと前記プロトコル・スタックとの間に同期データ・ストリーム・トランザクションを確立するリモート・ストリーム・オブジェクトであって、該リモート・ストリーム・オブジェクトと該プロトコル・スタックは前記クライアント・ノード内の通信データ・パスを完成するように動作するものとを具備していることを特徴とする装置。１３．垂直方向にリンクした前記複数のプロトコル層オブジェクトは、前記クライアント・ノードで実行される前記アプリケーション・プログラムに固有の上位プロトコル層オブジェクトと、前記ノードで実行される他のアプリケーション・プログラム相互間で共用される下位プロトコル層オブジェクトとを含むことを特徴とする請求項１２に記載の方法。１４．前記上位プロトコル層は、前記アプリケーション・プログラムとの間でパケットを交換するアプリケーション層オブジェクトを含むことを特徴とする請求項１３に記載の方法。１５．前記上位プロトコル層は、パケットをあらかじめ決めたフォーマットで前記下位プロトコル層オブジェクトへ提示するプレゼンテーション層オブジェクトを含むことを特徴とする請求項１４に記載の方法。１６．前記アプリケーション層オブジェクトおよびプレゼンテーション層オブジェクトは前記クライアント・ノードのプロセス・アドレス空間に置かれていることを特徴とする請求項１５に記載の方法。１７．前記コーラ・オブジェクトおよび前記アプリケーション・プログラムはさらに前記プロセス・アドレス空間に置かれていることを特徴とする請求項１６に記載の方法。１８．前記下位プロトコル層オブジェクトおよび前記オペレーティング・システムは前記クライアント・ノードのシステム・アドレス空間に置かれていることを特徴とする請求項１７に記載の方法。１９．リモート・ストリーム・オブジェクトは、前記プロセス・アドレス空間と前記システム・アドレス空間との間でパケットを提示するときの整合性のあるフォーマットを保証することを特徴とする請求項１８に記載の方法。２０．前記リモート・ストリーム・オブジェクトは、前記クライアント・ノードとサーバ・ノードとの間に短期的同期トランザクションを確立する要求／応答モデル・オブジェクトと、長期的同期トランザクションにわたって該ノードをバインドする部分的リモート・オペレーション・サービス・エレメント・モデル・オブジェクトの１つを含むことを特徴とする請求項１９に記載の方法。