基于Ajax的應用程序架構匯總及開發(fā)面臨的問題介紹

1純Javascript：應用程序框架

　　1.1 Bindows(自從2003年)

　　Bindows是一個軟件開發(fā)包(SDK)，它，通過強力聯(lián)合DHTML，JavaScript，CSS和XML等技術，能生成高度交互的互聯(lián)網(wǎng)應用程序-成為現(xiàn)代的桌面應用程序的強有力對手。Bindows應用程序不要求下載和也不需要在用戶端安裝-僅要求有一個瀏覽器(也不需要Java，F(xiàn)lash或者ActiveX)。Bindows有可能領導面向?qū)ο箝_發(fā)的AJAX應用程序的平臺。

　　1.2 BackBase(自從2003年)

是一個全面的瀏覽器端框架，支持豐富的瀏覽器功能以及與.NET和Java的集成。

　　·商業(yè)化，來自于Backbase B.V(總部在Amsterdam，成立于2003年)。

　　1.3 DOJO(開發(fā)中;自從2004年9月)

提供全面窗口小組件和瀏覽器-服務器消息支持。

　　·為創(chuàng)建定制的Javascript窗口小組件提供框架支持。

　　1.4 Open Rico(開發(fā)中;自從2005年5月;基于早期的私有框架)

是一多用途框架，支持Ajax基礎結構和用戶交互。

　　1.5 qooxdoo(開發(fā)中;自從2005年5月)

是另一個雄心勃勃的框架，提供寬范圍的UI支持和正在開發(fā)中的基礎結構特性。

　　1.6 Tibet(開發(fā)中;自從2005年6月)

　目的是提供高度可移植的和全面的Javascript API，結果是，可能自動生成大量的客戶端代碼。自稱是"企業(yè)級Ajax"。

　　2 純Javascript：基礎結構框架

　　2.1 AjaxCaller(Alpha版本;自從5月2005年)

是一基本的線程安全的XMLHttpRequest包裝器，主要針對Ajax新手，仍處于原始的alpha開發(fā)階段，

　　2.2 Flash JavaScript集成包

允許JavaScript和Flash內(nèi)容的集成

　　2.3 Google AJAXSLT(發(fā)行于2005年6月)

　是一個Javascript框架，用來執(zhí)行XSLT轉(zhuǎn)換以及XPath查詢。

　　2.4 HTMLHttpRequest(Beta版;始于2005年)

　　HtmlHttpRequest它使用了XMLHttpRequest和Iframes以改進兼容性。

　　2.5 交互式網(wǎng)站框架(自從2005年5月)

　　交互式網(wǎng)站框架目的是從瀏覽器端對Ajax基礎結構的多方面予以支持。自描述為"使用javascript，css，xml，和html來創(chuàng)造高度交互網(wǎng)站的框架。包括一個定制的針對高度可讀的javascript的xml分析器。實質(zhì)上，是建立基于AJAX的網(wǎng)站的基礎，還有另外一些通用腳本"。

　　2.6 LibXMLHttpRequest(發(fā)行于2003年6月)

　　libXmlRequest是XMLHttpRequest的一個瘦包裝器。

　　2.7 RSLite(x)

　是一個針對XMLHttpRequest的瘦包裝器。

　　2.8 Sack(在開發(fā)中，自從2005年5月)

　是一個針對XMLHttpRequest的瘦包裝器。

　　2.9 Sarissa(發(fā)行于2月，2003年)

是一種Javascript API，它封裝了在瀏覽器端可以獨立調(diào)用XML的功能。

　　2.10 XHConn(發(fā)行于自從4月，2005年)

　是一個對XMLHttpRequest的瘦包裝器。

　　2.11 Jquery

　　簡潔的思想：幾乎所有操作都是以選擇DOM元素(有強大的Selector)開始，然后是對其的操作(Chaining等特性)。

　　3 服務器端：多種語言

　　3.1 跨平臺異步的接口工具箱(5月2005年)

　　是一真正的支持PHP和ASP/Vbscript的Ajax實現(xiàn)和JSRS(JavaScript遠程腳本)實現(xiàn)。CPAINT提供給你需求的代碼在后臺實現(xiàn)AJAX和JSRS，而返回的數(shù)據(jù)以JavaScript形式在前臺操作，格式化和顯示。這允許你創(chuàng)建能提供接近實時的反饋給用戶的web應用程序。

　　3.2 SAJAX(可用，但是不是1.0版本;自從3月2005年)

　直接把調(diào)用從Javascript發(fā)送到你的服務器端語言并再次回返。

　　3.3 Javascipt對象標志(JSON)和JSON-RPC

是一個"胖的自由的XML選擇"，而JSON-RPC是一種遠程過程協(xié)議，類似于XML-RPC，強有力支持Javascript客戶。

　　3.4 Javascript遠程腳本(JSRS)(自從2000年)

　直接把調(diào)用從Javascript發(fā)送到你的服務器端語言并再次回返。
　4 服務器端：Java

　　4.1 WebORB for Java(自從2005年8月)

