Architektur eines Human-Task-Service

Präsentation zum Thema: "Architektur eines Human-Task-Service"—  Präsentation transkript:

1 Architektur eines Human-Task-Service
Daniel Grawunder Architektur eines Human-Task-Service Dresden · Frankfurt/Main · Leipzig · München · Hamburg · Görlitz · Berlin

2 Gliederung Einführung zu Human-Tasks
Grundlagen/Gemeinsamkeiten von HTs Bespielprozess Funktionale Anforderungen an den HT-Service Architekturbeschreibung Aufbau der HT-Service-Architektur Ablauf des HT-Service-Aufrufs Komponenten Nichtfunktionale Anforderungen Architekturbewertung Vergleich mit BPEL4People Vorteile/Herausforderungen Fazit/Fragen

3 Grundlagen

4 Grundlagen Was sind Human-Tasks?
Allgemein: Menschliche Beteiligung an einem Geschäftsprozess Geschäftsprozessschritte die von Menschen ausgeführt werden Im SOA-Kontext: Services die von Menschen implementiert werden Fachliches Wissen der Menschen stellt die Implementierung dar HT-Service stellt Infrastruktur bereit

5 Grundlagen Gemeinsamkeiten von Human-Tasks
Oftmals ähnliche Aufgabenstellung Bestätigung Prüfung Notification Benötigte Informationen Wer kann die Aufgabe erfüllen (Bearbeiter, Rollen, Rechte) Was ist zu tun (Aufgabenstellung) Womit (Ein- und Ausgabedaten) Schlussfolgerung für einen HT-Service: Generische Infrastruktur-Komponente Konfigurierbar für konkrete Human-Tasks

6 Grundlagen Bespiel-Geschäftsprozess mit Human-Task

7 Grundlagen Funktionale Anforderungen an den HT-Service
Konfiguration des HT-Service mittels Task-Beschreibungen (Wer, Was, Womit) Verteilung der Aufgeben an potentielle Bearbeiter Daten zur Präsentation Extraktion von benötigten Daten Informationen über die Ergebnisdaten Geschäftsprozess kann HT-Service aufrufen und Task-Instanz (TI) erstellen BPEL-Prozess besitzt keine HT-spezifischen Informationen Bearbeiter muss mit HT-Service interagieren Authentifizierung/Autorisierung Übersicht vorhandener TIs (Task-Liste) Reservierung und Bearbeitung von TIs (Task-Detail-Sicht)

8 Architekturbeschreibung

9 Architekturbeschreibung
Aufbau des HT-Service

10 Architekturbeschreibung
Aufbau des HT-Service

11 Architekturbeschreibung
Ablauf des Serviceaufrufs

12 Architekturbeschreibung
Ablauf des Serviceaufrufs

13 Architekturbeschreibung
Ablauf des Serviceaufrufs

14 Architekturbeschreibung
Ablauf des Serviceaufrufs

15 Architekturbeschreibung
Ablauf des Serviceaufrufs

16 Architekturbeschreibung
Ablauf des Serviceaufrufs

17 Architekturbeschreibung
Ablauf des Serviceaufrufs

18 Architekturbeschreibung
Ablauf des Serviceaufrufs

19 Architekturbeschreibung
Grundlegende Anwendungsfälle

20 Architekturbeschreibung
Anforderungen an die Komponenten HTP Serviceschnittstelle für Akteur Geschäftsprozess Bereitstellung der HT-spezifischen Daten (Task-Beschreibungs-Referenz) Instanziierung von HTs in HTI, Weiterleitung fachliches Dokument an HTI Weiterleitung Ergebnisdokument an Geschäftsprozess HTI Erstellung und Verwaltung der Task-Instanzen Bearbeiterverwaltung/Rechtemanagement Präsentation der Task-Liste/Task-Detail-Sicht Verarbeitung der Bearbeitereingaben/Erstellung Ergebnisdokument Persistente Speicherung aller Artefakte

21 Architekturbeschreibung
Komponentendiagramm

22 Architektur eines Human-Task-Service
Headline

23 Architekturbeschreibung
Vorteile der Trennung in TVK und TPK Speicherung des Zustands der HTs in der TVK Unterstützung verschiedener Darstellungs- Clients durch unterschiedliche TPKs Integration verschiedener TVKs durch eine TPK Bessere Möglichkeiten für die Skalierbarkeit der HT-Service-Komponenten

24 Architekturbeschreibung
Vorteile der Trennung in TVK und TPK Speicherung des Zustands der HTs in der TVK Unterstützung verschiedener Darstellungs- Clients durch unterschiedliche TPKs Integration verschiedener TVKs durch eine TPK Bessere Möglichkeiten für die Skalierbarkeit der HT-Service-Komponenten

25 Architekturbeschreibung
Vorteile der Trennung in TVK und TPK Speicherung des Zustands der HTs in der TVK Unterstützung verschiedener Darstellungs- Clients durch unterschiedliche TPKs Integration verschiedener TVKs durch eine TPK Bessere Möglichkeiten für die Skalierbarkeit der HT-Service-Komponenten

26 Architekturbeschreibung
Vorteile der Trennung in TVK und TPK Speicherung des Zustands der HTs in der TVK Unterstützung verschiedener Darstellungs- Clients durch unterschiedliche TPKs Integration verschiedener TVKs durch eine TPK Bessere Möglichkeiten für die Skalierbarkeit der HT-Service-Komponenten Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

