回眸Java10周年：J2EE從起源到目的二

2019-11-18 12:26:31

字體：大中小

來源：轉載

供稿：網友

　　多年以后，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的歷史仍在持續的創生之中；此時善待這樹種的人，也必在今后的樹蔭下獲得它的祝福。

上一篇：充分利用J2EE Enterprise BluePrint

下一篇：關于Apache Axis2的Web service消息