Kolloquium in Oldenburg

1. Automatische Generierung von
Bedienungsanleitungen für Services
Karsten Wolf
Universität Rostock

2. 2
Service-Orientierte Architektur
Service
Provider
Service Broker
Service
Requester
publishfind
bind
Signatur
Semantik
Verhalten
Nichtfunktionale Eigenschaften

3. 3
Beispiel
Getränkeautomat Verhalten: Service-Automat
€
C T
B
?€
?C ?T
!B !B
?

4. 4
Service-Automaten Praxis
BPEL-Prozess
offenes
Petrinetz
Service-Automat
Vollständige PN-Semantik für BPEL
[BPM 2005], [WS-FM 2007]
Zustandsraum
Petrinetztheorie
„Regionentheorie“
[Modellierung 2008]

5. 5
Was publizieren?
Ein Vorschlag: „Public View“ = Abstrakte Version des
Service
?

6. 6
Dieser Vorschlag im Beispiel
Provided Service
€
C T
Service
Requester
Public View
• Münze fällt
•Mechanismus
aktiviert Knöpfe
•Knopf löst Heizung
aus
•Tasse wird gefüllt

7. 7
Dieser Vorschlag im Beispiel
Provided Service
€
C T
Service
Requester
Bedienungs-
anleitung
• Wirf Münze ein!
• Drücke Knopf!
• Entnimm Tasse!

8. 8
Was publizieren?
Ein Vorschlag: „Public View“ = Abstrakte Version des
Service
Unser Vorschlag: Beschreibung des Verhaltens aller
Requester [Petri Nets 2007]
?

9. 9
Beispiel
?€
?C ?T
!B !B
Getränkeautomat
!€
!C
?B
Partner
!€ !C
?B
Kein Partner
1
2
3
4
5
6
7 8
9
10
11 12
13
[1,5,-] [2,5,€]
[2,6,-] [3,5,€C]
[3,7,-] [3,6,C]
[3,9,B] [4,9,-]
[10,5,-]
[11,5,€] [12,5,C]
[11,6,-]

10. 10
Bedienungsanleitung
eines provided Service P ist
Operationelle Beschreibung aller Partner von P

11. 11
Bedienungsanleitung
?€
?C ?T
!B !B
!€
!C
?B
!€
!T
?B
!T
!€
?B
!C
!€
?B
!€
!C
?B
!T
?B
....
!€
!€ !€
!T
!T !C
!C
?B ?B

12. 12
Bedienungsanleitung
!€
!C
?B
!€
!T
?B
!T
!€
?B
!C
!€
?B
!€
!C
?B
!T
?B
....
!€
!€ !€
!T
!T !C
!C
?B ?B
Liberalster Partner (ex. immer!)

13. 13
Bedienungsanleitung
!€
!C
?B
!€
!T
?B
!T
!€
?B
!C
!€
?B
!€
!C
?B
!T
?B
....
!€
!€ !€
!T
!T !C
!C
?B ?B
!€!€ !€
!T
!T !C
!C
?B ?B
!T∨!€∨!C
!T∨!C

14. 14
Bedienungsanleitung
= Implizite Beschreibung aller Partner
!€
!C
?B
!€
!T
?B
!T
!€
?B
!C
!€
?B
!€
!C
?B
!T
?B
....
!€
!€ !€
!T
!T !C
!C
?B ?B
!€!€ !€
!T
!T !C
!C
?B ?B
!T∨!€∨!C
!T∨!C

15. 15
Berechnung
Wie geht das?
Gleich die
Ergebnisse?

16. 16
Berechnung liberalster Partner
?€
?C ?T
!B !B
5
6
7 8
9
Schritt 1: Überapproximation beliebiger
Partner
(5,-
)
!€
!C
!T
(5,C
)
(5,€),
(6,-)
(5,T
)
!T
!€
(5,CT
)
(5,C€),(6,C),(7,-),
(9,B)
!€
?B
!T
!C
!T
!C
!€
?B
!C
(5,T€),(6,T),(8,-),
(9,B)
(9,-)
(5,C€T),(6,CT),(7,T),
(8,C),(9,T)

