CN102812435B

CN102812435B - 确认分布式应用的配置

Info

Publication number: CN102812435B
Application number: CN201180015164.6A
Authority: CN
Inventors: S·布萨亚拉特; V·波格列宾斯凯
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2010-03-24
Filing date: 2011-03-18
Publication date: 2016-06-01
Anticipated expiration: 2031-03-18
Also published as: WO2011119442A3; WO2011119442A2; US20110239055A1; US8219854B2; CN102812435A

Abstract

本发明涉及用于确认分布式应用的配置的方法、系统和计算机程序产品。本发明的实施例提供了一种用于标识分布式应用的配置差错和最优非顺从的根本原因的系统框架。该系统框架为平台提供者和客户两者提供了一种用于创建、扩展和利用简化配置故障诊断体验的工具的强大且一致的方法。使用该系统框架，用户能够访问更多关于应用的信息并同时对多个应用进行故障诊断，而不必加载或激活任一个应用。另外，用户能够添加用于标识经常发生的配置问题的自定义规则。

Description

确认分布式应用的配置

背景

1.1.背景和相关技术

计算机系统和相关技术影响社会的许多方面。的确，计算机系统处理信息的能力已转变了人们生活和工作的方式。计算机系统现在通常执行在计算机系统出现以前手动执行的许多任务（例如，文字处理、日程安排和会计等）。最近，计算机系统彼此耦合并耦合到其他电子设备以形成计算机系统和其他电子设备可以在其上传输电子数据的有线和无线计算机网络。因此，许多计算任务的执行分布在多个不同的计算机系统和/或多个不同的计算环境中。

在一些环境中，分布式应用的不同组件驻留在不同的计算机系统上并且进行互操作以实现该分布式应用的功能。一些分布式应用相对较简单，或许在两个不同的计算机系统中的每一个处具有一个组件。由此，将这些组件配置成互操作也是相当简单的。

然而，其他分布式应用可能较大、相对较复杂、并且高度互连且具有不同的实现和配置。例如，分布式应用可以在数十或甚至数百个不同的计算机系统处具有组件。可用于每一个组件的配置模型的灵活性也是相对广泛的。在试图标识和解决关于分布式应用的配置问题时，这些组件的数量及其配置的复杂性的组合可导致挑战。当分布式应用被主存在支持诸如多层配置层次、配置锁定和降级等强大的配置特征的复杂的服务器产品上时，这些挑战甚至可能更加困难。

当出现差错时，一些系统向应用所有者即便有帮助也是提供极少的帮助。其他系统提供差错消息，该消息在出现差错时向应用开发者提供至少某些信息。然而，即使这些消息存在，这些类型的差错消息也通常不足以解决差错。例如，这些类型的差错消息可能仅涉及分布式应用的少量（或甚至单个）组件。因此，应用所有者必须单独地激活每一个组件以查看该组件的运行时差错。因此，对多个互连应用组件进行故障诊断通常是具有挑战性的体验。

简要概述

本发明涉及用于确认分布式应用的配置的方法、系统和计算机程序产品。规则引擎从规则存储中访问配置确认规则。配置确认规则被配置成对配置数据执行以确认应用的至少部分配置。配置确认规则包含规则元数据、检测逻辑和解决逻辑。规则元数据从一个或多个配置读取器中标识配置确认规则将从中读取配置数据的至少一个配置读取器。检测逻辑指示如何检测从所标识的配置读取器访问的配置数据中的一种或多种状况。解决逻辑表示针对该一种或多种可检测状况的一个或多个可能的解决方案。

规则引擎基于在规则元数据中标识出至少一个配置读取器来将所访问的配置确认规则与该至少一个所标识的配置读取器进行匹配。规则引擎从至少一个所标识的配置读取器中访问配置数据的一部分。规则引擎尝试通过对所访问的配置数据的一部分执行检测逻辑来确认应用的至少部分配置。检测逻辑的执行包括尝试检测该检测逻辑被配置成检测的一种或多种状况中的任一种。

