JP3377210B2 - オブジェクト指向ネットワーク・プロトコル構成システム - Google Patents

Description

【発明の詳細な説明】 著作権表記 本出願は、一部に著作権保護の対象となる内容が含ま
れている。何人が、特許書類または特許開示事項を、米
国特許商標局の特許ファイルまたは記録の通りにファク
シミリ複製しても、著作権者はそれを妨げるものではな
いが、そうでない場合には、一切の著作権を留保する。

技術分野 本発明は、分散型コンピュータ・ネットワークに関
し、特に、分散型ネットワーク・ディレクトリとネーミ
ング・サービスに対応するネットワーク・プロトコル構
成に関する。

背景技術 コンピュータ・ハードウェアは、スタンド・アロンよ
り、分散型またはリモート型のものが益々多くなり、コ
ンピュータをネットワークで結合して、問題を協力して
解決している。このような分散型「サービス」ネットワ
ークは、問題解決を容易にするが、複数のコンピュータ
に対してオペレートされるソフトウェア・プログラムの
柔軟性と機能性に対する必要性がますます多くなってき
た。

Client−Server Computing,by Alok Sinhaには、クラ
イアント・サーバ・コンピューティング技法が開示され
ている。この文献では、基本的なパラダイムと、工業上
のパースペクティブと、技法と、結合インタフェースが
扱われており、データベース・インタフェートとグラフ
ィカル・インタフェースを含む将来の可能性が扱われて
いる。この文献はクライアント・サーバ技法を程良く扱
っている。

The OSI Management Architecture;An Overview,by
S.Mark Klererには、OSI管理環境の幾つかの態様が開示
されている。OSI管理環境は、基本となる汎用管理プロ
トコルであって、種々のネットワーク情報と統計を収集
し、その情報をいわゆるMIB（Management information
Bases）にストアするプロトコルを用いている。よっ
て、ネットワーク・フォールトを診断し、ネットワーク
性能を分析するのに、ネットワーク管理アプリケーショ
ンはこの情報をアクセスすることができる。

他の文献でも、「輻輳を軽減するか、フォールトを分
離するか、あるいは、多様なユーザのニーズに応える」
ため、ネットワークを再構成するのに、MIB情報を用い
ることができる。この分野では公知のことであるが、
「ネットワークを再構成する」ということは、ネットワ
ークを介してネットワーク・パケットをルーチングする
ため、種々のネットワーク・ノードにあるネットワーク
・アドレス・テーブルを再プログラムすることをいう。
このようにして、ネットワーク・トラフィックを、利用
率が高く、輻輳しているネットワーク・セグメントから
か、あるいは、伝送エラーが生じているセグメントから
リダイレクト（redirect）することができる。

Ｃ＋＋;Evolving Toward a more Powerful Language,
by J.O.Coplien et.alには、Ｃ＋＋と、非オブジェクト
指向言語であるＣとのそれぞれの利点と、保守と、プロ
グラミング特性とを対比させて、Ｃ＋＋プログラミング
言語の利点が記述されている。この文献には、プログラ
ム開発に対するオブジェクト指向パラダイムの幾つかの
態様が開示されている。これらの態様には、抽象データ
型と、クラスと、オブジェクト、継承と、動的バインデ
ィングが含まれる。この文献は、Ｃ＋＋を用いてインプ
リメントされているオブジェクト指向プログラミングの
利点に関する入門用のエッセイである。この文献には、
それなりに、この分野では周知のオブジェクト指向設計
とインプリメンテーション概念が開示されている。

分散型サービス・コンピュータ・ネットワークの例と
して、図１に示すような「クライアント・サーバ」シス
テム100がある。クライアント・サーバ・システム100は
クライアント・ノード102、例えば、ワークステーショ
ンまたはパーソナル・コンピュータを備えている。クラ
イアント・ノード102はネットワーク100を介して種々の
サーバ・ノード106と通信を行う。典型的なサーバ・ノ
ードは、クライアント・ノード102が自分のオペレーシ
ョンの効率を高めるのに用いるための高度なサービスの
集合、または、オペレーションを提供するハードウェア
およびソフトウェア要素を有するコンピュータである。

ネットワークの中には、LAN（local area network）
を含めて、クライアント・サーバ・システム100で採用
することができるものが幾つかある。LANは限られたエ
リアのネットワークであって、クライアント・ノードお
よびサーバ・ノードを相互結合するための伝送媒体、例
えば、同軸ケーブルまたは撚対線を有するのが典型的で
ある。それぞれのノードは、各ノードを一意に識別する
アドレスであって、ノードからノードにデータをルーチ
ングするのに用いられるアドレスで伝送媒体に結合され
ている。

ネットワークに結合されたノードは、データのディス
クリートな「パケット」を、事前に定義した「プロトコ
ル」に従って、交換することにより通信を行うのが典型
的である。このコンテキストでは、プロトコルはノード
どうしが互いにどのように対話するかを定義した規則の
集合よりなる。例えば、クライアント・サーバ・システ
ム100では、通信はパケット交換の形式をとるのが典型
的であり、クライアント102はリクエストを、サービス
を行うサーバ112に送信し、サーバ112は結果をクライア
ントに送信する。

設計が複雑にならないようにするため、ネットワーク
は、大部分、各ノード内に、一連のハードウェアおよび
ソフトウェア・レベル、すなわち、「層」として編成さ
れている。ネットワークを介して通信を行っているノー
ド間でデータを転送するため、これらの層は対話を行っ
てデータをフォーマットしている。具体的には、データ
が各層を上下されるときに、データに対して、予め定め
たサービスが行われ、各層は事前定義したプロトコルに
従って互いに通信を行う。このように階層化することに
より、各層は標準化されたインタフェースを用いて、他
の層に、選択されたサービスを提供する。標準化された
インタフェースは、サービスを実際に実現するという詳
細（details）からこれらの層を隠蔽（shield）してい
る。

標準化されたネットワーク・アーキテクチャ、すなわ
ち、あるネットワーク内で用いられる層およびプロトコ
ルのセットを標準化しようとして、一般化されたモデル
がISO（International Standard Organization）により
提案された。このモデルは、OSI（open systems interc
onnection）参照モデルといわれており、他のシステム
との通信に対して「オープン」なシステムを相互結合す
るためのものである。

この提案されたOSIモデルには、幾つかの層があり、
これらの層は、下から、「物理」層、「データ・リン
ク」層、「ネットワーク」層、「トランスポート」層、
「セッション」層、「プレゼンテーション」層、「アプ
リケーション」層といわれる。これらの層は、ネットワ
ークの各ノードで、プロトコル「スタック」を形成する
ように編成されている。

図２は従来のプロトコル・スタック225および275を示
すブロック図であり、クライアント・ノード200とサー
バ・ノード250間でデータを伝送するのに用いられる。
これらプロトコル・スタック225および275は、OSIの７
層モデルに従って構成されており、これら構成層の機能
が標準化されている。従って、クライアント・ノード20
0のプロトコル・スタック225のみを記載することにす
る。

大まかに言えば、OSIモデルの物理層214は通信チャネ
ル220を介してローデータ（raw data）ビット・ストリ
ームを伝送する。一方、データ・リンク層212はビット
・ストリームを操作し、そのビット・ストリームを見掛
け上伝送エラーのないデータ・ストリームに変換する。
このデータ・ストリームに変換するタスクは、伝送され
るデータをデータ・フレームに分割し、これらデータ・
フレームに、エラーを検出し訂正するエラー訂正メカニ
ズムを付加して、順次、伝送する。ネットワーク層210
は、物理ネットワークの多くの代替パスのうちの１つの
パスを選択して、データ・パケットをソース・ノードか
らデスティネーション・ノードにルーチングする。トラ
ンスポート層208は、セッション層206からデータ・スト
リームを受け取り、（必要な場合は）データ・ストリー
ムをより小さい単位に分割し、ネットワーク層212に渡
す。また、トランスポート層208は、分割して得られた
より小さい単位が、全て、デスティネーションに適正に
到着することを保証するため適正なメカニズムを提供す
る。

セッション層206はソース・ノードおよびデスティネ
ーション・ノード上のソフトウェア・プロセス間で「セ
ッション」、すなわち、コネクションを確立し、確立さ
れたコネクションを介して、順次、データを伝送する。
すなわち、セッションによりノード間で通常のデータ伝
送を行うことができるだけでなく、幾つかのアプリケー
ションに、ダイアログ・コントロールのようなサービス
を提供することができる。プレゼンテーション層204は
伝送されたデータのプレゼンテーションに関連する機能
であって、繰り返し要求される機能（データを符号化し
て標準のフォーマットにする機能を含む）をパフォーム
する。

図２から分かるように、プロトコル・スタック225お
よび275は、物理層214および164で、通信チャネル220を
介して物理的に結合されている。従って、クライアント
・サーバ・ネットワークを介して行うデータ伝送では、
クライアント・ノード200のアプリケーション層202でデ
ータ・メッセージが生成され、生成されたデータ・メッ
セージがプロトコル・スタック225を下る。その間、こ
のデータ・メッセージはチャネル220に供給するために
パケットのビットとしてフォーマットされる。これらの
パケット・ビットはサーバ・ノード250のプロトコル・
スタック275に伝送され、プロトコル・スタック275を上
り、アプリケーション層252に渡される。データの生成
とフォーメーションは、特に、これらのノードに対して
実行されるソフトウェア・プログラムにより行われる。
これらのソフトウェア・プログラムは、一般的に、２つ
の大きなクラス、すなわち、アプリケーション・プログ
ラムとオペレーティング・システムにカテゴライズされ
る。オペレーティング・システムは、通常、ある種のコ
ンピュータに特有のものであり、基本的なオペレーショ
ン、例えば、１次記憶装置および２次記憶装置から情報
を取り出し、関係付けをしたビデオ・ディスプレイに情
報を表示し、ある場合には、ネットワーク・オペレーシ
ョンをパフォームするような基本的なオペレーション
を、コンピュータにパフォームさせることができるユー
ティリティ・プロシージャの集まりよりなる。

オペレーティング・システムそれ自体では、一般的
に、ごく基本的な機能を提供するだけであるので、「ア
プリケーション」プログラムが必要である。アプリケー
ション・プログラムはオペレーティング・システムと対
話して、非常に高い機能を提供し、ノードのユーザを直
接インタフェースする。アプリケーション・プログラム
は、オペレーティング・システムと対話する間、標準ロ
ーカル・プロシージャ・コールにより、一連のパラメタ
・リクエストをオペレーティング・システムに発行し、
オペレーティング・システムはそのパラメタに従ってリ
クエストをパフォームして、ユーティリティ・プロシー
ジャを呼び出すのが典型的である。例えば、アプリケー
ション・プログラムはオペレーティング・システムを
「コール」し、コンピュータ・ディスク・メモリに特定
のデータをストアするか、あるいは、そのデータをネッ
トワークを介してフォワーディングすることができる。

上述したように、OSIモデルの各層の有用な機能は、
サービスを他の層に供給することである。これらの層に
より提供される２タイプのサービスは、「コネクション
指向」ネットワーク・サービスであり、「コネクション
レス」ネットワーク・サービスである。コネクション指
向サービスでは、ソース・ノードがデスティネーション
・ノードと、コネクションが確立し、メッセージを送信
した後、コネクションを終了する。このコネクション確
立に関連するオーバヘッドは、効率のよい通信性能を必
要とするノードにとって、避けたいものである。コネク
ションレス・ネットワーク・サービスの場合、伝送され
た各パケットは、デスティネーションの完全なアドレス
を、ネットワークを介して搬送する完全コネクションレ
ス・サービスが望ましい。

