Spezifikation und Implementierung einer verteilten persistenten Workflow-Engine auf der Basis von CORBA

Inhaltsverzeichnis

1 Einleitung

2 Workflow-Management
2.1 Einführung
2.2 Eigenschaften von Workflows
2.2.1 Atomare Workflows und komplexe Workflows
2.2.2 Agenten- / Rollenkonzept
2.3 Anforderungen an ein Workflow-Management-System
2.3.1 Workflow-Meta-Modell-bezogene Anforderungen
2.3.2 Implementierungsbezogene Anforderungen
2.4 Kommerzielle Workflow-Management-Systeme
2.4.1 FlowMark von IBM
2.4.2 WorkParty von Siemens
2.5 Der erste WASA Prototyp

3 Objektorientierter Entwurf
3.1 Philosophie
3.2 Analyse-Objektmodell
3.3 Design-Objektmodell
3.4 Plattformanforderungen

4 Persistency-Service
4.1 Anforderungen
4.2 Spezifikation nach OMG
4.3 Neue Spezifikation
4.3.1 Database
4.3.2 Transaction
4.3.3 Persistent Object
4.4 Implementierung
4.5 Eine Beispielanwendung
4.5.1 Implementierung der Interface
4.5.2 Implementierung der Factory
4.5.3 Implementierung des Servers
4.6 Modul Utility
4.7 Performanz
4.8 Optimierungsmöglichkeiten
4.8.1 Verminderung des Datenumfanges
4.8.2 Vorcompilierte Datenbankbefehle
4.8.3 Zusammenfassen von Daten
4.8.4 Messungen
4.8.5 Fazit

5 Implementierung des Prototypen
5.1 Realisierung des Workflow-Management-Systems mit OrbixWeb
5.2 Übersicht Klassenhierarchie
5.3 Objektmodell-orthogonale Dienste
5.3.1 Trading-Object-Service
5.3.2 Event-Service
5.4 Systemarchitektur
5.4.1 Logische Systemsicht
5.4.2 Physische Systemsicht
5.5 Basisfunktionalität
5.5.1 Templates
5.5.2 Daten
5.6 Workflow-Engine Kernfunktionalität
5.6.1 Darstellung von Workflows
5.6.2 Atomare Workflows
5.6.3 Komplexe Workflows

6 Beispiel
6.1 Das Workflow-Modell
6.2 Darstellung des Workflow-Modells
6.3 Darstellung einer Workflow-Instanz

7 Schlußbetrachtung
7.1 Erfahrungen
7.2 Ideen
7.3 Fazit

Literaturverzeichnis

A Klassen des Persistency-Service
A.1 Modul CosPersistency
A.1.1 IDL-Spezifikation
A.1.2 Klasse DatabaseImpl
A.1.3 Klasse PersistencyLoader
A.1.4 Klasse PersistentObjectImpl
A.1.5 Klasse RawdataIteratorImpl
A.1.6 Klasse TransactionImpl
A.2 Modul DB_Oracle
A.2.1 IDL-Spezifikation
A.2.2 Klasse Oracle_DatabaseImpl
A.2.3 Klasse Oracle_TransactionImpl
A.2.4 Klasse SQL_Statements
A.2.5 Datenbanktabellen

B Klassen der Workflow-Engine
B.1 Modul WASA
B.1.1 IDL-Spezifikation
B.1.2 Klasse AtomicImpl
B.1.3 Klasse AutomaticImpl
B.1.4 Klasse BinaryDataImpl
B.1.5 Klasse BooleanDataImpl
B.1.6 Klasse ComplexImpl
B.1.7 Klasse ConnectorImpl
B.1.8 Klasse DataObjectImpl
B.1.9 Klasse DecimalDataImpl
B.1.10 Klasse ForAllImpl
B.1.11 Klasse InputParameterImpl
B.1.12 Klasse InstanceOfImpl
B.1.13 Klasse NumberDataImpl
B.1.14 Klasse OutputParameterImpl
B.1.15 Klasse ParameterImpl
B.1.16 Klasse ParameterInstanceReferenceImpl
B.1.17 Klasse ParameterMappingImpl
B.1.18 Klasse StartConditionContextImpl
B.1.19 Klasse StartConditionImpl
B.1.20 Klasse StartConditionParameterReferenceImpl
B.1.21 Klasse StringDataImpl
B.1.22 Klasse TemplateImpl
B.1.23 Klasse WFSubWFRelationshipImpl
B.1.24 Klasse WorkflowImpl
B.1.25 Klasse WorkflowInputParameterReferenceImpl
B.1.26 Klasse WorkflowOutputParameterReferenceImpl
B.2 Modul Utility
B.2.1 IDL-Spezifikation
B.2.2 Klasse Creator
B.2.3 Klasse DynamicArrayImpl
B.2.4 Klasse IDLtoJAVA
B.2.5 Klasse JAVAtoIDL
B.2.6 Klasse State

Abbildungsverzeichnis

2.1 Struktur von Workflow-Modellen (Quelle:[WHKS97])

2.2 Beispiel für einen komplexen Workflow

3.1 Beispiel für einen Workflow

3.2 Objektorientiertes Workflow-Meta-Modells, 1. Ansatz

3.3 Analyse-Objektmodell (Quelle: [WHKS97])

3.4 Ein rekursiver Workflow

3.5 Design-Objektmodell (Quelle: [WHKS97])

3.6 Zustände von Workflows (Quelle: [WHKS97])

4.1 Schematische Darstellung Persistency-Service nach OMG

4.2 Performanz in Abhängigkeit von der Anzahl der Objektattribute

4.3 Performanz in Abhängigkeit von der Größe der Objektattribute

5.1 Wurzelbereich der Klassenhierarchie

5.2 Logische Sicht auf das System

5.3 Darstellung von Daten

5.4 Workflows

5.5 Workflowparameter

5.6 Zustände von Workflow-Instanzen

5.7 Atomare Workflows

5.8 Komplexe Workflows

5.9 Der Kontext von Workflows

5.10 Startbedingungen von Subworkflows

6.1 Modell eines Workflows

6.2 Objekte eines Workflow-Modells

6.3 Objekte einer Workflow-Instanz

1 Einleitung

Seit der Einführung von computergestützter Informationstechnologie in den Büro- und Produktionsalltag in den 70er Jahren ist das Ziel eines durchgehenden, computerge- stützten, unternehmensweiten Ablauf- und Ausführungsmanagements nicht erreicht worden. Wie läßt sich dieses Faktum in Bezug auf ein so schnell expandierendes Fach- gebiet, wie die Informatik / Wirtschaftsinformatik, in dem scheinbar alles auf Grund der rasanten Computerentwicklung (spätestens in ein paar Jahren) möglich ist, in Ein- klang bringen?

Eine Betrachtung der Historie der elektronischen Datenverarbeitung vermag die Situation aufzuhellen: Anfang der 70er Jahre zog die computergestützte Informati- onstechnologie in Form von Datenbanksystemen in den Büroalltag ein. Es wurden zentralisierte Großrechnersysteme verwendet, auf denen einige wenige Applikationen installiert waren, deren Hauptaufgabe das Archivieren und statistische Auswerten von Informationen war. Ein Datenaustausch zu anderen Systemen war kaum erforderlich und auch der Zugang zu den Systemen war einigen Spezialisten vorbehalten.

Den großen Durchbruch erlebte die computergestützte Informationstechnologie in den 80er Jahren, als es möglich geworden war, die Rechner klein genug zu gestalten, so daß sie an einem Büroarbeitsplatz installiert werden konnten. Das Zeitalter der Perso- nalcomputer begann: Textverarbeitung, Tabellenkalkulation und andere Applikationen standen auf einmal vielen Mitarbeitern zur Verfügung. Die Rechnerleistungen stiegen schnell weiter an und auch die Kommunikationstechnologie, in Form von Vernetzung der Systeme, nahm zu. Am Ende dieser Entwicklung stand eine Vielzahl von mächti- gen Applikationen, die jeweils einen Inselbereich der Büroarbeit effizient unterstützen konnten, aber es fehlte ein Gesamtkonzept. Durch die verschiedene Darstellung von Informationen innerhalb der unterschiedlichen Anwendungssysteme war häufig eine manuelle Konvertierung von Daten zwischen verschiedenen Formaten nötig. Damit trat das Phänomen auf, daß sich die Produktivität der Büroarbeit trotz immer besserer technischer Werkzeuge nicht erhöhen ließ, weil an den Schnittstellen der Werkzeuge Arbeitszeit für Konvertierungen verschwendet wurde. Der Ruf nach einer gesamtheit- lichen Lösung wurde laut.

Diese gesamtheitliche Lösung sollten in den 90ern die Workflow-Management- Systeme darstellen. Diese Vermögen an Hand von Modellen den Ablauf der Büroarbeit zu steuern und integerieren die im Unternehmen verwendeten Applikationen zu einem

Gesamtkonzept. Nach anfänglichen Erfolgen stellten sich jedoch auch hier Probleme ein: Die Workflow-Management-Systeme sind zu starr und unflexibel für dynamische Unternehmensbereiche. Die heutigen verfügbaren Workflow-Management-Systeme trennen strikt zwischen einer Buildtime - und einer Runtime -Umgebung [zM96]. In der Buildtime erstellt ein Modellierer ein Modell der logischen Struktur und der infor- mationsbezogenen Zusammenhänge von Applikationen an Hand der Unternehmens- struktur. Dieses Modell wird beim Übergang zur Runtime zumeist compiliert und in ein ausführbares Programm übersetzt, welches die Ablaufsteuerung übernimmt und zu den Applikationen Schnittstellen zur Verfügung stellt.