27 Architekturbeschreibung
Nichtfunktionale Anforderungen Performance Skalierbarkeit Sicherheit Ausfallsicherheit Erweiterbarkeit/Wartbarkeit Manageablity Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

28 Architekturbeschreibung
Performance Performance-Engpass => Nicht-Einhaltung vorgegebener SLAs Performance aus Sicht des Geschäftsprozess Service-Provider-Antwortzeit Nachrichten-Laufzeit Marshalling/Demarshalling Service-Provider-Bearbeitungszeit Performance aus Sicht des Bearbeiters Verzögerung Darstellung der Task-Liste Verzögerung Darstellung der Task-Detail-Sicht Verarbeitungszeit der Benutzereingaben Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

29 Architekturbeschreibung
Skalierbarkeit Mehrere TVKs mit dediziertem Datenspeicher Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

30 Architekturbeschreibung
Skalierbarkeit Mehrere TVKs mit gemeinsamen Datenspeicher Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

31 Architekturbeschreibung
Skalierbarkeit Mehrere TVKs und TPKs Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

32 Architekturbeschreibung
Sicherheit Anforderungen an Sicherheit Authentifizierung u. Autorisierung des Bearbeiters Authentifizierung u. Autorisierung des Service-Benutzers Sicherung der Vertraulichkeit und Integrität während des Datenaustauschs Auditing von sicherheitsrelevanten Aktionen Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

33 Architekturbeschreibung
Sicherheit Einsatz einer „demilitarisierten Zone“ Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

34 Architekturbeschreibung
Ausfallsicherheit/Erweiterbarkeit/Manageability Ausfallsicherheit Hochverfügbarkeit der Komponenten Wiederherstellung des Zustands nach Systemneustart Erweiterbarkeit Erstellung von HTPs für neue HT-Service-Instanzen Konfiguration der HTI durch Task-Beschreibungen Manageability Monitoring Administration Archivierung Eventuell Skalierbarkeit/Performance/Ausfallsicherheit noch mal als extra Thema

35 Architekturbewertung

36 Architekturbewertung
Vergleich mit BPEL4People

37 Architekturbewertung
Vergleich mit BPEL4People

38 Architekturbewertung
Vergleich mit BPEL4People

39 Architekturbewertung
Vergleich mit BPEL4People

40 Architekturbewertung
Vergleich mit BPEL4People

41 Architekturbewertung
Vorteile gegenüber BPEL4People Trennung zwischen Prozessschicht und HT- Schicht Auslagerung von HT-spezifischer Prozesslogik in den HTP Einheitliche Kategorisierung von Services und Zuordnung von Verantwortlichkeiten Umsetzung von Sicherheitsstrategien Einfache Umsetzung von komplexen Interaktionsmustern

42 Architekturbewertung
Vorteile gegenüber BPEL4People Trennung zwischen Prozessschicht und HT- Schicht Auslagerung von HT-spezifischer Prozesslogik in den HTP Einheitliche Kategorisierung von Services und Zuordnung von Verantwortlichkeiten Umsetzung von Sicherheitsstrategien Einfache Umsetzung von komplexen Interaktionsmustern

43 Architekturbewertung
Vorteile gegenüber BPEL4People Trennung zwischen Prozessschicht und HT- Schicht Auslagerung von HT-spezifischer Prozesslogik in den HTP Einheitliche Kategorisierung von Services und Zuordnung von Verantwortlichkeiten Umsetzung von Sicherheitsstrategien Einfache Umsetzung von komplexen Interaktionsmustern

44

45 Architekturbewertung
Vorteile gegenüber BPEL4People Trennung zwischen Prozessschicht und HT- Schicht Auslagerung von HT-spezifischer Prozesslogik in den HTP Einheitliche Kategorisierung von Services und Zuordnung von Verantwortlichkeiten Umsetzung von Sicherheitsstrategien Einfache Umsetzung von komplexen Interaktionsmustern

46 Architekturbewertung
Vorteile gegenüber BPEL4People Trennung zwischen Prozessschicht und HT- Schicht Auslagerung von HT-spezifischer Prozesslogik in den HTP Einheitliche Kategorisierung von Services und Zuordnung von Verantwortlichkeiten Umsetzung von Sicherheitsstrategien Einfache Umsetzung von komplexen Interaktionsmustern

47 Architekturbewertung
Vorteile gegenüber BPEL4People 4-Eyes-Principle Trennung zwischen Prozessschicht und HT- Schicht Auslagerung von HT-spezifischer Prozesslogik in den HTP Einheitliche Kategorisierung von Services und Zuordnung von Verantwortlichkeiten Umsetzung von Sicherheitsstrategien Einfache Umsetzung von komplexen Interaktionsmustern Chained-Execution

48 Architekturbewertung
Herausforderungen Starke Asynchronität des Serviceaufrufs Wiederholte Erstellung (fast) identischer HTPs

49 Fazit

50 Fazit Pragmatische Lösung zur Integration von HTs in Standard-BPEL-Prozesse Ausgangspunkt und Diskussionsgrundlage für die Implementierung Technologieneutrale Architektur, könnte selbst mit BPEL4People realisiert werden

51 Fragen