ejb编程模型的简化

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

简化后的ejb3的sessionbean依靠annotations元注释来定义sessionbean的类型，也就是说，ejb2中的sessionbean类型区分在ejb3继续继承，只不过书写代码的方式不同而已，例如下代码使用@stateless表示一个无状态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> 

拦截器概念

ejb3.0引入了类似aop中的拦截器概念(注意，aop不只等于拦截器，所以不能认为ejb3就是完全aop了)，jboss使用jbossaop来实现拦截器功能，自己定义的拦截器方法可以拦截任何一个业务方法或生命周期事件回调;拦截方法可以在bean中定义或专门的拦截器类。

@stateless

@interceptors( { nullchecker.class, argumentschecker.class })

public class statelesssessionbean implements statelesssession {

// this business method is called after

// the above two interceptor's @aroundinvoke

// methods are invoked. hence it is guaranteed

// that the argument to this method is not null

// and it starts with a letter

public string inituppercase(string val) {

string first = val.substring(0, 1);

return first.touppercase() + val.substring(1);

}

}

nullchecker和argumentschecker是statelesssessionbean两个拦截器，在拦截器nullchecker中，必须指定的拦截方法为@aroundinvoke。

public class nullchecker {
@aroundinvoke

public object checkifnull(invocationcontext ctx)

throws exception {

method method = ctx.getmethod();

if (method.getname().equals("inituppercase")) {

string param = (string) (ctx.getparameters()[0]);

}

.........

}

// proceed to the next interceptor

return ctx.proceed();

}

}

总结

总之，从上面ejb2和ejb3的总结上看，ejb3.0在ejb2基础上，引入了更多概念，最大变化就是annotation替代了配置文件，对于一些配置文件厌恶者来说，是一个好事；但是在实战中，在一些依赖注射不能照顾到地方，我们还必须和更加复杂的jndi名称打交道，这恐怕是ejb3的一个不是很完美的地方。

关于ejb3中可测试性的优点被很多人津津乐道，将ejb脱离容器测试，虽然可以进行微观的单元测试，但是脱离容器就是脱离特定完整的业务场景，所以，基于容器的(也就是基于完整的业务场景)单点跟踪调试才是最重要的，这些必须依赖开发工具的发展，目前已经在eclipse3.2以后版本+wpt(或jbosside/lomboz)中实现，这个功能适合大部分j2ee/javaee程序。

所以，个人对脱离容器的测试要求并不以为然，而这个曾经是martin fowler定义pojo的主要内容，因为在过去容器概念刚刚出现时，很多人都有容器恐惧症，以为容器都是不透明的，我们的业务对象放入进去，就失去了控制，这些都是落后设计观念导致，其实，java语言本身提供的可跟踪性和介入性是非常强大，目前性能跟踪工具profiler可以在容器运行时，跟踪到容器中某个具体类占据cpu多少，占用多少内存资源，那么一个单点调试岂是一个个所谓容器可以阻挡的?容器是java语言的特点，classloader决定了java就是一个容器性的语言，关键这个容器是必须透明的。