一种软件包的自动部署方法、装置和系统

摘要

本发明实施例公开了一种软件包的自动部署方法、装置和系统，其中，软件包的自动部署方法包括：从所订阅的与当前应用对应的聚合摘要Syndication Feed信息源中，获得Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的软件包的发布；根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署软件包；通过所述方法，应用服务器实现在无人工干预的情况下，完成当前应用相关的软件包的自动部署。

说明书

技术领域

本发明涉及软件管理领域，尤其涉及一种软件包的自动部署方法、装置和系统。

背景技术

目前对软件系统的自动化管理的要求越来越高，这主要包括软件系统的集中部署、自动化安装、升级、打补丁，版本管理以及补丁管理等；其中，软件部署和升级涉及客户端和后台应用服务端两部分；现有技术中，客户端部分的部署和升级是使用JWS(Java Web Star，Java网络启动)，即一种基于Java的应用程序，主要被用于客户端的零部署和自动化升级，包括：在每次系统重新启动时，检测是否有新的补丁需要安装；并需要预先在待部署客户端上安装一个木马程序；以及，后台需要一个Web服务器；

客户端使用JWS自动部署、升级客户端软件，而服务端的部署和升级目前是手工进行的，并且JWS技术不适用于服务器端软件的安装和升级，毕竟服务端的程序不可能经常重新启动；

发明人在实现本发明的过程中，发现现有技术中，服务器端软件部署、升级需要人工干预，效率低下。

发明内容

本发明实施例提供一种软件包的自动部署方法、部署服务器、应用服务器和软件包管理系统，以实现在无人工干预的情况下，完成软件包的自动部署。

一种软件包自动部署方法，包括：

从所订阅的与当前应用对应的聚合摘要Syndication Feed信息源中，获得Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的软件包的发布；

根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署相应的软件包。

以及，一种软件包信息的发布方法，包括：

接收应用服务器针对所订阅的与当前应用对应的聚合摘要SyndicationFeed信息源的查询请求；

如果该应用服务器所订阅的Syndication Feed信息源中包含更新的Syndication Feed信息，向该应用服务器返回所述更新的Syndication Feed信息，所述Syndication Feed信息用于反映与当前应用相关的软件包的发布。

以及，一种软件包管理系统，包括：

部署服务器，用于管理每个后台应用对应的聚合摘要Syndication Feed信息源，所述Syndication Feed信息源中包含用于反映与当前应用相关的软件包发布的Syndication Feed信息；

应用服务器，用于从所述部署服务器中获得所订阅的与当前应用对应的Syndication Feed信息源中的Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署相应的软件包。

以及，一种应用服务器，包括：所述应用服务器包括至少一个部署组件Bundle，每个部署Bundle对应一个应用，其中，所述部署Bundle包括：

订阅单元，用于从所订阅的与当前应用对应的聚合摘要Syndication Feed信息源中，获得Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的软件包的发布；

部署单元，用于根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署相应的软件包。

以及，一种部署服务器，包括：

服务通信单元，用于接收应用服务器针对所订阅的、与当前应用对应的聚合摘要Syndication Feed信息源的查询请求；订阅处理单元，用于在所述服务通信单元接收到该查询请求时，确定该应用服务器所订阅的Syndication Feed信息源中包含更新的Syndication Feed信息，并通过所述服务通信单元返回所述更新的Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的软件包的发布。

本发明实施例中，应用服务器从当前应用所订阅的Syndication Feed信息源中获得Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署软件包(补丁包或发布包)，从而实现在无人工干预的情况下，补丁包的自动升级、发布包的自动安装，减低了软件后期的升级维护所带来的成本压力。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例的软件包管理系统的结构示意图；

图2为本发明实施例所涉及的实体之间的关系示意图；

图3为本发明实施例一种软件包自动部署方法的流程示意图；

图4为本发明实施例一种软件包信息的发布方法的流程示意图；

图5为本发明实施例的一种软件包发布方法的流程示意图；

图6为本发明实施例的另一种软件包发布方法的流程示意图

图7为本发明实施例另一种软件包自动部署方法的流程示意图

图8为本发明实施例一种软件包自动部署方法的交互示意图；

