JPH11327919A - オブジェクト指向割込みシステム用の方法およびデバイス - Google Patents

Abstract

(57)【要約】 【課題】 オペレーティング・システムを、多くの異な
る種類のＣＰＵとともに使用することを可能とする割込
みシステムを提供する。 【解決手段】 割込み源ツリー内のそれぞれのエントリ
が、デバイス名前空間内の対応するエントリと相互参照
し、対応する割込み源のための割込みハンドラへの参照
を含む。割込みが発生すると、単一の割込みディスパッ
チャが呼び出され、割込み源ツリーにアクセスし、対応
する割込みハンドラを実行させる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般には、コンピ
ュータ・システムで割込みを発生させるためのデバイス
および方法に関し、詳細には、オブジェクト指向ソフト
ウェアを使用するコンピュータ・システムに実施された
割込みシステムに関する。

【０００２】

【従来の技術】コンピュータ・システムは一般に、メモ
リに記憶された「プログラム」に含まれる一連の特定の
命令を実行することで動作する。しかし、コンピュータ
は、ユーザがキーボードのキーを押す、プリンタが印刷
データをさらに要求する信号を送るなどの「割込み」と
呼ばれるランダムに発生する外部および内部イベントに
も応答しなければならない。コンピュータは通常の処理
を中断し、制御の流れを、記憶されているプログラムか
ら「割込みハンドラ」ルーチンと呼ばれる別のプログラ
ムに一時的に迂回させなければならない。

【０００３】割込み処理は、「手続き型プログラミン
グ」として知られる従来のソフトウェアを動作させるコ
ンピュータ、および、オブジェクト指向プログラミング
手法を使用して開発されたソフトウェアを使用する新し
いシステムのオペレーティング・システム（「ＯＳ」）
ソフトウェアによって実行される。しかし、従来技術の
オブジェクト指向割込み管理システムは、ＯＳの移植性
および性能に影響を及ぼすいくつかの限界を有する。

【０００４】

【発明が解決しようとする課題】すなわち、オペレーテ
ィング・システムを、多くの異なる種類のＣＰＵととも
に使用することを可能とする割込みシステムが提供され
ることが望ましい。さらに、オペレーティング・システ
ムによる割込みの処理がより高速により効率よく実施さ
れるようにすることが望ましい。

【０００５】本発明のデバイスおよび方法は、移植性が
あり高性能な割込み管理システムを提供することによっ
て、現在あるこれらの限界の全てを克服することを課題
とする。

【０００６】

【課題を解決するための手段】本発明の特徴および利点
を以下に説明する。これらには、この説明から明白なも
の、あるいは本発明を実施することによって理解される
ものがある。本発明の目的およびその他の利点は、本明
細書の説明、請求項、および添付図面に具体的に指摘し
た方法、デバイスおよび製品から理解され、達成されよ
う。

【０００７】これらおよびその他の利点を達成するた
め、具体例を挙げ、広く本発明を説明すると以下の通り
である。本発明は、ＣＰＵ、マイクロカーネルを含むメ
モリ、割込みを発生させる割込み源となる複数のデバイ
ス、それぞれが１つの割込み源に関連した複数のドライ
バ、およびシステム・データベースを有するオブジェク
ト指向コンピュータ・システムで割込みを処理する方法
を提供する。この方法は、それぞれのデバイスに対する
デバイス・エントリをデータベース内に作成する段階、
割込み源の１つを表すオブジェクトをそれぞれが含む複
数の割込み源ツリー・エントリを含む割込み源ツリーを
データベース内に作成する段階、および、対応する割込
み源ツリー・エントリの中のそれぞれの割込み源に関連
した割込み管理ソフトウェア・コンポーネントをインス
トールおよび削除するメソッドを含む割込み登録インタ
フェースを実施する段階を含む。この方法はさらに、そ
れぞれのデバイス・エントリを、対応する１つの割込み
源ツリー・エントリと相互参照させる段階、単一の割込
みディスパッチャを実行させ、割込みディスパッチャに
デバイスを識別させることによって、デバイスが発生さ
せた割込みに応答する段階、および割込みディスパッチ
ャによって呼び出された、識別されたデバイスに対応す
るハンドラで割込みを処理する段階を含む。

【０００８】他の態様では、本発明は、ＣＰＵ、割込み
を発生させることができる割込み源を構成する複数のデ
バイス、およびそれぞれが少なくとも１つの割込み源に
関連した複数のドライバを有するオブジェクト指向コン
ピュータ・システムにおける割込みを処理する装置を含
む。この装置は、それぞれが割込み源に関連したドライ
バによって供給される複数の割込み管理ソフトウェア・
コンポーネントと、それぞれのデバイスに対するデバイ
ス・エントリを含むデータベースを有するメモリと、少
なくとも１つの割込み源を表すオブジェクトをそれぞれ
が含み、対応するデバイス・エントリと相互参照し、少
なくとも１つの割込み管理ソフトウェア・コンポーネン
トへの参照をそれぞれが含む複数の割込み源ツリー・エ
ントリを含む割込み源ツリーと、識別されたデバイスに
対応する割込み源ツリー・エントリによって指定された
対応する割込み管理ソフトウェア・コンポーネントを実
行することによって、ＣＰＵによって識別された割込み
に応答する単一の割込みディスパッチャとを含む。

【０００９】

【発明の実施の形態】以上の概要および以下の詳細説明
はともに、例示および説明のためのものであり、請求の
範囲に記載した発明をさらに説明することを目的として
いることを理解されたい。

【００１０】添付図面は、本発明の理解を助けるための
ものである。これらは、本明細書に組み込まれ、その一
部を構成し、本発明の一実施形態を示し、前記説明とと
もに本発明の原理を説明する役割を果たす。

【００１１】本発明は、オブジェクト指向オペレーティ
ング・システム中に含まれる。開示の実施形態は、サン
・マイクロシステムズ社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔ
ｅｍｓ，Ｉｎｃ．）が提供するＪａｖａプログラミング
環境中で実施される。しかし本発明がこれに限定される
わけではなく、当業者なら分かるように、本発明を、そ
の他のコンピュータ・システムに組み込むこともでき
る。Ｓｕｎ、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｓｕ
ｎのロゴ、Ｊａｖａ、およびＪａｖａをベースにした商
標は、米国およびその他の国のサン・マイクロシステム
ズ社の商標または登録商標である。

【００１２】次に、図面に示した本発明に基づく実施態
様について詳細に説明する。添付図面および以下の説明
では可能なかぎり、同一または同様の要素には同じ参照
番号を使用する。

【００１３】図１に本発明の使用に適したコンピュータ
・システム１０を示す。コンピュータ・システム１０
は、例えばＳｕｎ ＳＰＡＲＣ、Ｍｏｔｏｒｏｌａ Ｐ
ｏｗｅｒ ＰＣ、またはＩｎｔｅｌ Ｐｅｎｔｉｍプロ
セッサとすることができる中央処理デバイス（ＣＰＵ）
１２を含む。コンピュータ・システム１０は、広範な演
算デバイスを代表する。例えばシステム１０を、家庭お
よび事務所で広く使われている標準的なパーソナル・コ
ンピュータとしてもよい。代わりに、システム１０が、
高品位テレビジョンまたは多機能セルラ電話の受信に使
用するセットトップ・ボックスのようなはるかに専門化
された「スマート」システムを含んでもよい。

【００１４】ＣＰＵ１２はメモリ１４に接続される。メ
モリ１４は、ランダム・アクセス・メモリ（ＲＡＭ）、
リード・オンリー・メモリ（ＲＯＭ）などのさまざまな
種類のメモリを含むことができる。ＣＰＵ１２はさらに
拡張バス１６に接続される。拡張バス１６を例えばＰＣ
Ｉバスとすることができる。バス１６には、さまざまな
種類の入出力デバイス１９、２０および２２が接続され
る。入力デバイス１８を例えば、システム１０を電話線
またはローカル・エリア・ネットワークに接続するモデ
ムまたはネットワーク・インターフェース・カードとす
ることができる。入力デバイス２０を例えばキーボー
ド、出力デバイス２２を例えばプリンタとすることがで
きる。任意選択で、Ｉ／Ｏバス２６によって接続された
ハードディスク・ドライブなどの大容量記憶デバイス２
４をシステム１０に含めることができる。Ｉ／Ｏバス２
６を例えばＳＣＳＩバスとすることができる。システム
１０はさらに、ＣＰＵ１２の制御下にあって、メモリ１
４とＰＣＩバス１６の間の直接データ転送を可能とする
ダイレクト・メモリ・アクセス（ＤＭＡ）コントローラ
２３を含む。

【００１５】次に、図１のメモリ１４に記憶されたソフ
トウェアを示す図２を参照する。図２は、論理的な一連
の層に配置されたソフトウェアを示す。上位層３０は、
「プラットフォーム・インデペンデント」である。「プ
ラットフォーム」という用語は、一般に、ＣＰＵ、物理
メモリ、ならびに永続的に取り付けられたデバイスおよ
びバスを指す。したがって、プラットフォーム・インデ
ペンデント層３２に含まれるソフトウェアは、変更なし
に、既存の、または将来に開発される任意のＣＰＵに基
づいた任意のプラットフォームとともに使用することが
できるような方法で書かれている。第２の層３４は、プ
ラットフォーム・デペンデントである。したがって層３
４のソフトウェアは、コンピュータ・システム１０の特
定のプラットフォームに対してカスタマイズされていな
ければならない。

【００１６】プラットフォーム・インデペンデント層３
２は、ユーザに対して、デスクトップ・パブリッシン
グ、通話管理、データベース管理などの特定の動作を実
行するアプリケーション・プログラム層３６を含む。ア
プリケーション層３６は、「Ｊａｖａ仮想マシン」（Ｊ
ＶＭ）として知られるコンポーネントを含む実行時シス
テム３８とインタフェースする。ＪＶＭは、アプリケー
ション・プログラムによって生成されたマシン・インデ
ペンデントなバイトコードの形態の命令を受け取り、そ
れらを解釈するソフトウェア・コンポーネントである。
ＪＶＭは、特定のプラットフォームとインタフェースし
て、所望の機能を実行する。開示の実施形態は、Ｊａｖ
ａ仮想マシンを使用するが、当業者に周知のその他の種
類の仮想マシンを使用することもできる。ＪＶＭの動作
は、当業者にはよく知られており、例えば、Ｔｉｍ Ｒ
ｉｔｃｈｅｙ著、Ｎｅｗ Ｒｉｄｅｒｓ Ｐｕｂｌｉｓ
ｈｉｎｇ社（米インディアナ州インディアナポリス）刊
の書籍「Ｊａｖａ！」、Ｌｉｎｄｈａｍ、Ｙｅｌｌｉｎ
共著、Ａｄｄｉｓｏｎ−Ｗｅｌｌｅｓｌｅｙ社刊「Ｔｈ
ｅ Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｓｐ
ｅｃｉｆｉｃａｔｉｏｎ」（１９７７）などで論じられ
ている。

【００１７】実行時層３８はさらに、バス１６、２６お
よびデバイス１８、２０、２２（図１）などのデバイス
の動作をサポートするデバイス・インタフェース部分４
２を含む。具体的にはデバイス・インタフェース４２
は、デバイスマネージャ４６および各種マネージャ４８
を含む。デバイス・インタフェース４２はさらに、それ
ぞれのデバイス１８、２０および２２用に書かれたオブ
ジェクト指向プログラムであるデバイス・ドライバ５０
を含む。デバイス・ドライバ５０は、プラットフォーム
・インデペンデント層３２に含まれており、そのため、
書かれた後は、既存の、または将来に開発される任意の
プラットフォームのデバイス１８、２０および２２をサ
ポートするのに使用することができることに留意された
い。同様に、デバイス・インタフェース４２は、図１の
ＰＣＩバス１６およびＳＣＳＩバス２６などのバス用に
書かれたオブジェクト指向プログラムであるプラットフ
ォーム・インデペンデントなバス・マネージャ５１を含
む。デバイス・インタフェース４２はメモリ・クラス５
２を含む。

【００１８】デバイス・インタフェース４２はさらに、
コンピュータ・システムの動作をサポートするシステム
・ローダ５４およびシステム・データベースを含む。シ
ステム・データベース５６は、クライアント・ソフトウ
ェアが、コンピュータ・システム１０の構成情報を記憶
したり、検索したりすることを可能とする。具体的に
は、システム・データベース５６は、存在するデバイス
の構成情報、インストールされているシステム・ソフト
ウェア・サービスについての情報、選択されているユー
ザおよびグループ属性についての情報、および必要なア
プリケーション特定情報を含む。記載の実施形態では、
このシステム・データベースを、Ｊａｖａシステム・デ
ータベース（ＪＳＤ）と呼ぶ。ＪＳＤの追加の詳細は、
付属書Ａに記載されている。

【００１９】実行時システム３８は、入出力、ネットワ
ーク操作、グラフィックス、印刷、マルチメディアなど
の操作をサポートする追加機能５８を含む。

【００２０】プラットフォーム・デペンデント層３４
は、プラットフォーム・インタフェース６０、ＯＳネイ
ティブ層６１、マイクロカーネル６２、およびブート・
インタフェース６４を含む。プラットフォーム・インタ
フェース６０は、仮想マシン４０から受け取ったシステ
ム機能呼出しをサポートする仮想マシン・システム機能
ライブラリ・ハンドラ６６を含む。これを、Ｊａｖａプ
ログラム言語で書くことができる。プラットフォーム・
インタフェース６０はさらに、やはりＪａｖａプログラ
ミング言語で書かれ、コンピュータ・システム１０およ
びバス・マネージャ４４の割込み動作をサポートする割
込みクラス６８を含む。プラットフォーム・インタフェ
ース６０は最後に、ともにＪａｖａプログラミング言語
で書かれたダイレクト・メモリ・アクセス（ＤＭＡ）ク
ラス７０およびメモリ・クラス７２を含む。

【００２１】マイクロカーネル６２は、ＣＰＵ１２特定
の言語（「ネイティブ」言語）で書かれ、資源割付け、
割込みプロセス、セキュリティなどのＣＰＵ１２の基本
的な低水準ハードウェア機能をサポートするソフトウェ
ア・コンポーネントから成る。具体的には、マイクロカ
ーネル６２は、スレッド管理、例外、タイミング、物理
メモリ管理、ハードウェア割込み処理、プラットフォー
ム制御、プロセス管理、ライブラリ管理、Ｉ／Ｏサポー
ト、およびモニタ機能を含む複数のカーネル機能７４を
含む。これらの機能を、サン・マイクロシステムズ社か
ら市販されているＣｈｏｒｕｓマイクロカーネルによっ
て実行してもよい。マイクロカーネル６２はさらに、デ
バッグ機能７６、割込みネイティブ・メソッド７８、Ｄ
ＭＡネイティブ・メソッド８０、およびメモリ・ネイテ
ィブ・メソッド８２を含む。

【００２２】プラットフォーム・デペンデント層３４の
最後のコンポーネントは、ブート・インタフェース６４
である。ブート・インタフェース６４は、コンピュータ
・システム１０に最初に電源が投入されたときに、メモ
リ１４（図１）にソフトウェアをロードし、これを初期
化する。ブート・インタフェース６４は、例えばフロッ
ピー・ディスクや大容量記憶２４（図１）に記憶された
ソフトウェア、または入力デバイス１８を介してネット
ワークから受け取ったソフトウェアをロードすることが
できる。

【００２３】次に、割込み処理のためのメソッドの概要
を説明する。コンピュータ・システム１０用のソフトウ
ェアをロードすると、ブート・インタフェース６４およ
びバス・マネージャ４４がシステム・データベースを構
成する。システム・データベースは、デバイス名前空間
および割込み名前空間を含む。デバイス名前空間は、ブ
ート・インタフェース６４およびバス・マネージャ４４
によって作成され、コンピュータ・システム１０のＣＰ
Ｕ、それぞれのバス、およびそれぞれのデバイスに対す
るエントリをオブジェクトの形態で含む。割込み名前空
間は、プラットフォーム・マネージャ・ソフトウェア・
コンポーネント４５によって作成され、それぞれの割込
み源、すなわち、割込みを発生させることができるそれ
ぞれのデバイスまたはバスに対するエントリをオブジェ
クトの形態で含む。

【００２４】割込み名前空間のオブジェクトは、割込み
源ツリーの形態に編成される。それぞれのオブジェクト
が割込み源エントリ（ＩＳＥ）である。デバイス名前空
間のそれぞれのエントリは、ＩＳＥ、すなわち割込み名
前空間のエントリと相互参照する。

【００２５】それぞれのＩＳＥは、１つまたは複数の割
込み処理コード・コンポーネントへの参照を含む。これ
らのコンポーネントには、デバイス・ドライバによって
供給される割込みハンドラ、割込みイネーブラ、割込み
ディスエーブラ、および割込みアクノレッジャ（ａｃｋ
ｎｏｗｌｅｄｇｅｒ）などがある。

【００２６】割込みが発生すると、マイクロカーネル
が、割込みを発生させたデバイスを識別する割込みベク
トルを生成し、割込みディスパッチャを実行させ、割込
みディスパッチャに割込みベクトルを供給する。割込み
ディスパッチャは、システム・データベースのデバイス
名前空間を参照し、そこで、割込みベクトルによって識
別されたデバイスに対応するエントリを求める。割込み
ディスパッチャは次いで、識別されたデバイスと相互参
照するＩＳＥを求め、そのＩＳＥによって指定された、
識別されたデバイスからの割込みを処理するための割込
みハンドラを求める。割込みディスパッチャは次いで、
求められた割込みハンドラを実行させる。

【００２７】以下に、本発明の一部を構成し、前述のプ
ロセスを実装する割込みクラスおよびインタフェースの
概要を示す。最初の項では、割込み源（すなわちデバイ
ス、バスまたはＣＰＵ）を抽象的に表現し、次いで、ド
ライバに公表する方法を説明する。２番目の項では、割
り込んだデバイスに関連付けることができるコードの種
類、および、割込みを処理し管理するコードを登録する
方法の概要を説明する。３番目の項では、割込みハンド
ラを調整し同期させる方法の概要を説明する。４番目の
項では、割込みに応答して割込みハンドラをディスパッ
チする方法の概要を説明する。

【００２８】割込み源の要約 割込み源オブジェクト 割込みは、デバイスが、デバイス・ドライバなどのソフ
トウェアにアテンションを要求する手段である。デバイ
スは、ＣＰＵの中に埋め込まれたり、ＣＰＵの外部バス
に直接に取り付けられたり、または、ＰＣＩなどのその
他の拡張バスに取り付けられたりしている場合がある。
本発明は、割込み源として割込みを発生させることがで
きる一切のデバイスを表している。

【００２９】割込み源は、その他の割込み源に関係付け
られる。例えば、ＣＰＵのバス上のデバイスは、あるＣ
ＰＵ特定レベルでＣＰＵに割り込む。ＣＰＵの割込みレ
ベルは割込み源、すなわちデバイス自体である。ＰＣＩ
バス上のデバイスが割込みを発生させると、ＣＰＵ自体
が割り込まれるまで、１つまたは複数のバス・ブリッジ
を介して信号が伝搬される。

【００３０】割込みルーティングのトポロジとデバイス
・トポロジは類似しているが、常に同一であるとは限ら
ない。デバイス・トポロジと割込みトポロジとが異なる
可能性があるため、割込み源を表すのに別のオブジェク
ト・クラスが必要となる。

【００３１】本発明は、ＣＰＵ、それぞれのＣＰＵ割込
みレベル、およびレベルを使用したバス−デバイス結合
を表す割込み源オブジェクトを作成する。図３に、ＣＰ
Ｕ、それぞれのＣＰＵレベル（この例では２つ）、バス
割込み源、および２つのデバイス割込み源に対する割込
み源オブジェクトの概念を示す。

【００３２】割込み源オブジェクトの編成 本発明の割込みクラスは、既知の割込み源セットを管理
する。可能なアクティブな割込み源オブジェクト・セッ
トが、ＪＳＤの割込み名前空間中に階層として編成され
る。

【００３３】割込み源ツリー（ＩＳＴ） 割込み名前空間（以後、割込み源ツリー（またはＩＳ
Ｔ）と称する）はＪａｖａシステム・データベース（Ｊ
ＳＤ）の中に予め作成される。割込み源ツリーの中のそ
れぞれのＪＳＤエントリは、割込みを通じてアテンショ
ンを要求することができるデバイスを表す。ＣＰＵ（ツ
リー・ルート）から、ＣＰＵレベルおよびバス（親エン
トリ）、最終的にデバイス（葉エントリ）にいたるＩＳ
Ｔのそれぞれの段は、割込み源の細分性がだんだんと細
かくなっていくことを表す。

【００３４】デバイス・ツリーとは別のツリーを使用し
て割込み源を表すことには利点がある。例えば、割込み
ルーティングが必ずデバイス−バス接続に従うとは限ら
ない。プラットフォームには、割込み情報をルーティン
グし、デコードするのにソフトウェアを必要とするもの
や、精巧なハードウェア補助機構を用いるものがある。

【００３５】デバイス・ドライバおよびバス・マネージ
ャを、割込みデコード論理と割込みディスパッチング論
理のさまざまな組合せを全て処理するように設計するこ
とはほぼ不可能である。ＩＳＴは、移植性のあるデバイ
ス・ドライバ・ソフトウェアおよびバス・マネージャ・
ソフトウェアを、プラットフォームの割込みハードウェ
アから分離し、保護するバッファの働きをする。

【００３６】割込み処理の論理および流れを伝達するの
に、プラットフォームごとに異なる形状のツリーが必要
な場合がある。ＩＳＴを用いることによって、プラット
フォーム設計者は、ドライバが壊れることを心配せずに
最新の最高性能の割り込みコントローラを使用すること
ができる。デバイス・ドライバは、ＣＰＵに関連した割
り込みコントローラ（すなわちＰＩＣ）またはバス・ブ
リッジ・コントローラに決してアクセスしない。

【００３７】図４に、先の例の関係付けた割込み源（図
３参照）がＩＳＴの中でどのように表現されるかを示
す。

【００３８】割込み源エントリ（ＩＳＥ） それぞれの割込み源は、割込み源エントリ（ＩＳＥ）と
呼ばれるＪＳＤエントリを使用して表現される。ＩＳＥ
は、Ｊａｖａとネイティブ・コードの両方から（時には
同時に）アクセスされるＪａｖａオブジェクトである。

【００３９】割込み源エントリは、ＪＳＤのＳｙｓｔｅ
ｍＥｎｔｒｙベース・クラスをサブクラス化する。 import java.system.database. Entry;public Interrup
tSourceEntry extends SystemEntry implements interr
uptRegistration(...)

【００４０】ＩＳＥは、ドライバが供給したコードをイ
ンストールしたり、削除したりするメソッドから成る割
込み登録インタフェースを実装する。

【００４１】バスを表すＩＳＥを作成するときには、関
連する子ＩＳＥ（またはデバイスＩＳＥ）の最大数を指
定しなければならない。子「スロット」を予め作成する
ことには、ハードウェア割込みレベルのＩＳＥにアクセ
スしなければならないネイティブ・コードにとっていく
つかの利点がある。

【００４２】ネイティブ・コードにとっての第１の利点
は、ページ・フォールトを防ぐために、そのオブジェク
トに関連した全てのメモリを簡単にロックダウンするこ
とができることである。ほとんどのマイクロカーネル
は、割込みレベルのページ・フォールトの処理をサポー
トすることができない。

【００４３】第２には、ＳｙｓｔｅｍＥｎｔｒｙのリン
ク・リストによる方法を使用する代わりに、バスＩＳＥ
が、デバイスＩＳＥへの参照を予め作成した配列に記憶
することができることである。ＩＳＥの中の配列を使用
することによって、バス・マネージャは、子デバイスに
番号をつけ、その番号を配列指標として使用することが
できる。これは、ハードウェア割込みレベルではとくに
重要である。ＪＮＩを使用して配列に指標付けすること
は、リンク・リストを実行するよりもはるかに単純であ
る。

【００４４】図５に、バスＩＳＥの子ＩＳＥ配列を示
す。

【００４５】ＩＳＴの構造 ＩＳＴは、ＪａｖａＯＳがプラットフォームを初期化す
るときに動的に構築される。最初に、プラットフォーム
・マネージャが割込み名前空間のルートを作成し、自体
を、この名前空間のマネージャとしてインストールする
（名前空間マネージャに関するＪＳＤ仕様を参照のこ
と）。プラットフォーム・マネージャは次に、単一のル
ートＣＰＵ割込み源エントリ（ＩＳＥ）を作成し、次い
で、（このプラットフォーム上で割込み可能な）それぞ
れのＣＰＵ割込みレベルに対し、子ＩＳＥを作成する。

【００４６】デバイス名前空間と割込み名前空間の調整 デバイスマネージャが、デバイスとドライバ、バスとバ
ス・マネージャをマッチングしていくうちに、ツリーが
生長し、ハンドラがインストールされる。プラットフォ
ーム・マネージャおよび活動化されたそれぞれのバス・
マネージャは、割込み源の子エントリを追加してツリー
を生長させる。それぞれの新しい子ＩＳＥはＪＳＤ属性
を使用して、デバイス名前空間のデバイス・エントリと
相互参照する。図６に、デバイス名前空間と割込み名前
空間がどのように相互参照するかを示す。

