【正文】 a 服務(wù)器實(shí)時(shí)發(fā)送給客戶端。首先，它允許數(shù)字信號(hào)直接發(fā)送給用戶。 圖 5：基于推技術(shù)的集成 7 架構(gòu)限制 架構(gòu)限制，可以理解為對(duì)架構(gòu)元素的角色限制以促使系統(tǒng)所需的建筑屬性。 表 2：制約因素導(dǎo)致的特性 單頁(yè)界面 SPIAR 是基于客戶機(jī)服務(wù)器風(fēng)格的，是在網(wǎng)絡(luò)環(huán)境中最出名的分布式應(yīng)用體系結(jié)構(gòu)。 圖 6:傳統(tǒng)的多頁(yè) Web 交互 圖 7：以客戶為中心的 Ajax交互 異步交互 AJAX 應(yīng)用的設(shè)計(jì)具有較高的用戶交互性和較低的用戶感知延遲。 Delta 通信 傳輸?shù)娜哂鄶?shù)據(jù)主要產(chǎn)生原因是沒(méi)有改變網(wǎng)頁(yè)的轉(zhuǎn)播，這是傳統(tǒng) Web 應(yīng)用的局限性之一。 SPIAR 更進(jìn)一步的使用一個(gè) Delta 的互動(dòng)通信方式。 這個(gè)限制直接導(dǎo)致網(wǎng)絡(luò)性能，像用戶感知和用戶交互的延遲。該模型定義了狀態(tài)和 UI 組件的行為和方式，使它們能夠相互作用。 框架遵守這一限制，適應(yīng)流動(dòng)性方面的代碼，在 節(jié)我們說(shuō)了三個(gè)代碼類型可以進(jìn)行狀態(tài)變化并傳播到客戶端。并使用 Web 標(biāo)準(zhǔn)， Web 瀏覽器遵守標(biāo)準(zhǔn)是很容易支持的，因此會(huì)引起某種程度的可靠性（ Avizienis 等， 2020 年）。作為交易，客戶端的性能可以成為一個(gè)籌碼，比如是否要處理很多需要在客戶端上的部件資源。在 Web 應(yīng)用中，命令的相互作用是相關(guān)的，使彼此互動(dòng)，這需要一個(gè)整體的組成部分以及拓?fù)浣Y(jié)構(gòu)的 依賴。 基于推的發(fā)布 /訂閱 客戶端和服務(wù)器交互作用是在基于推或者拉的風(fēng)格下實(shí)現(xiàn)的。 在基于拉的樣式中，表現(xiàn)方法是主動(dòng)請(qǐng)求客戶端組件的狀態(tài)變化。用戶感知延遲和適應(yīng)能力也有所改善，允許實(shí)時(shí)事件通知狀態(tài)變化給客戶。 Echo2 是 SPIAR 最具代表性的，因?yàn)樗谐浞值氖录?qū)動(dòng)和基于組件的架構(gòu)。但 GWT 不依賴服務(wù)器端組件的架構(gòu)，因此，不完全符合 SPIAR。 典型的 AJAX 配置 許多工業(yè)框架已經(jīng)開始在網(wǎng)絡(luò)上支持互動(dòng)的 AJAX 風(fēng)格。第一項(xiàng)是基于 REST 的經(jīng)典的Web 配置。如 Dojo， Ext 和 jQuery 都在客戶端上提供了豐富的用戶界面 UI 部件，促進(jìn)以客戶為中心的互動(dòng)模式，其中大部分功能是加載到瀏覽器關(guān)閉的。 如 GWT， DWR， 和 JSON RPC 的 Java 框架，支持的異步遠(yuǎn)程過(guò)程調(diào)用（ ARPC)）的交互方式。 第四個(gè)配置是一個(gè)純粹的基于推動(dòng)的交流，把該狀態(tài)的改變傳輸?shù)娇蛻舳耍ㄍㄟ^(guò)保持連接），沒(méi)有任何來(lái)自客戶端的明確要求。 表 3:Ajax配置和性能 AJAX 推進(jìn)的問(wèn)題 可伸縮性是推模型與傳統(tǒng)服務(wù)器模型的主要問(wèn)題。有 一個(gè)更好的基于服務(wù)器的工具事件。Bozdag 和 Mesbah， 2020 年）表明，推動(dòng)可以提供更高的數(shù)據(jù)一致性和更高的網(wǎng)絡(luò)性能，但同時(shí)也是一個(gè)消耗更多 CPU周期拉動(dòng)的 Comet 服務(wù)器應(yīng)用。不過(guò)相當(dāng)數(shù)量的狀態(tài)需要被維護(hù)，特別是普遍的數(shù)據(jù)項(xiàng)，（ Bhide 等， 2020）。使用一個(gè)通用的接口， 并提供身份，這個(gè)身份是網(wǎng)絡(luò)上的共同資源，這已成為網(wǎng)絡(luò)成功的關(guān)鍵因素之一。為了能夠回答這個(gè)問(wèn)題，我們需要看一看在單一網(wǎng)頁(yè)內(nèi)部的互動(dòng)：安全與不安全的相互作用。 該網(wǎng)站的架構(gòu)建議具有獨(dú)特的性能，并以資源為基礎(chǔ)來(lái)解決安全的相互作用（網(wǎng)址），而不安全的部分不一定對(duì)應(yīng)其中之一。 為了提供連接給安全操作的 AJAX， URI 的片段標(biāo)識(shí)符的網(wǎng)址（部分在 URL 中＃后）可讓其通過(guò)。如何計(jì)算分布在調(diào)整的 Web 應(yīng)用程序是一個(gè)重要因素。用戶可以發(fā)送一個(gè)請(qǐng)求到服務(wù)器，然后在此前得到回應(yīng)。 通信協(xié)議 正如我們所看到的，目前每一個(gè) AJAX 框架已經(jīng)實(shí)施了自己具體的通信協(xié)議。這兩個(gè)屬性可以通過(guò)定義一個(gè)標(biāo)準(zhǔn)的通信協(xié)議規(guī)范實(shí)現(xiàn)。 設(shè)計(jì)模型 圖 8 顯示了 AJAX 的 Web 應(yīng)用程序模型。一種觀點(diǎn)的變化，可以被看作是通過(guò)現(xiàn)有的部件駕馭的。 SPIAR 是一整套協(xié)調(diào)一致的體系結(jié)構(gòu)的限制，它試圖盡量減少用戶感知延遲和網(wǎng)絡(luò)使用，提高數(shù)據(jù)的一致性和最終用戶體驗(yàn)。 這種風(fēng)格側(cè)重于前期的網(wǎng) 絡(luò)應(yīng)用，即新品種結(jié)束時(shí)，服務(wù)提供商作為一個(gè)抽象的組件，它可以是中間返回組成的軟件產(chǎn)品。 一些技術(shù)書籍上出現(xiàn)了對(duì)開發(fā) AJAX 應(yīng)用程序的問(wèn)題。雖然這些書籍側(cè)重于執(zhí)行問(wèn)題，但是我們的工作主要是檢查在兩個(gè)不同客戶機(jī) /服務(wù)器組成部分的相互作用重點(diǎn)抽象層的架構(gòu)設(shè)計(jì)的決策和屬性。目前的重點(diǎn)，唯一的工作是 AJAX 在白色文件的 Khare（ 2020 年）。 該網(wǎng)頁(yè)序列是傳統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)模型，因此很難保存獨(dú)立的的網(wǎng)頁(yè)（片段）部分。最近提出的辦法包括一些服務(wù)器端和緩存方的機(jī)制。雖然片段可以獨(dú)立進(jìn)行檢索，但這些技術(shù)缺乏交互性的用戶界面組件以及所需的互動(dòng)應(yīng)用。Monroe 和 Garlan， 1996 年 。我們的工作密切相關(guān) REST 風(fēng)格的軟件工程原則（ Fielding 和 Taylor，2020 年）。 前面的架構(gòu)風(fēng)格可以概括為：基于事件的信托管理的分散應(yīng)用（ Suryanarayana等， 2020 年）， TIGRA 架構(gòu)風(fēng)格（ Emmerich 等， 2020 年）的分布式系統(tǒng)集成方面與中部辦公系統(tǒng)和 后臺(tái)辦公應(yīng)用，和 Aura（ Sousa 和 Garlan， 2020 年）中，用戶使用模式在環(huán)境中流動(dòng)的架構(gòu)框架，成立一流的實(shí)體，監(jiān)測(cè)和適應(yīng)計(jì)算環(huán)境。 最近， Erenkrantz 等（ 2020 年）已重新評(píng)估了新興的網(wǎng)絡(luò)體系結(jié)構(gòu)，即 REST風(fēng)格。他們的新風(fēng)格是擴(kuò)展 REST，被稱為計(jì)算的 REST（ CREST）。 10 結(jié)束語(yǔ) AJAX 作為一個(gè)有前途的解決方案執(zhí)行在敏感的設(shè)計(jì)和豐富的網(wǎng)絡(luò)應(yīng)用中，因?yàn)樗朔藗鹘y(tǒng)的客戶端限制服務(wù)器的方法。 從軟件體系結(jié)構(gòu)的角度來(lái)看，我們的貢獻(xiàn)是對(duì)概念和方法的，從軟件體系結(jié)構(gòu)的研究中獲得了 AJAX Web 應(yīng)用程序設(shè)置的使用。我們還提出一個(gè)基于組件和推技術(shù)的架構(gòu)，使其對(duì)同步在服務(wù)器和客戶端的事件都有效。 今后的工作包含了對(duì) SPIAR 的用途分析和影響 AJAX 發(fā)展的因素。 參考文獻(xiàn) Asleson, R., Schutta, ., 2020. Foundations of Ajax. Apress. Avizienis, A., Laprie, ., Randell, B., Landwehr, C., 2020. Basic concepts and taxonomy of dependable and secure puting. IEEE Trans. Depend. Secure Comput. 1 (1), 11–33. Barrett, ., Clarke, ., Tarr, ., Wise, ., 1996. A framework for eventbased software integration. ACM Trans. Softw. Eng. Methodol. 5 (4), 378–421. Bass, L., Clements, P., Kazman, R., 2020. Software Architecture in Practice, second ed. AddisonWesley. BernersLee, T., Masinter, L., McCahill, M., 1984. RFC 1738: Uniform Resource Locators (URL). Bhide, M., Deolasee, P., Katkar, A.,。在編寫文章時(shí)，我們正在讓 AJAX 使用功能豐富的網(wǎng)絡(luò)應(yīng)用程序，即 現(xiàn)有的 SPIAR。 AJAX 開發(fā)的領(lǐng)域是年輕，動(dòng)態(tài)和迅速變化的。為了做到這一點(diǎn)，我們的文章是建立在所提供的REST 風(fēng)格的基礎(chǔ)上，并提供了建設(shè)豐富用戶交互的 Web 應(yīng)用的目的，以及對(duì)這一風(fēng)格的進(jìn)一步分析。 在本文中，我們討論了 SPIAR，一個(gè) AJAX 的架構(gòu)風(fēng)格。換句話說(shuō)， CREST 就像 SPIAR 一樣承認(rèn)一個(gè)處理部分的 AJAX 引擎的意義。他們認(rèn)識(shí)到 AJAX引擎是作為提供的內(nèi)容來(lái)進(jìn)行 解釋環(huán)境的。 REST 的異步擴(kuò)展，稱為 A+REST，把允許服務(wù)器廣播其狀態(tài)更改為 39。 Parsons （ 2020 年）通過(guò)不斷的探索提供了一個(gè)網(wǎng)絡(luò)結(jié)構(gòu)模式現(xiàn)狀的概述。Mogul 公司等， 1997 年 。 基于組件的用戶界面模型與 SPIAR 風(fēng)格吸引了許多現(xiàn)有樣式（ Khare 和 Taylor，2020 年 。以高速緩存為基礎(chǔ)的技術(shù)試圖減少一些功能轉(zhuǎn)移到網(wǎng)絡(luò)邊緣的延遲。Brodie 等， 2020 年 。然而，白紙不評(píng)估這種推進(jìn)方式，例如可擴(kuò)展性和性能，可能的問(wèn)題。不過(guò)，大部分的工作重點(diǎn)放在客戶機(jī) /服務(wù)器的分布式系統(tǒng)和非 HTTP 的多媒體流或多用一個(gè)出版商（ Franklin和 Zdonik， 1998 年 。（ Crane 等，2020 年）提供的的 AJAX 網(wǎng)頁(yè)開發(fā)技術(shù)和深入的方法與最佳做法以及關(guān)于設(shè)計(jì)模式的詳細(xì)討論。 SPIAR 被認(rèn)為是對(duì) AJAX 的互動(dòng)作用必不可少的部分。因此寬松聯(lián)結(jié)不是包括在 SPIAR 的特性中的。我們必須進(jìn)行研究，提出 AJAX 開發(fā)人員所設(shè)計(jì)的模型，例如擴(kuò)展的 UML 建模語(yǔ)言的用戶交互 ，通過(guò)組件導(dǎo)航、異步 /同步行動(dòng)和客戶端與服務(wù)器端處理。單頁(yè)的客戶端由服務(wù)器端部件建立的。這里沒(méi)有一 個(gè)標(biāo)準(zhǔn)，這對(duì)傳遞者了解系統(tǒng)組件之間的相互作用是很困難的，因此制度本身將不再那么明顯。它也導(dǎo)致了這些應(yīng)用的可移植性水平很低。此行為可能對(duì)同步和整個(gè)應(yīng)用程序狀態(tài)有重大的影響。并且采用能適應(yīng)技術(shù)之間的作出選擇的服務(wù)器或用于加工目的的客戶需要更多的關(guān)注這方面。例如 jQuery 的歷史圖書館 /遠(yuǎn)程插件的編程登記，支持的途徑就是通過(guò)瀏覽器的歷史片段標(biāo)識(shí)符，這個(gè)狀態(tài)的變化是簡(jiǎn)單的。在 AJAX 應(yīng)用中，互動(dòng)作用越來(lái)越像桌面，最終將撤銷 /重做替換為后退 /前進(jìn)，安全的相互作用能保持進(jìn)行特定的解決，而不安全 的（ POST 請(qǐng)求）相互作用也可在這個(gè)背景下進(jìn)行。一個(gè)安全的互動(dòng)是用戶不需對(duì)結(jié)果負(fù)責(zé)，例如，簡(jiǎn)單的查詢和獲取，其中的資源狀況（在服務(wù)器上）不會(huì)更改?；诮M件級(jí)的 Delta 通信在 SPIAR 互動(dòng)方式中是不符合資源/URI 的 Web 架構(gòu)限制的。這些可擴(kuò)展性問(wèn)題繼承了 SPIAR，如表 3 所示。然而，推模型由于它的訂戶名單不太適應(yīng)斷開。然而，當(dāng)用戶數(shù)量增加的同時(shí)，接收消息的可靠性就會(huì)降低。因此，該服務(wù)器有多個(gè)連接與其配合，在事件很少發(fā)生時(shí)，它需要對(duì)每一個(gè)客戶有一個(gè)或多個(gè)線程。高級(jí)服務(wù)器負(fù)載和可擴(kuò)展性問(wèn)題主要?dú)w結(jié)于實(shí)時(shí)服務(wù)器必須維護(hù)關(guān)于客戶和對(duì)應(yīng)連接的狀態(tài)信息。低用戶認(rèn)知時(shí)延、高用戶交互性和降低服務(wù)器往返是這種配置的特點(diǎn)。這個(gè)變形提供了用戶一個(gè)高度互動(dòng)性和極低的用戶認(rèn)為延遲。 第二個(gè)配置是以客戶為中心的 AJAX。以 SPIAR 作為參照點(diǎn)，共同點(diǎn)和分歧是可以查明的。雖然在 Dojo和 Cometd 框架內(nèi)推的限制是很好的代表， 但基于組件的限制在這里是沒(méi)有的。在另一方面， GWT 也是一個(gè)有趣的架構(gòu)。 8 討論和評(píng)價(jià) 在本節(jié)中，我們通過(guò)調(diào)查如何使用現(xiàn)有的 AJAX 框架和典型的 AJAX 架構(gòu)來(lái)評(píng)估SPIAR 是否由風(fēng)格覆蓋，并在架構(gòu)性質(zhì)的屬性上討論了 AJAX 應(yīng)用設(shè)計(jì)的各種決定因素和權(quán)衡。 Comet 使我們能夠在互動(dòng)式網(wǎng)絡(luò)上模仿基于推技術(shù)的發(fā)布 /訂閱（ Eugster 等，2020 年）。基于事件的集成（ Barrett 等， 1996 年）和異步 REST（ Khare 和 Taylor， 2020年）是基于事件的異步通知方式，允許服務(wù)器狀態(tài)的變化。 不同于 REST， SPIAR 沒(méi)有明確制約狀態(tài)的性質(zhì)。 狀態(tài) 一個(gè)無(wú)狀態(tài)服務(wù)器對(duì)每個(gè)請(qǐng)求作一個(gè)獨(dú)立的交易，無(wú)關(guān)的任何以前的請(qǐng)求，即每個(gè)請(qǐng)求在服務(wù)器端必須包含所有信息并了解它，并且不能利用任何被存放的上下文(Fielding 和 Taylor， 2020 年）。例如，客戶端表單驗(yàn)證，減少了不必要的服務(wù)器端錯(cuò)誤報(bào)告和返回的消息。這個(gè)約束排除了運(yùn)行在 Web 瀏覽器中需要額外功能的辦法，（例如，插件，虛擬機(jī)），如Flash 和 Java 小程序， 并使得客戶端跨瀏覽器兼容。用戶的交互性大大提高，因?yàn)橛脩粼诮M件級(jí)基礎(chǔ)上可以和應(yīng)用程序交互，類似于桌面應(yīng)用程序。數(shù)據(jù)的連貫性也得以提高，同時(shí)可以讓用戶在使用大型網(wǎng)頁(yè)的過(guò)程中數(shù)據(jù)處理速度變得更快。 Delta 通信是基于增量編碼體系結(jié)構(gòu)的原則，但不同的是： Delta 通信不依賴于緩存，因此，客戶端只需要處理增量文件。為了減少數(shù)據(jù)冗余， Delta 編碼（ Mogul 公司等， 1997 年）使用了緩存技術(shù)以減少網(wǎng)絡(luò)流量。在這個(gè)背景下這些請(qǐng)求由客戶端處理，并根據(jù)最新的服務(wù)器響應(yīng)。這個(gè)約束導(dǎo)致用戶的交互性大大提高，因?yàn)榻换ナ腔诮M件級(jí)別的，用戶不必等待整個(gè)頁(yè)面中每一個(gè)狀態(tài)刷新的結(jié)果。一個(gè)“ +” 標(biāo)志直接的積極影響，而一個(gè)“ ”表示直接的負(fù)面影響。如果沒(méi)有這個(gè)解決方案，程序員要編寫明確的 JavaScript 函數(shù)，以便處理傳入的推動(dòng)數(shù)據(jù)?？梢岳^續(xù)不受阻礙的引進(jìn)推模塊。 這種方法可確保在服務(wù)器上的狀態(tài)與客戶端上的每個(gè)通知狀態(tài)同步。因而， SPIAR 的架構(gòu)風(fēng)格揭示了在基于 UI 組件和基于推技術(shù)之間緊張有趣的限制。如圖 4 所示。在這里，編碼器和解碼器直接與服務(wù)提供商連接，無(wú)需通過(guò)服