OSGi vs jboss热部署

Question

据我所知，在OSGi中，您可以在运行时更新jar而无需重新启动服务器。但jboss也有热部署，其中全耳更新并且服务器仍在运行。

那么OSGi在jboss的企业java项目中会带来什么好处？

Answer 1

我认为答案与每个OSGi用例相同：模块化和更精细的更新粒度。

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

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

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

因此，企业案例中OSGi设计的好处是应用程序的活跃性。无需强调其重要性。确实，有些用例可以安全地重新启动应用程序。但是在我看来，OSGi是目前Java EE唯一真正可扩展和可维护的选择。最重要的应用程序服务器已移动（或将要）到OSGi运行时（并因此提供OSGi应用程序支持）这一事实证明了这一点。

Answer 2

  

l10i写道：对于OSGi，情况并非如此：应用程序由大量捆绑包组成，每个捆绑包都希望能够处理单独的功能部分。这种方法支持应用程序内热部署，因为该框架旨在考虑重新启动任何单个jar为整个应用程序带来的影响，并让其他jar响应得当。这提供了尽可能保留应用程序状态的能力。

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

上述示例的这种架构非常强大，非常适合确保您的企业应用程序保持正常运行，并且可以通过使用OSGi服务以及动态安装，卸载或更新OSGi包的能力来实现。

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

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