CN101410795A

CN101410795A - 可伸缩的对监控规则的同步与异步处理

Info

Publication number: CN101410795A
Application number: CNA2004800012554A
Authority: CN
Inventors: D·R·贝克; S·J·孟席斯; R·W·麦克卢; R·R·帕朗卡
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2003-10-24
Filing date: 2004-07-27
Publication date: 2009-04-15
Anticipated expiration: 2024-07-27
Also published as: WO2005045739A2; WO2005045739A3; US20050114494A1; CN101410795B; US7539974B2; JP5030592B2; JP2007519075A; KR20060112184A; EP1678653A4; KR101203224B1; EP1678653A2

Abstract

一种规则运行时引擎，用于调度和并发处理规则。该引擎有效地以并行方式运行大量规则。这是通过用一种规则定义语言编写规则来实现的，将这些规则通过翻译器传送给运行时引擎，并且使用运行时引擎调度和并发处理经翻译的指令。该引擎还接收配置数据，它实例化指令以给出一组现实的规则的表格。

Description

可伸缩的对监控规则的同步与异步处理

交叉引用

本申请要求2003年10月24日提出的题为SCALABLE SYNCHRONOUS ANDASYNCHRONOUS PROCESSING OF MONITORING RULES(可伸缩的对监控规则的同步与异步处理)的美国专利申请序列号No.10/693,072的优先权，在此包括其整体；并且涉及下列共同待批的美国专利申请：于2003年10月23日提出的，序列号为No.10/692,216，题为“MODEL-BASED MANAGEMENT OF COMPUTER SYSTEMS ANDDISTRIBUTED APPLICATIONS(计算机系统与分布式应用的基于模型的管理)”；于2003年10月24日提出的，序列号为No.10/692,660，题为“RULES DEFINITIONLANGUAGE(规则定义语言)”；于2003年10月24日提出的，序列号为No.10/693,588，题为“USING URI’S TO IDENTIFY MULTIPLE INSTANCES WITH ACOMMON SCHEMA(使用URI用公共大纲识别多个实例)”；以及于2003年10月23日提出的，序列号No.10/692,432，题为“USE OF ATTRIBUTION TO DESCRIBEMANAGEMENT INFORMATION(使用属性描述管理信息)”。

技术领域

本发明涉及软件应用的系统管理，且更明确地，涉及用于异步处理规则的规则引擎。

背景技术

传统的系统管理主要为特定的。应用程序开发者没有一个结构化的框架用于管理它们的应用程序并实现高可靠性。用于便于这类管理体系结构的许多语言原本是单线程化的并且增加了对多任务的支持。因此，在那些语言中通过操作系统支持的诸如线程之类结构实现多任务就是用户的职责。

使用基于规则的机制在软件中提供了灵活性，使得任务与数据能够通过替换一个或多个规则而被容易地改变。最基本的要素是规则，它实现用于评估条件与启动动作的逻辑。例如，一个规则可监视系统盘的状态并在盘利用率变得低于某个阈限时报告错误。另一个规则监控处理器使用率并在使用率超过某个阈限时报告错误。在一个典型的监控系统中，两个规则同时运行。如果用户希望使用一种典型的编程语言，例如Visual Basic.Net，则该用户必须在表达规则意图的逻辑之外，还要编写对这些规则进行调度使得它们同时运行的代码。

所需要的是一种改进的基于规则的引擎，它便于对大量规则的并发处理。

发明概述

下面提供本发明的简化概要，以便提供对本发明某些方面的基本理解。本概要不是本发明的扩展综述。目的不是要确定本发明的关键/重要元素或者描绘本发明的范围。唯一的目的是以简化的形式提供本发明的某些概念，作为在稍后提供的更详细描述的序言。

在此所揭示并申请专利的本发明，在其一个方面，包括将规则翻译成指令的翻译器组件，便于在规则运行时引擎中对指令的并发处理。翻译器组件便于指令的实例化，使得所有状态由运行时引擎保存。指令包括让步语句(yieldstatement)，它便于调用实用功能和让步于运行时引擎的代码执行切换。

在其另一方面，提供一种创新的基于模型的管理框架的规则引擎，它允许开发者容易地编写大量规则，它们表达一个健康的系统所必须满足的准则。该框架提供一种运行时体系结构，它便于对大量规则的调度和并发处理。

监控规则引擎处理规则的自动调度，从而将此负担从用户处卸下并允许用户集中于只表达监控逻辑。例如，可编写一个规则，表达“如果我的盘使用超过80％，则向系统管理员报警”的意图。监控规则，就象在非计算机世界中的任何规则主体一样，是被同时隐含地处理的，因此所有规则在概念上是同时有效的(除非是显式编写的)。规则引擎提供运行时体系结构，它以这样一种方式，即从用户处将这个表达规则调度的负担提取出来，来便于这种隐含的对大量规则的并发处理。因此，要求用户所做的全部就是编写这些规则而不用管调度，并且由系统来照顾调度与并发处理。

规则引擎支持一种称为RDL(规则定义语言)的规则语言。规则监控系统提供下列高级需求：固有并行性-同时监视多事物；相关性；易于使用；随着规则数量的低存储器足迹和线性增长；低CPU使用率；以及可扩展性，容易地利用与扩展现有的规则与运行时软件。

上述需求，尤其是易于使用和固有并行性，对规则引擎的设计给予有利的影响。大多数其它语言原本是单线程化的并增加了对多任务的支持。然而，RDL语言与此完全不同，因为它被设计成固有地支持规则的逻辑并行执行，因此规则开发者不必费劲于实现同时的规则评估。由于固有并行性，因此这一体系结构支持在多个线程之间对规则的调度。

为实现前述与有关目标，在此结合下列描述与附图来描述本发明的某些说明性方面。然而，这些方面只表示可使用本发明原理的各种方法的一小部分，而本发明旨在包括所有这样的方面及其等价方面。本发明的其它优点与新颖特征可在结合附图考虑时通过下面本发明的详细描述而变得显而易见。

附图说明

图1例示本发明组件的方框图。

图2例示规则监控过程的流程图。

图3例示依照本发明的规则实例化的流程图。

图4例示规则对规则调用过程的流程图。

图5例示使用依照本发明的规则引擎的基于模型的管理体系结构。

图6例示与描述基于模型的管理体系结构的主要组件有关的附图映象。

图7A例示与基于模型的管理体系结构的模型组件相关的块。

图7B例示与基于模型的管理体系结构的说明清单组件相关的块。

图7C例示依照基于模型的管理体系结构用于管理应用或服务的系统组件的核心系统API的方框图。

图7D例示基于模型的管理体系结构的系统组件的与管理有关的API的方框图。

图7E例示基于模型的管理体系结构的任务组件的主要子组件。

图8例示基于模型的管理的过程的流程图。

图9例示实现基于模型的管理的过程的更详细的流程图。

图10例示实现所想要的基于模型的管理状态的过程的流程图。

图11例示可用于执行所揭示的体系结构的计算机的方框图。

图12例示依照本发明的示例性计算环境的示意性方框图。

详细说明

现在参考附图描述本发明，其中在全文中相同的标号用于标示相同的元素。在下面的描述中，为了说明的目的，阐述了众多特定细节以便提供对本发明的彻底理解。然而，明显的是，可在没有这些特定细节的情况下实施本发明。在其他实例中，以方框图形式示出众所周知的结构和设备以便于对本发明的描述。

如在本申请中所使用的，术语“组件(component)”和“系统(system)”意在指与计算机有关的实体，即硬件、软硬件组合、软件或者执行中的软件。例如，组件可以是，但不限于，在处理器上运行的进程、处理器、对象、可执行体、执行的线程、程序和/或计算机。作为说明，在服务器上运行的应用程序与服务器都可以是组件。一个或多个组件可驻留在进程和/或执行的线程内，并且组件可位于一个计算机上和/或分布在两个或多个计算机之间。

现在参考图1，这里例示了本发明的组件的方框图。这里提供一种规则监控系统100，它便于以同时发生方式运行规则。监控系统100包括三个逻辑实体：输入指令组件102(称为规则定义语言(RDL))，它表达输入到系统100的一个或多个规则104；翻译器组件106，它读取指令102并将它们翻译成并行执行形式；以及规则运行时引擎108，它读取经翻译的指令并且便于对经翻译指令的有效调度与并行处理。

RDL指令102允许为监控软硬件组件可用性的目的定义规则。例如，一个规则监视系统盘的状态并且在盘利用率变得低于某个阈限时报告错误。另一个规则监控CPU使用率并且在使用率超过某个阈限时报告错误。在一个典型的监控系统中，两个规则同时运行。

运行时引擎108将用RDL表达的规则代码以及用于实例化规则代码的配置数据110作为输入。规则代码被组织成一系列规则类型。每种类型表示一种逻辑，它是确定硬件和/或软件目标是否处在正被监控的系统的一种所想要的状态中所需要的逻辑。如果该类型确定目标不在所想要的状态中，通常它就执行某个动作。例如，下面的代码使用一种规则类型，它在系统变成处在一种非想要的状态中时抑制发送大量的错误事件。注意，规则逻辑是由RuleType...EndRuleType关键字分开并由它们包围。该代码由翻译器组件106翻译并被载入到规则引擎108中，因而将它放到一种可将它实例化的状态中。通过将配置数据110载入到运行时引擎108中来实例化规则代码，其中配置数据指定要运行哪些规则以及运行该规则所需要的参数。

通常，如果用户希望使用一种典型的编程语言，则需要在表达规则意图的逻辑之外还要编写代码以调度规则同时运行。本发明新颖的规则引擎108处理对规则的调度，从而从用户卸下这种负担并且使用户能够集中于表达监控逻辑。

为了便于调度，用RDL编写规则并且随后可以将它们翻译成任何合适的语言，例如C#。经翻译的代码被设计成通过将“提供(yielding)”语义引入代码来支持在大量的规则之间进行调度。在这种情况下，“提供(yield)”导致从规则代码到引擎代码并进入其它规则代码的上下文切换。这允许规则引擎108用有限数量的线程来使规则多任务化。

