Towards Real-time Collaboration in User Interface Mashups

Alexey Tschudnowsky, Michael Hertel, Fabian Wiedemann and Martin Gaedke

Department of Computer Science, Technische Universitt Chemnitz, Str. der Nationen 62, Chemnitz, Germany

Keywords:

User Interface Mashup, Widgets, End-user Development.

Abstract:

Recently, user interface mashups have become a popular approach for covering the long tail of end-user needs.

The simple composition paradigm and rich tool support aim at enabling even non-programmers to aggregate

data and application logic to solve situational business tasks. Despite of existing assistance mechanisms, both

development and usage of UI mashups remain mostly a single-user activity. As a result, novices are usually

left alone in case of conﬁguration problems or unexpected errors. Furthermore, the work cannot be distributed

efﬁciently to solve tasks faster. This paper presents an approach to make development of and interaction with

mashups a collaborative process. We show, how one can extend today’s composition platforms towards real-

time collaboration and demonstrate the approach in the context of the open-source mashup platform Apache

Rave.

1 INTRODUCTION

Dashboard-like applications (known also as user in-

terface mashups or, shortly, UI mashups) have been

widely adopted in enterprises (Hurwitz et al., 2005).

They enable management of complex, heterogeneous

and scattered information by end-users, so that situ-

ational problems can be solved faster and more ef-

ﬁciently (Cappiello et al., 2011). UI mashups con-

sist of autonomous but cooperativevisual components

called widgets, which aggregate data from various

sources and enable access to often used functionali-

ties. Within a mashup widgets are able to synchronize

their views using a dedicated messaging infrastruc-

ture. Though the development process is rather sim-

ple, novice users still lack initial knowledge on how

particular mashup platform works and have little sup-

port in case of conﬁguration problems. Furthermore,

if working in teams, users can hardly parallelize their

activities, as the majority of today’s mashup tools are

single-user applications.

The following scenario illustrates the problem.

Alice and Bob, two company employees, plan a joint

business trip to Vienna, Austria. To prepare the trip

they want to collect information about their desti-

nation, perform various bookings and agree on the

schedule. In contrast to Bob, Alice is already experi-

enced in developing mashups, and, thus, she quickly

constructs a dashboard, which aggregates and com-

pares data from different Web sources. If working

at the ofﬁce, Alice explains to Bob capabilities of

the composition platform and they use the resulting

mashup to prepare the trip. However, the planning

becomes much more challenging if the employees

work remotely. Without appropriate collaboration fa-

cilities, Alice cannot efﬁciently share her view on a

mashup and explain required conﬁguration. For the

same reason Bob can neither participate in the com-

position nor speed up the process.

We believe that real-time collaboration and com-

munication facilities can efﬁciently support situations

like this. However, equipping Web applications (and

mashup platforms in particular) with collaboration fa-

cilities is challenging and requires careful design of

synchronization algorithms, conﬂict resolution and

awareness services (Heinrich et al., 2012b). The pe-

culiarity of the UI mashup domain lies, additionally,

in the fact that the aggregated components, i.e. wid-

gets, can originate from third party developers and,

thus, be highly heterogeneous. Furthermore, many

mashup platforms host widgets in isolated security

contexts (e.g. iframes), so that Same-Origin-Policy

hinders direct access to their internal data or UI.

While isolation helps to prevent possible leak of data,

it represents a serious obstacle for synchronization of

widgets across mashup boundaries.

This paper tackles the above challenges by deriv-

ing a reference architecture and guidelines to enable

real-time collaboration in UI mashups. The main con-

tributions are threefold: First, a terminology and con-

193

Tschudnowsky A., Hertel M., Wiedemann F. and Gaedke M..

Towards Real-time Collaboration in User Interface Mashups.

DOI: 10.5220/0005049001930200

In Proceedings of the 11th International Conference on e-Business (ICE-B-2014), pages 193-200

ISBN: 978-989-758-043-7

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

ceptual approach to synchronize UI mashups is pre-

sented (Section 2 and 3); second, a reference archi-

tecture for integration of real-time collaboration facil-

ities into mashup platforms is derived (Section 4); and

ﬁnally, implementation of the approach in the con-

text of an existing open-source mashup platform is

demonstrated (Section 5). A review of related work

is given in Section 6. Section 7 concludes the paper

and gives an outlook on the planned evaluation and

future research.

2 UI MASHUPS: STATE OF THE

ART

