Web-based software and services are available all over the world instantly after they are released online. They can be used and updated without need to install anything, and once in place, they can also be reused in other contexts. As the amount of web services and devices used to consume data has exploded, it is becoming di cult to handle and gain access to the relevant data. Mashups are a new breed of web applications that act as content aggregates that leverage the power of the Web to support instant, worldwide sharing of content. Another dimension of mashups is that since they build on services that are readily available, they are also implicitly creating software ecosystems between service providers and application developers. In this paper, we address the role of mashups in the creation of software ecosystems for the web era. In addition, we identify four levels of support that service providers can o er for mashups. Furthermore, we will also discuss the di erent avors of mashups as well as implementation considerations that are relevant from the ecosystem perspective.
The web-based software is available all over the world instantly after the online release. It can be used and updated without need to install anything. Applications can support user collaboration, i.e., allow users to interact and share the same applications over the Web. In addition, numerous web services allowing users to upload, download, store and modify private and public resources have emerged. These resources can include personal images, texts, videos, e-mails, etc. as well as public data such as stock quotes, weather data and news feeds.
As the amount of web services and devices used to consume data has exploded, it is di cult to handle and gain access to the relevant data. To be able to handle the situation, searching has become one of the most important service of the Web. However, searching can be used only for data accessing, not for analyzing or parsing it. Similarly to resources, communication has decentralized into di erent services such as e-mail, di erent social media services, instant messaging services, chats, blogs, etc. Therefore, new mechanisms are needed for resource handling and communication services of the Web.
An important realization is that applications built on top of the Web do not have to live by the same constraints that have characterized the evolution of conventional desktop software. The ability to dynamically combine content from numerous web sites and local resources, and the ability to instantly publish services worldwide has opened up entirely new possibilities for software development. In general, such systems are referred to as mashups, which are content aggregates that leverage the power of the Web to support instant, worldwide sharing of content.
In this paper, we address the role of mashups in the creation of implicit and
explicit software ecosystems [
Mashups can be characterized as applications that combine resources { data, code and other content { from di erent services in the Web into an integrated experience. Mashups can combine the content in new, unforeseen ways, thus creating entirely new web services, or they can provide new visualizations for already existing service. For instance, a mashup can combine a map with images that can be attached to speci c locations. Another type of mashup can visualize the images in novel fashion, for example on a timeline or as a collage.
Mashups have potential for great user experiences, as they include more functions than just composition. Mashups can be used to lter, combine and modify data retrieved from multiple sources over the Web. Combining web resources into mashups is an e cient way to create new services or extract relevant information from a complex mixture of source data. Even unexpected innovations are possible as mashups can combine resources in unforeseen fashion. Furthermore, mashups are even more usable when non-technical users can create them with special purpose tools and have their own views for data. This is very inspiring part of mashups as it allows creative users to design their own applications that are capable of doing unexpected things. Allowing \do-it-yourself" mashups serve the long tail of users having diverse needs that are not ful lled by existing applications or services. On embedded devices, mobile devices being at the forefront, mashups can bene t from accessing the user's context to combine resources, potentially automatically.
Well-build mashups have functionality for ltering source data. By having
adjustable lters a mashup can provide more relevant results. Filters can be
based on much more relevant variables than manually entered limits such as the
highest and the lowest price of a product. Such lters can be time of the day,
location of the user, past activity of the user, activity of other users (trends),
pro le setting of users mobile device, etc. Heavy processing, e.g. ltering images
with face detection algorithm, can be executed on the server, using MashReduce
programming model [
Di erent kinds of dependability mechanisms play an important role in a mashup. At least the mashup should be implemented so that it checks whether the input data is correct. More sophisticated mashups can have fall-back mechanisms that, instead just giving up on error, try to use next best strategy to ensure even partial functionality. Furthermore, mashups can have controlling mechanisms that supervise the functionality and replace failing parts with other ones. In addition, mashups can have capabilities to extract the result mashup to some external viewing device and change the user interface of the mashup accordingly. For instance, this enables the creation of a mashup in a mobile device whereas the resulting output can be shown on a bigger screen if one is available.
Since mashups by de nition combine data from multiple sources, the stakeholders that provide this data form an ecosystem, i.e. a set of entities that act as a single unit instead of each participating business acting separately. This ecosystem { formed by service providers, mashup authors, and users as visualized in Fig. 1 { need not be controlled by a central authority. In contrast, even though mashup authors and service providers may have an explicit service level agreements (SLA), it is common that mashups are developed without such contracts, and the ecosystem is formed implicitly. For instance, one can build a mashup on top of services freely available in the web with liberal enough licenses. In a broad sense, any web document author can be considered as a service provider, as it is common that content is gathered from web sites by technique called \screen scraping" or \web scraping", where source data is parsed from HTML pages aimed at human readers.
In the following we will rst provide some background information regarding mashup ecosystems, and then advance to some challenges associated with the establishment of new mashup ecosystems.
Yu and Woodard [
Bosch has reviewed mashup ecosystem from end-user programming point of
view [
Another interesting study is concerning the way a mashup ecosystem grows.
For instance, hypothesis in [
Service providers are crucial stakeholders in mashup ecosystems, as they provide the necessary content that is reused in mashups. There are numerous motives to allow liberal access to the content of a service. One rationale is a desire for getting a wider audience for certain platform, product, or content accessed through the service. Moreover, opening a service can lead to numerous clients created by third party developers to emerge on di erent platforms and for di erent user requirements. Some services are designed so that spreading advertising messages along with the content is possible.
Service providers support mashup ecosystems in four identi able levels, which are described in the following: 1. No support for mashups. Some web content authors do not support mashups at all and provide their content solely as regular web documents. This kind of content is still accessible with \screen scraping", but such accessing is typically error prone, and it often is illegitimate. Some services even have implemented technical measures to prevent scraping. Furthermore, even if reusing the content in mashups would be allowed, the web content author does not have control on what parts of the content is reused, and it is difcult to build a business model around such approach towards mashups. In addition, it is likely that accessing the content is very ine cient and cumbersome from mashup author's point of view. Furthermore, since even the smallest change in the web page can lead to a di erent interpretation of the content, mashups relying on such services are usually somewhat fragile. 2. Access through a web feed. It is common that regularly updated sites, such as blogs or news sites, provide their content through RSS, Atom, or other type of web feed. A web feed is easy to set up and maintain, particularly if some publishing system is used. The feed is intended mainly for users to subscribe with some feed reader application, but at the same time the data becomes accessible for mashups, too. While it is possible to establish some kind of licensing for reusing the content, the control over the content is still rather coarse. Use cases of web feeds are limited to accessing the content as a whole, as, for instance, querying certain content item is not possible. Utilizing web feeds in mashups is typically straightforward as helpful libraries and tools for such task are available on most platforms. Some dedicated mashup tools, Yahoo! Pipes (http://pipes.yahoo.com/) for instance, support only web feeds if content from an arbitrary service is desired to be included into a mashup. 3. Access through a web interface. Providing a service with a web interface, typically following either REST or SOAP architecture style, enables using the service in mashups. Use cases of such interface allows not just data accessing but other types of services as well. For instance, a service can provide means for social communication, authentication, database accessing, or specialized functions such as reverse geocoding or music identifying. Setting up a web service with REST or SOAP interface requires careful planning and implementation, especially if sensitive information is handled. However, such system allows ne-grained control over the content as well as applications using the interface, and it enables di erent kinds of business models. Service load can be handled as well by limiting requests made in a time period, even individually for each application. Utilizing well-designed web interfaces in mashups is straightforward, and maintaining e orts that are needed when the service is updated are typically trivial. Conveniently, the content can be provided in di erent formats for the mashup developers to choose from, for instance both JSON and XML formats are often supported. 4. Access through a programmatic interface. Establishing a programmatic JavaScript API allows to integrate the sevice tightly with arbitrary web applications and mashup ecosystems. Such interface is used by including a JavaScript library into the application, which makes it possible to use the service with regular JavaScript function calls. Typically the JavaScript library is downloaded from the service provider's server instead of having a copy on the server hosting the mashup, which makes possible to always use the most recent version of the library. Setting up a programmatic JavaScript interface requires careful engineering, but it enables superior control over the content and applications. Diverse business models are possible, and the content can be provided with di erent terms and licenses for individual clients. Program code of the JavaScript library is often protected against misuse by code obfuscation or by other technical means. Considerable downside of the programmatic interfaces is that updating the interface a ects directly on the mashup implementation. Therefore, programmatic interfaces are often provided in numerous versions, and a new version is introduced whenever features are added. Consequently, bug xes need to be performed on all the versions, which makes maintaining the interface more laborious. Another downside is that if a programmatic interface is desired to be used on other runtime environments than a web browser, a parallel version needs to be provided. For instance, Google Maps API (https://developers.google.com/maps/) has separate native SDKs for Android and iOS mobile operating systems, and used to have another version for Adobe Flash Player (http://www.adobe. com/products/flashplayer.html). The Flash version was deprecated in September, 2011.
The proliferation of programmatic interfaces is a step towards software
created from downloadable components, which is sometimes referred to as
mashware, web software development technique described in [
Until recently most of the services have been provided for free with the exception of some very specialized ones such as image content recognition services. However, in October 2011 Google announced that Google Maps API will be provided in two di erent versions: free and non-free, with the latter called Google Maps API for Business. The one with a prize tag provides more advantageous features such as higher request limitations and technical support. Even if this is the rst remarkable example of this kind of development, it is an interesting change, particularly when bearing in mind that the Google Maps is the most popular service used in mashups, and it is widely utilized in other types of web applications, too. Therefore, this development may indicate a beginning of a new kind of emerging business model.
Typically, mashups are build with combination of server- and client-side parts. Functionality between these two parts is divided according to what is suitable for the current design. In the early days, dynamic web sites were created on server-side with combination of C programs, Perl, and shell scripts using Common Gateway Interface (CGI). Today, server-side web applications are often developed with Java, server-side JavaScript, Perl, PHP, Python or other suitable language. Applications of this kind work especially well if the client device has low processing resources as heavy processing takes place at the server-end and the client just shows the result. As client-end terminals have become more capable, it has become possible to compose mashups where the business logic resides completely on the client-end.
While mashups can be constructed in numerous di erent ways with a plethora of tools, there still are major practical problems related to mashup composing and security. For instance, the web browser security model is too restricting for mashups, tools introduced are lacking behind, and using dynamic languages for large applications is an unknown territory for many developers. The eld of web programming is constantly changing as new interfaces, technologies and frameworks build upon novel technologies emerge constantly. The amount of di erent, constantly evolving APIs with di erent licenses is overwhelming. When developing large-scale mashups, situation may be even more problematic. Mashup authors build their applications on web services, and mashup users can add content to these services and consume it with mashups. Such ecosystem has commercial potential, which is, however, limited because of technical, legal and other reasons. Some of the issues are general for both mobile and desktop environment, but naturally mobile mashups have their own speci c things to handle as well.
While mobility restricts applications and application development, at the
same time it is a great enabler from the mashup development point of view.
The dynamic nature of mashups suits well for di erent ways mobile terminals
can be used. Often, the information needed on the y is related to user's
context, which can be available for applications to access automatically [
There are situations when the composition of a mashup is not possible using only dynamic code. For example, applications that require a lot of computation power or access to interfaces that are not available for dynamic code, have to be constructed with both dynamic and native code. Therefore, o ering an interface for mixing web technologies with the capabilities of native software components is sometimes necessary. On the other hand, utilizing hybrid technology allows one to combine the best of both worlds: performance and eye candy of traditional, installed binary applications and pervasiveness and seemingly in nite resources of the web.
In general, web interface legal terms and conditions are diverse. Commonly service providers set restrictions for those uploading content to the service, as well as those utilizing content of the sevice through an API, including mashup developers. In the following, some typical requirements and terms that a ect mashup development are described. { Service Level Agreements (SLA) are used to provide uptime guarantee or to state that the API has no liability for downtime or unexpected changes. Sometimes the latter is available for those who use the interface for free, and the former for paying customers. { If the interface allows accessing user created content under di erent licenses, terms of service (TOS) require developers to strictly follow those licenses. If the application uses a cache, also the cache needs to re ect changes in content's licenses and availability. Sometimes service terms determine time limits for the cache re ecting these changes. Moreover, caching may be forbidden completely. { If the interface enables accessing user's private data, TOS usually include restrictions about how this data can be used and stored. The service provider's logo or other branding needs to be explicitly available in the mashup. Other services require adding acknowledgements to application source code. Detailed terms on how the branding is presented may be represented. For instance, when using Google Maps, the terms of the Google Maps API require that the Google logo is the largest logo in the nal implementation (https:// developers.google.com/maps/terms). { Interface access rate can be limited to a certain amount of requests in a time period. For instance, Twitter limits unauthenticated calls to 150 requests per hour, whereas authorized calls are limited to 350 requests per hour (https: //dev.twitter.com/docs/rate-limiting). { Certain types of applications may be prohibited by the service provider. For instance, Flickr TOS deny using Flickr API for any application that replicates or attempts to replace the essential user experience of Flickr.com (http:// www.flickr.com/services/api/tos/). { Repeated violations of interface terms, for instance exceeding use rates or using the API in a forbidden type of an application, may make the service provider to terminate certain application from accessing the interface. Technically this can be achieved by restricting application IP addresses or application speci c API key from accessing the service. In practice, TOS often contain a clause for such situation, although we have no data how commonly the clause is exercised.
The above issues are further complicated by the fact that in many cases, mashup developers have not signed a formal contract with service providers, but rely on licenses. Consequently, as copyright owners and service providers can change licenses more liberally than signed contracts, developers may end up accidentally violating license rights overnight when the original service provider updates license terms.
Mashups can be classi ed based on numerous criteria, which in many ways affects the fashion the associated ecosystem can be established. One can classify mashups into breeds, such as server- and client-side mashups, and multiple and single API mashups. Moreover, mashup ecosystems can be classi ed into explicit and implicit ecosystems. The former includes commercial and enterprise mashups, and the latter includes situational mashups, as well as most mashups, that can be classi ed according to the most essential API used, establishing an ecosystem that is led by the provider of this API. In the following, mashup breeds and ecosystems are described in more detail and examples of di erent types of mashup ecosystems are presented.
Server- and client-side mashups. One way to classify mashups is division between server-side and client-side mashups, based on where downloading, processing and generating of the web content takes place. Server-side mashups application logic as well as accessing di erent web resources is implemented at the server-end. Client-side mashups are implemented completely on the client-end so that processing takes place at the user's web browser. Because of historical reasons, server-side approach has been more popular in the past, but as the processing power of web browser at the client-end has increased, client-side approach has become common as well. These two types of mashups have their advantages as well as disadvantages and suit for di erent situations, for instance a serverside mashup is not limited by browser's security model, the same origin policy, that isolates documents loaded from distinct origins from each other. Naturally hybrid approach combining server- and client-side mashup techniques is possible as well, and mashup developer can decide how to divide the functionality between the server and the client. If a mashup ecosystem consists of client-side mashups, it is necessary to pay more attention on how mashups can interact with services located at di erent origins. In addition, accessing speci c mashup clients may be di cult because of addressing issues in IPv4-based networks.
Multiple and single API mashups. Instead of combining content from multiple APIs, which is usually the case, some mashups are using only one single API to create new visualization for existing web services. Often the user interface of this kind of mashups is simpli ed and added with attractive properties of some kind. Another kind of single API mashups provide more advanced ways for searching than the original service. For instance, there are numerous mashups that show images retrieved from the popular image service Flickr. Another example of a single API mashup is WikiMindMap (http://www.wikimindmap.org/), which generates a mindmap about a keyword based on Wikipedia articles. Mashup ecosystems that consist of numerous single API type of mashups are usually build around the few most popular services of the web. Such ecosystems have emerged, for instance, around Google Maps, Flickr, Wikipedia and Twitter.
Commercial mashups. Commercial mashups are created to show a pro t for the mashup publisher where as non-commercial mashups are provided nonpro t. In commercial mashup ecosystems, mashup authors and service providers coordinate explicitly and use either speci c contracts or common TOS agreements. Commercial mashup ecosystem is required to implement reliable and secure methods to in order to transfer sensitive data. In addition, availability of services in the ecosystem in a commercial setting is naturally vital. A typical example of a commercial mashup combines information about the product being sold with user reviews from multiple sources. Another type of commercial mashups is those including advertisements. Commercial mashups are targeted at consumers in contrast to enterprise mashups that are targeted at business users, even though both are often created by a company. It is common that a commercial mashup is provided for mobile device users as an alternative user interface for an electronic commerce. Further examples of commercial mashups are price comparison and product search mashups. For instance, there are numerous mashups o ering this kind of service based on Amazon's and EBay's price data. Another kinds of commercial mashups help to locate a certain dealer on a map. An example of a commercial mashup combining social network services is Scupal (http://www.scupal.com/), a social buying website launched in India. Scupal allows users to select a product they would be willing to purchase, and then gather other interested buyers of the same product within their social networking contacts. The more there are buyers the less is the price.
Enterprise mashups. Enterprise mashups are developed to solve some particular business-related problem. In contrast to consumer mashups, that utilize only open web services, they can use closed enterprise data sources and combine the information with data from the web. Forming more closed ecosystem than the commercial mashup ecosystem, enterprise ecosystem is controlled by organization's internal interface speci cations and descriptions, in addition to usage of public web services available under common TOSs. Security features of an enterprise mashup ecosystem are crucial as sensitive data of an organization is often handled. For instance, storing the data should be done in controlled fashion within the organization's own storage facilities. Enterprise mashups can be created solely by the company's IT department or a sand-box environment may be provided for non-experts to create mashups. However, the more degree of freedom is allowed, the greater are the skills needed for mashup development. Typical to enterprise mashups is that they focus is on a single presentation and target at providing a tool to help collaboration with di erent people working with the same objective.
Reusing of existing mashup solutions is often in a key role in an enterprise mashup ecosystem. One activity that targets at such reuse is Enterprise Mashup Markup Language (EMML), which is a XML-based domain speci c language for developing enterprise mashups developed by the Open Mashup Alliance (OMA). With EMML, OMA aims at introducing a standardized, consistent and interoperable way to develop enterprise mashups. In addition to de ning the language, OMA provides a reference implementation of a runtime that processes mashup scripts written in EMML. EMML can be used to declaratively describe the data processing ow, i.e. data composing, of a mashup.
Situational mashups. Term situational application is used about an
application that is created for a narrow group of users with unique needs, and some
mashups are developed as situational applications. In Clay Shirky's essay
Situated Software [
The most essential API. One way to do the classi cation is to use the type of most essential API to determine the mashup type. For instance, a mashup can be classi ed as social, news, map, image, video, audio or search mashup based on the main service utilized. In consequence the ecosystem is build around this central service, and it can contain both implicit and explicit interactions. Often these mashups are targeted at consumers and provided for free, and therefore the implicit model is more common. Mashup statistics divided into categories based on the essential API used in a mashup can be collected from ProgrammableWeb site. The site provides statistics about mashups as well as service interfaces used to create new mashups. Only those mashups that are submitted to the website are listed, but the site can be used as a source for suggestive information about consumer mashups. However, the site does not list enterprise mashups at all. As can be seen in Fig. 2, mapping mashups are the most popular type of mashups. Social, search, photo, shopping and video mashups are roughly equally popular. In addition, remarkable number of mashups have been discontinued (tagged \deadpool").
In our research (see e.g. [
Cloud Infrastructure. Cloud infrastructure related issues refer to addressability of mashup ecosystem endpoints as well as transparency and protocol support of network. Before IPv6 gains ground it might be necessary to use higher level methods to address network endpoints. Addressing mashup clients and services at too high level can derive scalability and performance issues. Another problem is caused by non-transparent network nodes that may cause some parts of the ecosystem become unattainable. Furthermore, lack of protocol support for other than HTTP can cause for instance video and audio streams fail to operate.
Web services. Web service reliability and complexity of integrating a high number of services are another type of challenges. Web service reliability can be addressed by adding fallback mechanisms, but this strategy will make the implementation more complex. While adding more services to the mashup can be attractive for users it makes the implementation more complex and increases vulnerability to service breakouts and incompatible version upgrades, which plague especially mashups that reuse services anonymously without explicit contracts. Furthermore, client-end device capabilities may be limited and operational expenses can be an issue, especially with mobile devices.
Legal issues. Moreover, legal issues related to mashup ecosystem are numerous. Service terms are often incompatible and hard to follow in complex mashups. The situation is even more complex when a mashup is hosted on third party platform, such as mashup tool providers servers. Mashups can be required to follow some content related limitations as well. For instance, some content can be freely available in U.S. but restricted from accessing in U.K. Some service providers may restrict their interfaces to be used only on desktop and prohibit using them on mobile devices. In addition, libraries and frameworks used in mashups may have con icting licenses. Furthermore, protecting a clientside mashup from copying is often di cult as the executable code needs to be transferred to the client-end terminal.
Tools. Mashups can be developed with conventional web programming
techniques using text editor and environment with debugging capabilities [
Web-based software and services have become commonplace. As virtually all
imaginable content and services are becoming available online, there will be
new, optimized ways to consume content and access services. In this paper, we
have argued that mashups { special kinds of web applications that combine
data and services from numerous sites { enables the development of new,
improved applications that enrich the basic online facilities. A dimension that has
been commonly overlooked with mashups is that they are not only about the
technology, but their development and use is governed by other factors as well.
Consequently the elements of opportunistic design { hacking, mashing and
gluing, as pointed out in [
Service interfaces are integral part of mashup ecosystems, and we indenti ed
four levels of support that service providers can o er for mashups. We believe
that the success of programmatic JavaScript interfaces is one indicator of the
trend towards mashware ecosystems { software ecosystems that leverage source
code and software components that are downloaded dynamically from all over the
world. As pointed out in [
In the future, we expect that the multifaceted nature of mashups will lead to increasing interest also on the research side. So far, such applications, as well as associated ecosystems, have gained relatively little attention from researchers. Consequently, there are numerous directions for future work, where the main development principles of mashups in general as well as associated business impacts are analyzed in more detail.