電信管理網(wǎng)開發(fā)范文
本站小編為你精心準備了電信管理網(wǎng)開發(fā)參考范文，愿這些范文能點燃您思維的火花，激發(fā)您的寫作靈感。歡迎深入閱讀并收藏。
一、網(wǎng)絡管理技術概述
網(wǎng)絡管理已經(jīng)成為計算機網(wǎng)絡和電信網(wǎng)研究中最重要的內容之一。網(wǎng)絡中采用的先進技術越多，規(guī)模越大，網(wǎng)絡的維護和管理工作也就越復雜。計算機網(wǎng)絡和電信網(wǎng)的管理技術是分別形成的，但到后來漸趨同化，差不多具有相同的管理功能和管理原理，只是在網(wǎng)絡管理上的具體對象上有些差異。
通常，一個網(wǎng)絡由許多不同廠家的產品構成，要有效地管理這樣一個網(wǎng)絡系統(tǒng)，就要求各個網(wǎng)絡產品提供統(tǒng)一的管理接口，即遵循標準的網(wǎng)絡管理協(xié)議。這樣，一個廠家的網(wǎng)絡管理產品就能方便地管理其他廠家的產品，不同廠家的網(wǎng)絡管理產品之間還能交換管理信息。
在簡單網(wǎng)絡管理協(xié)議snmp（simplenetworkmanagementprotocol）設計時，就定位在是一種易于實施的基本網(wǎng)絡管理工具。在網(wǎng)管領域中，它扮演了先鋒的角色，因osi的cmip發(fā)展緩慢同時在internet的迅猛發(fā)展和多廠商環(huán)境下的網(wǎng)絡管理解決方案的驅動下，而很快成為了事實上的標準。
snmp的管理結構如圖1所示。它的核心思想是在每個網(wǎng)絡節(jié)點上存放一個管理信息庫mib（managementinformationbase），由節(jié)點上60（agent）負責維護，管理者通過應用層協(xié)議對這些進行輪詢進而對管理信息庫進行管理。snmp最大的特點就是其簡單性。它的設計原則是盡量減少網(wǎng)絡管理所帶來的對系統(tǒng)資源的需求，盡量減少agent的復雜性。它的整個管理策略和體系結構的設計都體現(xiàn)了這一原則。
snmp的主要優(yōu)點是：
·易于實施；
·成熟的標準；
·c／s模式對資源要求較低；
·廣泛適用，代價低廉。
簡單性是snmp標準取得成功的主要原因。因為在大型的、多廠商產品構成的復雜網(wǎng)絡中，管理協(xié)議的明晰是至關重要的；但同時這又是snmp的缺陷所在——為了使協(xié)議簡單易行，snmp簡化了不少功能，如：
·沒有提供成批存取機制，對大塊數(shù)據(jù)進行存取效率很低；
·沒有提供足夠的安全機制，安全性很差；
·只在tcp／ip協(xié)議上運行，不支持別的網(wǎng)絡協(xié)議；
·沒有提供管理者與管理者之間通信的機制，只適合集中式管理，而不利于進行分布式管理；
·只適于監(jiān)測網(wǎng)絡設備，不適于監(jiān)測網(wǎng)絡本身。
針對這些問題，對它的改進工作一直在進行。如1991年11月，推出了rmon（rernotenetworkmonitor）mib，加強snmp對網(wǎng)絡本身的管理能力。它使得snmp不僅可管理網(wǎng)絡設備，還能監(jiān)測局域網(wǎng)和互聯(lián)網(wǎng)上的數(shù)據(jù)流量等信息，1992年7月，針對snmp缺乏安全性的弱點，又公布了s-snmp（securesnmp）草案。到1993年初，又推出了snmpversion2即snmpv2（推出了snmpv2以后，snmp就被稱為snmpv1）。snm-pv2包容了以前對snmp的各項改進工作，并在保持了snmp清晰性和易于實現(xiàn)的特點以外，吸取了cmip的部分優(yōu)點，功能更強，安全性更好，具體表現(xiàn)為：
·提供了驗證機制，加密機制，時間同步機制等，安全性大大提高；
·提供了一次取回大量數(shù)據(jù)的能力，效率大大提高；
·增加了管理者和管理者之間的信息交換機制，從而支持分布式管理結構，由位于中間層次（intermediate）的管理者來分擔主管理者的任務，增加了遠地站點的局部自主性。
·可在多種網(wǎng)絡協(xié)議上運行，如osi、appletalk和ipx等，適用多協(xié)議網(wǎng)絡環(huán)境（但它的缺省網(wǎng)絡協(xié)議仍是udp）。
·擴展了管理信息結構的很多方面。特別是對象類型的定義引入了幾種新的類型。另外還規(guī)范了一種新的約定用來創(chuàng)建和刪除管理表（managementbrs）中的“行”（rows）。
·定義了兩種新的協(xié)議數(shù)據(jù)單元pdu（protocoldataunit）。get-bulk-request協(xié)議數(shù)據(jù)單元允許檢索大數(shù)據(jù)塊（largedatablocks），不必象snmp那樣逐項（itembyitem）檢索；inform-request協(xié)議數(shù)據(jù)單元允許在管理者之間交換陷阱（tran）信息。
cmip協(xié)議是在osi制訂的網(wǎng)絡管理框架中提出的網(wǎng)絡管理協(xié)議。cmip與snmp一樣，也是由管理者、、管理協(xié)議與管理信息庫組成。
cmip是基于面向對象的管理模型的。這個管理模型表示了封裝的資源并標準化了它們所提供的接口。如圖2所示了四個主要的元素：
·系統(tǒng)管理應用進程是在擔負管理功能的設備（服務器或路由器等〕中運行的軟件：
·管理信息庫mib是一組從各個接點收集來的與網(wǎng)絡管理有關的數(shù)據(jù)；
·系統(tǒng)管理應用實體（systemmanagementapplicationentities）負責網(wǎng)絡管理工作站間的管理信息的交換，以及與網(wǎng)絡中其它接點之間的信息交換；
·層管理實體（layermanagemententities）表示在osi體系結構設計中必要的邏輯。
cmip模型也是基于c／s結構的。客戶端是管理系統(tǒng)，也稱管理者，發(fā)起操作并接收通知；服務器是被管系統(tǒng)，也稱，接收管理指令，執(zhí)行命令并上報事件通知。一個cmip操作臺（console）可以和一個設備建立一個會話，并用一個命令就可以下載許多不同的信息。例如，可以得到一個設備在一段特定時間內所有差錯統(tǒng)計信息。
cmip采用基于事件而不是基于輪詢的方法來獲得網(wǎng)絡組件的相關數(shù)據(jù)。
cmip已經(jīng)得到主要廠商，包括ibm、hp及at&t的支持。用戶和廠商已經(jīng)認識到cmip在企業(yè)級網(wǎng)絡管理領域是一個比較好的選擇。它能夠滿足企業(yè)級網(wǎng)管對橫跨多個管理域的對等相互作用（peertopeerinteractions）的要求。cmip特別適合對要求提供集中式管理的樹狀系統(tǒng)，尤其是對電信網(wǎng)（telecommunicationsnetwork）的管理。這就是下面提到的電信管理網(wǎng)。
二、電信管理網(wǎng)tmn
電信管理網(wǎng)tmn是國際電聯(lián)itu-t借鑒0si中有關系統(tǒng)管理的思想及技術，為管理電信業(yè)務而定義的結構化網(wǎng)絡體系結構，tmn基于osi系統(tǒng)管理（itu-ux.700／iso7498-4）的概念，并在電信領域的應用中有所發(fā)展.它使得網(wǎng)絡管理系統(tǒng)與電信網(wǎng)在標準的體系結構下，按照標準的接口和標準的信息格式交換管理信息，從而實現(xiàn)網(wǎng)絡管理功能。tmn的基本原理之一就是使管理功能與電信功能分離。網(wǎng)絡管理者可以從有限的幾個管理節(jié)點管理電信網(wǎng)絡中分布的電信設備。
國際電信聯(lián)盟（itu）在m.3010建議中指出，電信管理網(wǎng)的基本概念是提供一個有組織的網(wǎng)絡結構，以取得各種類型的操作系統(tǒng)（oss）之間、操作系統(tǒng)與電信設備之間的互連。它采用商定的具有標準協(xié)議和信息的接口進行管理信息交換的體系結構。提出tmn體系結構的目的是支撐電信網(wǎng)和電信業(yè)務的規(guī)劃、配置、安裝、操作及組織。
電信管理網(wǎng)tmn的目的是提供一組標準接口，使得對網(wǎng)絡的操作、管理和維護及對網(wǎng)絡單元的管理變得容易實現(xiàn)，所以，tmn的提出很大程度上是為了滿足網(wǎng)管各部分之間的互連性的要求。集中式的管理和分布式的處理是tmn的突出特點。
itu-t從三個方面定義了tmn的體系結構（architecture），即功能體系結構（functionalarchitecture），信息體系結構（informationarchitecture）和物理體系結構（physicalarchitecture）。它們分別體現(xiàn)在管理功能塊的劃分、信息交互的方式和網(wǎng)管的物理實現(xiàn)。我們按tmn的標準從這三個方面出發(fā)，對tmn系統(tǒng)的結構進行設計。
功能體系結構是從邏輯上描述tmn內部的功能分布。引入了一組標準的功能塊（functionalblock）和可能發(fā)生信息交換的參考點（referencepoints）。整個tmn系統(tǒng)即是各種功能塊的組合。
信息體系結構包括兩個方面：管理信息模型和管理信息交換。管理信息模型是對網(wǎng)絡資源及其所支持的管理活動的抽象表示，網(wǎng)絡管理功能即是在信息模型的基礎上實現(xiàn)的。管理信息交換主要涉及到tmn的數(shù)據(jù)通信功能和消息傳遞功能，即各物理實體和功能實體之間的通信。
物理體系結構是為實現(xiàn)tmn的功能所需的各種物理實體的組織結構。tmn功能的實現(xiàn)依賴于具體的物理體系結構，從功能體系結構到物理體系結構存在著映射關系。物理體系結構隨具體情況的不同而千差萬別。在物理體系結構和功能體系結構之間有一定的映射關系。物理體系結構中的一個物理塊實現(xiàn)了功能體系結構中的一個或多個功能塊，一個接口實現(xiàn)了功能體系結構中的一組參考點。
仿照osi網(wǎng)絡分層模型，itu-t進一步在tmn中引入了邏輯分層。如圖3所示：
tmn的邏輯分層是將管理功能針對不同的管理對象映射到事務管理層bml（businessmanagementlayer），業(yè)務管理層sml（servicemanagementlayer），網(wǎng)絡管理層nml（networkmanagementlayer）和網(wǎng)元管理層eml（elementmanagementlayer）。再加上物理存在的網(wǎng)元層nel（networkelementlayer），就構成了tmn的邏輯分層體系結構。從圖2-6可以看到，tmn定義的五大管理功能在每一層上都存在，但各層的側重點不同。這與各層定義的管理范圍和對象有關。
三、tmn開發(fā)平臺和開發(fā)工具
1．利用tmn的開發(fā)工具開發(fā)tmn的必要性
tmn的信息體系結構應用osi系統(tǒng)管理的原則，引入了管理者和的概念，強調在面向事物處理的信息交換中采用面向對象的技術。如前所述，tmn是高度強調標準化的網(wǎng)絡，故基于tmn標準的產品開發(fā)，其標準規(guī)范要求嚴格復雜，使得tmn的實施成為一項具有難度和挑戰(zhàn)性的工作；再加上osi系統(tǒng)管理專業(yè)人員的相對缺乏，因此，工具的引入有助于簡化tmn的開發(fā)，提高開發(fā)效率。目前比較流行的基于tmn標準的開發(fā)平臺有hpovdm、sunsem、ibmtmn平臺和dset的dsg及其系列工具。這些平臺可以用于開發(fā)全方位的tmn管理者和應用，大大降低tmn／q3應用系統(tǒng)的編程復雜性，并且使之符合開放系統(tǒng)互連（osi）網(wǎng)絡管理標準，這些標準包括高級信息模型定義語言gdm0，osi標準信息傳輸協(xié)議cmip，以及抽象數(shù)據(jù)類型定義語言asn.1。其中dset的dsg及工具系列除了具備以上功能外，還具有獨立于硬件平臺的優(yōu)點。下面將比較詳細論述dset的tmn開發(fā)工具及其在tmn開發(fā)中的作用。
2．dset的tmn開發(fā)工具的基本組成
dset的tmn開發(fā)工具從功能上來講可以構成一個平臺和兩大工具箱。一個平臺：分布式系統(tǒng)生成器dsg（distributedsystemgenerator）；兩個工具箱：管理者工具箱和工具箱。
分布式系統(tǒng)生成器dsg
dsg是用于頂層tcp／ip、osi和其它協(xié)議上構筑分布式并發(fā)系統(tǒng)的高級對象請求0rb。dsg將復雜的通信基礎設施和面向對象技術相結合，提供構筑分布式計算的軟件平臺。通信基礎設施支持分布式計算中通信域的通信要求。如圖4所示，它提供了四種主要的服務：透明遠程操作、遠程過程調用和消息傳遞、抽象數(shù)據(jù)服務及命名服務。借助于并發(fā)的面向對象框架，一個復雜的應用可以分解成一組相互通信的并發(fā)對象worker，除了支持例如類和多重繼承等重要的傳統(tǒng)面向對象特征外，為了構筑新的worker類，dsg也支持分布式對象。在一個開放系統(tǒng)中，一個worker可以和其它worker進行通信，而不必去關心它們所處的物理位置。
dsg提供給用戶用以開發(fā)應用的構造塊（buildingblock）稱為worker。一個worker可以有自己的控制線程，也可以和別的線程共享一個控制線程，每個worker都有自己的服務訪問點sap（serviceaccesspoint），通過sap與其它worker通信。worker是事件驅動的。在worker內部，由有限狀態(tài)機fsm（finitestatemachine〕定義各種動作及處理例程，dsg接受外部事件并分發(fā)到相應的動作處理例程進行處理。如圖5所示，獨占線程的此worker有三個狀態(tài)，兩個saps，并且每個sap的消息隊列中都有兩個事件。dsg環(huán)境通過將這些事件送到相應的事件處理程序中來驅動worker的有限狀態(tài)機。
worker是分布式的并發(fā)對象，dsg用它來支持面向對象的特點，如：類，繼承等等。worker由workerclass定義。worker可以根據(jù)需要由應用程序動態(tài)創(chuàng)建。在一個unix進程中可以創(chuàng)建的worker個數(shù)僅受內存的限制。
管理者工具箱由asn.c／c＋＋編譯器、cmip／rose協(xié)議和管理者代碼生成器mcg構成，如圖6所示。
其中的cmip／rose協(xié)議提供全套符合q3接口選用的osi七層協(xié)議棧實施。由于tmn在典型的電信環(huán)境中以面向對象的信息模型控制和管理物理資源，所有被管理的資源均被抽象為被管對象（m0），被管理系統(tǒng)中的幫助管理者通過mo訪問被管理資源，又根據(jù)itu-tm.3010建議：管理者與之間通過q3接口通信。為此管理者必須產生與通信的cmip請求。管理者代碼生成器讀取信息模型（gdmo文件和asn.1文件），創(chuàng)立代碼模板來為每個被定義的mo類產生cmip請求和cmip響應。由于所有cmip數(shù)據(jù)均由asn.1符號定義，而上層管理應用可能采用c／c++，故管理者應用需要包含asn.1數(shù)據(jù)處理代碼，管理者工具箱中的asnc／c++編譯器提供asn.1數(shù)據(jù)到c／c++語言的映射，并采用“預處理技術“生成asn.1數(shù)據(jù)的低級代碼，可見利用dset工具用戶只需編寫網(wǎng)管系統(tǒng)的信息模型和相關的抽象數(shù)據(jù)類型定義文件，然后利用dset的asnc／c++編譯器，管理者代碼生成器即可生成管理者部分代碼框架。
工具箱包括可硯化生成器vab、cmip翻譯器、asn.c／c++toolkit，其結構見圖7。用來開發(fā)符合管理目標定義指南gdmo和通用管理信息協(xié)議cmip規(guī)定的應用.使用dset獨具特色的工具箱的最大的好處就是更快、更容易地進行應用的開發(fā)。dset在應用的開發(fā)上為用戶做了大量的工作。
一個典型的gdmo／cm1p應用包括三個代碼模塊：
·、mit、mib的實施
·被管理資源的接口代碼
·后端被管理資源代碼
第一個模塊用于處理與mo實施。工具箱通過對過濾、特性處理、mo實例的通用支持，自動構作這一個模塊。dset的這一部分做得相當完善，用戶只需作少量工作即可完成本模塊的創(chuàng)建。對于mcreate、m-delete、m-get、m-cancel-get、m-set、m-set-confirmed、m-action、m-action-confirmed這些cmip請求，第一個模塊中包含有缺省的處理代碼框架。這些缺省代碼都假定管理者的cmip請求只與mo打交道。為了適應不同用戶的需求，dset工具箱又提供在缺省處理前后調用用戶程序的接入點（稱為userhooks）。當某cmip請求需與實際被管資源或數(shù)據(jù)庫打交道時，用戶可在相應的pre-或post-函數(shù)中加入自己的處理代碼。例如，當你需要在二層管理應用中發(fā)cmip請求，需望獲取實際被管資源的某屬性，而該屬性又不在相應mo中時你只需在gdmo預定義模板中為此屬性定義一pre-get函數(shù)，并在你自己的定制文件中為此函數(shù)編寫從實際被管設備取到該屬性值的代碼即可。dset的agent代碼在執(zhí)行每個cmip請求前都要先檢查用戶是否在gdmo預定義文件中為此清求定義了pre-函數(shù)，若是，則光執(zhí)行pre-函數(shù)，并根據(jù)返回值決定是否執(zhí)行缺省處理（pre-函數(shù)返回d-ok則需執(zhí)行缺省處理，否則agent向管理者返回正確或錯誤響應）。同樣當agent執(zhí)行完缺省處理函數(shù)時，也會檢查用戶是否為該請求定義了post-函數(shù)，若是則繼續(xù)執(zhí)行post-函數(shù)。至于agent與mo之間具體是如何實現(xiàn)通信的，用戶不必關心，因為dset已為我們實現(xiàn)了。用戶只需關心需要與設備交互的那一部分cmip請求，為其定制pre-／post函數(shù)即可。
第二個模塊實現(xiàn)mo與實際被管資源的通信。它的實現(xiàn)依賴于分布式系統(tǒng)生成器dsg所提供“網(wǎng)關處理單元”（gateway）、遠程過程調用（rpc）與消息傳遞機制及msl語言編譯器。通信雙方的接口定義由用戶在簡化的rose應用中定義，在dsg中也叫環(huán)境，該環(huán)境定義了雙方的所有操作和相關參數(shù)。dsg的ctx編譯器編譯ctx格式的接口定義并生成接口表。dsg的msl語言編譯器用以編譯分布式對象類的定義并生成事件調度表。采用dsg的網(wǎng)關作為mo與實際被管資源間的通信橋梁，網(wǎng)關與mo之間通過定義接口定義文件及各自的msl文件即可實現(xiàn)通信，網(wǎng)關與被管設備之間采用設備所支持的通信協(xié)議來進行通信，例如采用tcp／ip協(xié)議及socket機制實現(xiàn)通信。
第三個模塊對被管理資源進行實際處理。這一模塊根據(jù)第二個模塊中定義的網(wǎng)關與被管設備間的通信機制來實現(xiàn)，與工具沒有多大聯(lián)系。
四、tmn開發(fā)的關鍵技術
電信管理網(wǎng)技術蘊含了當今電信、計算機、網(wǎng)絡通信和軟件開發(fā)的最新技術，如osi開放系統(tǒng)互連技術、osi系統(tǒng)管理技術、計算機網(wǎng)絡技術及分布式處理、面向對象的軟件工程方法以及高速數(shù)據(jù)通信技術等。電信管理網(wǎng)應用系統(tǒng)的開發(fā)具有巨大的挑戰(zhàn)性。
工具的引入很大程度上減輕了tmn的開發(fā)難度。留給開發(fā)人員的最艱巨工作就是接口（interface）的信息建模。尤其是q3接日的信息建模問題。
q3接口是tmn接口的“旗艦”，q3接口包括通信模型和信息模型兩個部分，通信模型（0si系統(tǒng)管理）的規(guī)范制定的十分完善，并且工具在這方面所作的工作較多，因此，當我們設計和開發(fā)各種不同管理業(yè)務的tmn系統(tǒng)時，主要是采用一定的方法學，遵循一定的指導原則，針對不同電信領域的信息建模問題。
為什么說建模是tmn開發(fā)中的關鍵技術呢？從管理的角度而言，在那些先有國際標準（或事實上的標準），后有設備的情況下，是有可能存在一致性的信息模型的，例如目前sdh和七號信令網(wǎng)的tmn系統(tǒng)存在這樣的信息模型標準。但即使這樣，在這些tmn系統(tǒng)的實施過程，有可能由于管理需求的不同而對這些模型進行進一步的細化。在那些先有設備而后才有國際標準（或事實上的標準）的設備，而且有的電信設備就無標準而言，由于不同廠家的設備千差萬別，這種一致性的信息模型的制定是非常困難的。
例如，近年來標準化組織國際電信聯(lián)盟（itu-t）、歐洲電信標準組織（etsi）、網(wǎng)絡管理論壇（nmf）和atm論壇等相繼頒布了一些q3信息模型。但至今沒有一個完整的穩(wěn)定的交換機網(wǎng)元層的q3信息模型。交換機的q3信息模型提供了交換機網(wǎng)元的一個抽象的、一般的視圖，它應當包含交換機的管理的各個方面。但這是不可能的。因為隨著電信技術的不斷發(fā)展，交換機技術也在不斷的發(fā)展，交換機的類型不斷增加，電信業(yè)務不斷的引入。我們很難設計一個能夠兼容未來交換機的信息模型。如今的交換機已不再是僅僅提供電話的窄帶業(yè)務，而且也提供象isdn這樣的寬帶業(yè)務。交換機趨向寬帶窄帶一體化發(fā)展，因此交換機的q3信息模型是很復雜的，交換機q3信息建模任務是很艱巨的。
五、tmn管理者和的開發(fā)
下面結合我們的開發(fā)工作，探討一下tmn管理者和的開發(fā)。
1．管理者的開發(fā)
基于osi管理框架的管理者的實施通常被認為是很困難的事，通常，管理者可以劃分為三個部分。第一部分是位于人機之間的圖形用戶接口gui（graphicaluserinterfaces），接收操作人員的命令和輸入并按照一種統(tǒng)一的格式傳送到第二部分——管理功能。管理功能提供管理功能服務，例如故障管理，性能管理、配置管理、記費管理，安全管理及其它特定的管理功能。接收到來gui的操作命令，管理功能必須調用第三部分——cmsiapi來發(fā)送cmip請求到。cmisapi為管理者提供公共管理信息服務支持。
大多數(shù)的網(wǎng)管應用是基于unix平臺的，如solaris，aixandhp-ux。若gui是用x-window來開發(fā)的，那么gui和管理功能之間的接口就不存在了，從實際編程的的角度看，gui和管理功能都在同一個進程中。
上面的管理者實施方案盡管有許多優(yōu)點，但也存在著不足。首先是費用昂貴。所有的管理工作站都必須是x終端，服務器必須是小型機或大型機。這種方案比采用pc機作客戶端加上unix服務器的方案要昂貴得多。其次，擴展性不是很好，不同的管理系統(tǒng)的范圍是不同的，用戶的要求也是不一樣的，不是所有的用戶都希望在x終端上來行使管理職責。因此，pc機和調終端都應該向用戶提供。最后由于x-window的開發(fā)工具比在pc機上的開發(fā)工具要少得多。因此最終在我們的開發(fā)中，選擇了pc機作為管理工作站，sunultral作為服務器。
在實際工作中我們將管理者劃分為兩個部分——管理應用（managementapplication）和管理者網(wǎng)關（managergateway）。如圖8所示。
管理應用向用戶提供圖形用戶接口gui并接受用戶的命令和輸入，按照定義好的消息格式送往管理者網(wǎng)關，由其封裝成cmip請求，調用cmisapi發(fā)往。同時，管理者網(wǎng)關還要接收來自的響應消息和事件報告并按照一定的消息格式送往管理應用模塊。
但是這種方案也有缺點。由于管理應用和管理者網(wǎng)關的分離，前者位于pc機上，后者位于ultral工作站上。它們之間的相互作用須通過網(wǎng)絡通信來完成。它們之間的接口不再是一個參考點（referencepoint），而是一個物理上的接口，在電信管理網(wǎng)tmn中稱為f接口。迄今為止itu-t一直沒能制定出有關f接口的標準，這一部分工作留給了tmn的開發(fā)者。鑒于此，我們制定了管理應用和管理者網(wǎng)關之間通信的協(xié)議。
在開發(fā)中，我們選擇了pc機作為管理工作站，sunultral作為我們的管理者網(wǎng)關。所有的管理應用都在pc機上。開發(fā)人員可以根據(jù)各自的喜好來選擇不同開發(fā)工具，如java，vc++，vb，pb等。管理者網(wǎng)關執(zhí)行部分的管理功能并調用cmisapi來發(fā)送cmip請求，接收來自的響應消息和事件報告并送往相應的管理應用。
管理者網(wǎng)關的數(shù)據(jù)結構是通過編譯信息模型（gdmo文件和asn.1文件）獲得的。它基于dsg環(huán)境的。管理者網(wǎng)關必須完成下列轉換：
數(shù)據(jù)類型轉換：gui中的數(shù)據(jù)類型與asn.1描述的數(shù)據(jù)類型之間的相互轉換；
消息格式轉換：gui和管理者網(wǎng)關之間的消息格式與cmip格式之間的相互轉換；
協(xié)議轉換：tcp／ip協(xié)議與osi協(xié)議之間的相互轉換。
這意味著管理者網(wǎng)關接收來自管理應用的消息。將其轉換為asn.1的數(shù)據(jù)格式，并構造出cmis的參數(shù)，調用cmisapi發(fā)送cmip請求。反過來，管理者收到來自的消息，解讀cmis參數(shù)，構造消息格式，然后送往gui。gui和管理者網(wǎng)關之間的消息格式是由我們自己定義的。由于管理應用的復雜性，消息格式的制定參考了cmis的參數(shù)定義和asn.1的數(shù)據(jù)類型。
管理者網(wǎng)關是采用多線程（multi-thread）編程來實現(xiàn)的。
2．的開發(fā)
的結構如圖9所示。
為了使部分的設計和實現(xiàn)模塊化、系統(tǒng)化和簡單化，將agent分成兩大模塊——通用模塊和mo模塊——進行設計和實現(xiàn)。如圖所示，通用agent向下只與mo部分直接通信，而不能與被管資源mr直接進行通信及操作，即通用agent將manager發(fā)來的cmip請求解析后投遞給相應的m0，并從mo接收相應的應答信息及其它的事件報告消息。
的作用是代表管理者管理mo。利用工具的支持，采用面向對象的技術，分為八個步驟進行agent的設計和實現(xiàn)，這八個步驟是：
第一步：對信息模型既gdmo文件和asn.1文件的理解，信息模型是tmn系統(tǒng)開發(fā)的基礎和關鍵。特別是對信息模型中對象類和其中各種屬性清晰的認識和理解，對于實際的tmn系統(tǒng)來說，其信息模型可能很復雜，其中對象類在數(shù)量上可能很多。也就是說，在設計和實現(xiàn)agent之前，必須作到對mo心中有數(shù)。
第二步：被管對象mo的定制。這一部分是agent設計和實現(xiàn)中的關鍵部分，工具對這方面的支持也不是很多，特別是涉及到mo與mr之間的通信，更為復雜，故將mo專門作為一個模塊進行設計和實現(xiàn)mo和mr之間的通信以及數(shù)據(jù)和消息格式的轉換問題，利用網(wǎng)關原理設計一個網(wǎng)關來解決。
第三步：創(chuàng)建內置的m0。所謂內置mo就是指在系統(tǒng)運行時，已經(jīng)存在的物理實體的抽象。為了保證能對這些物理實體進行管理，必須將這些被管對象的各種固有的屬性值和操作預先加以定義。
第四步：創(chuàng)建外部服務訪問點sap。如前所述，tmn系統(tǒng)中各個基于分布式處理的worker之間通過sap進行通信，所以要為agent與管理者manager之間、agent與網(wǎng)關之間創(chuàng)建sap。
第五步：sap同內置mo的捆綁注冊。由于在tmn系統(tǒng)中，agent的所有操作是針對mo的，即所有的cmip請求經(jīng)解析后必須送到相應的m0，而基于dsg平臺的worker之間的通信是通過sap來實現(xiàn)的。因而，在系統(tǒng)處理過程中，當進行信息的傳輸時，必須知道相應mo的sap，所以，在agent的設計過程中，必須為內置mo注冊某一個sap。
第六步：agent配置。對agent中有些參數(shù)必須加以配置和說明。如隊列長度、流量控制門限值、agent處理單元組中worker的最大／最小數(shù)目。報告的處理方式、同步通信方式中超時門限等。
第七步：agent用戶函數(shù)的編寫，如agentworker初始化函數(shù)、子函數(shù)等的編寫。
第八步：將所有函數(shù)編譯，連接生成可運行的agent。
mo模塊是agent設計中的一個重要而又復雜的部分。這是由于，一方面工具對該部分的支持不是很多：另一方面，用戶的大部分處理函數(shù)位于這一部分；最主要的還在于它與被管資源要跨平臺，在不同的環(huán)境下進行通信。mo模塊的設計思想是在mo和mr之間設計一個網(wǎng)關（gateway），來實現(xiàn)兩者之間的消息、數(shù)據(jù)、協(xié)議等轉換。
mo部分的主要功能是解析，執(zhí)行來自管理者的cmip請求，維持各mo的屬性值同被管資源的一致性，生成cmip請求結果，并上報通用agent模塊，同時與mr通信，接收和處理來自mr的事件報告信息，并轉發(fā)給通用agent。
mo部分有大量的用戶定制工作。工具只能完成其中一半的工作，而另一半工作都需要用戶自己去定制。用戶定制分為兩大類；
第一類是pre-／post-函數(shù)。pre-／post-函數(shù)的主要功能是在agent正式處理cmip請求之前／之后與被管資源打交道，傳送數(shù)據(jù)到mr或從mr獲取數(shù)據(jù)并做一些簡單的處理。通過對這些pre-／post-函數(shù)的執(zhí)行，可以確保能夠真實地反映出被管資源的運行狀態(tài)。pre-／post-函數(shù)分為兩個層次：mo級別和屬性級別。mo級別層次較高，所有對該對象類的cmip操作都會調用mo級別的pre-／post-函數(shù)。屬性級別層次低，只有對該屬性的cmip操作才會調用這些函數(shù)。dset工具只提供了pre-／post-函數(shù)的人口參數(shù)和返回值，具體的代碼需要完全由用戶自己編寫。由于agent與被管資源有兩種不同的通信方式，不同的方式會導致不同的編程結構和運行效率，如果是同步方式，編程較為簡單，但會阻塞被管資源，適合于由大量數(shù)據(jù)返回的情況。異步方式不會阻塞被管資源，但編程需要作特殊處理，根據(jù)不同的返回值做不同的處理，適合于數(shù)據(jù)不多的情況，在選擇通信方式時還要根據(jù)mo的實現(xiàn)方式來確定。比如，mo若采用doer來實現(xiàn)，則只能用同步方式。
第二類是動作、事件報告和通知的處理，動作的處理相對比較容易，只需考慮其通信方式采用同步還是異步方式。對事件報告和通知的處理比較復雜。首先，需要對事件進行分類，對不同類別的事件采用不同的處理方法，由哪一個事件前向鑒別器efd（eventforwardingdiscriminator）來處理等等。比如，告警事件的處理就可以單獨成為一類。其次，對每一類事件需要確定相應的efd的條件是什么，哪些需要上報管理應用，哪些不需要。是否需要記入日志，這些日志記錄的維護策略等等。
除了這兩類定制外，mo也存在著優(yōu)化問題。比如mo用worker還是doer來實現(xiàn)，通信方式采用同步還是異步，面向連接還是無連接等等，都會影響整個的性能。
如果mo要永久存儲，我們采用文件方式。因為目前dset的工具只支持versant、odi這兩種面向對象數(shù)據(jù)庫管理系統(tǒng)oodbms，對于0racle，sybase等數(shù)據(jù)庫的接口還需要用戶自己實現(xiàn)。mo定制的工作量完全由信息模型的規(guī)模和復雜程度決定，一個信息模型的對象類越多，對象之間的關系越復雜（比如一個對象類中的屬性改變會影響別的類），會導致定制工作的工作量和復雜程度大大增加。
者agent在執(zhí)行管理者發(fā)來的cmip請求時必須保持與被管資源mr進行通信，將manager傳送來的消息和數(shù)據(jù)轉發(fā)給mr，并要從mr獲取必要的數(shù)據(jù)來完成其操作，同時，它還要接收來自mr的事件報告，并將這些事件上報給manager。
由上述可知，與被管資源mr之間的通信接口實際上是指mo與mr之間的通信接口。大部分mo是對實際被管資源的模擬，這些mo要與被管資源通信。若讓這些mo直接與被管資源通信，則存在以下幾個方面的弊端：
·由于mo模塊本身不具備錯誤信息檢測功能（當然也可在此設計該項功能，但增加了mo模塊的復雜性），如果將上向發(fā)來的所有信息（包括某些不恰當?shù)男畔ⅲ┤哭D發(fā)給mr，不僅無此必要，而且增加了數(shù)據(jù)通信量；同理mr上發(fā)的信息也無必要全部發(fā)送給mo。
·當被管資源向mo發(fā)消息時，由于mit對于被管資源來說是不可知的，被管資源不能確定其相應mo在mit中所處的具體位置，從而也就無法將其信息直接送到相應的mo，因而只能采用廣播方式發(fā)送信息。這樣一來，每當有消息進入mo模塊時，每個mo都要先接收它，然后對此消息加以判斷，看是否是發(fā)給自己的。這樣一方面使編程復雜化，使軟件系統(tǒng)繁雜化，不易控制，調試困難；另一方面也使通信開銷增大。
·mo直接與被管資源通信，使得系統(tǒng)在安全性方面得不到保障，在性能方面也有所下降，為此，采用計算機網(wǎng)絡中中網(wǎng)關（gateway）的思想，在mo與被管資源建立一個網(wǎng)關，即用一個gatewayworker作為mo與被管資源通信的媒介。網(wǎng)關在的進程處理中起到聯(lián)系被管資源與mo之間的“橋梁”作用。
六、總結與展望
q3接口信息建模是tmn開發(fā)中的關鍵技術。目前，各標準化組織針對不同的管理業(yè)務制定和了許多信息模型。這些模型大部分是針對網(wǎng)元層和網(wǎng)絡層，業(yè)務層和事務層的模型幾乎沒有，還有相當?shù)臉藴驶ぷ髡诶^續(xù)研究。業(yè)務層和事務層的模型是將來研究的重點。
除了q3接口外，tmn的接口還包括x，f，qx接口。它們的q3接口相同也包括通信模型和信息模型兩個部分。各標準化組織幾乎沒有針對這些接口的規(guī)范。f接口和具體的一個tmn系統(tǒng)的實施密切相關，沒有必要對其的通信模型和信息模型進行規(guī)范化。qx是不完善的q3接口，它是非標準的廠家專用的q接口，雖然在管理系統(tǒng)的實施中，很多產品采用qx接口作為q3接口的過渡，但是隨著標準化進程的推進，qx接口將逐步被拋棄。電信工業(yè)的變化日新月異，寬帶網(wǎng)絡使得分布系統(tǒng)互連成為可能，使得不同的電信服務公司和運營公司相互競爭、相互合作來向用戶提供服務。在這種環(huán)境下，整個電信網(wǎng)絡管理將涉及到不同的組織以及它們的管理系統(tǒng)。基于tmn的多域管理（tmn-basedmulti-domainmanagement）將成為未來電信網(wǎng)管的重要研究方向。x接口位于兩個tmn系統(tǒng)之間，對它研究是基于tmn的多域管理系統(tǒng)的重點。
tmn有技術上的先進、強調公認的標準和接口等優(yōu)點。但它也有目標太大、抽象化要求太高、信息模型的標準化進程太慢、osi滿協(xié)議棧的效率不高等問題。tmn自身需要進一步發(fā)展。在網(wǎng)絡管理技術方面，除了tmn一種體系結構以外，還有itu&iso的開放分布處理（odp），osf的分布處理和管理環(huán)境（dce／dme），nmf的omnipoint，omg的公共對象請求體系結構（corba）以及tina-c的電信信息網(wǎng)絡體系結構（tina）。目前，corba技術越來越被電信、網(wǎng)絡部門接受和采用。corba體系結構是對象管理組織omg為解決分布式處理環(huán)境中，硬件和軟件系統(tǒng)的互連而提出的一種解決方案。corba適用于業(yè)務層和事務層的管理應用。對于下幾層（網(wǎng)元層、網(wǎng)元管理層和網(wǎng)絡管理層）而言，還沒有比tmn更好的體系結構。tina體系結構是基于分布式計算，面向對象以及電信和計算機業(yè)界的其它和標準，如odp，in，tmn和corba；它將電信業(yè)務和管理業(yè)務綜合到同一種體系結構中，是電信業(yè)務與電信網(wǎng)絡技術無關，從而使電信業(yè)務的開放與管理不受多廠商設備的影響。雖然tina處于發(fā)展中，還不很成熟，但它是未來電信體系結構的最終方向。
