Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen (15.10.2004)...

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

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 (2.12.2004) 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 http://www.mathertel.de


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


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


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:


„altbekanntes“ immer noch aktuelles Problem auf Applikationsniveau


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


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 ()


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() …

}


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


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


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


Zeit Problem 2

Message orientierte Webservice Verbindungen

unterstützt auch sehr lang laufende Anfragen

Höhere Ausfallsicherheit

keine garantierten Antwortzeiten

nicht einmal http-Timeout


Zeit Problem 3

Benutzerinteraktion

Bestandteil einer Prozessdefinition

Modellierbar

keine garantierte Bearbeitungszeiten(Steuererklärung)


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



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.


Login

Auswahl

Antrag

Prüfung

Abholen

Beispiel: Buchausleihe mit Autorisierung

Ende

Anfrage

manuelle Entscheidung

aktuelleAnfragen

Entscheidung


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

aktuelleAnfragen

Entscheidung

Exception Sub-SystemAnfrage


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


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

Rem

ove

Store

UI Proxy

Ans

wer



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



Time

Gleich mehr…

Queue

Track

Guide

Messages


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


[ 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


Exception

Time / Queue


[ 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


Exception Time / Queue


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


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



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



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.


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


"Ä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.


Ausblick

Workflow Engine

Trennung in die tatsächliche Engine und zusätzliche Elemente der Benutzerführung (TO DO Liste)

Emailempfang 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 ?

Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen (15.10.2004)...

Documents

Transcript of Software Pattern für lang laufende Prozesse in WebService orientierten Applikationen (15.10.2004)...