作者：熊節 / 插畫：虎頭錘
以 Spring 爲代表的輕量級 J2EE 架構方案，不僅是一種技術方案，並且內蘊了與敏捷方法一脈共通的價值觀。輕量級 J2EE 與 EJB 的技術方案之爭，背後是瀑布與敏捷的方法之爭。輕量級方案的流行，爲後來敏捷的傳播打下了羣衆基礎。
從 EJB 到 Hibernate
“其實我以前也用 EJB 的呀，”範凱的嗓門有一種穿透性，一下子就把全桌人的注意力吸引過來，“前兩年我做過一個規模很大的項目，當時就是用 EJB，在那個項目過程當中發現 EJB 有很多問題，然後纔開始找別的替代方案。”
“就找到了 Hibernate？”莊表偉問道。雖說都在上海，JavaEye 這一羣網友此前還沒在線下聚過，這次是藉着《程序員》雜誌幾位編輯來上海出差，順道拜訪當地作者，才聚在一起吃了一頓飯。莊表偉跟範凱在論壇上時有交流，真人還是第一次見。
“沒有呢，那會兒大概是 2002 年吧，Hibernate 還沒發佈，我都想過自己做一個輕量級的框架來替代 EJB。後來到 2002 年底的時候就知道了有 Hibernate，那時候剛發佈，很多地方不成熟，但是方向一看就知道是對的。所以我就開始研究，後來做項目也用，也推薦別人用。”
“對對，我記得你在彭晨陽的論壇上也推薦過 Hibernate，跟他還吵起來了。”
“可不是嘛，”範凱感嘆道，“那段時間我發現呀，有很多人完全是不認可開源軟件的，他們覺得必須要按照大公司的技術方案做架構才靠譜，你拿個什麼二十幾歲的年輕程序員做的開源框架出來推薦呀，他們覺得你不靠譜，你宣傳的這都是些什麼異端邪說。”
“其實要說軟件的能力和架構的水平，還真不見得誰優誰劣。”
“對，不見得，而且這些人對開源方案多半是不熟悉的，不像我呀，我對 EJB 很熟，所以我是真的對比過優劣取捨。他們的論點經常就是說你這是個開源框架，所以就不靠譜。是不是開源框架就不靠譜、大廠商的方案就靠譜，我看也不一定。”
“我覺得很多人也不是真的要維護 EJB，只是要一種確定性。”莊表偉沉思一會兒說道，“有一套完整的架構方案，就可以照着做了，哪怕裏面有坑，也是別人趟過的，自己沒有風險。如果放棄了 EJB 用一套開源框架，可能就要遇到很多未知的坑。沒有了確定性，很多人會感到不安全吧。”
“當然，也能理解，”範凱說道，“不過我相信，輕量級架構這套方案也會逐漸成熟，你看現在有 Hibernate、有 Spring、有 WebWork，用這些框架開發真的比 EJB 要輕鬆得多。越來越多的人會轉到這上面來貢獻和積累，完整的架構方案很快就會有。”
複雜 + 開發效率低下：敏捷先驅們對 EJB 的嫌棄
彭晨陽一直認爲，EJB（包括 Entity Bean）的能力是沒有問題的。他甚至遵循 J2EE 推薦架構重新搭建瞭解道論壇，使用了 Session Bean 和 Entity Bean，試圖“從實踐角度來證明成熟技術的合理使用是多麼重要”。
然而以 Hibernate 爲代表的一批開源 Java 框架的支持者對構建在 EJB 基礎上的“經典” J2EE 架構提出的挑戰，重點很大程度上不在功能的完備。開源先鋒們對 EJB 的批評，首先是過度複雜，然後是開發效率低下。
EJB 的設計初衷是要支持基於遠程過程調用（Remote Procedure Call，RPC）的分佈式應用架構，即把另一個進程（很可能位於另一臺機器上）當做一個普通對象，像使用普通的 Java 方法一樣發起跨進程乃至跨網絡的方法調用。
爲了達成這一目的，J2EE 應用服務器、尤其是 EJB 容器需要提供大量複雜的基礎設施支持，也因而極大地增加了使用 EJB 技術開發應用程序的複雜度。
一般而言，每個 EJB 組件至少需要 3 個 Java 類：業務接口、業務實現、RMI 骨架（skeleton），以及若干 XML 配置文件。即便應用服務器廠商提供了預編譯工具幫助生成部分代碼，使用 EJB 開發應用的複雜度仍然遠高於使用 POJO（Plain Old Java Object，普通 Java 對象）。
EJB 這種複雜度使大廠商能夠順理成章地把應用服務器軟件賣出高價，因此廠商的態度很明確：EJB 的複雜度是應對企業應用的複雜度所必需的。時任深圳金蝶中間件有限公司技術總監的袁紅崗聲稱“如果項目中沒有使用 EJB，就不能算是真正使用了 J2EE 技術”，表達的就是這樣一種態度。
然而敏捷的技術領袖們對此並不買賬。Martin Fowler 提出的“分佈式對象設計第一法則”就是“不要分佈你的對象”。以他爲代表的一批技術領袖推薦的架構思路是在一個 Java 進程裏完成所有業務邏輯， 用集羣解決單臺服務器負載過重的問題。這種架構風格實際上就把 Web 應用簡化成了一個單進程編程的問題：不是“使遠程調用變得透明”，而是根本沒有遠程調用。這樣一來，是否必須使用 EJB（並承受其帶來的複雜度），就不再像袁紅崗所宣稱的那樣毋庸置疑了。
倡導敏捷的技術領袖們拒絕 EJB 帶來的複雜度，關鍵原因是這種複雜度造成了開發效率的損失。儘管應用服務器廠商努力通過代碼生成和預編譯手段減少業務邏輯之外的代碼編寫量，但這些措施又拖慢了修改代碼之後看到反饋的節奏：對業務邏輯的每次修改必須經歷漫長的“預編譯—編譯—打包—部署”過程才能生效，這個過程會耗費短則數十秒、長則數分鐘的時間，這個時間間隔看似微小，卻會每天無數次打擊程序員頻繁執行測試的積極性，從而對測試驅動開發等強調“小步前進”的開發方法造成致命的打擊。
而這種對開發過程中頻繁響應能力的訴求，採用瀑布式開發方法的團隊沒有強烈的訴求。支持與反對 EJB 的兩羣人彼此都會感到對方難以溝通，開發方法的差異是重要的原因之一。
以 Gavin King 爲代表的一批年輕的企業應用架構師在他們職業生涯的早期就深受 Kent Beck、“Bob 大叔”、Martin Fowler 等敏捷先驅的影響，極限編程於他們而言是習以爲常的工作方式。基於敏捷的習慣，他們提出了對 Entity Bean、繼而對整個 EJB 體系的批評，不僅針對其能力、更針對其對快速反饋的影響。
並且，他們表現出了極強的技術主動性：沒有等待大廠商主導的 J2EE 規範委員會迴應，他們開發出了像 Hibernate 這樣的替代框架，並以開放源碼的形式將其發佈給全行業使用。
時至 2004 年左右，敏捷與開源這兩股細流彙集，形成了全面反對 EJB 的風潮，站在交匯處的也是一位深受極限編程薰陶的年輕架構師：Rod Johnson，他開發的開源框架有一個好聽的名字，叫做 Spring。
Spring：敏捷的輕量級 J2EE 方案
正式指出“所有 J2EE 應用都應該使用 EJB”這種說法其實是個迷思（myth），Rod Johnson 可能是第一人。
他用大量實踐經驗雄辯地指出，濫用 EJB 很可能“導致代價高昂的錯誤”，而所謂“不濫用”，在 Johnson 看來，只有 EJB 的很小一個子集（即無狀態 Session Bean）是值得使用的，其他部分都應該打上問號，使用無狀態 Session Bean 的理由也只是提供遠程方法調用（RMI）的一層封裝；然而轉過頭來，他馬上又提出，即使需要給其他應用程序提供服務接口，這種接口也可以用 HTTP 協議上的 Web 服務（例如當時流行的 SOAP 和後來流行的 REST）來實現，因此也不一定需要 EJB。
爲了讓這個“沒有 EJB”的架構在企業應用環境中切實可行，他提出了輕量級容器架構：用輕量級（即基於 POJO 的）容器管理業務對象，通過容器提供聲明式事務等基礎設施能力，從而“享用 EJB……結構上的優勢，又不受困於 EJB 的缺陷”。
Johnson 認爲，這種架構的缺點只有三點：
- 第一，它不能直接支持 RMI 遠程客戶端，但正如他之前所說，他首先就認爲 RMI 並不必要；
- 第二，與 EJB 技術規範相比，目前輕量級容器還沒有標準，但同時 POJO 對象本身就沒有標準化的需求；
- 第三，與 EJB 架構相比，這種架構對於開發者來說還有點陌生。
說得更直白一點，Johnson 認爲輕量級容器架構全面優於 EJB 架構，J2EE 應用開發已經不需要 EJB。並且，他開發了名爲 Spring 的輕量級容器，實現了自己闡述的架構。
當時國內有一大批年輕的一線技術人員正在積極地尋找 J2EE 企業應用架構和研發管理的實操指南，Spring 則提供了符合他們期待的答案：這個框架不僅提供了企業應用開發所需的數據庫訪問、事務管理等基礎設施能力，還從工程結構、測試管理、甚至代碼風格等方面提供了具體且可落地的參考。
Rod Johnson 對極限編程的偏好，以框架設計的形式具象化。例如 Spring 框架專門針對持久層、業務邏輯層和 Web 層分別設計了單元測試腳手架，鼓勵對各層組件開展測試驅動開發。這種對於一線工程實踐的重視，在 EJB、乃至此前的任何應用框架中都是沒有的。
基於 Spring 提供的參考，一個對 J2EE 經驗並不豐富的架構師可以在很短時間內建立起企業應用開發的基本結構與工作辦法，這是 Spring 在國內迅速積累了一批擁躉的原因。
從 2003 年 9 月建站開始，就有這樣一批與範凱經歷相似的一線技術人員加入了 “Hibernate 中文站”的討論。
這羣人圍繞 Spring 展開了大量高水平的討論，例如楊戈（ID：Younger）和陶文（ID：taowen）翻譯的《Spring 框架簡介》，在很短時間內積累了超過 5 萬次瀏覽，並被很多網站轉載。這些高質量內容的聚集，使範凱的網站很快成爲了華東地區一個小有知名度的技術論壇。
同時，這些討論也把論壇的主題方向由 Hibernate 帶向更爲廣泛的 J2EE 架構、技術與開發方法，這也是 2004 年初範凱將網站改名爲 JavaEye 的原因。
隨後的一段時間，JavaEye 論壇的一些高質量的內容在整個 J2EE 社區都有較大的影響，例如錢安川（ID：moxie）在業餘時間編寫的 WebWork 教程在 JavaEye 有超過 11 萬次瀏覽，作爲國內第一份針對 WebWork 框架的學習材料，被很多一線技術人員競相傳閱。
不過，在相當長的一段時間裏，JavaEye 的名聲仍然侷限於一個較小的範圍。這個發源於上海的技術社區在全國、全行業獲得一定的知名度，並把 Spring 爲代表的輕量級 J2EE 架構風格與敏捷的開發方法推向更廣的範圍，契機是 2005 年 Martin Fowler 的訪華之行。
以上內容摘自《中國敏捷史》。
作者簡介
作者：熊節，現任寶尊電商成都研發中心總經理，曾任 ThoughtWorks 總監諮詢師、 CSDN 技術主編。
IT 行業打拼 18 年，在金融、零售、政府、電信、製造業、全球醫療等行業的信息化建設方面有着豐富經驗。翻譯了《重構》《軟件工藝》《實現模式》等行業重要著作，是中國 IT 浪潮中敏捷發展的領航者之一。熊節擁有利物浦大學 MBA 學位。
插圖：虎頭錘，旅居墨爾本的老程序員，北郵博士、北大碩士，15 年編程經驗。目前從事支付系統相關業務，曾轉戰區塊鏈、通信行業。敏捷倡導者、手繪愛好者。