最适合的 OSGi 平台？ [关闭]

Posted 2023-02-22

【中文标题】最适合的 OSGi 平台？ [关闭]

【英文标题】：most suitable OSGi platform? [closed]

【发布时间】：2014-01-26 10:45:45

【问题描述】：

我们目前正在开发一种新软件，我们认为 OSGi 模块化将非常有用，因为软件本身可以很好地分解为模块化结构，以避免将来代码混乱并能够轻松添加新功能并挂钩到现有的。

我一直在使用两个（可能是最流行的）OSGi 平台，Eclipse Equinox（使用 Gemini Blueprint）和 Apache Felix（使用 Aries）。基本上我现在正要做出决定，我们应该使用哪一个。

我们在 Spring 方面拥有丰富的经验，因此我们希望继续使用它以及注释（例如 @Autowired 用于在同一个包中自动装配 bean，@ServiceReference 用于跨包自动装配），一些特定的 Spring 插件（例如 Data JPA），作为 JPA 提供者的 Hibernate（到目前为止，我们仅使用 Hibernate 作为 JPA 实现的经验，它具有我们需要的所有功能，因此我们希望避免切换到其他东西），JMS 消息传递（使用ActiveMQ 客户端）和其他一些功能。 稍后，我们还希望能够实现我们自己的安全管理器（以控制对某些捆绑包的访问，例如基于它们的数字签名、嵌入权限的证书）

到目前为止，我已经能够制作两个测试包（一个正在使用另一个服务）并将它们视为 Equinox 上的 Spring Bean 和 Gemini BP。但是，我在注释方面遇到了一些问题（而且我不太喜欢在 XML 中连接 bean，尤其是在架构不那么复杂的情况下——它们中的大多数都是单例）。

我也尝试过 Aries（但没有成功启用 Spring；可能只是还没有花足够的时间 :)）。

对于此类用例，您推荐哪个 OSGi 平台？

【参考方案1】：

这可能不是最好的答案，但如果我分享我的经验，我认为它对你很有用。几年前，我遇到了完全相同的情况。我对 Spring、JPA（Hibernate 和 EclipseLink）很有经验。我发现 OSGi 模块化很有用，所以我们开始了基于 OSGi 的项目。

正如我之前使用过 Spring 一样，使用 Blueprint 很明显（我们最终使用了 Apache Aries，因为它比 Gemini Blueprint 更稳定）。我们这样做了两年。但是，我们遇到了很多问题，所以我开始根据规范实现一个新的蓝图容器。我多次听说 OSGi DS 更好，但由于我以前是 Spring 粉丝，这些教程并没有让我改变主意。我觉得 ConfigAdmin 使用起来会非常好，但使用 Blueprint 编写好的代码是不可能的（我知道有 cm 命名空间，但它对我们来说效果不佳）。

在 EclipseCon 上，我与 Peter Kriens 交谈，他说服我在一个项目中试用 DS。我这样做了，现在我对使用 Blueprint 的时间感到非常难过（我不是故意要伤害你，白羊座的人 :)）。声明式服务与 ConfigurationAdmin 一起设计用于在 OSGi 模块化世界中工作。我很确定我很了解你目前的感受，但如果我真的建议你不要犯同样的错误。尝试使用 DS 组件创建两个捆绑包，从 felix-configadmin 获取配置并感受强大的功能。

在 JPA 中，我们首先使用了 EclipseLink。由于它太麻烦，我们切换到 Hibernate。我编写了一个适配器以便能够使用它（可在 GitHub 上获得）。据我所知，Hibernate 现在在这个话题上有更多的支持，我从来没有尝试过。最后，我们决定离开 JPA。我们即将将我们的基础架构从 JPA 替换为 Liquibase+QueryDSL。 https://github.com/everit-org 的组件或多或少都准备好了，我们需要处理文档。如果您有兴趣，为什么我们从 JPA 切换，请阅读这篇博文下的 cmets：http://blog.osgi.org/2013/12/attributes-attributes-and-attributes.html

我的简短回答：

如果你想避免由于历史原因使用声明式服务（这是一个错误，但我可以理解），使用 Apache Aries 或 Gemini BP（你觉得更好）。由于 Apache Aries 是为 OSGi 创建的，因此为 Aries 编写的所有命名空间处理程序都可以正常工作。 Aries 不支持为 Spring 编写的命名空间处理程序，因为 Aries 有自己的 API。但是，ActiveMQ 和其他项目有 Aries 命名空间处理程序实现。再一次，我建议考虑改用 DS 并用 Java 而不是 XML 编写代码。如果您设计小型模块，部署时间将不是问题。另一方面，您将在配置和稳定性部分获得很多好处。 带有 Hibernate 的 JPA 可以在 OSGi 中使用。可以在此处找到示例：https://github.com/everit-org/osgi-hibernate。如果您使用 Google 搜索，可以获得更多最新示例。我建议您在 JPA 工作时环顾四周，但它对 OSGi 不友好。 关于引擎：如果您使用 Felix，您可以确保您的代码可以在 Equinox 或 Knopflerfish 等其他容器上运行。另外两个有特殊功能，如果你使用，你可能会遇到以后无法移植代码的问题。我个人使用 Equinox，但它有历史原因。

【讨论】：

感谢您提供非常详细的回复。所以你建议完全抛弃Spring？将它用于其他一些任务（不是作为依赖注入器）怎么样？例如，Spring Data JPA 提供了非常好的方法来定义你的 DAO/存储库（作为声明性接口），如果我可以在我的数据访问包中使用它会很棒

我建议你应该尽可能从 OSGi 开始。尝试一些关于声明式服务的教程。如果您没有看到，您如何实现您的目标，请转到蓝图（可能是白羊座）。但是，请记住，当您有几个使用 OSGi 的项目时，您可能会改回来。如果您想要一个使用 JPA 和 DS 的示例，您可以查看由 Peter Kriens 编写的 enRoute 示例：github.com/osgi/osgi.enroute.blog

【参考方案2】：

我们经常使用带有Apache aries 的蓝图。最近有很多与 aries 相关的错误，但大多数现在都已修复。 Blueprint 对我们来说工作得很好，但与 JavaEE 相比，它对企业功能的支持有点欠缺。它具有基本的容器管理事务，但在这方面仅此而已。

声明式服务似乎比蓝图更稳定、更轻量级。他们还真正接受了 OSGi 的动态特性。另一方面，DS 没有任何扩展名，例如JPA 和容器管理事务。所以我不确定用它们编写真正的业务代码有多难。

我会非常小心 Gemini 的蓝图。 Springsource 似乎已经完全抛弃了 OSGi。所以我担心双子座蓝图会和完全不维护的spring dm一样。当然双子座现在正处于日食状态，但我不确定社区能否单独支持这一点。

在中期，我真的很想在 OSGi 上使用 CDI 和完整的 JavaEE 支持。已经有 pax cdi 提供对 OSGi 上 CDI 的支持，并且有可移植的扩展，例如来自Apache Deltaspike 的 JPA 和容器管理事务。不幸的是，它还没有完全工作，所以到目前为止这不是真正的选择。

所以我的建议是目前使用 Aries 蓝图和 DS 进行自己的概念验证，然后在两者之间做出决定。同时，我会密切关注 OSGi 上的 JavaEE 支持，看看它何时准备就绪。

对于基本的 OSGi 平台，我认为 felix 和 equinox 都不错。查看Apache Karaf 可能也有意义，它在两个框架之上提供管理和企业功能。