EJB、Spring，這不是Java界最有名的兩大冤家，何以把它們扯在一起。其實Spring乃是EJB1.x、2.x的繼承者，正如EJB之前的COM、CORBA。他們的思想一脈相承，那就是企業級的組件化思想，也可稱之為理想！
一、非組件化的國內軟件行業
各個行業的企業總有一些核心業務，長久保持不變，新時期的新業務基本上都是圍繞核心業務展開。很長時間以來，IT技術的變化與企業業務的擴展存在著很大的矛盾。當企業的新業務開展之後，如何保證原有業務穩定運行的同時，新業務能夠得到IT的支持與擴展？當IT技術有重大進展後，如何保證原有業務的同時進行新技術改造？在以上兩種運動中，如何重用原有的技術成果？這是每一位負責任的系統管理員、CIO與及開發商所關心的事情。遺憾的是，組件化思想及實踐產生以前，這個矛盾基本上是極難解開的死結。絕大多數的做法就是重寫。
譬如DOS時代，很多單位都使用了單機foxbase版的財務系統，界面雖簡但穩定實用；到了Windows時代，流行VB、PB，於是系統重寫；再到B/S時代，系統再次重寫；到最近熱炒的RIA，系統是不是要再次重寫？對於很多小產商的作品而言，答案肯定是Yes。
很多同道可能會說，這樣正好啊？我們才可以不斷地賺錢。錯！
這樣的狀況叫“低水平重復”，這個術語經常被國人用來痛斥社會經濟領域的很多不合理現象。可惜我們這個自認為高智力的行業，很多時候就是在干這種愚事。每到技術革新，各企業要重花一次錢、重學一次操作、重轉一次數據，折騰得半死；而適應不了新技術的產商，隨被淘汰的代碼一同退出市場；適應不了新技術的程序員，只能轉行。要想不被淘汰，就必須緊跟時代風潮，不停地把精力放在新技術上，在領會業務上花的時間太少，最後導致我們的系統與企業的業務總是差半拍。因為原先快把業務搞清楚的程序員大多升官或離職了。
筆者以為這是軟件界，尤其是國內軟件界混亂的根本技術原因。由於技術長期得不到積累，我們不得不一次又一次吃外國的人剩飯。
那我們終究需要怎樣的軟件才能解決這些問題。
其實答案早就在我們身邊晃了太多年，偏偏我們視而不見。大家接個新外設，要不要換主機？加根內存條、換塊顯卡、聲卡要不要換主板？OS是不是只能用幾個特定的硬件，跑幾個特定的程序？而大家在OS下寫的程序，是不是在系統新版本運行不了？答案基本上是否定的。
OS可以適應全世界數以萬計的程序及其發展，為什麼我們的應用程序不能適應哪怕一個特定單位的變化和發展。為什麼我們的應用系統到了新環境下就要重寫？
原因就在於我們大多數應用程序規范性太低、耦合度太高。
要提高規范性、降低耦合度，就要不斷地設計、不斷地分層、不斷地抽象、不斷地重構。當我們終有一日把有用和成熟的代碼封裝成jar或是dll，不僅自己能重用，別人也能重用的時候，代碼其實才算合格。
現在大家都習慣用開源產品了，外國人熱衷的就是不斷地制造這樣的零件（組件）或技術。而我們中國人，熱衷的卻是組裝人家的零件和技術（一如其它涉及技術的產業）。很多外國人十多歲就做出了了不起的組件，而我們中國人卻把“不重復發明輪子”這種搬來的話掛在嘴在，結果是既不制造舊輪子，更沒有能力發明新輪子。很多人從業十多年都寫著亂糟糟代碼。
項目，不是說東西扔到客戶手上套足了錢，拍拍屁股就走人。成功的項目，要對客戶負責任。就算自己退了，也該把工作交接好。前面的工作成果後面用不上，只能說前面的工作不合格。
國內應用軟件界一直在走RAD的道路，一開始吃著爽，越到後面越不是滋味。不是說RAD不能用，而是說，一上來就RAD，注定被養成懶漢，早晚淪落成編碼機器。RAD誘使我們逃避思考，誘使我們逃避設計，最終讓我們被早早淘汰！
二、EJB、Spring的組件化實踐 在EJB之前，大家所知的COM和CORBA已然火過一頭了。這說明國外企業在經過長時間的信息化實踐後，已經深受上面所說“低水平重復”的非組件環境之苦。COM和CORBA的確解決了一些問題，但還沒有成為那種完整、成熟的體系。所以當初EJB出來的時候，業界瘋狂熱炒。這一方面是商業原因，更重要的是企業及開發者對組件化的熱切理想。其實EJB的確是成功地解決了很多問題，但由於一開始就定位在高端，技術上相當復雜，導致眾多開發者真正未能掌握，由此而產生了很多失敗的項目。
這個時候，MS的.NET開始熱了起來。.NET其實整個思想體系都是參照J2EE的。不過沿襲了MS產品一貫的易用風格，中小系統實現比較容易。但凡事有利有弊，MS為了迎合初學者偷懶的心理，架構上的RAD風格是相當明顯的。很多人不知不覺中又被養成了懶漢。這導致很多開發者拿著.Net這種OOP的企業級技術，繼續做過去那些高耦合的系統。最終結果，不論是開發者還是公司，都將重蹈以上筆者所說的覆轍。
應該說，J2EE一上來就強制開發者考慮OOP、分層、解耦、重用，這些很復雜但最重要的事情，最終必然後落得個“曲高和寡”的結果。但如果開發者真能以程序設計作為自己的畢生事業，就一定可以在Java的世界裡經過痛苦摸索，掌握軟件的精髓。
而後，火熱的Spring運動開始了。Rod集多年企業級開發的功力，創造性地開創了簡化版的EJB：Spring Framework。這裡有個前提，那就是Rod多年企業級開發的實踐，包括EJB的實踐。正是這個精通EJB的天才人物，才可能對EJB進行簡化和發揮。國內很多人自此運動後，把EJB以至於Sun形容得一文不值，卻忘了自己每天都在用Java這一偉大的語言，並實踐EJB這一技術所傳承的組件化思想。而初學者在不明就裡的階段，只記住了Spring的簡化，卻不知實踐組件化的根源所在。也就是說，不是Spring不好，而是說大家應該充分領會Spring所一脈相承的組件化解耦思想，而不只盯住Spring的簡化。
自此，Java界開始了無盡的混亂。人們每天都在考慮如何“簡化”J2EE，以至於把J2EE簡化到Web+DB，簡化到PHP那樣高耦合的程度，或者騎牆式的RoR。歷史再度倒退，組件化面臨嚴重危機，甚至於堅持組件化的Java也被殃及池魚。
這裡不得不稱贊一下Jdon和當家人banq。其實有一陣筆者也是Spring運動的熱心擁護者，對banq的EJB論調相當不感冒。待自己暈頭轉向了兩年，重回jdon，這才體會到banq的苦心。
正如眾所周知的英語學習無捷徑，好的程序設計同樣沒有捷徑。
banq這幾年冒天下之大不韪，一再堅持重申這個世間最簡單的真理，的確是值得敬佩的。
三、堅持組件化，打造真正的軟件工業
軟件發展到今天，其實應該並且能夠進入到工業時代了。
前面所說的企業軟件危機，既是技術問題，也是產業問題。
今天，地球人的各種產業都是大分工、大合作的工業化產業鏈。生產效率提高了，就業人群也隨之增加。在封建時代，大家都搞小作坊和行會，總覺得如果放開了，分工後大家會沒飯吃。但資本主義的實踐表明，越是分工合作程度高的產業，規模越大。原因很簡單，在生產效率提高的同時，消費被極大地刺激，以至於產業膨脹的速度仍趕不上消費。像現在的汽車，分工合作程度極高，使發達國家的人們買了一輛再買一輛，換了一輛再換一輛，結果是整個汽車產業的繁榮。
我們軟件業（尤以國內為甚）其實也一樣，表面上是沒事可做，事實上是由於軟件業整體的低效率，導致人們用不起軟件，或不敢用軟件。成天忙於低水平重復導致的低水平局部競爭，企業真正關心的很多需求得不到滿足。長久之後企業在信息系統得到的回報太小，自然不願意花錢在信息系統上。
其實大多數開發人員和開發商，都想充分滿足客戶的需求。可惜你幾十號人，打個比方，如果從種橡膠、挖鐵礦、到設計車型，焊接，推銷。什麼都要做，只怕是連小推車也造不出來的。
所以我們一定要分工合作。
現在電腦有了，OS有了，DB有了，編程語言有了，這些最難做的基礎工作外國人都做了。但進入企業級領域仍有無數的工作在等著你。國人在這一點上缺乏合作精神的劣習暴露無遺。明明只是精通業務，非要對設計指手劃腳；不過是分析專家，非要對不熟的技術挑三撿四；明明可以沿用原系統的精華部分，非要替換以示高明；更有不懂事的毛孩子，自以為可以用RAD搞定一切。很多國人的牛人都一種普遍的“超人”意識，老子天下第一，其他人都是垃圾。殊不知軟件業太大太復雜了，再新手的同道，也有很多你不知道的重要知識和奇思妙想；再高的所謂大蝦，也有無數的盲點和愚見。
所以要分工合作，一定要學會尊重他人，實事求是。
至於技術上的問題，其實以筆者愚見。至少spring已經基本上解決了“解耦”的重大難題。大家只要不偷懶，把自已寫的、別人寫的、書上看的，網上下的，好好琢磨透了，以spring這種大體上“無侵入”的框架裝配起來，即可基本上解決組件化的難題。
至於EJB，包括現在相當簡化了的EJB3，由於筆者所知甚淺，不便多述。望高手指點。
每一個程序員，不要想偷懶，努力實踐解耦自己的代碼。
每一個開發商，不要太急功近利，要努力提煉產品的類庫，盡力與其他產商互通互聯。
每一個系統管理員、CIO和企業領導更要謹記：高耦合的系統不能要、無類庫封裝的系統不能要，無測試的系統不能要、無類庫文檔的系統不能要。
這樣才可以杜絕國內急功近利的低水平軟件橫行市場，早日迎來中國軟件的組件化時代，形成健康、有秩、高效的軟件行業。
