Your SlideShare is downloading. ×
Lighweight Collaboration Management (Mashups09@OOPSLA)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lighweight Collaboration Management (Mashups09@OOPSLA)

694

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
694
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. Agenda 2 Collaboration Management Prototype Architecture Conclusion 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  • 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. 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. 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. 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. 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. Example Collaboration Process 9 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  • 9. make a plan communicate coordinate
  • 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. 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. 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. Trace & Evaluate 14 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  • 14. 15 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  • 15. 16 25 October 2009 | 3rd International Workshop on Web APIs and Services Mashups
  • 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. 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. 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. 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. 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. 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

×