OSGi 与 jboss 热部署
据我了解，在 OSGi 中，您可以在运行时更新 jar，而无需重新启动服务器。但jboss也有热部署，即全耳更新，服务器仍然运行。
那么 OSGi 在 jboss 中的企业 java 项目中有什么好处呢？
From what I understand, in OSGi you can update jars at runtime without restarting the server. But jboss also has hot-deployment in which the full ear is updated and the server is still running.
So what would be the benefits of OSGi in an enterprise java project in jboss ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信答案与每个 OSGi 用例相同：模块化和更精细的更新粒度。
OSGi 不仅仅是在运行时更新 jar 而无需重新启动服务器。从您的问题的角度来看，它是在运行时更新 jar，而无需重新启动应用程序。
我承认我不知道 JBoss AS 中 EAR 热部署的具体实现，但无论如何，EAR 更新都不可能被设计为保留应用程序的整个状态。服务器仍在运行，但您实际上在更新后重新启动应用程序。这种状态丢失的程度实际上取决于您设计应用程序的方式，但事实仍然是您正在单一地做事情。
对于 OSGi，情况并非如此：应用程序由大量捆绑包组成，每个捆绑包都希望设计为处理单独的功能部分。这种方法支持应用程序内热部署，因为该框架的设计考虑了重新启动任何单个 jar 给整个应用程序带来的影响，并让其他 jar 做出适当的反应。这提供了尽可能保留应用程序状态的能力。
因此，在企业案例中 OSGi 设计的好处是应用程序活跃度。无需强调这一点的重要性。确实，在某些用例中应用程序可以安全地重新启动。但我认为 OSGi 是当今 Java EE 唯一真正可扩展和可维护的选择。最重要的应用程序服务器已经（或将要）迁移到 OSGi 运行时（并因此提供 OSGi 应用程序支持）这一事实就证明了这一点。
I believe that the answer is the same as every OSGi use case: modularity and finer update granularity.
OSGi is far more than updating jars at runtime without restarting the server. From the perspective of your question, it is updating jars at runtime without restarting the application.
I admit I do not know the particular implementation of EAR hot deployment in JBoss AS, but in any case EAR updating cannot possibly be designed so to preserve the whole state of the application. The server is still running, but you essentially restart the application upon updating. The degree of such state loss really depends on how you design your application, but the fact remains that you are doing things monolitically.
With OSGi this is not the case: the application is made of a large set of bundles, each hopefully designed to handle a separate part of the functionality. This approach enables intra-application hot deployment, since the framework is designed to consider the effect that restarting any single jar brings to the application as a whole, and to let the other jars react appropriately. That offers the ability to preserve application state as much as possible.
Hence the benefits of an OSGi design in the Enterprise case is application liveness. No need to underline the importance of that. Truly, there are use cases where the application may be safely restarted. But OSGi in my opinion is the only really scalable and maintainable choice for Java EE nowadays. The fact that the most important application servers have moved (or are going to) to an OSGi runtime (and consequently giving OSGi application support) is proof of that.
进一步详细说明一下，最好的 OSGi 应用程序是通过 OSGi 服务注册表集成的面向服务的应用程序。该服务注册中心是动态的，服务可以随时出现和消失，并且 OSGi 服务使用者会对这种动态性做出适当的反应。
假设您的应用程序由多个捆绑包组成，其中一个捆绑包使用支付服务（例如，用于处理信用卡支付），另一个捆绑包提供该支付服务。如果您发现自己处于需要更新支付服务的情况（因为您有一个关键的修复程序或者您可能找到了更便宜的提供商等），您可以更新此支付服务，甚至无需关闭此服务的消费者。要实现此目的，您可以更新支付服务包本身，但在这种情况下，我建议首先安装新版本的支付服务包和旧版本。这是可能的，因为 OSGi 允许同一包的多个版本共存。然后，一旦新捆绑包启动并运行，您就可以删除旧的支付服务捆绑包，此时消费者将自动转向使用新的支付服务捆绑包，这由 OSGi 服务注册表提供。
像上面例子这样的架构对于确保您的企业应用程序保持正常运行来说确实非常强大，并且可以通过使用 OSGi 服务并结合动态安装、卸载或更新 OSGi 包的能力来实现。
顺便说一句，上面的示例有更多细节，因为捆绑包也可以编写为使用特定类型的所有服务 - 什么最适合您取决于您的情况。
有多种方法可以使用 OSGi 服务注册表，您可以将其与 ServiceTracker API，这是相当低级的。在大多数情况下，最好使用一个框架来实现此目的，例如 OSGi 声明性服务 (DS)、OSGi 蓝图或其他框架。在大多数情况下，这些框架通过注入工作并为您处理 OSGi 服务注册表的动态性。有关 DS 或 Blueprint 的信息，请参阅 OSGi 4.2 Enterprise 规范。
Just to elaborate on this a little more, the best OSGi applications are service-oriented applications which integrate through OSGi services registry. This service registry is dynamic, services can come and go at any time and OSGi service consumers react to this dynamicity appropriately.
So let's say your application is comprised of a number of bundles, including a bundle that uses a payment service (e.g. for handling credit card payments) and another bundle that provides that payment service. If you find yourself in a situation that the payment service needs to be updated (because you have a critical fix or maybe you have found a cheaper provider, etc) you can update this payment service without even taking the consumers of this service down. To achieve this, you can update the payment service bundle itself, but what I would recommend in such a case is to install the new version of the payment service bundle alongside the old version first. This is possible because OSGi allows multiple versions of the same bundle to co-exist. Then once the new bundle is up and running you can remove the old payment service bundle at which point the consumers will automatically flip to using the new ones, courtesy of the OSGi service registry.
Such an architecture as the above example is really powerful and great to ensure that your enterprise applications stay up, and it can be realized by using OSGi services combined with the ability to dynamically install, uninstall or update OSGi bundles.
BTW there is a little more detail to the above example as bundles can also be written to use all services of a particular type - what's best for you depends on your situation.
There are a number of ways to use the OSGi service registry, you can use it with the ServiceTracker API, which is fairly low-level. In most cases it's preferable to use a framework for this such as OSGi Declarative Services (DS), OSGi Blueprint or other framework. In most cases these frameworks work through injection and handle the dynamicity of the OSGi Service Registry for you. For information on DS or Blueprint see the OSGi 4.2 Enterprise Specification.