在試圖將 Asynchronous JavaScript™ and XML (Ajax) 編程技術引入到網路環境中時,常常會遇到一些困難。
簡介
Ajax 架構一個讓人興奮的特性就是能夠彙總來自多個資料來源的內容並由此建立一個全新的網站或 Web 應用程式。比方說,您可以建立這樣一個 Web 應用程式,它能綜合各種氣象服務的資訊來給出幾個滑雪場的天氣資訊。這些天氣資訊原來可以通過幾個 Web 網站得到,而您的應用程式將這些資料一同帶到了一個 Web 頁上。這類應用程式通常都被稱為 mashup。無需深入探究,只藉助 Google 或 Yahoo,就能充分領略在建立這類 Web 應用程式方面的諸多創新的可能性。
建立一個網路拓撲來支援來自多個網站的內容彙總,需要面對很多技術挑戰。這些技術挑戰包括瀏覽器的跨域限制、可能的使用者會話到期失效、持久連線逾時以及可能的身分識別驗證和授權問題。本文著眼於與 Ajax 有關的這些技術挑戰並探究了如何綜合使用 IBM WebSphere Application Server Feature Pack for Web 2.0 以及 IBM Tivoli Access Manager WebSEAL 來解決這些技術挑戰。
Ajax 拓撲
圖 1 顯示了一種典型的 Ajax 風格的架構。在左側是一個客戶機,比如一個 網頁瀏覽器。在這個例子中,瀏覽器支援 JavaScript 程式設計語言,用來處理被瀏覽頁面的 Document Object Model (DOM)。這些頁面可能會包含 JavaScript 小組件,這些小組件執行一個 GUI 函數。比方說,您可能會建立一個能從伺服器拉出資料並在瀏覽器上顯示內容的小組件。這個小組件負責 DOM 的建立和操縱,而瀏覽器則使用這個 DOM 來顯示圖形內容。
圖 1. 使用代理的 Ajax 架構
SOAP、ATOM、XML、JSON
當客戶機串連到伺服器進行資料交換時,就資料如何解釋而言總有一種約定的格式。SOAP、ATOM、XML 和 JSON 都是一些常用的格式,供伺服器和客戶機在串連時交換資訊。這些技術各有優缺點。究竟使用哪種技術取決於所開發 Web 應用程式的特定需要。Web 2.0 功能組件包在伺服器端和用戶端都提供了對這些協議的支援,有助於簡化 Web 開發。
圖 1 的中心是一個前向代理。若想彙總來自多個 Web 服務的內容或需要在串連到網路的那些客戶機上強制施行一種安全機制,那麼代理對於 Ajax 架構而言就愈發重要。比方說,Ajax 極大地依賴於 XMLHTTPRequests 在後台發出網路連接以便檢索資料。按照設計,現代的瀏覽器不允許 XMLHTTPRequests 到達所記錄的起源之外的那些域。比如,如果您建立的 JavaScript GUI 小組件源自 http://www.mysite.com,但隨後向 http://www.mydata.com/data 發出一個 XMLHTTPRequest 來拉出資料,該請求就會被瀏覽器阻塞。與之相反,客戶機會串連到充當中介的代理,並將客戶機的請求安排到其他的域。從客戶機的角度看,請求像是源自於與原始文檔相同的域。除了處理瀏覽器自己的安全模型之外,代理還可以提供額外的一層身分識別驗證和授權以便充當訪問網路上的文檔或服務的一個控制點。
圖 1 的右側是基於瀏覽器的客戶機可能試圖訪問的各種服務或文檔端點。在 Ajax 架構中,這些服務端點可能會訪問一個資料庫、Enterprise Service Bus 或其他後端服務來拉出資訊,所返回的這些資訊的格式要對用戶端點可用。典型的例子包括 SOAP、ATOM、XML 或 JSON。