Java OSGi解决了什么问题？

我在维基百科和其他网站上读到过关于这个问题的文章，但我并不真正了解全局。它说它是一个基于组件的平台，您可以在运行时重新加载模块。此外，到处给出的“实际示例”是Eclipse插件框架

我的问题是：

OSGi的清晰而简单的定义是什么

它解决了哪些常见问题

我所说的“常见问题”是指我们每天都要面对的问题，比如“OSGi能做些什么使我们的工作更高效/有趣/简单？”

为了清晰起见进行了编辑。OSGi页面给出了比我更好的简单答案

一个简单的答案是：OSGi服务平台为协作网络服务提供了一个标准化的、面向组件的计算环境。这种体系结构大大降低了构建、维护和部署应用程序的总体复杂性。 OSGi服务平台提供了在各种网络的设备上动态更改组合的功能，而无需重新启动

在单个应用程序结构中，比如EclipseIDE，安装新插件时重新启动并不是什么大问题。完全使用OSGi实现，您应该能够在运行时添加插件，获得新功能，但根本不必重新启动eclipse

再说一次，对于每天使用的小应用程序来说，这不是什么大问题

但是，当您开始研究多计算机、分布式应用程序框架时，这就是它开始变得有趣的地方。当您必须为关键系统提供100%的正常运行时间时，在运行时热交换组件或添加新功能的功能非常有用。诚然，现在大多数情况下都有这样做的功能，但OSGi正试图将所有内容捆绑到一个带有通用接口的漂亮小框架中

---

OSGi能解决常见问题吗？我不确定。我的意思是，它可以，但是对于更简单的问题，开销可能不值得。但是当你开始处理更大的、网络化的应用程序时，这是一个值得考虑的问题。

< p>我从OSGi中发现了以下优点：

• 每个插件都是一个版本化的工件，它有自己的类加载器
• 每个插件都依赖于它包含的特定JAR和其他特定版本的插件
• 由于版本控制和独立的类加载器，可以同时加载同一工件的不同版本。如果应用程序的一个组件依赖于插件的一个版本，而另一个组件依赖于另一个版本，则可以同时加载这两个组件

---

这样，您就可以将应用程序构造为一组按需加载的版本化插件工件。每个插件都是一个独立的组件。正如Maven帮助您构建可重复的、由一组特定版本的构件定义的构建一样，OSGi帮助您在运行时完成这项工作

我不太关心OSGi模块的热插拔能力（至少目前是这样）。更多的是强制模块化。在任何时候，在类路径上都没有数百万个“公共”类可以很好地防止循环依赖：你必须真正考虑你的公共接口——不仅仅是java语言构造的“公共”，而是你的库/模块：组件（确切地说）是什么，您希望为其他人提供的信息？实现您的功能真正需要（其他模块的）接口是什么

---

这很好，热插拔随它而来，但我宁愿重新启动我的常用应用程序，而不是测试所有的热插拔能力组合

它还被用于在移动端增加中间件和应用程序的可移植性。例如，WinMo、Symbian和Android都可以使用移动端。一旦与设备功能集成，可能会变得支离破碎。

• 类似地说，你可以在不关掉汽车的情况下更换汽车的发动机
• 您可以为客户定制复杂的系统。看看日食的力量吧
• 您可以重用整个组件。比仅仅是物体要好
• 您可以使用一个稳定的平台来开发基于组件的应用程序。这样做的好处是巨大的
• 您可以使用黑盒概念构建组件。其他组件不需要知道隐藏的接口，它们只看到发布的接口
• 您可以在同一系统中使用多个相同的组件，但在不同的版本中使用，而不会影响应用程序。OSGi解决了Jar地狱问题
• 有了OSGi，您就可以用它来构建系统了

---

对于每个使用Java的人来说，都有很多好处（我现在就提醒了他们）。

至少，OSGi让你想到了模块化、代码重用、版本控制以及项目的总体管道设计。

一些让我对OSGi着迷的事情：

1） 实现和它们的上下文加载器有很多怪癖，可以是异步的（我们在confluence内部使用felix）。与纯spring（无DM）相比，[main]几乎可以运行所有同步功能

2） 热负荷后，等级不相等。例如，您在hibernate上有一个tangosol缓存层。它由Fork.class填充，在OSGi范围之外。您热加载了一个新的jar，而Fork并没有改变。类[叉]！=类[叉]。出于相同的根本原因，它也会在序列化过程中出现

3） 集群

您可以解决这些问题，但这是一个很大的难题，并使您的体系结构看起来有缺陷

对于那些为热插拔做广告的人。。OSGi的第一个客户？日食。Eclipse在加载包后做什么

它会重新启动。

OSGi的组件系统为您提供了哪些好处
好吧，这里有一个很好的列表： 降低复杂性-使用OSGi技术开发意味着