CN1171145C

CN1171145C - 用于自动软件配置的请求调度程序

Info

Publication number: CN1171145C
Application number: CNB001359681A
Authority: CN
Inventors: N; N·伦兹; F·米尔克; R·特伦
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-12-30
Filing date: 2000-12-19
Publication date: 2004-10-13
Anticipated expiration: 2020-12-19
Also published as: CN1302014A; US7051092B2; US20010054091A1; JP2001222436A

Abstract

本发明与在用户位置使软件适用于需求设置的领域相关联。它适用于不同系统管理环境自动地配置软件。尤其，它与资源自动管理相关联(12，14，16)，甚至与软件程序的自动配置有关。发明基本上提出了下面一系列步骤：存取包含请求的资源库(18)；重新组织在某种意义上被排序、被附随等的所说请求；调用管理程序资源，例如，处理所说请求的服务的支持器。

Description

用于自动软件配置的请求调度程序

技术领域

本发明与在用户位置使软件适用于需求设置的领域相关联。尤其，它关系到内部相互依存的资源的自动管理，甚至关系到软件程序的自动配置。

背景技术

本发明覆盖了较广的应用领域。其基本概念能成功地被用于解决管理资源并行请求的问题——对这些资源的利用在一定程度上影响其它资源的可利用性。为大量请求者所分享的资源之间的相互依赖性就是一个例子。而且，许多涉及到计算机环境的问题也能得到解决，尤其，在大量资源需求被要求由单一设备——即系统管理器——满足的情况下，并且当为满足该需求而完成地工作相当复杂时。其复杂度可能基于大量不同的原因，例如，满足一个需求时可能影响到一个或多个其它的需求，并引起标准质量和数量的变化。或者，如执行所谓撤消(UNDO)操作的困难—即要恢复在某些需求被满足之前所处于的状态。

潜在应用的一个例子是这样的管理队列，其中资源存取被以下面的方式管理：排队处理过程以优化方式实现，尤其当要求一个过程完成后再处理另一个过程时。

然而，应用的一个特殊领域在于软件程序的配置和/或用户化。软件这一术语中明确包含各种类型的软件，即应用程序，中间设备，和操作系统程序。这一应用领域——尤其是应用程序——在这里被用于讨论现有技术及其相关的缺点。

通常，一种硬件系统，例如个人计算机、工作站或主机，被设计并计划要能容纳不止一种商业应用程序。

一般地，逻辑或物理系统资源，如用户ID、TCP/IP地址或不同的外围设备如打印机、绘图仪等，被这些程序以分享的方式使用。这样，通常这种程序必需被用户化，即使其适用于终端用户位置上的普遍环境。这就要求执行对使用中的计算机的操作系统所应用的系统变量进行设置。然而，不同的应用程序可能要求不同的系统变量设置。因为依赖于被牵扯到的系统变量的类型，所以错误的设置可能破坏基础的计算机硬件的正确操作，并最终引起对不应受干扰的商业操作程序异常中断。

依赖于使用的硬件类型，系统变量的数量范围可能从具有现行操作系统的PC机中的几百个到群集主机系统的系统环境中所定义的几十万个。因此，仅仅系统变量的数目就能导致某种复杂性的存在。

现有技术中，主机自动用户化，例如IBM OS/90产品，是不可行的。因此，系统管理员必需手动用户化产品——有时借助于特定的实用程序，这既不需要详细的了解操作系统的基本组成如何，也不需要了解通常形成操作系统与一个或多个应用程序之间的中间层的所谓中间设备产品。上面所提到的系统变量特定设置之间的相互依赖性可能很复杂，而保持对所牵扯的问题的整体了解的方法是独立的——由系统管理员操作的独立性所决定。因而，配置和/或用户化应用程序的任务是十分困难的。

对于其它的平台如Windows 98或Windows NT，有脚本驱动用户化过程，如InstallShield。这些脚本被提供以便防止终端用户动手做这些事。这些脚本与这些应用程序一起被提供以便能以成功地启动和使用这些程序的方式用户化计算机资源。

这一方法的缺点在于脚本中被执行的所有步骤必须由很了解操作系统细节的应用程序程序员编程。将他们结合到在一个脚本中的过程也限制了可靠性和可用性，尤其在由于遗漏细节出现失败的情况下。

发明内容

因此，本发明的一个目的是提供一种方法和系统，使用这种方法和系统，所有以共同管理单元为目标的大量并行资源需求可以以一种改进的方式被管理，例如，以减少系统管理员参与的方式。

