CN1758607A - 分布式业务系统中的软件版本升级系统及其方法 - Google Patents

Abstract

本发明提供了一种用于分布式业务系统中的软件版本升级方法，包括步骤：集中管理服务器接收主系统输入的新版本应用软件，更新集中管理服务器所连接的数据库记录的版本下发信息，以准备下发新版本应用软件；将所接收的新版本应用软件下发到应用服务器，更新所述应用服务器连接的数据库中的新版本应用软件的下发记录；集中管理服务器和应用服务器安装各自所接收的新版本应用软件，应用服务器向用户终端提供新版本应用软件的下载；当所述应用服务器未能接收到新版本应用软件，请求集中管理服务器下载所述新版本应用软件，并提供给用户终端；和用户终端安装所接收的新版本应用软件。

Description

分布式业务系统中的软件版本升级系统及其方法

技术领域

本发明涉及一种分布式业务系统中的软件版本管理及升级系统及其方法，特别是涉及一种将软件版本自动下发与请求下载版本相结合的方式来自动更新应用软件版本以防止网络拥塞的系统和方法。

背景技术

在诸如金融机构之类的很多业务系统中，很多子系统通过网络连接到中央主系统。系统中的应用终端设备分散部署在众多分支机构上，通过诸如局域网之类不同的网络经子系统连接到中央主系统，受中央主系统和所连接的子系统的管理和监控。在这些业务系统中，各终端设备中运行的应用软件由主系统提供。为了从主系统得到新应用软件或对已经运行的应用软件进行升级，一般是由主系统向终端设备自动下发新版本的应用软件，或由终端设备向主系统请求下载新版本的应用软件。

由于诸如金融业务系统之类的子系统或终端设备的数量众多，尤其是终端设备在很大范围内连网，由不同的分支机构对其进行维护，难以将整个系统中的各个部分控制在一个统一的版本水平上。因此，可能会出现因为管理困难而使各个终端设备中的软件版本不一致，造成业务内容不一致，不易协调各终端设备间的工作的问题，并且有可能造成交易错误。

传统的版本控制和实施方法需要安排大量的维护人员。其维护和管理成本较高，并且各子系统软件版本升级不一致，难以做到版本统一，给系统的全面升级带来很大困难。为了适应市场的飞速发展，各行业的业务类型需要不断地调整和变化，系统的软件版本也因此而需要频繁地更新。由于业务系统本身具有较为复杂的层次结构，版本升级工作复杂，容易因人为因素造成运行事故。另外，软件的版本与版本之间的依赖关系复杂，版本控制难度较大。

发明内容

鉴于上述问题，本发明的目的是提供一种实现软件版本的自动下发以及远程的版本控制的方法和系统，能够以多种手段实现版本的安装，将版本下发和版本安装的过程分开，从而避免系统远程升级在低速网络的情况下引起堵塞，并实现自动重连。

根据本发明的一个方面，提供一种用于分布式业务系统中的软件版本升级方法，包括步骤：集中管理服务器接收主系统输入的新版本应用软件，更新集中管理服务器所连接的数据库记录的版本下发信息，以准备下发新版本应用软件；将所接收的新版本应用软件下发到应用服务器，更新所述应用服务器连接的数据库中的新版本应用软件的下发记录；集中管理服务器和应用服务器安装各自所接收的新版本应用软件，应用服务器向用户终端提供新版本应用软件的下载；当所述应用服务器未能接收到新版本应用软件，请求集中管理服务器下载所述新版本应用软件，并提供给用户终端；和用户终端安装所接收的新版本应用软件。

根据本发明的另一个方面，提供一种用于分布式业务系统中的软件版本升级方法，包括步骤：集中管理服务器接收主系统输入的软件新版本文件包，轮询每个应用服务器，依次向每个应用服务器发送版本文件包，并更新集中管理服务器所连接的数据库中与每个应用服务器的新版本应用软件下载记录对应的信息；应用服务器接收集中管理服务器发送的版本文件包，更新所述应用服务器连接的数据库中的有关所述应用服务器的版本文件包的安装记录和状态；集中管理服务器和应用服务器安装各自的版本文件包，应用服务器向用户终端提供新版本应用软件的下载；用户终端安装所接收的新版本应用软件。

根据本发明的再一个方面，提供一种用于分布式业务系统中的软件版本升级方法，包括步骤：向集中管理服务器输入软件升级版本文件包；集中管理服务器保留本身的升级版本文件包，并向下层应用服务器传送用于下层应用服务器的软件升级所需的升级版本文件包；使数据库服务器增加软件版本的记录，将其状态设置为初始状态；向应用服务器自动下发升级版本文件包；集中管理服务器和应用服务器安装各自的版本文件包，应用服务器向用户终端提供新版本应用软件的下载；用户终端安装所接收的新版本应用软件。

