• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Lighweight Collaboration Management (Mashups09@OOPSLA)
 

Lighweight Collaboration Management (Mashups09@OOPSLA)

on

  • 1,138 views

Matthias Kunze, Alexander Großkopf, Hagen Overdick and Matthias Weidlich -- Lightweight Collaboration Management

Matthias Kunze, Alexander Großkopf, Hagen Overdick and Matthias Weidlich -- Lightweight Collaboration Management

Statistics

Views

Total Views
1,138
Views on SlideShare
977
Embed Views
161

Actions

Likes
0
Downloads
10
Comments
0

4 Embeds 161

http://www.mashup-oopsla.org 146
http://mashup.inf.unisi.ch 10
http://www.slideshare.net 3
http://jisi.dreamblog.jp 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Lighweight Collaboration Management (Mashups09@OOPSLA) Lighweight Collaboration Management (Mashups09@OOPSLA) Presentation Transcript

    • 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