JP3839472B2 - オブジェクト指向ルール・ベース・プロトコル・システム - Google Patents
オブジェクト指向ルール・ベース・プロトコル・システム Download PDFInfo
- Publication number
- JP3839472B2 JP3839472B2 JP51672595A JP51672595A JP3839472B2 JP 3839472 B2 JP3839472 B2 JP 3839472B2 JP 51672595 A JP51672595 A JP 51672595A JP 51672595 A JP51672595 A JP 51672595A JP 3839472 B2 JP3839472 B2 JP 3839472B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- directory
- communication
- network
- network protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4553—Object oriented directories, e.g. common object request broker architecture [CORBA] name server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
Description
著作権表記
本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁に記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではない。その他の権利を一切所有することを明示に留保する。
発明の分野
本発明は一搬的には分散コンピュータ・ネットワークに関し、より具体的には分散ネットワーク・ディレクトリとネーミング・サービスに対するルール・ベース・プロトコル処理に関する。
発明の背景
パーソナル・コンピュータやミニ・コンピュータなどの、独立型でローカル化されたデータ処理デバイスによるデータ処理が急成長していることに伴って、データ・ネットワークは物理的に切り離されたデバイスを互いに結合し、ネットワークに接続された種々のデバイス間でディジタル通信を行なうことを可能にするまで発展している。
ネットワークには、ローカル・エリア・ネットワーク（local area network-ＬＡＮ）と広域ネットワーク（wide area network-ＷＡＮ）を含めて、数種類のものがある。ＬＡＮは限定エリア・ネットワークであり、ＬＡＮに接続されたデータ・デバイスは同一建物内に置かれているのが一般である。代表的なＬＡＮは同軸ケーブルや撚り対線（twisted pair）のように、種々のコンピュータ、サーバ、プリンタ、モデム、その他のディジタル・デバイスを互いに結合する伝送媒体から構成されている。これらのデバイスは「ノード」と総称され、各々はノードを一意的に識別するアドレスで伝送媒体に接続され、データをあるノードから別のノードへルート（route）するために使用されている。資源とサービスを提供するノードは「サーバ（server）」ノードと呼ばれ、これらの資源とサービスを利用するノードは「クライアント（client）」ノードと呼ばれている。ＷＡＮはもっと大きなエリアを取り囲んでいるのが一般で、電話回線などのコモン・キャリア接続を含んでいる場合もある。
Alok Sinha著「クライアント−サーバ・コンピューティング」（Client-Server Computing）という文献には、クライアント−サーバ・コンピューティング・テクノロジの一般的概念が開示されている。この文献では、基本的パラダイム、業界の見通し、テクノロジ、接続インタフェース、およびデータベース・インタフェースとグラフィカル・インタフェースを含む将来の可能性が議論されている。この文献はクライアント−サーバ・テクノロジの適度に詳しい概要書である。
C.Tschudin著「フレキシブル・プロトコル・スタック」（Flexible Protocol Stacks）という文献はフレキシブル・スタックの実現可能性について検討し、「プロトコル・スタックが動的に再構成されたとき起こる、いくつかの基本的問題を実験する」ためのテスト・システムを開示している。この文献は、「スタック構築手法を探すためにもっと研究が必要である」こと、およびもっとテストとデバッギングが必要であることを指摘している。この文献はフレキシブル・プロトコルの可能性を考慮しているが、他方では、「そのようなプロトコル環境が実現可能であるかどうかという問題が残っている」こと、および「現在の研究水準では、任意のプロトコル・スタックを取り扱うために必要な手法と、かかる環境を実現するために必要な手法の知識が不十分である」ことを認めている。最後に、この文献は、「そのような一般的プロトコル環境を有することを期待する前に、実行状態（running）のプロトコル・スタックの管理に関する理解がもっと必要である」と述べている。
ＬＡＮとＷＡＮは、様々な構成で互いに結合されて、異なる建物やロケーション間を結んでいる場合や、大陸全体に渡っている場合もある「エンタープライズ」ネットワークを構築することがよくある。エンタープライズ・ネットワークが便利である理由には、いくつかある。このネットワークは資源共用を可能にする。つまり、プログラム、データおよび機器は、資源とユーザの物理的ロケーション（所在）に関係なく、ネットワークに接続されたすべてのノードが利用できる。また、エンタープライズ・ネットワークでは、複数のデータ・ソースを重複して使用可能にしておくことにより信頼性も得られる。例えば、重要なデータ・ファイルは複数のストレージ（記憶）デバイスに複製しておくことができるので、例えば、機器障害が原因でファイルの１つが使用不能になっても、重複ファイルを使用することができる。
エンタープライズ・ネットワークの最も重要な特徴の１つは、ネットワークに接続されたユーザのすべてに大規模で、高度のサービス・セットを妥当なコストで提供できる能力をもっていることである。しかし、ユーザがネットワークの潜在能力を活用するためには、ユーザはネットワーク資源を識別し、そこに位置づけて、アクセスできなければならない。ネットワークが小規模のときは、使用できる資源に位置づけて、アクセスすることは比較的単純であるが、ネットワークは成長して大きくなり、現在では、非常に大規模なネットワークが多数存在する。何千のノードからなるネットワークは普通であり、何百万のノードからなるネットワークが出現する見通しもある。
大規模ネットワークの例として、INTERNET（インターネット）ネットワークがあるが、これは大きな公共機関や私企業で利用されている。この種のネットワークがもつ能力の多くは、ユーザが使用できる機能にユーザが気づいていないか、あるいは機能にアクセスする方法が困難であるか、紛らわしいという単純な理由で未使用のままになっている。その結果、ユーザがネットワーク資源に位置づけて、アクセスするのを容易にするために、多くの既存ネットワークは現在では、ユーザから資源識別子または資源名を受け取り、所望のネットワーク資源に対応するネットワーク・アドレスに位置づけるネットワーク・ディレクトリまたはネーミング・サービスを利用している。
例えば、入力される識別子または名前は「記述的」にすることができ、他の資源と区別できるだけの十分な属性を記述することにより資源を指定する。このような記述名はネットワークをサーチして、ある特定基準に一致する資源を探し出す人間のユーザにとっては非常に役立つが、これらの名前は最大のコンピューティング資源も必要とし、効率よく分散化することが困難である。現在、このような記述名サービスに関する標準がいくつか存在する。例えば、国際電信電話諮問委員会（Consultative Committee on Infomational Telephony and Telegraphy-ＣＣＩＴＴ）および国際標準化機構（International Standards Organization-ＩＳＯ）は、X.500と呼ばれる記述名サービスに関する規格を開発した。
ネーミングとディレクトリ・サービス（これらは以下「ディレクトリ・サービス」と総称することにする）は、現在種々の方法で実現されている。最も単純な実現方法では、名前および対応するネットワーク・アドレスのリストを収めておくために、ローカル・サーバ・ノードに置かれている単一の集中型データベースを使用している。このようなローカル化ディレクトリ・サービスの例は図１に示されている。図１は、複数のクライアント・ノード１０６，１０８，１２０，１２２，１２８よりなる「クライアント−サーバ」構成に配置されたコンピュータ・ネットワークを示している。これらのクライアント・ノードは、例えば、ワークステーション・パーソナル・コンピュータ、ミニコンピュータまたは他のコンピューティング・デバイスになっており、そこではアプリケーション・プログラムが実行され、リンク１０２，１１０，１１６，１２６，１３６を含む種々のネットワーク・リンクを通して相互に通信し、またノード１００，１１２，１２４，１３２，１３８などのサーバ・ノードと通信している。サーバ・ノードには、クライアント・ノードの全部または一部にサービスまたはサービス・セットを提供できる専用化ハードウェア・デバイスとソフトウェア・プログラムが置かれている。クライアント・ノードは、サーバ・ノードから提供される種々のネットワーク・サービスのユーザである。
代表例として、集中型ディレクトリ・サービス・データベース１０４は、ノード１００のような、サーバ・ノードの１つに置かれている。クライアント・ノード、例えば、クライアント・ノード１０８は、サーバ・ノード１００と接続し、資源識別子または資源名を入力し、関連サービスのネットワーク・アドレスを検索することによりディレクトリ・サービスにアクセスすることができる。従来のデータベース手法によると、クライアント・ノードはデータベース上をサーチして特定の資源に位置づけることが可能になっている。さらに、多くのディレクトリ・サービスは部分名記述、「ワイルドカード（wild card）」およびプレースホルダ（placeholder）を使用してブラウズ（browse）することをサポートしている。単一データベースによるこの種の集中型ディレクトリ・サービスは、ネットワーク・アドレスが少数である小規模ネットワークでは有効である。しかし、大規模ネットワークでは、すべての資源識別子を中央の一か所に置いておくことは事実上不可能である。さらに、単一データベースはネットワーク全体を使用不能にできる単一の障害ポイントを表わす。さらに、集中型データベースは貧弱なパフォーマンスという欠点をしばしばもつ。例えば、クライアント１０８のようなローカル・クライアントがサーバ１００と接続してデータベース１０４をアクセスすることは比較的効率的であるが、クライアント１２０のようなリモート・クライアントは、「ゲートウェイ」リンク１１６と共に、いくつかのサーバ１２４，１１２を経由してリンクしなければならないので、大量のネットワーク・オーバヘッドが発生し、システム全体のアクセス「コスト」が高くなる。リモート・アクセスの試みが多くなると、ディレクトリ・サービス・プロバイダはネットワーク全体にわたって直ちに処理ボトルネックと通信ボトルネックになってしまう。
上記問題を解消するために、データベース・データを複数のロケーションに分散化する別の従来手法が開発されている。このようなシステムが図２に概略図的に示されている。図２はクライアント・サーバ型のネットワークを示しているが、これは図１に示したものと似ている。具体的には、これらの２つの図で対応するエレメントは対応する参照符号が付いている。例えば、図１のクライアント１０８は図２のクライアント２０８と類似している。これらの２つのネットワークの違いは、ディレクトリ・サービス・データベースがいくつかのサーバ・ノードに重複して置かれていることである。例えば、サーバ・ノード２００には、サーバ・ノード２１２（データベース２１４）、サーバ・ノード２３２（データベース２３０）およびサーバ・ノード２２４（データベース２１８）と同じように、ディレクトリ・サービス・データベース２０４が置かれている。データを重複してデータベースの各々に置いておく従来方法はいくつか知られている。あるシステムでは、各資源識別子を個別的に重複して各データベースに置いている。他のシステムでは、データベース全体を重複している。さらに、他のシステムでは、個別的ノードを重複するか、あるいはデータベースをなんらかの方法で分割して重複を制限している。
図２に示す分散システムは、集中型データベースに関連する問題を防止している。データは重複されているので、障害ポイントは一か所でない。また、データは近くのサーバ・ノードで通常使用可能であるので、「リモート」クライアント・ノードというものがなく、ネットワーク・オーバヘッドが大幅に軽減されている。
しかるに、分散システムには独自の問題がある。例えば、複数のソースがデータベースを更新する可能性のあるときは、なんらかの方法を使用してデータ整合性（data consistency）を保証しなければならない。あるシステムでは、データ整合性を保つために、データのすべてのコピーが従来のデータベース・システムと同じように、緊密に同期を保つようにしている。他のシステムでは、従来の同時実行調停方式（concurrency arbitration scheme）を用いてデータ保全性（data integrity）を保証している。
このようなネーミングおよびディレクトリ・サービスは、同じアクセス方式とプロトコルがネットワーク全体にわたって適用されるような同種ネットワークでは効果的である。この場合には、整合性のある名前とルールのセットが開発されて、種々の資源の位置づけとアクセスを比較的容易にできる。しかし、多くの大規模ネットワークは異種ネットワークである。つまり、ネットワークは、ワーク・ステーション、パーソナル・コンピュータ、ミニコンピュータ、スーパコンピュータ、メインフレームといったように、多種類の異なるコンピュータを含んでいるだけでなく、ネットワーク自体は、「ゲートウェイ」と呼ばれるインタフェースを通して互いに結合された多数の独立型小規模ネットワークから構成されている。これらの小規模ネットワークは独自のアクセス方式とプロトコルをもっていることがある。さらに、これらの大規模ネットワークの異種構造と編成は、共通の方式とプロトコルを指図できる中央制御と管理には力を貸さない。
互いに結合された小規模ネットワーク群から構成された多数の大規模ネットワークでは、基礎となる個別ネットワークの各々は、特定のプロトコルを使用する独自の異なるディレクトリ・サービスをもっている。このタイプのネットワークでは、ユーザは各ネットワーク・ディレクトリ・サービス・プロトコルに精通している必要があり、サーチがあるネットワークから次のネットワークへ実行されるとき、あるプロトコルから別のプロトコルへ移る必要がある。その結果、このような異種ネットワークでは、ネットワーク資源をアクセスすることを困難にしている主要問題の１つは、詳細および、これらの個別ネットワークの各々にアクセスするときに関連するプロトコルにユーザがとらわれることなく、異種ネットワーク上で動作可能なネットワーク資源の整合性のあるグローバル・アクセス可能なディレクトリが欠如していることに起因している。
今日のネットワーキング・サービスは種々のプロトコル・システムをもっている。従来技術では、アプリケーションは、ネットワーキングのプロトコル・アーキテクチャに関する詳細情報を含んでいなければならなかった。この要件がアプリケーションを特定のプロトコルに結びつけていた。アプリケーションはソース・コードを変更しないとプロトコルの変更をサポートできないために、これはネットワークを動的に構成することを妨げていた。
以上に鑑みて、本発明の目的はアプリケーションがサービスのタイプと品質を指定できるようにすることである。
発明の概要
本発明の一実施例によれば、ルール・ベース・プロトコル選択メカニズムが該当のプロトコル構成をサービスのタイプと品質に基づいて選択することにより、上述した問題を解決し、上述した目的を達成している。各プロトコル・ファミリごとに、ルール・セットが定義され、サービスのタイプと品質を特定の共通プロトコル・セットに変換するようにしている。
【図面の簡単な説明】
本発明の上記およびその他の利点は、添付図面と関連して以下の説明を参照することによりもっと理解しやすくなる。添付図面において、
図１は、ローカル・ディレクトリ・サービスを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。
図２は、分散ディレクトリ・サーバを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。
図３は、ルール・ベース・プロトコル選択メカニズムが動作しているコンピュータ・システム、例えば、パーソナル・コンピュータ・システムを示す概略ブロック図である。
図４は、ルール・ベース・プロトコル選択メカニズムを取り入れているクライアント・サーバ・ネットワークを示す概略ブロック図である。
図５は、国際標準化機構の７層モデルに準拠して２ノード構造間でデータを伝送するために使用される従来のプロトコル・スタックの詳細を示す概略ブロック図である。
図６は、通信ディレクトリ・サービスの主要コンポーネントを示す概略図である。
図７は、種々のディレクトリ・サービスと他のネットワーク・サービス上でブラウズを可能にするディレクトリ・ツリーのセットアップ例を示す概略図である。
図８はサーバ・ノードの主要コンポーネントを示す概略ブロック図であり、サービス・プログラムが通信ディレクトリ・サービスとやりとりする様子を示している。
図９は、新サービスをネットワーク上で使用可能にするときに伴うステップを示す簡略フローチャートである。
図１０は、サービス・オブジェクトをアクチベートするためにサービス・プログラムによって実行されるステップを示す展開されたフローチャートである。
図１１は、クライアント・ノードの主要コンポーネントを示す概略図であり、アプリケーション・プログラムが通信ディレクトリ・サービスとやりとりしてサービスをアクセスする様子を示している。
図１２は、ネットワーク上で使用可能なサービスをアクセスするときに伴うステップを示す簡略フローチャートである。
実施例の詳細な説明
本発明は、好ましくは、ＩＢＭ（登録商標）PS/2（登録商標）またはアップル（登録商標）マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータに常駐したオペレーティング・システムを背景に実施される。図３は代表的なハードウェア環境を示しもので、本発明によるコンピュータ３００の代表的なハードウェア構成を示していてる。コンピュータ３００は中央処理ユニット３０２によって制御されるが、このユニットは従来のマイクロプロセッサにすることが可能である。いくつかの他のユニットはすべてがシステム・バス３０８を介して相互に接続され、特定のタスクを成し遂げるために用意されている。特定のコンピュータは、図３に示すユニットの一部だけを備えていたり、図示していない付加的な構成要素を含んでいたりする場合があるが、大部分のコンピュータは、少なくとも図示のユニットを含んでいる。
具体的には、図３に示すコンピュータ３００は、情報の一時記憶域のためのランダム・アクセス・メモリ（ＲＡＭ）３０６、コンピュータの構成と基本的操作コマンドの永久記憶装置のためのリードオンリ・メモリ（ＲＯＭ）３０４、およびディスク・ユニット３１３やプリンタ３１４などの周辺デバイスを、それぞれケーブル３１５と３１２でバス３０８に接続するための入出力（Ｉ／Ｏ）アダプタ３１０を含んでいる。ユーザ・インタフェース・アダプタ３１６も提供されているが、これはキーボード３２０などの入力デバイス、およびマウスやスピーカ、マイクロホンを含む他の公知インタフェース・デバイスをバス３０８に接続するためのものである。ビジュアル出力は、バス３０８をビデオ・モニタなどのディスプレイ・デバイス３２２に接続しているディスプレイ・アダプタ３１８から提供される。ワークステーションは、常駐のアップル・システム／７（登録商標）オペレーティング・システムなどのオペレーティング・システムを有し、それにより制御と調整をされている。
好適実施例では、本発明は、オブジェクト指向プログラミング技法を用いてＣ++プログラミング言語で実現されている。Ｃ++はコンパイル型言語である。つまり、プログラムは人間が読むことのできるスクリプト（script）で書かれ、このスクリプトはコンパイラと呼ばれる別のプログラムに渡される。コンパイラはマシン可読（machine-readable）の数値コードを生成し、このコードはコンピュータにロードされ、コンピュータによって直接に実行される。以下で説明するように、Ｃ++言語はいくつかの特徴をもっている。これらの特徴によると、ソフトウェア開発者は他の人が書いたプログラムを容易に使用できると共に、プログラム再使用の管理を強化してプログラムの破壊や誤った使い方を防止することができる。Ｃ++言語は周知であり、この言語を詳しく説明した論文や文献は多数利用可能である。さらに、Ｃ++コンパイラは、Borland Internationa1,Inc.、Microsoft Corporationなどの数社から市販されている。そのために、混乱を避けるために、ここでは、Ｃ++言語の詳細とＣ++コンパイラの操作について詳しく説明することはしないことにする。
この分野に精通した当業者ならば理解されるように、オブジェクト指向プログラミング（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-80MVC(ParcPlace)などがある。
アプリケーション・フレームワークによる解決手法では、カプセル化、多様性、および継承のすべての原理をオブジェクト層に利用し、他のプログラミング技法を大幅に改善しているが、いくつかの困難な問題も起こっている。これらの困難な問題は、開発者が自身のオブジェクトを再使用することは容易であるが、他のプログラムによって生成されたオブジェクトを開発者が使用することが困難であることから起こっている。さらに、アプリケーション・フレームワークはモノリシック（monolithic）・オペレーティング・システムに上乗せされた１つまたは２つ以上のオブジェクト「層」から構成されているのが一般であり、オブジェクト層に柔軟性がある場合であっても、面倒な手続型コール（procedural call）を通して、基礎となるオペレーティング・システムと直接にやりとりする必要がしばしば起こっている。
アプリケーション・フレームワークがアプリケーション・プログラム用のプレハブ機能を開発者のために用意しているのと同じように、好適実施例に含まれているようなシステム・フレームワークは、開発者が変更またはオーバライドすることによりカスマイズした解決手法を作成できるシステム・レベルのサービス用のプレハブ機能を提供することができ、従来のアプリケーション・フレームワーク・プログラムで必要であった面倒な手続型コールを避けることができる。例えば、アプリケーション・プログラムによって生成された印刷可能情報の、自動ページ付け、プリプリント処理およびページ構成の土台を提供できる印刷フレームワークについて考えてみることにする。アプリケーション・ソフトウェア開発者がこれらの機能を必要とするときは、通常は、その機能を提供するための特定のルーチンを書く必要があった。これをフレームワークを使用して行う場合は、開発者は最終的出力の特性と動作を用意するだけでよいのに対し、フレームワークは、これらのタスクを実行する実際のルーチンを提供する。
好適実施例では、フレームワークの概念を取り入れ、アプリケーションとオペレーティング・システムを含むシステム全体にこの概念を適用している。商業ベースまたは企業の開発者、システム・インテグレータ、またはＯＥＭにとっては、このことは、MacAppなどのフレームワークに関して上述した利点のすべてが、テキストやユーザ・インタフェースなどの事物についてアプリケーション・レベルにおいてのみならず、プリント、フラフィックス、マルチメディア、ファイル・システム、入出力（Ｉ／Ｏ）、テストなどのサービスについてはシステム・レベルでも挺入れできることを意味する。
図４は、図１と図２に示すクライアント−サーバ・ネットワークにおいて、通信ディレクトリ・サービスが提供されているものを示す概略図である。図２と図４を比較すると分かるように、全体的ネットワーク構成はどちらのネットワークの場合も同じであるが、通信ディレクトリ・サービスが図４に示すように使用されるときは、ノードはすべてが通信ディレクトリ・サービス（ＣＤＳ）モジュールを含んでいる。具体的には、サーバ・ノード４００，４１２，４２４，４３２，４３８は、それぞれ通信ディレクトリ・サービス・モジュール４０５，４１３，４２５，４３０，４３９を含んでいる。さらに、サーバ・ノードはいずれかが、あるいはすべてが従来のディレクトリ・サービス４０４，４１４，４１８，４３０をそれぞれ含むことも可能である。従来のディレクトリ・サービスは、通信ディレクトリ・サービスと区別するために、以下では物理ディレクトリ・サービスと呼ぶことにする。
サーバ・ノードに加えて、クライアント・ノード４０６，４０８，４２０，４２２，４２８（それぞれＣＤＳ４０７，４０９，４２１，４２３，４２９）の各々も、通信ディレクトリ・サービスを含んでいる。以下で詳しく説明するように、図４に示すようなエンタープライズ・ネットワークでは、あるノードから別のノードへ送られる情報は、一般に離散的メッセージまたは「パケット」に分割され、これらのパケットは事前定義のプロトコルに従ってノード間で伝送される。ここで言う「プロトコル」とは、別々のノードがどのようにサポートされて、相互にやりとりするかを定義したルール（規則）またはプロシージャ（手順）の集まりからなっているものである。
設計の複雑さを軽減するために、大部分のネットワークは一連の「層」または「レベル」で編成されるので、あるノードから別のノードへ渡される情報が層から層へ伝送されるようになっている。各層内では、あらかじめ定義したサービスまたはオペレーションが実行され、層はあらかじめ定義されたプロトコルに従って相互に通信し合っている。層化的な設計の目的は、ある層が、標準化インタフェースを通して他の層へ選択されたサービスを提供することを可能にすると共に、ある層内の実際のインプリメンテーション（実装）の詳細が他の層から見えないようにすることである。以下で詳しく説明するように、クライアント・ノードとサーバ・ノードはどちらも、通信ディレクトリ・サービス・モジュールと共同作用してネットワーク層を構成し、ネットワーク層の方は、クライアントとサーバ間の接続のタイプとパラメータを、提供されるサービスのタイプに従って制御する。
ネットワーク・アーキテクチャ（ネットワークで使用される層とプロトコルの集まりの全体名）を標準化する試みとして、一般化されたモデルが国際標準化機構（ＩＳＯ）によって提案されているが、これは現在使用されている種々のプロトコルを国際的に標準化する第一歩となるものである。このモデルは、開放型システム間相互接続（open sytems interconnection-ＯＳＩ）参照モデルと呼ばれているが、これは他のシステムとの通信用に「開放」されているシステムの相互接続を扱っているためである。提案されたＯＳＩモデル案は７層からなり、（相互に作用し合う順に）「物理」層、「データリンク」層、「ネットワーク」層、「トランスポート」層、「セッション」層、「プレゼンテーション」層、「アプリケーション」層と名づけられている。ＯＳＩモデルの目的は、各層内で処理されるプロセスを標準化することである。
ＯＳＩモデルによれば、物理層で実行されるプロセスは、未処理（raw）データ・ビットの通信チャネル上の伝送を扱っている。データ・リンク層で実行されるプロセスは未処理データ・ビット・ストリームを操作し、それを見かけ上伝送エラーのないデータ・ストリームに変換する。後者のタスクは伝送データをデータ・フレームに分割し、そのあとにエラーを検出または訂正するエラー訂正メカニズムを付けてフレームを順次に伝送することにより行われる。
ネットワーク層プロセスは、データ・パケットをデータ・ソースからデータ・デスティネーションへどのようにルートする（route）かを、ネットワークを通る多数の代替経路から１つを選択することにより判断する。トランスポート層プロセスの機能は、セッション層からデータ・ストリームを受け取り、それをもっと小さな単位に分割し（必要な場合）、その小さな単位をネットワーク層へ渡し、順序エラー、重複または紛失データなしで、デスティネーションに正しくすべて到着したことを保証する適当なメカニズムを提供することである。
セッション層プロセスは、異なるマシンにいるユーザが相互間で「セッション」または「会話（dialogue）」を確立することを可能にする。セッションは通信し合うノード間で通常データのトランスポートを可能にするが、ある種のアプリケーションでは、会話制御、トークン管理と同期化などの機能強化サービスも提供する。プレゼンテーション層は要求頻度の高いある種の共通機能を実行して、例えば、データを標準フォーマットへのコード化、暗号化と解読の実行、その他の機能の実行といった、一般的解決法を見つけることを保証する。最後に、アプリケーション・プロトコル層は、データベース・アクセス、ファイル転送などの、共通に必要になる種々のプロトコルを含んでいる。
例えば、図５は、ＯＳＩ標準の７層アーキテクチャに準拠して２つのノード間を接続するために使用される従来技術のプロコトル・スタックを示す図である。ＯＳＩ標準によれば、ノードの各プロトコル・スタックは７層からなっている。例えば、クライアント・ノード４０８のスタック５２８は、アプリケーション層５００、プレゼンテーション層５０２、セッション層５０４、トランスポート層５０６、ネットワーク層５０８、データリンク層５１０および物理層５１２からなっている。これらの層の各々のオペレーションと目的は前述した通りである。同様に、サーバ・ノード４３２のスタック５３２は層５１４〜５２６からなっている。実際のデータ通信は２つの物理層５１２と５２６間でデータ・リンク５３０を通して行われるが、スタックが図５に示すような配置になっているときは、各層は、ある層と同じレベルにある層である「ピア（peer）」と通信していると考えることができる。例えば、アプリケーション層５００と５１４は、情報が層５０２〜５１２のすべてを通過し、データ・リンク５３０を経由し、層５１６〜５２６を通って戻る場合でも、直接に通信していると考えることができる。同様に、プレゼンテーション層５０２と５１６はピアツーピア（peer-to-peer）で通信することができる。
図５に示すようなプロトコル・スタックは、複数のデータ・バッファを使用して実現されているのが代表的である。各データ・バッファは、そこで処理が行われるプロトコル層を構成している。ある層で処理が完了したあと、データを別のバッファへ転送して、別の層に従ってさらに別の処理を行うことができる。
本発明がもつ一側面によれば、ネットワーク内でピアツーピア通信を制御するプロトコル・スタックは、通信ディレクトリ・サービスにストアされたスタック定義によって構成される。これらのスタック定義は、ネットワークで使用できる各サービス・タイプと関連づけることできるので、アプリケーション・プログラムからのサービス要求に応答してプロトコル・スタックを動的に構成することができるようになっている。
通信ディレクトリ・サービスの詳細図は図６に示されている。モジュールは３つの主要コンポーネントからなっている。ネットワークから提供される物理ディレクトリ・サービスと他のサービスの各々を、従来のツリー探索手法を用いて位置づけることを可能にする階層ディレクトリ・ツリー６０２と、クライアントがあらかじめ指定した通信リンク上にリモート・サーバ・ノードからのデータを要求できるようにする動的再構成可能スタックをプログラミングするために使用されるスタック定義オブジェクトの集まり６０４と、「サービス・オブジェクト」の集まり６０６とである。各サービス・オブジェクトは、ネットワーク上で使用できる１つのサービスと関連づけられ、そのサービスが使用可能なネットワーク・アドレスまたは交換アドレスと、スタック定義オブジェクト６０４の１つまたは２つ以上へのリファレンス（参照）６０８とを含んでいる。以下で詳しく説明するように、これらのサービス・オブジェクトの１つへのリファレンスは、対応するサービスへのアクセスを望んでいるアプリケーション・プログラムによって取得される。このリファレンスで識別されたオブジェクトにおける情報は、通信経路をセットアップするために再構成可能スタックへ送られる。
スタック定義６０４の各々は、各層で実行される処理と層間の相互作用を指定している層定義の集まりからなっている。スタック定義は、通信リンクがネットワーク・システムにインストールされるときに定義される。具体的には、スタック定義はシステム上の異種通信リンクごとに用意される。
通信ディレクトリ・サービス６００には、ネットワーク上のユーザにとってそのオペレーションを特に便利なものにする特徴がほかにもいくつかある。具体的には、ディレクトリ・サービスは使用可能なサービスとディレクトリ・サービスに関する情報を、一連のオブジェクトとしてディレクトリ・ツリーにストアする。さらに、通信ディレクトリ・サービス内のストアされたライブラリはオブジェクトを含んでいるので、アプリケーション・プログラムとサービス・プログラムは共に、オブジェクトを通して通信ディレクトリ・サービスと直接に通信することができる。通信ディレクトリ・サービスはノードの各々に存在するので、クライアントはどのディレクトリ・サービス・サーバともディレクトリ・サービスを使用する前に接続する必要はない。そのかわりオブジェクト自体がインタフェースとなるからである。さらに、サービス・オブジェクト６０６のような、あらかじめ定義されたオブジェクトの使用は、アプリケーション・プログラムが所望するサービスとの通信をオープンすることができる簡単な方法を提供する。アプリケーション・プログラムが実際の経路構造の詳細について気にする必要なしに、サービス・オブジェクトはネットワーキング・サービスへ直接に送られて通信経路をオープンできる。さらに、既存の物理ディレクトリ・サービスはいずれも、ディレクトリ・ツリー６０２のノード・オブジェクトにカプセル化されているので、物理ディレクトリ・サービスはクライアント・アプリケーションから完全に隠蔽され、クライアント・アプリケーションは、整合性のあるプロトコルとフィーチャ・セット（feature set）を使用して通信ディレクトリ・サービスと相互作用することができる。
通信ディレクトリ・サービスに見られるディレクトリ・ツリー６０２の詳細図は図７に示されている。以下で詳しく説明するように、ディレクトリ・ツリーは単純なサーチ（探索）コマンドを使用して走査することができ、完全なブラウズ機能はワイルド・カードとプレースホルダを使用により得られる。ディレクトリ・ツリーは、サーチの結果としてオブジェクトが返され、返されたオプジェクトのタイプがオブジェクトを返したディレクトリ部分のインプリメンテーションによって決定されるように設計されている。ディレクトリ・ツリーのサーチから返されるオブジェクトの例としては、リモート・サービスと接続するために使用される情報を含んでいる、図６に示すサービス・オブジェクト６０６へのリファレンス、ユーザに関するセキュリティと認証情報を含んでいるプリンシプル（principle）オブジェクト、ユーザに関する情報のコレクションを含んでいる「ビジネスカード」およびプログラム開発者がディレクトリ・ツリーに追加できる他のクラスがある。ディレクトリ・ツリーは、図７に示すような単一階層ツリーの編成になっている。なお、図７に示すツリー構成は単なる例示であり、本発明の範囲と原理から逸脱することなく実際のツリー構成は図示の構成と大幅に異なることがある。ツリー内のノードの各々は"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 ７０２のような中間namespaceを、ルートnamespace ７００とリーフ・ノード７０４〜７１０との間に挿入することが可能である。中間namespaceは他のnamespaceを参照している。前述したように、本発明の通信ディレクトリ・サービスはサービス・プログラムとアプリケーション・プログラムの両方と相互作用して、クライアントとサーバとの間で必要な通信リンクを透過的に（transparently）セットアップする。この相互作用では、サービス提供者による通信ディレクトリ・サービスにおけるサービス・オブジェクトの生成と、サーバ・ノードにおけるプロトコル・スタックの構成を含む。サービスのアクセスを所望するクライアントは関連サービス・オブジェクトを検索し、それを使用してプロトコル・スタックをクライアント・ノードに構成して通信リンクをセットアップする。図８〜図１０は、サーバ・ノードで稼働しているサービス・プログラムによって実行されて、クライアント・ノードで実行されているアプリケーション・プログラムにより使用できるように新しいサービスをネットワーク上で使用可能にするオペレーションを説明したものである。図８は、新サービスの生成とアクチベーションに含まれるサーバ・ノード・プログラムの部分を示す概略ブロック図である。図９は、サービス・プログラム、通信ディレクトリ・サービスおよびノード・ネットワーキング・サービスの間で相互作用して、新サービスを確立し、適当な通信リンク上で動作するようにネットワーキング・サービスを構成する手順を示したフローチャートである。図１０は、関連サービス・ブロックをアクチベートすることによって新サービスをアクチベートする様子を示す詳細ブロック図である。もっと具体的に説明すると、図８は、サービスをリモート・クライアントに提供するときのサーバ・ノードの基本的構成を示している。サーバ・ノードは共通エリア、または、システム・アドレス空間８００をもつ構成になっており、このアドレス空間には、オペレーティング・システム・プログラムと、システムで実行されるサービス・アプリケーションによって使用される種々の共有ライブラリが置かれている。具体的には、システム・アドレス空間８００には、通信ディレクトリ・サービス８０４およびネットワーキング・サービス・プログラムとライブラリ８１６が含まれている。サーバ・ノードには、独自のアドレス空間８１０で実行されるサービス・プログラムも置かれている。以下で説明するように、サービス・プログラム８０６は通信ディレクトリ・サービス８０４と相互作用してサービス・オブジェクトを作成し、これは通信ディレクトリ・サービス８０４に置かれる。このサービス・オブジェクトはこのシステム内の他のノードすべてに分散（distribute）されるので、ネットワーク上のクライアントのすべてに対してローカル・ベースでの使用ができる。サービス・オブジェクトはネットワーキング・サービス８１６を構成するための適当なスタック定義を含んでいるので、アプリケーション・プログラムは通信ディレクトリ・サービスと共に、以前にストアした定義を用いて構築の詳細においてクライアント・アプリケーション・プログラムの必要なしに、通信経路をセットアップすることができる。
図９を参照して説明すると、新サービスの生成はステップ９００からスタートして、ステップ９０２へ進む。ステップ９０２で、サービス・プログラムの開発者は、新サービスに適当な構成パラメータを含んでいる新サービス・オブジェクトの生成を動作可能にする。これは、ディレクトリ・サービスに置かれているサービス・オブジェクト・クラスをサブクラス化することにより行うことができる。具体的には、新サービス・オブジェクト・クラスを生成するために、サービス・プログラム開発者はそのサービスの一意的な名前（unique name）、サービスのタイプ、およびオプションとして、サービスをアクセスするとき使用できる種々の通信リンク・タイプを指定する。通常のオブジェクト指向プログラミング言語のオペレーションによれば、このサブクラス化情報はコンパイル時にサービス・プログラム・コードに含まれる。従って、サービス・プログラム８０６が適当なサーバ・ノードのサービス・プログラム・アドレス空間８１０にインストールされているときは、サービス・オブジェクト・サブクラスの構築子（constructor）は、コールされて、ステップ９０４（図９）に示すようにサービス・オブジェクトを通信ディレクトリ・サービス８０４に構築することができる。構築子をコールする過程で、サービス情報のタイプと品質は、図中に矢印８０２で示すように通信ディレクトリ・サービスに渡される。
前述したように、通信ディレクトリ・サービス８０４は、共用ライブラリに置かれているスタック定義の集まりを含んでいる。これらのスタック定義は、通信リンクが定義され、特定のトランスポート・メカニズムと関連づけられる時に生成される。スタック定義はそれぞれ層定義の集まりからなっている。層定義は、各層におけるデータの処理と層間の相互作用を制御する。各スタック定義は、トランスポート層から物理層までのスタックを完全に定義している（これらの層の詳細は上述した通りである）。
新サービス・オブジェクトを作成する過程で、通信ディレクトリ・サービス８０４はサービス・プログラムから提供れたサービス情報のタイプと品質を使用してセッション層を構築し、ストアされた通信スタック定義を参照する適当なリファレンスを、ステップ９０６に示すように含む。
新サービスをアクセスするために２つ以上の通信リンクが使用できるときは、適当なスタック定義が新サービス・オブジェクトの中で参照され、セッション層が構築されて、必要とするサービスのタイプと品質や通信リンクの可用性などの種々の基準に基づいて通信リンクの１つが選択される。
以上のように、新しく作成されたサービス・オブジェクトはセッション層と、トランスポート層から物理層までのスタックを定義している適当なスタック定義を含んでいる。このサービス・オブジェクトは通信ディレクトリ・サービスにストアされる。なお、この時点では、どのサービス・アドレスまたは交換アドレスもサービス・オブジェクトに提供されていない。これはサービス・オブジェクトが生成されても、アクティブでないからである。従って、サービス・オブジェクトは、サービス・プログラムがサーバ・ノードにインストールされているときはいつでも生成できるが、サービス・プログラムは下述する以降のステップがとられるまでアクチベートされない。
もっと具体的に説明すると、新サービスをアクチベートするために、サービス・プログラムは、ステップ９０８に説明されているように、ストアされたサービス・オブジェクトをネットワーキング・サービス８１６内の動的再構築可能スタック（ＤＲＰＳ）８２２へ送るように通信ディレクトリ・サービス８０４に指示する。サービス・オブジェクトがどのようにＤＲＰＳへ転送されるかは図８に示されている。具体的には、サービス・プログラム８０６は、まず、サービス・プログラム・インタフェース８２８を独自のアドレス空間８１０に生成する。サービス・プログラムとサービス・プログラム・インタフェースとの間の通信は図中に矢印８０８で示されている。サービス・プログラム・インタフェース８２８の方は構成データ・ストリーム８１４を生成し、これは、ネットワーキング・サービス８１６に常時使用できるように置かれているサーバ・インタフェース８１８へデータをストリーム化して送ることができる。
次に、サービス・プログラム８０６は、ネットワーク構成データを含んでいるサービス・オブジェクトを検索する。この構成データは、矢印８１２で示すように通信ディレクトリ・サービスからサービス・プログラム・インタフェース８２８へ渡される。そのあと、構成データは矢印８１４で示すように、ストリーム化されてシステム・アドレス空間８００へ送られる。
次に、ステップ９１０に示すように、サービス・プログラムがサービス・オブジェクトをアクチベートすると、サービス交換アドレスが通信ディレクトリ・サービス８０４に戻される。アクチベーション・シーケンスの詳細は図１０に示すフロー・チャートに示されている。具体的には、アクチベーション・シーケンスはステップ１０００からスタートし、ステップ１００２へ進む。ステップ１００２で、通信ディレクトリ・サービス８０４は、そのサービスが適当なものであれば、基礎となる物理ディレクトリ・サービス上のサービスをパブリッシュすることよりサービスを使用可能にする。このパブリケーションはサービスの名前を、ある場合には、サービス・アドレスを基礎となるディレクトリ・サービスに登録することからなる。
次に、ルーチンはステップ１００４へ進み、そこでサービスが通信ディレクトリ・サービスに登録される。前述したように、この登録はサービス・オブジェクトをストリーム化して、通信ディレクトリ・サービスのネーティブnamespaceノードに入れることを含む。この時点で、サービスへのリファレンスがＣＤＳディレクトリ・ツリーに追加されるので、サービスはユーザがツリーを走査することにより位置づけられることができる。
次に、ステップ１００６において、サービス・プログラム８０６からネットワーキング・サービス８１６内のサーバ・インタフェース８１８に渡されたスタック定義リファレンスは、ＤＲＰＳ８２２を再構成するときに使用されるスタック定義をセットアップするために使用される。ステップ１００８で、生成されたスタック定義はＤＲＰＳに渡される（このオペレーションは図中に矢印８２０で示されている）。この時点で、サービス・オブジェクト内の情報はセッション層８２３をセットアップするためにも使用される。
ステップ１０１０において、ＤＲＰＳ８２２内のセッション層８２３の交換アドレス、またはネットワーク・アドレスは、通信ディレクトリ・サービス８０４に返される。具体的には、ネットワーキング・サービス８１６は、セッション層のセットアップ時にセッション層アドレスをＤＲＰＳ８２２から得る。このアドレスはサービス・インタフェース８１８を経由し、構成データストリーム８１４を通してサービス・プログラム・インタフェース８２８へ返される。最後に、交換アドレスがデータストリーム８１２を通して通信ディレクトリ・サービス８０４へ返される。この交換アドレスは、前述したように、通信ディレクトリ・サービス８０４に置かれている関連サービス・オブジェクトにストアされるので、あとでクライアント・プログラムにより検索されるようになっている。この時点で、アクチベーションは完了し、図１０に示すアクチベーション・ルーチンはステップ１０１２で終了する。ステップ９１２で、交換アドレスは通信ディレクトリ・サービスに返され、サービス・アクチベーション・ルーチンはステップ９１４で終了する。
別のデータストリームもこの時点でサービス・プログラムによってセットアップされるので、そのあとで、クライアント・ノードがサーバ・ノードからのサービス要求したとき、入来するサービス要求を受け取ることができる。具体的には、物理通信リンク８２４経由で到着したサービス要求データは、セッション層８２３をサービス・プログラム・インタフェース８２８にリンクしている別の要求データ・ストリーム８２６を通して、構成されたＤＲＰＳ８２２へ渡されるサービス・プログラム・インタフェース８２８の方は要求をデータストリーム８０８を通してサービス・プログラム８０６へ転送（forward）する。応答情報はサービス・プログラム８０６により、データ・ストリーム８０８、サービス・プログラム・インタフェース８２８、要求データストリーム８２６、ＤＲＰＳ、８２２、および物理通信リンク８２４を経由してクライアント・ノードへ返される。
新しいサービスがローカル通信ディレクトリ・サービスに追加されたあと、多のノードに置かれているコピーを更新しなければならない。この更新は従来と同じように行われる。例えば、取外し可能ディスク上のコピーをすべてのノードに定期的に分散することも可能である。しかし、通信ディレクトリ・サービスのコピーを分散するもっと好ましい方法は、更新を受け取ったローカル・ノードがその更新情報を他のすべてのノードにブロードキャスト（同報通信）することである。このブロードキャストを成し遂げるために、ブロードキャスト・メッセージは、プロトコル・スタックのすべてをあらかじめ定められたデフォルト・プロトコルにセットさせる特殊なヘッダを含んでいる。このようにすると、ブロードキャスト・メッセージはすべてのノードで受信されることが可能になる。
図１１から図１３までは、クライアント・アプリケーションが通信ディレクトリ・サービスと協調してリモート・サービスをアクセスするとき必要になるステップを示している。具体的には、図１１はリモート・サービスをアクセスするときに必要となるクライアント・ノードの適当なセクションを示している。サーバ・ノード側と同じように、クライアント・ノードにはシステム・アドレス空間１１１０があり、このアドレス空間には通信ディレクトリ・サービス１１１２とネットワーキング・サービス１１１８が含まれている。アプリケーション・プログラム１１００は、独自のアプリケーション・アドレス空間１１０４で実行する。アプリケーション・プログラム１１００、ディレクトリ・サービス１１１２およびネットワーキング・サービス１１１８の相互作用は、図１２と図３に示すフローチャートに詳しく説明されている。
具体的に説明すると、クライアント・サービス・アクセス・ルーチンはステップ１２００からスタートし、ステップ１２０２へ進む。ステップ１２０２に示すように、クライアントは通信ディレクトリ・サービスと相互作用して、通信ディレクトリ・サービスにストアされたサービス・オブジェクトの１つへのリファレンスを受け取る。この相互作用は図１１に矢印１１０６で示されている。前述したように、この相互作用には、通信ディレクトリ・サービス１１１２に置かれたディレクトリ・ツリー上をユーザがサーチするときは、ユーザを直接に必要とすることがある。あるいはまた、この相互作用は、介入するアプリケーション・プログラムを必要とし、通信ディレクトリ・サービスと共同作用して例えば、ドキュメント・アイコンをサービス・アイコン上にドラッグするといったように、目に見える形でサービスを選択する場合もある。
いずれの場合も、ステップ１２０４に従い、通信ディレクトリ・サービス１１１２で識別されたサービス・オブジェクトへのリファレンスが、矢印１１０８に示すようにアプリケーション・プログラム１１００へ返される。これを受けて、アプリケーション・プログラムは、構成データをネットワーク・サービス１１１８へ送る準備としてクライアント・インタフェース・オブジェクト１１２６を生成する。サービス・オブジェクト・リファレンスは、通信ディレクトリ・サービス１１１２により構成データ・ストリーム１１１４を通してクライアント・インタフェース１１２６へ渡される。クライアント・インタフェース１１２６からは、構成データは構成データ・ストリーム１１１６上でストリーム化されて、ネットワーキング・サービス１１１８に置かれたサーバ・インタフェース・オブジェクト１１２０へ送られる。サービス・インタフェース・オブジェクト１１２０は、システム・ブートアップ時にネットワーキング・サービス１１１８が作成されるとき作成され、ネットワーキング・サービスに永続的に常駐する。
ステップ１２０６に従い、アプリケーション・プログラム１１００はサービス・オブジェクト・リファレンスをアクチベートする。図１３は、サービス・オブジェクト・リファレンスをアクチベートするときのステップを示す詳細図である。具体的には、アクチベーション・ルーチンはステップ１３００からスタートし、ステップ１３０２へ進む。ステップ１３０２において、サービス・オブジェクト・リファレンスは、適当であれば、基礎となる物理ディレクトリ・サービスのどれかで解決される。この解決は、サービス・オブジェクトに置かれたサービス名を使用して基礎となるディレクトリ・サービス上をサーチし、ネットワーク・アドレスを得ることにより行われる。あるいはまた、サービス・リファレンスが通信ディレクトリ・サービス１１１２のネーティブnamespaceに登録されていれば、サービス・アドレスまたはサービス交換はサービス・オブジェクト・リファレンスから直接に得ることができる。
ステップ１３０４において、サービス・オブジェクトに含められたスタック定義は、サービス・インターフェース１１２０とネットワーキング・サービス１１１８によって使用され、ＤＲＰＳ１１２４を構成するようにプロトコル・スタック層がセットアップされる。次に、ステップ１３０６で、生成されたスタック定義は矢印１１２２で示すようにＤＲＰＳに渡される。これらのスタック定義は、要求と応答データをアプリケーション・プログラム１１００とリモート・サービス（図１１には示されていない）との間で送る準備として、ＤＲＰＳ１１２４をセットアップし、通信リンクを構成する。
次に、ステップ１３０８において、ＤＲＰＳ１１２４内のセッション層１１２３のアドレスはサーバ・インタフェース１１２０に返される。そのあと、アクチベーション・ルーチンはステップ１３１０で終了する。図１２のステップ１２０８へ戻り、サーバ・インタフェース１１２０は、セッション層１１２３のアドレスを、サービス・オブジェクト・レファレンスから得たリモート・サービス交換と入れ替えて、リモート・サービス交換（ステップ１２０８に示すように）を、構成データ・ストリーム１１１６、クライアント・インタフェース１１２６およびデータ・バス（data path）１１０２を経由してアプリケーション・プログラム１１００に返す。このように、アプリケーション・プログラムはリモート・サービスと通信するときは、通信ディレクトリ・サービスからネットワーキング・サービスへ渡されたリモート・サービス・アドレスを使用する。
ステップ１２１０に示すように、サービス要求をアプリケーション・プログラム１１００からリモート・サービスへ送るように、別のデータ・パスがセットアップされる。この別のデータ・パスは、データ・パス１１０２、クライアント・インタフェース１１２６およびＤＲＰＳ１１２４のセッション層１１２３を含んでいる。ステップ１２１２に従って、要求情報は物理通信リンク１１３０を経由してリモート・サービス・ロケーションへ送出される。応答情報は、ＤＲＰＳ１１２４、データ・ストリーム１１２８、クライアント・インタフェース１１２６およびデータ・パス１１０２を経由してアプリケーション・プログラム１１００に返される。そのあと、サービス要求ルーチンはステップ１２１４で終了する。
本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁に記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではない。その他の権利を一切所有することを明示に留保する。
発明の分野
本発明は一搬的には分散コンピュータ・ネットワークに関し、より具体的には分散ネットワーク・ディレクトリとネーミング・サービスに対するルール・ベース・プロトコル処理に関する。
発明の背景
パーソナル・コンピュータやミニ・コンピュータなどの、独立型でローカル化されたデータ処理デバイスによるデータ処理が急成長していることに伴って、データ・ネットワークは物理的に切り離されたデバイスを互いに結合し、ネットワークに接続された種々のデバイス間でディジタル通信を行なうことを可能にするまで発展している。
ネットワークには、ローカル・エリア・ネットワーク（local area network-ＬＡＮ）と広域ネットワーク（wide area network-ＷＡＮ）を含めて、数種類のものがある。ＬＡＮは限定エリア・ネットワークであり、ＬＡＮに接続されたデータ・デバイスは同一建物内に置かれているのが一般である。代表的なＬＡＮは同軸ケーブルや撚り対線（twisted pair）のように、種々のコンピュータ、サーバ、プリンタ、モデム、その他のディジタル・デバイスを互いに結合する伝送媒体から構成されている。これらのデバイスは「ノード」と総称され、各々はノードを一意的に識別するアドレスで伝送媒体に接続され、データをあるノードから別のノードへルート（route）するために使用されている。資源とサービスを提供するノードは「サーバ（server）」ノードと呼ばれ、これらの資源とサービスを利用するノードは「クライアント（client）」ノードと呼ばれている。ＷＡＮはもっと大きなエリアを取り囲んでいるのが一般で、電話回線などのコモン・キャリア接続を含んでいる場合もある。
Alok Sinha著「クライアント−サーバ・コンピューティング」（Client-Server Computing）という文献には、クライアント−サーバ・コンピューティング・テクノロジの一般的概念が開示されている。この文献では、基本的パラダイム、業界の見通し、テクノロジ、接続インタフェース、およびデータベース・インタフェースとグラフィカル・インタフェースを含む将来の可能性が議論されている。この文献はクライアント−サーバ・テクノロジの適度に詳しい概要書である。
C.Tschudin著「フレキシブル・プロトコル・スタック」（Flexible Protocol Stacks）という文献はフレキシブル・スタックの実現可能性について検討し、「プロトコル・スタックが動的に再構成されたとき起こる、いくつかの基本的問題を実験する」ためのテスト・システムを開示している。この文献は、「スタック構築手法を探すためにもっと研究が必要である」こと、およびもっとテストとデバッギングが必要であることを指摘している。この文献はフレキシブル・プロトコルの可能性を考慮しているが、他方では、「そのようなプロトコル環境が実現可能であるかどうかという問題が残っている」こと、および「現在の研究水準では、任意のプロトコル・スタックを取り扱うために必要な手法と、かかる環境を実現するために必要な手法の知識が不十分である」ことを認めている。最後に、この文献は、「そのような一般的プロトコル環境を有することを期待する前に、実行状態（running）のプロトコル・スタックの管理に関する理解がもっと必要である」と述べている。
ＬＡＮとＷＡＮは、様々な構成で互いに結合されて、異なる建物やロケーション間を結んでいる場合や、大陸全体に渡っている場合もある「エンタープライズ」ネットワークを構築することがよくある。エンタープライズ・ネットワークが便利である理由には、いくつかある。このネットワークは資源共用を可能にする。つまり、プログラム、データおよび機器は、資源とユーザの物理的ロケーション（所在）に関係なく、ネットワークに接続されたすべてのノードが利用できる。また、エンタープライズ・ネットワークでは、複数のデータ・ソースを重複して使用可能にしておくことにより信頼性も得られる。例えば、重要なデータ・ファイルは複数のストレージ（記憶）デバイスに複製しておくことができるので、例えば、機器障害が原因でファイルの１つが使用不能になっても、重複ファイルを使用することができる。
エンタープライズ・ネットワークの最も重要な特徴の１つは、ネットワークに接続されたユーザのすべてに大規模で、高度のサービス・セットを妥当なコストで提供できる能力をもっていることである。しかし、ユーザがネットワークの潜在能力を活用するためには、ユーザはネットワーク資源を識別し、そこに位置づけて、アクセスできなければならない。ネットワークが小規模のときは、使用できる資源に位置づけて、アクセスすることは比較的単純であるが、ネットワークは成長して大きくなり、現在では、非常に大規模なネットワークが多数存在する。何千のノードからなるネットワークは普通であり、何百万のノードからなるネットワークが出現する見通しもある。
大規模ネットワークの例として、INTERNET（インターネット）ネットワークがあるが、これは大きな公共機関や私企業で利用されている。この種のネットワークがもつ能力の多くは、ユーザが使用できる機能にユーザが気づいていないか、あるいは機能にアクセスする方法が困難であるか、紛らわしいという単純な理由で未使用のままになっている。その結果、ユーザがネットワーク資源に位置づけて、アクセスするのを容易にするために、多くの既存ネットワークは現在では、ユーザから資源識別子または資源名を受け取り、所望のネットワーク資源に対応するネットワーク・アドレスに位置づけるネットワーク・ディレクトリまたはネーミング・サービスを利用している。
例えば、入力される識別子または名前は「記述的」にすることができ、他の資源と区別できるだけの十分な属性を記述することにより資源を指定する。このような記述名はネットワークをサーチして、ある特定基準に一致する資源を探し出す人間のユーザにとっては非常に役立つが、これらの名前は最大のコンピューティング資源も必要とし、効率よく分散化することが困難である。現在、このような記述名サービスに関する標準がいくつか存在する。例えば、国際電信電話諮問委員会（Consultative Committee on Infomational Telephony and Telegraphy-ＣＣＩＴＴ）および国際標準化機構（International Standards Organization-ＩＳＯ）は、X.500と呼ばれる記述名サービスに関する規格を開発した。
ネーミングとディレクトリ・サービス（これらは以下「ディレクトリ・サービス」と総称することにする）は、現在種々の方法で実現されている。最も単純な実現方法では、名前および対応するネットワーク・アドレスのリストを収めておくために、ローカル・サーバ・ノードに置かれている単一の集中型データベースを使用している。このようなローカル化ディレクトリ・サービスの例は図１に示されている。図１は、複数のクライアント・ノード１０６，１０８，１２０，１２２，１２８よりなる「クライアント−サーバ」構成に配置されたコンピュータ・ネットワークを示している。これらのクライアント・ノードは、例えば、ワークステーション・パーソナル・コンピュータ、ミニコンピュータまたは他のコンピューティング・デバイスになっており、そこではアプリケーション・プログラムが実行され、リンク１０２，１１０，１１６，１２６，１３６を含む種々のネットワーク・リンクを通して相互に通信し、またノード１００，１１２，１２４，１３２，１３８などのサーバ・ノードと通信している。サーバ・ノードには、クライアント・ノードの全部または一部にサービスまたはサービス・セットを提供できる専用化ハードウェア・デバイスとソフトウェア・プログラムが置かれている。クライアント・ノードは、サーバ・ノードから提供される種々のネットワーク・サービスのユーザである。
代表例として、集中型ディレクトリ・サービス・データベース１０４は、ノード１００のような、サーバ・ノードの１つに置かれている。クライアント・ノード、例えば、クライアント・ノード１０８は、サーバ・ノード１００と接続し、資源識別子または資源名を入力し、関連サービスのネットワーク・アドレスを検索することによりディレクトリ・サービスにアクセスすることができる。従来のデータベース手法によると、クライアント・ノードはデータベース上をサーチして特定の資源に位置づけることが可能になっている。さらに、多くのディレクトリ・サービスは部分名記述、「ワイルドカード（wild card）」およびプレースホルダ（placeholder）を使用してブラウズ（browse）することをサポートしている。単一データベースによるこの種の集中型ディレクトリ・サービスは、ネットワーク・アドレスが少数である小規模ネットワークでは有効である。しかし、大規模ネットワークでは、すべての資源識別子を中央の一か所に置いておくことは事実上不可能である。さらに、単一データベースはネットワーク全体を使用不能にできる単一の障害ポイントを表わす。さらに、集中型データベースは貧弱なパフォーマンスという欠点をしばしばもつ。例えば、クライアント１０８のようなローカル・クライアントがサーバ１００と接続してデータベース１０４をアクセスすることは比較的効率的であるが、クライアント１２０のようなリモート・クライアントは、「ゲートウェイ」リンク１１６と共に、いくつかのサーバ１２４，１１２を経由してリンクしなければならないので、大量のネットワーク・オーバヘッドが発生し、システム全体のアクセス「コスト」が高くなる。リモート・アクセスの試みが多くなると、ディレクトリ・サービス・プロバイダはネットワーク全体にわたって直ちに処理ボトルネックと通信ボトルネックになってしまう。
上記問題を解消するために、データベース・データを複数のロケーションに分散化する別の従来手法が開発されている。このようなシステムが図２に概略図的に示されている。図２はクライアント・サーバ型のネットワークを示しているが、これは図１に示したものと似ている。具体的には、これらの２つの図で対応するエレメントは対応する参照符号が付いている。例えば、図１のクライアント１０８は図２のクライアント２０８と類似している。これらの２つのネットワークの違いは、ディレクトリ・サービス・データベースがいくつかのサーバ・ノードに重複して置かれていることである。例えば、サーバ・ノード２００には、サーバ・ノード２１２（データベース２１４）、サーバ・ノード２３２（データベース２３０）およびサーバ・ノード２２４（データベース２１８）と同じように、ディレクトリ・サービス・データベース２０４が置かれている。データを重複してデータベースの各々に置いておく従来方法はいくつか知られている。あるシステムでは、各資源識別子を個別的に重複して各データベースに置いている。他のシステムでは、データベース全体を重複している。さらに、他のシステムでは、個別的ノードを重複するか、あるいはデータベースをなんらかの方法で分割して重複を制限している。
図２に示す分散システムは、集中型データベースに関連する問題を防止している。データは重複されているので、障害ポイントは一か所でない。また、データは近くのサーバ・ノードで通常使用可能であるので、「リモート」クライアント・ノードというものがなく、ネットワーク・オーバヘッドが大幅に軽減されている。
しかるに、分散システムには独自の問題がある。例えば、複数のソースがデータベースを更新する可能性のあるときは、なんらかの方法を使用してデータ整合性（data consistency）を保証しなければならない。あるシステムでは、データ整合性を保つために、データのすべてのコピーが従来のデータベース・システムと同じように、緊密に同期を保つようにしている。他のシステムでは、従来の同時実行調停方式（concurrency arbitration scheme）を用いてデータ保全性（data integrity）を保証している。
このようなネーミングおよびディレクトリ・サービスは、同じアクセス方式とプロトコルがネットワーク全体にわたって適用されるような同種ネットワークでは効果的である。この場合には、整合性のある名前とルールのセットが開発されて、種々の資源の位置づけとアクセスを比較的容易にできる。しかし、多くの大規模ネットワークは異種ネットワークである。つまり、ネットワークは、ワーク・ステーション、パーソナル・コンピュータ、ミニコンピュータ、スーパコンピュータ、メインフレームといったように、多種類の異なるコンピュータを含んでいるだけでなく、ネットワーク自体は、「ゲートウェイ」と呼ばれるインタフェースを通して互いに結合された多数の独立型小規模ネットワークから構成されている。これらの小規模ネットワークは独自のアクセス方式とプロトコルをもっていることがある。さらに、これらの大規模ネットワークの異種構造と編成は、共通の方式とプロトコルを指図できる中央制御と管理には力を貸さない。
互いに結合された小規模ネットワーク群から構成された多数の大規模ネットワークでは、基礎となる個別ネットワークの各々は、特定のプロトコルを使用する独自の異なるディレクトリ・サービスをもっている。このタイプのネットワークでは、ユーザは各ネットワーク・ディレクトリ・サービス・プロトコルに精通している必要があり、サーチがあるネットワークから次のネットワークへ実行されるとき、あるプロトコルから別のプロトコルへ移る必要がある。その結果、このような異種ネットワークでは、ネットワーク資源をアクセスすることを困難にしている主要問題の１つは、詳細および、これらの個別ネットワークの各々にアクセスするときに関連するプロトコルにユーザがとらわれることなく、異種ネットワーク上で動作可能なネットワーク資源の整合性のあるグローバル・アクセス可能なディレクトリが欠如していることに起因している。
今日のネットワーキング・サービスは種々のプロトコル・システムをもっている。従来技術では、アプリケーションは、ネットワーキングのプロトコル・アーキテクチャに関する詳細情報を含んでいなければならなかった。この要件がアプリケーションを特定のプロトコルに結びつけていた。アプリケーションはソース・コードを変更しないとプロトコルの変更をサポートできないために、これはネットワークを動的に構成することを妨げていた。
以上に鑑みて、本発明の目的はアプリケーションがサービスのタイプと品質を指定できるようにすることである。
発明の概要
本発明の一実施例によれば、ルール・ベース・プロトコル選択メカニズムが該当のプロトコル構成をサービスのタイプと品質に基づいて選択することにより、上述した問題を解決し、上述した目的を達成している。各プロトコル・ファミリごとに、ルール・セットが定義され、サービスのタイプと品質を特定の共通プロトコル・セットに変換するようにしている。
【図面の簡単な説明】
本発明の上記およびその他の利点は、添付図面と関連して以下の説明を参照することによりもっと理解しやすくなる。添付図面において、
図１は、ローカル・ディレクトリ・サービスを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。
図２は、分散ディレクトリ・サーバを取り入れている従来のクライアント・サーバ・ネットワークを示す概略ブロック図である。
図３は、ルール・ベース・プロトコル選択メカニズムが動作しているコンピュータ・システム、例えば、パーソナル・コンピュータ・システムを示す概略ブロック図である。
図４は、ルール・ベース・プロトコル選択メカニズムを取り入れているクライアント・サーバ・ネットワークを示す概略ブロック図である。
図５は、国際標準化機構の７層モデルに準拠して２ノード構造間でデータを伝送するために使用される従来のプロトコル・スタックの詳細を示す概略ブロック図である。
図６は、通信ディレクトリ・サービスの主要コンポーネントを示す概略図である。
図７は、種々のディレクトリ・サービスと他のネットワーク・サービス上でブラウズを可能にするディレクトリ・ツリーのセットアップ例を示す概略図である。
図８はサーバ・ノードの主要コンポーネントを示す概略ブロック図であり、サービス・プログラムが通信ディレクトリ・サービスとやりとりする様子を示している。
図９は、新サービスをネットワーク上で使用可能にするときに伴うステップを示す簡略フローチャートである。
図１０は、サービス・オブジェクトをアクチベートするためにサービス・プログラムによって実行されるステップを示す展開されたフローチャートである。
図１１は、クライアント・ノードの主要コンポーネントを示す概略図であり、アプリケーション・プログラムが通信ディレクトリ・サービスとやりとりしてサービスをアクセスする様子を示している。
図１２は、ネットワーク上で使用可能なサービスをアクセスするときに伴うステップを示す簡略フローチャートである。
実施例の詳細な説明
本発明は、好ましくは、ＩＢＭ（登録商標）PS/2（登録商標）またはアップル（登録商標）マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータに常駐したオペレーティング・システムを背景に実施される。図３は代表的なハードウェア環境を示しもので、本発明によるコンピュータ３００の代表的なハードウェア構成を示していてる。コンピュータ３００は中央処理ユニット３０２によって制御されるが、このユニットは従来のマイクロプロセッサにすることが可能である。いくつかの他のユニットはすべてがシステム・バス３０８を介して相互に接続され、特定のタスクを成し遂げるために用意されている。特定のコンピュータは、図３に示すユニットの一部だけを備えていたり、図示していない付加的な構成要素を含んでいたりする場合があるが、大部分のコンピュータは、少なくとも図示のユニットを含んでいる。
具体的には、図３に示すコンピュータ３００は、情報の一時記憶域のためのランダム・アクセス・メモリ（ＲＡＭ）３０６、コンピュータの構成と基本的操作コマンドの永久記憶装置のためのリードオンリ・メモリ（ＲＯＭ）３０４、およびディスク・ユニット３１３やプリンタ３１４などの周辺デバイスを、それぞれケーブル３１５と３１２でバス３０８に接続するための入出力（Ｉ／Ｏ）アダプタ３１０を含んでいる。ユーザ・インタフェース・アダプタ３１６も提供されているが、これはキーボード３２０などの入力デバイス、およびマウスやスピーカ、マイクロホンを含む他の公知インタフェース・デバイスをバス３０８に接続するためのものである。ビジュアル出力は、バス３０８をビデオ・モニタなどのディスプレイ・デバイス３２２に接続しているディスプレイ・アダプタ３１８から提供される。ワークステーションは、常駐のアップル・システム／７（登録商標）オペレーティング・システムなどのオペレーティング・システムを有し、それにより制御と調整をされている。
好適実施例では、本発明は、オブジェクト指向プログラミング技法を用いてＣ++プログラミング言語で実現されている。Ｃ++はコンパイル型言語である。つまり、プログラムは人間が読むことのできるスクリプト（script）で書かれ、このスクリプトはコンパイラと呼ばれる別のプログラムに渡される。コンパイラはマシン可読（machine-readable）の数値コードを生成し、このコードはコンピュータにロードされ、コンピュータによって直接に実行される。以下で説明するように、Ｃ++言語はいくつかの特徴をもっている。これらの特徴によると、ソフトウェア開発者は他の人が書いたプログラムを容易に使用できると共に、プログラム再使用の管理を強化してプログラムの破壊や誤った使い方を防止することができる。Ｃ++言語は周知であり、この言語を詳しく説明した論文や文献は多数利用可能である。さらに、Ｃ++コンパイラは、Borland Internationa1,Inc.、Microsoft Corporationなどの数社から市販されている。そのために、混乱を避けるために、ここでは、Ｃ++言語の詳細とＣ++コンパイラの操作について詳しく説明することはしないことにする。
この分野に精通した当業者ならば理解されるように、オブジェクト指向プログラミング（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-80MVC(ParcPlace)などがある。
アプリケーション・フレームワークによる解決手法では、カプセル化、多様性、および継承のすべての原理をオブジェクト層に利用し、他のプログラミング技法を大幅に改善しているが、いくつかの困難な問題も起こっている。これらの困難な問題は、開発者が自身のオブジェクトを再使用することは容易であるが、他のプログラムによって生成されたオブジェクトを開発者が使用することが困難であることから起こっている。さらに、アプリケーション・フレームワークはモノリシック（monolithic）・オペレーティング・システムに上乗せされた１つまたは２つ以上のオブジェクト「層」から構成されているのが一般であり、オブジェクト層に柔軟性がある場合であっても、面倒な手続型コール（procedural call）を通して、基礎となるオペレーティング・システムと直接にやりとりする必要がしばしば起こっている。
アプリケーション・フレームワークがアプリケーション・プログラム用のプレハブ機能を開発者のために用意しているのと同じように、好適実施例に含まれているようなシステム・フレームワークは、開発者が変更またはオーバライドすることによりカスマイズした解決手法を作成できるシステム・レベルのサービス用のプレハブ機能を提供することができ、従来のアプリケーション・フレームワーク・プログラムで必要であった面倒な手続型コールを避けることができる。例えば、アプリケーション・プログラムによって生成された印刷可能情報の、自動ページ付け、プリプリント処理およびページ構成の土台を提供できる印刷フレームワークについて考えてみることにする。アプリケーション・ソフトウェア開発者がこれらの機能を必要とするときは、通常は、その機能を提供するための特定のルーチンを書く必要があった。これをフレームワークを使用して行う場合は、開発者は最終的出力の特性と動作を用意するだけでよいのに対し、フレームワークは、これらのタスクを実行する実際のルーチンを提供する。
好適実施例では、フレームワークの概念を取り入れ、アプリケーションとオペレーティング・システムを含むシステム全体にこの概念を適用している。商業ベースまたは企業の開発者、システム・インテグレータ、またはＯＥＭにとっては、このことは、MacAppなどのフレームワークに関して上述した利点のすべてが、テキストやユーザ・インタフェースなどの事物についてアプリケーション・レベルにおいてのみならず、プリント、フラフィックス、マルチメディア、ファイル・システム、入出力（Ｉ／Ｏ）、テストなどのサービスについてはシステム・レベルでも挺入れできることを意味する。
図４は、図１と図２に示すクライアント−サーバ・ネットワークにおいて、通信ディレクトリ・サービスが提供されているものを示す概略図である。図２と図４を比較すると分かるように、全体的ネットワーク構成はどちらのネットワークの場合も同じであるが、通信ディレクトリ・サービスが図４に示すように使用されるときは、ノードはすべてが通信ディレクトリ・サービス（ＣＤＳ）モジュールを含んでいる。具体的には、サーバ・ノード４００，４１２，４２４，４３２，４３８は、それぞれ通信ディレクトリ・サービス・モジュール４０５，４１３，４２５，４３０，４３９を含んでいる。さらに、サーバ・ノードはいずれかが、あるいはすべてが従来のディレクトリ・サービス４０４，４１４，４１８，４３０をそれぞれ含むことも可能である。従来のディレクトリ・サービスは、通信ディレクトリ・サービスと区別するために、以下では物理ディレクトリ・サービスと呼ぶことにする。
サーバ・ノードに加えて、クライアント・ノード４０６，４０８，４２０，４２２，４２８（それぞれＣＤＳ４０７，４０９，４２１，４２３，４２９）の各々も、通信ディレクトリ・サービスを含んでいる。以下で詳しく説明するように、図４に示すようなエンタープライズ・ネットワークでは、あるノードから別のノードへ送られる情報は、一般に離散的メッセージまたは「パケット」に分割され、これらのパケットは事前定義のプロトコルに従ってノード間で伝送される。ここで言う「プロトコル」とは、別々のノードがどのようにサポートされて、相互にやりとりするかを定義したルール（規則）またはプロシージャ（手順）の集まりからなっているものである。
設計の複雑さを軽減するために、大部分のネットワークは一連の「層」または「レベル」で編成されるので、あるノードから別のノードへ渡される情報が層から層へ伝送されるようになっている。各層内では、あらかじめ定義したサービスまたはオペレーションが実行され、層はあらかじめ定義されたプロトコルに従って相互に通信し合っている。層化的な設計の目的は、ある層が、標準化インタフェースを通して他の層へ選択されたサービスを提供することを可能にすると共に、ある層内の実際のインプリメンテーション（実装）の詳細が他の層から見えないようにすることである。以下で詳しく説明するように、クライアント・ノードとサーバ・ノードはどちらも、通信ディレクトリ・サービス・モジュールと共同作用してネットワーク層を構成し、ネットワーク層の方は、クライアントとサーバ間の接続のタイプとパラメータを、提供されるサービスのタイプに従って制御する。
ネットワーク・アーキテクチャ（ネットワークで使用される層とプロトコルの集まりの全体名）を標準化する試みとして、一般化されたモデルが国際標準化機構（ＩＳＯ）によって提案されているが、これは現在使用されている種々のプロトコルを国際的に標準化する第一歩となるものである。このモデルは、開放型システム間相互接続（open sytems interconnection-ＯＳＩ）参照モデルと呼ばれているが、これは他のシステムとの通信用に「開放」されているシステムの相互接続を扱っているためである。提案されたＯＳＩモデル案は７層からなり、（相互に作用し合う順に）「物理」層、「データリンク」層、「ネットワーク」層、「トランスポート」層、「セッション」層、「プレゼンテーション」層、「アプリケーション」層と名づけられている。ＯＳＩモデルの目的は、各層内で処理されるプロセスを標準化することである。
ＯＳＩモデルによれば、物理層で実行されるプロセスは、未処理（raw）データ・ビットの通信チャネル上の伝送を扱っている。データ・リンク層で実行されるプロセスは未処理データ・ビット・ストリームを操作し、それを見かけ上伝送エラーのないデータ・ストリームに変換する。後者のタスクは伝送データをデータ・フレームに分割し、そのあとにエラーを検出または訂正するエラー訂正メカニズムを付けてフレームを順次に伝送することにより行われる。
ネットワーク層プロセスは、データ・パケットをデータ・ソースからデータ・デスティネーションへどのようにルートする（route）かを、ネットワークを通る多数の代替経路から１つを選択することにより判断する。トランスポート層プロセスの機能は、セッション層からデータ・ストリームを受け取り、それをもっと小さな単位に分割し（必要な場合）、その小さな単位をネットワーク層へ渡し、順序エラー、重複または紛失データなしで、デスティネーションに正しくすべて到着したことを保証する適当なメカニズムを提供することである。
セッション層プロセスは、異なるマシンにいるユーザが相互間で「セッション」または「会話（dialogue）」を確立することを可能にする。セッションは通信し合うノード間で通常データのトランスポートを可能にするが、ある種のアプリケーションでは、会話制御、トークン管理と同期化などの機能強化サービスも提供する。プレゼンテーション層は要求頻度の高いある種の共通機能を実行して、例えば、データを標準フォーマットへのコード化、暗号化と解読の実行、その他の機能の実行といった、一般的解決法を見つけることを保証する。最後に、アプリケーション・プロトコル層は、データベース・アクセス、ファイル転送などの、共通に必要になる種々のプロトコルを含んでいる。
例えば、図５は、ＯＳＩ標準の７層アーキテクチャに準拠して２つのノード間を接続するために使用される従来技術のプロコトル・スタックを示す図である。ＯＳＩ標準によれば、ノードの各プロトコル・スタックは７層からなっている。例えば、クライアント・ノード４０８のスタック５２８は、アプリケーション層５００、プレゼンテーション層５０２、セッション層５０４、トランスポート層５０６、ネットワーク層５０８、データリンク層５１０および物理層５１２からなっている。これらの層の各々のオペレーションと目的は前述した通りである。同様に、サーバ・ノード４３２のスタック５３２は層５１４〜５２６からなっている。実際のデータ通信は２つの物理層５１２と５２６間でデータ・リンク５３０を通して行われるが、スタックが図５に示すような配置になっているときは、各層は、ある層と同じレベルにある層である「ピア（peer）」と通信していると考えることができる。例えば、アプリケーション層５００と５１４は、情報が層５０２〜５１２のすべてを通過し、データ・リンク５３０を経由し、層５１６〜５２６を通って戻る場合でも、直接に通信していると考えることができる。同様に、プレゼンテーション層５０２と５１６はピアツーピア（peer-to-peer）で通信することができる。
図５に示すようなプロトコル・スタックは、複数のデータ・バッファを使用して実現されているのが代表的である。各データ・バッファは、そこで処理が行われるプロトコル層を構成している。ある層で処理が完了したあと、データを別のバッファへ転送して、別の層に従ってさらに別の処理を行うことができる。
本発明がもつ一側面によれば、ネットワーク内でピアツーピア通信を制御するプロトコル・スタックは、通信ディレクトリ・サービスにストアされたスタック定義によって構成される。これらのスタック定義は、ネットワークで使用できる各サービス・タイプと関連づけることできるので、アプリケーション・プログラムからのサービス要求に応答してプロトコル・スタックを動的に構成することができるようになっている。
通信ディレクトリ・サービスの詳細図は図６に示されている。モジュールは３つの主要コンポーネントからなっている。ネットワークから提供される物理ディレクトリ・サービスと他のサービスの各々を、従来のツリー探索手法を用いて位置づけることを可能にする階層ディレクトリ・ツリー６０２と、クライアントがあらかじめ指定した通信リンク上にリモート・サーバ・ノードからのデータを要求できるようにする動的再構成可能スタックをプログラミングするために使用されるスタック定義オブジェクトの集まり６０４と、「サービス・オブジェクト」の集まり６０６とである。各サービス・オブジェクトは、ネットワーク上で使用できる１つのサービスと関連づけられ、そのサービスが使用可能なネットワーク・アドレスまたは交換アドレスと、スタック定義オブジェクト６０４の１つまたは２つ以上へのリファレンス（参照）６０８とを含んでいる。以下で詳しく説明するように、これらのサービス・オブジェクトの１つへのリファレンスは、対応するサービスへのアクセスを望んでいるアプリケーション・プログラムによって取得される。このリファレンスで識別されたオブジェクトにおける情報は、通信経路をセットアップするために再構成可能スタックへ送られる。
スタック定義６０４の各々は、各層で実行される処理と層間の相互作用を指定している層定義の集まりからなっている。スタック定義は、通信リンクがネットワーク・システムにインストールされるときに定義される。具体的には、スタック定義はシステム上の異種通信リンクごとに用意される。
通信ディレクトリ・サービス６００には、ネットワーク上のユーザにとってそのオペレーションを特に便利なものにする特徴がほかにもいくつかある。具体的には、ディレクトリ・サービスは使用可能なサービスとディレクトリ・サービスに関する情報を、一連のオブジェクトとしてディレクトリ・ツリーにストアする。さらに、通信ディレクトリ・サービス内のストアされたライブラリはオブジェクトを含んでいるので、アプリケーション・プログラムとサービス・プログラムは共に、オブジェクトを通して通信ディレクトリ・サービスと直接に通信することができる。通信ディレクトリ・サービスはノードの各々に存在するので、クライアントはどのディレクトリ・サービス・サーバともディレクトリ・サービスを使用する前に接続する必要はない。そのかわりオブジェクト自体がインタフェースとなるからである。さらに、サービス・オブジェクト６０６のような、あらかじめ定義されたオブジェクトの使用は、アプリケーション・プログラムが所望するサービスとの通信をオープンすることができる簡単な方法を提供する。アプリケーション・プログラムが実際の経路構造の詳細について気にする必要なしに、サービス・オブジェクトはネットワーキング・サービスへ直接に送られて通信経路をオープンできる。さらに、既存の物理ディレクトリ・サービスはいずれも、ディレクトリ・ツリー６０２のノード・オブジェクトにカプセル化されているので、物理ディレクトリ・サービスはクライアント・アプリケーションから完全に隠蔽され、クライアント・アプリケーションは、整合性のあるプロトコルとフィーチャ・セット（feature set）を使用して通信ディレクトリ・サービスと相互作用することができる。
通信ディレクトリ・サービスに見られるディレクトリ・ツリー６０２の詳細図は図７に示されている。以下で詳しく説明するように、ディレクトリ・ツリーは単純なサーチ（探索）コマンドを使用して走査することができ、完全なブラウズ機能はワイルド・カードとプレースホルダを使用により得られる。ディレクトリ・ツリーは、サーチの結果としてオブジェクトが返され、返されたオプジェクトのタイプがオブジェクトを返したディレクトリ部分のインプリメンテーションによって決定されるように設計されている。ディレクトリ・ツリーのサーチから返されるオブジェクトの例としては、リモート・サービスと接続するために使用される情報を含んでいる、図６に示すサービス・オブジェクト６０６へのリファレンス、ユーザに関するセキュリティと認証情報を含んでいるプリンシプル（principle）オブジェクト、ユーザに関する情報のコレクションを含んでいる「ビジネスカード」およびプログラム開発者がディレクトリ・ツリーに追加できる他のクラスがある。ディレクトリ・ツリーは、図７に示すような単一階層ツリーの編成になっている。なお、図７に示すツリー構成は単なる例示であり、本発明の範囲と原理から逸脱することなく実際のツリー構成は図示の構成と大幅に異なることがある。ツリー内のノードの各々は"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 ７０２のような中間namespaceを、ルートnamespace ７００とリーフ・ノード７０４〜７１０との間に挿入することが可能である。中間namespaceは他のnamespaceを参照している。前述したように、本発明の通信ディレクトリ・サービスはサービス・プログラムとアプリケーション・プログラムの両方と相互作用して、クライアントとサーバとの間で必要な通信リンクを透過的に（transparently）セットアップする。この相互作用では、サービス提供者による通信ディレクトリ・サービスにおけるサービス・オブジェクトの生成と、サーバ・ノードにおけるプロトコル・スタックの構成を含む。サービスのアクセスを所望するクライアントは関連サービス・オブジェクトを検索し、それを使用してプロトコル・スタックをクライアント・ノードに構成して通信リンクをセットアップする。図８〜図１０は、サーバ・ノードで稼働しているサービス・プログラムによって実行されて、クライアント・ノードで実行されているアプリケーション・プログラムにより使用できるように新しいサービスをネットワーク上で使用可能にするオペレーションを説明したものである。図８は、新サービスの生成とアクチベーションに含まれるサーバ・ノード・プログラムの部分を示す概略ブロック図である。図９は、サービス・プログラム、通信ディレクトリ・サービスおよびノード・ネットワーキング・サービスの間で相互作用して、新サービスを確立し、適当な通信リンク上で動作するようにネットワーキング・サービスを構成する手順を示したフローチャートである。図１０は、関連サービス・ブロックをアクチベートすることによって新サービスをアクチベートする様子を示す詳細ブロック図である。もっと具体的に説明すると、図８は、サービスをリモート・クライアントに提供するときのサーバ・ノードの基本的構成を示している。サーバ・ノードは共通エリア、または、システム・アドレス空間８００をもつ構成になっており、このアドレス空間には、オペレーティング・システム・プログラムと、システムで実行されるサービス・アプリケーションによって使用される種々の共有ライブラリが置かれている。具体的には、システム・アドレス空間８００には、通信ディレクトリ・サービス８０４およびネットワーキング・サービス・プログラムとライブラリ８１６が含まれている。サーバ・ノードには、独自のアドレス空間８１０で実行されるサービス・プログラムも置かれている。以下で説明するように、サービス・プログラム８０６は通信ディレクトリ・サービス８０４と相互作用してサービス・オブジェクトを作成し、これは通信ディレクトリ・サービス８０４に置かれる。このサービス・オブジェクトはこのシステム内の他のノードすべてに分散（distribute）されるので、ネットワーク上のクライアントのすべてに対してローカル・ベースでの使用ができる。サービス・オブジェクトはネットワーキング・サービス８１６を構成するための適当なスタック定義を含んでいるので、アプリケーション・プログラムは通信ディレクトリ・サービスと共に、以前にストアした定義を用いて構築の詳細においてクライアント・アプリケーション・プログラムの必要なしに、通信経路をセットアップすることができる。
図９を参照して説明すると、新サービスの生成はステップ９００からスタートして、ステップ９０２へ進む。ステップ９０２で、サービス・プログラムの開発者は、新サービスに適当な構成パラメータを含んでいる新サービス・オブジェクトの生成を動作可能にする。これは、ディレクトリ・サービスに置かれているサービス・オブジェクト・クラスをサブクラス化することにより行うことができる。具体的には、新サービス・オブジェクト・クラスを生成するために、サービス・プログラム開発者はそのサービスの一意的な名前（unique name）、サービスのタイプ、およびオプションとして、サービスをアクセスするとき使用できる種々の通信リンク・タイプを指定する。通常のオブジェクト指向プログラミング言語のオペレーションによれば、このサブクラス化情報はコンパイル時にサービス・プログラム・コードに含まれる。従って、サービス・プログラム８０６が適当なサーバ・ノードのサービス・プログラム・アドレス空間８１０にインストールされているときは、サービス・オブジェクト・サブクラスの構築子（constructor）は、コールされて、ステップ９０４（図９）に示すようにサービス・オブジェクトを通信ディレクトリ・サービス８０４に構築することができる。構築子をコールする過程で、サービス情報のタイプと品質は、図中に矢印８０２で示すように通信ディレクトリ・サービスに渡される。
前述したように、通信ディレクトリ・サービス８０４は、共用ライブラリに置かれているスタック定義の集まりを含んでいる。これらのスタック定義は、通信リンクが定義され、特定のトランスポート・メカニズムと関連づけられる時に生成される。スタック定義はそれぞれ層定義の集まりからなっている。層定義は、各層におけるデータの処理と層間の相互作用を制御する。各スタック定義は、トランスポート層から物理層までのスタックを完全に定義している（これらの層の詳細は上述した通りである）。
新サービス・オブジェクトを作成する過程で、通信ディレクトリ・サービス８０４はサービス・プログラムから提供れたサービス情報のタイプと品質を使用してセッション層を構築し、ストアされた通信スタック定義を参照する適当なリファレンスを、ステップ９０６に示すように含む。
新サービスをアクセスするために２つ以上の通信リンクが使用できるときは、適当なスタック定義が新サービス・オブジェクトの中で参照され、セッション層が構築されて、必要とするサービスのタイプと品質や通信リンクの可用性などの種々の基準に基づいて通信リンクの１つが選択される。
以上のように、新しく作成されたサービス・オブジェクトはセッション層と、トランスポート層から物理層までのスタックを定義している適当なスタック定義を含んでいる。このサービス・オブジェクトは通信ディレクトリ・サービスにストアされる。なお、この時点では、どのサービス・アドレスまたは交換アドレスもサービス・オブジェクトに提供されていない。これはサービス・オブジェクトが生成されても、アクティブでないからである。従って、サービス・オブジェクトは、サービス・プログラムがサーバ・ノードにインストールされているときはいつでも生成できるが、サービス・プログラムは下述する以降のステップがとられるまでアクチベートされない。
もっと具体的に説明すると、新サービスをアクチベートするために、サービス・プログラムは、ステップ９０８に説明されているように、ストアされたサービス・オブジェクトをネットワーキング・サービス８１６内の動的再構築可能スタック（ＤＲＰＳ）８２２へ送るように通信ディレクトリ・サービス８０４に指示する。サービス・オブジェクトがどのようにＤＲＰＳへ転送されるかは図８に示されている。具体的には、サービス・プログラム８０６は、まず、サービス・プログラム・インタフェース８２８を独自のアドレス空間８１０に生成する。サービス・プログラムとサービス・プログラム・インタフェースとの間の通信は図中に矢印８０８で示されている。サービス・プログラム・インタフェース８２８の方は構成データ・ストリーム８１４を生成し、これは、ネットワーキング・サービス８１６に常時使用できるように置かれているサーバ・インタフェース８１８へデータをストリーム化して送ることができる。
次に、サービス・プログラム８０６は、ネットワーク構成データを含んでいるサービス・オブジェクトを検索する。この構成データは、矢印８１２で示すように通信ディレクトリ・サービスからサービス・プログラム・インタフェース８２８へ渡される。そのあと、構成データは矢印８１４で示すように、ストリーム化されてシステム・アドレス空間８００へ送られる。
次に、ステップ９１０に示すように、サービス・プログラムがサービス・オブジェクトをアクチベートすると、サービス交換アドレスが通信ディレクトリ・サービス８０４に戻される。アクチベーション・シーケンスの詳細は図１０に示すフロー・チャートに示されている。具体的には、アクチベーション・シーケンスはステップ１０００からスタートし、ステップ１００２へ進む。ステップ１００２で、通信ディレクトリ・サービス８０４は、そのサービスが適当なものであれば、基礎となる物理ディレクトリ・サービス上のサービスをパブリッシュすることよりサービスを使用可能にする。このパブリケーションはサービスの名前を、ある場合には、サービス・アドレスを基礎となるディレクトリ・サービスに登録することからなる。
次に、ルーチンはステップ１００４へ進み、そこでサービスが通信ディレクトリ・サービスに登録される。前述したように、この登録はサービス・オブジェクトをストリーム化して、通信ディレクトリ・サービスのネーティブnamespaceノードに入れることを含む。この時点で、サービスへのリファレンスがＣＤＳディレクトリ・ツリーに追加されるので、サービスはユーザがツリーを走査することにより位置づけられることができる。
次に、ステップ１００６において、サービス・プログラム８０６からネットワーキング・サービス８１６内のサーバ・インタフェース８１８に渡されたスタック定義リファレンスは、ＤＲＰＳ８２２を再構成するときに使用されるスタック定義をセットアップするために使用される。ステップ１００８で、生成されたスタック定義はＤＲＰＳに渡される（このオペレーションは図中に矢印８２０で示されている）。この時点で、サービス・オブジェクト内の情報はセッション層８２３をセットアップするためにも使用される。
ステップ１０１０において、ＤＲＰＳ８２２内のセッション層８２３の交換アドレス、またはネットワーク・アドレスは、通信ディレクトリ・サービス８０４に返される。具体的には、ネットワーキング・サービス８１６は、セッション層のセットアップ時にセッション層アドレスをＤＲＰＳ８２２から得る。このアドレスはサービス・インタフェース８１８を経由し、構成データストリーム８１４を通してサービス・プログラム・インタフェース８２８へ返される。最後に、交換アドレスがデータストリーム８１２を通して通信ディレクトリ・サービス８０４へ返される。この交換アドレスは、前述したように、通信ディレクトリ・サービス８０４に置かれている関連サービス・オブジェクトにストアされるので、あとでクライアント・プログラムにより検索されるようになっている。この時点で、アクチベーションは完了し、図１０に示すアクチベーション・ルーチンはステップ１０１２で終了する。ステップ９１２で、交換アドレスは通信ディレクトリ・サービスに返され、サービス・アクチベーション・ルーチンはステップ９１４で終了する。
別のデータストリームもこの時点でサービス・プログラムによってセットアップされるので、そのあとで、クライアント・ノードがサーバ・ノードからのサービス要求したとき、入来するサービス要求を受け取ることができる。具体的には、物理通信リンク８２４経由で到着したサービス要求データは、セッション層８２３をサービス・プログラム・インタフェース８２８にリンクしている別の要求データ・ストリーム８２６を通して、構成されたＤＲＰＳ８２２へ渡されるサービス・プログラム・インタフェース８２８の方は要求をデータストリーム８０８を通してサービス・プログラム８０６へ転送（forward）する。応答情報はサービス・プログラム８０６により、データ・ストリーム８０８、サービス・プログラム・インタフェース８２８、要求データストリーム８２６、ＤＲＰＳ、８２２、および物理通信リンク８２４を経由してクライアント・ノードへ返される。
新しいサービスがローカル通信ディレクトリ・サービスに追加されたあと、多のノードに置かれているコピーを更新しなければならない。この更新は従来と同じように行われる。例えば、取外し可能ディスク上のコピーをすべてのノードに定期的に分散することも可能である。しかし、通信ディレクトリ・サービスのコピーを分散するもっと好ましい方法は、更新を受け取ったローカル・ノードがその更新情報を他のすべてのノードにブロードキャスト（同報通信）することである。このブロードキャストを成し遂げるために、ブロードキャスト・メッセージは、プロトコル・スタックのすべてをあらかじめ定められたデフォルト・プロトコルにセットさせる特殊なヘッダを含んでいる。このようにすると、ブロードキャスト・メッセージはすべてのノードで受信されることが可能になる。
図１１から図１３までは、クライアント・アプリケーションが通信ディレクトリ・サービスと協調してリモート・サービスをアクセスするとき必要になるステップを示している。具体的には、図１１はリモート・サービスをアクセスするときに必要となるクライアント・ノードの適当なセクションを示している。サーバ・ノード側と同じように、クライアント・ノードにはシステム・アドレス空間１１１０があり、このアドレス空間には通信ディレクトリ・サービス１１１２とネットワーキング・サービス１１１８が含まれている。アプリケーション・プログラム１１００は、独自のアプリケーション・アドレス空間１１０４で実行する。アプリケーション・プログラム１１００、ディレクトリ・サービス１１１２およびネットワーキング・サービス１１１８の相互作用は、図１２と図３に示すフローチャートに詳しく説明されている。
具体的に説明すると、クライアント・サービス・アクセス・ルーチンはステップ１２００からスタートし、ステップ１２０２へ進む。ステップ１２０２に示すように、クライアントは通信ディレクトリ・サービスと相互作用して、通信ディレクトリ・サービスにストアされたサービス・オブジェクトの１つへのリファレンスを受け取る。この相互作用は図１１に矢印１１０６で示されている。前述したように、この相互作用には、通信ディレクトリ・サービス１１１２に置かれたディレクトリ・ツリー上をユーザがサーチするときは、ユーザを直接に必要とすることがある。あるいはまた、この相互作用は、介入するアプリケーション・プログラムを必要とし、通信ディレクトリ・サービスと共同作用して例えば、ドキュメント・アイコンをサービス・アイコン上にドラッグするといったように、目に見える形でサービスを選択する場合もある。
いずれの場合も、ステップ１２０４に従い、通信ディレクトリ・サービス１１１２で識別されたサービス・オブジェクトへのリファレンスが、矢印１１０８に示すようにアプリケーション・プログラム１１００へ返される。これを受けて、アプリケーション・プログラムは、構成データをネットワーク・サービス１１１８へ送る準備としてクライアント・インタフェース・オブジェクト１１２６を生成する。サービス・オブジェクト・リファレンスは、通信ディレクトリ・サービス１１１２により構成データ・ストリーム１１１４を通してクライアント・インタフェース１１２６へ渡される。クライアント・インタフェース１１２６からは、構成データは構成データ・ストリーム１１１６上でストリーム化されて、ネットワーキング・サービス１１１８に置かれたサーバ・インタフェース・オブジェクト１１２０へ送られる。サービス・インタフェース・オブジェクト１１２０は、システム・ブートアップ時にネットワーキング・サービス１１１８が作成されるとき作成され、ネットワーキング・サービスに永続的に常駐する。
ステップ１２０６に従い、アプリケーション・プログラム１１００はサービス・オブジェクト・リファレンスをアクチベートする。図１３は、サービス・オブジェクト・リファレンスをアクチベートするときのステップを示す詳細図である。具体的には、アクチベーション・ルーチンはステップ１３００からスタートし、ステップ１３０２へ進む。ステップ１３０２において、サービス・オブジェクト・リファレンスは、適当であれば、基礎となる物理ディレクトリ・サービスのどれかで解決される。この解決は、サービス・オブジェクトに置かれたサービス名を使用して基礎となるディレクトリ・サービス上をサーチし、ネットワーク・アドレスを得ることにより行われる。あるいはまた、サービス・リファレンスが通信ディレクトリ・サービス１１１２のネーティブnamespaceに登録されていれば、サービス・アドレスまたはサービス交換はサービス・オブジェクト・リファレンスから直接に得ることができる。
ステップ１３０４において、サービス・オブジェクトに含められたスタック定義は、サービス・インターフェース１１２０とネットワーキング・サービス１１１８によって使用され、ＤＲＰＳ１１２４を構成するようにプロトコル・スタック層がセットアップされる。次に、ステップ１３０６で、生成されたスタック定義は矢印１１２２で示すようにＤＲＰＳに渡される。これらのスタック定義は、要求と応答データをアプリケーション・プログラム１１００とリモート・サービス（図１１には示されていない）との間で送る準備として、ＤＲＰＳ１１２４をセットアップし、通信リンクを構成する。
次に、ステップ１３０８において、ＤＲＰＳ１１２４内のセッション層１１２３のアドレスはサーバ・インタフェース１１２０に返される。そのあと、アクチベーション・ルーチンはステップ１３１０で終了する。図１２のステップ１２０８へ戻り、サーバ・インタフェース１１２０は、セッション層１１２３のアドレスを、サービス・オブジェクト・レファレンスから得たリモート・サービス交換と入れ替えて、リモート・サービス交換（ステップ１２０８に示すように）を、構成データ・ストリーム１１１６、クライアント・インタフェース１１２６およびデータ・バス（data path）１１０２を経由してアプリケーション・プログラム１１００に返す。このように、アプリケーション・プログラムはリモート・サービスと通信するときは、通信ディレクトリ・サービスからネットワーキング・サービスへ渡されたリモート・サービス・アドレスを使用する。
ステップ１２１０に示すように、サービス要求をアプリケーション・プログラム１１００からリモート・サービスへ送るように、別のデータ・パスがセットアップされる。この別のデータ・パスは、データ・パス１１０２、クライアント・インタフェース１１２６およびＤＲＰＳ１１２４のセッション層１１２３を含んでいる。ステップ１２１２に従って、要求情報は物理通信リンク１１３０を経由してリモート・サービス・ロケーションへ送出される。応答情報は、ＤＲＰＳ１１２４、データ・ストリーム１１２８、クライアント・インタフェース１１２６およびデータ・パス１１０２を経由してアプリケーション・プログラム１１００に返される。そのあと、サービス要求ルーチンはステップ１２１４で終了する。
Claims (16)
- 通信ディレクトリ・サービスとサーバ・ノードとを有するクライアント・サーバ・ネットワークであって、前記サーバ・ノードが、クライアントを該サーバ・ノードに接続する複数の通信リンクを介してサービスを提供するサービス・プログラムであって、複数層動的再構成可能ネットワーク・プロトコル・スタックによって、前記複数の通信リンクのそれぞれに接続可能なサービス・プログラム、を有するクライアント・サーバ・ネットワークにおいて、前記サービスをアクチベートする方法において、
（ａ）複数のスタック定義を前記通信ディレクトリ・サービスにストアするステップであって、前記複数のスタック定義が、それぞれ、前記複数の通信リンクのうちのいずれかと対応し、かつ、前記スタック定義が、それぞれ、トランスポータと層から物理層までのネットワーク・プロトコル定義の各層においてデータの処理及び各層間の相互作用を制御するためにそれ以降使用される層定義の集まりを含み、
（ｂ）前記サービス・プログラムが前記サーバ・ノードにインストールされたとき、前記複数の通信リンクから１つの通信リンクを選択するセッション層を構築し、かつ、その後前記通信ディレクトリ・サービスにおいてサービス・オブジェクトを作成するステップであって、前記サービス・オブジェクトが、先に構築された前記セッション層を含み、かつ、前記複数の通信リンクのそれぞれの通信リンクごとに、当該通信リンクに対応するスタック定義のリファレンスを含み、
（ｃ）前記サービス・オブジェクトを前記ネットワーク・プロトコル・スタックに送信するステップと、
（ｄ）前記選択された通信リンクが、前記セッション層と、前記サービス・オブジェクトのスタック定義のリファレンスと、を使用して、前記ネットワーク・プロトコル・スタックを再構成し、前記サービス・プログラムと前記クライアント・サーバ・ネットワークとを接続するステップと、
を備えたことを特徴とする方法。 - 請求項１において、ステップ（ｄ）は、
（ｄ１）前記サービス・オブジェクトの作成過程において、前記ネットワーク・プロトコル・スタックにおけるセッション層であって交換アドレスを有するセッション層を、前記クライアント・サーバ・ネットワークにおいてセットアップするステップと、
（ｄ２）前記交換アドレスを前記通信ディレクトリ・サービス・プログラムに送信するステップと、
（ｄ３）前記交換アドレスを前記サービス・オブジェクトにストアするステップと、
を備えたことを特徴とする方法。 - 請求項１において、前記通信ディレクトリ・サービス・プログラムは、ディレクトリ・ツリーを有しており、
本方法は、
（ｆ）前記サービス・オブジェクトを前記ディレクトリ・ツリーに登録するステップ
を備えたことを特徴とする方法。 - 請求項１において、前記ステップ（ｂ）は、
前記セッション層が、後に前記ネットワーク・プロトコル・スタックで使用されるときに、（ａ）前記サービス・プログラムにより指定されたサービス品質、又は（ｂ）前記通信ディレクトリ・サービスにより決定された、前記選択された通信リンクの可用性、のうちの少なくとも１つに基づき、前記複数の通信リンクから１つの通信リンクを選択するように、前記セッション層を構築するステップ
を備えたことを特徴とする方法。 - 請求項１において、前記ステップ（ｃ）は、
（ｃ１）前記サービス・オブジェクトを、前記ネットワーク・プロトコルに、前記サービス・プログラムのサービス・プログラムインタフェースを介して、送信するステップを備えたことを特徴とする方法。 - 請求項５において、前記ステップ（ｃ１）は、
（ｃ１ａ）前記サービス・ノードにおいて、サービス・プログラム・インタフェースを作成するステップと、
（ｃ１ｂ）前記サービス・プログラム・インタフェースから前記ネットワーク・プロトコル・スタックまでの構成データ・ストリームを作成するステップと、
（ｃ１ｃ）前記ネットワーク・プロトコル・スタックを構成するため、前記サービス・オブジェクトを、前記通信ディレクトリ・サービスから、前記プログラム・インタフェース及び構成データ・ストリームを介して、前記ネットワーク・プロトコル・スタックに、ストリーム化して送るステップと、
を備えたことを特徴とする方法。 - 請求項６において、ステップ（ｄ）は、
（ｄ１）前記ネットワーク・プロトコル・スタックにおける前記セッション層の交換アドレスを、前記通信ディレクトリ・サービス・プログラムに、前記構成データ・ストリーム及び前記サービス・プログラム・インタフェースを介して、送信するステップを備えたことを特徴とする方法。 - 請求項１において、
（ｆ）前記サービス・オブジェクトを、前記クライアント・サーバ・ネットワーク・システム上の他の複数のノードの複数の通信ディレクトリ・プログラムに、送信するステップ
を備えたことを特徴とする方法。 - 通信ディレクトリ・サービスとサーバ・ノードとを有するクライアント・サーバ・ネットワークであって、前記サーバ・ノードが、クライアントを該サーバ・ノードに接続する複数の通信リンクを介してサービスを提供するサービス・プログラムであって、複数層動的再構成可能ネットワーク・プロトコル・スタックによって、前記複数の通信リンクのそれぞれに接続可能なサービス・プログラム、を有するクライアント・サーバ・ネットワークにおいて、前記サービスをアクチベートする装置において、
複数のスタック定義を前記通信ディレクトリ・サービスにストアする手段であって、前記複数のスタック定義が、それぞれ、前記複数の通信リンクのうちのいずれかと対応し、かつ、前記スタック定義が、それぞれ、トランスポート層から物理層までのネットワーク・プロトコル定義の各層においてデータの処理及び各層間の相互作用を制御するためにそれ以降使用される層定義の集まりを含む、ストアする手段と、
前記サービス・プログラムが前記サーバ・ノードにインストールされたとき、前記複数の通信リンクから１つの通信リンクを選択するセッション層を構築し、かつ、その後前記通信ディレクトリ・サービスにおいてサービス・オブジェクトを作成する動作手段であって、前記サービス・オブジェクトが、先に構築された前記セッション層を含み、かつ、前記複数の通信リンクのそれぞれの通信リンクごとに、当該通信リンクに対応するスタック定義のリファレンスを含む、動作手段と、
前記サービス・オブジェクトを前記ネットワーク・プロトコル・スタックに送信する手段と、
前記セッション層と、前記サービス・オブジェクトのスタック定義のリファレンスと、を使用して、前記ネットワーク・プロトコル・スタックを再構成して、前記サービス・プログラムと前記クライアント・サーバ・ネットワークとを接続する手段と、
を備えたことを特徴とする装置。 - 請求項９において、前記セッション層と、前記サービス・オブジェクトのスタック定義のリファレンスと、を使用して、前記ネットワーク・プロトコル・スタックを構成する前記手段は、
前記サービス・オブジェクトの作成過程において、前記ネットワーク・プロトコル・スタックにおけるセッション層であって交換アドレスを有するセッション層を、前記クライアント・サーバ・ネットワークにおいてセットアップする手段と、
前記交換アドレスを前記通信ディレクトリ・サービス・プログラムに送信する手段と、
前記交換アドレスを前記サービス・オブジェクトにストアする手段と、
を備えたことを特徴とする装置。 - 請求項９において、前記通信ディレクトリ・サービス・プログラムは、ディレクトリ・ツリーを有しており、
本装置は、
前記サービス・オブジェクトを前記ディレクトリ・ツリーに登録する手段
をさらに備えたことを特徴とする装置。 - 請求項９において、セッション層を構築しサービス・オブジェクトを作成する前記動作手段は、
前記セッション層が、後に前記ネットワーク・プロトコル・スタックで使用されるときに、前記サービス・プログラムにより指定されたサービス品質、又は（ｂ）前記通信ディレクトリ・サービスにより決定された、前記選択された通信リンクの可用性、のうちの少なくとも１つに基づき、前記複数の通信リンクから１つの通信リンクを選択するように、前記セッション層を構築する手段
を備えたことを特徴とする装置。 - 請求項９において、前記サービス・オブジェクトを前記ネットワーク・プロトコル・スタックに送信する前記手段は、前記サービス・オブジェクトを、前記ネット・プロトコルに、前記サービス・プログラムのサービス・プログラム・インタフェースを介して、送信する手段を備えたことを特徴とする装置。
- 請求項１３において、前記サービス・オブジェクトを前記ネットワーク・プロトコル・スタックを、前記サービス・プログラムのサービス・プログラム・インタフェースを介して送信する手段は、
前記サービス・ノードにおいて、サービス・プログラム・インタフェースを作成する手段と、
前記サービス・プログラム・インタフェースから前記ネットワーク・プロトコル・スタックまでの構成データ・ストリームを作成する手段と、
前記ネットワーク・プロトコル・スタックを構成するため、前記サービス・オブジェクトを、前記通信ディレクトリ・サービスから、前記プログラム・インタフェース及び構成データ・ストリームを介して、前記ネットワーク・プロトコル・スタックに、ストリーム化して送る手段と、
を備えたことを特徴とする装置。 - 請求項１４において、前記サービス・オブジェクトのスタック定義のリファレンスを用いて前記ネットワーク・プロトコル・スタックを再構築する手段は、前記ネットワーク・プロトコル・スタックにおける前記セッション層の交換アドレスを、前記通信ディレクトリ・プログラムに、前記構成データ・ストリーム及び前記サービス・プログラム・インタフェースを介して、送信する手段を備えたことを特徴とする装置。
- 請求項９において、前記サービス・オブジェクトを、前記クライアント・サーバ・ネットワーク・システム上の他の複数のノードの複数の通信ディレクトリ・プログラムに、送信する手段をさらに備えたことを特徴とする装置。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/169,867 | 1993-12-17 | ||
| US08/169,867 US5548726A (en) | 1993-12-17 | 1993-12-17 | System for activating new service in client server network by reconfiguring the multilayer network protocol stack dynamically within the server node |
| PCT/US1994/003978 WO1995017062A1 (en) | 1993-12-17 | 1994-04-11 | Object-oriented rule-based protocol system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09506725A JPH09506725A (ja) | 1997-06-30 |
| JP3839472B2 true JP3839472B2 (ja) | 2006-11-01 |
Family
ID=22617534
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP51672595A Expired - Lifetime JP3839472B2 (ja) | 1993-12-17 | 1994-04-11 | オブジェクト指向ルール・ベース・プロトコル・システム |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US5548726A (ja) |
| EP (1) | EP0726004B1 (ja) |
| JP (1) | JP3839472B2 (ja) |
| AU (1) | AU6702494A (ja) |
| CA (1) | CA2178583A1 (ja) |
| DE (1) | DE69405405T2 (ja) |
| WO (1) | WO1995017062A1 (ja) |
Families Citing this family (194)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6044205A (en) * | 1996-02-29 | 2000-03-28 | Intermind Corporation | Communications system for transferring information between memories according to processes transferred with the information |
| US6289390B1 (en) | 1993-08-18 | 2001-09-11 | Microsoft Corporation | System and method for performing remote requests with an on-line service network |
| US5548779A (en) * | 1993-12-21 | 1996-08-20 | Taligent | System for providing system services for a device to a client using stack definition and stack description of a stack having top, intermediate, and bottom service objects |
| EP1193940A3 (en) * | 1994-03-21 | 2004-09-01 | Avid Technology, Inc. | Apparatus and computer-implemented process for providing real-time multimedia data transport in a distributed computing system |
| JPH07302236A (ja) | 1994-05-06 | 1995-11-14 | Hitachi Ltd | 情報処理システムおよびその方法並びに情報処理システムにおけるサービス提供方法 |
| US5765155A (en) * | 1994-05-11 | 1998-06-09 | Nec Corporation | Master data managing method |
| US5694546A (en) | 1994-05-31 | 1997-12-02 | Reisman; Richard R. | System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list |
| EP1313038A3 (en) | 1994-09-01 | 2005-09-07 | Computer Associates Think, Inc. | X.500 System and methods using metadata |
| US7315860B1 (en) | 1994-09-01 | 2008-01-01 | Computer Associates Think, Inc. | Directory service system and method with tolerance for data entry storage and output |
| WO1996017306A2 (en) * | 1994-11-21 | 1996-06-06 | Oracle Corporation | Media server |
| US5745748A (en) * | 1994-12-09 | 1998-04-28 | Sprint Communication Co. L.P. | System and method for direct accessing of remote data |
| US5850518A (en) * | 1994-12-12 | 1998-12-15 | Northrup; Charles J. | Access-method-independent exchange |
| AU4469896A (en) * | 1994-12-23 | 1996-07-19 | Southwestern Bell Technology Resources, Inc. | Flexible network platform and call processing system |
| US5692180A (en) * | 1995-01-31 | 1997-11-25 | International Business Machines Corporation | Object-oriented cell directory database for a distributed computing environment |
| US6515968B1 (en) | 1995-03-17 | 2003-02-04 | Worldcom, Inc. | Integrated interface for real time web based viewing of telecommunications network call traffic |
| US6077315A (en) * | 1995-04-17 | 2000-06-20 | Ricoh Company Ltd. | Compiling system and method for partially reconfigurable computing |
| DE69624168T2 (de) * | 1995-05-26 | 2003-05-28 | Intel Corp., Santa Clara | Erweiterbares System zur Verwaltung von Kommunikationsverfahren für ein Rechnersystem |
| US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
| US6901433B2 (en) * | 1995-06-07 | 2005-05-31 | Microsoft Corporation | System for providing users with a filtered view of interactive network directory obtains from remote properties cache that provided by an on-line service |
| US5774668A (en) * | 1995-06-07 | 1998-06-30 | Microsoft Corporation | System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing |
| SE504523C2 (sv) * | 1995-06-19 | 1997-02-24 | Ericsson Telefon Ab L M | Anordning och metod för att länka kunder till servrar under körtid i ett distribuerat telekommunikationsnätverk |
| JPH096706A (ja) * | 1995-06-22 | 1997-01-10 | Hitachi Ltd | 疎結合計算機システム |
| EP0752652B1 (en) * | 1995-07-03 | 1998-12-16 | Sun Microsystems, Inc. | System and method for implementing a hierarchical policy for computer system administration |
| JP3335801B2 (ja) * | 1995-07-05 | 2002-10-21 | 株式会社日立製作所 | 異種ファイルへのアクセスを可能とする情報処理システム及びその制御方法 |
| JP3756954B2 (ja) * | 1995-07-11 | 2006-03-22 | 株式会社 日立製作所 | サービス提供システム |
| US5933599A (en) * | 1995-07-17 | 1999-08-03 | Microsoft Corporation | Apparatus for presenting the content of an interactive on-line network |
| US5941947A (en) * | 1995-08-18 | 1999-08-24 | Microsoft Corporation | System and method for controlling access to data entities in a computer network |
| US5956509A (en) * | 1995-08-18 | 1999-09-21 | Microsoft Corporation | System and method for performing remote requests with an on-line service network |
| US8065338B2 (en) * | 1995-08-30 | 2011-11-22 | Computer Associates Think, Inc. | Directory searching methods and systems |
| US5764902A (en) * | 1995-09-29 | 1998-06-09 | Intel Corporation | Conditional insert or merge in a data conference |
| US5826027A (en) * | 1995-10-11 | 1998-10-20 | Citrix Systems, Inc. | Method for supporting an extensible and dynamically bindable protocol stack in a distrubited process system |
| US7555529B2 (en) * | 1995-11-13 | 2009-06-30 | Citrix Systems, Inc. | Interacting with software applications displayed in a web page |
| US6370552B1 (en) | 1997-05-14 | 2002-04-09 | Citrix Systems, Inc. | Apparatus and method for displaying application output in an HTML document |
| US6088515A (en) | 1995-11-13 | 2000-07-11 | Citrix Systems Inc | Method and apparatus for making a hypermedium interactive |
| US6950991B2 (en) * | 1995-11-13 | 2005-09-27 | Citrix Systems, Inc. | Interacting with software applications displayed in a web page |
| US6493004B1 (en) * | 1995-11-14 | 2002-12-10 | Microsoft Corporation | Delayed transmission of controls from a server to a client |
| GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
| US6041109A (en) | 1995-12-29 | 2000-03-21 | Mci Communications Corporation | Telecommunications system having separate switch intelligence and switch fabric |
| US6032184A (en) * | 1995-12-29 | 2000-02-29 | Mci Worldcom, Inc. | Integrated interface for Web based customer care and trouble management |
| US6859783B2 (en) | 1995-12-29 | 2005-02-22 | Worldcom, Inc. | Integrated interface for web based customer care and trouble management |
| US6625617B2 (en) | 1996-01-02 | 2003-09-23 | Timeline, Inc. | Modularized data retrieval method and apparatus with multiple source capability |
| US7035914B1 (en) | 1996-01-26 | 2006-04-25 | Simpleair Holdings, Inc. | System and method for transmission of data |
| US5819281A (en) * | 1996-02-26 | 1998-10-06 | Electronic Data Systems Corporation | Notification of aspect value change in object-oriented programming |
| US5862325A (en) * | 1996-02-29 | 1999-01-19 | Intermind Corporation | Computer-based communication system and method using metadata defining a control structure |
| CA2199108C (en) * | 1996-03-05 | 2002-04-23 | Hirotoshi Maegawa | Parallel distributed processing system and method of same |
| US5764915A (en) * | 1996-03-08 | 1998-06-09 | International Business Machines Corporation | Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack |
| US5828843A (en) * | 1996-03-21 | 1998-10-27 | Mpath Interactive, Inc. | Object-oriented method for matching clients together with servers according to attributes included in join request |
| US6463446B1 (en) | 1998-02-26 | 2002-10-08 | Sun Microsystems, Inc. | Method and apparatus for transporting behavior in an event-based distributed system |
| US6446070B1 (en) | 1998-02-26 | 2002-09-03 | Sun Microsystems, Inc. | Method and apparatus for dynamic distributed computing over a network |
| US6182083B1 (en) | 1997-11-17 | 2001-01-30 | Sun Microsystems, Inc. | Method and system for multi-entry and multi-template matching in a database |
| US6185611B1 (en) | 1998-03-20 | 2001-02-06 | Sun Microsystem, Inc. | Dynamic lookup service in a distributed system |
| US6393497B1 (en) | 1998-03-20 | 2002-05-21 | Sun Microsystems, Inc. | Downloadable smart proxies for performing processing associated with a remote procedure call in a distributed system |
| US6598094B1 (en) | 1998-03-20 | 2003-07-22 | Sun Microsystems, Inc. | Method and apparatus for determining status of remote objects in a distributed system |
| US6832223B1 (en) | 1996-04-23 | 2004-12-14 | Sun Microsystems, Inc. | Method and system for facilitating access to a lookup service |
| US6421704B1 (en) | 1998-03-20 | 2002-07-16 | Sun Microsystems, Inc. | Method, apparatus, and product for leasing of group membership in a distributed system |
| US6438614B2 (en) | 1998-02-26 | 2002-08-20 | Sun Microsystems, Inc. | Polymorphic token based control |
| US6138238A (en) | 1997-12-11 | 2000-10-24 | Sun Microsystems, Inc. | Stack-based access control using code and executor identifiers |
| US6938263B2 (en) | 1996-04-23 | 2005-08-30 | Sun Microsystems, Inc. | System and method for facilitating dynamic loading of “stub” information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space |
| US6578044B1 (en) | 1997-11-17 | 2003-06-10 | Sun Microsystems, Inc. | Method and system for typesafe attribute matching |
| US6272559B1 (en) * | 1997-10-15 | 2001-08-07 | Sun Microsystems, Inc. | Deferred reconstruction of objects and remote loading for event notification in a distributed system |
| US6560656B1 (en) | 1998-02-26 | 2003-05-06 | Sun Microsystems, Inc. | Apparatus and method for providing downloadable code for use in communicating with a device in a distributed system |
| US6466947B2 (en) | 1998-03-20 | 2002-10-15 | Sun Microsystems, Inc. | Apparatus and method for dynamically verifying information in a distributed system |
| US6708171B1 (en) | 1996-04-23 | 2004-03-16 | Sun Microsystems, Inc. | Network proxy |
| US6487607B1 (en) | 1998-02-26 | 2002-11-26 | Sun Microsystems, Inc. | Methods and apparatus for remote method invocation |
| US6424991B1 (en) | 1996-07-01 | 2002-07-23 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server communication framework |
| US5987245A (en) | 1996-07-01 | 1999-11-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework |
| US5768510A (en) * | 1996-07-01 | 1998-06-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server application enabler system |
| US5893107A (en) * | 1996-07-01 | 1999-04-06 | Microsoft Corporation | Method and system for uniformly accessing multiple directory services |
| US6038590A (en) | 1996-07-01 | 2000-03-14 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system |
| US6304893B1 (en) * | 1996-07-01 | 2001-10-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system |
| US6266709B1 (en) | 1996-07-01 | 2001-07-24 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server failure reporting process |
| US6434598B1 (en) | 1996-07-01 | 2002-08-13 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system |
| US5848246A (en) | 1996-07-01 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system |
| US6272555B1 (en) | 1996-07-01 | 2001-08-07 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server-centric interprise computing framework system |
| US5999972A (en) | 1996-07-01 | 1999-12-07 | Sun Microsystems, Inc. | System, method and article of manufacture for a distributed computer system framework |
| US5748897A (en) * | 1996-07-02 | 1998-05-05 | Sun Microsystems, Inc. | Apparatus and method for operating an aggregation of server computers using a dual-role proxy server computer |
| US5809247A (en) * | 1996-07-22 | 1998-09-15 | Intel Corporation | Method and apparatus for guided touring of internet/intranet websites |
| US6728737B2 (en) | 1996-10-11 | 2004-04-27 | Sun Microsystems, Inc. | Method and system for leasing storage |
| US5832529A (en) | 1996-10-11 | 1998-11-03 | Sun Microsystems, Inc. | Methods, apparatus, and product for distributed garbage collection |
| US6237009B1 (en) * | 1996-10-11 | 2001-05-22 | Sun Microsystems, Inc. | Lease renewal service |
| US5915001A (en) | 1996-11-14 | 1999-06-22 | Vois Corporation | System and method for providing and using universally accessible voice and speech data files |
| US6061740A (en) * | 1996-12-09 | 2000-05-09 | Novell, Inc. | Method and apparatus for heterogeneous network management |
| US6052778A (en) * | 1997-01-13 | 2000-04-18 | International Business Machines Corporation | Embedded system having dynamically linked dynamic loader and method for linking dynamic loader shared libraries and application programs |
| US6363436B1 (en) | 1997-01-27 | 2002-03-26 | International Business Machines Corporation | Method and system for loading libraries into embedded systems |
| US6263376B1 (en) | 1997-02-24 | 2001-07-17 | Novell, Inc. | Generic run-time binding interpreter |
| US5903894A (en) * | 1997-03-03 | 1999-05-11 | Microsoft Corporation | System and method for using a hierarchical data structure to control and identify devices and represent connections between the devices |
| US6128653A (en) * | 1997-03-17 | 2000-10-03 | Microsoft Corporation | Method and apparatus for communication media commands and media data using the HTTP protocol |
| US5875322A (en) * | 1997-03-31 | 1999-02-23 | International Business Machines Corporation | Making a control available to a computer without installing the control |
| US5940593A (en) * | 1997-03-31 | 1999-08-17 | International Business Machines Corporation | Simulating a multi-tiered computer environment on a single development system for debugging |
| US6198738B1 (en) * | 1997-04-16 | 2001-03-06 | Lucent Technologies Inc. | Communications between the public switched telephone network and packetized data networks |
| US6038599A (en) * | 1997-04-23 | 2000-03-14 | Mpath Interactive, Inc. | Latency server and matchmaker |
| US6023729A (en) * | 1997-05-05 | 2000-02-08 | Mpath Interactive, Inc. | Method and apparatus for match making |
| US6049799A (en) * | 1997-05-12 | 2000-04-11 | Novell, Inc. | Document link management using directory services |
| AU726488B2 (en) * | 1997-05-14 | 2000-11-09 | Citrix Systems, Inc. | System and method for remotely executing an interpretive language application |
| US5941949A (en) | 1997-05-14 | 1999-08-24 | Citrix Systems, Inc. | System and method for transmitting data from a server application to more than one client node |
| US5961586A (en) * | 1997-05-14 | 1999-10-05 | Citrix Systems, Inc. | System and method for remotely executing an interpretive language application |
| EP1011236A3 (en) * | 1997-05-14 | 2000-11-02 | Citrix Systems, Inc. | System and method for remotely executing an interpretive language application |
| US6157944A (en) * | 1997-05-14 | 2000-12-05 | Citrix Systems, Inc. | System and method for replicating a client/server data exchange to additional client notes connecting to the server |
| US7631012B2 (en) | 1997-05-22 | 2009-12-08 | Computer Associates Think, Inc. | System and method of operating a database |
| US6047322A (en) * | 1997-05-27 | 2000-04-04 | Ukiah Software, Inc. | Method and apparatus for quality of service management |
| US5999940A (en) * | 1997-05-28 | 1999-12-07 | Home Information Services, Inc. | Interactive information discovery tool and methodology |
| US5948064A (en) * | 1997-07-07 | 1999-09-07 | International Business Machines Corporation | Discovery of authentication server domains in a computer network |
| US6760746B1 (en) * | 1999-09-01 | 2004-07-06 | Eric Schneider | Method, product, and apparatus for processing a data request |
| US6029201A (en) * | 1997-08-01 | 2000-02-22 | International Business Machines Corporation | Internet application access server apparatus and method |
| US6473407B1 (en) | 1997-09-05 | 2002-10-29 | Worldcom, Inc. | Integrated proxy interface for web based alarm management tools |
| US6714979B1 (en) | 1997-09-26 | 2004-03-30 | Worldcom, Inc. | Data warehousing infrastructure for web based reporting tool |
| US6745229B1 (en) | 1997-09-26 | 2004-06-01 | Worldcom, Inc. | Web based integrated customer interface for invoice reporting |
| US7225249B1 (en) | 1997-09-26 | 2007-05-29 | Mci, Llc | Integrated systems for providing communications network management services and interactive generating invoice documents |
| US6381644B2 (en) | 1997-09-26 | 2002-04-30 | Mci Worldcom, Inc. | Integrated proxy interface for web based telecommunications network management |
| US7058600B1 (en) | 1997-09-26 | 2006-06-06 | Mci, Inc. | Integrated proxy interface for web based data management reports |
| US6763376B1 (en) | 1997-09-26 | 2004-07-13 | Mci Communications Corporation | Integrated customer interface system for communications network management |
| US6615258B1 (en) | 1997-09-26 | 2003-09-02 | Worldcom, Inc. | Integrated customer interface for web based data management |
| US6418461B1 (en) | 1997-10-06 | 2002-07-09 | Mci Communications Corporation | Intelligent call switching node in an intelligent distributed network architecture |
| US6697868B2 (en) * | 2000-02-28 | 2004-02-24 | Alacritech, Inc. | Protocol processing stack for use with intelligent network interface device |
| US6957427B1 (en) | 1997-10-15 | 2005-10-18 | Sun Microsystems, Inc. | Remote object activation in a distributed system |
| US6189101B1 (en) | 1997-10-24 | 2001-02-13 | Richard G. Dusenbury, Jr. | Secure network architecture method and apparatus |
| US6233616B1 (en) * | 1997-10-24 | 2001-05-15 | William J. Reid | Enterprise network management using directory containing network addresses of users obtained through DHCP to control routers and servers |
| US7225463B2 (en) | 1997-10-24 | 2007-05-29 | Dusenbury Jr Richard G | Secure network architecture method and apparatus |
| EP1705563B1 (en) | 1997-11-14 | 2009-03-11 | Microsoft Corporation | Server operating system for supporting multiple client-server sessions and dynamic reconnection of users to previous sessions |
| AU1700299A (en) * | 1997-11-18 | 1999-06-07 | Stellar Computing | Method for establishing a communication connection between two or more users viaa network of interconnected computers |
| US6038611A (en) * | 1998-01-13 | 2000-03-14 | Inverness Systems Ltd. | Method for implementing a user-to-network (UNI) application programming interface (API) |
| JP2002505473A (ja) | 1998-02-26 | 2002-02-19 | サンマイクロシステムズ インコーポレーテッド | 決定性ハッシュでリモートメソッドを識別する方法とシステム |
| US6604127B2 (en) | 1998-03-20 | 2003-08-05 | Brian T. Murphy | Dynamic lookup service in distributed system |
| US6976080B1 (en) * | 1998-03-27 | 2005-12-13 | Hewlett-Packard Development Company, L.P. | Multiple-protocol communication subsystem controller |
| US6912588B1 (en) * | 1998-04-02 | 2005-06-28 | Intel Corporation | System and method for managing client requests in client-server networks |
| US6681327B1 (en) | 1998-04-02 | 2004-01-20 | Intel Corporation | Method and system for managing secure client-server transactions |
| US6067559A (en) * | 1998-04-23 | 2000-05-23 | Microsoft Corporation | Server architecture for segregation of dynamic content generation applications into separate process spaces |
| US6332023B1 (en) * | 1998-06-04 | 2001-12-18 | Mci Communications Corporation | Method of and system for providing services in a communications network |
| US6430571B1 (en) * | 1998-07-16 | 2002-08-06 | International Business Machines Corporation | Multi-frame output form that facilitates internet search and update in a hierarchical database |
| US7305451B2 (en) * | 1998-08-24 | 2007-12-04 | Microsoft Corporation | System for providing users an integrated directory service containing content nodes located in different groups of application servers in computer network |
| US6594698B1 (en) | 1998-09-25 | 2003-07-15 | Ncr Corporation | Protocol for dynamic binding of shared resources |
| GB9821150D0 (en) * | 1998-09-30 | 1998-11-25 | Northern Telecom Ltd | Detection of network topology changes affecting trail routing consistency |
| US6928469B1 (en) | 1998-12-29 | 2005-08-09 | Citrix Systems, Inc. | Apparatus and method for determining a program neighborhood for a client node in a client-server network using markup language techniques |
| US6449650B1 (en) * | 1999-02-01 | 2002-09-10 | Redback Networks Inc. | Methods and apparatus for deploying quality of service policies on a data communication network |
| US6338082B1 (en) * | 1999-03-22 | 2002-01-08 | Eric Schneider | Method, product, and apparatus for requesting a network resource |
| USRE43690E1 (en) | 1999-03-22 | 2012-09-25 | Esdr Network Solutions Llc | Search engine request method, product, and apparatus |
| US9141717B2 (en) | 1999-03-22 | 2015-09-22 | Esdr Network Solutions Llc | Methods, systems, products, and devices for processing DNS friendly identifiers |
| US6901518B1 (en) | 1999-04-08 | 2005-05-31 | Sun Microsystems, Inc. | Method and system for establishing trust in downloaded proxy code |
| US6792605B1 (en) | 1999-06-10 | 2004-09-14 | Bow Street Software, Inc. | Method and apparatus for providing web based services using an XML Runtime model to store state session data |
| WO2000078002A2 (en) * | 1999-06-11 | 2000-12-21 | Microsoft Corporation | Multi-dimensional authoritative names registry in pervasive computing |
| US6477576B2 (en) | 1999-06-17 | 2002-11-05 | International Business Machines Corporation | Methods, systems and computer program products for the automated discovery of a services menu |
| US7010492B1 (en) | 1999-09-30 | 2006-03-07 | International Business Machines Corporation | Method and apparatus for dynamic distribution of controlled and additional selective overlays in a streaming media |
| US8341662B1 (en) | 1999-09-30 | 2012-12-25 | International Business Machine Corporation | User-controlled selective overlay in a streaming media |
| US6711629B1 (en) | 1999-10-18 | 2004-03-23 | Fisher-Rosemount Systems, Inc. | Transparent support of remote I/O in a process control system |
| AU2752201A (en) * | 1999-11-08 | 2001-06-06 | Megaxess, Inc. | Quality of service (qos) negotiation procedure for multi-transport protocol access for supporting multi-media applications with qos assurance |
| AUPQ428499A0 (en) | 1999-11-26 | 1999-12-23 | Computer Associates Pty. Ltd. | A method and apparatus for operating a data base |
| US7149509B2 (en) * | 1999-12-06 | 2006-12-12 | Twenty Year Innovations, Inc. | Methods and apparatuses for programming user-defined information into electronic devices |
| US6496692B1 (en) | 1999-12-06 | 2002-12-17 | Michael E. Shanahan | Methods and apparatuses for programming user-defined information into electronic devices |
| US8170538B2 (en) | 1999-12-06 | 2012-05-01 | Solocron Media, Llc | Methods and apparatuses for programming user-defined information into electronic devices |
| US7065574B1 (en) | 2000-05-09 | 2006-06-20 | Sun Microsystems, Inc. | Messaging system using pairs of message gates in a distributed computing environment |
| US6970869B1 (en) | 2000-05-09 | 2005-11-29 | Sun Microsystems, Inc. | Method and apparatus to discover services and negotiate capabilities |
| US7577834B1 (en) | 2000-05-09 | 2009-08-18 | Sun Microsystems, Inc. | Message authentication using message gates in a distributed computing environment |
| US7716492B1 (en) | 2000-05-09 | 2010-05-11 | Oracle America, Inc. | Method and apparatus to obtain service capability credentials |
| US7010573B1 (en) | 2000-05-09 | 2006-03-07 | Sun Microsystems, Inc. | Message gates using a shared transport in a distributed computing environment |
| US7072967B1 (en) | 2000-05-09 | 2006-07-04 | Sun Microsystems, Inc. | Efficient construction of message endpoints |
| US7260543B1 (en) | 2000-05-09 | 2007-08-21 | Sun Microsystems, Inc. | Automatic lease renewal with message gates in a distributed computing environment |
| US7370091B1 (en) | 2000-05-09 | 2008-05-06 | Sun Microsystems, Inc. | Method and apparatus for obtaining space advertisements |
| US8001232B1 (en) | 2000-05-09 | 2011-08-16 | Oracle America, Inc. | Event message endpoints in a distributed computing environment |
| US6757730B1 (en) | 2000-05-31 | 2004-06-29 | Datasynapse, Inc. | Method, apparatus and articles-of-manufacture for network-based distributed computing |
| US6976066B1 (en) * | 2000-05-22 | 2005-12-13 | Microsoft Corporation | Network and method for implementing network platform services for a computing device |
| WO2002063479A1 (en) * | 2001-02-02 | 2002-08-15 | Datasynapse, Inc. | Distributed computing system |
| AU2001278879A1 (en) * | 2000-07-07 | 2002-02-05 | Science Applications International Corporation | A system or method for calling a vanity number using speech recognition |
| US6959332B1 (en) * | 2000-07-12 | 2005-10-25 | Cisco Technology, Inc. | Basic command representation of quality of service policies |
| US6968179B1 (en) | 2000-07-27 | 2005-11-22 | Microsoft Corporation | Place specific buddy list services |
| US7346842B1 (en) * | 2000-11-02 | 2008-03-18 | Citrix Systems, Inc. | Methods and apparatus for incorporating a partial page on a client |
| FI20002437A (fi) * | 2000-11-07 | 2002-05-08 | Nokia Corp | Palveluvirran ohjaaminen |
| US7194743B2 (en) * | 2000-12-12 | 2007-03-20 | Citrix Systems, Inc. | Methods and apparatus for communicating changes between a user interface and an executing application using property paths |
| US7296275B2 (en) | 2001-01-04 | 2007-11-13 | Sun Microsystems, Inc. | Method and system for passing objects in a distributed system using serialization contexts |
| US20020010715A1 (en) * | 2001-07-26 | 2002-01-24 | Garry Chinn | System and method for browsing using a limited display device |
| US7756969B1 (en) | 2001-09-07 | 2010-07-13 | Oracle America, Inc. | Dynamic provisioning of identification services in a distributed system |
| US7660887B2 (en) | 2001-09-07 | 2010-02-09 | Sun Microsystems, Inc. | Systems and methods for providing dynamic quality of service for a distributed system |
| US7305458B2 (en) * | 2003-04-22 | 2007-12-04 | Accton Technology Corporation | System and method for auto-configuring stackable network devices |
| US7113981B2 (en) * | 2003-12-29 | 2006-09-26 | Mixxer, Inc. | Cellular telephone download locker |
| US7792874B1 (en) | 2004-01-30 | 2010-09-07 | Oracle America, Inc. | Dynamic provisioning for filtering and consolidating events |
| US7519718B2 (en) | 2004-02-27 | 2009-04-14 | International Business Machines Corporation | Server-side protocol configuration of accessing clients |
| JP2005352689A (ja) * | 2004-06-09 | 2005-12-22 | Hitachi Ltd | 対話型サービス配置方法、対話型サービス配置プログラムおよびその記録媒体、ならびに、サービスブローカ装置 |
| US7207112B2 (en) * | 2005-01-12 | 2007-04-24 | Wen-Ya Yeh | Combination hairdressing scissor assembly |
| US7353034B2 (en) | 2005-04-04 | 2008-04-01 | X One, Inc. | Location sharing and tracking using mobile phones or other wireless devices |
| US7587705B2 (en) * | 2005-04-29 | 2009-09-08 | Sap (Ag) | Calls and return calls using client interfaces |
| US7634771B2 (en) * | 2005-04-29 | 2009-12-15 | Sap (Ag) | Object generation in packages |
| US7669181B2 (en) * | 2005-04-29 | 2010-02-23 | Sap (Ag) | Client interfaces for packages |
| WO2007024830A2 (en) * | 2005-08-23 | 2007-03-01 | Matsushita Electric Industrial Co. Ltd. | Method and system for peer-to-peer services architecture and framework |
| US8738703B2 (en) | 2006-10-17 | 2014-05-27 | Citrix Systems, Inc. | Systems and methods for providing online collaborative support |
| US7853669B2 (en) * | 2007-05-04 | 2010-12-14 | Microsoft Corporation | Mesh-managing data across a distributed set of devices |
| US8908700B2 (en) | 2007-09-07 | 2014-12-09 | Citrix Systems, Inc. | Systems and methods for bridging a WAN accelerator with a security gateway |
| US9332068B2 (en) * | 2007-11-29 | 2016-05-03 | Ooma, Inc. | Mechanisms for transparently converting client-server software agents to peer-to-peer software agents |
| US8484174B2 (en) * | 2008-03-20 | 2013-07-09 | Microsoft Corporation | Computing environment representation |
| US9298747B2 (en) * | 2008-03-20 | 2016-03-29 | Microsoft Technology Licensing, Llc | Deployable, consistent, and extensible computing environment platform |
| US8572033B2 (en) | 2008-03-20 | 2013-10-29 | Microsoft Corporation | Computing environment configuration |
| US9753712B2 (en) * | 2008-03-20 | 2017-09-05 | Microsoft Technology Licensing, Llc | Application management within deployable object hierarchy |
| US20090248737A1 (en) * | 2008-03-27 | 2009-10-01 | Microsoft Corporation | Computing environment representation |
| JP2012504261A (ja) * | 2008-06-09 | 2012-02-16 | モビゾフト エービー | ユーザ要求により開始されるデータファイル送信 |
| KR101040396B1 (ko) | 2009-01-20 | 2011-06-09 | 한올바이오파마주식회사 | 변형된 인간 트롬보포이에틴 폴리펩타이드 절편 및 그의 제조방법 |
| US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4821220A (en) * | 1986-07-25 | 1989-04-11 | Tektronix, Inc. | System for animating program operation and displaying time-based relationships |
| US4885717A (en) * | 1986-09-25 | 1989-12-05 | Tektronix, Inc. | System for graphically representing operation of object-oriented programs |
| DE3889904T2 (de) * | 1987-09-08 | 1995-01-12 | Digital Equipment Corp | Namensverwaltung für ein digitaldatenverarbeitungssystemnetzwerk. |
| US4891630A (en) * | 1988-04-22 | 1990-01-02 | Friedman Mark B | Computer vision system with improved object orientation technique |
| US4953080A (en) * | 1988-04-25 | 1990-08-28 | Hewlett-Packard Company | Object management facility for maintaining data in a computer system |
| EP0347162A3 (en) * | 1988-06-14 | 1990-09-12 | Tektronix, Inc. | Apparatus and methods for controlling data flow processes by generated instruction sequences |
| US5041992A (en) * | 1988-10-24 | 1991-08-20 | University Of Pittsburgh | Interactive method of developing software interfaces |
| US5133075A (en) * | 1988-12-19 | 1992-07-21 | Hewlett-Packard Company | Method of monitoring changes in attribute values of object in an object-oriented database |
| US5050090A (en) * | 1989-03-30 | 1991-09-17 | R. J. Reynolds Tobacco Company | Object placement method and apparatus |
| US5060276A (en) * | 1989-05-31 | 1991-10-22 | At&T Bell Laboratories | Technique for object orientation detection using a feed-forward neural network |
| US5125091A (en) * | 1989-06-08 | 1992-06-23 | Hazox Corporation | Object oriented control of real-time processing |
| US5257369A (en) * | 1990-10-22 | 1993-10-26 | Skeen Marion D | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US5181162A (en) * | 1989-12-06 | 1993-01-19 | Eastman Kodak Company | Document management and production system |
| US5093914A (en) * | 1989-12-15 | 1992-03-03 | At&T Bell Laboratories | Method of controlling the execution of object-oriented programs |
| US5075848A (en) * | 1989-12-22 | 1991-12-24 | Intel Corporation | Object lifetime control in an object-oriented memory protection mechanism |
| AU628753B2 (en) * | 1990-08-14 | 1992-09-17 | Digital Equipment Corporation | Method and apparatus for implementing server functions in a distributed heterogeneous environment |
| US5151987A (en) * | 1990-10-23 | 1992-09-29 | International Business Machines Corporation | Recovery objects in an object oriented computing environment |
| US5119475A (en) * | 1991-03-13 | 1992-06-02 | Schlumberger Technology Corporation | Object-oriented framework for menu definition |
| US5307490A (en) * | 1992-08-28 | 1994-04-26 | Tandem Computers, Inc. | Method and system for implementing remote procedure calls in a distributed computer system |
| US5396630A (en) * | 1992-10-06 | 1995-03-07 | International Business Machines Corporation | Method and system for object management across process boundries in a data processing system |
-
1993
- 1993-12-17 US US08/169,867 patent/US5548726A/en not_active Expired - Lifetime
-
1994
- 1994-04-11 DE DE69405405T patent/DE69405405T2/de not_active Expired - Lifetime
- 1994-04-11 CA CA002178583A patent/CA2178583A1/en not_active Abandoned
- 1994-04-11 WO PCT/US1994/003978 patent/WO1995017062A1/en active IP Right Grant
- 1994-04-11 AU AU67024/94A patent/AU6702494A/en not_active Abandoned
- 1994-04-11 JP JP51672595A patent/JP3839472B2/ja not_active Expired - Lifetime
- 1994-04-11 EP EP94914760A patent/EP0726004B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09506725A (ja) | 1997-06-30 |
| EP0726004A1 (en) | 1996-08-14 |
| CA2178583A1 (en) | 1995-06-22 |
| WO1995017062A1 (en) | 1995-06-22 |
| DE69405405T2 (de) | 1998-03-26 |
| US5548726A (en) | 1996-08-20 |
| EP0726004B1 (en) | 1997-09-03 |
| AU6702494A (en) | 1995-07-03 |
| DE69405405D1 (de) | 1997-10-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3839472B2 (ja) | オブジェクト指向ルール・ベース・プロトコル・システム | |
| US6360266B1 (en) | Object-oriented distributed communications directory system | |
| US5594921A (en) | Authentication of users with dynamically configurable protocol stack | |
| US5832219A (en) | Distributed object networking service | |
| EP0726003B1 (en) | Object-oriented network protocol configuration system | |
| Mascolo et al. | XMIDDLE: A data-sharing middleware for mobile computing | |
| US5499343A (en) | Object-oriented networking system with dynamically configurable communication links | |
| AU2002319843B2 (en) | General and reusable components for defining net-centric application program architectures | |
| US5515508A (en) | Client server system and method of operation including a dynamically configurable protocol stack | |
| EP1300757A1 (en) | Shareable installation hierarchies | |
| AU2002319843A1 (en) | General and reusable components for defining net-centric application program architectures | |
| AU2005201341A1 (en) | System and method for sharing objects between computers over a network | |
| JPH04229357A (ja) | 異種ネットワーク環境における適用業務プログラムの統合システム | |
| US20040060055A1 (en) | Method and system for dynamic configuration of interceptors in a client-server environment | |
| WO2002037230A9 (en) | A method and system for application development and a data processing architecture utilizing destinationless messaging | |
| Chunlin et al. | A mobile agent platform based on tuple space coordination | |
| EP1627301A2 (en) | Non blocking persistent state machines on enterprise java bean platform | |
| Baentsch et al. | WebMake: Integrating distributed software development in a structure-enhanced Web | |
| Cherrueau et al. | Geo-distribute cloud applications at the edge | |
| An et al. | Design and implementation of a dynamic protocol framework | |
| O'Grady | Flexible data sharing in a groupware toolkit. | |
| WO1995016956A1 (en) | Object-oriented rule-based directory system | |
| Lawler | Distributed architecture for the object-oriented method for interoperability | |
| CA2551059C (en) | Pipeline architecture for use with net-centric application program architectures | |
| Trichkov et al. | Integrated information system based on web services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050329 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050629 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050815 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050929 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051206 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060306 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060424 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060606 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060725 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060803 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090811 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100811 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100811 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100811 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110811 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110811 Year of fee payment: 5 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D04 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110811 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120811 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130811 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |