See the Complete Report with images at:
http://research.sun.com/techrep/2009/smli_tr-2009-181.pdf
TECHNICAL REPORT
Mashware: The Future of Web Applications
Antero Taivalsaari
> Sun Microsystems Laboratories
Mashware: The Future of Web Applications
Antero Taivalsaari
SMLI TR-2009-181 February 2009
Abstract:
The massive popularity of the World Wide Web is turning the web browser from a document ﾭtop-style web applications. Web applications require no installation or manual upgrades, and ﾭbly powerful, and will dramatically change the way people develop and use software, allowing worldwide application development and instant deployment without middlemen or distributors.
In this paper we present our vision for the future of web applications. A key observation in the paper is that web applications do not have to live by the same constraints that characterized the evolution of conventional desktop applications.The ability to instantly publish software worldwide, and the ability to dynamically combine code and content available from countless web sites and developers all over the planet will open up entirely new possibilities for software development. We believe that this will lead to a new software development approach that can be referred to as mashware, or software as a mashup. In this paper we provide an introduction to mashware, analyze the emerging mashup development technologies, as well as discuss the technical challenges and obstacles that still remain.
Sun Labs 16 Network Circle email address: Menlo Park, CA 94025 antero taivalsaari@sun.com
© 2009 Sun, Sun Microsystems, the Sun logo, Java, Java ME, Java SE, JavaScript, Java Platform, and Sun Labs Lively Kernel are trademarks or registered trademarks of Sun Microsystems, Inc. or its subsidiaries in the United States and other countries.
All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. UNIX is a registered trade¬mark in the United States and other countries, exclusively licensed through X/Open Company, Ltd.
Unlimited copying without fee is permitted provided that the copies are not made nor distributed for direct commercial advantage, and credit to the source is given. Otherwise, no part of this work covered by copyright hereon may be reproduced in any form or by any means graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an information retrieval system, without the prior written permission of the copyright owner.
For information regarding the SML Technical Report Series, contact Jeanie Treichel, Editor-in-Chief <jeanie.treichel@sun.com>. All technical reports are available online on our website, http://research.sun.com/techrep/.
Mashware: The Future of Web Applications
Antero Taivalsaari
antero.taivalsaari@sun.com
Sun Microsystems Laboratories P.O. Box 553 (TUT) FI-33101 Tampere, Finland
1. Paradigm Shift
The software industry is currently experiencing a major disruption. In the past few years, the World Wide Web has become the de facto deployment environment for new software systems and applications. Software applications that were previously targeted to specific operating systems, CPU architectures or devices, are now written for the Web, to be used from web browsers from all over the world. A typical example of this trend is iExpense, Sun’s new web-based expense reporting application that is now used by Sun’s employees worldwide. Outside Sun, there are numerous examples such as Google Docs, Desktoptwo.com, Microsoft Live Mesh, NetSuite.com, Salesforce.com, Webex.com, or various web-based e-mail and instant messaging clients. The recent release of Google’s Chrome web browser (http://www.google.com/chrome) – specifically designed to enable the efficient execution of web applications in the web browser – also confirms this trend.
Web applications have major benefits. In particular, they require no installation or manual upgrades, and they can be deployed and shared instantly worldwide, with no middlemen or distributors. This instant worldwide deployment aspect is extremely powerful and will dramatically change the way people develop, deploy and use software. Ultimately, it will cause a paradigm shift in the software industry – in the same fashion as the Web has already transformed the sharing and distribution of documents, books, photos, music, videos and so many other artifacts. Ordinary computer users will eventually run the majority of software from the Web, instead of using conventional, binary, desktop-bound applications. The long-term implications of this paradigm shift will be at least as significant as the dramatic transformations that are currently taking place in the entertainment and publishing industries.
2. Evolution of the World Wide Web – from Web Pages to Web Applications
The World Wide Web has undergone a number of evolutionary phases. Initially, web pages were simple textual documents with limited user interaction capabilities based on hyperlinks. Soon, graphics support and form-based data entry were added. Gradually, with the introduction of DHTML – the combination of HTML, Cascading Style Sheets (CSS), the JavaScript™ scripting language, and the Document Object Model (DOM) – it became possible to create increasingly interactive web pages with built-in support for advanced graphics and animation. Numerous plug-in components – such as Flash, RealPlayer and Shockwave – were then introduced to make it possible to build web pages with visually rich, interactive multimedia content.
At the high level, the evolution of web pages can be presented in three phases or generations, as illustrated in Figure 1:
1) Simple, “classic” web pages with text and static images only
2) Animated multimedia pages with plug-ins
3) Rich Internet Applications
In the first phase, web pages were truly pages, i.e., page-structured documents that contained primarily text with some interspersed static images, without animation or any interactive content. Navigation between pages was based simply on hyperlinks, and a new web page was loaded from the web server each time the user clicked on a link. There was no need for asynchronous network communication or any more advanced communication protocols between the browser and the web server. Some pages were presented as forms, with simple textual fields and the possibility to use basic widgets such as buttons, radio buttons or pull-down menus. These types of web pages and forms are still very common, characterized by visually simple web sites such as the main page of the Google search engine (http://www.google.com/).
Figure 1: Evolution of web usage
In the second phase, web pages became increasingly interactive, with animated graphics and plug-in components that allowed richer content to be displayed. This phase coincided with the commercial takeoff of the Web, when companies realized that they could create commercially valuable web sites by displaying advertisements or by selling merchandise or services over the Web. Navigation was no longer based solely on hyperlinks, and communication between the browser and the server became increasingly complicated. The JavaScript scripting language, introduced in Netscape Navigator version 2.0B in December 1995, made it possible to build animated, interactive content more easily. The use of plug-in components such as Flash, QuickTime, RealPlayer and Shockwave spread rapidly, allowing
advanced animations, movie clips and audio tracks to be inserted in web pages. In this phase, the Web started moving in directions that were unforeseen by its designers, with web sites behaving more like multimedia presentations rather than conventional pages. Content cross-linking and advertisements became commonplace. Web sites such as Yahoo (http://www.yahoo.com/) or YouTube (http://www.youtube.com/) are good examples of the second phase in web evolution. Car manufacturers such as Cadillac (http://www.cadillac.com/) or Toyota (http://www.toyota.com/) also utilize such technologies to create highly visual, multimedia-rich vehicle presentations on the Web.
In the past few years, we have been in the middle of another major evolutionary step towards desktop-style web applications, also known as Rich Internet Applications (RIAs) or simply as web applications. The technologies intended for the creation of such applications are also often referred to collectively as “Web 2.0” technologies. Web 2.0 is mostly a marketing term, surrounded by a lot of hype, but the underlying trends are dramatically changing the way people will perceive and use the Web and software more generally.
In short, Web 2.0 technologies combine two important characteristics or features: collaboration and interaction. By collaboration, we refer to the “social” aspects that allow a vast number of people to collaborate and share the same services, applications and data over the Web. However, an equally important, but publicly less noted aspect of Web 2.0 technologies is interaction. Web 2.0 technologies make it possible to build web sites that behave much like desktop applications, for example, by allowing web pages to be updated one user interface element at a time, rather than requiring the entire page to be updated each time something changes. Web 2.0 systems often eschew link-based navigation and utilize direct manipulation techniques familiar from desktop-style applications instead. Perhaps the best known example of such a system today is Google Docs (http://docs.google.com) – a web-based office productivity suite that provides support for desktop-style word processing and spreadsheet use over the Web.
Note that the three phases discussed above are not mutually exclusive. Rather, web pages representing all three phases coexist on the Web today. The majority of commercial web pages today represent the second phase. However, the trend towards web applications is becoming increasingly clear, with new web application development technologies and systems being introduced frequently.
3. Beyond Rich Internet Applications: Software as a Mashup
What does the future of web-based software look like beyond Rich Internet Applications? So far, the trend toward RIA has revolved primarily around making the Web a better place for desktop-style applications such as word processors, spreadsheets, e-mail or instant messenger applications.
However, an important realization is that web applications do not have to live by the same constraints that characterized the evolution of conventional desktop software. The ability to instantly publish software worldwide, and the ability to dynamically combine code and content available from numerous web sites and developers all around the planet will open up entirely new possibilities for software development. We believe that this will lead to a new software development approach that can be referred to as mashware, or software as a mashup.
Mashups. The trend toward mashups is already visible in other domains. In web terminology, a mashup is a web site that combines (“mashes up”) content from more than one source (from multiple web sites) into an integrated experience. Mashups are content aggregates that leverage the power of the Web to support worldwide sharing of content that conventionally would not have been easily accessible or reusable in different contexts or from different locations. Typical examples of mashups are web sites that combine photographs or maps taken from one site with other data that is overlaid on top of the map or photo. Some of the archetypical mashups are listed below:
Chicago Police Department crime statistics mashup (http://chicago.everyblock.com/crime/). This site displays Chicago area crime statistics in various formats based on ZIP codes, dates, type of crime, etc.
Parking availability mashups (e.g., http://www.parkingcarma.com/). This service displays the availability of parking spaces in various U.S. cities visually, and allows pre-reservation of parking spaces.
Traffic tracking and congestion mashups (e.g., http://dartmaps.mackers.com/). Traffic tracking and congestion services are available for various cities throughout the world already. The web site mentioned above displays the location of commuter trains in the city of Dublin, Ireland.
Real estate sales and rental mashups (e.g., http://www.housingmaps.com/). These mashups display houses or apartments for sale or rental, or provide information about recent real estate sales.
Figure 2 contains an illustration of a typical mashup in action. The map in Figure 2 shows an interactive, real-time display of locations of suburban commuter trains in the city of Dublin, Ireland. The mashup runs in a web browser, and is built around Google’s map service.
Figure 2: Dartmaps – a web mashup displaying the locations of commuter trains in Dublin
Mashups are by no means limited to maps or photos with overlays. In principle, the content can be anything as long as it can be meaningfully combined with other information available on the Web, e.g., price comparison information combined with product specifications, latest product news and user reviews or blogs. The key aspect is that the content must be available in a format that can be reused easily in other contexts. Textual representations such as HTML, XML, CSV (Comma-Separated Value format) or JavaScript source code, and standardized image and video formats such as GIF, JPEG, PNG and MPEG-4 play a crucial role in enabling the reuse of content in different contexts.
Software as a Mashup. When applied to software development, mashups give rise to a new way of developing software that can be referred to as mashware: software as a mashup. By mashware, we refer to a form of mashup development in which web applications can be composed by dynamically combining code originating from web sites from all over the world. For instance, the user interface widgets of an application might be downloaded from one site, storage features from another site, the localization capabilities from a third site, and so on, based on the availability of best components for each purpose. The code is combined dynamically in the client, i.e., in the web browser executing the code. The general idea is depicted in Figure 3.
Web Browser
Figure 3: Mashware – software as a mashup
In Figure 3, it is assumed that the developer is building a new web application to visualize stock market information. The application consists of a main application – downloaded from the developer’s own web server – that will dynamically download the other necessary components from other web sites. These components include: (1) the widget library used for presenting the user interface of the application, (2) stock graph visualization library for creating stock graphs, (3) stock quote / market data service interface available from a third site, and (4) localization (L10N) components for customizing the market data and the language for a specific country. All these components are downloaded to the browser from different web servers/sites and used dynamically without any static linking or pre¬processing.
In general, our ideal client-side web application architecture would support highly interactive, visually rich desktop-style applications that utilize the computing power available on the client and in the web browser. The applications would be built out of pre-existing components that can be loaded dynamically from anywhere on the Web on an on-demand basis. The components would be published with well-defined interfaces, i.e., each site would publish a well-defined “contract” to the outside world, and the components would be delivered in a platform-independent format that does not require any static linking or advance binding (e.g., in source code format or in some portable intermediate format). Application execution would take place in the web browser (preferably without any plug-in components), enhanced with a security model that allows application components to be downloaded from anywhere on the Web. Application communication with the web server would take place asynchronously, using asynchronous HTTP(S), without blocking the user interface. No installation or manual upgrades would be required, since the applications and all the necessary components would be loaded dynamically from the Web.
This kind of an environment would make it possible for software developers to collaborate on an immensely large scale, allowing unparalleled sharing and reuse of software, data, layout and visualization information, or any other content across the planet. Applications would be truly web applications, consisting of components that are loaded dynamically from those web sites that provide the most applicable components for each purpose. If such massive-scale reuse were possible, the productivity of software development could potentially be improved dramatically. The Web could be the enabling factor that would finally make large-scale software reuse a reality rather than just a perpetual dream.
4. Mashware vs. Cloud Computing
“Cloudware: Software that runs in or comes from the network.”
– TechEncyclopedia (http://www.techweb.com/encyclopedia/)
Software that runs in the network or is downloaded dynamically from the network is generally referred to as cloudware. The broader term that is used commonly is cloud computing. Cloud computing refers to running applications within a network server or downloading the software from the network each time it is used. Cloud computing implies “thin client” computing, in which the majority of processing is performed on the server. For example, Google Apps (http://www.google.com/apps) and Salesforce.com (http://www.salesforce.com/) provide common business applications online that are accessed from a Web browser, but in which the majority of data is located and processing is performed on the web server.
The mashware concept differs from the cloud computing vision in some important ways. First, the client is much “fatter” than in pure cloud computing. In mashware, the majority of computation – including the mashing up of the dynamically downloaded content – will take place on the client, utilizing the computing power available in the client computer or device. This is in contrast with cloud computing, in which the assumption is that the majority of computation-intensive processing will occur on the server.
Second, in mashware the client platform will offer rich libraries much like those libraries that were available to the developers of conventional desktop applications. In this sense, the mashware concept is
a logical follow-up to the current trend towards Rich Internet Applications. However, the actual mashware applications will be rather different from conventional, desktop-centric Rich Internet Applications, since mashware applications extensively leverage the possibility to dynamically combine code and content from various web sites and developers.
A third important difference between mashware and cloud computing is that mashware applications are not necessarily bound only to a single web server at a time. Rather, the mashware applications running in the web browser may communicate with a number of different web servers simultaneously. For security reasons, today’s web browsers do not usually allow this kind of behavior yet.
The common aspect between mashware and cloud computing (and Rich Internet Applications) is that software is downloaded dynamically from the network by “pulling pieces out of the sky” (hence the reference to the “cloud”). The software is accessed on demand and used with a minimal amount of static linking and advance compilation. In many cases the software is delivered simply in source code form, and executed using a dynamic language such as JavaScript.
Mashware ≈ Rich Cloud Computing
In summary, given the characteristics summarized above, mashware could also be referred to as Rich Cloud Computing – it is a more client-oriented form of cloud computing in which the computing power and other capabilities of client devices are utilized more extensively. Given how much computing power is available in today’s personal computers, mobile phones and other client devices, it seems rational to harness the available power also when building applications that rely extensively on components delivered over the Web.
5. The Importance of Dynamic Languages and JavaScript
“You cannot build mashups out of concrete bricks.”
As summarized by Paulson in the paper “Developers Shift To Dynamic Languages” [Pau07], there is a trend toward dynamic programming languages in the software industry today. The attention that dynamic languages are receiving is remarkable, and is something that has not occurred since the early days of personal computers and the widespread use of the BASIC programming language in the late 1970s and early 1980s. The comeback of dynamic languages is largely due to the shorter lifecycles of applications and generally faster pace of application development. It is also caused by the need to flexibly “glue” together various types of systems and services, as is typical especially in web-based software development.
There are a number of dynamic languages in widespread use today, including Perl, PHP, Python and Ruby. However, the dynamic language that has received by far the most attention recently is JavaScript [Fla06] (statistics on the popularity of different programming languages are available, e.g., in Gartner’s user survey results published in 2006). JavaScript was originally created as a scripting language and included in Netscape Navigator web browser version 2.0B in 1995 to support relatively simple web content scripting and animation tasks. Since then, the use of the JavaScript language has spread to considerably larger tasks and applications. Today, it is not uncommon to have JavaScript applications that consist of tens or even hundreds of thousands of lines of code.
Because of its humble beginnings as a web scripting language, JavaScript has suffered from a reputation as a “toy” language. In reality, JavaScript is a general-purpose programming language that can be used for real programming and not just scripting. We have analyzed the use of the JavaScript language as a real programming language in an earlier paper [MiT07b]. Doug Crockford has written an excellent book about the good and bad characteristics of the JavaScript language [Cro08].
JavaScript and mashware. Some would say that the trend toward JavaScript is purely accidental, reflecting only the fact that JavaScript is the only language supported (in reasonably compatible forms) by all the major web browsers. However, there is a more fundamental transition occurring in the industry that is leading the developers increasingly towards dynamic languages and JavaScript especially.
The power of the World Wide Web stems largely from the absence of static bindings [MiT07a]. For instance, when a web site refers to another site or a resource such as a bitmap image, or when a JavaScript program accesses a certain function or DOM attribute, the references are resolved at runtime without static checking. It is this dynamic nature that makes it possible to flexibly combine content from multiple web sites and, more generally, for the Web to be “alive” and evolve constantly with no central planning or control. The movement to web-based software will inevitably lead developers increasingly toward dynamic programming languages.
Dynamic languages play a critical role in enabling the development of applications that combine content from different web sites and that can adapt to the evolving data formats and types used in different web sites. Dynamic languages serve as the glue that allows different types of data representations to be converted from one form to another easily. For instance, the string manipulation operations (especially those related to regular expressions) in JavaScript are well suited to data format conversions. Dynamic languages usually also provide convenient syntactic mechanisms for creating new objects and new types of objects at runtime. For example, the object literal notation in JavaScript [Fla06 p. 106] makes it very easy to construct new objects on the fly:
var customer = { name: “John”, age: 37, email: “john@doe.com” };
In a conventional, statically compiled object-oriented language such as C++ or the Java™ programming language, the definition of new objects is much more rigid; basically, all the different types/classes of objects must be defined ahead of program compilation and execution. This makes it more difficult for the software to adapt to changes that later occur in the formats that the application will have to process.
The ability to deliver executable software in source code form also plays a critical role in enabling the development of software in the form of mashups. Unlike with programming languages that depend on static compilation, JavaScript applications can be easily distributed in source code form. The ability to deliver executable software in source code form makes it easier to reuse software in a piecemeal fashion, or tweak the code if some small changes are needed. Conventional programming languages that depend on binary files and static binding are poorly suited for this kind of operation. Compared to dynamic languages, binary files are like “bricks” that cannot easily be reused in contexts unforeseen by the designers.
Granted, dynamic languages and JavaScript have drawbacks too. The extremely dynamic, permissive, error-tolerant nature of the JavaScript language makes it difficult to catch errors at development time. As a general principle, JavaScript virtual machines do not report errors until absolutely necessary. This can lead to problems that are very difficult to trace and debug. For example, spelling errors in variable names implicitly result in the creation of a new variable with the misspelled name. This is often not the desired behavior. While such behavior enables the successful execution of code lines that contain spelling errors (and more generally, allows new variables to be added to objects easily), this usually results in other, significantly more difficult errors later in the execution. When an error is finally reported, the actual problem hides elsewhere in the program and is sometimes very difficult to pinpoint.
Web applications are generally so dynamic that it is impossible to know statically if all the necessary structures will be available at runtime. In some cases the absence of (or changes in) the requested elements can lead to serious problems that are impossible to detect before execution. Consequently, web applications require significantly more testing (especially coverage testing) to make sure that all the possible application behaviors and paths of execution are tested comprehensively.
In general, the development style associated with dynamic languages is rather different from conventional software development. Since there is no way to detect during development time whether all the necessary components are present or have the expected functionality, applications have to be written and tested piece by piece, rather than by writing tens of thousands of lines of code ahead of the first execution. Such a stepwise development style is similar to the style used with programming languages that are specifically geared towards exploratory programming. Examples of such languages include Smalltalk [GoR83] and Self [UnS87].
Performance issues. Since dynamic languages are usually built around simple interpreters that must be able to evaluate source code at runtime, these languages have not been particularly fast. Until recently web application performance was not much of an issue, since JavaScript was used for relatively simple scripting tasks. Furthermore, performance problems were largely masked by other issues such as network latency or poor graphics performance of the web browser. It is only recently when people started writing more serious JavaScript applications that performance issues have become more apparent.
JavaScript applications have traditionally run at least one or two orders of magnitude slower than corresponding applications written in programming languages such as C++ or Java. Yet the perception about JavaScript being a slow language is largely accidental, reflecting only the lack of attention that has been put into optimizing JavaScript virtual machines.
In the past year or so, several high-performance JavaScript engines have become available (in alphabetical order):
Apple SquirrelFish (http://trac.webkit.org/wiki/SquirrelFish) and SquirrelFish Extreme
Google V8 (http://code.google.com/p/v8/)
Mozilla Tamarin (http://www.mozilla.org/projects/tamarin/)
Mozilla TraceMonkey (https://wiki.mozilla.org/JavaScript:TraceMonkey)
These virtual machines are dramatically faster than the first-generation JavaScript engines that have been used in major web browser for years. For instance, Google’s V8 virtual machine runs the
SunSpider JavaScript benchmark approximately 18 times faster than the JScript engine in Microsoft Internet Explorer version 7. Based on the same benchmark, the performance difference between Google V8 and the SpiderMonkey virtual machine used in Mozilla Firefox version 2.0.0.17 is 8.5 times, i.e., nearly an order of magnitude.
The race towards high-performance JavaScript engines will gradually change the perception about the performance of the JavaScript language and dynamic languages in general. The situation resembles the rapid evolution of Java virtual machines in the late 1990s when the Java virtual machine performance wars were at full height. With abundant, continually increasing processing power available in computers and mobile devices, we believe that JavaScript will eventually become the most widely used programming language not only in desktop computers but also in mobile devices, at least for end-user application development.
6. Towards Mashware: The Landscape of Mashup Development Technologies
The technological pieces needed for supporting mashware are already largely in place, even though the current web browser is not yet ideally suited for such applications. In this section we take a look at some of the key technologies and trends related to mashware.
6.1. Existing General-Purpose Web Application Development Technologies
The landscape of web application development technologies is still rather diverse, reflecting the rapidly evolving state of the art in the web development area. At the high level, the technologies for the development of client-side web applications can be grouped into three categories:
1) Custom runtime: technologies that require a custom runtime (outside the web browser)
2) Plugin-based: technologies that depend on web browser plug-in component(s)
3) Browser-based: technologies that run in the web browser without any add-on components
These categories, as well as various currently used Rich Internet Application (RIA) technologies, have been illustrated in Figure 4. On the right there are technologies – such as the Java and Java FX platforms – that require a custom runtime environment that is commonly used outside the web browser. In the middle, there are systems that run inside a web browser but which require a special plug-in component in order to run inside the browser. On the left there are technologies that run inside a standard web browser without any plug-ins or other add-on components.
Many technologies that belong in the first category, such as Adobe AIR [FPM08], Microsoft Silverlight [Mor08], or Sun’s Java FX [Wea07], also have plug-in based implementations available that allow these systems to be used inside a web browser. For instance, Microsoft Silverlight plug-ins are currently available for Internet Explorer, Mozilla Firefox and Apple Safari web browsers. In general, the technologies in these categories are not distinct but overlap at least to some degree.
Technologies that belong in the third category (shown on the left in Figure 4) – browser-based systems such as Ajax [CPJ05] and Google Web Toolkit [HaT07] that do not require any add-on components – can be divided further into two subcategories: (1) those systems that utilize the computing power of the
client extensively and perform the majority of processing on the client, and (2) those systems that are server-centric and perform the majority of computation on the server (i.e., truly thin clients). Our focus in this paper is primarily on those technologies that leverage the client-side processing power extensively, as we believe that approach to be fundamental to mashware. A good example of such a client-side, purely browser-based web application technology is the Sun™ Labs Lively Kernel [IKU08,
- Run in a standard browser - Browser plug-in- Custom execution required engine required
- No plug-ins needed
- Custom UI - Runs outside
- Platform-independent
the browser
- Browser-based UI
- Custom/native UI
Figure 4: Different categories of RIA technologies
Important tradeoffs. It is important to note that there are significant tradeoffs in the RIA technologies based on how closely integrated the technology is with the web browser. Custom runtimes or plugin¬based systems can escape the limitations of the web browser (especially those related to the security model, supported API sets and the user interface features), and customize the user experience and interaction mechanisms much more easily. However, those benefits come at the expense of portability and ease of worldwide application deployment. If one wants to build truly portable “Open Web” applications and deploy those applications instantly worldwide without installation hassles, then any dependencies with technologies unsupported by the web browser must be eliminated. In other words, only those technologies that belong in the third (browser-based) category support the vision of fully portable, “zero-installation” web applications. Because of incompatibilities between different web browsers, there are still limitations in realizing the full potential of that vision, though.
We have provided a summary of several commonly used RIA systems in our previous paper [TMI08]. In that paper, we have also analyzed the use of the web browser as an application platform in detail. Therefore, we will not delve deeper into details here. However, it is interesting to note that there is a frontier forming between two types of RIA systems: (1) those that have been built around the Java programming language, such as Java, Java FX and Google Web Toolkit, and (2) those that have been built around different flavors of JavaScript: Ajax, Adobe Flash and AIR, Microsoft Silverlight, and
Sun Labs Lively Kernel. Note that Google has another RIA technology – Google Gears – that has been designed to complement Ajax, i.e., is built around JavaScript. The use of those RIA technologies that are based on neither Java nor JavaScript (such as Ruby on Rails) seem to be on the wane.
It should also be noted that the remarks about “thin” and “fat” web clients are not as clear-cut as presented in Figure 4. While it is true that custom runtimes and plugin-based systems provide support for much “fatter” API sets and other features, the web browser will gradually absorb more functionality and therefore make the browser-based systems fatter as well. For instance, the upcoming HTML 5 standard (http://www.w3.org/html/wg/html5/) will introduce many new features aimed at web application development, such as an immediate-mode 2D drawing API and drag-and-drop support. Yet the application development APIs offered by the standard web browser are still limited compared to full-fledged platforms such as the Java™ platform or Microsoft Silverlight.
6.2. Existing Mashup Development Technologies and Tools
In addition to general-purpose, “plain vanilla” web application development technologies discussed above, there are tools that have been designed specifically to support the development of mashups. The best known mashup development tools are (in alphabetical order):
Google Mashup Editor (http://code.google.com/gme/)
IBM Mashup Center (http://www.ibm.com/software/info/mashup-center/)
IBM Project Zero (http://www.projectzero.org/)
Intel Mash Maker (http://mashmaker.intel.com/)
JackBe Presto (http://www.jackbe.com/)
LiquidApps (http://www.liquidappsworld.com/)
Microsoft Popfly (http://www.popfly.com/)
Open Mashups Studio (http://www.open-mashups.org/)
Yahoo Pipes (http://pipes.yahoo.com/)
These systems differ from general-purpose web application environments in the sense that they are geared much more towards ordinary users and not just professional software developers. Most of the systems include a visual programming tool that supports drag-and-drop construction of applications based on existing web content and services. Application development is done primarily via “programming by wire”, i.e., by connecting visual elements representing different web services to each other. Source code editing is usually possible, too, but is required only for advanced tasks that cannot be performed visually. The generated applications can be used in standalone mode or embedded in other web pages and services.
Figure 5 shows screen snapshots from two different mashup development tools: Microsoft Popfly and Yahoo Pipes. Both systems are built around a visual editor that allows the user to choose various services from a list or tree of components shown on the left, and connect those services by wiring them to each other visually and then filling in the necessary attributes. The resulting applications can be tested immediately without compilation or static linking.
Both Microsoft Popfly and Yahoo Pipes run inside the web browser, i.e., the user does not have to use a separate tool for development. Most of the work, including the development, testing/debugging and
the execution of applications, occurs within the web browser. For Microsoft Popfly, more conventional development tools – built around Microsoft Visual Studio – are also available.
Figure 5: Examples of mashup development tools: Microsoft Popfly and Yahoo Pipes
In addition to mashup development tools, there are also “web mining” and scraping tools that allow information from web sites to be collected and processed in various ways, and then displayed graphically. These tools are more focused on finding suitable information from the Web rather than combining the information from various sites. A good example of a web mining tool is Metafy Anthracite (http://www.metafy.com/).
6.3. Summary of Popular Mashup Development Tools
In the Fall 2008, Prof. Tommi Mikkonen and Antero Taivalsaari arranged a seminar on Mashup Development Technologies at the Tampere University of Technology, Finland. About 25 Master’s degree and Ph.D. students participated in the seminar. During the seminar, the students took a detailed look at a number of popular mashup development tools, analyzing and dissecting their features, playing with existing demo applications, and building new mashups using the tools. Below we provide a summary of five systems that proved to be most interesting and useful during the seminar. The systems are summarized in alphabetical order.
6.3.1. Google Mashup Editor (GME)
Google Mashup Editor (http://code.google.com/gme/) is an Ajax development framework and a set of associated tools based on widely used web technologies (HTML, CSS, JavaScript) and GME’s own declarative XML tags. The system runs in Mozilla Firefox and Microsoft Internet Explorer web browsers without plug-in components. The system introduces a simple graphics editor that allows the user to create mashups visually. Additionally, GME has a JavaScript API that provides more functionality and flexibility for manipulating data programmatically.
The mashup creation capabilities of the Google Mashup Editor are limited primarily to extracting data from newsfeeds. It is possible to pull data from external RSS and Atom feeds as well as from Google Base (http://www.google.com/base/). Furthermore, it is possible to write application-or user-specific feeds using the JavaScript API.
As with most other mashup creation environments today, all the code created with GME is uploaded and hosted on a server. With the Google Mashup Editor, the source code and uploaded resource files related to applications are stored using the open source project hosting feature of Google Code (http://code.google.com/); when a new GME project is created, a new repository is created on Google Code to store the source files and resources associated with the project. A Subversion interface is provided to edit the files outside the Google Mashup Editor.
Google Mashup Editor is still in beta stage, and its availability is limited to a fixed number of trial users. Based on our experiences during the seminar mentioned above, Google Mashup Editor is still rather rudimentary and limited in terms of functionality, especially when compared to some other mashup environments such as Microsoft Popfly and Yahoo Pipes. On the positive side, it is important to note that Google Mashup Editor does not require any web browser plug-ins, i.e., it is an “Open Web” environment that runs in a standard web browser. (Note: Just as this report was reaching publication, Google announced that the development of Google Mashup Editor will be discontinued.)
6.3.2. IBM Mashup Center
IBM Mashup Center (http://www.ibm.com/software/info/mashup-center/) is a suite of tools built around two key components: IBM Lotus Mashups and IBM InfoSphere MashupHub. IBM Lotus Mashups is a graphical, browser-based tool intended for creating web pages and widgets visually. Lotus Mashups includes (1) a visual editor that runs in a web browser; (2) a mashup catalog which facilitates the sharing and discovery of mashup components, with features such as user community ratings, tagging, and commenting; and (3) a set of out-of-the-box widgets that can be used for visualizing the information displayed in mashups.
The back-end storage capabilities of IBM Mashup Center are provided by IBM InfoSphere MashupHub. InfoSphere MashupHub contains an application server, built around the IBM WebSphere Application Server, that exposes REST APIs (see [Fie00, FiT02]) to clients that can access its services over a secure HTTPS connection. MashupHub includes an integrated database for storing mashup information. It also offers a visual browser-based IDE, written in Ajax and Dojo (http://www.dojotoolkit.org/), that is intended for the visual creation of feeds.
Note that the two components in IBM Mashup Center – Lotus Mashups and InfoSphere MashupHub – offer somewhat overlapping client-side functionality. Both tools offer visual editing capabilities, and it is not always easy to decide which tool to use for which purpose. Lotus Mashups is geared more towards the creation of web pages and towards displaying data using pre-fabricated widgets. In contrast, the visual editing capabilities of InfoSphere MashupHub are intended primarily for creating feeds and feed mashups, resembling the capabilities of Yahoo Pipes to some extent. During our Mashup Development Seminar, students found the overlap between the tools confusing. In general, IBM Mashup Center felt less integrated and less intuitive to use than many other tools evaluated in the seminar.
Perhaps the most unique feature of IBM Mashup Center – at least when compared to the other mashup development systems discussed here – is the feature that allows the user to easily upload and publish data from a local computer (e.g., from a local PC) and then mix and match that data with other information available on the Web. This makes it easy, e.g., to combine information in the users’ Excel spreadsheets with maps or other data services available on the Web.
6.3.3. Intel Mash Maker
Unlike all the other mashup development systems summarized in this paper, Intel Mash Maker (http://mashmaker.intel.com/) is a primarily client-oriented system. Whereas in all the other mashup development systems discussed in this paper the mashing up of data is performed on the server, in Intel Mash Maker content combination is performed on the client (in the web browser). In general, Intel Mash Maker follows a different philosophy, in which “mashing is just browsing” and “mashups are personal”. This is in contrast with the other systems in which the source code, data, and resources of the generated mashups reside on the servers of the mashup service provider. From this viewpoint, Intel Mash Maker is closest to our notion of mashware, as summarized in Sections 3 and 4.
Intel Mash Maker is implemented as a web browser plug-in that complements the existing web browser with additional web page content extraction, processing and visualization capabilities. Plug-ins are currently available for Mozilla Firefox and Microsoft Internet Explorer.
A central component in the Intel Mash Maker is a tool called the extractor (there can be several extractors depending on the type of the content to analyze). An extractor allows the contents of a web page to be parsed and analyzed, and then displayed as a data tree (an example of a data tree is shown in Figure 6 on the left). The data tree provides a component-oriented view of the contents of the web page, based on the underlying (X)HTML or XML content. Currently supported content data formats include XML, JSON, (X)HTML and RSS. The data tree allows the contents of the web page to be edited and processed in various ways, e.g., to create a subset of the page containing only the information that the user wants to see, without advertisements or other undesired information.
A typical Mash Maker usage scenario is as follows. When the user navigates to a web page, Mash Maker immediately analyzes the contents of the site by using an extractor. The system then builds a graphical view of the site, and allows the user to “tag” those items that the user wishes to reuse in other contexts. The user can also choose the items to reuse simply by picking the items directly from the web browser’s page view. The web page looks fully normal, except that yellow highlights will appear around or behind those items that have been selected. The user can then create widgets (implemented as
iframes) that display only the specific content that was chosen earlier, and export those widgets to other places (e.g., to the user’s personal iGoogle web page).
Figure 6: Intel Mash Maker running in the Mozilla Firefox browser
Typical examples of Mash Maker mashups are regular web pages that contain city names. When the user navigates to such a page, the city names are automatically augmented with additional icons (shown next to the city names) that allow the user to fetch current weather information, travel information, and other information about that particular city. When such icons are clicked, the Mash Maker plug-in will automatically obtain the weather and/or traffic information, and display the information using the desired widget. The general idea here is very similar to Mozilla’s GreaseMonkey extension (http://en.wikipedia.org/wiki/Greasemonkey) that allows users to install scripts that make on-the-fly changes to HTML web pages.
Even though Mash Maker is a client-oriented system, it includes “community” capabilities such as sharing the created mashup with other users. For instance, it is possible to share the mashups so that when another user navigates to a web page that has previously been used as a target for mashups by a Mash Maker developer, the web browser will automatically display mashup icons that allow the user to use (and reuse) the mashups created by the other users earlier.
In our Mashup Development Seminar, the students found the Intel Mash Maker system quite useful and well-integrated with existing browsers. The students complained about the lack of proper documentation, though. They also reported that while the system works great in simple examples, the
scripting capabilities are insufficient even for relatively straightforward and frequently needed tasks such as date format conversions or removals of special characters during data extraction. For such tasks, it would be simpler to use an integrated scripting language, rather than attempting to do everything visually.
6.3.4. Microsoft Popfly
Microsoft Popfly (http://www.popfly.com/) is a web-based service that consists of three closely coupled tools: (1) A web page creation tool, (2) a visual game development tool, and (3) a mashup development tool. All these tools run in the web browser, and have a web-based graphical user interface that has been implemented using the capabilities of the underlying Microsoft Silverlight plug-in. A Silverlight plug-in is required to run Popfly. Currently Silverlight plug-ins are available for Microsoft Internet Explorer, Mozilla Firefox, and Apple’s Safari browser.
Figure 7: Microsoft Popfly online game development tool
The Popfly game development tool is illustrated in Figure 7. The game development tool includes a visual tile scripting environment (see [IWC88]) that allows the behavior of objects in simple online games to be defined visually by manipulating graphical blocks that represent the behaviors and
properties of game objects. This part of the Popfly environment is intended more for children rather than for professional software developers. Dozens of existing game templates are provided for starting new online game projects easily.
The Popfly mashup development tool is shown in earlier Figure 5. The mashup tool supports visual, interactive mashup creation inside the web browser. The tool consists of a number of “blocks” (displayed on the left in Figure 5) that represent hook-ups to various existing web services (such as Digg, Flickr, or different map, traffic or weather services). The system can be run in two basic modes: “Edit” and “Run”. In “Edit” mode, the user can connect different web services to each other by dragging the blocks representing them into the main display, drawing “wires” to connect those services, and then editing and filling in the relevant attributes, e.g., to determine which particular properties from the services will be included in the generated mashup. In “Run” mode, the created mashup can be tested inside the web browser immediately without compilation or linking.
All the Popfly tools support instant worldwide publishing of applications via the Popfly.com web service. Applications can be published as widgets and then embedded in other web pages using URLs. There are also wiki-like collaboration capabilities for users to share and discuss their projects. Projects can be “ripped” (copied) or “tweaked” (customized) by other users easily.
Since the Popfly environment has been built on top of the Silverlight Rich Internet Application platform, the environment provides a much more comprehensive set of APIs than is offered by the standard web browser and most other web development environments. A rich set of existing widgets and other GUI elements is provided.
For those users who want to build applications using a more conventional approach – outside the web browser and outside the Popfly web service – Microsoft Visual Studio support is also available. Programming is done primarily in JScript – Microsoft’s flavor of JavaScript. Debugging capabilities are provided both for those users who prefer using Microsoft Visual Studio and for those users who perform all the development using Popfly’s web-based interface.
During our Mashup Development Seminar, the students found the Popfly environment interesting and rather intuitive to use. Out of the systems evaluated in the seminar, Popfly proved to be the one that was most fun to use; students spent hours just viewing and playing with the existing sample applications.
On the negative side, Popfly’s dependence on the Microsoft Silverlight plug-in raised some questions during the seminar. The students also found a lot of bugs and compatibility issues depending on which web browser and which version of Silverlight they were using. Many of the demos crashed, froze, or refused to save themselves on the web server.
Given that all the applications, data and resources created with the web-based interface of Microsoft Popfly reside on Microsoft servers, there was also some discussion and concern about intellectual property ownership and trust more generally. Since most mashup development environments store the generated applications on the server (which is controlled by the mashup service provider and not by the mashup developer herself), this problem is more general and not specific to Microsoft Popfly only.
6.3.5. Yahoo Pipes
Yahoo Pipes (http://pipes.yahoo.com/) is a visual composition tool to aggregate, manipulate, and merge content from around the Web. Yahoo Pipes is able to read information from the Web in various different formats such as HTML, XML, JSON, CSV, RSS, Atom, RDF, Flickr, Google Base, Yahoo Local and Yahoo Search. The system can output results in various formats such as RSS 1.0, RSS 2.0, JSON and Atom. It can also create badges – visual mashup widgets that can be exported and embedded into other web sites (e.g., into iGoogle or My Yahoo).
As shown in Figure 5, Yahoo Pipes is a web-based system that has been built around a visual editor that runs inside a web browser. All the major web browsers are supported (except that for Microsoft Internet Explorer, at least version 7 is required). The visual editor consists of graphical elements that represent different kinds of data processing operations such as regular expressions, filters, sorting or looping instructions. By visually instantiating and then wiring those graphical elements to each other, the programmer can create powerful expressions for fetching and processing data from the Web in various ways. New mashups (known as pipes in Yahoo Pipes parlance) can be tested immediately by using the “Run Pipe…” operation. An integrated debugging panel is included, so that the behavior and the output of the pipe can be analyzed in different ways.
As with most other mashup systems, the generated pipes are stored on the server (in this case on pipes.yahoo.com). The system includes hook-ups to various existing web services such as Flickr, Google Base and Yahoo’s own web services, so that information from those services can be accessed and processed easily.
In our Mashup Development Seminar, the students found Yahoo Pipes the easiest and most intuitive to use, at least out of the five systems summarized in this report. It was also the system with which it was easiest to create useful mashups for everyday use. The visual programming capabilities of Yahoo Pipes were the most comprehensive among the evaluated systems. However, the usage scope of Yahoo Pipes seemed somewhat more limited than the scope of some other systems. Based on the students’ experiences, Yahoo Pipes is particularly capable at processing and creating new feeds. By creating badges, those new feeds can then quite easily be included and shown in other web sites.
6.4. Common Characteristics and Trends in Mashup Development Tools
In analyzing the different mashup development tools available today, some common themes and trends have started to emerge. Such trends include:
– Using the web browser not only to run applications/mashups but also to develop them. For instance, Google Mashup Editor, Microsoft Popfly and Yahoo Pipes use the web browser to host the development environment. Since the applications are developed inside the web browser, the user does not have to use any other tools besides the web browser itself. For many of the systems listed above, conventional IDEs are also available but intended primarily for professional developers.
– Using visual programming techniques to facilitate end-user development. Visual “tile scripting” and “program by wire” environments are provided, e.g., by Microsoft Popfly and Yahoo Pipes.
These environments are intended for non-professional application developers, including children. Conventional source code editing is usually supported, too, but required only for advanced tasks that cannot be performed visually.
– Using the web server to host and share the created mashups. Most of the mashup development tools mentioned above store the created mashups and applications on a web server that is hosted by the service provider. For instance, Google Mashup Editor, Microsoft Popfly and Yahoo Pipes applications reside on the googlemashups.com, popfly.com and pipes.yahoo.com servers, respectively. Applications can be distributed simply by passing along an URL pointing to the application on the server.
– Direct hook-ups to various existing web services. Since the Web itself does not provide enough semantic information or well-defined interfaces to access information in various web sites in a generalized fashion, most of the mashup development tools include custom-built hook-ups to access data in various existing web services. Hook-ups are commonly provided to services such as Digg, Facebook, Flickr, Google Maps, Picasa, Twitter, Yahoo Traffic and various RSS newsfeeds.
It should also be mentioned that most of the above listed mashup development tools are still under development, e.g., in beta or some other pre-release stage, reflecting the rapidly evolving state of the art in mashup development. Nevertheless, many of the systems are already quite advanced and capable, and – perhaps most importantly – a lot of fun even for children to use. For the younger generation of users, those who spend the majority of their time using the web browser anyway, the browser-based application development approach and the possibility to “borrow” code and other content from various sources will seem quite natural.
7. Towards Mashware: Technical Challenges, Obstacles and Solutions
All the mashup development systems discussed above are geared towards mashing up general content on the Web, rather than for creating applications that combine code from multiple web sites and services. In that sense, the systems discussed above do not fulfill our mashware vision yet. Out of the systems discussed in this paper, Intel Mashup Maker is closest to our vision in the sense that it performs content combination on the client, leveraging the computing power of the client computer and the web browser. However, the actual programming capabilities of Intel Mash Maker are among the most limited in those systems that we evaluated during our Mashup Development Seminar.
In the following subsections, we take a look at topics that we believe most fundamentally constrain the evolution of web technologies towards software as a mashup. Some key solutions are also proposed. The material in this section is an abbreviated summary of a workshop paper that was published earlier in 2008 [TaM08].
7.1. Lack of Modularity and Well-Defined Interfaces
When it comes to the development of mashups that combine content from different sites, there are major problems that arise from the fact that web sites have no well-defined interfaces that would clearly describe which parts of the web site are intended for reuse. Even though a tremendous amount
of valuable source code and data is available on the Web, only a fraction of it is available in a modular form that would make the code and data reusable in other contexts. For instance, most web sites do not offer technical documentation (e.g., a public interface specification) that would clearly state which parts of the site and its services are intended to be used externally by third parties, and which parts are implementation-specific and not intended for reuse at all. Only a small number of services, such as Google Maps and Flickr, offer a well-defined API through which these services can be used programmatically by other web sites.
In general, although a number of web interface description languages exist, such as the Web Service Description Language (WSDL, http://www.w3.org/TR/wsdl) or the Web Application Description Language (WADL, https://wadl.dev.java.net/), there is no single commonly accepted standard that would be widely used by web sites today. In the absence of well-defined interfaces and in the absence of a clean separation between the specification and implementation of web sites, there are rarely any guarantees that the reused services would remain consistent or even available in the future. The only exceptions are those services that have been clearly designated (and properly documented) for reuse, such as the aforementioned Google Maps API [GiE06]. Without the mashup development tools mentioned in the previous subsection – and their customized hook-ups to various existing web services
– the reuse of many commonly used web services would be nearly impossible. Even when using such tools, the resulting mashups are still fragile and ad hoc. We have discussed this topic in more detail in our earlier paper [TaM08].
7.2. Absence of Fine-Grained Security Model
Another important problem in the creation of mashware is the absence of a suitable security model. These problems date back to conventions that were established early on in the design and historical evolution of the web browser. A central security-related limitation in the web browser is the Same Origin Policy that was introduced in Netscape Navigator version 2.0 (http://www.mozilla.org/projects/security/components/same-origin.html). The philosophy behind the same origin policy is simple: it is not safe to trust content loaded from arbitrary web sites. When a document containing a script is downloaded from a certain web site, the script is allowed to access resources only from the same web site but not from other sites. In other words, the same origin policy prevents a document or script loaded from one web site (“origin”) from getting or setting properties of a document from a different origin.
The same origin policy makes it difficult to create and deploy mashups or other web applications that combine content (e.g., news, weather data, stock quotes, traffic statistics) from multiple web sites. Basically, most of the content mashing must be performed on the server. Special proxy arrangements are usually needed on the server side to allow networking requests to be passed on to external sites. When deploying web applications, the application developer must therefore be closely affiliated with the owner of the web server in order to make the arrangements for accessing the necessary sites.
7.3. Lack of Proper Namespace Isolation
An additional problem related to the absence of a proper security model is the lack of proper namespace isolation in JavaScript. By default, all the code that is downloaded into the JavaScript
virtual machine shares the same namespace (including the DOM tree). Without the same origin policy that prevents the downloading of content from different web sites, code downloaded from one web site could interface with code originating from other web sites. This would make it possible, e.g., to read private data that should not be visible to external users, or inject malicious scripts into code loaded from other sites. Vulnerabilities of this kind – collectively known as cross-site scripting (XSS) issues – have been exploited to craft powerful phishing attacks and other browser exploits. The possibility of cross-site scripting vulnerabilities is the reason why the same origin policy discussed above was introduced in the first place.
The key observation arising from the problems discussed above is that there is a need for a more fine-grained security model for web applications. On the Web today, applications are second-class citizens that are on the mercy of the classic, “one-size-fits-all” sandbox security model of the web browser. Decisions about security are determined primarily by the site (origin) from which the application is loaded, and not by the specific needs of the application itself. The problems become even more apparent when attempting to develop mashups that would need to flexibly combine content from multiple sites. Even though many interesting proposals have been made [Cro06, YUM07, WFH07, JaW07, KBS08], currently there is no commonly accepted finer-grained security model for web applications or for the Web more generally.
7.4. Additional Problems in Web Application Development
Web application and mashup development is still tedious. In our earlier work, we have divided the problems in web application development into the following categories. These problem areas are not specific to mashup development, but apply to web development more generally:
1) Usability and user interaction issues
2) Networking and security issues
3) Browser interoperability and compatibility issues
4) Development style and testing issues
5) Deployment issues
6) Performance issues
Most of the problems can be traced back to the fact that the web browser was not really designed to be a general-purpose application platform. For a more detailed discussion of problems in these areas, refer to the earlier paper [TMI08].
7.5. Possible Solutions
So, what is still missing from realizing the mashware vision? Architecturally, the following main features would be needed:
Modularity support and proper interfaces with information hiding.
A mechanism to document and publish application interfaces (more generally: the public interfaces of a web site) in a standardized format.
A more fine-grained browser security model that provides controlled access to security-critical APIs and host platform resources, as well as allows applications to download components flexibly from various sites.
An execution engine inside the web browser that supports namespace isolation and modularity to allow content from different sites to run securely.
In principle, technologies for all these areas are already available. For instance, modularity mechanisms and interface description languages have been investigated for decades, starting from the seminar work by Parnas, Liskov, Zilles and others [Par72, LiZ74]. In the context of the Web, technologies and protocols such as REST [Fie00, FiT02], SOAP (http://www.w3.org/TR/soap) and WSDL (http://www.w3.org/TR/wsdl) are gradually making it possible to specify and use the interfaces of web sites in a portable and reusable fashion. Fine-grained security models and namespace isolation have been studied extensively, e.g., in the context of the Java Platform, Standard Edition (Java SE) [GED03] or in the Java Platform, Micro Edition (Java ME). The latter platform has a lightweight, permission-based, certificate-based security model [RTV03] that could potentially be applicable also to web application development.
In general, the challenges in the areas discussed above are not only technological. The key problem is related to retrofitting proper modularity and security mechanisms into an architecture that was not really intended to be a full-fledged software platform in the first place. Standardization is a major challenge, since it is difficult to define a security solution that would be satisfactory to everybody while retaining backwards compatibility with the existing solutions. Also, many security models depend on application signing and/or security certificates; such solutions usually involve complicated business issues, e.g., related to who has the authority to issue security certificates. Therefore, it is likely that any resolutions in this area will still take years. Meanwhile, a large number of security groups and communities – such as the Web Application Security Consortium (WASC), the Open Web Application Security Project (OWASP), and the W3C Web Security Context Working Group – are working on the problem.
8. Conclusion
The World Wide Web is the most powerful medium for information sharing and distribution in the history of humankind. Therefore, it is not surprising that the use of the Web has spread to many new areas outside its original use, including the distribution of photographs, music, videos, and so on. We believe that the massive popularity of the Web will make it the de facto platform for software applications as well. As a consequence, the web browser will take over various roles that conventional operating systems used to have, e.g., in serving as a host environment for most commonly used end-user applications. For the average computer user, the web browser will effectively be the operating system; after all, most of the applications and services that they need will be available on the Web.
In this paper we have argued that the next logical step in the evolution of web applications is mashware: software as a mashup. In web terminology, a mashup is a web site that combines (“mashes up”) content from more than one source (from multiple web sites) into an integrated experience. Mashups are content aggregates that leverage the power of the Web to support worldwide sharing of content that conventionally would not have been easily accessible or reusable in different contexts or
from different locations. By mashware, we refer to a form of client-side mashup development in which web applications can be composed in the web browser by dynamically combining code originating from web sites from all over the world. This kind of an approach will make it possible for software developers to collaborate on an immensely large scale, allowing unparalleled sharing and reuse of software, data, layout and visualization information, or any other content across the planet. In this paper we have discussed the technological background of mashware, analyzed existing technologies intended for mashup development, as well as provided a summary of the challenges and obstacles that still remain in this exciting new area.
Acknowledgements
The author would like to thank Prof. Tommi Mikkonen and all the students who participated in the Mashup Development Seminar that we arranged at the Tampere University of Technology in Fall 2008. Most of the comments and observations related to existing mashup development tools, especially those presented in Section 6.3, are based on the presentations given by students during the seminar.
References
CPJ05 Crane, D., Pascarello, E, James, D., Ajax in Action. Manning Publications, 2005.
Cro06 Crockford, D., The <module> Tag: A Proposed Solution to the Mashup Security Problem. http://www.json.org/module.html, October 30, 2006.
Cro08 Crockford, D., JavaScript: The Good Parts. O’Reilly Media, 2008.
Fie00 Fielding, R.T., Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California at Irvine, CA, USA, 2000.
FiT02 Fielding, R.T., Taylor, R.N., Principled Design of the Modern Web Architecture. ACM Transactions on Internet Technology, Vol. 2, No. 2, May 2002, pp. 115-150.
Fla06 Flanagan, D., JavaScript: The Definitive Guide (5th Edition). O’Reilly Media, 2006.
FPM08 Freedman, C., Peters, K., Modien, C., Lucyk, B., Manning, R., Professional Adobe AIR: Application Development for the Adobe Integrated Runtime. Wrox Publishing, 2008.
GiE06 Gibson, R., Erle, S., Google Maps Hacks. O’Reilly Media, 2006.
GoR83 Goldberg, A., Robson, D., Smalltalk-80: the Language and Its Implementation. Addison-Wesley, 1983.
GED03 Gong, L., Ellison, G., Dageforde, M., Inside Java™ 2 Platform Security: Architecture, API Design, and Implementation (2nd Edition). Addison-Wesley (Java Series), 2003.
HaT07 Hanson, R., Tacy, A., GWT in Action: Easy Ajax with the Google Web Toolkit. Manning Publications, 2007.
IKU08 Ingalls, D., Palacz, K., Uhler, S., Taivalsaari, A., Mikkonen, T., The Lively Kernel – A Self-Supporting System on a Web Page. In Proceedings of the Self-Supporting Systems Conference (Potsdam, Germany, May 15-16), Lecture Notes in Computer Science LNCS 5146, Springer-Verlag, 2008, pp. 31-50.
IWC88 Ingalls, D., Wallace, C., Chow, Y-Y., Ludolph, F., Doyle, K., Fabrik: A Visual Programming Environment. In Proceedings of the OOPSLA’88 Conference (San Diego, California, September 25¬30), ACM SIGPLAN Notices, Vol. 23, No. 11, 1988, pp. 176-190.
JaW07 Jackson, C., Wang, H., Subspace: Secure Cross-Domain Communication for Web Mashups. In Proceedings of the 16th International World Wide Web Conference (Banff, Canada, May 8-12), 2007, pp. 611-619.
KBS08 Keukelaere, F., Bhola, S., Steiner, M., Chari, S., Yoshihama, S., SMash: Secure Component Model for Cross-Domain Mashups on Unmodified Browsers. In Proceedings of the 17th International World Wide Web Conference (Beijing, China, April 21-15), 2008, pp. 535-544.
LiZ74 Liskov, B.H., Zilles, S.N., Programming with Abstract Data Types. In Proceedings of ACM SIGPLAN Conference on Very High Level Languages, ACM SIGPLAN Notices, Vol. 9, No. 4, April 1974, pp. 50-59.
MiT07a Mikkonen, T., Taivalsaari, A., Web Applications: Spaghetti Code for the 21st Century. In Proceedings of the 6th ACIS International Conference on Software Engineering Research, Management and Applications (SERA’2008, Prague, Czech Republic, August 20-22), IEEE Computer Society, 2008, pp. 319-328. (An earlier, longer version published as Sun Labs Technical Report TR-2007-166, Sun Microsystems Laboratories, June 2007.)
MiT07b Mikkonen, T., Taivalsaari, A., Using JavaScript as a Real Programming Language. Sun Labs Technical Report TR-2007-168, Sun Microsystems Laboratories, October 2007.
Mor08 Moroney, L., Introducing Microsoft Silverlight 2.0. Microsoft Press, 2008.
Pau07 Paulson, L.D., Developers Shift to Dynamic Programming Languages, IEEE Computer, Vol. 40, No. 2, February 2007, pp. 12-15.
Par72 Parnas, D.L., On the Criteria to be Used in Decomposing Systems into Modules. Communications of the ACM, Vol. 15, No. 12, Dec. 1972, pp. 1053-1058.
RTV03 Riggs, R., Taivalsaari, A., Van Peursem, J., Huopaniemi, J., Patel, M., Uotila, A., Programming Wireless Devices with the Java™ 2 Platform, Micro Edition (2nd Edition). Addison-Wesley (Java Series), 2003.
TMI08 Taivalsaari, A., Mikkonen, T., Ingalls, D., Palacz, K., Web Browser as an Application Platform. In
Proceedings of the 34th Euromicro Conference on Software Engineering and Advanced Applications
(SEAA’2008, Parma, Italy, September 3-5), IEEE Computer Society, 2008, pp. 293-302. (An earlier, longer version published as Sun Labs Technical Report TR-2008-175, January 2008.)
TaM08 Taivalsaari, A., Mikkonen, T., Mashups and Modularity: Towards Secure and Reusable Web Applications. In Proceedings of 1st Workshop on Social Software Engineering and Applications (SoSEA’2008, L’Aquila, Italy, September 16), 2008.
UnS87 Ungar, D., Smith, R.B., Self: The Power of Simplicity. In Proceedings of the OOPSLA’87 Conference (Orlando, Florida, October 4-8), 1987, pp. 227-241.
Wea07 Weaver, J.L., JavaFX Script: Dynamic Java Scripting for Rich Internet/Client-Side Applications. Apress, 2007.
WFH07 Wang, H. J., Fan, X., Howell, J., Jackson, C., Protection and Communication Abstractions for Web Browsers in MashupOS. In Proceedings of the 21st ACM Symposium on Operating Systems Principles (Stevenson, WA, USA, October 14-17), Operating Systems Review, Vol. 41, No. 6, 2007, pp. 1-16.
YUM07 Yoshihama, S., Uramoto, N., Makino, S., Ishida, A., Kawanaka, S., De Keukelaere, F., Security Model for the Client-Side Web Application Environments. IBM Tokyo Research Laboratory presentation, May 24, 2007.
About the Author
Dr. Antero Taivalsaari is a Principal Investigator and Senior Staff Engineer at Sun Labs. Antero is best known for his seminal role in the design of the Java™ Platform, Micro Edition (Java ME platform) – one of the most popular commercial software platforms in the world, with over two billion devices deployed so far. Antero has received Sun’s Chairman’s Award for Innovation twice (in 2000 and 2003) for his work on Java ME technology. Since August 2006, Antero has been co-leading the Lively Kernel project with Dan Ingalls to bring lively, desktop-style user experience to the world of web programming. For more information, refer to http://www.taivalsaari.com/.
Sun Microsystems Laboratories 16 Network Circle Menlo Park, CA 94025
Mashware: The Future of Web Applications Antero Taivalsaari SMLI TR-2009-181