进一步的目的是提供能用于自动配置和/或用户化应用程序的方法和系统。

本发明的目的由附在后面的独立权利要求中所陈述的特征实现。发明地更为有利的装置和实施例在各个从属权利要求中提出。

为了提高说明的清晰度，为了确切地确定本发明的范围这些术语，这里使用的一些特定的术语被定义：

本发明使用到各种类型的软件上，即应用程序、中间设备和操作系统软件。

上面提到的使用大量系统资源的任何程序在这里被称为开发器产品或开发器(例如应用程序)，因为它使用系统资源开发新软件。

系统资源的支持器应理解为一种管理系统资源的程序方法。应理解为它包括大量有关如何恰当地处理特定系统资源的知识。当系统资源的管理相当复杂时，这些知识包括对管理资源不同方面的各子任务的了解和控制。

术语“连接”应在一定意义下理解为用户化开发器产品使其可用时对操作系统中必须被改变的资源的更新。

广义上讲，请求调度过程的发明概念能够用于支持任何类型的支持器维护的资源的自动管理。尤其，它能更具优势地被用于系统管理和软件产品的用户化。

根据其大体上的各方面，发明方法包括下列步骤：

存取包括请求的资源库——各请求定义了一个应被执行的动作，或一个应达到的与某一资源相关的一种预期状态；重新组织这些请求；调用管理程序方法的资源以用于处理一系列请求。然而，根据这些请求，支持器执行对资源的实际处理。

自动管理基本上包括重新组织这些在某种意义上被要求、被附随等的请求，并调用管理程序的资源，即上述提到的支持器，用于处理该请求的服务。应了解到运行请求时触发的动作变化范围很广。

可以提出请求以要求提供其基本的功能内容和结构由被讨论的计算机系统维护和控制的任何服务。例如更新文件、在安全数据库中创建用户ID。更一般的例子如从数据库搜集信息并将结果写入资源库中，调用其它的软件程序，触发其它硬件设备以实现特定的功能性(如通电话)，或启动产品设备。

上面提到的第二个问题的解决方法由通过所谓的请求定义而表达用户化需求的方法定义，这一请求定义说明了启动开发器产品时而必需建立的操作系统资源的资源状态。

为了达到这一目标，根据本发明的一个方面，执行软件需要逻辑上通过触发各程序执行用户化和/或配置，以便确保资源被要求的状态得到设置，其中各程序对特定的操作系统资源负责，例如，如UNIX操作系统目录中包含的传统配置文件。

触发软件形成发明概念的基本部分，在这里被称为请求调度程序。被触发程序被称为支持器或支持器程序。

用于配置支持应用程序的自动配置的本发明的基本原则是：在资源库中请求被完全具体化，例如包括用户特定环境信息的基于LDAP(简便目录存取协议)的目录。

请求调度程序和支持器程序在驱动系统中运行以更新目标系统中的资源，目标系统在某种特殊情况下可以是驱动系统本身。例如，如果有Windows用户在驱动系统中运行请求调度程序，可能触发支持器程序更新局域网服务器(目标系统)上的资源。在特殊情况中，当驱动系统等同于目标系统时，例如，请求调动程序运行在如Windows用户上，因此会更新Windows用户上的资源。

在现有技术中，上面提到的脚本说明何种功能性应被执行。这暗示了应用程序程序员必须在这一领域具有较高的技术水平。此程序员必须了解如何运用操作系统资源以满足无问题并且不与其它程序冲突运行程序需要的前提。

与上面的相比，发明的程序工具即“请求调度程序”形式下的发明方法会引发能够说明开发器产品预期先决条件是什么的开发器请求。根据本发明，如何在操作系统中实现的问题可通过交付实现的支持器程序得到解决，结果会改变由发明的请求调度程序驱动的被需求资源。

因此，请求调度程序的执行基于与传统的脚本处理过程不同的模式：脚本说明了做什么以及怎样做以设置特定的资源状态，但是发明的请求说明定义出哪种资源状态是要求的(仅说明目的而未说明实现途径)，因此与写脚本相比请求更易于指定。这样，开发器产品的程序员不需要了解更多的操作系统的特定知识，其次配置和用户化开发器产品的工作对于终端用户隐藏起来了。

总结本发明所包括的大致方面，下面的基本条目反映了发明的请求调度程序的各独立方面。这些基本条目被列如下：