17. 17
Berechnung liberalster Partner
?€
?C ?T
!B !B
5
6
7 8
9
Schritt 2: Streiche Zustände mit
Deadlocks
(5,-
)
!€
!C
!T
(5,C
)
(5,€),
(6,-)
(5,T
)
!T
!€
(5,CT
)
(5,C€),(6,C),(7,-),
(9,B)
?B
!C
!T
!C
!€
?B
(5,T€),(6,T),(8,-),
(9,B)
(9,-)
!€
!T
!C
(5,C€T),(6,CT),(7,T),
(8,C),(9,T)

18. 18
Berechnung liberalster Partner
?€
?C ?T
!B !B
5
6
7 8
9
Schritt 3: Neubewertung
(5,-
)
!€
!C
!T
(5,C
)
(5,€),
(6,-)
(5,T
)
!T
!€
(5,CT
)
(5,C€),(6,C),(7,-),
(9,B)
?B
!C
!T
!C
!€
?B
(5,T€),(6,T),(8,-),
(9,B)
(9,-)
(9,B)
(9,B)

19. 19
Berechnung liberalster Partner
?€
?C ?T
!B !B
5
6
7 8
9
Schritt 4: Wiederhole, bis deadlockfrei
(5,-
)
!€
!C
!T
(5,C
)
(5,€),
(6,-)
(5,T
)
!€
(5,C€),(6,C),(7,-),
(9,B)
?B
!C
!T
!T
(5,CT
)
!C
!€
?B
(5,T€),(6,T),(8,-),
(9,B)
(9,-)

20. 20
Annotationen
?€
?C ?T
!B !B
5
6
7 8
9
= „Falls Prov keinen Übergang hat,
halte mind. einen bereit!“
(5,-
)
!€
!C
!T
(5,C
)
(5,€),
(6,-)
(5,T
)
!€
(5,C€),(6,C),(7,-),
(9,B)
?B
!C
!T
!€
?B
(5,T€),(6,T),(8,-),
(9,B)
(9,-)

21. 21
Annotationen
?€
?C ?T
!B !B
5
6
7 8
9
(5,-
)
!€
!C
!T
(5,C
)
(5,€),
(6,-)
(5,T
)
!€
(5,C€),(6,C),(7,-),
(9,B)
?B
!C
!T
!€
?B
(5,T€),(6,T),(8,-),
(9,B)
(9,-)
= „Falls Prov keinen Übergang hat,
halte mind. einen bereit!“

22. 22
Annotationen
?€
?C ?T
!B !B
5
6
7 8
9
!C∨!T∨!
€
!€
!C
!T
!€
!C∨!T
!€
!€
?B
?B
!C
!T
!€
?B
?B
= „Falls Prov keinen Übergang hat,
halte mind. einen bereit!“

23. 23
Größe realer Bedienungsanleitungen
Tool: FIONA (HU Berlin + Uni Rostock)
Benchmark:
34 Services aus BPEL
20 Services von MEGA (KMU)
2 Services von GEDILAN (KMU)
4 Services aus BPEL-SPEC
8 Services aus Büchern/Tutorials
BPEL oder BPEL-Engines
40 Services aus UML-Aktivitäts-
diagrammen
(Schadensfallabwicklung einer
Versicherung)
Bestellung Hauslieferung
Contract Negotiation
Customer Service
Deliver finished goods
Dringende Bestellung
Eingang Einkauf
Einkauf Antrag
Kreditantrag vorbereiten
Normale Bestellung
Quotation Requisition
Reisereservierung
Ticket-Reservierung
Ticket-Schalter
OrderingServiceProcess
auctionService
loanApprovalProcess
purchaseOrderProcess
AusstellungPersonalausweis
Melderegisterauskunft
olive_prep
VacationRequest
SalesforceFlow
ResilientFlow
QuoteTracker
OrderApproval
HelpDeskServiceRequest
FlightBookingFlow
Breakdown analysis
Car Return
Car repair
Car Pickup
Reschedule
Reservations