根据本发明的再一个方面，提供一种用于分布式业务系统中的软件版本升级系统，包括：集中管理服务器，通过网络将多个应用服务器连接在一起，用于向所述多个应用服务器下发新版本的应用软件文件包，或者根据应用服务器发起的版本下载请求提供新版本的应用软件文件包的下载服务；多个应用服务器，用于向终端用户提供分布式业务系统的软件版本升级和管理；多个用户终端，用于接收应用服务器下发的新版本的应用软件文件包和请求应用服务器下载新版本的应用软件文件包，并运行新版本软件以向用户提供相应的业务；多个数据库，分别用于记录集中集中管理服务器、应用服务器和用户终端的软件版本信息和软件版本更新状态；和通信网络，用于在集中管理服务器、应用服务器和用户终端间进行通信。

本发明提供了一种用于分布式业务系统的软件自动更新方法，可以使得部署运行在不同物力地点的银行业务系统在运行过程中以多种手段获取新版本并自动更新自身各个组成模块，以实现系统的协调一致的版本升级和方便快捷的版本管理。

本发明能有效地提高银行业务系统版本下发的安全性，可靠性，降低系统版本的管理难度。

附图说明

通过下面结合附图说明本发明的优选实施例，将使本发明的上述及其它目的、特征和优点更加清楚，其中：

图1是表示根据本发明实施例的业务系统的架构图；

图2是表示根据本发明实施例的分布式业务系统的软件自动更新系统中的集中管理服务器的配置方框图；

图3是表示根据本发明实施例的业务系统中的应用服务器的配置方框图；

图4是表示根据本发明实现分布式业务系统的软件自动更新的终端设备的配置方框图；

图5是表示根据本发明实施例从集中管理服务器自动下发版本到应用服务器的流程图；

图6是根据本发明实施例从应用服务器请求下载版本以及系统软件升级的流程图；和

图7示出了根据本发明从应用服务器到终端程序的版本下载和升级安装的流程图。

具体实施方式

下面参照附图对本发明的实施例进行详细的说明，在描述过程中省略了对于本发明来说不必要的细节和功能，以防止对本发明的理解造成混淆。

图1是根据本发明实施例的业务系统的架构图。整个业务系统包括集中管理服务器1、数据库服务器2、版本控制客户端3、主管机构局域网4、数据库服务器5、一个或一个以上的应用服务器6，广域网7、分支机构局域网8、一个或一个以上的个人计算机(PC)终端9，和智能终端10。

如图1所示，集中管理服务器1通过主管机构4将多台应用服务器6连接在一起，负责向应用服务器6下发新版本的应用软件，或者针对应用服务器发起的版本下载请求提供下载服务。在本实例中，主管机构4可以是局域网，但本发明不限于此，也可以采用其它的主管机构网络来实现集中管理服务器1与应用服务器6的链接。

与集中管理服务器1连接的数据库服务器2负责记录和管理软件版本下发过程中各个应用服务器6的版本状态，并为管理人员了解版本下发状况提供数据。

应用服务器6向终端用户提供系统软件版本升级和管理，以及其它业务功能。一方面，应用服务器6可以通过版本自动下发装置获取新版本的软件，以更新自身的系统。另一方面，应用服务器6也可以向下端连接的众多PC终端和智能终端提供软件版本下载服务功能。应用服务器6还与其自身的数据库服务器5。数据库服务器5用于存放该应用服务器的版本安装记录和状态。作为实例，图1中示出了每个应用服务器6各连接一个数据库服务器5。然而，本发明不限于此，也可以是多个应用服务器6连接到一个数据库服务器5。数据库服务器5可以存储多个应用服务器6的版本安装记录和状态，并根据各个应用服务器6的ID来识别相应的服务器，以便由应用服务器6从数据库服务器5提取其自身状态数据。

主管机构局域网4将多个应用服务器6与集中管理服务器1连接起来。

版本控制客户端3可以作为系统版本下发、更新和监控集中管理服务器1的运行的控制台。系统管理人员通过版本控制客户端3控制整个业务系统，向整个系统传送版本文件，集中下达版本下发、安装等指令，并监控整个版本下发的过程。

