基于snmp協議的綜合網絡管理系統課程設計

1、<p><b>　　摘要</b></p><p>　　伴隨Internet時代的到來，網絡技術的迅猛發(fā)展，越來越多的企業(yè)、政府、學校、個人等都融入到互聯網當中。相比從前的專用網絡，現在的網絡已經和人們的學習，工作及生活密不可分了。而作為整個互聯網，穩(wěn)定、高效、準確的運行就顯得極為重要。要做到這一點，除了要依靠網絡設備本身和網絡架構的可靠性以外，還必須依靠一套有效的網絡管理手段來監(jiān)測

2、和管理整個網絡。本文介紹的綜合網絡管理系統應用了基于SNMP的網絡設備性能管理與報表生成。性能管理主要負責全網性能監(jiān)視、性能控制和性能分析。性能管理還進行鏈路性能測試，以及各類性能信息的收集、統計、存儲，性能信息數據庫的維護，性能管理閾值的設置與閾值越過報告，產生按需的性能報告。報表管理系統為管理人員提供從數據的收集，報表合并到報表展示生成的一整套報表體系。</p><p>　　本文還著重介紹了本系統的分層和業(yè)務

3、模塊劃分技術，使業(yè)務模塊和底層協議相分離，通過數據抽象層為中介對網絡設備進行抽象，實現對網絡資源的集中控制和調度。這是本系統的一大特色。</p><p>　　關鍵詞：網絡管理，簡單網絡協議（SNMP），性能管理，報表管理</p><p><b>　　1．緒論</b></p><p>　　1.1 課題背景及目的</p><p&

4、gt;　　眾所周知，網絡管理的起源來自于美國國防部設計的世界上頭幾個包交換網之一的ARPANET。在70年代，TCP/IP協議正式被定為軍方通信標準，隨著此協議的廣泛使用，網絡管理成了一件大事。在80年代末和90年代初，網絡迅速發(fā)展，許多子網數目的增多使網絡活動成為一種必須。在網絡管理的初期，對網絡的管理停留在使用ICMP和PING的基礎上，但是隨著網絡內主機數據的不斷增多，這種簡單的工具已經不可能完</p><p&

5、gt;　　成網絡管理的工作了。 </p><p>　　隨著網絡數目與網絡內主機數目的日益增多，單純依靠一些網絡專業(yè)進行網絡管理已經不可能了，必須有一種通行的網絡管理標準以及相應的管理工具是普通人也能管理網絡。第一個相關的協議是SGMP，它提供了一種直接監(jiān)視網關的方法，也因此成了一種通用的網絡管理工具。下來，有三種可供選擇的管理工具：HEMS，SNMP和建立在TCP/IP基礎上的CMIP（CMOT），因為需要使用I

6、SO/OSI模型進行網絡管理，SNMP首選CMOT作為管理工具由于基本的SNMP已經被廣泛使用了，所有的網絡產品都提供對SNMP的支持，新開發(fā)的具有遠程管理能力的SNMP是RMON，它使管理人員可以將整個子網進行管理，而不是對整個子網內的設備進行管理。 SNMP的核心功能是能讓管理員能改變基于SNMP協議裝置的狀態(tài)，比如說我們可以使用SNMP來關閉路由器，SNMP還能監(jiān)測交換機的問題，當溫度過高時還能發(fā)出警告。SNMP通常是用來管理路由

7、器，但是更重要的是它還能用來管理很置，SNMP的前身SGMP，僅僅是用來管理互聯網路由器，而SNMP卻可以被用來管理Unix系統，Windows系統、打印機、調制解調器、供電器等等。同時，運行在一些</p><p>　　信息的軟件同樣能被其管理，這就讓SNMP不僅僅包括物理硬件同樣也包含軟件，比如web服務器和數據庫。另一個網絡管理問題就是網絡監(jiān)控。網絡監(jiān)控不同于單個的路由器，主機或者是其他設備，它是一個整體的東

8、西。遠程網絡監(jiān)控（RMON）能幫助我們了解整個網絡的運作和每個設備在整個網絡中所起的作用，它不僅用于局域網更應用于廣域網。</p><p>　　1.2 發(fā)展現狀和國內外研究方向</p><p>　　伴隨Internet時代的到來，網絡技術的迅猛發(fā)展，越來越多的企業(yè)。政府、學校、個人等都融入互聯網當中，相比從前的專用網絡，現在的網絡已經和人們的學習、工作及生活密不可分了。而作為整個互聯網、穩(wěn)

9、定、高效、準確的運行就顯得極為重要。要做到這一點，除了要依靠網絡設備本身和網絡架構的可靠性以外，還必須依靠一套有效的網絡管理手段來監(jiān)測和管理整個網絡，而管理網絡就會需要一個適合的網絡協議，當前最典型的網絡管理協議有基于OSI七層模型的公共管理信息協議（CMIP）和基于TCO/IP的簡單網絡管理協議（SNMP）。OSI/CMIP系統管理模型是目前理論上最完備的網絡管理模型，是其他網絡管理模型的基本參考。但由于該模型比較復雜，實現代價高，因

10、此并沒有得到廣泛的應用。相反，當初只是為了管理TCP/IP網絡的SNMP卻得到了迅速的發(fā)展和廣泛應用。SNMP網絡管理模型的突出特點是簡單、易于實現，因此得到廠商的支持。特別是在Internet上的成功應用，使得它的重要性越來越突出，已經成為事實上的工業(yè)標準</p><p>　　1.3 課題研究方案</p><p><b>　　1.3.1 對象</b></p&g

11、t;<p>　　SNMP（Simple Network Management Protocol,簡單網絡管理協議）首先是由IETF的研究小組為了解決Internet上的路由器管理問題而提出的。SNMP的設計原則是簡單性和擴展性。簡單性是通過信息類型限制，請求響應或協議而取得。擴展性是通過將管理信息模型與協議，被管理對象的詳細規(guī)定（MIB）分離而實現的。作為一個基于SNMP的網絡管理模型包括以下關鍵元素：管理站；代理者；管理

12、信息庫；網絡管理協議。管理站一般是一個分立的設備，也可以利用共享系統實現。管理站作為網絡管理員與網絡管理系統的接口，它的基本構成為：一組具有分析數據，發(fā)現故障等功能的管理程序；一個用于網絡管理員監(jiān)控網絡的接口；將網絡管理員的要求轉變?yōu)閷h程網絡元素的實際監(jiān)控的能力；一個從所有被管網絡實體的MIB中抽取信息的數據庫。</p><p><b>　　1.3.2 框架 </b></p>

