袁博，汪斌強，馬東超

(1. 國家數(shù)字交換系統(tǒng)工程技術研究中心，河南 鄭州 450002；2. 北方工業(yè)大學 信息工程學院，北京 100041)

1 引言

隨著網(wǎng)絡規(guī)模不斷擴大，大量的個性化業(yè)務應用向規(guī)?；瘧棉D化，傳統(tǒng)的網(wǎng)絡體系結構已不能很好地適應這種發(fā)展趨勢?？芍貥嬋嵝跃W(wǎng)絡是解決此類問題的一個重要方法，它的理論根源在于動態(tài)地改變網(wǎng)絡的服務能力使之追隨用戶業(yè)務需求的變化，通過將網(wǎng)絡基礎設施的物理資源服務能力和服務提供商的業(yè)務承載能力相分離，以構建可重構服務承載網(wǎng)的形式，快速、靈活和高效地為用戶提供網(wǎng)絡服務。物理網(wǎng)絡為可重構服務承載網(wǎng)提供網(wǎng)絡資源，不同的可重構服務承載網(wǎng)具有不同的服務能力，從而在共享由不同基礎設施提供商提供的底層物理網(wǎng)絡資源的基礎上，能同時支持多個服務特征不同的異質(zhì)網(wǎng)絡體系結構并存，為用戶提供多樣化的網(wǎng)絡服務[1,2]。這種網(wǎng)絡得以實現(xiàn)的關鍵是將底層網(wǎng)絡服務與用戶業(yè)務松耦合，網(wǎng)絡節(jié)點的軟硬件資源也需要被合理的分割。節(jié)點設備構件化便是上述機制的一種物理映射，為此需要一種支持重構的構件模型。因為軟件和硬件在重構機制的實現(xiàn)上存在區(qū)別，本文主要研究的是節(jié)點設備控制平面軟件領域的構件模型。

傳統(tǒng)的構件模型設計時考慮的軟件運行環(huán)境是靜態(tài)的，即使考慮到運行環(huán)境變化也是基于對未來的預測，不能夠支持可重構環(huán)境中大量未知構件的動態(tài)植入和卸載。要支持構件的靈活重構，軟件工程層面應該提供一種便于構件重構的構件模型和管理機制，構件模型應該具有感知、決策和執(zhí)行的能力。即在感知到運行環(huán)境或構件發(fā)生變化后，構件模型做出相應決策，進而執(zhí)行方法調(diào)用、參數(shù)改變或者結構調(diào)整等動作?？芍貥嫮h(huán)境中構件的動態(tài)植入和卸載會帶來很多安全方面的不確定性因素，為保證軟件系統(tǒng)的安全性，構件模型還必須為外來構件提供可信交互機制，對構件交互信息進行可信封裝，保證任意一個構件的行為和數(shù)據(jù)不會影響到其他構件和系統(tǒng)環(huán)境。在構件重構后還應保證新結構下構件間的可信交互。

針對上述挑戰(zhàn)，本文提出了一種可信構件模型(TCM, trustworthy component model)。TCM包括構件代理、容器和行為構件，使用構件代理(CA,component agent)可完成決策和重構部署，利用AC(agent client)可完成構件間的可信交互。在構件組裝層面引入具有感知功能的容器可隔離底層操作系統(tǒng)的影響，從而實現(xiàn)感知、決策和執(zhí)行這3個功能的獨立表達和封裝，同時在容器中實現(xiàn)構件數(shù)據(jù)的可信封裝。在此基礎上，TCM使用動態(tài)軟件體系結構(DSA, dynamic software architecture)技術[3]實現(xiàn)構件連接關系的重構。上述機制一方面使第三方構件可以通過AC實現(xiàn)與軟件體系結構的松耦合而被靈活地植入和卸載，另一方面構件代理可以對模型下的構件進行管理，保證軟件構件系統(tǒng)的靈活重構和可信。

2 相關研究工作

構件的插拔與替換是基于構件的軟件工程(CBSE, component based software engineering)中的基本手段之一。在基于構件的軟件設計階段，設計的逐步求精可視為抽象度高的構件不斷被更細化的構件替換的過程；在構件的獲取階段，構件的檢索可視為檢索者所需的構件由構件庫中的具體構件所替換的過程；在構件的組裝階段，通過構件的替換可支持系統(tǒng)的靈活重構；在軟件運行階段，構件替換是支持系統(tǒng)升級、維護和演化的主要手段[4]。近年來興起的網(wǎng)構軟件，可通過服務構件的動態(tài)替換和編排機制實現(xiàn)網(wǎng)上服務的按需計算，呈現(xiàn)更強的動態(tài)性和演化性[5]。構件的替換已成為CBSE領域近年來研究的核心和熱點問題之一，但是目前還未提出可以支持構件靈活重構的構件模型。

