AJax是異步JavaScript和 XML單詞的縮寫(asynchronous Javascript and XML)。正如Web服務開發者應該關於的一樣，我們最應該的關注的技術是它的異步本質，以及隨之而來的它的暗示了關於在一個語言可執行的環境的知識的JavaScript根源——命名為一個浏覽器——並且也帶來了在至少的一點來看，一旦能夠運轉之後它所產生的視覺效果(不是說我們要忽略這個最後的一點，而是圖像設計師一般的比程序員更加熟練於解決這些問題)。
異步是描述的一個客戶端和一個服務器端的交互的側面，在這種交互中客戶端不用等待服務器端——或者經常稱之為的被阻塞——來等待接受從服務器端的響應。 消息傳遞系統，如MQ-SerIEs, Tibco Rendezvous和類似於JMS的可編程API，都是比較早就采用異步機制的概念了的，但是現在AJax正在以相同的方式來解決Web應用程序的問題。
AJax 的異步概念來自於由浏覽器進行的JavaScript 函數調用，並把結果返回給Web服務提供者或者服務端的應用程序。當你和一個AJax應用程序交互的時候，那種可以更新展示在屏幕上的信息塊的而不需要刷新或者重載它的所有內容的方式就是異步的，因為你能夠在服務器端構建很多不同的調用而不需要在等待服務器響應的時候——客戶阻塞——時刻的盯著一個空白的屏幕。
盡管正式那些Web2.0的支持者包括圖像設計者和軟件市場人員最經常的使用Ajax，很多開發出來的軟件使得AJax應用程序可以作為可復用服務的集合。
奇怪的是為一個AJax應用程序提供的數據不需要由一個Web浏覽器客戶端的約束或者JavaScript語言來幫定，實際上一個最優化的AJax設計將會確定的在服務端以一種廣為所知的Web服務設計方式來幫定:REST(可以在REST: Simplicity in Web Services design 專欄看到關於REST的更多的消息。)
REST服務，是被創建來用於提供一個Internet URL 的簡單的訪問點，有效的掩蓋服務端的平台，比如你也許期望的Web service 並且由最早的Web services選擇器提供最簡單的 設計模式，如eBay、Yahoo!和 Amazon。他們本質上是提供粒度的數據塊而不是提供完全的頁面，所提供的數據塊可以按照客戶端提供的需求來消費和產生。
因為Ajax應用程序的生命周期是由從服務端調用的對屏幕特定部分進行更新的過程組成的，REST服務提供了一個創建基於Ajax的應用程序的超集。所以如果現在你有一個已經存在的REST服務群，這將會是為你的Ajax應用程序開個好頭。類似的，你將會被很好的建議，以采取必要的步驟來整合所有的你是用來讓你的Ajax應用程序變成一個更加龐大的REST服務集合那些資產，這樣做的目的是讓這些資產能夠在其他的面向服務/非AJax的應用程序中使用。
在另外一方面來說，綁定到一個浏覽器來使用你的服務，遮掩個會限制你的使用環境，所以這也會暗示著創建你的Web services客戶端。 然而很多Web services客戶端具有從其他不同的來源集中和控制數據的能力，這些上可以實現的，因為他們被由類似於Java EE, .Net或者 PHP的系統架構構建而成的。
考慮在兩個不同的Web服務提供者之間集成數據。這種情況和在一個非浏覽器環境下也許一樣簡單，可以證明會成為AJax應用程序中的一個頭疼的問題，也就是它是跨站點的腳本的原因。為了能夠努力阻止惡意代碼的執行，一個浏覽器通常是受限的，它只能在它顯示的站點上擁有的執行邏輯代碼。這防止了信任的請求在那些未被信任的站點執行，但是這個相同的處理會避免接近兩個或者更多的不同Web service提供者，除非是在一個更低的安全配置要求的浏覽器的情況下，因為這種方式在整個IT安全實踐中都被認為是一種不好的方式。
最後的，還有一個需要考慮的東西是用來構建Ajax應用程序的Javascript語言。每一個用來開發Web應用程序的編程語言都依賴於一個特定的框架，以減少開發任務的難度和適應Web的本質。大部分的這些框架都是用於服務器端的平台，而Ajax作為服務端的一個簡單的單獨REST服務集合，它並不是其他的Web架構平台提供的並不適用於AJax應用程序的功能。它是這些設計所關注的一些簡單的東西——如標准化請求或者控制類——轉移到浏覽器。在最後，關於很多JavaScript 架構方面的研究都是很值得去做的，以便開出來讓創建AJax應用程序更加容易。
AJax本質上是web開發的下一個潮流，但並不是意味著它將會被作為一個Web的新的注視點而已。正如你可能已經意識到的一樣，在關於Ajax設計你的整個面向服務的動機結合起來的考慮意味著你可以在你的時間和資源上取得一個最大的回報。所以下一次你開發主動解決AJax適用的有效性的時候，可以試著用SOA的相同的可復用性方法。