JPH09171465A - 異なる命名サービス・プロバイダが動的に命名フェデレーションに接合することを可能とするシステムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 システム実施者がクライアント・アプリケー
ションを中断せずに、新しい命名システムを動的あるい
は静的にインストールすることを可能とする。 【解決手段】 本発明は４種類の名前サービス（アトム
名、複合名、部分コンポジット名およびコンポジット
名）に対する連合命名サービス・プロバイダ・インタフ
ェース（「ＦＮ ＳＰＩ」）を、クライアント・アプリ
ケーションと名前サービスの間にあり、コンポジット名
の分解のための呼出しの変換およびアドミニストレーシ
ョンをサポートしていて、クライアント・アプリケーシ
ョンが利用可能なＦＮ ＳＰＩ（所与のシステムに２つ
以上のＦＮ ＳＰＩがあってもよい）を適切に使用する
ことを可能とする「ＦＮフレームワーク」という機構と
ともに含んでいる改善された連合命名フレームワーク・
システムを提供する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は分散コンピューティ
ング・システム、クライアント・サーバ・コンピューテ
ィングおよびオブジェクト指向システムの分野に関す
る。具体的にいうと、本発明は分散コンピューティング
・システムにおける命名サービスおよびディレクトリ・
システムの分野に関する。

【０００２】

【従来の技術】クライアント・サーバ・コンピューティ
ングにおいては、一般に、コンピュータを接続している
ネットワークによって互いに通信できる一連のコンピュ
ータがある。これらのコンピュータの中には、他のコン
ピュータに対する機能のサービスのプロバイダとして働
くものがある。このようなサービスないし機能のプロバ
イダは、「サーバ」といわれており、このようなサービ
スないし機能の消費側は「クライアント」と呼ばれる。
クライアント・サーバ・モデルは、同一のコンピュータ
で動作している個別のプログラムが、何らかの保護機構
を介して互いに通信を行い、機能のプロバイダおよび消
費側として働いている、と一般化される。

【０００３】オブジェクト指向システムにおいて、オブ
ジェクトは、データと、このデータを操作するために呼
び出すことのできる操作とからなるコンポーネントであ
る。この操作はオブジェクトに呼出しを送ることによ
り、オブジェクト上に呼び出される。各オブジェクトは
オブジェクト・タイプを有している。オブジェクト・タ
イプはそのタイプのオブジェクトで行うことのできる操
作を定義する。オブジェクト操作はオブジェクト自体と
は無関係に実施される。さらに、あるオブジェクト・タ
イプは他のオブジェクト・タイプに対して定義され、実
施されたオブジェクト操作を継承することもできる。オ
ブジェクト指向設計とプログラミング技法の詳細につい
ては、Ｂｅｒｔｒａｎｄ Ｍｅｙｅｒの「Ｏｂｊｅｃｔ
−ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ Ｃｏｎｓｔｒ
ｕｃｔｉｏｎ」（Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ，１９８
８年）を参照されたい。

【０００４】クライアント・サーバ・モデルに基づくオ
ブジェクト指向分散システムには、オブジェクト指向イ
ンタフェースをクライアントに提供するサーバがある。
これらのサーバはデータと関連するプログラム命令から
なるオブジェクトをサポートしている。クライアントは
これらのオブジェクトにアクセスして、これらに呼出し
を実行することができる。これらの呼出しはクライアン
トからサーバに伝送される。サーバにおいて、これらの
呼出しはオブジェクトに関連したソフトウェアによって
実行される。これらの呼出しの結果はクライアントに戻
される。

【０００５】クライアント・アプリケーションないしプ
ログラムとは、オブジェクト・ハンドルないしオブジェ
クト名による特定のオブジェクトを指す。オブジェクト
名はオブジェクト（「ターゲット・オブジェクト」）を
探し出し、呼出しをこれに対して実行できるようにする
ために使用される。クライアント・プログラムは通常、
他のプログラムによってオブジェクト名が与えられた
り、あるいはプログラムの開始時にこれを継承する。所
与のクライアント・プログラムが特定のオブジェクトに
対するオブジェクト名を有している場合には、そのクラ
イアント・プログラムはそのオブジェクト名のコピーを
他のクライアント・プログラムに渡すことができる。第
２のクライアント・プログラムは次いで、そのオブジェ
クト名を使用して、そのオブジェクトにアクセスするこ
とができる。クライアントはオブジェクトの場所や、あ
るいは分散コンピュータ・システム内のどこかにあるコ
ンピュータにあるオブジェクトのインプリメンテーショ
ンについての情報を持っていない。オブジェクトの名前
によるオブジェクトに対するクライアントの呼出しは、
「命名ないしディレクトリ・サービス」によって可能と
される。

【０００６】命名ないしディレクトリ・サービスはあら
ゆるコンピュータ・システムにおいて基本的な機能であ
る。これは名前をオブジェクトに関連づけ、与えられた
名前によってオブジェクトを見つけだす手段である。命
名サービスは次のものに対する操作をもたらす。 ・名前をオブジェクトに関連づける（バインドする） ・名前をオブジェクトに分解する（ルックアップする） ・バインドの除去、名前のリスティング、名前変更など
これらの基本的な命名操作に加えて、サービスは属性を
取り扱う次の操作ももたらす。 ・命名されたオブジェクトに関連づけられた属性を検査
する ・命名されたオブジェクトに関連づけられた属性を修正
する ・属性を使用してオブジェクトを探す、など

【０００７】従来のシステムにおいて、命名サービスが
独立したサービスであることはあまりない。通常は、フ
ァイル・システム、データベース、デスクトップなどの
他のサービスに組み込まれている。たとえば、ファイル
・システムはファイルおよびディレクトリに対する命名
サービスを含んでおり、スプレッドシートはセルおよび
マクロに対する命名サービスを有している。

【０００８】大規模な分散コンピューティング環境に
は、個別にアクセスするか、協働してアクセスするかし
て、コンポジット名を分解することのできる多くの異な
る命名システムを有している。「コンポジット名」とは
複数の命名システムにまたがる名前である。これはゼロ
ないし複数のコンポーネントの番号付きリストからなっ
ている。各コンポーネントは単一の命名システムの名前
スペースからのストリング名である。さらに、異なる命
名システムからの名前を、「コンポジット名」の分解を
容易とするように実施できる「連合命名システム」に組
み合わせるプロトコルおよびプロセスのためのシステム
が開発されている。参照することによって、本明細書の
一部となる「Ａｐｐａｒａｔｕｓ ａｎｄ Ｍｅｔｈｏ
ｄ ｆｏｒａ Ｆｅｄｅｒａｔｅｄ Ｎａｍｉｎｇ Ｓ
ｙｓｔｅｍ ｗｈｉｃｈ ＣａｎＲｅｓｏｌｖｅ ａ
Ｃｏｍｐｏｓｉｔｅ Ｎａｍｅ Ｃｏｍｐｏｓｅｄ ｏ
ｆ Ｎａｍｅｓ ｆｒｏｍ Ａｎｙ Ｎｕｍｂｅｒ ｏ
ｆ ＤｉｓｐａｒａｔｅＮａｍｉｎｇ Ｓｙｓｔｅｍ
ｓ」という名称の、Ｒａｎｇａｓｗａｍｙ Ｖａｓｕｄ
ｅｖａｎに対して１９９４年１２月２７日付で発行され
た米国特許第５３７７３２３号を参照されたい。世界中
のもっとも大きな情報システム・サプライヤ、ユーザ組
織およびソフトフェア会社のほとんどによってサポート
されている独立した世界的な開放型システム組織である
Ｘ／Ｏｐｅｎは、クライアント（アプリケーション・プ
ログラム）が「連合命名システム」といわれるものにア
クセスする標準で画定された方法を採択している。参照
することによって、本明細書の一部となる「Ｆｅｄｅｒ
ａｔｅｄ Ｎａｍｉｎｇ：Ｔｈｅ ＸＦＮ Ｓｐｅｃｉ
ｆｉｃａｔｉｏｎ］、１９９４年７月、Ｘ／Ｏｐｅｎ
Ｃｏｍｐａｎｙ Ｌｉｍｉｔｅｄ，ＩＳＢＮ：１−８５
９１２−０４５−８という名称の暫定仕様書を参照され
たい。連合命名はコンポジット名をオブジェクト参照に
分解し、コンポジット名をオブジェクト参照にバインド
し、名前と参照のバインドを含んでいる命名コンテキス
トをリストする操作を含んでいる一連のアプリケーショ
ン・プログラム・インタフェースからなっている。さら
に、インタフェースはコンポジット名およびオブジェク
ト参照を取り扱う操作を含んでいる。

【０００９】

【発明が解決しようとする課題】命名およびディレクト
リ・サービス・プロバイダが個々の命名およびディレク
トリ操作を連合命名システム操作に組み込み、新しい任
意の命名およびディレクトリ・システムを実行時に、ア
プリケーションの再コンパイル、再リンキング、あるい
はアプリケーションを停止することなく、アプリケーシ
ョンにアクセス可能とする方法がなければならない。

【００１０】たとえば、Ｘ／Ｏｐｅｎ ＸＦＮ仕様書で
定義されたインタフェースは自律型の命名およびディレ
クトリ・システムへの複合アクセスおよび個別アクセス
を必要とするクライアント・プログラムを大幅に単純化
しているが、命名またはディレクトリ・サービス・プロ
バイダ・プログラムがそれぞれのサービスを命名フェデ
レーションに組み込むのは依然困難である。すなわち、
連合命名システムに対する操作はクライアント・プログ
ラムが「ｏｂｊｅｃｔＴ＝ｃｔｘ−＞ＯｐｅｎＬｏｏｋ
ｕｐ（ｎａｍｅ，＆ｓｔａｔｕｓ）」型のコマンドを使
用して、コンテキスト「ｃｔｘ」に関してコンポジット
名「ｎａｍｅ」によって命名されたオブジェクトに対す
る参照を得ることを比較的直接的なものとする。しかし
ながら、現時点では、新しい命名またはディレクトリ・
サービス・プロバイダ（以下で検討するところでは、命
名サービス・プロバイダという用語を、汎用性を損なう
ことなく、命名またはディレクトリ・サービス・プロバ
イダの代わりに使用する）を既存のシステムに統合する
ことがきわめて困難である。これが個々の既存の命名サ
ービス・プロバイダ・プログラムの変更／修正／増補を
含むことがしばしばある。すなわち、修正は、「ｎａｍ
ｅ」がアトム名である場合に、コンテキストｃｔｘでｈ
ｅａｄ（ｎａｍｅ）にバインドされたオブジェクト参照
を、命名サービス・プロバイダ・プログラムが返さなけ
ればならず、他の場合には、次のコンテキスト（たとえ
ば、コンテキストｃｔｙ）へのオブジェクト参照を、ｈ
ｅａｄ（ｃｔｙ）およびｔａｉｌ（ｎａｍｅ−ｃｔｙ）
を返すことによって返さなければならない「ｏｂｊｅｃ
ｔＴ＝ｃｔｘ−＞ＯｐｅｎＬｏｏｋｕｐ（ｎａｍｅ，＆
ｓｔａｔｕｓ）」型のコマンドへの応答に関連したタス
クを達成するのに直接的なものではなかった。そのクラ
イアント・アプリケーションの再コンパイルを必要とす
ることなく、あるいは「ｏｂｊｅｃｔＴ＝ｃｔｘ−＞Ｏ
ｐｅｎＬｏｏｋｕｐ（ｎａｍｅ，＆ｓｔａｔｕｓ）」型
のコマンドを処理するのに必要な操作の結果として、新
しい命名サービスに対する命名サービス・プロバイダ・
プログラムを呼び出す必要がある場合に、そのクライア
ント・アプリケーションを停止し、再起動する必要なし
に、命名サービス・プロバイダへのこれらの修正の組込
みを行わなければならない場合に、この問題はさらに困
難なものとなる。

【００１１】サービス・プロバイダ・プログラムを任意
の命名およびディレクトリ・システムに組み込み、クラ
イアントがこれらに個別に、あるいは複合して自動的に
アクセスできるようにする一様な方法を、従来技術は定
義していない。Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉ
ｎｃ．の子会社であるＳｕｎＳｏｆｔが作成した、１９
９４年４月付けの「Ｔｈｅ １９９４ Ｓｏｌａｒｉｓ
ＤｅｖｅｌｏｐｅｒＣｏｎｆｅｒｅｎｃｅ」という名
称のＣＤ−ＲＯＭが、１９９４年４月５日−７日にサン
フランシスコで開かれたＳｕｎ Ｄｅｖｅｌｏｐｅｒｓ
Ｃｏｎｆｅｒｅｎｃｅで配布された。このＣＤ−ＲＯ
Ｍは多数のデモンストレーション・バイナリ・プログラ
ムと、１９９４年４月付けのＳｕｎＳｏｆｔの「Ｆｅｄ
ｅｒａｔｅｄ Ｎａｍｉｎｇ Ｓｅｒｖｉｃｅ」という
名称のポストスクリプト形式の論文を含んでいた。この
「Ｆｅｄｅｒａｔｅｄ Ｎａｍｉｎｇ Ｓｅｒｖｉｃ
ｅ」は参照することによって、本明細書の一部となるも
のである。この論文は上記で概略を述べた連合命名シス
テムと関連する問題を説明しており、さらに、第５章
で、Ｓｏｌａｒｉｓでの連合命名システム準拠の命名サ
ービスのフェデレーションをサポートするサービス・プ
ロバイダ・フレームワークを記載している。Ｓｏｌａｒ
ｉｓはＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．が
作成し、販売しているオペレーティング・システム環境
プロダクトである。この第５章はフレームワーク、実施
者がフレームワークを使用して、既存の命名システムと
新しい命名システムを連合する方法、および実施者が記
載されているツールキットを使用して連合命名サービス
のタスクを楽なものとする方法を記載している。残念な
がら、この論文で定義されている機構は、フェデレーシ
ョン内の命名システムが命名システムの間の境界がある
場所を示すのに異なる方法を有していることを対象とし
ていない。フェデレーション内の異なる命名システムか
らの名前を命名システムの境界がある場所を効果的に識
別して、コンポジット名内で構文の上で区別する方法は
ない。本発明は強い分離と弱い分離とが定義されている
改善された連合命名フレームワーク機構と、これらの命
名システムの境界がどこにあるかを判定するために設け
られた機構とを提供する。

【００１２】したがって、本発明は開発者／メインテナ
ンス担当者が異なる命名サービス・プロバイダ・プログ
ラムを既存のシステムに統合し、クライアントが新たに
統合された命名またはディレクトリ・サービスに自動的
にアクセスでき、中断される必要のないようにするシス
テムおよび方法を規定する。

