曹敬瑜，柴瑋巖，王博，郭永紅

(1.北京理工大學(xué) 計算機學(xué)院，北京 100081;2.中國兵器工業(yè)計算機應(yīng)用技術(shù)研究所，北京 100089)

0 引言

當(dāng)今嵌入式分布計算環(huán)境中所涉及的嵌入式設(shè)備越來越多，所涉及的現(xiàn)場總線、通信協(xié)議也種類繁多，導(dǎo)致嵌入式軟件的開發(fā)難度和維護成本也越來越高，如何通過構(gòu)件化框架技術(shù)[1]簡化嵌入式軟件的設(shè)計，通過模塊重用的思想減少開發(fā)的工作量，提高系統(tǒng)的穩(wěn)定性已成為亟待解決的問題[2－6]。

分布式計算環(huán)境下構(gòu)件框架技術(shù)[7－8]主要有構(gòu)件中間件技術(shù)[9－10]、發(fā)布/訂閱中間件(面向消息的中間件)、面向服務(wù)架構(gòu)和Web 服務(wù)3 大類[11－12]。

構(gòu)件中間件技術(shù)主要以EJB[13]、CORBA 組件模型(CCM)為代表。EJB 主要運行于有JAVA 支持的環(huán)境下，但在實際的嵌入式設(shè)備中，由于遺留系統(tǒng)、強實時要求等因素，并不是所有嵌入式設(shè)備都支持JAVA 虛擬機環(huán)境[14]。CCM 模型[15－16]定義了構(gòu)件所提供的服務(wù)接口方式、連接點方式以及構(gòu)件運行容器等概念，為持久化、事件通知、事務(wù)、負(fù)載均衡以及安全提供的完整的實現(xiàn)機制。但是基于CCM模型的構(gòu)件在使用其他構(gòu)件所提供的服務(wù)時，先通過檢索名字服務(wù)器提供的名字服務(wù)，再生成服務(wù)代理和客戶代理進而通信，其本質(zhì)還是有核心的服務(wù)模型，這在分布式環(huán)境下不可避免單點故障問題，即一旦名字服務(wù)器發(fā)生故障，構(gòu)件之間便不能通信。此外，采用CORBA 分布式計算模型所生成的構(gòu)件實體體積都很大，特別是應(yīng)用于嵌入式環(huán)境下，對于有些對系統(tǒng)啟動時間有時限要求和對磁盤、內(nèi)存容量大小有限制的嵌入式系統(tǒng)是不可容忍的。

發(fā)布/訂閱中間件(面向消息的中間件[17])技術(shù)以MQ 系列、Java 消息服務(wù)(JMS)、數(shù)據(jù)分發(fā)服務(wù)(DDS)為代表，其主要優(yōu)點是支持異步通信，發(fā)送方在傳送數(shù)據(jù)給接收方后不需要被阻塞以等待接收方的響應(yīng)。但是其缺少面向?qū)ο?、面向服?wù)的特性，不適合應(yīng)用于關(guān)心操作結(jié)果或操作非等冪的軟件環(huán)境。

面向服務(wù)架構(gòu)和Web 服務(wù)基于純文本的協(xié)議，如基于HTTP 的XML，對于那些細(xì)粒度的分布式資源訪問，其性能通常比上述兩種中間件技術(shù)要低幾個數(shù)量級。因此性能優(yōu)先的應(yīng)用場合，如航空、財務(wù)以及流程控制領(lǐng)域的分布式實時嵌入式系統(tǒng)并不適應(yīng)此技術(shù)模型。

針對上述問題，本文提出了在嵌入式分布計算環(huán)境下的高效軟件構(gòu)件化框架，目的是使嵌入式軟件系統(tǒng)朝著通用化、標(biāo)準(zhǔn)化、系列化、構(gòu)件化、平臺化的方向發(fā)展，為系統(tǒng)內(nèi)外的互連、互通提供穩(wěn)定可靠的保障。

1 OSGi 框架模型

開放服務(wù)網(wǎng)關(guān)倡議(OSGi)旨在建立一個由廣域網(wǎng)向區(qū)域網(wǎng)及其相聯(lián)的設(shè)備傳輸各類服務(wù)的開放式標(biāo)準(zhǔn)。它為服務(wù)供應(yīng)商、網(wǎng)絡(luò)管理員、設(shè)備開發(fā)商和軟件開發(fā)商提供了一個開放、通用的架構(gòu)，使他們能互動地開發(fā)、部署和管理服務(wù)。

基于OSGi 標(biāo)準(zhǔn)的軟件模塊化已經(jīng)成為主流的軟件開發(fā)和集成方式。Eclipse 是目前著名的一個集成開發(fā)環(huán)境(IDE)，其最大的兩個特點是插件和擴展，而其插件機制正是通過實現(xiàn)OSGi 規(guī)范實現(xiàn)的[18]。它支持模塊化的動態(tài)部署、封裝和交互、支持模塊的動態(tài)配置、是一種面向服務(wù)的構(gòu)件模型。

