POJO應用架構:Spring與EJB 3.0的對比 – JAVA編程語言程序開發技術文章

愛因斯坦曾經說過:”每件事物都應該盡可能簡單,而不是更簡單”。的確,對科學真理的追求都是為瞭簡化理論的根本假設,這樣我們才能處理真正麻煩的問題。企業級軟件的開發也是這樣的。
  簡化企業級軟件開發的關鍵是提供一個隱藏瞭復雜性(例如事務、安全性和永續性)的應用框架。良好設計的框架組件可以提升代碼的重復使用(reuse)能力,提高開發效率,從而得到更好的軟件質量。但是,目前J2EE 1.4中的EJB 2.1框架組件被人們普遍認為是設計較差的和過於復雜的。Java開發者對EJB 2.1很不滿,他們已經試驗瞭多種其它的用於中間件服務傳送的方法。最引人註目的,下面兩個框架組件已經引起開發者的巨大興趣和積極的反映。它們很可能成為未來企業級Java應用程序可供選擇的框架組件。

  · Spring框架組件是一個流行的,但是非標準的開放源代碼框架組件。它主要是由Interface21 Inc.公司開發和控制的。Spring框架組件的架構是基於依賴註入(DI)設計模式的。Spring可以單獨地或者與現有的應用程序服務器一起工作,它大量地使用XML配置文件。

  · EJB 3.0框架組件是一個標準的框架組件,由Java社區組織(JCP)定義,並受到所有主流的J2EE廠商支持。預發佈的EJB 3.0規范的開放源代碼和商業實現都可以在JBoss和Oracle上看到瞭。EJB 3.0大量使用Java註釋(annotation)。

  這兩個框架組件的核心設計理念是相同的:兩者的目標都是把中間件服務傳遞給松散耦合的簡單舊式Java對象(POJO)。這些框架組件通過在運行時截取執行內容或向POJO註入服務對象,把應用程序服務與POJO捆綁在一起。POJO本身不關心捆綁的過程,並且對框架組件幾乎沒有依賴。其結果是,開發者可以聚焦於業務邏輯,個人可以在沒有框架組件的情況下測試他們的POJO。此外,由於POJO不需要從框架組件中繼承或實現框架組件接口,開發者建立繼承結構和構建應用程序的時候都有高度的靈活性。

  但是,盡管兩者的設計理念是相同的,它們傳遞POJO服務時卻采用瞭完全不同的方法。盡管目前已經出版瞭大量的圖書和文章來把Spring或EJB 3.0與EJB 2.1進行對比,但是它們都沒有對Spring與EJB 3.0之間的差異進行認真的研究。在本文中,我將研究Spring和EJB 3.0框架組件之間的關鍵差異,並討論它們的優缺點。本文的主題也可以應用在其它一些名氣稍小的企業級中間件框架組件上,因為它們都聚焦於”松散耦合的POJO”設計。我希望本文能夠幫助你選擇符合需求的最佳的框架組件。
  廠商無關性(Independence)

  開發者選擇某種Java平臺的一個最重要的理由就是該平臺的廠商無關性。EJB 3.0是一個開放的、標準的、具有廠商無關性的平臺。EJB 3.0規范是由企業級Java團體中所有主流開放源代碼和商業廠商開發和支持的。EJB 3.0框架組件把開發人員與應用程序服務器實現(implementation)隔離開來瞭。例如,盡管JBoss的EJB 3.0實現是基於Hibernate的,而Oracle的EJB 3.0實現是基於TopLink的,但是開發人員並不需要學習Hibernate或TopLink的特殊API,就可以讓他們的應用程序在JBoss和Oracle上運行。廠商無關性把EJB 3.0框架組件與其它的POJO中間件框架組件區分開來瞭。

  但是,很多EJB 3.0的批評傢迅速指出,在寫這篇文章的時候,EJB 3.0規范還沒有達到最終發表的版本。在EJB 3.0被所有主流的J2EE廠商采用之前可能還需要一到兩年時間。但是,即使你的應用程序服務器還沒有自然地(natively)支持EJB 3.0,你還是可以通過下載和安裝一個”嵌入式的” EJB 3.0產品,在服務器上運行EJB 3.0應用程序。例如,JBoss嵌入式EJB 3.0產品是開放源代碼的,可以在任何與J2SE-5.0兼容的環境中(例如,在Java應用程序服務器中)運行。它現在正在進行beta測試。其它的廠商也可能很快發佈他們的嵌入式EJB 3.0產品,特別是用於規范的”數據永續性”部分的產品。

  另一方面,Spring一直是非標準的技術,而且在可以預見的未來它仍然是這樣的。盡管你可以把Spring框架組件與任何應用程序服務器一起使用,但是Spring應用程序都被”鎖定”在Spring自身和你所選擇的集成到Spring中的特定服務中瞭。

  · 盡管Spring框架組件是一個開放源代碼項目,但是它仍然擁有配置文件的專利XML格式和專利編程接口。當然,這類”鎖定”發生在任何非標準的產品上,Spring也不例外。但是它卻造成瞭:你的Spring應用程序的長期生存能力依賴於Spring項目本身(或Interface21 Inc公司,它雇傭瞭大多數Spring核心開放人員)。此外,如果你使用任何Spring特定的服務,例如Spring事務管理器或Spring MVC,你就被”鎖定”在這些API中瞭。

  · Spring應用程序需要知道後臺的服務提供者。例如,對於數據持續(data persistence)服務來說,Spring框架組件為JDBC、Hibernate、iBatis和JDO使用瞭不同的DAO和模板輔助類。因此,如果你希望為Spring應用程序更換持續服務提供者(例如從JDBC切換到Hibernate),你就必須重構自己的應用程序代碼,使用新的輔助類。

  服務集成

  從較高的層次看,Spring框架組件位於應用程序服務器和服務類庫之上。其服務集成代碼(例如數據訪問模板和輔助類)位於框架組件之中,並暴露給應用程序開發者。與此不同的是,EJB 3.0框架組件被緊密地集成到應用程序服務器中,服務集成代碼被封裝在標準的接口中。

  其結果是,EJB 3.0廠商可以積極地優化總體性能和開發者體驗。例如,在JBoss的 EJB 3.0實現中,使用EntityManager保持實體BeanPOJO的時候,下層Hibernate對話事務會自動地與該調用方法的JTA事務聯系在一起,當JTA事務提交的時候,它也會提交。如果使用簡單的@PersistenceContext註釋(本文後面有一個例子),你甚至於可以在有狀態的(stateful)對話bean中把EntityManager和它的下層Hibernate事務捆綁到一個應用程序事務上。該應用程序事務在一個對話中跨越瞭多個線程,它在事務性的Web應用程序(例如多頁面購物車)中是非常有效的。由於在JBoss中,EJB 3.0框架組件、Hibernate和Tomcat緊密集成,上述的簡單和集成的編程接口才得以實現。Oracle的EJB 3.0框架組件和其下層Toplink持續服務之間的也實現瞭類似層次的集成。

  EJB 3.0中集成服務的另一個例子是群集(clustering)支持。如果你在服務器群集中部署EJB 3.0應用程序,那麼所有的失效接續(fail-over)、負載均衡、分佈式緩存和狀態復制服務都是可以自動地供應用程序使用的。下層群集服務都隱藏在EJB 3.0編程接口後面,它們對於EJB 3.0開發人員來說是完全透明的。

  在Spring中,優化框架組件與服務之間的交互操作要困難得多。例如,為瞭使用Spring的宣告式事務服務來管理Hibernate事務,你必須在XML配置文件中顯式地配置Spring TransactionManager和Hibernate SessionFactory對象。Spring應用程序開發者必須顯式地管理跨多個HTTP請求的事務。此外,要在Spring應用程序中使用群集服務也沒有簡單的途徑。

  服務集成的靈活性

  由於Spring中的服務集成代碼是作為編程接口的一部分暴露的,應用程序開發者可以根據需要靈活地集成服務。這個特性允許你集成自己的”輕量級”應用程序服務器。Spring最普遍的使用方式是把Tomcat和Hibernate”粘合”在一起來提供簡單的數據庫驅動web應用程序。在這種情況下,Spring自身提供事務服務,Hibernate提供持續(persistence)服務–這種組織方式在Spring中建立瞭一個微型應用程序服務器。

  EJB 3.0應用程序服務器沒有賦予你挑選服務的靈活性。在大多數情況中,你得到一組事先包裝好的特性,而你隻需要其中的一部分。但是,如果應用程序服務器由模式化的內部設計主導(類似JBoss),那麼你就可能把它分開,去掉一些不必要的特性。在任何情況下,定制成熟的應用程序服務器都不是一個簡單的事情。

  當然,如果應用程序的范圍超越瞭單節點,那麼你可能需要捆綁來自普通應用程序服務器的服務(例如資源緩沖池、消息隊列和群集)。在總體的資源消耗方面,Spring解決方案與任何EJB 3.0解決方案一樣,都是”重量級”的。

  在Spring中,靈活的服務集成使得我們更容易把仿制(mock)對象(而不是實際的服務對象)捆綁到應用程序,用於在容器外部進行單元測試。在EJB 3.0應用程序中,大多數組件都是簡單的POJO,我們可以很容易地在容器外部測試這些它們。但是對於測試那些涉及到容器服務的對象(例如持續EntityManager),我們推薦在容器內測試,因為比起仿制對象的方法,它們更簡單、更牢固、更精確。 XML與註釋的比較