规则引擎在所访问的配置数据的一部分中检测来自该一种或多种状况中的状况。规则引擎在用户界面呈现至少检测到的状况。针对检测到的状况的一个或多个可能的解决方案也能够与该检测到的状况一起呈现。

提供本概述以便以简化的形式介绍将在以下的详细描述中进一步描述的一些概念。本概述并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

本发明的附加特征和优点将在以下描述中叙述，且其一部分根据本描述将是显而易见的，或可通过对本发明的实践来获知。本发明的特征和优点可通过在所附权利要求书中特别指出的工具和组合来实现和获得。本发明的这些和其他特征将通过以下描述和所附权利要求书变得更加显而易见，或可通过对下文中所述的本发明的实践来领会。

附图简述

为了描述可获得本发明的上述和其他优点和特征的方式，将通过参考附图中示出的本发明的具体实施例来呈现以上简要描述的本发明的更具体描述。可以理解，这些附图仅描述本发明的典型实施例，从而不被认为是对其范围的限制，本发明将通过使用附图用附加特征和细节来描述和说明，在附图中：

图1示出了方便确认分布式应用的配置的示例计算机体系结构。

图2示出了用于尝试确认分布式应用的配置的示例方法的流程图。

图3示出了方便使用配置确认规则的可扩展性和依赖关系模型的示例计算机体系结构。

图4示出了用于规则API的统一建模语言（“UML”）类图的示例。

详细描述

在一些实施例中，配置确认规则被配置成对配置数据的多个部分执行以确认应用的至少部分配置。由此，规则引擎可以从配置读取器中访问配置数据的多个部分。另选地或组合地，规则引擎可以从多个不同的配置读取器中访问配置数据的一部分。

例如，规则引擎可以从第一配置读取器中读取配置数据的第一部分。该配置数据的第一部分可具有第一格式。规则引擎可以从第二配置读取器中读取配置数据的第二部分。该配置数据的第二部分可具有第二格式。

该配置数据的第一和第二部分可以从相同或不同的位置读取。该第一和第二格式可以是相同的格式或者可以是不同的格式。应用可以是本地、独立或分布式应用。

该配置数据的第一和第二部分被合并成表示该应用的至少部分配置的分布式应用配置。对分布式应用配置执行配置确认规则以尝试确认该应用的至少部分配置。可以在用户界面呈现任何检测到的状况，可能连同针对检测到的状况的可能的解决方案一起呈现。

本发明的各实施例可包括或利用专用或通用计算机，该专用或通用计算机包括诸如例如一个或多个处理器和系统存储器等计算机硬件，如以下更详细讨论的。本发明范围内的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。由此，作为示例而非限制，本发明的各实施例可包括至少两种显著不同的计算机可读介质：计算机存储介质和传输介质。

计算机存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储设备、或可用于存储计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的任何其他介质。

“网络”被定义为允许在计算机系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一个通信连接（硬连线、无线、或者硬连线或无线的组合）传输或提供给计算机时，该计算机将该连接适当地视为传输介质。传输介质可包括可用于携带计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的网络和/或数据链路。上述的组合也应被包括在计算机可读介质的范围内。

此外，在到达各种计算机系统组件之后，计算机可执行指令或数据结构形式的程序代码装置可从传输介质自动传输到计算机存储介质（或反之亦然）。例如，通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块（例如，“NIC”）内的RAM中，然后最终被传输到计算机系统RAM和/或计算机系统处的较不易失性的计算机存储介质。因而，应当理解，计算机存储介质可被包括在还利用（或甚至主要利用）传输介质的计算机系统组件中。

计算机可执行指令例如包括，当在处理器处执行时使通用计算机、专用计算机、或专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可以是例如二进制代码、诸如汇编语言之类的中间格式指令、或甚至源代码。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述特征或动作。相反，上述特征和动作是作为实现权利要求的示例形式而公开的。

