LooCI

原文：LooCI:the Loosely-coupled Component infrastructure

部分翻译：（不含图表）

本翻译纯属个人兴趣，请勿转载，谢谢合作。

如有翻译错误欢迎指正。

III．需求

基于对数个WSN部署原型的回顾，以及II中阐述的相关工作，我们为WSN组建设施中间件需求做了如下定义：

        异质性。在WSN方案中使用了各异的硬件设施，包括motes，智能电话，嵌入式Linux板。组件设施中间件因而必须为应用在各异的平台上发展提供共同的基础，同时允许各平台的优势能被全面的开发利用。

        协同工作。不同传感器节点及终端计算设施之间需要协同工作。因此组件设施中间件必须通过使用共同网络以及数据交换标准，来促使在各异设备上运行的组件的组合方式成为协作的应用。

        结构变形。WSN方案需要支持包括细粒度软件评估、基本应用重测、以及针对变化的环境条件与应用需求的自适应在内的结构变形。组件设施中间件因此必须支持软件功能性结构变形，并允许对现状进行有效具体化（即发展与分析）。

        分布式关系。为了在变化的拓扑结构中最大化组件的再利用，在本地组件实施与分布问题之间必须有一种稳固的隔离。由此产生的缺失会最终限制组件对单一网络环境的益处。组件设施中间件因此必须支持灵活捆绑形式以及简洁的本地与分布式功能的隔离。

        工作情况。即便在嵌入式mote平台上，WSN的组件设施中间件应当消耗最小存储空间并提供良好效果。中间件应当允许对异质资源的全面开发，同时增强组件及应用开发者的最小负担。

         在接下来的部分我们介绍LooCI；一种WSN组件设备中间件用以实现这些需求。

IV．松散耦合组件设备

        LooCI是一种平台独立的组件设备中间件。其结构如图1.

        LooCI允许独立的组件在运行时被部署到motes上。组件由重组管理者管理，并仅通过分布式事件总线（distributed event bus）通信。重组管理者提供推荐给所有本里组件，并规定进来的部署、控制、内省及捆绑通过事件总线接收到的指令。使用内省的一方可以发现目前在节点上的组件及其接口、当前状态及捆绑。

        为了察觉分布式事件总线，每一个LooCI节点使用一个本地事件管理者。事件管理者持有本地及远程捆绑列表，包含标明下一个本地及（或）远程组件事件的入口。所有预定都被本地持有，以排除对分布协调或专门的中间人的需求。虽然在逻辑上组件通过它们的接口交换事件从而直接交流，但实际上这些事件是通过事件管理者以及（如果发送给远程节点）网络架构和底层平台传递的。

        网络架构将底层平台提供的网络服务标准化，并提供统一的API给上层。网络服务的一种可扩展设定提供了包括全网络广播、单跳广播和单播。这使事件总线对底层网络协议不可知。即便组件不直接使用网络架构而是仅通过事件总线通信，这对节点很重要。

        LooCI提供的重组平台允许组件运行时部署及重组和捆绑。为了预防恶意组织利用这些特征在WSN上攻击或窃听，我们开发了一个安全部署协议和在组件接口层实现访问限制的机制。由于篇幅限制，我们请感兴趣的读者参阅原文。

        由于LooCI是平台独立的中间件说明书，它提供了多种底层执行环境之间的协同工作能力。目前LooCI支持Contiki，Squawk和OSGi。

A．LooCI重组组件模型

        LooCI组件是功能性独立部署的单元.它们通过控制API来管理，并通过简单的通信API与事件总线连接。LooCI组件建立在底层平台（例如contiki模块，Squawk套件或OSGi捆）部署的单元上。这允许开发者利用各种语言、操作系统和硬件平台提供的所有特性，而提供组件的标准化的封装、拓展和生命周期管理。LooCI也因此需要被视为允许应用开发者整合可能分布在异质节点上的软件资源的协作层。

        表征LooCI组件用到两点特征：（1）组件的用户定义名称，以及（2）由LooCI运行时提供的ID是主节点环境中唯一的。LooCI组件因此可以由数组<node address, componentID>来唯一表征。

        典型的LooCI组件实现细粒度应用级功能并通过捆绑到事件总线来构成分布式应用。为了这一目的，每一个组件包括数个接口，这些接口组成它们的通信API。供给接口描述了组件可能发布到总线上的事件，同时需求接口描述了组件可能从总线上读取的事件。这些接口根据分类系统（在IV.B部分讨论）来分类。从逻辑上捆绑连接了供给接口与需求接口。

        列表1和2提供了LooCI组件提供聚合的示例代码。列表1展示Java代码，能兼容Squawk和OSGi的LooCI端口。列表2展示了Contiki的C组件。功能性代码和库导入省略以节省空间。聚合器组件有一个SENSOR类型的需求接口和一个AGG_SENSOR类型的供给接口。由于我们建立在现存的语言及操作系统上，我们已非常仔细的最小化声明LooCI组件所需要的工作。如列表1所示，基于Java的LooCI端口需要1行代码来声明有接口和容器的组件。相反，C/Contiki版本的LooCI需要2行代码来声明组件，及额外的一行需求接口代码和一行供给接口代码。在所有的平台上，明确需求接口的组件也必须实现事件处理程序来解决到来的事件。

B. LooCI的分层类型系统

        LooCI提供允许开发者创建共享的事件类型概念化。LooCI类型系统把所有事件组织到分类系统从而提供每一个事件语义意义。层次分类法也允许基于多组机能等效事件的推理。LooCI分类系统提供一下优势：

·        类型安全重组。每一个接口都嵌入它在类型层次的位置。在捆绑时，这用来确认类型安全性和阻止不匹配接口的捆绑。由于匹配测试在所有LooCI节点可实现，这一功能能够用来构建自适应系统。

·        服务拓展。为了发展服务满足组件的依赖关系（需求接口），包含需求类型的getProvidedInterfaces指令被发送到单一或群组节点上。收到这一查询的节点通过返回所有本地供给接口的引用做出响应，这些接口是请求中指定类型的子类。

·        减少开销。分层类型系统通过允许开发者以类（如所有在节点上的SENSOR组件可能用单布线操作捆绑在记录仪上而不是用多操作捆绑到每个SENSOR的子类上）引用来减少捆绑和内省的开销。

       LooCI分类系统使用基于素数的编码体系，其中所有事件类型e­­_i被划分到一个分层分类中，并与素数p_i相关。当事件类型e_j被增加为e_i的子事件时，我们保存一个唯一识别码uid_j，通过将p_j与uid_j相乘计算得到。由此，uid_j唯一编码了e_j在分层中的位置，该位置与其父事件相关。在运行时，我们能够通过将uid_j与uid_i相除来高效计算出类型e_j中的事件和对应的uid_j是否为事件e_i的子类型。如果这一运算的结果没有余数，那么根据素数的唯一性，e_j一定为e_i的子类型（这一性质的正规证明在文献【21】中提供）。每种类型的uid只有在部署、捆绑、和自省时传送。

C．LooCI的分布式事件总线

        LooCI事件总线是异步的、基于事件的通信媒体，它伴随着一种基于分散主题的发布-订阅模型。事件根据IV.B部分表述的分类系统来分类，并只能够被类型兼容的接口发布和接收。LooCI中发布-订阅模型的应用提供组件之间的松散耦合，并消除了对昂贵的分布式静止协议的需求。

        为了通信，组件必须捆绑到一起。这发生在相关组件部署之后的运行时。捆绑是存储在事件管理者的捆绑列表中的人工产物，它能够清楚地连接发布组件的供给接口和与之兼容的订阅组件的需求接口。事件管理者拥有两个捆绑列表：一个用作捆绑两个本地组件的本地捆绑列表，和一个用作分布式捆绑一个本地组件与一个远程组件的远程捆绑列表。远程捆绑列表示例如图1所示。通常情况下，捆绑定义为<source event type, sourcecomponent ID, source address, destination event type, destination component ID,destination address>的数组形式。捆绑仅允许在兼容的接口之间进行，由它们的类型确定，如IV.B部分介绍。LooCI支持如下捆绑模式：

·        一对一捆绑通过发送一个标识唯一的供给接口和远程目标wireTo事件给源节点实现。发送标识唯一源接口和本地目标接口的wireFrom事件给目标节点。

·        一对多捆绑通过发送一个wireTo事件给源节点，该节点标识唯一的供给接口和一个通配符目标（网络广播或单跳广播）。然后指定源地址、唯一源接口和本地目标接口的wireFrom事件被广播到所有的目标节点。（注意：多对一捆绑通过反转这一系列操作来建立的。）

·        机会性捆绑通过发送一个标识供给接口类型和单跳广播通配符的wireTo事件给所有源节点实现。然后标明通配符源地址、通配符源组件ID、源接口类型和本地目标接口的wireFrom事件被发送到目标节点。

       值得注意的是组件既不发送也不接收事件直到它们被捆绑和激活。由于数据是根据语义分类的，所有通信通过精准捆绑发生，因此可能被用作使分布式关系和重组具体化的自省也可能被用作修改运行时的数据流。

D．API和管理支持

        为了部署或重组组件并在运行时捆绑，核心LooCI API如列表3所示。Countrol，Introspection和BindingAPI由重组管理者通过事件总线发布，并通过网关对终端系统元件可用。由于节点不可直接接触组件库，Deployment API仅通过网关对终端系统元件可用。包括最少功能的核心API需要管理LooCI节点的网络，同时当其可由开发者直接使用时我们期望它可以被更广泛的用作高层服务的建立。此类工具的具体示例包括QARI和PMA。

V．实现与评估

        在这一部分我们介绍了三种LooCI的实现方法，并用以评估所设计的LooCI。V.A部分定量了LooCI在每种评估平台上的开销，V.B部分比较了LooCI与其他基于重组组件的WSN中间件，V.C部分评估了LooCI的网络开销。

        LooCI的实施目前对Contiki, Squawk和OSGi可实现。表1总结了每一种LooCI实施以及评估中所用到的硬件平台。所有实施如实实现了IV部分描述的设计。共同的类型系统和事件总线确保了所有LooCI端口流畅互动，考虑了集成Contiki, Squawk和OSGi节点的组合。

A．LooCI的存储和性能开销

        LooCI自身的存储开销有额外的闪存和执行环境使用的RAM组成。由表2可见，LooCI在所有的测试平台上运行良好。在最坏情况下，在Raven中，结合的LooCI和Contiki图像剩余了超过54%的闪存和38%的RAM可用作应用开发。在SPOT和GumStix上，闪存和RAM的大量主体仍然可用。不仅有紧凑的中间件占用，应用组件紧凑也很关键。表3比较了对于Contiki, Squawk和OSGi，LooCI温度传感器组件的功能性等效实施的大小。

        表3显示，LooCI-Contiki和LooCI-OSGi组件的RAM花费比等效的Contiki或OSGi模块少。这是因为分布式支持已经包含在LooCI中间件中，不需要嵌入到组件中。LooCI-Contiki的闪存开销也较少，而LooCI-OSGi的略多。在LooCI-Squawk的情况中，组件化增加了极小的闪存开销，但由于每一个组件都运行了Inter-Isolate RPC服务器用以运行时与LooCI通信，因此有明显的RAM开销。然而5120字节的RAM开销为常数，因此随着组件尺寸的增加会愈加不重要。

        根据实例化和捆绑组件的时间需求，我们定义了性能开销。表4总结了LooCI毫秒级的性能时间。LooCI组件上的初始化和捆绑操作在所有的评估平台上都很快。此外LooCI分类系统留出了低性能开销的捆绑时间（在最坏情况下，4.8%的捆绑时间）以检查分类安全性。

