CN105302586A - 软件升级处理方法、装置、终端及服务器 - Google Patents

Abstract

本发明提供了一种软件升级处理方法、装置、终端及服务器，其中，该方法包括：将待升级的软件划分为一个或多个软件服务单元；提取用于丰富一个或多个软件服务单元的一个或多个适配元件；依据预定注入策略将一个或多个适配元件注入到对应的软件服务单元中，通过本发明，解决了相关技术中，软件升级存在复杂度高，升级效率低下的问题，进而达到了大大减少了软件升级的复杂度，提高了软件升级效率的效果。

Description

软件升级处理方法、装置、终端及服务器

技术领域

本发明涉及通信领域，具体而言，涉及一种软件升级处理方法、装置、终端及服务器。

背景技术

随着软件规模的扩大，其可维护性也随之降低，最终将导致软件更新的复杂度增加。例如，软件中某项服务需要更新升级，那么此项服务所涉及的需要全部被替换为更新后的内容。复杂服务的更新导致升级过程－－下载、替换、重启、重新装配的效率低下，复杂的软件规模亦是如此。

为了提升下载、替换速率，在线差分升级功能在一定程度上减少了下载量，降低了升级的复杂度。随之带来的问题是提高了差分包制作以及用户跨升级包更新，究其根本原因在于：软件***在更新过程中，更新模块所涉及的所有内容都需要被更新，更新粒度高。

因此，在相关技术中，软件升级存在复杂度高，升级效率低下的问题。

发明内容

本发明提供了一种软件升级处理方法、装置、终端及服务器，以至少解决相关技术中，软件升级存在复杂度高，升级效率低下的问题。

根据本发明的一个方面，提供了一种软件升级处理方法，包括：将待升级的软件划分为一个或多个软件服务单元；提取用于丰富所述一个或多个软件服务单元的一个或多个适配元件；依据预定注入策略将所述一个或多个适配元件注入到对应的软件服务单元中。

优选地，所述预定注入策略包括以下至少之一：顺序性策略、过滤性策略、阻截性策略、确定性策略、融合性策略、导航性策略、同步性策略。

优选地，将待升级的所述软件划分为所述软件服务单元包括：将所述软件的软件内容依据业务流程和技术方向进行分割；将在业务流程上具有逻辑关系，技术方向单一的核心功能划分为一个软件服务单元。

优选地，在依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元中之前，还包括：对正在运行的软件操作流程进行监控；判断依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元是否影响所述软件操作流程，在判断结果为否的情况下，依据所述一个或多个适配元件注入到对应的所述软件服务单元中。

优选地，依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元中包括：依据预定的映射机制映射出所述软件服务单元与所述适配单元的内部结构；依据所述预定注入策略，以及所述软件服务单元与所述适配单元的内部结构生成代理服务单元类源文件；对所述代理服务单元类源文件进行编译获得完整代理服务单元类。

优选地，在对所述代理服务单元类源文件进行编译获得所述完整代理服务单元类之后，还包括：对所述软件服务单元、所述适配单元、所述预定注入策略对应的所述完整代理服务单元类进行存储。

优选地，在对所述代理服务单元类源文件进行编译获得所述完整代理服务单元类之后，还包括：对所述完整代理服务单元类进行核查。

根据本发明的另一方面，提供了一种软件升级处理装置，包括：划分模块，用于将待升级的软件划分为一个或多个软件服务单元；提取模块，用于提取用于丰富所述一个或多个软件服务单元的一个或多个适配元件；注入模块，用于依据预定注入策略将所述一个或多个适配元件注入到对应的软件服务单元中。

优选地，所述划分模块包括：分割单元，用于将所述软件的软件内容依据业务流程和技术方向进行分割；划分单元，用于将在业务流程上具有逻辑关系，技术方向单一的核心功能划分为一个软件服务单元。

优选地，该装置还包括：监控模块，用于对正在运行的软件操作流程进行监控；判断模块，用于判断依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元是否影响所述软件操作流程，在判断结果为否的情况下，依据所述一个或多个适配元件注入到对应的所述软件服务单元中。

优选地，所述注入模块包括：映射单元，用于依据预定的映射机制映射出所述软件服务单元与所述适配单元的内部结构；生成单元，用于依据所述预定注入策略，以及所述软件服务单元与所述适配单元的内部结构生成代理服务单元类源文件；编译单元，用于对所述代理服务单元类源文件进行编译获得完整代理服务单元类。

