现代计算技术导致了非常复杂和不断变化的环境。一种这样的环 境就是Internet，也称为“因特网”。Internet是通过网关连接在一起的 一组计算机网络，这些计算机网络有可能不同，所述网关用于处理数 据传输，并将消息从发送网络的协议转换到接收网络所使用的协议。 术语“Internet”主要指使用TCP/IP协议族的网络和网关的集合。目前， 通过Internet传输数据的最常用方法是利用万维网环境，也将其简单 地称为“Web″。还存在用于传输信息的其他Internet资源，例如文件 传输协议(FTP)和Gopher，但还达不到Web那样普及。在Web环 境中，服务器和客户机使用超文本传输协议(HTTP)进行数据事务， HTTP是用于处理各种数据文件(例如，文本，静止图像，音频，运 动视频等)传输的公知协议。通过标准页面描述语言，即超文本标记 语言(HTML)，将各种数据文件中的信息进行格式化，以便提供给 用户。Internet还广泛用于向使用浏览器的用户传输应用程序。软件 包的用户会经常通过Internet搜索和获取对那些软件包的更新。
其他类型的复杂网络数据处理系统包括为大型公司中便于工作 而创建的系统。在许多情形中，这些网络可遍布于世界各地的多处区 域。这些复杂的网络还可将Internet用作用于商业运营的虚拟产品网 络的部分。由于需要对网络内部使用的软件进行管理和更新，从而这 些网络更为复杂。
由多个松散连接的软件部件构成的这种环境通常有些脆弱。在这 些环境中，对于网络数据处理系统所涉及的软件部件，对其中一个软 件部件部署新版本就可能造成问题，且可能对于仅仅无关地 (tangentially)连接到被替换部件的整个系统的各部分造成深远和不可 预料的影响。即便危险性并不明显的改变也往往会造成不可预见和不 期望的负面影响。从而，由于这些深远的影响，系统管理员通常对于 执行诸如部件升级或较小的配置变化之类的更新极为谨慎。当信息系 统对于现代商业非常重要时，甚至数秒的机器故障时间也可能造成严 重的问题，而跟踪探测该故障时间可能花费远比数秒更多的时间。例 如，电子邮件服务器对许多企业提供重要的部件，这是由于这些服务 器促成在企业或组织内部和外部的用户之间的通信。导致电子邮件消 息传递错误的电子邮件服务器更新会对公司或组织造成生产率降低和 业务损失。
随着软件变得日益“自主”，对软件进行更新，配置和修补的任务 也将越来越多地由计算机本身执行，而不是由管理员来执行。当前的 更新机制趋于“自主”处理。例如，许多操作系统和软件包将基于某些 事件，例如定时器或由用户执行的一组特定动作而自动查找更新。更 新机制经常在预选位置处连接到Internet，以查看是否存在更新。如 果存在更新，则向用户发送消息，该消息向用户询问是否下载和安装 更新。下一个趋向于“自主”计算的步骤涉及识别和下载更新，而无需 用户的干预。因此，提供一种用于处理因软件的这种更新，重新配置 和修补造成的不期望或仅仅不可预料的影响的改进的方法，设备和计 算机指令，将是有益的。

