David.Turing's blog

 

[原创]从中间件厂商的角度看EJB3标准

在我Support过的许多BEA客户里面,80%依然使用EJB2,20%已经开始使用Spring,但几乎没有看到有真实的大客户在关键系统中使用 EJB3,EJB3的技术其实已经很成熟,在分布式能力上,WebLogic EJB2.0容器经过10年的改进,在分布式性能以及稳定性方面,已经相当成熟,强大的JMX支持亦为WebLogic赢得更多的商业用户。尽管EJB2 的复杂性,但BEA毕竟将这些复杂性降至最低,比如通过WebLogic的Ant Task扩展,weblogic.ejb.GenericSessionBean等等,但这一切依然没有解决无接口不OO的尴尬局面(EJB3做到了真正的POJO化,即ReviewManagerBean是implements ReviewService,POJOer舒了一口气),且IDE工具的重构也更加容易直观。
EJB3的Annotation改善了POJOer的Coding状况,却没有增加EJB容器厂家很多的工作量。各个中间件厂商依然使用他们原有的EJB CodeBase作为EJB3的基础,因此,我们完全信任EJB3的稳定性和可靠性。
在中间件厂家的角度,EJB3其实可以分为两个部分:
A1,Session Bean、MDB领域【具有分布式容器依赖性】
A2,持久层实现(JPA)【对分布式容器无依赖性】

在 A1领域,中间件厂家更关注于属于容器的范畴,即比如为笨重的EJB2容器添加DI能力,无论是Annotation还是XML描述符,都额外简单;你可能有疑问,这些DI是否会增加容器设计的复杂性吗? 显然不会。据我所知,为了支持EJB3后,WebLogic容器的重构了大量的EJB2代码,从weblogic.ejb20抽出了大量的EJB内部接口到weblogic.ejb Package去,且仅仅改写了部分的内部类,于是,我们会看到内核中包含了一些beaninfo.isEjb3的条件分支的判断。
至于MDB,WebLogic 11g之后会融合更强的Oracle JMS Provider实现,性能和可靠性绝对会让人耳目一新。

A2,很久以前,WebLogic明显花了很大的力气去实现Entity Bean,它太难用了,几乎毫无学习的必要,KODO随后被BEA收购,并派生一个OpenJPA的开源项目(输给了Oracle的TopLink Essential开源项目),Oracle收购BEA之后,可能会将TopLink重新融入到WebLogic默认实现中,之前使用KODO结合 Spring的被发现很多运行时问题(困扰了我很久,后来索性换成TopLink Essential),可以让开发者大为放心。有着10多年历史、业界领先的TopLink作为WebLogic EJB容器的一部分(JPA Provider方式),它的稳定性也是有目共睹的;另外,要提到的是,TopLink包含了Runtime监控的特性,Oracle移植TopLink 到Weblogic11g的时候亦会包含它为OC4J提供的TopLink Runtime Monitor特性,这些特性是容器依赖的,但并不是必须。

对 EJB3的客户而言,Codebase的稳定性是非常重要的,从EJB2->EJB3,WebLogic并没有改变太多的EJB核心设计,从而保证了EJB2客户迁移到EJB3所带来的可靠性;另外,持久层方面,从KODO过渡到TopLink,ORM的稳定性和性能亦会有一个不少的飞跃。总之,WebLogic 11g是值得期待的一个强大的EJB3版本。

posted on 2008-06-29 22:28 david.turing 阅读(3141) 评论(1)  编辑  收藏 所属分类: BEA新闻频道

评论

# re: [原创]从中间件厂商的角度看EJB3标准 2008-06-29 22:32 yeshucheng

太久没有看到你的安全方面的文章,呵呵。这个也不错,毕竟是经验之谈  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(110)

我参与的团队

随笔分类(126)

随笔档案(155)

文章分类(9)

文章档案(19)

相册

搜索

积分与排名

最新随笔

最新评论

阅读排行榜

评论排行榜