CN101145945B - 一种电信网络管理中消息总线系统及控制方法 - Google Patents

Abstract

本发明公开了一种电信网络管理中消息总线系统及控制方法，该系统包括：服务层、通讯层、人机语言工具模块；服务层用于向上层应用模块提供发送请求和通知消息的服务，并对所述请求进行鉴权和记录日志；通讯层用于向服务层提供通讯支持，完成所述请求和通知消息的收发并通知服务层；人机语言工具模块用于向通讯层提供人机命令的解析和拼装服务，处理不同版本间人机命令的互通性。本发明解决了多种异构系统之间的互通，减轻了应用模块开发的工作量；消息总线系统实现了自接入，一个操作维护管理系统接入进来，只需要把消息总线系统在操作维护管理系统上部署好，然后实现应用逻辑相关的处理就可以了。

Description

一种电信网络管理中消息总线系统及控制方法

技术领域

本发明涉及电信网络管理技术领域，尤其涉及一种电信网络管理中消息总线系统及实现方法。 

背景技术

为了对全网设备进行管理，业界都一般采用对网管进行分级管理的方法。网管层次分为NMS(Network Management System网络层管理系统)/EMS(Element Management System网元层管理系统)/OMM(Operation Maintenance Management操作维护管理系统)三层。每层的功能是：NMS是网络层网管，完成所有电信产品的统一网管，并提供和OSS运营支撑系统的整合；EMS是网元层网管，实现对不同专业网网元的集中管理；OMM直接管理网元，完成对网元的单点管理。随着电信业的发展，各种各样的设备越来越多，每个设备都带一套管理系统，导致维护运营越来越困难，所以运营商对能够实行集中管理的EMS系统要求越来越高。 

现有网管系统中各专业网都独自开发自己的OMM系统，这些系统对外提供北向接口的协议都各不相同，并且各专业网的OMM系统版本管理难于控制，变化频繁。多数情况下都是多套版本同时在运行，不同版本之间的接口都存在差异。 

现有的解决上述问题的方法主要有以下两种： 

1、基于Java的RMI(Remote Method Invocation远程方法调用)和EJB(Enterprise Java Bean企业级JavaBean)远程调用，这种方式使用起来方便，开发简单快速。传递信息格式能够做到统一，都是使用Java类的序列化。但是它不能做到异构系统的互通，无法整合多种通讯途径，而且必须严格保证class的版本一致才能正确进行调用，无法适应各OMM系统多套版本同时运行的要求。 

2、CORBA(Common Object Request Broker Architecture公共对象请求代理体系结构)可以实现异构系统的互通，但是使用起来复杂，很难让开发人员快速上手进行开发，同时对多套版本同时兼容的问题也难以解决。 

发明内容

本发明所要解决的技术问题是提供一种电信网络管理中消息总线系统及方法。 

为解决上述技术问题，本发明是通过以下技术方案实现的： 

一种电信网络管理中消息总线系统，包括：服务层、通讯层、人机语言工具模块； 

服务层用于向上层应用模块提供发送请求和通知消息的服务，并对所述请求进行鉴权和记录日志； 

通讯层用于向服务层提供通讯支持，完成所述请求和通知消息的收发并通知服务层； 

人机语言工具模块用于向通讯层提供人机命令的解析和拼装服务，处理不同版本间人机命令的互通性。 

其中，所述服务层还用于注册和取消远端异步通知监听器。 

其中，所述服务层与通讯层间的接口通过通讯层的应用程序接口定义。 

一种如前面所述消息总线系统中命令请求处理的方法，包括以下步骤： 

a：上级应用模块生成一个请求消息，并将此请求消息发送给上级服务层； 

b：上级服务层根据请求消息查找其所要求的通讯协议，并将该请求发送给对应通讯协议的上级通讯层； 

c：上级通讯层通过下级通讯层将请求消息发送给下级服务层； 

d：下级服务层根据请求消息找到对应的下级应用模块，调用该下级应用模块来处理请求，并返回回应消息给上级服务层； 

e：上级服务层根据回应消息查找对应的请求线程，通过此线程将回应消息返回给上级应用模块。 

其中，步骤a与步骤b之间还包括上级服务层寻找是否存在空闲请求线程；如果有，则分配一个空闲线程给请求，开始执行请求；如果没有，并且线程数没有超过控制上限，则创建一个线程来执行请求。 

其中，所述步骤c进一步包括：上级通讯层调用其人机语言工具将请求消息转换为人机命令，并将其发送给下级通讯层，下级通讯层再调用其人机语言工具将此命令转换为请求消息后发送给下级服务层。 