從應用程序開發者的角度來看,Spring的編程接口主要是基於XML配置文件的,而EJB 3.0廣泛使用瞭Java註釋。XML文件可以表達復雜的關系,但是它們同時也很冗長、牢固程度也較低。註釋簡單明瞭,但是在註釋中我們卻很難表達復雜的或層次的結構。

  Spring和EJB 3.0關於XML或註釋的選擇是依賴於這兩個框架組件後面的架構的:由於註釋隻能保存相當少的配置信息,隻有預先集成的框架組件(類似在框架組件中已經完成瞭大多數預備工作)可以廣泛地把註釋作為配置選項。我們已經討論過瞭,EJB 3.0符合這種需求,而Spring作為一個通用的DI框架組件,不符合這個需求。

  當然,EJB 3.0和Spring都在學習對方的最佳特性,它們都在某個程度上支持XML和註釋。例如,在EJB 3.0中XML配置文件是一個可選的重載機制,可以用於改變註釋的默認行為。註釋也可以用於配置某㏒pring服務。

  認識XML和註釋之間的區別的最好途徑是通過示例。在下一部分,我們會看到Spring和EJB 3.0是如何為應用程序提供關鍵服務的。
宣告式服務(Declarative Services)

  Spring和EJB 3.0都把運行時服務(例如事務、安全性、日志記錄、消息和定制服務)捆綁到應用程序上。由於這些服務都沒有直接地與應用程序的業務邏輯相關聯,因此它們不由應用程序自身

發佈留言