軟件適應領域[6]的研究者已經(jīng)認識到構件接口的功能分離原則在軟件適應能力調(diào)整中的重要性。較為常見的實現(xiàn)方法是使用策略、規(guī)則等手段來單獨描述軟件適應的決策邏輯，然后通過對決策邏輯的更新來調(diào)整適應能力。文獻[7]給出了一個實現(xiàn)軟件自適應的規(guī)則模型。Chisel[8]面向完全不可預期的動態(tài)變化，使用策略來描述適應邏輯，通過對策略的動態(tài)更新來為軟件添加新的適應能力；K-Component通過適應契約描述語言(ACDL)來描述適應邏輯，實現(xiàn)體系結構在線變化過程中的功能點分離[9]；MADAM區(qū)分功能實現(xiàn)和適應性行為使能2個功能點，通過構件的附加屬性、效用函數(shù)等來支持軟件的適應動作[10]。上述方法均只強調(diào)決策邏輯從軟件功能實現(xiàn)中分離，而本文強調(diào)感知、決策、執(zhí)行三者功能的分離和在線重構，如引言中所做分析，感知能力的獨立表達和在線重構對于構件適應能力的調(diào)整是十分必要的。此外，上述方法僅強調(diào)功能分離，沒有考慮開發(fā)時帶來的設計和編程實現(xiàn)代價，本文則進一步給出了構件模型和使用 DSA技術來實現(xiàn)構件靈活重構的方法。

與本文工作密切相關的另一研究是基于體系結構的軟件自適應。早在1999年文獻[11]提出了一種基于體系結構的軟件自適應模型，該模型由描述適應過程的適應管理和實現(xiàn)體系結構在線變化的演化管理2部分組成。除了前面已提及的K-Component，MADAM 等模型外，Rainbow 研究了軟件體系結構在線修改過程中的軟件重用問題[12]；FORMAware強調(diào)對體系結構重配置時需要保證功能的完整性和遵守體系結構的約束[13]；Fractal構件模型要求在設計時就要考慮體系結構配置的變化[14]等。網(wǎng)構軟件運行平臺[15]也是基于軟件體系結構來支持軟件的自適應調(diào)整，通過自主構件來實現(xiàn)構件內(nèi)部從感知到行為執(zhí)行的功能適應[16]。文獻[17]提出了一種以“環(huán)境信息顯式化、互動方式層次化、體系結構可演化”為特征的環(huán)境驅動模型。上述工作研究了基于軟件體系結構的模型，通過可演化的體系結構來支持軟件自適應調(diào)整。但是這種調(diào)整能力還是依賴軟件體系結構的設計，這種設計方式在封閉的軟件架構中是有效的，一旦應用到開放的環(huán)境中就暴露出體系結構過于緊耦合的缺點。而本文工作則關注如何在運行時實現(xiàn)軟件構件的在線重構。例如構件間拓撲關系改變和通過增加或替換構件來引入新的功能等。本文提出的構件模型，將決策和執(zhí)行功能交予模型框架實現(xiàn)，構件只專注功能的實現(xiàn)，減少了第三方開發(fā)構件的難度，有利于軟件在開放異構環(huán)境中的應用。

對于運行大量外來構件的軟件系統(tǒng)，如何保證軟件系統(tǒng)的安全和外來構件的可信是必須要解決的問題。第三方構件主要依靠數(shù)據(jù)的交互影響其他構件，因此保證構件數(shù)據(jù)的安全是一種提高構件模型可信性的解決方案。數(shù)據(jù)的安全封裝最早出現(xiàn)在虛擬機研究中[18]。Tal Garfinkel和Ben Pfaff等提出了一種稱為Terra的可信計算體系結構[19]，它的目標是支持具有不同安全需求的應用同時運行在同一硬件平臺之上。Terra利用虛擬機技術在一個硬件平臺上構建多個具有不同安全特性的可信計算系統(tǒng)。通過嚴格保證虛擬機間的隔離，使得具有較低安全級別的“開放式”系統(tǒng)和具有較高安全級別的“封閉式”計算機系統(tǒng)能夠并發(fā)地執(zhí)行在同一硬件之上。但是Terra并沒有使用安全硬件，而且只為平臺上的各種應用提供基本安全保障，并沒有建立高等級的信任保證，也沒有采用KVM[20]或VaxVMM[21,22]的安全共享方法。IBM公司的vTPM系統(tǒng)[23]也是基于Xen實現(xiàn)，它能夠利用底層硬件的TPM模塊為上層的多個虛擬機提供可信平臺模塊服務，從而實現(xiàn)了信息流在虛擬機監(jiān)視器中的安全傳遞。HP也在TPM虛擬化方面做了類似的研究工作[24]。但是這些技術面對的是應用復雜多變和易遭受攻擊的計算機系統(tǒng)，對于可重構網(wǎng)絡中的節(jié)點設備，可以利用上述研究的數(shù)據(jù)安全隔離或封裝的思想，不需要開發(fā)獨立的可信計算平臺。

