我们目前正在为大学开展一个项目,我们希望将其实现为逻辑模块和 UI 模块。我们几乎没有部署 Web 应用程序的经验,但我们提出了以下替代方案:
- 将其部署为单个 WAR 项目(这将解决我们在 UI 与应用程序后端通信方面遇到的问题)。
- 在同一台服务器上部署两个 WAR 项目,使用网络服务在项目之间进行通信。 (我们有一个使用这种方法的原型(prototype)部署在 Tomcat 服务器上)
- 部署 WAR 项目和 EJB 项目。
- 部署一个包含对 WAR 和 EJB 项目的引用的 EAR 项目。 (我们有一个使用这种方法的原型(prototype)部署在 Glassfish 服务器上)
我们想知道这些备选方案中是否有任何一个是不正确的,或者是否有任何备选方案比另一个更好。具体来说,为什么将项目部署为 EAR 模块有用(或无用)?
项目现在正在启动,所以我们现在只会处理几百个用户。但是,如果项目成功,我们将需要处理几百万用户。
最佳答案
虽然 Tomcat 是一个 servlet 容器,但没有一个替代方案是不正确的,如果你想要 EJB,你需要类似 TomEE 的东西这是 Tomcat 扩展到完整的 EE 支持。或者使用那个 Glassfish。
什么是最好的取决于您的具体要求:您是更需要/重视模块的解耦,还是更愿意拥有将事物捆绑在一起的一致性和可靠性。 EJB 还具有一些您可能感兴趣的额外好处,但它们并非与每个项目都相关。请注意,除了提到的备选方案之外,还有其他备选方案,例如基于 JMS 的通信、HTTP REST 通信和使用 OSGi 来解耦包。
关于将项目部署为 EAR 模块的原因,引用维基百科:“EAR(企业存档)是 Java EE 使用的一种文件格式,用于将一个或多个模块打包到一个存档中,以便部署应用服务器上的各种模块同时且连贯地发生。它还包含称为部署描述符的 XML 文件,描述如何部署模块。所以基本上你得到了耦合的好处,归结为可靠性,你总是知道你的模块是如何相互对比部署的。 EAR 模块很好地支持 EE 机制,例如 EJB 模块,并且您可以获得一个可控的容器。
已经存在一个线程When is it appropriate to use an EAR and when should your apps be in WARs? ,这可能很有趣。
关于java - 部署 Java 应用程序 (Tomcat/Glassfish),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15042973/