j2ee

J2EE（Java 2 Platform, Enterprise Edition）是一個為大企業主機級的計算類型而設計的Java平台。Sun微系統（與其工業夥伴一起，例如IBM）設計了J2EE，以此來簡化在受客戶級環境下的應用開發。由於創造了標準的可重用模塊組件以及由於構建出能自動處理編程中多方面問題的等級結構，J2EE簡化了應用程序的開發，也降低了對編程和對受訓的程序員的要求。

J2EE本身是一個標準，而不是一個現成的產品（雖然現在有很多符合J2EE標準的產品），它由以下幾個部分組成：

（1）J2EE規範。該規範定義了J2EE平台的體系結構、平台角色及J2EE中每種服務和核心API的實現要求。它是J2EE應用伺服器開發商的大綱。

（2）J2EE兼容性測試站點。Sun公司提供的一個測試J2EE應用伺服器是否符合J2EE規範的站點，對通過該站點測試的產品，Sun公司將發放兼容性證書。

（3）J2EE參考實現。即J2EESDK，它既是Sun公司自己對J2EE規範的一個非商業性實現，又是為開發基於J2EE企業級應用系統原型提供的一個免費的底層開發環境。

（4）J2EE實施指南。即BluePrints文檔，該文檔通過實例來指導開發人員如何去開發一個基於J2EE的多層企業應用系統。

J2EE的體系結構可以分為四層。

·客戶端層：負責與用用戶直接交互，J2EE支持多種客戶端，所以客戶端既可以是WEB瀏覽器，也可以是專用的Java客戶端。

·伺服器端組件層：本層是為了基於WEB的應用服務的，利用J2EE中的JSP與Java Servlet技術，可以響應客戶端的請求，並向後訪問封裝有商業邏輯的組件。

·EJB層：本層主要封裝了商務邏輯，完全企業計算機，提供了事務處理，負載均衡、安全、資源連接等各種基本服務，程序在編寫EJB時可以不關心這些基本的服務，集中注意力於商務邏輯的實現。

·企業信息系統層：企業信息系統層包括了企業的現有系統（包括資料庫系統、文件系統），J2EE提供了多種技術以訪問這些系統，如JDBC訪問DBMS。

在J2EE規範中，J2EE平台包括有一整套的服務、應用編程介面和協議，可用於開發一般的多層應用和基於WEB的多層應用，是J2EE的核心和基礎。它還提供了EJB、Java Servlets API、JSP和XML技術的全面支持等。

1、企業級應用框架的需求 在許多企業級應用中，例如資料庫連接、郵件服務、事務處理等都是一些通用企業需求模塊，這些模塊如果每次在 開發中都由開發人員來完成的話，將會造成開發周期長和代碼可靠性差等問題。於是許多大公司開發了自己的通用模塊服務。這些服務性的軟體系列統稱為中間件。

2、為了通用必須要提出規範，不然無法達到通用

在上面的需求 基礎之上，許多公司都開發了自己的中間件，但其與 用戶的溝通都各有不同，從而導致用戶無法將各個公司不同的中間件組裝在一塊為自己服務。從而產生瓶頸。於是提出標準的概念。其實J2EE就是基於 JAVA技術的一系列標準。

註：中間件處在操作系統和更高一級應用程序之間。它充當的功能是：將應用程序運行環境與操作系統隔離，從而實現應用程序開發者不必為更多系統問題憂慮，而直接關注該應用程序在解決問題上的能力。容器的概念就是中間件的一種。

Sun公司在1998年發表JDK1.2版本的時候，使用了新名稱Java 2 Platform，即“Java2平台”，修改後的JDK稱為Java 2 Platform Software Develping Kit，即J2SDK。並分為標準版(Standard Edition，J2SE), 企業版(Enterprise Edition，J2EE)，微型版(MicroEdition，J2ME)。J2EE便由此誕生。

2005年6月，JavaOne大會召開，SUN公司公開Java SE 6。此時，Java的各種版本已經更名以取消其中的數字“2”：J2EE更名為Java EE, J2SE更名為Java SE，J2ME更名為Java ME。

Java2平台包括標準版（J2SE）、企業版（J2EE）和微縮版（J2ME）三個版本。

J2EE為搭建具有可伸縮性、靈活性、易維護性的商務系統提供了良好的機制：

1. 保留現存的IT資產：

由於企業必須適應新的商業需求，利用已有的企業信息系統方面的投資，而不是重新制定全盤方案就變得很重要。這樣，一個以漸進的（而不是激進的，全盤否定的）方式建立在已有系統之上的伺服器端平台機制是公司所需求的。J2EE架構可以充分利用用戶原有的投資，如一些公司使用的BEA Tuxedo、IBM CICS,IBM Encina，、Inprise VisiBroker 以及Netscape Application Server。這之所以成為可能是因為J2EE擁有廣泛的業界支持和一些重要的'企業計算'領域供應商的參與。每一個供應商都對現有的客戶提供了不用廢棄已有投資，進入可移植的J2EE領域的升級途徑。由於基於J2EE平台的產品幾乎能夠在任何操作系統和硬體配置上運行，現有的操作系統和硬體也能被保留使用。

2. 高效的開發：

J2EE允許公司把一些通用的、很繁瑣的服務端任務交給中間供應商去完成。這樣開發人員可以集中精力在如何創建商業邏輯上，相應地縮短了開發時間。高級中間件供應商提供以下這些複雜的中間件服務：

o 狀態管理服務 -- 讓開發人員寫更少的代碼，不用關心如何管理狀態，這樣能夠更快地完成程序開發。

o 持續性服務 -- 讓開發人員不用對數據訪問邏輯進行編碼就能編寫應用程序，能生成更輕巧，與資料庫無關的應用程序，這種應用程序更易於開發與維護。

o 分散式共享數據對象CACHE服務 -- 讓開發人員編製高性能的系統，極大提高整體部署的伸縮性。

3. 支持異構環境：

J2EE能夠開發部署在異構環境中的可移植程序。基於J2EE的應用程序不依賴任何特定操作系統、中間件、硬體。因此設計合理的基於J2EE的程序只需開發一次就可部署到各種平台。這在典型的異構企業計算環境中是十分關鍵的。J2EE標準也允許客戶訂購與J2EE兼容的第三方的現成的組件，把他們部署到異構環境中，節省了由自己制訂整個方案所需的費用。

4. 可伸縮性：

企業必須要選擇一種伺服器端平台，這種平台應能提供極佳的可伸縮性去滿足那些在他們系統上進行商業運作的大批新客戶。基於J2EE平台的應用程序可被部署到各種操作系統上。例如可被部署到高端UNIX與大型機系統，這種系統單機可支持64至256個處理器。（這是NT伺服器所望塵莫及的）J2EE領域的供應商提供了更為廣泛的負載平衡策略，能消除系統中的瓶頸，允許多台伺服器集成部署。這種部署可達數千個處理器，實現可高度伸縮的系統，滿足未來商業應用的需要。