【００４７】ＩＳＴトポロジおよび管理 プラットフォーム・マネージャ、それぞれのバス・マネ
ージャ、およびそれぞれのドライバは、ＩＳＥおよびＩ
ＳＴとある方法で対話する。

【００４８】プラットフォーム・マネージャがＣＰＵお
よびＣＰＵレベルを作成する プラットフォーム・マネージャは割込み名前空間を作成
し、次いで、単一のＣＰＵオブジェクトおよび複数のＣ
ＰＵレベル・オブジェクトを作成する。それぞれのＪａ
ｖａＯＳプラットフォームには、それぞれのＣＰＵレベ
ルのための組込みハンドラ（ネイティブおよびＪａｖ
ａ）が付属する。

【００４９】バス・マネージャがＩＳＴを伸縮させる プラットフォームのＣＰＵバス・マネージャ（すなわち
プラットフォーム・マネージャ）を含むバス・マネージ
ャは、ドライバおよびその他のバス・マネージャに代わ
ってＩＳＴを維持する。バス・マネージャの制御下にあ
るそれぞれのデバイスに対して、そのデバイスの割込み
源を表す少なくとも１つのエントリがＩＳＴの中に作成
される。

【００５０】デバイス・ドライバがＩＳＥの中のエント
リを使用する ドライバは、割込み源オブジェクトを構成し、次いで適
当なバス・マネージャに、それをＩＳＴにインストール
するよう要求する。図７に、どのコードがどのＩＳＴレ
ベルを管理するかを示す。

【００５１】割込みコード登録 この第２の項では、割込みを処理および管理するコード
を登録する方法の概要を説明する。

【００５２】割込みコードの種類 ４種類のコード、すなわち割込みハンドラ、割込みイネ
ーブラ、割込みディスエーブラ、および割込みアクノレ
ッジャを、割込み源エントリに登録することができる。

【００５３】割込みハンドラは割込みに応答して実行さ
れる。その役割は、デバイスからのアテンションの要求
を満たすこと、実時間データを安全にすること、およ
び、できるだけ早くオペレーティング・システムに制御
を返すことである。本発明は、後に説明する３種類の割
込みハンドラを提供する。

【００５４】割込みイネーブラはデバイスを、割込みが
可能な状態、すなわちマスクされていない状態に置く。
ＣＰＵ割込みイネーブラは、ＣＰＵ割り込みコントロー
ラを共用する全ての（内部または外部）割込みを可能に
する。ＣＰＵレベル・イネーブラは、ただ１つの割込み
レベルのマスクを外す。バス・イネーブラまたはデバイ
スイネーブラは、そのバスまたはデバイスからの割込み
だけのマスクを外す。

【００５５】割込みディスエーブラは、デバイスを、割
込みが不可能な状態、すなわちマスクされた状態に置
く。

【００５６】割込みアクノレッジャは、ＯＳおよび／ま
たはデバイス・ドライバが割込みを処理した（すなわち
割込みに応答した）ことをハードウェアに伝える。応答
は、ハンドラが実際にディスパッチされる前またはされ
た後に実施される。

【００５７】割込みハンドラ 本発明は、３つの割込み処理レベルを認識する。それぞ
れのレベルは、ハンドラおよびその種類のハンドラに対
する実行コンテクストを定義する。マイクロカーネル
は、これらの３つの割込み処理レベルのうちの２つを監
督する。第３の割込み処理レベル（Ｊａｖａセントリッ
ク（Ｊａｖａ−ｃｅｎｔｒｉｃ）レベル）は、Ｊａｖａ
仮想マシンがＪａｖａスレッドを使用してサポートす
る。

【００５８】割込み処理レベルに関連したそれぞれの種
類のハンドラは、それ自体の特別な割込み実行コンテキ
ストで実行される。１つの割込み源は、割込みの処理に
割り当てられたこれらの種類のハンドラのうち、任意の
数のハンドラを一組のハンドラとして機能させることが
できる。

【００５９】それぞれの割込み処理レベルは、割込み源
エントリを共通のデータ交換点として使用し、状態およ
びデータを他のレベルに伝達することができる。これら
の割込み処理レベルのうちの２つは据置きである。据置
き割込みレベルは、非実時間処理に対して望ましく、ネ
イティブ・コードによってのみ開始される。

【００６０】３種類の割込み処理とは、 ・第１レベル実時間ネイティブ割込み処理 ・第２レベル据置きネイティブ割込み処理 ・第３レベル据置きＪａｖａ割込み処理 である。

【００６１】第１レベル・ハンドラ 第１の種類の割込みハンドラは、ＣＰＵ割込みレベルで
実行されるネイティブ割込みハンドラである。このハン
ドラはネイティブ・コードからなるが、このコードは、
「Ｃ」からコンパイルされたものでも、そうでなくても
よい。アセンブリ言語からなる場合であってもこのハン
ドラは、そのプロセッサに対して定義された「Ｃ」呼出
し規則に従う。

【００６２】第１のレベル・ハンドラに入ったとき、マ
イクロカーネルはすでにプロセッサ・レジスタを保管し
ており、別の割込みスタックに切り換わっている可能性
がある。どのスタックで第１レベル・ハンドラを実行す
るかを選択するのはマイクロカーネルである。

【００６３】多くのマイクロカーネルがこの目的にＣＰ
Ｕあたり１つの割込みスタックを充てる。他のマイクロ
カーネルは、単にカレント・スレッドのスタックでハン
ドラを実行し、このハンドラの処理が完了するとスタッ
クをアンワインドする。

【００６４】この種類のハンドラのコードは、マイクロ
カーネルによって呼び出されたときに実行される。割込
みレベル実行コンテクストは、第１レベル・ハンドラに
以下のサポート・サービスを提供する。第１レベル割込
みハンドラはＪＮＩ（Ｊａｖａネイティブ・インタフェ
ース）を使用して、 ・割込み源オブジェクトからデータを読み取ること、お
よびこれにデータを書き込むこと、 ・ＩＳＴを横断し、その後に、その他の第１レベル割込
みハンドラをディスパッチすること、ならびに ・第２、第３、またはメイン実行レベルで待機中のスレ
ッドが実行されるように、割込み源オブジェクトに信号
を送ること ができる。

【００６５】第１レベル・ハンドラの役割は、容量が限
られているバッファでデバイスからデータを読みとるな
どのデバイスの即時の実時間要求を満たすことである。

【００６６】デバイスの実時間要求を満たした後に、第
１レベル割込みハンドラは、第２または第３レベル・ハ
ンドラをマイクロカーネルによって待ち行列に入れるこ
とができる。第１レベル・ハンドラは、第２および第３
レベルの据置きハンドラに状態および／またはデータ
を、このオブジェクトのデータを取得し、設定するＪＮ
Ｉを使用する割込み源オブジェクトを介して送る選択を
することができる。

【００６７】このハンドラの「Ｃ」関数のプロトタイプ
は、マイクロ秒で表した、ブートから現在までの時間を
含む単一のｌｏｎｇ型パラメータを有する割込み源オブ
ジェクトのネイティブ・メソッド・プロトタイプのそれ
と一致する。このハンドラは、ハンドラが割込みを処理
したかどうかを知らせる整数を返す。ネイティブＣＰＵ
レベル割込みハンドラは以下のように定義される。 typedef long firstLevelHandler(void ^* ise,int64#t
when);

【００６８】複数の第１レベル割込みハンドラを、それ
ぞれ異なるレベルで同時に実行させることができる。こ
のことは、単一ＣＰＵにもＳＭＰシステムにも当てはま
る。ただしＳＭＰシステムでは、マイクロカーネルが、
それぞれの割込みレベルの実行を直列化するので、２つ
のＣＰＵが同じハンドラを同時に実行しようとすること
はない。

【００６９】第１レベル割込みハンドラは、システム内
で最も優先順位が高いコードであり、その他の割込みハ
ンドラおよびスレッドを優先（ｐｒｅｅｍｐｔ）する。
したがって、第１レベル割込みハンドラが費やす時間を
最小限に抑えなければならない。

【００７０】第２レベル・ハンドラ 第２の種類の割込みハンドラは、ネイティブ割込みスレ
ッドのコンテキストで実行される。このハンドラも、
「Ｃ」呼出し規則に従うネイティブ・コードから成り、
単一のパラメータを有するネイティブ・メソッドとして
構築される。

【００７１】第１レベル・ハンドラと同様に、第２レベ
ル・ハンドラは、その裁量に任された限られた数のサポ
ート・サービスを有する。ネイティブ・ハンドラ（第
１、第２レベル）は、ＪＮＩだけを使用してＩＳＥデー
タを取得し、これを設定し、同じＩＳＥに関連したその
他のネイティブ・メソッドを呼び出すことができる。

【００７２】第２レベル割込みハンドラは、２つの状況
下で実行されるよう待ち行列に入れられる。第１レベル
割込みハンドラは、第２レベル・ハンドラを待ち行列に
入れることができる。第１レベル・ハンドラが存在しな
い場合には、マイクロカーネルが割込みに応答して第２
レベル・ハンドラを自動的に待ち行列に入れる。

【００７３】第２レベルネイティブ割込みハンドラは以
下のように定義される。 typedef long secondLevelHandler(void^* ise,int64#t
when);

【００７４】ネイティブ割込みスレッドは、第２レベル
・ハンドラの登録プロセス中にマイクロカーネルによっ
て作成される。ネイティブ・スレッドに割り付けられる
スタックの長さは少なくとも１ページである。

【００７５】第２レベル割込みハンドラは、第１レベル
割込みハンドラの後に実行され、第３レベル・ハンドラ
およびその他のＪａｖａまたはネイティブ・スレッドを
優先することができる。

【００７６】第３レベル・ハンドラ Ｊａｖａ割込みハンドラはＪａｖａスレッドのコンテキ
ストで実行され、したがって、Ｊａｖａ言語、Ｊａｖａ
ＯＳおよびＪＤＫの全てのリソースを使用することがで
きる。

【００７７】Ｊａｖａ割込みハンドラを、予め作成され
たＪａｖａシステム・スレッドを含む任意のＪａｖａス
レッドのコンテクストで実行させることができる。

【００７８】第３レベル割込みハンドラは待ち行列に入
れられ、以下の状況で実行される。第１または第２レベ
ルのハンドラが割込み源に対して存在しない場合、デバ
イスが割込みを発生させると、マイクロカーネルが第３
レベル・ハンドラを待ち行列に入れる。

【００７９】第１または第２レベルのハンドラによって
待ち行列に入れられた場合も、第３レベル割込みハンド
ラは実行される。第３レベル割込みハンドラは、第１お
よび第２レベル割込みハンドラの後に実行され、優先順
位の低いその他のスレッドを優先することができる。Ｊ
ａｖａベースの第３レベル割込みハンドラ・メソッド
は、ＤｅｖｉｃｅＩｎｔｅｒｒｕｐｔＳｏｕｒｃｅクラ
ス内に以下のように定義され、ある有用な作業をするた
めに導出された特定のデバイス・ドライバ・クラスによ
ってオーバライドされる。 public boolean handleThirdLevelInterrupt(long when) return true; ]

【００８０】割込みコード用インタフェース ＪａｖａＯＳによって認識されるためには、ハンドラ、
イネーブラ、ディスエーブラおよびアクノレッジャを割
込み源オブジェクトに登録しなければならない。新しい
エントリがＩＳＴに追加されると、そのＩＳＥはその親
の登録されたコードを継承する。後に、子特定のコード
が登録される。

【００８１】Ｊａｖａインタフェースは、それぞれの種
類の割込み管理コードに対して定義される。

【００８２】 割込みハンドラ・インタフェース public interface DeviceInterruptManager extends InterruptManagement [ public boolean setFirstLevelIntrHandler(int firstLevelIntrHandler); public boolean setSecondLevelIntrHandler(int secondLevelIntrHandler); public boolean handleThirdLevelInterrupt(long when); ........ ] ＤｅｖｉｃｅＩｎｔｅｒｒｕｐｔＳｏｕｒｃｅクラス
は、ＤｅｖｉｃｅＩｎｔｅｒｒｕｐｔＭａｎａｇｅｒイ
ンタフェースを実装する。このインタフェースのｓｅｔ
ＦｉｒｓｔＬｅｖｅｌＩｎｔｒＨａｎｄｌｅｒメソッド
は、第１レベル・ネイティブ割込みハンドラの「Ｃ」ア
ドレスを記憶するための整変数の設定に使用される整数
パラメータをとる。第１レベル・ハンドラを必要とする
ＤｅｖｉｃｅＩｎｔｅｒｒｕｐｔＳｏｕｒｃｅ子クラス
はそのネイティブ・メソッドを呼び出し、第１レベル割
込みハンドラのアドレスを取り出さなければならない。
次にこの子クラスは、ｓｅｔＦｉｒｓｔＬｅｖｅｌＩｎ
ｔｒＨａｎｄｌｅｒメソッドを呼び出し、この値をＩＳ
Ｅに記憶しなければならない。このＩＳＥがＩＳＴに挿
入されると、ＣｐｕＬｅｖｅｌＩｎｔｅｒｒｕｐｔＳｏ
ｕｒｃｅクラスのメソッドは、ＩＳＥに記憶された
「Ｃ」関数ポインタを使用して第１レベル割込みハンド
ラをこのデバイスに呼び出すことができる。

【００８３】第２レベル割込みハンドラは第１レベル割
込みハンドラと同様に処理される。

【００８４】Ｊａｖａベースの第３レベル割込みハンド
ラ、ｈａｎｄｌｅＴｈｉｒｄＬｅｖｅｌＩｎｔｅｒｒｕ
ｐｔは、子クラスにオーバライドされたＤｅｖｉｃｅＩ
ｎｔｅｒｒｕｐｔＳｏｕｒｃｅクラスに、ダミーの実装
を有する。

【００８５】割込み管理インタフェース public interface InterruptEnabler(...) public interface InterruptDisabler(...) public interface InterruptAcknowledger(...)

【００８６】割込みレベル管理 適当な時期に手当てをしないとデバイスがデータを失う
可能性があるときに、第１レベル割込みハンドラが必要
となる。第１レベル割込みハンドラの持続時間はマイク
ロ秒で測定しなければならない。

【００８７】第２レベル割込みハンドラは、マルチメデ
ィア・アプリケーションで必要となるもののような拡張
実時間処理を行うときに有用である。

【００８８】第３レベル割込みハンドラは、マウスおよ
びキーボード・イベント処理などの非実時間処理を行う
ときに有用である。第３レベル割込みハンドラでは、仮
想マシンのガベージ・コレクタと同期をとる必要から、
散発的な待ち時間が生じる可能性がある。これらの待ち
時間がデバイスの管理にとって受け入れがたいものであ
る場合には第２レベル割込みハンドラを使用しなければ
ならない。

【００８９】ドライバの役割は、それぞれの割込み処理
レベルをいつ使用するかを選択することである。本発明
によって、複数の割込み処理レベルを同期させるジョブ
が大幅に単純化される。

【００９０】割込みハンドラの同期 同期の問題は割込み処理に付随する。本発明によって、
ドライバの非割込みレベル・コードを３つの割込み処理
レベルの全てと同期させることができるようになる。最
初に、第２レベル・ハンドラおよび第３レベル・ハンド
ラの同期を検討する。

【００９１】第２および第３レベル・ハンドラを実行す
るそれぞれのスレッドはハンドラを実行する前に、ＩＳ
Ｅに関連したＪａｖａモニタを取得する。このようにド
ライバは、ＩＳＥのモニタを取得することによって、第
２または第３レベル・ハンドラが実行されることを防ぐ
ことができる。割込みハンドラがすでに実行中である場
合、ハンドラがモニタを解放するまで、ドライバはブロ
ックする。モニタが解放されている場合、ドライバはモ
ニタを取得し、ドライバがモニタを解放するまでハンド
ラによる次のモニタ取得の試みをブロックする。

【００９２】スレッド・コンテキスト（すなわち第１レ
ベル・ハンドラ）内で実行されないコードを同期させる
ためには、ドライバが、割込み源自体を許可および禁止
する必要がある。それぞれの割込み源オブジェクトは、
この目的の割込み許可および割込み禁止メソッドを含む
インタフェースを実装する。

【００９３】図８に、割込み処理におけるＪａｖａモニ
タの使用を示す。

【００９４】据置き割込みハンドラ待ち行列 第１レベルおよび第２レベルのネイティブ割込みハンド
ラは、割込み単位で、より高位の割込みレベルに作業を
据え置く選択をすることができる。ドライバが作業を据
え置くための単純な機構が必要である。

【００９５】低位の割込みレベルから高位の割込みレベ
ルに作業を据え置くためには、割込みハンドラが、現在
の割込み源オブジェクトをただ単に書き留める。割込み
源オブジェクトを知らせることによって、仮想マシン
が、割込みを待つスレッドをウェークアップさせる。

