但是，就像本文中“J2EE缺乏對編程的支持”提到的一樣，J2EE這個平台沒有能夠提供一個令人滿意的應用程序編程模型（application programming model）。Sun公司和一些大的應用服務器供應商都想用開發工具來降低J2EE開發的復雜性，但是這些工具沒有其他的JAVA 開發工具優秀，後者有先進的重構工具，和.NET平台相比，J2EE的工具支持顯得很遜色。
很多J2EE開發工具自動產生的代碼像這些工具本身同樣復雜。在開源社區很多小型J2EE開發者選擇了另外一種開發方式—— 一些可以降低J2EE開發難度的開發框架,較為流行的比如： Struts, Hibernate, 和 Spring Framework，他們當今很多J2EE項目種扮演著重要角色。
為什麼要采用框架？
框架是一由一些類組成，正式這些類為應用程序提供了一個可重用的設計――或者我們經常提到的——應用程序種的一層。應用程序代碼訪問類庫從而執行任務，而框架是調用應用程序代碼，從而管理程序的流程。這就是經常說道的好萊塢原則：“不要試圖聯系我們，我們到時候自會通知你。”開發者寫的程序在運行時由框架調用。
設計一個在各種未知背景下都可以使用的框架是很有挑戰性的。框架很適合在復雜的J2EE開發中使用，它可以為開發者提供一個簡單易用的模型。采用一個經過良好設計的開源框架有很多好處：
·在好的框架下，開發者只需要寫一些必須的代碼；他們不需要直接接觸底層的API。 這一點很重要。
·經過良好設計的框架可以為程序提供清晰的結構並且提高程序的內聚性。好清晰的結構使得其他人可以更容易加入項目。
·一個容易使用的框架可以通過一些例子和文檔為用戶提供最佳實踐。
·采用成功的框架的代碼比自己的代碼容易測試
·框架只有提供了一些值得使用的功能才會變得流行。J2EE工程只有真正需要框架的時候才會用它，而自己的框架並不是這樣，後者是處於統治地位的。
J2EE本身也提供了一些框架。比如， Enterprise Java-Beans (EJB) container或者 Servlet engine，二者都運用了“ 采用了好萊塢原則”這個思想，並采用運行時調用來管理對象。像Struts這些開源web應用框架正式建立在這兩個框架的基礎上的，本文討論的重點也是像Struts這樣建立在J2EE上的框架，他們為開發者提供了更為簡單的模型，和其他的一些好處。
開源框架的出現
很多大型的J2EE項目都用自己的內部框架來隱藏平台的復雜性，直到最近人們才逐漸發現一些在很多項目中都存在的共有的難題，這些難題都可以由一個較為統一的解決方案來解決。而有的框架正好可以充當這些問題的解決方案。現在有種很明顯的趨勢：與從前的內部框架相比，這些框架將成為這些難題的更加“標准化 ”的解決方案。
J2EE平台的日益成熟是這些框架流行的一個原因。開發者知道有些地方是J2EE的標准API無能為力的，倚他們的經驗來看，要彌補這個缺陷是很困難的。於此同時，一些優秀的開源框架可供使用，它們提供了極為豐富的技術文檔，在它們背後還有一個專業的團隊做支持，並且一切都是免費的。
Struts，在web應用程序產生時就有的開源框架。在1999－2000年，開發者們意識到JSP“Model1”的缺陷，JSP中充斥著請求處理代碼和靜態數據模板，這意味著你不得不把業務邏輯和復雜的HTML以及其他的標簽混到一起。那個時候還沒有標准的框架和J2EE的標准支持，要解決這個問題開發者就得自己實現前端控制器，這樣可以把業務邏輯分離到java類中，從而可以減輕對JSP的維護難度。前端控制器模式經常運用在MVC架構中，MVC模式在OO語言的GUI開發中經常使用（這個名字總是讓人誤解，WEB MVC中的視圖是從模型中“拉”數據；而在經典MVC中，模型把事件“推向”視圖）。
最初的前端控制器實現質量參差不齊。2001～2002年間，Apache開源組織發布的Struts改變了這個狀況，雖然它並非一個完美的框架，但已經足夠使其成為該領域事實上的標准。
Struts向人們展示了開源框架的一些優點，比如，新手可以很容易地熟悉它的結構。2002年末，它成立很多J2EE項目很自然的選擇，每一個認真的J2EE開發者都會對它很熟悉。
Struts幾乎用才每一個J2EE項目中，這使得它成為J2EE架構的一個重要組成部分。甚至很多保守的組織也將其作為軟件底層的一部分，並同意接受Apache的開源協議條款。
Hibernate。下一個倒下的多骨諾米牌就是持久化。J2EE提供了兩個持久化的手段：JDBC，它是J2SE中訪問關系數據庫系統的標准API；另一個是實體Beans ,它是EJB中專門模型化持久化實體的組件。
JDBC以一種錯誤的編程模型來強制開發者用Java代碼來處理關系思想。而實體beans，先不說Sun和其他主要的J2EE供應商的吹噓，給人很笨重的感覺：起初這門技術的應用范圍很窄，連持久對象間的關系都不能處理。它使得應用程序難於測試，並且使用了一個很糟糕的查詢語言。直到2003年，即使EJB2.0和2.0做了很多改進，開發者們卻很少用它。
早期的嘗試
持久化問題的解決方案是由關系-對象映射（ORM）來解決的，它可以透明地持久化普通java對象（POJO）。該思想在注釋中有解釋。雖然這種方案並不是專屬java的。但相對與其他的社區而言比如.NET，ORM在java社區更加流行(.NET開發者總是對之抱有懷疑的態度)。
早在1990年，一些商業的ORM工具就出現了，比如TopLink。但由於其價格昂貴、結構復雜並且與Sun的實體bean標准相左，所以很少人會用。不管怎樣，在持久化POJO方面，這些工具與JDBC和實體Bean相比確實有了很大的進步
Java Data Object於2001年在Java Community Progress(www.jcp.org)的規范中出現。它為一般的POJO提供了大多數的持久化實現(盡管很多實現都是對關系數據庫的)。但Sun公司以及其他的J2EE技術提供商對該技術表現的很冷淡。所以JDO也沒有能夠流行。
Hibernate的出現。ORM領域在2002年發生了大變化，原因有兩個。首先，實體Beans在實踐中失敗，開發者們將其從J2EE中忽視掉了。它向開發者們說明了一個規范是如何將開發拉入泥潭的。
另外的一個原因是Hibernate的發布，它是第一個功能健全的解決關系對象影射解決方案。雖然在功能上，它沒有TopLink多樣。但在那些最常用的功能上，Hibernate實現的更加健壯，並且有一個非常專業的團隊提供全職的開發。Hibernate並不是全新的，它的ORM思想在這個領域很普遍，但它提供的編程模型比其他任何競爭者都容易使用、都來的直接，它為ORM的使用提供了更加易用、廉價的途徑。
於此同時，新一代的商業產品針對關系數據庫提供了極其高效的JDO規范的實現。這樣開發者的選擇就更豐富了；還有，TopLink也朝著開發者友好的方向前進，它的liscense越來越開放了。
ORM大獲全勝
所的這些因素是的ORM比以往更加規范。雖然很多項目仍然使用自己的持久層框架，但Hibernate，TopLink以及一些高端的JDO實現，使得使用自己持久層框架的難度相對變大、可維護性降低，自然，也沒有什麼理由去使用自己的框架了。
雖然這些框架的功能覆蓋范圍已經很大了，但仍有很多地方不在其中。比如，一個基於struts，hibernate的項目，業務邏輯很難搞定。盡管對於這種問題，J2EE規范提出了解決方案（EJB），但仍舊沒有一個合適的編程模型。
Spring
J2EE框架被大規模地運用到項目中，而項目總要負責這些框架以及自己業務代碼的連接，使之真正融合到一起。Spring就是專注於這個問題的，它和Hibernate融合的很好。
本質上講，Spring是IOC(Inversion of Control)和面向切面編程(AOP)的組合體。它是一個非侵入式的框架，增強了POJO的功能。從服務上講(With a service abstraction)，它將程序代碼從J2EE環境解耦到普通的java對象（自然，這些代碼可以脫離J2EE而在多種環境中運行）。它還在很多功能上提供了除EJB之外的選擇――比如為所有的POJO提供聲明式事務。Spring被廣泛運用到很多項目中，從小的web程序到大的企業應用程序。
在這個領域還有其他的產品，比如HiveMind和NamoContainer。前者和Spring的思想大致相同，只不過在IOC上有較大差異；後者將很多服務融合在PicoContainer的IOC容器中。這些產品的實現方式和J2EE的不同在於，它們都很輕便。
在有J2EE API下做測試是非常困難的，這些容器將POJO從J2EE API中脫離出來，從而大大降低了測試的難度。測試一個普通的java對象，不用象測試J2EE程序那樣，得先將應用程序部署到服務器上，要不就得自己動手模擬J2EE環境。提供日益流行的測試驅動的開發環境（對於開發者來說這是應得的），是這些輕量容器流行的關鍵因素。
下一個將會是誰？
人們日益對開源框架的重視，使得很多項目的成本大大降低，並且投放使用以及維護速度都增加了。現在的開源框架都有很高的質量，都提供了很好的文檔＆一些書籍讓開發者做參考。即便如此，兩大因素是的J2EE領域充滿了不確定性：開源領域和J2EE“標准”的沖突和AOP的日益重要。
開源和標准之間的沖突表現在兩個地方。一個是表現層，JSF的身後有Sun公司和其他的一些大公司，而在這個領域有Struts等開源產品與之競爭。在中間層，EJB 3.0采用J2SE5.0的annotations實現了依賴注入(dependency injection)的功能，但這個功能只是Spring的一個子集
在這兩個領域，開源產品都更加革新。JSP借鑒了ASP.NET，而Tapestry則采用了WebObjects的思想。
同樣的，不知道EJB3.0為何要嘗試著標准化依賴注入，即使這樣會使之不可避免地喪失很多功能。 EJB 3.0好像也要進入程序編寫領域，而J2EE規范在這方面還沒有涉足。
於此同時，AOP的重要性在J2EE社區猛增，在使用上，AOP也越來越受到開發者的青睐。像Spring、dynaop等被稱作“帶著雙拐的AOP”實現提升了AOP的知名度。而純粹的AOP技術比如AspectJ，在將來的幾年也會流行起來。
其次，JBoss通過JCP和EJB3.0保持一致，它極大地推動了AOP技術。但即使如此，JCP 還沒有轉向AOP跡象。
下一代的J2EE規范將擁抱更簡單的POJO編程模型，就像Spring和Hibernate做的一樣。J2EE開發者也注定要從“欺詐客戶”轉到以自己的編程經驗開發上來。這次改變將受到大多數人的歡迎，不像以前那樣每一個新規范發布後，最終都沒有能很好的實現。
