用EJB3.0 簡化EJB開發

引入 Enterprise JavaBeans （ EJB ） 是為了建構分布式元件。最初 ， 該技術承諾可以解決 CORBA 的所有問題并降低其複雜性。作為J2EE的核心，EJB經曆了幾次較大的修訂，并加入了許多特性，因而變得臃腫起來。從一開始，大部分開發人員就非常鐘愛EJB，甚至在沒有任何意義的情況下也在其應用程式中使用EJB。當項目不能正常擴充，又在使用EJB時，很多開發人員都會責怪EJB。

　　EJB 開發從來就沒有變得更為容易 ， 相反 ， 随着 EJB 規範的相繼釋出， 它還變得越來越複雜了。由于其複雜性和本身龐大的體系，EJB被喻為一頭大象。許多開發人員認為EJB就像油炸圈餅外邊多的一層糖。在狂熱奉行低糖飲食和低碳水化合物的年代，EJB專家委員會别無選擇，隻能努力提供“低糖”的EJB，以簡化EJB的開發。EJB 3.0專家委員會在JavaOne 2004會議期間釋出了 EJB 3.0規範 的第一個公開草案，并給出了一個輕量級模型的示例圖檔。

　　新的 EJB 子產品 給人的第一感覺是看上去很漂亮 ， 在本文中 ， 我們将讨論 EJB 3.0 如何把自己包裝得更為小巧玲珑 ， 進而吸引開發人員的眼球。在接下來的另一篇文章裡，我們将讨論EJB3.0如何簡化持久性模型。

EJB 模型的複雜性

　　在開始讨論EJB 3.0帶來的新特性之前，讓我們了解一下目前 EJB 模型的複雜性。

目前的 EJB 模型 需要建立若幹個元件接口并實作若幹個不必要的回調方法。

這些元件接口需要實作 EJB Object 或 EJB LocalObject ， 且需要處理許多不必要的異常情況。

EJB 部署描述符複雜 ， 且易出錯。

容器管理的持久性基于 EJB 模型 ， 也十分複雜 ， 不利于開發和管理。缺乏一些基本功能（如按标準方法使用資料庫序列定義主鍵等），且 EJBQL 十分受限。

由于有繼承性和多态性方面的限制 ， EJB 元件與其源對象并不相同。

EJB 的主要缺點之一就是不能在 EJB 容器外測試 EJB 子產品 ，而且 對開發人員而言 ， 要在容器内調試 EJB 是件可怕的事。

如果用過 EJB ， 您就會知道查找和調用 EJB 的有多複雜了。為了在應用程式中使用 EJB ，您必須了解 JNDI 的每個細節。

簡化開發人員視圖

　　如果用過最新的規範開發 EJB ， 就會發現開發一個類似于 HelloWorldEJB 這樣簡單的 EJB 有多困難。您至少需要兩個接口、一個bean類和一個部署描述符。大多數開發人員都在想：我要這些幹什麼？在 Oracle JDeveloper 、 Eclipse 和 XDoclet 等IDE中，開發人員可以輕松地完成這些瑣事，不過，在将EJB部署到所選的容器之前，開發人員仍需負責編譯這些類并包裝部署描述符。

　　EJB 3.0希望使用以下方法來克服這種複雜性：

無需使用接口和部署描述符 ， 而是由容器使用中繼資料标注生成。

将 普通 Java 類用作 EJB ，将 普通業務接口用于EJB。

中繼資料标注

　　EJB 3.0 對中繼資料标記的依賴性很強。在 JSR 175 下中繼資料标記得以标準化 ， 且将包含在 J2SE 5.0 中。标注是一種面向屬性的程式設計，與Xdoclet類似。不過 ， 與需要預編譯的 XDoclet 不同 ，标注是在 編譯時由 Java 編譯器編譯到類中的 （ 取決于如何設定 @Retention ） 。對開發人員而言，标注是類似于public一樣的修飾符，可以在類、字段、方法、參數、本地變量、構造函數、枚舉及包中使用。可以指定可用于生成代碼、歸檔代碼或在運作時提供特殊服務（增強的業務級安全或特定業務邏輯）的屬性，進而在Java代碼中使用标注。J2EE 1.5（5.0）的目标是用标注來簡化開發，因而它會提供自己的一組标注。标注使用@來進行标記，如下所示：

　　EJB 3.0 的目标是為了簡化開發 ， 因而要使用中繼資料标注來生成若幹類似接口一樣的工件 ，要 使用标注而不使用部署描述符。

使用 POJO 和 POJI

