1 引言
    層之間的接口是網(wǎng)絡(luò)管理系統(tǒng)設(shè)計和實現(xiàn)的關(guān)鍵之一，接口直接影響網(wǎng)絡(luò)管理系統(tǒng)的通信效率、管理功能和系統(tǒng)的可擴展性。目前傳統(tǒng)面向設(shè)備網(wǎng)絡(luò)管理系統(tǒng)中，網(wǎng)絡(luò)層與下層之間的接口通常是標準化的SNMP(Simple Network Man-agement Protocol)接口或CMIP(Common Management Infor-mation Protocol)接口或Q3接口或開發(fā)商提供的專用接口。與傳統(tǒng)的面向設(shè)備網(wǎng)絡(luò)管理系統(tǒng)不同，面向業(yè)務(wù)的網(wǎng)絡(luò)管理以網(wǎng)絡(luò)業(yè)務(wù)為被管對象，其管理對象和管理功能均以網(wǎng)絡(luò)業(yè)務(wù)為中心，而不再以網(wǎng)絡(luò)設(shè)備為出發(fā)點進行設(shè)計和開發(fā)，網(wǎng)絡(luò)設(shè)備層不可能也不需要直接向業(yè)務(wù)層提供統(tǒng)一的信息格式和統(tǒng)一的接口。
    而在目前的面向業(yè)務(wù)的網(wǎng)絡(luò)管理系統(tǒng)中，系統(tǒng)設(shè)計一般遵循分層的設(shè)計方法，即從上往下依次是業(yè)務(wù)層、網(wǎng)絡(luò)層和網(wǎng)元層。網(wǎng)絡(luò)業(yè)務(wù)管理處于業(yè)務(wù)層，它還必須得到網(wǎng)絡(luò)層的服務(wù)支持，網(wǎng)絡(luò)層是網(wǎng)絡(luò)業(yè)務(wù)管理的基礎(chǔ)和支撐，業(yè)務(wù)層需要對網(wǎng)絡(luò)層發(fā)布相應(yīng)的業(yè)務(wù)管理任務(wù)，通過收集網(wǎng)絡(luò)層提供的相關(guān)信息，推斷網(wǎng)絡(luò)業(yè)務(wù)的狀態(tài)，進而進行網(wǎng)絡(luò)業(yè)務(wù)管理。但目前，網(wǎng)絡(luò)層向上提供的信息還沒有統(tǒng)一的格式，也沒有統(tǒng)一的接口規(guī)范。因此，一方面需抽象千變?nèi)f化網(wǎng)絡(luò)業(yè)務(wù)，從而屏蔽上層各種管理業(yè)務(wù)的差異性，同時需規(guī)范網(wǎng)絡(luò)層向上層提供的信息格式，從而在網(wǎng)絡(luò)層和業(yè)務(wù)層之間建立一個統(tǒng)一規(guī)范的接口。
    借鑒主動網(wǎng)絡(luò)技術(shù)和電信網(wǎng)絡(luò)業(yè)務(wù)管理的先進思想，提出一種基于主動網(wǎng)絡(luò)技術(shù)的面向業(yè)務(wù)管理模型，并開發(fā)一個基于主動網(wǎng)絡(luò)技術(shù)的面向業(yè)務(wù)管理原型系統(tǒng)，在該系統(tǒng)中，在網(wǎng)絡(luò)層和業(yè)務(wù)層之間設(shè)計和實現(xiàn)一個統(tǒng)一接口層，使面向業(yè)務(wù)的網(wǎng)絡(luò)管理系統(tǒng)的網(wǎng)絡(luò)層和業(yè)務(wù)層能夠方便地通信，同時提高網(wǎng)管系統(tǒng)的可擴展性。

2 業(yè)務(wù)的抽象
    這里可將計算機網(wǎng)絡(luò)應(yīng)用理解為網(wǎng)絡(luò)服務(wù)，而將網(wǎng)絡(luò)服務(wù)理解為網(wǎng)絡(luò)業(yè)務(wù)，將業(yè)務(wù)定義為由一組網(wǎng)絡(luò)層功能支持的面向終端用戶的網(wǎng)絡(luò)應(yīng)用。面向?qū)ο?/strong>技術(shù)在描述被管對象方面具有很大優(yōu)勢，因為面向?qū)ο蟮姆治龇椒ㄊ抢妹嫦驅(qū)ο蟮男畔⒔８拍?如實體、關(guān)系、屬性等)，同時運用封裝、繼承、多態(tài)等機制構(gòu)造模擬現(xiàn)實系統(tǒng)的方法。因此，在將網(wǎng)絡(luò)業(yè)務(wù)作為被管對象時，也應(yīng)采用相同的方法進行抽象。利用面向?qū)ο蠹夹g(shù)，提出一套較為完整的業(yè)務(wù)抽象原則、抽象方法、抽象粒度、抽象等級、業(yè)務(wù)描述方法等。
