使用 OSGi 和 Eclipse Concierge 创建物联网应用程序

早期情况
在 2000 年，当 OSGi 联盟 (OSGi Alliance) 发布其第一批规范时，就十分明确地以嵌入式设备为目标。可以用两个重要的观察结果来恰当地概括 OSGi 的动机：

1. 嵌入式系统的软件是动态的（组件不断变化）；
2. 因为这些设备的使用寿命较长，软件需要保持一直有效，不能经常中断用户操作。

后者已通过 bundle（Java® 代码的模块化单元，可以单独加载、卸载和更新）实现，只会影响直接依赖于它们的其他 bundle。前者导致了服务的引入，服务是将接口与实现分离的轻量级实体，它们保存在一个中央服务注册表中，以便减少模块间的耦合。服务由一个事件系统进行补充，用于向正在使用的 bundle 通知服务可用性中发生了哪些变化。

当时流行的设备包括，电视机顶盒、“互连家居” 网关和个人数字助理 (PDA)，还包括对未来毫无危险意识的人们称之为 “智能手机” 的设备。2006 年，还在 Sharp Zaurus 和 Nokia Communicators 的年代，我对流行的 OSGi 框架实现占用越来越大的空间，及其死板的运行时行为越来越感到失望，我开始在我的 硕士论文 中关注 Concierge。我试图用尽可能少的代码实现 OSGi R3 规范，该规范最终成为了一个 86 kiB 的 JAR 文件。与此同时，我降低了代码的复杂性，并利用了使该框架在 JVM 上运行性能大幅提高的优化，这种优化常用于移动设备和嵌入式设备上。这些设备往往缺乏充分的 JIT 编译器的支持。我想在不进行任何妥协的情况下获得 OSGi 为嵌入式软件提供的好处。

我们的现状
十五年后，嵌入式设备中的 CPU 平均速度几乎可以与 OSGi 婴儿期的高端台式机 CPU 相当。传感器变得经济实惠且无所不在，例如，在手机中。将智能设备的不同岛屿互联起来，并将它们变成智能外界环境，这种趋势仍在继续，并导致物联网 (IOT) 得到广泛普及。即使有了这一切，最初推动 OSGi 的主要因素并没有发生改变。从有利的一面讲，由于物联网固有的分布式特点，物联网的部署仍然活跃，甚至可能更加活跃。遗憾的是，在嵌入式设备上实现 OSGi 框架的速度仍然比预期望的慢，而且众所周知，它们很难设置。

Eclipse Concierge
Eclipse Concierge 团队继续开发旧的 R3 实现，将它变​​成一个现代化的 R5 实现，并且不损害设计原则，也不会丢失嵌入式设备的关注重点。现在，我们已经通过所有相关的合规性测试，并发布了新的 Concierge 的第一个主要版本。此 版本被称为 5.0.0，与它所实现的 OSGi 核心规范的修订保持一致。最好的消息是，尽管功能和 API 方面的标准明显增加了，但 Eclipse Concierge R5 没有调试符号的 JAR 的占用空间仍低于 250 kiB，有调试符号的 JAR 的占用空间则低于 330 kiB。此外，在启动时间和服务注册表性能方面，我们测量到了相对于其他框架的明显性能优势。我们将在未来继续优化 Concierge 服务。

除了保持代码的快速和精益特征之外，我们还专注于让 Concierge 像 OSGi 框架一样易于使用。创建 Concierge 部署主要包括，将框架 JAR 和 bundle 复制到设备，然后创建一个 init.xargs 文件，该文件类似于 Knopflerfish 使用的文件。该文件的内容可以包括 Java 属性声明或指令，比如，安装、启动或 istart（安装并启动）bundle。为了让创建启动文件比那的更容易、更简洁，Concierge 支持对声明的系统变量进行了变量替换，还支持在文件名中使用通配符。从清单 1 中可以看出这一点，它可以使用替代变量来分析出常见的 URL 和通配符，使部署可以灵活地切换到外壳 bundle 的不同每夜构建 (nightly build)。