CN100498702C

CN100498702C - 一种配置信息处理方法及装置以及平台系统

Info

Publication number: CN100498702C
Application number: CNB2007101030216A
Authority: CN
Inventors: 穆鸿
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-04-29
Filing date: 2007-04-29
Publication date: 2009-06-10
Anticipated expiration: 2027-04-29
Also published as: US20090259991A1; WO2008134948A1; CN101042649A

Abstract

本发明公开了一种配置信息处理方法及通讯系统以及配置信息处理装置，用于提高平台定制的灵活性。本发明方法包括：接收用户发送的策略标识，其中策略标识用于表示用户请求获取配置信息；根据所述策略标识获取包含所述配置信息的配置源对应的源信息以及合并策略信息，所述合并策略信息包含合并规则；查找所述源信息对应的配置源；按照所述合并策略信息将所述配置源合并为一个统一配置源。本发明还提供一种配置信息处理装置以及平台系统。本发明可以有效地提高平台定制的灵活性。

Description

一种配置信息处理方法及装置以及平台系统

技术领域

本发明涉及数据处理领域，尤其涉及一种配置信息处理方法及装置以及平台系统。

背景技术

在大型应用软件开发的过程中配置文件数量多、格式多、存储位置多，给软件的安装、部署、升级以及定制开发带来了很大的不便。

现有技术中一种配置信息处理方法为：采用数据库对配置文件进行管理，将配置文件的内容保存到数据库中。

平台系统允许用户根据自身的需要进行组合或其它的简单操作即可完成软件的开发和定制，平台系统中一般有多种功能模块，针对每个功能模块又有对应的缺省的配置信息，用户进行软件开发和定制时常常通过更改配置信息以实现需要的功能。

现有技术中一种配置信息处理方法为：配置信息被存储于配置文件中，配置文件被存储于数据库中，用户需要获取配置信息时，从数据库中读取对应的配置文件。发明人在实现本发明的过程中发现现有技术中至少存在如下缺点，现有技术为单一配置源的方案，即每个配置文件中保存对应的配置信息，用户需要获取配置信息时首先查找对应的配置文件，再从配置文件中读取配置信息，所以当用户更改配置信息时，包含平台系统缺省的配置信息的配置文件可能被覆盖，同时如果平台系统进行了升级，其配置信息也会随之进行升级，导致原配置信息被覆盖，用户再次对配置信息进行操作时也会造成错误，所以需要用户再次对配置进行重新设置，增加了平台定制的复杂度。

发明内容

一方面，提供一种配置信息处理方法及平台系统以及配置信息处理装置，能够提高平台定制的便捷性。

另一方面提供了一种配置信息处理方法，包括：接收用户发送的策略标识，其中策略标识用于表示用户请求获取配置信息；根据所述策略标识获取包含所述配置信息的配置源对应的源信息以及合并策略信息，所述合并策略信息包含合并规则；查找所述源信息对应的配置源；按照所述合并策略信息将所述配置源合并为一个统一配置源。

另一方面提供了一种配置信息处理装置，包括：策略标识接收单元，信息获取单元，配置源查询单元以及配置源合并单元；所述策略标识接收单元用于接收策略标识，其中策略标识用于表示用户请求获取配置信息；所述信息获取单元用于根据接收到的策略标识获取包含所述配置信息的配置源对应的源信息以及合并策略信息，所述合并策略信息包含合并规则；所述配置源查询单元用于根据获取到的源信息查询并获得对应的配置源；所述配置源合并单元用于根据获取到的合并策略信息将查询到的配置源进行合并为一个统一配置源。

另一方面提供了一种平台系统，包括：用户操作接口，配置信息处理装置及产品生成单元；所述用户操作接口用于接收用户发送的包含策略标识的产品处理请求；所述配置信息处理装置用于根据产品请求中的策略标识对包含配置信息的配置源进行合并得到一个统一配置源，所述策略标识与源信息以及合并策略信息对应，所述源信息与包含所述配置信息的配置源对应，所述合并策略信息包含合并规则；所述产品生成单元用于根据合并后的一个统一配置源开发或者定制用户请求的平台产品。

从以上技术方案可以看出，本发明实施例具有以下优点：

由于本发明实施例中获取多种配置源合并的结果作为配置源，在开发产品基础版本的时候设置一份基本的配置信息，而各个定制版本可以不用修改基本的配置信息只需要增加定制文件，通过合并的方式获取配置，所以在一个配置源中包含原始的配置信息以及更新的配置信息，能够便捷的实现平台产品的升级和定制。