本发明提供了一种用于更新软件部件的方法，设备和计算机指 令。判定是否要更新软件部件。当判定要更新软件部件时，更新软件 部件以形成更新的软件部件。自动测试更新的软件部件。响应当测试 更新的部件时出现的失败，执行校正动作。
本发明提供了一种在数据处理系统中的方法，用于更新数据处理 系统中包含的软件部件，所述方法包括计算机实现的步骤：判定是否 要更新该软件部件；当判定要更新该软件部件时，更新该软件部件以 形成更新的软件部件；由主更新管理部件跟踪涉及具体实现的信息； 建立测试策略，该测试策略根据涉及具体实现的信息指定多个测试中 的测试；识别用于软件部件更新的具体实现；选择所述多个测试中针 对该具体实现指定的测试，以形成选择的测试；自动地对所述更新的 软件部件执行所述选择的测试；建立错误过程策略，该错误过程策略 根据错误类型指定多个错误过程中的至少一个；当对所述更新的软件 部件进行的所述选择的测试中的一个测试失败时，判定发生的错误的 类型；选择所述多个错误过程中针对所述发生的错误的类型而指定的 错误过程；使用所述多个错误过程中选择的错误过程判定是否应执行 校正动作；当判定没有校正动作应被执行时，保持所述更新的软件部 件不被改变；以及当判定应执行校正动作时，根据所述多个错误过程 中选择的错误过程执行校正动作。
本发明提供了一种在数据处理系统中对网络数据处理系统中的 多个节点部署更新的计算机处理方法，所述计算机处理方法包括：从 网络数据处理系统内的多个节点中识别出具有需要更新的软件部件的 节点，以形成一组识别的节点；利用该更新来启动对该组识别的节点 的更新，以生成一组更新的节点；对该组更新的节点进行自动测试； 存储度量数据，该数据包含该组更新的节点的测试的结果；以及当该 组更新的节点中的节点出现测试失败时，执行校正动作。
本发明提供了一种更新软件部件的数据处理系统，所述数据处理 系统包括：第一判定装置，用于判定是否要更新该软件部件；更新装 置，当判定要更新该软件部件时，用于更新该软件部件以形成更新的 软件部件；第一跟踪装置，用于通过主更新管理部件跟踪涉及具体实 现的信息；第一建立装置，用于建立测试策略，该测试策略根据涉及 具体实现的信息指定多个测试中的测试；识别装置，用于识别用于软 件部件更新的具体实现；第一选择装置，用于选择所述多个测试中针 对该具体实现指定的测试，以形成选择的测试；测试装置，用于自动 地对所述更新的软件部件执行所述选择的测试；以及第二建立装置， 用于建立错误过程策略，该错误过程策略根据错误类型指定多个错误 过程中的至少一个；第二判定装置，用于当对所述更新的软件部件进 行的所述选择的测试中的一个测试失败时，判定发生的错误的类型； 第二选择装置，用于选择所述多个错误过程中针对所述发生的错误的 类型而指定的错误过程；使用装置，用于使用所述多个错误过程中选 择的错误过程判定是否应执行校正动作；当判定没有校正动作应被执 行时，保持所述更新的软件部件不被改变的装置；以及当判定应执行 校正动作时，根据所述多个错误过程中选择的错误过程执行校正动作 的装置。
本发明提供了一种对网络数据处理系统中的多个节点部署更新 的数据处理系统，所述数据处理系统包括：标识装置，用于从网络数 据处理系统内的多个节点中识别出具有需要更新的软件部件的节点， 以形成一组识别的节点；启动装置，用于利用该更新来启动对该组识 别的节点的更新，以生成一组更新的节点；测试装置，用于对该组更 新的节点进行自动测试；存储装置，用于存储度量数据，该数据包含 该组更新的节点的测试的结果；以及执行装置，当该组更新的节点中 的节点出现测试失败时，用于执行校正动作。
附图说明
在所附权利要求中给出了认为是本发明特征的新颖特性。不过， 结合附图，参照后面对示意性实施例的详细描述，将更好地理解本发 明本身，和所使用的优选实施方式，以及其他目的和优点，其中：
图1示意性地表示可实现本发明的数据处理系统的网络；
图2表示根据本发明优选实施例实现为服务器的数据处理系统的 框图；
图3表示可实现本发明的数据处理系统的框图；
图4表示根据本发明优选实施例对软件部件进行更新时所使用的 部件的图例；
图5表示根据本发明优选实施例的自主更新中所使用的部件的图 例；
图6表示用于根据本发明优选实施例执行自主更新的过程的流程 图；
图7表示用于根据本发明优选实施例执行自主更新的过程的流程 图；
图8表示用于根据本发明优选实施例执行自主更新的过程的流程 图；而
图9表示用于根据本发明优选实施例修改自主更新的过程的流程 图。

