關(guān)于AJAX構(gòu)架的一點(diǎn)構(gòu)想

以前搞了一個(gè)XPP的編程平臺(tái)，應(yīng)該來說，不是一個(gè)成功的東東。XPP本身確實(shí)解決了目前編程的諸多問題，例如頁面狀態(tài)保持、統(tǒng)一的界面風(fēng)格、良好的數(shù)據(jù)效驗(yàn)器，但并沒有考慮到數(shù)據(jù)傳輸?shù)膯栴}，雖然采用了壓縮流來傳遞數(shù)據(jù)，但同樣也增加了服務(wù)器的壓力。也許對(duì)于中小型的企業(yè)應(yīng)用，XPP可以作為一個(gè)被選的平臺(tái)，但作為大型的企業(yè)應(yīng)用，XPP表現(xiàn)恐怕很難實(shí)用。
在有了上次失敗的經(jīng)歷后，考慮是否可以采用AJAX作為一個(gè)輕量級(jí)的框架(XPP的體系太過龐雜，過多在服務(wù)端考慮了前端的UI邏輯，也是這才是失敗的根本)，側(cè)重于業(yè)務(wù)邏輯層的調(diào)用，不再考慮UI層的邏輯。
AJAX主要實(shí)現(xiàn)的主要技術(shù):
1、XmlHttpRequest
主要考慮是否需要支持瀏覽器的差異性，目前至少提供對(duì)IE和Mozilla的支持，以后是否考慮對(duì)其他瀏覽器進(jìn)行支持？
這是是個(gè)很easy的問題，暫時(shí)不進(jìn)行深入探索。

2、XML數(shù)據(jù)傳輸層的封裝(AJAX的核心)
AJAX的核心數(shù)據(jù)傳遞毫無疑問只能是基于XML的，如何有效地對(duì)XML數(shù)據(jù)輸送層進(jìn)行封裝，來保證構(gòu)架良好的可用性和擴(kuò)展性？這里主要是需要考慮兩個(gè)方面：良好的封裝性和執(zhí)行效率。
我初步的想法是服務(wù)端采用類似buffalo的技術(shù)實(shí)現(xiàn)JAVA POJO與XML的序列化，客戶端采用js實(shí)現(xiàn)類封裝實(shí)現(xiàn)JAVA對(duì)象的映射(考慮采用服務(wù)器端自動(dòng)生成js文件，并動(dòng)態(tài)加載js對(duì)象，以提高瀏覽器的處理能力)，并在此基礎(chǔ)上實(shí)現(xiàn)XML-PRC。

3、服務(wù)端集成
考慮AJAX與其它架構(gòu)集成的方案，并保證系統(tǒng)良好的安全性和執(zhí)行效率。

暫時(shí)處于疑問中的幾個(gè)問題：
1、UI層如何表現(xiàn)？
采用AJAX的話，是采用js構(gòu)建頁面還是采用XmlHttp獲取服務(wù)端返回的頁面信息？

2、數(shù)據(jù)效驗(yàn)問題？
對(duì)于AJAX作RIA的應(yīng)用，UI層的數(shù)據(jù)效驗(yàn)肯定是必要的，由于采用AJAX，用戶繞過UI效驗(yàn)是很容易的事情，如果在服務(wù)端同樣做數(shù)據(jù)效驗(yàn)的話，是否會(huì)增加代碼的編寫工作量？是否能夠采用統(tǒng)一的數(shù)據(jù)效驗(yàn)？如何可以的話，如何實(shí)現(xiàn)？

目前buffalo主要有如下問題：
a. JAVA Object的序列化邏輯與RPC的業(yè)務(wù)邏輯混在一起，不利于系統(tǒng)的擴(kuò)展
b. buffalo只支持UTF-8編碼的XML，不支持GBK編碼的XML
c. buffalo可以調(diào)用服務(wù)的所有方法，可能會(huì)對(duì)服務(wù)器產(chǎn)生一定的安全隱患