jasmine214--love

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