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

sodai

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服务方面也无能为力。设计一个灵活但简单的界面架构，用户的很多需求都针对界面的。

[ 本帖最后由 sodai 于 2009-5-5 17:57 编辑 ]