我熟悉LAMP堆栈，多年来已成功部署了一些基于它的Web sties。我已经使用了从Apache + modPerl到PHP，Ruby和Rails的所有东西。通过充分利用缓存，我的Rails站点可以承受相当不错的负载，但我并不是说大量的。
我从来没有真正喜欢Java作为语言或XML，并且非常忽略了整个Java EE方面。对于那些在这两个领域都拥有真实和直接经验的人来说：Java EE是否有一些我非常喜欢的东西，或者只是一堆热风？什么证明了专有应用程序服务器的高价格？
我不是在这里徘徊：我正在寻找具体的例子，如果存在这样的差异，那么现代 LAMP框架中缺少Java EE真正指出的东西。 （Modern = Rails，Django等）。或者选择使用LAMP真正做得更好的东西（更少的XML坐标）。
+++++ 2008年10月16日更新
我很伤心地报告说，这里大部分的答复是没有帮助的，并简单地分为两类：“这秤是因为这里是大网站的三个例子”和“这秤，因为它是真正的实际比LAMP堆栈好得多“。
我已经做了很多阅读，并得出结论，Java EE只有一个非常好的技巧：交易（感谢Will），至于其余的你可以成功或失败的自己的优点，没有任何本质上在环境中导致您创建一个可扩展且可靠的Web站点，事实上Java EE有很多陷阱可以很容易地失败（例如，很容易开始使用会话bean而没有意识到您现在正在支付相当的费用通过不同的设计可能已经避免了一些JMS流量。）
有用的讨论
答案 0 :(得分：18)
Java EE提供的关于LAMP堆栈的关键区别可以归结为一个单词。交易。
大多数较小的系统只依赖于数据库提供的事务系统，并且对于许多（显然）非常令人满意的应用程序而言。
但每个Java EE服务器都包含一个分布式事务管理器。这使您可以安全可靠地在不同系统中执行更复杂的操作。
最简单的例子是从数据库中获取记录，将其放在消息传递队列（JMS）上，然后从数据库中删除该行的简单方案。这个简单的案例涉及两个独立的系统，并且不能在交易的一边做得可靠。例如，您可以将行放在消息队列中，但是（由于系统故障）不会从数据库中删除该行。您可以看到如何与JMS提供程序进行事务以及与数据库进行单独的事务并不能真正解决问题，因为事务未链接在一起。
显然，这个简单的场景可以解决，处理等等。但是，Java EE的优点是你不必处理这些问题 - 容器可以处理它们
而且，并非所有问题都需要此级别的事务处理。但对于那些做的人来说，这是非常宝贵的。一旦你习惯了它们，你就会发现Java EE服务器的事务管理是一个很好的资产。
答案 1 :(得分：10)
大枪Java EE Web服务器（Jboss，WebSphere，WebLogic等）和Windows Server / IIS / ASP.NET在可扩展性和性能方面与典型的灯泡堆真正不同。
我的团队负责美国最大的电信商务网站之一，每天处理数百万次点击（我们的一个数据库大小超过1000TB，为您提供一些视角）。
我们对网站的不同部分使用ASP.NET和WebSphere以及SAP ISA（也是Java EE解决方案）的组合，LAMP堆栈绝对没有办法在不扩展的情况下处理这种负载大量的硬件...... .NET堆栈部分处理大部分负载，仅在32台服务器上运行。
我们也不做任何花哨的事情，例如使用memcached类型的解决方案，或静态HTTP缓存...我们在各个应用服务器上缓存SOAP调用和数据库调用，但不使用内存数据库等...到目前为止，我们的平台可以处理它。
所以是的，将它的苹果变成橘子，将这种东西与LAMP进行比较。
答案 2 :(得分：4)
Amazon.com，ebay，google - 他们都使用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）。
希望它有所帮助。
答案 3 :(得分：4)
您可以使用Java EE构建真正庞大且可扩展的应用程序，并且它广泛用于企业计算。
可是：
我对Java EE的经历非常糟糕，因为我的团队90％的工作似乎是样板和管道。当时我们的生产力远远低于我们使用不同技术堆栈时的生产率。
答案 4 :(得分：4)
几乎所有答案都提到了构建Java EE web 应用程序所需的内容。让我提一下另一个重要的考虑大多数企业都有重要的后台需求，企业应用程序必须与其他应用程序集成。这可能包括连接到一些古老的COBOL大型机程序，LAMP堆栈到一些会计师晚上吵闹的小型Access应用程序等。通常这意味着你需要某种消息传递解决方案才能获得2或者更多应用程序连接在一起。根据我的经验，我发现Java EE世界比典型的LAMP堆栈更进一步处理这些集成问题。
答案 5 :(得分：2)
Java EE的核心只是一堆接口，它们具有容器提供的实现。大多数应用程序不使用所有Java EE规范。
人们在讨论Java EE时会有两个主要方面：EJB和Servlet。
我对EJB没有任何经验。我使用Spring Framework，因此它提供了Ben Collins回答中引用的所有“管道和样板”代码。它提供了我们需要EJB执行的所有操作，然后是一些（具有数据库访问权限的事务是我们使用其特殊功能的事务，尽管我们使用其IOC容器以及Servlet部分）。
但是，Servlets很棒。它们是一种非常好的，经过验证的技术。Servlet的核心是请求和响应周期：用户请求某些内容，服务器拦截请求并根据它提供响应。可以通过单个用户的会话跟踪一系列请求和响应。
至于专有应用程序服务器的高价格，我不知道为什么价格如此之高，但Apache Tomcat是一个非常好的Servlet容器并且是免费的。我们使用Tomcat进行测试，使用WebSphere进行部署（Websphere由我们的客户提供，供应用程序使用）。不幸的是，它只是Websphere 6（更新11，因为我们发现令人沮丧，它没有更新13的修复，它使JSTL函数在包含在JSP标记内时能够正常运行），所以我们被迫使用Java 1.4x，而不是Java 1.5 +。
还有一些框架（参见之前引用的Spring框架），可以轻松实现Servlet开发。如果你只是将它用于HTTP / HTML，那么有很多框架可以帮助你进行这种开发。
答案 6 :(得分：1)
Java EE和其他程序语言必须像任何其他工具一样对待。是的，它已被用于企业环境，并且需要良好的工艺才能使这些工具“完美”工作并知道何时使用它。我目前正在研究大型机环境，并且在某种程度上使用了Java EE。如果涉及高速事务，Java EE将是我的最后选择。如果需要多平台互操作性，那么Java EE，XML和Web服务将更合适。
答案 7 :(得分：1)
就可伸缩性而言，Java EE为您提供了LAMP堆栈或RUBY所没有的巨大选择。所有选择都围绕着N层应用程序，而大多数LAMP和ruby应用程序都是2层。
我正在开发一个应用程序，并计划允许人们通过网络访问API。 Java EE将允许我轻松扩展中间层，而不会影响UI层。当我向我的应用程序添加接口时，我可以非常轻松地扩展中间层。 LAMP堆栈没有内置的概念。
所以我必须使用接口，Web UI和SOAP API。现在我想要一个rest API。好的...构建该界面也可以点击中间层...并向群集中添加更多计算机..或者进行聚集并不重要。这个中间层都是EJB，在很多方面都是SOAP的快速协议。
现在让我们说我想添加SMS文本我的用户的功能。我还需要根据它们设置的内容执行此操作，这些内容来自数据库。可伸缩性方面，我想断开文本的实际发送，从应用程序想要发送它的实现。这尖叫着JMS。我可以使用Timer Bean每隔X个时间关闭一次，并找出需要发送的消息，并将每个消息放入JMS。现在我可以管理队列以及正在处理多少个处理器等等。我可以看到有多少文本正在运行。我甚至可以将接收器放在另一个盒子上，这对我的其他服务器性能影响很小。
按比例缩放，我可以看到我的哪些EJB受到的影响最大，并为这些资源添加更多资源，同时从其他资源中删除资源。我可以使用JMS队列以及Java EE技术堆栈的其他部分来实现这一点。我不仅获得了可扩展性，还获得了服务器资源的管理。
由于LAMP和Ruby还没有用于异步处理的JMS类队列，或者能够轻松地将业务逻辑放在单独的层中，因此使用多个接口可能难以扩展。你需要做什么来剔除逻辑，并将其提供给不同的界面？让我们说现在您不仅为您的网站提供Web UI，还提供桌面UI，IVR接口和SOAP接口？
答案 8 :(得分：1)
除了可扩展性和其他问题之外，这里有一个简单的事情没有提及，这可能是一个优势：它是Java。
在商业环境中选择平台时，可能非常重要。