我相信答案与每个OSGi用例相同:模块化和更精细的更新粒度.
OSGi不仅仅是在运行时更新jar而不重新启动服务器.从您的问题的角度来看,它是在运行时更新jar而不重新启动应用程序.
我承认我不知道JBoss AS中EAR热部署的特定实现,但无论如何都不能设计EAR更新以保持应用程序的整个状态.服务器仍在运行,但您基本上在更新时重新启动应用程序.这种状态损失的程度实际上取决于您如何设计您的应用程序,但事实仍然是您在单一地进行操作.
对于OSGi,情况并非如此:应用程序由大量捆绑包组成,每个捆绑包都有望设计用于处理功能的单独部分.这种方法支持应用程序内热部署,因为该框架旨在考虑重新启动任何单个jar为整个应用程序带来的影响,并让其他jar响应得当.这提供了尽可能保留应用程序状态的能力.
因此,企业案例中OSGi设计的好处是应用程序的活跃性.无需强调其重要性.确实,有些用例可以安全地重新启动应用程序.但是我认为OSGi是目前Java EE唯一真正可扩展和可维护的选择.最重要的应用程序服务器已移动(或将要)到OSGi运行时(并因此提供OSGi应用程序支持)这一事实证明了这一点.
l10i写道:对于OSGi,情况并非如此:应用程序由大量的捆绑包组成,每个捆绑包都希望能够处理单独的功能部分.这种方法支持应用程序内热部署,因为该框架旨在考虑重新启动任何单个jar为整个应用程序带来的影响,并让其他jar响应得当.这提供了尽可能保留应用程序状态的能力.
再详细说明一下,最好的OSGi应用程序是面向服务的应用程序,它们通过OSGi服务注册表集成.此服务注册表是动态的,服务可以随时进出,OSGi服务使用者可以适当地对此动态做出反应.因此,假设您的应用程序由多个捆绑包组成,包括使用支付服务的捆绑包(例如用于处理信用卡付款)和另一个提供该支付服务的捆绑包.如果您发现自己处于需要更新支付服务的情况(因为您有一个关键修复或者您找到了更便宜的提供商等),您可以更新此支付服务,甚至无需关闭此服务的消费者.为此,您可以更新支付服务包本身,但在这种情况下我建议的是先安装新版本的支付服务包以及旧版本.这是可能的,因为OSGi允许同一捆绑的多个版本共存.然后,一旦新捆绑包启动并运行,您就可以删除旧的支付服务捆绑包,此时消费者将自动转向使用新的捆绑服务,由OSGi服务注册表提供.
上述示例的这种体系结构非常强大,非常适合确保您的企业应用程序保持正常运行,并且可以通过使用OSGi服务以及动态安装,卸载或更新OSGi软件包的能力来实现.
顺便说一下,上面的例子还有一些细节,因为也可以编写捆绑包来使用特定类型的所有服务 - 最适合你的是什么取决于你的情况.
有许多方法可以使用OSGi服务注册表,您可以将它与ServiceTracker API一起使用,这很低级.在大多数情况下,最好使用一个框架,例如OSGi声明服务(DS),OSGi蓝图或其他框架.在大多数情况下,这些框架通过注入工作,并为您处理OSGi Service Registry的动态性.有关DS或蓝图的信息,请参阅OSGi 4.2企业规范.
| 归档时间： |
|
| 查看次数： |
3630 次 |
| 最近记录： |