具有用于缓解和自动防护的责任约束服务等级协议及模式的服务性能管理器

摘要

所公开的服务性能管理器是企业软件平台，所述企业软件平台监控并前瞻性地管理基于服务等级协议的个体服务和分组服务的健康和性能，所述服务性能管理器在个体服务和分组服务上提供更好的可视性和控制，包括但不限于IT服务和业务服务。服务性能管理器在消费者意识到之前预测并解决潜在的与消费者相关的问题，使机构能够满足服务质量目标。与其他软件平台不同的是，所公开的服务性能管理器利用更佳的粒度和精度自动地优化资源、服务以及服务等级协议，同时不变地保持厂商中立，允许服务性能管理器基本上同时管理许多不同的应用程序和面向服务的体系结构平台。所公开的服务性能管理器允许用户监控并管理个体服务或分组服务的性能，并且从技术和业务的角度在服务监控中提供可视性。

说明书

对相关申请的交叉引用：本发明申请涉及并要求2008年4月29日提交的题目为“具有用于缓解和自动防护的责任约束服务等级协议(SLA)及模式的服务性能管理器(Service Performance Manager with Obligation-Bound Service Level Agreements(SLA)and Patterns for Mitigation and Autoprotection)”的临时专利申请No.61/048,932的优先权，本文通过引用将其并入本申请，以用于任何用途。

背景

技术领域

所公开的实施方案一般地涉及面向服务的体系结构(Service-Oriented Architecture)系统管理，并且更具体地，涉及具有有条件的服务等级协议和问题缓解(issue mitigation)以及自动防护(autoprotection)特征的服务性能管理器软件平台。

背景技术

面向服务的体系结构(SOA)正迅速被各行各业及各种规模的许多不同机构所采纳并部署(deploy)。在直接聚焦和关注实施SOAs的同时，各机构总地来讲几乎未曾注意过监控和管理其SOAs，以确保服务等级得到保持并且效率得到提高。

发明内容

所公开的服务性能管理器(SPM)是企业软件平台，所述企业软件平台监控并前瞻性地(proactively)管理基于服务等级协议(SLAs)的个体服务和分组服务的健康和性能。在意外高峰(spikes)期间，SPM提供运行的服务的增强可视性，允许额外服务实例的自动部署以满足负载高峰，并且帮助确保不违反(violate)SLAs。SPM还允许用来监控服务性能、服务可用性(availability)以及服务使用的规则。SPM为IT经理和营运经理提供针对其IT服务和业务服务的更好的可视性和控制。SPM在消费者意识到之前预测并解决潜在的与消费者相关的问题，使机构能够满足服务质量目标。与其他软件平台不同的是，所公开的SPM利用更佳的粒度(granularity)和精度自动地优化资源、服务以及SLAs，同时不变地保持厂商中立，允许SPM基本上同时地管理许多不同的应用程序和面向服务的体系结构(SOA)平台。所公开的SPM允许用户监控并管理个体服务或分组服务的性能，并且从技术和业务的角度在服务监控中提供可视性。

附图说明

在附图中以实施例的方式图示说明了实施方案，在附图中相似的参考标号表示类似的部件，并且其中：

图1根据本公开提供描绘可以由所公开的SPM监控的项目的示例性选择的图示说明；

图2根据本公开图示说明示例性贷款核准过程流程图；

图3根据本公开图示说明所公开的SPM的基本项目的工作流的示意图；

图4根据本公开图示说明用于所公开的SPM的用户工作流的示意图；

图5根据本公开图示说明用于所公开的SPM的用户工作流的示意图；

图6根据本公开图示说明用于所公开的SPM的用户工作流的示意图；

图7根据本公开提供图示说明SPM产品体系结构的示意图；

图8根据本公开图示说明详述简单规则和复杂规则的流程图；

图9根据本公开图示说明显示用于设置规则的步骤的流程图；

图10根据本公开提供规则包(rule package)的概要图示说明，该规则包以具有四条规则的目标(objective)为特征；

图11根据本公开提供描绘规则包内规则集合的结构的示意图；

图12根据本公开提供被引用的目标对象类型的列表；

图13根据本公开图示说明用于SOA自动防护的服务消费者责任与应用程序的流程图；以及

图14为根据本公开的框图，图示说明用于实施SPM的一个实施方案的计算机系统。

具体实施方式

服务性能管理器

服务性能管理是监控和测量个体服务或分组服务的可观察行为(behavior)并且基于限定的一套规则对其行为实施(反应性地或前瞻性地)变化的能力。可观察行为可以包括系统性能、可用性、使用、错误和有效负荷。

