最合适的OSGi平台？

Question

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

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

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

到目前为止，我已经能够制作两个测试包（一个是使用另一个的服务）并将它们视为Equinox上的Spring Beans与Gemini BP。但是，我在注释方面遇到了一些问题（我并不喜欢在XML中使用布线bean，特别是在架构不那么复杂的情况下 - 大多数都是Singletons）。

我也尝试过Aries（但是没有成功在那里启用Spring;可能还没有花足够的时间在那上面:)）。

您建议哪种OSGi平台用于此类用例？

Answer 1

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

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

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

从JPA开始，我们首先使用了EclipseLink。因为太麻烦了，我们切换到了Hibernate。我写了一个适配器以便能够使用它（在GitHub上可用）。据我所知，Hibernate现在在这个主题上有更多的支持，我从未尝试过。最后，我们决定离开JPA。我们将基础架构从JPA更换为Liquibase + QueryDSL。这些组件或多或少已准备好https://github.com/everit-org，我们需要处理文档。如果您有兴趣，为什么我们从JPA切换，请阅读此博客文章中的评论：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编写代码。如果设计小模块，部署时间不会成为问题。另一方面，您将在配置和稳定性部分获得许多好处。
• 带有Hibernate的JPA可以在OSGi中使用。可以在此处找到一个示例：https://github.com/everit-org/osgi-hibernate。如果你谷歌，可以获得更多最新的例子。我建议您应该环顾四周，因为JPA可以工作，但它不是OSGi友好的。
• 关于引擎：如果您使用Felix，您可以确保您的代码可以在其他容器上运行，如Equinox或Knopflerfish。另外两个具有特殊功能，如果您使用，您可能会遇到以后无法移植代码的问题。我个人使用Equinox，但它有历史原因。

Answer 2

我们经常使用Apache aries的蓝图。最近有很多与白羊座有关的虫子，但现在大多数都是固定的。 Blueprint对我们来说效果很好，但与JavaEE相比，它对企业功能缺乏一点支持。它有基本的容器管理交易，但在这方面却没有多少。

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

我会非常小心双子座的蓝图。 Springsource似乎完全放弃了OSGi。所以我担心双子座的蓝图会和春天的dm一样，而根本没有维持。当然，双子座现在处于日蚀状态，但我不确定社区是否能够支持这一点。

在中期我非常想在OSGi上使用CDI和完整的JavaEE支持。已经有pax cdi为OSGi上的CDI提供支持，并且有便携式扩展，例如：来自Apache Deltaspike的JPA和容器管理的事务。不幸的是它还没有完全正常工作，所以现在这不是一个真正的选择。

所以我的建议是目前用Aries蓝图和DS做自己的概念证明，并在两者之间做出决定。与此同时，我会密切关注OSGi上的JavaEE支持，看看它何时可以准备好。

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