|
Written by Webmaster
|
|
Wednesday, 19 July 2006 |
Christine Herron provides a good summation of the twenty or more mashup entries that competed head-to-head in the speed geeking contest at Mashup Camp 2 (MC2). As a campster myself, I was happy to see my favorite mashup take first place honors based on the most Wooden Nickel votes. WeatherBonk won the speed geeking contest yet the spectrum of votes on the various entries raised a major issue about this new technology domain being referred to as "mashups".
Specifically, what is considered a mashup? While we seem to all agree with the Wikipedia definition, it becomes difficult to articulate why one mashup is better than another if we do not have a common understanding of the characteristics of a mashup. Furthermore, it becomes even more difficult to describe to a customer the scope of this new technology domain and why it is so unique if our examples tend to be instances of a very broad interpretation of the definition.
Christine suggests that her favorite mashup, which was created by David Neilsen of StrikeIron, offered a systems-level view of mashups. She states that StrikeIron has considered the needs and desires of both developers and data providers within the emerging mashup ecosystem. As she describes, StikeIron leverage Microsoft Excel as a container for assembling their reverse phone lookup application. This assembly container, or mashup maker (a.k.a: Excel) used WSDL wizards to integrate StikeIron phone validation services with spreadsheet cells to create an ad-hoc application.
Conversely, WeatherBonk was written using a Java-based mashup maker framework. The developer was able to leverage this framework to then create GolfBonk and SkiBonk. This Bonk suite of ad-hoc applications serve a specific need for a specific community interest (weather, golfers, and skiers, respectively). These applications leveraged a common runtime environment that simplified the programmers task of assembling the application. It will be interesting to see if this Java-based framework will be contributed to the open source community or if it will be a fee-based mashup maker for Java programmers.
Not mentioned in Christine's report was the demonstration of QEDWiki,
a PHP-based Enterprise Mashup Maker, at MC2. The same questions hold true for IBM. Will they open source QEDWiki or create a new product for sale.
One of my observations at MC2 was that many of the contest solutions fell into one of four categories: New application utility that integrates disparate data sources with an interactive user interface (for example StrikeIron Phone Validation Workbook and WeatherBonk) New data service that represents a composite of two or more disparate services (for example TrainCheck) Content filters and feed generators (411Sync, Open Directory) Various Software Products that integrate external data (for example MindJet, ElephantDrive)
The Wikipedia definition for mashup states that "a mashup is a website (URL) or web application that uses content from more than one source to create a completely new service". While I would prefer our Wikiedia definition to replace the word "service" with "utility" or "application", the fact remains that both Christine's preference and the contest winner represented entries that better exemplified the notion that a mashup was an interactive application that yielded a new application utility.
I realize that many participants in MC2 were either developers or service API vendors.
As such the focus of these communities were clearly focused on an important aspect of the mashup ecosystem, namely service interfaces. Yet the shear act of joining two or more
data services into a new web service (feed, api, etc) does not make a mashup (IMHO).
Such an action is important but I would argue that such new content services are better described as composite web services then they are mashups.
So what can we derive from the preferred mashup contest entries to help describe our notion of a mashup? By reviewing the Bonk suite, StrikeIron's Workbook, RealEstateFU, ChuckLove and a few other entries we can conclude that these mashup examples: are new applications that leverage disparate data services address ad-hoc situational needs for an individual or small community are informal solutions with the focus on functionality not on productization are just good enough for the problem domain may only be pertinent for a short term need
|
|
Last Updated ( Wednesday, 19 July 2006 )
|
Commentary 
