CN1668009B - 用于分发软件的更新分发系统的体系结构和方法 - Google Patents

Abstract

提出了一种用于分发软件更新的分层软件更新分发系统和方法。该更新分发系统包括一根更新服务节点和至少一个更新服务节点。在一更新分发系统中，除根更新服务节点之外，每一更新服务节点具有一个父更新服务节点。每一更新服务节点可担当对子更新服务节点的父更新服务节点。

Description

用于分发软件的更新分发系统的体系结构和方法

技术领域

本发明涉及软件和计算机网络，尤其涉及一种用于分发软件更新的更新分发系统的体系结构和方法。

背景技术

几乎所有可购买的软件产品都要经受连续不断的修订过程以修复或更新软件的特征。软件产品的每一修订经常要求添加新文件、用较新的修订替换现有文件、删除废弃文件或这些行动的各种组合。替换软件产品的较旧的文件、添加新文件、删除废弃文件、通过添加和/或删除功能改变软件产品的配置和行为的这一过程将在下文被称为“更新产品”，并且包括更新产品中使用的二进制文件、数据文件、更新指令、元数据等的数据集合在下文被较简单地称为“更新”。

一旦软件提供商创建了软件产品的更新，以解决问题、增强安全性或添加新特征，则软件提供商将希望令该更新对其顾客群广泛地可用。通常，如当更新针对纠正产品中的瑕疵或解决严重的安全问题时，软件提供商将希望更新被尽可能快地安装到顾客的计算机上。实际上，大多数软件提供商具有将软件更新尽可能快且无麻烦地分发到他们的顾客的商业动机。

计算机行业在连接到网络，尤其是因特网的计算机的数量上经历了爆发性的增长。由于这一爆发性的增长，并由于通过对因特网的连接可用的通信能力，因特网已经变为软件提供商用于向其顾客分发更新的重要且完整的渠道。实际上，因特网已经变成许多软件提供商用于向其顾客提供软件更新的主要分发渠道。软件提供商通常最感兴趣的是通过因特网分发软件更新，因为通过因特网的电子更新分发减少了其总成本，并使顾客在软件更新一旦可用时就能够获得它们。这些软件更新越来越频繁地通过因特网自动执行，而无需用户干预。

尽管因特网现在常用作从软件提供商分发软件更新的渠道，然而经常会出现一些问题。两个这样的问题包括(1)涉及更新分发架构/资源的效率，以及(2)对软件更新的分发和安装的管理控制。

对于分发资源的效率，网络，包括因特网，仅拥有有限量的通信资源，这通常被称为带宽。有限量的通信带宽通常导致瓶颈，尤其是对于流行软件产品的软件更新，如微软公司的家族操作系统和相关的生产产品。即使软件更新在遍及因特网分布的多个下载位置上可用，也会存在这类瓶颈。出现这类瓶颈的一个原因是因特网上可用的非结构化访问模型。例如，如果计算机A处的第一用户请求对软件产品的最新下载，该下载通过第一用户的独立服务提供商(ISP)。此外，该请求作为单个的、个别的访问来处理，这意味着该请求独立于，且不相关于任何其它网络话务和/或请求来处理。由此，如果恰巧具有相同ISP的计算机B处的第二用户请求与第一用户相同的下载，则来自第二用户的请求也被作为单个的、个别的访问来处理。在这一示例中，同一下载将通过同一架构发送两次，因为每一请求被单独地处理。很明显，如果用户数量有相当大的增加，有限的通信带宽将变为瓶颈。在这一相当常见的示例中，如果下载在本地位置上高速缓存，并且每一用户请求从本地高速缓存中得到满足，则将会更有效。

对于分发的控制，许多组织，尤其是大型组织，具有合法的理由来控制更新向其计算机的分发。例如，不幸的是，某些更新具有或引入“破坏”软件产品的特征的瑕疵，通常被称为程序错误。这些被破坏的特征可能是不重要的，但是它们过于频繁地弄乱企业的对任务关键的特征。可选地，如果移除了对任务关键的特征，或者其行为实际上由特定的软件更新改变了，它们可被“破坏”。由于企业无法负担丢失其对任务关键的特征，负责的企业在将更新发行到其剩余的计算机之前，将在某一段时间内在受控的环境中首先评估并测试每一软件更新。这一评估时间段准许组织确认更新是否会对任务关键的特征产生不利的影响。仅在令人满意地确定更新将不会贬损任务关键特征之后，才准许该更新被分发到组织的其它计算机。很明显，大多数组织必须行使对其计算机上的软件更新的安装的控制。

企业或组织经常需要控制软件更新的分发的另一原因是确保组织中计算机之间的一致性。信息服务部门具有所有计算机可在其上操作的标准化的目标平台是十分重要的，不论它是用于文字处理程序还是操作系统。如果没有标准，软件和计算机维护可能会不必要地复杂和困难。

本地控制重要的又一原因是用于记账目的。在大型组织中，个别地在计算机上安装软件，或对组织中的每一计算机个别地维护特定软件产品的许可证通常是低效的。相反，单个场地许可证(site license)准许组织在众多计算机上运行一个软件产品。由此，可要求组织报告在该场地许可证下运行产品的计算机的数量，或组织需限制在场地许可证下运行产品的计算机的数量。所有这些原因经常要求对软件更新分发的本地控制。

鉴于上述涉及软件更新分发的各种问题，需要一种用于提供对软件更新的分发的控制，以及提高其分发效率的可扩充软件更新分发体系结构。本发明解决了现有技术中这些和其它问题。

发明内容

依照本发明，提出了一种用于通过通信网络分发软件更新的软件更新分发系统。该软件更新分发系统包括一根更新服务节点，以及至少一个子更新服务节点。依照本发明的各方面，根更新服务节点和至少一个子更新服务节点用分级的方式来组织。根更新服务节点是至少一个子更新服务节点的父更新服务节点。除根更新服务节点之外，每一更新服务节点具有一父更新服务节点。每一子更新服务节点也可以是该软件更新分发系统层次中至少一个其它更新服务节点的父节点。另外，根更新服务节点从软件提供商处获取软件更新。至少一个子更新服务节点的每一个从其父更新服务节点处获取该软件更新。

