CN101119526A - 移动通信系统中消息接口完全可配置框架的装置及其方法 - Google Patents

Abstract

本发明公开了一种移动通信系统中消息接口完全可配置框架的装置及其方法，所述移动通信系统包括前台、后台，所述前台上设置有业务接口模块；所述后台上设置有网管框架模块，其中该方法包括：步骤一，建立所述业务接口模块与所述网管框架模块之间的链接；及步骤二，由所述业务接口模块根据所述网管框架模块提供的脚本描述文件实现所述前台与所述后台之间的业务接口的对齐，所述网管框架模块通过写脚本描述文件加入网管版本。本发明采取了措施对三种情况分别作了框架上的抽象，减少了项目之间的强耦合，很大程度上缓解了给网管产品带来的负面影响，提升了网络产品对需求的快速响应，和网管接口的广泛兼容性，提高了网管版本核心代码的稳定性。

Description

移动通信系统中消息接口完全可配置框架的装置及其方法

技术领域

本发明涉及移动通信技术，特别是涉及一种移动通信系统中定义前后台消息接口完全可配置框架的装置及其方法。

背景技术

网管领域中，存在着这样一个普遍的现象，网络管理系统(简称网管系统)与被管理对象之间存在大量的不同类型的消息接口。由于网络产品生产公司涉及很长的产品线，项目分工很细，一般网管版本的开发与实际通讯业务的前台版本开发属于不同部门、不同项目，这样前后台的接口问题就很突出了，经常是前台接口改变，而后台没有得到通知，导致版本发布出现问题。关于接口改变，最小的修改类似结构中某个字段类型的修改，某个字段宏值发生修改类似1表示“激活”改为3表示“激活”。这种修改会因前后台不同步而导致功能失败，很小的问题会带来网管异常、内存越界。接口问题常常直接影响到网络产品的发布与推广，对产品质量也有影响。因此网络产品生产公司需要花费较多的会议时间，用于接口变更的商讨与通知，同时也需要花费大量的时间用于与接口适配相关的编码与交流。

问题的关键在于不同项目针对同一个接口开发，接口的变化在前台项目，而后台项目却需要花费大量时间去适配，而且这种适配需要细心和耐心，经常发生前台单方面修改了接口，没有及时通知后台，从而导致网管系统的功能不可用。

网管系统与业务项目的接口只有消息接口，消息接口又分为三种类型：

1)目的端(后台)不对应数据库，并不必涉及数据类型、数据字典的转换；

2)目的端不直接对应数据库，但是消息交互采用了数据域信息描述与数据信息，仍要进行数据适配；

3)两端(前台、后台)都有数据库，需要进行数据适配。

目前，常见的实现方式都未对上述三种情况作特别处理，导致代码接口变更对齐工作量非常大，不利于网络产品的稳定。只要目的端是数据库且当涉及到目的端数据表的交互时，则比较麻烦，涉及数据库的类型适配、数据字典，需要大量的时间来解决接口变更与新功能的加入；由于不同版本，目的端数据库的数据字典定义就会有差别，如果不能设法将这种差异性从代码中分离出来，每次版本制作都会涉及代码的维护，比较繁琐，同时也容易出错。

另外，即使目的端不涉及数据库操作，接口仅涉及双边的数据结构的一致性约定，通常做法是采用前后台系统共用同一个数据结构的头文件，而只要涉及前台协议的调整，结构就会有修改，这样就涉及硬编码的调整，接口的变更导致代码的修改，不利于框架代码的稳定。

发明内容

本发明所要解决的技术问题在于提供一种移动通信系统中消息接口完全可配置框架的装置及其方法，用于解决前后台消息接口代码修改导致的框架代码整体不稳定的问题。

为了实现上述目的，本发明还提供了一种移动通信系统中消息接口完全可配置框架的装置，所述移动通信系统包括前台、后台，其特征在于，该装置包括：

业务接口模块，设置于所述前台上，用于根据接收的脚本描述文件实现所述前台与所述后台之间的业务接口的对齐；及