與前人不同，本文提出了一種支持網(wǎng)絡重構的可信構件模型，并從構件數(shù)據(jù)的可信性出發(fā)，對構件交互的數(shù)據(jù)進行安全封裝，阻止構件進行惡意操作，提高了整個構件模型的可信性。本文創(chuàng)新點在于提出了一種支持重構的可信構件模型，并闡述了模型的重構機制，組裝機制和可信機制，除了應用于可重構柔性網(wǎng)絡的節(jié)點中，任何需要軟件自適應調(diào)整的場合均可使用本文提出的構件模型。

3 TCM構件模型

一般說來，軟件構件的結構模型決定了構件的基本形態(tài)，它是軟件方法學的核心。為建立面向可重構環(huán)境的軟件構件模型，本節(jié)針對經(jīng)典軟件結構模型存在的“預定的環(huán)境、緊耦合的結構、集中式的開發(fā)和重編程的應變方式”等問題，提出以“松耦合結構、分布式聚合、動態(tài)化重構、可信化保障”為特征的軟件構件模型。其中開放協(xié)同是基礎，主要特征是“松耦合結構與分布式聚合”，它將突破傳統(tǒng)封閉可控模型的限制，使得軟件在結構上能夠適應可重構環(huán)境對各類資源的多模式協(xié)同的要求。外界驅動的特征是“感知環(huán)境變化與動態(tài)重構”，其中外界環(huán)境變化也包括人為發(fā)布的重構指令，在此基礎上，建立開放協(xié)同模型與環(huán)境模型的交互計算模式，從而形成環(huán)境驅動的動態(tài)化重構。更進一步，可信化保障主要指“數(shù)據(jù)的安全交互”，它是在環(huán)境驅動模型的基礎上引入安全封裝，解決開放環(huán)境下構件的可信性問題，最終形成一個安全可信的軟件模型。

構件模型由構件和容器組成，構件分為構件代理和行為構件2種類型。容器負責外界環(huán)境的感知為構件提供運行環(huán)境，構件代理具有決策功能，構件模型中只含有一個構件代理，行為構件負責實現(xiàn)具體的功能。宏觀上構件模型如圖1所示。構件植入到容器后，首先向構件代理(CA,component agent)注冊，由CA記錄構件的屬性信息并分配構件一個在容器內(nèi)唯一的通信地址。構件間的交互是通過 AC(agent client)進行的，AC利用容器提供的通信服務將構件的信息在構件間按需地進行傳遞。

圖1 構件模型與外界環(huán)境關系

3.1 感知、決策和執(zhí)行分離機制

為了適應可重構環(huán)境的環(huán)境多變和重構特性，本文提出了構件模型中感知、決策和執(zhí)行分離的機制，如圖2所示。感知功能包括對環(huán)境變化的檢測和接收人為發(fā)出的重構指令，與外界環(huán)境交互密切所以交由容器實現(xiàn)，以建立環(huán)境模型和觸發(fā)重構決策。本文將環(huán)境的變化抽象為軟件運行的上下文變化，上下文是構件模型中一個重要概念，將在后文中詳細闡述，它為形式化描述環(huán)境變化提供了方法和工具，便于容器感知功能的實現(xiàn)。容器除了具有感知功能，還負責完成構件對外信息的交互和對底層資源的調(diào)用，這點與軟件中間件功能類似。

圖2 感知、決策和執(zhí)行分離機制

決策功能是構件模型的中樞部分，是執(zhí)行軟件重構過程中決策邏輯的構件，因此本文使用一種特殊的構件實現(xiàn)決策功能，稱為構件代理(CA)。本身這種實現(xiàn)方式也是一種功能分離機制，當構件模型決策機制變化時只需修改其中的構件代理，這樣做可以使構件模型達到最大程度的前向兼容效果。構件代理的動作可以分為修改構件功能描述與修改構件連接拓撲：前者指構件代理可以對行為構件的語義進行調(diào)整，具體表現(xiàn)為構件屬性描述信息的變化；后者則是指構件代理能夠對行為構件間連接拓撲進行調(diào)整，如增刪、替換構件和連接關系等，具體表現(xiàn)為構件代理修改容器所提供的AC服務。

行為構件用來在容器中實現(xiàn)軟件的功能，大多數(shù)構件由第三方開發(fā)，需要考慮行為構件的安全性和標準化。因此后文重點關注行為構件接口的標準化和可信數(shù)據(jù)傳遞。行為構件是可重構操作的對象，本文正是通過行為構件的增刪與替換實現(xiàn)軟件整體功能的重構。

3.2 軟件構件模型支持的重構機制

可重構柔性網(wǎng)絡的特點是按照用戶需求構建具有不同業(yè)務屬性的可重構服務承載網(wǎng)，不同的服務承載網(wǎng)對應一系列不同的構件。服務承載網(wǎng)的構建和重構一方面涉及數(shù)據(jù)平面轉發(fā)和交換部件的重構，另一方面涉及控制平面中軟件構件的替換和增刪。重構過程中兩者相互配合，數(shù)據(jù)平面提供構件模型與外界交互的通道，控制平面借助構件模型完成軟件構件的部署和替換，啟用適應數(shù)據(jù)平面的控制構件。網(wǎng)絡節(jié)點的重構過程涉及到節(jié)點內(nèi)的構件代理、容器和行為構件，還需要節(jié)點外構件庫的支持，執(zhí)行過程如圖3所示。服務承載網(wǎng)重構反映的是構件模型接收重構指令進行重構操作的過程，除此之外構件模型還可根據(jù)感知環(huán)境的變化進行構件重構，兩者相比區(qū)別僅在于驅動重構的來源不同，本文對前者進行詳細描述，后者不再贅述。