Für einfach strukturierte und im Zeitablauf statische Aufgaben sind die heuti- gen Workflow-Management-Systeme gut geeignet. Probleme treten insbesondere in hoch dynamischen Bereichen auf, in denen entweder zu Beginn einer Aufgabe noch nicht der vollständige Ablauf bekannt ist oder sich laufend ändert. Auch der Versuch, Workflow-Management-Systeme durch die Einführung von Ausnahmebehandlungen flexibler zu gestalten, half nicht für alle Aufgabenstellungen. Die einzige vielverspre- chende Lösung ist, auf eine strikte Trennung von Runtime und Buildtime zu verzichten und somit dem Anwender zu ermöglichen, auch zur Laufzeit von Workflow-Instanzen Änderungen an diesen vornehmen zu können.

Das Ziel dieser Diplomarbeit ist die Spezifikation und Implementierung eines flexiblen Workflow-Management-Systems, basierend auf dem in [WHKS97] vorge- stellten Objektmodell. Das Workflow-Management-System soll sich durch seine Ver- wendbarkeit auf heterogenen Systemen, Verteilung und Persistenz von Workflow- Modellen und -Instanzen auszeichnen. Zu diesem Zweck wird das System auf der Ba- sis von CORBA in der Programmiersprache Java spezifiziert und implementiert (siehe [WHH 98]). Zur Erhaltung der Persistenz der Datenobjekte wird eine Schnittstelle zu einer Datenbank definiert und für die am Institut vorhandene Oracle -Datenbank programmiert.

Die Kapitel 2 und 3 führen kurz in die Thematik der Workflows und der Workflow- Modellierung ein und stellen verschiedene Ansätze für Workflow-Management-Sys- teme vor. Die Realisierung der Persistenz wird in Kapitel 4 ausführlich behandelt. Die Implementierung des Workflow-Management-Systems wird in Kapitel 5 erläutert und es wird beispielhaft die Darstellung von Workflows in dem System im 6. Kapitel erklärt. Abschließend wird im letzten Kapitel ein Resumee gezogen, das die Erfah- rungen, die bei der Implementierung des Systems gemacht worden sind, umfaßt und einige Ideen für die zukünftige Weiterentwicklung des Systems vorstellt.

2. Workflow-Management

2.1 Einführung

Eine Aktivität ist eine definierte und abgeschlossene Tätigkeit, die unter Umständen von verschiedenen, aber definierten Agenten ausgeführt werden kann. Im Zusammen- hang mit Workflow-Management ist unter einem Agenten eine Person oder ein Soft- waresystem zu verstehen. Eine Menge von Aktivitäten, die in einem logischen Zu- sammenhang zu einander stehen und inhaltlich abgeschlossen sind, wird als Workflow bezeichnet.

Die Aufgabe eines Workflow-Management-Systems ist die Koordinierung von Workflows, die durch ein Workflow-Modell von außen vorgegeben werden. Ein Mo- dell ist als ein immaterielles Abbild eines Realweltausschnittes für die Zwecke eines Subjekts zu verstehen [BS96]. Konkret bedeutet dieses für den Fall eines Workflow- Modells, daß alle Informationen über die logischen Abhängigkeiten, die sich daraus ergebende Aktivitätenreihenfolge, die zur Koordinierung benötigten Informationen und die Organisationstruktur eines Unternehmens im Workflow-Modell enthalten sein müssen.

Workflow-Modelle können durch Sprachen beschrieben werden [JBS97], [WV98]. Im folgenden wird zur Beschreibung von Modellen die in [WHKS97] beschriebe- ne, graphbasierte Workflow-Sprache verwendet, bei der Workflow-Modelle durch ge- schachtelte gerichtete Graphen repräsentiert werden.

2.2 Eigenschaften von Workflows

Damit das Workflow-Management-System seiner koordinierenden Aufgabe gerecht werden kann, muß es einige relevante Laufzeit-Informationen über Workflows haben, an Hand derer Entscheidungen getroffen werden können, die den weiteren Arbeits- ablauf steuern. Daher ist es sinnvoll, daß Workflows neben kontrollrelevaten Struktu- ren (Kontrollkonnektoren), die den logischen Ablauf vorgeben, auch Parameter haben. Über Parameter, können vorangehende Workflows auf einen Workflow Einluß nehmen,

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Struktur von Workflow-Modellen (Quelle:[WHKS97])

indem die Eingabeparameter des einen mit den Ausgabeparmetern des anderen verbun- den werden. Hier stehen zwei Konzepte zur Auswahl: globale Parameter oder Schnitt- stellenparameter. In Workflow-Sprachen, die mit globalen Parametern arbeiten, kann jeder Workflow auf einen Parameter schreibend oder lesend zugreifen [WV98]. Spra- chen dagegen, die Schnittstellenparameter verwenden, definieren für jeden Workflow eine Menge von Eingabe- und Ausgabeparametern, die über Datenfluß-Konnektoren miteinander verbunden werden [WV98]. Eine solche Modellierung wird in dieser Ar- beit verwendet, weil die Datenflüsse in Workflow-Modellen so deutlicher zu erkennen sind und Workflows leichter wiederverwendbar sind, weil es nicht zu Seiteneffekten¹ auf Modellebene kommen kann.

Wie in Abbildung 2.1 (b) sichtbar, hat ein Workflow neben den datenflußrelevanten Parametern auch zwei Kontrollfluß-relevante Parameter. Diese kontrollflußrelevanten Parameter gewinnen im Zusammenhang mit komplexen Workflows (siehe nächster Abschnitt) an Bedeutung. Während Datenfluß-relevante Parameter einen beliebigen Datentypen haben können, sind Kontrollfluß-relevante Parameter immer von einem speziellen Datentyp, der den Wertebereich { true signaled, not signaled, false signa- led } hat. Der erste (linke) Kontrollfluß-relevante Parameter des atomaren Workflows gibt an, ob ein Workflow ausgeführt werden soll. Dieses ist dann der Fall, wenn der Parameter den Wert true signaled hat. Der zweite (rechte) Kontrolfluß-relevante Para- meter hat solange den Wert not signaled, wie der Workflow nicht ausgeführt wurde. Ist der Workflow erfolgreich abgeschlossen worden, dann wird der Wert auf true signaled, ansonsten false signaled gesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Beispiel für einen komplexen Workflow

2.2.1 Atomare Workflows und komplexe Workflows

Es lassen sich zwei Arten von Workflows unterschieden: atomare und komplexe Workflows. Ein atomarer Workflow zeichnet sich dadurch aus, daß er innerhalb des Workflow-Management-Systems keine sichtbare innere Struktur hat, entweder weil er sich auf Grund seiner Natur nicht weiter unterteilen läßt, oder weil eine weitere Unter- teilung für das Workflow-Management-System nicht von Bedeutung ist.

Komplexe Workflows unterscheiden sich von atomaren Workflows nach außen be- trachtet nicht, sie haben jedoch eine im Modell spezifizierte innere Struktur. Ein kom- plexer Workflow besteht aus beliebig vielen Subworkflows, die über Datenkonnektoren und Kontrollkonnektoren miteinander im Kontext des Superworkflows verbunden sind (siehe Abbildung 2.1 (c)). Um in einem Workflow-Modell verschiedene Ausführungs- pfade definieren zu können, erzwingt die hier verwendete Sprache, im Kontext eines Superworkflows, neben der Definition einer Terminationsbedingung, die Definition ei- ner Startbedingung, die, wie in Abbildung 2.1 (a) gezeigt, sowohl die kontrollflußrele- vanten als auch die datenflußrelevanten Eingabeparameter auswerten kann.

Abbildung 2.2 zeigt ein Beispiel für einen komplexen Workflow. Der Workflow stellt die Auftragserfassung einer Unternehmung dar. Zunächst wird ein eingegange- ner Auftrag eingescannt und es wird überprüft, ob der Kunde schon in der Kunden- datenbank existiert. Ist das der Fall, dann gibt der Workflow „Kunden bestimmen“die Kundennummer zurück, ansonsten wird keine Kundennummer zurückgegeben (also null). Ist keine Kundennummer zurückgegeben worden, so startet der Workflow „Kun- den erfassen“und gibt als Ergebnis die Kundennummer des neuen Kunden zurück. Da der Parameter „KNR“des Workflows „Auftrag erfassen“von zwei Datenflußkonnekto- ren referenziert wird, muß dieser Zugriff synchronisiert werden. Dies geschieht über Prioritäten (kleiner Kreis mit Ziffer an den Datenflußkonnektoren). Da die Priorität für den Datenfluß von „Kunden erfassen“höher ist als von „Kunden bestimmen“ist die Kundennummer von „Kunden erfassen“ausschlaggebend, sofern dieser Workflow ge- startet wird. Zu allerletzt werden die Daten mit der gegebenen Kundennummer erfaßt und der komplexe Workflow ist mit der Auftragsnummer als Rückgabewert beendet.

2.2.2 Agenten- / Rollenkonzept