B. 面向可重构的基于组件的WSN中间件的性能比较

        表5中们标明了竞争中间件的分布机制、语言和硬件平台，以及在文献中报告过的相关的评估优势。

        由于NesC生产了一个无法与LooCI隐形有意义比较的庞大系统版图，因此省略。从表5可见，LooCI是唯一的提供分布支持和平台独立的可重组WSN中间件。

        表6比较了LooCI与其他基于组件的WSN中间件的存储占用。当每种中间件提供了略微的性能差异时，LooCI-Contiki是基于C的WSN组件模型中最小的，LooCI-Squawk是基于Java的WSN组件模型中最小的。与唯一基于组件的支持分布式的中间件GridKit相比，LooCI的所有版本都有更小的存储占用。

        表7比较了基于组件的WSN中间件关于组件初始化和捆绑的性能。注意：这些时间是在表5列举的多种硬件平台上观测得到的，因此在不计算平台性能时不应当直接进行比较。性能数据省略的地方是源文章中未提供的。

        与基于C的组件模型相比，LooCI-Contiki的示例比RUNES快三倍，比Lorien快出三个数量级。然而LooCI测试平台的计算功率比Lorien和RUNES评估平台多25%。

        与基于Java的GridKit中间件相比，即便在提供少于一般的计算功率的节点上评估，LooCI-Squawk仍提供更快的组件初始化和捆绑，然而仍需提示应注意这是由不同的操作系统支持的。比较LooCI-OSGi和GridKit在GumStix上的性能，结论各异。LooCI提供了组件捆绑时比其他快两个数量级的速度，但在组件实例化时比其他慢一个数量级（归因于inter-isolate RPC的启动）。我们认为，实例化速度比捆绑速度的重要性低，因为实例化速度通常很少与捆绑操作相比。

C. LooCI网络方法开销

       在这一部分我们根据激活每一个LooCI指令所必须传送的字节数量，给LooCI产生的最差情况的网络开销定量（即用报文有效载荷的最大可能尺寸）。次分析没有把网络动态考虑在内，因此代表了在无冲突或丢包的理想单跳网络中的最差情况方案。根据组建之间传递的应用报文，LooCI的报文发送形式在每个报文中增加固定的4字节开销。由于所有的LooCI API中的指令使用简单的请求/回复方案，worst-case的激活任意LooCI指令传输的字节数量可由：Bytes= n * (P_RQ +P_RP)给出。其中n是定向节点数量，P_RQ是请求报文的大小，P_RP是回复报文的大小。表8提供了LooCI API上所有指令的P_RQ和P_RP开销，并可用于计算最差情况下所有指令所需的传送字节数。

        CS是被部署的组件的尺寸，C是匹配相关查询的组件数量，I是匹配相关查询的接口数量，A是网络地址大小的字节数，ST是语义类型描述最差情况的大小。由于类型安全性在拓展和捆绑是可能被撤销，类型非安全[TU]和类型安全[TS]操作的开销都提供了。对于现阶段的实施，对于全部IPv6地址A的最大尺寸为16字节，对65000元件类型系统TS的最大尺寸为22字节（在实际方案中，TS远小于该值）。所有的LooCI指令都是紧凑的并且在一般情况下请求和回复可以在单一802.15.4包中良好适应，存在可能的例外是以类型安全发现报文返回大量匹配接口的描述。

        由于分类学的数据和组件名称只用作支持发展和捆绑，the个数据不会被存储在事件管理者的捆绑列表中。因此，该列表中每一个将到来的线路输入仅使用5+A字节，而每一个将离开的线路输入仅使用4+A字节。这使得组件通信的复杂图样在目前节点平台资源有限的情况下被生成、检测和重组。

VI. 结论和工作前景

        这篇文章介绍了松弛耦合组件设备（LooCI）。LooCI是第一个WSN独立、分布式的组件设别中间件平台。LooCI提供语言独立重构组件模型和功能性、运行时重构及软件组件在各异平台运行管理的标准支持。LooCI有效分离了组件实施与分布的问题，允许组件在分布式环境中安全再利用。我们的分析显示LooCI提供了比其他重构WSN中间件更丰富的特性组合，并有最小化的特性开销。

        我们首要的未来工作道路是用各异的节点将LooCI实现到大规模WSN应用中。我们有使用LooCI原型事先实现的应用，但这些是小规模并且在同类硬件部署上实现的。我们相信大规模、异质性LooCI部署现在需要实现LooCI模型并在实际环境中评估我们的网络方法。