A Cloud-based Platform for Enterprise Mashup Ecosystems

Michele Stecca

Computer Platform Research Center (CIPI)

c/o DEI University of Padova

Via Gradenigo 6A, 35131 Padova

e-mail: m.stecca@cipi.unige.it

Massimo Maresca

Computer Platform Research Center (CIPI)

c/o DEI University of Padova

Via Gradenigo 6A, 35131 Padova

e-mail: m.maresca@cipi.unige.it

Abstract – In the last years we witnessed a proliferation of the

Web APIs (Application Programming Interfaces) provided by

Web companies such as eBay, Amazon, Google, Yahoo,

Facebook, Twitter, etc. in order to ‘open’ their platforms to

3rd party developers to increase revenues. These APIs can be

combined together to create new value added services called

Mashups. In this paper we propose a classification of some

Mashup types and then we show through examples how they

can be applied to different application domains. The paper also

describes a platform for Mashup creation and execution

according to the Platform as a Service – PaaS Cloud

Computing paradigm. Finally we describe a ‘Mashup

Ecosystem’ enabled by such a platform and inspired by the

Apple Store case study.

Keywords: Mashup; Ecosystem; PaaS; Cloud; Enterprise

I. INTRODUCTION

In these last years the Internet has gradually evolved from an information repository to a service repository (a.k.a., Internet of Services). In the traditional scenario, companies provide information (e.g., documents, maps, news) to customers and users through web sites. Today a growing number of companies is migrating to the service scenario in the sense that expose Application Programming Interfaces (APIs) which can be used by other companies (usually called 3rd Parties) to create new value added services, or composite services, a.k.a. Mashups [1]. A consequence of such an evolution is the proliferation of the open APIs available over the Internet (see the programmableweb.com portal for a list of more than 3200 APIs). Meanwhile the Cloud Computing paradigm [2] is gaining momentum. According to the NIST definition [2], “Cloud computing is a model for enabling convenient, on demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”. This general definition effectively reflects the different facets of the Cloud Computing paradigm which can be found at different infrastructure levels. It is possible to identify three Cloud Service Models, namely the Infrastructure as a Service (IaaS) model, i.e., the rental of storage, processing, network, and other fundamental resources (e.g., Amazon EC2 [3]), the Platform as a Service (PaaS) model, i.e., the deployment of customer-created applications in a Cloud platform (e.g., Google Application Engine [4]), and the Software as a Service (SaaS) model, i.e.,

the usage of provider's applications over the network (e.g., the Customer Relationship Management system by Salesforce [5]). The Mashup world and the Cloud Computing world are strictly related as the services composed in Mashups very often follow the SaaS model and, more in general, rely on Cloud systems. Moreover the Mashup platforms can be implemented according to the PaaS paradigm in the sense that Mashup developers can deploy their own Mashups – implemented client side – in the Cloud. In this way developers can rely on of the advantages brought by the Cloud Computing paradigm, in particular the pay-per-use accounting scheme, the elasticity, the reduction of CAPEX vs. OPEX, etc. IBM Mashup Center [6], RunMyProcess [7], and JackBe Enterprise Mashup Server [8] are examples of products that are already following this philosophy.

The simultaneous evolution of distributed applications toward the service paradigm and of computing toward the Cloud Computing paradigm has opened a new market for service delivery platforms, which can be now dematerialized “in the cloud”, and has laid the ground for the rise of innovative business models in which service developers, Mashup developers and platform operators cooperate to provide solutions for end-users.

In this paper we analyze these two issues. We start from the analysis of Mashups in general, focusing on a particular category of Mashups, that we call Event Mashup, that combine events rather than data (Section II). Then we describe the requirements and the organization of a platform that supports the execution of Event Mashups in the Cloud (Section III) and describe a business ecosystem enabled the technical approach proposed (Section IV). Before providing some concluding remarks (Section VI), we compare the proposed solution with other Mashup platforms (Section V).

II. MASHUPS

A. Mashup Types

