诸如计算系统集群、数据中心和网格系统的分布式系统涉及管 理大量资源和服务组件。提供给这种系统用户的典型最终服务需要 多样资源和服务组件的组合，其一起递送用户感兴趣的最终服务。 多个组件的这种组合需要仔细地配置和部署这些组件，使其以兼容 的方式对接，从而组合服务被部署并初始化、处理由用户提交的工 作负荷，适度地处理组件级别故障，以及当处理工作负荷波动时提 供鲁棒服务。
实现组件的这种组合涉及对大量不同种类的资源和服务组件的 协同安排。人工管理各种任务倾于乏味和易于犯错。当资源属于多 个管理域时，复杂程度将增加。虽然基于网格的系统能够为跨越共 享多个管理域的资源提供便利，但是从系统管理的观点来看，基于 网格的系统更加难于管理。难于管理的一个原因是，系统管理技术 的当前状态并没有跟上中间件和网格技术发展的步伐。在管理基于 单个或集群的系统中已经取得了一定成绩。即使对于这些系统，在 现有基础上配置和部署新服务或管理现有服务和软件栈的生命周期 时，系统管理仍将面临较高级别的复杂性。在复杂应用环境中，例 如在涉及协同安排由多个商业过程所形成的工作流的环境中，情形 将更加糟糕。在这种情形中，部署和生命周期管理解决方案需要综 合观察所涉及的多层，而当前的系统管理技术不提供构建这种解决 方案所需的手段。
配置和部署软件组件的传统方法，严重依赖于领域专家关于组 件需求、中间件可用性和底层基础架构以及整个IT环境的知识。使 用这种背景知识，首先需要系统管理员配置现有的基础架构，并接 着定制新组件的配置和部署步骤，从而可以成功地部署新组件。在 分布式组件的情形中，这种方法可能费时、易于犯错，并且无法升 级至大规模安装。另外，由于系统管理员是配置工作流程的关键因 素，这种方法没有自动化。
配置和管理系统的大型安装的能力是信息技术界内的活跃研究 领域。本地配置(LCFG)是当前使用的基于脚本的系统，该系统基 于存储在中央数据库的配置信息动态地配置机器(Anderson，P.， “Towards a High-Level Machine Configuration System，”LISA，1994)。 该信息与需要配置在系统上的网络、系统和服务有关。对象组的智 能框架(SmartFrog)是用于指定分布式应用的配置和部署的已知系 统(Goldsack，P.，Guijarro，J.，Mecheneau，G.，Murray，P.，Toft， P.，”SmartFrog：Configuration and Automatic Ignition of Distributed Applications”，HP OVUA 2003)。SmartFrog提供了一种指定应用的 配置和应用之间的依赖性的语言。SmartFrog提供了一种在分布式系 统上处理和部署应用的基础架构。GridWeaver项目正在探究结合 LCFG和SmartFrog技术用于大型系统的配置管理的观点。结构化信 息标准推动组织(OASIS)正着眼于使用web服务管理分布式资源。 网格论坛正在尝试将作为配置描述、部署和生命周期管理(CDDLM) 行为一部分的规范语言(specification language)标准化。
一些技术提供了对参与提供服务的单独JavaTM2平台企业版 (J2EE)组件进行监控的方法。该技术帮助系统管理员监测性能、 识别错误和检查性能瓶颈。

提供了用于管理组合软件服务的计算机实现的方法、数据处理 系统、计算机可用程序代码和活动知识库(repository)。示范性实 施方式接收使用软件服务的请求。如果该软件服务还没有部署在计 算机网络中，示范性实施方式在计算机网络中配置和部署软件服务 的新实例。如果软件服务已经部署，但是没有被恰当地配置和提供 为在该请求需要的级别上执行，则重新配置和重新部署该软件服务。 示范性实施方式执行对部署该软件服务所需的其它支持软件服务和 物理资源的分析，并且可以重新配置和/或部署附加的软件服务以支 持该软件服务的部署。
为了执行这些管理功能，示范性实施方式基于该分析，使用活 动模板在活动知识库中创建活动对象以管理该新软件服务。示范性 实施方式使用活动对象在计算机网络中部署该新软件服务，并且使 用该活动对象在其生命周期内管理新软件服务。活动知识库中的活 动对象相互交互。这些交互导致服务管理行动，从而通过组件软件 服务来实现期望的服务组合，并将该组合维持在其期望状态。

在所附权利要求中阐明了被认为是示范性实施方式的特性的新 颖特征。然而，结合附图和参照下列示范性实施方式的详细描述， 将最好地理解示范性实施方式本身以及使用的优选模式、进一步目 标及其优点，其中：
图1描述了可以实现示范性实施方式的方面的数据处理系统的 网络的图形表示；
图2描述了可以实现示范性实施例的方面的数据处理系统的结 构图；
图3描述了根据示范性实施方式的使用用于配置和部署的活动 知识库的基于组合的服务管理基础；
图4描述了根据示范性实施方式的活动知识库的组件；
图5描述了根据示范性实施方式的、与活动对象相关联的示例 性功能组件和管理接口；
图6描述了根据示范性实施方式的、用于管理组合服务的宏级 别(macro-level)控制；和
图7描述了根据示范性实施方式的、用于部署和管理软件服务 的操作的流程图。