所公开的服务性能管理系统是软件平台，所述软件平台保持并自动地管理个体服务或分组服务的可观察行为的健康和性能，同时附加地管理业务有效负荷。在实施方案中，SPM保持并管理IT服务的可观察行为的健康和性能。在另一实施方案中，SPM保持并管理业务服务(business service)的可观察行为的健康和性能。SPM可以用来设计、计划并监控基于业务需要的服务。SPM还可以用来相对于成本平衡服务等级。此外，SPM可以用来实现并加强服务的可测量等级以及减小无法预测的需求的可能性。SPM可以显著地改善服务提供者和消费者之间的关系。所公开的SPM的实施方案包括以责任约束的服务等级协议(SLAs)为特征的性质，以及用于识别部件不当行为(misbehavior)的模式。

SPM可以使用策略管理技术来分布监听者(listener)和相关联的策略，并且还可以搜集性能信息。利用复杂事件处理、规则、策略以及Java管理扩展(JMX)控制界面的组合，SPM允许用户针对服务等级例外(exceptions)或反常(anomalies)创建基本上任何的反应情景(reaction scenario)。

SPM允许用户通过使用分布的监控和测试设备架构(instrumentation framework)来监控部署的服务工件(service artifacts)。在实施方案中，独立于部署的基础结构(deployment infrastructure)，用户可以通过使用显控工具(dashboard)来监控部署的服务工件，以从服务透视图(perspective)追踪度量(track metrics)。

在实施方案中，SPM可以被加入到现有的SOA基础结构中。SPM可以被加入到各种技术和体系结构中。

SPM可以对包含结合监控使用SLAs的SOA构造(fabric)提供自治能力(autonomic capability)，在阈值违规(threshold violations)或迫近违规(impending violations)方面提供前瞻性和反应性警报，以及在使用和执行(performance)二者中尽可能提供保证(自愈和自优化二者)。

在实施方案中，SPM提供SLAs和规则的基于向导的创建。

SPM不仅提供用户到其运行的服务中的基本上立即的可视性，而且允许其建立额外服务实例的自动部署，以满足负载高峰。这可以确保在意外峰值期间服务等级协议不被违反，并且可以允许用户建立来监控服务度量的规则，服务度量包括但不限于，系统性能、可用性以及使用。如果发生事件或违规，可以通过在用户界面或显控工具上的警报或者通过电子邮件来处理。在实施方案中，业务流程管理(BPM)或客户关系管理(CRM)工作流可以被启动(initiated)。

SPM不仅帮助监控服务，还可以辅助管理这些服务。SPM允许用户监控业务流程中的关键性能指标(key performance indicator)、分析性能、检验行为模式以及以前瞻性和预见性的方式采取纠正动作，来成功地管理和经营业务。基于过往的性能，用户可以预测未来的性能、确认瓶颈并且为更好的性能而采取纠正动作。在特定情况下，如果特定条件被满足或者如果特定规则被违反，用户可以是前瞻性的并且建立规则以触发动作，从而对用户提供一定水平的保证。

规则库可以使用SPM来创建，其中可以在某些服务度量上限定简单规则或复杂规则。如果限定在规则中的条件被满足，这些规则可以内部地触发一种或更多种类型的动作。动作库可以储存示例性动作，例如发送警报、调用(invoking)脚本或服务，或者将事件记入日志(logging event)。一些规则可以以按照循环的(recurring)时间表来运行，例如在所有工作日中每天的下午两点运行或在高峰时间运行。标准时间表可以被限定在时间表库中，时间表库可以用来基于相应的规则在指定的时间触发动作。

在实施方案中，SPM通过集中式管理和自管理协议提供低成本管控(administration)，确保更好的顺从性(compliance)和SOA治理(governance)。在另一实施方案中，实现更有效的操作管理和质量控制。SPM可以允许更容易的SLAs测量和确定。在实施方案中，用于端对端企业基础结构监控和管理的SPM的附加提供预测并响应大量业务服务和事件的能力。

业务情景

在典型的业务情景中，存在服务提供者和服务消费者。不管用户的角色是作为服务提供者还是服务消费者，SPM可以被用来监控和管理业务服务。图1为描绘可以由所公开的SPM的实施方案监控的项目的示例性选择的示意图100。所公开的SPM可以监控请求、基础结构以及服务，包括但不限于，监控来自提供者或消费者的请求或在业务环境中的请求；监控基础结构节点或容器；以及监控原子(atomic)、编制(orchestration)或收集服务。在实施方案中，SPM结合监控请求、基础结构以及服务来使用探测策略和/或SLAs，以管理事件并提供警报。

图2提供流程图，来图示说明SPM是如何可以被用于示例性贷款核准过程200的实施方案。在示例性过程的第一步中，检索消费者的信息210。在下一步中，使用外部信用核查服务230来核查消费者的信用220。在实施方案中，信用核查服务为外部的并且可以具有99.9％的有保证的(guaranteed)可用性。基于该信用是可接受与否的确定240，额度被发放或贷款被拒绝。如果信用是可接受的，则额度被发放250，否则贷款被拒绝260。SPM用在这个实施例中来监控外部信用核查服务230和贷款公司之间的可用性、响应以及数据通信量。