在下面的规则中，配置数据指定DnsRule为要运行的规则，并且它为TimeLimit、CountLimit和RestartInterval参数提供值。

RuleType DnsRule(TimeLimit As Integer，CountLimit As

Integer，RestartInterval As Integer)

Dim Count as Integer

Do

Count＝0

e＝GetEvent(″system″，″microsoft.dns″，″4514″)

Within Seconds(TimeLimit)

Do

e＝GetEvent(″system″，″microsoft.dns″，″4514″)

Count+＝1

Loop

Else

If Count＞Limit Then

DisableDnsEvents()

End If

End Within

Wait(RestartInterval)

ReenableDnsEvents()

Loop

End RuleType

为了以并行方式运行已实例化的规则，翻译器组件106将规则代码翻译成一种中间形式，它便于与运行时引擎108的交互。将中间形式设计成这样，使得规则的所有状态(自变量与局部变量)由引擎108保存。规则让步于代码执行切换的引擎108的运行库，并且调用由引擎108提供的实用功能。经翻译的代码将周期性让步指令插入代码中。在上面的例子中，翻译将在每次循环结束处并至少在GetEvent调用之后提供。

上面的代码示例以自变量与局部变量两者的形式保存状态信息。例子分别包括TimeLimit和Count。当引擎108暂停该代码的执行时，这些变量的状态被保存，因此在下一次由引擎108执行该代码时是可用的。

Within块提供一个使用引擎108上的实用功能的例子。在上面的代码中，存在一个Within...End Within语句块，它使引擎108对所包含的代码实施时间限制。如果所包含的代码占用超过所指定运行的时间，则引擎108自动地使该块的Else部分运行，同时结束在Within...Else语句之间代码的执行。这个块的经翻译版本发送指令给已经进入过Within块的引擎108。引擎108随后监控规则代码的执行并且执行合适的动作使得表明先前描述的语义。

在规则监控中，等待直到一个特定的事件发生为止，随后行动，这是非常普通的。引擎108支持对大量事件的有效等待，同时使它易于在代码中表达这种等待。GetEvent指令调用便于地表达等待直到某事发生为止(受由Within语句表达的时间限制束缚)并随后对该信息作出行动的愿望。GetEvent指令被翻译，使得引擎108将该代码置为睡眠并且等待代表它的事件。当事件发生时，该代码恢复运行并且允许对事件作出动作。

总之，引擎108有效地以并行方式运行大量规则。这是通过用RDL编写规则、将这些规则通过翻译器106并随后传到运行时引擎108来实现的。引擎108接收实例化指令并因而形成一组现实的规则的配置数据。

要意识到，规则引擎与其所有组件可以包含在计算机可读介质中。

现在参考图2，这里例示了规则监控过程的流程图。尽管为了简化说明的目的，在此示出的一个或多个方法(例如以流程图形式)，被示为和描述为一系列的行为，但要理解和意识到，本发明不受限于行为的顺序，因为依照本发明，有些行为可按不同的顺序和/或与其它在此所示与描述的行为同时发生。例如，那些本领域熟练技术人员将理解和意识到，可替换地，可将一种方法表示为一系列相关的状态或事件，如在状态图中。而且，依照本发明要实现一种方法并不要求所有被例示的行为。

在200，规则被接收到系统中并且用RDL编写。在202，规则被翻译成一种中间形式，它便于与规则引擎的交互。在204，将经翻译的规则载入运行时引擎中。在206，引擎接收配置数据以实例化经编码和经翻译的规则。在208，经翻译的规则既由运行时引擎调度，又由它处理以便并行处理。该进程随后到达停止(Stop)块。

现在参考图3，这里例示了依照本发明进行规则实例化的流程图。在300，将规则翻译成用于与引擎交互的中间形式。在302，引擎保存规则的所有状态。在304，经翻译的形式将让步指令插入代码中。在306，经翻译的形式让步于规则代码执行的引擎运行库。在308，经翻译的形式调用由引擎提供的实用功能。该进程随后到达停止(Stop)块。

翻译算法

在翻译期间，为每一合适的节点产生深度优先遍历标签和临时变量，使得顺序为从左至右和从底至顶。每一被标注的节点(不是所有节点将检索标签)产生临时变量赋值、对随后的标签的指令块赋值和返回语句。本翻译算法具有易于编码的好处。它产生许多指令块，并用返回到引擎。下面例示一个简单的赋值语句的翻译(为了可读性使用了简写符号)。

r Ln-将指令块设置为Ln并返回。

RDL：

myObject.Property＝a+b-c

赋值语句的翻译如下：

case L1：

T1＝myObject；

r L2；

case L2：

T2＝a；

r L3；

case L3：

T3＝b；

r L4；

case L4：

T4＝c；

r L5；

case L5：

T5＝T3-T4；

r L6；

case I6：

T6＝T2+T5；

r L7；

case L7：

T1.Property＝T6；

r L8；

用RDL编写的规则可以分组成模块。模块可以用编译器，例如Visual BasicStandardModuleAttribute翻译成类，如下所示：

{Microsoft.VisualBasic.CompilerServices.StandardModuleAttribu

te]

public class MyRules

{

...

}

