CN105630522A - 一种Web应用的更新方法、装置和系统 - Google Patents

Abstract

本申请实施例提供了一种Web应用的更新方法、装置和系统，所述的方法包括：接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；判断所述修改时间是否大于或等于上一次的加载时间；若是，则在所述展示层中加载所述资源更新文件。本申请实施例通过将展示层进行独立管理，在对展示层进行更新时，可以直接在展示层进行修改，发布资源更新文件，可以不用关心后端代码的更新，无需通过代码合并、编译、打包等复杂的传统发布过程，大大减少了发布的流程，加快了发布时间，同时，减少了更新的风险、提高了展示层的稳定性，大大提高了更新效率。

Description

一种Web应用的更新方法、装置和系统

技术领域

本申请涉及网络技术领域，特别是涉及一种Web应用的更新方法、一种Web应用的更新装置和一种Web应用的更新系统。

背景技术

随着互联网技术的发展，Web(网络)应用程序作为动态网站的实现基础越来越广泛应用，Web应用程序可以由Java(一种面向对象的程序设计语言)、PHP(HypertextPreprocessor，超文本预处理语言)、Python(一种面向对象、直译式计算机程序设计语言)等诸多语言实现，为基于浏览器的客户端用户提供网页浏览等Web服务。

对于Web应用，为了便于开发、维护等要求，需要对Web应用逻辑划分层次，使得不同的开发人员可同时对更层进行开发。

其中，分层中一般会包括视图层，可以是用户看到并与之交互的界面，互联网行业经常调整展现的内容，改变用户交互、文案等以提升用户体验或者发布新功能。

在传统的发布过程中，所有代码(包括视图层)的修改，都使用统一的发布过程：修改代码→代码合并→编译→打包→代码分发→部署。

可以看到整个过程中，修改视图层需要经过复杂的发布过程，更新时间十分长。并且，每次更新都需要发布Web应用的全量的发布包，发布过程占用大量的网络资源。

在发布过程中，由于应用容器需要重启，无法对外提供服务。所以集群的发布过程需要经过停流量、重新部署、开启流量非常复杂的操作。

上述发布过程修改代码的业务逻辑风险非常高，每次重新部署会加载所有的资源文件，包括视图文件以及后端逻辑文件，造成每次发布的风险不可控，稳定性也有潜在的风险。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：如何提出一种Web应用的更新方法，用以减少发布流程，减少网络资源的耗费，减少风险，提高稳定性。

发明内容

本申请实施例所要解决的技术问题是提供一种Web应用的更新方法，用以减少发布流程，减少网络资源的耗费，减少风险，提高稳定性。

相应的，本申请实施例还提供了一种Web应用的更新装置，用以保证上述方法的实现及应用。

为了解决上述问题，本申请公开了一种Web应用的更新方法，包括：

接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

判断所述修改时间是否大于或等于上一次的加载时间；若是，则在所述展示层中加载所述资源更新文件。

优选地，所述展示层用于加载Web应用中的交互界面；

所述展示层中包括以下至少一种资源文件：

网页文档、模板文件、图片、级联样式表、脚本对象。

优选地，所述资源更新文件为针对所述展示层中的资源文件进行更新的增量文件。

优选地，所述接收针对Web应用中独立的展示层的资源更新文件的步骤包括：

将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

对所述资源更新文件配置修改时间。

优选地，所述在所述展示层中加载所述资源更新文件的步骤包括：

启动所述展示层对应的模板引擎；

采用所述模板引擎加载所述目录中的资源更新文件。

优选地，所述Web应用还包括应用层，所述展示层与所述应用层相互独立，所述展示层与所述应用层在同一个Web容器中运行。

本申请实施例还公开了一种Web应用的更新装置，包括：

资源更新文件接收模块，用于接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

时间判断模块，用于判断所述修改时间是否大于或等于上一次的加载时间；若是，则调用资源更新文件加载模块；