Wird an Hand eins Workflow-Modell ein konkreter Workflow erstellt, spricht man vom Instantiieren eines Workflow-Modells. Ist eine Modell-Instanz erstellt worden, dann kommt irgendwann der Zeitpunkt, an dem atomare Workflows ausgeführt werden sol- len. Da ein Workflow zu seiner Ausführung einen Agenten braucht, muß ein geeigneter zunächst gefunden werden. Diesen Vorgang nennt man Rollenauflösung.

Wie schon zu Beginn dieses Kapitels erwähnt, muß in einem Workflow-Modell auch die Organisationsstruktur eines Unternehmens abgebildet werden, um geeignete Agenten zur Ausführung von atomaren Workflows zu finden, die sowohl die Kompe- tenz, als auch die Fähigkeit haben, ein bestimmte Aktivität auszuführen. Zur Darstel- lung der Fähigkeiten und Kompetenzen von Agenten verwendet man das Konzept der Rollen. Ein Agent hat verschiedene Rollen, die er einnehmen kann und ein Workflow steht zu Rollen in Beziehung, die ein Agent haben muß, um ihn ausführen zu können.

Üblicherweise geht die Rollenauflösung so vor sich, daß Agenten, sofern diese human sind, über Workflows, die von ihnen ausgeführt werden dürfen, in Form einer Worklist informiert werden. In diesem Zusammenhang ist es sinnvoll, noch weitere Ei- genschaften für Workflows zu modellieren, um zum Beispiel zu verhindern, daß Work- flows, aus welchen Gründen auch immer, überhaupt nicht, oder zu spät ausgeführt werden. Hierzu gibt es insbesondere die Konzepte der Priorisierung und der Deadli- ne. Bei der Priorisierung bekommt jeder Workflow eine eigene statische Priorität, die seine Wichtigkeit ausdrückt. Dieses Konzept kann flexibilisiert werden, indem sich die effektive Priorität eines atomaren Workflows von seiner eigenen und der seines Sub- workflows berechnet; sehr sinnvoll im Zusammenhang mit Aufgaben, in denen sowohl unwichtige als auch sehr hochpriorisierten Tätigkeiten anfallen. Das zweite Konzept der Deadline sieht einen spätesten Zeitpunkt vor, an dem ein Workflow bearbeitet oder beendet sein muß. Dieses Konzept ist dynamisch, weil sich die Workflow-Wichtigkeit im Verlaufe der Zeit ändern kann. Besser geeignet als die Priorisierung ist dieses Kon- zept insbesondere bei Terminsachen.

2.3 Anforderungen an ein Workflow-Management-System

Bei Workflow-Management-Systemen handelt es sich um sehr komplexe Software- produkte, die nicht ad hoc implementiert und nachträglich ohne weiteres in ihrer Funktionalität erweitert werden können. Vor der Implementierung eines Workflow- Management-Systems sind vielmehr zunächst Überlegungen theoretischer Art not- wendig um ein in der Praxis anwendbares System zu erstellen. Dies ist darin begrün- det, daß ein Workflow-Management-System nicht eine vollständige Applikation im herkömmlichen Sinne ist, sondern vielmehr eine Plattform darstellt, in die bestehende und zukünftige Systeme eingebunden werden sollen. Das heißt, daß das Workflow- Management-System als Mittler zwischen Applikationen verstanden werden kann, der aus einer Menge von Einzelapplikationen eine zusammenhängende, unternehmens- weite Anwendung zur Unterstützung der Unternehmensziele schafft. Da sich die Ziele einer Unternehmung kurzfristig und langfristig ändern oder an die Zeit anpassen müs- sen, ist nicht nur das Workflow-Management-System, sondern auch die verwendeten

Applikationen Änderungen unterworfen. Daher müssen von vorneherein Überlegun- gen angestellt werden, das System „zukunftskompatibel“zu gestalten.

2.3.1 Workflow-Meta-Modell-bezogene Anforderungen

Die theoretischen Überlegungen zu einem Workflow-Management-System umfassen insbesondere das Workflow-Meta-Modell. Die Definition des Workflow-Meta-Modells legt fest welche Workflow-Modelle das System erlaubt und verarbeiten kann, somit ist ein konkretes Workflow-Modell einer Unternehmung eine Instanz des Workflow- Meta-Modells [JBS97].

Aus diesem Grunde ist eine wohlüberlegte Modellierung des Workflow-Meta- Modells von entscheidender Bedeutung für das Workflow-Management-System. Ein Workflow-Meta-Modell sollte die folgenden Anforderungen erfüllen, um „Zukunfts- kompatibilität“zu gewährleisten [Jab96]:

Erweiterbarkeit: Workflow-Management-Systeme werden in Unternehmen einge- führt, um verschiedene Anwendungsbereiche zu integrieren, die durch un- terschiedlichste Workflows charakterisiert sind. Daher es ist unmöglich von Anfang an bei der Systemspezifikation alle benötigten Eigenschaften und Modellelemente von Workflows vorherzusehen, so daß das Workflow-Meta- Modell in der Art flexibel gestaltet sein muß, daß auch neue Workflow- Typen oder Kontrollkonstrukte nachträglich in das Modell eingefügt werden können.

dynamische Anpassungsfähigkeit: Das Workflow-Meta-Modell sollte die Mög- lichkeit vorsehen, bereits gestartete Workflows nachträglich zu ändern. Das heißt, es muß für einen gestarteten komplexen Workflow zum Beispiel mög- lich sein, Subworkflows, die noch nicht ausgeführt worden sind, zu über- springen oder neue Subworkflows einzufügen etc.

Gründe, die eine solche Flexibilität erzwingen, sind zum einen die Pro- blematik von Fehlern bei der Ausführung von Workflows. Selbst ein Workflow-Meta-Modell, welches eine sehr ausführliche Fehlerbehandlung für Workflow-Modelle zur Verfügung stellt, wird niemals alle möglichen Fehlerquellen abfangen können, allein auf Grund der Tatsache, daß die Fehlerursache sich außerhalb des Workflow-Management-Systems befin- den kann. Des weiteren können Änderungen an der Umgebung von Unter- nehmen kurzfristiger oder langfristiger Art auch Änderungen an Workflow- Modellen erzwingen.

Wiederverwendbarkeit: Auf Grund der Tatsache, daß der Aufwand für die Erstel- lung eines Workflows ein nicht zu unterschätzender Kostenfaktor ist, soll- te das Workflow-Meta-Modell eine Wiederverwendung von Workflows und anderen Modell-Elementen gestatten. Das bedeutet zum Beispiel für einen Subworkflow, daß er keine Annahmen über irgendwelche Eigenschaften sei- nes Superworkflows treffen sollte, um problemlos in den Kontext eines an- deren Superworkflows eingebunden werden zu können.

Offenheit: Workflows können die verschiedensten Bereiche einer Unternehmung um- spannen, in denen die unterschiedlichsten Hard- und Softwareplattformen ihre Verwendung finden. Daher sollte ein Workflow-Modell keine Annah- men über die Beschaffenheit von Applikationen treffen, um keine Restrik- tionen in den Anbindungsmöglichkeiten von Anwendungen zu haben. Das bedeutet, daß ein Workflow-Modell eine geeignete Schnittstelle zwischen der Workflow-Repräsentation einer Applikation und der Applikation selbst zur Verfügung stellen muß.

2.3.2 Implementierungsbezogene Anforderungen

Neben den theoretischen dürfen die praktischen Überlegungen zur Implementierung des Workflow-Management-Systems nicht vernachlässigt werden, damit das System auch ergonomische Aspekte erfüllt. Leider sind die implementierungsbezogenen An- forderungen und die Workflow-Meta-Modell-bezogenen Anforderungen nicht voll- ständig orthogonal zueinander, so daß bei der Entwicklung des Systems eine enge Kooperation zwischen Meta-Modell-Designer und den Programmierern notwendig ist. Folgende Anforderungen gilt es zu berücksichtigen [JBS97]:

Offenheit: Wie bei den Workflow-Meta-Modell-bezogenen ist die Offenheit des Sy- stems bei den implementierungsbezognenen Aspekten von entscheidender Bedeutung. Unter Offenheit im Kontext der Systemimplementierung ist jetzt allerdings nicht nur die Fähigkeit des Systems zur Einbindung von verschie- denen Anwendungen gemeint, sondern auch die Möglichkeit das gesam- te System (mit Anpassungen) auf eine Vielzahl von Plattformen zu por- tieren. Insbesondere im Zusammenhang mit der Offenheit von Workflow- Management-Systemen ist die Verwendung von Middleware-Produkten, wie zum Beispiel CORBA, sinnvoll.

Skalierbarkeit: Da ein Workflow-Management-System im Verlauf seines Einsatzes in der Unternehmung bei erfolgreicher Anwendung immer mehr Bereiche umfassen wird, muß von vorneherein mit einer steigenden Anzahl von An- fragen an das System gerechnet werden. Daher ist es enorm wichtig, das Sy- stem skalierbar, das heißt an die Zahl der Anfragen anpassbar, zu gestalten. In diesem Zusammenhang ist es sinnvoll, über die Verteilung des Systems zu reden (siehe übernächster Punkt).

Zuverlässigkeit: Auf Grund der zentralen Bedeutung des Workflow-Management- Systems für eine Unternehmug ist ein zuverlässiger und sicherer Betrieb unerläßlich. Das System muß nicht nur Persistenz und Fehlertoleranz auf- weisen, sondern muß auch eine geringe Ausfallzeit haben. Das bedeutet, die Workflow-Engine muß entweder auf mehreren Rechnern repliziert oder verteilt sein.