附图说明

图1为本发明实施例中平台系统第一实施例示意图；

图2为本发明实施例中平台系统第二实施例示意图；

图3为本发明实施例中配置信息处理装置实施例示意图；

图4为本发明实施例中配置信息处理方法实施例流程图。

具体实施方式

本发明实施例提供了一种配置信息处理方法及装置以及平台系统，用于便捷的实现平台产品的升级和定制。

首先对本发明实施例中的平台系统进行介绍：

请参阅图1，本发明实施例中平台系统第一实施例包括：用户操作接口101，配置信息处理装置102及产品生成单元103。

用户操作接口101用于接收用户的产品处理请求，其中，产品处理请求中包括用户期望开发或定制的平台产品(如软件或硬件)的类型，内容以及功能信息。平台产品一般由多个功能模块组成，每个功能模块有对应的配置信息，在产品处理请求中可以包含策略标识，表示用户请求获得这些配置信息。

配置信息处理装置102用于根据产品请求中的策略标识对包含配置信息的配置源进行合并得到统一配置源。

产品生成单元103用于根据合并后的统一配置源开发或者定制用户请求的平台产品。

请参阅图2，本发明实施例中平台系统第二实施例中，

配置信息处理装置102包括：

策略标识接收单元201，信息获取单元202，配置源查询单元203及配置源合并单元204。

策略标识接收单元201用于接收策略标识。

信息获取单元202用于根据接收到的策略标识获取对应的源信息以及合并策略信息。

配置源查询单元203用于根据获取到的源信息查询对应的配置源。

配置源合并单元204用于根据获取到的合并策略信息将查询到的配置源进行合并为统一配置源。

具体地，产品生成单元103包括：

产品定制单元205，产品封装单元206以及产品输出单元207。

产品定制单元205用于根据用户的请求对从配置源合并单元204获取的统一配置源进行配置。

产品封装单元206用于对配置后的功能模块进行封装形成最终产品。

产品输出单元207用于将形成的最终产品输出，本实施例中，将功能模块封装成软件之后设置用户接口即是输出最终产品。

下面介绍本发明实施例中配置信息处理装置：

请参阅图3，本发明实施例中配置信息处理装置实施例包括：

策略标识接收单元201，信息获取单元202，配置源查询单元203以及配置源合并单元204。

策略标识接收单元201用于接收策略标识，其中策略标识用于表示用户请求获取配置信息。

配置源查询单元203用于根据获取到的源信息查询并获得对应的配置源。

本实施例中，配置信息处理装置还包括：

策略存储单元301，资源查找控制单元302，配置源存储单元303以及配置源反馈单元304。

策略存储单元301用于存储能够提供合并规则的合并策略信息，信息获取单元202可以根据接收到的策略标识在策略存储单元301中查询对应的合并策略信息。

资源查找控制单元302用于接收信息获取单元202的获取到的源信息，并将该源信息转发至配置源查询单元203，请求配置源查询单元203查询源信息对应的配置源。

配置源存储单元303用于存储配置源以及经过合并的统一配置源，配置源查询单元203在配置源存储单元303存储的配置源中查询与源信息对应的配置源，配置源合并单元204将配置源合并为统一配置源之后将统一配置源存储于配置源存储单元303。

配置源反馈单元304用于将经过合并的统一配置源反馈给请求配置源的用户。

本实施例中，配置信息处理装置还包括：

配置事件分发器305，其中配置事件分发器305包括：

侦听标识接收单元3051，事件监控单元3052。

侦听标识接收单元3051用于接收用户发送的事件侦听标识，并将该标识发送至事件监控单元3052。

事件监控单元3052根据接收到的事件侦听标识对配置事件进行监控，判断是否满足该事件侦听标识中的预置条件，若满足则请求配置源反馈单元304向用户反馈当前的配置源。

预置条件包括：配置源发生了改变，或者是主动调用配置的变更接口引起的配置改变。

其中，配置源合并单元204包括：

初始化单元306，数据访问单元307，合并执行单元308以及合并控制单元309。

初始化单元306用于根据合并策略信息进行初始化处理，初始化处理的过程为设定各种合并参数，例如处理的数据的类型为“XML”，合并后形成的配置源的类型为“DOM”等参数，具体的参数以及设置方法可以由实际情况进行确定，此处不作限定。

数据访问单元307用于获取配置源中的待合并数据，并将数据发送至合并执行单元308。

