0

我们目前正在为大学开发一个项目，我们希望将其实现为逻辑模块和 UI 模块。我们几乎没有部署 Web 应用程序的经验，但是我们提出了以下替代方案：

  1. 将其部署为单个 WAR 项目（这将解决我们在将 UI 与应用程序后端通信时遇到的问题）。
  2. 使用 Web 服务在同一服务器上部署两个 WAR 项目，以便在项目之间进行通信。（我们有一个使用这种方法的原型部署在 Tomcat 服务器上）
  3. 部署 WAR 项目和 EJB 项目。
  4. 部署一个包含对 WAR 和 EJB 项目的引用的 EAR 项目。（我们有一个使用这种方法的原型部署在 Glassfish 服务器上）

我们想知道这些替代方案中是否有任何一个不正确，或者是否有任何替代方案比另一个更好。具体来说，为什么将项目部署为 EAR 模块有用（或没有用）？

该项目现在正在启动，所以我们现在只会处理几百个用户。但是，如果项目成功，我们将需要处理数百万用户。

4

1 回答 1

1

尽管 Tomcat 是一个 servlet 容器，但没有一个替代方案是不正确的，如果您想要在那里使用 EJB，您需要像TomEE这样的东西，它是 Tomcat 扩展到完全 EE 支持的。或者使用那个 Glassfish。

什么是最好的取决于您的具体要求：您是否需要/更重视模块的解耦，或者您是否希望将事物捆绑在一起具有一致性和可靠性。EJB 还具有一些可能令人感兴趣的额外好处，但它们并不适用于每个项目。请注意，除了提到的替代方案之外，还有其他替代方案，例如基于 JMS 的通信、HTTP REST 通信以及使用 OSGi 来解耦包。

关于为什么将项目部署为 EAR 模块会很有用，引用维基百科：“EAR（Enterprise ARchive）是 Java EE 用于将一个或多个模块打包到单个存档中的一种文件格式，以便部署各种模块到应用程序服务器上同时发生且连贯。它还包含称为部署描述符的 XML 文件，用于描述如何部署模块。”。所以基本上你得到了归结为可靠性的耦合的好处，你总是知道你的模块是如何部署的。EAR 模块很好地支持 EE 机制，例如 EJB 模块，并且您获得了一个可控的容器。

已经存在一个线程什么时候适合使用 EAR 以及您的应用程序什么时候应该在 WAR 中？，这可能很有趣。

于 2013-02-23T17:03:18.727 回答