Verteilbarkeit: Auch wenn die Verteilung eines Systems nicht gerade zu den einfach- sten Disziplinen der Informatik gehört, bietet sie sich im Zusammenhang mit Workflows auf Grund ihrer Struktur an. Atomare Workflows werden

weitestgehend autonom ausgeführt und könnten somit als eigener Knoten des verteilten Systems gesehen werden. Auf diese Weise ist, eine genügen- de Anzahl von Rechner vorausgesetzt, eine Skalierbarkeit des Systems ge- geben, wenn die Workflows möglichst an dem Ort ausgeführt werden, an dem sich auch der Agent befindet.

Ein Nachteil der Verteilung im Zusammenhang mit Workflow-Management- Systemen ist das Monitoring. Da beim Monitoring von Workflows im allge- meinen sehr viele Daten über Subworkflows etc. benötigt werden, hat bei dieser Problematik der zentralisierte Ansatz naturgemäß Vorteile.

2.4 Kommerzielle Workflow-Management-Systeme

Es gibt eine Vielzahl kommerzieller Workflow-Management-Systeme auf dem Markt, von denen hier zwei kurz vorgestellt werden sollen:

2.4.1 FlowMark von IBM

FlowMark ist ein seit 1994 von der Firma IBM distributiertes, zentrales Workflow- Management-System. Das System ist auf Grund seiner Client-Server Architektur zen- tral, weil es aus logischer Sicht gesehen, genau einen Server gibt (der physisch ge- spiegelt sein kann). Das heißt, daß alle Workflow-Daten auf einem Knoten vereinigt sind. FlowMark kann auf heterogenen Plattformen, auf Grund der breiten Basis an unterstüzten Systemen (OS/2, AIX, Windows, HP-UX), verwendet werden.

In FlowMark werden Prozesse (komplexe Workflows) in Form von gerichteten Graphen modelliert, die aus Aktivitäten (atomaren Workflows) bestehen, die über Kon- troll fl ußkonnektoren miteinander logisch verknüpft werden. Aktivitäten haben jeweils genau einen Input- und einen Output-Container, die über Datenflußkonnektoren mit Containern anderer Aktivitäten im Prozeß verknüpft sein können [zM96].

FlowMark implementiert strikt das Runtime-Buildtime Konzept [RzM96]. Das heißt Workflow-Modelle werden zur Buildtime in einem anderen Datenformat gehal- ten als zur Runtime. Zur Konvertierung eines Buldtime-Modells wird ein Compiler verwendet, der das Modell in ein fertiges Programm übersetzt. Dieses wirkt sich sehr restriktiv auf die dynamische Veränderbarkeit von Workflows aus. Bei FlowMark ist es nicht möglich in den Ablauf von Workflow-Instanzen nach ihrem Start einzugreifen oder ihr Modell zu ändern. Die Veränderungen an einem Workflow-Modell werden erst dann wirksam, wenn sich der Agent, der einen neuen Workflow startet, in das Sy- stem erneut einloggt. Dafür bietet FlowMark die Möglichkeit Prozeßadministratoren zu bestimmen, die im Falle eines Scheiterns von Workflow-Instanzen über die Situa- tion informiert werden. Daneben ist ein statisches Exceptionhandling für Aktivitäten möglich.

Die Wiederverwendung von Workflows ist in FlowMark auf Grund der direkten Zuordnung von Containern zu Workflows gut gestaltet. Einzig die Tatsache, daß ein Workflow genau zwei Container hat (einen Input- und einen Outputcontainer) wirkt

etwas befremdlich. Ein Container enthält mehrere Datenfelder, die bei einem Daten- fluß von einem Input- zu einem Outputcontainer über eine Mapping -Operation einan- der zugeordnet werden (siehe Meta-Modell FlowMark in [zM96]). Somit kann einem Workflow-Modell nicht auf einen Blick angesehen werden, welche Datenfelder eines Outputcontainers in welche Datenfelder eines Inputconatiners übertragen werden.

2.4.2 WorkParty von Siemens

WorkParty ist, wie FlowMark, ein zentrales Workflow-Management-System, daß 1992 von der Siemens Nixdorf AG für die Windows-Plattform entwickelt wurde. Ein Prozeß (komplexer Workflow) in WorkParty ist ein gerichteter Graph, dessen Knoten aus Ak- tivitäten bestehen, die durch Konnektoren miteinander verbunden sind. Die Konnek- toren können nicht frei platziert werden, sondern es werden dem Modellierer vordefi- nierte Ablaufkonstrukte zur Verfügung gestellt, die die Modellierung eines syntaktisch korrekten Workflowmodells sicherstellen [zM96].

Auch in WorkParty wird zwischen einer Runtime und einer Buldtime unterschie- den, dennoch ist das verwendete Konzept flexibler als bei FlowMark. Wie bei Flow- Mark können auch bei WorkParty schon gestartete Workflow-Instanzen nicht mehr beeinflußt werden, aber es ist bei WorkParty möglich, in Workflow-Modellen Aktivi- täten leer zu lassen. Wird eine leere Aktivität ausgeführt, dann hat der Benutzer zur Laufzeit die Möglichkeit, entweder ein schon fertig modelliertes Workflow-Template an dieser Stelle ausführen zu lassen, oder ad hoc einen eigenen Workflow zu model- lieren (der natürlich auch keine Aktivitäten enthalten darf, was dem Überspringen der Leer-Aktivität entspricht).

Die Wiederverwendung von Workflow-Modellen ist mit WorkParty möglich, aber auf Grund der Art der Parameterdarstellung im Workflow-Meta-Modell nicht gut ge- löst. In WorkParty werden Daten in Akten gespeichert, die für jede Workflow-Instanz neu erzeugt werden, aber die für alle Aktivitäten der Workflow-Instanz global sind. Das heißt, jede Aktivität ist in der Lage diese Akten zu beschreiben oder zu lesen, ohne daß dieses explizit über Datenflußkonnektoren ausgedrückt wird. Somit ist der Modellierer bei der Wiederverwendung gezwungen, darauf zu achten, daß das wieder- verwendete Workflow-Modell mit seinen verwendeten Akten nicht in ungewünschte Konflikte mit den Akten der anderen schon vorhandenen Workflows gerät. Insbeson- dere bei nachträglichen Änderungen an Modellen, die von anderen Benutzern erstellt worden sind, ist mit gefährlichen Seiteneffekten auf Grund von zufälligen, nicht se- mantisch begründeten, gleichen Aktenbenennungen möglich (siehe Workflow-Meta- Modell zu WorkParty in [zM96]).

2.5 Der erste WASA Prototyp

Im Jahre 1997 ist am Lehrstuhl für Informatik des Institutes für Wirtschaftsinforma- tik der Westfälischen Wilhelms-Universität Münster im Rahmen einer Diplomarbeit [Wit97] der erste WASA Prototyp entstanden. Dieser Prototyp zeichnet sich dadurch aus, daß er sowohl dynamische Änderungen an Workflows erlaubt, als auch für hete- rogene Rechnerumgebungen geeignet ist.

Er weist eine, für die meisten Workflow-Management-Systeme übliche, zentrale Client-Server Architektur auf. Im Unterschied zu anderen Systemen, sind aber so- wohl der Client als auch der Server in Java programmiert. Durch die fundamentale Eigenschaft vom Java-Programmcode in einer virtuellen Maschine ausgeführt zu wer- den [WHH 98], kann das System auf allen Plattformen, für die es eine Java-Virtual- Machine gibt, installiert und ausgeführt werden. Die Workflow-Modell-Daten des er- sten Prototypen sind auf einer relationalen Datenbank ausgelagert, weil dieser Daten- banktyp vielfach verbreitet ist und Java eine gute Anbindung zu diesem über JDBC ([WHH 98]) zur Verfügung stellt.

Wie die anderen Systeme auch, unterscheidet der erste WASA Prototyp zwischen einer Runtime- und einer Buildtime-Umgebung. Die Trennung der beiden ist aller- dings weit weniger starr als bei anderen kommerziellen Systemen. Das Buildtime- Workflow-Modell wird in der Datenbank in Form von Relationen gespeichert und wird beim Instantiieren eines Workflow-Modells in ein objektorientiertes Runtime-Modell umgewandelt, welches beim Abarbeiten des Workflows interpretiert wird. Somit ist es zur Laufzeit einer komplexen Workflow-Instanz möglich alle nicht ausgeführten Subworkflows und ihre Beziehungen zueinander, zu ändern. Das heißt eine „Ad hoc“- Modellierung ist mit diesem System gegeben. Eine große Schwäche des Konzeptes kann an dieser Stelle jedoch nicht verschwiegen werden. Dadurch, daß die Workflow- Instanzen zur Ausführung aus dem Workflow-Modell in den flüchtigen Speicher ge- laden werden und nicht in einer Datenbank gesichert werden, ist die Persistenz von Workflow-Instanzen und deren Daten nicht gewährleistet. Auch ein nachträgliches Auditing kann nur über die Protokolldateien des Workflow-Servers geschehen. Somit können schon abgearbeitete Workflow-Instanzen nicht mehr vollständig nachvollzo- gen werden.