PC终端和智能终端(9，10)通过广域网7与上端的应用服务器6连接，并通过分支机构局域网8相互连接。PC终端和智能终端是整个业务系统的人机交互界面。用户(金融系统的业务人员)通过PC终端或智能终端录入交易信息，并通过其与应用服务器进行交互，以完成各种业务交易。PC终端和智能终端(9，10)上都运行着相同的终端程序，并同样采用向应用服务器6请求版本下发的方式完成自身版本的升级。对于版本自动下发功能而言，两者没有区别。

图2示出了集中管理服务器1内部的系统架构。应该指出，在此仅示出了集中管理服务器1中与本发明的功能相关的部分，并省略了与实现本发明无关的部分，以避免对本发明造成混淆。如图2所示，集中管理服务器1包括数据库访问接口21，版本下载服务装置22，版本自动下发装置23，下层通信接口24，版本监控通信接口25和版本升级控制装置26。

在集中管理服务器1中，数据库访问接口21可以连接到数据库服务器2，执行数据库的查询、更新等操作。版本下载服务装置23响应通过下层通信接口24接收的来自应用服务器6的版本下载请求，通过数据库访问接口21从数据库提取新版本软件，并通过下层通信接口24向发出请求的应用服务器6下载新版本的软件。另一方面，版本自动下发装置22通过数据库访问接口21从数据库提取新版本软件，并通过下层通信接口24主动向应用服务器6下发版本文件。版本自动下发装置22和版本下载服务装置23都通过下层通信接口24与下端连接的应用服务器通信。

版本监控通信接口25负责监听来自版本控制客户端3的操作指令，包括：例如，各种版本下发和升级安装操作。当版本监控通信接口25接收到升级安装指令时，还负责集中管理服务器1中软件的升级安装，同时还响应客户端对版本下发情况的查询请求。版本升级控制装置26还用于对通过版本监控通信接口25从版本监控通信接口25接收到的版本的解包和升级安装操作。

图3示出了根据本发明实施例的业务系统中的应用服务器的配置方框图，为了简化起见，该图示出了应用服务器内部系统架构与本发明功能相关的部分，并省略了与实现本发明无关的部分。如图3所示，应用服务器上层通信接口31用于与上端的集中管理服务器1进行通信。当有新版本的软件从集中管理服务器1下发时，应用服务器版本接收装置33用于通过应用服务器上层通信接口31接收集中管理服务器1主动下发的版本文件。另外，可以通过应用服务器版本下载请求装置32向集中管理服务器1询问业务系统已更新的版本。如果新版本的软件已经到达本地，则由应用服务器中的应用服务器版本升级控制装置37对接收到的新版本的软件执行解包和升级安装操作。否则，如果应用服务器版本接收装置33没有接收到新版本的软件，还需要向集中管理服务器1请求下载该版本后再安装。应用服务器数据库访问接口34用于进行数据库的查询、更新等操作。应用服务器版本下载服务装置35负责响应来自下端终端用户对程序的版本下载请求，并通过应用服务器下层通信接口36与下端连接的用户的PC终端9或智能终端10进行通信，以向其传送新版本软件。

图4示出了用户的PC终端9和智能终端10中与本发明功能相关的部分的内容系统架构。如图4所示，为了简化起见，省略了PC终端9和智能终端10中与实现本发明无关的部分。终端上层通信接口41用于通过网络与上端的应用服务器通信，以接收下发的新版本软件或向应用服务器6发出对新版本软件的请求。终端版本下载请求装置42用于向集中应用服务器6询问系统是否有已更新的版本。如有已更新的软件，则将其下载到本地并由终端版本升级控制装置43对接收的软件版本进行解包和升级安装操作。

接下来，描述根据本发明的分布式业务系统中的软件版本管理升级系统及其操作。

为了实现版本的自动下发以及远程的版本控制，本发明的功能通过以下几种方式来完成。

1.采用主动和被动方式实现版本下发

如果按照版本文件传递的方向，将传递版本的双方(集中管理服务器和PC终端或智能终端)称为版本源和版本目标，则系统中版本文件的传递可分为由版本源主动发起的版本下发(主动方式)，以及由版本目标发起版本下载请求，版本源被动地响应该请求并提供下载服务的方式(即被动方式)。

版本由集中管理服务器1到应用服务器6的传递过程以主动下发方式为主。在这种方式中，集中管理服务器1主 动地轮询每个应用服务器6，依次向其发送版本文件包，从而避免了下端的应用服务器集中向集中管理服务器1请求版本下载造成的网络拥塞以及在下载过程中等待时间过长的问题。另一方面，应用服务器6也可以向集中管理服务器1请求下载那些已经在系统中启用的版本。这样就避免了应用服务器6因为某些原因没有开机而错过由集中管理服务器主动发起的版本下发过程，保证系统中版本的一致性。

