-----------------------------------------------------------------------------------------
前 言
看了幾篇關於“迴歸C/S”的文章，作爲一名多年開發B/S的程序員，不免熱血沸騰，深受鼓舞！曾經，我是B/S結構的忠實擁護者，同時也爲了所謂的“零部署”陷入過技術泥潭。正當爲B/S煩愁的時候，RIA走進了我的視線… …
什麼是RIA
Internet已經日益成爲應用程序開發的默認平臺。用戶對應用程序複雜性要求日增，但現在的Web應用程序對完成複雜應用方面卻始終跟不上步伐。用戶與今天中等複雜程度的Web應用程序交互時，其體驗並不能令人滿意。Web模型是基於頁面的模型，缺少客戶端智能機制。而且，它幾乎無法完成複雜的用戶交互（如傳統的C/S應用程序和桌面應用程序中的用戶交互）。這樣的技術使得Web應用程序難以使用，支持成本高，並且在很多方面無法發揮效應。
爲了提高用戶體驗，出現了一種新類型的Internet應用程序。那就是Rich Internet Applications（RIA）。這些應用程序結合了桌面應用程序的反應快、交互性強的優點與Web應用程序的傳播範圍廣及容易傳播的特性。RIA簡化並改進了Web應用程序的用戶交互。這樣，用戶開發的應用程序可以提供更豐富、更具有交互性和響應性的用戶體驗。
基於主機模式→C/S模式→B/S模式→RIA模式
我們的行業經歷了幾次系統架構方面的重要轉變，在此過程中，客戶端的表現功能有起有落。上圖介紹了每個階段的計算功能所帶來的應用程序體驗方面的變化，這一過程從大型機開始，到RIA的出現爲止。
隨着各企業組織認識到RIA模型可產生顯著的商業利潤、提高生產率及降低成本的優勢後，這種模型的發展勢頭越來越猛烈。這些應用程序結合了桌面應用程序的反應快、交互性強的優點與Web應用程序的傳播範圍廣及容易傳播的特性。系統架構發展的下一步是RIA，它最大程度地提高了廣泛性和豐富性。
論傳統B/S之不足
過程複雜性
過程複雜性是由於需要表達一個多步驟或多選項任務或互動作用所引起的。在HTML裏，一個多步驟的任務可以在單頁內表達出來。但是由於HTML的互動性有限，便可能產生一份很長的頁面，使用戶感到混亂、笨拙而難以使用。爲了避免這種難以忍受的用戶體驗，便需將任務在表面上看來“自然”的部分處區分成多個步驟，甚至需多個網頁共同完成。這種以網頁爲主的用戶界面通常需要反覆翻轉網頁，以解決在順序步驟中有牽連性的改變。其結果是緩慢、不自然、混亂而且令人感到懊惱的用戶體驗。
配置複雜性
許多Web應用程序允許用戶配置自己所要的定製產品——可以是皮包或是計算機，甚至是汽車等產品。但是配置產品是一項很困難的過程，因爲在向用戶展示所有有效的產品選項組合時，應用程序必須能夠表達出有關的複雜性，尤其是當用戶可以從數十、數百或數千選項中定製出一個產品時。表達這些複雜性包括指出所需條件、有效和無效組合、一些導致問題的元素以及它們的適當解決方法；爲每一項個人選擇提供費用信息以及費用總計（一旦有所更改）；還有最重要的是容許用戶觀看最後結果。這些是傳統Web應用程序相當難以表現的。
規模複雜性
今天，網站內的搜索工具大多是文本性質，間中夾着一些錦上添花的圖像。當用戶輸入他或她的數碼照相機準則，有可能是價格、以像素等，網站便接着回覆數頁符合準則的產品，而大部分都是說明文本。反之，另一種方法則是使用視覺化來簡化搜索空間（也就是提供立即和動態的視覺反饋）。在一個視覺化選擇照相機的網站，其搜索過程可能如下：網站從一個包含所有照相機種類圖像的單屏幕開始。當用戶通過複選框、遊標或數據輸入域來選擇篩選準則時，所有不符合準則的照相機圖像將被刪除，只餘下符合準則的照相機可在屏幕上看到。因此，在把選擇聚焦至符合準則的數部照相機的過程中，用戶可經歷一個截然不同，而且和現實生活中的購物經驗更相似的體驗。
反饋複雜性
高度互動性的應用程序如遊戲，能使反饋變得複雜，也即是指用戶行動和快速移動或情節不斷改變的屏幕元素之間的反饋環路。傳統的HTML頁面一向來都可以說是無法表達這類複雜性。它所需要的是擁有高度互動性和局部智能型的客戶端應用程序，以便可以在無需刷新全頁或干擾與服務器之間的通信的情況下，響應用戶的輸入和改變它們的狀態或界面。放棄如今依賴服務器的客戶機將使用戶體驗更吸引，同時也解決了反饋複雜性的問題。Web應用程序必須擁有表達複雜性的能力，以容許用戶視看複雜的數據、配置多選項的產品、搜索大型數據集以及容許用戶與數據之間的互動交換。
真正的RIA
爲了解決如今的問題，理想中的Web應用程序應該能夠：
1、 利用無處不在的客戶機
2、 在多種硬件平臺上毫無更改的操作互聯網
3、 無論低或高帶寬的連接都可毫無妨礙的執行
4、 將處理能力復原給客戶（而不僅是提供能力而已）
5、 提供吸引人的高度互動的用戶界面
6、 表達過程、數據配置、規模和反饋複雜性
7、 無縫的利用聲音、視像、圖像和文本
8、 容許用戶在線和離線工作以支持移動工作流程
9、 容許客戶自行決定要在何時存取何種內容和數據（異步內容檢索）
10、 存取多種中間層服務（.NET或Java）和後端數據存儲
11、 採用新崛起的標準如XML和SOAP，爲演進中的Web Service爲主的網絡提供動態高效的前端應用
12、 與遺舊的應用程序和系統集成
13、 容許在現有Web應用程序和環境內逐步添加新功能以充分利用現有網絡應用投資
結 構
RIA本身有能力提供這類Web應用解決方案。如上圖，RIA將桌面型計算機軟件應用的最佳用戶界面功能性與Web應用程序的普遍採納和低成本部署以及互動多媒體通信的長處集於一體，終於成就了一種可以提供更直觀、響應性和有效的用戶體驗應用程序。它所具備的桌面型計算機長處包括了在確認和格式編排方面提供互動用戶界面；在無刷新頁面之下提供快捷的界面響應時間；提供通用的用戶界面特性如拖放式(drag and drop)以及在線和離線操作能力。Web網的長處如立即部署、跨越平臺可用性、採用逐步下載來檢索內容和數據、擁有雜誌式佈局的網頁以及充分利用被廣泛採納的互聯網標準。通信的長處則包括雙向互動聲音和圖像。
客戶機在RIA內的作用不僅是展示頁面，它可以在幕後與用戶請求異步地進行計算、遞送和檢索數據、重新畫出屏幕的一部分和密切綜合使用聲音和圖像，這一切都可以在不依靠客戶機連接的服務器或後端的情況下進行。
RIA提供一個強勁的技術平臺，使客戶機的能力復原到差不多與桌面型計算機軟件應用或傳統的C/S系統中的客戶機能力相似。它適合傳統的N層開發過程，同時也能夠和遺舊的環境集成以延展現有的應用程序而無需進行修改。它也可以作爲基礎網絡服務的互動表現層，允許用戶在線和離線工作。RIA有能力解決各種複雜性，使需要複雜性的應用得以開發並且減少開發成本，同時在很多時候這類應用之所以能夠成形主要是拜RIA所賜。
RIA方案—基於Flash的Flex
Flex簡介
Macromedia公司被公認爲新興的RIA市場的領導者。今天98%的瀏覽器上都使用Macromedia Flash客戶端軟件，因此幾乎每個人都可以使用基於Flash的RIA。Macromedia Flex是Macromedia的新服務器產品，它使企業應用程序開發人員能夠全面訪問RIA的功能。Flex具有基於標準的架構，與當前企業開發人員的工具、方法和設計模式互補。
Flex應用程序與傳統的HTML應用程序的主要區別在於Flex應用程序處理最適合在客戶端運行，如字段校驗、數據格式、分類、過濾、工具提示、合成視頻、行爲及效果等。Flex 可使開發人員更好地交付應用程序，這種應用程序使用戶可以迅速反應、在不同狀態與顯示間流暢過渡，並提供毫無中斷的連續的工作流。
Flex 應用程序框架
如上圖所示，Flex應用程序框架由MXML、ActionScript 2.0及Flex類庫構成。開發人員利用 MXML及ActionScript 2.0編寫Flex應用程序。利用MXML定義應用程序用戶界面元素，利用ActionScript 2.0定義客戶邏輯與程序控制。Flex類庫中包括Flex組件、管理器及行爲等。利用基於Flex 組件的開發模型，開發人員可在程序中加入預建的組件、創建新組件或是將預建的組件加入複合組件中。
這裏重點介紹一下MXML。與HTML一樣，都是標記語言，它描述了反映內容與功能的用戶界面。與HTML不同的是，MXML 可對表示層邏輯與用戶界面和服務器端數據綁定提供聲明抽象。MXML可將表示與業務邏輯的問題徹底分開，以實現最大程度地提高開發人員的生產率及應用程序的重複使用率。
Flex的不足
目前Macromedia最新推出了Flex 1.0 Updater，但它代號爲“Brady”的IDE還沒有正式推出，目前還在進行Beta 3測試。拋開IDE不說，筆者認爲Flex目前還很不成熟，還不利於在實際項目中使用。
例如，Flex自帶的ZipCodeValidator，裏面只提供了美國和加拿大的郵編規則，沒有其他選擇，也無法個性化它。看來只有自己來定義Validator了，但這樣一來，和在JS中寫正則表達式有什麼區別（代碼量和JS差不多）？用戶需要的是國際化的ZipCodeValidator，這樣才能提高工作效率。
一句話概括
現在的Flex纔是1.0版本，很多地方都不完善，只好自定義才能完成特定的要求。期待着Brady以及Flex後續版本的推出！
RIA方案—基於JS的Bindows
Bindows簡介
“Bindows把javascript發揮到了第九層！”——網友這樣評價Bindows。
運行中的Bindows
的確如此，Erik等編寫這個框架已經將javascript的OOP和基於IE6的DHTML發揮到極點！Bindows 0.93發佈的時候已經將IE內置的功能開發得淋漓盡致了，包括Filter、XMLHTTP、Web Service、VML。javascript用於客戶端界面的顯示和處理，XMLHTTP用於客戶端與服務器的信息傳輸。javascript在客戶端的表現力不容置疑，看看www.bindows.net所表示出來的能力，利用javascript幾乎可以實現Windows應用程序所能幹的大部分事情，XMLHTTP一直以來常被用於實現“無刷新”的Web頁面，它和javascript配合，可以完成數據從服務器和客戶端的傳輸。
Bindows的不足
Erik喜歡那種一次全部載入的方式來實現腳本庫，使用過Bindows會發現，在窗口的加載期，需要一個漫長的等待過程，甚至瀏覽器的進程會產生無響應的情況。按照V0.93，腳本文件的大小是600多K，在一個普通的Web應用中，我們更多時候不會用到Bindows的全部功能，這點Bindows根本沒有遵循“用多少去多少”的準則。另外，過多的JS會使CPU佔用率陡然增加，產生潛在問題。
內部大量利用了IE6的技術，沒有考慮到非微軟平臺的瀏覽器，限制了Bindows的流行。在圖表方面，大量採用了VML技術，在IE5，IE5.5這兩個版本，VML引擎不是那麼的成熟，很多地方的顯示不夠流暢，會受到帶寬和硬件的限制，過分絢麗的圖形最終會給用戶帶來崩潰。“圖形方面我是採用VML的，當初太偏執，如果使用SVG來實現可能好許多的，也就是那段日子，我花了非常多的時間去折騰web方面開發。”——有網友這樣說。
一句話概括
在技術的角度上，從Bindows是可以學到不少東西的，但好像它的學術價值大於它的商業價值。
後 記
興奮歸興奮，冷靜下來仔細想想，運用RIA改造現有B/S模式還爲時尚早。制約我們的首先是網絡環境和硬件環境的不完善性，我想沒有哪個用戶願意花大量的時間來等待想要看見的“花哨”頁面，更不願意等來的東西使自己的機器不堪重負，而換來的只是一些良好體驗吧？市場決定一切，而不是任何的新技術！其次，目前RIA的解決方案也不成熟，筆者看好Flex，可惜還需要長時間的等待纔有結果。當然，還有很多RIA的方案，感覺MS的Smart Client + Web Service來頭不小。
本文叫“迎接RIA時代的來臨”，筆者充滿了對RIA的美好憧憬，期待着有一天能夠在RIA的環境中進行虛擬現實的交互式體驗！
Are you ready? Let’s go!
鳴 謝：RIA中國 沒有他們，我想今天也不會對RIA有如此的認識！！！
參考文獻
Flex 白皮書
IDC--RIA白皮書
迴歸C/S?解釋Bindows
迎接Client/Server模式的迴歸
Flex: RIA 的先驅，無堅不摧的銀彈？
Return of Rich Client