1.请求调度程序定义了结构接口，支持器程序必须使用该接口获得与请求调度程序通信的统一方式。这样确保了可扩展性，在某种意义上新支持器程序能插接到请求调度程序上而并不改变请求程序的代码。

2.请求从资源库中被读取并根据静态顺序关系被存储，静态顺序关系定义了支持器将被请求调用程序调用时所遵循的序列。根据用于说明哪个请求应先于其自身被执行的请求前趋属性，由请求调用程序实现排序。当开发器具有对多个支持器的请求时，这一静态支持器顺序关系使得为所有请求调用各个支持器成为可能，这样提高了性能。根据前趋属性，请求排序允许定义相互依赖的请求的执行序列。

3.各支持器获取经排序的请求链，这对更新被说明的资源状态负责。

根据资源状态说明，支持器更新资源对开发器和产品用户隐藏了实现细节。开发器不必担心如何实现他们产品中操作系统的特定前提，而相反，他们仅需定义这些前提是什么。

4.资源库中说明的请求可能属于不同的开发器产品，即请求调度程序能配置更多的开发器产品并将其调度到相应的支持器上。因此，各支持器的请求链可能包含不同开发器的请求。发明的请求调度程序的实现是灵活的，在某种意义上不同的开发器产品可以同时得到配置。

5.支持器程序的一个已被熟知的特征是其“幂等性”。

基于这一术语，应当了解该支持器控制其自身负责的资源，支持器可以被多次调用，而且由于幂等性的原因，支持器知道是否有些东西改变与否。支持器幂等性的这一特征被进一步开发，与请求调度过程的发明概念相结合。这使得请求调度程序更为强壮并隐藏了实现细节。

6.请求调度程序允许支持器产生子请求，尤其在为了改进现存请求时。这利用在下面将进一步说明的EVALUATE(评估)功能性实现。通过产生子请求而改进请求时允许更容易地具体化和压缩请求定义。依据应被配置的特定系统，支持器利用此机制，通过生成对BIND(连接)步骤中实现的子目标负责的新请求，使请求更加细化。更进一步地，它允许将更新功能性部分分派给其它支持器。

7.通过使请求调度程序登录机制可用于协议执行流程并可用于说明支持器能做些什么，请求调度程序才能使支持器在“SIMULATE”(模拟)模式下运行。这意味着模拟过程并不更新资源，但任何支持器都在登录文件中说明当SIMULATE(模拟)模式关闭时——即现实已被模拟——已经做了些什么。请求的这种模拟允许支持器在登录文件中拟定在不真正更新资源的情况下应完成何种工作，例如，如果安全管理员不想自动的执行改变，他可以模拟资源改变，然后检测登录文件中哪些动作已被自动地完成了。然后他可以决定要自动还是手动完成这些动作，或者根本不更新资源状态。

8.更新资源，即用下面说明的请求调度程序选项BIND(连接)来实现驱动，与资源的激活相分隔开有利。因此，对于在“BIND”(连接)步骤中由支持器生成的激活请求的执行，请求调度程序具有ACTIVATION(激活)功能性。BIND(连接)和ACTIVATE(激活)间相分离的发明特征并不迫使用户在一步中同时完成它们。因此，对于系统管理员来说如果首先检测资源更新更为有利的话，他可以先检测，晚一些时候再激活它们。另一个优点就是两个彼此不相关的不同时刻可以用来完成此两项任务。

9.“UNBIND(拆分)实现”的发明特征，依据上面提到的“BIND”(连接)中使用的静态顺序关系和请求的前趋排序，将按相反的顺序触发具有逆向请求改变的支持器。因而，“UNBIND”(拆分)是一个重要的功能，能自动逆转资源改变而不需要将逆转具体化为一个新的请求。来自“BIND“(连接)功能的请求将被使用，逆转实现将自动地被执行。这样，系统管理员的工作得到减轻。

10.请求调度程序在调用各带有“BIND”(连接)的任何支持器之前要调用各带有“CHECK_BIND”(检验连接)的支持器。在CHECK_BIND(检验连接)期间，任何支持器有机会在其被再次调用以真正地执行BIND(连接)——即更新资源之前能检测其前提条件。根据本发明的优选特征，在执行CHECK_BIND(检测连接)之前，要检测是否被请求的最小支持器版本已被安装。如果已安装，支持器将被调用，否则版本不匹配的信息将被写入到登录文件中，请求调度程序终止。这一过程同样适用在“ACTIVATE”(CHECK_BIND(检测激活))过程中。