　　按照規範化的術語 ， JavaBeans 和接口經常分别被稱為 Plain Old Java Objects （ POJO ） 和 Plain Old Java Interfaces （ POJI) 。現在的EJB類和接口将分别類似于POJO和POJI。像home接口之類的不必要工件将不再需要。

　　開發人員要麼必須在 javax.EJBpackage 中實作一個 EJB 接口 （ SessionBean 、 EntityBean 或 MessageDrivenBean ），要麼就是 在 bean 實作類中使用标注。可以使用 Stateless 、 Stateful 、 MessageDriven 或 Entity 标注 bean 類。例如 ， 若将一個Stateless EJB 定義為 HelloWorld ，可以這樣 定義該 EJB ：

　　EJB 的接口可以是遠端的 ， 也可以本地接口 ，都 不必實作 EJBObject 或 EJBLocalObject 。必須為 EJB 提供業務接口 ， 并在 bean 類中實作該接口 ； 或者在部署期間生成該接口。對于Entity bean，接口是可選的；不過對于 SessionBean 和 MessageDrivenDriven ，接口則是必需的。如果沒有為session bean實作接口，将會生成一個bean接口。生成的接口類型可以是本地的或遠端的，取決于在bean類中使用的标注。從上面的代碼示例可以很清楚地看出， @Remote 是用于為 HelloWorld bean生成遠端接口的。如果需要，可以為EJB同時提供遠端接口和本地接口。

　　上面的例子清楚地表明 ， 開發人員沒有必要進行大量的尋常任務 ， 如定義接口和實作回調方法。

　　生成的接口的名稱源自 bean 實作類的名稱。生成的接口對開發人員來說的确不錯。不過，我認為生成接口并沒有多大優勢，因為大多數IDE（如Oracle Jdeveloper）都可動态生成這些接口。

　　草案中并沒有清楚地說明什麼是 EJB 查找的用戶端要求 ，以及 如何得到調用該 EJB 所需的這些接口。我建議不要使用生成的接口，原因如下：

生成的接口的名稱将從 bean 名稱派生

您可能不願意在生成的接口中公布 EJB 中 的某些方法 ， 而預設情況下 ， 生成的接口将公開所有的方法。

您需要用戶端接口來調用 EJB 。

　　不再需要回調方法

　　EJB2.1 及以前的版本要求為每個 EJB 實作若幹個生命周期方法 ， 如 ejbPassivate 、 ejbActivate 、 ejbLoad 、 ejbStore 等 ， 即使不需要這些方法 ， 也要這樣做。例如 ， Stateless 會話 bean 不需要 ejbPassivate ， 但仍需要在 bean 類 中實作該方法。由于現在的EJB3.0與普通Java類類似，是以實作這些生命周期方法已經不是必需的了。若在EJB中實作回調方法，容器就會調用該方法。

　　惟一的例外是 Stateful 會話 bean 中的 ejb Remove 方法 ， 在 Stateful 會話 bean 中可以使用 Remove 标注來标注 Stateful 會話 bean 業務方法。如果使用此标注 ， 它将會在被标注的方法完成 （ 正常或異常完成 ） 後提示容器删除 Stateful 會話 bean 執行個體。例如 ， 可以指定以下代碼在執行完 checkOut 方法後删除 Stateful 會話 bean 執行個體。

　　标注與部署描述符對比

　　如前所述 ， EJB 将不再需要部署描述符 ， 而将使用标注。部署描述符中的每個屬性的預設值都将被標明，開發人員無需指定這些屬性，除非要使用預設值以外的值。可以在bean類本身中使用标注來指定這些值。 EJB 3.0 規範為開發人員定義了一組中繼資料标注 ， 如 bean 類型、接口類型、資源引用、事務屬性、安全性等。舉例來說，假設我們希望對某一特定的EJB進行資源引用，則進行如下定義：

@Resource(name="jdbc/OracleDS", resourceType="javax.sql.DataSource")

　　J2EE 供應商 （ 如 Oracle 、 BEA 、IBM ） 将在其特定于供應商的部署描述符中添加屬性标注 ， 開發人員将使用這些标注來避免使用部署描述符。對于開發人員而言，這相當有吸引力，因為沒有了他們最讨厭的XML描述符。不過，這也帶來一些問題，在使用标記的之前，我們需要多幾分謹慎。

這妨礙了應用程式可移植性目标的實作 ， 因為如果 EJB 使用特定于供應商的部署描述符 ， 并且不重新編譯 / 重新包裝 EJB ，變化 就不會如願以償。

無需逐個檢視 ejb ，部署描述符就為彙編器 / 部署器 （ ejb-jar ） 提供了 EJB 子產品的完整視圖，它們還按照每一部署的要求調整這些視圖。如果描述符不可用或直到部署結束時才生成，那麼後果可能會不堪設想。

