JP2006107449A - エンティティドメイン - Google Patents

Abstract

【課題】 機能を、コスト高で複雑なサービスとコンポーネントとの原子的結合や、サービスインスタンスの複製を必要とせず、共通のコンテキストでこの機能を共有するコンポーネントの集合に公開する効率的な方法を提供すること。
【解決手段】 エンティティドメイン・フレームワークは、階層状に配列される１以上のエンティティドメインを含む。各エンティティドメインは、さらに１以上のコンポーネントを互いに階層状に分類する。各エンティティドメインは、エンティティドメイン内のコンポーネントに方針を提供する１以上のサービスを含む。複合機能がフレームワークを互いに結合して、さらにバスのような機構を提供し、それによってエンティティは、ドメインが要求を満たすと分かるまでサービス要求を上位の階層へ登らせることができる。
【選択図】 図１

Description

本発明は、機械読み取り可能なコードコンポーネントを管理するための改良型ストラテジーに関係する。

アプリケーションは、コードコンポーネントのコレクションを使ってそれらの規定されたタスクを実行できる。例えばオブジェクト指向プログラミングの場合、アプリケーションは、そのソースコード内に、定義されたタスクを実行する機能を提供するためにランタイムで使用できる様々なクラスを割り当てることができる。つまり、ランタイムで、コンピュータは、これらクラスを例示して、特定のオブジェクト（「インスタンス」ともいう）を提供する。上記オブジェクトは、コンピュータのメモリの割り当てられる部分に記憶する。上記オブジェクトがそのそれぞれの目的を果たし、もはや必要なくなると、コンピュータはいわゆるガーベッジコレクション機能を実行してメモリから上記オブジェクトを削除し、さらに別のオブジェクトを作成、記憶するための余地を提供する。

アプリケーションのランタイムを実行中のある時点で、コンピュータのメモリは、ランタイムコードコンポーネントの大きなコレクションを記憶することが予想される。上記コードコンポーネントは、それらの規定されたタスクを行うために互いに対話できなければならない。このために、アプリケーションは上記コードコンポーネントをまとめて「ワイヤリング」するための機能を提供する。ワイヤリングは、コンポーネントが他のコンポーネントを参照し、コンポーネント間で情報を交換してその割り当てタスクを行えるようにする。

アプリケーションは、典型的にはコンポーネント間の前記ワイヤリングリンクを作成し、管理し、および切断するとき、あるプロトコルを適用する。外部では、このようなプロトコルが、エンドユーザーによる消費のためのユーザー・インターフェース・プレゼンテーションの論理フローとなる。しかし、内部では、プロトコルは本質的に非構造コンポーネントの相互依存の複雑な格子を生成する。

コードコンポーネントのインスタンスを管理するための従来の技術から多数の問題が生じる。例えば、コード開発者は、アプリケーションの内部のランタイム動作を理解するのが非常に難しいであろう。このため開発者はアプリケーションを事前にテストして潜在的なソフトウェアのエラーを発見できず、また開発者は検出されたエラーの発生源をうまく発見できない。一般に、ランタイムで現れるソフトウェアのエラー（例えば、コンパイル時と違い）は、多くの場合潜在的なもので、アプリケーションの実行中にある条件が存在する場合にのみ発生する。従来のアプローチでは、このためプログラムを消費者に出荷する前に、上記エラーを発見するのが難しい。他の事例では、アプリケーションはエラーのないようにそのサービスを提供するが、様々な問題のために次善策としてそのようにしている（つまり、必要以上にメモリを多く使っているか、又は必要以上に多くの時間をかける）。

従来のガーベッジコレクション技術からは、ある具体的な困ったエラー源が生じる。上記従来の技術は、オブジェクトを指す参照リンクのトラックを維持してオブジェクトがもう必要ないか否かを判断する。リンクの数がゼロになったら、ガーベッジコレクション機能がオブジェクトを処分する。この技術は、数多くの参照リンクの正確なカウントを維持しなければならないため、複雑な計算の需要を強いることがある。この複雑さのために、この計算タスクはよくエラーの発生源となる。一般的なエラーは、オブジェクトがもはや用途をもたないが、インスタンスがなおもオブジェクトへの参照リンクを維持するときに生じる。これはオブジェクトを削除すべき時にもオブジェクトを生かしておき、それによって一種の「ゾンビ」インスタンスを作り出す効果をもつ。言うまでもないが、この種のエラーは、メモリの無駄使い（例えば、「リソース漏れ」）からプログラムのクラッシュまで、様々な問題を引き起こすことがある。従来のストラテジーは上記種類の問題の解決のために十分な装備がなされていない。つまり、上記ストラテジーは、コード開発者がよく理解できていないランタイム時のインスタンスの非構造格子に依存するため、格子内に収集される前記「ゾンビ」インスタンスの発生を検出するのが難しくなる。

また、従来の方法を使用すると、開発者は、ランタイム時にコンポーネントのグループに一定の機能を効率よく提供するコードを書き込めない。例えば、開発者は、様々なコンポーネントにある機能を提供しようとするとき、様々なパラダイムを使用してこの機能が必要なコンポーネントにこの機能を有するインスタンスを「ワイヤリング」する。しかし、個々のコンポーネントにサービスを原子的な結合（ａｔｏｍｉｃ ｃｏｕｐｌｉｎｇ）するのは、これら個別のリンクを記述する参照情報を記憶する必要があるため、コスト高である。また、本発明者が認めるように、周知のアプローチは、同じ機能に依存する、そのため共通の「コンテキスト」を共有するコンポーネントがそのような機能に効率よくアクセスできるようにする適切な機構を提供できていない。コンテキストを共有するための従来の技術（広域変数を使用するなど）は、比較的粗い基準での（例えばプロセスやスレッドレベルで）共有を提供するため、この問題の解決策としては不十分である。

少なくとも前記説明および例示した理由により、ランタイム時のコードコンポーネントを管理するために、上記特定した問題の１以上の発生をなくす又は減らすより効率的なストラテジーが必要である。

ある例示的な実装に従い、ランタイム時のコンポーネントのコレクションを含む機械読み取り可能コードを実行するための方法を説明する。方法は、エンティティドメインが少なくとも１つの規定の方針（以下、略して、単数の「規定の方針」という）に従う階層構造のエンティティドメインに、少なくとも１つのコードコンポーネントを分類するための工程と、エンティティドメインの方針に従ってコードコンポーネントを管理するための工程とからなる。

別の例示的な態様に従い、分類の工程は、各方針に従う複数のエンティティドメインを提供するための工程からなる。

別の例示的な態様に従い、複数のエンティティドメインは親子関係でまとめてリンクさせる。

別の例示的な態様に従い、エンティティドメインの各々は、複数のエンティティドメインを階層的なエンティティドメインのフレームワークに結合する各複合機能を提供する。

別の例示的な態様に従い、複数のエンティティドメインにより提供される複合機能は集合的に、エンティティがエンティティドメイン・フレームワークを通して要求を送る結合機構を定義する。

別の例示的な態様に従い、あるエンティティドメイン内で行われた要求は、（ａ）あるエンティティドメインが要求を満たすことができるか否かを判別し、満たせるならあるエンティティドメインの要求を処理し、（ｂ）あるエンティティドメインが要求を満たせないなら、あるエンティティドメインの親エンティティドメインが要求を満たせるか否かを判別し、満たせるなら親エンティティドメインの要求を処理し、（ｃ）親エンティティドメインが要求を満たせないなら、要求が満たされるまで、又は要求が満たせないと判別されるまで（ｂ）の操作を繰り返すことによって処理する。

別の例示的な態様に従い、エンティティドメインが提供する前述の方針は、前述の少なくとも１つのコンポーネントの有効期間の管理に関係し、その管理する工程が、前述の少なくとも１つのコンポーネントの確定的な停止を有効期間管理方針に基づいて統制する工程からなる。

別の例示的な態様に従い、有効期間管理方針に従うエンティティドメインの停止のための工程は、エンティティドメインに含まれるあらゆるネスト状に内包された有効期間ドメインの反復的停止を調整するための工程と、事前に通知を受け取るよう登録されていた少なくとも１つのコンポーネントに停止の通知を提供するための工程と、エンティティドメイン外のオブジェクトからの参照リンクをエンティティドメインに切断するための工程とからなる。

別の例示的な態様に従い、エンティティドメインが提供する前述の方針はエラー処理管理に関係し、管理のための工程が前述のエンティティドメインに関連するエラーの系統的処理をエラー処理管理方針に基づいて統制するための工程からなる。

別の例示的な態様に従い、エンティティドメインは少なくとも１つの他のエンクロージングエンティティドメイン内の内包エンティティドメインであり、管理する工程が、内包エンティティドメインがエラー処理タスクを満足に処理できない場合、前述の少なくとも１つのエンクロージングエンティティドメインにエラー処理タスクを留保するための工程からなる。

補足的な例示の実装を以下に説明する。

以下の説明は、コンポーネントをエンティティドメイン・フレームワークに分類するための例示的なストラテジーと、このフレームワークを使用してコンポーネントを管理するための例示的なストラテジーを述べる。エンティティドメイン・フレームワークは、コンポーネントをエンティティドメインの階層構造に編成できる。各エンティティドメインは、１以上の基本コンポーネントと複合機能を含むことができる。複合機能は基本コンポーネントをまとめて１つのエンティティドメイン内に分類する。エンティティドメイン・フレームワークはまた、各エンティティドメインの複合機能をまとめて結合し、エンティティドメインの階層構造を作成する。

各エンティティドメインは１以上のサービスを提供できる。一般的に、エンティティは直接エンティティドメイン・フレームワークと対話することはできない。エンティティドメイン・フレームワーク内のエンティティは検索機能を使ってサービスにアクセスできる。検索機能は、各エンティティドメインが要求されるサービスを提供できるか否かを順次判別しながら、階層を上方へ移動することによってサービスにアクセスする。

ある例示的なアプリケーションでは、有効期間管理サービスをエンティティドメインに適用して、それによって有効期間ドメインを確立する。有効期間のサービスは、有効期間ドメイン内のエンティティが停止時に削除されるような方法で統制する。各有効期間ドメインは、有効期間のサービスを実装する有効期間ディレクタを含む。また、各有効期間ドメインは、有効期間オーナーが直接管理できる。有効期間ドメインは他の有効期間ドメインにネストできる。有効期間ディレクタは、一番深くネストされた内包有効期間ドメインから始めて、その内包有効期間ドメインを停止することによって、そのエンクロージング有効期間ドメインの停止を調整する。有効期間ディレクタはまた、事前に停止通知を受け取るよう登録されている全てのコンポーネント（以下「登録者コンポーネント」という）に停止通知を発行する。１種の登録者コンポーネントはリソース・マネージャーであり、これは名前が示すとおり、ある種のリソース（例えば、データベース・リソースなど）を管理する役割を果たす。オーナーは停止操作を開始する目的を果たす。オーナーはまた、有効期間ドメインを指す有効期間ドメイン外のオブジェクトからリンクを張る役割を果たす。

別の例示的なアプリケーションでは、エラー管理サービスをエンティティドメインに適用して、それによってエラー処理・ドメインを確立する。各エラー処理・ドメインは、エラー処理サービスを実装するエラー処理・ディレクタを含む。有効期間ドメインと同様、エンティティドメイン・フレームワークは内包エラー処理・ドメインを提供できる。内包エラー処理・ディレクタは、そのドメイン内で検出したエラーを、そのローカル・エラー処理・ドメイン内のサービスを使って、エラーをローカルに処理できるか否かを判別することによって処理できる。これが行えない場合、エラー処理・ディレクタはエラーを処理するジョブを、エラーをきちんと処理できるエンクロージングエラー処理・ドメインに先送りし、もしできない場合、エラーはそれ自体のエンクロージングエラー処理・ドメインに移す。エラーをきちんと処理できるエラー処理・ドメインは、アプリケーションの一部（又は全部）を停止するなど、あらゆる修正措置を行うことができる。

エンティティドメイン・フレームワークは多数の利点をもつ。ある利点によれば、エンティティドメインの設計から、コード開発者はランタイム時のアプリケーションに何が起こっているのかをよりよく理解できる。このため、コード開発者はアプリケーションをより簡単にテストでき、検出したエラーの原因をより簡単に発見できる。そのためこの特徴は以前よりエラーの少ないコードを作成できる可能性がある。

別の利点によると、エンティティドメインの設計は、アプリケーションの一部を停止するためのより信頼性のある技術を提供する。つまり、本明細書で説明する（例えば、オーナーの通知と合わせたネストされた停止に関わる）技術は、停止時に体系的かつ予測的にコンポーネントを解放するための系統的プロトコルを提供する。この技術はまた、停止することになるコンポーネントへの参照を削除するのがより確実になる。このことは、背景技術の部分で説明した周知の技術が、様々な従来のガーベッジコレクションプロトコルを使用するのとは対照的である。上記技術は本明細書で説明するエンティティドメインの構造を活かしておらず、そのため停止時に系統的ではない方法でコンポーネントを解放したり、又はコンポーネントを全く解放しない可能性がある。このため、コンポーネントが不適切に生きたままになり、それによって「ゾンビ」コンポーネントが生じる。