网管框架模块，设置于所述后台上，用于向所述业务接口模块提供所述脚本描述文件，并通过写脚本描述文件加入网管版本。

所述的消息接口完全可配置框架的装置，其中，所述业务接口为消息接口，包括：所述后台无数据库、所述后台有数据库、所述前台、所述后台都有数据库。

所述的消息接口完全可配置框架的装置，其中，当所述消息接口为所述后台无数据库时，所述业务接口模块根据所述网管框架模块的配置文件所定义的偏移找到对应的配置的域，根据定义的解析方法，查找相应的资源文件，给出对应的解析。

所述的消息接口完全可配置框架的装置，其中，当所述消息接口为所述后台有数据库时，所述业务接口模块通过将与接口相关的部分与相对不变的流程部分分离，并对与接口相关的部分采取配置文件与转换实行类进行处理。

所述的消息接口完全可配置框架的装置，其中，当所述消息接口为所述前台、所述后台都有数据库时，所述业务接口模块定义所述前台的数据字典的配置文件对常用类型的数组的处理抽取为默认处理，通过扩展转换策略类对相关业务进行处理。

为了实现上述目的，本发明提供了一种移动通信系统中消息接口完全可配置框架的方法，所述移动通信系统包括前台、后台，所述前台上设置有业务接口模块；所述后台上设置有网管框架模块，其特征在于，该方法包括：

步骤一，建立所述业务接口模块与所述网管框架模块之间的链接；及

步骤二，由所述业务接口模块根据所述网管框架模块提供的脚本描述文件实现所述前台与所述后台之间的业务接口的对齐，所述网管框架模块通过写脚本描述文件加入网管版本。

所述的消息接口完全可配置框架的方法，其中，所述消息接口包括：所述后台无数据库、所述后台有数据库、所述前台、所述后台都有数据库。

所述的消息接口完全可配置框架的方法，其中，所述步骤二中，进一步包括：当所述消息接口为所述后台无数据库时，所述业务接口模块根据所述网管框架模块的配置文件所定义的偏移找到对应的配置的域，根据定义的解析方法，查找相应的资源文件，给出对应的解析。

所述的消息接口完全可配置框架的方法，其中，所述步骤二中，进一步包括：当所述消息接口为所述后台有数据库时，所述业务接口模块通过将与接口相关的部分与相对不变的流程部分分离，并对与接口相关的部分采取配置文件与转换实行类进行处理。

所述的消息接口完全可配置框架的方法，其中，所述步骤二中，进一步包括：当所述消息接口为所述前台、所述后台都有数据库时，所述业务接口模块定义所述前台的数据字典的配置文件对常用类型的数组的处理抽取为默认处理，通过扩展转换策略类对相关业务进行处理。

本发明采取了措施对三种情况分别作了框架上的抽象，减少了项目之间的强耦合，很大程度上缓解了给网管产品带来的负面影响，提升了网络产品对需求的快速响应，和网管接口的广泛兼容性，特别是提高了网管版本核心代码的稳定性。

以下结合附图和具体实施例对本发明进行详细描述，但不作为对本发明的限定。

附图说明

图1是本发明消息接口完全可配置框架的装置结构图；

图2是本发明接口变更自适应示意图；

图3是本发明在线配置的类工厂示意图；

图4是本发明静态数据传输协议示意图；

图5是本发明表适配器前后台接口部分示意图。

具体实施方式

以下结合附图和具体实施例对本发明的技术方案作进一步更详细的描述。

如图1所示，是本发明消息接口完全可配置框架的装置结构图，该装置200用于移动通信系统100，移动通信系统100包括前台10、后台20，该装置200包括：

业务接口模块11；设置于前台10上，用于根据接收的脚本描述文件实现前台10与后台20之间的业务接口的对齐；

网管框架模块12；设置于后台20上，设置于后台20上，用于向业务接口模块11提供所述脚本描述文件，并通过写脚本描述文件加入网管版本。