其中，步骤d中返回回应消息给上级服务层具体包括：下级应用模  块返回回应消息给下级服务层，下级服务层将回应消息发送给下级通讯层，下级通讯层调用人机语言工具模块完成回应消息和人机命令的相互转化，并将回应消息通过上级通讯层发送给上级服务层。 

一种如前面所述消息总线系统中异步通知处理的方法，包括以下步骤： 

a：下级应用模块调用下级服务层接口，创建异步通知主题，并发送一个异步通知消息给下级服务层； 

b：下级服务层将异步通知消息通过下级通讯层和上级通讯层发送给上级服务层； 

c：上级服务层查找注册到上述主题上的监听链路，依次调用上级应用模块的各个监听器处理异步通知消息； 

d：上级应用模块处理完成，返回回应消息给下级应用模块。 

其中，步骤a中创建异步通知主题后还包括：上级应用模块通过调用上级服务层接口注册对应主题的监听器，上级服务层将注册请求发给上级通讯层，并于上级通讯层建立一条监听链路。 

其中，所述步骤b进一步包括：下级服务层将异步通知消息发送给下级通讯层，下级通讯层调用人机语言工具模块将此消息转换成人机命令后发送给上级通讯层，上级通讯层再通过调用其人机语言工具模块将此人机命令转换成异步通知消息后发送给上级服务层。 

本发明提供的消息总线系统实现了不同专业网OMM之间的互连互通，能够同时管理多套版本不同的OMM，具有以下有益效果： 

1、能够很方便的扩展通讯层。通讯层的独立，使得能够很方便的  对通讯层进行扩展，要多支持一种新的协议，只需要增加一种相应协议的通讯层实现，很好的解决了多种异构系统之间的互通。 

2、实现了上层应用和底层通讯的解藕。对上层应用来说，完全不需要关注服务层之下的通讯层，上层应用只同服务层交换数据，使用起来很方便，让应用开发人员能够专注于业务逻辑的开发。 

3、上级EMS网管版本和下级OMM网管版本的解耦。由于采用了传递人机命令的方式，上级EMS网管和下级OMM网管可以互相独立的出版本，互相不影响，EMS的版本就不用跟随OMM的版本作频繁的变动。 

4、上级EMS也能够同时管理多个版本的OMM系统，为实际开局环境中多版本混合组网提供了可能。 

5、EMS和OMM之间的接口统一、明确、清晰。EMS和OMM之间的接口全部采用MML(人机语言)人机命令的形式，可读性好，给开发过程中的对接调试也提供了极大的方便。 

6、减轻了应用模块开发的工作量。消息总线系统实现了自接入，一个OMM接入进来，只需要把消息总线系统在OMM上部署好，然后实现应用逻辑相关的处理就可以了。消息总线系统还集中实现了一些公共功能。 

附图说明

图1为消息总线系统结构图； 

图2为消息总线系统各个组成单元分布图； 

图3为命令请求过程序列图； 

图4为异步通知处理流程图。 

具体实施方式

本发明的核心思想：通过提供一种综合EJB(企业级JavaBean)和CORBA(公共对象请求代理体系结构)两者优点的消息总线系统，并采用了人机命令作为统一的信息表现形式，解决EMS系统和各专业网OMM之间的互连互通问题，而且在接入同一系统的不同版本时能够保持兼容，从而实现在EMS对不同专业网网元的统一管理。 

其中，采用人机命令作为统一的信息表现形式，有两点主要原因：a：EMS和OMM之间的版本兼容问题，从本质上讲就是信息表达形式的兼容问题，设计良好的人机命令能够满足兼容性的要求；b：人机命令简单易于理解，开发人员也很习惯使用人机命令。 

消息总线系统本身具有自接入的特性，只要在EMS和OMM上都部署一套消息总线系统，它们之间就可以连通了。同样，如果接入NMS系统，在其上部署一套消息总线系统就可以连到EMS系统了。 

下面结合附图及实施例对本发明作进一步详细的描述： 

请参阅图1所示消息总线系统结构图，包括：服务层12、通讯层13和MML工具14三个部分组成； 

服务层12：直接面向上层应用，为应用模块11提供发送请求和异步通知的服务，完成一些能够集中处理的功能，如：命令鉴权、记录日志等。主要功能包括：接收从应用模块11来的请求，将请求分发给对应的通讯层13去完成请求发送；从通讯层13接收请求的回应，并交给相应的应用模块11；从通讯层13接收从远端来的请求，派发给相应的  应用模块11执行该请求，并将请求的回应通过相应的通讯层13发回远端。能够注册和取消远端异步通知监听器；从通讯层13接收从远端来的异步通知，将异步通知派发给相应的应用模块11进行处理。完成系统中全局的线程调度和管理，对请求进行鉴权并记录日志。 

