实战角度比较EJB2和EJB3的异同

　　本文从实战角度比较EJB2和EJB3的异同，通过深入剖析揭示EJB3.0的真相，EJB3.0真是带来简化？还是一种表象上的简化？EJB3.0真的变得轻量了，还是披着羊皮的狼？

　　EJB编程模型的简化

　　首先，EJB3简化的一个主要表现是：在EJB3中，一个EJB不再象EJB2中需要两个接口一个Bean实现类，虽然我们以前使用JBuilder这样可视化开发工具自动生成了EJB2的这三个类，好像不觉得复杂，但是当EJB个数增加时，就显得累赘了。

　　简化后的EJB3的sessionBean依靠annotations元注释来定义SessionBean的类型，也就是说，EJB2中的SessionBean类型区分在EJB3继续继承，只不过书写代码的方式不同而已，例如下代码使用@Stateless表示一个无状态Bean.

package example;

@Stateless
public class TestSessionBean implements TestSessionLocal{
public void xxxx(){

　　　　System.out.println("hello");　　

　　}
}

　　上述Session Bean中没有了EJB2中ejbCreate等多余方法，这样TestSessionBean很象一个普通JavaBeans了。是不是简单？先别急，我们需要接着看看这个TestSessionBean是如何调用？

　　在EJB2中，一个EJB对象的调用需要经过两个步骤：JNDI寻找和工厂创建，如下例：

Context ctx = new InitialContext();
TestSessionLocalHome home = (TestSessionLocalHome)ctx.lookup("java:comp/env/ejb/TestSession");
TestSessionLocal bean = home.create();

bean.xxxx();//真正目的 对象使用

　　其实上述代码最后一句才是我们真正目的，但是为了这个目的，必须经过前面冗长的代码创建，而在EJB3中，为创建型模式的Ioc模式（或称依赖注射）取代了home.create这样简单工厂创建模式，以一种更加松耦合和简洁的方式解决了对象创建问题，可以让我们精力更集中在对象的使用上了。

　下面是annotations+Ioc/DI的EJB3调用代码：

 @EJB //注意这里后面是空白
private TestSessionLocal testbean; //使用接口声明

public void invoke(){
　　testbean.xxxx(); //直接使用

}

　　上述EJB3调用代码中，@EJB后面是空白，这其实使用了TestSessionLocal的缺省JNDI名称，一直到这里，我们一直满足于EJB3的简化，但是如果研究@EJB语法后，会发现其完整写法如下：

@EJB(
name = “ejb/shopping-cart”,//被调用者Cart实现类的ejb-reference名称
beanName = “cart1”, //被调用者的名称 beanName
beanInterface = ShoppingCart.class, //接口名称
description = “The shopping cart for this application”
)
private Cart myCart;

　　上述完整@EJB写法适用于同一个接口有多个实现子类时，其中关键是 beanName的定义：beanName是被调用EJB的类名 （不带包名，称为unqualified name ），或者， 如果被调用EJB有 XML descriptor定义， 它就是配置项ejb-name值（如果你使用过EJB2，就容易理解这个ejb-name了）。

　　@EJB还有一个属性mappedName，这是被调用者的JNDI名称，一般不使用，因为这个JNDI名称和具体服务器有关，如果是JBoss4，那么它的缺省形式是："EAR-FILE-BASE-NAME/BEAN——CLASS-NAME/local" （or remote）。 也就是：被调用者EJB所在EAR包的名称/Bean实现子类（不带包名）/local，如果是remote调用，就是remote. 如果这个EJB被打包在jar包中，那么JNDI名称就是EJB-CLASS-NAME/local and EJB-CLASS-NAME/remote，当然，作为替换@RemoteBinding 和 @LocalBinding 也可定义JNDI名称。

　　也就是说：JBoss的EJB3中，如果你不使用XML配置，直接使用annotations，那么JNDI缺省名称没有一个统一规定名称，有的可以直接是类名；在JBoss中还和EJB打包的形式有关，是动态变化的。如果你以为在EJB3中不会接触到这个变化的JNDI缺省名称，那你就错了。

　　JBoss 4 在Servlet中不支持类似EJB调用EJB那样的依赖注射 binding-by-injection，因为Web容器和EJB容器是两个不同容器，当然借助另外JBoss Seam则是另外一回事，因此，在Web层调用EJB，就必须通过JNDI绑定一个session bean，这时，你就必须使用到那个变化不定的缺省JNDI名称了。

    JNDI Naming Context

　　无论J2EE还是Java EE中，JNDI是一个好像不起眼，但是极其重要的概念，不理解JNDI可以说，对J2EE或JavaEE只了解一半。

　　JNDI本来是EJB2中比较复杂的一个概念，不同容器有自己的JNDI名称，由此EJB2引入了第三者EJB-Reference，虽然解决了代码中耦合JNDI名称问题，但是又带来了更加烦琐的配置，这种现象当然被JavaEE5.0继续继承了下来，问题远非这么简单。

　　J在Java EE5.0中（包括EJB3和Web环境），当我们需要访问一个JNDI环境下资源时，有两种方式：除了传统EJB2中的JNDI调用方式；还有一种就是：使用依赖注射Ioc模式，这个依赖注射的表达方式是使用annotations.

　　因此，在EJB3中，必须好好搞清楚annotations、依赖注射和JNDI之间的关系，如果这个问题不弄明白，EJB3就绝非EJB2那么容易搞定，当然，搞定了的结果很简单，让人感觉简化轻量了，真不知道EJB3这种简化是不是有点象“掩耳盗铃”。

　　可以总结一句：凡是EJB2中使用配置文件定义的；EJB3一般都可以使用 annotations定义（当然EJB3也支持配置文件定义）；凡是EJB2通过JNDI寻找的资源（调用容器中其他EJB、调用环境变量等Resource资源等），都是可以依靠annotations+依赖注射机制完成。

　　JPA替代实体Bean

　　。如果说EJB3与EJB2变化最大的部分，就是持久层使用Java Persistence API 替代了EJB2的实体Bean，这样，我们通过Evans DDD建模得到的Domain Model类可以直接持久化保存到数据库，不像EJB2中还需要在Model类和实体Bean中进行一次转换。

　　EJB3引入EntityManager进行需要持久实体的查询及其新增修改；EntityManager非常类似JDBCTemp/HibernateTemplate等持久化模板。

　　JPA和JDO以及Hibernate等O/R mapping框架都是非常相似的。

　　虽然在JPA中，我们都可以使用Annotation来替代配置，实现很多过去需要专门配置文件才能实现功能，不再一定需要 每个服务器不同的cmp映射文件，增强了移植性，但是EJB3还是需要 一个叫persistence.xml配置文件，在这个配置中进行数据库JNDI配置；当然，还有一些和具体服务器有关的配置属性，如果使用JBoss，JBoss的JPA底层使用Hibernate实现，因此在persistence.xml要进行有关Hibernate属性配置：

<persistence>
　　<persistence-unit name="Ejb3Tutorial">
　　　　<jta-data-source>java:/TestDS</jta-data-source>
　　　　<properties>
　　　　　　<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
　　　　</properties>
　　</persistence-unit>
</persistence>