　是一個平臺，支持開發(fā)AJAX和基于Flash的胖客戶端應用程序，并可以把它們與Java對象和XML Web服務相系起來。在線舉例(http：//www.themidnightcoders.com/examples)

　　4.2 Echo 2(自從3月2005年)

　允許你用純Java代碼編寫Ajax應用軟件

　　4.3 Direct Web Remoting (DWR)(2005年)

是一個框架，用于直接從Javascript代碼中調(diào)用Java方法。

　　4.4 SWATO(2005年)

是一套可重用的和良好集成的Java/JavaScript庫，它實現(xiàn)了一種更容易的方式來改變你的web應用程序的交互，它是通過AJAX方式實現(xiàn)。

　　5 服務器端：Lisp

　　5.1 CL-Ajax

　實現(xiàn)Javascript直接調(diào)用服務器端Lisp函數(shù)。

　　6 服務器端：.NET

　　6.1 WebORB for.NET(自從8月2005年)

　是一個平臺，用于開發(fā)AJAX和基于Flash的胖客戶端應用程序，并能把它們連接到.NET對象和XML Web服務

　　6.2 Ajax.NET(自從3月2005年)

　是一個庫，實現(xiàn)從Javascript到服務器端.NET的存取。

　　7 服務器端：PHP

　　7.1 AjaxAC(自從2005年4月)

用單個的PHP類封裝了完整的應用程序。

　　7.2 JPSpan

　　直接把Javascript調(diào)用傳遞到PHP函數(shù)。

　　7.3 XAJAX

直接把Javascript調(diào)用傳遞到PHP函數(shù)。

　　8 服務器端：Ruby

是一個通常的強力支持Ajax的web框架：

　　開發(fā)Ajax應用面臨的問題及解決方案

　　對程序員而言，開發(fā)Ajax應用最頭痛的問題莫過于以下幾點：

　　Ajax在本質(zhì)上是一個瀏覽器端的技術，首先面臨無可避免的第一個問題即是瀏覽器的兼容性問題。各家瀏覽器對于JavaScript/DOM/CSS的支持總有部分不太相同或是有Bug，甚至同一瀏覽器的各個版本間對于JavaScript/DOM/CSS的支持也有可能部分不一樣。這導致程序員在寫Ajax應用時花大部分的時間在調(diào)試瀏覽器的兼容性而非在應用程序本身。因此，目前大部分的Ajax鏈接庫或開發(fā)框架大多以js鏈接庫的形式存在，以定義更高階的JavaScript API 、JavaScript對象(模板)、或者JavaScript Widgets來解決此問題。如prototype.js。

　　Ajax技術之主要目的在于局部交換客戶端及服務器之間的數(shù)據(jù)。如同傳統(tǒng)之主從架構，無可避免的會有部分的業(yè)務邏輯會實現(xiàn)在客戶端，或部分在客戶端部分在服務器。由于業(yè)務邏輯可能分散在客戶端及服務器，且以不同之程序語言實現(xiàn)，這導致Ajax應用程序極難維護。如有用戶接口或業(yè)務邏輯之更動需求，再加上前一個JavaScript/DOM/CSS之兼容性問題，Ajax應用往往變成程序員的夢魘。針對業(yè)務邏輯分散的問題，Ajax開發(fā)框架大致可分為兩類：

　　將業(yè)務邏輯及表現(xiàn)層放在瀏覽器，數(shù)據(jù)層放在服務器：因為所有的程序以JavaScript執(zhí)行在客戶端，只有需要數(shù)據(jù)時才向服務器要求服務，此法又稱為胖客戶端(fat client)架構。服務器在此架構下通常僅用于提供及儲存數(shù)據(jù)。此法的好處在于程序員可以充分利用JavaScript搭配業(yè)務邏輯來做出特殊的用戶接口，以符合終端用戶的要求。但是問題也不少，主因在第一，JavaScript語言本身之能力可能不足以處理復雜的業(yè)務邏輯。第二，JavaScript的執(zhí)行效能一向不好。第三，JavaScript訪問服務器數(shù)據(jù)，仍需適當?shù)姆掌鞫顺绦蛑浜?。第四，瀏覽器兼容性的問題又出現(xiàn)。有些Ajax開發(fā)框架如DWR企圖以自動生成JavaScript之方式來避免兼容的問題，并開立通道使得JavaScript可以直接調(diào)用服務器端的Java程序來簡化數(shù)據(jù)的訪問。但是前述第一及第二兩個問題仍然存在，程序員必須費相當?shù)牧獠拍苓_到應用程序之規(guī)格要求，或可能根本無法達到要求。

　　將表現(xiàn)層[2]、業(yè)務邏輯、及數(shù)據(jù)層放在服務器，瀏覽器僅有用戶接口引擎(User Interface engine);此法又稱為瘦客戶端(thin client)架構，或中心服務器(server-centric)架構。瀏覽器的用戶接口引擎僅用于反映服務器的表現(xiàn)層以及傳達用戶的輸入回到服務器的表現(xiàn)層。由瀏覽器所觸發(fā)之事件亦送回服務器處理，根據(jù)業(yè)務邏輯來更新表現(xiàn)層，然后反映回瀏覽器。因為所有應用程序完全在服務器執(zhí)行，數(shù)據(jù)及表現(xiàn)層皆可直接訪問，程序員只需使用服務器端相對較成熟之程序語言(如Java語言)即可，不需再學習JavaScript/DOM/CSS，在開發(fā)應用程序時相對容易。缺點在于用戶接口引擎以及表現(xiàn)層通常以標準組件的形式存在，如需要特殊組件(用戶接口)時，往往須待原框架之開發(fā)者提供，緩不濟急。如開源碼Ajax開發(fā)框架ZK目前支持XUL及XHTML組件，尚無XAML之支持。

　　Ajax是以異步的方式向服務器提交需求。對服務器而言，其與傳統(tǒng)的提交窗體需求并無不同，而且由于是以異步之方式提交，如果同時有多個Ajax需求及窗體提交需求，將無法保證哪一個需求先獲得服務器的響應。這會造成應用程序典型的多進程(process)或多線程(thread)的競爭(racing)問題。程序員因此必須自行處理或在JavaScript里面動手腳以避免這類競爭問題的發(fā)生(如Ajax需求未響應之前，先disable送出按鈕)，這又不必要的增加了程序員的負擔。目前已知有自動處理此問題之開發(fā)框架似乎只有ZK。