目录
7.基于Oracle官网的关于的JAVA EE规范内容的划分方式
1.JAVA EE规范综述
JAVA EE是作为JAVA语言的企业级规范进行指定的，其目的是满足于行业软件的企业的应用的需求，在复杂的业务逻辑的前提下，尽可能将屏蔽网络，硬件等复杂的设施，将这些内容转嫁给一些实现了部分JAVA EE规范服务的供应商或者完全实现JAVA EE规范的应用服务器厂商和来做，让系统集成商只关注与业务。
JAVA EE部分规范服务的提供商，以开源项目居多，以实用比较广泛的Tomcat为例，实现了JSP，Servlet等部分的JAVA EE规范，但其不能算作JAVA EE应用服务器，只能被称为web规范的容器而已；
对于JAVA EE规范的应用服务器的提供厂商，开源项目和商业产品并存，举例来说，开源的glassfish为JAVA EE规范的参考实现；对于IBM的Webaphere和Oracle的Weblogic来说，之所以称之为JAVA EE应用服务器，也是因为其实现了JAVA EE的全集规范。
在JAVA EE6规范之前，所有的规范都实现才可以叫做JAVA EE应用服务器，但是由于时代的发展，JAVA EE规范越来越多，越来越重，将重量级JAVA EE规范进行轻量级的呼声尤为突出；JAVA EE6规范，首先做出改革，将最常用的web容器相关的规范，做成了一个集合，叫做Web Profiler，JAVA EE应用服务器可以选择只实现WebProfiler，或者实现一个全集规范，例如开源项目TomEE就是只是选择实现了WebProfiler；
总之，JAVA EE其实就是一个社区推动起来的一个企业级的规范，可以简单的说，就是一系列关注与企业级领域的API，由此而引申的关于如何做企业级应用，和围绕着JAVA EE的一些API(例如Servlet，JPA)等一些兴起的开源项目社区，日益的庞大，使得企业级应用开发越来越便利；未来的JAVA EE规范仍旧会不断的向前发展，向着模块化各种规范，向着轻量级，高性能，云计算，海量数据处理等方向前进。
2.JAVA EE整体架构
可以看到，在JAVA EE6的最新规范中，是按照容器进行划分的，这里的容器的概念其实可大可小，对于整个JAVA EE6的大块来看，一共分成4个大的容器：
a. 应用客户端容器，一般这个客户端为直接在操作系统中存在的JRE环境中，实质上可以理解为在JRE中启动一个JVM的进程，也就是main函数，在这个main函数中，可以直接在这个环境中引入一些对应的规范，在上面的竖条中的规范可以看到，n次出现在各种容器中，其代表就是，对应的JAVA EE规范是否可以再当前的容器中运行。
b. Applet容器，实质就是在嵌入到浏览器环境中的JRE的一个插件，通过Swing和Awt等图形化的API，在浏览器宿主环境中，显示具体的图形。
c. Web容器，可以理解为其主要支撑的JAVA EE规范是WebProfiler的，其核心为Servlet和JSP，在Web容器中的竖条规范中，即为JAVA EE的WebProfiler。
d. EJB容器，即为除了WebProfiler特性之外的所有的规范的内容集合，注意，一定不要理解为仅仅支持单纯的EJB规范，只是在EJB容器中的核心为EJB规范而已，可以看到在EJB容器中的很多内容都是与Web容器相重复的，只是容器的核心不同而已，并且在EJB容器中，例如在Web容器中的JSTL，EL等规范就不能使用了；
上述的四个容器构成了整个JAVA EE的环境，可以看到上图中还有一些连线，这里面描述了容器和容器之间的调用关系，和一些调用协议，例如加密协议SSL和普通的HTTP协议；对于数据库也可以看到一些连线，通过Web容器，EJB容器，应用客户端可以对数据库进行操作。
3.JAVA EE规范的角色划分图
JAVA EE的规范中，还需要明确的就应该是JAVAEE平台的角色的划分，我们可以根据目前的行业软件的一个非常典型的合作情况，来看整个JAVA EE规范的角色的划分；
可以看到上述的几个角色：
a. JAVA EE Product Provider ：JAVA EE产品的提供商，也就是JAVAEE应用服务器，对于国产的JAVA EE应用服务器来说，就是东方通，金蝶，中创；对于国外来说，就是IBM的Websphere，和Oracle的Weblogic的服务器。
b. Application component provider ：应用组件提供商，相当于实现了Servlet，EJB的一些Bean，但是可以看到目前的企业级软件市场的领域中，对于这些Bean都进行了二次的封装，例如一些公用的服务，通用的领域组件，这些部分通常一些开源的项目，例如Spring，Struts等开源项目，都会通过优良的设计模式和架构模式将一些API接口更好的使用起来，这部分的封装也有一些商业上的实现，如国内比较著名的普元，起步软件等等；
c. Tool Provider：对于工具的支撑再好理解不过了，例如Eclipse中有对应的应用服务器的一些的插件，也有对应着领域平台，如用友NC平台的一些插件；
d. Application Assembler ：系统集成，对应的就是系统的集成商，也就是中软，神州数码，用友，东软这一个层级的行业软件的公司，进行业务的组装，俗称系统集成；
e. Deployer：JAVA EE角色中，将部署提高到一个非常高的高度，成为了一个角色，其实来说部署确实是一个非常繁重的任务，将大家开发的源码都集成起来，进行编译工作，编译完成打成应用服务器识别的包，进行部署的工作；虽然这里面大部分有一些自动化的脚本来完成，但是在部署中出现的错误和问题，需要部署人员去定位，然后找到对应的系统集成人员进行修改；
f. System administrator：系统管理员指的是系统集成商中，维护这个JAVA EE系统的监控，运维这部分的内容；
g. System Component Provider：在本系统之间需要调用到其它的系统，例如JCA借口这类的集成任务；
4.JAVA EE平台依赖的J2SE API
在JAVA EE平台中，依赖于一些J2SE的API
a. HTTP：net包中的内容
b. HTTPS：net包，ssl包
c. RMI-IIOP: rmi的包， EJB的环境实现方式
d. JAVA IDL：调用Corba包，IDL接口定义，EJB的环境构成，在JAVAEE5之前，Corba一直是标准实现
e. JDBC：数据库驱动
f. JNDI：命名服务
g. JAVAMail：邮件服务包
h. JAF：判断数据属于什么MIME类型，这个JAVAMAIL包主要调用的这个包，这个包一般用的不是很多
i. XML Process：JAXP
j. Sercurity Service：JCA，JCE，JSSE，JACC，JAAS等几个JAVA安全的认证
k. Management：JMX
5.JAVA EE平台的版本变迁
对于JAVA EE平台的版本：
从JAVA EE 1.3是一个基本的雏形，包括整个规范的前身的内容，JMS，JCA，EJB等等都在这一个规范中有一个雏形；
JAVA EE 1.4是将1.3的雏形相对而言的进行完善，并且加上了关于WebService等非常多的分布式的内容，可以看到这个和当时的历史是有关系，1.4正值SOA的热潮；
JAVA EE 1.5比较大的变化，首先从名字上进行修改，为JAVA EE5，不再是1.x的序列；其次，由于J2SE中的原注释等非常大的跨度的改变，JAVA EE 5进行了大量的原注释的内容的变化，将原来的好多的配置文件都转化为原注释进行定义，可以看到与JDK 5与时俱进。
JAVA EE 6主要是针对于hibernateSpring的社区的IOC，AOP等很多的注入进行了大量的更新，加入了好多如CDI,DI的规范，其次针对于目前的轻量级的浪潮，JAVA EE 6以profile的划分进行更精细化的分割。
6.JAVA EE平台的趋势预测
从上述的JAVA EE平台的发展上面来看，JAVA社区汇总了当前时代的最新的思想，SOA，MAVEN的约定大于配置，云计算等等的优秀的思路；但是往往JAVA EE平台这种跟风的潮流，JAVA EE的这些规范越来越“小众化”，所谓的“小众化”指越少人使用这些往往已经成为人们心目中经典的内容，例如Spring作为依赖注入基本上是事实的标准，所以JAVA EE6后来出了一个DI，CDI这种的原注释的信息，这种内容肯定不被人们所知，例如Apache的OpenWebbean这种开源的参考实现，Spring的原注释有很多自定义的内容，并不是JAVA EE6的标准，系统集成人员往往习惯使用类似于这样的内容，而不用一些标准化的内容，即使Spring目前已经支撑了标准化的JSR 330和JSR 299等标准；
因此，这种“小众化”的影响是，整个JAVAEE6看起来是非常的美好，但是对于新增加的这部分的规范，使用人数越来越少，人们往往使用的还是Servlet,Jsp，就连JSF使用的人数也是越来越少了，从这样，也可以侧面的反应出，目前国内的金蝶等中间件厂商并没有急于跟进JAVA EE6的规范，这个也是其中的一个原因；
对于未来来讲，JAVA EE的规范人就是企业级服务的经典，对于上述“小众化”的内容，在与JAVA EE指定人之一，TongTech的李明的讨论会议中，未来的趋势是将这些“小众化”的规范从WebProfiler中移除，只保留几个例如Jsp等非常有用的规范即可；
未来的JAVA EE平台仍旧是前途莫测，实践证明，规范这种内容，如果不紧跟着时代的脉搏，那么JAVA EE规范必然会走向消亡，从而导致无人而用的境地。
7.基于Oracle官网的关于的JAVA EE规范内容的划分方式
本节内容是Oracle在官方网站上，基于JAVA EE规范的内容的一个分类，(当然这仅仅只是Oracle的一种分类方法，不一定准确)这种分类方式内容涵盖了J2SE，按照模块来进行划分，可以看到更为清晰的描述了JAVA EE规范的内容：
a.webservice相关规范
b.web容器相关规范
c.ejb容器相关规范
d.管理和安全相关规范
e.j2se相关规范
8.基于Profiler规范的JAVA EE规范的划分方式
a.WebProfiler
a.servlet3.0
b.Jsp2.2
c.el2.2
d.jstl1.2
e.jsf2.0
f.debuggerfor support for other language： 此规范的解决实质，为其它语言编译为JAVA语言时，在调试的时候行号无法对应，最典型的例子就是增加了这个规范之后，JSP可以进行调试，此规范定义了一个列表SMAP，这个列表的行号为其它语言与JAVA语言之间一一对应关系。
g.jax-rs2.0: rest的API
h.ejb3.1
i.intercepters1.1:原来为EJB规范拦截器规范，后由于此规范的通用性，JAVA EE将此规范从EJB3.0规范中脱离，在其它的组件环境中也可适用
j.jta1.2
k.jpa2.1：EJB2.0时代的CMP的替代产物，CMP已经成历史的废弃的产物
l.commonannotation1.1:公用的注释方法，@PreConstruct，@PostConstruct等，此规范的真正意图是将这种公用的原注释放入一个包中，进行调用。
m.CDI1.1：jboss推荐的注入包，在JAVAEE5中加入，后来由于内容比较全而复杂，很多场景只需简单的注入，后来引入DI规范，CDI规范基于DI规范来做，是其JAVAEE的扩充。
n.DI1.0：google推荐的注入包，CDI内容精简版，guice的参考实现，其目的是在J2SE中提供一个简单注入规范，从而解决CDI过于复杂的JAVA EE注入定义；
o.ManagedBeans1.0：JAVA EE6的“灵魂规范”，虽然内容不多，但是就是一句话告诉了我们，JAVA EE的所有Bean都是托管Bean，都是可以注入，拦截，原注释引用的；
p.BeanValidation1.1：从JPA规范的子规范中脱离的，关于Bean校验的内容，和拦截器一样，由于通用性，被提到了一个规范的高度
a.FullProfiler的其它规范
a.jms1.1
b.jca1.6
c.JAVAmail1.4
d.JAVAmanagement1.1：jmx最新版本
e.JAVAdeploy1.2(可选)：JSR88的deploy接口
f.jacc1.4：安全容器认证规范，关于安全这块的这几个规范的配合如下：
认证与授权为JAAS和JACC，SSL处理为JSSE，密码处理为JCA/JCE；
上图为JAVA EE运行时整个安全认证框架；
g.jaspic1.0：在消息发送和传输的过程中，需要一些认证和安全相关的SPI的接口，JASPIC就是定义这个SPI的provider的接口的，与JMS配合使用；
h.webservicefor JAVA EE 1.3：webservice相关规范
i.webservicemetadata for JAVA EE 1.3：webservice相关规范
j.jax-ws2.2：与jax-rs对应的webservice的soap协议规范
k.jaxb2.2：xml相关
l.jaxr1.0(可选)：xml相关
9. JAVA EE6 Webprofiler规范的新特性
a.Servlet 3.0新特性
原注释配置：在原有的web.xml的基础上，加上了诸如@WebServlet，@WebFilter，@WebListener等一些原注释的标签，使用这些标签之后，完全可以抛弃web.xml了；
异步处理：可以通过在web.xml中servlet的配置设置asyncSupported属性，将这个servlet变为异步的servlet。所谓的servlet的异步调用，实际是servlet的执行不再是同步的，实际是新启动了一个线程，执行servlet的内部逻辑的内容，不管其是否能执行完成，直接进行返回；然后通过注册Listener，可以通过观察者模式来得到目前的异步servlet线程的事件和进展情况，对应不同的事件执行对应的动作。
WebFragment：由于原来一个大项目中web.xml可能会非常大，对应一个web项目来说分为不同的模块，因此在Servlet3.0中引入了一个新的概念，通过在META-INF文件夹下的web-fragment.xml中定义web.xml的片段，通过before和after等标签确定web.xml中的位置，应用服务器扫描这个文件，并在部署的时候加入到web.xml中来。
ServletContext动态API：在原来的JAVA EE6之前，不可以在应用部署之后，增加一些Servlet，Filter之类的内容，只能通过重部署，而在新规范中可以放出一些ServletContext的API进行动态添加。
b.JSP 2.2新特性
omit属性：<jsp:attribute name="color"omit="false">blue</jsp:attribute> 的omit属性，可以指示该属性是否可以忽略掉。
c.JSF 2.0新特性
简化托管Bean的配置：将faces-config.xml中的ManageBean的配置，可以再类中定义@ManageBean进行原注释；
AJAX支持：在button中定义f:ajax标签，制定渲染的对象，使得通过JSF标签可以自动进行ajax的提交和渲染操作，全程一行和ajax的与服务器交互的js代码都不用写。
隐式导航：原来的JSF的配置导航，无非是需要在faces-config.xml中配置navigation-rule，而隐式导航其实是通过约定大于配置，默认在标签中加入域文件路径同名的应用，这样的好处就是省略了不必要的配置。
资源获取：增加了<h:outputScript>和 <h:outputStylesheet>两个标签的内容，可以引入resource目录下面的js脚本和css样式表。
模板：在velocity等框架中非常常用的模板，在JSF2.0中也开始出现了，通过定义<ui:insert>和<ui:define> 标签，可以再JSF页面中清晰的插入已经存在的模板内容；
其实JSF2.0的最大的变化是，页面不再是.jsf了，而是.xhtml等这种普通的页面了，这个才是JSF2.0最大的利好消息；
d.EJB 3.1新特性
EJB3.0是EJB的最大的变化，在3.0阶段，使用了大量的原注释，替代了原来的繁琐的接口和xml配置方式，极大的提高了ejb的编写的工作效率；其次EJB3.0中，对于EJB的引用也大大的进行了提升，即使用原注释通过注入的方式进行注入，这样就解决了通过JNDI硬编码调用的问题，大大的提高了代码的可读性；EJB3.0中吸取了Hibernate的开源项目的很多优势，依据其ORM的思想进行形成JPA规范，在EJB3.0规范内部。
EJB3.1对EJB3.0的规范更加的进行了修改和细化，并对庞大的EJB3.0进行裁剪，扩充到平级的JAVA EE规范中，内容如下：
EJB3.0裁剪：JPA2.0，Intercepter规范从EJB3.0规范的拦截器规范分离了出来。
无接口的EJB：在EJB3.0中，将远程和本地接口转化为了普通的接口，这样看起来EJB其实就是和普通的bean没有什么两样了，而在EJB3.1中，更近一步，把接口也给省略了，直接通过原注释@Stateless在类中进行定义，EJB的定义从而变得空前的简单；
单例Bean：一个服务器中只保存一个实例，在EJB3.1中根据设计模式中的单例模式，引入的一种新Bean。
异步调用:在Servlet3.0中有了异步调用后，在EJB3.1中也开始了异步调用的新特性，可以看到通过在方法级别注入使用@Asynchronous注解后便成为是异步调用的方法，返回一个java.util.concurrent API的Future对象，供客户端 进行处理，此种方式与Servlet的异步注入稍有不同。
JNDI的统一命名：基于JAVA EE6有一套整体的JNDI的统一命名原则，而EJB也因为统一命名原则而得利，例如：global的模式：java:global[/<app-name>]/<module-name>/<bean-name>
EjbLite与版本划分：针对于Webprofiler进行了EJB部分的裁剪，保留了无状态，状态，单例Bean最核心的内容，做出lite版本就是为了在web容器中使用。
War包中含有EJB：在war包中有EJB的定义，此更新意义重大，即在web容器中可以同样使用EJB，当然这个EJB是EJBlite。
定时器加强：Timer是在EJB3.0阶段引入的，在EJB3.1的阶段中，对定时规则的更进一步的精细化的定制。
e.JPA 2.0新特性
JPA规范是在EJB3.0时期，替代CMP，基于ORM的思想，重磅推出的一个JAVAEE规范。由于JPA已经身处于JDK5的时代，因此JPA规范一上来就是通过原注释的方式进行工作，可以通过@PeresistenceContext注入，也可以通过JNDI代码方式获取，也可以配置persistence.xml文件；对于JPA中有关EntityManager的事务控制。
JPA2.0相比较JPA1.0，增加的功能不多，大多数都是边缘的功能，例如Criteria API，悲观锁等功能。
f.JNDI新特性
在JAVA EE6之前，JNDI分为组件名空间和全局名空间，所谓的全局名空间，就是对应的一颗全局的JNDI树，树枝上就是Context入口，树Node节点上就是对应绑定的内容，可以看到这个结构异常的清晰，当一棵树上的树Node节点的名字还想换成其它的名字时候，需要通过配置文件，配置env环境名称映射，然后在代码中通过java:comp/env进行访问和调用处理。
可以分析上述的JNDI规范中的env环境名称映射，相当于是针对于JAVA EE对JNDI树节点在当前的模块下，进行重命名映射，使得应用也可以用另外一个名字进行访问。在JAVA EE中，根据这种环境映射名称，进行了更大范围的扩充，将其分为java:comp，java:module，java:app，java:global；
java:global对应的就是原来全局的JNDI树，在原来的JNDI节点需要加上java:global前缀；
而java:app对应的是同一个应用的共享环境名称映射，java:module对应的是在同一个应用的同一个模块的共享环境名称映射，这两个共享的名称映射无需进行任何的配置，直接就是JAVA EE规范支持，可以直接通过java:module，java:app在相关的作用域下面的程序，直接可以进行调用。
java:comp实际上和java:comp/env还是有一些区别的，java:comp实际上的理解就是通过组件自身的作用域下面，可以自己调用自己，但可以分析出，这样做没有什么意义，并且程序循环嵌套还会出现问题，因此可以说JAVA EE中之所以分出四个作用域，实际上除了java:comp的作用域，其它的三个作用域是实际存在作用的；而java:comp作用域更多代表的是组件名的配置文件中的映射，继承下原来的JAVA EE5的内容。
f.DI新规范
google的Guice的官方的实现，Guice的实现非常的简单，而DI的意图实际上，是简化CDI规范中的庞杂的注入，并在J2SE层级提供可以使用的轻量化的CDI规范。
可以看到，整个DI规范在加入JAVA EE规范后，DI规范仅仅是CDI规范的基础，CDI规范和DI规范在JCP社区中进行和谐的发展，二者分工各有所不同。
g.CDI新规范
CDI规范为JAVA EE中就引入的规范，在JAVAEE6中为JAVA EE各种容器中依赖注入的核心规范，为@ManageBean的实现作为依托。
CDI规范实际上是，Jboss服务器中的关于依赖注入的一个非常完美的注入实现，JAVA EE社区基于此，将Jboss这些这部分的实现做成了CDI的参考实现。
CDI规范实际上是DI的JAVA EE版本，其很多的规范描述的功能，都在DI规范的基础注入概念的基础之上，加上限定符，具有JAVA EE领域含义的实际的范围，生产注入工厂，替换和特殊化，装饰器，发送事件等内容，这些内容全部是注入的延伸，和更好的在JAVA EE领域中使用注入。
h.BeanValidation新规范
Bean Validation规范为Bean规范的校验，从JAVAEE 6来看，将各种的功能特性，以组件为核心，以各种行为作为组件的动作，由此形成了规范集合的定义。
而在这些对象和动作中，校验这种动作时具有非常通用和普遍意义的，因此JAVA EE6从Hibernate中的Bean Validation的功能，将几乎所有的这些功能都引入了JAVA EE的规范中，这也就成了Bean Validation；
Bean Validation主要用于在JPA规范，ORM对象进行增删改查的时候，进行校验的这一基本动作，后由于@ManageBean规范的引入，将JAVA EE对象组件化，这个 Bean Validation 就可以引申至整个的JAVA EE规范的领域的组件校验当中。
i.Intercepter新特性
Intercepter规范，基于Spring的AOP的思想，在调用EJB对象，在调用的前后进行拦截。由于Intercepter规范的过于简略，和Spring的强大的AOP切面编程，无法相提并论，因此该规范一直被JAVA 开源爱好者所诟病。
在JAVA EE6 中，Intercepter规范从EJB规范中脱离出来，将AOP的拦截功能升级为单独的规范，将JAVA EE范围的所有的“ManageBean”都可以执行拦截。
j.ManageBean新规范
ManageBean，即为受管Bean，原指JSF规范中的@ManageBean，原来的ManageBean为JSF中事件处理类。
JSF与MVC思潮不同，在于一个为事件驱动型，一个是控制流转型，而ManageBean就是将浏览器组件的事件进行包装，在服务器端解析成html，将html的后端映射的servlet类，根据url的请求，指向对应的ManageBean逻辑处理类。通过上述的分析，实际上JSF是通过servlet规范来实现了JSF规范，因此可以说JSF规范是servlet规范的上层，也可以说由MVC实现了事件响应模式。
ManageBean在JAVA EE6中，将原来的JSF中的@ManageBean，提升到了JAVA EE全局。也就是在JAVAEE应用中，带有@java.annotation.ManageBean的，带有原来javax.faces.bean.ManageBean的，ejb都会被叫做受管Bean，从形态上来看，受管Bean和普通的javabean无任何区别，从行为上来看，受管Bean受服务器生命周期的控制，因此才叫做受管Bean。
在ManageBean生命周期，委托对应的容器来进行生命周期管理，例如ejb就是由ejb容器进行管理，JSF的ManageBean就是由jsf的映射缓存进行管理等等，而@java.annotation.ManageBean由注入容器进行管理等等。
在JAVA EE规范的实现中，大多数注入容器都将所有的JAVABean(条件满足ManageBean的)，解释成JAVABean，注入容器负责将这些所有的JAVABean进行管理。
k.CommonAnnotation新规范
对于一些JAVA EE规范中的一些通用的原注释，例如涉及到ManageBean，和preConstruct，postDestroy等等原注释，还有数据源定义的一些，JAVA EE将其单独抽取到一个包中。
这个规范也被叫做CommonAnnotation规范。
10.JAVA EE规范专家组成员
在JAVA EE6的专家组中，东方通首次加入了JAVA EE的专家组，并且在JAVA EE7中也同样有东方通的名字，代表人为ming li，在JAVA EE6的中国区还有peking university的gang huang，下面是JAVA EE6的所有的专家组的成员：
Bill Shannon (Sun Microsystems, Inc.)和Roberto Chinnici (Sun Microsystems, Inc.)。此专家组包含了下面的成员: Florent Benoit (Inria), Adam Bien(Individual), David Blevins (Individual), Bill Burke (Red Hat Middleware LLC),Larry Cable (BEA Systems), Bongjae Chang (Tmax Soft, Inc.), ReJAVA EEvDivakaran (Individual), Francois Exertier (Inria), Jeff Genender (Individual),Antonio Goncalves (Individual), Jason Greene (Red Hat Middleware LLC),GangHuang (Peking University),Rod Johnson (SpringSource), WernerKeil (Individual), Michael Keith (Oracle), Wonseok Kim (Tmax Soft, Inc.), JimKnutson (IBM), Elika S. Kohen (Individual), Peter Kristiansson (Ericsson AB),Changshin Lee (NCsoft Corporation), Felipe Leme (Individual), Ming Li (TongTech Ltd.), VladimirPavlov (SAP AG), Dhanji R. Prasanna (Google), Reza Rahman (Individual), RajivShivane (Pramati Technologies), Hani Suleiman (Individual)。
11.JAVA EE6官方文档内容预览
可以从Oracle的官方网站上下载对应的文档，例如对应的JAVA EE6来说，就是下面的两个文档：
对于第一个文档而言，其从以前的版本中，就描述了整个JAVA EE规范的所关注的内容，可以看到其章节的组织：
