零雨其蒙's Blog

?? （零雨其蒙原創，轉載請注明）
??? 是驚喜抑或是困頓，在過去的 20 年間 IT 界發生了很多變革，生產力和理論都取得了突飛猛進的發展。這比更早時候的發展更加迅速， Oreilly 公司畫出了一幅從 1954 年 Fortran 到 2003 年 Python2.3.1 出現的程序語言發展的清明上河圖。 1990 年 10 月， Tim Berners-Lee 發明了 WEB ，之后世界變得異常精彩， 1995 年是偉大的一年，第一個用 Perl 語言編寫的 CGI 誕生了， Netscape 發布了 JavaScript ， Rasmus Lerdorf 發明了 PHP ， Sun 發明了 Java ， Matz 發布了 Ruby 。從那一年開始，你可能會發現兩件事，一件是 Web 開發會成為未來的主流，一件是軟件工業開始在創新和完善中趨同。程序語言是相似的，語法有 C （ 1971 年）， Pascal （ 1970 年）， Basic （ 1964 年）幾大風格流派，而程序開發的思想卻基本上是 Pascal 之父 Nicklaus Wirth 所言“算法 + 數據結構 = 程序”。 1965 年出現了 OO 理論， 1967 年 Simula 實現了 OO 理論， 1980 年帶著 Class （類）的 C 語言出現， 1983 年， Bjarne 創造了 C++ 。而真正讓 OO 開始“飛入尋常百姓家”的卻是 Java ，而 2000 年 Delphi 之父 Anders Hejlsberg 產下了第二個孩子—— C# ， C# 和 .Net Framework 全面模仿 Java ——其實這么說也有失公允，虛擬機的思想來源于 Pascal ，其他優秀的風格來自 C\C++ ，而 C# 則借鑒了 C++ 、 Java 、 VB 、 Delphi 等語言，其實可以說是借鑒了程序語言發展 50 年的廣泛經驗。另外對于方法論的研究，軟件工程學的研究，也都取得了不小的進步。從 1970 年 Winston Royce 博士引領的瀑布模型到后來改進的 V 模型，到 UP 到 AM ，我看到的是業界的經驗越來越豐富，而對于方法的迷信在不斷的降低，而務實的方法越來越受到歡迎，從敏捷宣言的“工作的軟件勝過面面俱到的文檔（ Working software over comprehensive documentation ）”即可看出。在 Java 的世界里，人們樂于討論各種各樣的思想，制定各種各樣的標準，而在 Microsoft 的世界里，則都是總結行業數十年經驗的產品。

??? 說這些只是為了引出本文的兩個基本觀點，一是相信業界幾十年經驗的總結，方法論、模式與反模式、框架、藍圖、產品；二是遵循“循證”原則，不相信任何官樣文字，不崇拜任何泥塑偶像，凡事以實際出發，而不是墨守成規的遵循所謂規范。在相信與不相信中取舍是困難的，本文所選的主題是在 .Net 和 J2EE 兩大平臺中選擇其一作為廣州港信息化架構平臺。正是基于業界數十年發展的經驗的總結和“循證”思想， .Net 和 J2EE 越來越趨同。這意味著只看廠商的宣傳和書本的講解很難做出抉擇，而且往往是不可信的。

??

想要正確理解 J2EE 和 .Net 就必須深入到其背后，了解其產生的背景，盲目崇拜規范或使用產品（ J2EE 歸根到底還是使用其產品）就會造成嚴重的后果， Rod Johnson 在《 Expert one-on-one J2EE Design and Development 》中指出由于人們過于迷信 Sun 制定的 J2EE 規范，而沒有考慮到實際情況（盲目使用分布式計算，不合時宜的使用 EJB ，特別是實體 Bean ）。

行業背景

促成如今 .Net 和 J2EE 當然還包括 RoR 和 LAMP 群雄割據的原因自然是業界對于軟件解決實際問題的呼喚，而這些技術滲透的思想包含業界數十年的經驗， OO 技術（光是信息隱藏就爭論了十幾年）、中間件技術、 Web 技術、 n 層結構，而如今這些爭論越來越趨向于統一，下面分而述之：

n???????? OO 技術

面向對象絕對是編程思想的一次革新（相對于面向過程的結構化思想），我沒有趕上 C/C++ 橫行的年代（雖然在某些場景下它們依然橫行），因此對某些思想上轉變時的痛苦感覺并不深刻，盡管核心思想（跟我見過的一些中國的教科書上說的不一樣）的轉變頗費了一段時間。《 Code Complete 》說學習面向對對象首先要理解 ADT ，而在《編程高手箴言》中我看到了對于重載方法在編譯碼層次上的實現，并且明顯感到作者對面向對象的理解體現在技術本身（這種技術實現的原理），對于 C 程序員甚至是 C++ 程序員而言，往往直接操作數據結構和內存等（比如指針和鏈表），所以理解 ADT 算是思想上的革命了。正如前面所說， C++ 程序員總是能看到 VMT 這樣的技術原理，我認為在進行 OO 編程時應該暫時忘掉這些，因為它將阻礙你理解 OO 設計思想。

