文章作者：Brent Ashley (
brent@ashleyit.com), President, Ashley IT Services, Inc.
Current Web browsers weren't designed to easily and securely get content from multiple sources into one page. Discover how developers have stretched the available tools to fit the task and how doing so has put strain on the resulting applications with respect to security and scalability. Also, learn about several browser improvements being proposed to remedy the situation and how to become part of the conversation that will bring Web development beyond this hurdle to a new level of interoperability.
Mashing it up with Ajax
A mashup is a Web application that integrates content from more than one source and delivers it for presentation in a single page. The server makes requests to each content source, parses the information it receives, and combines the results into a page to send to the browser, as Figure 1 shows.
An Asynchronous JavaScript + XML (Ajax) application allows a Web page to get content from the server and update itself in place asynchronously using JavaScript™ code, as shown in Figure 2. In this way, users can interact with a rich user interface (UI) without reloading the full page. The server sends an initial page to the browser, which makes calls back to the server for updated content. The asynchronous JavaScript code calls frequently use XML to encode the data; however, other data formats are common, such as JavaScript Object Notation (JSON), HTML, and delimited text.
An Ajax mashup is a hybrid Web application. It uses Ajax techniques to present a rich UI that updates itself in place using content that it retrieves asynchronously from multiple sources. The server sends an initial page to the browser, which then makes calls to retrieve updated content. These calls can be made directly to the third-party sources from the browser or back to the originating server, which acts as a proxy for the third-party content.
Round pegs, square holes
When the elements comprising the current browser environments were designed, Ajax mashups were not on anybody's radar. Nothing was built into the browsers, into the Hypertext Transfer Protocol (HTTP), or into HTML or XHTML that was specifically designed to accommodate the browser's asynchronous retrieval of content from multiple sources in a secure and robust manner. Some features in the World Wide Web Consortium (W3C) HTTP specifications that might have been used for mashups, such as Document Object Model (DOM) Level 3 Load and Save Specification, were either not fully implemented or not implemented at all by a majority of browsers.
Dynamic HTML (DHTML) was not initially used in combination with dynamically retrieved content. Both the presentation and data elements of a dynamic Web page were delivered together along with scripts to manipulate them. The scripts would display, hide, move, create, and destroy document objects to create dynamic effects, but any time more data was needed from the server, the page would be replaced with a new one. Data flow was synchronous with page reload.
Consequently, developers who wished to build the kind of hybrid Web application that we now call a mashup had to take the available technology and find ways to stretch it to fit their needs. Two approaches were taken to allow the browser to retrieve content without reloading the page: embedding an external transport mechanism and using browser-native objects to perform transport duties.
Outside help
An early solution was Microsoft's Remote Scripting, which used a Java™ applet that exchanged XML-formatted messages with server-side components. This approach quickly became unwieldy because of vendor squabbles as well as Java Virtual Machine (JVM) and security model differences.
Microsoft later built the XMLHttpRequest (XHR) object, whose designers had the expectation that it would be used only with Microsoft
