目前,您会使用 JBoss 或 Glassfish (或其他)作为新项目的 JavaEE 服务器吗?

如果您今天开始一个新的 JavaEE 项目,这个项目将在大约一年内完成,那么您会选择哪个应用程序服务器,为什么?

你的部分答案应该包括你对你的决定的论据。以及您对您选择的 JavaEE 服务器和市场上其他可用服务器有多少经验。这些都很有趣,因为我们都得到了一个调查的感觉,并认为这是你的答案。

63051 次浏览

我已经使用 jBoss 3-4年了。

JBoss 的论点:

  1. 开源。
  2. 提供商业支持。
  3. 活跃的大型用户社区。

反对 jBoss 的观点:

  1. 没有通用访问,支持 JavaEE5容器版本。
  2. 很多文档,但是很冗长; 可能很难找到“ How do I do x?”的答案
  3. 与其他商业产品相比,4.x 版本的管理工具很差。

我通常问自己的第一个问题是“我能用 Tomcat 做这个吗?”.如果答案是否定的,因为我需要 JMS 或 JTA,那么我会求助于应用服务器。

大约3年前,我使用 WebLogic 8,对 WebLogic 的易用性和许可/成本模型感到满意。我们将其用于两个项目,一个是 Web 服务,另一个是门户。我们在 WebLogic 或 WebLogic Portal 这两个项目中都没有遇到任何问题。

在过去的两年里,我一直在使用 WebSphere。无论何时我与 IBM 谈判,最终的成本都是 WebLogic 等价产品的两倍,但公司政策规定必须使用 WebSphere。我发现 WebSphere 上的学习曲线比 WebLogic 要陡峭得多,而且我们的构建/部署/测试生命周期非常耗时,以至于我们在开发环境中使用了 Tomcat。但是我在使用 WebSphere 时遇到的最大问题是,当我们遇到一个 bug,迫使我们升级到下一个补丁版本时,却遇到了解析 web.xml 的新问题。我花了48小时才熬过来。

虽然目前我使用的是 JBoss。大约3个月前,我正准备开始我的新项目 Tomcat 和 Jetspeed 2,但是我注意到 Jetspeed 2现在看起来有点停滞不前,JBoss Portal 2.7.0刚刚发布了支持 JSR 286/Portlet 2.0的版本。我试用了 JBoss,发现它非常容易设置和管理。构建/部署/测试周期非常快,除非在某处更改了 Spring XML 文件,否则很少需要重新启动服务器。

我可能会把你喜欢的操作系统作为决策标准。如果您使用同一个供应商的操作系统和应用程序服务器,它应该更容易支持。如果您已经与一个或两个供应商建立了关系,请考虑是否可以与他们进行良好的交易。

从技术角度来看,我会选择 GlassFish,因为它支持更新的创新。我不认为 JBoss 是坏的,无论如何它只是不是最新的。

我的大部分经验是在 WebLogic 上,但我使用过 JBoss 和 GlassFish。我刚刚在一个完整的 Sun 开源堆栈(OpenSolaris,GlassFish,MySQL)上发布了一个新站点,这是一个很棒的经历,只有一些小挫折。

在过去的10多年里,我使用过 WebLogic、 WebSphere、 JBoss、 GlassFish、 RESH、 Jetty、 Tomcat 和其他一些软件。所以,如果我在考虑一个新项目,我会先问自己几个问题。我不会再质疑的一件事是,除非我被折磨到哭着喊妈妈,否则我会坚决拒绝使用 JSP。

我必须兼容/部署到特定的产品,因为某人的命令?难道就没有办法忽视他们或者说服他们不这么做吗?如果是这样,这就是你的答案。

我必须使用 EJB 吗?真的吗?如果可能的话尽量避免使用它们——它们实际上只在非常大的企业级系统中才需要。记住,它们只是工具,而且是巨大的工具(有人会说“黄金大锤”吗?).它们被过度使用,所以真的,真的质疑你是否需要它们。如果你真的需要它们,那么你就失去了一些选择,包括我最喜欢的 Jetty。

您是否必须使用其他主要的 J2EE 技术,如 JMS、 ESB 等?如果是这样的话,而且您真的不能没有它,那么您将再次被限制在一个成熟的 J2EE 容器中。例如,在您决定使用 BPM 之前,请仔细考虑和调查,避免使用(几乎)所有代价的 AquaLogic BPM ——它极其丑陋。

如果您真的必须使用成熟的 J2EE 容器,那么首先考虑开源,因为它更加健壮、受到更好的支持,并且更具成本效益。它们拥有更大的客户基础和更开放的支持交互,因此它们往往能更快地获得更好的修复。然而,树脂是不成熟的,相对于 GlassFish 或 JBoss,我会避免使用它——我发现部署和支持它是有问题的。我更喜欢 JBoss,因为它有更广泛的客户基础,更成熟等等。GlassFish 很难整合到自动化的构建/部署过程中,但是它的一些特定特性(如果您需要的话)可能会更好。

