EJB概述

        随着软件的规模的快速增大，各种分布式技术CORBA、RMI等技术陆续出现，软件规模的快速增大和技术复杂度的增加，导致软件开发变得越来越复杂。也就是在这样的背景之下，EJB技术应运而生。

 

        EJB出现之初，它就被捧的非常高，因为SUN公司宣称EJB是一种可以快速开发大规模企业应用的组件体系结构，它会让应用程序开发者集中精力去开发解决各种复杂业务逻辑问题，而不用花费精力来处理分布式服务器、远程调用等底层技术。

 

       也是因为这样的原因，很多人都开始了解EJB，深入研究EJB，也有很多公司开始开发自己的应用服务器，希望在EJB领域中占有先机。然而事情慢慢的发生了改变。

 

       在2000年起，很多技术人员开始对EJB产生怀疑，到了2002年和2003年，这种怀疑达到了顶峰。很多人开始对这种技术进行了抱怨，抱怨它的复杂性，和一开始的简单易用背道而驰。

 

       其实这个时间段正式在EJB的版本2阶段，EJB2确实是有很高的复杂性，这种复杂性体现在了高花费、高投入和非常高的学习成本，很多人在EJB2身上并没有发现当初开始之初倡导的简单易用，开发之中困难重重等。

 

       后来DOT NET出现了，这个给J2EE阵营带了很大的冲击，很多人都在对这两个阵营的孰优孰劣喋喋不休，但是至今也没有有个好的结论。

 

        之后就是Spring和Hibernate的轻量级框架的出现，很多开发者非常喜欢这些轻量级的框架，因为有EJB2的复杂做衬托，直接影响了轻量级JAVAEE的受亲睐的程度。使用Spring+Hibernate框架的组合花费少，可以简单快速的开发出同样健壮的企业级应用。

 

       我们可以发现Spring的IOC容器负责处理企业级应用中各种组件的依赖，AOP可以以切片的形式处理应用底层的系统级问题，例如事务和访问控制等等；而hibernate则作为持久化的解决方案。

 

       这样的背景下，SH框架的组合随处可见，很多人就放弃了EJB改为sh框架结构进行开发。

 

        也许EJB2的复杂性“欺骗”了很多人，其实在我看来其实EJB2还是非常值得肯定的，虽然它没有达到简单易用的那样高的高度，但是它提供了一个成熟解决分布式问题的解决方案，提供了一个成熟的解决分布式问题的规范和架构。

 

       还好SUN公司认识到自己的不足，怀揣着勇于自我否定的勇气，推出了EJB3，直接抛弃了EJB2倍受诟病的一些东西。一下在将沉下去的天平又抬起来了。在这里不得不佩服SUN公司的自我否定的勇气和气度，勇于否定自己，改正并且重装出发。

 

       EJB3吸收了SH等开源框架的优点，用注解的方式代替配置文件简化复杂度，用JPA规范作为持久层的解决方案实现真正的移植性；用依赖注入的方式代替了手动JNDI查找，而且还提供了拦截器机制。

 

       EJB3再次赢得了很多开发者的认同，而且比EJB2简单，SH开发者也很容易转变为EJB3的技术人才，这些都让EJB3获得了大量的支持者。

 

       这就是我所知道的EJB【可能还有些地方认识不深刻，还需大家指正】，一个经历了跌宕起伏的技术，在这个过程中有很多东西需要我们去深思，也需要我们去认识，更加需要我们去学习。