OSGi 和 Java EE 之间的根本区别是什么？

What are the fundamental differences between OSGi and Java EE?

提问by IAmYourFaja

So I took some time this afternoon to finally sit down and begin reading up on the mysterious and elusive "OSGi" and its so-called bundles.

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

OK, so I thinkI get it. An OSGi "bundle" is basically a JAR with some additional manifest information. And, instead of deploying it to a normal application server (or other container), you deploy it to an OSGi server like Apache Felix. It run and then provides services to users/clients.

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

How is this any different than a normal EAR being deployed to an app server???

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

OSGi seems to be on the rise (I keep running into it!), but for the life of me I don't understand what it offers (feature-wise) over anything you can do with real-deal enterprise server like GlassFish or Spring.

OSGi 似乎正在兴起（我一直在遇到它！），但在我的生活中，我不明白它提供了什么（功能方面），而不是你可以用像 GlassFish 或 Spring 这样的真实企业服务器做的任何事情.

I know the world hasn't gone crazy, so I'm obviously missing something. Just haven't been able to figure out what. Thanks for any help or insight!

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

回答by Edwin Buck

An OSGi bundle is more of a "software module" than a "jar", "war", or "ear" file. OSGi bundles rarely provide benefit if they bundle an entire application; however, they are very beneficial in the automation and correct handling of hooking up lots of libraries.

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

So consider the problem OSGi attempted to solve, and you will better understand where it fits. It is the Java equivalent of the "diamond inheritance" pattern from C++. You include two libraries, which each need a common logging library, but in this case it's not because of multiple inheritance, it's because of multiple include statements.

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

If the two libraries both work with the same version of the common logging library, you're in luck. If they don't, then to get each library working correctly independently, you need to load two copies of the same library, each which likely uses the same name spaces (and often the same class names).

如果这两个库都使用相同版本的公共日志库，那么您很幸运。如果没有，那么为了让每个库独立正常工作，您需要加载同一个库的两个副本，每个副本可能使用相同的名称空间（通常是相同的类名）。

OSGi is a means of bundling which allows two versions of the same library to be loaded which use the same name spaces, the same class names, but were created at different times. It also hooks up the "right" version to the "right" OSGi bundle, preventing a bundle from using the "wrong" release of the "right" library.

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

Java EE does a lot, but this isn't something that Java EE even addresses. At best, project Jigsaw was working on the same problem. Where the Java EE / OSGi confusion comes into play is that most of the early adopters of OSGi bundling were those who were implementing functionality similar to some of the libraries offered in Java EE. That said, the actual container-connection framework (OSGi) had nothing to do with the bundled functionality (although some of the discovery was structurally modified to comply with OSGi bundling requirements).

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

回答by A.H.

Comparing Java EE with OSGi is like comparing apples and oranges with the additional bonus of not knowing what is what.

比较 Java EE 和 OSGi 就像比较苹果和橘子一样，但额外的好处是不知道什么是什么。

Java EE focus is on scalable multi-tier business applications in heterogenous environments and enterprise wide integration of information systems.

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

OSGi started at another corner by integrating several independent codebases into one JVM (please excuse me for being extremelybrief).

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

Of course someproblems (e.g. hot deployment) are common to both environments - but to a varying degree.

当然，有些问题（例如热部署）在两种环境中都是共同的——但程度不同。

Of course you can upgrade, downgrade and crossbreed both of them and they will meet somewhere in the middle.

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

So the question should not be "What benefit has A over B" but something like "In what field A has clear advantages over B and vice versa?" Let me rephrase that: "When do I need a hammer and when do I need a saw?"

所以问题不应该是“A 比 B 有什么好处”，而是“A 在什么领域比 B 有明显优势，反之亦然？” 让我改写一下：“我什么时候需要锤子，什么时候需要锯子？”

回答by Tomasz Jankowski

I'm sorry but ALL answers here are completely laughable. Dependency version issues solved with OSGi? Pooooohlease.... Ever heard of class loader policies in app servers?

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

OSGi seems like an idea to keep selling new books and training, while the functional needs have been covered for eons by the JAR/EAR packaging & deployment in JEE. Those who buy into it simply never got to understand how they're being manipulated. There's also a question of trends and fashion. I.e. non-engineering considerations that are a shame to this industry.

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

Reinventing the wheel is profitable because there are tons of fools out there. Unfortunately, there are tons of management-type simpletons who want to be on the "bleeding edge of technology" who will gladly fund their employees' courses, absorb the learning curve, and then pay through their nose in "re-engineering" of things that had nothing wrong with them to begin with.

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

It's not a question of "am I to use a screwdriver of a hammer". It's more a question of "hey boss, there's this new thing out there called HEMMAR, and it's really cool!". "Isn't it a HAMMER?", "No no, it's waaaaay better, it's a HEMMAR, it's for driving nails into boards, it will revolutionize the world".

这不是“我用锤子的螺丝刀”的问题。这更像是一个“嘿老板，有一种叫做 HEMMAR 的新东西，它真的很酷！”的问题。“这不是锤子吗？”，“不不，它更好，它是 HEMMAR，用于将钉子钉在板上，它将彻底改变世界”。

回答by Tony

Most of the major benefits, at least the reasons we use OSGi, are listed at http://karaf.apache.org/, notably the first two.

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

Additionally, the OSGi alliance has a long list of benefits: https://www.osgi.org/developer/benefits-of-using-osgi/.

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