Lightweight Collaboration
Management
Matthias Kunze
Alexander Grosskopf
Hagen Overdick
Matthias Weidlich
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Agenda
2
Collaboration Management
Prototype
Architecture
Conclusion
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

People
3 • live in the Web
• work in the Web
• collaborate in the web
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

ough the routing elements are different from Petri nets, the informa
tics of the languages used are typically token-based and hence a (par
ping is relatively straightforward. A characteristic of workflow process
Implicit Processes
they are typically case-oriented, i.e., processes can be instantiated for
casesCollaboration is coordinated work, yet not get intertwined. This
5 but the life-cycles of different cases do the notion of a
lustrated using Figureneglected
process is often 1. The process represented by the “cloud” ca
antiatedparticipants tokens on the input place start. Each of these to
• by putting
esents the creation of a particular case. The goal is that after a while t
• tasks output place end for each initiated case.
be a token in
• deliverables (input/output)
1. A WF-net is a Petri net with a start and an end place. The goal is that a
ated via October 2009 | 3 International Workshop on completes byMashups
25 place start successfully Web APIs and Services putting a token in place end.
rd

Deficiencies of Implicit Processes
6 • not transparent
participants miss the big picture
• not consistent
uncoordinated messages and inconsistent information
• not efficient
decentralized coordination breaks the flow of work
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Explicit Processes
7 make a plan
• identify tasks and deliverables
• order tasks by dependency (allow concurrency)
• assign tasks to participants
communicate & coordinate
• take action
• coordinate by means of the plan
trace & evaluate
• monitor and give insights
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Collaboration Management
8 • coordinate through messages
• directed
• globally visible
• correlated
• minimize distractions:
do not introduce new tools
• make process explicitly visible
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Example Collaboration Process
9
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

make a plan communicate coordinate

Make a Plan
11 • “Modeling as a Service”
• web-based modeling platform oryx-project.org
• model is a hypertext resource
• sharing via OpenId
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Communicate
12 • feature-rich messaging service
• directed: @mashups09
• globally visible
• correlated
• 140 characters
• quick comprehension
• fast response
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Coordinate
13 • document based storage
and execution engine
• language – behavior (domain logic)
• model – scenario
• instance – state of actual case
• coordination via commands
• @participant <task-instance> start <description>
• @robot <task-instance> done
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Trace & Evaluate
14
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

15
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

16
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Architecture
18 • Xenodot is implementation
platform
•
follow URLs,
executes semantics of create process R
R get process
instance information
model
modeling language
R
read and write
twitter messages
• persists and drives Oryx UI Twitter UI
classic mashup
UI
state of instances oryx-­project.org twitter.com
Oryx API Twitter API
Mashup R R
R
• people interact with Logic
model importer execution engine
classic mashup
logic
original web applications Xenodot
process process process
• “map”-mashup to trace LCM
languages models instances
and evaluate process Logic
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Classic Mashup Architecture
19 • aggregates resources into one UI
• instant, real-time insight
(mostly information)
R
• typical architecture [6,9,19,22,24]
Mashup UI
• intermediary to users
Mashup Logic
• proxy to services R
R
• proprietary user interface
Web API1 Web APIn
• web API as alternative interface
Web App1 Web Appn
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Reverse Mashup Architecture
20 • orchestrates resources
• continuous observation/
coordination (esp. functionality)
R
R
R
• system integration patterns
Mashup UI UI1 UIn
• bus among web apps
Mashup Logic Web App1 Web Appn
• invisible to users
R
Web API1 Web APIn
R
• retains web apps’ UIs R
Web API1 Web APIn R
• Web APIs as complementary
Web App Web Appn Mashup Logic
interface 1
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Is it still a mashup?
21 • co-create value through combination
• combine services with
heterogeneous interfaces
• use lightweight web
technologies: HTTP, JSON,
JavaScript
• address situational needs
• small scale
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

Conclusion
23 Collaboration Management
• makes implicit processes explicit
• needs a coordinator
Mashup Prototype
• implements lightweight Collaboration Management
• coordinates people unobtrusively on the Web
Reverse Mashup Architecture
• provides coordination platform
• orchestrates Web applications/services behind the scenes
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups

References
24 [6] A. Bradley. Reference Architecture for Enterprise ’Mashups’. Technical report, Gartner
Research, Sep 2007.
[9] L. Clarkin and J. Holmes. Enterprise Mashups. The Architecture Journal, 13:24–28, 2007.
[19] V. Hoyer, K. Stanoesvka-Slabeva, T. Janner, and C. Schroth. Enterprise Mashups: Design
Principles towards the Long Tail of User Needs. In SCC ’08: Proceedings of the 2008 IEEE
International Conference on Services Computing, pages 601–602, Washington, DC, USA,
2008. IEEE Computer Society.
[22] M. Kunze. Business Process Mashups – An Analysis of Mashups and their Value Proposition
for Business Process Management. Master’s thesis, Hasso Plattner Institut an der Universität
Potsdam, 2009.
[24] J. Lopez, A. Pan, F. Ballas, and P. Montoto. Towards a Reference Architecture for Enterprise
Mashups. In Actas del Taller de Trabajo ZOCO’08/JISBD. Integracion de Aplicaciones Web:
XIII Jornadas de Ingenieria del Software y Bases de Datos. Gijon, 7 al 10 de Octubre de
2008, pages 67–76, 2008.
A complete list of references can be found in the paper: „Lightweight Collaboration Management“
Matthias Kunze | Alexander Grosskopf | Hagen Overdick | Matthias Weidlich
Business Process Technology Group
Hasso Plattner Institute
at the University of Potsdam
matthias.kunze@hpi.uni-potsdam.de