JPH11500248A - 一般的なウエブ・ブラウザが複数の異なるプロトコル型のサーバをアクセスすることを可能にするための情報ハンドリング・システム - Google Patents

Abstract

(57)【要約】 この情報ハンドリング・システムは、一のクライアント・コンピュータ装置と一のサーバ・コンピュータ装置の間に設けられている一のネットワークを介して、前記クライアント・コンピュータ装置が、前記サーバ・コンピュータ装置に置かれている情報をアクセスすることを可能にする。前記クライアント・コンピュータ装置は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用して前記サーバ・コンピュータ装置をアクセスするとともに、前記サーバ・コンピュータ装置から受信される情報をハイパーテキスト・マークアップ言語（ＨＴＭＬ）ソフトウェアを使用して前記クライアント・コンピュータ装置の一のユーザに供給する。前記情報ハンドリング・システムが含んでいる前記ネットワークは、前記クライアント及びサーバ・コンピュータ装置間に設けられ、ＨＴＴＰとは異なる一のネットワーク伝送プロトコルを使用するとともに、ＨＴＭＬとは異なる一のネットワーク・データ・フォーマットを使用する。また、前記情報ハンドリング・システムが含んでいる伝送プロトコル変換手段は、前記クライアント及びサーバ・コンピュータ装置のうち少なくとも１つのコンピュータ装置から前記ネットワークを介して送信されるか又は前記ネットワークを介して前記少なくとも１つのコンピュータ装置によって受信されるＨＴＭＬ／ＨＴＴＰ情報を、前記ネットワーク伝送プロトコル及び前記ネットワーク・データ・フォーマットに変換する。

Description

