在整个开发过程中，我将我的代码分成独立的项目，其中大部分都接收 JMS 提要，对每条消息进行一些处理，保留域对象，然后为其他一些项目公开服务以使用 RMI 调用。除了现在有 6 个的 web 应用程序运行（在 tomcat 上运行）之外，所有这些都作为独立 jar 运行。我想这可以从上面推断出来，但我不使用 EJB；所有项目都使用 Spring。
我使用 tomcat 的经验非常有限，几乎没有使用应用程序服务器的经验，但今天我突然想到这些应用程序可以托管在任何一个 tomcat/应用程序服务器上，我觉得这可能是其他人所做的。我听说它可以用来管理事务、jndi 查找等，它们听起来很有用。
考虑到这一点，我认为它也可能开始解决我在通过 RMI 检索域对象时的延迟加载问题。
我想知道是否有人可以指导我是否正确地认为这是要走的路？
【问题讨论】：
标签： java spring transactions rmi application-server
使用 Tomcat（在我看来它更像是一个轻量级容器）还是使用重型容器（JBoss AS、Glassfish 等）的决定主要取决于您需要做什么。
所有容器共享一些基本的东西（例如数据库池、jmx、..），但在某个点（例如，您需要一个具有所有自动故障转移的重型集群解决方案）更复杂的容器为此类要求提供了更多开箱即用的功能.当然，您也可以使用轻量级解决方案构建此类解决方案，但使用 J2EE 容器可能更容易。
另一方面，POJO 比 EJB 更容易处理，只要您没有任何大而重的要求，我会坚持使用 Spring。仅使用 J2EE 容器的一小部分并在其中构建应用程序使其不是真正的使用点。
Spring 和 J2EE 中的事务处理基本相同（这两种方式都可以通过使用例如声明性方法（注解）来完成）。
如果您从未在容器上运行您的应用程序，我会从更简单的容器（Tomcat）开始，然后在需要时使用更大的容器，因为它可能会让您的生活更轻松。只要您没有任何无法解决的特殊要求，我认为没有任何理由立即开始使用 JBoss 或 Glassfish 并重写您的应用程序以符合 J2EE。
【讨论】：
这可能有点盲人带盲，但我认为你是对的。应用服务器是包含所有小项目并绑定它们的包装——它控制它们的生命周期以及您可能不想手动处理的其他事情，例如部署、缓存和冗余。
虽然我多年来在不同的企业中为它们编写代码，但我花了一段时间才弄清楚它们所说的“容器”是什么意思，它包含少量任意独立的代码。
可能已经发布了更好的答案-只是想让您知道您并不孤单:)
【讨论】：