基于ＡＣＥ的網(wǎng)元文檔服務(wù)的設(shè)計(jì)與實(shí)現(xiàn)

摘 要：以ACE為底層平臺(tái)，以3G無(wú)線網(wǎng)管系統(tǒng)為應(yīng)用背景，設(shè)計(jì)并實(shí)現(xiàn)了網(wǎng)元文檔服務(wù)。網(wǎng)元文檔采用XML格式存儲(chǔ)，以動(dòng)態(tài)更新方式生成，以FTP方式和中轉(zhuǎn)方案上傳，滿足了用戶需求；提供了TMN標(biāo)準(zhǔn)中各模塊對(duì)網(wǎng)元信息遺漏的解決方案。

關(guān)鍵詞：網(wǎng)元文檔； 后管理模塊； 自適配通信環(huán)境； 第三代移動(dòng)通信系統(tǒng)

中圖分類號(hào)：TP393.07文獻(xiàn)標(biāo)志碼：A

文章編號(hào)：1001—3695(2007)03—0206—03

隨著第三代移動(dòng)通信系統(tǒng)(3G)技術(shù)的日益成熟和商務(wù)化，3G網(wǎng)絡(luò)管理系統(tǒng)也成為移動(dòng)通信網(wǎng)絡(luò)建設(shè)的焦點(diǎn)。3G網(wǎng)絡(luò)管理主要集中在對(duì)網(wǎng)絡(luò)環(huán)境的管理和對(duì)網(wǎng)絡(luò)設(shè)備的管理上[1，2]。這些網(wǎng)絡(luò)設(shè)備作為網(wǎng)絡(luò)管理系統(tǒng)中的網(wǎng)元 (NE) ，成為系統(tǒng)管理的基本對(duì)象。

對(duì)網(wǎng)元的管理重點(diǎn)在于對(duì)通信網(wǎng)絡(luò)中網(wǎng)元的配置、性能、軟件、告警、安全等信息進(jìn)行監(jiān)測(cè)和控制[3]。然而這些模塊各有側(cè)重，還不能提供足夠的網(wǎng)元信息。隨著網(wǎng)管規(guī)模的擴(kuò)大，許多以前不需要網(wǎng)管管理的信息也迫切需要網(wǎng)管的參與。大量被管設(shè)備的生產(chǎn)信息、維修信息，對(duì)于實(shí)現(xiàn)被管設(shè)備的遠(yuǎn)程維修、維護(hù)具有重要的參考價(jià)值。而這些信息是通用網(wǎng)管所不能提供的，于是網(wǎng)元文檔的需求應(yīng)運(yùn)而生。網(wǎng)元文檔描述了設(shè)備的基本信息、連接信息、模塊信息、配置信息、對(duì)端信息、版本信息、機(jī)框信息、機(jī)槽信息、單板信息等。其中單板信息包括了單板的生產(chǎn)信息、維修信息等。網(wǎng)元文檔服務(wù)就是要把網(wǎng)管系統(tǒng)所管理網(wǎng)元的這些信息呈現(xiàn)給用戶。文中以ACE為底層平臺(tái)，設(shè)計(jì)并實(shí)現(xiàn)了3G無(wú)線網(wǎng)管系統(tǒng)的網(wǎng)元文檔服務(wù)。網(wǎng)元文檔服務(wù)的提出與設(shè)計(jì)同時(shí)也豐富了TMN（Telecommunications Management Network）的知識(shí)框架，完善了其理論體系。

ACE（Adapter Communication Environment，自適配通信環(huán)境）是可以自由使用、開放源碼的面向?qū)ο髽?gòu)架。ACE提供了一組豐富的可復(fù)用C++包裝外觀和構(gòu)架組件，可跨越多種平臺(tái)完成通用的通信軟件任務(wù)[4]。網(wǎng)元文檔服務(wù)使用了ACE提供的通信組件和線程控制組件，保證了開發(fā)的效率和質(zhì)量。

1 網(wǎng)元文檔服務(wù)的設(shè)計(jì)與實(shí)現(xiàn)

1.1 網(wǎng)元文檔服務(wù)功能需求