在调用带有BIND(连接)功能的支持器之前调用带有CHECK_BIND(检测连接)功能的各个支持器能够确保只有当所有支持器能无误的实现更新时才执行真正的资源更新。这样提高了这种复杂操作的可靠性，因为在BIND(连接)过程中降低了出错的风险。版本不匹配检测运算法则也是一种品质改进，因为在现有技术系统中这些版本不匹配不能系统化地被检测出来，只是在运行期间出现在基础的参数层次上的不匹配除外，而这是很难于辨别出的。

11.支持器能确定支持什么样的功能性，例如，如果不需要激活请求生成，那么请求调度程序将不为ACTIVATE(激活)功能调用这种支持器，支持器实现这种类型的功能性将在支持器的服务说明中被具体明确，即作为具有“supportType”(支持类型)属性的资源库的一部分，并因此该功能可通过存取资源库从请求调度程序中存取。由请求调度程序支持的其它功能性，如初始化——这里称为PRIME，如果不能由特定请求调度程序功能性的支持器程序设计提供，那么能够被开或关。处理“supportType”(支持类型)属性能够防止对不能实现特定类型功能性的支持器的不必要的调用。这样提高了性能。

12.在用户化过程中，终端用户将从请求调度程序的执行中获利，尤其对于现有技术IBM OS/390系统，因为直到现在对于配置OS/90产品也没有自动的解决方法。另外，与现有技术脚本程序相比，用户化步骤的可靠性和可用性由于发明的请求细化度而被提高了——这是一个平台的独立特征，例如，现有技术中基于WINDOWS系统的IstallShield方法。

13.在与请求调度程序所运行的系统一致的系统中，请求调度程序可被有利地实现于使用标准的Java类加载器以调用支持器程序。然而，远程类加载器或Java RMI(远程方法调用)也可被使用，并具有这样的优点，即支持器程序可以同请求调度程序一样驻留在其它系统中，这意味着对于使用不同操作系统的不同系统之间的协同性而言，请求调度程序的设计是开放式的。唯一的假设在于两者要对相同的资源库进行存取。

14.请求调度程序也被用于触发能实现除更新系统资源以外的其它功能的支持器程序的执行。请求调度程序是独立于支持器所执行的工作种类，但是要对请求进行管理而不管它们将在支持器一侧触发何种动作。

15.生成XML(可扩充标高语言)的格式的登录文件，文件中保存着请求的执行序列，在出错时能检测问题所在，这是一个重要的优点。XML格式本身被选择以便易于使用标准软件来浏览其内容。尤其，追踪属于设计的结构部分，而且支持器与请求调度程序能追踪到相同的文件中，如果该申请调度程序将有助于确定问题所在。

本发明的一个重要而有利的特征是请求调度过程的复杂流程可被登录或追踪工具写下来，而这些工具可以被请求调度程序和支持器使用。

一个具有优势的设计问题——即使未来的支持器程序能以其自身的代码插接到请求调度程序上——已由请求调度程序和支持器程序之间的用于调用和结果提示的结构接口所解决。

总结请求调度程序的优选结构特征，基本上从两个接口来获取输入：

一是命令行调用接口；二是资源库存取。命令行接口能被手动触发或，例如在Windows NT系统中，被GUI驱动工具触发。通过可辨识的名称，命令行接口引用了bindConfiguration(连接配置)，其中bindConfiguration(连接配置)涉及到了明确请求和应被执行的功能性(EVLUATE【评估】，BIND【连接】，ACTIVATE【激活】，UNBIND【拆分】)的开发器服务。它们被送给请求调度程序。驱动和目标系统的可辨识名称也作为输入。

利用bindConfiguration(连接配置)，为资源库中各开发器服务而组织的请求被请求调度程序读取到存储器中。它将这些请求分组到支持器的特定链中，由此各请求由支持器负责执行的“requestedService”(被请求的服务)属性定义。因为这是请求调度程序设计的一个重要特征，因此将在下面尤其参考IBM OS/90主机技术的例子中解释：

设想有一个涉及到两个开发器服务的bindConfiguration(连接配置)，这两个服务为应被用户化的应用程序或‘产品’，称为ParallelSysplex和HomeBanking。开发器ParallelSysplex定义了对照支持器RACFSecurity和其自身的请求。开发器HomeBanking定义了两个对照支持器RACFSecurity的请求和一个对照支持器Parmlib的请求。

请求调度程序发现了所有的请求并将其排序成三个链。

—RACFSecurity链，包括三个请求，即两个HomeBanking请求和一个RarralleSysplex请求；

—Parmlib链，包括一个请求；

—ParallelSysplex链，包括一个请求。

请求链要被排序以及如何实现排序这一事实是另一个重要的发明特征。支持器顺序关系在资源库中被定义，是代表支持器执行序列的。

另外，请求调度程序包括排序机制，以便根据请求的前趋属性指定的前趋属性对请求链进行排序。被前趋属性所引用的请求——前趋属性具有对具有相同的被请求的服务名称的另一个请求的引用，在请求包括前趋属性之前存在于请求链中。

进一步，请求调度程序能以模块化形式被有利地实现。因此，它提供了大量——这里基本上是四个——主函数，这些主函数要在序列EVALUATE(评估)，BIND(连接)，ACTIVATE(激活)和UNBIND(拆分)中被成功地执行。因此，请求调度程序将被调用三次以成功地将开发器服务连接到操作系统上，并再调用一次以便将开发器服务与操作系统拆分开(UNBIND)。

请求调度程序通过使用SupporterObject(支持器对象)有利地调用支持器功能性作为输入，利用SupporterObject支持器程序能存取请求调用程序提供的API。这些输入包括请求链和有关追踪和登录的信息，根据上面描述的以及在资源库说明中描述的静态顺序关系，这是为了使支持器程序易于使用这些工具。

请求调度程序的另一个重要的发明特征在于，在XML登录文件中登录执行序列。这允许请求调度程序和支持器程序产生其动作的连续执行序列，同时允许请求模拟。这里模拟并不意味着在资源中执行请求，而是在模拟模式关闭时说明已经做过哪些动作。

被应用到调度开发器请求中的发明方法的四个基本功能性概括如下：

EVALUATE(评估)

当请求调度程序通过EVALUATE(评估)被调用时，它调用支持器提供资源库存取方法，以便产生新的连接请求作为现存连接请求的子请求。这一功能性被设计成允许支持器对开发器请求精选。其原因在于，开发器产品不了解也不欲关心太多的支持器细节。因此，建议支持器允许具体化高级请求，依赖于操作系统的细节最终这些高级请求可以被相应的支持器精选。换句话说，一种请求级联被建立起来。在实现成功的评估后，用户能浏览资源库以审察由该级联生成的请求，并改变它们，因为手动执行干预是可能的。然后，用BIND调用请求调度程序以执行被生成的连接请求。

BIND(连接)

如果请求调度程序使用选项BIND(连接)被调用，根据上面用CHECK_BIND说明的顺序关系，它首先调用所有的支持器，参考第10页。支持器具有查证用选项BIND(连接)执行请求是否失败的可能性。如果所有支持器返回OK——返回代码，它们将用函数BIND(连接)以相同的顺序被调用。支持器将在整个请求链上工作，同时更新资源。这些是被要求配置开发器产品的资源以使该产品被启动。

通常地，更新资源不足以在操作系统中使更新处于激活状态。因此，通过使用与EVALUATE(评估)中所使用的相同的请求调度程序接口，用于激活的请求可被支持器程序创建。

ACTIVATE(激活)

为了激活操作系统中的资源改变，请求调度程序可用选项ACTIVATE(激活)被调用。所有的在连接期间被生成的激活请求将以BIND(连接)中使用的相同的形式并按照支持器使用选项ACTIVATE(激活)被调用时所遵循的顺序关系被执行。支持器实现激活请求，例如它们通过设置命令激活OS/390 parmlib中的成员。在设置完命令之后，被改变后的parmlib处于激活状态，在某种意义上其被改变后的参数正影响着操作系统，例如，它们定义了更多的虚拟存储器等。

UNBIND(拆分)

如果在BIND(连接)过程中，一个请求不能得到执行，整个bindConfiguration(连接配置)都不能成功地连接。这时请求调度程序将失败地终止。为了使资源改变被成功地执行，失败的请求在这之前必须被清除。因此请求调度程序能用选项UNBIND(拆分)被调用，与BIND(连接)过程相比，选项UNBIND(拆分)迫使支持器以相反的顺序被调用，同时请求链也被反向。

附图说明

结合前面提到的作为对应用程序自动配置的请求调度程序的专利申请，本发明将得到更为详细地说明。本发明的优选方面将通过例示的方式被说明，但是并不限于附图中图表的形式。附图包括：

图1是示意方块图，表示发明请求处理过程和其中涉及到的最基本的要素的总体想法；

图2A和B是示意方块图，表示发明方法的总体控制流程；

图3是示意描述，表示支持器执行和登录步骤的细节。

具体实施例描述

对于下面本发明优选实施例的详细说明，应假设有n个应用程序被容纳在主机中。对于本领域中的技术人员，他们经常遇到大量应用程序中的并列配置请求的问题，发明的优点应是为他们所理解的。

根据本发明所包括的基本想法，大量应用程序从操作系统的角度被看成是开发器E1、E2...En，因为他们开发操作系统的资源。

在图1中，开发器或开发器产品用框10框起来，这样意在表示出相同的硬件系统和相同的操作系统资源被它们所存取。

另一方面，所说操作系统资源在图1的右边用符号描述出来，参看标号12、14、16。

当开发器产品将被安装时或其配置数据必须被更新时，将导致的系统配置的改变会引起开发器产品E1...En向操作系统的资源提出并行请求的问题。

根据本发明，所说大量请求在请求资源库18中被连接。这些请求在图1中只部分地被说明，用r11，r1j...rn1表示出来。所说这些请求用XML语言定义，和该请求资源库是一个基于LDAP目录。这样使用通常的浏览工具系统管理员就可以看见这些请求。

在所说资源库18中，请求有利地以树形结构被存储。通常，各请求具有一个或多个属性，这些属性必需用相关的值填充以定义所说请求。例如，系统中用于确认用户标识的请求可能包括下列属性及其值：

请求属性

Objectclass对象类 BindRequest连接请求

BindRequest连接请求 Securityl安全1

ConfigurationID配置ID ParallelSysplex并行Sysplex

RequestedService被请求的服务 RACFSecurity RACF安全

RequestedSupportName被请求的支持名称 ASSURE_USER确定-用户

RequestParameters请求参数 USER_ID＝THEL用户-ID-THEL

RequestParameters请求参数 GROUP＝D1311组＝D1311

RequestStatus请求状态 REQUESTED被请求的

ReturnCode返回代码 0

ReasonCode原因代码 0

MinSupportVersion最小支持版本 1.0

更多的属性可以被相加成，例如一个属性，用于具体指明是否特定请求的服务对于系统运行是必要的或是可选择的。上面的请求定义应仅仅理解为一个例子，用面向对象的编程语言实现。通常，定义请求的任何属性的类型，数量以及值对于各个请求都是特定的。然而，下面的属性对于应用在下列实施例中的所有请求都是相同的：

被请求的服务：用于明确指定由请求调度程序所调用的支持器程序的名称。

被请求的支持名称：这里被请求的功能性可被定义，例如用于确认用户。

配置ID：定义唯一的字符串，识别包括请求的开发器配置。

请求参数：是支持器特定的，在上面的例子中它们表示特定的用户标识名和安全支持组。

请求状态：说明请求的现行状态。

REQUESTED：意思是请求将被执行，其它可能的值为BOUND(连接)，BIND_FAILED(连接-失败)，EVALUATED(评估)等。

最小支持版本：包括为执行请求而被要求的支持器版本。

请求调度程序，即一些程序方法，用参考标号20标识。所说请求调度程序20能通过标准化接口22存取请求资源库18进行读写操作。

请求调度程序重新组织这些下面进一步详细说明的请求。标准化的接口24在请求调度程序20和大量支持器S1，S2...SM之间被提供以便使请求调度程序能调用支持器。请求调度程序20的一个任务是将这些请求重新组织分成子组，在图1中用rik表示，每个子组都与各自的支持器S1，...SM相关联。这样，m个请求链被创建。其优点在于来自不同开发器产品请求的多个请求被请求调度程序视为一个语义单元，该请求调度程序减轻了解决独立请求与相同资源之间以及各不同资源之间的相互依赖关系的难题。

指向左侧的箭头表示大量支持器S通过所说被标准化的接口和请求调度程序将数据写到请求资源库18中，以便将系统资源的任何动作及其影响报告到登录文件中，登录文件在图1中未表示出来。

实际系统资源12、14、16的操作是仅由支持器实现的，这用支持器和资源之间的箭头表示。

通用的支持器/开发器资源库17可被支持器使用，以产生输出信息，这些信息可由开发产品或在用户化期间由配置开发产品的用户化产品读取。作为一个特例，请求资源库和通用的支持器/开发器资源库能在相同的技术中被结合起来(例如，基于LDAP的目录)。

