在JavaEE 6 WAR vs EAR中打包EJB

Question

启动一个新项目，并想了解在WAR与EAR中打包EJB的优缺点。

当EJB在WAR中时，JNDI仍然可以工作吗？效率？等？

感谢。

Answer 1

在单独的JAR中使用EJB bean的一个重要动机是业务逻辑和视图逻辑的分离。

由于EJB应该只关注业务逻辑，因此将它们放入一个单独的模块是有意义的。

这正是传统Java Enterprise Archive的便利之处。 EJB bean进入代表EJB module的JAR文件，而与Web相关的工件（Facelets，支持bean，实用程序代码）进入代表Web module的Web存档（WAR）文件。请注意，WAR实际上不必是文件。在所谓的爆炸格式中，它们仅仅是目录。

这种分离的一个关键方面是这两个模块通过类加载器层次结构隔离。 Web module可以访问EJB module中的资源（通常是bean），EJB module可以引用整个EAR伞中定义的资源（通常是库）。另一个方向是不可能的。具体而言，EJB module无法访问Web module中定义的任何资源。

这种强制执行是故意的。

业务逻辑应完全独立于任何视图技术。实施这种隔离可以防止开发人员意外地或在压力下混合这些问题。这种分离的好处是，业务逻辑可以简单地被Java SE客户端，Web模块客户端，JAX-RS客户端等使用。如果业务逻辑意外地具有JSF或Servlet依赖性，那么使用它将非常困难。来自Java SE客户。

将此与不允许使用scriptlet的Facelets进行比较。这样可以保持Facelets的清洁，让它们专注于组件布局和标记。另一个类比是编码到接口，它将合同与实现分开。

因此，拥有单独的EJB模块实际上是最佳实践。然而...

对于较小的项目，可能没有必要进行这种分离，对于初学程序员而言，可能很难围绕需要去哪里的结构。因此，删除强制分离使得没有经验的开发人员更容易从Java EE开始。它给了他们一个温和的Java EE介绍，稍后他们得到分层的想法，然后他们可以选择引入EJB module。

Answer 2

到目前为止，这就是我所得到的。

WAR中的EJB

专业人士：

1. 更易于开发和部署

2. 您可以使用@Path注释将Session Bean方法公开为REST服务。请参阅here

缺点：

1. 不支持JNDI查找，因此我认为您无法从其他应用程序客户端执行RMI

2. 正如arjan所指出的那样，它在设计上缺乏模块性。

Answer 3

我认为您需要记住的是，WAR内部的EJB是EJB Lite的一部分，这是一个很好的工作，可以使用EJB容器提供的最少服务来运行应用程序。因为您并不总是需要EJB容器提供的所有服务。

因此，如果您想知道在WAR或EAR中打包EJB的优缺点，那么您应该考虑一下您需要多少服务。

HTH。

Answer 4

我目前正在研究EJB 3.1认证的一些指南，并且必须测试它的每个功能。所有这些都可以在战争中使用。

与WAR包装的EJB Lite非常不同。

您可以使用可以包含在Web项目中的ejb jar来实现一些逻辑模块化。但是所有模块共享相同的环境（jndi），因此可能会发生一些名称冲突。在EAR项目中，每个模块都有自己的命名空间。

Answer 5

我做了一些关于这个主题的实验，并对结果感到惊讶。我的结论是从未在WAR中使用EJB。让我们留下EJB容器的工作，这样如果有人想要获得最佳和无错误的开发，请使用EAR。

当我使用NetBeans 7.1.3，Glassfish 3.1.2.2和JRebel在WAR中工作EJB以加快开发时，我已经意识到，如果JRebel部署在EAR包中，它只能在重新加载EJB模块中所做的更改时完美地工作。如果我制作了简单的WAR包，那么类加载器在开发阶段表现得非常奇怪，并且会导致很多随机错误。

无论如何，正常部署中的战争包在其他方面都是完美的。

同样在WAR包中，NamedQuery字符串中的更改在保存和编译后没有出现。如果我打包到EAR，开发顺利而快速。当然，这也可能是JRebel中的一个错误。