Florian Daniel, Agnes Koschmider, Tobias Nestler, Marcus Roy and Abdallah Namoun. Toward Process Mashups: Key Ingredients and Open Research Challenges

1. Toward Process Mashups: Key
Ingredients and Open Research
Challenges
Abdallah Namoun
University of Manchester
-Daniel Florian, Tobias Nestler,
Agnes Koschmider, Marcus Roy-

2. Overview and Strategy
 Understand and define process mashups
 Introduce three dimensions:
 Multi-user support
 Multi-page support
 Workflow support
 Combine these dimensions to define new classes of
mashups
 Investigate existing mashup development tools and
classify them according to the mashups they
support
 Highlight some challenges and issues

3. Motivation
 Mashup development has become very matured
recently
 Types of known Mashups: data mashups, service
mashups, user interface mashups
 A new concept emerged: process mashups?
 The aim is to
 explain process mashups and
 identify the dimensions of process mashups
 In the paper,
 we define a set of new mashups based on the dimensions
 For each mashup, we discuss suitable application scenario
and show tool support

4. Definitions and background
 Mashup: a web application integrating data,
application logic, and user interfaces
 A business process: a set of activities represented
in a visual form
 Business processes primarily focus on the control
flow perspective and technical level of Service to
Service interactions
 A workflow: an executable part of a process
consisting of several activities and defining a series
of tasks that need to be managed by different
resources

5. Background (cont’d)
 Service composition is a complex, expensive, and error prone
process requiring specialist skills and knowledge
 Thus, the emergence of lightweight composition and mashup
platforms
 Graphical mashup platforms for web development include:
Yahoo! Pipes, Open mashup, Marmite
 Such tools mainly support the development of data-oriented
mashups;
 no multiple views are supported
 no control-flow is supported
 only single users are addressed
 Other tools, e.g. SOA4All PE and Serena Mashup Composer,
handle business processes but are considered professional
development environments

6. Example – Leave request
scenario
 A business process typically involves multiple user
roles and a workflow style composition
 Might require multiple views and multiple users and
a central workflow
 Employee enters his request
 Manager reviews and decides on the request
 Notification is sent to the employee
 Currently, mashup development approaches do not
adequately support the creation of applications
supporting the above scenario
 Such applications are called Process Mashups

7. Process Mashups
 Process mashups were first introduced as the
next type of mashups that consider the
integration of business processes (in addition
to data and presentation layers)
 In our opinion, process mashups are more
than simply adding business processes to data
and presentation layers
 Process Mashups should consider multiple
users and multiple pages and organise human
tasks

8. Ingredients of Process
Mashups (1)
 Support for multiple users: enabling multiple users to
concurrently operate on the same instance of a mashup
application. This is different from sharing mashups.
 Motivation: current mashups do not allow multiple users to
concurrently work together on the same instance
 Activities in a process model can be associated to different
actors who will be authorised and assigned different tasks
 Challenges arising:
 Concurrent access: How to support concurrent access of many
users to the same view of the mashup?
 Role-based access: How to support cooperative access of many
users to different views of the mashup based on the role of each
user?

9. Ingredients of Process
Mashups (2)
 Support for navigation among multiple
connected pages: ability to organise
mashup components into a hierarchical
navigation structure which can be explored
via hyperlinks
 Challenges arising:
 Navigation structure: How to structure the
components into a set of well-structured and
connected pages?
 Navigation state: How to keep the state of the
navigation in multi-page mashups?

10. Ingredients of Process
Mashups (3)
 Support for workflows: ability to specify a control and data
flow over human tasks; thus to define sequences, branches,
and conditional executions of work items
 Data mashups are mainly data flow-based mashups without
control flow
 Challenges arising:
 Workflow: how to define a workflow for human actors over
mashups or components of mashups?
 Dataflow: how to propagate data from one task to another task?
 Integration of data, services, UIs, and people: how to coordinate
, not only human actors, but also data, web services, and the UIs
the human actors need to interact with?

11. The New Perspective
 Putting the three dimensions together
results in a variety of different mashup
types with different characteristics

12. Simple Mashups
 Simple Mashups: address single user ,
single page, and do not support workflow
 E.g. employee has an integrated view of
his colleague’s leave requests
 Such mashups serve as informational
sources
 No direct interaction or cooperation with
the manager
 Representative tool: mashArt

13. Simple Mahups – mashArt
 Enables one to abstract
from low-level
implementation details
 Compose simple data
feeds, complex web
services –round construct-
, and UI components
(rectangles) by wiring
events of 1 component to
operations of another
component
 Other examples: Yahoo!
Pipes (data mashups),
Intel MashMaker(UI
mashups)

14. Multi Page Mashups
 Multi page mashups: support a single user,