应该注意到，根据本发明，用于连接大量请求以及重新组织它们的发明方法能有利地被应用在大量应用程序即开发器产品被安装到硬件系统中的情况下，因为发明概念允许在系统中被真正执行之前检测系统资源被请求的状态的效果。

在相同的情况下，“UNDO”(撤消)功能可被执行，该操作逆转在前述的操作系统资源改变期间对系统资源所作的全部改变。

现在参看图2A和B，对包括大量发明方法特征的控制流程的总体想法将在下面得到更详尽地说明。

作为预备步骤，不必要在第一步210中包含发明概念，而要准备对包括由大量请求程序请求的并行请求的适应性进行连接，即连接请求被存储在资源库中。

在步骤220中，发明请求调度程序工具经由EVALUATE(评估)选项被调用。该评估步骤使得支持器能读取用编址的这些支持器的各个请求的内容，并确定是否还能再作些工作以改进这些请求。为了实现这种请求的改进，要使支持器本身产生对一个或多个不同支持器编址的请求。那些请求也被存储在请求资源库中。

应当了解，在评估步骤中所有的请求都被各自的支持器处理，在评估步骤结束时，所有的支持器被彻底地处理过。这些在包括大量支持器的外层程序循环中和包括被访问到支持器的所有请求的第二内层循环中实现。

在步骤230中，请求资源库18可被系统管理员浏览，并且抵触请求在处理过程早期已被识别出来。

在步骤240中连接步骤被调用。

尤其，连接步骤被分割成至少两个不同的部分：在步骤250中执行的第一部分和依赖于步骤250的结果而决定步骤260或步骤270哪个将被执行的第二部分。

尤其，在步骤250中，大量不同请求的相容性被检测。检测意味着各支持器被询问是否它能够服务被访问它的所有请求。根据这一特征，识别独立请求不能得到服务的情况是很有可能的，而且——如果各个请求属性告诉支持器该请求被要求——终止系统的改变以便保持正确地系统运行而不冒险产生由不能被服务的请求而引发的系统问题，也是很可能的。这样，如果请求相容性为OK(是)，决定252生成；否则，就不生成。在结果为NO(否)的分枝中——步骤254，测试容易得到终止而并不产生系统改变。这样，系统始终保持未改变。然而，在结果为YES(是)的分枝中，系统管理员被询问是否他想要执行改变，还是他想要模拟改变的执行。256中的各个决定在图2中被说明。在YES(是)的分枝中，系统资源的改变被执行，但在步骤260中它们却处于非激活状态。然而，在步骤270中改变的执行仅仅被模拟。

模拟方针允许终端用户执行连接和激活而并不真正地影响资源，因为在这种模式下任何支持器将执行细节写到所说登录文件中而并不更新资源。这样，模拟比前面提到过的检测预期的系统改变是否是有用的特征更多——因为在这方面该工具的答案仅仅包括是和否。在模拟步骤中，所有的细节都能从登录文件中被追踪回来。

在步骤280中，在转换执行完成后，所有的请求能再一次被系统管理员浏览并控制。

在步骤290中——步骤290被在命令行中具体化ACTIVATE(激活)选项的发明工具的新调用所调用，被实现的变化的激活过程被调用。该步骤反映了发明方法的重要优点，在变化执行完后的任意时刻都可执行该步骤，因此可以由系统管理员自由地确定。这样，激活步骤可以发生在步骤260执行完例如几个星期或几个月之后。

参考图2B，在激活之前，请求的相容性在步骤300中再一次被检测。在步骤310中确定检测的成功与否。如果不成功，使用户能浏览登录文件并编辑它以便手动地更正潜在的错误，这是步骤320。随后相容性将再次被检测。或者，在步骤310的“YES”(是)分枝上，用户必需确定在步骤330是否他想要执行激活，或者是仅仅在步骤335中模拟激活。在模拟状态下，控制被反馈回步骤300中以再次检测请求的相容性，或者，另一种情况，控制被反馈到步骤320中以手动纠正一些错误。在步骤330的YES(是)分枝上，激活在步骤340中被实际地执行。尤其，在步骤260中被执行完的改变被激活，这意味着激活的系统资源状态根据存储在资源库18中的请求确实得到了改变。在步骤350中，用户被通知成功的实现激活，随后该工具终止。

应当注意到，模拟激活请求的行为与连接请求的模拟是相似的。支持器将激活动作的细节写到登录文件中而并不影响执行。

图2整体上表示了发明的请求调度过程方法是模块化结构，这些模块可以被独立地处理和调用，参考步骤220、240、290。不同模块的处理过程在这里作为发明工具的调用实现，而各不同的调用选项经由命令行接口被执行。其它接口，例如GUI接口，或面向批量的调用也能实现。

参考图3，支持器执行和登录仅仅通过参考执行和登录一个支持器所必需的步骤而被更详尽地说明。支持器执行和登录的整个任务在包括所有支持器的循环中被有利地实现。

在第一步510中，请求调度程序访问请求资料库18以便获取调用支持器所必需的数据，尤其是支持器的名称，如何调用它以及其它在这里不相关的细节信息。该支持器信息可能包括资料库18，而它也可以位于任何地方。此外，所有连接请求被读取，以便准备好使它们能被现行循环操作内实际相关的支持器程序可存取。

在下面的步骤520中，所有的请求被依次地注册到登录文件中，即上面提到的XML文件，以便追踪哪个请求已被执行、哪个支持器被寻址。

在下面的步骤530中，执行与现有循环操作相关的支持器的特定进入点。如果激活请求确实存在——回去参考图2B中步骤340——支持器执行实际工作以激活预先定义的系统资源的新状态。支持器执行的所有动作被写入到登录文件中以便使系统管理员能保持对被执行的所有系统改变的全面了解。

在下面的步骤540中，执行请求的结果以能反映请求状态的返回代码的形式被写入到与定义请求属性的存储结构相关的存储位置。这样，“请求成功实现”或“请求失败”等的标记被存储。

在下面的步骤550中，由请求调度程序执行的完整登录，即所有被认为是控制前述的动作所必需的信息被写入到登录文件中以便能被系统管理员追踪。

对于其余的所有支持器，步骤510到550中的序列被重复，直到所有支持器根据静态支持器顺序关系已被处理。

在前述的详细说明中，参考特定的例示实施例发明得到了说明。然而，显而易见的是各种修改和变化可被实现而并不背离将在附加权利要求中提出的发明的广义和范围。因此，这些详细说明和附图应被看成是说明性的，而不具有限制意义。

本发明能在硬件中、软件中或软硬件结合的系统中实现。根据本发明，请求调用程序工具能在一个计算机系统中以集中的方式被实现，或在不同组件被分布在几台互连的计算机系统中的情况下以分布的方式实现。任何类型的计算机系统或其它用来执行这里描述的方法的设备都是适合的。软硬件的典型结合可以是一个通常用途的计算机系统，其上的计算机程序当被加载和被执行时控制计算机系统以便它能执行这里描述的方法。

本发明也能被嵌入到计算机程序产品中，这种产品包括所有能使这里说明的方法实现的特征，并且当载入到计算机系统中时能执行这些方法。

本文中的计算机程序方法和计算机程序意味着一组指令的任何类型语言的表达、代码或符号，这组指令要使具有信息处理能力的系统直接地执行特定的功能，或在执行完以下两种之一或全部之后执行特定的功能：

a)转换为另一种语言，代码或符号；

b)不同资料形式的再现。

Claims

1.支持自动管理支持器自身的资源(12、14、16)的方法，包括下列步骤：

存取(510)包括请求的资源库(18)，各请求定义了应被执行的动作，或一个应达到的预期的状态，该状态与各自的资源(12、14、16)相关联；

重新组织(520)所述请求；

调用(530)管理程序方法的资源以处理所述请求的链。

2.根据权利要求1的方法，其中所述请求定义了由操作系统维护的资源(12、14、16)的预期状态，该方法包括下列步骤：

调用(220、240、260、290)支持器程序方法，以保证所述资源根据所述请求被设置。

3.根据权利要求2的方法包括：

将标准化接口(24)用于支持器程序的调用。

4.根据权利要求3的方法包括至少下列步骤之一：

检测(250、300)一个或多个请求之间的不相容性；

生成(220)一个或多个新的请求作为已存在的请求的子请求；

模拟(270、335)所述请求的执行；

执行(260)资源更新，并生成特定的激活请求；

使操作系统了解更新；

逆向前面所实现的更新。

5.根据权利要求4的方法，进一步包括下面的步骤：

生成用户可读取协议，其中记录根据所述步骤之一的执行结果以及所述资源的相应设置。