下面文件使用术语“物理资源”或“资源”表示诸如计算机服 务器、计算机网络、文件系统等的硬件资源。这些资源可以开启或 关闭、共享或以专用模式使用，并具有物理位置。术语“计算机服 务”用于指示由运行在一个或多个资源上的计算机程序所提供的服 务。
示范性实施方式提供了对软件组件和服务进行管理的解决方 案。现在参照附图，特别地参照图1-图2，其提供了可以实现实施方 式的数据处理环境的示例性框图。可以意识到，图1-图2仅是示例 性的，并不意图对可以实现本发明方面或实施方式的环境明示或暗 示任意限制。可以对所描述的环境做出多种修改，而不脱离示范性 实施方式的精神和范围。
现在参照附图，图1描述了可以实现示范性实施例的方面的数 据处理系统的网络的图形表示。网络数据处理系统100是可以实现 实施方式的计算机的网络。网络数据处理系统100包括网络102，网 络102是用于在网络数据处理系统100内相互连接的各种设备以及 计算机之间提供通信链接的介质。网络102可以包括诸如有线、无 线通信链接，或者纤维光学电缆的连接。
在描述的示例中，服务器104和服务器106以及存储单元108 连接到网络102。另外，客户端110，112和114连接到网络102。 例如，这些客户端110，112和114可以是个人计算机或网络计算机。 在描述的示例中，服务器104向客户端110，112和114提供诸如启 动文件、操作系统图像和应用的数据。在此示例中，客户端110，112 和114是服务器104的客户端。网络数据处理系统100可以包括另 外的服务器、客户端和没有示出的其它设备。
在描述的示例中，网络数据处理系统100是互联网，网络102 表示全球范围内使用传输控制协议/互联网协议(TCP/IP)组相互通 信的网络和网关的集合。互联网的中心是重要节点或主机之间的高 速数据通信链接的主干网，包括数以千计路由数据和消息的商业性、 政府性、教育性和其它公司系统。当然，网络数据处理系统100还 可以实施为许多不同类型的网络，例如，内联网、本地局域网(LAN) 或广域网(WAN)。图1意在作为示例，并不作为对不同实施方式 的结构性限制。
现在参照图2，其示出了可以实现示范性实施例的方面的数据处 理系统的结构图。数据处理系统200是计算机的示例，例如图1中 的服务器104或客户端110，执行实施方式的过程的计算机可用代码 或指令可以位于其中。
在描述的示例中，数据处理系统200采用包括北桥和存储控制 器集线器(MCH)202，以及南桥和输入/输出(I/O)控制器集线器 (ICH)204的集线器结构。处理器206、主存储器208和图形处理 器210耦合到北桥和存储控制器集线器202。例如，图形处理器210 可以通过加速图形端口(AGP)耦合到MCH。
在描述的示例中，本地局域网(LAN)适配器212耦合到南桥 和I/O控制器集线器204，并且音频适配器216、键盘和鼠标适配器 220、调制解调器222、只读存储器(ROM)224、通用串行总线(USB) 端口以及其它通信端口232，以及PCI/PCIe设备234通过总线238 耦合到南桥和I/O控制器集线器204，而且硬盘驱动器(HDD)226 和CD-ROM驱动器230通过总线240耦合到南桥和I/O控制器集线 器204。PCI/PCIe设备可以包括，例如，以太网适配器、插卡、笔记 本计算机的PC卡。PCI使用卡总线控制器，PCIe却并不使用。ROM 224例如可以是闪速二进制输入/输出系统(BIOS)。硬盘驱动器226 和CD-ROM驱动器230例如可以使用集成驱动电子装置(IDE)或 串行高级技术附加(SATA)接口。超级I/O设备236可以耦合到南 桥和I/O控制器集线器204。
操作系统运行在处理器206上，并协调和提供控制图2中的数 据处理设备200内的各种组件。该操作系统可以是商业上可用的操 作系统，例如XP(Microsoft和Windows是微 软公司在美国、其它国家或者说所有国家的商标)。诸如JAVATM 编程系统的面对对象编程系统可以与该操作系统结合运行，并提供 从数据处理系统200上执行的Java程序或应用到操作系统的调用 (Java和所有基于Java的商标是Sun微系统公司在美国、其它国家 或者说所有国家的商标)。
操作系统的指令、面对对象编程系统和应用或程序都位于诸如 硬盘驱动器226的存储设备中，也可以位于主存储器208中以便由 处理器206执行。可以由处理器206利用计算机实施指令，执行示 范性实施方式的处理，所述指令可以位于诸如主存储器208、只读存 储器224或其它一个或多个外围设备的存储器中。
图1-图2中的硬件设备可以随着实现而变化。诸如闪存、等效 的非易失性存储器或光学磁盘驱动器及类似的其它内在硬件或外围 设备，可以附加或替代在图-2中描述的硬件。另外，可以将示范性 实施方式的处理应用到微处理器数据处理系统。
在一些示范性示例中，数据处理系统200可以是个人数字助理 (PDA)，它通常配置有闪存以提供用于存储操作系统文件和/或用 户生成数据的非挥发性存储器。总线系统可以包括诸如系统总线、I/O 总线和PCI总线的一个或多个总线。当然，该总线系统可以实施为： 利用任意类型的通信结构或架构，为附加到该结构或架构的组件或 设备之间提供数据传输。通信单元可以包括一个或多个用于传送和 接收数据的组件或设备，例如调制解调器或网络适配器。存储器例 如可以是主存储器208或在北桥和存储器控制器集线器202中找到 的高速缓冲存储器。处理单元可以包括一个或多个处理器或CPU。 图1-图2中描述的示例以及上述示例并不意在暗示结构性限制。例 如，数据处理系统200还可以是平板计算机、膝上型计算机或除PDA 形式之外的电话设备。
示范性实施方式的方面提供了用于编译源代码的计算机实现的 方法、装置和计算机可用程序代码。示范性实施方式的方法可以在 数据处理系统(例如，图1示出的数据处理系统100或图2示出的 数据处理系统200)中执行。
示范性实施方式提供用于管理软件服务的计算机实现的方法、 数据处理系统、计算机可用程序代码和活动知识库。软件服务是由 运行在本地或/远程计算机网络上的计算机程序或程序的集合所提供 的服务，其提供对服务请求的部分或完全解决方案，并不需要请求 者执行包括配置、部署和生命周期管理任务在内的与服务关联的任 何管理任务。软件服务的一些示例为薪金名册服务、消费者管理服 务、供应链管理服务、搜索引擎服务、电子邮件服务、认证服务、 消息服务、诸如由WebSphere应用服务器提供的服务、数据库服务、 网络连接服务等的一般应用管理服务。
软件服务管理包括服务依赖性分析、对资源及所部署服务的计 划和调度、配置管理、部署管理和部署后的生命周期管理。这些管 理功能本身是软件服务。示范性实施方式提供这些管理服务，从而 响应于来自用户的服务请求，按照系统化、受控的方式来执行软件 服务的必要安装、配置和部署。另外，实施方式对已部署的服务进 行管理，从而按照当前请求工作负荷和/或预期的未来工作负荷执行 这些服务，并且当不需要或需要维护时，这些服务被断线或终止。
当服务状态偏离期望状态时，示范性实施方式提供管理服务以 将已部署服务维持到期望状态并采取纠正动作。响应于与特定服务 有关的提示，实施方式中的管理服务自动地触发分析，以确定该提 示的原因，确定是否需要使用备选资源或支持服务，并且使用备选 资源和/或服务来重新部署所管理的服务。这些管理服务可以升级， 固有地是自发的，并且可以管理多平台的服务。
图3描述了根据示范性实施方式的使用用于配置和部署的活动 知识库的基于组合的服务管理基础架构。在基于组合的服务管理基 础架构300中，新类型的服务请求302和当前所支持的请求类型的 服务请求304到达服务基础架构管理器接口306。服务请求是针对来 自(i)最终用户，(ii)系统中的其它服务，或(iii)网络中别处的 其它服务的请求。所请求的服务是系统使用一个或多个软件服务和 系统所支持的物理资源所能够提供的服务。
注意到，在完成前请求可以被多个软件服务处理，并且需要通 过在运行时进行配置、部署和管理来使所有这些服务变得可用。软 件服务可以被系统支持，但可能无法在任何时间都能对软件服务进 行配置和部署。即使对软件服务进行了配置和部署，也可能无法将 软件服务配置为满足服务请求关于期望性能的需求和/或服务所期望 的递送方式。例如，请求可能要求以安全或专用服务递送模式传输 服务。
新类型的服务请求302包括针对当前没有布置和部署在系统中 的软件服务的请求。当前支持请求类型的服务请求304是针对已经 布置和部署在系统中的软件服务的请求。另外，注意到，新或当前 支持类型的请求由运行在终端(end-point)资源314上的软件服务 来服务。服务基础架构管理器接口306处发生的请求处理对于服务 请求者而言是透明的。
管理员可以使用管理员接口308与系统交互以执行动作，例如 设置策略，配置或重新配置资源状态，以通过覆盖默认设置等来配 置和部署软件服务。管理员发出的命令经由管理员接口308发送到 服务基础架构管理器接口306。在后端，服务基础架构管理器接口 306与协调和管理服务310和活动知识库312交互。活动知识库312 包括活动对象和活动模板。活动对象经由终端管理接口316与终端 资源314或者运行在终端资源上的软件服务进行交互。另外，协调 和管理服务310还与活动知识库312交互。如前所述，请求实际上 在终端资源314处被处理。
图4描述了根据示范性实施方式的活动知识库的组件。活动知 识库402可以是诸如图3的活动知识库312的活动知识库。如前所 述，活动知识库402包括活动模板404和活动对象406。活动模板是 用于活动对象的模板。活动对象是使用可用资源和其它管理服务实 例来管理已实例化或将被实例化的服务实例(例如，管理服务组件 408之一)的管理对象。系统中的每一物理资源和服务组件在活动知 识库402中具有代表性的活动对象。活动对象通过执行状态和依赖 性管理、配置、部署和生命周期管理来管理那些资源或那些服务组 件。对于所管理的每一类型服务，在活动知识库402中的活动模板 404中存在活动模板。
不论何时对服务的新实例进行实例化，都会根据活动模板404 中表示所实例化的服务类型的活动模板，在活动对象406中也实例 化新的活动对象。然而，并不是任何时候活动模板404中的每一活 动模板都可以具有活动对象406中的实例化活动对象。
随着新的服务在现有服务和/或物理资源之上被组合和实例化， 在活动对象406中实例化新的活动对象。类似地，当不再需要组合 服务时，该组合服务和用于管理该组合服务的活动对象二者都终止。 终止的活动对象作为垃圾被收集。另外，用以支持和组成被终止服 务的组件服务或者资源所对应的活动对象406内的活动对象都被更 新，以反映其不再支持该组合服务的事实。当组件不再需要时，除 非策略另有指示，否则活动对象406内的相应活动对象被终结并作 为垃圾被收集。例如，策略可以指示：不论关于该服务的当前需求， 在任何时刻都配置至少一个服务实例。在这种情形中，当没有针对 该服务的需求时，除了最后一个实例之外，该服务的所有实例都被 终止。
当活动模板404的范围变化或者由活动对象406内的相应活动 对象所控制的环境演进或修改将被应用于活动对象406时，活动模 板404被更新。当新类型的资源或服务引入到被管理的环境时，新 的活动模板同样引入活动模板404中。例如，当6.0作 为企业版JavaBeansTM(EJB)容器服务引入到系统时，在活动模板 404中引入新的活动模板。即使在活动模板404中存在用于  5.x的活动模板时，还是这么做。这是因为管理  6.0与管理 5.x容器显著不同。活动模板具 有关于所提供服务的信息、依赖性要求、一个或多个平台的配置和 部署信息。
当将要支持 6.01时，并不引入新的模板，但是要对 现有的模板进行更新以适应区别。执行该更新是因为从管理的角度 看，这两个发布版本在管理方面区别很小。从模板得到的活动对象 可以管理 6.0容器，也可以管理 6.01容器。 类似地，如果最初  6.0仅部署在 平台  6.0的模板仅具有管理管理容器的信息。如果后 来， 6.0还被部署和支持在平台， 6.0的模板需要被更新以增加这种能力，这是改变模板范围的示例。
对活动知识库402中的活动对象406中的每个活动对象进行编 程，以管理特定的资源或者服务组件通过实现预期的状态来递送特 定于组件的服务。期望状态是由活动对象所管理的实际服务实例实 现期望效果或性能所需的状态。活动对象406中每个活动对象都了 解其负责管理的被管理资源或服务组件的当前状态和期望状态。活 动对象的期望状态可以受系统管理员、策略管理器或系统中其他对 象的影响。活动知识库402提供用于执行查找、服务/资源代理、创 建组成员、设置策略等的手段。
用于配置和部署的控制在两个级别被执行：一个在微级别，另 一个在宏级别。微级别控制操作在服务模板和服务实例对象的级别。 协调多个服务以支持一个或多个更高级服务所需的全面控制由宏级 别控制促进。宏级别控制允许管理服务来协调动作，例如按照一致 的方式来联合服务配置和部署。宏级别系统控制建立在微级别系统 控制之上，并利用微级别系统。
所有的计划相关逻辑(例如用于依赖性分析和共享支持服务) 被封装到活动对象406中。这种逻辑是动态可更新的，并且可以嵌 入插件以增加先前不存在的功能性。
每一活动对象406具有用于对活动知识库中的活动对象所表示 的服务进行管理的四个功能组件。示范性示例中的四个管理功能组 件为：监控、分析、配置和执行(MACE)。这些在图5中示出。
图5示出了根据示范性实施方式的、与活动对象相关联的示例 性功能组件和管理界面。活动对象是诸如图4中的活动对象406之 一的活动对象。在这些示例中，监控功能组件502监控下列实体：
(1)所管理服务的状态；
(2)所管理服务组件所依赖的服务的状态；也即，向管理服务提 供支持的服务组件(如果有的话)的状态；
(3)所管理组件支持的服务组件的状态，也即，依赖于所管理的 服务组件的服务组件(如果有的话)的状态；
(4)管理员输入。
分析功能组件504为活动对象提供决策能力。它由下列事件中 的一个触发行动：
(1)所管理对象的观察状态和期望状态不平衡；
(2)由支持组件提供的功能性和服务级别的不平衡；以及
(3)该组件支持的组件所要求的功能性和服务级别的不平衡。
由于(i)当前状态或(ii)期望状态中任一的变化，可以发生上述任 一不平衡。例如，考虑安装到服务器但是当前没有启动的 WebSphere应用服务器。该应用服务器的当前状态是“离线”。如 果期望状态设置到具有某种属性的“在线”(例如缓冲器大小，处 理的请求数目，到特定数据库的连接，等等)，这导致了不平衡， 该不平衡触发相应活动对象中的分析组件。当通过期望的属性使其 “在线”后，假设当前状态变成“在线”和“丢失到数据库的连接”。 再一次，这导致了触发分析组件行动的不平衡。通过监控功能组件 502来通知当前状态的变化。通过(i)协调和管理组件或(ii)经由管理 员接口的管理员动作，或(iii)来自需要现有策略下的动作的另一活动 对象的服务请求中的任一个，导致期望状态的变化。
当分析组件504认识到所管理对象的当前状态和期望状态之间 存在不平衡时，该分析组件执行分析以建立管理服务将被转变到的 最优配置状态。为了执行该分析，分析组件考虑系统中其它服务和 资源的状态和可用性，以及当前和将被支持的服务组件或工作负载 的需求和优先级。在分析步骤的最后，完全确定了支持资源和软件 服务，并且最终确定表征该支持的参数(例如，表征该支持的参数 可以是连接数、端口数、预期响应时间和最小保证带宽)。类似地， 表征所支持服务的参数也确定下来。
分析的复杂度和特性取决于分析功能组件504可用的决策选择。 可以通过高精度来指定期望状况(例如，在具有启用的特定网络适 配器、具有特定IP地址和以特定方式配置的特定web服务的特定服 务器上的特定版本、发布和补丁级别的“在线”Websphere实例)。 在这种情形中，在没有选择的情况下，分析组件标识将使用的资源 和服务以及应用于支持服务的配置参数，从而使被管理的服务能够 达到前述预期状态。
另一方面，可以通过可能状态的范围或在某种程度自由地指定 期望状态(例如，特定网络子域中任意服务器上兼容6.0版本的“在 线”实例，或者可以无约束地将被启动的服务器上应用 服务器的期望状态设置为“在线”。结果，其可以是第一可用服务 器，或该约束可能需要从一组服务器中使用具有最大容量存储器的 服务器)。当存在选择和配置支持服务和资源的选择时，分析功能 组件504通过与其它活动模板和/或活动对象交互来进行决策。
基于正被考虑配置和部署的现有服务和新服务的可用能力和性 能级别及相应要求，通过将最优问题公式化并求解来实现该交互。 该最优问题的目标由所管理对象相关联的策略来控制。一些与管理 对象相关的策略的示例是特定时间期间内某些用户组独占使用该服 务、维修目的的留出时间、用作支持资源的优选资源实例，等。
分析功能组件504将这些策略考虑在内，并且试图解决系统中 尽可能多的不平衡。如果无法完全消除不平衡，分析功能组件504 试图满足依赖性，从而使可实现的新状态最接近于期望状态，并且 从当前状态转变到这个新状态是可能的。该分析的结果确定用于纠 正系统中不平衡的实际支持服务和资源。由于这些支持服务和资源 的状态确定了管理服务将被转变到的最终状态，管理服务可能无法 总是实现实际的期望状态，但是可以实现次优状态。取决于实现的 状态距期望状态有多远，可以重复分析以及随后的配置和部署步骤。
配置功能组件506从分析功能组件504获取结果，并且执行下 列任务：
(1)创建用以配置或重新配置管理服务组件的现有状态的动作 的计划，从而使管理服务组件可以按照最优方式从其当前状态转变 到新状态；
(2)确定带来组件实际变化的实际命令、脚本和过程；和
(3)在自身配置之前向支持服务组件发送请求消息，在配置变化 适当后向从属(dependent)服务发送确认消息。
执行功能组件508执行下列任务：
(1)执行由配置功能组件506确定的动作计划，从而根据策略来 管理失败风险；
(2)执行核实步骤以确认已经发生期望的变化；
(3)当初始计划并不成功时，执行备选行动计划；和
(4)在适当的配置变化后，核实与支持组件和从属组件的交互。
每一活动对象内封装的MACE功能支持由活动对象表示的被管 理软件服务组件独立地演进以及与其他服务协调演进，并适应发生 在系统中的动态变化。与该领域内的现有技术不同，这些示范性实 施方式并不需要为了管理那些组件而完全集中地评价服务组件。此 处描述的系统允许规定全局性策略来指导系统的整体管理，并不需 要集中决策制定和执行能力。不论何时当活动对象需要操作所管理 的对象时，活动对象触发系统运行时。系统运行时仅检查活动对象 的状态，并执行包含在活动对象内的动作。这种动作中的一些动作 对被管理服务进行操作，而其它动作对在知识库的其它活动对象进 行操作。
例如，活动对象可以发出要求被管理对象“离线”的命令。在 其它情形中，活动对象向其它活动对象发送通知，该通知指明：由 被通知的活动对象所管理的服务不再需要该支持服务。活动对象的 状态可以受诸如资源监控器、服务监控器和其它更高级活动对象请 求管理行动之类的外部事件的影响。当事件改变活动对象的状态时， 先前描述的管理组件被激活，并且活动对象开始将被管理服务指导 入更稳定状态。
活动知识库中的每一活动对象与管理接口相关联，以监控和控 制所管理的资源和服务的性能。在图5中示出由诸如图4中活动对 象406之一的活动对象所提供的示例性管理接口。先前描述的活动 对象的示例性功能组件使用这些示例性管理接口来执行其对管理对 象的管理动作。由于这些控制所产生的动作影响单个终端资源和软 件服务实例，因此将这种管理动作称为微级别控制。示例性管理接 口如下：
(1)服务规范510；
(2)依赖性需求512；
(3)服务配置514；
(4)服务部署516；
(5)服务状态518；和
(6)生命周期管理520。
活动对象从活动模板中继承这些管理接口，其中该活动对象首 先是从该活动模板处被实例化的。在活动模板中，按照较为通用的 方式来表示管理接口，该方式覆盖多种可能配置和部署以及生命周 期管理过程。
服务规范510标识由服务提供的功能。该服务功能包括递送给 客户的实际物理值以及递送该实际物理值的方式二者。由服务提供 的功能可以取决于对服务进行配置和部署的方式。例如，可以将 stock-quote(股票报价)服务配置为提供实时报价或延迟报价。类似 地，可以将文档递送服务配置为递送经过加密或的文档未经加密的 文档。在服务模板对象中，列出了所有可用功能。服务实例对象列 出了选中的特定功能以及在该实例中当前使能的功能。
依赖性需求512具有两个部分：
(a)对从属服务的需求；以及
(b)对依赖服务的需求。
依赖性需求512的第一部分描述依赖性需求，以便使服务可用。 在服务模板对象中，针对服务能够传送的每一功能列出依赖性。在 服务实例对象中，仅针对该实例中支持的的功能列出依赖性。除了 资源依赖性(例如，需要具有至少两个CPU和企 业AS版本3OS的服务器)之外，依赖性信息还包括空间依赖性(例 如，服务器可能依赖于数据库、文件系统，而这些需要在部署该服 务的相同子网上可用)和时间依赖性(例如，备份服务器可能依赖 于每个星期五从上午2点到上午3点访问高带宽网络。)
依赖性需求512的第二部分描述了施加在依赖于该服务的服务 上的需求。该部分仅对未被部署为高级别服务的服务有意义。高级 别服务是这样的服务，其不支持系统中任意其它服务，但是可以处 理最终用户请求。这些需求中的一些需求是静态的(例如，取决于 软件版本)，一些是半静态的(例如，取决于所启用的服务功能)， 还有一些可以是动态的(例如，取决于由其支持服务所递送的服务 质量，服务可以调整该服务施加在该服务所支持的服务上的需求)。 在活动对象中，仅针对服务规范接口512中启用的功能来暴露该依 赖性需求。
服务配置514具有三个部分：
(a)支持服务的配置；
(b)所管理的服务实例的配置；以及
(c)所支持的服务的配置。
服务配置514的第一部分管理关于配置支持服务的信息，使得 可以在支持服务之上对该服务实例进行配置。通用服务应该可以运 行在多种提供相似功能性的支持服务上。例如，如果服务可以部署 在具有操作系统的服务器上，则操作范围是有限的。但是，如 果该服务可以运行在的任意变体上，则该服务的操作范围将 更大。如果该服务还可以部署在操作系统内的服务器上， 该服务将更大。
然而，随着可接受的支持服务的范围增长，选择以及相关联的 部署步骤可能变得非常复杂(除了管理多个软件包之外)。复杂度 由服务配置514的第一部分管理。对于每种可接受类型的支持服务， 服务配置514维护关于待设置参数和待执行初始化步骤的信息(例 如，在执行安装步骤之前可能需要创建特定用户和群组ID，根据某 种计划可能需要初始化数据库表，可能需要架设特定的文件系统， 等等)。
服务配置514的第二部分针对一组满足依赖性需求的支持服务 来，管理关于服务实例的信息。服务配置514还把将要被启用的特 定服务功能性考虑在内(如服务规范部分所述)，并管理配置步骤 使得仅启用选中的服务功能。
服务配置514的第三部分管理配置从属服务的方式。例如，服 务配置514可以提供插件从而使客户能够以特定方式与服务配置 514交互，或监听特定端口从而使从属服务可以发送请求，或使用客 户端特定的主题在出版-预定消息网络上发布信息，等等。
服务部署516针对支持服务的特定配置、将要启用的服务功能、 以及将要支持的较高级别的服务，管理服务实例的部署。服务部署 516包括三个部分：
(a)部署动作；
(b)有效性测试和集成测试；以及
(c)恢复动作。
该部件基于服务配置514中规定的配置来管理动作。提供有效 性测试和集成测试是为了以递增方式来管理复杂的部署步骤。在有 效性测试和集成测试期间失败的情况下，服务部署516还包含恢复 动作。
服务状态518具有三个部分：
(a)所递送服务的状态；
(b)支持服务的状态；以及
(c)被支持服务的状态。
服务状态518的第一部分列出选中的和启用的服务功能。对于 每个功能，服务状态518描述所观测的性能范围和预期的性能范围。 服务状态518的第二部分列出被选中用来支持该服务的实际服务实 例。服务状态518还通过该服务、与每个服务实例的服务级协议以 及任何违反(violation)来描述每一支持服务实例的当前使用。服务 状态518还描述当前状态的各种属性，例如，其可以声明：以专用 模式或共享模式来部署该服务，并且可以指出相应的策略或商业规 则。类似地，服务状态518的第三部分列出该服务实例所支持的实 际服务实例、那些服务实例所提出的要求、以及被支持服务的当前 使用。服务状态518还列出与所支持服务的任意服务级别协议，以 及任何违反。
生命周期管理520具有三个部分：
(a)服务生命周期的管理；
(b)用于部署该服务的软件包的生命周期的管理；以及
(c)服务管理层的生命周期的管理。
在生命周期管理520的第一部分中，服务生命周期的管理主要 涉及关于服务实例的“开始”、“停止”、“暂停”和“重启”类 型的生命周期事件。在生命周期管理520的第二部分中，软件生命 周期的管理涉及软件包的位置、访问软件包的动作和许可、软件版 本、升级和补丁管理。在生命周期管理520的第三部分中，管理服 务管理层自身的生命周期。在特定服务将要完全消除的情况下，这 允许服务管理层演进或终止。
活动对象内导致分析和后续动作的行为是由在单个活动对象的 级别处观测到的状态不平衡来驱动的。仅仅考虑对活动对象可用的 信息以及可应用于活动对象的策略，活动对象的分析功能组件504 处所做出决策是局部的。该决策并不考虑全局策略或权衡。例如， 如果活动对象发现，其可以选择使用功能相同但性能不同的两组支 持服务之一，其可以使用局部标准和策略来根据局部需求选择一组， 而不考虑其它服务的当前或将来需求。多个活动对象是同时活动的， 并且多个活动对象的分析功能组件在其操作限制内持续地尝试优化 其所管理的服务的状态。在下文中，将在响应于针对该类型服务的 请求的新服务实例配置的上下文中来解释这些动态性。
当无法使用现有服务或服务组件来服务于服务请求时，通知表 示所请求服务类型的活动模板。继而，该模板评估该请求，并且实 例化新的活动对象来管理该服务的新实例，或者指示现有的活动对 象重新配置管理对象来适应新请求。简单地通过改变管理服务的期 望状态来执行用于重新配置的指令。这种情形下的后续动作是在创 建新活动对象时随后的动作的子集。在下文中，描述了由新实例化 的活动对象所执行的一组动作。这些动作递归地向下遍历依赖树， 并建立组件服务树，直到整个组合服务完全被配置和部署，以此根 据组件服务对组合服务进行组合和部署。
在该活动知识库的建立中，活动对象的直接依赖性是已知的， 但并未得到满足。当在活动知识库中实例化活动对象时，为活动对 象指派被称为期望状态，以及被称为当前状态的另一状态。当前状 态是由活动对象管理的服务或资源的状态。期望状态是管理服务或 资源的期待状态。
活动对象中的分析功能组件504持续地监测这两个状态。如果 这两个状态不匹配，分析功能组件504分析将当前状态转变到期望 状态的可能选择，并且确定为了达到该期望状态是否存在任意必须 满足的依赖性需求。因此，在活动对象被实例化时，如果当前状态 是“离线”而期望状态是“在线”，活动对象中的分析功能组件504 检查需要满足的依赖性以使管理资源/服务“在线”。依赖性信息存 储在依赖性需求512接口中，它是管理对象的六个管理接口之一。 通过所需服务或资源的类型来表示每一依赖性。依赖性分析标识将 当前状态转变到期望状态所需的特定类型的服务或资源。另外，分 析功能组件504还确定满足依赖性所需的其它服务/资源上的性能和 任何位置约束。这是期望状态的功能。
例如，如果web服务器的期望状态需要每分钟处理m次业务， (此时m的值已知)，分析功能组件504首先确定该web服务器依 赖于数据库服务，接着它量化该数据库服务满足性能需求的特征。 由于该数据库服务是通过读取和更新数据记录的速度来表征的，因 此分析功能组件504计算其有资格作为支持服务所需的最小读取和 更新速度。换句话说，分析功能组件504计算关于支持数据库服务 的一组性能约束。m，u和r之间的关系可以由单一代数公式表达， 或者可能需要表示该数据库系统的近似性能的多项式等式计算。
将用于确定来自实现某种期望状态所需要的支持服务的性能级 别的性能特定的特征编码到依赖性需求512接口。注意到，分析功 能组件504并不识别用于满足特定依赖性的管理服务或资源的确切 实例。分析功能组件504仅仅量化需要的管理服务或资源的类型， 以及性能、位置和支持组件的安全约束。关于期望状态、到达该状 态需要满足的依赖性、对管理服务或资源的约束的信息，被送交给 配置功能组件506。
配置功能组件506确定其用以满足依赖性的能力的实际组件和 部分。为了做出这个判定，对于每个未满足的依赖性，配置功能组 件506联系表示满足该依赖性所需要的服务/资源的类型的活动模 板。对于每个这种活动模板，配置功能组件506发出对其正在寻找 的服务类型的请求以及必需满足的关联约束。每个这种活动模板试 图通过下列三种方式之一来满足该请求：(i)指定现有服务或资源来 提供所需的支持，(ii)重新配置现有服务来适应新要求，或(iii)配置和 部署新的服务实例来提供所需的支持。当这些选项无一可能时，配 置功能组件506返回否定信息。当可以提供支持时，配置功能组件 506返回管理该支持服务的相应活动对象的地址。注意到，可以通过 可接受范围来表示关于依赖性的性能约束。在这种情形中，期望已 标识的支持服务在该范围内递送服务。这里，策略也将发挥作用。 策略可以指定可以放宽约束的条件，并且可以指定放宽约束的程度。 支持活动模板在进行决策时考虑这些策略。
每一支持活动模板的后续步骤与上文在触发活动对象处动作的 原始请求的上下文中所描述的步骤相同。递归地执行这些步骤，直 到解决了所有的依赖性，或者确定：给定的系统资源组设置和当前 的策略设置无法解决它。因此，对用于向任意服务组件提供支持的 整个依赖树进行自上而下地遍历：从活动模板到活动对象到支持活 动模板，依此类推。通过对依赖图的并发深度优先遍历，按照自下 而上的方式建立实际服务的依赖树。
只要将支持服务配置和部署为准备提供必需服务的状态，便通 过肯定确认以及管理该支持服务的活动对象的细节来通知请求活动 对象。此时，所有的管理服务或资源组件及其当前配置(包括其可 用能力)对于依赖图中的每一节点都是已知的。使用该信息，配置 功能组件506量化支持服务之上的配置服务中所使用的实际参数。 所述参数可以包括：IP地址、使用的通信端口、用户ID和允许访问 支持服务的密码、缓冲器大小，等等。这些细节取决于服务的类型。 此配置信息接着传递到执行功能组件508。
执行功能组件508执行建立和安装过程并发送命令，从而使被 管理服务在支持服务之上以期望状态被实例化。随后的命令和过程 存储在活动对象的服务部署516接口中。这就完成了对作为组合服 务的构成的服务的部署。随后，对该用户请求进行处理，或者在这 种服务组合之上组合其它更高级级别的服务。
如前所述，根据组件服务来确定依赖树的整个过程是经由活动 知识库中的活动模板和活动对象来动态遍历的。通过对依赖图的并 发深度优先遍历，由依赖图中节点表示的实际服务组件以自下而上 地方式被配置和部署。
如果已经部署了实际组件，但是需要重新部署实际组件，相应 活动对象调用特定动作，以便引起期望的组件配置变化。只要组件 被配置和部署并且其性能令人满意，便通知依赖图中更高级别处的 活动对象。当已知实际组件的所有支持组件已经准备好和起作用时， 下一级别的对象对实际组件进行配置和部署。该过程继续，直到包 括高级别服务组件在内的所有组件被配置、部署，并处于服务传送 状态。
因此，在微级别，活动对象控制其负责服务管理的活动服务实 例。在这情况下，它们还影响支持的服务和被支持服务或资源实例 的性能。而且，其对被支持和支持资源的行为改变进行响应。然而， 微级别控制并没有带来将全局约束和策略考虑在内的同步全局改 变。这些改变由宏级别控制引起。需要宏级别控制来执行全局策略， 诸如共享临界资源的方式、需求被给予优先级的方式及需求被服务 的方式，等等。在资源缺乏以及需求可能超出供给时，这种策略是 必需的。当要进行复杂决策以及权衡并不明确时，策略也是必需的。
这个示范性实施方式的新颖性在于，其通过局部微级别管理控 制支持了对全局控制机制进行组合。
图6描述了根据示范性实施方式，用于管理组合服务的宏级别 控制。协调和管理服务600是诸如图3中协调和管理服务300的协 调和管理服务。协调和管理服务600包括提供用于管理组合服务的 宏级别控制的管理服务。协调和管理服务600由分析和计划引擎 602、配置引擎604、部署引擎606、监控引擎608和生命周期引擎 610提供。这些引擎中的每一个与活动知识库612和活动知识库612 中呈现的管理对象相交互。
如前所述，活动对象内的分析和后续动作由被管理服务实例的 期望状态独自驱动。然而，在决定临界服务和资源的分配、共享和 调度时，这些服务和资源可能需要全局考虑。在这种情形中，分析 和计划引擎602执行关于分配、共享、安排的裁决和决策。这些决 策继而确定一个或多个活动对象的期望状态。类似地，全局配置和 部署考虑导致诸如图3中活动知识库312的活动知识库中的一个或 多个活动对象的微级别调度步骤。因此，由图6示出的五个引擎所 提供的宏级别控制被转变为微级别控制。活动知识库612中的活动 对象控制相应的资源和组件服务，从而使宏控制的期望状态在微级 别处被实现。
如前所述，活动知识库管理软件服务组件的所有生命周期方面， 以响应于服务请求来递送解决方案。活动知识库执行该功能时将账 户相关的系统管理策略以及由物理资源可用性设置的约束考虑在 内。该生命周期管理的一方面是当需要组合服务时，对复杂服务进 行组合。另一方面是当没有需要、或策略需要这种动作，或者一个 或多个支持服务不可用时，结束或分解复合服务。
作为示范性示例，图7描述了根据示范性实施方式的、用于部 署和管理软件服务的操作的流程图。随着操作开始，接收在计算机 网络中部署软件服务的请求(步骤702)。如果所请求的软件服务是 新的软件服务，活动知识库(诸如图3的活动知识库312)中现有的 活动模板和活动对象使用这些资源来执行对将要管理的所请求软件 服务所关联的物理资源以及当前软件服务集的分析(步骤704)。
新的软件服务是当前没有被现有活动对象管理的服务。该分析 之后，表示将要创建的新服务类型的活动模板首先在活动知识库中 实例化活动对象(步骤706)。该活动对象管理新软件服务。活动知 识库使用活动对象在网络中部署软件服务(步骤708)，并且该活动 对象管理该软件服务(步骤710)，随后操作终止。使用在相关应用 中描述的方法来执行软件服务的实际部署。在创建活动对象之后， 活动对象如关于图5所描述的那样来管理软件服务。
如果所请求的服务是现有的软件服务，活动知识库标识管理该 现有软件服务的现有活动对象。使用现有活动对象将现有软件服务 部署在网络中，并且使用现有活动对象管理对其进行管理。
由此，示范性实施方式接收针对服务的请求。如果所请求的服 务当前未被部署，响应于所请求的服务是新软件服务，实施方式执 行对配置和部署将被管理的所请求软件服务所需的物理资源和其它 组件软件服务的分析，以此来服务于该请求以及其它请求。这些步 骤可以导致识别需要进行配置或重新配置以及部署或重新部署的其 它组件软件服务。示范性实施方式执行所需的动作，从而使所请求 服务作为一个或多个处理该请求的被管理服务的组合而变得可用。
示范性实施方式还对针对当前已经配置、但没有以处理该请求 所期望的形式而配置的服务的请求进行响应。示范性实施方式通过 重新配置和/或重新部署一个或多个服务组件和资源来采取动作，从 而能够以期望配置来部署所请求的服务。示范性实施方式基于该分 析使用活动模板，创建活动对象以管理新软件服务。最后，示范性 实施方式使用活动对象在网络中部署新软件服务，并且使用活动对 象管理新软件服务。在控制和管理软件服务时，活动知识库中的活 动对象相互交互。这些交互导致服务管理行动，从而通过组件软件 服务来实现期望的服务组合，并且将该组合维持在其期望状态。
本发明可以采用完全硬件的实施方式、完全软件的实施方式， 或包括硬件和软件组件的实施方式的形式。在优选实施方式中，以 包括但不限于固件、驻留软件、微代码等的软件实施本发明。
另外，本发明可以采用计算机可用或计算机可读介质可访问的 计算机程序产品的形式，该介质提供计算机或任意指令执行系统使 用或与其相关的程序代码。为了描述目的，计算机可用或计算机可 读的介质可以是容纳、存储、通信、传播或运送由指令执行系统、 装置或设备使用或与其相关的程序代码的任意有形装置。
该介质可以是电子的、磁的、光的、电磁的、红外线的或半导 体系统(或装置或设备)或传播介质。计算机可读介质的实例包括 半导体或固态存储器、磁带、可移动计算机磁盘、随机访问存储器 (RAM)、只读存储器(ROM)、硬磁盘和光盘。光盘的当前实例 包括致密盘-只读存储器(CD-ROM)、致密盘-读/写(CD-R/W)和 DVD。
适于存储和/或执行程序代码的数据处理系统，包括通过总线直 接或非直接地耦合到存储器的至少一个处理器。存储器组件可以包 括在程序代码的实际执行中使用到的本地存储器、大容量存储器， 以及提供至少部分程序代码临时存储以减少在执行中从大容量存储 器检索代码的次数的高速缓冲存储器。
输入/输出或I/O设备(包括但是不限于键盘、显示器、指针设 备等)，可以直接或通过与I/O控制器交互耦合到系统。
网络适配器也可以耦合到系统，通过与私有或公共网络交互， 使数据处理系统耦合到其它数据处理系统或远程打印机或存储设 备。调制解调器、电缆调制解调器和以太网卡仅是当前可用类型的 网络适配器中的一些。
本发明呈现的描述是为了说明和描述目的，并不意欲穷举或将 本发明限制为披露的形式。对于本领域技术人员，本发明的许多修 改和变化是明显的。选择和描述实施方式，以最好地解释本发明的 原则和特定应用，并且使本领域的其它技术人员理解本发明具有各 种变化的各种实施方式适应于特定的使用构思。