在JavaEE 6 WAR和EAR中打包EJB
开始一个新项目，想了解在WAR和EAR中打包EJB的优缺点。
当EJB处于WAR中时，JNDI仍然可以工作吗？ 效率？ 等等。？
谢谢。
把EJB bean放在一个单独的JAR中的一个重要动机是将业务逻辑和查看逻辑分离开来。
因为EJB应该专注于业务逻辑，所以把它们放在一个单独的模块中是有意义的。
这正是传统的Java企业档案所促成的。 EJB bean进入代表EJB module的JAR文件，而与Web相关的构件（Facelets，后台Bean，实用程序代码）进入代表Web module的Web Archive（WAR）文件。 请注意，WAR实际上并不是一个文件。 在所谓的分解格式中，它们仅仅是目录。
这种分离的一个关键方面是这两个模块是通过类加载器层次结构隔离的 。 Web module可以从EJB module访问资源（通常是bean）， EJB module可以引用在整个EAR伞中定义的资源（通常是库）。 另一个方向是不可能的。 具体而言， EJB module无法访问Web module定义的任何资源。
这种执行是故意的。
业务逻辑应该完全独立于任何视图技术 。 无论如何，实施这种隔离措施可以防止开发者意外或者在压力下混淆这些问题。 这种分离的好处是，业务逻辑可以被其他Java SE客户端，Web模块客户端，JAX-RS客户端等使用。如果业务逻辑意外地具有JSF或Servlet依赖关系，那么使用它将是非常困难的来自Java SE客户端。
将此与Facelets进行比较，不允许使用scriptlet。 这使Facelets保持清洁，并让它们专注于组件布局和标记。 另一个比喻是编码到接口，从而将合同与执行分开。
所以拥有一个单独的EJB模块实际上是一个最佳实践 。 然而…
对于规模较小的项目，可能没有必要进行这种分离，对于初学程序员来说，可能很难将头围绕在需要去哪里的结构上。 删除强制性分离因此使没有经验的开发人员更容易从Java EE开始。 它给了他们对Java EE的简单介绍，稍后他们有了分层的想法，他们就可以select引入一个EJB module了。
到目前为止，这是我得到的。
EJB中的WAR
优点：
-
更简单的开发和部署
-
您可以使用@Path注释将会话Bean方法公开为REST服务。 看到这里
缺点：
-
不支持JNDI查找，所以我相信你不能从另一个应用程序客户端执行RMI
-
正如arjan指出的那样，它在devise上缺乏模块化。
我认为你需要记住的是，WAR内部的EJB是EJB Lite的一部分，这使得应用程序运行在EJB容器提供的最servlets上是一个不错的工作。 因为你并不总是需要EJB容器提供的所有服务。
因此，如果您想知道在WAR或EAR中打包EJB的优缺点，那么您应该考虑您需要多less服务。
HTH。
我目前正在学习一些EJB 3.1authentication指南，并且要testing它的每一个特性。 所有的战争都可以使用。
这是来自WAR包装的非常不同的EJB Lite。
你可以有一些使用ejb jar的逻辑模块化，你可以在你的web项目中join。 但所有的模块共享相同的环境（jndi），所以一些名称冲突可能发生。 在EAR项目中，每个模块都有自己的名称空间。
我在这个主题上做了一些实验，结果真的很惊讶。 我的结论是从不在WAR中使用EJB。 让我们离开EJB容器的工作，如果有人想要得到最好的和无差错的开发，那就用EAR代替。
当我在WAR中使用NetBeans 7.1.3，Glassfish 3.1.2.2和JRebel进行EJB开发时，我发现JRebel只适用于在EJB模块中重新加载更改（如果它部署在EAR包中）。 如果我做了简单的WAR包，类加载器在开发阶段performance得非常奇怪，并导致了很多随机的错误。
无论如何，在正常的部署战争包裹完美作为由别人mentiod完美。
同样在WAR包中，保存和编译后，NamedQuerystring中的更改没有变化。 如果我打包成EAR，那么发展是顺利和快速的。 当然这也可能是JRebel中的一个bug。