【００１３】本発明は命名システムの境界が定義されて
いない連合命名システム操作が必要とする場合に、命名
サービス・プロバイダを既存の分散コンピューティング
・システムに実施する問題を解決するものである。以下
のことを行うシステムおよび方法を開示する。 ・命名サービス・プロバイダがその個々の命名およびデ
ィレクトリ操作を連合命名システム操作に組み込む方法
を単純化する。 ・新しい任意の命名およびディレクトリ・サービスがア
プリケーションの再コンパイル、再リンキングを行わず
に、あるいはアプリケーションを停止させずに、換言す
れば、混乱を引き起こさずに、実行時にアプリケーショ
ンにアクセスできるようにする。 ・それぞれの命名システムにおける強いあるいは弱い分
離に対するサポートを示すように構成された命名システ
ム機構を提供する。

【００１４】

【課題を解決するための手段】本発明はサービス・プロ
バイダのニーズに合わせて、コンポジット命名またはア
トム命名のレベルで命名サービスの組込みを可能とす
る。この方法および装置は実行時に該当する命名または
ディレクトリ・サービス・プロバイダのインプリメンテ
ーションを識別し、呼び出す方法を含んでいる。これは
アプリケーションが複数の異なる命名システムの存在あ
るいはその場所に関する事前の知識なしに、これらの命
名システムを移動できることを意味する。装置の動的な
機能によって、任意の命名サービス・プロバイダを組み
込み、アプリケーションを中断させることなく、これら
のプロバイダにアクセスすることが可能となる。

【００１５】本発明の一態様において、分散コンピュー
ティング・システムで使用される連合命名フレームワー
ク・システムが開示される。連合命名フレームワーク・
システムはクライアント・アプリケーションと、連合さ
せる必要がある1つまたは複数の命名サービスの間の中
間層として働き、それぞれの命名システムにおいて強い
または弱い分離のサポートを示すように構成された1つ
または複数の命名サービス機構を含んでいる連合命名フ
レームワーク機構を含んでいる。

【００１６】本発明の他の態様において、連合命名フレ
ームワーク・システムは1つまたは複数の命名サービス
・プロバイダと通信するように構成された命名サービス
・プロバイダ・インタフェースを含んでいる。

【００１７】本発明のさらに他の態様において、命名サ
ービス・プロバイダを既存のクライアントを中断するこ
となく、既存のシステムに追加することを可能とする機
構をもたらす方法が開示される。

【００１８】本発明のさらにまた他の態様において、埋
め込まれたコンピュータ読取り可能コード機構を含んで
いるコンピュータで使用可能な媒体を有するコンピュー
タ・プログラム・プロダクトであって、コンピュータ読
取り可能コード機構が、クライアント・アプリケーショ
ンと、連合させる必要がある1つまたは複数の命名サー
ビスの間の中間層として働き、それぞれの命名システム
において強いまたは弱い分離のサポートを示すように構
成された1つまたは複数の命名サービス機構を含んでい
る連合命名フレームワーク機構を含んでいるコンピュー
タ・プログラム・プロダクトが開示される。

【００１９】本発明のシステムの目的、特徴および利点
は以下の説明から明らかとなろう。

【００２０】

【発明の実施の形態】表記および用語以下の詳細な説明
は大部分が、コンピュータ・メモリ内のデータ・ビット
に対する操作についてのアルゴリズムおよび記号の表記
によって示されている。これらのアルゴリズムの説明お
よび表記はデータ処理分野の技術者が、自分たちの作業
の主旨を他の技術者に最も効果的に伝えるために使用し
ている手段である。

【００２１】アルゴリズムは、希望する結果につながる
一貫したステップのシーケンスである。これらのステッ
プは物理量の物理的な操作を必要とするものである。通
常、必ずしも必要ではないが、これらの量は記憶、転
送、組合せ、比較、あるいは取扱いを行える電気または
磁気信号の形式を取る。これらの信号をビット、値、要
素、記号、文字、項、数値などと呼ぶのが、主に共通の
用途の点から、多くの場合に便利なことが判明してい
る。しかしながら、これらおよび類似の用語が該当する
物理量と関連づけられるものであり、これらの量に適用
された便宜上のラベルにすぎないことに留意すべきであ
る。

【００２２】さらに、行われる操作は人間の操作員が行
う知的な操作と共通して関連づけられる加算、比較など
の用語で呼ばれることがしばしばある。人間の操作員の
このような能力は、本発明の一部を形成する、本明細書
で記載する操作のいずれにも必要ではないし、多くの場
合は望ましくないものである。操作は機械の操作であ
る。本発明の操作を行うのに有用な機械は、汎用ディジ
タル・コンピュータまたは類似の装置を含んでいる。す
べての場合に、コンピュータを操作する際の方法の動作
と、コンピュテーション自体の方法との区別に留意すべ
きである。本発明は電気その他（たとえば、機械的、化
学的な）の物理信号を処理して、他の希望する物理信号
を発生する際にコンピュータを操作する方法のステップ
に関する。

【００２３】本発明はこれらの操作を行う装置にも関す
る。この装置は必要な目的に合わせて特に構成されたも
のであっても、コンピュータに記憶されたコンピュータ
・プログラムによって選択的に活動化、あるいは再構成
される汎用コンピュータからなるものであってもよい。
本明細書に示すアルゴリズムは本来、特定のコンピュー
タまたは装置に関するものではない。詳細にいえば、各
種の汎用の機構を本発明の教示にしたがって書かれたプ
ログラムとともに使用することもできるし、あるいは必
要な方法ステップを行うための専用の装置を構築するの
が便利なこともある。各種のこれらの機構に必要な構造
は、以下の説明から明らかとなろう。

【００２４】任意の命名サービスを分散コンピューティ
ング・システムの命名フェデレーションに組み込むシス
テムおよび方法を開示する。以下の説明において、説明
のため、特定のデータおよび構成を記載して本発明を完
全に理解できるようにする。本明細書に記載する好まし
い実施の形態は、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ
^(R) ，Ｉｎｃ．が作成したＳｏｌａｒｉｓ^(TM)オペレー
ティング・システムで使用されるように実施される。Ｓ
ｏｌａｒｉｓはＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉ
ｎｃ．の商標であり、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍ
ｓは同社の登録商標である。しかしながら、当分野の技
術者には、本発明を特定の細部なしに実施でき、かつ各
種のコンピュータ・システムおよび各種の構成、あるい
は緊密結合プロセスの製品またはモデル、あるいは疎結
合マイクロプロセッサ・システムの各種の構成で実施す
ることができることが理解できよう。

【００２５】本発明は一連の標準化された連合命名サー
ビス・プロバイダ・インタフェース（「ＦＮ ＳＰ
Ｉ」）を含んでいる連合命名フレームワーク（「ＦＮフ
レームワーク」）用のシステムおよび方法である。本発
明によって、サービス・プロバイダのニーズに合わせ
て、コンポジット命名からアトム命名までの範囲のさま
ざまなレベルでの命名サービスの組込みが可能となる。
この方法および装置は実行時に該当する命名サービス・
プロバイダのインプリメンテーションを識別し、呼び出
す方法も含んでいる。このことはアプリケーションが複
数の異なる命名システムの存在あるいはその場所に関す
る事前の知識なしに、これらの命名システムを移動でき
ることを意味する。装置および方法の動的な性質によっ
て、任意の命名サービス・プロバイダを組み込み、アプ
リケーションを中断させることなく、これらのプロバイ
ダにアクセスすることが可能となる。

【００２６】作動環境 本発明が使用される環境は汎用コンピュータ、ワークス
テーション、またはパーソナル・コンピュータが各種の
タイプの通信リンクによって接続されており、多くがオ
ブジェクトの形のプログラムおよびデータをシステムの
各種のメンバが利用して、システムの他のメンバによる
実行およびアクセスを可能とする一般的な分散コンピュ
ーティング・システムを包含している。汎用ワークステ
ーション・コンピュータの要素のいくつかを、図１に示
す。図には、入出力（「Ｉ／Ｏ」）部２、中央演算処理
装置（「ＣＰＵ」）３およびメモリ部４を有するプロセ
ッサ１が示されている。Ｉ／Ｏ部２はキーボード５、表
示装置６、ディスク記憶装置９およびＣＤ−ＲＯＭ駆動
装置７に接続されている。ＣＤ−ＲＯＭ駆動装置７はプ
ログラム１０とデータを通常収めているＣＤ−ＲＯＭ媒
体８を読み取ることができる。本発明の装置および方法
を実現する機構を収めているコンピュータ・プログラム
・プロダクトは、メモリ部４に置かれていても、ディス
ク記憶装置９に置かれていても、あるいはこのようなシ
ステムのＣＤ−ＲＯＭ８に置かれていてもよい。図２は
個々のコンピュータ２０、２２および２４が互いに接続
されており、おそらくは、通信リンク２６を介して共用
メモリ装置２８に接続されている典型的なマルチプロセ
ッサ分散コンピュータ・システムを示している。図３は
ユーザ３０が第１のコンピュータ３２でクライアント・
アプリケーション３４を起動できる典型的なオブジェク
ト指向クライアント・サーバ構成を示している。クライ
アント・アプリケーション３４はオブジェクト参照３６
に対して呼出し４０を行い、この参照は第２のコンピュ
ータ（サーバ）５０にあるオブジェクト（「ターゲット
・オブジェクト」ともいう）のインプリメンテーション
４６をポイントする。呼出し４０は通信制御機構３８に
渡され、この機構は呼出しをオブジェクト・インプリメ
ンテーション４６が置かれているサーバ５０に送る。こ
のオブジェクト・インプリメンテーション機構４６は、
本来オブジェクト参照３６を作成し、通常、オブジェク
ト・インプリメンテーションが最初に作成されたとき
に、ユーザが利用できるようにする。このオブジェクト
・インプリメンテーション機構４６は呼出し処理を完了
すると、メッセージまたは希望する操作の結果を、通信
リンク４２を介して、送信元のクライアント・アプリケ
ーション３４に返す。このクライアント・サーバ・モデ
ルは通信機構の機能がオペレーティング・システム（図
４の６２）によって行われるシングル・プロセッサ・ユ
ニットでも動作できる。

【００２７】連合命名および定義の背景 本発明に密接な関係がある顕著な連合命名システムの概
念は、次のとおりである。

【００２８】すべての名前は命名規則と呼ばれる一連の
構文規則によって生成される。アトム名とは命名規則に
よって定義された1つまたは複数の文字の分割不能なコ
ンポーネント・シーケンスである。命名規則は考えられ
るすべてのアトム名を定義する。複合名は1つまたは複
数のアトム名のシーケンスである。コンポジット名は1
つまたは複数の複合名のシーケンスである。各複合名は
異なる命名システムに属している。

【００２９】コンテキストとは個別のアトム名との一連
のバインディングを含んでいるオブジェクトである。あ
らゆるコンテキストは関連する命名規則を有している。
コンテキストは参照をオブジェクトに返すルックアップ
（分解）操作をもたらす。また、名前のバインド、名前
のバインド解除、名前の変更、バインドされた名前のリ
スト、命名されたオブジェクトに関連した属性の検査お
よび取扱いなどを行う操作ももたらす。

【００３０】命名システムは同じタイプ（同じ命名規則
を有している）であり、同一の構文の同じセットの操作
をもたらすコンテキストの接続されたセットである。

【００３１】連合命名システムは標準インタフェースと
協働して、コンポジット名の名前分解を実現する自律型
の命名システムのセットである。それ故、連合命名シス
テムは２つ以上の命名システムにわたるコンテキストの
接続されたセットである。フェデレーションの２つの命
名システムの間の接続は、次命名システム・ポインタと
いう概念を使用して表され、実施することができる。次
命名システム・ポインタはフェデレーションの次の命名
システムにどのようにして到達するかに関する参照情報
を含んでいる。

【００３２】フェデレーション内の命名システムは命名
システム境界によって分離されている。コンポジット名
を使用して、連合命令システムのオブジェクトを命名す
る。強い分離および弱い分離という用語はフェデレーシ
ョン内の異なる命名システムがコンポジット名内で構文
上どのように分離されているかを記述し、命名システム
の境界がどこにあるかを効果的に識別するために使用さ
れる。強い分離において、コンポジット・コンポーネン
ト名セパレータが命名システム境界を示すために使用さ
れる。弱い分離において、コンポジット・コンポーネン
ト名セパレータは必ずしも命名システムの境界を示すも
のではない。命名システムの境界は分解プロセスが進ん
だ場合に動的に決定されるか（動的な弱い分離とい
う）、命名システム固有の構文規則を使用して静的に決
定されるかする（静的な弱い分離という）。強い分離と
弱い分離は特定の命名システムの特性である。強く分離
された命名システムと弱く分離された命名システムは、
単一のフェデレーションで共存できる。

【００３３】命名コンテキスト 命名コンテキストというこの概念が命名システムという
一般的な考え方の基本となるものであるから、コンテキ
ストの概念についてのいくつかの見方をここで説明す
る。図５を参照すると、コンテキスト・オブジェクトが
示されている。各種のメソッド３８６と、オブジェクト
参照にバインドされた名前のリストからなる状態３８４
を含んでいるコンテキスト・オブジェクト３８２が示さ
れている。オブジェクト参照はオブジェクト３９４など
のオブジェクトをポイントしていても、それ自体が同様
な操作（メソッド）と、他の参照、たとえば、オブジェ
クト３９２をポイントしているコンテキスト・オブジェ
クト３９６のものや、オブジェクト３９０をポイントし
ているコンテキスト・オブジェクト３８８のものにバイ
ンドされている名前を含んでいる状態を有している他の
コンテキスト・オブジェクト３８８、３９６をポイント
していてもかまわない。これらのオブジェクト３９４、
３９２および３９０は、その場所がオブジェクト名にバ
インドされた参照によって示されるオブジェクトのイン
プリメンテーションであることが理解されよう。

【００３４】図６を参照すると、コンテキスト・オブジ
ェクトの他のビューが示されている４００。コンテキス
ト・オブジェクト４００は一連の名前−オブジェクト参
照アソシエーション（名前のバインディングとも呼ばれ
る）を保持しているテーブル４０１を含んでいる。好ま
しい実施の形態において、名前はこれらが使用されるコ
ンテキスト内でだけ意味を持っている。したがって、オ
ブジェクト参照をいくつかの異なるコンテキスト・オブ
ジェクトのいくつかの異なる名前に同時にバインドして
もかまわない。典型的な命名サービスのクライアント
は、コンテキスト・オブジェクト４００のメソッド・テ
ーブル４０３で特定されたメソッドによって命名操作を
行う。好ましい実施の形態においては、たとえば、コン
テキスト・オブジェクトはオブジェクトの名前をルック
アップするメソッド４０８を有しているが、これはコン
テキスト内の所与の名前にバインドされたオブジェクト
参照をルックアップし、名前をオブジェクトにバインド
４０６し、これによって名前をオブジェクトの参照と関
連づけ、名前と関連づけられた参照とをリスト４０５す
るなどのことを意味する。

