豐富網際網路應用程式

豐富網際網路應用程式（Rich Internet applications，簡稱 RIA），又譯為豐富性網路應用服務，是一種具有近似於傳統桌面應用軟體系統功能和特性的網路應用系統。RIA 系統最大的特點是將大部分處理任務都從使用者介面端移植到客戶端，僅保留一些必要資料與伺服器端進行資訊互動。

RIA 系統的特性：

運行於瀏覽器中，不需要額外安裝支援軟體
在本地執行時，受安全沙箱全程保護

RIA 技術方案列表

1.1 Adobe Flash

Adobe Flash 是建立富網路應用程式另一個方法。這項技術是跨平臺，用來產生使用者介面。Adobe Flex 是一個框架，提供選項給開發者，經由編譯 MXML，（一個以 XML

為基礎的介面描述語言），來建造使用這介面。這個 Adobe Flex 框架編譯並轉成 Swf 後，其能在 Adobe Flash player 上執行。

1.2 Java applet

Java applets 是 Java 語言的一種類瀏覽器應用程式。

1.3 JavaFX

1.4 Silverlight

Silverlight 原名 WPF/E，使用 XAML，是一種基於 XML 的語言，有聲錄影（Movie Clips）、向量圖形（Vector Graphics）等功能，被稱為是 “Flash Killer”，亦可執行於 Firefox 甚至 Safari 等瀏覽器。Silverlight 3.0 可支援 H.264 影音媒體格式與 3D 繪圖能力。

發展歷史

“豐富網際網路應用程式系統” 一詞源於 Macromedia 公司在 2002 年 3 月發表的一份白皮書，儘管如此，該詞在更早的年代中就已包含其他含義，包括遠端指令碼（由微軟於 1998 年左右提出）、X Internet（由 Forrester Research 於 2000 年 10 月提出）、豐富（網頁）客戶端和豐富網路應用。

優點

儘管與開發執行在桌面的程式相比，開發執行在瀏覽器中的應用程式要更受限、更復雜、更困難，但是這種努力還是值得的，因為它具有以下優點：

安裝簡便 — 終端使用者可在任何連線到網際網路上的裝置中使用程式，而應用程式會自動或以簡單手動方式更新到最新版本，更新與使用費用與桌面程式和作業系統相比要經濟的多。
有很多工具支援離線使用，例如 Adobe AIR，Google Gears 等等。
多數豐富網際網路應用程式藉由網頁瀏覽器，可以跨平臺使用
與可執行檔案相比，基於網路的應用程式可以有效的避免病毒侵襲 (此一優點或已過時)

由於豐富網際網路應用程式採用客戶端引擎，所以它具有以下特點：

表現力豐富：豐富網際網路應用程式能在基於標準瀏覽器的網頁應用，實現 HTML 標籤難以實作的使用者介面效果。這種內涵更豐富的互動涵蓋所有在客戶端所能實現的功能，例如拖拽功能、滑塊功能，而且這些功能無需與伺服器端互動資料，完全是在客戶端進行運算，如抵押計算。
反應更加迅速：與那些總須與遠端伺服器進行互動的標準網頁瀏覽應用相比，豐富網際網路應用介面的反應要迅速的多，這也是豐富網際網路應用程式特點之一。成熟的豐富網際網路應用，會給人近似於本地端作業系統桌面程式的經驗。

而且，使用客戶端引擎還有以下好處：