通讯层13：为服务层12提供通讯支持，主要完成请求和通知的收发并通知服务层12、维护链路的有效性和各种网络异常的处理。通讯层13向服务层12暴露的接口通过通讯层API定义，API的多个实现可以同时接入到服务层12中，每当接入一种专业网OMM时，只需要使用这个OMM定义的通讯协议实现通讯层API，然后接入到服务层12中，EMS上的应用模块就可以和这个OMM相互通讯了。 

MML工具模块14：这部分主要功能是完成人机命令的解析和拼装工作，同时要处理不同版本间人机命令的兼容性问题。通讯层13在发送请求时，使用本模块将请求转换成人机命令；相应的，在收到人机命令时，使用本模块将其转换成回应消息。其他异构的系统只要基于同样的人机命令格式也可以通过消息总线系统接入。消息总线系统不直接向应用模块暴露人机命令，而是一些定义好的消息类，这样符合开发人员面向对象的开发习惯，也减小了应用模块开发的工作量 

如图2所示，为本发明实施例中消息总线系统各个组成单元分布图。上级和下级各部署了一套完全相同的消息总线系统。自接入时，上下级的区别主要体现在服务层上，在上级的服务层21，负责将请求消息转发给通讯层22和从通讯层22接收并派发回应消息，而下级的服务层23则负责处理请求。如果是在一个三级结构中，中间一级既是上级，也要  充当下级的角色，所以此时它的服务层需要完成两者功能的和。通讯层和MML工具模块在上下级的作用是一样的。 

实施例1： 

如图3所示，为本发明实施例中一个请求到完成整个过程的序列图。同步请求的过程是由上级应用模块发起，中间通过消息总线系统传递，到下级再由应用模块处理请求，最后又通过消息总线系统传递回上级。 

具体步骤如下： 

步骤301：应用模块生成一个请求消息，填入请求码，调用消息总线系统服务层对外提供的接口，向下级发起一个同步请求。 

步骤302：服务层寻找是否存在空闲请求线程，如果有则分配一个空闲线程给请求，开始执行请求。如果没有，并且线程数没有超过控制上限，则创建一个线程来执行请求。如果超过线程数上限，返回异常给调用者。 

步骤303：根据请求查找其所要求的通讯协议，将请求发给实现了对应通讯协议的通讯层，同时请求线程等待请求结果回来。如果等待时间超时结果还未返回，则不再等了，返回异常给调用者。 

步骤304：调用MML工具模块将请求消息转换成人机命令，出现错误时返回异常给调用者。 

步骤305：将人机命令发到下级的消息总线系统，出现错误时返回异常给调用者。 

步骤306：调用MML工具模块将人机命令转换成请求消息，出现错误时返回异常给调用者。 

步骤307：将请求消息发到服务层。 

步骤308：查找是否存在空闲的处理线程，如果有则分配一个空闲线程给这个请求，开始处理请求。如果没有，并且线程数没有超过控制上限，则创建一个线程来处理请求。如果超过线程术上限，返回异常给上级。 

步骤309：根据请求码找到对应的应用处理模块，调用应用处理模块来处理请求。 

步骤310：应用模块处理完成，返回回应消息给服务层。如果处理过程中出现错误，应用模块返回异常给服务层。 

步骤311：服务层将应用模块返回的回应消息或异常消息交给通讯层。 

步骤312：通讯层调用MML工具模块将回应消息转换成人机命令。出现错误时返回异常。 

步骤313：将人机命令发到上级的消息总线系统。 

步骤314：调用MML工具模块将人机命令转换成回应消息。出现错误时返回异常。 

步骤315：将回应消息发给服务层。 

步骤316：找到与回应消息对应的正在等待的请求线程，将回应传给该线程并激活它重新运行。 

步骤317：请求线程重新运行，将回应消息返回给调用者应用模块。 

实施例2： 

如图4所示，为本发明实施例中一个异步通知到处理完成整个过程  的序列图。异步通知的过程是由下级主动发出通知，通过消息总线系统传递到上级，由上级应用模块完成异步通知的处理。具体步骤如下： 

步骤401：下级应用模块调用服务层接口，创建一个异步通知主题。 

步骤402：创建成功，返回控制给应用模块。如果失败则会返回异常给应用模块。 

步骤403：上级要能够收到下级的通知还必须进行注册，把自己的监听器注册到想要监听的主题上。通过调用服务层的接口进行注册。 

步骤404：服务层将注册请求发给通讯层。 

步骤405：同下级建立一条监听的链路。如果该主题已经被多次注册，则公用一条监听链路。 

步骤406：链路建立成功，返回。 

步骤407：返回到服务层。 

步骤408：返回给应用模块。 