由于单个终端的版本升级只涉及单个用户，因此版本文件由应用服务器到分支机构各种终端的传递过程采用被动方式，即由终端在启动时连接到应用服务器6，询问是否有新版本需要更新。如果有，则由应用服务器6提供版本文件的下载服务。

2.版本下发和版本启用(安装)相分离

由于诸如金融业务系统之类的系统规模非常庞大，涉及数量众多的基础网点和终端设备，因此版本自动下发是一个相对较长的过程。在此过程中，要求版本下发和安装操作不影响系统正常的业务操作。如果将版本下发和版本安装捆绑在一起，对于执行版本下发的版本源来讲，其处理能力在某一时刻必然受版本源所在硬件设备的系统处理能力的限制，从而导致各子系统(例如交易服务器和数量众多的终端)为保证版本的统一升级而长时间排队。按照本发明，将版本下发和版本安装相分离，即可将版本先下发到各个应用服务器，再由应用服务器下发到用户终端，从而使版本下发过程对于各子系统而言可以有先后的区别，但对于版本安装则采用统一、自主安装的策略。这样，既保证了整个系统中各子系统采用统一版本，又使版本安装采用分布式处理，从而提高了版本升级操作的效率。

3.采用数据库记录版本文件下发记录和所处状态

本发明利用数据库记录各交易服务器上版本文件的到位情况，以及版本所处的状态，从而提供智能化的版本自动下发功能，并为操作人员查询版本下发情况提供数据。其中，与集中管理服务器1连接的数据库2主要存放版本文件当前的下发状态，并记录下层各应用服务器6的版本到位的情况。与应用服务器6连接的数据库5主要记录本地版本的下发状态。

4.版本文件包按传递顺序分层次组织

根据本发明，按照版本文件传递的顺序，对各层子系统所需的版本包层层嵌套地进行打包，本层得到的版本文件包含下一层的，通过下发过程层层剥离，向下传递。

最初，版本包包括集中管理该集中管理服务器1、应用服务器6和终端(9，10)的程序的升级版本。当版本包从版本控制客户端3到达集中管理服务器后1，该版本包被解包，其中一部分文件是集中管理服务器的版本，这部分文件留在集中管理服务器1上，另一部分则包括下一层交易服务器以及终端程序的升级版本，这部分文件则继续向应用服务器6传递。在到达应用服务器6之后，该版本文件包又被解包，分为两部分。被应用服务器6解包的文件的一部分是应用服务器的升级版本，保留在应用服务器上，另一部分则为终端程序的升级版本，将被下载到终端上供升级时安装使用。

通过采用层层嵌套的方式组织版本包，可以对各子系统的版本升级进行统一控制，从而可以对整个系统中的版本升级进行有效管理。

5.用XML文档描述版本升级的各类操作

版本在安装时可能采用解压缩、打包数据备份、拷贝、移动、执行shell脚本等操作，而且这些操作在每个升级版本的安装过程中并不是完全一致的。本发明将版本安装步骤按照XML格式进行描述，形成操作清单，与版本文件打包在一起，在版本包升级时首先解析出该清单，然后系统按照清单中定义的操作步骤对升级版本文件进行操作。由于XML语言良好的可扩展性，可以方便的定义更多新的操作，为以后系统的版本升级提供新的手段。

下面给出以一个应用服务器升级版本的操作清单文件的例子，以说明系统是如何按照操作清单完成版本升级工作的。

<ver>

  <name>cts</name>                    //版本名称

  <version>0.0.1</version>                 //版本号

  <action>                             //A、备份操作

    <backup>

      <mkdir>./ctsbackup</mkdir>              //创建备份目录

      <copy>

        <src>./cts/version</src>               //将原有版本目录进行备份

        <des>./ctsbackup</des>

      </copy>

   </backup>

   <update>                                     //B、升级操作

      <mkdir>./ctsupdate</mkdir>                   //创建升级目录

      <decompress>                             //解压缩文件包

         <src>./version/cts_0.0.1.jar</src>

         <des>./ctsupdate</des>

      </decompress>

     <copy>                       //拷贝文件<src>./ctsupdate/rc/ctb/windows/ctbver_0.0.1.jar</src>

          <des>./rc/ctb/windows/</des>

       </copy>

       <exec>./rc/ctb/windows/cts.shell</exec>     //执行脚本操作

      ......

      <delete>./ctsupdate</delete>            //删除目录

      <delete>./ctsbackup</delete>

   </update>

   <recover>                               //C、恢复操作

      <move>

        <src>./ctsbackup</src>              //将原有版本目录进行备份

        <des>./cts/version</des>

      </move>

    </recover>

  </action>