【００３５】図５に示すように、コンテキスト・オブジ
ェクトは他のオブジェクトをポイントしてもかまわな
い。すなわち、あるコンテキスト・オブジェクトの名前
を第２のコンテキスト・オブジェクトの参照にバインド
することができる。他のコンテキスト・オブジェクト内
のあるコンテキスト・オブジェクトをバインドすると、
命名グラフが作成されるが、これはノードとラベル付き
のエッジを備えた有向グラフであって、ノードと外向き
のエッジがコンテキストである。エッジが他の命名シス
テムのコンテキストにつながっている場合、これは複数
の命名システムにわたる命名グラフを作成する。言い換
えると、名前スペースの構成、すなわち、ある名前スペ
ースが他の名前スペースに接続されている連合名前スペ
ースの作成が行われる。

【００３６】命名サービス・プロバイダ 異なる命名システムは異なる機構を使用して、コンテキ
スト・オブジェクト同士をバインドし、オブジェクト名
を該当するオブジェクト・インプリメンテーションにマ
ップする。クライアントとこの命名構造の間のインタフ
ェースをもたらすために使用される機構が、命名サービ
ス・プロバイダである。図７には、これらの要素の間の
機能的な関係８００が示されている。アプリケーション
（クライアント）８０２は、通常、コンテキスト・オブ
ジェクトに対して呼出しを実行する。この呼出し８０４
は名前、実行する操作、その操作に必要な1つまたは複
数の付加的なパラメータ、たとえば、「名前ｆｏｏ、操
作Ａ」を含んでいる。この例について、ｆｏｏがアトム
名であり、操作がｆｏｏによって指定されたコンテキス
ト・オブジェクトに対して行われるものと想定する。操
作がｆｏｏによって指定されたコンテキストではなく、
終わりから２番目のコンテキスト（ｂｉｎｄなどの操作
の場合）に対して行われる場合には、以下の説明が若干
異なることとなる。すなわち、操作Ａがコンテキスト・
オブジェクト８２０ではなく、コンテキスト・オブジェ
クト８１０によって行われることとなる。呼出し８０４
は通常、命名サービス・プロバイダ８０６に送られ、供
給されたコンテキスト・オブジェクトをまず探し出す。
次いで、「名前ｆｏｏ、操作Ａ」８０８をそのコンテキ
スト・オブジェクト８１０に渡す。コンテキスト・オブ
ジェクト８１０はオブジェクト名ｆｏｏをオブジェクト
のインプリメンテーションの場所にマップしようと試み
る。コンテキスト・オブジェクト８１０は参照ｌｏｃｎ
８１４にバインドされたその名前テーブル８１２で名前
ｆｏｏを見つけだし、これを命名サービス・プロバイダ
８０６に返す８１６。命名サービス・プロバイダ８０６
は次いで、参照ｌｏｃｎ８１６を使用して、オブジェク
トｆｏｏのインプリメンテーション８２０のアドレスに
対するポインタを生成し、これを操作Ａに与える８１
８。コンテキスト・インプリメンテーション８２０は操
作Ａに対応したメソッド８２４を行い８２２、結果８２
６を命名サービス・プロバイダ８０６に返し、プロバイ
ダは呼出し側クライアント８０２に結果８２８を渡し、
これによって元の操作呼出し要求を完了する。他の実施
の形態は呼び出された操作の任意の結果を呼出し側クラ
イアント・アプリケーション８０２に直接返すコンテキ
スト・インプリメンテーション８２０をもたらす。当分
野の技術者には、元の名前をインプリメンテーションの
場所にマップするのに、複数のコンテキスト・オブジェ
クトが関与している場合に、命名サービス・プロバイダ
８０６が大幅に多くの活動を管理できることが認識され
よう。

【００３７】複数の命名サービス・プロバイダが関与し
ている場合には、より複雑な状況が生じる。これは、コ
ンポジット名が複数の命名システムにわたっている場合
である。図８に示した例を考える。図８に示されている
システム９００は、クライアント・アプリケーション９
０２がコンポジット名ｙ．ｘ／ｉ：ｊ９０４を有してい
るオブジェクトに対する呼出しを、命名サービス・プロ
バイダＭ９０６に発行するシステムを示している。コン
ポジット名ｙ．ｘ／ｉ：ｊは２つのコンポーネントｙ．
ｘとｉ：ｊからなっており、第１のコンポーネントｙ．
ｘは右から左へのドットで区切られた名前構文を持って
いる名前スペースからの複合名であり、一方、第２のコ
ンポーネントｉ：ｊは左から右へのコロンで区切られた
名前構文を持っている名前スペースからの複合名であ
る。

【００３８】この命名サービス・プロバイダＭ９０６
は、コンテキスト・オブジェクトＢ９１４をポイントす
る参照９１２に名前部分ｘ９１０を分解するコンテキス
ト・オブジェクトＡ９０８によって名前ｙ．ｘ／ｉ：ｊ
を分解しようと試みる。コンテキスト・オブジェクトＢ
９１４において、名前部分ｙ９１６はエントリ９１８に
分解され、これは他の命名システムにおけるコンテキス
トに対する参照である。命名サービス・プロバイダに扱
えるものが同じ命名システムのコンテキストだけである
から、コンテキスト・オブジェクトＢ９１４は応答９２
０をコンテキスト・オブジェクトＡ９０８へ送り、それ
故、９２２を命名サービス・プロバイダＭ９０６に送
り、これは９２４「名前（ｉ：ｊ）の残りを分解できま
せん」と通知する。この場合、命名サービス・プロバイ
ダＭ９０６は命名サービス・プロバイダＮ９３０を知っ
ておらず、したがって、クライアント・アプリケーショ
ン９０２に「要求されたオブジェクトの名前を分解でき
ません」というメッセージ９２６を送らなければならな
い。クライアント９０２が第２の命名サービス・プロバ
イダＮ９３０を呼び出すことを知っている場合には、呼
出しを行って、コンポジット名ｉ：ｊの残り９２８を分
解することができる。この例において、第２の命名サー
ビス・プロバイダＮ９３０は名前の残りの部分を分解す
る方法を知っており、呼び出されたオブジェクト・イン
プリメンテーション９５８が最終的に呼び出され、呼出
しは正常に終了する。

【００３９】図８について上述した例において、他の命
名サービス・プロバイダをシステムに追加する必要があ
る場合、クライアント９０２を修正しなければならな
い。名前ｉ：ｊの残りを分解するためには、命名サービ
ス・プロバイダＮ９３０を呼び出すことを知っていなけ
ればならない。他の命名サービス・プロバイダを追加し
た場合、クライアントを修正し、これらのプロバイダを
知っているようにする必要がある。さらに、クライアン
ト９０２は異なる命名サービス・プロバイダへの呼出し
も管理している。クライアント・アプリケーションとそ
のプログラマがこれらの異なる命名サービス・プロバイ
ダを取り扱ったり、管理したりする必要がない方が望ま
しい。本発明が取り上げるのは、この問題である。

【００４０】本発明の概要 「背景」の項で説明したさまざまな形式の名前−−アト
ム名、複合名およびコンポジット名−−について与えた
定義にしたがい、本発明は４つのタイプ（アトム名、複
合名、部分コンポジット名、およびコンポジット名）に
関する連合命名サービス・プロバイダ・インタフェース
（ＦＮ ＳＰＩ）、ならびにこれらのインタフェースと
クライアントとの間に存在し、コンポジット名の分解の
ための呼出しの変換およびアドミニストレーションをサ
ポートする連合命名フレームワーク（ＦＮフレームワー
ク）という機構を提供する。これによって、連合命名Ａ
ＰＩを使用するクライアント・アプリケーションが利用
可能なＦＮ ＳＰＩ（２つ以上のＦＮ ＳＰＩがシステ
ムに存在することもある）を適切に使用することが可能
となる。本発明はシステムの実装者がクライアント・ア
プリケーションを中断することなく、新しい命名サービ
スを動的にインストールすることを可能とする。

【００４１】本発明のビューの１つを図９に示す。図９
はＦＮフレームワーク１００４によって取り扱われるも
のとして、図８のシステムを示しているシステム１００
０を示している。システム１０００において、ＦＮフレ
ームワーク１００４はクライアント・アプリケーション
１００２と命名サービス・プロバイダ１０１２、１０３
０との間に配置されており、両方の命名サービス・プロ
バイダ１０１２、１０３０による部分的な分解を必要と
するコンポジット名の分解に必要なすべての機能を実行
する。当分野の技術者には、ＦＮ ＳＰＩによって複数
の命名サービス・プロバイダとインタフェースできるＦ
Ｎフレームワーク１００４が、複数の異なる命名サービ
スからなる連合命名システムを実施するシステムにとっ
てきわめて有用なことが明らかであろう。

【００４２】本発明の詳細 Ａ．アーキテクチャ 本発明は命名コンテキストが基本的な命名の概念である
ということを利用している。各命名コンテキスト・オブ
ジェクトには、これに対するインプリメンテーション−
−コンテキスト・インプリメンテーションと呼ぶ−−が
関連づけられている。各コンテキスト・インプリメンテ
ーションはコンテキスト・インタフェースのものと機能
的に同等な操作（ルックアップ、バインド、属性の関連
づけ、これらの検査など）を備えている（上述の米国特
許第５３７７３２３号参照）。コンテキスト・インプリ
メンテーションはＦＮフレームワークとコンテキスト・
インプリメンテーションの間のコントラクトである連合
命名サービス・プロバイダ・インタフェース（ＦＮ Ｓ
ＰＩ）によって、これらの操作を利用する。コンテキス
ト・インプリメンテーションの機能に応じて、４種類の
ＦＮ ＳＰＩがあるので、異なる命名サービスの要件を
適切に満たすことができる。４種類のＦＮＳＰＩとは次
のとおりである。 コンポジット名ＳＰＩ 部分コンポジット名ＳＰＩ 複合名ＳＰＩ アトム名ＳＰＩ

【００４３】コンポジット名に関与する操作はコンポジ
ット名の分解を必要とする。ＦＮフレームワークは、関
連する各コンテキストに関連づけられたコンテキスト・
インプリメンテーションを使用して異なるコンテキス
ト、おそらくは異なる命名システムによってコンポジッ
ト名の分解を可能とする。名前とそのコンテキスト・ハ
ンドルの間のアソシエーションは次のようにして行われ
る。ＦＮ ＡＰＩが名前にバインドされた参照を返す操
作（ＯｐｅｎＬｏｏｋｕｐ）を供給する。各ＦＮＳＰＩ
はｃｏｎｓｔｒｕｃｔｏｒ（）操作を含んでおり、これ
はコンテキストに対するコンテキスト・ハンドルを取得
するためにＦＮフレームワークが（各コンテキスト・イ
ンプリメンテーションに対して）呼び出したものである
（オブジェクト・ハンドルおよびコンストラクタは、Ｂ
ｅｔｒａｎｄ Ｍｅｙｅｒの上述の文献「Ｏｂｊｅｃｔ
−Ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ Ｃｏｎｓｔｒ
ｕｃｔｉｏｎ」、Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、１９８
８年に記載されている）。この参照を使用して、ＦＮフ
レームワークは、その参照に関連づけられたコンテキス
ト・インプリメンテーションにロードし、これからｃｏ
ｎｓｔｒｕｃｔｏｒ（）操作を呼び出す。この時点で、
ＦＮフレームワークはコンテキスト・オブジェクトに対
するコンテキスト・ハンドルを有している。ＦＮフレー
ムワークはコンポジット名からのコンポーネントを二者
択一的に分解し、コンポーネントによって指定されたコ
ンテキスト・オブジェクトに対するコンテキスト・ハン
ドルを取得することによって、コンポジット名の分解を
管理する。結果として、コンポジット名のすべてのコン
ポーネントが消費され、ターゲット操作が行われるター
ゲット・コンテキストに到達する。ＦＮフレームワーク
は次いで、ターゲット・コンテキストに対してターゲッ
ト操作を呼び出し（その操作に該当する引数を使っ
て）、呼出しの結果をクライアント・アプリケーション
に返す。好ましい実施の形態において、以下はコンスト
ラクタを呼び出す方法についてのコード・フラグメント
を説明するものである。 ｃｔｘ＝ｃｏｎｓｔｒｕｃｔｏｒ（ｒｅｆｅｒｅｎｃ
ｅ） ただし、ｃｔｘはコンテキスト・オブジェクトに対する
ハンドルであり、ｒｅｆｅｒｅｎｃｅは名前をルックア
ップすることによって得られる参照である。（これにつ
いては、以下のコンテキスト・インプリメンテーション
・リンケージの項で詳細に検討する。）

【００４４】本発明の次の３つの主要なコンポーネント
について、以下で詳細に検討する。 ・ＦＮ ＳＰＩ ・ＦＮフレームワーク ・コンテキスト・インプリメンテーション・リンケージ

【００４５】Ｂ．連合命名サービス・プロバイダ・イン
タフェース 連合命名サービス・プロバイダ・インタフェース（ＦＮ
ＳＰＩ）は、命名およびディレクトリ・サービス・プ
ロバイダがその命名およびディレクトリ操作を連合命名
システム操作に組み込むための簡単な方法を提供する。
命名サービス・プロバイダは同じシステムにある他の命
名サービス・プロバイダに関する知識から分離されてお
り、これらが使用するＳＰＩで定義された操作を供給す
ることだけが必要とされている。

【００４６】上述したように、各ＦＮ ＳＰＩは各コン
テキスト・インプリメンテーションが供給しなければな
らないｃｏｎｓｔｒｕｃｔｏｒ（）操作を含んでいる。

【００４７】ＦＮ ＳＰＩの各操作は状況引数を持って
おり、これはコンテキスト・インプリメンテーションに
よってセットされる。すべてのコンテキスト・インプリ
メンテーションは次のようにして状況引数をセットす
る。操作をＦＮフレームワークが継続しなければならな
い場合、コンテキスト・インプリメンテーションは状況
（あるいは、状況コード）をＣＯＮＴＩＮＵＥにセット
し、状況オブジェクトの次の２つのフィールドを以下の
ようにセットしなければならない。ｒｒｅｆ（分解され
た参照フィールド）は操作を継続するコンテキストに対
する参照である。ｒｎａｍｅ（残っている名前フィール
ド）はｒｒｅｆによってポイントされたコンテキストで
処理される名前にセットされる。この情報によって、Ｆ
Ｎフレームワークがコンポジット名の処理を最後まで継
続できるようになる。

【００４８】４種類のＦＮ ＳＰＩの各々を以下で説明
する。

【００４９】コンポジット名ＳＰＩ 完全なコンポジット名の分解を取り扱おうとする命名サ
ービス・プロバイダはコンポジット名ＳＰＩを与えなけ
ればならない。コンテキスト・インプリメンテーション
はコンテキスト・インタフェース（ｃｔｘ＿ｌｏｏｋｕ
ｐ（）、ｃｔｘ＿ｂｉｎｄ（）、ｃｔｘ＿ｕｎｂｉｎｄ
（）など）を直接提供するものであり、あらゆる命名シ
ステム境界を横切って完全なコンポジット名の分解を取
り扱い、答えをクライアントに返すことができなければ
ならない。

