http://www.javajia.com/forum/viewtopic.php?t=89135
起點
在“J2EE”這個縮略語被第一次介紹給世人的時刻，也許沒有幾個人可以預料出它在日後的奇特歷程。那是在1999年6月的JavaOne年會上，時任Sun公司Java企業開發部門主管的Mala Chandra興奮地預告了Java世界的這位新成員。
那些不熟悉背景的聽衆們，揣摩着她演說中出現的一串串全新術語，表情大概又是驚喜、又是迷惑:一個完整的“多層企業開發架構”、以“容器”和“組件”的形式提供服務、一套“廠商中立的開放技術規範”、對開發者隱藏了不同平臺和“中間件”的技術細節、實現了企業級應用間的“無縫集成”等等。
在今天的開發者看來，這些似乎都已經是老生常談，但在當時的場景下，閃動在幻燈片上的每一個口號，都意味着聽衆們事後又要經歷一段困難的學習過程。
幸虧Chandra有一副了不起的口才；這位本科念建築學的印度裔高層主管，談起軟件架構來也有特強的空間想象力。她清晰地說明了設計J2EE架構的兩個初衷：首先，對於廠商，J2EE意味着一套開放標準，加入這個標準，他們的產品就可以運行在各種不同的操作系統和工作環境下，成爲一個成熟的企翟慫閭逑抵鋅商婊壞牟考?BR> 其次，對於開發者，J2EE是一套現成的解決方案，採用這個方案，企業應用開發中的很多技術難題（包括跨平臺移植、事務處理、安全性等等）就會迎刃而解，“信息像一條不間斷的河流，經過各種各樣的平臺和設備，從企業應用系統的這一端流向那一端”。
要想理解這段話在當時的實際效應，我們仍然要把時間指針撥回1999年。除了預備迎接千年蟲之外，99年你做了什麼？爲了回答這個犀利的問題，我翻出6年前的工作記錄，發現了自己那時參與的一個項目的規格說明書，它正好能提供一幅“Java企業開發”在1999年的標準照。
這是一家日本知名IT廠商的企業信息管理系統，運行在NetScape 3.0 Gold瀏覽器中的Java Applet界面，通過一個專用的中間層系統與Oracle 8數據庫連接。這個中間層已經相當現成、完善，能夠提供遠程對象調用、事務處理等一系列的底層服務；留給我們的任務只是完成服務器端業務對象代碼，以及相應的客戶端交互開發。
除了Applet客戶端有些特別之外，上述系統與今天常見的J2EE架構很接近；尤其是業務對象編碼也由home類、PK（主鍵）類、entity類等部分構成，很多機制都與EJB如出一轍??只不過這些類並沒有繼承javax.ejb包的接口，而是採用了專用的API。它與EJB之間的相似不像是偶然的，設計者肯定參照了Sun在1997年底推出的EJB 1.0技術規範。
換言之，在J2EE誕生伊始的語境中，市面上已經存在着很多程度不一的“準J2EE中間件”了。它們主要用於解決三大類問題：事務處理、分佈式對象管理和Web請求處理。首先，事務處理管理器（Transaction Processing Monitor）一直是高端企業計算領域的熱門產品，著名的應用服務器廠商BEA，正是通過收購事務處理軟件Tuxedo進入中間件市場的。另一方面，從90年代初開始，越來越多的人把“N層分佈式對象架構” 當成傳統的客戶端/服務器架構的替代方案。
那時剛剛興起的CORBA技術是推動這一趨勢的重要力量（比如說，前面提到的那個由日本廠商自行開發的專用中間層，就採用了CORBA作爲基礎架構）。最後，Java技術在Web領域中的應用也是當時初露頭角的熱點。
1997年6月，Sun在發佈一款“Java Web Server”的同時第一次公佈了Servlet API；沒想到這項技術副產品（連同1998年問世的JSP）正好迎合了廠商的戰略需要。對於上面提到的N層架構來說，HTTP服務是一個非常理想的前端；所以基於Java的Web引擎，也在此時成了企業級Java解決方案的一個必不可少的部分。
Java、Web、事務、分佈式對象，這幾股開發潮流匯合在一處，形成了當時最熱門的產品“應用服務器（Application Server）”或“中間件（Middleware）”。
爲了給定語“最熱門”作個註釋，我們可以參照一下BEA公司在1998年收購Web應用服務器廠商Weblogic的成交價：1.92億美元。而這並不是一樁孤立的收購，NetScape和Sun也以相近的價格買下了另外兩家企業Kiva和NetDynamics。
而這也正是J2EE規範出臺的背景：幾乎所有要廠商都推出了、或是正在趕製自己的應用服務器產品，但這個“應用服務器”究竟應該是什麼東西，競爭者們又各有表述、莫衷一是。
說到這裏，我們才梳理出了J2EE技術規範的第一個版本在1999年12月問世的實際意義。首先，它爲Java企業開發提供了一幅清晰的全景，各項分支技術在這個領域中的地位和作用得到了客觀、準確的定義。
至此大家纔對一個Java企業解決方案的構成要素有了基本共識。其次，它使用“容器”和“組件”等概念描繪了Java企業系統的一般架構，明確地劃分了中間件廠商和應用開發者的職責所在。
最後（但絕非最不重要地），J2EE通過一套公開標準規定了應用服務器產品的具體行爲，在執行此標準的廠商產品之間實現了一定程度的可替換性和互操作性。
當時的媒體用“B2B開發的默認標準”之類的說法歡呼這項里程碑式的成就??那些撰稿人哪裏知道，在J2EE與那個被稱爲“B2B” 的短命新貴之間，其實並不會有太多故事發生；同樣，他們也不會想到，J2EE要想成爲一種真正成熟的開發範式，前方還有一段遠爲艱辛的旅程。
社區的形成
記得Kruglinski在名著《Inside Visual C++》的某個版本中給出了一個Web瀏覽器的代碼例子；在這一節的開頭他說到：如果你幾年前開發了一個Web瀏覽器，那肯定會給你帶來上千萬的收益；但如果你現在纔想到開發這個東西??那也就是個C++語言的練習罷了。
在今天的程序員眼中，應用服務器似乎也成了價格低廉（如果不是全然免費）的日用消費品。所以，想要理解它們在那幾年的大行其道，就非得藉助Kruglinski這樣的智慧不可。
在1999年底，市面上可以找到30種以上自稱“Java應用服務器”的產品，可見當時這類軟件是網絡風險投資的寵兒。但是此時出臺的J2EE規範就像是一陣席捲整個產業的勁風，在一夜之間，所有人都有了判斷什麼是一個“應用服務器”的權威途徑。
爲了獲得一張J2EE競技場的入場券，各家廠商面臨兩項考驗：首先，要具有能夠覆蓋J2EE中所有主要技術的產品線。這在當時是一項非常苛刻的要求，在沒有開源產品可供參照的情況下，短時間內推出包括EJB容器、Web引擎和JMS中間件的整體解決方案，這決不是隨便哪家創業公司都能辦到的。
完成了若干次成功的併購之後，BEA在這一點上搶佔了先機，完整的產品線使它成了人們心目中的首選J2EE平臺提供商。其次，要讓產品通過Sun的J2EE兼容性測試。要做到這一點同樣不易：就連IBM的WebSphere也一時還沒達到百分之百的EJB支持。
到2000年底爲止，共有15家廠商能夠提供完整的J2EE解決方案，其中9家（包括Sun本身）實現了“J2EE兼容”，他們中間包括了日後這個領域的主要競爭者。毫無疑問，這是一次非常殘酷的行業洗牌，但留在場內的廠商也相應地形成了推動J2EE發展的主體力量。
上面說過，在它的孵化階段，Sun的J2EE團隊主管是女強人Mala Chandra，她本人雖不是工程師出身，但對技術有着很強的感知能力和想象力；J2EE一出臺就能夠爲人們提供一幅完整、直觀而不失深邃的圖景，此中當然有Chandra本人的大量貢獻。
在她直接領導下工作的幾位工程師，也都是Sun內部非常傑出的人才。無論是制定了JDBC、JMS等規範的Mark Hapner、JavaMail的設計者Bill Shannon，還是EJB的主要設計者Vlada Matena，後來都是業界一言九鼎的技術領袖。
這個班子的合作時間並不太長：2000年左右的那個時期正是IT界創業的黃金年月，Chandra很快就和Sun公司Java部門的總裁（也是創造Java的功臣之一）Alan Baratz一起，到一家剛起步的Email中間件公司Zaplet淘金去了；捷克裔的開發天才Matena也離開Sun開辦了自己的公司。留下的兩個人Hapner和Shannon先後擔任了J2EE技術的首席設計師。
多年以後，Hapner回憶起J2EE初創的那個時期，深感如今Sun對Java的左右能力已經大不如前：“現在，Java事實上屬於整個技術社區，它的發展有賴全體參與者的推動。”的確，如今Sun已經不太可能重演當年的開拓性功績，很難再爲一個已經成形的領域重繪版圖。
但正如上文所說，即使是在1999年，J2EE設計者們面對的也不是一張從未着墨的白紙。他們的設計始終要以各大廠商的現有產品爲出發點，這也是天才的設計師們做出的設計卻遠非完美的原因之一：與從頭設計一門全新的編程語言不同，J2EE規範從一開始就是各方博弈和妥協的產物。
很容易注意到，J2EE與Java社區的決策機制JCP（Java Community Process）是幾乎同步產生的。J2EE下屬的各種技術規範，包括1.4版之後的J2EE本身，都作爲待決規範議案（JSR，Java Specification Request）被納入了JCP的議程。
這些議案的審議過程很少是一帆風順的，幾乎每一個都要經歷18個月以上的拉鋸戰。在多項技術規範的審議過程中，我們都見到了這樣的現象：最初列名審議委員會的某家主要廠商，沒能等到該規範通過就已經被收購或倒閉了。
與微軟在.NET平臺上的乾剛獨斷相比，J2EE發展中的這個“牛步”特徵雖說是審慎和民主的表現，但終歸不符合軟件演化應有的速度。
J2EE社區中的另一股重要力量，當然是種類極爲豐富的開放源代碼項目。2002年以來，在J2EE領域的各個層面上，幾乎所有主流產品都有來自開源項目的替代方案，在其中很多位置上，開源產品反而是勝過商業產品的首選。
但請別誤解，這裏的“開源”並不意味着完全的自動自發，J2EE世界中的開源項目也與Linux或PHP世界頗爲不同。在很多非常成功的J2EE開源項目背後，我們都能發現商業機構的推動作用：Apache的Jakarta社區是IBM扶植的結果；實現了開源應用服務器JOnAS的ObjectWeb，則是許多法國IT廠商（包括若干政府部門）合資支持的一個聯盟組織……這些有商業背景的開源項目資金雄厚，人員齊整；更重要的是，從投資者到開發者，參與這些項目的很多人都體現了軟件工業中難得的非功利心態，因而最終推出的產品質量甚至高於同類型的商業軟件。在主流廠商之外，它們是支撐J2EE大廈存在的一組基石。
另一方面，不少開發者也間接地通過自己的開源產品獲得了可觀的盈利。這些人大多以免費的開源產品爲依託，以收費方式提供附加的諮詢、方案實施以及技術支持服務。Marc Fleury，開源應用服務器的JBoss創始人，不無矛盾地把自己倡導的這種商業模式稱爲“職業開源開發”。
無論叫它什麼，高端產品的開源化/免費化運動註定要在J2EE產業的發展過程中製造顯著的後果。“JBoss的行徑惡化了J2EE的商業環境，”這是McNealy先生2002年的著名論斷。他的推理過程如下：只有做好商業推廣，J2EE產品才能最終擊潰邪惡的.NET平臺；但開源服務器會降低主流廠商的銷售利潤；銷售利潤越低，用於商業推廣的預算就越少；因此，整個J2EE陣營都將受損於JBoss。
但在狂熱的開源運動支持者看來，以上論證的大前提就是可疑的。“難道只有會做廣告的軟件纔是好軟件？MySQL有過多少廣告預算”爭論的雙方都認爲對手誤解了軟件商業模型的實質。究竟誰才掌握了這裏的真理呢？也許只有根據J2EE的未來??也就是它的目標和終點（Telos）??才能做出最終的裁決。
技術的離心力
考察事物的演化，通常有兩種對立的方法。考古學家（Archaeologist）探究肇始和起源；目的論者（Teleologist）則揭示目的和終點。對於前者，“開端（希臘語Arche）”從根本上決定了此後的發展，參天大樹的繁茂都包含在種子最初的萌芽中；而對於後者，“目的（Telos）”纔是事物的根本和旨歸：誰沒見過樣態完善的樹，誰也就沒法弄懂種子到底是怎麼回事。
在J2EE五年之後，人們只能交替地用這兩種目光審視它的演化歷程。它的起源與它的目的、“它從何處來”與“它往何處去” 的問題緊密地交織在一起，誰拾起了其中的一個，誰也就要連同另一個一起回答。
今天的J2EE在多大程度上符合它的初衷？回答這個問題並不涉及對J2EE技術成敗的評判，而只是要考察一下：它是否還運行在最初開闢的那個空間之中。在事務處理、對象分佈化和Web請求處理這三個方面中，也許J2EE對事務和Web保持了一貫的忠誠。
我們記得Fleury喜歡重複的一個信條:“He who owns the transactional Web owns the Web（誰掌握了帶事務處理的Web，誰就掌握了Web）”Web接口是今天大部分J2EE應用暴露的唯一接口；而雖然事務處理的常用方法已經有了很大改變（藉助AOP機制，很多非EJB架構的系統也自如地實現了聲明式的事務處理），但對事務的重視當然仍將是J2EE開發中的要素之一。
換言之，在5年的演化中，J2EE發生的最大變化可能就在於它放棄了對“分佈式對象模型”的強調。EJB2.0引入的本地接口使得Web層與EJB層可以運行在同一個Java虛擬機中，從而使Web容器與EJB容器的物理分離部署變成一種昂貴的冗餘；J2EE 1.4以後版本支持的Web Services兼容性，使得客戶端可以通過粗粒度的Web接口調用遠程服務??這兩次變化事實上都是在論證“分佈式對象架構”的無用性。
人們發現，同一系統的各個分層最好採用細粒度接口調用，並且運行在同一個進程中；之所以劃分不同的層次，與其說是爲了實現物理上的可擴展性，不如說是設計美學上的考慮。
而對於異質系統之間的調用，則應該儘量選用異步的、粗粒度的服務接口（所以Web Services成爲了非常理想的選擇）。換句話說，傳統上的“分佈式對象架構”，現在看來似乎只適合於銀行遠程支付等要求極爲苛刻的應用場景，而絕不是所有J2EE應用都該考慮的標準方案。
前面描述的離心現象畢竟還遵循了J2EE發展的內在邏輯，說到底，EJB的革新和Web Services的引入更多地是主流廠商倡導的結果。但在近年來，還有一股更強勁的離心潮流在深刻地影響着J2EE的演進，它肇始於上文提到的開源軟件運動。
最初它只在Rickard Oberg的動態代理RMI設計與JBoss服務器的微內核架構中顯露過邪惡的一角，但是兩三年來，經過多個項目、各種技術雜誌/論壇/Blog的折射和放大，它已經形成了一個名爲“輕量級容器架構”的完整解決方案，並暴露出完全取代傳統EJB架構的終極野心。
按照這一運動信徒們的說法，J2EE的發展史上只出現過一個錯誤??不幸的是，這個錯誤名叫EJB。與EJB提供的重量級架構不同，藉助AOP和IoC機制，輕量級容器能夠最大程度地降低代碼對於專用接口的依賴性，以簡短、輕便、專注、可移植的方式實現業務對象。
從“輕量級容器架構”這個詞被髮明出來的那一刻起，人們對J2EE遠景的考慮就發生了根本性的分裂：Sun和大部分主流廠商更多地關注於“Web Services”和“快速開發工具”這些利潤增長點，而一部分離經叛道的獨立專家和開發者則認爲，如果不把輕量級容器納入規劃，J2EE的發展藍圖就註定無足稱道。
其實，雙方爭執的關鍵是傳統意義上的“應用服務器”的存亡??如果所有企業級服務都可以通過AOP機制提供給普通Java對象，如果管理業務對象生命週期的可以是一個最微不足道的“微內核”，那麼深盔重鎧的應用服務器還有什麼存在理由？
而如果失去了應用服務器的這個產品類型，那些靠這項銷售起家的廠商又將何以自處？正是在這裏，兩個陣營之間存在着最深刻的利益分歧；而這場爭執的結局當然也將決定J2EE（乃至Java企業開發）的最終走向。
或許兩年之後，我們將從紛爭中勝利者一方的角度重述J2EE的整部歷史??或許兩年之後的J2EE本身也將隨着紛爭的解決而成爲歷史。但讓我們換個樂觀的口吻：問世五年，J2EE的歷史仍在持續的創生之中；此時善待這樹種的人，也必在今後的樹蔭下獲得它的祝福。