5.穩定的可用性：

一個伺服器端平台必須能全天候運轉以滿足公司客戶、合作夥伴的需要。因為INTERNET是全球化的、無處不在的，即使在夜間按計劃停機也可能造成嚴重損失。若是意外停機，那會有災難性後果。J2EE部署到可靠的操作環境中，他們支持長期的可用性。一些J2EE部署在WINDOWS環境中，客戶也可選擇魯棒性（穩定性）更好的操作系統如Sun Solaris、IBM OS/390。魯棒性最好的操作系統可達到99.999%的可用性或每年只需5分鐘停機時間。這是實時性很強商業系統理想的選擇。

這種基於組件，具有平台無關性的J2EE 結構使得J2EE 程序的編寫十分簡單，因為業務邏輯被封裝成可復用的組件，並且J2EE 伺服器以容器的形式為所有的組件類型提供後台服務。因為你不用自己開發這種服務，所以你可以集中精力解決手頭的業務問題。

容器和服務容器設置定製了J2EE伺服器所提供的內在支持，包括安全，事務管理，JNDI(Java Naming and Directory Interface）定址，遠程連接等服務，以下列出最重要的幾種服務：

J2EE安全（Security）模型可以讓你配置 web 組件或enterprise bean，這樣只有被授權的用戶才能訪問系統資源. 每一客戶屬於一個特別的角色，而每個角色只允許激活特定的方法。你應在enterprise bean的布置描述中聲明角色和可被激活的方法。由於這種聲明性的方法，你不必編寫加強安全性的規則。

J2EE 事務管理（Transaction Management）模型讓你指定組成一個事務中所有方法間的關係，這樣一個事務中的所有方法被當成一個單一的單元. 當客戶端激活一個enterprise bean中的方法，容器介入一管理事務。因有容器管理事務，在enterprise bean中不必對事務的邊界進行編碼。要求控制分散式事務的代碼會非常複雜。你只需在布置描述文件中聲明enterprise bean的事務屬性，而不用編寫並調試複雜的代碼。容器將讀此文件並為你處理此enterprise bean的事務。JNDI 定址（JNDI Lookup）服務向企業內的多重名字和目錄服務提供了一個統一的介面，這樣應用程序組件可以訪問名字和目錄服務。

J2EE遠程連接（Remote Client Connectivity）模型管理客戶端和enterprise bean間的低層交互。當一個enterprise bean創建后，一個客戶端可以調用它的方法就象它和客戶端位於同一虛擬機上一樣。

生存周期管理（Life Cycle Management）模型管理enterprise bean的創建和移除，一個enterprise bean在其生存周期中將會歷經幾種狀態。容器創建enterprise bean，並在可用實例池與活動狀態中移動他，而最終將其從容器中移除。即使可以調用enterprise bean的create及remove方法，容器也將會在後台執行這些任務。

資料庫連接池（Database Connection Pooling）模型是一個有價值的資源。獲取資料庫連接是一項耗時的工作，而且連接數非常有限。容器通過管理連接池來緩和這些問題。enterprise bean可從池中迅速獲取連接。在bean釋放連接之後可為其他bean使用。

J2EE應用組件可以安裝部署到以下幾種容器中去：

EJB 容器管理所有J2EE 應用程序中企業級bean 的執行。enterprise bean 和它們的容器運行在J2EE 伺服器上。

Web 容器管理所有J2EE 應用程序中JSP頁面和Servlet組件的執行。 Web 組件和它們的容器運行在J2EE 伺服器上。應用程序客戶端容器管理所有J2EE應用程序中應用程序客戶端組件的執行。應用程序客戶端和它們的容器運行在J2EE 伺服器上。Applet 容器是運行在客戶端機器上的web瀏覽器和 Java 插件的結合。

J2EE是Java 2 enterprise edition是Java的一種企業版用於企業級的應用服務開發

J2SE是Java 2 standard edition是Java的標準版，用於標準的應用開發

J2ME是Java 2 Micro Edition是Java的微型版，常用於手機上的開發

J2EE，J2SE，J2ME是java針對不同的的使用來提供不同的服務，也就是提供不同類型的類庫。

J2EE使用多層的分散式應用模型，應用邏輯按功能劃分為組件，各個應用組件根據他們所在的層分佈在不同的機器上。事實上，sun設計J2EE的初衷正是為了解決兩層模式（client/server）的弊端，在傳統模式中，客戶端擔當了過多的角色而顯得臃腫，在這種模式中，第一次部署的時候比較容易，但難於升級或改進，可伸展性也不理想，而且經常基於某種專有的協議，通常是某種資料庫協議。它使得重用業務邏輯和界面邏輯非常困難。現在J2EE 的多層企業級應用模型將兩層化模型中的不同層面切分成許多層。一個多層化應用能夠為不同的每種服務提供一個獨立的層，以下是 J2EE 典型的四層結構：

運行在客戶端機器上的客戶層組件

運行在J2EE伺服器上的Web層組件

運行在J2EE伺服器上的業務邏輯層組件

運行在EIS伺服器上的企業信息系統（Enterprise information system）層軟體

J2EE應用程序組件

J2EE應用程序是由組件構成的.J2EE組件是具有獨立功能的軟體單元，它們通過相關的類和文件組裝成J2EE應用程序，並與其他組件交互。J2EE說明書中定義了以下的J2EE組件：

應用客戶端程序和applets是客戶層組件.

Java Servlet和JavaServer Pages(JSP）是web層組件.

Enterprise JavaBeans(EJB）是業務層組件.

J2EE應用程序可以是基於web方式的，也可以是基於傳統方式的.

J2EE web層組件可以是JSP 頁面或Servlets.按照J2EE規範，靜態的HTML（標準通用標記語言下的一個應用）頁面和Applets不算是web層組件。

正如下圖所示的客戶層那樣，web層可能包含某些 JavaBean 對象來處理用戶輸入，並把輸入發送給運行在業務層上的enterprise bean 來進行處理。

業務層代碼的邏輯用來滿足銀行，零售，金融等特殊商務領域的需要，由運行在業務層上的enterprise bean 進行處理. 下圖表明了一個enterprise bean 是如何從客戶端程序接收數據，進行處理（如果必要的話），併發送到EIS 層儲存的，這個過程也可以逆向進行。

有三種企業級的bean: 會話（session) beans，實體（entity) beans，和消息驅動（message-driven) beans. 會話bean 表示與客戶端程序的臨時交互. 當客戶端程序執行完后，會話bean 和相關數據就會消失. 相反，實體bean 表示資料庫的表中一行永久的記錄. 當客戶端程序中止或伺服器關閉時，就會有潛在的服務保證實體bean 的數據得以保存。消息驅動 bean 結合了會話bean 和 JMS的消息監聽器的特性，允許一個業務層組件非同步接收JMS 消息.