13、<p>　　當今網絡越來越重要，網絡的規(guī)模、復雜度也越來越大，為了保證網絡有良好的性能，必須使用網絡管理系統，網絡管理系統監(jiān)視和控制網絡，即對網絡進行配置、獲取信息、監(jiān)視網絡性能、監(jiān)視和管理故障以及進行安全控制。但是，由于歷史的原因，現在的網絡管理系統存在著缺陷，不同的網絡運營商擁有各自分割的網管系統，有些廠商發(fā)展自己專用的協議。同時，針對不同的網絡管理功能，存在著大量功能單一的網絡管理系統。這些管理功能相互獨立，甚至不同廠

14、家同類設備間的管理系統也做不到很好的統一。這些情況致使網絡協議不兼容，管理信息分離，不能更好的共享管理資源，缺乏對整個網絡的統一管理，從技術方面看，管理內容龐雜、操作界面多種多樣，從管理方面看，不同的網管系統需要更多的人員學習維護，浪費人力，同時隨著網絡的復雜度增加，分散管理，不容易進行問題定位和對網絡的優(yōu)化針對以上網絡管理中存在的問題，各網絡運營商希望能夠在目前網絡管理基礎上建</p><p>　　立一個綜合的

15、網絡管理系統，以實現網絡管理的統一。這就有了綜合網絡管理的需求，</p><p>　　即把現有的獨立的不同網管系統進行整合，實現兼容和互操作性，形成一個界面友好、</p><p>　　功能齊全的網絡管理系統。</p><p>　　1.3.3 方案論證</p><p>　　隨著科技的不斷發(fā)展，網絡的使用和規(guī)模不斷的擴大，現在的大部分網管軟件都只

16、有實現邏輯拓撲，沒有網絡真實連接和鏈路真實情況的反映，無法幫助用戶了解和分析問題。而綜合網絡管理系統的拓撲發(fā)現過程，采用了物理拓撲算法和拓撲優(yōu)化算法。真正實現了用戶最關心的物理真實拓撲的現實。該系統能展現一個用戶從局域網到廣域網的所有網絡設備的真實連接情況，鏈接狀態(tài)和鏈接負載等，能幫助用戶分析問題和解決問題。拓撲圖不僅真實的再現了網絡結構，且在拓撲圖上網絡管理人員能方便快速地定位到網絡故障，有利于網絡的維護。同時對于大規(guī)模用戶，會有各種

17、不同的網絡設備（包括核心網絡設備和邊緣網絡設備），不用網絡設備，需要有不同的管理和輪詢策略，才能保證實時管理能力的需要，同時不會對網絡造成太大的負載。輪詢間隔管理保證了對骨干網路流量，CPU負載較高時，網管軟件的運行都不會對網絡性能造成太大的影響</p><p>　　簡單網絡協議（SNMP）簡單網絡管理協議（SNMP）是一個應用層協議，是TCP/IP協議套件的一部分。SNMP協議的作用是在網絡構件間提供并傳輸管理

18、信息。通常，SNMP協議可以管理網絡上所有的SNMP設備，管理應用需要的所有數據（狀態(tài)、性能、故障、報警、報表等等）都是依靠SNMP協議在被管理設備間傳輸的</p><p>　　2.1 SNMP模型 </p><p><b>　　SNMP</b></p><p>　　的簡單模型如下圖所示</p><p>　　圖 2-1

19、SNMP簡單模型圖</p><p>　　2.1.1 被管設備</p><p>　　被管理設備是這樣的網絡節(jié)點，它包括一SNMP代理并且駐留在一個被管理網絡中。被管理設備收集并存儲管理信息，并使這些信息對于使用SNMP的管理站點是可用的。被管理設備有時也叫網絡元素，它可以是路由器和訪問服務器、交換機和網橋、總線、計算機主機或打印機。 </p><p><b>

20、;　　2.1.2 代理</b></p><p>　　代理是一個網絡管理軟件模塊，它駐留在一個被管理設備中。代理具有管理信息的本地知識，并把這些信息翻譯成與SNMP兼容的形式。</p><p><b>　　2.1.3管理站點</b></p><p>　　管理站點監(jiān)測并控制被管理設備，它提供網絡管理所需的大部分進程和內存資源。管理站點只

21、存在于被管理網絡上。</p><p>　　2.2 SNMP特點分析 </p><p>　　簡單網絡管理協議SNMP作為網管協議，它提供了監(jiān)控網絡和管理網絡的一整套系統的方法。它有以下特點： </p><p>　　1. 簡單性：顧名思義，SNMP相對以前的管理協議簡單，容易實現且成本低（盡管</p><p>　　實際上SNMP并不是太簡單）。&

22、lt;/p><p>　　2. 可伸縮性：SNMP可管理絕大部分符合Internet標準的設備。</p><p>　　3. 擴展性：通過定義新的“被管理對象”即MIB，可以非常方便地擴展管理能力。 </p><p>　　4. 健壯性：即使在被管理設備發(fā)生嚴重錯誤時，也不會影響管理者的正常工作。 </p><p>　　2.2.1 SNMP v1 &l

23、t;/p><p>　　SNMP v1出臺后，在短短幾年內得到了廣大用戶和廠商的支持。在實踐中，它確實顯示出能管理絕大部分與Internet相連的設備的強大能力。現今的數據通信設備生產廠家都把他們的產品缺省地兼容SNMP v1。大量的商業(yè)產品軟件都實現這個協議，使得該協議的應用越來越廣。從而，SNMP也成為網絡管理的一個較成功的標準。但隨著SNMP v1的廣泛使用，暴露出SNMP v1的如下缺點</p>

24、<p>　　1. 簡單的結構 采用SNMP里確立的功能，只讓一個管理站點執(zhí)行取請求、取下一個請求和置請求命令。利用取請求命令，SNMP管理員能夠請求代理所支持的變量的值。這些變量必須始終予以正確的指示。取下一個請求命令允許讀取代理中的任何對象的直接后繼。此命令大大簡化了讀表的手續(xù)，但是它也的確意味著代理中的變量必須加以分類。結構的簡單性導致了實現的復雜性。</p><p>　　2. 繁重的網絡負擔取請求