合并执行单元308用于根据合并策略信息对获取到的待合并数据进行合并。

合并控制单元309用于判断待合并数据是否已经合并完成，并生成判断结果。

其中，判断结果可以是：若合并完成则返回最终合并数据，若未合并完成，则指示合并执行单元308继续处理待合并数据。

上面对本发明实施例中的配置信息处理装置进行了详细介绍，可以理解的是，上述介绍的均为功能单元，在实际的应用中可以多个功能单元集成在一个单元中，例如：

1、将策略标识接收单元201以及配置源反馈单元304集成于配置策略管理器中，同时配置策略管理器还具有一些其它的功能，包括：根据接收到的策略标识向资源查找控制单元302转发源信息以查找配置源，并根据策略标识查找对应的策略信息，并根据策略信息查询对应的合并策略信息；

2、将配置源查询单元203以及配置源存储单元303集合为配置资源管理器，即配置资源管理器用于接收资源查找控制单元302发送的源信息，并根据源信息在本地存储的配置源中查询对应的配置源，并将查询到的配置源反馈至资源查找控制单元302。

上面介绍了两种单元集合的情况，可以理解的是，在实际使用过程中还可以是其它的集成情况，具体不作限定，为方便描述，在下面对方法实施例的描述中以上述集成情况为例，即配置信息处理装置包括：配置策略管理器，资源查找控制单元，配置资源管理器，策略存储单元，配置源合并单元，配置源反馈单元以及配置事件分发器。

由于本发明实施例中配置信息处理装置可以将多个配置源合并的结果作为统一配置源，在开发产品基础版本的时候设置一份基本的配置信息，而各个定制版本可以不用修改基本的配置信息只需要增加定制文件，通过合并的方式获取配置，所以在一个配置源中包含原始的配置信息以及更新的配置信息，能够便捷的实现平台产品的升级和定制。下面结合上述描述的配置信息处理装置对本发明实施例中配置信息处理方法实施例进行详细描述，为能够更清楚的说明本发明实施例中的配置信息处理方法，在下面的描述中将插入一个现实中的例子，假设统一配置策略的文件样例uconfig.xml，例子中策略标识为“sql”，该策略使用两个文件即“default-sql.xml”和“customization-sql.xml”作为配置源，使用“sql.xslt”作为合并的模板，使用可扩展的样式语言转换(XSLT，Extensible Style sheet LanguagcTransformations)作为合并引擎。目标是将两个文件合并为一个配置信息数据结构，数据结构采用文档对象模式(DOM，Document Object Model)格式。

uconfig.xml文件的内容如下：

<default type＝”xml”>f:/conf/default-sql.xml</default>

<extension type＝”xml”>f:/ext/conf/customizations-sql.xml</extension>

<merge-template>sql.xslt</merge-template>

<engine-type>xslt</engine-type>

其中该文件的含义为：在该文件中，策略标识为“sql”，文件类型为“xml”，缺省配置文件路径，即一个配置源为“f:/conf/default-sql.xml”，用户配置的配置文件路径，即另一个配置源为“f:/ext/conf/customizations-sql.xml”，合并的模板为“sql.xslt”，合并模板中指示合并的规则，具体的规则在本实施例中为：“若节点中id一样则使用customization-sql中的值，其余的节点两个文件合并”。

default-sql.xml文件的内容如下：

<sql>select*fromfunction where funciton.id＝’1’</sql>

<sql>select*from customers</sql>

其中该文件的含义为：若软件中的功能节点id为“sql1”，则执行SQL语句“select*from function where funciton.id＝’1’”，若节点id为“sql2”，则执行SQL语句“select*from customers”。

上述所提到的节点id为软件功能模块中的一个参数。

customization-sql.xml文件的内容如下：

<sql>select*from function where funciton.id＝’2’</sql>

其中该文件的大致含义为：若节点id为“sql1”，则执行SQL语句“selcct*from function where funciton.id＝’2’”。

请参阅图4，本发明实施例中配置信息处理方法实施例包括步骤，在下面的介绍中，步骤的执行主体均为配置信息处理装置：

401、接收策略标识。

配置信息处理装置中的配置策略管理器接收用户发送的策略标识，该策略标识用以表示用户请求获取统一配置信息。

在本实施例中，用户向配置策略管理器发送策略标识“sql”以获取统一配置信息。

402、获取配置策略信息。

配置策略管理器在接收到用户端发送的策略标识后在本地存储的对应规则中查询策略标识对应的策略信息。