A Mashup is a composite application that combines functionalities (e.g., APIs) and contents (e.g., RSS Feeds), provided by utilizing a variety of sources and technologies. A number of tools and models have been proposed to support Mashup development by means of graphical interfaces, allowing end users to create Mashups even without specific programming skills. Very often these tools provide a set of basic blocks corresponding to “mashable/composable” services. A basic block is defined

2011 IEEE Conference on Commerce and Enterprise Computing

978-0-7695-4535-6/11 $26.00 © 2011 IEEE

DOI 10.1109/CEC.2011.44

244

by means of a set of actions (i.e., the functionalities provided by a basic service), a set of events (i.e., the state changes that occur during the base service execution), and a set of input/output properties. The Mashup logic is entered by linking together these basic blocks according to the “event/action” paradigm in which an event occurred inside a base service triggers the execution of an action in one or more base services. Some examples are shown in Figure 1 and Figure 2.

The base services currently available over the Internet can be classified as Monitoring Services (e.g., Monitor Mail, Monitor RSS Feed, etc.), Notification Services (e.g., Send SMS, Make Phone Call, etc.), Presence Services (e.g., GTalk), Location Svc (e.g., Yahoo! Fireeagle), Maps Svcs (e.g., Google Maps), etc. The combination of these base service enables the creation of the following “Mashup types” (see [9] for more details on base service and Mashup classification):

• Event Mashup: It combines different sources of

information such as RSS Feed, Social Networks,

Government Web Sites, e-Commerce Web Sites, etc.

with different notification channels like SMS, e-mail,

Social Networks, etc. This Mashup type is described in

details in Section B;

• Resource Monitoring, Processing and Map visualization

Mashup: It represents the typical Web Mashup pattern

in which some information elements are shown on a

Map. For instance, whenever a new event is published

on the Facebook account of a user’s friend, the Mashup

visualizes the location of that event (Monitor Facebook

Events Svc + Google Maps Svc) on Google Map;

• Data Aggregator Mashup (a.k.a., Data Mashup): It

aggregates elements retrieved from different sources to

merge them together to create new contents. It is useful

when different public sources must be merged (e.g.,

news about the same topic from different newspapers, or

a set of significant events - e.g. “all the jazz concerts”-

from different cities, etc.) or when a heterogeneous set

of information elements must be merged (e.g., company

fusions, data migrations, etc.).

These Mashup types can be applied to different application

domains such as e-Government (see [9]), e-commerce, and

Enterprises (see Table I).

B. Event Mashups

Figure 1. Event Mashup

The Event Mashups are those of particular interest in

this paper, as they correspond to distributed applications not

relying on the existence of a central coordination system.

Such a paradigm well matches most of distributed

information system interactions, in which local state change

taking place in information system components are

supposed to cause the execution of actions in other

information system components. An Event Mashup, shown in Figure 1, interconnects

different sources of information to different notification channels. The base services are not just remote procedures or Web Services called by other software components. On the contrary they are live components that detect state changes in their domains (for example a base service may detect the arrival of a plane, or the update of an item in a repository) and issue events accordingly. The event paradigm can be used to create at least three classes of Event Mashups, namely: 1. “Reminder” Mashups, such as for example:

• Tax Payments Deadline reminder: The day before the submission deadline, send an SMS (or any other kind of notification) to the people who are supposed to pay a certain tax (Monitor Tax Payments Deadline Svc + Send SMS Svc);

• Appointment reminder: Check the date of a specific appointment on your Google Calendar and send an SMS (or any other kind of notification) the day before that date (Monitor Google Calendar Svc + Send SMS Svc).

2. “Alert” Mashups, such as for example :

• Public Transportation Delay Alert: Monitor the progress of a train trip and send an SMS in case of delay (Monitor Train Delay Svc + Send SMS Svc);

• Public School Closing/Delay Alert: Provide updates about unscheduled public school closings, delays and early dismissals (Monitor Public School RSS Feed Svc + Send SMS Svc);