2．1 網(wǎng)絡(luò)業(yè)務(wù)的抽象原則、粒度和等級
    在進行網(wǎng)絡(luò)業(yè)務(wù)抽象時，應(yīng)遵循如下原則：(1)抽象出來的業(yè)務(wù)應(yīng)該能夠支撐完整的用戶功能需求；(2)對業(yè)務(wù)管理而言沒有顯著意義的、網(wǎng)絡(luò)提供的其它業(yè)務(wù)可以不抽象為網(wǎng)絡(luò)管理業(yè)務(wù)對象；(3)應(yīng)該遵循統(tǒng)一性，一致性的原則，力求抽象的業(yè)務(wù)具備可重用性，兼容性?？傊?，在業(yè)務(wù)抽象時，需充分考慮業(yè)務(wù)對象是否是用戶所關(guān)心的、對用戶是否具有管理的意義、對用戶是否能夠支撐完整的管理功能需求。
    業(yè)務(wù)的粒度對管理功能子模塊的劃分以及與網(wǎng)元的影射有直接影響。粒度太大容易抽象，但不利于功能模塊的劃分和與網(wǎng)元的影射，粒度太小，則增加系統(tǒng)的復(fù)雜性和實現(xiàn)難度。把握粒度的原則是支持功能的完整性，如果一個網(wǎng)絡(luò)功能不能完成完整的用戶功能需求，就不定義為一個管理業(yè)務(wù)對象。例如。E-mail業(yè)務(wù)需要檢驗用戶的身份和口令，然而身份認證功能對用戶而言，不是使用網(wǎng)絡(luò)的目的，而是E-mail業(yè)務(wù)所包含的安全功能，因此不被定義為獨立的業(yè)務(wù)。對網(wǎng)絡(luò)業(yè)務(wù)的抽象應(yīng)遵循統(tǒng)一性、一致性原則，使抽象的網(wǎng)絡(luò)業(yè)務(wù)之間盡量不出現(xiàn)重疊、模棱兩可的情況。利用面向?qū)ο蠹夹g(shù)，將業(yè)務(wù)進行抽象、封裝，并在相關(guān)的業(yè)務(wù)之間建立繼承關(guān)系，使定義的屬性和管理功能在最大的范圍內(nèi)能夠重用。例如，E-mail業(yè)務(wù)就可以分為兩種，一種是基于Web的郵件，一種是利用POP和SMTP協(xié)議實現(xiàn)的郵件功能。
