As Web services continue to entrench themselves as the preferred mechanism to expose application functionality, the possibilities of combining such services into an even richer set of application behaviors has come to the forefront. The technique has grown to the extent of having its own name, "mashup." It brings a new series of issues to the services landscape ranging from the technical to the legal, some of which we will address in the following article.
The novelty behind what is being dubbed a mashup in today's development circles, is the data perspective created by combining different Web sources into one seamless interface. While the reality is that any application's business value stems from combining data to generate different perspectives, until the emergence of Web services this process was either very resource intensive or error prone.
Prior to the ubiquity of networks, tapping numerous data sources to create an application was limited to a handful of companies since the process implied having on-demand archives of such information. As networks became mainstream, other techniques followed to access networked data, among them were screen scraping and Web crawling, which to this day are still used successfully by many application developers.
But while some of these last approaches are still in use today, many of them are error prone for the simple fact that they are intended to extract data from what would otherwise be a human-bound format, such as HTML or an ASCII terminal. WithWeb services being designed as machine consumable applications -- that is, exposing data in language neutral format like XML -- the possibilities for integrating different data sources into more elaborate applications known as mashups has created fertile ground for web services.
The power behind a mashup application is that it can obtain fine grained data sets in an on-demand fashion due to its reliance on Web services, whereas using non-Web-services techniques -- such as Web crawling or screen scraping -- just the process of preparing and filtering data to be reused in another application is a task unto itself, something that is integral to Web services.
Still moving along the mashup power curve it's not so much the combination of Web services via server side applications like Java EE or .NET, but rather on browser-bound applications, something that is achievable in combination with another emerging technique named Ajax, asynchronous JavaScript and XML.
Not to underestimate the possibilities of combining Web services tied to server side platforms, but by designing client side applications to interact directly with Web services -- via Ajax -- you are not only leveraging the Web services and data sources maintained by third party providers without writing elaborate server side logic yourself, but you are also empowering the user to obtain on-the-fly snapshots of combined data from around the Web.
Herein lies some of the complexities of effective mashup development. Since the Web services an end user will be accessing do not belong to the same source, a serious browser security breach takes place, one known as cross-site scripting (XSS). On all but the least secure browser installations, an end user will receive an ominous message indicating he is attempting to access an untrustworthy site, so what was designed as a powerful mashup application may be perceived as an insecure page.
Default protection against XSS is done with good reason, you may be trying to deliver a creative mashup combining news and mapping data, but the same technique could be used to contact rogue services. So you are left with only one option, pipe all Web services data through a trusted source: your site.
Since a user is consensually navigating your site, this implies a level of trust, one which can be leveraged to proxy requests for third party Web services and return the results back to the browser without the user even realizing data was obtained remotely. Yet pursuing this proxy technique for mashups also comes with another security pitfall.
By having your own proxy broker requests on behalf of browser clients, you need to establish an authentication mechanism to guarantee that only authorized requests can make their way through the proxy, otherwise you risk anyone on the wider Internet making calls to third party Web services via your server. This authentication step may seem trivial, but considering the proxy is a Web service for another Web service careful consideration should be taken.
Switching gears from the technical side of mashups, we also find that this technique has brought new legal considerations into the use of Web services. With access to the exploding body of Web services ranging from maps, weather, data feeds (RSS/Atom), government statistics and many more sources, it was probably inevitable that unfettered creativity would surpass the many uses a Web service was initially conceived for right into questionable legal waters.
To date, some mashups on the Net have been either redesigned or completely shutdown due to questionable uses of Web services data, ranging from the combination of trademark infringement pertaining to a popular board game to correlating crime data which became sensitive when mixing it with another source. The possible legal consequences have touched such a nerve that many leading Web services providers have outright prohibited the mixing of data with any other source in any shape or form. So take heed either as a consumer or Web provider for mashups, as you may be violating legal terms of use or some consumers may be using your data in unexpected forms.
With this we conclude our overview of mashups, one of the latest approaches to adopt Web services technologies as its building blocks and expand the usage scenarios for XML data.
About the author
Daniel Rubio is an independent technology consultant specializing in enterprise and Web-based software, He blogs regularly on these and other software topics.