Komplexe Workflows werden bei dem ersten WASA Prototypen als gerichtete Graphen dargestellt, deren Kanten über Kontroll- und Datenflüsse miteinander ver- knüpft werden können. Es ist sowohl horizontaler als auch vertikaler Datenfluß mög- lich. Workflows können in dem System beliebig viele Ein- und Ausgabeparameter haben. Sowohl Kontrollkonnektoren als auch Datenkonnektoren zwischen Workflows sind nur im Kontext eines komplexen Workflows gültig, so daß eine Wiederverwen- dung von Workflows ohne Einschränkungen möglich ist.

3. Objektorientierter Entwurf

Während die klassischen Workflow-Management-Systeme von einer strikten Tren- nung von Client und Server, Runtime und Buildtime sowie Workflow-Modell-Daten und Workflow-Instanz-Daten ausgehen, weist der objektorientierte Entwurf in ei- ne andere Richtung. Er verbindet die verschiedenen Sichtweisen auf das Workflow- Management-System zum einem vollständigen Modell.

3.1 Philosophie

Der Grundgedanke des objektorientierten Ansatzes ist der, daß ein Workflow-Modell und seine Workflow-Instanzen strukturell identisch sind. Die Idee muß zunächst ein- mal erklärt werden: Nehmen wir als Beispiel ein komplexes Workflow-Modell, wel- ches lediglich eine Tiefe von eins hat, und somit nur aus atomaren Workflows be- steht, wie in Abbildung 3.1. Bei der Instanziierung und Abarbeitung des komplexen Workflow-Modells werden die einzelnen Subworkflows ebenfalls instantiiert und ab- gearbeitet, sowie die Parameter und somit die Datenflüsse auch mit Werten belegt. Die Struktur des Workflows ist sowohl bei dem Modell, als auch bei den Instanzen gleich. Modell und Instanz unterscheiden sich lediglich in der Tatsache, daß für die im Mo- dell definierten Platzhalter (Parameter, Datenflüsse, etc.) auf Instanzebene konkrete Datenwerte stehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Beispiel für einen Workflow 17

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Objektorientiertes Workflow-Meta-Modells, 1. Ansatz

Der erste und naheliegendste Ansatz um ein Workflow-Management-System als objektorientiertes System dazustellen, ist der, den oben genannten Sachverhalt in die

„objektorientierte Welt“zu übertragen. Das heißt, ein Workflow-Modell wird durch eine Klassendefinition repräsentiert und eine Workflow-Instanz als Objekt der entspre- chenden Klasse gesehen. Eine solche Übertragung ist sinnvoll, weil ein Workflow ei- ne für sich abgeschlossene Einheit darstellt, die interne Zustände hat (objektorientiert: Attribute) und über definierte Datenflußkonnektoren und Kontrollflußkonnektoren (ob- jektorientiert: Methoden) mit der Außenwelt in Kontakt tritt (siehe Abbildung 3.2).

Ein so vollständig spezifiziertes und implementiertes Workflow-Management- System hätte positive Eigenschaft in Bezug auf die Verteilung des Systems. Es wäre möglich jede Workflow-Instanz / jedes Objekt als eigenständigen Prozeß auf einem Rechner auszuführen, ohne daß dieses Objekt während seiner internen Abarbeitung in Kontakt mit dem restlichen System stehen muß. Zur Datenannahme und Datenweiter- gabe würde dieses Objekt über Methodenaufrufe die Daten von seinen Vorgänger- beziehungsweise Nachfolgerobjekten erhalten können. Somit ist das strikte Client-

/ Server-Prinzip gebrochen, weil jedes Objekt sowohl als Client als auch als Server fungieren kann. Ein solches Workflow-Management-System könnte auf Grund seiner objektorientierten Struktur auf CORBA aufbauen, um schnell zu einer plattformunab- hängigen Verteilung zu gelangen.

Bei genauerer Betrachtung zeigt sich eine evidente Schwäche des genannten An-

satzes: Die Workflow-Modell-Daten und die Workflow-Instanz-Daten sind strikt von- einander getrennt, das heißt, es muß zwischen den beiden Zuständen Runtime und Buildtime für ein Workflow-Modell unterschieden werden. Während der Modellie- rungsphase werden die Workflow-Modell-Daten in irgendeiner Datenbank gespeichert und müssen anschließend beim Übergang zur Ausführungsphase in ausführbaren Pro- grammcode compiliert werden. Dies ist höchst unbefriedigend, weil dadurch die Fle- xibilität von Workflows, das heißt insbesondere die dynamische Veränderbarkeit von Modellen und von laufenden Instanzen nicht gegeben ist (siehe Abschnitt 2.4).

Ausgehend von der genannten Problematik sind wir zu dem Ergebnis gekom- men, daß das Modell eines objektorientierten Workflow-Management-Systems eine Abstraktionsebene höher angesiedelt werden muß. Das heißt konkret: Es gibt die Klasse Workflow, von der sowohl Workflow-Modelle als auch Workflow-Instanzen als Objekte instantiiert werden. Eine solche Konstruktion ist deshalb möglich, weil Workflow-Instanzen und Workflow-Modelle sich strukturell nicht unterscheiden (wie zu Eingang dieses Abschnittes erklärt). Die Unterscheidung zwischen Modell und In- stanz kann ausschließlich über einen Zustand des betreffenden Objektes geschehen.

Eine solche Konstruktion weist die gewünschte Eigenschaft einer dynamischen Veränderbarkeit von Workflow-Modellen und -Instanzen auf, weil die Ausführung ei- ner Instanz nicht mehr der Ausführung eines vorcompilierten Programmcodes, son- dern der Interpretation eines Modell-Schemas entspricht. Das heißt, alle Subworkflows eines komplexen Workflows, die während des Ausführens einer Workflow-Instanz noch nicht durchlaufen worden sind, können unabhängig vom Modell geändert wer- den. Wie das Meta-Modell einer objektorientierten Workflow-Engine genau aussieht, zeigt der nächste Abschnitt.

3.2 Analyse-Objektmodell

In einem Objektmodell wird die statische Struktur von Objekten in einem System und ihre Beziehungen zueinander beschrieben. Die Systementwicklung geschieht in meh- reren Schritten. Das Analyse-Objektmodell ist ein Schritt, in dem zunächst versucht wird, die Struktur des Systems formal zu beschreiben. Dieses wird dann im Design- Objektmodell um technische Details verfeinert und optimiert, bevor es in Form eines Implementierungs-Objektmodells implementiert wird.

Die im Zuge dieser Diplomarbeit implementierte Workflow-Engine basiert auf dem Analyse-Objektmodell aus [WHKS97], welches in der Abbildung 3.3 spezifi- ziert wird. Zur Darstellung von Objektmodellen wird im folgenden die Unified Mo- deling Language (UML) [RSC97] verwendet. Nun wird auf einige für diese Arbeit relevaten Aspekte dieses Modells eingegangen: Aus den im vorherigen Abschnitt ge- nannten Gründen werden Workflow-Modelle und -Instanzen durch Objekte der Klasse Workflow repräsentiert. Auf Grund der Tatsache, daß komplexe Workflows Bezie- hungen zu Subworkflows eingehen, leiten sich von der Klasse Workflow die bei- den Klassen Complex, für komplexe Workflows, und Atomic, für atomare Work- flows, ab. Die Klasse Complex hat eine Beziehung zu Workflow über die eine Superworkflow-Subworkflow-Zuordnung dargestellt wird. Diese Modellierung erlaubt

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Analyse-Objektmodell (Quelle: [WHKS97])

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4: Ein rekursiver Workflow

eine beliebige Verfeinerungstiefe von komplexen Workflows, wodurch die Wiederver- wendung schon vorhandener Workflows erleichtert wird [JBS97].

Schleifen innerhalb von komplexen Workflows werden in dem vorgestellten Ob- jektmodell durch Rekursionen hinreichend dargestellt, weil diese mächtiger sind als Schleifen. Das Modell ist aber derart flexibel, daß sich Schleifenkonstrukte bei Bedarf als eine spezielle von Complex abgeleitete Klasse implementieren lassen, die dann ihre Subworkflows mehrmals hintereinander bis zur Erfüllung einer Abbruchbedin- gung instantiieren würden. Abbildung 3.4 zeigt auf der linken Seite das Modell und auf der rechten Seite die Ausführung eines rekursiven Workflows. Das rechte Bild stellt eine Workflow-Instanz vereinfacht als Kreis dar und verzichtet auf Datenkonnektoren und Parameter. Die als true signaled gefeuerten Kontrollkonnektoren sind als durch- gezogene Linien mit Pfeilspitzen dargestellt, die gestrichelte Linie ist der Workflow- Kontext und die nicht ausgeführten Workflow-Instanzen werden durch einen gestri- chelten Kreis angedeutet.

Workflows haben in dem Meta-Modell keine eigenen Startbedingungen. Diese sind nur im Kontext eines Superworkflows definiert als Klasse StartCondition. Die Konstruktion ist im Zusammenhang mit der Wiederverwendung von Workflows sinn- voll, weil ein Workflow, der Subworkflow zweier unterschiedlicher Superworkflows ist, auch unterschiedliche Startbedingungen haben kann. Innerhalb eines komplexen Workflows können zwei Arten von Datenflüssen definiert werden: horizontaler und vertikaler Datenfluß. Der horizontale Datenfluß entspricht dem Datenfluß zwischen zwei Subworkflows. Der vertikale ist ein Datenfluß zwischen dem Super- und einem Subworkflow. Damit ist es möglich Eingabe- beziehungsweise Ausgabeparameter ei- nes Superworkflows an seine Subworkflows „durchzuschleifen“.