本领域的技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践，这些计算机系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。本发明也可在其中通过网络链接（或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组合）的本地和远程计算机系统两者都执行任务的分布式系统环境中实施。在分布式系统环境中，程序模块可以位于本地和远程存储器存储设备二者中。

图1示出了方便确认分布式应用的配置的示例计算机体系结构100。参考图1，计算机体系结构100包括配置确认框架151，该确认框架151还包括配置读取器101、规则引擎102、规则API104和规则存储103。配置确认框架151还可任选地包括一个或多个附加配置读取器，包括配置读取器121。配置确认框架151的每一个组件以及可能的用户界面106可经由计算机系统的系统总线来彼此连接。因此，各组件可以通过系统总线彼此通信。

分布式应用107的各组件可分布在多个和可能的数十个、数百个或甚至数千个不同的计算机系统上。配置文件108存储关于分布式应用107的不同组件的配置数据。配置文件108可包括诸如配置数据111、112和113等也分布在多个不同的计算机系统上的配置数据的不同部分。配置数据的不同部分还能够不同地格式化并且可适用于分布式应用107的不同组件。例如，配置数据111可具有一个格式而配置数据112可具有不同的第二格式。

由此，分布式应用107的各组件、配置文件108的不同部分和配置确认框架151可通过诸如局域网（“LAN”）、广域网（“WAN”）和甚至因特网等网络彼此连接（或作为网络的一部分）。因此，分布式应用107的各组件、配置文件108的不同部分和配置确认框架151以及任何其他连接的计算机系统及其组件都可以创建消息相关数据并通过网络交换消息相关数据（例如，网际协议（“IP”）数据报和利用IP数据报的其他更高层协议，诸如传输控制协议（“TCP”）、超文本传输协议（“HTTP”）、简单邮件传输协议（“SMTP”）等）。

分布式应用107可以是主存在同一应用服务器下的多层和/或互连应用的组合。在一些实施例中，分布式应用107是web服务/工作流应用。例如，分布式应用可以是主存在网际信息服务（“IIS”）上的WindowsCommunicationFoundation（“WCF”）/WindowsWorkflowFoundation（“WF”）应用。在这些实施例中，配置文件108可包含用于将分布式应用107配置成在IIS环境中操作的配置数据。本发明的各实施例还可用于确认网站配置。

一般而言，配置读取器被配置成从配置文件108中读取不同位置的和/或不同地格式化的配置数据，并将该不同位置的和/或不同地格式化的配置数据转换成与规则引擎102兼容的规则引擎格式。每一个配置读取器都被配置成将一个或多个不同的配置数据格式转换成规则引擎格式的配置数据。例如，配置数据111可具有第一格式而配置数据112可具有不同的第二格式。配置读取器101可被配置成读取第一格式和不同的第二格式的配置数据，并将第一格式和不同的第二格式的配置数据转换成规则引擎格式的配置数据。

配置数据113可具有不同的第三格式。配置读取器101还可被配置成读取不同的第三格式的配置数据，并将不同的第三格式的配置数据转换成规则引擎格式的配置数据。或者，诸如配置读取器121等另一配置读取器可被配置成读取不同的第三格式的配置数据，并将不同的第三格式的配置数据转换成规则引擎格式的配置数据。

由此，一个或多个配置读取器各自被配置成读取并转换可被包括在配置确认框架151中的一个或多个不同格式的配置数据。该一个或多个配置读取器还可将规则引擎格式的配置数据的不同部分组合在一起以形成（例如，分布式）应用配置。该应用配置可表示（例如，分布式）应用的至少部分配置。

在一些实施例中，配置读取器读取配置数据的一个或多个部分并创建应用配置的存储器中视图。配置读取器可使用外部配置应用程序接口（“API”）来从特定于一种技术的配置系统中读取配置数据。例如，配置读取器可以对IIS主存的应用使用Microsoft.Web.AdministrationAPI。

