网络中的Ajax:在Ajax架构中聚合来自多个站点的内容所面临的安全性和拓扑问题

网络中的Ajax:在Ajax架构中聚合来自多个站点的内容所面临的安全性和拓扑问题2011-01-11 IBM Kevin Haverlock在试图将 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 风格的架构。在左侧是一个客户机，比如一个 Web 浏览器。在这个例子中，浏览器支持 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。