Java EE 中輕量級框架與重量級框架的概念

【專家解說】：操作簡單，要求硬件配置低。 量級主要是看容器的依賴性所決定的,依賴性越小,越輕量, Jim Rivera是 BEA 公司的一位技術主管，負責通過技術傳播推廣BEA 產品的應用。Jim 于1999 年加入BEA，擔任 BEA WebLogic Server 6、7 和8 版本的技術產品經理。在這個崗位上，Jim 負責各種服務器組件的策略和路線圖，包括 EJB、Web services、XML 和集群。Jim 在dev2dev 上有一個blog。dev2dev 通過電子郵件采訪了 Jim，獲得他對輕量級Java、應用程序框架和持久性框架，以及它們與應用服務器上企業(yè)計算的關系的看法。 輕量級Java dev2dev: 您是如何定義“輕量級Java”的？ Jim: 我認為，在Java 應用程序開發(fā)環(huán)境中，“輕量級Java”主要是指兩個東西：簡化的編程模型和更具響應能力的容器。輕量級Java 旨在消除與傳統(tǒng) J2EE API 有關的不必要的復雜性和限制。它也將縮短應用程序的部署時間，這對于支持開發(fā)最佳實踐（比如頻繁單元測試）非常重要。 dev2dev: 對您來說哪種輕量級技術是最重要的,輕量級Java 對終端用戶有什么幫助？ Jim: 很顯然，控制反轉 (IoC)模式在這個領域有著重大的影響。使用IoC，開發(fā)人員不需要編寫復雜的代碼來執(zhí)行查詢、處理基礎架構異?；蚬芾磉B接，就能夠解決對象依賴性問題。這有助于簡化代碼、將業(yè)務邏輯與基礎架構分離，從而使應用程序更易于維護。 輕量級Java 的另一個關鍵特征是，它不會強迫業(yè)務對象遵循平臺特定接口。這允許開發(fā)人員在普通舊式Java 對象(POJO)中實現(xiàn)業(yè)務邏輯,從而提高生產率。 與具體的類相反，當把開發(fā)的最佳實踐與界面相結合時,這些特性也使得對代碼進行單元測試容易得多。由于業(yè)務邏輯實現(xiàn)在 POJO中，所以不再需要將對象部署到重量級容器中以在單元測試中練習它。因此，將對象宿主在諸如 JUnit 之類的簡單測試環(huán)境中和為快速迭代單元測試“模擬”外部依賴性就變得微不足道了。 dev2dev: 作為一個技術傳播者，您一定目睹了許多新的和已部署的技術。您是否看到了轉向輕量級技術的趨勢？ Jim: 當然。在早期的采用者當中,明確地存在轉向諸如 Spring、Hibernate 和Beehive 之類框架的趨勢。它在應用程序的構建方式上有了明顯的不同，對未來 J2EE技術的方向有著積極的影響。例如，EJB 3.0就基本上是以使得輕量級Java盛行的概念為基礎的。 重量級 dev2dev:人們在想起應用服務器供應商時，通常把它們置于“重量級陣營”。我想您正在努力改變這種狀況，對吧？換言之，許多人認為應用程序供應商已經在實現(xiàn)重量級組件（比如 EJB 2.0）上付出了很大的代價，它們不愿意輕易放棄這些成果。 Jim: 首先，我認為沒有理由放棄在 EJB 上的現(xiàn)有投資，因為在某些場景中它仍然是最好的技術，例如當您希望通過 RMI遠程公開業(yè)務服務時。當然，諸如 EJB 之類的開放標準在保護客戶投資方面的價值也不能低估。 已經說過,我覺得人們經常過分強調 EJB在應用服務器中的實際價值。盡管這一點未必對所有的應用服務器供應商都適用，但是 BEA 只投入了相對較少的一部分開發(fā)資源來支持 J2EE API。我們工作最主要的目標是為宿主應用程序構建最可靠、可伸縮和容錯的內核。這些品質以及分布式事務服務、高速消息傳遞、遺留系統(tǒng)集成、高級 Web 服務、配置管理、診斷和故障排除和高級安全性，代表了 WebLogic Server 的真正價值，而且對總體擁有成本（TCO）有著巨大的影響。幸運的是，這些附加值對基于Spring 或Beehive 的應用程序的相關性和適用性與采用EJB 構建的應用程序是一樣的。雖然輕量級Java 技術使得應用程序的開發(fā)和維護更容易，但是它們不會代替真正高端應用服務器的品質。實際上，我們認為輕量級Java 與WebLogic Server 是一致的。 dev2dev: BEA 有沒有一個輕量級 Java 策略？BEA 實現(xiàn)輕量級 Java 的方法是什么？ Jim: 我們的策略是接納所有有利于提高開發(fā)人員生產率、在市場上為部署這些技術提供最佳平臺的技術。輕量級 Java有助于降低開發(fā)成本,WebLogic Server 則有助于降低運營成本,它們是一個非常強大的組合。 應用程序框架 dev2dev:由BEA贊助的Beehive項目顯然是一個輕量級 Java組件模型。您能否談談關于 Beehive 的情況，以及它在你們的整個策略中的地位？ Jim: Beehive是一個應用程序框架，致力于使J2EE 應用程序和基于SOA 的應用程序的開發(fā)更容易，它基于我們發(fā)布WebLogic Workshop 的經驗。它基于 POJO 和用于配置依賴性、服務質量等的元數(shù)據(jù)提供一個編程模型。元數(shù)據(jù)以 J2SE 5.0 代碼注解和外部 XML文件的形式獲得支持。存在一些用于訪問 J2EE資源、定義業(yè)務和 Web 服務以及基于 MVC模式開發(fā) Web 應用程序的組件。在我們努力提高開發(fā)人員生產率、鞏固 Java 整體市場的過程中，Beehive 是非常關鍵的一部分。 dev2dev: Beehive 可以被認為是一個“應用程序框架”。在Spring framework中提供了一種非常流行的輕量級 Java 方法。Spring（以及其他類似的框架）對于 BEA 有多重要？ Jim: 任何能夠幫助我們的客戶提高生產率的東西都對我們非常重要。我們歡迎并且接納這些技術,在適當?shù)臅r候也可以在技術層面上集成或者共享這些技術。 dev2dev: 你們考慮過明確支持這些框架嗎？ Jim: 就像我原來說過的,WebLogic Server具有很多方面的特性，能夠提供基于輕量級 Java 技術的應用程序。許多都是隱含的，然而在某些情況下，最小量的集成工作就能為輕量級 Java 開發(fā)人員提供重要的價值。舉個例子，當今存在的一些適配器允許 Spring 應用程序使用 WebLogic Server 的分布式事務能力，無需改變任何應用程序代碼。我們正在調查許多其他的機會，當然也一直在傾聽客戶的需求。 dev2dev: 我們已經看到輕量級框架對EJB 3 的一些影響。您認為這會擴展到J2EE的其他方面嗎？ Jim: 是的。我認為 JSR 175（即Java元數(shù)據(jù)）對于簡化 J2EE 編程模型是一種關鍵的支持技術。EJB 3.0使用了它，而且它也是 JSR 181（即Web Services 元數(shù)據(jù)，一個BEA 倡導的規(guī)范）的基礎。沒有理由相信它會就此停止。 輕量級持久性 dev2dev: IoC 容器看起來是輕量級 Java 的中心。另外的一個關鍵因素是POJO 和輕量級持久性。您能針對這個問題談談看法嗎？ Jim: 同樣，共同的主題是簡化編程模型。沒有比POJO更簡單的了。當然，企業(yè)開發(fā)要求我們有能力應用附加的品質,比如持久性規(guī)則、事務語義和 POJO 的安全約束。盛行很廣的方式是在元數(shù)據(jù)中定義這些品質，要么作為代碼注解，要么放在外部文件中。 dev2dev: 您是否覺得因為有多種方法用于完成持久性這樣的事情而存在一些危險？比如，我們很快將會有EJB 2、EJB 3、JDO、Hibernate，等等。 Jim: 我認為這只是成熟領域的一個實際情況。多年來，J2EE 規(guī)范沒有完全涵蓋這個特定的領域，自然就會導致其他規(guī)范的出現(xiàn)。就我所知道的在 JCP中發(fā)生的事情，我們似乎正在走向統(tǒng)一。這對于整個行業(yè)來說是一件好事。 未來 dev2dev: 您能預見一下輕量級 Java和 BEA 的未來嗎？ Jim: 我們將會繼續(xù)活躍于這個領域中，既通過諸如 Apache Beehive、XMLBeans、Eclipse和JCP 之類的渠道推動創(chuàng)新，又吸收諸如 Spring 這樣的其他領先技術，并且為了客戶的利益而展開協(xié)作。 艾伯特.愛因斯坦曾經說過：“一切都應該盡可能地簡單，但是不能更簡單?！贝_實如此，簡化一門理論的基本假設，使我們可以專注于真正關鍵的地方，這正是一直以來對科學真理的追求。企業(yè)軟件開發(fā)同樣如此。 提供一個將復雜的事物（例如，事務、安全或持久性）對開發(fā)者進行隱藏的應用框架是簡化企業(yè)軟件開發(fā)的關鍵。一個設計良好的框架可以提高代碼重用率、開發(fā)者的生產力及軟件的質量。然而，現(xiàn)有J2EE1.4的EJB2.1框架被普遍認為設計差，且過于復雜。不滿于EJB2.1的框架結構，Java開發(fā)者嘗試了各種各樣的中間件服務傳遞方法。最引人注目的是，以下兩個框架引起了開發(fā)者極大興趣并得到了大量正面的反饋。他們以未來企業(yè)Java應用所選框架的姿態(tài)展現(xiàn)。 Spring框架雖然很流行但并不是一個標準的開源框架。它主要由Interface21 Inc開發(fā)和控制。Spring框架結構是基于依賴注入(Dependency Injection (DI))的設計模式。它可以獨立或在現(xiàn)有的應用服務器上運行，而且大量地使用了xml配置文件 EJB3.0是由Java Community Process (JCP)制訂的標準框架，為所有主要的J2EE廠商支持。JBoss已經提供了試用版EJB3.0標準的開源或商業(yè)性質實現(xiàn)。EJB3.0充分利用了Java的注釋 這兩個框架結構都有一個共同核心設計理念：將中間件服務傳遞給耦合松散的POJOS (Plain Old Java Objects, 簡單潔凈Java對象)。 這樣的框架利用截取執(zhí)行上下文或在運行時將服務對象注入POJO來把應用服務“纏繞”到POJO。POJO本身并不關心這種“纏繞”，對這種框架結構也沒有什么依賴。因此，開發(fā)者可專注于業(yè)務邏輯和脫離框架的POJO單元測試。除此之外， 由于POJO并不須要繼承框架的類或實現(xiàn)其接口，開發(fā)者能夠極其靈活地搭建繼承結構和建造應用。 然而，在擁有同一理念的同時，兩個框架結構使用不同的方式來傳遞POJO服務。許多書籍或文章都將Spring 或EJB3.0和EJB2.1做了比較，但是對Spring 和EJB3.0的比較并沒有仔細研究過。在本文中，我將對Srping和EJB3.0框架背后的關鍵不同處進行考察，并討論其優(yōu)缺點。本文的觀點也適用于其它更少為人知的框架，因為他們都是對“耦合松散的POJO”的設計。希望這篇文章可以幫助你選擇適合你需求的最好框架。 廠商無關性 開發(fā)者選擇Java平臺其中最引人注目的理由之一：廠商無關性。EJB3.0正是一套設計為廠商無關的開放性標準。EJB3.0標準為所有企業(yè)Java社團里開源或商業(yè)性質廠商所開發(fā)和支持。它將開發(fā)者與應用服務器實現(xiàn)完全隔離。例如，JBoss的 EJB3.0實現(xiàn)基于Hibernate，Oracle的基于Toplink，但是開發(fā)者并不須要學習Hibernate- 或Toplink的具體API來使應用可在Jboss或Oracle上運行。廠商無關性使EJB3.0與現(xiàn)今其它POJO中間件框架區(qū)別開來。 但是，正如許多EJB3.0評論家迅速所指出的，在本文撰寫時EJB3.0標準還沒有到達一個最終版本。大概還有一到兩年的時間EJB3.0才能廣泛地為所有主要J2EE廠商所支持。即使你的應用服務器本身不支持EJB3.0，你仍然可以通過下載安裝”內嵌的”EJB3.0產品來運行EJB3.0的應用。例如，JBoss的內嵌EjB3.0是開源產品且可以在任何J2SE5.0兼容的環(huán)境運行(例如, 在任何Java服務器上)，此產品正處于軟件測試階段。其它廠商不久也將發(fā)布自己的內嵌EJB3.0產品，特別是針對標準中關于數(shù)據(jù)持久性的部分。 另一方面，Spring一直以來都是非標準的技術，在未來可預知的一段時間內這種情況將持續(xù)下去。雖然你可以在任何應用服務器上使用Spring框架，Spring應用會被鎖入在Spring本身和你選擇整合進Spring的具體服務中。 Spring框架是一個開源項目，但同時它有一個XML格式的配置文件和編程接口。當然任何一個非標準的產品都會有這種“鎖入”(lock-in)的情況，并不是Spring特有的。但Spring應用的長期生存能力仍然還得托Spring這個項目的福（或者是Interface21公司，它雇傭了大部分Spring核心開發(fā)人員）。除此之外，假如你用到任何一個具體的Spring服務，例如，Spring事務管理器或則Spring MVC，你也會被鎖入到這些API里。 Spring的應用對終端用戶是不可知的。例如，對數(shù)據(jù)持久服務，Spring框架兼容不同的DAO和JDBC的模版幫助類，如Hibernate, iBatis, 和 JDO。所以假如你需要為spring應用切換在數(shù)據(jù)持久化服務（例如從JBDC到Hibernate），你需要修改你的代碼以適合新的模版幫助類。 服務整合 從一個很高的角度上看，Spring框架處于應用服務器和服務庫的上方。服務整合的代碼（如，數(shù)據(jù)訪問模板和幫助類）屬于框架，并暴露于應用開發(fā)者。相反，EJB3.0框架與應用服務器高度整合，服務整合代碼也包裝在一個標準接口后面。 因此，實現(xiàn)EJB3.0的廠商可以大大地優(yōu)化整體性能和提升開發(fā)者的體驗。例如，在JBoss EJB3.0的實現(xiàn)中，當你在用EntityManager持久化一個Entity Bean時，后臺的Hibernate會話事務已經自動地幫定到調用方法的JTA 的事務上，在JTA 事務提交的同時Hibernate會話事務也提交了。你甚至可以使用一個簡單的 @PersistenceContext 注釋（稍候例子演示）將EntityManager和它后臺的Hibernate事務綁定到一個stateful session bean的應用事務中。在一個會話中應用事務橫跨多個線程，這在事務性網(wǎng)頁應用很有用，例如，多頁面的購物車。 由于高度整合的EJB3.0的框架，使簡單、集成的編程接口成為可能。Oracle EJB3.0框架和其后臺的Toplink持久化服務也同樣程度地整合。 另一個EJB3.0整合服務的絕好例子就是集群支持。假如你在一個服務器集群上部署了一個EJB3.0的應用，所有容錯(fail-over)、負載均衡、分布式緩沖和狀態(tài)復制都已經自動為應用所獲得可用。后臺的集群支持被隱藏在EJB3.0的框架后面，對EJB3.0開發(fā)者來說這些都是完全透明不可見的。 在Spring里，很難優(yōu)化框架和服務之間的通訊。例如，為了使用Spring里的聲明事務服務來管理Hibernate事務，你必須顯示地在XML文件中配置Spring TransactionManager和Hibernate SessionFactory對象。Spring必須電顯示地管理橫跨多個HTTP請求的事務。除此之外，沒有別的方法均衡Spring應用里的集群。 服務組合的彈性 由于Spring的服務整合代碼作為編程接口的一部份暴露在外，應用開發(fā)者有按自己需求裝配服務的彈性。這個特點使你能夠組合自己的輕量級應用服務器。Spring的一個普遍用法就是將Tomcat和Hibernate組合在一起支持數(shù)據(jù)庫驅動的web應用。在這種情況，Spring本身提供事務服務，Hibernat提供持久化服務——這種設置創(chuàng)建了一個袖珍型的應用服務器。 EJB3.0應用服務器典型地不提供這種根據(jù)需求任你挑撿服務的彈性空間。大多數(shù)時間，你得到的只是一系列包裝好的特性，其中一些你可能根本就不需要。但是如果應用服務器像JBoss一樣提供一個模塊性的內部設計，那么你可以只取其中一部分，而把不必要的部分剝去。在任何情況，去自定義一個功能強大的應用服務器是沒有什么價值的。 當然，假如應用已經超過單個點，那么你應該加入常用服務器上的服務，例如，資源池（resource pooling），消息隊列（message queuing）和集群（clustering）。就總體的資源消耗而言，Spring解決方法和其他EJB3.0解決方法一樣是重量級的。 在Spring框架里，具有彈性的服務裝配使得將虛擬對象而不是真正的業(yè)務對象綁定到應用中做脫離容器的單元測試更簡單。在EJB3.0應用中，大多數(shù)組件都是簡單POJO，他們可以很容易地在容器外被測試。但是對于與容器服務相關的對象（例如持久化實實體管理器EntityManager）建議用容器內測試。因為這樣會比虛擬對象測試方法更簡單，強壯及準確。 XML Vs.注解 從應用開發(fā)者的觀點上來看，Spring的編程開發(fā)接口主要基于XML配置文件而EJB3.0廣泛地應用Java注解。XML可以表達復雜的關系，但是它也冗長且不夠健壯；注解簡單明了，但是很難在注解里表達復雜或繼承性的關系。 Spring選擇XML或EJB3.0選擇注解都是有他們兩者框架后的體系結構決定的。因為注解只能容納很少的配置信息，只有整合前的框架（重頭戲都在框架里）才可以把廣泛地使用注解作為配置選擇。正如我們所討論過的，EJB3.0剛好符合這個要求，而Spring作為一個普通的DI框架并不符合。 當然，EJB3.0和Spring都相互取長補短，在某種程度上他們都支持XML和注解。例如，在EJB3.0中，XML配置文件作為一個可選的重載機制來改變注解的默認行為。注解也可以配置一些Spring服務。 通過例子是學習XML和注解方式之間差異的最好方法。在下面幾個環(huán)節(jié)里，讓我們來看看Spring和EJB3.0是怎樣提供關鍵服務給應用的。 聲明性服務 Spring和EJB3.0都將運行時服務（例如，事務、安全、日志和配置服務）綁定到應用。因為這些服務于應用的業(yè)務邏輯是沒有直接聯(lián)系，他們只是由應用本身管理。換句話說，這些服務在運行時由容器透明地應用到應用中。開發(fā)者或是管理者配置容器，準確地告訴它什么時候怎樣應用這些服務。 EJB3.0運用Java注解來配置聲明性服務，而Sring使用XML配置文件。在大多數(shù)情況下，EJB3.0注解方式對于這種服務更簡單明了。這里有一個在EJB3.0中將事務服務運用到POJO的例子。 public class Foo { @TransactionAttribute(TransactionAttributeType.REQUIRED) public bar () { // do something ... } } 你也可以為一個代碼段聲明多個屬性，應用多個服務。這是一個在EJB3.0里同時應用事務和安全服務到POJO的例子