圖3 構件模型支持的重構機制

結合前文的描述，用戶負責下發(fā)重構方案，重構方案中包含了預先定義便于構件代理識別的重構指令。構件庫中提前存有第三方遵循構件模型標準開發(fā)的構件，構件代理根據(jù)重構指令下載合適的構件。

構件運行時，首先向構件代理注冊，構件代理為每個構件分配通信地址，并告知當前構件的通信對象。每個構件將與自己通信的構件分為上游構件和下游構件，接收對方消息時標記對方為上游構件，向對方發(fā)送消息時標記對方為下游構件。分別在各自AC中保持上、下游構件通信列表。當通信對象發(fā)生變化時只需更新AC中的通信列表。

當需要添加構件時，構件代理為新構件分配地址，同時廣播新構件的地址，各構件AC根據(jù)廣播消息更新自己的通信列表；刪除構件時，構件代理將原有構件地址宣布為無效地址，各構件AC將自己通信列表中的相同地址標記為無效；替換構件時，只需將被替換構件AC中的信息遷移到新構件中。上述重構機制在實際場景中有多種實現(xiàn)方式，可根據(jù)編程語言選擇合適通信機制和編程實現(xiàn)。

4 TCM的構件類型和構造方法

構件模型是基于構件的軟件開發(fā)方法的核心，它由構件語義、構件語法和構件組裝3部分組成。構件語義說明了構件到底是什么；構件語法規(guī)定了構件是如何被定義、構造和表示的；構件組裝則說明構件是如何被靜態(tài)和動態(tài)組裝的。

上下文是環(huán)境某一個維度(如可用內(nèi)存、溫度、位置等)，其定義可以來源于相應的上下文本體，上下文的值代表了環(huán)境在該維度的狀態(tài)，上下文事件代表的則是該維度狀態(tài)的變化。在上述定義的基礎上，可以區(qū)分構件的上下文端口和服務接口；前者可以定義上下文事件，用來更新容器內(nèi)部的環(huán)境模型等；后者則是一般意義上包括方法、屬性等的接口。

定義1 上下文E可定義為三元組 ＜ name, t p ye,value＞，其中，name是上下文的名稱，type是上下文的類型，上下文E在任一確定的時刻均有一個類型為type的值value。

定義 2 容器 C可以定義為三元組 , ,In Out＜service＞，其中，In表示容器用來接收構件消息的端口集合，端口的類型決定了容器中可以植入構件的類型，Out表示容器輸出消息的端口集合，service表示容器可以提供的服務類型的集合，一般service都會與一組In和Out端口綁定。

容器C是構件運行的環(huán)境，在軟件生存周期內(nèi)屏蔽環(huán)境變化造成的影響，它提供了豐富的供構件調(diào)用的服務接口，完成構件間基本的信息交互和對底層資源的調(diào)用，如內(nèi)存分配和時鐘管理等。容器C定義的端口和服務是第三方開發(fā)構件時參照的重要標準，容器C的實現(xiàn)方式?jīng)Q定了構件植入方式。

4.1 構件類型

構件代理是一類特殊構件，它不參與軟件功能的處理，是對軟件決策邏輯手段的封裝，執(zhí)行重構操作。構件代理負責接收用戶制訂的重構方案，按照預先約定的語義解析方案，根據(jù)方案進行構件重構，可以控制構件的加載，激活，配置和卸載。構件代理還可根據(jù)環(huán)境變化調(diào)整構件之間的連接關系。

對于行為構件引用傳統(tǒng)意義的定義，即具有相對獨立功能、可以明確辨識、接口由契約指定、可獨立部署、和語義有明顯依賴關系、且多由第三方提供的可組合軟件實體[25]。它對具體業(yè)務處理行為進行封裝，通過AC對外提供多個服務接口，并可以依賴其他接口。

4.2 構件構造方法

在已有的構件模型中，構件外部特征的定義方法可以分為兩大類：直接使用具體的編程語言(如Java)或使用專門的構件定義語言(如CCM，COM/DCOM)。后者一方面有助于實現(xiàn)不同語言、不同平臺間的互操作，更重要的是，它們可以顯式地表示構件類型信息，從而有助于對軟件體系結構的后續(xù)修改。因此，本文在TCM中引入了XML語言來定義構件。

本文對XML語言進行了擴展，主要的擴展內(nèi)容包括：引入component，id等關鍵字及相關語法來定義構件；引入event關鍵字及相關語法來定義上下文事件；引入 in_port，in_port_num，in_message_type, out_port等關鍵字來描述接口；引入state關鍵字來定義構件組裝類型等。

