嵌入式分布計算環境下的高效軟件構件化框架研究

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

(1.北京理工大學 計算機學院，北京 100081;2.中國兵器工業計算機應用技術研究所，北京 100089)

0 引言

當今嵌入式分布計算環境中所涉及的嵌入式設備越來越多，所涉及的現場總線、通信協議也種類繁多，導致嵌入式軟件的開發難度和維護成本也越來越高，如何通過構件化框架技術[1]簡化嵌入式軟件的設計，通過模塊重用的思想減少開發的工作量，提高系統的穩定性已成為亟待解決的問題[2－6]。

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

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

發布/訂閱中間件(面向消息的中間件[17])技術以MQ 系列、Java 消息服務(JMS)、數據分發服務(DDS)為代表，其主要優點是支持異步通信，發送方在傳送數據給接收方后不需要被阻塞以等待接收方的響應。但是其缺少面向對象、面向服務的特性，不適合應用于關心操作結果或操作非等冪的軟件環境。

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

針對上述問題，本文提出了在嵌入式分布計算環境下的高效軟件構件化框架，目的是使嵌入式軟件系統朝著通用化、標準化、系列化、構件化、平臺化的方向發展，為系統內外的互連、互通提供穩定可靠的保障。

1 OSGi 框架模型

開放服務網關倡議(OSGi)旨在建立一個由廣域網向區域網及其相聯的設備傳輸各類服務的開放式標準。它為服務供應商、網絡管理員、設備開發商和軟件開發商提供了一個開放、通用的架構，使他們能互動地開發、部署和管理服務。

基于OSGi 標準的軟件模塊化已經成為主流的軟件開發和集成方式。Eclipse 是目前著名的一個集成開發環境(IDE)，其最大的兩個特點是插件和擴展，而其插件機制正是通過實現OSGi 規范實現的[18]。它支持模塊化的動態部署、封裝和交互、支持模塊的動態配置、是一種面向服務的構件模型。

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

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

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

執行環境:在硬件和操作系統之上標準的基礎軟件開發環境，如POSIX 操作環境，標準的協議環境(TCP/IP 協議族協議、RPC 等)，開源庫環境(ACE、boost 等)。

模塊層:該層負責動態加卸載軟件構件。一個完整的軟件構件由構件可執行體(.out，.so 文件)及構件描述文件組成，構件描述文件中包括構件名稱、優先級、構件內存大小、構件自身配置的屬性信息。

在加載構件時，模塊層通過解析描述文件，動態加載構件可執行體，并為構件分配內存，提供可執行環境，記錄下構件運行優先級及構件配置的屬性信息，即為構件執行建立一個容器。

在卸載構件時，模塊層負責回收分配的內存，刪除構件執行容器，并在系統中卸載構件可執行體。

生命周期層:該層主要負責軟件構件的安裝、啟動、更新、停止、卸載等操作。

服務層:軟件構件可以向服務層注冊零個或多個服務，服務層主要功能是注冊服務和撤銷服務，另外，還可以根據特定的服務屬性來查找目標服務。

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

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

2 嵌入式軟件構件框架研究

2.1 基于OSGi 的嵌入式軟件構件框架

將OSGi 框架映射到嵌入式分布環境對應關系如圖2 所示。

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

其中硬件/操作系統層因各嵌入式設備的不同而不同，不在本文研究范圍之內。本文所設計實現的構件框架是基于POSIX、RPC、OSGi 等標準所實現的嵌入式軟件構件框架，因此具有普遍的適應性。

本文的嵌入式軟件構件化系統體系結構如圖3所示。

圖3 嵌入式軟件構件化系統體系結構Fig.3 Architecture of component－based embedded software system

2.1.1 可插拔實時傳輸協議適配層

嵌入式系統中設備種類繁多，設備之間通信所使用的總線、接口方式及通信協議也多種多樣，可插拔傳輸協議適配層就是在原有總線驅動的基礎上，向上為核心服務層封裝了一層固定的接口，向下屏蔽了總線及其驅動程序的差異性。接口形式依據不同的總線而不同，其中包括了基本的控制接口與數據收發接口[21]。完善的接口應支持長數據幀的收發，如用戶數據報協議(UDP)數據包最長為2 048字節等，而封裝后的接口則沒有數據幀長度的限制，可以支持長數據幀的收發。可插拔實時傳輸協議適配層提供了固定接口的驅動封裝層，在整個體系結構中是軟件執行環境中的一部分。