網(wǎng)元文檔功能需求有如下特點(diǎn)：①主要功能。將網(wǎng)管系統(tǒng)所管理的所有網(wǎng)元文檔收集到用戶端。②內(nèi)容的可擴(kuò)展性。網(wǎng)元文檔內(nèi)容沒(méi)有統(tǒng)一的業(yè)界標(biāo)準(zhǔn)，因此其屬性內(nèi)容應(yīng)該允許擴(kuò)充。③任務(wù)量大。用戶往往要成批操作，經(jīng)常對(duì)數(shù)百個(gè)網(wǎng)元請(qǐng)求生成網(wǎng)元文檔。在完成上述要求的同時(shí)，要求系統(tǒng)滿足效率性和可靠性。

1.2 網(wǎng)元文檔服務(wù)的設(shè)計(jì)思想

如圖1所示，GUI接收用戶請(qǐng)求，并顯示返回的結(jié)果信息。

圖1 網(wǎng)元文檔服務(wù)框架

網(wǎng)元文檔服務(wù)運(yùn)行在服務(wù)器上，它接收GUI發(fā)送來(lái)獲取網(wǎng)元文檔的請(qǐng)求，并將該請(qǐng)求轉(zhuǎn)換成MML（Man Machine Language）命令格式，通過(guò)適配層下發(fā)到BAM（Back Administrator Moudle）；另外接收BAM反饋回來(lái)的報(bào)文，包括成功/失敗信息、任務(wù)進(jìn)度信息等，并將處理后的信息發(fā)送到用戶界面。服務(wù)器與用戶界面及服務(wù)器內(nèi)部服務(wù)與適配層的交互通過(guò)CORBA[5]接口實(shí)現(xiàn)。

適配層用于屏蔽不同網(wǎng)元之間報(bào)文格式之間的差異。適配層的存在使得呈現(xiàn)給服務(wù)器內(nèi)部服務(wù)的是統(tǒng)一的報(bào)文格式。常用的通信協(xié)議有MML命令方式、Bin方式、BinMML方式等。由于不同的通信協(xié)議并不影響主題的開展，在接下來(lái)的討論中，將以MML命令報(bào)文作為適配層與BAM及BAM與網(wǎng)元之間的通信協(xié)議。

BAM接收適配層的命令，進(jìn)行相應(yīng)解析；發(fā)送命令到各個(gè)主控板、機(jī)框、機(jī)架、單板，并匯總返回的結(jié)果，執(zhí)行生成網(wǎng)元文檔的任務(wù)，同時(shí)將進(jìn)度上報(bào)。

1.3 網(wǎng)元文檔的生成

1.3.1 存儲(chǔ)方案

網(wǎng)元文檔有兩種存儲(chǔ)方案可供選擇，即數(shù)據(jù)庫(kù)格式存儲(chǔ)和文件流的格式存儲(chǔ)。數(shù)據(jù)庫(kù)格式便于檢索，但要求表結(jié)構(gòu)固定，不便于擴(kuò)展；文件流恰恰相反，不便于檢索，但存儲(chǔ)內(nèi)容更加靈活。基于對(duì)網(wǎng)元文檔屬性內(nèi)容可擴(kuò)展性的考慮，文件流更為適合。鑒于XML作為文件存儲(chǔ)格式所表現(xiàn)出來(lái)的優(yōu)越性，包括通用性、擴(kuò)展容易、可讀性好。網(wǎng)元文檔遵守標(biāo)準(zhǔn)的XML文件格式。其存儲(chǔ)格式（部分內(nèi)容）如下：

1.3.2 生成方案

網(wǎng)元文檔生成功能最初的設(shè)計(jì)方案是：每次用戶要求生成網(wǎng)元文檔時(shí)，就查詢網(wǎng)元文檔的每一個(gè)屬性，并最后組成一份完整的網(wǎng)元文檔并呈現(xiàn)給用戶。然而一條MML命令通常對(duì)應(yīng)一條屬性信息，即對(duì)于包含數(shù)千條屬性的網(wǎng)元文檔來(lái)說(shuō)，就需要下發(fā)數(shù)千條MML命令，才能得到完整的文檔信息。而幾千條MML命令報(bào)文的下發(fā)和解析，所需時(shí)間太長(zhǎng)。實(shí)驗(yàn)數(shù)據(jù)表明，對(duì)于一個(gè)包含350塊單板的RAC網(wǎng)元，其生成文檔的時(shí)間達(dá)到7 min。而商用局點(diǎn)中，單個(gè)網(wǎng)元安裝1 000塊以上單板是比較常見(jiàn)的。按照實(shí)驗(yàn)數(shù)據(jù)統(tǒng)計(jì)的時(shí)間進(jìn)行估算，這樣的站點(diǎn)生成文檔將達(dá)到20 min，顯然是用戶所不能忍受的。

