Last week IBM hosted an exploratory summit on mashups, modeled (I think) on our early brainstorming sessions that lead to the formation of the OpenAjax Alliance. Zimbra was thrilled to get the opportunity to join in and share some of our lessons learned in Ajax “mashing” the past couple of years. (As usual in these circumstances, I believe that any thoughts voiced by others are out of bounds for blogging, but feel no such reservations about our own contributions and ideas.)
Zimbra is likely as bullish about mashups as any of our high-tech brethren. In fact, while the luster of the 2.0 buzzword may (hopefully ☺) wear off over time, I will bet that mashups and collaborative authoring will remain two of the “killer” technologies to come out of Web 2.0.
One thing that became apparent during the session was that there was no strong consensus on what actually constituted a mashup. Here is a proposal:
A mash-up consists of one Web application (the consumer) whose user interface contextually displays either data/content or user interface functionality from another independent application or data source (the producer). Mashups can occur on intranets or the Internet, but necessarily leverage Web technologies – the consumer is typically an Ajax application (although other Web UI technologies like Flash/Flex could also be used), and the producer is typically another Web application or an XML data source.
Of course, the best way to understand mashups are to see them in action. Check out some of the Zimbra mashups via a Flash demo here.
Widgets also factored heavily into the discussion, although there perhaps was not yet a consensus on their role. In this context, a widget framework is software component model that makes it easier to build mashups. Zimbra’s Zimlets are one such widget framework. Zimlets are consumer-side widgets in that they are specific to the Zimbra application (e.g., they understand contacts, appointments, and drag and drop within the Zimbra UI). Indeed, the power of Zimlets comes out of how much easier they make it to mashup other applications within Zimbra: Most of the Zimbra mashups created to date were “weekend projects” specified declaratively in a simple XML template. We have an open gallery of such mashups here.
For those that may be familiar with it, the Apple Dashboard widget is similar in concept, but not designed for use within web applications. Instead, Dashboard widgets make it easier to integrate Mac (“producer”) applications into the Apple Dashboard container (the “consumer”). Google’s Gadget architecture combines aspects of both Zimlets and Apple Dashboard widgets in that both desktop (for the Google Desktop) and universal (web application) frameworks are provided. One could also envision the analog of JavaBeans emerging in our Javascript toolkits/class libraries to facilitate more general, programmatic definition of mashups. Given these disparities in use model, I do not see any particular widget architecture dominating the landscape, but rather think developers will choose widget frameworks based on what what (producer) and where (consumer) they are mashing.
Since the consumer application manages the mashup, the business/licensing questions associated with mashing tend to focus on the producer. We have seen roughly three approaches, but in all cases the producer ultimately “wants” to be mashed up:
• Proprietary/subscription – The data being mashed up is something that the enduser is already entitled to (your Salesforce CRM data or corporate data from your intranet).
• Transaction fees – Skype or SMS mashups fall into this category in that the enduser or mashup provider pays a usage fee.
• Free – Most of the Internet mashups today target producers that choose to give their content away for free (perhaps to embed their logo, or in the hopes that the user will “click” into a map to explore nearby services) and often even package it (such as within widgets) to facilitate mashing.
There is no doubt work that can be done in organizations like OpenAjax to define best (or at least better) practices for Web/Ajax UI mashups, widget/component architectures, and security (in addition to raising Ajax security issues, mashups can present single sign-on/credential management challenges).
I am much more skeptical, however, of extending the mashup concept to encompass data aggregation/transformation, service-oriented architecture (SOA), integration, and so on, as some others seem to be. There is already a substantial body of work, ranging from the WS-* web services family through to XQuery and the Semantic Web, focused on non-UI application and data integration. Frankly, trying to get data-only “mashups” right strikes me as a hard, ill-defined problem relative to making Web UI mashups easier.
Just our $.02 from the first round. More as this discussion plays out.
Comments are closed.