基于構件化框架所開發的應用依據自身的設備環境對此層進行配置。核心服務層的部署與配置服務，通過讀取可插拔實時傳輸協議適配層的配置文件，動態加載對應的驅動程序來實現。

2.1.2 核心服務層

核心服務層實現了構件化框架的核心功能，它是對OSGi 框架的生命周期、模塊和執行環境3 個層次的實現。核心服務層分為6 個功能模塊:

1)部署與配置

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

2)傳輸抽象層

傳輸抽象層負責將實時傳輸協議適配層的數據轉換為統一的數據格式提交給核心服務層的其他模塊，傳輸抽象層屏蔽了底層多樣的傳輸協議、不同的接口方式，向上層提供了統一的數據格式、一致的接口方式，使整個核心服務層成為真正的中間件層。

3)遠程服務管理

在嵌入式分布計算環境中，構件可以使用另一個遠程設備所提供的服務，一個構件所提供的服務也是面向整個系統的，也可以被遠端的設備所使用。遠程服務管理通過遠程代理(Remote Proxy)、遠程過程調用(RPC)等技術為上層提供遠程服務。

4)遠程服務自動發現

遠程服務自動發現功能包括自動發現系統內其他節點和自動發現系統網絡中的服務。自動發現功能與遠程服務管理合作實現了分布式構件化的功能。本文以簡單服務發現協議(SSDP)為基礎，實現了多鏈路層下系統網絡服務發現機制，使服務自動發現更具廣泛性。

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

5)本地服務管理

構件以提供服務的方式來實現功能，本地服務管理記錄了本地所有構件各自所提供的服務、服務被引用的次數，服務監聽、響應服務注冊和請求以及服務接口的過早請求等功能。

6)構件管理

實現了構件的啟動、停止、監聽等功能。

2.1.3 構件接口層

此層是對OSGi 模型中構件層和服務層的實現，一個完整的構件從內部實現和外部接口描述包含以下5 部分:

1)服務接口定義

構件接口定義采用IDL 文件或純虛函數的.h 文件，支持標準數據類型和自定義數據類型。

2)構件實現

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

一個構件實現可以提供零個或多個服務，因此包含零個或多個服務接口實現。

3)構件啟動器

構件實現的啟動器類集成自標準的構件啟動器類，構件實現者須實現啟動器類的標準函數，包括start、stop 等函數，在start 函數中主要完成注冊構件所能提供的服務服務，監聽構件所需的服務等操作。

4)構件描述文件

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

5)構件獲取服務

構件獲取其他構件所提供的服務時通過服務監聽器實現，構件以服務名稱為參數向框架注冊服務監聽器，框架在接收到對應的服務注冊后主動通知服務監聽器，構件在實現的服務監聽器中可以獲取到所需要的服務。

服務接口、構件實現、構件啟動器與服務監聽器之間的關系如圖4 所示。

圖4 構件接口層類圖Fig.4 Class diagram of the component interface layer

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

2.2 傳輸抽象層設計實現

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

1)傳輸抽象層應提供統一套統一的調用接口，接口函數應盡量簡單、明確，復雜、繁多的接口會增加軟件系統的復雜性，不利于錯誤的發現和定位。

2)傳輸抽象層中的接口函數在各個不同的嵌入式系統中要保證實現的是相同的功能，否則應用程序在不同平臺下會產生錯誤的結果。

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

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

考慮到傳輸抽象層的特點和實際需求，本文采用軟件設計中的結構型設計模式——適配器模式。適配器模式可以將一個具體的接口轉換成統一的抽象接口。適配器模式在實現時的類結構如圖5 所示。

圖5 傳輸抽象層適配器模式類結構Fig.5 Class structure of adapter pattern in transmission abstraction layer