3. “Automatic notification of significant events” Mashups, such as for example:

• Research Project funding: If the Government web site publishes a news item related to the funding of a research project then the Mashup automatically shares the link of the news on the user’s Facebook page (Monitor RSS Feed + Share link on Facebook Svc);

• Public Events publication in social communities by Facebook friend: If one of the friends of a Facebook subscriber publishes an Event related to a rock group concert, the subscriber is notified through an SMS (Monitor Facebook Events Svc + Send SMS Svc).

Figure 2. Event Mashup enriched with notification channel selection

245

TABLE I MASHUP TYPES APPLIED TO E-GOV, E-COMMERCE, and ENTERPRISE

e-Government e-Commerce Enterprise

Event Mashup

Monitor Twitter Account Svc

+ Google Calendar Svc.

If the Government publishes

a tweet on Twitter related to

a new auction for a house

then the Mashup

automatically updates the

Google Calendar application

of the user by adding a new

“Auction Event” to it.

The MonitorEbay Svc + SendSMS Svc Mashup keeps monitoring if a specific good is added to eBay catalog and notifies it via SMS as soon as it is made available.

The Monitor CRM Orders

Svc + Send Priority eMail

Svc Mashup keeps

monitoring the orders

associated to a specific

customer and sends a

priority e-mail as soon as a

new order is registered in the

CRM system.

Map Visualization Mashup

The RetrieveTrainPosition

Svc + Google Maps Svc

Mashup displays the

positions of the trains of the

London’s underground in

real time.

The YellowPagesQuery Svc

+ CalcDistFromHome Svc +

Conditional Svc + Google

Maps Svc Mashup searches

for a Shoes Shop in the

Yellow Pages system and

displays on a Google Map

all the shops “close” to the

home address of the user.

The Retrieve Customer

Address Svc + Google Maps

Svc Mashup retrieves the

address of a specific

customer from the CRM

system and shows it on a

Google Map.

Data Mashup

The USOpenData Svc +

ItalyOpenData Svc +

GermanyOpenData Svc

Mashup compares between

production and consumption

of coal, electricity, gas, and

oil in different countries

which leads to interesting

results both from an

economical point of view

and from an environmental

point of view.

The RetrievePricesForItem

Svc + SortValues Svc +

SaveMSExcelSpreadsheet

Svc Mashup retrieves a set of

prices for the same item

from different e-commerce

Web Sites, sorts the prices

(e.g., ascending order), and

saves the sorted list in a

spreadsheet.

The Import Data From

MSExcel Svc + Import Data

From MSAccess Svc +

Merge Data Svc + Save CSV

File Svc Mashup translates

the different formats in a

common “internal” format

and checks the compatibility

of the inputs. Finally it

merges the input data and

saves them in a CSV file.

Event Mashups can be enriched with the capability to

select the communication channel along with the notification is to be sent. Examples of such a behavior include “Time Dependent Notification”, Location Dependent Notification” and “Presence Dependent Notification”.

Figure 2 shows an example of an Event Mashup enriched with notification channel selection. Its semantics can be expressed as follows:

• Keep Monitoring an RSS Feed provided by the Government that reports the town criminal actions within the last 24 hours;

• As soon as this information is retrieved trigger the “get time of the day” Svc which retrieves the current time;

• Inform the user as follows: In work hours Send an SMS otherwise invoke a text to speech call Svc and Call.

This example allows to personalize the Notification

Channel based on the hour of the day.

III. MASHUP EXECUTION PLATFORM

A. The Event Mashup lifecycle

Event Mashups may run as services in a Service

Platform, which must support the creation, the deployment,

the activation, the execution and the management of Event

Mashups. Mashup Creation: The Mashup creator takes advantage