針對(duì)這種情況，有兩種方案可供選擇:

(1)每天的某個(gè)固定時(shí)間（如凌晨）定時(shí)生成網(wǎng)元文檔。通常來(lái)說(shuō)，網(wǎng)絡(luò)設(shè)備在24 h內(nèi)更改量不會(huì)很大，則可以在用戶需要時(shí)，將這份已經(jīng)生成但卻是過(guò)時(shí)的數(shù)據(jù)提供給用戶。該方案能夠迅速地將網(wǎng)元信息反饋給用戶，并且基本上保證是比較新（24 h內(nèi)）的數(shù)據(jù)。缺點(diǎn)是，在某些特殊情況下，小概率事件還是可能發(fā)生的，在某個(gè)較小的時(shí)間段內(nèi)對(duì)網(wǎng)元進(jìn)行了較大調(diào)整。這時(shí)用戶得到的就是大量的錯(cuò)誤數(shù)據(jù)，將會(huì)導(dǎo)致用戶作出錯(cuò)誤的決策。

(2)采用動(dòng)態(tài)配置。在這個(gè)方案中，網(wǎng)元文檔的生成可分為兩種情況，即網(wǎng)絡(luò)初次運(yùn)行時(shí)文檔的始化生成和網(wǎng)絡(luò)運(yùn)行過(guò)程中設(shè)備增加、修改、刪除時(shí)的文檔更新。一般來(lái)說(shuō)，初始化網(wǎng)元文檔的工作量較大，但是頻度低（一次）；而動(dòng)態(tài)更新任務(wù)恰恰相反，工作量一般較小，但是頻度高（這個(gè)視實(shí)際運(yùn)行過(guò)程中管理需要來(lái)確定）。動(dòng)態(tài)配置避免了用戶得到臟的數(shù)據(jù)，并能保證用戶較快得到結(jié)果，但實(shí)現(xiàn)復(fù)雜。

綜合比較，可采用第二種方案。相對(duì)來(lái)說(shuō)，對(duì)于動(dòng)態(tài)地增加單板、改變單板的位置、為單板增加扣板、維修處理等變動(dòng)，可采用動(dòng)態(tài)更新的方法，即只對(duì)修改后的元件下發(fā)命令，獲取信息，并將更新后的信息保存到網(wǎng)元文檔中。歸納網(wǎng)元各個(gè)元件的變動(dòng)有如下三種情況：①增加，多指增加物理元件，如增加單板。②修改，多見(jiàn)于修改軟件信息或配置信息，如增加維修記錄（指修改歷史信息）、更換軟件版本（修改版本信息）。③刪除，如卸載軟件版本、拆除物理元件。BAM的運(yùn)行系統(tǒng)監(jiān)控整個(gè)網(wǎng)元，一旦發(fā)現(xiàn)改動(dòng)，則發(fā)送與該改動(dòng)相關(guān)的命令字到主動(dòng)請(qǐng)求模塊。主動(dòng)請(qǐng)求模塊是一個(gè)隨系統(tǒng)而運(yùn)行的線程，一旦接收到該命令字后，則檢查日志，判斷該改動(dòng)是來(lái)自于服務(wù)器還是來(lái)自于現(xiàn)場(chǎng)運(yùn)行環(huán)境。如果來(lái)自于服務(wù)器，則返回該命令字，不作處理；否則，查看MML命令配置文件（表1），將命令字對(duì)應(yīng)的MML命令取出，并執(zhí)行該MML命令。最后，將命令執(zhí)行結(jié)果更新到網(wǎng)元文檔中。

網(wǎng)元文檔更新后，BAM發(fā)送MML通知報(bào)文告知服務(wù)器獲取新的網(wǎng)元文檔。

1.4 網(wǎng)元文檔的上傳