我需要阿帕奇有什么特别的原因吗? 那就向 Tomcat 倾斜,也许还有些别的原因。

我可以只使用 servlet 吗?然后我会使用 Jetty ——它是最轻、最快、最简单、最灵活的解决方案。如果我倾向于不能使用 Jetty,我会质疑我所有的假设。YAGNI 适用。

最好是在 Jetty 上使用 StringTemplate/WebStringTemplate: 一个干净、健壮、快速、可维护的解决方案,没有许可费用、良好的声誉和支持等等。这就是我现在开始的地方。

大多数应用程序/系统选择了许多花哨的 J2EE 特性,而它们真正需要的只是具有一些体面架构/设计的 servlet 和 JDBC。问问你为什么觉得你需要更多。

在成熟的容器中,我会避免使用 WebLogic 和 WebSphere,除非你支持一个 MAJOR 公共网站(我现在雇主的网站部署在 WebLogic 上,每月有1100多万的点击率,其他网站的点击率相当)。WebLogic 真正成名的地方在于它们相对容易的集群,但是要避免它们的专有供应商锁定功能(几乎是不惜一切代价)。WebSphere 只是一个我会不惜一切代价避免的噩梦——在过去做过几个涉及 WebSphere 的项目之后,我拒绝做这样的项目。这两种产品都不值得支付大量的许可费,除非您确实有特殊需求,从而驱动使用专有特性。作为《财富》500强企业的高级建筑师/工程师,在过去的十年里,我还没有看到这样的需求。另一方面,我看到了很多痛苦,因为选择这样的专有产品。

即使对于那些真正庞大、流量高的公共网站来说,其专有产品仍然值得怀疑。我宁愿把每年数百万美元的许可费用花在一些好的硬件上,花在一些优秀顾问的高质量时间上,来解决一个简单的可伸缩性解决方案。每年额外的数百万美元可以用来制作一些值得在那个漂亮的网站上销售的东西。

编辑: 另一个需要考虑的部分..。

我最近遇到了 兵马俑。我正在重新考虑所有的事情,并希望尽快将其部署到一个重要的系统中。特别是,Terracotta 在集群方面做得比其他任何东西都好,所以我不再推荐 WebLogic 进行集群。

我仍然认为 WebLogic 是市场上最好的 JavaEE 应用服务器。我觉得如果你能负担得起那些执照费用,这是值得的。

通过组合 Tomcat、 OpenEJB 和 ActiveMQ,我很惊讶地看到您能走多远。在我看来,这是一个低成本的选择。

我还要查看 Springdm 服务器。它是基于 Tomcat 的,但我认为他们添加的 OSGi 片段可以在短时间内遍布各地。如果它的质量与 Spring 框架相同,那么它的确非常好。

另一种选择: 根本不使用 appserver。

查看 译自: 美国《科学》杂志网站(http://www.atomikos.com/publications/j2eeWithoutApplicationServer) http://www.atomikos.com/publications/j2eewithoutapplicationserver

对于 Web 项目,如果必要的话,可以保留一个轻量级的 Web 容器,并结合 Wicket 之类的东西,以避免 JSP/JSF 或 struts 的复杂性。

盖伊

术语“应用服务器”是模棱两可的。使用 GlassFish v3,您可以从小型开始,比如说,一个传统的 Web 容器,然后进化(使用 OSGi 和简单的“添加容器”功能)来添加任何您想要添加的东西: JPA、 JAX-RS、 EJB、 JTA、 JMS、 ESB 等等。.然而,它是同样的产品,同样的管理界面,等等。对您来说,这算是一个应用服务器吗? - Alexis (Sun)

看看 GlassFish 3.1!基于 Java EE 6的 GlassFish v3内核构建在模块之上,版本3.1提供集群、集中管理和高可用性。

详情请参阅 http://blogs.oracle.com/nazrul/entry/glassfish_3_1

这里没有讨论的另一个问题是性能。如因服务类别或使用者人数而令人关注,则可采用以下方法:

  • 雄猫似乎比玻璃鱼慢
  • 玻璃鱼似乎比树脂慢
  • 树脂比 G-WAN + Java 慢得多

请注意,G-WAN 仅依赖于 JVM: 它不使用任何进一步的容器(除非明确指定) ,因此您可以将它保留给 Web 应用程序的性能关键部分。

由于 G-WAN 支持其他语言(C、 C + + 、 C # 、 D、 Objective-C) ,您甚至可以使用原始 C 处理应用程序的某些部分,同时保留 Java 用于其他任务。