OSGi 概念中主要分為構(gòu)件(Bundle)和服務(wù)(Service)，可以認(rèn)為Bundle 是一個模塊的容器，主要通過BundleActivator 管理模塊的生命周期，而Service 則是這個模塊可暴露對外的服務(wù)對象。這里體現(xiàn)了OSGi 和傳統(tǒng)的Plugin Framework 不同的一個地方，管理和靜態(tài)結(jié)構(gòu)分開。在OSGi 中通過在描述文件中增加一些內(nèi)容來發(fā)布Bundle，在其中描述了Bundle 的提供商、版本、唯一ID、執(zhí)行體路徑、暴露對外的接口、所依賴的接口。每個Bundle擁有自己的實例構(gòu)件器以及構(gòu)件執(zhí)行環(huán)境context，通過context 可進行服務(wù)的注冊、卸載等，這些操作都會通過事件機制廣播給相應(yīng)的其他的Bundle.一般來說，通過在Bundle 中編寫初始需要注冊的服務(wù)的方法來完成Bundle 可供外部使用的服務(wù)的暴露功能。需要調(diào)用其他Plugin 提供的服務(wù)可通過context 的getServiceReference 先獲取Service 的句柄，再通過context.getService (ServiceReference)的方法獲取Service 的實體。OSGi 標(biāo)準(zhǔn)所定義的框架模型[19]如圖1 所示。

圖1 OSGi 框架模型Fig.1 OSGi framwork model

硬件/操作系統(tǒng):嵌入式分布計算硬件及操作系統(tǒng)，如X86，PowerPC，ARM 等，操作系統(tǒng)VxWorks，Linux。

執(zhí)行環(huán)境:在硬件和操作系統(tǒng)之上標(biāo)準(zhǔn)的基礎(chǔ)軟件開發(fā)環(huán)境，如POSIX 操作環(huán)境，標(biāo)準(zhǔn)的協(xié)議環(huán)境(TCP/IP 協(xié)議族協(xié)議、RPC 等)，開源庫環(huán)境(ACE、boost 等)。

模塊層:該層負(fù)責(zé)動態(tài)加卸載軟件構(gòu)件。一個完整的軟件構(gòu)件由構(gòu)件可執(zhí)行體(.out，.so 文件)及構(gòu)件描述文件組成，構(gòu)件描述文件中包括構(gòu)件名稱、優(yōu)先級、構(gòu)件內(nèi)存大小、構(gòu)件自身配置的屬性信息。

在加載構(gòu)件時，模塊層通過解析描述文件，動態(tài)加載構(gòu)件可執(zhí)行體，并為構(gòu)件分配內(nèi)存，提供可執(zhí)行環(huán)境，記錄下構(gòu)件運行優(yōu)先級及構(gòu)件配置的屬性信息，即為構(gòu)件執(zhí)行建立一個容器。

在卸載構(gòu)件時，模塊層負(fù)責(zé)回收分配的內(nèi)存，刪除構(gòu)件執(zhí)行容器，并在系統(tǒng)中卸載構(gòu)件可執(zhí)行體。

生命周期層:該層主要負(fù)責(zé)軟件構(gòu)件的安裝、啟動、更新、停止、卸載等操作。

服務(wù)層:軟件構(gòu)件可以向服務(wù)層注冊零個或多個服務(wù)，服務(wù)層主要功能是注冊服務(wù)和撤銷服務(wù)，另外，還可以根據(jù)特定的服務(wù)屬性來查找目標(biāo)服務(wù)。

構(gòu)件:構(gòu)件是具有獨立業(yè)務(wù)功能、可獨立部署和卸載的軟件實體。軟件構(gòu)件通過向服務(wù)層注冊服務(wù)對外部提供功能服務(wù)，也可以向服務(wù)層請求服務(wù)來獲取其他服務(wù)功能。

OSGi 框架模型因其開放性，具有跨平臺、交互操作的能力，且小而高效，更加動態(tài)，無需重新啟動，特別適合嵌入式應(yīng)用[20]。但OSGi 均基于Java 實現(xiàn)，如Equinox、Apache Felix 等IDE.而在嵌入式領(lǐng)域，大多數(shù)設(shè)備尤其是已有設(shè)備的環(huán)境都基于C、C++執(zhí)行環(huán)境。尤其是在某些專用的嵌入式領(lǐng)域，沒有對Java 環(huán)境的支持。本文參考OSGi 標(biāo)準(zhǔn)設(shè)計并實現(xiàn)了一個適用于標(biāo)準(zhǔn)C、C++環(huán)境的構(gòu)件化框架，并通過遠程調(diào)用(RPC)將其應(yīng)用于分布式環(huán)境。

2 嵌入式軟件構(gòu)件框架研究

2.1 基于OSGi 的嵌入式軟件構(gòu)件框架

將OSGi 框架映射到嵌入式分布環(huán)境對應(yīng)關(guān)系如圖2 所示。