上述对应规则为策略标识与策略信息之间的对应关系。

获取到的策略信息中主要包括源信息，例如由哪些文件合并产生最终的配置信息。

在本实施例中，配置策略管理器查找源信息，此处对应“sql”标识的源信息是f:/conf/default-sql.xml和f:/ext/conf/customization-sql.xml。

403、查找配置源。

配置策略管理器查询到源信息后向资源查找控制单元发送查询到的源信息请求进行配置源的查找。

在本实施例中，配置策略管理器将源信息f:/conf/default-sql.xml和f:/ext/conf/customization-sql.xml以及配置源的类型“xml”发送给资源查找控制单元。

404、获取配置源。

资源查找控制单元根据不同的配置源类型将接收到的源信息转发给对应的配置资源管理器，请求配置资源管理器进行配置源查询。

在本实施例中，资源查找控制单元将查询具体资源信息的请求转发给文件类型的配置资源管理器，在请求中包含源信息，并且指定文件类型格式是xml类型。

405、返回配置源。

配置资源管理器查询到对应的配置源将配置源返回给资源查找控制单元。

在本实施例中，配置资源管理器在文件系统中查询文件，取得文件的URL，并返回给资源查找控制单元。

406、返回配置源信息。

资源查找控制单元接收各资源管理器发送的配置源，并对各个配置源进行汇总后返回给配置策略管理器。

在本实施例中，资源查找控制单元将f:/conf/default-sql.xml和f:/ext/conf/customization-sql.xml封装为统一的资源类型，这里的资源类型包括了下列信息URL、文件类型、是否存在、描述信息等，经过转换的资源被返回给配置策略管理器；其中具体的封装过程为现有技术，此处不作赘述。

407、获取合并策略信息。

配置策略管理器根据获取到的策略信息在策略存储单元中查询对应的合并策略信息。

在本实施例中，合并策略信息为策略模板，即“sql.xslt”，也有可能该模板需要经过处理，例如参数格式的同一等处理。

408、返回合并策略信息。

策略存储单元根据配置策略管理器的请求查询到对应的合并策略信息之后将合并策略信息反馈至配置策略管理器。

在本实施例中，策略存储单元将处理过的“sql.xslt”发送至配置策略管理器。

409、发送配置源信息，合并策略信息以及引擎信息。

配置策略管理器将从资源查找控制单元接收的配置源信息，从策略存储单元接收的合并策略信息以及策略信息中的引擎信息发送至配置源合并单元。

在本实施例中，配置策略管理器得到的配置源，策略模板“sql.xslt”以及策略信息中的引擎信息(这里指定引擎为xslt)发送至配置源合并单元，这里的“sql.xslt”采用的策略是：“若节点中id一样则使用customization-sql中的值，其余的节点两个文件合并”。

410、返回合并后的配置源。

配置源合并单元进行配置源合并，并将合并后的统一配置源返回至配置策略管理器。

具体的合并过程为：

1、配置源合并单元访问配置源，获取其中的一个数据作为待合并数据A，如果只有一个配置源则直接返回配置源的数据，否则执行步骤2。

2、获取配置源中第二个数据，作为待合并数据B。

3、根据引擎信息查找对应的合并算法引擎，并使用策略模板初始化引擎，初始化的过程为设定各引擎参数，具体的参数以及设置方法可以由实际情况进行确定，此处不作限定。

4、将待合并数据A和待合并数据B传入配置源合并单元，然后引擎根据策略模板的信息引导数据进行合并，将合并的结果作为待合并数据A。

5、继续获取资源集合中的下一个数据作为待合并数据B，重复步骤4以及步骤5，直到资源集合遍历完成。

6、最后将待合并数据A作为结果返回。

在本实施例中，配置源合并单元使用对应的xslt引擎，将传入的两个配置源合并为一个统一的配置源，返回“sql”策略配置的DOM数据，具体的合并过程与上述描述的过程一致。

411、对配置进行缓存。

配置策略管理器指示配置源存储单元对合并后的数据进行缓存，以便用户再次请求同样配置的时候可以不用重新合并数据而直接返回缓存中的数据。

在本实施例中，配置策略管理器指示配置源存储单元对合并的DOM数据做缓存，以便统一配置用户再次请求同样配置的时候可以不用重新合并数据而直接返回缓存的数据。

412、返回统一配置。

配置策略管理器指示配置源反馈单元将合并后的数据返回给用户。

