With or Without EJB?

With or Without EJB?

EJB 运行时所享受的 J2EE 基础服务

1 参与AppServer 提供分布式事务管理(JTA,JTS)。
2 AppServer 提供高性能通讯框架(基于RMI 或 IIOP实现)和大并发处理。
 1) AppServer 如 WebLogic/WebSphere 替换了 Sun 标准 RMI 实现（基于著名的多线程阻塞IO），国内的 Apusic 4 则基于纯 NIO 的 IIOP通讯协议实现EJB 远程通讯。
 2) AppServer 提供 EJB 实例池、请求队列、执行线程池等等服务。

3 AppServer 提供透明 EJB 集群管理（负载均衡、故障恢复），保证应用的处理能力能够水平扩展。
4 J2EE 安全体系
5 AppServer 特有的附加增值服务
 1) 如 WebLogic WTC EJB，可实现从TUXEDO Service(C语言) 高性能访问 EJB。

 

大型项目所关注的重点

对于大型项目如全国集中这一级别而言，它所关注的重点风险反而是系统的性能、吞吐量、稳定性、高可用性这样的一些基本属性，这里并非说具体的业务功能就不重要；而是与上述的基本属性相比，业务功能可以说是相对的不重要。
基本属性如果有某一项没有达到，直接后果就是项目失败，或者运行时存在高风险。
业务功能则主要是堆时间、堆人、堆代码、堆测试人员的问题，如果实在来不及了，那就放到第二期去做好了，不影响主旋律么。

对于大型项目而言，采用新技术的关注点主要是：
1 能否满足基本质量属性，无重大运行时风险。
比如说，数据访问层，从性能和稳定性角度而言，还算直接采用 JDBC 编码合适，最多采用SQL映射型JDO。对于带缓冲的JDO实现则不宜采用，会带来水平扩展和稳定性风险。

2 项目组相关人员是否有此技术的经验，最好不要付出学习成本，避免因不熟悉所带来的风险。

 

EJB 和 IoC 框架如 Spring 的定位比较

Spring IoC/Context/AOP 可以认为是一个代码组织(Assembler)框架，关注代码如何组织和去耦。

EJB 则是运行结构，关注我们的应用如何运行，如何做集群，系统计算资源如何分配等等。
EJB 3 的改进主要还是从代码组织角度做出的，对于 EJB 运行时架构并没有多少变化（如果说错了，还请指正）；BEA 还有过将 EJB 3的代码翻译为 EJB 2.1 运行时架构的考虑（参见 BEA 的关于 EJB 3 的一篇文章http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb_p.html）。

从上述角度来看，EJB 和 Spring 是从不同的角度看待应用，我们完全可以做到用 Spring 组织代码实现EJB。

With or Without EJB?
从上述讨论可以看出，用Spring还是用EJB并不是个问题，最终还是看用户的实际需求而定。小Web项目多半不关注性能、并发、集群等等属性，出于开发过程简单和学习成本的考虑，完全可以不用EJB；而大型项目可能还是得用EJB。