特定のサービスを実行するため、RPC（remote proced
ure call）により、クライアント・ノードとサーバ・ノ
ードの間でこのような「コネクションレス・セッショ
ン」を確立する。RPCは、リモート・コールをノードに
対して見掛け上「ローカル」にするため、ソフトウェア
・プログラムに組み込まれるのが典型的である。よっ
て、クライアント・サーバ通信は、プロシージャ・コー
ルの形式をとり、「スタブ」プロシージャといわれるロ
ーカル・プロシージャにネットワーク詳細（network de
tail）を置いて、ネットワーク詳細を隠蔽する。

図３は典型的なクライアント・サーバ・システム300
を示し、クライアント・ノードとサーバ・ノードをボッ
クス305および355で示す。各ノードには、ボックス302
および352で示すアプリケーション・プログラムと、ボ
ックス306および356で示すオペレーティング・システム
が駐在する。アプリケーション・プログラム302および3
52と、オペレーティング・システム306および356の間の
対話は、矢印304および354で示す。このデュアル・プロ
グラム・システムは、メインフレームからパーソナル・
コンピュータまでの種々のコンピュータで用いられる。

RPC機能を提供するため、アプリケーション・プログ
ラムは、パラメタ・リクエストを交換することにより、
（矢印308および318で示すように）スタブ・プロシージ
ャ・ソフトウェア310および360と対話する。各スタブ・
プロシージャはオペレーティング・システムと関係付け
してあるのが一般的であり、コンピュータのタイプに応
じてパラメタを編成、つまり、「フラット化し（flatte
n）」、予め定めたメッセージ・フォーマットにする。R
PCはデータを転送するか、あるいは、オペレーションを
パフォームするようにサーバに要求することができる。
従って、このようなアクションを呼び出すか、あるい
は、このようなアクションに応答するため、各ノードに
おいて、適正なスタブ・プロシージャを具体的に設計し
なければならない。

トランスポート・エンティティ314および364、つま
り、プロトコル・スタックのトランスポート層内のソフ
トウェアは、（矢印312および362で示すように）スタブ
・プロシージャ310および360と対話してメッセージを受
信し、受信されたメッセージをフォーマットしてパケッ
トにし、得られたパケットをネットワーク・アダプタ31
6および366によりネットワーク・チャネル315に渡す。
ネットワーク・アダプタ316および366には、ネットワー
ク・チャネル315と対話するのに必要な、信号、電気お
よび機械特性と、交換回路（interchange circuit）と
が組み入れられている。これらトランスポート・エンテ
ィティ314および364は、物理ネットワーク・チャネルと
は関係なく、クライアントとサーバとの間で、リライア
ブル（reliable）で、コスト効率の高いデータ・トラン
スポートを提供するのが一般的である。

RPCシステムを実現するために、クライアント・ノー
ド305のアプリケーション・プログラム302は、特に、慣
用のプロシージャ・コールを行うのにパラメタを渡して
いるのと同様にパラメタを渡して、スタブ・プロシージ
ャ310をコールする。クライアント・スタブ・プロシー
ジャ310はパラメタをフラット化し、フラット化された
パラメタは、データ・パケットとしてサーバ355に伝送
するため、トランスポート・エンティティ314に渡され
る。RPCはコネクションレス・システムであるので、ト
ランスポート・エンティティ314はパケットにヘッダを
付加してから、パケットをアダプタ316にフォワーディ
ングし、アダプタ316によりチャネル315にフォワーディ
ングするのが典型的である。そのパケットがサーバ・ノ
ード355に到達すると、アダプタ366はそのパケットをト
ランスポート・エンティティ364に渡し、そのパケット
はトランスポート・エンティティ364によりサーバ・ス
タブ・プロシージャ360に渡され、サーバ・スタブ・プ
ロシージャ360によりパラメタがアンフラット化（unfla
tten）される。そして、スタブ・プロシージャ360はア
プリケーション・プログラム352をコールし、そのパラ
メタを慣用の方法で渡す。

その仕事を完了した後、アプリケーション・プログラ
ム352は、ローカル・プロシージャ・コールを行う慣用
の方法で、例えば、結果を返して「戻る」。スタブ・プ
ロシージャ360は結果をフラット化してメッセージに
し、得られたメッセージをトランスポート・エンティテ
ィ364に渡す。トランスポート・エンティティ364は応答
パケットをフォーマットし、チャネル315を介してクラ
イアント・ノード305に転送する。トランスポート・エ
ンティティ314は、応答パケットを受け取ると、そのパ
ケットをアンフラット化するため、そのパケットをクラ
イアント・スタブ・プロシージャ310に渡す。最後に、
クライアント・スタブ・プロシージャ310は応答パラメ
タをアプリケーション・プログラム302に返す。

明らかに、RPCシステムはクライアント−サーバ・シ
ステムで分散サービスを提供する有用な手段（vehicl
e）である。しかし、ネットワークを介して利用可能な
サービスの種類が増大するにつれて、これらのサービス
を分散するため、クライアント−サーバ・システムを追
加する必要がある。このため、アプリケーション・プロ
グラムが実行されるクライアント・ノードでも、サービ
スが提供されるサーバ・ノードでも、RPCソフトウェア
を開発することが要求されることになる。さらに、ネッ
トワークに接続される媒体の種類が多様化するにつれ
て、ノード間通信を可能にするため、トランスポート・
エンティティも含めて、プロトコル・スタック・ソフト
ウェアを開発しなければならない。以前、クライアント
−サーバ・システムの実現が試みられたが、このとき
は、共通のRPCとトランスポート機能を提供するため、
コーディングが手作業で行なわれた。手作業で書いたコ
ードはエラーを生じ易い上、ノードごとに複製されるの
で、ソフトウェア開発者のマンパワーにコストが掛かり
過ぎ、マンパワーの使用効率が悪いことが露呈された。

このような点に鑑みて、本発明の目的の１つは、分散
サービス・ネットワークでリライアブル（reliable）・
クライアント−サーバ・システム通信を効率よく実現す
るための柔軟性に富んだインタフェースを提供すること
にある。

発明の開示 要約して説明すると、本発明は、新規なオブジェクト
指向クライアント−サーバ・ファシリティ（client−se
rver facility−CSF）インタフェースと、ネットワーキ
ング・サービス・ファシリティ（networking service f
acility−NSF）インタフェースにあり、分散サービス・
ネットワークのクライアント・ノードとサーバ・ノード
に駐在するアプリケーション・プログラム間で通信を実
現する。CSFインタフェースには、各ノードからサービ
ス・リクエストを呼び出すとともに応答するためのRPC
オブジェクトと、これらのサービス・リクエストをノー
ド間でトランスポートするためのAPI（application pro
gramming interface）オブジェクトが含まれる。しか
し、APIオブジェクトは、１つのノード内に通信トラン
スポートのみを提供する。従って、リモート・サーバ・
ノードに対するサービスをアクセスするとき、クライア
ント・ノードのアプリケーション・プログラムが必要と
するトランスポート・メカニズムを完成するため、API
オブジェクトとRPCオブジェクトは、NSFインタフェース
内の動的構成可能プロトコル・スタック（dynamically
−configurable protocol stack）と対話する。

具体的には、RPCオブジェクトは、caller/dispatcher
オブジェクトと、transportオブジェクトを備えてい
る。caller/dispatcherオブジェクトは、一度、インス
タンシエートされると、高レベルの「クライアント−サ
ーバ通信」プロトコル・リクエストを供給するものであ
り、caller/dispatcherオブジェクトは、トランスポー
ト・メカニズム、つまり、データストリームであって、
クライアントとサーバの間で、「クライアント−サーバ
通信」プロトコル・リクエストをフォワーディングする
のに用いられるものである。これらのトランスポート・
メカニズムには、APIオブジェクトが提供され、APIオブ
ジェクトには、データストリームを作成するためのloca
l/remote streamオブジェクトが含まれている。

最初に、トランスポート・オブジェクトは、クライア
ント・ノードでインスタンシエートされ、アプリケーシ
ョン・プログラムと新規なNSFインタフェースの間にデ
ータ・パスを構成する。サーバ・ノードにおける対応す
るデータ・パスは、当該ノードを初期化するとき構成さ
れる。よって、クライアント・ノードにおけるクライア
ント−サーバ通信とは、remote streamオブジェクトに
より作成されたデータ・ストリームを用いて、クライア
ント・ノードのアプリケーション・プログラムとNSFイ
ンタフェースとの間で行われる通信をいう。典型的に
は、transportオブジェクトとremote streamオブジェク
トは、ノード、すなわち、「クライアント」・ノードの
プロセス・アドレス空間に作成される。ここでは、tran
sportオブジェクトのレシーバは、システム・アドレス
空間、つまり、「サーバ」・ノードにおけるプロトコル
・スタックのセッション層のプロトコル・トランスレー
タ（protocol translator）である。transportオブジェ
クトはremote streamオブジェクトを作成し、作成され
たremote streamオブジェクトは、これら２つのアドレ
ス空間の間に、データをプレゼンテーションするための
一貫したフォーマットを保証する「データストリーム」
パスを作成する。

これらデータ・パスが構成されると、callerオブジェ
クトがクライアント・ノードでインスタンシエートさ
れ、別のtransportオブジェクト（これはさらに別のデ
ータ・ストリームを作成する）を作成して、RPCサービ
ス・リクエストを呼び出す。作成されたtransportオブ
ジェクトは、例えば、remote streamオブジェクトによ
り作成されるこのデータストリームに、RPCサービス・
リクエストを挿入する。このデータ・パスが構成される
ので、クライアント−サーバ通信では、RPCサービス・
リクエストが、クライアント・ノードから直接にリモー
ト・サーバ・ノードに転送される。リモート・サーバ・
ノードでは、dispatcherオブジェクトと、このdispatch
erオブジェクトに関係付けをしたメソッドが、リモート
・リクエストを取り出し、サービスを実行し、必要なら
ば、応答を返す。サーバ・ノードに対してオペレートさ
れている資源タスクと関連して、あるサービスが実行さ
れるのが典型的である。種々のサービスを実行するの
に、多種類の資源が必要になる場合がある。従って、こ
れら種々の資源タイプと一致するサーバ・ノードに、サ
ブオブジェクト（sub−object）が供給される。、これ
らのサブオブジェクトは「親」caller/dispatcherオブ
ジェクトの「子」であり、リモートで実現するための機
能を含んでいる。

remote streamオブジェクトは、同期・送信−受信−
応答データ・ストリーム・トランザクションをノード間
で確立するのに用いられるのが一般的である。「リクエ
スト／応答」トランザクション・モデルは、remote sen
der streamオブジェクトとremote receiver streamオブ
ジェクトを利用して、典型的な短期クライアント−サー
バ通信を２つのノードで確立する。クライアント・ノー
ドがサーバとの長期関係付けを必要とする場合、PROSE
（partial remote operation service element）モデル
は、複数のサービス・リクエストに、これらのノードを
「バインド（bind）」する。PROSE remote streamオブ
ジェクトは、特に、トランザクションの持続期間（dura
tion）の間、クライアント・ノードに関する状態情報を
維持して、これら長期トランザクションを実現してい
る。