multiple pages, and no workflow
 E.g. a list of leave requests. Upon selecting
one item from the list, the mashup opens a
new page and displays additional details
about an employee
 Users of such mashups do not interact or
cooperate with other roles
 Representative tool: EzWeb platform

15. Multi Page Mahups – EzWeb
 Users combine and
wire gadgets (mini
applications)
 Gadgets may consist
of multiple screens
arranged according to
a screenflow
 Connections between
screens are
automatically created

16. Guided Mashups
 Guided mashups: address a single user, a single page,
and a workflow
 Offer user guidance to the user in order to accomplish her
task
 React on user’s input and accordingly provide next possible
activities
 E.g. employee invokes a leave request, the mashup
guides the user through the process (after selection of
name, mashups shows leave entitlement period,
employee selects type of leave request)
 Representative tool: We are not aware of guided
mashups tools

17. Page Flow Mashups
 Page Flow Mashups: address a single user,
multiple pages, and a workflow
 E.g. a mashup supporting the manager to
handle a leave request. One page provides
a list of incoming leave requests. Another
page to request additional information if
necessary. A 3rd page provides stats about
all leave requests
 Representative tool: ServFace Builder

18. Page Flow Mahups – ServFace
Builder
 WYSIWYG approach
 Service composition at
the presentation layer
 Compose web services
using their frontends
 Applications = a set of
pages connected to
create a navigation flow
 Connections between
services define dataflow
 Connections between
pages define control
flow

19. Shared Page Mashups
 Shared page mashups: address multiple users, a
single page, and support no workflow
 E.g. the Amazon.com shopping together mashup
(on Programmableweb.com) enables users to shop
together through MSN Messenger. Users browse
the catalogue and chat to each other
 Different employees working simultaneously on a
single leave request
 Representative tool: we are not aware of any
mashup tool for this category.

20. Shared Space Mashups
 Shared space mashups: address multiple users,
multiple pages, and do not support workflow
 Enable multiple users to concurrently share space
= collection of mashup pages connected together
and have a navigational structure.
 E.g. employee shares pages with his manager and
a temporary replacement. Manager previews
previous leave requests of the employee
 Representative tool: IBM Mashup Centre, a
collection of tools to create shared mashup pages.

21. Cooperative Mashups
 Cooperative mashups: address multiple
users, a single page, and support workflow
 E.g. employees jointly view a conflict on
one page and decide which leave request
to remove. The interaction between the
employees is guided
 Representative tool: Gravity (within the
Google Wave environment)

22. Cooperative Mashups -Gravity-
 A lightweight collaborative
business process modelling
tool
 Targets non-BPM-experts
 Multiple users can model a
business process (model
view) and its UI (application-
design view) at the same
time
 Users can drag and drop
components and draw lines
 Supports multiple-users
control flow, and data flow

23. Process Mashups
 Process mashups: address multiple users,
multiple pages, and support workflow
 E.g. a mashup providing the employee with a
web page allowing him to configure his travel
arrangements (flight, hotel) and the manager
with a page to decide on the employee’s
request. These two pages / tasks can be put
into a cycle that terminates one a decision is
made.
 Representative tool: MarcoFlow platform

24. Process Mashups – MarcoFlow
Platform
 Based on the idea of distributed
orchestration of UIs
 Users can bring together UIs, web
services, and people in a single
orchestration logic, language, and
tool
 Covers: design –visual editor-,
deployment –code generators-,
and execution (distributed runtime
environment)
 The coordination problem is split
into two levels: intra-page UI
synchronisation and distributed UI
synchronisation and web service
orchestration , and to provide
runtime environments to both
client side and server side
environments
 Other tools: JOpera allows the
definition of interaction logic
between components and multiple
users - no support for UI comp

25. Findings and Issues (1)
 We were not able to always provide representative
platforms for all mashup classes (e.g. guided mashups and
shared page mashups)
 End users –especially non-programmers- are always looking
for ease of development, so “easiness to use” and “user-
friendliness” are must have criteria for successful mashups
tools
 Mashups tools should focus on the end user in order to
accommodate their skills (e.g. inability to program)
 Sadly, more user friendliness and simplicity often mean less
expressiveness and complexity (of resulting applications)

26. Findings and Issues (2)
 MarcoFlow satisfies alls dimensions of process mashups but is
still considered a complex tool for web users, so can we really
consider MarcoFlow a mashup platform?
 Runtime support: coordinating different actors requires
software support that is long running and sometimes stateful.
 The need for adequate identification and authentication
mechanisms in case of multiple users in the execution
environment
 Developing process mashups is not a trivial task and requires
application planning (defining user roles), design (UI design),
composition (workflow, coordination of actors), implementation
and execution (runtime configuration).

27. THANK YOU!