OSGi 和 Java EE 之间的根本区别是什么？ [关闭]答案

【问题标题】：What are the fundamental differences between OSGi and Java EE? [closed]OSGi 和 Java EE 之间的根本区别是什么？ [关闭]
【发布时间】：2011-11-21 08:30:54
【问题描述】：

所以我今天下午花了一些时间终于坐下来开始阅读神秘而难以捉摸的“OSGi”及其所谓的bundles。

好的，所以我认为我明白了。 OSGi“捆绑包”基本上是一个带有一些附加清单信息的 JAR。而且，您无需将其部署到普通的应用程序服务器（或其他容器），而是将其部署到像 Apache Felix 这样的 OSGi 服务器。它运行，然后为用户/客户提供服务。

这与部署到应用服务器的普通 EAR 有何不同？？？

OSGi 似乎正在崛起（我一直在遇到它！），但对于我的生活，我不明白它提供了什么（功能方面）超过你可以用真正的企业服务器做的任何事情，比如GlassFish 或 Spring。

我知道世界并没有变得疯狂，所以我显然错过了一些东西。只是一直想不通是什么。感谢您的帮助或见解！

【问题讨论】：

我认为如果将其表述为“OSGi 和 Java EE 之间的根本区别是什么”，那么这将更有用，而不是“基于意见”
此时可以说... OSGi 主要是执行 CDI 试图解决的问题（依赖注入和解析）但不会通常阻止它运行的容器有错误。它提供了一个界面[通常通过命令行]，允许在运行时进行修复。 Java EE 需要部署来解决这些问题。 Java EE 是一个应用程序堆栈，虽然它提供容器服务，但它只在应用程序的范围内（尽管可能会从服务器获得注入）请注意，尽管大型 Java EE 服务器现在构建在 OSGi 上。

标签： java jakarta-ee osgi

【解决方案1】：

OSGi 包更像是一个“软件模块”，而不是一个“jar”、“war”或“ear”文件。如果 OSGi 捆绑包捆绑整个应用程序，它们很少能带来好处。但是，它们在连接大量库的自动化和正确处理方面非常有益。

所以考虑一下 OSGi 试图解决的问题，你会更好地理解它适合的地方。它是 C++ 中“钻石继承”模式的 Java 等价物。您包含两个库，每个库都需要一个通用的日志记录库，但在这种情况下，不是因为多重继承，而是因为多个包含语句。

如果这两个库都使用相同版本的通用日志库，那么您很幸运。如果他们不这样做，那么要让每个库独立正常工作，您需要加载同一个库的两个副本，每个副本可能使用相同的名称空间（并且通常是相同的类名）。

OSGi 是一种捆绑方式，它允许加载相同库的两个版本，它们使用相同的名称空间、相同的类名，但创建时间不同。它还将“正确”版本连接到“正确”OSGi 捆绑包，防止捆绑包使用“正确”库的“错误”版本。

Java EE 做了很多工作，但这不是 Java EE 甚至可以解决的问题。 Jigsaw 项目充其量只能解决同样的问题。 Java EE / OSGi 混淆的原因在于，大多数 OSGi 捆绑的早期采用者是那些实现类似于 Java EE 中提供的一些库的功能的人。也就是说，实际的容器连接框架 (OSGi) 与捆绑的功能无关（尽管一些发现在结构上进行了修改以符合 OSGi 捆绑要求）。

【讨论】：

