本文概述 Enterprise JavaBeans (EJB) 技術(shù)，旨在讓讀者快速理解基本 概念。第 1 部分講述 EJB 技術(shù)的歷史和某些目標、優(yōu)點(diǎn)和技術(shù)。為了簡(jiǎn)潔 明了，有選擇地講述 EJB 技術(shù)的一些關(guān)鍵要素。請注意，雖然 EJB 組件依賴(lài)于一些基礎 的 Java 服務(wù)（如 Java Transaction Service），但使 用 EJB 組件及認識這些組件的好處并不需要掌握這些相關(guān)技術(shù)的知識。 Enterprise JavaBeans 技術(shù)自 1998 年 3 月問(wèn)世以來(lái)很受好評。下面這段話(huà)就是一個(gè)例子： “自從兩年多以前問(wèn)世以來(lái)，Enterprise JavaBeanstm 技術(shù)在平臺供應商和企業(yè)的開(kāi)發(fā)小組中，同樣都保持著(zhù)空前的發(fā)展勢頭。這是因為 EJBtm 的服務(wù)器端組件模型簡(jiǎn)化了中間件組件的開(kāi)發(fā)，這些中間組件都是事務(wù)性的、可伸縮的和可移植的。Enterprise JavaBeans 服務(wù)器通過(guò)為中間件服務(wù)（如事務(wù)處理、安全性、數據庫連接及其他）提供自動(dòng)支持，降低了開(kāi)發(fā)中間件的復雜程度。”（Sun Microsystems 網(wǎng)站） Enterprise JavaBeans 這一名稱(chēng)利用了 Java bean — 這種可移植、可重用 的 Java 軟件組件的聲望。Enterprise JavaBeans 技術(shù)把 Java 組件的概念從客戶(hù)機域擴展到了 服務(wù)器域：這是 Java 技術(shù)成長(cháng)過(guò)程中有重大意義的一步，它使 Java 技術(shù)發(fā)展成為一種強健的、可伸縮的環(huán)境，能夠支持以任務(wù)為關(guān)鍵的企業(yè)信息系統。 服務(wù)器上的 Java 應用程序 Java 編程語(yǔ)言最初在 Web 開(kāi)發(fā)人員中獲得好評的一個(gè)原因是，它支持稱(chēng) 為 applet 的可下載 Java 程序。對 Applet 的支持以 Applet 類(lèi)的形式內置到 了 1.0 版的 Java Development Kit (JDK) 中。按照 1.0 版的時(shí)間框架，Java 開(kāi)發(fā)是以 applet 和 應用程序作為中心的?；?JDK 1.0 版的 Java 讀物都是從 applet 和應用程序的角度來(lái)描述 Java 編程的： “Java 程序由更多的類(lèi)定義中的某一個(gè)組成，每個(gè)類(lèi)定義均已編譯成它自已 的 Java 虛擬機對象代碼的 .class 文件。這些類(lèi)之一必須定義一個(gè) 叫做 main() 的方法，程序就是從這個(gè)方法開(kāi)始運行的。想調用一個(gè) Java 程序，需要運行 Java 解釋器 java，并指定包含 main() 方法的類(lèi)的名稱(chēng)。請注 意 Java applet 并不是一個(gè)應用程序 — 它是一個(gè)由已在運行的 Java 應用 程序（如 Web 瀏覽器或 applet 查看器）裝入并運行的 Java 類(lèi)。”（見(jiàn) Flanagan 所著(zhù) 的 Java in a Nutshell） Java 應用程序可以在服務(wù)器上運行，但是不管是在客戶(hù)機-服務(wù)器環(huán)境下，還是在基于 Web 的環(huán)境 下，JDK 中都沒(méi)有提供讓 Java 應用程序專(zhuān)用于服務(wù)器機器的接口或包。認識到 Java 在 Web 環(huán)境下作為一種服務(wù)器語(yǔ)言的潛力，Sun Microsystems 編寫(xiě)了 Java Servlet 規范。servlet 在許多方面 與 applet 相似，它是專(zhuān)門(mén)為在 Web 服務(wù)器機器上運行而設計的 Java 程序： “servlet 是由容器管理的 Web 組件，可產(chǎn)生動(dòng)態(tài)內容。servlet 是 一種小型的、與平臺無(wú)關(guān)的 Java 類(lèi)，被編譯成體系結構中立的字節代碼，這種代碼可以動(dòng)態(tài)地加載到 一個(gè) web 服務(wù)器上，并由此 web 服務(wù)器運行。servlet 通過(guò)一種 由 servlet 容器實(shí)現的請求-響應模型與 Web 客戶(hù)機進(jìn)行交互。這種請求-響應模型建立在超文本傳輸協(xié)議 (HTTP) 行為的基礎之上。”（見(jiàn) JavaSoft 的“Java Servlet API Specification”） 在一臺 Web 服務(wù)器控制下，在多臺服務(wù)器上運行若干小型用戶(hù)程序，這種想法并不新鮮 — 一段時(shí)間 以來(lái)，公共網(wǎng)關(guān)接口 (CGI) 程序（常被稱(chēng)為 CGI 腳本）一直起著(zhù)這種作用，并推動(dòng)了 Web 的普 及。但 Java servlet 可以以更高的效率和可移植性來(lái)實(shí)現這一目的，因而 可望最終會(huì )取代 CGI 程序。為 servlet 提供運行時(shí)環(huán)境的 軟件（通常被稱(chēng)為 servlet 引擎）可以添加到現有的、本身并不支持 Java 可執行程序 的 Web 服務(wù)器上。 Java servlet 的出現，為應用程序員使用 Java 來(lái)創(chuàng )建 Web 應用程序開(kāi)辟了新的途徑。但是，僅有 servlet 還不能為真正的企業(yè)計算提供完整的模型。CGI 應用程序本身往往不是完整的應用程序，在處理接收自 Web 瀏覽器上用戶(hù)的信息請求時(shí)，CGI 只是整個(gè)處理過(guò)程中的一個(gè)中間步驟。例如，CGI 應用程序的一種常見(jiàn)用途是訪(fǎng)問(wèn)數據庫。將它用于這種任務(wù)時(shí)，CGI 程序提供一種方法，將用戶(hù)的數據請求連接到能滿(mǎn)足這種請求的企業(yè)數據庫。CGI 程序常常充當一種中間軟件，從 Web 瀏覽器接收請求，決定必須調用哪些計算資源來(lái)滿(mǎn)足這些請求，并向瀏覽器發(fā)回響應。Java servlet 與 CGI 程序一樣，最適合充當連接前端 Web 請求與后端 數據資源的中間層組件。 三層體系結構 Web 編程向服務(wù)器端 Java 應用程序的演化，也帶來(lái)了體系結構的演化，使它脫離了常規的客戶(hù)機-服務(wù)器兩層模型，而向一種三層方法發(fā)展。兩層模型當時(shí)曾經(jīng)具有創(chuàng )新意義，因為它將一些計算任務(wù)從主處理器上卸載到靈巧的客戶(hù)機。常規的基于 LAN 的數據庫應用程序就是一個(gè)例子，其中數據庫管理器服務(wù)器軟件駐留在一個(gè)專(zhuān)用的服務(wù)器機器上，而用戶(hù)則通過(guò)他們的工作站上的客戶(hù)機代碼來(lái)訪(fǎng)問(wèn)數據庫。隨著(zhù)客戶(hù)機-服務(wù)器模型成長(cháng)到能付諸使用，就出現了對服務(wù)器可伸縮性和對客戶(hù)機代碼大小和復雜性的關(guān)注。于是提出了一種三層的體系結構，以避免在兩層模型中已察覺(jué)到的弱點(diǎn)，使 Web 能成為一個(gè)計算平臺： “許多人...斷言，傳統的客戶(hù)機/服務(wù)器兩層體系結構不會(huì )有好的可伸縮性，因為用戶(hù)連接和數據訪(fǎng)問(wèn)的數量無(wú)法預測，而且在一些系統管理上也存在問(wèn)題。為處理兩層體系結構的限制，許多開(kāi)發(fā)集體都在轉向三層體系結構。這種體系結構大致可以定義為：客戶(hù)機層上的表示層、中間的服務(wù)器和后端的某種數據庫。這種設想的目的就是緩和客戶(hù)機或數據庫服務(wù)器上的代碼膨脹，集中管理業(yè)務(wù)邏輯，更靈活地使用數據庫，而不僅是使用所存儲的過(guò)程和觸發(fā)器。”（見(jiàn) Kim 的“Looking for a 3-Tier App Builder?”） 一個(gè)三層結構模型通常被想像成有一個(gè) Web 瀏覽器作為客戶(hù)層。Web 瀏覽器由于有可能成為一種真正的通用客戶(hù)機，使它從觀(guān)念上取代了兩層結構的“胖客戶(hù)機”。如果瀏覽器作為 Web 應用程序體系結構的標準瘦客戶(hù)機獲得認可，那么以前駐留在兩層模型的胖客戶(hù)機中的功能會(huì )怎么樣呢？現在，應用程序專(zhuān)用的功能并不移植回服務(wù)器（例如數據庫管理器），而是有意將它駐留在一個(gè)新的中間層上。中間層支持應用程序服務(wù)器軟件，這種軟件是中間件的一種形式，它處于第一層上瘦客戶(hù)機的最小功能和第三層上服務(wù)器端業(yè)務(wù)系統的豐富功能之間。由于三層體系結構與 Web 處理模型有密切關(guān)系，所以中間層應用程序服務(wù)器常被視 為 Web 服務(wù)器的一種功能擴展?，F有的 Web 應用程序利用 CGI 程序，將來(lái)自 Web 瀏覽器的用戶(hù)請求傳送 到不基于 Web 的業(yè)務(wù)系統，并向瀏覽器返回響應，就是三層模型的一種實(shí)現。這些應用程序逐漸向 servlet 技術(shù)的轉移說(shuō)明三層模型正在增強。 JavaBeans 組件 JavaBeans 規范將“組件軟件”的概念引入到 Java 編程的領(lǐng)域。組件是自含的、可重用 的軟件單元；而 JavaBeans 組件，則可以使用可視的應用程序開(kāi)發(fā)工具，可視地將它們 編寫(xiě)到 Java 程序中。JavaBeans 規范為 Java 開(kāi)發(fā)人員提供了一種“組件化”其 Java 類(lèi)的方法： Bean 是一些 Java 類(lèi)，可在一個(gè)可視的構建器工具中操作它們，并且可以將它們一起編寫(xiě)到應用程序中。任何具有某種特性和事件接口約定的 Java 類(lèi)都可以是一個(gè) Bean。（見(jiàn) JavaSoft，“Using the Beans Development Kit 1.0”） 如果軟件重用是一個(gè)好主意，那么是否應該讓每一個(gè) Java 類(lèi)都成為 Java bean 呢？如 果 Java 類(lèi)滿(mǎn)足某些準則，它們就適于充當 bean 的角色： 在開(kāi)發(fā)任何新軟件之前，都值得考慮是否用 JavaBean 的形式來(lái)開(kāi)發(fā)它。如果軟件模塊要既能夠可視地操作，又能夠定制以達到某些效果，則這種軟件模塊就可能適于做成一個(gè) JavaBean。為幫助您確定要開(kāi)發(fā)的軟件是否應該是一個(gè) JavaBean，假定它應該是 用 Java 編寫(xiě)的，請向您自已提出以下問(wèn)題，并相應地作出決定： 是否打算讓它可重用？或者，它會(huì )是可重用的嗎？ 是否希望將它與其他可重用的 Java 組件一起使用？ 是否預計會(huì )在 IDE 工具中使用它？ 如果上述問(wèn)題的答案都是肯定的，則它應該作為 JavaBean 來(lái)開(kāi) 發(fā)。（見(jiàn) developerWorks 的“JavaBeans Guidelines”） JavaBean 概念是為了在 Java 編程環(huán)境中支持可重用的組件，它是一種一般性的設計方法，適用于客戶(hù)機或服務(wù)器機器上運行的 Java 程序。由于對可視的構建器工具的強調，也由于許多 Java bean 都是圖形用戶(hù)界面 (GUI) 組件，所以 JavaBean 組件可能被視為一種客戶(hù)端技術(shù)。但是，并不要求 Java bean 都是可視的，并且它們也可以用于服務(wù)器環(huán)境中。 編碼為 Java bean 的 Java 類(lèi)通常具有以下特征： 使用設計模式。這些模式就是方法和接口的編碼約定。 支持可視的軟件開(kāi)發(fā)工具。類(lèi)必須將變量（稱(chēng)為屬性）、方法和事件展示出來(lái)。 可以定制。定制包括能支持缺省的屬性編輯器，或者提供單一的定制規則。定制使開(kāi)發(fā)人員得以在不更改源代碼的情況下更改 bean 的行為。 支持自省 (introspection)。這指的是將屬性、方法和事件公開(kāi)給其他類(lèi)，可以通過(guò)設計模式或通過(guò)創(chuàng )建 BeanInfo 類(lèi) 來(lái)完成這種自省。 是持久的。這就允許在一個(gè)可視構建器中定制一個(gè) bean，然后以其定制后的狀態(tài)加以保存。 Java 2 Platform, Enterprise Edition Sun Microsystems 發(fā)起了一項稱(chēng)為 Java 2 Platform, Enterprise Edition (J2EE) 的技術(shù) 創(chuàng )新，旨在將 Java 平臺的范圍擴展到大規模服務(wù)器環(huán)境： “1997 年 4 月 12 日，Sun 宣布了一項為企業(yè)環(huán)境 開(kāi)發(fā) Java 平臺的創(chuàng )新成果。使 用開(kāi)放式的 Java Community Process，Sun 促進(jìn)了一組標準的 Java 擴展的開(kāi)發(fā)，稱(chēng) 為 Enterprise Java API。這些應用程序編程接口 (API) 為各種各樣的中間件的實(shí)現提供了不依賴(lài) 供應商的編程 接口。Enterprise Java API 的要點(diǎn)是 Enterprise JavaBeans API，后者為 Java 應用程序服務(wù)器 定義了一個(gè)服務(wù)器端組件模型，以及一個(gè)不依賴(lài)供應商的編程接口。”（見(jiàn) Thomas 的“Java 2 Platform, Enterprise Edition: Ensuring Consistency, Portability, and Interoperability”） J2EE 為 Enterprise JavaBeans 技術(shù)提供了工作環(huán)境。事實(shí)上，Sun 把若干項軟件技術(shù)都設想為這樣的構件塊，它們將使大型企業(yè)能夠把以任務(wù)為關(guān)鍵的業(yè)務(wù)系統移植到 Java 環(huán)境 中，而 Enterprise JavaBeans 技術(shù)不過(guò)是這些技術(shù)之一。EJB 組件是按它們自己的規范定義 的，但 EJB 技術(shù)并不是一項獨立的技術(shù)。它建立在 其他 Java 技術(shù)之上，這些技術(shù)由 Sun 和其他 IT 公司聯(lián)合規定，它們一起提供了這個(gè)框架的內容，該框架就稱(chēng)為 Java 2 Platform, Enterprise Edition。 J2EE 中包括以下技術(shù)： Enterprise JavaBeans (EJB) 技術(shù) 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) 技術(shù) JDBC 數據庫訪(fǎng)問(wèn) API 參與到這個(gè)企業(yè) Java 框架中，并不意味著(zhù)每項技術(shù)都依賴(lài)于所有其他技術(shù)。單獨的規范文檔指出每項技術(shù)的相關(guān)性。例如，Enterprise JavaBeans 規范 1.0 發(fā)行版就指明了在定位各個(gè)組件時(shí)與 JNDI 的相關(guān)性，以及在編程中啟動(dòng)和停止事務(wù)處理時(shí)與 JTA 的相關(guān)性。 EJB 技術(shù)的設計目標 EJB 規范的第一版以初稿形式于 1997 年 12 月公布，并于 1998 年 3 月作為 1.0 版發(fā)行。規范 作者為 EJB 體系 結構制定了以下目標： Enterprise JavaBeans 體系結構將 是標準的組件體系結構，用于以 Java 編程語(yǔ)言構建分布式的面向對象的商務(wù)應用程序。通過(guò)把使用不同供應商提供的工具開(kāi)發(fā)出來(lái)的組件組合在一起，Enterprise JavaBeans 體系結構將有可能構建分布式的應用程序。 Enterprise JavaBeans 體系結構將使編寫(xiě)應用程序變得容易：應用程序開(kāi)發(fā)人員將不必了解低層次的事務(wù)和狀態(tài)管理的細節、多線(xiàn)程、資源共享和其他復雜的低級 API。但是，將允許專(zhuān)家級的程序員直接訪(fǎng)問(wèn)低 級 API。 Enterprise JavaBeans 應用程序將遵循 Java 編程語(yǔ)言的“一次編寫(xiě)，隨處運行”的 原則。EJB 組件可以只開(kāi)發(fā)一次，然后在多個(gè)平臺上部署，而不需要重新編譯或修改源代碼。 Enterprise JavaBeans 體系結構將處理企業(yè)應用程序生命周期中的開(kāi)發(fā)、部署和運行等方面。 Enterprise JavaBeans 體系結構將定義一些約定，這些約定使多個(gè)供應商提供的工具能夠開(kāi)發(fā)并部署可在運行時(shí)互操作的組件。 Enterprise JavaBeans 體系結構將與現有的服務(wù)器平臺兼容。供應商將能夠擴展它們的現有產(chǎn)品，以支持 Enterprise JavaBeans 組件。 Enterprise JavaBeans 體系結構將與 Java 編程語(yǔ)言編寫(xiě)的其他 API 兼容。 Enterprise JavaBeans 體系結構將提供 EJB 組件和非 Java 編程語(yǔ)言應用程序之間的互操 作性。 Enterprise JavaBeans 體系結構將與 CORBA 兼容。 使用 EJB 技術(shù)的好處 這些設計目標會(huì )使企業(yè)和開(kāi)發(fā)人員得到什么好處呢？下面列出了可望從 采用 Enterprise JavaBeans 環(huán)境獲得的好處： EJB 組件使編寫(xiě)應用程序更為簡(jiǎn)單。盡管 EJB 體系結構復雜，但應用程序開(kāi)發(fā)人員一般都不必再編寫(xiě)用于訪(fǎng)問(wèn)系統服務(wù)的代碼。一種稱(chēng)為 EJB 容器的系統組件使系統服務(wù)可 用于 EJB 組件的任務(wù)。 服務(wù)器端商務(wù)邏輯可以移植。除了 Java 語(yǔ)言固有的可移植性外，EJB 體系結構還在 bean 和支持該 bean 的容器之間提供了一套標準化的應用程序編程接口。這 使開(kāi)發(fā)人員能夠將 bean 從一種操作環(huán)境移植到另一種操作環(huán)境，而無(wú)須重新編寫(xiě)其源代碼。 可以從現有的軟件組件裝配出服務(wù)器端應用程序，這與從現有的 Java bean 可以裝配出客戶(hù)端應用程序一樣，從而使軟件能夠重用。 EJB 體系結構內置了對典型企業(yè)級系統服務(wù)的支持，包括分布式對象、事務(wù)處理、數據庫、安全和全局命名。 多家 IT 供應商都采納 EJB 體系結構，這是由于有這樣的承諾：客戶(hù)將能夠從選定的供應商那里選購軟件組件，如 EJB 組件、容器及 EJB 服務(wù)器；也由于承諾了不同供應商的產(chǎn)品，只要 符合 EJB 體系結構，就都是可互操作的。 用 EJB 組件構建的應用程序可以從一個(gè)服務(wù)器移植到另一個(gè)服務(wù)器，從而支持可伸縮性，這是因為在 EJB 模型中，各個(gè)軟件組件都是嚴格分離的。 EJB 體系結構能保障原有的 IT 投資，這是通過(guò)允許將現有的信息系統和資產(chǎn)“包裹”在這些應用程序中，而不要求客戶(hù)更換現有技術(shù)。事實(shí)上，在關(guān)系數據庫中存儲數據的企業(yè)已經(jīng) 有了一套已有雛形的實(shí)體 bean，正等著(zhù) 通過(guò) EJB 外殼去訪(fǎng)問(wèn)。 進(jìn)一步考察 JNDI Enterprise JavaBeans 組件使用 Java Naming and Directory Interface (JNDI) 來(lái)訪(fǎng)問(wèn)各種目錄 服務(wù)。JNDI 分 兩部分：應用程序編程接口 (API) 和服務(wù)供應商接口 (SPI)： “JNDI 體系結構由 JNDI API 和 JNDI SPI 組成。JNDI API 允許 Java 應用 程序訪(fǎng)問(wèn)各種命名和目錄服務(wù)。JNDI SPI 則是設計來(lái)供任意一種服務(wù)的供應商（也包括目錄服務(wù)供應商）使用。這使得各種各樣的目錄服務(wù)和命名服務(wù)能夠透明地插入到使用 JNDI API 的 Java 應用程序 中。（見(jiàn) JavaSoft，“JNDI: Java Naming and Directory Interface”） JNDI API 并不同某種專(zhuān)用的命名技術(shù)或目錄技術(shù)連在一起，也不同任何供應商的目錄服務(wù)連在一起，因此它對 EJB 組件的可移植性有所貢獻。例如，客戶(hù)可以從多種不同的技術(shù)中選擇，來(lái)為其 EJB 應用程序提供目錄服務(wù)，這些技術(shù)包括： LDAP：Sun 的 LDAP 服務(wù)供應商支持 LDAP 協(xié)議的第 2 版和第 3 版。 NIS：Sun 提供一個(gè) NIS 服務(wù)供應商（NIS 即網(wǎng)絡(luò )信息服務(wù)，以前稱(chēng)為黃頁(yè)）。 COS 命名：Sun 的 COS 命名服務(wù)供應商提供對 CORBA 命名服務(wù)的訪(fǎng)問(wèn)。 文件系統：Sun 提供一個(gè)服務(wù)供應商來(lái)訪(fǎng)問(wèn)文件系統。 RMI 注冊：Sun 為 RMI 注冊提供一個(gè)服務(wù)供應商。 Novell：有幾個(gè)服務(wù)供應商可提供對目錄服務(wù) NDS 的訪(fǎng)問(wèn)以及 NetWare 3X 連接庫、Novell 文件 系統和其他 Novell 服務(wù)（如擴展 NCP）的訪(fǎng)問(wèn)。 雖然 JNDI 規范對供應商是中立的，但不應認為，實(shí)現 JNDI 接口的應用程序服務(wù)器一定要能訪(fǎng)問(wèn)來(lái)自多個(gè)供應商的服務(wù)供應商代碼。 JNDI 命名體系結構的關(guān)鍵概念包括： 對象和名稱(chēng)之間的綁定。 若干稱(chēng)為命名上下文的綁定集。 命名系統，即若干組命名上下文。 命名空間，指一個(gè)命名系統中的所有名稱(chēng)。 名稱(chēng)分類(lèi)為原子名稱(chēng)、復合名稱(chēng)和合成名稱(chēng)。原子名稱(chēng)是不可分割的，可以綁定到一個(gè)對象上。復合名稱(chēng)是原子名稱(chēng)的組合，而合成名稱(chēng)則跨越多個(gè)命名系統。 命名上下文特別重要：所有的命名操作均是在上下文對象上進(jìn)行的，并且名稱(chēng)解析過(guò)程總是從最初的命名上下文開(kāi)始。 EJB 應用程序是如何使用 JNDI 的呢？JNDI 的主要用途是檢索對 EJB 組件的引用。因 為 EJB 框架是一個(gè)分布式對象框架，所以 EJB 應用程序不應當假定 EJB 組件的位置。JNDI 就是 獲取對 bean 的起始引用的一種機制。當一個(gè) bean 安裝到一個(gè) enterprise bean 服務(wù)器上 時(shí)，一個(gè)被稱(chēng)為 EJB 容器的軟件組件就負責創(chuàng )建各個(gè)名稱(chēng)-對象綁定，使所需的 Java 類(lèi)文件能使用 這個(gè) bean。應用程序使用 JNDI 的查找方法來(lái)檢索對象引用，如下例所示： Context initialContext = new InitialContext( ); CartHome cartHome = javax.rmi.PortableRemoteObject.narrow( initialContext.lookup("applications/shopping_cart"), CartHome.class); 應用程序有責任知道外部名稱(chēng)，應用程序就是通過(guò)這個(gè)名稱(chēng)才得以引用一個(gè) enterprise bean，并通過(guò) JNDI 來(lái)獲取對該 bean 的引用的。 進(jìn)一步考察 JTA 除 JNDI 以外，Enterprise JavaBeans 體系結構還使用 Java Transaction API (JTA)。因為事務(wù)對維護數據完整性和可靠性很重要，所以支持事務(wù)處理是 EJB 體系結構的一個(gè)基本部分。如果企業(yè)應用程序是分布式的，事務(wù)處理就會(huì )更加重要： “事務(wù)的概念是一個(gè)重要的編程范例，其目的在于簡(jiǎn)化既要求可靠性又要求可用性的應用程序結構，特別是那些需要同時(shí)訪(fǎng)問(wèn)共享數據的應用程序。事務(wù)的概念最早是用在商務(wù)運作的應用程序中，其中它被用于保護集中式數據庫中的數據。后來(lái)，事務(wù)的概念已擴展到分布式計算的更廣泛的環(huán)境中。今天，事務(wù)是構建可靠的分布式應用程序的關(guān)鍵，這一點(diǎn)已得到廣泛承認。”（見(jiàn)對象管理組的“Transaction Service Specification”） 有時(shí)將事務(wù)描述為具有下列特征的工作單元： 原子性 — 如果因故障而中斷，所有結果均撤銷(xiāo) 一致性 — 事務(wù)的結果保留不變的特性 孤立性 — 中間狀態(tài)對其他事務(wù)是不可見(jiàn)的 持久性 — 已完成的事務(wù)的結果是持久的 事務(wù)的終止有兩種方式：提交一個(gè)事務(wù)會(huì )使其所有的更改永久不變，而 回滾 (rolling back) 一個(gè)事務(wù) 則撤銷(xiāo)其所有的更改。 對象管理組織 (OMG) 為一種面向對象的事務(wù)服務(wù)，即對象事務(wù)服務(wù) (OTS)，創(chuàng )建了一種 規范。OTS 是 EJB 體系結構內的事務(wù)服務(wù)的基礎。下列事務(wù)規范就是為 enterprise bean 所采用的事務(wù) 模型而設： OMG 的對象事務(wù)服務(wù) (OTS) Sun Microsystems 的 Transaction Service (JTS) Sun Microsystems 的 Java Transaction API (JTA) 開(kāi)放組 (X/Open) 的 XA 接口 這種與語(yǔ)言無(wú)關(guān)的對象事務(wù)服務(wù)，為一個(gè)強健的分布式事務(wù)服務(wù)提供了基本概念、定義和功能。 Java Transaction Service 是 OTS 的 Java 映 射，在 org.omg.CosTransactions 和 org.omg.CosTSPortability 這兩個(gè) 包中定義。JTS 對事務(wù)分界和事務(wù)環(huán)境的傳播之類(lèi)的服務(wù)提供支持。JTS 功能由應用程序通過(guò) Java Transaction API 訪(fǎng)問(wèn)。 Java Transaction API 指定事務(wù)管理器與分布式事務(wù)中涉及的其他系統組件之間的各種高級接口，這些系統組件有應用程序、應用程序 服務(wù)器和資源管理器等。JTA 功能允許事務(wù)由應用程序本身、由應用程序服務(wù)器或由一個(gè)外部事務(wù)管理器來(lái)管理。JTA 接口包含 在 javax.transaction 和 javax.transaction.xa 這兩個(gè)包中。 XA 接口定義了資源管理器和分布式事務(wù)環(huán)境中外部事務(wù)管理器之間的約定。外部事務(wù)管理器可以跨多個(gè)資源協(xié)調事務(wù)。XA 的 Java 映射包含在 Java Transaction API 中。 第二部分：EJB 編程模型 Ken Nordby IBM 軟件工程師 2000 6 月 本文的第二部分說(shuō)明創(chuàng )建 Enterprise JavaBean 組件所需的 Java 接口和類(lèi)的作用。除了對 bean 類(lèi)本身進(jìn)行編碼外，EJB 開(kāi)發(fā)人員還必須為 bean 定義一個(gè)本地接口和一個(gè)遠程接口。這些接口的實(shí)現類(lèi)通常由容器生成，因此部署 EJB 組件是開(kāi)發(fā)人員和 EJB 容器的合作行為。第二部分還區分了 enterprise bean 的兩種主要類(lèi)型，即會(huì )話(huà) bean 和實(shí)體 bean，并說(shuō)明了 EJB 容器和 EJB 服務(wù)器之間的關(guān)系。 enterprise bean 的編程模型的三個(gè)關(guān)鍵特征是：面向對象、對象的分布式和使用代理對象。由于此編程模型使用 Java 技術(shù)，因此它在本質(zhì)上就是面向對象的。此模型也是分布式的，這是指 bean 在理論上是位置透明的。根據 Enterprise JavaBeans (EJB) 規范，“一般說(shuō)來(lái)，EJB 類(lèi)和 EJB 容器的實(shí)際位置對客戶(hù)機是透明的。”在客戶(hù)機想要訪(fǎng)問(wèn) EJB 組件時(shí)使用代理對象。bean 本身對于客戶(hù)機是不可訪(fǎng)問(wèn)的，對 bean 方法的訪(fǎng)問(wèn)則由 helper 類(lèi)提供。 接口、委托和代理 當 Java 程序員編寫(xiě)一個(gè) Enterprise JavaBeans 組件時(shí)，他們所創(chuàng )建的類(lèi)必須實(shí)現一個(gè) EJB 接口，并且它必須包含一個(gè)名為 ejbCreate() 的方法。一個(gè) EJB 接口 -- 例如 SessionBean 接口 -- 指定了一些方法，它們包括以下各項： ejbActivate() ejbPassivate() ejbRemove() setSessionContext() ejbActivate() 和 ejbPassivate() 方法通知一個(gè) bean，管理該 bean 的容器組件正在主動(dòng)和被動(dòng)之間切換 bean 的狀態(tài)（這通常是指在內存中還是交換到磁盤(pán)）。ejbRemove() 方法使 bean 知道它已被從容器中刪除。setSessionContext() 方法使 bean 與一個(gè)上下文對象相關(guān)聯(lián)，此上下文對象是為了便于 bean 與其容器進(jìn)行通信。 ejbCreate() 方法并不是從零做起創(chuàng )建 enterprise bean 的。當客戶(hù)機想要創(chuàng )建新的 enterprise bean 時(shí)，bean 的容器將調用這個(gè) bean 的類(lèi)的 newInstance() 方法，來(lái)實(shí)例化新的 bean 對象。然后容器調用 setSessionContext() 方法來(lái)建立上下文對象，用于與 bean 進(jìn)行通信。最后，容器調用新 bean 中的 ejbCreate() 方法。像 ejbCreate()、ejbActivate() 和 ejbPassivate() 這樣的方法有時(shí)稱(chēng)為對象生存周期方法，以區別于業(yè)務(wù)邏輯方法。 當開(kāi)發(fā)人員設計一個(gè)新的 EJB 組件時(shí)，編寫(xiě)組成 enterprise bean 類(lèi)的代碼本身是不夠的。EJB 程序員還必須編寫(xiě)兩個(gè)將由 helper 類(lèi)使用的 Java 接口。這些強制性接口必須擴展標準的 EJBObject 和 EJBHome 接口，而這兩個(gè)接口則都是 java.rmi.Remote marker 接口的擴展。擴展標準 EJBObject 接口的接口被稱(chēng)為 enterprise bean 的遠程接口，它指定在 bean 自身中定義的業(yè)務(wù)方法。當應用程序調用 enterprise bean 中的業(yè)務(wù)方法時(shí)，應用程序并不訪(fǎng)問(wèn) bean 本身。實(shí)際上，方法調用被傳遞給實(shí)現 EJBObject 接口擴展的那個(gè)對象。這種做法稱(chēng)為委托，它是 EJB 體系結構中的一個(gè)設計要點(diǎn)： “客戶(hù)機從來(lái)不直接訪(fǎng)問(wèn) enterprise bean 類(lèi)的實(shí)例?？蛻?hù)機總是使用 enterprise bean 的遠程接口來(lái)訪(fǎng)問(wèn) enterprise bean 的實(shí)例。實(shí)現 enterprise bean 的遠程接口的類(lèi)由容器提供。此類(lèi)所實(shí)現的分布式對象稱(chēng)為 EJB 對象。”(Enterprise JavaBeans Specification 1.0) bean 對 EJBObject 接口的擴展稱(chēng)為其遠程接口，而實(shí)現遠程接口的對象則稱(chēng)為 EJB 對象。 enterprise bean 還必須具有本地接口。此接口是標準 EJBHome 接口的擴展。實(shí)現 bean 的本地接口的對象稱(chēng)為本地對象。本地對象包含一個(gè) create() 方法，此方法由應用程序調用，而應用程序則必須創(chuàng )建一個(gè) bean 實(shí)例。本地對象中的 create() 方法創(chuàng )建一個(gè)新的 EJB 對象。它并不直接創(chuàng )建新的 enterprise bean 實(shí)例，因為不允許直接訪(fǎng)問(wèn) bean。 EJB 對象和本地對象充當 bean 對象的代理，因為它們代表 bean 接收方法調用。EJB 對象主要為 bean 業(yè)務(wù)方法充當代理；本地對象主要為 bean 生存周期方法充當代理。 為 EJB 組件使用 create() 方法并不一定要實(shí)例化新的 bean。容器確定如何最好地滿(mǎn)足創(chuàng )建請求，對于某些類(lèi)型的 bean，它可以重用現有的實(shí)例： “客戶(hù)機使用會(huì )話(huà) bean 本地接口上的 create 和 remove 方法。雖然客戶(hù)機以為它正在控制著(zhù) EJB 實(shí)例的生存周期，但是，是容器在處理 create 和 remove 調用，而不一定要創(chuàng )建和刪除 EJB 實(shí)例。在客戶(hù)機和...實(shí)例之間不存在固定的映射。容器只是將客戶(hù)機的工作委托給任何一個(gè)方法已經(jīng)就緒的可用實(shí)例而已。”( Enterprise JavaBeans Specification 1.0) 創(chuàng )建新的 bean 實(shí)例受容器的控制，并可以與客戶(hù)機發(fā)布 create() 方法異步。 當創(chuàng )建一個(gè) EJB 組件時(shí)，開(kāi)發(fā)人員負責定義 EJBObject 接口和 EJBHome 接口，但是無(wú)需編寫(xiě)實(shí)現這些接口的類(lèi)的代碼。EJB 容器軟件組件自動(dòng)創(chuàng )建這些類(lèi)。 下面的代碼段說(shuō)明客戶(hù)機應用程序可能怎樣使用稱(chēng)為 CartBean 的 enterprise bean 來(lái)進(jìn)行在線(xiàn)購物： CartHome cartHome = javax.rmi.PortableRemoteObject.narrow( initialContext.lookup("applications/shopping_cart"), CartHome.class); Cart cart = cartHome.create(); cart.addItem(item29); cart.addItem(item67); cart.addItem(item91); cart.purchase(); cart.remove(); CartHome 是實(shí)現本地接口的類(lèi)（EJBHome 接口的擴展）。Cart 是實(shí)現遠程接口的類(lèi)（EJBObject 接口的擴展）。當客戶(hù)機調用應用程序方法（如 addItem() 和 purchase()）時(shí)，它們是在 cart 對象上調用的，此對象接著(zhù)將這些方法的執行委托給 bean 自身。enterprise bean 的功能是通過(guò)其代理 EJB 對象（即 cart）來(lái)獲得的。如果多臺客戶(hù)機同時(shí)訪(fǎng)問(wèn) cart bean，將會(huì )發(fā)生什么事情呢？Enterprise bean 開(kāi)發(fā)人員無(wú)需編寫(xiě)代碼來(lái)支持并發(fā)訪(fǎng)問(wèn)。并發(fā)性由 EJB 容器支持。 下圖說(shuō)明各 EJB 對象之間的關(guān)系： 服務(wù)器和容器 EJB 體系結構包括 EJB 服務(wù)器和 EJB 容器兩個(gè)概念。EJB 服務(wù)器充當一種組件執行系統，正如 EJB 白皮書(shū)中所述： “Enterprise JavaBeans 規范為每個(gè)支持完全可移植性的 Java 應用程序服務(wù)器定義了一個(gè)標準模型。任何廠(chǎng)商都可以使用此模型來(lái)實(shí)現對 Enterprise JavaBeans 組件的支持。多種系統（如 TP 監視器、CORBA 運行時(shí)系統、COM 運行時(shí)系統、數據庫系統、Web 服務(wù)器系統或其它基于服務(wù)器的運行時(shí)系統）都可以調整到能夠支持可移植的 Enterprise JavaBeans 組件。”(Thomas, Enterprise JavaBeans Technology: Server Component Model for the Java Platform) EJB 服務(wù)器為使用 EJB 組件的應用程序提供操作環(huán)境，并供應所有必需的服務(wù)，來(lái)支持 EJB 體系結構。打包 EJB 服務(wù)器軟件并沒(méi)有預先規定的方式。一種方法是將它作為一項功能增強包括到應用程序服務(wù)器中，這就是在 IBM WebSphere Application Server, Advanced Edition, Version 2.0 中采用的方法。 EJB 組件并不在 EJB 服務(wù)器的頂部直接執行。一個(gè)稱(chēng)為 EJB 容器的中間軟件組件在 EJB 服務(wù)器環(huán)境中運行，從而又為這些 bean 自身提供操作環(huán)境。EJB 容器對 EJB 應用程序是完全透明的，但是在支持 bean 操作方面起著(zhù)關(guān)鍵性的作用。 為了使 enterprise bean 能充當可重用的軟件組件，它們對特定的服務(wù)器或平臺功能不能有內建的相關(guān)性。服務(wù)器端功能的幾種常見(jiàn)類(lèi)型已經(jīng)被從 bean 設計中“分離出去”，而將此功能的責任轉移給了容器組件。例如，容器將被用來(lái)接管安全性、并發(fā)性、事務(wù)處理、交換到輔助存儲器和其它服務(wù)的責任，從而使 bean 免受服務(wù)器相關(guān)性的制約，并將按業(yè)務(wù)邏輯來(lái)優(yōu)化，而不是按服務(wù)邏輯來(lái)優(yōu)化。 EJB 白皮書(shū)這樣描述容器的作用： “EJB 容器管理部署于其中的 enterprise bean?？蛻?hù)機應用程序并不直接與 enterprise bean 進(jìn)行交互。相反，客戶(hù)機應用程序通過(guò)由容器生成的兩個(gè)封裝接口（ EJB Home 接口和 EJB Object 接口）與 enterprise bean 進(jìn)行交互。當客戶(hù)機使用封裝接口調用各種操作時(shí)，容器截獲每個(gè)方法調用，并插入管理服務(wù)。”(Thomas, Enterprise JavaBeans Technology: Server Component Model for the Java Platform) 可以期望 EJB 容器軟件一般都會(huì )隨 EJB 服務(wù)器軟件一起提供，盡管規范允許分離這些組件。除了提供對運行時(shí)服務(wù)（如事務(wù)處理和安全性）的訪(fǎng)問(wèn)以外，還期望 EJB 容器包括各種必要工具，來(lái)支持 enterprise bean 的安裝、操作和管理。例如，需要有工具解釋 EJB jar 文件的內容，有工具生成數據庫訪(fǎng)問(wèn)，來(lái)獲得容器提供的持久性，有工具監視正在運行的 bean 的行為，以及實(shí)現安全性等。 Bean 風(fēng)格 EJB 組件分為兩種主要類(lèi)別 -- 會(huì )話(huà) bean 和實(shí)體 bean。根據 bean 處理狀態(tài)、事務(wù)和持久性的方式這些類(lèi)別還可以進(jìn)一步細分。會(huì )話(huà) bean 通常具有以下屬性： 代表單個(gè)客戶(hù)機執行 可以是事務(wù)性的 可以更新共享數據庫中的數據 生存期相對較短 其生存期通常就是客戶(hù)機的生存期 任何持久性數據都由 bean 管理 可以依容器的判斷予以刪除 會(huì )在 EJB 服務(wù)器失敗時(shí)被刪除 實(shí)體 bean 通常具有以下屬性： 代表數據庫中的數據 是事務(wù)性的 允許多個(gè)用戶(hù)共同訪(fǎng)問(wèn) 可以長(cháng)期存在 持久性數據可以由容器管理 在 EJB 服務(wù)器失敗后能繼續生存 EJB 規范對會(huì )話(huà) bean 和實(shí)體 bean 的說(shuō)明如下： “對于客戶(hù)機，會(huì )話(huà) enterprise bean 是一種非持久性的對象，它實(shí)現某些在服務(wù)器上運行的業(yè)務(wù)邏輯。想像一個(gè)會(huì )話(huà)對象的一種方式是：會(huì )話(huà)對象是運行在服務(wù)器上的客戶(hù)機程序的邏輯擴展。會(huì )話(huà)對象不在多臺客戶(hù)機之間共享。 “對于客戶(hù)機，實(shí)體 enterprise bean 是一種持久性對象，它代表一個(gè)存儲在持久性存儲器（例如，一個(gè)數據庫）中的實(shí)體的對象視圖，或者是一個(gè)由現有企業(yè)應用程序實(shí)現的實(shí)體。”( Enterprise JavaBeans Specification 1.0) 用一種粗略的說(shuō)法，會(huì )話(huà) bean 代表這樣的操作，它檢索或存儲數據以滿(mǎn)足用戶(hù)請求；而實(shí)體 bean 則代表一種數據集，可以訪(fǎng)問(wèn)這些數據集來(lái)滿(mǎn)足用戶(hù)請求。 會(huì )話(huà) bean 最簡(jiǎn)單的一種 Enterprise JavaBeans 組件就是無(wú)狀態(tài)的會(huì )話(huà) bean。因為這些 bean 沒(méi)有可以區分它們的狀態(tài)，所有的實(shí)例都是完全相同的。容器管理無(wú)狀態(tài)會(huì )話(huà) bean 的生存周期，其方式是通過(guò)創(chuàng )建足夠數目的此種 bean 來(lái)適應客戶(hù)機工作負荷，并在不需要它們時(shí)將其刪除。鈍化，即將閑置的 bean 寫(xiě)到磁盤(pán)上，不用于無(wú)狀態(tài)的會(huì )話(huà)。要調用 bean，客戶(hù)機程序調用本地接口中的 standard create() 方法，盡管此操作不一定導致實(shí)例化新的 bean 實(shí)例。容器可以選擇將客戶(hù)機請求發(fā)送給現有的對象。反之，容器則可以按它的選擇創(chuàng )建新的實(shí)例，且獨立于由客戶(hù)機發(fā)布的 create() 方法。 在 EJB 本地對象上發(fā)布的 create() 調用返回一個(gè)對 EJB 對象的引用，這個(gè) EJB 對象代表 enterprise bean。一旦客戶(hù)機有了 EJB 對象引用，它就可以將業(yè)務(wù)方法發(fā)布到 EJB 對象上，容器隨之會(huì )將這些方法委托給 bean 自身。 負責管理會(huì )話(huà) bean 的容器組件無(wú)需推斷會(huì )話(huà) bean 是否是無(wú)狀態(tài)的。會(huì )話(huà) bean 是無(wú)狀態(tài)的還是有狀態(tài)的在安裝時(shí)聲明。 如果會(huì )話(huà) bean 在方法調用之間保留狀態(tài)信息，則它是有狀態(tài)的。通過(guò)調用 ejbPassivate() 方法，容器可以依其判斷將有狀態(tài)會(huì )話(huà) bean 鈍化，或寫(xiě)到輔助存儲器中。EJB 規范并不要求容器在鈍化 bean 時(shí)使用 Java 串行化協(xié)議，但是它們必須提供等價(jià)的功能。當容器決定將一個(gè)非活動(dòng)的會(huì )話(huà) bean 交換回到內存中時(shí)，它會(huì )取消被動(dòng) bean 的串行化，并調用 ejbActivate() 方法。有狀態(tài)會(huì )話(huà) bean 的開(kāi)發(fā)人員負責確保狀態(tài)數據是可串行化的。在集群的應用程序服務(wù)器環(huán)境中實(shí)現有狀態(tài)會(huì )話(huà) bean 時(shí)務(wù)必要小心，因為并不是所有的服務(wù)器都支持集群的有狀態(tài)會(huì )話(huà) bean 的同步化。 有狀態(tài)會(huì )話(huà) bean 可以是事務(wù)性的。通過(guò)使用 javax.transaction.UserTransaction 接口中的方法，如 begin()、commit() 和 rollback()，bean 可以控制事務(wù)；通過(guò)實(shí)現 javax.ejb.SessionSynchronization 接口，bean 可以接收有關(guān)事務(wù)狀態(tài)的通知。EJB 容器無(wú)需推斷哪些 bean 需要事務(wù)支持；UserTransaction 接口僅可用于那些在安裝時(shí)被標記為事務(wù)性的 bean。 實(shí)體 bean 實(shí)體 bean 在體系結構上與會(huì )話(huà) bean 類(lèi)似，但它們提供對企業(yè)數據的訪(fǎng)問(wèn)，而不是支持用戶(hù)會(huì )話(huà)。一個(gè)實(shí)體 bean 可以支持多個(gè)并發(fā)用戶(hù)，而容器則使訪(fǎng)問(wèn)和事務(wù)同步化。實(shí)體 bean 還具有支持本地對象中的 finder 方法的主鍵。知道實(shí)體 bean 的主鍵的客戶(hù)機可以通過(guò)調用本地對象上的 findBy PrimaryKey() 方法獲得對象引用。與會(huì )話(huà) bean 不同，實(shí)體 bean 的本地對象除了具有 create 方法外還具有 finder 方法。 持久性是實(shí)體 bean 的一個(gè)基本屬性。EJB 規范允許兩種形式的實(shí)體持久性：bean 管理的持久性和容器管理的持久性。對于代表關(guān)系數據庫中的數據的實(shí)體 bean，bean 對持久性的管理意味著(zhù)，對數據庫訪(fǎng)問(wèn)的調用是直接編寫(xiě)在企業(yè) bean 的方法中的（使用 JDBC 或 SQLJ）。這種方法是直截了當的，但它降低了可移植性。容器對持久性的管理意味著(zhù) bean 不受數據庫調用的影響。在安裝時(shí)告知容器有關(guān) bean 數據所需的持久性，而容器負責生成實(shí)現持久性的代碼。這種方法允許 bean 的可移植性更高，甚至達到持久性可使用不同數據源的程度。然而，此方法要求容器中要有復雜功能。 當實(shí)體 bean 對象與 EJB 對象相關(guān)聯(lián)時(shí)，前者處于就緒狀態(tài)；否則將認為它們處于共享狀態(tài)。當客戶(hù)機調用 EJB 對象中的方法時(shí)，容器查找關(guān)聯(lián)的實(shí)體 bean 的實(shí)例（如果存在的話(huà)），或者從共享狀態(tài)中傳送出一個(gè)實(shí)例。處于就緒狀態(tài)的實(shí)體 bean 可以接收到通過(guò)委托從客戶(hù)機傳播給它們的業(yè)務(wù)方法調用。它們還可以在容器請求時(shí)執行 ejbLoad() 和 ejbStore() 方法。load 方法和 store 方法旨在維持實(shí)體 bean 和基礎數據存儲之間數據的一致性。 實(shí)體 bean 支持多個(gè)用戶(hù)并發(fā)地訪(fǎng)問(wèn)數據。EJB 規范聲明，維持數據完整性是容器的責任： “enterprise bean 開(kāi)發(fā)人員在編寫(xiě)業(yè)務(wù)方法時(shí)無(wú)需擔心來(lái)自多個(gè)事務(wù)的并發(fā)訪(fǎng)問(wèn)。enterprise bean 開(kāi)發(fā)人員在編寫(xiě)方法時(shí)可以假定，對于被多個(gè)事務(wù)同時(shí)訪(fǎng)問(wèn)的各個(gè)實(shí)體 bean，將能確保適當的同步化。”(Enterprise JavaBeans Specification 1.0) 容器完成這一任務(wù)通常是通過(guò)鎖定數據庫中的數據，并使訪(fǎng)問(wèn)串行化，或通過(guò)創(chuàng )建實(shí)體 bean 的多個(gè)實(shí)例，并允許在基礎數據存儲中使用并發(fā)控制，這樣來(lái)管理訪(fǎng)問(wèn)。 第三部分：布署和使用 Enterprise JavaBeans 組件 Ken Nordby 軟件工程師，IBM 2000 年 7 月 本文的第 3 部分說(shuō)明 Enterprise JavaBeans 組件的部署過(guò)程，部署并不僅僅是安裝，因為它通常還涉及代碼生成。部署還使用了一個(gè)特殊的部署描述符文件，此文件支持控制企業(yè)級 bean 行為（如某個(gè) bean 是否需要事務(wù)）的參數。bean 部署的這一特性支持 bean 行為的說(shuō)明性、綱領(lǐng)性規范的 EJB 目標。第 3 部分還比較了持久性的兩種主要類(lèi)型，bean 管理式持久性和容器管理式持久性，并討論了 EJB 組件與 CORBA 的關(guān)系。同時(shí)還給出了一個(gè)簡(jiǎn)單的三層 EJB 應用程序。 部署過(guò)程 Enterprise JavaBeans (EJB) 組件是在稱(chēng)為部署的特定過(guò)程中安裝的。由容器組件提供對部署過(guò)程的支持。在高級別上，部署由下列步驟組成： bean 的開(kāi)發(fā)人員創(chuàng )建必需的類(lèi)文件、接口文件和控制信息。 容器分析輸入文件并生成必要的類(lèi)。 容器將條目添加到指向本地對象的 JNDI 命名空間中。 EJB 組件的開(kāi)發(fā)人員編寫(xiě) bean 的 Java 源文件，此文件包含為這個(gè) bean 提供功能的業(yè)務(wù)邏輯方法，還包括 ejbCreate() 方法。bean 類(lèi)還必須實(shí)現 javax.ejb.SessionBean 接口或 javax.ejb.EntityBean 接口。此外，bean 的開(kāi)發(fā)人員編寫(xiě)接口文件，定義對 javax.ejb.EJBHome 接口和 javax.ejb.EJBObject 接口的擴展。EJBHome 接口的擴展，稱(chēng)為 bean 的本地接口，包含一個(gè)創(chuàng )建方法，并且如果 bean 是一個(gè)實(shí)體 bean，它還會(huì )包含一個(gè) finder 方法。EJBObject 接口的擴展，稱(chēng)為 bean 的遠程接口，指定在 bean 本身中定義的業(yè)務(wù)邏輯方法。 bean 的開(kāi)發(fā)人員提供由部署描述符、環(huán)境屬性和清單式文件組成的控制信息。 部署描述符是 javax.ejb.deployment.SessionDescriptor 對象或 javax.ejb.deployment.EntityDescriptor 對象的序列化實(shí)例。 環(huán)境屬性作為鍵-值對存儲在一個(gè)文件中，可通過(guò) java.util.Properties 對象訪(fǎng)問(wèn)此文件。 清單式文件是標識企業(yè)級 bean 及其相關(guān)文件所必需的。 企業(yè)級 bean 的類(lèi)文件、這兩個(gè)接口的類(lèi)文件、部署描述符文件、環(huán)境屬性文件和清單式文件都是使用名為 ejb-jar 的文件格式歸檔的。所生成的 ejb-jar 文件提供給容器，作為部署過(guò)程的輸入。 在部署時(shí)，容器分析 ejb-jar 文件的內容，并采取必要的操作使此 bean 可用。這些操作包括：生成實(shí)現 bean 的本地和遠程接口的新 Java 類(lèi)，將本地接口實(shí)現綁定到 JNDI 命名空間中，生成樁模塊和 skeleton helper 類(lèi)，后者是支持 RMI 通信所必需的。容器也可以生成 bean 的子類(lèi)，并入容器專(zhuān)用的代碼，以方便對 bean 的管理。部署時(shí)由容器生成的類(lèi)通常是容器專(zhuān)用的，而不像 EJB 組件本身那樣具有可移植性。 持久性、事務(wù)和安全 在為 EJB 組件提供持久性、事務(wù)和安全服務(wù)方面，EJB 容器可扮演主要角色。是將這些服務(wù)的職責指定給容器，還是假定職責由 bean 自身負責，EJB 規范為 bean 的開(kāi)發(fā)人員提供了靈活性。例如，對實(shí)體 bean 的持久性支持既可以由 bean 管理，也可以由容器管理。如果 EJB 組件開(kāi)發(fā)人員選擇使用容器管理式持久性，他們就會(huì )在部署描述符中添加一個(gè)稱(chēng)為 containerManagedFields 的屬性。根據 EJB 規范： “containerManagedFields 屬性的值是一個(gè)實(shí)例字段列表，企業(yè)級 bean 提供者希望，容器通過(guò)從數據庫加載或將其存儲到數據庫，來(lái)管理這些實(shí)例字段。企業(yè)級 bean 代碼不應該包含任何數據庫訪(fǎng)問(wèn)調用 -- 數據庫訪(fǎng)問(wèn)調用將由容器工具在部署時(shí)生成。 “專(zhuān)用于提供容器管理式持久性支持的容器，通常將提供豐富的部署時(shí)工具，以允許企業(yè)級 bean 部署者建立實(shí)例字段到基礎數據源的映射。一般認為，盡管容器提供者的工具簡(jiǎn)化了映射進(jìn)程，但映射進(jìn)程仍可能涉及到 bean 部署者（即映射進(jìn)程不是全自動(dòng)的）。”(Enterprise JavaBeans Specification 1.0) 除了支持容器管理式持久性以外，EJB 體系結構還支持容器對事務(wù)的管理。該規范規定： “Enterprise JavaBeans 是一種高級組件框架，它試圖使應用程序開(kāi)發(fā)人員不面對系統的復雜性。因此，大多數企業(yè)級 bean 及其客戶(hù)機不需要通過(guò)程序訪(fǎng)問(wèn)事務(wù)管理。”(Enterprise JavaBeans Specification 1.0) 當 bean 的開(kāi)發(fā)人員依賴(lài)容器進(jìn)行事務(wù)管理時(shí)，就稱(chēng)為容器管理式定界，容器使用在部署時(shí)提供的事務(wù)屬性： “無(wú)論客戶(hù)機何時(shí)調用企業(yè)級 bean，容器都會(huì )介入這個(gè)方法調用。這種介入允許容器通過(guò)事務(wù)屬性顯式控制事務(wù)定界。例如，如果企業(yè)級 bean 部署了 TX_REQUIRED 事務(wù)屬性，則無(wú)論何時(shí)，只要客戶(hù)機調用支持事務(wù)的企業(yè)級 bean，容器就會(huì )自動(dòng)啟動(dòng)事務(wù)，而客戶(hù)機并不與任何事務(wù)上下文相關(guān)聯(lián)。”( Enterprise JavaBeans Specification 1.0) 如果開(kāi)發(fā)人員選擇在 bean 內支持事務(wù)，則他們在部署描述符中指定 TX_BEAN_MANAGED 事務(wù)屬性，然后就可以在 bean 自身內部自由使用 javax.transaction.UserTransaction 接口劃分事務(wù)邊界。通過(guò)認出 TX_BEAN_MANAGED 事務(wù)屬性，容器就能知道不必介入事務(wù)支持。 通過(guò)增強 AccessControlEntry 對象和 RunAs 安全標識中指定的限制，容器為 EJB 組件提供安全支持。AccessControlEntry 對象在 bean 級別上或針對單個(gè)方法，將 Identity 對象與企業(yè)級 bean 相關(guān)聯(lián)。Identity 對象反映允許調用 bean 的方法的用戶(hù)或角色。當容器試圖訪(fǎng)問(wèn)數據源或另一個(gè) bean 時(shí)，它們也會(huì )將 RunAs 安全身份應用于 EJB 組件?？蓪?RunAs 身份設置為等同于某個(gè)特定用戶(hù)帳戶(hù)、有權限的系統帳戶(hù)或客戶(hù)機安全身份。訪(fǎng)問(wèn)控制和 RunAs 的信息是 bean 的開(kāi)發(fā)人員在部署描述符中指定的，將影響容器管理 bean 的與安全有關(guān)的行為方式。 雖然 EJB 1.0 規范也提到安全問(wèn)題，但更詳細的安全功能定義，見(jiàn)該規范的后續版本。 CORBA 和 EJB 技術(shù)的關(guān)系 公用對象請求代理程序體系結構 (CORBA) 為分布式對象的平臺中立和語(yǔ)言中立的計算環(huán)境奠定了基礎。在 CORBA 環(huán)境中，功能駐留于對象之中，而客戶(hù)機可通過(guò)對象請求代理程序 (ORB) 訪(fǎng)問(wèn)這些對象。完整的 CORBA 實(shí)現提供 ORB，外加稱(chēng)為 CORBA 對象服務(wù)和 CORBA 公用工具的幾個(gè)運行時(shí)服務(wù)。也可只提供 ORB，不提供相關(guān)聯(lián)的對象服務(wù)和公用工具（例如，IBM 就提供這樣的兩種獨立 ORB）。實(shí)現基本 ORB 功能的軟件稱(chēng)為 ORB 核心。為了支持語(yǔ)言無(wú)關(guān)性，CORBA 應用程序是用接口定義語(yǔ)言 (IDL) 編寫(xiě)的。該語(yǔ)言在語(yǔ)法上類(lèi)似于 C++，但不包含語(yǔ)義：IDL 中指定的操作是操作接口，而不是操作實(shí)現。由于它對多種平臺和多種語(yǔ)言的支持，以及源自其分布式特征的可伸縮性，CORBA 非常適合于管理企業(yè)規模的信息系統。 設計 EJB 規范也是為了支持企業(yè)信息系統。這樣說(shuō)來(lái)，CORBA 是一個(gè)競爭者嗎？根據 Frequently Asked Questions for Enterprise JavaBeans，答案是否定的： “實(shí)際上，EJB 技術(shù)很好地補充了 CORBA。CORBA 提供了一個(gè)強大的基于標準的基礎結構，可在此結構之上構建 EJB 服務(wù)器。EJB 技術(shù)使得在 CORBA 基礎結構的頂層構建應用程序變得更為容易。”（Enterprise JavaBeans 常見(jiàn)問(wèn)題解答） 雖然 EJB 規范和 CORBA 規范說(shuō)明的是不同的技術(shù)，但 EJB 實(shí)現目前利用 CORBA 技術(shù)的某些方面。一個(gè)例子就是 RMI/IIOP。EJB 規范要求 EJB 組件及其容器使用 Remote Method Invocation (RMI) 技術(shù)，實(shí)現分布式對象之間的方法調用。 RMI 規定遠程方法的語(yǔ)法和語(yǔ)義，但并不規定應使用何種傳輸協(xié)議提供網(wǎng)絡(luò )連接。CORBA Internet 對象請求代理程序間協(xié)議 (IIOP) 基本上定義了通過(guò) TCP/IP 傳輸 CORBA 消息的一種方法。開(kāi)發(fā)使用 IIOP 消息形式交換 RMI 數據的 EJB 實(shí)現，說(shuō)明了 EJB 應用程序怎樣才能有效地使用 CORBA 技術(shù)的各部分。這種網(wǎng)絡(luò )也支持與 CORBA 應用程序的互操作性，后者使用 IIOP 發(fā)送本地 CORBA 消息，與 RMI 無(wú)關(guān)。IBM 的 EJB 實(shí)現，即 WebSphere Application Server，優(yōu)化了 IIOP 的使用，方法是，弄清楚分布式對象何時(shí)駐留在同一臺服務(wù)器上，并且只在對象確實(shí)在遠程時(shí)才調用 IIOP。 為了方便既并入 EJB 技術(shù)，又并入 CORBA 技術(shù)的企業(yè)系統的開(kāi)發(fā)，Sun Microsystems 在 EJB 規范和 CORBA 之間創(chuàng )建了一種映射。將 EJB 體系結構映射到 CORBA，影響到 EJB 技術(shù)的幾個(gè)方面，包括對象分布、命名和事務(wù)。CORBA 映射的主要目的是，保證不同廠(chǎng)商構建的 EJB 服務(wù)器之間的互操作性?；ゲ僮餍蕴峁┮韵潞锰帲?CORBA 客戶(hù)機可以訪(fǎng)問(wèn)部署在基于 CORBA 的 EJB 服務(wù)器上的 EJB 組件 客戶(hù)機程序在事務(wù)中可以將對 CORBA 對象的調用，與對企業(yè)級 bean 的調用混合在一起 事務(wù)可以跨多個(gè) bean，而這些 bean 又位于來(lái)自不同廠(chǎng)商的基于 CORBA 的多臺 EJB 服務(wù)器上 使用來(lái)自某個(gè)廠(chǎng)商的 ORB 的客戶(hù)機，可以訪(fǎng)問(wèn)另一個(gè)廠(chǎng)商基于 CORBA 的 EJB 服務(wù)器上的 bean 對于要訪(fǎng)問(wèn) EJB 組件的 CORBA 客戶(hù)機來(lái)說(shuō)，bean 接口被映射到 IDL。例如，可將股票交易 bean 中定義的 buy() 和 sell() 方法，指定為 IDL 文件中的 CORBA 操作。非 bean 的 CORBA 客戶(hù)機，如 C++ 客戶(hù)機，可以訪(fǎng)問(wèn)這個(gè) bean，并用標準 CORBA 調用來(lái)調用 bean 的方法。如果容器使用 IIOP 作為它的分布式對象協(xié)議，則該容器的職責是，生成與企業(yè)級 bean 及其接口對應的 IDL。 EJB 命名服務(wù)，它以“CORBA 對象服務(wù)”命名服務(wù)為基礎，使 EJB 組件可用于 CORBA 客戶(hù)機。Java Naming and Directory Interface (JNDI) 可提供到 CORBA 命名服務(wù)的接口，同時(shí)，客戶(hù)機既可以通過(guò) JNDI 調用間接訪(fǎng)問(wèn)基礎命名服務(wù)，也可以通過(guò)“CORBA 對象服務(wù)” (COS) 命名 API 直接訪(fǎng)問(wèn)該服務(wù)。 EJB 事務(wù)支持依賴(lài)于 CORBA Transaction Service，即 Object Transaction Service (OTS)。Java Transaction Service (JTS) 代表 OTS 的 Java 綁定，它是語(yǔ)言中立的?；?CORBA 的 EJB 容器必須識別 CORBA 客戶(hù)機通過(guò) OTS 接口發(fā)出的事務(wù)邊界，以及 EJB 應用程序通過(guò) Java Transaction API (JTA) 接口發(fā)出的事務(wù)，JTA 是到 JTS 的應用程序級接口。JTA 還代表 Open Group XA 接口的 Java 綁定，以便將應用程序資源連接到外部事務(wù)管理器。JIA 中含存的 javax.transaction.UserTransaction 接口，為事務(wù)邊界的應用程序級控制提供 API。UserTransaction 接口，既可由其事務(wù)屬性設置為 TX_BEAN_MANAGED 的 bean 使用，以可由 Java 客戶(hù)機使用。 使用 EJB 組件 因為 EJB 體系結構被設計為高度靈活的，并支持使用任意復雜的方式連接企業(yè)級 bean，所以可構建許多不同的方案，來(lái)說(shuō)明應用程序可怎樣使用企業(yè)級 bean。一個(gè)有用的方案提出將 EJB 組件表示為三層信息系統的關(guān)鍵組件，該系統將企業(yè)數據、事務(wù)和應用程序資源連接到 Web 上。 基于 EJB 的三層編程模型視 Web 瀏覽器為第一層，視支持應用程序的 Web 服務(wù)器為第二層，視企業(yè)信息資源為第三層。在此編程模型中，除了 EJB 技術(shù)外，還實(shí)現了 Java servlet 技術(shù)、JavaBeans 技術(shù)和 Java Server Page (JSP) 技術(shù)。下圖顯示了各層的排列情況： 第一層是瘦客戶(hù)機 -- 通常是 Web 瀏覽器，它可以處理普通 Web 數據類(lèi)型，如 HTML 和 GIF，并支持 HTTP 通信。第二層是 Web 應用程序服務(wù)器，它是用代碼擴充的 Web 服務(wù)器，用來(lái)對能夠通過(guò) Web 服務(wù)器調用的應用程序提供運行時(shí)支持?，F有的 Web 應用程序都沿用 CGI-BIN 編程模型，但預計第二層應用程序開(kāi)發(fā)將轉向 Java servlet 編程模型，后者提供大幅改善的性能和可移植性。除支持 Java servlet 外，Web 應用程序服務(wù)器還將添加 EJB 服務(wù)器功能，以支持使用 EJB 組件的應用程序。第三層代表企業(yè)級信息資源，可以包括關(guān)系數據庫和面向對象的數據庫、事務(wù)監視器和定制的應用程序。EJB 技術(shù)在這一設計中扮演著(zhù)關(guān)鍵角色，因為，它使駐留在第二層上的應用程序組件，與組成第三層的企業(yè)資源之間的接口，得以標準化。 Java servlet、Java beans 和 Java server page 不是 EJB 應用程序方案的必需元素，但它們可與 EJB 組件一起工作，以提供基于 Java 的內聚性的應用程序環(huán)境。此處描繪的環(huán)境將以下職責指定給參與工作的 Java 組件： 給 Java servlet 指定了應用程序“控制器”的角色 JSP 頁(yè)面處理數據表示和用戶(hù)界面的任務(wù) Java bean 充當“數據封裝器”，存儲中間結果的數據 EJB 組件提供訪(fǎng)問(wèn)企業(yè)信息資源的機制 客戶(hù)可以使用一個(gè)假定的、基于 EJB 的 Web 應用程序更新現有的庫存，并用容器管理式持久性和容器管理式事務(wù)，將訪(fǎng)問(wèn)庫存數據庫的位置封裝在實(shí)體 EJB 組件的內部。庫存票據可通過(guò) Web 瀏覽器輸入，瀏覽器提供一個(gè) HTML 表單來(lái)捕獲產(chǎn)品編號、供應商，等等，并在提交時(shí)調用一個(gè) servlet。servlet 代碼充當應用程序控制器角色，確定哪些企業(yè)數據庫需要更新，需要用戶(hù)追加什樣的信息。servlet 可通過(guò)代表它的實(shí)體 bean 訪(fǎng)問(wèn)主庫存數據庫，并調用 JNDI 接口獲取對此 bean 的本地對象的引用，然后使用 finder 方法定位所請求產(chǎn)品編號的遠程對象。此時(shí)，通過(guò)調用遠程對象的方法，servlet 可更新庫存計數，接著(zhù)容器將此方法委托給 EJB 組件。因為容器根據數據庫更新，以對 bean 透明的方式劃分一個(gè)事務(wù)，而且以對 bean 透明的方式將數據寫(xiě)入數據庫來(lái)保證數據持久性，所以也就保持了數據的完整性。 從 EJB 組件返回到 servlet 的任何結果信息，都可以使用 setter 方法存儲在一個(gè)（非企業(yè)的） Java bean 的屬性中。此時(shí) servlet 可將控制權轉讓給一個(gè)適當的 JSP 頁(yè)面，以便將這些結果組合到表示格式中，并將結果返回給用戶(hù)。JSP 頁(yè)面很可能主要由靜態(tài)文本和有關(guān)單個(gè)事務(wù)的可變信息占位符組成。在向瀏覽器發(fā)送表示數據之前，JSP 頁(yè)面使用 getter 方法從 Java bean 的屬性中獲得可變數據元素。 基于 EJB 的三層設計提供了幾個(gè)好處，包括： 訪(fǎng)問(wèn)企業(yè)數據的業(yè)務(wù)邏輯可封裝在可重用、可移植的企業(yè)級 bean 中。 現有的企業(yè)系統只需很少修改或者根本不需要修改，就可以集成為企業(yè)級 bean。 企業(yè)應用程序所需的運行時(shí)服務(wù)，如事務(wù)和持久性，可以從 bean 中分解出來(lái)，并指定給此 bean 的容器。 無(wú)須更改 EJB 組件，即可修改控制應用程序流程的 Servlet。 Servlet 代碼可將注意力集中在應用程序控制邏輯上，而無(wú)須考慮數據表示。 JSP 頁(yè)面可將靜態(tài)和動(dòng)態(tài)內容混合在一起，生成表示信息。 用 Java 語(yǔ)言編寫(xiě)的系統組件，對于具有 JVM 的任何平臺都是可移植的。 結論 在開(kāi)發(fā)能夠支持關(guān)鍵任務(wù)的企業(yè)級信息系統的過(guò)程中，EJB 規范代表了 Java 技術(shù)的下一個(gè)發(fā)展階段。EJB 組件將隨 JavaBeans 規范引入的 Java 組件模型，擴展到服務(wù)器領(lǐng)域，從而使業(yè)務(wù)邏輯組件的開(kāi)發(fā)可以跨企業(yè)應用程序重用，并且可以跨支持 Java 的平臺移植。由于包含了基于 RMI 技術(shù)的對象分布，所以支持跨多層的可執行組件的分立，從而允許最大的實(shí)現靈活性和高度可伸縮性。如果將常規的企業(yè)應用程序運行時(shí)服務(wù)重新定義為可指定給容器抽象的對象服務(wù)，則允許 EJB 組件的開(kāi)發(fā)人員將精力集中在業(yè)務(wù)邏輯上，從而減小了通常與運行時(shí)服務(wù)相關(guān)的復雜性和平臺相關(guān)性。 增強 Java 運行環(huán)境，以包括命名和目錄服務(wù)的標準接口、關(guān)系數據庫訪(fǎng)問(wèn)、事務(wù)服務(wù)和遠程對象訪(fǎng)問(wèn)，使 Java 開(kāi)發(fā)人員能夠編寫(xiě)強健的企業(yè)應用程序，而不必離開(kāi) Java 編程環(huán)境。將其它 Java 技術(shù) -- 如 Java servlet 和 JavaServer Pages 技術(shù) -- 與 EJB 組件一起使用，可創(chuàng )建一個(gè)對于大型企業(yè)系統來(lái)說(shuō)足夠強健的緊湊編程模型，但由于使用了巧妙的接口，從而簡(jiǎn)化了開(kāi)發(fā)工作。而且，因為 EJB 體系結構是 JavaBeans 組件模型的邏輯擴展，所以作為 EJB 組件開(kāi)發(fā)的業(yè)務(wù)邏輯可跨多個(gè)企業(yè)應用程序重用。 企業(yè)級 bean 體系結構的另一個(gè)好處是，提供了現有企業(yè)信息系統的直接集成通道，此通道可能與 Java 編程語(yǔ)言或 bean 編程模型毫無(wú)共同之處。因為現有的企業(yè)信息資源 -- 如關(guān)系數據庫、事務(wù)監視器和業(yè)務(wù)應用程序的定制新品種 -- 可通過(guò)將它們封裝在 EJB 組件中連接到 Web 前端，而無(wú)須替換應用程序或重寫(xiě)主要代碼段，所以，客戶(hù)可保護其現有的 IT 投資。 考慮到 EJB 技術(shù)的巨大前景，IT 業(yè)界以相當大的興趣歡迎 EJB 規范，就不是什么令人驚訝的事了。EJB 體系結構提供的一個(gè)最大好處可能是，把業(yè)務(wù)邏輯編程與將業(yè)務(wù)邏輯和企業(yè)級服務(wù)器端運行環(huán)境的復雜集成分離開(kāi)來(lái)。如果部署了 EJB 組件的容器承擔了管理運行時(shí)服務(wù)（如持久性、事務(wù)和并發(fā)數據庫訪(fǎng)問(wèn)）的職責，則 bean 的開(kāi)發(fā)人員就可以自由地將精力集中在開(kāi)發(fā)封裝業(yè)務(wù)邏輯的軟件組件上。JavaSoft 副總裁表述了 EJB 技術(shù)的重要性（引自 Sun Microsystems 網(wǎng)站）： “‘Enterprise JavaBeans API 將為企業(yè)開(kāi)發(fā)人員和解決方案提供商提供一種新的戰略武器，供他們建立下一代行業(yè)領(lǐng)先的、基于關(guān)鍵業(yè)務(wù)的應用程序，’Sun Microsystems 的 JavaSoft 軟件產(chǎn)品部副總裁，Jon Kannegaard 說(shuō)：‘因為用 Enterprise JavaBeans API 設計的應用程序將與現有的企業(yè)系統一起工作，所以企業(yè)利用 Java 平臺會(huì )獲得新的競爭優(yōu)勢，同時(shí)還保留他們對現有技術(shù)的投資，’Kannegaard 繼續說(shuō)。 “使用 Enterprise JavaBeans API，開(kāi)發(fā)人員將能夠消除應用程序開(kāi)發(fā)過(guò)程中的復雜性。這是可能的，因為每個(gè) Enterprise JavaBeans 組件都封裝了一個(gè)基本的業(yè)務(wù)功能。目前開(kāi)發(fā)人員必須懂得如何編寫(xiě)業(yè)務(wù)邏輯和專(zhuān)門(mén)的系統級程序，以控制諸如安全性功能部件和處理多個(gè)事務(wù)的能力 -- 一項既枯燥又復雜的任務(wù)。Enterprise JavaBeans API 使全體開(kāi)發(fā)人員能夠將精力集中在編寫(xiě)解決業(yè)務(wù)問(wèn)題的邏輯上，而不是將精力集中在編寫(xiě)用以簡(jiǎn)化不同技術(shù)間交互作用的代碼上。”
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