资源更新文件加载模块，用于在所述展示层中加载所述资源更新文件。

优选地，所述展示层用于加载Web应用中的交互界面；

所述展示层中包括以下至少一种资源文件：

网页文档、模板文件、图片、级联样式表、脚本对象。

优选地，所述资源更新文件接收模块包括：

存储子模块，用于将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

配置子模块，用于对所述资源更新文件配置修改时间。

优选地，所述资源更新文件加载模块包括：

启动子模块，用于启动所述展示层对应的模板引擎；

加载子模块，用于采用所述模板引擎加载所述目录中的资源更新文件。

本申请实施例还公开了一种Web应用的更新系统，所述系统包括发布平台和一个或多个服务器；

其中，所述发布平台包括：

资源更新文件发布模块，用于发布针对Web应用中独立的展示层的资源更新文件；

所述服务器包括：

资源更新文件接收模块，用于接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

时间判断模块，用于判断所述修改时间是否大于或等于上一次的加载时间；若是，则调用资源更新文件加载模块；

资源更新文件加载模块，用于在所述展示层中加载所述资源更新文件。

优选地，所述展示层用于加载Web应用中的交互界面；

所述展示层中包括以下至少一种资源文件：

网页文档、模板文件、图片、级联样式表、脚本对象。

优选地，所述资源更新文件接收模块包括：

存储子模块，用于将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

配置子模块，用于对所述资源更新文件配置修改时间。

优选地，所述资源更新文件加载模块包括：

启动子模块，用于启动所述展示层对应的模板引擎；

加载子模块，用于采用所述模板引擎加载所述目录中的资源更新文件。

与背景技术相比，本申请实施例包括以下优点：

本申请实施例通过将展示层进行独立管理，在对展示层进行更新时，可以直接在展示层进行修改，发布资源更新文件，可以不用关心后端代码的更新，无需通过代码合并、编译、打包等复杂的传统发布过程，大大减少了发布的流程，加快了发布时间，同时，减少了更新的风险、提高了展示层的稳定性，大大提高了更新效率。

本申请实施例通过热加载的方式更新展示层，无需重启Web容器，在集群部署过程中无需进行停流量、重启Web容器、开启流量这样复杂的发布过程，大大提高了操作的简便性，进一步提高了更新效率。

本申请实施例在更新展示层时，发布增量文件，无需发布全量的发布包，大大减少了在发布过程的网络资源消耗。

附图说明

图1是一种传统的代码合并是示例图；

图2是一种传统的发布包的发布示例图；

图3本申请的一种Web应用的更新方法实施例的步骤流程图；

图4本申请的一种资源更新包的发布示例图；

图5是本申请的一种Web应用的更新装置实施例的结构框图；

图6是本申请的一种Web应用的更新系统实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

对于Web应用，为了便于开发、维护等要求，需要对Web应用逻辑划分层次。

一般都采用经典的MVC框架来划分层次。MVC(ModelViewController)把一个Web应用的输入、处理、输出流程按照模型(Model)－视图(View)－控制器(Controller)的方式进行分离，用一种业务逻辑、数据、界面显示分离的方法组织代码，这样一个Web应用可以被分成三个层——模型层、视图层、控制层。

视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML(HypertextMarkupLanguage，超文本标记语言)界面，但有可能为XHTML(TheExtensibleHyperTextMarkupLanguage，可扩展超文本标识语言)、XML(ExtensibleMarkupLanguage，可扩展标记语言)和Applet(小应用程序)。一个Web应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。

模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存(持续化)。比如将一张订单保存到数据库，从数据库获取订单，并可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。

控制(Controller)可以理解为接收用户请求,将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，清楚地说明其是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后,并不处理业务信息，它把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。

MVC将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。MVC分层同时也简化了分组开发，使得不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

而由于互联网产品发布快的行业特点，尤其是经常修改视图层，对于发布的周期有着非常紧迫的需求。