在实施方案中，如果不满足外部服务(例如图2中所呈现的信用核查服务)的有保证的可用性，则服务消费者可以将该事件记入日志、向管理员发出警报、发起支持请求和/或发起开具处罚账单。

在实施方案中，服务提供者可以期望在SLA中指定的时间内确保针对所有请求的有保证的响应。例如，如果消费者发送太多的请求(这些请求在数量上异常巨大或者具有错误的有效负载)而使系统超载，服务提供者可以选择采取纠正动作来使系统负载受到控制。这样的纠正动作可以包括阻挡(blocking)进一步的请求，从而整个系统不会受损，或者向其他参与方发出警报。为修复错误或超载服务，系统管理员可以选择投入更多的网格资源(分配附加的计算资源)、重新分配现有资源或者选择要处理的请求。

项目(project)生命周期

图3为图示说明所公开的SPM的实施方案的基本项目工作流的示意图。被包括在监控和管理服务等级性能中的主要步骤为发现服务310、测量可观察度量320、分析和预测行为330、监控服务340以及发送警报350。

在发现服务的步骤310中，SPM可以核查运行在单一环境或多种环境下的所有服务。这些服务可以为个体服务或分组服务，例如服务组件或服务单元。SPM还可以核查服务相关性、复合服务以及服务引用。再者，SPM可以核查被限定在每个服务和参与方上的SLAs以及针对每个服务所限定的阈值。

一旦服务及针对这些服务的消费者和提供者各方被识别，下一步是测量可观察值320，或者测量度量值。可测量度量中的一些可以包括服务度量、基础结构度量以及来自有效负载的业务度量。服务度量可以包括吞吐量、延迟、请求大小、错误以及可用性信号；基础结构度量可以包括容量、存储器以及关于中央处理器(CPU)的信息；而来自有效负载的业务度量可以包括用户身份或角色、来源以及交易值。在实施方案中，业务度量可以直接从请求的内容或包络(envelop)中提取。例如，用户身份、请求的来源或者以美元或欧元为单位的交易金额可以用来关联一值，通过该值使一请求具有优先权。还可以搜集与可以通过JMX工具(instruments)来搜集的物理部署体系结构有关的度量。

度量及其值经过一段时间搜集后，数据可以被分析并且未来数据需求可以在分析和预测行为的步骤330中被预测。可以由计算和聚集来分析数据。特定行为模式可以被识别，这可以帮助预测未来数据需求。可以执行统计的和基于时间的分析，其中除了用于移动时间帧窗口的值以及用于前一小时、前一天、前一星期或前一月的值以外，还计算均值、最大值和最小值。可以执行基础结构聚集计算，其中计算节点对应的(by)度量值和容器对应的度量值。可以执行功能性聚集计算，其中计算服务组件对应的度量值和服务单元对应的度量值。可以执行业务聚集计算，其中计算客户对应的度量值和金额对应的度量值。最终，可以执行基于消费者的聚集分析，其中获得并聚集与消费者角色(例如，金级、银级以及白金级)对应的度量值。

下一步是分析和预测行为的步骤330。任何的这些度量均可以被显示在基于网络的显控工具中，该显控工具可以包括一些预先限定的视图。在实施方案中，这些度量可以通过每分钟获取数据以及更新度量值来提供实时值。各种视图可以被配置来监控各种等级的性能，例如，环境、机器、节点、服务组件以及服务单元。显控工具可以根据需要是个性化的，用于特定的业务需要来获得实时的更新，包括但不限于，服务可用性、服务用法、服务错误、业务有效负载。使用所公开的SPM来监控服务，可以限定规则包和规则，并且可以选择应用这些规则的目标对象。在实施方案中，这些对象被称为引用目标对象。此外，可以在可用于被选择的目标对象的默认度量上设置条件，可以创建时间表来在指定时间运行规则，并且可以限定动作并使其与用于管理服务性能的规则相关联。动作可以为默认动作或自定义动作。当规则被使能时，系统可以针对被限定在规则中的指定的一套条件开始监控所有引用目标对象。当度量值达到阈值条件，规则被触发，这又启动动作来在指定的范围内管理该性能。在实施方案中，基于服务消费者和提供者之间的SLA，可以限定一套规则。这些规则能够被监控并被定制，这帮助消费者和提供者两者追踪服务执行情况并且遵循服务等级业务协议。

可以在度量值上限定阈值条件并且可以基于该度量设置规则。当达到这些阈值等级或满足被限定在规则中的条件时，一种或更多种警报或动作可以被触发350。在实施方案中，如果SLA中存在任何违规，则发出警报。警报可以被显示在显控工具中作为可视指示器。有时，这些警报可以以内部的方式触发特定动作，包括但不限于，运行脚本、将事件记入日志或发送邮件通知。