【発明の詳細な説明】 一般的なウェブ・ブラウザが複数の異なるプロトコル型のサーバをアクセスす ることを可能にするための情報ハンドリング・システム発明の分野 本発明は、ネットワーク化された複数の情報処理システムを有する情報ハンド リング・システムに係り、更に詳細に説明すれば、クラス・ライブラリを使用し てＷＷＷ（ワールド・ワイド・ウェブ）と呼ばれるサーバ・コンピュータ・シス テム（以下「サーバ」と略記）を開発するためのオブジェクト指向技術に係る。 本発明の背景に関する一層詳細な説明については、以下の記述を参照されたい。発明の背景 過去２年の間、ほぼ全世界にまたがるコンピュータ・ネットワークの集合体と してのインターネットの利用、特にその最上部に構築したシステムの１つである ＷＷＷの利用が爆発的に増加した。ＷＷＷを構成する多数のページ又は情報ファ イルは、多数の異なるサーバにまたがって分散されている。例えば、かかるペー ジ上に格納される情報は、或る企業の組織や、連絡先データ、製品データ及びそ の企業に関係するニュース等の詳細とすることができる。この情報は、テキスト 、 グラフィック、音声及びビデオ・データを組み合わせた形態で、クライアント・ コンピュータ・システム（以下「クライアント」と略記）としてのユーザのコン ピュータ・システムに提供することができる。各ページは、ＵＲＬ（未入手資源 ロケータ）によって識別される。ＵＲＬは、サーバと、このサーバ上の特定のフ ァイル又はページの両方を指定する。単一のサーバ上には、多数のページ又はＵ ＲＬが存在することがある。 ＷＷＷを利用するため、各クライアントは、グラフィカル・ウェブ・ブラウザ と呼ばれる小さなソフトウェア、例えば（ＩＢＭ社のＯＳ／２の一部として提供 される）WebExplorer や、ネットスケープ・コミュニケーション社の Navigator プログラムを実行する。なお、「WebExplorer」、「OS/2」及び「IBM」は、イ ンターナショナル・ビジネス・コーポレイションの商標であり、「Navigator」 及び「Netscape」は、ネットスケープ・コミュニケーション社の商標である。ク ライアントがブラウザと対話して特定のＵＲＬを選択する場合、ブラウザは、当 該ＵＲＬ又はページのための要求を当該ＵＲＬが識別するサーバに送信する。サ ーバは、この要求に応じて、要求対象のページを検索するとともに、その要求デ ータを要求元のクライアントに返送する（クライアントとサーバとの間の対話は 、ＨＴＴＰ（ハイパーテキスト転送プロトコル）に従って行われる）。次に、こ のページは、クライアントの画面を通してユーザに表示される。また、クライア ント は、例えば、特定のトピックに関係するＷＷＷページを探索するためのアプリケ ーションを立ち上げるように、サーバに要求することができる。 殆どのＷＷＷページは、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）で 書かれたプログラムに従ってフォーマット化されている。このプログラムは、ク ライアントのグラフィカル・ブラウザを介して表示すべきデータを保持するほか に、ブラウザに対し当該データの表示方法を指示するためのフォーマット化コマ ンドを保持する。かくて、代表的なウェブ・ページには、テキストが含まれてい るだけでなく、タグと呼ばれるフォーマット化コマンドが埋め込まれているから 、これらのコマンドを使用して、フォントの大きさや、フォントのスタイル（例 えば、イタリック又は太字）や、テキストのレイアウト方法等を制御することか できる。ウェブ・ブラウザは、指定されたフォーマットに従ってテキストを表示 するために、ＨＴＭＬスクリプトの「解析」を行う。また、ＨＴＭＬタグを使用 すると、クライアントのブラウザを介してユーザに表示すべきグラフィック、音 声及びビデオ・データの表示形態を指示することができる。 殆どのウェブ・ページは、元のページと同一のサーバ上に必ずしも存在しない 処の、他のウェブ・ページに対する１つ以上の参照を含んでいる。かかる参照を 活動化するには、ユーザが画面上の特定の位置を選択したり、マウスの制御ボタ ンを（ダブル）クリックするのが普通である。これらの参照 又は位置は、「ハイパーリンク」と呼ばれていて、ブラウザが特定の様式でフラ グするようになっている（例えば、各ハイパーリンクに関連するテキストを、目 立ちやすいカラーで表示することがある）。もし、ユーザがこのハイパーリンク を選択すれば、参照されたページが検索されて、現に表示されているページに置 き換わることになる。 ＨＴＭＬ及びＷＷＷに関する詳細な情報については、Douglas McArthur，"Wor ld Wide Web and HTML"，Dr Dobbs Journal，December 1994，pp.18-26 及び Ia n Graham，"The HTML SourceBook"（John Wiley，New York，1995）を参照され たい。 ＨＴＭＬを受理してこれを表示する一般的なウェブ・ブラウザは、アプリケー ションの開発者に対し、顕著な能力を与える。即ち、ユーザ・インタフェースを 実現するためにブラウザを使用すると、次の２つの利点を享受することができる からである。 第１：通信プロトコル（ＨＴＴＰ）が埋め込まれる。 第２：ユーザ・インタフェース環境（ＨＴＭＬ）が埋め込まれる。 通信とユーザ・インタフェースは、プラットフォームに依存する度合いが極め て高いという理由で、アプリケーション開発の非常に高価な２つの分野になって いる。これらの２つの問題が存在するために、多くのアプリケーションは、全て のカストマに行きわたっていない。 現在、ＨＴＴＰ ＴＣＰ／ＩＰとは異なる通信プロトコルを使用して伝送を行 うようなウェブ・ブラウザ／サーバは、全く存在しない。しかしながら、設置済 みの多数のコンピュータは、NetＢＩＯＳ、ＩＰＸ及び直列回線のような、種々 の通信プロトコルを使用している。これらのコンピュータのユーザは、ＴＣＰ／ ＩＰ接続の使用を必要とせずに、ウェブ・ブラウザ／サーバ技術を使用すること を望む場合がある。この技術は、かかる制約により制限される。 この技術が特に重要となる１つの環境は、システム管理である。効率的なシス テム管理は、設置済みコンピュータが大型であるか小型であるかを問わず、その 動作にとって非常に重要である。システム管理のタスクを改良するために、これ まで多数のアプリケーションが開発されてきた。これらのアプリケーションが試 みたことは、これらのコンピュータのユーザ又はシステム管理者に対し一層強力 な管理能力を与えるために、不可解なハードウェア及びオペレーティング・シス テム（以下「ＯＳ」と略記）に依存するコンピュータの監視結果及び制御手段を 抽象化し且つこれらを照合する、というものである。 最近のシステム管理ソフトウェアでは、グラフィカル・ユーザ・インタフェー ス（ＧＵＩ）を通して、監視結果及び制御手段が表示及び制御されるようになっ ている。本発明に即して説明すれば、これらのシステム管理アプリケーションは 、次の２つの問題点を有している。即ち、（１）これらのＧＵ Ｉは、特定のコンピュータ上で実行するように制約されているだけでなく、制限 されたプロトコルを通してのみベースのシステム管理オブジェクトと通信するよ うに制約されており、また（２）システム管理アプリケーションを他のコンピュ ータ又はプロトコルに移動させるには、この新しいプラットフォーム用のＧＵＩ を再びコード化しなければならない、ということである。現在の技術は、これが サポートするコンピュータに対してのみ、システム管理データを供給するに過ぎ ない。従って、かかる現在の技術には、強力で且つ柔軟なシステム管理インタフ ェースに対する諸障壁が存在する。発明の要約 本発明が提供せんとする情報ハンドリング・システムは、一のクライアント・ コンピュータ装置が、一のサーバ・コンピュータ装置に置かれている情報をアク セスすることを可能にする。前記クライアント・コンピュータ装置は、ハイパー テキスト転送プロトコル（ＨＴＴＰ）を使用して前記サーバ・コンピュータ装置 と通信するための手段と、前記サーバ・コンピュータ装置から受信される情報を ハイパーテキスト・マークアップ言語（ＨＴＭＬ）を使用して当該クライアント ・コンピュータ装置の一のユーザに供給するための手段とを含んでいる。前記情 報ハンドリング・システムは、その特徴的構成として、前記クライアント及びサ ーバ・コンピュータ装置間に設けられた一のネットワークと、伝送プロトコル変 換手段とを備えている。前記ネットワークは、ＨＴＴＰとは異なる一のネットワ ーク伝送プロトコルを使用するとともに、ＨＴＭＬとは異なる一のネットワーク ・データ・フォーマットを使用する。他方、前記伝送プロトコル変換手段は、前 記クライアント及びサーバ・コンピュータ装置から前記ネットワークを介して送 信されるか又は前記ネットワークを介して前記クライアント及びサーバ・コンピ ュータ装置によって受信されるＨＴＭＬ／ＨＴＴＰ情報を、前記ネットワーク伝 送プロトコル及び前記ネットワーク・データ・フォーマットに変換するように機 能する。 前述の要件に加えて、本発明の前記情報ハンドリング・システムは、次の要件 を満足することが好ましい。即ち、前記クライアント・コンピュータ装置の前記 情報を供給するための手段が、特定の型のグラフィカル・ユーザ・インタフェー スを使用し、前記クライアント・コンピュータ装置が、インターネットに接続さ れ、前記ネットワークが、前記インターネットと前記サーバ・コンピュータ装置 の間に設けられ、前記伝送プロトコル変換手段が、一のＨＴＭＬオブジェクト及 び一のＨＴＴＰオブジェクトを含むオブジェクト指向のコンピュータ・ソフトウ ェアを実行し、前記ＨＴＭＬオブジェクトが、前記クライアント・コンピュータ 装置からＨＴＭＬ要求データを受理し且つ当該受理済みのＨＴＭＬ要求データを 前記ネットワーク・データ・フォーマットに変換し、前記ＨＴＴＰオブジェクト が、前記クライアント及びサーバ・コン ピュータ装置間でインターネット接続をオープン及び維持し、前記クライアント ・コンピュータ装置から受信される前記ＨＴＭＬ要求データを解析し、前記クラ イアント・コンピュータによって使用される前記特定の型のグラフィカル・ユー ザ・インタフェースの識別子を検出し、前記要求データ及び検出済みのグラフィ カル・ユーザ・インタフェースの識別子を前記ＨＴＭＬオブジェクトに伝送する とともに、ＨＴＭＬデータを前記ネットワーク及び前記インターネットを介して 前記ＨＴＭＬオブジェクトと前記クライアント・コンピュータ装置の間で転送す る、ということである。 第２の側面において、本発明が提供せんとする情報ハンドリング・システム用 の一のプログラム要素は、前記情報ハンドリング・システム上で実行される際に 、データと（ａ）ＨＴＭＬ及びＨＴＴＰ、並びに（ｂ）少なくとも１つのコマン ド及びＨＴＭＬ又はＨＴＴＰの何れとも異なるプロトコルの間のマッピングを行 うための一のマッピング・ブロックを備えている。前記マッピング・ブロックは 、一のＨＴＭＬオブジェクト及び一のＨＴＴＰオブジェクトを有している。前記 ＨＴＭＬオブジェクトは、ＵＲＬ（未入手資源ロケータ）及び他の要求データを 受理し、受理済みの要求を内部コマンド及びＨＴＭＬ又はＨＴＴＰの何れとも異 なるプロトコルに形成し、内部コマンド及びＨＴＭＬ又はＨＴＴＰの何れとも異 なるプロトコルの形式を有する応答を受理し、受理済みの応答をＨＴＭＬに変換 するとともに、当該ＨＴＭＬを前記ＨＴ ＴＰオブジェクトに送信するように機能する。他方、前記ＨＴＴＰオブジェクト は、インターネット通信をオープン及び維持し、前記インターネットを介してＨ ＴＴＰ要求を受理し、受理済みの要求を形成するＵＲＬ及び関連するデータを解 析し、当該ＵＲＬ、関連するデータ及びブラウザ・プログラムの識別子を前記Ｈ ＴＭＬオブジェクトに伝送し、前記ＨＴＭＬオブジェクトからＨＴＭＬソースを 受理するとともに、ＨＴＭＬソースをＨＴＴＰ応答として前記インターネットに 戻すように機能する。 また、本発明は、インターネット上のどこかに接続される任意のブラウザが、 一のシステム管理プロトコルの諸イベントを表示及び制御するために、一のグラ フィカル・ユーザ・インタフェースとして機能することを可能にする。図面の簡単な説明 本発明の幾つかの目的は前述の通りであるが、他の目的は、以下の添付図面を 参照して行われる後段の説明から次第に明らかとなるであろう。 図１Ａは、典型的なパーソナル・コンピュータ・システム（以下「パーソナル ・コンピュータ」と略称）の斜視図である。 図１Ｂは、本発明に従った装置及び方法を実施した情報ハンドリング・ネット ワークを示す図である。 図２は、図１Ａのパーソナル・コンピュータ用の統合化プ レーナ・ボードの概略ブロック図である。 図３は、図１Ａのパーソナル・コンピュータ用の代替的なプレーナ・ボードの 概略ブロック図である。 図４は、図３の代替的なプレーナ・ボードに関連して使用するプロセッサ・カ ードの概略ブロック図である。 図５は、本発明に従った図１Ｂの情報ハンドリング・ネットワークを介してシ ステム構成情報を通信するために取られる諸ステップの流れ図である。 図６は、図５の流れ図で取られる幾つかのステップの一層詳細な流れ図である 。 図７は、例示的フレームワーク機構のカテゴリ図である。 図８〜図１２は、図７の例示的フレームワーク機構のクラス図である。 図１３は、図７〜図１２の例示的フレームワーク機構のオブジェクト図である 。 図１４Ａ及び図１４Ｂは、図１Ｂのネットワークを通して行われる、本発明の システム管理の実施例を示す図である。 図１５は、図１４Ａ及び図１４Ｂに示したマッピング・ブロックの要素を示す 図である。推奨実施例の説明 以下、本発明の背景に係る技術を一層詳細に説明する。当該技術について高度 な知識を有する読者は、以下の背景情報に係る説明を読んでも読まなくても良い が、この情報は本発 明を理解するのに重要であるので、これを十分に検討することを勧める。 本発明の推奨実施例を示した添付図面を参照して本発明を詳述するに先だち、 当業者は、本発明の効果を享受しつつ本明細書中で説明した本発明を適宜に変更 又は修正しうることを理解すべきである。従って、以下の説明は、当業者に向け られた広範な技術的教示を開示しているに過ぎず、本発明の技術範囲を制限する ものではないことを理解すべきである。ハードウェア環境 一般のパーソナル・コンピュータ、特にＩＢＭ社のパーソナル・コンピュータ は、現在社会の多くの分野に対しコンピュータ能力を提供するために、広範に使 用されるようになってきた。一般に、パーソナル・コンピュータは、形態的には 、デスク・トップ型、床置き型及び携帯型に類別され、構成的には、システム・ プロセッサを有するシステム・ユニット、表示モニタ、キーボード、１つ以上の ディスケット駆動装置、固定ディスク記憶、オプションのマウス及び印刷装置を 含んでいる。これらのシステムは、主として、個々のユーザ又は小グループのユ ーザに対し、独立の計算能力を与えるように設計されており、個人又は企業が購 入しやすいように安価な価格で提供されている。かかるパーソナル・コンピュー タは、商標として、例えば「IBM PERSONAL COMPUTER」、「PERSONAL COMPUTER X T」、「PERSONAL COMPUTER AT」及び「IBM PERSONAL SYSTEM/2」（以下、ＩＢＭ ＰＣ、ＸＴ、ＡＴ及びＰ Ｓ／２とそれぞれ略称）を付したモデル２５、３０、５０、５５、５７、６０、 ６５、７０、８０、９０及び９５として提供されている。 一般に、これらのパーソナル・コンピュータは、２つのファミリに分類するこ とができる。第１のファミリは、「ファミリ１モデル」と呼ばれ、ＡＴコンピュ ータ及び他の「ＩＢＭ互換」マシンによって代表されるバス・アーキテクチャを 使用する。第２のファミリは、「ファミリ２モデル」と呼ばれ、ＩＢＭ社のＰＳ ／２モデル５０〜９５によって代表される「マイクロチャネル」バス・アーキテ クチャを使用する。ファミリ１及びファミリ２モデルが使用するこれらのバス・ アーキテクチャは、当該技術分野では周知である。 ＩＢＭ ＰＣ及びＸＴは、ＩＢＭ社のパーソナル・コンピュータ・ラインの最 初のモデルであり、インテル社の８０８８プロセッサを使用していた。ＩＢＭ社 のパーソナル・コンピュータに対する次の重要な変更は、ＡＴであって、これは インテル社の８０２８６プロセッサを使用していた。他方、ＰＳ／２のラインは 、インテル社の幾つかのプロセッサを使用していた。即ち、モデル３０は８０８ ６を使用し、モデル５０及び６０は両者とも８０２８６を、モデル７０の或るバ ージョン及びモデル８０は８０３８６を、モデル７０の他のバージョン、モデル ９０のＸＰ ４８６及びモデル９５のＸＰ ４８６は８０４８６を使用していた 。これらの全てのパーソナル・コンピュータの共通点は、インテル社のＸ８６フ ァミリ・プロセッサを使用しているということである。容易に入手可能で且つ周 知の種々のＯＳ、例えばＤＯＳ又はＯＳ／２は、インテル社のＸ８６ファミリ・ プロセッサ上で動作することができる。 また、ファミリ１モデルの最も初期のパーソナル・コンピュータ（例えば、Ｉ ＢＭ ＰＣ）の時点から、ソフトウェアとハードウェアの互換性を維持するとい う目標が最も重要であることが認識されていた。この目標を達成するため、「マ イクロコード」と呼ばれる常駐コードの隔離層が、ソフトウェアとハードウェア の間に設定された。このコードは、ユーザのアプリケーション／ＯＳとハードウ ェア装置の間に動作インタフェースを提供して、ハードウェア装置の特性を考慮 するという重荷からユーザを解放した。このコードは、最終的に基本入出力シス テム（以下「ＢＩＯＳ」と略記）として開発され、これによりアプリケーション ／ＯＳをハードウェア装置の特性から隔離しつつ、新しいハードウェア装置をシ ステムに追加することが可能となった。ＢＩＯＳが重要である所以は、これによ って装置ドライバが特定のハードウェア装置の特性に依存しなくなり、しかもハ ードウェア装置への中間インタフェースを有する装置ドライバを提供することが できる、という点にある。ＢＩＯＳは、パーソナル・コンピュータの不可分の部 分を構成していて、システム・プロセッサと授受すべきＩ／Ｏデータの移動を制 御するものであるから、システム・ユニットのプレーナ・ボード上に搭載した読 み取り専用メモリ（ＲＯＭ）又は消去可能読み取り専用メモリ（ＥＰＲＯＭ）の 形態で、ユーザに出荷されていた。例えば、当初のＩＢＭ ＰＣにおけるＢＩＯ Ｓは、プレーナ・ボード上に搭載したＲＯＭの８Ｋバイトを占有していた。プレ ーナ・ボードは、ＲＯＭに加えて、システム・プロセッサと、主ランダム・アク セス・メモリ（ＲＡＭ）と、このボード上で実質的に共平面状に固定された他の 構成要素を含んでいた。また、ＲＯＭは、そのパーソナル・コンピュータをテス トし且つ初期化するために使用する電源オン自己テスト・プログラム（以下「Ｐ ＯＳＴ」と略記）を保持していた。かかるＲＯＭ内に常駐するコードの集合は、 「システム・ファームウェア」又は単に「ファームウェア」と呼ばれるようにな った。このように、ファームウェアは、ＰＯＳＴ部分及びＢＩＯＳ部分を含んで いた。或る形態のＢＩＯＳは、ＰＯＳＴを含むように定義されていた。 パーソナル・コンピュータ・ファミリの新しいモデルが導入される場合、その ファームウェアを更新するとともに、Ｉ／Ｏ装置のような新しいハードウェア装 置をサポートするように、これを拡張しなければならなかった。容易に予測でき るように、ファームウェアのメモリ・サイズは、次第に増大してきた。例えば、 ＡＴの導入とともに、ファームウェアは３２ＫバイトのＲＯＭを必要とするよう になった。また、マイクロチャネル・アーキテクチャを使用するＰＳ／２の導入 に際し、拡張ＢＩＯＳ（ＡＢＩＯＳ）と呼ばれる処の、実質 的に新しいＢＩＯＳが開発された。しかしながら、ソフトウェア上の互換性を維 持するために、互換ＢＩＯＳ（ＣＢＩＯＳ）と呼ばれるファミリ１モデルからの ＢＩＯＳを、ファミリ２モデルに含めなければならなかった。かくて、当初のＢ ＩＯＳは、互換ＢＩＯＳ及び拡張ＢＩＯＳのような２種類以上のＢＩＯＳを含む ように発展してきた。パーソナル・コンピュータに係る現在のアーキテクチャ上 の定義は、ファームウェア用として最大１２８Ｋバイトまでのシステム・アドレ ス空間（システム・ファームウェア・アドレス空間）を許容する。 現在では、新しい技術の継続的な開発とともに、パーソナル・コンピュータは 一層複雑になりつつあり、また一層頻繁に拡張されるようになっている。技術が 速やかに変わりつつあり、しかも新しいＩ／Ｏ装置がパーソナル・コンピュータ に追加されつつあるので、その開発サイクルにおいては、ファームウェアの修正 及び拡張が以前にも増して重要な問題となってきた。 マイクロチャネル・アーキテクチャの導入に際し、ＩＢＭ社は、プログラマブ ル・オプション・セレクト（ＰＯＳ）と呼ばれる処の、新しい構成手順を提供し た。ＰＯＳは、インストール及びパーソナル・コンピュータの拡張を以前のＰＣ よりも容易に且つ簡明に行うことを目標として、ＤＩＰスイッチ、ジャンパ及び ヘッダを使用しないでパーソナル・コンピュータの構成動作を行うことができる ように設計されてい る。ＰＳ／２は、低電力のバッテリ・パック式ＣＭＯＳメモリを使用して、その ハードウェア構成を記憶することができる。この構成は、拡張装置の識別子と、 システムの残りの部分に関しこれらの拡張装置がどのように機能するかという情 報を含んでいる。マイクロチャネル用に設計された全ての拡張カードは、一意的 な識別番号を有する。パーソナル・コンピュータがブートする場合、ＰＳ／２は 、インストールされるオプションをその不揮発性メモリ（ＮＶＲＡＭ）内の情報 と比較して、その設定の完全性を保証するために構成上の変更を検出する。これ らの設定ファイルは、リファレンス・ディスケットを使用する構成手順の間にフ ァイル・システム内に自動的に取り込まれる。例えば、ＰＳ／２のモデル７０及 び８０用のリファレンス・ディスケットは、これらのコンピュータに付属し且つ システム構成情報を格納するフロッピ・ディスケットから成る。ＰＳ／２の構成 手順は、極めて簡単でその実行が容易であるが、そのリファレンス・ディスケッ トは、すぐに使えるように手近の場所に置いておかなければならない。しかしな がら、最後のシステム構成から或る期間が経過すると、リファレンス・ディスケ ットを失ったり、どこかに置き忘れたりすることがあり得る。従って、リファレ ンス・ディスケットのコピーを直接アクセス記憶装置（ＤＡＳＤ）上に格納して おくことが望ましい。 本発明の譲受人に譲渡された米国特許第５１２８９９５号は、ＤＡＳＤのシス テム部分からリファレンス・ディスケッ トのイメージをロードするための装置を開示している。このＤＡＳＤの保護領域 には、ブート・レコード、ＢＩＯＳイメージ及びリファレンス・ディスケットの イメージが格納されるようになっている。ＤＡＳＤの一部を保護する理由は、Ｂ ＩＯＳの汚染及び破壊を防止する必要があるからである。所定のシステム動作の 間、例えばプロセッサがＯＳの制御下にあるか、又はこのプロセッサが或るアプ リケーションを実行している場合、ＤＡＳＤ制御装置は、この保護領域を無視す るように構成される。 現在の傾向として、複数のパーソナル・コンピュータを互いにリンクして情報 ハンドリング・ネットワーク（例えば、ＬＡＮ）を構築することが、次第に多く なってきた。このようにすると、複数のパーソナル・コンピュータが、情報を交 換したり、Ｉ／Ｏ装置を共有したり、特定のハード・ファイル又はディスケット のような特定のＤＡＳＤを利用することができるからである。典型的な情報ネッ トワークは、クライアントと呼ばれる多数の情報処理システムと、サーバと呼ば れる少なくとも１つの管理用の情報処理システムとを含んでおり、そしてこれら の全てのシステムは、銅線又は光ファイバ・ケーブルのような通信媒体を介して 互いに接続又はネットワーク化されている。サブシステム構成要素（即ち、クラ イアント又はサーバ）による典型的なネットワーク通信は、トークン・リング又 はイーサネットのような、１つ以上のネットワーク通信プロトコルに従う通信ア ダプタを介して行わ れる。更に、種々の無線又は赤外線プロトコルによってサーバに接続される処の 、無線式のモバイル・クライアントが開発された。有線式のＬＡＮに見られる前 述の諸問題は、無線式のＬＡＮについても殆どそのまま該当する。 ネットワーク化情報ハンドリング・システムの主要な利点は、複数の情報処理 システム間で種々の形式の情報を通信することができる、という能力にある。こ のネットワーク内で通信可能な情報は、情報ハンドリング・システム自体のステ ータス又は構成に係る情報を含んでいる。この構成情報は、種々の態様で（例え ば、診断を行ったり、ネットワーク化情報処理システム間で互いに構成及び機能 を通知するように）処理することができる。 従来、システム構成情報は、大型のネットワーク化システム内の障害条件を検 出するために利用されていた。例えば、ＩＢＭ社のシステム３９０は、ネットワ ーク化システム内の性能を実時間式に監視するように設計されている。障害条件 を検出すると、診断ルーチンを実行して、この障害条件を欠陥のあるシステム構 成要素として隔離した後、検出済みの障害条件及びその診断結果を、モデム及び 電話回線を介して中央ステーションに通信するようになっている。 一般に、かかる実時間式の障害監視及び障害通信機能は、システムのハードウ ェア・アーキテクチャ、ＯＳ又はアプリケーション内に取り込まれている。しか しながら、大型のコンピュータ・ネットワーク内で実現されているような実時間 式の障害検出機能は、パーソナル・コンピュータから構成されるような小型の情 報ハンドリング・システムには適していない。その一部の理由は、事実上の業界 標準となっているＯＳ（例えば、ＤＯＳ及びＷＩＮＤＯＷ）が、大型のシステム で利用可能な障害分析及び報告機能をサポートしていない、という点にある。一 層重要なことは、実時間式の構成監視、障害検出及び報告機能を実現するには、 パーソナル・コンピュータの現在の中央処理能力が十分でない、ということであ る。 しかしながら、情報ハンドリング・ネットワークを構成する小型の情報処理シ ステム（例えば、パーソナル・コンピュータ）のＯＳ及びＣＰＵの能力が、かか るネットワークを介してシステム構成情報を実時間式に通信することをサポート していないとしても、かかるネットワークを介してシステムに関係する情報を通 信するという要請が依然として存在するのである。 このような要請が取り組まれたことのある情報ハンドリング・ネットワークと は、各々が対応するＯＳ及び予定のシステム構成をそれぞれ有する複数の情報処 理システムを備え、各情報処理システムがその対応するＯＳの制御下でそれぞれ 動作するように編成されているものである。各情報処理システムは、そのＯＳを ロードする前の初期マイクロコード・ロード（以下「ＩＭＬ」と略記）期間中に 、予定のシステム構成に基づいてシステム構成中の任意の変更を検出するための 検出手段を含んでいる。また、各情報処理システムは、ＯＳをロードする前にシ ステム構成中の変更を検出したことに応答して、システム構成情報をネットワー クを介して通信するための通信手段を含んでいる。 また、この情報ハンドリング・ネットワークに含まれる管理用の情報処理シス テム（例えば、サーバ）は、このネットワークを介して行われる通信を監視する ための監視手段及びこのネットワークを介して通信されるシステム構成情報を受 信するための受信手段を有する。 システム構成情報は、システム構成中の変更がユーザによって開始された特定 の情報処理システムを識別するための情報を含むことができる。管理用の情報処 理システムは、許可信号を供給することにより、ユーザが開始したシステム構成 の変更を許可したり又は不許可にする。 ここで、図面のうち特に図１Ａを参照すると、そこには図１Ｂの情報ハンドリ ング・ネットワーク１５０（以下「ネットワーク１５０」と略記）内で動作可能 なパーソナル・コンピュータ１００（以下「システム１００」と略記）が示され ている。システム１００は、適当なケースを有するシステム・ユニット１０２、 表示モニタ１０４（例えば、通常のビデオ表示装置）、キーボード１１０、オプ ションのマウス１１２及び印刷装置１１４から成る。また、システム・ユニット １０２は、ディスケット駆動装置１０８及びハード・ファイルとも呼ばれる固定 ディスク駆動装置１０６を含むことがで きる。 図１Ｂのネットワーク１５０は、複数の情報処理システム１０２Ａ及び１０２ Ｂから成り、そのうちの少なくとも１つは、図１Ａのシステム１００と同等の構 成とすることができる。システム１０２Ａはサーバであり、ネットワーク１５０ 内の管理用の情報処理システムとして動作する。他方、システム１０２Ｂは、ク ライアントとして動作する。典型的なクライアント（１０２Ｂ）は、サーバ１０ ２Ａと同等の構成を有する。但し、システム１０２Ｂは、固定ディスク駆動装置 １０６を備えていなくてもよい（その場合、システム１０２Ｂは「メディアレス ・クライアント」と呼ばれる）。システム１０２Ａ及び１０２Ｂは、周知の方法 で互いにネットワーク化され、ケーブル１６０を介して情報ハンドリング・ネッ トワーク内で情報信号を通信する。 動作を説明すると、システム１０２Ａ及び１０２Ｂの動作を制御するためのＯ Ｓ（例えば、ＤＯＳ又はＯＳ／２）は、ＩＭＬ期間後にロードされる。一般に、 このＯＳが利用するＢＩＯＳは、ＩＭＬ期間後に主メモリにロードされるように なっている。ＢＩＯＳは、ハードウェア装置とＯＳの間のインタフェースを提供 する。これにより、プログラマ又はユーザは、特定のハードウェア装置の動作に ついて高度な知識を有さなくても、そのマシンをプログラムすることができる。 例えば、ＢＩＯＳディスケット・モジュールは、ディスケット駆動装置のハード ウェアについて高度な知識を有さないプ ログラマが、そのディスケット駆動装置をプログラムすることを可能にする。か くて、異なる企業が設計及び製造した多数のディスケット駆動装置をシステム１ ００内で使用することができる。また、ＩＭＬ期間中にロードされるＰＯＳＴは 、電源オン時にシステム・ハードウェアの自己テストを行い、システム構成を決 定するとともに、そのシステム構成をＮＶＲＡＭ内に格納する。即ち、ＰＯＳＴ は、予定のシステム構成を現在のシステム構成と比較することにより、システム 構成上の変更を検出することができる。ＢＩＯＳ及びＰＯＳＴの詳細については 、「IBM Personal System/2 and Personal Computer BIOS Interface Technical Reference 1991」を参照されたい。本明細書では、この文献を援用する。統合化プレーナ 図２には、システム１０２Ａ又は１０２Ｂの統合化プレーナ２００が示されて いる。プレーナ２００の印刷回路ボード（ＰＣＢ）２０１上には、それぞれＩ／ Ｏスロットを有する多数のＩ／Ｏバス・コネクタ２３２と、バス制御ユニット２ １４の制御下で高速のＣＰＵローカル・バス２１０を介してメモリ制御ユニット ２５６に接続されたプロセッサ２０２が実装されている。メモリ制御ユニット２ ５６は、ＲＡＭ２６４のような主メモリに接続されている。適当な任意のプロセ ッサ２０２（例えば、インテル社の８０３８６、８０４８６等）を使用すること ができる。ＰＣＢ２０１上に実装したシステム電源コネクタ２０５は、システム １００用の電力を供 給するための電源ユニット（図示せず）に接続されている。 ＣＰＵローカル・バス２１０（アドレス、データ及び制御部分から成る）は、 プロセッサ２０２、オプションの数値演算コプロセッサ２０４、キャッシュ制御 装置２０６及びキャッシュ・メモリ２０８を相互接続する。ＣＰＵローカル・バ ス２１０に結合したシステム・バッファ２１２は、システム・バス２１６（アド レス、データ及び制御部分から成る）に接続されている。システム・バス２１６ は、システム・バッファ２１２とＩ／Ｏバッファ２２８の間に延びており、バス 制御ユニット２１４及び直接メモリ・アクセス（ＤＭＡ）制御ユニット２２０に 接続されている。ＤＭＡ制御ユニット２２０は、中央アービタ２２４及びＤＭＡ 制御装置２２２を含んでいる。Ｉ／Ｏバッファ２２８は、システム・バス２１６ とＩ／Ｏバス２３０の間のインタフェースを提供する。システム１００に対し適 当なクロック信号を提供するために、発信器（ＯＳＣ）２０７が図示のように接 続されている。推奨実施例は、当該技術分野で周知のＰＳ／２のマイクロチャネ ル・バス上で実現されているが、本発明を実施するに当たって他のバス・アーキ テクチャも同様に使用できることは、当業者には明らかであろう。 Ｉ／Ｏバス２３０に接続した複数のＩ／Ｏバス・コネクタは、Ｉ／Ｏ装置又は メモリ用のアダプタ・カードを受け取るためのＩ／Ｏスロット２３２を有する。 図面の内容を簡潔にするため、図２には２つのＩ／Ｏコネクタ２３２が示されて いるに過ぎないが、特定のシステムの要件に応じて追加のＩ／Ｏコネクタを設け ることができる。図示のように、１つのＩ／Ｏコネクタは、システム（１０２又 は１０２Ｂ）用のネットワーク通信機能を提供するための、周知のトークン・リ ング式の通信アダプタ・カード２３１に接続されている。ネットワーク通信を開 始する場合、プロセッサ２０２は、周知の方法で通信アダプタ・カード２３１を 起動して、ネットワーク１５０を介してインバウンド及びアウトバウンド情報が 通信できるようにする。このため、通信アダプタ・カード２３１は、ネットワー ク１５０を介して情報を通信するために送信手段及び受信手段の両方を含んでい る。アービトレーション・バス２２６は、ＤＭＡ制御装置２２２及び中央アービ タ２２４をＩ／Ｏコネクタ２３２及びディスケット・アダプタ２４６に結合する 。システム・バス２１６に接続したメモリ制御ユニット２５６は、メモリ制御装 置２５８、アドレス・マルチプレクサ２６０及びデータ・バッファ２６２を含ん でおり、ＲＡＭ２６４によって代表されるような主メモリにも接続されている。 メモリ制御ユニット２５６は、プロセッサ２０２からのアドレスをＲＡＭ２６４ の特定領域にマップしたり、ＲＡＭ２６４の特定領域をプロセッサ２０２へのア ドレスにマップするための論理手段を含んでいる。システム１００は、１メガバ イトの容量を有する基本のＲＡＭ２６４を備えるように図示されているが、オプ ションのＲＡＭ２６６、２６８及び２７０を追加することもできる。 システム・バス２１６とプレーナＩ／Ｏバス２３４の間には、バッファ２１８ が結合されている。プレーナＩ／Ｏバス２３４は、アドレス、データ及び制御部 分を含んでいる。プレーナＩ／Ｏバス２３４に沿って、多様なＩ／Ｏアダプタ及 び周辺装置が結合されている。これを例示すると、（オプションの表示モニタ１ ０４を駆動するための）表示アダプタ２３６、クロック／ＣＭＯＳ ＲＡＭ２５ ０、ＮＶＲＡＭ２４８、直列アダプタ２４０（同期アダプタ又はＲＳ２３２アダ プタと呼ばれることもある）、並列アダプタ２３８、複数のタイマ２５２、ディ スケット・アダプタ２４６、キーボード／マウス制御装置２４４、割り込み制御 装置２５４及びファームウェア・サブシステム２４２である。一般に、ファーム ウェア・サブシステム２４２は、ＲＯＭを含んでいて、そこに「ステージＩ Ｐ ＯＳＴ」と呼ばれるＰＯＳＴ及びＢＩＯＳプログラムの一部を保持している。以 下で詳述するように、「ステージＩ ＰＯＳＴ」は、初期の及び制限されたシス テム・テストを行うために使用され、ＩＭＬイメージとも呼ばれる「ステージＩ Ｉ ＰＯＳＴ」を、ディスケット駆動装置１０８又は固定ディスク駆動装置１０ ６のような外部記憶装置からロードするためのルーチンを含んでいる。 クロック／ＣＭＯＳ ＲＡＭ２５０は、時刻を計算するために使用する。ＮＶ ＲＡＭ２４８は、システム構成を格納するために使用する。即ち、ＮＶＲＡＭ２ ４８は、システム１００の現構成（例えば、アダプタ・カードの初期データ、固 定ディスク又はディスケットの容量、主メモリの容量、等）を記述するための情 報を保持する。構成プログラムを実行するたびに、これらのデータがＮＶＲＡＭ ２４８に格納されるようになっている。この構成プログラムは、ＰＳ／２に付属 するリファレンス・ディスケット上に格納した、通常の構成情報設定プログラム とすることができる。このリファレンス・ディスケットは、診断保守又はサービ ス・ディスケットと呼ばれることもある。この構成プログラムの目的は、システ ム１００の構成を特徴づける値を予め決定し且つこれをＮＶＲＡＭ２４８に予め 格納することである。ＮＶＲＡＭ２４８は、システム１００の電源がオフとなっ てもこれらの値を保存することができるように、バッテリ・バックアップを有し 且つ消費電力の小さなＣＭＯＳメモリとすることができる。 キーボード／マウス制御装置２４４には、ポートＡ ２７８及びポートＢ ２ ８０が接続されている。これらのポートＡ及びＢは、キーボード１１０及びマウ ス１１２をシステム１００に接続するために使用される。直列アダプタ２４０に は、直列コネクタ２７６が結合されている。モデム（図示せず）のようなオプシ ョンの装置をこのコネクタ２７６を通してシステム１００に結合することができ る。並列アダプタ２３８に結合した並列コネクタ２７４には、印刷装置１１４の ような装置を接続することができる。ディスケット・アダプタ２４６に接続した ディスケット・コネクタ２８２は、１つ以上のディスケット駆動装置１０８を接 続するために使用す る。代替的なプレーナ・ボード システム１００の代替実施例に従って、統合化プレーナ２００は、プレーナ・ ボード３００及びプロセッサ・カード４００（図３及び図４を参照）によって置 き換えられる。プロセッサ・カード４００は、プレーナ・ボード３００上に取り 外し可能に実装され、これに電気的に接続されている。図３及び図４における構 成要素のうち、図２の構成要素と同じものには、後者と同じ参照番号が付されて いる。図３を参照するに、プレーナ・ボード３００のＰＣＢ３０１上には、その 内部配線又は回路により相互接続された種々の構成要素が実装（例えば、表面実 装）されている。これらの構成要素は、適当な電気コネクタ３０２を含んでいる 。このコネクタ３０２には、プロセッサ・カード４００のエッジ４１６を差し込 んで、プロセッサ・カード４００をプレーナ・ボード３００上に取り外し可能に 実装し且つこれに電気的に接続する。ＰＣＢ３０１上に実装した複数のシングル ・インライン・メモリ・モジュール（ＳＩＭＭ）コネクタ３０６は、システムの 主メモリを形成するメモリ・バンク３０８Ａ、３０８Ｂへ接続するためのもので ある。ＰＣＢ３０１上に実装した１つ以上のＩ／Ｏバス又は拡張コネクタ２３２ は、システム１００に追加又は内蔵可能な種々の拡張アダプタ又はオプションへ 接続するためのものである。例えば、固定ディスク駆動装置１０６は、小型コン ピュータ用周辺機器インタフェース（Ｓ ＣＳＩ）ディスク制御装置を有する処の、アダプタ・カード２３１に接続されて いる。アダプタ・カード２３１は、Ｉ／Ｏバス又は拡張コネクタ２３２に接続さ れている。各コネクタ２３２は、前述のマイクロチャネル・アーキテクチャに準 拠した型の市販のコネクタであることが望ましい。 また、ＰＣＢ３０１上に実装した他の構成要素には、キーボード・コネクタ２ ７８及びマウス・コネクタ２８０にそれぞれ接続した割り込み制御装置２５４及 びキーボード／マウス制御装置２４４、ディスケット・コネクタ２８２に接続し たディスケット制御装置又はアダプタ２４６、直列コネクタ２７６及び並列コネ クタ２７４にそれぞれ接続した直列アダプタ２４０及び並列アダプタ２３８があ る（これらのアダプタ２４０及び２３８は、種々のＩ／Ｏ装置をシステム１００ に接続することを可能にする）。ＰＣＢ３０１上に実装したシステム電源コネク タ２０５は、システム１００の電力を供給するための電源ユニット（図示せず） に接続されている。ＰＣＢ３０１上に実装したその他の構成要素には、ＮＶＲＡ Ｍ２４８、クロック／ＣＭＯＳ ＲＡＭ２５０、タイミング信号を供給するため の種々の発信器（図示せず）、回路の諸セクションを周知の方法で隔離するため のバッファ３４２及び３４４がある。 ＰＣＢ３０１の配線は、図示されている種々の構成要素を相互接続し、次の３ つのグループに大別される。即ち、メモリ・バス３１０（線３２４〜３３８を含 む）と、チャネル・ バス３１２（アドレス・バス３２２、データ・バス３２０及び制御バス３１８を 含む）と、割り込み線３１４及び３１６を含むその他の信号線である。これらの グループの全ては、コネクタ３０２及び４１６を通して、ＰＣＢ４０２上の対応 する配線に接続されることになる。バス３１２から分岐されているのは、プレー ナ機能バス３１９である。プロセッサ・カード 図４には、プレーナ・ボード３００上に取り外し可能に実装すべきプロセッサ ・カード４００が示されている。このプロセッサ・カード４００のＰＣＢ４０１ 上に実装（例えば、表面実装）した複数の構成要素は、プロセッサ２０２、オプ ションの数値演算コプロセッサ２０４、キャッシュ制御装置２０６、キャッシユ ・メモリ２０８、ＤＭＡ制御ユニット２２０、バス制御ユニット２１４、メモリ 制御ユニット２５６、ファームウェア・サブシステム２４２、パリティ検査ユニ ット４０２及び４０４を含んでいる。プロセッサ２０２は、例えばインテル社の ８０４８６のように、３２ビットのデータ経路及び３２ビットのアドレス指定能 力を有する高性能型であることが望ましい。もちろん、インテル社の８０３８６ 及びそれと同等のプロセッサも使用することができる。残りの構成要素は、この プロセッサとの互換性を維持するように、通常の方法で選択することができる。 複数のバッファ４０６、４０８、４１０、４１２及び４１４は、図示のように接 続されていて、諸回路間の選択的な隔離又は接続機能をそれぞれ 提供する。その目的とする処は、異なる回路を同時に使用できるようにすること であり、１例を挙げれば、プロセッサ２０２とキャッシュ・メモリ２０８の間で データを移動するのと並行して、或るＩ／Ｏ装置と主メモリ３０８Ａ、３０８Ｂ の間でデータを転送する、ということである。前述の全ての構成要素は、ＰＣＢ ４０１内の印刷配線回路によって、互いに電気的に接続されている。エッジ・コ ネクタ４１６は、図３に示したプレーナ・ボード３００上のエッジ・コネクタ３ ０２に差し込み可能であり、その場合には、プレーナ・ボード３００とプロセッ サ・カード４００を電気的に且つ機械的に相互接続することができる。かくて、 それぞれに関連する特定の型のプロセッサを有する処の、種々のバージョンのプ ロセッサ・カード４００を、プレーナ・ボード３００に差し込むことができる。 ＰＣＢ４０１の配線回路は、ローカル・バス４１８を含んでいる。このローカ ル・バス４１８は、データ線４２０、アドレス線４２２及び制御線４２４から成 り、図４に示すように、プロセッサ２０２、オプションの数値演算コプロセッサ ２０４、キャッシュ制御装置２０６及びキャッシュ・メモリ２０８を相互接続す る。残りの回路線は、一般に、割り込み線３１６、チャネル・バス線３１２及び メモリ・バス線３１０を含んでいる。チャネル・バス線３１２は、制御バス線３ １８、データ・バス線３２０及びアドレス・バス線３２２を含んでいる。他方、 メモリ・バス線３１０は、多重化メモリ ・アドレス線３２４及び３３２、メモリ・バンク３０８Ａ及び３０８Ｂ用の行ア ドレス・ストローブ（ＲＡＳ）線３２８及び３３６、列アドレス・ストローブ（ ＣＡＳ）線１３８、データ・バスＡ線３２６及びデータ・バスＢ線３３４、パリ ティ検査又はＥＣＣ検査を介したエラー検査に使用するための線３３０を含んで いる。システム１００に対し適当なクロック信号を提供するために、発信器２０ ７が図示のように接続されている。図２〜図４の内容を簡潔にするため、これら の図面では、他の種々雑多の線（例えば、リセット、接地、電源オン等）が省略 されている。 プレーナ・ボード３００及びプロセッサ・カード４００を有するシステム１０ ０の通常の動作中、プロセッサ・カード４００は、プレーナ・ボード３００に電 気的に及び機械的に接続される。この場合、プロセッサ・カード４００は、プレ ーナ・ボード３００に対し実質的に垂直な平面内に位置することが多い。 前述のように、システム・ファームウェアは、ＰＯＳＴ及びＢＩＯＳを含んで いる。また、ＢＩＯＳは、互換ＢＩＯＳ及び拡張ＢＩＯＳを含んでいる。ＰＯＳ Ｔは、システム１００の電源が最初にオンとなるときに実行すべき１組の命令を 含んでいる。現在のシステム構成が決定される場合、ＰＯＳＴの実行は、システ ム１００の初期化にとって極めて重要である。ＢＩＯＳは、プロセッサ２０２と Ｉ／Ｏ装置の間のデータ及び制御命令の転送を容易にするための１組の命令を含 んでいる。 システム１０２Ｂ（クライアント）がメディアレスで、固定ディスク駆動装置 又はディスケット駆動装置を有していない場合、通信アダプタ・カード２３１を 介して、リモート初期プログラム・ロード（ＲＩＰＬ）が行われる。この通信ア ダプタ・カードは、例えばコネクタ２３２の１つに接続されていて、周知の方法 でシステム１０２Ａ（サーバ）からＯＳをブートすることを可能にする。 ＰＯＳＴ内のブートストラップ・プログラムは、ブート装置を突き止めるとと もに、ブート・レコードをロードするように試みる。代表的なブート装置は、固 定ディスク駆動装置１０６又はディスケット駆動装置１０８であるが、メディア レス・クライアントの場合には、サーバ１０２Ａをブート装置として使用する。 ディスケット駆動装置１０８は、その動作のためにブート又はＯＳのディスケッ ト（図示せず）を必要とする。もし、ＰＯＳＴが、ブート装置からのブート・レ コードを成功裏にロードすれば、ＰＯＳＴは、このブート・レコードに制御を渡 して、そのブートストラップ・プログラムの動作を完了する。他方、ブート・レ コードがロード不能で、しかもＲＩＰＬアダプタが存在すれば、ＰＯＳＴは、ブ ート・ソースが必要であることをユーザに指示する。このシステムのブートスト ラップ動作には、互換ＢＩＯＳが不可欠である。互換ＢＩＯＳは、固定ディスク 駆動装置１０６及びディスケット駆動装置１０８へのアクセスを含む、多数のサ ービスを提供する。 システム１０２Ａ及び１０２Ｂは、ＩＭＬと呼ばれる処の、２ステージのＰＯ ＳＴを実行する。このＩＭＬは、当該技術分野では周知であり、本明細書におい て援用する米国特許第５１２８９９５号に詳細に開示されている。ＩＭＬに従っ て、プロセッサは、「ステージＩ ＰＯＳＴ」の間にファームウェア・サブシス テム２４２の内容をロードし、その諸コマンドを実行して、表示装置や所定のメ モリ・アドレスの如き所定のＩ／Ｏ装置の最小検査を行う。その後の「ステージ ＩＩ ＰＯＳＴ」の間に、プロセッサ２０２は、ＩＭＬイメージを使用してシス テム・テストを完了する。このＩＭＬイメージは、ＰＯＳＴを完了し且つプロセ ッサ２０２の制御をＯＳに渡すための諸命令を含んでいる。ＰＯＳＴの間、現在 のシステム構成を決定した後に、予め決定され且つＮＶＲＡＭ２４８内に予め格 納されているシステム構成情報と比較する。このＩＭＬイメージは、プロセッサ ２０２に特有のものであって、記憶装置のシステム区画内に格納される。もし、 この記憶装置がディスケット駆動装置１０８内のディスケットであれば、このシ ステム区画は、このディスケットの一部を占有することになる。このシステム区 画上に格納したＩＭＬイメージは、ＰＯＳＴの一部を構成するとともに、システ ム・ハードウェアを設定又は診断するための諸ルーチンを保持するリファレンス ・イメージの一部を構成する。一の構成変更に起因するエラーをＰＯＳＴが検出 する場合、このリファレ ンス・イメージがロードされて実行される。また、予め定義されたキー・シーケ ンスに応答して、このリファレンス・イメージがロードされることもある。もし 、記憶装置が固定ディスク駆動装置１０６であれば、前記のシステム区画は、重 要なＩＭＬイメージが不注意により破壊されないように、記憶媒体の保護領域に 格納される。ＰＳ／２のモデル９０及び９５では、保護されたシステム区画が記 憶媒体の最後の領域に格納されて、３メガバイトの記憶容量を占有するようにな っている。 本発明によれば、ネットワーク１５０のシステム１０２Ａ及び１０２Ｂは、Ｉ ＭＬ期間中にシステム構成中の任意の変更を検出する際に、通信アダプタ・カー ド２３１を活動化することにより、ＯＳをロードする前に、ネットワーク１５０ を介して所定のシステム構成情報を同報通信する。 図５を参照するに、その流れ図５００は、本発明の目的を達成するために取ら れる諸動作ステップを示している。システムの電源がオンになると（ブロック５ ０１）、システムは、ＩＭＬ期間中にＰＯＳＴを実行する（ブロック５０２）。 次に、このシステムは、システム構成の変更が試みられたか否かを決定する。か かるシステム構成の変更が生じ得るのは、例えば主メモリの増加又は減少のよう なハードウェア構成が変更される場合である。或いは、ユーザが予め定義された キー・ストローク・シーケンスを実行してシステム構成の変更を要求するような 場合にも、システム構成の変更がユーザか ら開始又は指示されることがある。先ず、このシステムは、ＩＭＬ期間中にＰＯ ＳＴを通してハードウェア構成の変更があったか否かを決定する（ブロック５０ ３）。このような決定を行うには、現在のシステム構成をＮＶＲＡＭ２４８に格 納した予定のシステム構成と比較すればよい。もし、ハードウェア構成の変更が 存在しなければ、ユーザが開始した構成の変更が存在するか否かを決定する（ブ ロック５０４）。この決定を行うには、周知の方法を使用して、予め定義された キー・ストローク・シーケンスをユーザが実行したか否かを検出すればよい。も し、ユーザが開始した構成の変更が存在しなければ、ＯＳがロードされる（ブロ ック５０５）。 他方、このシステムのハードウェア構成が変更されたことをＰＯＳＴが決定す れば（ブロック５０３）、所定のシステム構成情報を収集した後、ＯＳをロード する前にネットワーク１５０を介してこれを通信する。かかるシステム構成情報 は、就中、１つ以上のアダプタ・カードの障害に係るエラー・コード、ＮＶＲＡ Ｍ、ＣＭＯＳ及びＢＩＯＳデータ領域、等の情報を含んでいる。その後、システ ム区画からリファレンス・イメージをロードし且つこれを実行することにより、 現在のシステム構成をＮＶＲＡＭ２４８内に格納する。 もし、ＰＯＳＴの結果、ユーザが開始した構成の変更が試みられたことが分か れば、システム区画のアクセスが許可されているか否かを決定する（ブロック５ ０７）。もし、許可されていなければ、システム構成情報を収集し且つこれをネ ットワークを介して通信した後（ブロック５０８）、ＯＳをロードする（ブロッ ク５０９）。他方、システム区画のアクセスが許可されていれば（ブロック５０ ９）、このアクセスが、管理用の情報処理システム、即ちサーバ１０２Ａからの 許可を必要とするか否かを決定する（ブロック５１０）。もしそうでなければ、 リファレンス・イメージをロードし且つこれを実行することにより、ユーザが変 更したシステム構成を許可する。他方、システム区画のアクセスがサーバ１０２ Ａからの許可を必要としていれば、変更すべきシステム構成の識別子を含むシス テム構成情報の変更要求を、通信アダプタ・カード２３１を通して、サーバ１０ ２Ａへ通信する（ブロック５１１）。もし、サーバ１０２Ａが許可を与えなけれ ば、ＯＳをロードする（ブロック５１０及び５０５）。 図６には、図５のブロック５０６及び５０８の間に取られる諸ステップの一層 詳細な流れ図６００が示されている。システム構成の変更（ハードウェアの変更 又はユーザが開始した構成の変更）を検出すると、通信アダプタ・カード２３１ を活動化する（ブロック６０１）。次に、このシステムは、ＮＶＲＡＭ２４８か ら予定のシステム構成を収集するためのドライバをロードする（ブロック６０２ ）。このドライバは、種々の装置からこのシステムの現在のハードウェア構成を 収集する（ブロック６０３）。次に、エラーに関係する情報、即ちハードウェア 構成変更のエラー・コード又はユーザ・アクセス要求情報を収集する（ブロック ６０４）。前述の諸ス テップの間に収集した全ての情報をフォーマット化し且つこれを通信アダプタ・ カード２３１を通してネットワーク１５０上に通信する。 サーバ１０２Ａは、通信アダプタ・カード２３１を通して、通信されたシステ ム構成情報を受信する。サーバ１０２Ａは、ネットワーク１５０上の通信を監視 するためのソフトウェア・ルーチンの形態であることが好ましい、監視手段を含 んでいる。前記システム構成情報を検出する場合、サーバ１０２Ａは、この情報 を受信するとともに、これをＤＡＳＤのような永続記憶媒体内に格納する。この ような格納情報をフォーマット化することが好ましく、また後の処理に備えて時 刻スタンプを付すことが好ましい。 ネットワーク１５０内の各システムは、本発明に従って通信されるシステム構 成情報を受信する機能を有する。これらのシステムが受信した情報は、各受信シ ステムに対し、ネットワーク１５０内の他のシステムの諸機能を通知して、これ らのネットワーク機能を十分に活用するように各受信システムのハードウェアを 適応させることを可能にする。 前述の内容から明らかなように、本発明は、ＯＳ又は他の任意のアプリケーシ ョンをロードする前に、システム構成情報の通信機能を提供する。かくて、通常 のＯＳを搭載した情報処理システム（例えば、ＩＢＭ互換マシン）から成る情報 ハンドリング・ネットワークが、この有用なネットワーク機能を活用することが できるようになる。また、本発明によれ ば、起動時であって、しかもＯＳをロードする前に、必要に応じてシステム構成 情報を通信することができるので、各システムは構成の監視タスクを実時間式に 行うことから解放されることになる。ソフトウェア環境 概要：オブジェクト指向技術 本発明は、オブジェクト指向のフレームワーク技術を使用して、これを実現す ることができる。かかるフレームワーク技術について十分な知識を有する当業者 は、以下の概要に係る説明をスキップしてもかまわない。しかしながら、オブジ ェクト指向技術やフレームワーク技術の知識が十分でない当業者については、本 発明の利点を理解するために、以下の概要に係る説明を十分に検討すべきである 。オブジェクト指向技術と手続き型技術との対比 本発明は特定のオブジェクト指向技術に係るが、ここで最初に理解すべきは、 一般に、オブジェクト指向技術が通常の手続き型技術（プロセス型技術とも呼ば れる）と著しく異なる、という点である。これらの技術は、両者とも同じ問題を 解決するために使用することができるが、この問題に対する最終的な解は、常に 著しく異なっている。その原因は、手続き型技術の設計目標がオブジェクト指向 技術のそれと根本的に異なっている、という点にある。即ち、手続き型技術の設 計目標が、問題を解決するプロセスの全体に向けられているのに対し、オブジェ クト指向技術の設計目標は、問題の解を 与えるために、この問題を作業可能な１組の自律走行式エンティティ（オブジェ クトと呼ばれるもの）にどのようにして分解することができるか、ということに 向けられている。別言すれば、オブジェクト指向技術が手続き型技術と著しく異 なっている理由は、それぞれの問題が互いに協働する１組のオブジェクトに還元 され、ネストされたプログラム又は手続きの階層構造に還元されるのではないか らである。用語「フレームワーク」 オブジェクト指向技術の専門家にとって特定の意味を有する用語や他の表現は 、時代とともに次第に発展してきた。しかしながら、オブジェクト指向分野にお いて最も曖昧な定義の１つは、「フレームワーク」という用語の定義である。な ぜなら、フレームワークという用語は、人が変わればその意味も変わってくるか らである。従って、想定した２つのフレームワーク機構の特性を比較する場合、 この比較が適正な比較対象について行われていることに留意すべきである。以下 の説明から明らかなように、本明細書では、コア機能及び拡張可能な機能を有す るように設計されたオブジェクト指向機構を意味するものとして、「フレームワ ーク」という用語を使用する。コア機能とは、フレームワークの消費者による修 正の対象とはならない処の、フレームワーク機構の部分である。他方、拡張可能 な機能とは、フレームワークの消費者によってカストマイズ及び拡張されるよう に明示的に設計した処の、フレームワーク機構の部分である。オブジェクト指向のフレームワーク機構 一般に、オブジェクト指向のフレームワーク機構は、オブジェクト指向の解と して適正に特徴づけることができるが、フレームワーク機構と基本的なオブジェ クト指向の解との間には、根本的な相違点が存在する。この相違点は、フレーム ワーク機構が、この解の或る側面のカストマイズ及び拡張を許容し且つこれを促 進するように設計されていることに由来する。別言すれば、フレームワーク機構 は、問題に対する解を与えるのに留まらない。なぜなら、フレームワーク機構は 、時間の経過とともに変わる個別の要件に取り組むためにカストマイズ及び拡張 可能であるという意味の、生きている解を与えるからである。もちろん、フレー ムワーク機構のカストマイズ／拡張性は、フレームワークの消費者にとって極め て価値がある。なぜなら、フレームワークをカストマイズ又は拡張するのに要す るコストは、既存の解の置き換え又はその再作業を行うのに要するコストよりも ずっと少ないからである。 従って、フレームワーク設計者（以下「設計者」と略記）が特定の問題を解決 せんとする場合、この設計者は、単に個々のオブジェクトや、これらのオブジェ クトの相互関係を設計しているのに留まらない。この設計者は、そのフレームワ ークのコア機能（即ち、フレームワーク消費者による潜在的なカストマイズ及び 拡張の対象とすべきでないフレームワークの部分）及び拡張可能な機能（即ち、 潜在的なカストマイ ズ及び拡張の対象とすべきフレームワークの部分）をも設計するからである。要 するに、フレームワーク機構の最終的な価値は、オブジェクト設計の品質だけに あるのではなく、フレームワークのどの側面がコア機能を表し且つどの側面が拡 張可能な機能を表すかということを含む、設計上の選択肢にもある。ＺＡＦ：例示的なフレームワーク機構 当業者には明らかなように、フレームワークの設計は、必然的に絡み合った反 復的プロセスとなるが、以下では、簡略化したフレームワーク機構の設計上の選 択肢を例示する。当然のことなから、この例示的フレームワークは、本発明の利 点を理解することができるように、フレームワーク機構を説明するための便宜上 のものであるに過ぎない。 この設計者は、問題ドメインから諸オブジェクトを選択することによって、或 るフレームワーク機構に必要な諸オブジェクトを決定する。問題ドメインとは、 解決すべき特定の問題の抽象的な表示である。このフレームワーク機構について 選択した例示的な問題ドメインは、動物園の管理用のそれである。特定の問題は 、動物園の動物（animal）を世話し且つ給餌する際に、飼育係（zoo keeper）を 援助するための機構を設計することである。これから例示的に説明する動物園管 理用フレームワーク（Zoo Administration Framework：以下「ＺＡＦ」と略記） では、この設計者は、動物に関する問題ドメインを調べた上で、任意のＺＡＦが 飼育係と動物の間の 関連を表現した機構（即ち、飼育係が行うべき動物の飼育方法を表現した機構） を必然的に含んでいるのを決定することになろう。また、この設計者は、動物が 、檻、囲い、水槽及び他の収容ユニット（containment unit）内で生息している のを認識することになろう。従って、この設計者は、かかるフレームワークが、 これらの３つのエンティティ及び関連の全てを表現した機構を包含しなければな らない、という着想から出発することになろう。 設計プロセスから説明すると、この設計者は、カテゴリ図と呼ばれるものから 出発する筈である。カテゴリ図とは、高レベルの複数のフレームワーク機構が互 いにどのように関係しているかを記述するのに使用されるものである。図７は、 ＺＡＦのカテゴリ図である。カテゴリ図にある各機構は、特定の機能を遂行する 諸オブジェクトのグループ化を表している。説明の便宜上、この設計者が、ＺＡ Ｆを４つの高レベルの機構（即ち、管理用の機構、飼育係の機構、動物の機構及 び収容ユニットの機構）から構成しなければならない、と決定するものと仮定す る。 管理用の機構は、動物園を管理するために、飼育係の機構を使用するように設 計されている。従って、管理用の機構は、飼育係の機構との使用関連を有してい ると云われる。 前述の如く、管理用の機構は、ＺＡＦの全体を制御するための責任を有するよ うに設計されている。従って、管理用の機構は、飼育係の機構の動作をスケジュ ールするための責任 を有する。ここで、この設計者が、管理用の機構をＺＡＦのコア機能として設計 した、という点に留意すべきである。つまり、管理用の機構は、潜在的なカスト マイズ及び拡張の対象とならないように設計されている。図７のカテゴリ・ボッ クス内の記号「Ｃ」は、かかるコア機能を意味する。また、管理用の機構と飼育 係の機構の間の使用関連も、フレームワーク消費者による最終的なカストマイズ に利用できないように設計されている。 飼育係の機構は、総じて動物の世話及び給餌について責任を有するように設計 されている。従って、飼育係の機構は、そのタスクを遂行するために、動物の機 構及び収容ユニットの機構を使用する。しかしながら、管理用の機構の設計と異 なり、この設計者は、飼育係の機構を拡張可能な機能として設計した。つまり、 飼育係の機構は、動物の世話及び給餌の将来の要件に取り組むために、フレーム ワーク消費者が変更及び／又は拡張するのに使用することができるように設計さ れている。図７のカテゴリ・ボックス内の記号「Ｅ」は、かかる拡張可能な機能 を意味する。 この設計者は、動物と飼育係の間の動物側の対話を表すように、動物の機構を 設計している。動物園内の動物の総数は定期的に変動するのが普通であるから、 動物の機構は、これを反映して拡張可能な機能として設計されている。収容ユニ ットの機構は、（囲いや水槽や檻などの）個々の収容ユニットを表すことにより 、飼育係の機構と対話する。動物の機構 と同様に、収容ユニットの機構は、将来のカストマイズ及び拡張要件を処理する ことができるように、拡張可能な機能として設計されている。ここで、飼育係、 動物及び収容ユニットのそれぞれの機構の全てが拡張可能な機能として設計され ているとしても、これらの機構の間の関連は、ＺＡＦのコア機能として設計され ていることに留意されたい。別言すれば、フレームワークの消費者（以下「ＺＡ Ｆ消費者」と表記）に対し飼育係、動物及び収容ユニットの機構に関する柔軟性 を与えることが望ましいとしても、これらの機構の間の関連を、ＺＡＦ消費者が 変更することを許容するのは望ましくない、ということである。 次に、この設計者は、図７の諸機構を構成する処の、諸クラス及び諸関連を設 計することになろう。クラスとは、１組の同様のオブジェクトの定義である。か くて、クラスとは、これらのオブジェクトの抽象概念又はオブジェクトの或る型 の定義であると考えることができる。コンピュータ・システムの観点からすれば 、単一のオブジェクトは、カプセル化した１組のデータ及びかかるデータについ てコンピュータ・システムが遂行するような単一又は１群の動作を表す。事実、 安全なコンピュータ・システムでは、或るオブジェクトによって制御された情報 をアクセスするには、このオブジェクト自体を介して行わなければならない。こ のことが、オブジェクト内に保持された情報がこのオブジェクトによってカプセ ル化されている、と云われる所以である。 各クラス定義は、そのオブジェクトによって制御される情報を定義するための データ定義と、そのオブジェクトが制御するデータについて諸オブジェクトによ って遂行される１つ又は１組の動作を定義するための動作定義とから成る。別言 すれば、クラス定義とは、定義されたデータについて遂行される１つ又は１組の 動作を定義することによって、或るオブジェクトが他のオブジェクトに対しどの ように作用及び反応するかを定義するものである（これらの動作は、メソッド、 メソッド・プログラム及び／又はメンバ＿機能と呼ばれることもある）。まとめ て考える場合、かかる定義済みの動作及びデータは、そのオブジェクトの振る舞 い（behaviour）と呼ばれる。要するに、クラス定義とは、その１つ以上のメン バ・オブジェクトの振る舞いを定義するものである。 図８は、この設計者がＺＡＦ用に設計した諸基本クラスを示す処の、オブジェ クト指向のクラス図である。各クラス表示は、図７の諸機構に対するその関連を 含んでいる。例えば、飼育係のクラスは、飼育係の機構からのものであると表示 されている。ＺＡＦの諸基本クラスが含んでいるのは、動物園の管理者のクラス （管理用の機構の一部）、飼育係のレジストリ・クラス（管理用の機構の一部） 、動物のレジストリ・クラス（飼育係の機構の一部）、飼育係のクラス（飼育係 の機構の一部）、収容ユニットのレジストリ・クラス（飼育係の機構の一部）、 動物のクラス（動物の機構の一部）、収容ユニットのクラス（収容ユニットの機 構の一部）である。 ここで、これらのクラスの間の関連は、ＺＡＦのコア機能として設計されてい るので、ＺＡＦ消費者がこれらを最終的に変更できないことに留意されたい。 管理者のクラスは、ＺＡＦの制御全般に責任のあるオブジェクトの定義である 。ここで、オブジェクト指向の全てのクラスは、特定の問題の解を与えるように 対話する処の、複数のオブジェクトを定義することを想起されたい。しかしなが ら、生きている解（即ち、将来の諸要件に取り組むようにカストマイズ及び／又 は拡張可能な解）を与えるために、それぞれのフレームワーク機構のそれぞれの オブジェクトがどのように設計されているかを理解するには、これらのクラス定 義の特性を調べることが必要である。 管理者のクラスは、飼育係のレジストリとの使用関連を有するように設計され ている。この設計者は、管理者のクラス及びレジストリ・クラスを、ＺＡＦのコ ア機能として設計している。なぜなら、この設計者は、ＺＡＦ消費者が、これら のクラス定義のメンバである諸オブジェクトの振る舞いを変更できないようにす べきであると決定したからである。飼育係のレジストリは、飼育係のクラスに対 し「a contains by reference」と呼ばれる関連を有するクラスであって、飼育 係のオブジェクトの全ての収容体であるようなオブジェクトを定義する。従って 、飼育係のレジストリは、「list_zoo_keepers()」動作の定義を含んでいる。後 述するように、この動作は、飼育係のオブジェクトのリストを、当該リストを要 求 する他のオブジェクトに与える責任を有する。 図９は、管理者のクラスの下位レベル表示である。管理者の型の諸オブジェク トは、ＺＡＦの制御全般について責任を有するから、管理者のクラスは、動物園 の管理に向けられた諸タスクを遂行するための諸動作を含むように設計されてい る。このクラス定義は、次の５つの動作を含んでいる。 5_minute_timer(); add/delete_animal(); add/delete_containment_unit(); add/delete_zoo_keeper(); start_zoo_admin()。 前記の「start_zoo_admin()」動作は、ＺＡＦを開始する責任を有する。即ち 、ユーザ又はシステム管理者が「start_zoo_admin()」動作と対話することによ り、ＺＡＦを介して動物園の管理を開始する、ということである。この設計者は 、一旦開始されると、「5_minute_timer()」動作を開始するように、「start_zo o_admin()」動作を設計している。この「start_zoo_admin()」動作は、飼育者の 諸オブジェクトに対し、外に出て動物を調べるように、５分ごとに命令する。「 add/delete_zoo_keeper()」動作の責任は、ＺＡＦのユーザと対話することを通 して、追加の飼育係を定義し（即ち、追加の飼育係のクラス）、追加の飼育係を 加え（即ち、飼育係のオブジェクト）、飼育係のクラス及び／又はオブジェクト を除去することである。明らかに、飼育係のオブジェクトの各々は、 動物園内の特定のタスクを遂行する責任を有する。従って、ＺＡＦのユーザの希 望に応じて、追加のタスクを取り扱うために飼育係の定義及びオブジェクトを追 加したり、もはや必要でなくなった定義又はオブジェクトを除去することができ る。この柔軟性は、飼育係の機構を拡張可能な機能として設計することに由来す るものである。 前記の「add/delete_zoo_keeper()」動作と同様に、「add/delete_animal()」 動作の責任は、ユーザと対話することを通して、動物の追加のクラス及びオブジ ェクトを定義し、もはや必要でなくなったクラス及びオブジェクトを除去するこ とである。動物園にとっては、動物を追加したり除去することは、極めて自然で あるからである。「add/delete_containment_unit()」動作の責任は、収容ユニ ットの新しいクラス及びオブジェクトを定義するとともに、もはや必要でなくな ったクラス及び／又はオブジェクトを除去することである。この柔軟性を得るた めに、この設計者は、動物の機構及び収容ユニットの機構を拡張可能な機能とし て設計している。 再び図８を参照するに、飼育係のクラス定義は、動物のレジストリ、動物、収 容ユニットのレジストリ及び収容ユニットのクラスとの使用関連を有する。ＺＡ Ｆの価値を強化するには、飼育者、動物及び収容ユニットのクラスをＺＡＦ消費 者がカストマイズ及び拡張できるようにすればよいから、これらのクラスは拡張 可能な機能として設計されている。しかしながら、動物及び収容ユニットのレジ ストリ・クラスの振 る舞いを変更すると、ＺＡＦの基本動作を混乱させることになりかねない。従っ て、これらのクラスは、ＺＡＦのコア機能として設計されている。 図１０は、飼育者のクラスのクラス図である。図１０の詳細を説明するに先立 ち、図１０のクラス定義が、「クラス階層」と呼ばれる非常に簡単な配列内でラ ンクされていることを指摘しておく。或るクラス階層において最も一般的／抽象 的なクラスを表すようなクラス（例えば、飼育者のクラス）は、この階層の基本 クラスと呼ばれる。或るクラス階層における諸クラスの配列は、最も抽象的なも のから最も具体的なもの（即ち、一般から特殊）に移行する。一般性が比較的少 ないクラス（例えば、給餌係のクラス）は、これより一般的な１つ以上のクラス （例えば、飼育係のクラス）からの特性を継承すると云われる。かくして、給餌 係、獣医（veterinarian）及び温度制御係のクラス定義は、飼育係のクラスのサ ブクラスであると云われる。継承機構については、図１１を参照して以下で詳述 する。 図１０に示すように、飼育係のクラス定義は、「check_animals()」動作の単 一の定義を含んでいる。また、飼育者のクラスが、抽象クラスとしてマークされ ていることに留意されたい。抽象クラスとは、そのメンバとして作成されたオブ ジェクトを有するように設計されておらず、その代わりに、その諸サブクラス用 の共通のインタフェース／プロトコルを定義するために使用される。或るクラス が抽象クラスであると 云われるのは、その少なくとも１つの動作定義が、純粋で仮想的な動作定義であ る場合である。かかる純粋で仮想的な動作定義を定義する目的は、その動作のサ ブクラス定義用の共通のインタフェースを定義するためだけにある。別言すれば 、実際の振る舞い（即ち、データ及び動作）の設計は、サブクラス自体に任され るのである。飼育係のクラス定義の場合は、給餌係、獣医及び温度制御係のサブ クラス定義が、飼育係のクラスに含まれている処の、純粋で仮想的な「check_an imal()」動作定義の特定の実現体を規定する。或る動作がゼロに等しく設定され ると、この動作は、純粋で仮想的なものとマークされることになる。 尤も、純粋で仮想的な動作定義の共通なインタフェースを、全てのサブクラス が尊重しなければならないことに留意する必要がある。即ち、要求元のオブジェ クト（クライアント・オブジェクトと呼ばれるもの）がサブクラスのメンバ・オ ブジェクト（サーバ・オブジェクトと呼ばれるもの）を使用することが可能であ り、しかもその場合において、このサーバ・オブジェクトの特定のサブクラスを 知る必要がない、ということである。例えば、動物園の管理者のクラスによって 定義されたオブジェクトが特定のアクションの遂行を必要とする場合、このオブ ジェクトは、常に飼育者のオブジェクトと対話することになる。これらのオブジ ェクトに対するインタフェースは抽象的に定義されたから、基本クラスの飼育係 及び「check_animal()」動作用のサブクラス定義内に保持され た管理者のオブジェクトは、任意のサーバ・オブジェクトの諸サブクラスに関す る特別の知識を有する必要がない。この結果、（管理者のオブジェクトの側にお ける）アクションの必要性を、このアクションを（飼育係のサブクラスのオブジ ェクトの１つによって）実行する方法から隔離することができる。抽象クラスの 特性を活用する（ＺＡＦの設計と同様の）設計は、ポリモアフィック（polymorp hic）であると云われる。 かかるポリモアフィズム（polymorphism）がオブジェクト指向のフレームワー ク設計にとって極めて重要である理由は、アクションが実際に行われているとい う事実に依存するような機構を生じさせることなしに、何かが行われる方法（実 現体と呼ばれるもの）を変更又は拡張することが可能となるからである。別言す れば、クライアント・オブジェクトは、所定のオブジェクトが所定の機能を遂行 することだけを理解すれば十分であって、これらの機能が実際にどのように遂行 されるかを理解する必要はないのである。この方法を使用すれば、将来の諸要件 を満足するように、適正に設計されたフレームワークのカストマイズ及び拡張を 容易に行うことができる。 前述の通り、この設計者は、飼育係のオブジェクトが動物のオブジェクト及び 収容ユニットのオブジェクトと対話してそれらのタスクを遂行するように、ＺＡ Ｆを設計している。図１１は、抽象クラスである動物のクラス階層についてのク ラス図である。動物のクラス定義は動物の特性及び振る舞い を表現する責任を有するから、この設計者は、この責任を反映するように抽象ク ラスである動物を設計している。図示の如く、例示的な動物のクラス定義は、デ ータ定義の「feed_freq」、「location」及び「temp_range」と、動作定義の「g et_temp_range()」、「feed()」、「needs_food()」及び「vet_visit()」を含ん でいる。 このフレームワークの全容を理解するには、各定義を詳細に調べる必要はない 。しかしながら、データ定義の「temp_range」、並びに動作定義の「get_temp_r ange()」及び「feed()」は、十分に考えられたフレームワーク設計の選択肢の良 い例である。 「feed()」動作定義は、（図示されていない特定の給餌装置を通して）動物へ の実際の給餌を遂行するように設計されている。かかる「feed()」動作は、純粋 で仮想的な動作である。このことは、このクラスの設計が次のようなものである こと、即ち必要な機能を遂行する実際の機構がその諸サブクラスによって定義さ れることを意味する。説明中の例では、諸サブクラスのメンバとして作成される 諸オブジェクトがそれぞれ特殊化されたニーズを有しているので、このようにサ ブクラス定義に任すことは、良い設計方法である。例えば、ＺＡＦでは、動物の それぞれの型ごとに特定の給餌装置が必要となる公算が大きいから、一般的な「 feed()」動作を定義することは困難であるばかりでなく、無駄でもある。 比較のため、この設計者は、「get_temp_range()」動作を、 純粋で仮想的な動作定義ではないように、明示的に設計している。このことは、 「get_temp_range()」動作がデフォルト動作として一般的に定義されていること を意味する。かくて、これは仮想的な動作であると見なされる。デフォルト動作 は、諸サブクラスに対し一般的な機能を与えるために使用されるものである。こ れらのサブクラスは、単にデフォルト動作を使用するか、或いは再定義によって デフォルト動作をカストマイズ又は拡張することができる。 哺乳動物は、動物のクラスのサブクラスであるから、後者の全ての特性を継承 する。これに関連して、哺乳動物のクラスが抽象クラスとしても定義されること に留意されたい。つまり、このクラスがそのメンバとして作成されたサブクラス を有するように設計されていないが、その代わりに、その諸サブクラス用の共通 のインタフェースを与えるように設計されている、ということである。哺乳動物 のサブクラスは、更に肉食動物及び草食動物のクラスにサブクラス化される。 「feed()」動作の定義は、それぞれのサブクラスに任されているから、肉食動 物及び草食動物のサブクラスの各々は、「feed()」動作のそれ自体の定義を有す る。これが良い設計方法である所以は、肉食動物のニーズと草食動物のニーズが それぞれ異なるからである。 「temp_range」データ定義は、特定の動物が自然に生息する場所のそれと一致 するような温度の範囲を定義し、「get_temp_range()」動作定義は、特定の動物 に対する「temp_ran ge」を検索し且つこれを要求元のクライアント・オブジェクトに戻すように設計 されている。爬虫動物のサブクラスは、それ自体の「temp_range」データ定義と 、それ自体の「get_temp_range()」動作定義を含んでいる。ＺＡＦは、動作定義 と同様にデータ定義が変更可能であることを記述するように、設計されている。 多くの爬虫動物は、夜が非常に寒く且つ日中が非常に暑い砂漠条件下で生息して いるから、爬虫動物のクラスに関しては、時刻及び温度情報を含むようにデフォ ルトの「temp_range」定義が変更されている（図１１には明示せず）。これが良 い設計方法である所以は、時刻及び爬虫動物の収容ユニット自体の現在の温度に 基づいて温度調整を行うことができるように、ＺＡＦが、爬虫動物の収容ユニッ トを他の収容ユニットとは異なる態様で扱うことを可能にするからである。 図１２は、収容ユニットのクラスの下位レベル表示のクラス図である。収容ユ ニットのクラスは、仮想的な動作定義である処の、「adjust_temp()」を含んで いる。かかる「adjust_temp()」動作定義は、動物園の諸収容ユニット内の温度 を（図示しない加熱及び冷却機構を介して）実際に調整するために使用されるよ うな、インタフェース及び機構の両方を定義する。ＺＡＦの諸オブジェクトが対話する方法 特定の問題に対する解を構成する諸オブジェクトを設計することに加えて、こ の設計者は、個々のオブジェクトがどの ように対話するかということも設計しなければならない。別言すれば、これらの オブジェクトは、その設計方法を活用するように相互に関係しなければならない 。前述のように、或るオブジェクトの定義済みの動作がこのオブジェクト用に定 義したデータを操作する方法は、このオブジェクトの振る舞いと呼ばれる。それ ぞれのオブジェクトは、自律走行式エンティティとして特徴づけることができる が、依然として重要なことは、各オブジェクトが他のオブジェクトと相互に関係 するときに、一貫性のある振る舞いを呈することである。なぜなら、オブジェク ト自体が一貫性のある振る舞いを呈するためには、これらのオブジェクトが、他 のオブジェクトの一貫性のある振る舞いに依存することになるからである。事実 、一貫性のある振る舞いが非常に重要であることは、或るオブジェクトの振る舞 いを、このオブジェクトが他のオブジェクトと有する契約と呼んでいることから も明らかであろう。或るオブジェクトが一貫性のある振る舞いを呈さない場合、 このオブジェクトは、他のオブジェクトとの契約に違反したと云われる。 第１のオブジェクトの動作が第２のオブジェクトの制御下にあるデータのアク セスを必要とする場合、第１のオブジェクトは、第２のオブジェクトのクライア ントであると見なされる。第２のオブジェクトの制御下にあるデータをアクセス するために、このクライアントの１つの動作は、第２のオブジェクトの１つの動 作を呼び出して、このデータへのアクセ スを獲得する。次に、呼び出されたオブジェクトの１つの動作（即ち、本例の場 合は、サーバ動作）を実行して、呼び出されたオブジェクトの制御下にあるデー タをアクセス及び／又は処理する。 図１３のオブジェクト図は、動物園の職員を援助して動物園を運営するために 、ＺＡＦの例示的な諸オブジェクトがどのように対話するかを示している。この 全容を理解するには、ＺＡＦの全てのオブジェクトの対話を詳細に解析すること は必要ではない。しかしながら、諸問題を解決するためにこれらのオブジェクト がどのように対話するかを一般的に理解するには、以下で説明する簡単な制御の 流れを検討するのが有用であろう。 前述の如く、オブジェクトは、特定クラスのメンバとして作成される。従って 、動物園の管理者の「Zelda」（オブジェクト７０６）は、管理者のクラスのメ ンバ（実際には唯一のメンバ）であるようなオブジェクトである。かくて、「Ze lda」のオブジェクトは、ＺＡＦの制御全般について責任を有する。飼育係のオ ブジェクトの全ては、飼育係のレジスタ・オブジェクト（オブジェクト７００） に登録されている。従って、「Zelda」のオブジェクトは、飼育係のレジスタ・ オブジェクトの「list_zoo_keepers()」動作を呼び出して（ステップ１）、現在 の飼育者のリストを獲得する。飼育係のレジスタ・オブジェクトは、飼育係のレ ジスタ・クラスのメンバとして作成されている。説明の便宜上、これが「Zelda 」の「5 _minute_timer()」動作の一部として５分ごとに生ずるものと仮定する。次に、 飼育係のレジスタ・オブジェクトは、「keepers_list」に応答する（ステップ２ ）。この飼育係のリストは、温度検査係の「Tina」（オブジェクト７１４）、獣 医の「Vince」（オブジェクト７４０）、食餌係の「Fred」（オブジェクト７５ ２）を含んでいる。飼育係の各々は、飼育係のクラスのメンバとして作成されて いる。特に、温度検査係の「Tina」、獣医の「Vince」及び食餌係の「Fred」の オブジェクトは、温度制御係、獣医及び食餌係のサブクラスのそれぞれのメンバ である。「Temp()」動作は、ポリモアフィックである。別言すれば、オブジェク ト「Tina」の「check_animals()」動作は、「adjust_temp()」動作の各々がその タスクをどのように遂行するかということに関する特殊な知識を必要としない。 従って、「check_animals()」動作は、インタフェースによって単に「adjus_tem p()」動作を呼び出すことに留まるのである。その後は、個々の「adjust-temp() 」動作が、それらのタスクを適正に行うことになる。 以上で、ＺＡＦの機構を説明したのは、これが極めて簡単なフレームワーク機 構であって、当業者がその幾つかのフレームワーク概念を理解することを通して 、本発明の利点を十分に認識することができると考えられるからである。これら の利点は、以下の説明を参照すれば一層明らかとなろう。 ここで、図１４Ａ、図１４Ｂ及び図１５を参照して、説明を続ける。図１４Ａ 及び図１４Ｂは、前述の文脈において、 本発明のフレームワーク（以下「管理フレームワーク」と表記）を例示し、図１ ５は、この管理フレームワーク内で使用される特定のオブジェクトを例示する。 図１４Ｂは高レベルのブロック図であり、図１４Ａは低レベルの詳細を示す図で ある。図１４Ａ及び図１４Ｂの管理フレームワークは、以下の要素を有する。 ウェブ・ブラウザ； マッピング・ブロック； サーバ層；及び ＯＳ。 この実施例のマッピング・ブロックは、インターネット上の任意のブラウザを 有する任意のユーザに対し、システム管理プロトコルのイベント監視及び制御手 段を提供する。マッピング・ブロックは、ブラウザ上で表示するためにプロトコ ル・サービスの内部データをＨＴＭＬに変換し、ＨＴＭＬとしてのユーザの入力 をプロトコル・サービスの制御信号に変換する。 本発明のユーザは、現に市販中の任意のものでよいブラウザから、システムを 監視及び制御する。 マッピング・ブロックは、インターネット上のウェブ・ブラウザに、静的形式 （例えば、ＨＴＭＬ形式）又は動的形式（例えば、Ｊａｖａ形式）のアプレット を供給する。これらの形式又はアプレットは、システム管理プロトコルからの監 視情報を供給するか、又はシステム管理プロトコル内でイベ ントを生成するための入力手段を供給する。 ブラウザへのユーザ入力は、このユーザが監視することを望んでいる監視対象 又はこのユーザが望んでいる制御方法を指示する。これらのユーザ入力は、前記 形式又はアプレットが与える諸命令の制御下で、ブラウザを介して、マッピング ・ブロックに返送される。マッピング・ブロックとブラウザの間で交換すべきデ ータは、ＨＴＭＬのような標準言語の形式を有し、ＨＴＴＰプロトコルを使用し てインターネットを介して伝送される。 マッピング・ブロックは、システム管理プロトコルのサービス層と直接的に通 信する。実際、マッピング・ブロックは、このサービス用のＧＵＩになる。サー バは、インターネットを介して受信したＨＴＭＬを、サービス層に与えられる諸 コマンドに変換する。かくて、サービス層は、ＯＳを通して諸要求を実行する。 本発明は、ＤＭＩ、ＳＮＭＰ、ＣＭＩＰ及びＣＭＯＬシステム管理プロトコル 用の、プラットフォーム独立のインターネット上のブラウザを許容する。 マッピング・ブロックは、ウェブ・ブラウザからのＨＴＴＰ要求をサービス層 に固有の呼び出し（コール）に変換する処の、ＨＴＴＰサーバとして設計するこ とができる。このサービス層から戻されたデータは、ＨＴＭＬに変換されてブラ ウザに戻される。このようにすると、実質的にプラットフォーム独立のウェブ・ ブラウザから、ＤＭＩ、ＳＮＭＰ、ＣＭ ＩＰ、ＣＭＯＬ又は他の任意のシステム管理プロトコルを管理することができる 。 他の実施例として、図１４Ａ及び図１４Ｂの管理フレームワークは、次の要素 を含んでいる。 ＨＴＴＰ要求元； マッピング・ブロック； トランスポート層；及び ＨＴＴＰサーバ。 本発明のこの実施例は、マッピング・ブロックを通して、ＨＴＴＰをトランス ポート層が使用するプロトコル独立の諸コマンドに変換するための管理フレーム ワークを提供する。ＨＴＴＰ要求元とマッピング・ブロックの間の通信は、２つ の型のうちの何れかとすることができる。マッピング・ブロックは、ＴＣＰ／Ｉ ＰからのＨＴＴＰ要求を受理し、これを NetＢＩＯＳ、ＩＰＸ又は直列プロトコ ルを備えたトランスポート層を通して経路指定する処の、ゲートウェイ式のＨＴ ＴＰサーバとすることができる。この方式によれば、一般的なウェブ・ブラウザ を使用して、ＴＣＰ／ＩＰに直接に接続されていないＨＴＴＰサーバに到達する ことが可能になる。ＴＣＰ／ＩＰ接続を持たないコンピュータについては、ＨＴ ＴＰ要求元又はウェブ・ブラウザをマッピング・ブロックと直接に統合化しなけ ればならない。 本発明を実現するには、例えば、マッピング・ブロックを含むようにブラウザ のバッタエンドに再書き込みを行うか、 又はこのブラウザによって送信されるＨＴＴＰ要求用のゲートウェイとして機能 するマッピング・ブロックを開発すればよい。 更に他の実施例として、図１４Ａ及び図１４Ｂの管理フレームワークは、次の 要素を含んでいる。 ウェブ・ブラウザ； マッピング・ブロック； トランスポート層；及び システム管理ベース。 この実施例のマッピング・ブロックは、インターネット上の任意のブラウザを 有する任意のユーザに対し、システム管理の監視及び制御手段を提供することを 可能にする。マッピング・ブロックは、ブラウザ上で表示するためにシステム管 理ソフトウェアの内部データをＨＴＭＬに変換し、ＨＴＭＬとしてのユーザ入力 をシステム管理ソフトウェアの制御信号に変換する。ウェブ・ブラウザを除くと 、この管理フレームワークの諸要素は、サーバ上で実行することができる。本発 明のユーザは、一般的な任意のウェブ・ブラウザから、管理中の諸システムを監 視及び制御する。 マッピング・ブロックは、インターネット上のウェブ・ブラウザに、静的形式 （例えば、ＨＴＭＬ形式）又は動的形式（例えば、Ｊａｖａ形式）のアプレット を供給する。これらの形式又はアプレットは、管理中の諸システムからの監視情 報を供給するか、又はトランスポート層を通してシステム管 理ベースにアクセスすることにより、管理中の諸システムを制御するための入力 手段を提供する。ブラウザへのユーザ入力は、このユーザが監視することを望ん でいる監視対象又はこのユーザが望んでいる制御方法を指示する。かかるユーザ 入力は、前記形式又はアプレットが与える諸命令の制御下で、ブラウザを介して 、マッピング・ブロックに返送される。 マッピング・ブロックとウェブ・ブラウザの間で交換すべきデータは、ＨＴＭ Ｌのような標準言語の形式を有し、ＨＴＴＰプロトコルを使用してインターネッ ト上に伝送される。 マッピング・ブロックは、トランスポート層及びシステム管理ベースを通して 、管理中の諸システムと通信する。実際、マッピング・ブロックは、ＧＵＩベー ス・パラダイムにおけるＧＵＩになる。マッピング・ブロックは、インターネッ トを介して受信したＨＴＭＬを、トランスポート層に与えられるプロトコル独立 の諸コマンドに変換する。 トランスポート層は、これらのコマンドを、NetＢＩＯＳ、ＴＣＰ／ＩＰ、Ｉ ＰＸ又は直列リンクを介して、システム間で伝送する。 システム管理ベースは、トランスポート層からのコマンドを受信する。次に、 システム管理ベースは、ユーザの諸命令を実行するか、又はコンピュータ・シス テム自体からの所望の監視を要求する。 このシステム管理ベース内で利用可能な諸サービスは、ウェブを通して本発明 が制御することができるものである。こ れらのサービスを列挙すると、次の通りである。 （１）システム情報ツール： 当該システムのハードウェア及びソフトウェア構 成について包括的な情報を供給する。 （２）システム監視サービス： 当該システムにおける測定可能な量の監視を可 能にする。これらの量を表示し、収集し、データベースにエクスポートすること ができる。また、警報をトリガするために、これらの量について閾値を設定する ことができる。 （３）システム区画アクセス・サービス： 或るシステムのシステム区画の表示 及び制御を可能にする。 （４）警報管理サービス： 警報ログの表示、警報時に行うべきアクションの設 定、諸警報クラスをカプセル化する諸プロファイルの定義、警報収集手段からの プロファイルによる警報の要求を可能にする。 （５）セキュリティ管理サービス： 或るサービス・レベル上のアクセスを制限 するために、ユーザ及びパスワードを定義することを可能にする。 （６）ＥＣＣメモリ・サービス： ＥＣＣメモリ・エラー及び障害についての監 視及び警報を可能にする。 （７）予知式障害分析サービス： ディスク・エラー及び障害についての監視及 び警報を可能にする。 （８）システム・プロファイル・サービス： 当該システム上の重要な会計及び インベントリ情報の定義及び入力を可能にする。 （９）クリティカル・ファイル・モニタ： 諸ファイル内の変更を検出するため に、これらのファイルの監視及び警報を可能にする。 （１０）NetFinity 直列制御： 内部プロトコルによる通信用の直列回線の定義 及び設定を可能にする。 なお、「NetFinity」は、インターナショナル・ビジネス・コーポレイション の商標である。 （１１）ＲＡＩＤ管理： それぞれのＲＡＩＤ駆動装置を制御し、ＲＡＩＤ駆動 装置のエラー及び障害を監視及び警報することを可能にする。 （１２）遠隔セッション・サービス： それぞれの遠隔システムについて端末シ ェル能力を可能にする。 （１３）ファイル転送サービス： ローカル・システムと遠隔システムの間のフ ァイル又はディレクトリの転送を可能にする。 （１４）画面ビュー・サービス： ローカル又は遠隔システム上の可視画面の捕 捉及び表示を可能にするとともに、システム入力及び出力の実時間的な捕捉を可 能にする。 （１５）遠隔システム管理サービス： 諸システム・グループの定義及び保守に 加えて、諸システムのステータス又は存在についての警報を可能にする。 （１６）サーバ保護サポート・システム： 諸サーバ上のハードウェア・モニタ （電源、温度、等）の状態についての監視及び警報を可能にする。 （１７）イベント・スケジューラ・サービス： スケジュールされたサービス又 はコマンドの定義及び活動化を可能にする。 （１８）電源オン・エラー検出： 電源オンとシステム・ブートの間に生ずるエ ラーの捕捉及び警報を可能にする。 （１９）データベース・サポート： サービス・データをデータベースに対しエ クスポートするための諸パラメータの設定及び調整を可能にする。 （２０）ソフトウェア・インベントリ： 当該システム上に導入されたソフトウ ェアの定義及び監視を可能にする。 （２１）ＤＭＩブラウザ： ＤＭＩイベントの生成及び表示を可能にする。 （２２）報告： 種々の監視サービスから生ぜられる諸報告の定義、生成及び表 示を可能にする。この報告サービスは、種々のサービスによって与えられる実時 間式のデータを補足する処の、履歴データの静的なベースとして機能する。更に 、これらの報告は、システム管理業務について直接の責任を負わない人々によっ て消費されることが多い。この目的にとって、プラットフォーム独立のウェブ・ インタフェースを有することは、極めて有用である。 ＨＴＴＰサーバは、インターネットに接続されたポート上にＨＴＭＬを受理す るような、マッピング・ブロックとして書かれている。このサーバの大部分は、 公知のシステム管理プログラム、例えばＩＢＭ社が提供する「NetFinity」内に 既 に存在する各サービスへのそれぞれのＧＵＩを書き換えたものである。主要な相 違は、ウインドウ・システムと対話する代わりに、このサーバがＨＴＭＬと対話 することにある。 更に、多くの強力なシステム管理能力がウェブ／ブラウザ・パラダイムには自 然であり、専用のＧＵＩにおいては一層困難である。 マッピング・ブロックの内部構造を示す図１５には、マッピング・ブロック内 に見いだされる諸オブジェクトが一層詳細に示されている。図１４の内容からも 明らかなように、マッピング・ブロックは、ウェブ・ブラウザとインターネット を介して制御される観察中のアプリケーションの間に存在する。マッピング・ブ ロックは、２つのオブジェクト、即ちＨＴＴＰオブジェクト及びＨＴＭＬオブジ ェクトから成る。 ＨＴＴＰオブジェクトは、次の事項に責任を有する。 ＊ インターネット通信をオープンし且つこれを維持する； ＊ インターネットを介してＨＴＴＰ要求を受理する； ＊ この要求を形成するＵＲＬ及び他の任意のデータを解析する； ＊ このＵＲＬ、入力データ及びブラウザの識別子をＨＴＭＬオブジェクト に伝送する； ＊ このＨＴＭＬオブジェクトからＨＴＭＬソースを受理し、これを要求元 のブラウザに戻す。 図１５に示すように、ＨＴＴＰオブジェクトは、ブラウザ の型によって更にサブクラス化することができる。このようにすると、ＨＴＴＰ オブジェクトは、ＨＴＭＬフィルタとして振る舞って、ＨＴＭＬオブジェクトが 戻すＨＴＭＬソースを、特定のブラウザが一層良好に使用することができるよう なソースにメッセージ交換することになろう。図１５には、３つのブラウザが例 示されている。市販の製品である「NetScape」のような十分に機能的なブラウザ にサービスする場合、ＨＴＴＰオブジェクトは、このブラウザに転送するＨＴＭ Ｌに対し、如何なる変更も加えないことがある。しかしながら、比較的に能力の 低いブラウザ（例えば、ＨＴＭＬ１．０だけを適正に処理することができるもの ）にサービスする場合には、それよりも拡張されたサービスを必要とするＨＴＭ Ｌソース部分のフィルタ処理を行って、かかる環境で有意に表示可能なソースに 変換することになろう。更に、ＨＴＴＰオブジェクトは、或るコマンド行「ブラ ウザ」を処理するように、サブクラス化することができる。この場合、ＨＴＭＬ を端末画面上に有意に表示するためには、このＨＴＭＬを根本的に変更して、全 てのマークアップを除去するとともに、適当なスペースを挿入しなければならな い。 ＨＴＭＬオブジェクトは、次の事項に責任を有する。 ＊ ＵＲＬ及び他の要求データを受理する； ＊ これらの要求を理解し且つこれらの要求をアプリケーションのインタフ ェース表示内に形成する； ＊ アプリケーションからの応答を受理する； ＊ これらの応答をＨＴＭＬに変換し、このＨＴＭＬをＨＴＴＰオブジェク トに送信する。 図１５に示されているように、ＨＴＭＬオブジェクトは、ブラウザの型によっ て更にサブクラス化することができる。ＨＴＴＰオブジェクトの場合と同様に、 このサブクラス化の目的は、特定のブラウザによって最も良く理解されるような ＨＴＭＬを生成することにある。しかしながら、ＨＴＴＰオブジェクトは、単に ＨＴＭＬを入力として受け取り、ＨＴＭＬ／ＨＴＭＬ又はＨＴＭＬ／ＡＳＣＩＩ フィルタとして機能するに過ぎないから、入力のＨＴＭＬが表す実際のデータに 対し何の意味も与えない。これとは対照的に、ＨＴＭＬオブジェクトのステージ では、アプリケーションとのインタフェースの設計者は、このデータが真に何を 表してるかを依然として知っている。従って、この設計者は、このステージにお けるブラウザの選択に反応し、このブラウザの識別に応じて、このデータをＨＴ ＭＬ又はＡＳＣＩＩにフォーマット化することができる。簡単な１つの例は、グ ラフのブラウザによって要求することである。このブラウザが「NetScape」ブラ ウザであれば、ＨＴＭＬオブジェクトは、ＧＩＦとして送信されるようなグラフ を生成することができよう。他方、このブラウザが或るコマンド行であれば、こ のブラウザは、このグラフのＡＳＣＩＩ近似を生成することになろう。 本発明の実施例では、２つのオブジェクトが関与する。 第１のオブジェクトは、ＨＴＴＰオブジェクトである。こ のオブジェクトは、ＨＴＴＰ接続をカプセル化する。 そのメンバは、次の通りである。 ＴＣＰ／ＩＰソケット； 要求されたＵＲＬ。 そのメソッドは、次の通りである。 get the path; get the service; get the user; get the password; get the capability; get the particular arguments。 第２のオブジェクトは、ＨＴＭＬオブジェクトである。このオブジェクトは、 ＨＴＭＬ／アプリケーション・インタフェースをカプセル化する。 そのメンバは、次の通りである。 ＨＴＭＬデータ。 そのメソッドは、次の通りである。 adding text; adding of markup; adding of browser-sepcific markup。 本発明のこの実施例は、ＨＴＴＰオブジェクト及びＨＴＭＬオブジェクト用の １組のクラス・ライブラリとして実現される。このＨＴＭＬオブジェクトは、特 定のブラウザに固有のマークアップ機能を提供するように、サブクラス化される ことになろう。本発明は、ウェブ・サーバが生成するＨＴＭＬを、特定のブラウ ザ（例えば、ＭＶＳ又はＶＴ１００ブラウザ）に適合させるために使用される。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｈ０４Ｌ 12/58 (31)優先権主張番号 ０８／５５８，６２８ (32)優先日 1995年11月14日 (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ０８／５５８，６３１ (32)優先日 1995年11月14日 (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＢＲ，ＣＡ，ＣＮ，Ｃ Ｚ，ＨＵ，ＪＰ，ＫＲ，ＰＬ，ＲＵ (72)発明者 リード、ベンジャミン アメリカ合衆国カリフォルニア州サンタ・ クルーズ、コシュランド・ウエイ 507 (72)発明者 ウエルッチ、ステイーブン アメリカ合衆国カリフォルニア州ギルロ イ、カナダ・ロード 3330 (72)発明者 メドフォード、ミッチェル アメリカ合衆国ノースカロライナ州カリ ー、ストラスバーグ・レーン 109 【要約の続き】 置のうち少なくとも１つのコンピュータ装置から前記ネ ットワークを介して送信されるか又は前記ネットワーク を介して前記少なくとも１つのコンピュータ装置によっ て受信されるＨＴＭＬ／ＨＴＴＰ情報を、前記ネットワ ーク伝送プロトコル及び前記ネットワーク・データ・フ ォーマットに変換する。

Claims (1)

1. 【特許請求の範囲】 １．一のクライアント・コンピュータ装置が一のサーバ・コンピュータ装置に置 かれている情報をアクセスすることを可能にするための情報ハンドリング・シス テムであって、 前記クライアント・コンピュータ装置が、ハイパーテキスト転送プロトコル（ ＨＴＴＰ）を使用して前記サーバ・コンピュータ装置と通信するための手段及び 前記サーバ・コンピュータ装置から受信される情報をハイパーテキスト・マーク アップ言語（ＨＴＭＬ）を使用して当該クライアント・コンピュータ装置の一の ユーザに供給するための手段を含み、 更に、前記情報ハンドリング・システムが、 前記クライアント及びサーバ・コンピュータ装置間に設けられた一のネットワ ークを備え、 当該ネットワークが、ＨＴＴＰとは異なる一のネットワーク伝送プロトコルを 使用するとともに、ＨＴＭＬとは異なる一のネットワーク・データ・フォーマッ トを使用するものであり、 更に、前記クライアント及びサーバ・コンピュータ装置から前記ネットワーク を介して送信されるか又は前記ネットワークを介して前記クライアント及びサー バ・コンピュータ装置によって受信されるＨＴＭＬ／ＨＴＴＰ情報を、前記ネッ トワーク伝送プロトコル及び前記ネットワーク・データ・フォーマットに変換す るための伝送プロトコル変換手段を備え ることを特徴とする、前記情報ハンドリング・システム。 ２．前記伝送プロトコル変換手段が、オブジェクト指向のコンピュータ・ソフト ウェアを実行することを特徴とする、請求の範囲第１項記載のシステム。 ３．前記クライアント・コンピュータ装置が、インターネットに接続され、前記 ネットワークが、前記インターネットと前記サーバ・コンピュータ装置の間に設 けられていることを特徴とする、請求の範囲第１項記載のシステム。 ４．前記クライアント・コンピュータ装置の前記情報を供給するための手段が、 特定の型のグラフィカル・ユーザ・インタフェースを使用し、 前記クライアント・コンピュータ装置が、インターネットに接続され、前記ネ ットワークが、前記インターネットと前記サーバ・コンピュータ装置の間に設け られ、 前記伝送プロトコル変換手段が、オブジェクト指向のコンピュータ・ソフトウ ェアを実行し、 前記コンピュータ・ソフトウェアが、 前記クライアント・コンピュータ装置からＨＴＭＬ要求データを受理し且つ当 該受理されたＨＴＭＬ要求データを前記ネットワーク・データ・フォーマットに 変換するための一のＨＴＭＬオブジェクトと、 前記クライアント及びサーバ・コンピュータ装置間でインターネット接続をオ ープン及び維持し、前記クライアント・コンピュータ装置から受信される前記Ｈ ＴＭＬ要求データを 解析し、前記クライアント・コンピュータによって使用される前記特定の型のグ ラフィカル・ユーザ・インタフェースの識別子を検出し、前記要求データ及び検 出済みのグラフィカル・ユーザ・インタフェースの識別子を前記ＨＴＭＬオブジ ェクトに伝送するとともに、ＨＴＭＬデータを前記ネットワーク及び前記インタ ーネットを介して前記ＨＴＭＬオブジェクトと前記クライアント・コンピュータ 装置の間で転送するための一のＨＴＴＰオブジェクトを含んでいることを特徴と する、請求の範囲第１項記載のシステム。 ５．前記サーバ・コンピュータ装置が、一のシステム管理ソフトウェア・プログ ラムを実行するためのシステム管理手段を含み、前記ネットワーク伝送プロトコ ルが、一のシステム管理プロトコルであり、前記クライアント・コンピュータ装 置からのＨＴＭＬ／ＨＴＴＰデータが、前記システム管理ソフトウェア・プログ ラムを制御するための少なくとも１つのコマンドを含んでいることを特徴とする 、請求の範囲第３項記載のシステム。 ６．前記システム管理ソフトウェア・プログラムが、前記クライアント及びサー バ・コンピュータ装置のハードウェア及びソフトウェア構成に係るデータを処理 することを特徴とする、請求の範囲第５項記載のシステム。 ７．情報ハンドリング・システム用の一のプログラム要素であって、 前記情報ハンドリング・システム上で実行される際に、デ ータと（ａ）ＨＴＭＬ及びＨＴＴＰ、並びに（ｂ）少なくとも１つのコマンド及 びＨＴＭＬ又はＨＴＴＰの何れとも異なるプロトコルの間のマッピングを行うた めの一のマッピング・ブロックを備え、 前記マッピング・ブロックが、一のＨＴＭＬオブジェクト及び一のＨＴＴＰオ ブジェクトを有し、 前記ＨＴＭＬオブジェクトが、ＵＲＬ（未入手資源ロケータ）及び他の要求デ ータを受理し、受理済みの要求を内部コマンド及びＨＴＭＬ又はＨＴＴＰの何れ とも異なるプロトコルに形成し、内部コマンド及びＨＴＭＬ又はＨＴＴＰの何れ とも異なるプロトコルの形式を有する応答を受理し、受理済みの応答をＨＴＭＬ に変換するとともに、当該ＨＴＭＬを前記ＨＴＴＰオブジェクトに送信するよう に機能し、 前記ＨＴＴＰオブジェクトが、インターネット通信をオープン及び維持し、前 記インターネットを介してＨＴＴＰ要求を受理し、受理済みの要求を形成するＵ ＲＬ及び関連するデータを解析し、当該ＵＲＬ、関連するデータ及びブラウザ・ プログラムの識別子を前記ＨＴＭＬオブジェクトに伝送し、前記ＨＴＭＬオブジ ェクトからＨＴＭＬソースを受理するとともに、ＨＴＭＬソースをＨＴＴＰ応答 として前記インターネットに戻すように機能することを特徴とする、前記プログ ラム要素。 ８．前記ＨＴＭＬオブジェクトが、そのメンバとして、 ＴＣＰ／ＩＰソケット； 要求済みのＵＲＬ を有し、そのメソッドとして、 get the path; get the service; get the user; get the password; get the capability; get the particular arguments を有することを特徴とする、請求の範囲第７項記載のプログラム要素。 ９．前記ＨＴＴＰオブジェクトが、そのメンバとして、 ＨＴＭＬデータ。 を有し、そのメソッドとして、 adding text; adding of markup; adding of browser-sepcific markup を有することを特徴とする、請求の範囲第７項記載のプログラム要素。