CN101179414A

CN101179414A - 一种在上级网管中集成下级网管功能的方法

Info

Publication number: CN101179414A
Application number: CNA200610063558XA
Authority: CN
Inventors: 郑平; 邓朝明; 张强
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2006-11-09
Filing date: 2006-11-09
Publication date: 2008-05-14
Anticipated expiration: 2026-11-09
Also published as: CN100571156C

Abstract

一种在上级网管中集成下级网管功能的方法，把下级网管客户端上的功能模块做成一个个独立的插件部署到上级网管客户端上；使所述插件包含在一个个独立的空间中，每个独立的空间都采用一个独立的类加载器把该空间中的各个插件加载到Java进程中；打开配置插件的功能管理界面；对插件的功能管理界面进行管理操作；对发送命令调用请求加工后通过上级网管服务器转发到下级网管服务器上。本发明可以在上级网管上支持同时运行不同版本的下级网管功能件，在上级网管实现集中的操作维护，而且上级网管对下级网管功能的实现不需要增加开发工作量。

Description

一种在上级网管中集成下级网管功能的方法

技术领域

本发明涉及一种网络设备的管理方法，尤其涉及一种在上级网管中集成下级网管功能的方法。

背景技术

电信网络管理技术是复杂的分布式系统，Java技术特别是J2EE也已在电信网管中得到长足的应用。为了对全网设备进行管理，一般采用对网管进行分级管理的方法：下级网管(OMM)直接管理网元，完成对网元的单点管理；上级网管(EMS)实现对各个OMM的集中管理，见附图1，一个上级网管EMS管理了三个下级网管OMM，这样就能够在上级网管客户端能够集中的对下面三个网管的设备进行查看和监控。

随着电信业的发展，运营商要求提供对网络设备的综合管理能力变得越来越重要，EMS上的管理功能已经不再局限于只能对各个下级OMM进行集中的查看和监控了，而是要求在OMM网管上的各种操作管理功能如配置等都能够在EMS上具有，以达到在EMS上功能不缺失的目的。

因此，在原有上级EMS网管上集中查看和监控功能的基础上，如果能够直接在上级网管中集成下级OMM网管的功能，以便在上级EMS网管上可以直接操作、配置下级网管的管理设备，更能够满足越来越复杂的网络管理的需要。

传统的解决方法主要是以下两种：

1、在EMS上重新开发一套OMM上的功能，包括客户端功能和服务器功能都要重新开发。

2、不用新开发代码，只是把各个OMM的客户端完整版本都在EMS上存放一份，当需要对某个OMM进行操作配置时，就启动这个OMM对应的客户端版本进程，该进程自己连到这个OMM服务器，所有的操作功能都在这个进程的界面上完成。

这两种解决办法存在以下问题：

1、如果在EMS上新开发OMM上的功能，由于要适应不同种类的OMM，开发工作量巨大无比，而且随着OMM自身版本升级和功能增强，也需要EMS上新开发的代码也随着OMM编写和修改新的代码，导致EMS和OMM的版本耦合太紧。主要的问题就是开发周期长、维护成本大，远不能适应运营商要求的快速推出市场的目的。

2、如果在EMS客户端对每个要连接的OMM都启动一个独立的客户端进程的方法，每个独立的进程要进行登录、初始化等过程，启动速度慢，而且需要用户在不同进程的操作界面间切换，使得用户的感受大打折扣；而且各个客户端进程的操作界面是独立的，这有悖于EMS的根本目标是进行集中的操作维护和管理；还有，上下级网管系统之间的IP通路是受专门控制的，只能是上下级服务器之间有专门的通道，而在上级客户端机器往往无法直接同下级OMM网管服务器通讯，因此在工程部署上不可接受的。

在本发明中，上级网管(EMS)包括了上级网管客户端和上级网管服务器；下级网管(OMM)，包括下级网管客户端和下级网管服务器。用户一般是直接同上级或下级网管的客户端来对设备运行情况进行监控的。现在的趋势是，用户要求能够直接在上级网管客户端上就能够对下级网管所管理的设备进行监控，如省级网管(一般是集中EMS上级网管)上的用户可以直接对分布在各个地方的市级网管(即OMM网管)的设备进行管理和操作。

发明内容