圖2 OSGi 框架到嵌入式環(huán)境的映射Fig.2 Mapping from OSGi framework to embedded environment

其中硬件/操作系統(tǒng)層因各嵌入式設(shè)備的不同而不同，不在本文研究范圍之內(nèi)。本文所設(shè)計實現(xiàn)的構(gòu)件框架是基于POSIX、RPC、OSGi 等標(biāo)準(zhǔn)所實現(xiàn)的嵌入式軟件構(gòu)件框架，因此具有普遍的適應(yīng)性。

本文的嵌入式軟件構(gòu)件化系統(tǒng)體系結(jié)構(gòu)如圖3所示。

圖3 嵌入式軟件構(gòu)件化系統(tǒng)體系結(jié)構(gòu)Fig.3 Architecture of component－based embedded software system

2.1.1 可插拔實時傳輸協(xié)議適配層

嵌入式系統(tǒng)中設(shè)備種類繁多，設(shè)備之間通信所使用的總線、接口方式及通信協(xié)議也多種多樣，可插拔傳輸協(xié)議適配層就是在原有總線驅(qū)動的基礎(chǔ)上，向上為核心服務(wù)層封裝了一層固定的接口，向下屏蔽了總線及其驅(qū)動程序的差異性。接口形式依據(jù)不同的總線而不同，其中包括了基本的控制接口與數(shù)據(jù)收發(fā)接口[21]。完善的接口應(yīng)支持長數(shù)據(jù)幀的收發(fā)，如用戶數(shù)據(jù)報協(xié)議(UDP)數(shù)據(jù)包最長為2 048字節(jié)等，而封裝后的接口則沒有數(shù)據(jù)幀長度的限制，可以支持長數(shù)據(jù)幀的收發(fā)?？刹灏螌崟r傳輸協(xié)議適配層提供了固定接口的驅(qū)動封裝層，在整個體系結(jié)構(gòu)中是軟件執(zhí)行環(huán)境中的一部分。

基于構(gòu)件化框架所開發(fā)的應(yīng)用依據(jù)自身的設(shè)備環(huán)境對此層進行配置。核心服務(wù)層的部署與配置服務(wù)，通過讀取可插拔實時傳輸協(xié)議適配層的配置文件，動態(tài)加載對應(yīng)的驅(qū)動程序來實現(xiàn)。

2.1.2 核心服務(wù)層

核心服務(wù)層實現(xiàn)了構(gòu)件化框架的核心功能，它是對OSGi 框架的生命周期、模塊和執(zhí)行環(huán)境3 個層次的實現(xiàn)。核心服務(wù)層分為6 個功能模塊:

1)部署與配置

基于OSGi 而構(gòu)建的系統(tǒng)可以以模塊化的方式動態(tài)地部署至框架中，從而增加、擴展或改變系統(tǒng)的功能。OSGi 通過提供Configuration Admin 服務(wù)來實現(xiàn)模塊的動態(tài)配置和統(tǒng)一管理，基于此服務(wù)各模塊的配置可在運行期間進行增加、修改和刪除，所有對于模塊配置的管理統(tǒng)一調(diào)用Configuration Admin 服務(wù)接口來實現(xiàn)。

2)傳輸抽象層

傳輸抽象層負(fù)責(zé)將實時傳輸協(xié)議適配層的數(shù)據(jù)轉(zhuǎn)換為統(tǒng)一的數(shù)據(jù)格式提交給核心服務(wù)層的其他模塊，傳輸抽象層屏蔽了底層多樣的傳輸協(xié)議、不同的接口方式，向上層提供了統(tǒng)一的數(shù)據(jù)格式、一致的接口方式，使整個核心服務(wù)層成為真正的中間件層。

3)遠程服務(wù)管理

在嵌入式分布計算環(huán)境中，構(gòu)件可以使用另一個遠程設(shè)備所提供的服務(wù)，一個構(gòu)件所提供的服務(wù)也是面向整個系統(tǒng)的，也可以被遠端的設(shè)備所使用。遠程服務(wù)管理通過遠程代理(Remote Proxy)、遠程過程調(diào)用(RPC)等技術(shù)為上層提供遠程服務(wù)。

4)遠程服務(wù)自動發(fā)現(xiàn)

遠程服務(wù)自動發(fā)現(xiàn)功能包括自動發(fā)現(xiàn)系統(tǒng)內(nèi)其他節(jié)點和自動發(fā)現(xiàn)系統(tǒng)網(wǎng)絡(luò)中的服務(wù)。自動發(fā)現(xiàn)功能與遠程服務(wù)管理合作實現(xiàn)了分布式構(gòu)件化的功能。本文以簡單服務(wù)發(fā)現(xiàn)協(xié)議(SSDP)為基礎(chǔ)，實現(xiàn)了多鏈路層下系統(tǒng)網(wǎng)絡(luò)服務(wù)發(fā)現(xiàn)機制，使服務(wù)自動發(fā)現(xiàn)更具廣泛性。