在传统的发布过程中，所有代码的修改，不区分是否修改视图层还是模型层和控制层，都使用如下统一的发布过程：

1、修改代码

开发人员申请代码版本管理工具(如subversion，SVN)主干(trunk)的分支(branch)，修改代码，经过开发测试过程，确保功能正确。

其中，主干可以是相对稳定版本的代码，分支可以是一种隔离项目的手段。多个分之可以并行开发，把代码最终都合并到主干上来。

改动较大的项目可以要在分支上进行，这样如果该项目有问题，不影响其他分支的开发，也不影响主干的运行，有问题的分支可以延期、甚至废弃。

一般情况下，诸如SVN等版本管理工具，可以包括主干(trunk)、分支(branch)和标记(tag)，使用方法可以如下：

trunk：可以用于Web应用主方向的开发。对于一个新模块的开发，可以采用trunk，当模块开发完成后，需要修改，可以采用branch。

branch：可以用于并行的开发，这里的并行是指和trunk进行比较。

tag：是用来做一个标记的，不管是不是发布版本，但都是一个可用的版本。

例如，某个Web应用的3.0版本开发完成，这个时候可以做一个tag，tag_release_3_0，然后基于这个tag做发布，比如安装程序等。trunk进入3.1版本的开发，但是3.0版本发现了漏洞bug，那么就需要基于tag_release_3_0做一个branch，branch_bugfix_3_0，基于这个branch进行漏洞修改，等到漏洞修改结束，做一个tag，tag_release_3_0_1，然后，根据需要决定branch_bugfix_3_0是否并入trunk。

2、代码合并

将分支的代码合并到主干，回归测试。

例如，如图1所示，当分支1中的项目开发测试完成，达到一个稳定的状态后，将分支1合并到主干；

主干进行集成测试，确认正常发布后从主干拷贝一份代码到tag下，因此tag下面的最新的分支即为线上稳定版本的Web应用；

此时，若有项目需要分支，该项目可以从tag的稳定版本打出分支，如分支2，进行开发。当分支2中的项目开发测试完成，达到一个稳定的状态后，将分支2合并到主干。

3、编译

由于后端逻辑的代码(如Java)要编译，因此，需要将修改过后的主干编译代码。

4、打包

将编译好的文件、配置文件及视图代码打成一个待发布的发布包，如图2所示，发布包一般包括ear包(即App.ear)和Htdocs(hostdocuments)。

其中，ear包中为模型层和控制层的代码，包括Java、XML等文件。

Htdocs是一个文件夹的命名，主要用来放视图层的文件，包括HTML、vm(模板文件)等文件。

5、分发

如图2所示，分发平台将打好的发布包发布到集群中的每一台服务器上。

6、部署

如图2所示，各服务器的应用容器(如jetty、jboss等)重启，重新加载所有的资源文件，修改过后的代码发布上线，应用在各服务器的Web应用，如Web应用1、Web应用2……Web应用n。

可以看到整个发布过程中，由于模型、视图、控制在开发和运行都是一个整体，无论修改什么代码，哪怕就是修改一个文案中的错别字，都要经过复杂的研发流程，这完全不符合互联网时代的发布时间要求。

并且，每次更新都需要发布Web应用的全量的发布包(ear包和Htdocs)，发布过程占用大量的网络资源。

在发布过程中，由于应用容器重启，无法对外提供服务。所以集群的发布过程需要停流量、重新部署、开启流量非常复杂的操作。这个过程由于不区分是否修改了业务逻辑，修改Java代码的业务逻辑风险非常高，每次重新部署会加载所有的资源文件，包括视图层的文件以及Java文件，造成每次发布的风险不可控，稳定性也有潜在的风险。

因此，创造性地提出了本申请实施例的核心构思之一，提出新的分层发布思路，单独发布后端代码和展现层代码，由于展现层代码轻薄，改动频繁，随时可以发布上线。

参照图3，示出了本申请的一种Web应用的更新方法实施例的步骤流程图，具体可以包括如下步骤：