在实施方案中，除警报外，特定纠正动作也可以被设置来在规则中执行。当满足规则中的条件时，这些纠正动作可以自动地被执行，这可以有助于业务连续性(continuity)。纠正动作中的一些可以包括自动资源分配、开始节点或事件管理。

用户工作流

在实施方案中，业务中实施SPM所包括的主要步骤的高度概括包括识别技术需求、配置系统以及监控性能和管理系统。

图4为图示说明用于识别技术需求的用户工作流的示意图400。这可以包括设置业务的技术需求。在实施方案中，业务分析员410识别使用在业务中的所有服务，并且提供数据420来建立并配置SPM。这种数据可以包括所有服务等级中的业务需求。数据420被提供给系统管理员430。然后，这样的信息，包括但不限于来自系统管理员430、系统架构师440以及SPM管理员450的信息以及其他信息可以被编辑来确定这样的技术需求460，包括但不限于，针对服务、规则、动作、节点以及机器的需求。为测量业务服务的性能，监控点(例如服务、流程、机器以及节点)被确定。数据被提供给SPM管理员450并且可以引导SPM的建立和配置。

图5为图示说明用于配置系统和性能监控规则的用户工作流的示意图500。可以由SPM管理员510配置域和环境530。配置530可以包括SPM管理员510，该SPM管理员510识别要由SPM实例管理的所有环境和域，识别所有服务容器，和/或识别在这些环境和域中的所有服务。在识别服务容器和服务后，SPM管理员还可以配置或限定目标对象组570，来将目标对象分到逻辑组中。例如，在实施方案中，SPM管理员可以选择将具有金级SLA需求的所有服务放入一个目标对象组，而将所有其他服务放入另一目标对象组。在目标对象组570上限定规则前，SPM管理员检查可用的外度量，以评估它们是否为充足的560。如果分类现有度量或积累新的数字度量需要任何自定义度量，SPM管理员限定自定义度量560。基于SLAs或服务性能的非正式预期，SPM管理员在目标对象组上限定规则并将这些规则组织成目标和规则包550。SPM管理员限定当针对特定目标对象540触发或清除规则时所采取的动作。这些动作包括向一组用户发出警报、缓解动作、规模调节(scaling)动作(例如供应服务容器(节点/引擎)或者将服务部署到新服务容器)、自动防护(例如阻挡用户发送过多的请求)或者管理员限定的自定义动作。在实施方案中，SPM的管理员510可以使用生成和配置规则透视图来在一组被选择的目标对象上限定规则。适合的服务被分组作为目标对象组并且在其上限定规则。这些规则可以包括被限定在服务度量上的条件。规则还可以与当满足规则中的特定条件时自动触发的自定义动作相关联。观察和管理显控工具透视图显示各种形式的度量数据，例如图表和报告。

图6为图示说明用于监控和管理系统的用户工作流的示意图600。SPM管理员610可以通过观察未处理的和聚集的度量的显控工具，利用相关的环境(context)信息(例如部署细节、机器和节点信息以及所生成的警报)交互地监控系统630。如果限定规则，系统将比较测量值640和所限定的规则条件阈值，并且如果需要则触发动作620。可以由外部系统通过分析度量的历史(historic)性能来动态地生成阈值。测试和仿真可以用来生成用于进行比较的阈值。保证动作620可以包括自动防护动作，例如在触发条件已经被缓解前阻挡请求，在触发条件已经被缓解前供应新资源(规模调节)，触发手动工作流来使管理员手动地缓解问题(例如，重启数据库、供应新硬件等等)。还可以通过生成警报消息(电子邮件或其他消息)来触发手动缓解。当条件被限定且满足规则时，规则可以触发动作620。动作可以为例如，发通知、发警报、调用脚本或增加节点。这些动作帮助SPM管理员610管理系统性能，并且保证系统是可靠的。

产品架构

所公开的SPM的体系结构可以包括这样的组，所述组包括但不限于，接入到(plugged into)面向服务的体系结构服务平台的管理员的用户界面，集成到面向服务的体系结构服务平台的后端(back-end)网络服务，以及诸如部署到面向服务的体系结构服务平台基础中的规则服务和动作服务的系统服务。在实施方案中，所公开的SPM可以被集成到TIBCO ActiveMatrix服务平台中。

图7为图示说明SPM产品架构的实施方案的示意图700。SPM包括各种类别的探测器760来监控与SOA平台有关的数据。在实施方案中，探测器被直接嵌入在容器基础结构780内部。探测器也可以测量来自在SOA中提供服务的其他集成软件或应用软件770的信息。附加探测器770可以测量关于每个计算机操作系统的相关信息，来提供附加环境信息，例如CPU、存储器以及网络使用。在实施方案中，SPM探测器可以被增强来支持自定义度量。例如，SPM探测器可以从服务请求有效负载中提取业务信息，提供关于请求的重要性的附加环境信息。由探测器搜集的信息可以通过实时设备总线(instrumentation bus)740被分布到SPM系统服务750。在实施方案中，SPM可以包括运行时间节点服务探测器760，来监控与TIBCO ActiveMatrix和/或数据TIBCO BusinessWorks^TM相关的数据。