</ver>

如上面给出的程序所示，其中给出了备份操作，升级操作和恢复操作。下面对这些操作进行说明。

A.备份操作：为了防止系统升级过程中出现故障，导致原有的系统文件受损或被覆盖，需要在升级前对现有文件系统进行备份。为此，程序解析该XML格式的操作清单，当读到“<mkdir>”节点，即按照该节点内的值创建一个备份目录。然后，读到“<copy>”节点，将本次升级可能涉及的文件目录复制到该备份路径下。

B.升级操作：版本文件包在传输过程中是经过压缩处理的，以便减小网络传输的数据量。因此，在升级前，首先需要创建一个升级目录，将版本文件包解压缩后存放在该目录下。此后，将其中的文件移动到系统应有的路径下。另外，操作清单还定义了对其中一些脚本的执行操作，通过执行这些脚本实现一些复杂的系统操作如增加或改变系统变量、设置操作系统参数等；最后需要删除创建的两个临时工作目录。

C.恢复操作：如果在升级操作中出现错误，将使整个系统升级失败。此时系统应该恢复到升级前的文件系统状态。操作清单定义了将备份操作保存的数据恢复到原有路径的动作，使系统始终能够保持完整性，提高了系统升级的容错能力。

下面参考图5说明根据本发明从集中管理服务器自动下发版本到应用服务器的流程的一个实施例。该过程主要包括系统管理人员将升级版本文件从版本控制客户端3传递到整个系统。按照版本在系统中的运动过程分为从客户端上传到集中管理服务器1，从集中管理服务器1下发到应用服务器6，集中管理服务器1和应用服务器6的升级安装，应用服务器6到终端程序的版本下载和升级安装4个阶段，现在分别介绍4个阶段的工作流程。

首先，由系统管理人员通过版本控制客户端3将升级版本文件上传到集中管理服务器1。在步骤S501，由集中管理服务器1上的版本监控通信接口25接收该升级版本文件。应该指出，本发明不限于升级版本文件，也可以是全新的软件。该版本文件可以有两个部分，一部分是集中管理服务器1本身的升级程序包，另一部分则是下端(包括应用服务器6和终端程序9，10)所用的升级版本程序。两部分版本被打在一个压缩包内。该版本到达集中管理服务器1后，首先由版本升级控制装置将该升级文件包接开，分成两部分。然后，在步骤S502，通过数据库访问接口21在数据库服务器增加该版本的信息，将其状态设置为初始状态。此时，管理人员通过版本控制客户端3可以查看到该版本已经进入系统。

此后，在步骤S503，通过数据库访问接口(图2装置1)访问数据库2，判断该版本的状态是否为正在自动下发。如果步骤S502的判断结果为否定，流程则转到步骤S510，表明该版本的自动下发过程结束。如果在步骤S503判断该版本的状态处在自动下发状态，流程则进行到步骤S504，集中管理服务器访问其连接的数据库2，然后根据当前版本号，查找那些目前尚未得到该版本文件的应用服务器，将这些应用服务器的ID送版本自动下发装置，排列在向其自动下发升级版本文件的任务队列中，并向应用服务器执行升级版本文件自动下发过程。版本自动下发装置依照队列逐一向应用服务器发送版本。然后，在步骤S505，每发送成功一次，即在数据库中记录该结果，集中管理服务器1检验其任务队列中是否为空，直到队列为空时循环结束。如果步骤S505的判断结果为否定，流程则进行到步骤S506，继续任务队列中排列的应用服务器自动下发升级版本文件，并在步骤S506后返回步骤S505，检查任务队列。

如果在步骤S505判断任务队列为空，流程则进行的步骤S507，集中管理服务器1访问数据库2查看得到版本文件的应用服务器的数量，并在步骤S508判断版本自动下发是否达到预定的效果。当其下发比例超过预先设定的阈值时，则认为版本下发达到预定效果。此时，流程进行到步骤S509，集中管理服务器1再次访问数据库2，修改其中存储的有关服务器的版本的状态为“版本下发成功”，并退出下发过程。相反，如果在步骤S508判断的结果为否定，则表明对其中一部分应用服务器6的版本下发过程失败。这种情况下，可以在数据库中查到的版本文件下发不成功的应用服务器的ID及这些服务器的数量。这些服务器的数量将表明版本下发未达到预定效果，则系统将返回步骤S503，再次循环下发该版本。

