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

look_w

早期情况在 2000 年，当  发布其第一批规范时，就十分明确地以嵌入式设备为目标。可以用两个重要的观察结果来恰当地概括 OSGi 的动机：
1. 嵌入式系统的软件是动态的（组件不断变化）；
2. 因为这些设备的使用寿命较长，软件需要保持一直有效，不能经常中断用户操作。
后者已通过 bundle（Java® 代码的模块化单元，可以单独加载、卸载和更新）实现，只会影响直接依赖于它们的其他 bundle。前者导致了服务的引入，服务是将接口与实现分离的轻量级实体，它们保存在一个中央服务注册表中，以便减少模块间的耦合。服务由一个事件系统进行补充，用于向正在使用的 bundle 通知服务可用性中发生了哪些变化。
当时流行的设备包括，电视机顶盒、“互连家居” 网关和个人数字助理 (PDA)，还包括对未来毫无危险意识的人们称之为 “智能手机” 的设备。2006 年，还在  和  的年代，我对流行的 OSGi 框架实现占用越来越大的空间，及其死板的运行时行为越来越感到失望，我开始在我的  中关注 Concierge。我试图用尽可能少的代码实现 OSGi R3 规范，该规范最终成为了一个 86 kiB 的 JAR 文件。与此同时，我降低了代码的复杂性，并利用了使该框架在 JVM 上运行性能大幅提高的优化，这种优化常用于移动设备和嵌入式设备上。这些设备往往缺乏充分的 JIT 编译器的支持。我想在不进行任何妥协的情况下获得 OSGi 为嵌入式软件提供的好处。
我们的现状 十五年后，嵌入式设备中的 CPU 平均速度几乎可以与 OSGi 婴儿期的高端台式机 CPU 相当。传感器变得经济实惠且无所不在，例如，在手机中。将智能设备的不同岛屿互联起来，并将它们变成智能外界环境，这种趋势仍在继续，并导致物联网 (IOT) 得到广泛普及。即使有了这一切，最初推动 OSGi 的主要因素并没有发生改变。从有利的一面讲，由于物联网固有的分布式特点，物联网的部署仍然活跃，甚至可能更加活跃。遗憾的是，在嵌入式设备上实现 OSGi 框架的速度仍然比预期望的慢，而且众所周知，它们很难设置。
Eclipse                Concierge 团队继续开发旧的 R3 实现，将它变​​成一个现代化的 R5 实现，并且不损害设计原则，也不会丢失嵌入式设备的关注重点。现在，我们已经通过所有相关的合规性测试，并发布了新的 Concierge 的第一个主要版本。此 ，与它所实现的 OSGi 核心规范的修订保持一致。最好的消息是，尽管功能和 API 方面的标准明显增加了，但 Eclipse Concierge R5 没有调试符号的 JAR 的占用空间仍低于 250 kiB，有调试符号的 JAR 的占用空间则低于 330 kiB。此外，在启动时间和服务注册表性能方面，我们测量到了相对于其他框架的明显性能优势。我们将在未来继续优化 Concierge 服务。
除了保持代码的快速和精益特征之外，我们还专注于让 Concierge 像 OSGi 框架一样易于使用。创建 Concierge 部署主要包括，将框架 JAR 和 bundle 复制到设备，然后创建一个 init.xargs 文件，该文件类似于  使用的文件。该文件的内容可以包括 Java 属性声明或指令，比如，安装、启动或 istart（安装并启动）bundle。为了让创建启动文件比那的更容易、更简洁，Concierge 支持对声明的系统变量进行了变量替换，还支持在文件名中使用通配符。从清单 1 中可以看出这一点，它可以使用替代变量来分析出常见的 URL 和通配符，使部署可以灵活地切换到外壳 bundle 的不同每夜构建 (nightly build)。

1 2 3 4 5 6 7 8 9 10 11 12

# xargs sample file to load some Felix bundles<br> # uncomment for clean starts<br> #  -Dorg.osgi.framework.storage.clean=onFirstInit<br> # use a separate profile<br>     -Dorg.eclipse.concierge.profile=felix<br><br> # repos to load  bundles from <br> -Drepo=https://archive.apache.org/dist/felix/<br> # load bundles<br>          -istart bundles/org.eclipse.concierge.shell-5.0.0.*.jar<br> -istart          ${repo}/org.apache.felix.scr-1.8.0.jar<br> -istart          ${repo}/org.apache.felix.eventadmin-1.4.2.jar<br> -install          ${repo}/org.apache.felix.metatype-1.0.12.jar<br> -install          ${repo}/org.apache.felix.configadmin-1.8.4.jar<br> -level 1 -start          ${repo}/org.apache.felix.metatype-1.0.12.jar<br> -level 2 -start          ${repo}/org.apache.felix.configadmin-1.8.4.jar

除了命令行和 xargs 文件外，Concierge 还可以嵌入到 Java 应用程序中，并通过标准化的启动 API 启动，或者由 等工具启动。
尽管设计很简单，但 Concierge 还提供了一个可选服务，作为该框架的开箱即用服务的一部分，该服务就是日志服务。这样做的理由是，在嵌入式系统上，由于许多设备的无头特性，调试和跟踪通常会特别难。在框架中提供日志服务让 Concierge 框架实现可以与应用程序使用相同的日志。这使得将应用程序中观察到的行为关联到 OSGi 特定事件变得更容易，比如，包解析或服务注册表活动。反过来，也减轻了一些最初在应用程序中采用 OSGi 时通常会观察到的难题。与此相反，在完整的 OSGi 规范符合性并不很重要的封闭环境中进行操作时，可以静态地禁用某些功能，例如，禁用对传统 bundle（bundle 清单版本 1）的支持，以便进一步减少占用空间。这是通过一个微内核设计实现的，其目的是使这种传统支持特性变成可选特性。事实上，它甚至可能连 bundle 清单版本 2 的支持都删除掉，生成一个只在 R5 一般需求/功能模型上运行的 Concierge 框架。最后，在对代码不进行任何修改的情况下，解析 xargs 文件是另一项可以删除的微服务。
在 5.0.0 版本的框架中，我们也发布了一组 bundle，包括一个最小的命令行外壳，用于实现与框架（或包管理的实施）的交互，我们还提供了一些入门级服务，面向依赖于它们的传统 (R4) bundle。我们计划添加一个用于管理框架的 RESTful 接口、一个小事件管理实现和 bundle，与选定的流行嵌入式设备的硬件功能进行交互。
不久的将来
驾驭第一个版本是我们这个项目中的关键一步，但我们会很快面临另一个挑战，即推动在其他  项目和其他地方的采用。我们已经成功地将  带到 Concierge 上，这说明了我们的实现的优势和适用性，但我们还需要做更多的工作，才能获得长期成功。下一步我们将发展我们的社区，将 Concierge 带给物联网和嵌入式系统的应用程序开发人员。我们参加了 ，其目的是向 CS 学生公开开源流程，我们还与来自  的学生合作，基于 Concierge 创建新的物联网应用程序。
Eclipse Concierge 团队会很高兴地聆听您在物联网应用程序和嵌入式系统中使用 OSGi 的体验。