在本实施例中，配置策略管理器指示配置源反馈单元将合并的数据返回给统一配置的用户，返回的DOM数据如下：

<sql>select*from function where funciton.id＝’2’</sql>

<sql>select*from customers</sql>

其中default-sql中节点id为“sql1”时执行SQL语句“select*from functionwhere funciton.id＝’1’”，customization-sql中节点id为“sql1”时执行SQL语句“select*from function where funciton.id＝’2’”，而根据“sql.xslt”采用的策略：“若节点中id一样则使用customization-sql中的值，其余的节点两个文件合并”可知，节点id相同时采用customization-sql文件中的值，所以此处当节点id为“sql1”时执行SQL语句“select*from function where funciton.id＝’2’”，合并的其余部分为：当节点id为“sql2”时执行SQL语句“select*fromcustomers”。

在本实施例中，步骤407以及步骤408的执行位置可以根据实际情况进行调整，例如在配置策略管理器获取到源信息之后就执行步骤407与步骤408也可以实现发明目的，步骤411为优选方案中的执行步骤，也可以不执行，并不影响发明目的的实现。

另外，本实施例中，在步骤401之前或之后或同时，用户端还可以向配置事件分发器发送包含预置条件的事件侦听标识，请求对事件进行监控，当满足预置条件时通知用户。

在配置源合并单元将各个配置源合并为统一配置源之后，或者是在配置事件分发器接收到用户端发送的事件侦听标识之后，配置事件分发器对用户的事件侦听标识进行注册之后对事件进行监控，若监控判断到满足其中的预置条件时，通知用户。

其中，预置条件可以是当前的配置源发生变化，或者是达到指定的触发时间。

若配置源发生变化，则配置事件分发器将更新后的配置信息发送至用户，用户根据接收到的更新后的配置信息重新加载配置。

本实施例中将进行合并后的数据进行缓存处理，所以可以提高用户获取配置信息的效率，同时使得数据的保存和使用分开，可以提高数据存储的扩展性；

其次，由于本实施例中采用基于引擎合并的方式，只需要调整引擎的方式和使用不同的合并策略信息就可以满足不同的统一配置需求，所以提高了配置合并的灵活性；

再次，由于本实施例中还设置有配置事件分发器，所以用户可以设置触发标识，当配置发生变化时，配置事件分发器会主动向用户下发变更后的配置信息，所以提高了用户获取配置信息的灵活性；

最后，由于本实施例中对源信息的查找采用的是“二级查找”的机制，即资源查找控制单元接收查询请求并转发至资源管理器进行查找，并对来自资源管理器的反馈信息进行汇总后发送给配置策略管理器，所以可以有效地提高各单元的处理性能，进而提高整体系统的性能。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括如下步骤：接收用户发送的策略标识；根据所述策略标识获取源信息以及合并策略信息；查找所述源信息对应的配置源；按照所述合并策略信息将所述配置源合并为统一配置源。上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上对本发明所提供的一种配置信息处理方法及装置以及平台系统进行了详细介绍，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1、一种配置信息处理方法，其特征在于，包括：

接收用户发送的策略标识，其中策略标识用于表示用户请求获取配置信息；

根据所述策略标识获取包含所述配置信息的配置源对应的源信息以及合并策略信息，所述合并策略信息包含合并规则；

查找所述源信息对应的配置源；

按照所述合并策略信息将所述配置源合并为一个统一配置源。

2、根据权利要求1所述的配置信息处理方法，其特征在于，所述根据所述策略标识获取包含所述配置信息的配置源对应的源信息的步骤包括：

在本地存储的对应规则中查询接收到的策略标识对应的策略信息；

所述对应规则为策略标识与策略信息的对应规则；

所述策略信息包括源信息以及对应合并算法的引擎信息。

3、根据权利要求1所述的配置信息处理方法，其特征在于，所述根据所述策略标识获取合并策略信息的步骤包括：

根据获取到的策略信息查询对应的合并策略信息。

4、根据权利要求2或3所述的配置信息处理方法，其特征在于，所述查找所述源信息对应的配置源的步骤包括：

发送包含所述源信息的配置源查找查询请求；

根据所述源信息查询配置源，并汇总查询到的配置源形成配置源集合。

5、根据权利要求4所述的配置信息处理方法，其特征在于，所述按照所述合并策略信息将所述配置源合并为一个统一配置源的步骤包括：

将获取的配置源集合，合并策略信息以及策略信息中的引擎信息发送至配置源合并单元；

根据合并策略信息对配置源合并单元进行初始化处理；