2．2 業(yè)務(wù)抽象實例
    根據(jù)上述業(yè)務(wù)抽象的原則、粒度和等級，可采用面向?qū)ο蟮姆椒▽I(yè)務(wù)進行抽象。從面向?qū)ο蟮挠^點來看，網(wǎng)絡(luò)業(yè)務(wù)可視為一個抽象類，作為各種具體網(wǎng)絡(luò)業(yè)務(wù)的公共父類。因為網(wǎng)絡(luò)業(yè)務(wù)類定義的特性(屬性和服務(wù))每個業(yè)務(wù)子類都能繼承。例如，F(xiàn)TP、Telnet、E-mail等業(yè)務(wù)都是網(wǎng)絡(luò)業(yè)務(wù)Ser-vice類的子類。而E-mail業(yè)務(wù)又分為兩種，一種是基于Web的郵件，一種是利用POP和SMTP協(xié)議實現(xiàn)的郵件功能，這兩種郵件業(yè)務(wù)雖然是利用不同方式提供給用戶的，但在用戶的視角中，它們提供的是相同的服務(wù)，因此，既應(yīng)該抽取它們的共同之處，建立郵件業(yè)務(wù)對象；又應(yīng)該強調(diào)它們各自的特點。分別建立相應(yīng)的業(yè)務(wù)子類對象進行管理，如圖1所示。

    在面向業(yè)務(wù)的網(wǎng)絡(luò)管理系統(tǒng)，把可以存儲、管理和操作的所有業(yè)務(wù)用一個統(tǒng)一的抽象名字“業(yè)務(wù)對象”標記。實際上，業(yè)務(wù)對象就是對被管對象和相關(guān)支撐資源的抽象。按照面向?qū)ο蠹夹g(shù)的思想，將具有相同管理操作、屬性、特性組、通知和行為特性的業(yè)務(wù)對象組合成一個“業(yè)務(wù)對象類”?！皹I(yè)務(wù)對象類”只是一個虛的概念類，它僅描述類的類別。業(yè)務(wù)對象類可以派生子類，子類可繼承父類的各種特征量，如圖2所示。當一個具體的業(yè)務(wù)實體作為某類業(yè)務(wù)對象存在(創(chuàng)建)時，該實體就被稱為業(yè)務(wù)對象實例。對于接口的實現(xiàn)，在網(wǎng)絡(luò)層和業(yè)務(wù)層進行交互時，更多需考慮對象實例的屬性，因此首先需描述對象實例的屬性。對象實例的屬性主要包含屬性名字、屬性值、對屬性的操作特性等。同一個類中的屬性名應(yīng)具有唯一標識性。屬性值可通過內(nèi)在的系統(tǒng)手段、網(wǎng)絡(luò)活動或管理活動讀取和修改，但修改活動受屬性操作特性的限制。在定義業(yè)務(wù)對象時可以規(guī)定某些屬性對外部系統(tǒng)是只讀的，也可規(guī)定屬性值改變的條件等。一般每個業(yè)務(wù)對象擁有多個屬性。為方便網(wǎng)絡(luò)業(yè)務(wù)的管理。為業(yè)務(wù)對象定義許多可見屬性，如業(yè)務(wù)名稱、業(yè)務(wù)類型、業(yè)務(wù)響應(yīng)時間、業(yè)務(wù)接入時間、業(yè)務(wù)活動訪問計數(shù)、業(yè)務(wù)數(shù)據(jù)吞吐量、業(yè)務(wù)通路延遲、業(yè)務(wù)通路延遲抖動、業(yè)務(wù)通路丟包率等。如圖2所示。

3 統(tǒng)一接口的設(shè)計
    處于業(yè)務(wù)層的網(wǎng)絡(luò)業(yè)務(wù)管理需得到網(wǎng)絡(luò)層的服務(wù)支持，因此，網(wǎng)絡(luò)層和業(yè)務(wù)層間通過接口進行交互，業(yè)務(wù)層需對網(wǎng)絡(luò)層發(fā)布相應(yīng)的業(yè)務(wù)管理任務(wù)。通過收集網(wǎng)絡(luò)層提供的相關(guān)信息。推斷網(wǎng)絡(luò)業(yè)務(wù)狀態(tài)，進而管理網(wǎng)絡(luò)業(yè)務(wù)。但目前網(wǎng)絡(luò)層向上提供的信息還沒有統(tǒng)一格式，也沒有統(tǒng)一的接口規(guī)范。由于網(wǎng)管系統(tǒng)中的各種設(shè)備在邏輯上和物理上都分布在整個被管網(wǎng)絡(luò)中，并且經(jīng)常處于動態(tài)變化中，而CORBA很好地結(jié)合面向?qū)ο?/strong>和分布處理技術(shù)，其體系結(jié)構(gòu)很好地解決了對象的可重用性、可移植性和互操作性等問題。它基于事件服務(wù)的主動服務(wù)PUSH和PULL技術(shù)，可實時收集各種告警信息、進行信息處理；同時對象之間還可以通過互相調(diào)用對方提供的服務(wù)，有分布透明的支持，業(yè)務(wù)對象和組件還可以在網(wǎng)絡(luò)內(nèi)動態(tài)遷移。為此，根據(jù)上述對業(yè)務(wù)對象的抽象、對業(yè)務(wù)對象屬性的描述以及面向業(yè)務(wù)網(wǎng)絡(luò)管理的分層結(jié)構(gòu)，同時考慮到接口的實現(xiàn)，引入CORBA(Common Object Re-quest Architecture，公共對象請求代理體系結(jié)構(gòu))在業(yè)務(wù)層和網(wǎng)絡(luò)層之間設(shè)計一種統(tǒng)一的規(guī)范接口，如圖3所示。

    在此規(guī)范接口方式中，各個子管理層間的通信方式有：
    (1)CORBA／IDL接口即采用CORBA作為通信平臺，管理層間的接口信息模型采用IDL(Interface Definition Lan-guage，接口定義語言)描述，使用C／S交互方式。該接口存在于業(yè)務(wù)管理層和網(wǎng)絡(luò)業(yè)務(wù)層之間，各實體成員間的通信采用CORBA/IDL作為進程間的通信方式。
    (2)SNMP接口即采用SNMP協(xié)議作為傳送信息的方式。層次間的接口信息模型采用SMI／ASN．1的描述。使用管理者／代理的交互方式。這種接口存在于網(wǎng)絡(luò)管理層和網(wǎng)元管理層以及網(wǎng)元管理層和網(wǎng)元之間，是標準化的接口。
    (3)專用接口這種接口只存在于網(wǎng)元管理層和網(wǎng)元間，一般由廠家提供。