企業信息系統層處理企業信息系統軟體包括企業基礎建設系統例如企業資源計劃(ERP），大型機事務處理，資料庫系統，和其它的遺留信息系統. 例如，J2EE 應用組件可能為了資料庫連接需要訪問企業信息系統。

J2EE平台由一整套服務（Services）、應用程序介面（APIs）和協議構成，它對開發基於Web的多層應用提供了功能支持，下面對J2EE中的13種技術規範進行簡單的描述（限於篇幅，這裡只能進行簡單的描述）：

1:JDBC(Java Database Connectivity)

JDBC API為訪問不同資料庫提供了統一的路徑，像ODBC一樣,JDBC開發者屏蔽了一些細節問題，另外,JDBC對資料庫的訪問也具有平台無關性.

2:JNDI(Java Naming and Directory Interface)

JNDI API 被用於執行名字和目錄服務。它提供了一致的模型來存取和操作企業級的資源DNS和LDAP,本地文件系統，或應用伺服器中的對象.

3:EJB(Enterprise JavaBean)

J2EE技術之所以贏得廣泛重視的原因之一就是EJB.它提供了一個框架來開發和實施分散式商務邏輯，由此很顯著的簡化了具有可伸縮性和高度複雜的企業級應用程序的開發.EJB規範定義了EJB組件在何時如何與它們的容器進行交互作用。容器負責提供公用的服務，例如目錄服務，事務管理，安全性，資源緩衝池以及容錯性。但這裡值得注意的是,EJB並不是實現J2EE的唯一路徑。正是由於J2EE的開放性，使得所有的廠商能夠以一種和EJB平行的方式來達到同樣的目地.

4:RMI(Remote Method Invoke)

遠程方法請求,RMI協議調用遠程對象上的方法。它使用了序列化的方式在客戶端和伺服器之間傳遞數據.RMI是一種被EJB使用的更底層的協議.

5:Java IDL/CORBA(通用對象請求代理架構是軟體構建的一個標準 )

在Java IDL的支持下，開發人員可以將Java和CORBA集成在一起。他們可以創建Java對象並使之可在CORBA ORB中展開，或者他們還可以創建Java類並和其它ORB一起展開的CORBA對象客戶。后一種方法提供了另外一種途徑，通過它Java可以被用於將你的新的應用程序和舊的系統集合在一起.

6:JSP

JSP頁面由HTML（標準通用標記語言下的一個應用）代碼和嵌入其中的Java代碼組成。伺服器在

頁面被客戶端所請求以後對這些Java代碼進行處理，然後將生成的HTML頁面返回給客戶端瀏覽器.

7:Java Servlet

Servlet 是一種小型的Java程序，它擴展了web伺服器的功能。作為一種伺服器的應用，當被請求時開始執行，這和CGI Perl腳本很相似.Servlet提供的功能大多和JSP類似，不過實現的方式不同.JSP通常是大多數的HTML代碼中嵌入少量的Java代碼，而servlet全部由java寫成並且生成HTML.

8:XML

XML（標準通用標記語言的子集）是一種可以用來定其它標記語言的語言。它被用來在不同的商務過程中共享數據.XML的發展和java是相互獨立的，但是，它和java具有的相同目標是平台獨立性.

9:JMS

MS是用於和面向對象消息的中間件相互通信的應用程序介面。它既支持點對點的域，又支持發布/訂閱類型的域，並且提供了下列類型的支持：消息傳遞，事務型消息的傳遞，一致性消息和具有持久性的訂閱者支持.JMS還提供了另一種方式來對新系統和舊後台系統相互集成.

10:JTA

JTA定義了一種標準API,應用程序由此可以訪問各種事務監控.

11:JTS

JTS是CORBA OTS事務監控的基本實現.JTS規定了事務管理的實現方法。該事務管理器是在高層支持java Transaction API規範，並且在較低層次實現OMG OTS specification 和Java對象.JTS事務管理器為應用程序伺服器，資源管理器，獨立的應用以及通信資源管理器提供了事務服務.

12:JavaMail

JavaMail是用於存取郵件伺服器的API,它提供了一套郵件伺服器的抽象類。不僅支持SMTP伺服器，也支持IMAP伺服器.

13:JAF(JavaBeans Activation Framework)

JAVA安全認證框架。提供一些安全控制方面的框架。讓開發者通過各種部署和自定義實現自己的個性安全控制策略。

容器：充當中間件的角色。

WEB容器：給處於其中的應用程序組件（ JSP，SERVLET）提供一個環境，使JSP,SERVLET直接與容器中的環境變數介面交互，不必關注其它系統問題。主要由WEB伺服器來實現。例如：TOMCAT,WEBLOGIC,WEBSPHERE等。該容器提供的介面嚴格遵守J2EE規範中的WEB APPLICATION 標準。我們把遵守以上標準的WEB伺服器就叫做J2EE中的WEB容器。

EJB容器：Enterprise java bean 容器。更具有行業領域特色。他提供給運行在其中的組件EJB各種管理功能。只要滿足J2EE規範的EJB放入該容器，馬上就會被容器進行高效率的管理。並且可以通過現成的介面來獲得系統級別的服務。例如郵件服務、事務管理。

WEB容器和EJB容器在原理上是大體相同的，更多的區別是被隔離的外界環境。WEB容器更多的是跟基於HTTP的請求打交道。而EJB容器不是。它是更多的跟資料庫、其它服務打交道。但他們都是把與外界的交互實現從而減輕應用程序的負擔。例如SERVLET不用關心HTTP的細節，直接引用環境變數session,request,response就行、EJB不用關心資料庫連接速度、各種事務控制，直接由容器來完成。

RMI/IIOP：遠程方法調用internet對象請求中介協議，他們主要用於通過遠程調用服務。例如，遠程有一台計算機上運行一個程序，它提供股票分析服務，我們可以在本地計算機上實現對其直接調用。當然這是要通過一定的規範才能在異構的系統之間進行通信。RMI是JAVA特有的。

JNDI:JAVA命名目錄服務。主要提供的功能是：提供一個目錄系統，讓其它各地的應用程序在其上面留下自己的索引，從而滿足快速查找和定位分散式應用程序的功能。

JMS:JAVA消息服務。主要實現各個應用程序之間的通訊。包括點對點和廣播。

JAVAMAIL:JAVA郵件服務。提供郵件的存儲、傳輸功能。他是編程中實現郵件功能的核心。相當MS中的EXCHANGE開發包。

JTA：JAVA事務服務。提供各種分散式事務服務。應用程序只需調用其提供的介面即可。

JAAS:JAVA安全認證框架。提供一些安全控制方面的框架。讓開發者通過各種部署和自定義實現自己的個性安全控制策略。

EAI:企業應用集成。是一種概念，從而牽涉到好多技術。J2EE技術是一種很好的集成實現。

為了聯繫實際，GOULD基於WEBLOGIC應用伺服器（來自 BEASYSTEMS公司的一種廣為應用的產品）環境來介紹J2EE的這些技術。 JAVA最初是在瀏覽器和客戶端機器中閃亮登場的。當時，很多人質疑它是否適合做伺服器端的開發。隨著對JAVA2平台企業版（J2EE）第三方支持的增多，JAVA被廣泛接納為開發企業級伺服器端解決方案的首選平台之一。

J2EE平台由一整套服務（SERVICES）、應用程序介面（APIS）和協議構成，它對開發基於WEB的多層應用提供了功能支持。在本文中我將解釋支撐J2EE的13種核心技術：JDBC,JNDI,EJBS,RMI,JSP,JAVA SERVLETS,XML,JMS,JAVA IDL,JTS,JTA,JAVA MAIL 和 JAF，同時還將描述在何時、何處需要使用這些技術。當然，我還要介紹這些不同的技術之間是如何交互的。此外，為了讓您更好地感受J2EE的真實應用，我將在WEBLOGIC應用伺服器（來自BEA SYSTEMS公司的一種廣為應用的產品）環境下來介紹這些技術。不論對於WEBLOGIC應用伺服器和J2EE的新手，還是那些想了解J2EE能帶來什麼好處的項目管理者和系統分析員，相信本文一定很有參考價值。

宏觀印象：分散式結構和J2EE

過去，二層化應用--通常被稱為CLIENT/SERVER應用--是大家談論的最多的。在很多情況下，伺服器提供的唯一服務就是資料庫服務。在這種解決方案中，客戶端程序負責數據訪問、實現業務邏輯、用合適的樣式顯示結果、彈出預設的用戶界面、接受用戶輸入等。CLIENT/SERVER結構通常在第一次部署的時候比較容易，但難於升級或改進，而且經常基於某種專有的協議（通常是某種資料庫協議）。它使得重用業務邏輯和界面邏輯非常困難。更重要的是，在WEB時代，二層化應用通常不能體現出很好的伸縮性，因而很難適應INTERNET的要求。

SUN設計J2EE的部分起因就是想解決二層化結構的缺陷。於是J2EE定義了一套標準來簡化N層企業級應用的開發。它定義了一套標準化的組件，並為這些組件提供了完整的服務。J2EE還自動為應用程序處理了很多實現細節，如安全、多線程等。用J2EE開發N層應用包括將二層化結構中的不同層面切分成許多層。一個N層化應用A能夠為以下的每種服務提供一個分開的層：顯示：在一個典型的WEB應用中，客戶端機器上運行的瀏覽器負責實現用戶界面。

動態生成顯示：儘管瀏覽器可以完成某些動態內容顯示，但為了兼容不同的瀏覽器，這些動態生成工作應該放在WEB伺服器端進行，使用JSP、SERVLETS，或者XML（標準通用標記語言下的一個子集可擴展標記語言）和XSL（可擴展樣式表語言）。

業務邏輯：業務邏輯適合用SESSION EJB（後面將介紹）來實現。

數據訪問：數據訪問適合用ENTITY EJB（後面將介紹）和JDBC來實現。

後台系統集成：後台系統的集成可能需要用到許多不同的技術，至於何種最佳需要根據後台系統的特徵而定。

您可能開始詫異：為什麼有這麼多的層？事實上，多層方式可以使企業級應用具有很強的伸縮性，它允許每層專註於特定的角色。例如，讓WEB伺服器負責提供頁面，應用伺服器處理應用邏輯，而資料庫伺服器提供資料庫服務。

由於J2EE建立在JAVA2平台標準版（ J2SE）的 基礎上，所以具備了J2SE的所有優點和功能。包括“編寫一次，到處可用”的可移植性、通過JDBC訪問資料庫、同原有企業資源進行交互的CORBA技術以及一個經過驗證的安全模型。在這些基礎上，J2EE又增加了對EJB（企業級JAVA組件）、JAVA SERVLETS、JAVA伺服器頁面（JSPS）和XML（標準通用標記語言的子集）技術的支持。

分散式結構與WEBLOGIC應用伺服器

J2EE提供了一個框架--一套標準API--用於開發分散式結構的應用，這個框架的實際實現留給了第三方廠商。部分廠商只是專註於整個J2EE架構中的的特定組件，例如APACHE的TOMCAT提供了對JSP和SERVLETS的支持，BEA系統公司則通過其WEBLOGIC應用伺服器產品為整個 J2EE規範提供了一個較為完整的實現。

WEBLOGIC伺服器已使建立和部署伸縮性較好的分散式應用的過程大為簡化。WEBLOGIC和J2EE代理處理了大量常規的編程任務，包括提供事務服務、安全領域、可靠的消息、名字和目錄服務、資料庫訪問和連接池、線程池、負載平衡和容錯處理等。通過以一種標準、易用的方式提供這些公共服務，像WEBLOGIC伺服器這樣的產品造就了具有更好伸縮性和可維護性的應用系統，使其為大量的用戶提供了增長的可用性。

J2EE技術在接下來的部分里，我們將描述構成J2EE的各種技術，並且了解WEBLOGIC伺服器是如何在一個分散式應用中對它們進行支持的。最常用的J2EE技術應該是JDBC、JNDI、EJB、JSP和SERVLETS，對這些我們將作更仔細的考察。

JAVA DATABASE CONNECTIVITY (JDBC)

JDBC API以一種統一的方式來對各種各樣的資料庫進行存取。和ODBC一樣，JDBC為開發人員隱藏了不同資料庫的不同特性。另外，由於JDBC建立在JAVA的基礎上，因此還提供了資料庫存取的平台獨立性。

JDBC定義了4種不同的驅動程序，現分述如下：

類型 1: JDBC-ODBCBRIDGE

在JDBC出現的初期，JDBC-ODBC橋顯然是非常有實用意義的，通過JDBC-ODBC橋，開發人員可以使用JDBC來存取ODBC數據源。不足的是，他需要在客戶端安裝ODBC驅動程序，換句話說，必須安裝MICROSOFT WINDOWS的某個版本。使用這一類型你需要犧牲JDBC的平台獨立性。另外，ODBC驅動程序還需要具有客戶端的控制許可權。

類型 2: JDBC-NATIVE DRIVER BRIDGE

JDBC本地驅動程序橋提供了一種JDBC介面，它建立在本地資料庫驅動程序的頂層，而不需要使用ODBC。JDBC驅動程序將對資料庫的API從標準的JDBC調用轉換為本地調用。使用此類型需要犧牲JDBC的平台獨立性，還要求在客戶端安裝一些本地代碼。

類型 3: JDBC-NETWORK BRIDGE

JDBC網路橋驅動程序不再需要客戶端資料庫驅動程序。它使用網路上的中間伺服器來存取資料庫。這種應用使得以下技術的實現有了可能，這些技術包括負載 均衡、連接緩衝池和數據緩存等。由於第3種類型往往只需要相對更少的下載時間，具有平台獨立性，而且不需要在客戶端安裝並取得控制權，所以很適合於 INTERNET上的應用。

類型 4: PURE JAVA DRIVER

第4種類型通過使用一個純JAVA資料庫驅動程序來執行資料庫的直接訪問。此類型實際上在客戶端實現了2層結構。要在N-層結構中應用，一個更好的做法是編寫一個EJB，讓它包含存取代碼並提供一個對客戶端具有資料庫獨立性的服務。

WEBLOGIC伺服器為一些通常的資料庫提供了JDBC驅動程序，包括ORACLE,SYBASE,MICROSOFT SQLSERVER以及INFORMIX。它也帶有一種JDBC驅動程序用於CLOUDSCAPE，這是一種純JAVA的DBMS，WEBLOGIC伺服器中帶有該資料庫的評估版本。

以下讓我們看一個實例。

JDBC實例在這個例子中我們假定你已經在CLOUDSCAPE中建立了一個PHONEBOOK資料庫，並且包含一個表，名為CONTACT_TABLE ，它帶有2個欄位：NAME 和 PHONE。開始的時候先裝載CLOUDSCAPE JDBC DRIVER，並請求DRIVER MANAGER得到一個對PHONEBOOK CLOUDSCAPE資料庫的連接。通過這一連接，我們可以構造一個STATEMENT 對象並用它來執行一個簡單的SQL查詢。最後，用循環來遍歷結果集的所有數據，並用標準輸出將NAME和PHONE欄位的內容進行輸出。

OK。接著我們來看一看JDBC是如何在企業應用中的進行使用。JDBC在企業級應用中的應用以上實例其實是很基本的，可能有些微不足道。它假定了一個2層結構。在一個多層的企業級應用中，更大的可能是在客戶端和一個EJB進行通信，該EJB將建立資料庫連接。為了實現和改進可伸縮性和系統性能，WEBLOGIC伺服器提供了對連接緩衝池CONNECTION POOL的支持。CONNECTION POOL減少了建立和釋放資料庫連接的消耗。在系統啟動以後即可建立這樣的緩衝池，此後如故再有對資料庫的請求，WEBLOGIC伺服器可以很簡單地從緩 沖池中取出數據。數據緩衝池可以在WEBLOGIC伺服器的WEBLOGIC.PROPERTIES 文件中進行定義。（可參考 WEBLOGIC.PROPERTIES 文件中的例子，WEBLOGIC伺服器的文檔中還有更詳細的參考信息）在企業級應用的另一 個常見的資料庫特性是事務處理。事務是一組申明STATEMENT，它們必須做為同一個STATEMENT來處理以保證數據完整性。預設情況下JDBC使 用 AUTO-COMMIT 事務模式。這可以通過使用CONNECTION類的 SETAUTOCOMMIT() 方法來實現。

現在我們已經對JDBC有了一些認識，下面該轉向JNDI了。

JAVA NAMING AND DIRECTORY INTERFACE (JNDI)

JNDI API被用於執行名字和目錄服務。它提供了一致的模型來存取和操作企業級的資源如DNS和LDAP，本地文件系統，後者在應用伺服器中的對象。

在JNDI中，在目錄結構中的每一個結點稱為CONTEXT。每一個JNDI名字都是相對於CONTEXT的。這裡沒有絕對名字的概念存在。對一個應用來說，它可以通過使用 INITIALCONTEXT 類來得到其第一個CONTEXT:

CONTEXT CTX = NEW INITIALCONTEXT();

應用可以通過這個初始化的CONTEXT經有這個目錄樹來定位它所需要的資源或對象。例如，假設你在WEBLOGIC伺服器中展開了一個EJB並將 HOME介面綁定到名字 MYAPP.MYEJB ，那麼該EJB的某個客戶在取得一個初始化

CONTEXT以後，可以通過以下語句定位HOME介面：

MYEJBHOME HOME = CTX.LOOKUP( "MYAPP.MYEJB" );

在這個例子中，一旦你有了對被請求對象的參考，EJB的HOME介面就可以在它上面調用方法。我們將在下面的"ENTERPRISE JAVA BEANS"章節中做更多的介紹。

以上關於JNDI的討論只是冰山之一角而已。如果要更進一步地在CONTEXT中查找對象，JNDI也提供了一些方法來進行以下操作：

將一個對象插入或綁定到CONTEXT。這在你展開一個EJB的時候是很有效的。

從CONTEXT中移去對象。

列出CONTEXT中的所有對象。

創建或刪除子一級的CONTEXT。

接下來，我們要開始關注EJB了。

ENTERPRISE JAVA BEANS (EJB)

J2EE技術之所以贏得媒體廣泛重視的原因之一就是EJB。它們提供了一個框架來開發和實施分散式商務邏輯，由此很顯著地簡化了具有可伸縮性和高度複雜的企業級應用的開發。EJB規範定義了EJB組件在何時以及如何與它們的容器進行交互作用。容器負責提供公用的服務，例如目錄服務、事務管理、安全性、資源緩衝池以及容錯性。

EJB規範定義了3中基本的BEAN類型：

STATELESS SESSION BEANS: 提供某種單一的服務，不維持任何狀態，在伺服器故障發生時無法繼續存在，生命期相對較短。例如，一個STATELESS SESSION BEAN可能被用於執行溫度轉換計算。

STATEFUL SESSION BEAN: 提供了與客戶端的會話交互，可以存儲狀態從而代表一個客戶。典型例子是購物車。STATEFUL SESSION BEAN在伺服器故障時無法繼續生存，生命期相對較短。每一個實例只用於一個單個的線程

ENTITY BEANS: 提供了一致性數據的表示-- 通常存放在資料庫中 -- 在伺服器故障發生后能繼續存在。多用戶情況下可以使用EJB來表示相同的數據。ENTITY EJB的一個典型例子是客戶的帳號信息。

儘管有以上的區別，所有的EJB還是有許多的共同之處：

它們都處理HOME INTERFACE。它定義了一個客戶端是如何創建與消亡EJB的。

可以在BEAN中對定義了客戶端方法的遠程介面進行調用；

BEAN類則執行了主要的商務邏輯描述

EJB的開發已經超出了本文的範圍。但是，如果一個EJB已經被開發了或者從第三方進行了購買，它就必須在應用伺服器中進行發布。WEBLOGIC SERVER 5.1帶有一個EJB DEPLOYER TOOL來協助處理EJB的發布。當你使用EJB DEPLOYER TOOL的時候，你要定義客戶端所用的JNDI名字來定位EJB。DEPLOYER TOOL將生成WRAPPER類來處理和容器的通信以及在一個JAR文件中把被請求的JAVA類綁定在一起。一旦EJB被發布，客戶端就可以使用它的JNDI名字來定位EJB。

首先，它必須得到一個到HOME介面的REFERENCE。

然後，客戶端可以使用該介面，調用一個 CREATE() 方法來得到伺服器上運行的某個BEAN實例的句柄；

最後，客戶端可以使用該句柄在BEAN中調用方法。

了解 EJB后，讓我們再來看JSP。

JAVA SERVER PAGES (JSPS)

我們中間可能已經有許多人已經熟悉MICROSOFT的ACTIVE SERVER PAGES (ASP）技術了。JSP和ASP相對應的，但更具有平台對立性。他們被設計用以幫助WEB內容開發人員創建動態網頁，並且只需要相對較少的代碼。即使WEB設計師不懂得如何編程也可以使用JSP，因為JSP應用是很方便的。JSP頁面由HTML（標準通用標記語言下的一個應用）代碼和嵌入其中的JAVA代碼所組成。伺服器在頁面被客戶端所請求以後對這些JAVA代碼進行處理，然後將生成的HTML頁面返回給客戶端的瀏覽器。

下面我們來看一個JSP的簡單實例。它只顯示了伺服器的當前日期和時間。雖然，對語法的具體解釋已經超出了本文的範圍，但我們還是可以很直觀地看到，JAVA代碼被放在<%和%>；的中間，而JAVA的表達式則放在<%=和%>；之間。

您可能有時候聽說過JHTML。這是JSP以前的一種較老的標準。WEBLOGIC伺服器既可支持JSP，又可支持JHTML。

請注意，在預設狀況下，JSP在WEBLOGIC伺服器中並沒有處於有效狀態。要使之有效，你可以編輯WEBLOGIC.PROPERTIES文件。如果WEB伺服器還沒有處於有效狀態，則要先使之有效。SERVLET的情況和JSP是一樣的。

下面是：JAVA SERVLETS

JAVA SERVLETS

SERVLET提供的功能大多與JSP類似，不過實現的方式不同。JSP通常是大多數HTML代碼中嵌入少量的JAVA代碼，而SERVLETS全部由JAVA寫成並且生成HTML。

SERVLET是一種小型的JAVA程序，它擴展了WEB伺服器的功能。作為一種伺服器端的應用，當被請求時開始執行，這和CGI PERL腳本很相似。SERVLETS和CGI腳本的一個很大的區別是：每一個CGI在開始的時候都要求開始一個新的進程 -- 而SERVLETS是在SERVLET引擎中以分離的線程來運行的。因此SERVLETS在可伸縮性上提供了很好的改進。在開發SERVLETS的時候，您常常需要擴展JAVA X.SERVLET.HTTP.HTTPSERVLET 類，並且OVERRIDE一些它的方法，其中包括：

SERVICE(): 作為DISPATCHER來實現命令-定義方法

DOGET(): 處理客戶端的HTTP GET請求。

DOPOST(): 進行HTTP POST操作

其它的方法還包括處理不同類型的HTTP請求-- 可以參考HTTPSERVLET API文檔。

以上描述的是標準J2EE SERVLET API的各種方法。WEBLOGIC伺服器提供了一個該API完整的實現途徑。一旦你開發了一個SERVLET，你就可以在 WEBLOGIC.PROPERTIES 中加以註冊並由此可以在WEBLOGIC伺服器中對它進行配置。通過JAVA SERVLETS，我們已經到達了J2EE主要技術的末尾了。但J2EE所提供的並不止於這些。

下面的段落中我們將簡要地看一下現存的一些技術，包括RMI,JAVA IDL和CORBA,JTA，以及XML（標準通用標記語言的子集），等等。

REMOTE METHOD INVOCATION (RMI)

正如其名字所表示的那樣，RMI協議是在遠程對象上調用一些方法。它使用了連續序列方式在客戶端和伺服器端傳遞數據。RMI是一種被EJB使用的更下層的協議。

JAVA IDL/CORBA

在JAVA IDL的支持下，開發人員可以將JAVA和CORBA集成在一起。他們可以創建JAVA對象並使之可在CORBA ORB中展開，或者他們還可以創建JAVA類並作為和其它ORB一起展開的CORBA對象的客戶。后一種方法提供了另外一種途徑，通過它JAVA可以被用於將你的新的應 用和LEGACY系統相集成。

JAVA TRANSACTION ARCHITECTURE (JTA)/JAVA TRANSACTION SERVICE (JTS)

JTA定義了一種標準的API，應用系統由此可以存取各種事務監控。

JTS是CORBA OTS事務監控的基本實現。JTS規定了事務管理器的實現方式。該事務管理器是在高層支持JAVA TRANSACTION API (JTA）規範，並且在較底層實現OMG OTS SPECIFICATION的JAVA映像。JTS事務管理器為應用伺服器、資源管理器、獨立的應用以及通信資源管理器提供了事務服務。

JAVA MAIL AND JAVA BEANS ACTIVATION FRAMEWORK

JAVA MAIL是用於存取郵件伺服器的API，它提供了一套郵件伺服器的抽象類。不僅支持SMTP伺服器，也支持IMAP伺服器JAVA MAIL利用JAVA BEANS ACTIVATION FRAMEWORK (JAF）來處理MIME-編碼的郵件附件。MIME的位元組流可以被轉換成JAVA對象，或者轉換自JAVA對象。由此大多數應用都可以不需要直接使用JAF。

JAVA MESSAGING SERVICE (JMS)

JMS是用於和面向消息的中間件相互通信的應用程序介面（API）。它既支持點對點的域，又支持發布/訂閱（PUBLISH/SUBSCRIBE）類型的域，並且提供對下列類型的支持：經認可的消息傳遞、事務型消息的傳遞、一致性消息和具有持久性的訂閱者支持。JMS還提供了另一種方式來對您的應用與LEGACY BACKEND系統相集成。

XML（標準通用標記語言的子集）

XML是一種可以用來定義其它標記語言的語言。它被用來在不同的商務過程中共享數據。XML的發展和JAVA是相互獨立的，但是，它和JAVA具有的相同目標正是平台獨立性。通過將JAVA和XML的組合，您可以得到一個完美的具有平台獨立性的解決方案。目前正有許多不同的公司在為JAVA和XML的組合而努力。如果要了解更多的這方面的信息，可以訪問SUN的JAVA-XML頁面，或者IBM DEVELOPERWORKS的XML ZONE。

總結

在本文中，我們介紹了建立在J2EE上的分散式應用結構，並且描述了WEBLOGIC伺服器對J2EE的各種支持。然而，我們所揭示的僅僅是冰山之一角而已，要以一篇數千字的文章來展示J2EE潛在的對您的企業級應用的影響可是很不公平的。

我們已經關注了在您開始用J2EE進行工作時最有可能遇到的各類技術：JDBC,JNDI,EJB,JSP和SERVLET。我們也為您提供了一些尚未常見的J2EE技術的背景知識。不管您是一名開發人員，商務應用分析師，或者項目經理，都應該對J2EE和WEBLOGIC伺服器所能提供給我們，給我們的企業以及我們的企業級應用所帶來的意義有一個更好的認識。

J2EE 帶動了Java在企業級的發展，但隨著一些輕量級組件的出現，J2EE的臃腫和開發難度高的缺點越來越引起了許多人的注意，EJB2.0也被許多人稱為累贅。隨著Spring,Hibernate的不斷完善和發展，EJB3.0出現了，成為了未來Java 企業級開發的新的方向。

使用元數據，註釋代替傳統的配置文件成為了新的熱點。JPA更是代替了傳統的CMP作為了更加便捷的持久化的方案。

J2EE事務併發訪問主要可以分為兩類，分別是同一個系統事務和跨事務訪問的併發訪問控制，其中同一個系統事務可以採取樂觀鎖以及悲觀鎖策略，而跨多個系統事務時則需要樂觀離線鎖和悲觀離線鎖。

樂觀鎖是在同一個資料庫事務中我們常採取的策略，因為它能使得我們的系統保持高的性能的情況下，提供很好的併發訪問控制。樂觀鎖，顧名思義就是保持一種樂觀的態度，我們認為系統中的事務併發更新不會很頻繁，即使衝突了也沒事，大不了重新再來一次。它的基本思想就是每次提交一個事務更新時，我們想看看要修改的東西從上次讀取以後有沒有被其它事務修改過，如果修改過，那麼更新就會失敗。

因為樂觀鎖其實並不會鎖定任何記錄，所以資料庫的事務隔離級別設置為讀取已提交或者更低的隔離界別，那麼是不能避免不可重複讀問題的（因為此時讀事務不會阻塞其它事務），所以採用樂觀鎖的時候，系統應該要容許不可重複讀問題的出現。

一般可以採用以下三種方法：

版本（Version）欄位：在我們的實體中增加一個版本控制欄位，每次事務更新后就將版本欄位的值加1.

時間戳（timestamps）：採取這種策略后，當每次要提交更新的時候就會將系統當前時間和實體載入時的時間進行比較，如果不一致，那麼就報告樂觀鎖失敗，從而回滾事務或者重新嘗試提交。採用時間戳有一些不足，比如在集群環境下，每個節點的時間同步也許會成問題，並且如果併發事務間隔時間小於當前平台最小的時鐘單位，那麼就會發生覆蓋前一個事務結果的問題。因此一般採用版本欄位比較好。

基於所有屬性進行檢測：採用這種策略的時候，需要比較每個欄位在讀取以後有沒有被修改過，所以這種策略實現起來比較麻煩，要求對每個屬性都進行比較，如果採用hibernate的話，因為Hibernate在一級緩存中可以進行臟檢測，那麼可以判斷哪些欄位被修改過，從而動態的生成sql語句進行更新。

在JDBC和Hibernate中使用樂觀鎖：

JDBC中使用樂觀鎖：如果我們採用JDBC來實現持久層的話，那麼就可以採用以上將的三種支持樂觀鎖的策略，在實體中增加一個version欄位或者一個Date欄位，也可以採用基於所有屬性的策略，下面就採用version欄位來做一演示：

假如系統中有一個Account的實體類，我們在Account中多加一個version欄位，那麼我們JDBC Sql語句將如下寫：

Select a.version....from Account as a where (where condition..)

Update Account set version = version+1.....(another field) where version =?...(another contidition)

可以通過更新結果的行數來進行判斷，如果更新結果的行數為0，那麼說明實體從載入以來已經被其它事務更改了，所以就拋出自定義的樂觀鎖定異常（或者也可以採用Spring封裝的異常體系）。具體實例如下：

在使用JDBC API的情況下，需要在每個update語句中，都要進行版本欄位的更新以及判斷，因此如果稍不小心就會出現版本欄位沒有更新的問題，相反當前的 ORM框架卻為我們做好了一切，需要做的就是在每個實體中都增加version或者是Date欄位。

Hibernate中使用樂觀鎖：如果採用Hibernate做為持久層的框架，那麼實現樂觀鎖將變得非常容易，因為框架會幫我們生成相應的sql語句，不僅減少了開發人員的負擔，而且不容易出錯。下面同樣採用version欄位的方式來總結一下：

同樣假如系統中有一個Account的實體類，我們在Account中多加一個version欄位，

提交事務時，hibernate內部會生成相應的SQL語句將版本欄位加1，並且進行相應的版本檢測，如果檢測到併發樂觀鎖定異常，那麼就拋出StaleObjectStateException.

所謂悲觀鎖，顧名思義就是採用一種悲觀的態度來對待事務併發問題，系統中的併發更新會非常頻繁，並且事務失敗了以後重來的開銷很大，這樣就需要採用真正意義上的鎖來進行實現。悲觀鎖的基本思想就是每次一個事務讀取某一條記錄后，就會把這條記錄鎖住，這樣其它的事務要想更新，必須等以前的事務提交或者回滾解除鎖。

最後還是需要明確一個問題，假如資料庫事務的隔離級別設置為讀取已提交或者更低，那麼通過悲觀鎖，控制了不可重複讀的問題，但是不能避免幻影讀的問題（因為要想避免我們就需要設置資料庫隔離級別為Serializable，而一般情況下會採取讀取已提交或者更低隔離級別，並配合樂觀或者悲觀鎖來實現併發控制，所以幻影讀問題是不能避免的，如果想避免幻影讀問題，那麼只能依靠資料庫的serializable隔離級別（幸運的是幻影讀問題一般情況下不嚴重）。

下面就分別以JDBC和Hibernate來總結一下：

JDBC中使用悲觀鎖：在JDBC中使用悲觀鎖，需要使用select for update語句，假如我們系統中有一個Account的類，我們可以採用如下的方式來進行：

Select * from Account where ...(where condition).. for update.

當使用了for update語句后，每次在讀取或者載入一條記錄的時候，都會鎖住被載入的記錄，那麼當其他事務如果要更新或者是載入此條記錄就會因為不能獲得鎖而阻塞，這樣就避免了不可重複讀以及臟讀的問題，但是其他事務還是可以插入和刪除記錄，這樣也許同一個事務中的兩次讀取會得到不同的結果集，但是這不是悲觀鎖所造成的問題，這是資料庫隔離級別所造成的問題。

最後還需要注意的一點就是每個衝突的事務中，必須使用select for update 語句來進行資料庫的訪問，如果一些事務沒有使用select for update語句，那麼就會很容易造成錯誤，這也是採用JDBC進行悲觀控制的缺點。

Hibernate中使用悲觀鎖：相比於JDBC使用悲觀鎖來說，在Hibernate中使用悲觀鎖將會容易很多，因為Hibernate有API讓我們來調用，從而避免直接寫SQL語句。下面就Hibernate使用悲觀鎖做一總結：

首先先要明確一下Hibernate中支持悲觀鎖的兩種模式LockMode.UPGRADE以LockMode.UPGRADE_NO_WAIT.(PS：在JPA中，對應的鎖模式是LockModeType.Read，這與Hibernate是不一樣的呵呵）

假如系統中有一個Account的類，那麼具體的操作可以像這樣：

或者也可以採用如下方式來載入對象：

這樣以來當載入對象時，hibernate內部會生成相應的select for update語句來載入對象，從而鎖定對應的記錄，避免其它事務併發更新。

目前，Java 2平台有3個版本，它們是適用於小型設備和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、適用於桌面系統的Java 2平台標準版（Java 2 Platform Standard Edition，J2SE）、適用於創建伺服器應用程序和服務的Java 2平台企業版（Java 2 Platform Enterprise Edition，J2EE）。J2EE是一種利用Java 2平台來簡化企業解決方案的開發、部署和管理相關的複雜問題的體系結構。J2EE技術的基礎就是核心Java平台或Java 2平台的標準版，J2EE不僅鞏固了標準版中的許多優點，例如"編寫一次、隨處運行"的特性、方便存取資料庫的JDBC API、CORBA技術以及能夠在Internet應用中保護數據的安全模式等等，同時還提供了對 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML（標準通用標記語言的子集）技術的全面支持。其最終目的就是成為一個能夠使企業開發者大幅縮短投放市場時間的體系結構。

J2EE體系結構提供中間層集成框架用來滿足無需太多費用而又需要高可用性、高可靠性以及可擴展性的應用的需求。通過提供統一的開發平台，J2EE降低了開發多層應用的費用和複雜性，同時提供對現有應用程序集成強有力支持，完全支持Enterprise JavaBeans，有良好的嚮導支持打包和部署應用，添加目錄支持，增強了安全機制，提高了性能。

J2EE是由 SUN公司開發的一套企業級應用規範。2009年04月20日，甲骨文74億美元收購Sun。取得java的版權。2011年7月，甲骨文公司發布java7的正式版。支持J2EE的應用伺服器有IBM WebSphere Application Server,Oracle Weblogic SERVER,Jboss,SUN GlassFish，東方通 TongWeb等。

在舊金山舉行的2011年JavaOne大會上，甲骨文公司展示了其推動Java 平台企業版（Java EE）發展的最新成果。

Java EE 繼續大受歡迎，並有越來越多的開發人員採用，包括Oracle GlassFish Server在內的Java EE組件獲得了4000萬次下載。

自2009年12月推出以來，6個主要IT廠商已經推出了經過認證、開源和商業實施的Java EE 6，使其成為迄今為止最迅速獲得採用的平台產品。

作為下一代Java EE, Java EE 7進展順利，其中，有超過20個的不同參與企業和數百名工程師通過Java 社區（JCP）對10個活躍的Java規範要求(JSRs)進行了開發處理。

Java EE 7 JSRs 包括：Java EE 7 平台, Java Persistence API 2.1, JAX-RS 2.0: 用於RESTful網路服務的 Java API, Servlet 3.1, 表達語言 3.0, Java 信息服務 2.0, JavaServer Faces 2.2, Enterprise JavaBeans 3.2, 面向Java EE 1.1的Contexts and Dependency Injection , Bean Validation 1.1.等。

Java EE 7專家組也在尋求把其他JSRs加入到Java EE 7的可能性，這些JSRs包括JCache 1.0 – Java Temporary Caching API, Concurrency Utilities 1.0, Java 狀態管理 1.0 和Java Identity API 1.0。

Java EE 7旨在進一步增強Java EE平台的雲環境。因此，基於Java EE-7的應用和產品將能夠在私有雲和公有雲中更方便地操作，並通過支持多用戶租用和彈性使用（如平行擴展）等功能來實現功能即服務。

作為Java EE的參考實施，GlassFish伺服器不僅僅是全面的Java EE 6實施，（開源版是GlassFish 伺服器開源版，商業版是Oracle GlassFish伺服器），還為即將推出的Java EE 7提供了堅實的基礎。

Oracle GlassFish伺服器完善了Oracle WebLogic 伺服器 11g，後者是一款專門為運行Oracle 融合中間件11g的廣泛產品組合以及可內部部署和雲部署的大規模企業應用而設計的伺服器。

甲骨文在2011 年JavaOne大會的136個聯合研討會、BOF和動手實驗室，以及JavaOne展覽館中對Java EE及相關技術進行了展示。

從整體上講，J2EE是使用Java技術開發企業級應用的一種事實上的工業標準(Sun公司出於其自身利益的考慮，至今沒有將Java及其相關技術納入標準化組織的體系)，它是Java技術不斷適應和促進企業級應用過程中的產物。目前，Java平台有三個版本：適用於小型設備和智能卡的J2ME(Java 2 Platform Micro Edition)、適用於桌面系統的J2SE和適用於企業級應用的J2EE。Sun推出J2EE的目的是為了克服傳統Client/Server模式的弊病，迎合Browser/Server架構的潮流，為應用Java技術開發伺服器端應用提供一個平台獨立的、可移植的、多用戶的、安全的和基於標準的企業級平台，從而簡化企業應用的開發、管理和部署。J2EE是一個標準，而不是一個現成的產品。各個平台開發商按照J2EE規範分別開發了不同的J2EE應用伺服器，J2EE應用伺服器是J2EE企業級應用的部署平台。由於它們都遵循了J2EE規範，因此，使用J2EE技術開發的企業級應用可以部署在各種J2EE應用伺服器上。