我正在阅读使用 GlassFish 3 开始 Java EE 6，我对打包 Java EE 应用程序的正确性感到困惑。
EJBs Lite 可以直接打包在war 或jar 文件中。如果您需要使用完整的 EJB 规范（例如，远程接口、JMS、异步调用...），您必须将其打包成 jar，而不是 war。
这是什么意思？如果我在 Glassfish 中部署一个打包为 WAR 的应用程序，它不会给我所有的 Java EE 服务吗？如果是这样，我错过了什么。
我知道 3.1 引入了一个新的配置文件 EJB Lite，它旨在成为完整规范的一个子集，针对不想实现所有内容的实现者，并且您从 3.1 可以将 EJB 打包到 WAR 中并使用指定的服务由 EJB Lite 规范。但是如果你在一个完整的规范容器中部署一个 WAR，它应该给你所有的东西，就像你创建一个 JAR 一样？WAR 不就是 JAR 的另一个名称吗？区别不能在于它是如何打包的，而在于它实际支持什么？
有人可以澄清一下。
将 EJB 逻辑 bean 放入 JAR 文件的动机来自于业务逻辑和视图逻辑之间的分离。目前，据我所知，没有必要将所有的 EJB 打包到 JAR 中，然后将这个 JAR 与 WAR 结合到 EAR 中。
但是...由于 EJB 应该只专注于业务逻辑，因此将它们打包在单独的存档中是有意义的。另一方面，WAR 是与向用户显示 GUI 相关的所有内容的存档，包括 JSP、Facelets、图像、CSS 文件和 JavaScript 库。WAR 文件可以在一个文件夹中有一组类WEB-INF\classes，以及在WEB-INF\lib. 无论如何，WAR 文件不一定是文件。WAR 文件可以成为展开的 WAR，基本上是一个与存档中的结构相同的目录。
其中一个关键方面是类加载器层次结构中的类加载器隔离。WAR 模块可以访问 EJB 归档 (JAR) 中的资源，而 EJB 模块可以引用和访问 EAR 文件本身中的资源（库）。另一个方向，特别是从 EJB 模块访问 WAR 资源，是被禁止的。设计就是这样，因为它可以防止开发人员（在压力下工作）混合这些问题并创建意大利面条式代码。业务逻辑应该与视图逻辑分开，因为它可以并且应该被 Java SE 客户端、不同的 Web 模块客户端、JAX-RS 或基于 SOA 的解决方案重用。如果业务逻辑在 JSF 或 Servlet 之间有任何依赖关系，那么在 Java SE 桌面解决方案中使用它们是不可能的。
因此，拥有一个由许多 JAR 和 WAR 文件组成的 EJB 归档结构可能不是必需的，但这是一种最佳实践，并且应该小心并注意违反该规则。