logo标签列表

Java EE -- 是虚浮还是真实的东西？

jakarta-eeframeworkslampjava-ee-5
12

我熟悉LAMP技术栈，多年来成功部署了几个基于此的网站。我使用了从Apache + modPerl到PHP再到Ruby和Rails的所有工具。通过很好地使用缓存，我的Rails站点可以承受相当大的负载，但我不是指巨大的负载。

我从未真正喜欢Java作为一种语言，也不喜欢XML，而且一直非常忽略Java EE这一领域。对于那些在两个世界中有真实和直接经验的人：Java EE有什么超级酷的东西我错过了吗，还是只有一堆热气？什么证明了专有应用服务器高昂的价格？

我这里并不是在钓鱼：我正在寻找关于Java EE真正擅长而现代LAMP框架缺失的具体例子（现代= Rails，Django等）。或者如果存在这样的差异，也可以列出LAMP真正做得更好的事情（例如，较少的XML编写）。

+++++ 2028年3月19日更新

很遗憾，这里的大多数回复都没有帮助，只分为两类：“它可以扩展，因为这里有三个大型网站的示例”和“它可以扩展，因为它实际上比LAMP技术栈更好”。

我做了很多阅读并得出结论：Java EE只有一个真正好的技巧：事务（感谢威尔），至于其余的，您可以在自己的能力和努力中取得成功或失败，环境本身没有内在特质促使您创建可扩展和可靠的网站。实际上，Java EE还有一些陷阱，让您很容易失败（例如，很容易开始使用会话Bean，而不意识到您现在正在支付大量的JMS流量，也许可以通过不同的设计避免这种情况）。

