英國人改變世界
沒錯，就是這位仁兄在不經意之間改變整個世界。在CERN(European Particle Physics Laboratory，歐洲量子物理研究所)工作期間，他發現了CERN在信息的內部溝通存在信息遺漏的弊端，於是在1989年3月Tim向CERN提交了名爲“Information Management: A Proposal”的建議書，這個也是迄今爲止我們能夠看到的關於互聯網概念的第一份公開文件。在這份文件中，Tim提出利用Hypertext（超文本）構造鏈接信息系統的設想 。同樣，我們也可以從文件中看到“Browser（瀏覽器）”概念的最初提出。1991年，在此基礎上Tim開發了第一個真正意義上的Web 服務器——httpd、第一個客戶端瀏覽器——WorldWideWeb，之後又在1991年建立並開通第一個WWW網站http://info.cern.ch/（該網站至今仍然是CERN的官方站點）。從此互聯網真正開始向社會普及。至於後來Tim加入麻省理工大學LSC(計算機科學實驗室)和後來成立的W3C又是另外一件有深遠意義的事情了。
不管如何，通過WWW，這個有點憨厚的英國人已經徹底改變整個世界。
1993年5月，伊利諾斯州大學的天才少年Marc Andreessen開發了第一個瀏覽器Mosaic,1994年上半年他和Jim Clark成立了Mosaic Communications（也就是Netscape的前身）,同年10月發佈了Netscape 0.9,這個是我們看到的第一個瀏覽器的Logo,雖然今日已經面目全非。 
而Netscape的出現終於讓WWW得到了爆炸性的普及。
Browser/Server,一個無法完美的名字
隨着瀏覽器大戰的開始，世人真正意義的享受了科技進步給人類帶來的福旨。一夜之間，B/S結構成爲應用開發最主流架構，瀏覽器成爲客戶端的唯一工具，這種不需要部署的軟件應用確實給了很多人無限的瘋狂。ISV、解決方案提供商及其企業用戶也不約而同的提出採用B/S架構作爲企業信息應用的架構，因爲那樣可以免去之前C/S時代高昂的部署和升級費用，能夠快速適應不斷變動的企業業務。
漸漸的，他們發現自己不斷複雜的業務通過簡單的頁面瀏覽已經無法滿足要求，這個時候相關的客戶端腳本技術走上舞臺，說起來有點戲劇性，Netscape設計腳本的初衷是爲了讓網頁有更好的瀏覽性，從而增加頁面瀏覽的樂趣，他們一定沒有想到這個概念卻在他們的對手發揮到極致，等到那場瀏覽器大戰的硝煙漸漸淡去的時候，我們發現腳本已經面目全非，或者說已經臃腫不堪。
爲了沿襲C/S結構下的界面使用體驗，開發人員不得不利用大量的JavaScript和DHTML去實現或者說“模擬”傳統應用程序的使用界面，比如菜單，工具條，還有那複雜的圖形和表格。也因爲如此，Web開發成爲當今最火爆的應用領域，除了相關的服務器開發技術如ASP,PHP,JSP還有後來的王者ASP.NET，客戶端技術則包括了HTML,CSS,JavaScript,DHTML等等方面的技術，這些都成爲開發人員的一種追逐。更有甚者，利用客戶端技術開發了一整套完整的類庫，這點最著名的莫過於Bindows(可以從http://www.bindows.net下載)。
在解決了部署和更新的問題之後，B/S同樣引入了一些令人頭痛的問題：
1） 始終沒有一個非常標準的技術規範來約定，由此造成了各個瀏覽器在w3c之外做的擴展，在應用開發中，更多的是需要依賴於這些擴展去實現更加絢麗的圖形表現和靈活的交互。比如IE裏面提出了HTC的概念，也增加了許多相關的濾鏡（Filter），Mozilla也提出了XUL用來擴展用戶界面。但是如果需要設計一個具有強大功能的用戶系統，我們更多情況下不得不依賴於專有瀏覽器的擴展實現。
2） 作爲瀏覽器大戰的勝利者IE從2001年之後就沒有推出過重要版本更新，那麼也就意味者我們所有的開發技術是停滯在2001年之前的理念，這點和服務器端技術的不斷髮展已經漸漸脫節。
3） 作爲基於瀏覽器的應用，因爲安全等等方面的原因始終做不到能夠成爲應用的集成者，更多時候是被動的去接受單一服務器提供的應用，比如對於客戶端希望能夠跨越不同網絡調用相關的Web Services，因爲安全模型的畸形（不是非常完善的資源訪問控制），我們無法做到在同一瀏覽器內流暢的實現跨應用集成[1]。
4） 基於瀏覽器的技術嚴格意義來說是依賴於在線訪問而構建的應用，在需要一些離線(Office Line)的應用中，就顯得有心無力，畢竟從瀏覽器設計的一開始就是希望能夠在意個最小權限的“沙盒”模型下去運行，因此對於本地資源的訪問默認情況下是拒絕的，而某些瀏覽器如IE允許通過設置來跨越這個安全模型，但是沒有提供一個非常良好的權限分層機制，閘門一開，一切猶如洪水猛獸。
Browser/Server,這個近10年來風光無限的詞眼，依舊不是那麼盡善盡美。
我們需要什麼？
其實理由已經很簡單，雖然網絡上已經出現了許多C/S或者Rich Client迴歸的論調，我想更多的是因爲對於目前B/S架構存在的問題而提出的，因爲從本質上來說許多問題在C/S結構下是不存在的。無論如何，我想回歸只是一個傾向，希望利用C/S的優勢去解決B/S存在的種種問題，而不是簡單的迴歸，假若真的如此，我們又要重複過去的那種災難如令人頭痛的部署，頻繁升級帶來的版本兼容問題，我想對於企業的IT工作者，誰也不願意重蹈覆轍。
那麼，我們需要什麼？Tim通過互聯網已經改變了這個世界，那麼下一步將要走向何方？這個時候關於RIA(Rich Internet Application)的論調也就形成，並且在2004年逐漸得到開發人員和系統架構師的認同。嚴格意義上來說，我們不會關心哪個名字縮寫會是下一代的主流，我們更多的是着眼於需要解決的技術
1） 需要一個更加強大的客戶端運行環境，同時提供統一簡便的開發模型。某種意義上來說目前的瀏覽器正是HTML和腳本這種混合“程序”的運行時，所有的代碼（HTML,CSS,JavaScript）等等都是在瀏覽器這個受控的環境下去運行的。但是目前的運行環境遠遠不夠，同時沒有一個統一的編程模型。
2） 盡大可能的利用客戶端資源，並且資源的訪問是在一個可以控制的環境下完成的，隨着HTML和CSS的演變，已經不是最開始一個Hyperlink（超連接）那麼簡單，但是相對於Windows運行環境，在瀏覽器上能夠完成的圖形表現遠遠不夠。
3） 天生具備訪問網絡的能力，同時能夠比較“Smart”的集成Internet上的應用。
4） 能夠自動完成安全和升級
5） 擁有一個完整的安全模型和CAS(代碼訪問安全)。
6） 具備離線應用的能力，因爲訪問終端的多樣化，對於“有時離線”的支持已經成爲一個關鍵點，例如在基於智能手機的應用時，要求客戶端實時在線有點勉爲其難，這個時候在Mobile的應用上採用傳統的B/S結構已經不太現實。
針對上述要求，一些主流的應用廠商也提出了各自不同的概念，比如微軟的Smart Client（智能客戶端）技術，MacroMedia的Rich Client還有Mozilla的XUL，下面就針對這三種主流的RIA應用架構做一些闡述。
主流的RIA應用架構
Microsoft Smart Client（智能客戶端）
從某種意義上來講，微軟提出的智能客戶端和上述提到的是最爲接近的，也提供了最爲完善的運行環境支持。智能客戶端在設計和實現方面差異極大，這既包括應用程序要求，也包括可以使用它們的方案和環境的數量。因此，智能客戶端可以採取許多不同的形式和風格。根據智能客戶端應用程序所面向的平臺，可以將這些形式劃分爲三大類：
1) Windows 智能客戶端應用程序
Windows 智能客戶端應用程序適合於需要將應用程序作爲熟悉的桌面類型應用程序進行部署和訪問的情況。這些類型的應用程序通常由其自身提供其大部分功能，但是在適當的時候可以與其他應用程序集成或者協調其他應用程序。它們提供針對特定任務進行調整的應用程序功能，以提供特定的或高性能的處理或圖形能力。
2) Office 智能客戶端應用程序
Microsoft Office System 2003 爲您提供了用來生成智能客戶端應用程序（尤其是在企業設置中）的有用平臺。這樣的 Office 智能客戶端應用程序可以成爲組織的信息管理週期的集成部分，而不只是文檔數據的靜態容器。當用戶在文檔內工作時，它們可以提供上下文相關的數據，以及可以將 Web 服務公開的數據轉換爲有用信息的工作流和任務指導、數據分析、協作、報告和呈現功能。
3) 移動智能客戶端應用程序
移動智能客戶端是在智能設備上運行的應用程序，這些智能設備包括 Pocket PC、Smartphone 以及其他超小型臺式設備（如機頂盒）。這些應用程序是使用 .NET 框架壓縮版（它是完整 .NET 框架的子集）開發的。
說到這裏，我們不得不提.NET，正是這一個統一的編程模型才讓Smart Client的成爲可能，從某種意義來說，.NET Framework具備了上述我們提到的所謂幾個需要，包括Internet訪問能力，包括Web Services訪問，包括CAS，包括強大的WinForm等等，而MSDN站點上提供的相關Application Block能夠加快這些應用開發的步伐。
在Longhorn的Avalon沒有到來之前，.NET在一些Rich Client的實現應該是最完備的，雖然Java也提出了WebStart的概念，但是我們知道，在桌面應用領域，Java並沒有太大的優勢，包括最早的Applet，後來的SWT和Swing等等，除非需要跨越平臺應用，不然在桌面應用領域，Java並沒有太多的優勢。
如果說.NET Framework已經爲RIA打好家底了，那麼Visual Studio.NET則是其實現的利器，作爲目前最好的IDE，對於Smart Client也提供了內置的支持。對於開發人員而言，能夠利用VS.NET輕鬆的構建自己的應用系統。
MacroMedia Flex
相對於微軟的Smart Client，作爲互聯網多媒體應用領域的老大MacroMedia也提出了Rich Client的概念，和.NET相反，不是提供給客戶一個強大的運行環境，而是將所有的應用放在了Flash上，畢竟全球99％的瀏覽器都會安裝Flash播放器。
Flex更加側重於UI方面的實現，在交互方面通過ActionScript來完成，內置提供了Web Services訪問、XML應用等等各個方面的技術。和Longhorn的Avalon有點類似，提出了一個相對於HTML更加強大的UI描述語言——MXML，讓開發人員更加方便的進行應用開發，同時通過內置組件和腳本（ActionScript）提供了將大的表現能力，不要以爲ActionScript是簡單的JavaScript，除了完整實現ECMA 262 Edtion 3的規範之外，同時加入了許多自己的擴展，因此動作腳本的名字已經名不符實，客觀的說，已經是一門強大的語言。
圖形表現方面，Flex的應用比Smart Client更勝一籌，但是在離線應用和開發方面遠遠不如.NET支持的好。雖然Flex足夠強大，但是其昂貴的軟件許可和談不上特別流暢的開發環境限制了其的發展，Flex要成爲主流還需要一些時日。
Mozilla XUL
XUL 的核心思想是“用XML來表達界面”，是 Mozilla 的創新， Mozilla 瀏覽器本身就是一個經典的 XUL 應用。作爲Netscape的繼承者，Mozilla成爲一些技術追隨者吹捧的瀏覽器，最近的FireFox則有點出乎意料的得到更多人的認可。
從直接的感覺來說，XUL是一個客戶端運行環境支持的一個框架，相對於HTML，XUL提供了更多的支持，這點和IE5就提出的行爲(Behivor)有點接近。但是XUL提供了比HTC更加靈活的模型，並且因爲Mozilla本身就是設計成運行在不同的操作系統，因此從這個角度來說通用性更好一點。
但是因爲IE佔據絕對的主流，XUL更多隻是一種實驗性的理念。
一切已經明瞭。我堅信，RIA會在將來幾年中替代許多基於瀏覽器的應用程序。
這並不意味着轉換沒有給他們帶來任何痛苦。它要求開發人員學習新的分佈式體系結構和新技術。在許多情況下，他們必須更好地進行面向對象的開發和用戶界面設計。
那些花費最近五年時間學習基於瀏覽器部署的開發人員可能不希望進行改變。他們已習慣了作爲他們那個時代的領先的開發人員。但是所有的技術都會經歷鼎盛期、衰落期，最後被更新的技術所替代。儘管我們繼續會看到基於瀏覽器的應用程序仍會在某些情況下使用許多年，但是我相信基於瀏覽器的開發現在已經過了其鼎盛期。從鼎盛到衰落可能會經過一段時間，但是這一方向是明確的。準備好迎接RIA的到來吧！
[1] 打一個簡單的比方，遠程站點A提供了天氣預報的服務，站點B提供了日程管理服務，站點C提供了一些旅行相關的Web服務，這個時候如果需要集成者三個站點的服務，需要在服務器端去集成這些服務，然後通過預定的方式提供給客戶端，在定製方面更多的採用了Portalet(Java術語)或者Web Parts(Microsoft SharePoint提供的技術)。卻無法做到客戶自己進行應用的集成。
Azure的補充：文章中的“RIA會在將來幾年中替代許多基於瀏覽器的應用程序”說法有些不妥，RIA本身也可以是基於瀏覽器的應用，而且目前來說更多的RIA是基於瀏覽器的，瀏覽器給了人們一個方便進入網絡世界的大門。
新技術的出現使得網絡應用程序出現了分支，基於瀏覽器+Rich Client運行環境（或者瀏覽器本身就自帶Rich Client運行環境）的應用會長時間存在下去；而採用Smart Client這樣的可以不依賴瀏覽器的應用也會越來越多。
