GET READY FOR MASHABILITY!

Concepts for Web 2.0 Service Integration

Pavel Drášil, Tomáš Pitner

Masaryk University, Faculty of Informatics, Botanická 68a, 602 00 Brno, Czech Republic

Thorsten Hampel, Marc Steinbring

Department of Knowledge and Business Engineering, University of Vienna, Rathausstr. 19/9, A-1010 Vienna, Austria

Keywords: Web 2.0, Service Classification, Mashup, Business Models, License Agreements.

Abstract: Mashups represent – beside the ease-of-use, high interactivity and social networking factors – another

significant phenomenon of Web 2.0. However, this "mashing process" is mostly based upon ad-hoc

approaches and techniques, rather than upon an in-depth analysis of the "mashing potential" of the services.

Therefore, the first goal of this paper is to provide a conceptual foundation for the mashups – to identify

services being typically integrated into mashups, and propose classification criteria forming a "Mash-Tree"

that were subsequently applied to selected services – representatives of each classification category. We

concentrate mainly on mashing of Web 2.0 services; integration in an enterprise environment is behind the

scope of this paper. Secondly, the mashing potential is studied from three perspectives – technical aspects of

mashability, business models for mashups, and potential legal issues concerning services themselves as well

as the data in them. We hope that the proposed mashup conceptualization together with our analysis of

mashability can help to develop future Web 2.0 mashups that not only better meet stakeholders' expectations

but also respect legal terms and are technologically sound.

1 INTRODUCTION

Although these days the buzzwords “web 2.0” and

“mashup” have become an important topic of

conversation – backed up by many successful

applications, it is hard to find a clear and concise

definition of the latter term. While the term “web

2.0” a.k.a “new net” per se has already been defined

and discussed since the groundbreaking article by

tim o’reilly was published in 2005 (o’reilly, 2005),

the question of what a “mashup” service actually is

remains. What are the underlying services being

“mashed-up”? What are the main factors for a

successful development of mashups? How do they

differ from conventional solutions? And above all,

do they keep their promise to be a flexible service by

communicating via open and usable application

interfaces? Based on a closer research of particular

mashups and services, this article analyses key

elements for a progressive deployment of services in

the new web.

Web services are probably the most widespread

application of the Service Oriented Architectures

(SOA) concept (Alonso et al, 2004). On one hand

they concentrate on building the service-oriented

application architecture using a set of individual

services. At the same time they take advantage of

standardized protocols, formats and interfaces for

communication and information exchange.

There are two substantial new developments

which form an important basis for the idea of service

oriented infrastructures, namely the ability of

services to be self-described using semantic

techniques, and a new culture of offering flexible

service and customized service usage by mashups.

A mashup service or simply mashup can be

defined as a Web Service or application built upon

the integration of other services or data usually

providing a certain added value, contextualization,

or innovation above the integrated services (Merrill,

2006). Due to their variety, we will identify typical

services being mashed-up and provide

a classification of them, creating a “Mash-Tree” (see

160

Drášil P., Pitner T., Hampel T. and Steinbring M. (2008).

GET READY FOR MASHABILITY! - Concepts for Web 2.0 Service Integration.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - SAIC, pages 160-167

DOI: 10.5220/0001709501600167

 SciTePress

Figure 1) – a view of different components for the

successful development of mashups. This

classification is based upon our recent research and

analysis of established mashups. Respecting the

research notes Service Oriented Architectures from

Gartner Group (Gartner, 1996), where SOA was

mentioned first, this article takes both aspects –

business and technology – into consideration to find

concepts for mashups.

2 SERVICE CLASSIFICATION

Out of the market research we differentiate six major

types of Web 2.0 services which can be divided by

their general interest and focus of the service they

offer. We have selected popular and representative

services from each group and apply the following

classification to them. A distinction is drawn

between creating, sharing, storing and presenting

content as well as between their

coordination/communication and community

orientation.

Content Creation

Typical services in this area are wikis

, blogs

even online-databases (such as Google Base

) are

enriched with semantic patterns for self-organized

structuring (e.g. tagging) of peer created content.

Contemporary Web 2.0 services also enable text

processing (e.g. Google Docs

) or spreadsheet