クライアント・ノードとサーバ・ノードの間でリモー
ト通信を行う場合、remote streamオブジェクトは、各
ノードのNSFインタフェース内に置かれた動的構成可能
プロトコル・スタックと対話する。これらの新規なプロ
トコル・スタックは、垂直方向にリンクされた一連のpr
otocol layerオブジェクトであって、クライアント・ノ
ードとサーバ・ノードの間の同期・送信−受信−応答デ
ータ・ストリーム・トランザクションを完成するように
オペレートするprotocol layerオブジェクトを備えてい
る。protocol layerオブジェクトは、一般的に、共有ラ
イブラリに存在するオブジェクトであって、クライアン
トとサーバのアドレス空間のクライアント・アプリケー
ションとサーバ・アプリケーションが、システム・アド
レス空間に駐在するクライアントとサーバのプロトコル
・スタックをアクセスするのに用いるオブジェクトであ
る。

本発明の利点は、共通のRPC機能とトランスポート・
ソフトウェア機能を複製せずに、クライアント・アプリ
ケーション・プログラムがCSFインタフェースと直接に
通信を行って、リモート・サーバ・ノード側にあるサー
ビスをアクセスするために、クライアント・ノードを自
動的に構成することができる点である。

このような問題点を解決し、このような目的を達成す
るため、オブジェクトのセットに入っている接続情報を
カプセル化し、この接続情報を用いて、ネットワークを
構成する。この際、アプリケーションは特定のネットワ
ーク・プロトコルには気が付いていない。

図面の簡単な説明 上述した本発明の利点とその他の本発明の利点は、添
付図面を参照するとともに、次の記述を参照することに
より、さらに理解することができる。

図１はクライアント−サーバ・システムにおいて相互
結合されたノードの集まりを含むコンピュータ・ネット
ワークを示すブロック図である。

図２はOSIの0SI7層モデルに準拠して構成された従来
のプロトコル・スタックであって、図１に示すシステム
のクライアント・ノードとサーバ・ノードの間でデータ
を伝送するために用いられるプロトコル・スタック示す
ブロック図である。

図３はオペレーティング・システムと、アプリケーシ
ョン・プログラムと、スタブ・プロシージャと、従来の
プロトコル・スタックのトランスポート層のソフトウェ
アとの間の関係を示す典型的なクライアント−サーバ・
システムであって、クライアント・ノードとサーバ・ノ
ードの間のリモート・プロシージャ・コールを実現する
クライアント−サーバ・システムを示す概略図である。

図４は新規なオブジェクトCSFインタフェースを用い
ることができるクライアント・ノードを示す概略ブロッ
ク図である。

図５は新規なCSFインタフェースを用いることができ
るサーバ・ノードを示す概略ブロック図である。

図６はクライアント・ノードとサーバ・ノードが本発
明に係るオブジェクト指向CSFインタフェースとNSFイン
タフェースを組み入れたクライアント−サーバ・システ
ムを示す概略ブロック図である。

図７は、クライアント・ノードとサーバ・ノードで実
行されるアプリケーション・プログラムが参照すること
ができる、CSFインタフェースのRPCオブジェクトとAPI
オブジェクトを示す概略ブロック図である。

図８はNSFインタフェースの新規な動的構成可能プロ
トコル・スタックを示す概略ブロック図である。

図９は、本発明に係るCSFインタフェースと対話する
ために用いられるRPCオブジェクトを説明するためのブ
ロック図である。

図10は本発明に係るCSFインタフェースと対話するの
に用いられるAPIオブジェクトを説明するためのブロッ
ク図である。

図11は図10に示すAPIオブジェクトをコンストラクト
するときに関係する基底クラスと、サブクラスと、関係
付けをしたクラスを示す簡略なクラス階層を示す図であ
る。

図12は、RPCサービス・リクエストを呼び出す前にデ
ータ・パスを構成するのに、オブジェクト指向CSFイン
タフェースとNSFインタフェースが利用されるクライア
ント・ノードを示す概略ブロック図である。

図13は、RPCサービス・リクエストを呼び出す前に、
クライアント・ノードのデータ・パスを構成する際に関
係するステップのシーケンスを示すフローチャートであ
る。

図14は、RPCサービス・リクエストを呼び出し、RPCサ
ービス・リクエストに応答するのに、オブジェクト指向
CSFインタフェースとNSFインタフェースが利用されるク
ライアント・ノードとサーバ・ノードを示す概略ブロッ
ク図である。

図15AおよびＢは、本実施の形態に係るクライアント
・ノードとサーバ・ノードで、RPCサービス・リクエス
トを呼び出し、RPCサービス・リクエストに応答する際
に関係するステップのシーケンスを示すフローチャート
である。

発明を実施するための最良の形態 図４は本発明に係るクライアント・ノード400の典型
的なハードウェア構成を示す図である。クライアント40
0はCPU（central processing unit）402により制御され
る。CPU402は慣用のマイクロプロセッサでも良い。具体
的なタスクを行うため、他の多くのユニットが、全て、
システム・バス408を介して相互結合されている。特定
のクライアント・コンピュータは、図４に示すユニット
の一部だけを有することができるか、あるいは、図示し
ないコンポーネントを追加することもできるが、大部分
のクライアントが少なくとも図示したユニットを含むこ
とになる。具体的に説明すると、クライアント400は、
情報を一時的にストアしておくRAM（random access mem
ory）406と、コンピュータの構成と、基本操作コマンド
を永続的にストアするためのROM（read only memory）4
04と、クライアントを伝送チャネル450に接続するため
のネットワーク・アダプタ410とを含んでいる。キーボ
ード420のような入力デバイスと、他の公知のインタフ
ェース・デバイス（マウスと、スピーカと、マイクロホ
ンを含む）をバス408に接続するためのユーザ・インタ
フェース・アダプタ416も有する。ディスプレイ・アダ
プタ418はバス408をビデオ・モニタのようなディスプレ
イ・デバイス422に接続するものであり、このディスプ
レイ・アダプタ418によりビジュアル出力が供給され
る。

図５は本発明に係るサーバ・ノード500の典型的なハ
ードウェア構成を示す図である。サーバ500は、クライ
アント400で採用されているのと同じユニットが多く用
いられていて、CPU502と、ROM504と、RAM506と、ネット
ワーク・アダプタ510と、インタフェース・アダプタ516
と、ディスプレイ・アダプタ518を含み、これらはシス
テム・バス508を介して相互結合されている。その上、
サーバはI/Oアダプタ550を含むのが典型的である。I/O
アダプタ550は、周辺装置、例えば、２次記憶装置513や
プリンタ514のような周辺装置を、それぞれ、ケーブル5
12および515を介してバス508に接続するものである。

本発明は、クライアント・ノードとサーバ・ノード、
例えば、IBM PS/2またはApple Macintoshコンピュータ
のコンテキストで実施されるのが好ましい。さらに、ク
ライアントとサーバには、オペレーティング・システ
ム、例えば、Apple System/7オペレーティング・システ
ムのようなオペレーティング・システムが駐在してお
り、このオペレーティング・システムにより制御されコ
ーディネートされる。好ましい実施の形態では、本発明
は、OOP（object−oriented programming）技法を用い
てＣ＋＋プログラミング言語で実現されている。Ｃ＋＋
はコンパイル型言語である。つまり、プログラムは人間
が読むことのできるスクリプトで書かれ、このスクリプ
トはコンパイラと呼ばれる別のプログラムに供給され
る。コンパイラはマシン可読（machine−readable）の
数字コードを生成する。生成されたコードはコンピュー
タにロードされ、コンピュータにより直接に実行され
る。次に説明するように、Ｃ＋＋言語には、他の人が書
いたプログラムをソフトウェア開発者が容易に用いるこ
とができ、他方、プログラムの再利用を様々に管理し
て、プログラムが破壊されたり、プログラムが誤って用
いられないようにすることができるという特徴がある。
Ｃ＋＋言語は周知の言語であり、この言語を詳しく説明
した多くの論文や文献が利用可能である。その上、Ｃ＋
＋コンパイラは、Borland International,Inc.や、Micr
osoft Corporationを含む幾つかのベンダから市販され
ている。従って、ここでは、混乱を避けるため、Ｃ＋＋
言語をこまごま説明したり、Ｃ＋＋コンパイラのオペレ
ーションを詳しく説明するようなことはしないことにす
る。

当業者にとって当然であるが、OOP技法には、「オブ
ジェクト」を定義し、作成し、使用し、破壊することが
関係する。これらのオブジェクトは、データ要素（data
element）と、データ要素を操作するルーチン、つま
り、関数を備えているデータ・エンティティ（data ent
ity）である。データと、関連する関数は、あたかも単
一のアイテム（item）であるかのように、作成し、使用
し、削除することができるエンティティとして、ソフト
ウェアによって取り扱われる。同時に、データと関数に
より、オブジェクトは、実世界のエンティティを、その
特性（データにより表現することができる）と、その振
る舞い（データ操作関数により表現することができる）
に限って言えば、仮想的にモデル化することができる。
このようにして、オブジェクトは、人やコンピュータの
ような具体的な物をモデル化することができ、数やジオ
メトリ（geometry）のデザインのような抽象的なコンセ
プトをモデル化することもできる。

オブジェクトは「クラス」を作成して定義される。こ
のクラスは、それ自体はオブジェクトではないが、実際
のオブジェクトをどのようにコンストラクト（cnstruc
t）するかをコンパイラに指示するテンプレートの働き
をするあるクラスは、例えば、データ変数の個数および
タイプを指定することができ、データを操作する関数に
関連するステップを指定することができる。オブジェク
トは、実際には、「コンストラクタ（constructor）」
という特殊な関数を使用してプログラム内に作成され
る。このコンストラクタは、対応するクラス定義と、追
加情報、例えば、オブジェクト作成時に供給された引数
のような情報を用いて、オブジェクトをコンストラクト
する。同様に、オブジェクトは「デストラクタ（destru
ctor）」という特殊な関数により破壊される。オブジェ
クトはデータを操作し関数を呼び出して用いることがで
きる。

OOP技法の主な利点は、３つの基本原理、すなわち、
カプセル化と、多態性（polymorphism）と、継承による
ものである。具体的には、オブジェクトは、内部データ
構造および内部関数の全てまたは一部を隠蔽、すなわ
ち、カプセル化するように設計することができる。特
に、プログラム設計中、プログラム開発者は、データ変
数の全てまたは幾つかと、関連する関数の全てまたは幾
つかが、「プライベート（private）」、つまり、その
オブジェクトのみで用いられるオブジェクトを定義する
ことができる。他のデータまたは関数を、「パブリック
（public）」、つまり、他のプログラムが使用のために
利用可能であると宣言することができる。当該オブジェ
クトのprivateデータをアクセスするpublic関数を当該
オブジェクトで定義すると、このprivateデータに他の
プログラムからアクセスするように制御することができ
る。public関数は、そのprivateデータと「外部」世界
との制御されかつ一貫したインタフェースを形成する。
private変数を直接にアクセスするプログラム・コード
を書くと、コンパイラはプログラム・コンパイル時にエ
ラーを生じる。このエラーにより、コンパイル・プロセ
スが停止され、プログラムがrunされない。

