是否存在对 OSGi 术语、框架及其关系的概述？

Question

我正在努力适应庞大的企业 OSGi 编程生态系统，但我发现很难大致了解该技术堆栈是如何组合在一起的，哪些技术相互构建，哪些技术解决了哪些任务，以及它们如何适用于我迄今为止设法理解的有限术语。

例如：Apache Felix、Equinox、Karaf、Jira OSGi、Spring DM、Aries Blueprint、Gemini Blueprint、iPOJO、Camel等有什么关系...

我知道 Equinox 是基于 Felix 的，而且蓝图变体和 iPOJO 与组件管理有些相关，但是声明式服务呢？ DS 是 Blueprint 的替代品，还是 Blueprint 是声明式服务的实现？

总的来说，我很困惑，我真的需要一个简单的概述，了解一般的 OSGi 技术是如何相关的。

有谁知道存在这样的 OSGi 生态系统概览（也许是图形化的）？

最好的问候。

Answer 1

我不知道图形表示。我可以分解您在帖子中提到的一些具体内容：

1. “OSGi 框架”是核心 OSGi 规范的实现。它必须实现捆绑包、安装和解析捆绑包、生命周期、服务等概念。
2. Apache Felix 是一个 OSGi 框架实现。
3. Equinox 也是一个 OSGi 框架实现。它不是“基于”Apache Felix，但确实从中借用了少量代码。 Equinox 是 Eclipse 等中使用的 OSGi 的实现。
4. Karaf 本质上是一个应用服务器产品。它使用 Felix 作为其核心 OSGi 框架实现，然后在顶部添加了许多额外的功能。
5. Jira OSGi：不知道。我相信 Jira 是用 OSGi 在内部实现的，但我不知道任何细节。
6. Spring DM 是一个过时/死的项目。这是一种使用 OSGi 将 Spring bean 图拆分为模块化应用程序的方法。
7. Blueprint 是 OSGi 联盟发布的规范。它是纲要规范之一，即核心中不需要的附加组件。 Blueprint 受到 Spring-DM 的启发，它标准化了在 bundle 内和 bundle 之间将 bean 连接在一起的想法。
8. Gemini Blueprint 是 Blueprint 规范的实现。 Gemini 从 Spring-DM 代码开始，并将其演变为符合（当时的）新规范。
9. Aries 蓝图也是蓝图的一种实现。它是“洁净室”，即根据规范从头开始实施，而不是从旧的 Spring 代码演变而来。
10. Declarative Services 是来自 Compendium 的 OSGi 规范。这是定义组件并使用跨包服务将它们连接在一起的另一种方法。许多经验丰富的 OSGi 开发人员（包括我）认为声明式服务远优于蓝图。如果您愿意，我可以详细说明原因。
11. iPOJO 是另一种定义组件并将它们连接在一起的不同方式。它不符合任何 OSGi 规范。
12. Camel 是一个集成库，主要用于消息传递应用程序。除了可以在 OSGi 下运行之外，它与 OSGi 没有太大关系。

我希望这会有所帮助。