前台10、后台20之间的接口体现在表适配器脚本与特殊转换策略上。

业务接口模块11将调用者发起表A的X局数据转换为前台格式；根据表适配器脚本，由表适配器获取前台数据字典和后台数据查询脚本；

业务接口模块11通过表适配器获取后台数据信息；并在必要时，由表适配器调用特殊转换策略；

表适配器执行后台数据模型到前台数据模型的转换，并返回解析得到的前台字节流。

如图2所示，是本发明接口变更自适应示意图。下面结合图1、2进一步描述第一种情况的解决方式。

第一种情况是目的端不对应数据库，并不必涉及数据类型、数据字典的转换。

针对目的端无数据库的情形，消息一去多回，典型地，例如失败观察的数据上报，而且回的消息信息含义不同，信息字段域间存在可以程序化的对应关系。不同应答数据的数据结构不同、定义不同，前后台都设定一个足够大的内存块，以适配全部不同大小的上报消息体，同时也约定一个消息头，消息头中定义实际数据大小、实际消息分类；后台根据消息头确定发往对应的处理线程。数据的处理根据配置文件定义的偏移找到对应的配置的域，根据定义的解析方法，查找相应的资源文件，给出对应的解析。

约定上报消息体不超过最大长度，消息头中有消息类型、实际长度信息，解析时根据消息的大类，由不同处理线程完成解析。

图2中，前台结构的解析，字段值到对应含义的资源文件的对应，全部由配置文件来实现，前台有新业务，或修改已有上报结构，不必修改代码，只用由业务人员自行加入或修改配置文件就可以了，实现了功能的完全可客户化，网管框架代码基本在很长的周期中都不必修改。

如图3所示，是本发明在线配置的类工厂示意图。下面结合图3进一步描述第二种情况的解决方式。

第二种情况是目的端不直接对应数据库，但是消息交互采用了数据域信息描述与数据信息，仍要进行数据适配。

针对目的端有数据库，消息一去一回。典型地，例如在线配置，后台有数据库，而前台没有对应的数据表。需要后台配置命令的查询SQL(StructuredQuery Language，结构化查询语言)，需要指定前台对应信息域的类型，抽取类型为BYTE、WORD、DWORD、IP、MAC(Media Access Control，媒体访问控制)地址、CONST常量类型等前台结构中固定的几种需要特别处理的类型，参见图3，其中类OprdataUtil提供了这些转换用公用函数提供给二次开发人员。

图3中提供的通用类工厂机制与工具类，将各个在线配置命令的前后台消息交互部分标准流程固化，将可变部分(数据信息转换)提取为接口，由不同实行类实现，前后台统一交互接口，接口中描述字段类型。将公共的处理抽取，将数据同步与命令执行代码合并一处，减少重复开发。

实际开发中每条在线配置命令，用户只用实现图3中AbstractCmd中的2个抽象方法SetLocation、getOprdata提供位置信息的获取逻辑和操作数据的拼装，实际上这两处体现了接口，其他部分通过框架把客户端信息获取、数据库信息的获取、消息发向前台的公共流程固化。新的功能加入只用针对接口写适配，提高了对需求的响应速度。

在线配置中前台无对应的关系表，后台才保持了关系表。关系表删除数据前，会检查是否有其他记录对该数据有引用；如果有，则不能删除；若直接先发前台，有可能前台已经删除成功，但是后台删除不了，而在线配置命令已经下发到网元，不能回滚。本发明中，如果在线配置存在与前台数据交互，先执行数据库操作，若执行失败，不必发消息到前台；否则给前台发消息，若发送失败后，后台事务回滚。通过临时表方式解决了后台先删除数据后，向前台发送删除命令时已经在后台删除的数据无法访问的问题。

进一步地描述临时表处理策略，其是在后台删除时，把删除的信息挪动到临时表中，仅仅在整个事务执行成功时，才清除临时表中的数据。