多態性とは、オブジェクトと関数は、全体的なフォー
マットが同一であるものの、対象とするデータが異なる
とともに、それらの機能が異なるが、一貫した結果を生
じさせるコンセプトをいう。例えば、加算関数は、変数
Ａプラス変数Ｂすなわち、（Ａ＋Ｂ）と定義することが
できるが、この同じフォーマットを、ＡとＢを数にする
か、文字にするか、あるいは、ドル（dollars）とセン
ト（cents）にするかに関らず、用いることができる。
しかし、加算を行う実際のプログラム・コードは、Ａと
Ｂを含む変数のタイプによって大幅に異ならせることが
できる。多態性により、３つの関数定義（変数の各タイ
プ（数と文字とドル）に対して１つ）を個別に書くこと
ができる。これらの関数が定義されると、後で、プログ
ラムはその共通フォーマット（Ａ＋Ｂ）により加算関数
を参照することができ、コンパイル時に、Ｃ＋＋コンパ
イラは、変数のタイプを調べて、３つの関数のどれが実
際に使用されているかを判断する。そして、コンパイラ
は適正な関数コードを代入することになる。多態性によ
ると、類似の結果を出力する同様の関数は、プログラム
・ソース・コードで「グループに分けられ」、より論理
的で明確なプログラム・フローを生成することができ
る。

OOPの基礎となる第３の原理は継承である。プログラ
ム開発者はこの継承により既存のプログラムを再利用す
ることが容易になり、ソフトウェアを初めから作成しな
くて済む。継承の原理により、ソフトウェア開発者は、
クラス（と、そのクラスから後で作成されるオブジェク
ト）を相互に関係付けをして宣言することができる。具
体的には、他の基底クラス（base class）のサブクラス
としてクラスを表記することができる。サブクラスは、
その基底クラスの全public関数があたかも当該サブクラ
スに存在するかのように、その基底クラスの全public関
数を「継承」しアクセスする。あるいはまた、サブクラ
スは継承した関数の一部または全部をオーバライドする
ことができるか、あるいは、単に、同一のフォームで新
しい関数を定義するだけで、継承された関数の一部また
は全部を修正することができる（オーバライドまたは修
正を行っても、基底クラスの変数は変更されず、単に、
サブクラスでの関数の使い方が修正されるだけであ
る）。別のクラスの（選択的に変更を加えた）機能の一
部をもつ新しいサブクラスを作成すると、ソフトウェア
開発者は既存のコードを開発者独自の要求に合うように
容易にカストマイズすることができる。

OOPは他のプログラミングのコンセプトを大幅に改善
しているが、プログラム開発は、特に、既存のソフトウ
ェア・プログラムが修正の対象でない場合、修正に多大
な時間と作業量が必要である。その結果、従来のアプロ
ーチでは、事前定義され相互結合されたクラスのセット
であって、共通に遭遇するタスクを特定の環境でパフォ
ームするオブジェクトと雑多な追加のルーチンのセット
を作成するクラスが、プログラム開発者に提供される。
このような事前定義されたクラスとライブラリは、「ア
プリケーション・フレームワーク（application framew
ork）」と呼ばれるのが典型的であり、本質的には、ワ
ーキング・アプリケーションにプレハブ構造（pre−fab
ricated structure）を提供する。

例えば、ユーザ・インタフェースのためのアプリケー
ション・フレームワークは、ウィンドウと、スクロール
バーと、メニューと、等々を作成する事前定義されたグ
ラフィック・インタフェース・オブジェクトのセットを
提供し、サポートと、「デフォルト」振る舞いを、これ
らグラフィック・インタフェース・オブジェクトに提供
する。アプリケーション・フレームワークはオブジェク
ト指向の技法に基づいているので、事前定義のクラスを
基底クラスとして使用することができ、組み込まれたデ
フォルトの振る舞いを開発者定義のサブクラスにより継
承することができる。また、開発者がフレームワークを
拡張し、カストマイズされたソルーションを専門知識分
野において作成することができるようにするため、組み
込まれたデフォルト振る舞いの修正またはオーバライド
のいずれかを行うことができる。このオブジェクト指向
によるアプローチにより、伝統的なプログラミングより
大きな利点が提供される。というのは、プログラマはオ
リジナル・プログラムを変更するのではなく、オリジナ
ルのプログラムの機能を拡張しているからである。さら
に、開発者はなん層ものコードを当てずっぽうに作業し
ない。というのは、フレームワークは、アーキテクチャ
のガイダンスとモデリングを提供し、同時に、開発者を
解放し、問題領域に特有の特定のアクションを供給する
からである。

関係するシステムのレベルと、解決される問題の種類
により、アプリケーション・フレームワークは多くの種
類のものが利用可能である。フレームワークのタイプの
範囲は、ユーザ・インタフェースの開発で支援する高レ
ベル・アプリケーション・フレームワークから、基本シ
ステム・ソフトウェア・サービス、例えば、通信と、印
刷と、ファイル・システム・サポートと、グラフィック
スと、等々のようなサービスを提供する低レベル・フレ
ームワークまでに亘っている。市販のアプリケーション
・フレームワークとしては、MacApp（Apple）と、Bedro
ck（Symantec）と、OWL（Borland）と、NeXT Step App
Kit（NeXT）と、Smalltalk−80 MVC（ParcPlace）があ
る。

アプリケーション・フレームワークによるアプローチ
により、オブジェクト層でのカプセル化と、多態性と、
継承の原理が全て利用され、他のプログラミング技法が
実質的に改善されるが、困難な問題が生じる。これらの
困難な問題は、開発者にとって、自身のプログラムの再
利用は容易であるが、他のプログラムにより生成された
オブジェクトを用いるのが困難であることに起因する。
さらに、アプリケーション・フレームワークは、モノリ
シック・オペレーティング・システム上の１つ以上のオ
ブジェクト「層」により構成されているのが一般的であ
るが、このオブジェクト層に柔軟性があっても、依然と
して、awkwardなプロシージャ型コール（procedural ca
ll）により基礎となるオペレーティング・システムと頻
繁に直接に対話する必要がある。アプリケーション・フ
レームワークがアプリケーション・プログラム用のプレ
ハブ機能を開発者のために用意しているのと同じよう
に、システムフレームワーク、例えば、好適な実施の形
態に含まれるようなシステム・フレームワークは、プレ
ハブ機能を、システム・レベルのサービス（これらのサ
ービスを開発者は修正またはオーバライドして、カスト
マイズされたソリューションを作成することができる）
に提供することができるので、従来のアプリケーション
・フレームワーク・プログラムで必要であったawkward
なプロシージャ型コールを行わずに済む。例えば、CSF
（client−server facility）インタフェースと、NSF
（networking servive facility）インタフェースであ
って、自動化RPC機構と、トランスポート・エンティテ
ィに基盤を提供し、クライアント・ノードとサーバ・ノ
ードとの間でサービス・リクエストを転送することがで
きるインタフェースを考察する。これらの機構を必要と
するアプリケーション・ソフトウェア開発者は、通常、
その機構を提供するため、具体的なルーチンを書かなけ
ればならないことになる。その機構にフレームワークを
用いるには、開発者が最終出力の特性と振る舞いを供給
し、これらのタスクを行う実際のルーチンが、フレーム
ワークを提供する。

好適な実施の形態では、フレームワークのコンセプト
を取り入れ、このフレームワークのコンセプトを、アプ
リケーションとオペレーティング・システムを含むシス
テム全体に適用している。このことは、コマーシャル開
発者やコーポレート開発者か、システム・インテグレー
タか、あるいはOEMにとって、次のことを意味する。す
なわち、上述したMacAppのようなフレームワークの全て
の利点を、テキストとユーザ・インタフェースのような
事物（things）に対するアプリケーション・レベルでレ
バレッジ（leverage）することができるだけではなく、
サービス、例えば、印刷と、グラフィックスと、マルチ
メディアと、ファイル・システムと、I/Oと、ここで説
明したようなネットワークワーキングのようなサービス
に対して、システム・レベルでレバレッジすることがで
きることを意味する。

図６はクライアント−サーバ・システム600を示す概
略ブロック図であり、クライアント・ノード610とサー
バ・ノード650には、本発明に係るCSFインタフェースと
NSFインタフェースが組み入れられている。CSFインタフ
ェースとNSFインタフェースは、オブジェクト指向プロ
グラムであって、クライアント・ノードとサーバ・ノー
ドで、RPCサービス・リクエストを呼び出し、RPCサービ
ス・リクエストをトランスポートし、RPCサービス・リ
クエストに応答すると、アプリケーション・プログラム
によってアクセスされるオブジェクト指向プログラムで
ある。まず、クライアント・ノード610を説明する。ア
プリケーション・プログラム612とオペレーティング・
システム620により、ノード210のオペレーションが制御
されコーディネートされる。アプリケーション・プログ
ラム612とオペレーティング・システム620との通信は、
矢印614で示す。しかし、アプリケーション・プログラ
ム612はスタブ・プロシージャと直接に通信を行うので
はなく、RPCサービスをリクエストするとき、オペレー
ティング・システム620と、より高レベルな通信を行
う。アプリケーション・プログラム612と、オペレーテ
ィング・システム620との対話（点線の矢印618で示す）
は、オブジェクト指向CSFインタフェース630を提供して
行われる。オブジェクト指向CSFインタフェース630は主
にオペレーティング・システム620に組み込まれてい
る。しかし、RPCサービス・リクエストを呼び出し、サ
ーバ・ノード650と通信するために、トランスポート・
メカニズムを確立するとき、オブジェクト指向CSFイン
タフェース630の一部がアプリケーション・プログラム6
12で作成される。この詳細は後程説明する。

サービス・リクエストは、矢印635で図示するように
オブジェクト指向SFインタフェース630からオブジェク
ト指向NSFインタフェース640に転送される。オブジェク
ト指向NSFインタフェース640は、リクエストをフォーマ
ットし、リクエストをフォーマットしない場合には、ク
ライアント・ノード610とサーバ・ノード650の間にトラ
ンスポート・パスを完成させる。後程、このことは詳細
に説明する。その後、リクエストは、矢印42で図示する
ように、ネットワーク・アダプタ645にフォワーディン
グされ、通信チャネル648を介して、サーバ・ノード650
にフォワーディングされる。

サーバ650では、リモートRPCリクエストがネットワー
ク・アダプタ685により受信され、矢印682で図示するよ
うに、NSFインタフェース680に渡される。NSFインタフ
ェース680はリクエストを再フォーマットし、矢印675で
示すように、再フォーマットされたリクエストを、CSF
インタフェース670にフォワーディングする。

サービスを実行するため、CSFインタフェース670は、
RPCに応答して、そのリクエストをアプリケーション・
プログラム652に向ける。

クライアント・ノード610の場合のように、アプリケ
ーション・プログラム652は、矢印654で図示するよう
に、サーバ・ノード650のオペレーティング・システム6
60と直接に通信を行う。CSFインタフェース670はアプリ
ケーション・プログラム652とオペレーティング・シス
テム660の両方に駐在しており、インタフェース670間の
対話は点線の矢印658で図示してある。