【００５０】部分コンポジット名ＳＰＩ コンポジット名ＳＰＩは基礎となるコンテキスト・イン
プリメンテーション・プロバイダが操作を結論が再帰的
な評価を含むものであっても、結論に達するまで行うこ
とを必要としている。再帰モデルはクライアントに対し
て便利なものであるが、再帰的評価は必ずしも望ましい
ものではなく、可能なものでないことさえある。コンポ
ジット名を部分的に分解することだけを行おうとしてい
る命名サービス・プロバイダは部分コンポジット名ＳＰ
Ｉを備えているべきである。

【００５１】部分コンポジット名ＳＰＩをもたらすコン
テキスト・インプリメンテーションは部分コンポジット
名に対する操作のインプリメンテーションを備えてい
る。このようなコンテキスト・インプリメンテーション
は、コンポジット名を全体的に取り扱うのには必要な
い。コンポジット名の残っている未使用のコンポーネン
トは、操作をＦＮフレームワークに対してどのように継
続すべきかを示す状況情報とともに、コンテキスト・イ
ンプリメンテーションによって返される。ＦＮフレーム
ワーク（以下で、詳述する）はこの状況情報を解釈し
て、次の命名サービス・プロバイダを呼び出して、操作
を継続する。

【００５２】部分コンポジット名ＳＰＩはＦＮフレーム
ワークが使用するコンテキスト・インタフェースの操作
をミラーする一連の操作（ｐ＿ｌｏｏｋｕｐ（）、ｐ＿
ｌｉｓｔ＿ｎａｍｅ（）など）を定義している。図１１
は例示的な部分コンポジット名分解を示す。「ｐ＿」と
いう接頭辞の付いた操作（たとえば、ｐ＿ｌｏｏｋｕｐ
（））がコンテキストｃｔｘに対して呼び出され、コン
ポジット名ｎａｍｅを入力として取り、＜ｏｐｅｒａｔ
ｉｏｎ ｒｅｓｕｌｔｓ＞と状況を返す。ｐ＿操作が操
作を完了せず、その操作を他のコンテキストで継続する
ことを必要としている場合には、下記の情報を使って状
況オブジェクトをセットする。 −状況コードをＣＯＮＴＩＮＵＥにセットして、操作を
継続すべきことを示す −状況の残っている名前部分（ｒｎａｍｅ）を、さらに
処理を必要とするｎａｍｅの一部になるようにセットす
る −状況の分解された参照部分（ｒｒｅｆ）がこれまでに
分解された名前の参照になるようにセットする この状況情報はコンテキスト・インプリメンテーション
によって、ＦＮフレームワークに返され、これはｎａｍ
ｅ引数をｒｎａｍｅに更新し、ｃｔｘをｒｒｅｆによっ
て特定されたコンテキストのコンテキスト・ハンドルに
なるように更新する。更新されたｎａｍｅおよびｃｔｘ
引数は、ｐ＿操作を継続するために使用される。これに
ついては以下のＦＮフレームワークの検討の際に詳細に
説明する。ｐ＿操作を継続する必要がない場合（正常に
終了したか、失敗したかの場合）、結果はクライアント
・アプリケーションに返される。

【００５３】複合名ＳＰＩ 部分コンポジット名ＳＰＩは基礎となるコンテキスト・
インプリメンテーションが、２つ以上の命名システムか
らの名前を含んでいるコンポジット名を取り扱うことを
必要としている。単一の命名システムからの名前を取り
扱えるだけでよい命名サービス・プロバイダは複合名Ｓ
ＰＩを備えていなければならない。

【００５４】複合名ＳＰＩは単一の命名システムからの
名前を取り扱おうとだけしている命名サービス・プロバ
イダに合わせて設計されている。部分コンポジット名Ｓ
ＰＩと同様に、複合名ＳＰＩは複合名ＳＰＩが複合名に
対して操作する操作をのぞき、コンテキスト操作をミラ
ーする一連の操作（ｃ＿ｌｏｏｋｕｐ（）、ｃ＿ｌｉｓ
ｔｎａｍｅ（）など）を定義する。

【００５５】静的な弱い分離をサポートしているコンテ
キスト・インプリメンテーションの場合、インプリメン
テーションは入力名のどの最初のコンポーネントが命名
システムに属しているかを決定する付加的な操作を供給
しなければならない。命名システムが使用しないコンポ
ーネントの残りは他のパラメータで操作に返される。好
ましい実施の形態において、この操作はｐ＿ｃｏｍｐｏ
ｎｅｎｔ＿ｐａｒｓｅｒ（）と呼ばれる。以下のコード
・フラグメントはこれをどのようにして呼び出すかを説
明するものである。 ｃｏｍｐｏｕｎｄ＿ｎａｍｅ＝ｃｔｘ−＞ｐ＿ｃｏｍｐ
ｏｎｅｎｔ＿ｐａｒｓｅｒ（ｎａｍｅ，＆ｒｅｓｔ，＆
ｐｓｔａｔｕｓ）；ただし、 −ｎａｍｅは分解対象のコンポジット名である −ｃｏｍｐｏｕｎｄ＿ｎａｍｅはこの命名システムのコ
ンテキストによって処理されるコンポジット名ｎａｍｅ
の最初のコンポーネントである −ｒｅｓｔは次の命名システム（もしあれば）に対して
残されるｎａｍｅのコンポーネントである −ｐｓｔａｔｕｓはｐ＿ｃｏｍｐｏｎｅｎｔ＿ｐａｒｓ
ｅｒ（）インプリメンテーションの実行状況を示す状況
パラメータである

【００５６】たとえば、コンテキストが名前スペースに
属している各コンポーネントがその中に等号文字（’
＝’）を持っていなければならないという構文方針を使
用して静的な弱い分離をサポートしているものとする。
このコンテキスト・インプリメンテーションは、ｐ＿ｃ
ｏｍｐｏｎｅｎｔ＿ｐａｒｓｅｒ（）に対してインプリ
メンテーションを供給し、このインプリメンテーション
はａ＝ｂ／ｃ＝ｄ／ｅ／ｆ／ｇなどのコンポジット名と
ともに供給された場合に、ｃｏｍｐｏｕｎｄ＿ｎａｍｅ
＝ｃｔｘ−＞ｐ＿ｃｏｍｐｏｎｅｎｔ＿ｐａｒｓｅｒ
（“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ／ｇ”，＆ｒｅｓｔ，＆ｐ
ｓｔａｔｕｓ）であり、ｃｏｍｐｏｕｎｄ＿ｎａｍｅに
“ａ＝ｂ／ｃ＝ｄ”を返し、ｒｅｓｔに“ｅ／ｆ／ｇ”
を返す。

【００５７】ターミナル命名システムはその後に次の命
名システムを持つことができない。操作がこの命名シス
テムに到達すると、フェデレーション内の他の命名シス
テムに入ることができなくなる。命名システムが命名シ
ステムのフェデレーションの一部になった場合、それが
ターミナル命名システムでない限り、コンポジット名の
分解のための中間命名システムとして使用されるという
概念をサポートしなければならない。これは他の名前ス
ペースのルートがバインドされ、ルックアップされるよ
うにする機構を備えていなければならないということを
意味する。本発明の好ましい実施の形態において、この
機構は次命名システム・ポインタと呼ばれる。異なる命
名サービスは次命名システム・ポインタをサポートする
のに異なる方法を持っている。たとえば、ある命名シス
テムは次命名システム・ポインタを、これらのポインタ
に特別な名前を与え、同じ命名システムに記憶すること
によってサポートしているのに対し、他のコンポーネン
ト命名システムは次命名システム・ポインタを特に取り
扱う別個のサービスを有していることもある。

【００５８】ｃ＿インタフェースに加えて、複合名ＳＰ
Ｉは次命名システム・ポインタを取り扱うための、コン
テキスト操作をミラーする付加的な一連の操作（ｃ＿ｌ
ｏｏｋｕｐ＿ｎｎｓ（）、ｃ＿ｌｉｓｔｎａｍｅｓ＿ｎ
ｎｓ（）など）を定義する。これらの「ｎｎｓ」操作は
複合名を引数として取るが、名前自体ではなく、この名
前に関連づけられた次命名システム・ポインタに対して
操作を行う。図１２は正規の複合名ＳＰＩコンテキスト
操作とｎｎｓ複合名ＳＰＩ操作との相違を示している。 ｃｔｘ−＞ｃ＿ｌｏｏｋｕｐ（“ａ／Ｂ”，＆ｓｔａｔ
ｕｓ） に対する呼出しが複合名“ａ／Ｂ”にバインドされた参
照の返しをもたらすのに対し、 ｃｔｘ−＞ｃ＿ｌｏｏｋｕｐ＿ｎｎｓ（“ａ／Ｂ”，＆
ｓｔａｔｕｓ） に対する呼出しは“ａ／Ｂ”の次命名システム・ポイン
タにバインドされた参照の返しをもたらす。

【００５９】アトム名ＳＰＩ 複合名ＳＰＩはコンテキストが複合名を取り扱うことを
必要としている。アトム名を取り扱うことができればよ
い命名サービス・プロバイダはアトム名ＳＰＩを備えて
いなければならない。

【００６０】アトム名ＳＰＩはアトム名に対して操作を
行うためのコンテキスト操作をミラーする一連の操作
（ａ＿ｌｏｏｋｕｐ（）、ａ＿ｌｉｓｔｎａｍｅｓ（）
など）を定義する。さらに、アトム名ＳＰＩはアトム名
に関連づけられた次命名システム・ポインタを取り扱う
一連の操作（ａ＿ｌｏｏｋｕｐ＿ｎｎｓ（）、ａ＿ｌｉ
ｓｔｎａｍｅｓ＿ｎｎｓ（）など）も含んでいる。

【００６１】アトム名ＳＰＩを使用する命名サービス・
プロバイダは階層命名サービスの基本ビルディング・ブ
ロックをもたらす単一のコンテキスト内での分解を取り
扱う。アトム名ＳＰＩを供給するコンテキスト・インプ
リメンテーションは、アトム名と、そのアトム名に関す
るあらゆる次命名システム・ポインタ上での操作のため
にインプリメンテーションを備えている。

【００６２】アトムＳＰＩを供給するコンテキスト・イ
ンプリメンテーションは、その入力名が命名システムの
ターゲット・コンテキストの分解される、あるいは操作
が行われる名前を表す単一のストリングであると期待し
ている。換言すると、入力名は１コンテキスト以上にわ
たることができない。

【００６３】強い分離（上述の定義参照）をサポートし
ているコンテキスト・インプリメンテーションは、その
特定の命名システムに対する命名規則を使用して、先頭
／最後のコンポーネントに複合名を構文解析する付加的
な操作ｃ＿ｃｏｍｐｏｎｅｎｔ＿ｐａｒｓｅｒ（）を供
給しなければならない。（複合名を先頭／最後のコンポ
ーネントに構文解析するプロトコルの説明は、参照する
ことによって、本明細書の一部となる米国特許第５３７
７３２３号を参照されたい）。ｃ＿ｃｏｍｐｏｎｅｎｔ
＿ｐａｒｓｅｒ（）に対する入力は複合名であり、その
最初のコンポーネントはターゲット・コンテキストで分
解される。出力は第１のコンポーネントｈｅａｄであ
り、コンポーネントの残りｔａｉｌは別の引数に戻され
る。次のコード・フラグメントはどのようにして呼び出
すかを説明するものである。 ｈｅａｄ＝ｃｔｘ−＞ｃ＿ｃｏｍｐｏｎｅｎｔ＿ｐａｒ
ｓｅｒ（ｃｏｍｐｏｕｎｄ＿ｎａｍｅ，＆ｔａｉｌ，＆
ｃｓｔａｔｕｓ）；ただし、ｃｏｍｐｏｕｎｄ＿ｎａｍ
ｅは構文解析対象の複合名である ｈｅａｄはこのコンテキストｃｔｘの命名規則によるｃ
ｏｍｐｏｕｎｄ＿ｎａｍｅの最初のアトム名である ｔａｉｌはｈｅａｄを除くｃｏｍｐｏｕｎｄ＿ｎａｍｅ
のアトム名の配列された残りのものである ｃｓｔａｔｕｓはｃ＿ｃｏｍｐｏｎｅｎｔ＿ｐａｒｓｅ
ｒ（）操作の成功または失敗を示す状況である。

【００６４】たとえば、ｉ：ｊ：ｋが左から右へのコロ
ンで区切られた名前構文を有している名前スペースから
の複合名であるとする。この命名システムに対するコン
テキスト・インプリメンテーションはｃ＿ｃｏｍｐｏｎ
ｅｎｔ＿ｐａｒｓｅｒ（）に対するインプリメンテーシ
ョンを供給する。次のものを実行した場合、 ｈｅａｄ＝ｃｔｘ−＞ｃ＿ｃｏｍｐｏｎｅｎｔ＿ｐａｒ
ｓｅｒ（”ｉ：ｊ：ｋ”，＆ｔａｉｌ，＆ｃｓｔａｔｕ
ｓ）；ｈｅａｄが”ｉ”を含むのに対し、ｔａｉｌは”
ｊ：ｋ”を含んでいる。

【００６５】静的な弱い分離をサポートしているコンテ
キスト・インプリメンテーションは、コンポジット名を
最初のｃｏｍｐｏｕｎｄ＿ｎａｍｅとｒｅｓｔコンポー
ネントに構文解析するルーチンｐ＿ｃｏｍｐｏｎｅｎｔ
＿ｐａｒｓｅｒ（）（上述の）を供給しなければならな
い。

【００６６】ＦＮフレームワークがアトム名ＳＰＩをエ
キスポートするコンテキストとどのように相互作用する
かの詳細については、連合命名フレームワークの項で説
明する。

【００６７】ＳＰＩの要約 要約すると、本発明を使用して連合する命名サービス・
プロバイダの代替策は次のとおりである。 （１）あらゆるコンポジット名全体を扱うことのできる
コンポジット名を認識する命名サービスに対するコンポ
ジット名ＳＰＩの操作用のインプリメンテーションを供
給する。

【００６８】（２）おそらく２つ以上の命名システムか
らの名前を扱うことができるが、必ずしも全体でなくと
もよいコンポジット名を認識する命名サービスに対する
コンポジット名ＳＰＩの操作用のインプリメンテーショ
ンを供給する。

【００６９】（３）コンポジット名を認識しない命名サ
ービスに対する複合名ＳＰＩの操作用のインプリメンテ
ーションを供給する。このインプリメンテーションは複
合名を受け入れ、これに対してコンテキスト操作を行
う。

【００７０】（４）階層命名サービスのビルディング・
ブロックであるアトム名サービスに対するアトム名ＳＰ
Ｉの操作用のインプリメンテーションを供給する。この
インプリメンテーションは、アトム名を受け入れ、これ
に対してコンテキスト操作を行う。