优选地，该装置还包括：存储单元，用于对所述软件服务单元、所述适配单元、所述预定注入策略对应的所述完整代理服务单元类进行存储。

优选地，该装置还包括：核查单元，用于对所述完整代理服务单元类进行核查。。

根据本发明的另一方面，还提供了一种终端，包括上述任一项所述的装置。

根据本发明的再一方面，提供了一种服务器，包括上述任一项所述的装置。

通过本发明，采用将待升级的软件划分为一个或多个软件服务单元；提取用于丰富所述一个或多个软件服务单元的一个或多个适配元件；依据预定注入策略将所述一个或多个适配元件注入到对应的软件服务单元中，解决了相关技术中，软件升级存在复杂度高，升级效率低下的问题，进而达到了大大减少了软件升级的复杂度，提高了软件升级效率的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的软件升级处理方法的流程图；

图2是根据本发明实施例的软件升级处理装置的结构框图；

图3是根据本发明实施例的软件升级处理装置中划分模块22的优选结构框图；

图4是根据本发明实施例的软件升级处理装置的优选结构框图；

图5是根据本发明实施例的软件升级处理装置中注入模块26的优选结构框图一；

图6是根据本发明实施例的软件升级处理装置中注入模块26的优选结构框图二；

图7是根据本发明实施例的软件升级处理装置中注入模块26的优选结构框图三；

图8是根据本发明实施例的终端的结构框图；

图9是根据本发明实施例的服务器的结构框图；

图10是根据本发明实施例的快速升级普适框架示意图；

图11是根据本发明实施例的软件服务单元规划的流程图；

图12是根据本发明实施例的本地***的主要模块示意图；

图13是根据本发明实施例的代理类工厂的核心类图；

图14是根据本发明实施例的代理类工厂动态生成代理类服务单元的流程图；

图15是根据本发明实施例的配置单元的逻辑结构图；

图16是根据本发明实施例的终端与服务器的交互升级流程图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在本实施例中提供了一种软件升级处理方法，图1是根据本发明实施例的软件升级处理方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，将待升级的软件划分为一个或多个软件服务单元；

步骤S104，提取用于丰富一个或多个软件服务单元的一个或多个适配元件；

步骤S106，依据预定注入策略将一个或多个适配元件注入到对应的软件服务单元中，需要说明的是，该预定注入策略可以包括多种，例如，可以为以下至少之一：顺序性策略、过滤性策略、阻截性策略、确定性策略、融合性策略、导航性策略、同步性策略。

通过上述步骤，依据预定注入策略将适配元件注入到软件服务单元中的方式实现软件升级，相对于相关技术中，对软件升级需求对整个软件下载，替换、重启、配置的整套的不仅软件升级存在复杂度高，升级效率低下的问题，进而达到了大大减少了软件升级的复杂度，提高了软件升级效率的效果。

在将待升级的软件划分为软件服务单元时，也可以采用多种方式，较优地，可以采用以下处理方式：将软件的软件内容依据业务流程和技术方向进行分割；将在业务流程上具有逻辑关系，技术方向单一的核心功能划分为一个软件服务单元。

为了保证升级过程不影响到软件的用户对软件的正常使用，可以在依据预定注入策略将一个或多个适配元件注入到对应的软件服务单元中之前，对正在运行的软件操作流程进行监控；判断依据预定注入策略将一个或多个适配元件注入到对应的软件服务单元是否影响软件操作流程，在判断结果为否的情况下，依据一个或多个适配元件注入到对应的软件服务单元中。采用这样的处理，可以有效避免升级流程带来的体验降低的问题。

优选地，依据预定注入策略将一个或多个适配元件注入到对应的软件服务单元中时，可以采用以下处理方式：依据预定的映射机制映射出软件服务单元与适配单元的内部结构；依据预定注入策略，以及软件服务单元与适配单元的内部结构生成代理服务单元类源文件；对代理服务单元类源文件进行编译获得完整代理服务单元类。为了使得避免对软件重复升级，在对代理服务单元类源文件进行编译获得完整代理服务单元类之后，还可以对软件服务单元、适配单元、预定注入策略对应的完整代理服务单元类进行存储。之后，如果再接收到对该同样的软件，依据同样的适配单元，采用同样的预定注入策略进行升级时，直接可以提取存储的该完整代理服务单元类。采用这样的处理，大大提高了软件升级的效率。

另一方面，为了保证软件升级的质量，在对代理服务单元类源文件进行编译获得完整代理服务单元类之后，还可以对完整代理服务单元类进行核查，例如，可以对升级完成后获得的完整代理服务单元类进行类型、语法、装配、规则分别进行核查。

在本实施例中还提供了一种软件升级处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图2是根据本发明实施例的软件升级处理装置的结构框图，如图2所示，该装置包括划分模块22、提取模块24和注入模块26，下面对该装置进行说明。

划分模块22，用于将待升级的软件划分为一个或多个软件服务单元；提取模块24，连接至上述划分模块22，用于提取用于丰富一个或多个软件服务单元的一个或多个适配元件；注入模块26，连接至上述提取模块24，用于依据预定注入策略将一个或多个适配元件注入到对应的软件服务单元中。

图3是根据本发明实施例的软件升级处理装置中划分模块22的优选结构框图，如图3所示，该划分模块22包括：分割单元32和划分单元34，下面对该划分模块22进行说明。

分割单元32，用于将软件的软件内容依据业务流程和技术方向进行分割；划分单元34，连接至上述分割单元32，用于将在业务流程上具有逻辑关系，技术方向单一的核心功能划分为一个软件服务单元。

图4是根据本发明实施例的软件升级处理装置的优选结构框图，如图4所示，该装置除包括图2所示的结构外，还包括：监控模块42和判断模块44，下面对该装置进行说明。

监控模块42，连接至上述提取模块24，用于对正在运行的软件操作流程进行监控；判断模块44，连接至上述监控模块42和注入模块26，用于判断依据预定注入策略将一个或多个适配元件注入到对应的软件服务单元是否影响软件操作流程，在判断结果为否的情况下，依据一个或多个适配元件注入到对应的软件服务单元中。

图5是根据本发明实施例的软件升级处理装置中注入模块26的优选结构框图一，如图5所示，该注入模块26包括：映射单元52、生成单元54和编译单元56，下面对该注入模块26进行说明。

映射单元52，用于依据预定的映射机制映射出软件服务单元与适配单元的内部结构；生成单元54，连接至上述映射单元52，用于依据预定注入策略，以及软件服务单元与适配单元的内部结构生成代理服务单元类源文件；编译单元56，连接至上述生成单元54，用于对代理服务单元类源文件进行编译获得完整代理服务单元类。

图6是根据本发明实施例的软件升级处理装置中注入模块26的优选结构框图二，如图6所示，该装置除包括图5所示的所有模块外，还包括存储单元62，下面对该存储单元62进行说明。

存储单元62，连接至上述编译单元56，用于对软件服务单元、适配单元、预定注入策略对应的完整代理服务单元类进行存储。

图7是根据本发明实施例的软件升级处理装置中注入模块26的优选结构框图三，如图7所示，该装置除包括图5所示的所有模块外，还包括核查单元72，下面对该核查单元72进行说明。

核查单元72，连接至上述编译单元56，用于对完整代理服务单元类进行核查。。

图8是根据本发明实施例的终端的结构框图，如图8所示，该终端80包括上述任一项的软件升级处理装置82。

图9是根据本发明实施例的服务器的结构框图，如图9所示，该服务器90包括上述任一项的软件升级处理装置82。

针对相关技术中，软件升级存在复杂度高，升级效率低下的问题，在本实施例中，提供了一种提高升级效率的普适框架；包括软件服务单元划分方法、适配元件提取、动态装配引擎、现场控制等。该框架的优点在于：当前服务单元与升级后的服务单元的细微差异可以通过粘合注入不同的适配元件来消除，既降低了单个服务单元的复杂性也减少了服务的数量。另外一方面，对于开发新的服务单元的需求，可以先考虑通过现有服务单元及适配元件组装成符合用户新需求的服务，以减少新需求对于软件***的影响。对于开发者来说，相较于服务单元来说，适配元件的设计和开发任务量较少，且易维护，同时通过动态装配引擎，可以通过修改现有适配元件或增加新的适配元件来达到修改服务功能的目的，而不是增加新的服务单元或修改服务单元。由此可见，通过此方案的升级过程，下载量以及更新复杂度将进一步降低。从软件设计阶段开始到最终升级过程，规划软件的可扩展性，提高软件的可维护性，从而最终提升软件升级效率。

针对相关技术中，软件规模的扩大，软件的可维护性随之下降，导致更新模块粒度升高，最终使得软件升级过程复杂度提高，降低升级效率以及影响用户体验的问题，通过上述粘合注入方法在软件可扩展性的应用以提高软件升级效率。下面对该粘合注入的方法进行说明。

