Java技術(shù)，在網(wǎng)絡(luò)管理系統(tǒng)中的應(yīng)用已經(jīng)比較普遍。網(wǎng)管軟件的分類有很多種，有側(cè)重于業(yè)務(wù)應(yīng)用的，有側(cè)重于管理設(shè)備的，有側(cè)重于網(wǎng)絡(luò)的，有側(cè)重于桌面管理的，每種網(wǎng)管軟件雖然外在的具體表現(xiàn)形式都不同，但其實(shí)內(nèi)部的技術(shù)都大同小異。這其中的設(shè)備網(wǎng)管軟件就是一個(gè)最典型的技術(shù)代表，一個(gè)全面的設(shè)備網(wǎng)管軟件基本上要包含網(wǎng)絡(luò)拓?fù)鋱D、設(shè)備配置、故障管理、性能管理、安全管理、業(yè)務(wù)管理，也就是FCAPS 這幾大塊功能。
一、 技術(shù)架構(gòu)的變遷
???? 在網(wǎng)管軟件最早的年代，基本上都是從電信管理網(wǎng)的那一套發(fā)展起來的，按TMN規(guī)范定義的模型來處理，像什么Q接口、F接口、X接口、CORBA、NMS/EMS、FCAPS功能劃分，都是這種模型的代表。這種模型對于大型的電信網(wǎng)絡(luò)來說是必須的，可是對于企業(yè)級別的設(shè)備網(wǎng)管軟件來說，就顯得過于笨重，花費(fèi)的成本是無法接受的。
???? 于是對于設(shè)備網(wǎng)管軟件的架構(gòu)，逐步向?qū)嵱没⒐こ袒l(fā)展，也就是輕量級技術(shù)的發(fā)展。輕量級的技術(shù)，沿用了FCAPS的功能模型，也是用戶關(guān)心的問題。而在內(nèi)部技術(shù)上，突破了TMN的種種限制，好的就借用，不好的就拋棄。在這種輕量級技術(shù)的影響下，根據(jù)用戶的需求，靈活選擇JAVA技術(shù)、數(shù)據(jù)庫技術(shù)、SNMP協(xié)議，就是這一技術(shù)的代表。
二、 輕量級技術(shù)架構(gòu)
???? 選擇C/S，還是B/S？這是首選問題。C/S的客戶端功能很強(qiáng)大，界面表現(xiàn)力很好，而且故障的反應(yīng)能實(shí)時(shí)處理。B/S在集成網(wǎng)絡(luò)拓?fù)鋱D的界面展示上會(huì)打折扣，好在報(bào)表分析這塊上。最好的建議是用Applet+服務(wù)端的模式，兼顧兩者的優(yōu)缺點(diǎn)。因?yàn)榫W(wǎng)管軟件的網(wǎng)絡(luò)服務(wù)特性、實(shí)時(shí)處理特性、大量任務(wù)監(jiān)視、事件分發(fā)特性，不適合采用J2EE的模型，用普通JAVA做服務(wù)端是最恰當(dāng)?shù)摹?/p>
三、 模塊級技術(shù)選擇
1.通信協(xié)議選擇：C/S架構(gòu)的，可以選擇RMI；Applet架構(gòu)的可選XML-RPC或RMI技術(shù)，B/S架構(gòu)不存在這個(gè)問題。
2.數(shù)據(jù)庫技術(shù)選擇：O-R Mapping是最佳選擇，Hibernate是這個(gè)領(lǐng)域最成熟的組件，比只用JDBC簡便很多。
3.網(wǎng)管客戶端：這個(gè)是最容易被忽略的問題，真正在網(wǎng)管開發(fā)中，界面的復(fù)雜度和工作量比服務(wù)端大很多，而且對于用戶體驗(yàn)來說，界面更加重要。界面當(dāng)中最重要非網(wǎng)絡(luò)拓?fù)鋱D不可，基本上大多數(shù)的網(wǎng)管軟件界面都是圍繞著網(wǎng)絡(luò)拓?fù)鋱D來開發(fā)的。目前可以用商業(yè)的ilong視圖組件，因?yàn)楣δ苌婕懊姹容^廣，API比較復(fù)雜，報(bào)表系統(tǒng)做的很多，每個(gè)客戶端都要收運(yùn)行費(fèi)用。喜歡輕量級開發(fā)的，可以用itopoview網(wǎng)絡(luò)拓?fù)鋱D組件，專門針對網(wǎng)管軟件，很多網(wǎng)管系統(tǒng)常用的界面處理都內(nèi)置了，上手也快，組件庫小巧靈活，只收開發(fā)費(fèi)。兩個(gè)組件都可以用于applet環(huán)境。
4.WEB客戶端：如果選用B/S，可以考慮flex或SGV或ajax技術(shù)的web拓?fù)鋱D，flex更成熟一些，用的人比較多。但是所有WEB 拓?fù)鋱D都有一個(gè)缺點(diǎn)，都是100% java技術(shù)的，這樣的話，團(tuán)隊(duì)中需要懂其他技術(shù)的開發(fā)人員。這是我再次推薦用Applet的原因。
5.網(wǎng)管協(xié)議：目前運(yùn)用的最多是SNMP協(xié)議，相關(guān)的java協(xié)議棧也比較多，像SNMP4j就是比較好的JAVA SNMP協(xié)議棧。如果想加快SNMP的開發(fā)，可以考慮ObjectSNMP組件，采用O/M Mapping技術(shù)（和O/R Mapping類似），這樣的話，開發(fā)SNMP的主要工作就是定義普通JAVA對象，當(dāng)然ObjectSNMP底層可能采用如SNMP4J這樣的協(xié)議棧。
6.客戶端報(bào)表分析：毫無疑問，jfreechar肯定能滿足需求，而且是免費(fèi)的（只收文檔費(fèi)用）。還有一個(gè)選擇，用JRobin，可以快速做出漂亮的流量圖，但是JRobin是基于文件的數(shù)據(jù)存儲(chǔ)，與系統(tǒng)的集成度不好，將來做數(shù)據(jù)分析也不方面，僅限用于救急。
7.故障、事件分發(fā)機(jī)制：網(wǎng)管的事件分發(fā)不是很復(fù)雜，用一個(gè)JMS的產(chǎn)品如OpenJMS就可以；如果嫌JMS的存儲(chǔ)多余，可以考慮JGroup消息廣播機(jī)制。
8.任務(wù)機(jī)制：是網(wǎng)管就不可避免的會(huì)設(shè)計(jì)到監(jiān)控任務(wù)、定時(shí)任務(wù)。如果你對線程和時(shí)間處理的很好的，可以用java只帶的就可以；否著的話，可以選擇Quartz，再復(fù)雜的任務(wù)都能處理。
其他體會(huì)：
不要迷信j2ee，對于設(shè)備級網(wǎng)管來說，只會(huì)幫倒忙，而且處處別扭；即使是B/S的架構(gòu)，J2EE在處理任務(wù)、故障事件、SNMP服務(wù)方面也無能為力。設(shè)計(jì)一個(gè)靈活但簡單的界面架構(gòu)，用戶的很多需求都針對界面的。(bitsCN.com原創(chuàng)/文jianlong/轉(zhuǎn)載請保留)
文章轉(zhuǎn)載自網(wǎng)管網(wǎng)：http://www.bitscn.com/pdb/java/200905/161526.html