一般地，SPM系统服务在一个或更多个特别提供的节点和硬件上的孤立(isolated)SPM系统环境750下运行。在实施方案中，所有针对SPM的服务被寄宿(hosted)于分开的“spmenv”环境中被命名为“spmnode”的节点上。在实施方案中，“spmenv”环境被保持为分开的，并且不用于任何业务服务。SPM系统服务除了其他服务外可以包括规则服务、动作管理器服务、标准动作服务以及警报服务器。规则服务可以收集和聚集基本度量和自定义度量，可以转换(translate)和部署SPM规则，并且可以发出规则触发或清除消息到动作管理器服务。动作管理器服务可以处理规则动作，例如在规则触发或清除消息以及如阻挡进一步的请求或供应新计算资源的保证790的基础上，发警报、调用服务或者记录日志。动作管理器服务可以使用用于警报的模板生成消息。标准动作服务可以在附加的现有节点上部署服务，通过供应新节点来在附加的节点上部署服务，在机器上调用脚本，生成简单网络管理协议(SNMP)异步通知消息或“陷阱(traps)”，并且为用于面向服务的体系结构服务平台引擎控制方法的集成软件提供支持。通过管理总线740，动作被分布回节点来执行。警报服务器允许用户指定电子邮件格式(例如文本或HTML)以及电子邮件的递送方法(例如精简模式(digest mode))。

在实施方案中，用于SOA服务平台的集成软件包括TIBCO Business Works^TM。

SPM的用户界面(UI)被接入到SOA服务平台管理员的管理员中。用户界面包括生成和配置规则的透视图，以及用于观察和管理显控工具的透视图，显控工具包括但不限于，监控显控工具710和SLA显控工具720。另外，UI可以支持监控自定义度量，包括限定自定义度量来监控和管理任何服务的性能。通过实时消息总线或显控工具总线730，性能测量的实时更新以及警报被分布到显控工具。

指令行界面(CLI)(未示出)基本上支持来自UI的所有被执行的动作。CLI还可以支持限定警报模板和将这些警报模板用于电子邮件通知。用来支持SPM UI和CLI的网络服务可以经由标准http协议和实时异步通信总线730来接入面向服务的体系结构服务平台服务器。这些网络服务获得数据并且然后将数据显示给用户。

在实施方案中，在期望执行远程脚本和提取增强的机器度量的所有管理守护进程上运行机器代理。

规则

在实施方案中，通过生成并配置各种规则，用户可以使用SPM监控和管理系统性能。规则限定条件，以用于监控目标对象。规则还可以指定当满足指定条件时要在所选择的目标对象上执行的动作。

在实施方案中，规则是SPM的基本构造块(building blocks)。存在两种类型的规则，简单规则和复杂规则。图8图示说明示例性简单规则810和复杂规则850的流程图800。简单规则810可以具有目标对象812、条件814以及动作816。在实施方案中，创建简单语句来触发一种或更多种类型的动作816(例如，发警报、调用脚本或服务或者将事件记入日志)。复杂规则850可以具有目标对象852，可以具有多于一个条件854、856、858以及动作860。在实施方案中，复杂规则850包括与(AND)逻辑。复杂规则850可以触发多于一个动作860。在实施方案中，基于可用于所选择的目标对象的默认度量限定条件814、854、856、858。

图9是图示说明用来设置或创建规则的步骤的流程图900。在实施方案中，一旦新的规则被创建，其可以被储存在规则库中。用于创建规则的主要步骤包括提供基本规则信息910、选择目标对象920、创建条件930以及设置动作940。

提供基本规则信息910可以包括提供诸如名称和描述的信息。在实施方案中，提供基本规则信息910还可以包括从时间表库中预先限定的时间表指定用于运行规则的时间表。在另一实施方案中，提供基本规则信息910还可以包括针对规则设置优先权。

选择目标对象920可以包括选择单个目标对象或一组目标对象924。一组目标对象924可以由相同类型或具有共享标准的对象形成。目标对象922、924可以为机器、节点、服务组件、服务实例或操作。在实施方案中，目标对象选自TIBCO Active Matrix环境或域的基础结构或部署视图。在实施方案中，TIBCO Business Works^TM服务探测器被安装并且Business Works^TM服务和流程可以被选择作为目标对象。

依赖于所选择的目标对象，使相关的度量可用于创建条件930。条件可以为简单的932或复杂的934。在实施方案中，复杂规则934可以包括增加多达三个的使用逻辑与运算符的条件。条件在运行时间可以被验证，当实现指定的标准时，动作可以被触发。