我認為 OO 的核心是對于對象的理解，而并非重載、繼承之類的具體技術，站在對象的角度思考問題是思維方式的變革，是非常苦難的。然而不幸的是，我見過的多數使用 OO 技術的人并未真正理解對象，而只是機械的使用類（ Class ），重載等技術，這些 Class 其實并非真正的類，只不過是堆積大量沒有任何實際含義的容器（比如將驗證用戶帳號信息和保存訂單放在一個類里）。沒有實際含義的類（有實際含義的類就像 Customer 類中只包含消費者自身的行為，而不應該出現保存訂單之類的行為，那應該交給 Order 類）和結構化的程序沒有更多本質上的區別，同樣是難以維護的（這里主要指程序不是自明含義的）。

業界的實踐已經證明了 OO 是設計復雜系統可行的好的方法，而真正用好 OO 并非易事，正確使用設計模式是有效的方式。然而知道設計模式（能背誦 Gof 的 23 種 Design Pattern ）和理解設計模式（這本身已經不容易，因為不了解 OO 的基本技術如接口，繼承，多態等并且沒編寫過相關程序，閱讀并理解設計模式和其范例是不可能的）與靈活運用設計模式不是一個層次上的。盡管設計模式是從實踐中總結出來的解決特定問題的方法，而且優秀的程序員都是這樣進行設計編程的，然而我們身邊到處都是不優秀的程序員。

理解 OO 設計思想比理解 J2EE 架構重要的多，正如 Rod Johnson 所說：我們使用 J2EE 實現 OO 設計，而不是讓我們的 J2EE 來支配對象設計。使用了 J2EE 平臺（實際上是使用了 WebSphere ， Jboss 這樣的產品）并不意味著能解決復雜的企業級問題，關鍵在于你怎么做。

n???????? 中間件技術

中間件技術起源于 1980 年左右，其作用是屏蔽 OS 的復雜度，為應用程序提供企業級服務，比如事務管理、安全管理、并發控制、分布式管理等，按照 IDC （ http://www.idc.com ）的分類方法，中間件可分為六類，第一類是終端仿真 / 屏幕轉換中間件，第二類是數據庫訪問中間件，第三類是遠程過程調用中間件，第四類是消息中間件，第五類是交易中間件，第六類是對象中間件。

最初的中間件是基于遠程過程調用（ RPC ）的，通過遠程方法可以透明調用實現分布式的通信計算，雖然這一代的中間件沒有 Web 的支持，但是其 RPC 的思想得到了廣泛的應用，在后來的中間件中也得到了繼承；九十年代初出現了消息中間件，通過消息傳遞和消息隊列的方式實現基于多協議的可靠消息傳遞機制，主要的產品有 IBM 的 MQSeries ， BEA 的 MessageQ ；而交易中間件則是致力于管理大型的事務處理的，當前成熟的 BEA 的 Tuxedo 就是其中的代表，交易中間件通過 XA 規范接口與資源管理器進行交互，并且通過二階段提交協議進行事務管理；正如前面提到的面向對象的中間件是 OO 技術的應用，九十年代初 OMG 提出了以 CCM 為基礎的 CORBA 規范，還有就是 Sun 提出的以 EJB 為基礎的 J2EE 規范和 Microsoft 提出的 .Net 平臺。

n???????? Web 技術

1990 年 10 月， Tim BL 在 NeXT 平臺上開發出了世界上第一個圖形界面的超文本瀏覽編輯器，名字就叫“ World Wide Web ”，同時 Tim BL 依照 SGML 標準，開發出了 HTML （ Hypertext Mark-up Language ，超文本標記語言）！ 1991 年的 8 月 6 日 （美國時間）， Tim Berners-Lee 在當時的 alt.hypertext 討論組上正式向全世界介紹了他的 WWW 計劃，從那一天開始， Web 開始走向世界化。

為了滿足人民群眾日益增長的物質文化需求， Web 技術不斷推陳出新，回顧這段歷史是很有意思的，同時也是有意義的，它會讓你知道每種技術為何而生，以便更有效的利用它。 1995 年誕生的打響了動態腳本語言的第一炮，隨后 1996 年 Microsoft 推出了 ASP ， 1997 年 Sun 推出了 Servlet ， 1998 年又推出了 JSP ， 2003 年 Microsoft 將 ASP 升級為 ASP.Net 。 2005 年出現了 Ajax 。越來越多的基于 Web 的應用系統被創建，從簡簡單單的以展示內容為主的網站變成了需要處理復雜業務邏輯的大型系統， Sun 和 Microsoft 采用了幾乎相同的手段，來滿足這些需求。

