在JavaEE 6 WAR vs EAR中打包EJB

duv*_*uvo 28 java-ee java-ee-6 ejb-3.1

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

当EJB在WAR中时,JNDI仍然可以工作吗?效率?等等.?

谢谢.

Arj*_*jms 56

将EJB bean放在单独的JAR中的一个重要动机是将业务逻辑视图逻辑分开.

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

这正是传统Java Enterprise Archive的便利之处.EJB bean进入一个表示的JAR文件EJB module,而与Web相关的工件(Facelets,支持bean,实用程序代码)进入一个表示文件的Web存档(WAR)文件Web module.请注意,WAR实际上不必是文件.在所谓的分解格式中,它们仅仅是目录.

这种分离的一个关键方面是这两个模块通过类加载器层次结构隔离.的Web module访问来自资源(典型地豆)EJB module,并且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.


duv*_*uvo 6

到目前为止,这就是我所得到的.

WAR中的EJB

优点:

  1. 更易于开发和部署

  2. 您可以使用@Path批注将Session Bean方法公开为REST服务.看到这里

缺点:

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

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


Cel*_*des 5

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

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

HTH.


vic*_*era 5

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

它与WAR打包有很大不同。

您可以使用可以包含在Web项目中的ejb jar进行一些逻辑模块化。但是所有模块共享相同的环境(jndi),因此可能发生一些名称冲突。在EAR项目中,每个模块都有其自己的名称空间。