现在参照附图，图1示意性地表示可实现本发明的数据处理系统 的网络。网络数据处理系统100为可实现本发明的计算机网络。网络 数据处理系统100包含网络102，网络102是用于在网络数据处理系 统100内连接在一起的多个设备和计算机之间提供通信链路的介质。 网络102可包括诸如线缆，无线通信链路或光缆之类的连接。
在所述示例中，服务器104与网络102连接，并且与存储单元106 连接。此外，客户机108，110和112也与网络102相连。这些客户机 108，110和112可为例如个人计算机或网络计算机。在所述示例中， 服务器104向客户机108-112提供数据，如引导文件，操作系统映像 和应用程序。客户机108，110和112为服务器104的客户机。服务器 104可为客户机(如客户机108，110和112)提供更新源。在这些示 例中，网络数据处理系统100包含自动计算特性，如更新在网络数据 处理系统100内使用的软件部件的特性。具体地，可在无需用户干预 以获取和安装更新的情况下对软件部件进行更新。这些更新可包括例 如对软件部件的可执行文件的更新，对软件部件的新可执行文件或数 据文件的更新，或甚至对软件部件的配置文件的改变。网络数据处理 系统100可包括另外的服务器，客户机，以及其他设备，在此未示出。
在所述示例中，网络数据处理系统100为Internet，其中网络102 表示彼此使用传输控制协议/网际协议(TCP/IP)协议族进行通信的 网络和网关的世界范围集合。Internet的核心为主节点或主机(由成 千上万个对数据和消息进行路由的商业，政府，教育及其他计算机系 统组成)之间的高速数据通信线路的骨干网。当然，还可将网络数据 处理系统100实现为多个不同类型的网络，如企业内部网，局域网 (LAN)，或广域网(WAN)。图1意在作为示例，并不对本发明进 行体系结构限制。
参看图2，其中根据本发明优选实施例描述了可实现为服务器(例 如图1中的服务器104)的数据处理系统的框图。数据处理系统200 可以是包括与系统总线206相连的多个处理器202和204的对称多处 理器(SMP)系统。或者，可以采用单处理器系统。存储器控制器/ 高速缓存208也与系统总线206连接，并为局部存储器209提供接口。 I/O总线桥(bus bridge)210与系统总线206相连，并为I/O总线212 提供接口。如图所示，可将存储器控制器/高速缓存208与I/O总线桥 210集成。
连接到I/O总线212的外围部件互连(PCI)总线桥214提供针 对PCI局部总线216的接口。若干个调制解调器可与PCI局部总线 216连接。典型的PCI总线设备将支持4个PCI扩展槽或内插(add-in) 连接器。到图1中客户机108-112的通信链路可通过经由内插板 (add-in board)与PCI局部总线216相连的调制解调器218或网络 适配器220来提供。
附加的PCI总线桥222和224提供针对附加PCI局部总线226 和228的接口，由此可支持附加的调制解调器或网络适配器。通过这 种方式，数据处理系统200能连接多个网络计算机。如图所示，还可 将存储器映射图形适配器230和硬盘232直接或间接地与I/O总线212 相连。
本领域技术人员可知，可以改变图2中所示的硬件。例如，还可 以使用其他外围设备，如光盘驱动器等，或者用这些设备添加到或取 代所述硬件。所述示例并不意味着对本发明进行体系结构限制。
在图2所示的数据处理系统例如可为IBM eSever系统(纽约 Armonk的IBM公司的产品)，该系统可运行先进交互执行程序(AIX) 操作系统或LINUX操作系统。
现参看图3，图3的框图表示可实现本发明的数据处理系统。数 据处理系统300表示客户机计算机的示例。数据处理系统300采用外 围部件互连(PCI)局部总线体系结构。尽管所示示例采用PCI总线， 不过也可使用其他总线体系结构，如加速图形端口(AGP)和工业标 准体系结构(ISA)。处理器302和主存储器304通过PCI桥308与 PCI局部总线306相连。PCI桥308还可包括处理器302的集成存储 器控制器和高速缓存。到PCI局部总线306的附加连接可通过直接部 件互连或内插板实现。在所示示例中，局域网(LAN)适配器310， SCSI主机总线适配器312和扩展总线接口314通过直接部件连接与 PCI局部总线306相连。相比之下，音频适配器316，图形适配器318 和音频/视频适配器319通过插入到扩展槽的内插板与PCI局部总线 306相连。扩展总线接口314为键盘和鼠标适配器320，调制解调器 322和附加存储器324提供连接。小型计算机系统接口(SCSI)主机 总线适配器312为硬盘驱动器326，磁带驱动器328和CD-ROM驱动 器330提供连接。
操作系统在处理器302上运行，用于对图3中数据处理系统300 内的多个部件进行协调和提供控制。操作系统可为市场上能够获得的 操作系统，如Windows XP(可从微软公司获得)。诸如Java的面向 对象编程系统可结合操作系统运行，并从在数据处理系统300上执行 的Java程序或应用提供对操作系统的调用。“Java”为Sun Microsystems公司的商标。操作系统，面向对象的操作系统，和应用 或程序的的指令处在存储设备上，如在硬盘驱动器326上，并且可将 其载入到主存储器304，以便由处理器302执行。
本领域技术人员可知，可以根据实现改变图3中所示的硬件。可 以使用其他内部硬件或外围设备，如快擦写只读存储器(ROM)，等 效非易失性存储器或光盘驱动器等，来补充或取代图3中所示硬件。 另外，本发明的处理可应用于多处理器的数据处理系统。
图3所示示例和上述示例并不意在对体系结构进行限制。例如， 除采用PDA的形式外，数据处理系统300还可为笔记本电脑或手持式 计算机。数据处理系统300还可为公共信息亭(kiosk)或Web电器。
现参看图4，图4表示根据本发明优选实施例对软件进行更新时 所使用的部件。这些部件可处在单个数据处理系统内部，或这些部件 中的一个或多个可处在一个或多个其他数据处理系统中。
在执行自动更新时，更新管理部件400利用数据库402。使用术 语“自主更新”表示使用软件过程没有任何用户干预地自动执行软件部 件的更新。该更新可包括例如对可执行文件的改变，对数据文件的改 变，添加新的可执行文件，添加新的数据文件，或改变配置。数据库 402包括可用更新(available update)404，测试信息406，安装信息 408和回退信息410。可用更新404包含有关对不同软件部件的更新的 消息，它可由更新管理部件400进行管理。该信息可包括例如通过版 本号所标识的当前可用更新，可标识更新的位置或路径，或实际更新 文件本身。该信息还可包括参与自主更新的不同数据处理系统的标识。 如果更新位于可用更新404之外，则这些更新可通过路径或位置信息 来定位。例如，在可用更新404内的更新信息可指向存储介质412， 该存储介质可由更新管理部件400访问。存储介质412可与更新管理 部件400位于相同的数据处理系统上，或可处在远程数据处理系统上。 该存储介质可采用多种形式，如硬盘驱动器，磁带或CD-ROM。
数据库402还包括可用更新404中列出的每个更新的测试信息。 在这些示例中，测试信息406指定在自主部署更新之后所要执行的零 或更多个测试。术语“自主部署”可与术语“自主更新”互换使用。在自 主更新后执行的测试可根据具体实现进行变化。测试可包括除用于确 定更新是否被正确安装的测试之外的测试。例如，在某些情形中，测 试可包括性能测试，单元测试，兼容性测试，或运行中(on-the-fly) 回归测试。单元测试涉及测试更大整体的一小部分。例如，针对正开 发的特定软件的各个对象进行软件单元测试，以检验这些对象是否响 应不同输入和输出而产生正确行为。在这些示例中，单元测试涉及对 特别相关于所应用更新的一个或多个部件进行测试。更新可为例如新 的程序文件，修改的程序文件，或配置改变。此类型测试从时间和影 响方面而言成本较低，并且在过程级别(course level)上验证对于某 些标准或基准(benchmark)而言该更新正有效执行。性能测试被用于确 定更新之后的系统性能是可接受的。可使用各种阈值和标准作为性能 测试的部分。可采用兼容性测试以确保更新部件按照与更新部件通信 的其他部件可接受的方式工作。回归测试为可用于确定更新部件是否 与旧部件等效工作的另一种测试。对于性能测试，如果软件部件未满 足某种度量(metric)或阈值，则即便已对软件部件成功部署更新， 该测试也失败。所执行的不同类型测试称为“自主”测试，这是由于在 执行更新后自动执行测试。执行这些测试不需要任何用户输入。在这 些示例中，由更新管理部件400执行自主测试。“自主”测试是不需要 用户输入或介入便可启动或执行的测试。换而言之，响应于更新刚好 发生而启动自动测试，其中不需要用户向数据处理系统提供用户输入 来选择或启动测试。是否执行测试以及执行什么样的测试取决于测试 信息406内的策略。例如，策略可指定如果更新是针对电子邮件服务 器的，则在部署更新后要执行性能测试。另外，所要采取的校正动作 可包括在测试信息406中。校正动作可包括例如回退更新，安装完全 不同的软件部件，或用不同的参数或选项重新安装更新。
此外，数据库402还包含安装消息408。在这些示例中，该安装 消息指定在使用特定更新安装或更新软件部件时由更新管理部件400 所使用的过程。回退信息410指定若更新要被回退则所要执行的过程。 更新的回退涉及移除更新，并将软件部件置回到其更新前的先前状态。 如果对更新的软件部件的测试结果为失败或某种特定错误，则根据本 发明的优选实施例执行这样的过程。在某些情形中，错误或许较小， 导致不执行回退而保留更新。在另外一些情形中，错误可能较严重， 导致更新管理部件400执行更新的回退。
安装数据库414是安装在特定数据处理系统上的软件部件和更新 的数据库。安装数据库414可包含一个数据处理系统或多个数据处理 系统的信息。安装数据库414可被更新管理部件400用来通过可用更 新404交叉引用该数据库中的信息，以识别可用于特定数据处理系统 的更新。其次，历史数据库416包含对数据处理系统做出的更新的历 史纪录。例如，该历史信息包括当每个更新均被部署时，已被部署到 数据处理系统的可用更新404中的更新的标识，以及对更新执行的测 试的测试结果。该数据库还可跟踪不止一个计算机的状态。此外，可 将更新测试后做出的判决以及根据测试结果所采取的任何动作存储在 历史数据库416中。通过历史数据库416，更新管理部件400可对更 新做出例如有关安装哪些更新以及何时安装更新的判定。更新管理部 件400使用的另一数据库是优选数据库(preference database)418。该 数据库包含用于控制更新管理部件400的操作的附加信息。例如，优 选数据库418可指定对于特定软件部件，不应安装最新的更新。从而， 该特定软件部件会一直使用当前可用更新之前的更新来运行。
在这些示例中，安装数据库414，历史数据库416和优选数据库 418可包含关于不止一个客户机数据处理系统的信息。例如，优选数 据库418可指定对于特定软件部件和特定数据处理系统，不应安装最 新的更新。从而，该特定数据处理系统会一直使用该特定软件部件的 当前可用更新之前的更新来运行。更新管理部件400还可跟踪除在数 据库402中所示信息之外的其他类型的信息。例如，可将与计算机过 去状态以及更新有关的信息存储在数据库402中。
现在参看图5，图5表示根据本发明优选实施例的自动更新中所 使用的部件。在该示例中，使用中央或主更新部件(如主更新管理部 件500)执行更新，从而对多个不同客户机(如客户机502和504)上 的更新进行管理。这些客户机包含辅助更新管理部件，例如，辅助更 新管理部件506和508。主更新管理部件500可处在服务器上，如处 在图1中的服务器104上，而辅助更新管理部件506和508可处在客 户机上，如在图1中的客户机108和110上。这些辅助更新管理部件 均管理其所在的客户机上的软件部件。
在该示例中，数据库510被主更新管理部件500访问，以控制可 用更新的自主更新，测试和回退。在这些示例中，可用更新在可用更 新512中。用于在客户机502和504上安装更新的信息在安装信息514 中，而在安装之后所要执行的测试在测试信息516中。如果测试失败， 则用于回退更新的过程在回退信息518中。
辅助更新管理部件506访问历史数据库520和优选数据库522， 而辅助更新管理部件508访问历史数据库524和优选数据库526。这 些辅助更新管理部件均会与主更新管理部件500联系以确定更新是否 可用于每个特定客户机。在检查可用更新时，可将有关安装的更新的 优选信息和历史信息从辅助更新管理部件506和辅助更新管理部件 508发送到主更新管理部件500。该检查的进行可基于某些事件，如周 期性事件(类似于定时器的到期)，或基于某些其他非周期性事件，如 软件部件的启动。更新的可用性存储在可用更新512中。
如果更新可用，则由主更新管理部件500从安装信息514获得用 于安装更新的过程，并将其发送到辅助更新管理部件506和508。响 应于接收到安装信息，辅助更新管理部件506和辅助更新管理部件508 将使用从主更新管理部件500接收的过程执行自主更新。安装更新之 后，辅助更新管理部件506和辅助更新管理部件508将使用通过主更 新管理部件500接收的来自测试信息516的测试信息，执行更新的测 试。如果测试成功，则软件部件继续操作。如果测试不成功，则通过 主更新管理部件500从回退信息接收回退过程。关于更新，测试和回 退的数据及其他统计信息存储在历史数据库520和历史数据库524中。
在该特定示例中，主更新管理部件500可跟踪附加信息，如关于 参与自主更新的计算机，用于执行测试的数据处理系统的标识，每个 软件部件的版本标识以及当前安装在计算机中的配置的信息，以及关 于可用于安装的软件部件的版本和配置的信息。另外，主更新管理部 件500还可跟踪有关在客户机上当前进行的更新和测试的其他信息。 该信息可包括例如当前更新的软件部件和所执行的任何测试的状态或 阶段。
在关键软件部件的情形中，可在具有相似或相同配置的新客户机 上执行软件部件的安装。例如，客户机502可为形成网络数据处理系 统关键部件的电子邮件服务器。当辅助更新管理部件506识别出电子 邮件服务器部件的可用更新时，识别出在其上要执行更新的另一客户 机。特别是，可由辅助更新管理部件508对客户机504进行更新，而 客户机502不进行更新。当在客户机504上对电子邮件服务器部件进 行更新并执行测试后，可将用户从客户机502转移或迁移到客户机 504。如果未出现失败或错误，则可逐步停止(phase out)客户机502， 客户机504可向用户提供电子邮件服务。如果出现错误，则可使用户 移回到客户机502。如果在更新后出现某些错误或失败，该过程提供 了附加的防故障机制。通过在第二数据处理系统上执行更新，同时保 持第一数据处理系统处于没有更新的状态，当在第二数据处理系统上 出现失败时，可快速使第一数据处理系统恢复服务。当然，该过程可 通过对软件部件的更新以及使用迁移进行控制的单个管理部件来执 行，如图4所示，而不采用如图5所示分布式结构。
现在参看图6，图6表示用于根据本发明优选实施例执行自主更 新的过程的流程图。如图6所示的流程可在更新管理部件(例如，图 4中的更新管理部件400)中实现。
流程以选择软件部件(步骤600)而开始。部件的选择可根据具 体实施方式而发生变化。在这些示例中，所选的部件可通过访问安装 数据库，例如图4中的安装数据库414来进行识别。安装数据库可标 识在特定数据处理系统上安装的软件部件。或者，软件部件可在特定 时刻(如当要执行更新时)动态识别。判定更新对于软件部件是否可 用(步骤602)。该更新可通过检查数据库，例如图4的数据库402 中的信息来进行。如果更新对于部件可用，则判定是否需要更新(步 骤604)。该判决可借助可在数据库，例如图4的历史数据库416和 优选数据库418中找到的优选和历史信息来实现。如果需要更新，则 部署更新(步骤606)。在部署更新后，判定部署是否成功(步骤608)。 如果部署是成功的，则判定是否测试更新(步骤610)。在某些情形 中，可不对更新执行测试。如果要对更新进行测试，则执行一个或多 个指定的测试(步骤612)。要运行的特定测试通过测试消息(例如， 在图4所示数据库402中所找到的测试消息406)来指定。执行测试 之后，判定对更新所执行的测试是否成功(步骤614)，如果测试是 成功的，则更新历史数据库(步骤616)。历史数据库为诸如图4所 示历史数据库416的历史数据库。写入到数据库中的信息包括关于更 新形式的信息，测试的结果，以及用于确定更新对软件部件的未来应 用的任何其他数据。接下来，判定是否存在其他未处理的软件部件(步 骤618)。如果不存在其他未处理的软件部件，则流程结束。
再次参看步骤618，如果存在其他未处理的软件部件，则流程返 回到如上所述的步骤600。回到步骤614，如果测试未成功，则执行校 正动作(步骤620)。对软件部件更新的回退可作为校正动作执行。 可执行的其他校正动作包括例如识别应用到软件部件的不同更新，或 加速全新软件部件的展开(roll out)以代替现有软件部件。例如，如 果对Web服务器进程的更新导致测试失败，可安装来自不同源的Web 服务器进程来代替当前的Web服务器进程，而不是将Web服务器进 程回退到其未更新状态。所要采取的具体校正动作可包括在数据库， 例如图4的数据库402中。如果执行回退，可从图4所示数据库402 的回退信息中识别用于回退更新的过程。此后，发送通知(步骤622)。 通知通常在没有进行更多尝试来重新应用更新时发送。通知通常发送 给管理人员。通知可通过多种通信机制发送，如电子邮件，寻呼机和 简单网络管理协议(SNMP)，其中流程进行到如上所述的步骤618。
回到步骤608，如果部署不成功，则判定是否重试更新部署(步 骤624)。如果要重复更新，则流程返回到步骤606。否则，流程进行 到如上所述的步骤622。在此情形中，通知指示在部署中出现失败。 通知可在多种类型的失败后出现，例如，当单个部署失败时，当对同 一目标的同一更新的两次或多次尝试部署失败时，或当对不同目标的 同一更新的两次或多次尝试部署失败时，或当对同一目标的两个或多 个不同更新的一次或多次尝试部署失败时。可根据具体实施方式将这 些通知记录在文件中或发送到管理员处。再次参看步骤610，如果不 执行测试，流程进行到如上所述的步骤618。在某些情形中，如果度 量表明不太可能出现失败，则不执行测试。如果不需要更新，则流程 也从步骤604进行到步骤618。再次参看步骤602，如果更新对部件而 言不可用，则流程也进行到步骤618。
现在参看图7，图7表示用于根据本发明优选实施例执行自动更 新的过程的流程图。如图7所示的流程可在辅助更新管理部件(例如， 图5的辅助更新管理部件506)中实现。
流程以向主更新管理部件发送消息(步骤700)而开始。该消息 包括有关更新是否可用以及是否应执行更新的查询。发送到主管理部 件的消息可包括诸如以下内容的信息：关于更新的优选信息和关于对 软件部件执行的最后更新的历史信息。接收对消息的响应(步骤702)。 消息指示是否要执行更新以及所要执行的任何更新的标识。该消息还 可包括诸如以下的信息：用于安装更新的过程，安装更新后执行的一 个或多个测试的标识，以及如果测试不成功，回退过程的标识。判定 是否要执行更新(步骤704)。如果要执行更新，则使用从主更新管 理部件接收的安装信息对软件部件执行更新(步骤706)。对部件进 行测试(步骤708)，并判定测试是否成功(步骤710)。如果测试成 功，则更新历史数据库(步骤712)，此后，流程结束。
再次回到步骤710，如果测试不成功，则执行更新的回退，以便 从软件部件中去除更新，并将软件部件置回到其先前状态(步骤714)， 此后，流程结束。再次参看步骤704，如果不需要执行更新，则流程 结束。
还可对图7所示步骤进行修改，以使得辅助更新管理部件能够被 主更新管理部件联系到。在此情形中，主更新管理部件告知辅助更新 管理部件什么更新是可用的。与在辅助更新管理部件对主更新管理部 件进行询问以确定更新是否可用的这些示例中所述的拉入模型(pull model)相对比，这样的配置属于推送模型(push model)。
现参看图8，图8表示用于根据本发明优选实施例执行自主更新 的过程的流程图。图8所示流程可在更新管理部件(例如，在图5中 的辅助更新管理部件506和在图4中的更新管理部件400)中实现。 在该示例中的流程用于对具有重要功能的软件部件执行软件更新。
流程以判定更新是否可用(步骤800)而开始。如果更新是可用 的，则判定是否需要更新(步骤802)。如果需要更新，则识别新的 系统(步骤804)。新系统为另一数据处理系统，将所述另一数据处 理系统配置成提供同更新管理部件所管理的软件部件相同的功能。例 如，如果软件部件为电子邮件服务器，则选择更新包含该软件部件的 另一数据处理系统。对新系统部署更新(步骤806)。测试对新系统 的更新(步骤808)，判定更新是否成功(步骤810)。如果更新成功， 将软件部件的客户移到新系统(步骤812)。在步骤812中，根据具 体实施方式，可将某些或全部客户移动到新系统。判定将客户移动或 转移到新系统后是否存在错误(步骤814)。如果存在错误，将客户 移回到旧系统(步骤816)，此后，流程结束。
再次参看步骤814，如果不存在错误，则逐步停止旧系统(步骤 818)，此后，流程结束。再次参看步骤810，如果更新不成功，则流 程结束。当然，根据具体实施方式，可执行附加尝试以实现更新。再 次参看步骤802，如果不需要更新，则流程结束。再次参看步骤800， 如果更新不可用，则流程结束。
现在参看图9，图9表示用于根据本发明优选实施例修改自主更 新的过程的流程图。图9所示的流程可在更新管理部件(例如，在图 5中的主更新管理部件500)中实现。
流程以检索关于更新的度量(步骤900)而开始。这些度量可从 历史数据库(例如在图5中的历史数据库520或历史数据库524)中 检索。这些度量可从单个客户机或节点，或者从网络数据处理系统中 的多个客户机或节点获取。这些度量包括诸如以下的数据：执行展开 的日期和客户机，发生回退的数据和客户机，以及关于更新的任何测 试和测试结果。对度量进行分析(步骤902)。根据具体实现，该分 析可采用各种形式。例如，可对度量进行分析以识别在特定类型或组 的软件实体，用户，硬件类型和操作系统之间的错误出现率之间的模 式和关联。使用该分析修改更新的部署(步骤904)，此后，流程结 束。该修改可采用各种形式。例如，可避免在更新很可能失败的数据 处理系统上进行更新的部署。该修改还可包括对很可能成功部署的数 据处理系统进行加速更新部署。修改还可包括停止更新部署或修改更 新。分析可导致这样的修改，其中，部署或进行附加更新以提高先前 更新的成功率。此外，根据在步骤902中识别的特定关联或模式，可 对管理员提供关联或模式的通知。
从而，本发明提供了用于自主更新软件部件的改进的方法，设备 和计算机指令。本发明的机制对软件部件进行更新，自动测试软件部 件以判定是否出现错误或故障，并且当在测试中识别出错误或故障时， 可将更新回退到先前的版本或采取某些其他校正动作。显然，本发明 的更新管理部件能够接收关于更新的进展和状态的信息，并基于该信 息作出判决。这些判决可囊括从简单(例如，判断是否回退升级以及 不尝试重新部署)到复杂(例如，判断是否部分回退升级-将其从升 级计算机的子集进行回退-以及对于按照某种相关度量而言与升级会 使测试失败的计算机相似的计算机，不尝试部署升级)的范围。因此， 显然看出，与没有更新管理部件的情况相比，更新管理部件的出现使 得能够基于更宽的可用数据集自动地进行更为复杂的判决。
出于进一步改进的目的，在另一优选实施例中，更新的显著成功 (按照一个或多个适当的度量而言)可加速对其他机器的更新部署。 在又一实施例中，度量的分析表明软件更新在某些环境中工作良好， 而在其他环境中并不好，并且分析可指示在更新运行不好的环境之间 的相似性-于是可继续对与更新失败的环境不具有相似性的机器进行 更新展开。在另一实施例中，当部件部署遇到问题时，可决定加速对 被认为可解决，或通过某些其他方式处理所检测出的问题的另一软件 部件的部署。另一可能的实施例具有这样的更新管理部件，即该更新 管理部件对许多计算机执行同样的更新，并且当在一些这样的计算机 上成功进行更新和测试之后，决定跳过该更新对其余计算机的部署的 某些或全部测试。
另外，本发明的机制可保持所有软件更新，展开，回退和测试的 度量，以识别在特定类型的软件实体，特定类型的用户，特定类型的 数据处理系统，和/或操作系统之间的错误出现模式。这些模式可通 过通常用于识别模式的不同统计分析来识别。多个数据处理系统上多 个更新的总体行为的某些示例包括这样一种模式，其中每次在运行特 定操作系统的机器上尝试更新时更新失败。在该情形中，在未来不应 执行对该特定操作系统的更新。另一示例为，每次将更新安装在特定 厂商的数据处理系统上时，更新失败。另一模式的示例为，当到第三 更新安装时，而其在第一更新后任何时候的安装都无法通过测试。另 一模式可为，例如，除非先安装第二更新，否则从来都不安装第四更 新。更细粒度的模式检测也可用于检测其他模式，例如，在性能或兼 容性方面的模式。这些模式可用于自适应修改更新的过程或更新处理 中的其他因素，以减少部署中错误以及所需回退的发生。例如，特定 模式可指示其中发生安装的方式的改变，或者在特定步骤或选项被识 别为导致测试故障或失败的情况下，指示更新选项的选择。通过该方 式，可避免在测试很可能失败的系统上进行部署或更新。此外，这些 识别可加速软件的部署，以对其他计算机进行更新。在所识别的模式 表明更新不太可能导致任何失败的情形中，这确实如此。此外，当模 式表明会出现许多失败时，可停止更新的部署。在其他情形中，模式 可表明应采用附加的更新以提高先前更新的成功率。该机制还可用于 以某种方式识别对更新的修改以增加随后更新的成功可能性。更新过 程可用于基于哪些先前更新已经执行或尚未执行来对模式(例如，在 其中某些安装会失败或不会成功出现的模式)进行自动测试和响应。 可通过改变过程来调整更新过程，以避免在测试或更新安装中出现失 败。
重要的是应注意，虽然针对全功能的数据处理系统描述了本发 明，然而本领域普通技术人员应该理解，本发明的处理能够以计算机 可读指令介质的形式以及多种其它形式分布，并且无论实际用于实现 分布的信号承载介质的具体类型如何，本发明同样适用。计算机可读 介质的示例包括可读类型介质，如软盘，硬盘驱动器，RAM，CD- ROM，DVD-ROM，和传输类型介质，诸如使用例如无线电频率和 光波传输的传输形式的数据和模拟通信链路，有线或无线通信链路。 计算机可读介质可采用编码格式的形式，该编码格式在具体数据处理 系统中为实际使用而进行解码。
本发明的描述是出于说明及描述目的，并不意在以所批露的形式 详尽列举出本发明或限制本发明。显而易见，本领域普通技术人员能 够易于想到多种修改和变形。所选及所述实施例是为了更好地说明本 发明的原理以及实际应用，并能够使本领域其他普通技术人员理解本 发明的具有各种修改的多种实施例，这些修改的实施例适用于他们所 想到的具体应用。
相关申请的交叉引用
本发明涉及以下申请：“Method and Apparatus for Publishing and Monitoring Entities Providing Services in a Distributed Data Processing System”，序列号10/252,816(代理受理号 YOR920020173US1)；“Composition Service for Autonomic Computing”，序列号10/252,324(代理受理号YOR920020181US1)； 以及“Adaptive Problem Determination and Recovery in a Computer System”，序列号10/252,979(代理受理号YOR920020194US1)；所 有申请均与本发明在同一天递交，转让给相同受让人，并在此引作参 考。