通過專門設計的編譯器可以將XML構件定義映射為Java、C等具體編程語言下的構件框架，構件開發(fā)者可以填寫構件實現(xiàn)并生成構件分組。構件模型的接口中包括了普通服務、事件處理和構件映射3 類方法，其中，普通服務和事件處理由XML定義直接映射生成，構件映射方法則需要向構件代理注冊構件類型、當前運行狀態(tài)等基本信息，由構件代理決定誰來具體完成該請求。TCM構件的構造方法如圖4所示。

圖4 構件構造方法

4.3 構件組裝機制

組裝是構件模型應用的核心，構件模型可對行為構件按照滿足應用需求的方案進行組裝來實現(xiàn)軟件功能。

在構件的組裝過程中，涉及到不同構件之間的連接拓撲，而且不同構件的連接拓撲也決定了構件間信息流的傳輸路徑。根據(jù)信息流在互連構件間的流向，從復雜的構件連接方式中提取出順序組裝、聚合組裝和分支組裝3種最基本的構件組裝方式，如圖5所示，圖中省略了連接拓撲的實現(xiàn)細節(jié)。任何復雜的構件組裝均以這3種組裝關系為基礎。從軟件體系結構描述角度出發(fā)，可在基本構件的形式化描述基礎上，推導出基于以上3種方式組裝的復合構件的形式化描述。若以推導出的復合構件為基礎構件，可進一步推導出更高層次的復合構件，如此反復，最終可推導出整個復雜軟件系統(tǒng)的體系結構描述。TCM模型從軟件體系結構的角度實施構件的組裝，通過AC的連接拓撲變化來實現(xiàn)構件間的組裝，可以用XML語言描述構件間接口關系的改變來描述構件的組裝藍圖。圖 6展示了使用 XML語言描述簡單的順序組裝和聚合組裝。

圖5 構件組裝機制

圖6 XML語言描述的構件組裝

5 TCM模型的可信機制

可重構柔性網(wǎng)絡節(jié)點中運行著大量第三方構件，其中，多個構件在容器中組裝成為更復雜的軟件構件。構件模型的可信機制應既要保證單個構件的可信，也要保證組裝后構件系統(tǒng)的可信性。

構件在構件模型中通過AC調(diào)用容器提供的接口進行消息通信，在TCM模型中提出了一種構件接口數(shù)據(jù)的安全封裝機制，防止構件進行違反約束的訪問和操作。容器是將構件和底層操作系統(tǒng)隔離的一種構件運行環(huán)境，操作系統(tǒng)默認容器與自己進行的操作都是高安全級別的可信操作，構件進行的操作都是低安全級別的操作。低安全級別的操作可以依賴高安全級別的操作，若高安全級別的操作依賴于低安全級別的操作則認為這是不可信的?？尚艡C制中涉及的對象包含CA代表的構件代理, C代表的容器，AC代表的構件接口。本文在容器中對構件的接口數(shù)據(jù)進行安全屬性劃分和封裝。

定義 3 安全級別、安全操作和安全操作集函數(shù)。利用安全級別對 CA、C、AC進行劃分。CA和C之間交互的數(shù)據(jù)屬于高安全級別，記為 d ataH，AC之間交互的數(shù)據(jù)屬于低安全級別，記為 d ataL。CA和 C進行的操作屬于高安全級別操作，記為ActH，AC進行的操作屬于低安全級別操作，記為ActL。函數(shù) g et_ Acts( d: d ata) → 2Acts表示由數(shù)據(jù)安全級別得到執(zhí)行該數(shù)據(jù)安全操作的集合。

定義 4 安全屬性和安全屬性映射函數(shù)。安全屬性記為prop，安全映射函數(shù)記為 fp rop( p: p rop)→data。

在容器C中，將存儲空間劃分為相互隔離的區(qū)域使用安全屬性標記，為了保證構件傳遞數(shù)據(jù)的安全，使用安全映射函數(shù)將構件的數(shù)據(jù)保存在不同的存儲空間。當發(fā)生構件組裝后，將組裝在一起的構件數(shù)據(jù)映射到安全屬性相同的存儲空間，如圖7所示。

構件代理為相互通信的構件分配相同 security property值，AC將構件的數(shù)據(jù)與此security property值綁定。容器根據(jù)構件數(shù)據(jù)的security property值將數(shù)據(jù)存儲在特定的安全存儲空間。當其他構件讀取此數(shù)據(jù)時，只有security property值一致時才能獲取數(shù)據(jù)。構件組裝后，構件代理為被組裝的構件分配同一個security property值，構件只能使用此security property與參與組裝的構件通信。這種機制可以保證構件代理對構件間通信的管理，避免惡意構件自主通信。security property值由構件代理分配，取值來自Hdata和Ldata構件無權修改，AC負責綁定security property值和數(shù)據(jù)，惡意構件無法偽造security property值欺騙AC。另外還可以使用加密算法保證security property值不被惡意構件獲取。

6 原型驗證及實驗

本節(jié)描述在可重構路由器中實現(xiàn)的TCM容器原型，并基于容器開發(fā)的構件實例來驗證TCM模型的有效性。