图9为本发明实施例的应用服务器的结构示意图；

图10为本发明实施例的部署服务器的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

聚合摘要Syndication Feed技术是一种基于XML(Extensible MarkupLanguage，可扩展标记语言)的文档格式以及基于HTTP(Hyper Text TransferProtocol，超文本传输协议)的协议，它被站点和客户工具等用来聚合网络内容，包括杂志和新闻标题等。

本发明实施例提供一种软件包的自动部署方法、部署服务器、应用服务器和软件管理系统，其中，部署服务器采用Syndication Feed技术来发布用于反映新软件包发布的Syndication Feed信息；应用服务器获取与当前应用相关的Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署新软件包；注：这里的新软件包(亦可称为部署包)是指新增加的OSGI Bundle(Open Service Gateway Initiative Bundle，开放服务网关发起者组件)、原有OSGI Bundle的补丁包，OSGI Bundle的资源包，应当理解的是，新增加的OSGI Bundle指新增加的功能组件，就是发布包；原有OSGI Bundle的补丁包、OSGI Bundle的资源包是对原来已有的OSGIBundle进行打补丁的补丁包。

请参阅图1，为本发明实施例的软件包管理系统，包括：

部署服务器10，用于管理每个后台应用对应的聚合摘要Syndication Feed信息源，所述Syndication Feed信息源中包含用于反映与当前应用相关的软件包发布的Syndication Feed信息；

应用服务器20(20-1、20-2)，用于从部署服务器10中获得所订阅的与当前应用对应的Syndication Feed信息源中的Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署新软件包；这里的关键信息包括：软件包名称、版本信息和部署策略中的一种或多种。

以及，部署服务器10，进一步用于接收应用服务器针对当前应用对应的Syndication Feed信息源的订阅请求，所述Syndication Feed信息源中包含用于反映与当前应用相关的软件包发布的Syndication Feed信息；

部署服务器10，进一步用于根据上传的部署包相关信息生成或更新对应的Syndication Feed信息到相关的应用所订阅的Syndication Feed信息源中。一种实现下，即根据上传的部署包相关信息生成新的Syndication Feed条目到指定的频道Channel下，这里的Channel就是该应用所订阅的Channel。

以及，部署服务器10，进一步可以用于存放和管理上传的软件包；如图1所示的存量数据库50，应当理解的是发布包和补丁包可以统称为软件包，可见，通过部署服务器10存放和管理上传的软件包体现软件的集中管理功能。

在一种实现下，部署服务器10可以是一个B/S(Browser/Server，浏览器/服务器)结构系统，提供远程管理界面和远程软件包的上传能力，并能够根据上传的部署包相关信息生成对应的Syndication Feed信息。

以及，本发明实施例的应用服务器20中，每个应用服务器20上可以涉及一个或多个应用，每个应用对应部署有一个部署组件Bundle，部署Bundle预先向部署服务器订阅与当前应用关联的Syndication Feed信息源，该Syndication Feed信息源包含反映与当前应用相关的软件包的Syndication Feed信息，并且获取Syndication Feed信息源中与当前应用相关的Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的存量信息，下载并部署新软件包；

应当理解的是，部署Bundle是后台应用服务器中的一个逻辑实体，其本身也运行在OSGI框架内，作为整个后台服务基础平台的一部分发布的，其本身实现OSGI规范中的部署功能，其本身提供了Syndication Feed信息订阅、解析以及任务调度的能力。同时也提供对外的管理接口，包括目前操作的状态，部署包的存量信息等，这里的部署包的存量信息示例，如图1所示的存量数据库40中的记录。

可见，本发明实施例中，应用服务器20从部署服务器10中所订阅的、当前应用对应的Syndication Feed信息源中获得Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署软件包(补丁包或发布包)，从而实现补丁包的自动升级、发布包的自动安装；

以及，本发明实施例通过使用Syndication Feed信息发布机制、SyndicationFeed信息源订阅机制，实现部署远程监控，一站式管理，减轻了软件后期的升级维护所带来的成本压力。

请参阅图2，为本发明实施例所涉及的实体之间的关系示意图，如图2所示：

