10

据我了解，在 OSGi 中，您可以在运行时更新 jar，而无需重新启动服务器。但是 jboss 也有热部署，其中完整的耳朵被更新并且服务器仍在运行。

那么在 jboss 的企业 Java 项目中，OSGi 有什么好处呢？

4

2 回答 2

9

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

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

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

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

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

于 2011-10-09T08:27:20.367 回答
6

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

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

像上面例子这样的架构真的很强大，可以很好地确保您的企业应用程序保持正常运行，并且可以通过使用 OSGi 服务以及动态安装、卸载或更新 OSGi 包的能力来实现。

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

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

于 2011-10-13T07:49:37.890 回答