CN100579256C - 核心开通平台系统 - Google Patents

Abstract

本发明提供一种用于开通电信业务的核心开通平台系统，其特征在于：整个系统由基于数据流驱动的系列组件组成，各个组件之间通过消息连接件进行数据通信，每个组件中具有定义数据处理的规则文件，每个组件作为数据流的处理环节或节点能够被组织到数据处理流程中。采用该核心开通平台系统能够实现从电信运营商的前端业务定单系统的定单自动地转换成各种网络、各类设备的配置命令并激活业务的全过程。

Description

核心开通平台系统

技术领域

本发明涉及包含有计算机技术和通讯技术的现代电信运营支撑系统，特别是一种用于开通电信业务的核心开通平台系统，采用该核心开通平台系统能够实现从电信运营商的前端业务定单系统的定单自动地转换成各种网络、各类设备的配置命令并激活业务的全过程。电信运营支撑系统的缩写为OSS，核心开通平台系统缩写为CAP(英文全称为CoreActivation Platform)。

背景技术

随着计算机技术和通讯技术的发展，尤其是移动通信和数据通讯业务爆炸式增长，电信运营商的网络规模越来越大，设备种类日渐复杂，业务类型日益丰富，而传统的依靠资源优势的竞争逐步转变为提高网络运营效率和服务质量的竞争。目前，电信运营商的大多数业务的开通配置工作都依靠手工方式或者基于电子工单系统的半自动方式进行，虽然对于前端客户业务信息的受理已经逐渐通过电子化工单流程的方式实现，但是电子工单系统中的业务信息如何转变为不同厂商的设备配置命令是当前电信运营商业务开通配置流程中的脱节点，需要人工根据经验和设备的配置命令集进行相应的组织，转换并手工配置。

随着电信运营商持续、快速推出业务的压力越来越大，而自动、准确地部署和开通新业务、修改/升级/组合现有业务的要求也越来越高，这是整个电信运营业的支撑手段中所面临的急需解决的课题。

当前，全球范围内已经有两类厂商致力于业务自动开通的研究，并推出了相关的产品：

一类是设备供应商：如CISCO开发的ISC，华为公司推出的VPN Manager等，这些业务开通系统的特点是针对本厂商的某一类设备的开通或者激活，还不足以实现从业务到所有类型设备配置命令的映射，也没有统一的资源库的概念，系统具有明显的局限性，基本仍然可以看作一个面向设备的网元自动配置系统。

另一类是独立软件开发商：例如Metasolv公司的系列化产品(Provisioning5，ObjectTel，ASAP等)，Cramer公司的资源管理产品。

国内一些厂商也在开发业务开通产品，但是普遍存在流程和业务开通所依赖的资源数据脱节的现象，而且对于设备命令的自动转换方面存在明显的缺陷。

在目前电信运营商的竞争态势下，要提供良好的服务质量，业务的快速开通和业务质量的保障是密不可分的，而反映跨不同专业网络、跨厂商、跨地域(接入端、中继段)的端到端资源模型和相关的数据是支撑二者的基础。

要实现跨专业网络、跨厂商、跨地域的业务自动开通需要解决以下几个关键的问题：

1)可伸缩的业务开通数据/工作流模型和实现技术，这是整个业务开通系统的核心；

2)高度抽象的业务模型，将反映业务特征的网络元素抽象为具有共同特征的对象；

3)针对所抽象的资源对象进行组织和管理的平台化技术，这为业务的自动开通奠定数据基础；

4)满足跨专业网络、跨厂商开通的需要的关键技术，包括业务层服务质量(以下简称QOS：Quality of Service)到网络层QOS的转换技术，设备配置命令的转换技术、端到端路径的选择技术。

发明内容

本发明针对现有技术中存在的缺陷或不足，提供一种用于开通电信业务的核心开通平台系统，采用该核心开通平台系统能够实现从电信运营商的前端业务定单系统的定单自动地转换成各种网络、各类设备的配置命令并激活业务的全过程。

本发明的技术构思为，基于资源管理系统的资源服务，采用以数据流驱动和组件化软件技术，实现从电信运营商的前端业务定单系统的定单自动地转换成各种网络、各类设备的配置命令并激活业务的全过程。

本发明的技术方案如下：

核心开通平台系统，其特征在于：整个系统由基于数据流驱动的系列组件组成，各个组件之间通过消息连接件进行数据通信，每个组件中具有定义数据处理的规则文件，每个组件作为数据流的处理环节或节点能够被组织到数据处理流程中；

所述系列组件包括：业务对象分解组件、形成原子业务对象组件、业务模板参数审计组件、参数转换组件和命令解析组件，所述业务对象分解组件用于：非带宽型业务开通的业务对象的分解；所述形成原子业务对象组件用于：将业务对象组合映射为原子的不可分割的业务对象，作为业务开通的最小单元；所述业务模板参数审计组件用于：对info表示的不同业务请求参数进行有效性和正确性审计，info是采用XML描述的数据结构体，不同的业务开通请求数据结构是不同的，要增加对一种新业务开通配置，需要在预定义模板中增加一种描述新业务数据结构的模版，这个组件就可以对新业务进行处理；所述参数转换组件用于：将原子业务对象中的相关参数，获取对应的参数转换映射和运算配置，把业务参数转换为配置命令模板需要的参数；所述命令解析组件用于：将命令参数与配置命令模板中的相关厂商、设备型号和操作系统版本的相关参数项进行替换，形成完成一个原子业务操作的、与设备相关的配置命令序列。

所述系列组件中包括作为数据最初入口的定单适配组件和作为数据最终出口的命令执行控制组件，所述定单适配组件用于：将不同数据格式的业务定单转化为待开通业务对象的数据加工节点，待开通业务对象是系统能够识别的数据结构；所述命令执行控制组件用于：根据命令序列的控制内容，执行相关的命令操作，完成对设备的相关配置任务。

所述非带宽型业务开通的业务对象的分解是指：将接入型业务对象作为一个整体的业务对象分解为若干个业务对象的组合，或者，对于MPLS VPN业务开通而言，将一个VPN业务对象分解为若干个SITE对象的组合。

所述系列组件中包括：端到端路径选择组件、客户层QOS向网络层QOS的映射组件、和/或作业调度组件，所述端到端路径选择组件用于：根据待开通业务对象所描述的业务信息，根据资源数据的组织，进行端到端路径的选择，能够做到跨网络、跨地域、跨层次的选径，能够根据不同的路径选择策略进行路径的选择；在完成路径的选择之后，待开通业务请求就转化为由若干段路径组成的业务对象组合；所述客户层QOS向网络层QOS的映射组件用于：在经过分解的业务对象组合层次，将客户层的QOS服务的描述，分解到每一个业务对象上，作为业务对象组合的描述；所述作业调度组件用于：将命令队列中的命令序列按照调度规则进行调度，发送到命令执行和事务控制组件；所述命令执行和事务控制组件按照命令序列，完成对特定设备的配置。

所述端到端路径选择组件能够调用资源查询组件，从统一资源库中进行资源信息的查询。

所述业务对象分解组件能够调用资源查询组件，从统一资源库中进行资源信息的查询。

所述消息连接件能够实现对数据流每一个处理环节的数据持久化和数据核查。

所述数据统一采用XML语言来进行描述，数据加工的配置文件也采用XML文件来统一地进行描述。该系统能够采取并行数据流处理，也能够通过重新组织数据处理组件及其数据处理的规则文件以适应数据处理流程的变化。

本发明的技术效果如下：

使用本发明主要可以给用户带来以下好处：

1、利用本发明的成果，可以快速实现VPN、ATM、FR和DDN等各个专业网络业务开通解决方案，并且可以针对电信运营商的不断提升的要求，在综合资源数据库的层次上，实现跨地域、跨网络、跨设备厂商的端到端业务开通。

2、通过基于数据流的组件组装技术，可以快速地适应用户需求的变化，灵活地根据用户的业务开通数据流的变化和需求的提升，稳步地通过添加新组件的方法，解决系统的需求变化情况下的系统稳定性问题。

