Diplomarbeit: Untersuchungen zur Erstellung eines Workflowmanagementsystems entsprechend dem Referenzmodell der WfMC

Diplomarbeit:

Untersuchungen zur Erstellung einesWorkflowmanagementsystems entsprechend

dem Referenzmodell der WfMC

2

Gliederung

• Motivation

• Standard der WfMC

• Vorhandenes WfM System

• Einbringung des Standards

• Einbringung einer Datenbank

• Zusammenfassung

3

Motivation

Beispiel einer Workflowdefinition (Prozessdefinition): Warenbestellung

Bestellung ausführen

Bestellung prüfen

Lieferfähigkeitprüfen

Bonität desKunden prüfen

Paket vorbereiten

Warenzusammen-

stellen

Paketbeschriften

Paket versenden

4

Motivation

Rechnergestützte Abarbeitung von Workflows:

Process-Definition-Tool

Engine

11001101

Client-Application Client-Application

Workflowmanagementsystem

5

Motivation

Bedarf an Standards: Szenario 1 - Austausch von Komponenten:


Engine

11001101



10110110

6

Motivation

Bedarf an Standards: Szenario 2 - Interoperabilität:


Engine

11001101


Engine

7

Motivation

Vorteile von Standards:

• Austausch einzelner Komponenten

• Integration spezialisierter Komponenten

• Senkung der Kosten bei Verwendung von WfM Systemen

• Senkung des Risikos beim Erwerb neuer Komponenten

8

Standard der WfMC

Workflow Management Coalition:

• Verbund von 300 Organisationen

• Ziel: Festlegung von Standards für WfM Systeme

• Betrachtung gemeinsamer Charakteristika bestehender WfM Systeme Definition eines Referenzmodells

• Definition einer Begriffsterminologie

9

Standard der WfMC

Referenzmodell:

10

Standard der WfMC: Referenzmodell

Interface 1: Process Definition Tool

• Zum Importieren und Exportieren von Prozessdefinitionen zwischen Engine und Process Definition Tool

• Bisher: meist systeminterne Verwendung eines proprietären Formates

• 1. Entwurf eines Austauschformates für Definitionen mit Hilfe eines Metamodells

• 2. Entwurf einer API zum Austauschen der Definitionen


Engine11001101

11


Interface 2: Client Applications

• Zur Interaktion mit dem Workflowteilnehmer

• Starten, Unterbrechen und Beenden von Aktivitäten

• Worklist-Handler: Filtern von relevanten Aktivitäten für den Workflowteilnehmer

Engine Client-Application

12


Interface 3: Involvierte Anwendungen

• Zum Einbeziehen externer Anwendungen

• Nicht nur Problem im Bereich des WfM

• Verwendung eines Application Agents

• Besser: Einbeziehung workflowbefähigter Anwendungen

Engine Invoked Application

13


Interface 4: Interoperabiliät

• Zur Verwaltung von Workflows durch heterogene Enactment-Services

• Definition vier verschiedener Szenarien mit unterschiedlicher Befähigung zur Interoperabilität

• Benötigt einheitliche Interpretation von Prozessdefinitionen

• Benötigt Funktionen zum Austausch von Kontrollinformationen und prozessrelevanten Daten

Engine Engine

Enactment-Service

14


Interface 5: Administration und Überwachung

• Zur Administration und Überwachung mehrerer Engines

• Verwaltung von Workflowteilnehmern und Rollen

• Verwaltung von Ressourcen

• Verwaltung von Workflows

EngineAdministration- and

Monitoring Tools

15

Vorhandenes WfM System

• Im Rahmen eines Projektes in Java entworfen

• Weiterentwicklung durch eine Diplomarbeit



Architektur:

Java-Anwendung

Java-Anwendung

16

Einbringung des WfMC Standards

1.: Anpassung der Architektur:



Java-Anwendung

Java-Anwendung Java-Anwendung

17

Einbringung des WfMC Standards

Referenzmodell

WAPIWAPI Mapping

zu IDLjFlow

2.: Implementation des Interfaces - Wahl einer konkreten Spezifikation

18

Einbringung des WfMC Standards: jFlow

jFlow

• Antwort auf RfP der OMG zur Spezifikation einer WfM Facility

• Von 19 Firmen konzeptioniert und von 18 weiteren unterstützt

• Basiert auf dem Referenzmodell der WfMC

• Spezifiziert Interfaces 2, 4 und 5 in der IDL

19


jFlow-Modell

20


• Konflikte bei Einbringung von jFlow Adaption von jFlow:

• 2 Regeln:– Funktionsangebot des vorhandenen WfM Systems muss erhalten bleiben– Nicht zu sehr vom jFlow Standard abweichen


Java-Anwendung Java-Anwendung

jFlow

21


1. Konflikt: dynamische Änderungen von Prozessdefinitionen

Prozess

Aktivität Aktivität Aktivität

entfernen hinzufügen

22


2. Konflikt: unterschiedlicher Aufbau von Prozessdefinitionen

Prozess


Prozess

Aktivität Aktivität

jFlow vorhandenes System

Aufgabe

Aufgabe Aufgabe

AufgabeAufgabe

23


2. Konflikt: unterschiedlicher Aufbau von Prozessdefinitionen

Prozess


Lösung:


andere Variante:

Prozess

Prozess Prozess


24


3. Konflikt: unterschiedliche Zustandsdiagramme

open

waiting

enabled

running

closed

done

disabled

vorhandenes Modell:

not_running

jFLow Modell:open

not_started

suspended

running

closed

terminated

completed

aborted

25


3. Konflikt: unterschiedliche Zustandsdiagramme

not_running

open

not_started

suspended

running

closed

terminated

completed

aborted

in_queue

dropped

Lösung:

26


Umsetzung der adaptierten jFlow IDL durch CORBA:

jFlow IDL

Stub Skeleton

Language Mapping

Servants

implCORBA-Client

CORBA-Server

CORBA-Objekte

Instanz

27


Erweiterung der bestehenden Architektur durch CORBA:


CORBA-ClientCORBA-Server

Servants

28


Erweiterung der bestehenden Architektur durch CORBA:

Engine

Client-Application

Java-Anwendung

Java-Anwendung

CORBA-ClientCORBA-Server

Servants

CORBA-Object-Factory

Engine-Bridge

standardisiertes jFlow-Interface

29

Einbringung einer Datenbank

Einbringung einer Datenbank:

Engine

Native XML-Datenbank:

30

Zusammenfassung

Entstandene Architektur:


Engine

11001101

Client-Application

Web-Server

eXist-Datenbank

jFlowEngine

Administration- andMonitoring Tools

jFlow +

?

Invoked Application

?jFlow

31

Zusammenfassung

Bewertung des Standards der WfMC:

• Abstrakte Spezifikation zukunftsfähig

• Konkrete Spezifikationen nicht praktikabel

• Standard erreicht nicht sein Ziel Test der entstandenen Software nicht möglich

• In Zukunft ist ein einsatzfähiger Standard zu erwarten

Documents

Diplomarbeit: Untersuchungen zur Erstellung eines Workflowmanagementsystems entsprechend dem Referenzmodell der WfMC