下面参考图6描述集中管理服务器1和应用服务器6的版本升级安装过程。管理人员通过版本控制客户端3向集中管理服务器1下达版本升级的指令。集中管理服务器1首先经版本监控通信接口25接收该命令，然后通过数据库访问接口21访问数据库2，将该版本的状态由“版本下发成功”改为“准备安装版本”。

当集中管理服务器1下次启动系统时，首先访问数据库2，当发现该软件版本处于升级准备状态时，则由版本升级控制装置26依照版本文件包中的升级操作清单完成各种升级动作。之后，修改数据库2中对该软件版本的记录状态，例如，由“准备安装”改为“已经安装”。此时，下端的众多应用服务器6仍未进行该新版本的升级安装。

随后，在应用服务器端，在步骤S601，启动应用服务器，通过上层通信接口31连接到集中管理服务器1上。此后，在步骤S602，应用服务器试图对自身进行版本升级。具体地讲，应用服务器1向其所连接的数据库5查询自身当前的版本号，将其上送集中管理服务器，并在步骤S603询问集中管理服务器是否有新的版本需要升级安装。接下来，在步骤S604，集中管理服务器1中的版本下发服务装置35处理来自应用服务器6的查询请求。然后，在步骤S605，版本下发服务装置35根据该应用服务器6的版本号，查找当前本地数据库2中的版本情况，以确定是否有已经安装的新版本。如果在步骤S605发现本地系统的当前版本高于该应用服务器6当前使用的版本，则在步骤S606将所需安装的版本号发送回应用服务器6；如果本地系统的当前版本与该应用服务器6当前使用的版本相同，则向应用服务器6返回相应的信息。

应用服务器6在步骤S607接收从集中管理服务器返回的查询结果，并在步骤S608判断是否需要对该应用服务器中使用的软件版本进行升级。如果在步骤S608判断不需要对其软件版本进行升级，流程则转到步骤S615，结束该版本升级安装过程。如果需要对应用服务器6中的软件版本进行升级，流程则转到步骤S609，首先查看所需升级的版本是否由于集中管理服务器1主动下发或者手工拷贝等原因已经预先到达本地(即本应用服务器连接的数据库5。如果步骤S609中的判断结果为否定，即新版本的软件仍未到达本地，则在步骤S610由版本下载请求装置32向集中管理服务器1请求下载该版本的软件。

集中管理服务器1中的版本下载服务装置23在步骤S611负责将该版本的软件送到应用服务器6，并由应用服务器6在步骤S612通过网络接收版本下载服务装置23提供的软件版本。接下来，由应用服务器6上的版本升级控制装置37在步骤S613完成升级版本的各项操作。在步骤S614，应用服务器6通过数据库访问接口在应用服务器所连接的数据库中记录安装后系统当前的最新版本，最后在步骤S615退出升级操作。

另外，如果应用服务器在步骤S609判断版本文件已经在本地，流程则继续进行到步骤步骤S613，执行如上所述的涉及升级版本的各项操作。

图7示出了从应用服务器到终端程序的版本下载和升级安装的流程。该过程与应用服务器从集中管理服务器下载和升级安装的过程基本相同。下面参考图7对其进行详细说明。

在步骤S701，启动用户终端(9，10)，通过终端上层通信接口41连接到应用服务器6上。此后，在步骤S702，用户终端试图对自身进行版本升级。具体地讲，用户终端查询自身当前运行的版本号，将其上送给应用服务器6，并在步骤S703询问应用服务器6是否有新的版本需要升级安装。接下来，在步骤S704，应用服务器6中的应用服务器版本下发服务装置35处理来自用户终端的查询请求。然后，在步骤S705，应用服务器版本下发服务装置35根据该用户终端提供的版本号，在其所连接的数据库中查找用户终端的版本情况，以确定是否有已经安装的新版本。如果在步骤S705发现应用服务器的当前版本高于该用户终端当前使用的版本，则在步骤S706将所需安装的版本号发送给用户终端；如果应用服务器的当前版本与用户终端当前使用的版本相同，则在步骤S706向用户终端返回相应的信息。

用户终端在步骤S707接收从应用服务器返回的查询结果，并在步骤S708判断是否需要对该用户终端中运行的软件版本进行升级。如果在步骤S708判断不需要对其软件版本进行升级，流程则转到步骤S715，结束该版本升级安装过程。如果需要对用户终端中运行的软件版本进行升级，流程则转到步骤S709，首先查看所需升级的版本是否由于应用服务器6主动下发或者手工拷贝等原因已经预先到达该用户终端。如果步骤S709中的判断结果为否定，即新版本的软件仍未到达本地，则在步骤S710由终端版本下载请求装置42向应用服务器6请求下载该版本的软件。

应用服务器6中的应用服务器版本下载服务装置35在步骤S711负责将该版本的软件送到用户终端，并用户终端在步骤S712通过网络接收版本下载服务装置35提供的软件版本。接下来，用户终端在步骤S713完成升级版本的各项操作。然后，在步骤S714，应用服务器在应用服务器所连接的数据库中记录已经将最新版本的软件提供给该用户终端，最后在步骤S715退出升级操作。

另外，如果用户终端在步骤S709判断版本文件已经在本地，流程则继续进行到步骤步骤S713，执行如上所述的涉及升级版本的各项操作。

根据本发明的系统和方法能够有效地解决了大型业务系统，特别是金融业务系统中版本升级的升级维护和版本管理、控制问题，与现有的本地化版本安装方式相比，其优点主要从以下几个方面：

1)大型金融业务系统拥有数量众多的子系统或终端，要为这些分散地运行在不同物理位置的计算机设备上的应用软件进行升级，其维护工作量极大。尤其是在业务发展迅速，升级工作频繁的情况下，其维护成本很大。本发明为这类大型金融业务应用系统提供了远程、自动化的升级手段，尤其是实现了终端程序极大地降低了系统运行维护成本。

