something about ejb

最近借ejb3 ea出台的机会review了一下ejb2.1 spec，顺手也总结一下我对ejb的认识：

Enterprise JavaBeans is an architecture for component-based computing.

ejb规范明确的指出了ejb是基于组件的结构，也就是说是component architecture的东西，那么它的基本出发点就是技术问题和业务问题的SoC，只有在这个认识的基础上我们才能来谈论ejb的轻重、ejb的复用。曾经有位在国内颇有些名声的dx跟我说：“COM和EJB都鼓吹模块化和复用，模块化是真的，复用是骗人的”，当时我就寒了，说ejb不易复用我是承认的，可如果说复用是骗人，我想估计是这位dx没有注意到ejb的component architecture吧，任何component architecture的东西都不可能脱离开容器谈复用，因为component和container之间有一种约定，哪部分归容器，哪部分归component都是事先说明的，比如transaction，如果容器支持，那么component就不会写transaction代码，而是在deploy的时候用annotation声明，反之则必须写。在ejb里，ejb container担负了很多的技术支持，比如调度、cache、transaction等，造成ejb不易复用的原因是他纯粹是业务组建想复用必须提供足够的技术context。component结构保证了的复用性是在等价的技术环境内复用component，因此ejb只可在ejb contianer间或者提供等价的技术环境内复用，ejb复用不是骗人，只是需要有个正确的认识。

Enterprise beans are components of transaction-oriented enterprise applications.

这句话是这次看的时候才注意到的，然后就如醍醐灌顶一下让我理解了ejb为什么是这个样子。对ejb的诟病里有一部分是因为对比jdo或者hibernate，entity bean不能提供完整的oo建模的能力，的确是这样，但是人家在规范里已经说了，所有ejb都是面对transaction-oritented enterprise application的，根本没有承诺要支持oo建模，为什么？因为在大型企业应用里底层数据库需要额外的调优，dba可能会针对一些多并发访问的表作调优（比如根据可能的数据需要拆表以减少并发），那么在真正的高性能企业系统里，出现完整oo模型的机会不大，甚至是没有，而ejb格外强调是面向企业应用的，因此只支持transaction-oriented enterprise application也是对的。至于轻量社区的指摘，只能是因为他们需要的系统没有这么复杂，没有这么企业，那么为enterprise量身定制的ejb显然不适用也就显得有些重。sun曾经说过对于大多数人而言用不到ejb，的确是这样的，国内尤其如此，可能90%的j2ee程序员都不会用到ejb，因为作的系统太小了，太不够enterprise了。

review ejb 2.1之后，对比ejb3，ejb3采用javaBean作为component model，持久化上支持了oo建模以及其他一些持久化的方法，ejb3从enterprise java bean变成了可具有enterprise能力的javabean，可能改叫enhanced java bean更合适。