別の利点によると、本明細書で説明する停止機構は、一般的にシステム内の多様な設計空間に適用できる適切な停止プロトコルを提供する。このことは、特定の各設計空間に狭く機能するようカスタム設計される周知の停止プロトコルとは対照的である。

別の利点によると、当該設計は、方針をこの方針を利用する（およびそのため同じ「コンテキスト」を共有するアプリケーション内の各コンポーネントグループに受けさせるための構造的かつ効率的な機構を提供する。つまり、検索機能を通し、エンティティドメイン内のコンポーネントはドメインに共通して利用できるようにしたサービスを利用できる。このことはコンポーネント間の複雑なピア・ツー・ピアの非構造リンケージの量を減らすのに役立てられる。さらに、当該設計には、コンポーネントをエンティティドメイン・フレームワークの他の側面と直接対話させないカプセル化機構を含む。

さらに他の利点も、以下の説明を読めば当業者には明らかであろう。

用語に関して、「コンポーネント」という用語は規定のタスクを行うよう構成されたオブジェクトをいう。以下の説明で最も一般的に想起される状況では、コンポーネントは、オブジェクト指向のプログラミングパラダイムの中のオブジェクト（又はインスタンス）である。さらに具体的な例は、マイクロソフト社の．ＮＥＴプログラミング環境（ワシントン州レドモンドのマイクロソフト・コーポレーションが提供）などのバーチャルプログラミング環境の状況であげられる。．ＮＥＴプログラミング環境は編集した中間コードを作ることによって機能し、そのため共通言語ランタイム（ＣＬＲ）機能のサービスを使ってランタイム時に実行する。しかし、これら例は単なる例示的な実例である。本明細書で説明する原理は、あらゆる技術的なプラットフォームの状況におけるあらゆるプログラミングパラダイムに適用できる。

本明細書は以下の項目を含む。Ａ項では例示的なエンティティドメイン・フレームワークを説明する。Ｂ項では、エンティティドメイン・フレームワークに適用できる例示的なサービスを説明する。Ｃ項では、エンティティドメイン・フレームワークの操作のある面を説明する例示的な一連のフローチャートを説明する。最後にＤ項では、エンティティドメイン・フレームワークを実装するための例示的なコンピュータ環境を説明する。

（Ａ．例示的なシステム）
一般的に、本明細書で説明する機能はいずれも、ソフトウェア、ファームウェア（例えば、固定論理回路）、手動処理、又はこれら実装の組合せを使用して実装できる。本明細書で使用する「モジュール」、「コンポーネント」、「機能」、および「論理」という用語は一般的にソフトウェア、ファームウェア、又はソフトウェアとファームウェアの組合せを表す。ソフトウェア実装の場合、「モジュール」、「コンポーネント」、「機能」、又は「論理」という用語は、一又は複数の処理装置（例えば、一又は複数のＣＰＵ）で実行したときに指定のタスクを行うプログラムコードを意味する。プログラムコードは１以上の固定および／又は取り外し可能なコンピュータ読み取り可能記憶装置に記憶できる。メモリは１サイト又は分散して複数のサイトに設けることができる。

（Ａ．１．エンティティドメイン・フレームワークの概要）
図１は、エンティティドメイン・フレームワーク１００に入れるコンポーネントの例示的な階層編成を示す。この編成はランタイム時に現れる。ランタイムとは、アプリケーションプログラム（略して「アプリケーション」という）を実行するときのプログラミングコンポーネントのインスタンス化をいう。例えば、オブジェクト指向プログラミングパラダイムの非制限的な例の場合、ランタイムはクラスのコレクションから必要なオブジェクトを生成し、これらオブジェクトをメモリヒープに記憶し、さらに必要なくなったときにガーベッジコレクション機能を使ってこれらオブジェクトを削除することを伴うことができる。この場合、編成はアプリケーションを実行しているときのメモリ内のオブジェクトの関係で現れる。マイクロソフト社の．ＮＥＴプログラミング環境におけるエンティティドメイン・フレームワーク１００のある例示的な実装に関し、詳細を説明する例を本明細書で提示する。しかし、前述したように、これら実装は例示的なものであり、限定的なものではない。「コンポーネント」という用語は、あらゆるプログラミングパラダイムおよび技術的なプラットフォームにおけるあらゆるコードの単位をいう。

コンポーネントとは「エンティティコンポーネント」として表される。この用語を本明細書で使用するとき、「エンティティ」という修飾語は、コンポーネントがエンティティドメイン・フレームワーク１００のメンバーの役目を果たせるある規則（以下に説明する）にコンポーネントが適合することを意味する。例えばある場合には、適切な結合機構（図示せず）により、エンティティコンポーネントは非エンティティコンポーネント１０２と対話できる。大まかに言うと、非エンティティコンポーネント１０２とは、エンティティコンポーネントが従うのと同じ規則を受けないコンポーネントである。

一般的に、エンティティコンポーネントはあらゆる種類のアプリケーションの様々な面を実装する。例えば、オブジェクト指向のパラダイムでは、エンティティコンポーネントはクラスの個々のオブジェクト（インスタンス）に対応でき、個々のオブジェクトはアプリケーション内の様々なタスクを行うための様々な方法や関連特性をもつ。ユーザー・インターフェース（ＵＩ）プレゼンテーションを提供するアプリケーションの具体的な事例では、個々のコンポーネントはＵＩプレゼンテーションの様々な特徴を提供することができる。在庫管理アプリケーションでは、個々のコンポーネントはプログラムの会計機能の様々な特徴を提供できる、等々。これらはエンティティドメイン・フレームワーク１００を適用できる膨大な数のアプリケーションの単なる例示的で非制限的な例である。

エンティティドメイン・フレームワーク１００は階層構造をもつ。つまり、フレームワーク１００のエンティティコンポーネントは、親子関係（およびピア・ツー・ピア関係）で他のエンティティコンポーネントに結合される。この編成を実装するために、エンティティフレームワーク１００は２種類のエンティティコンポーネント（略して、以下単に「コンポーネント」という）、基本コンポーネントと複合コンポーネントを含む。基本コンポーネントとは、子がないコンポーネントをいう。基本コンポーネントはアプリケーションの動作の面を実装する。複合コンポーネントは複数のメンバーを含むことのできるコンポーネントをいう。そのため複合コンポーネントは、基本コンポーネントと他の複合コンポーネントの両方を含むエンティティコンポーネントのグループを含むことができる。複合コンポーネントは、グループとして機能させることのできるいわゆる複合機能を含む。「Ａ」、「Ｂ」、「Ｃ」のメンバーを有するコンポーネントのグループ「Ｘ」を考えてみる。グループを複合というとき、この用語を本明細書で使用する場合、例えばその個々のメンバー（Ａ、Ｂ、およびＣ）を無条件に数えることにより、グループの複合体の性質をいう。このグループが提供する複合機能をいうとき、その状態がグループＸとして想起され、具体的にはグループとして機能させ、エンティティドメインの階層内の他のグループと対話させることのできる機能を含む。

図１に基本コンポーネントと複合コンポーネントのある例示的で非制限的な編成を示す（すなわち複合機能を含む）。つまり、複合機能１０４は、例示的な基本コンポーネント１０６および１０８など、第１レベルの複合分類を定義する。この第１レベルの複合分類は他の複合機能１１０も含み、これが第２レベルの複合分類を定義する。第２レベルの複合分類は例示的な基本コンポーネント１１２および１１４を含む。第２レベルの複合分類は他の複合機能１１６も含み、さらに第３レベルの複合分類を定義する。第３レベルの複合分類は基本コンポーネント１１８および１２０、さらに複合機能１２２を含む。図１はより包括的なエンティティフレームワーク１００のほんの小さな断片を表すにすぎない。例えば、最上位レベルの複合機能１０４はさらに高次のレベル（図示せず）を結合でき、第３レベルの複合機能１２２はさらに低次レベル（図示せず）に結合できる。「高次」という用語はさらにエンクロージングドメイン（たとえば親と祖先レベル）を簡略化した比喩的な表現であり、また「低次」という用語はさらに内包ドメイン（例えば、子のレベル）を簡略化した比喩的な表現である。厳密に言うと、プログラミング環境は「上下」の区別はしない。

実際の例示的な実装では、最上位レベルのコンポーネント分類は、アプリケーション全体の最も要約した表現に対応するであろう。この最上位レベルは親をもたないルートの複合機能（図示せず）を表すことができる。最下位レベルは、個人ユーザー・インターフェース制御など、アプリケーション内の比較的細かい詳細に対応する。これらの例は単なる例示的なものである。さらに、図１は、１連鎖の内包された複合機能（１０４、１１０、１１６、１２２）で定義される階層を示す。ただし、他のエンティティドメイン・フレームワークは複数の連鎖の内包された複合機能を含むことがある。例えば、別のエンティティドメイン・フレームワーク（図示せず）は、前記コンポーネントの比較的複雑な階層を定義する複合機能の複数のブランチを含むことができる。この場合、エンティティドメイン・フレームワークは１以上の上位コンポーネントを共有するピアコンポーネントを含むことができるが、それ以外は互いにある種の傍系又はグラフ状の関係をもつ。ここでの傍系又はグラフ状の関係とは、親子関係以外のあらゆる種類の関係を意味する（ツリー状の関係を定義する）。

複合分類（複合機能で表す）は個々のいわゆるエンティティドメインを定義する。例えば、複合機能１０４は第１レベルのエンティティドメイン１２４（Ａ）を定義する。複合機能１１０は第２レベルのエンティティドメイン１２６（Ｂ）を定義する。複合機能１１６は第３レベルのエンティティドメイン１２８（Ｃ）を定義する。図形的に示した点線の境界線のボックスはこれら３つの個々のエンティティドメインを意味する。前述したように、エンティティドメイン・フレームワーク１００は、より包括的な階層木のほんの断片を表す。このように、エンティティドメイン・フレームワーク１００は図１に図示するよりも多くのエンティティドメインを含むことができる。

ある例示的で非制限的な例を提供するために、エンティティドメイン１２４はユーザー・インターフェースのウィンドウ形式の表示に対応する。エンティティドメイン１２６はそのウィンドウ形式の表示内のウィンドウ形式の表示内のスクロールバー機能に対応するであろう。エンティティドメイン１２８はスクロールバーの中央にあるスクロール可能な指押しボタンなど、スクロールバー機能のある具体的なコンポーネントに対応するであろう。最上位レベルのエンティティドメイン（図示せず）はアプリケーション全体に対応する。

エンティティドメインのコンポーネントの分類は、あらゆる種類の共有方針に従う。大まかに言うと、方針はエンティティドメイン内のメンバーに集合的に適用する１以上の規則を規定する。前述したように、ある例示的な方針はエンティティドメイン内のコンポーネントの有効期間管理に属する。有効期間管理とは、エンティティドメイン内のコンポーネントの削除を統制する規則をいう。別の例示的な方針はエラー処理管理に属するであろう。エラー処理とは、検出したエラーをエンティティドメインがどのように処理するかを統制する規則をいう。これらの方針はエンティティドメインに適用できる多様な記録の単なる例示的なものである。Ｂ項（以下）に、有効期間ドメインとエラー処理・ドメインの例示的な実装に関する詳細な情報を述べる。

エンティティドメインは、１以上のサービスによって前述の方針を提供する。例えば、第１レベルのエンティティドメイン１２４はサービスのコレクション１３０を提供できる。第２レベルのエンティティドメイン１２６はサービスの別のコレクション１３２を提供できる。第３レベルのエンティティドメイン１２８はサービス１３４の別のコレクションを提供できる。（代わりに、１以上のエンティティドメインは一定のサービスを省略できる）。図１の具体的な例では、サービス（１３０、１３２、１３４）は階層的にネストされて、第１レベルのエンティティドメイン１２４のサービス１３０は第２レベルのエンティティドメイン１２６と第３レベルのエンティティドメイン１２８に利用でき、第２レベルのエンティティドメイン１２６のサービス１３２はオプションで第３レベルのエンティティドメイン１２８に利用できる。例えばエラー処理サービスの場合を考えてみる。第１レベルのエンティティドメイン１２４はあるエンティティドメイン（１２４、１２６、１２８）内で検出された一定のクラスのエラーに対応するために、全ての状況に対応できる一般的なエラーハンドラーを提供でき、一方より深くネストされた他のエンティティドメイン（例えば、１２６、１２８）は、各エンティティドメイン（１２６、１２８）内で発生するある種類のエラーにより厳密に合わせたエラーハンドラーを提供できる。第３レベルのエンティティドメイン１２８のメンバーであるエンティティでエラーが検出されたと仮定する。エンティティドメイン・フレームワーク１００はこのエラーを第３レベルのエンティティドメイン１２８が提供するローカルサービス１３４を使用して対応しようとする。しかし、これらのサービスがエラーに対応するのに十分でない場合、複合機能１１６はエラー処理のタスクを第２レベルのエンティティドメイン１２６まで留保する。エンティティドメイン１２６はエラーにうまく対応できない場合、さらにエラーを第１レベルのエンティティドメイン１２４に先送りできる。Ｂ．２項で、エンティティドメイン・フレームワーク１００におけるエラーのエスカレーションのプロセスに関し詳細な情報を述べる。