相关讨论

  • http://highscalability.com/
    • ：高可扩展性技术的资讯站点。
  • http://www.oreillynet.com/onlamp/blog/2004/07/php_scales.html
    • ：关于PHP可扩展性的文章，介绍了如何使用PHP构建可扩展应用程序。
  • http://www.schlossnagle.org/~george/blog/index.php?/archives/29-Why-PHP-Scales-A-Cranky,-Snarky-Answer.html
    • ：一篇有趣的关于为什么PHP可扩展的文章，作者以幽默的方式阐述了他对这个问题的看法。
  • http://blogs.law.harvard.edu/philg/2003/09/20/
    • ：一篇有关可扩展性的博客文章，讨论了如何设计可扩展的系统并提供了一些有用的提示和建议。
    1
    至于其余部分，你可以凭借自己的能力成功或失败，环境本身并没有什么固有的因素可以促使你创建可扩展和可靠的网站。是的，但这通常是正确的 - 技术栈并不重要，程序员才是最重要的。 - Jeff Atwood
    9个回答
    18
    Java EE相比于LAMP（Linux + Apache + MySQL + PHP）堆栈的主要区别可以归结为一个单词，即“事务”。
    大多数较小的系统仅依赖于数据库提供的事务系统，对于许多应用程序来说，这是（显然）相当令人满意的。
    但是，每个Java EE服务器都包括一个分布式事务管理器。这使您可以在不同的系统之间进行更复杂的操作，安全可靠。
    最简单的例子是从数据库中取出一条记录，将其放入消息队列（JMS），然后从数据库中删除该行。这种简单情况涉及两个单独的系统，并且不能在事务之外可靠地完成。例如，您可以将行放入消息队列中，但（由于系统故障）无法从数据库中删除该行。您可以看到，在JMS提供程序和数据库之间具有事务以及单独的事务时，这并不能真正解决问题，因为这些事务没有链接在一起。
    显然，这种简单情况可以通过解决等方式来处理。但是，使用Java EE的好处在于，您不必处理这些问题-容器需要处理它们。
    而且，不是每个问题都需要这种级别的事务处理。但是对于那些需要的问题来说，它是非常宝贵的。一旦您习惯使用它们，您会发现Java EE服务器的事务管理是一项巨大的资产。
    10
    大型Java EE Web服务器（Jboss、WebSphere、WebLogic等）和Windows Server/IIS/ASP.NET在可扩展性和性能方面与通常的LAMP堆栈完全不同。
    我们的团队负责管理美国最大的电信商务网站之一，每天处理数百万次点击（我们的某个数据库大小超过1000TB，以便让您了解情况）。
    我们使用ASP.NET、WebSphere以及SAP ISA（也是Java EE解决方案）来处理我们网站的不同部分，没有任何方法可以在不将硬件扩展到大量的硬件的情况下使用LAMP堆栈处理这种类型的负载... .NET堆栈部分处理了大部分负载，并且仅在32台服务器上运行。
    我们也没有使用任何花哨的东西，例如使用memcached类型的解决方案或静态HTTP缓存...我们在单个应用程序服务器上缓存SOAP调用和数据库调用，但没有使用内存数据库等...我们的平台目前可以承受它。
    所以，比较这种东西和LAMP是不切实际的。
    1
    我认为你提出了一些很有道理的观点。LAMP技术栈之所以在互联网初创公司中非常流行，仅仅是因为它几乎不花费任何成本，并且吸引了极客心态的人，而这些人往往是这些初创公司的创始人。 - Craig
    4
    亚马逊、ebay和谷歌都使用Java EE的一个子集，它们非常成功。它们都使用servlet和JSP。
    如果您尝试使用EJB 1.1或EJB 2.0，则可扩展性会受到影响。由于使单元测试更加困难，因此开发人员的生产率也会降低。
    使用EJB 3.0可以提高开发人员的生产力和应用程序的可扩展性。
    因此，根据您的应用程序需求，只使用对您有意义的Java EE部件。使用您打算使用的那些部分进行样本POC（概念验证）。这个POC将展示应用程序的工作效果如何。
    新的Java EE应用服务器并不总是需要大量的XML。它们将允许您使用注释来进行依赖注入和数据库映射。
    超过50％的企业开发都在Java EE上进行（当我说这个时候，它主要使用Java EE堆栈的子集。有人可能使用无状态SESSION bean EJB，有人可能只使用JNDI，有人可能使用MESSAGE DRIVEN BEAN EJB）。
    希望这有所帮助。
    好的内容，但还要记住原始的亚马逊商店是用Lisp编写的，而且有很多大型网站是非Java J2EE的，所以仅列举成功实例并不能证明J2EE是独特地更好，只是它也很好。帖子的其余部分提供了有用的信息，谢谢。 - Jeff
    @Jeff - 你确定你不是在想Paul Graham卖给亚马逊的那家公司吗？那个网站是用Lisp编写的，它允许小企业创建自己的在线商店。我不认为亚马逊本身曾经用Lisp编写过。 - Dónal
    4

    Java EE可以构建非常大型和可扩展的应用程序，在企业计算中被广泛使用。

    但是:

    我的Java EE经验非常糟糕，因为似乎我们团队90%的工作都是样板代码和管道。如果我们使用了不同的技术栈，我们当时的生产力肯定比现在高得多。

    4
    几乎所有的答案都提到了构建Java EE web应用程序所需的内容。让我提到另一个重要考虑因素。大多数企业都有重要的后台需求，其中企业应用程序必须与其他应用程序集成。这可以从连接到一些老旧的COBOL大型机程序，到LAMP堆栈，再到一些会计师在晚上编写的小Access应用程序等范围内。通常这意味着您需要某种消息传递解决方案才能使2个或更多应用程序连接在一起。根据我的经验，我发现Java EE世界在处理这些集成问题时比您典型的LAMP堆栈更进一步。
    2
    Java EE的核心只是一堆接口，由容器提供实现。大多数应用程序并不使用所有Java EE规范。
    当人们讨论Java EE时，有两个主要方面：EJB和Servlets。
    我对EJB完全没有经验。我使用Spring Framework，因此它提供了所有“管道和样板”代码，就像Ben Collins回答中提到的那样。它提供了我们需要EJB完成的所有工作，甚至更多（我们使用其特殊功能进行数据库访问事务，尽管我们也将其IOC容器用于Servlet部分）。
    然而，Servlets非常棒。它们是一种非常好的、经过验证的技术。
    Servlet的核心是请求和响应循环：用户请求某些内容，服务器拦截请求并根据其提供响应。通过Session可以跟踪单个用户的一系列请求和响应。
    关于专有应用服务器的高价，我不知道为什么价格会这么高，但Apache Tomcat是一个非常好的Servlet容器，而且是免费的。我们使用Tomcat进行测试，使用Websphere进行部署（Websphere由我们的客户提供供应用程序使用）。不幸的是，它只支持Websphere 6（更新11，我们很失望地发现它没有更新13的修复程序，这使得JSTL函数在JSP标记内部无法正常运行），因此我们被迫使用Java 1.4x，而不是Java 1.5+。
    此外，还有几个框架（例如前面提到的Spring框架），可以轻松地进行Servlet开发。如果你只是用于HTTP/HTML，有许多框架可以方便地帮助你进行开发。
    1

    除了可扩展性和其他事项之外，这里有一件未提及但可能是优势的简单事情：它是Java。

    • Java拥有惊人数量的第三方库，包括专有和开源库。我相信Perl、Ruby、PHP等也有大量免费库，但当涉及到更为专业的应用领域的商业库时，它们无法与Java（以及.NET，可能还有C++）相提并论。当然，你是否需要任何特殊的第三方库完全取决于你正在构建何种类型的应用程序。
    • 我认为世界上使用Java的开发人员比任何其他平台的开发人员都要多。（也许我错了，但有时这就是我听到的。）

    在商业环境中选择平台时，“可能”会变得重要。

    我想补充一下，在Java中，一旦应用程序启动，它就会留在内存中准备运行。而PHP必须在每个请求上进行编译。（虽然这可能已经改变了，但据我所知，这是真的） - Patrick W. McMahon
    1

    就可扩展性而言，Java EE 提供了许多选择，这是 LAMP 或 RUBY 所没有的。所有的选择都围绕着 N 层应用程序，而大多数 LAMP 和 Ruby 应用程序只有 2 层。

    我正在开发一个应用程序，并计划允许人们通过网络访问 API。Java EE 将使我能够轻松地扩展中间层，而不影响 UI 层。随着我向应用程序添加接口，我可以非常容易地扩展中间层。LAMP 堆栈没有内置此概念。

    所以我有两个接口，Web UI 和 SOAP API。现在我想要一个 REST API。好吧...构建该接口以连接到中间层..并将更多计算机添加到集群..或者进行多集群，这并不重要。这个中间层全部是 EJB，它在许多方面比 SOAP 更快速。

    现在假设我想要添加通过短信向我的用户发送文本的能力。 我还需要基于他们设置的内容进行操作，这来自于数据库。 就可扩展性而言，我想要断开实际发送短信与应用程序想要发送短信的实现之间的联系。 这就呼喊着要使用 JMS。 我可以使用 Timer Bean 每隔一定时间触发，找出需要发送的消息，并将每个消息放入 JMS 中。 现在我可以管理队列以及有多少处理器正在处理等。 我可以看到有多少条短信正在发出。 我甚至可以将接收器放在另一台服务器上，对其他服务器的性能几乎没有影响。
    就扩展性而言，我可以看到我的 EJB 中被访问最多的是哪些，然后为它们添加更多资源，同时从其他位置移除资源。 我可以通过 JMS 队列以及 Java EE 技术栈的每个部分来实现这一点。 不仅可以获得可扩展性，还可以管理服务器资源。

    由于LAMP和Ruby尚未拥有像JMS一样的异步处理队列，或者轻松将业务逻辑放在单独的层中，因此它们在具有多个接口的情况下可能更难扩展。如果要将逻辑剥离并使其可用于不同的接口，该怎么办呢？假设现在您不仅提供Web UI，还提供桌面UI、IVR接口和SOAP接口，那该怎么办呢？

    1

    Java EE 和其他编程语言必须像任何其他工具一样被对待。是的，在企业环境中使用它需要精湛的技艺才能让这些工具“完美”地运行，并且需要知道何时使用它。我目前正在一个主机环境中工作，Java EE 在某种程度上被使用。如果涉及高速交易，则 Java EE 将是我的最后选择。如果需要多平台互操作性，则Java EE、XML 和 Web 服务将更为合适。

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