Die Datenhaltung wird von Objekten der Klasse DataObject übernommen, die eine lineare Versionierung implementieren. Damit soll es leichter möglich sein, schon ausgeführte Workflows nachzuvollziehen, indem man in der Lage ist, sich die Ver- änderungen auf einem Datenobjekt im Zuge des Workflow-Durchlaufes nachträglich anzusehen. Zu diesem Zweck ist die Relation ParameterMapping eingeführt wor- den, die für einen Workflow festlegt, welche Parameter semantisch durchlaufende Da- ten enthalten (also gleiches Datenobjekt mit unterschiedlicher Versionsnummer) und für welche Parameter ein neues Datenobjekt erzeugt werden soll.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Design-Objektmodell (Quelle: [WHKS97])

3.3 Design-Objektmodell

Beim Übergang vom Analyse- zum Design-Objektmodell (Abbildung 3.5) sind zwei entscheidente Vereinfachungen getätigt worden, die die Ausdrucksfähigkeit des Mo- dells nicht negativ beeinflußt haben [WHKS97]:

Zunächst wurde auf eine explizite Darstellung der Kontrollkonnektoren verzichtet, weil sich diese genau so einfach und effizient als spezielle Workflow-Parameter dar- stellen lassen mit dem Wertebereich: true signaled, not signaled, false signaled. Der Vorteil dieses Verzichtes liegt nicht nur in einem schlankeren Modell, sondern auch in der Vereinfachung der Startbeziehungen. Diese brauchen jetzt die Kontrollkonnekto- ren und die Eingabeparameter nicht mehr zu unterscheiden und können somit einfacher implementiert werden.

Die zweite Änderung ist der Verzicht auf die explizite Unterscheidung der horizon- talen von den vertikalen Datenkonnektoren. Die beiden für diesen Zweck ursprünglich verwendeten trinären Beziehungen sind durch eine einzige vierfach-Beziehung ersetzt worden, die über eine spezielle Bedingung (Constraint c1) dieselbe Semantik erhält, wie die beiden Ursprünglichen Beziehungen. Durch diese Vereinfachung ist ein Tra- versieren von Datenflüssen zwischen den Workflows aus technischer Sicht vereinfacht worden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.6: Zustände von Workflows (Quelle: [WHKS97])

In Workflow und seinen Subklassen soll die Kernfunktionalität der Workflow- Engine implementiert werden, die von der Rollenauflösung in Role unterstützt wird. Aus diesem Grunde haben Workflows die in Abbildung 3.6 spezifizierten Zustände und Zustandsübergänge. Objekte der Klasse Workflow befinden sich direkt nach ihrer Erzeugung im Zustand init. Zum Starten werden sie über getReady in den Zustand ready gesetzt. In diesem Augenblick erscheinen manuelle Workflows auf der Work- list der zuständigen Agenten. Automatische und komplexe Workflows werden einem Rechner zugeordnet, der sie ausführen soll, und sogleich aktiviert. Workflows, die sich im Zustand running befinden, sind in Ausführung. Für komplexe Workflows bedeutet dieses, daß zunächst die eigenen Subworkflows instantiiert werden und anschließend die logisch ersten Workflows über getReady startklar gemacht werden. Ausführlich wird die Implementierung des Design-Objektmodells in Kapitel 5 behandelt.

3.4 Plattformanforderungen

Wenn das im Design-Objektmodell spezifizierte Workflow-Management-System mit allen Vorzügen implementiert werden soll, dann ergeben sich für die Implementie- rungsplattform eine Reihe von Anforderungen:

Systemunabhängigkeit: Da größerer Organisationen häufig heterogene Rechnersy- steme haben, ist es sinnvoll, wenn die verwendete Plattform nicht nur in der Lage ist, mit den unterschiedlichsten Systemen zusammenzuarbeiten, sondern auch eine Migration des Workflow-Management-Systems auf ver- schiedene Systeme möglich ist.

Objektorientierung: Die Plattform muß den Ansatz der Objektorientierung adequat unterstützen, damit der Programmierer nicht unnötig Zeit mit der „Simula- tion“von Objektorientierung vergeudet.

Verteilung: Das hier vorgestellt Workflow-Meta-Modell eignet sich auf Grund sei- ner objektorientierten Struktur hervorragend für die Verteilung. Daher ist es wünschenswert, wenn die Plattform, auf der die Workflow-Engine imple- mentiert werden soll, eine Verteilung von Objekten auf breiter Basis unter- stützt.

Kommunikation: Werden die Objekte auf verschiedenen Rechner verteilt, so müssen diese miteinander kommunizieren können. Hier sind zwei Arten von Kom- munikation sinnvoll. Es sollte eine Punkt-zu-Punkt Kommunikation mög- lich sein (in objektorientierten Systemen werden dieses Methodenaufrufe sein), sowie eine eingeschränkte Broadcast-Kommunikation, um das Moni- toring von Workflows zu erleichtern.

Objektlebenszyklus: Da Workflow-Modelle und -Instanzen dynamisch erzeugt wer- den müssen, muß die Plattform das dynamische Erzeugen und Löschen von Objekten gestatten.

Objektpersistenz: Workflows müssen auf Grund ihrer zentralen Bedeutung für eine Organisation sicher sein, das heißt sie müssen auch nach Systemausfällen in einem sichern Zustand wiederhergestellt werden können. Die Plattform sollte daher eine Form von Persistenz auf Objekten unterstützen.

Relationenunterstützung: Die hohe Anzahl von Beziehungen in dem Objektmodell läßt ein Konzept für die Verwaltung derselben sinnvoll erscheinen.

4 Persistency-Service

Wie in [WHH 98] ausführlich dargelegt, haben wir uns für eine Implementierung des Workflow-Management-Systems in CORBA, mit dem Broker OrbixWeb (Iona Tech- nologies) entschieden, obwohl es unter OrbixWeb keinen implementierten Persistency- Service gibt. Dieser Service hat die Aufgabe, für die Persistenz von Objekten zu sor- gen. Das heißt er stellt Mechanismen zur Verfügung, mit denen der Zustand eines Ob- jektes (also die Attribute) in einer Datenbank gespeichert werden können und sorgt bei Bedarf automatisch dafür, daß diese im Falle eines Systemausfalls hochgeladen wer- den. Das folgende Kapitel beschäftigt sich mit dem Design und der Implementierung des Persistency-Service für OrbixWeb.

4.1 Anforderungen

Für einen Dienst ist es relevant, daß er für den Anwendungsprogrammierer einfach zu handhaben ist und bei einer maximalen Funktionalität eine minimale Komplexität aufweist, um die Produktivität des Anwendungsprogrammierers zu unterstützen und sie nicht durch unnötige Belastungen zu verringern. Dabei sind die folgenden Kriterien für einen Persistency-Service zu erfüllen:

Der Persistency-Service hat in erster Linie die Aufgabe, die Persistenz von Ob- jekten zu gewährleisten. Das heißt, es muß eine Möglichkeit geschaffen werden, die Attribute eine Objektes auszulesen und zu bestimmten Zeitpunkten auf die Festplatte eines Rechners entweder direkt als File oder in einer Datenbank zu speichern. Wün- schenswert ist die Fähigkeit des Dienstes ohne großen Aufwand diese Daten transpa- rent auf verschiedenen Datenbanken/Filesystemen zu verteilen, um nicht einen Engpaß im System durch Zentralität des Persistenz-Dienstes zu schaffen. Ebenso erscheint es sinnvoll, den Ort des persistenten Speichers nach außen hin unsichtbar verschieben zu können, um Objekte, die zu weit entfernten Orten verschoben wurden, nicht aus entfernt liegenden Datenbanken hochladen zu müssen.

An dieser Stelle kommen wir zum Punkt der Handhabbarkeit des Persistency- Service. Der Implementierungsaufwand für ein persistentes Interface sollte nur ge- ringfügig höher sein als der Aufwand für dasselbe Interface ohne Berücksichtigung der Persistenz. Die Problematik liegt insbesondere in der Erfassung der Attribute und dem Auslesen der Werte. In den meisten Programmiersprachen ist der Programmie- rer gezwungen für das Auslesen, wie auch für das Schreiben sämtlicher Attribute ei- nes Objektes zwei eigene Methoden zu definieren, die rekursiv die Klassenhierarchie durchlaufen um an die Attribute zu gelangen. Der Nachteil eines solchen Vorgehens liegt auf der Hand, die „Wartung“dieser Methoden ist umständlich. Immer dann, wenn Attribute nachträglich in eine Klasse eingefügt oder gelöscht werden, ist der Program- mierer gezwungen, selber Hand anzulegen und seine Attributauslesemethode bezie- hungsweise eine -schreibmethode anzupassen. Da aber auch die Entscheidung für die Programmiersprache Java zu unseren Designaspekten gehört, ist es für einen Persi- stency Service sinnvoll, wenn seine Spezifikation flexibel genug ist, die Verwendung des Java-spezifische Moduls „java.lang.reflect“sinnvoll zu ermöglichen. Das heißt, daß der Dienst in der Lage sein muß Objektdaten zu speichern, ohne daß die Struktur des Objektes schon zur Compilezeit bekannt ist. Stattdessen soll das Objekt dynamisch zur Laufzeit Metainformationen über sich selbst erfragen können, mit de- nen es dann in der Lage ist, seine eigenen Attribute ohne zutun des Programmieres zu speichern, beziehungsweise zu laden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1: Schematische Darstellung Persistency-Service nach OMG

