【文章內(nèi)容簡(jiǎn)介】 雖然這種 限制可以提高可擴(kuò)展性，但對(duì)于權(quán)衡網(wǎng)絡(luò)性能和用戶的交互性來(lái)說(shuō)，更重要的是設(shè)計(jì)一個(gè) AJAX 架構(gòu)。 是以緩存為基礎(chǔ)，同時(shí)促進(jìn) AJAX 的實(shí)時(shí)數(shù)據(jù)檢索。 ，每一個(gè)反應(yīng)必須立即產(chǎn)生，每個(gè)請(qǐng)求只能產(chǎn)生一個(gè)響應(yīng)（ Khare 和 Taylor， 2020 年）。 Comet 需要一個(gè)使數(shù)據(jù)從服務(wù)器到客戶端推動(dòng)的模式。 這些不匹配的條件呼吁制定新的架構(gòu)風(fēng)格來(lái)滿足所需的屬性。 表 1： REST 提供的機(jī)制和 Ajax 所需應(yīng)用的對(duì)比 4 架構(gòu)屬性 一個(gè)軟件體系結(jié)構(gòu)的架構(gòu)性質(zhì)包括系統(tǒng)中獲得的功能 特性和非功能特性，功能特性通常被稱為質(zhì)量屬性（ Bass 等， 2020 年 。Offutt， 2020 年）。因?yàn)闃?gòu)架一個(gè)系統(tǒng)需要一個(gè)必要的理解，所以這些屬性也可以作為一些要求。 下面，我們討論了一些有關(guān) AJAX 本質(zhì)的架構(gòu)屬性。其他屬性，如可擴(kuò)展性和安全性，可能是任何系統(tǒng)所需要的，但都沒(méi)有直接采用 AJAX 技術(shù)去影響決定，所以不考慮在內(nèi)。請(qǐng)注意，下面討論的性質(zhì)是有相互關(guān)聯(lián)的：例如，用戶交互性影響用戶感知延遲，而這又同時(shí)影響了網(wǎng)絡(luò)性能。 用戶交互性 在人機(jī)交互學(xué)上的定義是在某種程度上通信過(guò)程的參與者可以控制的交互性 ，并存在相互交流的話語(yǔ)角色。用戶的交互性是密切相關(guān)的可用性（ Folmer， 2020 年），這個(gè)詞是在文獻(xiàn)中使用的軟件架構(gòu)。張志賢等（ 2020 年）提供了用戶交互性并在一個(gè)商業(yè)網(wǎng)絡(luò)應(yīng)用上進(jìn)行深入研究。他們的研究結(jié)果表明，交互程度的增加對(duì)用戶的感知滿意度，效能，效率，價(jià)值和對(duì)一個(gè)網(wǎng)站的整體態(tài)度事有正面影響的。改善這種網(wǎng)絡(luò)上的特性已成為 AJAX 進(jìn)步的主要?jiǎng)恿Α? 用戶感知延遲 用戶感知延遲是指用戶發(fā)出請(qǐng)求和從系統(tǒng)響應(yīng)的第一個(gè)跡象之間的時(shí)期。一般來(lái)說(shuō)，有兩種主要方式來(lái)改善用戶感知性能。首先，通過(guò)減少往返時(shí) 間，時(shí)間定為消息從瀏覽器傳到服務(wù)器，然后再返回，第二，允許用戶與系統(tǒng)進(jìn)行異步交互。這是所有帶客戶端的分布式應(yīng)用中的一個(gè)重要特性。 網(wǎng)絡(luò)性能 網(wǎng)絡(luò)性能受吞吐量的影響，吞吐量即在網(wǎng)絡(luò)和帶寬上數(shù)據(jù)傳輸?shù)乃俾?，即最高可傳輸?shù)臄?shù)據(jù)吞吐量，是一個(gè)度量衡。網(wǎng)絡(luò)性能可以通過(guò)減少傳輸數(shù)據(jù)的數(shù)量和粒度來(lái)提升。 簡(jiǎn)易性 簡(jiǎn)易或發(fā)展工作是指需要去了解，設(shè)計(jì)，實(shí)施，保持和發(fā)展一個(gè) Web 應(yīng)用工作。這是影響任何一個(gè)新方法使用和接受的重要因素。 可伸縮性 在分布式環(huán)境中的可擴(kuò)展性是由一個(gè)系統(tǒng) 對(duì)越來(lái)越多組件處理能力的程度決定的。在網(wǎng)絡(luò)工程中，系統(tǒng)的可擴(kuò)展性是確定的，例如，客戶可以被不同的服務(wù)器服務(wù)而不影響結(jié)果的程度?？缮炜s的 Web 體系結(jié)構(gòu)可以輕松配置，以服務(wù)越來(lái)越多的客戶要求。 可移植性 可在不同環(huán)境中使用的軟件被稱為是可移植的。在網(wǎng)絡(luò)上，能夠使用 Web 瀏覽器而不需要用戶的任何額外操作，例如，下載插件導(dǎo)致產(chǎn)生了可移植的特性。 可見(jiàn)度 可見(jiàn)性（ Fielding， 2020 年）是由外部調(diào)解員理解兩部分相互作用的程度決定的，即調(diào)解員越容易理解其相互作用，兩個(gè)組件之間的互動(dòng)就越明顯 。從當(dāng)前 AJAX框架的實(shí)行來(lái)看，可見(jiàn)度在客戶端服務(wù)器中的相互作用較低，因?yàn)樗鼈兪且愿髯缘膮f(xié)議為基礎(chǔ)的。雖然高層次的可見(jiàn)度使互動(dòng)更被理解，但相應(yīng)的高觀測(cè)性也會(huì)對(duì)安全問(wèn)題產(chǎn)生負(fù)面影響。因此，低可見(jiàn)度不是本身的劣勢(shì)特點(diǎn)，而是依賴于特性與權(quán)衡所構(gòu)成的期望的系統(tǒng)。 可靠性 可靠性是指正確服務(wù)的連續(xù)性（ Avizienis 等， 2020 年）。任何軟件系統(tǒng)的成功 很大程度上取決于它的可靠性。在互聯(lián)網(wǎng)上，依賴于不可靠軟件和惡劣工作的網(wǎng)絡(luò)應(yīng)用，就會(huì)失去客戶（ Offutt， 2020 年）。測(cè)試（測(cè)試自動(dòng)化，單位測(cè)試和 回歸測(cè)試）資源可以提高一個(gè)應(yīng)用程序的可靠性水平。但是，跟傳統(tǒng)的桌面應(yīng)用程序相比， Web應(yīng)用通常沒(méi)有作出很好的測(cè)試。除了短時(shí)間內(nèi)對(duì)市場(chǎng)的壓力，多頁(yè)互動(dòng)式網(wǎng)頁(yè)也使其很難檢驗(yàn)。采用單頁(yè)基于組件的 Web 應(yīng)用開(kāi)發(fā)方式可以提高系統(tǒng)的可測(cè)試性和結(jié)果的可靠性。 數(shù)據(jù)一致性 網(wǎng)絡(luò)數(shù)據(jù)對(duì)實(shí)時(shí)事件通知的一個(gè)重要方面是對(duì)數(shù)據(jù)一致性的修復(fù)，這些數(shù)據(jù)在事件發(fā)生時(shí)就要盡快地告知用戶，如股票價(jià)格（ Bhide 等， 2020 年）。如果服務(wù)器上的數(shù)據(jù)和客戶端是同步的，那么這個(gè)數(shù)據(jù)就被定義為是一致的。在堅(jiān)持 HTTP 協(xié)議的 Web應(yīng)用中，客戶端 需要頻繁地拉基于預(yù)定間隔的數(shù)據(jù)。相比之下，采用推性能的服務(wù)器維護(hù)了客戶的有關(guān)資料，并且當(dāng)發(fā)生變化時(shí)把其通知給用戶。這兩種技術(shù)在取得的數(shù)據(jù)一致性方面有不同的屬性（ Bozdag 等， 2020 年）。 適應(yīng)性 適應(yīng)性是指便于系統(tǒng)或該系統(tǒng)部件適應(yīng)不斷變化的環(huán)境的特性。在 Web 應(yīng)用中，一個(gè)允許在服務(wù)器上變化的架構(gòu)被傳播到客戶端即稱為適應(yīng)性。我們用代碼的動(dòng)態(tài)概念（ Fuggetta 等， 1998 年）來(lái)比較不同 AJAX 架構(gòu)行為方面的變性和適應(yīng)性。移動(dòng)代碼，一般來(lái)說(shuō)，是軟件代碼，它從遠(yuǎn)程服務(wù)器獲得，通過(guò)網(wǎng)絡(luò)傳輸， 然后下載并執(zhí)行在未明確安裝或由收件人執(zhí)行的客戶端上。 5 SPIAR 的建筑原理 根據(jù) Fielding， Perry 和 Wolf， SPAIR 的建筑原理主要分成三類，即數(shù)據(jù)處理（組件），數(shù)據(jù)和連接組件。關(guān)于組件的概貌在圖 1 中展現(xiàn)。在這一章節(jié)，我們對(duì)組件進(jìn)行解釋，而在下一章節(jié)，我們將討論他們之間的相互影響。 圖 1：一個(gè)基于 SPIAR架構(gòu)方式的處理 處理組件 處理元素是那些在數(shù)據(jù)元素上提供轉(zhuǎn)換處理的組件。 客戶瀏覽器提供一系列標(biāo)準(zhǔn)支持，如超文本傳送協(xié)議，超文本制標(biāo)語(yǔ)言，層疊網(wǎng)絡(luò)文稿， JAVA 描述語(yǔ)言以及文檔對(duì)象模型。通過(guò)對(duì)代表性模型的網(wǎng)頁(yè)進(jìn)行處理產(chǎn)生用戶界面。用戶交互可以建立在一個(gè)獨(dú)立的用戶界面模型上。所有的視覺(jué)漸變及效果都通過(guò)這個(gè)界面展現(xiàn)給用戶。就像桌面客戶應(yīng)用程序，它由一個(gè)獨(dú)立并帶有別的部件的主要頁(yè)面組成。這些部件的性質(zhì)可被獨(dú)立操作，而不要求刷新頁(yè)面去改變。 AJAX 系統(tǒng)是一個(gè)客戶系統(tǒng)，它在客戶瀏覽器中裝入運(yùn)行。網(wǎng)絡(luò)應(yīng)用及運(yùn)行不需要插件程序。然而，下載系統(tǒng)要向用戶產(chǎn)生初始等待時(shí)間，這將由更小的數(shù)據(jù)傳送來(lái)補(bǔ)償。此系統(tǒng)負(fù)責(zé)代表性模型的初始化和操作。從圖 1 可以看出，系統(tǒng)通過(guò)用戶處理事件的初始 化響應(yīng)，與服務(wù)器進(jìn)行通信以及執(zhí)行客戶端數(shù)據(jù)處理。 服務(wù)器應(yīng)用程序依附于服務(wù)器，通過(guò)接受來(lái)自網(wǎng)絡(luò)的 HTTP 響應(yīng)請(qǐng)求進(jìn)行運(yùn)作，向請(qǐng)求者提供應(yīng)答。所有的服務(wù)器端功能依附在服務(wù)器應(yīng)用程序數(shù)據(jù)處理組件上。 服務(wù)供應(yīng)商代表服務(wù)器的邏輯引擎處理狀態(tài)變化及用戶請(qǐng)求動(dòng)作。它可以存儲(chǔ)任意需要執(zhí)行動(dòng)作的資源（比如數(shù)據(jù)庫(kù)，網(wǎng)絡(luò)服務(wù)）。服務(wù)供應(yīng)商的功能是由事件監(jiān)聽(tīng)器調(diào)用，由組件附屬，通過(guò)引用請(qǐng)求初始的 Delta 編碼 /編碼程序輸出 /輸入 Delta信息?；谶@一點(diǎn)，用戶與服務(wù)器之間的通信協(xié)議被定義和隱藏在一個(gè)接口上。此組件支持用戶與服務(wù) 器之間的 Delta 通信，這個(gè)服務(wù)器提高了用戶覺(jué)察的等待時(shí)間以及網(wǎng)絡(luò)性能。 UI 組件由一系列服務(wù)器端的 UI 組件構(gòu)成。這個(gè)在服務(wù)器上的組件模型可以著色用戶的代表性模型。每個(gè)服務(wù)器端組件包含了數(shù)據(jù)以及部分依附于客戶端部件的性能，此部件與狀態(tài)變化相關(guān)；何時(shí)及怎樣著色客戶端的 UI 密碼有不同的途徑。比如，GWT 著色整個(gè)來(lái)自服務(wù)器端 Java 組件的客戶端 UI 密碼編譯時(shí)間。在另一方面，擁有一個(gè)真實(shí)基于組件的架構(gòu)命令著色在運(yùn)行時(shí)間的組件，并保持同在客戶端和服務(wù)器端的組件。這些 UI 組件有事件接聽(tīng)項(xiàng)，這些事件接聽(tīng)項(xiàng)可以依附于客戶端 用戶初始事件，比如點(diǎn)擊按鈕。這個(gè)組件通過(guò)提供位物變數(shù)組件而建立網(wǎng)絡(luò)應(yīng)用系統(tǒng)來(lái)提高單一性。 服務(wù)器依附于一個(gè)在服務(wù)器應(yīng)用系統(tǒng)上的獨(dú)立模塊。此數(shù)據(jù)處理組件有能力開(kāi)啟從服務(wù)器到用戶的數(shù)據(jù)入棧的 HTTP 連接。服務(wù)器供應(yīng)商可以發(fā)布給此組件新的數(shù)據(jù)（狀態(tài)改變）。推送客戶組件依附于客戶端內(nèi)。它可以是一個(gè)獨(dú)立的模塊或是 AJAX引擎的一部分。此組件可以描述為在推送服務(wù)器組件上一個(gè)特別的通道，接收來(lái)自服務(wù)器發(fā)布的實(shí)時(shí)數(shù)據(jù)。 數(shù)據(jù)組件 數(shù)據(jù)組件包含通過(guò)由數(shù)據(jù)處理組件使用和轉(zhuǎn)換的信息。 表征組件包括任意媒體形式，比如 REST。 HTML、 CSS 以及圖象都是這個(gè)數(shù)據(jù)組件的組成部分。 代表性模塊是一個(gè)運(yùn)行時(shí)間的抽象性，它表明 UI 怎樣在客戶端瀏覽器上顯現(xiàn)。瀏覽器內(nèi)的文檔對(duì)象模型在 AJAX 應(yīng)用系統(tǒng)中有著非常重要的作用。它主要通過(guò)操作這個(gè)代表性模塊產(chǎn)生豐富的效果。一些構(gòu)架比如 Backbase， 運(yùn)用特別域語(yǔ)言來(lái)定義結(jié)構(gòu)及代表性模塊的性能。其他像 GWT 則用一個(gè)直接的途徑，即運(yùn)用 JAVA 描述語(yǔ)言。 Delta 通信信息形成了客戶及服務(wù)器之間的 Delta 通信協(xié)議方式。 SPIAR 對(duì)客戶端 Delta 數(shù)據(jù)和服務(wù)器端 Delta 數(shù)據(jù)作了區(qū)別。前者由客戶創(chuàng) 造，代表客戶端狀態(tài)改變的相應(yīng)命令引起這些變化，而后者響應(yīng)是在服務(wù)器組件上命令的結(jié)果。此 Delta通信的數(shù)據(jù)建立在各種當(dāng)前的格式上，比如 XML。 JavaScript Object Notation 或者完全的 Java 描述語(yǔ)言?？蛻舳?Delta 消息包含了服務(wù)器所需的信息，例如知道這些行動(dòng)必須執(zhí)行的組成部分。 作為一個(gè)例子，圖 2 顯示了在 Echo2 中的 Delta 通信。用戶點(diǎn)擊一個(gè)組件（按鈕ID 為 c_7）后，客戶端引擎檢測(cè)并將它傳到服務(wù)器端，顯示在圖 2 的 REQUEST 塊中。然后服務(wù)器使用在 Delta 的客戶端信息，響應(yīng)一 個(gè)服務(wù)器端 XML 格式的 Delta。在這種情況下，是由行動(dòng)，組件 ID 和事件類型組成的。可以看出， Delta 服務(wù)器告訴客戶端引擎到底如何與新的風(fēng)格和文字內(nèi)容，特別是與 ID c_35_content 的父組件來(lái)更新 DOM 狀態(tài)。 圖 2： Echo2中 Delta 通信的一個(gè)例子 我們區(qū)分三種代碼，可以改變客戶端的狀態(tài)：表象代碼，功能代碼和文本數(shù)據(jù)。 表象代碼顧名思義是對(duì)視覺(jué)風(fēng)格和應(yīng)用演示方面有影響，例如， CSS 或 HTML 格式。文本數(shù)據(jù)是單純的數(shù)據(jù)。功能代碼可以執(zhí)行在客戶端，例如， JavaScript 代碼，或 XML 格式的命令（例如，在圖 2 中的 DOM 添加）。 Delta 服務(wù)器可以組成任意這些三種類型的代碼。這三種類型的代碼可以影響到客戶端的應(yīng)用代表性模型（ DOM），它是運(yùn)行時(shí)代碼的表象抽象，被執(zhí)行的功能代碼和文本數(shù)據(jù)的結(jié)合。 GWT 使用 Delta 服務(wù)器主要是由文本數(shù)據(jù)組成的 RPC 樣式的服務(wù)，而在 Backbase公司和 Echo2 中一個(gè)基于組件的方法實(shí)施調(diào)用事件監(jiān)聽(tīng)器，是混合在一個(gè)表象和功能的代碼中的。 連接組件 連接元素作為粘合劑，擔(dān)當(dāng)了使它們能夠結(jié)合起來(lái)的作用。 時(shí)間構(gòu)成了在 SPIAR 中交互模型的基礎(chǔ)。一個(gè)事件是由每個(gè)發(fā)起的對(duì)接口傳播到用戶操作的引擎。根據(jù)事件的種類，一個(gè)請(qǐng)求到服務(wù)器，或一次接口的部分更新都是可能需要的。如果需要，該事件可以異步處理，在這種情況下，控制立即返回給用戶。 在服務(wù)器上，會(huì)請(qǐng)求由事件發(fā)起調(diào)用的服務(wù)。這項(xiàng)服務(wù)可以直接或通過(guò)調(diào)用相應(yīng)的用戶界面組件的事件監(jiān)聽(tīng)器來(lái)實(shí)現(xiàn)。 Delta 連接器是輕量級(jí)的，用通信媒體連接引擎和服務(wù)器使用請(qǐng)求 /響應(yīng)機(jī)制來(lái)結(jié)束 HTTP。 Delta 更新用于更新客戶端和組件模型在服務(wù)器上的代表性模式，以反映狀態(tài)的變化。當(dāng)一個(gè)代表性模式的增量更新在直接 的用戶界面并且有一個(gè)直接明顯的結(jié)果，那么說(shuō)明一個(gè)組件模型的更新引起了適當(dāng)?shù)穆?tīng)眾。這些更新通常是通過(guò)程序調(diào)用的方法實(shí)現(xiàn)的。 渠道是在基于推的消費(fèi)者和生產(chǎn)商之間連接的元素。一個(gè)消費(fèi)者（接收器）訂閱了一個(gè)渠道，通過(guò)握手的程序，并接收任何由生產(chǎn)者（信息來(lái)源）從 Delta 推動(dòng)服務(wù)器通道發(fā)送的信息。 6 架構(gòu)觀點(diǎn) 由于加工，數(shù)據(jù)和連接的因素，我們可以使用不同的架構(gòu)觀點(diǎn)來(lái)描述元素，形成一個(gè)共同的結(jié)構(gòu)。在這里，我們利用兩個(gè)處理意見(jiàn)，在某些方面集中數(shù)據(jù)流和與各方面的數(shù)據(jù)處理單元連接（ Fielding， 2020 年）。這種觀點(diǎn)適 合在組件和連接器視圖類型中討論，（ Clements 等 ,2020 年）。我們談?wù)撘粋€(gè)對(duì)基于組件的 AJAX 解決方案的處理意見(jiàn)，一個(gè)是一種基于 RPC 的 AJAX 應(yīng)用，一個(gè)是查看基于推的變形。 AJAX 方式 圖 1 描述了一個(gè)以 SPIAR 為基礎(chǔ)的處理方式，在體系結(jié)構(gòu)上翻譯了運(yùn)行時(shí)的組件，例如， Echo2。該視圖顯示了一些在最初的頁(yè)面請(qǐng)求中組件相互作用的時(shí)間（引擎是在客戶端上運(yùn)行）。 用戶接口關(guān)閉一個(gè)事件上的用戶活動(dòng)，表示了某種組件定義的行動(dòng)是授權(quán)給AJAX 引擎的。如果在服務(wù)器偵聽(tīng)端上的組件已注冊(cè)到事件本身，發(fā) 動(dòng)機(jī)會(huì)作出 Delta的相應(yīng)事件來(lái)改變當(dāng)前狀態(tài)的客戶端郵件，并將其發(fā)送到服務(wù)器。在服務(wù)器上，解碼器將轉(zhuǎn)換信息，確定并通知組件樹(shù)中有關(guān)的組成部分。更改后的組件最終將調(diào)用服務(wù)提供者的事件監(jiān)聽(tīng)器。服務(wù)供應(yīng)商處理之后的行動(dòng)，將更新的對(duì)應(yīng)組件由編碼器回報(bào)到新的狀態(tài)。之后，呈現(xiàn)的增量服務(wù)郵件，送回到將用于更新的代表性模型，并最終顯示在接口。如果服務(wù)器還是沒(méi)有需要，引擎也有直接在事件以后更新代表模型往返的能力。 在運(yùn)行時(shí)處理的 GWT 框架圖描述如圖 3?？梢钥闯?， GWT 不維護(hù)服務(wù)器端的組件樹(shù)。相反，服務(wù)器端