SSDP 定義了如何在網(wǎng)絡(luò)上發(fā)現(xiàn)網(wǎng)絡(luò)服務(wù)的方法，SSDP 信息的傳送是依靠HTTPU 和HTTPMU 進行的。設(shè)備接入網(wǎng)絡(luò)之后，要利用它向網(wǎng)絡(luò)廣播自己的存在(廣播的信息中還有設(shè)備位置的描述)，以便盡快與對應(yīng)的控制點建立聯(lián)系;控制點則利用SSDP 來搜索自己將要控制的設(shè)備在哪里。并且可以排除已經(jīng)存在的設(shè)備和控制點，只為新近的或尚未“聯(lián)絡(luò)”上的雙方服務(wù)。

5)本地服務(wù)管理

構(gòu)件以提供服務(wù)的方式來實現(xiàn)功能，本地服務(wù)管理記錄了本地所有構(gòu)件各自所提供的服務(wù)、服務(wù)被引用的次數(shù)，服務(wù)監(jiān)聽、響應(yīng)服務(wù)注冊和請求以及服務(wù)接口的過早請求等功能。

6)構(gòu)件管理

實現(xiàn)了構(gòu)件的啟動、停止、監(jiān)聽等功能。

2.1.3 構(gòu)件接口層

此層是對OSGi 模型中構(gòu)件層和服務(wù)層的實現(xiàn)，一個完整的構(gòu)件從內(nèi)部實現(xiàn)和外部接口描述包含以下5 部分:

1)服務(wù)接口定義

構(gòu)件接口定義采用IDL 文件或純虛函數(shù)的.h 文件，支持標(biāo)準(zhǔn)數(shù)據(jù)類型和自定義數(shù)據(jù)類型。

2)構(gòu)件實現(xiàn)

軟件構(gòu)件是具有獨立業(yè)務(wù)功能、可獨立部署和卸載的軟件實體，軟件構(gòu)件通過向服務(wù)層注冊服務(wù)對外部提供功能服務(wù)，也可以向服務(wù)層請求服務(wù)來獲取其他服務(wù)功能。

一個構(gòu)件實現(xiàn)可以提供零個或多個服務(wù)，因此包含零個或多個服務(wù)接口實現(xiàn)。

3)構(gòu)件啟動器

構(gòu)件實現(xiàn)的啟動器類集成自標(biāo)準(zhǔn)的構(gòu)件啟動器類，構(gòu)件實現(xiàn)者須實現(xiàn)啟動器類的標(biāo)準(zhǔn)函數(shù)，包括start、stop 等函數(shù)，在start 函數(shù)中主要完成注冊構(gòu)件所能提供的服務(wù)服務(wù)，監(jiān)聽構(gòu)件所需的服務(wù)等操作。

4)構(gòu)件描述文件

構(gòu)件描述文件描述了構(gòu)件的基本屬性，其中包括構(gòu)件版本、提供商、加載路徑、服務(wù)接口定義文件以及構(gòu)件的基本屬性等信息。

5)構(gòu)件獲取服務(wù)

構(gòu)件獲取其他構(gòu)件所提供的服務(wù)時通過服務(wù)監(jiān)聽器實現(xiàn)，構(gòu)件以服務(wù)名稱為參數(shù)向框架注冊服務(wù)監(jiān)聽器，框架在接收到對應(yīng)的服務(wù)注冊后主動通知服務(wù)監(jiān)聽器，構(gòu)件在實現(xiàn)的服務(wù)監(jiān)聽器中可以獲取到所需要的服務(wù)。

服務(wù)接口、構(gòu)件實現(xiàn)、構(gòu)件啟動器與服務(wù)監(jiān)聽器之間的關(guān)系如圖4 所示。

圖4 構(gòu)件接口層類圖Fig.4 Class diagram of the component interface layer

BundleContext 是構(gòu)件運行的容器，構(gòu)件啟動器通過BundleContext 所提供的方法與框架進行信息交互，如向框架注冊服務(wù)，向框架注冊服務(wù)監(jiān)聽器等操作;構(gòu)件啟動(BundleActivatorImpl)類是BundleActivator 的接口實現(xiàn)，在實現(xiàn)接口中start 方法完成服務(wù)的注冊與監(jiān)聽;構(gòu)件獲取服務(wù)(ServiceEntity)類是對服務(wù)接口ServiceInterface 的實現(xiàn)，服務(wù)監(jiān)聽器類ServiceListener 在接收到框架對服務(wù)的事件后，可以從框架中獲取到所監(jiān)聽的服務(wù)接口指針。

2.2 傳輸抽象層設(shè)計實現(xiàn)

嵌入式系統(tǒng)中設(shè)備種類繁多，設(shè)備之間通信所使用的總線、接口方式及通信協(xié)議也多種多樣，傳輸抽象層是在原有總線驅(qū)動的基礎(chǔ)上為上層封裝了統(tǒng)一的編程接口，屏蔽了上層軟件程序與各總線驅(qū)動軟件調(diào)用接口的差異。傳輸抽象層在整個嵌入式軟件構(gòu)件化框架中起著承上啟下的作用，對上它統(tǒng)一系統(tǒng)調(diào)用接口;對下它實現(xiàn)與各具體總線通訊的功能。因此，傳輸抽象層的設(shè)計應(yīng)遵循以下4 點設(shè)計原則:

1)傳輸抽象層應(yīng)提供統(tǒng)一套統(tǒng)一的調(diào)用接口，接口函數(shù)應(yīng)盡量簡單、明確，復(fù)雜、繁多的接口會增加軟件系統(tǒng)的復(fù)雜性，不利于錯誤的發(fā)現(xiàn)和定位。

2)傳輸抽象層中的接口函數(shù)在各個不同的嵌入式系統(tǒng)中要保證實現(xiàn)的是相同的功能，否則應(yīng)用程序在不同平臺下會產(chǎn)生錯誤的結(jié)果。

3)傳輸抽象層中的接口函數(shù)應(yīng)盡可能的覆蓋應(yīng)用程序調(diào)用到的全部功能接口，以提供給編程設(shè)計人員較大的靈活性和自主性。

4)傳輸抽象層的接口應(yīng)具有自封閉性、可測試性，由于其處于系統(tǒng)的中間層，出現(xiàn)錯誤時會對應(yīng)用程序的調(diào)試定位產(chǎn)生一定的干擾，因此，系統(tǒng)必須經(jīng)過完備的測試保證嵌入式軟件系統(tǒng)的健壯性。

考慮到傳輸抽象層的特點和實際需求，本文采用軟件設(shè)計中的結(jié)構(gòu)型設(shè)計模式——適配器模式。適配器模式可以將一個具體的接口轉(zhuǎn)換成統(tǒng)一的抽象接口。適配器模式在實現(xiàn)時的類結(jié)構(gòu)如圖5 所示。

圖5 傳輸抽象層適配器模式類結(jié)構(gòu)Fig.5 Class structure of adapter pattern in transmission abstraction layer

圖5中，Client 為使用抽象接口的應(yīng)用;Target定義了Client 使用的與特定領(lǐng)域相關(guān)的接口，Target內(nèi)定義了所有抽象接口;Adaptee 為已經(jīng)存在的接口，也是需要適配具體的接口;Adapter 實現(xiàn)了對Adaptee 的接口與Target 接口的適配。Client 調(diào)用Target 的Request 函數(shù)時通過使用了Adaptee 對象的SpecificRequest 函數(shù)，來實現(xiàn)了對具體接口的抽象功能。

本文傳輸抽象層的主要功能是完成不同類型總線數(shù)據(jù)的收發(fā)，因此適配器主要包含兩個接口，即接收數(shù)據(jù)接口和發(fā)送數(shù)據(jù)接口，如圖6 所示。

圖6 傳輸抽象層適配器接口Fig.6 Interface of adapter pattern in transmission abstraction layer

圖6中TransAdapter 是傳輸接口基類，TransCAN、TransFlexRay、TransMIC 分別代表CAN 總線、FlexRay 總線、MIC 總線的傳輸驅(qū)動封裝實現(xiàn)，其內(nèi)部實現(xiàn)了具體總線通信的驅(qū)動程序，同時還實現(xiàn)了傳輸適配器所要求的發(fā)送和接收數(shù)據(jù)接口。

3 構(gòu)件遠程服務(wù)實現(xiàn)

目前比較流行的分布式計算模型有CORBA、DCOM[22]，還有一些專門基于Java 實現(xiàn)的模型，這些模型大多面向企業(yè)級應(yīng)用，有較完整的體系結(jié)構(gòu)，但應(yīng)用接口太過復(fù)雜，體積龐大，通信協(xié)議單一，且容易出現(xiàn)單點故障，應(yīng)用于嵌入式分布計算環(huán)境難度很大[23]。

遠程過程調(diào)用(RPC)是一種從遠程計算機程序上請求一個服務(wù)器，而不需要了解下層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC 協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP 或自定義傳輸協(xié)議，使得通信程序之間能傳輸信息數(shù)據(jù)，在OIS 網(wǎng)絡(luò)通信模式中跨越了傳輸層和應(yīng)用層。RPC 使得生成應(yīng)用程序包括分布式復(fù)用程序更加容易。

在嵌入式分布計算環(huán)境中，傳輸層需要依據(jù)不同的物理總線和具體的總線傳輸協(xié)議重新實現(xiàn)。相比CORBA，DCOM 等分布式計算模型架構(gòu)，RPC 是一個輕量級的分布式通信模型，更適合應(yīng)用于嵌入式分布計算環(huán)境。

RPC 使用的是客戶機/服務(wù)器模式。請求程序就是一個客戶機，而服務(wù)程序就是一個服務(wù)器。首先，調(diào)用過程發(fā)送一個調(diào)用信息到服務(wù)過程，然后等待應(yīng)答信息。調(diào)用過程包括過程參數(shù)，應(yīng)答信息包括過程結(jié)果。在服務(wù)器端，過程保持睡眠狀態(tài)到調(diào)用信息的到達。當(dāng)一個調(diào)用信息到達，服務(wù)器獲得過程參數(shù)，計算結(jié)果，發(fā)送應(yīng)答信息，然后等待下一個調(diào)用信息。最后，調(diào)用過程接收應(yīng)答信息，獲得過程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進行。