圖5中，Client 為使用抽象接口的應用;Target定義了Client 使用的與特定領域相關的接口，Target內定義了所有抽象接口;Adaptee 為已經存在的接口，也是需要適配具體的接口;Adapter 實現了對Adaptee 的接口與Target 接口的適配。Client 調用Target 的Request 函數時通過使用了Adaptee 對象的SpecificRequest 函數，來實現了對具體接口的抽象功能。

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

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

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

3 構件遠程服務實現

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

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

在嵌入式分布計算環境中，傳輸層需要依據不同的物理總線和具體的總線傳輸協議重新實現。相比CORBA，DCOM 等分布式計算模型架構，RPC 是一個輕量級的分布式通信模型，更適合應用于嵌入式分布計算環境。

RPC 使用的是客戶機/服務器模式。請求程序就是一個客戶機，而服務程序就是一個服務器。首先，調用過程發送一個調用信息到服務過程，然后等待應答信息。調用過程包括過程參數，應答信息包括過程結果。在服務器端，過程保持睡眠狀態到調用信息的到達。當一個調用信息到達，服務器獲得過程參數，計算結果，發送應答信息，然后等待下一個調用信息。最后，調用過程接收應答信息，獲得過程結果，然后調用執行繼續進行。

本文所實現的嵌入式分布環境下的遠程過程調用依據RFC1057[24]協議標準實現，調用流程如圖7所示。

圖7 遠程過程調用流程圖Fig.7 RPC flowchart

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

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

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

RPC 協議從語義上保證了調用信息和答復信息對調用過程及結果描述的完整性，遠程服務管理實現了信息鑒定、超時處理，信息長度限制等內容。

4 實驗結果分析

本文所實現的構件化框架將開放、靈活的OSGi模型應用于嵌入式C++應用環境下，并在VxWorks操作系統中得到了驗證，從內存空間、性能約束、實時性等方面保證了此構件化框架可應用于更苛刻的嵌入式系統環境。

圖8 是相同嵌入式應用軟件在VxWorks 操作系統下，采用本文所實現的分布嵌入式軟件構件框架與采用CCM 模型對系統的存儲空間、啟動時間、內存容量平均指標對比圖。

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

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

圖9 是在分布式應用環境下，采用本文所實現的分布嵌入式軟件構件框架與采用CCM 模型的系統服務實時性的對比圖。

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

圖10 CCM 模型節點請求服務模式Fig.10 Pattern of service request between nodes in CCM

圖11 CCM 模型節點請求服務執行流程Fig.11 Flow－process of service request between nodes in CCM

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

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

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

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

5 結論

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

References)

[1]齊勇，趙季中，侯迪.基于Web 的中間件系統集成框架——應用服務器的研究[J].計算機研究與發展，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]劉國梁，魏峻，馮玉琳.基于組件模型分析的組件容器產品線體系結構[J].軟件學報，2010，21(1):68 －83.LIU Guo－liang，WEI Jun，FENG Yu－lin.Container product line architecture base on component model analysis[J].Journal of Software，2010，21(1):68 －83.(in Chinese)

[7]王瓊，杜承烈，蔡小斌，等.基于構件的中間件體系結構集成形式化研究[J].計算機科學，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]彭云峰，姚琳，趙沖沖，等.并行構件技術研究綜述[J].計算機科學，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 應用組合工具的研究[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].軟件學報，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.面向模式的軟件架構:分布式計算的模式語言:第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 集成技術的研究[J].計算機科學，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]黃罡，張路，周明輝.構件化軟件設計與實現[M].北京:清華大學出版社，2008:198 －204.HUANG Gang，ZHANG Lu，ZHOU Ming－hui.Design and Implementation of component－based software[M].Beijing:Tsinghua University Press，2008:198 －204.(in Chinese)

[16]陳波，李舟軍，陳火旺.構件模型研究綜述[J].計算機工程與科學，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]甄甫，劉民，董明宇.基于面向服務架構消息中間件的業務流程系統集成方法研究[J].計算機集成制造系統，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 規范的“智能化”嵌入式應用開發[J].儀器儀表學報，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]何小朝.消息設計與開發:分布式應用開發的核心技術[M].北京:電子工業出版社，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]韋華穎，詹劍鋒，王沁.分布式構件技術綜述[J].計算機應用研究，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.