In the following, we introduce terminology of UI

mashups by adapting the deﬁnitions introduced by

Wilson et.al. in (Wilson et al., 2012). The terminol-

ogy is used for analysis, which artefacts are involved

into real-time collaboration and helps to deﬁne syn-

chronization algorithms for UI mashups.

Conceptually, a UI mashup is a tuple

m =< M,W, I > with:

• M =< name, description > being a basic meta-

data of the mashup

• W = {w

: w

=< S

, A

, Pos

, Dim

>} being

a set of widgets w

with relative position in

a mashup Pos

=< left

,top

>, dimensions

Dim

=< width

, height

>, internal state S

, and

inter-widget communication (IWC) affordances

. The internal state S

describes, for exam-

ple, current focus of a map widget or its cur-

rent zoom level. Affordances A

are speciﬁc to

the concrete strategy used for IWC. In (Wilson

et al., 2012) authors distinguish between chore-

ographed, orchestrated or hybrid ones. In case of

the choreographed and hybrid IWC strategies the

affordances are deﬁned as A

=< E

, O

> with

= {e

: e

=< name

,topic

>} being a set

of events generated by a widget and O

= { o

=< name

>} being a set of supported op-

erations (Wilson et al., 2012). t

∈ T are well-

known communication channles (topics) deﬁned

by a topic ontology T. On occurance of internal

event e

, widget publishes a message on topic t

Other widgets, which support operations for the

same topic, i.e. subscribe to t

, are notiﬁed about

the new message and execute their respective op-

erations automatically.

• I being an IWC conﬁguration of a mashup spe-

ciﬁc to the utilized IWC strategy. For hy-

brid IWC strategy it contains restrictions put by

user on communication between a pair of wid-

gets: I = {r

: r

=< w

jsender

, w

jreceiver

>} with

jsender

, w

jreceiver

∈ W and t

∈ T.

From the implementation point of view, a wid-

get w is considered to be a standalone, autonomous

Web application with its own user interface, applica-

tion logic and persistence layer. The source code of a

widget is usually packaged for distribution, e.g. in a

dedicated ZIP archive (cf. W3C Web Apps

) or mod-

ularized XML ﬁle (cf. OpenSocial

). To be composed

with others, a widget needs to be ﬁrst instantiated and

integrated into the hosting Web application. The state

S of an aggregated widget is, conceptually, the same

as the state of a traditional Web application (Lo et al.,

2013). It reﬂects the widget’s current DOM tree and

states of Javascript objects. The hosting mashup acts

as runtime environment for the aggregated widgets

and operates among others a messaging infrastruc-

ture, which enables widgets to notify each other about

internal state changes. Usually, widgets do not ex-

change data on low-level events (such as button clicks

or text input), but rather on domain-speciﬁc ones such

as form submissions or domain object selections. De-

pending on the utilized IWC strategy the infrastruc-

ture can either a global message bus, shared memory

or registry of communication endpoints.

Lifecycle of a mashup can be roughly divided into

a development and an execution phases. During a de-

velopment phase mashup designer speciﬁes mashup

metadata, selects widgets for composition, conﬁgures

their dimensions and initial state and speciﬁes mashup

IWC conﬁguration. The result of the development

phase is a speciﬁcation, which can used by mashup

runtime environment to instantiate the Web applica-

tion. During the execution phase, mashup designer

(or any other user) consumes information presented

by the aggregated widgets and interacts with them to

accomplish domain-speciﬁc tasks.

Despite the formal separation, development and

execution phases of UI mashups are usually inter-

weaved. The so called ”live development” paradigm

promotes smooth transition between the both in order

to lower the barrier of mashup development(Aghaee

and Pautasso, 2013). Many platforms and tools

emerged, which enable runtime mashup reconﬁgura-

tion. One reference architecture for such develop-

ment and execution approach has been developed in

the FP7 EU Project OMELETTE (OMELETTE Con-

sortium, 2013) and its excerpt is presented in Figure

http://www.w3.org/TR/widgets/

http://opensocial.github.io/spec/2.5.1/Core-

Gadget.xml

ICE-B2014-InternationalConferenceone-Business

194

Figure 1: Reference architecture for UI mashups (terminology adjusted).

In the ﬁgure, the Widget Runtime Environment

persists, instantiates and manages widgets. The

Mashup Runtime Environment enables composition

of widgets based on end-user-oriented programming

techniques, e.g., using visual metaphors or natu-