依照本发明的其它方面，提出了用于向客户机计算机分发软件更新的更新服务节点和子更新服务节点。更新服务节点包括用于储存软件更新的更新存储。更新服务节点也包括一web服务接口，更新服务节点通过其从其父更新服务节点处获取软件更新，并且更新服务节点通过其向子更新服务节点分发软件更新。更新服务节点还包括一管理应用编程接口(API)，使用管理用户界面的管理员通过其建立用于向子更新服务节点分发软件更新的规则。更新服务节点还包括一子更新模块，用于依照所建立的规则确定哪些软件更新可用于分发到子更新服务节点。

依照本发明的另外一些方面，提出了一种软件更新系统中子更新服务节点用于从其父更新服务节点获取软件更新的方法。该子更新服务节点从其父更新服务节点处获取软件产品列表。该软件产品列表标识父更新服务节点为其分发软件更新的那些软件产品。子更新服务节点选择软件更新所搜寻的软件产品。子更新服务节点然后向标识所搜寻更新的那些软件产品的父更新服务节点提交请求。作为响应，子更新服务节点接收标识对子更新服务节点可用的所选择的软件产品的软件更新的更新列表。子更新服务节点然后从父更新服务节点处获取该软件更新列表中每一软件更新。

依照本发明的还有一些方面，提出了一种在父更新服务节点上执行的、用于向子更新服务节点分发软件更新的方法。从子更新服务节点接收请求软件更新目录的请求。向子更新服务节点返回标识父更新服务节点向其分发软件更新的软件产品的软件更新目录。然后接收对所选择的软件产品的软件更新列表的请求。作为响应，父更新服务节点确定所选择的软件产品的任何软件更新是否可用于子更新服务节点。向子更新服务节点返回标识被确定为可用于子更新服务节点的所选择的软件产品的那些软件更新的更新列表。该更新列表依照一唯一的更新标识符标识了可用的软件更新。接收请求对应于更新列表中标识的可用软件更新的元数据的更新请求，该更新请求标按其唯一标识符标识了可用软件更新。作为响应，向客户机更新服务节点返回更新元数据。更新元数据包括对应于软件更新的信息，包括用于获取对应的更新负载的参考。

附图说明

当结合附图阅读以下详细描述时，可以更容易且更好地理解本发明的上述方面和许多附加的优点，附图中：

图1是依照本发明的各方面形成的示例性更新分发系统的图示；

图2所示是依照本发明的各方面形成的更新服务节点的示例性逻辑组件的框图；

图3所示是依照本发明的各方面形成的根更新服务节点的示例性逻辑组件的框图；

图4所示是依照本发明的各方面，当从父更新服务节点向子更新服务节点提供软件更新时，父更新服务节点和子更新服务节点之间的示例性交换的框图；

图5所示是在子更新服务节点上执行的周期性地从其父更新服务节点处获取更新的示例性例程的流程图；

图6是适用于在图5的示例性例程的用于从父更新服务节点处获取更新目录的示例性子例程的流程图；

图7是适用于图5的示例性例程的用于从父更新服务节点处获取软件更新的示例性子例程的流程图；以及

图8是用于处理来自子更新服务节点的更新请求的示例性例程的流程图。

具体实施方式

依照本发明的各方面，提出了一种以分层方式组织的、用于分发软件更新的更新分发系统。为本发明的目的，如上所述，软件更新可涉及替换或删除较旧和/或废弃的文件、添加另外的文件、改变软件产品的配置等等。另外，尽管未特别地针对技术和文字意义上的软件产品的软件更新，然而本发明的各方面可有利地用于分发软件产品。因此，尽管以下描述是按照在更新分发系统中分发软件更新来作出的，但它仅为说明性的目的，并且不应当被解释为局限本发明。

图1是依照本发明的各方面形成的示例性更新分发系统100的图示。依照本发明，在诸如所示的更新分发系统100的更新分发系统的“顶部”的是一根更新服务节点102。诸如软件提供商110的软件提供商通过向根更新服务节点102提交更新，经由更新分发系统100分发其软件更新。依照本发明的各方面，诸如软件提供商110的软件提供商可通过网络，如因特网108向根更新服务节点102提交其软件更新。

诸如示例性更新分发系统100的分层更新分发系统可能包括除根更新服务节点102之外的至少一个其它更新服务节点。如图1所示，该示例性更新分发系统100包括根更新服务节点102和两个额外的更新服务节点：更新服务节点104和更新服务节点106。依照本发明，每一分层更新分发系统在根更新服务节点102下以树形结构来组织。换言之，更新分发系统中的每一更新服务节点具有零个或多个子更新服务节点。由此，尽管示例性更新分发系统100示出每一父更新服务节点(即，根更新服务节点102和更新服务节点104)仅有一个子节点，然而这仅为说明性目的，并且不应当被解释为局限本发明。此外，依照本发明的一个实施例，除根更新服务节点102之外，更新分发系统中的每一更新服务节点具有一个父更新服务节点。因此，如图1所示，更新服务节点104是根更新服务节点102的子节点，而更新服务节点106是更新服务节点104的子节点。在一个可选实施例中，子更新服务节点可从多个父更新服务节点(未示出)处接收更新。如可以见到的，除根更新服务节点102之外，每一更新服务节点既可以是子更新服务节点，也可以是父更新服务节点。

如示例性更新分发系统100中所示的，根更新服务节点102通过因特网108与更新服务节点104通信。然而，应当理解，这仅为说明性的，并且不应当被解释为局限本发明。更新分发系统中的每一更新服务节点只需能够通过某一通信网络与其父和/或子节点通信。由此，尽管更新服务节点104通过因特网108与其父节点-根更新服务节点102通信，它可选地可通过局域网124与其子节点，如更新服务节点106通信。