3、通过XML方式作为标准的内部和外部数据描述方式，结合标准的消息连接件技术，统一了业务监视和业务开通所需要的资源模型，并且通过通用对象管理平台进行描述，使系统具有很高的可扩展性。

4、通过将业务的表述、设备命令的描述和命令执行的分离，并且通过数据流技术进行统一，使得市场部门的用户可以关注于业务特征、系统维护人员关注于设备配置模板的维护，操作人员关注于操作的流程，不同人员的关注点不同，又通过数据流贯穿数据的变化过程，形成一个协同工作的平台。

附图说明

图1为本发明的数据流驱动和组件化结构，注：其中灰底色图形是可选部分。

图2为通用资源模型建立示意图。

图3为业务开通配置引擎数据流驱动结构。

图4为同层网络对象关系图。

图5为上下层网络对象关系图。

图6为基于成本的路径选择算法示例。

图7为事务控制的两个层面结构。

图8为基于本发明CAP的应用产品结构图。

具体实施方式

下面结合附图对本发明作进一步的详细说明。

一、本发明涉及的技术包括：

(1)基于数据流驱动和组件单元组装技术的业务自动开通软件体系架构；

(2)基于通用对象建模和数据管理的业务开通资源模型；

(3)基于模版替换的命令自动映射和转化引擎方法；

(4)基于资源的成本模型路径选择算法；

(5)业务处理过程中的事务控制机制。

二、与本发明相关的现有技术包括规则引擎技术、数据管理中间件技术、和通用网络模型，分别说明如下：

1.规则引擎技术

规则引擎技术是随着企业级应用的复杂化，需求不断的随着业务规则的变化而变化，使得企业应用中的业务逻辑需要同开发人员的技术架构相分离而产生的技术，需要将业务规则从软件中抽取出来，进行集中的管理，使之能够在不同的时段(包括运行时)，可以动态的对业务规则进行修改，而不用中断系统的服务。

规则引擎可以看作是一个通用软件模块，业务规则可以看作是对程序中代码片段的一种抽取，规则引擎负责将应用程序中的业务规则加载并解释执行。

规则引擎的技术是从程序或者软件结构的角度实现规则的分离，对于实现自动化的业务开通而言，很自然的想法是将开通过程的业务规则与规则引擎剥离，因此作为本发明的相关技术。

2.数据管理中间件技术

该技术是在本公司发明的有关通用对象建模方法及通用对象管理系统(专利申请号03146664.8)基础上，进一步结合电信运营支撑系统的实际需求，对上层应用提供数据模型服务和数据访问服务的中间件技术。

对象建模方法包括采用通用对象模型、特殊对象模型和应用业务逻辑三层对象模型来建立被管对象的描述和应用的扩展，所述通用对象模型层描述和定义一般对象的属性和呈现方式，将所有被管对象采用统一标准的格式来描述，形成有序组织的对象；特殊对象模型层定义对象和对象之间的相互关系，以及对象特定的应用含义，从而形成特定技术领域的对象模型描述；应用业务逻辑层定义基于特定对象模型的特定操作或方法，并与相关的应用逻辑相结合。本发明通过对通用对象模型层的描述，可以建立所有被管理对象的模型，适应对多技术领域、多专业领域管理对象的管理。

本发明中所使用的数据存储服务、数据模型服务和数据访问服务由对象管理系统所提供。

3.通用网络模型

如何建立通用的网络模型，很多国际组织在这方面做出了巨大的贡献，如电信管理论坛的TMF605所描述的CaSMIM(Connection and Service Management Information Model)模型，CaSMIM描述端到端业务中的网络节点和他们之间的连接，通过对象之间的客户、服务关系来实现网络层次间的关系。

CaSMIM建立了一个通用网络模型，应用于所有的网络中，但是它局限在从网络连接的角度来描述业务，对于单点接入型业务、组合业务的描述存在扩充的必要，尤其需要从网络资源、业务资源和客户资源以及他们之间的关系的角度对模型进一步扩充。

三、关于本发明基于数据流驱动和组件化技术的核心设计：

对于OSS领域而言，对于将业务规则和程序分开的通常做法是采取规则引擎的方式，从软件程序的角度来考虑系统的设计。而本发明的核心设计思想是：