他の事例では、ローカルサービス（例えば、サービス１３２、１３４）は、エンクロージング（親）エンティティドメインが提供する一般サービスを無効にする又は修正する。他の事例では、エンティティドメイン・フレームワーク１００は、あるエンティティドメイン（およびその関連の複合機能）がエンティティドメイン・フレームワーク１００の高次レベルが提供するサービスにアクセスできないようにする。他の事例では、エンティティドメイン・フレームワーク１００は、エンティティドメインの全部の中に一定の基本サービスの冗長インスタンスを提供して、これらエンティティドメイン内のあるエンティティが階層を登ることによってこれらサービスを検索する必要をなくすことができる。

以下の項目では、前述した一般原理を説明する補足的な詳細を述べる。
（Ａ．２．結合機構とカプセル化機構）
さらに図１を参照して、エンティティドメイン・フレームワーク１００の階層構造は、フレームワーク１００のコンポーネントをまとめて繋げる参照のコレクションにより維持する。つまり、各コンポーネントは、その各親にリンクさせる参照情報によってそのエンティティドメインに結合する。親子結合を実装する１つの方法は、各子のコンポーネントの構築時に親の参照情報を各子のコンポーネントに提供することよる。親の参照情報は、このコンポーネントをその複合コンポーネントにリンクする。この機構は、エンティティドメイン・フレームワーク１００が子のコンポーネントを連続的に親のコンポーネントに追加することによって大きくなるため、エンティティドメイン・フレームワーク１００のトップダウン構成を促進する。例えば、参照１３６はその対応するエンティティドメイン１２４で基本コンポーネント１０６をリンクする（部分的に複合機能１０４によって具体化される）。さらに、特別な方針の一部として（有効期間管理など）、子の基本コンポーネントはその親と祖先に登録できる。このことは親と祖先にその各子に関する情報を提供する。この情報は、親エンティティドメインがその内包エンティティドメインを停止したいときなど、様々な状況で役に立つようになる。しかし、これら特別な場合を除いて、親はその子を識別する参照情報へのアクセス権をもたない。この特徴は、コレクションの準備ができているコンポーネントのガーベッジコレクションを干渉する可能性がある参照情報を持ち込まないため有益である。

複合機能（１０４、１１０、１１６）は前述の方法でまとめて結合できる。つまり、子の複合機能は、その親を識別する参照情報に基づいて、その親の複合機能に結合できる。例えば、参照１３８は複合機能１１０を親複合機能１０４とリンクする。一定の方針固有の状況では、親複合機能は、どの子複合コンポーネントが親複合機能に従属するかを判別するための機構を含むこともできる。

リンクした複合機能（１０４、１１０、１１６、１２２）の階層ツリーは、エンティティドメイン・フレームワーク１１０内のアクターが様々なサービスにアクセスできるコンジットを成す。このコンジットはサービスバス１４０と呼ばれる。コンジットは、フレームワーク１１０内の個々のアクターと各サービスの事例とを明示的にポイント・ツー・ポイント結合を必要とせず、アクターに一般的な要求プロトコルからサービスの要求を出すのを許可するという意味でバスに似ている。要求プロトコル（検索サービスが提供）は、必要なら様々なレベルの階層で、要求されるサービスを有するエンティティドメインに到達するまで連続的に照会を行うことによって、要求されるサービスにアクセスする。

サービスバスは様々な理由で他のストラテジーよりも優れる。ポイント・ツー・ポイントストラテジーは、オブジェクトとサービスの原子的な結合を必要とすることがある。他のストラテジーは、事前にサービスが必要な各オブジェクトのためにサービスを複製することがある。対照的に、本フレームワーク１００の独特なサービスバス１４０を使えば、フレームワーク内のエンティティは、事前に必要とするサービス、又は呼び出すサービスの個々のインスタンスに特別なリンクを設ける必要はない。エンティティがサービスを要求する場合、サービスの種類を指定してサービスを要求できる。このサービスはサービスバス１４０を介して階層のあるレベルで受け取る。このアプローチは特定の代替法よりも複雑ではないとともに、メモリ効率もよい。例えば、サービスと対話するための周知のストラテジーは一般的にアプリケーションのランタイム実装にオーバーヘッドを追加することがあるが、これはさらにそのメモリのフットプリントを増やすことになり、他のランタイムの効率が悪くなる事態を招く。本明細書で説明する設計は、これらの欠点をなくす又は減らすことができる。メモリ節約の具体的な例は、エンティティが利用するかもしれないサービスそれぞれに対する個々の参照を記憶する必要がないということによる。エンティティは検索サービスにアクセスできる１つの参照を記憶するだけでよく、それから検索サービスは複数のサービスのいずれにもアクセスできる。（背景技術のところで述べたように、一部の従来の技術は広域変数を使用して共有コンテキストを実装し、それによって効率や性能などの面で利点を得るが、これら技術は比較的粗いレベル、例えばプロセスやスレッドレベルの範囲を提供し、本明細書で説明するエンティティドメインの個別の使用による利点は得られない。）次の項では、サービスバス１４０を実装するために使用できる例示的な検索プロトコルに関する詳細を述べる。

検索機能は、コンポーネントを一定のサービスにアクセスさせる一方、エンティティドメイン・フレームワーク１００はそれ以外のエンティティドメイン・フレームワーク１００内のコンポーネント間の情報の交換を制限する機構を含むことができる。ある前記機構に従い、エンティティドメイン・フレームワーク１００は、任意のエンティティコンポーネントをエンティティドメイン・フレームワーク１００の一定の特徴を発見させないようにする保護・カプセル化機能を含むことができる。より具体的には、前述のように、エンティティドメイン・フレームワーク１００は任意のコンポーネントにその親を識別する参照情報を発見させることができるともいえる。エンティティドメイン・フレームワーク１００は任意のコンポーネントに検索サービスにアクセスさせることもでき、すなわちそのコンポーネントがそのローカルエンティティドメインによって提供される又はエンクロージングエンティティドメインによって提供されるサービスにアクセスできる。しかし、エンティティドメイン・フレームワーク１００は任意のエンティティコンポーネントにそのピア、複合機能が提供するサービスの性質、エンティティドメイン・フレームワーク全体の構造などに関する情報を発見させないようにすることもできる。より具体的には、エンティティドメイン・フレームワーク１００は、前記情報をエンティティドメイン・フレームワーク１００自体の基本構造の一部として発見するための機構を提供しないという意味で、あるコンポーネントに前記情報を「発見させないように」できる。それでも、エンティティドメイン・フレームワーク１００は依然多機能で、あるアプリケーションはコンポーネント間のある程度の対話を可能にするカスタム機能を組み込むことができる。言い換えると、エンティティドメイン・フレームワーク１００は前記コンポーネント間の対話は妨げない。そのストック、又はコアの一部として単に機能を提供するわけではない。

アプリケーションリソースの統合性を確保するために、さらに別の保護・カプセル化機構も採用できる。

（Ａ．３．サービスおよび検索機能）
ここで図２に進むと、この図は、図１に示すエンティティドメイン・フレームワーク１００が実装できる例示的なサービス２００を示す。図２の説明では図１の一定の特徴も参照する。

サービスとは、直接又は間接的に、エンティティドメイン・フレームワーク１００内のエンティティコンポーネントが１以上の規定のタスクを行うために使用できるあらゆる機能をいう。一定のサービスとは、多様な様々な種類のアプリケーションに適用する他よりもより基礎的又は基本的なものである。図２は例示的な基本機能サービス２０２として基礎的サービスを参照する。ある前記基本機能サービス２０２は、検索サービス２０４である。コンポーネントは検索サービス２０４を呼び出して、エラー処理サービスなどの別のサービスを要求し、アクセスすることができる。１組の基本機能サービス２０２は、一般的に図２の楕円形で表示するように、「その他基本機能サービス」２０６とラベル付けされたその他基礎的サービスを含むことができる。

サービス２００内のグループのその他のサービスは、基本機能サービス２０２に依存する高次の方針に属するであろう。ある前記高次のサービスとは有効期間サービス２０８である。有効期間サービス２０８を含むエンティティドメインは、有効期間ドメインと呼ばれる。述べたように、有効期間サービス２０８は、コンポーネントを構成しその使用をやめる方法を統制する機能を提供する。Ｂ．１の項に有効期間サービス２０８に関する詳細な情報を述べる。

別の高次のサービスはエラー処理サービス２１０である。エラー処理サービス２１０を含むエンティティドメインは、エラー処理・ドメインという。上述のように、エラー処理サービス２１０は、エンティティドメイン・フレームワーク１００内で発見されたエラーを処理する方法を統制する機能を提供する。Ｂ．２項にエラー処理サービス２１０に関する詳細情報を述べる。

１組の高次サービスは、一般的に図２の楕円形で表示するように、「その他サービス」２１２とラベル付けされるようなその他のサービスを含むことができる。一般的に、図２のサービスの高次サービスおよび基本機能サービスへの分解は、サービスを理解しやすくするためであり、これらサービスが必然的に著しく異なる特徴をもつことを示すと解釈してはならない。例えば、有効期間サービス２０８とエラー処理サービス２１０が多くの種類のアプリケーションに幅広く使え、恐らくはさらに高次の性質のサービスでも使用されると予想される限り、これらサービス（２０８、２１０）は代わりに基本機能サービス２０２に分類できる。

前述の説明は、サービス２００をあるアプリケーションが実装できる個別の機能として識別した。しかし、１つのアプリケーションは、有効期間管理サービス２０８とエラー処理サービス２１０との両方など、複数のサービスを使える。ある場合では、ある種のドメイン（有効期間ドメインなど）は別の種類のドメイン（エラー処理ドメイン等）と同じメンバーを有することがある。他の場合では、ある種のドメインのメンバーシップは他の種類のドメインの構成とは異なることがある。後者の場合、異なる複合機能が異なるドメインに割り当てられて、これらドメインの異なる構成を定義し、このように作成された複合機能は、そのメンバーが使用するために異なるサービスを発行し、それによってドメインの性質を定義する（例えば、有効期間サービスは有効期間ドメインを定義するなど）。

サービス２００は様々な方法で実装できる。一般的に、サービス２００は複合コンポーネント自体により実装でき、又は複合コンポーネントのあるサブオブジェクト（典型的には基本コンポーネント）により実装できる。あるいは、例えばサービスや他の要因の性質によって、あるアプリケーションは異なる技術の組合せを使用して、異なるサービスを実装することもできる。さらに他の実装も提供できる。Ａ．４項（下記）に、エンティティコンポーネントとその関連サービスの例示的な実装に関する詳細を述べる。

図３は、検索サービス２０４の操作を統制するプロトコル３００を示す。この例では、プロトコル３００が例示的な複合機能（３０２、３０４、３０６、３０８）の階層において使われる。これら複合機能の各々（３０２、３０４、３０６、３０８）は、各エンティティドメインを定義し、その各々が１以上の基本コンポーネント（図示せず）を含むことができる。各複合機能（３０２、３０４、３０６、３０８）は、それをそのエンクロージング（親）複合機能にリンクさせる参照情報を含む。図３は、１連鎖の複合機能（３０２、３０４、３０６、３０８）を示すが、エンティティドメイン・フレームワークはあらゆる複雑さおよびサイズの複合機能の多枝のツリーを含むことができる。（より具体的には、トップダウンの見方からすると、エンティティドメイン・フレームワーク１００はツリーとして見えるが、エンティティドメイン・フレームワーク１００内の所定の子のコンポーネントは１連鎖の参照を通しツリーのルートに関係する。）また、複合機能（３０２、３０４、３０６、３０８）はより包括的なエンティティドメイン・フレームワーク（図示せず）の一部のみを表すこともあろう。

各複合機能（３０２、３０４、３０６、３０８）は、各複合機能（３０２、３０４、３０６、３０８）に関連するサービス（３１０、３１２、３１４、３１６）へのアクセス権をもつ。つまり、複合機能３０２はサービス３１０へのアクセス権をもち、複合機能３０４はサービス３１２へのアクセス権をもち、複合機能３０６はサービス３１４へのアクセス権をもち、複合機能３０８はサービス３１６へのアクセス権をもつ。加えて、以下に説明する方法で、エンティティドメイン・フレームワーク１００内のいずれのエンティティも、親又は祖先の複合機能が提供するあらゆるサービスにアクセスできる。

