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

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

Grundlagen

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

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

Grundlagen Bespiel-Geschäftsprozess mit Human-Task

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)

Architekturbeschreibung

Architekturbeschreibung Aufbau des HT-Service

Architekturbeschreibung Aufbau des HT-Service

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Ablauf des Serviceaufrufs

Architekturbeschreibung Grundlegende Anwendungsfälle

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

Architekturbeschreibung Komponentendiagramm

Architektur eines Human-Task-Service Headline

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

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

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

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

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

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

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

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

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

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

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

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

Architekturbewertung

Architekturbewertung Vergleich mit BPEL4People

Architekturbewertung Vergleich mit BPEL4People

Architekturbewertung Vergleich mit BPEL4People

Architekturbewertung Vergleich mit BPEL4People

Architekturbewertung Vergleich mit BPEL4People

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

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

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

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

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

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

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

Fazit

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

Fragen