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相關
m.jax-rpc1.1(可選)：rpc協定規範
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規範的所關注的内容，可以看到其章節的組織：
(feiying工作室 技術文章原創 請勿轉載 謝謝)