本文所實現(xiàn)的嵌入式分布環(huán)境下的遠程過程調(diào)用依據(jù)RFC1057[24]協(xié)議標(biāo)準(zhǔn)實現(xiàn)，調(diào)用流程如圖7所示。

圖7 遠程過程調(diào)用流程圖Fig.7 RPC flowchart

客戶端代理/服務(wù)器代理:代理是對服務(wù)接口的一層封裝，客戶對服務(wù)的請求由代理執(zhí)行，本文在遠程服務(wù)管理模塊中實現(xiàn)了客戶端/服務(wù)器代理模板類RPCClient，RPCServer，將接口抽象類作為模板參數(shù)傳入即可，如客戶端代理RPCClient ＜Interface ＞，服務(wù)器代理類RPCServer ＜Interface ＞，在實現(xiàn)時，代理是由遠程服務(wù)管理模塊自動生成的，應(yīng)用程序并不需要知道服務(wù)在本地還是在遠程。

傳輸適配器:系統(tǒng)網(wǎng)絡(luò)上各控制點通過傳輸適配器進行信息交互，同樣，RPC 協(xié)議也通過傳輸適配器進行傳輸，這樣同一個服務(wù)代理可以為多條總線上的客戶提供服務(wù)，客戶端也可以從不同的總線上獲取不同的服務(wù)。

RPC 協(xié)議:遠程過程調(diào)用(RPC)信息協(xié)議由兩類不同結(jié)構(gòu)組成:調(diào)用信息和答復(fù)信息。每條調(diào)用信息都包括程序號(prog)、程序版本號(vers)、過程號(proc)三個無符號整數(shù)字段，以獨立識別遠程過程。成功的答復(fù)信息包含調(diào)用服務(wù)接口后的返回結(jié)果，失敗的答復(fù)信息包含調(diào)用失敗的原因。

RPC 協(xié)議從語義上保證了調(diào)用信息和答復(fù)信息對調(diào)用過程及結(jié)果描述的完整性，遠程服務(wù)管理實現(xiàn)了信息鑒定、超時處理，信息長度限制等內(nèi)容。

4 實驗結(jié)果分析

本文所實現(xiàn)的構(gòu)件化框架將開放、靈活的OSGi模型應(yīng)用于嵌入式C++應(yīng)用環(huán)境下，并在VxWorks操作系統(tǒng)中得到了驗證，從內(nèi)存空間、性能約束、實時性等方面保證了此構(gòu)件化框架可應(yīng)用于更苛刻的嵌入式系統(tǒng)環(huán)境。

圖8 是相同嵌入式應(yīng)用軟件在VxWorks 操作系統(tǒng)下，采用本文所實現(xiàn)的分布嵌入式軟件構(gòu)件框架與采用CCM 模型對系統(tǒng)的存儲空間、啟動時間、內(nèi)存容量平均指標(biāo)對比圖。

圖8 框架性能對比Fig.8 Comparison of framework performances

由于CCM 模型主要面向企業(yè)級應(yīng)用，所生成的構(gòu)件實體體積都很大，所占磁盤、內(nèi)存容量較大，啟動時間較長，因此在嵌入分布式環(huán)境下，與本文框架相比在這些性能方面要遜色很多。實驗結(jié)果表明，采用本文所實現(xiàn)的分布嵌入式軟件構(gòu)件框架，與采用CCM 模型相比，相同嵌入式應(yīng)用軟件所需核心庫的容量大小平均降至約1/9，啟動時間平均下降至約3/10，內(nèi)存占用空間平均下降至不到1/5.

圖9 是在分布式應(yīng)用環(huán)境下，采用本文所實現(xiàn)的分布嵌入式軟件構(gòu)件框架與采用CCM 模型的系統(tǒng)服務(wù)實時性的對比圖。

由于CCM 模型中各節(jié)點的構(gòu)件在使用其他節(jié)點構(gòu)件所提供的服務(wù)時，先通過檢索名字服務(wù)器提供的名字服務(wù)來請求服務(wù)，如圖10 所示。且當(dāng)構(gòu)件請求服務(wù)時，需一直保持等待狀態(tài)直至名字服務(wù)器的回應(yīng)結(jié)果才能進行其他任務(wù)，如圖11 所示。因此當(dāng)請求服務(wù)接口大量增多時，名字服務(wù)器處于忙碌狀態(tài)，申請服務(wù)的構(gòu)件等待的時間也急劇增加，系統(tǒng)的服務(wù)接口響應(yīng)時間相應(yīng)急劇增加。如圖9 所示，當(dāng)系統(tǒng)的服務(wù)接口由400 個增加到1 000 個時，響應(yīng)時間由0.01 s 增加到0.018 s，增加了180%.此外，若名字服務(wù)器發(fā)生故障，則整個系統(tǒng)的請求服務(wù)均不能進行，造成單點故障問題。