步骤301，接收针对Web应用中独立的展示层的资源更新文件；

应用本申请实施例，可以基于分层设计思想对Web应用进行分层，分层设计是程序开发中一种常见的架构思想，由于程序代码经常变更，将代码分层可以将复杂问题分解简单化，每一层负责自己的实现，并向外提供服务层与层之间约定好接口，改动的时候只需要关心其中一层的变化，可以不用去关心其它层。

本申请实施例中，一个Web应用可以划分为至少两层，其中一层可以为展示层，另一层可以为应用层。

展示层可以用于加载Web应用中的交互界面，即用户看到并与之交互的界面。一个Web应用可能有很多不同的展示层，本申请实施例中的展示层可以用于视图上数据的采集和处理，以及处理用户的请求，而可以不包括在展示层上的业务流程的处理。业务流程的处理交予应用层处理。

互联网行业经常调整展现层内容，改变用户交互、文案等以提升用户体验或者发布新功能，由于互联网产品发布快的行业特点，对于发布的周期有着非常紧迫的需求。所述展示层中可以可以包括以下至少一种资源文件：

网页文档HTML、模板文件vm、图片、级联样式表CSS(CascadingStyleSheet)、脚本对象JS(JavaScript，脚本语言)等等。

其中，网页文档HTML可以通过标记符号来标记要显示的网页中的各个部分。网页文件本身是一种文本文件，通过在文本文件中添加标记符，可以告诉客户端(如浏览器)如何显示其中的内容(如：文字如何处理，画面如何安排，图片如何显示等)。

模板文件vm可以为开发Web应用的模板。

级联样式表CSS可以对网页中的对象的位置排版进行像素级的精确控制，支持几乎所有的字体字号样式，拥有对网页对象和模型样式编辑的能力，并能够进行初步交互设计。

脚本对象JS可以在HTML网页上使用，用来给HTML网页增加动态功能，例如响应用户的各种操作。其源代码在发往客户端(如浏览器)运行之前不需经过编译，而是将文本格式的字符代码发送给客户端(如浏览器)，由客户端(如浏览器)解释运行。

加载该资源文件可以实现界面的显示，而在加载时，本申请实施例可以对其记录加载时间，则所述资源文件可以具有加载时间(即加载该资源文件的时间)。

应用层可以为Web应用中除展示层外的代码集合，即Web应用中的后端代码。

若应用MVC的分层理念，应用层可以进一步划分为模型层和控制层。

模型层可以为业务流程/状态的处理以及业务规则的制定，模型接受展示层请求的数据，并返回最终的处理结果。模型中可以包括一个或多个数据模型，该数据模型主要指实体对象的数据保存(持续化)。

控制层可以接收请求,将模型层与展示层匹配在一起，共同完成请求。控制层明确其是一个分发器，选择什么样的数据模型，选择什么样的展示层，可以完成什么样的用户请求。

若应用其他分层理念，应用层可以进一步划分为其他层次，本申请实施例对此不加以限制。

在实际应用中，所述展示层可以与所述应用层相互独立。

具体而言，在开发展示层与应用层时，可以分别采用版本管理工具(如SVN)进行独立的开发，展示层和应用层各自可以具有独立的主干(trunk)，本申请实施例中可以对展示层和应用层进行隔离管理。

展示层比较轻薄，可以负责简单的显示逻辑处理，速度更快；应用层需要处理企业级开发，结构复杂，涉及的外部资源众多、事务密集、数据量大、用户数多，有较强的安全性考虑。

在运行时，所述展示层与所述应用层可以在同一个Web容器中运行。

Web容器可以是一种服务程序，可以由Web服务器来实现，为Web服务器(如JSP服务器，servlet服务器等)提供一个运行环境，使Web服务器直接跟容器中的环境变量接口交互，不必关注其他系统问题。

web容器可以是包括Java中的Tomcat，ASP(ActiveServerPage，动态服务器页面)的IIS或PWS等等。

