比较 OpenEjb 和 Glassfish

发布于 2024-09-11 12:45:57 字数 143 浏览 9 评论 0原文

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

OpenEJB 代替 glassfish 有什么限制？

问候

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

谁的新欢旧爱 2024-09-18 12:45:57

请注意，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.1 版本中完成了重要的远程性能工作，并在我们的基准测试中将 RPC 调用的平均值提高到 7300 TPS。

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

更新

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

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

就我个人而言，我认为该帖子中的评论是采取认证步骤的主要动力之一。感谢 StackOverlfow 的每个人提供的反馈，我觉得这些反馈既令人鼓舞又很有根据。与这个社区的联系给 OpenEJB/TomEE 带来了很多积极的变化。

Note that Hani's comment was in regards to Geronimo 1.0/OpenEJB 2.0. Hani was wrong in the frankenstein comment as the OpenEJB 2.x codebase was built entirely from scratch for Geronimo and as a result it only ran in Geronimo; the embedded, tomcat, and standalone modes were all lost. We found Hani's comment was right in that the performance was not good.

For OpenEJB 3.x we abandoned the 2.x codebase and picked things up from where we left off in OpenEJB 1.x and brought it up to EJB 3.0 certification. 2.x and 3.x share no code. OpenEJB 3.x turned out very well and the project has been growing pretty rapidly since the first 3.0 release in 2008. The EJB 3.1 Embedded Container and EJBs in .wars features came from OpenEJB. We had the first @Singleton implementation and hope to complete the rest of EJB 3.1 and certify web profile by Q4 this year. Failover and JMX monitoring have been under heavy development since January, are now complete, and will be released in 3.1.3 in a couple weeks. The failover is actually second generation, the first failover support was released in 3.1.1. There was significant remote performance work done in the 3.1.1 release as well bringing RPC calls up to a mean of 7300 TPS in our benchmarking.

Less important to some, but very important to others, Apache OpenEJB is not a corporately controlled open source project. The majority of committers are users who have earned commit and use OpenEJB at work. This has its advantages and disadvantages, but the bottom line is OpenEJB is filled with people who love it and use it and the community is just as open as the source.

UPDATE

In October 2011, we obtained Java EE 6 Web Profile certification with "Tomcat+OpenEJB", now called Apache TomEE.

Certified and with a clearer name, we hope this makes the stack easier to both understand and compare.

On a personal note, I view the comments in this thread as one of the major motivators for taking the certification step. Thank you to everyone at StackOverlfow for feedback which I find both encouraging and grounding. Connecting with this community has resulted in so much positive change in OpenEJB/TomEE.

回复收藏 0 原文

So尛奶瓶 2024-09-18 12:45:57

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

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

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

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

第三，我从未对 OpenEJB 进行过测试，我仅将其用于测试，从未计划将其用于生产，主要是因为它的声誉不佳。请参阅此评论，了解 Geronimo 在 TSS 上的表现（来自 Hani Suleiman ，如果它是腐蚀性的，请不要感到惊讶）：

我想这句话是说 EJB
等级“可接受”是关于
你能说的最好的事情。
据我所知，geronimo 的 ejb 代码
基于 openEJB，它具有，
从历史上看，bean是最糟糕的容器
你可能会找到。你必须
看起来也很难找到，只是
充满不同程度的
一旦你做到了这一点就会后悔/愤怒
可疑的目标。
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，尤其是在没有问题需要解决的情况下。

另请参阅

I guess the question is about the runtime environment but still, I don't understand what lighter application does mean. Memory footprint? Startup time? Deployment time? What problem do you actually have? And please define light.

For what it's worth, I consider GlassFish 3 as a light runtime and my experience with it is very positive. From the product data sheet:

Oracle GlassFish Server 3 implements the OSGi runtime, which allows features to be dynamically added to the Java server as needed, and for the smallest possible Java stack to be deployed to support applications. This helps to keep the footprint as small as possible by loading only the modules required to service deployed applications—improving startup time and reducing resource utilization.

Second, I personally don't like the Frankenstein approach, I believe that the glue between all parts that you get with a real application server is part of the added value, that's actually why I use an app server.

Third, I never benched OpenEJB, I used it for testing only and never planned to use it for production, mostly because of its bad reputation. See this comment about Geronimo's performances on TSS (from Hani Suleiman, don't be surprised if it's caustic):

I'd imagine that saying that the EJB
tier is 'acceptable' is about the
nicest thing you could say.
From what I know, geronimo's ejb code
is based off openEJB, which has,
historically, bean the worst container
you could possibly find. You'd have to
look pretty hard to find it too, only
to be filled with various degrees of
regret/rage once you achieve that
dubious goal.
It's not surprising that G's
performance will always be sub-par.
The frankenstein approach of software
building is a great recipe for bad
performance. Sure, you'll have lots of
pretty diagrams, great looking
dependency graphs, and loose coupling.
All of which are fairly irrelevant to
users who want a coherent appserver
that they can treat as a black box.

Things might have changed, OpenEJB has probably improved, at least a bit, but still:

OpenEJB doesn't fully support EJB 3.1.
Tomcat + OpenEJB is still not a full Java EE implementation, you might still have to add some pieces to your creature (not even mentioning Java EE 6).
And what about the administration, clustering, etc?
If you don't need the full Java EE 6 profile, there is the Java EE 6 web profile
I'm happy with GlassFish 3, I don't find it "heavy" (and I suggest to try it).
I know it can perform well.

For all these reasons, I wouldn't consider Tomcat+OpenEJB instead of GlassFish, especially if there is no problem to solve.