同样在图1中示出的，更新服务节点106驻留在局域网124的子网126中。作为一个示例，局域网124可对应于该组织的通用企业网络，并且更新服务节点104表示企业通过其对父节点-根更新服务节点102的连接链接到更新分发系统100。此外，子网126可对应于企业网络内可标识的计算机组，如测试/评估组、远程定位办公室或任务关键组。如下文将更详细地描述的，依照本发明的各方面，更新服务节点104上的管理员能够控制对更新服务节点106的更新分发，并最终控制对客户机的更新分发。

应当理解，每一更新服务节点，包括根更新服务节点102和更新服务节点104和106，被配置成向子更新服务节点和客户机计算机两者分发软件更新。如图1所示，示例性更新分发系统100包括客户机计算机112-122。每一更新服务节点，包括根更新服务节点102，依照本地配置信息向子更新服务节点和客户机计算机分发更新。依照一个实施例，管理员定义组，并将更新分发规则与那些组相关联。每一更新服务节点具有至少一个分发组。

作为示出更新分发系统如何操作的一个示例，假定局域网124对应于企业组织的企业网络。依照本发明的一个实施例，更新服务节点104的管理员可定义企业网络124的多个分发组，包括评估组，它对应于包括更新服务节点106和客户机计算机120和122的子网126，用于评估对通用企业网络124的更新的适合性；以及通用企业组，包括更新服务节点104和客户机计算机114-118。

对于评估组，管理员包括更新服务节点106作为成员，并将规则与该组相关联，使得一旦更新变得可用，它们就立即被分发到评估组的成员。可选地，对于通用企业组，管理员添加客户机计算机114-118，并关联规则，使得如果有管理员特别地授权，更新仅被分发到通用企业组的成员。也假定子更新服务节点106的管理员创建默认组，它由评估子网126中的客户机计算机120和122构成，可向其立即分发任何新的软件更新。

继续上述示例，软件提供商110向根更新服务节点102提交软件更新。依照在根更新服务节点102处建立的规则，更新最终被分发到企业更新服务节点104。在接收更新之后，其每一个的规则由管理员建立，企业更新服务节点104将更新分发到评估组的成员(仅被定义为子更新节点106)，但是保持来自通用企业组的更新直到向该组分发更新的特定授权。

继续上述示例，在接收更新之后，评估更新服务节点106处理对于每一定义的组的更新。在本示例中，评估更新服务节点106仅有一个组。然而，如上所述，在实际的实现中，可以定义多个组，每一组具有一套唯一的相关联的分发规则。对于本示例，评估更新服务节点106立即使更新变得可用于分发到客户机计算机120和122。客户机计算机120和122现在可以被更新，并且评估周期/过程可以开始。

继续上述示例，当企业更新服务节点104的管理员对该更新适用于通过整个企业网络124分发感到足够满意时，管理员然后明确地授权该更新被分发到通用企业组的成员。企业更新服务节点104相应地使该更新对客户机114-118可用。应当理解，评估更新服务节点106也可被包括在通用企业组中。然而，由于评估更新服务节点106已被更新，不需要额外的更新相关行动来将更新分发到评估子网126。

如可通过上述示例见到的，本发明提供了本地分发控制和下载效率方面的重要益处。除上述本地分发控制方面之外，也实现了通信带宽的重大节省。例如，尽管图1所示的示例性企业网络124包括五个客户机计算机，然而软件提供商的更新从根更新服务节点102下载到企业更新服务节点104仅一次。因此很明显，当由更新服务节点服务的客户机计算机的数量增加时，父更新服务节点和客户机更新服务节点之间的通信带宽使用保持不变，由此实际上减少了所使用的通信带宽量。另外，更新分发系统是可扩充且可伸缩的。更新分发系统在至少两方面是可扩充的：可向父更新服务节点添加任何数量的子更新服务节点，并且子更新服务节点也可以是父更新服务节点。因此，可以调整更新分发系统的每一子树以满足个别的需求。

本发明实现的另一益处是管理员在他所负责的客户机计算机和网络上建立并实施一致软件平台的简易性。例如，管理员确保客户机计算机上的一致软件平台的现有过程一般是：确定软件平台是什么，即，应当安装哪些更新而不安装哪些更新；确定每一客户机计算机上的软件平台的状态；以及将适当的软件更新推入客户机计算机中用于安装。即使在最初的努力之后，管理员必须频繁地重复该过程，以确保软件平台保持一致。与这些现有技术方法相反，通过使用上述更新分发系统，以及支持将客户机机器分组成不同的目标组的架构和使不同的更新以不同的目标组为目标(在下文描述)的能力，管理员可以为他所负责的网络和/或客户机计算机的软件更新安装指定期望状态。管理员通过一管理员API(也在下文描述)为任何数量的客户机计算机和/或客户机计算机组指定期望状态。一旦建立/指定了期望更新状态，管理员可依赖于更新分发系统来实施贯穿整个更新分发系统的更新分发。更新分发系统用于确保系统中的客户机符合由管理员指示的期望状态。通过周期性的行动，更新分发系统不断地试图使不符合期望状态的那些客户机计算机达到符合。另外，通过将特定的安装属性与软件更新相关联，诸如强制安装属性或最终期限安装属性，更新分发系统减轻了管理员与维护一致软件平台相关联的实现细节的相当大一部分的负担。将安装属性与软件更新相关联以控制客户机计算装置上的行为的更详细描述在2004年3月12日共同提交且共同转让的名为“控制客户机计算机上的安装更新行为(Controlling Installation Update Behaviors On a Client Computer)”，美国专利申请号10/799,336中有描述，该申请通过引用结合于此。

图2所示是依照本发明的各方面形成的更新服务节点200，如企业更新服务节点104(图1)或评估更新服务节点106(图1)的示例性逻辑组件的框图。如图2所示，更新服务节点200包括更新web服务202、客户机更新模块204、子更新模块206以及报告模块208。示例性更新服务节点200也包括验证/授权模块210、管理应用编程接口(API)212、更新内容存储214、管理员用户界面218和更新信息存储216。