25、、取下一個請求和置請求命令一般導致網絡負擔沉重，因為對于每一個所要求的變量，請求和回答報文都要經過網絡發(fā)送。網管應用帶來了沉重的網絡負擔，占據了大量的網絡帶寬。</p><p>　　3. 功能的固定分配因為在SNMP v1里，缺少管理員之間的通信，所以只有扁平的網關結構能夠實現。</p><p>　　4. 僅用于TCP/IP網絡在理論上SNMP可用于任何可用的協議棧上。然而在實踐中，SNM

26、P</p><p>　　的內部結構（地址、保留端口等）己表現太不靈活，以至難于并入多協議環(huán)境中。 </p><p>　　5. 數據的安全性就安全性而言，SNMP v1存在下列問題：SNMP數據包的轉換、時序的正確性、共同體的假冒、信息的無驗證讀。在由SNMP監(jiān)督與控制的網絡里，一個未驗證的用戶總是可能捕捉到數據包并且為了其目的而修改其信息。在如此轉換之后，改變了的數據包又被發(fā)送至它們本來的

27、目標站。接收設備不可能知道此類數據的變化。于是它響應包里的信息，猶如是從管理站點直接收到一樣。一般而言，管理站點與相連代理之間的全部數據，都是采用未加密的用戶數據報協議（UDP）服務發(fā)送的。由于UDP不保證數據順序的正確性，SNMP數據要么作為局域網動態(tài)的結果而被動地、要么經過破壞分子的改造而主動地推遲，或以修改了的次序到達接受站點。這樣一來未經驗證的用戶總是能隨意地修改數據內容，而接收站卻無從</p><p>

28、　　發(fā)覺這類形式的變化。僅僅通過共同體串的重新定義，網管站的擁有者即可隨時訪問與該網絡相關聯的每一個代理。這種偽裝使一個未予驗證的用戶可以冒充驗證用戶去讀取所有的信息并實施所有的管理操作。代理無從區(qū)分正確的實體和假冒者。由未予驗證的用戶采用數據分析儀順帶讀取數據，這是跟數據網絡相關聯的固有問題。一般提供網絡故障檢修使用的全部功能和設備，亦可隨時濫用于骯臟的目的。任何數據（包括口令）在LAN上均可順帶讀到，隨后加以濫用。</p>

29、;<p>　　2.2.2 SNMP v2 </p><p>　　SNMP v2是原始版本SNMP v1的發(fā)展。1993年，SNMP v2作為一系列建議的互聯網標準發(fā)表，現在它已經是一個標準草案。SNMP v2規(guī)范為創(chuàng)造更先進的管理協議奠定了基礎。與SNMP v1相比，SNMP v2做了大量功能擴充。</p><p>　　1. 擴充的通信模型</p><p&

30、gt;　　安全和驗證機制可由網絡管理員通過伙伴來配置。各種訪問權限、管理信息庫的透</p><p>　　視圖可分別借助伙伴來配置，而且?guī)讉€網絡管理站可以訪問一個代理。</p><p>　　2. 管理信息結構的擴充SNMP v2的管理框架在驗證和授權方面進行了擴展。 </p><p>　　3. 管理站之間的通信在SNMP v2中代理和管理站點之間的嚴格區(qū)分己不復存在，

31、網絡管理者可同時扮演代理和管理站點進程的角色。這一功能使管理者之間的通信成為可能。</p><p><b>　　4. 安全</b></p><p><b>　　SNMP v2</b></p><p>　　中采納了一些安全措施。如MD5算法已用于驗證中。通過組合一種檢查和一時間戳，MD5算法為每個SNMP v2報文形成一個1

32、6字節(jié)的指紋。另外還有一加密選項，從而可阻止網絡的外部監(jiān)視者了解傳輸的信息。進一步的安全措施是在SNMP消息的整個生命期內運用時間戳，這用于防止有效信息的重復。還可對所有數據進行加密，所提供的加密機制是國家標準化研究所的DES（數據加密標準）。</p><p>　　5. PDU （協議數據單元）中成批數據傳輸作為對老的SNMP命令的補充，在SNMP v2中引入了Bulk操作，通過一次請求就可以讀取整個MIB樹。由

33、于成批數據傳輸顯著地減少了要處理的數據量，所以為其他數據保留了網絡傳輸容量。 </p><p>　　6. 擴充的出錯信號在SNMP v2中對錯誤列表進行了擴充。</p><p>　　7. 各種傳輸服務的使用SNMP v2真正與多協議因特網相匹配，可適用于多種不同的傳輸協議。除了基于用戶數據報的傳輸映射外，也定義了基于其他協議使用的SNMP v2：OSI</p><p&g

34、t;　　上的SNMP v2DPP上的SNMP v2和Novell-IPX上的SNMP v2。</p><p>　　8. 向下兼容性在所有產品完全遷移到SNMP v2之前，所有代碼都用兩種語言予以實現。這樣，SNMP v2代理可以直接與其管理站進行通信，而SNMP v1必須經過SNMP語言翻譯器</p><p><b>　　才能進行通信。 </b></p>

35、<p><b>　　2.3 管理信息庫</b></p><p>　　<MIB> 管理信息庫（MIB）是網絡管理中的重要組成部分。每個MIB包含：系統與設備的狀態(tài)信息，運行的數據統計，配置參數等。通過SNMP的五種命令就可以讀取或設置MIB</p><p>　　庫中變量的值。所以，通過MIB，網絡管理器對管理對象的管理就簡化為網絡管理器對被管對象

36、的MIB庫的內容的查看和設置。對不同的設備，只要它們有相應的代理軟件和統一的MIB，網絡管理器就可以對它進行統一管理。同時，網絡管理器對被管對象的控制也通過MIB改變?yōu)閷IB內變量值的設置，這樣就避免了管理協議定義過多的控制信息，因為新的控制功能可以通過在MIB中增加對應的新的變量來實現，而不必增加新的控制信息。大體來說，MIB變量可劃分為兩部分：簡單變量和表格。簡單變量包括諸如賦值的或未賦值的整型變量及字符串之類，也包括一些數據結構

37、，它們對應于C語言中的“結構”或PASCAL語言中的“記錄”。表格對應于一維數組，一張表格可以包含變量的多個實例</p><p>　　2.3.1 MIB管理樹所有的MIB對象類型被收集到一個或多個管理信息庫中并且對象類型按照管理信息結構和標識（SMI）定義。一個對象類型的名字明確地代表一個對象，稱為對象標識符。對象標識符是按照在OSI-MIB樹中建立的嚴格分層空間構造的，對象標識符總是一個唯一的從樹根開始描述MI

