lighweight collaboration management (mashups09@oopsla)

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

Lightweight Collaboration ManagementMatthias KunzeAlexander GrosskopfHagen OverdickMatthias Weidlich


Agenda

2

Collaboration Management

Prototype

Architecture

Conclusion


People

3 • live in the Web

• work in the Web

• collaborate in the web

5


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


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


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



• coordinate through messages

• directed

• globally visible

• correlated

• minimize distractions: do not introduce new tools

• make process explicitly visible

8


Example Collaboration Process

9

make a plan communicate coordinate

Make a Plan


11 • “Modeling as a Service”

• web-based modeling platform

• model is a hypertext resource

• sharing via OpenId

oryx-project.org

Communicate


12 • feature-rich messaging service

• directed: @mashups09

• globally visible

• correlated

• 140 characters

• quick comprehension

• fast response


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


Trace & Evaluate

14


15


16


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


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


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


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



• 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 [email protected]

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“

mailto:[email protected]

mailto:[email protected]

lighweight collaboration management (mashups09@oopsla)

Technology

web work

rd international workshop

services mashups

usersrweb api1 web apin

classic mashup architecture

reverse mashup architecture

end place

mashup ui intermediary