of a graphical tool called Service Creation Platform (SCP), sketched in Figure 3, that allows creating a Mashup by dragging and dropping blocks corresponding to elementary services and by drawing edges corresponding to events issued and actions invoked. Each service is associated to a set of input properties the values of which, possibly combined with data coming from external data sources or services with which the Svc interacts directly, produce a set of output properties. An event notification originating at the beginning of an edge corresponds to the invocation of an action in the service located at the edge termination. If needed, the output properties of the service that notifies the event are copied to the input properties of the services in which actions are invoked. For example, the leftmost service

246

in Figure 3 is associated to the Mail Monitor service, defined through a of a set of input properties (i.e., User Id, User Password, Sender Address Filter, Email Subject Filter), one output property (i.e., Received Email Content), one action (i.e., Start Monitoring) and two events (i.e., Authentication Failed and Mail Received). As soon as the Mail Monitor service is activated by means of the Start Monitoring action invocation, the service starts monitoring the e-mail inbox of the user identified by the User Id property. Every time a new e-mail massage matching the filters (e.g., Subject and Sender) is received, the service issues a new Mail Received event. This service can be combined with other highly reusable modules to create a Mashup. In Figure 3 the Mail Received event triggers the Make TTS Call action of a Text To Speech Call Service that has been linked in cascade of the Mail Monitor Svc. This simple Event Mashup can be used, for example, when one wants to receive a phone call at any time a specific e-mail is received (the Text to Speech service will read the body of the e-mail to the callee).

Figure 3. An Event Mashup as it appear in the SCP

Event Mashup Deployment: The new Mashup created by

means of the SCP is saved as an XML file and deployed in

the SEP. New Mashups can be deployed into SEP according

to the PaaS paradigm (see Section C) to make them usable

by Mashup users. The Container provides a deployment

module that supports the friendly deployment of new

Mashups into the SEP. In fact the Deployer Module of the

platform provides also the Svc Deployment functionality as

explained in Section C.

Mashup Activation/Execution: An end-user that intends

to use an Event Mashup must first provide the configuration

data and then activates the Mashup. Mashup Activation

corresponds to a pre-configuration of the Mashup which,

from then on, is ready to be executed at the occurrence of

the External Events that it is configured and that it is

waiting for. Actual Mashup execution, or more precisely a

Mashup execution instance called Session, takes place in a

component of the Service Platform named Service

Execution Platform (SEP) when the expected initial event

configured at activation is received.

For example, the Activation of a Mashup including the

Mail Monitor service and the TTS Mashup causes the

configuration of the Mail Monitor Service through

appropriate configuration properties (e.g., the destination

address, a keyword in the subject or in the text, etc.). Then

the reception of an e-mail message matching the above

properties trigger the Mashup execution start.

Mashup Management: The platform provides some

mechanisms to support Mashup management. Security,

probably the most important issue, is intended in the

following two ways. The first is related to the protection of

the system from external malicious service providers while

the second is related to the management of the user roles.

This is very important in Enterprise Mashups in which

different employees (or users) probably have different

access to company data. Another important management

issue lies in the monitoring of Mashup usage, service usage,

resource usage, etc. The SEP provides a set of statistics that

allow the administrator to have a clear picture of what is

happening inside the platform. Finally, the SEP supports

some Service Level Agreement – SLA functionalities to

support the guaranteeing different service levels to different

users.

B. Mashup Orchestration in the Cloud

Client Side vs. Server Side execution A Mashup is called a “Client Side Mashup”, when its

execution takes place within a client platform such as a browser, while it is called a “Server Side Mashup ”, when its execution takes place in an external SEP. We focus on the this latter case which exhibits the following distinctive features: a) Support for Long Running Mashup Execution: While

Client-Side Mashups typically exhibit short processing times and run under direct control by a user, Server-Side Mashups are typically characterized by long processing times and require no direct control by a user. Server-Side platforms enable permanently active ‘demons’ in Event Mashups’ logic (e.g. a GMail Monitor Svc monitors a Gmail inbox and issues a new event when an e-mail matching a given filter is received).

