12

我熟悉 LAMP 堆栈，多年来已成功部署了一些基于它的 Web 站点。我使用过从 Apache + modPerl 到 PHP，再到 Ruby 和 Rails 的所有东西。通过充分利用缓存，我的 Rails 站点可以维持相当不错的负载，但我说的不是大量。

我从来没有真正喜欢 Java 作为一门语言，或者 XML，并且一直非常忽略 Java EE 的整个方面。对于那些在这两个世界中都有过真实和直接经验的人：Java EE 是否有一些我想念的超酷的东西，或者只是一堆热空气？是什么证明了专有应用服务器的高价？

我不是在这里拖钓：我正在寻找现代LAMP 框架中缺少的 Java EE 真正指出的具体示例（如果存在此类差异）。（现代 = Rails、Django 等）。或者使用 LAMP 确实做得更好的那些东西（更少的 XML 仰卧起坐）。

+++++ 2008 年 10 月 16 日更新

我很遗憾地报告，这里的大多数回复都没有帮助，只是属于以下两类之一：“它可以扩展，因为这里是大型网站的三个示例”和“它可以扩展，因为它实际上比LAMP 堆栈”。

我读了很多书，得出的结论是 Java EE 只有一个非常好的技巧：事务（感谢 Will），至于其余的你可以根据自己的优点成功或失败，环境中本质上没有任何东西为了让您创建一个可扩展且可靠的网站，Java EE 确实有很多陷阱，使其很容易失败（例如，很容易开始使用会话 bean 而没有意识到您现在为相当多的 JMS 付出了代价通过不同的设计可能可以避免的流量。）

有用的讨论

4

9 回答 9

18

Java EE 在 LAMP 堆栈上提供的关键区别可以归结为一个词。交易。

大多数较小的系统仅依赖于数据库提供的事务系统，并且对于许多应用程序来说（显然）相当令人满意。

但是每个 Java EE 服务器都包含一个分布式事务管理器。这使您可以安全可靠地跨不同系统执行更复杂的事情。

最简单的示例是从数据库中获取记录，将其放入消息队列 (JMS)，然后从数据库中删除该行的简单场景。这个简单的案例涉及两个独立的系统，并且不能可靠地在事务之外完成。例如，您可以将行放到消息队列中，但（由于系统故障）不能从数据库中删除该行。您可以看到与 JMS 提供者的事务和与数据库的单独事务并不能真正解决问题，因为这些事务没有链接在一起。

显然，这个简单的场景可以解决、处理等等。不过，Java EE 的好处是您不必处理这些问题——容器可以处理它们。

而且，不是每个问题都需要这种级别的事务处理。但对于那些这样做的人来说，这是无价的。一旦您习惯了使用它们，您就会发现 Java EE 服务器的事务管理是一项巨大的资产。

于 2008-10-04T03:35:37.270 回答
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 进行比较是苹果与橙子的对比。

于 2008-10-04T03:13:49.153 回答
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 堆栈的子集。有人可能使用无状态会话 bean EJB，有人可能只是 JNDI，有人可能使用 MESSAGE DRIVEN BEAN EJB） .

希望能帮助到你。

于 2008-10-04T03:05:36.643 回答
4

您可以使用 Java EE 构建真正庞大且可扩展的应用程序，它广泛用于企业计算。

但：

我对 Java EE 的体验非常糟糕，因为我的团队所做的工作似乎 90% 都是样板和管道。我们当时的生产力远远低于我们使用不同技术堆栈时的生产力。

于 2008-10-04T03:08:56.963 回答
4

几乎所有的答案都提到了构建 Java EE Web应用程序需要什么。让我提及另一个重要的考虑因素。大多数企业都有重要的后台要求，企业应用程序必须与其他应用程序集成。这可以从连接到一些笨拙的旧 COBOL 大型机程序，到 LAMP 堆栈，再到某个会计师在晚上启动的小型 Access 应用程序等。通常这意味着您需要某种消息传递解决方案才能获得 2 或更多应用程序连接在一起。根据我的经验，我发现 Java EE 世界在处理这些集成问题方面比典型的 LAMP 堆栈更进一步。

于 2008-10-04T03:48:55.463 回答
2

Java EE 的核心只是一堆接口，它们具有由容器提供的实现。大多数应用程序并不使用所有的 Java EE 规范。

人们在讨论 Java EE 时会想到两个主要方面：EJB 和 Servlet。

