Posted on 2005-12-07 15:54
笨笨 阅读(2718)
评论(2) 编辑 收藏 所属分类:
Java
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。