更新web服务202提供了一组常见的web服务，客户机计算机、子更新服务节点和父更新服务节点可通过其与更新服务节点通信。例如，参考图1，为使子/评估更新服务节点106能够从父/企业更新服务节点104获得软件更新，客户机通过父节点的更新服务web服务202通信。类似地，当父更新服务节点，如根更新服务节点102具有传递到其子更新服务节点104的信息时，包括更新，父更新服务节点通过子节点的更新web服务202通信。

客户机更新模块204处理客户机计算机和更新服务节点200之间关于储存在更新服务节点上的更新和更新信息的通信。更新相关的通信包括，但不限于，响应于客户机请求分发更新并向客户机计算机提供可用软件产品和相关联的更新的列表。客户机更新模块204也负责确定客户机计算机是否被授权来依照相关联的分发规则获取特定的更新，并用客户机计算机被授权来访问的更新相关信息来响应客户机计算机。

子更新模块206处理父更新服务节点和其子更新服务节点之间的更新相关通信。更新相关通信包括，但不限于，标识对子更新服务节点可用的软件产品和相关联的更新的列表，以及响应来自子更新服务节点的更新请求。下游更新模块206负责确定子更新服务节点是否被授权来依照相关联的分发规则获取特定的更新，并用子更新服务节点被授权来访问的更新相关信息来响应子更新服务节点。

报告模块208生成更新相关报告，如哪些组已收到或尚未收到特定更新、哪些客户机计算机已下载/安装或尚未下载/安装更新、更新服务节点上有什么更新可用等等。这些报告可如由管理员内部地使用，并且也可通过父节点的更新服务接口202提交到父更新服务节点。如上所述，企业通常需要确定哪些客户机计算机安装了特定更新，比如为了记账目的或为了维护目的。由报告模块208生成的信息/报告可以是这些报告的基础。

验证/授权模块210负责验证，即确定特定客户机计算机或子更新服务节点的身份，并确定客户机计算机或子更新服务节点是否被授权来访问更新服务节点200上的可用更新。对于已被验证并被授权来访问更新服务节点上的更新的那些客户机计算机和子更新服务节点，验证/授权模块210签发必须结合获取更新一起使用的授权令牌。授权令牌的签发和使用在下文参考图4A和4B更详细地来描述。

管理API 212表示应用程序接口，通过其可行使更新服务节点200的控制，并且更新最终通过其来储存和分发。当更新web服务202从客户机计算机和子更新服务节点接收各种更新相关请求时，这些请求直接或间接地通过客户机更新模块204和子更新模块206被分解成对管理API 212的调用。结合管理用户界面218或安装在更新服务节点200上被合适地配置成使用管理API 212的某些其它程序，管理员最终控制该更新服务节点以及任何子更新服务节点和客户机计算机的更新过程的所有方面。

通过管理用户界面218，管理员可通过管理API 212配置并维护更新服务节点200。由此，通过管理用户界面218，管理员创建、修改、删除组，并关联每一组的规则。此外，使用管理用户界面218，管理员建立客户机计算机或子更新服务节点属于那一组。通过管理用户界面218，管理员也可明确地向客户机计算机或子更新服务节点授权更新的分发、配置更新服务节点200以周期性地向其父更新服务节点查询新更新、配置报告参数并察看内部报告等等。如上所述，尽管管理用户界面218准许管理员行使对更新服务节点200的各方面的控制，然而驻留在更新服务节点200上的另一应用程序也合适地适用于用管理API 212来操作，它可替代管理用户界面218来使用。

如上所述，依照本发明的一个实施例，更新服务节点200包括更新内容存储214和更新信息存储216两者。更新内容存储214储存表示软件更新的实际文件，如二进制和补丁文件。相反，更新信息存储216储存对应于更新服务节点200上可用的更新的信息和元数据，包括储存在更新内容存储214中的更新文件。依照一个实施例，更新内容存储214和更新信息存储216都是关系型数据库。尽管示出示例性更新服务节点200具有两个数据存储，本发明不应当被如此限制。在一个替换实施例中，更新内容存储214和更新信息存储216可在单个信息存储中组合。

依照本发明的各方面，即使更新不物理地储存在更新内容存储214中，也可向客户机计算机和子更新服务节点呈现软件更新为在更新服务节点200上“可用”。更具体地，与在更新服务节点200上立即下载并储存实际的更新文件相反，引用父更新服务节点或别处的更新文件的链接可被替代地储存在更新服务节点上。由此，如果客户机计算机请求更新，或子更新服务节点请求实际更新，然后从父更新服务节点上取出更新并储存在更新内容存储214中，以准备好将其传送到客户机计算机或子更新服务节点。本领域的技术人员认识到，这一类型的更新访问被称为及时下载(just-in-time downloading)。以这一方式，“可用”更新在它被实际请求之前不需要通过各种网络通道来分发。依照本发明的各方面，更新服务节点200的管理员可选择性地确定是否要以及时方式获取软件更新。

尽管图2的以上描述示出了示例性更新服务模块200的各种组件，然而应当理解，也可存在更新服务模块的其它组件。此外，上述组件应当被理解为逻辑组件，不必要为实际组件。在一个实际的实现中，依照实现确定，上述组件可以被组合在一起和/或与其它组件相组合。另外，应当理解，尽管更新服务节点200可被视为网络上的服务器计算机，然而在一个实际的实现中，更新服务节点可以在任何数量类型的计算装置上实现。例如，每一更新服务节点200可以在单个独立的计算机系统上实现和/或安装，或可选地在包括多个计算装置的分布式计算系统上实现和/或安装。

图3所示是依照本发明的各方面形成的根更新服务节点300，如图1所示的根更新服务节点102的示例性逻辑组件的框图。类似于更新服务节点200(图2)的逻辑组件，根更新服务节点300包括更新web服务202、子更新模块206以及验证/授权模块210。另外，示例性根更新服务节点300也包括管理API 212，更新内容存储214和更新信息存储216。可任选地，根更新服务节点300也可包括客户机更新模块204，报告模块208和管理用户界面218。