步骤409：下级应用模块发出一个异步通知。 

步骤410：将通知消息交给通讯层。 

步骤411：将通知消息转换成人机命令。出现错误则返回异常给应用模块。 

步骤412：查找注册到这个主题上的所有监听链路。 

步骤413：依次往所有查找的监听链路上发送人机命令。其中某些出现失败的情况就忽略。 

步骤414：上级通讯层将人机命令转换成通知消息。如果失败则忽略，不再往服务层转发。 

步骤415：将通知转交给服务层。 

步骤416：查找所有注册到主题上的监听器。 

步骤417：依次调用各个监听器处理通知消息。 

步骤418：应用模块处理完成，返回。 

以上为消息总线系统处理请求和通知的主要流程。通过请求和通知，能够完成应用模块所有的上下级交互。从而可以将EMS和各专业网OMM很好整合起来，如果还要接入NMS系统，依据上述思想，本发明提供的消息总线系统同样可以实现。 

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。 

Claims (10)

1.一种电信网络管理中消息总线系统，其特征在于，包括：服务层、通讯层、人机语言工具模块；

服务层用于向上级应用模块提供发送请求和通知消息的服务，并对所述请求进行鉴权和记录日志；

通讯层用于向服务层提供通讯支持，完成所述请求和通知消息的收发并通知服务层；

人机语言工具模块用于向通讯层提供人机命令的解析和拼装服务，处理不同版本间人机命令的互通性；所述人机语言工具模块还用于将基于同样的人机命令格式的其他异构的系统通过消息总线系统接入。

2.如权利要求1所述的电信网络管理中消息总线系统，其特征在于，所述服务层还用于注册和取消远端异步通知监听器。

3.如权利要求1或2所述的电信网络管理中消息总线系统，其特征在于，所述服务层与通讯层间的接口通过通讯层的应用程序接口定义。

4.一种如权利要求1所述消息总线系统中命令请求处理的方法，其特征在于，包括以下步骤：

a：上级应用模块生成一个请求消息，并将此请求消息发送给上级服务层；

b：上级服务层根据请求消息查找其所要求的通讯协议，并将该请求发送给对应通讯协议的上级通讯层；

c：上级通讯层通过下级通讯层将请求消息发送给下级服务层；

d：下级服务层根据请求消息找到对应的下级应用模块，调用该下级应用模块来处理请求，并返回回应消息给上级服务层；

e：上级服务层根据回应消息查找对应的请求线程，通过此线程将回应消息返回给上级应用模块。

5.如权利要求4所述的消息总线系统中命令请求处理的方法，其特征在于，步骤a与步骤b之间还包括上级服务层寻找是否存在空闲请求线程；如果有，则分配一个空闲线程给请求，开始执行请求；如果没有，并且线程数没有超过控制上限，则创建一个线程来执行请求。

6.如权利要求4或5所述的消息总线系统中命令请求处理的方法，其特征在于，所述步骤c进一步包括：上级通讯层调用其人机语言工具将请求消息转换为人机命令，并将其发送给下级通讯层，下级通讯层再调用其人机语言工具将此命令转换为请求消息后发送给下级服务层。

7.如权利要求4或5所述的消息总线系统中命令请求处理的方法，其特征在于，步骤d中返回回应消息给上级服务层具体包括：下级应用模块返回回应消息给下级服务层，下级服务层将回应消息发送给下级通讯层，下级通讯层调用人机语言工具模块完成回应消息和人机命令的相互转化，并将回应消息通过上级通讯层发送给上级服务层。

8.一种如权利要求1所述消息总线系统中异步通知处理的方法，其特征在于，包括以下步骤：

a：下级应用模块调用下级服务层接口，创建异步通知主题，并发送一个异步通知消息给下级服务层；

b：下级服务层将异步通知消息通过下级通讯层和上级通讯层发送给上级服务层；

c：上级服务层查找注册到上述主题上的监听链路，依次调用上级应用模块的各个监听器处理异步通知消息；

d：上级应用模块处理完成，返回回应消息给下级应用模块。

9.如权利要求8所述的消息总线系统中异步通知处理的方法，其特征在于，步骤a中创建异步通知主题后还包括：上级应用模块通过调用上级服务层接口注册对应主题的监听器，上级服务层将注册请求发给上级通讯层，并于上级通讯层建立一条监听链路。

10.如权利要求8所述的消息总线系统中异步通知处理的方法，其特征在于，所述步骤b进一步包括：下级服务层将异步通知消息发送给下级通讯层，下级通讯层调用人机语言工具模块将此消息转换成人机命令后发送给上级通讯层，上级通讯层再通过调用其人机语言工具模块将此人机命令转换成异步通知消息后发送给上级服务层。

Images