検索サービス２０４の操作を説明するために、複合機能３０２に関連するエンティティ（図示せず）がサービスの種類を指定することによってあるサービスを要求すると仮定する。応答して、複合機能３０２はまず、そのローカルサービス３１０が要求されるサービスを提供できるか否かを判別する。提供できるなら、複合機能３０２はこのサービスを提供する。複合機能３０２が要求されるサービスを提供できないなら、次に検索サービス２０４が複合機能３０４に問い合わせて要求されるサービスを提供できるか否か判別する。検索サービス２０４は、要求されるサービスを提供できるエンティティドメインが見つかるまで、順次エンティティドメインの階層を登りながら、このプロセスを繰り返す。例えば、この検索プロトコル３００はエンティティドメインの階層のルート（図示せず）までとことん進むことができる。前述の機構は、図１を参照して紹介したサービスバス１４０を実装する。

サービスバス１４０の動作を変える多数の例外が適用できる。ある技術では、ローカルエンティティドメインは、エンクロージング親又は祖先エンティティドメインから以前にアクセスしたことのあるサービスをキャッシュに格納することができる。そのローカルエンティティドメインがそのサービスへのアクセスを再び要求する場合、サービスはそのキャッシュからアクセスできる。このことは前述した反復検索を行う必要をなくす。

別の技術では、エンティティドメイン・フレームワークはエンティティドメインを分離できる。この機構で、検索サービス２０４は分離されたエンティティドメインを超えてエンティティドメインの階層を登れない。言い換えると、エンティティドメインを分離することは、本質的に検索を分離したエンティティドメインで終了させる。図３はこの特徴を「Ｘ」で示しており、検索サービス２０４がこの地点を超えて登らない遮断を表す。この機構は、少なくとも要求されるサービスを遮断することに関し、複合機能３０２を効率よく偽のルートに見せている。これは、その検索サービスが複合の親を参照しないように構成された特別な複合コンポーネントを提供することによって実装できる。