24. 24
Größe realer Bedienungsanleitungen
Tool: FIONA (HU Berlin + Uni Rostock)
Größe Bedienungsanleitungen
1
10
100
1000
10000
100000
1000000
0 50 100 150 200 250 300 350 400
Knoten PN
KantenOG
Kanten OG

25. 25
Größe realer Bedienungsanleitungen
Tool: FIONA (HU Berlin + Uni Rostock)
Berechnungszeit OG
1
10
100
1000
0 50 100 150 200 250 300 350 400
Knoten PN
Zeit(sec)
Zeit

26. 26
Wie finden?
?
= Simulation ROG und Prüfung der Annotationen
Zustand von R
Zustand OG
!a∨(?b∧?c)
Simulations-
relation
!a ?b
Belegung: a,b: true
c: false

27. 27
Service-Orientierte Architektur
publishfind
bind
?€
?C ?T
!B !B
!€!€ !€
!T
!T !C
!C
?B ?B
!T∨!€∨!C
!T∨!C
!€!€ !€
!T
!T !C
!C
?B ?B
!T∨!€∨!C
!T∨!C
!€
!T !C
?B ?B

28. 28
Anwendung 1: Service-Discovery
• Registry (Broker) speichert Bedienungsanleitungen
• Requester sendet Public View oder
Bedienungsanleitung
• Matching beim Broker
Auswahl passender Services
Aktuelle Forschung: Gestaltung eines Repository
= Datenstruktur für Menge von
Bedienungsanleitungen

29. 29
Variante: „Ich will Kaffee!“
• Gewünschtes Verhalten/Unerwünschtes Verhalten
als Automat C (= „Constraint“) spezifizieren
• R⊕C mit Bedienungsanleitung matchen
 Es matchen die Bedienungsanleitungen von
denjenigen Services, die C genügen
[BPM 2007]

30. 30
Anwendung 2: Requester generieren
• Erinnerung: Bedienungsanleitung ist operationell!
• Constraint C formulieren
• Produkt von C und OG bilden
Operationelle Beschreibung von R
[BPM 2007]

31. 31
Anwendung 3: Vertragsbasierte
organisationsübergreifende Prozesse
Limit Ltd.
Corpus Corp.
Park Bank
-Workflownetz
-schwach sound
Vertrag:

32. 32
VetragPublic Views
Corpus Corp. Park BankLimit Ltd.

33. 33
Public view  Private view
Park Bank

34. 34
Private views  Tatsächliches System
Park Bank
Ziel: System
schwach sound
Kriterien lokal
prüfbar

35. 35
Lösung
Kriterium: Partners(Public view)  Partners(Private View)
Verifikation:
Simulationsbeziehung zwischen OG(Public View)
und OG(Private View) derart, dass Implikation der
annotierten Formeln gültig ist
[WS-FM 2007]

36. 36
Anwendung 4: Testen
• geg.: Spezifikation S als BPEL-Prozess
• geg.: Implementation I als (Java,...)-Code
• brauchen zum Testen von I: Partner
nehmen Bedienungsanleitung von S
[Aktuelle Arbeiten]

37. 37
Anwendung 5: Adaptergenerierung
• geg.: R,P, nicht Partner voneinander
• ges.: Adapter so, dass R⊕A⊕P passend
A Partner von R⊕P‘
Bedienungsanleitung hilft bei der Suche
[DFG-Projekt „Verhaltensadapter“]

38. 38
Ausblick
• Bedienungsanleitungen für Multi-Partner-Services
– Problem: separate OG „Cartesian Closed“
• andere Korrektheitsbegriffe
– Livelockfreiheit, garantierte Terminierung
• alternative Nachrichtenmodelle
– synchron/asynchron; semantische Abhängigkeiten
[DFG-Projekt „Bedienungsanleitungen“]

39. 39
Fazit
• Bedienungsanleitungen sind nützliches Vehikel für
allerlei Probleme des SOC
• Berechnung trotz theoretisch hoher Komplexität
machbar (Model Checking Technologie kommt noch)
• Bezug zur Praxis durch bidirektionale Übersetzung zu
BPEL
• Varianten & Anwendungen: Work in Progress
• Verhalten orthogonal zu Signatur, Semantik,
nichtfunktionalen Eigenschaften