一般而言，规则存储103存储配置确认规则109。配置确认规则109可包含各种规则，包括配置确认规则131、132等，这些规则检测以下各项中的一个或多个：应用配置中的句法差错、语义差错和最优违背。在一些实施例中，规则存储103是可扩展的并且由规则作者（例如，规则作者153）来维护。

可以向规则作者（例如，规则作者153）展示规则API104以实现新规则。由此，可以向诸如系统管理员或应用开发者等规则作者展示公共编程接口及其文档编制，以创建符合其需求的自定义和可插入确认规则。图4示出了用于规则API的统一建模语言（“UML”）类图400的示例。

一般而言，规则引擎102被配置成接收分布式应用配置和配置确认规则。规则引擎102对分布式应用配置的一个或多个部分应用配置确认规则以尝试确认所表示的分布式应用的配置。在一些实施例中，规则引擎102对分布式应用配置执行配置确认规则集并向用户（例如，应用所有者152）报告检测到的状况。

应用所有者或其他用户可经由显示规则执行的输出的工具（例如，用户界面106）来访问配置确认框架151。在适当时，该工具还可接收与解决检测到的状况相关的用户输入。该工具可以与其他服务器管理产品集成和/或被包括在这些产品中。

配置确认规则通常至少包括元数据和检测逻辑并且还可任选地包括解决逻辑。元数据包含规则的静态属性，诸如名称、描述、类别、严重性等级、置信度水平、问题消息模板、解决方案及其消息模板的列表，等等。检测逻辑（用代码）描述如何检测状况。检测逻辑还构造状况和解决消息的实例（对于一个问题可存在多个解决方案）。解决逻辑（用代码）描述如何解决问题。在一些实施例中，解决逻辑自动解决检测到的状况。在其他实施例中，解决逻辑可以从用户取得附加输入以便于进行半自动化的解决。

在适当时，检测到的状况消息和解决消息可被声明为资源串类型并进行键控以使得可被定位。检测到的状况和解决消息还可包含可替换串以使得能够动态地构造上下文专用消息。

图2示出了用于尝试确认分布式应用的配置的示例方法200的流程图。方法200将参考计算机架构100的组件和数据来描述。

方法200包括从规则存储中访问配置确认规则的动作，该配置确认规则被配置成对配置数据执行以确认应用的至少部分配置，该配置确认规则包含规则元数据、检测逻辑和解决逻辑，该规则元数据从一个或多个配置读取器中标识配置确认规则将从中读取配置数据的至少一个配置读取器，该检测逻辑指示如何检测从所标识的配置读取器中访问的配置数据中的一种或多种状况，该解决逻辑表示针对一种或多种可检测状况的一个或多个可能的解决方案（动作201）。例如，规则引擎102可访问规则131，该规则被配置成对配置数据执行以确认分布式应用107的至少部分配置。如图所示，配置规则131包括元数据135、检测逻辑134和可任选的解决逻辑136。元数据135将至少配置读取器101标识为规则131将从中读取配置数据的配置读取器。检测逻辑134指示如何检测从配置读取器101中访问的配置数据中的一种或多种状况（例如，差错、警告和信息消息）。解决逻辑136表示针对由检测逻辑134检测到的状况的一个或多个可能的解决方案。

元数据135可描述规则131，包括以下各项中的一个或多个：使用什么配置读取器、规则131的名称、规则131的描述、规则131的类别、规则131的严重性等级、规则131的置信度水平、规则131的问题消息模板以及解决方案及其消息模板的列表。

