Spring3.x应用程序在JavaEE6容器中的可行性——有时？

头痛时间

我们有一个产品，包括一个服务器和许多客户端的软件。我们希望用Java实现来取代它，以减少内部代码维护，并在更现代的技术上取得进展

服务器上的服务非常面向SOA，队列上有大量消息，我们认为MDB非常适合取代现有的PHP脚本。客户端上的服务生成消息供服务器发送和处理更新，并定期与服务器同步。服务器是合适的工具，客户端通常是客户提供的Windows XP台式机。现在你有了一点背景知识

我们喜欢JavaEE6的想法。我们希望能够构建一个服务器集群。然而，我们意识到，在某些情况下，相当多的服务器功能可以交给客户端。这意味着向客户提供大量JavaEE位。我的思绪正滑向春天

---

那么，这听起来有多可行？我们是否可以编写应用程序，以便在Spring容器或EE容器中运行？也许需要一些包装？

您可以编写符合Spring框架或Java EE规范（EJB、servlet、CDI等）的应用程序。没有“我们现在就写，然后再决定我们将使用什么”。
您可以（理论上）使用应用程序服务器做出这样的决定，但不能使用将要开发的代码

Spring并不太依赖于它所使用的应用服务器，因为它为应用程序提供了所有的依赖关系，所以它就像是将一堆JAR上传到应用服务器中一样，即Tomcat（我想这就是您所说的“Spring容器”）

Java EE兼容解决方案依赖于应用服务器服务。您不需要向应用程序添加任何内容，只需部署代码（jar、war或ear）并依赖应用程序服务器提供的服务，即Glassfish（您称之为“EE容器”）

成熟的JavaEE应用程序需要完整的JavaEE配置文件，这意味着您不能在Tomcat上运行它（它基本上是一个JSP和Servlet容器，是整个EE堆栈的一小部分）

您已经提到，您关心已发布应用程序的大小。请记住，这是“运送”此类环境的实时操作，就目前而言，我个人而言，我不认为100 MB太大（顺便说一句，Glassfish的完整版本是65 MB，而不是100+MB，它已经提供了您所需的所有服务）

如果您关心CPU和内存的使用情况，我不敢在这一点上说任何话，除非对其进行测量，或者至少找到一个可靠的性能比较来源（如果存在的话）。我所知道的衡量标准纯粹是关于少数服务器的启动时间，你们可能会发现这一点

---

最后，如果您更确信使用Tomcat而不是其中一个，同时，正如您所说的，您“喜欢JavaEE6的想法”，而不是您可能感兴趣的想法。它基本上是一个Tomcat，但有JavaEE服务。

没有“Spring容器”这样的东西。Spring被设计为在JavaEE（即servlet）容器中工作。没有冲突。Spring提供了一个可以在客户端安装上使用的IoC容器。这与生产服务器上的应用程序服务器相比。我们可以编写不关心它在哪个服务器中运行的代码吗？“IoC容器”被设计（但不限于）嵌入到JavaEE服务器中。我不太明白为什么“向客户运送大量JavaEE位”会让你想到Spring框架。请描述您所理解的“Spring容器”和“EE容器”——您是指像“Tomcat”这样的“Spring容器”和像“Glassfish Java EE 6完整配置文件应用程序服务器”这样的“EE容器”？我真正关心的是我们的应用程序是否包括一个100MB+的应用程序服务器，如JBoss或Glassfish。我的印象是，为我们的应用程序提供Tomcat（例如）和Spring框架不仅可以大幅减少连线和磁盘的大小，而且还可能减少内存和cpu的使用，同时可能让我们构建组件，而不必考虑在哪个容器中运行。这里的共识是将客户设备需求降至最低，特别是当机器（通常）工作人员的台式机也忙于其他办公室工作时……Glassfish可能有65 MB，但它需要80 MB的JDK，其中大约20 MB似乎是JRE。JBoss不需要JDK，但附带编译器。所以我真的希望JBoss加上20MB的JRE，我们的应用程序有100MB的容量，而不是20MB的JRE加上Tomcat（或类似的）加Spring，这看起来很小，但我还没有计算所有的需求。您的客户站点上的磁盘空间有任何限制吗？或者您担心占用的磁盘空间越多，吞吐量就越慢？环境磁盘大小的差异真的是您最关心的问题吗？还有很多事情可能比安装尺寸更重要。为了完整起见，请看一看。您基本上看到的是20MB的JRE+7MB的Tomcat+27MB的just Spring Framework=54MB。我在午餐时与一位同事交谈，他经常在客户提供的设备上安装我们当前的软件（Delphi和PHP）。他说，更大的下载或文件系统占用空间并不像内存消耗那样令人担忧。我们仍然有512MB的计算机可以安装在Windows和Office上共享，显然需要更多（比如1-2GB）可能会延迟新客户的加入。很明显，机器交换并不少见。增加我们的RAM需求可能是不可避免的，但限制这种增长很重要。内存占用是更相关的因素。J