各種工具使用部署描述符在 EJB 子產品 中識别 ejb ， 當在容器間進行遷移時這會非常有用。 

EJB 3.0 規範還提出了一種重寫部署描述符中标注的方法。不過，規範中并沒有給出重寫标記的具體細節。

　　毫無疑問 ， 不再使用部署描述符将使新的開發人員能夠更輕松地開展工作 ， 但如果使用不當 ， 可能會引發管理問題。

簡化容器管理的持久性

　　EJB 3.0 對 CMP 實體 bean 進行了全面的革新 ，以吸引 開發人員的注意力。持久性架構 （ 如 OracleAS TopLink ） 、開放源碼的 Hibernate ） 已成為開發 J2EE 應用程式持久性架構的寵兒，而 實體 bean 由于既 複雜又沉重，已不再受歡迎。 EJB 3.0 采用了一個類似 TopLink 和 Hibernate 的輕量級持久性模型 ， 以簡化容器管理的持久性 ， 而這對開發人員而言無疑很有誘惑力。我們來簡單了解一下該實體bean計劃，關于持久性改進方面的詳細内容，我們将在另一篇文章中讨論。

　　實體 bean 正在 作為 POJO 而重獲新生，實體 bean 也 将不再需要元件接口。現在實體bean将被視為純粹的對象，因為它也将支援繼承性和多态性。

　　以下是 實體 bean 的源代碼 ：

　　觀察以上代碼 ， 可以發現此 bean 類是目前 實體 bean 的實體類 ， 而不是抽象類。

　　EJB QL 中對查詢功能進行了若幹改進 ，并 在 實體 bean 中支援 SQL 查詢。提出類似于 Hibernate 的新 EntityManager API （ TopLink ' Session API 的一個簡化版本）用于對實體 bean 進行操作 ， 即建立、删除和查找 實體 bean 。。

　　我們将在下一篇文章中仔細探讨提出的 CMP 實體 bean 的細節。

簡化 EJB 的用戶端視圖

　　使用 EJB （ 即查找和調用）非常複雜 ， 即使在應用程式中已經配置了 EJB 。J2EE 1.4和EJB 3.0規範正是要簡化EJB的用戶端視圖。

　　若現在就想使用 EJB ， 則必須在部署描述符中定義 ejb-ref 或 ejb-local-ref ， 查找 EJB 然後再調用。若想調用HelloWorld EJB，以下是在目前實作中調用EJB的最簡單方法。

　　首先在部署描述符中定義 EJB 引用 ， 如下所示 ：

　　然後 ， 利用以下代碼查找 EJB 。必須顯式處理 bean 執行個體的 EJB 查找和建立異常情況。

　　對于 環境變量 ， EJB 3.0 建議使用另一種方法，即使用 setter 注入來查找和調用 EJB 。

　　以下代碼是使用 setter 注入在另一個 EJB 中查找 HelloWorldEJB 的方法。

　　仔細研究上面的代碼 ， 可以發現 setSessionContext 方法用 @Inject 進行了 标注 ， 目的是将依賴注入用于該方法。注入的方法将由容器調用，以在該EJB上調用任一業務方法前設定EJBContext。

　　另一個注入 HelloWorld 會話 bean 的直接例子是隻使用 @EJBpublic HelloWorld myHello ， 這将導緻 myHello 通過一個 HelloWorld bean 執行個體注入。

　　可以使用依賴注入來查找任何類型的環境和資源引用 ， 如 DataSource 、 JMS 、 Mail 、 Web 服務 等。

容器外的可測試性和可用性

　　目前 EJB 開發人員所關心的一個主要問題不僅包括 EJB 開發的複雜性 ， 還包括測試這一難題。開發和測試EJB離不開EJB容器，開發人員也必須熟悉最終的部署平台，才能進行測試。對于很多企業開發人員而言，這可能不是主要問題。但對于為多個供應商提供支援的ISV而言，這的确是個問題，他們必須維護多個環境以測試其EJB。EJB 3.0規範承諾要提供在容器外進行測試的能力，但目前在規範的草案中并沒有提到細節。

結束語

　　盡管遺漏了很多包裝、組裝以及 API 的細節資訊 ， EJB 3.0 草案中的提議仍然對企業 Java 開發人員充滿了誘惑。把這些工作留給容器供應商來做，将有助于減少開發人員面對的複雜問題。這就要看容器供應商如何實施這些工作，并使EJB 3.0成為開發企業應用程式的必然之選了。   

本文轉自 牛海彬 51CTO部落格，原文連結：http://blog.51cto.com/newhappy/76889，如需轉載請自行聯系原作者