严重性等级可一般指示在被检测到时状况对分布式应用的操作有多有害。严重性等级可包括：差错、警告和信息。差错严重性等级指示检测到的状况很有可能导致分布式应用的执行故障。当检测到具有差错严重性等级的状况时，可以在诸如用户界面106等客户机工具处输出差错消息。警告严重性等级指示将给予关于检测到的状况的警告。警告严重性等级指示检测到的状况可能导致分布式应用中的某种类型的不适当或低效操作（但这不一定导致分布式应用发生故障）。当检测到具有警告严重性等级的状况时，可以在诸如用户界面106等客户机工具处输出警告消息。信息严重性等级指示将给予关于检测到的状况的信息消息（即使故障或不适当/低效操作是不太可能的）。当检测到具有信息严重性等级的状况时，可以在诸如用户界面106等客户机工具处输出信息消息。

方法200包括基于在规则元数据中标识出至少一个配置读取器来将所访问的配置确认规则与该至少一个所标识的配置读取器进行匹配的动作（动作202）。例如，规则引擎102可基于元数据135来将规则131与配置读取器101进行匹配。方法200包括从至少一个所标识的配置读取器中访问配置数据的一部分的动作（动作203）。例如，规则引擎102可以从配置读取器101中访问配置数据111R。配置确认框架151能够在逻辑上将配置数据111R视作已发现的应用配置114，该应用配置表示分布式应用107的至少部分配置。

方法200包括尝试通过对所访问的配置数据的一部分执行检测逻辑来确认应用的至少部分配置的动作，检测逻辑的执行包括尝试检测该检测逻辑被配置成检测的一种或多种状况中的任一种（动作204）。例如，规则引擎102可尝试通过对已发现的应用配置114执行检测逻辑134来确认分布式应用107的至少部分配置。执行检测逻辑134包括尝试检测该检测逻辑134被配置成检测的一种或多种状况中的任一种。

在一些实施例中，尝试确认至少部分配置包括将该至少部分配置与参考应用模型进行比较。该参考应用模型可根据最佳实践来指示用于应用的合适句法和语义。例如，规则引擎102可将分布式应用107的至少部分配置与参考应用模型149进行比较。参考应用模型149可根据用于分布式应用107的最佳实践来指示用于分布式应用107的合适句法和语义。

方法200包括在所访问的配置数据的一部分中检测来自一种或多种状况中的状况的动作（动作205）。例如，规则引擎102可以在已发现的应用配置114中检测状况142。状况142可以是配置文件108中的句法差错、语义差错或最优违背。

方法200包括在用户界面呈现至少检测到的状况的动作（动作206）。例如，规则引擎102可以在用户界面104呈现消息141（例如，差错、警告或信息消息）。消息141包括状况142以及解决方案143。解决方案143表示针对状况142的可能的解决方案。

在一些实施例中，解决方案143取得附加用户输入。由此，在发送消息141后，规则引擎102可等待附加用户输入。响应于接收到消息141，应用所有者153可以在用户界面106输入用户输入144。规则引擎102可使用用户输入144来实现解决命令146。

或者，在其他实施例中，解决方案143不取得附加用户输入。由此，在发送消息141后，规则引擎102能够自动地且在没有附加用户输入的情况下实现解决命令136。

解决命令136可包括编辑命令或用于纠正所标识的状况的其他命令，诸如纠正以下各项中的一个或多个：配置文件108中的句法差错、语义差错和/或最优违背。

在一些实施例中，配置确认规则被配置成对配置数据的多个部分执行以确认应用的至少部分配置。在这些实施例中，规则引擎可以从配置读取器中访问配置数据的多个部分。例如，规则引擎102可以从配置读取器101中访问配置数据111R和112R。另选地或组合地，规则引擎可以从多个不同的配置读取器中访问配置数据的一部分。例如，规则引擎102可结合配置数据111R和112R中的一个或多个来访问配置数据113R。

该配置数据的多个部分被合并成表示该应用的至少部分配置的分布式应用配置。例如，配置数据111R、112R和113R中的两个或更多个可被合并成表示分布式应用107的至少部分配置的已发现的应用配置114。