本发明要解决的技术问题是，提出一种在上级网管中增加下级网管功能的方法，实现在上级网管客户端上集成各下级网管已经实现了的功能，使其能够在上级网管客户端的同一个Java进程中被部署和运行。

本发明包括以下步骤：

步骤一、把下级网管(OMM)客户端上的功能模块做成一个个独立的插件部署到上级网管(EMS)客户端上；

步骤二、使所述插件包含在一个个独立的空间中，每个独立的空间都采用一个独立的类加载器把该空间中的各个插件加载到Java进程中；

步骤三、打开配置插件的功能管理界面；

步骤四、对插件的功能管理界面进行管理操作；

步骤五、对发送命令调用请求加工后通过上级网管(EMS)服务器转发到下级网管(OMM)服务器上。

上述方案中，所述插件以压缩包的形式存在或以目录的形式存在。

所述步骤一中的插件放部署到上级网管(EMS)客户端的存放方式为：把做好的插件放到特定的目录下由系统自动发现这个插件；或把插件放置到任何地方，并且编写一个插件连接文件以描述这个插件的具体位置，由系统读取所述连接文件来发现这个插件。

所述步骤二中的独立空间包括主空间和域空间，每一个域空间中可以装载一个或多个插件，并对应于一个下级网管(OMM)，域空间之间是相互独立的。主空间就是用于管理域空间生命周期的，它为域空间的运行提供基础支持，包括加载域空间和卸载域空间。

所述类加载器把该空间中的各个插件加载到Java进程中的方法为，当需要加载一个类的字节码时，先在域空间中查询是否有该类的字节码，如果有就使用这个字节码；否则就使用主空间缺省的类加载器进行加载。

所述步骤三中的打开配置插件的功能管理界面是指加载域空间中所包含的各个插件，实现方法包括以下步骤：创建域空间类加载器的一个实例；读取域空间描述符文件来获取这个空间包含的所有插件；使用该域空间类加载器的实例加载这些插件中的类；扫描插件中的各种资源文件，当插件要读取资源文件时就把它赋给插件。

当不再使用域空间时把它停止掉，释放所占用的内存资源。

所述步骤四进行数据配置的管理操作，包括以下步骤：把下发的命令以及参数包装成字节流；把字节流传递到上级网管服务器；上级网管服务器收到后转发到下级网管服务器；在下级网管服务器上再把字节流还原成原始的数据或命令进行处理；下级网管服务器处理后对需要返回的数据，也加工成字节流的形式返回给上级网管服务器，最后再返回给上级网管(EMS)客户端进程中对应的域空间中，把结果的字节流数据还原后显示到域空间打开的界面上呈现给用户。

通过上述方案，可以达到如下有益效果：

1、上级EMS网管对下级OMM功能的零开发工作量。下级OMM网管上已经有的功能不需要在EMS上重新开发一套，这些已经有的功能只需做成独立的插件部署到EMS上即可，这可以最大程度地利用已有的开发成果，快速推出市场。

2、上级EMS网管版本和下级OMM网管版本的解耦。由于下级OMM的功能是通过插件集成到上级EMS中运行的，EMS对于OMM提供什么样的功能可以完全不必了解，去掉了EMS和OMM之间版本的依赖性。

3、上级EMS网管实现了集中的操作维护。由于各个OMM下级网管对应的插件是集成在EMS的同一个Java进程中运行的，启动速度快，避免了用户在不同的进程界面之间来回切换，实现了EMS必须达到的集中操作维护的目标，大大提升了用户界面操作的感受。

4、上级EMS上支持同时运行不同版本的OMM功能。这些不同版本的OMM功能，它们的类名、包名都是相同的，显然采用传统的类加载方式是不可能做到在同一个进程中被同时装载的；但是在本发明中，这些OMM功能模块分别由不同的插件承载，每个插件都由一个独立的类加载器进行装载，这使得它们在被加载后处于独立的空间中，彼此之间没有任何关联影响，因此做到了在同一个JVM(JavaVirtual Machine，即Java虚拟器)进程中被装载的过程。

附图说明：

图1是上级EMS管理下级OMM示意图；

图2是本发明中的域空间中的命令转向处理流程图。

具体实施方式：

