轻量级java snmp设备网管软件开发技术

tocomeone 发布于 2009/05/04 16:44
阅读 4K+
收藏 11

Java技术,在网络管理系统中的应用已经比较普遍。网管软件的分类有很多种,有侧重于业务应用的,有侧重于管理设备的,有侧重于网络的,有侧重于桌面管理的,每种网管软件虽然外在的具体表现形式都不同,但其实内部的技术都大同小异。这其中的设备网管软件就是一个最典型的技术代表,一个全面的设备网管软件基本上要包含网络拓扑图、设备配置、故障管理、性能管理、安全管理、业务管理,也就是FCAPS 这几大块功能。

一、 技术架构的变迁
     在网管软件最早的年代,基本上都是从电信管理网的那一套发展起来的,按TMN规范定义的模型来处理,像什么Q接口、F接口、X接口、CORBA、NMS/EMS、FCAPS功能划分,都是这种模型的代表。这种模型对于大型的电信网络来说是必须的,可是对于企业级别的设备网管软件来说,就显得过于笨重,花费的成本是无法接受的。
     于是对于设备网管软件的架构,逐步向实用化、工程化发展,也就是轻量级技术的发展。轻量级的技术,沿用了FCAPS的功能模型,也是用户关心的问题。而在内部技术上,突破了TMN的种种限制,好的就借用,不好的就抛弃。在这种轻量级技术的影响下,根据用户的需求,灵活选择JAVA技术、数据库技术、SNMP协议,就是这一技术的代表。

二、 轻量级技术架构
     选择C/S,还是B/S?这是首选问题。C/S的客户端功能很强大,界面表现力很好,而且故障的反应能实时处理。B/S在集成网络拓扑图的界面展示上会打折扣,好在报表分析这块上。最好的建议是用Applet+服务端的模式,兼顾两者的优缺点。因为网管软件的网络服务特性、实时处理特性、大量任务监视、事件分发特性,不适合采用J2EE的模型,用普通JAVA做服务端是最恰当的。

三、 模块级技术选择
1.通信协议选择:C/S架构的,可以选择RMI;Applet架构的可选XML-RPC或RMI技术,B/S架构不存在这个问题。

2.数据库技术选择:O-R Mapping是最佳选择,Hibernate是这个领域最成熟的组件,比只用JDBC简便很多。

3.网管客户端:这个是最容易被忽略的问题,真正在网管开发中,界面的复杂度和工作量比服务端大很多,基本上大多数的网管软件界面都是围绕着网络拓扑图来开发的。目前可以用商业的ilong视图组件,功能涉及面比较广,API比较复杂,报表系统做的很多。喜欢轻量级开发的,可以用itopoview网络拓扑图组件,专门针对网管软件,很多网管常用的界面处理都内置了,上手也快,而且只收开发费。两个组件都可以用于apple web环境。

4.WEB客户端:如果选用B/S,可以考虑flex或SGV或ajax技术的web拓扑图,flex更成熟一些,用的人比较多。但是所有WEB 拓扑图都有一个缺点,都不是100% java技术的,这样的话,团队中需要懂其他技术的开发人员。这是我再次推荐用Applet的原因。

5.网管协议:目前运用的最多是SNMP协议,相关的java协议栈也比较多,像SNMP4j就是比较好的JAVA SNMP协议栈。如果对SNMP细节不是很熟悉或是想加快SNMP的开发,可以考虑ObjectSNMP组件,采用O-M Mapping技术(和O/R Mapping类似)。

6.客户端报表分析:毫无疑问,jfreechar肯定能满足需求,而且是免费的(只收文档费用)。还有一个选择,用JRobin,可以快速做出漂亮的流量图,但是JRobin是基于文件的数据存储,与系统的集成度不好,将来做数据分析也不方面,仅限用于救急。

7.故障、事件分发机制:网管的事件分发不是很复杂,用一个JMS的产品如OpenJMS就可以;如果嫌JMS的存储多余,可以考虑JGroup消息广播机制。

8.任务机制:是网管就不可避免的会设计到监控任务、定时任务。如果你对线程和时间处理的很好的,可以用java只带的就可以;否着的话,可以选择Quartz,再复杂的任务都能处理。

其他体会:
不要迷信j2ee,对于设备级网管来说,只会帮倒忙,而且处处别扭;即使是B/S的架构,J2EE在处理任务、故障事件、SNMP服务方面也无能为力。设计一个灵活但简单的界面架构,用户的很多需求都针对界面的。

加载中
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部