设置动作940包括设置当满足被限定在规则中的任一条件时要被执行的动作。可以针对任一给定的条件执行单个动作942或多个动作944。动作可以被设置来例如，发警报、调用脚本或将事件记入日志。

规则包

规则可以为单独的规则或者可以为属于规则包的目标的一部分。图10提供规则包1000的概略图示说明，规则包1000的特征在于具有规则A、B、C、D的目标1010，其中规则A、B、C、D分别具有目标对象A、B、C、D；条件A、B、C、D以及动作A、B、C、D。

目标为意图实现明确目的(goal)的规则的集合。目标可以将通用元数据、时间表以及动作施加到被包含于其中的规则上。在实施方案中，被封包(packaged)来实现业务目的的一组目标被称为规则包。规则包可以由基于规则包所表征的服务等级的业务角色(business role)来组织。

图11提供在示例性规则包1110中描绘规则集合的结构的示意图。在实施方案中，规则包为SLA的数字表现形式(digital manifestation)。规则包可以如一条规则那样简单，或者如基于共同目标被分组在一起的数百条规则那样复杂。规则包1110包含一个或更多个目标1120，而目标包含一条或更多条规则1130。在创建新规则包的时候，可以创建目标。规则包拥有默认目标时间表1112，从而所创建的没有时间表的任何目标具有默认时间表可以使用。在实施方案中，默认时间表1112被设置为“总是”，从而时间表总是被应用。规则包1110还可以将通用元数据1118施加到被包含在规则包中的目标1120上。规则包1110具有在SLA中识别提供者和消费者双方1114的选择，以及可选地识别规则包所表征的(角色)的服务等级1116，从而参与方和角色为可选的字段。在实施方案中，为访问规则包，用户必须从生成和配置透视图选择规则包。

引用(Referenced)目标对象

引用目标对象为由一条或更多条规则所引用的目标对象。限定在规则中的条件相对于所选择的目标对象被验证。如果违反条件，规则被触发来发警报。如果规则与动作相关联，动作采取纠正措施并且在指定条件内设法产生(bring)性能。图12提供引用目标对象类型的列表1200。引用目标对象类型可以包括服务类型1210、服务实例类型1220、服务操作类型1230、服务操作实例类型1240、环境或域类型、机器类型1260以及节点或引擎类型1250。在实施方案中，服务类型1210、服务实例类型1220、服务操作类型1230、服务操作实例类型1240以及环境或域类型，可以包括选择TIBCO ActiveMatrix或TIBCOBusinessWorks^TM服务、服务实例、服务操作或流程、服务操作实例或流程实例，以及环境或域。机器类型1260可以包括在其上运行TIBCO ActiveMatrixor TIBCO BusinessWorks^TM的机器。节点或引擎类型1250可以包括TIBCO ActiveMatrix节点或TIBCO BusinessWorks^TM引擎。个体用户和超级用户可以访问引用目标对象库来浏览、删除或重新选择引用目标对象。

时间表

时间表限定循环时间周期，在该周期内运行规则、目标或规则包。在实施方案中，仅仅当规则为单独规则而不属于规则包或目标时，应用针对该规则而设置的时间表。在实施方案中，如果规则在目标中，该目标时间表优先，或换言之，在默认情况下，当将规则加入到目标中时，不复制时间表。规则包包含用于规则包中所有目标的默认时间表，当目标不具有其自身的时间表时使用该默认时间表；然而，目标不是必需具有时间表。

时间表可以包含控制何时相关联的规则应当或不应当被运行的“包括(include)”和“不包括(exclude)”时间段。例如，被称为“高峰时间”的时间表可以包括全年中所有月份从每天下午9点到半夜的时间，但不包括一月份的从上午3点到上午6点的时间。在实施方案中，针对单个时间表限定多个包括时间段和不包括时间段。

在实施方案中，SPM支持由超级用户所有的全局时间表(global schedules)和由个体所拥有的时间表。

超级用户是具有创建和管理全局时间表(包括即时可用的(out-of-the-box)时间表)的特权的用户。全局时间表对所有用户都是可用的。超级用户还可以删除和编辑由个体用户创建的时间表，以及复制用户所拥有的时间表并将其保存为全局时间表。

个体用户可以查看并复制库中的所有时间表，编辑由个体用户所拥有的时间表，查看和使用规则生成器中时间表下拉列表中的全局时间表或其所拥有的时间表，并且创建规则包生成器对话框(dialogs)。个体用户可以利用所拥有的另一时间表或全局时间表来替换已拥有的时间表。可以以全体的方式(在使用旧时间表的每个地方利用新时间表来替换)或单独的方式(导引通过所有使用旧时间表的位置，并且利用另一时间表替换旧时间表)来替换时间表。个体用户也可以删除其所拥有的未在任何地方使用的时间表。

自定义动作