当软件***运行过程中，用户请求服务单元提供功能时，动态装配引擎将实时将服务单元、适配元件、以及注入策略动态组装为“完整服务单元”提供给用户。服务单元的适配元件以及注入策略可灵活改变，通过动态装配引擎可装配出具备新功能的“完整服务单元”，最终，使得软件***更新为升级后的版本。

服务单元为当前业务领域的软件需求中具有相对独立功能的部分，它只涉及基础功能。适配元件为某一服务单元的扩展功能部分，它的注入功能部分与其被注入服务单元的接口必须具备一定的相容性。适配元件需要通过注入策略注入到相应服务单元中，以扩展其功能。注入策略的主要内容为适配元件注入服务单元的格式说明，包括：适配元件的注入方法入口、适配元件接口、装配形式等。

动态装配引擎主要功能是根据某一服务单元的内部结构、其适配元件的内部结构、以及注入策略的格式说明，动态生成新的服务单元。其核心组件包括：反射部件、编译部件、加载部件、实例化部件、以及缓存部件。反射部件的主要功能是通过反射机制，映射出服务单元和适配元件的内部结构。其他部件完成动态生成的完整服务类文件的编译、加载、实例化，以及缓存一系列过程。

在粘合注入方法指导下，需将软件需求功能划分为独立的服务单元和适配元件，通过动态装配引擎，读取最新的配置文档，实时为用户装配出更新后的软件***。升级过程不影响用户当前的处理操作，现场控制模块将保存和处理用户当前操作，整个升级过程对用户透明。图10是根据本发明实施例的快速升级普适框架示意图，如图10所示，该框架主要包括以下几个部件：现场控制(EC)、服务单元类管理(SCM)、适配元件类管理(CCM)、注入策略控制(PSC)、装配核查(AC)、升级管理(UM)、动态装配引擎(DLE)。下面针对各个部件分别进行说明。

软件服务单元规划

服务单元规划思路从两点出发；服务内容和服务粒度。服务内容应从具体的业务范畴去定义，使服务功能更切合具体领域中业务流程的实际情况，而服务的粒度方面，则应保证拥有业务原子性与技术原子性的基础上，保持最低的细粒度。图11是根据本发明实施例的软件服务单元规划的流程图，如图11所示，该流程包括如下步骤：

第一步：全面收集；将具体业务领域内的所示知识进行收集、分析、总结。全面了解该业务范畴，分解出每个关键业务活动在业务领域中的逻辑依赖关系。

第二步：服务单元分割；从业务方面和技术方面将全面收集的内容进行分割。业务方面；以业务目的为界限将业务活动中包括的“最小”功能划分出来。这样一来，保证划分出来的最小业务功能在具体的业务领域中具有合法的流程单元意义。技术方面；从技术的维度去分割出服务单元主要是服务于从业务角度分割出的服务单元。技术服务单元的服务范围应与具体业务内容独立，同时保持其最小原子性以提高技术服务单元在软件***的复用性。

第三步：组合并归；首先，将在业务流程上具有较强逻辑依赖关系以及技术服务单元的服务方向单一的核心功能划归为单个服务单元。依赖关系包括前向依赖即A->B、后向依赖A<-B、双向依赖A<->B，其中双向依赖的依赖关系最强。将复用度不高的服务单元并归为一个服务单元，虽然导致粗粒度的服务产生，但是，此服务单元为稳定性较高的服务，应避免在软件***中通过动态装配引擎动态生成，提高***的运行效率，由其在分布式环境中部署的软件***。

服务单元接口的定义要注意耦合性与可注入性，降低耦合性有利于独立扩展，提高可适配性，则可方便地适配元件。服务的具体实现应以服务基本目的为参照，即只关注当前服务定义中所必要的需求，而不关注将来可能需要的扩展功能。

适配元件提取

适配元件提取过程建立在相对单独的服务单元的基础之上，目的在于丰富服务单元某方面的功能。完整服务单元的功能包括：基本业务功能和扩展功能部分。基本业务功能在软件服务单元规划阶段中涉及。扩展功能部分由适配元件完成。元件定义的目的；第一，丰富当前服务单元，以满足当前用户需求。第二，协调服务间、元件间、以及服务与元件间的逻辑关系，以满足当前业务流程。只要服务与元件之间的接口定义地较合理－－尤其是可扩展性方面，那么，服务单元的扩展功能可以无限增加。至此阶段，软件***变成“单服务实例多装配元件”的粘合注入运行模式。表1是根据本发明实施例的经过软件服务单元规划和适配元件提取阶段后，完成的服务单元扩展表，如表1所示。