我对 EJB 没有任何经验。我使用Spring Framework，因此它提供了 Ben Collins 的回答中引用的所有“管道和样板”代码。它提供了我们需要 EJB 做的所有事情，然后是一些（具有数据库访问权限的事务是我们使用它的特殊功能的地方，尽管我们也将它的 IOC 容器用于 Servlet 部分）。

然而，Servlet 非常棒。它们是一种非常好的和经过验证的技术。

Servlet 的核心是一个请求和响应循环：用户请求某事，服务器截取该请求并基于该请求提供响应。可以通过单个用户的会话来跟踪请求和响应链。

至于专有应用服务器的高昂价格，我不知道为什么价格如此之高，但 Apache Tomcat 是一个非常好的 Servlet 容器，而且是免费的。我们使用 Tomcat 进行测试，使用 WebSphere 进行部署（Websphere 由我们的客户端提供给应用程序使用）。不幸的是，它只是 Websphere 6（更新 11，正如我们失望地发现的那样，它没有修复更新 13，它使 JSTL 函数在包含在 JSP 标记中时能够正常运行），所以我们被迫使用 Java 1.4 倍，而不是 Java 1.5+。

还有几个框架（参见前面引用的 Spring 框架作为示例）可以轻松进行 Servlet 开发。如果您只是将它用于 HTTP/HTML，那么有大量框架可以轻松帮助您进行此开发。

于 2008-10-04T03:20:18.860 回答
1

必须像对待任何其他工具一样对待 Java EE 和其他程序语言。是的，它已在企业环境中使用，并且需要良好的工艺才能让这些工具“完美”地工作并知道何时使用它。我目前正在研究大型机环境，并且在某种程度上使用了 Java EE。如果涉及到高速事务，Java EE 将是我最后的选择。如果需要多平台互操作性，那么 Java EE、XML 和 Web 服务会更合适。

于 2008-10-04T03:56:37.350 回答
1

在可伸缩性方面，Java EE 为您提供了 LAMP 堆栈或 RUBY 所没有的大量选择。所有的选择都围绕着 N 层应用程序，而大多数 LAMP 和 ruby​​ 应用程序都是 2 层的。

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

所以我必须使用接口、Web UI 和 SOAP API。现在我想要一个休息 API。好的......构建该接口以达到中间层......并将更多计算机添加到集群......或者去多集群并不重要。这个中间层全是 EJB，在许多方面比 SOAP 更快的协议。

现在假设我想为我的用户添加短信功能。我还需要根据他们设置的内容来执行此操作，并且来自数据库。可扩展性方面，我想将文本的实际发送与应用程序想要发送的实现断开连接。这让 JMS 尖叫。我可以使用 Timer Bean 每隔 X 时间关闭一次，找出需要发送的消息，并将每条消息放入 JMS。现在我可以管理队列以及有多少处理器正在处理它等等。我可以看到有多少文本正在输出。我什至可以将接收器放在另一个盒子上，这对我的其他服务器性能几乎没有影响。

明智地扩展，我可以看到我的哪些 EJB 受到的影响最大，并为这些 EJB 添加更多资源，同时从其他 EJB 中删除资源。我可以使用 JMS 队列以及 Java EE 技术堆栈的所有其他部分来做到这一点。我不仅获得了可扩展性，还获得了对服务器资源的管理。

由于 LAMP 和 Ruby 还没有类似 JMS 的异步处理队列，或者能够轻松地将业务逻辑放在单独的层中，因此它们可能更难以使用多个接口进行扩展。您需要做什么来删除逻辑，并使其可用于不同的界面？假设您现在不仅为您的网站提供了 Web UI，还提供了桌面 UI、IVR 接口和 SOAP 接口？

于 2008-12-16T22:56:38.253 回答
1

撇开可伸缩性和其他问题不谈，这里有一个没有提到的简单的事情，这可能是一个优势：它是 Java。

  • There's a staggering amount of 3rd party libraries available for Java, both proprietary and open-source. Now, I'm sure there are huge free libraries for Perl, Ruby, PHP, etc. - but when it comes to commercial libraries for more niche application areas, they don't come close to Java (and .NET, and probably C++). Whether you need any special 3rd party libraries of course depends solely on what kind of application you are building.
  • I think there are more Java developers in the world than developers for any other platform. (Maybe I'm wrong but this is what I've heard sometimes.)

When choosing a platform in a commercial setting, either might turn out important.

于 2009-02-06T06:57:21.980 回答