作者：老好人
日期：2000-11-30 18:24:24


什么是 Enterprise JavaBeans 組件？
第一部分：EJB 體系結構的歷史和目標


 
 
 
本文概述 Enterprise JavaBeans (EJB) 技術，旨在讓讀者快速理解基本概念。第 1 部分講述 EJB 技術的歷史和某些目標、優點和技術。為了簡潔明了，有選擇地講述 EJB 技術的一些關鍵要素。請注意，雖然 EJB 組件依賴于一些基礎的 Java 服務（如 Java Transaction Service），但使用 EJB 組件及認識這些組件的好處并不需要掌握這些相關技術的知識。
Enterprise JavaBeans 技術自 1998 年 3 月問世以來很受好評。下面這段話就是一個例子： 


“自從兩年多以前問世以來，Enterprise JavaBeanstm 技術在平臺供應商和企業的開發小組中，同樣都保持著空前的發展勢頭。這是因為 EJBtm 的服務器端組件模型簡化了中間件組件的開發，這些中間組件都是事務性的、可伸縮的和可移植的。Enterprise JavaBeans 服務器通過為中間件服務（如事務處理、安全性、數據庫連接及其他）提供自動支持，降低了開發中間件的復雜程度。”（Sun Microsystems 網站）

Enterprise JavaBeans 這一名稱利用了 Java bean — 這種可移植、可重用的 Java 軟件組件的聲望。Enterprise JavaBeans 技術把 Java 組件的概念從客戶機域擴展到了服務器域：這是 Java 技術成長過程中有重大意義的一步，它使 Java 技術發展成為一種強健的、可伸縮的環境，能夠支持以任務為關鍵的企業信息系統。

服務器上的 Java 應用程序 
Java 編程語言最初在 Web 開發人員中獲得好評的一個原因是，它支持稱為 applet 的可下載 Java 程序。對 Applet 的支持以 Applet 類的形式內置到了 1.0 版的 Java Development Kit (JDK) 中。按照 1.0 版的時間框架，Java 開發是以 applet 和應用程序作為中心的。基于 JDK 1.0 版的 Java 讀物都是從 applet 和應用程序的角度來描述 Java 編程的：


“Java 程序由更多的類定義中的某一個組成，每個類定義均已編譯成它自已的 Java 虛擬機對象代碼的 .class 文件。這些類之一必須定義一個叫做 main() 的方法，程序就是從這個方法開始運行的。想調用一個 Java 程序，需要運行 Java 解釋器 java，并指定包含 main() 方法的類的名稱。請注意 Java applet 并不是一個應用程序 — 它是一個由已在運行的 Java 應用程序（如 Web 瀏覽器或 applet 查看器）裝入并運行的 Java 類。”（見 Flanagan 所著的 Java in a Nutshell）

Java 應用程序可以在服務器上運行，但是不管是在客戶機-服務器環境下，還是在基于 Web 的環境下，JDK 中都沒有提供讓 Java 應用程序專用于服務器機器的接口或包。認識到 Java 在 Web 環境下作為一種服務器語言的潛力，Sun Microsystems 編寫了 Java Servlet 規范。servlet 在許多方面與 applet 相似，它是專門為在 Web 服務器機器上運行而設計的 Java 程序：


“servlet 是由容器管理的 Web 組件，可產生動態內容。servlet 是一種小型的、與平臺無關的 Java 類，被編譯成體系結構中立的字節代碼，這種代碼可以動態地加載到一個 web 服務器上，并由此 web 服務器運行。servlet 通過一種由 servlet 容器實現的請求-響應模型與 Web 客戶機進行交互。這種請求-響應模型建立在超文本傳輸協議 (HTTP) 行為的基礎之上。”（見 JavaSoft 的“Java Servlet API Specification”）

在一臺 Web 服務器控制下，在多臺服務器上運行若干小型用戶程序，這種想法并不新鮮 — 一段時間以來，公共網關接口 (CGI) 程序（常被稱為 CGI 腳本）一直起著這種作用，并推動了 Web 的普及。但 Java servlet 可以以更高的效率和可移植性來實現這一目的，因而可望最終會取代 CGI 程序。為 servlet 提供運行時環境的軟件（通常被稱為 servlet 引擎）可以添加到現有的、本身并不支持 Java 可執行程序的 Web 服務器上。

