EJB2移植到EJB3的一些实践

众所周知EJB被人病诟的很大的一个缺陷就是它复杂的配置，和奇异的编程模型。所以EJB3的推出减小了这些毛病， 但是Rod Johnson似乎还是不满意:)

 

关于2个标准的对比已经有很多文章和书籍了，我这里不再赘述。我只想说的是自己经历到的移植的经验，希望和大家分享。主要是session bean的移植。

• 首先是开发EJB配置的模式

由于EJB3把配置由descriptor移到了java annotation,所以原来依靠更改descriptor文件来改变配置的方式必须变为改动java代码。

你的transaction, security, 以及ejb的reference都写到了annotation。不幸的是有时候legacy代码是不能动的,这就是问题。

有些场合比较核心的EJB的逻辑相对稳定，但是他的reference，它的一些属性可能会被设计成descriptor可配置。从这点来说以修改java代码来配置还没有传统的descriptor来的好。一般来说你的application会比较固定的在一种application server 上面部署，这样descriptor文件也只要维护一套。如果有的时候这个application不得不部署到2种server，annotation会是比较好的方式。我看到过要维护2套descriptor的烦人的配置和风险。EJB3同时支持2种配置。

 

• 由于技术之外的因素，新的EJB3不得不和老的EJB2兼容(compatibility )，这导致了相对复杂的情况。

据说EJB3是'homeless'的，一开始听到这个消息开心了一阵，但是要知道让老的EJB2来reference EJB3, EJB3仍旧需要丑陋的home! 所以从这个角度来说EJB3的好处被弱化了。虽然它不需要descriptor但是还是需要home。你不得不在EJB3上面加上：

     @LocalHome (MyEJBLocalHome.class)  

反过来，新作的EJB3有时要reference EJB2。由于设计的因素，你不得不继承现有的代码，而这些代码可能在基类就reference 其他的EJB，这样一来你就没法使用很cool的DI机制。

 

EJB3的设计者也知道世界上还运行着很多老EJB，所以兼容性是必须考虑的。上面所列的问题不是新EJB规范的问题:从EJB2的观点来看home当然是必要的，并且JNDI的name space也是需要定义的。这些都是application本身的问题。