在实施方案中，SPM包括动作库。动作库包含网络服务(web service)列表。这些服务可以自动地执行服务管理任务并保存管理员时间。服务可以做什么的范围取决于网络服务是如何编写的。服务被配置来应用到具体端点或被配置为用于具体目标对象类型的目标服务。

当使用规则生成器创建规则时，其中触发该规则并且满足规则中的条件时用户可以选择调用脚本。在实施方案中，根据对单个节点的需求是否超出最大量，超级用户可以创建被设计为增加新节点的脚本。该脚本还可以包含撤销方法，来在需求再次下降时，移除额外的节点。撤销方法对应于被限定在规则中的取消条件的状态。当创建规则时，个体用户可以选择使用这种脚本。

在实施方案中，SPM提供一些由超级用户拥有的全局服务。在这个实施方案中，SPM仅支持由超级用户拥有的服务。个体用户仅可以在规则生成器中查看服务列表，并且选择哪些服务被应用到规则中。服务名称和拥有者可以显示在规则生成器中。超级用户可以增加对所有用户是全局可用的服务。超级用户还可以删除服务和利用另一服务来替换服务或根本就不用服务来进行替换。如果正在使用中的服务被替换，可以自动向规则拥有者发通知。超级用户还可以在规则生成器中的选择服务面板内阻止或允许显示某些服务。

有条件的SLAs

SLAs指定服务提供者将保证的服务等级。例如，SLA可以保证最大响应时间。在一些情况下，只有当服务消费者遵循具体的条件或责任时，才能够实现SLA。例如，贷款流程服务可以能够保证5-秒的响应时间，但这只有当贷款请求率没有超过每秒钟一个时才能实现。

本发明将SLA规范延伸为包括在服务消费者一方的责任概念。从而，只有如果服务消费者满足指定的责任或限制，SLA才必需被满足。消费者责任是不能由服务提供者控制的可测量的特性，但可以被监控并且如果违背可以被处理(acted upon)。

服务提供者的条件源可以是内部的(例如，提供者物理容量的限制)，或者可以是服务提供者作为服务消费者的次要角色的副产物。在后一种情况下，需要借助于另一服务提供者来完成其任务的服务提供者可以将次要的提供者责任传回初始服务消费者。消费者责任可以包括，例如请求速率、请求大小、请求形式依从、请求内容依从(生成大量错误的谬误有效负载)以及响应配置文件(生成异常后端负载的有效负载)。服务提供者责任可以包括，例如在一段时间内的响应时间、吞吐量、错误率以及可用性。

由于责任一般不由服务提供者控制，责任从根本上不同于普通的SLA特性(例如有保证的响应时间或可用性)。责任可以被有效地使用于若干情景中。这些情景包括提供针对服务消费者正在进行不当行为的高级警示；如果没有满足消费者责任，形成不缓解和提供附加提供者计算资源的决定；提供对SLA违规的洞察(insight)，并且指示识别和隔离违规源的补救步骤；以及当由于未满足的消费者责任而违反SLA时，减轻财务冲击。

用于缓解和自动防护的模式

SPM提供用于缓解系统的任何组成部分的不当行为的影响的方法。系统中的任何组成部分，无论其是服务的消费者或提供者，由于硬件或软件错误均将出现行为不当(misbehave)。SPM可以通过结合源于消费者、提供者以及基础结构的若干因素来检测这样的情况。可识别的情况为消费者约束的(consumer-bound)、提供者约束的(provider-bound)或者基础结构约束的(infrastructure-bound)。

消费者约束的情况包括异常请求大小或吞吐量、生成大量错误的谬误有效负载以及生成异常后端负载的谬误有效负载。提供者约束的情况包括超负载后端CPU、提供者软件故障(failure)以及死锁。基础结构约束的情况包括机器故障和网络故障。

SPM通过收集度量、检测阈值违规以及识别问题源(机器、客户、用户应用程序(user app)、服务等)来评估问题源。SPM具有这样的能力来缓解发生意外情况的应用程序的影响，即通过经由阻拦或节流策略隔离问题源或者如果允许的话移除问题源的能力。

图13为图示说明服务消费者责任以及这些服务消费者责任对在本申请中所描述的面向服务的体系结构自动防护的应用的流程图1300，从而，如在框1310中所图示说明的，跨该体系结构提供实时度量的集合。该动作在附图中被标记为“收集实时度量”，并且其在该体系结构中提供观察数据的搜集、聚集以及分析。可以在本地、主机级(host-level)数据点以及全局级(global level)搜集这些实时度量，在全局级中主机级观察数据可以被聚集和结合。通过提供遍及体系结构的实时度量，可以获得质量上、显著度、及时方面的显著改进，以及度量方面的其他有利改进。