表1

通过此表格，可以全面了解当前整个软件***中的单独服务单元及其可适配元件的组合情况。此后，如***中某项服务需要更新时，由动态装配引擎由更新元件动态注入服务中，装配后的“完整”服务单元实例为用户提供服务功能，并且动态产生的新服务单元类的整个过程对于客户和运行中的软件业务***来说是完全透明的。

至此，软件***可根据存储于本地的服务扩展结构，由动态装配引擎、现场控制等本地***完成启动、运行、升级等一系列过程，图12是根据本发明实施例的本地***的主要模块示意图，如图12所示。

代理类工厂

代理类工厂模块包括反射部件、编译部件、加载部件、实例化部件、缓存部件。

反射部件；通过反射机制，获得被注入服务单元类的内部整体结构，其中主要包括：方法名称、方法的参数列表、修饰器(诸如public,private,static等等)、superclass(如Object)、实现的interfaces(如Serializable)、fields。通过反射部件最主要的是得到被装配服务单元类内部中的方法集。方法集为适配元件类的注入对象。具有反射机制的主流开发语言有Java和C#。

编译部件；被代理服务类的源文件需要经过动态编译，生成运行文件后，才能在软件***中运行。运行文件的存放方式主要有两种；第一种，被经过编译后的文件存储在硬盘中，这种情况不会占大量的内存，但需要经过加载到内存的过程，效率低下，而且，会产生大量的编译文件。第二种，存放到内存中，这种情况的效率较高，但如果动态生成代理服务单元类将会占用大量的内存，可能导致内存泄漏。在Java开发语言方面，主流编译工具有JavaCompiler、CGLIB、ASM。在C#开发语言方面，Microsoft.Csharp命名空间里有一个CSharpCodeProvider类提供对C#代码生成器和编译器的实例访问。

加载部件；代理服务单元类的运行文件需要通过加载部件生成相应的class。类文件的加载方式应多种多样，不应只局限于加载classpath路径下的文件。

实例化部件；生成的class将通过实例化部件产生此类的对象返回给业务层逻辑。

缓存部件；为了提高代理服务单元类的生成效率，将缓存条目；服务单元类ID、适配元件类ID、注入策略类ID，存储在缓存部件中，当实时获得代理服务单元类的接口被调用时，将先检索缓存部件，如已存在有相同的服务单元类被同样的适配元件类及注入策略装配，将直接把存储于缓存部件中的代理服务单元类的对象返回。缓存部件的退出机制的主要参考因素包括：内存容量、代理服务单元类的对象产生的次数等。

图13是根据本发明实施例的代理类工厂的核心类图，如图13所示，服务单元类Service和代理服务单元类ProxyService都实现接口Serviced，适配元件类Logger实现接口Component。Policy接口中GetSMethodName方法得到被装配服务类中被装配的方法名；SetSMethodName方法用于设置被装配服务类中被装配的方法名；GetPMethodName方法得到装饰适配元件类中装饰方法名；SetPMethodName方法用于设置装饰适配元件类中装饰方法名；注入策略类Vertical实现接口Policy，不同类型的注入策略类都实现同一的策略接口Policy。服务单元管理类ServicedMgr和适配元件管理类ComponentMgr各自控制服务单元类Serviced及适配元件类Component的注册、装载以及统筹。为了通过服务单元类ID和适配元件类ID而获得服务单元类和适配元件类源文件，代理工厂类ProxyFactory聚合包含了一个服务单元管理类对象和一个适配元件管理类对象。代理工厂类中的newInstance()方法将顺序调用缓存部件接口、反射部件接口、编译部件接口、加载部件接口、实例化部件接口，最后生成代理服务类对象。其中，代理服务类与服务单元类都实现同一的服务接口Serviced，而且，代理服务类聚合一个被装配服务单元类对象和适配元件对象。

图14是根据本发明实施例的代理类工厂动态生成代理类服务单元的流程图，如图14所示，粘合注入***中所有客户的公共流程为：①->②->③。首先，客户向代理类工厂提供服务单元ID、适配元件ID、注入策略ID以得到代理服务类对象。然后，代理类工厂使用“服务单元ID+适配元件ID+注入策略ID”组合结构到缓存部件中去检索相应代理服务类对象。如果找到了相应对象，则直接执行⑩，由代理类工厂将对象返回给客户。反之，如果在缓存部件中找到不相应对象，则执行④->⑤->⑥->⑦->⑧->⑨一系列流程。