上述したように、CSFインタフェースとNSFインタフェ
ースは、あるノードで実行される全てのアプリケーショ
ンによって共有されるオブジェクト指向プログラムであ
る。このため、これらのインタフェースは、主に、各ノ
ードのシステム・アドレス空間、例えば、各ノードのオ
ペレーティング・システムに駐在している。RPCサービ
ス・リクエストが呼び出されると、そのリクエストはサ
ービスをリクエストするアプリケーション・プログラム
に一意的である。従って、アプリケーション・プログラ
ムはCSFインタフェースの一部をそのプログラムのアド
レス空間内に、つまり、プロセス・アドレス空間内に作
成する。本発明によれば、アプリケーション・プログラ
ムと「デュアル」CSFインタフェースとの間の対話に
は、「オブジェクト」を作成し操作することが含まれ
る。この対話をより詳細に図７に示す。しかし、スタブ
・プロシージャ・メカニズムも、オブジェクトとしてで
はないが、CSFインタフェースにより提供されることに
注意すべきである。

図７に示すクライアント−サーバ・システム700は、
クライアント・ノード710とサーバ・ノード750とのデー
タ・パスを構成するか、あるいは、RPCサービス・リク
エストを呼び出し、しかも、RPCサービス・リクエスト
に応答するのに、採用することができる。これについて
は、図12〜図15を参照して詳しく説明する。一般的に、
クライアント・ノード710で実行されるアプリケーショ
ン714は、RPCオブジェクト716と、APIオブジェクト718
をプロセス・アドレス空間712内に作成して、CFSインタ
フェース720と対話する。アプリケーション714と、オブ
ジェクト716および718との間の対話は、矢印715で図示
してある。

本発明の一実施の形態では、RPCオブジェクト716は、
データ・パスを確立するときに使用される適正なトラン
スポート・メカニズム、つまり、データ・ストリームを
選択することができる。そして、APIオブジェクト718は
そのデータ・ストリーム・トランスポートを作成する。
別の実施の形態では、RPCオブジェクト716も、RPCサー
ビス・リクエストを、スタブ・プロシージャ・メカニズ
ムを含めて、呼び出すことができ、そして、RPC−ビス
・リクエストがデータ・ストリームに置かれる。どちら
の場合にも、APIオブジェクト718はノード710内にデー
タストリーム・トランスポートを提供するだけであり、
よって、サーバ・ノード750をアクセスするのに、アプ
リケーション714が必要とするトランスポート・メカニ
ズムを完成するため、NSFインタフェース735と対話しな
ければならない。

NSFインタフェース735は、アプリケーション714とは
別の（システム）アドレス空間に駐在するので、APIオ
ブジェクト724とRPCオブジェクト726がクライアント・
ノードの初期化時にオペレーティング・システム620に
より作成されるのが好ましい（図６）。これらのオブジ
ェクトはシステム・アドレス空間730内にCSFインタフェ
ース725を構築しており、データストリーム・トランス
ポートを完成するのに必要になるものである。具体的に
は、RPCオブジェクト716と726は高レベルのクライアン
ト−サーバ通信プロトコル・リクエストを提供するのに
対して、APIオブジェクト718と724は２つのアドレス空
間の間でこれらのリクエストをプレゼンテーションする
ための一貫したフォーマットを保証する。APIオブジェ
クト間の対話は矢印722で示す。そして、APIオブジェク
ト724とRPCオブジェクト726は、NSFインタフェース735
と対話する。NSFインタフェースは通信チャネル740への
トランスポート・パスを構成する。この対話は矢印728
で示す。

サーバ・ノード750では、タスク・アプリケーション7
54は、RPCオブジェクト756とAPIオブジェクト758をその
プロセス・アドレス空間752内に作成して、CSFインタフ
ェース760と対話する。タスク754とオブジェクトとの対
話は矢印755で示す。NSFインタフェース775はシステム
・アドレス空間770に駐在するので、APIオブジェクト76
4とRPCオブジェクト766、つまり、CSFインタフェース76
5はノード750内のトランポートを完成するために必要に
なるものである。これらのオブジェクトは、例えば、図
６に示すオペレーティング・システム660により作成さ
れる。APIオブジェクト間の対話は矢印62で示す。APIオ
ブジェクト764とRPCオブジェクト766は、矢印768で示す
ように、NSFインタフェース775と対話して、通信チャネ
ル740へのデータ・パスを構成する。

サーバのデータ・パスは当該ノードの初期設定時に構
成され、一般に静的（static）であることに注意された
い。つまり、このデータ・パスは、プロトコル・スタッ
クの構成を含めて、修正されないのが典型的である。こ
れは、主に、サーバ・ノードが予め定めたサービスか、
あるいは、サービスのセットを提供するように構成され
ているからである。

そして、クライアント・ノードとサーバ・ノード間の
ネットワーク通信は、アプリケーション714がタスク754
と通信することができるように、NSFインタフェース735
と775をチャネル740を介して結合して完成される。具体
的には、動的オペレーティング構成可能スタック732お
よび72は、NSFインタフェース735と775内に含まれてお
り、それぞれ、チャネルを介して「結合」され、ノード
間で「ピア・ツー・ピア」通信を行う。このことを次に
説明する。

インタフェースおよび動的構成可能プロトコル・スタッ
ク NSFインタフェースの備えているオブジェクトは、一
般的に、共有ライブラリ、例えば、システム・アドレス
空間に存在しており、クライアントとサーバのプロトコ
ル・スタックにアクセスするため、クライアントとサー
バのアドレス空間のアプリケーションにより使用され
る。プロトコル・スタックもシステム・アドレス空間に
駐在している。次により詳しく説明するが、NSFインタ
フェースは、特にAPIオブジェクトと対話して、リモー
ト・ノード間に、同期クライアント／サーバ・トランス
ポート・サービスを提供する。このサービスは動的構成
可能プロトコル・スタックを同期オペレーションのセッ
トとして用いて実現される。種々のネットワーキング・
アーキテクチャと、ネットワーク・アダプタ・デバイス
をサポートするのに、これらのスタックを構成すること
ができる。

NSFインタフェースは、リモート・サービス・リクエ
ストを呼び出し応答するクライアントとサーバのアプリ
ケーションと同一のアドレス空間に存在しないことに、
注意すべきである。従って、アクティブなクライアント
・アプリケーションとサーバ・アプリケーションは、そ
れぞれ、少なくとも１つのシャドウ・タスクをNSFイン
タフェースにもっている。リクエスト・データのプレゼ
ンテーションは、プロセス・アドレス空間内で扱われ、
具体的には、動的構成可能プロトコル・スタックのプレ
ゼンテーション層内で取り扱われる。RPCオブジェクト
は、クライアント−サーバ・プロトコルを呼び出すが、
新規のプロコトル・スタックのアプリケーション層で生
成されるのが典型的である。APIトランスポート・オブ
ジェクトは、それらのアドレス空間の間でそのリクエス
ト・データをプレゼンテーションするための一貫したフ
ォーマットを保証するのに用いられる。

図８は新規の動的構成可能スタック800を示す概略ブ
ロック図である。動的構成可能スタック800は、垂直方
向にリンクされた一連のプロトコル層であって、名前が
OSIプロトコル層モデルとよく似た一連のプロトコル層
を備えている。プロトコル・スタックは、各層が、図８
にプロトコル層825として示す単一の抽象基底クラスか
ら派生したオブジェクトであって、当該クラスに関係付
けをした関数、例えば、下位および上位のプロトコル・
オブジェクトを“get"することにより、アクセスするこ
とができるオブジェクトが好ましい。プロトコル・スタ
ックのこれらの層には、「アプリケーション」層と、
「プレゼンテーション」層と、「セッション」層と、
「トランスポート」層と、「ネットワーク」層と、「フ
ァミリ」層と、「カプセレータ」層と、「データリン
ク」層と、「物理」層が含まれている。一般的に、これ
らの層の構造と機能は、クライアント・ノードとサーバ
・ノードで同様である。

具体的には、アプリケーション層オブジェクト802
は、プロトコルとインタフェース情報とをハンドルし
て、クライアントおよびサーバ・ノードに対してオペレ
ートされているアプリケーション・プログラムと、デー
タ、例えば、データ・リクエスト／応答を交換する。プ
レゼンテーション層オブジェクト804は、アプリケーシ
ョン層オブジェクト802から伝送されたデータのプレゼ
ンテーションを専ら行うのに対して、セッション層オブ
ジェクト806はトランスポート・サービスをアプリケー
ションに関係付けをすることを担当する。トランスポー
ト層オブジェクト808はデータをフォーマットしてパケ
ットにし、ネットワークを介して、リモート・ピア、つ
まり、別のトランスポート層に伝送する。別のトランス
ポート層への伝送ステップは、データをパケットにコピ
ーするためのネットワーク・バッファ（図示せず）を獲
得することにより行われる。各パケットにコピーするこ
とができるデータ量は、採用されたプロトコルによって
変化する。プロトコルに関する情報はトランスポート・
ヘッダに入っているが、このトランスポート・ヘッダは
パケット化する前にトランスポート層により獲得されて
いなければならない。データが一旦コピーされると、そ
のデータはトランスポート・ヘッダ情報と共にカプセル
化され、ネットワーク層に渡される。

本発明によれば、ネットワーク層オブジェクト810
は、プロトコル・アーキテクチャの一部であって、プロ
トコル・スタック800の特定のインスタンシエートに関
するステート情報を含むものを表わす。このステート情
報には、このオブジェクトのピア（peer）のネットワー
ク・アドレス、つまり、NSAP（network service access
point）と、プロトコル・スタック800によりサポート
される上位レベル・プロトコルのタイプとが含まれてい
る。具体的には、ネットワーク層オブジェクト810は、
トランスポート層から送られてきたデータを自身のヘッ
ダと共にカプセル化する。ネットワーク・ヘッダに入れ
られる典型的な情報は、リクエスト／応答のソース・ア
ドレスとデスティネーション・アドレスである。カプセ
ル化された情報は、図示しないバッファにロードされ、
ファミリ層オブジェクト812に渡され、例えば、正しいc
apsulatorオブジェクトをアクセスして適正なデータ・
リンクにディスパッチされる。

ファミリ層オブジェクト812は、ネットワーク層オブ
ジェクトの非複製部分、例えば、ルーチング情報を表わ
す。具体的には、ファミリ層オブジェクトは、プロトコ
ル・アーキテクチャのベースを表わし、正しいdata lin
kオブジェクトを選択してパケットを供給することを担
当している。

カプセレータ層814には、サポートされるデータリン
ク・プロトコルと、ネットワーキング・プロトコル・ア
ーキテクチャに関する情報を含む複数のcapsulatorオブ
ジェクトが含まれている。これらのカプセレータ、つま
り、特殊化されたシム（specialized shim）は、MAC（m
edium access control）アドレシング情報をアウトバウ
ンド・パケットに追加し（カプセル化し）、インカミン
グ・パケットのMACアドレシング情報を解釈する（デカ
プセル化する）。具体的には、capsulatorオブジェクト
は正しいデータリンク・ヘッダと一緒にパケットをカプ
セル化する。パケットをカプセル化するために必要な情
報は、そのバッファから取り出される。その情報には、
プロトコル固有のフォーマットのデスティネーション・
アドレスと、データ・リンク、つまり、ソースのアドレ
スとが含まれている。デスティネーション・アドレスは
特定のデータリンク・フォーマットに「マッピング」さ
れて、データリンク層に渡される。

