Post on 11-May-2015
description
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
Lightweight Collaboration ManagementMatthias KunzeAlexander GrosskopfHagen OverdickMatthias 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
5
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
Implicit Processes
Collaboration is coordinated work, yet the notion of a process is often neglected
• participants
• tasks
• deliverables (input/output)
The flow-oriented nature of workflow processes makes the Petri net formalism
a natural candidate for the modeling and analysis of workflows. Most workflow
management systems provide a graphical language which is close to Petri nets.
Although the routing elements are different from Petri nets, the informal se-
mantics of the languages used are typically token-based and hence a (partial)
mapping is relatively straightforward. A characteristic of workflow processes is
that they are typically case-oriented, i.e., processes can be instantiated for mul-
tiple cases but the life-cycles of different cases do not get intertwined. This can
be illustrated using Figure 1. The process represented by the “cloud” can be
instantiated by putting tokens on the input place start. Each of these tokens
represents the creation of a particular case. The goal is that after a while there
will be a token in output place end for each initiated case.
Fig. 1. A WF-net is a Petri net with a start and an end place. The goal is that a caseinitiated via place start successfully completes by putting a token in place end.
This paper focuses on processes having the structure shown in Figure 1.
These are so-called workflow nets (WF-nets). WF-nets were introduced in [1, 2].
Together these two papers got more than one thousand references illustrating
the interest in the topic.3
In the context of WF-nets a correctness criterion called
soundness has been defined [1, 2]. A WF-net such as the one sketched in Figure 1
is sound if and only if the following three requirements are satisfied: (1) optionto complete: for each case it is always still possible to reach the state which just
marks place end, (2) proper completion: if place end is marked all other places
are empty for a given case, and (3) no dead transitions: it should be possible
to execute an arbitrary activity by following the appropriate route through the
WF-net. In [1, 2] it was shown that soundness is decidable and that it can be
translated into a liveness and boundedness problem, i.e., a WF-net is sound if
and only if the corresponding short-circuited net is live and bounded.
Since the mid-nineties many people have been looking at the verification
of workflows. These papers all assume some underlying model (e.g., WF-nets)
and some correctness criterion (e.g., soundness). Hence there are two dimensions
when considering workflow verification:
3 In fact, [2] is the second most cited workflow paper after [32] according to GoogleScholar (visited on January 9th, 2008).
2
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
Deficiencies of Implicit Processes
• not transparentparticipants miss the big picture
• not consistentuncoordinated messages and inconsistent information
• not efficientdecentralized coordination breaks the flow of work
6
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
Explicit Processes
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
7
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
Collaboration Management
• coordinate through messages
• directed
• globally visible
• correlated
• minimize distractions: do not introduce new tools
• make process explicitly visible
8
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
Example Collaboration Process
9
make a plan communicate coordinate
Make a Plan
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
11 • “Modeling as a Service”
• web-based modeling platform
• model is a hypertext resource
• sharing via OpenId
oryx-project.org
Communicate
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
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
twitter.com
Twitter UI
Twitter API
oryx-project.org
Oryx UI
Oryx API
R
create processmodel
R
read and write twitter messages
Xenodot
model importer execution engine
processlanguages
processmodels
processinstances
R R
classic mashupUI
classic mashuplogic
R
Rfollow URLs, get process
instance information
• Xenodot is implementation platform
• executes semantics of modeling language
• persists and drives state of instances
• people interact with original web applications
• “map”-mashup to trace and evaluate process
LCM Logic
MashupLogic
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)
• typical architecture [6,9,19,22,24]
• intermediary to users
• proxy to services
• proprietary user interface
• web API as alternative interfaceWeb API1 Web APIn
Mashup Logic
R
R
R
UI1 UIn
Web API1 Web APIn
Mashup Logic
R
R
R
R
Mashup UI
Web App1 Web Appn
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)
• system integration patterns
• bus among web apps
• invisible to users
• retains web apps’ UIs
• Web APIs as complementary interface
Web API1 Web APIn
Mashup Logic
R
R
R
UI1 UIn
Web API1 Web APIn
Mashup Logic
R
R
R
R
Mashup UI
Web App1 Web Appn
Web App1 Web Appn
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
Is it still a mashup?
• co-create value through combination
• combine services with heterogeneous interfaces
• use lightweight web technologies: HTTP, JSON, JavaScript
• address situational needs
• small scale
21
25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
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
23
Conclusion
Matthias Kunze | Alexander Grosskopf | Hagen Overdick | Matthias WeidlichBusiness Process Technology Group Hasso Plattner Institute at the University of Potsdam matthias.kunze@hpi.uni-potsdam.de
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“