java - Spring 3.x 应用程序在 Java EE 6 容器中的可行性 - 有时？

Question

头疼的时候..!

我们的产品由带有服务器和许多客户端的软件组成。我们希望用 Java 实现替换它，以减少内部代码维护并采用更现代的技术。

服务器上的服务非常面向 SOA，队列上有大量消息，在我们看来，MDB 非常适合替换现有的 PHP 脚本。客户端上的服务生成消息供服务器发送并处理更新，并定期与服务器同步。服务器是真正的野兽，客户端通常是客户提供的 Windows XP 桌面。现在您已经有了一些背景知识。

我们喜欢 Java EE 6 的想法。我们希望能够构建服务器集群。然而，我们意识到，在某些情况下，相当多的服务器功能可以交给客户端。这意味着向客户交付大量 Java EE 位。我的思绪正在滑向 Spring 框架领域。

那么，这听起来有多可行呢？我们能否编写可以在 Spring 容器或 EE 容器内运行的应用程序？也许会以某种方式结束？

Answer 1

您可以编写符合 Spring Framework 或 Java EE 规范(EJB、Servlet、CDI 等)的应用程序。没有“我们现在就写它，然后决定我们将使用什么”。
您可以(理论上)通过应用程序服务器做出此类决定，但不能通过您将开发的代码做出此类决定。

Spring 不太依赖它所工作的应用程序服务器，因为它将所有依赖项都带入了应用程序，所以这就像将一堆 jar 上传到应用程序服务器 - 即 Tomcat (我猜这就是您所说的“Spring 容器”)。

Java EE 兼容解决方案依赖于应用程序服务器服务。您不向您的应用程序添加任何内容 - 只需部署您的代码(jar、war 或ear)并依赖应用程序服务器提供的服务 - 即 Glassfish (这就是您所指的作为“EE容器”)。

成熟的 Java EE 应用程序需要完整的 Java EE 配置文件，这意味着您无法在 Tomcat(基本上是 JSP 和 Servlet 容器 - 整个 EE 堆栈的一小部分)上运行它。

您提到您担心已发送的应用程序的大小。请记住，这是“交付”这样的环境的准时操作，目前，我个人认为 100 MB 并不是“太大”(顺便说一句 - Glassfish 的完整版本是 65 MB，而不是 100+ MB)并且它已经附带了您需要的所有服务)。

如果您担心 CPU 和内存使用情况 - 在没有测量或至少找到可靠的性能比较来源(如果存在)的情况下，我现在不敢说什么。我所知道的措施纯粹是关于少数服务器的启动时间，你可能会发现它 here .

最后 - 如果您更确信使用 Tomcat 而不是 Java EE compliant servers 之一同时，正如您所说，您“喜欢 Java EE 6 的想法”，也许比 Apache TomEE 更喜欢它。对你来说会很有趣。它基本上是一个 Tomcat，但具有 Java EE 服务。