2)由于金融业务系统子系统或终端数量众多，尤其是终端，由不同的分支机构对其进行维护，因此常出现因为管理困难而各部分版本不一致，难以将整个系统各部分控制在一个统一的版本水平上。本发明采用数据库对版本下发状况和当前运行版本进行跟踪记录，并在系统启动时通过向上询问版本的方式保证同一层次的子系统版本一致，对整个系统各部分运行的版本升级情况进行了有效的控制，避免了系统版本管理的混乱，最终减少了因版本问题造成生产事故的可能。

3)本发明采用XML语言描述版本升级操作，使版本升级可以根据各个版本的具体情况自定义升级操作，并且充分利用XML可扩展标记语言的特性，使升级操作可以随着系统自身的不断发展而扩展、进化，使系统该功能具有良好的柔性。

至此已经结合优选实施例对本发明进行了描述。本领域技术人员应该理解，在不脱离本发明的精神和范围的情况下，可以进行各种其它的改变、替换和添加。因此，本发明的范围不应该被理解为被局限于上述特定实施例，而应由所附权利要求所限定。

Claims (15)

1.一种用于分布式业务系统中的软件版本升级方法，包括步骤：

集中管理服务器接收主系统输入的新版本应用软件，更新集中管理服务器所连接的数据库记录的版本下发信息，以准备下发新版本应用软件；

将所接收的新版本应用软件下发到应用服务器，更新所述应用服务器连接的数据库中的新版本应用软件的下发记录；

集中管理服务器和应用服务器安装各自所接收的新版本应用软件，应用服务器向用户终端提供新版本应用软件的下载；

当所述应用服务器未能接收到新版本应用软件，请求集中管理服务器下载所述新版本应用软件，并提供给用户终端；和

用户终端安装所接收的新版本应用软件。

2.一种用于分布式业务系统中的软件版本升级方法，包括步骤：

集中管理服务器接收主系统输入的软件新版本文件包，轮询每个应用服务器，依次向每个应用服务器发送版本文件包，并更新集中管理服务器所连接的数据库中与每个应用服务器的新版本应用软件下载记录对应的信息；

应用服务器接收集中管理服务器发送的版本文件包，更新所述应用服务器连接的数据库中的有关所述应用服务器的版本文件包的安装记录和状态；

集中管理服务器和应用服务器安装各自的版本文件包，应用服务器向用户终端提供新版本应用软件的下载；

用户终端安装所接收的新版本应用软件。

3.根据权利要求2所述的方法，其中进一步包括应用服务器向集中管理服务器询问有关分布式业务系统中当前所运行的软件的版本，并且当应用服务器运行的软件的版本与集中管理服务器中运行的软件的版本不相同时，请求集中管理服务器下载分布式业务系统中已经启用的新版本软件文件包的步骤。

4.根据权利要求2所述的方法，其中进一步包括用户终端在启动时询问所连接的应用服务器是否有需要更新用户终端中所运行的软件的版本，并在需要更新软件的版本时由应用服务器向用户终端提供版本文件包的步骤。

