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来构建一个单独运行的应用程序如：银行保险业中的批处理业务的框架的搭建。