图13中的面向服务的体系结构将使用在框1310中所收集的实时度量，来并列执行框1320和框1330中分别用于分析和预测提供者SLA违规以及分析和预测消费者责任违规的分析和预测步骤。涉及提供者SLA违规的框1320中的分析和预测帮助面向服务的体系结构基于聚集的实时度量(从框1310)有效地分析、预测以及采取动作。如所提到的，在框1320，凭借在全局和本地级聚集数据，系统可以相对于具体地识别由提供者提供的资源中的问题，达到更高等级的粒度和准确度(accuracy)(这又帮助预测可能的提供者SLA违规)。基于相同原理，在框1330，系统也可以相对于在消费者责任约束的SLA已被提交到面向服务的体系结构时根据施加在消费者上的责任识别消费者性能中的问题，来达到更好的粒度和准确度。

一旦在框1320和/或框1330，可能的违规已经被识别，在框1340面向服务的体系结构包括“估算缓解步骤”。取决于被识别的违规，可以如在框1350、1360和1370中所图示说明的，进行数个步骤中的任意步骤。如在这些各自的动作框中所图示说明的，这些违规可以通过以下内容来解决：增加更多的资源，分配不同的资源或者以其他方式重新供应资源(如在框1350中所指示的)；使消费者得到关于该问题的警报，从而消费者可以重新提交工作、重新配置工作、将工作分配给另一提供者，或者采取一些其他行动(如在框1360中所指示的)；或者节流或关闭在消费者计算机(框1370)上操作的消费者(或更具体地为代理进程/守护进程)。

图14为示出用于实施SPM的实施方案的系统1400的框图。在实施方案中，实施SPM特性的SPM计算机1410包括总线或用于在SPM计算机1410的部件之间进行信息通信的其他通信装置。SPM计算机1410还可以包括耦合到总线和存储元件(例如，随机存取存储器(RAM)或其他同样耦合到总线的动态储存器件)的处理器。存储元件储存用于由处理器执行的指令。存储元件还可以储存临时变量。SPM计算机1410可以包括耦合到总线的海量储存器件，用来储存不像被储存在存储元件中的信息那样被定期访问的信息。SPM计算机1410还可以包括通信设备。如果SPM计算机1410正在实施系统的一个实施方案的一部分，则通信设备允许SPM计算机1410与系统的其他部分通信，包括所有服务。SPM计算机1410可以为单个SPM计算机或者可以为多个SPM计算机。

SPM系统的模块在SPM计算机1410中的处理器上操作。规则和测量值可以被储存在数据库1420、1430中，并且可以由SPM计算机1410存取，并且由SPM系统的模块实施或使用。SPM计算机1410通过网络1450发送信息至一个或更多个SOA应用计算机1460和从一个或更多个SOA应用计算机1460接收信息。SPM探测器1465被定位在SOA应用计算机1460上，并且可以监控与SOA平台有关的数据。在实施方案中，探测器被直接嵌入到容器基础结构内部。由探测器1465搜集的信息可以通过网络1450被分布到运行SPM系统服务的SPM计算机1410。度量值和规则可以被储存在数据库1420、1430中，并且可以由SPM计算机1410存取。结果和度量可以通过网络1440被发送到显示计算机1470。在实施方案中，显示计算机1470可以实现显控工具，可以包括在显控工具控制台1480上显示结果和度量。在实施方案中，SPM计算机1410可以通过网络1440写入更新显示计算机和显控工具控制台。

SPM计算机1410通过网络1450从系统探测器1465接收测量值1490，并且通过网络发出保证1495到SOA应用计算机1460。

尽管上面已经描述了根据本文所公开的原理的各种实施方案，应该理解，这些仅仅是以实施例而不是限制性的方式给出的。因此，一个或更多个本发明的宽度和范围不应该被任何上述示例性实施方案所限制，而应该仅仅根据从本公开所授权的任何权利要求及其等同范围来限定。另外，上面的优点和特征是在所描述的实施方案中提供的，但是不应该将这些授权的权利要求的应用限制到实现上述优点中的任何优点或所有优点的过程和结构。

此外，这里的章节标题是为了符合37CFR 1.77下的建议或者以其他方式提供组织标记而提供的。这些标题不应该限制或表征在任何可以从该公开被授权的权利要求中给出的一个或更多个发明。具体地并且以实施例的方式，尽管所述标题提及“发明领域”，但是权利要求书不应该受到在该标题下选择来用于描述所谓的领域的语言的限制。此外，对“发明背景”中的技术的描述并非要被解读为承认该特定技术是本公开中一个或更多个发明的现有技术。“发明内容”也并非要被视为是这里的权利要求书中所阐述的一个或更多个发明的特征。此外，该公开中任何以单数形式提及“发明”不应该被用于争论在该公开中仅要求保护单个具有新颖性的要点。根据伴随该公开的多项权利要求的限制可以提出多个发明，并且因此这些权利要求限定了由此受到保护的一个或更多多个发明及其等同物。在所有情况下，应该根据说明书基于这样的权利要求书本身的价值来考虑权利要求书的范围，而不应该受这里给出的标题的约束。