本发明的基本设计思想是把OMM客户端上的功能模块作成一个个独立的插件部署到EMS客户端上，把这些插件包含在一个个独立的空间中，每个独立的空间都采用一个独立的类加载器把该空间中的各个插件加载到Java进程中运行；这些插件在运行时发送命令调用请求进行拦截，经过加工后通过EMS服务器转发到下级OMM服务器上。

本发明中的“插件”是指完成一个或多个网管功能的物理实现，按照模块划分的原则组织在一起的集合。该物理实现包括：该功能代码编译出来的.class文件，一般以jar包的形式存在的；该功能所用到的各种数据资源，例如XML文件资源、属性文件资源、图片文件资源、声音文件资源等。插件是自描述的，即该插件本身带了描述该插件自身信息的资源，例如XML描述符来描述自己包括那些Java的jar包、有哪些资源等，描述的信息包括名称、版本信息、插件提供者等。插件能够被动态的加载并激活。插件可以以压缩包的形式存在，也可以以目录的形式存在。

本发明中的“域空间”、“主空间”：由于EMS客户端上可能会同时管理多个下级OMM网管相关的功能界面，这些功能之间必须是相互独立的，不能有相互影响。因此，必须让这些功能运行在各自独立的环境中，这个环境就称为“域空间”。域空间是插件装载和运行的容器，一个域空间可以装载一个或多个插件，并对应于一个下级OMM网管。域空间有生命周期的过程：当加载了域空间后，就可以使用该域空间中各个插件的功能了；当卸载了域空间后，也就停用了该域空间中各个插件的功能。“主空间”就是用于管理域空间生命周期的，它为域空间的运行提供基础支持。主空间和域空间都运行在同一个Java进程中。

下面对本发明进一步介绍：

请参阅图2所示：

第一步生成插件

把OMM上的配置功能相关的所有物理实现，包括代码编译后的jar、图片资源和配置文件等组合到一个目录下，再把这个目录压缩成一个以.par为后缀的文件中，这个压缩的文件就是一个插件。根据下级OMM客户端需要集成到上级EMS客户端的各个功能生成多个独立的插件。其中，一个插件完成一个功能。

插件的存在形式可为压缩文件，也可为目录。在该实施方式中，插件主要以目录的形式存在的，这样可以避免在加载插件时解压缩花费的时间，提高启动速度。插件通常以规范的方式命名，在该实施方式中该插件必须以.par为后缀的方式命名，该插件以配置功能的插件为例，命名成zte-cdyjs-cm.par。

第二步：部署插件

把做好的插件放到EMS客户端所在的机器。存放有两种方式，一是把做好的插件放到特定的目录下，系统将会自动发现这个插件；另一种是把插件放置到任何地方，并且编写一个插件连接文件以描述这个插件的具体位置，系统将会读取这个文件来发现这个插件。在本实施方式中，将该配置功能插件存放在EMS客户端固定的目录c:/zte/ums-clnt下。

第三步：空间化插件。

每个要管理的下级OMM网管都使用一个独立的域空间，把这个下级OMM网管功能的插件包含到这个域空间中，每个域空间使用一个描述符文件来描述要包含的插件。在具体实施中，可以命名一个域空间叫“zxom01-ss”，并采用文本编辑器或XML工具编写一个域空间描述符文件，使上面的配置功能插件包含在这个域空间中。

空间化的关键是在每个域空间中使用一个独立的类加载器，称为域空间类加载器，专门加载域空间中各个Java类的字节码。类加载的关键实现方法是：当需要加载一个类的字节码时，先在域空间中查询是否有该类的字节码，如果有就使用这个字节码；否则就使用主空间缺省的类加载器进行加载。

在本例中，域空间中只有这个配置功能插件，这个类加载器就负责加载这个插件中所有类的字节码。而其它一些公共功能的类已经在主空间中存在，而且在插件中不存在它的字节码，因此这些类是被共享使用的。

第四步：启动域空间

在本实施方式中启动域空间的结果就是打开配置管理插件的网管功能界面，其实现步骤是：

1、创建域空间类加载器的一个实例；

2、读取域空间描述符文件来获取这个域空间包含的配置功能插件；

3、使用这个域空间类加载器的实例加载配置功能插件中的类；

4、扫描配置功能插件中的各种资源文件，并保存到一个结果列表中；

5、配置功能插件在被加载过程中要读取图片资源文件，就从扫描结果列表中获取。

