輕量級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服務方面也無能爲力。設計一個靈活但簡單的界面架構，用戶的不少需求都針對界面的。