網(wǎng)元文檔可以通過(guò)CORBA接口、MML接口及FTP方式傳送。CORBA接口有數(shù)據(jù)長(zhǎng)度的限制；MML接口具有靈活、方便、適合小數(shù)據(jù)的特點(diǎn)；而FTP方式則對(duì)于大數(shù)據(jù)量也能在很短時(shí)間內(nèi)安全可靠地傳送。由于網(wǎng)元文檔數(shù)據(jù)量較大，從幾千字節(jié)到十幾兆字節(jié)不等，文中采納FTP方式上傳。網(wǎng)元文檔存儲(chǔ)的路徑一般是其網(wǎng)元類型為文件名的文件夾，同時(shí)以網(wǎng)管服務(wù)器為該網(wǎng)元分配的唯一ID為文件名，以避免多個(gè)網(wǎng)元可能重名的情況，造成網(wǎng)元文檔的覆蓋，并方便文檔檢索。

網(wǎng)元文檔上傳功能最初的設(shè)計(jì)方案采用的是在所有傳輸過(guò)程中，將GUI和網(wǎng)元均作為FTP客戶端，而網(wǎng)元文檔服務(wù)器作為FTP服務(wù)器，向客戶端和網(wǎng)元提供FTP服務(wù)。網(wǎng)元文檔生成后，服務(wù)器端下發(fā)上傳命令，同時(shí)將FTP用戶名、密碼、文件保存路徑一并下發(fā)。網(wǎng)元上傳文件，同時(shí)上報(bào)進(jìn)度。但是對(duì)某些用戶，由于其特定的網(wǎng)絡(luò)安全策略，在網(wǎng)管系統(tǒng)和網(wǎng)元設(shè)備之間往往會(huì)添加防火墻的設(shè)置，導(dǎo)致網(wǎng)管系統(tǒng)的FTP端口不能被網(wǎng)元訪問(wèn)，從而使得網(wǎng)元文檔的上傳功能不可用。

針對(duì)這種情況，使用中轉(zhuǎn)服務(wù)器的改進(jìn)方案。無(wú)論網(wǎng)元是否具有FTP功能，其文件傳輸均以網(wǎng)元作為FTP服務(wù)器，而以網(wǎng)管服務(wù)器作為FTP客戶端。當(dāng)某種網(wǎng)元不具有FTP服務(wù)器功能時(shí)，為其尋找一個(gè)可提供FTP服務(wù)的網(wǎng)元作為其中轉(zhuǎn)服務(wù)器，目標(biāo)網(wǎng)元作為FTP客戶端將文件傳輸?shù)皆撝修D(zhuǎn)服務(wù)器上；然后網(wǎng)管服務(wù)器作為一個(gè)FTP客戶端，從中轉(zhuǎn)服務(wù)器上將文件取到自身中。當(dāng)某種網(wǎng)元具有FTP功能時(shí)，只要將該網(wǎng)元本身作為自己的中轉(zhuǎn)服務(wù)器，按照同樣的方式，即可獲取文件。在設(shè)置中轉(zhuǎn)服務(wù)器的條件下，服務(wù)器首先獲得中轉(zhuǎn)服務(wù)器的IP、用戶名、密碼等信息，并告知網(wǎng)元；然后網(wǎng)元將網(wǎng)元文檔上傳到中轉(zhuǎn)服務(wù)器，上傳成功后，通知服務(wù)器；最后，服務(wù)器通過(guò)FTP登錄到中轉(zhuǎn)服務(wù)器將相關(guān)文檔下載到本地。文檔上傳流程圖如圖2所示。

1.5 網(wǎng)元文檔的下載

網(wǎng)元文檔的下載是指GUI登錄到網(wǎng)元文檔服務(wù)器，將上傳到網(wǎng)元文檔服務(wù)器的網(wǎng)元文檔下載到用戶端。該過(guò)程較為簡(jiǎn)單，不作詳細(xì)介紹。

2 關(guān)鍵技術(shù)

2.1 多線程執(zhí)行