データリンク層オブジェクト816はフレーミングされ
たバイト（framed bytes）をカプセレータ層814から受
け取り、それらのバイドを物理層オブジェクト818に供
給する。物理層オブジェクト818はそれらのバイトをネ
ットワーク上に伝送する。具体的には、データリンク・
オブジェクトはISR（interrupt service routine）によ
り処理するため、そのバッファにキュー（queue）す
る。ISRは、ハードウェア割込みを直接に取り扱うプロ
セスである。具体的には、ISRは、ネットワーク・アダ
プタ・デバイスとの間でデータを移動することを担当し
（図６の645と685を参照）、当該デバイスのアクション
を制御することを担当している。data linkオブジェク
トがバッファをアクセスすると、パケットが完全にフォ
ーマットされ、例えば、ポインタとバイト長により記述
される。

各層は、次に下位層が理論的順番が下位のプロトコル
をエクスポートするものと予測するのが典型的である。
しかし、必ずしもそうであるとは限らない。従って、一
般的には、ある層が特定の隣接する層を予測することが
できない。ある層が特定の隣接する層を予測することが
できない場合には、シムを用いて、プロトコル層を任意
にスタッキングすることができる。シムとは特殊変換オ
ブジェクトであって、プロトコル層間に挿入して、種々
の問題、例えば、層自体を混乱させることなく、２つの
似通っていない層を共にマッピングするか、あるいは、
２つの層から見て透過になるように既存の２つの層に機
能を追加するような問題を解決することができるオブジ
ェクトである。

実際のデータ通信は２つのプロトコル・スタックの物
理層間で通信チャネルを介して行われるのであるが、リ
モート・スタックのある層と同じレベルの層であって、
一方のスタックのある層である「ピア」と、各層が通信
を行っていると考えることができる。例えば、図８から
分かるように、上位のプロトコル層802と804はノードの
プロセス・アドレス空間830に駐在する。これらの層
は、ノードの各アプリケーションに対して一意であり、
リモート・ノードの上位の個々のプロトコル層と通信を
行う。他方、下位のプロトコル層806〜818は、全てのア
プリケーションにより共有され、そのため、あるノード
のシステム・アドレス空間840に駐在しており、リモー
ト・ノードの対応する下位のプロトコル層と通信を行
う。

これまで説明したように、アウトバウンド・データ・
リクエスト、例えば、伝送または送信リクエストは、ア
プリケーションからトランスポートを「介して」NSFへ
転送され、このNSFにて、このデータ・リクエストは、
シャドウ・タスク、つまり、新規のスタックのセッショ
ン層でオペレートしているプロトコル・トランスレータ
によってサービスされる。本発明によれば、プロトコル
・トランスレータ（セッション層）の直接のクライアン
トはAPIトランスポートである。プロトコル・トランス
レータは、一般的に、トランスポート「に対する」リク
エストを既存のプロトコル・スタックと関係付けをし、
その後、データ・リクエストをパケットにコピーし、パ
ケットを新規のプロトコル・スタックの下位層に供給す
る。

RPCオブジェクト 図９は900で示すCSFインタフェースと対話するために
アプリケーション・プログラムにより用いられるRPCオ
ブジェクトを示す概略図である。これらの事前定義され
たオブジェクトは、必要とする「クライアント−サーバ
通信」のタイプにより、アプリケーション・プログラム
またはオペレーティング・システムより作成される。

本発明によれば、RPCオブジェクトはcallerオブジェ
クト902と、dispatcherオブジェクト904と、transport
オブジェクト906を備えている。これらのオブジェクト
は、それぞれ、データと、そのデータに対してオペレー
トされる関数とを備えている。具体的には、callerオブ
ジェクト902は、対応するdispatcherオブジェクト902内
の他の場所に駐在している「リモート」リクエストをコ
ールするため、高レベルRPCプロトコルを提供する。dis
patcherオブジェクト904は、callerオブジェクト902に
よって呼び出された関数を解釈し、その後、これら呼び
出された関数にディスパッチして、callerオブジェクト
902を補足する。transportオブジェクト906は、caller/
dispatcher protocolオブジェクトと、それぞれに対応
するデータリクエストとを分離して、特定のトランスポ
ート・メカニズムにトランスポートする。すなわち、tr
ansportオブジェクトは、callerオブジェクトと、対応
するdispatcherオブジェクトとの間で発行された要求を
ハンドルする。

callerオブジェクト902とtransportオブジェクト904
は、自分のクラスであるRemoteCallerとRemoteDispatch
erからそれぞれコンストラクトされる。これらのクラス
は、agreed upon remote requestプロトコルであって、
「クライアント」アプリケーションにより発行されたリ
クエストを識別し、「サーバ」で、適正なクラスと関数
に自動的にディスパッチするプロトコルを実現する。tr
ansportオブジェクト906は自分のクラスであるRemoteCa
llerTransportからコンストラクトされる。このRemoteC
allerTransportクラスは、特に引数と結果ストリームを
含むトランスポート・メカニズムの特性と、あるリクエ
ストを送信するためにコール側により呼び出されたメソ
ッドと、あるリクエストを開始し終了するのに必要な振
る舞いを定義する。caller/dispatcherクラスはtranspo
rtクラスとは無関係にコンストラクトされ、必要に応じ
て、トランスポートと置換されることに注意すべきであ
る。

本発明によれば、サーバ・ノードで資源を管理するた
め、典型的には、これらサーバ・ノードで、サブオブジ
ェクトを提供することができる。これらのサブオブジェ
クトは「親」caller/dispatcherオブジェクトの「子」
であり、これらのオブジェクトをリモートで実現するた
めの関数を含む。具体的には、これらサブオブジェクト
は、データとプロトコルの両方をリモートにできるとい
うプロパティを有するので、RPCリクエストにより関数
コールを行うことができる。これらのプロトコルは相互
に独立しているので、「親」と「子」の間にプロトコル
関係がある必要はない。さらに、クライアント・ノード
では、親と子のプロトコル・オブジェクトはトランスポ
ートを共有する。サーバ・ノードでは、親はその子オブ
ジェクトを「モニタ」する。その結果、子のリクエスト
を正しい子のインスタンスにマッピングすることがで
き、その結果、ディスパッチすることができる。

RPCリクエスト中に生じた例外は、caller/dispatcher
クラスを用いてハンドルされる。つまり、サーバが例外
を引き起こした場合、結果の代わりにその例外が返さ
れ、クライアントに供給される。コール側で例外が生じ
た場合は、その例外はコール側によりハンドルされる。
結果がサーバからクライアントに流れている間に例外が
生じた場合、その例外は、その結果がアンフラット化さ
れると、クライアントに現われる。

APIオブジェクト 図10は、1000で示すCSFインタフェースと対話するた
めに、アプリケーション・プログラムにより用いられる
APIオブジェクトを示す概略図である。これらのオブジ
ェクトは、それぞれ、データと、そのデータに対してオ
ペレートされる関数とを備え、各オブジェクトを、採用
された「クライアント−サーバ通信」のタイプにより、
アプリケーション・プログラムまたはOSにより作成する
ことができる。

編成上、APIオブジェクトを次の３つの異なるモデル
・グループに分割することができる。すなわち、（ｉ）
クライアント・ノードとサーバ・ノード間で、典型的な
（短期）同期・送信−受信−応答データストリーム・ト
ランザクションを確立するために用いられる「リクエス
ト／応答」モデル・オブジェクトと、（ii）複数の（長
期関係付けをした）サービス・リクエストに、これらの
ノードを「バインド」するためのPROSE（partial remot
e operation service element）モデル・オブジェクト
と、（iii）各ノード内にデータリクエストを送信し、
各ノードからデータを受信するのに用いられる「ローカ
ル」モデル・オブジェクトに分割することができる。

図10を説明する。CSF（API）インタフェース1000のre
mote sender streamオブジェクト1002とremote receive
r streamオブジェクト1004は「リクエスト／応答」モデ
ルに関係するオブジェクトである。PROSEモデルには、b
ound remote sender streamオブジェクト1006とbound r
emote receiver streamオブジェクト1008が含まれてお
り、これに対して、「ローカル」モデルは専らlocal st
reamオブジェクト1010を備え、local streamオブジェク
ト1010は自分のクラスからコンストラクトされる。後者
のモデルは非同期のデーへ送受信をサポートし、全二重
通信をサポートしている。

大まかに言うと、「リクエスト／応答」モデルは、サ
ーバ・ノードが任意の数のクライアント・ノードｋらリ
クエストを受信する状況で採用される。上述したよう
に、通信は、これらのノードで実行されるクライアント
・アプリケーションとサーバ・アプリケーションの間
で、同期・送信／応答トランザクションの形式をとる。
一例として、クライアント・アプリケーションはリクエ
ストをサーバ・タスク・アプリケーションに送信する。
サーバ・アプリケーションは、そのリクエストを受信す
ると直ちに、そのリクエストを処理し、（必要な場合
は）応答を計算し、後でクライアント・アプリケーショ
ンによって受信された応答を返す。この例では、remote
sender streamオブジェクト1002はリクエストを送信し
応答を受信するために、クライアント・アプリケーショ
ンによって使用され、一方、remote receiver streamオ
ブジェクト1004はリクエストを受信し応答を送信するた
めに、サーバ・アプリケーションによって使用される。

PROSEモデルは、一般的に、クライアント・アプリケ
ーションがサーバ・アプリケーションとの長期関係付け
を必要とする状況で、リクエスト／応答トランザクショ
ンを提供する。この関係付けはコネクション・シーケン
スによって開始され、ディスコネクション（disconnect
ion）・シーケンスによって終了されるのが典型的であ
る。関係付けの間、サーバ・アプリケーションにより受
信されたリクエストは、それぞれ、「送信」クライアン
ト・アプリケーションを示す識別名（identification）
を含む。さらに、stateオブジェクトを各クライアント
と関係付けをすることもできる。PROSEオブジェクトを
必要とするトランザクションの場合、bound remote sen
der streamオブジェクト1006は、サーバ・アプリケーシ
ョンとの長期関係付けを確立し、リクエストを送信し応
答を受信するために、サーバ・アプリケーションにより
使用される。bound remote receiver streamオブジェク
ト1008は、クライアント・アプリケーションとの関係付
けを確立し、リクエストを受信し応答を送信するため、
サーバ・アプリケーションによって用いられる。

上述したように、これらのAPIオブジェクトは、単一
のノードに駐在するアプリケーション間か、あるいは、
２つのリモート・ノード間に、通信インタフェースを提
供するようにオペレートする。しかし、APIオブジェク
トは、APIオブジェクト自身で、通信トランスポート、
つまり、データ・ストリームをノード内のみに提供す
る。２つのノードの間でリモート通信を行うために、AP
IオブジェクトとRPCオブジェクトは、NSFインタフェー
スの動的構成可能・プロコトル・スタックのセッション
層でオペレートするプロトコル・トランスレータと通信
する。セッション層のこのトランスレータは、当該ノー
ドの通信モデル、例えば、「リクエスト／応答」と、プ
ロトコル・スタックの両方と対話する。さらに、このト
ランスレータにより、「クライアント」のプロトコル・
スタックがネットワーク通信チャネルを介してサーバプ
ロトコル・スタックと通信することができる。これらAP
Iオブジェクトのオペレーションをもっと理解するた
め、これらのオブジェクトの振る舞いを備えた主要な関
数ルーチンと共に、そのコンストラクションを試験する
ことが有用である。これらオブジェクトを試験する際に
は、オブジェクトをコンストラクトするのに用いられる
クラスも試験するのが有用である。（上述したように、
クラスはオブジェクトをコンストラクトするためのテン
プレートとしてサーブする）。従って、オブジェクトが
一度コンストラクトされると、クラスと、各クラスに固
有の関数との関係を用いて、オブジェクトの振る舞いを
予測することができる。