C/S 結構的負擔平衡 (此點或為誤解，實作剛好相反)：豐富網際網路應用程式可以使客戶端和伺服器端對資源的需求更加平衡，從而使伺服器不必再像傳統網頁應用中那樣一直高負荷的運轉。由此伺服器端的資源得到了解放，從而提升了同一伺服器端硬體能並行服務的客戶端會話數量。
非同步通訊：無須等待使用者執行諸如在按鈕或連結上點選的互動操作，客戶端引擎便可與伺服器端進行互動。如此，使用者便可在客戶端引擎跟伺服器端通訊的同時，非同步地進行頁面瀏覽或互動。豐富網際網路應用程式的設計方式，便可在免予讓使用者等待的情境下，在客戶端與伺服器端之間傳輸資料 (因此伺服器端可能收到更多 http 請求，負荷會比傳統網頁更重)。程式會預先從伺服器端讀取資料，即程式預見到未來可能需要某些資料的時候，會先於使用者端發出請求之前將其下載，可提升回應後續請求的速度。Google Maps 便是利用了這種技術，先於使用者將螢幕滾動到臨近地區，預取到周圍的圖片資料。
網路效率高 (此點或為誤解，實作剛好相反)：豐富網際網路應用程式的網路通訊量也會明顯減少，這是由於在決定需要與伺服器端交換什麼資料時，為應用程式專門設計的客戶端引擎，會比標準的網頁瀏覽器更智慧 (?)。由於每次互動所需傳輸的資料量變少了，從而總負載也減輕了 (總負載並不因而減輕)，所以每個請求和響應的速度也就提升。

反之，非同步請求和預取資料技術的濫用，一定會削減原先預期帶來的優勢，有時甚至還會起到反作用 (此即現今實作弊端的起源)。程式本就無法準確地預期每個使用者下一步操作所需的資料，所以採用這種技術時時常下載過多冗餘資料 (為商業行銷用廣告居多)；對多數客戶端而言，這些資料其實並非使用者真正所需要的。

缺點

豐富網際網路應用程式存在以下缺陷：

受限於安全沙箱。由於豐富網際網路應用程式程式執行在安全沙箱中，所以其對系統資源的訪問會受到限制。一旦對系統資源的訪問出現錯誤，那麼豐富網際網路應用程式程式就將無法正常執行。
依賴於指令碼支援。豐富網際網路應用程式程式常常需要 JavaScript 或其它指令碼語言的支援。一旦使用者瀏覽器對這些指令碼進行遮蔽，豐富網際網路應用程式將無法正常運作。
客戶端執行速度受限。為實現平臺無關性，一些豐富網際網路應用程式選用諸如 JavaScript 這類指令碼語言來編寫其客戶端指令碼，從而導致了效能上的損失（在移動裝置中，此類問題尤為顯著）。而對於如 Java 這類的客戶端語言是不存在這類問題的，因為它的效能已可比擬傳統的編譯型語言了，而對於 Flash，Curl 或 Silverlight，因為在其外掛中所執行的程式碼也是經過編譯的，所以同樣也不存在這類問題。
下載指令碼的延時。雖然無需安裝軟體，但是豐富網際網路應用程式的客戶端引擎還是要從伺服器端傳送資訊到客戶端。雖然絕大多數傳輸資訊會被快取，但這種傳輸也至少要執行一次。根據下載的型別和大小，指令碼的下載可能會是一件令人苦惱的事情。對此，豐富網際網路應用程式的開發者可採取壓縮、分段等技術在一定程度上減少這種延遲帶來的影響。
整合困難。如果基於 X/HTML 開發應用，那麼應用程式的目的（嚮往控制一切表現效果和行為）和 X/HTML 的目的（嚮往解除一切控制）之間的衝突會進一步加劇。X/HTML 的 DOM 介面為建立豐富網際網路應用程式提供了一個可能，但是該方案又會導致豐富網際網路應用程式中的一些功能癱瘓。因為在該方案中，豐富網際網路應用程式的客戶端可以修改應用程式的基本結構並覆蓋其的表現效果和行為，這可能將導致應用程式在客戶端的執行錯誤。最終，該問題透過採用新式的客戶端機制來解決，在該機制中，豐富網際網路應用程式將受限於只能對其自身範圍的資源進行修改。（標準的執行在本地軟體之所以不存在該類問題是因為其遵循一個自動程式的定義，只能處理它自行分配的資源）。
搜尋引擎最佳化困難。搜尋引擎可能無法搜尋應用程式文字內容中的索引。
依賴於網際網路連線。最理想的替代桌面程式的網際網路應用程式要允許使用者間斷性的上網，這樣使用者就可以遊走在各個熱點與辦公地之間。鑑於此，一些特殊的平臺（如 Adobe AIR，Google Gears）就需要允許離線操作的豐富網際網路應用程式程式。
可訪問性存在困難。在豐富網際網路應用程式中存在很多訪問性的困難，其中多數明顯地表現為螢幕閱讀器在探測由 JavaScript 引起的 HTML 內容更變上遇到了極大的困難。
無法部署。除了 Adobe 的 AIR 技術以外，其它的豐富網際網路應用程式不能像傳統的桌面應用那樣進行部署。