（Ａ．４．例示的なエンティティの実装）
前述したように、エンティティドメイン・フレームワーク１００内のエンティティはオブジェクト指向プログラミング技術を用いて実装できる。より具体的には、複合機能は第１の基本クラス（例えば、ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ）に基づいてインスタンス化ができる。複合機能のインスタンス化はエンティティドメインを確立する。基本コンポーネントは、第２の基本クラス（例えば、ＥｎｔｉｔｙＥｌｅｍｅｎｔ）に基づいてインスタンス化ができる。これら２つのそれぞれのクラスを実装する例示的なコードの抜粋を以下にあげる。
public abstract class EntityComposite:IEnityDomain,・・・
{
protected EntityComposite(IEntityDomain entityDomain）{・・・}
・・・
}
public abstract class EntityElement
{
protected EntityElement （IEntityDomain entityDomain）{・・・}
・・・
}

ある例示的で非制限的な実装によると、エンティティドメイン・フレームワーク１００は、親エンティティドメインの参照（ＩＥｎｔｉｔｙＤｏｍａｉｎ）をコンストラクタパラメータとして構成中に子のコンポーネントに渡すことによって、エンティティドメインの関係を確立する。エンティティコンストラクタはさらにこの情報をその基本クラス（ＥｎｔｉｔｙＥｌｅｍｅｎｔ又はＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ）コンストラクタに渡すことができる。ＥｎｔｉｔｙＥｌｅｍｅｎｔとＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅの両基本クラスはこの参照を保持して、それをそのコンストラクタで初期設定する。（一般的に、この例示的な実装では、分離した基本クラスのコードはこれら上側のリンクの管理を担当する。）このモデルはトップダウン構成を実施する。トップダウン構成は、親参照の一回だけ設定できるセマンティックスと合わせて、エンティティドメイン構造自体へのサイクルの導入を不可能にする。

基本クラスは、これら基本クラスを使って作成したコンポーネントが前項で説明したタスクを実施できるようにする機能を提供する。例えば、ある例示的で非制限的な実装では、ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅとＥｎｔｉｔｙＥｌｅｍｅｎｔの両基本クラスは、保護された非バーチャルな方法で前述の基本機能サービス２０２を提供する。ある前記方法とはＬｏｏｋｕｐＳｅｒｖｉｃｅの方法で、図２で紹介した検索サービス２０４を実装する。

ＬｏｏｋｕｐＳｅｒｖｉｃｅの方法は、ＥｎｔｉｔｙＥｌｅｍｅｎｔ基本クラスとＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ基本クラス両方に関わる面をもち、ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ基本クラスは、図３に図示する反復的な検索動作を実装するのに重要な機能を提供する。より具体的には、ある特定の基本コンポーネントに関連する検索操作を開始すると、ＥｎｉｔｉｔｙＥｌｅｍｅｎｔ基本クラスのＬｏｏｋｕｐＳｅｒｖｉｃｅが、本明細書ではｐ−１親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントと呼ぶその親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントに即座に先送りする。

ｐ−１親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントは、ＬｏｏｋｕｐＳｅｒｖｉｃｅのその一部を実行することによりＥｎｔｉｔｙＥｌｅｍｅｎｔコンポーネントに応答する。これは、まずｐ−１親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントが発行する１組のサービスの照会を伴う。ｐ−１親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントが発行したサービスの中から要求されるサービスの種類を見つけられなかったら、本明細書ではｐ−２ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントと呼ぶ上側のそれ自体の親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントに先送りする。

ｐ−２親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントは、ｐ−１親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントと同じように反応する。つまり、まずそれが発行した１組のサービスを照会して、ＬｏｏｋｕｐＳｅｒｖｉｃｅを呼び出し、要求されるサービスが見つからなかったら、その各親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネント（つまり、ｐ−３親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネント）に先送りする。要求されるサービスが見つかるまで（又は要求されるサービスが見つからないと判別されるまで）このプロセスを繰り返す。

しかし、分離したサービス範囲を導入する特別に構成した複合コンポーネント（そのため利用できるサービスに関して含まれるコンポーネントを分離する）はその各親ＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅコンポーネントには従わず、そのため前述の反復的検索操作をサポートしない。言い換えると、サービスの要求は、分離した特徴が呼び出されているこのようなエンティティドメインに到達すると終了する。

エラー処理サービス２１０に関しては、ＥｎｔｉｔｙＥｌｅｍｅｎｔとＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅの両基本クラスは、コンポーネントが出会うエラーを報告するための保護された方法をもつ。（これは、エラーの発生時にエラー処理機能にアクセスした後、その機能を呼び出すための検索操作のカプセル化として実施する。）より具体的には、エラー処理方法は、（エラー処理サービスを受けさせるエンティティドメインである）コンポーネントを含む隣接するエンクロージングエラー処理ドメインに前記エラーを回すことができる。エラーハンドラーがエラーを収容できれば、適切な措置をとる。エラーハンドラーがエラーの処理方法が分からない場合、エラーは次のエンクロージングエラー処理ドメインに先送りする。

別の特徴によると、基本コンポーネントは、ＥｎｔｉｔｙＥｌｅｍｅｎｔ基本クラスのＰａｒｅｎｔプロパティを使ってそのエンティティドメインの親を発見できる。基本コンポーネントは、この機能を使って収容するエンティティドメイン内に新たなピアを作成する。

明細書および図面を通して同様のコンポーネントおよび特徴の参照は同じ番号を使用する。１００番台の番号は最初に図１にでてくる特徴を示し、２００番台の番号は最初に図２にでてくる特徴を示し、３００番台の番号は最初に図３にでてくる特徴を示し、以下同様である。

（Ｂ．例示的なサービス）
本項では、図１のエンティティドメイン・フレームワーク１００により実装できる例示的なサービスを説明する。つまり、Ｂ．１項では有効期間サービス２０８を説明し、Ｂ．２項ではエラー処理サービス２１０を説明する。

（Ｂ．１．有効期間ドメイン）
図４は、有効期間サービス２０８を説明するための手段として使用するエンティティドメイン・フレームワーク４００を示す。前述したように、有効期間サービス２０８を実装するエンティティドメインは有効期間ドメインと呼ぶ。有効期間サービス２０８は、さらにアプリケーションのランタイム中にコンポーネントの削除を統制するために使用する機能を提供する。

まず、エンティティドメイン・フレームワーク４００は、ルートノード（図示せず）から始めて一つずつ構成できる。ルートノードは、アセンブリの一定の汎用面を定義する。作成プロセスは、追加コンポーネントをルートノードに追加し、これがさらに追加コンポーネントを追加するためのプラットフォームの役割を果たす。プロセスは、このようなトップダウン方式でアプリケーションを構築および実行しながら進める。同時に、以下に説明する機能はまた、このように作成されたエンティティドメイン・フレームワークのプルーニングの作業時に、もはや必要のないコンポーネントを削除する。

ルートノードは、アプリケーションが提供する最も包括的な有効期間ドメインに対応する。アプリケーションはその後、コンポーネントの各追加グループの有効期間を統制する追加の内包有効期間ドメインを作成する。開発者は、発展するエンティティドメイン・フレームワーク４００を様々な考慮事項に基づき、様々なドメインに分割するコードを提供できる。例えば、開発者は、以下の要因の１以上を適用するため、コンポーネントのグループに個々の有効期間を割り当てる決定をしてもよい。その要因とは、（ａ）コンポーネントのグループを単体としてアプリケーションが一般的に作成および削除する、（ｂ）コンポーネントのグループがグループのエンクロージング有効期間ドメインより短い有効期間を有する、（ｃ）コンポーネントのグループに確定的な停止が必要である、および/又は（ｄ）グループ内のコンポーネントに、対話するリソースを解放するための明示的な停止通知が必要である、というものである。「確定的な停止」という用語は一般的に、一定の停止イベントに反応して、定義されたプロトコルに従い（例えば、定義された操作シーケンスに従い）行う停止プロセスをいう。確定的な停止は、停止操作に予測可能性を提供する。そのため、より具体的な例示的状況では、確定的停止は、予測可能な順番と予測可能な終了結果をもつ停止プロセスをいう（例えば、開始したのと同時に完了するプロセス）。対照的に、従来のガーベッジコレクション技術は、インスタンスが参照されなくなると（つまり、もはや別のコンポーネントから参照されなくなる）インスタンスがガーベッジコレクションの対象となる時を容易に予測できない。さらに、ともに削除の候補に挙がる２つのインスタンス間にある関係がある場合、従来のガーベッジコレクション技術は、それらを削除する順番を容易に予測できない。

例えば、あるリストのＵＩエレメントに対応する親エンティティドメインと、リストエレメントに含まれる表のＵＩエレメントに対応する子のエンティティドメインとの場合を考えてみる。表エレメントは、リストエレメント全体の前に削除する必要があると考えられる。これはリストエレメント全体ではなく、表エレメントの削除を促すスクローリングイベントが原因であろう。この状況は、部分的には個々の有効期間ドメインを表エレメントに割り当てるのが適切となろう。さらに、リストエレメント全体が削除される場合、表エレメントも削除されるはずである。この状況は、リストエレメントの有効期間ドメイン内に表エレメントの有効期間ドメインをネストして、エンクロージング有効期間ドメインの停止が表エレメントの有効期間ドメインの停止も促すようにするのが適切であろう。

様々なアプリケーションや設計上の考慮事項が様々な有効期間ドメインの分割の作成を保証する。説明する手段を提供するために、図４に、制限するものでなく、ある例示的なエンティティドメイン構造４００の一部を表す。エンティティドメイン・フレームワーク４００は、第１レベルの有効期間ドメイン４０４を定義する複合機能４０２を含む。第２複合機能４０６が第１複合機能４０２に結合される。この第２複合機能４０６は第２有効期間ドメイン４０８を確立し、これに例示的な基本コンポーネント４１０が含まれる。第３複合機能４１２も第１複合機能４０２に結合される。この第３複合機能４１２は第３有効期間ドメイン４１４を確立し、これが基本コンポーネント４１６および４１８を含む。基本コンポーネント４１６は、データベースなどの様々なリソース４２０と対話するように構成される。この役割は、基本コンポーネント４１６をリソース・マネージャーにする。最後に、オブジェクト４２２など、例示的な有効期間ドメイン４１４外の様々なエンティティは、有効期間ドメイン４１４内のコンポーネントを指す参照を保持できる。

有効期間ドメイン（４０４、４０８、４１４）を作成するために、エンティティドメイン階層４００は、１以上のいわゆる有効期間ディレクタを提供する。これらディレクタは、一般的に（図２を参照して紹介した）有効期間サービス２０８の特徴を実装する。ある例示的な実装では、各有効期間ドメイン（４０４、４０８、４１４）は、それ自身の有効期間ディレクタを含む。しかし、図４は主に第１有効期間ドメイン４０４と第３有効期間ドメイン４１４との対話に着眼しており、そのため説明しやすくするために第３有効期間ドメイン４１４に関連する有効期間ディレクタ４２４だけを図示している。有効期間ディレクタ４２４の基本的な目的は、第３有効期間ドメイン４１４内の停止活動を調整することである。

別の態様によると、有効期間サービス２０８は、定義する有効期間ドメインのオーナーを状況に応じて受け入れる。図４に、第３有効期間ドメイン４１４を「所有」するある例示的なオーナー４２６を示す。オーナー４２６とその有効期間ドメイン４１４には一対一の関係がある。しかし、他の場合には、１オーナーが複数の有効期間ドメインを制御することがある。オーナー４２６の基本的な目的は、第３有効期間ドメイン４１４の停止を開始することと、（例えば、外部オブジェクト４２２から）第３有効期間ドメイン４１４を指す外部の参照を分離することである。

ディレクタ４２４は、第３有効期間ドメイン４１４内で作動する一方、オーナー４２６は、第３有効期間ドメイン４１４の外、典型的には第３有効期間ドメイン４１４を囲むある有効期間ドメイン（例えば、ドメイン４０４）で作動する。有効期間ディレクタ４２４は、その有効期間オーナー４２６への参照を保持する。有効期間オーナー４２６は、さらに所有する第３有効期間ドメイン４１４の複合機能４１２への参照を保持する。ある実装では、有効期間ディレクタ４２４は、有効期間ドメイン４１４の外部のその対応するオーナー４２６を認識する唯一のエージェントである。

有効期間オーナー４２６と有効期間ディレクタ４２４の機能は、有効期間オーナー４２６から始めて以下詳細に説明する。有効期間オーナー４２６はいくつかの役割を果たす。

１つの役割は、停止を開始することである。ある場合には、有効期間オーナー４２６は、その有効期間ドメイン４１４を停止するための具体的な要求を受け取ることができる。つまり、この場合、要求は、具体的には有効期間ドメイン４１４を対象とする。さらに停止は、有効期間ディレクタ４２４で調整しながら、確定的な方法で進める。ある一般的な原理では、エンクロージング有効期間ドメインを停止する要求も、エンクロージングドメインの内包有効期間ドメインの全ての反復的な停止を促す。これによって、従属有効期間ドメインは、そのエンクロージング（親）有効期間ドメインより長く残らない。親有効期間ドメインがスクロールバーに対応し、子の有効期間ドメインがそのスクロールバーのある一部に対応する例を考えてみる。スクロールバー全体の削除はそのコンポーネント部分の削除を促すとともに、その部分に対応する全ての内包子ドメインの削除を促す。

この停止動作を実装するある方法は、各内包有効期間ドメインがその存在をその親有効期間ドメインに登録するよう要求することである。その結果、親有効期間ドメインは、どの内包有効期間ドメインが「その下」にあるかが「分かる」。さらに、親有効期間ドメインの停止が促されるイベントが発生する場合、有効期間ドメインは、従属有効期間ドメインのレジストリにアクセスして、それをその従属有効期間ドメインの各々に対する停止指示を差し向けることができる。内包従属ドメインの停止は、反復的に行う。停止は、最も深くネストした有効期間ドメインから始めて、２番目に深くネストした有効期間ドメイン等とし、停止するべき対象有効期間ドメインで終了する。

他の事例では、有効期間オーナー４２６は、（例えば、前述したネストされる停止操作の種類により）有効期間オーナー４２６自体が停止する有効期間ドメインの一部であることを有効期間オーナー４２６に通知する有効期間ディレクタ４２４からの要求を受け取ることができる。

有効期間オーナー４２６は、停止を開始することに加えて、追加タスクを行うことにより停止に応答できる。あるタスクでは、有効期間オーナー４２６は外部オブジェクト（例えば、オブジェクト４２２から）の全ての参照を第３の有効期間ドメイン４１４に分離する。この内部への参照の分離は、停止するサブシステムを確実にガーベッジコレクションの対象にできるために望ましい。対照的に、有効期間ドメイン内に全体が留まる全ての参照は制限を受けない。このため、特別な有効期間管理機構をこの種の参照の処理に充てる必要はない。（ドメインの外部から有効期間ドメインへの参照は、これら参照が例えばドメインがまだ何らかの形でアプリケーションに利用されているか否かを示すことによりドメインを動作したままにするものであるため、特別な問題である。）

同様に、停止プロトコルを実行しながら、複合アップリンクのいずれも分離する必要はない。これらアップリンクは全て、停止の対象となる最も外側の複合機能の最後にある１つの下位参照を削除することによって、１回の動作で切り離すことができる。言い換えると、有効期間オーナーからの参照をそれが所有するドメインの複合機能に分離することは、厳密に言うと停止する最も外側の有効期間ドメインにのみ必要である。

しかし、一般的に言うと、エンティティドメインはオーナーを含むこともあれば含まないこともある。有効期間ドメインがオーナーを含む場合、そのエンクロージング親有効期間ドメインとは分離して確定的に停止できる。オーナーを含む有効期間ドメインをアクティブドメインという。例えば、図４の場合、第３有効期間ドメイン４１４がオーナー４２６を含むので、その親有効期間ドメイン４０４からは独立して停止できる（ただし、前述したように、親有効期間ドメイン４０４は、子の有効期間ドメイン４１４も停止しなければ停止できない）。別の状況では、有効期間オーナー４２６は省略することができる。オーナーのない有効期間ドメインをパッシブドメインという。この場合、第３有効期間ドメイン４１４は、その親有効期間ドメイン４０４が停止されると、それから分離せずに必ず自動的に停止されるであろう。更なる注意として、外部参照の処理に関する一定の前述の規則はアクティブ有効期間ドメインにのみ適用する。パッシブ有効期間ドメインは分離して停止できない。そのため、入ってくる参照は、それがエンクロージングアクティブ有効期間ドメインも交わっていない限り問題ない。

有効期間ディレクタ４２４は、停止に関連する様々な活動の調整も行う。これら機能の一部は、内包有効期間ドメインの停止の調整など、上記のとおりである。別の特徴によると、有効期間ディレクタ４２４はまた、リソース・マネージャーに停止通知を提供する。より具体的には、基本コンポーネント４１６などの有効期間ドメイン内の一定のエンティティは、データベースなどの１以上のリソース４２０と対話し、それによってこれらコンポーネントをリソース・マネージャーにする。その役割のために、リソース・マネージャーはその関連するリソースの有効期間を制御したり、又は影響を与えたりすることができる。有効期間ディレクタ４２４は、この関係を、リソース・マネージャーの系統的かつ信頼性のある停止を確保するプロトコルを提供することによって処理する。系統的な停止を実装するある方法は、各リソース・マネージャー（例えば、リソース・マネージャー４１６）を、その包括的な有効期間ドメイン４１４に登録を要求することによって行う。さらに、停止時、有効期間ディレクタ４２４はこれらリソース・マネージャー（例えば、リソース・マネージャー４１６）にその各リソース（例えば、リソース４２０）との関わりを解放するよう指示できる。

うまく停止した後、ガーベッジコレクション機能４２８を実行してもはや必要のなくなった割り当てメモリヒープからコンポーネントを削除できる（ただし、ガーベッジコレクションは、正式にはそれ自体が有効期間管理サービスの一部ではない）。ガーベッジコレクション機能は周知のシステムで使用されるが、ここで説明する状況において明確に使用されるわけではない。従来のシステムでは、ガーベッジコレクション機能は、メモリに記憶される各アクティブコンポーネントに関連する参照の詳細な計算を保持する。ガーベッジコレクション機能が、あるコンポーネントがもはやそれへの参照をもたないことを発見したら（つまり参照数＝０）、ガーベッジコレクション機能は、そのコンポーネントを削除する。しかし、これらのシステムでは、アプリケーションの一部を正確に停止し、もはや必要なくなったときにこれら一部への参照を正確に削除するプロトコルはない。正反対に、図４の状況で説明する有効期間管理は、（例えば、前述したように、確定的に）十分に定義され予測可能な操作シーケンスを用いるガーベッジコレクションに先行するものとして、アプリケーションの一部を停止する十分確立されたプロトコルを提供する。

一般的に、前述の機構により、（例えば、子から親の「方向」における）基本コンポーネントから複合機能に「上へ」の参照は、有効期間ドメインのガーベッジコレクションを干渉しない。有効期間ドメインは「下へ」の参照（親から子の方向に）も維持して停止を調整する。系統的な停止手順は、必要なくなったときにこれら参照を切断し、それによってこれら参照が停止されている有効期間ドメインのガーベッジコレクションを妨げないようにする。

上記一般的な特徴を念頭に入れて、以下の説明は停止を行う例示的なある状況を述べる。上記展開した例をここでも適用すると仮定する。この例では、エンティティドメイン４０４は、リストＵＩエレメントの有効期間を管理する。リストＵＩエレメントは、表ＵＩエレメントなど、複数の役割を含む。有効期間ドメイン４１４は、表エレメントの有効期間を管理できる。

以下のイベントを行って、表エレメントを作成する。
・まずリストエレメントは、表エレメントの有効期間オーナーを作成する。有効期間オーナーは、表エレメントと一対一の関係であってもなくてもよい。
・次に、リストエレメントをそれ自体とともに表エレメントコンポーネントの親として有効期間オーナーを、表エレメントを作成する構成機能（例えば、いわゆるファクトリ機能）に移す。（それと対照に、新たなインスタンスを作成及び初期設定して、さらにそれを発呼者に渡すあらゆる方法をファクトリ方法という）。
・構成機能が表エレメントを作成する時、（表エレメントの親を識別する）親参照を渡さなければならず、任意で（表エレメントのオーナーを識別する）オーナー参照を子のコンストラクタに渡すことができる。これで表エレメントの作成プロセスは完了する。

以下のイベントのシーケンスは、表エレメントを停止するために行う。
・リストエレメントは、表エレメントの有効期間オーナー４２６に表エレメントの停止を要求できる。
・表エレメントの有効期間オーナー４２６は、表エレメントの有効期間ディレクタ４２４に停止の開始を通知する。
・表エレメントの有効期間ディレクタ４２４は、さらに表エレメントの有効期間オーナー４２６に、（他の有効期間ドメインから）全ての外部参照を表エレメントに分解するよう要求する。この指示は、有効期間オーナー４２６に外部オブジェクト４２２からの参照を切断するように促す。
・有効期間オーナー４２６は、その参照を表エレメントに解放する。
・有効期間ディレクタ４２４は、その有効期間ドメイン４１４が囲むあらゆる子（内包）有効期間ドメインに停止要求を伝える。簡単にするために、表エレメントの有効期間ドメインの全ての子は、非有効期間複合体に対応すると仮定する。
・表エレメントの有効期間ディレクタ４２４は、停止通知のために登録している全てのコンポーネントに通知する。これらは、コンポーネント４１６のように、リソースを閉じる又は通知から登録抹消する必要のあるコンポーネントである。それから有効期間ディレクタ４２４は、リストエレメントが管理する子の有効期間コレクションから表エレメントを削除する。
・コールスタックを有効期間オーナー４２６に解く。表エレメントは、この時点でガーベッジコレクションの対象となることができる。
・コールがリストエレメントに解かれ、リストエレメントは、その参照を表オーナー４２６に解放でき、同様にこの時点でガーベッジコレクションの対象となれる。

上記の例は表のリストに関わり、各表は、リストから独立して追加および削除することができ、それによって各表の有効期間ドメインを保証する。この例の表は、エレメントとしての役割を果たす。しかし、当業者にはこの例が単なる例示的なものであると理解されるであろう。別の例では、表自体をＵＩエレメントのリストとして実装でき、各エレメントが表の列に対応する。表の個々のエレメントに関して、前述したのと同様な有効期間管理操作が行える。

エンティティドメイン・フレームワーク４００は、前述の有効期間フレームワーク４００を様々な方法で実装できる。例えば、有効期間ディレクタ４２４は、エンティティ複合体の特別な複合基本クラス（例えば、ＬｉｆｅｔｉｍｅＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ）として実装できる。このことは、有効期間ディレクタ機能を複合インプリメンタから封じられるため有利である。より具体的には、ＬｉｆｅｔｉｍｅＤｏｍａｉｎＣｏｍｐｏｓｉｔｅクラスは、エンティティ複合体の特別な変型であるため、Ａ．４項（上記）で論じたＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅ基本クラスから導く。

より具体的には、有効期間ドメインを確立したい複合コンポーネントは、ＬｉｆｅｔｉｍｅＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ基本クラスから導ける。有効期間ドメインを実装する複合クラスのコンストラクタへのパラメータの１つがそのオーナーである。このオーナー参照は、親参照とともに基本クラスに渡されるはずである。オーナー参照は、基本クラスに記憶でき、停止操作中に発呼者を検証するために使用できる。（オーナーをもたない）パッシブ有効期間ドメインは、オーナーパラメータのヌル値を渡して作成できる。

有効期間ドメイン複合体をインスタンス化する場合、ＬｉｆｅｔｉｍｅＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ基本クラスのコンストラクタは、次のエンクロージング有効期間ドメインを検索して、停止プロトコルに参加できるようにそれ自体をそこに登録する。その結果、親有効期間ドメインは、そのネストされた子の有効期間ドメイン全部への参照を維持する。

前述の基本クラス（ＬｉｆｅｔｉｍｅＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ）は、有効期間ドメインをサポートする機能を含む。この基本クラスが実装する例示的なインターフェースとそれらの各目的とを以下に挙げる。（インターフェースの識別名は、これに制限するものではなく、例示的なものとして意図している）。
・ＩＰｒｏｖｉｄｅＳｈｕｔｄｏｗｎインターフェースは、コンポーネントが停止通知のための登録を行うために使用する。
・ＩＩｎｉｔｉａｔｅＳｈｕｔｄｏｗｎインターフェースは、有効期間オーナーが所有する有効期間ドメインで停止を開始するために使用する。
・ＩＭａｎａｇｅＣｈｉｌｄＬｉｆｅｔｉｍｅＤｏｍａｉｎｓインターフェースは、子の有効期間ドメインがエンクロージング有効期間ドメインから子の有効期間ドメインを追加および削除するために使用する。
・ＩＳｈｕｔｄｏｗｎＴｈｉｓＬｉｆｅｔｉｍｅＤｏｍａｉｎインターフェースは、ネストされた子の有効期間ドメインに停止要求を伝えながら、内包有効期間ドメインの停止を開始するために使用する。

有効期間オーナーの役割は様々な方法で実装できる。有効期間オーナーは、収容するエンティティ複合体が制御するあるインスタンスに対応できる。つまり、有効期間オーナーは、典型的にはそのエンクロージング（つまり、親）複合体のエンティティである。しかし、有効期間オーナーとその関連する有効期間ドメインとは、同じ直の親ではなく共通の祖先だけをもつことも可能である。いずれの場合の、有効期間オーナーは、所有する有効期間ドメインを（ＬｉｆｅｔｉｍｅＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ基本クラスで）構成しようとするとき、それが所有する有効期間ドメインへの参照が与えられ、その時点で有効期間オーナーは、所有する有効期間ドメインへの参照を記憶する。

有効期間オーナーは、前述の割り当てられた責任を実装するよう構成するという以外で、有効期間オーナーを実装できる方法には制約がない。例えば、有効期間オーナーは、前述のＩＩｎｉｔｉａｅｔＳｈｕｔｄｏｗｎ．Ｓｈｕｔｄｏｗｎ機能を呼び出して確定的な停止を開始できる。このことがＬｉｆｅｔｉｍｅＤｏｍａｉｎＣｏｍｐｏｓｉｔｅ基本クラスを促して、構成中に渡されるオーナー参照を調べることによって発呼者が有効期間オーナーであることを検証する。それから確定的な停止が、（収容される有効期間ドメインへの参照とＩＳｈｕｔｄｏｗｎＴｈｉｓＬｉｆｅｔｉｍｅＤｏｍａｉｎインターフェースを使用する）その有効期間ドメインに根付いた有効期間ドメイン階層を通じて伝えられ、さらに全ての内包有効期間ドメインを停止する。これにより停止通知がリソース・マネージャーに送られ、これらマネージャーがそのリソースを確定的に解放する機会を与える。

有効期間オーナーの別の役割は、全ての外部参照をドメイン外のオブジェクトからそれが所有する有効期間ドメインに分割できることである。そのため、有効期間ドメインのクライアントは、この知識を有効期間オーナーに組み上げるはずである。有効期間オーナーは、ＩＰｒｅｐａｒｅＦｏｒＳｈｕｔｄｏｗｎ機能を実装して、停止中に外部参照を有効期間ドメインに分割する。より具体的には、有効期間ディレクタは、停止要求を受け取ると、ＩＰｒｅｐａｒｅＦｏｒＳｈｕｔｄｏｗｎインターフェースを使って有効期間オーナーに通知して、外部参照をその外部のオブジェクトから有効期間ドメインに分割するのに必要な動作を開始する。有効期間オーナーは、停止がその有効期間オーナーから開始されるか、又はネストされた停止に参加するか否かに関わらず、ＰｒｅｐａｒｅＦｏｒＳｈｕｔｄｏｗｎ要求を受け取ることに留意するべきである。有効期間オーナーはまた、この呼び出し中にその参照を所有する有効期間ドメインに解放する。

リソース・マネージャー（基本コンポーネント４１６など）は、同様に様々な方法で実装できる。これらマネージャーは、確定的にそのリソースを解放する停止プロセスに参加するための機構を含むことができる。このような機構は、リソース・マネージャーが停止通知に同意する機能を含むことができる。リソース・マネージャーは、停止通知のために、前述のＩＰｒｏｖｉｄｅＳｈｕｔｄｏｗｎインターフェースを使用してエンクロージング有効期間ドメインに登録できる。

さらに、リソース・マネージャーは、そのリソースを様々な異なる状況で解放するよう構成できる。例えば、有効期間ディレクタは、１以上のリソース・マネージャーがこの通知に従って動作するときにエラーを出しても、それに登録されたリソース・マネージャー全部に停止を通知することができる。ある例示的な事例では、停止が要求されたときに、リソース・マネージャーにはユーザー・インターフェース・プレゼンテーションの表示又は長時間実行する他の操作の開始を禁止することができる。さらに、リソース・マネージャーには、例外事項が発生することになりうる停止中の操作を禁止することができる。

最後の話題として、アプリケーションが何らかのエラーを出しているか否かを判別するために、有効期間ドメインの使用を補足する検査機構を構築できる。ある技術では、ランタイム時に、エンクロージング有効期間サービスがその入れ子関係を含めて判別できるということを推進するテストツール又はハーネスを構成できる。テストツール又はハーネスは不正確な方向に参照を確立する試みを検出できる。そのドメインのオーナー又は停止クリーンアップ機構の管理下にある有効期間ドメインへの参照を可能とする排除機構が望ましい。

別のアプローチは、デバッグビルドで「ゾンビ」チェックを行うことである。ここでの考えは、適切なランタイムツール（マイクロソフト社のCLRパフォーマンス・プロファイラーなど）を使用して、ある時点の作成中の参照を全て抽出し、さらに停止している有効期間ドメイン内に直接又は間接的に含まれるコンポーネントを探すことである。不活性ドメインを指す参照は、前記コンポーネントを「ゾンビ」にして、このドメイン内のコンポーネントを作動したまま維持する。チェック機構は有効期間サービスが定める方針の規則を破る参照を正確に突き止めるのに役立つ。このような技術は従来の技術では利用できない。なぜならこれら従来の技術は、コンポーネントのグループを本明細書で説明する有効期間ドメインに編成しないからである。

ゾンビを発見できることは、このオブジェクトが深刻な問題になることがあるため特に便利である。つまり、万が一（例えば、弱い参照のメソッドコールにより）実行のスレッドがゾンビに進入でもしたら、ゾンビは、典型的にはアプリケーションにゾンビではないインスタンスへのメソッドコールを作る。前記メソッドコールの対象は、一般的にこれらゾンビをアプリケーションに存在しないと理解して、そのためそれからの呼び出しに対応する準備がなされない。結果として様々な否定的な影響が起こることがある。

（Ｂ．２．エラー処理・ドメイン）
図５に、エラー処理サービス２１０を説明する手段として用いるエンティティドメイン・フレームワーク５００を示す。前述したように、エンティティドメインサービス２１０を実装するエンティティドメインは、エラー処理・ドメインと呼ばれる。従ってエラー処理サービス２１０は、一般的にエンティティドメイン・フレームワーク５００で発生するエラー、又は例えばエンティティドメイン内のインスタンスからその外部のインスタンスまでメソッドコールする結果として、あるいはエンティティドメイン・フレームワーク外で発生するエラーを受信して、処理するあらゆる機能をいう。

図５は、これに制限するものではなく、例示的なエンティティドメイン構造５００の一部を表し、ここでは説明のために提示する。エンティティドメイン・フレームワーク５００は、第１レベルのエラー処理・ドメイン５０４を定義する複合機能５０２を含む。第２複合機能５０６を第１複合機能５０２に結合する。この第２複合機能５０６は、第２エラー処理・ドメイン５０８を確立する。第３複合機能５１０も第１複合機能５０２に結合する。この第３複合機能５１０は、第３エラー処理・ドメイン５１２を確立する。第４複合機能５１４も、ネスト状に、第３複合機能５１０に結合する。この第４複合機能５１４は、第４エラー処理・ドメイン５１６を確立する。

エンティティドメイン階層５００は、各エラー処理・ディレクタを使って各エラー処理・ドメインに適用する様々なエラー処理サービスを実装できる。つまり、第１エラー処理・ドメイン５０４は、エラー処理・ディレクタ５１８を提供し、第２エラー処理・ドメイン５０８は、エラー処理・ディレクタ５２０を提供し、第３エラー処理・ドメイン５１２は、エラー処理・ディレクタ５２２を提供し、第４エラー処理・ドメイン５１４は、エラー処理・ディレクタ５２４を提供する。一般的に、エラー処理・ディレクタ（５１８、５２０、５２２、５２４）は、エンティティドメイン・フレームワーク５００で検出されるエラーに応答するタスクを行う。より具体的には、各エラー処理・ディレクタは、（例えば、この機能を実装するカスタムコードを提供することによって）カスタム・エラー処理方針を実装できる。つまり、様々なエラー処理・ドメインが様々なカスタム方針を適用できる。このことは有効期間ドメインとは対照的で、有効期間ドメインのある例示的な事例では、全てのドメインが同じ均一なサービスを実装する。

ここでもう一度、図５は、より包括的なエンティティドメイン・フレームワーク５００のサンプルのみを表すことができ、そのため完全なエンティティドメイン・フレームワーク５００は数多くのエラー処理・ドメインと関連するエラー処理・ディレクタ（図示せず）を含むことができる。

以下の例は、エンティティドメイン構造５００の操作を説明する。内包エラー処理・ドメイン５２６に関連したエラーを検出すると仮定する。図５はこのようなエラーをＸ５２６で図式的に表す。エラー処理手順はまず、エラーをエラー処理・ディレクタ５２４に送ることを伴う。エラー処理手順はまず、このエラーをローカル・エラー処理・ディレクタ５２４を使ってローカルで処理しようとする。しかし、エンティティドメイン・フレームワーク５００で採用するカプセル化のために、エラー処理・ディレクタ５２４は、エラー処理・ドメイン５１６がアプリケーション全体の中にあるより大きな状況を完全に「理解」（又は何らかの理解）ができていないかもしれない。この制限のため、エラー処理・ディレクタ５２４は検出したエラーをうまく処理できないかもしれない。より具体的には、エラー処理・ディレクタ５２４は、これらエラーが発生した全体を支配する状況を認識せずに、ローカル規模でうまく処理できる一定のクラスのエラーだけを処理するように構成されているといえる。そのため検出されたエラーがこれらのクラス内の一つではない場合、エラー処理・ディレクタ５２４はそれを処理できない。

エラー処理・ディレクタ５２４が検出したエラーをうまく処理できない場合、エラーのエスカレーションプロセスを行って、それによって検出したエラー処理のタスクを、次に「高い」エラー処理・ディレクタ５２２に先送りする。このエラー処理・ディレクタ５２２はさらに、検出したエラーをうまく処理できるか否かを判別する。処理できない場合、エラー処理・ディレクタ５２２は、さらにエラー処理タスクを次に「高い」エラー処理・ディレクタ５１８に先送りする。このプロセスは、エラーがうまく処理されるまで、又はプロセスがエンティティドメイン・フレームワーク５００のルートまで到達するまで繰り返し、その時点で「未処理エラー」となる。

（エラー処理サービスに基づいて）エラーを処理できるエラー処理・ディレクタは、様々な方法でエラーに対応できる。エラー処理サービスは典型的には、コンポーネントをあるリセットプロトコルのエラー処理・ドメインに使うことによってエラーを処理する。例えば、エラー処理は、処理前のある周知の良好な状態にリセットするために、エラー処理・ドメインの全てのデータベース接続に信号を送ることを伴うことができる。エラー処理はまた、アプリケーションの一部を停止する、一定の情報を補正する、エラーに関連する一定の情報を記録する等を伴うこともできる。エンクロージングエラー処理・ドメインが停止したら、その内包エラー処理・ドメインの全ても同様に停止する。

実装の点では、エラーシグナリングプロトコルをカプセル化するために、基本クラスＥｎｔｉｔｙＥｌｅｍｅｎｔとＥｎｔｉｔｙＣｏｍｐｏｓｉｔｅとは保護されたインスタンス方法ＨａｎｄｌｅＥｒｒｏｒを提供でき、この方法はエンティティがエンクロージングエラー処理サービスを発動するために呼び出せる。（それによって適切なエラーハンドラーが発動された）この機能は、前述の検索サービス（Ａ．３およびＡ．４の項を参照）を使用して動作する。より具体的には、ＨａｎｄｌｅＥｒｒｏｒは、検索サービスを使って適切なエラー処理サービスを、反復検索を行い、さらに適切なエラー処理サービスを呼び出すことによって操作する。

（Ｂ．３．その他サービスドメイン）
前述のサービスおよび関連エンティティドメインは、あらゆる種類のアプリケーションに適用できる。そのためこれらサービスは汎用の適用性がある。その他のサービスは、あるアプリケーション固有のアーキテクチャを補足するよう特別に作られるものもある。

（Ｃ．操作方法）
図６〜８は前述の主題の特徴をフローチャート形式でまとめたものである。説明し易くするために、一定の操作は一定の順番で行う個別の工程を構成するように記述する。（かかる実装は、例示的で制限するものではない）本明細書で説明する一定の工程はまとめて１操作で行うことができ、一定の工程は本明細書に記載する例で採用する順番とは異なる順番でも行える。

図６は、有効期間管理サービスをもつエンティティドメイン・フレームワークを作成するためのプロセスを説明する。工程６０２で、アプリケーションはアプリケーションのエンティティドメイン全体を定義する１以上の初期のルート型のオブジェクトを追加する。その後、工程６０４で、アプリケーションは順次エンティティドメインをエンティティドメイン・フレームワークに追加する。アプリケーションはこの工程６０４を、関連するドメインを効率的に定義しながら、エンティティドメイン・フレームワークに複合機能を追加して行う。アプリケーションは、その各複合機能に結合する基本コンポーネントを追加してエンティティドメインを移植できる。従って、アプリケーションはエンティティドメイン・フレームワークをネスト状のトップダウン形式で構築する。トップダウン構造は、フローチャートの右側のフレームワークの断片にも図示している。前述のプロセスは、工程６０６で、アプリケーションが最終的にその全体を停止するまで続ける。図６には描かれていないが、アプリケーションはもはや必要なくなったコンポーネントを削除するために、作成に類似した別の操作を行う。

有効期間サービス２０８の場合、アプリケーションは、多くの状況で個別の内包ドメインを作成することを決めることがある。例えば、コンポーネントがそのエンクロージング（親）有効期間ドメインより潜在的に有効期間が短い場合、又はコンポーネントが停止の明示的な通知を要求する場合等、（開発者の設計目的に基づき）アプリケーションは新たに追加したコンポーネントのコレクションを個々の有効期間ドメインに分類することに決めることがある。有効期間を確定的かつ独立して停止するのが望ましい場合、アプリケーションは有効期間ドメインに有効期間オーナーも割り当てるであろう。オーナーは、停止を開始するエージェントとしての役目を果たす。また、オーナーは、有効期間ドメイン外のエンティティから有効期間ドメイン内のコンポーネントに指示するリンクを切断するエージェントである。

図７に、基本的な検索サービス２０４の操作を示す。工程７０２では、ローカルエンティティドメインが、エラー処理サービスなどのあるサービスの要求を受け取る。工程７０４で、ローカルエンティティドメインは、要求されるサービスを提供できるか否かを判別する。提供できるなら、ローカルエンティティドメインは、工程７０６で要求されるサービスを提供する。提供できないなら、工程７０８で、検索サービス２０４がこのサービスを照会できる他のエンクロージングドメインがあるか否かを判別する。この照会の否定的な応答には２つの状況がある。最初のケースは、検索サービス２０４が要求されるサービスを見つけられずに、エンティティドメイン・フレームワークのルートに進んでいる場合に起こる。２番目のケースは、開発者がドメインを分離ドメインとして指定している場合に起こり、これはさらに内包ドメインの連鎖まで進むのをブロックする効果がある。上記ケースのいずれの場合も、工程７１０で、検索サービスは、要求されるサービスが利用できないと判断する。しかし、検索サービスが、エンクロージング親エンティティドメインに進めると判断する場合には、工程７１２でそのようにする。その時、エンクロージング親エンティティドメインに関して、図７に示す操作シーケンスを繰り返す。反復検索手順の操作も、フローチャートの左側のドメインの断面に図示する。前述の動作を実行するある方法は、ＬｏｏｋｕｐＳｅｒｖｉｃｅと呼ばれる基本クラス法である。この方法は連続的なレベルで、階層を登りながら反復的に行う。これは、子のいないコンポーネントが階層の高次レベルが提供するサービスの「知識」をもつという意味で、連鎖を登る１種の「ブラインド」である。コンポーネントは、コンポーネントがあるバスで要求を出したのと同じように、ＬｏｏｋｕｐＳｅｒｖｉｃｅに依存する。つまり、バス要求の場合と同様に、コンポーネントは、存在すれば、どの「アクター」が要求を満たすかは認識せず、問題にならない。

最後に、図８に、有効期間サービスが統制するエンティティドメイン・フレームワークの例示的な停止手順を図示する。工程８０２では、エンティティドメイン・フレームワーク内のあるエンティティドメインが停止の要求を受け取る。工程８０４で、停止要求は、Ｂ．１項で完全に列挙した多数のクリーンアップ操作をトリガーする。一般的に、これら操作は、停止要求を最終的なエンクロージング有効期間ドメイン内の内包有効期間ドメイン全てに伝えることを伴うであろう。それから停止は、最も深くネストされた有効期間ドメインから始めて、反復的に進む。各レベルで、停止は多数の下位工程を含むことができ、その一部を工程８０４の右側の拡大リストに列挙する。ある下位工程では、オーナーは、有効期間ドメインを指す有効期間ドメイン外からの全ての参照を切断できる。別の下位工程では、有効期間ディレクタは、以前に停止通知を受け取るために登録していた有効期間ドメイン内の全てのリソース・マネージャーに停止通知を送ることができる。

工程８０４で、ガーベッジコレクションは、（アプリケーションがもはや必要としないものを指す）それらを指す参照をもたないシステムメモリからのオブジェクトの削除を行うことができる。ある実装では、（工程８０４における）ガーベッジコレクションは、正式には有効期間管理サービスが提供する停止プロトコルの一部ではなく、そのため有効期間管理サービスにより必ずしもトリガーされない。言い換えると、従来のガーベッジコレクションは、本明細書で説明する有効期間サービスと関連して使うことができる。しかし、従来の方法とは異なり、ガーベッジコレクションは、（系統的かつ予測可能な停止の操作シーケンスを定義する）固有の確定的な停止プロトコルにより、もはや使用しなくなったオブジェクト全部がガーベッジコレクションの対象となるのがより確実である点で優れている。

（Ｄ．例示的なコンピュータ環境）
図９は、エンティティドメイン・フレームワークのパラダイムに基づいてアプリケーションプログラムを実行するために使用できるある例示的なコンピュータ環境９００に関する情報を提供する。

コンピュータ環境９００は、汎用タイプのコンピュータ９０２とディスプレイ装置９０４を備える。しかし、コンピュータ環境９００は他の種類のコンピュータ機器を備えることができる。例えば、図示していないが、コンピュータ環境９００は携帯型又はラップトップ型の機器、セットトップボックス、ゲーム操作機、拡張型コンピュータ、大型汎用コンピュータ、レンダリング装置に埋め込まれた論理機能等々を備えることができる。また、図９は説明しやすくするためにまとめたコンピュータ環境９００の要素を示す。しかし、コンピュータ環境９００は分配型の処理構成を採用することもできる。分配型のコンピュータ環境では、コンピュータリソースは環境全体に物理的に分散することができる。

例示的なコンピュータ９０２は１以上のプロセッサ又は処理装置９０６と、システムメモリ９０８と、バス９１０とを備える。バス９１０は様々なシステムコンポーネントを互いに接続する。例えば、バス９１０はプロセッサ９０６をシステムメモリ９０８に接続する。バス９１０は、メモリバスやメモリコントローラー、周辺バス、アクセラレーテッド・グラフィックス・ポート、多様なバスアーキテクチャのいずれかを使用したプロセッサやローカルバスなど、あらゆる種類のバス構造又はバス構造の組合せを使用して実装できる。

コンピュータ９０２は、様々な種類の揮発性および不揮発性媒体など、そのそれぞれが取外し可能又は固定の様々なコンピュータ読み取り可能媒体を備えることもできる。例えば、システムメモリ９０８は、ランダムアクセスメモリ（ＲＡＭ）９１２などの揮発性メモリ、読取専用メモリ（ＲＯＭ）９１４などの不揮発性メモリの形態のコンピュータ読み取り可能媒体を備える。ＲＯＭ９１４は、起動時など、コンピュータ９０２内部のエレメント間の情報の転送を助ける基本ルーチンを内蔵する入出力システム（ＢＩＯＳ）９１６を備える。ＲＡＭ９１２は典型的には、プロセッシングユニット９０６で即座にアクセスできる形態のデータおよび/又はプログラムモジュールを内蔵する。

他の種類のコンピュータ記憶媒体は、固定の不揮発性磁気媒体に読取りと書き込みをするためのハードディスクドライブ９１８と、取り外し可能な不揮発性磁気ディスク９２２（例えば、「フロッピー（登録商標）ディスク」）に読み取りと書き込みをするための磁気ディスクドライブ９２０と、ＣＤ−ＲＯＭ、ＤＣＤ−ＲＯＭ、又はその他光学媒体などの取り外し可能な不揮発性光学ディスク９２６に読取りおよび/又は書き込みをするための光学ディスクドライブ９２４とを備える。ハードディスクドライブ９１８、磁気ディスクドライブ９２０、光学ディスクドライブ９２４はそれぞれ１以上のデータ媒体インターフェース９２８でシステムバス９１０に接続する。代わりに、ハードディスクドライブ９１８、磁気ディスクドライブ９２０、光学ディスクドライブ９２４は、ＳＣＳＩインターフェース（図示せず）又はその他連結機構でシステムバス９１０に接続することができる。図示していないが、コンピュータ９０２は、磁気カセットやその他磁気記憶装置、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）やその他光学記憶装置、電気的に消去して再書き込み可能な読出し専用メモリ（ＥＥＰＲＯＭ）など、他の種類のコンピュータ読み取り可能媒体を備えることができる。

一般的に、前述のコンピュータ読み取り可能媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、およびコンピュータ９０２が使用するためのその他のデータの不揮発性記憶装置を提供する。例えば、読み取り可能媒体はオペレーティングシステム９３０、アプリケーションモジュール９３２、その他プログラムモジュール９３４、プログラムデータ９３６を記憶できる。この媒体の一部も、前項で説明したオブジェクト管理機能の特徴を実装するための記憶装置を提供できる。つまり、前述したエンティティドメイン・フレームワークが統制するランタイムコンポーネントを記憶するためにメモリを割り当てることができる。

コンピュータ環境９００は、様々な入力装置を備えることができる。例えば、コンピュータ環境９００は、命令や情報をコンピュータ９０２に入力するためのキーボード９３８やポインティングデバイス９４０（例えば、「マウス」）を備える。コンピュータ環境９００は、マイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、シリアルポート、スキャナ、カード読取装置、デジタル又はビデオカメラなど、他の入力装置（図示せず）を備えることができる。入出力インターフェース９４２は入力装置をプロセッシングユニット９０６に連結する。より一般的には、入力装置は、パラレルポート、シリアルポート、ゲームポート、ユニバーサルシリアルバス（ＵＢＳ）ポート等などあらゆる種類のインターフェースやバス構造を介してコンピュータ９０２に連結できる。

コンピュータ環境９００は、ディスプレイ装置９０４も備える。ビデオアダプタ９４４はディスプレイ装置９０４をバス９１０に連結する。ディスプレイ装置９０４に加えて、コンピュータ環境９００は、スピーカー（図示せず）、プリンタ（図示せず）等などの他の出力用周辺装置を備えられる。

コンピュータ９０２は、リモートコンピューティング装置９４６など、１以上のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作する。リモートコンピューティング装置９４６は、汎用パーソナルコンピュータ、携帯型コンピュータ、サーバー、ゲーム機、ネットワーク拡張装置などあらゆる種類のコンピュータ機器から構成できる。リモートコンピューティング装置９４６はコンピュータ９０２に関して前述した特徴の全て、又はそのある部分集合を備えられる。

ＷＡＮ、ＬＡＮ等など、コンピュータ９０２をリモートコンピューティング装置９４６に連結するにはあらゆる種類のネットワーク９４８を使用できる。コンピュータ９０２は、ネットワークインターフェース９５０を介してネットワーク９４８に連結し、これはブロードバンド接続、モデム接続、ＤＳＬ接続、又はその他の接続方法を利用できる。図示していないが、コンピュータ環境９００は、コンピュータ９０２をリモートコンピューティング装置９４６に接続するために、ワイヤレス通信機能を提供できる（例えば、変調無線信号、変調赤外線信号など）。

最後に、本明細書では多数の例を選択肢（例えば、ケースＡ又はケースＢ）として提示した。加えて、本明細書があらゆる場合に結合した事例を明示的に述べていなくても、本明細書は１つの実装で選択肢を組み合わせた事例を含む（例えば、ケースＡおよびケースＢ）。

より一般的には、本発明は構造的な特徴および/又は方法論的な行為に固有の言語で記述してきたが、当然ながら添付の請求項で定義される本発明は記述した具体的な特徴や行為に必ずしも制限されるものではない。むしろ、具体的な特徴や行為は請求される発明を実施する例示的な形態として開示される。

エンティティドメイン・フレームワークに入れるコンポーネントの例示的な編成を示す図である。 図１のエンティティドメイン・フレームワーク内で利用できるサービスの例示的なコレクションを示す図である。 図１のエンティティドメイン・フレームワーク内のサービスを検索するために使用できる例示的な検索機能の操作を示す図である。 図１のエンティティドメイン・フレームワークを有効期間管理タスクに例示的に適用したものを示す図である。 図１のエンティティドメイン・フレームワークをエラー処理タスクに例示的に適用したものを示す図である。 図１のエンティティドメイン・フレームワークを作成するための例示的な手順を示す図である。 図１のエンティティドメイン・フレームワーク内のサービスを検索するための例示的な手順を示す図である。 図１のエンティティドメイン・フレームワークの一部を停止するための例示的な手順を示す図である。 図１に図示するエンティティドメイン・フレームワークの特徴を実装するための例示的なコンピュータ環境を示す図である。

符号の説明

９００ コンピュータ環境
９０２ コンピュータ
９０４ ディスプレイ装置
９１８ ハードディスクドライブ
９２０ 磁気ディスクドライブ
９２４ 光学ディスクドライブ

Claims (40)

1. ランタイム時のコンポーネントのコレクションを含む機械読み取り可能なコードを実行するための方法であって、前記方法は、
   エンティティドメインが規定の方針に従い、少なくとも１つのコードコンポーネントを階層構造にしたエンティティドメインに分類する工程と、
   前記少なくとも１つのコードコンポーネントをエンティティドメインの方針に従って管理する工程と
   を備えたことを特徴とする方法。
2. 請求項１に記載の方法であって、前記エンティティドメインは、前記少なくとも１つのコンポーネントを前記エンティティドメインに結合する複合機能を提供することを特徴とする方法。
3. 請求項１に記載の方法であって、前記分類する工程は、各方針に従う複数のエンティティドメインを提供する工程からなることを特徴とする方法。
4. 請求項３に記載の方法であって、前記複数のエンティティドメインは、トップダウン形式で構成されることを特徴とする方法。
5. 請求項３に記載の方法であって、前記複数のエンティティドメインは、互いに親子関係としてリンクすることを特徴とする方法。
6. 請求項３に記載の方法であって、前記エンティティドメインの各々は、前記複数のエンティティドメインを結合して階層的なエンティティドメイン・フレームワークにする各複合機能を提供することを特徴とする方法。
7. 請求項６に記載の方法であって、前記複数のエンティティドメインによって提供される前記複合機能は、前記エンティティドメイン・フレームワークを介して要求を送ることができる結合機構を集合的に定義することを特徴とする方法。
8. 請求項７に記載の方法であって、特定のエンティティドメインに関連する要求を、
   （ａ）前記特定のエンティティドメインが要求を満たせるか否かを判別し、満たせるなら前記特定のエンティティドメインで要求を処理し、
   （ｂ）前記特定のエンティティドメインが要求を満たせないなら、前記特定のエンティティドメインの親エンティティドメインが要求を満たせるか否かを判別し、満たせるなら前記親エンティティドメインで要求を処理し、
   ｃ）前記親エンティティドメインが要求を満たせない場合、要求が満たされるか、又は要求が満たされないと判断されるまで（ｂ）の操作を繰り返して処理することを特徴とする方法。
9. 請求項１に記載の方法であって、前記エンティティドメインが提供する方針は、前記少なくとも１つのコンポーネントの有効期間管理に関係し、前記管理する工程が前記少なくとも１つのコンポーネントの確定的な停止を前記有効期間管理の方針に基づいて統制する工程からなることを特徴とする方法。
10. 請求項９に記載の方法であって、前記エンティティドメインは、複数のコンポーネントを含み、前記管理する工程が前記複数のコンポーネントを単体として停止する工程からなることを特徴とする方法。
11. 請求項９に記載の方法であって、前記エンティティドメインは、少なくとも１つの内包ドメインを含むエンクロージング有効期間ドメインであり、前記管理する工程が前記エンクロージング有効期間ドメインの前に前記少なくとも１つの内包有効期間ドメインの停止を調整することを特徴とする方法。
12. 請求項９に記載の方法であって、前記管理する工程は、通知を受け取るために事前に登録していた少なくとも１つのコンポーネントに停止通知を提供する工程を含むことを特徴とする方法。
13. 請求項９に記載の方法であって、前記有効期間管理の方針は、前記エンティティドメインの外から提供される有効期間オーナー機能を収容し、前記管理する工程が前記少なくとも１つのコンポーネントの停止を開始する前記オーナー機能を使用する工程を含むことを特徴とする方法。
14. 請求項９に記載の方法であって、前記管理する工程は、前記エンティティドメインの外部のオブジェクトからの参照リンクを前記エンティティドメインに分離する工程を含むことを特徴とする方法。
15. 請求項１４に記載の方法であって、前記有効期間管理の方針は、有効期間オーナー機能を収容し、前記管理する工程が分離を行うために前記オーナー機能を使用する工程を含むことを特徴とする方法。
16. 請求項１に記載の方法であって、前記エンティティドメインが提供する前記方針は、エラー処理管理に関係し、前記管理する工程が前記エラー処理管理の方針に基づいて、前記エンティティドメインに関連するエラーの系統的な処理を統制する工程を含むことを特徴とする方法。
17. 請求項１６に記載の方法であって、前記エンティティドメインは、複数のコンポーネントを含み、前記管理する工程が前記複数のコンポーネントの全てに前記同じエラー処理管理方針を適用する工程を含むことを特徴とする方法。
18. 請求項１６に記載の方法であって、前記エンティティドメインは、少なくとも１つのエンクロージングエンティティドメイン内の内包エンティティドメインであり、前記管理する工程が、前記内包エンティティドメインがエラー処理タスクを十分に処理できない場合、前記少なくとも１つのエンクロージングエンティティドメインに前記エラー処理タスクを留保する工程からなることを特徴とする方法。
19. 請求項１に記載の分類する工程と管理工程とを実装することを特徴とする機械読み取り可能媒体。
20. 請求項１に記載の分類する工程と管理工程とを実装するように構成された論理を有することを特徴とする装置。
21. エンティティドメイン・フレームワークを実装するデータ構造を提供する機械読み取り可能媒体であって、前記データ構造は、
    少なくとも１つのコードコンポーネントを含む階層構造のエンティティドメインと、
    前記少なくとも１つのコンポーネントに適用する規定の方針を定義する、エンティティドメインに関連するサービス機能と、
    を備えたことを特徴とする機械読み取り可能媒体。
22. 請求項２１の機械読み取り可能媒体において、エンティティドメインが前記少なくとも１つのコンポーネントをエンティティドメインに結合する複合機能を提供することを特徴とする機械読み取り可能媒体。
23. 請求項２１に記載の機械読み取り可能媒体であって、前記エンティティドメイン・フレームワークは、各方針を定義するそれぞれサービス機能を有する複数のエンティティドメインを含むことを特徴とする機械読み取り可能媒体。
24. 請求項２３に記載の機械読み取り可能媒体であって、前記複数のエンティティドメインは、互いに親子関係においてリンクされることを特徴とする機械読み取り可能媒体。
25. 請求項２３に記載の機械読み取り可能媒体であって、前記エンティティドメインの各々は、前記複数のエンティティドメインを互いに結合して前記エンティティドメイン・フレームワークを定義するそれぞれの複合機能を提供することを特徴とする機械読み取り可能媒体。
26. 請求項２５に記載の機械読み取り可能媒体であって、前記複数のエンティティドメインによって提供される前記複合機能は、エンティティが前記エンティティドメイン・フレームワークを介して要求を送ることのできる結合機構を集合的に定義することを特徴とする機械読み取り可能媒体。
27. 請求項２１に記載の機械読み取り可能媒体であって、前記エンティティドメインによって提供される前記方針は、前記少なくとも１つのコンポーネントの有効期間管理に関係し、前記有効期間管理の方針に基づいて少なくとも１つのコンポーネントの確定的な停止を統制することを特徴とする機械読み取り可能媒体。
28. 請求項２１に記載の機械読み取り可能媒体であって、前記エンティティドメインによって提供される前記方針は、エラー処理管理に関係し、前記エラー処理管理の方針に基づく前記エンティティドメインに関連するエラーの系統的な処理を統制することを特徴とする機械読み取り可能媒体。
29. ランタイム時にアプリケーションの一部を実行するコンポーネントを記憶するメモリと、
    少なくとも１つのコードコンポーネントを階層構造のエンティティドメインに編成して、前記少なくとも１つのエンティティドメインをメモリに記憶し、および
    前記エンティティドメインの方針に従って前記少なくとも１つのコードコンポーネントを管理するように構成された論理を有する
    命令を実行するように構成されたプロセッシング装置と
    を備えたことを特徴とするアプリケーションを提供する装置。
30. 請求項２９に記載の装置であって、前記エンティティドメインは、前記少なくとも１つのコンポーネントを前記エンティティドメインに結合する複合機能を提供することを特徴とする装置。
31. 請求項２９に記載の装置であって、複数の各方針に従う複数のエンティティドメインをさらに備えたことを特徴とする装置。
32. 請求項３１に記載の装置であって、前記複数のエンティティドメインは、互いに親子関係においてリンクされることを特徴とする装置。
33. 請求項３１に記載の装置であって、前記エンティティドメインの各々は、前記複数のエンティティドメインを階層的なエンティティドメイン・フレームワークに結合するそれぞれの複合機能を提供することを特徴とする装置。
34. 請求項３３に記載の装置であって、前記複数のエンティティドメインによって提供される前記複合機能は、エンティティが前記エンティティドメイン・フレームワークを介して要求を送ることのできるバスを集合的に定義することを特徴とする装置。
35. 請求項２９に記載の装置であって、前記エンティティドメインによって提供される方針は、前記少なくとも１つのコンポーネントの有効期間管理に関係し、前記有効期間管理の方針に基づく前記少なくとも１つのコンポーネントの確定的な停止を統制することを特徴とする装置。
36. 請求項２９に記載の装置であって、前記エンティティドメインによって提供される前記方針は、エラー処理管理に関係し、前記エラー処理管理の方針に基づく前記エンティティドメインに関連するエラーの系統的な処理を統制することを特徴とする装置。
37. ランタイム時のコンポーネントのコレクションを含む機械読み取り可能コードを実行する方法であって、前記方法は、
    エンティティドメインが有効期間管理方針に従い、少なくとも１つのコードコンポーネントを階層構造の前記エンティティドメインに分類する工程と、
    前記有効期間管理方針に従い、前記エンティティドメインを停止する工程と
    を備えたことを特徴とする方法。
38. 請求項３７に記載の方法であって、前記有効期間管理の方針に従い前記エンティティドメインを停止する工程は、
    前記エンティティドメイン内に含まれるあらゆる内包有効期間ドメインの反復的な停止を調整する工程と、
    通知を受け取るために事前に登録していた少なくとも１つのコンポーネントに停止通知を提供する工程と、
    前記エンティティドメイン外のオブジェクトからの参照リンクを前記エンティティドメインに分離するための工程と
    を含むことを特徴とする方法。
39. ランタイム時のコンポーネントのコレクションを含む機械読み取り可能コードを実行する方法において、前記方法は、
    エンティティドメインがエラー処理管理の方針に従い、少なくとも１つのコードコンポーネントを階層構造のエンティティドメインに分類する工程と、
    前記エラー処理管理の方針に基づきエンティティドメインに関連するエラーを処理する工程と
    を備えたことを特徴とする方法。
40. 請求項３９に記載の方法であって、前記エンティティドメインは、少なくとも１つの他のエンクロージングエンティティドメイン内の内包エンティティドメインであり、前記エラーを処理する工程が、前記内包エンティティドメインがエラー処理タスクを十分に処理できない場合、前記エラー処理タスクを前記少なくとも１つのエンクロージングエンティティドメインに先送りする工程からなることを特徴とする請求項３９に従う方法。
    

Images