Model-Driven Mashup Development

Challenges for mashup development today include interoperability, reuse, and automatic service invocation and mediation. In my opinion, model-driven mashup development can provide a potential solution to these challenges.

In analogy to model-driven engineering (MDE) as used in software engineering, model-driven mashup development (MDMD) focuses on mashup specification (i.e. creating mashup models) rather than mashup implementation.

The figure above depicts how a model-driven approach to mashup development works.

1. The MDMD approach starts with a mashup modeling step, which occurs in a mashup environment neutral manner. In this crucial step, mashups are expressed as models. These models define the mashup functionality using a general purpose Mashup Modeling Language (MML). An MML would be used to describe how to call the mashup services (service invocation), what parameters are expected (service input), what parameters are needed for mediation (service mediation), and what to expect in return (service/mashup output). The result of this step are mashup models that are portable, reusable, interoperable, and user interface framework independent. I would propose the Mashup Mapping Description (MMD) as an example of an MML. MMD borrows from the Service Mapping Description (SMD) proposed by Kris Zip to describe RESTful and JSON-RPC services. MMD is a simple and lightweight JSON representation describing RESTful mashups (i.e. mashups of RESTful Web services). Here is an MMD sample that provides a model for the mashup of two popular services, namely Geonames and Google Video Search.

It's also possible to think about other mashup modeling languages that are based on other well-established service description specifications, such as WADL and WSDL 2.0 (both are XML-based and are used to describe HTTP-based services). The main advantage of MMD, as compared to a WADL or WSDL 2.0-based MML, is that it uses JSON, which offers several major advantages over XML (less verbose, easier to parse, enables client-based/in-browser mashups, and supports cross-domain Ajax via JSONP).

In order to support the mashup modeling step, mashup modeling tools (e.g. Visual Mashup Model Composer) are required to help users create mashup models in an easy and visual manner without the need to get familiar with the MML.

2. In a second step, the mashup model is translated to one or more platform/UI framework specific mashup implementations. The mashup implementation can be a mashup code using a particular declarative mashup Domain Specific Language (DSL) (e.g. EMML) or a mashup UI based on specific UI framework (e.g. HTML/JavaScript/CSS, Flash/Flex, Android).

This step should be well supported through generic tools that can process the mashup models written in MML and generate human or programmatic interfaces.

3. Once the mashup code/interface is generated and the mashup property values are assigned (in the code/interface), the mashup can then be executed inside a compliant mashup runtime that serves as a mashup demonstration environment (e.g. EMML Reference Runtime Engine, Flash Player Runtime, Android Runtime).

4. Once a mashup is created, it should be possible to provide a view of the mashup in a portable and embeddable mashup widget (aka mashlet). Mashlets are defined by JackBe as "user-oriented micro-applications ... providing the visualization, or “face”, of a mashup to be embedded in a web page". Once a fully functioning mashlet is developed, it can be published, shared, and reused anywhere. It can for instance be embedded into any HTML page, blog, wiki, portal, widget/gadget container (e.g. iGoogle, Apache Shindig), CMS/LMS, social networking platform, enterprise mashup platform, or mobile device.