经翻译的代码被分解成一系列指令块。指令块被分成switch-case(开关盒)块并且规则框架具有一个保存当前块的字段。指令块等价于MSIL(Microsoft中间语言)地址，尽管翻译块不具有与MSIL中相同级别的粒度。MSIL是一种用作许多编译器(例如C#，VB和.NET)的输出的语言。每个指令块代表一个工作项，其意义在于在块内的所有代码作为一个单元执行，因此让步于引擎发生在块之间。

下面的代码示出一个简单的例子，即如何使用指令块。下面所示的规则被分解成三个不同块。每个块以返回语句结束。在规则返回到引擎之前，用在下次重新进入该规则时应当执行的指令块来更新规则框架。如果在switch语句内出现break(中断)，如在第二个块中所示，则终止该规则。

规则在终止前启用IExecution.SetCallerFrame()，因此引擎将在下次进入这个调用者规则。

[Startup]

public static void Rule2(IExecutionStack stack)

{

switch(SC.InstructionBlock)

{

case 0：

LocalFrame_Rule2 1f＝new LocalFrame_Rule2()；

SCL＝1f；

((LocalFrame_Rule2)SCL).i＝0；

SCIB＝1；

return；

case 1：

if(！(((LocalFrame_Rule2)SCL).i＜＝10))

{

break；

}

SCIB＝2；

return；

case 2：

((LocalFrame_Rule2)SCL).i++；

SCIB＝1；

return；

}

stack.SetCallerFrame()；

}

翻译所有的规则，使得它们具有一个签名，例如下面的签名：

public static void RuleName(IExecutionStack stack)

返回值与参数均位于堆栈中。如所示的，将所有规则实现为静态函数，它们是在其中定义它们的模块的成员。模块被翻译成类，如在本文中其它地方所讨论的。

规则名称精确地匹配在RDL文件中表达的名称。下面是一个规则名称的例子，它是完全合格的名称：

Namespace.ModuleName.RuleName

启动规则用启动属性<Startup>标记。所有启动规则由规则引擎在成功载入后启用。

Rule MyRule

End Rule

经翻译的启动规则如下：

[Startup]

public static void MyRule(IExecutionStack stack)

如果经启动通过ByRef(通过引用)传递ValueType，则它只经下面的机制接收一个副本。这意味着在调用者中的原始副本不改变。

现在参考图4，这里例示了规则对规则启用的过程的流程图。RDL容许一个规则启用其它规则。规则对规则启用包括在经翻译代码中的下列步骤。在400，为调用者设置返回地址(一个case块值)。在402，创建与被调用者相关联的规则框架(“RuleFrame”)。在404，规则框架的构造函数委托给经翻译的函数并且由引擎使用来作出实际的调用。在406，在框架内设置被调用者函数的参数。在408，随后将被调用者框架推入堆栈，且流程返回到引擎。步骤400-408代表序言。在410，设置调用者的堆栈。在412，被调用者框架从堆栈中弹出。在414，为任何ByRef参数设置局部变量。流程随后返回到引擎，如在416所示。步骤412和414代表结语。

RDL表达式近似一对一地用经翻译的代码映射，除了在下列条件之下例外：当表达式包含规则启用时；以及当表达式包含任何异步函数启用时。当表达式包含这些类型的项时，表达式被分解成三地址代码(three-address code)。编译器以自顶而下和自左而右的方式遍历树，并且在每一节点发出基本的翻译。当遍历抽象语法树(AST)时，获得标签和临时变量标志。

RDL包含两种范围的变量：自变量和局部变量。当完全简化了表达式求值时，可以对自变量或者局部变量进行赋值，并且将被翻译。

每一经翻译的函数具有一个相关联的定制的RuleFrame导出类。导出类包含直接与被传递给RDL函数的参数相关的成员。这被翻译成一个函数。

当启用一个函数时，如前所述，在序言中适当地设置在导出的RuleFrame中的成员，并且将RuleFrame推入堆栈。在返回时，如前所述，读取ByRef成员并且适当地将它们传送给在结语中的调用者框架。

在RDL中支持轮询。为了支持轮询，RuleFrame类维护轮询结构的堆栈。堆栈允许在单一函数内嵌套轮询。引擎只依照当前框架和在堆栈顶上的轮询结构进行调度。为了配置轮询，在堆栈顶上建立一个轮询结构。每个轮询块只在它创建轮询结构并将它推入堆栈时调用轮询指令一次。在块进入时，设置时间间隔。随后设置返回指令，并且流程返回到引擎。

引擎随后检查以了解是否已经建立轮询，并且调度执行堆栈来执行。每次设置轮询间隔时，在框架内设置一个标志来表示已经建立了轮询。如果未曾改变轮询间隔，则可以人工地设置轮询标志。引擎在调度之后复位标志。因此，所发出的代码从不复位轮询标志。随后在退出时从轮询堆栈弹出轮询结构。

RDL使用两种数据类型：引用类型；以及值类型。RDL引用数据类型一对一地翻译成编程语言对应部分(例如C#)，并且驻留在局部框架或者规则框架内，取决于它们的范围。在下文相对于变量讨论范围。值类型提供关于封装的几个问题，因为它们不能通过引用传递。它们将被封装在引用类型内。

在RDL中变量具有两种不同位置。变量范围或者在一个函数的参数列表内，或者在函数本身内。如果变量是参数列表的一部分，则在导出RuleFrame指令内产生它们。如果在函数内声明变量，则它们驻留在函数的局部框架内。局部框架是高度专用于一个容器函数的。基RuleFrame类维护一个指向局部框架的引用。

分析者启用等同于任何常规的对象启用。这些启用以两种味道出现：同步和异步。同步启用是直接调用，其中函数的参数和返回值是局部框架上的变量(或文字)。同步启用看上去如下：

((LocalFrame_MyRule)SCL).Value＝

((LocalFrame_MyRule)SCL).objPerformanceCounter.NextValue()；

在某些情况下，方法启用是异步的。这些调用遵循标准异步设计模式。设置返回地址，并且将框架标记为预留的。随后为对象启用异步开始(BEGIN)操作。

((LocalFrame_MyRule)SCL).asyncResult＝

((LocalFrame_MyRule)SCL).asyncDelegate

BeginInvoke(

10000，

out((LocalFrame_MyRule)SCL).MethodOutput，

stack.RuleServices.AsynchronousDispatcher，

stack

)；

最后两个参数提供异步回调，它们是规则引擎的分派程序方法和规则的执行堆栈。最后两个参数是相同的并且是所有异步调用所要求的。第一组参数根据异步组件的性质变化。当异步调用完成时，一个线程被分派给引擎分派处理程序，后者最终将调用传递回规则。

循环

如前所述，规则被分解成一系列指令块。因此，循环分解成条件检查，指令块设置，并返回到引擎。这与MSIL相似，其中分支指令将执行移动到具有一个重要差别的不同地址。在跳转之前，规则总是返回到引擎，因此可实现非抢先式调度。注意，返回到引擎不必意味着将切断任务，因为如果条件保证的话则引擎可立即返回该任务。

循环以与在MSIL中相似的方式构造出映射out(输出)，使得所有循环结构检查结构块结束处的条件，以使它们都共享同一翻译。这意味着，对于一个WHILE循环，在循环之前的指令引起一个初始分支到块的结束处，因此在初始进入时检查条件。

RDL语言被设计为内在地支持许多规则之间的多任务。因此，以这样一种方式构造经翻译的代码，即允许规则引擎用有限数量的线程在大量规则之间切换，因此所得到的体系结构实质上浓缩了非抢先式调度系统。

调度

在描述调度解决方案的要素之前，先保证对问题的清楚描述。考虑一个包含大量规则的规则文档，并且在文档内有下面三个规则，如下所示，称为CheckCDiskSpace，CheckCounter和CreateEvent。还考虑到为了简单起见，规则引擎设置为只使用一个单线程用于在一组任务之间的多任务。(注意，CheckCDiskSpace包含一个属性，将其标记为启动规则并且应当与相似地标记的其它规则并行地运行该规则。)在概念上，规则引擎处理经编译的组装部件并且构造一个必须并行运行的所有规则的列表，例如下面所示的CheckCDiskSpace。

然后将每个规则放在任务执行队列中供规则引擎线程来消耗。在下面所示规则的情况下，CheckCDiskSpace被放在初始执行队列中。在某个时间点上，线程从队列中取出规则并开始执行CheckCDiskSpace。在稍后的某个时间点上，线程遭遇CheckCounter。线程通过在这个内部函数刚出现时就同步地启用它来启用这个内部函数，隐含着经翻译的编程语言代码(例如C#)将几乎精确地出现，如在下面的RDL示例中所示。

然而，这个答案为规则引擎产生了一个问题。假定一个规则包含“While-Sleep(time)-End While(当睡眠(时间)-结束循环)”形式的连续循环，以及假定一个线程进入这个循环。一旦遭遇这种类型的结构，线程进入一种状况，即它不能从这种状况返回并因此为其它任务进行调度。当被调用者消耗过多的时间来进行计算时，发生不太严重的偏差。无论原因是什么，最终结果是任务不足。经翻译的代码必须便于任务切换，因此可以在任务之间调度线程以合理处理。因此，经翻译的代码便于易于协作的多任务，以便函数执行状态可被保存(自变量，局部变量和当前指令)并且在稍后时刻被重建。

<Startup(Parallel:＝True)>

Rule CheckCDiskSpace

DIM Uri as String

DIM Threshold as Double

DIM Value as Double

Uri ＝″\\LogicalDisk(C:)\\％Free Space″

Threshold＝40

If CheckCounter(Uri，Threshold，Value)Then

CreateEvent(Value)

Return False

End If

Return True

End Rule

Function CheckCounter(ByVal URI as String，ByVal

Threshold as Double，ByRef Value as Double)as Boolean

Value＝GetPerfCounter(URI)

If X＞Threshold Then

Return True

End If

Return False

End Function

Function CreateEvent(ByVal Counter)as Boolean

DIM Event as String

Event＝″<Event>CounterEvent″+″<Counter>″+Counter+

″</Counter>″+″</Event>″

RaiseEvent(Event)

Return True

End Function

任务切换

协作的多任务系统要求受调度的任务放弃对线程的控制，以便运行其它任务。由于RDL代码的翻译是受控制的，因此作出关于每个任务在哪里放弃控制的决定。任务简单地通过以正常的方式从当前执行的函数返回来放弃控制。然而，在返回之前，每个任务将更新一个堆栈框架，它包含有关参数、局部变量以及在重新进入时要跳转到函数的什么位置的信息(在下文中有关于堆栈框架的细节)。由于任务切换包含函数返回，因此系统堆栈被解除和丢弃。

因此，系统堆栈可以被限制在一的深度，使得在规则之间的函数调用包括在被调用者函数进入之前返回到运行库。当函数返回到运行库时，可以出现两种执行途径之一。不是运行库直接进入被调用者函数并且开始在同一线程上的执行，就是任务堆栈框架被压入工作项队列并因而引起任务切换。

堆栈框架

为了便于规则之间的任务切换，翻译RDL代码，使得所得到的代码包含用于构造调用框架的指令。这些框架包含函数参数，当前指令块，当前函数和局部变量。只要函数被调用，就构造和连接这些框架，因而，构成调用堆栈。保存这样一个调用堆栈，使指令与计算状态分开，使函数成为无状态的并且便于任务切换。

RuleFrame结构用作基础结构，从它来创建函数专用框架结构。只要调用者函数启动被调用者函数，就创建并填充RuleFrame，并且它具有下列属性：m_RuleDelegate是用于这个框架的函数的代表；m_InstructionBlock是当前正执行(或下一个要执行)的指令块；m_Mode是函数应当被调用的方式(同步或异步)；m_RetVal是函数的返回值；m_LocalFrame包含函数的局部变量；以及m_ParentFrame是这个框架的被调用者函数。

每个函数具有一个定制的框架，它是从RuleFrame结构派生的。下面例示用于上面所示的CheckCounter函数的框架看上去象什么。

class Frame_CheckCounter:RuleFrame

{

string URI；

double Threshold；

DoubleRef Value；

}

每个调用者知道每个被调用者派生的调用框架结构。局部框架结构也专用于它所应用于的函数。下面例示用于CheckCDiskSpace函数的局部框架。

class CheckCounterlLocalFrame:LocalFrame

{

StringRef m_Uri；

DoubleRef m_Threshold；

DoubleRef m_Value；

}

如在上面指出的，RDL支持通过轮询在周期性基础上启用规则的能力。受轮询的规则预期被广泛地使用，并因此，有可能存在成千个这样的规则。下面的RDL代码片段例示一个典型的受轮询的规则。

[Startup]

Rule SetupDiskChecks

Run CheckDisk(″c:″，500000)

Run CheckDisk(″d:″，600000)

Run CheckDisk(″e:″，1230000)

End Rule

[Poll(Minutes(30))]

Rule CheckDisk(Drive as string，Limit as Uint64)

Dim FreeSpace as Uint64

FreeSpace＝

RDL.Get(″#microsoft/os/storage/disk/{0}/freespace″，

Drive)

If FreeSpace＜Limit Then

RDL.RaiseEvent(″Disk drive {0}is below the

limit！″，Drive)

End If

End Rule

上面的规则是由来自规则引擎的线程调用的，在规则内执行计算，并且随后在逻辑上在它的下一次启用之前睡眠三十分钟。要求规则引擎支持潜在的成千个这些类型的规则，同时最小化中央处理器使用率。因此，引擎实现一种算法，用于调度并散开受轮询规则的启用。去同步受轮询规则的问题在预期将有大量规则变成活动的启动期间内是最尖锐的。如果没有及时散开轮询，只要一组任务变成到期，则处理器使用率将周期性地达到峰值。轮询间隔越短，则这个问题变得越尖锐。

当前，预期引擎支持秒粒度的轮询间隔。为了使处理器使用率保持低，人工地用时间间隔将任务分散开，使得目标使用率约略地为百分之五。设置间隔的大小使得任务的处理器密集计算必须不占用超过百分之五的间隔。例如，假定任务要求，平均起来，1GHz处理器的单处理器机器的三毫秒处理器时间。任务散开间隔必须大约为六十毫秒，以便让使用率保持在百分之五。这意味着规则引擎在使用率开始爬到百分之五之上时只能支持总共十六个1秒轮询的规则。

返回到上面的例子，这变得显而易见，即受轮询的规则可以在任何时候被初始化(不只是在启动时，如上所示)。结果，在没有对代码进行某种分析的情况下，引擎在将作出轮询请求时一点也不知道。例如，一千个30秒轮询规则可全部在同一时刻请求轮询或者这些请求可被分散在二十分钟内，取决于如何编写规则。即使这些轮询请求均匀地在二十分钟期间内到达，也不保证引擎将不结束这样一种状态，即以周期性方式在同一时刻启用大量的规则使得每三十秒产生使用率的难看的峰值。

为了最小化这种可能性，引擎利用下面的试探来最小化同步的规则启用。引擎从某个任意绝对时间起以固定的时间增量调度所有任务。当一个规则显式地调用调度函数时，发生调度散开。

RuleEngine.Schedule(RuleFrame ruleFrame，int Interval，

bool firstInvocation)

如果firstInvocation为真，则应用散开算法。否则，按指定的间隔立即调度规则。首先如下调度启用：

Interval＞m_DefaultInterval？t_Interval＝

m_DefaultInterval:t_Interval＝Interval

n＝(int)(1+(t_CurrentTime-m_ReferenceTime)/

m_DefaultInterval)

ScheduledWait＝m_ReferenceTime+n＊m_DefaultInterval-

CurrentTime+Random.Next(t_Interval/MinSpread)，

其中，m_MinSpread是任务之间的最小调度间隔并且在运行时期间被固定(在几十毫秒的数量级上)；m_ReferenceTime是一个固定的时间，从该时间起建立所有查询(规则引擎在启动时设置这个值)；以及，m_DefaultInterval是一个时间间隔，在此期间散开受轮询的启用(这是在分钟数量级上，并且应当足够大以散开数千个轮询而不引起初始启用的不适当的延时)。

计算均匀地将轮询启用散开在一个给定轮询时段的时隙的离散集合上。如果轮询间隔非常大，则在更小的足够大的间隔上散开启用，以便防止启动间隔的不适当延迟。如果没有将小的轮询间隔均匀地散开在它们相应的时段上，则群集影响可以在具有相同轮询间隔的规则之间出现，当它们同相地激发时。

初始规则启动

在启动期间，规则引擎利用反射，并且建立一个任务列表，基于这些被标记了Startup属性的规则来运行。当已经建立了任务列表时，则引擎利用其调度函数来散开所有规则的启动。在一系列批(batch)中启动规则，使得在时间配置的时间间隔(即上面定义的m_DefaultInterval)内调度每一批。这个默认的间隔是可配置的并且可取决于在计算机中使用的处理器数量--处理器越多，间隔越小。

异步函数启用

许多分析者完全是由规则引擎驱动的。这些分析者由规则创建，由规则供给数据，并且随后查询计算的结果。典型的周期按如下发生。创建并初始化分析者，诸如上升斜率。在受轮询的基础上，向操作系统查询性能计数器并将这个数据传递给分析者。然后向分析者询问它是否具有足够的数据来完成计算。如果是，则获得并处理结果。如果否，则等待下一个轮询，并且重新开始周期。下面的RDL片段例示这个周期。

Rule CheckDiskSpace

Dim Obj as RisingSlope＝new RisingSlope(-20，5)

Dim Sample as Double

Dim Result as Double

Poll Seconds(60)

Sample＝GetPerfCounter(″\LogicalDisk(C:)\％

Free Space″)

Obj.Add(Sample)

If Obj.ThresholdBreached()Then

Result＝Obj.GetSlope()

//Send an event

End If

End Poll

End Rule

这个周期在分析者部分上是完全同步的并且不要求用于引擎或者分析者的任何队列。

另一个可替换方案是使分析者异步并且让它在数据可用时通知引擎。引擎随后在通知时检索数据，并处理它。下面的代码例示这个思想。

Rule CheckDiskSpace

Dim Obj as RisingSlope＝new RisingSlope(-20，5)

Dim Sample as Double

Dim Result as Double

Run WaitForBreach(Obj)

Poll Seconds(60)

Sample＝GetPerfCounter(″\LogicalDisk(C:)\％

Free Space″)

Obj.Add(Sample)

End Poll

End Rule

Rule WaitForBreach(ByVal RisingSlope Obj)

Double Result

Do

Result＝Obj.GetSlope()

//Send an event

While True

End Rule

这个模式要求引擎以异步方式启用GetSlope，因此不阻塞线程。在这个模式中，用结果对象将GetSlope调用分解成两个步骤来使调用相关。第一个步骤包括一个Begin(开始)操作方法调用，其中引擎将传入回调函数连同调用框架，并且在返回时接收异步上下文对象。在某个时间点上，分析者启用回调并且提供异步对象。引擎从异步对象获得它的上下文并且用线程池调度规则来执行。当规则执行时，它启用分析者结束操作，传入异步对象，接收调用结果，并且处理这些结果。

由于分析者继续在这种情况下运行，因此有可能的是，它可以在正处理一个结果的同时产生更多的结果。在这种情况下，分析者可以维护一个队列并且等待来自规则的Begin Get(开始取)请求。在许多情况下，不要求这种类型的模型，由于引擎一般供给分析者。对此的一个例外是独立于引擎接收其数据。

基于模型的管理体系结构

现在参考图5，这里例示了利用依照本发明的规则引擎的基于模型的管理体系结构500。基于模型的管理方法使开发者能够按照其组成组件来描述应用或者服务502并且按照功能、配置、安全和性能来描述所想要的状态。因而，应用或服务描述504便于按照一个或多个可管理的组件来描述应用或服务502，这些可管理组件至少包括模型组件506、说明清单(manifest)组件508、系统组件510和任务组件512。基于模型的管理系统500利用属性(attribution)组件514来便于源代码从模型组件506属性到说明清单组件508。

计算机系统516在安装应用502时使用应用或服务描述504来配置与计算机操作系统相关的管理服务518。管理服务518随后通过自动管理动作诸如配置管理、问题检测、诊断和恢复来帮助确保应用或服务502的可用性。模型506还描述了管理员可执行的普通任务。基于模型的管理体系结构500便于较低的所有权总成本，并且在从开发到部署、运行和商业分析的应用生存周期上使用。通常，开发者通过按照应用如何工作，其组成组件，开发者定义并选择监控的所要的健康状态，至少与如何安装它和应用或服务要求的设置有关的配置方面，以及管理任务及其调度，来创建应用或服务的一个或多个模型。然后在特定区域将模型的源代码属性(或加标签)用于列出说明清单。

模型被积累到探测(instrumentation)说明清单中。模型往往是文本文档、电子表格文档等形式的结构化文档，这些文档不是通过代码、脚本、工具就是手工地转换成说明清单，这些说明清单易于成为更多的XML大纲，并易于进一步被机器处理和机器阅读。也就是说，模型文档更多地可由人阅读，而说明清单更多地可由机器阅读。于是使用说明清单以便于系统管理。

属性子组件514与源代码属性相关联。属性用于表达管理信息连同它附属的代码。没有属性，就需要编写两个独立的代码片断--一个用于正常的应用处理而一个用于将它向管理公开。在源代码内的属性用于描述应当使用代码的哪些部分(称为探测器(probe))来确定和/或纠正健康，以及指定何时执行监控规则。探测器可以从访问现有操作系统API(应用程序接口)的组件或从载入运行的应用或服务内部的组件公开。在这两种情况下，开发者添加属性以表示组件内什么类型的子集应当被公开以及应当如何识别它们。使用管理员名字空间内的URI(统一资源标识符)来识别探测器。在运行时，通过从计算机上的所有探测器的目录内识别探测器，并且按照关于该探测器的相关信息来检索该探测器。

源代码属性也可以将指令提供给监控服务，例如，给应当用作监控规则并且在启动时载入、周期性地轮询、在一个事件上运行的属性函数。可以自动处理这个属性并以与装置相同的方式将它放入说明清单。因而，属性不只是装置，而是也可用于其它管理目的。属性也可用于支持行政管理任务和/或纠正动作。

现在参考图6，这里例示了与描述基于模型的管理体系结构500的主要组件有关的附图映象600。体系结构包括相对于图7A描述的模型组件506，相对于图7B描述的说明清单组件508，相对于图7C和图7D描述的系统组件510，以及相对于图7E描述的任务组件512。已经描述了属性，并将在整个说明书中提到它。

现在参考图7A，例示了与基于模型的管理体系结构的模型组件506相关的块。为构成应用的组件、健康状态和恢复、配置设置和行政管理任务而开发了若干模型。

在其支持中，有一个组件模型子组件700用于对系统的任何和所有组件(以及与之相关的关系、依赖关系和服务角色)建立模型。组件模型700描述文件、配置、可以安装应用的不同方法等等。

可以开发健康模型子组件701来描述各种故障状态，以及应用或服务故障的方式。健康模型701描述自动化健康特征所需要采取的步骤。健康模型701至少代表故障状态，检测状态，验证，诊断和系统状态的解决(resolution)。健康状态可以按照必须要符合什么准则才被认为完全健康、完全故障和任何中间状态(例如降级的性能、部分工作、部分客户功能在工作)来描述，并且是提供预期的服务等级的应用或服务。健康还考虑功能是好的，但性能不符合标准，即表示应用或服务不健康。

配置模型子组件702与为系统配置建模相关。配置模型702用于描述应用设置、用户控制、默认值、各种限制等。行政管理任务模型子组件703与为行政管理任务建模相关，并且包括用户在系统上采取的动作，诸如开始、停止、添加用户、添加数据库，以及可从健康模型701调用的纠正动作。模型702枚举可以用应用或服务完成的一切。体系结构模型704用于描述分布式环境和相关的部署，通常与例如大的客户机网络相关，它具有相同或相似硬件和软件设置和配置以及分布式数据库。因而，局部应用可依赖于远程盘阵列。在部署时，盘阵列需要在部署级用说明清单实例化并使用URI。由于URI是与机器不相关的，分布式系统也可以获得基于模型的管理系统的好处。可以开发性能模型705来描述开发者希望使用度量标准用于监控应用或服务的性能的方式。这与系统的健康紧密相关。可以产生安全模型706来描述与应用或服务相关的安全类型。

注意，这里提供的许多模型不是详尽的，因为开发者可以提供许多不同的模型来管理应用或服务的各种方面。

本发明的基于模型的系统可以使用各种基于人工智能方案来实现其各种方面。例如，关于模型，用于确定对于一个给定的实例或实现可以利用什么模型的过程可以通过自动分类系统和过程便于地实现。而且，这样的分类器可用于建立系统的运行简档，即开始检测系统模式，以及学习什么是好状态、坏状态以及成功与不成功的事务。随后可以将这个信息反馈到相应的模型中并且用作下一代系统的更新的模型。这样的分类可以使用基于概率和/或统计的分析(例如，分解成分析效用和成本)来预测或推断用户想要自动执行的动作。例如，可以使用支持向量机器(support vector machine)(SVM)分类器。其它分类方法包括贝叶斯(Bayesian)网络、决策树，并且可以使用提供不同独立性模式的概率分类模型。在这里使用的分类还包括用于开发优先权模型的统计回归。

如易于从本发明说明书中意识到的，基于模型的系统可以使用分类器，它们既受到显式训练(例如通过一般的训练数据)，也受到隐式训练(例如通过观察用户行为，接收外来信息)，因此分类器用于依照预定的准则自动地确定，例如，对于给定的实现使用什么初始设置，并且随后随着时间过去当系统成熟并经历各种关于数据、安装应用的数量和与其交互的节点数量的载荷条件时调整设置。例如，关于很好理解的SVM，是通过分类器构造函数和特征选择模块内的学习或训练阶段来配置SVM的。分类器是一个函数，它将一个输入属性向量x＝(x1，x2，x3，x4，xn)映射到该输入属于一个类的置信度--即，f(x)＝confidence(class)。在管理系统的情况下，例如，属性是所想要的状态的系统参数，并且类是感兴趣的分类或领域(例如，所有驱动器，所有本地进程)。分类器也可以用于捕捉和分析事务日志，查找模式，以及通过查找成功和不成功模式来诊断系统。

配置健康包括，例如，从五到十改变队列大小，并且确定该改变会对应用、服务或系统具有什么影响。这也适用于安全和性能，其中分类器可以用于监控性能计数器并且使系统相应改变从而优化性能。也可以监控并分析安全用于模式，其影响可以用于提议或改变安全策略。因而，要意识到，健康是一个广泛的概念，可以应用于系统的许多领域。在系统级范围内，性能可以是良好的，但安全可能差。因而，跨越系统的许多科目的整体视图是有益的。

所想要的管理员状态可以在代码中表达，在说明清单中将代码披露出来并且通过监控服务传递它用于监控。系统可以根据说明清单中的指令监控应用或服务并且当应用或服务不符合性能时向管理员报警，并且根据这些指令采取纠正动作。例如，在电子邮件的测试设定未被保持而落到时间段的阈限之下的情况下，可以增加另一个机器直到载荷减退，并且网络通信量也可以用作增加资源数量以处理给定载荷的触发器。目标是尽可能自动化，因此仅当要求手工动作时才会涉及管理员。

基于模型的管理系统是可配置的。它是基于组件的，组件几乎包括一切。因而，可以将系统还原为其最低可管理片断并反过来组成它。在数据库中，例如，存在带有实例、数据库、表和存储过程的应用，并且可以与单文件一样小地缩减它。考虑401k的应用。401k应用可以依赖于数据库、web服务器和客户自己的商业逻辑，下降到一个依赖于操作系统并且相关的数据库。想要的是，在各种等级上进行管理和报告。通过组件之间的关系描述应用。这些关系可以表达一个单独的应用是如何装配的(例如，SQL服务器包含服务、实例和数据库)、平台要求(例如操作系统和其它应用)以及与其它组件的通信(连接到SQL服务器的web服务器)。单个管理员可能关心数据库和单个机器，而财务管理员可能关心401k应用，以及CIO关心所有应用和机器。模型、报告和期望状态应当处理一切，使得可以参考各个指标来确定系统是否正在执行预期的内容。

所有模型系于一个URI名字空间，提供一种标准的方法来导航系统、枚举所有安装的组件以及向组件询问它提供什么、什么被认为是健康的、它具有什么事件、在昨天或最近的几小时内发生过什么错误事件、包括什么配置设置、在最近的一小时内发生什么变化等等。

现在参考图7B，这里例示了与基于模型的管理体系结构的说明清单组件508相关的块。与应用一起发货的说明清单包含来自模型的信息和机器可读形式的源代码属性供管理系统服务使用。在说明清单内定义应用的行政管理任务。可以存在相应于模型产生的许多说明清单，包括下列：与组件依赖关系、组件之间的关系和服务角色相关联的第一说明清单子组件707；与事件、探测器、规则和动作相关联的第二说明清单子组件708；与设置和声明相关联的第三说明清单子组件709；与命令(即小命令(cmdlet))和行政管理角色相关联的第四说明清单子组件710；与分布式环境相关联的第五说明清单子组件711；以及与部署相关联的第六说明清单子组件712。

说明清单是开发者与操作团队和管理员之间的“桥”，并且用一种工具自动地创建它，该工具在模型中扫描属性的代码。组件说明清单707由设置引擎使用，以确定如何安装应用或服务。它描述逻辑组件、文件、应当在哪里安装文件以及配置设置(或任何设置)。依赖关系是在安装之前需要定义的内容，并且包括各种角色，以便应用可以以具有变化的安全度以及不同的运行简档的不同模式来安装。组件说明清单707使用户和/或系统更易于知道手工和自动要做的内容。说明清单粒度可以下至每组件一个说明清单。

按照惯例，安装比实际所需的更多的文件。说明清单允许只安装那些需要的文件。这至少提高性能和安全。在说明清单707中定义软件依赖关系。在应用层次，依赖关系可以专用于单个机器并且定义组件关系和硬件资源。计算机可以由说明清单描述，例如，应当将应用部署在特定制造商的双处理器机器上，或者与4处理器机器接口。这个说明清单707描述处理器、存储器、驱动器等到实现所需的硬件粒度的程度。因而，管理可以是更主动的然后是反应性的，如在常规的系统中。硬盘故障可以确定为由热故障引起的，例如，其中随着时间过去监控系统温度，并且监控电源干线电压，但发现是足够的。

健康模型701用于产生健康说明清单708。健康说明清单708是从健康模型701使用属性和其它工具来填充的。不是在模型701中而是在资源文件中调出事件。一种工具扫描资源文件和属性的源代码，并且填充健康说明清单708。故障状态可以通过监视预定的事件序列或监控性能计数器阈限来检测。可以将关于如何解决这类故障状态的指令提供给系统。健康模型被转换成规则。健康说明清单708包括规则类型事件序列，带有参数如事件1、事件2、时间3等。

配置模型702描述包括什么设置并且被转换成设置和声明说明清单709，它为系统提供指令大纲用于在安装组件时创建设置。

行政管理任务模型703通过小命令和管理角色说明清单710被转换成动作。例如，如果要求数据备份，则小命令是实际代码或者URI，用来便于备份任务。在需要执行众多管理任务的情况下，说明清单710提供URI路径给那些命令并且可能给代码。可以通过在代码上的声明来处理小命令或者小命令可要求外部代码。管理角色是另一个抽象支持，例如，多个管理这个应用或服务的用户类，以及它们可以各自行使的控制等级。这关联于基于角色的访问。要求元数据来描述各种用户的角色及其被允许的能力。角色与系统的所有方面相关-允许谁安装、谁可以改变监控、谁可以查看健康、谁可以解除警报、谁可以采取这些不同动作等等。

任务模型703定义开发者认为管理员应当做的内容，如在说明清单710中表达的，并且由操作团队为它们的环境而定制的。这些定制可以在类层次和实例层次上完成。可以在说明清单中在类层次上、在实例层次上作出改变，并且可以在运行时直接作出改变。所揭示的基于模型的管理体系结构的一个非常强大的特征是，可以首先在类层次上描述能力，而在运行时，对实例空间进行访问。

体系结构模型704将分布式组件说明清单711和部署说明清单712披露出来。例如，机器的网络连接、硬件要求在这里被覆盖。部署说明清单712至少支持构成web服务器、中间层服务器和数据库服务器的应用，并且包括前端/后端应用，两个应用之间的网络连通性，以及描述各个节点之间的关系。部署时间创建在整个体系结构模型704中描述的那些的实例。

性能和安全模型(705和706)各自支持相应的描述那些有关的函数和操作的说明清单(未示出)。

返回到使用基于机器的学习，分类器可以用于选择并且动态地根据在例如初次部署期间的要求来产生模型代码的选择部分的说明清单。默认模型可以自动地使用较多或较少属性来产生。随着时间过去，当系统运行信息变得可用时，可以分析这个信息，使得说明清单的粒度的等级可以，例如，根据最近的数据趋势和日志调整到更接近地监控在特定区域中的系统。然后在需要时重新产生和使用更新的说明清单以更接近地监控应用或服务。

如果说明清单描述来自制造商的默认安装或推荐的最佳实施，则管理员可能想要有所改变。例如，关于健康规则，管理员可能想要将阈限从三十改变到四十，或者安装组件，或者超越安全策略。这可以通过创建说明清单的定制版本以超越由制造商捆绑的说明清单来完成。在安装期间可以检测不同版本，允许用户有机会选择默认说明清单或定制说明清单。可替换地，可以有一个独立的列出超越的文件由系统阅读，随后显示它供用户选择以应用于默认说明清单或者在安装期间应用，使得默认设置被超越。

关于分布式应用，管理员可以更一般地规定他或她想要这些的三个、那个的四个和那些的六个在这个配置中全部连线。管理员可定义部署说明清单712从而用于给定的环境。

现在参考图7C，这里例示了依照基于模型的管理体系结构的管理应用或服务714所利用的系统组件510的核心系统API的方框图。系统组件510包括要受管理的应用或服务714。系统510在协作通信中包括多个API便基于模型的管理。系统510由多个服务组成，它们由应用说明清单内信息配置(参考图7B描述)。

系统510由确保应用的可用性所需要的服务和使用在说明清单组件508中表达的并由管理员修改的所想要的状态组成，以执行下列内容：安装，用于验证依赖关系并且只安装必需的文件、设置和安全性；事件预订，用于预订事件并且按指定转发；受轮询的装置，用于周期性地收集装置和计数器；以及，综合事务或模拟用户事务。对于监控系统，确定应用是否可用并且按所期望的(所想要的状态)执行的一种最佳方法是仿佛应用是一个用户那样使用应用。这是主动的监控。潜在的第二种方法是对真实用户事务的主动监控，并且向系统报告总计的数据用于分析。这些步骤结束循环并且显示内部应用数据是不足的。基于模型的管理也在应用之外工作。

系统510使用在说明清单组件508中表达的所想要的状态，还为自动任务管理执行任务调度；基于角色的访问，用于限制对程序函数的访问；监控，用于检测问题、诊断根原因、采取纠正动作并且通知系统管理员何时需要干预；以及，中心配置，用于为上述内容定制策略并且应用于许多机器。

提供与应用714联系的安装API 716，以便应用的安装、应用更新和修补。安装API 716通过指示系统在这个机器上安装这个组件、这个说明清单和这个版本，来取由代码表示的说明清单组装部件并且实例化组装部件。安装API 716将它与协议718和观察器720相关联。协议718便于与系统510的其它组件传送与API有关的数据。观察器720显示与安装API 716有关的数据。安装API 716不仅便于在单一机器上的安装，而且还用于涉及本地和远程系统两者的分布式应用或服务，也用于硬件设置(provisioning)和抽象。对于分布式数据中心环境，重要的是，能够一般以较细的粒度将硬件系统抽象为一个特定的机器抽象。协议，如在此相对于一个API所考虑的，是控制与该API有关的数据的发送与接受的规则。观察器720，如在本说明书中所理解的，是显示与API有关的数据的程序，这里是安装API 716。API数据包括但不限于例如声音文件、视频文件和其它类型的文件。

系统510包括与应用714联系的配置API 722，以便于配置应用714。配置API 722将它与大纲723、协议724和观察器726相关联。大纲723定义在API 722与应用714之间传递的数据结构和内容。协议724便于与系统510的其它组件传送与API有关的数据。观察器726显示与配置API 722有关的数据。

还包括管理API 728，它便于分布式环境的多对一管理。API 728与受管理的应用714通信，也与远程系统(未示出)通信。API 728具有相关联的协议730和观察器732。

系统510包括与应用714联系的性能计数器API 734，它便于跟踪在管理应用714时使用的计数器变量。计数器API 734将它与协议736和观察器738相关联。协议736便于与系统510的其它组件传送与API有关的数据。观察器738显示与计数器API 734有关的数据。由应用714公开性能计数器并且通过观察器738发布计数器。

提供与应用714联系的装置API 740，它便于配置装置和与应用714传递装置数据。装置API 740将它与协议742和观察器744相关联，并通过观察器744公开装置。协议742便于与系统510的其它组件传送与API有关的数据。观察器744显示与装置API 740有关的数据。装置API 740通过IPC(进程间通信)746与受管理的应用714通信。IPC是一个程序与另一个程序之间数据的自动交换，不是在同一计算机内就是通过网络。在用户使用剪贴板手工将数据从一个文件剪切和粘贴到另一个文件时执行IPC函数的一个例子。计数器总是通过共享的存储器发布，而装置是按需交付的。装置API 740还包括大纲748，它用与事件大纲相似的方式描述装置类的外表。还可包括装置日志(未示出)；然而，许多管理员更喜欢使用事件日志。

系统510包括目录747，它是保持跟踪并高速缓存组件和模式信息的存储器。这个模式信息来自在安装时的说明清单，以及部分是动态的且在运行时更新。目录747包括目录API并且提供对事件、计数器、装置和配置数据的访问，这里仅列出存储在其中的几种数据类型。协议751和观察器753便于对目录747的访问。中心配置数据库包含积累起来的或者总计的、与多个受管理的节点相关的目录视图。

系统510包括与应用或服务714联系的事件API 750，它便于实现和跟踪在管理应用714时使用的事件。事件API 750与事件日志752接口，后者用作所有发生的事件的存储器。事件API 750将它与协议754和观察器756相关联。协议754便于与系统510的其它组件传送与API有关的数据。观察器756显示与事件API 750有关的数据。与应用714的通信依照事件大纲758，它定义在它们之间传递的数据结构和内容。在描述或发生事件时发布事件。大纲描述事件的表面。

系统510包括与应用714联系的自动化API 760，它便于自动化通常可与应用714交互而完成的过程。自动化API 760将它与协议762与命令解释程序764相关联。协议762便于与系统510的其它组件传送与API有关的数据。命令解释程序764提供与自动化API 760的用户接口，它便于与其的用户交互，用于输入和显示与自动化进程有关的数据和自动化进程的用户控制。

系统510还包括与应用714和自动化API 760两者联系的受调度的任务API766。受调度的任务API 766便于至少为自动化API 760和受管理的应用714调度工作或程序。它保存一个要运行的工作列表并且相应地分配资源。调度的任务API 766将它与协议768和观察器770相关联。协议768便于与系统510的其它组件传送与API有关的数据。观察器770显示与调度的任务API 766有关的数据。任务大纲772定义在任务API与其它组件之间传递的数据结构和内容。

自动化和任务是从任务和小命令模型接收的。这些特征可以通过管理命令解释程序或者在本地或者远程地来自动化。调度系统可以运行这些，例如，在3AM的备份。

要意识到，在图7C中描述的组件可以代表本地实现的组件，而在图7D中组件可以代表与分布式实现相关的组件，使得分析在许多机器和软件系统上进行。因而，在分布式实现中，图7D的组件与图7C的至少一个本地系统通信，但一般是多个这样的本地实现以有线和/或无线方式通信。在本地实现中，系统510还可以包括图7D的任何或全部组件，包括本地监控服务API 765。本地监控服务API 765还包括协议767，观察器769和大纲771，它们分别便于与其它API的这类组件相似的功能。在分布式实现中，本地监控服务765随后将监控信息传递给分布式监控服务，它在下文描述。

现在参考图7D，这里例示了基于模型的管理体系结构的系统组件510的与管理有关的API的方框图。提供配置数据库子组件774，对它的访问和控制是通过中心配置API 776提供的。中心配置API 776与系统510的所有子组件接口，并且将它与用于通信和交互的协议778和观察器780相关联，以及与描述配置设置和属性诸如声明和默认值的形式的大纲组件782相关联。协议778便于与系统510的其它组件传送与API有关的数据。

还提供操作数据库子组件783，它用作用于与操作有关的管理系统数据(例如，报告、当前状态和历史数据)的储存库。监控API 784与操作数据库783和基于模型的管理系统的所有子组件接口，并且还将它与协议785、观察器786和大纲787相关联。协议785便于与系统510的其它组件传送与API有关的数据。观察器786显示与监控API 784有关的数据。大纲787提供整个操作数据库783的定义，至少关于在结构内每个数据元素可以包括的内容的结构和类型。

中心配置可以触及所有API，并且由管理员用于设置配置细节，可以包括用于分布式应用情况的细节，诸如在什么机器上应当安装应用。配置还包括监控配置。例如，所有机器必须历时五分钟显示不少于80％的CPU使用率。因而，监控系统使用配置系统。监控是管理员如何通过管理系统确保应用按照模型运行、配置和安装。它还包括确保预期的功能、所想要的安全量、正确地执行以及按用户的期望交付数据。因而，监控涉及这些领域的所有方面。一般的过程是安装、设定、按需运行任务、消耗事件、提供装置、配置并且存储数据和结果。健康说明清单以规则的形式提供工作指令给监控系统，规则是给监控系统的指令。一般而言，说明清单包含运行库指令，且运行库实现所想要的状态。

监控服务既是本地服务，也可以是中心或分布式机制。对于分布式实现，健康包括本地机器的实现以及在本地和远程机器之间的关系。例如，给定十个机器的群集，只要六个运行正常，则认为系统是健康的。然而，如果不超过五个机器在运行，则系统健康状态降级为警戒状态。如果不超过四个机器在运行，则认为系统健康为故障状态。硬件抽象便于当一个或多个群集机器故障或变成离线时使一个或多个备份系统或应用/服务在线。因而，空闲或共享资源池可以根据指令来控制。这个特征在数据中心环境中特别有用。可以实现自动化的动作来确保系统保持优化或者至少最低的功能。

基于模型的管理体系结构的一个方面允许开发者编写大量规则，表达对一个系统被认为是健康的所必须满足的准则。监控API 784包括一个规则运行时引擎，它便于对规则的隐含的并发处理。规则引擎接收将规则表达为中间形式的输入指令，其中规则是使用规则定义语言(RDL)表达的。规则引擎还从配置数据库774接收用于实例化规则代码的配置数据。翻译器读取输入指令并且将它们转换成并行执行形式。运行时引擎读取经翻译的指令并且便于并行执行。规则代码是通过将配置数据载入到运行时引擎来实例化规则代码的，它指定要运行哪些规则，以及运行规则所需要的参数。规则参数可以在运行时改变，诸如只有在已经检测到问题时才允许具有严重系统影响的规则。因而，规则是动态的，阈限也是如此，可相应地改变它们。监控API 784还连接系统510的所有子组件。

还提供说明清单存储和编辑服务788，供管理员使用。说明清单服务788将它与协议789和观察器790相关联，以将这些说明清单函数向管理员公开。说明清单服务788将说明清单通过协议789和观察器790供给管理员，允许管理员在安装之前观看和改变说明清单。说明清单服务788还便于依照更新和定制对说明清单的版本化。

还提供基于角色的访问API 791，它与基于模型的管理体系结构的所有子组件接口，并且还将它与协议792和观察器793相关联。协议792便于与系统510的其它组件传送与API有关的数据。观察器793显示与基于角色的API 791有关的数据。这个API 791例示在监控和配置组件之上的层次处，以提供对基于模型的管理系统的各种组件和方面的访问的全部管理。基于角色的访问API791包括协议792和观察器793是不必要的，因为可以由系统510的其它组件来便于这些功能。

系统还包括分类器794，用于基于机器的学习和控制。如在上文指出的，可以用许多方法来使用分类器794以增强系统性能和健康，这只是一些例子。为便于基于机器的学习，分类器794与中心配置服务776接口，使得系统的所有组件可被访问并且使用它的数据。

现在参考图7E，这里例示了基于模型的管理体系结构的任务组件512的主要子组件。通过管理任务模型描述任务。任务落入三个子组件：监控子组件795，故障寻找子组件796，和管理子组件797。

监控子组件795的任务包括监视健康、安全、修补、配置、性能和应用数据。故障寻找子组件796的任务包括诊断健康状态，处理报警，以及更新事件、装置和性能日志。管理子组件797的任务包括中心配置/策略，调度和更新部署。管理不仅包括单个系统的管理，而且还包括管理例如许多机器、应用和系统、策略、备份时间、修改和更新。

在基于模型的管理体系结构中使用URI以唯一地识别抽象或物理的资源或者资源集合。用于资源的大纲可以由带有用于资源的占位符的URI来识别。带有占位符的URI称为URI模板。系统的目录依靠URI模板来描述装置而不参考特定的实例。URI模板允许识别探测器并且理解它们的特征而不实际地检索用于特定实例的探测器。保护与实例分离地预定义装置的能力使规则的部署和编写更容易并且使相关的操作系统更可管理。

基于模型的管理框架使用RDL来允许为了监控软硬件的可用性定义规则。用RDL编写的规则由运行时引擎作为部分监控服务来执行。RDL的目的是测试声明，使用运行时信息实施约束，作出推论，执行相关(correlation)，并且将动态测试的结果发送给其它组件。RDL定义规则类型(即类)，同时使用单独的XML(可扩展标记语言)文档，通过指定规则类型实例化所需的参数值来创建规则类型的实例。有一个大纲用于描述系统为问题检测、诊断、解决、验证和报警所应当采取的步骤序列。这就是在模型中所描述的，在说明清单中所表达的，以及由监控系统所执行/管理的。

基于模型的管理框架使用事件和性能计数器的更新值来表示服务的健康模型(或状态)，以及测试或综合事务，如前面所指出的。健康模型701是服务或组件如何会故障的图形和/或文本表示，它帮助管理员理解服务的各种事件和性能计数器的意义，并且有效地决定是否根据观察到装置数据采取任何动作。开发者建立健康模型701，随后从模型和源代码属性产生相应的文件。

健康模型701包括组件关系还有信赖关系的描述。取决于所检测到问题的环境，系统可以遍历关系树并且试图根据其它组件的健康来确定根原因。这种方法由模型和说明清单支持。

现在参考图8，例示了基于模型的管理的过程的流程图。在800，要安装的应用或服务的组件按照其组件进行描述。在802，按照功能、配置、安全和性能来描述应用或服务所想要的状态。在804，在安装期间连同应用或服务提供描述，使得系统使用描述来配置系统的管理服务。然后过程到达停止块。

现在参考图9，例示了实现基于模型的管理的过程的更详细的流程图。在900，为应用组件、健康状态和恢复、配置设置和管理任务开发模型。在902，用户依照环境定制系统/规则/模型。在904，将属性插入源代码中以表示用于监控的装置和逻辑。在906，为由管理系统服务使用，提供模型信息和源代码属性的说明清单。为由管理系统服务使用，以机器可读形式提供说明清单。在908，根据说明清单信息配置一个或多个管理系统服务。在910，在说明清单内为应用定义行政管理任务，诸如向系统注册小命令、设置调度等。过程然后到达停止块。

现在参考图10，例示了实现所想要的基于模型的管理的状态的过程的流程图。在1000，从说明清单访问所想要的状态。在1002，验证依赖关系并且只安装必需的文件、设置和安全特征。在1004，预订和转发事件，如在说明清单中指定的。在1006，周期性地收集装置数据和计数器数据，以及执行测试和综合事务。在1008，执行自动管理任务。在1010，限制对程序函数的访问。然而，这对便于基于模型的管理不是所必须的。在1012，检测问题，诊断根问题，采取纠正动作，并且在要干预时通知系统管理员。在1014，对于许多其它类型的机器和系统，为应用定制上述所有内容的策略。过程随后到达停止块。

现在参考图11，例示了可用于执行所揭示的体系结构的计算机的方框图。为了为本发明的各种方面提供附加的背景，图11和下面的讨论旨在提供适合于在其中实现本发明各种方面的计算机环境1100的简要概括的描述。尽管已经在可在一个或多个计算机上运行的计算机可执行指令的一般背景中描述了本发明，但那些本领域熟练技术人员将认识到，也可结合其它程序模块和/或作为软硬件的结合来实现本发明。通常，程序模块包括例程、程序、组件、数据结构等，它们执行特定任务或者实现特定的抽象数据类型。而且，那些本领域熟练技术人员将意识到，本发明的方法可用其它计算机系统配置来实施，包括单处理器或多处理器计算机系统、小型机、大型机以及个人计算机、手持式计算设备、基于微处理器的或可编程消费电子产品等等，它们都能有效地与一个或多个相关设备耦合。本发明的例示方面也可在分布式计算环境中实施，其中某些任务由通过通信网络连接的远程处理设备来执行。在分布式计算环境中，程序模块既可位于本地的也可位于远程的存储器存储设备中。

再次参考图11，例示了实现本发明各种方面的示例性环境1100，它包括一个计算机1102，计算机1102包括处理单元1104，系统存储器1106和系统总线1108。。系统总线1108将包括但不限于系统存储器1106在内的系统组件耦合到处理单元1104。处理单元1104可以是任何各种在商业上可获得的处理器。双微处理器和其它多处理器体系结构也可用作处理单元1104。

系统总线1108可以是若干类型总线结构之一，可进一步互连到存储器总线(带有或不带有存储控制器)、外设总线和使用任何多种多样在商业上可获得的总线结构的局部总线。系统存储器1106包括只读存储器(ROM)1110和随机存取存储器(RAM)1112。基本输入/输出系统(BIOS)存储在非易失存储器1110诸如ROM、EPROM、EEPROM中，其中BIOS包含基本例程，它们帮助在计算机1102内的元件之间传送信息，如在启动时。RAM 1112也可以包括高速RAM，诸如用于高速缓存数据的静态RAM。

计算机1102还包括硬盘驱动器1114，磁盘驱动器116(例如读写可移动盘1118)，和光盘驱动器1120(例如，读CD-ROM盘1122或者读写其它高容量光介质诸如数字视频盘(DVD))。硬盘驱动器1114，磁盘驱动器1116和光盘驱动器1120可以分别通过硬盘驱动器接口1124、磁盘驱动器接口1126和光盘驱动器接口1128连接到系统总线1108。驱动器及其相关的计算机可读介质提供数据、数据结构、计算机可执行指令等的非易失性存储。对于计算机1102，驱动器和介质以适当的数据格式容纳广播编程的存储。尽管上面计算机可读介质的描述指硬盘、可移动磁盘和CD，但那些本领域熟练技术人员应当意识到，由计算机可读的其它类型的介质，诸如zip驱动器、磁盒、闪存卡、数字视频盘、盒式磁盘等，也可在示例性操作环境中使用，并且此外任何这类介质可包含用于执行本发明的方法的计算机可执行指令。

在驱动器和RAM 1112中可存储多个程序模块，包括操作系统1130，一个或多个应用程序1132，其它程序模块1134和程序数据1136。操作系统、应用、模块和/或数据的全部或部分也可高速缓存在RAM 1112中。

要意识到，本发明可以用各种在商业上可获得的操作系统或操作系统的组合来实现。

用户可以通过键盘1138和定点设备如鼠标1140将命令和信息输入计算机1102。其它输入设备(未示出)可包括话筒、IR遥控、操纵杆、游戏垫、卫星天线、扫描仪等等。这些和其它输入设备常常通过耦合到系统总线1108的串行端口接口1142连接到处理单元1104，但可用其它接口诸如并行端口、游戏端口、通用串行总线(“USB”)、IR接口等来连接。监视器1144或其它类型的显示设备也通过接口诸如视频适配器1146连接到系统总线1108。除监视器1144之外，计算机一般包括其它外围输出设备(未示出)，诸如扬声器、打印机等。

计算机1102可在使用通过有线和/或无线通信到一个或多个远程计算机如远程计算机148的逻辑连接的网络化环境中运行。远程计算机1148可以是工作站、服务器计算机、路由器、个人计算机、便携式计算机、基于微处理的娱乐器具、对等设备或其它公用网络节点，以及一般包括相对于计算机1102所述的许多或全部元件，尽管为了简单，只例示了一个存储器存储设备。所示的逻辑连接包括局域网(LAN)1152和广域网(WAN)1154。这样的网络环境在办公室、企业级计算机网络、企业内部互联网和因特网中很常见。

当在LAN网络环境中使用时，计算机1102通过有线或无线通信网络接口或适配器1156连接到局域网1152。适配器1156可便于与LAN 1132的有线或无线通信，后者还可包括布置在其上的无线接入点，用于与无线适配器1156通信。当在WAN网络环境中使用时，计算机1102一般包括调制解调器1158，或者连接到LAN上的通信服务器，或者具有在WAN 1154如因特网上建立通信的其它装置。调制解调器1158，可以是内置或外置以及有线或无线的设备，通过串行端口接口1142连接到系统总线1108。在网络化环境中，相对于计算机1102所述的程序模块或者其部分，可存储在远程存储器存储设备1150。将意识到，所示的网络连接是示例性的，并且可使用在计算机之间建立通信链路其它方法。

计算机1102用于与任何以无线通信方式有效布置的无线设备或者实体通信，例如，打印机、扫描仪、台式和/或便携式计算机、便携式数据助理、与可无线检测的标签相关联的任何装置或位置的(例如，公用电话间、报栏、公共厕所)和电话。这至少包括Wi-Fi和Bluetooth^TM(蓝牙)无线技术。因而，通信可以是如同常规网络的预定义结构，或者只是至少两个设备之间的ad hoc(特定)通信。

Wi-Fi或无线保真，允许从家中的睡椅、旅馆房间里的床或单位里的会议室无线地连接到因特网。Wi-Fi是与蜂窝电话相似的无线技术，它使这样的设备例如计算机能够在室内外发送和接收数据；在基站内的任何地方。Wi-Fi网络使用称为IEEE 802.11(a，b，g等)无线电技术来提供安全、可靠、快速无线连通性。Wi-Fi网络可以用于将计算机彼此连接，连接到因特网，以及连接到无线网络(它使用IEEE 802.3或以太网)。Wi-Fi网络在无许可证的2.4和5GHz无线电频带中运行，具有11Mbps(802.11b)或54Mbps(802.11a)数据速率或者具有包含两个频带(双频带)的产品，因此网络可以提供与在许多办公室中使用的基本10BaseT有线以太网相似的真实世界性能。

现在参考图12，这里例示了依照本发明的示例性计算环境1200的示意性方框图。系统1200包括一个或多个客户机1202。客户机1202可以是硬件和/或软件(例如，线程、进程、计算设备)。例如，客户机1202可以容纳通过使用本发明的cookie和/或相关的上下文信息。系统1200还包括一个或多个服务器1204。服务器1204也可以是硬件和/或软件(例如，线程、进程、计算设备)。例如，服务器1204可以容纳通过使用本发明执行变换的线程。在客户机1202与服务器1204之间的一种可能的通信可以是以适合于在两个或多个计算机进程之间传输的数据包的形式。例如，数据包可包括cookie和/或相关的上下文信息。系统1200包括通信框架1206(例如，全球通信网络如因特网)，可以用它来便于客户机1202和服务器1204之间的通信。

可通过有线(包括光纤)和/或无线技术来便于通信。客户机1202可操控地连接至一个或多个客户机数据存储器1208，可以使用它(们)来存储客户机1202本地的信息(例如，cookie和/或相关的上下文信息)。同样，服务器1204可操控地连接到一个或多个服务器数据存储器1210，可以使用它(们)来存储服务器1204本地的信息。

上面已经描述的内容包括本发明的例子。当然，不可能为了描述本发明而描述每一种可能的组件或方法组合，但本领域普通技术人员可认识到，本发明的许多其它组合和变更是可能的。因此，本发明旨在包括所有这样的变更、修改和变体，它们落在所附的权利要求书的精神和范围内。而且，对于在详细描述或在权利要求书中都使用术语“包括”的情况，该术语是要以与术语“包含”在被使用时被解释为权利要求中的一个过渡词语相似的方式来表示包括在内。

Claims

1.一种便于处理规则的系统，包括翻译器组件，它使用同步编程模型将同步语句翻译成异步指令。

2.如权利要求1所述的系统，其特征在于，将所述语句组织成一系列规则类型。

3.如权利要求2所述的系统，其特征在于，所述规则类型表示确定所想要的目标资源的状态的逻辑。

4.如权利要求3所述的系统，其特征在于，响应于所想要的状态，采取行动。

5.如权利要求1所述的系统，其特征在于，所述翻译器组件便于所述异步指令的实例化。

6.如权利要求1所述的系统，其特征在于，所述指令便于由运行时引擎进行的并发处理。

7.如权利要求6所述的系统，其特征在于，所述指令便于由所述运行时引擎保存所有状态，其中状态包括自变量与局部变量的至少之一。

8.如权利要求1所述的系统，其特征在于，所述指令便于让步于运行时规则代码执行切换与调用实用功能的至少之一。

9.如权利要求1所述的系统，其特征在于，所述指令插入周期性让步语句。

10.如权利要求1所述的系统，其特征在于，所述翻译器组件便于深度优先遍历以产生相应节点的标签与临时变量至少之一。

11.如权利要求1所述的系统，其特征在于，所述翻译器组件将所述规则的模块翻译成类。

12.如权利要求1所述的系统，其特征在于，所述指令包括一种地址代码表示，以便于由运行时引擎进行的上下文切换。

13.如权利要求12所述的系统，其特征在于，所述地址代码表示使用至少三个地址代码，在语句或表达式包括异步调用时使用所述表示。

14.如权利要求1所述的系统，其特征在于，所述指令被翻译成一系列指令块，它们被分成switch-case块。

15.如权利要求14所述的系统，其特征在于，在所述指令块内的指令作为一个单元执行，并且仅让步于这类指令块之间的运行时执行。

16.如权利要求14所述的系统，其特征在于，所述系列指令块已将其与一更新标识符相关联，更新标识符保存要在下次重新进入所述规则后要执行的所述系列的那一个指令块。

17.一种便于并发处理规则的系统，其特征在于，包括：

翻译器组件，将所述规则翻译成用于并发处理的指令；以及

运行时引擎，为处理而调度所述指令并且依照所述调度并发处理所述指令的部分或全部。

18.如权利要求17所述的系统，其特征在于，所述运行时引擎便于对所述规则的隐含的并发处理。

19.如权利要求17所述的系统，其特征在于，所述运行时引擎接收所述指令和配置数据两者，其中配置数据指定哪些规则的至少之一要运行和运行所述规则所需要的参数。

20.一种便于在基于模型的管理体系结构中处理规则的系统，其特征在于，包括：

表达所述体系结构的健康准则的多个规则；

翻译器组件，将所述规则翻译成用于并发处理的异步指令；以及

运行时引擎，为处理而调度所述经翻译的指令并且依照所述调度并发处理所述指令的部分或全部。

21.如权利要求20所述的系统，其特征在于，所述运行时引擎依照所述指令之一操作，所述指令暂停对代码的处理并且等待一个事件发生，响应于所述事件，恢复对代码的处理并且允许对所述事件行动。

22.如权利要求20所述的系统，其特征在于，所述多个规则之一启用另一个规则。

23.如权利要求20所述的系统，其特征在于，所述引擎根据当前框架的轮询结构以及所述轮询结构是否处在执行堆栈的最上面来调度所述执行堆栈的执行。

24.如权利要求20所述的系统，其特征在于，所述指令组件包括便于循环的语言，使得在跳转之前，规则返回到所述运行时引擎以便于无抢先式调度。

25.如权利要求20所述的系统，其特征在于，所述经翻译的指令便于协同的多任务，因此保存函数的执行状态，并且在以后的时间组成它。

26.如权利要求20所述的系统，其特征在于，所述指令便于构造调用框架，其中调用框架包括函数参数、当前指令块、当前函数和局部变量中的至少一个。

27.如权利要求20所述的系统，其特征在于，所述运行时引擎包括一种散开算法，它在从一任意时间开始的一段时间内散开任务的执行来减少过使用率。

28.依照权利要求20的计算机系统。

29.一种处理规则的方法，其特征在于，包括：

接收多个规则；

将所述规则翻译成传送给运行时引擎的指令；

为由所述运行时引擎处理而调度所述经翻译的指令；

由所述运行时引擎并发处理所述多个指令中的至少两个；以及

接收配置数据到所述运行时引擎中以实例化所述规则。

30.如权利要求29所述的方法，其特征在于，还包括将让步指令插进所述规则以便于在由所述运行时引擎处理期间让步于规则对规则代码执行切换的执行，并且便于对由所述运行时引擎提供的实用功能的调用。

31.如权利要求29所述的方法，其特征在于，所述经翻译的指令被翻译成一系列指令块，其中所述指令块的执行的开始使所述指令块在让步于所述运行时引擎之前被全部执行。

32.如权利要求29所述的方法，其特征在于，还包括在启动过程中，建立标记为由所述运行时引擎在启动时执行的规则的任务列表，并且将所述规则的初始化散开在若干批中，使得为在时间配置的时间间隔内处理而调度每批规则。

33.如权利要求32所述的方法，其特征在于，还包括根据预定的准则配置所述时间间隔，其中准则包括由计算机使用的处理器的数量。

34.如权利要求29所述的方法，其特征在于，为由所述运行时引擎按批处理而调度所述指令，使得为均匀地在与处理一个批的相关时间间隔上处理而调度所述批的规则。

35.如权利要求29所述的方法，其特征在于，还包括根据轮询结构为处理而调度所述经翻译的指令，其中对当前框架的轮询结构和在堆栈最上面的轮询结构的至少之一进行处理。

36.如权利要求29所述的方法，其特征在于，依照无抢先式调度方式执行调度。

37.一种用于处理规则的系统，其特征在于，包括：

用于接收多个规则的装置；

用于将所述规则转换成指令的装置；

用于为由运行时引擎处理而翻译所述指令的装置；以及

用于调度和并发处理所述多个指令的至少两个的装置。

38.如权利要求37所述的系统，其特征在于，所述用于转换的装置包括用于将控制放弃代码插入规则的装置，所述规则确定在其执行期间在什么地方放弃对相关的经翻译的指令的控制，其中放弃代码与一个堆栈框架相关联，堆栈框架包含参数、局部变量和在重新进入要跳转到所述经翻译指令的什么地方中的至少一个。

39.如权利要求37所述的系统，其特征在于，还包括用于在规则之间任务切换的装置，其中所述经翻译的指令包括调用框架以便于任务切换。

40.一种具有用于执行对规则的并发处理的计算机可执行指令的计算机可读介质，其特征在于，包括翻译器组件，使用同步编程模型将同步规则语句翻译成异步指令，其中指令便于调用实用功能并且让步于运行时代码切换。