【００７１】Ｃ．連合命名フレームワーク 本発明の第２の主要な要素は図１０にブロック１１０８
として示されているＦＮフレームワークである。新しい
任意の命名およびディレクトリ・システムが、アプリケ
ーションの再コンパイル、再リンクを行うこと、および
このアプリケーションを停止することを必要とせずに、
実行時にアプリケーションにアクセスできるようにする
ことを目的として有しているのが、この要素である。以
下で説明するように、ＦＮフレームワークは上述のＦＮ
ＳＰＩ準拠のコンテキスト・インプリメンテーション
を差し込むことができるインフラストラクチャを備えて
おり、またクライアント・アプリケーションに透過的に
新しい命名サービスを追加することのできるクライアン
ト・アプリケーションに対するインタフェースを備えて
いる。

【００７２】ＦＮフレームワークは異なるＦＮ ＳＰＩ
を供給する異なるインプリメンテーションがクライアン
ト機械に同時に存在することを可能とし、これによって
クライアント・アプリケーションが命名サービスの異な
る数のフェデレーションにアクセスすることを可能とす
る。本発明の使用方法の例を図１０に示す。図１０にお
いて、システム１１００はクライアント・アプリケーシ
ョン層１１０４を備えており、この層はコンポジット名
１１０２を取り扱うことができ、指定されたＦＮ ＳＰ
Ｉを各々が使用する特定の命名サービス１１１０、１１
１２、１１１４に対する各種のコンテキスト・インプリ
メンテーションがインタフェースできる連合命名フレー
ムワーク層１１０８の上に置かれている連合命名アプリ
ケーション・プログラミング・インタフェース（「ＦＮ
ＡＰＩ」）層１１０６とインタフェースしている。コ
ンテキスト・インプリメンテーション１１１０はＸ．５
００ディレクトリ・サービス１１１６を排他的にサポー
トするインタフェースであるＸＤＳに対するＦＮ ＳＰ
Ｉのマッピングを表している。このコンテキスト・イン
プリメンテーション１１１０は静的な弱い分離をサポー
トしており、複合名ＳＰＩを供給する。同様に、コンテ
キスト・インプリメンテーション１１１２はインターネ
ットＤＮＳを排他的にサポートするインタフェースであ
るインターネットＤＮＳレゾルバＡＰＩに対するＦＮ
ＳＰＩのマッピングを表している。コンテキスト・イン
プリメンテーション１１１２は強い分離をサポートして
おり、複合名ＳＰＩを供給する。また、コンテキスト・
インプリメンテーション１１１４はＮＩＳ＋を排他的に
サポートするインタフェースであるＮＩＳ＋ ＡＰＩに
対するＦＮ ＳＰＩのマッピングを表す。コンテキスト
・インプリメンテーション１１１４は強い分離をサポー
トしており、複合名ＳＰＩを供給する。

【００７３】図１３ａはクライアント・アプリケーショ
ンからの入力を取り入れるためにＦＮフレームワークが
用い、クライアント・アプリケーションが要求したコン
ポジット名に対する操作を達成するため該当するＦＮ
ＳＰＩと対話するプロセスを示している。

【００７４】図１３を参照すると、クライアント・アプ
リケーションは、コンテキスト・ハンドル、コンポジッ
ト名、実行すべき操作、および操作に必要な1つまたは
複数の引数（ｃｔｘ、ｎａｍｅ、ｏｐｅｒａｔｉｏｎ
Ａ、ａｒｇｓなど）１３０４からなるＦＮフレームワー
ク１３０２に対して入力を供給する。ＦＮフレームワー
クはまず、コンテキスト・ハンドルｃｔｘがポイントし
たコンテキスト・インプリメンテーションにロードし、
どのＦＮ ＳＰＩがｃｔｘ１３０６、１３１６、１３４
０および１３４６によってサポートされているかを判定
する。

【００７５】コンポジット名ＳＰＩとのＦＮフレームワ
ークの相互作用 コンテキスト・インプリメンテーションがコンポジット
名ＳＰＩ１３０８をサポートしている場合、ＦＮフレー
ムワークはｏｐｅｒａｔｉｏｎ Ａに適切なｃｔｘに対
するコンテキスト・インプリメンテーションの操作（ｃ
ｔｘ＿）を呼び出し、これを操作（ｎａｍｅ、ａｒｇ
ｓ）１３１０に対する引数とともに供給する。この操作
を行った結果はクライアント・アプリケーション１３１
２に返される。

【００７６】コンポジット名ＳＰＩを供給するコンテキ
スト・インプリメンテーションに関する次の例を考え
る。

【００７７】ｎａｍｅは“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ／
ｇ”である（これは２つの命名システムにわたってい
る。“ａ＝ｂ／ｃ＝ｄ”は一方の命名システムに属して
おり、“ｅ／ｆ／ｇ”は他方の命名システムに属してい
る。） ｏｐｅｒａｔｉｏｎ Ａは“ｌｏｏｋｕｐ（）”である ａｒｇｓは空である（他の引数はない） ＦＮフレームワークは引数（“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ
／ｇ”，“ｌｏｏｋｕｐ（）”，｛｝）をｃｔｘのコン
テキスト・インプリメンテーション（ＣＣ１）に供給す
る。ＣＣ１は次のようにコンポジット名“ａ＝ｂ／ｃ＝
ｄ／ｅ／ｆ／ｇ”に対してｃｔｘ＿ｌｏｏｋｕｐ（）操
作を行い、 ｒｅｆ＝ｃｔｘ−＞ｃｔｘ＿ｌｏｏｋｕｐ（）（“ａ＝
ｂ／ｃ＝ｄ／ｅ／ｆ／ｇ”，＆ｓｔａｔｕｓ）；その操
作の結果（ｒｅｆ）をＦＮフレームワークに返し、フレ
ームワークは次いで結果をクライアント・アプリケーシ
ョンに返す。

【００７８】上記の例はあるコンテキスト・インプリメ
ンテーションＣＣ１を用いたＦＮフレームワークがどの
ように、２つの命名システムにわたっているコンポジッ
ト名に対して操作を行うかを示している。ＣＣ１はコン
ポジット名ＳＰＩを使用しており、したがって、コンポ
ジット名が複数の命名システムにわたっている場合で
も、コンポジット名全体を処理すると考えられる。ＦＮ
フレームワークを使用しているクライアント・アプリケ
ーションも、ＦＮフレームワーク自体もＣＣ１に関する
知識を含んでいない。ＦＮフレームワークはコンポジッ
ト名ＳＰＩを使用して、ＣＣ１と通信している。

【００７９】部分コンポジット名ＳＰＩとのＦＮフレー
ムワークの相互作用 コンテキスト・インプリメンテーションが部分コンポジ
ット名ＳＰＩ１３１８をサポートしている場合、ＦＮフ
レームワークはｏｐｅｒａｔｉｏｎ Ａに適切なｃｔｘ
に対するコンテキスト・インプリメンテーションの操作
（ｐ＿）を呼び出し、これを操作（ｎａｍｅ，ａｒｇ
ｓ）１３２０に対する引数とともに供給する。コンテキ
スト・インプリメンテーションはｐ＿操作およびｓｔａ
ｔｕｓ１３２２の呼出し結果をＦＮフレームワークに返
す。ｐ＿操作から返されたときに、操作が進めるだけ進
んでいる（成功するか、継続できなくなって）１３３４
を、操作の状況１３２４が示した場合、ＦＮフレームワ
ークは操作の結果をクライアント・アプリケーション１
３１２に返す。操作を継続する必要がある１３２６と、
状況が示した場合、ＦＮフレームワークはｓｔａｔｕｓ
から情報を引き出し１３２８、操作を継続する。ｓｔａ
ｔｕｓオブジェクトは次のものを含んでいる。 −ｒｎａｍｅ、まだ処理されていないｎａｍｅの残りの
部分 −ｒｒｅｆ、操作を継続するためのコンテキストの参照

【００８０】ＦＮフレームワークはｒｎａｍｅを使用し
て、ｎａｍｅを更新する。換言すると、ｒｎａｍｅは効
果的に、ＦＮフレームワークによる次の相互作用で使用
される新しいｎａｍｅ引数になる。ＦＮフレームワーク
は状況オブジェクトからのｒｒｅｆも使用して、新しい
コンテキスト・ハンドルｃｔｘ＿ｎｅｗを構築する。ｃ
ｔｘ＿ｎｅｗはｒｒｅｆと関連づけられたコンテキスト
・インプリメンテーションが供給するｃｏｎｓｔｒｕｃ
ｔｏｒ（）操作を呼び出すことによって作成される１３
３０。ｃｔｘはｃｔｘ＿ｎｅｗに更新され、効果的に、
ＦＮフレームワークによる次の相互作用で使用される新
しいｃｔｘ引数になる。ＦＮフレームワークはこの手順
を繰り返して、どのＦＮ ＳＰＩを新しいｃｔｘのコン
テキスト・インプリメンテーションがサポートしている
かを判定し１３３２、新しい引数（ｎａｍｅ、ｏｐｅｒ
ａｔｉｏｎ Ａ、ａｒｇｓ）を新しいコンテキスト・イ
ンプリメンテーションに供給する。

【００８１】上記を説明するために、部分コンポジット
名ＳＰＩを供給するコンテキスト・インプリメンテーシ
ョン（ＰＣ１）の次の例を考える。

【００８２】ｎａｍｅは“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ／
ｇ”である（これは２つの命名システムにわたってい
る。“ａ＝ｂ／ｃ＝ｄ”は一方の命名システムに属して
おり、“ｅ／ｆ／ｇ”は他方の命名システムに属してい
る。） ｏｐｅｒａｔｉｏｎ Ａは“ｌｏｏｋｕｐ（）”である ａｒｇｓは空である（他の引数はない） ＦＮフレームワークは入力（“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ
／ｇ”，“ｌｏｏｋｕｐ（）”，｛｝）をｃｔｘのコン
テキスト・インプリメンテーション（ＰＣ１）に供給す
る。ＰＣ１は次のようにコンポジット名“ａ＝ｂ／ｃ＝
ｄ／ｅ／ｆ／ｇ”に対してｐ＿ｌｏｏｋｕｐ（）操作を
行い、 ｒｅｆ＝ｃｔｘ−＞ｐ＿ｌｏｏｋｕｐ（“ａ＝ｂ／ｃ＝
ｄ／ｅ／ｆ／ｇ”，＆ｓｔａｔｕｓ）；その操作の結果
（ｒｅｆ）をＦＮフレームワークに返す。

【００８３】この例の場合、ＰＣ１が“ａ＝ｂ／ｃ＝ｄ
／ｅ／ｆ／ｇ”を処理し、ＣＯＮＴＩＮＵＥ状況をＦＮ
フレームワークに返すものと想定する。さらに、次の２
つの状況情報を返すものとする。 −ｒｎａｍｅ−残っている名前（“ｅ／ｆ／ｇ”） −ｒｒｅｆ−操作を継続するためのコンテキストの参照
（参照は“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ／ｇ”にバインドさ
れている。）

【００８４】ＦＮフレームワークはｒｒｅｆを使用し
て、使用するコンテキスト・インプリメンテーション
（ＰＣ２）を特定し、ＰＣ２からｃｏｎｓｔｒｕｃｔｏ
ｒ（）インプリメンテーションを呼び出して、新しいコ
ンテキスト・ハンドルｃｔｘ＿ｎｅｗを構築する。ＦＮ
フレームワークはｃｔｘの古い値をｃｔｘ＿ｎｅｗと置
き換える。ＦＮフレームワークはｎａｍｅの古い値をｒ
ｎａｍｅとも置き換える。ＦＮフレームワークはこれで
プロセスを継続するのに十分な情報を持つことになる。

【００８５】新しいｃｔｘは部分コンポジット名ＳＰＩ
もエキスポートするものと想定する。ＦＮフレームワー
クは（“ｅ／ｆ／ｇ”，“ｌｏｏｋｕｐ（）”，｛｝）
をＰＣ２に供給する。ＰＣ２はコンポジット名“ｅ／ｆ
／ｇ”に対して次のようにｐ＿ｌｏｏｋｕｐ（）を行
う。 ｒｅｆ＝ｃｔｘ−＞ｐ＿ｌｏｏｋｕｐ（“ｅ／ｆ／
ｇ”，＆ｓｔａｔｕｓ）；この例について、この操作が
この時点で正常に終了するものと想定する。ＰＣ２“ｅ
／ｆ／ｇ”にバインドされた参照（ｒｅｆ）をＦＮフレ
ームワークに返し、フレームワークはこれをクライアン
ト・アプリケーションに返す。

【００８６】上記の例はＦＮフレームワークが２つのコ
ンテキスト・インプリメンテーションＰＣ１およびＰＣ
２をどのように用いるかを示しており、これら２つのコ
ンテキスト・インプリメンテーションは部分コンポジッ
ト名ＳＰＩを使用して、２つの命名システムにわたるコ
ンポジット名に対して操作を行う。ＦＮフレームワーク
を使用するクライアント・アプリケーションも、ＦＮフ
レームワーク自体もＰＣ１またはＰＣ２に関する知識を
含んでいない。ＦＮフレームワークは部分コンポジット
名ＳＰＩを使用して、ＰＣ１およびＰＣ２の両方と通信
を行う。

【００８７】複合名ＳＰＩとのＦＮフレームワークの相
互作用 コンテキスト・インプリメンテーションが複合名ＳＰＩ
１３４０をサポートしている場合、ＦＮフレームワーク
は複合名ＳＰＩエンジン１３４２（この詳細は図１４に
示す）が記述するアルゴリズムを実行する。エンジンの
出力は操作の結果とｓｔａｔｕｓ１３４４である。ｓｔ
ａｔｕｓがＣＯＮＴＩＮＵＥである１３２６場合、ＦＮ
フレームワークはｓｔａｔｕｓからの残っている名前フ
ィールド（ｒｎａｍｅ）を使用して、ｎａｍｅの新しい
値を構築する１３２８。次いで、ｓｔａｔｕｓからｒｒ
ｅｆを抜き出して、コンテキスト・ハンドルｎｅｗ＿ｃ
ｔｘを構築し、ｃｔｘの古い内容をこれと置き換える。
次いで、ＦＮフレームワークは改訂されたｎａｍｅおよ
びコンテキスト・ハンドルｃｔｘを使用して、プロセス
を初めから繰り返す１３３２。ｓｔａｔｕｓがＣＯＮＴ
ＩＮＵＥでない場合１３３４、ＦＮフレームワーク・シ
ステムは復帰する１３１２。

【００８８】ここで、図１４を参照すると、コンテキス
ト・インプリメンテーションが複合名ＳＰＩをサポート
している場合、ＦＮフレームワークは複合名ＳＰＩエン
ジン１４００が記述するアルゴリズムを入力（ｃｔｘ、
ｎａｍｅ、ｏｐｅｒａｔｉｏｎ Ａ、およびａｒｇｓ）
１４０４に対して実行する（図１３のブロック１３４
２）。図１４において、ＦＮフレームワークはまず、入
力ｎａｍｅのどの部分をこのコンテキストが処理するの
かを判定しなければならない。すなわち、コンテキスト
が複合名ＳＰＩをサポートしているため、ＦＮフレーム
ワークは操作するコンテキストに関して複合名ｃｏｍｐ
ｏｕｎｄ＿ｎａｍｅを取得しなければならない。このコ
ンテキストが使用しないｎａｍｅの残りはｒｅｓｔとい
う変数に保持される。

