迎接RIA時代的來臨
[摘自] 中國RIA開發者論壇 前 言
看了幾篇關于“回歸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來頭不小。