38、B樹的整數序列。SMI明確要求所有被管理的信息和數據都要由管理樹來標識。這棵管理樹來源于OSI的定義，它具有從根開始的嚴格分層化結構。管理樹的分支和葉子是用數字和字母兩種方式顯示的。數字化編碼是機器可讀的，字母顯示則更適合于人的眼睛并幫助用戶尋找穿過錯綜復雜分支的路徑與MIB相關的管理樹的結構如下： </p><p><b>　　圖</b></p><p>　　2-2

39、 MIB管理樹結構圖</p><p>　　2.3.2 MIB對象類</p><p>　　在SNMP中管理的對象定義在MIB中。為了方便，這些對象目前分為11類，每一類對應MIB-2下的11個節(jié)點中的一個，新的類型和對象可以繼續(xù)加入。具體如下表</p><p><b>　　圖2-3 MIB</b></p><p>　　對象

40、類表所以對于所有MIB對象，前面的路徑都為1.3.6.1.2.1。SNMP就是通過這棵命名樹來識別MIB中的不同對象的。例如：變量1.3.6.1.2.1表示IP地址和MAC地址轉換表的入口。</p><p>　　2.4 抽象句法表示法</p><p>　　ASN.1 SNMP模型的核心是管理站點和管理代理的對象。對象的定義語言采用ASN.1（Abstract Syntax Notation

41、 One）。ASN.1使得數據的描述與系統和廠家無關。這種一致的數據標識意味著聯入網的所有SNMP終端都可以清楚地理解所傳輸的信息[3]。</p><p>　　2.4.1數據類型 </p><p>　　SMI （管理信息結構）定義了3種數據類型：原語類型、結構類型和自定義的類型。</p><p>　　1.原語類型原語ASN. 1類型有Integer（整數）、Octe

42、t String（字節(jié)串）、Object Identifier（對象標識符）和NULL（空）幾種類型。整數類型主要用于數值顯示。字節(jié)串類型在SNMP</p><p>　　里總是用于顯示一個設備的軟硬件信息（Display String）或顯示網絡構件的物理地址（PhysAddress）。MIB樹中的每一個標號是用對象標識符描述的，實際上，對象標識符是一個整數數值的序列。空類型被用作信息標識，該信息能夠具有某種意義

43、，盡管它不包含任何值。</p><p>　　2. 結構類型結構類型是一種用于匯集列表和表格的復合類型。結構類型Sequence允許使用簡單類型的列表：SEQUENCE{<typel>，?，<typeN>} 表格Sequence of是對一些元素組成的抽象數據結構的顯示，用entry表示列表名；SEQUENCE OF <entry> </p><p>　　

44、3. 自定義類型借助于列表和結構類型，其他類型可以從基本類型派生。為此，</p><p>　　SMI定義了6種復合類型：Network Address（網絡地址），IP Address（因特網地址），Counter（計數器），Gauge（量規(guī)），Time Ticks（時間標記），Opaque（模糊）。Counter是32位非負整數計數器。從0記到2的32次冪減1（十進制的4294967295），如超出，從0重新計

45、數。Gauge與Counter類似，但既可遞增計數也可遞減計數。Time Ticks表示一個非負的計數器，按1/100s計數時間。Opaque的引入是為了繞過由SNMP定義帶來的任何可能的限制。 </p><p>　　2.4.2 對象結構和內容 </p><p>　　管理信息的結構和標識沒有定義各自的被管對象，而定義了它們的形式化結構和內容，每個對象類型由5個字段構成：對象名、句法、定義、

46、訪問方式和狀態(tài)。對象名與對象標識符總是成對出現，句法用于描述對象數據類型，定義用于存儲描述被管對象的正文，訪問方式定義對象的訪問字段為只讀、只寫、讀寫或不可訪問，狀態(tài)字段可以是必備、可選或作廢閉。 2.5 SNMP報文操作</p><p>　　SNMPv2中提供了7種協議數據單元，列舉如下：Get Request，Get Next，Get Bulk，Set Request，Response，Trap和Inform

47、 Request[2]。</p><p>　　2.5.1 Get Request報文管理站點利用</p><p>　　Get Request協議數據單元明確請求SNMP代理的MIB中的己知變量。對象標識符在這類報文中作為參量進行發(fā)送。Get Request的協議數據單元代碼規(guī)定為0。除協議數據單元代碼外， Get Request報文還包含另外4個字段：Request ID（請求標一記），E

48、rror Status（錯誤狀態(tài)），Error Index（錯誤索引），Variable Bindings（變量綁定）。 </p><p>　　圖 2-4 Get Request</p><p>　　報文請求標記僅用于監(jiān)視未完成的報文。有了這一標記，SNMP就可以將應答與發(fā)出的請求應起來。錯誤狀態(tài)和錯誤索引在Get Request協議數據單元中總是為0。變量綁定字段中定義所需的對象標識符。

49、2.5.2 Get Next 報文管理站點能夠利用Get Net Request命令查詢MIB樹型結構中下一個對象的值，在這種PDU中，以上次己知對象作為標識符而不是所需對象標識符的值作為參量。Get Next操作特別適合于遍歷各個表或快速查詢連續(xù)數據對象。對那些不了解的對象，可以針對其前一對象發(fā)出Get Next Requests。</p><p>　　圖 2-5 Get Next</p><

50、;p>　　報文變量綁定字段包含的是緊接所需對象之前的對象。</p><p>　　2.5.3 Get Bulk 報文</p><p>　　Get Bulk是對Get Next的推廣。有了Get Bulk協議數據單元，就可以對大量數據尤其是表格進行更為有效的讀取。與Get Next協議數據單元相比，Get Bulk操作中通過網絡發(fā)送的包更少。利用Get Bulk，基本重復操作僅局限于代理

51、中。如果在代理中可以用指定的值處理相關命令，則返回一個Response包從而確認操作有效。除了協議數據單元代碼外，Get Bulk</p><p>　　報文還包含另外4個字段：Request ID、Non-Repeaters（非重復者）、Max-Repetitions（最大重復）、Variable Bindings。</p><p>　　圖 2-6 Get Bulk 報文</p>

52、;<p>　　非重復者參數指示變量表中有多少變量不必重復。Get Bulk協議數據單元中的重復計數器定義在代理中Get Next操作應該進行的頻度。然后代理將所請求的變量值封裝在一個Response協議數據單元中。如果Response協議數據單元到達了其最大值，則余下的變量值將被丟棄而必須由管理站再一次請求。 </p><p>　　2.5.4 Set Request 報文</p>&l

