First published by IBM developerWorks at http://www.ibm.com/developerWorks. Visit ibm.com/ developerWorks for more tutorials on open standard technologies, IBM products, and more.

• The API/content providers. These are the (sometimes unwitting) providers of the content
  being mashed. In the ChicagoCrime.org mashup example, the providers are Google and the
  Chicago Police Department. To facilitate data retrieval, providers often expose their content
  through Web-protocols such as REST, Web Services, and RSS/Atom (described below).
  However, many interesting potential data-sources do not (yet) conveniently expose APIs.
  Mashups that extract content from sites like Wikipedia, TV Guide, and virtually all government
  and public domain Web sites do so by a technique known as screen scraping. In this context,
  screen scraping connotes the process by which a tool attempts to extract information from
  the content provider by attempting to parse the provider’s Web pages, which were originally
  intended for human consumption.
  
• The mashup site. This is where the mashup is hosted. Interestingly enough, just because this
  is where the mashup logic resides, it is not necessarily where it is executed. On one hand,
  mashups can be implemented similarly to traditional Web applications using server-side dynamic content generation technologies like Java servlets, CGI, PHP or ASP.

Alternatively, mashed content can be generated directly within the client’s browser through
client-side scripting (that is, JavaScript) or applets. This client-side logic is often the combination of code directly embedded in the mashup’s Web pages as well as scripting API libraries or applets (furnished by the content providers) referenced by these Web pages. Mashups using this approach can be termed rich internet applications (RIAs), meaning that they are very oriented towards the interactive user-experience. (Rich internet applications are one hallmark of what’s now being termed “Web 2.0”, the next generation of services available on the World Wide Web.) The benefits of client-side mashing include less overhead on behalf of the mashup server (data can be retrieved directly from the content provider) and a more seamless userexperience (pages can request updates for portions of their content without having to refresh the entire page). The Google Maps API is intended for access through browser-side JavaScript, and is an example of client-side technology.

Often mashups use a combination of both server and client-side logic to achieve their data
aggregation. Many mashup applications use data that is supplied directly to them by their
user base, making (at least) one of the data sets local. Additionally, performing complex
queries on multiple-sourced data (such as “Show me the average purchase price for real
estate bought by actors who have co-starred in movies with Kevin Bacon”) requires computation that would be infeasible to perform within the client’s Web browser.

• The client’s Web browser. This is where the application is rendered graphically and where user interaction takes place. As described above, mashups often use client-side logic to assemble and compose the mashed content.

Ajax

There is some dispute over whether the term Ajax is an acronym or not (some would have it represent “Asynchronous JavaScript + XML”). Regardless, Ajax is a Web application model rather than a specific technology. It comprises several technologies focused around the asynchronous loading and presentation of content:

• XHTML and CSS for style presentation
• The Document Object Model (DOM) API exposed by the browser for dynamic display and interaction
• Asynchronous data exchange, typically of XML data
• Browser-side scripting, primarily JavaScript