This chapter is from the book
This chapter is from the book
This chapter is from the book
Types of Mashups
Mashups have several different colloquial interpretations, which has resulted in some confusion regarding the term and its use. The word originated in the music industry, where a mashup was a combination of two or more songs to create a new experience. Typically, the vocal track of one song was combined with the instrumental background of another in this process.
The technology industry extended this definition to encompass a new application genus that described the combination of two or more sources into an integrated site. This technique of development hybridization can be roughly split into two separate categories: consumer mashups and enterprise mashups.
Consumer mashups are generally associated with Web 2.0. They require a lesser amount of programming expertise because they rely on public Web sites that expose well-defined APIs and feeds (see Figure 1.4).
)
Figure 1.4 A small number of sites with public APIs account for the majority of consumer-created mashups.
Source: http://www.programmableweb.com/apis
The output is usually created by one of the sites participating in the mashup. In the classic "show craigslist listings on a Google map,"13 the API of Google Maps is used to plot and present the feed obtained from craigslist.com. The limitation of this approach was that resources had to be "mashup ready."
Enterprise 2.0 mashups (sometimes referred to as data mashups) are more complex. Depending on which solution a firm deploys, enterprise mashups can emerge in several ways:
- Mashups are used solely by IT to rapidly deliver products. Application developers use both internal and external sources to create data mashups and employ traditional coding techniques to create the user interface around them. Users aren't directly involved in the construction process but they benefit from IT's ability to provide solutions more quickly.
- IT creates a set of "mashable" components and gives end users a sand-box environment where they can freely mix and match the pieces together themselves. If users need new components, they have to solicit IT help to create them.
- An organization deploys an environment that lets anyone create and combine his or her own mashups. This approach is the most difficult implementation to manage, but probably has the greatest impact. To understand the challenge of this approach, consider the use of Microsoft Excel in many firms. Users can create spreadsheet-based applications and pass them around without any central oversight of what exists, how it is used, or if it was tested. This friction-free creation and distribution model spreads good solutions as quickly as bad ones.
Whether mashups are used by IT, business associates, or both, their agile nature makes them a key enabler of Enterprise 2.0. Unfortunately, they are not without potential downsides. In an attempt to "deconstruct" the success of Google, the Harvard Business Review points out several pitfalls14 that can hinder success in a culture of open development:
- As people spend more time experimenting, productivity in other areas can suffer.
- Poor coordination across groups can lead to duplication of efforts and repeated mistakes.
- A constant stream of new products may confuse the organization and its employees.
Despite these potential hazards, the authors indirectly identify the virtuous circle of Enterprise 2.0 (Figure 1.5). As diverse products are combined to create useful new resources, they themselves become fodder for the next generation of useful products. In principle, this process isn't very different from the longstanding goal of reusability that firms have strived for in their applications and architecture. Three important differences arise this time around, however:
- In the age of mashups "reuse" is no longer an ivory-tower concept restricted to the purview of application architects. Because end users and developers alike will be creating solutions, everyone will engage in the practice of reuse.
- The existing approach to reuse front-loads development efforts with additional planning and coding to create open APIs and extra documentation that may never be used. Because mashups impose reusability "after the fact," their creators will build their own APIs and include only the minimum functionality needed.
- Traditional reuse practices don't require that a system that leverages existing code or libraries is itself reusable. This leads to implementations that are essentially "dead ends." Mashups are implicitly reusable, which creates a never-ending cycle of potential associations and recombination.
)
Figure 1.5 The virtuous circle of mashups
The Structure of HTML
Consider the following simple Web form:
)
This is the underlying HTML:
<form method="POST">
<table border="0" width="250">
<tr>
<td width="85">User Name</td>
<td><input id="user1" type="text" name="user_field" size="20"></td>
</tr>
<tr>
<td width="85">Password</td>
<td><input id="pw" type="password" name="password_field" size="20"></td>
</tr>
</table>
<input type="submit" value="Logon" name="B1">
</form>
When parsed by a browser, this HTML is internally organized into a hierarchical structure known as the Document Object Model (DOM). The DOM is more conducive to automated analysis than the presentation users receive.
)
Beyond their original intent within HTML, id and class attributes can also serve as "markers" for general-purpose processing by other applications/agents (e.g., mashups). Unlike the screen scrapers of the past that relied solely on positional information to parse screen content, mashups are able to examine the underlying attributes used to build the presentation. Although not a foolproof approach, this data changes much less frequently than the look and feel of a site, as demonstrated in the sidebar "Presentation Changes Don't Break Object Discovery." While consumer mashup builders queue up and wait for content providers to expose an API, enterprise teams are using Web harvesting to grab whatever data they want.
Presentation Changes Don't Break Object Discovery
This example shows a sample Web page before and after a radical redesign. Although a visitor might be disoriented by the drastic changes, similarities in the underlying HTML (and resulting DOM tree) will not slow down a mashup that examines the site.
Before
)
As part of a larger system, a mashup is created to sign in to a Web site by supplying a "Sign On ID" and a "Password." The form attributes and DOM information are displayed following the screenshot.
... <td width="74" height="25"><div class="fixedfont">Sign On ID: </div></td> <td width="89" height="25"> <p align="right"><input maxlength="20" name="username" size="10" style="font-family: courier"></p></td></tr> <p align="center"> <tr> <td width="74" height="5"><div class="fixedfont"> </div></td> <td width="89" height="5"><div class="fixedfont"> </div></td></tr> <tr> <td width="74" height="25"><div class="fixedfont">Password:</div></td></p> <td width="89" height="25"> <p align="right"><input maxlength="20" name="password" size="10" style="font-family: courier" type="password"></p></td></tr> <tr> ...
After
)
Even though the site has been radically redesigned, it still contains form elements for "Sign On ID" and "Password." A peek at the underlying HTML and DOM shows that these fields retain the same attributes. A mashup most likely will not have a problem recognizing the new design, even though a human might take some time to become accustomed to the new interface.
... <tr> <td width="70" class="text_boxsubtitle">Sign-On ID:</td> <td><input type="text" maxLength="20" name="username" size="10" style='width:122px;FONT-FAMILY: Courier'/></td> </tr> <tr> <td width="70" class="text_boxsubtitle">Password:</td> <td><input maxLength="20" name="password" size="10" type="password" style="width:122px;FONT-FAMILY: Courier"/></td> </tr> ...
Enterprise mashups are not restricted to skimming content from HTML: They can leverage more structured formats such as XML (RSS, ATOM), Web Services, or even binary formats such as Excel and PDF (as shown in Figure 1.6). Nevertheless, the great promise of enterprise mashups derives from their ability to treat the entire World Wide Web as a first-class data source.
)
Figure 1.6 Enterprise mashups can consume a variety of different data sources.