calculations (e.g. Zoho

As an orthogonal technology, various services

can be combined with syndication feeds like RSS

(Really Simple Syndication) or Atom that bring

hypertext characteristics to effectively any kind of

resource.

Content Sharing

Along with the fundamental ideas of Web 2.0

(O’Reilly, 2005), the added value of user-generated

content is further amplified by its distribution and

online availability. Web 2.0 services offer many

opportunities to share a wide range of media and

documents. We will mention the most prominent

categories as represented by Flickr

or Google

http://www.wikidot.com or http://www.wikitravel.com

http://www.wordpress.com

http://base.google.com

http://docs.google.com

http://www.zoho.com

http://www.flickr.com

Picasa

for photo sharing, Adobe Share

for

documents, MediaMax

and DivShare

for

multimedia sharing services, while Slideshare

V3 Solution and Resource Center

are suited to

sharing slide presentations and screencasts.

Each service provides a certain kind of access

management. Open and cooperative group policies

may limit access to online information depending on

the level of publicity or confidentiality. OpenID

and Enterprise Sign On Engine

are examples of

Authentication and Authorization Infrastructures

(AAI) enabling service access via a light-weight

identity service.

Content Storage

In addition to this end-user content sharing, we also

come across services providing generic storage and

data management functionality for other services,

thus contributing to the “web as the platform”. One

of the most successful ones is Amazon S3

acting as

the underlying data storage for many famous data-

heavy services. There are also infrastructural

services analyzing web traffic for maintenance and

marketing purposes, see Monitor.us

or Google

Analytics

Content Contextualization, Presentation and

Management

These services provide content created by

interacting with other web interfaces for a final

enriched presentation to the user. Thus,

communication via APIs (Application Programming

Interfaces) and customization possibilities form the

added value of these services. Services for

presenting web-based desktops

or geo-referenced

map presentations (like Google Maps

) can be

noted. Individual information retrieval and bundling

are gaining more and more importance these days

which technically means interconnecting services

via their application interfaces. Services like Yahoo!

http://www.picasa.com

http://share.adobe.com

http://www.mediamax.com

http://www.divshare.com

http://www.slideshare.net

http://leonardo-v3.eu

http://www.openid.net

http://www.esoeproject.org

http://aws.amazon.com/s3

http://mon.itor.us

http://analytics.google.com

http://www.netvibes.com or http://www.pageflakes.com

http://maps.google.com

GET READY FOR MASHABILITY! Concepts for Web 2.0 Service Integration

161

Pipes

or Dapper

fit into this class. In future these

services will consequently also be provided under

different license models. At present, there are

service providers, e.g. Postini, Inc.

, utilizing

Google Apps API directly in their customers’

infrastructure. Contextualizing data services like

verifying postal codes or ordering numbers from

third party services is a promising next step into

flexible web service integration.

Figure 1: The Mash-Tree shows qualities of Web 2.0

services.

Coordination and Communication

Having started with web-based e-mail services at the

beginning of the Internet era, most e-mail providers

now supply complex communication and

collaboration possibilities. As an example, the

Google service suite, i.e. Google Calendar together

with GMail enhanced by Google Talk as well as the

integration of instant messaging features into Yahoo!

Mail provide an open API-based access. Unlike

complex e-mail infrastructures like Microsoft

Exchange, lightweight web-based collaboration

http://pipes.yahoo.com

http://dapper.com

http://www.postini.com

services (like Zimbra

) are approaching flexible

service interoperability. Typically, they utilize tags

for personal e-mail content structuring. Zimbra’s

special features are its encapsulated modules

(Zimlets) for integrating APIs provided by distinct

client applications.

Community

Communities are playing a decisive role in the

success of the development of Web 2.0 services, as

most of them exhibit a strong network effect and

may even depend on reaching a critical mass

(Hendler & Golbeck, 2007). People with similar

interests and/or common activities use social

networking services such as MySpace

, XING

Facebook

, or even more specialized community

services.

Table 1 depicts services selected from each

classification category.

Table 1: Service Classification Overview.

Content Creation Blogger

Bubbl.us

Google Docs

Wikidot.com

Zoho Online Office

Sharing Adobe Share

Clipmarks

Diigo

DivShare

Flickr

MediaMax

Picasa Web Albums

SlideShare

Storage Amazon S3

Contextualization,

Presentation and

Management

Pageflakes

Google Maps

Community Communication GMail + GTalk

Coordination Backpack

Calendarhub

Google Calendar

Google Groups

Remember The Milk

Community MySpace

http://www.zimbra.com

http://www.myspace.com

http://www.xing.com

http://www.facebook.com

ICEIS 2008 - International Conference on Enterprise Information Systems

162

3 ASPECTS OF MASHING

We will now concentrate on technological, business,

and legal aspects of mashing the Web 2.0 services.

We will show which techniques, protocols, and

formats are predominantly used as well as what

quality of support developers can expect from the

service providers. Finally, we will discuss what

business and legal issues are related to the mashing

development and operating.

3.1 Technological Aspects

Mashing Techniques

Nowadays, many web services are loudly supporting

the principles of Web 2.0. Unfortunately, some of

them are using this fashionable label for marketing

purposes only and are somewhat remote from

implementing its ideas. One of the basic principles

of Web 2.0 – “web as a platform” – is hard to

implement without services offering their

functionality for programmatic access. Our analysis

correlates with another result (Novak & Voigt,

2007) and shows an alarming lack of realization of

Web 2.0 principles, since one third of the services

reviewed have been created for direct usage by

humans only.

Services without an application programming

interface can be (from strictly technological point of

view) accessed using web-scraping techniques, i.e.

analyzing the HTML code of their web interface and

then simulating user actions normally performed in a

web browser. This is, however, unreliable, error-

prone and disputable from a legal point of view.

Mashing on Server or Client

The basic decision developers have to make when

designing a mashup service is whether the code

accessing particular services and combining their

functionality will be run on a server or on client.

Both variants have their advantages and

disadvantages and further elaboration of this

problem is beyond the scope of this article (see

however Ort et al., 2007). What is important here is

that apart from the traditional server-side model,

there are also client-side models in which developers

have very limited possibilities in terms of operations

allowed and available technologies.

Protocols and Formats

The technical realizations of APIs in services that

offer such a possibility differ a lot (cf. Table 2).

However, all APIs except those of instant messaging

and emailing services use HTTP as a communication

protocol. The reasons for this are clear – its

simplicity and the fact that it can easily pass through

firewalls in the Internet.

Table 2: Services, API, and Protocols.

Service Official API

Adobe Share REST

Amazon S3 REST, SOAP

Backpack XML over HTTP

Blogger GData

bubbl.us no

Calendarhub no

Clipmarks no

Diigo no

DivShare REST

Flickr REST, XML-RPC, SOAP

GMail + GTalk POP3/SMTP/IMAP, XMPP

Google Base GData

Google Calendar GData

Google Docs GData

Google Groups no

MediaMax REST

MySpace no

Picasa Web Albums GData

Remember The Milk REST

SlideShare REST

wikidot.com no

Zoho Online Office REST, XML-RPC

Although some services utilize the traditional RPC

(Remote Procedure Call) messaging model in the

form of either SOAP (Simple Object Access

Protocol) or XML-RPC (eXtensible Markup

Language with Remote Procedure Call), the most

popular messaging model today is REST

(Representational State Transfer). The term is,

however, often used in a much looser sense than it

was defined in Fielding (2000), meaning that the

service offers a simple interface transmitting

domain‐specific data over HTTP without an

additional messaging layer. The data is transferred in

HTTP responses in various formats including

service-specific XML, JSON (JavaScript Object

Notation), binary data and plain text. For data

retrieval, RSS and ATOM formats are very popular.

In addition to pre-defined RSS/ATOM channels,

services usually provide their users with the

possibility of defining their own channels with data

selected by user-specified criteria.

GET READY FOR MASHABILITY! Concepts for Web 2.0 Service Integration

163

Google, one of the major Web 2.0 companies,

developed its own generic protocol for reading and

writing data on the Internet, called GData. It is based

on RSS and ATOM, and allows data updates, too.

Google uses this home-made protocol in all its APIs.

It is not an exception when a service offers more

API variants or even more semantically equivalent

APIs. Service client developers can choose not only

which format they want to receive data in (XML,

JSON etc.), but sometimes also which messaging

model and protocol they want to use (REST, SOAP

or XML-RPC). The two main reasons for this are the

freedom of choice for developers and – especially in

newly established services which are trying to attract

users away from competitive services – copying the

API of some rival service in order to make the

transition between services easier

(e.g. ma.gnolia.com offers del.icio.us-like API).

The relationship between technology

standardization and service „mashability“ is depicted

in Figure 2.

Developer Support

The basic support for service client developers is

API documentation. This can be found in a variety

of forms and extents with every service offering a

public API. Some services go even further and

provide libraries, which facilitate the use of their

API in specific programming environments (Java,

JavaScript, PHP, Ruby, or .NET). Where no library

is officially provided, there are third-party libraries

which can do the job. “Third party” usually

represents some enthusiastic service user(s).

Figure 2: Technological Standards and Integration.

Authentication and Authorization

Services often require client applications developers

to request an “API key” that uniquely identifies

every client application when accessing the service

through its API. This allows services to set limits to

the usage of their API (e.g. to one query per second

or 1,000 queries per day for a registered application,

as SlideShare does). Such limits are not an issue for

single-user applications but this is quite a rare case

in the “web as a platform” environment. For multi-

user applications such limitations can be a serious

problem.

3.2 Business Aspects

When the understanding of the “Web Service“

concept in general is only of a technical nature (as

described in the last section), the counterpart in an

economic sense is service supply and demand.

Mashups can be seen as a specific combination of

existing services that bring a particular added value.

This combination is more than just technical services

and their interaction with each other. Repercussions

also occur for the non-technical service in general.

For instance, the popular service “Google Maps” can

be found in other solutions integrating (geo)spatial

information such as Trulia

. It presents information

which is enriched with governmental and private

data collections. But what are the essential elements

of successful acceptance?

Out of our survey on well-established mashups,

their success can be seen in their implementing of

the following basic conditions. It is a combination of

access to information, semantic enrichment and

individuality of the service (see Figure 3).

Access to Available Information

A necessary precondition for flexibly usable services

is the access to primary sources of information. The

newly created service has access to the primary

source’s data, e.g. purchasing power in relation to

the geographical area based on public surveys.

Besides free access to data, which is in most cases

owned by the government, some service providers

have become specialists in private information

collections, like Navteq

or Claritus

, where access

costs money in the majority of cases.

Value-added Semantic Combination

The success of mashed-up services is based on an

easy way of combining and consolidating existing

information in order to create a new value. The

popularity of services like Yahoo Pipes (addressing

different APIs for a customized search) or Microsoft

Popfly (customizing an API-controlled Web

Desktop), or even a general-purpose IBM Mashup

http://www.trulia.com

http://www.navteq.com

http://www.claritus.com

ICEIS 2008 - International Conference on Enterprise Information Systems

164

Starter Kit

is based on that advantage. A good

example showing the power of new forms of

mashed-up services is given by Placebase, Inc.,

a company presenting detailed information based on

geo-referenced statistical combination, like a census

or neighbourhood data.

Generating an Individualized Service

Mashing data or information into a meaningful

service requires a focus on customers. Firstly, the

presentation of emerging information out of the

user’s demand is a necessary condition for success.

Mashups must aim at an individual composition of

services to present this information. Secondly,

influenced by a specific “culture” of both, offering

and using services, the attitude of a long-term

balance between taken and given is reached by

allocating web access to the public. In fact, the

success of Google Maps is a result of this attitude.

This diversity of so-called “open web services” will

lead to a customized use of services and a more

accurate settlement of demand again. Deriving from

this fact, a third step can be seen in the flexibility of

the underlying business model. It contains adaptable

license agreements and legal terms of use depending

on the contextualized usage.

Figure 3: Success Factors for a Mashup Service.

In combination with innovative techniques these

business-related principles of the new web are

promising advantages for a Web 2.0 era, see

Figure 3.

http://www.alphaworks.ibm.com/tech/ibmmsk

3.3 Legal Issues

Each of the services reviewed here, except one

(Bubbl.us), provides its users with a document

named “terms of use” or “terms of service” (ToS),

even if it is not obviously visible for the user in

every case. The style of licensing documents ranges

from a list of clear and simple explanations to

complex documents spanning 10 or more printed

pages. The latter is typical especially for services

provided by larger companies (Google, Yahoo etc.).

Some services are aware of this difficulty and

provide users with a simplified version of their ToS,

explaining selected aspects in a more

comprehensible way. Google is the only service

provider offering some ToSs (namely for Blogger

and Google Groups) in Czech.

User-supplied Data Licensing

Many Web 2.0 services are data-centred. The data

can be provided by the service itself or, much more

frequently, by its users. Many services just manage

data provided or created by their users. Therefore the

rules for handling this data are very important.

As a general rule, services do not claim

ownership of data provided by users. On the

contrary, they disavow the data in order to prevent

themselves from accusations of publishing law

infringing data. On the other hand services need to

have special rights to the content due to their

functionality – e.g. image sharing services would not

be able to create thumbnails without the right to

modify supplied pictures. At this point, services’

conditions differ significantly – some services claim

solely the rights necessary for providing their

functionality, while others claim much wider rights,

e.g. using supplied non-private data for advertising

or promotion.

Data privacy is another important criterion. All

services are treating personal data and the data

labelled as “private” as confidential and reveal them

without the submitter’s approval only under very

serious conditions, explicitly named in their ToS.

Almost all services allow their users to restrict

access of other users to supplied data using

sophisticated AAI implementation, but a cross-

service infrastructure is rarely adopted. It usually

includes private access (only owners can access the

data), public access (everybody on the Internet can

see or even modify the data) and also some

specification in between. Approaches to data sharing

vary a lot.

Licensing user-supplied published data for other

service users is not considered by many services and

GET READY FOR MASHABILITY! Concepts for Web 2.0 Service Integration

165

is rather left up to users, see Table 3. Only a few

services deal with this type of licensing,

systematically allowing users to assign one of the

pre-defined licenses based on Creative Commons

to every piece of data. Flexible determined license

structures are representing an effective approach to

multidimensional agile usage.

Table 3: Licensing User-generated Content.

Service Licensing for

service provider

Licensing for other

users

Ad. Share Necessary only

Amazon

Backpack Service promotion

Blogger Service promotion?

Bubbl.us

Clipmarks Complete rights

Flickr

7 possibilities (CC

)

Gmail/Talk Necessary only

G. Base Use in their services

Calendar

Necessary only

G. Groups Use in their services,

promotion

MediaMax

Picasa Use in their services,

promotion

Remember

The Milk

Necessary only

SlideShare Usage for their

business

7 possibilities (CC

)

Wikidot Usage in their

services

14 possibilities (CC

)

Although each service has its specific ToS, some

aspects are common for all reviewed services.

Firstly, services are, not surprisingly, sensitive about

user accounts – they require accounts not to be

created in any automated way, allowing creating

accounts for humans only, and forbid account

sharing among multiple people. Secondly, services

are anxious about the data and therefore explicitly

* http://creativecommons.org

prohibit any kind of systematic harvesting or

indexing of its content. The third common point is

software copyright. It is not allowed to copy,

reproduce, alter, modify, reverse engineer or create

derivative works from any of the services.

Table 4: Terms of Service and GUI.

Service Incorporating

GUI

Automated access to

GUI

Ad. Share forbidden unspecified

Amazon S3 no GUI no GUI

Backpack with permission unspecified

Blogger forbidden unspecified

Bubbl.us unspecified unspecified

Calendhub forbidden unspecified

Clipmarks forbidden forbidden

Diigo forbidden forbidden

DivShare with permission no robot w/o permission

Flickr with permission via provided intf. only

Gmail/Talk forbidden forbidden

G. Base forbidden via provided intf. only

G. Calendar forbidden forbidden

G. Docs with permission forbidden

G. Groups with permission unspecified

MediaMax unspecified "Reasonable Usage"

MySpace with permission forbidden

Picasa forbidden via provided intf. only

Rememb.

forbidden forbidden

SlideShare forbidden no "burdening" robots

Wikidot limited forbidden

Zoho allowed unspecified

Some services prohibit incorporating their

graphical user interface into other applications or

accessing it via any automated processes (cf.

Table 4). But even in cases where these activities are

not explicitly forbidden, they are probably violations

of the previously mentioned rule. The only service

directly supporting incorporating its GUI into

another application is Zoho, which allows using

Writer, Sheet and Show from its office suite as

editors for appropriate document formats.

All services restrict user supplied content not to

violate copyrights and not to contain vulgarity,

nudity, racism and other improper or illegal

information. For some services, this is the only

limitation. Other services go further and restrict the

data type in accordance with the service’s intention

– to personally taken photos (Flickr), for example.

Another example of content limitation is in Google

ICEIS 2008 - International Conference on Enterprise Information Systems

166

Base which (at the time of writing) allows textual

data to be in English and German only. The

Figure 4. shows a scale of “openess” and

mashability with respect to service and content

licensing.

Figure 4: Mashability Determined by ToS Factors.

4 CONCLUSIONS

The main goal of this research was to provide a

conceptual, technical, business, and legal foundation

for Web 2.0 mashup development and deployment.

We proposed a basic classification of Web 2.0

services from functional points of view and applied

this classification to a selected set of popular

services. Then, the “Mash-Tree” was proposed.

Further, we have identified “mashing” potential

and issues of the services in three dimensions:

technical, business, and legal. The technical analysis

showed that – despite the overall popularity of

SOAP in enterprise computing – in Web 2.0 the

HTTP and REST are predominantly used.

We have revealed that many often-alluded to

practices like screen scraping can rarely be

implemented legally. Our investigations also

brought interesting results about licensing the user-

generated content stored in the Web 2.0 services.

By highlighting technical success factors as well

as distinguishing different types of business and

legal aspects onto the market, this article contributes

to the improvement of further mashup development.

Our research of well-established Web 2.0

services shows that a full mashing potential has not

yet been achieved in the market. A ubiquitous

practicability and usage is closely linked with self-

description and (machine) readability of a service,

which is not achieved in all cases yet. In a vision of

the New Web, services with different focus can be

flexibly mixed into a new context.

The potential of service mashability for

flexibility of software usage and tailored software

customization is bringing new business models to

bear, replacing previous models produced under

monolithic, fixed infrastructures. Scenario based

licensing as well as cross service charging

(Micropayment 2.0) can be a successful achievement

for users and producers.

We hope that our conceptual framework,

classification and aspect evaluation can serve

mashups developers as well as future research.

ACKNOWLEDGEMENTS

The research has been partially supported by the

Czech National Program Information Society,

project 'E-learning in the Semantic Web Context',

No. 1ET208050401.

REFERENCES

Alonso, G., Casati, F., Kuno, H. and Machiraju, V. (2004).

Web Services – Concepts, Architectures and

Applications. Springer-Verlag, Berlin, 2004

Creative Commons (2008). http://creativecommons.org,

cited 06/03/08

Fielding, R. (2000). Representational State Transfer,

http://www.ics.uci.edu/~fielding/pubs/

dissertation/rest_arch_style.htm, cited 06/03/08

Gartner Group (1996). Service Oriented Architectures,

Part 1 and 2, SSA Research Note SPA-401-068 and

SPA-401-069, Gartner Press, 1996

Hendler, J., Golbeck, J. (2007). Metcalfe's law, web 2.0,

and the semantic Web, Journal of Web Semantics,

Vol. 10, Elsevier B.V., 2007

Merrill, D. (2006). Mashups: The new breed of Web app,

IBM Developerworks, 2006, http://www.ibm.com/

developerworks/xml/library/x-mashups.html

Novak, J., Voigt, B. (2007). Mashups: Structural

Characteristics and Challenges of End-User

Development in Web 2.0, in: i-com 02/2007,

Zeitschrift für interaktive und cooperative Medien,

Volume 5, p. 19-25, Oldenbourg Verlag, Munich,

2007 (in German)

O’Reilly, T. (2005). What is web 2.0? – design patterns

and business models for the next generation of

software.

Ort, E., Brydon S., Basler M. (2007). Mashup styles, Part1

and Part2: Server-Side Mashups, 2007,

http://java.sun.com/developer/technicalArticles/J2EE,

cited 06/03/08

GET READY FOR MASHABILITY! Concepts for Web 2.0 Service Integration

167