OSGi和Java EE有哪些根本区别？

Question

OSGi和Java EE有哪些根本区别？

18

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

好的，那么我认为我明白了。一个 OSGi 的 “bundle” 基本上是一个带有一些额外清单信息的 JAR 文件。并且，你不是将其部署到普通应用服务器（或其他容器）上，而是将其部署到像 Apache Felix 这样的 OSGi 服务器上。它运行并向用户/客户端提供服务。

这与部署到应用服务器的普通 EAR 有什么区别吗？？？

OSGi 似乎正在崛起（我不停地遇到它！），但就我个人而言，我不明白它在功能方面相对于 GlassFish 或 Spring 等真正的企业服务器提供了什么优势。

我知道世界没有疯狂，所以显然我漏掉了什么。只是一直没能找出来。谢谢任何帮助或见解！

- IAmYourFaja

我认为如果这个问题被表述为“OSGi和Java EE之间的根本区别是什么”，那么它会更有用，也不会那么“基于观点”。 - Archimedes Trajano

在哪个点上可以说...OSGi主要是一个容器，它解决了CDI试图解决的问题（依赖注入和解析），但通常不会在出现错误时阻止其运行。它提供了一个接口[通常通过命令行]，允许在运行时进行修复。Java EE需要部署才能解决问题。Java EE是一个应用程序堆栈，虽然它提供容器服务，但它只在应用程序范围内（虽然可能从服务器获得注入）。请注意，现在大型Java EE服务器都构建在OSGi之上。 - Archimedes Trajano

4个回答

4

将Java EE与OSGi进行比较，就像比较苹果和橙子一样，并且不知道哪个是哪个的额外奖励。

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

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

当然，有些问题（例如热部署）对两种环境都是普遍存在的，但程度各不相同。

当然，您可以升级、降级和交叉使用它们，它们会在某些方面相遇。

因此，问题不应该是“A优于B有什么好处”，而应该是“在哪个领域A具有明显优势，B反之亦然？”让我重新说一下：“我何时需要锤子，何时需要锯子？”

- A.H.

10

如果那是问题，你的答案是什么？;) - Rui Marques

2

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

OSGi似乎是一种保持销售新书和培训的想法，而功能需求在JEE的JAR/EAR打包和部署中已经被覆盖了数十年。那些购买它的人根本没有理解他们如何被操纵。还有趋势和时尚的问题。也就是说，非工程考虑对这个行业来说是个耻辱。

重复发明轮子是有利可图的，因为有成堆的傻瓜。不幸的是，有成堆的管理型傻瓜想要处于“技术前沿”，他们会很乐意资助员工的课程，在学习曲线上付出代价，并支付“重新设计”那些原本没有问题的东西。

这并不是“我要使用螺丝刀还是锤子”的问题。更多的是“嘿，老板，有一个叫做HEMMAR的新东西，它真的很酷！”。 “它不是锤子吗？” “不，不，它远远更好，它是一种HEMMAR，它可以将钉子钉入木板，它将彻底改变世界。”

- Tomasz Jankowski

虽然这与主题（功能上）有些偏离，但这是这里最好、最正确的答案，区别在于你可以付费获得一个JEE“容器”，或者在你的组织中下载和安装一个“免费”的容器，并学会正确使用它。 - niken

1

企业应用程序本质上是不断发展的。你不能在第一天就生产出企业应用程序。当你有1000个模块且它们都必须协同工作时，JEE类加载策略将是一个真正的噩梦难以管理。JEE模块只能是EJB、MDB、RAR或WEB，那么单个JAR呢？如果你想更新单个模块，那么停机时间怎么办……没有分阶段！因此，请注意，JEE远远不及OSGi所解决的问题！ - SJunejo

2

大多数主要优点，至少我们使用OSGi的原因，在http://karaf.apache.org/列出，特别是前两个。

此外，OSGi联盟有一个长列表的优点：https://www.osgi.org/developer/benefits-of-using-osgi/。

- Tony

1

值得注意的是，OSGi bundle 不是一个“完整”的应用程序，而是一个子组件，可以被任何其他 bundle 使用，这些 bundle 的集合组成了一个应用程序。 - Tony

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Edwin Buck · Accepted Answer

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

因此请考虑OSGi试图解决的问题，你将更好地理解它的适用范围。这相当于C ++中的“钻石继承”模式的Java版本。您包括两个库，每个库都需要一个公共的日志记录库，但在这种情况下，这不是由于多重继承，而是由于多个include语句。

如果这两个库都使用相同版本的公共日志记录库，则运气爆棚。如果它们没有，那么为了让每个库在独立工作时都能正确运行，您需要加载两个副本的相同库，每个库都可能使用相同的名称空间（通常还有相同的类名）。

OSGi是一种捆绑方式，允许加载两个使用相同名称空间、相同类名但创建于不同时期的相同库，并将“正确”的版本与“正确”的OSGi bundle连接起来，防止bundle使用“错误”的“正确”库发布。

Java EE做了很多事情，但这并不是Java EE所涉及的内容之一。最多，项目Jigsaw正在解决同样的问题。Java EE / OSGi混乱之处在于，大多数早期采用OSGi捆绑的人都是那些实现了类似于Java EE中所提供的一些库功能的人。也就是说，实际的容器连接框架（OSGi）与打包的功能无关（尽管一些发现已结构上修改以符合OSGi打包要求）。