【００８９】コンテキスト・インプリメンテーションが
強い分離をサポートしている場合１４２０、ｃｏｍｐｏ
ｕｎｄ＿ｎａｍｅはｎａｍｅの最初のコンポーネントに
すぎず、ｒｅｓｔは最初のコンポーネントのないｎａｍ
ｅのすべてになる１４２２。

【００９０】コンテキストが静的な弱い分離をサポート
している場合１４０８、１４１２、ＦＮフレームワーク
はコンテキスト・インプリメンテーションが供給するｐ
＿ｐａｒｓｅ＿ｃｏｍｐｏｎｅｎｔ（）機能を呼び出し
て、このコンテキストの命名システムに属しているコン
ポジット名ｎａｍｅの最初のコンポーネント（ｃｏｍｐ
ｏｕｎｄ＿ｎａｍｅ）を抜き出す。ｐ＿ｐａｒｓｅ＿ｃ
ｏｍｐｏｎｅｎｔ（）はこの命名システムが消費しない
残りをｒｅｓｔに返す１４１６。

【００９１】コンテキスト・インプリメンテーションが
動的な弱い分離をサポートしている場合１４１４、ＦＮ
フレームワークはｎａｍｅ全体をコンテキスト・インプ
リメンテーションに対するｃｏｍｐｏｕｎｄ＿ｎａｍｅ
として使用する。これはコンテキスト・インプリメンテ
ーションがｃｏｍｐｏｕｎｄ＿ｎａｍｅのどの部分を消
費すべきかを動的に決定し、残りの名前フィールドｒｎ
ａｍｅを適宜ｓｔａｔｕｓにセットする。ｒｅｓｔはＮ
ＵＬＬにセットされる１４１８。

【００９２】この時点で、すべての異なるタイプの分離
に関して、ＦＮフレームワークはコンテキスト・インプ
リメンテーションへの供給のための複合名になるように
セットされたｃｏｍｐｏｕｎｄ＿ｎａｍｅと、ｎａｍｅ
の未使用部分にセットされたｒｅｓｔを有している。ｒ
ｅｓｔがＮＵＬＬである場合１４２６、ｃｏｍｐｏｕｎ
ｄ＿ｎａｍｅは処理されるｎａｍｅの最後のコンポーネ
ントになる。この場合、ＦＮフレームワークはｏｐｅｒ
ａｔｉｏｎ Ａに対応するコンテキスト・インプリメン
テーションからｃ＿操作を呼び出し、これを引数ｃｔ
ｘ、ｃｏｍｐｏｕｎｄ＿ｎａｍｅおよびａｒｇｓ１４２
８とともに供給する。ｒｅｓｔがＮＵＬＬでないが１４
３０、ｎａｍｅの最後のコンポーネントであり、かつ空
のストリングである１４３４場合、クライアント・アプ
リケーションはｃｏｍｐｏｕｎｄ＿ｎａｍｅと関連づけ
られた次命名システム・ポインタに対して操作を行おう
としていることを指定する。この場合、ＦＮフレームワ
ークはｏｐｅｒａｔｉｏｎＡに対応したコンテキスト・
インプリメンテーションからｃ＿ｎｎｓ操作を呼び出
し、これを引数ｃｔｘ、ｃｏｍｐｏｕｎｄ＿ｎａｍｅお
よびａｒｇｓ１４３６とともに供給する。ｒｅｓｔがｎ
ａｍｅの最後のコンポーネントでないか、最後である
が、空のストリングでない１４４０場合、ｃｏｍｐｏｕ
ｎｄ＿ｎａｍｅが指定したコンテキストが中間コンテキ
ストとして作用する。この場合、ＦＮフレームワークは
ｃｔｘ、ｃｏｍｐｏｕｎｄ＿ｎａｍｅおよびａｒｇｓ１
４４２におけるコンテキスト・インプリメンテーション
から操作ｃ＿ｌｏｏｋｕｐ＿ｎｎｓ（）を呼び出す。ｃ
＿ｌｏｏｋｕｐ＿ｎｎｓ（）の結果（ｒｅｆ２）が成功
した場合１４４８、操作を継続するための次の命名シス
テムに対する参照を含むこととなり、したがって、ｃ＿
ｌｏｏｋｕｐ＿ｎｎｓ（）から正常に復帰したときに、
状況がＣＯＮＴＩＮＵＥ１４５０に変わり、操作を継続
しなければならないこと、およびｓｔａｔｕｓのｒｒｅ
ｆフィールドがｒｅｆ２にセットされたことを示すよう
になる。

【００９３】この時点で、ＦＮフレームワークは状況の
次のアドミニストレーションを行ってから、複合名ＳＰ
Ｉエンジンを終了する。ｒｅｓｔ変数はさらに処理しな
ければならないｎａｍｅの一部を含んでいる。操作が成
功したかどうかにかかわりなく、ｒｅｓｔを状況オブジ
ェクトのｒｎａｍｅフィールドに付加して、処理をさら
に必要とするｎａｍｅの残りの部分をｒｎａｍｅが示す
ようにしなければならない１４３７。ＦＮフレームワー
クはこの場合、複合名ＳＰＩエンジンを終了して、図１
３の１３４４で継続する（これについては、上記の部分
コンポジット名の項で詳述した）。

【００９４】上記を説明するために、複合名ＳＰＩを供
給するコンテキスト・インプリメンテーション（Ｃ１）
に関する次の例を考える。ｎａｍｅは“ａ＝ｂ／ｃ＝ｄ
／ｅ／ｆ／ｇ”である（これは２つの命名システムにわ
たっており、“ａ＝ｂ／ｃ＝ｄ”は一方の命名システム
に属しており、“ｅ／ｆ／ｇ”は他方の命名システムに
属している） ｏｐｅｒａｔｉｏｎ Ａは“ｌｏｏｋｕｐ（）”である ａｒｇｓは空である（他の引数はない） この例について、Ｃ１が静的な弱い分離をサポートして
いるものと想定する。

【００９５】ＦＮフレームワークはｐ＿ｃｏｍｐｏｎｅ
ｎｔ＿ｐａｒｓｅｒ（）をＣ１から呼び出して、ｃｏｍ
ｐｏｕｎｄ＿ｎａｍｅおよびｒｅｓｔ引数を抜き出す。 ｃｏｍｐｏｕｎｄ＿ｎａｍｅ＝ｃｔｘ−＞ｐ＿ｃｏｍｐ
ｏｎｅｎｔ＿ｐａｒｓｅｒ（“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ
／ｇ”，＆ｒｅｓｔ，＆ｐｓｔａｔｓ）；Ｃ１のｐ＿ｃ
ｏｍｐｏｎｅｎｔ＿ｐａｒｓｅｒ（）が等号文字
（‘＝’）を使用して、名前のどのコンポーネントがそ
の命名システムに属しているかを判定するものと想定す
る。ｃｏｍｐｏｕｎｄ＿ｎａｍｅはこの場合、“ａ＝ｂ
／ｃ＝ｄ”を含んでおり、ｒｅｓｔは“ｅ／ｆ／ｇ”を
含んでいる。ｒｅｓｔがナルでも、最後のコンポーネン
トでもないので、“ａ＝ｂ／ｃ＝ｄ”が指定したコンテ
キストは中間命名システムにある。ＦＮフレームワーク
は入力（“ａ＝ｂ／ｃ＝ｄ”，“ｌｏｏｋｕｐ＿ｎｎｓ
（）”，｛｝）をｃｔｘのコンテキスト・インプリメン
テーション（Ｃ１）に供給する。Ｃ１はｃ＿ｌｏｏｋｕ
ｐ＿ｎｎｓ（）操作を複合名“ａ＝ｂ／ｃ＝ｄ”に対し
て行い、 ｒｅｆ２＝ｃｔｘ−＞ｃ＿ｌｏｏｋｕｐ＿ｎｎｓ（“ａ
＝ｂ／ｃ＝ｄ”，＆ｓｔａｔｕｓ）；この操作の結果
（ｒｅｆ２）をＦＮフレームワークに返す。

【００９６】この例の場合、この操作が成功したものと
想定する。この場合、ＦＮフレームワークはｓｔａｔｕ
ｓをＣＯＮＴＩＮＵＥにセットし、ｓｔａｔｕｓの分解
された参照フィールドｒｒｅｆをｒｅｆ２にセットす
る。ｒｅｓｔを状況の残りの名前フィールドｒｎａｍｅ
に付加する。 −ｒｎａｍｅ（“ｅ／ｆ／ｇ”） −ｒｒｅｆ（ｃ＿ｌｏｏｋｕｐ＿ｎｎｓ（“ａ＝ｂ／ｃ
＝ｄ”，．．．の結果）操作） ＦＮフレームワークは次いで、ｒｒｅｆを使用して、使
用するコンテキスト・インプリメンテーション（Ｃ２）
を特定し、Ｃ２からｃｏｎｓｔｒｕｃｔｏｒ（）インプ
リメンテーションを呼び出して、新しいコンテキスト・
ハンドルｃｔｘ＿ｎｅｗを構築する。ＦＮフレームワー
クはｃｔｘの古い値をｃｔｘ＿ｎｅｗと置き換える。Ｆ
Ｎフレームワークはｎａｍｅの古い値をｒｎａｍｅと置
き換える。ＦＮフレームワークはこれでプロセスを継続
するのに十分な情報を持つことになる。

【００９７】Ｃ２が複合名ＳＰＩを供給し、動的な弱い
分離をサポートしているものと想定する。ＦＮフレーム
ワークはｒｅｓｔをＮＵＬＬにセットし、入力（“ｅ／
ｆ／ｇ”，“ｌｏｏｋｕｐ＿ｕｐ（）”，｛｝）をＣ２
に供給する。Ｃ２は次のようにコンポジット名“ｅ／ｆ
／ｇ”に対してｃ＿ｌｏｏｋｕｐ（）を行う。 ｒｅｆ＝ｃｔｘ−＞ｃ＿ｌｏｏｋｕｐ（“ｅ／ｆ／
ｇ”，＆ｓｔａｔｕｓ）；この例の場合、この操作がこ
の時点で正常に終了するものと想定する。Ｃ２は“ｅ／
ｆ／ｇ”にバインドされた参照（ｒｅｆ）をＦＮフレー
ムワークに返す。ｒｅｓｔがＮＵＬＬであるため、ｓｔ
ａｔｕｓの内容に対する更新は必要ない。ＦＮフレーム
ワークはｒｅｆをクライアント・アプリケーションに返
す。

【００９８】上記の例はＦＮフレームワークがどのよう
に、両方とも複合名ＳＰＩを使用している２つのコンテ
キスト・インプリメンテーションＣ１およびＣ２を用い
て、２つの命名システムにわたっているコンポジット名
に対して操作を行うのかを示している。Ｃ１が静的な弱
い分離をサポートしているのに対し、Ｃ２が動的な弱い
分離をサポートしている。ＦＮフレームワークを使用す
るクライアント・アプリケーションも、ＦＮフレームワ
ーク自体もＣ１またはＣ２に関する知識を含んでいな
い。ＦＮフレームワークは複合名ＳＰＩを使用して、Ｃ
１およびＣ２の両方と通信を行う。

【００９９】アトム名ＳＰＩとのＦＮフレームワークの
相互作用 図１３にもう一度戻ると、コンテキスト・インプリメン
テーションがアトム名ＳＰＩ１３４６をサポートしてい
る場合、ＦＮフレームワークはアトム名ＳＰＩエンジン
１３４８（この詳細は、図１５に示されている）が記述
するアルゴリズムを実行する。エンジンの出力はオペレ
ーションの結果とｓｔａｔｕｓ１３５０である。ｓｔａ
ｔｕｓがＣＯＮＴＩＮＵＥである場合１３２６、ＦＮフ
レームワークはｓｔａｔｕｓからの残りの名前フィール
ド（ｒｎａｍｅ）を使用して、ｎａｍｅの新しい値を構
築する１３２８。次いで、ｓｔａｔｕｓからｒｒｅｆを
抜き出して、コンテキスト・ハンドルｎｅｗ＿ｃｔｘを
構築し、ｃｔｘの古い値をこれと置き換える。ＦＮフレ
ームワークは次いで、改訂されたｎａｍｅとコンテキス
ト・ハンドルｃｔｘを使用して、このプロセスを初めか
ら繰り返す１３３２。ｓｔａｔｕｓがＣＯＮＴＩＮＵＥ
でない場合１３３４、ＦＮフレームワーク・システムは
復帰する１３１２。

【０１００】コンテキスト・インプリメンテーションが
アトム名ＳＰＩをサポートしている場合（図１３の１３
４６）、ＦＮフレームワークは図１５のアトム名ＳＰＩ
１５００で記述されているアルゴリズムを実行する。図
１５において、ＦＮフレームワークはまず、入力ｎａｍ
ｅのどの部分をこのコンテキストが処理するのかを判定
しなければならない。すなわち、コンテキストがアトム
名ＳＰＩをサポートしているため、ＦＮフレームワーク
は操作するコンテキストに対するアトム名ｈｅａｄを取
得しなければならない。これを２つのステップで行う。
まず、ｎａｍｅから複合名ｃｏｍｐｏｕｎｄ＿ｎａｍｅ
を取得し、次いで、ｃｏｍｐｏｕｎｄ＿ｎａｍｅから処
理するアトム名部分ｈｅａｄを取得する必要がある。ｃ
ｏｍｐｏｕｎｄ＿ｎａｍｅの一部ではないｎａｍｅの残
りの部分は、ｒｅｓｔという変数に保持される。ｈｅａ
ｄの一部ではないｃｏｍｐｏｕｎｄ＿ｎａｍｅの残りの
部分はｔａｉｌという変数に保持される。

【０１０１】コンテキストが強い分離をサポートしてい
る場合１５０８、ｃｏｍｐｏｕｎｄ＿ｎａｍｅはｎａｍ
ｅの最初のコンポーネントだけとなり、ｒｅｓｔは最初
のコンポーネント以外のｎａｍｅのすべての部分となる
１５１０。ＦＮフレームワークは次いで、コンテキスト
・インプリメンテーションが供給するｃ＿ｐａｒｓｅ＿
ｃｏｍｐｏｎｅｎｔ（）機能（前述した）を呼び出し
て、処理するアトム・コンポーネント（ｈｅａｄ）を抜
き出す。ｃ＿ｐａｒｓｅ＿ｃｏｍｐｏｎｅｎｔ（）はｔ
ａｉｌにｈｅａｄのないｃｏｍｐｏｕｎｄ＿ｎａｍｅの
残りも返す１５１２。