如图4所示，是本发明静态数据传输协议示意图；图5是本发明表适配器前后台接口部分示意图。下面结合图4、5进一步描述第三种情况的解决方式。

第三种情况是两端都有数据库，需要进行数据适配。

针对前后台两端都有数据库，同时数据库的数据对应关系不同，之间需要转换，并且这种转换多数情况不具备可逆性。前台是自研的内存数据库，后台是基于SQL92标准的商用数据库。

图5中，通过定义前台数据字典的配置文件，对常用类型BYTE、WORD、DWORD、BYTE数组、WORD数组、DWORD数组、各种BCD码、字符、16进制字符的典型处理抽取为默认处理方法，这种处理占转换的70％以上的工作，业务相关的特殊处理提供可以扩展的转换策略类。对于基本表，不必写代码，写配置文件就可以定义好数据查询脚本、前台数据字典，前后台数据转换关系；需要关注的转换策略类实际上就是用户需要特别处理的，例如，1个字段的值与其他字段、其他表相关记录的取值相关，或字符有特别处理，这样只要用户加入一个处理类，配置在配置文件对应字段的转换处理类定义上，系统可以通过JAVA反射机制调用。前后台接口体现在表适配器脚本与特殊转换策略上。

具体地，包括：

步骤501，将调用者发起表A的X局数据转换为前台格式；

步骤502，根据表适配器脚本，表适配器获取前台数据字典和后台数据查询脚本；

步骤503，表适配器获取后台数据信息；

步骤504，必要时，表适配器调用特殊转换策略；

步骤505，表适配器执行后台数据模型到前台数据模型的转换；

步骤506，返回解析得到的前台字节流。

以前这些工作是由大量的编码工作来完成的，并且这些编码都是对相同处理流程的大量重复拷贝，导致系统很难维护，改一处动全身。通过这样的处理，让前后台的数据库对应完全可配置，减少了开发成本，提高了系统对需求的响应速度。

前后台数据同步采用状态机，如乒乓机制，见图4，同时在接口上屏蔽了不同表数据字典上的不同，统一采用最大的字段数，消息可以分包处理，以支持大数据的表。根据状态机的不同状态，前后台的消息接口有不同，对于不同的数据，接口做到了抽象，接口结构中定义了有效长度，消息体为BYTE数组，内存区的处理由前台不同表对应函数自行处理。

本发明通过对上述三种情况的分析处理，很好地解决了网管系统中存在的问题。对于第一种情况，本发明实现了消息接口变更的自适应与网管功能零维护，如图2，本发明采取处理流程抽象方式，采用一个流程解析各类不同的上报，配置文件方式让应用可配置不同消息类型来对应不同结构体，同时结构体的对应码流的解析做到完全可配置，配置文件中定义哪个字段对应的码流起始位置，字段的类型(通常上报消息中可能的消息类型有WORD、BYTE、DWORD、CHAR、BCD、系统特有的时间日期类型)，甚至包括字段的解析方式，通常的解析是另外还有国际化的配置文件定义字段各种取值的含义。目前这边的部分模块，如失败观察的CS，PS，IMS各个项目的功能提交都实现了接口的变化由接口双方中的一方全部解决，保证了网管版本的稳定。

本发明对于涉及后台数据库的第二、三两种情况也妥善进行了解决。由于不仅仅是配置文件能解决的，需要对应修改后台相关数据库的创建脚本，配置界面，前后台数据库的适配工作，这些工作必须由后台网管人员来实现，这样能做的就是通过将接口相关的部分与相对不变的流程部分分离，变化部分采取配置文件与特殊转换实行类来处理，由于千百个不同表的操作命令对应的执行流程相同，仅仅是转换不同，通过这个处理让这类接口对齐工作量到最小。

本发明采取了措施对三种情况分别作了框架上的抽象，减少了项目之间的强耦合，很大程度上缓解了给网管产品带来的负面影响，提升了网络产品对需求的快速响应，和网管接口的广泛兼容性，特别是提高了网管版本核心代码的稳定性。