利用所述引擎信息对应的合并算法根据合并策略信息中的合并规则对配置源进行合并。

6、根据权利要求5所述的配置信息处理方法，其特征在于，该方法当配置源合并完毕之后包括步骤：

对合并结果进行缓存；

将合并的结果发送至用户。

7、根据权利要求1所述的配置信息处理方法，其特征在于，所述接收用户发送的策略标识的步骤之前或之后包括：

接收用户发送的事件侦听标识；

所述按照所述合并策略信息将所述配置源合并为一个统一配置源的步骤之后包括：

对接收到的事件侦听标识进行注册并进行事件监控，若判断满足事件侦听标识中包含的预置条件，则通知所述用户。

8、根据权利要求7所述的配置信息处理方法，其特征在于，所述预置条件包括：当前配置源发生变化，或调用配置的变更接口引起配置发生变化。

9、根据权利要求8所述的配置信息处理方法，其特征在于，若配置源发生变化，则将更新后的配置信息发送至用户；

所述用户根据所述更新后的配置信息重新加载配置。

10、一种配置信息处理装置，其特征在于，包括：

策略标识接收单元，信息获取单元，配置源查询单元以及配置源合并单元；

所述策略标识接收单元用于接收策略标识，其中策略标识用于表示用户请求获取配置信息；

所述信息获取单元用于根据接收到的策略标识获取包含所述配置信息的配置源对应的源信息以及合并策略信息，所述合并策略信息包含合并规则；

所述配置源查询单元用于根据获取到的源信息查询并获得对应的配置源；

所述配置源合并单元用于根据获取到的合并策略信息将查询到的配置源进行合并为一个统一配置源。

11、根据权利要求10所述的配置信息处理装置，其特征在于，所述装置还包括：

策略存储单元，资源查找控制单元，配置源存储单元以及配置源反馈单元；

所述策略存储单元用于存储能够提供合并规则的合并策略信息；

所述资源查找控制单元用于接收从所述信息获取单元获取到的源信息，并将该源信息转发至配置源查询单元；

所述配置源存储单元用于存储配置源以及经过合并的一个统一配置源；

所述配置源反馈单元用于将经过合并的一个统一配置源反馈给请求配置源的用户。

12、根据权利要求11所述的配置信息处理装置，其特征在于，所述装置还包括：

配置事件分发器，所述配置事件分发器包括：

侦听标识接收单元以及事件监控单元；

所述侦听标识接收单元用于接收用户发送的事件侦听标识，并将该标识发送至事件监控单元；

所述事件监控单元根据接收到的事件侦听标识对配置事件进行监控，判断是否满足该事件侦听标识中的预置条件，若满足则请求配置源反馈单元向用户反馈当前的配置源。

13、根据权利要求10至12中任一项所述的配置信息处理装置，其特征在于，所述配置源合并单元包括：

初始化单元，数据访问单元，合并执行单元以及合并控制单元；

所述初始化单元用于根据合并策略信息进行初始化处理；

所述数据访问单元用于获取配置源中的待合并数据，并将数据发送至合并执行单元；

所述合并执行单元用于根据合并策略信息对获取到的待合并数据进行合并；

所述合并控制单元用于判断待合并数据是否已经合并完成，并生成判断结果。

14、一种平台系统，其特征在于，包括：

用户操作接口，配置信息处理装置及产品生成单元；

所述用户操作接口用于接收用户发送的包含策略标识的产品处理请求；

所述配置信息处理装置用于根据产品请求中的策略标识对包含配置信息的配置源进行合并得到一个统一配置源，所述策略标识与源信息以及合并策略信息对应，所述源信息与包含所述配置信息的配置源对应，所述合并策略信息包含合并规则；

所述产品生成单元用于根据合并后的一个统一配置源开发或者定制用户请求的平台产品。

15、根据权利要求14所述的平台系统，其特征在于，所述配置信息处理装置包括：

策略标识接收单元，信息获取单元，配置源查询单元及配置源合并单元；

所述信息获取单元用于根据接收到的策略标识获取对应的源信息以及合并策略信息；

16、根据权利要求14或15所述的平台系统，其特征在于，所述产品生成单元包括：

产品定制单元，产品封装单元以及产品输出单元；

所述产品定制单元用于根据用户的请求对从配置源合并单元获取的一个统一配置源进行配置；

所述产品封装单元用于对配置后的功能模块进行封装形成最终产品；

所述产品输出单元用于将形成的最终产品输出。