传统的视图层一般包括展示层和应用层的部分代码。以java语言为例，视图层会有一部分视图处理的java代码，这部分代码如果要有变更，是要编译重启才能生效的。

在本申请实施例中，若开发人员基于业务需求对展示层进行修改，由于展现层代码比较轻薄，修改很简单，工作量小，所以可以在展示层的主干上修改代码，避免了代码合并的传统的发布过程。因此，展示层的配置管理策略可以是主干开发、主干发布。

开发人员在主干修改代码，经过开发、测试，保证功能正确，生成资源更新文件(Htdocs)，该资源更新文件可以具有修改时间，以标识该资源更新文件进行修改的时间。

所述资源更新文件可以为针对所述展示层中的资源文件进行更新的增量文件，具体可以包括以下至少一种资源文件：

网页文档HTML、模板文件vm、图片、级联样式表CSS(CascadingStyleSheet)、脚本对象JS(JavaScript，脚本语言)等等，即修改哪个资源文件就发布对应的资源更新文件。

由于后端代码也是独立管理，因此，在更新独立的展示层时，无需对资源更新文件进行编译、打包，可以直接发布资源更新文件。

本申请实施例通过将展示层进行独立管理，在对展示层进行更新时，可以直接在展示层进行修改，发布资源更新文件，可以不用关心后端代码的更新，无需通过代码合并、编译、打包等复杂的传统发布过程，大大减少了发布的流程，加快了发布时间，同时，减少了更新的风险、提高了展示层的稳定性，大大提高了更新效率。

本申请实施例在更新展示层时，发布增量文件，无需发布全量的发布包(ear包和Htdocs)，大大减少了在发布过程的网络资源消耗。

开发人员在制作完成资源更新文件后，可以通过发布平台将该资源更新文件分发到一个或多个服务器中，以进行安装在该服务器中Web应用展示层的更新。

需要说明的是，该一个或多个服务器可以为基于分布式架构的集群服务器，则发布平台可以通过分布式版本控制系统(例如Git)将该资源更新文件分发到一个或多个服务器中。

在本申请的一种优选实施例中，步骤302可以包括如下子步骤：

子步骤S11，将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

在实际应用中，展示层可以按照约定，在应用中按照功能划分各个模块，各个模块中的资源文件存储在各自对应的目录中。

例如，对于某个商务网站的展示层，其资源文件的目录结构可以如下所示：

其中，该展示层按照功能可以在模板文件(template)中划分为三个模块，分别为user(用户模块)、trade(交易模块)、consumerecord(交易记录模块)，每个模块具有各自对应的目录。其中，user(用户模块)可以用于加载与用户相关的界面，如用户登录、用户注册、帮助等等；trade(交易模块)可以用于加载与交易相关的界面，如支付等等；consumerecord(交易记录模块)可以用于加载交易记录的界面。当服务器接收到展现层的资源更新文件时，需要将该资源更新文件存储在指定的目录中，替换原有的资源文件，以便进行正常的加载，更新展示层。

子步骤S12，对所述资源更新文件配置修改时间。

资源更新文件一般具有修改时间，以表示对该资源更新文件进行最后修改的时间。

在本申请实施例中，该修改时间可以为服务器接收到该资源更新文件的时间。

步骤302，判断所述修改时间是否大于或等于上一次的加载时间；若是，则执行步骤303；

本实际应用中，可以在服务器的内存中存储每一个资源文件的最后加载时间(即上一次的加载时间)。

本申请实施例可以对Web应用的框架进行修改，以使得服务器可以定时或不定时扫描资源文件，若修改时间大于或等于上一次的加载时间，则可以认为资源更新文件的版本比资源文件的版本要新，需要对资源文件进行更新。

在具体实现中，修改时间和加载时间可以换算成秒数进行大小的比较，例如，修改时间为2014年9月29日17:35，加载时间为2014年9月28日23:42，此时该时间信息比加载时间大。