注入策略控制

代理类工厂中的反射部件生成代理服务类源文件时，需要通过注入策略类将适配元件注入相应的服务单元类当中。根据不同特性的服务单元，使用不同类型的策略提供给适配元件，以便有效的装配服务单元。为了弥补服务单元的公共属性与当前客户的新式属性之间的矛盾，适配元件类可以在功能方面弥补服务单元在所提供的功能上的不足，而注入策略则在弥补形式上为适配元件注入服务提供注入标准。一种注入策略类型为一类适配元件类形式服务，为了弥补每项服务的不足，一个或多个适配元件可以通过一种或多种策略类型注入服务单元类。

类型规划包含顺序性策略、过滤性策略、阻截性策略、确定性策略、融合性策略、导航性策略、同步控制性策略。

顺序性策略；服务单元类与注入适配元件具有逻辑前后关系且依赖性差。装配形式：service.execute()->plug.execute()或者反之。应用场景：具有垂直关系，如日志、事务或权限、主体服务在业务流程中不受影响。

过滤性策略；服务单元类执行完成的结果需要被注入适配元件再次经过过滤得到最后结果并且之间的依赖性高。装配形式如：plug.execute(service.execute())。应用场景：组合查询。

阻截性策略；服务单元类的接收信息需要被注入适配元件阻截部分内容，当服务单元类执行完成之后，被阻截的内容需要与服务单元类的返回内容结合传给下一个处理流程。装配形式：plug.intercept()->service.execute()->plug.giveBack()。应用场景：当前调用服务类单元的用户的权限发生改变，敏感内容需要对该用户透明。

确定性策略；服务单元类的整个执行过程中调用了注入适配元件的功能，在代理服务单元类被生成之前，不确定具体的适配元件类对象。装配形式：service.execute(plug)。应用场景：当前服务单元类的调用对象或是被处理对象发生改变，该对象应由注入适配元件承担。

融合性策略；前一服务单元类的处理后的信息与后一个服务单元类的接收信息不相容，导致它们在目前业务流程上不具有逻辑关系，此时，需要通过注入适配元件将它们嫁接合并，消除它们之间的不相容性。装配形式：serviceA.execute()->plug.execute()->serviceB.execute()。应用场景：当前整个业务流程的个数不发生改变，但流程的逻辑顺序需要改变。

导航性策略；当前服务单元类处理完成后的结果，具体接收此结果的下一下服务单元类自己不明确，而由注入适配元件来确定。装配形式：service.execute()->plug.navigate()。应用场景：下一个业务流程需要对当前处理流程透明。

同步控制性策略；服务单元类在处理当前流程之前，需要根据当前的流程状态来采取具体处理流程。判断当前流程的状态不仅和当前服务单元类的本身状态相关，而且和其他并发业务流程或普遍元素，如时间等相关，具体的注入适配元件类指出流程的当前状态。装配形式：status＝plug.evaluate(affairs)->service.execute(affairs,status)。应用场景：并发业务流程之间需要协调。

装配管控；模拟当前开发人员为适配元件类选择的注入策略生成服务单元类逻辑，帮助开发人员防止不合法或不符合业务要求服务单元类的产生。

装配核查

类型过滤器；核查代理服务单元类的字符串中是否出现继承类型的错误，考查的标准是代理服务单元类的父类是否与被代理服务单元类的父类相同，否则，返回到业务层逻辑的代码中将会出现类型不相容的错误。

语法过滤器；核查生成的代理服务单元类的字符串中的基本语法错误。避免代理类工厂中的编译部件将产生引用不完整错误或其他非致使性错误。

装配过滤器；主要检查并修正一些适配元件在装配服务时，所生成语句的错误。生成语句与上一语句或下一语句不匹配。

规则过滤器；此过滤器指在为开发人员将来提供增加核查条目提供接口。只有不断完善的规则过滤器才能保证不必要的不合法错误出现在编译阶段，因为在编译阶段的错误是不可逆的，所以，只有尽可能的在装配核查阶段发现错误，并修正语法错误。

一般地，当装配核查模块检查出不相容错误时，需及时修正配置文档中的错误。并返回给服务器，当前升级版本中的适配元件与选取的注入策略不合法。

现场控制

当客户端收到服务器的更新版本指令时，需要保护用户当前处理现场，以保证旧版本的流程与新版本的升级同时进行且互不影响，以达到静默升级，真正对用户透明。