ral language. Its submodules persist mashup mod-

els, manage user proﬁles and operate messaging in-

frastructure for IWC. Widget Browser enables man-

ual discovery of widgets. To ease mashup devel-

opment the runtime environment can be equipped

with composition assistance services such as Mashup

Pattern Recommender and Automatic Composer

(Roy Chowdhury et al., 2013). Concrete Web im-

plementations of the reference architecture are usu-

ally split into a server and a client sides. The server

side is responsible for mashup persistence and man-

agement, while the client side renders a representation

of a mashup, provides the IWC infrastructure and en-

ables interaction with user.

3 REAL-TIME COLLABORATION

IN UI MASHUPS

In the following, we analyze end-user and technolog-

ical requirements on collaborative mashup develop-

ment and usage. Afterwards, synchronization algo-

rithms for both mashups and single widgets are pre-

sented.

3.1 Requirements Analysis

From a mashup designer’s point of view, the main

requirement is the ability to ”share” his view on a

mashup with one or more collaborators and to in-

teract with the mashup simultaneously. All changes

to mashup structure and all interactions with widgets

should be propagated and made visible to all collab-

orators in real-time. The awareness of mutual in-

teractions should help to distribute work more efﬁ-

ciently and to minimize the number of possible con-

ﬂicts. Finally, real-time communication facilities are

desired to support coordination of actions during de-

velopment and usage phases.

From the technical point of view, the main require-

ment for enabling real-time collaboration is the abil-

ity to keep mashup representations rendered in dif-

ferent contexts, i.e. browser instances, synchronized

over time. Interactions with mashup and with widgets

must be tracked, propagated and replayed in all con-

texts in real-time. Possible conﬂicts should be auto-

matically resolved to keep all mashup representations

in a consistent state. To support awareness of mu-

tual presence and interactions, information about col-

laborators and about origin of remote changes should

be visualized. Also interactions, which do not nec-

essarily result in changes in mashup or widget UI

(such as mouse movements or clicks), should be prop-

agated. Finally, the platform should enable an on-

demand transfer of text and multimedia data between

collaborators with acceptable quality.

3.2 Real-Time Collaboration Facilities

According to the requirements above, integration of

real-time collaboration facilities requires considera-

tion of the following three aspects:

• Synchronization of mashups being rendered in

different browser instances

• Tracking and visualization of active collaborators

and their interactions

• Capturing, propagation and replay of media

streams between collaborators

TowardsReal-timeCollaborationinUserInterfaceMashups

195

In the following, the three tasks and their concep-

tual realization are discussed in details.

3.3 Mashup Synchronization

First, we assume, that mashups representations be-

ing rendered in two browser instances of different

users can be described as mashups from Section 2.

We say, two mashup representations m

and m

are

synchronized at some point of time t, if m

.M =

.M ∧ m

.W = m

.W ∧ m

.I = m

.I. The real-time

synchronization takes place, if changes to one mashup

representation are applied or made visible to all oth-

ers within some pre-deﬁned time limit ∆t. The real-

time synchronization constraint creates an illusion of

working on the same mashup, while in reality users

interact only with local representations.

To keep all representations synchronized, we pro-

pose to apply the Operational Transformation (OT)

algorithm (Ellis and Gibbs, 1989). Local modiﬁca-

tions to metadata, widgets or IWC conﬁguration of

a mashup should be modelled as operations, which

are observed and propagated to the master copy of the

mashup representation. Each local mashup represen-

tation is assigned a revision number, which identiﬁes

a particular state of the mashup. Two mashup repre-

sentations are considered to be synchronized if their

revision numbers are equal. A conﬂict resolution en-

gine should apply dedicated transformation functions

to operations of different revisions, incorporate them

into the master copy and propagate the transformed

operations to all clients. Based on the mashup deﬁ-

nition above the following operations have been iden-

tiﬁed (hybrid IWC strategy (Wilson et al., 2012) is

assumed):

Op 1. SetMashupName(name : string)

Op 2. SetMashupDescription(desc : string)

Op 3. CreateNewWidget()

Op 4. MoveWidget(w :Widget;left,top : int)

Op 5. ResizeWidget(w :Widget;width, height : int)

Op 6. DeleteWidget(w : Widget)

Op 7. AllowTopicBetweenWidgets(w

, w

:Widget,

topic : Topic)

Op 8. ForbidTopicBetweenWidgets(w

, w

:Widget,

topic : Topic)

