J2EE的13種核心技術

J2EE(Java 2 Platform, Enterprise Edition)是一個為大企業主機級的計算型別而設計的Java平臺。Sun微系統(與其工業夥伴一起，例如IBM)設計了J2EE，以此來簡化在瘦客戶級環境下的應用開發。下面是小編整理的關於J2EE的13種核心技術，歡迎大家參考!

一、巨集觀印象: 分散式結構和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-ODBC BRIDGE

在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 SQL SERVER以及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伺服器的ERTIES 檔案中進行定義。(可參考 ERTIES 檔案中的例子，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介面繫結到名字 B ，那麼該EJB的某個客戶在取得一個初始化

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

MYEJBHOME HOME = UP( "B" );

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