6.1 支持ATCM的容器原型

容器除了提供構件運行的環(huán)境外，也是實現(xiàn)重構的場所和提供可信機制的基礎設施。基于Quagga路由軟件的Zebra平臺[26]實現(xiàn)了一個TCM的容器原型，其主要部件如圖8所示。構件管理引擎負載構件的加載、激活和卸載等操作。通信引擎負責支持構件的數(shù)據(jù)通信和轉發(fā)構件的服務接口的訪問請求，提供數(shù)據(jù)報文的傳遞。可信存儲提供數(shù)據(jù)安全存儲機制，隔離構件低安全級別的操作。構件組裝引擎負責執(zhí)行和維護構件的組裝，并將組裝結果反饋給可信存儲。環(huán)境模型提供外界環(huán)境變化的表征，保存當前影響構件的環(huán)境維度的屬性值，構件屬性描述信息等。日志記錄負責保存重構操作記錄，容器架構信息等。系統(tǒng)接口與操作系統(tǒng)交互，為容器提供操作系統(tǒng)的支撐服務。

圖7 容器C安全存儲資源分布

Zebra容器運行時需要維護系統(tǒng)內(nèi)部狀態(tài)的一致性，如構件重構時的狀態(tài)遷移等。當構件模型發(fā)生變化時，構件管理引擎負責映射構件相關的變化，環(huán)境模型負責映射容器體系結構的變化。當發(fā)生如構件意外失效的特殊情況時，構件管理引擎通過輪詢構件AC反射接口獲知情況變化，相應的狀態(tài)會被反饋到環(huán)境模型中。Zebra容器目前可以運行在Linux和其他Unix變體系統(tǒng)上，符合GNU的GPL標準并提供了支持C語言編譯器等開發(fā)工具。

除了上述構件重構和管理部分的功能外，Zebra容器本身對路由軟件提供了非常豐富的操作支持。它支持 BGP-4、BGP-4+、OSPFv2、OSPFv3、RIPv1、RIPv2和RIPng等協(xié)議的標準接口和數(shù)據(jù)操作，對外提供類似Cisco IOS管理操作接口。第三方開發(fā)者可以按照構件AC和容器接口規(guī)范開發(fā)路由協(xié)議構件，在6.2節(jié)將介紹構件AC接口的使用。

6.2 構件模型重構實例

圖8 ATCM容器原型

圖9 路由協(xié)議構件運行示意

以OSPFv2協(xié)議構件和路由管理構件為例介紹構件的重構過程，圖9中是OSPFv2協(xié)議的一種實現(xiàn)實例。第三方開發(fā)OSPFv2構件時首先滿足協(xié)議處理功能需求，其次根據(jù)構件模型規(guī)范，開發(fā)與構件模型需要交互的接口，開發(fā)時使用3類AC，AC1負責為網(wǎng)絡管理員提供一個通過指令配置、干預、查看OSPFv2運轉狀況的通道；AC2提供函數(shù)可獲取底層接口信息和重分配路由信息，同時將 OSPF路由信息交給路由管理構件；AC3主要實現(xiàn)OSPFv2協(xié)議構件與操作系統(tǒng)的TCP/IP協(xié)議棧的連接，以接收和發(fā)送數(shù)據(jù)分組，并提供對協(xié)議模塊運行過程中的內(nèi)存和定時器管理。

通過如下場景驗證構件模型對構件重構的支持。

1) 構件的加載。初始情況下路由設備中只啟動Zebra容器。構件代理發(fā)布命令下載和啟動OSPFv2構件(component 1)，OSPFv2構件可以進行正常的協(xié)議報文收發(fā)，并且將協(xié)議處理的路由信息下發(fā)給底層路由查表模塊。如圖9路徑A所示。圖10顯示了構件的端口信息和構件代理打印的構件拓撲連接信息。其中，路由查表構件(component 3)屬于硬件構件，雖然不在Zebra容器中運行但可以接收構件代理的消息。

2) 構件間連接關系的重構。隨著路由設備的運行，陸續(xù)加載RIP，BGP等構件，此時需要路由管理構件來統(tǒng)一管理各個路由協(xié)議的路由信息，此時需要改變OSPFv2構件路由信息的傳輸路徑，如圖9路徑B所示。構件代理下發(fā)重構命令，修改構件的通信關系同時更改構件的security property值。圖11顯示了構件代理打印的構件注冊信息和構件拓撲連接信息，以及各個構件間的消息傳遞。此時構件都被設置使用端口1傳遞消息。

3) 構件的卸載。構件運行中如果需要對構件進行替換，需要將舊的構件卸載，通過構件代理發(fā)布命令卸載路由管理構件(component2)。構件顯示的信息如圖12所示?？梢园l(fā)現(xiàn)，構件代理發(fā)布命令，注銷component 2，同時將此消息通知component 1和component 3，隨后通知component 1和component 3改變通信對象，從而實現(xiàn)了構件連接拓撲關系的改變。

圖10 構件間拓撲連接

