迎接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中寫Regex有什麼區別（代碼量和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來頭不小。

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1446518