Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lighweight Collaboration Management (Mashups09@OOPSLA)

1,248 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Lighweight Collaboration Management (Mashups09@OOPSLA)

  1. 1. Lightweight Collaboration Management Matthias Kunze Alexander Grosskopf Hagen Overdick Matthias Weidlich 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  2. 2. Agenda 2 Collaboration Management Prototype Architecture Conclusion 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Example Collaboration Process 9 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  9. 9. make a plan communicate coordinate
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. Trace & Evaluate 14 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  14. 14. 15 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  15. 15. 16 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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

×