1.数据流的角度来分析和描述业务开通的过程：对于数据流的处理环节，抽象为一个数据加工节点，定义为一类组件，通过在该组件中定义相关的配置文件来实现对数据的加工，数据处理算法和规则的抽象体现在若干个小的组件内部。

2.数据统一采用XML语言来进行描述，数据加工的配置文件也采用XML文件来统一地进行描述。

3.两个数据加工组件之间，通过消息连接件实现组件之间的数据通信。

4.可以通过消息连接件实现对数据流每一个处理环节的数据持久化和数据核查。

5.数据的处理过程可以采取并行数据流处理的方法，以提高系统的性能。

6.数据处理流程变化时，可以通过重新组织数据处理组件和相关的配置文件，达到适应变化的目标。

参见图1所示，详细描述了业务开通过程中，如何将业务定单通过数据加工节点，转变为设备配置命令序列的基本数据流程。

1.定单适配组件：将不同数据格式的业务定单转化为待开通业务对象的数据加工节点，待开通业务对象是系统可以识别的数据结构。

2.端到端路径选择组件：根据待开通业务对象所描述的业务信息，根据资源数据的组织，进行端到端路径的选择，可以做到跨网络、跨地域、跨层次的选径，可以根据不同的路径选择策略进行路径的选择。在完成路径的选择之后，待开通业务请求就转化为由若干段路径组成的业务对象组合。

3.业务对象分解组件：适用于非带宽型业务开通的业务对象的分解，例如，接入型业务对象，将一个整体的业务对象分解为若干个业务对象的组合。例如，对MPLS VPN业务开通而言，将一个VPN业务对象分解为若干个SITE对象的组合。

4.客户层QOS向网络层QOS的映射组件：在经过分解的业务对象组合层次，将客户层的QOS服务的描述，分解到每一个业务对象上，作为业务对象组合的描述。

5.形成原子业务对象组件：将业务对象组合映射为原子的不可分割的业务对象，作为业务开通的最小单元。

6.业务模板参数审计组件：对info表示的不同业务请求参数进行有效性和正确性审计，info是采用XML描述的数据结构体，不同的业务开通请求数据结构是不同的，要增加对一种新业务开通配置，需要在预定义模板中增加一种描述新业务数据结构的模版，这个组件就可以对新业务进行处理。

7.参数转换组件：将原子业务对象中的相关参数，获取对应的参数转换映射和运算配置，把业务参数转换为配置命令模板需要的参数。

8.命令解析组件：关联到相关厂商、设备型号、操作系统版本，将命令参数与配置模板中的相关参数项进行替换，形成完成一个原子业务操作的、与设备相关的配置命令序列。

9.作业调度组件：将命令队列中的命令序列按照调度规则进行调度，发送到命令执行和事务控制组件。

10.命令执行控制组件：根据命令序列的控制内容，执行相关的命令操作，完成对设备的相关配置任务。

端到端路径选择组件和业务对象分解组件都调用资源查询组件，从对象管理平台或者第三方的资源管理系统中进行资源信息的查询。

四、关于基于通用对象建模和数据管理平台的业务开通资源模型：

资源模型是对现实世界中网络、业务、客户以及他们之间关系的一个抽象，业务开通的过程本质上就是资源状态发生变化的过程，也就是将物理/逻辑的网络资源转变为业务资源的一个过程。

本发明的业务开通资源模型采用对象的方法描述，并且通过对象管理平台加以实现，提供资源数据的服务，本发明也可以支持所有符合OSSJ API规范的资源管理系统。

模型驱动是系统的灵魂，本发明采用了通用对象建模的方法，描述网络中的节点(可以是设备、端口、端子)和节点之间的连接关系(可以是中继、电路、路径等)，以及网络和网络之间的连接关系(虚连接)，采用统一的数据描述与组织，采用多层模型实现从通用模型到专业模型的支持，为业务应用开发提供基础。资源模型的建立分为三个层次(如图2)：最低层是一般对象层，在这个层次上把所有的网络资源实例完全按照OO的思想进行共性化抽象，采用统一标准的格式来描述，形成有序组织的一般性对象(在这个层次中，对象都是独立的实体)；中间层是对象关系层，在这个层次上根据对象的应用领域特性对对象之间的关系(比如包含关系，引用关系和其他关联关系等)进行定义和描述，形成特定领域的资源对象模型；最上层是业务逻辑层，在这个层次上定义对象在特定领域中所拥有的特定操作或方法，并与相关的应用逻辑进行结合，从而最后形成特定领域的一个通用的资源模型。