図11はAPIオブジェクトの簡略化したクラス階層を示
す。remote sender streamオブジェクトをコンストラク
トするために用いられた（ボックス1104で示す）クラス
は、Sender Stream 1006と呼ばれる抽象基底クラスのサ
ブクラスである。クラスSender Streamはボックス1108
で示すStreamのサブクラスである。従って、Sender Str
eam 1106は、Streamで利用可能なストリーミング演算
子、例えば、送信と、受信と、応答のような関数を、Re
mote Sender Streamクラス1104のオブジェクトに提供す
る。さらに、Sender Streamクラス1004は、そのサブク
ラスを実現するのに内部で用いられるプロトコルを定義
する。

remote receiver streamオブジェクトをコンストラク
トするために用いられる（ボックス1112で示す）クラス
は、別の抽象基底クラスであるReceiver Stream1110の
サブクラスである。Remote Receiver Streamクラス1112
と他のサブクラスを実現するのに用いられるプロトコル
を定義している間、ReceiverStream1110も、Stream1108
のもう１つのサブクラスとして、上述したStreamのスト
リーミング演算子を、Remote Receiver Streamオブジェ
クトに提供する。

bound remote sender streamオブジェクトをコンスト
ラクトするのに用いられる（ボックス1102で示す）クラ
スは、Remote Sender Streamクラス1104のサブクラスで
あり、bound remote receiver streamオブジェクトをコ
ンストラクトするのに用いられる（ボックス1114で示
す）クラスは、Remote Receiver Streamクラス1112のサ
ブクラスである。

スタック構成 図12はクライアント・ノード1200を示す。クライアン
ト・ノード1200では、RPCサービス・リクエストを呼び
出す前に、データ・パスを構成するため、オブジェクト
指向CSFインタフェース1210とNSFインタフェース1220が
利用される。システム・アドレス空間1205に置かれたデ
ィレクトリ・サービス1202には、ネットワークで利用可
能なサービスをアクセスするのに必要なプロトコル・ス
タックのタイプを定義し、そのため、必要とされるデー
タ・パスを定義するサービス・オブジェクトが含まれ
る。アプリケーション1214は、ノード1200で実行され、
transportオブジェクト1222とremote streamオブジェク
ト1224であって、それぞれ、プロセス・アドレス空間12
12に駐在しているオブジェクト1220および1224と対話す
る。

アプリケーション1214と、CSFインタフェース・オブ
ジェクトとの対話は矢印1215で示す。システム・アドレ
ス空間1205では、CSFインタフェース1230は別のremote
streamオブジェクト1232と、protocol translatorオブ
ジェクト1234を備え、protocol translatorオブジェク
ト1234は動的構成可能プロトコル・スタックのセッショ
ン層でオペレートするのが好ましい。remote streamオ
ブジェクト間の対話は矢印1225で示す。CSFインタフェ
ース1230は、矢印1235で示すように、動的構成可能プロ
トコル・スタック1240と対話する。さらに、protocol t
ranslatorオブジェクト1234はバッファ1236と対話し
て、アドレス情報をストアし、そのアドレス情報を検索
する。サーバ・ノードは図12に示していないが、サービ
ス・リクエストに応答するため、データ・パスを構成す
るのに必要になる構成要素は、一般的に、上述したもの
と同一であることに注意すべきである。典型的には、タ
スク・アプリケーション・プログラムは、サービス・リ
クエストに応答するため、資源を提供する。

図13は、RPCサービス・リクエストを呼び出す前に、
クライアント・ノードのデータ・パスを構成するステッ
プのシーケンスを示すフローチャートである。このシー
ケンスはステップ1300から始まり、ステップ1302に進
み、ステップ1302にて、特定のサービスを要求するクラ
イアント・アプリケーションは、ディレクトリ・サービ
スからserviceオブジェクトを取得する。serviceオブジ
ェクトは２つの部分、すなわち、スタック定義の参照
と、リモート・サービスのアドレスを備えているのが典
型的である。スタック定義はそれ自体がオブジェクトで
あり、クライアント・アプリケーションからNSFインタ
フェースに渡され、動的構成可能プロトコル・スタック
をインスタンシエートする。リモート・サービスのアド
レスは、リモート・プロトコル・スタックのASAP（appl
ication service access point）である。

次に、ステップ1304にて、クライアント・アプリケー
ションはtransportブジェクトとremote streamオブジェ
クトを作成する。具体的には、transportブジェクトはr
emote streamオブジェクトを作成し、remote streamオ
ブジェクトはserviceオブジェクトを引数として「渡
す」。すなわち、ステップ1306にて、remote streamオ
ブジェクトは、NSFインタフェースのプロトコル・スタ
ックのセッション層まで達しているデータストリームを
「オープン」し、serviceオブジェクトをそのストリー
ム上に挿入する。

この事例でのクライアント−サーバ通信とは、そのノ
ードのアプリケーション・プログラムとNSFインタフェ
ースとの間の通信のことであるので、「クライアント」
はアプリケーション1214（図12）であり、transportオ
ブジェクトの受信側はシステム・アドレス空間の動的構
成可能プロトコル・スタックのセッション層に駐在する
プロトコル・トランスレータ、つまり、「サーバ」であ
る。

ステップ1308にて、プロトコル・トランスレータはse
rviceオブジェクトをデータストリームから取り出し、
スタック定義を用いて、リモート・サービスと通信する
ようにプロトコル・スタックを構成する。そして、プロ
トコル・スタックは、ステップ1310にて、ASAPリモート
・アドレスをバッファにストアし、つまり、キャッシュ
し、新しく構成されたプロトコル・スタックのSSAP（se
ssion service access point）を、データ・ストリーム
に乗せて、クライアント・アプリケーションに返す。そ
して、ステップ1312にて、クライアント・アプリケーシ
ョンはSSAPアドレスをサービス・ディレクトリに記録
し、よって、ステップ1314にて、データ・パス構成シー
ケンスを完了する。

RPCサービス・リクエスト 図14は、クライアント・ノード1410とサーバ・ノード
1450を含むクライアント−サーバ・システム1400を示す
概略ブロック図である。クライアント−サーバ・システ
ム1400では、RPCサービス・リクエストを呼び出し、そ
のサービス・リクエストに応答するため、オブジェクト
指向CSFインタフェースとNSFインタフェースが利用され
る。アプリケーション1414はクライアント・ノード1410
に対して実行され、適正なプロトコル・スタックのSSAP
アドレスを含むリクエスト1416を生成する。しかし、本
発明はこの実施の形態では、アプリケーション1414は、
それぞれ、プロセス・アドレス空間1412に駐在するcall
er/transportオブジェクト1422とremote streamオブジ
ェクト1424を介して、CSFインタフェース1420と対話す
る。アプリケーション1414とCSFインタフェース1420と
の対話は矢印1415で示す。

システム・アドレス空間1430では、protocol transla
torオブジェクト1434は、動的構成可能プロトコル・ス
タック1432のセッション層でオペレートしている。prot
ocol translatorオブジェクトとremote streamオブジェ
クト1424との対話は矢印1425で示す。さらに、protocol
translatorオブジェクト1434とプロトコル・スタック1
438の下位層との対話は矢印1435で示す。さらに、proto
col translatorオブジェクト1234はバッファ1436と対話
して、アドレス情報をストアしそのアドレス情報を取り
出す。

サーバ・ノード1450では、タスク・アプリケーション
1454は、プロセス・アドレス空間1452にそれぞれ駐在す
るdispatcherオブジェクト1462とremote streamオブジ
ェクト1464を介してCSFインタフェース1460と対話す
る。タスク・アプリケーション1454とCSFインタフェー
ス1460との対話は矢印1455で示す。クライアント・ノー
ド1410と同様に、protocol translatorオブジェクト147
4はシステム・アドレス空間1470に駐在する動的構成可
能プロトコル・スタック1472のセッション層でオペレー
トしている。protocol translatorオブジェクトとremot
e streamオブジェクト1464との対話は矢印1465で示し、
protocol translatorオブジェクト1474とプロトコル・
スタック1478の下位層との対話は矢印1435で示す。最後
に、protocol translatorオブジェクト1274はバッファ1
476と対話して、アドレス情報をストアし、そのアドレ
ス情報を検索する。

図15は、クライアント・ノードとサーバ・ノードで、
RPCサービス・リクエストを呼び出し、そのRPCサービス
・リクエストに応答する際のステップのシーケンスを示
すフローチャートである。このシーケンスはステップ15
00から開始され、ステップ1502に進み、ステップ1502に
て、サービスへのアクセスを望むクライアント・アプリ
ケーションは、callerオブジェクトとtransportオブジ
ェクトを作成し、フォーマットされるリクエストを発行
する。ステップ1504にて、transportオブジェクトはNSF
インタフェースにデータ・ストリームを「オーブン」す
るremoteオブジェクトを作成する。データ・パスは事前
に構成されているので、クライアント−サーバ通信で
は、サービス・リクエストをアプリケーション1414（図
14）つまり「クライアント」から、リモート・サーバ・
ノードのアプリケーション1454つまり「サーバ」に転送
される。

そして、サービス・リクエストは適正なプロトコル・
スタックのSSAPを含めて、データ・ストリーム上に「ス
トリーミング」され、プロトコル・トランスレータによ
り受信される。このプロトコル・トランスレータは、サ
ービス・リクエストを適正なプロトコル・スタックのセ
ッション層アドレスに渡す（ステップ1506）。プロトコ
ル・トランスレータはリモート・ノードの適正なピアの
セッションにそのリクエストを供給することができる。
具体的には、プロトコル・トランスレータはキャッシュ
されたASAPリモート・アドレスをバッファから取り出し
（ステップ1508）、取り出されたASAPリモート・アドレ
スをデスティネーション・アドレスとしてサービス・リ
クエストに追加する。ステップ1510にて、パケットとし
て送信するためフォーマットされたサービス・リクエス
トは、プロトコル・スタックを下り、ネットワーク通信
チャネルに渡される。

サーバ・ノードでは、リクエスト・パケットはプロト
コル・スタックで、再フォーマット（ソース・アドレス
をパケットから剥ぎ取り、そのアドレスをキャッシュす
ることを含む）される（ステップ1512）。ステップ1514
にて、リクエストは、スタックを上り適正なASAPデステ
ィネーション・アドレスに渡される。具体的には、その
リクエストがサーバのセッション層に到達すると、その
リクエストが試験され、具体的なサービスを提供する層
を一意的に識別するASAPが取り出される。そして、事前
定義されたdispatcherオブジェクトと、そのdispatcher
オブジェクトに関係付けをしたメソッドが、そのデータ
・ストリームからリモート・リクエストを取り出し、取
り出されたリモート・リクエストを適正なタスクに渡
し、サービスを実行するように、データ・ストリーム
が、事前定義されたリモート・ストリーム・オブジェク
トにより作成される（ステップ1516）。サーバの特定の
資源と関係付けをしたサブオブジェクトが、サービスを
実行することができることが良くある。長期PROSEトラ
ンスポート・トランザクションの場合、サーバが応答す
るまで、サーバとトランスポート・データ・ストリーム
がASAPにバインドされていることに注意すべきである。

