CN1755617A - 实体域 - Google Patents

Abstract

描述用于将应用程序的运行时组件组织到实体域框架中的策略。实体域框架包括一或多个以分层方式排列的实体域。每实体域进一步将一或多个组件以分层方式分组在一起。每个实体域可以包括一或多个提供政策给实体域内组件的服务。合成功能将框架耦合在一起，并且进一步提供类似于总线的机制，由此实体可以通过层次结构将服务请求转送直到一个被认为满足请求的域。由实体域框架提供的示例***包括生存期管理服务，出错处理服务，等等。分层结构提供有效方式来向将以共同的周境共享功能的组件分组揭示功能，而不要求代价高而且复杂的服务与组件的原子耦合或者服务实例的复制。

Description

实体域

技术领域

本发明涉及管理机器可读代码组件的改进策略。

背景技术

应用程序可以使用代码组件集合执行它们规定的任务。在面向对象的说明性案例中，例如，应用程序可以在它们的源代码中分配不同的类，这些类可以在运行时使用，以提供执行所定义任务的功能。即，在运行时，计算机器可以实例化这些类，以提供特定的对象(也称为“实例(instance)”)。这些对象存储在计算机器的存储器的已分配部分。在这些对象已经服务于它们相应的目的并且不再需要之后，计算机器可以运行所谓的垃圾收集功能，以从存储器中移除这些对象，因而为其它对象提供创建和存储的空间。

在应用程序的运行时执行中的任何给定时间，计算机器的存贮器可以预期存储运行时代码组件的大集合。这些代码组件必须相互交互以执行规定的任务。为此，应用程序将提供把这些代码组件“线连接(wire)”在一起。线连接允许组件引用其它组件，使得组件可以在它们之间交换信息以执行它们分派的任务。

应用程序一般在创建、管理和切断这类组件之间线连接的链接时应用某种协议。在外部，这样一个协议导致由最终用户使用的用户界面展示的逻辑流。然而在内部，协议可产生在本质上非结构化的组件互相依赖的复杂网状结构。

许多困难源于管理代码组件实例的传统技术。例如，代码开发者在理解应用程序的内部运行时行为时有很大的困难。这会阻止开发者主动地测试应用程序，以发现潜在的软件错误，并且还会阻止开发者成功地揭示还没有检测到的错误源。通常，在运行时显示的软件错误(与例如编译时间相反)经常具有滞后性，只在应用程序执行过程中出现某些条件时才发生。因而，在传统方法中，在将程序向顾客发货之前揭示这些错误是困难的。在其它情况下，应用程序可用无错误方式提供它的服务，但因为各种问题，它以次佳的方式来这么做(即，通过使用比应该要求的更多存储器，或者花费比应该要求的更多时间)。

