我在维基百科和其他网站上读过关于OSGi的文章,但我并没有真正看到大局。它说它是一个基于组件的平台,并且您可以在运行时重新加载模块。同样,到处都给出的“实际示例”是Eclipse插件框架。
我的问题是:
OSGi清晰而简单的定义是什么? 它能解决什么常见问题?
所谓“常见问题”,我指的是我们每天都要面对的问题,比如“OSGi能做些什么来让我们的工作更高效/有趣/简单?”
我在维基百科和其他网站上读过关于OSGi的文章,但我并没有真正看到大局。它说它是一个基于组件的平台,并且您可以在运行时重新加载模块。同样,到处都给出的“实际示例”是Eclipse插件框架。
我的问题是:
OSGi清晰而简单的定义是什么? 它能解决什么常见问题?
所谓“常见问题”,我指的是我们每天都要面对的问题,比如“OSGi能做些什么来让我们的工作更高效/有趣/简单?”
当前回答
至少,OSGi让您考虑到模块化、代码重用、版本控制以及项目的一般管道。
其他回答
为清晰起见,经过编辑。OSGi页面给出了一个比我更好的简单答案
一个简单的答案:OSGi服务平台为协作网络服务提供了一个标准化的、面向组件的计算环境。这种体系结构显著降低了构建、维护和部署应用程序的整体复杂性。 OSGi服务平台提供了在各种网络的设备上动态改变组合的功能,不需要重新启动。
在单个应用程序结构中,比如Eclipse IDE,在安装新插件时重新启动并不是什么大问题。完全使用OSGi实现,您应该能够在运行时添加插件,获得新功能,而完全不需要重新启动eclipse。
同样,这不是每天都要做的大事,只是应用程序的小用途。
但是,当你开始研究多计算机、分布式应用框架时,这就是它开始变得有趣的地方。当关键系统必须有100%的正常运行时间时,热插拔组件或在运行时添加新功能的能力非常有用。当然,现在大多数情况下都有这样做的能力,但是OSGi正试图将所有东西捆绑到一个具有公共接口的漂亮的小框架中。
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有以下好处:
每个插件都是一个版本化的工件,它有自己的类加载器。 每个插件都依赖于它所包含的特定jar和其他特定版本的插件。 由于版本控制和隔离的类加载器,同一工件的不同版本可以同时加载。如果应用程序的一个组件依赖于插件的一个版本,而另一个组件依赖于另一个版本,那么它们可以同时加载。
这样,您就可以将应用程序构建为一组按需加载的版本化插件构件。每个插件都是一个独立的组件。就像Maven帮助您构建构建,使其可重复,并由创建它的工件的一组特定版本定义一样,OSGi帮助您在运行时完成这一点。
我使用OSGi已经有8年左右的时间了,我不得不说,只有当你有业务需要在运行时更新、删除、安装或替换某个组件时,你才应该考虑使用OSGi。这也意味着您应该有一个模块化的心态,并理解模块化的含义。有一些争论说OSGi是轻量级的——是的,这是真的,但也有一些其他的框架是轻量级的,更容易维护和开发。同样的道理也适用于安全java等等。
OSGi需要一个可靠的体系结构才能正确使用,而且在没有任何OSGi参与的情况下,很容易使OSGi系统成为一个独立可运行的jar。
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?
这很好,热插拔是附带的,但我宁愿重新启动我通常的应用程序,而不是测试所有的热插拔组合…