步骤303，在所述展示层中加载所述资源更新文件。

由于启动时加载了资源文件，放到了内存中，那么更改了这些资源文件时，必须要重新加载。本申请实施例若判断资源更新文件的修改时间大于或等于上一次资源文件的加载时间，则加载该资源更新文件，实现了热加载。

在本申请的一种优选实施例中，步骤303可以包括如下子步骤：

子步骤S21，启动所述展示层对应的模板引擎；

展示层可以按照固定的模板语言进行编译，而模板语言可以有多种，例如，Velocity、JSP(JavaServerPages)、FreeMaker等等。

以Velocity为例，Velocity的模板引擎在启动时，可以采用Velocity.init()或者新建VelocityEngine类的方式，调用RuntimeInstance类中的init方法，通过设置的模板引擎属性初始化模板引擎。

子步骤S22，采用所述模板引擎加载所述目录中的资源更新文件。

在具体实现中，在应用中可以配置模板引擎的属性resourceLoaderPath告诉模板引擎到哪个目录寻找展示层的模板文件及资源更新文件，如config.xml、css.vm、js.vm文件。

Web应用加载了被分发到服务器上的资源更新文件，实现修改过后的展现层发布上线。

本申请实施例通过热加载的方式更新展示层，无需重启Web容器，在集群部署过程中无需进行停流量、重启Web容器、开启流量这样复杂的发布过程，大大提高了操作的简便性，进一步提高了更新效率。

为使本领域技术人员更好地理解本申请实施例，以下通过具体的示例来说明本申请实施例中Web应用的更新方法。

如图4所示，根据业务需求，开发人员对Web应用中独立的展示层进行修改，需要在某个电子商务网站的支付工具界面中增加一段文案提醒：“充值送红包”。

技术人员可以在Web应用的资源文件i.vm中增加该文案提醒，并提供代码。该代码经测试通过后，生成资源更新文件(Htdocs，即i.vm)，技术人员在发布平台中查找发布单，确定只需要发布某个目录下的i.vm。在发布平台通过Git将资源更新文件(Htdocs，即i.vm)分发到各个服务器中，在各个服务器中的Web应用(如Web应用1、Web应用2……Web应用n)中包括独立的应用层(App.ear)和展示层(Htdocs)，在展示层中通过热加载的方式加载资源更新文件(Htdocs，即i.vm)，实现修改过后的展现层发布上线。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图5，示出了本申请一种Web应用的更新装置实施例的结构框图，具体可以包括如下模块：

资源更新文件接收模块501，用于接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

时间判断模块502，用于判断所述修改时间是否大于或等于上一次的加载时间；若是，则调用资源更新文件加载模块503；

资源更新文件加载模块503，用于在所述展示层中加载所述资源更新文件。

在具体实现中，所述展示层可以用于加载Web应用中的交互界面；

所述展示层中包括以下至少一种资源文件：

网页文档、模板文件、图片、级联样式表、脚本对象。

在实际应用中，所述资源更新文件为针对所述展示层中的资源文件进行更新的增量文件。

在本申请的一种优选实施例中，所述资源更新文件接收模块501可以包括如下子模块：

存储子模块，用于将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

配置子模块，用于对所述资源更新文件配置修改时间。

在本申请的一种优选实施例中，所述资源更新文件加载模块503可以包括如下子模块：

启动子模块，用于启动所述展示层对应的模板引擎；

加载子模块，用于采用所述模板引擎加载所述目录中的资源更新文件。

在本申请的一种优选实施例中，所述Web应用还包括应用层，所述展示层与所述应用层相互独立，所述展示层与所述应用层在同一个Web容器中运行。

参照图6，示出了本申请一种Web应用的更新系统实施例的结构框图，所述系统可以包括发布平台610和一个或多个服务器620；

其中，所述发布平台610可以包括如下模块：

资源更新文件发布模块611，用于发布针对Web应用中独立的展示层的资源更新文件；