此外，本发明还支持将业务开通的资源模型和业务监视的资源模型统一在一起，为在业务开通后，立即对所开通的业务实现相关监视提供了资源数据的基础。通过模型驱动，实现了数据、模型和应用的分离，将复杂的业务开通问题分而治之，为实现多厂商、多层次、多业务、跨地域的业务开通提供了一个灵活扩展和快速实现的资源数据管理平台，这也有力地支撑了基于数据流驱动的组件技术的实现。

五、关于基于模板和参数替换的通用配置引擎：

图3描述了CAP平台中的通用配置引擎的结构，在数据流的驱动下，通过业务参数模板审计组件，首先对info表示的不同业务请求参数进行有效性和正确性审计，info是采用XML描述的数据结构体，不同的业务开通请求数据结构是不同的，要增加对一种新业务开通配置，需要在预定义模板中增加一种描述新业务数据结构的模版，这个组件就可以对新业务进行处理。参数转换组件，接收经过审计的原子业务对象中的相关参数，获取对应的参数转换映射和运算配置，把业务参数转换为配置命令模板需要的参数。命令解析组件，关联到相关厂商、设备型号、操作系统版本，将命令参数与模板中的相关项进行替换，形成完成一个原子业务操作的、与设备相关的配置命令序列，并将命令序列放入到命令队列中。通过作业调度组件，将命令序列发送到命令执行和事务控制组件，完成对特定设备的配置。

通用配置引擎的特点在于：

1.实现了业务描述与命令描述特征的分离：命令生成的过程中，将模板审计、参数替换、命令解析的过程通过数据流驱动进行加工处理。模板替换可以实现统一的业务描述，将Info原子业务对象映射到不同厂商、不同型号的设备参数替换的模版；参数替换可以将定单中的业务参数映射到模板中的命令解析所需要的参数，以实现业务和设备命令的无关性；命令解析的过程才将命令的参数替换模板中的变量，以生成命令序列。

2.命令的执行与命令的生成过程完全独立，通过作业调度组件对队列中的命令序列进行FIFO的调度

3.系统的可扩展性好，可以部署多个不同的命令执行组件，一个命令执行组件，可以配置telnet、ssh等不同的命令交互方式。

通过以上的技术手段，本发明可以做到对任何类型的业务开通，只需要定制相关的模板和参数映射表，就可以实现从业务描述到设备命令序列的映射，以及与设备之间的命令序列的交互。

六、关于基于资源的成本模型路径选择算法：

1.成本模型的建立

从本质上讲，业务开通的过程就是对网络中的业务点设备或者业务点设备组成的路径进行自动化的配置。在人工配置过程中，业务点设备或路径都是由人工根据选择规则进行选择指定，对于自动开通系统，就需要解决业务点设备或路径的选择问题。

基于资源的成本模型和基于成本的路径选择算法是本方案解决业务自动开通过程中端到端路径选择的方法，这里的成本并非经济学中的货币量衡的价值，而是一个扩展的概念，成本是一组影响路径选择的因子(如带宽，最短路径，造价以及用户特殊规定的因素)按照权重组合形成的一个综合指标，成本需要跟随其影响因素的变化而变化，成本与寻径节点所代表的资源对象(例如，设备)直接相关。

通过与资源模型结合，使成本成为每个资源对象都具有的一个属性，资源模型和成本模型之间的关系如下：

成本模型是在网络模型和资源模型的结合基础上进行变换形成。不管是从应用，还是从技术角度，网络模型是整个电信网络的骨架，把网络中的每个设备元素作为一个点进行看待，描述的是网络中所有网元点之间的关系；而资源则是对每个设备作为网元对象本身进行描述，表示了设备对象的特征。

