Mashup Interview with Jonathan Marsh

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By Jonathan Marsh
  • 17 Apr, 2007

Jonathan Marsh is the the Director of Mashup Technologies at WSO2. Jonathan has served as editor of W3C Recommendations including XInclude, XML Base, xml:id and the XPointer Framework, as well as the editor of the W3C Member Submissions WSDL 1.1 Binding Extension for SOAP 1.2 and the SOAP 1.1 Binding for MTOM 1.0. He has been involved in the development of a number of technologies such as XML 1.0, XSLT 1.0 and XPath 1.0, the XML Information Set, WS-Addressing 1.0, WSDL 2.0, and the WS-I Basic Profile.

Oxygen Tank (OT): What is a "mashup" anyway?

Jonathan: The term mashup apparently comes from musical styles where recordings from different sources are combined into a new piece. On the Web it means consuming information published from multiple sources and integrating it into a new information stream. The repurposing of information to the needs of an individual or interested community is part of the Web 2.0 trend about decentralizing power. Until recently, Web publishers had fairly complete control over how the user experienced the content. But consumers have increasingly opted for technologies that give them the power -RSS gives users the ability to publish their own content, and to consume published information in more ways than just visiting a Web page. Mashups extend this decentralization further by allowing a user to tailor information from more than one source. For example, there are many mashups today that combine information specific about an individual or group and integrates it into a visual display such as a map. Such a display is not controlled (though it may be encouraged) by the providers of the various information sources.

OT: So does a mashup necessarily include a visual component?

Jonathan: Today in practice, mostly yes. Today's mashups generally build upon a framework such as Google Maps or Yahoo Maps primarily to display aggregated information in an interesting way. Yahoo Pipes provides a model where the output, instead of an HTML display, is materialized as an RSS feed. But most mashup technologies aren't purely data oriented.

OT: How do Web Services fit in with mashups?

Jonathan: Mashups are all about consuming information from multiple sources, combining it, and exposing the combined data to consumers in visual or data form. In order to combine data, first you have to get it! Today lots of useful information is locked up in HTML pages, but more and more of that data is being exposed in a more machine-friendly format - generally in XML.

Web Services is simply a set of protocols helping to get XML from one place to another. As such they are a natural conceptual match for mashups. XML is pretty well universally accepted as the format for machine-to-machine communication on the Web, and Web Services are gaining adoption (though mainly in the Enterprise) as a way to deliver XML to the right place with the right quality of service - robust message-level security being primary among these.

Web Services also provides a way to expose the mashed-up data back onto the Web. Today's mashups pretty much terminate in the browser, but a data mashup that combined information and exposed that information back on the Web can take advantage of the descriptive capabilities of Web services to improve access to and discovery of that content.

OT:WSO2 is developing a "Web Service Mashup Server". Can you talk about how that fits in here?

Jonathan: Sure, the Web Service Mashup Server is a product we're working on that helps developers create and deploy Web Service mashups. It makes it easy to deploy a Web Service, and also to consume and combine information from other Web Services and expose the resulting mashup as a service. By attacking the problem of the complexity of deploying Web Services, we hope to significantly broaden the community creating and consuming Web Services. The goal is to move beyond Enterprise Web Services, which are centrally defined and controlled, robust, scalable, and sometimes expensive, to something I've been calling Personal Web Services - lightweight, quickly deployed, cheap. I think there are lots of tasks Web Services are well suited to solving on behalf of individual developers if they could be created and deployed in minutes rather than days. Web Service mashups are actually a subset of that larger problem - if we solve the problem of Personal Web Services, and one of these lightweight services relies on other Web services, it then becomes a "mashup".

OT:What will the developer experience be like in the Mashup Server?

Jonathan: The goal of the Mashup Server is to mimic the strengths of the Web and its successful adoption history. A Web site could be published initially (and still can be today) with no more than Notepad and a Web server. You use a fairly simple language (HTML) and simple text-editing tools, save the result in a special directory that the Web server monitors, and voila you have a web page. Similarly, to create a Personal Web Service, one works in a simple language (Javascript) and with a universal model (XML) using text-based tools (E4X is perfect here - extends Javascript with a native XML datatype), save the result in a special directory, and voila you have a new Web service. The Web Service Mashup Server is the Web Service equivalent of the Web server for HTML pages. There will also be a simple administrative UI that allows you to start and stop services, configure the bindings which define how the XML is to be framed and transmitted on the wire, and define access privileges and so forth.

OT: Is it really possible to write services in a dynamic language like Javascript? What about metadata like WSDL?

Jonathan: Metadata is really important in machine-to-machine communication, since there's no human to adapt to ambiguous responses. But one of the hardest things about deploying Web Services today is getting all your metadata right. First you have to write an XML Schema, so right there you've exceeded the capabilities of many of us Web developers. Then you have to create WSDL, maybe some WS-Policy, maybe even some BPEL or something. That's daunting enough to scare away most of the Web developers from Web Services. But the Web Service Mashup Server will be able to create and consume metadata automatically so that the average developer can focus on his code.

OT: How does this approach to mashups compare with other mashup products?

Jonathan: What's different about this from most other mashup offerings is that they are very tooling specific. Just as HTML and Notepad succeeded over infinitely more sophisticated tools such as Microsoft Word, I think there is greater potential for a clean and simple underlying model, exposed directly to the developer without intervening abstractions. Sophisticated tooling can be built upon that, but I see that as a much longer term project.

Also, today's mashups are very UI based - and generally limited in their UI to HTML. When you separate the logic of combining data from the presentation of that data, the available UI palette becomes much greater - stretching from HTML and desktop gadgets to instant messaging, SMS, email - any way a machine touches a human. That richness is going to allow some compelling applications.

Another advantage of building mashups using Web Services is the ability to migrate the mashing of data from the browser on my laptop, to a Web Service running as a service on that laptop, to a 24/7 hosting service running on the internet somewhere, make it easy to share the building blocks of sophisticated distributed applications with others, seeding the network effects which the Web has repeatedly demonstrated. That unleashing of creativity will undoubtedly lead to new ways technology can enhance our lives.