Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( ) Ideas Make the Future Folie 1 OOP 2005: Session Mi 19 Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 2 Zur Person Matthias Hertel Leiter der Entwicklung bei der Firma AP Automation + Productivity AG Realisierung eines ERP Systems für den fertigenden Mittelstand auf der Basis von modernen Internet Technologien: (D)HTML, XHTML, WebServices, eCommerce Siehe auch

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 3 Agenda Sensibilisierung für das Problemfeld (Architektur, Prozesse) Wo liegt das Problem ? UI WebServices Automatisierung von Vorgängen Track and Guide-Pattern Relevanz Proof of Concept Einfache Realisierung Beispiel Abgrenzungen Warum nicht Workflow Andere Patterns

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 4 Focus: Web-Applikationen Service orientierte Applikationen WebService basierte Architekturen Stateless (State = DB-Content) Heute: WebServices als RPC Ersatz Morgen: Asynchroner Austausch von Nachrichten Leicht verständliches Szenario. Die Problematik ist auf komplexere Situationen übertragbar. Browser Web Server Applikations-Server DB Netzwerk Fremd-Systeme Sub-Systeme

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 5 Wo liegt das Problem ? Problemfeld 1: Die veränderten Laufzeitumgebungen Verlust der kompakten Programmierung von Prozessen Implementierung von unabhängigen Services, Wiederverwendbarkeit Problemfeld 2: Neue Anforderungen an Prozess- und Applikations-Kommunikation Leichte Kopplung von Komponenten Trennung von Benutzerführung + Transaktionslogik in Sub-Systeme Beispiel: Buchausleihe Problemfeld 3: Automatisierung von Vorgängen altbekanntes immer noch aktuelles Problem auf Applikationsniveau

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 6 Unternehmen planen Prozesse Üblicherweise wird nur der optimale Prozess definiert Selten auch die Ausnahmen (ad-hoc) Welche Teile des Prozesses sind überhaupt prozessrelevant ? Login Auswahl Antrag Prüfung Abholen Ende

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 7 veränderten Laufzeitumgebungen (1) Programmierung der '80er: Prozess = Maske = Menüeintrag Monolitische Realisierungen (Bananencode) Trennung von Menüsystem und Prozessen war State of the Art Einfache Prozesse, nicht Systeme übergreifend Papier-Schnittstellen Pseudo-Code: Matchcode = SuchMaske(); PrimärerSchlüssel = SelektionsListe(Matchcode); DatensatzMaske(PrimärerSchlüssel); Daten = DatenErfassung (); Transaktion(PrimärerSchlüssel, Daten) ErgebnisAnzeige ()

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 8 veränderten Laufzeitumgebungen (2) Programmierung der '90er Eventgesteuert Prozess = Programm / Modul Prozess innerhalb eines klar abgegrenzten (großen) Programmbereiches Komplexere Prozesse sind möglich Prozesse im Bereich der Benutzerführung werden im Programm Code nicht mehr klar formuliert class DatensatzMaske { Function Button1_OnClick() … Function Button2_OnClick() … }

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 9 Architektur-Problem: kein Prozess Events und die Codierung der passenden Handler sind über viele Dateien, Klassen und WebServices verstreut An keiner Code-Stelle ist der Ablauf des Prozesses implementierbar Probleme: Wie findet man Prozess-Zusammenhänge ? Wo sind Schleichwege ? Wo testen – z. B. nach Änderung eines Sub-Systems ? Richtige Reihenfolge der Bedienungsschritte ? Keine Prozess-ID / Prozess-Referenz

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 10 Message orientierte WebServices Heute: RPC style WebService Aufrufe: aktives Warten auf Antworten Das funktioniert nur bei passenden Protokollen (z.B. http, https) Zukunft: Nachrichtenaustausch ohne direkte Antwort Protokoll unabhängig Routing Keine garantierten Antwortzeiten

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 11 Zeit Problem 1 Unsichere Verbindungen Schlüssel zu Standortübergreifenden Prozessen. Lost Netzwerk-Packages / Resent DNS und Http-Timeouts Nicht verfügbare Sub-Systeme oder externe Kommunikationspartner WAN Übertragungen WAN = zeitkritisch

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 12 Zeit Problem 2 Message orientierte Webservice Verbindungen unterstützt auch sehr lang laufende Anfragen Höhere Ausfallsicherheit keine garantierten Antwortzeiten nicht einmal http-Timeout

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 13 Zeit Problem 3 Benutzerinteraktion Bestandteil einer Prozessdefinition Modellierbar keine garantierte Bearbeitungszeiten (Steuererklärung)

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 14 Problem des aktiven Wartens Ein Prozess wartet auf Antwort… Wie ? Sleep () Nicht wirklich ! Betriebssystem Prozess läuft weiter ! Polling CPU Last Aktiver Thread ? Offener Port und ereignisgesteuerter Programmablauf Typisch für WebServices 1 Port und Dispatcher – System (WebServer) Empfangslogik (Prozessmodell) liegt verteilt in den WebService Methoden

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 15 Automatisierung von Vorgängen Ereignisse Zeit : Zeitpunkt / Zeitdauer Eingehende Nachrichten Eingaben eines Benutzers Ablauf einer Aktion (Sequenzen) Aktionen Transaktionen … Bei der Automatisierung von Vorgängen ist die Erweiterbarkeit und Modellierbarkeit der Prozessmodelle gefragt.

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 16 Login Auswahl Antrag Prüfung Abholen Beispiel: Buchausleihe mit Autorisierung Ende Anfrage manuelle Entscheidung aktuelle Anfragen Entscheidung

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 17 Login Auswahl Antrag Prüfung Abholen Beispiel: Buchausleihe mit Autorisierung Ereignisse (Events) bestimmen die Schlüsselstellen Eingänge und Ausgänge Entscheidungen sind zu treffen Nutzdaten, State sind entscheidungsrelevant (Benutzer, Buch, Anfragestatus) Ende manuelle Entscheidung aktuelle Anfragen Entscheidung Exception Sub-System Anfrage

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 18 Sub-System: manuelle Entscheidung Beispiel für ein Subsystem lang laufender Entscheidungsprozess Aufnahme von zu entscheidenden Fragestellungen Ja / Nein Antworten Eigene kleine Web Applikation Eintragen von neuen Fragen über einen WebService Antworten werden per WebService zurückgegeben Austausch der Nachricht jeweils nur in eine Richtung Keine synchronen (RPC WebService) Entscheidungen

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 19 Sub-System: manuelle Entscheidung Keys: Benutzer + Buch Keine schnelle, datengestützte Entscheidung bei der ein RPC Aufruf möglich wäre Externe Applikation mit eigenem Web. Service Enter Remove Store UIProxy Answer

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 20 Track and Guide-Pattern Umgangsspachlich: Sag' mir was du zu tun gedenkst und ich sage dir wo es lang geht. Ansatz: Sag' mir viel (Alles) Weiche Entscheidung: Benutzerführung Harte Entscheidung: Zugriffsrechte (Role based Security, RBAC, zentrale Kontrolle) Zentrale Implementierung Vermittlung ohne weitere eigene Funktionalität (Benutzerführung) oder aktives Element in der Prozessgestaltung (Modellierung) Name -> Name Mapping Voraussetzung: Funktionen, UI arbeiten mit Referenzen URLs oder Namespaces die auf ein einheitliches Messageschema abgebildet werden können

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 21 Track and Guide-Pattern Time Gleich mehr… Queue Track Guide Messages

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 22

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 23 Fall 1: Aufruf einer Web-Seite newUrl = TAG.UrlRequest (url + "/enter") if (newUrl != null) Redirect(newUrl)... [ Implementierung der Seite ]... void button1.click() { newUrl = TAG.UrlRequest(url + "/call"); if (newUrl != null) Redirect(newUrl); } // button1.click Events: Vor dem Ausführen (Aufbau) der Seite ist zu prüfen, ob der Aufruf zulässig ist. Bei alle Ausgängen (Funktionen / Hyperlinks) wird eine Entscheidung aus dem TAG benötigt. Aufbau der Message: Url der Seite Parameter der Seite Benutzer-ID (implizit) Umleitung Nächster Prozessschritt

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 24 [ Empfangen einer Soap Nachricht ] newUrl = TAG.SoapRequestEnter (namespace + "/func");... [ Ausführung ]... TAG.SoapRequestLeave (namespace + "/func"); return (result); Fall 2: Aufruf eines Webservices zur Kontrolle Events: Vor dem Ausführen der Funktionalität ist zu prüfen, ob der Aufruf zulässig ist. Nach erfolgreichem Ausführen weitere Prozessschritte einleiten. Aufbau der Message: Namespace des WebServices + Name der Methode Enter / Leave Parameter (XMLDom) der Parameter Benutzer-ID (implizit) Exception Time / Queue

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 25 [ Empfangen einer Soap Nachricht ] newUrl = TAG.SoapRequest (namespace + "/func"); // Ausführung im TAG System return; Fall 3: Aufruf eines Webservices zur Automatisierung Explizite Anstoß eines (automatisierten) Prozesses Events: Der Aufruf ist der Event Aufbau der Message: Namespace des WebServices + Name der Methode Parameter (XMLDom) der Parameter Benutzer-ID (implizit) ExceptionTime / Queue

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 26 Implementierung der Entscheidungen Allgemeine Anforderungen: Eigenständiger Prozess (Service) Stateless Keine Hybride Implementierung (kein UI) Notwendige Elemente: Synchroner Aufruf Empfang von Messages eines einheitlichen Schemas Abbilden der Anwendungsfälle auf dieses Message Schema Speicherung von Messages (Time, Queue) Speicherung von Variablen einer Prozessdefinition

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 27 Implementierung der Entscheidungen (Code) Time Queue Track Guide Messages Key = user + book; // keine ProzessInstanz-ID switch (message) { case "../AntragEnter": if (Vars[key, "Genehmigt"] == true) return("../Abholen"); case "../Entscheidung": Vars.Add(key, Erlaubnis); return(null); case "../AbholenLeave": Vars.Delete(key); return(null); case "Timer-Zeitablauf": Vars.Delete(key); return(null); } // switch Variablen Prozess

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 28 Implementierung der Entscheidungen Hintergrundsprozess Der Hintergrundsprozess implementiert nur die Loopbacks der Time und Queue Messages. Der Hintergrundsprozess kann jederzeit beendet und wieder gestartet werden, da er selbst keine lang laufenden Aktivitäten implementiert. Sehr lang laufende, automatische Prozesse sind durch die Queue realisierbar und ebenfalls unterbrechbar Reboot von Servern, Restart ist möglich

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 29 Implementierung der Entscheidungen Entscheidungsfunktionalität Eine kompakte manuelle Codierung ist möglich. Die Entscheidungsfunktionalität wird nur bei Bedarf aufgerufen (SOA). Transaktionsfähig State Speicherung der Variablen (~ Prozess-Instanz) Keine Prozess-Instanz-ID Speicherung von Messages (Time / Queue) Die Speicherung von mehreren Message Objekten ermöglicht nebenläufige Vorgänge.

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 30 Implementierung der Entscheidungen (ML) Problem: BPEL4WS / Workflow Sprachen sind nicht für eine Message zentrierte Modellierung ausgelegt. In BPEL4WS gibt es Events, aber das Prozessabbild wird unüberschaubar. Prozessschritte sind beim TAG Ansatz nur logische Zusammenfassung von Messages in der Modellierung. Ziel: Generierung von Code aus BPEL4WS ähnlichen Metadaten. Software Factories Domain Specific Languages

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 31 "Ähnlichkeiten mit... Patterns Im Unterschied zum State-Pattern bestimmt der Object.State nicht das primäre Verhalten sondern die Message. Interaktion und Schnittstellen sind speziell auf einheitliche Nachrichten zugeschnitten. Namespaces/Urls können auch Ist/Soll Werte sein. Das Track and Guide-Pattern eignet sich besonders für Service- Orientierte Architekturen und ist selbst nach SOA Grundsätzen aufgebaut. Stateless und gut skalierbar.

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen ( )Folie 32 Ausblick Workflow Engine Trennung in die tatsächliche Engine und zusätzliche Elemente der Benutzerführung (TO DO Liste) empfang und -senden passt in das Konzept. Verteilbar, da segmentierbar nach Prozess und Benutzer Benutzerführung Abbild des Kernprozesses und Zuordnung der aktuellen Dateien in der Anzeige zu einem Prozessschritt Da die enter/leave Messages auf Hyperlinks abgebildet werden können kann aus einer TODO Liste direkt in die Web Anwendung gesprungen werden (incl. Parameter der URL) Prozessmodellierung als (Ver-)Middelware ?