客户机更新模块204是根更新服务节点300的可任选组件，取决于根更新服务节点是否直接向客户机计算机提供软件更新。例如，参考图1，作为直接服务客户机计算机112的根更新服务节点，根更新服务节点102可包括可任选客户机更新模块204。然而，如果根更新服务节点300不直接服务客户机计算机，则可省略客户机更新模块204。

报告模块208对根更新服务节点300是可任选的，因为根更新服务节点没有向其提供更新报告的父更新服务节点。然而，在根更新服务节点的管理员需要更新报告的意义上，可任选地包括报告模块208。

除包含包括在更新服务节点200(图2)中的逻辑组件之外，根更新服务节点300也包括软件提供商接口302。软件提供商接口302提供通信接口，软件提供商110(图1)可通过其直接向根更新服务节点300提交软件更新，并间接向示例性更新分发系统100提交软件更新。

类似于图2的更新服务节点200，图3的以上描述示出了示例性根更新服务模块300的各种组件。然而，应当理解，也可存在根更新服务模块的其它组件。此外，上述组件应当被理解为是逻辑组件，不必要是实际的组件。在一个实际的实现中，依照实现确定，上述标识的组件可被组合在一起和/或与其它组件相组合。另外，应当理解，尽管根更新服务节点200可被视为网络上的服务器计算机，然而在一个实际的实现中，更新服务节点可在任何数量的计算装置上实现。例如，根更新服务节点300可以在单个单独的计算机系统，或可选地在包括多个计算装置的分布式计算系统上实现和/或安装。

为更好地理解如何遍及整个更新分发系统100从根更新服务节点分发更新，证明了父更新服务节点和子更新服务节点之间的一个示例性交换的说明。图4所示是依照本发明的各方面，父更新服务节点402和子更新服务节点404之间在从父更新服务节点向子更新服务节点传播软件更新时的示例性交换400。如可以见到的，该示例性图被划分成两半，左半边对应于父更新服务节点402的行动和事件，右半边对应于子更新服务节点404的行动和事件。

为参考图4来讨论的目的，还应当理解，父更新服务节点402可以是或不是更新分发系统100中的根更新服务节点。另外，为本讨论的目的，假定父更新服务节点402由管理员配置，使得子更新服务节点404在未被管理员明确地授权来接收软件更新之前无法接收软件更新。

如示例性交换400中所示的，在事件406开始，父更新服务节点402从软件提供商110处接收软件更新，如果父更新服务节点是根更新服务节点102，则直接接收，如果不是，则通过更新分发系统100间接接收。在父更新服务节点402从软件提供商110处接收软件更新之后的某一点，子更新服务节点404开始从父更新服务节点处获取软件更新的过程。

依照一个实施例，子更新服务节点404可被配置成在周期性的基础上从父更新服务节点202处自动获取可用的软件更新。更具体地，管理员可通过管理用户界面218选择性地配置子更新服务节点404，以在周期性的基础上自动获取父更新服务节点402上可用的最新的软件更新。作为一个示例，管理员可配置子更新服务节点404，以在每日和/或每小时的基础上从其父更新服务节点402处获取最新的软件更新，并可以指定开始自动更新过程的一天中的时间。也可使用其它周期性的时间表和准则。类似地，管理员可通过管理用户界面218来手动启动更新过程。

为开始更新过程，在事件408，子更新服务节点404向父更新服务节点402验证并授权其本身。向父更新服务节点402的验证和授权提供了对软件更新的分发的控制元素，从而将更新分发限制到授权的更新服务节点。验证和授权技术在本领域中是众所周知的，可采用任何数量的技术来向父更新服务节点402验证和授权子更新服务节点404。本发明不限于任何一个技术。

在正确地向父更新服务节点402验证和授权之后，在事件410，父更新服务节点402向子更新服务节点404返回授权令牌。依照一个实施例，授权令牌是对时间敏感的令牌，它向子更新服务节点404提供了授权，以在有限的时间量内对父更新服务节点进一步执行更新活动。由此，如果子更新服务节点404被不正确地向父更新服务节点验证和授权，则不会返回任何授权令牌，并且子更新服务节点无法执行任何其它更新相关活动，除验证和授权之外。类似地，在更新令牌超时之后，子更新服务节点404无法对父更新服务节点402执行任何进一步的更新相关活动，除重新验证和重新授权之外。

在接收授权令牌之后，在事件412，子更新服务节点404连同授权令牌一起向父更新服务节点提交对产品更新目录的请求。产品更新目录表示父更新服务节点402分发软件更新的软件产品的内容的列表或表格。

依照本发明的各方面，不要求子更新服务节点404传播其父更新服务节点402上可用的所有软件更新。例如，参考图1的示例性更新分发系统，企业更新服务节点104可具有对根更新服务节点102上可用的软件产品的仅一小部分的场地许可证。因此，企业更新服务节点104不必要获取根更新服务节点102上可用的所有软件更新，因为大多数更新从不使用。因此，更新服务节点的管理员可选择性地建立更新服务节点上哪些软件产品更新可用。除选择软件产品之外，管理员也可选择性地标识涉及软件产品的额外的、更具体的方面，以将更新过程中消耗的网络带宽量最小化。例如，除选择软件产品之外，管理员可选择性地为所选择的软件产品指定仅请求软件更新的英语版本。类似地，管理员可选择性地指定仅下载具有特定属性的软件更新。作为这些特定属性的一个示例，管理员可为所选择的软件产品仅请求安全相关的软件更新，或软件提供商110认为关键的那些软件更新。总之，依照本发明的各方面，管理员可依照软件更新的任何可标识的属性或方面为所选择的软件产品请求软件更新列表。