The transformation function for two operations

, o

) (o

having a higher revision) is deﬁned as fol-

lows:

1. If o

= o

including all parameter with o

, o

∈

{Op1, Op2, Op4, Op5, Op7, Op8}, then the result

of the tranformation function is (NoOp, o

) with

NoOp being the nothing affecting operation.

2. If o

and o

do not possess any equal parameters

(meaning they do not affect the same artefact),

then they are transformed to (o

, o

3. (o

, o

) with o

, o

∈ {Op4(w

, ...), Op5(w

, ...),

Op7(w

, ...), Op8(w

, ...)} except (Op7(w

, ...),

Op8(w

, ...)) and (Op8(w

, ...), Op7(w

, ...)) is

transformed to (o

, o

) as the affected widget

properties are independent.

4. (Op6(w

), o) with o ∈ (Op4(w

, ...), Op5(w

, ...),

Op7(w

, ...), Op8(w

, ...) is transformed to

(NoOp, Op6(w

)), which avoids any operations

on widgets, which have been deleted locally.

5. (o

, o

) with o

, o

∈ (Op7, Op8) is transformed

to (NoOp, o

Synchronization of widget states requires sepa-

rate consideration. A complete synchronization can

be achieved by exchange of complete DOM trees

and Javascript objects of Web applications (Lo et al.,

2013). However,if applied often, signiﬁcant overhead

especially in the context of complex HTML5 appli-

cations can be caused. Second, access both to wid-

get DOM tree and Javascript variables is usually re-

stricted for security reasons and, thus, generic change

listeners and object modiﬁers would not work. To

tackle the above challenges, we propose to use alter-

native synchronization mechanism for widgets. Wid-

gets should reuse the existing IWC interface and no-

tify their hosting environment about domain-relevant

state changes only. The IWC interface is usually de-

signed to bridge different security contexts by offer-

ing high level messaging operations. The mashup

communication infrastructure should propagate the

issued notiﬁcations to runtimes of other collaborators

and invoke special IWC operations to apply the up-

dates to corresponding widgets. The IWC operation

to be invoked is the one, which has been assigned

to a topic with an agreed naming convention (e.g.,

original − topic − name concatenated with the suf-

ﬁx −sync). The operation (implemented by widget

developer) should update widget UI and internal vari-

ables according to the incoming data.

To illustrate the synchronization of widget states,

consider the example from Section 1. Every time Al-

ice selects a new city on the map widget, the wid-

get issues notiﬁcations about its internal state change

(e.g., an IWC event on topic city and Vienna as pay-

load). To display the same city in the Bob’s map wid-

get, the Alice’s mashup runtime environment propa-

gates the event to the Bob’s one, which in turn noti-

ﬁes the local map widget about incoming update. The

data is propagated on the topic city-sync and the Bob’s

map widget triggers a dedicated operation subscribed

ICE-B2014-InternationalConferenceone-Business

196

to this topic. It updates widget UI and internal objects

to set the map focus on the new location.

The advantage of the method is that users can si-

multaneously interact with widgets. The drawback is,

however, that they may put widgets into an inconsis-

tent state. The reason is that events and operations

affect only parts of the state, which might have inter-

dependencies (e.g. selected city and country). To

guarantee consistent widget state is in general chal-

lenging, as semantics of the events is domain-speciﬁc.

Inconsistent states can be avoided on costs of simul-

taneous modiﬁcation, e.g. by designing event param-

eters in the way, so that they reﬂect the most of the

internal widget state. In best case, widgets propagate

representations of the whole state, so that any even-

tual inconsistencies produced by local modiﬁcations

are overwritten by incoming updates (last state update

wins). Nevertheless, generic consistency preservation

in widgets is still an open issue and should be consid-

ered in future research.

3.4 Presence and Awareness

As mentioned earlier, mashup runtime environments

usually keep track of user proﬁles and mashup mod-

els. To take collaboration sessions with involvedusers

and mashups into account, we propose to put the list

of mashups shared to a particular user directly into his

proﬁle. While instantiating a certain mashup speci-

ﬁcation, runtime environment may check how many

users have requested the same mashup and if they are

still reading/writing the master representation. The

check should result in a list of active collaborators,

which can be displayed to all users to indicate pres-

ence information. The awareness of users about mu-

tual activities should be established by visualizing

their mouse movements and clicks to other users. One

possibility to capture and display the mouse position

is to track the identiﬁer or XPath location of the ele-

ment, where the cursor of a user is currently located

and to propagate this information to other runtime

environments for visualization. The same should be

done for single and double mouse clicks. The method

supports heterogeneous devices with different display

as it doesn’t stick to any absolute coordinates but

rather to the DOM tree. The drawback is, however,

that awareness inside of widgets in isolated security

contexts cannot be established as such widgets hinder

any access to internal mouse interactions.

3.5 Real-time Communication

For the communication of users during development

and usage of mashups, we propose to utilize instant

messaging, audio and video chat facilities. The three

methods have been proven to be highly efﬁcient on

the Web and can be easily integrated into today’s

Web applications using latest HTML5 speciﬁcations.

Communication endpoints correspond to browser in-

stances of active collaborators. The functionalitiesare

accessible on demand using a dedicated control panel

in the mashup runtime environment.

4 REFERENCE ARCHITECTURE

The integration of the above facilities results in a new

updated reference architecture illustrated in the Fig-

ure 2.

The common Authentication Manager now keeps

track of shared mashups and takes care of collabo-

ration sessions. The Local State Manager observes

changes in mashup structure and listens to notiﬁca-

tions issued by widgets. The data is forwarded to the

Global State Manager, which maintains the master

representation of the shared mashup, performs even-

tual conﬂict resolution (OT transformations as de-

scribed in section 3.3) and propagates the updates

to other Local State Managers. On receipt, Local

State Managers apply the changes to local mashups

and invoke dedicated IWC primitives to update states

of their widgets. Interactions, which affect neither

mashup nor states of widgets, such as mouse move-

ments, clicks or presence changes, are observed and

visualized in all mashup instances by a dedicated

Awareness Manager. Finally, RTC Manager provides

instant messaging, audio and video chat services to

collaborating participants. Depending on the direc-

tion of communication (uni- or broadcast), messages

and multimedia data are transferred to one or more

mashup runtime environments.

5 IMPLEMENTATION

To demonstrate the proposed concepts we extended

the open source UI mashup platform Apache Rave

towards real-time collaboration. Apache Rave en-

ables aggregation of W3C and OpenSocial widgets

on one canvas and provides IWC infrastructure based

on OpenAjaxHub

(choreographed model). Wid-

gets’ source code is deployed to Apache Wookie

http://rave.apache.org

http://www.openajax.org/member/wiki/

OpenAjax

Hub 2.0 Speciﬁcation

http://wookie.apache.org

TowardsReal-timeCollaborationinUserInterfaceMashups

197

Figure 2: Reference architecture of UI mashups with integrated real-time collaboration facilities.

which enables their instantiation and provides vari-

ous runtime services such as persistence or proxy fa-

cilities. Widgets can autonomously publish and sub-

scribe messages on a shared message bus. With ac-

tivated IWC conﬁguration extension (Tschudnowsky

et al., 2014), mashup designers are able to adjust

IWC using widget isolations and topic blockades.

In its current version, Apache Rave provides only

rudimental collaboration facilities - mashups can be

shared among users, but no real-time synchronization,

awareness or communication services are provided.

Updates to shared mashup instances become visible

only on the next page reload (mashup speciﬁcation is

used as a master model of mashups). No conﬂict res-

olution mechanism exists.

The platform has been extended towards the refer-

ence architecture from Section 4 (cf. Figure 3).

Awareness and RTC Manager are implemented

using the TogetherJS

framework, which also acts

as messaging infrastructure for global state manage-

ment. TogetherJS consists of a JavaScript library and

a messaging server, called TogetherJS Hub. The de-

cision to use this particular framework was motivated

by the fact, that the framework offered infrastructure,

which could be easily reused and extended towards

the peculiarities of the UI mashup domain.

The client library has been integrated into the

front-end of Apache Rave. Upon loading, all local

mashups connect to the TogetherJS hub and join a

common session, which is used to group collaborators

and to broadcast update notiﬁcations. Client library

enables message exchange using publish-subscribe

strategy. Local State Managers are implemented as a

set of callback routines, which are invoked on changes

https://togetherjs.com

to mashup structure, layout and IWC conﬁguration.

These changes and IWC notiﬁcations of widgets on

internal updates are recorded and are propagated to

the TogetherJS hub, which routes them to Local State

Managers of shared instances. The updates are then

either applied directly to corresponding local models

or passed to IWC state-update operations of widgets

(cf. Section 3.3). Mouse movements, clicks and pres-

ence changes are tracked and visualized. Real-time

communication facilities include text and audio chat

implemented using WebSockets

and WebRTC

pro-

tocols respectively.

Online Demonstration. A demonstration of

the proposed facilities is available at http://vsr.cs.tu-

chemnitz.de/demos/collaborative-ui-mashups.

6 RELATED WORK

A number of frameworks emerged to support integra-

tion of real-time collaboration features into generic

Web applications. The frameworks implement op-

erational transformation (OT) algorithms on various

data structures (text, XML, JSON objects etc.) and

support concurrency control in real-time. ShareJS

OpenCoweb

and Apache Wave

are some of the

examples of such frameworks. However, peculiari-

ties of application domain should be considered dur-

ing their integration. A generic approach to transform

http://dev.w3.org/2011/webrtc/editor/webrtc.html

https://tools.ietf.org/html/rfc6455

http://sharejs.org

http://opencoweb.org

http://incubator.apache.org/wave

ICE-B2014-InternationalConferenceone-Business

198

Figure 3: Integration of real-time collaboration facilities into Apache Rave.

single-user Web applications into multi-user ones is

presented in (Heinrich et al., 2012b). Authors propose

to synchronize multiple copies of Web applications

on the DOM tree level. In (Heinrich et al., 2012a)

the approach is enriched with awareness widgets such

as telepointer or participant list. Though, the pre-

sented solution signiﬁcantly simpliﬁes implementa-

tion of collaborative applications, it doesn’t consider

synchronization of application-speciﬁc Javascript ob-

jects and widget being executed in isolated environ-

ments. A few commercial and open-source projects

integrated real-time collaborationfacilities into the re-

spective mashup platforms. Adobe Genesis

is one

commercial solution based on Adobe Air, which en-

ables composition of widgets (called tiles) and shar-

ing of the resulting view with other users. Liferay

is an open-source Web-based portal software that can

be extended towards real-time collaboration using the

commercial plugin OpenScape Web Collaboration

Due to the lack of information on the internal imple-

mentation, it is difﬁcult to compare or reuse utilized

solutions to the presented problems.

Several research projects attempted integration of

real-time collaboration facilities into UI platforms.

PEUDOM (Matera et al., 2013) is an end-user-

oriented UI mashup platform, which enables collab-

orative composition of widgets. Shared mashups are

synchronized in real-time - both their structure and

widget states. Authors apply a similar synchroniza-

http://helpx.adobe.com/genesis/topics/getting-

started.html

www.liferay.com

http://www.unify.com/us/products-services/uniﬁed-

communications/applications/web-collaboration.aspx

tion approach based on explicit widget state exposure.

Similar approach for widgets described on an abstract

level has been considered by (Blichmann et al., 2013).

Fine-grained access control in mashups with real-

time collaboration support has been considered by

Sire et.al. in (Sire et al., 2009). Authors develop a

dedicated speciﬁcation language and discuss various

use cases. The work doesn’t focus on engineering as-

pects of collaborative mashup platforms, but could be

used in conjunction with the presented work.

In contrast to existing projects, this paper uses

IWC as a mechanism for state observation, propaga-

tion and replay. If widgets support IWC, than the no-

tiﬁcations on state changes can be efﬁciently reused.

The interface requires only minimal changes (new

IWC operations) to incorporate those updates into

widgets of remote mashups. Additionally, this pa-

per considers the problem of keeping mashups in a

consistent state, which arises if users interact with a

mashup simultaneously.

7 CONCLUSIONS AND

OUTLOOK

Collaboration software has been widely applied

within enterprises and on the Web. However, only lit-

tle research can be found within UI mashup domain.

Peculiarities of Web mashups require special consid-

erations of involved data structures and synchroniza-

tion of heterogeneous and secured components. This

paper presented a systematic approach to integrate

real-time collaboration facilities into UI mashup plat-

TowardsReal-timeCollaborationinUserInterfaceMashups

199

forms. A conceptual approach including mashup and

widget synchronization algorithms, a reference archi-

tecture and an example implementation were given.

One lesson learned, is that though current technolo-

gies and protocols signiﬁcantly simplify implementa-

tion of collaborative Web applications, a careful de-

sign is still needed if applied to a concrete domain.

By now, we haven’t found a generic automatic solu-

tion for syncronization of widgets being executed in

secured contextes. As a result widget developers are

required to extend the IWC interface manually. At

least for controlled environments, where source code

of widgets is available, we are exploring application

of automatic source code transformation towards the

extended IWC interface.

A detailed evaluation of the integrated real-time

collaboration facilities is planned. A user study and

performance evaluations should help to assess usabil-

ity and efﬁciency of the current solution. The per-

formance evaluations should provide data on, how

fast updates are exchanged between mashups and how

many conﬂicts emerge in practice. The usability study

should unveil, how comfortable users are with the in-

tegrated mechanisms, and if the current tools sufﬁ-

ciently support knowledge exchange and work distri-

bution.

REFERENCES

Aghaee, S. and Pautasso, C. (2013). Live mashup tools:

Challenges and opportunities. San Francisco, CA,

USA.

Blichmann, G., Radeck, C., and Meiner, K. (2013). En-

abling end users to build situational collaborative

mashups at runtime. In 8th International Confer-

ence on Internet and Web Applications and Services

(ICIW2013).

Cappiello, C., Daniel, F., Matera, M., Picozzi, M., and

Weiss, M. (2011). Enabling end user development

through mashups: requirements, abstractions and in-

novation toolkits. In Proceedings of the Third in-

ternational conference on End-user development, IS-

EUD’11, pages 9–24, Berlin, Heidelberg. Springer-

Verlag.

Ellis, C. A. and Gibbs, S. J. (1989). Concurrency control in

groupware systems. SIGMOD Rec., 18(2):399–407.

Heinrich, M., Gr¨uneberger, F. J., Springer, T., and Gaedke,

M. (2012a). Reusable awareness widgets for collabo-

rative web applications - a non-invasive approach. In

ICWE, pages 1–15.

Heinrich, M., Lehmann, F., Springer, T., and Gaedke, M.

(2012b). Exploiting single-user web applications for

shared editing: a generic transformation approach. In

Mille, A., Gandon, F. L., Misselis, J., Rabinovich,

M., and Staab, S., editors, WWW, pages 1057–1066.

ACM.

Hurwitz, J., Halper, F., and Kaufman, M. (2005). Dash-

boardsenabling insight and action. Technical report,

Hurwitz and Associates.

Lo, J. T. K., Wohlstadter, E., and Mesbah, A. (2013).

Imagen: Runtime migration of browser sessions for

javascript web applications. In Proceedings of the

22Nd International Conference on World Wide Web,

WWW ’13, pages 815–826, Republic and Canton of

Geneva, Switzerland. International World Wide Web

Conferences Steering Committee.

Matera, M., Picozzi, M., Pini, M., and Tonazzo, M. (2013).

Peudom: A mashup platform for the end user devel-

opment of common information spaces. In Daniel,

F., Dolog, P., and Li, Q., editors, Web Engineering,

volume 7977 of Lecture Notes in Computer Science,

pages 494–497. Springer Berlin Heidelberg.

OMELETTE Consortium (2013). D2.3 - ﬁnal speciﬁca-

tion of mashup description language and telco mashup

architecture. Public deliverable, The OMELETTE

Project (FP7/2010-2013 grant agreement n 257635).

Roy Chowdhury, S., Chudnovskyy, O., Niederhausen, M.,

Pietschmann, S., Sharples, P., Daniel, F., and Gaedke,

M. (2013). Complementary assistance mechanisms

for end user mashup composition. In Proceedings

of the 22Nd International Conference on World Wide

Web Companion, WWW ’13 Companion, pages 269–

272, Republic and Canton of Geneva, Switzerland.

International World Wide Web Conferences Steering

Committee.

Sire, S., Palmr, M., Bogdanov, E., and Gillet, D. (2009).

Towards collaborative portable web spaces. In Second

International Workshop on Mashup Personal Learn-

ing Environments (MUPPLE09), pages 80–88.

Tschudnowsky, A., Pietschmann, S., Niederhausen, M., and

Gaedke, M. (2014). Towards awareness and control

in choreographed user interface mashups. In Proceed-

ings of the 23nd International Conference on World

Wide Web companion (to appear), WWW 14 Com-

panion.

Wilson, S., Daniel, F., Jugel, U., and Soi, S. (2012). Or-

chestrated user interface mashups using w3c widgets.

In Proceedings of the 11th International Vonference

on Web Engineering, ICWE’11, pages 49–61, Berlin,

Heidelberg. Springer-Verlag.

ICE-B2014-InternationalConferenceone-Business

200