对分布式应用配置执行配置确认规则以尝试确认该应用的至少部分配置。例如，对已发现的应用配置114执行规则131。可以在用户界面呈现任何检测到的状况，可能连同针对检测到的状况的可能的解决方案一起呈现。例如，可以在用户界面106呈现包括状况142和解决方案143的消息141。自动化或基于输入的任何解决命令（例如146）可以在配置文件108上实现。

在一些实施例中，配置确认规则可具有对一个或多个其他配置确认规则的依赖关系。由此，一些配置确认规则可根据父-子依赖关系模型来定义。可以为父-子配置确认规则对定义各种不同类型的依赖关系中的一种。可使用依赖关系类型来描述父和子配置确认规则之间的关系以及将如何基于父配置确认规则的结果来执行子配置确认规则。依赖关系类型的示例包括：

Isprerequisiteof（作为先决条件）–子规则将在父规则不发动的情况下执行。

Overriddenby（被盖写）-子规则将在父规则发动的情况下执行。如果子规则发动，则来自父规则的执行的结果被盖写。

配置确认规则在其检测期间读取或创建的配置数据可被存储在高速缓存中。由此，任何子规则可重用配置数据。高速缓存可用于隔离规则的检测逻辑，减少代码重复和提高规则执行性能。

一般而言，规则引擎通过例如从.Net类属性（经由汇编反映）或从专用元数据文件中读取规则元数据来发现新规则。规则引擎然后从元数据中创建规则依赖关系树。树中的每一节点都表示一确认规则并具有到其父节点及其子节点的链接。每一链接都可具有相关联的DependencyType（依赖关系类型）属性。

配置确认规则执行次序由规则依赖关系来确定（父规则在其子规则之前执行）。同辈配置确认规则之间的执行次序可由整型元数据属性Order（次序）来确定。如果指定，则同辈配置确认规则将按属性值的升序来执行。花费较长时间执行的配置确认规则可具有较高的Order值以减少平均响应时间。

图3示出了方便使用配置确认规则的可扩展性和依赖关系模型的示例计算机体系结构300。如图所示，计算机体系结构300包括规则301、父规则306、父规则307和高速缓存311。规则301包含元数据302、检测逻辑303和解决逻辑304。规则301对父规则306和307的依赖关系可以在元数据302中指示。在所描绘的安排中，规则301在执行父规则306且未执行父规则307时执行。如果规则301执行，则规则301盖写来自规则306的结果。父规则306和307可将作为执行的结果的数据写到高速缓存311。规则301可以从高速缓存311中读取数据以供执行。

因此，本发明的实施例提供了一种用于标识分布式应用的配置差错和最优非顺从的根本原因的系统框架。该系统框架为平台提供者和客户提供了一种用于创建、扩展和利用简化配置故障诊断体验的工具的强大且一致的方法。使用该系统框架，用户能够访问更多关于应用的信息并同时对多个应用进行故障诊断，而不必加载或激活任一个应用。另外，用户能够添加用于标识经常发生的配置问题的自定义规则，并由此提高他们的日常操作中的总生产力。

本发明可具体化为其它具体形式而不背离其精神或本质特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。因此，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变被权利要求书的范围所涵盖。

Claims

1.一种在计算机系统处的用于尝试确认应用的配置的方法，所述计算机系统包括一个或多个处理器和系统存储器，所述计算机系统还包括一个或多个配置读取器以及规则存储，所述规则存储包含多个配置确认规则，所述一个或多个配置读取器中的每一个都被配置成读取关于来自所述多个配置确认规则中的一个或多个配置确认规则的配置数据，规则引擎被配置成对配置数据应用配置确认规则，所述方法包括：