圖10 CCM 模型節(jié)點請求服務(wù)模式Fig.10 Pattern of service request between nodes in CCM

圖11 CCM 模型節(jié)點請求服務(wù)執(zhí)行流程Fig.11 Flow－process of service request between nodes in CCM

而本文所實現(xiàn)的分布嵌入式軟件構(gòu)件框架中，各節(jié)點構(gòu)件僅需通過本節(jié)點自帶的簡單服務(wù)發(fā)現(xiàn)協(xié)議(SSDP)，向其他節(jié)點的構(gòu)件請求服務(wù)，節(jié)點之間直接通信避免了單點故障問題，如圖12 所示。本節(jié)點的服務(wù)發(fā)現(xiàn)協(xié)議一旦與要調(diào)用的節(jié)點控件聯(lián)系上，便通知本節(jié)點構(gòu)件，系統(tǒng)內(nèi)的其他構(gòu)件在此期間可以繼續(xù)工作而不受影響不用等待，如圖13 所示。

圖12 本文框架請求服務(wù)模式Fig.12 Pattern of service request between nodes in the framework of this article

由圖9 可以看出，當(dāng)系統(tǒng)的服務(wù)接口由400 個增加到1 000 個時，本文框架系統(tǒng)響應(yīng)時間不僅絕對值比CCM 模型的低，僅由0.004 s 增加到0.005 s，且變化的相對值也低，僅增加了25%.顯然本文框架更適合應(yīng)用于對實時性要求高的嵌入分布式系統(tǒng)。

圖13 本文框架請求服務(wù)執(zhí)行流程Fig.13 Flow－process of service request between nodes in the framework of this article

5 結(jié)論

本文所研究的構(gòu)件化框架將OSGi 框架模型應(yīng)用于嵌入式C++應(yīng)用環(huán)境下，通過加入傳輸抽象層實現(xiàn)了在多通信協(xié)議環(huán)境下的嵌入式軟件構(gòu)件化框架，為動態(tài)可擴展的系統(tǒng)開發(fā)提供了支持。與目前通用的EJB、CORBA 組件模型(CCM)等分布式構(gòu)架框架技術(shù)相比，能解決其單點故障、構(gòu)件實體體積大等問題，更適用于對系統(tǒng)啟動時間、磁盤內(nèi)存有嚴(yán)格要求的嵌入式分布計算環(huán)境。通過實驗數(shù)據(jù)驗證了本文框架的系統(tǒng)存儲空間、啟動時間、內(nèi)存容量、服務(wù)實時性等性能均高于CCM 模型框架，具有一定的工程應(yīng)用價值。

References)

[1]齊勇，趙季中，侯迪.基于Web 的中間件系統(tǒng)集成框架——應(yīng)用服務(wù)器的研究[J].計算機研究與發(fā)展，2001，38 (4):430－437.QI Yong，ZHAO Ji－zhong，HOU Di.Study of application serverweb－based middleware system integrated framework[J].Journal of Computer Research ＆Development，2011，38(4):430 －437.(in Chinese)

[2]Lau K K，Wang Z.Software computer models[J].IEEE Transactions on Software Engineering，2007，33(10):709 － 724.

[3]Manolios P，Subramanian G，Vroon D.Automating componentbased system assembly[C]∥Proceedings of the 2007 International Symposium on Software Testing and Analysis.New York:NY，2007:61 －72.

[4]Crnkovic I，Schmidt H，Stafford J，et al.Automated componentbased software engineering[J].Journal of Systems and Software，2005，74(1):1 －3.

[5]Cao F，Bryant B R，Burt C C，et al.A component assembly approach based on aspect－oriented generative domain modeling[J].Electronic Notes in Theoretical Computer Science，2005，114(1):119 －136.

[6]劉國梁，魏峻，馮玉琳.基于組件模型分析的組件容器產(chǎn)品線體系結(jié)構(gòu)[J].軟件學(xué)報，2010，21(1):68 －83.LIU Guo－liang，WEI Jun，F(xiàn)ENG Yu－lin.Container product line architecture base on component model analysis[J].Journal of Software，2010，21(1):68 －83.(in Chinese)

[7]王瓊，杜承烈，蔡小斌，等.基于構(gòu)件的中間件體系結(jié)構(gòu)集成形式化研究[J].計算機科學(xué)，2010，37(8):164 －167.WANG Qiong，DU Cheng－lie，CHAI Xiao－bin，et al.Research of integration of middleware architecture[J].Computer Science，2010，37(8):164 －167.(in Chinese)

[8]彭云峰，姚琳，趙沖沖，等.并行構(gòu)件技術(shù)研究綜述[J].計算機科學(xué)，2011，38(2):18 －27.PENG Yun－feng，YAO Lin，ZHAO Chong－chong，et al.Overview of technologies for parallel component[J].Computer Science，2011，38(2):18 －27.(in Chinese)