依照本发明的一个方面，从父更新服务节点402获得的更新产品目录标识了更新对其可用的所有软件产品，不论子更新服务节点404是否被配置成分发每一产品的更新。然而，依照本发明的一个替换方面，从父更新服务节点402处获得的更新产品目录仅标识了子更新服务节点被配置成向其分发更新的那些软件产品。例如，可依照子更新服务节点303所属的一个或多个组来确定限制哪些软件产品将在产品更新目录中列出。

在事件414，父更新服务节点402向子更新服务节点404返回产品更新目录。在事件416，子更新服务节点404从产品更新目录中选择当前需要最新更新的那些产品。应当注意，即使产品更新目录可能仅列出子更新服务节点404所分发的那些软件产品，然而子更新服务节点可被配置成在不同的时候或按不同的周期时间表获取不同软件产品的更新。

在事件418，子更新服务节点404连同授权令牌一起提交更新同步请求，它标识子更新服务节点当前正在搜寻其更新的所选择产品。同步请求中包括的是标识对子更新服务节点404上的产品可用的最新更新的信息。标识产品的最新更新的信息在下文被称为“更新锚(update anchor)”。每一软件产品的更新锚通常储存在更新信息存储216(图2)中。在一个实施例中，更新锚包括修订号以及与其相关联的日期。

响应于更新同步请求，在事件420，父更新服务节点402确定哪些新更新(如果有的话)对子更新服务节点404可用。如上所述，该确定基于与特定软件更新相关联的特定规则和子更新服务节点404是其成员的一个或多个组，以及更新锚。对于本示例，如上所述，先前接收的软件更新被明确地不对子更新服务节点404授权。因此，在事件406接收的软件更新不被确定为对子更新服务节点404“可用”。因此，在事件422，向子更新服务节点404返回一更新列表，而不标识在事件406接收的软件更新。依照本发明的各方面，更新列表依照同步请求标识了父更新服务节点402上“可用”的所有更新。在一个实施例中，更新列表用一与更新相关联的唯一标识符来标识每一“可用”更新信息。

在事件424，由于更新列表是空的，即，当前在父更新服务节点402上没有更新“可用”，则子更新服务节点404的更新过程简单地延迟或休眠一段确定的时间。依照当前示例，在延迟时段期间，在事件426，父更新服务节点402的管理员授权在事件406接收的软件更新可以被分发到子更新服务节点404。

在事件428(图4B)，子更新服务节点404再一次通过向父更新服务节点402验证和授权其本身来开始自动更新过程。作为响应，在事件430，父更新服务节点402向子更新服务节点404返回授权令牌。

在事件432，子更新服务节点404连同授权令牌一起向父更新服务节点402提交产品更新目录的请求。在事件434，父更新服务节点402向子更新服务节点404返回产品更新目录。在事件436，子更新服务节点404为期望更新的更新目录选择产品。在事件438，子更新服务节点404用授权令牌提交标识那些所选择的产品的更新同步请求。

由于子更新服务节点404被授权来获取先前在事件406处接收的软件更新，因此在事件440，父更新服务节点402确定该软件更新对子更新服务节点“可用”，并在更新列表中包括对应的更新信息。之后，在事件442，父更新服务节点402向子更新服务节点404返回更新列表，该更新列表现在标识在事件406处接收的软件更新。

由于具有标识在父更新服务节点402上“可用”的更新的更新列表，子更新服务节点404现在具有获取软件更新所需的信息。依照本发明的一个实施例，子更新服务节点404在以下两个部分从父更新服务节点402获取软件更新：获取更新元数据，以及获取更新内容或文件，下文称为更新负载。依照本发明的其它方面，更新元数据描述了软件更新的相关方面，包括但不限于：唯一地标识更新的更新标识符、与软件更新相关联的修订号信息、该软件更新是否应当被认为是优先级、语言专用信息、与其它软件更新的关系、用于下载目的更新负载的位置、安装处理程序例程等等。

通常用两个部分，即更新元数据和更新负载来下载整个软件更新是有利的某些原因是更新负载通常显著大于更新元数据，并且更新负载不总是立即需要的，即，需要用于安装到客户机计算机(如果在任何时候需要的话)。由此，依照本发明的一个实施例，更新负载与更新元数据分离地下载，并仅当需要时才下载。本领域的技术人员将认可这一下载技术为惰性下载(1azy downloading)，或可选地为及时下载。依照本发明的各方面，管理员可配置更新服务节点来以及时的方式，或在获取更新元数据之后立即获取更新负载。此外，在一个替换实施例中，更新元数据和更新负载可以共同下载。

如图4B所示，由于具有在更新列表中标识的更新，在事件444，子更新服务节点404依照更新列表中其唯一的标识符请求“可用”软件更新的更新元数据。对于与父更新服务节点402的大多数其它通信交换，更新请求与授权令牌一起提交。应当注意，尽管在所示的示例中，所有的更新元数据在一次访问中下载，然而依照本发明的替换方面(未示出)，更新元数据可以在一次以上访问中下载。例如，在第一次访问中，首先下载确定软件更新是否适用和/或合乎需要所需的更新元数据的仅一些元素，如适用规则和对其它软件更新的依赖性。然后，在确定更新适用和/或合乎需要之后，可获取更新元数据的剩余部分。作为响应，在事件446，父更新服务节点402向子更新服务节点404返回软件更新的更新元数据，子更新服务节点404进而将更新元数据储存在更新信息存储216中。

可任选地，在事件448，子更新服务节点404提交从父更新服务节点402下载更新负载的请求。作为响应，在事件450，父更新服务节点402向子更新服务节点404返回更新负载，子更新服务节点404进而将其储存在更新内容存储214中。在一个替换实施例中，子更新服务节点404从更新元数据中指定的位置的存储位置中下载更新负载，该存储位置可以不是父更新服务节点402。

由于现在在子更新服务节点404上发生了更新活动，因此在事件452，子更新服务节点生成更新报告，并将其提交给父更新服务节点402，该报告略述了最近刚发生的更新活动。之后，子更新服务节点404再一次延迟，直到下一次该更新过程被调度来运行(未示出)。