如果用户关闭该配置管理界面，则该域空间被停止，此时该域空间释放占用的内存资源。

上述第三步和第四步之间的关系是，第三步骤完成域空间类加载器的创建；第四步执行加载过程。

第五步：命令转向处理

下级OMM的配置管理的功能界面被打开后，即在进行数据配置的界面操作，为了把数据配置的命令以及参数下发到下级OMM服务器上，需要对命令调用过程进行如下命令转向处理，流程如图2所示：

1、域空间下发数据配置的命令以及参数；

2、EMS客户端将该数据配置命令以及参数转换成字节流，转换的方式根据命令和参数的类型，一般采用Java序列化的方式。

3、将该字节流传递给EMS服务器；

4、EMS服务器收到该字节流后再原样地转发到下级OMM服务器；

5、该OMM服务器将该字节流还原成原始数据配置的命令以及参数；

6、OMM服务器将该数据配置的命令以及参数交给配置功能模块进行处理，并发参数下发到网元上。

7、OMM服务器将处理后对需要返回的数据如配置后网元对象，加工成字节流的形式返回给EMS服务器；

8、EMS服务器将该结果字节流返回给EMS客户端，

9、该EMS客户端将该结果字节流传递给进程中对应的域空间中；

10、该域空间将该结果的字节流数据还原后显示到域空间打开的界面上呈现给用户。

在上述介绍中把命令和参数以及处理的结果都转换成字节流，是因为它们可能是Java类的对象，由于要通过EMS服务器进行中转，如果直接下发对象会导致EMS服务器上找不到对应的Java类而失败。

Claims

1.一种在上级网管中增加下级网管功能的方法，包括以下步骤：

步骤三、打开配置插件的功能管理界面；

步骤四、对插件的功能管理界面进行管理操作；

2.权利要求1所述的在上级网管中增加下级网管功能的方法，其特征在于，所述插件以压缩包的形式存在或以目录的形式存在。

3.权利要求1所述的在上级网管中增加下级网管功能的方法，其特征在于，所述插件放部署到上级网管(EMS)客户端的存放方式为：把做好的插件放到特定的目录下由系统自动发现这个插件；或把插件放置到任何地方，并且编写一个插件连接文件以描述这个插件的具体位置，由系统读取所述连接文件来发现这个插件。

4.权利要求1所述的在上级网管中增加下级网管功能的方法，其特征在于，所述步骤二中的独立空间包括主空间和域空间，每一个域空间中可以装载一个或多个插件，并对应于一个下级网管(OMM)，域空间之间是相互独立的。主空间就是用于管理域空间生命周期的，它为域空间的运行提供基础支持，包括加载域空间和卸载域空间。

5.权利要求4所述的在上级网管中增加下级网管功能的方法，其特征在于，类加载器把该空间中的各个插件加载到Java进程中的方法为，当需要加载一个类的字节码时，先在域空间中查询是否有该类的字节码，如果有就使用这个字节码；否则就使用主空间缺省的类加载器进行加载。

6.权利要求5所述的在上级网管中增加下级网管功能的方法，其特征在于，所述步骤三中的打开配置插件的功能管理界面是指加载域空间中所包含的各个插件，实现方法包括以下步骤：

创建域空间类加载器的一个实例；

读取域空间描述符文件来获取这个空间包含的所有插件；

使用该域空间类加载器的实例加载这些插件中的类；

扫描插件中的各种资源文件，当插件要读取资源文件时就把它赋给插件。

7.权利要求6所述的在上级网管中增加下级网管功能的方法，其特征在于，当不再使用域空间时把它停止掉，释放所占用的内存资源。

8.权利要求1至7任一权利要求所述的在上级网管中增加下级网管功能的方法，其特征在于，所述步骤四进行数据配置的管理操作，包括以下步骤：

把下发的命令以及参数包装成字节流；

把字节流传递到上级网管服务器；

上级网管服务器收到后转发到下级网管服务器；

在下级网管服务器上再把字节流还原成原始的数据或命令进行处理；

下级网管服务器处理后对需要返回的数据，也加工成字节流的形式返回给上级网管服务器，最后再返回给上级网管(EMS)客户端进程中对应的域空间中，把结果的字节流数据还原后显示到域空间打开的界面上呈现给用户。