专利名称：用于管理在分布式系统中的附属关系的方法和装置的制作方法
技术领域：
本发明涉及分布式计算系统，特别涉及用于管理在这种分布式计算系统中的各个组件之间的附属关系的方法和装置。
背景技术：
分布式系统中的组件之间的附属关系(dependency)的识别和跟踪对于综合故障管理来说变得越来越重要。应用程序、服务以及他们的组件各种支持服务，这些服务可能是一个服务提供者外部提供的。另外，基于网络(基于万维网)商务构架的出现允许在运行时间中编辑基于网络的电子商务应用程序福。
应当知道术语“运行时间”通常是指一个软件被执行以及在计算机系统存储器中激活的时间段，与静止和仅仅位于计算机硬盘驱动上的存储器中的状态相对。因此，能够在运行时间编辑电子商务应用程序是指能够执行该操作而不需要关闭并且重新启动该系统/应用程序，并且不需要重新编辑该应用程序。通常，一个计算机程序的操作周期是编写程序代码-＞编译(转变为机器代码)-＞运行。因此，通过上述功能，人们可以“飞快地”汇编几个程序会以形成的一个新的程序，即，如需要关闭/编译/重新启动该应用程序。
但是，在一个服务中出现的故障影响被提供给一个客户的其他服务，即，服务从属于其他服务。在单个系统上的不同服务的组件之间以及在多个系统和域上的一个服务的客户机和服务器组件之间存在附属关系。在此，附属于其他服务的服务被称为附属者(dependents)，被其他服务所附属的服务被称为先前者(antecedents)。
应当注意一个服务通常扮演两种角色(例如，一个名服务被许多应用程序和服务所要求，但是它本身附属于其他服务的适当功能，例如操作系统和网络协议以及下部结构)。另外，附属关系是传递的，即给定组件的附属者除了需要该组件本身之外还需要该组件的先前者。
附属关系存在于分布式系统的各个组件之间，例如终端用户服务、系统服务，应用程序以及他们的逻辑和物理组件。但是，服务附属者，关系在单晶系统中并不清楚，因此使得问题决定、隔离和解决的任务特别困难。
在软件开发(例如美国专利4,751,635和美国专利5,960,196)、维护(例如美国专利5,493,682)和软件封装(例如美国专利5,835,777)领域中的现有技术处理形成于一个程序封装的原子部分的各个软件单元，并且需要程序源代码的可用性，以构建软件并且把它捆绑成软件产品。
电子和电气工程师协会标准1387.2(名称为“便携式操作系统接口(POSIX)系统管理，部分2软件管理”，IEEE，1995)针对于软件发布/调度/安装。IEEE标准定义用于保证(要被安装的)新的软件组件不与现有的软件安装相冲突。IEEE标准所识三种关系先决条件(prerequisite)、非必要条件(exrequisite)、共存条件(corequisite)，则促进兼容性检查。这对需要安装新软件的每个系统分别执行。利用IEEE标准，存在于其它系统上的软件目录不被考虑。另外，IEEE标准不处理例示应用程序和服务，因此，没有提供任何确定在运行时间中组件之间的附属关系的任何方法。
开发组(系统管理分布式软件管理，CAE标准C701，开放组，1998年1月)通过定义几个命令(swinstall、swlist、swmodify，等等)而扩展IEEE 1387.2，这些命令由在特定系统上的软件安装工具所调用。开发组还定义一个软件定义文件格式，以保证上述命令所需的信息可以从调用该命令的系统所获得。IEEE 1387.2的缺点(即，局限于单个隔离系统，没有方法用于确定在运行时间中软件的附属关系)也应用于该开发组标准。
当前操作系统详细目录实现(例如，IBM AIX对象数据管理器(ODM)，Linux红帽包管理器(RPM)微软视窗登记)遵守开发组标准和IEEE 1387.2标准或者以所有者格式描述软件目录。因此，上述限制也应用于这种当前操作系统目录实现中。
用于整个程序包的电子软件发布的技术(例如，美国专利6,009,525和美国专利5,721,824)或者更新/纠正/整理/修补(例如，美国专利5,999,740、美国专利5,805,891和美国专利5,953,533)通过定义被限制为(一次执行一个或多个)实际软件包的发布/调度/安装，并且不考虑到应用程序的运行时间阶段。另外，它们在一个时刻处理一个系统，并且不考虑到应用程序和服务的交叉系统方面。
用于确定在现有的软件/硬件配置中的冲突的技术(例如，美国专利5,867,714)也被限于单个系统，并且没有考虑到运行时间方面。
尽管现有的工作(例如，美国专利5,917,831)通常在事件相关关系的范围内(Gruschke等人的，″Integrated Event ManagementEventCorrelation Using Dependency Graphs，DSOM′98，1998，以及Ktker等人的.，″Fault Isolation and Event Correlation for Integrated FaultManagement，IM′97，1997)已经把注意力集中在识别和用所有者格式描述服务附属关系，现在还不清楚在故障管理过程的不同实体之间实际可以交换多少附属关系信息。由于在来自外部的应用程序的故障管理过程中所涉及的不同各方使用相同的工具箱用于指定和交换附属关系信息。
总而言之，与软件产品之间的关系确定相关的几种技术已经被描述并且应用于现有技术中。这些现有技术具有如下的一种或多种缺点(a)它们仅仅针对于软件产品的安装和调度阶段；即，它们不尝试解决设计和运行时间方面的问题；(b)它们不处理跨过多个系统的端到端应用程序和服务；即，它们针对于驻留在单个、隔离的系统上的软件的特性；以及(c)软件目录信息被以所有者格式而描述，这使得它非常难以在各个相异系统之间共享该信息。
发明内容
本发明提供用于管理信息的技术，特别是在一个计算环境中的各个组件之间的附属关系信息。例如，本发明的技术可以应用于分布式计算环境。该计算环境也可以是一个自治的计算环境。
在本发明的一个方面中，用于在计算环境中的管理信息的技术包括如下步骤/操作。获得与该计算环境的组件相关的信息。然后，从至少一部分所获得的信息确定与该计算环境的至少一部分组件相关的一个或多个关系的存在。根据本发明，一个或多个关系的存在的确定能够考虑到(accounting for)与该计算环境的至少一个组件相关的整个操作周期(例如，包括调度、安装和运行时间)。例如，一个组件可以是一个服务、应用程序、中间件、硬件、设备驱动器、操作系统或者与该计算环境相关的系统。但是，术语“组件”不限于这些例子。
另外，该技术也能够考虑到与该计算环境的至少两个组件相关的相异性，并且考虑到跨越与该计算环境相关的一个或多个域的一个或多个组件。
在一个优选实施例中，本发明的技术通过计算以包括功能分类、结构分类和操作分类的形式计算组件附属关系而确定是否存在一个或多个关系。
因此，本发明有利地提供从各个系统的一级概括，并且允许如客户所感知的与端到端服务相关的服务/应用程序附属关系的计算。
与上述在现有技术中的限制相反，本发明通过向客户提供一个较高级别(端到端服务/应用程序)的跨越多个系统并且反映所涉及的系统、应用程序和服务的运行时间中的行为的视角，而克服这种缺点。所收集的附属关系信息被以一种开放、可扩展的格式来描述，以促进数据交换。
从下文结合附图示出示意实施例的详细描述中，本发明的这些和其他目的、特点和优点将变得更加清楚。
图1为示出具有与本发明的特征相互作用以产生信息的一个客户机-服务器应用程序构架的一个例子的方框2A为示出根据本发明一个实施例用于提供附属关系管理的系统的方框图；图2B为示出根据本发明一个实施例适用于实现提供附属关系管理的系统的计算机系统的一般硬件构架的方框图；图3为示出根据本发明一个实施例的服务的功能附属关系模型的方框4为示出根据本发明一个实施例的服务的结构附属关系模型的方框图；图5为示出根据本发明一个实施例的由功能、结构和操作附属关系模型所针对的服务操作周期的方框图；图6为示出根据本发明一个实施例的在功能、结构和操作附属关系模型之间的关系的方框图；图7为示出根据本发明一个实施例的在计算端到端附属关系中所涉及的组件的方框图；图8为示出根据本发明一个实施例的附属关系服务的组件的方框图；图9为示出根据本发明一个实施例的附属关系服务的动作的步骤的流程图；图10为示出根据本发明一个实施例的用于创建和更新功能附属关系模型的管理员的任务的流程11为示出根据本发明一个实施例在一个计算机系统上通过安装或删除硬件/软件组件而更新结构附属关系模型的步骤的流程图；图12为示出根据本发明一个实施例负责操作模型的计算的系统的步骤的流程图；图13为示出根据本发明一个实施例检索位于一个指定的主机上的服务的直接先前者的步骤的流程图；图14为示出根据本发明一个实施例递归地检索位于一个指定主机上的服务的先前者的步骤的流程图；图15为示出根据本发明一个实施例检索位于一个指定主机上的一个服务的直接先前者的步骤的流程图；图16为示出根据本发明一个实施例用于递归地检索位于一个指定主机上的一个服务的附属者的步骤的流程图；以及图17为示出根据本发明一个实施例附属关系服务应用程序编程接口的例子。
具体实施例方式
下面将在一个示意的分布式计算环境的情况下描述本发明。但是，应当知道本发明不限于这种特定计算环境。而是，本发明可以更加一般地应用于任何计算环境，其中希望管理(例如，计算、查询，等等)附属关系以使得问题的确定、隔离和解决更加容易。
如在此所用，根据该讨论的上下文，术语“系统”可以被用于表示一个计算机系统、软件系统和/或它们的一些组合。术语“系统”也可以被用于表示一个应用程序和/或服务。因此，短语“多系统”是指几个系统的一个集合。并且术语“组件”可以指一个系统本身，或者一个系统的一个或多个部分。
如上文所述，服务附属关系在当今的系统中没有被明确给出，因此使得问题的确定、隔离和解决的任务特别困难。解决该问题需要确定和计算在不同系统和域上的服务和应用程序之间的附属关系，即，建立一个“全局”服务附属关系模型并且使得系统管理员从上到下以及相反地导航通过所获得的直接图形。对于这种机制的需求在如下两种情况中被更好地示出。
第一情况关于管理来自外部的服务，一般由互联网或应用程序服务提供者(ISP/ASP)所提供。来自外部的服务导致分层的服务层级，其中例如，一个ASP服务基于由ISP所提供的IP-连通性(网际协议-连通性)，其接着依赖于电信公司的广域网。在每个层面中，一个服务被通过服务接入点(SAP)而访问。一个SAP限定不同组织域之间的边界，并且是服务层协议(SLA)被定义和观察的位置。通常，这是通过监控由该提供者所公开的一组特定参数在每个层面实现的。在上层服务中的停机或性能下降的情况中，需要从上到下通过该服务层级，以识别该问题的根本原因。
第二种情况关于日常的维护任务，其不能够“快速”地完成，因此影响服务和它们的客户例如，电子邮件随着它们的操作系统的新发行版而获得更新，网络设备随着新的固件版本等等而被交换或更新。在所有情况中，对于网络和服务管理员来说重要的是预先确定有多少和更加具体的是哪个服务和用户受到该维护的影响。我们把这种任务称为影响分析。
上述任务被如下原因而进一步加重。
附属关系模型提供一个直接的方法来识别一个被观察的问题的可能的根本原因。如果用于一个系统的附属关系图是已知的，则把该图从一个被修复的服务导航到其先前者(共同位于相同的主机上或位于不同的系统上)将揭示哪一个实体可能发生故障。向着其根节点遍历该图(即，在向上方向上)产生一个服务的附属者，即，如果该服务受到暂停则该组件可能出现故障。需要解决如下问题。
(a)缩放性在多个所涉及的系统之间的附属关系的数目可以被计算，但是可能变得非常大。从工程的观点来看，通常不希望(并且有时是不可能的)在单个位置存储一个完全、例示的附属关系模型。因此由于所涉及的附属关系的数目和动态性，例如把一个例示网络图保存在平台数据库中这样的用于网络管理平台中的传统机制不能够应用于附属关系。
这两个事实导致不能够按照“网络-管理-方式”方法来调度应用程序、服务和中间件附属关系模型。作为一个例子，服务外部来源的典型数据中心容纳大量(几千个)的网络应用程序和数据库服务器。这意味着例如网络应用程序服务和数据库服务器的大量同时运行的程序实例。能够构造一个附属关系模型的系统应当提供通过在管理过程中所涉及的系统上分布附属关系的存储和计算而允许适当的可缩放性。
(b)动态所容纳的应用程序(在网络应用程序服务器中运行)具有非常短的操作周期，通常为几秒。在接收一个请求之后，一个网络应用程序的商务逻辑(通常被应用为一个或多个Java服务小程序(Servlets))获得该应用程序服务器的服务小程序引擎的例示，执行其任务并且然后被该服务小程序引擎所删除。结果，用于计算在这些动态实体中的附属关系的系统应当在该数据的精度和为检索该数据而产生的工作负担之间权衡。
(c)相异性相异性来自三个不同的方面。首先，被提供到客户的服务在较大程度上是不同的。其次，在把一个服务提供给一个客户中可能涉及各种提供者。最后，实现一个服务的产品可能来源于各种销售商。用于计算附属关系的系统应当提供独立于特定操作系统、网络协议、软件产品以及提供到一个客户的服务的语言。
(d)附属关系数据的手动维护一个附属关系模型的获取(甚至局限于单个主机系统)是对通常不提供适当的管理工具的当今系统的一个挑战。应当知道，该术语“工具”是指通过一个明确定义(有时甚至是标准化的)接口(管理)资源公开管理特性和能力的程序代码。另外，即使可以从被管理的资源获得，但是附属关系数据不被当今的管理系统所开发利用。而是，该附属关系信息不但必须被手动地输入到一个特定的管理组件，而且还采用一个所有者格式。因此，该附属关系信息是不完整的、过时的(因为容易出现错误的手动处理)、并且有时甚至是不一致的，因为不同的操作员独立地输入该规则，并且没有方法来以自动的方式检查该规则基础的一致性。
(e)用于附属关系的分类法附属关系的概念非常粗略并且需要被精确定义，以便于使用。用于该分类的例子是附属关系的强度(表示近似性和如果其先前者发生故障则一个组件受到影响的程度、关键程度(该附属关系对于一个企业的目标和政策的重要性)、形式化程度(即，获得该附属关系的难易程度)等等。需要把属性添加到附属关系，使得它们可以被更加适当地考核；并且相应地，需要把这些属性反映在附属关系表现中。
(f)问题确定特征希望获得用于把存储在每个系统中的本地附属关系组合到一个统一的附属关系模型中的本地附属关系图的进一步的设施。另外，这些设施应当提供一个API(应用程序编程接口)使得管理应用程序对于附属关系模型发出查询。这些查询将被允许检索直接基于或者递归地确定包括副先前者的整个节点组的特定服务。由管理应用程序所接收节点列表使得它执行特定的问题确定例程，以检查这些服务是否可选。
上述讨论示出建立一个服务操作周期的三个不同阶段之间的映射是重要的(a)一个(概括)服务被提供给客户，例如，“网络主机服务”、“被管理的存储器”、“IP连通性”、“被管理的数据库”，等等；(b)一个服务的应用，即，被用于提供该服务的产品，例如，“IBM通用数据库版本7.1”、“WebSphere Application Server version 3.2”；以及(c)一个实现的运行实例，即，该处理或任务，例如，“db2 daemon”，“nfs daemon”。
尽管独立地在每个阶段获得信息的任务是可行的，但是把三个阶段组合到一个统一的附属关系模型受到挑战，并且还没有在以前的工作中实现。另外，在此需要建立一个可有效计算的附属关系模型，其解决底层环境的缩放性、动态性和互异性的要求并且消除人的相互作用和附属关系数据的需求。
如在附图的上下文中所示，本发明针对于这些和其他需求。也就是说，本发明的特征是为一个管理应用程序计算分布式系统的组件之间的运行时间附属关系(“附属关系模型”)。本发明提供一种普通和统一的方法用于从提供检索各个计算机系统的配置信息的机制或者提供这种采用机器可读格式的数据的计算机系统检索附属关系信息。
上述系统的一个优点是可以从这些计算机系统获得大量应用程序/服务管理信息，而不必对各个应用程序/服务提供检测仪器。但是，如果这种应用程序/服务的检测仪器可用，则它可以由本发明所使用。
本发明所述的系统的执行可以由一个特定(管理)应用程序(例如影响分析器、根本原因分析器)、一个网络管理平台(例如，IBM/TivollNetView、HP Open View或Aprisma Spectrum)或者基于传统网络管理系统和平台的管理应用程序。
本发明提供用于如下操作的特征(a)观察被订购服务的性能下降和停止；(b)通过从上到下遍历该附属关系模型的不同层面而跟踪该问题的根本原因(由于各种服务可能是来自其他服务提供者之外的，一个附属关系模型的(递归)遍历通过域边界)；以及(c)通过把该附属关系模型从下到上导航而分析一个服务暂停的影响。
本发明组合可以在一个应用程序或服务的操作周期过程中获得的附属关系信息(即，从该设计到一个应用程序/服务的调度、安装和运行时间阶段)。该信息被保持在如下模型中(a)功能模型在一个优选实施例中，该功能模型定义不同普通服务(数据库服务、名服务、网络应用程序服务、连接服务，等等)之间的附属关系。该功能模型不描述在一个特定服务中的客户机/服务器关系。另外，该功能方框不考虑到哪一个具体的产品已经被选择以实现该服务，也没有考虑到它们的实际配置。该功能模型建立约束其他模型(在下文中所述)的主要限制，即，进一步的模型可以对于具体系统下部结构改进在该功能模型中定义的附属关系，但是不应当导入在服务类别之间的新的附属关系。该模型非常紧凑和普通，并且最好存储在该管理系统中。
(b)结构模型在一个优选实施例中，该结构模型包括实现在该功能模型中定义的服务的软件组件的详细描述。该结构模型提供在安装/调度阶段捕获的具体细节，并且通过考虑到具体系统的软件目录而补充该功能模型。该结构模型提供关于哪一个服务被安装和配置在一个特定的系统上，以及对于每个服务判断该系统是否以一个客户机或服务器角色而工作的信息。潜在的大量系统和服务使得从一个远程位置跟踪这些附属关系变得困难。因此，希望把该模型存储在接近于所管理的资源或在所管理的资源上。
(c)操作模型在一个优选实施例中，当建立获得例示并且捆绑在服务和应用程序之间的软件包时，创建附属关系的操作模型。该模型和大量所步及的系统的的高度动态性对可以例示和存储该完整模型的程度施加限制。定义和存储这样一个模型是不现实的，并且该模型必须被动态和逐步地计算。因此，该操作模型被“根据要求”计算，并且依赖于该功能和结构模型。
如所期望的那样，在大规模的分布式系统中，附属关系的量和它们的动态性极高。本发明的特征使得它们对该分布式系统(在资源和带宽使用方面)的影响尽可能地小，并且保留尽可能多的可以影响对用户的性能的配置选项。用于这种情况的例子是用于检索一个更新附属关系模型的时间间隔、其附属关系应当被跟踪的系统的范围、附属关系模型的深度(仅仅受到立即影响的服务对比用于给定服务的传递关闭对比整个服务等级)。
本发明最好利用附属关系信息的如下特性(a)在不同服务之间的附属关系被分层。另外，它们的附属图是定向和非循环的。后者也反映对IP基网络服务的体验，例如DNS(域名系统)、NFS(网络文件系统)、DFS(分布式文件系统)、NIS(网络信息系统)等等，但是这些可以是相互附属关系可能出现在一些系统中的情况。用于这种相互附属关系的异常例子是安装该文件系统的DNS服务器，其中它的DNS配置被通过NFS从一个远程系统存储。尽管这样一个配置在技术上是可行的，但是它反映了在该系统设计中的缺陷，因为这导致一个不稳定的系统，其引导可能是不确定的，因此应当避免。发现循环附属关系的附属关系检查应用程序应当向管理员发出一个警告。
(b)每个附属关系可以在一个客户/提供者域边界上可见并且可以通过SLA明确。由此得到可观察的附属关系数目是无限的。
(c)附属关系模型允许附属关系链的从上到下遍历。
(d)在不同系统之间的(“系统间”)附属关系不被理解为在相同服务的客户机和服务器部分之间的附属关系。服务A的客户机不可以把请求发送到提供不同服务B的服务器。
本发明的一个目的是主要从少数几个公知/明确定义的位置(例如，系统存储库)检索信息，以从具体服务/应用程序检测仪器获得最大程度的独立性。为了实现该目的，本发明定义一种最小和足量的通常可用的附属关系信息。
本发明包括用于永久存储附属关系模型的设施或者把这保留给管理应用程序或者使用本发明的另一个服务的判断。
本发明具有一个历史概念，以检测和确定在附属关系模型中的改变。在这种情况中，本发明提供一个出版/订购接口，用于通知以前已经登记的软件组件，用于在该附属关系模型中改变。本发明的另一个可能使用是把在附属关系模型的改变检测保留在该附属关系模型中，直到一个管理应用程序(或者一个改变管理服务)的判断向本发明发出定期呼叫，以确定在该附属关系模型中是否出现改变。
给出根据本发明做出的上述实现和与本发明相关的一般特征，下文的详细描述将提供用于执行在图1至17的上下文中的这种实现和特征的技术的示意性说明。
首先参见图1，一个方框图示出采用客户机-服务器应用程序构架形式的电子商务系统的一个例子，其中本发明的特征可以相互作用以产生信息。图1的构架将在下文中详细描述，以说明在没有本发明的技术的情况下，这样一个构架如何能够处理一个交易。
如图所示，一个客户机系统105被用于发出一个请求，例如，通过键盘发出。但是，请求可以由任何常规的装置来发出，例如通过敲击鼠标、语音命令、条码扫描等等。该客户机系统105的例子是个人计算机、公用电话亭、数据输入终端、扫描仪、电话、寻呼机、手持或腕带设备、无线设备、个人数字助理、具有网络功能的手表，等等。
该请求局部地作用在该请求被形成和通过网络110转发到网络应用程序服务器120并且通过一个或多个网络接入115设备的位置处。网络110和通信协议的一个例子是架在局域网(LAN)上的TCP/IP(传输控制协议/网际协议)传输上的基于套接字的通信，其中该局域网由例如路由器和交换机这样的网络接入115设备连接到包含许多交换位置的广域网(WAN)，该交换位置创建到达一个服务提供者以及最终到达一个网络应用程序服务器120的虚拟电路。网络应用程序服务器120的例子是运行守备来自客户机的请求并且在适当时把该请求发送到适当的后端数据库服务器的高端个人计算机、基于RISC的PowerPC、基于UNIX的工作站、微型计算机或者大型计算机。
为了说明的目的，在一个(运行于该客户机系统105中的)网络浏览器中启动一个电子商务交易，以使用现在将描述的互联网购买一个商品。应当知道，本发明的技术可以用于任何形式的交易。网络应用程序服务器的例子包括但不限于可以从IBM公司获得的商标为WEBSPHERE的服务器、从BEA系统公司获得的商标为WEBLOGIC的服务器或从Lotus公司获得的商标为LOTUS DOMINO SERVER的服务器。
在该示例的交易中，网络应用程序服务器120的商业逻辑处理到来的请求并且提供该客户机系统105的认证和/或识别。一旦由该网络应用程序服务器120所实现的商业逻辑确定该客户机可以进行购买，则它通过网络123把另一个请求传送到数据库服务器125以减小存储总量。该数据库服务器125处理该请求，访问它的数据库130，并且准备一个照到达该网络应用程序服务器120的响应。数据服务器的例子包括但不限于由微软公司所销售的商标为SQL/SERVER或TRANSACTIONSERVER的服务器或者由IBM公司所销售的商标为DB2 UNIVERSALDATABASE SERVER的服务器。
网络应用程序服务器120接收来自数据库服务器125的响应，并且通过网络110把它返回到客户机系统105。该客户机系统105然后处理该响应，以把它格式化为用于显示和提供该响应用于由交易的发起者浏览。
管理员100观察处理商业交易的位于服务提供者的位置处的各种软件和硬件组件，以确定它们是否正常工作。在数据库130出现停机135的情况中，例如一个恶化的表空间或者数据库运行时间系统的故障，管理员100的任务是确定停机的原因，解决该问题并且确认是否所有系统再次正常工作。应当知道本发明用于任何形式的停机或的性能下降。
管理员100直接或者通过处理由一个明确定义的管理接口处的软件和硬件组件所公开的管理信息(例如状态和健康数据)的管理系统与软件和硬件组件交互作用。在任何一种情况中，应当注意该硬件和软件组件被管理员所认为是一个孤立的资源并且不作为服务特定的商业目的的整个系统的一部分。
特别地，在一个组件中出现错误可能不被注意到，因为管理员由于没有连续监控而不能够注意到该错误。另外，在没有本发明的技术的情况下，管理员不能够以直接的方式获得在各个组件之间的相互附属关系的明确信息。因此，在一个不被连续监控的组件中的一个错误可能不被注意直到该故障扩展到被监控的组件时为止。
在上述数据库停机135的情况中，如果网络应用程序服务器120，不再正常工作(例如，在该网络应用程序服务器上的负载大大增加，因为它不断地尝试与数据库服务器125相连接，并且不能够完成由客户机系统105所发送的请求)，一个管理员可能最终仅仅注意到该停机。因此，该管理员100将首先检测该网络应用程序服务器120，然后决定是否存在网络123连通性问题，最后确认如果该数据库服务器125遇到可能来自数据库130中的内部错误的困难。
上述客户机-服务器应用程序构架可以被作为的由IBM公司称为“自治”的的紧急计算环境的先驱的。在P.Horn在2001年10月所发表的“Autonomic ComputingIBM′s PerspectiVe on the State of InformationTechnology，”IBM研究，的内容被包含于此以供参考，其中定义了作为具有最少的人的干预的自我管理计算系统的全面和完整的方法的自治计算方法。该术语来自人体的自治神经系统，其控制关键功能，而不意识到或涉及于其中。更加具体来说，自治计算方法的一个目的是执行通常由管理员100所执行的一些或所有任务。其目的如下。
随着计算技术的发展，重叠连接、附属关系和相互作用应用程序要求比任何人可以做到的更快的管理决定和响应。查明故障的根本原因变得更加困难，并且查找增加系统效率的方法产生比任何人可以期望解决的变量更多的变量。识别和跟踪一个自治计算环境的不同系统之间的附属关系可以用如下方法来特征化。由于一个系统可以存在于许多级别上，一个自治系统需要其组件、当前状态、最终容量以及与其他自我管理的系统的所有连接的详细知识。本领域的普通技术人员应当认识到本发明可以在一种自治的计算环境中执行。
参见图2A，一个方框图示出用于提供根据本发明一个实施例的附属关系管理的系统。更加具体来说，图2A示出解决上述问题的一种附属关系管理系统。该系统包括四个层级(应用层200、服务层205、中间件层210和资源层215)以及一个管理员图形用户界面285，管理员通过该界面与该系统相互作用。
最低层是资源层215。该资源层215包括被管理的资源220、资源附属关系存储库225和存储库代理230。被管理的资源220的例子包括但不限于物理和逻辑硬件组件(前者的例子是硬盘、随机存取存储器、中央处理单元、网络适配器、信道控制器，等等；后者的例子是磁盘分区、文件系统，等等)和软件组件(例如操作系统、如打印假脱机系统或名服务这样的系统服务、以及终端用户应用程序)。
该资源附属关系存储库225包含每个被管理的资源220的硬件和软件组件的目录，以及关于每个资源的附属关系信息(即，在一个被管理资源220中的组件之间的附属关系)。该资源附属关系存储库225可以与每个被管理的资源220相同位置，或者驻留在一个集中的位置处。该资源附属关系存储库225可以被通过一个存储库代理230而查询、更新和修改，其使得该资源附属关系存储库225的信息可以由该系统的其他组件所获得。
该中间件层210包括一个管理通信下部结构235，例如该系统的不同组件之间交换(管理)信息的协议和对象要求代理程序。
该服务层205包括各种管理服务250，例如、政策、事件和目录，其可以由各种管理应用程序所使用。一个特别重要的服务是附属关系服务245，其从被管理的资源220以及从存储库代理230提取信息，并且处理该信息，以建立整个资源环境的一个端到端附属关系模型。根据该附属关系服务245的需要(例如，为了更快检索的缓存)，该模型(或者它的一部分)被存储在该端到端附属关系存储库240中。请注意，该附属关系服务245仅仅是在所述系统中的组件，其直接与该端到端附属关系存储库240相互作用。
该应用层200包括各种管理应用程序，其使用普通管理服务250和/或该附属关系服务245。这种管理应用程序的例子包括但不限于故障管理器260、拓扑产生器265、影响分析器270、影响模拟器275和根本原因分析器280。
该根本原因分析器280根据从受到停机影响的一个组件向着它的先前者方向遍历，而确定停机的根本原因(即，最初导致停机的组件)。该根本原因分析器可以采用在上述参考文献和同时提交的由律师卷号YOR920020096US1所表示的，名称为“Methods And Apparatus ForRoot Cause Identification and Problem Determination in DistributedSystems”的美国专利申请中公开的技术。但是也可以采用其他根本原因分析技术。
该影响分析器270根据从受到停机的一个组件向其附属者的方向遍历该附属关系模型(由附属关系服务245所提供)而确定停机的影响(即，可能受到该停机的影响的组件)。该附属关系模型(附属关系服务245)。该影响分析器可以采用在上述参考和同时由律师卷号SOM920020004US1所表示的，名称为“Methods And Apparatus ForImpact Analysis and Problem Determination”的美国专利申请所公开的技术。但是也可以采用其他影响分析技术。
该影响模拟器275根据影响分析器270允许一个管理员100通过模拟一个特定组件的停机对整个系统的影响而执行“假设”分析。该影响模拟器可以采用在上述参考文献和同时提交的由律师卷号SOM920020005US1表示的，名称为“Methods And Apparatus ForDependency-based Impact Simulation and Vulnerability Analysis”的美国专利申请所公开的技术。但是，也可以采用其他影响模拟技术。
故障管理器260对已经由该根本原因分析器280或影响分析器270所识别作为一个故障的候选者的组件执行适当的“健康检查”或测试。也就是说，该故障管理器可以在该根本原因分析器280或影响分析器270的方向上执行这种测试(即，作为用于这些模型的一个接口)，以及报告回结果。但是，根本原因分析器280或影响分析器270可以执行独立于故障管理器的自身测试。
应当知道该故障管理器最好包括允许确定被测试的组件是否工作正常的对应用程序特定或对资源特定的工具的集合。因此，在利用相关的工具测试该组件时，故障管理员可以返回一条消息，表示该组件是否“工作”或“不工作”。这些工具可以是自动和/或手动的。通过一个自动的例子，一个所谓的“ping”程序检查网络的连通性。如果目标的远程系统应答一个ping，则它是在线的，并且其网络协议栈(以及所有下层硬件，例如，网络适配器、电缆、中间网络组件，等等)正常工作。如果该远程系统不应答，则得知至少存在一些错误，并且可以采用另一组工具来确定该问题。因此，故障管理器可以采用ping程序，以及测试该分布式计算环境的组件的任何数目和类型的其他工具(例如，心跳检测、状态指示，等等)。
拓扑产生器265建立一个分布式系统的整体拓扑(的一个子集)，包括大量高度动态的组件，例如网络应用程序、数据库实例和交易。使用拓扑产生器265的一个例子是显示在完成一个特定客户机系统105的请求中所涉及的一个分布式系统的组件。根据拓扑产生器265的需要(例如，用于更快的检索的缓存)，该附属关系模型(或者其一部分)被存储在该拓扑数据库255中。请注意，该拓扑产生器265是在直接与拓扑数据库255交互作用的所述系统中的唯一组件。该拓扑产生器265可以利用在上述参考文献和同时提交的由律师卷号SOM920020003US1所表示的，名称为“Methods And Apparatus For Topology Discovery andRepresentation of Distributed Applications and Services”的美国专利所述的技术。但是，也可以采用其他拓扑产生技术。
现在参见图2B，一个方框图示出适用于实现提供如图所示在此详细描述的附属关系管理的一个系统的各种功能组件/模型的计算机系统的一般化硬件构架。应当知道，该附属关系管理系统的各个组件，即，与该图形用户界面285、应用层200、服务层205和中间件层210(图2A)相关的组件，可以在具有如图2B中所示的构架的一个或多个计算机系统上实现。图2A中所示的其他组件，例如，与资源层215相关的组件也可以在类似的计算机系统上实现。
如图所示，该计算机系统可以根据一个处理器90、存储器292和I/O设备294而实现。应当知道在此所用的术语“处理器”用于包括任何处理设备，例如，包括CPU(中央处理单元)和/或其他处理电路的设备。在此所用的术语“存储器”用于包括与处理器或CPU相关的存储器，例如，RAM、ROM、固定存储设备(例如，硬盘驱动器)、可移动存储设备(例如，磁盘)、快速存储器，等等。另外，在此所用的术语“输入/输出设备”或“I/O设备”包括例如用于把数据输入到该处理单元的一个或多个输入设备(例如，键盘)，和/或用于显示与该处理单元相关的结果的一个或多个输出设备(例如，CRT显示器和/或打印机)。
还应当知道，术语“处理器”可以表示一个以上的处理设备，并且与一个处理设备相关的各种元件可以由其他处理设备所共享。
相应地，包括用于执行本发明的方法的指令或代码的软件组件，如在此所述，可以存储在一个或多个相关的存储设备中(例如，ROM、固定或可移动存储器)以及当准备使用时被部分或全部装载(例如，装载在RAM中)，并且由一个CPU所执行。
现在参见图3，一个方框图示出根据本发明一个实施例的服务的功能附属关系模型。更加具体来说，图3示出在例如图1中所示的电子商务系统中的各个组件之间的一个功能应用程序附属关系图。该功能附属关系模型表示分布式系统和它们的附属关系的功能组件。因此，该模型确定从商业的角度被认为是基本的一般服务之间的附属关系。这意味着该功能模型与在一个商业服务中出现的附属关系无关。这种分解在被用于实现该服务的特定产品的范围中是有意义的，并且将在下文参见图4更加详细地讨论。
在组件之间的附属关系由箭头所表示。一个箭头总是从附属者指向其先前者。功能组件是一个服务提供者需要安排以向一个客户提供端到端服务的(子)服务，后者被定义在服务级协议中。该功能模型针对于端到端服务的设计，并且从一个端到端服务的技术实现的具体细节中提炼出来，例如用于提供服务的产品、它们的位置(本地或远程系统)、提供者的域(即，该提供者自身是否把它的一些服务对客户透明地向外提供到另一个服务提供者)，等等。
如图所示，电子商务应用程序300服务基于包含商业逻辑的一个网络应用程序服务305。为了正常工作，该网络应用程序服务305另外需要两个服务。该电子商务网址的静态内容由网络服务310所提供，而后端数据库服务330存储被提供到一个客户的电子商务应用程序300的动态内容(例如，产品描述、用户和制造商数据、购物车、用户概况和喜好、支付信息，等等)。该网络服务310自身基于两个服务，即，用于把主机名映射到IP地址的名服务315和用于网络连通性的IP服务320。
该附属关系是传递性的，即，一个给定组件的附属者需要除了该组件本身之外还需要该组件的先前者。从而，除了IP服务320和数据库服务330之外，所有所示的服务需要一个操作系统(OS)服务的存在。为了简化，一个OS 325与硬件组件之间的附属关系没有被示出，但是它们被显示在一个功能模型中。
现在参见图4，一个方框图示出根据本发明一个实施例的服务的结构附属关系模型。更加具体来说，图4示出在例如图1中所示的一个电子商务系统中的各种组件之间的结构应用程序的附属关系图。
该结构附属关系模型按照如下方式在该功能模型(图3)中扩展。该结构附属关系模型关于一个商业服务的实现，并且针对于具体的产品和它们的逻辑(方框、组件)和物理(文件、共享库)构架。该结构附属关系模型获得软件组件的详细描述，即，该系统目录，其被记录在各种系统存储库中，或者记录在明确定义的位置处，例如，一个被管理资源220的配置文件。
请注意，尽管该结构模型处理单个系统的组件，但是可以保持由其他系统对服务和应用程序的参考，因为位于该系统上的配置文件可以包含该信息。系统存储库的例子包括但不限于IBM AIX对象数据管理器(ODM)、Linux红帽包管理器(RPM)或者微软视窗注册程序。与软件组件相关的信息一般被在软件包的安装和调度的过程中被捕获。另外，该结构模型包括如箭头所示在各种系统组件之间的附属关系。为了清楚起见，在图4中，该商业服务的名称被写出而没有加引号，并且该结构模型的单元名称被写出而没有加引号。
具有完全合格的域名wslab8.watson.ibm.com的系统400包括如下组件电子商务应用程序(在该功能方框中定义的商业服务)，其被应用为前台服务小程序410，并且后者包括该应用程序。该网络应用程序服务由IBM WebSphere版本3.5 415所实现，而该网络服务由IBM HTTP Server版本1.3.6 420所实现。该IP服务由默认IP协议栈430所实现，该操作系统(OS)是Win(dows)NT版本4 425。
具有完全合格的域名rslab2.watson.ibm.com的系统405包括如下组件(IBM)DB2通用数据库(UDB)版本5.2 435所实现的数据库服务、以及一种操作系统，在此为(IBM)先进交互作用执行者(AIX)版本4.3.3 440。
现在参见图5，一个方框图示出由根据本发明一个实施例的功能、结构和操作附属关系模型所针对的服务操作周期。更加具体来说，图5示出在上述的一个功能模型500和结构模型510之间的关系，并且引入第三附属关系模型，一个操作模型520。这三个模型使得本发明在它们的整个操作周期过程中跟踪该服务，即，从设计阶段到安装和调度阶段，到操作或运行阶段。
如上文所示，该功能模型500涉及商业服务的设计，因此在一个商业系统的设计时间内被捕获。一旦由该功能模型500所描述的系统变为例示或被调度(步骤505)，则建立该结构模型510。当该结构模型510的各个组件变为例示时以及当建立它们之间的运行时间捆绑时，创建该操作模型520(步骤515)。该操作模型表示在运行时间中上述模型的特性。现在将描述说明上述概念的几种情况。
该网络应用程序服务305由IBM WebSphere 415来实现；后者的一个或多个实例被称为websphere-daemon 545。在此，网络(或WWW)服务310由两个产品来实现，即，Apache 1.3.4 525和Lotus Domino 530。这些产品的运行实例可以被表示为http daemons″httpd″550。该数据库服务330由两个产品来实现，即，Oracle v7 535和DB2 UDB 435；但是，没有Oracle v7 535的实例是活跃的，因为在该操作模型520中没有看到服务器处理。相反，DB2 UDB 435的四个实例被运行，如可以从该操作模型520中的四个DB2 daemons″db2d″555看出。该名服务315可以由BIND版本5.6 540来实现；该BIND的运行实例可以被观察为在该操作模型520中的“命名的”560。
请注意该附属关系被从该功能模型传递到结构和操作模型。这是必要的，因为不可能从一个运行中的应用程序实例确定哪一个其他应用程序实例需要正常工作。
由于一些应用程序实例的寿命较短，该操作模型520是高度动态的，并且潜力非常大。与该功能和结构附属关系模型相反，该操作模型520不被存储在一个存储库或数据库中，而是根据要求和需要的程度而被计算。
现在参见图6，一个方框图示出根据本发明一个实施例在功能、结构和操作附属关系模型之间的关系。更加具体来说，图6示出用于三个附属关系模型的数据模板和用于通过一个例子把这些模型联系在一起的具体细节。该例子详细示出用于描述在其操作周期过程中的名服务的模板和其相关数值。
用于功能模型500的功能模板605包含该“主机名”(容纳该服务的计算机系统的唯一名称)，“服务名”(该服务的名称)以及“组件类型”(该服务扮演的角色，即，客户机或服务器)。利用该信息，一个服务可以被在一个分布式环境中唯一地识别。但是，可以添加包含描述数据(例如该服务的目的的描述，客户对该服务的订购，等等)的其他字段可以被添加，而不脱离本发明的精神。最后，“先前者”字段包括服务，该服务需要正常工作。
用于结构模型510的结构模板610包含该功能模板605的所有字段，其允许把该功能模板605与结构模板610相连接，以从功能模型500导航到结构模型510，反之亦然。另外，该结构模板610包括“组件名”(产品组件的名称)、“标识符”(用于识别该组件的全局唯一的名称)、“版本”、“发行版”和“修订”(例如，维护或者修补/修理级别)号、“安装状态”(表示该组件是否已经被成功和完全安装)和“过程名”(表示在运行时间中该产品组件的处理名称)。另外，该“先前者”字段列出组件，该组件需要被操作。
用于该操作模型520的操作模板615包含字段“主机名”(包含该服务的计算机系统的唯一名称)和过程名(表示在运行时间中的产品组件的过程名称)。这两个字段把结构模板610与操作模板615相联系，以从该结构模型510导航到操作模型，反之亦然。另外，该操作模板615包括“操作状态”(该过程的操作状态，即，运行、中断、僵进程，等等)、“端口号”(由一个应用程序可以连接到该过程的TCP/UDP端口的号码)以及“实例ID”(区别在一个计算机系统中的各种应用程序实例)。
三个附属关系模型被在不同的位置存储和计算以获得最大程度的有效性。该功能模型500被收集和存储在该管理系统620中，即，控制的中心点，管理员100通过该中心点与该分布式环境进行交互作用。对于该选择的一些原因如下。如图3和图5中所示，该功能模型500相当紧凑，因为可能的商业服务的量是有限的。另外，该功能模型不受到过度频繁地改变。当一个商业服务被提供到一个客户并且保持不变直到该服务提供周期结束时为止时，该功能模型被确定。由于该管理员100负责设置和更新功能模型500，因此把它保持接近于该管理系统620是一个自然的选择。
如图4和图5中所示，相反该结构模型510捕获软件组件的详细描述，即，通常被记录在各种系统的存储库或者在一个明确定义的位置处的系统目录，例如，被管理资源220的配置文件。相反，它的内容较大(一个系统存储库的内容通常在几百K字节到几兆字节)并且还受到频繁的改变。因此，把一个系统的结构模型510保持在被管理的资源220处，其本身消除用于更新该模型的通信开销和对大存储量的需求，如果所有被管理的资源(220)的结构模型510被存储在一个集中的位置，则存在这些需求。
操作模型520已经被在图5中描述为非常动态，并且还特别大，因为它覆盖存在于该分布式环境的计算机系统上的每个应用程序的多个潜在实例以及它们之间的附属关系。给定这样的事实，即，互联网/应用程序/存储服务提供者和外部来源的当前数据中心由几千个计算机系统所构成，每个计算机系统接近于容纳100个应用程序和系统服务，包括所有当前例示的应用程序和它们的附属关系的一个操作模型可能是不现实的。因此，一个实践方法是根据需要计算该操作模型的相关部分(步骤625)。这是该附属关系服务245的目的，其功能在图7中详细描述。
现在参见图7，一个方框图示出计算在根据本发明一个实施例的端到端附属关系中所涉及的组件。更加具体来说，图7示出用于查询和计算端到端附属关系的各种组件。假设被管理的资源220能够提供它们的系统目录、配置文件和它们的各种附属关系的XML(可扩展的标识语言)描述。但是，应当知道，根据本发明可以使用任何数据描述格式。关于如何获得该信息的具体细节如下。
一种直接的方法是在该系统和其应用程序和服务中提供适当的仪器。该信息用直接的(flat)XML文件740来描述，并且可以通过一个网络服务器725由该系统的其他组件所获得。
另外，该附属关系服务245利用存储在系统存储库745中的信息，产生适当的服务附属关系信息。该信息可以通过一个网络服务器730由该系统的其他组件所获得。
第三，该被管理的资源220通过一个仪器代理公开它的信息，该仪器代理被称为CIM提供者750，其与由分布式管理特别工作组(DMTF)所提议的CIM对象管理员(CIMOM)735交互作用。该CIMOM然后向感兴趣的组件公开必要的信息。
在图7的中央，示出作为该服务层205的一部分的各种管理服务。其中为名服务700、商人服务710、事件服务715和附属关系服务245。该附属关系服务245由管理员100的查询通过其管理系统或者任何位于该应用层200中的使用一种通信协议(例如，Java远程方法调用(RMI))管理应用程序所触发，执行处理，并且把结果返回到该管理员100。该附属关系服务245的主要任务如下(a)与该管理系统或者位于该应用层200中的任何管理应用程序交互作用。该管理系统把查询发送到该附属关系服务(245)的应用程序编程接口(API)。
(b)在接收一个服务的标识符之后，公开“向下钻(drill-down)”方法，返回(i)其直接先前者的描述，即，在表示该服务的节点之下的第一级，或者(ii)在表示该服务的节点之下的整个子图，(iii)该附属关系图的任意子集(在给定节点之下的层m至n)。
(c)利用相同设施提供“向上钻”方法，触发该服务的附属者。
(d)提供用于收集和过滤被管理对象的种类和属性的信息的附加方法。
(e)通过http(超文本传输协议)发出查询而从被管理的资源获得附属关系信息并且对它应用过滤规则(如管理员100所指定)，从该被管理的资源220获得该附属关系信息。
(f)把该信息组合到被发送回该管理系统作为XML文档的一个数据结构。
如上文所示，由于其完全的分布式特性，本发明的目的使得在每个所涉及系统上的负担尽可能低。本发明使得该管理系统与被管理的资源220分离，并且把消耗时间的过滤和接合操作包含到该附属关系服务245中，其可以被在各种系统上复制。因此，可以对查询操作获得最大的平行度，因为可以通过该管理系统灵活地完成该附属关系服务245的实例的选择。
另一个重要优点是(非常大和高度动态)的操作模型520不被存储在一个特定的位置，而是按照逐步的方式根据需要而计算。该结构模型510的不同部分被存储在该被管理的资源220处，因此该管理系统总是接收最近的信息，但是仍然自由地根据完善的缓存策略而存储它。
现在参见图8，一个方框图示出根据本发明一个实施例的附属关系服务的组件。更加具体来说，图8示出实现该附属关系服务245的组件。如图所示，一个信息提供者810与该应用层200的管理应用程序交互作用。该信息提供者810通过Java RMI接收查询840，并且把其结果作为XML文档835发送回。查询840与基本信息相关(例如服务和组件的描述或者特定属性的数值的检索)或者处理更加复杂的问题(例如在附属关系模型中的向下钻或向上钻操作)。
资源代理800负责通过与资源网络服务器725相接而获得被管理的资源XML描述830。该资源代理800还通过把一个查询经http发送到(步骤827)该资源网络服务器725而实现该操作。在接收XML描述830之后，该资源代理800对它们进行分析，并且对它们应用查询表达(例如选择和过滤规则)，以及把该结果转发到一个查询解决者805。
该查询解决者805的任务是维护一个图，以对一个给定的主机名确定哪一个资源代理800能够服务该请求并且把该请求转发到适当的资源代理800。
单元URI分解器815负责对给定的主机名构造统一资源标识符(URI)并且把该结果发送回调用者，其可以是信息提供者810或者查询解决者805。
XML子类分解器820是负责根据在XML方案825中定义的类型系统而确定特定类型的单元的帮助方框。其例子是查询在具有类型“服务”(例如网络应用程序服务、网络服务或名服务)、具有类型“主机”(被确定服务和附属关系的主机)或者具有类型“附属关系”的一个或多个XML文档中的所有单元。
现在参见图9，一个流程图示出根据本发明一个实施例用于调用一个附属关系服务(例如，附属关系服务245)并且收集其结果的动作的步骤。该方法由一个管理员100或者作为该应用层200的一部分的管理应用程序所启动，如图2A中所示。
该方法以方框900为开始并且进行如下。首先，由于一个管理员对由该分布式系统所提供的商业服务感兴趣，该商业服务一般被从该功能模块选择(步骤905)。在选择一个商业服务之后，该结构模型被查询，以提供在该商业服务的供应中所涉及的主机的选择。这可以通过把该结构模型置于该分布式系统的每个主机上，或者(为了效率的目的)通过此查询存储在包含该分布式系统中存在的服务和主机之间的映射的该管理系统中的一个(定期更新的)服务/主机查找表而实现。该管理员然后根据他的判断选择一个主机(步骤910)。
另外，该管理员编辑一个查询(步骤915)。查询参数的例子包括但不限于遍历的方向(向着服务附属者或者向着其先前者)、遍历的深度(例如，仅仅紧接着的先前者/附属者；所有可能的先前者/附属者，即，该操作模型的完全传递闭包；仅仅在该操作模型的第m和第n层之间)、与属性的存在或者与它们的数值相关的过滤标准。
用于选择服务(步骤905)、主机(步骤910)和用于编辑查询的选项的步骤次序被在此规定的事实强调本发明的“以服务为中心的”方法(与现有技术的“以主机为中心的”方法相反)。但是，本领域的普通技术人员将认识到可以对步骤的次序做出改变(步骤905、910和915)，而不脱离本发明的精神和范围。
这种修改的例子是向用户提供(例如，通过一个图形用户界面)按照任意次序执行选择操作的三个步骤的选择；允许首先选择一个主机，然后通过查询该结构模型查找存在于该主机上的服务，从而限制用于选择的可能服务候选者。
在该服务和主机选择以及查询的编辑之后，该附属关系服务被这些参数所调用(步骤920)。请注意调用的模式可以是同步的(例如，阻止该调用者直到由该附属关系服务返回该结果)或者异步的(因此允许调用者在计算过程中执行附加的任务)。
该附属关系服务计算该操作模型的适当部分，并且根据本发明的模式，把该结果发送回该调用者，或者把该结果可用的情况通知该调用者。然后该调用者收集该结果(步骤925)并且进一步处理它们。该方法在方框930处结束。
现在参见图10，一个流程图示出根据本发明一个实施例用于创建和更新功能附属关系模型的管理员的任务。如果调度和提供新的(商业)服务，或者把改变应用于一个现有的模型，或者现有的(商业)服务被从一个供应中撤回，则这是必要的。
该方法以方框1000为开始，并且进行如下。一个管理员或者管理应用程序评估一个新的商业服务是否应当被添加或者一个现有的服务是否要被删除(步骤1005)。如果没有必要，则该方法直接进行到方框1025。否则，在步骤1010，该服务以及它的描述被输入到已经在图6中所述的该功能模型的模板605(或者被从该模板删除)。
然后，在步骤1015，该服务附属关系，即，关于其先前者的关系，需要被添加到该功能模型的模板605(或者被从该模板删除)。在删除的情况中，请注意来自该服务附属者的附属关系需要被调节到要被删除的服务的先前者的位置。这可能涉及检查在该先前者的附属关系中的最终复制描述。最后，该更新的功能模型被存储在该管理系统的存储库中(步骤1020)。该方法在方框1025结束。
现在参见图11，一个流程图示出根据本发明一个实施例的通过在一个计算机系统上安装或删除硬件/软件组件而更新一个结构附属关系模型的步骤。如果一个新的组件被调度和安装在一个主机上，或者现有的组件被从该主机上删除，则这是必要的。
该方法在方框1100开始，并且进行如下。如果新的硬件组件被安装/删除，则通常通过该操作系统执行它们的附属关系的确认和调节，因此没有在此进一步描述。另外，如下描述针对于添加/删除软件组件的任务。一个管理员或执行软件发布和安装的管理应用程序评估一个新的软件组件是否应当被添加或者一个现有的软件组件是否要被删除(步骤1105)。如果没有必要，则该方法直接进行到方框1125。否则，在步骤1110，该软件组件的描述被输入到已经在图6中所述的该结构模型的模板610(或者被从该模板删除)。然后，在步骤1115，该软件组件附属关系，即，关于其先前者的关系，需要被添加到该功能模型的模板610(或者被从该模板删除)。
在删除的情况中，请注意来自该软件组件的附属者的附属关系需要被调节到要被删除的软件组件的先前者的位置。这可能涉及检查在该先前者的附属关系中的最终复制描述。最后，该更新的功能模型被存储在该主机的资源附属关系存储库中(步骤1120)。该方法在方框1125结束。
现在参见图12，一个流程图示出根据本发明一个实施例的负责操作模型的计算的系统的步骤。该方法在方框1200开始，并且进行如下。
执行操作附属关系模型的计算的系统连续监听在哪一个系统上的该主机的一个特定端口处的请求被执行，其由把方框1205与其自身相连接的循环所示。这是用于实现服务的服务器处理(″daemons″)的标准行为，其可以在任何时候被应用程序所调用。
在接收一个请求时，该系统从该请求提取输入参数(步骤1210)。如图9中所示，输入参数的例子包括但不限于所讨论的服务和主机的名称、遍历的方向、遍历的深度、与属性的存在或者与它们的数值相关的过滤标准。然后，这些输入参数被用于执行该操作模型的实际计算(步骤1215)。
根据在调用时指定的调用模式，该计算的结果，即该操作模型，然后被传递到该调用应用程序(步骤1220)。在该步骤之后，运行该系统的主机的任何被分配资源被释放(步骤1225)。主机资源的例子包括但不限于存储器、磁盘空间或者CPU寄存器。最后，该系统返回到其初始状态，用于后续的输入请求(1205)。
现在参见图13，一个流程图示出根据本发明一个实施例的提取位于一个指定的主机上的直接先前者的步骤。该方法在方框1300开始，并且进行如下。
首先，获得该目标服务和主机的名称(步骤1305)。这些参数通过该调用管理应用程序而提供，其直接从管理员或从到达该管理控制台的一个事件消息获得这些参数。然后，包含该服务描述的单元位于该指定的主机的结构模型中(步骤1310)。
然后，如图6中所示，给定服务的结构模板610的先前者属性的评估(步骤1315)揭示该服务是否具有任何先前者。如果该先前者属性为空，即该单元没有先前者，则该服务单元本身被添加到该操作模型(步骤1320)。一个调用管理应用程序把这解释为仅仅附属于它本身的一个服务。然后该方法直接进行到方框1340。
但是，如果该先前者属性包含一个或多个单元，则该服务具有先前者。因此，该方法进行到方框1325，其把该服务单元添加到该操作模型。另外，一个附属关系单元被添加到该操作模型(步骤1330)。在该附属关系单元的范围内，紧接着在该附属关系单元之后，通过把该结构模板610的先前者属性的内容复制到该操作模型，添加(一个或多个)先前者单元的列表。这样一个实现方式的典型例子是把该附属关系单元定义为一个XML标签，添加先前者的列表，然后关闭该XML标签。该方法通过把该操作模型的内容发送到该调用者而在方框1340结束。
现在参见图14，一个流程图示出根据本发明一个实施例递归地检索位于一个指定的主机上的一个服务的先前者的步骤。更加具体来说，图14示出在递归地检索位于一个指定主机上的一个服务的每个(即，直接或间接)先前者中的深度优先策略的应用。请注意递归查询可以跨越系统或者甚至提供者的边界，例如，到另一个系统的客户机/服务器接合点。
该方法在方框1400开始并且进行如下。首先，获得该目标服务和主机的名称(步骤1405)。这些参数由该调用管理应用程序或者API功能所提供，其直接从该管理员或从到达该管理控制台的事件消息获得这些参数。
然后，包含该服务描述的单元被置于该指定主机的结构模型中，并且进入一个服务列表(步骤1410)。在完成该步骤之后，评估该服务列表是否为空(步骤1415)。如果该服务列表包括单元，则该列表的第一单元被选择，添加到该模型(步骤1420)并且从该列表中删除。
如图6中所示，给定服务的结构模板610的先前者属性的评估揭示该服务是否具有任何先前者。在该先前者属性中列出的单元然后被置于一个分离列表，即，可以为空的该先前者列表(步骤1425)。
然后该方法直接进行到方框1430，其揭示该先前者列表是否包含任何单元。如果该先前者列表为空(即，该服务没有任何进一步的先前者)，则该方法返回到方框1415，以继续在该服务列表中的下一个项目，如果存在该项目的话。
但是，如果该先前者列表包含一个或多个单元，则该服务具有先前者。因此，该方法进行到方框1435，其从该先前者列表中除去先前者服务，并且把它插入到该服务列表的开始处，以使允许该图形结构的深度优先遍历。另外，该先前者(以及表示实际附属关系的链接)被添加到该操作模型(步骤1440)。该方法的这一部分被执行，直到该先前者列表为空。如果存在这种情况，则该方法进行到方框1415，并且继续(最终被扩展的)服务列表。如果该服务列表为空(方框1445)，则通过把该操作模型的内容发送到该调用者而结束该方法。
现在返回到图15，一个流程图示出根据本发明一个实施例检索位于一个指定主机上的服务的直接附属者的步骤。该方法在方框1500开始，并且继续执行如下。
首先，获得目标服务和主机的名称(步骤1505)。这些参数通过调用管理应用程序而提供，其直接从该管理员或从到达该管理控制台的一个事件消息获得这些参数。然后，包含该服务描述的单元位于该指定主机的结构模型中(步骤1510)。
然后，对于其先前者是该目标服务单元的所有单元的搜索揭示该服务是否具有任何附属者。如果该结果为空(步骤1515)，即，该单元没有附属者，则该服务单元自身被添加到该操作模型(步骤1520)。一个调用管理应用程序把这种情况理解为仅仅附属于其自身的一个服务。然后该方法直接进行到方框1540。
但是，如果对于其先前者是目标服务单元的所有单元的搜索产生一个或多个单元，该服务具有附属者。因此，该方法进行到方框1525，其把该服务单元添加到该操作模型。另外，一个附属关系单元被添加到该操作模型(步骤1530)。在该附属关系单元的范围内，紧接着在该附属关系单元之后，把(一个或多个)附属者单元添加到该操作模型。这种实现方式的一个典型例子是把该附属关系单元定义为一个XML，添加附属者的列表，然后关闭该XML标签。通过把该操作模型的内容发送到该调用者，该方法在方框1540结束。
现在参见图16，一个流程图示出根据本发明一个实施例的递归地检索位于一个指定主机上的服务的附属者的步骤。更加具体来说，图16示出递归地检索在位于一个指定主机上的一个服务的每个(即，直接或间接)附属者的一个深度优先策略的使用。请注意，该递归查询可以跨越系统或者甚至提供者的边界，例如，到另一个系统的客户机/服务器接合点。
该方法在方框1600开始并且进行如下。首先，获得该目标服务和主机的名称(步骤1605)。这些参数由该调用管理应用程序或者API功能所提供，其直接从该管理员或从到达该管理控制台的事件消息获得这些参数。然后，包含该服务描述的单元被置于该指定主机的结构模型中，并且进入一个服务列表(步骤1610)。
在完成步骤1610之后，评估该服务列表是否为空(步骤1615)。如果该服务列表包括单元，则该列表的第一单元被选择，添加到该模型(步骤1620)并且从该列表中删除。如图6中所示，对于该服务列表的当前单元的存在情况的所有结构模板610的先前者属性的评估揭示该服务是否具有任何附属者。
在其先前者属性中出现所述服务的该单元的服务名然后被置于一个分离列表，即，可以为空的该附属者列表(步骤1625)。另外，如果该结构模板610包含一个附属者属性(即，该附属关系由双向链路所表示)，则该附属者属性的内容被复制在该附属者列表中。
该方法然后直接进行到方框1630，其评估该附属者列表是否包含任何其他单元。如果该附属者列表为空(即，该服务没有任何进一步的附属者)，则该方法返回到方框1615，以继续在该服务列表中的下一个项目，如果存在该项目的话。
但是，如果该附属者列表包含一个或多个单元，则该服务具有附属者。因此，该方法进行到方框1635，其从该附属者列表中除去该附属者服务，并且把它插入到该服务列表的开始处，以使允许该图形结构的深度优先遍历。另外，该附属者(以及表示实际附属关系的链接)被添加到该操作模型(步骤1640)。该方法的这一部分被执行，直到该附属者列表为空。如果存在这种情况，则该方法进行到方框1615，并且继续(最终被扩展的)服务列表。如果该服务列表为空(方框1645)，则通过把该操作模型的内容发送到该调用者而结束该方法。
现在返回到图17，其中示出根据本发明一个实施例的附属关系服务应用程序编程接口(API)的例子。该表格包括可以为给定的服务和主机名产生、发送和请求适当操作模型的接收的基本API。本领域的普通技术人员应当知道该API可以使用一个或多个参数(未示出)来识别由该API所使用的特性(在功能描述中指定)。
具体来说，一个″getAntecedents(参数)″API检索位于一个特定主机上的服务的直接先前者。该″getAntecedentsRecursive(参数)″API执行递归″向下钻″操作，即，它检索位于特定主机上的一个给定服务的所有先前者。该″getDependents(参数)″API检索位于一个特定主机上的给定服务的直接附属者。该″getDependentsRecursive(参数)″API执行一个递归的“向上钻”操作，即，其检索位于一个特定主机上的一个给定服务的所有附属者。″getServiceDependencies(参数)″API对于一个特定服务产生所有递归附属者的列表(即，先前者和附属者)。″getTransactionDependencies(参数)″API检索参与在一个特定交易中的硬件和软件组件的列表以及它们的附属关系。″getTransactionComponents(参数)″API检索参与在一个特定交易中的硬件和软件组件的列表。″getHostDependencies(参数)″API对位于一个特定主机上的所有服务产生一个所有递归附属关系的列表。″getHostComponents(参数)″API检索安装在一个特定主机上的硬件和软件组件的列表。“getExternalServiceDependencies(参数)API”对一个特定服务产生跨越域边界的所有递归附属关系的列表(即，先前者和附属者)，即在另一个服务提供者的控制下。最后，″getReferencingDependencies(参数)″API对于在主机上的一个给定服务返回向上和向下的附属关系的参考。
尽管在此参照
本发明的示意实施例，但是应当知道本发明不限于这些具体实施例，本领域的普通技术人员可以做出各种改变和变型而不脱离本发明的精神和范围。
权利要求
1.一种基于计算机的在计算环境中的管理信息的方法，该方法包括如下步骤获得与该计算环境的组件相关的信息；从至少一部分所获得的信息确定与该计算环境的至少一部分组件相关的一个或多个关系的存在，其中确定一个或多个关系的存在的步骤能够考虑到与该计算环境的至少一个组件相关的整个操作周期。
2.根据权利要求1所述的方法，其中该计算环境包括一个分布式计算环境。
3.根据权利要求1所述的方法，其中该计算环境包括一个自治的计算环境。
4.根据权利要求1所述的方法，其中确定与该计算环境的至少一部分组件相关的一个或多个关系的存在的步骤进一步能够考虑到对与该计算环境的至少两个组件相关的互异性。
5.根据权利要求1所述的方法，其中确定与该计算环境的至少一部分组件相关的一个或多个关系的存在的步骤进一步考虑到跨越与该计算环境相关的一个或多个域的一个或多个组件。
6.根据权利要求1所述的方法，其中确定与该计算环境的至少一部分组件相关的一个或多个关系的存在的步骤进一步包括以一种形式计算组件附属关系，该形式包括功能分类、结构分类和操作分类。
7.根据权利要求6所述的方法，其中组件附属关系的功能分类包括被模型化为一个节点图的功能单元，其中一个或多个第一节点被链接到被该一个或多个第一节点所附属的一个或多个第二节点，以及链接到附属于一个或多个第一节点的一个或多个第三节点。
8.根据权利要求7所述的方法，其中该节点是在该计算环境中的组件的表示。
9.根据权利要求8所述的方法，其中该组件被定义为至少附属者和先前者之一。
10.根据权利要求9所述的方法，其中该节点图包含在节点之间的链路，该链路表示附属关系。
11.根据权利要求10所述的方法，其中该附属关系是一对一的关系，包括一个附属者和一个先前者。
12.根据权利要求7所述的方法，其中该功能单元与在该结构分类中的结构单元链接或交叉引用。
13.根据权利要求6所述的方法，其中该组件附属关系的结构分类包括被模型化为一个节点图的结构单元，其中一个或多个第一节点被链接到被该一个或多个第一节点所附属的一个或多个第二节点，以及链接到附属于一个或多个第一节点的一个或多个第三节点。
14.根据权利要求13所述的方法，其中该结构单元提供定义该计算环境的组件的调度方面的信息。
15.根据权利要求14所述的方法，其中在由至少一个系统管理员和操作员所进行的调度操作过程中，关于该结构分类的信息被存储在一个或多个存储库中。
16.根据权利要求15所述的方法，其中关于结构单元的信息可以由一个或多个应用程序编程接口从一个或多个系统存储库中获得。
17.根据权利要求6所述的方法，其中该组件附属关系的操作分类包括被模型化为一个节点图的操作单元，其中一个或多个第一节点被链接到被该一个或多个第一节点所附属的一个或多个第二节点，以及链接到附属于一个或多个第一节点的一个或多个第三节点。
18.根据权利要求17所述的方法，其中该操作单元与在该结构分类中的结构单元链接或交叉引用。
19.根据权利要求6所述的方法，其中该操作分类从至少一个结构分类和功能分类计算。
20.根据权利要求6所述的方法，其中该组件附属关系的分类被表示为图形表示。
21.根据权利要求20所述的方法，其中该图形表示的至少一部分边界由附加的考核信息所表示。
22.根据权利要求20所述的方法，其中该图形表示是单向和双向之一。
23.根据权利要求20所述的方法，其中该图形表示是有向非循环图和有向循环图之一。
24.根据权利要求20所述的方法，其中一个图形表示至少是可向上、向下和横向遍历之一。
25.根据权利要求20所述的方法，其中由一个图形表示所表示的附属关系信息可以根据一个或多个应用程序编程接口而被访问。
26.根据权利要求6所述的方法，其中在被计算之后，一个或多个分类被永久地存储。
27.根据权利要求6所述的方法，其中在计算之后，一个或多个分类不被永久地存储。
28.根据权利要求1所述的方法，其中一个组件是服务、应用程序、中间件、硬件、设备驱动器、操作系统和与计算环境相关的系统之一。
29.根据权利要求1所述的方法，其中该信息获取步骤进一步包括通过一个或多个直接涉及的系统和一个或多个代理系统中的至少一个获取信息。
30.根据权利要求1所述的方法，其中进一步包括维护与一个或多个关系的至少一部分相关的改变历史的步骤。
31.一种用于在计算环境管理信息的装置，其中包括至少一个处理器，其操作为(i)获得与该计算环境的组件相关的信息；以及(ii)从至少一部分所获得的信息确定与该计算环境的至少一部分组件相关的一个或多个关系的存在，其中确定一个或多个关系的存在步骤能够考虑到与该计算环境的至少一个组件相关的整个操作周期；以及耦合到至少一个处理器的存储器，其存储与一个或多个所确定关系相关的信息。
32.根据权利要求31所述的装置，其中该计算环境包括一个分布式计算环境。
33.根据权利要求31所述的装置，其中该计算环境包括自治计算环境。
34.根据权利要求31所述的装置，其中至少一个处理器被进一步操作，以检索至少一部分所存储信息。
35.根据权利要求31所述的装置，其中确定与计算环境的至少一部分组件相关的一个或多个关系的存在的操作进一步能够考虑到与该计算环境的至少两个组件相关的相异性。
36.根据权利要求31所述的装置，其中确定与该计算环境的至少一部分组件相关的一个或多个关系的存在的操作进一步能够考虑到跨越与该计算环境相关的一个或多个域的一个或多个组件。
37.根据权利要求31所述的装置，其中确定与该计算环境的至少一部分组件相关的一个或多个关系的存在的操作进一步包括计算采用一种形式的组件附属关系，该形式包括功能分类、结构分类和操作分类。
38.根据权利要求31所述的装置，其中一个组件是服务、应用程序、中间件、硬件、设备驱动器、操作系统和与该计算环境相关的系统之一。
39.根据权利要求31所述的装置，其中该信息获取操作进一步包括通过一个或多个直接涉及的系统和一个或多个代理系统中的至少一个获取信息。
40.根据权利要求31所述的装置，其中至少一个处理器进一步操作以维护与一个或多个关系的至少一部分相关的改变历史。
41.一种用于在计算环境中管理信息的产品，其中包括包含一个或多个程序的机器可读介质，当执行该程序时执行如下步骤获得与该计算环境的组件相关的信息；以及从至少一部分所获得的信息确定与该计算环境的至少一部分组件相关的一个或多个关系的存在，其中确定一个或多个关系的存在步骤能够考虑到与该计算环境的至少一个组件相关的整个操作周期。
全文摘要
用于在计算环境中管理信息的技术。获得与该计算环境的组件相关的信息。然后，从至少一部分所获得的信息，确定与该计算环境的至少一部分组件相关的一个或多个关系的存在。确定一个或多个关系的存在步骤能够考虑到与该计算环境的至少一个组件相关的整个操作周期(例如，包括调度、安装和运行)。因此，用于管理计算系统的各个组件之间的运行时间附属关系的技术被公开，其提供来自各个系统的一级概括，并且允许与端到端服务相关的服务/组件(其中该组件例如可以是一个应用程序、中间件、硬件、设备驱动器、操作系统和与该计算环境相关的系统)的附属关系的计算。例如，本发明的技术可以应用于一个分布式计算环境。该计算环境也可以是一个自治计算环境。
文档编号G06Q10/00GK1489078SQ0315807
公开日2004年4月14日 申请日期2003年9月4日 优先权日2002年9月11日
发明者亚历山大·凯勒, 亚历山大 凯勒, 尤利·布拉门塔尔, 布拉门塔尔, D. 杰克逊, 罗利·D.·杰克逊, 卡尔, 高塔姆·卡尔 申请人:国际商业机器公司