本领域的技术人员可以理解，上述事件用于说明目的，并反映了一组特定的示例性事件和环境。很清楚，依照特定的细节和情况，也可以出现其它事件，它们会导致对上述事件的某些变化。另外，应当理解，尽管子更新服务节点404从父更新服务节点402处获取最新的“可用”软件更新，然而子更新服务节点可以同时处理来自其子更新服务节点的更新请求。因此，上述事件序列应当被视为仅说明性的，并非局限本发明。

图5所示是在子更新服务节点，如图1的企业更新服务节点104上执行的，用于周期性地从其父更新服务节点获取更新的示例性例程500的流程图。在块502开始，子更新服务节点从父更新服务节点获取“可用”更新的经同步的更新列表。从父更新服务节点获取“可用”更新的经同步的更新列表在下文参考图6来描述。

图6是示例性子例程600的流程图，它适用于图5的示例性例程500，用于从父更新服务节点获取“可用”更新的经同步的更新列表。在块602开始，如上文相对于图4A和4B所描述的，子更新服务节点向父更新服务节点验证并授权其本身，并且响应于正确的验证和授权，接收一授权令牌。在块604，连同该授权令牌一起，子更新服务节点建立与父更新服务节点的通信参数。建立通信参数准许父和子更新服务节点正确地建立父节点和子节点都理解的公用基础。通信参数包括但不限于：通信更新协议或版本；产品分组；等等。

在建立了与父更新服务节点的通信参数之后，在块606，子更新服务节点获取描述父更新服务节点向其提供/分发更新的软件产品的产品更新目录。在块608，子更新服务节点选择当前正在搜寻更新的那些软件产品更新。在块610，子更新服务节点向父更新服务节点提交更新同步请求，包括授权令牌和与所选择的软件产品相关联的“锚”，它标识了已经在子更新服务节点上的现有修订和更新。

响应于更新同步请求，在块612，子更新服务节点从父更新服务节点获取更新列表、依照父更新服务节点上“可用”的软件更新来同步，“可用”是依照当前储存在子更新服务节点上的内容的。如上所述，更新列表用唯一的标识符标识了父更新服务节点上对子更新服务节点“可用”的那些软件更新。之后，示例性子例程600终止。

再次参考图5，在从父更新服务节点获取了经同步的更新列表之后，在判别块504，确定当前是否有任何软件更新“可用于”从父更新服务节点下载。这一确定是依照经同步的更新列表中是否有任何更新标识符来作出的。如果当前没有任何软件更新“可用于”下载，则示例性例程500前进到延迟块510，其中，示例性例程延迟/休眠，直到下一更新周期出现。可选地，如果有更新“可用于”从父更新服务节点下载，则在块506，子更新服务节点从父更新服务节点获取更新。从父更新服务节点获取“可用”更新在下文参考图7来描述。

图7所示是适用于图5的示例性例程500的、用于从父更新服务节点获取“可用”软件更新的示例性子例程700的流程图。在块702开始，选择更新列表中的第一更新标识符。在块704，子更新服务节点从父更新服务节点获取对应于所选择的更新标识符的更新元数据，并将其储存在更新信息存储216中。

依照一个实施例，在块706，子更新服务节点从父更新服务节点获取对应于所选择的更新标识符的更新负载，并将该更新负载储存在更新内容存储212中。可任选地，更新内容不需要直接被下载到子更新服务节点。如上所述，子更新服务节点可选择性地被配置成以及时的方式从父更新节点下载更新。依照该可任选处理，如图7所示，与从块704前进到块706相反，示例性子例程700可任选地从块704前进到判别块708。

在判别块708，在获取了所选择的更新标识符的更新元数据之后，并可任选地获取了更新负载之后，确定更新列表中是否有另外的更新标识符。如果有另外的更新标识符，则在块710，选择更新列表中的下一更新标识符，并且子例程700返回到块704以进行另外的处理。例程700继续，直到在判别块708确定更新列表中没有更多的更新标识符，在那时，示例性子例程700终止。

返回到图5，在从父更新服务节点获取了“可用”更新之后，在块508，子更新服务节点向父更新服务节点报告更新活动。之后，在延迟块510，示例性例程500延迟/休眠一段预定时间，直到下一更新周期，然后前进到块502以重复上述更新过程。

如图5所示，在判别块504，即使当父更新服务节点上没有任何更新“可用”时，子更新服务节点也可任选地被配置成向父更新服务节点报告其更新活动。依照这一替换配置，当没有更新可用时，示例性例程500可前进到块508，以报告更新活动。

图8是在父更新服务节点上实现的、用于响应于来自子更新服务节点的更新同步请求生成标识“可用”更新的经同步的更新列表的示例性例程800的流程图。在块802开始，父更新服务节点从子更新服务节点接收对标识“可用”更新的更新列表的更新同步请求。在块804，选择更新同步请求中标识的第一软件产品。

在判别块806，确定对标识的软件产品是否有任何可用更新。这一确定是依照储存在更新信息存储216中的软件产品的元数据、依照由子更新服务节点提供的更新锚、并依照与子更新服务节点所属的组相关联的分发规则来作出的。依照该确定，如果有更新“可用”，则在块808，与“可用”更新相关联的唯一更新标识符被写入更新列表中。在将“可用”更新的唯一更新标识符写入更新列表中之后，在块810，确定更新同步请求中是否标识了任何更多的其它软件产品。如果在更新同步请求中有另外的更新软件产品，则在块814，父更新服务节点选择更新同步请求中标识的下一软件产品，并返回到判别块806以确定对所选择的软件产品是否有“可用”更新。可选地，如果更新同步请求中没有标识更多的软件产品，则在块812，将更新列表返回到子更新服务节点。之后，示例性子例程800终止。

尽管示出并描述了本发明的各个实施例，包括较佳实施例，然而可以理解，可在不脱离本发明的精神和范围的情况下作出各种改变。

Claims (17)

