如果您今天开始了一个新的 Java EE 项目,该项目将在大约一年内完成,您会选择哪个应用程序服务器,为什么?
你的部分答案应该包括你的决定论据。以及您在使用您选择的 Java EE 服务器和市场上其他可用服务器方面的经验。这些很有趣,因为我们都对您的答案中的调查和想法有所了解。
如果您今天开始了一个新的 Java EE 项目,该项目将在大约一年内完成,您会选择哪个应用程序服务器,为什么?
你的部分答案应该包括你的决定论据。以及您在使用您选择的 Java EE 服务器和市场上其他可用服务器方面的经验。这些很有趣,因为我们都对您的答案中的调查和想法有所了解。
在过去的 10 多年里,我使用过 WebLogic、WebSphere、JBoss、GlassFish、Resin、Jetty、Tomcat 和其他一些工具。所以,如果我正在考虑一个新项目,我会先问自己几个问题。我不会再质疑的一件事是,除非我受到折磨直到我为妈妈哭泣,否则我会坚决拒绝使用 JSP。
由于某人的授权,我是否必须兼容/部署到特定产品?有没有办法忽略他们或以其他方式说服他们?如果是这样,这就是你的答案。
我必须使用 EJB 吗?真的吗?尽可能避免使用它们——它们实际上只需要非常大的企业级系统。请记住,它们只是工具,而且是大工具(谁能说“金大锤”?)。它们被严重过度使用,所以真的,真的怀疑你是否需要它们。如果您确实需要它们,那么这会删除您的几个选项,包括我最喜欢的 Jetty。
您是否必须使用任何其他主要的 J2EE 技术,如 JMS、ESB 等?如果是这样,而且您真的不能没有,那么您将再次受限于成熟的 J2EE 容器。例如,在您致力于 BPM 之前,请仔细考虑和调查,并(几乎)不惜一切代价避免使用 AquaLogic BPM —— 它非常丑陋。
如果您真的必须使用成熟的 J2EE 容器,请首先考虑开源,因为它更健壮、支持更好且更具成本效益。他们拥有更大的客户群和更开放的支持互动,因此他们倾向于更快地获得更好的修复。但是,Resin 还不成熟,相对于 GlassFish 或 JBoss,我会避免使用它——我发现它在部署和支持方面存在问题。我更喜欢 JBoss,因为它有更广泛的客户群、成熟度等。GlassFish 更难融入自动化构建/部署过程,但它的某些特定功能(如果您需要它们)可能会更好。
我是否有特殊的理由需要 Apache?然后倾向于Tomcat,也许还有一些东西。
我可以只使用 servlet 吗?然后我会使用 Jetty——它是最轻、最快、最简单、最灵活的解决方案。如果我反对能够使用 Jetty,我会质疑我对原因的所有假设。YAGNI 适用。
最好是在 Jetty 上使用 StringTemplate/WebStringTemplate:一个干净、健壮、快速、可维护的解决方案,没有许可费用、良好的声誉和支持等。这就是我现在开始的地方。
大多数应用程序/系统选择了许多花哨的 J2EE 功能,而他们真正需要的是 servlet 和 JDBC 以及一些不错的体系结构/设计。质疑为什么你认为你需要更多。
在成熟的容器中,我会避免使用 WebLogic 和 WebSphere,除非你支持一个主要的公共网站(我现在雇主的网站部署在 WebLogic 上,它每月获得 11+ 百万次点击,其他网站具有可比性)。WebLogic 真正声名鹊起的是它们相对容易的集群,但要(几乎)不惜一切代价避免其专有的供应商锁定功能。WebSphere 简直就是一场噩梦,我会不惜一切代价避免——在过去做过几个项目之后,我拒绝做涉及 WebSphere 的项目。这两种产品都不值得支付巨额的许可费用,除非您确实有特殊需求来推动使用专有功能。在作为许多财富 500 强公司的高级架构师/工程师的十年中,我还没有看到这样的需求。另一方面,
即使对于真正庞大、高流量的公共网站,专有产品仍然值得怀疑。我宁愿将每年数百万美元的许可费花在一些好的硬件上,并从少数真正优秀的顾问那里花一些宝贵的时间来解决一个简单的可扩展性解决方案。每年额外的数百万可以用来生产一些值得在那个漂亮的网站上销售的东西......
编辑:另一件要考虑的...
我最近遇到了兵马俑。我正在重新考虑一切,并希望尽快将其部署到一个重要的系统中。特别是,Terracotta 的集群比其他任何东西都好,所以我不会再推荐 WebLogic 的集群。
术语“应用程序服务器”是模棱两可的。使用 GlassFish v3,您可以从传统的 Web 容器开始,然后发展(使用 OSGi 和简单的“添加容器”功能)以添加您想要的任何内容:JPA、JAX-RS、EJB、JTA、JMS、ESB等等……但它是相同的产品、相同的管理界面等。这对您来说是否有资格作为应用服务器?-亚历克西斯(太阳)
我通常会问自己的第一个问题是“我可以用 Tomcat 做到这一点吗?”。如果答案是否定的,因为我需要 JMS 或 JTA,那么我求助于应用程序服务器。
大约 3 年前,我使用 WebLogic 8,对 WebLogic 的易用性和许可/成本模型感到满意。我们将它用于两个项目,一个是 Web 服务,另一个是门户。在这两个项目中,我们都没有遇到 WebLogic 或 WebLogic Portal 的任何问题。
在过去的两年里,我一直在使用 WebSphere。每当我与 IBM 谈判时,它的成本总是 WebLogic 同等产品的两倍,但公司政策规定必须使用 WebSphere。我发现 WebSphere 的学习曲线比 WebLogic 陡峭得多,而且我们的构建/部署/测试生命周期非常耗时,因此我们在开发环境中使用了 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 文件,否则我很少需要重新启动服务器。
我已经使用 jBoss 3-4 年了。
jBoss 的参数:
反对 jBoss 的论据:
签出 GlassFish 3.1!构建在模块化、基于 Java EE 6 的 GlassFish v3 内核之上,版本 3.1 提供集群、集中管理和高可用性。
有关详细信息,请参阅http://blogs.oracle.com/nazrul/entry/glassfish_3_1。
这里没有讨论的另一点是性能。如果这是由于服务类型或用户数量而引起的问题,则以下内容将适用:
请注意,G-WAN 仅依赖于 JVM:它不使用任何其他容器(除非明确指定),因此您可以将其保留给 Web 应用程序的性能关键部分。
由于 G-WAN 支持其他语言(C、C++、C#、D、Objective-C),您甚至可以使用原始 C 语言处理应用程序的某些部分,同时保留 Java 用于其他任务。
我可能会将您首选的操作系统作为决策标准。如果您为操作系统和应用服务器使用相同的供应商,它应该更容易支持。如果您已经与一个或两个供应商建立了关系,请考虑他们是否适合处理。
从技术角度来看,我会选择 GlassFish,因为它支持最新的创新。我不认为 JBoss 不好,因为它根本不是最新的。
我的大部分经验是在 WebLogic 上,但我使用过 JBoss 和 GlassFish。我刚刚在完整的 Sun 开源堆栈(OpenSolaris、GlassFish、MySQL)上发布了一个新站点,这是一次很棒的体验,只有一点点挫折。
我仍然认为 WebLogic 是市场上最好的 Java EE 应用服务器。如果你能负担得起这些许可费,我认为这是值得的。
我很惊讶地看到结合 Tomcat、OpenEJB 和 ActiveMQ 可以走多远。在我看来,这似乎是一种低成本的选择。
我还会研究 Spring dm Server。它基于 Tomcat,但我认为他们添加的 OSGi 片段可能会在短期内无处不在。如果能做到和 Spring 框架一样的质量,确实非常好。
另一种选择:根本不使用应用服务器。
查看http://www.atomikos.com/Publications/J2eeWithoutApplicationServer。
对于 web 项目,如果必须的话,保留一个轻量级的 web 容器,并结合 Wicket 之类的东西来避免 JSP/JSF 或 struts 的复杂性。
HTH 家伙