***；跟踪记录用户当前业务操作进程，用于判断升级后的服务单元是否会影响用户当前和后续的业务流程。一般地，在业务流程开始前或结束后，各个服务单元类可被全部更新升级。

响应器；接收服务器端的升级服务单元类、适配元件类、注入策略类、以及相应的配置文档，并且增加、替换、删除相应类型文件，在这一过程中，修改操作需要与记录器进行交互，如影响到当前业务流程，需要缓存所涉及文档，并在***中建立观察者，以便当影响行为不存在时，再继续修改操作。

控制器；加载缓存配置文档；第一，软件***启动时，首先，将整个***的中的服务单元类以及其附加的适配元件类和注入策略类等配置信息加载至内存，以便***运行时，动态生成代理服务单元类。第二，当响应器更新本地文件过程完成时，重载加载配置文档以替换缓存中的副本。

服务器端部署与客户端配置文档

在服务器端，图15是根据本发明实施例的配置单元的逻辑结构图，如图15所示，该服务单元类、适配元件类、注入策略类(以下称为配置单元)信息存储在数据库的逻辑结构。服务单元类以及其附加的信息都以被序列化存储在数据库中。

服务端升级程序主要有两部分组成；第一，版本记录器：记录当前版本与前一版本修改了哪些配置单元。第二，推送器：将客户端的版本信息与需要升级的版本信息发给版本记录器进行对比，得到客户端需要修改的配置单元列表，根据此列表，从数据库中查找到配置单元的序列化项，并生成配置文档修改项一并推送给客户端程序中的现场控制部件的响应模块。表2是根据本发明实施例的升级包JSON推送格式示意表，如表2所示：

表2

其中，升级所需的配置单元序列主要包含各个单元的文件名,以及源文件的序列化结果键值对。配置文档主要包含了各个代理服务单元类编号，以及需要更新的配置单元组合键值对。

客户端配置文档存储格式可采用以下语言表述：

<itemID＝”1”service＝”com.flexible.service.Register”plug＝”com.flexible.component.Checker”policy＝”com.flexible.policy.Intercept”/>

<itemID＝”2”service＝”com.flexible.service.Saver”plug＝”com.flexible.component.Log”policy＝”com.flexible.policy.Order”/>

……

<itemID＝”N”service＝”com.flexible.service.Index”plug＝”com.flexible.component.Enhance”policy＝”com.flexible.policy.Filter”/>

其中，每个代理服务单元项都由编号、服务单元类名、适配元件类名、注入策略类名组成，编号是动态装配引擎和响应器修改配置文档的入口。

图16是根据本发明实施例的终端与服务器的交互升级流程图，如图16所示，该流程包括如下步骤：

S1，在客户端，现场控制中响应器向服务器端升级程序发送当前客户端软件版本信息。

S2，服务器端升级程序将客户端的版本信息与当前需要升级的版本交给版本记录器进行对比分析。

S3，版本记录器返回客户端更新至升级版本所需要修改的服务单元类、适配元件类、注入策略类。

S4，将配置单元详细信息列表交给推送器以对数据库进行查询。

S5，按照数据库查询结果生成对应的配置文档调整项，并将其与修改配置单元序列化转化为JSON数据返回给客户端响应器。

S6，解析JSON数据，将配置文档调整项数据交给***进行对实时业务流程的影响分析，并将响应器中的观察者***注册到***中，当业务流程发生变化的同时，响应器可对更新处理过程进行调整。

S7，将当前升级版本所需修改配置单元对实时业务流程影响结果返回给响应器。业务流程影响结果主要包括：是否影响当前业务流程、哪些配置单元影响当前业务流程等。

S8，根据业务流程影响结果启动更新配置单元过程。如对当前业务流程无影响，则直接全部更新替换配置单元，如各别配置单元对当前业务流程存在影响，则等待观察者监听返回影响业务流程完成消息再继续更新处理。

S9，当响应器完成整个升级更新过程后，发送消息给控制器。

S10，将配置文档调整项更新控制器中的配置文档缓存中的数据。

S11，配置单元与配置文档缓存更新完成后，业务逻辑层向控制器请求生成“完整”代理服务单元类。

S12，根据业务逻辑层的请求中的配置单元的ID号在配置文档缓存中查找对就的类名，并将它们传递给动态装配引擎。

S13，将服务单元类名、适配元件类名、注入策略类名传递给反射器。