【００９６】例えば第３レベル割込みハンドラを、予め
作成したＪａｖａシステム・スレッドのコンテキスト、
または、他のスレッドのコンテキストで実行することが
できる。待機スレッドは、以下のようなループを維持す
る。 public void run[ while(true) [ try[ long when = waitForNextInterrupt(); handleThirdLevelInterrupt(when); ] catch(Throwable e)[ ] ]

【００９７】図９に、据置き割込み処理の概念を示す。

【００９８】割込みディスパッチング この項では、３レベルのハンドラを使用した割込み処理
を説明する。

【００９９】割込みハンドラをディスパッチするにはＩ
ＳＴにアクセスする必要がある。プラットフォームの初
期化中、ＪａｖａＯＳのＣｐｕＬｅｖｅｌＩｎｔｅｒｒ
ｕｐｔＳｏｕｒｃｅクラスのネイティブ・メソッドがＩ
ＳＴにアクセス可能となる。

【０１００】この割込みクラスのネイティブ部分は、ツ
リーのそれぞれのエントリ（Ｊａｖａオブジェクト）
が、その寿命の間、Ｊａｖａヒープにロックダウンされ
ることを保証する。ＣＰＵを表すＩＳＥへのポインタ
が、静的変数に記憶され、保管されて、割込みを処理す
るために呼び出されたネイティブ割込みディスパッチャ
によってアクセスされる。

【０１０１】割込みディスパッチャ ＪａｖａＯＳ割込みディスパッチャは、第１および第２
レベル割込みハンドラを実行するネイティブ・コードの
コンポーネントである。割込みディスパッチャは、マイ
クロカーネルの上に階層化され、自体を、マイクロカー
ネルがエクスポートする全ての割込みベクトルのハンド
ラとして実際に登録する。図１０に、マイクロカーネル
の上に階層化された割込みディスパッチャを示す。

【０１０２】マイクロカーネルはＩＳＴの知識を持たな
い。割込みディスパッチャは、全ての割込みの唯一のハ
ンドラを有し、マイクロカーネルに自体を提示する。こ
の設計は、基礎をなすマイクロカーネルに、ＣＰＵベク
トル割込みハンドラをインストールおよび削除する単純
なインタフェース以外、ほとんど何も要求しない。

【０１０３】以下の「Ｃ」インタフェースが割込みディ
スパッチャをサポートする。 void(*native#handler)(int level) ; void set#native#intr#handler(int level,native#hand
ler func) ;

【０１０４】「ｌｅｖｅｌ」パラメータはＣＰＵレベル
（またはベクトル）を指定する。「ｆｕｎｃ」パラメー
タは、ネイティブ割込みハンドラを指定する。ヌル・ハ
ンドラを渡すとハンドラは削除される。マイクロカーネ
ルは、現在の割込みレベルを唯一のパラメータとしてネ
イティブ・ハンドラに渡す。

【０１０５】バスおよびデバイス割込み処理 それぞれのバスおよびデバイスは関連割込みハンドラを
有する。バス割込みハンドラは、割込みディスパッチャ
が使用するハンドラ呼出し論理を実際に増大させる特殊
なデコード機能を実行する。

【０１０６】バス・ハンドラの役割は、どのデバイス割
込みハンドラを次に呼び出すべきかを決定することであ
る。デバイス割込みハンドラは、バス割込みハンドラが
ＪＮＩを使用して呼び出す。階層化されたバスの場合に
は、複数のバス割込みハンドラを呼び出して割込みをデ
コードすることができる。最後に、デバイスの割込みを
実際に処理するデバイス・ハンドラが呼び出される。

【０１０７】バスおよびデバイス割込みハンドラは、プ
ラットフォームの要件および性能の考慮事項に応じ、割
込み処理の全てのレベルに存在することができる。ただ
しプロセスは常に同じである。バス割込みハンドラが、
特定のバス上の割込み源を求める。デバイス割込みハン
ドラがこの割込みを処理する。それぞれのレベルの唯一
の違いは実行コンテキストの違いであり、すなわち、割
込みかスレッドか、ネイティブかＪａｖａかの違いであ
る。

【０１０８】図１１に、バス割込みハンドラおよびデバ
イス割込みハンドラを示す。

【０１０９】図１２に、ＩｎｔｅｒｒｕｐｔＳｏｕｒｃ
ｅクラス階層を示す。

【０１１０】性能向上 本発明は、Ｊａｖａレベル・スレッドが、Ｉｎｔｅｒｒ
ｕｐｔＳｏｕｒｃｅオブジェクトを待つだけで割込みを
直接に処理することを可能にする。このプログラミング
・モデルによって、ハンドラを呼び出すために、特に指
定されたＪａｖａレベル・システム・スレッドに切り換
える必要がなくなる。

【０１１１】例えば、従来技術のネットワーキング・ド
ライバは、ドライバの中の「リーダ」スレッドをウェー
クアップする割込みハンドラをインストールする。本発
明は、「リーダ」スレッドが、特別なシステム割込みス
レッドの実行に依存する代わりに、割込みを直接に待つ
ことを可能にする。図１３に、イーサネット読取り割込
みの性能向上を示す。

【０１１２】以下の項で、本発明のクラスおよびインタ
フェースをより詳細に説明する。

【０１１３】クラスおよびインタフェースの概要 ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ Ｉｎｔｅｒｒｕｐ
ｔＳｏｕｒｃｅＥｎｔｒｙ ｅｘｔｅｎｄｓ Ｅｎｔｒ
ｙ メソッドまたはコンストラクタ 機能 public boolean isEnabled(). この割込み源は割込み可能か？

【０１１４】ｉｎｔｅｒｆａｃｅ Ｉｎｔｅｒｒｕｐｔ
Ｈａｎｄｌｅｒｓ ｅｘｔｅｎｄｓＦｉｒｓｔＬｅｖｅ
ｌＩｎｔｅｒｒｕｐｔＨａｎｄｌｅｒ，ＳｅｃｏｎｄＬ
ｅｖｅｌＩｎｔｅｒｒｕｐｔＨａｎｄｌｅｒ，Ｔｈｉｒ
ｄＬｅｖｅｌＩｎｔｅｒｒｕｐｔＨａｎｄｌｅｒ メソッドまたはコンストラクタ 機能 ハンドラ・インタフェースの収集 Ｃｐｕレベルおよびバス割込み源が 、これらの全てのハンドラのインプリ メンテーションを宣言する。 システムがメソッドの呼出しを試みな い限り、ネイティブ・コードを供給し ないことはｏｋである。これが起きた 場合、ＮａｔｉｖｅＭｅｔｈｏｄＮｏ ｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎが送 出される。 この条件を防ぐために、デフォルトの 第１および第２レベル「ヌル」ハンド ラが供給される。 public boolean insert(Entry child); ＪＳＤの挿入メソッドをオーバライド する。 使用可能なスロットを捜して子の配列 を走査する。スロットが見つからない 場合、挿入は失敗する。 ＪＳＤ内にエントリを置くことをＪＳ Ｄに要求する（ｓｕｐｅｒ．ｉｎｓｅ ｒｔ（ｃｈｉｌｄ）を呼び出す）。こ れに失敗した場合はエラーを返す。 親の子配列に子を挿入する。 その他のネイティブ・メソッドを探索 するために、ＪＮＩ呼出しを含むネイ ティブ側の初期化を実行するためにネ イティブ・メソッドｉｎｉｔＣｈｉｌ ｄ（）を呼出す。 public boolean isEnabled(); この割込み源は割込み可能か？ public boolean isSrcEnabled = false; この割込み源の現在の状態を含むブ ール

【０１１５】ａｂｓｔｒａｃｔ ｃｌａｓｓ Ｉｎｔｅ
ｒｒｕｐｔＳｏｕｒｃｅ ｅｘｔｅｎｄｓ Ｓｙｓｔｅ
ｍＥｎｔｒｙ ｉｍｐｌｅｍｅｎｔｓ Ｉｎｔｅｒｒｕ
ｐｔＳｏｕｒｃｅＥｎｔｒｙ メソッドまたはコンストラクタ 機能 InterruptSource (InterruptSource ＩｎｔｅｒｒｕｐｔＳｏｕｒｃｅを構 parent, String name, int 成する。この割込み源を、ＪＳＤの「 maxChildSources); ｐａｒｅｎｔ」の下に挿入する。 この割込み源が、将来の割込み源の親 となる場合は、子スロットの最大数を 供給する。 コンストラクタが、「ｍａｘＣｈｉｌ ｄＳｏｕｒｃｅｓ」を使用して、Ｉｎ ｔｅｒｒｕｐｔＳｏｕｒｃｅｓの配列 を割り付ける。 この子を、親の子配列に挿入する。子 への配列アクセスは最適化であり、そ のため、ＪＳＤカーソルを使用して、 子割込み源のリストを歩く必要はな い。 プラットフォーム・マネージャが、こ のコンストラクタを使用するＣＰＵお よびＣＰＵレベル割込み源オブジェ クトを作成する。 コンストラクタが最後に実施するのは 、ネイティブ側の初期化を実行するネ イティブｉｎｉｔ（）メソッドの呼出 しである。例えば、割込み源をヒー プに留める。そのため、ネイティブ側 は割込みレベルで安全に動作すること ができる。 InterruptSource (String name, int ＪＳＤまたは親の子配列に挿入を実施 maxChildSources); しないこと以外は、上記と同じ。 バス・マネージャおよびデバイス・ド ライバがこのコンストラクタを使用す ることが予想される。次いでバス・マ ネージャがＪＳＤにエントリを挿入す る。 public void inheritFromParent 親から子に、割込み管理ルーチン（イ (InterruptSource child); ネーブラ、ディスエーブラ、およびア クノレッジャ）をコピーする。バス・ マネージャは、このフィーチャを使用 して、デフォルト管理ルーチンを子お よび孫に伝える（階層化バス・マネー ジャ）。 public boolean insert(Entry child); ＪＳＤの挿入メソッドをオーバライド する。 使用可能なスロットを捜して子の配列 を走査する。スロットが見つからない 場合、挿入は失敗する。 ＪＳＤ内にエントリを置くことをＪＳ Ｄに要求する（ｓｕｐｅｒ．ｉｎｓｅ ｒｔ（ｃｈｉｌｄ）を呼び出す）。こ れに失敗した場合はエラーを返す。 親の子配列に子を挿入する。 その他のネイティブ・メソッドを探索 するため、ＪＮＩ呼出しを含むネイテ ィブ側の初期化を実行するためにネイ ティブ・メソッドＩｎｉｔＣｈｉｌｄ （）を呼出す。 public boolean isEnabled(); この割込み源は割込み可能か？ private boolean isSrcEnabled = この割込み源の現在の状態を含むブ false; ール

【０１１６】ｐｕｂｌｉｃ ｃｌａｓｓ ＣｐｕＩｎｔ
ｅｒｒｕｐｔＳｏｕｒｃｅ ｅｘｔｅｎｄｓ Ｉｎｔｅ
ｒｒｕｐｔＳｏｕｒｃｅ ｉｍｐｌｅｍｅｎｔｓ メソッドまたはコンストラクタ 機能 public CpuInterruptSource(int ＣｐｕＩｎｔｅｒｒｕｐｔＳｏｕｒｃ nLevels); ｅオブジェクトを構成する。その名前 は、デバイス・ツリーでのＣＰＵの名 前と同じである。さらに、デバイス・ ツリーのＣＰＵエントリを指す「デバ イス」と呼ばれるｘ−ｒｅｆ属性を追 加する。ｎＬｅｖｅｌｓが、「ｍａｘ ＣｈｉｌｄＳｏｕｒｃｅｓ」としてＩ ｎｔｅｒｒｕｐｔＳｏｕｒｃｅコンス トラクタに渡される。 public native int このＣＰＵがサポートする割込みレベ getCpuInterruptLevelCount(); ル数の整数カウントを返す。プラット フォーム・マネージャによって呼び出 され、結果はＣｐｕＩｎｔｅｒｒｕｐ ｔＳｏｕｒｃｅコンストラクタに渡さ れる。 private native boolean initCpu(); １回限りのＣＰＵ割込み管理初期化を 実行する（ＣＰＵおよびプラットフォ ーム・デペンデント）。コンストラク タによって呼び出される。 public native boolean ＣＰＵ割込みを可能にする（全レベル enableInterrupt() ） public native boolean ＣＰＵ割込みを禁止する（全レベル） disableInterrupt() public native void ＣＰＵ割込みに応答する。内部または acknowledgeInterrupt() 外部割込みコントローラを使用するこ とができる（プラットフォーム／ＣＰ Ｕ特定）。 何もしなくてもよい。

【０１１７】ＩｎｔｅｒｒｕｐｔＭａｎａｇｅｍｅｎｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＣｐｕＬｅｖｅｌｌｎｔｅ
ｒｒｕｐｔＳｏｕｒｃｅｅｘｔｅｎｄｓ Ｉｎｔｅｒｒ
ｕｐｔＳｏｕｒｃｅ Ｍｅｔｈｏｄ ｏｒ Ｃｏｎｓｔ
ｒｕｃｔｏｒ メソッドまたはコンストラクタ 機能 public CpuLevelInterruptSource このＣＰＵ割込みレベル＃’ｌｅｖｅ (CpuInterruptSource cpu, int level, ｌ’を表すＣｐｕＬｅｖｅｌＩｎｔｅ int maxChildrenSharingLevel); ｒｒｕｐｔＳｏｕｒｃｅオブジェクト を構成する。このエントリの名前が、 ”ｃｐｕ．ｇｅｔＮａｍｅ（）＋Ｌｅ ｖｅｌ”＋ｌｅｖｅｌになる。レベル を整数としてオブジェクトに記憶し、 ネイティブ・コードがアクセスする。 プラットフォームが、この割込みレベ ルを同時に共用することができる子装 置の最大数を与える。 public int getLevel(); この割込み源に関連した割込みレベル を返す。 private native boolean ＣＰＵ割込みレベルの１回限りの初期 initCpuLevel() 化。ＣＰＵおよびプラットフォーム特 定。何もしなくてもよい。コンストラ クタによって呼び出される。 private int levelNumber; コンストラクタからの割込みレベルを 含む。 public static native int プラットフォーム・ネイティブ・メソ maxDevicesForLevel(int level); ッドが、この割込みレベルを同時に共 用することができるデバイスの最大数 を返す。結果は、プラットフォーム・ マネジャによってコンストラクタへの パラメータとして使用される。 public boolean handleThirdLevelInter このレベルの第３レベル割込みハンド rupt(long when); ラ。このレベルでの割込みに応答して 、システム割込みスレッドによって呼 び出される。この第３レベル・ハンド ラは、全ての子の第３レベル・ハンド ラを呼び出す。 public native boolean このレベルの第２レベル割込みハンド handleSecondLevelInterrupt(long ラ。ネイティブ・システム割込みスレ when); ッドによって呼び出される。 public native boolean このレベルの第１レベル割込みハンド handleFirstLevelInterrupt(long ラ。 when); public native boolean enablelnterrup ＣＰＵまたはプラットフォームの割り t(); 込みコントローラのこのレベルのマス クを外すことによってＣＰＵレベル割 込みを可能にする。 public native boolean ＣＰＵまたはプラットフォームの割り disableInterrupt(); 込みコントローラのこのレベルをマス クすることによってＣＰＵレベル割込 みを禁止する。 public native void ＣＰＵレベル割込みに応答する。ＣＰ acknowledgeInterrupt(); Ｕまたは割り込みコントローラ特定の 動作。

【０１１８】ｉｍｐｌｅｍｅｎｔｓ Ｉｎｔｅｒｒｕｐ
ｔＭａｎａｇｅｍｅｎｔ，ＩｎｔｅｒｒｕｐｔＨａｎｄ
ｌｅｒｓｐｕｂｌｉｃ ｃｌａｓｓ ＤｅｖｉｃｅＩｎ
ｔｅｒｒｕｐｔＳｏｕｒｃｅ ｅｘｔｅｎｄｓ Ｉｎｔ
ｅｒｒｕｐｔＳｏｕｒｃｅ Ｍｅｔｈｏｄ ｏｒ Ｃｏ
ｎｓｔｒｕｃｔｏｒ メソッドまたはコンストラクタ 機能 public DeviceInterruptSource (String 命名された指定のデバイスのＤｅｖｉ ｃｅ deviceName); ＩｎｔｅｒｒｕｐｔＳｏｕｒｃｅを構 成する。 名前は、ドライバ起動後にバス・マネ ージャから獲得される。さらに、デバ イスツリーのデバイス・エントリを指 す「デバイス」と呼ばれるｘ−ｒｅｆ 属性を追加する。 public DeviceInterruptSource (String ＢｕｓＩｎｔｅｒｒｕｐｔＳｏｕｒｃ deviceName, int maxChildren); ｅコンストラクタがこのコンストラク タを呼び出す。 public boolean このデバイスの第３レベル割込みハン handleThirdLevelInterrupt(long ドラ。サブクラスが、このダミー・メ when); メソッドをオーバライドする。 protected int firstLevelIntrHandler; これが、ネイティブ第１レベル割込み ハンドラ機能のアドレスに、ｓｅｔＦ ｉｒｓｔＬｅｖｅｌＩｎｔｒＨａｎｄ ｌｅｒメソッドを使用して設定される 。 protected int secondLevelIntrHandler これが、ネイティブ第２レベル割込み ; ハンドラ機能のアドレスに、ｓｅｔＳ ｅｃｏｎｄＬｅｖｅｌＩｎｔｒＨａｎ ｄｌｅｒメソッドを使用して設定され る。

【０１１９】ｉｍｐｌｅｍｅｎｔｓ ＤｅｖｉｃｅＩｎ
ｔｅｒｒｕｐｔＭａｎａｇｅｒ，Ｒｕｎｎａｂｌｅｐｕ
ｂｌｉｃ ａｂｓｔｒａｃｔ ｃｌａｓｓ ＢｕｓＩｎ
ｔｅｒｒｕｐｔＳｏｕｒｃｅ ｅｘｔｅｎｄｓ Ｄｅｖ
ｉｃｅＩｎｔｅｒｒｕｐｔＳｏｕｒｃｅ ｉｍｐｌｅｍ
ｅｎｔｓ ＩｎｔｅｒｒｕｐｔＭａｎａｇｅｍｅｎｔ メソッドまたはコンストラクタ 機能 BusInterruptSource (Entry bus, int 指定されたバスのＢｕｓＩｎｔｅｒｒ maxSources); ｕｐｔＳｏｕｒｃｅを構成する。さら に、デバイス・ツリーのデバイス・エ ントリを指す「デバイス」と呼ばれる ｘ−ｒｅｆ属性を追加する。 整数「ｍａｘＳｏｕｒｃｅｓ」は、こ のバスが処理する子デバイス割込み源 の最大数を定義する。この整数を使用 し、ＩｎｔｅｒｒｕｐｔＳｏｕｒｃｅ ｓの配列を作成する。 public abstract boolean サブクラスに、バス特定割込みイネー enableInterrupt(); ブラ・メソッドを実装させる。 親のイネーブラを継承することができ る。 サブクラスに、バス特定割込みディセ public abstract boolean ーブラ・メソッドを実装させる。 disableInterrupt(); 親のディスエーブラを継承することが できる。 サブクラスに、バス特定割込み応答メ ソッドを実装させる。親のアクノレッ public abstract boolean ジャを継承することができる。 acknowledgeInterrupt();

【０１２０】ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ Ｆｉ
ｒｓｔＬｅｖｅｌＩｎｔｅｒｒｕｐｔＨａｎｄｌｅｒ メソッドまたはコンストラクタ 機能 public boolean ネイティブ第１レベル割込みハンドラ handleFirstLevelInterrupt(long のプロトタイプ。ハンドラには２つの when); パラメータが渡される。第１のパラメ ータは、オブジェクトへの通常のハン ドルである。第２のパラメータは、マ イクロ秒で表したタイムスタンプであ る。

【０１２１】ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ Ｓｅ
ｃｏｎｄＬｅｖｅｌＩｎｔｅｒｒｕｐｔＨａｎｄｌｅｒ メソッドまたはコンストラクタ 機能 public boolean ネイティブ第１レベル割込みハンドラ handleFirstLevelInterrupt(long のプロトタイプ。ハンドラには２つの when); パラメータが渡される。第１のパラメ ータは、オブジェクトへの通常のハン ドルである。第２のパラメータは、マ イクロ秒で表したタイムスタンプであ る。

【０１２２】ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ Ｉｎ
ｔｅｒｒｕｐｔＥｎａｂｌｅｒ メソッドまたはコンストラクタ 機能 public boolean enableInterrupt(); 割込みがすでに許可されていれば真を 返し、そうでなければ偽を返す。この 割込み源からの割込みを許可する。

【０１２３】ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ Ｉｎ
ｔｅｒｒｕｐｔＤｉｓａｂｌｅｒ メソッドまたはコンストラクタ 機能 public boolean disableInterrupt(); 割込みがすでに許可されていれば真を 返し、そうでなければ偽を返す。この 割込み源からの割込みを禁止する。

【０１２４】ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ Ｉｎ
ｔｅｒｒｕｐｔＡｃｋｎｏｗｌｅｄｇｅｒ メソッドまたはコンストラクタ 機能 public void acknowledgeInterrupt(); 割込み処理する前および／または後に 割込み源に応答する。 前か後かの選択は、デバイスおよびハ ードウェア・デペンデントである。

【０１２５】以上に記載したクラスは、フロッピー・デ
ィスク、ＣＤ−ＲＯＭ、光ディスクなどのコンピュータ
可読媒体に記憶される。別法としてこれらは、コンピュ
ータ・システム１０のリード・オンリー・メモリに供給
されるか、またはコンピュータ・データ・キャリア・ウ
ェーブの形態でネットワークを介して供給される。

【０１２６】本発明の範囲または趣旨から逸脱すること
なくさまざまな修正および変更を、開示のプロセスおよ
び製品に実施することができることは、当業者にとって
明白である。本発明のその他の実施形態は、当業者が、
本明細書に開示した本発明の明細および実施を考慮する
ことによって明白となろう。以上の明細および例は単に
例示のためのものであり、本発明の真の範囲および趣旨
は、前記の特許請求の範囲に示されている。

【０１２７】付属書Ａ 第１章 序論 概要 Ｊａｖａシステム・データベース（ＪＳＤ）は次世代の
Ｊａｖａ構成サポートである。ＪＳＤは、オペレーティ
ング・システム・サービス、アプリケーション、Ｊａｖ
ａ ＢｅａｎｓおよびＪａｖａ Ｄｅｖｅｌｏｐｅｒ
Ｋｉｔ（ＪＤＫ）コンポーネントが、全てのＪａｖａプ
ラットフォームに関する複雑な構成情報を記憶したり、
検索したりすることを可能にする。この構成情報には、
存在するデバイス、インストールされるシステム・ソフ
トウェア・サービス、選択されているユーザおよびグル
ープ属性、ならびに必要なアプリケーション特定情報が
記述される（図１４参照）。

【０１２８】構成および通信ハブ クライアント側の構成および通信ハブとして、ＪＳＤ
は、３つの不可欠なサービスをクライアントに提供す
る。すなわちＪＳＤは、構成情報（およびオペレーティ
ング・システム情報）を記憶し、検索し、公表する。検
索されたデータを、要求を出したソースに送る、すなわ
ち公表することができる。ＪＳＤは、ネットワーク・コ
ンピューティングおよびデスクトップ・マネージメント
の信頼できる基礎を提供する。構成情報を定義および維
持するためのレジストリ・サービスとして、ＪＳＤは、
ネットワーク・コンピュータを管理しやすいスマートな
端末に変える。ＪＳＤの重要な特徴には以下のようなも
のがある。 ・クライアント／サーバ・実装（クライアント側でのキ
ャッシングおよびローカル実行） ・リモート管理機能（システム管理が容易） ・単純なユーザ・インタフェース ・トランザクション・ベースのアクセス ・小さなメモリ・フットプリント（２００ｋ未満） ・イベント通知 ・持続性記憶（ＦＣＳに使用可能な標準インタフェー
ス） ・ツリー構造ベースのデータベース・エントリ階層構造
（クライアントでのスマートな記憶および検索） ＪＳＤは、１００％ ｐｕｒｅ Ｊａｖａで書かれてお
り、現在はＪＤＫ １．１をサポートし、将来的には標
準ＡＰＩとしてＪＤＫに移植されると予想される。

【０１２９】ＪＳＤの目的 ジェフ：「日曜の晩に、ＮＣＰマニフェスト（ｍａｎｉ
ｆｅｓｔ）からのいくつかの資料に手を加え、この「目
的」の項を追加しました。目を通して、異議のある部分
または古くなっている部分を書き直すか、削除して頂く
ようお願いします」 ＪＳＤは以下の事項によって、ネットワーク・コンピュ
ータの基準アーキテクチャの主要な要件を満たす。 ・異種のＮＣクライアントとサーバの間の相互運用性を
保証する、ネットワークコンピュータの構成管理の詳細
な定義 ・開発者が、自分のアプリケーションを、ＮＣおよびそ
のデスクトップ環境に登録または統合するための軽量な
インフラストラクチャおよびＡＰＩの定義 ・デスクトップの持続性（ｐｅｒｓｉｓｔｅｎｃｅ）を
通したユーザ・モビリティのサポート ＪＳＤは、クライアント側インタフェースおよびサーバ
側インタフェースを有する。クライアントは、レジスト
リのローカル・コピーを維持する。これによって、シス
テム構成要素またはアプリケーション（デスクトップを
含む）が、データベース・エントリの値を問い合わせた
り、または設定したりすることができる。サーバ側は、
持続性モデルをサポートし、ネットワーク・クライアン
トを管理する。ＪＳＤは、予め定義された名前空間構造
を有し、エントリを作成、変更、削除するためのアクセ
ス・メソッドを含む。レジストリの探索、またはレジス
トリへの問合せを実施することができ、レジストリの変
更をリスナに通知するイベント・モデルが実装される。
セッション管理機能によって状態を保管したり、復元し
たりすることができ、１つのシステムから他のシステム
に移動するユーザのデスクトップ持続性が保証される。

【０１３０】標準システム属性 ＪＳＤは、プラットフォーム、ユーザおよびアプリケー
ション特定情報を単一化されたレジストリとして維持す
る。データベースのそれぞれのエントリは、エントリ
（またはエントリに関連した情報）を記述するのに使用
する属性を有することができる。ただし属性を含まなく
てもよい。標準ＪＤＫ属性にはＪＳＤ以外からもアクセ
ス可能である。ＪＤＫは、単純なシステム属性機構を使
用することによってアプリケーションおよびＪＤＫクラ
スの総称構成サポートを供給する。以下の表に、Ｊａｖ
ａの標準システム属性のいくつかを示す。

【０１３１】 表１−３０ システム属性 属性名 属性値 ｊａｖａ．ｖｅｒｓｉｏｎ バージョン番号（整数） ｊａｖａ．ｖｅｎｄｏｒ ベンダ名（文字列） ｊａｖａ．ｖｅｎｄｏｒ．ｕｒｌ ベンダのホーム・ページのＵＲＬ ｊａｖａ．ｈｏｍｅ Ｊａｖａのインストレーション・ディレク トリ

【０１３２】（名前文字列および値オブジェクトから成
る）これらの属性は、Ｊａｖａプラットフォームの全て
のバージョンに対して定義される。Ｊａｖａプラットフ
ォームの市場がますます多様化するにつれて、追加のプ
ラットフォーム構成サポートが必要と成る可能性もあ
る。

【０１３３】要件および役割 ＪＳＤデータベースは、柔軟なポピュレーション・イン
タフェースを使用してプラットフォームの起動時に動的
にポピュレートされるように設計される。ポピュレーシ
ョン・インタフェースによって、図１５に示すように、
ファイル、ネットワーク、およびホストＯＳからデータ
を得ることができる。データベース情報の持続性は、ロ
ーカルのポピュレーティング・コンポーネントまたはク
ライアント／サーバ・アーキテクチャが取り扱う。例え
ばＷｉｎｄｏｗｓ ＮＴでは、ＮＴレジストリからこの
データベースをポピュレートすること、およびデータベ
ースが、ＮＴの持続性キー・サポートを利用することが
できる。ＪＳＤは、データベースの初期ポピュレーショ
ン後にデータのコヒーレンシ（ｃｏｈｅｒｅｎｃｙ）を
維持するのに使用できるイベント機構をサポートする。

【０１３４】汎用機構 ＪＳＤは汎用インタフェースではあるが、本書では、提
案のネットワーク・コンピュータ基準アーキテクチャに
関係する、名前空間およびエントリ管理の方針について
説明する。コアＪＳＤ自体は、名前空間名、それらのス
キーマ、ポピュレーション方法、および基礎をなす持続
性機構が存在する場合にはこれを指図しない。ＪＳＤを
インスタンス化するとき、開発者は、最初の名前空間名
の文字列を、それぞれの名前空間を管理するクラスとと
もにに与えなければならない。あるＪＳＤクラスを拡張
することによって、代替の持続性機構（ＬＤＡＰ、ＡＣ
ＡＰなど）を実装することができる。Ｊａｖａ Ｓｙｓ
ｔｅｍ Ｄａｔａｂａｓｅは、アプリケーションおよび
（デバイス・ドライバなどの）ＪＤＫシステム・サービ
スに代わって構成情報を記憶、検索するが、その情報を
最初に獲得する、または解釈する方法を指図しない。Ｊ
ＳＤは、単一化された構成リポジトリであり、厳密に言
うと構成マネージャではない。第２章「アーキテクチャ
の概要」では、提案の名前空間およびそれらのスキーマ
の高位の概要を示し、基礎をなすＩＩＯＰベースの通信
機構について触れる。ネットワーク・コンピュータ基準
アーキテクチャを明らかにするこのような定義が必要な
のは、さまざまなクライアント／サーバ・システムの間
の相互運用性を保証するためである。しかしＪＳＤは柔
軟であるので、その他の多くの目的に使用することもで
きる。

【０１３５】第２章 アーキテクチャの概要 Ｊａｖａ Ｓｙｓｔｅｍ Ｄａｔａｂａｓｅは、命名さ
れたデータベース・オブジェクトの集合である。オブジ
ェクトの命名は、名前文字列をデータベース・エントリ
と関連づけるプロセスと定義される。パス名は一般に、
パス名コンポーネント・セパレータ文字によって区切ら
れた名前から成り、データベース中のエントリを一意的
に識別する。エントリは、プラットフォーム、ファイ
ル、アプリケーション、ユーザまたはデバイスなどを表
す働きをすることができる。エントリを挿入することに
よって、その存在が、その他のソフトウェア・コンポー
ネントに向けて公表され、公示される。エントリは、名
前文字列とＪａｖａオブジェクトの値の対である属性を
有することができる。それぞれの属性に対して、ＪＳＤ
は、その値オブジェクトへの参照を維持する。ＪＳＤ自
体が、オブジェクトを記憶するのではない。例えばＤｅ
ｖｉｃｅ属性には、メモリ・バッファ、割込みベクトル
などのデバイスリソースがリストされる。ＪＳＤは、デ
ータベース内のエントリに関連した属性の作成、読取
り、または削除に使用する標準属性インタフェースを提
供する。

【０１３６】名前空間階層 データベースは、エントリの階層として編成される。こ
の階層は、スーパールート・エントリとして知られる単
一エントリをその頂点とする。スーパールートは、Ｊａ
ｖａの起動手順中に作成され、初期化される。その名前
は「／」である。階層内の全てのエントリは、単一エン
トリとしての働き、および子孫エントリのツリーのルー
ト・エントリとしての働きをする。ツリー内のそれぞれ
のエントリは親エントリを１つだけ有し、子エントリは
いくつでも持つことができる。全てのエントリは、それ
らの親エントリおよび子エントリとのリンクを含む。

【０１３７】名前空間 データベース階層はさらに、名前空間に細分される。名
前空間は、ソフトウェア、デバイスなどの同じ種類のオ
ブジェクトを命名する、特に指定されたエントリのツリ
ーである。名前空間は常に、スーパールートから直接に
派生する。プラットフォームの起動手順中にいくつかの
標準名前空間が作成される。

【０１３８】名前空間マネージャ それぞれの名前空間はデフォルトの名前空間マネージャ
によって管理される。名前空間マネージャは、名前空間
の中にエントリを実際に記憶したり、名前空間の中のエ
ントリにアクセスする方法を制御する。名前空間マネー
ジャは、名前空間内のエントリのセキュリティ、記憶、
および所有権属性をエクスポートする標準インタフェー
スを実装する。エントリは、データベースに挿入される
と、その親エントリのマネージャを継承する。全ての名
前空間が、特定の種類の周知のオブジェクトで完全にポ
ピュレートされる必要はない。オブジェクト・ポピュレ
ーションの細分性は名前空間マネージャの制御下にあ
る。

【０１３９】標準データベース名前空間 Ｊａｖａプラットフォームの初期化シーケンスで、その
プラットフォームの全ての実装で使用可能な６つの周知
の名前空間が作成される。初期化完了後に、動的に構成
されたその他の名前空間をデータベースに追加すること
もできる。名前空間マネージャは、それぞれの標準名前
空間に対して提供される。追加の名前空間も名前空間マ
ネージャを必要とし、これらは、名前空間の作成者が提
供しなければならない（標準名前空間の最上位レベルを
表す図１６参照）。

【０１４０】Ｓｏｆｔｗａｒｅ ｓｏｆｔｗａｒｅ名前空間は、デバイス・ドライバ、ア
プリケーション、およびユーザ構成情報などのインスト
ールされた、および／または使用可能なシステム・サー
ビスのリストを含む。この情報は、ブートおよびユーザ
・ログイン中に１つまたは複数のサーバ・マシンからダ
ウンロードされた階層中に示される。クライアントとサ
ーバの対話の詳細については第６章「クライアント／サ
ーバの概要」を参照されたい。ｓｏｆｔｗａｒｅ名前空
間は持続性である。すなわちサーバが、この名前空間内
の全てのエントリに対してバックアップ記憶域を提供す
る。ｓｏｆｔｗａｒｅ名前空間の編成は、パブリックに
アクセス可能なクライアント側ＪＳＤの多くを定義す
る。ｓｏｆｔｗａｒｅ名前空間の最上位レベルを以下に
示す（ｓｏｆｔｗａｒｅ名前空間のサブスキーマを表す
図１７参照）。

【０１４１】それぞれのソフトウェア・カテゴリの下に
は、エントリ名に対するＪａｖａの固有パッケージ命名
方式を使用して配置されたサブエントリがある。すなわ
ち、ｃｏｍ．ｉｂｍ、ｃｏｍ．ｓｕｎ、ｃｏｍ．ｌｏｔ
ｕｓ、ｃｏｍ．ｎｃなどの一意の会社名が、会社特定情
報を区別する。一意の会社エントリの下のエントリ名お
よび編成は会社特定である。それぞれのカテゴリの下に
あるサブエントリ「Ｊａｖａ」は、そのＪＤＫ実装のバ
ージョンに共通のエントリを表す。これらは会社特定で
はない。

【０１４２】Ａｐｐｌｉｃａｔｉｏｎ Ａｐｐｌｉｃａｔｉｏｎサブエントリ階層の例を図１８
に示す。

【０１４３】それぞれのエントリに属性を割り当てて、
特定のアプリケーションに対する構成情報を示すことが
できる。同じアプリケーションの異なるバージョンに対
するプリファレンスを表すためにその他のエントリを作
成することもできる。個々の会社レベルの下の編成は、
ベンダ特定である。

【０１４４】Ｓｙｓｔｅｍ 図１９に例を示したＳｙｓｔｅｍ階層は、仮想マシンお
よびＮＣオペレーティング・システム特定情報を含む実
行時操作に関する情報を含む。デバイス・ドライバなど
のロード可能なコンポーネントの構成情報は、ｓｅｒｖ
ｉｃｅサブエントリの下に維持される。

【０１４５】Ｓｅｒｖｉｃｅ システムによってロードされたサービスの構成情報はこ
の階層内に維持される。サービスは一般に、デバイス・
ドライバ、ネットワーキング・スタック、ファイル・シ
ステムなどのシステム・コンポーネントである。図２０
に可能なｓｅｒｖｉｃｅ階層を示す。

【０１４６】Ｐｕｂｌｉｃ ｐｕｂｌｉｃ階層は、一般にグローバルなデータの値を
定義するそれぞれのサービスまたはアプリケーションを
提供するのではなしに、このような情報の周知のリポジ
トリを提供する。しかし、任意のサービスまたはアプリ
ケーションを選択して、それ自体がｐｕｂｌｉｃ設定を
オーバライドするようにしてもよい。図２１に、プロキ
シおよびメール・サーバ情報などの共通情報を含む階層
を示す。ｓｅｒｖｉｃｅおよびａｐｐｌｉｃａｔｉｏｎ
階層のベンダ特定部分の情報を捜す所与のサービスまた
はアプリケーションを必要とせずに、個々の会社が情報
を、システムの残りの部分に対してパブリックにするこ
とも可能である。

【０１４７】Ｄｅｖｉｃｅ ｄｅｖｉｃｅ名前空間は、ローカル・プラットフォーム
に見られるデバイスセットを含む。ｄｅｖｉｃｅ名前空
間の構造は、プラットフォームに存在するＩ／Ｏバスお
よびデバイス階層の全てまたはいくつかを反映する。言
い換えると、バスおよびデバイスの物理的な接続がエン
トリのツリーとして表される。このとき、バスが親エン
トリとなり、デバイスが葉エントリとなる。

【０１４８】デバイス・エントリ ｄｅｖｉｃｅ名前空間マネージャはｄｅｖｉｃｅ名前空
間の内容を監督する。物理デバイスまたは論理デバイス
が見つかると、ドライバおよびアプリケーションのリソ
ースを表すデバイス名エントリが作成される。ＲＡＭデ
ィスクのような仮想デバイスもデバイス名エントリとし
てこの名前空間の中に表される。ｄｅｖｉｃｅ名前空間
の階層は、表されたデバイスの地理的位置を直接に反映
する。デバイスの地理的位置には、デバイスにアクセス
するのに使用されるバスも含まれる。一般には、デバイ
スが葉エントリ（子エントリを持たないエントリ）で、
バスが親エントリである。バス・エントリは常に、デバ
イス・エントリの親エントリかまたはグランドペアレン
ト・エントリである。バス・エントリを、他のバス・エ
ントリの子エントリにすることもできる。例えば、ＰＣ
Ｉバス・ブリッジを、Ｓバスデバイスを含むＳバスに繋
げてもよい。このシナリオを、バス−デバイス・トポロ
ジを示す図２２の中央のパネルに示した。ＰＣＩバス・
エントリが、Ｓバス・エントリの親エントリに、Ｓバス
・エントリが、Ｓバスデバイス・エントリの親エントリ
担っている。Ｄｅｖｉｃｅ名前空間は、Ｊａｖａの起動
プロセス中に構成される。ｄｅｖｉｃｅ名前空間マネー
ジャ（デバイス・マネージャとも呼ばれる）は、Ｔｒｅ
ｅＰｏｐｕｌａｔｏｒインタフェースのサービスを使用
し、一度に１エントリずつｄｅｖｉｃｅ名前空間を構築
する。ＴｒｅｅＰｏｐｕｌａｔｏｒインタフェースは、
ドライバの探索を手伝うそれぞれのプラットフォーム・
デバイスについての（属性の形態の）情報をデバイス・
マネージャに提供する。

【０１４９】Ｉｎｔｅｒｆａｃｅ ｉｎｔｅｒｆａｃｅ名前空間は、（ｄｅｖｉｃｅ、ｓｏ
ｆｔｗａｒｅなどの）その他の名前空間の中のタイプに
よるオブジェクトのクロス・レフェレンスである。例え
ばデバイス・ドライバは、ｄｅｖｉｃｅ名前空間内のエ
ントリの管理で競合する。あるドライバがそのデバイス
を要求すると、クロス・レフェレンス・インタフェース
・エントリが、ｉｎｔｅｒｆａｃｅ名前空間の中のｄｅ
ｖｉｃｅと呼ばれる周知のエントリの下に挿入される。
例えば、シリアル・デバイス・ドライバが（ｄｅｖｉｃ
ｅ名前空間内の）シリアル・デバイスを要求すると、ク
ロス・レフェレンスＳｅｒｉａｌＤｅｖｉｃｅエントリ
がｉｎｔｅｒｆａｃｅ名前空間に追加される。インタフ
ェース・トポロジを示す図２３に、シリアル・マウスに
ついてこの関係を示す。Ｊａｖａアプリケーション、Ｊ
ａｖａアプレットおよびＪａｖａ Ｂｅａｎｓは、ｉｎ
ｔｅｒｆａｃｅ名前空間の中のインタフェース・タイプ
によってデバイスを探索し、その結果、プラットフォー
ムの物理接続から隔離される。アプリケーションは、よ
り単純化されたａｌｉａｓ名前空間を使用して、上図に
示した／ａｌｉａｓ／ｍｏｕｓｅなどの一般的なデバイ
スの場所を見つけることができる。（デバイス・ドライ
バの詳細については、別に入手可能なＪＤＩ仕様を参照
されたい。）

【０１５０】インタフェース・エントリ ｉｎｔｅｒｆａｃｅ名前空間は、標準Ｊａｖａランゲー
ジ・プログラミング・インタフェースを実装するデバイ
ス・ドライバのセットを含む。ドライバがデバイスに割
り当てられると、デバイス・マネージャは、そのドライ
バによってどのインタフェースが実装されたかを書き留
める。次いでこれらのインタフェースは、ｉｎｔｅｒｆ
ａｃｅ名前空間に自動的に記録される。新しいデバイス
が発見されるかまたは、既存のデバイスが取り除かれる
と、ｉｎｔｅｒｆａｃｅ名前空間の内容が変更される。
しかし、インタフェース・エントリとデバイス・エント
リは１対１には対応しない。これは、１つのデバイス・
ドライバが、２つ以上のプログラミング・インタフェー
スをサポートすることがあるからである（例えばＳｅｒ
ｉａｌＤｅｖｉｃｅ、ＰｏｗｅｒＭａｎａｇｅｍｅｎｔ
など）。ｉｎｔｅｒｆａｃｅ名前空間のトポロジはむし
ろフラットであり、デバイス・ドライバによって実装さ
れたそれぞれの種類のＪａｖａインタフェースに対して
１つの親エントリを含む。それぞれの親エントリは、親
インタフェースを実装するデバイスを表す子エントリを
有することができる。ただしこのような子エントリを持
たなくてもよい。例えばシリアル・ドライバはシリアル
・ポートを管理し、ＳｅｒｉａｌＤｅｖｉｃｅインタフ
ェースを実装する。シリアル・ドライバによってアクテ
ィブに管理されたそれぞれのシリアル・ポートに対し
て、ｉｎｔｅｒｆａｃｅ名前空間内にエントリが作成さ
れる。ＳｅｒｉａｌＤｅｖｉｃｅエントリは、Ｓｅｒｉ
ａｌＤｅｖｉｃｅインタフェース・エントリの子エント
リとして作成される。このクロス・レフェレンス割当て
プロセスを以下のようにまとめることができる。Ｊａｖ
ａ Ｓｅｒｖｉｃｅ Ｌｏａｄｅｒ（ＪＳＬ）が、適当
なデバイスへのドライバ・クロス・レフェレンス・エン
トリでｉｎｔｅｒｆａｃｅ名前空間をポピュレートす
る。このクロス・レフェレンス割当てプロセスを図２４
に示す。同図で、デバイス・ドライバはインタフェース
を実装し （＃１）、デバイス・マネージャは、ｄｅｖ
ｉｃｅ名前空間内のデバイスをこのドライバに割り当て
る（＃２）。

【０１５１】Ｃｏｎｆｉｇ ｃｏｎｆｉｇ名前空間は、クライアント、ユーザ、およ
びアプリケーション構成情報を維持するのに使用され
る。この名前空間は、サーバのＪＳＤ実装でのみ使用さ
れる。クライアントでは、ｓｏｆｔｗａｒｅ名前空間が
持続性であり、ハードウェア・プラットホームおよび現
在ログインしているユーザに特定の情報を含む。サーバ
では、ｃｏｎｇｆｉｇｕｒａｔｉｏｎ名前空間が持続性
である。詳細については第６章「クライアント／サーバ
の要点」を参照のこと。

【０１５２】Ａｌｉａｓ ａｌｉａｓ名前空間のエントリはｉｎｔｅｒｆａｃｅ名
前空間のエントリを参照し、いくつかのシステムデバイ
スの単純な周知の論理的命名方式を提供する。エイリア
スは、システム管理者によって明示的に定義される。こ
の名前空間の一般的なエイリアスの例は、エントリ／ｉ
ｎｔｅｒｆａｃｅ／ｄｅｖｉｃｅ／ｐｒｉｎｔｅｒ／ｈ
ｐＩｎｋｊｅｔ＃１を参照することができる／ａｌｉａ
ｓ／ｓｙｓｔｅｍ／ＤｅｆａｕｌｔＰｒｉｎｔｅｒであ
る。

【０１５３】Ｔｅｍｐ ｔｅｍｐ名前空間は一時記憶として使用可能である。ｔ
ｅｍｐの中のエントリの変更を指示するイベントが生成
されるが、エントリ自体は持続性でない。アプリケーシ
ョンは、ＪＳＤの機能セットおよび、この一時記憶機能
を利用することができる。

【０１５４】要約 名前空間の要点を以下の表に示す。 表１−３１ 名前空間の要点 名前空間 ポピュレーション機構 説明 ｓｏｆｔｗａｒｅ ブートおよびユーザ・ ａｐｐｌｉｃａｔｉｏｎ、ｓｙｓ ログイン中にサーバか ｔｅｍ、ｓｅｒｖｉｃｅ、および らポピュレートされる ｐｕｂｌｉｃサブディビジョン（ ｓｕｂｄｉｖｉｓｉｏｎ）が、持 続性データをクライアント上に保 持する ｄｅｖｉｃｅ ＴｒｅｅＰｏｐｕｌａ サブディビジョンはバス／デバイ ｔｏｒインタフェース ス特定である によってポピュレート される ｉｎｔｅｒｆａｃｅ デバイス・マネージャ ドライバ情報を、ｄｅｖｉｃｅお によってポピュレート よびａｌｉａｓ名前空間へのクロ される ス・レフェレンスとともに保持す る ｃｏｎｆｉｇ 持続性記憶域からサー 持続性情報を記憶するときにのみ バ側ＪＳＤへポピュレ サーバ側で使用される ートされる ａｌｉａｓ システム管理者 ｉｎｔｅｒｆａｃｅ名前空間との クロス・レフェレンス ｔｅｍｐ 任意のサブシステムま 一時記憶 たはアプリケーション

【０１５５】第３章 システム・エントリ ＪＳＤは、それぞれがパス名によって識別される情報の
原子性単位であるエントリの階層から成る。エントリ
は、それに関連した１つまたは複数の属性を有すること
ができる。属性は、エントリをさらに説明するものであ
る。この章では、エントリの構造、エントリの状態、な
らびにエントリに関連した操作およびイベントについて
説明する。 エントリ構造 ＪＳＤのそれぞれのエントリは、エントリ・インタフェ
ースを実装するベース・クラスＳｙｓｔｅｍＥｎｔｒｙ
によって定義される。このインタフェースは、データベ
ースの中のエントリを操作するのに使用される一般的な
メソッドのセットを定義する。それぞれのエントリは、
データベース階層、管理方式およびそれぞれのエントリ
に関連した属性の維持に使用される以下の属性を定義す
る。 ・名前 ・状態 ・親 ・子 ・ロック ・クッキー（不明瞭なデータ） ・マネージャ ・世代番号 ・属性

【０１５６】名前 エントリ名は、ｊａｖａ．ｌａｎｇ．Ｓｔｒｉｎｇオブ
ジェクトであり、ＵＲＬでアドレス可能な任意の文字を
含むことができる。ヌル参照または空の文字列であって
はならないこと、および、そのエントリが属する親の下
の子エントリのいずれとも異なっていなければならない
こと以外に、エントリ名に制限はない。ＳｙｓｔｅｍＥ
ｎｔｒｙクラスは、パス名のコンポーネント・セパレー
タ文字であるフォワード・スラッシュ（「／」）を名前
文字列中に使用できないという追加の制約事項を定義す
る。

【０１５７】 状態エントリは、３つの状態、すなわちドラフト（ｄｒ
ａｆｔｅｄ）状態、公表（ｐｕｂｌｉｓｈｅｄ）状態、
および削除（ｄｅｌｅｔｅｄ）状態をとることができ
る。エントリの状態については、後にこの章の「エント
リ状態」の項で詳細に論じる。

【０１５８】親エントリ 親エントリを参照する。公表状態では、親エントリは常
に有効である。

【０１５９】子エントリ エントリは、その全ての子エントリへの参照を維持す
る。子への参照は、列挙法によって使用可能である（第
５章「データベース・ナビゲーション」を参照された
い）。

【０１６０】ロック 干渉なしにエントリを検査したり、または変更したりす
ることができるようにリーダ−ライタ・ロック機構が用
意されている（ＳｙｓｔｅｍＤａｔａｂａｓｅＬｏｃ
ｋ）。Ｊａｖａモニタ機構（同期キーワード）は、同期
キーワードの範囲内にオブジェクトを排他的にロックさ
せる（コード・ブロックまたはメソッド全体）。しか
し、データベース・エントリ・ロックは、エントリがロ
ックされている間に複数のメソッド呼出しが実施される
ことを考慮している。データベース・エントリ・ロック
はさらに、複数リーダまたは排他的ライタを許容する。
リーダとライタは相互排除である。リーダはいくつあっ
てもよいが、ライタは１つだけである。書込みロックに
は、Ｔｒａｎｓａｃｔｉｏｎオブジェクトが必要であ
る。１つのトランザクションのみが、書込みロックを獲
得し所有する。所有トランザクション自体が、追加のリ
ーダおよびライタを許可するかどうかの方針を決定す
る。現在、Ｔｒａｎｓａｃｔｉｏｎクラスは、単一の排
他的ライタのみを許可する。詳細については第４章「ト
ランザクション」を参照されたい。

【０１６１】クッキー（Ｃｏｏｋｉｅ） クッキーは通常、不明瞭なオブジェクト参照である。し
かし本書で提案している基準アーキテクチャでは、クッ
キーがよりはっきりとした機能を有する。エントリ・ク
ッキーは、そのエントリに割り当てられたサービス・ク
ラス・オブジェクトを保持するのに使用される。クッキ
ーの値は、ＳｙｓｔｅｍＥｎｔｒｙ ｓｅｔＣｏｏｋｉ
ｅ（）メソッドを使用して設定される。この値はｇｅｔ
Ｃｏｏｋｉｅ（）を介して取得される。

【０１６２】マネージャ それぞれのエントリは、マネージャと呼ばれるロード可
能なソフトウェア・コンポーネントによって管理され
る。それぞれの名前空間は、マネージャ・クラスを与え
る。エントリは、データベースに挿入されると、その親
のマネージャを継承する。マネージャは、エントリの方
針を設定するのに使用される。マネージャは、セキュリ
ティ・チェックを実行したり、またはエントリの振舞い
に影響を及ぼすその他の判断を下したりすることができ
る。さらにマネージャは、エントリに持続性を与える機
構である。

【０１６３】世代番号 エントリ世代番号は、単調に増加する６４ビット数（Ｊ
ａｖａ ｌｏｎｇ）であり、エントリが変更されるたび
にエントリのステータスとは無関係に増分される。これ
は、イベント処理のオーバヘッドを必要としない単純な
コヒーレンシ方式のポーリング機構を提供する。エント
リの変更とは、データベース中でのエントリの挿入また
は削除、あるいは属性の追加、変更または削除であると
定義される。

【０１６４】属性 それぞれのエントリには属性が関連づけられる。ただし
属性を持たなくてもよい。属性は、名前（ｊａｖａ．ｌ
ａｎｇ．Ｓｔｒｉｎｇ）と値（ｊａｖａ．ｌａｎｇ．Ｏ
ｂｊｅｃｔ）から成る。属性を追加、変更、削除、およ
び検索するメソッドがＥｎｔｒｙインタフェースに提供
されている。存在する全ての属性名を発見するために、
属性名を列挙することができる。これ以上の構造は属性
に加えられない。名前および値の実際のタイプの決定は
属性のユーザに完全に委ねられている。ＪＳＤは、暗黙
的ブール属性をサポートする。属性だけが追加されて値
が与えられない場合、その属性はブール属性であるとみ
なされる。その存在は真の値を示し、その不在は偽の値
を指示する。属性を追加、除去、および変更するメソッ
ドが提供される。既存の属性に値が割り当てられると、
変更が起こる。属性値（参照）ではなく値オブジェクト
自体が何らかの方法で変更された場合（例えばバイト・
アレイ中のバイトの変更など）、ＪＳＤは、変更が起こ
ったことを検出することができない。同じ属性名および
値をそのエントリに再び割り当てることによってその他
に通知するのは、このような変更を行ったエンティティ
の責任である。その結果、世代番号が増分されイベント
が生成される。属性名を指定する属性関連メソッドのい
ずれかに対して、ＥｎｔｒｙＰｒｏｐｅｒｔｙＮａｍｅ
ＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎを送出し、（読取
ったり、削除したりするよう）指定された属性名が存在
しないことを指示することができる。いくつかのエント
リ・タイプは、何がリーガルな属性名を示すかについて
制約を置くことができる。このようなエントリは、Ｅｎ
ｔｒｙＰｒｏｐｅｒｔｙＮａｍｅＩｎｖａｌｉｄＥｘｃ
ｅｐｔｉｏｎを送出することができる。

【０１６５】属性読取り ｇｅｔＰｒｏｐｅｒｔｙＣｏｕｎｔ（）メソッドを呼び
出すことによって、そのエントリに関連した属性の数が
返される。ｇｅｔＰｒｏｐｅｒｔｙＮａｍｅｓ（）メソ
ッドは、そのエントリに関連した全ての属性名を列挙す
ることができる列挙を返す。属性名が与えられると、そ
の値は、ｇｅｔＰｒｏｐｅｒｔｙＶａｌｕｅ（）メソッ
ドを介して獲得することができる。

【０１６６】属性の追加および属性値の変更 ａｄｄＰｒｏｐｅｒｔｙ（）メソッドは、新しい属性を
追加するか、または既存のメソッドを修正する。追加す
る属性の名前が存在していない場合には、属性名が作成
され、与えられた値が新しい属性名と関連づけられる。
エントリが公表状態にある場合、ＥｎｔｒｙＰｒｏｐｅ
ｒｔｙＩｎｓｅｒｔＥｖｅｎｔが関係消費者に対して生
成される。新しい属性を指示するａｄｄＰｒｏｐｅｒｔ
ｙ（）はｎｕｌｌオブジェクト参照を返す。そのエント
リに対する属性名がすでに存在する場合、その新しい値
がその属性名に関連づけられ、公表エントリに対して、
ＥｎｔｒｙＰｒｏｐｅｒｔｙＶａｌｕｅＣｈａｎｇｅＥ
ｖｅｎｔが生成される。この場合、ａｄｄＰｒｏｐｅｒ
ｔｙ（）が以前の値オブジェクトへの参照を返す。

【０１６７】属性の削除 属性は、ｒｅｍｏｖｅＰｒｏｐｅｒｔｙ（）メソッドを
使用してエントリから削除される。属性を削除するとき
には、公表エントリに対してＥｎｔｒｙＰｒｏｐｅｒｔ
ｙＲｅｍｏｖｅＥｖｅｎｔが生成される。削除された属
性値への参照が返される。

【０１６８】エイリアス・エントリ ＳｙｓｔｅｍＡｌｉａｓＥｎｔｒｙを使用して、データ
ベース中のその他のエントリ、またはその他のエイリア
スを参照する。エイリアスは、他のエントリへの参照を
保持し、（エイリアス・エントリとは別に）それ自体の
属性を維持することができる。しかし、エイリアスが子
を持つことは許されていない。リンク鎖が循環してはな
らない。ただし参照鎖が、ツリーおよび名前空間の境界
を横切ってもよい。複数のエイリアスまたはリンクが１
つのエントリを指すことができる。しかしこれは、それ
ぞれのエイリアスが参照されたエントリの親であること
を意味しない。実際、エイリアスへエイリアシングされ
たエントリは参照を維持しない。したがって、エイリア
シングされたエントリが削除されても、エイリアスは、
削除されたエントリを参照することができる。このエイ
リアスは、削除されたエントリを参照するので、ターゲ
ット・エントリはガベージ・コレクションの対象とはな
らない。このように、エイリアス自体も削除するのでな
ければ、エイリアスを、動的エントリの参照に使用して
はならない。いくつかの非標準名前空間マネージャは、
エイリアスの作成をサポートしない可能性がある。しか
し標準名前空間マネージャは全て、それらをサポートす
る。

【０１６９】エントリ状態 エントリは、３つの異なる状態、すなわちドラフト（ｄ
ｒａｆｔｅｄ）状態、公表（ｐｕｂｌｉｓｈｅｄ）状
態、および削除（ｄｅｌｅｔｅｄ）状態を有し、その寿
命のあいだこれらのいずれかの状態をとる。

【０１７０】ドラフト状態 エントリは最初、データベースの境界の外側、かつＪａ
ｖａのオブジェクト・ヒープの内部に存在するドラフト
状態に構成される。エントリの作成者は、 SystemEntry sample = new SystemEntry("SampleName") のようなコード断片を使用して名前の付いたエントリを
構成する。この状態のエントリになされた変更に対して
はイベントは生成されない。そのためエントリの作成者
は自由に、属性を追加、変更、削除したり、所望の属性
セットを達成したり、後に、データベースの残りの部分
に対してエントリを公表したりすることができる。エン
トリの階層全体をオフラインで構築し、これを、サブツ
リーとして１回の操作で挿入することができる。公表エ
ントリまたは公表エントリの階層をＪＳＤから分離する
こと、およびこれらを、オフラインであるとみなされる
ドラフト状態に戻すことができる。しかし、分離された
エントリへの参照が保持されるので、それらは真の意味
でのオフラインではない。このようなエントリの変更を
反映するイベントは生成されないが、ドラフト・エント
リであっても世代番号は更新される。

【０１７１】公表状態 エントリは、データベース内の公表親エントリの下に挿
入されると、公表状態に移行する。エントリがデータベ
ースに入れられると、関係アプリケーションおよび／ま
たはシステム・サービスは、エントリの名前および／ま
たは属性を検索基準として使用してエントリの場所を見
つけることができる。エントリが挿入されると、ＪＳＤ
は挿入イベントを生成する。新しいエントリの調査に関
係するリスナには、この方法で通知される。さらに必要
に応じて属性イベントが、全ての公表エントリに対して
ＪＳＤによって生成される。

【０１７２】削除状態 エントリの削除は、オフラインのドラフト状態またはオ
ンラインの公表状態のエントリをＪＳＤから除去するこ
とによって実施される。削除されたエントリに対する全
てのメソッド呼出しは失敗となり、ＥｎｔｒｙＤｅｌｅ
ｔｅｄＥｘｃｅｐｔｉｏｎが送出される。削除されたエ
ントリは本質的にガベージ・コレクションを待つが、削
除されたエントリへの参照を保持することができるの
で、それらへの参照が全て解放されるまで、それらの決
定的な振舞いが必要となる。削除されたエントリは、他
のどの状態になることもできない。

【０１７３】状態遷移 図２５に、エントリがその寿命の間に経過する可能性が
ある状態遷移を示す。番号をつけた遷移の定義は以下の
とおりである。 １．エントリが構成される。 ２．エントリが公表親エントリの下に挿入される。Ｅｎ
ｔｒｙＩｎｓｅｒｔＥｖｅｎｔが生成される。 ３．公表子エントリが、（公表）親エントリから分離さ
れる。ＥｎｔｒｙＤｉｓｃｏｎｎｅｃｔＥｖｅｎｔが生
成される。 ４．公表エントリが削除される。ＥｎｔｒｙＲｅｍｏｖ
ｅＥｖｅｎｔが生成される。 ５．ドラフト・エントリが削除される。 ６．ドラフト・エントリがドラフト親エントリの下に挿
入される。 ７．ドラフト子エントリが（ドラフト）親エントリから
分離される。

【０１７４】エントリの操作 ＪＳＤエントリに対しては３つの基本操作、すなわち挿
入、分離、および削除が定義される。

【０１７５】挿入 エントリはドラフト状態に構成される。ドラフト・エン
トリはドラフト親エントリの下、または公表親エントリ
の下に挿入することができる。前者の場合、この子エン
トリはドラフト状態のままであり、後者では、公表状態
に変化する。公表状態では、子エントリはその親エント
リのマネージャを継承する。この手順は、単一のエント
リに適用されるのと同じように、（公表親エントリの下
に挿入された）エントリのサブツリーにも適用される。
サブツリー内のそれぞれのエントリに対して、Ｅｎｔｒ
ｙＩｎｓｅｒｔＥｖｅｎｔが生成され、それぞれのエン
トリは親のマネージャを継承する。挿入は、親エントリ
にｉｎｓｅｒｔ（）メソッドを呼び出し、それに子エン
トリへの参照を与えることによって実行される。親エン
トリは、子エントリの適性を判定し、その挿入を拒否す
ることができる。例えば、親エントリがエイリアス（Ｓ
ｙｓｔｅｍＡｌｉａｓＥｎｔｒｙ）である場合、エイリ
アス・エントリは子エントリをサポートしないので挿入
は失敗に終わる。同様にエントリが、あるタイプの子エ
ントリしか受け入れない場合、またはその他の形態の家
族計画に固執する場合がある。図２６参照のこと。

【０１７６】分離 エントリ（またはサブツリー）を、ドラフト親エントリ
または公表親エントリから分離することができる。親エ
ントリのｄｉｓｃｏｎｎｅｃｔ（）メソッドが呼び出さ
れ、分離する子エントリへの参照が与えられる。その子
エントリの子孫エントリも全て同様に分離される。公表
エントリのみを分離するときには、ＥｎｔｒｙＤｉｓｃ
ｏｎｎｅｃｔＥｖｅｎｔがそれぞれのエントリに対して
生成される。親子関係が分離されるのは、分離された点
においてのみである。子エントリの子孫エントリは全
て、それらの家族関係（サブツリー）を維持する。サブ
ツリー内のエントリは全てドラフト状態に変更され、そ
れらのマネージャへの参照は維持される。図２７を参照
のこと。ＰｅｒｓｉｓｔｅｎｔＳｙｓｔｅｍＥｎｔｒｙ
およびＰｅｒｓｉｓｔｅｎｔＭａｎａｇｅｒによって提
供される持続性実装は分離をサポートしない。マネージ
ャへの参照が維持されるのは、公表親エントリから分離
されたエントリへの参照が保持されている場合には、そ
れらが依然としてアクセス可能である可能性があるから
である。したがって、マネージャ参照は、分離されたエ
ントリに実施されたメソッド呼出しを管理し、これらの
エントリは、新しく構成されたドラフト・エントリほど
原始的（ｐｒｉｓｔｉｎｅ）にはならない。ドラフト親
エントリからドラフト・エントリのサブツリーを同じよ
うに分離することができる。この場合、手順は同一であ
るがイベントは生成されない。

【０１７７】削除 エントリ（またはサブツリー）の削除には、ＪＳＤのト
ランザクション性が与えられた２段階のプロセスが関与
する。失敗の場合に全ての操作をロールバックすること
ができなければならず、したがってエントリ削除の第１
の段階はエントトリの分離になる。分離が成功した場合
には、トランザクションのコミットに続いて実際の削除
が実施される。サブツリー除去の最終段階を示す図２８
参照。ガベージ・コレクションを促すために、削除され
たエントリによって保持された全ての参照はヌルにセッ
トされる。これには、全ての家族参照、マネージャ、ク
ッキー、ロック、ならびにエイリアスの場合のエイリア
シングされたエントリ参照などが含まれる。それらが、
ＪＳＤの公表エントリであった場合には、分離されたエ
ントリと同様に、削除されたエントリへの参照をそのま
ま維持し続けることができる。削除されたエントリにつ
いてメソッドを呼び出すと、ＥｎｔｒｙＤｅｌｅｔｅｄ
Ｅｘｃｅｐｔｉｏｎが送出される。これは、その参照の
保持者に、それを解放し、削除されたエントリをガベー
ジ・コレクションの対象とすることを指示する。

【０１７８】エントリ・イベント システム・データベースは、データベースの変更を指示
するイベントを生成する。全てのデータベース・イベン
トは、ＳｙｓｔｅｍＤａｔａｂａｓｅＥｖｅｎｔベース
・クラスから派生する。したがって、そのイベント・オ
ブジェクトのクラスは、受け取ったイベントのタイプを
指示する。イベント・オブジェクトｇｅｔＥｎｔｒ
ｙ（）メソッドは、影響を受けたデータベース・エント
リへの参照を返す。Ｊａｖａ Ｓｙｓｔｅｍ Ｅｖｅｎ
ｔ（ｊａｖａｘ．ｓｙｓｔｅｍ．ｅｖｅｎｔｓ）サブシ
ステムは、イベントの生成者と消費者とを突き合せ、必
要に応じてイベントを送る機構として使用される。ＪＳ
Ｅは、イベント・オブジェクトを用いてターゲット消費
者を改善するのにＪＳＤが使用するイベント・フィルタ
文字列を与える。ＪＳＤイベントは、そのイベントが関
係するエントリまでのパス名を表す文字列を含む。ＪＳ
Ｅフィルタを、イベントの送達をさらにリファインする
のに使用することができる。ＪＳＤイベントに関係する
消費者は、ＪＳＥに直接に名前を登録する。この時点
で、イベント登録のためのＪＳＤ ＡＰＩはない。ＪＳ
Ｄは、全てのＪＳＤイベント・クラスの独占的生成者と
してＪＳＥに名前を登録する。そのため、その他のソー
スがＪＳＤイベントを生成することはできない。イベン
ト・フィルタリングを用いると、例えばイベント消費者
だけが、／ｓｏｆｔｗａｒｅ名前空間内のエントリに関
係するイベントに関与することができるようになる。こ
のリスナは、フィルタ文字列「／ｓｏｆｔｗａｒｅ」を
登録することができ、「／ｓｏｆｔｗａｒｅ」で始まる
フィルタ文字列を含んでいるイベントだけが消費者に送
達される。消費者への不必要なコンテキスト切替えを排
除するため、このフィルタリングはイベント生成者のコ
ンテキストで実行される。ＪＳＥイベント・フィルタリ
ング機構は事実上の汎用性を有する。これは、スコーピ
ング・イベントに備えるために特にＪＳＤによって使用
され、消費者は、それらが関係する範囲のイベント・ク
ラス・タイプをそれらに送る。スコーピングは汎用では
ない。このフィルタ文字列は、プレフィックス（ｊａｖ
ａ．ｌａｎｇ．Ｓｔｒｉｎｇ．ｓｔａｒｔｓＷｉｔ
ｈ（））としての働きだけをする。一般的な正則表現等
は現在のところサポートされていない。したがって、イ
ベント範囲を設定することはできず、そのため、例えば
「／ｔｅｍｐ」、「／ｃｏｎｆｉｇ」の中のイベントが
関係するとみなされる。範囲がヌルまたは「／」である
と、指定されたクラスの全てのイベントが送達される。

【０１７９】ＪＳＤの主要なイベント・カテゴリは２つ
ある。 ・データベース階層に関係するもの（エントリの挿入、
分離、除去など） ・エントリの属性の変更の指示に使用されるもの（属性
の追加、除去、変更など） ＳｙｓｔｅｍＤａｔａｂａｓｅＥｖｅｎｔまたはそのサ
ブクラスの１つをサブクラス化することによって、新し
いイベント・カテゴリを将来、導入することができる。
ＪＳＥは、イベント消費者が、Ｊａｖａクラス階層を利
用することに備えている。すなわち、ＥｎｔｒｙＰｒｏ
ｐｅｒｔｙＥｖｅｎｔを聴取（ｌｉｓｔｅｎ）すること
によって、リスナは、ＥｎｔｒｙＰｒｏｐｅｒｔｙＥｖ
ｅｎｔタイプのイベントおよびその全てのサブクラスを
受け取る。その結果、指定のスコーピングを受けた、属
性変更に関係する全てのイベント（エントリの挿入、分
離、および除去には関係しない）が受け取られる。

【０１８０】イベント・クラス階層 ＪＳＤのイベント・クラス階層を図２９に示す。Ｓｙｓ
ｔｅｍＤａｔａｂａｓｅＥｖｅｎｔの聴取の結果、全て
のデータベース・イベントが受け取られる。イベント・
クラス・タイプは、Ｊａｖａのｉｎｓｔａｎｃｅｏｆオ
ペレータを介して区別することができる。ＥｎｔｒｙＥ
ｖｅｎｔおよびその全てのサブクラスは、影響を受けた
エントリへの参照を含む。ＥｎｔｒｙＰｒｏｐｅｒｔｙ
Ｅｖｅｎｔおよびそのサブクラスに、影響を受けた属性
の名前を問い合わせることができる。以前の属性値（オ
ブジェクト参照）は、ＥｎｔｒｙＰｒｏｐｅｒｔｙＲｅ
ｍｏｖｅＥｖｅｎｔおよびＥｎｔｒｙＰｒｏｐｅｒｔｙ
ＶａｌｕｅＣｈａｎｇｅＥｖｅｎｔから使用可能であ
る。イベント・リスナとして登録するマネージャは、イ
ベントを受け取ると適当なアクションをとることができ
る。例えばＰＣＭＣＩＡマネージャは、挿入および除去
イベントを聴取し、ユーザがＰＣＭＣＩＡカードを挿入
または取り出すときに適当に行動し、関連サービスをロ
ードまたはアンロードし、カードに関係するインタフェ
ース・エントリを追加または除去することができる。１
つのレベルのリスナによるイベント応答によって、別の
リスナにアクションを起こさせるイベントが生成される
ことがある。例えば、ＰＣＭＣＩＡモデム・カードを挿
入することによって、ＰＣＭＣＩＡマネージャが、その
カードに必要なサービス（ドライバなど）をロードし、
Ｉｎｔｅｒｆａｃｅ名前空間内にエントリを作成する。
これによって、ダイヤラ・アプレットなどのより高いレ
ベルのサービスをｉｎｔｅｒｆａｃｅ名前空間マネージ
ャが見つけようとする別のイベントが生成される。

【０１８１】第４章 トランザクション トランザクションは、ＪＳＤの１つまたは複数の関係エ
ントリを原子的にロックしたり、書き込んだりする手段
である。Ｔｒａｎｓａｃｔｉｏｎクラスは、エントリへ
の書込みアクセスのために排他的に実装される。すなわ
ち、トランザクション・オブジェクトは、エントリへの
全ての書込みアクセスに必要であるが、読取りアクセス
には必要ない（ただし読取りアクセスが、トランザクシ
ョン・エントリ・ロックに影響を与えることがある）。
エントリの任意の集合を、トランザクションに関与させ
ることができる。

【０１８２】サブツリー・トランザクション ＪＳＤトランザクション・モデルはデータベースのサブ
ツリー上で動作する。図３０にサブツリーを示す。サブ
ツリーは、黒く塗りつぶしたエントリで示されている。
このサブツリーは、ルート・エントリによって定義さ
れ、その子孫エントリの階層を通って全ての葉エントリ
まで延びる。トランザクションは、後に「機構」の項で
説明するエントリ・ロックを獲得する。書込みアクセス
では、ロックは、単一のトランザクション・オブジェク
トに排他的に関連づけられる。排他ロック操作が試みら
れるとき、それを許可するかどうかの決定は、所有トラ
ンザクションのａｌｌｏｗＷｒｉｔｅ（）メソッドに委
ねられる。Ｔｒａｎｓａｃｔｉｏｎの現行の実装では、
エントリ・ロックへのアクセスが、所有トランザクショ
ンを構成したスレッドだけに制限されている。これによ
って、エントリ・ロックはスレッドの細分性を与える。
しかし所有スレッドは、ロックの再入が許されている。
この方針は将来、トランザクションのメンバーへのマル
チ・スレッド（おそらくはスレッド・グループ）同時ア
クセスができるように改められる可能性がある。しか
し、ＪＳＤの最初のリリースにそれだけの複雑さは必要
ない。

【０１８３】トランザクションの定義 ＪＳＤは、分散したフラットなトランザクション・モデ
ルを提供する。トランザクションは、［１］に定義され
ているように、４つの属性、すなわちＡＣＩＤ属性を提
供しなければならない。 １．原子性（Ａｔｏｍｉｃｉｔｙ）。トランザクション
に関連した全ての状態変化が起こらなければならない
か、または状態変化が一切起こってはならない。 ２．整合性（Ｃｏｎｓｉｓｔｅｎｃｙ）。コミットされ
たトランザクションが状態を正確に変換する。 ３．分離（Ｉｓｏｌａｔｉｏｎ）。トランザクションは
コヒーレント状態を保証しなければならない。複数のト
ランザクションが状態を同時に修正することはできな
い。ただし、状態を直列に修正することはできる。 ４．耐久性（Ｄｕｒａｂｉｌｉｔｙ）。トランザクショ
ンが正常終了した場合には、その後にどんな障害（シス
テム・クラッシュなど）が起きても状態変化は維持され
る。 クライアントでは、メモリ・ベースのローカル・トラン
ザクションは耐久性ではない。分散トランザクション・
モデルは、持続性をサポートするのに必要である。Ｔｒ
ａｎｓａｃｔｉｏｎクラスは、従属分散トランザクショ
ン識別子を定義できる。持続性実装は従属トランザクシ
ョンを利用し、ＡＣＩＤ属性が、エンド・ツー・エンド
のフィーチャとなり、全体のＪＳＤトランザクション機
構が持続性エントリに対するものとなるようにしなけれ
ばならない。持続性エントリ用のネットワーク・コンピ
ュータ基準実装の最初のリリースでは、ＡＣＩＤ属性の
「Ｄ」（耐久性）が、ホスト・オペレーティング・シス
テムのファイル・システムを介した基礎をなすＢｔｒｅ
ｅへの書込みの正常終了までに制限される。 [1] Transaction Processing: Concepts and Technique
s,Jim Gray,Andreas Reuter,Morgan Kaufmann Publishe
rs,1993.ISBN 1-55860-190-2.

【０１８４】トランザクション使用の概要 ＪＳＤトランザクションの使用には以下の３つの段階が
関与する。 １．Ｔｒａｎｓａｃｔｉｏｎオブジェクトを構成する。
サブツリーのルートは、コンストラクタへの引き数とし
て指定される。構成中、サブツリーの中の全てのエント
リは、トランザクションによって排他的にロックされ
る。持続性機構、すなわちローカル・ファイルまたはリ
モート・サーバが関与する場合には、コンストラクタが
例外を送出せずにリターンした後に、必要な全てのロッ
クがエンド・ツー・エンドで実施される。 ２．ロックされたエントリに、エントリ属性の挿入、分
離、削除、または修正などの操作を、Ｅｎｔｒｙ ｉｎ
ｓｅｒｔ（）、ｄｉｓｃｏｎｎｅｃｔ（）、ｒｅｍｏｖ
ｅ（）、ｒｅｍｏｖｅＰｒｏｐｅｒｔｙ（），およびａ
ｄｄＰｒｏｐｅｒｔｙ（）メソッドを介して実行する。 ３．ｃｏｍｍｉｔ（）メソッドを呼び出してトランザク
ションをコミットするか、またはａｂｏｒｔ（）メソッ
ドを介してトランザクションをロールバックする。これ
らのメソッドは、トランザクションによって保持された
全てのエントリ・ロックを解除する。ａｂｏｒｔ（）メ
ソッドは、トランザクションをロールバックし、トラン
ザクション・オブジェクトを無効にし、それ以後、これ
を使用できなくする。これは、エンド・ツー・エンド手
順であり、そのため、持続性のために必要な従属トラン
ザクションもコミットされるかまたは打ち切られる。Ｊ
ＳＤエントリへのアクセスは、エントリの探索およびそ
れらの属性値の読取りに最適化される。少なくともＪＳ
Ｄを初期化した後は、ＪＳＤアクセスの大部分がこのタ
イプになることが予想される。このようにエントリ・ロ
ック機構（ＳｙｓｔｅｍＤａｔａｂａｓｅＬｏｃｋ）は
複数のリーダを収容する。読取りは、トランザクション
・ベースではないが、原子性が重要な場合には、いくつ
かのエントリ読取りロックを獲得することができる。し
かし近い将来、デッドロック回復プロセスを援助するた
めに、ＪＳＤで、読取りがトランザクションの対象とな
る可能性がある。ＪＳＤへの全ての書込みアクセスには
トランザクション・オブジェクトが必要である。トラン
ザクションに関与するそれぞれのエントリに対して、排
他ロックを獲得しなければならない。これによってオー
バヘッドが生じる。トランザクションは楽観的であり、
トランザクションの進行中にＪＳＤに実際に変更が実施
される。トランザクションが打ち切られるまれなケース
にのみ、潜在的に時間消費性のロールバックが実施され
る。

【０１８５】機構 エントリ、エントリ・ロック、およびトランザクション
は非常に絡み合っている。エントリはその危険地域を定
義し、エントリ・ロックが適正に使用されるようにチェ
ックする。ｇｅｔＰｒｏｐｅｒｔｙＶａｌｕｅ（）、ｇ
ｅｔＰｒｏｐｅｒｔｙＣｏｕｎｔ（）メソッドなどのメ
ソッドを用いてエントリに読取りアクセスするとき、エ
ントリは、属性リストにアクセスする前に読取りアクセ
スにロックされ、メソッドがリターンする前にロック解
除される。読取りアクセスは現在、トランザクション・
オブジェクトを含まないが、読取りロックによって、ト
ランザクション・ベースの書込みロックは待機状態とな
る。排他アクセスが許されたときにのみ、書込みロック
は成功する。エントリの状態を変更する（ｉｎｓｅｒｔ
（ ）、ｄｉｓｃｏｎｎｅｃｔ（）、ｒｅｍｏｖ
ｅ（））か、あるいは属性値を削除または変更する（ｒ
ｅｍｏｖｅＰｒｏｐｅｒｔｙ（）、ａｄｄＰｒｏｐｅｒ
ｔｙ（））全てのエントリ・メソッドは、トランザクシ
ョン・オブジェクトを必要とする。これらのエントリ・
メソッドは、トランザクションがエントリをロックして
いることを確認してから、先に進む。ロックされていな
い場合には、ＥｎｔｒｙＬｏｃｋＳｔａｔｅＥｘｃｅｐ
ｔｉｏｎが送出され、メソッドは失敗に終わる。エント
リ・ロックはアクセスの獲得をいつまでも待つわけでは
ない。ＪＳＤは、エントリにアクセスするパブリックＡ
ＰＩ（すなわちエントリ読取りロック・メソッドｌｏｃ
ｋＲｅａｄ（）およびｕｎｌｏｃｋＲｅａｄ（））およ
びＴｒａｎｓａｃｔｉｏｎクラスを提示するので、故意
または偶然のＪＳＤデッドロックは回復可能でなければ
ならない。デッドロックを確実に防ぐことはできず、そ
のため、検出と回復が唯一のオプションとなる。エント
リ・ロックへの（読取りまたは書込み）アクセスの獲得
を待っている間にスレッドがタイムアウトすると、デッ
ドロックが検出される。これが起こると、ロックを所有
するトランザクションのｓｙｓＡｂｏｒｔ（）メソッド
が呼び出される。これによって、所有トランザクション
が（ロールバックされて）打ち切られ、それが保持する
ロックが解除される。従属トランザクションも全て打ち
切られる。トランザクション・オブジェクトは無効とな
り、将来にこれを使用しようとすると、Ｔｒａｎｓａｃ
ｔｉｏｎＩｎｖａｌｉｄＥｘｃｅｐｔｉｏｎが送出され
る。ロックがタイムアウトとなったスレッドに対して
は、ＥｎｔｒｙＬｏｃｋＴｉｍｅｏｕｔＥｘｃｅｐｔｉ
ｏｎが送出される。この時点でそれは、ロックの獲得を
再試行すべきか、またはこの操作を打ち切るべきかを判
断することができる。デッドロックを引き起こしたトラ
ンザクションに対しては、割込み源トランザクションの
オーナに混乱を収拾させるのではなく、ＪＳＤ自体が、
そのロックのロールバックおよび解除を誘導することに
留意されたい。これによって、ＪＳＤが有効な状態に戻
ることが保証される。トランザクション・オブジェクト
のユーザには、トランザクション・オブジェクトを使用
した将来のメソッド呼出しによって送出されるＴｒａｎ
ｓａｃｔｉｏｎＩｎｖａｌｉｄＥｘｃｅｐｔｉｏｎによ
って通知される。相互作用を示す図３１を参照。

【０１８６】例外 トランザクションおよびエントリ・ロックに関係するＪ
ＳＤの例外階層を図３２に示す。Ｔｒａｎｓａｃｔｉｏ
ｎＩｎｖａｌｉｄＥｘｃｅｐｔｉｏｎは、無効なトラン
ザクション・オブジェクト（打ち切られたトランザクシ
ョン・オブジェクト）が、エントリに提示された（例え
ばａｄｄＰｒｏｐｅｒｔｙ（））とき、またはそのトラ
ンザクションにメソッド呼出しが実施された場合（例え
ばｃｏｍｍｉｔ（））に送出される。このイベントは、
トランザクションのユーザに、それをもう使用できない
こと、ＪＳＤの一切の変更がすでにそのためにロールバ
ックされたことを知らせる。再試行するためには、新し
いトランザクション・オブジェクトを構成する必要があ
る。ＥｎｔｒｙＥｘｃｅｐｔｉｏｎクラスは、全てのエ
ントリ特定例外のスーパークラスである。これは、例外
が関係するエントリへの参照を返すメソッドｇｅｔＥｎ
ｔｒｙ（）を提供する。ＥｎｔｒｙＬｏｃｋＥｘｃｅｐ
ｔｉｏｎは、エントリ・ロックに関係する全ての例外に
対して同じ役割を果たす。エントリ・ロック例外は以下
のように定義される。

【０１８７】ＥｎｔｒｙＬｏｃｋＳｔａｔｅＥｘｃｅｐ
ｔｉｏｎ トランザクションによって所有されていないロックを解
除しようとするか、または、リーダ・カウントのアンダ
フローの発生によって生じる。このイベントを受け取る
理由にはこの他、提供されたトランザクションがエント
リ・ロックをすでに所有していることを期待するエント
リ・メソッド（例えばａｄｄＰｒｏｐｅｒｔｙ（））が
呼び出されたが、ロックを所有していない場合がある。
エントリは構成時に、トランザクションの一部となって
いなければならない。

【０１８８】ＥｎｔｒｙＬｏｃｋＴｉｍｅＯｕｔＥｘｃ
ｅｐｔｉｏｎ タイム・アウトは、トランザクション・コンストラクタ
を介して書込みロックを獲得するのを待っている間、ま
たはＥｎｔｒｙ ｌｏｃｋＲｅａｄ（）メソッドを介し
て読取りロックを獲得するのを待っている間に起こる。
これは、デッドロックの検出を指示する。

【０１８９】トランザクション・オブジェクトの詳細 トランザクション・クラスはイベント待ち行列（ＪＳＥ
ＯＳＥｖｅｎｔＱｕｅｕｅ）、およびトランザクショ
ンが保持するロックを記録するスタックを定義する。ロ
ックは、トランザクション・オブジェクトを構成する間
に指定されたエントリに対して獲得される。ロックされ
たエントリに修正が加えられている間、ＪＳＤイベント
は、トランザクション・イベント待ち行列の中に維持さ
れ、トランザクションがコミットされるまでイベント消
費者はこれを使用することができない。イベント待ち行
列およびその他の補助的ＳｙｓｔｅｍＥｎｔｒｙフィー
ルドを使用して、トランザクションをロールバックする
ことができる。この場合、イベント待ち行列は、トラン
ザクション中に実行された操作の記録の役目を果たす。
トランザクションがコミットされると、待ち行列中のイ
ベントは、関係イベント消費者に配布される。この代わ
りにトランザクションが打ち切られた場合には、待ち行
列を使用して、すでに実施された変更が取り消される。
ロールバックが済むと、待ち行列中のイベントは掲示さ
れなくなる。パブリック・コンストラクタは１つの引き
数、すなわち、トランザクションのあいだロックされる
データベースのサブツリーのルートを示すエントリを受
け取る。この時点で、イベント待ち行列およびロック・
スタックが作成される。それはさらに、カレント・スレ
ッドのＩＤを記録し、トランザクションの状態を有効に
セットする。 public Transaction(Entry subTreeRoot) throws Syste
mDatabaseException; トランザクションは、以下のメソッドを使用して所有ス
レッドによってコミットされるか、または打ち切られ
る。 final public void commit() throws SystemDatabaseEx
ception; final public void abort(); トランザクションの状態は、 final public boolean isValid() を介して問い合わせることができる。残りのメソッド
は、プライベート・パッケージであり、分散管理を含め
て、トランザクションの管理にＪＳＤの内部で使用され
る。さらに、ＳｙｓｔｅｍＥｎｔｒｙメソッドは更新の
進行中にトランザクションにイベントを通知する。

【０１９０】トランザクションの完了 トランザクションは、以下に示す４つの方法のいずれか
で完了となる。 １．トランザクションを使用するスレッドが、トランザ
クション（および従属分散トランザクションがローカル
に）が失敗したことを指示する例外を受け取っていな
い。この場合、スレッドは、関連イベントをポストする
ｃｏｍｍｉｔ（）メソッドを呼び出し、トランザクショ
ンが保持する全てのロックを解除する。 ２．ＪＳＤが、所有スレッドに失敗例外を送出しない場
合でも、スレッドが、（その他の高位の理由で）トラン
ザクションの打切りを決定することがある。この場合に
スレッドは、その変更（および従属トランザクションの
変更）をロールバックするａｂｏｒｔ（）メソッドを呼
び出し、イベント待ち行列を無効にし、全てのロックを
解除する。トランザクション・オブジェクトは無効状態
となり、それ以降それを使用することができない。 ３．一般にデッドロック回復アクションの一部としてＪ
ＳＤ自体が、ｐａｃｋａｇｅ ｐｒｉｖａｔｅ ｓｙｓ
Ａｂｏｒｔ（）メソッドを使用してトランザクションを
打ち切る。所有スレッドによる打切りと同様に、トラン
ザクションはロールバックされ、イベント待ち行列は無
効化され、全てのロックは解除される。トランザクショ
ンは無効状態となる。これは、所有スレッドとは非同期
に実施されるので、所有スレッドが、このトランザクシ
ョン・オブジェクトを将来に使用しようとすると、Ｔｒ
ａｎｓａｃｔｉｏｎＩｎｖａｌｉｄＥｘｃｅｐｔｉｏｎ
が送出されて、システム主導の打切りが所有スレッドに
通知される。 ４．トランザクションを所有するスレッドが終了してい
る場合、トランザクションは、上記３に記載した方法で
ｓｙｓＡｂｏｒｔ（）を介して打ち切られる。

【０１９１】コミット トランザクション中に変更が実施されるとそれらはロー
カルＪＳＤに加えられる。イベントが変更されると、そ
れらは、トランザクション・イベント待ち行列にポスト
される。トランザクションがコミットされると、待ち行
列中のイベントが、（イベントが受け取られた順に）全
ての関係消費者にポストされ、トランザクションが保持
する全てのロックが解除される。キー・トランザクショ
ン・コンポーネントでは、エントリ（またはサブツリ
ー）がＪＳＤから削除されるとき、エントリはＪＳＤか
ら分離されるだけである。トランザクションがコミット
されたときにのみ、分離されたエントリ（サブツリー）
は実際に削除される。分離されたエントリの削除に失敗
が生じる可能性はない。

【０１９２】打切り トランザクションが打ち切られると、ＪＳＤへの全ての
変更はロールバックされ、その後、全てのロックが解除
される。ロールバックは、複雑で、潜在的に時間消費的
なプロセスであり、持続性が関与するときには特にそう
である。楽観的にトランザクションを見ると、ロールバ
ックはまれなイベントであると期待される。トランザク
ション・イベント待ち行列は、ロールバック・プロセス
を制御する機構である。イベントは、後入れ先出し方式
で待ち行列から削除される。この時点で、イベント待ち
行列はイベント・スタックとして使用されている。削除
されるエントリ（サブツリー）は、この時点では分離さ
れているだけであり（上記参照）、簡単に再接続するこ
とができる。挿入されたエントリは分離され（ドラフト
状態に戻り）、分離されたエントリは再接続される。属
性に関係するイベントは古い属性値を含み、そのためそ
れらを復元することができる。挿入された（新しい）属
性は削除される。

【０１９３】分散モデル 過渡エントリへのトランザクションの実行はクライアン
ト側でローカルに起こる。その他のホストは関与せず、
ローカル持続性実装も含まれない。このようなトランザ
クションはＡＣＩ特性を満たす。過渡エントリの耐久性
は保証されない。ＡＣＩＤ特性が持続性エントリにあて
はまることを保証するためには、持続性実装による作業
が必要である。ＩＩＯＰの他にＪＳＤプロトコルを使用
するネットワーク・コンピュータ基準のデフォルト持続
性実装によって、エンド・ツー・ニヤ・エンド実装が行
われる。先に述べたように、この実装は、ホスト・オペ
レーティング・システム・インタフェースを使用してフ
ァイルを書き込む。これを「ニヤ・エンド」とするの
は、ファイル・システムのバッファ・キャッシュが関与
し、現在のところ、サーバ上のトランザクションが、デ
ィスク媒体へのビットの書込みが成功したことを検査す
るまでには拡張されていないからである。将来的にはそ
のように拡張される可能性がある。将来の持続性実装が
同様のことを保証しない場合、持続性エントリのトラン
ザクションはこれらの実装でＡＣＩＤを満たさない。

【０１９４】トランザクションの成功 図３３に、２つの持続性エントリ、ｅｎｔｒｙ１および
ｅｎｔｒｙ２に関するトランザクションを示す。ｅｎｔ
ｒｙ２は、ｅｎｔｒｙ１の子孫エントリである。クライ
アントでトランザクションが構成される（ｃｔ）。持続
性機構の結果、サーバにトランザクションが構成され
（ｓｔ）、エントリがエンド・ツー・エンドでロックさ
れることが保証される。持続性実装は、サーバで使用す
るコアレセンス（ｃｏａｌｅｓｃｅｎｃｅ）アルゴリズ
ムを考慮に入れて、クライアント・エントリをサーバ・
エントリにマップすることができなければならない。番
号付きの矢印は以下のことを表す。 １．持続性エントリへの参照が、クライアントのトラン
ザクション・コンストラクタに与えられ、持続性機構に
よって、サーバ上にもトランザクションが構成され、ク
ライアントからサーバへエンド・ツー・エンドでサブツ
リーがロックされる。 ２．クライアントが、ｅｎｔｒｙ１の属性を追加／変更
する。これによって、クライアントのｅｎｔｒｙ１のコ
ピーが更新され、次いでサーバのｅｎｔｒｙ１のコピー
も更新される。 ３．クライアントが、ｅｎｔｒｙ２の属性を追加／変更
する。これによって、クライアントのｅｎｔｒｙ２のコ
ピーが更新され、次いでサーバのｅｎｔｒｙ２のコピー
も更新される。 ４．クライアントが、ローカル・トランザクションのコ
ミットを試みる。クライアントはまず、トランザクショ
ンのコミットをサーバに要求する。次いでクライアント
もコミットする。 ２つのトランザクション・オブジェクトがコミットさ
れ、エントリ・ロックが解除される。Ｔｒａｎｓａｃｔ
ｉｏｎクラスは、分散従属トランザクションを結び付け
る識別子を維持する。これらの識別子を使用して、一貫
性のある結果を得るのに必要な初期接続手順（ｈａｎｄ
ｓｈａｋｉｎｇ）を実装するのは、持続性実装の責任で
ある。

【０１９５】トランザクション失敗モード 開始クライアント・トランザクションは、従属サーバ・
トランザクションの識別子を保持する。サーバ・トラン
ザクションは、クライアント・トランザクションの識別
子を保持する。これらの識別子およびローカル・タイム
アウト機構は、トランザクション全体をエンド・ツー・
エンドに打ち切り、ロールバックするのに不可欠であ
る。

【０１９６】クライアント打切り 何らかの理由でクライアントがトランザクションを打ち
切る場合には、サーバ・トランザクションも打ち切られ
なければならない。クライアントは、従属トランザクシ
ョンの識別子を使用してサーバにトランザクションの打
切りを命じる。全ての変更はロールバックされ、全ての
ロックが解除される。クライアントでは、この打切りプ
ロセスによって、全てのローカル変更がロールバックさ
れ、全てのローカル・ロックが解除される。サーバの持
続性機構も、トランザクションに代わって、持続性記憶
に書き込まれた変更をロールバックしなければならな
い。

【０１９７】サーバ打切り 従属サーバ・トランザクションを打ち切る場合には、サ
ーバは、クライアント・トランザクションの識別子を与
えてクライアントにトランザクションの打切りを命じ
る。前記のクライアント打切りのシナリオと同様に、ロ
ールバックは、クライアントとサーバの両方で実施され
る。

【０１９８】コンタクトの喪失 トランザクションは、タイムアウト機構を実施する。タ
イムアウトするとトランザクションは打ち切られる。こ
の打切りの間に、従属トランザクションも打ち切られ
る。トランザクション・オブジェクトは無効になる。後
に、リモート識別子を介してトランザクションにアクセ
スする場合、それは失敗に終わり、その識別子にアクセ
スしているトランザクションはその時点で打ち切られ
る。２つの相互依存トランザクションを有する１クライ
アント、１サーバの構成では、以下の回復アクションが
可能である。 １．リモート・トランザクションが開始されると、クラ
イアントはサーバとコンタクトすることができない。あ
る時点で、クライアント・トランザクションがタイムア
ウトし、打切りとなる。サーバが依然として作動してい
る（例えばネットワークの問題などで）場合、そのトラ
ンザクションもある時点でタイムアウトし、打切りとな
る。その結果、クライアントとサーバの両方がロールバ
ックされる。 ２．分散トランザクションの処理がクライアントによっ
て開始され駆動される。サーバ・トランザクションがタ
イムアウトし、打ち切られた場合、クライアントが、リ
モート・トランザクション識別子を次に利用しようとし
たときに、クライアントにこのことが通知され、クライ
アントは、そのローカル・トランザクションを打ち切
る。 ３．コンタクトが失われている時間が短く、どちらのト
ランザクションもタイムアウトしていない場合、完全な
トランザクションを先に進めることができる。

【０１９９】 コード例 複数の原子性更新を実行して、単一のエントリにアクセスする。 Transaction t = new Transaction(entryl); try [ entry1.addProperty(t, "name1", value1); entry1.addProperty(t, "name2", value2); entry1.removeProperty(t, "name3"); t.commit(); ] (catch TransactionInvalidException ex) [ //再試行？ロールバック済み ] ３つの異なるエントリにアクセスし、原子的な方法でそれらを修正する。この 例で、ｅｎｔｒｙ２およびｅｎｔｒｙ３はｅｎｔｒｙ１の子孫エントリである。 Transaction t = new Transaction(entry1); try [ entry1.addProperty(t, "name1", value1); entry2.addProperty(t, "name2", entry3 .getPropertyValue("name3")); t.commit(); ] (catch TransactionInvalidException ex) [ //再試行？ロールバック済み ] より現実的な例は、その構成情報を更新するアプリケーションである。 Tree t = SystemDatabase.getTree(); try [ Entry me = t.findEntry("/software/application/com.appsRus/ killerappl") ; Transaction t = new Transaction(me); me.addProperty(t, "background", bgValue); me.addProperty(t, "foreground", fgValue); t.commit() ; ] catch (EntryNotFoundException ex) [ //おっとまだ適正にインストールしていなかった ] catch (TransactionlnvalidException ex) [ //再試行？ロールバック済み ]

【０２００】第５章 データベース・ナビゲーション ツリー 任意のデータベース・エントリをツリーのルートに指定
すること、および任意のデータベース・エントリがＴｒ
ｅｅインタフェースからの一連のメソッドに応答するこ
とができる。ルートの子孫エントリは全てツリーの一部
である。あるコンテクストを提供するため、ツリー・イ
ンタフェースを使用して、全てのツリーに共通のメソッ
ドを定義する。これらには、以下のメソッドが含まれ
る。 ・ルート・エントリ ・カレント・エントリ ・ツリー・ポピュレータ ・ファインド・アンド・ニュー ツリーは、ルート・エントリからその全ての子孫エント
リまでの階層全体を含む。ツリーの範囲を制限する深さ
の概念はない。ツリーの名前は、指定されたツリー・ル
ートの名前と同じであり、単一の名前空間に属する。ツ
リーの中のエントリを、ルートまたは指定されたカレン
ト・エントリからのパス名によって参照することができ
る。「／」で始まるパス名は、ツリー・ルートを基準に
してエントリを指名する。その他の形態のパス名は全
て、カレント・エントリを基準にしてエントリを識別す
る。カレント・エントリを取得し、設定するメソッドが
提供されている。ツリーのカレント・エントリは、ＵＮ
ＩＸオペレーティング・システムの現行作業ディレクト
リと類似のものである。

【０２０１】ツリー・ポピュレーション ＴｒｅｅＰｏｐｕｌａｔｏｒインタフェースは、所与の
ツリーをポピュレートする一般的な機構を提供する。将
来のＪａｖａの（例えばセルラ電話などへの）組込みバ
ージョンでは、予め定義された文字列のスタティック・
テーブルからデータベースのセクションをポピュレート
することが望まれる。電話のような単純なプラットフォ
ームは、一続きの文字列で簡単に表すことができるいく
つかの周知の固定デバイスを有する。より複雑なシステ
ムでは、例えばＯｐｅｎＢｏｏｔファームウェア、ホス
ト・オペレーティング・システム情報（ＮＴレジスト
リ）、フラッシュ・メモリなどに基づいてツリー・ポピ
ュレータを実装することができる。

【０２０２】ファインド・アンド・ニュー（Ｆｉｎｄ
Ａｎｄ Ｎｅｗ） Ｔｒｅｅインタフェースは、ツリーの中のパス名ルック
アップを開始するのに使用するメソッド（ｆｉｎｄＥｎ
ｔｒｙ（））、およびツリーに新しいエントリを追加す
るのに使用するメソッド（ｎｅｗＥｎｔｒｙ（））を定
義する。これらのメソッドは、ルート・エントリにｌｏ
ｃａｔｅ（）メソッドを呼び出すのとほぼ同じ働きをす
る。

【０２０３】データベース・パス名 パス名は、データベースの中のエントリを識別する文字
列である。パス名は、名前空間内のスーパールートまた
は指定されたカレント・エントリを基準として解釈され
る。ＵＲＬをパス名として使用することについては検討
中である。

【０２０４】例外 データベース内のエラーはＪａｖａ例外を介して伝達さ
れる。ＳｙｓｔｅｍＤａｔａｂａｓｅＥｘｃｅｐｔｉｏ
ｎクラスは、全てのＪＳＤ関連例外のスーパークラスで
ある。データベース・メソッドの大部分は、Ｓｙｓｔｅ
ｍＤａｔａｂａｓｅＥｘｃｅｐｔｉｏｎの送出によって
宣言される。これは一般に、キャッチ・オール（ｃａｔ
ｃｈ ａｌｌ）表記である。特定のメソッドが送出する
ことができる特定のデータベース例外についてはＪａｖ
ａｄｏｃドキュメンテーションを参照されたい。ＪＳＤ
例外階層を示す図３４参照。ほとんどの種類の例外は、
特定のエントリへのメソッド呼出しに関するエラーに関
係する。それぞれの例外クラスが送出される条件および
使用可能なメソッドの詳細については「例外クラス」の
項を参照されたい。

【０２０５】データベース・ナビゲーション ＪＳＤは、エントリ参照およびパス名ルックアップを介
したナビゲーションを提供する。エントリ参照は、Ｅｎ
ｔｒｙインタフェースのｇｅｔＰａｒｅｎｔ（）および
ｇｅｔＣｈｉｌｄＥｎｔｒｉｅｓ（）メソッドによって
実現される。パス名ルックアップは、Ｔｒｅｅインタフ
ェースによって定義されているｆｉｎｄＥｎｔｒｙ（）
メソッドによって提供される機能である。Ｑｕｅｒｙク
ラスは、エントリ名および属性名に基づいてＪＳＤのよ
り複雑な探索を実行するために提供される。ただし最終
的には、問合せの結果としてエントリ参照が返される。
Ｅｎｔｒｙ ｇｅｔＰａｒｅｎｔ（）メソッドは、その
エントリの親エントリへの参照を返す。エントリは、親
エントリを１つだけ持つ。ドラフト状態のエントリは、
親エントリを持つ場合と持たない場合がある。ｇｅｔＣ
ｈｉｌｄＥｎｔｒｉｅｓ（）は、列挙（ｅｎｕｍｅｒａ
ｔｉｏｎ）を返す。それぞれの子エントリへの参照をこ
の方法で獲得することができる。これらのメソッドは、
データベース・パッケージ自体の内部で一般に使用され
るが、ＪＳＤエントリを検出し、作成する他のより便利
な機構が使用可能である。

【０２０６】Ｔｒｅｅインタフェースは、ｆｉｎｄＥｎ
ｔｒｙ（）およびｎｅｗＥｎｔｒｙ（）メソッドを定義
する。これらのメソッドはともに、問題のエントリのパ
ス名を表す文字列を受け入れる。パス名は、「／ｕｓｒ
／ｂｉｎ／ｒｍ」などのようなＵＮＩＸスタイルのファ
イル名と同様である。例外ＥｎｔｒｙＮｏｔＦｏｕｎｄ
Ｅｘｃｅｐｔｉｏｎ、ＥｎｔｒｙＮａｍｅＥｘｉｓｔｓ
Ｅｘｃｅｐｔｉｏｎ、およびＥｎｔｒｙＮａｍｅＩｎｖ
ａｌｉｄＥｘｃｅｐｔｉｏｎは失敗モードを指示するた
めに送出される。Ｅｎｔｒｙインタフェースは、パス名
ルックアップのフックを提供する。ｌｏｃａｔｅ（）お
よびｉｓＢａｓｅｎａｍｅ（）メソッドがフックにあた
る。ｌｏｃａｔｅ（）メソッドによって、データベース
・エントリが、その子エントリの中に、そのパス名の対
象エントリ（最終コンポーネントまたはベース名）、ま
たは対象エントリに到達するのに通過するコンポーネン
トとなっているエントリを含むかどうか指示する。Ｌｏ
ｃａｔｅＲｅｓｕｌｔクラスのオブジェクトへの参照が
ｌｏｃａｔｅ（）に与えられる。このオブジェクトは、
この呼出しの結果を指示するように修正される。有効な
エントリ名およびパス名コンポーネント・セパレータを
表す文字を明示的に指示しないことによって、ＪＳＤは
柔軟になる。ＳｙｓｔｅｍＥｎｔｒｙベース・クラスの
パス名コンポーネント・セパレータは、フォワード・ス
ラッシュ（「／」）である。このように、Ｓｙｓｔｅｍ
Ｅｎｔｒｙオブジェクトだけから成るパス名は非常にＵ
ＮＩＸに似ている。しかし、Ｅｎｔｒｙインタフェース
のその他の実装は、異なるコンポーネント・セパレータ
文字を選択したり、または名前をある型に限定したりす
ることができる。

【０２０７】図３５に、仮定のｘ８６ベースのクライア
ント上のＪＳＤサブセットを示す。この例では、データ
ベースのこの部分にあるエントリは全て、Ｓｙｓｔｅｍ
Ｅｎｔｒｙオブジェクトである。ブート時、スーパール
ート・エントリを作成した後に、ＳｙｓｔｅｍＴｒｅｅ
オブジェクトが、データベースの最上位ツリーを示すよ
うインスタンス化される。このツリーのルート・エント
リはスーパールート・エントリである。図示の例では、
「／ｄｅｖｉｃｅ／ｉ８６ｐｃ／ｉｓａ」で示されるエ
ントリがツリーのカレント・エントリである。このエン
トリは、このマシンのＩＳＡバスを表す。ＩＳＡバス上
のフロッピー・ディスク・コントローラへのエントリ参
照を取得するためには、システム・データベース・ツリ
ー・オブジェクトのｆｉｎｄＥｎｔｒｙ（）メソッド
を、パス名「／ｄｅｖｉｃｅ／ｉ８６ｐｃ／ｉｓａ／ｆ
ｄｃ」で呼び出すか、または、ＩＳＡバス・エントリが
カレント・エントリとなっているのでパス名「ｆｄｃ」
で呼び出す。最初の文字がセパレータ文字でないパス名
の基準は、ＳｙｓｔｅｍＴｒｅｅオブジェクトに定義さ
れたカレント・エントリとなる。パス名ルックアップが
始まるエントリは、探索開始点（ｓｔａｒｔｉｎｇ ｓ
ｅａｒｃｈ ｐｏｉｎｔ）として知られる。パス名ルッ
クアップは以下のように進行する。

【０２０８】 public Entry findEntry(String path) throws SystemDatabaseException [ entry = getStartingSearchPoint(path); //locateメソッドがLocateResultクラスを介してパスを修正する class while (path is not empty) [ //EntryNotFoundExceptionを送出することができる entry = entry.locate(remaining#path); return entry;

【０２０９】図３５の例を使用して、パス名「／ｄｅｖ
ｉｃｅ／ｉ８６ｐｃ／ｉｓａ／ｆｄｃ」を与えると、探
索開始点はスーパールート・エントリになる。スーパー
ルートでｌｏｃａｔｅ（）が呼び出され、残りのパスが
「ｄｅｖｉｃｅ／ｉ８６ｐｃ／ｉｓａ／ｆｄｃ」にな
る。「ｄｅｖｉｃｅ」という名前の子エントリがあるた
め、ｌｏｃａｔｅ（）は成功し、一致した子エントリへ
のエントリ参照が返される。次いでパス名が「ｉ８６ｐ
ｃ／ｉｓａ／ｆｄｃ」になる。「ｄｅｖｉｃｅ」エント
リのｌｏｃａｔｅ（）メソッドが呼び出され、以下同様
の操作が実施される。最後に、「ｉｓａ」という名前の
エントリのｌｏｃａｔｅ（）メソッドが呼び出され、
「ｆｄｃ」という名前の子エントリを見つける。この時
点で残りのパスはなく、最後のパス名コンポーネントの
マッチングが成功したことが分かる。パス名コンポーネ
ントが、そのエントリの子エントリの１つと一致するか
どうかを指示することに加え、ｌｏｃａｔｅ（）メソッ
ドは、一致したコンポーネントを削除してパス名を更新
する。そのため、前記のｗｈｉｌｅループは最後には終
了する。この機構の利点は、Ｅｎｔｒｙインタフェース
の実装によって、パス・コンポーネントを含むものが定
義されることである。この方針は、子エントリに代わっ
てその親エントリによって実施される。

【０２１０】例えば、装着されたＮＦＳファイル・シス
テムを表す仮定のクラスＮＦＳＥｎｔｒｙを与えると、
ナビゲーションは、図３６のこのエントリ（グレー）に
対してどのような異なる振舞いを見せるだろうか。この
例では、システム・データベース・ツリーのカレント・
エントリは「ｖｏｌｕｍｅ」エントリであり、そのた
め、ＮＦＳマウント・ポイント・エントリには、「／ｉ
ｎｔｅｒｆａｃｅ／ｖｏｌｕｍｅ／ｍｎｔｐｔ」または
単に「ｍｎｔｐｔ」で到達することができる。エントリ
「／ｉｎｔｅｒｆａｃｅ／ｖｏｌｕｍｅ／ｍｎｔｐｔ／
ｄｉｓｔ／ｂｉｎ／ｐｒｏｇ」を見つける手順は、最初
の例と同じように始まる。しかし、ｌｏｃａｔｅ（）メ
ソッドが「ｍｎｔｐｔ」エントリで呼び出されたときに
は、このメソッドに、パス「ｄｉｓｔ／ｂｉｎ／ｐｒｏ
ｇ」が与えられる。メソッドは、この残りのパスを使用
して、ＮＦＳサーバから情報を獲得することができる。
次いでＮＦＳＥｎｔｒｙオブジェクトは、指定されたフ
ァイルを参照するデータベース・エントリを作成するこ
とができる。あるいは、ＮＦＳＥｎｔｒｙ自体がある状
態を維持し、（おそらくは残りのパスに基づいたハッシ
ュテーブル・エントリを介して）ファイル自体を表すこ
とができる。

【０２１１】所与のＥｎｔｒｙ実装を高度にカスタマイ
ズできることは容易に分かる。専門化されたエントリの
ｌｏｃａｔｅ（）メソッドに、パス「ｍａｃｈｉｎｅ
１．ｃｏｍ ｜ ｍａｃｈｉｎｅ２．ｃｏｍ：ＳＴＡＴ
ＵＳ」を与えると、ｌｏｃａｔｅ（）メソッドは、この
文字列を分割する方法を知り、例えば、これらの２つの
マシンにステータスを問い合わせ、次いで、そのステー
タスを表すデータベース・エントリをインスタンス化す
る。パス名に基づいて新しいエントリを作成するときに
は、その文字列のベース名（最後のコンポーネント）
が、新しいエントリの名前に使用される。少なくともＳ
ｙｔｓｅｍＥｎｔｒｙではこれがあてはまる。ルックア
ップ・プロセスの間、個々のエントリのパス名構文は未
知であるので、ＳｙｓｔｅｍＴｒｅｅ ｎｅｗＥｎｔｒ
ｙ（）メソッドは、親ＳｙｓｔｅｍＥｎｔｒｙの地点ま
でのルックアップを実行することができる。残りのパス
と一致する子エントリがない場合、新しいＳｙｓｔｅｍ
Ｅｎｔｒｙオブジェクトがインスタンス化され、先の残
りのパスの名前がその名前となる。

【０２１２】しかし、残りのパスが例えば「ｘｘｘ／ｙ
ｙｙ」であると、これは、ＳｙｓｔｅｍＥｎｔｒｙに対
して無効となる。それはこれが、コンポーネント・セパ
レータを含むからである。ＳｙｓｔｅｍＴｒｅｅは、セ
パレータが何であるか、または、エントリ名にその他の
制限があるかどうかを知らないので、親エントリのｉｓ
Ｂａｓｅｎａｍｅ（）メソッドを呼び出す。このメソッ
ドは、残りのパスが子エントリに適当であるかどうかを
指示する。適当である場合には、親エントリのマネージ
ャを使用して、子エントリとして挿入される新しいイン
スタンスを作成することができる。以上に記載したパス
名ルックアップ法は、外見は任意のＪＳＤルールを単に
全てのエントリに実施する方法よりもいくぶん複雑で、
実装にコストがかかるが、非常に大きなパワーと柔軟性
を提供する。

【０２１３】データベース検索 この項では、データベース検索サービスの概要を説明す
る。ＪＳＤは、指定された基準と一致するエントリを求
めてデータベースを検索するＱｕｅｒｙとＰｒｏｐｅｒ
ｔｙＱｕｅｒｙと呼ばれるクラスを定義する。マッチン
グ基準に、エントリ名または任意の属性名を含めること
ができる Ｑｕｅｒｙオブジェクトは、検索開始点（エントリ）お
よび検索基準を与えることによって構成される。問合せ
は、検索基準と一致するエントリを探すＪａｖａの列挙
インタフェースをサポートする。検索をリセットした
り、バックアップする追加のメソッドも提供される。Ｊ
ＳＤの問合せには以下のものが含まれる。 ・名前（文字列） ・検索範囲 ・検索状態 ・最後の一致エントリ ・現在の一致エントリ

【０２１４】検索基準 Ｑｕｅｒｙクラス・コンストラクタは、検索範囲内に定
義された全てのエントリに対して突き合わせを行う名前
文字列の指定を考慮する。ＰｒｏｐｅｒｔｙＱｕｅｒｙ
コンストラクタは、属性名を検索する同じ機能を提供す
る。 検索範囲 検索の範囲を、自己（ｓｅｌｆ）、親（ｐａｒｅｎ
ｔ）、兄弟（ｓｉｂｌｉｎｇｓ）、子（ｃｈｉｌｄｒｅ
ｎ）、または子孫（ｄｅｓｃｅｎｄａｎｔｓ）とするこ
とができる。 自己 検索開始点のエントリのみを対象に、エントリ名または
属性名を検索する。 親 検索開始点エントリの親エントリのみを対象に、エント
リ名および属性名を検索する。 兄弟 検索開始点エントリ自体を含む全ての兄弟または検索開
始点エントリを対象に、エントリ名および属性名を検索
する。これらより下のエントリは検索しない。 子 検索開始点エントリの直接の子エントリのみを対象に、
エントリ名および属性名を検索する。 子孫 検索開始点エントリの全ての子孫エントリ（サブツリー
階層全体）を対象に、エントリ名および属性名を検索す
る。 検索結果 それぞれの一致エントリへの参照を獲得するメソッド
が、ＱｕｅｒｙおよびＰｒｏｐｅｒｔｙＱｕｅｒｙクラ
スによって提供される。標準Ｊａｖａ Ｅｎｕｍｅｒａ
ｔｉｏｎインタフェースも実装される。

【０２１５】第６章 クライアント／サーバの要点 この章では、ＪＳＤクライアント／サーバ・アーキテク
チャの概要をその高位レベルに限って説明する。現在出
版されているもの、または近く出版されるものの中に、
クライアント／サーバの同期をとるために使用される機
構およびプロトコルをより詳細に述べたものがある。ま
たこの章は、ブート・プログラム（ＰＲＯＭなど）が、
ブート・サーバとコンタクトを確立する方法、コア・オ
ペレーティング・システムをダウンロードする方法、ま
たは必要なプロトコルを呼び出す方法を説明しようとす
るものではない。

【０２１６】導入部 ＪＳＤは、痩せた（ｔｈｉｎ）クライアントの実装を容
易にするクライアント／サーバ・モデルをサポートす
る。このようなクライアントは、ネットワーク上の１つ
または複数のサーバから、構成情報、サービス、アプリ
ケーション、およびユーザ・データ・アクセスを獲得す
る。あるサーバは、クライアントをブートするのに必要
な実行可能でロード可能なサービスをクライアントに提
供し、別のサーバは、ユーザ・ログインを認証し、ユー
ザ特定構成情報をクライアントに提供する。また別のサ
ーバは、アプリケーションおよびユーザ・データの送信
元となる。将来、クライアント自体が、サーバ側ＪＳＤ
を実装し、モバイル（ポータブル）コンピューティング
を提供する可能性がある。この場合、クライアントに
は、ある形態のローカル持続性記憶域（ディスク、フラ
ッシュ・メモリ、バックアップ・バッテリ付きのＲＡＭ
など）が必要となる。ネットワークに再接続されたとき
に、クライアントは、１つまたは複数のサーバと同期を
とることができる。

【０２１７】サーバ・スキーマ サーバには、システム・アーキテクチャの章で説明した
ものと同じ最上位レベル名前空間が存在する。クライア
ントでは、ｓｏｆｔｗａｒｅ名前空間が持続性であり、
この名前空間には、そのハードウェア・プラットホーム
および現在ログインしているユーザに特定の情報が含ま
れる。サーバでは、ｃｏｎｆｉｇ名前空間が持続性であ
る。クライアントは一度に、単一のマシン・アーキテク
チャおよび一人のユーザをサポートすればよいのに対し
て、サーバは、複数のクライアントおよびユーザのため
の情報を維持しなければならない。その結果、ｃｏｎｆ
ｉｇ名前空間は、大きなマシンおよびユーザ・カテゴリ
を含む。ｃｏｎｆｉｇ名前空間のサブスキーマを表す図
３７参照。

【０２１８】マシン サーバは、マシン固有識別子を介して特定のクライアン
トを識別する。これは一般に、ＭＡＣアドレス（イーサ
ネット、トークンリング）およびハードウェア・タイプ
のようないくぶん低レベルのものである。識別子文字列
が与えられると、サーバは、／ｃｏｎｆｉｇ／ｍａｃｈ
ｉｎｅ／ｉｄｅｎｔｉｆｉｅｒｓ／ｍａｃｈ＿ｕｎｉｑ
ｕｅ＿ｉｄの中で特定のクライアントの情報の場所を見
つけることができる。所与のクライアント・ファミリー
（例えばＳｕｎのＪａｖａＳｔａｔｉｏｎ）に共通の情
報を、プラットフォーム・サブエントリ、例えば／ｃｏ
ｎｆｉｇ／ｍａｃｈｉｎｅ／ｐｌａｔｆｏｒｍ／ＪＤＭ
１の中で見つけることができる。マシン識別子エントリ
は一般に、プラットフォーム・エントリを参照して、共
通情報を共用し、管理を容易にする。特定のクライアン
トが、プラットフォームに追加情報を提供するか、また
はオーバライドするとシステム管理者がみなした場合、
この情報は、そのマシン特定エントリに維持される。最
後に、マシン固有エントリは、１つまたは複数のプロフ
ァイルを参照することができる。プロファイルは、属性
を共有するマシンの追加のグルーピングを考慮する。例
えば、小売状況では、スポーツウェア部門のクライアン
トは全て、宝石部門のクライアントが参照するプロファ
イルとは異なるプロファイルを参照することができる。
マシン・アーキテクチャ（プラットフォーム）はこのプ
ロファイルを指図しないが、システム管理者が決定した
その他の関係がこれを行う。マシン固有エントリ、その
プラットフォーム、およびプロファイルは協力して、ク
ライアントがブートされた後、ユーザがログインする前
にクライアントにダウンロードするサービス、アプリケ
ーションなどを決定する。マシン階層を表す図３８参照

【０２１９】ユーザ ユーザ・カテゴリは、マシンに提供される機能と同様の
機能をユーザに提供する。ユーザは、「ｂｉｌｌ」など
のログイン識別子によって識別される。ユーザ・エント
リは、グループ・エントリを参照することができる。た
だし参照しなくともよい。グループ・エントリは、１人
または複数人のユーザに共通の情報を提供する。グルー
プは、システム管理者によってセットアップされ、維持
される。ユーザ・エントリは、システム管理者の干渉な
しにユーザが属性をカスタマイズすることができる唯一
の場所である。ユーザは、ログイン後に追加のサービス
をロードすること、またはある属性値で、グループ・エ
ントリに定義された属性値をオーバライドすることを指
示することができる。許される場合には、ユーザ属性
で、マシン・エントリ階層から得た属性をオーバライド
することもできる。ユーザ階層を示す図３９を参照。

【０２２０】サーバ・データ・コアレセンス クライアントに最終的にダウンロードされる情報は、１
つまたは複数のサーバのｃｏｎｆｉｇ名前空間の中のさ
まざまなソースに由来する。エントリおよびそれらの属
性、ならびに結果としてロードされたサービスおよびア
プリケーションはクライアントＪＳＤに現れる。データ
の使用順序を課すのはＪＳＤサーバの責任である。一般
に、より特定な情報が、より一般的な情報にオーバライ
ドする。サイト・セキュリティ方針を侵害しない限り、
ユーザ情報はマシン情報に優先する。一般に、マシン特
定情報が、関連プラットフォームまたはプロファイル情
報にオーバライドする。プロファイルが他のプロファイ
ルにオーバライドする方法は、システム管理者によって
決められる。ユーザ特定情報は一般に、ユーザ・エント
リが参照する１つまたは複数のグループに由来する情報
にオーバライドする。この場合も、セキュリティー方針
によって、これのいくつかまたは全てが起きることを防
ぐことができる。同様に、ユーザ起源の情報が、マシン
階層からの情報にオーバライドするようにしてもよい
し、しなくてもよい。それにもかかわらず、マシン・デ
ータとユーザ・データのコアレセンス（ｃｏａｌｅｓｃ
ｅｎｃｅ）がサーバで起こる。その結果は、クライアン
トのｓｏｆｔｗａｒｅ名前空間にダウンロードされる。
クライアント・スキーマは、クライアント上で、全ての
サービスおよびアプリケーションがそれらの構成情報を
見つける機構である。

【０２２１】クライアント／サーバ通信 図４０に、ＪＳＤに持続性を実装するのに使用する高位
の機構を示す。持続性エントリは、持続性マネージャ・
クラスの助けを借りて、持続性記憶域に出し入れされ
る。一般的なクライアントの場合、持続性マネージャ
は、その持続性操作をＩＩＯＰを介してサーバに伝達す
る。サーバは一般に、大容量記憶デバイスとの相互作用
で、持続性を実現する。しかしサーバの持続性マネージ
ャは、ＪＳＤ／ＩＩＯＰプロトコルを使用して他のサー
バと簡単に通信する。あるいは代わりに、ＮＩＳ、ＬＤ
ＡＰ、ＡＣＡＰまたはその他のディレクトリ／命名サー
ビスなどのその他の機構を使用することもできる。複数
の持続性マネージャ・クラスを実装することによって選
択の結合をサポートすることができる。持続性マネージ
ャは、定義された持続性マネージャ・インタフェースを
実装するだけでよい。基礎となる潜在的な実装の数は限
りないが、その場合もクライアント／サーバの相互運用
性を考慮しなければならない。例えば、クライアントの
持続性マネージャが、持続性のためにＡＣＡＰプロトコ
ルを使用するが、ＡＣＡＰサーバが使用できない場合、
たとえいくつかのＪＳＤ／ＩＩＯＰプロトコル・サーバ
が使用できたとしてもそのクライアントにとって何の役
にも立たない。ＪＳＤクライアントに、ＪＳＤ／ＩＩＯ
Ｐプロトコルを実装させることによって、この状況を改
善することができるが、サーバは、使用可能な持続性記
憶手段を実装することができる。持続性の情報をローカ
ル・ディスクに持ち続けるか、ＡＣＡＰクライアントと
して機能するか、または、ローカルＷｉｎｄｏｗｓ Ｎ
Ｔレジストリにアクセスするかをサーバが選択する場
合、それは、クライアントにとって関係の無いことであ
る。

【０２２２】ＪＳＤプロトコル 持続性マネージャ・クラスは、高水準ＪＳＤプロトコル
をサポートするために実装するメソッドを決める。これ
らのメソッドは、合体された（ｃｏａｌｅｓｃｅｄ）サ
ーバ・サブツリーのダウンロード、クライアントが開始
する変更のプッシュバック、クライアント・エントリの
無効化などの操作を定義する。ある意味で、複数のクラ
イアントが共通データを共用すると、キャッシュ・コヒ
ーレンシ・プロトコルが実装される。その最初の実装で
は、クライアントとサーバの間でオブジェクトを前後に
移動させるプロトコルとしてＩＩＯＰが使用される。Ｌ
ＤＡＰ、ＡＣＡＰなどのその他の機構を実装するため
に、この実装のこの部分を将来的に変更することができ
る。モバイル・コンピューティングについては既に述べ
た。クライアントがサーバにアクセスしているか否かに
応じて異なる振舞いをする持続性マネージャ・クラスを
実装することができる。まず、（おそらくはユーザがア
プレットを走らせることによって）サーバから分離され
ることを見越して、クライアントは、オフラインの間に
アクセスする必要がある追加のサービスおよびアプリケ
ーションをダウンロードすることができる。分離後に
は、クライアントによって開始されたｓｏｆｔｗａｒｅ
名前空間への変更をローカル・キャッシュに入れること
ができる。サーバの存在を検出するとクライアントはそ
の変更を、サーバで実施された変更と同期させる。持続
性マネージャ・ベースクラスにこの機能を組み込むの
は、サーバ・システム・クラッシュまたはネットワーク
の中断などの間に、サーバとのコンタクトが失われた場
合のはね返りを見越したものである。

【０２２３】第７章 クラス／インタフェースの要点 この章では、ＪＳＤクライアントＡＰＩの高位の要点に
ついて述べる。キーとなるインタフェースおよびクラス
のメソッド・シグナチャを示し、それらの目的を簡単に
説明する。詳細についてはＪａｖａｄｏｃベースのドキ
ュメンテーションを参照されたい。メソッドの大部分
は、ＳｙｓｔｅｍＤａｔａｂａｓｅＥｘｃｅｐｔｉｏｎ
を送出する。この例外クラスは、ＪＳＤの最上位クラス
である。ＪＳＤのその他の全ての例外は、Ｓｙｓｔｅｍ
ＤａｔａｂａｓｅＥｘｃｅｐｔｉｏｎのサブクラスであ
る。ＪＳＤの例外クラスの階層についてはこの章の「例
外クラス」の項を参照されたい。さらに、メソッド引き
数がイリーガルであるとみなされた場合（例えばヌル・
エントリ参照）には、ｊａｖａ．ｌａｎｇ．Ｉｌｌｅｇ
ａｌＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎを、ＪＳＤの
セキュリティ・マネージャが、メソッド引き数がイリー
ガルであると判定した場合には、ｊａｖａ．ｌａｎｇ．
ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎを送出することが
できる。ＪＳＤのクラスおよびインタフェースは、以下
の４つのヘッデングの下にグループ分けされる。 ・インタフェース ・クラス ・イベント ・例外

【０２２４】インタフェース Ｅｎｔｒｙインタフェース 表１−１ Ｅｎｔｒｙインタフェース メソッド 機能 public String getName(); エントリに関連した名前を返す。 public boolean isDrafted(); エントリがドラフト・エントリである かどうかを指示する。 public boolean isPublished(); エントリが公表エントリであるかどう かを指示する。 public boolean isDeleted(); エントリが削除エントリであるかどう かを指示する。 public boolean isPersistent() throws エントリが持続性である（サーバまた SystemDatabaseException; はローカル記憶デバイスにバックアッ プされている）場合に真を返す。 public long getGenerationNumber() 世代番号を返す。 throws SystemDatabaseException; public Entry getParent() throws エントリの親エントリを返す。 SystemDatabaseException; public Enumeration getChildEntries() エントリの子エントリへの参照を得る throws SystemDatabaseException. のに使用した列挙を返す。 public int getNumberOfChildren() エントリの子エントリの数を返す。 throws SystemDatabaseException. public Manager getManager() throws マネージャ参照を返す。 SystemDatabaseException; public Manager setManager(Manager 匿名のトランザクション・オブジェク mgr) throws SystemDatabaseException; トを使用してマネージャ参照を設定す る。以前のマネージャ参照を返す。 public Manager setManager マネージャ参照を設定する。 (Transaction t, Manager mgr) throws SystemDatabaseException. public void locate(LocateResult lr) ＬｏｃａｔｅＲｅｓｕｌｔを見つけ更 throws SystemDatabaseException; 新する。 public Service assignService(Service エントリにサービスを割り当てる。匿 newService) throws 名のトランザクション・オブジェクト SystemDatabaseException; を使用する。 public Service assignService エントリにサービスを割り当てる。 (Transaction t, Service newService) throws SystemDatabaseException; public Service getAssignedService() エントリに割り当てられたサービスを throws SystemDatabaseException; 取得する。 public boolean isBasename(String 名前が、有効なベース名であるかどう name) throws かを指示する。 SystemDatabaseException; public void insert(Entry childEntry) 参照された子エントリを挿入する。匿 throws SystemDatabaseException; 名のトランザクション・オブジェクト を使用する。 public void insert(Transaction t, 参照された子エントリを挿入する。 Entry childEntry) throws SystemDatabaseException; public void disconnect(Entry 参照された子エントリを分離する。匿 childEntry) throws 名のトランザクション・オブジェクト SystemDatabaseException; を使用する。 public void disconnect(Transaction 参照された子エントリを分離する。 t, Entry childEntry) throws SystemDatabaseException; public void remove(Entry childEntry) 参照された子エントリを削除する。匿 throws SystemDatabaseException; 名のトランザクション・オブジェクト を使用する。 public void remove(Transaction t, 参照された子エントリを削除する。 Entry childEntry) throws SystemDatabaseException; public int getPropertyCount() throws このエントリに関連した追加属性の名 SystemDatabaseException; 前および値のカウントを返す。 public Enumeration これらの属性の列挙子を返す。 getPropertyNames() throws SystemDatabaseException; public boolean hasPropertyWithName エントリが属性名「ｎａｍｅ」を有す (String name) throws る場合に真を返す。 SystemDatabaseException; public Object getPropertyValue 属性名「ｎａｍｅ」を有する属性の値 (String name) throws を取得する。 SystemDatabaseException; public Object addProperty 値「ｖａｌｕｅ」を有する「ｎａｍｅ (String name, Object value) throws 」という名前の属性を追加する。匿名 SystemDatabaseException; のトランザクション・オブジェクトを 使用する。この属性の以前の値を返す 。 public Object addProperty 値「ｖａｌｕｅ」を有する「ｎａｍｅ (Transaction t, String name, Object 」という名前の属性を追加する。この value) throws 属性の以前の値を返す。 SystemDatabaseException; public Object addProperty(String 匿名のトランザクション・オブジェク name) throws トを使用してブール属性を追加する。 SystemDatabaseException; この属性の以前の値を返す。 public Object addProperty ブール属性を追加する。この属性の以 (Transaction t, String name) throws 前の値を返す。 SystemDatabaseException; public Object removeProperty(String 「ｎａｍｅ」という名前の属性を削除 name) throws する。匿名のトランザクション・オブ SystemDatabaseException; ジェクトを使用する。その属性の値を 返す。 public Object removeProperty 「ｎａｍｅ」という名前の属性を削除 (Transaction t, String name) throws する。その属性の値を返す。 SystemDatabaseException; public void lockRead() throws 読み取るエントリをロックする。 SystemDatabaseException; public void unlockRead() throws 読み取るエントリのロックを解除する SystemDatabaseException; 。 public void lockWrite(Transaction t) 書き込むエントリをロックする。 throws SystemDatabaseException; public void unlockWrite(Transaction 書き込むエントリのロックを解除する t) throws SystemDatabaseException; 。 public void reenterWrite(Transaction 書き込むエントリがロックされている t) throws SystemDatabaseException; かどうかを再入する（検証する）。 public void buildPath(Tree tree, 指定されたバッファの中にエントリの StringBuffer buf) throws 絶対パス名を構築する（ｗｒｔ ”ｔ SystemDatabaseException; ｒｅｅ’）。 void printEntry(PrintStream out); デフォルトの記述法でエントリを印刷 する。 void printEntry(PrintStream out, 指定された記述法でエントリを印刷す String prefix, boolean properties, る。 boolean verbose, boolean debug, boolean children, boolean recurse);

【０２２５】Ｔｒｅｅインタフェース 表１−２ Ｔｒｅｅインタフェース メソッド 機能 public Entry getRootEntry(); ツリーのルート・エントリを返す。 public Entry getCurrentEntry(); 指定されたカレント・エントリを返す 。 public boolean setCurrentEntry エントリを、カレント・エントリとし (Entry nextCurrentEntry) throws て指定する。 SystemDatabaseException; public Entry findEntry パス名が与えられたエントリを検索す (String pathName) throws る。 SystemDatabaseException; public Entry newEntry 残りのパスによって識別された親エン (String pathName) throws トリの下に、ベース・パス名を有する SystemDatabaseException; 新しいエントリを作成する。 public Entry newEntry(Entry parent, 新しいエントリを作成し、指定された String name) throws 親エントリの子としてそれを挿入する SystemDatabaseException; 。 public boolean newEntry 指定された親エントリの子としてエン (String parent, Entry child) throws トリを挿入する。 SystemDatabaseException; public Entry newAlias(String 指定されたパス名のエントリを参照す aliasPath, String aliasedEntryPath) る、指定されたパス名の新しいエイリ throws SystemDatabaseException; アスを作成する。そのエイリアスのエ ントリを返す。 public Entry newAlias(String 指定されたエントリを参照する、指定 aliasPath, Entry aliasedEntry) されたパス名の新しいエイリアスを作 throws SystemDatabaseException; 成する。そのエイリアスのエントリを 返す。 public void populateTree 指定されたポピュレーション・オブジ (TreePopulator populator) throws ェクトを使用してツリーをエントリで SystemDatabaseException; 埋める。 public void printTree(boolean 記述的な方法でツリーを印刷する。 verbose); public void recursePrintTree 指定された記述法でツリーを印刷する (Cursor cursor, String prefix, 。 boolean verbose);

【０２２６】ＴｒｅｅＰｏｐｕｌａｔｏｒインタフェー
ス 表１−３ ＴｒｅｅＰｏｐｕｌａｔｏｒインタフェース メソッド 機能 public int getRootEntry(); ルート・エントリへの整数参照を返す 。 public String getEntryName 指定されたエントリの名前を返す。 (int entry) throws SystemDatabaseException; public int getParentEntry(int entry) 指定されたエントリの親エントリを返 throws SystemDatabaseException; す。 public int getFirstChildEntry 指定されたエントリの最初の子エント (int entry) リを返す。 throws SystemDatabaseException; public int getPeerEntry(int entry) 指定されたエントリの次の兄弟エント throws SystemDatabaseException; リを返す。 public int getPropertyNameLength(); 属性名の長さの最大値を返す。 public String getNextProperty(int 以前の属性名が与えられた次の属性名 entry, String prevPropName) throws を返す。 SystemDatabaseException; public int getPropertyValueLength 属性値の長さをバイト数で返す。 (int entry, String propName) throws SystemDatabaseException; public Object getPropertyValue 属性値を返す。 getPropertyValue(int entry, String propName) throws SystemDatabaseException;

【０２２７】Ｍａｎａｇｅｒインタフェース 表１−４ Ｍａｎａｇｅｒインタフェース メソッド 機能 public Entry makeNewEntry(String 名前が与えられた新しいエントリ（ド name) throws ラフト・エントリ）を作成する。 SystemDatabaseException; public String getPropertyPrintString 指定されたエントリの命名された属性 (Entry e, String propName) throws のデコード／フォーマットされたＳｔ SystemDatabaseException; ｒｉｎｇ表現を獲得する。

【０２２８】クラス ＳｙｓｔｅｍＤａｔａｂａｓｅクラス 表１−５ ＳｙｓｔｅｍＤａｔａｂａｓｅクラス メソッドまたはコンストラクタ 機能 public SystemDatabase(String[] システム・データベースを初期化する namespaces, String[] mgrClasses) 。最初の名前空間およびｍａｎａｇｅ throws SystemDatabaseException; ｒクラスを与える。 public static Entry スーパー・ルートのエントリ参照を返 getSuperRootEntry(); す。 public static Tree システム・データベースを定義するツ getSystemDatabase(); リーを返す。

【０２２９】ＳｙｓｔｅｍＥｎｔｒｙクラス Ｅｎｔｒｙインタフェースを実装し、データベースの基
本機能を提供する。機能を拡張するために、Ｓｙｓｔｅ
ｍＥｎｔｒｙクラスのサブクラス、すなわちＰｅｒｓｉ
ｓｔｅｎｔＳｙｓｔｅｍＥｎｔｒｙを設けることができ
る。

【０２３０】Ｔｒａｎｓａｃｔｉｏｎクラス 表１−６ Ｔｒａｎｓａｃｔｉｏｎクラス メソッドまたはコンストラクタ 機能 public Transaction(Entry 指定されたｓｕｂｔｒｅｅＲｏｏｔエ subtreeRoot) ントリによって表された全てのエント リから成る新しい有効トランザクショ ンを構成する。 final public void commit() throws トランザクションをコミットする（全 SystemDatabaseException; てのロックを解除する）。 final public void abort(); トランザクションを打ち切る（全ての ロックをロールバックし解除する）。 final public boolean isValid(); トランザクションが有効か、または無 効かを指示する。

【０２３１】Ｑｕｅｒｙクラス 表１−７ Ｑｕｅｒｙクラス メソッドまたはコンストラクタ 機能 public Query(Entry entry, int 指定された範囲の中の全てのエントリ scope); を突き合わせる、「ｅｎｔｒｙ」をル ートとする問合せを作成する。 public Query(Entry entry, String 指定された範囲の中でコンポーネント name, int scope) 名「ｎａｍｅ」を有するエントリを探 索するための、「ｅｎｔｒｙ」をルー トとする問合せを作成する。 public Query(Entry entry, String[] n 指定された範囲の中で、「ｎａｍｅｓ ames, int scope) 」の中のいずれかと一致するコンポー ネント名を有するエントリを探索する ための、「ｅｎｔｒｙ」をルートとす る問合せを作成する。 public int setSearchScope() この探索の範囲を変更する。 public int getSearchScope() この探索の範囲を取得する。 public String getSearchName() この探索に使用されたエントリ名を返 す。 public Object getSearchValue() この探索に使用されたエントリ値を返 す。 public boolean namesMustMatch() 名前は一致しなければならないか？ public Entry previousMatch() 最後の一致に問合せをリセットする。 public Entry getCurrentMatch() 現在の一致を返す。 public Entry getPreviousMatch() 最後の一致を返す。 public Entry nextMatch() 次の一致を返す。 public boolean hasMoreElements() この探索で別の一致があるか？ public Object nextElement() 次の一致を返す。 final public static int THIS = 0; 探索範囲：自体を探索する。 final public static int PARENT =1; 探索範囲：親エントリを探索する。 final public static int SIBLINGS 探索範囲：エントリの全ての兄弟エン = 2; トリを探索する。 final public static int CHILDREN 探索範囲：エントリの全ての直接の子 = 3; エントリを探索する。 final public static int DESCENDANTS 探索範囲：自体を除くエントリの下の = 4; 全てのエントリを探索する。 final public static int styleIsExact 突合せスタイル：名前が正確に一致し = 0; なければならない。 final public static int 突合せスタイル：名前の最初の文字が styleIsStartsWith =1; 同じであればよい。

【０２３２】ＰｒｏｐｅｒｔｙＱｕｅｒｙクラス Ｑｕｅｒｙクラスを拡張し、エントリの属性名に基づく
探索機能を提供する。 表１−８ ＰｒｏｐｅｒｔｙＱｕｅｒｙクラス メソッドまたはコンストラクタ 機能 public PropertyQuery(Entry entry, 指定された範囲の中で属性名「ｎａｍ String name, int scope) ｅ」を有するエントリを探索するため の、「ｅｎｔｒｙ」をルートとする問 合せを作成する。 public PropertyQuery(Entry entry, 指定された範囲の中で「ｎａｍｅｓ」 String[] names, int scope) の中のいずれかと一致する属性名を有 するエントリを探索するための、「ｅ ｎｔｒｙ」をルートとする問合せを作 成する。

【０２３３】イベント・クラス ＳｙｓｔｅｍＤａｔａｂａｓｅＥｖｅｎｔクラス システム・データベースに関係した全てのイベントのベ
ース・クラス。 表１−９ ＳｙｓｔｅｍＤａｔａｂａｓｅＥｖｅｎｔク
ラス メソッド 機能 なし。タグ・クラスのみ。

【０２３４】ＥｎｔｒｙＥｖｅｎｔクラス ＳｙｓｔｅｍＤａｔａｂａｓｅＥｖｅｎｔを拡張し、全
てのエントリ特定データベース・イベントのベースを表
す。 表１−１０ ＥｎｔｒｙＥｖｅｎｔクラス メソッド 機能 public Entry getEntry(); イベントが関係するエントリの参照を 返す。

【０２３５】ＥｎｔｒｙＩｎｓｅｒｔＥｖｅｎｔクラス ＥｎｔｒｙＥｖｅｎｔを拡張する。公表エントリの挿入
を指示する。 表１−１１ ＥｎｔｒｙＩｎｓｅｒｔＥｖｅｎｔクラス メソッド 機能 public Entry getEntry(); 新しく挿入されたエントリの参照を返 す。

【０２３６】ＥｎｔｒｙＤｉｓｃｏｎｎｅｃｔＥｖｅｎ
ｔクラス ＥｎｔｒｙＥｖｅｎｔを拡張する。公表エントリの分離
を指示する。 表１−１２ ＥｎｔｒｙＤｉｓｃｏｎｎｅｃｔＥｖｅｎｔクラス メソッド 機能 public Entry getEntry(); 分離されたエントリへの参照を返す。 public Entry getAffectedParent(); 前の親エントリへの参照を返す。 ヌルの場合、エントリは分離点ではな く、分離点のエントリの子孫エントリ である。

【０２３７】ＥｎｔｒｙＲｅｍｏｖｅＥｖｅｎｔクラス ＥｎｔｒｙＥｖｅｎｔを拡張する。公表エントリの削除
を指示する。 表１−１３ ＥｎｔｒｙＲｅｍｏｖｅＥｖｅｎｔクラス メソッド 機能 public Entry getEntry(); 削除されたエントリへの参照を返す。 public Entry getAffectedParent(); 前の親エントリへの参照を返す。

【０２３８】ＥｎｔｒｙＰｒｏｐｅｒｔｙＥｖｅｎｔク
ラス ＥｎｔｒｙＥｖｅｎｔを拡張する。挿入を表し、全ての
エントリ属性特定データベース・イベントのベースを表
す。 表１−１４ ＥｎｔｒｙＰｒｏｐｅｒｔｙＥｖｅｎｔクラス メソッド 機能 public Entry getEntry(); 属性イベントが関係するエントリの参 照を返す。 public String getPropertyName(); 影響を受けた属性の名前を返す。

【０２３９】ＥｎｔｒｙＰｒｏｐｅｒｔｙＩｎｓｅｒｔ
Ｅｖｅｎｔクラス ＥｎｔｒｙＰｒｏｐｅｒｔｙＥｖｅｎｔを拡張する。公
表エントリに新しい属性が追加されたことを指示する。 表１−１５ ＥｎｔｒｙＰｒｏｐｅｒｔｙＩｎｓｅｒｔＥｖｅｎｔクラス メソッド 機能 public Entry getEntry(); 新しい属性が追加されたエントリへの 参照を返す。 public String getPropertyName(); 新しい属性の名前を返す。

【０２４０】ＥｎｔｒｙＰｒｏｐｅｒｔｙＲｅｍｏｖｅ
Ｅｖｅｎｔクラス ＥｎｔｒｙＰｒｏｐｅｒｔｙＥｖｅｎｔを拡張する。公
表エントリから属性が削除されたことを指示する。 表１−１６ ＥｎｔｒｙＰｒｏｐｅｒｔｙＲｅｍｏｖｅＥｖｅｎｔクラス メソッド 機能 public Entry getEntry(); 属性が削除されたエントリの参照を返 す。 public String getPropertyName(); 影響を受けた属性の名前を返す。 public Object getPreviousValue(); 削除された属性の以前の値を返す。

【０２４１】ＥｎｔｒｙＰｒｏｐｅｒｔｙＶａｌｕｅＣ
ｈａｎｇｅＥｖｅｎｔクラス ＥｎｔｒｙＰｒｏｐｅｒｔｙＥｖｅｎｔを拡張する。公
表エントリの属性値が変更されたことを指示する。 表１−１７ ＥｎｔｒｙＰｒｏｐｅｒｔｙＶａｌｕｅＣｈａｎｇｅＥｖｅｎｔク ラス メソッド 機能 public Entry getEntry(); 属性値が変更されたエントリの参照を 返す。 public String getPropertyName(); 影響を受けた属性の名前を返す。 public Object getPreviousValue(); 属性の以前の値を返す。

【０２４２】例外クラス ＳｙｓｔｅｍＤａｔａｂａｓｅＥｘｃｅｐｔｉｏｎクラ
ス システム・データベースに関係した全ての例外クラスの
ベース・クラス。 表１−１８ ＳｙｓｔｅｍＤａｔａｂａｓｅＥｘｃｅｐ
ｔｉｏｎクラス メソッド 機能 なし。タグ・クラスのみ。

【０２４３】ＥｎｔｒｙＥｘｃｅｐｔｉｏｎクラス ＳｙｓｔｅｍＤａｔａｂａｓｅＥｘｃｅｐｔｉｏｎを拡
張し、全てのエントリ特定データベース例外クラスのベ
ース・クラスを表す。 表１−１９ ＥｎｔｒｙＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Entry getEntry(); イベントが関係するエントリの参照を 返す。

【０２４４】ＥｎｔｒｙＩｎｖａｌｉｄＳｔａｔｅＥｘ
ｃｅｐｔｉｏｎクラス ＥｎｔｒｙＥｘｃｅｐｔｉｏｎを拡張する。エントリが
期待される状態にないことを指示する。例えば、公表エ
ントリを挿入しようとすると、この例外が送出される。 表１−２０ ＥｎｔｒｙＩｎｖａｌｉｄＳｔａｔｅＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Entry getEntry(); イベントが関係するエントリの参照を 返す。

【０２４５】ＥｎｔｒｙＬｏｃｋＥｘｃｅｐｔｉｏｎク
ラス ＥｎｔｒｙＥｘｃｅｐｔｉｏｎを拡張し、ロックに関係
した全てのエントリ特定データベース例外クラスのベー
ス・クラスを表す。 表１−２１ ＥｎｔｒｙＬｏｃｋＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Entry getEntry(); イベントが関係するエントリの参照を 返す。 SystemDatabaseLock getLock(); イベントが関係するロックへの参照を 返す。

【０２４６】ＥｎｔｒｙＬｏｃｋＳｔａｔｅＥｘｃｅｐ
ｔｉｏｎクラス ＥｎｔｒｙＬｏｃｋＥｘｃｅｐｔｉｏｎを拡張する。エ
ントリ・ロックが期待される状態にないことを指示す
る。 表１−２２ ＥｎｔｒｙＬｏｃｋＳｔａｔｅＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Entry getEntry(); イベントが関係するエントリの参照を 返す。 SystemDatabaseLock getLock(); イベントが関係するロックへの参照を 返す。

【０２４７】ＥｎｔｒｙＴｉｍｅｏｕｔＥｘｃｅｐｔｉ
ｏｎクラス ＥｎｔｒｙＬｏｃｋＥｘｃｅｐｔｉｏｎを拡張する。エ
ントリ・ロック操作がタイムアウトしたことを指示する
（デッドロックの検出）。 表１−２３ ＥｎｔｒｙＴｉｍｅｏｕｔＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Entry getEntry(); イベントが関係するエントリの参照を 返す。 SystemDatabaseLock getLock(); イベントが関係するロックへの参照を 返す。

【０２４８】ＥｎｔｒｙＮａｍｅＥｘｉｓｔｓＥｘｃｅ
ｐｔｉｏｎクラス ＥｎｔｒｙＥｘｃｅｐｔｉｏｎを拡張する。そのエント
リの名前が、特定の親エントリの下にすでに存在するこ
とを指示する。 表１−２４ ＥｎｔｒｙＮａｍｅＥｘｉｓｔｓＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Entry getEntry(); 同一の名前をすでに有するエントリの 参照を返す。

【０２４９】ＥｎｔｒｙＮｏｔＦｏｕｎｄＥｘｃｅｐｔ
ｉｏｎクラス ＥｎｔｒｙＥｘｃｅｐｔｉｏｎを拡張する。そのエント
リ名が存在しないことを指示する。 表１−２５ ＥｎｔｒｙＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Entry getEntry(); パス名のルックアップが最後に成功し たエントリの参照を返す。

【０２５０】ＥｎｔｒｙＰｒｏｐｅｒｔｙＮａｍｅＮｏ
ｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎクラス ＥｎｔｒｙＥｘｃｅｐｔｉｏｎを拡張する。そのエント
リ属性名が存在しないことを指示する。 表１−２６ ＥｎｔｒｙＰｒｏｐｅｒｔｙＮａｍｅＮｏｔＦｏｕｎｄＥｘｃｅｐ ｔｉｏｎクラス メソッド 機能 public Entry getEntry(); この例外が関係するエントリの参照を 返す。 public String getName(); 見つからなかった名前を返す。

【０２５１】ＥｎｔｒｙＰｒｏｐｅｒｔｙＮａｍｅＩｎ
ｖａｌｉｄＥｘｃｅｐｔｉｏｎクラス ＥｎｔｒｙＥｘｃｅｐｔｉｏｎを拡張する。エントリ属
性名が、エントリ・クラスに対して無効であることを示
す。 表１−２７ ＥｎｔｒｙＰｒｏｐｅｒｔｙＮａｍｅＩｎｖａｌｉｄＥｘｃｅｐｔ ｉｏｎクラス メソッド 機能 public Entry getEntry(); この例外が関係するエントリの参照を 返す。 public String getName(); 無効であった名前を返す。

【０２５２】ＴｒａｎｓａｃｔｉｏｎＩｎｖａｌｉｄＥ
ｘｃｅｐｔｉｏｎクラス ＳｙｓｔｅｍＤａｔａｂａｓｅＥｘｃｅｐｔｉｏｎを拡
張する。トランザクションに打切りが実行されたため
に、トランザクション・オブジェクトが無効となり、そ
れ以降、そのオブジェクトを使用することができなくな
ったことを指示する。 表１−２８ ＴｒａｎｓａｃｔｉｏｎＩｎｖａｌｉｄＥｘｃｅｐｔｉｏｎクラス メソッド 機能 public Transaction getTransaction(); イベントが関係するトランザクション の参照を返す。

【図面の簡単な説明】

【図１】 本発明を実施したコンピュータ・システムの
ハードウェア・ブロック図である。

【図２】 図１のコンピュータ・システムのオブジェク
ト指向ソフトウェアを示す図である。

【図３】 割込み源間の関係の例を示す図である。

【図４】 図３の例に対応する割込み源ツリーの一部分
を示す図である。

【図５】 バス割込み源エントリの例を示す図である。

【図６】 割込み名前空間とデバイス名前空間の相互参
照を示す図である。

【図７】 割込み源ツリーのさまざまなレベルとソフト
ウェアとの関係を示す図である。

【図８】 割込みハンドラの同期を示す図である。

【図９】 据置き割込み処理の概念を示す図である。

【図１０】 割込みディスパッチャ、および割込みディ
スパッチャと実行時ソフトウェア、マイクロカーネル・
ソフトウェアとの関係を示す図である。

【図１１】 バス割込みハンドラおよびデバイス割込み
ハンドラを示す図である。

【図１２】 割込み源クラス階層を示す図である。

【図１３】 本発明による、イーサネット読取り割込み
動作の性能向上を示す図である。

【図１４】 ＪＳＤの構成を示す図である。

【図１５】 ＪＳＤのポピュレーションと使用方法を示
す図である。

【図１６】 標準名前空間の最上位レベルを示す図であ
る。

【図１７】 ｓｏｆｕｔｏｗａｒｅ名前空間のサブスキ
ーマを示す図である。

【図１８】 ａｐｐｌｉｃａｔｉｏｎ階層を示す図であ
る。

【図１９】 ｓｙｔｅｍ階層を示す図である。

【図２０】 Ｓｅｒｖｉｃｅ階層を示す図である。

【図２１】 Ｐｕｂｌｉｃ階層を示す図である。

【図２２】 バス−デバイス・トポロジを示す図であ
る。

【図２３】 インターフェース・トポロジを示す図であ
る。

【図２４】 Ｉｎｔｅｒｆａｃｅ名前空間の割り当てを
示す図である。

【図２５】 エントリの状態遷移を示す図である。

【図２６】 サブツリーの挿入を示す図である。

【図２７】 サブツリーの分離を示す図である。

【図２８】 サブツリーの除去の最終段階を示す図であ
る。

【図２９】 ＪＳＤ絵弁とのクラス階層を示す図であ
る。

【図３０】 サブツリーの定義を示す図である。

【図３１】 相互作用を示す図である。

【図３２】 トランザクションとロック例外を示す図で
ある。

【図３３】 分散トランザクション・モデルを示す図で
ある。

【図３４】 ＪＳＤ例外階層を示す図である。

【図３５】 ナビゲーションの例を示す図である。

【図３６】 ナビゲーションの例を示す図である。

【図３７】 ｃｏｎｆｉｇ名前空間のサブスキーマを示
す図である。

【図３８】 マシン階層を示す図である。

【図３９】 ユーザ階層を示す図である。

【図４０】 ＪＳＤのクライアント／サーバ編成を示す
図である。

【符号の説明】

３２ プラットフォーム・インデペンデント層 ３４ プラットフォーム・デペンデント ３６ アプリケーション・プログラム層 ３８ 実行時システム ４０ Ｊａｖａ仮想マシン ４２ デバイス・インタフェース ４４ バス・マネージャ ４６ デバイスマネージャ ４８ 各種マネージャ ５０ デバイス・ドライバ ５１ プラットフォーム・インデペンデント・バス・マ
ネージャ ５２ プラットフォーム・インデペンデント・メモリ ５４ システム・ローダ ５６ システム・データベース ５８ 追加機能 ６０ プラットフォーム・インタフェース ６１ ＯＳネイティブ層 ６２ マイクロカーネル ６４ ブート・インタフェース ６６ 仮想マシン・システム機能ライブラリ・ハンドラ ６８ 割込みクラス ７０ ダイレクト・メモリ・アクセス（ＤＭＡ）クラス ７２ メモリ・クラス ７４ カーネル機能 ７６ デバッグ機能 ７８ 割込みネイティブ・メソッド ８０ ＤＭＡネイティブ・メソッド ８２ メモリ・ネイティブ・メソッド

フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ. (72)発明者 トーマス・サウルパウグ アメリカ合衆国・95120・カリフォルニア 州・サン ホゼ・ブレート ハート ドラ イブ・6938 (72)発明者 グレゴリー・ケイ・スローター アメリカ合衆国・94306・カリフォルニア 州・パロ アルト・エマーソン ストリー ト・3326 (72)発明者 シャオヤン・ツェン アメリカ合衆国・94555・カリフォルニア 州・フレモント・ゴルビン コモン・5454

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ＣＰＵと、マイクロカーネルを含むメモ
   リと、割込みを発生させる源を構成する複数のデバイス
   と、それぞれが、少なくとも１つの源に関連した複数の
   ドライバと、システム・データベースとを有するオブジ
   ェクト指向コンピュータ・システムにおける割込みを処
   理する方法において、 それぞれのデバイスに対するデバイス・エントリをデー
   タベース内に作成する段階と、 割込み源の１つを表すオブジェクトをそれぞれが含む複
   数の割込み源ツリー・エントリを含む割込み源ツリーを
   データベース内に作成する段階と、 対応する割込み源ツリー・エントリの中のそれぞれの割
   込み源に関連した割込み管理ソフトウェア・コンポーネ
   ントをインストールするメソッドを含む割込み登録イン
   タフェースを実装する段階と、 それぞれのデバイス・エントリを、対応する１つの割込
   み源ツリー・エントリと相互参照させる段階と、 単一の割込みディスパッチャを実行させ、割込みディス
   パッチャにデバイスを識別させることによって、デバイ
   スが発生させた割込みに応答する段階と、 割込みディスパッチャによって呼び出された、識別され
   たデバイスに対応するハンドラで割込みを処理する段階
   とを含むことを特徴とする方法。
2. 【請求項２】 ＣＰＵと、割込みを発生させることがで
   きる割込み源を構成する複数のデバイスと、それぞれ
   が、少なくとも１つの割込み源に関連した複数のドライ
   バとを有するオブジェクト指向コンピュータ・システム
   における割込みを処理する装置において、 それぞれが割込み源に関連したドライバによって供給さ
   れる複数の割込み管理ソフトウェア・コンポーネント
   と、 それぞれのデバイスに対するデバイス・エントリ、およ
   び、割込み源の１つを表すオブジェクトをそれぞれが含
   み、対応するデバイス・エントリと相互参照し、少なく
   とも１つの割込み管理ソフトウェア・コンポーネントへ
   の参照をそれぞれが含む複数の割込み源ツリー・エント
   リを含む割込み源ツリーを有するデータベースを含むメ
   モリと、 識別されたデバイスに対応する割込み源ツリー・エント
   リによって指定された対応する割込み管理ソフトウェア
   ・コンポーネントを実行することによって、ＣＰＵによ
   って識別された割込みに応答する単一の割込みディスパ
   ッチャとを含むことを特徴とするデバイス。
3. 【請求項３】 ＣＰＵと、メモリと、割込みを発生させ
   ることができる割込み源を構成する複数のデバイスとを
   有するオブジェクト指向コンピュータ・システムにおけ
   る割込みを処理するための機能を与える命令を含むコン
   ピュータ可読媒体において、割込みの処理が、 メモリ内にデータベースを作成する段階と、 それぞれのデバイスに対するデバイス・エントリをデー
   タベース内に作成する段階と、 割込み源の１つを表すオブジェクトをそれぞれが含む複
   数の割込み源ツリー・エントリを含む割込み源ツリーを
   データベース内に作成する段階と、 対応する割込み源ツリー・エントリの中のそれぞれの割
   込み源に関連した割込み管理ソフトウェア・コンポーネ
   ントをインストールするメソッドを含む割込み登録イン
   タフェースを実装する段階と、 それぞれのデバイス・エントリを、対応する１つの割込
   み源ツリー・エントリと相互参照させる段階と、 単一の割込みディスパッチャを実行させ、割込みディス
   パッチャにデバイスを識別させることによって、デバイ
   スが発生させた割込みに応答する段階と、 識別されたデバイスに対応するハンドラを割込みディス
   パッチャで呼び出すことによって割込みを処理する段階
   とによって実施されることを特徴とするコンピュータ可
   読媒体。
4. 【請求項４】 ＣＰＵと、メモリと、割込みを発生させ
   ることができる割込み源を構成する複数のデバイスとを
   有するオブジェクト指向コンピュータ・システムにおけ
   る割込みを処理するための機能を与える命令を含む搬送
   波上のコンピュータ・データ信号において、割込みの処
   理が、 メモリ内にデータベースを作成する段階と、 それぞれのデバイスに対するデバイス・エントリをデー
   タベース内に作成する段階と、 割込み源の１つを表すオブジェクトをそれぞれが含む複
   数の割込み源ツリー・エントリを含む割込み源ツリーを
   データベース内に作成する段階と、 対応する割込み源ツリー・エントリの中のそれぞれの割
   込み源に関連した割込み管理ソフトウェア・コンポーネ
   ントをインストールするメソッドを含む割込み登録イン
   タフェースを実装する段階と、 それぞれのデバイス・エントリを、対応する１つの割込
   み源ツリー・エントリと相互参照させる段階と、 単一の割込みディスパッチャを実行させ、割込みディス
   パッチャにデバイスを識別させることによって、デバイ
   スが発生させた割込みに応答する段階と、 識別されたデバイスに対応するハンドラを割込みディス
   パッチャで呼び出すことによって割込みを処理する段階
   とによって実施されることを特徴とするコンピュータ・
   データ信号。