4.2 Spezifikation nach OMG

Die OMG hat eine Spezifikation eines Persistency-Service in [OMG97] herausgege- ben. Diese ermöglicht das Speichern von Objekten in einer oder auch mehreren un- terschiedlichen Datenbanken. Der Designer dieses Dienstes versucht den Dienst sehr flexibel zu gestalten, erzielt aber damit einen sehr hohen Grad an Komplexität1, der der Aufgabe einer Speicherung von Objekten nicht gerecht ist.

Bei der Anwendung des spezifizierten Services ist es vorgesehen, daß zum Spei- chern von Objekten eines Interface ein neues Interface, das nur die Datenobjekte in der Datenbank speichert, definiert wird (siehe Abbildung 4.1). Das heißt, man braucht für dieses Dateninterface wiederum ein spezielles Interface, das als Factory dient, um Ob- jekte erzeugen zu können. Dieses sollte dann auch in einem Factory Finder eingetragen

Quelltextauszug 4.1 Persistency-Service Modul (verkürzt)

Abbildung in dieser Leseprobe nicht enthalten

werden, um ein transparentes Erzeugen von Instanzen zu ermöglichen. Somit hat man einen enormen Overhead alleine für die Implementierung eines persistenten Interfa- ces. Zudem wiederspricht dieses Konzept der Anforderung, die Objektdatenstruktur erst zur Laufzeit angeben zu müssen, weil in dieser Spezifikation für die Daten ein eigenes Interface angelegt werden muß, daß aber schon zur Compilezeit bekannt ist und nicht mehr zur Laufzeit verändert werden kann.

Somit trägt neben der unnötig hohen Komplexität des von der OMG spezifizierten Dienstes als auch die fehlende Möglichkeit die Features von Java auszureizen dazu bei, den von der OMG spezifizierten Persistency-Services für die WASA-Implementierung abzulehnen.

4.3 Neue Spezifikation

Ziel der neuen Spezifikation des Persistency-Service ist es, die in Abschnitt 4.1 ge- nannten Anforderungen so gut wie möglich zu erfüllen. Der Quelltextauszug 4.1 zeigt die verkürzte Spezifikation des Persistency-Service, bestehend aus einem Modul und drei Interfaces:

4.3.1 Database

Das Interface Database entspricht einer abstrakten Sicht auf eine Datenbank. Jede Datenbank im System, die vom Persistency-Service genutzt werden soll, muß genau

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 4.2 Database Interface

Abbildung in dieser Leseprobe nicht enthalten

eine Instanz dieses Interface zur Verfügung stellen. Der Quelltextauszug 4.2 zeigt die Methoden, die zur Verfügung gestellten werden müssen. Um Daten zu speichern, sieht das Konzept vor, eine Transaktion in der Datenbank zu belegen, die die notwendigen Methoden zur Speicherung der Daten zur Verfügung stellt.

Zur Identifizierung von persistenten Objekten wird ein im gesamten System ein- deutiger Schlüssel benötigt. Hier ist es zunächst naheliegend den CORBA-Objekt- schlüssel zu verwenden. Dieses hat aber den unangenehmen Nebeneffekt, daß eine Verschiebung von Objekten zwischen den Rechnern nicht mehr transparent durchge- führt werden kann. Die Lösung des Problems ist die Verwendung nur noch eines Teils des CORBA-Objektschlüssels für die Identifikation. Die Idee ist, den Teil des Objekt- schlüssels zu nehmen, der für den Programmierer unabhängig von dem Ort des Objek- tes frei wählbar ist. Dieser ist der Marker, der nur die Restriktion hat, daß er eindeutig innerhalb eines Objektservers definiert sein muß. Dieser Marker wird im folgenden als eindeutiges Identifikationsmerkmal benutzt, indem sichergestellt wird, daß jeder Marker für persistente Objekte genau einmal vorkommt. Daher stellt jede Datenbank die Methode getNewObjectmarker zur Verfügung, die einen neuen eindeutigen Marker zurückgibt.

An Hand eines Markers kann jede Datenbank wiederum mit der Methode find- Database feststellen, auf welcher Datenbank sich das persistente Abbild eines Ob- jektes befindet. Der Vorteil einer solchen Spezifikation ist nicht nur die einfache Hand- habung, sondern auch die Flexibilität in der Implementation. Hat man nur eine Daten- bank, so ist der Implementierungsaufwand der beiden zu letzt genannten Methoden sehr gering. Sind mehrere Datenbanken nötig, ohne daß ein Verschieben persistenter Abbilder der Objekte zwischen den Datenbanken relevant ist, so fällt nur ein geringer zusätzlicher Implementierungsaufwand an um dieses neue Ziel aus der „eine Daten- bank Implementierung“zu erreichen. Es reicht dann einfach aus dafür zu sorgen, daß die möglichen Wertebereiche der Marker für die verschiedenen Datenbanken disjunkt sind. (Das heißt, dem Marker kann direkt angesehen werden zu welcher Datenbank er gehört.)

Die letzte Ausbaustufe des Dienstes ist eine „mehr-Datenbank-Implementation mit Verschiebung der persistenten Abbilder“. Hier muß ein Marker unabhängig von der

Datenbank sein, so daß eine Marker-Datenbank-Zuordnung im System existieren muß, die optimaler Weise auch noch verteilt (und gegebenenfalls redundant) verwaltet wird.

Zu allerletzt ermöglicht das Interface das Erzeugen korrekter² Referenzen auf per- sistente Objekte an Hand der Struktur UnboundObjectRef, beziehungsweise des Markers. Die Methode bindUnboundObjectRef versucht mit den ihr gegebenen Daten eine Referenz auf das gewünschte Objekt zu erzeugen, sofern es im Speicher des Servers vorhanden ist. Ist das Objekt noch nicht hochgeladen, so muß eine Instanz des Objektes auf dem entsprechenden Server unter Verwendung der gespeicherten Daten erzeugt werden. Die Methode bindMarker kann eine Referenz auf ein gespeichertes Objekt erzeugen, ohne zu wissen, von welchem Server dieses Objekt zur Verfügung gestellt wird. Dafür werden diese Daten aus der Datenbank geladen und anschließend die Methode bindUnboundObjectRef aufgerufen.

Ein Beispiel für die Anwendung des Persistency-Service kann erst dann sinn- voll behandelt werden, wenn auch die beiden anderen Klassen Transaction und Persistent Objekt erklärt worden sind und die Implementierung des Dienstes insbesondere im Zusammenhang mit java.lang.reflect erklärt wurde. Daher findet sich ein Beispiel erst in Abschnitt 4.5.

4.3.2 Transaction

Die grundlegende Spezifikation des Interfaces Transaction zeigt der Quelltext- auszug 4.3. Instanzen von Transaction werden von Instanzen des Interface Database erzeugt und wieder freigegeben. Eine Instanz von Transaction ent- spricht dem Sachverhalt einer Transaktion im Kontext der Datenbanktechnik. Das heißt, eine Transaktion kann begonnen werden (start) und ermöglicht somit einen Zugriff auf die Datenbank nach dem ACID-Prinzip [Vos94], bis diese erfolgreich be- endet (commit) oder abgebrochen wird (abort).

Das Interface Transaction unterstützt auch verschachtelte Transaktionen. Da- mit können Schreib-/Leseoperationen für persistente Objekte über mehrere verschie- dene Datenbanken stattfinden. Durch diese Spezifikation ist es somit dem Program- mierer von persistenten Objekten offen gelassen, ob er seine Objekte nach jedem ver- ändernden Methodenaufruf sofort speichert, oder ob er lieber zu gewissen Zeitpunkten die vollständige Objektstruktur, das heißt das eigentliche Objekt und alle von diesem Objekt referenzierten Objekte, speichert. Im ersten Fall werden keine verschachtelten Transaktionen benötigt und man hat den Vorteil, daß die Methoden des persistenten Objektes ohne viel Aufwand so programmiert werden können, daß sie das ACID- Prinzip erfüllen. Der größte Nachteil ist der enorme Datenbankzugriffsoverhead. Ver- schachtelte Transaktionen sind im zweiten Fall sehr von Vorteil, weil damit gewährlei- stet werden kann, daß nur dann Schreibzugriffe auf die Datenbank wirksam werden, wenn auch wirklich alle Objekte korrekt geschrieben worden sind. Der Vorteil dieser Methode ist ein geringer Datenbankzugriffsoverhead, der aber durch den Nachteil von

Quelltextauszug 4.3 Transaction Interface (verkürzt)

Abbildung in dieser Leseprobe nicht enthalten

Quelltextauszug 4.4 PersistentObject Interface

Abbildung in dieser Leseprobe nicht enthalten

möglichen Informationsverlusten erkauft wird, weil die Daten nicht nach jeder Ände- rung gespeichert werden. In Fällen, in denen Objektzustände nicht notwendigerweise immer auf dem letzten Stand persistent gespeichert werden müssen, ist diese zweite Methode eine sinnvolle Alternative.

Bevor Objektattribute geschrieben werden können, muß mit pushWorking- ObjectMarker festgelegt werden, von welchem Objekt diese Attribute stammen. Jede Transaction verwaltet dazu einen Stack, in dem das gerade zu bearbeitende Objekt an oberster Stelle liegt. Dieses Stack-Konzept ist zwar prinzipiell nicht not- wendig, aber es unterstützt das Konzept von verschachtelten Transaktionen auf sehr elegante und einfache Weise und erleichtert dem Anwendungsprogrammierer die Ver- wendung von Transaction, weil er sich nur an wenigen definierten Stellen (wenn überhaupt) um die Objekt-Marker kümmern muß.

