JavaBean vs EJB

   兴业实习开始的时候，项目经理要求3个星期后给他一份报告，说明JavaBean和EJB的区别。在学习了一段时间的EJB后，结合网络上的相关知识，我写了以下这篇报告，主旨是站在比较高的角度，如架构，设计的层次来看区别，因为具体而微的区别，我实在想不通，我觉得这是完全不同的2种概念，好像没啥可比性。废话不说，来看报告。
    
    从官方文档上来，JavaBean和EJB其实都只是一组规范，在这些规范下，它们的目的是一样的，那就是通过严格标准的设计，来提高开发效率以及组件的复用性。
    按照Sun的定义，JavaBean是一个组件模型，从程序实现上来看，它就是一个Java类，只是这个类被Sun的文档规定了格式，比如说有属性必须是private的，必须有个无参构造函数等等，通过这些约定，JavaBean之间就可以通过Java语言的诸如反射灯机制来发现对方的属性，并对这些属性进行操作。JavaBean支持完整的面向对象建模，其不包含除Get和Set方法外的其它方法的特例POJO就可以表示一个纯的数据对象，其作用在轻量级开发中往往用于ORM中的VO和PO，也往往在MVC模式的实现中的充当模型角色。
    相比较起来，EJB就复杂庞大了很多，它的标准定义可见Sun文档中的一段英文“Enterprise JavaBeans is an architecture for component-based computing.Enterprise beans are components of transaction-oriented enterprise applications”它是JavaEE的一部分，定义了一个用于开发基于组件的面向事务和分布的企业应用的标准，主要包含了3种Bean，会话Bean，实体Bean，和消息驱动Bean。
    上面简要的介绍了JB和EJB的相同之处和基本概念，对于其不同之处，本人认为应从以下几个方面来看：
    1.       JB和EJB定位的不同
    看上面的EJB的英文解释，可以清楚的看到，EJB是面向事务的，由此可见，它所关注的主要是事务。在JavaEye 论坛潜水的时候，本人了解到，许多需要处理大批量数据的领域里，往往都是以数据性能为主，因此，他们很少用面向对象来建模，而对应于这样的系统，上层所关注的数据操作的粒度就是事务，再细下去，就是要靠DBA优化了，而EJB之所以叫EJB，原因也就是在世，它的核心是事务，它是面向事务的，而不是面向对象的，因此，它定义于企业级。而JavaBean有完整的面向对象模型，它对数据的操作粒度对象，如ORM中，一个对象代表一个记录，如此，再设计上来看，的确是非常优雅，但是性能能否达到企业级的需求？因此，面向事务和面向对象是EJB和JB的最大区别。
    2.       它们对容器依赖程度不同
    这里，要先明确一个概念，何谓轻量级？何谓重量级？其实，本人也是在本周的阅读中，才略有体会。量级主要是看容器的依赖性所决定的,依赖性越小,越轻量。
    EJB必须存在于EJB容器中，EJB规范中，清楚的定义了，那些功能由容器提供，那些功能由Bean提供，因此，EJB严重依赖于EJB容器，因此，它是重量级的。而JavaBean并没有特殊的环境要求，只要在JavaSE平台基础上，它都可以存在，可见它是轻量级的。对于重量级的EJB来说，由于是侵入式设计，将导致其业务逻辑组件脱离了EJB容器后将无法复用，因为组件内有太多的方法或特性需要EJB容器提供（如声明式事务管理，CMP等），而业务逻辑组件往往是程序中最为稳定的部分，这样EJB业务逻辑组件的复用性就大大降低。另外一个关键的地方是，由于其侵入式设计，导致业务逻辑组件必须部署在EJB容器中才能运行，这对于开发调试来说，是极为麻烦的，本人开发过Struts1，深深体会到这样的不便（在Struts1中，业务逻辑控制器依赖于Struts框架，因此，并需部署在Web容器中，才能调试，Struts2改变了这个情况）。
    而JavaBean并不依赖于容器，在业务逻辑层面，我们在JavaBean中只关注业务逻辑，然后可以借助其它框架,如Spring，Hibernate来提供诸如依赖注入，AOP，声明式事务管理以及ORM等技术，这样的好处是，由于Spring和Hibernate都不是侵入式的，或者说不是严重侵入式的，这就使得JavaBean的复用性相对来说较好。
    由此可见，从设计来看，EJB需要强大的容器的相关技术支持，这就将导致它和容器见有许多约定，如哪些是该容器做的，哪些是Bean做的。这样规定以后，对于开发者来说，只有唯一的选择，而这样标准的建立，对代码编写往往有利。反观JavaBean，由于其对容器没有要求，而是借助第三方框架来提供技术支持，导致其和容器间没有约定，而第三方框架也往往没有标准化，也不是说这样就不好，但在越来越抢到规范化的软件领域，这的确是个软肋。
    3.       所处容器的灵活性不同
    对于EJB来说，哪些该由容器实现都已经明文规定了，因此，EJB容器的环境往往不能配置，EJB容器提供了所有企业级开发所必须的技术，如事物，分布等等。而市面上的EJB容器，往往都全部包含了这些技术，不管企业要不要，都一股脑儿的卖出去，这虽然不是一件什么坏事，但从另一角度来说，这导致了EJB容器的极端复杂，并且开销很大，这也是其一直被人诟病的地方。反观JavaBean，在第三方框架的支持下，对容器的环境可以进行配置，讲白一点，就是要什么功能，我引入什么框架，比如，我想要用依赖注入来解除业务逻辑层和持久层的耦合，就可以引入开源的Spring框架等。而对于其容器来说，主要的工作就是装配这些框架，而装配这些框架的能力是基础的，容器不提供其它任何的技术环境。这样，就给组件的实现着提供了灵活配置的权利。
    以上就是本人在阅读书籍和浏览相关网站后，所归纳出的JB和EJB的不同，主要从大的架构和思想上来分析。至于EJB3，本人感觉其已经在朝轻量级的方向发展。由于本人对EJB还了解不深，许多技术细节还尚未弄懂，以上可能还存在观念性错误，还请各位老师，经理指正。