S14，将反射器生成完整代理服务单元类源文件传递给编译器。

S15，将经过编译处理的源文件结果类文件传递给加载器。

S16，将编译后的类文件加载至内存中，并将内存中的类文件加载传递给实例化器，生成“完整”代理服务单元类的对象。

S17，将实例化后的代理服务单元类对象以及服务单元类ID、适配元件类ID、注入策略类ID传递给缓存部件，建立相应缓存条目。

S18，返回代理服务单元类实例化对象给动态装配引擎。

S19，动态装配引擎将装配“完整”对象返回给控制器。

S20，最终，控制器将“完整”代理服务单元类对象返回给相应业务逻辑层。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

1.一种软件升级处理方法，其特征在于，包括：

将待升级的软件划分为一个或多个软件服务单元；

提取用于丰富所述一个或多个软件服务单元的一个或多个适配元件；

依据预定注入策略将所述一个或多个适配元件注入到对应的软件服务单元中。

2.根据权利要求1所述的方法，其特征在于，所述预定注入策略包括以下至少之一：

顺序性策略、过滤性策略、阻截性策略、确定性策略、融合性策略、导航性策略、同步性策略。

3.根据权利要求1所述的方法，其特征在于，将待升级的所述软件划分为所述软件服务单元包括：

将所述软件的软件内容依据业务流程和技术方向进行分割；

将在业务流程上具有逻辑关系，技术方向单一的核心功能划分为一个软件服务单元。

4.根据权利要求1所述的方法，其特征在于，在依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元中之前，还包括：

对正在运行的软件操作流程进行监控；

判断依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元是否影响所述软件操作流程，在判断结果为否的情况下，依据所述一个或多个适配元件注入到对应的所述软件服务单元中。

5.根据权利要求1至4中任一项所述的方法，其特征在于，依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元中包括：

依据预定的映射机制映射出所述软件服务单元与所述适配单元的内部结构；

依据所述预定注入策略，以及所述软件服务单元与所述适配单元的内部结构生成代理服务单元类源文件；

对所述代理服务单元类源文件进行编译获得完整代理服务单元类。

6.根据权利要求5所述的方法，其特征在于，在对所述代理服务单元类源文件进行编译获得所述完整代理服务单元类之后，还包括：

对所述软件服务单元、所述适配单元、所述预定注入策略对应的所述完整代理服务单元类进行存储。

7.根据权利要求5所述的方法，其特征在于，在对所述代理服务单元类源文件进行编译获得所述完整代理服务单元类之后，还包括：

对所述完整代理服务单元类进行核查。

8.一种软件升级处理装置，其特征在于，包括：

划分模块，用于将待升级的软件划分为一个或多个软件服务单元；

提取模块，用于提取用于丰富所述一个或多个软件服务单元的一个或多个适配元件；

注入模块，用于依据预定注入策略将所述一个或多个适配元件注入到对应的软件服务单元中。

9.根据权利要求8所述的装置，其特征在于，所述划分模块包括：

分割单元，用于将所述软件的软件内容依据业务流程和技术方向进行分割；

划分单元，用于将在业务流程上具有逻辑关系，技术方向单一的核心功能划分为一个软件服务单元。

10.根据权利要求8所述的装置，其特征在于，还包括：

监控模块，用于对正在运行的软件操作流程进行监控；

判断模块，用于判断依据所述预定注入策略将所述一个或多个适配元件注入到对应的所述软件服务单元是否影响所述软件操作流程，在判断结果为否的情况下，依据所述一个或多个适配元件注入到对应的所述软件服务单元中。

11.根据权利要求8至10中任一项所述的装置，其特征在于，所述注入模块包括：

映射单元，用于依据预定的映射机制映射出所述软件服务单元与所述适配单元的内部结构；

生成单元，用于依据所述预定注入策略，以及所述软件服务单元与所述适配单元的内部结构生成代理服务单元类源文件；

编译单元，用于对所述代理服务单元类源文件进行编译获得完整代理服务单元类。

12.根据权利要求11所述的装置，其特征在于，还包括：

存储单元，用于对所述软件服务单元、所述适配单元、所述预定注入策略对应的所述完整代理服务单元类进行存储。

13.根据权利要求11所述的装置，其特征在于，还包括：

核查单元，用于对所述完整代理服务单元类进行核查。

14.一种终端，其特征在于，包括权利要求8至13中任一项所述的装置。

15.一种服务器，其特征在于，包括权利要求8至13中任一项所述的装置。