J2EE 概述

J2EE 就是在這樣一個大背景下誕生了。 J2EE 主要組成部分有 J2EE 平臺， J2EE 規范（ Platform Specification ），參考實現 (Reference Implementation) ，兼容性測試套件（ Compatibility Test Suite ）和 J2EE 藍圖（ J2EE BluePrints ）。

J2EE 規范

對于 J2EE 規范，有一個中英文的細節是， J2EE 規范的“規范”用的詞不是 criterion 而是 specification ，我們知道 specification 是指軟件過程設計階段的規格說明書，而 J2EE Specification 就是一個使用 Java2 語言，構建企業級應用系統的設計規格說明書，它包括了整個企業系統的架構，以及各種中間件如何設計，細化到了每個 API 是如何設計的。如果把 J2EE 這個中間件看成一個應用系統，那么二十余年的行業經驗就是它的需求（ Require ）文檔， J2EE 規范就是設計（ Design ）文檔，而實現（ Implement ）的結果就是 J2EE 平臺。需求和設計是由 Sun 完成的，而實現則是由廣大中間件廠商完成，這些廠商當然也包括 Sun 自己。

?

J2EE 平臺

根據 IDC 早期的一份報告顯示，企業用戶的需求要求各種中間件進行整合，也就是說各種中間件分開來還不能夠滿足其需求， J2EE 平臺正是這樣的一種產物。它首先是一個對象中間件（按照面向對象設計思想設計的，比如 EJB 這樣的對象），同時包含了消息中間件（ JMS ），數據庫訪問中間件（ JDBC ），遠程過程調用中間件（ RMI ， JNDI ），交易中間件（ EJB ， JTA/JTI ）。 J2EE 是第一個將這些中間件整合在一起的強大的平臺，我們使用的就是一個現成的，用 Java 開發的中間件軟件，不同的廠商使用同一個規格說明書來生產自己的 J2EE 平臺，比如 Sun 自己的 J2EE SDK ， IBM 的 WebSphere ， BEA 的 WebLogic ，還有很多開源的實現比如 JBoss 、 Lomoz 等。而且 J2EE 平臺也包含針對 Web 系統的內容， Servlet 和 JSP 。隨著技術的發展，大量的新技術也都加入到了這個平臺，比如 XML 、 Web Service 等。

J2EE 藍圖

?? J2EE 藍圖包含了對在 J2EE 平臺上進行企業級應用系統設計的指導，同時還包括了一個 Demo 程序及相應的文檔。在藍圖中 Sun 給出了 J2EE 的分層模型，即表現層、業務邏輯層、持久層和 EIS 層。表現層中主要是 Web 層，當然還可能是其他軟件，比如 Swing 程序。我們可以看出 J2EE 部分組件的構成也是根據該模型給出的，比如面向表現層的 JSP/Servlet ，面向業務邏輯層的 Session Bean ，面向持久層的 Entity Bean ， JDBC ， JTA ，面向 EIS 層的 JCA 和 JAX-RPC 等。

?

理解 J2EE 的全貌需要從上面三個宏觀方面進行，每個方面都是看 J2EE 的一個角度，它們互相補充。 J2EE 為我們提供很好的解決問題的方法，如果你清楚每種中間件的作用，以及那些時髦的新技術名詞，你將很清楚我所說的指什么，在此就不多贅述了。

很好的使用 J2EE 平臺為我們服務，就如同 Rod Johnson 所言：我們應該以任務驅動，而不是以 J2EE 技術驅動。因此理解面向對象、理解三層結構、理解 Web 開發、理解中間件技術都是比理解 J2EE 規范、 J2EE 平臺、 J2EE 藍圖更重要的事情。特別是 Spring 、 Hibernate 等輕量級框架的出現， Rod Johnson 、 Martin Fowler 、 Robert Martin 的主張以及敏捷方法的興起，一種更加務實的態度和做法正在被重視。 Rod Johnson 在自己的三本著作中都在大聲批判 J2EE 規范中的一些組件，比如認為 Entity Bean 是徹底的失敗， EJB 是不建議使用的超級復雜的重量級解決方案， JNDI 也不是每次都要使用， IoC 比 CMP 更具有明顯的優勢，并很不給面子的說 J2EE 規范專家組的成員對實際應用并不在行，而應該把這些交給上千成員的社區等，這些都是從實踐中得出的結論，而讓人興奮的是 Sun 的專家組已經聽取了大家的建議，在 EJB3.0 規范中已經大大的簡化了 EJB ，也引入了 IoC 等新的理念。

