[转载]javaEE规范和SSH三大框架到底有什么关系

转载自： http://blog.csdn.net/bingjing12345/article/details/20641891

1994-2000 年是互联网的大航海时代。

请注意，下面的时间点及其重要。

1994年，网景公司（Netscape）发布了Navigator浏览器0.9版。这是历史上第一个比较成熟的网络浏览器，轰动一时。但是，这个版本的浏览器只能用来浏览，不具备与访问者互动的能力。网景公司急需一种网页脚本语言，使得浏览器可以与网页互动。

1995年Sun公司将Oak语言改名为Java，正式向市场推出。Sun公司大肆宣传，许诺这种语言可以"一次编写，到处运行"（Write Once, Run Anywhere），它看上去很可能成为未来的主宰。

1995年5月，网景公司做出决策，未来的网页脚本语言必须"看上去与Java足够相似"，但是比Java简单，使得非专业的网页作者也能很快上手，于是JavaScript就诞生了。

1998年Sun公司在发表JDK1.2版本的时候，使用了新名称Java2 Platform，即“Java2平台”，修改后的JDK称为Java 2 Platform Software Develping Kit，即J2SDK。

并分为标准版(Standard Edition，J2SE), 企业版(Enterprise Edition，J2EE)，微型版(MicroEdition，J2ME)。J2EE便由此诞生。

sun设计J2EE的初衷正是为了解决两层模式（client/server）的弊端。

在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议，通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。

J2EE将网站的开发分为四层：

客户层组件

J2EE应用程序可以是基于web方式的（浏览器），也可以是基于传统方式的.浏览器方面主要推动了html+css+js

web 层组件

J2EE web层组件可以是JSP 页面或Servlets.

业务层组件

EJB做了业务逻辑的处理和数据库相关的操作。

有三种企业级的bean: 会话（session) beans，实体（entity) beans，和消息驱动（message-driven)

beans. 会话bean 表示与客户端程序的临时交互.实体bean 表示数据库的表中一行永久的记录. 当客户端程序中止或服务器关闭时，就会有潜在的服务保证实体bean 的数据得以保存.消息驱动 bean 结合了会话bean 和 JMS的消息监听器的特性，允许一个业务层组件异步接收JMS 消息.

企业信息系统层

存储信息。企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划

(ERP），大型机事务处理，数据库系统，和其它的遗留信息系统。

这套规范大大降低了网站的开发难度，从某些方面看它绝对是成功的。可网站的开发还是比较困难。J2EE这套规范应该是订的太早了，因为当制定这套规范时互联网正在迅猛发展，可以用一日千里形容。

2000年发生互联网泡沫，sun公司一蹶不振。同时遇难的还有一堆不知名的小互联网公司。可能是那时候做网站的一堆人们日子比较清闲，毕竟很多公司都关门大吉了。有些人就发现，J2EE这套规范臃肿、低效、难用且脱离现实。于是他们下定决心，对其改造。

2000~2001年 Craig觉得web层可以使用MVC框架使该层开发更加容易，于是就有了Struts，这一步是对原来规范的很好实现，并没有产生质的突破。

2001~2003年 Gavin 觉得EJB连接数据的部分有待改进，于是就有了hibernate，Hibernate并没有被规范束缚，而是想怎么改就怎么改。

2002年左右 html+css+js也开始渐渐分离

2002~2004年 Rod觉得类和类之间的依赖关系应该改善，于是就有了spring，Spring是为了让javaEE规范更加易用，因此对其进行了大刀阔斧的改造。在当时看绝对是取其精华，去其糟粕。

从1998年到2004年，sun公司不可能没有发现J2EE存在的问题，可是从2000年以后sun就无能为力了，因为它的股票一落千丈，跌的就剩下零头了。这才有了SSH这些框架诞生的时间和空间。

由此看来危机恰恰才是我们的转机，在黑暗中看到希望，我们的成就才能超出我们的想象。

还没完，以下来自百度知道，感觉回答的挺好的。

简单的理解为是一种语言的的一种设计思想， 在java的基础上加入了一些EJB，Servlet，JSP，XML等技术的全面支持，其最终目标是成为一个支持企业级应用开发的体系结构，简化企业解决方案的开发，部署和管理等复杂问题。