部署服务器，管理一个或多个软件包；

部署服务器，根据上传的部署包相关信息生成对应的Syndication Feed条目，由于其管理一个或多个软件包，而一个软件包对应一个部署包相关信息，故一个部署服务器维护一条或多条Syndication Feed条目；

部署Bundle，是后台应用服务器中的一个逻辑实体，一个部署Bundle对应一个应用服务(亦可称为应用)；一个部署Bundle订阅当前应用关联的一个Syndication Feed信息源，该Syndication Feed信息源中包含一条或多条Syndication Feed条目；

部署Bundle，下载、部署一个或多个软件包，其中，这里的软件包，即一个独立的jar文件，用于发布新的OSGI Bundle、原有OSGI Bundle的补丁包，OSGI Bundle的资源包，其命名方式以及内部的文件格式和内容要遵守OSGI规范。软件包一般包含如下几个部分：

META-INF/MANIFEST.MF文件，这是标准的JAVA指定文件；

新部署的OSGI Bundle，可以是多个；需要说明的是，一个应用涉及一个或多个功能组件，每个功能组件对应一个OSGI Bundle；

资源包，用于对指定的OSGI Bundle打补丁，也可以是多个，具体可以包括Bundle的私有jar和配置文件；

进一步的，如果软件包使用了数字签名，META-INF/*.SF，META-INF/*.DSA，META-INF/*.RS也包含在内。

请参阅图3，为本发明实施例的软件包自动部署方法的流程示意图，应用于应用服务器侧，如图3所示，包括：

S201、从所订阅的与当前应用对应的Syndication Feed信息源中，获得Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的软件包的发布；

其中，从所订阅的与当前应用对应的Syndication Feed信息源中，获得Syndication Feed信息可以包括：根据配置的统一资源定位符URL向部署服务器发送查询请求；接收所述部署服务器返回的更新的Syndication Feed信息。

S202、根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署相应的软件包。

本发明实施例的软件包自动部署方法中，进一步的可以包括：

S200、应用服务器向部署服务器订阅与当前应用对应的Syndication Feed信息源，该Syndication Feed信息源包含反映与当前应用相关的软件包发布的Syndication Feed信息。

进一步的，本发明实施例的软件包自动部署方法中，S202中所下载的软件包可以包括新增加的OSGI Bundle、原有OSGI Bundle的补丁包，OSGIBundle的资源包中的一种或多种。

可见，本发明实施例中，应用服务器从当前应用所订阅的Syndication Feed信息源中获得Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署新软件包(补丁包或发布包)，从而实现补丁包的自动升级、发布包的自动安装；即通过使用Syndication Feed订阅机制，实现部署远程监控，一站式管理，减低了软件后期的升级维护所带来的成本压力；

进一步的，由于软件包为OSGI bundle，所以部署时，无需中断系统的操作，如不需要重启系统即可完成部署。

请参阅图4，为本发明实施例一种软件包信息的发布方法的流程示意图，应用于部署服务器侧，如图4所示，包括：

S300、部署服务器为每个后台应用创建对应的Syndication Feed信息源；

S301、接收应用服务器针对所订阅的、与当前应用对应的聚合摘要Syndication Feed信息源的查询请求；

S302、如果订阅方应用服务器所订阅的Syndication Feed信息源中包含更新的Syndication Feed信息，向该应用服务器返回所述更新的Syndication Feed信息，所述Syndication Feed信息用于反映与当前应用相关的软件包的发布。

本发明实施例软件包信息的发布方法中，进一步可以包括：

S303、接收部署包相关信息；

第一种实现下，S303具体可以为接收上传的软件包和部署包相关信息，其中所述部署包相关信息包括软件包所对应的应用名称、软件包名称、版本信息和部署策略中的一种或多种；

第二种实现下，所述部署包相关信息为包含反映部署包相关信息的Syndication Feed信息的XML文本。

S304、根据所述部署包相关信息生成或更新对应的Syndication Feed信息到对应的应用所订阅的Syndication Feed信息源中。

针对S303的第一种实现，即根据所述部署包相关信息生成对应的Syndication Feed信息到该软件包对应的应用的Syndication Feed信息源中。

针对S303的第二种实现，即根据所述部署包相关信息更新对应的Syndication Feed信息到该软件包对应的应用的Syndication Feed信息源中。

针对S303的第一种实现，本发明实施例方法进一步包括：存放所述软件包；

以及，本发明实施例软件包信息的发布方法中，进一步可以包括：

S305、接收应用服务器针对当前应用对应的Syndication Feed信息源的订阅请求；应当理解的是，S305可以在S301之前执行。

可见，本发明实施例中，部署服务器通过使用Syndication Feed信息发布机制，即使用Syndication Feed技术发布反映新软件包的Syndication Feed信息到应用服务器所订阅的Syndication Feed信息源，从而实现了软件包的自动发布；进一步的，还实现了软件包的集中管理。

以及，本发明实施例通过采用Syndication Feed信息源订阅机制，实现向订阅方返回更新的Syndication Feed信息，所述Syndication Feed信息反映有新的软件包发布，实现部署远程监控，一站式管理，减轻了软件后期的升级维护所带来的成本压力。

下面为了更好的理解本发明实施例方案，分别从如下几个流程来进行介绍：

一、首次部署流程

系统首次部署时，管理员在部署服务器上为每个应用创建一个SyndicationFeed信息源，在一种实现下即一个应用对应有一个频道Channel，并对每个应用的部署Bundle配置URL(统一资源定位符，Universal Resource Locator)，使部署Bundle在系统启动后向部署服务器订阅与当前应用对应的SyndicationFeed信息源；之后，部署Bundle周期性的通过配置的URL来读取所订阅的Syndication Feed信息源中的Syndication Feed信息，一种实现下即部署Bundle周期轮询所订阅的频道中的Syndication Feed信息。

部署服务器可以支持多种Syndication Feed格式，包括RSS0.9(Rich SiteSummary0.9，富站点概要0.9)/RSS2.0(Really Simple Syndication2.0，真正简单联合2.0)和原子ATOM。系统可以使用一个统一的Syndication Feed模型，根据具体的需要转换成具体的RSS或ATOM模型。

二、软件包发布流程：

请参阅图5，为本发明实施例的一种软件包发布流程示意图，如图5所示，包括：

S411、维护人员操作Web客户端通过部署服务器提供的文件上传页面将软件包上传到部署服务器上，以及上传部署包相关信息；

这里的部署包相关信息包括但不限于：软件包所对应的应用的名称、软件包的名称(在一个应用中包名唯一)、版本信息和部署策略(如什么时候启动安装或升级)等。

S412、部署服务器完成上传软件包的存放，在一种实现下，如图4所示，部署服务器接收到维护人员上传的软件包后，向FTP(File Transfer Protocol，文件传输协议)服务器下发所述软件包，FTP服务器存储软件包；在另一种实现，部署服务器直接存放维护人员上传的软件包。

S413、根据部署包相关信息生成对应的Syndication Feed信息到为对应的应用所创建的Syndication Feed信息源中，其中部署包相关信息可以包括：软件包所对应的应用的名称(简称应用名称)、软件包的名称、版本信息和部署策略中的一种或多种。

如果当前上传的软件包名称与部署服务器维护的Syndication Feed条目中的一条Syndication Feed信息中软件包名称相同，则用生成的Syndication Feed信息更新。

可见，本发明实施例中，通过采用Syndication Feed技术实现用于反映新上传软件包的Syndication Feed信息的自动发布。

请参阅图6，为本发明实施例的另一种软件包发布流程示意图，如图6所示，包括：

S511、维护人员操作Web客户端上传软件包到FTP服务器上；

在一种实现下，即通过FTP的方式上传软件包到FTP服务器上；

S512、通过ATOM Publishing protocol/XML RPC(ATOM发布协议/XML远程过程调用)的方式将部署包相关信息以Syndication Feed的方式发布给部署服务器；

其中，将部署包相关信息以Syndication Feed的方式发布给部署服务器，可以是，反映部署包相关信息的Syndication Feed信息以XML文本表示，调用XML RPC接口发送该XML文本到部署服务器；

S513、部署服务器接收XML文本，更新对应的Syndication Feed信息；

使用这种方式要求部署服务器提供用于Syndication Feed信息变更的WebService(网页服务)接口。

应当理解的是，FTP服务器和部署服务器可以运行在一个物理实体上，如部署服务器提供了FTP的功能，或者FTP服务器和部署服务器可以为不同物体实体。

可见，本发明实施例中，通过采用Syndication Feed技术实现用于反映新上传软件包的Syndication Feed信息的自动发布。

三、软件包的自动部署阶段

应用服务器(部署bundle)基于系统启动后订阅了部署服务器中与当前应用相关的Syndication Feed信息源，一旦上传了新的软件包到部署服务器或FTP服务器，应用服务器通过定期查询部署服务器上所订阅的Syndication Feed信息源中的Syndication Feed信息，获得Syndication Feed信息中对应部分中的软件包名字和版本信息，与本地的部署包存量信息记录进行比较，根据比较结果下载软件包并部署；

请参阅图7，为本发明实施例软件包自动部署方法的流程示意图，应用于应用服务器，该应用服务器包括至少一个部署Bundle，每个部署Bundle对应一个应用，换句话说，即每个应用服务器实例中包括一个部署Bundle，如图7所示，包括：

S601、从部署服务器中所订阅的与当前应用对应的Syndication Feed信息源中，获得Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的软件包的发布；

S602、从该Syndication Feed信息中获取软件包名称，与所维护部署包存量信息进行匹配，如果在所维护的部署包存量信息中没有匹配到软件包名称相同的记录，则执行步骤S605；如果在所维护的部署包存量信息中匹配到软件包名称相同的记录，则执行步骤S603；

需要说明的是，从Syndication Feed信息中获取软件包名称，到部署包存量表中匹配，如果没有找到，就意味着这可能是一个新的部署；如果找到，就意味这可能是一个升级部署，需要进一步检测版本信息。

S603、进一步的比较版本信息，即将从该Syndication Feed信息中获取的第一版本信息与匹配的软件包名称相同的记录中的第二版本信息进行比较，如果第一版本信息(如2.1.2)优于第二版本信息(如2.1.1)，则确定当前应用存在一个新版本的软件包，执行步骤S604；反之，则确定上传的软件包是老版本的软件包，流程结束；

S604、根据该Syndication Feed信息，更新所维护的部署包存量信息中对应的老存量信息；

如图1所示，在一种实现下，所维护的部署包存量信息中的每条记录可以包括：软件包名称、版本信息和位置连接；即可以将第二版本信息更新为从该Syndication Feed信息中获取的第一版本信息；

S605、根据该Syndication Feed信息中的软件包名称、版本信息等，生成新的存量记录；

S606、根据该Syndication Feed信息中的软件包下载地址，如URL信息，下载新的软件包；

下载软件包可以使用HTTP协议也可以使用FTP协议。软件包下载地址(URL)在发布的Syndication Feed信息中给出。

S607-608、检查部署策略，根据该Syndication Feed信息中的部署策略，如部署包的时间策略，判断是否即时启动部署，当不是立即启动时，则执行步骤S609；当是立即启动时，则执行步骤S610；

例如，这里的时间策略为每天的后半夜2点开始部署；

由于一个bundle的起停(即安装发布包或升级补丁包)可能会引起其他bundle由活动状态转成reserve(保留)状态，所以需要根据实际情况调整不同的部署策略。

S609、启动定时器，当定时时长到达时，执行步骤S610；

S610、启动会话开始部署新的软件包；

这个过程由部署bundle发起，由OSGI框架提供的服务参与实施，包括启动会话、停止指定服务、更新资源、部署新的服务以及回滚功能。

应当理解的是：OSGI规范为网络服务定义了一个标准的、面向组件的计算环境。将OSGI服务平台添加到一个网络设备中，可以为其增加在网络的任何地方管理组件的生命周期的能力。软件组件可以从运行中被安装、升级或者移除而不需要中断设备的操作。软件组件可以动态的发现和使用其他库或者应用程序。

OSGI为动态扩充、修改系统功能和改变系统行为提供了支撑，在OSGI服务平台上可以部署许多OSGI的组件，即OSGI Bundle。OSGI有一整套完整的机制去实现动态改变系统行为，基于OSGI的系统运行时就可通过安装新的Bundle、更新或停止现有的Bundle来实现系统功能的插拔。可插拔、可动态改变行为从根本上保证了系统在运行期足够的灵活性和扩展性。

由于新的软件包(发布包或补丁)是OSGI bundle，所以部署时，不需要重启系统即可完成部署。

S611、记录部署结果；流程结束。需要说明的是，对于如上描述的流程中也可以不包括S611。

可见，本发明实施例中，从部署服务器中当前应用所订阅的SyndicationFeed信息源中获得Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署软件包(补丁包或发布包)，从而实现补丁包的自动升级、发布包的自动安装；

以及，本发明实施例通过使用Syndication Feed信息发布机制、SyndicationFeed信息源订阅机制，实现部署远程监控，一站式管理，减轻了软件后期的升级维护所带来的成本压力。

上述分别从各个阶段对本发明实施例的方案进行了描述，下面结合一个具体应用进一步介绍本发明实施例的方案：

请参阅图8，为本发明实施例软件包的自动部署方法的交互示意图，应用于包括Web客户端、部署服务器和应用服务器的系统，如图8并结合图1所示，包括：

S701、结合图1所示，部署服务器10根据后台应用1和应用2分别创建两个Syndication Feed信息源。

部署服务器创建Syndication Feed信息源(换言之即部署服务器发布Syndication Feed信息)的方式可以使用标准的页面锚<a/>，也可以使用<link/>方式。

例如：<a href＝＂http://localhost：8080/NE Software/info.xml＂>具体应用的名称</a>

或者，<link rel＝＂alternate＂type＝＂application/atom+xml＂title＝＂具体应用的名称＂href＝＂http://localhost：8080/NE Software/info.xml＂/>

本发明实施例中，即“具体应用的名称”为应用1、应用2，即可完成创建Syndication Feed信息源，包括应用1的Syndication Feed信息源、应用2的Syndication Feed信息源。

在一种实现下，即部署服务器10定义两个频道，所述两个频道分别对应应用1和应用2。

S702-S703、应用服务器20-1订阅应用1的Syndication Feed信息源，应用服务器20-2订阅应用2的Syndication Feed信息源。

应用1和应用2各自都包含一个部署Bundle，当部署Bundle首次被部署时，被设定分别订阅Syndication Feed，即应用1的部署Bundle订阅应用1的Syndication Feed信息源，应用2的部署Bundle订阅应用2的Syndication Feed信息源。在一种实现下，应用1的部署Bundle订阅应用1的频道，应用2的订阅应用2的频道。

S704、维护人员通过Web客户端30上传新的软件包，以及提供部署包相关信息；

这里的部署包相关信息包括：软件包对应的应用名称：应用1，软件包版本信息：2.1.3，软件包名称：PK1，部署策略：每日凌晨2点启动部署；这里可以使用HTTP的方式也可以采用FTP的方式上传新的软件包。

S705、结合图1所示，部署服务器10接收到新的软件包和部署包相关信息后，根据所述部署包相关信息生成对应的Syndication Feed信息，更新该新软件包对应的应用1的Syndication Feed信息源中的信息，并将所述新的软件包存放到指定目录下；其中，该指定目录作为包下载地址信息包含于应用1的Syndication Feed信息源中更新后的Syndication Feed信息。

下面给出了一个基于ATOM模型的Syndication Feed信息的例子，如图1所示，以XML文本表示：

<xml version＝＂1.0＂encoding＝＂utf-8＂？>

<feed xmlns＝＂http://www.w3.org/2005/Atom＂>

  <title type＝＂text＂>Application name</title>

  <link href＝＂http://localhost：8080/＂/>

  <id>tag:diveintomark.org，2003：3.2397</id>

  <updated>2008-07-10T12：29：29Z</updated>

  <rights>Copyright(c)2008，Huawei Tech</rights>

  <entry>

    <title>Package name</title>

    <id>urn:uuid：1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>

    <updated>2008-07-10T12:29:29Z</updated>

    <published>2006-12-13T08:29:29-04:00</published>

    <content type＝＂Application/octet-stream＂

  src＝＂http://localhost:8080/resources/packagename.jar＂/>

    </content>

    <version>2.1.3/version>

    <action_time></action_time>

  </entry>

</feed>

其中，Feed中的title元素中Application name即应用名称，这个名称在整个部署服务器中唯一，本实施例中这里是Application 1；

Entry中的title元素中Package name即软件包名称，这个名称在本应用中唯一，本实施例中这里是PK1。

Content元素的type属性是合法的MIME(Multipurpose Intemet MailExtensions，多用途互联网邮件扩展)类型，一般是application/octet-stream。Src属性是一个合法的URL，指示软件包的下载地址，即src＝http://localhost：8080/resources/packagename.jar。

Version元素和action_time元素是扩展元素，分别用于指定软件包的版本和部署的时间策略。如果action_time是空，表示立即执行。action_time中的时间格式符合标准的GTS时间格式。本实施例中版本信息是2.1.3；本实施例中部署的操作时间为空。

如果使用RSS2.0，则每个Channel对应一个应用，Title元素对应于应用名称。每个item元素对应一个软件包，title子元素给出软件包名称，enclosure元素用于给出软件包下载的URL地址，这里不再赘述。

S706、应用服务器20-1获得所订阅的与当前应用对应的Syndication Feed信息源中的Syndication Feed信息；

具体可以包括，应用服务器20-1上的部署bundle定时向部署服务器10发送查询请求，如http请求；

部署服务器10接收该查询请求后，如果请求方所订阅的Syndication Feed信息源中有更新的Syndication Feed信息，返回包含更新的Syndication Feed信息的响应，换句话说，即下载最新的Syndication Feed信息；如果请求方所订阅的Syndication Feed信息源中没有更新的Syndication Feed信息，返回一个http头的响应内容，指示没有新的Syndication Feed；还可以使用压缩技术将Syndication Feed信息压缩后再传送。

由于S704中是针对应用1有新的软件包发布，所以S706中应用服务器20-1(应用1)上的部署Bundle会获得更新的Syndication Feed信息。

S707、结合图1所示，应用服务器20-1解析该Syndication Feed信息，从该Syndication Feed信息中获取软件包名称PK1，根据软件包名称PK1在维护的部署包存量信息表中匹配到软件包名称相同的记录，将从该Syndication Feed信息中获取的版本信息2.1.3与匹配记录中的版本信息2.1.2进行比较，2.1.3优于2.1.2，根据该Syndication Feed信息中的包下载地址信息src＝http://localhost：8080/resources/packagename.jar下载相应的升级包；

S708、应用服务器20-1根据该Syndication Feed信息，更新所维护的部署包存量信息表中对应的老存量记录；

S709、应用服务器20-1根据该Syndication Feed信息中的部署时间策略为空，立即启动会话，开始部署升级包，即调用OSGI的服务来实现升级操作。

S710、应用服务器20-1向部署服务器10返回操作结果。

可见，本发明实施例中，部署服务器通过使用Syndication Feed技术发布反映新软件包的Syndication Feed信息到应用服务器所订阅的Syndication Feed信息源，应用服务器从当前应用所订阅的Syndication Feed信息源中获得Syndication Feed信息，根据所述Syndication Feed信息和所维护的存量信息，下载并部署新软件包(补丁包或发布包)，从而实现在无人工干预的情况下，软件包能够自动被部署服务器发布、自动被应用服务器检测并下载，从而完成应用服务相关补丁包的自动升级、发布包的自动安装；即通过使用SyndicationFeed发布、订阅机制，实现部署远程监控，一站式管理，减低了软件后期的升级维护所带来的成本压力；

进一步的，由于软件包为OSGI bundle，所以部署时，无需中断系统的操作，如不需要重启系统即可完成部署。

请参阅图9，为本发明实施例的应用服务器的结构示意图，本发明实施例的应用服务器包括至少一个部署Bundle(组件)，每个部署Bundle对应一个应用，如图9所示，部署Bundle包括：

订阅单元901，用于从所订阅的与当前应用对应的Syndication Feed信息源中，获得Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的新软件包的发布；

部署单元902，用于根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署新软件包。

以及，订阅单元901，进一步用于向部署服务器订阅与当前应用对应的Syndication Feed信息源，该Syndication Feed信息源包含反映与当前应用相关的软件包的Syndication Feed信息。

本发明实施例的应用服务器中，部署Bundle进一步的可以包括：管理单元903，用于维护部署包存量信息；需要说明的是所维护的存量信息中的每条记录表示该部署Bundle对应的应用已部署的软件包的情况。

在一种实现下，部署单元902为第一部署单元，用于从所述SyndicationFeed信息中获取软件包名称，与所维护部署包存量信息进行匹配，根据匹配得到的软件包名称相同的存量记录中的第二版本信息与从该Syndication Feed信息中获取的第一版本信息的比较结果以及从该Syndication Feed信息中获取的软件包下载地址，下载并部署新软件包。

或者，部署单元902为第二部署单元，用于从所述Syndication Feed信息中获取软件包名称，当从所维护部署包存量信息中匹配不到软件包名称相同的记录时，根据从该Syndication Feed信息中获取的软件包下载地址，下载软件包并部署。

以及，所下载的新软件包可以包括新增加的OSGI Bundle、原有OSGIBundle的补丁包，OSGI Bundle的资源包中的一种或多种。

可见，本发明实施例中，应用服务器从当前应用所订阅的Syndication Feed信息源中获得Syndication Feed信息，根据所述Syndication Feed信息中的关键信息和所维护的部署包存量信息，下载并部署新软件包(补丁包或发布包)，从而实现补丁包的自动升级、发布包的自动安装；即通过使用Syndication Feed订阅机制，实现部署远程监控，一站式管理，减低了软件后期的升级维护所带来的成本压力；

进一步的，由于软件包为OSGI bundle，所以部署时，无需中断系统的操作，如不需要重启系统即可完成部署。

请参阅图10，为本发明实施例的部署服务器的结构示意图，如图10所示，包括：

服务通信单元1001，用于接收应用服务器针对所订阅的、与当前应用对应的聚合摘要Syndication Feed信息源的查询请求；

订阅处理单元1002，用于在所述服务通信单元接收到该应用服务器的查询请求时，确定订阅方(该应用服务器)所订阅的Syndication Feed信息源中包含更新的Syndication Feed信息，并通过所述服务通信单元返回所述更新的Syndication Feed信息，其中所述Syndication Feed信息用于反映与当前应用相关的软件包的发布。

本发明实施例部署服务器进一步可以包括：管理单元1003，用于为每个后台应用创建对应的Syndication Feed信息源。

相应的，服务通信单元1001，进一步用于接收应用服务器针对当前应用对应的Syndication Feed信息源的订阅请求。

本发明实施例部署服务器进一步可以包括：Syndication Feed生成单元1004，用于根据接收的部署包相关信息生成或更新对应的Syndication Feed信息到对应的应用所订阅的Syndication Feed信息源中；这里生成或更新对应的Syndication Feed信息可以为RSS Feed信息、ATOM Feed信息，应当理解的是，每当有软件包被上传到部署服务器或FTP服务器时，Syndication Feed生成单元1004生成或更新对应的Syndication Feed信息。

以及，本发明实施例部署服务器进一步可以包括：存储单元1005，用于存放通过所述管理单元所接收的上传的软件包。

可见，本发明实施例中，部署服务器通过使用Syndication Feed技术发布反映新软件包的Syndication Feed信息到应用服务器所订阅的Syndication Feed信息源，从而实现了软件包的自动发布；进一步的，还实现了软件包的集中管理。

以及，本发明实施例通过采用Syndication Feed信息源订阅机制，实现向订阅方返回更新的Syndication Feed信息，所述Syndication Feed信息反映有新的软件包发布，实现部署远程监控，一站式管理，减轻了软件后期的升级维护所带来的成本压力。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上所述仅为本发明的几个实施例，本领域的技术人员依据申请文件公开的可以对本发明进行各种改动或变型而不脱离本发明的精神和范围。