応答が必要でない場合には（ステップ1518）、シーケ
ンスはステップ1520で終了する。応答が必要な場合に
は、ステップ1522にて、その応答をデータ・ストリーム
上に挿入して、その応答がディスパッチャにより返され
る。その応答はプロトコル・スタックを下り、（以前
の）ソース・アドレスがデスティネーション・アドレス
として応答に追加される（ステップ1524）。そして、ス
テップ1526にて、その応答はパケットとして再送するた
めフォーマットされ、ネットワークを介してフォワーデ
ィングされる。ステップ1528にて、パケットはクライア
ント・ノードにより受信され、適正なスタックを上がっ
てクライアント・アプリケーションに渡される。よっ
て、RPCリクエストはステップ1530で完了する。長期関
係付けの場合、リクエスト・クライアントにその応答が
返されるとき、その応答はバウンド・パスを介して送信
され、よって、アドレシング情報を必要としないことに
も注意すべきである。

以上、本発明の特定の実施の形態に限定して説明して
きたが、当然、本発明を修正および変更することがで
き、本発明の効果を奏することができる。そのため、請
求の範囲の目的は、本発明の精神と範囲を逸脱せず行わ
れた修正および変更を包含することにある。

フロントページの続き (56)参考文献 米国特許5548723（ＵＳ，Ａ) Ａｌｏｋ Ｓｉｎｈａ，Ｃｌｉｅｎｒ −Ｓｅｒｖｅｒ Ｃｏｍｐｕｔｉｎｇ, ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＯＦ ＴＨＥ ＡＳＳＯＣＩＡＴＩＯＮ ＦＯ Ｒ ＣＯＭＰＵＴＩＮＧ ＭＡＣＨＩＮ ＥＲＹ，米国，ＡＣＭ，1992年７月，Ｖ ＯＬ．35，ＮＯ．７，77−98 Ｓ．Ｍａｒｋ Ｋｌｅｒｅｒ，Ｔｈｅ ＯＳＩ Ｍａｎａｇｅｍｅｎｔ Ａｒ ｃｈｉｔｅｃｔｕｒｅ；ａｎ Ｏｖｅｒ ｖｉｅｗ，ＩＥＥＥ ＮＥＴＷＯＲＫ： ＴＨＥ ＭＡＧＡＺＩＮＥ ＯＦ ＣＯ ＭＰＵＴＥＲ ＣＯＭＭＵＮＩＣＡＴＩ ＯＮＳ，米国，ＩＥＥＥ，1988年３月, ｖｏｌ．２，ｎｏ．２，20−29 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 13/00 357 G06F 13/00 351 H04L 12/00 ＥＵＲＯＰＡＴ（ＱＵＥＳＴＥＬ) ＩＮＳＰＥＣ（ＤＩＡＬＯＧ) ＪＩＣＳＴファイル（ＪＯＩＳ) ＷＰＩ（ＤＩＡＬＯＧ)

Claims (10)

(57)【特許請求の範囲】
1. 【請求項１】クライアント・ノード（610,710,1410）が
   リモート・プロシージャ・コールによりサーバ・ノード
   （650,750,1450）からサービスをリクエストすることが
   できるように、前記クライアント・ノードを前記サーバ
   ・ノードに結合するマルチ・ノード・コンピュータ・ネ
   ットワーク・システムにおいて、 少なくとも１つのプロセッサ（402,502）と、該１つの
   プロセッサに接続したメモリ（404,406,504,506,513）
   とを有するクライアント・ノードとサーバ・ノードであ
   って、前記少なくとも１つのプロセッサにより制御され
   るクライアント・ノードとサーバ・ノードと、 前記クライアント・ノードと前記サーバ・ノードの間で
   通信を行うために、前記クライアント・ノードと前記サ
   ーバ・ノードを結合するためのネットワーク（316,315,
   366）であって、複数のプロトコル層で形成された事前
   に定義されたネットワーク・プロトコルを有するネット
   ワークと を有するコンピュータ・ネットワーク・システムにおい
   て、 （ａ）前記クライアント・ノードは、さらに、動的構成
   可能プロトコル・スタック（732,772,800,1240）により
   制御されている前記ネットワークを介して通信を行う手
   段を備え、前記スタックは複数の層オブジェクト（802
   −818）を備え、各層オブジェクトは前記プロトコルの
   プロトコル層のうちの１つのプロトコル層に対応してお
   り、 （ｂ）前記ネットワーク・プロトコルのプロトコル定義
   を決定する手段と、 （ｃ）前記クライアント・ノードが、前記ネットワーク
   ・プロトコルに従って、前記ネットワークを介して、サ
   ーバ・ノードに、リモート・プロシージャ・コールを供
   給し、前記サーバ・ノードからサービスをリクエストす
   ることができるように、前記プロトコル定義に応答し
   て、前記プロトコル・スタックの層オブジェクトを構成
   するする手段と を備えたことを特徴とするコンピュータ・ネットワーク
   ・システム。
2. 【請求項２】請求項１において、前記クライアント・ノ
   ードは、複数のサービス・オブジェクトであって、それ
   ぞれ、リモート・サービスに対応し、それぞれ、スタッ
   ク定義（1302）への参照を含む複数のサービス・オブジ
   ェクト（1204）を、さらに、含み、 前記プロトコル定義を決定する手段は、前記ディレクト
   リ・サービスをアクセスして前記複数のサービス・オブ
   ジェクトのうちの１つのサービス・オブジェクトを獲得
   し、スタック定義への参照を前記プロトコル定義として
   獲得し、 前記構成する手段は、前記再構成可能プロトコル・スタ
   ックを構成し、前記プロトコル定義に対応させるため、
   複数の層オブジェクトをインスタンシエートする手段を
   含む ことを特徴とするコンピュータ・ネットワーク・システ
   ム。
3. 【請求項３】請求項２において、前記ネットワーク・プ
   ロトコルは、セッション層と、複数の下位層を含み、 前記決定する手段は前記セッション層に対応するセッシ
   ョン層オブジェクトに駐在し、 前記構成する手段は前記プロトコルの下位層に対応する
   下位層オブジェクトをインスタンシエートする ことを特徴とするコンピュータ・ネットワーク・システ
   ム。
4. 【請求項４】請求項２において、前記構成する手段は、
   前記プロトコル・スタックを参照するため、セッション
   ・サービス・アクセス・ポイントを提供する手段を含む
   ことを特徴とするコンピュータ・ネットワーク・システ
   ム。
5. 【請求項５】請求項２において、前記サービス・オブジ
   ェクトはアプリケーション・サービス・アクセス・ポイ
   ントをさらに含み、 前記通信する手段は、前記サーバ・ノードと通信を行う
   ために、デスティネーション・アドレスを有するネット
   ワーク・リクエストを用い、 前記クライアント・ノードは、前記アプリケーション・
   サービス・アクセス・ポイントをキャッシュする手段を
   含み、前記ネットワークを介して伝送されたリモート・
   プロシージャ・コールを含むネットワーク・リクエスト
   のデスティネーション・アドレスとして、アプリケーシ
   ョン・サービス・アクセス・ポイントを追加することに
   より、対応するリモート・サービスを得るため、リモー
   ト・プロシージャ・コールを発行する手段を含む ことを特徴とするコンピュータ・ネットワーク・システ
   ム。
6. 【請求項６】クライアント・ノード（610,710,1410）が
   リモート・プロシージャ・コールによりサーバ・ノード
   （650,750,1450）からサービスをリクエストすることが
   できるように、前記クライアント・ノードと前記サーバ
   ・ノードをネットワーク（316,315,366）を介して結合
   する方法であって、該ネットワークが、複数のプロトコ
   ル層で形成された事前定義されたネットワーク・プロト
   コルを有し、各ノードが、１つのメモリ（404,406,504,
   506,513）を接続した少なくとも１つのプロセッサ（40
   2,502）有する方法において、 （ａ）前記クライアント・ノードが前記ネットワーク・
   プロトコルのプロトコル定義を決定するステップと、 （ｂ）前記クライアント・ノード・メモリの複数の層オ
   ブジェクトであって、それぞれ、前記プロトコル層のう
   ちの１つのプロトコル層に対応する層オブジェクトを定
   義し、 （ｃ）前記層オブジェクトを構成して、前記ネットワー
   ク・プロトコルを示す再構成可能プロトコル・スタック
   にするステップと、 （ｄ）前記クライアント・ノードが、プロトコル・スタ
   ックを制御して、リモート・プロシージャ・コールを前
   記ネットワークを介してサーバ・ノードに発行し、該サ
   ーバ・ノードからのサービスをリクエストするステップ
   と を備えたことを特徴とする方法。
7. 【請求項７】請求項６において、前記クライアント・ノ
   ードが、それぞれ、リモート・サービスに対応し、それ
   ぞれ、スタック定義への参照を含む複数のサービス・ノ
   ードを備え、 前記ステップ（ａ）は、 （a.1）前記ディレクトリ・サービスをアクセスして、
   前記複数のサービス・オブジェクトのうちの１つのサー
   ビス・オブジェクトを獲得し、具体的なスタック定義へ
   の参照を前記プロトコル定義として獲得するステップを
   備え、 前記ステップ（ｃ）は、 （c.1）前記プロトコル定義に対応するプロトコル・ス
   タックを形成するため、複数の層オブジェクトをインス
   タンシエートするステップを備えた ことを特徴とする方法。
8. 【請求項８】請求項７において、前記ネットワーク・プ
   ロトコルはセッション層と複数の下位層を備え、 前記ステップ（ｃ）は （c.2）前記プロトコルの下位層に対応する下位層オブ
   ジェクトをインスタンシエートするステップを備えた ことを特徴とする方法。
9. 【請求項９】請求項７において、前記ステップ（ｃ）は （c.3）前記プロトコル・スタックを参照するため、セ
   ッション・サービス・アクセス・ポイントを提供するス
   テップと、 （c.4）前記対応するプロトコル・スタックをアクセス
   するため、前記セッション・サービス・アクセス・ポイ
   ントを用いることができるように、対応するリモート・
   サービスによるその後のアクセスにより、前記セッショ
   ン・サービス・アクセス・ポイントを前記ディレクトリ
   ・サービスにストアするステップと を備えたことを特徴とする方法。
10. 【請求項１０】請求項７において、前記サービス・オブ
    ジェクトは、アプリケーション・サービス・アクセス・
    ポイントをさらに含み、 前記ステップ（ｄ）は （d.1）デスティネーション・アドレスを含むネットワ
    ーク・リクエストを、リモート・プロシージャ・コール
    を含めて、発行するステップと、 （d.2）前記クライアント・ノードに前記アプリケーシ
    ョン・サービス・アクセス・ポイントをキャッシュする
    ステップと、 （d.3）前記ネットワークを介して伝送されたリモート
    ・プロシージャ・コールを含むネットワーク・リクエス
    トのデスティネーション・アドレスとして、前記アプリ
    ケーション・サービス・アクセス・ポイントを追加する
    ステップと を備えたことを特徴とする方法。