你会在目前使用JBoss或Glassfish(或其他)作为Java EE服务器来开展新项目吗?

136

如果你今天开始了一个为期一年左右的新Java EE项目,你会选择哪个应用服务器?为什么?

你的回答应包括你做出该决策的理由。另外还要说明您在所选Java EE服务器上的经验以及市场上其他可用服务器的经验。这些是有趣的,因为我们可以感受到你在回答中所付出的研究和思考。

9个回答

180

在过去的10多年中,我使用了WebLogic、WebSphere、JBoss、GlassFish、Resin、Jetty、Tomcat等多种IT技术。因此,如果我考虑一个新项目,我首先会问自己几个问题。其中一个我不会再质疑的事情是,除非我被折磨到哭妈妈为止,否则我绝不会再使用JSP。

我是否必须兼容/部署特定产品,因为有人的命令?是否没有办法忽略它们或说服他们改变想法?如果是这样,那么答案就出来了。

我是否必须使用EJB?真的吗?尽可能避免使用它们--它们只在非常大型的企业级系统中才真正需要。请记住,它们只是工具,而且是很大的工具(有人能说“金鎚子”吗?)。它们被过度使用,所以一定要认真地质疑你是否需要它们。如果确实需要它们,那么这将削弱你的选择,包括我的最爱Jetty。

您是否必须使用其他主要的J2EE技术,如JMS、ESB等?如果是这样,并且您真的不能没有它们,则再次受限于完整的J2EE容器。在承诺BPM之前,请仔细考虑和调查,并尽可能避免使用AquaLogic BPM--它极其丑陋。

如果您确实必须使用完整的J2EE容器,首先考虑开源,因为它更强大、得到更好的支持并且更具成本效益。它们拥有更大的客户群和更多的开放式支持交互,因此它们往往会更快地获得更好的修复程序。但是,相对于GlassFish或JBoss,Resin还不成熟,我会避免使用它--我发现它部署和支持存在问题。我更喜欢JBoss,因为它拥有更广泛的客户群、成熟度等等。GlassFish很难纳入自动化构建/部署流程中,但如果您需要它的特定功能(如果您需要),它可能会更好一些。

我是否有特殊理由需要使用Apache?那么可以倾向于Tomcat,可能再加上其他东西。

我只使用Servlet能否胜任?如果可以,我会选择Jetty——它是最轻、最快、最简单、最灵活的解决方案。如果我对使用Jetty持怀疑态度,那么我会质疑自己为什么要这样做。YAGNI原则适用。

最好使用StringTemplate/WebStringTemplate on Jetty:一种干净、强大、快速、可维护的解决方案,没有许可费、具有良好的声誉和支持等等,这就是我现在的首选。

大多数应用程序/系统选择使用很多花哨的J2EE特性,而实际上他们只需要一些合理的架构/设计以及Servlets和JDBC。质疑为什么你认为你需要更多的东西。

对于全功能容器来说,除非您要支持一个主要的公共网站(我的当前雇主的网站部署在WebLogic上,并且每月接收1100万次以上的点击量,其他情况类似),否则我会避免使用WebLogic和WebSphere。WebLogic真正的招牌是其相对较容易的集群,但请尽量避免使用他们的专有供应商锁定功能。WebSphere就是一场噩梦,我会尽可能避免——在过去做了几次WebSphere项目后,我拒绝做任何涉及WebSphere的项目。除非您真正有一个驱动使用专有功能的特殊需求,否则这两个产品都不值得支付巨额许可费用。作为一名高级架构师/工程师,我在为许多财富500强公司工作的十年中,从未见过这样的需求。另一方面,我看到很多由于选择这些专有产品而导致的痛苦。

即使对于那些真正大型、高流量、公共网站,也还有问题。我宁愿将每年的数百万美元许可费用用于购买一些好硬件和一些来自一些真正优秀的顾问的优质时间,以解决一个简单的可扩展性方案。然后,多出来的数百万美元可以用于生产一些值得在那个漂亮网站上销售的东西......

编辑:还有一个需要考虑的因素...

我最近遇到了Terracotta。我正在重新思考一切,并计划很快在一个重要的系统中部署它。特别是,Terracotta比其他任何东西都更擅长集群,因此我不再推荐WebLogic的集群。


7
供日后参考,您通常可以通过Google或维基百科搜索找到缩略语的定义。YAGNI = You Aren't Going to Need It(你不会需要它)= 不要过度设计 JMS = Java消息服务 ESB = 企业服务总线 BPM = 业务流程管理 - Rob Williams
21
你对Java EE和EJB的评论有些过时了。J2EE?那已经是5年前的事情了。看一下Java EE 6,现代化你的观点吧! - Brian Leathem
6
我同意Brian的观点,特别是对于EJBLite来说,它变得更加轻量级了。 - Thang Pham
7
@Brian,请看这篇文章——它是在你的评论三年前写的。我仍然认为Spring比Java EE瘦身后还要轻。 - duffymo
2
EJB不再繁琐。你对EJB的看法已经过时了。 - Oliver Watkins
显示剩余8条评论

10
术语“应用服务器”很模糊。使用GlassFish v3,您可以从传统的Web容器开始,并演变(使用OSGi和简单的“添加容器”功能)以添加任何您想要的内容:JPA、JAX-RS、EJB、JTA、JMS、ESB等等...... 然而,它是同一产品,同一管理界面等。您认为这是否符合应用服务器的要求?-Alexis(Sun)

1
不幸的是,Glassfish不再是官方产品,而只是“参考实现”。 - Thorbjørn Ravn Andersen