Anschließend können die objektspezifischen Daten mit readObject bezie- hungsweise writeObject gelesen oder geschrieben werden. Attribute werden über Methoden wie zum Beispiel readAttrLong oder writeAttrLong bearbeitet, die für alle grundlegenden IDL-Datentypen (wie: long, unsigned long, short, ...) existieren.

4.3.3 Persistent Object

Für den Anwender des Persistencyservice ist das Interface PersistentObject (siehe Quelltextauszug 4.4) von besonderer Bedeutung, weil alle Anwenderinterfa- ces, die Persistenz ihrer Daten gewährleisten wollen, sich von diesem Interface ablei- ten müssen. Die Aufgabe des Programmieres eines persistenten Objektes beschränkt sich auf die Programmierung der Methoden saveMeT und loadMeT. Die beiden Methoden saveMe und loadMe brauchen im allgemeinen nicht neu überladen zu werden, weil diese lediglich eine Transaktion belegen und anschließend die jeweilige loadMeT beziehungsweise saveMeT Methode aufrufen.

Auch hier ist das Aufteilen der Methoden zur Speicherung / zum Laden der Ob- jekte in jeweils zwei Methoden eine Anpassung an die Möglichkeit verschachtelter Transaktionen. In dem Fall, daß es gewünscht sein sollte das aktuelle Objekt und alle an diesem Objekt hängenden Referenzen zu speichern, muß nicht für jedes referen- zierte Objekt eine neue Transaktion begonnen werden, sondern es kann mit der schon

allokierten Transaktion gearbeitet werden, sofern beide Objekte in derselben Daten- bank gespeichert sind. Diese Art der Spezifikation hat nur einen sehr geringen Mehr- aufwand in der Implementierung zur Folge, spart aber bei komplexen Objektstrukturen mit wenigen Datenbanken Resourcen und somit auch Abarbeitungszeit.

4.4 Implementierung

Der oben vorgestellte Persistency-Service ist in Java Version 1.1 in dem Modul DB_Oracle implementiert. Dieses Modul enthält die beiden Interfaces Ora- cle_Database und Oracle_Transaction, die sich von den Interfaces Database beziehungsweise Transaction ableiten. Die Daten werden in ei- ner Oracle -Datenbank gespeichert. Der Zugriff auf die Datenbank erfolgt über die JDBC-Treiber der Firma WebLogic für Oracle-Datenbanken.

Das Modul Oracle_Database ist in der „mehr Datenbank Implementierung ohne Verschieben der persistenten Abbilder“implementiert worden. Der Grund dafür liegt in der Tatsache, daß diese Ausbaustufe eine optimales Verhältnis zwischen Flexi- bilität und Implementierungsaufwand bietet (siehe Abschnitt 4.3.1) und dabei dennoch den Weg offen hält, bei Bedarf diese Implementierung zur letzten Ausbaustufe zu er- weitern.

Das Hochladen von nicht im flüchtigen Speicher vorhandenen Objekten eines Ser- vers ist nicht in der Methode Database.bindUnboundObjectRef implemen- tiert worden, sondern in einem Loader. Loader sind ein Feature von OrbixWeb, die es ermöglichen Objekte automatisch bei Anfrage zu laden, wenn diese auf dem Ser- ver nicht vorhanden sind. Dies geschieht dadurch, daß auf jedem Server ein von der Klasse LoaderClass abgeleitetes Objekt installiert wird, welches im Falle eines nicht Auffindens eines gewünschten Objektes aktiviert wird und die Möglichkeit hat, dieses Objekt über den Persistency-Service aus der Datenbank hochzufahren. Diese Aufgabe übernimmt die Klasse CosPersistency.PersistencyLoader, die von jedem Server verwendet werden muß. Auf diese Weise werden Objekte immer dann hochgeladen, wenn versucht wird, diese zu binden und diese nicht im flüchti- gen Speicher vorhanden sind. Dieses geschieht auch dann, wenn nicht die Methode Database.bindUnboundObjectRef verwendet wird und ist somit vollständig transparent für den Anwendungsprogrammierer.

Das Interface PersistentObject wurde der Art implementiert, daß der An- wendungsprogrammierer in den üblichen Fällen keine Methode überladen muß, um seine Objektattribute zu speichern, sofern er sich an einige kleine Richtlinien hält. Dieses ist nur durch das Java-Paket java.lang.reflect möglich geworden. Mit Hilfe dieses Paketes ist es einem Objekt möglich, selber Metainformationen über seine eigene Klassenzugehörigkeit sowie seine eigenen Konstruktoren, Methoden und Attri- bute zu erhalten.

Wird daher auf einem sich von PersistentObject abgeleiteten Objekt die Methode saveMeT aufgerufen, so beginnt sich das Objekt, sofern diese Metho- de nicht überladen wurde, selber zu analysieren. Es werden zunächst alle zu die- sem Objekt zugehörigen Attribute erfragt und deren Modifizierer bestimmt. Über

java.lang.reflect ist es nicht möglich auf Attribute zuzugreifen, auf die man auch zur Compilezeit keinen Zugriff hatte, weil sie geschützt sind (zum Beispiel private Attribute). Dieses hat zur Folge, daß nur Attribute persistent gespeichert werden können, die auch als public deklariert wurden. Die anderen werden an die- ser Stelle einfach ignoriert. Allerdings ist dies keine sehr große Schwäche dieses Kon- zeptes, weil damit auf keinste Weise die Funktionalität eingeschränkt wird und man unter CORBA nur auf Attribute zugreifen kann, die über Methoden erreichbar sind.

Ist die Menge der öffentlich zugänglichen Attribute bestimmt, so werden jetzt die Datentypen der Attribute überprüft. Es werden nur Typen gespeichert, die ein- fache Datentypen sind und auch von der Sprache IDL unterstützt werden (dazu ge- hören: int, short, char, byte, float, double und boolean). Des wei- teren werden auch die beiden komplexen Datentypen java.lang.String und CosPersistency.rawdata für die binäre Speicherung von Daten unterstützt.

Referenzen auf andere Objekte werden in sofern unterstüzt, als sich diese Ob- jekte von dem Interface CosPersistency::PersistentObject auf CORBA- Ebene beziehungsweise von CosPeristency._PersistentObjectRef auf Java-Ebene ableiten müssen. Die derzeitige Implementierung sieht für die Referenzen keine rekursive Speicherung vor, weil es im Falle eines Workflowmanagementsystems sinnvoll erscheint Daten nicht nur ohne Verluste wiederherstellen zu können, sondern weil auch die ACID-Eigenschaft von Methoden erwünscht ist und diese eine rekursive Speicherung von Daten nicht erfordert, aber ein direktes Speichern nach Attributver- änderungen benötigt (siehe Abschnitt 4.3.2).

Für den Fall, daß Klassen um Attribute erweitert werden, ist die nach außen nicht sichtbare Methode defaultValue vorgesehen. Diese Methode kann vom Anwen- dungsprogrammierer überladen werden, und wird immer dann aufgerufen, wenn ver- sucht wird ein Objekt hochzuladen, daß neue zusätzliche Attribute erhalten hat, die zum Zeitpunkt der Speicherung noch nicht vorhanden waren. In dieser Methode kann dieses Problem abgefangen werden und ein Wert zurückgegeben werden, der in das Attribut eingetragen werden soll.

Sollten dem Anwendungsprogrammierer nicht die von mir unterstützten Datenty- pen ausreichen, so braucht er nicht auf den Komfort der automatischen Attributspei- cherung vollständig zu verzichten. Der Programmierer braucht lediglich die Methoden loadAttributes beziehungsweise saveAttributes zu überladen. Er kann an dieser Stelle dann seine speziellen Datentypen wie gewünscht speichern und ruft an- schließend, die ursprünglichen Methoden auf.

Bei dem Versuch die Methode readAttrRaw unter Orbix zu implementieren ist das Problem aufgetreten, daß Orbix nicht in der Lage ist größere Sequenzen von Octets (in der Größenordnung von mehr als ca. 20 kByte) korrekt als Rückgabepara- meter zu übertragen. Um diesem Problem zu begegnen ist die Rückgabe des Daten- typs rawdata bei der Methode readAttrRaw über einen Iterator gelöst worden, der die Daten in Form von kleineren Sequenzen vom Server zum Klienten überträgt. Zu diesem Zweck ist das Interface RawdataIterator nachträglich in das Modul CosPersistency eingefügt worden.

[...]

---

¹ Mit Seiteneffekten ist hier die schon aus den Programmiersprachen bekannte Problematik von globa- len Parametern (Variablen) gemeint, die insbesondere beim nachträglichen Verändern auftritt, bedingt durch die Eigenschaft von globalen Variablen, ihnen nicht ansehen zu können an welchen Stellen und im welchen kausalen Zusammenhang Zugriffe auf diese geschehen.

² Korrekt bedeutet in diesem Falle, daß das Objekt mit seiner tatsächlichen Klasse und nicht mit einer seiner Superklassen gebunden wird. Diese Eigenschaft ist wichtig, wenn der Rückgabewert über die Methode _narrow in eine Subklasse umgewandelt werden soll (siehe [Ion96]).