CN103684904A - 基于ip三网融合网络监控系统 - Google Patents
基于ip三网融合网络监控系统 Download PDFInfo
- Publication number
- CN103684904A CN103684904A CN201310569865.5A CN201310569865A CN103684904A CN 103684904 A CN103684904 A CN 103684904A CN 201310569865 A CN201310569865 A CN 201310569865A CN 103684904 A CN103684904 A CN 103684904A
- Authority
- CN
- China
- Prior art keywords
- monitoring module
- network
- client
- ems
- request broker
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及网络监控技术领域,具体为一种基于公共对象请求代理体系结构的网络监控系统,采用三层结构,分别为网络管理系统(NMS),网元管理系统(EMS)和网元(NE),所述NE和EMS之间采用SNMP接口连接,所述NE通过私有接口连接各客户端,所述NMS和EMS之间和设有故障监控模块、配置监控模块、性能监控模块和安全监控模块,所述故障监控模块、配置监控模块、性能监控模块和安全监控模块均架设于公共对象请求代理体系结构(CORBA),所述公共对象请求代理体系结构,包括对象请求代理单元、客户存根(stub)、实现骨架(skeleton),对象适配器、接口池、实现池和调用方法,本发明简单易于实现,不需要运行网络设备的改动和升级即可实现全网可管可控的综合网络监控。
Description
技术领域
本发明涉及信息处理技术领域,具体涉及一种基于IP三网融合网络监控系统。
背景技术
三网融合是指电信网、计算机网和有线电视网三大网络通过技术改造,能够提供包括语音、数据、图像等综合多媒体的通信业务。这样各通信运营商的网络规模变得越来越大,包括核心网、传输网、分组交换网、智能网和接入网等等,网络设备的种类和数量也不断增加,整个网络的复杂性日益提高。因此多厂商设备的网络管理问题非常突出,尽管每个厂商都提供了对自己设备的网络监控系统,然而这些网络监控系统无法提供统一的接口和数据指标,更重要的是网络管理作为一个整体却被这些相互独立的网络监控系统划分开来,导致目前各类网络如铁路警察各管一段,无法做到全网可管可控的综合网络监控。
针对上述网络监控的问题,运营商都希望能够在目前分散的网络监控系统基础上建立综合网络监控系统NMS(Network Management System)又称网络管理系统和网络管理服务端,其主要是针对网络设备进行监测、配置和故障诊断。主要功能有自动拓扑发现、远程配置、性能参数监测、故障诊断等。以实现全网的综合管理,包括:集中监控、分析、优化,及时掌握全网运行情况并进行有效控制,从而提高运营商信息化管理水平,最终提高移动通信的服务质量和运营效益。支持SNMP协议,简单网络管理协议(Simple Network Management Protocol):简单网络管理协议(SNMP),由一组网络管理的标准组成,包含一个应用层协议(application layer protocol)、数据库模型(database schema),和一组资料物件。该协议能够支持网络管理服务端,用以监测连接到网络上的设备是否有任何引起管理上关注的情况。SNMP为管理员提供了一个网管平台(NMS),负责网管命令发出,数据存储及数据分析等。被监管的设备上则运行一个SNMP代理(Agent),又称为代理器,代理实现设备与管理站(NMS)的SNMP通信。
在IP三网融合网络监控系统,一般采用分层管理的方式,对设备进行管理,一般分为三层:网络管理系统(Network Management System,简称NMS),网元管理系统(Element Management System,简称EMS)和网元(Network Element,简称NE)。
因此,有人提出所有的网络设备提供统一的接口、协议和数据规范,从而建立代理端Agent到管理端Manager的综合网络监控系统。但这种方案需要涉及到现有在运行网络设备的改动和升级,实施难度大,成本高。
发明内容
现结合附图和具体实施方式对本发明进一步说明。解决上述技术问题,本发明提供了一个架构于公共对象请求代理体系结构的网络监控系统平台,可实现全网可管可控的综合网络监控。
为了达到上述目的,本发明所采用的技术方案是,一种基于IP三网融合网络监控系统,采用三层结构,分别为网络管理系统(NMS),网元管理系统(EMS)和网元(NE),所述NE和EMS之间采用SNMP接口连接,所述NE通过私有接口连接各客户端 ,所述NMS和EMS之间和设有故障监控模块、配置监控模块、性能监控模块和安全监控模块,所述故障监控模块、配置监控模块、性能监控模块和安全监控模块均架设于公共对象请求代理体系结构(CORBA),所述公共对象请求代理体系结构,包括对象请求代理单元(ORB)、客户存根(stub)、实现骨架(skeleton),对象适配器、接口池、实现池和调用方法,
所述对象请求代理单元(ORB)用于根据客户端的输入的请求进行准确地对象定位,并激活远程对象实现,进而建立客户端与远程对象实现的连接,
所述客户存根(stub)用于向客户端提供一个因接口而异的API,
所述实现骨架(skeleton)用于提供将对象适配器转发的请求调度到远程对象实现上的适当操作代码,
所述对象适配器用于实现对象实现访问公共对象请求代理体系结构(ORB)所提供的服务,
所述接口池是储存、发布、监控相关对象接口定义的集合;
所述实现池包含了允许ORB激活和定位对象实现的信息的集合;
所述调用方法包括静态方法和动态方法,用于客户端与远程对象发送和接受请求的方法主要有两种:静态方法和动态方法。
进一步的,所述静态方法为:由IDL编译程序生成客户端的客户存根代码和服务端的实现骨架代码,并分别链接到客户端程序和服务端对象实现中;所述动态方法为:客户端动态激活接口向对象实现发出请求,服务端的对象适配器使用动态骨架接口访问对象,两者之间的接口信息从ORB接口池中动态获取。
进一步的,故障监控模块对EMS进行监测,将所监测到的信息发送至NMS,并根据NMS的反馈信息进行故障定位,并存储故障信息发送至EMS。
进一步的,所述配置控制模块将NMS发送的配置信息发送给EMS,并由EMS发送至NE,对每个NE进行配置,同时对EMS的系统参数进行收集和保存。
进一步的,所述性能监控模块收集EMS的流量、拥塞率等进行采集和统计、并进行分析后,将分析诊断结果发送至NMS。
进一步的,所述安全监控模块用于对EMS的用户进行权限等级划分和监控。
本发明通过采用上述技术方案,与现有技术相比,具有如下优点:
本发明提出了一种让各三网融合的设备厂商能实现全网综合网络监控的解决方案,并开发了一个架构于公共对象请求代理体系结构的网络监控系统平台,能实现可扩展性和异构网络的监控,适用于基于三网融合的大规模异构复杂网络的监控,包括集中监控、分析、优化,及时掌握全网运行情况并进行有效控制,提高了三网融合网络的服务质量和营业效益。
本发明的公共对象请求代理体系结构是提供给其他厂家或运营商进行接入和监控的接口,即向上提供的接口。它是驻留在底层网管上的一个进程,负责处理来自上层网管的请求报文,发送Trap信息,同时能提供故障、拓扑、资源等多类接口,完成故障查询,资源查询等多类网管功能。
附图说明
图1是本发明的实施例的结构示意图;
图2是本发明的实施例的公共对象请求代理体系结构主要组成部分的框图:
图3是本发明的实施例的ORB模型图;
图4是本发明的实施例的对象适配实现图;
图5是本发明的实施例的Client/Server模式实现流程图。
具体实施方式
现结合附图和具体实施方式对本发明进一步说明。
作为一个具体的实施例,如图1所示,本发明的一种基于IP三网融合网络监控系统,采用三层结构,分别为网络管理系统(NMS),网元管理系统(EMS)和网元(NE),所述NE和EMS之间采用SNMP接口连接,所述NE通过私有接口连接各客户端 ,所述NMS和EMS之间和设有故障监控模块、配置监控模块、性能监控模块和安全监控模块,所述故障监控模块、配置监控模块、性能监控模块和安全监控模块均架设于公共对象请求代理体系结构(CORBA),本实施例的公共对象请求代理体系结构,包括对象请求代理单元ORB、客户存根(stub)、实现骨架(skeleton),对象适配器、接口池、实现池和调用方法。进一步的,故障监控模块对EMS进行监测,将所监测到的信息发送至NMS,并根据NMS的反馈信息进行故障定位,并存储故障信息发送至EMS。所述配置控制模块将NMS发送的配置信息发送给EMS,并由EMS发送至NE,对每个NE进行配置,同时对EMS的系统参数进行收集和保存。所述性能监控模块收集EMS的流量、拥塞率等进行采集和统计、并进行分析后,将分析诊断结果发送至NMS。所述安全监控模块用于对EMS的用户进行权限等级划分和监控。
在分布式计算机领域中,存在几种体系结构,其允许及其彼此通信,或者共享分布式或网络中心应用程序。这些体系结构中的一个包括公共对象请求代理体系结构(CORBA)。CORBA是由对象管理组(OMG)开发的体系结构设计规范,而OMG是致力于开发在面向对象的计算机中使用的标准的独立组。遵从CORBA的系统的例子包括网景公司的ONE产品、和BEA系统的网络逻辑企业服务端。
CORBA提供了接口定义语言(IDL)规范,IDL允许软件开发者以标准模式为其面向对象应用程序定义接口。IDL包括允许IDL定义的映射和要映射到包括C、C++、以及Java的各种程序设计语言的类型。因此,CORBA允许开发者创建“透明的”应用程序,可以独立于原始程序设计语言而将其解释。开发者和第三方供应商通过对象请求代理(ORB),创建彼此相互作用的对象、使用语言映射,开发者可以创建ORB理解的客户端 “占位程序(stub)”和服务端 “框架”,
自从CORBA 2.0,CORBA规范包括了一种允许多个ORB彼此无缝通信的方法。ORB互操作性体系结构,或者更具体的说,通过对象请求代理间协议(GIOP)标准,定义了一组ORB可以在网络上发出来的消息请求。存在各种风格的GIOP,每一个适用于特定网络传输的需要。如OMG定义的GIOP包括三个组件:
公用数据表示:将IDL类型映射到网络代理之间使用的低级类型的传送语法。
GIOP消息格式:当前有七种,包括客户端请求、服务端应答、客户端取消请求、客户端定位请求、服务端定位应答、服务端关闭连接、以及消息错误。
GIOP消息传输假定:包括:传输是面相连接的,可靠的,可以视为字节流,提供无序连接损失的合理通知,并且初始化连接的传输模型可以映射到TCP/IP的通用连接模型。
所有ORB必须都能够通过规范使用的公共GIOP实现是因特网对象请求代理间协议(IIOP)。IIOP将GIOP消息映射到TCP/IP,这允许ORB使用例如因特网的TCP/IP网络作为通信总线或干线。参考图1的金字塔结构,金字塔的最底层是物理器件,例如具有MAC(介质访问控制)地址的以太网卡。其上是以太网协议,其提供基于连接的广播拓扑,在其中对消息编码,并解决冲突。下一层是网际协议(IP),其指定穿越因特网的数据包的格式,并支持主机名和IP地址。主机名允许对IP作路由选择。在IP之上是传输控制协议(TCP),其加入端口号和注入数据包分段和存活时间的控制指令的功能。这提供了可靠的、基于流的传递。IIOP建于TCP之上。在IIOP之上是ORB层,其整理IIOP请求。在金字塔的顶端是应用程序本身,其包括对象实现和其他ORB对象及诸如命名服务的服务。
在如上述的分布式对象系统中,在请求对象功能的处理和实现对象功能的处理之间来回传送请求。展示n个客户端调用M个服务端。当有n*m个连接时,很难用这样的系统取得可缩放性,其中n代表请求一组对象功能的处理数,而m代表实现这组对象功能的处理数。这是一般已知的“扇出(fan-out)问题”,其导致难于确保系统资源足够充分,以允许可缩放性。有一些技术允许请求经集中器处理集中到IIOP/ORB域或对象实现的组。问题是以相反方向、从域内对象实现到域外其他对象实现进行时,如何可以取得可缩放性。
对象请求代理单元ORB:对象请求代理ORB为核心部分,它提供对象定位、对象激活和对象通讯的透明机制。通过 ORB,一个客户端可以很简单地使用服务端对象的方法而不论服务端是在同一机器上还是通过一个网络访问。ORB 截获调用然后负责找到一个对象实现这个请求,传递参数和方法,最后返回结果。客户端不用知道对象在哪里,是什么语言实现的,它的操作系统以及其它和对象接口无关的东西。ORB给分布式对象提供了透明地发送请求和接受响应的机制,主要包括以下职责:
l 负责根据客户端给出的对象引用定位相应的远程对象实现,激活远程对象实现,建立与远程对象实现的连接;
2 客户端ORB用户请求的参数,将参数打包,通过ORB互联协议跨网络送给服务端的ORB;
3 服务器端的ORB接受通过ORB互联协议跨网络传送过来的参数,并将这些参数解包,发送给对象实现;
4 负责将对象实现响应客户端请求后的输出参数、返回值等,以同样的打包/解包方式,传回给客户端。
参考图2所示,具体来说就是:当客户端程序要调用远程对象上的方法时,首先要得到这个远程对象的引用,之后就可以像调用本地方法一样调用远程对象的方法。当发出一个调用时,实际上ORB会截取这个调用,因为客户端和服务端可能在不同的网络、不同的操作系统上甚至用不同的语言实现,ORB还要负责将调用的名字、参数等编码成标准的方式(称序列化)通过网络传输到服务端(实际上在同一台机器上也如此),并通过将参数反序列化的过程,传到正确的对象上(这整个过程叫重定向),服务端对象完成处理后,ORB通过同样的序列化/反序列化方式将结果返回给客户端。
客户存根(stub):客户存根(stub)是由IDL编译程序根据IDL文件(Interface Description Language,接口定义语言)生成的,与编程语言相关的客户端代码段,客户存根向客户端提供一个因接口而异的API,从而透明对象实现的位置和ORB操作。
实现骨架(skeleton):实现骨架(skeleton)是由IDL编译程序根据IDL文件生成的,与编程语言相关的服务端代码框架,实现骨架提供将对象适配器转发的请求调度到对象实现上的适当操作代码。
IDL:全称Interface Description Language ,它是使用编程语言编写的API提供基于标准的和公共对象请求代理体系结构的交互性和连接性,用于描述接口。
对象适配器:对象适配器是对象实现访问ORB所提供服务的主要方式,它分为:基本对象适配器BOA和可移植对象适配器POA。
参考图3所示,基本对象适配器BOA着重公共对象请求代理体系结构服务端的实现,而不是公共对象请求代理体系结构对象的实现;
可移植对象适配器POA规约定义公共对象请求代理体系结构对象为具有标识、接口和实现的抽象实体,负责把公共对象请求代理体系结构对象概念配为编程语言的服务体概念,允许编程人员构造可移植的对象实现;
由于对象的单一接口,通过对象适配器,ORB可以定制接口,为一组特定的对象实现提供服务。ORB通过对象适配器提供的服务通常包括:
1 、 生成和解释对象引用;
2 、 方法调用;
3 、 交互安全性;
4 、 对象和实现激活及冻结;
5 、 将对象引用映射到实现;
6、 注册实现;
接口池是储存、发布、监控相关对象接口定义的集合,通常以IDL文件作为输入,将接口描述信息经过处理后存放在文件、数据库、或者其它形式的存储机制中,并提供一组标准的调用接口供运行时动态查询;
实现池包含了允许ORB激活和定位对象实现的信息,一般来说,对象实现的安装和与对象实现的激活及执行有关的策略控制都是通过实现仓库上的操作完成的。
调用方法:客户端与远程对象发送和接受请求的方法主要有两种:静态方法和动态方法,对于一般的应用,静态方法更为普遍;
静态方法要求在编译时已知所有的IDL接口,由IDL编译程序生成客户端的客户存根代码和服务器的实现骨架代码,并分别链接到客户端程序和服务端对象实现中;
动态方法在编译时客户端和服务端程序都不知道IDL接口。运行时,客户端动态激活接口向对象实现发出请求,服务端的对象适配器使用动态骨架接口访问对象,两者之间的接口信息从ORB接口池中动态获取。
参考图4所示,在传统的基于Client/Server模式的应用程序开发过程中,项目开发人员遵循公开的标准或自由设计模块间的协议,这样的协议依赖于网络类型、实现语言、应用方式等。引入ORB后,客户端只要遵循服务端对象的对外接口标准服务对象提出业务请求,由ORB在分布时在对象间建立客户端-服务端对象关系。
① 在客户端发出方法调用消息,利用客户存根Stub进行封装后发到客户端 ORB;
② 客户端ORB通过互联网内部对象请求代理协议IIOP把请求发送到服务端ORB;
③ 服务端ORB转到服务端上的服务对象,由服务对象的实现骨架Skeleton对消息进行解析,还原成正确的方法调用;
④ 服务端执行后的结果由实现骨架Skeleton 进行封装后发到服务端ORB;
⑤ 服务端ORB通过互联网内部对象请求代理协议IIOP把结果发送回客户端ORB;
⑥ 客户端ORB把结果转给客户存根Stub,客户存根Stub解析后再传回客户端。
参考图5所示,公共对象请求代理体系结构系统中的对象完全通过接口来访问,在公共对象请求代理体系结构中,接口用标准格式的IDL来定义,IDL独立于具体的编程语言,下图说明了IDL如何将Server对象和Client结合在一起:IDL 定义好接口后,由IDL编译器分别生成Stub/Skeleton代码(IDLtoCPlus 编译器生成C++代码,IDLtoJava编译器生成JAVA代码,本文中采用JAVA)Stub 代码跟 Client源代码链接在一起产生Client 可执行代码。Skeleton代码跟Server源代码链接在一起产生Server 可执行代码。
因此,公共对象请求代理体系结构的开发流程如下:
1) 定义接口:应用程序对象建模并用IDL来定义公共接口;
2) 产生进入代码:用代码生成工具为应用程序(包括Client和 Server)生成进入点,然后编辑产生的代码加入业务逻辑代码;
3) 编译IDL:用IDL编译器生成Client和Server的JAVA源文件;
4) 开发Server端:Server是一个公共对象请求代理体系结构对象的容器,每个对象都提供IDL接口,在这些对象的实现中添加业务逻辑代码;
5) 开发Client端,Client获取Server提供的对象的引用,并以此来调用Server上的方法;
6) 编译并运行应用程序。
使用IDL定义接口
定义接口是公共对象请求代理体系结构程序设计的一个很重要的部分,因此我们本节专门进行介绍。定义接口实现了接口对象建模到IDL描述,有了IDL后将其映射成实际的代码(如:C++、JAVA等)最终得以实现接口提供的方法及如何调用这些方法。
接口的定义包括定义操作(Operations)和属性(Attributes)。操作是指对象提供的供Client调用的方法,属性则是单个的数据值。这跟面向对象程序设计中的公有方法的属性几乎一致。
IDL定义接口:
1) 简单数据
因为IDL的主要目的是实现在不同的语言、机器和操作系统间的可移植性,它是强类型的,这里是最基本(标准)的公共对象请求代理体系结构类型:
IDL Type | Java Type | Exceptions |
boolean | Boolean | |
char | Char | CORBA::DATA_CONVERSION |
wchar | Char | CORBA::DATA_CONVERSION |
octet | Byte | |
string | java.lang.string | CORBA::MARSHAL, CORBA::DATA_CONVERSION |
wstring | java.lang.string | CORBA::MARSHAL, CORBA::DATA_CONVERSION |
short | Short | |
unsigned short | Short | large number mismatch a€“ test |
long | Int | |
unsigned long | Int | large number mismatch a€“ test |
long long | Long | |
unsigned long long | Long | large number mismatch a€“ test |
float | Float | |
double | Double | |
long double | **unmapped | It is unclear at this time if this type will be added as a new primitive type or an addition to a library, for examplejava.math.BigFloat |
2) typdef
使用typedef关键字就可以定义自己的类型:
typedef unsigned long SubscriptionIdType ;
typedef string SystemDNType;
3) 结构体/枚举
enum ScopeType{
BASE_ONLY,BASE_NTH_LEVEL,BASE_SUBTREE,BASE_ALL
};
Struct JobFilesInfoType{
string ftpIP;
snsigned int ftpPort;
string ftpUser;
string filePath;
};
4) 数组/序列
序列是一个变长的数组:
JobFileInfoType jobFilesInfo[20];
typedef sequence<string>NotificationCategorySetType;
NotificationCategorySetType notificationCategorySet:
5) 方法
下面例子定义了一个名为getIRPOutline的方法,它的两个参数分别是输入参数string IRPVersion ,输出参数SupportedIRPListType supportedIRPList ,且定义了可能抛出InvalidFilter异常。
module EnterPointIRPSystem{
enum ResultType{SUCCESS,FAILURE};
typedef sequence<string>SupportedIRPListType;
interface EnterPointIRP{
ResultType getIRPOutline(int string IRPVersion , out SupportedIRPListType
supportedIRPList) raises(InvalidFilter);
};
};
这些声明非常JAVA代码:参数由in,out,inout三种类型之一来修饰。它们的语义如下:in参数是客户向对象发送的数据,out参数是对象向客户发送的数据,inout参数先从客户发送到对象,再被返回给客户。
6) 异常定义
IDL也可以定义异常(exception)同样类似于JAVA的异常类。
exception InvalidFilter{
string reason;
};
如下定义的方法能抛出这个异常。
ResultType getIRPOutline(int string IRPVersion, out SupportedIRPListType
supportedIRPList raises(InvalidFilter);
2、服务端具体实现
服务端实现主要思路如下:
a) 提供IDL中NorthBoundInterface接口中定义方法的具体实现;
b) 将提供服务的OSS对象绑定至命名服务器,供远端访问;
a、提供IDL中NorthBoundInterface接口中定义方法的具体实现;
具体操作及注意点:
① 修改以前服务端代码中的各种ManagedResource(以GFDevice为例);
实现流程 :
修改类定义,使其实现com.gview.corba._GFDevice_CIOperations接口。由于接口中的方法早期已全部实现,所以其它代码无须修改;
② 修改服务端OSS类中的getManagedObject方法
实现流程 :
根据对象具体的类型返回具体类型的对象,而不只是单纯的ManagedObject;
ManagedObject mo = topoAPI.getByName(mo_Tree.getName());
String moType = mo.getType();
ManagedObject_CI moTemp = new _ManagedObject_CITie(mo);
if (moType.equalsIgnoreCase("GFDevice"))
{
GFDevice temp = (GFDevice) mo;
moTemp = new _GFDevice_CITie(temp);
}
return moTemp;
③ 修改服务端OSS类中的setManagedObject方法
实现流程 :
根据对象具体的类型获取相应的可设置的属性并统一组成一个包对设备进行设置,若成功则同时更新数据库;
b、将提供服务的OSS对象绑定至命名服务器,供远端访问
主要实现在callMain方法中,如下:
String argv[] = { args[2], args[3], args[4], args[5] };
// create and initialize the ORB
ORB orb = ORB.init(argv, null);
// create servant and register it with the ORB
OSS api = new OSS();
orb.connect(api);
// get the root naming context -- Modify the code to get this from the
// Corba_parameters.conf
org.omg.CORBA.Object objRef = orb.resolve_initial_references(args[0]);
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// bind the Object Reference in Naming
NameComponent nc = new NameComponent(args[1], "");
NameComponent path[] = { nc };
ncRef.rebind(path, api);
3、客户端具体实现
客户端实现的主要思路如下:
a) 获取远程调用对象的引用;
b) 在获得对象引用后,通过调用IDL接口中定义的方法获得并显示相关数据。
a、获取远程调用对象的引用;
主要实现在connect方法中,如下:
① 初始化ORB,并获得命名服务的引用;
String args[] = { "-ORBInitialHost", host, "-ORBInitialPort",portNum };
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// get the root naming context -- Modify the code to get this from the
// Corba_parameters.conf
// org.omg.CORBA.Object objRef = orb.resolve_initial_references(argv[0]);
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
② 通过命名服务,获得远端对象的引用;
// resolve the Object Reference in Naming
NameComponent nc = new NameComponent("WebNMS", "");
NameComponent path[] = { nc };
NorthBoundInterface webNMSRef = NorthBoundInterfaceHelper.narrow(ncRef.resolve(path));
③ 获取通用API的远程对象引用,如EventAPI,AlertAPI等;
NameComponent nc1 = new NameComponent("com", "com");
NameComponent nc2 = new NameComponent("adventnet", "adventnet");
NameComponent nc3 = new NameComponent("nms", "nms");
NameComponent[] nmsNC = { nc1, nc2, nc3 };
NamingContext nmsContext = NamingContextHelper.narrow(ncRef.resolve(nmsNC));
NameComponent nc4 = new NameComponent("TopoAPI", "");
NameComponent[] name = { nc4 };
// resolve the Object Reference using NamingService
org.omg.CORBA.Object objectRef = nmsContext.resolve(name);
// Obtain the TopoAPI_CI ref from it
topoAPI = TopoAPI_CIHelper.narrow(objectRef);
nc4 = new NameComponent("EventAPI", "");
name[0] = nc4;
eventAPI = EventAPI_CIHelper.narrow(nmsContext.resolve(name));
nc4 = new NameComponent("AlertAPI", "");
name[0] = nc4;
alertAPI = AlertAPI_CIHelper.narrow(nmsContext.resolve(name));
b、在获得对象引用后,通过调用IDL接口中定义的方法获得并显示相关数据
实现流程 :
主要是在远端对象引用的基础上,通过调用IDL接口中定义的方法,将所要完成的任务转交给远端对象,并等待结果;
以设备监控界面为例,进行举例说明。
① 获得远端对象TopoAPI的引用,然后调用方法getCompleteList_CT()得到所有被管对象名(在系统中,与设备有关的信息均以被管对象的形式存在,即ManagedObject);
OSS_Server ossObj = OSS_Server.getInstance();
if(ossObj == null)
{
return;
}
TopoAPI_CI topo_api = ossObj.getTopoAPI();
String[] moArr = topo_api.getCompleteList_CT();
② 创建ManagedObject对象—device_mo,并将相应的被管对象名赋值给该对象;然后利用device_mo创建ManagedObject_CI对象—mo;接下来,通过oss对象,将mo对象作为参数传递给远程对象引用并等待结果的返回;
OSSImpl oss = OSS_Server.oss;
ManagedObject device_mo = new ManagedObject();
device_mo.setName(moName);
ManagedObject_CI mo = new _ManagedObject_CITie(device_mo);
ManagedObject_CI mo_CI = oss.getManagedObject(mo);
③ 上一步获得的mo_CI对象包含了相应对象在服务端数据库中所有的信息,因此可以直接使用公开接口中定义的方法访问其相关属性。下面的代码是通过调用mo_CI对象的getProperties_CT方法,获得设备的线路名称属性。
Property_CT[] props = mo_CI.getProperties_CT();
NVProperties NVP = new NVProperties(props);
//System.out.println(NVP);
String slotName = NVP.getProperty("cmmcSlotName");
尽管结合优选实施方案具体展示和介绍了本发明,但所属领域的技术人员应该明白,在不脱离所附权利要求书所限定的本发明的精神和范围内,在形式上和细节上可以对本发明做出各种变化,均为本发明的保护范围。
Claims (6)
1.一种基于公共对象请求代理体系结构的网络监控系统,其特征在于:采用三层结构,分别为网络管理系统(NMS),网元管理系统(EMS)和网元(NE),所述NE和EMS之间采用SNMP接口连接,所述NE通过私有接口连接各客户端 ,所述NMS和EMS之间和设有故障监控模块、配置监控模块、性能监控模块和安全监控模块,所述故障监控模块、配置监控模块、性能监控模块和安全监控模块均架设于公共对象请求代理体系结构(CORBA),所述公共对象请求代理体系结构,包括对象请求代理单元(ORB)、客户存根(stub)、实现骨架(skeleton),对象适配器、接口池、实现池和调用方法。
2.根据权利要求1所述的一种基于公共对象请求代理体系结构的网络监控系统,其特征在于:所述对象请求代理单元(ORB)用于根据客户端的输入的请求进行准确地对象定位,并激活远程对象实现,进而建立客户端与远程对象实现的连接,
所述客户存根(stub)用于向客户端提供一个因接口而异的API,
所述实现骨架(skeleton)用于提供将对象适配器转发的请求调度到远程对象实现上的适当操作代码,
所述对象适配器用于实现对象实现访问公共对象请求代理体系结构(ORB)所提供的服务,
所述接口池是储存、发布、监控相关对象接口定义的集合;
所述实现池包含了允许ORB激活和定位对象实现的信息的集合;
所述调用方法包括静态方法和动态方法,用于客户端与远程对象发送和接受请求的方法主要有两种:静态方法和动态方法。
3.根据权利要求1所述的一种基于公共对象请求代理体系结构的网络监控系统,其特征在于:故障监控模块对EMS进行监测,将所监测到的信息发送至NMS,并根据NMS的反馈信息进行故障定位,并存储故障信息发送至EMS。
4.根据权利要求1所述的一种基于公共对象请求代理体系结构的网络监控系统,其特征在于:所述配置控制模块将NMS发送的配置信息发送给EMS,并由EMS发送至NE,对每个NE进行配置,同时对EMS的系统参数进行收集和保存。
5.根据权利要求1所述的一种基于公共对象请求代理体系结构的网络监控系统,其特征在于:所述性能监控模块收集EMS的流量、拥塞率等进行采集和统计、并进行分析后,将分析诊断结果发送至NMS。
6.根据权利要求1所述的一种基于公共对象请求代理体系结构的网络监控系统,其特征在于:所述安全监控模块用于对EMS的用户进行权限等级划分和监控。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310569865.5A CN103684904A (zh) | 2013-11-13 | 2013-11-13 | 基于ip三网融合网络监控系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310569865.5A CN103684904A (zh) | 2013-11-13 | 2013-11-13 | 基于ip三网融合网络监控系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN103684904A true CN103684904A (zh) | 2014-03-26 |
Family
ID=50321283
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310569865.5A Pending CN103684904A (zh) | 2013-11-13 | 2013-11-13 | 基于ip三网融合网络监控系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103684904A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105162858A (zh) * | 2015-08-20 | 2015-12-16 | 中国人民解放军国防科学技术大学 | 针对corba中间件的通用传输协议框架、通信系统及方法 |
CN107948001A (zh) * | 2017-12-26 | 2018-04-20 | 北京中船信息科技有限公司 | 一种船舶制造车间工业网络智能监控系统及方法 |
CN109643252A (zh) * | 2016-08-17 | 2019-04-16 | 谷歌有限责任公司 | 中间件接口和中间件接口生成器 |
WO2023279831A1 (zh) * | 2021-07-07 | 2023-01-12 | 中兴通讯股份有限公司 | 网管代理以及网元管理平台 |
-
2013
- 2013-11-13 CN CN201310569865.5A patent/CN103684904A/zh active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105162858A (zh) * | 2015-08-20 | 2015-12-16 | 中国人民解放军国防科学技术大学 | 针对corba中间件的通用传输协议框架、通信系统及方法 |
CN105162858B (zh) * | 2015-08-20 | 2018-11-27 | 中国人民解放军国防科学技术大学 | 针对corba中间件的通用传输协议框架、通信系统及方法 |
CN109643252A (zh) * | 2016-08-17 | 2019-04-16 | 谷歌有限责任公司 | 中间件接口和中间件接口生成器 |
CN109643252B (zh) * | 2016-08-17 | 2024-04-16 | 谷歌有限责任公司 | 中间件接口和中间件接口生成器 |
CN107948001A (zh) * | 2017-12-26 | 2018-04-20 | 北京中船信息科技有限公司 | 一种船舶制造车间工业网络智能监控系统及方法 |
WO2023279831A1 (zh) * | 2021-07-07 | 2023-01-12 | 中兴通讯股份有限公司 | 网管代理以及网元管理平台 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Crnkovic et al. | Challenges of component-based development | |
JP3179513B2 (ja) | 異種ネットワーク環境における適用業務プログラムの統合システム | |
CN102053860B (zh) | 基于CORBA的OSGi分布式扩展系统及方法 | |
EP0726003B1 (en) | Object-oriented network protocol configuration system | |
JP3519920B2 (ja) | オブジェクトのネーミングを管理するための方法、オブジェクトの物理corbaアドレス上でオブジェクトの論理アドレスを表示するための方法およびコンピュータシステム | |
CN101420437B (zh) | 一种原型系统与hla仿真系统的接口设备 | |
CN109542457A (zh) | 一种边缘计算网络的分布式应用分发部署的系统及方法 | |
CN102854853A (zh) | 一种跨平台轻量级的分布式控制系统 | |
Dobaj et al. | A microservice architecture for the industrial Internet-of-Things | |
CN104579792A (zh) | 多适配方式实现多种类型虚拟资源集中管理架构及方法 | |
US20060004856A1 (en) | Data management and persistence frameworks for network management application development | |
CN105721562A (zh) | 一种基于代理的异构服务调用方法与协同调用系统 | |
Theiss et al. | Software agents in industry: A customized framework in theory and praxis | |
Pavlou et al. | The OSIMIS platform: Making OSI management simple | |
CN105760498A (zh) | 一种xml数据与关系型数据库匹配的实现方法 | |
CN103684904A (zh) | 基于ip三网融合网络监控系统 | |
CN115150454A (zh) | 一种跨操作系统的中心化发布订阅通信中间件 | |
Leppinen et al. | Java-and CORBA-based network management | |
US7127721B2 (en) | Core object model for network management configuration applications in telecommunication systems | |
CN100544369C (zh) | 一种基于消息的分布式系统以及在其中通信的方法 | |
CN115328679A (zh) | 异构函数库的自动化集成方法、计算设备及其系统 | |
Wein et al. | Flexible and lightweight framework for active industrial asset administration shells | |
CN104615815A (zh) | 一种并行模型的消息传输方法及系统 | |
KR101757259B1 (ko) | Cim 기반 실시간 데이터 교환을 위한 통합관리 시스템 | |
Quinot et al. | From functional to architectural analysis of a middleware supporting interoperability across heterogeneous distribution models |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20140326 |