圖11 重構構件時消息傳遞顯示

圖12 卸載構件過程中的信息顯示

6.3 構件模型可信機制評估

構件模型在Zebra容器中內(nèi)嵌安全存儲機制來實現(xiàn)構件交互數(shù)據(jù)的安全可信。設計2個場景評估可信機制的效果，一個是安全存儲對可重構路由器的構件性能的影響，即對單位時間內(nèi)報文交互時延的影響。另一個場景是測試可信機制對惡意行為檢測效果。

場景1 使用路由器R1將真實路由分別廣播給啟用安全存儲的可重構路由器R2和不啟用安全存儲的可重構路由器R3，待R2和R3學得路由后再分別廣播給路由器R4。在R1和R4的鏈路中抓取路由廣播分組，抓取分組軟件使用Etheral 0.10.14，計算分組時延并進行比較，觀察可信存儲機制造成的時延。普通路由器 R1和 R4使用的是中興ZXR10，路由表數(shù)據(jù)來自 routing information service(RIS)[27]。測試網(wǎng)絡拓撲如圖13所示。

路由器處理每條路由的時間較短，選擇真實路由表中前綴為25的路由信息10 000條，每100條統(tǒng)計一次均值，并且設置OSPFv2構件每5s廣播一次路由信息，分別用c、a點的時間戳差值和d、b點的時間戳差值比較。

可重構路由器中使用最多的是路由協(xié)議構件，OSPFv2構件可以設置廣播路由消息的時間間隔，固定的時間間隔削弱了路由信息的實時處理性，為消息的安全封裝和讀寫提供了時間保證。從圖 14中可以發(fā)現(xiàn)雖然路由信息的處理時延存在抖動但是控制在1s之內(nèi)，2個路由器的處理時延平均值相差不到0.4s，這個時間差主要產(chǎn)生于從安全數(shù)據(jù)存儲區(qū)域取出數(shù)據(jù)廣播路由信息這個過程。構件模型的數(shù)據(jù)安全存儲機制對路由信息報文交互的處理時延影響較小，不會影響路由協(xié)議的性能。

圖14 R2和R3路由信息處理時延比較

場景2 構件惡意行為檢測。

使用rip構件充當惡意構件，修改rip構件的協(xié)議報文發(fā)送函數(shù)，使它冒充OSPFv2構件調(diào)用AC提供的接口函數(shù)進行報文收發(fā)。下面的這些回調(diào)函數(shù)的賦值用來完成構件代理對 OSPFv2構件的控制，原來包含在OSPFv2構件中。OSPF協(xié)議中使用的是raw socket，所以修改時重點替換的是socket創(chuàng)建和setsockopt函數(shù)(如圖15所示)。篇幅所限不在此一一列舉。

Zebra容器運行過程中，原本發(fā)送給 OSPFv2構件的數(shù)據(jù)被惡意的rip構件調(diào)用AC接口函數(shù)進行讀寫，雖然此時AC接口函數(shù)可以被調(diào)用，但是當惡意構件在安全存儲區(qū)讀取數(shù)據(jù)時，無法獲得正確的security property值，讀取操作被拒絕，并在反饋給構件代理警告信息，運行結果如圖16所示。

圖15 構件代碼修改示例

圖16 構件惡意行為檢測

從結果中可以發(fā)現(xiàn)，構件注冊時構件代理把惡意rip構件認為是OSPFv2構件，所以惡意構件注冊成功并運行，但是當構件開始讀取數(shù)據(jù)時被發(fā)現(xiàn)為惡意構件，結果被存入日志并且上報構件代理，構件代理將其打印顯示，同時暫停惡意構件的運行待管理人員進行處理。其他構件不受此影響正常運行。

7 結束語

構件化的路由設備是可重構柔性網(wǎng)絡的重要節(jié)點支撐設備。本文以路由設備控制平面支持可重構為背景，兼顧軟件系統(tǒng)對環(huán)境變化的適應?；跇嫾g連接關系的調(diào)整和構件數(shù)據(jù)的安全存儲提出了一種可信構件模型 TCM。構件模型從環(huán)境感知、決策、執(zhí)行三者相分離的思想出發(fā)，使用構件代理完成決策功能，使用容器感知環(huán)境和隔離底層操作系統(tǒng)影響，使用行為構件實現(xiàn)軟件系統(tǒng)功能，通過在容器中內(nèi)嵌安全存儲機制提高構件的可信性。根據(jù)本文構件模型開發(fā)的Zebra容器和在其中實現(xiàn)的構件實例已經(jīng)應用到了可重構路由器的開發(fā)中。后續(xù)工作將對深層次的構件重構機制和構件的可信評估展開研究。

[1] 汪斌強, 鄔江興. 下一代互聯(lián)網(wǎng)的發(fā)展趨勢及相應對策分析[J].信息工程大學學報, 2009, 10(3):1-6.WANG B Q, WU J X. Development trends and associated countermeasures analysis for NGN[J]. Journal of Information Engineering University, 2009, 10(3):1-6.

