什么是EnterpriseJavaBeans組件？(三）

2019-11-18 16:24:42

字體：大中小

來源：轉載

供稿：網友

　　出自：ibm KenNordby
第三部分：布署和使用 EnterPRise javaBeans 組件

本文的第 3 部分說明 Enterprise JavaBeans 組件的部署過程，部署并不僅僅是安裝，因為它通常還涉及代碼生成。部署還使用了一個特殊的部署描述符文件，此文件支持控制企業級 bean 行為（如某個 bean 是否需要事務）的參數。bean 部署的這一特性支持 bean 行為的說明性、綱領性規范的 EJB 目標。第 3 部分還比較了持久性的兩種主要類型，bean 管理式持久性和容器管理式持久性，并討論了 EJB 組件與 CORBA 的關系。同時還給出了一個簡單的三層 EJB 應用程序。
部署過程
Enterprise JavaBeans (EJB) 組件是在稱為部署的特定過程中安裝的。由容器組件提供對部署過程的支持。在高級別上，部署由下列步驟組成：

bean 的開發人員創建必需的類文件、接口文件和控制信息。
容器分析輸入文件并生成必要的類。
容器將條目添加到指向本地對象的 JNDI 命名空間中。
EJB 組件的開發人員編寫 bean 的 Java 源文件，此文件包含為這個 bean 提供功能的業務邏輯方法，還包括 ejbCreate() 方法。bean 類還必須實現 javax.ejb.sessionBean 接口或 javax.ejb.EntityBean 接口。此外，bean 的開發人員編寫接口文件，定義對 javax.ejb.EJBHome 接口和 javax.ejb.EJBObject 接口的擴展。EJBHome 接口的擴展，稱為 bean 的本地接口，包含一個創建方法，并且如果 bean 是一個實體 bean，它還會包含一個 finder 方法。EJBObject 接口的擴展，稱為 bean 的遠程接口，指定在 bean 本身中定義的業務邏輯方法。

bean 的開發人員提供由部署描述符、環境屬性和清單式文件組成的控制信息。

部署描述符是 javax.ejb.deployment.SessionDescriptor 對象或 javax.ejb.deployment.EntityDescriptor 對象的序列化實例。
環境屬性作為鍵-值對存儲在一個文件中，可通過 java.util.Properties 對象訪問此文件。
清單式文件是標識企業級 bean 及其相關文件所必需的。
企業級 bean 的類文件、這兩個接口的類文件、部署描述符文件、環境屬性文件和清單式文件都是使用名為 ejb-jar 的文件格式歸檔的。所生成的 ejb-jar 文件提供給容器，作為部署過程的輸入。

在部署時，容器分析 ejb-jar 文件的內容，并采取必要的操作使此 bean 可用。這些操作包括：生成實現 bean 的本地和遠程接口的新 Java 類，將本地接口實現綁定到 JNDI 命名空間中，生成樁模塊和 skeleton helper 類，后者是支持 RMI 通信所必需的。容器也可以生成 bean 的子類，并入容器專用的代碼，以方便對 bean 的管理。部署時由容器生成的類通常是容器專用的，而不像 EJB 組件本身那樣具有可移植性。

持久性、事務和安全
在為 EJB 組件提供持久性、事務和安全服務方面，EJB 容器可扮演主要角色。是將這些服務的職責指定給容器，還是假定職責由 bean 自身負責，EJB 規范為 bean 的開發人員提供了靈活性。例如，對實體 bean 的持久性支持既可以由 bean 管理，也可以由容器管理。如果 EJB 組件開發人員選擇使用容器管理式持久性，他們就會在部署描述符中添加一個稱為 containerManagedFields 的屬性。根據 EJB 規范：

“containerManagedFields 屬性的值是一個實例字段列表，企業級 bean 提供者希望，容器通過從數據庫加載或將其存儲到數據庫，來管理這些實例字段。企業級 bean 代碼不應該包含任何數據庫訪問調用 -- 數據庫訪問調用將由容器工具在部署時生成。

“專用于提供容器管理式持久性支持的容器，通常將提供豐富的部署時工具，以允許企業級 bean 部署者建立實例字段到基礎數據源的映射。一般認為，盡管容器提供者的工具簡化了映射進程，但映射進程仍可能涉及到 bean 部署者（即映射進程不是全自動的）。”(Enterprise JavaBeans Specification 1.0)

除了支持容器管理式持久性以外，EJB 體系結構還支持容器對事務的管理。該規范規定：

“Enterprise JavaBeans 是一種高級組件框架，它試圖使應用程序開發人員不面對系統的復雜性。因此，大多數企業級 bean 及其客戶機不需要通過程序訪問事務管理。”(Enterprise JavaBeans Specification 1.0)

當 bean 的開發人員依賴容器進行事務管理時，就稱為容器管理式定界，容器使用在部署時提供的事務屬性：

“無論客戶機何時調用企業級 bean，容器都會介入這個方法調用。這種介入允許容器通過事務屬性顯式控制事務定界。例如，如果企業級 bean 部署了 TX_REQUIRED 事務屬性，則無論何時，只要客戶機調用支持事務的企業級 bean，容器就會自動啟動事務，而客戶機并不與任何事務上下文相關聯。”(Enterprise JavaBeans Specification 1.0)

如果開發人員選擇在 bean 內支持事務，則他們在部署描述符中指定 TX_BEAN_MANAGED 事務屬性，然后就可以在 bean 自身內部自由使用 javax.transaction.UserTransaction 接口劃分事務邊界。通過認出 TX_BEAN_MANAGED 事務屬性，容器就能知道不必介入事務支持。

通過增強 accessControlEntry 對象和 RunAs 安全標識中指定的限制，容器為 EJB 組件提供安全支持。AccessControlEntry 對象在 bean 級別上或針對單個方法，將 Identity 對象與企業級 bean 相關聯。Identity 對象反映允許調用 bean 的方法的用戶或角色。當容器試圖訪問數據源或另一個 bean 時，它們也會將 RunAs 安全身份應用于 EJB 組件。可將 RunAs 身份設置為等同于某個特定用戶帳戶、有權限的系統帳戶或客戶機安全身份。訪問控制和 RunAs 的信息是 bean 的開發人員在部署描述符中指定的，將影響容器管理 bean 的與安全有關的行為方式。

雖然 EJB 1.0 規范也提到安全問題，但更詳細的安全功能定義，見該規范的后續版本。

CORBA 和 EJB 技術的關系
公用對象請求代理程序體系結構 (CORBA) 為分布式對象的平臺中立和語言中立的計算環境奠定了基礎。在 CORBA 環境中，功能駐留于對象之中，而客戶機可通過對象請求代理程序 (ORB) 訪問這些對象。完整的 CORBA 實現提供 ORB，外加稱為 CORBA 對象服務和 CORBA 公用工具的幾個運行時服務。也可只提供 ORB，不提供相關聯的對象服務和公用工具（例如，IBM 就提供這樣的兩種獨立 ORB）。實現基本 ORB 功能的軟件稱為 ORB 核心。為了支持語言無關性，CORBA 應用程序是用接口定義語言 (IDL) 編寫的。該語言在語法上類似于 C++，但不包含語義：IDL 中指定的操作是操作接口，而不是操作實現。由于它對多種平臺和多種語言的支持，以及源自其分布式特征的可伸縮性，CORBA 非常適合于管理企業規模的信息系統。

設計 EJB 規范也是為了支持企業信息系統。這樣說來，CORBA 是一個競爭者嗎？根據 Frequently Asked Questions for Enterprise JavaBeans，答案是否定的：

“實際上，EJB 技術很好地補充了 CORBA。CORBA 提供了一個強大的基于標準的基礎結構，可在此結構之上構建 EJB 服務器。EJB 技術使得在 CORBA 基礎結構的頂層構建應用程序變得更為容易。”（Enterprise JavaBeans 常見問題解答）

雖然 EJB 規范和 CORBA 規范說明的是不同的技術，但 EJB 實現目前利用 CORBA 技術的某些方面。一個例子就是 RMI/IIOP。EJB 規范要求 EJB 組件及其容器使用 Remote Method Invocation (RMI) 技術，實現分布式對象之間的方法調用。 RMI 規定遠程方法的語法和語義，但并不規定應使用何種傳輸協議提供網絡連接。CORBA Internet 對象請求代理程序間協議 (IIOP) 基本上定義了通過 TCP/IP 傳輸 CORBA 消息的一種方法。開發使用 IIOP 消息形式交換 RMI 數據的 EJB 實現，說明了 EJB 應用程序怎樣才能有效地使用 CORBA 技術的各部分。這種網絡也支持與 CORBA 應用程序的互操作性，后者使用 IIOP 發送本地 CORBA 消息，與 RMI 無關。IBM 的 EJB 實現，即 WebSphere application Server，優化了 IIOP 的使用，方法是，弄清楚分布式對象何時駐留在同一臺服務器上，并且只在對象確實在遠程時才調用 IIOP。

為了方便既并入 EJB 技術，又并入 CORBA 技術的企業系統的開發，Sun Microsystems 在 EJB 規范和 CORBA 之間創建了一種映射。將 EJB 體系結構映射到 CORBA，影響到 EJB 技術的幾個方面，包括對象分布、命名和事務。CORBA 映射的主要目的是，保證不同廠商構建的 EJB 服務器之間的互操作性。互操作性提供以下好處：

CORBA 客戶機可以訪問部署在基于 CORBA 的 EJB 服務器上的 EJB 組件
客戶機程序在事務中可以將對 CORBA 對象的調用，與對企業級 bean 的調用混合在一起
事務可以跨多個 bean，而這些 bean 又位于來自不同廠商的基于 CORBA 的多臺 EJB 服務器上
使用來自某個廠商的 ORB 的客戶機，可以訪問另一個廠商基于 CORBA 的 EJB 服務器上的 bean
對于要訪問 EJB 組件的 CORBA 客戶機來說，bean 接口被映射到 IDL。例如，可將股票交易 bean 中定義的 buy() 和 sell() 方法，指定為 IDL 文件中的 CORBA 操作。非 bean 的 CORBA 客戶機，如 C++ 客戶機，可以訪問這個 bean，并用標準 CORBA 調用來調用 bean 的方法。如果容器使用 IIOP 作為它的分布式對象協議，則該容器的職責是，生成與企業級 bean 及其接口對應的 IDL。

EJB 命名服務，它以“CORBA 對象服務”命名服務為基礎，使 EJB 組件可用于 CORBA 客戶機。Java Naming and Directory Interface (JNDI) 可提供到 CORBA 命名服務的接口，同時，客戶機既可以通過 JNDI 調用間接訪問基礎命名服務，也可以通過“CORBA 對象服務” (COS) 命名 API 直接訪問該服務。

EJB 事務支持依賴于 CORBA Transaction Service，即 Object Transaction Service (OTS)。Java Transaction Service (JTS) 代表 OTS 的 Java 綁定，它是語言中立的。基于 CORBA 的 EJB 容器必須識別 CORBA 客戶機通過 OTS 接口發出的事務邊界，以及 EJB 應用程序通過 Java Transaction API (JTA) 接口發出的事務，JTA 是到 JTS 的應用程序級接口。JTA 還代表 Open Group XA 接口的 Java 綁定，以便將應用程序資源連接到外部事務管理器。JIA 中含存的 javax.transaction.UserTransaction 接口，為事務邊界的應用程序級控制提供 API。UserTransaction 接口，既可由其事務屬性設置為 TX_BEAN_MANAGED 的 bean 使用，以可由 Java 客戶機使用。

使用 EJB 組件
因為 EJB 體系結構被設計為高度靈活的，并支持使用任意復雜的方式連接企業級 bean，所以可構建許多不同的方案，來說明應用程序可怎樣使用企業級 bean。一個有用的方案提出將 EJB 組件表示為三層信息系統的關鍵組件，該系統將企業數據、事務和應用程序資源連接到 Web 上。

基于 EJB 的三層編程模型視 Web 瀏覽器為第一層，視支持應用程序的 Web 服務器為第二層，視企業信息資源為第三層。在此編程模型中，除了 EJB 技術外，還實現了 Java servlet 技術、JavaBeans 技術和 Java Server Page (jsp) 技術。下圖顯示了各層的排列情況：

第一層是瘦客戶機 -- 通常是 Web 瀏覽器，它可以處理普通 Web 數據類型，如 Html 和 GIF，并支持 HTTP 通信。第二層是 Web 應用程序服務器，它是用代碼擴充的 Web 服務器，用來對能夠通過 Web 服務器調用的應用程序提供運行時支持。現有的 Web 應用程序都沿用 CGI-BIN 編程模型，但預計第二層應用程序開發將轉向 Java servlet 編程模型，后者提供大幅改善的性能和可移植性。除支持 Java servlet 外，Web 應用程序服務器還將添加 EJB 服務器功能，以支持使用 EJB 組件的應用程序。第三層代表企業級信息資源，可以包括關系數據庫和面向對象的數據庫、事務監視器和定制的應用程序。EJB 技術在這一設計中扮演著關鍵角色，因為，它使駐留在第二層上的應用程序組件，與組成第三層的企業資源之間的接口，得以標準化。

Java servlet、Java beans 和 Java server page 不是 EJB 應用程序方案的必需元素，但它們可與 EJB 組件一起工作，以提供基于 Java 的內聚性的應用程序環境。此處描繪的環境將以下職責指定給參與工作的 Java 組件：

給 Java servlet 指定了應用程序“控制器”的角色
JSP 頁面處理數據表示和用戶界面的任務
Java bean 充當“數據封裝器”，存儲中間結果的數據
EJB 組件提供訪問企業信息資源的機制
客戶可以使用一個假定的、基于 EJB 的 Web 應用程序更新現有的庫存，并用容器管理式持久性和容器管理式事務，將訪問庫存數據庫的位置封裝在實體 EJB 組件的內部。庫存票據可通過 Web 瀏覽器輸入，瀏覽器提供一個 HTML 表單來捕獲產品編號、供應商，等等，并在提交時調用一個 servlet。servlet 代碼充當應用程序控制器角色，確定哪些企業數據庫需要更新，需要用戶追加什樣的信息。servlet 可通過代表它的實體 bean 訪問主庫存數據庫，并調用 JNDI 接口獲取對此 bean 的本地對象的引用，然后使用 finder 方法定位所請求產品編號的遠程對象。此時，通過調用遠程對象的方法，servlet 可更新庫存計數，接著容器將此方法委托給 EJB 組件。因為容器根據數據庫更新，以對 bean 透明的方式劃分一個事務，而且以對 bean 透明的方式將數據寫入數據庫來保證數據持久性，所以也就保持了數據的完整性。

從 EJB 組件返回到 servlet 的任何結果信息，都可以使用 setter 方法存儲在一個（非企業的） Java bean 的屬性中。此時 servlet 可將控制權轉讓給一個適當的 JSP 頁面，以便將這些結果組合到表示格式中，并將結果返回給用戶。JSP 頁面很可能主要由靜態文本和有關單個事務的可變信息占位符組成。在向瀏覽器發送表示數據之前，JSP 頁面使用 getter 方法從 Java bean 的屬性中獲得可變數據元素。

基于 EJB 的三層設計提供了幾個好處，包括：

訪問企業數據的業務邏輯可封裝在可重用、可移植的企業級 bean 中。
現有的企業系統只需很少修改或者根本不需要修改，就可以集成為企業級 bean。
企業應用程序所需的運行時服務，如事務和持久性，可以從 bean 中分解出來，并指定給此 bean 的容器。
無須更改 EJB 組件，即可修改控制應用程序流程的 Servlet。
Servlet 代碼可將注意力集中在應用程序控制邏輯上，而無須考慮數據表示。
JSP 頁面可將靜態和動態內容混合在一起，生成表示信息。
用 Java 語言編寫的系統組件，對于具有 JVM 的任何平臺都是可移植的。
結論
在開發能夠支持關鍵任務的企業級信息系統的過程中，EJB 規范代表了 Java 技術的下一個發展階段。EJB 組件將隨 JavaBeans 規范引入的 Java 組件模型，擴展到服務器領域，從而使業務邏輯組件的開發可以跨企業應用程序重用，并且可以跨支持 Java 的平臺移植。由于包含了基于 RMI 技術的對象分布，所以支持跨多層的可執行組件的分立，從而允許最大的實現靈活性和高度可伸縮性。如果將常規的企業應用程序運行時服務重新定義為可指定給容器抽象的對象服務，則允許 EJB 組件的開發人員將精力集中在業務邏輯上，從而減小了通常與運行時服務相關的復雜性和平臺相關性。

增強 Java 運行環境，以包括命名和目錄服務的標準接口、關系數據庫訪問、事務服務和遠程對象訪問，使 Java 開發人員能夠編寫強健的企業應用程序，而不必離開 Java 編程環境。將其它 Java 技術 -- 如 Java servlet 和 JavaServer Pages 技術 -- 與 EJB 組件一起使用，可創建一個對于大型企業系統來說足夠強健的緊湊編程模型，但由于使用了巧妙的接口，從而簡化了開發工作。而且，因為 EJB 體系結構是 JavaBeans 組件模型的邏輯擴展，所以作為 EJB 組件開發的業務邏輯可跨多個企業應用程序重用。

企業級 bean 體系結構的另一個好處是，提供了現有企業信息系統的直接集成通道，此通道可能與 Java 編程語言或 bean 編程模型毫無共同之處。因為現有的企業信息資源 -- 如關系數據庫、事務監視器和業務應用程序的定制新品種 -- 可通過將它們封裝在 EJB 組件中連接到 Web 前端，而無須替換應用程序或重寫主要代碼段，所以，客戶可保護其現有的 IT 投資。

考慮到 EJB 技術的巨大前景，IT 業界以相當大的興趣歡迎 EJB 規范，就不是什么令人驚訝的事了。EJB 體系結構提供的一個最大好處可能是，把業務邏輯編程與將業務邏輯和企業級服務器端運行環境的復雜集成分離開來。如果部署了 EJB 組件的容器承擔了管理運行時服務（如持久性、事務和并發數據庫訪問）的職責，則 bean 的開發人員就可以自由地將精力集中在開發封裝業務邏輯的軟件組件上。JavaSoft 副總裁表述了 EJB 技術的重要性（引自 Sun Microsystems 網站）：

“‘Enterprise JavaBeans API 將為企業開發人員和解決方案提供商提供一種新的戰略武器，供他們建立下一代行業領先的、基于關鍵業務的應用程序，’Sun Microsystems 的 JavaSoft 軟件產品部副總裁，Jon Kannegaard 說：‘因為用 Enterprise JavaBeans API 設計的應用程序將與現有的企業系統一起工作，所以企業利用 Java 平臺會獲得新的競爭優勢，同時還保留他們對現有技術的投資，’Kannegaard 繼續說。

“使用 Enterprise JavaBeans API，開發人員將能夠消除應用程序開發過程中的復雜性。這是可能的，因為每個 Enterprise JavaBeans 組件都封裝了一個基本的業務功能。目前開發人員必須懂得如何編寫業務邏輯和專門的系統級程序，以控制諸如安全性功能部件和處理多個事務的能力 -- 一項既枯燥又復雜的任務。Enterprise JavaBeans API 使全體開發人員能夠將精力集中在編寫解決業務問題的邏輯上，而不是將精力集中在編寫用以簡化不同技術間交互作用的代碼上。”（新聞稿：Sun Releases Draft Enterprise JavaBeans Specification for Public Review）

參考資料

通過 Sun 網站的 associated FAQs 深入了解 Java 技術和 EJB 體系結構。
查閱 Enterprise JavaBeans Specification 1.0。
請參閱 Enterprise JavaBeans 規范的完整新聞稿。
請參閱 IBM WebSphere Application Server如何使用 EJB 技術。

作者簡介
Ken Nordby 是 IBM 軟件開發實驗室的軟件工程師，該實驗室位于北卡羅來納州 Research Triangle Park。作為 SWG ProdUCt Affinity Services 業務小組的成員，Ken 與為 IBM WebSphere Application Server （Enterprise JavaBeans 技術的 IBM 實現）進行開發和咨詢的 IBM 人一起工作。可以通過 nordby@us.ibm.com 與 Ken 聯系進入討論組討論。

（出處：http://m.survivalescaperooms.com）

上一篇：使用EclipseRCP的IBMWorkplaceManagedClient

下一篇：實例-用JSF實現文件下載