J2EE是一套全然不同於傳統套用開發的技術架構，包含許多組件，主要可簡化且規範套用系統的開發與部署，進而提高可移植性、安全與再用價值。
J2EE核心是一組技術規範與指南，其中所包含的各類組件、服務架構及技術層次，均有共同的標準及規格，讓各種依循J2EE架構的不同平台之間，存在良好的兼容性，解決過去企業後端使用的信息產品彼此之間無法兼容，企業內部或外部難以互通的窘境。
J2EE組件和“標準的” Java類的不同點在於：它被裝配在一個J2EE套用中，具有固定的格式並遵守J2EE規範，由J2EE伺服器對其進行管理。J2EE規範是這樣定義J2EE組件的：客戶端應用程式和applet是運行在客戶端的組件；Java Servlet和Java Server Pages (JSP) 是運行在伺服器端的Web組件；Enterprise Java Bean (EJB )組件是運行在伺服器端的業務組件。
基本介紹
- 中文名：Java2平台企業版
- 外文名：Java 2 Platform Enterprise Edition
- 簡稱：J2EE
- 功能：提高可移植性、安全與再用價值
簡介,發展背景,優勢,結構,容器類型,區別,四層模型,客戶層組件,web 層組件,業務層組件,信息系統層,組件標準規範,名詞解釋,核心技術,控制策略,樂觀鎖,悲觀鎖,發展狀況,發展趨勢,組合框架,
簡介
J2EE（Java 2 Platform, Enterprise Edition）是一個為大企業主機級的計算類型而設計的Java平台。Sun微系統（與其工業夥伴一起，例如IBM）設計了J2EE，以此來簡化在受客戶級環境下的套用開發。由於創造了標準的可重用模組組件以及由於構建出能自動處理編程中多方面問題的等級結構，J2EE簡化了應用程式的開發，也降低了對編程和對受訓的程式設計師的要求。
發展背景
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. 高效的開發：
o 狀態管理服務 -- 讓開發人員寫更少的代碼，不用關心如何管理狀態，這樣能夠更快地完成程式開發。
o 持續性服務 -- 讓開發人員不用對數據訪問邏輯進行編碼就能編寫應用程式，能生成更輕巧，與資料庫無關的應用程式，這種應用程式更易於開發與維護。
o 分散式共享數據對象CACHE服務 -- 讓開發人員編制高性能的系統，極大提高整體部署的伸縮性。
3. 支持異構環境：
J2EE能夠開發部署在異構環境中的可移植程式。基於J2EE的應用程式不依賴任何特定作業系統、中間件、硬體。因此設計合理的基於J2EE的程式只需開發一次就可部署到各種平台。這在典型的異構企業計算環境中是十分關鍵的。J2EE標準也允許客戶訂購與J2EE兼容的第三方的現成的組件，把他們部署到異構環境中，節省了由自己制訂整個方案所需的費用。
4. 可伸縮性：
企業必須要選擇一種伺服器端平台，這種平台應能提供極佳的可伸縮性去滿足那些在他們系統上進行商業運作的大批新客戶。基於J2EE平台的應用程式可被部署到各種作業系統上。例如可被部署到高端UNIX與大型機系統，這種系統單機可支持64至256個處理器。（這是NT伺服器所望塵莫及的）J2EE領域的供應商提供了更為廣泛的負載平衡策略，能消除系統中的瓶頸，允許多台伺服器集成部署。這種部署可達數千個處理器，實現可高度伸縮的系統，滿足未來商業套用的需要。
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方式的，也可以是基於傳統方式的.
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 訊息.
信息系統層
組件標準規範
J2EE平台由一整套服務（Services）、應用程式接口（APIs）和協定構成，它對開發基於Web的多層套用提供了功能支持，下面對J2EE中的13種技術規範進行簡單的描述（限於篇幅，這裡只能進行簡單的描述）：
1:JDBC(Java Database Connectivity)
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
頁面被客戶端所請求以後對這些Java代碼進行處理,然後將生成的HTML頁面返回給客戶端瀏覽器.
7:Java Servlet
Servlet 是一種小型的Java程式,它擴展了web伺服器的功能.作為一種伺服器的套用,當被請求時開始執行,這和CGI Perl腳本很相似.Servlet提供的功能大多和JSP類似,不過實現的方式不同.JSP通常是大多數的HTML代碼中嵌入少量的Java代碼,而servlet全部由java寫成並且生成HTML.
8:XML
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特有的。
JMS:JAVA訊息服務。主要實現各個應用程式之間的通訊。包括點對點和廣播。
JAVAMAIL:JAVA郵件服務。提供郵件的存儲、傳輸功能。他是編程中實現郵件功能的核心。相當MS中的EXCHANGE開發包。
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
類型 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欄位的內容進行輸出。
importjava.sql.*;publicclassjdbcexample{publicstaticvoidmain(stringargs[]){try{class.forname("com.cloudscape.core.jdbcdriver");connectionconn=drivermanager.getconnection("jdbc:cloudscape:phonebook");statementstmt=conn.createstatement();stringsql="selectname,phonefromcontact_tableorderbyname";resultsetresultset=stmt.executequery(sql);stringname;stringphone;while(resultset.next()){name=resultset.getstring(1).trim();phone=resultset.getstring(2).trim();system.out.println(name+","+phone);}}catch(exceptione){//handleexceptionheree.printstacktrace();}}}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的表達式則放在<%=和%>；之間。
<html><head><title>SampleJSPPage</title></head><body><h1>DateJSPsample</h1><%response.setHeader("Refresh",5);%>Thecurrentdateis<%=newDate()%>.</body></html>您可能有時候聽說過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所提供的並不止於這些。
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的發展和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作為了更加便捷的持久化的方案。
控制策略
樂觀鎖
樂觀鎖是在同一個資料庫事務中我們常採取的策略，因為它能使得我們的系統保持高的性能的情況下，提供很好的並發訪問控制。樂觀鎖，顧名思義就是保持一種樂觀的態度，我們認為系統中的事務並發更新不會很頻繁，即使衝突了也沒事，大不了重新再來一次。它的基本思想就是每次提交一個事務更新時，我們想看看要修改的東西從上次讀取以後有沒有被其它事務修改過，如果修改過，那么更新就會失敗。
因為樂觀鎖其實並不會鎖定任何記錄，所以資料庫的事務隔離級別設定為讀取已提交或者更低的隔離界別，那么是不能避免不可重複讀問題的（因為此時讀事務不會阻塞其它事務），所以採用樂觀鎖的時候，系統應該要容許不可重複讀問題的出現。
一般可以採用以下三種方法：
時間戳（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封裝的異常體系）。具體實例如下：
.......introwsUpdated=statement.executeUpdate(sql);If(rowsUpdated==0){throwsnewOptimisticLockingFailureException();}........在使用JDBC API的情況下，需要在每個update語句中，都要進行版本欄位的更新以及判斷，因此如果稍不小心就會出現版本欄位沒有更新的問題，相反當前的 ORM框架卻為我們做好了一切，需要做的就是在每個實體中都增加version或者是Date欄位。
Hibernate中使用樂觀鎖：如果採用Hibernate做為持久層的框架，那么實現樂觀鎖將變得非常容易，因為框架會幫我們生成相應的sql語句，不僅減少了開發人員的負擔，而且不容易出錯。下面同樣採用version欄位的方式來總結一下：
同樣假如系統中有一個Account的實體類，我們在Account中多加一個version欄位，
publicclassAccount{Longid;.......@Version//也可以採用XML檔案進行配置Intversion.......}提交事務時，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的類，那么具體的操作可以像這樣：
......session.lock(account,LockMode.UPGRADE);......
或者也可以採用如下方式來載入對象：
session.get(Account.class,identity,LockMode.UPGRADE).
這樣以來當載入對象時，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套用伺服器上。