1.一种用于通过通信网络分发软件更新以分发到客户机计算机的软件更新分发系统，其特征在于，它包括：

一根更新服务节点；以及

多个子更新服务节点；

其中，所述根更新服务节点和所述至少一个子更新服务节点以一分层方式组织，使得所述根更新服务节点是所述至少一个子更新服务节点的父更新服务节点，其中，除所述根更新服务节点之外的每一更新服务节点具有一父更新服务节点，其中，所述多个子更新服务节点中的每一个配置成作为另一子更新服务节点的父更新服务节点，且所述多个子更新服务节点中的至少一个子更新服务节点是所述多个子更新服务节点中的另一子更新服务节点的父更新服务节点；以及

其中，所述根更新服务节点从一软件提供商处获取软件更新，并且其中，所述至少一个子更新服务节点中的每一个通过从其父更新服务节点处获取所述软件更新来获取用于分发到客户机计算机的软件更新，

其中所述至少一个子更新服务节点中的每一个还包括一客户机更新模块，用于响应于客户机请求向客户机计算机分发软件更新，所述客户机更新模块根据相关的分发规则确定客户机计算机是否被授权获得特定的更新，所述客户机更新模块根据分发规则把软件更新分发到客户机计算机。

2.如权利要求1所述的软件更新分发系统，其特征在于，所述根更新服务节点包括：

一更新存储器，用于储存软件更新；

一更新web服务，所述根更新服务节点通过所述更新web服务经由所述通信网络向其子更新服务节点分发软件更新；以及

一软件提供商接口，软件提供商通过所述软件提供商接口经由所述通信网络向所述根更新服务节点提交其软件更新。

3.如权利要求2所述的软件更新分发系统，其特征在于，所述多个子更新服务节点中的每一个包括：

一更新存储器，用于储存软件更新；

一更新web服务，所述子更新服务节点通过所述更新web服务经由所述通信网络从其父更新服务节点处获取软件更新，并且所述子更新服务节点通过所述更新web服务经由所述通信网络向其子更新服务节点分发软件更新；

一管理应用编程接口API，管理员使用一管理用户界面通过所述管理应用编程接口API建立用于向其子更新服务节点分发软件更新的规则；以及

一子更新模块，用于依照所建立的规则确定哪些软件更新可用于分发到其子更新服务节点。

4.如权利要求3所述的软件更新分发系统，其特征在于，所述多个子更新服务节点中的每一个还包括：

一报告模块，用于生成并向所述父更新服务节点发送更新活动报告；以及

一验证和授权模块，用于确定一更新服务节点是否被授权来从所述子更新服务节点获取软件更新。

5.如权利要求4所述的软件更新分发系统，其特征在于，所述更新存储器包括一储存了所述软件更新的更新负载的更新内容存储器，以及一储存所述软件更新的更新元数据的更新信息存储器。

6.如权利要求5所述的软件更新分发系统，其特征在于，所述子更新服务节点通过从所述父更新服务节点获取所述软件更新的更新元数据，并从所述父更新服务节点单独地获取所述软件更新的更新负载，来从所述父更新服务节点获取所述软件更新。

7.如权利要求6所述的软件更新分发系统，其特征在于，所述子更新服务节点在被请求时从所述父更新服务节点获取所述软件更新的更新负载。

8.如权利要求4所述的软件更新分发系统，其特征在于，所述分发规则由管理员使用所述管理用户界面通过所述管理应用编程接口API来建立。

9.如权利要求8所述的软件更新分发系统，其特征在于，所述根更新服务节点还包括一客户机更新模块，用于向客户机计算机分发软件更新。

10.如权利要求3所述的软件更新分发系统，其特征在于，所述子更新服务节点可选择性地被配置成周期性地从所述父更新服务节点获取可用软件更新。

11.一种用于向客户机计算机和子更新服务节点分发软件更新的更新服务节点，更新服务节点以多个相似配置的更新服务节点的分层结构组织，所述更新服务节点包括：

一更新存储器，用于储存软件更新；

一更新web服务，所述更新服务节点通过所述更新web服务经由一通信网络从一父更新服务节点获取软件更新，并且所述更新服务节点通过所述更新web服务经由所述通信网络向所述分层结构中的子更新服务节点分发软件更新；

一管理应用编程接口API，管理员使用一管理用户界面通过所述管理应用编程接口API建立用于向其子更新服务节点分发软件更新的规则；

一子更新模块，用于依照所建立的规则确定哪些软件更新可用于被分发到其子更新服务节点；以及

一客户机更新模块，用于响应于客户机请求向客户机计算机分发软件更新，所述客户机更新模块根据相关的分发规则确定客户机计算机是否被授权获得特定的更新，所述客户机更新模块根据分发规则把软件更新分发到客户机计算机。

12.如权利要求11所述的更新服务节点，其特征在于，它还包括：

一报告模块，用于向所述父更新服务节点生成更新活动报告；以及

一验证和授权模块，用于确定一子更新服务节点是否被授权来从所述更新服务节点获取软件更新。

13.如权利要求12所述的更新服务节点，其特征在于，所述更新存储器包括一储存所述软件更新的更新负载的更新内容存储器，以及一储存所述软件更新的更新元数据的更新信息存储器。

14.如权利要求13所述的更新服务节点，其特征在于，所述更新服务节点通过从所述父更新服务节点获取所述软件更新的更新元数据，并从所述父更新服务节点单独地获取所述软件更新的更新负载，来从所述父更新服务节点获取所述软件更新。

15.如权利要求14所述的更新服务节点，其特征在于，所述更新服务节点在被请求时从所述父更新服务节点获取所述软件更新的更新负载。

16.如权利要求12所述的更新服务节点，其特征在于，所述分发规则由管理员使用所述管理用户界面通过所述管理应用编程接口API来建立。

17.如权利要求11所述的更新服务节点，其特征在于，所述子更新服务节点可以被选择性地配置成周期性地从所述父更新服务节点获取可用软件更新。

Images