5.根据权利要求2所述的方法，其中进一步包括按照版本文件传递的顺序，对各层子系统所需的版本层层嵌套地进行打包，使本层得到的版本文件包含下一层的版本文件包，通过下发过程剥离版本文件包，以向下层传递的步骤。

6.根据权利要求2所述的方法，其中进一步包括当版本文件包到达集中管理服务器后，对版本文件包解包，其中一部分文件保留在集中管理服务器，另一部分版本文件包传送到下一层应用服务器以及终端的步骤。

7.一种用于分布式业务系统中的软件版本升级方法，包括步骤：

向集中管理服务器输入软件升级版本文件包；

集中管理服务器保留本身的升级版本文件包，并向下层应用服务器传送用于下层应用服务器的软件升级所需的升级版本文件包；

使数据库服务器增加软件版本的记录，将其状态设置为初始状态；

向应用服务器自动下发升级版本文件包；

集中管理服务器和应用服务器安装各自的版本文件包，应用服务器向用户终端提供新版本应用软件的下载；

用户终端安装所接收的新版本应用软件。

8.根据权利要求7所述的方法，其中进一步包括集中管理服务器查找目前尚未得到该升级版本文件包的应用服务器，将这些应用服务器的ID排列在向其自动下发升级版本文件的任务队列中，并向应用服务器执行升级版本文件包自动下发过程的步骤。

9.根据权利要求7所述的方法，其中进一步包括集中管理服务器访问所连接的数据库以查看得到版本文件包的应用服务器的数量，以判断版本自动下发是否达到预定的效果的步骤。

10.根据权利要求7所述的方法，其中进一步包括在升级版本文件包下发过程失败的情况下，在数据库中查找的升级版本文件包下发失败的应用服务器的ID及这些服务器的数量，并在数据库中记录这些应用服务器下发失败的步骤。

11.根据权利要求7所述的方法，其中进一步包括应用服务器向集中管理服务器请求下载那些已经在系统中启用的软件版本的升级版本文件包的步骤。

12.一种用于分布式业务系统中的软件版本升级系统，包括：

集中管理服务器，通过网络将多个应用服务器连接在一起，用于向所述多个应用服务器下发新版本的应用软件文件包，或者根据应用服务器发起的版本下载请求提供新版本的应用软件文件包的下载服务；

多个应用服务器，用于向终端用户提供分布式业务系统的软件版本升级和管理；

多个用户终端，用于接收应用服务器下发的新版本的应用软件文件包和请求应用服务器下载新版本的应用软件文件包，并运行新版本软件以向用户提供相应的业务；

多个数据库，分别用于记录集中管理服务器、应用服务器和用户终端的软件版本信息和软件版本更新状态；和

通信网络，用于在集中管理服务器、应用服务器和用户终端间进行通信。

13.根据权利要求12所述的系统，其中所述集中管理服务器包括：

数据库访问接口，用于连接到数据库，以执行数据库的查询、更新操作；

版本下载服务装置，用于响应来自应用服务器的版本下载请求，通过数据库访问接口从数据库提取新版本软件，并向应用服务器下载新版本的软件；

版本自动下发装置，通过数据库访问接口从数据库提取新版本软件，并通过下层通信接口向应用服务器下发版本文件；

版本监控通信接口，用于系统操作员的操作指令和响应系统操作员对软件版本下发情况的查询请求；

版本升级控制装置，用于对通过版本监控通信接口接收到的版本进行解包和升级安装操作。

14.根据权利要求12所述的系统，其中所述应用服务器包括：

应用服务器上层通信接口，用于连接集中管理服务器；

应用服务器版本接收装置，用于通过应用服务器上层通信接口接收集中管理服务器主动下发的版本文件；

应用服务器版本下载请求装置，用于向集中管理服务器询问分布式业务系统已更新的软件版本；

应用服务器版本升级控制装置，对接收到的新版本的软件执行解包和升级安装操作；

应用服务器数据库访问接口，用于对所连接的数据库进行查询、更新操作；和

应用服务器版本下载服务装置，用于响应来自用户终端对软件版本的下载请求，并向用户传送新版本软件。

15.根据权利要求12所述的系统，其中所述用户终端包括：

终端上层通信接口，用于通过网络与上端的应用服务器通信，以接收下发的新版本软件和向应用服务器发出对新版本软件的请求；

终端版本下载请求装置，用于向应用服务器询问分布式系统是否有已更新的版本，如果有已更新的软件，则将其下载到本地；

终端版本升级控制装置，用于对接收的软件版本进行解包和升级安装操作。

Images