并發(fā)是網(wǎng)元文檔服務(wù)必要的需求。一方面，分布式系統(tǒng)中允許存在多個(gè)客戶的并發(fā)訪問(wèn)方式；另一方面，多處理器平臺(tái)上的網(wǎng)絡(luò)服務(wù)器常常通過(guò)使用并發(fā)來(lái)提高整個(gè)系統(tǒng)的性能。網(wǎng)元文檔服務(wù)對(duì)于并發(fā)的支持表現(xiàn)在兩個(gè)方面：①使用多個(gè)線程來(lái)解批處理問(wèn)題；ACE提供了Task框架，可以管理多個(gè)線程的執(zhí)行。在該框架中，一個(gè)主線程MainTask被啟動(dòng)，成為網(wǎng)絡(luò)看守的主事件循環(huán)，并等待響應(yīng)客戶端的消息到來(lái)。客戶端每發(fā)送一個(gè)消息，就啟動(dòng)一個(gè)線程來(lái)處理一個(gè)與網(wǎng)元交互的請(qǐng)求。該線程執(zhí)行完某種處理后，會(huì)自動(dòng)消亡。對(duì)于每一個(gè)網(wǎng)元也將啟動(dòng)一個(gè)線程來(lái)執(zhí)行相應(yīng)的任務(wù)，任務(wù)執(zhí)行完后自動(dòng)消亡。②控制線程的數(shù)量。線程并不是越多越好，實(shí)驗(yàn)數(shù)據(jù)（Sun Blade服務(wù)器：2GB內(nèi)存，雙CPU）表明，當(dāng)線程的數(shù)量達(dá)到一定數(shù)目時(shí)，在本實(shí)驗(yàn)中線程數(shù)為1 000后，系統(tǒng)性能下降，處理出現(xiàn)瓶頸。于是在本系統(tǒng)中，當(dāng)線程數(shù)達(dá)到500時(shí)，將暫停后面的任務(wù)，直到前面線程執(zhí)行完畢，再喚醒后面的線程。

2.2 同步機(jī)制

網(wǎng)元文檔服務(wù)中啟用了多個(gè)線程，包括上報(bào)進(jìn)度線程、任務(wù)超時(shí)計(jì)算線程、主線程。這些線程會(huì)訪問(wèn)一些共同關(guān)心的數(shù)據(jù)，如各線程均會(huì)訪問(wèn)任務(wù)時(shí)間。多個(gè)線程訪問(wèn)同一段內(nèi)存很可能造成數(shù)據(jù)的錯(cuò)誤，所以，必須有一定的同步機(jī)制來(lái)序列化多線程控制的執(zhí)行。ACE中的鎖機(jī)制可以解決這個(gè)問(wèn)題。ACE中有幾種包裝為同步多線程提供了接口。在Guard接口包裝中，Gurard有效地利用C++類構(gòu)造器和析構(gòu)器的語(yǔ)義來(lái)確保在進(jìn)入和退出代碼塊時(shí)分別自動(dòng)獲取和釋放鎖ACE_Write_Guard和ACE_Read_Guard。

首先定義ACE_Mutex m_iTimerMute

上報(bào)進(jìn)度線程

Guard包裝有效地保證了線程間的互斥。如上例，保證了同一時(shí)間對(duì)m_iTimer只能有一個(gè)操作。

2.3 通信機(jī)制

GUI及BAM與網(wǎng)元文檔服務(wù)器的網(wǎng)元文檔傳輸采用FTP協(xié)議方式；網(wǎng)元文檔服務(wù)器與BAM命令通信采用MML協(xié)議方式；GUI與網(wǎng)元文檔服務(wù)器的信息傳遞采用CORBA調(diào)用方式。這里討論MML協(xié)議及FTP協(xié)議的使用。

MML基于TCP協(xié)議，其報(bào)文格式如下：

發(fā)送與接收使用ACE提供的通信組件ACE：：Socket類，使用Socket通信的過(guò)程可參考文獻(xiàn)[6]。ACE同樣提供了FTP通信組件ACE：：FTP類，使用FTP通信的過(guò)程可參考文獻(xiàn)[6]。

3 結(jié)束語(yǔ)

文中設(shè)計(jì)并實(shí)現(xiàn)了一種網(wǎng)元文檔服務(wù)，解決了網(wǎng)元文檔生成、上傳時(shí)間長(zhǎng)的問(wèn)題，并提出了一系列技術(shù)，包括XML存儲(chǔ)方案、中轉(zhuǎn)服務(wù)器、多線程機(jī)制、同步機(jī)制等來(lái)保證系統(tǒng)可靠、高效地運(yùn)行。網(wǎng)元文檔服務(wù)解決了網(wǎng)管各模塊包括故障、配置、性能、安全等對(duì)網(wǎng)元信息的遺漏，給出了解決方案，并已得到成功應(yīng)用。但如果進(jìn)行推廣，文檔內(nèi)容及格式還需要進(jìn)一步規(guī)范。

本文中所涉及到的圖表、注解、公式等內(nèi)容請(qǐng)以PDF格式閱讀原文。