我在维基百科和其他网站上读过关于OSGi的文章,但我并没有真正看到大局。它说它是一个基于组件的平台,并且您可以在运行时重新加载模块。同样,到处都给出的“实际示例”是Eclipse插件框架。
我的问题是:
OSGi清晰而简单的定义是什么? 它能解决什么常见问题?
所谓“常见问题”,我指的是我们每天都要面对的问题,比如“OSGi能做些什么来让我们的工作更高效/有趣/简单?”
我在维基百科和其他网站上读过关于OSGi的文章,但我并没有真正看到大局。它说它是一个基于组件的平台,并且您可以在运行时重新加载模块。同样,到处都给出的“实际示例”是Eclipse插件框架。
我的问题是:
OSGi清晰而简单的定义是什么? 它能解决什么常见问题?
所谓“常见问题”,我指的是我们每天都要面对的问题,比如“OSGi能做些什么来让我们的工作更高效/有趣/简单?”
当前回答
I don't care too much about the hotplugability of OSGi modules (at least currently). It's more the enforced modularity. Not having millions of "public" classes available on the classpath at any time protects well from circular dependencies: You have to really think about your public interfaces - not just in terms of the java language construct "public", but in terms of your library/module: What (exactly) are the components, that you want to make available for others? What (exactly) are the interfaces (of other modules) you really need to implement your functionality?
这很好,热插拔是附带的,但我宁愿重新启动我通常的应用程序,而不是测试所有的热插拔组合…
其他回答
它还被用于在移动端带来额外的中间件和应用程序的可移植性。移动端可用于WinMo, Symbian, Android等。一旦与设备功能集成,就会出现碎片化。
I don't care too much about the hotplugability of OSGi modules (at least currently). It's more the enforced modularity. Not having millions of "public" classes available on the classpath at any time protects well from circular dependencies: You have to really think about your public interfaces - not just in terms of the java language construct "public", but in terms of your library/module: What (exactly) are the components, that you want to make available for others? What (exactly) are the interfaces (of other modules) you really need to implement your functionality?
这很好,热插拔是附带的,但我宁愿重新启动我通常的应用程序,而不是测试所有的热插拔组合…
如果基于Java的应用程序需要添加或删除模块(扩展应用程序的基本功能),而不需要关闭JVM,则可以使用OSGI。通常,如果关闭JVM的成本比较高,那么仅仅是为了更新或增强功能。
例子:
Eclipse:为插件的安装、卸载、更新和相互依赖提供了平台。 AEM: WCM应用程序,其中功能更改将由业务驱动,无法承担维护停机时间。
注意:Spring框架停止支持OSGI Spring包,认为它对于基于事务的应用程序或这些行中的某些点来说是不必要的复杂性。我个人是不会考虑OSGI的,除非绝对必要,比如在构建平台这样的大项目中。
其他人已经详细概述了OSGi的好处,我在此解释我所见过或使用过的实际用例。
In one of our application, we have event based flow and flow is defined in plugins based on OSGi platform so tomorrow if some client wants different/additional flow then he just have to deploy one more plugin, configure it from our console and he is done. It is used for deploying different Store connectors, for example, suppose we already have Oracle DB connector and tomorrow mongodb is required to be connected then write a new connector and deploy it and configure the details through console and again you are done. deployment of connnectors is handled by OSGi plugin framework.
我使用OSGi已经有8年左右的时间了,我不得不说,只有当你有业务需要在运行时更新、删除、安装或替换某个组件时,你才应该考虑使用OSGi。这也意味着您应该有一个模块化的心态,并理解模块化的含义。有一些争论说OSGi是轻量级的——是的,这是真的,但也有一些其他的框架是轻量级的,更容易维护和开发。同样的道理也适用于安全java等等。
OSGi需要一个可靠的体系结构才能正确使用,而且在没有任何OSGi参与的情况下,很容易使OSGi系统成为一个独立可运行的jar。