b) Reduction of User Terminal power consumption: The presence of Monitoring Svcs – Monitor RSS Feed, Monitor e-mail inbox or other – that leverage polling mechanisms may affect the Client-Side Mashup performance (e.g. running on a smartphone) in terms of user terminal battery life as proved in a study by Ericsson Labs

1.

c) Compensation of User Terminal’s disconnection from a Network: Mobile terminals access the Internet via a 2.5/3/4 Generation Network which may be unreachable due to connectivity problems or the terminal is switched-off (e.g. a dead battery or a user is on a plane is unable to use their smartphone). Thus, it can be stated, that if one wants Mashups to keep running even when a user terminal is disconnected from its network, one must follow the Server-Side approach.

1

https://labs.ericsson.com/apis/mobile-java-push/blog/save-device-

battery-mobile-java-push

247

d) Privacy Protection: While Client-Side Mashups receive and process raw content from content providers in an external and uncontrolled location; in Server-Side Mashups, content combination occurs in a protected environment (i.e. a Server-Side Mashup execution platform). For example, when a Mashup combines contents protected by a privacy policy – hospital patient information, government-citizen information, company customer information – privacy policy enforcement becomes a priority.

e) System Protection: While Client-Side Mashups freely access content/service provider platforms to retrieve content and/or to activate services and as a consequence exhibit no protection against attacks; Server-Side Mashups protect both platforms by interposing a processing layer that inspects, authorizes or blocks content/service requests.

A Server Side Platform

A Server Side Service Execution Platform (SEP) can be

located “in the Cloud” and operated and managed by a platform provider, according to the PaaS paradigm. That leads to the following benefits:

• Reduction of Capital Expenditure (CAPEX): Cloud Computing allows for the relocation of in-house IT infrastructures (or part of them) to remote data centers, thus reducing the investments in machinery and software;

• Limitation of Operation Expenditure (OPEX): The adoption of the Cloud Computing paradigm allows for the application of the pay-per-use based accounting model. In addition the concentration of applications enables the optimization of computing/networking infrastructures due to resource sharing;

• Service Time to Market reduction: Rapid resource provisioning allows Cloud Computing users to move from prototype systems to production system, and as a consequence to business development, very quickly;

• Power consumption limitation (‘Green’ approach):. Cloud Computing infrastructures are deployed in large-scale data-centers seen as an ‘optimized aggregation’ of many other data centers. This aggregation leads to power consumption savings thanks to hardware sharing.

With specific reference to the Mashup Service Execution

Platform, another advantage brought by the PaaS paradigm is the possibility to create a sort of “gallery” of the Event Mashups available to end users.

If follows that we are describing an “ecosystem” in which a Cloud company provides a Platform as a Service (PaaS) system (i.e., the SEP which is in charge of executing services) in which the users can deploy Mashups developed by means of a SCP. Similar approaches, proposed by IBM [6], JackBe [8], and RunMyProcess [7], are referred in the literature as CaaS – Composition as a Service [10].

C. Platform as a Service Architecture

Platform Components

The presence of heterogeneous technologies such as

SOAP, REST, etc. and different data formats such as XML, JSON, RSS Feed, etc. to interact with Base Services requires the introduction of a Service Proxy (SP), a component that wraps the external functionality/content to make it “mashable”. On the Mashup side each SP exposes a standard interface to the Mashup Orchestrator (see red/green arrows in Figure 4) while on the external side each SP interacts with the external world by means of the technology dictated by the External Services (ES) (see dashed arrows in Figure 4). In this way the Orchestrator becomes protocol-agnostic in the sense that it composes any kind of service/data regardless the technology used to access the base services (SOAP, RESTful, proprietary, etc.). SPs are developed as computer programs by skilled programmers (e.g., the IT employees of a company) who can rely on both the automatic software generating tools (e.g., in case of a WSDL file is provided) and on human readable descriptions (e.g., in case of RESTful services).

Figure 4. The high level architecture of the SEP

Figure 4 shows the high level architecture of the SEP that we designed and implemented as a prototype. The main components of the SEP are:

• The Service Proxy (SP): The SPs represent the high reusable blocks that allow easy and quick Mashup development. The set of available SPs in the SEP is not fixed because Mashup developers might need to add new basics functionalities to be embedded into composite services (e.g., a new service available on the Web). In order to support the inclusion of new base services the SEP must support also friendly Service Deployment. The creation of new SPs must be regarded as a platform upgrade.

• The Orchestrator: At deployment time, the logic of the Mashup is translated into a data structure called Routing Table (RT) which is loaded into the Orchestrator. As soon as a SP notifies an event to the Orchestrator, the Orchestrator retrieves the next SP(s) to be invoked from the RT (for details see [11]).

248

• Communication Interface: The software interfaces exposed by the SEP is the following:

o invokeAction primitive: used by the Orchestrator to issue the activation commands in SPs at run-time;

o notifyEvent primitive: used by SPs to notify events (i.e., their internal state changes) at run-time.

This interface is the only mandatory constraint that must be taken into account by a developer who wants to include a new SP in the SEP in order to extend the set of available base services.

The components of the Deployer Module

The Deployer Module manages the installation of new

components in the SEP. It consists of two sub-modules, namely:

• The Mashup Deployer: this sub-module performs the operations related to Mashup Deployment, i.e., it takes an XML file containing the Mashup logic as an input, translates such a file into a Routing Table and finally passes such a table to the Orchestrator;

• The Service Deployer: this sub-module performs the operations related to the Service Deployment phase, i.e., it takes a Java Archive - JAR file containing the implementation of the new SP as an input, loads the classes contained in the JAR file into the JVM and updates the list of the available base services.

It is worth noticing that while the Mashup Deployer simply invokes a Java method containing the operations to be performed (i.e., the parsing of the XML file representing the Mashup to be deployed), the Service Deployer must support the injection of new classes into the JVM running the container through the JVM class loading system.

IV. BUSINESS ISSUES IN MASHUP ECOSYSTEMS

In this Section we analyze the business issues related to a possible scenario enabled by the PaaS platform described in this paper. We start describing the four different types of actors interacting in such a “Mashup Ecosystem”:

• PaaS Provider. The actor providing and operating the

whole platform.

• Service creator. The actor who implements a new

Service, i.e. a ‘mashable’ part, according to the

interfaces defined in Section III.C. This role is usually

for a software company, a.k.a. 3rd Party, as new

Service creation requires strong programming skills.

• Mashup creator. The actor who creates new Mashups

by means of the Service Creation Platform. This role

can be filled by both a company, a.k.a. 3rd Party, and

an end user capable of creating new services by means

of a graphical editor. This class of end users is called

‘active users’.

• The Mashup user. The actor who uses the Mashups.

This role is usually undertaken by a class of end users

called ‘passive users’.

The term “ecosystem” refers to a scenario in which these actors interact to establish innovative value chains, different from the traditional ones where the money spent by end users for services goes directly to the service providers. In this ecosystem a new kind of actors called 3rd Parties take advantage of a SEP operated by PaaS providers to develop services for end users. The revenues can be shared by the PaaS Providers and by the 3rd Parties. The most interesting example of 3rd Party involvement is perhaps that of the Apple Store in which the end users buy personal iPhone applications without involving the Telecom Operators in the value chain. In addition to bypassing the Telecom Operators Apple has introduced a new business model based on the opening of its own platform to 3rd Parties, to increase the number of iPhone applications. The revenues of application sales are shared by Apple (30%) and by the individual application developers (70%)

2.

Table II provides a rough economical analysis of an hypothetical ecosystem enabled by the platform described in this paper. The identification of a realistic application scenario should be based on the identification of a target user base. Unfortunately, it is difficult to estimate the size of such a target user base mainly because Mashups represent an innovative class of services based on an innovative fruition model for which it is not easy to forecast the degree of success.

