JP2000505921A - 分散オペレーティング・システム - Google Patents

Abstract

(57)【要約】 本発明は、各々のライブラリがそれぞれ空間的場所に存在し、かつ該各ライブラリが異なる複数のトピックについてのインスタンス集合と関連をもっている、これらライブラリの集合を有し、前記各トピックは、システム・リソースのカプセル化されたセットであり、アプリケーション、データベース、ソフトウエア成分、又はその他の論理的に関連したファイルの集合を含むファイル・システムを有しており、同一トピックの複数のインスタンスは、それぞれ異なるライブラリに存在すると共に、該各インスタンスは任意の時に任意のライブラリに存在し得る、ネットワーク用の分散オペレーティング・システムにおいて、第１及び第２のグローバルで唯一の識別子からなるアドレス付与基準を前記ライブラリ及びトピックに適用し、前記第１のグローバルで唯一の識別子は各ライブラリを識別するために使用し、前記第２のグローバルで唯一の識別子は各トピックを識別するために使用する、分散オペレーティング・システムを提供する。トピックの各インスタンスは、どのライブラリに属していても同一のトピック識別子を有する。前記アプリケーション、ソフトウエア成分、及び異なる複数のライブラリにおける複数のトピックとして保存された書類の、相互対話を可能とするコミュニケーション・プロトコルがライブラリの外部に存在する。

Description