从所述规则存储中访问配置确认规则的动作，所述配置确认规则被配置成对配置数据执行以确认所述应用的至少部分配置，所述配置确认规则包含规则元数据、检测逻辑和解决逻辑，所述规则元数据从所述一个或多个配置读取器中标识所述配置确认规则将从中读取配置数据的至少一个配置读取器，所述检测逻辑指示如何检测从所标识的配置读取器中访问的配置数据中的一种或多种状况，所述解决逻辑表示针对所述一种或多种可检测状况的一个或多个可能的解决方案；

基于在所述规则元数据中标识出所述至少一个配置读取器来将所访问的配置确认规则与所述至少一个所标识的配置读取器进行匹配的动作；

从所述至少一个所标识的配置读取器中访问配置数据的一部分的动作；

尝试通过对所访问的配置数据的一部分执行所述检测逻辑来确认所述应用的至少部分配置的动作，所述检测逻辑的执行包括尝试检测所述检测逻辑被配置成检测的一种或多种状况中的任一种；

在所述所访问的配置数据的一部分中检测来自所述一种或多种状况中的状况的动作；

在用户界面呈现至少检测到的状况的动作；以及

基于解决策略来对所述检测到的状况应用来自所呈现的一个或多个可能的解决方案的解决方案的动作。

2.如权利要求1所述的方法，其特征在于，将所访问的配置确认规则与所述至少一个所标识的配置读取器进行匹配的所述动作包括将所访问配置确认规则与第一配置读取器和不同的第二配置读取器进行匹配；

从所述至少一个所标识的配置读取器中访问配置数据的一部分的所述动作包括从所述第一配置读取器中访问配置数据的第一部分以及从所述不同的第二配置读取器中访问配置数据的第二部分的动作；

所述方法还包括将所述配置数据的第一部分和所述配置数据的第二部分一起组合成分布式应用配置以供所述配置确认规则使用的动作，所述分布式应用配置表示所述应用的至少部分配置；并且

尝试通过执行所述检测逻辑来确认所述应用的至少部分配置的所述动作包括对所述分布式应用配置执行所述检测逻辑的动作。

3.如权利要求1所述的方法，其特征在于，从所述规则存储中访问配置确认规则的所述动作包括访问依赖于父配置确认规则的子配置确认规则的动作。

4.如权利要求3所述的方法，其特征在于，尝试确认所述应用的至少部分配置的所述动作包括所述子配置确认规则从高速缓存中访问结果数据的动作，所述结果数据由所述父配置确认规则来写到所述高速缓存。

5.如权利要求3所述的方法，其特征在于，还包括检测所述父配置确认规则未执行的动作；并且

尝试确认所述应用的至少部分配置的所述动作包括尝试响应于检测到所述父配置确认规则未执行来确认所述应用的至少部分配置的动作。

6.如权利要求1所述的方法，其特征在于，还包括在从所述规则存储中访问配置确认规则之前，规则作者通过规则应用程序接口(“API”)来输入所述配置确认规则以便存储在所述规则存储中的动作。

7.如权利要求1所述的方法，其特征在于，尝试通过执行所述检测逻辑来确认所述应用的至少部分配置的所述动作包括将所述至少部分配置与参考应用模型进行比较的动作。

8.如权利要求1所述的方法，其特征在于，检测状况的所述动作包括检测所述配置数据的一个或多个部分中的句法差错、语义差错或最优违背中的一个的动作。

9.如权利要求1所述的方法，其特征在于，检测状况的所述动作包括检测以下各项中的一个的动作：指示所述应用的至少部分配置中的差错的状况、批准关于所述应用的至少部分配置的警告的状况以及批准提供关于所述应用的至少部分配置的信息的状况。

10.如权利要求1所述的方法，其特征在于，对所述检测到的状况应用来自所呈现的一个或多个可能的解决方案的解决方案的所述动作包括自动编辑配置数据的一部分以纠正句法差错、语义差错和最优违背中的一个或多个的动作。