网络模型和资源模型结合，变换之后形成的成本模型，不仅具备网络模型的构架，同时具备了资源模型的内容。形成成本模型的结合点是网元，变换操作不仅计算产生了成本因子，并且对网络模型的结构进行了调整，成本模型沿袭了网络模型的结构，但是对其边缘进行突出，把边缘对象强化，把非边缘对象进行隐藏屏蔽，只在本网络内部可见，使同层的网络对象关系简化为仅仅是网络之间边缘节点之间的连接；在成本模型的每一个结构层次上，呈现的都是点和线形成的简单图形，成本体现在点之间的连线上。

图4中的黑色实心原点就是边沿网元，3个大的椭圆表示同一层次的3个子网对象，子网之间的连线表示边缘连接，线上的数字表示这个连接路径的成本；两边的单节点连线表示了超出了管理范围的边界节点和连线。

在成本模型的上下相邻两层子网对象之间是C/S关系，上层C网络中的每两个边缘端点之间的连接都要有至少一条对应的下层S网络对象内以及对象间的连接(如上图5)，使得C/S之间的服务委托关系能够顺利进行；

建立了成本模型，就为路径选择建立了理论基础。

2.路径选择算法

进行路径选择，首先就是产生一个符合成本模型的路径选择实体图，路径选择参考图是遵守成本模型，具体的结合实际的网络模型图和实际的资源模型实体，并进行转换和成本因子运算的结果。成本因子的运算是根据业务需要，确定影响路径选择的要素，并指定每个要素影响的权重和运算公式，把路径选择影响要素汇集成为一个算法因子。

同层网络成本图基本上是在网络模型图的基础上，区分边缘和内部，分别建立边缘连接和内部连接，关联成本因子到每个连接。

上下层网络成本图的产生是下层成本图向上的一个汇聚和简化：把内部节点和网络内连接对上隐藏，只把边缘节点和边缘连接在上层网络对象中暴露，并上升为上层对象的内部连接或者边缘连接；

根据成本模型形成了选径图，如何从中选择一条符合业务需求的路径，则是路径选择算法的工作。

提到选择算法，从技术角度讲有两种选择方向，一个是深度，一个是广度。

CAP的路径选择算法是建立在成本模型基础之上的，是结合了深度和广度两种方式的算法。路径选择就是按照成本模型为基础进行，根据成本模型的产生特征，路径选择分成同层选径和上下层选径两种过程，同层选径是广度算法，上下层选径是深度算法，一个路径选择请求就是通过两种方式的结合，互相交叉，最后完成最佳路径的选择。上下层路径选择就是通过C/S的原语实现，上次请求直接委托给下层进行实现(图5已经形象的表示了上下层选择的算法了)；同层之间选径分为网络对象间和网络对象内两种，网络对象间路径选择就是根据成本选择子网之间的连接，网络对象间仅存在连接关系，没有中间点，并且连接的数量一般很少；

网络内选径是最复杂的，在这个层次采用‘广度优先’的算法。首先选择路径选择参考点(路径选择参考点一定是网络边缘点，并且是上层指定的节点，是确定的)，根据成本模型图关系获取与选择参考点直接关联的所有备选连接，然后根据成本选择条件，确定一条最佳的连接；在确定最佳连接的同时，选择参考点就会移动到连接上一个参考点的最佳连接的对端点，以此类推，直到网络的输出边缘点。输出边缘点的确定一般也是上层委托时指定的，是确定的。

下面举例说明这个算法。如下图6的某个网络选径图(这张图仅反映下述请求执行之前的情况，选择的路径在被部署业务后，选径图就会发生变化)，图中白底黑字的节点表示这个网络的边缘节点(其中节点10，11连接到同一个外部网络)，灰底黑字的节点是网络内节点，黑底白字的节点是通过选择之后确定的业务开通路径经过的节点(这些节点都是中间节点)；实线是节点间的电路连接，粗实线表示路径选择的结果，细实线表示两条路径选择过程中的可能路径；节点图标中的数字表示该节点在网络中的编号，实线上的数字是电路的成本。