【０１０２】コンテキストが静的な弱い分離をサポート
している場合１５１４、１５１８、ＦＮフレームワーク
はコンテキスト・インプリメンテーションが供給するｐ
＿ｐａｒｓｅ＿ｃｏｍｐｏｎｅｎｔ（）機能（前述し
た）を呼び出して、このコンテキストの命名システムに
属するコンポジット名ｎａｍｅの最初のコンポーネント
（ｃｏｍｐｏｕｎｄ＿ｎａｍｅ）を抜き出す１５２０。
ｐ＿ｐａｒｓｅ＿ｃｏｍｐｏｎｅｎｔ（）はこの命名シ
ステムが消費しない残りをｒｅｓｔとして返す１５２
２。

【０１０３】コンテキスト・インプリメンテーションが
動的な弱い分離をサポートしている場合１５２４、ＦＮ
フレームワークはｎａｍｅ全体をコンテキスト・インプ
リメンテーションに対するｃｏｍｐｏｕｎｄ＿ｎａｍｅ
として使用する。これはコンテキスト・インプリメンテ
ーションがｃｏｍｐｏｕｎｄ＿ｎａｍｅのどの部分を消
費すべきかを動的に決定し、復帰状況を適宜決定するか
らである。ｒｅｓｔはＮＵＬＬにセットする１５２６。

【０１０４】弱い分離の両方の形式について、ｈｅａｄ
はｃｏｍｐｏｕｎｄ＿ｎａｍｅの最初のコンポーネント
であり、ｔａｉｌはｈｅａｄ以外のｃｏｍｐｏｕｎｄ＿
ｎａｍｅの残りの部分となる１５２２。

【０１０５】この時点で、すべての異なるタイプの分離
について、ＦＮフレームワークはｃｏｍｐｏｕｎｄ＿ｎ
ａｍｅをこのコンテキストｃｔｘの命名システムに属す
る複合名になるようにセットし、ｒｅｓｔをｎａｍｅの
未使用部分にセットする。さらに、ｈｅａｄはｃｔｘが
処理するｃｏｍｐｏｕｎｄ＿ｎａｍｅからのアトム名に
セットされ、ｔａｉｌはｃｏｍｐｏｕｎｄ＿ｎａｍｅの
残りの部分にセットされる。

【０１０６】ｔａｉｌがＮＵＬＬでない場合１５６０、
ｃｏｍｐｏｕｎｄ＿ｎａｍｅにはｈｅａｄ以外にも処理
すべき他のアトム名があり、ｈｅａｄによって指定され
たコンテキストは同じ命名システム内の中間コンテキス
トとなる。ＦＮフレームワークはコンテキスト・インプ
リメンテーションからａ＿ｌｏｏｋｕｐ（）をｈｅａｄ
に呼び出して、ｈｅａｄにバインドされた参照（ｒｅｆ
２）を取得する１５６２。ａ＿ｌｏｏｋｕｐ（）を呼び
出した後、ＦＮフレームワークはｔａｉｌの内容を最初
のコンポーネントとしてｒｅｓｔに挿入し、このコンテ
キスト・インプリメンテーションがまだ処理していない
コンポーネントを突き止める１５６４。ｒｅｓｔは、ｓ
ｔａｔｕｓオブジェクトの残りのフィールドｒｎａｍｅ
の内容に付加される１５３７。操作が成功した場合には
１５５２、ＦＮフレームワークは操作の状況をＣＯＮＴ
ＩＮＵＥにセットし１５５４、操作を継続する必要があ
ることを示し、かつｓｔａｔｕｓの分解された参照フィ
ールド（ｒｒｅｆ）をｒｅｆ２にセットする。ＦＮフレ
ームワークは次いで、このエンジンを終了する１５３
８。

【０１０７】ｔａｉｌがＮＵＬＬの場合１５３０、ｈｅ
ａｄはｃｔｘに関連づけられた命名システムで処理され
る最後のアトムとなる。ｒｅｓｔがＮＵＬＬの場合１５
３４、ターゲット・コンテキストに到達している。ＦＮ
フレームワークはｏｐｅｒａｔｉｏｎ Ａに対応するコ
ンテキスト・インプリメンテーションからａ＿操作を呼
び出し１５３６、エンジンを終了する１５３８。

【０１０８】ｔａｉｌがＮＵＬＬであるが１５３０、ｒ
ｅｓｔがｎａｍｅの最後で空のコンポーネントでない場
合１５４４、ｈｅａｄが指定したコンテキストがこの命
名システムを次のものに接続する中間コンテキストとな
る。ＦＮフレームワークは操作ａ＿ｌｏｏｋｕｐ＿ｎｎ
ｓ（）をｈｅａｄに呼び出して、次のコンテキスト（次
の命名システムで）への参照（ｒｅｆ２）を取得して、
操作を継続する１５４６。操作が成功した場合１５５
２、ＦＮフレームワークは状況をＣＯＮＴＩＮＵＥにセ
ットして１５５４、操作を継続しなければならないこと
を示し、ｓｔａｔｕｓの分解された参照フィールドを
（ｒｅｆ２）になるようにセットし、エンジンを終了す
る１５３８。

【０１０９】ｔａｉｌがＮＵＬＬであるが１５３０、ｒ
ｅｓｔがｎａｍｅの最後で空のコンポーネントである場
合１５５６、操作はｈｅａｄに関連づけられた次の命名
システムに対して行われる。ＦＮフレームワークはコン
テキスト・インプリメンテーションからａ＿ｎｎｓ操作
を、引数ｃｔｘ、ｈｅａｄ、およびａｒｇｓによって呼
び出し１５５８、エンジンを終了する１５３８。

【０１１０】アトム名ＳＰＩエンジンを終了した場合１
３５０、ＦＮフレームワークは部分コンポジット名の項
で上述したように継続する（図１３の１３２４）。

【０１１１】上記を説明するため、アトム名ＳＰＩを供
給するコンテキスト・インプリメンテーション（Ａ１）
に関する次の例を考える。ｎａｍｅは“ａ＝ｂ／ｃ＝ｄ
／ｅ／ｆ／ｇ”である（これは２つの命名システムにわ
たっており、“ａ＝ｂ／ｃ＝ｄ”は一方の命名システム
に属しており、“ｅ／ｆ／ｇ”は他方の命名システムに
属している） ｏｐｅｒａｔｉｏｎ Ａは“ｌｏｏｋｕｐ（）”である ａｒｇｓは空である（他の引数はない） この例の場合、Ａ１が静的な弱い分離をサポートしてい
るものと想定する。

【０１１２】ＦＮフレームワークはＡ１からのｐ＿ｃｏ
ｍｐｏｎｅｎｔ＿ｐａｒｓｅｒ（）を呼び出して、ｃｏ
ｍｐｏｕｎｄ＿ｎａｍｅおよびｒｅｓｔ引数を抜き出
す。 ｃｏｍｐｏｕｎｄ＿ｎａｍｅ＝ｃｔｘ−＞ｐ＿ｃｏｍｐ
ｏｎｅｎｔ＿ｐａｒｓｅｒ（“ａ＝ｂ／ｃ＝ｄ／ｅ／ｆ
／ｇ”，＆ｒｅｓｔ，＆ｐｓｔａｔｕｓ）；Ａ１のｐ＿
ｃｏｍｐｏｎｅｎｔ＿ｐａｒｓｅｒ（）が等号文字
（‘＝’）を使用して、名前のどのコンポーネントがそ
の命名システムに属しているかを判定する。ｃｏｍｐｏ
ｕｎｄ＿ｎａｍｅはこの場合、“ａ＝ｂ／ｃ＝ｄ”を含
んでおり、ｒｅｓｔは“ｅ／ｆ／ｇ”を含んでいる。Ｆ
Ｎフレームワークは次いで、ｃｏｍｐｏｕｎｄ＿ｎａｍ
ｅからｈｅａｄとｔａｉｌを抜き出す。ｈｅａｄは“ａ
＝ｂ”となり、ｔａｉｌは“ｃ＝ｄ”になる。ｔａｉｌ
がＮＵＬＬでないため、“ａ＝ｂ”が指定したコンテキ
ストは同じ命名システム内の中間コンテキストである。
ＦＮフレームワークは入力（“ａ＝ｂ”，“ｌｏｏｋｕ
ｐ（）”｛｝）をｃｔｘのコンテキスト・インプリメン
テーション（Ａ１）に供給する。Ａ１はａ＿ｌｏｏｋｕ
ｐ（）操作をアトム名“ａ＝ｂ”に対して次のように行
い、 ｒｅｆ２＝ｃｔｘ−＞ａ＿ｌｏｏｋｕｐ（“ａ＝ｂ”，
＆ｓｔａｔｕｓ）；この操作の結果（ｒｅｆ２）をＦＮ
フレームワークに返す。

【０１１３】この例の場合、この操作が成功したものと
想定する。ＦＮフレームワークはこの場合、ｓｔａｔｕ
ｓをＣＯＮＴＩＮＵＥにセットし、ｓｔａｔｕｓの分解
された参照フィールドｒｒｅｆをｒｅｆ２にセットす
る。次いで、ｔａｉｌ（“ｃ＝ｄ”）をｒｅｓｔ（“ｅ
／ｆ／ｇ”）の前に挿入し、この（“ｃ＝ｄ／ｅ／ｆ／
ｇ”）が新しいｒｅｓｔになる。ＦＮフレームワークは
次いで、ｒｅｓｔを状況の残っている名前フィールドｒ
ｎａｍｅに付加する。 −ｒｎａｍｅ（“ｃ＝ｄ／ｅ／ｆ／ｇ”） −ｒｒｅｆ（ｌｏｏｋｕｐ（“ａ＝ｂ”，．．．）操作
の結果） ＦＮフレームワークはｒｅｓｔをＮＵＬＬにリセットす
る。ＦＮフレームワークは次いで、ｒｒｅｆを使用し
て、次のコンテキスト・オブジェクトに対するハンドル
を構築する。ＦＮフレームワークはｒｒｅｆをＡ１から
のｃｏｎｓｔｒｕｃｔｏｒ（）インプリメンテーション
に供給して、新しいコンテキスト・ハンドルｃｔｘ＿ｎ
ｅｗを構築する。ＦＮフレームワークはｃｔｘの古い値
をｃｔｘ＿ｎｅｗと置き換える。ＦＮフレームワークは
ｎａｍｅの古い値をｒｎａｍｅ（“ｃ＝ｄ／ｅ／ｆ／
ｇ”）と置き換える。ＦＮフレームワークはこれでプロ
セスを継続するのに十分な情報を持つことになる。

【０１１４】ＦＮフレームワークは入力（“ｃ＝ｄ／ｅ
／ｆ／ｇ”，“ｌｏｏｋｕｐ（）”，｛｝）をＡ１に供
給する。アトム名ＳＰＩエンジンにしたがうが、この相
互作用の場合、ｈｅａｄは“ｃ＝ｄ”であり、ｔａｉｌ
はＮＵＬＬである。ｒｅｓｔ（“ｅ／ｆ／ｇ”）はｎａ
ｍｅの最後で空のコンポーネントであり、これは“ｃ＝
ｄ”が指定したコンテキストが中間命名システムの最後
のコンテキストであることを意味する。ＦＮフレームワ
ークはａ＿ｌｏｏｋｕｐ＿ｎｎｓ（）を“ｃ＝ｄ”に呼
び出し、次の命名システムに対する参照を取得して、操
作を継続する。Ａ１は次のようにアトム名“ｃ＝ｄ”に
対してａ＿ｌｏｏｋｕｐ＿ｎｎｓ（）を行う。 ｒｅｆ２＝ｃｔｘ−＞ａ＿ｌｏｏｋｕｐ＿ｎｎｓ（“ｃ
＝ｄ”，＆ｓｔａｔｕｓ）；この例の場合、この操作が
この時点で正常に終了したと想定する。Ａ１は“ｃ＝
ｄ”の次の命名システムにバインドされた参照（ｒｅｆ
２）をＦＮフレームワークに返す。ＦＮフレームワーク
は次いで、操作の状況をＣＯＮＴＩＮＵＥにセットし、
状況の分解された参照部分（ｒｒｅｆ）をｒｅｆ２にセ
ットし、ｒｅｓｔ（“ｅ／ｆ／ｇ”）をｓｔａｔｕｓの
残っている名前（ｒｎａｍｅ）に付加する。

【０１１５】この時点で、ＦＮフレームワークは“ａ＝
ｂ／ｃ＝ｄ”がポイントしている次の命名システムに分
解しており、“ｅ／ｆ／ｇ”に対して操作を継続しなけ
ればならない。この例の場合、新しいｒｒｅｆに関連づ
けられているコンテキスト・インプリメンテーションＣ
２が動的な弱い分離を使用して複合名ＳＰＩを供給して
いると想定する。ＦＮフレームワークはｒｅｓｔをＮＵ
ＬＬにセットし、入力（“ｅ／ｆ／ｇ”，”ｌｏｏｋｕ
ｐ＿ｕｐ（）”，｛｝）をＣ２に供給する。Ｃ２はコン
ポジット名“ｅ／ｆ／ｇ”に対してｃ＿ｌｏｏｋｕ
ｐ（）を次のように行う。 ｒｅｆ＝ｃｔｘ−＞ｃ＿ｌｏｏｋｕｐ（“ｅ／ｆ／
ｇ”，＆ｓｔａｔｕｓ）；この例の場合、この操作がこ
の時点で正常に終了したと想定する。Ｃ２は“ｅｆ／
ｇ”にバインドされた参照（ｒｅｆ）をＦＮフレームワ
ークに返す。“ｅ／ｆ／ｇ”がｎａｍｅの最後のコンポ
ーネントである（すなわち、ｒｅｓｔがＮＵＬＬであ
る）から、ｓｔａｔｕｓの内容に対する更新は必要な
い。ＦＮフレームワークはｒｅｆをクライアント・アプ
リケーションに返す。

【０１１６】上記の例はＦＮフレームワークが２つのコ
ンテキスト・インプリメンテーションＡ１およびＣ２を
どのように用いて、２つの命名システムにわたるコンポ
ジット名に対して操作を行うかを説明したものである。
Ａ１はアトム名ＳＰＩを使用し、静的な弱い分離をサポ
ートしているコンテキスト・インプリメンテーションで
ある。Ｃ２は複合名ＳＰＩを使用し、動的な弱い分離を
サポートしているコンテキスト・インプリメンテーショ
ンである。ＦＮフレームワークを使用しているクライア
ント・アプリケーションも、ＦＮフレームワーク自体も
Ａ１またはＣ２に関する知識を含んでいない。ＦＮフレ
ームワークはアトム名ＳＰＩを使用してＡ１と、また複
合名ＳＰＩを使用してＣ２と通信を行う。

【０１１７】上記の詳細な説明はこの時点での好ましい
実施の形態を示している。しかしながら、当分野の技術
者には、これらの操作の各種の類似したインプリメンテ
ーションが可能であり、本発明範囲内のものであること
が認識されよう。

【０１１８】Ｄ．コンテキスト・インプリメンテーショ
ンのリンク 本発明の第３の要素は異なるコンテキスト・インプリメ
ンテーションを呼び出すためにＦＮフレームワークが使
用する機構である。

