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

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

0 引言

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

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

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

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

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

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

1 OSGi 框架模型

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

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

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

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

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

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

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

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

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

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

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

構(gòu)件:構(gòu)件是具有獨(dú)立業(yè)務(wù)功能、可獨(dú)立部署和卸載的軟件實(shí)體。軟件構(gòu)件通過(guò)向服務(wù)層注冊(cè)服務(wù)對(duì)外部提供功能服務(wù)，也可以向服務(wù)層請(qǐng)求服務(wù)來(lái)獲取其他服務(wù)功能。

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

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

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

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

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

其中硬件/操作系統(tǒng)層因各嵌入式設(shè)備的不同而不同，不在本文研究范圍之內(nèi)。本文所設(shè)計(jì)實(shí)現(xiàn)的構(gòu)件框架是基于POSIX、RPC、OSGi 等標(biāo)準(zhǔn)所實(shí)現(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 可插拔實(shí)時(shí)傳輸協(xié)議適配層

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

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

2.1.2 核心服務(wù)層

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

1)部署與配置

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

2)傳輸抽象層

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

3)遠(yuǎn)程服務(wù)管理

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

4)遠(yuǎn)程服務(wù)自動(dòng)發(fā)現(xiàn)

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

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

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

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

6)構(gòu)件管理

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

2.1.3 構(gòu)件接口層

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

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

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

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

軟件構(gòu)件是具有獨(dú)立業(yè)務(wù)功能、可獨(dú)立部署和卸載的軟件實(shí)體，軟件構(gòu)件通過(guò)向服務(wù)層注冊(cè)服務(wù)對(duì)外部提供功能服務(wù)，也可以向服務(wù)層請(qǐng)求服務(wù)來(lái)獲取其他服務(wù)功能。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖5 傳輸抽象層適配器模式類(lèi)結(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 實(shí)現(xiàn)了對(duì)Adaptee 的接口與Target 接口的適配。Client 調(diào)用Target 的Request 函數(shù)時(shí)通過(guò)使用了Adaptee 對(duì)象的SpecificRequest 函數(shù)，來(lái)實(shí)現(xiàn)了對(duì)具體接口的抽象功能。

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

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

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

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

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

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

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

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

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

圖7 遠(yuǎn)程過(guò)程調(diào)用流程圖Fig.7 RPC flowchart

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

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

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

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

4 實(shí)驗(yàn)結(jié)果分析

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

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

圖8 框架性能對(duì)比Fig.8 Comparison of framework performances

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

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

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

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

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

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

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

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

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

References)

[1]齊勇，趙季中，侯迪.基于Web 的中間件系統(tǒng)集成框架——應(yīng)用服務(wù)器的研究[J].計(jì)算機(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]劉國(guó)梁，魏峻，馮玉琳.基于組件模型分析的組件容器產(chǎn)品線體系結(jié)構(gòu)[J].軟件學(xué)報(bào)，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].計(jì)算機(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].計(jì)算機(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].計(jì)算機(jī)工程與設(shè)計(jì)，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é)報(bào)，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):分布式計(jì)算的模式語(yǔ)言:第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].計(jì)算機(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è)計(jì)與實(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].計(jì)算機(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].計(jì)算機(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]楊春陽(yáng)，劉兵.基于OSGi 規(guī)范的“智能化”嵌入式應(yīng)用開(kāi)發(fā)[J].儀器儀表學(xué)報(bào)，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è)計(jì)與開(kāi)發(fā):分布式應(yīng)用開(kāi)發(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].計(jì)算機(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.