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网络拓扑图组件,专门针对网管软件,很多网管系统常用的界面处理都内置了,上手也快,组件库小巧灵活,只收开发费。两个组件都可以用于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服务方面也无能为力。设计一个灵活但简单的界面架构,用户的很多需求都针对界面的。(bitsCN.com原创/文jianlong/转载请保留)
文章转载自网管之家:http://www.bitscn.com/pdb/java/200905/161526.html
一、 技术架构的变迁
在网管软件最早的年代,基本上都是从电信管理网的那一套发展起来的,按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网络拓扑图组件,专门针对网管软件,很多网管系统常用的界面处理都内置了,上手也快,组件库小巧灵活,只收开发费。两个组件都可以用于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服务方面也无能为力。设计一个灵活但简单的界面架构,用户的很多需求都针对界面的。(bitsCN.com原创/文jianlong/转载请保留)
文章转载自网管之家:http://www.bitscn.com/pdb/java/200905/161526.html