不会像 Maven 或 Apache Ivy 这样的传递依赖管理器自己解决这个“JAR 地狱”吗？如果我的应用程序依赖于 2 个库 L1 和 L2，L1 依赖于 joda-time-1.1.jar，L2 依赖于 joda-time-1.2.jar，Ivy 会为我解决这个问题，只要我有两个版本在运行时我的类路径中的 joda-time，我很高兴。还是没有从这里的树木中看到森林......
Ivy 可以下载这两个 jar 文件，但是当需要编译时，Java 不允许在同一个类加载器中定义两个不同的类并具有相同的名称。如果将两者都放在类路径上，则满足类名的第一个将返回该类，无论它是正确的版本还是错误的版本。所以你需要类加载器树，具体依赖于调用类的“包”。这意味着您实际上需要一种方法来跟踪捆绑包的需求，因此需要清单文件以及最终的“框架”，即 Jigsaw 或 OSGi。
Ok....所以 OSGi 基本上通过提供一套专门的类加载器来解决命名空间问题。因此，如果您有幸拥有一个依赖关系图，其中没有两个库依赖于同一个 jar（或同一个 jar 不同版本），那么您就不需要 OSGi。否则，它似乎是一个非常重要的工具。这个评价好不好。另外，如果 OSGi 现在才刚刚兴起，那么 Java EE 应用程序如何存在这么长时间而没有解决这个问题？这是一种重大的！
除了隔离之外，OSGi 提供的其他东西很少是服务发现和单个服务的动态重新加载（无需重新启动应用程序）。 OSGi Compendum 中还描述了许多附加功能（标准配置、管理接口等）
@mamakin 很抱歉告诉你这一点，但是一旦找到该类，JEE 类加载层次结构就会停止。层次结构没有构造层次结构，因此一个“包含语句”可以拉入库的一个版本，而另一个“包含语句”拉入不同版本的库。

【解决方案2】：

将 Java EE 与 OSGi 进行比较就像比较苹果和橘子，还有一个额外的好处是不知道什么是什么。

Java EE 的重点是异构环境中的可扩展多层业务应用程序和企业范围内的信息系统集成。

OSGi 从另一个角度开始，将几个独立的代码库集成到一个 JVM 中（请原谅我非常简短）。

当然一些问题（例如热部署）在两种环境中都很常见 - 但程度不同。

当然，您可以对它们进行升级、降级和杂交，它们会在中间的某个地方相遇。

所以问题不应该是“A 比 B 有什么好处”，而应该是“A 在哪些领域比 B 具有明显优势，反之亦然？”让我换个说法：“我什么时候需要一把锤子，什么时候需要一把锯子？”

【讨论】：

如果是这个问题，你的答案是什么？ ;)

【解决方案3】：

大部分主要好处，至少是我们使用 OSGi 的原因，都列在http://karaf.apache.org/，尤其是前两个。

此外，OSGi 联盟还有很多好处：https://www.osgi.org/developer/benefits-of-using-osgi/。

【讨论】：

值得补充的是，OSGi 包不是一个“完整”应用程序，而是一个可以被任何其他包使用的子组件，这些包的集合构成一个应用程序。

【解决方案4】：

我很抱歉，但这里的所有答案都是完全可笑的。 OSGi 解决了依赖版本问题？ Pooooohlease.... 听说过应用服务器中的类加载器策略吗？

OSGi 似乎是一个继续销售新书和培训的想法，而 JEE 中的 JAR/EAR 打包和部署已经满足了千百年来的功能需求。那些购买它的人根本无法理解他们是如何被操纵的。还有一个趋势和时尚的问题。 IE。对这个行业来说是一种耻辱的非工程考虑因素。

重新发明轮子是有利可图的，因为那里有很多傻瓜。不幸的是，有大量的管理型傻瓜想要站在“技术的前沿”，他们会很乐意资助员工的课程，吸收学习曲线，然后通过他们的鼻子“重新设计”事物这对他们来说并没有错。

这不是“我要不要用螺丝刀或锤子”的问题。这更像是一个“嘿老板，外面有一个叫 HEMMAR 的新东西，它真的很酷！”的问题。 “这不是 HAMMER 吗？”、“不不，它更好，它是 HEMMAR，用于将钉子钉入木板，它将彻底改变世界”。

【讨论】：

虽然有点偏离主题（功能上），但这是最好和最正确的答案，不同之处在于您要么支付购买一个jee“容器”，要么下载并安装一个“免费”在您的组织中，并学会正确使用它。
企业应用程序本质上是不断发展的。您不会在第一天生成企业应用程序。当您拥有 1000 个模块并且它们都必须一起工作时，JEE 类加载策略是管理的真正噩梦。 JEE模块只能是EJB、MDB。 RAR 或 WEB 单个 JAR 怎么样？如果您甚至想更新单个模块，那么停机时间如何......没有阶段！所以 Pooooohlease JEE 与 OSGi 正在解决的问题相去甚远！