一个特别令人烦恼的错误源源自传统的垃圾收集技术。这些传统技术通过跟踪指向对象的引用链接来确定对象是否不再需要。当链接的数量达到零，则垃圾收集功能处置该对象。该技术可以强加了复杂的记帐需求，因为它必须维护许多引用链接的准确计数。由于这种复杂性，因此该记帐任务经常是错误源。共同的错误导致当一个对象不再有任何用途时，但仍然有实例保持引用链接到该对象。这就起到了当一个对象应该被移除时仍然保持它存在的效果，从而创建一种“僵(zombie)”实例。不用说，这种错误可以导致各种问题，其范围从低劣的存储器利用率(例如“资源泄漏(resouce leak)”到程序崩溃。没有很好地配备传统的策略来解决这些类型的问题。即，因为这些策略在运行时依赖于实例的非结构化网状结构，这是代码开发者很少了解的，它变得难以检测到在该网状结构内收集的这类“僵”实例的发生。

而且，传统方法的使用阻止开发者编写有效地在运行时提供某种功能给组件组合。例如，开发者可试图通过使用各种范例将某种功能“线连接”至这些需要该功能的组件来提供该种功能。然而，将服务原子耦合(atomistic couple)到单独的组件代价很大，因为它要求描述这些独立链接的引用信息存贮。而且，如本发明所意识到的，已知的方法未能提供合适的机制来允许依赖于相同功能的组件(并且因此共享一个共同的“周境”)来以有效方式访问这样的功能。共享上下文的常规技术(诸如通过使用全局变量)在相对粗粒度的基础提供共享(例如，在过程或者线程等级上)，并且因此不足以解决这个问题。

对于至少这些说明性和示例性原因，存在对在运行时管理代码组件的更有效策略，它们消除或减少上述一或多个问题。

发明内容

按照一个示例性实现，描述一种运行包括运行时组件的集合的机器可读代码的方法。该方法包括将至少一个代码组件分组到分层结构化的实体域中，其中，实体域服从至少一个规定政策(下面为了简单称为单数的“规定政策(prescribed policy)”)，并且按照该实体域的政策管理该代码组件。

按照另一个示例性方面，分组包括提供服从相应政策的多个实体域。

按照另一个示例性方面，多个实体域以父子关系链接在一起。

按照另一个示例性方面，每个实体域提供相应于合成功能，将多个实体域耦合到分层的实体域框架中。

按照另一个示例性方面，由多个实体域提供的合成功能共同地定义一个耦合机制，通过它实体可通过实体域框架发送请求。

按照另一个示例性方面，在一个特定实体域内产生的请求按下面的步骤处理：(a)判定特定实体域是否能够满足请求，如果是，则在特定实体域处理请求；(b)如果特定实体域不能满足请求，判定特定实体域的父实体域是否能够满足请求，并且如果是，则在父实体域处理请求；以及(c)如果父实体域不能满足请求，则重复操作(b)直到满足请求或者确定无法满足请求。

按照另一个示例性方面，由实体域提供的上述政策属于上述至少一个组件的生存期管理，并且管理包括基于生存期管理政策控制上述至少一个组件的确定性关闭。

按照另一个示例性方面，按照生存期管理政策的实体域的关闭包括：协调包括在实体域内的任何嵌套的生存期域的递归关闭；提供关闭通知给至少一个已经预先注册接收这类通知的组件；以及切断在实体域外的对象到实体域中的引用链接。

按照另一个示例性方面，由实体域提供的上述政策属于出错处理管理，以及其中，管理包括基于出错处理管理政策控制与上述实体域相关联的错误的顺序处理。

按照另一个示例性方面，实体域是在至少一个其它封闭实体域内的嵌套实体域，以及其中，管理包括如果嵌套实体域不能符合要求地处理出错处理任务，则将出错处理任务推迟到上述至少一个封闭实体域。

下面描述其它示例性实现。

附图说明

图1例示组件在实体域框架中的示例性组织。

图2例示在图1的实体域框架中可得到的服务的示例性集合。

图3例示可以用于在图1的实体域框架中查找服务的示例性查找功能的操作。

图4例示图1的实体域框架示例性地应用程序于程序生存期管理的任务。

图5例示图1的实体域框架示例性地应用程序于出错处理的任务。

图6例示创建图1的实体域框架的示例性过程。

图7例示在图1的实体域框架内查找服务的示例性过程。

图8例示关闭图1的实体域框架的一些部分的示例性过程。

图9例示实现图1所示实体域框架诸方面的示例性计算机器环境。

遍及本说明书和附图使用相同的数字引用相同的组件和特征。100系列的数字指最初在图1中出现的特征，200系列的数字指最初在图2中出现的特征，300系列的数字指最初在图3中出现的特征，等等。

详细说明

下面的描述阐述将组件分组到实体域框架和使用该框架管理这些组件的策略。实体域框架可以将这些组件组织到实体域的分层结构中。每个实体域可以包括一或多个元素组件和合成功能。合成功能将元素组件在一个实体域内分组在一起。实体域框架还将相应的实体域的合成功能耦合在一起，以创建实体域的分层结构。

每个实体域可以提供一或多个服务。通常，阻止实体直接与实体域框架交互。在实体域框架内的实体可以使用查找功能访问服务。查找功能通过经由分层结构上移访问服务，成功地判定每个实体域是否能够提供所请求的服务。

在一个示例性应用中，生存期管理服务被应用于实体域，因此建立生存期域。生存期服务控制在生存期域内的实体在关闭时被移除的方式。每个生存期域包括一个生存期指挥器来实现生存期服务。而且，每个生存期域可以直接由生存期所有者来管理。生存期域可以嵌套在其它生存期域中。生存期指挥器通过关闭其嵌套生存期域，从最深嵌套生存期域开始，来协调其封闭生存期域的关闭。生存期指挥器还发出关闭通知给任何已经预先注册接收关闭通知的组件(下面称为“注册组件(registrant component)”)。一种注册组件是资源管理器，如名字所表示的，用作管理某种资源(例如，数据库资源等)的角色。所有者用于启动关闭操作的目的。所有者还履行切断在其生存期域之外的对象指到生存期域中的链接的角色。

在另一个示例性应用中，错误管理服务被应用于实体域，因此建立出错处理域。每个出错处理域包括一个出错处理指挥器以实现出错处理服务。与生存期域一样，实体域框架可以提供嵌套出错处理域。嵌套出错处理指挥器可通过判定它是否能够在本地使用其本地出错处理域处理错误来检测错误。如果这不能完成，则出错处理指挥器将处理错误的工作推迟到封闭出错处理域，它可能能够成功地处理错误，并且如果不能，则将错误传递给它自己的封闭出错处理域。能够成功处理错误的出错处理域可以采取任何纠正动作，诸如关闭应用的部分(或全部)。

实体域框架具有许多优点。按照一个优点，实体域设计使代码开发者能够较好地理解在运行时对于应用程序发生了什么。这使代码开发者能够更容易地测试应用程序，并且更容易地发现检测到的错误的原因。这个特征因此具有产生具有较少错误的代码的可能性。

按照另一个优点，实体域设计提供更可靠的技术来关闭一个应用程序的一些部分。即，在此所述的技术(例如，包括结合所有者通知的嵌套关闭)提供有顺序的协议用于***地和可预言地在关闭时释放组件。该技术还较好地保证移除对被关闭的组件的引用。这与在背景技术章节中所述的使用各种常规垃圾收集协议的已知技术形成对比。这些技术不采用在此所述的实体域结构的优势，并且因此具有在关闭时以无序方式释放组件或根本未能释放组件的可能性。这增加了使组件保持不适当地运行的可能性，因此产生“僵”组件。

按照另一个优点，在此所述的关闭机制提供一个可通用的关闭协议，它可以应用于***内各种各样的设计空间。这与定制设计为仅仅用于特定的相应设计空间的已知关闭协议形成对比。

按照另一个优点，设计提供一个结构化且有效的机制来将一个政策向应用程序内利用该政策(并且因此共享相同的“上下文”)的相应组件分组揭示。即，通过查找功能，在实体域内的组件可以利用使其共同可用于域的服务。这可以帮助减少组件之间复杂的对等非结构化联系的总数。而且，设计包括封装条款(provision)，阻止组件直接与实体域框架的其它方面交互。

通过阅读下面的描述，其它优点对于本领域的熟练技术人员是显而易见的。

关于术语，术语“组件(component)”指配置为执行规定任务的对象。在下面的讨论中最经常出现的上下文中，组件是面向对象编程范例内的对象(或实例)。在虚拟编程环境的上下文中提供其它特定的例子，诸如Microsoft的.NET编程环境(由Washington(华盛顿)，Redmond(雷德蒙德)的Microsoft公司提供的)。.NET编程环境通过产生编译的中间代码来操作，随后使用公共语言运行库(CLR)功能的服务在运行时执行代码。然而，这些例子仅仅是示例性和说明性的；在此描述的原理可以应用于在任何技术平台的上下文中的任何编程范例。

本说明书包括下列章节。章节A描述示例性实体域框架。章节B描述可以应用于实体域框架的示例***。章节C描述一系列示例性流程图，说明实体域框架的操作的某些方面。以及章节D描述实现实体域框架的示例性计算机环境。

A.示例性***

通常，任何在此描述的功能可以使用软件、固件(例如，固化的逻辑电路***)、手工处理或者这些实现的组合来实现。在此使用的术语“模块(module)”、“组件(component)”、“功能(functionality)”和“逻辑(logic)”通常代表软件、固件或软件与固件的组合。在软件实现的情况下，术语“模块”、“组件”、“功能”或“逻辑”代表在一或多个处理设备(例如，一或多个CPU)上执行时完成指定任务的程序代码。程序代码可以存储在一或多个固化的和/或可移动的计算机可读存储器设备中。存储器可以用分布式方式在一或若干位置处提供。

A.1实体域框架概述

图1示出组件到实体域框架100中的示例性分层组织。在运行时表明该组织。运行时指在执行应用(简称为“应用(application)”)时编程组件的实例化。例如，在示例性和非限制性的面向对象编程范例的情况下，运行时可以包括在需要时从类集合创建对象，存储这些对象于存储器堆中，并且随后在不再需要它们时使用垃圾收集功能移除这些对象。在这种情况下，在应用正在运行时在存储器中对象之间的关系表明了组织。在此提供的例子提供了关于实体域框架100在Microsoft公司的.NET编程环境的上下文中的一个示例性实现的进一步细节。然而，如上所述，这些实现是说明性且非限制性的；术语“组件”可以指以任何编程范例和技术平台中的任何代码单元。

组件称为“实体组件(entity component)”。在此使用该术语时，限定词“实体(entity)”表示组件遵守某些规则(下面要描述的)，这些规则使组件能够用作实体域框架100的成员。实体组件可以与非实体组件102交互，例如，在一种情况下，通过适当的耦合机制(未示出)。一般而言，非实体组件102是不服从实体组件服从的相同规则的组件。

通常，实体组件实现任何种类应用的不同方面。例如，在面向对象的范例中，实体组件可相应于类的独立对象(实例)，它们具有在应用内完成各种任务的各种方法和相关属性。在提供用户界面(UI)呈现的应用的特定情况下，独立组件可提供UI呈现的不同特征。在存货清单(inventory)应用中，独立组件可提供程序记帐功能的不同特征，等等。这些只是众多可以应用实体域框架100的应用的说明性和非限制性的例子。

实体域框架100具有分层结构。即，框架100中的实体组件以父子关系(以及对等关系)耦合到其它实体组件。为实现该组织，实体框架100包括两种实体组件(下面为了简单仅称为“组件”)：元素组件和合成组件。元素组件指没有子的组件。元素组件实现应用的行为方面。合成组件指可包括多个成员的组件。合成组件因此可以包含实体组件分组，包括元素和其它合成组件两者。合成组件包括所谓的合成功能，使它作为分组运行。考虑具有成员“A”、“B”和“C”组件的分组“X”。将分组称为合成，如在此使用该术语时，指对分组的多重具体化(multi-bodied)性质进行引用，例如，通过隐式地枚举它的各个成员(A，B和C)。将由该分组提供的引出其状态的合成功能称为分组X，明确地包括使它作为分组运行和与在实体域分层结构中其它分组交互的功能。

图1示出元素组件和合成组件(它进而包括合成功能)的一个示例性和非限制性组织。即，合成功能104定义第一层的合成分组，包括示例性元素组件106和108。这个第一层合成分组还包括其它合成功能110，它定义第二层合成分组。第二层合成分组包括示例性元素组件112和114。第二层合成分组还包括其它合成功能116，它进而定义第三层合成分组。第三层合成分组包括元素组件118和120，以及进一步的合成功能122。图1可只代表具有更大范围的实体框架100的一小部分。例如，顶层合成功能104可耦合到较高层(未示出)，并且第三层合成功能122可耦合到更低的层(未示出)。注意，术语“较高(higher)”是对更大的封闭域(例如，父和祖先层)的简写比喻引用，而术语“较低(lower)”是对进一步嵌套的域(例如，子层)的简写比喻引用；严格地讲，编程环境不区分“上(up)”和“下(down)”。

在一个实际的示例性实现中，顶层组件分组可相应于整个应用最抽象的表示。该顶层可以由没有父组件的根合成功能(未示出)来表示。最低层可相应于应用内相对小的细节，诸如各个用户界面控件等等。这些例子仅是说明性的。而且，图1示出由嵌套合成功能的单一链(104，110，116，122)定义的分层结构。然而，其它实体域框架可以包括多个嵌套合成功能链。例如，另一个实体域框架(未示出)可以包括合成功能的多个分支来定义这类组件相对复杂的树。在这种情况下，实体域框架可包括对等组件，它们共享一或多个共同祖先组件，但另外具有一种横向或类似于图的彼此相关关系；这里横向或类似于图的关系指除父子关系(定义类似于树的关系)之外的任何种类的关系。

每个合成分组(由合成功能表示的)定义单独的所谓实体域。例如，合成功能104定义第一层实体域124(A)；合成功能110定义第二层实体域126(B)；以及合成功能116定义第三层实体域128(C)。具有虚线边界的方框图示这三个独立实体域的范围。如上所述，实体域框架100可只代表具有更大范围的分层树的一部分；因此，实体域框架100可以包括比图1例示的更多实体域。

为提供一个说明性和非限制性例子，实体域124可相应于用户界面窗口类型呈现；实体域126可相应于在该窗口类型呈现内的滚动条部件；并且实体域128可相应于滚动条部件的一个特定组件，诸如在滚动条中间的可滚动的指压片(thumb piece)，等等。顶层实体域(未示出)可相应于整个应用。

在实体域中组件的分组服从任何种类的共享政策。粗略地说，政策指定一或多个共同应用于实体域内的成员的规则。如前提到的，一个示例性政策可属于实体域内的组件的生存期管理。生存期管理指控制实体域内组件的移除规则。另一个示例性政策可属于出错处理管理。出错处理指控制如何由实体域处理检测到的错误的规则。这些政策仅仅是可以应用于实体域的各种各样规则的例子。章节B(下面)提供关于生存期域和出错处理域的示例性实现的详细信息。

实体域通过一或多个服务提供上述政策。例如，第一层实体域124可以提供服务集合130。第二层实体域126可以提供另一个服务集合132。以及第三层实体域128可以提供另一个服务集合134。(可供替换地，一或多个实体域可以省略某些服务)。在图1的特定例子中，服务(130，132，134)是分层嵌套的，使得第一层实体域124的服务130可用于第二层实体域126和第三层实体域128，并且第二层实体域126的服务132可选地可用于第三层实体域128。例如，考虑出错处理服务的情况。第一层实体域124可提供一般的捕捉全部出错处理器来解决在任何实体域(124，126，128)内检测到的某类错误，同时其它更深嵌套的实体域(例如，126，128)可提供更精细地适合于可在它们相应的域(126，128)内出现的错误的出错处理器。假定作为第三层实体域128的成员的实体检测到一个错误。实体域框架100可试图使用由第三层实体域128提供的本地服务134解决这个错误。然而，如果这些服务不足以解决该错误，则合成功能116可将出错处理任务推迟到第二层实体域126。实体域126可以进而将该错误推迟到第一层实体域124，如果它不能成功地解决它。章节B.2提供关于实体域框架100中的错误逐步升级过程的更多信息。

在其它情况下，本地服务(例如，服务132、134)可以覆盖或修改由封闭(父)实体域提供的一般服务。在其它情况下，实体域框架100可以阻止实体域(及其相关联的合成功能)访问由实体域框架100中较高层提供的服务。在其它情况下，实体域框架100可以提供所有实体域内的某些基本服务的冗余实例，因此在这些实体域内的实体不需要通过爬行分层结构来搜索这些服务。

下面的子章节提供另外的细节来说明上述一般原理。

A.2耦合机制和封装条款

仍参考图1，实体域框架100的分层结构是通过将框架100中的组件系在一起的引用集合来维护的。即，每个组件是由将它链接到它相应父组件的引用信息耦合到它的实体域的。实现子到父耦合的一种方法是通过在构造每个子组件时提供父引用信息给每个子组件来进行的。父引用信息将子组件链接到它的合成组件。该条款促进实体域框架100的自顶向下构造，因为实体域框架100是通过以连续方式添加子组件到父组件而增长的。例如，引用136将元素组件106与其相应的实体域124(具体地说，部分地由合成功能104)链接起来。而且，作为一个特殊政策(诸如生存期管理)的一部分，子元素组件可以注册它们的父和祖先组件；这为父和祖先组件提供关于其相应子组件的信息。该信息在各种情况下变得有用，诸如当父实体域希望关闭它的嵌套实体域。然而，除这些特殊情况外，父组件没有访问标识其子组件的引用信息。这个特征是有益的，因为它没有引入有可能干扰组件(它们对于收集是成熟的)的垃圾收集的引用信息。

合成功能(104，110，116)可以用上述方式耦合在一起。即，子合成功能可以耦合到它的父合成功能，这是通过标识其父合成功能的引用信息的优点。例如，引用138将合成功能110与父合成功能104链接起来。在某政策特定的情况下，父合成功能也可以包括判定什么子合成组件依赖于父合成功能的机制。

链接的合成功能的分层树(104，110，116，122)形成一个管道，通过它在实体域框架110内的施动者(actor)可以访问各种服务。该管道称为服务总线140。该管道像总线一样，在于它允许施动者通过一般的请求协议放置对服务的请求，不要求框架110中各个施动者与相应的服务实例之间显式的点对点耦合。请求协议(由查找服务提供的)访问所请求的服务，如果需要通过在分层结构的不同层处产生连续的查询，直到它到达具有所请求服务的实体域。

服务总线比其它策略好，这有许多原因。点对点策略可以要求对象到服务的原子耦合。另一个策略可以预先为每个需要服务的对象复制服务。相反，通过使用当前框架100的唯一服务总线140，在框架内的实体不需要预先提供到它需要的服务的特定链接，或者它可调用的服务的单独实例。当实体需要服务时，它可以通过指定服务类型来请求服务。它通过服务总线140在分层结构中的某个层接收该服务。该方法与某些其它方法相比不太复杂并且存储器效率更高。例如，用于与服务交互的已知策略一般会增加应用的运行时实现的开销，后者进而可以增加它的存储器印迹，并且可以导致其它运行时低效率；在此描述的设计可以消除或者减少这些缺点。存储器节省的一个特定的例子是因为实体不需要存储到可用于它的每个服务的单独引用的事实；实体可以存储允许它访问查找服务的单一引用，基于它查找服务可以访问任意多个服务。(如在背景技术章节中提到的，有些常规技术通过使用全局变量实现共享的上下文，从而在效率和性能方面取得某些增益；然而，这些技术在相对粗粒的等级上提供机会，例如，在过程或线程等级上，这就未能通过唯一使用实体域而产生在此所述的好处)。下一个子章节提供关于可以用于实现服务总线140的示例性查找协议的更多细节。

尽管查找条款使组件能够访问某些服务，但实体域框架100可包括另外限制实体域框架100内组件之间的信息交换的条款。按照一个这样的条款，实体域框架100可以包括保护和封装功能，它阻止任何实体组件发现实体域框架100的某些特征。更明确地说，如上所述，这是真的，即实体域框架100可以使任何组件能够发现标识其父组件的引用信息。实体域框架100也可以使任何组件能够访问查找服务，它进而使组件能够访问它本地实体域提供的或由封闭实体域提供的服务。然而，实体域框架100还可以阻止任何实体组件发现关于它对等的信息，由合成功能提供的服务的性质，整个实体域框架的结构，等等。更明确地说，实体域框架100可以“阻止”组件发现这样的信息，因为它不提供发现这样的信息的机制作为实体域框架100本身基本结构的一部分。然而，实体域框架100保持通用性，因此特定应用可以结合定制功能，它允许在组件之间任意程度的交互。换言之，实体域框架100不排除这样的在组件之间的交互；它仅仅不提供它作为其树干或核心、功能的一部分。

还有其它保护和封装条款可以用于保证应用资源的完整性。

A.3服务和查找功能

现在转到图2，该图示出在图1中所示的实体域框架100可以实现的示例***200。在说明图2时也将参考图1的某些特征。

服务指可以由实体域框架100内的实体组件直接或间接使用以完成一或多个规定任务的任何功能。某些服务比其它服务更基本，应用于各种各样不同种类的应用。图2将基本服务称为示例性基本功能服务202。一个这样的基本功能服务202是查询服务204。组件可以启用查找服务204来请求和访问另一个服务，诸如出错处理服务。基本功能服务202组集可以包括其它基本服务，如一般由图2中标有“其它基本功能服务”206的气泡表示。

在服务分组200中的其它服务可属于依赖于基本功能服务202的较高阶政策202。一个这样的较高阶服务是生存期服务208.包括生存期服务208的实体域称为生存期域。如提到的，生存期服务208提供控制构造和释放组件方式的功能。章节B.1提供关于生存期服务208的详细信息。

另一个较高阶服务是出错处理服务210。包括出错处理服务210的实体域称为出错处理域。如提到的，出错处理服务210提供控制处理在实体域框架100内发现的错误的方式的功能。章节B.2提供有关出错处理服务210的详细信息。

较高阶服务组集可以包括其它这样的服务，如一般由图2中标有“其它服务”212的气泡表示的。通常，图2的服务被分成高阶服务和基本功能服务，这是提高对服务理解的手段，而不解释为暗示这些服务必然具有显著不同的特性。例如，迄今为止生存期服务208和出错处理服务210预期由许多类型的应用广泛使用，并且有可能由具有更高阶性质的服务使用，这些服务(208，210)可以可供替换地被分类为基本功能服务202。

上面的讨论将服务200描述为可以由应用实现的独立功能。然而，单个应用可以应用多个服务，诸如生存期管理服务208和出错处理服务210。在某些情况下，一种域(诸如生存期域)可具有与其它种类域(诸如出错处理域)相同的成员。在其它情况下，一种域的成员资格可与另一种域的成员资格不同。在后一种情况下，不同合成功能可以被分配给不同的域以定义这些域的不同成员资格，并且这样创建的合成可以发布不同服务供它们的成员使用，从而定义域的性质(例如，生存期服务定义生存期域，等等)。

服务200可以用各种方法实现。通常，服务200可以由合成组件本身实现或者可以由合成组件的某个子对象(一般是元素组件)实现。或者一个特定应用可使用不同技术的组合来实现不同的服务，例如，取决于服务的性质和其它因素。还有其它实现可以提供。章节A.4(下面)提供关于实体组件及其服务的示例性实现。

图3示出协议300，它控制查找服务204的操作。在本例中，协议300在合成功能(302，304，306，308)的示例性分层结构的周境中做完。这些合成功能的每一个(302，304，306，308)定义相应的实体域，它们每一个可包括一或多个元素组件(未示出)。每个合成功能(302，304，306，308)包括引用信息，它将自己链接到它的封闭(父)合成功能。图3示出合成功能(302，304，306，308)的单一链，但实体域框架可以包括任何复杂性和大小的合成功能的多分支树。(更明确地说，从自顶至下来看，实体域框架100可以视为一棵树，但在实体域框架100中任何给定的子组件通过引用的单一链与树的根相关。)而且，合成功能(302，304，306，308)可只代表具有更大范围的实体域框架(未示出)的一部分。

每个合成功能(302，304，306，308)具有访问与每个相应合成功能(302，304，306，308)相关联的服务(310，312，314，316)的权限；即，合成功能302具有访问服务310的权限，合成功能304具有访问服务312的权限，合成功能306具有访问服务314的权限，以及合成功能308具有访问服务316的权限。另外，以下面描述的方式，在实体域框架100中的任何实体可访问由父或祖先合成功能提供的任何服务。

为例示查找服务204的操作，假定与合成功能302相关联的实体(未示出)通过指定服务类型请求特定服务。响应时，合成功能302将首先确定它的本地服务310是否能够提供所请求的服务。如果能，则合成功能302提供该服务。如果合成功能302不能提供所请求的服务，则查找服务204接着查询合成功能304以判定它是否能提供所请求的服务。查找服务204重复该过程，不断地通过实体域的分层结构上升，直到找到一个能够提供所请求服务的实体域为止。例如，这个查找协议300可一路前进到实体域分层结构(未示出)的根。上述机制实现参考图1引入的服务总线140。

许多例外可以应用，它们改变服务总线140的行为。在一种技术中，本地实体域可以高速缓存它已经在先前从一个封闭父或祖先实体域访问的服务。当该本地实体域要求再次访问该服务时，它可以从其高速缓存访问该服务。这避免需要执行上面描述的递归搜索。

在另一种技术中，实体域框架可以孤立一个实体域。该条款阻止查找服务204在实体域分层结构中超出被孤立的实体域范围上升。换言之，孤立一个实体域实质上使查找搜索在被孤立的实体域处终止。图3用“X”表示这个特征，它代表阻塞，阻止查找服务204超出这个点前进。该条款有效地将合成功能302呈现为一个伪根，至少相对于被阻塞的所请求服务的可行性。这可以通过提供一个特殊的合成组件来实现，配置它使得它的查找服务不考虑该合成的父组件。

A.4实体的示例性实现

如上所述，在实体域框架100中的实体可以使用面向对象的编程技术来实现。更明确地说，合成功能可以基于第一个基类(例如EntityComposite(实体合成))来实例化。一个合成功能的实例化建立一个实体域。元素组件可以基于第二个基类(例如，EntityElement(实体元素))来实例化。实现这两个相应类的示例性代码摘录在下面提供：

public abstract class EntityComposite：IEntityDomain，...

{

 protected EntityComposite(IEntityDomain entityDomain){...}

 ...

}

public abstract class EntityElement

{

 protected EntityElement(IEntityDomain entityDomain){...}

 ...

}

按照一个示例性和非限制性实现，实体域框架100通过在构造期间传递父实体域引用(IEntityDomain)给子组件作为构造函数的参数来建立实体域关系。实体构造函数随后可以传递该信息给它们的基类(EntityElement或EntityComposite)构造函数。EntityElement和EntityComposite基类两者都保存这个引用并且在它们的构造函数中初始化它。(通常，在这个示例性实现中，孤立的基类代码负责这些向上链接的管理。)这个模型实施自顶至下的构造。自顶向下构造，具有父引用的一次性设置语义，排除了将循环引入实体域结构本身。

基类提供允许使用这些基类创建的组件执行在前面的章节中描述的任务的功能。例如，在一个示例性和非限制性实现中，EntityComposite和EntityElement基类两者都通过保护的非虚拟方法来提供上述基本功能服务202。一个这样的方法是LookupService(查找服务)方法，它实现在图2中引入的查找服务204。

LookupService方法具有这样一些方面，即包括EntityElement基类和EntityComposite基类两者，EntityComposite基类提供实现在图3中例示的递归查找行为的关键功能。更明确地说，在启动与一个特定元素组件相关联的查找操作时，在EntityElement基类中的LookupService立即推迟到它父EntityComposite组件，在此称为p-1父EntityComposite组件。

p-1父EntityComposite组件通过执行其LookupService部分，响应于EntityElement组件。这包括首先考虑由p-1父EntityComposite组件发布的服务集合。如果p-1父EntityComposite组件不能在发布的服务中找到所请求的服务类型，它向上推迟到它自己的父EntityComposite组件，在此称为p-2父EntityComposite组件。

p-2父EntityComposite组件以与p-1父EntityComposite组件相同的方式响应。即，它通过首先考虑由它发布的服务集合来调用LookupService，并且如果它不能找到所请求的服务，则推迟到它相应的父EntityComposite组件(即，p-3父EntityComposite组件)。重复这个过程，直到所请求的服务被找到(或者确定无法找到所请求的服务)。

然而，引入孤立的服务范围(因而相对于可用的服务孤立它们包含的组件)的特殊配置的合成组件将不推迟到它相应的父EntityComposite组件，并且因此将不支持上述递归查找操作。换言之，对服务的请求在它们到达这样一个实体域(在其中孤立的特征已经被调用)时终止。

相对于出错处理服务210，EntityElement和EntityComposite基类两者都具有一个保护方法来报告组件遇到的错误。(这实现为查找操作的封装，它在如果发生错误时访问出错处理功能，随后启用该功能。)更明确地说，出错处理方法可以将这类错误发送到直接包含该组件的封闭出错处理域(即揭示出错处理服务的实体域)。如果出错处理器可以包含该错误，则它采取适当的动作。如果出错处理器不知道如何处理错误，则它向上推迟到下一个封闭出错处理域。

按照另一个特征，元素组件可以通过使用EntityElement基类上的Parent(父)属性来发现它们的父实体域。元素组件可以使用该功能在包含的实体域内创建新的对等组件。

B.示例***

本章节描述可以由图1的实体域框架100实现的示例***。即，子章节B.1描述生存期服务208，以及子章节B.2描述出错处理服务210。

B.1生存期域

图4示出用作说明生存期服务208的工具的实体域框架400。如上所述，实现生存期服务208的实体域称为生存期域。生存期服务208进而提供用于控制在应用的运行时期间组件移除的功能。

开始，实体域框架400可以从一个根节点开始以逐点方式来构造。根节点定义应用的某些一般方面。创建过程将更多组件添加到根节点，随后用作添加更多组件的平台。该过程以这种自顶至下方式在建立和运行应用时进行。在同时，下面要描述的功能还在工作时剪除这样创建的实体域框架来移除不再需要的组件。

根节点相应于由应用提供的具有最大范围的生存期域。应用之后可以创建附加的嵌套生存期域，它控制附加的相应组件分组的生存期。开发者可以基于不同的考虑事项提供将发展的实体域框架400划分到不同域的代码。例如，开发者可决定分配一个单独的生存期给一个组件分组，因为一或多个下列因素适用：(a)组件分组通常作为一个单元由应用来创建和移除；(b)组件分组可以具有比分组的封闭生存期域更短的生存期；(c)组件分组要求确定性的关闭；和/或(d)在分组内的组件要求显式关闭通知来释放它们可交互的资源。术语“确定性的关闭(deterministic shutdown)”通常指一个关闭过程，它是按照一个定义的协议(例如，按照定义的操作序列)响应于某个关闭事件执行的。确定性的关闭在关闭操作中提供可预言性。因而，在更特定的示例性上下文中，确定性的关闭指具有可预言的顺序和可预言的最终结果(例如，一旦启动就同步地完成的过程)的关闭过程。相反，传统的垃圾收集技术很难允许人们预言一旦一个实例变成不被引用(即，一旦它不再由另一个组件引用)何时一个实例将遭受垃圾收集。而且，如果在两个都是移除候选的实例之间有某种关系，传统的垃圾收集技术很难允许人们预言它们将被移除的顺序。

例如，考虑相应于一个列表UI元素的父实体域和一个相应于包括在该列表元素中的表格UI元素的子实体域的情况。在整个列表元素之前需要先移除表格元素是可能的。这可由一个滚动事件引起，该事件引起表格元素的移除，但不是整个列表元素。这个情况可部分地使它适合于将一个单独的生存期域分配给该表格元素。而且，如果列表元素整个被移除，则表格元素也应该被移除。这种情况使它适合于将表格元素的生存期域嵌套在列表元素的生存期域内，使得封闭生存期域的关闭也将引起表格元素的生存期域的关闭。

不同应用和设计考虑事项将保证不同生存期域分区的创建。为提供讨论的工具，图4表示一个示例性和非限制性实体域结构400的一部分。实体域框架400包括合成功能402，它定义第一层生存期域404。第二合成功能406耦合到第一合成功能402。第二个合成功能406建立第二个生存期域408，它包括一个说明性元素组件410。第三个合成功能412也耦合到第一个合成功能402。这第三个合成功能412建立第三个生存期域414，它包括元素组件416和418。元素组件416配置为与各种资源420诸如数据库交互。这个角色使元素组件416成为一个资源管理器。最后，在示例性生存期域414之外的各种实体诸如对象422可保存指向生存期域414内的组件的引用。

为创建生存期域(404，408，414)，实体域分层结构400提供一或多个所谓的生存期指挥器。这些指挥器通常实现生存期服务208(参考图2引入的)的诸方面。在一个示例性实现中，每个生存期域(404，408，414)包括它自己的生存期指挥器。然而，图4主要集中于第一个生存期域404与第三个生存期域414之间的交互，并且因此只例示了与第三个生存期域414相关联的生存期指挥器424来促进讨论。生存期指挥器424的基本目的是协调第三个生存期域414内的关闭活动。

按照另一个方面，生存期服务208可选地接受它定义的生存期域的所有者。图4示出一个示例性所有者426，它“拥有”第三个生存期域414。在所有者426与它的生存期域414之间存储一个一对一关系。然而，在其它情况下，单个所有者可控制多个生存期域。所有者426的基本目的是启动第三个生存期域414的关闭并且还切断指向第三个生存期域414的外部引用(例如，从外部对象422)。

指挥器424在第三个生存期域414内起作用，然而所有者426在第三个生存期域414之外起作用，一般在一个封闭第三个生存期域414的生存期域(例如，域404)中。生存期指挥器424保存到它的生存期所有者426的引用。生存期所有者426进而保存到它所拥有的第三个生存期域414的合成功能412的引用。在一个实现中，生存期指挥器424是唯一的代理，它知道它在生存期域414之外的所有者副本426。

生存期所有者426和生存期指挥器424的功能将在下面更详细地描述，从生存期所有者426开始。生存期所有者426执行若干角色。

一个角色是启动关闭。在一种情况下，生存期所有者426可以接收一个特定请求关闭它的生存期域414。即，在这种情况下，该请求明确地以生存期域414为目标。关闭随后将以确定性方式进行，如由生存期指挥器414协调的。按照一个一般原理，关闭一个封闭生存期域的请求也将引起所有该封闭域的嵌套生存期域的递归关闭。这保证没有从属的生存期域会比其封闭(父)生存期域存在更长的时间。考虑这样一个例子，其中父生存期域相应于一个滚动条，而子生存期域相应于该滚动条的一部分。整个滚动条的移除应该引起其组件部分的移除，引起所有相应于那些部分的嵌套子域的移除。

实现这个关闭行为的一种方法是要求每个嵌套的生存期域向其父生存期域注册其存在。结果，父生存期域“知道”什么嵌套生存期域“在它之下”。随后，当发生一个使父生存期域关闭的事件时，生存期域可以访问从属生存期域的注册表并且用它将关闭指令转送到它的每个从属生存期域。嵌套的从属域的关闭是以递归方式执行的。关闭从最深嵌套的开始，第二深嵌套的，等等，以要被关闭的目标生存期域结束。

在另一个情况下，生存期所有者426可以从生存期指挥器424接收一个请求，它通知生存期所有者426，生存期所有者426本身是要关闭的生存期域的一部分(例如，由于上述嵌套的关闭操作的类型)。

生存期所有者426可以响应于关闭，通过执行除启动关闭之外的附加任务。在一个任务中，生存期所有者426切断所有从外部对象(例如从对象422)到第三个生存期域414中的引用。这个向内引用的切断希望保证被关闭的子***可以可靠地从属垃圾收集。相反，所有完整地留在生存期域内的引用是不受限制的。因而，不需要特殊的生存期管理条款专用于解决这些类型的引用。(从域外部到生存期域的引用是特别感兴趣的，因为这些引用是保持一个域存在的引用，例如，通过表示域是否仍由应用以某种方式使用。)

在相似的脉络(vein)中，没有必要在执行关闭协议的同时切断任何合成上行链路。这些上行链路可以在一个动作中切断，这是通过移除单个向下引用(它锚定要受到关闭的最远的合成功能)来进行的。换言之，从生存期所有者到其拥有的域的合成功能的引用的切断严格地说只有被关闭的最远的生存期域才需要。

然而，一般而言，实体域可以包括或不包括所有者。如果生存期域包括所有者，则可以独立于它的封闭父生存期域确定性地关闭它。包括所有者的生存期域称为主动域。例如，在图4的情况下，因为第三个生存期域414包括所有者426，可以独立于它的父生存期域404关闭它(尽管，如上所述，父生存期域404不能在还没有关闭子生存期域414的情况下被关闭)。在另一个情况下，生存期所有者426可以被省略。没有所有者的生存期域称为被动域。在这种情况下，第三个生存期域414在它的父生存期域404被关闭时将被自动关闭，但不能独立于父生存期域404被关闭。要进一步注意，关于外部引用处理的某些上面提到的规则只应用于主动生存期域。被动生存期域不能孤立地被关闭；结果，输入的引用不会有问题，除非它们还跨过一个封闭主动生存期域。

生存期指挥器424还协调与关闭相关联的各种活动。这些功能的一些在上面描述，诸如嵌套生存期域协调的关闭。按照另一个特征，生存期指挥器424还提供关闭通知给资源管理器。更明确地说，在生存期域内的某些实体，诸如元素组件416，与一或多个资源420诸如数据库交互，从而使这些组件成为资源管理器。由于它们的角色，资源管理器可控制或影响它们相关联的资源的生存期。生存期指挥器424通过提供一个协议来解决这个关系，该协议保证资源管理器的有序和可靠的关闭。实现有序关闭的一种方法是通过要求每个资源管理器(例如，资源管理器416)向其封闭生存期域414注册来进行的。随后，在关闭时，生存期指挥器424可以指示这些资源管理器(例如，资源管理器416)释放它们与其相应资源(例如资源420)的关联。

在成功关闭之后，可以运行垃圾收集功能428来从已分配的存储器堆中移除不再需要的组件(尽管垃圾收集在形式上不是生存期管理服务本身的一部分)。垃圾收集功能在已知***中使用，但显然不是在这里描述的上下文中。在传统***中，垃圾收集功能保持与每个存储在存储器中的主动组件相关联的引用的详细记帐。当垃圾收集功能发现一个组件不再具有任何到它的引用(即，引用数＝0)时，垃圾收集功能移除该组件。然而，在这些***中，没有协议保证应用的诸部分被正确地关闭并且在这些部分不再需要时到这些部分的引用被正确地移除。形成显著对比的是，在图4的上下文中描述的生存期管理提供良好建立的协议来关闭应用的诸部分，作为垃圾收集的预报器，它使用良好定义的和可预言的操作序列(例如确定性地，如上定义的)。

通常，要注意的是，由于上述条款，从元素组件到合成功能的“向上”引用(例如，以子到父的“方向”)不干扰生存期域的垃圾收集。生存期域还维护“向下”引用(以父到子的方向)以协调关闭。有序的关闭过程在这些引用不再需要时切断它们，因而阻止这些引用抑制已经被关闭的生存期域的垃圾收集。

在了解了上述一般特征后，下面的讨论阐述一个执行关闭的示例性情况。假定再次使用上面开发的例子。在本例中，实体域404管理列表UI元素的生存期。列表UI元素包括多个部分，包括表格UI元素。生存期域414可以管理表格元素的生存期。

执行下面的事件来创建表格元素：

·列表元素首先创建表格元素的生存期所有者。生存期所有者可以在或不在与表格元素的一对一关联中。

·列表元素随后连同本身作为表格元素组件的父组件一起将生存期所有者传递给创建表格元素的构造功能(例如所谓的工厂功能)。(任何按照约定创建和初始化一个新实例并且随后将它传给调用者的方法称为工厂方法)。

·当构造功能创建表格元素时，它必须传递一个父引用(标识表格元素的父组件)，并且可以可选地将一个所有者引用(标识表格元素的所有者)给子组件的构造函数。这完成了创建一个表格元素的过程。

执行下面的事件序列来关闭表格元素：

·列表元素可以请求表格元素的生存期所有者426关闭表格元素。

·表格元素的生存期所有者426通知表格元素的生存期指挥器424以启动关闭。

·表格元素的生存期指挥器424随后请求表格元素的生存期所有者426断开(从其它生存期域)到表格元素的所有外部引用。这个指令引起生存期所有者426切断来自外部对象422的引用。

·生存期所有者426释放它的到表格元素的引用。

·生存期指挥器424还将关闭请求传播到任何由它的生存期域414封闭的子(嵌套)生存期域。为了简单，假定在表格元素生存期域中的所有子组件相应于非生存期合成组件。

·表格元素的生存期指挥器424通知所有已经注册了关闭通知的所有组件。这些是与组件416一样的组件，它们需要关闭资源或者撤消对通知的注册。生存期指挥器424随后从由列表元素管理的子生存期集合中移除表格元素。

·调用堆栈退到生存期所有者426。表格元素可以在这点上受到垃圾收集。

·当调用退到列表元素，列表元素可释放它的到表格所有者426的引用，所有者426同样可以在这点上受到垃圾收集。

上面阐述的例子涉及表格的列表，其中每个表格可以独立地从列表中添加和移除，从而保证每个表格的生存期域。在本例中的表格用作一个元素。但本领域的熟练技术人员将意识到，本例只是说明性的。在另一个例子中，表格本身可以实现为UI元素的列表，每个元素相应于一个表格行。对于上述对象的相似的生存期管理操作可以相对表格的各个元素执行。

实体域框架400可以用各种方法实现上述生存期框架400。例如，生存期指挥器424可以实现为实体合成(例如，LifetimeDomainComposite(生存期域合成))的特殊合成基类。这是有利的，因为它使生存期指挥器功能能够对于合成实现者是密封的。更明确地说，LifetimeDomainComposite类是一个实体合成的特殊变体并且因此从子章节A.4(上面)中讨论的EntityComposite基类导出。

更明确地说，希望建立生存期域的合成组件可以从LifetimeDomainComposite基类导出。实现生存期域的合成类的构造函数的参数之一是它的所有者。这个所有者引用应该连同父引用一起传递给基类。可以将所有者引用存储在基类中并且可以用于在关闭操作期间验证调用者。被动生存期域(它没有所有者)可通过传递一个null(空)值作为所有者参数来创建。

当实例化一个生存期域合成时，LifetimeDomainCompositie基类构造函数查找下一个封闭生存期域并且向它注册自己以便能够参加关闭协议。结果，父生存期域保存到它所有嵌套生存期域的引用。

上述基类(LifetimeDomainComposite)包括支持生存期域功能。这个基类及其相应目的实现的示例性接口在下面描述。(描述的接口名字是说明性，不是限制性的。)

·IProvideShutdown(提供关闭)接口由组件用于为关闭通知进行注册。

·IInitiateShutdown(启动关闭)接口由生存期所有者用于启动在它拥有的生存期域上的关闭。

·IManageChildLifetimeDomains(管理子生存期域)接口由子生存期域用于从封闭生存期域添加和移除子生存期域。

·IShutdownThisLifetime(关闭这个生存期)接口用于在将关闭请求传播给嵌套的生存期域时启动嵌套生存期域的关闭。

生存期所有者角色可以用各种方式实现。生存期所有者可以相应于由包含的实体合成控制的某实例。即，生存期所有者一般是在它的封闭(即，父)合成中的实体。但也有可能的是，生存期所有者及其相关联的生存期域只有一个共同的祖先组件而不是相同的直接父组件。在任何情况下，给生存期所有者一个到它拥有的生存期域的引用，这是在所拥有的生存期域正在构造(由LifetimeDomainComposite基类)的时候，这时生存期所有者存储到所拥有的生存期域的引用。

在可以如何实现生存期所有者上没有限制，除了配置为实现上面所述的分配给它的责任。例如，生存期所有者可以通过调用上述IInitiateShutdown.Shutdown功能来启动确定性的关闭。这引起LifetimeDomainComposite基类通过对照在构造期间传给它的所有者引用检查来验证调用者是生存期所有者。确定性的关闭随后可以通过以该生存期域为根的生存期域分层结构传播(使用到被包含的生存期域的引用并使用IShutdownThisLifetimeDomain接口)，因而关闭所有嵌套的生存期域。这使关闭通知被发送到资源管理器，为这些管理提供一个确定性地释放它们的资源的机会。

生存期所有者的另一个角色是要能够断开所有从域之外的对象到它拥有的生存期域中的外部引用。生存期域的客户因此应该构造这个知识到生存期所有者中。生存期所有者实现IPrepareForShutdown(为关闭准备)功能以在关闭期间断开到生存期域中的外部引用。更明确地说，当生存期指挥器接收关闭请求时，它使用IPrepareForShutdown接口通知生存期所有者，以启动断开从它外部的对象到生存期域中的外部引用的必要动作。注意，生存期所有者接收PrepareForShutdown请求，不管关闭是否通过该生存期所有者启动还是它是否参加嵌套的关闭。生存期所有者也应该在该调用期间释放它的到拥有的生存期域的引用。

资源管理器(诸如元素组件416)同样可以用不同方式实现。这些管理器可以包括一个机制来参加关闭过程以确定性地释放它们的资源。这样一个机制可以包括使资源管理器能够订阅关闭通知的功能。资源管理器可以使用上面描述的IProvideShutdown向它们的封闭生存期域注册关闭通知。

而且，资源管理器可以配置为在各种不同情况下释放它们的资源。例如，生存期指挥器可以向所有它的注册的资源管理器通知关闭，即使一或多个资源管理器在对这个通知起作用时遇到错误。在一个示例性情况下，可以禁止资源管理器在请求它们关闭时显示任何用户界面呈现或者启动其它长期运行的操作。而且，可以禁止资源管理器在可以导致例外被抛出的关闭期间执行操作。

作为最后的主题，可以建立测试机制，它补充生存期域的使用以判定一个应用是否有任何错误。在一种技术中，可以构造一个测试工具或装置，它利用在运行时可以确定封闭生存期服务包括它们的嵌套关系的事实。测试工具或装置可以检测在不正确的方向建立引用的尝试。一个排除机制希望允许到一个在域的所有者的控制或关闭清除机制下的生存期域中的引用。

另一个方法是在排错编译(debug build)上执行“僵”检查。这时的思想是使用适当的运行时工具(诸如Microsoft公司的CLR PerformanceProfi1er(CLR性能简档器))在某个时间点提取所有存在的引用，并且随后在一个已经关闭的生存期域内接或者间接地搜寻被封闭的组件。指向非活动域的引用保持组件在这个域内有效，使这类组件变“僵”。检查条款帮助精确参考违反由生存期服务阐述的政策规则。这样一种技术不能用于传统技术，因为这些传统技术没有将组件分组组织到在此所述的生存期域中。

发现僵状态的能力特别有用，因为这类对象会表现出严重的困难。即，如果一个执行线程无论何时进入僵状态(例如，通过在一个弱引用上的方法调用)，则僵状态一般使方法调用进入应用中的非僵实例。这样的方法调用的目标通常理解这些僵状态是应用所没有的并且因而不准备处理来自它们的调用。各种负面结果会跟着发生。

B.2出错处理域

图5示出用作说明出错处理服务210的工具的实体域框架500。如上所述，实现出错处理服务210的实体域称为出错处理域。出错处理服务210进而一般指任何接收和处理在实体域框架500中或者有可能在实体域框架之外发生的错误的任何功能，例如，作为从实体域内的实例对在它之外实例的方法调用的结果。

图5表示任何示例性和非限制性的实体域结构500的一部分，在此为说明的目的而提供。实体域框架500包括定义第一层出错处理域504的合成功能502。第二个合成功能506耦合到第一个合成功能502。这第二个合成功能506建立第二个出错处理域508。第三个合成功能510也耦合到第一个合成功能502。这第三个合成功能510建立第三个出错处理域512。第四个合成功能514也以嵌套方式耦合到第三个合成功能510。这第四个合成功能514建立第四个出错处理域516。

实体域分层结构500可以实现不同的出错处理服务，它们应用于使用相应出错处理指挥器的相应出错处理域。即，第一个出错处理域504提供出错处理指挥器518，第二个出错处理域508提供出错处理指挥器520，第三个出错处理域512提供出错处理指挥器522，以及第四个出错处理域514提供出错处理指挥器524。通常，出错处理指挥器(518，520，522，524)执行响应于在实体域框架500中检测到的错误的任务。更明确地说，每个出错处理指挥器可以实现定制的出错处理政策(例如，通过提供实现这个功能的定制代码)。即，不同的出错处理域可以应用不同的定制政策。这与生存期域形成对比，其中，在一个示例性情况下，所有域实现相同的一致服务。

再一次，图5只可以表示一个具有更大范围的实体域框架500的样本，因此完整的实体域框架500可包括许多更多的出错处理域和相关联出错处理指挥器(未示出)。

下面的例子例示实体域结构500的操作。假定检测到一个与嵌套的出错处理域516相关联的错误。图5图示这样一个具有X 526的错误。出错处理过程首先必需将错误传送到出错处理指挥器524。出错处理过程首先试图在本地基础上使用本地出错处理指挥器524来解决这个错误。然而，因为在实体域框架500中使用的封装，出错处理指挥器524可能没有完全“理解”(或任何理解)较大的上下文，其中出错处理域516全部位于应用之内。由于这个限制，出错处理指挥器524不能成功地处理检测到错误。更明确地说，出错处理指挥器524可配置为只处理可以在本地等级上成功处理的某些错误类，在不知道发生这些错误的全部上下文的情况下；如果检测到的错误不落入这些类之一，则出错处理指挥器524无法处理它。

如果出错处理指挥器524不能成功地处理检测到的错误，则执行错误逐步上升过程，通过它处理检测到的错误的任务被推迟到下一个“较高”的出错处理指挥器522。这个出错处理指挥器522随后判定它是否能成功地处理检测到的错误。如果否，则出错处理指挥器522进一步将出错处理任务推迟到下一个“较高”出错处理指挥器518。重复这个过程，直到错误被成功处理或者该过程到实体域框架500的根，由此它变成一个“未经处理的错误”。

可以处理错误的出错处理指挥器(基于它的出错处理服务)可以用各种方式响应于错误。出错处理服务一般通过以某种复位协议使组件参加出错处理域来处理错误。例如，出错处理操作可以要求给在出错处理域中的所有数据库连接发信号以在进行之前使它们复位到某个已知的好状态。出错处理操作也可以要求关闭应用的一部分，纠正某信息，记录与错误相关联的某信息，等等。如果一个封闭出错处理域关闭，则它也将关闭它的所有嵌套的出错处理域。

在实现方面，为封装错误信令协议，基类EntityElement和EntityComposite可以提供一个保护实例方法HandleError(处理错误)，实体可以调用它来启用封闭出错处理服务。这个功能(通过它启用适当的出错处理器)使用上述查找服务(见子章节A.3和A.4)来操作。更明确地说，HandleError通过使用查找服务执行对适当出错处理服务的递归搜索，并且随后调用适当的出错处理服务。

B.3其它服务域

上面描述的服务和相关联的实体域可以应用于任何种类的应用。这些服务因此具有一般可应用性。其它服务可明确地设计成补充特定应用的独特体系结构。

C.操作方法

图6-8以流程图方式概括了上述本发明的方面。为方便讨论，将某些操作描述为以某种顺序执行的组成步骤。这类实现是示例性和非限制性的。在此描述的某些步骤可以分组在一起并且在单一操作中执行，并且某些步骤可以以不同于在本说明书中阐述的例子中使用的顺序执行。

图6描述创建具有生存期管理服务的实体域框架的过程。在步骤602中，应用添加一或多个定义应用的整个实体域的初始根类型对象。之后，在步骤604中，应用连续地添加实体域到实体域框架。应用通过添加合成功能到实体域框架有效定义关联域，来执行这个步骤(604)。应用可以通过添加耦合到它们相应的合成功能的元素组件来填充实体域。因此，应用以嵌套的自顶至下方式建立实体域框架。自顶至下构造也在流程图右边的框架片断中例示。上面描述的过程继续，直至在步骤606中，应用最后全部关闭。尽管在图6中未示出，但应用执行另一个类似于创建的操作来移除不再需要的组件。

在生存期服务208的上下文中，应用可决定在许多情况下创建不同的嵌套域。例如，应用可决定(根据开发者的设计目标)来将新添加的组件集合分组成单独的生存期域，如果这些组件可以潜在地具有比它们的封闭(父)生存期域短的生存期或如果自件需要明确的关闭通知等。如果希望确定性地和独立地关闭生存期域，则应用应该还分配一个生存期所有者给生存期域。所有者用作启动关闭的代理。而且，所有者是用于切断从生存期域之外的实体指向生存期域内组件的链接的代理。

图7描述基本查找服务204的操作。在步骤702中，本地实体域接收对某服务的请求，诸如出错处理服务。在步骤704中，本地实体域判定它是否可以提供所请求的服务。如果是，则在步骤706中，本地实体域提供所请求的服务。如果否，在步骤708中，查找服务204判定是否存在可以为这个服务查询的其它封闭域。存在两种否定回答该查询的情况。第一种情况在查找服务204已经前进到实体域框架的根而没有找到所请求的服务时发生。第二种情况在开发者已经将一个域指定为一个孤立的域时发生，它具有阻塞进一步沿嵌套域链向上前进的效果。在任一情况下，在步骤710中，查找服务确定所请求的服务不可用。然而，在步骤712中，如果查找服务确定它可以前进到一个封闭父实体域，则它就这么做。因此，图7中所示的操作序列相对于封闭父实体域被重复。递归查找过程的操作也在流程图左边的域片断中例示。实现上述行为的一种方法是通过称为LookupService的基类方法进行的。该方法在连续的层上递归地被调用，沿分层结构向上前进。这是一种“盲(blind)”的沿链向上前进，因为子组件不“知道”由分层结构中较高层提供的服务。组件依赖于LookupService，其方式与组件将请求放在总线上相同；即，如在总线请求的情况下，组件可不知道或不关心什么“施动者(actor)”将满足请求，如果有的话。

最后，图8例示一个用于由生存期服务控制的实体域框架的示例性关闭过程。在步骤802中，在实体域框架中某实体域接收关闭的请求。在步骤804中，关闭请求触发许多在子章节B.1中完全列举的清除操作。通常，这些操作可以包括发送一个关闭请求到所有在最终的封闭生存期域内嵌套的生存期域。关闭随后以递归方式从最深嵌套的生存期域开始进行。在每个层，关闭可以包括许多子步骤，其中一些在步骤804的右边的扩展列表中列举。在一个子步骤中，所有者可以切断所有从生存期域之外指向生存期域的引用。在另一个子步骤中，生存期指挥器可以发送关闭通知给生存期域内任何已经预先注册要接收这类关闭通知的资源管理器。

在步骤804中，可以执行垃圾收集以从***存储器中移除没有指向它们的引用(表示它们不再由应用需要)的对象。在一个实现中，垃圾收集(在步骤804中)在形式上不是由生存期管理服务提供的关闭协议的一部分，并且因此不必由生存期管理服务触发。换言之，常规的垃圾收集可以结合在此描述的生存期服务使用。然而，不像传统的方法，在垃圾收集之前已经加上了独特的确定性关闭协议(定义有序和可预言的关闭操作序列)，它更好地保证不再使用的对象受到垃圾收集。

D.示例性计算环境

图9提供关于一个示例性计算机环境900的信息，它可以用于运行基于实体域框架范例的应用。

计算环境900包括通用型计算机902和显示设备904。然而，计算环境900可以包括其它种类的计算装置。例如，尽管未示出，计算机环境900可以包括手持式或膝上型设备，机顶盒，游戏控制台，扩展型计算机，大型计算机，嵌入在呈现设备中的逻辑功能等等。而且，图9示出分组在一起的计算机环境900的元素以方便讨论。然而，计算环境900可以使用分布式处理配置。在分布式计算环境中，计算资源可以物理地分散在整个环境中。

示例性计算机902包括一或多个处理器或处理单元906，***存储器908和总线910。总线910将各种***组件连接在一起。例如，总线910将处理器906连接到***存储器908。总线910可以使用任何种类的总线结构或总线结构组合来实现，包括存储器总线或存储器控制器，外设总线，加速图形端口，和使用任何各种总线体系结构的处理器或局部总线。

计算机902也可以包括各种各样计算机可读介质，包括各种各样类型的易失性和非易失性介质，它们各自可以是可移动的或不可移动的。例如，***存储器908包括易失性存储器形式的计算机可读介质，诸如随机存取存储器(RAM)912，以及非易失性存储器，诸如只读存储器(ROM)914。ROM 914包括输入/输出***(BIOS)916，它包含帮助计算机902内的元件之间传送信息的基本例程，诸如在启动时。RAM 912一般包含可以由处理单元906快速存取的形式的数据和/或程序模块。

其它种类的计算机存储介质包括读写不可移动非易失性磁介质的硬盘驱动器918，读写可移动非易失性磁盘922(例如“软盘”)的磁盘驱动器920，以及读写可移动非易失性光盘926诸如CD-ROM、DVD-ROM或其它光介质的光盘驱动器924。硬盘驱动器918、磁盘驱动器920和光盘驱动器924各种通过一或多个数据介质接口928连接到***总线910。可供替换地，硬盘驱动器918、磁盘驱动器920和光盘驱动器924可以通过SCSI接口(未示出)或其它耦合机制连接到***总线910。尽管未示出，计算机902可以包括其它类型的计算机可读介质，诸如磁盒或其它磁存储设备，闪存卡，CD-ROM，数字多功能盘(DVD)或其它光存储，电子可擦除可编程只读存储器(EEPROM)等。

通常，上述计算机可读介质提供由计算机902使用的计算机可读指令、数据结构、程序模块和其它数据的非易失性存储。例如，可读介质可以存储操作***930、应用模块932、其它程序模块934和程序数据936。该介质的其它部分还可以提供实现在前面章节中描述的对象管理功能方面的存储。即，可以分配存储器用于存储由前面描述的实体域框架控制的运行时组件。

计算机环境900可以包括各种各样输入设备。例如，计算机环境900包括键盘938和定点设备940(例如“鼠标”)用于输入命令和信息到计算机902中。计算机环境900可以包括其它输入设备(未示出)，诸如话筒、操纵杆、游戏垫、卫星天线、串行端口、扫描仪、卡阅读设备、数字或视频摄像机等等。输入/输出接口942将输入设备耦合到处理单元906。更一般地，输入设备可以通过任何种类的接口和总线结构诸如并行端口、串行端口、游戏端口、通用串行总线(USB)端口等耦合到计算机902。

计算机环境900还包括显示设备904。视频适配器944将显示设备904耦合到总线910。除显示设备904之外，计算机环境900可以包括其它输出***设备，诸如扬声器(未示出)、打印机(未示出)等等。

计算机902在使用逻辑连接至一或多个远程计算机诸如远程计算设备946的网络化环境中操作。远程计算设备946可以包括任何种类的计算机装置，包括通用个人计算机、便携式计算机、服务器、游戏控制台、网络扩展设备等等。远程计算设备946可以包括上面相对于计算机902所述的全部特征，或者其某个子集。

任何类型的网络948可以用于将计算机902与远程计算设备946耦合，诸如WAN、LAN等等。计算机902通过网络接口950耦合到网络948，它可以使用宽带连接、调制解调器连接、DSL连接或其它连接策略。尽管未示出，计算环境900可以提供无线通信功能，用于将计算机902与远程计算设备946连接(例如，通过经调制的无线电信号，经调制的红外信号等)。

到此为止，在本说明书中以不同方案(例如，案例A或案例B)提供了许多例子。另外，本说明书包括将不同方案组合在一个实现中的那些案例(例如，案例A和案例B)，即使本说明书没有在每个实例中明确地指出这些结合的案例。

更一般地，尽管已经以专用于结构化特征和/或方法过程的语言描述了本发明，但要理解在所附的权利要求书中的定义的本发明不必受限于所述的这些特定特征或过程。相反，这些特定特征和过程是作为实现所主张的本发明的示例性形式揭示的。

Claims (40)

1.一种运行包括运行时组件的集合的机器可读代码的方法，其特征在于，包括：

将至少一个代码组件分组到一分层结构化实体域中，其中，所述实体域服从一规定政策；以及

按照所述实体域的政策管理所述至少一个代码组件。

2.如权利要求1所述的方法，其特征在于，所述实体域提供将所述至少一个组件耦合至所述实体域的合成功能。

3.如权利要求1所述的方法，其特征在于，所述分组包括提供服从各自政策的多个实体域。

4.如权利要求3所述的方法，其特征在于，所述多个实体域是以自顶向下方式构造的。

5.如权利要求3所述的方法，其特征在于，所述多个实体域是以父子关系链接在一起的。

6.如权利要求3所述的方法，其特征在于，每个所述实体域提供将所述多个实体域耦合到一个分层的实体域框架的相应的合成功能。

7.如权利要求6所述的方法，其特征在于，由所述多个实体域提供的合成功能共同地定义一种耦合机制，通过该机制实体可通过所述实体域框架发送请求。

8.如权利要求7所述的方法，其特征在于，与一特定的实体域相关联的请求是通过下列步骤来处理的：

(a)判定所述特定实体域是否能够满足所述请求，并且如果是，则在所述特定实体域中处理所述请求；

(b)如果所述特定实体域不能满足所述请求，则判定所述特定实体域的父实体域是否能够满足所述请求，并且如果是，则在所述父实体域处理中请求；以及

(c)如果父实体域不能满足请求，重复操作(b)，直到满足所述请求或者确定无法满足所述请求为止。

9.如权利要求1所述的方法，其特征在于，由所述实体域提供的政策属于所述至少一个组件的生存期管理，并且所述管理包括基于所述生存期管理政策控制所述至少一个组件的确定性关闭。

10.如权利要求9所述的方法，其特征在于，所述实体域包括多个组件，并且所述管理包括将所述多个组件作为一个单元关闭。

11.如权利要求9所述的方法，其特征在于，所述实体域是包括至少一个嵌套域的封闭生存期域，并且所述管理在封闭生存期域之前协调所述至少一个嵌套的封闭生存期域的关闭。

12.如权利要求9所述的方法，其特征在于，所述管理包括提供一关闭通知给至少一个事先已经注册要接收这类通知的组件。

13.如权利要求9所述的方法，其特征在于，所述生存期管理政策容纳所述实体域之外提供的生存期所有者功能，并且所述管理包括使用所述所有者功能来启动所述至少一个组件的关闭。

14.如权利要求9所述的方法，其特征在于，所述管理包括切断从所述实体域之外的对象到所述实体域中的引用链接。

15.如权利要求14所述的方法，其特征在于，所述生存期管理政策容纳生存期所有者功能，并且其中，所述管理包括使用所述所有者功能来执行切断。

16.如权利要求1所述的方法，其特征在于，由所述实体域提供的政策属于出错处理管理，并且其中，所述管理包括基于所述出错处理管理政策控制与所述实体域相关联的错误的顺序处理。

17.如权利要求16所述的方法，其特征在于，所述实体域包括多个组件，并且所述管理包括将相同的出错处理管理政策应用于所有所述多个组件。

18.如权利要求16所述的方法，其特征在于，所述实体域是在至少一个其它封闭实体域内的嵌套实体域，并且其中，所述管理包括如果所述嵌套实体域不能符合要求地处理出错处理任务，则将所述出错处理任务推迟到所述至少一个封闭实体域。

19.一种用于实现权利要求1所述的分组和管理的机器可读介质。

20.一种包括被配置成实现权利要求1所述的分组和管理的逻辑的装置。

21.一种提供实现实体域框架的数据结构的机器可读介质，所述数据结构包括：

分层结构化的实体域，它包括至少一个代码组件；以及

与所述实体域相关联的服务功能，它定义应用于所述至少一个组件的规定政策。

22.如权利要求21所述的机器可读介质，其特征在于，所述实体域提供将所述至少一个组件耦合到所述实体域的合成功能。

23.如权利要求21所述的机器可读介质，其特征在于，所述实体域框架包括具有定义相应政策的相应服务功能的多个实体域。

24.如权利要求23所述的机器可读介质，其特征在于，所述多个实体域是以父子关系链接在一起的。

25.如权利要求23所述的机器可读介质，其特征在于，每个所述实体域提供将所述多个实体域耦合在一起以定义实体域框架的相应的合成功能。

26.如权利要求25所述的机器可读介质，其特征在于，由所述多个实体域提供的合成功能共同地定义一耦合机制，通过该机制实体可通过所述实体域框架发送请求。

27.如权利要求21所述的机器可读介质，其特征在于，由所述实体域提供的政策属于所述至少一个组件的生存期管理，基于所述生存期管理政策控制所述至少一个组件的确定性关闭。

28.如权利要求21所述的机器可读介质，其特征在于，由所述实体域提供的政策属于出错处理管理，基于所述出错处理管理政策控制与所述实体域相关联的错误的顺序处理。

29.一种用于提供应用程序的装置，其特征在于，包括：

存储器，用于存储实现应用程序的运行时部分的组件；

处理设备，它被配置成执行指令，以便：

将至少一个代码组件组织到一分层结构化的实体域，并且将所述至少一个实体域储存在所述存储器中；以及

被配置成按照所述实体域的政策管理所述至少一个代码组件的逻辑。

30.如权利要求29所述的装置，其特征在于，所述实体域提供将所述至少一个组件耦合到所述实体域的合成功能。

31.如权利要求29所述的装置，其特征在于，还包括服从多个相应政策的多个实体域。

32.如权利要求31所述的装置，其特征在于，所述多个实体域是以父子关系链接在一起的。

33.如权利要求31所述的装置，其特征在于，每个所述实体域提供将所述多个实体域耦合到一分层实体域框架中的相应的合成功能。

34.如权利要求33所述的装置，其特征在于，由所述多个实体域提供的合成功能共同地定义一总线，通过该总线实体可通过所述实体域框架发送请求。

35.如权利要求29所述的装置，其特征在于，由所述实体域提供的政策属于所述至少一个组件的生存期管理，基于所述生存期管理政策控制所述至少一个组件的确定性关闭。

36.如权利要求29所述的装置，其特征在于，由所述实体域提供的政策属于出错处理管理，基于所述出错处理管理政策控制与实体域相关联的错误的顺序处理。

37.一种运行机器可读代码的方法，所述代码包括运行时组件的集合，所述方法包括：

将至少一个代码组件分组到一分层结构化实体域中，其中，所述实体域服从生存期管理政策；以及

按照所述生存期管理政策关闭所述实体域。

38.如权利要求37所述的方法，其特征在于，按照生存期管理政策关闭所述实体域包括：

协调包括在所述实体域内的任何嵌套的生存期域的递归关闭；

提供一关闭通知给至少一个已经预先注册接收这类通知的组件；以及

切断从所述实体域外的对象到所述实体域中的引用链接。

39.一种运行机器可读代码的方法，所述代码包括运行时组件的集合，所述包括：

将至少一个代码组件分组到一分层结构化实体域中，其中，所述实体域服从出错处理管理政策；以及

基于所述出错处理管理政策处理与实体域的相关联的错误。

40.如权利要求39所述的方法，其特征在于，所述实体域是在至少一个其它封闭实体域内的嵌套实体域，并且其中，错误的处理包括如果所述嵌套实体域不能符合要求地处理出错处理任务，则将所述出错处理任务推迟到所述至少一个封闭实体域。

Images