53、t;p>　　Set Request命令使管理系統能夠改變代理上指定變量的值。對象標識符作為參量同這種報文一起發(fā)送。如果代理能夠處理帶有規(guī)定值的Set Request命令，則發(fā)回一個Response包從而確認操作有效，如果出錯，則創(chuàng)建一個Response包，并將相關出錯消息發(fā)回給請求者。 </p><p>　　圖 2-7 Set Request 報文變量綁定字段中規(guī)定所需的對象標識符。</p>

54、<p>　　2.5.5 Response 報文 </p><p>　　Response命令是代理能夠對來自管理系統的所有Get Next，Set Request，Get Bulk或Get Request查詢進行響應。如果代理能夠將指定的值正確操作，則錯誤狀態(tài)和錯誤索引的值為0。否則錯誤狀態(tài)和錯誤索引的值被設為原先預定的值。</p><p>　　圖 2-8 Response<

55、/p><p>　　報文為錯誤狀態(tài)字段規(guī)定的值在下表中列出：</p><p>　　圖 2-9 Response</p><p>　　表如果Response協議數據單元中的錯誤狀態(tài)字段為非0值，則說明在剛進行的請求中檢測到有錯誤發(fā)生。錯誤索引字段中含有的附加信息有助于標示錯誤的原因錯誤索引字段值的定義如下：</p><p>　　圖 2-10錯誤索引字

56、段 </p><p>　　2.5.6 Trap 報文 </p><p>　　SNMP v2中，如果代理探測到特殊情況，它就向管理站發(fā)出陷阱類型（trap-type）的報文。</p><p>　　圖 2-10 Trap 報文 變量綁定字段結構如下</p><p><b>　　[6]</b></p><p

57、>　　：SysUpTime定義了自上次設備重新引導以來所經過的時間。SnmpTrapOID表示相應陷阱的固定名。對象標識符表示一個或多個對象。在RFC1450中，SNMP v2預先定義了若干陷阱：Traps Group陷阱組，那種可以進行配置以便發(fā)送SNMP v2 Trap PDL的代理預先規(guī)定的所有對象均包含在這個陷阱組中。Well Known Traps（周知陷阱），包括：1. cold Start—冷啟動陷阱指示某SNMP

58、v2代理已經因配置變化而重新初始化。2. warm Start—熱啟動陷阱指示某SNMP v2代理己重新初始化，但沒有改變配置。3. Link Down—鏈路斷陷阱指示SNMP v2代理己檢測到某條鏈路出了差錯。4. LinkUp-LinkUp陷阱指示配置的某SNMP v2代理的鏈路已被激活。5. authentication Failure—該陷阱指示SNMP v2代理已檢測到在其收到的數據包中有驗證錯。6. egpNeighborL

59、oss—該陷阱指示SNMPv2代理已將通信進程讓于某EGP鄰居。2.5.7 Inform Request 報文與SNMP v1不同，</p><p>　　3.1 系統可行性的提出 </p><p>　　當今網絡越來越重要，網絡的規(guī)模、復雜度也越來越大，為了保證網絡有良好的性能，必須使用網絡管理系統，網絡管理系統監(jiān)視和控制網絡，即對網絡進行配置，獲取信息，監(jiān)視網絡性能，監(jiān)視和管理故障以及進行

60、安全控制。但是，由于歷史的原因，現在的網絡管理系統存在著缺陷，不同的網絡運營商擁有各自分割的網管系統，有些廠商發(fā)展自己專用的協議。同時，針對不同的網絡管理功能，存在著大量功能單一的網絡管理系統。這些管理功能相互獨立，甚至不同廠家同類設備間的管理系統也做不到很好的統一。這些情況致使網絡協議不兼容，管理信息分離，不能更好的共享管理資源，缺乏對整個網絡的統一管理，從技術方面看，管理內容龐雜、操作界面多種多樣，從管理方面看，不同的網管系統需要更

61、多的人員學習維護，浪費人力，同時隨著網絡的復雜度增加，分散管理，不容易進行問題定位和對網絡的優(yōu)化。針對以上網絡管理中存在的問題，各網絡運營商希望能夠在目前網絡管理基礎上建</p><p>　　立一個綜合的網絡管理系統，以實現網絡管理的統一。這就有了綜合網絡管理的需求，即把現有的獨立的不同網管系統進行整合，實現兼容和互操作性，形成一個界面友好、功能齊全的網絡管理系統。而該系統實現了跨平臺，支持多廠商設備，可以針對本

62、行業(yè)實際需要進行二次開發(fā)。該管理系統能集成國內，外各種主流網絡廠商的產品。如Cisco，3COM，華為等。提供了全中文的網絡管理平臺，符合國內客戶的使用習慣，能有效協助用戶維護網絡系統正常運行，提高網絡利用率，幫助用戶更好的利用網絡為自己服務。隨著信息時代的到來，對計算機網絡的依賴使得計算機網絡本身運行的可靠性變得至關重要，對網絡管理也就有了更高的要求。按照OSI的定義，網絡管理主要包括五個功能域：故障管理、配置管理、性能管理、安全管理

63、和計費管理。在五大功能域中，配置管理是基礎，它的主要功能包括發(fā)現網絡的拓撲結構、監(jiān)視和管理網絡設備的配置情況。其它的各項功能都以已知網絡的拓撲結構為基礎。網絡拓撲發(fā)現的主要目的是獲取和維護網絡節(jié)點的存在信息和它們之間的連接關系信息，并在此基礎上繪制出整個網絡拓撲圖。網絡管理人員在拓撲圖的基礎上對故障節(jié)點進行快速定位。 </p><p><b>　　3.2 需求分析 </b></p>

64、;<p>　　3.2.1 性能管理 </p><p>　　性能管理主要負責全網性能監(jiān)視、性能控制和性能分析，完成鏈路性能測試，以及各類性能信息的收集、統計、存儲，性能信息數據庫的維護，性能管理閾值的設置與閾值越過報告，產生按需的性能報告，即提供性能信息查詢功能或周期性的性能報告。為操作人員和管理部門提供網絡運行狀態(tài)、報文數統計情況、處理機負荷能力等信息。性能管理模塊需要信息模型模塊和配置管理模塊提供

65、的信息來完成可定制的性能采集以及性能分析報告，還需要向報表模塊提供數據用于產生性能統計報表。性能管理子系統原始數據有兩類，一類是性能監(jiān)控和分析的數據，這部分來自數據庫，有一個專門的數據采集模塊來完成，另一類是實時監(jiān)測數據所用到的數據，這些數據直接調用SNMP數據通信模塊從被管設備那里獲得。</p><p>　　3.2.2 報表管理 </p><p>　　報表管理系統為管理人員提供從數據的收

66、集，報表合并到報表展示生成的一整套報表體系。各個管理模塊使用報表模塊開發(fā)了各種不同管理報表。使用這一報表功能，能為網管人員提供各種不同類型、從不同角度的報表，如性能報表、故障報表、各種日報、周報、月報、年報等。報表管理模塊以直觀的表格和圖形方式顯示故障、性能等各種參數信息，是網絡維護人員最為關心的模塊之一。該報表管理系統可以生成網絡維護人員想要到得到的各種形式的報表，如匯總報表，各種設備和接口的屬性報表，可以是歷史也可是實時報表，并且可

67、以保存以可選格式，如Excel、PDF格式等[14]。 </p><p><b>　　3.3 系統組成 </b></p><p>　　本軟件包括以下子系統： </p><p>　　1. 拓撲管理子系統：包括IP</p><p>　　拓撲發(fā)現與自動布局，拓撲圖管理等； </p><p>　　2. 告

68、警管理子系統：包括告警過濾、分類、排序、查看和直接定位等；</p><p>　　3. 配置管理子系統：包括對設備配置數據的管理和審計；</p><p>　　4. 性能管理子系統：檢測被管理設備的運行狀況，定時或者用戶驅動的性能數據的采集和表現； </p><p>　　5. 報表管理子系統：報表的定制、產生、分發(fā)和展示；</p><p>　　6

69、. 系統管理子系統：對系統自身的管理包括用戶及其權限的管理、日志的記錄、數據備份、系統冗余； </p><p>　　7. 信息模型服務：提供對所有被管理網元（包括網絡軟件、硬件、應用和服務對象）的面向對象抽象、存儲和查詢機制，實現管理對象持久化存儲和管理； </p><p>　　8. 協議適配器：對設備網絡管理協議的統一抽象和描述； </p><p>　　9. Ag

70、ent：實現對服務器及其軟件環(huán)境的監(jiān)控； </p><p>　　10..分布式中間件：包括軟件實現結構和分布式計算中必要的服務如名字解析，事務，消息服務等，能夠實現分布式服務對象定位和調用，負載平衡等分布式計算機制； </p><p>　　3.4系統總體設計方案 </p><p>　　3.4.1 系統上下文定義 </p><p>　　系統與外

71、部環(huán)境[15]：</p><p>　　圖3-1 系統和外部環(huán)境</p><p>　　系統處于網絡管理層，實現網絡層的告警管理、性能管理、拓撲管理、報表管理、配置管理。既可以從網元上直接采集管理數據，也可以通過標準接口與第三方網元管理系統交互取得管理數據，也可以驅動第三方的管理系統實現網元級別的管理。對服務器及其軟件環(huán)境的管理由私有的Agent實現。向上可以支撐各業(yè)務系統。 </p&g

72、t;<p>　　3.4.2 設計思路與方法 </p><p>　　按照功能需求規(guī)格來決定主要軟件模塊的劃分。將整個軟件系統分為四層：數據采集層，數據抽象層，數據處理層和數據表現層；每一層的功能依托于下一層的實現，一般不作跨越功能層次的調用。利用分布式總線實現各個模塊之間的通信。模塊之間通過接口，利用總線進行互操作?？傮w設計上先決定功能模塊，然后按照功能模塊設計其服務接口；按照功能模塊特點和數據流量以

73、及流向決定其部署方式和通信方式；按照性能需求和對移植性、開發(fā)強</p><p>　　度的綜合考慮決定中間件和對象服務的選型。本系統采用自頂向下的設計方法。首先決定整體構架，然后再逐步完善構架的基礎上，分模塊完成各個功能模塊的設計。</p><p>　　3.4.3 設計約束</p><p>　　本系統運行于安裝操作系統Linux、Windows、Solaris的PC和

74、服務器平臺，應用層界面能夠同時運行在以上平臺上；服務層、中間件、對象服務、數據采集層要求能夠在這三種平臺上以較小修改被移植；網絡接口，要求運行平臺支持100M以太網接口；在采用集中配置的方案下，網管服務器應通過網絡接口與被管理網絡實現SNMP等管理協議互通；在采用分布式配置的方案下，網管服務器應該與分布式數據采集機實現基于TCP/IP的網絡互聯。本系統的技術限制是由于采用java實現系統，考慮到數據網絡業(yè)務和協議融合的趨勢，在設計上保留

75、擴展以支持其他管理協議的能力，如TL1、CMIP、MML或者其他私有協議等，但需要為這些協議編寫適配層。服務層主要處理（更新，一致性檢查，匯總）來自各個管理域中以管理信息模型組織的管理信息，并將其處理為面向用戶和應用的數據組織，存入數據庫。這樣可以將底層數據提取、抽象等操作與對用戶請求的響應操作分別處理，提高了應用層的響應速度，屏蔽了底層復雜性。數據庫中的信息按照面向應用的方式進行組織，便于備份，查詢。充分采用中間件提供的各種服務來實現

76、分布式計算中的事務、并發(fā)控制、名字服務、持續(xù)性</p><p><b>　　性。</b></p><p>　　3.4.4 系統框架圖 </p><p>　　從軟件體系結構角度看，系統可以分為以下四層： </p><p>　　數據采集層：本層由各種協議適配器構成，向上層提供統一的接口訪問管理協議棧（SNMP、CMIP、TL

77、1等），獲取管理信息（包括事件信息、日志信息、性能信息和拓撲信息等）,并在初始發(fā)現時作為驅動模塊構建信息模型；數據抽象層：對底層數據采集的數據進行統一的描述，組織為管理信息庫。向上提供一個統一的管理語義和調用接口。使得各個業(yè)務模塊面對統一的數據模型，使得對資源的管理方式一致并處于單一的可控路徑下，方便對資源進行權限管理，互斥訪問等操作，使得面向事務的并發(fā)管理成為可能。內部的Adapter Controller作為控制器決定上層的請求應該

