9

我们可以用 Tomcat/OpenEJB 替换 Glassfish 来实现更轻量级的应用程序吗？与作为 EJB 容器的 glassfish 相比，OpenEJB 的性能如何。

OpenEJB 而不是 glassfish 的限制是什么？

问候

4

6 回答 6

9

请注意，Hani 的评论是关于 Geronimo 1.0/OpenEJB 2.0。Hani 在 frankenstein 的评论中是错误的，因为 OpenEJB 2.x 代码库完全是为 Geronimo 从头开始​​构建的，因此它只能在 Geronimo 中运行；嵌入式、tomcat 和独立模式都丢失了。我们发现哈尼的评论是正确的，因为性能不好。

对于 OpenEJB 3.x，我们放弃了 2.x 代码库，并从我们在 OpenEJB 1.x 中中断的地方重新开始，并将其提升到 EJB 3.0 认证。2.x 和 3.x 不共享代码。OpenEJB 3.x 结果非常好，自 2008 年第一个 3.0 版本以来，该项目一直在快速增长。EJB 3.1 嵌入式容器和 .wars 功能中的 EJB 来自 OpenEJB。我们有第一个@Singleton 实现，并希望在今年第四季度完成 EJB 3.1 的其余部分并认证 Web 配置文件。自 1 月份以来，故障转移和 JMX 监控一直在大力开发，现已完成，并将在几周后在 3.1.3 中发布。故障转移实际上是第二代，第一个故障转移支持是在 3.1.1 中发布的。在 3.1 中完成了重要的远程性能工作。

Apache OpenEJB 对某些人来说不那么重要，但对其他人来说却非常重要，它不是一个公司控制的开源项目。大多数提交者是已获得提交并在工作中使用 OpenEJB 的用户。这有其优点和缺点，但归根结底是 OpenEJB 充满了热爱和使用它的人，并且社区与源代码一样开放。

更新

2011 年 10 月，我们通过“Tomcat+OpenEJB”（现在称为 Apache TomEE）获得了 Java EE 6 Web Profile 认证。

经过认证并具有更清晰的名称，我们希望这使堆栈更易于理解和比较。

就个人而言，我认为此线程中的评论是采取认证步骤的主要动力之一。感谢 StackOverlfow 的每个人的反馈，我觉得这些反馈既鼓舞人心，又让我感到鼓舞。与这个社区的联系导致 OpenEJB/TomEE 发生了如此多的积极变化。

于 2010-07-26T20:15:32.750 回答
5

我想这个问题是关于运行时环境的，但我仍然不明白更轻的应用程序是什么意思。内存占用？启动时间？部署时间？你实际上有什么问题？请定义光。

对于它的价值，我认为 GlassFish 3 是一个轻量级的运行时，我对它的体验非常积极。从产品数据表：

Oracle GlassFish Server 3 实现了 OSGi 运行时，它允许根据需要将功能动态添加到 Java 服务器，并部署尽可能小的 Java 堆栈以支持应用程序。这有助于通过仅加载为部署的应用程序提供服务所需的模块来尽可能减小占用空间——缩短启动时间并降低资源利用率。

其次，我个人不喜欢科学怪人的方法，我相信你使用真正的应用程序服务器获得的所有部分之间的粘合剂是附加价值的一部分，这实际上就是我使用应用程序服务器的原因。

第三，我从来没有替 OpenEJB 做替补，我只将它用于测试，从未计划将它用于生产，主要是因为它的名声不好。请参阅有关 Geronimo 在 TSS 上的表现的评论（来自 Hani Suleiman，如果它是腐蚀性的，请不要感到惊讶）：

我想，说 EJB 层是“可接受的”是你能说的最好的话。

据我所知，geronimo 的ejb 代码基于openEJB，从历史上看，它是您能找到的最糟糕的容器。你也必须看起来很难找到它，一旦你实现了那个可疑的目标，就会充满不同程度的遗憾/愤怒。

G的表现总是低于标准并不奇怪。软件构建的科学怪人方法是导致性能不佳的良方。当然，您将拥有许多漂亮的图表、漂亮的依赖关系图和松散耦合。对于想要一个可以将其视为黑匣子的一致应用服务器的用户来说，所有这些都无关紧要。

事情可能已经改变了，OpenEJB 可能已经改进了，至少有一点，但仍然：

  • OpenEJB 不完全支持 EJB 3.1。
  • Tomcat + OpenEJB 仍然不是一个完整的 Java EE 实现，您可能仍然需要为您的生物添加一些部分（甚至没有提到 Java EE 6）。
  • 那么管理、集群等呢？
  • 如果您不需要完整的 Java EE 6 配置文件，可以使用 Java EE 6 Web 配置文件
  • 我对 GlassFish 3 很满意，我觉得它并不“沉重”（我建议尝试一下）。
  • 我知道它可以表现良好。

由于所有这些原因，我不会考虑用 Tomcat+OpenEJB 代替 GlassFish，尤其是在没有问题需要解决的情况下。

相关问题

也可以看看

于 2010-07-26T07:21:56.470 回答
4

在我的简短测试中，我发现 glassfish 的亮度不足以满足我的需求（启动时间和内存使用）。到目前为止，我对 openejb 很满意。

于 2010-07-27T08:22:32.003 回答
4

真是有趣的帖子。这正是我们（公司）在三四年前尝试 OpenEJB 3.0 之前的观点！

我们现在对 OpenEJB 有了很好的体验，它在生产/开发中得到了广泛的应用。它非常轻巧且易于使用。多亏了 OpenEJB，开发人员节省了大量时间（Matthew B. Jones 的帖子也是一个很好的反馈）。

社区活跃，思想开放，随时准备通过来自用户真实反馈的有用功能来帮助和改进产品。

最后但并非最不重要的一点是，表演真的很棒！

让-路易

于 2010-07-30T11:36:52.753 回答
3

OpenEJB 作为独立应用程序服务器的轻量级嵌入式替代方案。我们将我们的应用程序从 JBoss 和 Weblogic（它必须同时支持两者）移植到 Tomcat/OpenEJB 上，没有出现重大问题。性能测试显示了增益或不差的结果。

OpenEJB 最大的限制是文档不完整。它的网站还可以（它实际上对于开源项目来说相当不错），但它无法与 JBoss、Glassfish 等相提并论。

您应该注意的另一件事是它使用 ActiveMQ 作为 JMS 提供程序，这是另一个开源项目。与 ActiveMQ 的集成很好，但存在一些限制。例如，您不能只升级到最新版本的 ActiveMQ。

再一次，与开源一样，缺乏支持和文档可以通过免费访问源代码和编写它的开发人员来弥补。

于 2010-10-09T03:55:26.130 回答
2

我认为我支持 David Blevins，因为 Glassfish 现在意味着 Oracle，我们都知道他们为 OC4J 留下的遗产。我担心 Glassfish 可能需要越来越多的硬件来提供相同的服务。

无论如何，最好的建议是：建立一个 Benchmark 并自己尝试这两种解决方案，这只需不超过 20 小时的专家工作。

于 2010-07-26T20:51:36.207 回答