9
我通常会问自己一个问题:"我能用Tomcat做到这个吗?"。如果答案是否定的,因为我需要JMS或JTA,那么我就会使用应用服务器。
大约3年前,我使用过WebLogic 8,并且很满意它的易用性和许可/成本模型。我们用它来完成了两个项目,一个是Web服务,另一个是门户网站。在这两个项目中,我们都没有遇到任何WebLogic或WebLogic门户方面的问题。
接下来的两年里,我一直在使用WebSphere。每当我与IBM协商时,最终的成本总是是WebLogic相应成本的两倍,但公司政策规定必须使用WebSphere。我发现,与WebLogic相比,WebSphere的学习曲线要陡峭得多,而我们的构建/部署/测试生命周期非常耗时,以至于我们在开发环境中使用Tomcat。但是,我在WebSphere上遇到的最大问题是,当我们遇到一个错误时,被迫升级到下一个补丁版本,结果遇到了新的问题,解析web.xml时出错。这花费了我们48小时才解决。
目前,我正在使用JBoss。大约3个月前,我准备开始使用Tomcat和Jetspeed 2开展新项目。但是我注意到目前Jetspeed 2似乎有点停滞不前,而JBoss Portal 2.7.0刚刚发布,支持JSR 286/Portlet 2.0。我试用了JBoss,发现它非常容易设置和管理。构建/部署/测试周期非常快,除非我在某个地方更改了Spring XML文件,否则我很少需要重新启动服务器。

很好的回答!你试过Jetty吗?如果你试过,你对它有什么看法? - user14070

7

我已经使用jBoss三到四年了。

jBoss的优点:

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

jBoss的缺点:

  1. 没有通用的Java EE 5容器发布并获得支持。
  2. 文档很多但冗长,可能难以找到“如何做x”的答案。
  3. 与其他商业产品相比,4.x的管理工具较差。

没有通用访问支持的JEE 5容器版本发布。我猜现在情况已经不是这样了,对吗? - Raedwald
@Raedwald:是的,现在JEE 6已经存在一段时间了;-) - ymajoros

4

3
另外一个这里没有讨论到的问题是性能。如果这是因为服务类型或用户数量的原因而引起的关注,那么以下内容将适用:
- Tomcat似乎比Glassfish慢 - Glassfish似乎比Resin慢 - Resin比G-WAN + Java慢得多
请注意,G-WAN仅依赖于JVM:它不使用任何其他容器(除非明确指定),因此您可以将其保留给Web应用程序中性能关键部分。
由于G-WAN支持其他语言(C、C ++、C#、D、Objective-C),因此您甚至可以在保留Java用于其他任务的同时,在原始C中处理应用程序的某些部分。

2

我仍然认为WebLogic是市场上最好的Java EE应用服务器。如果您可以负担得起那些许可证费用,那么我认为这是值得的。

我很惊讶地发现,通过组合Tomcat、OpenEJB和ActiveMQ,您能够实现很长的路程。这对我来说似乎是一种低成本的替代方案。

我也会考虑使用Spring dm Server。它基于Tomcat,但我认为他们添加的OSGi部分可能会很快普及。如果像Spring框架一样具有相同的质量,那么它将非常出色。


2
我对WebLogic的问题在于供应商锁定,当你真的不需要时,这是一个令人不愉快的事实! - Manius
1
这适用于我所知道的所有Java EE供应商,不仅仅是WebLogic。如果您使用任何特定于供应商的功能,则会被锁定。总得写些代码。 - duffymo
3
WebLogic只是商业产品,这就是我的意思——一旦你支付了巨额款项,你会比使用开源替代品时更加“锁定”。显然,如果你关心平台独立性,你不会使用供应商特定的功能,所以这不是我所指的。实际上,我曾经读过一份调查报告,其中开发人员认为,避免供应商锁定是开源的最大优势(而不是成本)。 - Manius
完全胡说八道?你相信与供应商签订一份数百万美元的合同不会束缚你吗?这就是证明。 - duffymo
我反驳Perce的评论,即从供应商的角度来看,供应商锁定是不可取的。我认为他们肯定希望将您锁定在使用他们的应用服务器上,而不使用其他任何东西。合同通常以这样的方式措辞,即无论您是否使用应用服务器,都要支付费用,因此客户很少有动力允许开发人员出于任何其他原因更改应用服务器。我认为声称这是一个虚构的、无意义的想法是天真的。 - duffymo
显示剩余2条评论

2
我可能会将您的首选操作系统作为决策标准。如果您使用相同供应商的操作系统和应用程序服务器,这应该会使支持更容易。如果您已经与一个或两个供应商建立了关系,请考虑他们是否易于处理。
从技术角度来看,我会选择GlassFish,因为它支持更多最新的创新。我认为JBoss在任何方面都不差,只是没有那么更新。
我的大多数经验都是在WebLogic上,但我也使用过JBoss和GlassFish。我刚刚在完整的Sun开源堆栈(OpenSolaris、GlassFish、MySQL)上发布了一个新站点,这是一次很棒的体验,只有一些小的挫折。

操作系统并不是一个问题,除非您有非常特定的二进制依赖项(这对大多数Java项目来说不应该是问题)。我们在Windows上开发,32位和64位,并在Solaris上的Glassfish上部署。大多数开发人员并不真正了解也不必关心。用户看不到它(我们大部分的开发都是Web应用程序)。 - ymajoros

1

如果你不想学习使用工具,就不要使用任何工具。或者尝试成为一个熟练的专业人士并投资于你的环境,你会得到回报。必须承认我在某些项目中做到了这一点。同样的项目从没有应用服务器,到Spring自定义客户端-服务器,再到纯Java EE和Glassfish。永远不想回去,第一个解决方案实际上太复杂了,今天它非常简单(而且标准化,可以在任何Java EE应用服务器上部署而不需要太多更改)。 - ymajoros
好的答案,获取文档的方法不可取。 - msangel

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接