Mashup design patterns
<warning: the following post meanders, is unstrucutured and doesn't arrive at any conclusion>
In the middle of last year, I invited Dion to meet with me and other members of Microsoft's Data Programmability team to discuss REST in the context of data access over the web. Dion's perspective is one of the reasons our team was able to recognise the potential of a RESTful programming model against relational data, manifested today as Project Astoria.
I've been waiting to read Dion's thoughts on Project Astoria (via John Musser). It's an interesting take, contextualizing Astoria within the overall architectural trends we're seeing take place.
I liked this diagram and got me thinking (dangerous...):
Dion warns that the diagram like this could never be complete representation of the concepts discussed in his post and is work in progress. The mapping done here for the 3 types of applications (Composite Applications, Recombinant Software and Mashups) makes some sense to me. However, it reminds me that I have used the terms "Composite applications" and "Mashups" interchangeably (but never Recombinant Software) depending on who I'm speaking to and without really thinking through what I mean by these terms. To try and clarify my own thinking on this, here's my effort to do so...
Here are the Wikipedia definitions of Composite Applications, Recombinant Software and Mashups.
"the term composite application expresses a perspective of software engineering that defines an application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems)."
"A mashup is a website or application that combines content from more than one source into an integrated experience."
So nothing in Wikipedia for "Recombinant software", but in searching for a definition I did come another post by Dion written in June 2006 - "Is IBM making enterprise mashups respectable?". Here Dion asserted:
"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."
Dion then went on to define 5 mashup types:
- 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.
Back to the plot...
When speaking with an "enterprisey" architect I use the term "Composite applications". "Enterprisey" architects think and talk in terms of governance, security, scale and complexity. They also like to hear and use technical sounding terms that confound non-IT folks ;-)
When speaking with a developer, I tend to use the term "Mashups". Developers are smart and lazy - they want to write fewer lines of code, do more with less and love to impress. In my mind at least, the term "mashup" implies a speedy development / test / deploy cycle, design flexibility and simplicity in the sense that its "less hard to do".
Now, if I'm talking to a developer who works in the enterprise context (enterprise as in a large business) the term "enterprise mashup" can connect the "enterprisey" values - governance, security, scale but without the complexity AND with the "mashup" values - speed, flexibility and simplicity.
Reviewing the 5 mashup design patterns above, there is reasonably defined line: Client-side vs. Server-side. Some of the fall into the WOA space - referring to Dion's diagram above:
"Another important item: The bottom of the overlapping circle contains a cryptic acronym near the edge of the circle: WOA. This stands for Web-Oriented Architecture, a concept that I’ve written about several times here and here in this blog. It’s an idea that basically states that software that goes naturally with the “grain” of the Web, extending the core infrastructure of the Web in natural ways, works the best."