Java servlet 的出現，為應用程序員使用 Java 來創建 Web 應用程序開辟了新的途徑。但是，僅有 servlet 還不能為真正的企業計算提供完整的模型。CGI 應用程序本身往往不是完整的應用程序，在處理接收自 Web 瀏覽器上用戶的信息請求時，CGI 只是整個處理過程中的一個中間步驟。例如，CGI 應用程序的一種常見用途是訪問數據庫。將它用于這種任務時，CGI 程序提供一種方法，將用戶的數據請求連接到能滿足這種請求的企業數據庫。CGI 程序常常充當一種中間軟件，從 Web 瀏覽器接收請求，決定必須調用哪些計算資源來滿足這些請求，并向瀏覽器發回響應。Java servlet 與 CGI 程序一樣，最適合充當連接前端 Web 請求與后端數據資源的中間層組件。

三層體系結構 
Web 編程向服務器端 Java 應用程序的演化，也帶來了體系結構的演化，使它脫離了常規的客戶機-服務器兩層模型，而向一種三層方法發展。兩層模型當時曾經具有創新意義，因為它將一些計算任務從主處理器上卸載到靈巧的客戶機。常規的基于 LAN 的數據庫應用程序就是一個例子，其中數據庫管理器服務器軟件駐留在一個專用的服務器機器上，而用戶則通過他們的工作站上的客戶機代碼來訪問數據庫。隨著客戶機-服務器模型成長到能付諸使用，就出現了對服務器可伸縮性和對客戶機代碼大小和復雜性的關注。于是提出了一種三層的體系結構，以避免在兩層模型中已察覺到的弱點，使 Web 能成為一個計算平臺：


“許多人...斷言，傳統的客戶機/服務器兩層體系結構不會有好的可伸縮性，因為用戶連接和數據訪問的數量無法預測，而且在一些系統管理上也存在問題。為處理兩層體系結構的限制，許多開發集體都在轉向三層體系結構。這種體系結構大致可以定義為：客戶機層上的表示層、中間的服務器和后端的某種數據庫。這種設想的目的就是緩和客戶機或數據庫服務器上的代碼膨脹，集中管理業務邏輯，更靈活地使用數據庫，而不僅是使用所存儲的過程和觸發器。”（見 Kim 的“Looking for a 3-Tier App Builder?”）

一個三層結構模型通常被想像成有一個 Web 瀏覽器作為客戶層。Web 瀏覽器由于有可能成為一種真正的通用客戶機，使它從觀念上取代了兩層結構的“胖客戶機”。如果瀏覽器作為 Web 應用程序體系結構的標準瘦客戶機獲得認可，那么以前駐留在兩層模型的胖客戶機中的功能會怎么樣呢？現在，應用程序專用的功能并不移植回服務器（例如數據庫管理器），而是有意將它駐留在一個新的中間層上。中間層支持應用程序服務器軟件，這種軟件是中間件的一種形式，它處于第一層上瘦客戶機的最小功能和第三層上服務器端業務系統的豐富功能之間。由于三層體系結構與 Web 處理模型有密切關系，所以中間層應用程序服務器常被視為 Web 服務器的一種功能擴展。現有的 Web 應用程序利用 CGI 程序，將來自 Web 瀏覽器的用戶請求傳送到不基于 Web 的業務系統，并向瀏覽器返回響應，就是三層模型的一種實現。這些應用程序逐漸向 servlet 技術的轉移說明三層模型正在增強。

JavaBeans 組件 
JavaBeans 規范將“組件軟件”的概念引入到 Java 編程的領域。組件是自含的、可重用的軟件單元；而 JavaBeans 組件，則可以使用可視的應用程序開發工具，可視地將它們編寫到 Java 程序中。JavaBeans 規范為 Java 開發人員提供了一種“組件化”其 Java 類的方法： 


Bean 是一些 Java 類，可在一個可視的構建器工具中操作它們，并且可以將它們一起編寫到應用程序中。任何具有某種特性和事件接口約定的 Java 類都可以是一個 Bean。（見 JavaSoft，“Using the Beans Development Kit 1.0”） 

如果軟件重用是一個好主意，那么是否應該讓每一個 Java 類都成為 Java bean 呢？如果 Java 類滿足某些準則，它們就適于充當 bean 的角色：


在開發任何新軟件之前，都值得考慮是否用 JavaBean 的形式來開發它。如果軟件模塊要既能夠可視地操作，又能夠定制以達到某些效果，則這種軟件模塊就可能適于做成一個 JavaBean。為幫助您確定要開發的軟件是否應該是一個 JavaBean，假定它應該是用 Java 編寫的，請向您自已提出以下問題，并相應地作出決定：

是否打算讓它可重用？或者，它會是可重用的嗎？ 
是否希望將它與其他可重用的 Java 組件一起使用？ 
是否預計會在 IDE 工具中使用它？ 

如果上述問題的答案都是肯定的，則它應該作為 JavaBean 來開發。（見 developerWorks 的“JavaBeans Guidelines”）

JavaBean 概念是為了在 Java 編程環境中支持可重用的組件，它是一種一般性的設計方法，適用于客戶機或服務器機器上運行的 Java 程序。由于對可視的構建器工具的強調，也由于許多 Java bean 都是圖形用戶界面 (GUI) 組件，所以 JavaBean 組件可能被視為一種客戶端技術。但是，并不要求 Java bean 都是可視的，并且它們也可以用于服務器環境中。

編碼為 Java bean 的 Java 類通常具有以下特征：

使用設計模式。這些模式就是方法和接口的編碼約定。 
支持可視的軟件開發工具。類必須將變量（稱為屬性）、方法和事件展示出來。 
可以定制。定制包括能支持缺省的屬性編輯器，或者提供單一的定制規則。定制使開發人員得以在不更改源代碼的情況下更改 bean 的行為。 
支持自省 (introspection)。這指的是將屬性、方法和事件公開給其他類，可以通過設計模式或通過創建 BeanInfo 類來完成這種自省。 
是持久的。這就允許在一個可視構建器中定制一個 bean，然后以其定制后的狀態加以保存。
Java 2 Platform, Enterprise Edition 
Sun Microsystems 發起了一項稱為 Java 2 Platform, Enterprise Edition (J2EE) 的技術創新，旨在將 Java 平臺的范圍擴展到大規模服務器環境：


“1997 年 4 月 12 日，Sun 宣布了一項為企業環境開發 Java 平臺的創新成果。使用開放式的 Java Community Process，Sun 促進了一組標準的 Java 擴展的開發，稱為 Enterprise Java API。這些應用程序編程接口 (API) 為各種各樣的中間件的實現提供了不依賴供應商的編程接口。Enterprise Java API 的要點是 Enterprise JavaBeans API，后者為 Java 應用程序服務器定義了一個服務器端組件模型，以及一個不依賴供應商的編程接口。”（見 Thomas 的“Java 2 Platform, Enterprise Edition: Ensuring Consistency, Portability, and Interoperability”）

J2EE 為 Enterprise JavaBeans 技術提供了工作環境。事實上，Sun 把若干項軟件技術都設想為這樣的構件塊，它們將使大型企業能夠把以任務為關鍵的業務系統移植到 Java 環境中，而 Enterprise JavaBeans 技術不過是這些技術之一。EJB 組件是按它們自己的規范定義的，但 EJB 技術并不是一項獨立的技術。它建立在其他 Java 技術之上，這些技術由 Sun 和其他 IT 公司聯合規定，它們一起提供了這個框架的內容，該框架就稱為 Java 2 Platform, Enterprise Edition。

J2EE 中包括以下技術：

Enterprise JavaBeans (EJB) 技術 
Java Interface Definition Language (IDL) 
Java Message Service (JMS) API 
Java Naming and Directory Interface (JNDI) 
Java Remote Method Invocation (RMI) 和 Object Serialization 
Java Servlet API 
Java Transaction API (JTA) 
Java Transaction Service (JTS) 
JavaServer Pages (JSP) 技術 
JDBC 數據庫訪問 API
參與到這個企業 Java 框架中，并不意味著每項技術都依賴于所有其他技術。單獨的規范文檔指出每項技術的相關性。例如，Enterprise JavaBeans 規范 1.0 發行版就指明了在定位各個組件時與 JNDI 的相關性，以及在編程中啟動和停止事務處理時與 JTA 的相關性。

EJB 技術的設計目標 
EJB 規范的第一版以初稿形式于 1997 年 12 月公布，并于 1998 年 3 月作為 1.0 版發行。規范作者為 EJB 體系結構制定了以下目標：

Enterprise JavaBeans 體系結構將是標準的組件體系結構，用于以 Java 編程語言構建分布式的面向對象的商務應用程序。通過把使用不同供應商提供的工具開發出來的組件組合在一起，Enterprise JavaBeans 體系結構將有可能構建分布式的應用程序。


Enterprise JavaBeans 體系結構將使編寫應用程序變得容易：應用程序開發人員將不必了解低層次的事務和狀態管理的細節、多線程、資源共享和其他復雜的低級 API。但是，將允許專家級的程序員直接訪問低級 API。


Enterprise JavaBeans 應用程序將遵循 Java 編程語言的“一次編寫，隨處運行”的原則。EJB 組件可以只開發一次，然后在多個平臺上部署，而不需要重新編譯或修改源代碼。