4.1 軟體開發複雜性

豐富網際網路應用程式技術的出現，給網頁應用的開發引入了相當可觀的複雜度。僅使用標準 HTML 構建的傳統網頁應用，其軟體架構相對來說較為簡單，同時開發方案選擇也有限，所以比較起來易於設計和管理。對使用豐富網際網路應用程式技術的個人或組織而言，他們所面臨額外的複雜度是更難於進行設計、測試、評估和支援。

豐富網際網路應用程式技術的使用，引起了若干個在服務級管理（service level management，簡稱 SLM）上的新挑戰。而這些挑戰至今也仍未得到徹底解決。服務級管理所關心的並非總是應用開發者的焦點所在，也甚少為應用使用者所察覺，但它們對一個線上應用的成功交付，卻起著至關重要的作用。豐富網際網路應用程式架構中，使管理過程相對複雜化的方面包括：

更大的複雜度讓開發變得更加困難：將程式碼移至客戶端的能力，給了應用設計者和開發者更多的創造空間。但是這反過來也讓開發變得更加困難，增加了發生過失（bugs）的可能性，也加大了軟體測試的複雜度。無論引入何種方法論或過程，這些複雜程度都會延長開發過程。這些問題中有些可能利用網頁應用框架，對豐富網際網路應用程式的設計和開發進行標準化來減輕。但是不論以何種解決方案，如果增加了使用案例的數量，則導致後續的測試過程也將隨之複雜化並延長工期。而不完整的測試又會降低應用的品質，和使用時的可靠性。

有人可能要說，上邊的討論並非只是豐富網際網路應用程式技術特有的，而是關於複雜性的廣泛問題。例如，同樣的爭論就發生於蘋果跟微軟分別在 1980 年代釋出其 GUI 時，甚至可能還發生於 Ford 釋出其 Model T 時。不過在十幾年間，人類已展現了調適並且吸收新技術優勢的能力。

豐富網際網路應用程式架構違反了網頁正規化：傳統的網頁應用為一系列的網頁檔案，每一網頁都需單獨經由 HTTP GET 請求發起載入頁面過程。這種模型被稱為網頁正規化。豐富網際網路應用程式幾乎跳過了這樣子的流程，額外引入了非同步的伺服器端通訊方式來支援反應更迅速的使用者介面。在豐富網際網路應用程式中，完整載入一個頁面所需的時間，可能不再是使用者所能察覺到的重要指標，因為（打個比方說）客戶端引擎可能預先載入了某些內容。為了能有效地評估豐富網際網路應用程式，反映使用者體驗的指標，應會有新技術被設計出來。在這種評估技術出現之前，豐富網際網路應用程式的開發者，應該指示他們的應用程式碼來為 SLM 產生測量資料。
非同步通訊導致難以隔離效能問題。看似矛盾地，增強應用的響應能力的措施，同時也使其難於衡量、理解、報告以及管理響應能力。一些豐富網際網路應用程式在載入第一個頁面後，便不再從瀏覽器傳送任何 HTTP GET 請求，而是透過其客戶端引擎使用非同步請求來初始化後續下載。