SSH与SSH2这种框架组合的历史原由

早在2001年时当时的J2EE推崇的是EJB，EJB被称为J2EE的核心，当时要学J2EE就是Servlet+EJB，在EJB里其实早已经有了AOP与实体映射这些概念了。

EJB有三种形态的BEAN，SessionBean, Entity Bean, MBEAN对吧？其中，EntityBean就是Hibernate，大家看看，嘿嘿，所以技术这个东西所谓的新也是换汤不换药，在2001时就已经有了Hibernate这种概念了，而且Spring经典的声明式事务代理也早就有了，就是你的SessionBean如果抛出一个java.runtime.exception，EJB容器就会自动回滚事务，而且我们在声明EntityBean时就是和Hibernate2.x一样，写一个xml文件将字段表名和类名和属性名进行一一对应的。

但是有许多人会说ejb2.0是一个失败之作，它的实体映射隐藏了数据库底层的操作把对于表的操作转化成了OOP的操作，这是一个非常好的理念，但是在早期的EJB中连对于如：selectcount(), select max()这样的操作都没有，当然在那时如果碰到这样的处理时有经验的程序员一般会采用EJB中的BPM即直接使用SessionBean+jdbc去完成的，但是就如我前面所说的，为了使用框架而用框架的事情和人数大有所在，为了在工程中使用一套纯正的EJB，纯CMP BEAN，很多程序员们就去用ArrayList.size或者是Vector.size来做这些个count,max等操作，甚至在碰到多表连接时对于每个表取一个List然后在Java代码层去用数据结构来拼装出一个View来。

EJB2.x的配置也是非常繁琐的，没有一个好的现成的工具，一般不包括MBEAN的话仅要使用SessionBean和EntityBean就要配4个xml文件，同时每个EJB的容器如：JBOSS,WEBLOGIC,WAS又彼此间不能通用，在使用不同的J2EE容器时还要为这个容器单独配一个厂商支持的xml文件。

等等等等。。。。。。这一系列导致了使用EJB的工程变得臃肿复杂，难于调试，并伴有严重的性能问题，当时网上骂声也是一片，EJB一度走入低谷。于是，人们就在想，我能否保留EJB中CMPBean的这种实体映射的特性呢？而且我也只希望使用实体映射，于是Hibernate诞生了.Hibernate就是一个除去了EJB2.x一切特性只保留EntityBean的一种技术。

03年，04年随着Hibernate的推广，人们又在想，Hibernate现在有了，EJB原有的声明式事务也是一个不错的设计，我可以让程序员不需要关心他们的数据库层面的transaction处理而只关心业务层面的transaction，所以原有EJB2.x中的AOP概念又被单独剥离了出来，这导致了Spring的诞生.

于是在早期的人们采用Spring+Hibernate这样的架构时，大家其实还是在把这两者的组合在当作EJB来使用的，这样的组合其实就是一个轻量级的EJB2.x，一个缩微了的EJB。因为EJB的设计太超前太好了，只是它的一些缺陷一些瓶劲导致程序员们错用乱用EJB而给EJB造成了不好的口碑，但是因为J2EE的核心就是EJB，因此在04年对于Spring+Hibernate这样的组合有一句口号叫“Thisis not a J2EE”，因为我们不是EJB但我能做到EJB所有的优点，呵呵。这其实就是一种无招胜有招的典形应用场景，把各自的优点最大化的发挥出来而不拘泥于框架而来论框架.

当然，随着EJB3的回归，EJB反过来吸收了Hibernate3与Spring3的一切优点而且它借助着SUN（现在叫ORACLESUN）的工业标准和强大的技术支持，J2EE终还将回归EJB。

EJB3前途无量，它不仅仅把SSH全部又整回成了一个EJB还简化了配置，同时还彻底做到了厂商无关，数据库无关。如著名的SEAM3框架，SCA编程模形（EJB3的SessionBean中可以调用Webservice，这为EJB满足SCA编程模型中的引用、导入等概念带来了极大的便利）都是基于EJB3的，大家有时间我觉得还是可以好好的去关注和学习EJB3技术。

结束今天的教程，下次开始要讲在SSX体系中如何来做unit testing以及如何使用Spring来构建一个单独运行的应用程序如：银行保险业中的批处理业务的框架的搭建。