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