11.如权利要求1所述的方法，其特征在于，呈现至少检测到的状况的所述动作包括与针对检测到的状况的可能的解决方案一起呈现所述检测到的状况的动作，所述可能的解决方案请求与解决所述检测到的状况相关的用户输入；

所述方法还包括在对所述检测到的状况应用解决方案之前接收与纠正所述检测到的状况相关的用户输入的动作；并且

对所述检测到的状况应用解决方案的所述动作包括所述解决逻辑使用所述用户输入来解决所述检测到的状况的动作。

12.一种在计算机系统处的用于尝试确认应用的配置的方法，所述计算机系统包括一个或多个配置读取器和规则存储，所述规则存储包含多个配置确认规则，所述一个或多个配置读取器中的每一个都被配置成读取关于来自所述多个配置确认规则的一个或多个配置确认规则的配置数据，规则引擎被配置成对配置数据应用配置确认规则，所述方法包括：

从所述规则存储中访问配置确认规则，所述配置确认规则被配置成对配置数据执行以确认所述应用的至少部分配置，所述配置确认规则包含规则元数据、检测逻辑和解决逻辑，所述规则元数据从所述一个或多个配置读取器中标识所述配置确认规则将从中读取配置数据的至少一个配置读取器，所述检测逻辑指示如何检测从所标识的配置读取器中访问的配置数据中的一种或多种状况，所述解决逻辑表示针对所述一种或多种可检测状况的一个或多个可能的解决方案；

基于在所述规则元数据中标识出所述至少一个配置读取器来将所访问的配置确认规则与所述至少一个所标识的配置读取器进行匹配；

从所述至少一个所标识的配置读取器中访问配置数据的一部分；

尝试通过对所访问的配置数据的一部分执行所述检测逻辑来确认所述应用的至少部分配置，所述检测逻辑的执行包括尝试检测所述检测逻辑被配置成检测的一种或多种状况中的任一种；

在所述所访问的配置数据的一部分中检测来自所述一种或多种状况中的状况；

与针对检测到的状况的一个或多个可能的解决方案一起呈现所述检测到的状况；以及

基于解决策略来对所述检测到的状况应用来自所呈现的一个或多个可能的解决方案的解决方案。

13.一种在计算机系统处的用于尝试确认应用的配置的系统，所述计算机系统包括一个或多个配置读取器和规则存储，所述规则存储包含多个配置确认规则，所述一个或多个配置读取器中的每一个都被配置成读取关于来自所述多个配置确认规则的一个或多个配置确认规则的配置数据，规则引擎被配置成对配置数据应用配置确认规则，所述系统包括：

用于从所述规则存储中访问配置确认规则的装置，所述配置确认规则被配置成对配置数据执行以确认所述应用的至少部分配置，所述配置确认规则包含规则元数据、检测逻辑和解决逻辑，所述规则元数据从所述一个或多个配置读取器中标识所述配置确认规则将从中读取配置数据的至少一个配置读取器，所述检测逻辑指示如何检测从所标识的配置读取器中访问的配置数据中的一种或多种状况，所述解决逻辑表示针对所述一种或多种可检测状况的一个或多个可能的解决方案；

用于基于在所述规则元数据中标识出所述至少一个配置读取器来将所访问的配置确认规则与所述至少一个所标识的配置读取器进行匹配的装置；

用于从所述至少一个所标识的配置读取器中访问配置数据的一部分的装置；

用于尝试通过对所访问的配置数据的一部分执行所述检测逻辑来确认所述应用的至少部分配置的装置，所述检测逻辑的执行包括尝试检测所述检测逻辑被配置成检测的一种或多种状况中的任一种；

用于在所述所访问的配置数据的一部分中检测来自所述一种或多种状况中的状况的装置；

用于与针对检测到的状况的一个或多个可能的解决方案一起呈现所述检测到的状况的装置；以及

用于基于解决策略来对所述检测到的状况应用来自所呈现的一个或多个可能的解决方案的解决方案的装置。