Mashup patterns

May 8, 2008

For some reason I was thinking about mashups and if there were any established patterns (or anti-patterns) that have been cooked up.

I found an article from 2007 that referenced this article from 2006 (that I am now referencing in 2008) that lays out five ‘styles’ of mashups. I guess if you put a UML diagram in for each of them, then you’d have patterns. These would not be domain based patterns, but high level architectural or something like that. Now, what is a pattern again..

The 5 styles of mashups

Accepting that information, visuals, and software can be remixed and combined at multiple levels in an application stack means that there are (at least) five places that mashups can take place.  These five styles are:

  • Presentation Mashup: This is the shallowest form of mashup in the sense that underlying data and functionality don’t meet.  Information and laout is retrieved and either remix or just placed next to each other.  Many of the Ajax desktops today fall into this category and so do portals and other presentation mashup techniques.
  • Client-Side Data Mashup: A slight deeper form of mashup is the data mashup which takes information from remote Web services, feeds, or even just plain HTML and combines it with data from another source. New information that didn’t exist before can result such as when addresses are geocoded and display on a map to create a visualization that could exist without the underlying combination of data.
  • Client-Side Software Mashup: This is where code is integrated in the browser to result in a distinct new capability.  While a component model for the browser is only now being hashed out as part of Open Ajax, there is considerable potential in being able to easily wire together pieces of browser-based software into brand new functionality.
  • Server-Side Software Mashup: Recombinant software is probably easier right now on the server since Web services can more easily use other Web services and there are less security restrictions and cross domain issues.  As a result, server-side mashups like those that in turn use things like Amazon’s Mechanical Turk or any of the hundreds of open Web APIs currently available, are quite common.
  • Server-Side Data Mashup: Databases have been linking and connecting data for decades, and as such, they have relatively powerful mechanisms to join or mashup data under the covers, on the server-side.  While it’s still harder to mashup up data across databases from different vendors, products like Microsoft SQL Server increasingly make it much easier to do.  This points out that many applications we have today are early forms of mashups, despite the term.  Of course, the more interesting and newer aspects of mashups happen above this level.

First of all, I should have defined "mashup" for reference. Maybe I should have gone to mashup camp . Who knows what one is exactly, in precise terms because it is another one of those IT terms that is actually very vague.

This one from that 2007 article that I cited earlier: "A mashup is a website or application that combines content from more than one source into an integrated experience." That’s pretty good. Here’s another: "Mashups pull data from different sources, aggregate and transform the data to be used in different contexts."  One mashup vendor says that a mashup should follow 5 C’s:

  • Consume – A user must be able to consume public and private services on demand. The minimum set of consumable SOA-style services includes: WSDL, REST, RSS and Databases.
  • Create – A user must be able to create new mashups made up of consumed services and previously created mashups, preferably in a visual editor.
  • Customize – A user must be able to customize (filter, for example) existing mashups and create variants which themselves become mashups. Versioning of mashups is also preferred.
  • Collaborate – A user must be able to publish and share their mashups publicly and privately, also providing opinions/rating/comments on services and mashups to peers.
  • Confidence – All consumption, creation, customization and collaboration must occur in a secured and governed environment that delivers enterprise-grade security (i.e. integrating with single sign-on systems), reliability, and enterprise monitoring/governance systems.
  • Maybe the pattern/concept/meme "mashup" could be considered a pattern itself . And it’s really nothing new .

    Anyway, are there any identifiable design patterns for mashups (based on type of data used, public/corporate/intranet, target audience)?



    Leave a Reply

    Please log in using one of these methods to post your comment: Logo

    You are commenting using your account. Log Out /  Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )


    Connecting to %s

    %d bloggers like this: