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

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

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

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

3、 模块级技术选择
1.通讯协议选择：C/S架构的，能够选择RMI；Applet架构的可选XML-RPC或RMI技术，B/S架构不存在这个问题。

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

3.网管客户端：这个是最容易被忽略的问题，真正在网管开发中，界面的复杂度和工做量比服务端大不少，并且对于用户体验来讲，界面更加剧要。界面当中最重要非网络拓扑图不可，基本上大多数的网管软件界面都是围绕着网络拓扑图来开发的。目前能够用商业的ilong视图组件，由于功能涉及面比较广，API比较复杂，报表系统作的不少，每一个客户端都要收运行费用。喜欢轻量级开发的，能够用itopoview网络拓扑图组件，专门针对网管软件，不少网管系统经常使用的界面处理都内置了，上手也快，组件库小巧灵活，只收开发费。两个组件均可以用于applet环境。

4.WEB客户端：若是选用B/S，能够考虑flex或SGV或ajax技术的web拓扑图，flex更成熟一些，用的人比较多。可是全部WEB 拓扑图都有一个缺点，都是100% java技术的，这样的话，团队中须要懂其余技术的开发人员。这是我再次推荐用Applet的缘由。

5.网管协议：目前运用的最可能是SNMP协议，相关的java协议栈也比较多，像SNMP4j就是比较好的JAVA SNMP协议栈。若是想加快SNMP的开发，能够考虑ObjectSNMP组件，采用O/M Mapping技术（和O/R Mapping相似），这样的话，开发SNMP的主要工做就是定义普通JAVA对象，固然ObjectSNMP底层可能采用如SNMP4J这样的协议栈。

6.客户端报表分析：毫无疑问，jfreechar确定能知足需求，并且是免费的（只收文档费用）。还有一个选择，用JRobin，能够快速作出漂亮的流量图，可是JRobin是基于文件的数据存储，与系统的集成度很差，未来作数据分析也不方面，仅限用于救急。

7.故障、事件分发机制：网管的事件分发不是很复杂，用一个JMS的产品如OpenJMS就能够；若是嫌JMS的存储多余，能够考虑JGroup消息广播机制。

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

其余体会：
不要迷信j2ee，对于设备级网管来讲，只会帮倒忙，并且到处别扭；即便是B/S的架构，J2EE在处理任务、故障事件、SNMP服务方面也无能为力。设计一个灵活但简单的界面架构，用户的不少需求都针对界面的。