用J2EE開發N層應用

 翻譯：布老虎

基於BEA WebLogic應用伺服器，提供對J2EE介紹

內容簡介
Steven Gould在文中介紹了Java2平台企業版（J2EE）的13種核心技術：JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail 和 JAF。為了聯絡實際，Gould基於WebLogic應用伺服器—來自BEA Systems公司的一種廣為應用的產品—環境來介紹J2EE的這些技術。

　 Java最初是在瀏覽器和用戶端機器中粉墨登場的。當時，很多人質疑它是否適合做伺服器端的開發。現在，隨著對Java2平台企業版（J2EE）第三方支援的增多，Java被廣泛接納為開發企業級伺服器端解決方案的首選平台之一。
J2EE平台由一整套服務（Services）、應用程式介面（APIs）和協議構成，它對開發基於Web的多層應用提供了功能支援。
在本文中我將解釋支撐J2EE的13種核心技術：JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail 和 JAF，同時還將描述在何時、何處需要使用這些技術。當然，我還要介紹這些不同的技術之間是如何互動的。
此外，為了讓您更好地感受J2EE的真實應用，我將在WebLogic應用伺服器—來自BEA Systems公司的一種廣為應用的產品—環境下來介紹這些技術。不論對於WebLogic應用伺服器和J2EE的新手，還是那些想瞭解J2EE能帶來什麼好處的專案管理者和系統分析員，相信本文一定很有參考價值。

宏觀印象: 分布式結構和J2EE

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

圖1. 二層化應用結構

Sun設計J2EE的部分起因就是想解決二層化結構的缺陷。於是，J2EE定義了一套標準來簡化N層企業級應用的開發。它定義了一套標準化的組件，並為這些組件提供了完整的服務。J2EE還自動為應用程式處理了很多實現細節，如安全、多線程等。

用J2EE開發N層應用程式套件括將二層化結構中的不同層面切分成許多層。一個N層化應用A能夠為以下的每種服務提供一個分開的層：

顯示：在一個典型的Web應用中，用戶端機器上啟動並執行瀏覽器負責實現使用者介面。
動態產生顯示: 儘管瀏覽器可以完成某些動態內容顯示，但為了相容不同的瀏覽器，這些動態產生工作應該放在Web伺服器端進行，使用JSP、Servlets，或者XML（可延伸標記語言 (XML)）和（可延伸樣式表語言 (XSL)）。
商務邏輯：商務邏輯適合用Session EJBs（後面將介紹）來實現。
資料訪問：資料訪問適合用Entity EJBs（後面將介紹）和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代你處理了大量常規的編程任務，包括提供事務服務、安全領域、可靠的訊息、名字和目錄服務、資料庫訪問和串連池、線程池、Server Load Balancer和容錯處理等。

通過以一種標準、易用的方式提供這些公用服務，象WebLogic伺服器這樣的產品造就了具有更好伸縮性和可維護性的應用系統，使其為大量的使用者提供了增長的可用性。

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

圖2表示了在一個分布式應用中，J2EE技術的各個方面通常在何處發揮作用。

圖2. 一個N層應用結構的例子

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欄位的內容進行輸出。

import java.sql.*;

public class JDBCExample
{
public static void main( String args[] )
{
try
  {
  Class.forName("COM.cloudscape.core.JDBCDriver");
  Connection conn = DriverManager.getConnection("jdbc:cloudscape:PhoneBook");
  Statement stmt = conn.createStatement();
  String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BY name";
  ResultSet resultSet = stmt.executeQuery( sql );

  String name;
  String phone;
  while ( resultSet.next() )
   {
   name = resultSet.getString(1).trim();
   phone = resultSet.getString(2).trim();
   System.out.println( name + ", " + phone );
   }
  }
catch ( Exception e )
  {
  // Handle exception here
  e.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: T提供了與用戶端的會話互動，可以儲存狀態從而代表一個客戶。典型例子是購物車。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。

JavaServer Pages (JSPs)
我們中間可能已經有許多人已經熟悉Microsoft的Active Server Pages (ASP)技術了。JSP和ASP相對應的，但更具有平台對立性。他們被設計用以協助Web內容開發人員建立動態網頁，並且只需要相對較少的代碼。即使Web設計師不懂得如何編程也可以使用JSP，因為JSP應用是很方便的。 JSP頁面由HTML代碼和嵌入其中的Java代碼所組成。伺服器在頁面被用戶端所請求以後對這些Java代碼進行處理，然後將產生的HTML頁面返回給用戶端的瀏覽器。
下面我們來看一個JSP的簡單一實例。它只顯示了伺服器的當前日期和時間。雖然，對文法的具體解釋已經超出了本文的範圍，但我們還是可以很直觀地看到， Java代碼被放在 <% 和 %> 符號的中間，而Java的運算式則放在 <%= 和 %> 符號之間。

<html>
<head>
<title>Sample JSP Page</title>
</head>
<body>
<h1>Date JSP sample</h1>

<h2>
<% response.setHeader("Refresh", 5); %>
The current date is <%= new Date() %>.
</h2>

</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的時候，您常常需要擴充javax.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交易管理員為應用伺服器、資源管理員、獨立的應用以及通訊資源管理員提供了事務服務。

JavaMail and JavaBeans Activation Framework
JavaMail是用於存取郵件伺服器的API，它提供了一套郵件伺服器的抽象類別。不僅支援SMTP伺服器，也支援IMAP伺服器。

JavaMail利用JavaBeans Activation Framework (JAF)來處理MIME-編碼的郵件附件。MIME的位元組流可以被轉換成Java對象，或者轉換自Java對象。由此大多數應用都可以不需要直接使用JAF。

Java Messaging Service (JMS)
JMS是用於和面向訊息的中介軟體相互連信的應用程式介面(API)。它既支援點對點的域，有支援發布/訂閱(publish/subscribe)類型的域，並且提供對下列類型的支援：經認可的訊息傳遞,事務型訊息的傳遞，一致性訊息和具有持久性的訂閱者支援。JMS還提供了另一種方式來對您的應用與 legacy backend系統相整合。

Extensible Markup Language (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伺服器所能提供給我們，給我們的企業以及我們的企業級應用所帶來的意義有一個更好的認識。

palatum edited on 2002-11-04 13:25