嵌入式分布计算环境下的高效软件构件化框架研究

曹敬瑜，柴玮岩，王博，郭永红

(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.