OSGi vs jboss热部署

Question

据我所知，在OSGi中，您可以在运行时更新jars，而无需重新启动服务器。但jboss也有热部署，在热部署中，完整的ear会更新，而服务器仍在运行。

那么，在jboss的企业级java项目中使用OSGi有什么好处呢？

Answer 1

我相信每个OSGi用例的答案都是一样的:模块化和更精细的更新粒度。

OSGi远不止是在运行时更新far而不重新启动服务器。从您的问题的角度来看，它在运行时更新jars，而无需重新启动应用程序。

我承认我不知道JBoss AS中EAR热部署的具体实现，但在任何情况下，EAR更新都不可能被设计为保留应用程序的整个状态。服务器仍在运行，但实际上是在更新时重新启动应用程序。这种状态损失的程度实际上取决于您如何设计您的应用程序，但事实仍然是您正在单调地做事情。

对于OSGi，情况并非如此:应用程序由一大组捆绑包组成，每个捆绑包都被设计为处理功能的单独部分。这种方法支持应用程序内的热部署，因为框架的设计考虑了重新启动任何单个jar对整个应用程序带来的影响，并让其他jar做出适当的反应。这提供了尽可能多地保留应用程序状态的能力。

因此，在企业案例中，OSGi设计的好处是应用程序的活跃性。没有必要强调这一点的重要性。确实，在某些用例中，应用程序可以安全地重启。但在我看来，OSGi是目前唯一真正可伸缩和可维护的Java选择。最重要的应用程序服务器已经(或将要)迁移到OSGi运行时(并因此提供OSGi应用程序支持)就证明了这一点。

Answer 2

l10i写道:对于OSGi，情况并非如此:应用程序由一大组捆绑包组成，每个捆绑包都被设计为处理功能的单独部分。这种方法支持应用程序内的热部署，因为框架的设计考虑了重新启动任何单个jar对整个应用程序带来的影响，并让其他jar做出适当的反应。这提供了尽可能多地保留应用程序状态的能力。

更详细地说，最好的OSGi应用程序是通过OSGi服务注册中心集成的面向服务的应用程序。这个服务注册中心是动态的，服务可以在任何时候来来去去，OSGi服务使用者对这种动态性做出了适当的反应。因此，假设您的应用程序由许多捆绑包组成，包括使用支付服务的捆绑包(例如，用于处理信用卡支付)和另一个提供该支付服务的捆绑包。如果你发现自己的支付服务需要更新(因为你有一个关键的修复，或者你可能已经找到了一个更便宜的提供商，等等)，你可以更新这个支付服务，甚至不需要关闭这个服务的消费者。要实现这一点，您可以更新支付服务捆绑包本身，但在这种情况下，我建议先在旧版本的同时安装新版本的支付服务捆绑包。这是可能的，因为OSGi允许同一包的多个版本共存。然后，一旦新的捆绑包启动并运行，您就可以删除旧的支付服务捆绑包，此时消费者将自动转向使用新的服务捆绑包，这是由OSGi服务注册中心提供的。

像上述示例这样的体系结构在确保企业应用程序正常运行方面非常强大，并且可以通过结合使用OSGi服务和动态安装、卸载或更新OSGi包的能力来实现。

顺便说一句，上面的例子有更多的细节，因为也可以编写包来使用特定类型的所有服务-最适合你的取决于你的情况。

有许多方法可以使用OSGi服务注册表，您可以将其与ServiceTracker API一起使用，这是相当低级的。在大多数情况下，最好使用OSGi声明服务(DS)、OSGi蓝图或其他框架等框架。在大多数情况下，这些框架通过注入工作，并为您处理OSGi服务注册表的动态性。有关DS或蓝图的信息，请参阅OSGi 4.2 Enterprise Specification。