The first question to be faced is concerned with the identification of the number of the potential users. We might take as a starting point the total number of mobile telephone subscribers, but such a number is very large and might so lead to an optimistic forecast. It is true, on the other side, that not all mobile telephone subscribers are oriented to the adoption of innovative services like those provided by Mashups. The problem is therefore to identify a class of existing services and technologies that can be considered similar to the class of Mashups, so that it is possible to take the size of the user base of such existing services and technologies as a starting point for the estimation of the number of the platform potential users.

The technology taken as a reference is that of Widgets3

and the number of the Mashup potential users is considered equivalent to that of the Widget user base. Although this equivalence might lead to an underestimation of the user base size, mainly because the Widget technology and services are at an early stage of diffusion, that is the choice. The Widget user base corresponds to two per cent of the broadband Internet user base. We start from such a figure. We take Italy as a reference case, considering that Italy is an example of a European country of about 60 million people, of the same order of magnitude as Spain, France, Great Britain and Germany. The number of potential Mashup users in Italy, considered equivalent to that of the Widget users, is about 300,000.

In the following simulation we envision two types of revenues, namely direct revenues (i.e., end users are charged

2 http://developer.apple.com/programs/ios/distribute.html

3 http://www.w3.org/2008/webapps/wiki/WidgetSpecs

249

TABLE II SUMMARY OF THE NUMERICAL SIMULATION FOR THE ‘MASHUP ECOSYSTEM’

Users base 300,000

Specific Mashups’ users base

Flat Fee % 5-10 7.5

Single Event Fee % 8-12 10.00

Service Prices

Flat fee EUR 5 to 10 7.50

Single event pricing EUR 1 to 2 1.5

Events per month 2 to 3 2.50

Advertising

CPM per banner 1.00

Accesses or executions per day and user 1.00

Revenues

Flat fee EUR 2,025,000

Single event EUR 1,350,000

Advertising EUR 109,500

Total sales EUR 3,484,500

Revenue sharing with Svc providers % 70

Percentage of Svc provided by 3rd

Parties % 40

3rd

Party Revenue EUR 975,660

for Mashup usage) and indirect revenues (e.g., revenue coming from advertisement).

Now the point is how many Mashups will be actually purchased by potential users. We made the assumption that a fraction of about 7.5% of the Mashup potential users will be available to pay a monthly fee of 7.5 € to subscribe to flat fee Mashups and about 10% of the Mashups potential users will be available to pay a 0.75 € fee for a single service 2.5 times a month.

The total annual revenues deriving from flat fee sales is given by the following formula:

Flat Fee Revenue =

Users Base x

Flat Fee Users Base % x

Flat Fee Month Price x

12

while the total revenues deriving from single service sales is

given by the following formula:

Single Event Revenue =

Users Base x

Single Event Users Base % x

Single Event Price x

Events per Month x

12

The total revenues deriving from flat fee sales and single

service sales amount to €3,375,000 according to the hypotheses made.

As far as the indirect revenue is concerned, we make the assumption that the CPM (Cost per Impression, i.e. the cost for displaying a banner 1000 times) related to a single banner is equal to €1 and that each user will make an access every

250

day on average. The total annual revenues deriving from advertisement is given by the following formula:

ADV Revenue = (CPM x Users Base x Visits per Day) / 1000

This leads to an indirect revenue of €109,500. Now the point is to estimate what fraction of these

revenues may be attributed to 3rd Parties. Again we need to identify a class of services and technologies similar to Mashups to partition the estimated revenues among PaaS Providers and 3rd Parties. Such a similar class of technologies and services, which is taken as a reference, is that of the AppStore services. In that case the revenues are shared as follows: 30 per cent to the platform operator and 70 per cent to the 3rd Parties.

Finally the fraction of the number of Base Services coming from 3rd Party over the total must be estimated. We used a value of 40 per cent.

If we apply such percentages to our estimations, we end up forecasting a total revenue for 3rd Parties equal to 975,660 euros.

V. RELATED WORK

In recent years, many Mashup tools coming from both the

academic and industrial communities have been proposed. IBM provides a platform called Mashup Center allowing