78、由哪個適配器處理； 數據處理層：專注于管理業(yè)務的實現，不再關心底層協議的差異性。響應前臺應用的請求，完成數據查詢，處理等功能； 數據表現層：前臺界面，從數據處理層得到數據加以顯示，它是管理員與網絡管理系統的接口；每一層的功能依托于下一層的實現。每一層包含一組相互操作的組件，每層組件向下層組件獲取服務，并提供服務給上層組件；層與層之間的服務訪問點通過明確定義的接口來進行。層次是對系統的一種橫向劃分，從縱向看，針對性能、事件、拓撲、配置、用

79、戶和安全等每個管理功能</p><p>　　圖 3-2 軟件體系結構圖</p><p>　　數據處理層添加視圖處理模塊。配置管理需要對系統的可擴展部分進行配置，比如如何添加一個設備對象。</p><p>　　圖3-2中，系統被刻畫為前臺界面和后臺程序。這是從簡化了軟件部署信息和實際調用關系后，按照模塊層次和邏輯關系畫的系統邏輯結構圖。反映了每個系統組件從邏輯上看處于

80、系統的哪個位置。而在實際應用中，整個系統將按照應用環(huán)境和網絡管理需求，被部署在一臺或者多臺服務器和數據采集前置機上。從數據采集層、數據抽象層、數據處理層直到數據表現層，這些可能分布于不同機器和進程空間的軟件組件，通過公共中間件提供的通信和服務機制實現互操作。</p><p><b>　　3.4.5 模塊</b></p><p>　　子系統分解描述 性能管理（Perfo

81、rmance Module）：包括性能數據采集、實時分析和歷史分析；子模塊：性能管理界面：實時性能管理界面（分析、采集配置）；歷史性能管理界面（分析、采集配置）；門限配置界面。性能服務：性能數據匯總（入庫）；性能分析實現（實時分析與轉發(fā)，歷史分析）；性能采集配置（實時，歷史）；門限配置（存儲，分發(fā)）；數據采集（實時，歷史采集任務配置，執(zhí)行）；門限檢查；門限事件生成（按照內部事件格式）；數據緩存（歷史數據）；數據上報（實時，歷史）；性能門

82、限</p><p>　　1.get perf item</p><p>　　2.schedule collect perf data</p><p>　　3.snmp get</p><p>　　4.threshold event</p><p>　　5.push event</p><p>　

83、　圖 3-3性能門限示意圖 </p><p>　　說明：性能模塊從信息模型管理器上得到性能指標對象；請求協議適配器收集性能數據；協議適配器從設備上獲取數據；如性能越界則發(fā)送性能越界事件給jms；jms將事件推送到告警模塊進行處理。報表管理（Report Manager）：包括報表配置，自動生成和分發(fā)； 子模塊：報表管理界面：配置，察看界面；報表服務：報表模板配置功能；報表模板管理（存儲，查找）；報表任務配置功能；

84、定時任務執(zhí)行（報表生成，存放，分發(fā)）功能；報表察看響應；1.get alarm data</p><p>　　2.get topo data</p><p>　　3.get perf data</p><p>　　4.get conf data</p><p>　　圖 3-4報表產生示意圖</p><p>　　產生報表

85、：報表模塊從各個業(yè)務模塊獲得生產報表的原始數據，再根據報表模版生成報表。 3.4.6 模塊</p><p>　　子系統間的依賴關系 各業(yè)務功能模塊之間的依賴關系如下圖所示：</p><p>　　圖 3-5依賴關系圖</p><p>　　如圖3-5所示，模塊按功能組織，表現為功能之間的依賴關系。 4. 系統的技術特點 </p><p><

86、b>　　4.1分層的系統</b></p><p>　　本系統的特點是業(yè)務模塊與底層協議相分離，通過數據抽象層為中介對網絡設備進行抽象，實現對網絡資源的集中控制和調度。 </p><p><b>　　4.2信息模型 </b></p><p>　　使用了信息模型的觀念來管理整個網絡，使網管的所有業(yè)務都基于信息模型。使各個業(yè)務模塊對

87、網絡的理解一致，便于信息的交互。在信息模型與設備之間使用適配層來處理設備管理協議的差異，適配層與具體的網管業(yè)務無關，只負責設備的管理協議與信息模型的映射。我們需要將所有可管理的資源以被管對象的方式來表現，每一個獨立的設備或業(yè)務系統是一棵獨立的包含樹。COL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLEA業(yè)務系統網絡設備服務器 </p><p>　　圖 4-1被管對象包含

88、樹</p><p>　　整個網絡有一個根節(jié)點，管理域作為根節(jié)點下的被管對象，所有設備和業(yè)務系統都包含到對應的管理域節(jié)點下。COL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLECOL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLECOL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLECOL

89、-ACT-</p><p><b>　　STA-</b></p><p>　　123456789101112</p><p>　　HS1HS2OK1OK2PS</p><p><b>　　CONSOLE</b></p><p><b>　　COL-</b>

90、;</p><p><b>　　ACT-</b></p><p><b>　　STA-</b></p><p>　　123456789101112</p><p>　　HS1HS2OK1OK2PS</p><p><b>　　CONSOLE</b><

91、;/p><p><b>　　COL-</b></p><p><b>　　ACT-</b></p><p><b>　　STA-</b></p><p>　　123456789101112</p><p>　　HS1HS2OK1OK2PS</p>

92、<p><b>　　CONSOLE</b></p><p><b>　　服務器 </b></p><p><b>　　圖 4-2管理域</b></p><p>　　以一個管理域為例，信息模型管理器只維護被管對象之間的包含關系，與業(yè)務模塊</p><p>　　相關的

93、部分數據由業(yè)務模塊以被管對象為基礎自行維護。</p><p>　　如拓撲，維護被管對象之間的連接關系，配置模塊定義了被管對象之間的依賴關系。COL-</p><p><b>　　ACT-</b></p><p><b>　　STA-</b></p><p>　　123456789101112<

94、/p><p>　　HS1HS2OK1OK2PS</p><p><b>　　CONSOLE</b></p><p>　　服務器業(yè)務系統服務器網絡設備網絡設備服務器業(yè)務系統服務器port1port2進程1port2拓撲模塊配置模塊信息模型管理器 </p><p><b>　　圖4-3連接關系圖</b>&l

95、t;/p><p>　　從邏輯上看整個信息模型是統一的，既包含了網絡資源的抽象，也包含業(yè)務數據。port1port2進程1 </p><p><b>　　圖 4-4邏輯抽象</b></p><p>　　這樣使各個業(yè)務模塊的數據可以統一的方式進行共享。當網絡設備的端口（port1）發(fā)生故障或性能發(fā)生劣化時，會發(fā)送相應端口事件。故障管理模塊接收到該事件，

96、從拓撲模塊得知該端口對象與服務器上的端口（port2）有連接關系，必然對port2造成影響；從配置模塊得知port2 被進程1所依賴，進程1被業(yè)務系統所依賴，由此可以判斷由于port1的故障或性能劣化必將對業(yè)務系統造成影響。由此可以有選擇的發(fā)送告警信息，并對告警進行準確的定位。從實現的層面考慮將業(yè)務數據由各業(yè)務模塊去維護簡化了數據抽象層的實現，提高</p><p>　　信息模型的檢索效率，同時當某業(yè)務模塊發(fā)生故障

97、、數據發(fā)生錯誤時不會影響其他的業(yè)</p><p>　　務模塊，最大限度的保障系統的正常運行。對網絡設備的對象化是以我們預先定義的被</p><p>　　管對象類為依據來實現的。每個被管對象類包含公有屬性和私有屬性。私有屬性是為了唯一標識一個對象，并供協議適配器從網元上獲取數據時使用，實例化為被管對象后私有屬性被賦與固定的值。公有屬性是供數據處理層使用，定義被管對象所管理的內容，實例化為被管

98、對象后不賦值。當數據處理層需要讀取或設置公有屬性的值時由協議適配器從網元上直接獲得或寫入。實例化后的管理信息樹如下：</p><p>　　-type=CISCO 3550</p><p>　　-EquID=10.0.0.1</p><p><b>　　-Index=1</b></p><p>　　-EquID=10.0.

99、0.1</p><p><b>　　-Index=2</b></p><p>　　-EquID=10.0.0.1</p><p><b>　　-Index=24</b></p><p>　　-EquID=10.0.0.1</p><p>　　-EquID=10.0.0.1&l

100、t;/p><p>　　-EquID=10.0.0.1</p><p>　　-EquID=10.0.0.1</p><p><b>　　1</b></p><p><b>　　1</b></p><p><b>　　1</b></p><p

101、><b>　　1</b></p><p><b>　　1</b></p><p><b>　　1</b></p><p><b>　　1</b></p><p><b>　　1</b></p><p>&

102、lt;b>　　1</b></p><p><b>　　1</b></p><p><b>　　1</b></p><p><b>　　1</b></p><p>　　圖 4-6管理信息樹圖</p><p>　　需要管理的設備及其邏輯功能

103、及物理結構被抽象化為被管對象類，系統運行時將這些類實例化為被管對象，所有的對象都可以統一的方式分配權限。所有的被管對象組成管理信息樹，由協議適配器根據預先定義好的被管對象類和實際被管理的資源來構造。當數據處理層需要從設備上獲得數據時只需要從樹上找到相應的對象，交給協議適配器即可，每個被管對象中包含相關的網絡管理協議的信息如SNMP OID信息模型管理器實現對象化的接口來創(chuàng)建、維護被管對象樹和被管對象類，持久化機制由管理器提供。業(yè)務層只需

104、要和信息模型交互。在統一的信息模型之下我們可以實現更為復雜的管理需求，比如基于策略的管理、基于業(yè)務的管理、對管理活動的事務化等，同時可以方便的開發(fā)新的業(yè)務模塊，以及集成第三方的產品，包括硬件產品和軟件產品。同時以信息模型為基礎還可以使業(yè)務模塊最大限度的獨立開來，單獨提供給市場，以滿足不同客戶的需求，也為更上層的管理系統如NGOSS提供了良好的支持。信息模型包含兩部分： </p><p>　　1. 被管對象類及其包

105、含關系。描述系統可管理的資源； </p><p>　　2. 根據被管對象類生成的被管對象。描述系統目前管理的資源的實例；被管對象類定義的原則：1. 以物理設備為基礎，以物理設備上需要本網管系統管理的功能模塊為節(jié)點構造基</p><p>　　本被管對象類；2. 被管對象不包括設備及其功能實際的信息，只作為它們的抽象表示；</p><p>　　3. 被管對象包含低層協議

106、的詳細信息，這些信息供協議適配層使用；</p><p>　　4. 每個設備是一棵獨立的包含樹，在做分域管理時，相應的設備樹被聚合到對應的</p><p><b>　　域節(jié)點中；</b></p><p>　　5. 被管對象只具有屬性； </p><p>　　6. 如果是對業(yè)務系統或服務器的管理，也參照上面的原則。 <

107、/p><p><b>　　4.3 可擴展性 </b></p><p>　　可擴展性體現在以下幾個方面： </p><p>　　1. 協議適配層，可以動態(tài)添加需要的協議適配器，對系統尚不支持的管理協議進行處理，向數據抽象層提供統一的接口，使得上層模塊無需關心底層協議適配器的變化； </p><p>　　2. 數據抽象層，可以添

108、加新的被管對象類，作為協議適配器創(chuàng)建被管對象的依據； </p><p>　　3. 數據處理層，可以動態(tài)添加新的業(yè)務模塊，以支持用戶的特殊需求；</p><p>　　4. 添加一個特殊的SNMP設備或添加新的功能時，只需要通過系統管理模塊的圖形化界面，在信息模型管理器中定義新的管理類，并聚合到適當的節(jié)點上，就可以實現</p><p>　　對該設備或功能的管理。<

109、/p><p><b>　　4.4技術框架 </b></p><p>　　本系統主要使用java語言實現，表現方式主要采用B/S方式。部分需要實時顯示的部分，如告警、實時性能監(jiān)控、實時拓撲更新等要增加基于瀏覽器applet方式作為用戶的可選項。數據表現層直接相關部分采用STRUTS作為框架，負責界面的構成。數據處理層、數據抽象層、數據采集層使用EJB3.0作為實現框架。數據

110、處理層各模塊：拓撲管理、故障管理、性能管理、系統管理、配置管理使用各自的無狀態(tài)會話Bean向上提供接口。各模塊需要接收消息，使用消息驅動Bean。數據抽象層使用一個無狀態(tài)會話Bean向上和向下提供接口。數據采集層將每一個協議適配器實現為單獨的Resource Adapter。使用中間件提供的JMS作為整個系統的消息轉發(fā)中心。中間件使用Jboss4.0.4，需要嵌入服務器的Agent模塊使用基于ACE+TAO的C++實現，提供CORBA接