本发明通过对业务过程的深入研究，对现有代码的缺陷分析，运用泛化、部分特化的研究思路，在网管应用领域，针对较为普遍的前后台消息交互，提出了泛化与完全可配置框架，通过良好的架构，让业务开发人员关注于业务，把固定的流程处理抽取出来，把与业务接口部分相关的部分分离出来；让网管开发人员关注于网管框架的开发，而把公共业务接口的工作全部由前台业务开发人员完成，前台业务开发人员的工作是按后台提供的脚本说明配置脚本，以自行对齐业务接口，在新业务调试时，前台业务开发人员只用写脚本就可以完成网管新功能的加入，后台项目只用关注网管的功能、易用性、效率，可以不必关注前后台接口的变化，这样各司其责，从而有效保证产品质量。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (10)

1.一种移动通信系统中消息接口完全可配置框架的装置，所述移动通信系统包括前台、后台，其特征在于，该装置包括：

业务接口模块，设置于所述前台上，用于根据接收的脚本描述文件实现所述前台与所述后台之间的业务接口的对齐；及

网管框架模块，设置于所述后台上，用于向所述业务接口模块提供所述脚本描述文件，并通过写脚本描述文件加入网管版本。

2.根据权利要求1所述的消息接口完全可配置框架的装置，其特征在于，所述业务接口为消息接口，包括：所述后台无数据库、所述后台有数据库、所述前台、所述后台都有数据库。

3.根据权利要求2所述的消息接口完全可配置框架的装置，其特征在于，当所述消息接口为所述后台无数据库时，所述业务接口模块根据所述网管框架模块的配置文件所定义的偏移找到对应的配置的域，根据定义的解析方法，查找相应的资源文件，给出对应的解析。

4.根据权利要求2所述的消息接口完全可配置框架的装置，其特征在于，当所述消息接口为所述后台有数据库时，所述业务接口模块通过将与接口相关的部分与相对不变的流程部分分离，并对与接口相关的部分采取配置文件与转换实行类进行处理。

5.根据权利要求2所述的消息接口完全可配置框架的装置，其特征在于，当所述消息接口为所述前台、所述后台都有数据库时，所述业务接口模块定义所述前台的数据字典的配置文件对常用类型的数组的处理抽取为默认处理，通过扩展转换策略类对相关业务进行处理。

6.一种移动通信系统中消息接口完全可配置框架的方法，所述移动通信系统包括前台、后台，所述前台上设置有业务接口模块；所述后台上设置有网管框架模块，其特征在于，该方法包括：

步骤一，建立所述业务接口模块与所述网管框架模块之间的链接；及

步骤二，由所述业务接口模块根据所述网管框架模块提供的脚本描述文件实现所述前台与所述后台之间的业务接口的对齐，所述网管框架模块通过写脚本描述文件加入网管版本。

7.根据权利要求6所述的消息接口完全可配置框架的方法，其特征在于，所述消息接口包括：所述后台无数据库、所述后台有数据库、所述前台、所述后台都有数据库。

8.根据权利要求7所述的消息接口完全可配置框架的方法，其特征在于，所述步骤二中，进一步包括：当所述消息接口为所述后台无数据库时，所述业务接口模块根据所述网管框架模块的配置文件所定义的偏移找到对应的配置的域，根据定义的解析方法，查找相应的资源文件，给出对应的解析。

9.根据权利要求7所述的消息接口完全可配置框架的方法，其特征在于，所述步骤二中，进一步包括：当所述消息接口为所述后台有数据库时，所述业务接口模块通过将与接口相关的部分与相对不变的流程部分分离，并对与接口相关的部分采取配置文件与转换实行类进行处理。

10.根据权利要求7所述的消息接口完全可配置框架的方法，其特征在于，所述步骤二中，进一步包括：当所述消息接口为所述前台、所述后台都有数据库时，所述业务接口模块定义所述前台的数据字典的配置文件对常用类型的数组的处理抽取为默认处理，通过扩展转换策略类对相关业务进行处理。

Images