所述服务器620可以包括如下模块：

资源更新文件接收模块621，用于接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

时间判断模块622，用于判断所述修改时间是否大于或等于上一次的加载时间；若是，则调用资源更新文件加载模块623；

资源更新文件加载模块623，用于在所述展示层中加载所述资源更新文件。

在具体实现中，所述展示层可以用于加载Web应用中的交互界面；

所述展示层中包括以下至少一种资源文件：

网页文档、模板文件、图片、级联样式表、脚本对象。

在实际应用中，所述资源更新文件为针对所述展示层中的资源文件进行更新的增量文件。

在本申请的一种优选实施例中，所述资源更新文件接收模块621可以包括如下子模块：

存储子模块，用于将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

配置子模块，用于对所述资源更新文件配置修改时间。

在本申请的一种优选实施例中，所述资源更新文件加载模块623可以包括如下子模块：

启动子模块，用于启动所述展示层对应的模板引擎；

加载子模块，用于采用所述模板引擎加载所述目录中的资源更新文件。

在本申请的一种优选实施例中，所述Web应用还包括应用层，所述展示层与所述应用层相互独立，所述展示层与所述应用层在同一个Web容器中运行。

对于装置、系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种Web应用的更新方法、一种Web应用的更新装置和一种Web应用的更新系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (11)

1.一种Web应用的更新方法，其特征在于，包括：

接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

判断所述修改时间是否大于或等于上一次的加载时间；若是，则在所述展示层中加载所述资源更新文件。

2.根据权利要求1所述的方法，其特征在于，所述展示层用于加载Web应用中的交互界面；

所述展示层中包括以下至少一种资源文件：

网页文档、模板文件、图片、级联样式表、脚本对象。

3.根据权利要求1所述的方法，其特征在于，所述资源更新文件为针对所述展示层中的资源文件进行更新的增量文件。

4.根据权利要求1或2或3所述的方法，其特征在于，所述接收针对Web应用中独立的展示层的资源更新文件的步骤包括：

将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

对所述资源更新文件配置修改时间。

5.根据权利要求4所述的方法，其特征在于，所述在所述展示层中加载所述资源更新文件的步骤包括：

启动所述展示层对应的模板引擎；

采用所述模板引擎加载所述目录中的资源更新文件。

6.根据权利要求1或2或3或5所述的方法，其特征在于，所述Web应用还包括应用层，所述展示层与所述应用层相互独立，所述展示层与所述应用层在同一个Web容器中运行。

7.一种Web应用的更新装置，其特征在于，包括：

资源更新文件接收模块，用于接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

时间判断模块，用于判断所述修改时间是否大于或等于上一次的加载时间；若是，则调用资源更新文件加载模块；

资源更新文件加载模块，用于在所述展示层中加载所述资源更新文件。

8.根据权利要求7所述的装置，其特征在于，所述展示层用于加载Web应用中的交互界面；

所述展示层中包括以下至少一种资源文件：

网页文档、模板文件、图片、级联样式表、脚本对象。

9.根据权利要求7或8所述的装置，其特征在于，所述资源更新文件接收模块包括：

存储子模块，用于将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；

配置子模块，用于对所述资源更新文件配置修改时间。

10.根据权利要求9所述的装置，其特征在于，所述资源更新文件加载模块包括：

启动子模块，用于启动所述展示层对应的模板引擎；

加载子模块，用于采用所述模板引擎加载所述目录中的资源更新文件。

11.一种Web应用的更新系统，其特征在于，所述系统包括发布平台和一个或多个服务器；

其中，所述发布平台包括：

资源更新文件发布模块，用于发布针对Web应用中独立的展示层的资源更新文件；

所述服务器包括：

资源更新文件接收模块，用于接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；

时间判断模块，用于判断所述修改时间是否大于或等于上一次的加载时间；若是，则调用资源更新文件加载模块；

资源更新文件加载模块，用于在所述展示层中加载所述资源更新文件。