[9]彭天翔，曹旻.基于中間件的Web 應(yīng)用組合工具的研究[J].計算機工程與設(shè)計，2010，31(7):1500 －1502，1634.PENG Tian－xiang，CAO Min.Research on middleware－based Web application integration tool[J].Computer Engineering and Design，2010，31(7):1500 －1502，1634.(in Chinese)

[10]胡劍軍，官荷卿，魏峻，等.一種基于性能模型的中間件自配置框架[J].軟件學(xué)報，2007，18(9):2117 －2129.HU Jian－jun，GUAN He－qing，WEI Jun，et al.A performance model－based self－configuration framework for middleware[J].Journal of Software，2007，18(9):2117 － 2129.(in Chinese)

[11]Frank Buschmann，Kevlin Henney，Douglas C.Schmidt.面向模式的軟件架構(gòu):分布式計算的模式語言:第4 卷[M].肖鵬，陳立，譯.北京:人民郵電出版社，2010:9 －17.Buschmann F，Henney K，Schmidt D C.Pattern－oriented software architecture:a pattern language for distributed computing:volume 4[M].XIAO Peng，CHEN Li，translation.Beijing:Posts ＆ Telecom Press，2010:9 －17.(in Chinese)

[12]Komoda N.Service oriented architecture(SOA)in industrial system[C]∥Proceedings of IEEE International Conference on Industrial Informatics.Washington:IEEE，2006:1 －5.

[13]Broll W，Lindt I，Herbst I，et al.Toward next－gen mobile AR games[J].IEEE Computer Graphics and Application，2008，28(4):40 －48.

[14]李磊，王懷民.CORBA 與EJB 集成技術(shù)的研究[J].計算機科學(xué)，2001，28(6):27 －29.LI Lei，WANG Huai－min.The integration studu of CORBA and EJB[J].Computer Science，2001，28(6):27 －29.(in Chinese)

[15]黃罡，張路，周明輝.構(gòu)件化軟件設(shè)計與實現(xiàn)[M].北京:清華大學(xué)出版社，2008:198 －204.HUANG Gang，ZHANG Lu，ZHOU Ming－h(huán)ui.Design and Implementation of component－based software[M].Beijing:Tsinghua University Press，2008:198 －204.(in Chinese)

[16]陳波，李舟軍，陳火旺.構(gòu)件模型研究綜述[J].計算機工程與科學(xué)，2008，30(1):105 －109.CHEN Bo，LI Zhou－jun，CHEN Huo－wang.Research on component models:a survey[J].Computer Engineering ＆ Science，2008，30(1):105 －109.(in Chinese)

[17]甄甫，劉民，董明宇.基于面向服務(wù)架構(gòu)消息中間件的業(yè)務(wù)流程系統(tǒng)集成方法研究[J].計算機集成制造系統(tǒng)，2009，15(5):968 －972.ZHEN Fu，LIU Min，DONG Ming－yu.SOA message－oriented middleware based system integration method for business process[J].Computer Integrated Manufacturing Systems，2009，15(5):968 －972.(in Chinese)

[18]Gruber O，Hargrave B J，McAffer J，et al.The Eclipse 3.0 platform:adopting OSGi technology[J].IBM Systems Journal，2005，44(2):289 －299.

[19]OSGi Alliance.OSGi service platform core specification release 4 version 4.3[EB/OL].2011－04－01.http:∥www.osgi.org/Download/Release4V43.

[20]楊春陽，劉兵.基于OSGi 規(guī)范的“智能化”嵌入式應(yīng)用開發(fā)[J].儀器儀表學(xué)報，2004，25(4):624 －626.YANG Chun－yang，LIU Bing.“Smart”application development based on OSGi specification[J].Chinese Journal of Scientific Instrument，2004，25(4):624 －626.(in Chinese)

[21]何小朝.消息設(shè)計與開發(fā):分布式應(yīng)用開發(fā)的核心技術(shù)[M].北京:電子工業(yè)出版社，2011:13.HE Xiao－chao.Design and development of message:the core technologies of distributed application development[M].Beijing:Publishing House of Electronics Industry，2011:13.(in Chinese)

[22]Sharp D.Real－time distributed object computing:ready for mission－critical embedded system applications[C]∥Proceedings of the Third International Symposium on Distributed Objects and Applications (DOA'01).Rome:IEEE，2001:3 －4.

[23]韋華穎，詹劍鋒，王沁.分布式構(gòu)件技術(shù)綜述[J].計算機應(yīng)用研究，2004，21(10):12 －15，32.WEI Hua－ying，ZHAN Jian－feng，WANG Qin.Overview of distributed component technologies[J].Application Research of Computers，2004，21(10):12 －15，32.(in Chinese)

[24]Sun Microsystems，Inc.RFC 1057－RPC:remote procedure call protocol specification:version 2[EB/OL].1988－06－01.http:∥www.rfc－editor.org/rfc/rfc1057.txt.