[2] 袁博, 汪斌強, 張博. 綠色網(wǎng)絡的實例——可重構柔性網(wǎng)絡[J]. 電信科學, 2011, 27(10A):200-207.YUAN B, WANG B Q, ZHANG B, A case study of green network——reconfigurable flexible network[J]. Telecommunications Science,2011, 27(10A):200-207.

[3] MEI H, SHEN J R. Progress of research on software architecture[J].Journal of Software, 2006, 17(6):1257-1275.

[4] VALLECILLO A, HERNANDEZ J, TROYA J M. Component Interoperability[R]. ITI200037, Universidad de Málaga, 2000.

[5] YANG F Q. Thinking on the development of software engineering technology[J]. Journal of Software, 2005,16(1):1-7.

[6] SALEHIE M, TAHVILDARI L. Self-Adaptive software: landscape and research challenges[J]. ACM Trans on Autonomous and Adaptive Systems, 2009,4(2):1-42.

[7] WANG Q X. Towards a rule model for self-adaptive software[J].Sigsoft Software Engineering Notes, 2005, 30(1):1-5.

[8] KEENEY J. Completely Unanticipated Dynamic Adaptation of Software[D]. Dublin: Trinity College, University of Dublin, 2004.

[9] DOWLING J, CAHILL V. The K-component architecture meta-model for self-adaptive software[A]. Proc of the Int’l Conf on Meta level Architectures and Separation of Crosscutting Concerns[C]. Kyoto, Japan,2001. 81-88.

[10] PASPALLIS N, PAPADOPOULOS G A. An approach for developing adaptive, mobile applications with separation of concerns[A]. Proc of the 30th Annual Int’l Computer Software and Applications Conf(COMPSAC)[C]. Chicago, USA, 2006. 299-306.

[11] OREIZY P, GORLICK M M, TAYLOR R N, et al. An architecture-based approach to self-adaptive software[J]. IEEE Intelligent Systems, 1999, 14(3):54-62.

[12] GARLAN D, CHENG S W, HUANG A C, et al. Rainbow: architecture-based self-adaptation with reusable infrastructure[J]. IEEE Computer, 2004, 37(10):46-54.

[13] MOREIRA R, BLAIR G, CARRAPATOSO E. FORMAware: framework of reflective components for managing architecture adaptation[A]. Proc of the 3rd Int’l Workshop on Software Engineering and Middleware[C]. Orlando, USA, 2002.

[14] BRUNETON E, COUPAYE T, STEFANI J B. Recursive and dynamic software composition with sharing[A]. Proc of the 7th Int’l Workshop on Component-Oriented Programming (WCOP)[C]. Malaga, Spain, 2002.

[15] YANG F Q, LV J, MEI H. Technical framework for Internetware: an architecture centric approach[J]. Science in China (Series E), 2008,38(6):818-828.

[16] MEI H, HUANG G, ZHAO H Y, et al. A software architecture centric engineering approach for Internetware[J]. Science in China (Series E),2006, 36(10):1100-1126.

[17] LU J, MA X X, TAO X P, et al. On environment-driven software model for internetware[J]. Science in China (Series E), 2008, 38(6):864-900.

[18] VMware, Inc VMware virtual machine technology[EB/OL]. http://www.vmware.com, 2006.

[19] GARFINKEL T, PFAFF B, CHOW J, et al. Terra: a virtual machine-based platform for trusted computing[A]. Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP'03)[C].New York, USA, 2003. 193-206.

[20] KARGER P A. Multi-level security requirements for hypervisors[A].Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC'05)[C]. Tucson, Arizona, USA, 2005. 267-275.

[21] JAEGER T, SAILER R, SREENIVASAN Y. Managing the risk of covert information flows in virtual machine systems[A]. Proceedings of the 12th ACM Symposium on Access Control Models and Technologies (SACMAT'07)[C]. Sophia Antipolis, France, 2007. 81-90.

[22] CABUK S, DALTON C I, RAMASAMY H G, et al. Towards automated provisioning of secure virtualized networks[A]. Proceedings of the 14th ACM Conference on Computer and Communications Security(CCS'07)[C]. Alexandria, VA, USA, 2007. 235-245.

[23] STEFAN B, RAMON C, KENNETH A G, et al. vTPM: virtualizing the trusted platform module[A]. Proceedings of 15th USENIX Security Symposium[C]. Vancouver, Canada, 2006. 305-320.

[24] MELVIN J A, MICHA M, CHRIS I D. Towards trustworthy virtualization environments: Xen library OS security service infrastructure[EB/OL]. http://www .hpl.hp.com/techreports/2007/HPL- 2007-69.html, 2007.

[25] 楊芙清，梅宏，李克勤. 軟件復用與軟件構件技術[J]. 電子學報，1999, 27(2):68-75.YANG F Q, MEI H, LI K Q. Software reuse and software component technology[J]. Acta Electronica Sinica, 1999, 27(2):68-75.

[26] QUAGGA guide[DB/OL]. http://quagga.net.

[27] RIS raw data[DB/OL]. http://data.ris.ripe.net.