對于 J2EE 的使用我見過四種人，第一種是根本不了解 J2EE ，以為使用了 WebLogic 、 WebSphere 這樣的 J2EE 中間件軟件就是使用 J2EE 了，完全沒有用到容器提供的各種企業級服務，比如連接池， JTA ；第二種是根本不理解 J2EE ，完全按照 Sun 給的規范去做，造成了濫用分布式、不恰當的使用 Entity Bean 的情況；第三種是跟著流行走，直接使用 Spring 等框架，完全拋棄了 Sun 的規范；第四種是能夠正確看待“正統” J2EE 和輕量級 J2EE ，能根據需要進行方案的比選。第一種是無知，第二、三種是蠻干，第四種人才是 J2EE Expert 。

在這一部分，我沒有一一介紹每種組件，因為已經出版了太多的書籍來介紹這些。重要的是我們看問題的角度。

.Net 概述

J2EE 是依托一種面向對象語言—— Java 建立的平臺和規范，而 .Net 則是使用多種語言構建的統一的平臺。與 Java 的可移植的思想相近，通過將 .Net 平臺上所有的語言（使用托管方法）轉化成中間語言，然后由 CLR 來解釋執行，相當于 J2EE 平臺下的 JVM 。 .Net 平臺跟 Java 平臺的一個區別是 .Net 平臺沒有把那個規格說明書公開，而是直接由微軟自己拿出了產品，而其需求與 J2EE 是一致的，就是為企業用戶服務，構建企業級信息系統。因此 .Net 平臺也是一個對象中間件產品，也包含消息中間件（ Message Queuing ），數據庫訪問中間件（ ADO.Net ），遠程過程調用中間件（ Remoting ），交易中間件（ Enterprise Service ）。而 Web Service 是 Microsoft 和 IBM 一起提出的，因此 Microsoft 自然也是很早就開始支持 Web Service 的，而且從 .Net Framework 1.1 時就已經是賣點了。

Microsoft 自有一套研究方法， Microsoft? 解決方案框架 (MSF) 是一種成熟的、系統的技術項目方法，它基于一套制定好的原理、模型、準則、概念、指南，以及來自 Microsoft 的、經過檢驗的做法。這很像Java陣營常講的J2EE設計模式、敏捷方法之類的東西，而且他們的共同點都是基于實踐經驗。Microsoft把自己在軟件業闖蕩20年的豐富經驗和其他合作者的經驗再加上在模擬真實環境的實驗室的實驗結果整合到自己的產品中，于是就有了Visual Studio .Net系列強大的工具，而且他們是統一的，不是東拼西湊而成的。

想要更好的構建.Net平臺下的方法與J2EE平臺相同，而很多好的實踐經驗由于已經構建在平臺內部，比如code behind風格使得使用MVC架構模式變得容易。但是與J2EE平臺相同，構建穩固的、可復用的、易于維護的、具有擴展性和延展性的、安全的、面向對象的系統，依然需要設計者對于OO設計思想的準確把握、對于n層結構的深入理解以及對于任務的透徹掌握，使用.Net平臺同樣不意味著你一定能設計出好的應用程序。

新趨勢

???? J2EE 和 .Net 兩大平臺正在齊頭并進，互相借鑒， 2006 年 Sun 推出了 J2EE 5.0 ，使用了 J2SE 5.0 的新特性——標注 (Annotation) ，引入了 .Net 平臺中的 Metadata 概念，對 EJB 進行了大刀闊斧的改革，去掉了為人詬病的復雜性，就連原來 Rod Johnson 指出的 Entity Bean 只能在 J2EE 容器中測試而造成的困難都被去掉了，現在 Entity Bean 可以像 POJO 一樣被測試了。而 Hibernate 也發布了新版本，開始支持 JTA 。而 Spring 推出了 2.0 版，改進了 Spring MVC 等部分，我們可以看出，隨著 J2EE 社區 Rod Johnson 以及敏捷社區在實踐中發出要簡化 J2EE 開發的復雜度的呼聲， J2EE 開始走向簡單，而這正是 Microsoft 一貫的做法。而 .Net 也將于 2007 年上半年發布 .Net Framework 3.0 ，其中統一了遠程服務（ WCF ），工作流（ WF ），桌面 UI 和 Web UI API （ WPF ），安全驗證（ WCS ）。 Microsoft 繼續向簡化之路邁進，盡可能的讓用戶沒有選擇（有選擇和沒選擇都是雙刃劍），講究一致性。我們可以看出 .Net 在不斷的增強 Web Service ，更好的整合各種應用系統。

不僅發出感嘆， .Net 和 J2EE 兩大平臺越走越近，隨著時間的推移，或許抉擇只需考慮個人偏好了。因此在當下作出兩大平臺的選擇還有些客觀的辦法，雖然同樣是相當困難的。

?