要求：选择一条以节点1为输入节点，以10或者11为输出节点的一条成本最低的路径；

【假定上图6中的所有网络节点的服务特征都满足业务需求】

算法描述：首先以节点1为中心，采用波浪线对与其直接相连的节点进行扫描，得到所有的备选路径节点(如图6中的2，3，4)，根据选径规则选出符合条件的路径和通过的节点(图6中的节点3和1与3之间的电路连接)；接下来以3为中心，采用同样的方法继续进行(注意：已经选择过的节点不能再被作为备选节点)，直至到达输出节点。在选择的过程中，会出现某个节点到它的下一个节点的所有路径都是相同的成本(如节点5的情况)，这是就需要就每个下步节点分别进行，得到所有备选路径，最后从所有已选出的路径集中再选出最符合条件的路径(集)；由于网络的复杂性，选径过程中也会发生断路的情况(比如图6中，假如6-4间电路的成本也是1时，以4为起点，就没有可以选择的路径了，此时，这条路径就放弃。

结果：遵循上述算法，选径的最后结果是：1-3-5-6-9-11；

路径选择的结果必须是一条或者多条可以进行业务参数配置操作的网络对象的有序组合。

七、关于业务处理过程中的事务控制：

业务开通的前后，导致了网络和资源对象属性和特征的改变，特别是对于端到端的业务开通过程中会涉及到对整个路径上所有或者多个网元设备的配置，整个路径上配置数据的一致性和完整性，是业务开通配置必须处理的一个重点问题。在CAP中，引入了事务处理机制。

事务(Transaction)这个概念最初是在数据库领域进行应用，有效的保证了数据库中数据的完整性和一致性。这里的事务概念和数据库领域的概念是一致的，不同的是应用到了电信领域的业务开通配置过程控制中。

在CAP中，事务包括两个层面(如下图7)：一个是面向业务的事务，保证了每个业务配置开通中所涉及到的网络设备的操作一致性；另一个是面向每个网络设备，保证一个业务的开通配置命令在设备上的完整性；也就是说，在CAP中事务控制是分层控制的，上面的第一个层面的控制是面向用户业务请求，后一个控制是面向网络设备。

在CAP的事务控制设计中，事务的最小单元是一个业务请求在单个网络设备的开通配置动作，一个业务请求是有多个最小单元的事务组合形成，CAP事务控制器完成业务层事务向最小事务单元的分解，并监测和管理每个最小事务单元的生命期。

CAP的事务控制具备较强的业务特征性，事务的生命期管理可以根据不同的业务开通特征进行灵活配置，比如对于端到端的业务开通，整个业务事务中的任何一个最小事务单元失败，也就是在整个业务路径上的任何一个设备配置失败，整个事务就失败，全部回滚，业务层事务和设备层事务是一体的，不管是业务层处理还是设备层配置，任一出现失败，则整个业务层事务和所有的设备层事务都回滚；对于多点的接入业务，多点中的每个点配置互不影响，业务层事务和设备层事务是分立的，比如MPLSVPN业务开通，事务控制就仅仅需要对最小单元进行控制，保证每个点的事务性，单个点的开通配置失败，并不需要对整个业务层事务进行回滚，但是业务层事务处理失败，则必然会影响到设备层事务。

因此，CAP的事务控制是事务的概念在电信领域业务开通的一个扩展应用，通过两个层次的事务划分，使得事务和业务特征结合的更充分，更符合领域的需求。

八、关于产品结构：

根据以上的技术方案的描述，基于CAP的应用产品结构描述如下：

1.在网元配置层，通过通用配置引擎和相关的适配器模块，完成设备命令的形成和配置下发，可以形成命令序列的方式直接与设备交互，也支持通过厂商所提供的网元管理系统(EMS)的API接口完成。

2.在核心开通引擎层，实现路径选择、特征映射、事务控制、服务派发、资源问询、异常处理等功能，各个组件之间通过消息连接件以XML方式传递相关的信息。

3.核心开通引擎的北向接口是定单适配器，负责将业务定单系统的定单信息转换为系统所能够识别的开通业务对象(Order)；南向接口负责将核心开通引擎所形成的原子业务对象(Info)下发给相关的配置引擎。

4.整个系统由基于数据流驱动的组件组成，组件和组件之间通过消息连接件进行通信，通信的数据交互格式通过XML描述。根据组件完成功能的层次不同，划分为以上的产品结构。

Claims (9)

1.核心开通平台系统，其特征在于：整个系统由基于数据流驱动的系列组件组成，各个组件之间通过消息连接件进行数据通信，每个组件中具有定义数据处理的规则文件，每个组件作为数据流的处理环节或节点能够被组织到数据处理流程中；

所述系列组件包括：业务对象分解组件、形成原子业务对象组件、业务模板参数审计组件、参数转换组件和命令解析组件，所述业务对象分解组件用于：非带宽型业务开通的业务对象的分解；所述形成原子业务对象组件用于：将业务对象组合映射为原子的不可分割的业务对象，作为业务开通的最小单元；所述业务模板参数审计组件用于：对info表示的不同业务请求参数进行有效性和正确性审计，info是采用XML描述的数据结构体，不同的业务开通请求数据结构是不同的，要增加对一种新业务开通配置，需要在预定义模板中增加一种描述新业务数据结构的模版，这个组件就能够对新业务进行处理；所述参数转换组件用于：将原子业务对象中的相关参数，获取对应的参数转换映射和运算配置，把业务参数转换为配置命令模板需要的参数；所述命令解析组件用于：将命令参数与配置命令模板中的相关厂商、设备型号和操作系统版本的相关参数项进行替换，形成完成一个原子业务操作的、与设备相关的配置命令序列。

2.根据权利要求1所述的核心开通平台系统，其特征在于：所述系列组件中包括作为数据最初入口的定单适配组件和作为数据最终出口的命令执行控制组件，所述定单适配组件用于：将不同数据格式的业务定单转化为待开通业务对象的数据加工节点，待开通业务对象是系统能够识别的数据结构；所述命令执行控制组件用于：根据命令序列的控制内容，执行相关的命令操作，完成对设备的相关配置任务。

3.根据权利要求1所述的核心开通平台系统，其特征在于：所述非带宽型业务开通的业务对象的分解是指：将接入型业务对象作为一个整体的业务对象分解为若干个业务对象的组合，或者，对于MPLS VPN业务开通而言，将一个VPN业务对象分解为若干个SITE对象的组合。

4.根据权利要求3所述的核心开通平台系统，其特征在于：所述系列组件中包括：端到端路径选择组件、客户层QOS向网络层QOS的映射组件和作业调度组件，所述端到端路径选择组件用于：根据待开通业务对象所描述的业务信息，根据资源数据的组织，进行端到端路径的选择，能够做到跨网络、跨地域、跨层次的选径，能够根据不同的路径选择策略进行路径的选择；在完成路径的选择之后，待开通业务请求就转化为由若干段路径组成的业务对象组合；所述客户层QOS向网络层QOS的映射组件用于：在经过分解的业务对象组合层次，将客户层的QOS服务的描述，分解到每一个业务对象上，作为业务对象组合的描述；所述作业调度组件用于：将命令队列中的命令序列按照调度规则进行调度，发送到命令执行和事务控制组件；所述命令执行和事务控制组件按照命令序列，完成对特定设备的配置。

5.根据权利要求4所述的核心开通平台系统，其特征在于：所述端到端路径选择组件能够调用资源查询组件，从统一资源库中进行资源信息的查询。

6.根据权利要求1所述的核心开通平台系统，其特征在于：所述业务对象分解组件能够调用资源查询组件，从统一资源库中进行资源信息的查询。

7.根据权利要求1所述的核心开通平台系统，其特征在于：所述消息连接件能够实现对数据流每一个处理环节的数据持久化和数据核查。

8.根据权利要求1所述的核心开通平台系统，其特征在于：所述数据统一采用XML语言来进行描述，数据加工的配置文件也采用XML文件来统一地进行描述。

9.根据权利要求1所述的核心开通平台系统，其特征在于：该系统能够采取并行数据流处理，也能够通过重新组织数据处理组件及其数据处理的规则文件以适应数据处理流程的变化。

Images