users to create Client-Side Mashups where the emphasis lies on a combination of different ‘presentation services,’ or user interface components, called Widgets. A Widget is a small application or a piece of dynamic content that can be easily placed into a web page. Yahoo!Pipes

4 is a well-known

graphical tool facilitating processing and a combining of multiple sources. By means of this tool a Mashup creator can implement data processing pipelines where different data sources – RSS Feed, Atom, and XML sources – are combined with filters – sorting, filtering, counting, regular expressions – to create new content issued as RSS Feeds. Apatar

5 is another data-oriented Mashup tool providing a

graphical environment for data manipulation. JackBe, a company targeting the Enterprise Mashup domain (i.e., composite services mixing the private data/functionalities of companies with the public data/functionalities available on the Web), supports Mashup creation and execution through Presto. Presto includes a graphical editor in which basic functionalities represented as blocks, can be linked through edges to create Mashups. Its Mashup structure is saved in an XML language called Enterprise Mashup Markup Language, EMML, specifically designed for the development, interoperability and compatibility of Enterprise Mashup and supported by the Open Mashup Alliance

6. For Mashup

execution Presto includes an orchestration engine based on Apache Tomcat technology. JackBe Presto is also available according to the PaaS paradigm in order to exploit the

4 http://pipes.yahoo.com

5 http://www.apatar.com

6 http://www.openmashup.org

advantages described in Section III.B. Moreover, the PaaS platform acts like a “central repository” where different users can share the developed Mashups fostering re-usability. RunMyProcess is another product available as a PaaS system. Jack Presto and RunMyProcess both differ from the proposed solution because they don’t provide native support to Event Mashups (e.g., the JackBe Presto platform allows the programmatic creation of event queues through an additional component called “Event Connector”) while the other tools don’t target the enterprise domain.

VI. CONCLUSIONS

In this paper we discussed how the Mashup and the Cloud Computing technologies might be used to foster the implementation, the reuse, and the effective execution of value added services belonging to different application domains. Examples of such application domains are e-Government, e-Commerce, and Enterprise. The first contribution is the definition of a set of ‘Mashup Types’. The three categories identified cover a large number of real life applications like reminders, alerts, time dependant notifications, maps, data manipulations, etc. The second contribution is the description of the architecture of a platform supporting the deployment and the execution of Mashups according to the PaaS Cloud Computing paradigm. The last contribution is the analysis of a ‘Mashup ecosystem’ involving PaaS providers, Mashup developers, Base Service developers and end users.

REFERENCES

[1] Koschmider A. et. all, "Elucidating the Mashup Hype: Definition,

Challenges, Methodical Guide and Tools for Mashups", Proceeding of "2nd Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009)", April 2009

[2] Mell P. and Grance T., “The NIST Definition of Cloud Computing”, NIST Report, July 2009.

[3] Amazon EC2 http://aws.amazon.com/ec2/

[4] Google App Engine, http://code.google.com/intl/en/appengine/

[5] Saleforce CRM, http://www.salesforce.com/crm/products.jsp

[6] IBM Mashup Center, http://www-01.ibm.com/software/info/mashup-center/

[7] RunMyProcess, http://www.runmyprocess.com/

[8] Jack Be Presto, http://www.jackbe.com

[9] Stecca M., Maresca M., “Mashup Patterns applied to e-Government”, Journal of Internet Business, Issue 8 (2010) Pages: 81-108.

[10] M. Brian Blake, Wei Tan, and Florian Rosenberg, “Composition as a Service”, IEEE Internet Computing 14, 1 (January 2010), 78-82. DOI=10.1109/MIC.2010.2 http://dx.doi.org/10.1109/MIC.2010.2

[11] Stecca M.; Maresca M., An execution platform for event driven mashups, International Conference on Information Integration and web-based Applications and Services. Proceedings of the 11th International Conference on Information Integration and Web-based Applications & Services, Kuala Lumpur, Malaysia, Pages: 33-40, Year of Publication: 2009

251