4 接口描述和實現(xiàn)
    接口通過消息的封裝來實現(xiàn)。在面向業(yè)務(wù)的網(wǎng)絡(luò)管理體系結(jié)構(gòu)中，為管理網(wǎng)絡(luò)業(yè)務(wù)，定義一種協(xié)議數(shù)據(jù)單元PDU(Protocol Data Unit)描述業(yè)務(wù)數(shù)據(jù)。PDU中包含的域有serID、serType、serName、serTime、serAddress、dataLong、 serData，各個域的含義如下serID：表示業(yè)務(wù)的編號；serType表示業(yè)務(wù)的類型，不同的編碼表示與業(yè)務(wù)有關(guān)的故障、性能、配置、安全、計費等5項功能；serName表示業(yè)務(wù)的名稱；serTime表示業(yè)務(wù)管理任務(wù)得到相應(yīng)的時間；serAddress表示發(fā)出管理業(yè)務(wù)任務(wù)的IP地址；dataLong表示后面數(shù)據(jù)的總長度，以Byte為單位；serData表示與該業(yè)務(wù)有關(guān)的各個屬性的值，包含圖3中描述的屬性值；業(yè)務(wù)數(shù)據(jù)包封裝在UDP中，前面依次加上UDP的頭結(jié)構(gòu)：2字節(jié)的UDP源端口號、2字節(jié)的UDP目的端口號、2字節(jié)校驗和、2字節(jié)的信息長度。
    用CORBA的IDL語言定義接口如下：

   

    把IDL模式轉(zhuǎn)換為JAVA源代碼后，生成serviceMes-sageStub．java和serviceMessage Operation．java等多個文件。業(yè)務(wù)數(shù)據(jù)包封裝在UDP的數(shù)據(jù)項中。業(yè)務(wù)層中客戶端的樁程序把用戶的請求進行編碼、發(fā)送到對象實現(xiàn)端．并對接收到的處理結(jié)果進行解碼，將結(jié)果返回給用戶。網(wǎng)絡(luò)層中服務(wù)端的框架程序?qū)τ脩粽埱筮M行解碼，定位所要求的對象方法并執(zhí)行，將執(zhí)行結(jié)果或異常信息編碼后送回業(yè)務(wù)層中的用戶。
    在業(yè)務(wù)層的客戶端要求一些特定的代碼得到對遠程對象的引用，一旦客戶代碼擁有對遠程對象的引用，調(diào)用遠程對象的方法就和涮用本地方法一樣。網(wǎng)絡(luò)層服務(wù)端的代碼必須定義類并實例化類的遠程對象，之后，在服務(wù)端要求提供一些特定的代碼登記對象并導(dǎo)出方法給客戶，則這些被導(dǎo)出的方法就可被遠程調(diào)用?？蛻舳说拇a和服務(wù)端的代碼都必須訪問以上定義的IDL文件，使客戶和服務(wù)器相聯(lián)系。

5 結(jié)論
    詳細討論與接口設(shè)計和實現(xiàn)相關(guān)的業(yè)務(wù)對象的抽象方法，并詳細描述業(yè)務(wù)對象的屬性。根據(jù)面向業(yè)務(wù)管理的需要，在業(yè)務(wù)層和網(wǎng)絡(luò)層之間設(shè)計一個統(tǒng)一的接口層，并闡述該接口的描述和實現(xiàn)。該接口層在基于主動網(wǎng)絡(luò)技術(shù)的面向業(yè)務(wù)網(wǎng)絡(luò)管理原型系統(tǒng)中得到應(yīng)用，應(yīng)用結(jié)果表明該接口層能夠使業(yè)務(wù)層與網(wǎng)絡(luò)層方便地交互，提高了網(wǎng)管系統(tǒng)的可擴展性。同時由于該接口層屏蔽上層業(yè)務(wù)的差異性，對下層提供的數(shù)據(jù)格式具有透明性，可作為其他面向業(yè)務(wù)網(wǎng)絡(luò)管理系統(tǒng)的通用基礎(chǔ)設(shè)施。