Jakarta EE 程式設計/Jakarta Enterprise Beans
EJB 代表 Enterprise JavaBeans。新手不要將其與 Core Java 的 Java Beans 混淆。
此頁面介紹 Enterprise JavaBeans 2.1。它還涵蓋了 EJB 2.0，後者仍在廣泛使用。正如 Java 平臺徹底改變了我們對軟體開發的思考方式一樣，Enterprise JavaBeans 徹底改變了我們對開發關鍵任務企業軟體的思考方式。它將伺服器端元件與分散式物件技術、非同步訊息傳遞和 Web 服務相結合，極大地簡化了應用程式開發任務。它自動考慮了業務系統的許多要求，包括安全、資源池、永續性、併發和事務完整性。
本書將向您展示如何使用 Enterprise JavaBeans 開發可擴充套件、可移植的業務系統。但在我們開始討論 EJB 本身之前，我們需要簡要介紹一下 EJB 所涉及的技術，例如元件模型、分散式物件、非同步訊息傳遞和 Web 服務。尤其需要了解元件事務監視器，即 EJB 底層技術。
假設您已經熟悉 Java；如果您不熟悉，請先閱讀 Java 程式設計。本書還假設您熟悉 JDBC API，或者至少熟悉 SQL。如果您不熟悉 JDBC，請參閱 使用 SQLite 的 Java JDBC。
Java 最重要的特性之一是平臺獨立性。自首次釋出以來，Java 一直被宣傳為“一次編寫，隨處執行”。雖然炒作有時有點過分，但使用 Sun 的 Java 程式語言編寫的程式碼在平臺之間具有非凡的獨立性。Enterprise JavaBeans 不僅是平臺獨立的，而且是實現獨立的。如果您使用過 JDBC，那麼您對這意味著什麼有一點了解。JDBC API 不僅可以在 Windows 機器或 Unix 機器上執行，還可以透過使用不同的 JDBC 驅動程式訪問許多不同供應商的關係資料庫（DB2、Oracle、MySQL、SQLServer 等）。您無需針對特定資料庫實現進行編碼——只需更改 JDBC 驅動程式，即可更改資料庫。EJB 也是如此。理想情況下，EJB 元件（企業 Bean）可以在實現 EJB 規範的任何應用程式伺服器中執行。這意味著您可以在一個伺服器（例如 BEA 的 WebLogic）中開發和部署您的 EJB 業務系統，然後將其移動到另一個 EJB 伺服器，例如 Pramati、Sybase EAServer、IBM 的 WebSphere 或開源專案，如 Apache Geronimo、OpenEJB、JOnAS 或 JBoss。實現獨立性意味著您的業務元件不依賴於伺服器品牌，這為您在開發和部署之前、期間和之後提供了更多選擇。
除了支援分散式業務物件外，Enterprise JavaBeans 還支援非同步訊息傳遞。EJB 2.1 還允許將企業 Bean 作為 Web 服務公開，以便其他 J2EE 應用程式以及在各種平臺上用其他程式語言編寫的應用程式可以呼叫其方法。EJB 2.1 中的 Web 服務支援 RPC 樣式和文件樣式的訊息傳遞。對 Web 服務的支援基於新的 Web 服務 API：JAX-RPC。
面向物件的語言（如 Java、C++ 和 C#）用於編寫靈活、可擴充套件和可重用的軟體——面向物件開發的三個公理。在業務系統中，面向物件的語言用於改進 GUI 的開發、簡化對資料的訪問以及封裝業務邏輯。將業務邏輯封裝到業務物件中是資訊科技行業最近的重點。業務是流動的，這意味著企業的商品、流程和目標會隨著時間的推移而發展。如果模擬業務的軟體可以封裝到業務物件中，它將變得靈活、可擴充套件和可重用，從而隨著業務的發展而發展。
伺服器端元件模型可以定義一個用於開發分散式業務物件的架構，該架構將分散式物件系統的可訪問性與物件化業務邏輯的靈活性相結合。伺服器端元件模型用於中間層應用程式伺服器，這些伺服器在執行時管理元件並使它們可供遠端客戶端使用。它們提供了基本的功能，使開發分散式業務物件並將其組裝成業務解決方案變得容易。
伺服器端元件也可用於模擬業務系統的其他方面，例如表示和路由。例如，Java servlet 是一個用於為三層架構的表示層生成 HTML 和 XML 資料的伺服器端元件。本書後面將討論的 EJB 2.1 訊息驅動 Bean 是可以用於使用和處理非同步訊息的伺服器端元件。
伺服器端元件與其他元件一樣，可以作為獨立的可執行軟體進行買賣。它們符合標準元件模型，並且可以在支援該元件模型的伺服器中執行，無需直接修改。伺服器端元件模型通常支援基於屬性的程式設計，允許在部署元件時修改元件的執行時行為，而無需更改元件中的程式設計程式碼。根據元件模型的不同，伺服器管理員可以透過將這些屬性設定為特定值來宣告伺服器端元件的事務、安全甚至永續性行為。
隨著組織的服務、產品和操作流程的發展，可以重新組裝、修改和擴充套件伺服器端元件，以便業務系統反映這些變化。想象一下，一個業務系統是一組模擬客戶、產品、預訂和倉庫等概念的伺服器端元件。每個元件都像一個樂高積木，可以與其他元件組合起來構建業務解決方案。產品可以儲存在倉庫中或交付給客戶；客戶可以預訂或購買產品。您可以組裝元件、拆卸元件、以不同的組合使用元件並更改其定義。基於伺服器端元件的業務系統是流動的，因為它被物件化了，並且它是可訪問的，因為元件可以被分佈。
Oracle 對 Enterprise JavaBeans 的定義是
- “Enterprise JavaBeans 架構是用於開發和部署基於元件的分散式業務應用程式的元件架構。使用 Enterprise JavaBeans 架構編寫的應用程式是可擴充套件的、支援事務的和多使用者安全的。這些應用程式可以編寫一次，然後部署在任何支援 Enterprise JavaBeans 規範的伺服器平臺上。”
這很拗口，但對於 Sun 如何定義其許多 Java 技術來說並不典型——您是否曾經閱讀過 Java 語言本身的定義？大約長兩倍。本書對 EJB 提供了一個更簡短的定義
Enterprise JavaBeans 是用於分散式業務應用程式的標準伺服器端元件模型。
這意味著 EJB 提供了一個標準模型，用於構建表示業務物件（客戶、庫存中的商品等）和業務流程（購買、庫存等）的伺服器端元件。構建出一組符合業務需求的元件後，您可以將它們組合起來建立業務應用程式。最重要的是，作為“分散式”元件，它們不必都駐留在同一臺伺服器上：元件可以駐留在最方便的位置：Customer 元件“駐留”在 Customer 資料庫附近，Part 元件可以“駐留”在庫存資料庫附近，而 Purchase 業務流程元件可以“駐留”在使用者介面附近：您可以執行任何必要的操作以最大程度地減少延遲、共享處理負載或最大化可靠性。
要了解 EJB，您需要了解分散式物件的工作原理。分散式物件系統是現代三層架構的基礎。在三層架構中，如圖 1-1 所示，表示邏輯駐留在客戶端（第一層），業務邏輯駐留在中間層（第二層），其他資源（如資料庫）駐留在後端（第三層）。
所有分散式物件協議都構建在相同的基本架構之上，該架構旨在使一臺計算機上的物件看起來像駐留在另一臺計算機上。分散式物件架構基於非常簡單的網路通訊層。本質上，此架構由三個部分組成：業務物件、骨架和存根。
業務物件駐留在中間層。它是物件的一個例項，用於模擬某個現實世界概念的狀態和業務邏輯，例如人員、訂單或帳戶。每個業務物件類都具有與其匹配的存根和骨架類，這些類專門為該型別的業務物件構建。例如，一個名為Person的分散式業務物件將具有匹配的PersonStub和PersonSkeleton類。如圖1-2所示，業務物件和骨架駐留在中間層，而存根駐留在客戶端。
存根和骨架負責使中間層的業務物件看起來好像在客戶端機器上本地執行。這是透過某種遠端方法呼叫(RMI)協議實現的。RMI協議用於透過網路通訊方法呼叫。CORBA、Java RMI和Microsoft .NET都使用自己的協議。中間層上每個業務物件的例項都由其匹配的骨架類的例項包裝。骨架在埠和IP地址上設定並偵聽來自存根的請求，存根駐留在客戶端機器上並透過網路連線到骨架。存根充當客戶端上業務物件的代理，並負責透過骨架將客戶端的請求傳達給業務物件。圖1-2說明了從客戶端到伺服器物件再返回的方法呼叫通訊過程。存根和骨架分別向客戶端和實現類隱藏了RMI協議的通訊細節。
業務物件實現一個公共介面，該介面宣告其業務方法。存根實現了與業務物件相同的介面，但存根的方法不包含業務邏輯。相反，存根上的業務方法實現將請求轉發到業務物件並接收結果所需的任何網路操作。當客戶端在存根上呼叫業務方法時，請求透過網路通訊，將呼叫的方法名稱和作為引數傳遞的值流式傳輸到骨架。當骨架接收傳入流時，它會解析流以發現請求哪個方法，然後在業務物件上呼叫相應的業務方法。從業務物件上呼叫的方法返回的任何值都由骨架流式傳輸回存根。然後，存根將該值返回給客戶端應用程式，就好像它在本地處理了業務邏輯一樣。
術語“元件模型”有很多不同的解釋。Enterprise JavaBeans指定了一個伺服器端元件模型。使用javax.ejb包中的一組類和介面，開發人員可以建立、組裝和部署符合EJB規範的元件。最初的JavaBeans™也是一個元件模型，但它不是像EJB那樣的伺服器端元件模型。事實上，除了共享“JavaBeans”這個名稱之外，這兩個元件模型完全無關。過去，很多文獻將EJB稱為原始JavaBeans的擴充套件，但這是一種誤傳。這兩個API服務於截然不同的目的，EJB既不擴充套件也不使用原始的JavaBeans。
JavaBeans旨在用於程序內目的，而EJB則專為程序間元件設計。換句話說，最初的JavaBeans並非旨在用於分散式元件。JavaBeans可用於解決各種問題，但它主要用於透過組裝視覺（GUI）和小部件來構建客戶端。它是一個優秀的元件模型，可能是迄今為止為程序內開發設計的最佳模型，但它不是伺服器端元件模型。另一方面，EJB明確旨在解決在三層體系結構中管理分散式業務物件所涉及的問題。
鑑於JavaBeans和Enterprise JavaBeans完全不同，為什麼它們都被稱為元件模型？在此上下文中，元件模型定義了元件開發人員與託管元件的系統之間的一組契約。這些契約表達瞭如何開發和打包元件。一旦定義了元件，它就會成為可以分發並在其他應用程式中使用的獨立軟體。元件是為特定目的開發的，而不是為特定應用程式開發的。在原始的JavaBeans中，元件可能是按鈕或電子表格，可以根據原始JavaBeans元件模型中指定的規則用於任何GUI應用程式。在EJB中，有幾種不同型別的元件：表示資料庫中實體的元件（實體Bean）與其容器的契約略有不同，而表示業務流程的元件（會話Bean）則不同。例如，元件可能是由實體Bean表示的“客戶”業務物件，可以部署在任何EJB伺服器中，並用於開發任何需要客戶業務物件的業務應用程式。另一種型別的元件可能是由會話Bean表示的MakePurchase物件，該物件模擬客戶購買特定產品時發生的情況。（儘管購買行為本身並未在資料庫中表示，但購買涉及客戶、銷售人員、庫存、應收賬款以及可能的其他實體之間的複雜互動）。MakePurchase物件與其容器的契約不同於Customer物件，但它也可以部署在任何EJB伺服器中，並在任何需要支援購買的業務應用程式中使用。第三種類型的EJB，MessageDrivenBean，與其容器的契約略有不同，但它也可以部署在任何EJB伺服器中。
Enterprise JavaBeans並非憑空出現；它是眾多元件事務監視器 (CTM) 之一，而CTM又源於更舊的事務處理監視器（如Tuxedo）和物件請求代理。但是，EJB 最重要的競爭對手是 Microsoft 的 .NET 框架。.NET 的起源可以追溯到 Microsoft 事務伺服器 (MTS)，它可以說是第一個商用 CTM。MTS 後來更名為 COM+。Microsoft 的 COM+ 基於元件物件模型 (COM)，最初設計用於桌面使用，但最終被用作伺服器端元件模型。對於分散式訪問，COM+ 客戶端使用分散式元件物件模型 (DCOM)。
當 MTS 於 1996 年推出時，這是一個令人興奮的發展，因為它為業務物件提供了一個全面的環境。使用 MTS，應用程式開發人員可以編寫 COM 元件，而無需擔心繫統級問題。一旦業務物件設計為符合 COM 模型，MTS（現在是 COM+）就會處理所有其他事情，包括事務管理、併發和資源管理。
COM+ 已成為 Microsoft 新 .NET 框架的一部分。COM+ 服務提供的核心功能在 .NET 中基本保持不變，但開發人員看到的方式發生了重大變化。.NET 框架開發人員不是將元件編寫為 COM 物件，而是將應用程式構建為託管物件。所有託管物件，實際上是為 .NET 框架編寫的所有程式碼，都依賴於公共語言執行時 (CLR)。對於面向 Java 的開發人員，CLR 非常類似於 Java 虛擬機器 (VM)，而託管物件類似於 Java 類的例項；即 Java 物件。
.NET 框架透過 SOAP (簡單物件訪問協議) 協議提供一流的 Web 服務支援，這使得 .NET 世界中的業務元件能夠與用任何語言編寫的任何其他平臺上的應用程式通訊。這可能使 .NET 中的業務元件能夠普遍訪問，這是一個不容忽視的功能。事實上，.NET 是促使 Sun Microsystems 擴充套件 EJB 和 J2EE 平臺其餘部分以支援 Web 服務的動力。自 1995 年推出 Java 程式語言以來，Microsoft 的 .NET 平臺對 Java 平臺的主導地位構成了最大的威脅。
儘管 .NET 框架提供了許多有趣的功能，但它作為開放標準卻有所欠缺。.NET 框架中的 COM+ 服務是 Microsoft 的專有 CTM，這意味著使用此技術會將您繫結到 Microsoft 平臺。如果您的公司計劃在非 Microsoft 平臺上部署伺服器端元件，則 .NET 不是可行的解決方案。此外，.NET 框架中的 COM+ 服務專注於無狀態元件；沒有內建對永續性事務物件的支援。儘管無狀態元件可以提供更高的效能，但業務系統需要 CTM 提供的那種靈活性，其中包括有狀態和永續性元件。
什麼是標準的伺服器端元件模型？簡單來說，這意味著您可以使用 Enterprise JavaBeans 元件模型開發業務物件，並期望它們在任何支援完整 EJB 規範的應用伺服器上都能正常工作。這是一個非常強大的宣告，因為它在很大程度上消除了 Microsoft .NET 產品潛在客戶面臨的最大問題：對供應商“鎖定”的恐懼。使用標準的伺服器端元件模型，客戶可以承諾使用符合 EJB 規範的應用伺服器，並知道如果出現更好的伺服器，他們可以遷移到該伺服器。顯然，在使用供應商開發的專有擴充套件時必須小心，但這並不是什麼新鮮事。即使在關係資料庫行業——幾十年來一直在使用 SQL 標準——也存在大量的可選專有擴充套件。
擁有一個標準的伺服器端元件模型除了實現獨立性之外還有其他好處。標準組件模型為第三方產品的增長提供了途徑。如果眾多供應商支援 EJB，那麼建立附加產品和元件庫對軟體供應商來說更有吸引力。IT 行業已經看到這種型別的家庭作坊圍繞其他標準（例如 SQL）發展起來；現在可以購買數百種附加產品來增強儲存在符合 SQL 規範的關係資料庫中的資料的業務系統。報表生成工具和資料倉庫產品就是典型的例子。GUI 元件行業也見證了其自身第三方產品的增長。對於 Sun 最初的 JavaBeans 元件模型等 GUI 元件模型，已經存在一個健康的元件庫市場。
今天，許多針對 Enterprise JavaBeans 的第三方產品存在。已經為各種相容 EJB 的系統引入了用於信用卡處理、遺留資料庫訪問和其他業務服務的附加產品。這些型別的產品使 EJB 系統的開發比替代方案更簡單、更快，從而使 EJB 元件模型對企業 IS 和伺服器供應商都具有吸引力。預打包 EJB 元件的市場在多個領域不斷增長，包括銷售、金融、教育、網站內容管理、協作以及其他領域。
為了使事情變得更容易，也更有趣，我們將在這本書中討論所有概念，並將其置於一家名為“泰坦”的虛構郵輪公司的背景下。郵輪公司是一個特別有趣的例子，因為它包含了幾種不同的業務：它擁有類似於酒店房間的船艙，它像餐廳一樣提供餐點，它提供各種娛樂機會，並且需要與其他旅行業務互動。
這種型別的企業非常適合分散式物件系統，因為許多系統的使用者在地理上分散。例如，需要預訂泰坦船隻航程的商業旅行社需要訪問預訂系統。支援許多（可能是數百個）旅行社需要一個強大的事務系統來確保代理商能夠訪問並正確完成預訂。在本書中，我們將構建泰坦 EJB 系統的一個相當簡單的片段，重點關注預訂郵輪的過程。此練習將使我們有機會開發 Ship、Cabin、TravelAgent、ProcessPayment 等企業 Bean。在此過程中，您需要建立關係資料庫表以持久化示例中使用的資料。假設您熟悉關係資料庫管理系統，並且可以根據提供的 SQL 語句建立表。EJB 可以與任何型別的資料庫或遺留應用程式一起使用，但關係資料庫似乎是最常用的資料庫，因此我選擇它作為持久層。
要使用 EJB 開發業務物件，您必須瞭解 EJB 元件的生命週期和體系結構。這意味著從概念上理解 EJB 的元件是如何管理以及如何作為分散式物件提供的。