【発明の詳細な説明】 分散オペレーティング・システム ［技術分野］ 本発明は、分散オペレーティング・システムに関する。オペレーティング・シ ステムとはコンピュータを動作させる主制御プログラムのことである。これらオ ペレーティング・システムは、コンピュータのシステム内で動作するアプリケー ションプログラムに対して動作基準を設定するため、コンピュータのシステムに おける重要な要素となっている。全てのプログラムはオペレーティング・システ ムと「対話」することが必要である。 ［背景技術］ 大部分の最近のコンピュータシステムにおけるアーキテクチャでの中心的特徴 の１つに、どのオペレーティング・システムも、該システムが管理するデータ及 びアプリケーションに対して単一の名前空間を定義するということがある。例え ば、オペレーティング・システムによって定義された名前空間には、ファイルを 位置づけるためのファイル・システム又はディレクトリ構造体、ファイルを開く ための識別子、共通ソフトウエア成分、及びその他のネットワーク・リソースが 含まれる。 このようなシステムにおいて、ファイルは情報格納の基本単位である。具体的 に、ファイルは、１単位のデータを含むか、または１機能（アプリケーション又 はソフトウエア成分）を含んでいる。データファイルに対しては、前記オペレー ティング・システムが適切なアプリケーションを各ファイルと関係づけることに より、該ファイルの内容は閲覧或いは更新可能となる。 アプリケーションはオブジェクト指向ソフトウエア成分を統合したもの によって構築されている。これらオブジェクト指向ソフトウエアは、特定のアプ リケーションとしてカスタマイズされたり、或いは、多数の異なるアプリケーシ ョンにおける共通成分として使用できるように設計することが可能である。 複合ファイルが開発され、アプリケーション内の様々なオブジェクト指向成分 が、単一ファイル内においてデータを独立して読み書きすることができるように なった。この複合ファイルは、１単位の情報（書類）を構成する様々なオブジェ クト（複数単位のデータ）を格納するための効果的な方法ではあるが、大きな複 合ファイルをネットワーク上に配布することは、困難かつ時間のかかることにな り得る。そのため、書類を小さなファイルの集まりに分割することでインターネ ット（又はイントラネット）書類を構築する工業規格（HTMLやJava等）が広く普 及している。 論理的に関係づけられた複数のファイルの集合を特定することのできる画一化 された方法は、公知のオペレーティング・システムでは存在しない。つまりオペ レーティング・システムは、インターネット（又はイントラネット）書類のグル ープ、共通ソフトウエア成分(複数組合わされた実行可能なモジュール、テンプ レート、サンプル及び関連した書類、を含む)、又は大きなデータベースのよう な、多数のファイルに及ぶ情報の集合を特定し又は管理することができないので ある。 パスと呼ばれる物理的アドレスはファイルをディレクトリ構造体において位置 づけるのに用いられる。このパスは、情報を位置づけることと、情報を構築する こと、といった相違なる２つの目的で使用される。情報を再構築するにはディレ クトリ構造体内でファイルを移動させねばならず、ファイルの移動により、アプ リケーションが情報を位置づけるために使用するパスを変化させる。 各オペレーティング・システムは単一の名前空間しか定義できないので、 オペレーティング・システム内において、いつの時点でどの名前が使用されるか ということを予知することは不可能である。つまり、特定のシステム・リソース と関連した名前は時々刻々と変化しているのである。例えば、大部分のアプリケ ーションに設定されているインストール手続では、エンドユーザによって関連フ ァイルの格納ディレクトリが選択され得るようになっている。 ファイルと関連した名前には特別な意味は無いので、この名前だけでは、オペ レーティング・システムには、情報がネットワークを経由してどのように配布さ れているのかを認識することができない。即ち、データ、ソフトウエア成分、及 びアプリケーションの、ネットワークを経由した配布を管理するためには、複合 的なアプリケーションが開発されなければならない。 ローカル・エリア・ネットワーク（ＬＡＮ）は、複数のコンピュータからなる グループ上での個々のファイルを、更なる別のＬＡＮサーバにおける共有ファイ ルとなるように拡張させている。ＬＡＮサーバ上のファイルは、該ＬＡＮに接続 されたどのコンピュータからも閲覧及び更新が可能である。このＬＡＮは、１つ のオペレーティング・システムによって定義された名前空間を、複数のＬＡＮサ ーバ上の選択されたリソースが含まれるように拡張することから、独立型コンピ ュータシステムから論理的に進化した段階であると言える。 しかしＬＡＮに関する基本的な問題として、該ＬＡＮに接続された各コンピュ ータがそれぞれ異なる名前空間を定義しているということがある。１つのコンピ ュータにおけるリソースに新規の名前を作成し、別のコンピュータ用に定義され た名前空間に割り当てるようにする必要がある。各ワーク・ステーションが複数 の共通ネットワーク・リソースに対して異なる名前を定義するとなると、ＬＡＮ での保守が非常に困難となり得る。この 問題は、ＬＡＮワーク・ステーションの構成定義に対して汎用的な共通基準を定 義することで解決できる。しかしこれら基準を保守するには大がかりな共通シス テム管理が必要となり、エンドユーザにとっては不都合となることが多い。また 、ＬＡＮについての更に重要な問題として、前記共通基準は比較的小規模のワー ク・グループにおいてのみ効果的に作用し得るということがある。 グローバル・コミュニケーションの道具としてのワールド・ワイド・ウエブ（ ＷＷＷ）は、「サーバ・ドメイン・ネーム」と呼ばれる、グローバル（世界規模 ）で唯一の識別子に基づくアドレス付与機構を使用することに成功している。個 々のサーバ・ドメイン・ネームは、インターネット（又はイントラネット）・リ ソースに対して個々の名前空間を定義している。サーバ・ドメイン・ネームによ り、インターネット（又はイントラネット）に接続された独立型コンピュータ（ 又はＬＡＮ）が定義した名前空間にマップ（map）が提供される。インターネッ ト（又はイントラネット）で使用されるこのアドレス付与機構は、ユニバーサル ・リソース・ロケータ（ＵＲＬ）と呼ばれ、サーバ・ドメイン・ネームをパスに 連結することにより構築されている。 インターネット（又はイントラネット）は、ネットワーク・リソースに名前を 付与する際に、同一のグローバルな基準を使用する「ＬＡＮ」として定義できる ので、前記ＬＡＮから論理的に進化した段階であると言える。各情報単位が単一 のサーバ・ドメイン・ネームにより定義された名前空間内にもっぱら存在するな らば、そして各サーバ・ドメイン・ネームに関連した情報が再構築されなければ 、ＵＲＬは情報交換において効果的な道具である。しかしインターネットを使用 する者なら誰でもわかるように、このＵＲＬは、数年間だけ使用された廃リンク に対しても割り当てられたままとなっている。更にこのＵＲＬでは、複数のサー バ・ドメインを経て複 製された情報を認識するための機構が何も提供されない。ＬＡＮの場合と同様に 、インターネット（又はイントラネット）を介しての情報配布を管理するために 、複合的な（そして特別の）アプリケーションが提供されねばならない。 オブジェクト指向ソフトウエア開発においては、統合されて複合的なアプリケ ーションに形成され得る１群の基準ソフトウエア成分を定義することが目的の１ つとなっている。長年にわたりコンピュータ・ハードウエア産業の基礎となって いたモジュール化手法と同様の手法をソフトウエア産業に導入するという考え方 である。この目的を達成するにあたりソフトウエア産業にとっての根本的な障害 の１つに、複数ある最近のオペレーティング・システムはそれぞれ異なる命名規 則を使用しているという事実がある。結果として、ディレクトリ構造体内で特定 のソフトウエア成分を検索する信頼できる方法が存在しない。 マイクロソフト社はこの問題を、ウインドウズ９５及びウインドウズＮＴにお いて、システム・レジストリを構築することで解決している。ソフトウエア成分 がインストールされる際に、様々な項目がシステム・レジストリに作成され、該 成分の位置づけ及び活性化が可能となっている。この成分がシステムから削除さ れる際には、システム・レジストリ内の前記様々な項目も削除されるようになっ ている。同様なアプローチが、オブジェクト・マネジメント・グループ（ＯＭＧ ）によって定義された共通オブジェクト・リクエスト・ブローカ・アーキテクチ ャ（ＣＯＲＢＡ）によっても使用されている。複合分散システムを構築するのに 使用される際、この方法にはいくつかの制限がある。 システム・レジストリは保守している様々なレジストリ項目を認識しないので 、オペレーティング・システム内にインストールされた様々なソフトウエア成分 やアプリケーションにより適宜更新する方法に依存するしか ない。この方法は比較的静的な構成を保守しているオペレーティング・システム には効果的であるが、大きくて継続的に変化するネットワーク環境で用いるオペ レーティング・システムに対しては非現実的である。 ウインドウズ９５のシステム・レジストリは、「ＣＬＳＩＤ」と呼ばれる、グ ローバルで唯一の識別子を使用して共通ソフトウエア成分を位置づけている。し かしウインドウズ９５のシステム・レジストリにおいて使用されるＣＬＳＩＤは 、以下のような問題を有している。 ＣＬＳＩＤはソフトウエア成分に対してのみ定義されている。データファイル は、システム・レジストリ内で項目を作成又は保守することができないので、デ ータファイルを位置づけするのにこのシステム・レジストリを使用することはで きない。 システム・レジストリは、オペレーティング・システムの名前空間において、 ソフトウエア成分のためのＣＬＳＩＤをリソース名（例えばパス）と関連づける ことによりアドレス付与機構として作用する。システム・レジストリが定義する アドレス付与機構は個々のオペレーティング・システムの範囲内でのみ有効であ るので、該システム・レジストリを分散システムを構築する際に使用するには支 障がある。別のオペレーティング・システムに対して定義されたシステム・レジ ストリの項目を読み取ることができても、読み取り結果は意味をなさないもので ある。 ＣＬＳＩＤはソフトウエア成分内の最上位のオブジェクトを識別するので、該 オブジェクトのインスタンスが生成される。ＣＬＳＩＤは、成分の位置づけ及び インスタンス生成に対する方法を提供するが、該成分を作成する全てのリソース （大部分のファイル）を識別することはない。つまり、ＣＬＳＩＤは、ネットワ ークを介した情報の配布を管理する際に使用するには支障がある。 マイクロソフト社のＯＬＥやアクティブＸプロトコルは、ソフトウエア 成分の統合に対してマイクロソフト社が定義した方法である。これら両プロトコ ルはマイクロソフト社の構成要素オブジェクト・モデル（「ＣＯＭ」と称する）を 基礎としたものであり、ＯＬＥプロトコルは、単一のオペレーティング・システ ム内で動作する機能及びアプリケーションの開発に有効利用されてきた。一方の アクティブＸプロトコルは、インターネット（又はイントラネット）・サイトの 開発に有効利用されてきた。 ＯＬＥ及びアクティブＸプロトコルは２つの基本的機能をサポートしている。 即ち、アプリケーションがソフトウエア成分を活性化できるようにする一連の機 能と、アプリケーションが、成分ファイルの作成、読み取り、更新を行えるよう にする機能である。これらのプロトコルはシステム・レジストリを使用して個々 のソフトウエア成分を位置づけるので、上述したような該システム・レジストリ における問題により不都合なものとなり、これらプロトコルも非常に複雑なもの となる。 このＯＬＥ及びアクティブＸプロトコルにより、ネットワークを巨大なオペレ ーティング・システムと同等なアーキテクチャとしてみなすことができる。マイ クロソフト社のローカル／リモート・トランスピアランシー（Local/Remote Tra nsparency）という概念は本質的には、複数の分散リソースを１つのオペレーテ ィング・システムの名前空問に割り当てる方法である。ＣＯＭでは、システムに おける全ての成分は、ネットワーク上の唯一の位置に存在しており、アプリケー ションはこれら分散成分を結合させることにより構築されるとしている。データ ベース技術（Oracle、IBM、Informix、Sybaseによって提供されているものを含 む）は、１群のファイル及び共通ソフトウエア成分からなる。この共通ソフトウ エア成分により、他のアプリケーションに対してもファイル中の情報にアクヤス 可能とさせる特別なデータベース・アクセス方法が提供されている。データベー スとは、情報の集合をカプセル化してできた名前空間として説明すること ができる。関係データベースが成功したのは、主に、関係型アクセス方法により データベースに格納された全てのデータが他のデータ名で使用可能となるという 事実のおかげである。 しかし、最近のデータベース技術には、データベースの使用前にデータベース の構造（データタイプ及びインデックス）が定義されねばならないといったよう ないくつかの問題がある。データベースの構造を定義するには、多大な時間と熟 練が必要であるので、多大でかつ反復したビジネス活動が可能な場合にのみ行う ことができる。また、各データベースはカスタムされた名前空間を定義するので 、データベースを使用する人は誰でも、該データベースがどのように構築されて いるのかを理解する必要がある。 個々に定義されたデータベースによって、互いに異なり画一性の無い名前空間 が提供されることがある。この問題を解決するために、汎用性が強化され、情報 管理に対する更なる共通基準が開発されている。 ロータス・ノーツ（最近「ロータス・ドミノ」と改名された）・ネットワーク は、ロータス・ノーツ・サーバと多数のクライアントからなる。これらサーバと クライアントは所有権を主張できるソフトウエアを運用しなければならず、デー タベースはクライアント又はサーバのうちいずれかのマシンに格納可能である。 ロータス・ノーツにより、複数グループの個別ユーザが互いに情報を共有するこ とができる環境が提供される。この環境内において書類を閲覧し或いは編集する には、ユーザは指定及びクリックを行うだけでよい。ノーツの環境で作成されて いない書類へのアクセスは、オブジェクト・リンキング（Object Linking）及び エンベッディング（Embedding）をサポートするアプリケーションに限られる。 しかし、所定のプラットフォームに限定されるという事実はあるが、ノーツは更 なる共通データベースのいくつかに対しての先駆けとなっている。 このロータス・ノーツの環境は、組織上の情報に対する、閉鎖され、カ テゴリー化され、インデックス化された基準である。これにより個々のユーザが チームの一部として働けるようになっており、単一の書類及び共有機能に対して 複数のユーザがアクヤスできるようになっている。各データベースのアイコンは 、キー項目によって格納され論理的に関連づけられた書類の集まりを意味してい る。これらの書類は、組織内の他のユーザと情報を共有しようとしている個々の ユーザによって追加できる。 組織内の個々のユーザやグループに対してロータス・ノーツは、情報の公開及 び、書類に対するコメント、編集、更新の機会を提供している。また、書類の論 理的グループ化を行う機能を提供している。しかしこれによると、組織のネット ワーク内のユーザに限定される。 ロータス・ノーツ及びその他の大部分のワーク・グループ・システムは、基本 的には、ワーク・グループ・アプリケーションの特定サイトをサポートするよう に設計されたデータベース技術である。これらワーク・グループ・アプリケーシ ョンは広範囲にわたる機能をサポートしてはいるが、データベース技術における 問題を残している。即ち、大部分のワーク・グループ・システムは開設及び保守 に費用がかかるということである。この関連の費用のため、大部分のワーク・グ ループ・システムは、多大でかつ反復したビジネス活動の支えがあって初めて行 うことができる。 ソフトウエアをＬＡＮを介して（広域通信ネットワークを介することもある） 配布するプロセスを自動化する製品が、インテル・コーポレーション社のLANDes kを含めていくつか存在する。これらのシステムが効果的に動作するためには、 ＬＡＮワーク・ステーションの構成に対して、更に多くの共通基準が定義されね ばならない。そして、このネットワーク管理ツールは、前記共通基準に含まれる アプリケーションの配布を管理するように形成されねばならない。 基本的にネットワーク管理ツールは、各ワーク・ステーションにアクセ スしソフトウエアを更新インストールするプロセスを強化するという別の作業を 自動化するようになっている。これらのツールで、ソフトウエアを配布するのに 係るコストは削減されるが、元々あるソフトウエア配布プロセスに関する別の問 題は残している。例えば、ネットワーク管理ツールは中央情報技術サポートグル ープによってインストールされ管理されねばならず、該中央サポートグループは 、ＬＡＮに接続された各ワーク・ステーションのためにハードウエア及びソフト ウエア財産を保守しなければならない。中央サポートグループに係るコストのた めに、ネットワーク管理ツールは、組織において広く使用されるアプリケーショ ンの場合にだけ、そのコストと見合うことができる。 ネットワーク管理ツールは、配布しているアプリケーションに関する如何なる 特有の情報も有していない。このツールは、アプリケーションを作成する更新フ ァイルを単にコピーし、選択された更新を関連する構成上のファイルに加える。 ネットワーク管理ツールは、高度にカスタマイズされた配布プロセスが要求され るアプリケーションをサポートすることはできない。 ネットワーク管理ツールは、多数のワーク・ステーションにインストールされ 、かつ常に静的な情報を配布するようにだけ設計されている。書類がネットワー クを介して予知できない場所と時間において作成され更新される場合には、ネッ トワーク管理ツールを用いて書類を配布することはできない。 以上のように、どのように名前を定義し、どのようにデータを配布するのかと いう観点から、様々なアプリケーションについて述べてきた。大部分の最近のア プリケーションは、特定のビジネス・ニーズに合ったカスタムされた名前を定義 することにより、数々の自動化を実現している。異なるアプリケーションによっ て、また異なるオペレーティング・システムに よって定義された様々な名前を統合し融合するため、最近のオペレーティング・ システムは益々複雑になってきている。 ［発明の概要］ 新しく考えられた本発明は、各々のライブラリがそれぞれ空間的場所に存在し 、かつ該各ライブラリが異なる複数のトピックについてのインスタンス集合と関 連をもっている、これらライブラリの集合を有し、前記各トピックは、システム ・リソースのカプセル化されたセットであり、アプリケーション、データベース 、ソフトウエア成分、又はその他の論理的に関連したファイルの集合を含むファ イル・システムを有しており、同一トピックの複数のインスタンスは、それぞれ 異なるライブラリに存在すると共に、該各インスタンスは任意の時に任意のライ ブラリに重複することなく存在し得る、ネットワーク用の分散オペレーティング ・システムにおいて、第１及び第２のグローバルで唯一の識別子からなるアドレ ス付与基準を前記ライブラリ及びトピックに適用し、前記第１のグローバルで唯 一の識別子は各ライブラリを識別するために使用し、前記第２のグローバルで唯 一の識別子は各トピックを識別するために使用する、分散オペレーティング・シ ステムを提供する。トピックの各インスタンスは、どのライブラリに属していて も同一のトピック識別子を有する。前記アプリケーション、ソフトウエア成分、 及び異なる複数のライブラリにおける複数のトピックとして保存された書類の、 相互対話を可能とするコミュニケーション・プロトコルがライブラリの外部に存 在する。 本発明によると、書類や共通ソフトウエア成分のような独立して作成された情 報を結合して統合システムを形成することが、複雑なアドレス翻訳の必要なく可 能となるという効果を奏する。 また本発明によると、１つのシステムから別のシステムに情報がコピーされる 際に、該情報の識別が可能となる。情報がネットワークを介してど のように配布されているのかを認識できるので、ソフトウエア配布や目録管理と いったネットワークの保守作業は非常に簡単なものとなる。また本発明によると 、配布されることで有用となるアプリケーションの新しいクラスの開発が可能に なる。 トピックは書類であってもよい。書類の各インスタンスは該書類の最新バージ ョンを含んでもよく、更に該書類についての１つまたはそれ以上の旧バージョン を含んでもよい。該書類の様々なインスタンスに対する更新は要求に応じて配布 される。 トピックはアプリケーション（又はソフトウエア成分）であってもよい。アプ リケーションの各インスタンスは該アプリケーションの完全コピーを含んでいる 。各アプリケーションのインスタンスに対する更新は要求に応じて配布される。 トピックはフォーラムであってもよい。フォーラムの１つのインスタンスは該 フォーラムの完全コピーを含んでいる。残りのインスタンスによりエンドユーザ は、ネットワークを介して該フォーラムを参照したり該フォーラムにコメントを 加えることができる。 トピックはデータベースであってもよい。フォーラムと同様に、トピックの１ つのインスタンスは該データベースの完全コピーを含んでいる。また残りのイン スタンスによりエンドユーザは、ネットワークを介して該データベースにアクセ スできる。 トピックはイメージ記録書類であってもよい。該トピックの様々なインスタン スにより、表示のための書類イメージの収集及び配布を管理する。追加更新が要 求に応じてイメージ記録書類の各インスタンスに配布される。 各アプリケーションがトピック内にカプセル化されている。共通ソフトウエア 成分を使用するためには、アプリケーションが複数のライブラリ・サービス（Li brary services）を用いて前記ソフトウエア成分を含むトピ ック内の適切なリソースを参照することができる。ライブラリにより、前記参照 されたトピックが別のライブラリ内にあると判断されると、同様なネットワーク ・サービスを用いて前記外部のライブラリに要求を送ることができる。このプロ セスを用いることで、アプリケーション及びソフトウエア成分はどちらも、外部 のトピックが参照できるための特別な手段は必要ない。 トピックＩＤは配布されたアプリケーションに対するグローバルで唯一の識別 子であるので、アプリケーションがライブラリ（又はネットワーク）に特定のト ピックＩＤのインスタンスを検索させる。データベースのインスタンスがローカ ルのライブラリで利用可能ならば、該ローカルのインスタンスを使用することで 十分なデータベース参照が可能である。データベースにおけるローカルのインス タンスでは要求を直接満たすことができない場合は、該ローカルのインスタンス は、データベースにおける外部のインスタンスの代理として動作することができ る。トピックのローカルのインスタンスが見つからない場合は、ライブラリは、 共有ライブラリに命じてリストを検索し、データベースにおける適切な外部のイ ンスタンスを見つける。 複数のトピックは、祖先トピック及び子孫トピックからなる階層構造に組織さ れてもよい。アドレス付与基準は、トピックを位置づけするライブラリ構造に依 存しないので、ライブラリはトピックをどのような構造（階層行列、など）に組 織してもよい。様々なエンドユーザに対して、ライブラリをカスタム表示するた め、該ライブラリは多重組織構造を同時にサポートしてもよい。 特定のエンドユーザだけにライブラリを閲覧させるようにすることで、十分な レベルのアクセス権限を持たないエンドユーザに対してトピックを隔離すること ができる。異なるアクセス・レベルが、トピックへのアドレ ス及び組織構造の閲覧に対して定義され得る。ソフトウエア成分を含むトピック はエンドユーザが閲覧するライブラリに表示されないようにすることも可能であ り、エンドユーザは、ソフトウエア成分を参照するためのアプリケーションを使 用するようにしてもよい。 バージョンを管理するには２つの基本的な処理がある。バージョンはトピック をコピーすることにより作成されること、成いはバージョン管理はトピック内で 形成されることである。トピックをコピーすることにより新しいバージョンが作 成されると、様々なバージョンのトピック間で従属関係が定義されるので、これ に関連した調整作業が簡単化できる。 或いは、トピックはバージョン管理を伴う書類を含んでもよい。書類の特定バ ージョンは単一の複合ファイル又は単一のサブディレクトリに含まれてもよい。 書類の新しいバージョンが作成される際には、これらは同一のトピック内で、追 加の複合ファイル又はサブディレクトリに格納され得る。またトピックは、様々 なバージョンの書類に対して提供されたコメントを統合し格納するのに使用され 得る。このようなトピックの配布により、最新バージョンの書類、旧バージョン の書類、及び関連したコメントを含む新しいインスタンスを形成すること（又は 既存のインスタンスを更新すること）ができる。 ソフトウエア成分に対するバージョン管理は個別に行われる。ソフトウエア開 発環境は、新しいソフトウエア成分及びアプリケーションを含む新しいトピック を生成するライブラリとして準備されてもよい。更に、各ソフトウエア成分（又 はアプリケーション）の複数のバージョンが、各トピック内でサポートされても よい。このようなトピックの配布により、最新バージョンのソフトウエア成分（ 又はアプリケーション）を含む新しいインスタンスを作成すること（又は既存の インスタンスを更新すること）ができる。この方法により、全てのソース・コー ド、実行可能なモジュール、 書類、特定のソフトウエア成分に対するインストール手続が、単一のトピック内 でカプセル化される。この方法により、各ソフトウエア成分に関連したトピック ＩＤ及び名前が初期形成から配布されるまで一定となるので、テスト環境の開発 が簡単になり、ソフトウエア成分の信頼性が向上する。 ライブラリはトピックを「信頼できるトピック」又は「疑わしいトピック」に 識別できる。各ライブラリは、トピックが信頼できるライブラリ上の信頼できる トピックから配布されている場合には、該トピックを信頼できるトピックとして 識別できる(或いは、権限のあるエンドユーザによって信頼できるトピックと識 別できる)。各ライブラリは、信頼できるアプリケーション及びソフトウエア成 分の配布元である信頼できるライブラリの簡単なリストを保持している。１つの ライブラリによって定義された信頼できる複数のライブラリは前記１つのライブ ラリに対する信頼できるドメインとなる。信頼できるライブラリの信頼できるト ピックから配布されなかったトピックは疑わしいトピックとして識別される。疑 わしいトピックは、該トピックの名前空間内及び、該疑わしいトピックを命名従 属（Named Dependent）としてリストに載せているトピックの名前空間内に含ま れるリソースの変更のみ可能であり、その他のトピックに含まれるリソースは更 新不可能である。この規制により、有害なトピックによってライブラリ又はネッ トワークに与えられる損害は効果的に抑えられる。 トピック内でカプセル化されたリソースに加えて、各トピックは「処理」と呼 ばれる複数の機能を備え、これによりそれ自身の配布を制御することができる。 処理は必ずしも全てのトピックについて定義される必要はない。１つのトピック によって使用される全ての処理及びライブラリ・サービスは特定のトピックの作 業場所内で実行される。トピックはライブラリ機能（及びオペレーティング・シ ステム機能）を関連ライブラリから継承することができる。 トピックをコピーするには、該トピックに対して定義されたトピック複製処理 が呼び出される。トピック複製処理は新しいトピックを作成し、該新しいトピッ クの内容を初期化する。その後、該新しいトピックに対して定義された処理が呼 び出され、初期化プロセスが完了される。 アクティブ・ビュー（active view）内でトピックを移動するには、該トピッ クに対して設けられたトピック移動処理が呼び出される。トピック移動処理では 現在の祖先の直下の子である該トピックを削除し、２番目のトピックの直下の子 であるトピックをインストールする。そして、処理は移動された全てのトピック について呼び出される。トピックが移動される際、その子孫も一緒に移動される 。 トピックを削除するには、該トピックの祖先に対して設けられたトピック削除 処理が呼び出される。多くのオペレーティング・システムでは、機能の読み込み 元となるファイルを該機能で削除することは不可能なので、トピックは自分自身 を削除することはない。 トピック開放処理が使用され、トピックに関連するアプリケーション又はソフ トウエア成分が活性化される。 トピックを別のライブラリに配布するためにトピック配布処理が使用される。 トピック配布処理は、トピックの元のインスタンスは元のライブラリに残り、コ ピーが目的のライブラリに配布されるものとする。またトピック配布処理は、各 命名従属に対するトピック配布処理が既に実行されているものとしている。トピ ック配布処理は、トピックのインスタンスが既に存在しているかどうか目的のラ イブラリをチェックする。もし、該トピックのインスタンスが目的のライブラリ に既に存在しているならば、既存のインスタンスに設けられているBeforePublis hTopic処理が呼び出され、該既存のトピックの内容が更新される。該トピックの インスタンスが目的のライブラリに見つからない場合は、該トピックのインスタ ンスが目的の ライブラリに加えられる。 トピック復元処理は、トピックをより新しいバージョンに更新する代わりに前 のバージョンに復元すること以外は、前記トピック配布処理と同じである。トピ ック復元処理は、トピック配布処理と共に動作するように設計されており、これ によりトピックは、該トピックを別のライブラリに「配布する」ことによりバッ クアップ回復され、必要に応じて「復元する」ことができる。例えば、トピック の元のインスタンスが破損されたり削除された場合、トピック復元処理が使用さ れ、配布されたインスタンスより該トピックの元のインスタンスが再生可能であ る。配布されたトピックのインスタンスが、元のインスタンスの再生には不十分 な情報しか含んでいない場合は、トピック復元処理は有効に働かない。 トピック更新処理は、トピックに対する更新の自動配布を制御するのに使用さ れる。該トピック更新処理が実行される際には、該トピックは、更新が配布でき るものかどうかチェックする。更新が使用可能である場合には、更新を含む該ト ピックのインスタンスの位置が伝送され、トピック更新処理が実行されて更新プ ロセスが完了される。 トピック伝送処理はトピックを別のライブラリに配布するのに使用される。ト ピック伝送処理は、トピックの元のインスタンスは目的のライブラリに移動され 、コピーが元のライブラリに残るようにする。トピックを伝送するには、該トピ ックに対して設けられたトピック伝送処理が呼び出される。トピック伝送処理は 、各命名従属に対するトピック配布処理が既に実行されているものとしている。 トピック伝送処理は、トピックのインスタンスが既に存在しているかどうか目的 のライブラリをチェックする。もし、該トピックのインスタンスが目的のライブ ラリに既に存在しているならば、該既存のインスタンスに設けられているBefore RouteTopic処理が呼び出され、該既存のトピックの内容が更新される。該トピッ クのインス タンスが目的のライブラリに見つからない場合は、該トピックのインスタンスが 目的のライブラリに伝送され追加される。 トピックの各インスタンスには、ライブラリＩＤ及びトピックＩＤの結合とし てグローバルなアドレスが定義されている。これらグローバルなアドレスに加え て、アドレスは２つの相違なる基本形式に定義され得る。即ち、相対アドレス及 び命名従属である。グローバルなアドレス、相対アドレス、命名従属を連結させ て複合アドレスが形成される。 トピック内の各リソースは、該トピックにより定義された作業場所（名前空間 ）内でのみ有効な名前を有している。他のトピックのリソースは、該トピックに 対して接頭語としてグローバルなアドレス（又は複合アドレス）を用いることに より参照できる。 アクティブ・ビューにおいて他のトピックを識別するために、トピックにより 相対アドレスが使用されてもよい。但し、一般的に１個以上の直下の子が各トピ ックには存在しているので、直下の子に対して相対アドレスを定義することはで きない。 第１のトピックにより第２のトピックが命名従属として定義されている場合、 該第１のトピックは前記第２のトピックに従属している。ここで命名従属は、名 前と複合アドレスとの間の関係である。命名従属として識別された複合アドレス には、前記アクティブ・トピックが従属する複数のトピックが記述されている。 命名従属に関連する名前はアドレスとして使用され得る。 タグは名前と短文フレーズとの間の関係である。次の標準タグが全てのトピッ クに対して定義される。 Name−トピックの名前 〈Compound Address〉−トピックの名前 Author−該トピックを作成した作者個人の名前 Address−上記作者の郵便配達住所 E-mail Address−上記作者の電子メールアドレス Company−該トピックを開発した会社 名前付きファイルは名前とパスとの間の関係である。本発明が旧世代システム 上に設けられた場合、実際にファイルを移動することなく、トピック内に１つか それ以上のファイルを含む必要がある。即ち、トピックのファイル・システムに 組み込まれてはいないが、トピック内にカプセル化されているファイルを、名前 付きファイルは識別する。該トピックが配布され又は伝送される際、名前付きフ ァイルのコピーは該トピックについての外部のインスタンスに組み込まれている 。また、名前付きファイルは、カプセル化された書類のＨＴＭＬリンクを作成す るのに使用される。例えば、ＨＴＭＬリンクが名前付きファイルとして識別され ている文書ファイルに対して作成され、該ファイルの内容がインターネット又は イントラネットを介して閲覧され編集され得る。 本発明の実施は、典型的には比較的短期間の一回限りの作業であり、高価値で 戦略的な計画の自動化をサポートする場合に特に有効である。このような実施は 、外部からの販売努力及び共同利益に対する支払い努力の自動化をサポートする イントラネット配布ツールを含むことができる。 ［図面の簡単な説明］ 以下、本発明の一例を添付された図面を参照して説明する。 図１は、本発明の実施例であるネットワークに関する組織図、 図２は、ライブラリとトピックとの間の関係を示す組織図、 図３は、配布されたトピックを示す組織図、 図４は、ライブラリの階層構造を示す図である。 ［発明実施の最適形態］ まず図１に示すように、ネットワーク１は複数のオペレーティング・シ ステム又はライブラリ２を有しており、更にこれらオペレーティング・システム 又はライブラリ２は、カプセル化された集合体であるシステム・リソース又はト ピック３を複数有している。個々のトピック３はファイル・システム４を有して おり、各ファイル・システム４は、アプリケーション、データベース、ソフトウ エア成分、又はその他の論理的に関連づけられたファイル５の集まりを含んでい る。ネットワーク１は複数のコミュニケーション・プロトコルをサポートしてお り、これにより異なるライブラリ２におけるトピック３どうしが対話することが できる。ライブラリ２により定義された名前空間によりトピック３を限定してい る。 任意の時点で、各ライブラリ２はネットワーク１上の特定の空間的場所に存在 し、「ライブラリＩＤ」という特定のグローバルな識別子が割り当てられている 。この識別子はインターネット（又はイントラネット）に対して定義されたサー バ・ドメイン・ネームとなり得るものであり、或いは（オープン・ソフトウエア ・ファンデーションのＵＵＩＤ又はマイクロソフト社のＧＵＩＤのような）非常 に高い確率で独自性をもつ乱数であってもよい。 また、ネットワーク上の各トピックには、グローバルで唯一の識別子又は「ト ピックＩＤ」が割り当てられる。１つ以上のライブラリに存在するトピックは複 数の「インスタンス」をもつ。１つのトピックについての様々なインスタンスに は常に同じトピックＩＤが割り当てられる。トピックＩＤはＵＵＩＤとして又は ＧＵＩＤとして定義することができ、成いは前記トピックの最初のインスタンス が形成されたライブラリにおけるライブラリＩＤから構築することもできる。ア ドレス付与基準は、ライブラリＩＤをトピックＩＤと連結させることにより定義 される。 アドレス付与基準を定義する別の方法では、１つのネットワーク１を２っの異 なるグループとして記述する。即ち図２に示すように、１グループ のライブラリ２と、１グループのトピック３である。ネットワークは、１グルー プのトピック３を各ライブラリ２に関係づけることにより構築される。そして、 各ライブラリ２は、該ライブラリに対して関係したトピック２のインスタンスを 加えることにより構築される。このアプローチでは明らかなように、同じトピッ クの２つのインスタンスは同一のライブラリに出現し得ないようになっている。 同一のライブラリにおいて、１つのアプリケーション、１つのソフトウエア成分 、又は１つの書類についての２コピーを有することは実質的に無意味であるので 、上記制限を加えることに不都合はない。また、新しいトピックは、必要に応じ て既存のトピックのインスタンスをコピーすることにより作成され得る。 トピックのインスタンスは容易に位置づけされ(これらは全て同一のトピック ＩＤが割り当てられる)、更に図３に示すように、統合されて分散型のアプリケ ーション６を形成することもできる。トピックのインスタンスは必ずしもトピッ クについての同一のコピーである必要はない。トピックの各インスタンスの内容 及び振る舞いは異なるトピック間では相違している。例えば、イントラネット出 版ツールには次のようなトピックが含まれる。 「書類」−書類の各インスタンスは、該書類の最新バージョンを有しており、 １つ又はそれ以上の旧バージョンを有していてもよい。書類の様々なインスタン スに対する更新は要求に応じて配布される。 「アプリケーション(又はソフトウエア成分)」−アプリケーションの各インス タンスは該アプリケーションの完全なコピーを有している。各アプリケーション のインスタンスに対する更新は要求に応じて配布される。 「フォーラム」−フォーラムのインスタンスのうちの１つは該フォーラムの完 全なコピーを有している。その他のインスタンスによりエンドユーザは該フォー ラムをネットワークを介して参照し、該フォーラムに対して 追加をすることができる。 「データベース」−フォーラムと同様に、トピックのインスタンスのうちの１ つは該データベースの完全なコピーを有している。一方、その他のインスタンス によりエンドユーザは該データベースにネットワークを介してアクセスできる。 「イメージ記録書類」 トピックの様々なインスタンスは、表示すべき書類イメージの集合及び配布を 管理する。追加更新が、要求に応じてイメージ記録書類の各インスタンスに配布 される。 各トピックに対して依存関係が定義され得る。例えば、特定のワープロソフト で作成された書類は、通常では該ワープロソフトに依存している。前記依存関係 を使用することにより、ライブラリにインストールされたソフトウエアは、エン ドユーザの作業をサボートすべき要求に応じて更新維持され再構築され得る。 ＊追加構築 ライブラリ及びトピックは、既存の或いは「旧世代」のオペレーティング・シ ステム及びアプリケーションの上に構築することができる。まず、本発明の特徴 を最大限に利用したアプリケーションが作成され、その後、本発明を利用して追 加機能が付与され、これにより旧世代システムに対する依存が軽減される。 複数のシステム・リソースをカプセル化したセットとしてトピックを定義する ことにより、旧世代システムの上位層として本発明の実施例を構築することが可 能である。実際には本発明は、旧世代システムにより管理されているリソースを 複数のトピックのセットに分割することにより実現可能である。 本発明により作成されたアプリケーションはアドレス付与基準を使用す ることによりリソースを参照する。本発明により作成されたアプリケーションが 、旧世代技術に基づいたアプリケーション又はサービスの活性化を必要とする際 には、そのアドレスは、適切な旧世代システムの名前空間に翻訳し直さなければ ならない。例えば、トピック内に格納されているインターネット（又はイントラ ネット）書類もまた、オペレーティング・システムのディレクトリ構造体内のフ ァイルとして存在する。 新しいアドレスは、既存の旧世代システムの名前空間に翻訳し直され得るとい う事実があるので、一見、本発明はあまり価値がないように思える。しかし、ト ピック又はライブラリが時々刻々と異なる空間的場所に移動可能であり、トピッ クが他のライブラリに配布可能である、ということは忘れてはならない重要な点 である。トピックの特定のインスタンスがどこに格納されても、そのカプセル化 されたリソースに対するアドレス付与基準を使用して構築されたアドレスは一定 である。これにより、配布されたトピック内でカプセル化されたリソースを用い ているアプリケーションの構築は非常に容易になる。新しいアドレスは、既存の 旧世代システムの名前空間に翻訳し直すことができるが、この翻訳の結果は時々 刻々と変化する。 ＊ローカル／リモート・トランスピアランシー 先述したように、ＯＬＥ及びアクティブＸプロトコルに対する基礎として使用 されるマイクロソフト社のコンポーネント・オブジェクト・モデル（ＣＯＭ）は 、ローカル／リモート・トランスピアランシー（Local/Remote Transparency） の概念に基づいている。この考えは、アプリケーションは、ソフトウエア成分を 統合するための、画一した方法を使用すべきであり、他のプロセッサ内で又は外 部のネットワーク・サーバ上で作動するソフトウエア成分に対して例外的な方法 は何も提供すべきでない、ということである。マイクロソフト社は、外部のソフ トウエア成分を「ハンドラー」又は「プロキシ」と関連づけることにより、ロー カル／リモート・トランス ピアランシーという概念を提供している。このアプローチは、アプリケーション の観点からは好適に作用するが、ソフトウエア成分の開発及びインストールを非 常に複雑化させる。ソフトウエア成分内に構築すべき新たな複雑さに係るコスト は、開発されたソフトウエア成分が何度も使用されなければ合理的なものとなら ない。 本発明は、ローカル／リモート・トランスピアランシーの目的を実現するため に別の方法を使用している。各アプリケーションはトピック内でカプセル化され ている。共通ソフトウエア成分を使用するため、アプリケーションは複数のライ ブラリ・サービスを使用し、該ソフトウエア成分を含むトピック内における適切 なリソースを参照する。ライブラリにより、参照されたトピックが別のライブラ リ内に位置していることを判断すると、同様のネットワーク・サービスが使用さ れ該外部のライブラリに対して要求を送る。このプロセスを使用することにより 、アプリケーション及びソフトウエア成分のいずれも、特別なものを必要とせず 外部のトピックが参照できる。 ソフトウエア成分における別の外部のインスタンスに対するプロキシ（代理） として動作するように、ソフトウエア成分のインスタンスを設計することにより 、本実施例においてプロキシ及びハンドラーを構築することが可能である。 実際、ローカル／リモート・トランスピアランシーの概念は更に上の段階に向 上させることができる。トピックＩＤは、分散アプリケーションに対するグロー バルで唯一の識別子であるから、アプリケーションはライブラリ（又はネットワ ーク）に特定のトピックＩＤのインスタンスを検索させることができる。例えば 、アプリケーションは、関連するトピックＩＤを用いるだけで、顧客情報を含む データベースを参照することができる。データベースのインスタンスがローカル のライブラリ内で利用可能なら、 満足のいく参照が可能となる。データベースについてのローカルのインスタンス が要求を直接満たすことができないならば、該ローカルのインスタンスは、デー タベースの外部のインスタンスに対する代理として動作することができる。トピ ックのローカルのインスタンスが検索されなければ、ライブラリは、共用ライブ ラリの順序リストを検索して、データベースの適切な外部のインスタンスを見つ けることができる。 ＊プラットフォーム独立 アドレス付与基準により、如何なるトピックでもグローバルなネットワークを 介して他のトピック内に含まれるリソースを参照することが可能となるが、この ように行う参照では、その参照リソースが互換性のあるリソース・クラスに属す る場合にのみ有用である。「リソース・クラス」は、オペレーティング・システ ム・サービス、従って特定のＬＡＮインターフェース、又はインターネット（又 はイントラネット）書類のように、完全に一致したシステム・リソースとして定 義される。本発明により、１つのトピックは、任意のリソース・クラスに属する 様々なリソースをカプセル化することができる。 プラットフォーム独立のリソース・クラスの最適な例の１つに、インターネッ ト（又はイントラネット）書類がある。適切なＷＷＷブラウザさえあれば、開発 されたプラットフォームに関係なく、どのようなインターネット（又はイントラ ネット）書類でも閲覧することができる。このＷＷＷが普及していることが、プ ラットフォーム独立のリソース・クラスに対する価値を示す明らかな証拠となっ ている。 また本実施例は、相違するプラットフォーム（ここで、「プラットフォーム」 とは、統合された複数のリソース・クラスであると説明することができる）に構 築されるライブラリへのトピックの配布の手法を示唆している。トピックに対し てプラットフォーム独立基準を定義することが１つの 解決方法である。このような基準は、トピック内にカプセル化されたリソースを プラットフォーム独立のリソース・クラスに限定することにより定義することが できる。例えば、プラットフォーム独立基準は、トピックの全ての活性化成分が Ｊａｖａ（サンマイクロシステムズ社のプラットフォーム独立言語）で開発され ることが必要である。 相違するプラットフォームへのトピックの配布をサポートする別の方法では、 １つのプラットフォームから別のプラットフォームに配布されるようにトピック を変形構築する。エンドユーザの立場から見ると、このようなトピックはプラッ トフォーム独立となる。様々なプラットフォームに対してこれらトピックを意図 的に変形することで、これらトピックは、各プラットフォームに関連した独自の リソース・クラスに対してその性能を効果的に活用することができる。例えば、 ウインドウズ９５のゲートウェイは、メインフレーム・ライブラリ上のデータベ ースのインスタンスをウインドウズ９５のライブラリに配布することにより作成 できる。 また本発明では、個々のトピックを仮想マシンとして構築することができる。 そして、各ライブラリの複数の異なるタイプの仮想マシンをサポートすることが できる。このような仮想マシンは、プラットフォーム独立やプラットフォーム特 定である。プラットフォーム独立の仮想マシン内で動作するように定義されたト ピックは、異種のプラットフォームを介して配布伝送され得る。該トピック内の リソースは、全ての物理プラットフォーム上における一致した仮想環境内で動作 する。（関連したリソースをカプセル化するための）トピックを囲む境界により 、内部（仮想）リソースが外部（実際の）リソースに割り当てられる。この境界 は、トピックの内部ファイル構造をプラットフォームのファイル構造に割り当て ることができ、或いは、トピックの内部処理を分散処理に割り当てることができ る。例えば、トピック開放処理では、同一の外部項目ポイントをトピックの内部 処 理に提供するように設計される。 ＊ライブラリ組織 上述したように、大部分の最近のオペレーティング・システムに備えられたデ ィレクトリ構造体は、情報を位置づけすると共に情報を組織するために使用され る。アドレス付与基準は、グローバルなネットワークを介した情報の位置づけ及 び配布には効果的な道具であるが、トピックをライブラリ内で組織するための機 能は何も提供しない。 ある共通の作業場所において何らかの目的を達成するためにライブラリが構築 される。ライブラリに関連したこれら目的及び共通の作業場所は、任意の時に、 該ライブラリに含まれるトピックに対して自然な組織構造を定義するが、これら 目的及び共通の作業場所はどちらも時間の経過と共に変化し得る。即ち、どのよ うにしてトピックが複数のライブラリ間で組織されるか、又は、どのようにして ライブラリ内においてトピックが継続的に組織されるか、については制限があっ てはならない。 この目的に関し本発明では、図４に示すように、ライブラリはトピックを階層 構造に組織することができる。階層構造のうちの祖先７は、コア成分及びライブ ラリ自身に対する構成ファイルを含んだトピックである(ここで、ライブラリは 別の共通ソフトウエア成分である)。図４に示すように、ライブラリにおける目 的及び共通の作業場所に応じて、残りのトピック８、９、１０、１１は前記祖先 トピック（ライブラリ）の下位として組織されている。トピックの親を指す言葉 として「祖先」を使用し、トピックの子を指す言葉として「直下の子」を使用す る。 原則として本発明では、アドレス付与基準が、トピックを位置づけするための ライブラリ構造体に依存していないので、ライブラリはトピックをどのような構 造体（階層、行列、等）内にでも組織することができる。１つのライブラリは、 複合組織構造を同時にサポートし、様々なエンドユー ザに該ライブラリをカスタマイズして閲覧させることができる。例えば、エンド ユーザがライブラリを閲覧することで、アクセス権限の十分なレベルを有してい ないトピックを排除することができる。アドレス付与基準はライブラリに定義さ れた組織構造に依存していないので、異なるアクセスレベルを、アドレス付与し たトピック及び閲覧組織構造に定義することができる。ソフトウエア成分を含む トピックは、エンドユーザが閲覧するライブラリに現れないが、このエンドユー ザは、ソフトウエア成分を参照したアプリケーションを使用することができる。 ＊バージョン管理 バージョン管理には２つの基本的な方法がある。バージョンはトピックをコピ ーすることによって作成することができ、或いは、バージョン管理はトピック内 で行うことができる。トピックをコピーし新しいバージョンを作成するという考 えは、ファイルをコピーし新しいバージョンを作成するのと略同様のことである 。ファイルと同様に、トピックをコピーすることによって新しいバージョンを作 成すると、様々なバージョンのトピックを調整するのに手間がかかる(手作業又 は特別なアプリケーションでの処理による)。本方法を採用すると、これに係る 調整作業が簡単になり、トピックの様々なバージョン間で依存関係が定義される 。 大部分の場合には、トピック内にバージョン管理を設けることがより簡単な代 替方法となる。例えば、トピックはバージョン管理に書類を含んでいてもよい。 特定バージョンの書類は、単一の複合ファイル又は単一のサブディレクトリ内に 含まれている。新しいバージョンの書類が作成されると、これらは同じトピック 内の、新たな複合ファイル又はサブディレクトリに格納される。また、このトピ ックは、様々なバージョンの書類に対して提供されたコメントを統合し格納する ために使用される。このようなトピックの配布により、最新バージョンの書類と 、旧バージョンの書類と、 関連のコメントと、を含む新しいインスタンスが作成される(又は既存のインス タンスが更新される)。 ソフトウエア成分に対するバージョン管理では異なる処理がなされる。ソフト ウエア開発環境は、新しいソフトウエア成分及びアプリケーションを含む新しい トピックを生成するライブラリとして設定される。そして、各トピック内では各 ソフトウエア成分（又はアプリケーション）の複数のバージョンがサポートされ る。このようなトピックの配布により、最新バージョンのソフトウエア成分（又 はアプリケーション）を含む新しいインスタンスが作成される（又は既存のイン スタンスが更新される）。この方法により、全てのソース・コード、実行可能な モジュール、文書化、特定のソフトウエア成分のインストール処理が、単一のト ピック内でカプセル化される。各ソフトウエア成分に関連するトピックＩＤ及び 名前が構築時から配布時まで一定であるので、前記方法により、テスト環境の開 発が容易になり、コンポーネントの信頼性が向上する。 ＊ネットワーク・セキュリティー 大部分の最近のオペレーティング・システムではアプリケーションに対して単 一の名前空間を定義しているので、１つのオペレーティング・システムが適正な アプリケーションとウイルス（又はその他の害のあるプログラム）とを区別する ことはできない。１つのオペレーティング・システムの名前空間に様々なネット ワーク・リソースを含めることのできるＬＡＮやその他ネットワークの構築によ り、害のあるプログラムが普及される機会が増える。従来この問題を解決するに は、ネットワークの異なるセクション間での情報の流れを注意深く監視し制御す る強固なファイヤーウォールを構築していた。しかし、ファイヤーウォールでは 、ネットワーク境界を越える情報の流れを規制する程度しか効果が無いというこ とが問題である。ファイヤーウォールにより形成された規制に不満を持つエンド ユーザ がこのファイヤーウォールを一時的にでも外してしまうと、ここから害のあるプ ログラムをネットワーク上の保護セクションに侵入させてしまうことも起こり得 る。 Ｊａｖａ（サンマイクロシステムズ社のプラットフォーム独立言語）は、オペ レーティング・システム内にファイヤーウォールを構築するインターネット（又 はイントラネット）技術の一例である。Ｊａｖａは翻訳された首語であり、セキ ュリティー・ファイヤーウォールを有する各プラットフォームにおいてインタプ リタのインストールが必要である。Ｊａｖａが普及しているのを見れば、オペレ ーティング・システム内に構築されたセキュリティー・バリアにより情報交換を 如何に促進できるかがわかる。しかしこのＪａｖａには、Ｊａｖａインタプリタ 内に設けられたファイヤーウォールがＪａｖａアプリケーションに対してのみ有 効であるという問題がある。このＪａｖａファイヤーウォールでは、他の言語で 記載された害のあるアプリケーションを排除することはできない。 本発明では、オペレーティング・システム内におけるセキュリティー・ファイ ヤーウォールの構築に代替する方法をサポートしており、これによりどのような 種類のアプリケーションに対しても良好に作用する。ライブラリはトピックを、 「信頼できるトピック」又は「疑わしいトピック」というように識別できる。信 頼できるライブラリ上の信頼できるトピックから配布された場合は、このトピッ クは信頼できるトピックとして識別される(或いは、権限のあるエンドユーザに より信頼できるトピックとして識別される)。各ライブラリは信頼できるライブ ラリの簡単なリストを保持しており、該リストにあるライブラリから信頼できる アプリケーション及びソフトウエア成分の配布を受けるようになっている。ある ライブラリによつて定義された信頼できるライブラリは該ライブラリに対する信 頼できるドメインである。信頼できるライブラリ上の信頼できるトピックから配 布されたのではないトピックは、全て疑わしいトピックとして識別される。疑わ しいトピックは、該トピック自身の名前空間内及び、その他のトピックの名前空 間内に含まれるリソースを変質させることができ、該疑わしいトピックは、命名 従属としてリストアップされる。しかし、該疑わしいトピックは他のトピックに 含まれるリソースを更新することはできない。この規制により、害のあるトピッ クによってライブラリ又はネットワークに与えられる損害は効果的に低減される 。 また、アプリケーション内でのセキュリティー漏れが発覚している場合には、 信頼できるアプリケーションについても疑わしいトピックとして認識することが できる。例えば、疑わしいトピックとして構築されたＷＷＷブラウザは、既知の セキュリティー・リスクを主張する活動成分（Ｊａｖａ、アクティブＸなど）の サポートを可能とできる。このＷＷＷブラウザを疑わしいトピックとして設計す ることにより、セキュリティー・リスクは該ＷＷＷブラウザに関連した名前空間 に限定される(そして該名前空間が害を受けて破損しても、簡単に削除し再構築 することができる)。 上述したネットワーク・セキュリティーの方法によると、ファイヤーウォール の必要性は殆ど無くなる。アプリケーション及びソフトウエア成分は個々のトピ ック内で分離されているので、内部共用ネットワークにおける境界や相互共用ネ ットワーク間の境界を越えた情報の流れを規制する必要性は少なくなる。たとえ 、害のあるプログラムがワーク・ステーション上の信頼できるトピックに至る経 路を自ら発見したとしても、この特定のワーク・ステーションに対する加害活動 は規制されるようになっている。というのは、通常、ワーク・ステーションは、 他のワーク・ステーションに対する信頼できるドメインの一部ではないからであ る。 ＊基本的なトピックの処理（機能） トピックの様々なインスタンスは統合されて分散アプリケーションを形 成し得る。分散アプリケーションをインストールする１つの方法は、トピックの 各インスタンスを独立してインストールし、これら様々なインスタンスにより分 散アプリケーションを形成することである。しかし、このような手動インストー ル処理には多大な時間や費用がかかり、熟練が必要とされる。 各トピックがそれ自身の配布を管理できるようにすることにより、分散アプリ ケーションの構築が自動化できる。この目的のために、従来のオブジェクト指向 の手法を採用しトピックの配布管理を行う。トピック内でカプセル化されたリソ ースに加えて、各トピックは機能（「処理(Methods)」と称する）を構築し、それ 自身の配布を管理する。これら機能は、ライブラリ内でのトピックの複製を管理 すると共に、他のライブラリに対するトピックの配布を管理する。処理はトピッ クに対して設けられ、以下の基本的活動を自動化する。 ● トピックのコピー ● トピックの移動 ● トピックの削除 ● トピックの開放 ● トピックの配布 ● トピックの復元 ● トピックの更新 ● トピックの伝送 これら基本的活動が要求される特定の処理は次に述べるセクションにおいて定 義される。なお、ＱＮＩＤとは複合アドレスを意味する言葉である。 全てのトピックに対して処理が定義される必要はない。例えば、特定トピック のインスタンスは、ワーク・グループのフォーラムを管理するように設計された 分散アプリケーションを定義することができる。フォーラム を含むトピックのインスタンスをコピーできなければならないが、フォーラムに 対するアクセスポイントを提供するだけのインスタンスはコピーする必要がない 。これは、単一のライブラリ内で、同じフォーラムに対して２つのアクセスポイ ントがあっても意味がないからである。 また、トピックにより使用される全ての処理及びライブラリ・サービスが、特 定トピックの作業場所において実行されることも忘れてはならない重要なことで ある。共通ライブラリ機能（又はオペレーティング・システム機能）を、個々の トピックの作業場所において実行するということは一見奇妙に思えるかもしれな い。 複数の共通ライブラリ機能は、ライブラリ処理として独立して設けられる。こ の方法に関しては、トピックの様々なインスタンスが異なるライブラリに含まれ るという問題がある。複数の共通ライブラリ機能が独立して設けられた場合、ト ピックの各インスタンスは、ライブラリ機能を実行する前に、適切なライブラリ を識別しなければならない。これによって各トピックには無用な複雑さが加えら れる。アプリケーションが、ソフトウエア成分のような別のトピックと関連した 共通ライブラリ機能を実行しようとする場合には、複雑さはより一層増すことに なる。この複雑さの大部分は、トピックが関連するライブラリからライブラリ機 能（及びオペレーティング・システム機能）を継承することにより回避すること ができる。 ＊トピックのコピー ネットワーク内の各トピックは分散アプリケーションの成分として活動するこ とができ、それ自身の配布を管理する。トピックのこの独特な特徴により、所定 のテンプレートが無ければライブラリにより新しいトピックは作成することがで きない。「トピック複製」処理により、既存トピックがテンプレートとして使用 され、新しいトピックが作成される。 例えば、特定プロジェクトに対するセールス・フォーラムを管理するト ピックを考えてみる。このトピックは、多くの異なるタイプのフォーラムをサポ ートする共通ソフトウエア成分に依存しており、セールス・フォーラムに対する 複数の適切な構成パラメータを有している。セールス・フォーラムに設けられた トピック複製処理は別のセールス努力に対するセールス・フォーラムを生成する 。この新しいセールス・フォーラムも、前記共通ソフトウエア成分に依存してお り、既存のセールス・フォーラムから適切な構成パラメータを継承する。 また、共通ソフトウエア成分も、１つ又はそれ以上のクラスのトピックに対す るテンプレートとして使用できる。単一のライブラリ内にソフトウエア成分のコ ピーを２つ保持しておく必要はないので、ソフトウエア成分に設けられたトピッ ク複製処理を使用して従属したトピックを生成することができる。上述した例に 加えて、トピック複製処理により共通ソフトウエア成分の異なるクラスのフォー ラムを作成することができる。トピック複製処理の実行最中には、エンドユーザ には特定のクラスのフォーラムを選択するように指示が与えられる。エンドユー ザがセールス・フォーラムを選択すると、セールス・フォーラムに対する初期構 成パラメータをもつ新しいトピックが初期生成される。 トピック複製処理は２つの部分に形成される。 cQNIDが新しいトピックに対する祖先のQNIDであり、cNewQNIDは新しいトピッ クに対するトピック複製処理により生成されたQNIDを保持するためのバッファで あり、iSizeofNewQNIDはcNewQNIDバッファの長さであ り、cOldQNIDは元のトピックのQNIDである。 トピックをコピーするため、該トピックに対して定義されたトピック複製処理 が呼び出される。このトピック複製処理は新しいトピックを作成し、該新しいト ピックの内容を初期化する。最後に、新しいトピックに対して定義されたInitAf terCopyTopic処理が呼び出され、初期化プロセスを完成させる。 ＊トピックの移動 トピック移動処理が、ライブラリに関連する階層構造を変更するために使用さ れる。このトピック移動処理は２つの部分に形成される。 cQNIDが前記トピックに対する祖先のQNIDであり、cOldQNIDが移動されたトピ ックのQNIDである。 トピックを移動するため、前記トピックに対して設けられたトピック移動処理 が呼び出される。このトピック移動処理は、現在の祖先の直下の子にあたる該ト ピックを削除し、cQNIDにより識別されたトピックの直下の子にあたるトピック をインストールする。そして、移動された全てのトピックについて上記UpdateAf terMoveTopicが呼び出される。なお、トピックが移動される際には、その子孫も 全て移動される。 ＊トピックの削除 トピック削除処理は、トピック及びその子孫全てを削除するために使用される 。トピック削除処理は２つの部分に形成される。 cQNIDが削除されるべきトピックのQNIDである。 トピックを削除するために、該トピックの祖先に設けられたトピック削 除処理が呼び出される。そして、BeforeDeleteTopic機能が、削除すべき全ての トピックについて呼び出される。エラーがなければ、該トピック及びその全ての 子孫が削除される。多くのオペレーティング・システムでは、ファイルが自己の 機能により削除されることがないので、トピックは自分自身を削除することはな い。更に、トピックは、これが削除される前に、BeforeDeleteTopic処理を使用 して要求された処理を行うことができる。またエラー・コードを返送するように すれば、自分自身の削除を防止するトピックに対しても前記BeforeDeleteTopic 処理が使用可能となる。 ＊トピックの開放 トピック開放処理は、トピックに関連づけられたアプリケーションを活性化す るために使用される。例えば、バージョン管理を伴う書類に対するトピック開放 処理は、様々なバージョンの書類を管理するように設計されたアプリケーション を活性化することができる。 dwTypeはトピックを開放するために使用する処理であり、またeole_reqは、該 トピックがどのように開放されるべきか記述する構造であり(eole_reqはiMethod の値に基づいて変化する)、eole_intは、開放されたトピックに対するポインタ が復帰される構造である(eole_intはiMethodの値に基づいて変化する)。 ＊トピックの配布 トピック配布処理はトピックを別のライブラリに配布するのに使用される。ト ピック配布処理では、トピックの元のインスタンスが元のライブラリ上に残って おり、コピーが目的のライブラリに配布される。実際には、トピック配布処理は ４つの部分で形成される。 iMethodがトピックを配布するために使用される処理であり、目的のライブラ リの位置づけがcLocationであり(cLocationはiMethodの値に基づいて変化する) 、cQNIDは配布されたトピックに対する元の祖先についてのQNIDであり、cNewLoc ationはトピック配布処理によって作成され更新されたトピックの位置づけであ り、またiSizeofNewLocationはcNewLocationに対して割り当てられたバッファの サイズであり、更にQN_NEW_TOPIC_DATAは、以下のように定義された構造である 。 bExistingTopicは、該トピックのインスタンスが目的のライブラリ上 に存在する場合にはＴＲＵＥであり、インスタンスが目的のライブラリ上に存在 しない場合はＦＡＬＳＥである。また、cNameは目的のライブラリ上のトピック の名前であり(この名前は元のライブラリにおける名前と異なっていてもよい)、 cTargetLocationは目的のライブラリにおけるトピックのインスタンスに関連し た位置づけであり、cSourceLocationは元のライブラリにおけるトピックのイン スタンスに関連した位置づけであり、cQNIDAncestorは、目的のライブラリ上の トピックに対する祖先についてのQNIDである(iExistingTopicがＦＡＬＳＥの場 合は元の祖先となり、iExistingTopicがＴＲＵＥの場合は既存インスタンスの祖 先となる)。 トピックを配布するために、該トピックに設けられたトピック配布処理が呼び 出される。このトピック配布処理は、各命名従属に対するトピック配布処理が既 に実行されているものとしている。そしてトピック配布処理は、目的のライブラ リをチェックし、該トピックのインスタンスが存在しているかどうかを検知する 。目的のライブラリに該トピックのインスタンスが存在している場合には、既存 のインスタンスに設けられているBeforePublishTopic処理が呼び出される。即ち 、既存のトピックの内容が更新され、該更新されたトピックに対するUpdateAfte rPublishTopic処理が呼び出される。 トピックのインスタンスが目的のライブラリ上に見つけられない場合は、該ト ピックのインスタンスが目的のライブラリに追加される。即ち、新しいトピック に対してInitAfterPublishTopic処理が呼び出され、続いてUpdateAfterPublishT opic処理が呼び出される。前記新しいトピックを目的のライブラリに追加するた めにInitAfterPublishTopic機能が使用される。異なるライブラリは異なるプラ ットフォーム上に形成されるのであり、それらの構成ファイルに対して異なるフ ォーマットを採用するのであるから、あるライブラリは別のライブラリ構成ファ イルを直接更新することは できない。 ＊トピックの復元 トピック復元処理は、トピックをより新しいバージョンに更新する代わりに該 トピックを前バージョンに復元するという点を除けば、トピック配布処理に等し い。トピック復元処理はトピック配布処理と共に動作するように設計されており 、これによってトピックは、該トピックを別のライブラリに「配布」し、配布し たトピックを必要に応じて「復元」することにより、バックアップされ復元され るようになっている。例えば、トピックの元のインスタンスが破損したり削除さ れた場合、トピック復元処理が配布されたインスタンスより元のインスタンスを 生成するように使用されることができる。トピックの配布されたインスタンスが 、元のインスタンスを生成できるのに十分な情報を有していない場合には、トピ ック復元処理はサポートされない。実際に、トピック復元処理は４つの部分から 形成されている。 iMethodがトピックを復元するために使用される処理であり、目的のライブラ リの位置づけがcLocationであり(cLocationはiMethodの値に基づいて変化する) 、cQNIDは復元されたトピックに対する元の祖先につい てのQNIDであり、cNewLocationはトピック復元処理によって作成され更新された トピックの位置づけであり、またiSizeofNewLocationはcNewLocationに対して割 り当てられたバッファのサイズであり、更にQN_NEW_TOPIC_DATAは、トピック配 布処理に対して特定されたフォーマット中の構造である。 ＊トピックの更新 トピック更新処理は、更新されたトピックの自動配布を制御するために使用さ れる。トピック更新処理が実行されると、該トピックは、更新が配布できるかど うかを判定する。更新トピックがＴＲＵＥを返送すると、iMethod、cLocation、 cQNIDは、更新を含む前記トピックの外部のインスタンスを認識し、これにより トピック配布処理が実行され、更新処理を完了する。トピック更新処理は次のよ うに形成されている。 iMethodがトピックを復元するために使用される処理であり、元のライブラリ の位置づけがcLocationであり(cLocationはiMethodの値に基づいて変化する)、i SizeofLocationはcLocationに対して割り当てられたバッファのサイズであり、c QNIDはソース・トピックについてのQNIDであり、iSizeofQNIDはcQNTDに対して割 り当てられたバッファのサイズである。 ＊トピックの伝送 トピック伝送処理は、トピックを別のライブラリに伝送するのに使用される。 トピック伝送処理は、トピックの元のインスタンスが目的のライブ ラリに移動され、該トピックのコピーが元のライブラリに残されるようにする。 iMethodがトピックを伝送するために使用される処理であり、目的のライブラ リの位置づけがcLocationであり(cLocationはiMethodの値に基づいて変化する) 、cQNIDは伝送されたトピックに対する元の祖先についてのQNIDであり、cNewLoc ationはトピック伝送処理によって作成され更新されたトピックの位置づけであ り、またiSizeofNewLocationはcNewLocationに対して割り当てられたバッファの サイズであり、更にQN_NEW_TOPIC_DATAは、トピック配布処理に対して特定され たフオーマット中の構造である。 トピックを伝送するため、該トピックに設けられたトピック伝送処理が呼び出 される。このトピック伝送処理は、各命名従属に対するトピック配布処理が既に 実行されているものとしている。そしてトピック伝送処理は、目的のライブラリ をチェックし、該トピックのインスタンスが存在しているかどうか検知する。目 的のライブラリに該トピックのインスタンスが存在している場合は、既存のイン スタンスに設けられたBeforeRouteTopic処理が呼び出される。即ち、既存のトピ ックの内容が更新され、該更新されたトピックに対するUpdateAfterRouteTopic 処理が呼び出される。 トピックのインスタンスが目的のライブラリ上に見つけられない場合は、該ト ピックのインスタンスが目的のライブラリに追加される。即ち、新しいコピーに 対してInitAfterRouteTopic処理が呼び出され、続いてUpdateAfterRouteTopic処 理が呼び出される。前記新しいトピックを目的のライブラリに追加するためにIn itAfterRouteTopic処理が使用される。異なるライブラリは異なるプラットフォ ーム上に形成されるのであり、それらの構成ファイルに対して異なるフォーマッ トを採用するのであるから、あるライブラリは別のライブラリ構成ファイルを直 接更新することはできない。 ＊複合アドレス グローバルなアドレスがトピックの各インスタンスに対して、ライブラリＩＤ 及びトピックＩＤとして定義される。グローバルなアドレスには２つの形式が定 義される。即ち、ライブラリＩＤがローカルのライブラリに対してデフォルトと なる相対的ＱＮＩＤと、ライブラリＩＤが明確に指定される絶対的ＱＮＩＤであ る。これらグローバルなアドレスに加えて、他にも２つの基本的形式でアドレス が定義される。グローバルなアドレス、相対アドレス、及び命名従属を連結する ことにより複合アドレスが形成される。 ライブラリに対して定義された組織構造は特定のリソースを位置づけるために は使用されないが、トピックは、アクティブ・ビューにおける他のトピックを識 別できる状態になっている。相対アドレスはこの目的で使用することができる。 相対アドレスの最も普通の使用は、インターネット（又はイントラネット）書 類の生成のための使用であろう。相対アドレスは、エンドユーザが、ライブラリ に対して定義されたアクティブ・ビューを介してナビゲーションできるインター ネット書類を生成するのに使用できる。次の相対アドレ スが階層ビューに対して定義される。 〈-Topic〉−アクティブなトピック 〈-Ancestor〉−アクティブ・ビュー中のトピックに対する祖先 〈-Library〉−アクティブ・ビューの祖先トピック 各トピックには通常１つ以上の直下の子があるため、直下の子に対して相対ア ドレスを定義することはできない。１つ目のトピックにより２つ目のトピックが 定義される場合、前記１つ目のトピックは２つ目のトピックに依存することにな り、ここでは命名従属が、名前及び複合アドレスの間の関係である。命名従属に 関連した名前はアドレスとして使用することができる。グローバルなアドレス、 相対アドレス及び命名従属を上記のように定義すると、複合アドレスを次のよう に構築することができる。 ● 〈Compound Address〉=〈global address〉: ● 〈Compound Address〉=〈Relative address〉: ● 〈Compound Address〉=〈Named Dependent〉: ● 〈Compound Address〉=〈Compound Address〉〈Compound Address〉: ２つの複合アドレスが連結されると、２つ目の複合アドレスが、１つ目の複合 アドレスの内容において評価される。以下の例により、如何にして複合アドレス が評価されるのかを説明する。 ● 〈Topic>:<Ancestor〉:−アクティブなトピックの祖先を参照。 ● 〈Named Dependent〉:〈Ancestor〉:−命名従属の祖先を参照。 ● 〈Ancestor〉:〈Named Dependent〉:−アクティブなトピックの祖先によ り定義された命名従属を参照。 上記の処理に対して、適切な複合アドレスがＱＮＩＤとして使用できる。 トピックは複数のシステム・リソースがカプセル化されたものとして定義され ている。トピック内の各リソースは、該トピックにより定義された内容（又は名 前空間）内でのみ有効である名前を有している。例えば、各 トピックは、関連したインターネット（又はイントラネット）書類に対する項目 ポイントとして作用する「index.htm」と名付けられたファイルを含むことがで きる。１つのトピックを他のトピックとリンクさせるため、該トピックは、他方 のトピックに含まれる前記「index.htm」のファイルを参照する。他方のトピッ クのリソースが、該トピックに対する複合アドレスを接頭語として使用すること により参照される。例えば、トピックの祖先に関するインターネット（又はイン トラネット）書類へのリンクは、 〈ancestor〉:index.htm のように定義される。 ＊特別目的のリソース・クラス ３つの特別目的のリソース・クラスが初期形成時に定義される。即ち、命名従 属、タグ、及び名前付きファイルである。 上述したように、命名従属は、名前と複合アドレスとの間の関係である。命名 従属として識別された複合アドレスは、アクティブなトピックが依存している１ セットのトピックを記述している。例えば、通常、書類を含むトピックは、命名 従属としてワープロ・システムを有している。 タグは名前と短文フレーズとの間の関係である。まずタグは、トピックに対し て生成されたインターネット（又はイントラネット）書類に挿入すべき短文フレ ーズを定義するためにアプリケーションによって使用される。 次の標準タグが全てのトピックに定義されている。 ● Name−トピックの名前 ● 〈Compound Address〉−特定のトピックの名前 ● Author−トピックを作成した作者個人の名前 ● Address−上記作者に対する郵便配達住所 ● E-mail Address−上記作者に対する電子メールアドレス ● Company−このトピックを開発した会社 名前付きファイルは名前とパスとの間の関係である。形成完了時には、トピッ クに関連する全てのファイルが該トピック内にカプセル化され、名前付きファイ ルが不要になる。しかし、本発明が従来のシステム上に形成される場合は、ファ イルの移動無しに１つ以上のファイルを含むことが必要となる。このように名前 付きファイルは、トピックのファイル・システムに保存されていないファイルで 、該トピック内にカプセル化されたファイルを識別する。トピックが配布又は伝 送される際には、名前付きファイルのコピーは、該トピックの外部のインスタン スに保存される。トピックに対して定義された名前付きファイルを保存するため に次の処理が使用される。 ＊名前空間処理 形成完了時には、名前を翻訳する必要はないので、名前空間管理は非常に簡単 となる。しかし、従来のシステム上に構築された場合は、トピックの名前空間か ら１つ以上の従来の名前空間に名前を伝送することが依然として必要となる。特 定のエンドユーザのワーク・ステーション構成に応じて従来の名前が様々である ことが多いので、名前翻訳はより複雑化する。 名前を管理すべきトピックには４つの処理が形成される。 cRC1assが特定のリソース・クラスの名前であり、cTopicNameがトピックの名 前空間で定義されたリソースの名前であり、iSizeofNameはcTopicNameに対して 定義されたバッファのサイズであり、cReferenceNameはある名前空間翻訳に対す るリファレンス・ポイントとして要求されており、cValueはcTopicNameに係る値 であり、iSizeofValueはcValueに対して定義されたバッファのサイズである。 形成初期には以下のようなリソース・クラスがサボートされる。 相対的ＱＮＩＤ−ライブラリ内で使用される短縮型ＱＮＩＤ 絶対的ＱＮＩＤ−ネットワーク内で使用される長伸型ＱＮＩＤ タグ−名前と短文フレーズとの間の関係 命名従属−名前と従属トピックとの間の関係 直下の子−トピックに関連した直下の子 名前付きファイル−名前とファイルとの間の関係 相対的パスーリファレンス・パスに対して相対的なファイルのパス 絶対的パスーファイルの完全修飾パス GetNamedItem及びSetNamedItem処理はトピックの直下の子に対しては定義され ない。また、SetNamedItem処理は、相対的パス、絶対的パス、相対的ＱＮＩＤ、 絶対的ＱＮＩＤに対しては定義されない。少なくとも初期形成時ではGetFirstNa medItem及びGetNextNamedItemにより返送された項目は、標準名前をもつ項目を 含んでいない。例えば、「タグ」リソース・クラスに対するGetFirstNamedItem 及びGetNextNamedItemには、トピックに対して定義されたName、Address、E-mai l Address、或いはその他、トピックに対して定義された標準タグを含んでいな い。 ＊インターネット（又はイントラネット）書類 上述したように初期形成時では、プラットフォーム独立のリソース・クラスと して、複数のインターネット（又はイントラネット）書類を含んでいる。これに よりライブラリは、プラットフォーム独立のイントラネット配布ツールとして使 用できる。これはイントラネットについての専門知識のないユーザが、通常の作 業と同じようにしてイントラネット書類を作成できるというアイデアである。ま た、トピックはどのような複雑さのアプリケーションを有してもよく、この形成 によりユーザの作業性は阻害されない。 １つの方法は、各トピックにそれ自身のインターネット（又はイントラネット ）書類を作成させることである。このような方法はトピックに対して何らかの付 加をなすのであるから、各トピックには不要な複雑さが付加されてしまう。更に 、各トピックにおいてインターネット（又はイントラネット）書類を作成する場 合、それぞれ異なる処理を使用すると、権限のあるエンドユーザは、各トピック で作成されたインターネット（又はイントラネット）書類のデザインを変更する ことが難しくなる。 この問題の解決として、インターネット（又はイントラネット）書類の 生成に対するデフォルト処理がある。この処理により各トピックは複数のスタイ ルを含むことが要求される。スタイルは、前処理コマンドを含んだインターネッ ト（又はイントラネット）書類である。各ライブラリは前処理系を含んでおり、 この前処理系により、ライブラリ組織、トピック・スタイル、及び、トピックに 対して作成すべきインターネット（又はイントラネット）書類の内容を統合する 。 上記前処理コマンドは次のように定義される。 ● 〈XO Tag=”Name of a Tag“〉−このコマンドは、前処理系によりタグの 値と置き換えられる。もし”Name of a Tag“が複合アドレスならば、該コマン ドは参照トピックの名前に置き換えられる。 ● 〈XO NamedFile=”Name of a Named File“〉−このコマンドは、前処理 系により名前付きファイルに対する相対的パスと置き換えられる。 ● 〈XO AbsolutePath=”Path to a File“〉−このコマンドは、特定のファ イルに対する絶対的パスと置き換えられる。”Path to a File“が別のトピック のファイルに対する参照となる（複合アドレスを接頭語として使用することによ る)。 ● 〈XO RelativePath=”Path to a File“〉−このコマンドは、特定のファ イルに対する相対的パスと置き換えられる。”Path to a File“が別のトピック のファイルに対する参照となる(複合アドレスを接頭語として使用することによ る)。 ● 〈XO Text=”Path to a File“〉−このコマンドは、別のテキストファイ ルがスタイルに挿入されることを示す。このコマンドによりアプリケーションは 、トピック・スタイル内の挿入に対して大セクションのテキスト（更に別の前処 理コマンドを含んでもよい）を生成することができる。 ● 〈XO AllDirectDescendants〉−このコマンドは、一連のリスト項目と置 き換えられる。各リスト項目は、トピックに対する直下の子の１つを 参照している。 ● 〈XO AllNamedDependents〉−このコマンドは、一連のリスト項目と置き 換えられる。各リスト項目は、トピックに対して定義された命名従属の１つを参 照している。 ● 〈XO AllNamedFiles〉−このコマンドは、一連のリスト項目と置き換えら れる。各リスト項目は、トピックに対して定義された名前付きファイルの１つを 参照している。 初期形成時においては、トピックの内容が更新されたり、或いはライブラリの 組織が変更されたりした際に、各トピックに対して前処理系が自動的に作動され る。この方法により複数の静的なインターネット（又はイントラネット）書類が 作成され、これは既存のインターネット（又はイントラネット）・ブラウザによ りいつでも閲覧することができる。初期形成時に各ライブラリが１つの表示形式 でしか閲覧できない場合、これは好ましい方法である。複数の表示形式で閲覧で きる静的なインターネット（又はイントラネット）書類の異なるバージョン全て を調整することは不可能である。 別の方法を用いると複数の表示形式で閲覧できる。ダイナミック前処理（Dyna mic Pre-processing）と呼ばれる方法では、個々の書類がネットワークを介して アクセスされるように前処理系を作動させねばならない。前処理系は、特定の表 示形式内で作動されるので、インターネット（又はイントラネット）書類はこの 特定の表示形式に対して簡単にカスタマイズされる。 静的なインターネット（又はイントラネット）書類の生成をサポートするのに 、次の処理が各トピックに形成される。 ProcessStyles処理は、トピックに対して定義されているスタイルにより、該 トピックに対するインターネット（又はイントラネット）書類を生成する。Upda teStyles処理は、トピックに対して定義されているスタイルを前記クラスのトピ ックに対するデフォルト・スタイルと置き換える。デフォルト・スタイルは、前 記トピックを形成するために使用されるテンプレートと共に保存される。Update Template処理は、トピックに関連したテンプレートを前記クラスのトピックに対 するデフォルト・テンプレートと置き換える。これらテンプレートは、CopyTopi c及びPublishTopic処理を介してトピックを作成及び更新するのに使用される。 本発明によれば、トピックに対するスタイル及びテンプレートは、個々の作成 者の特定の要求に合わせてカスタマイズできる。UpdateStyles及びUpdateTempla te処理は、これらのカスタム変更を取り消す手段となっている。またUpdateStyl es及びUpdateTemplate処理は、PublishTopic処理を介して配布されない拡張スタ イル及びテンプレートを配布する手段ともなっている。 本発明は好ましい実施例を参照して説明したが、本発明はその他の形態で実施 することも可能である。例えば本発明は、汎用共通ネットワーク、公共ネットワ ーク(ワールド・ワイド・ウエブ（ＷＷＷ）のようなもの)、或いは低コストの動 的再構成ワーク・ステーションによるネットワーク（通常は「ネットワーク・コ ンピュータ」と称する）として実施することができる。 当業者であれば本明細書を見てわかるように、広範囲にわたって説明された本 発明の思想を逸脱しない範囲で、本発明には多くのバリエーションや変更・変形 が可能である。従って、本実施例は全て例示であり限定的に解釈すべきではない 。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，Ｍ Ｗ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，Ｅ Ｓ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＨＵ，ＩＤ，ＩＬ ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ， ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｋ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ， ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，Ｙ Ｕ，ＺＷ 【要約の続き】 ョン、ソフトウエア成分、及び異なる複数のライブラリ における複数のトピックとして保存された書類の、相互 対話を可能とするコミュニケーション・プロトコルがラ イブラリの外部に存在する。