【０１１９】好ましい実施の形態において、コンテキス
ト・インプリメンテーションはコンストラクタを使用す
ることによってアプリケーションにリンクされている。
コンテキストに対するすべてのアクセスはそのコンテキ
スト・ハンドルを介するものである。コンテキスト・ハ
ンドルはＦＮ ＳＰＩに固有な他の内部コンストラクタ
を呼び出すこともできる、以下で説明する事前定義の手
法を使用して指定されたコンストラクタを呼び出すこと
によって取得される。ＦＮ ＳＰＩコンストラクタは図
６で説明したものと類似した手法を使用して、適切なＦ
Ｎ ＳＰＩを供給するコンテキスト・オブジェクトに、
ハンドルを返す。コンテキスト・ハンドルを含む以降の
操作は、ＦＮ ＳＰＩを介してコンテキスト・インプリ
メンテーションが供給する対応する操作をトリガする。

【０１２０】図１０はコンテキスト・インプリメンテー
ション１１１０、１１１２、１１１４、命名サービス１
１１６、１１１８、１１２０およびＦＮフレームワーク
１１０８の間の関係を示す。特定のコンテキスト・イン
プリメンテーションに対するコードは、コンテキストの
参照およびアドレス・タイプを使用して一意に特定され
る。コンテキスト・インプリメンテーション内にロード
されたコンストラクタも、コンテキストの参照およびア
ドレス・タイプを使用して一意に特定される。たとえ
ば、上述のように、以下はコンストラクタをどのように
呼び出すかについてのコード・フラグメントを示す。 ｃｔｘ＝ｃｏｎｓｔｒｕｃｔｏｒ（ｒｅｆｅｒｅｎｃ
ｅ）；ただし、ｃｔｘはコンテキスト・オブジェクトに
対するハンドルであり、ｒｅｆｅｒｅｎｃｅは名前をル
ックアップすることによって得られる参照である。

【０１２１】ＦＮフレームワークのアーキテクチャ、お
よびその定義、ならびにＦＮ ＳＰＩを使用することに
より、新しい任意の命名およびディレクトリ・サービス
が再コンパイルなしにアクセス可能となる。ＦＮフレー
ムワークは特定のコンテキスト・インプリメンテーショ
ンに対して依存しておらず、コンテキスト・インプリメ
ンテーションがもたらすインタフェース（ＦＮ ＳＰ
Ｉ）だけに依存している。このため、ＦＮフレームワー
クはコンストラクタを使用することによって、ＦＮフレ
ームワークまたはクライアント・アプリケーションを何
も変更することなく、要求に応じて使用する異なるコン
テキスト・インプリメンテーションを選択することがで
きる。

【０１２２】ＦＮフレームワークおよびコンテキスト・
インプリメンテーションが配備される操作環境がダイナ
ミック・リンキングをサポートしている場合、アプリケ
ーションはこれを再リンクまたは停止することを必要と
しないという他の利点を得る。ダイナミック・リンキン
グが利用できる場合、ＦＮフレームワークはコンストラ
クタを使用することにより要求に応じて異なるコンテキ
スト・インプリメンテーションに動的にリンクでき、こ
れによってアプリケーションを必要となる可能性のある
すべての考えられるコンテキスト・インプリメンテーシ
ョンと予めリンクする必要がなくなる。

【０１２３】当分野の技術者には、本発明の範囲から逸
脱することなく、本明細書で開示した本発明の好ましい
実施の形態に各種の改変および変更を行えることが理解
されよう。したがって、本発明の範囲は上述の特定な発
明の実施の形態に限定されるものではなく、首記の特許
請求の範囲およびその同等物によってのみ画定されるべ
きものである。

【図面の簡単な説明】

【図１】 本発明とともに使用されるタイプの典型的な
コンピュータ・ワークステーションの図である。

【図２】 本発明とともに使用される分散コンピュータ
・システムの典型的な構成の図である。

【図３】 分散システムにおける典型的なクライアント
・サーバの関係を示す図である。

【図４】 共通ホスト・システムにおける典型的なクラ
イアント・サーバの関係を示す図である。

【図５】 コンテキスト・オブジェクトの図である。

【図６】 コンテキスト・オブジェクトの他の図であ
る。

【図７】 クライアントに対する典型的な命名サービス
・プロバイダの機能的関係を示す図である。

【図８】 複数の命名サービス・プロバイダを有するシ
ステムの図である。

【図９】 本発明による複数の命名サービス・プロバイ
ダを有するシステムの構造の図である。

【図１０】 いくつかの異なる命名サービスに対するコ
ンテキスト・インプリメンテーションの例を示す本発明
の他の図である。

【図１１】 連合命名（ＦＮ）フレームワークが部分コ
ンポジットＳＰＩを使用してコンテキスト・インタフェ
ースを実現する方法を示す図である。

【図１２】 複合名と「次命名システム」ポインタの使
い方を示す図である。

【図１３】 連合命名フレームワークを実施するシステ
ムの一般的な操作を示す流れ図である。

【図１４】 連合命名フレームワークを実施するシステ
ムの一般的な操作を示す流れ図である。

【図１５】 連合命名フレームワークを実施するシステ
ムの一般的な操作を示す流れ図である。

【符号の説明】

１ プロセッサ ２ 入出力（Ｉ／Ｏ）部 ３ 中央演算処理装置（ＣＰＵ） ４ メモリ部 ５ キーボード ６ 表示装置 ７ ＣＤ−ＲＯＭ駆動装置 ８ ＣＤ−ＲＯＭ媒体 ９ ディスク記憶装置 １０ プログラム

【手続補正書】

【提出日】平成８年１０月２５日

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図１】

【図２】

【図３】

【図４】

【図１０】

【図５】

【図６】

【図７】

【図１１】

【図８】

【図９】

【図１２】

【図１３】

【図１４】

【図１５】

フロントページの続き (72)発明者 ランガスワミー・ヴァスデヴァン アメリカ合衆国 94022 カリフォルニア 州・ロス アルトス ヒルズ・カリロ レ イン・13428

Claims (6)

【特許請求の範囲】
1. 【請求項１】 中央演算処理装置、メモリ、表示装置お
   よび入出力機構を有しており、２つ以上の命名システム
   にわたるコンポジット名を使用するように構成されたク
   ライアント・アプリケーションと、コンポジット名を分
   解するのに使用される命名サービス機構との間のインタ
   フェース・システムをもたらす少なくとも１台のコンピ
   ュータを有する分散コンピュータ・システムで使用され
   る連合命名フレームワーク・システムにおいて、 前記クライアント・アプリケーションに結合され、命名
   サービス機構を使用してオブジェクトのコンポジット名
   を分解するように構成された、コンピュータ・メモリの
   連合命名フレームワーク機構と、 連合命名サービス・プロバイダ・インタフェースに合致
   するように構成され、連合命名フレームワーク機構に結
   合された1つまたは複数の命名サービス機構と、 それ
   ぞれの命名システムにおける強いあるいは弱い分離に対
   するサポートを示すように構成されている1つまたは複
   数の命名サービス機構とを備えている連合命名フレーム
   ワーク・システム。
2. 【請求項２】 中央演算処理装置、メモリ、表示装置お
   よび入出力機構を有する少なくとも１台のコンピュータ
   を有する分散コンピュータ・システムのクライアント・
   アプリケーションによって使用される、オブジェクトの
   コンポジット名を分解する改善された方法において、 クライアント・アプリケーションによって呼び出せるよ
   うに構成され、命名サービス機構を使用してオブジェク
   トのコンポジット名を分解するように構成されたコンピ
   ュータ・メモリに、指定された連合命名サービス・プロ
   バイダ・インタフェースに合致するコンテキスト・イン
   プリメンテーションを備えた連合命名フレームワークを
   設けるステップを備えており、 コンピュータ制御の下で、クライアント・アプリケーシ
   ョンが連合命名フレームワーク機構を呼び出し、クライ
   アント・アプリケーションがコンテキスト・ハンドル、
   コンポジット名、実行対象の指定された操作、およびそ
   の操作に必要な１つまたは複数の引数を備えた入力を供
   給し、 連合命名フレームワーク機構がコンテキスト・ハンドル
   を使用して、コンテキスト・ハンドルがポイントしたコ
   ンテキスト・インプリメンテーションをロードし、かつ
   どの連合命名サービス・プロバイダ・インタフェースを
   コンテキスト・インプリメンテーションがサポートして
   いるかを判定し、 連合命名フレームワーク機構がコンテキスト・インプリ
   メンテーションによってサポートされている命名サービ
   ス・プロバイダ・インタフェースに適切であり、かつク
   ライアント・アプリケーションによって呼び出された指
   定された操作に適切なものである、第１の操作をコンテ
   キスト・インプリメンテーションに対して呼び出し、 コンテキスト・インプリメンテーションが呼び出された
   第１の操作の結果を返し、かつ連合命名フレームワーク
   機構に状況値を返し、 第１の操作が成功し、これによってコンポジット名を分
   解したか、あるいは継続できないかのいずれかを状況値
   が示している場合には、連合命名フレームワーク機構が
   第１の操作の結果をクライアント・アプリケーションに
   返し、 操作を継続すべきことを状況値が示している場合には、
   連合命名フレームワーク機構が返された状況情報に基づ
   いて、コンポジット名の残りに対する処理を継続するオ
   ブジェクトのコンポジット名を分解する方法。
3. 【請求項３】 クライアント・アプリケーションによっ
   て呼び出された、２つ以上の命名システムにわたるオブ
   ジェクトのコンポジット名を分解するように構成された
   コンピュータ読取り可能プログラム・コード機構が具体
   化されているコンピュータで使用可能な媒体を備えてい
   るコンピュータ・プログラム・プロダクトにおいて、該
   コンピュータ・プログラム・プロダクトのコンピュータ
   読取り可能プログラム・コード機構が、 クライアント・アプリケーションから呼出しを受け入れ
   て、連合命名フレームワーク機構によってコンポジット
   名を分解するように構成され、名前の分解を行うために
   命名サービス機構をさらに使用するように構成されてい
   るコンピュータ読取り可能コード機構と、 連合命名サービス・プロバイダ・インタフェースに合致
   する１つまたは複数の命名サービス機構を収めるように
   構成されており、１つまたは複数の命名サービス機構が
   クライアント・アプリケーションと直接接続していない
   コンピュータ読取り可能コード機構と、 １つまたは複数の命名サービス機構がそれぞれの命名シ
   ステムにおける強いあるいは弱い分離に対するサポート
   を示すように構成されるようにするコンピュータ読取り
   可能コード機構とを備えているコンピュータ・プログラ
   ム・プロダクト。
4. 【請求項４】クライアント・アプリケーションによって
   呼び出された、オブジェクトのコンポジット名を分解す
   るように構成されたコンピュータ読取り可能プログラム
   ・コード機構が具体化されているコンピュータで使用可
   能な媒体を備えているコンピュータ・プログラム・プロ
   ダクトにおいて、該コンピュータ・プログラム・プロダ
   クトのコンピュータ読取り可能プログラム・コード機構
   が、 クライアント・アプリケーションから呼出しを受け入れ
   て、連合命名フレームワーク機構によってコンポジット
   名を分解するように構成され、名前の分解を行うために
   １つまたは複数の命名サービス機構をさらに使用するよ
   うに構成されており、前記１つまたは複数の命名サービ
   ス機構がコンストラクタ機構を使用することによって配
   置されているコンピュータ読取り可能コード機構と、 各々が命名サービスをもたらす１つまたは複数の命名サ
   ービス機構が連合命名サービス・プロバイダ・インタフ
   ェースに合致するように、かつそれぞれの命名システム
   における強いあるいは弱い分離に対するサポートを示す
   ように構成されるようにするコンピュータ読取り可能コ
   ード機構とを備えているコンピュータ・プログラム・プ
   ロダクト。
5. 【請求項５】 クライアント・アプリケーションによっ
   て呼び出された、オブジェクトのコンポジット名を分解
   するように構成されたコンピュータ読取り可能プログラ
   ム・コード機構が具体化されているコンピュータで使用
   可能な媒体を備えているコンピュータ・プログラム・プ
   ロダクトにおいて、該コンピュータ・プログラム・プロ
   ダクトのコンピュータ読取り可能プログラム・コード機
   構が、 クライアント・アプリケーションから呼出しを受け入れ
   て、連合命名フレームワーク機構によってコンポジット
   名を分解するように構成され、名前の分解を行うために
   １つまたは複数の命名サービス機構をさらに使用するよ
   うに構成されているコンピュータ読取り可能コード機構
   と、 命名サービス機構が連合命名サービス・プロバイダ・イ
   ンタフェースにしたがって連合命名フレームワーク機構
   に接続されるように構成されており、新しい命名サービ
   ス機構をクライアント・アプリケーションに影響を与え
   ることなく連合命名フレームワーク機構に接続できるコ
   ンピュータ読取り可能コード機構とを備えているコンピ
   ュータ・プログラム・プロダクト。
6. 【請求項６】 中央演算処理装置、メモリ、表示装置お
   よび入出力機構を有する少なくとも１台のコンピュータ
   を有する分散コンピュータ・システムのクライアント・
   アプリケーションによって使用される、オブジェクトの
   コンポジット名を分解する方法において、 クライアント・アプリケーションによって呼び出せるよ
   うに構成され、命名サービス機構を使用してオブジェク
   トのコンポジット名を分解するように構成されたコンピ
   ュータ・メモリに、指定された連合命名サービス・プロ
   バイダ・インタフェースに合致するコンテキスト・イン
   プリメンテーションを備えた連合命名フレームワークを
   設けるステップと、 コンテキスト・ハンドル、コンポジット名、実行対象の
   指定された操作、およびその操作に必要な１つまたは複
   数の引数を備えた入力を供給クライアント・アプリケー
   ションが連合命名フレームワーク機構を呼び出すことを
   可能とするプロセスをもたらすステップと、 連合命名フレームワーク機構がコンテキスト・ハンドル
   を使用して、コンテキスト・ハンドルがポイントしたコ
   ンテキスト・インプリメンテーションをロードし、かつ
   どの連合命名サービス・プロバイダ・インタフェースを
   コンテキスト・インプリメンテーションがサポートして
   いるかを判定できるようにするプロセスをもたらすステ
   ップと、 コンテキスト・インプリメンテーションが呼び出された
   第１の操作の結果を返し、かつ連合命名フレームワーク
   機構に状況値を返すことができるようにするプロセスを
   もたらすステップと、 第１の操作が成功し、これによってコンポジット名を分
   解したか、あるいは継続できないかのいずれかを状況値
   が示している場合には、連合命名フレームワーク機構が
   第１の操作の結果をクライアント・アプリケーションに
   返すことができるようにするプロセスをもたらすステッ
   プと、 操作を継続すべきことを状況値が示している場合には、
   連合命名フレームワーク機構が返された状況情報に基づ
   いて、コンポジット名の残りに対する処理を継続できる
   ようにするプロセスをもたらすステップとを備えている
   オブジェクトのコンポジット名を分解する方法。