Claims (1)

1. 【特許請求の範囲】 ［請求項１］ 各々のライブラリがそれぞれ空間的場所に存在し、かつ該各ライブラリが異な る複数のトピックについてのインスタンス集合と関連をもっている、これらライ ブラリの集合を有し、 前記各トピックは、システム・リソースのカプセル化されたセットであり、ア プリケーション、書類、データベース、ソフトウエア成分、又はその他の論理的 に関連したファイルの集合を含むファイル・システムを有しており、 同一トピックの複数のインスタンスは、それぞれ異なるライブラリに存在し得 ると共に、該各インスタンスは任意の時に任意のライブラリに重複することなく 存在し得る、ネットワーク用の分散オペレーティング・システムにおいて、 第１及び第２のグローバルで唯一の識別子からなるアドレス付与基準を前記ラ イブラリ及びトピックに適用し、前記第１のグローバルで唯一の識別子は各ライ ブラリを識別するために使用し、前記第２のグローバルで唯一の識別子は各トピ ックを識別するために使用する、分散オペレーティング・システム。 ［請求項２］ トピックの各インスタンスは、どのライブラリに属していても同一のトピック 識別子を有する、請求項１記載の分散オペレーティング・システム。 ［請求項３］ 前記複数のトピックは、祖先トピック及び子孫トピックからなる階層構造に組 織されており、該階層構造はトピックの位置づけにのみ使用され、トピックを他 と識別するには前記グローバルで唯一の識別子が使用される、 請求項１又は２記載の分散オペレーティング・システム。 ［請求項４］ 各トピックは、トピックをライブラリ内でコピーし、トピックを開放し、トピ ックを他のライブラリに配布（又は伝送）するオブジェクト指向処理のセットを 備えている、請求項１、２又は３記載の分散オペレーティング・システム。 ［請求項５］ 各トピックは、配布したトピックのインスタンスから該トピックを復元し、ト ピックについての更新の自動配布を制御するオブジェクト指向処理のセットをも 備えている、請求項４記載の分散オペレーティング・システム。 ［請求項６］ 前記アプリケーション、ソフトウエア成分、及び同一のライブラリ内又はネッ トワーク上にある異なる複数のライブラリにおいて異なる複数のトピックとして 保存された書類の、相互対話を可能とする共通のコミュニケーション・プロトコ ルが存在する、請求項１、２、３、４又は５記載の分散オペレーティング・シス テム。 ［請求項７］ 分離トピックとして配布されている基準及びカスタム成分のセットを結合させ ることにより、アプリケーション及び複合書類が構築されている、請求項１、２ 、３、４又は５記載の分散オペレーティング・システム。 ［請求項８］ 個々のトピックが備える前記オブジェクト指向処理を用いることにより、デー タ及びソフトウエア成分をネットワークを介して配布するための分散アプリケー ションが構築されている、請求項４又は５記載の分散オペレーティング・システ ム。 ［請求項９］ １つのライブラリ内の前記複数のトピックは多重表示形式に組織されており、 この多重表示形式はトピックの識別ではなく位置づけのために使用する、請求項 １、２、３、４又は５記載の分散オペレーティング・システム。 ［請求項１０］ トピックの各インスタンスには、ライブラリＩＤ及びトピックＩＤの結合とし てグローバルなアドレスが定義されている、請求項１、２、３、４又は５記載の 分散オペレーティング・システム。 ［請求項１１］ １つのトピックが、相対アドレスを用いてアクティブ・ビューにある他のトピ ックを識別する、請求項１、２、３、４又は５記載の分散オペレーティング・シ ステム。 ［請求項１２］ 第１のトピックにより第２のトピックが命名従属として定義されている場合、 該第１のトピックは前記第２のトピックに従属している、請求項１、２、３、４ 又は５記載の分散オペレーティング・システム。 ［請求項１３］ グローバルなアドレスである、相対アドレス及び命名従属を結合することによ り、複合アドレスが形成されている、請求項１０、１１又は１２記載の分散オペ レーティング・システム。 ［請求項１４］ 各トピックにスタイルが定義されており、これによりインターネット（又はイ ントラネット）書類の適切なセットが生成されて前記トピックの内容を拡張され たワークスグループと共有するようになっている、請求項１、２、３、４又は５ 記載の分散オペレーティング・システム。 ［請求項１５］ 個々のトピックに対するアクセスが権限のあるユーザだけに制限されている、 請求項１、２、３、４又は５記載の分散オペレーティング・システム。 ［請求項１６］ 各ライブラリは、信頼できるアプリケーション及びソフトウエア成分の配布元 である信頼できるライブラリのリストを保持しており、配布されたトピックが信 頼できるライブラリに含まれた信頼できるトピックから配布されている場合には 、該トピックは信頼できるトピックとして識別され、信頼できるトピックとして 識別されないトピックを疑わしいトピックと判定する、請求項１、２、３、４又 は５記載の分散オペレーティング・システム。 ［請求項１７］ 疑わしいトピックは、該トピックの名前空間内及び、該疑わしいトピックを命 名従属としてリストに載せているトピックの名前空間内に含まれるリソースの変 更のみ可能であり、その他のトピックに含まれるリソースは更新不可能である、 請求項１６記載の分散オペレーティング・システム。 ［請求項１８］ 各トピックにはテンプレートが定義されており、該トピックがライブラリ内で コピーされる際又は他のライブラリに配布される際に、前記テンプレートにより 、前記トピックの内容及び振る舞いが有用に変化するように制御する、請求項１ 、２、３、４又は５記載の分散オペレーティング・システム。 ［請求項１９］ 各トピックは仮想マシン内で動作し、各トピック周囲の境界により、内部又は 仮想のリソースを、外部又は実際のリソースに位置づけする、請求 項１、２、３、４又は５記載の分散オペレーティング・システム。