Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen [original]

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

Datenbank-Spektrum 4/2002 59

Prozessorientierte Anwendungen lassen

sich nur durch die Verwendung eines

Workflow-Management-Systems (WfMS)

mit vernünftigem Aufwand und zu akzep-

tablen Kosten realisieren. Jedoch stoßen

zentrale WfMS mit nur einem einzigen

Server zur Steuerung aller Workflows

(WF) oftmals sehr schnell an ihre Leis-

tungsgrenze. Zur Erhöhung der Skalier-

barkeit von WfMS werden deshalb zahl-

reiche Ansätze für die Realisierung von

WfMS mit mehreren WF-Servern vorge-

schlagen. Bei vielen dieser Multi-Server-

WfMS wird der konkrete WF-Server zur

Kontrolle einer bestimmten WF-Aktivität

meist durch eine Serverzuordnung festge-

legt. Jedoch entstehen bei solchen verteil-

ten WfMS Probleme, wenn einzelne Kom-

ponenten (WF-Server, Teilnetze oder

Gateways) überlastet sind oder ausfallen.

Eine aus anderen Bereichen der Informa-

tik bekannte Vorgehensweise ist in sol-

chen Fällen, die Hardwarezuordnung

dynamisch zu verändern. In der vorlie-

genden Arbeit wird erstmalig untersucht,

inwieweit durch eine dieser Vorgehens-

weise entsprechende dynamische Ände-

rung von Serverzuordnungen in verteilten

WfMS geeignet auf Überlast- und Aus-

fallsituationen reagiert werden kann.1

1 Einleitung

WfMS ermöglichen die computerunter-

stützte Ausführung von Arbeitsprozessen

(engl. Workflow; kurz: WF) in einer ver-

teilten Systemumgebung (vgl. [AH02,

JBS97, LR00, Obe96]). Der entscheiden-

de Vorteil von WfMS ist, dass sie helfen,

prozessorientierte Anwendungssysteme

überschaubarer und damit besser wartbar

zu gestalten. Dazu wird der applikations-

spezifische Code der benutzten Anwen-

dungen von der Ablauflogik des Ge-

schäftsprozesses (»Prozesslogik«) ge-

trennt. Anstelle eines großen monolithi-

1. Diese Arbeit wurde im Rahmen des von der

Deutschen Forschungsgemeinschaft (DFG)

geförderten Projekteslierbarkeit in adaptiven

Workflow-Management-Systemen« erstellt.

schen Programmpakets erhält man ein-

zelne Aktivitäten, welche die Anwen-

dungsprogramme repräsentieren. Ihre

Ablauflogik wird in einer separaten Be-

schreibung festgelegt, welche die Aus-

führungsreihenfolge (Sequenz, bedingte

oder parallele Verzweigung, Schleifen)

der einzelnen Aktivitäten und die Daten-

flüsse zwischen ihnen bestimmt. Durch

die beschriebene Trennung können Ent-

wurfsfehler bzgl. des Prozessablaufs

noch vor Implementierung der eigentli-

chen Anwendungskomponenten entdeckt

werden. Aus denselben Gründen sind

spätere Änderungen der Geschäftspro-

zesse und dadurch notwendige Anpas-

sungen der Anwendungssysteme einfa-

cher durchführbar.

Ausgehend von einem solchen WF-

Modell können berechtigte Benutzer zur

Laufzeit neue WF-Instanzen erzeugen

und starten. Die Ausführung dieser WF-

Instanzen wird vom WfMS über ihre

komplette Lebendauer hinweg koordi-

niert und überwacht. Dabei sorgt das

WfMS dafür, dass jeweils nur solche Ak-

tivitäten einer WF-Instanz bearbeitbar

sind, die der Ablauflogik zufolge aktuell

zur Ausführung anstehen. Diese werden

in die Arbeitslisten berechtigter Benutzer

eingefügt. Welche Personen zur Bearbei-

tung einer bestimmten Aktivität autori-

siert sind, wird dabei meist durch Angabe

einer Rolle festgelegt, die auch den ent-

sprechenden Bearbeitern zugeordnet sein

muss. Dabei ist es möglich, dass mehrere

Benutzer ermittelt werden, die für die Be-

arbeitung einer bestimmten Aktivität in

Frage kommen.

Generell besteht bei (zentralen)

WfMS das Problem, dass der einzelne

WF-Server durch die vielen zu erledigen-

den Aufgaben (z.B. Aktualisieren von

Benutzerarbeitslisten, interpretative Aus-

führung von WF-Graphen, Starten von

Aktivitätenprogrammen) und durch die

hohe Anzahl der zu kontrollierenden WF-

Instanzen überlastet sein kann. Zur Ver-

meidung von Überlastsituationen in

WfMS wurden in der Vergangenheit zahl-

reiche Ansätze für ein verteiltes WF-Ma-

nagement entwickelt (z.B. [Bau01,

MWW+98, SNS99]). Ihnen liegt allesamt

die Idee zugrunde, dass die zu bewälti-

gende Last auf mehrere WF-Server auf-

geteilt wird. Des Weiteren wird üblicher-

weise versucht, für die Kontrolle der Ak-

tivitäten jeweils einen gut geeigneten

WF-Server auszuwählen. Hierfür bietet

sich z.B. der WF-Server desjenigen Teil-

netzes an, in welchem die Mehrzahl der

potenziellen Bearbeiter der jeweiligen

Aktivität angesiedelt ist. Durch die topo-

logische Nähe der entsprechenden WF-

Clients zum betroffenen WF-Server er-

gibt sich bei dieser Art der Serverzuord-

nung ein günstiges Kommunikationsver-

halten (vgl. [Bau01, BD99]), d.h., es re-

sultieren kurze Antwortzeiten und niedri-

ge Kommunikationskosten.

Üblicherweise wird bei den in der

Literatur diskutierten Ansätzen für ver-

teiltes WF-Management der für eine be-

stimmte WF-Aktivität zuständige WF-

Server bereits bei der Modellierung des

betreffenden Workflow festgelegt. In be-

stimmten Situationen kann es jedoch

sinnvoll sein, von diesen vorgeplanten

Serverzuordnungen abzuweichen. Eine

auch aus anderen Bereichen der Informa-

tik bekannte Vorgehensweise ist in die-

sem Zusammenhang, die Zuordnung von

Aufgaben zu Hardwarekomponenten erst

zur Ausführungszeit durchzuführen. Ein

Beispiel hierfür ist das Prozess-Schedu-

ling in Betriebssystemen (vgl. [CK88,

Gos91]). Hier wird der Prozessor für die

Ausführung eines Betriebssystemprozes-

ses meist erst bei dessen Start ausgewählt.

Auch bei der verteilten Systemumgebung

CORBA [OMG95] sowie gängigen Ap-

plikationsservern wird der Server zur Be-

arbeitung eines Methodenaufrufs ggf.

erst zur Laufzeit ausgewählt. Dabei kann

die aktuelle Last- und Ausfallsituation

berücksichtigt werden.

Wird diese weit verbreitete Vorge-

hensweise auf verteilte WfMS übertra-

gen, kann dadurch etwa versucht werden,

die Überlastung einer WfMS-Kompo-

nente (WF-Server, Teilnetz oder Gate-

way) zu kompensieren. Ist zum Beispiel

ein bestimmter WF-Server überlastet,

können Aufgaben, für die er ursprünglich

vorgesehen war, einem anderen, augen-

blicklich weniger belasteten Server über-

tragen werden. Ein anderes Szenario, in

dem von einer dynamischen (also zur

Laufzeit der WF-Instanzen stattfinden-

Thomas Bauer, Manfred Reichert

Dynamische Änderung von Server-

zuordnungen in verteilten Workflow-

Management-Systemen

Diese Arbeit wurde im Rahmen des von der

Deutschen Forschungsgemeinschaft (DFG) ge-

förderten Projektes »Skalierbarkeit in adaptiven

Workflow-Management-Systemen« erstellt.

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

60 Datenbank-Spektrum 4/2002

den) Veränderung der Serverzuordnun-

gen – im Folgenden kurz dynamische Ser-

veränderungen genannt – Gebrauch ge-

macht werden kann, ist der Ausfall von

Komponenten des WfMS. In diesem Fall

kann (dynamisch) ein anderer WF-Server

für die Kontrolle der betroffenen Aktivi-

täten bzw. Aktivitäteninstanzen gewählt

werden.

Aus den dargelegten Gründen er-

scheint die Verwendung dynamischer

Serveränderungen – zumindest bei ober-

flächlicher Betrachtung – sehr vorteilhaft

zu sein. Wir haben deshalb systematisch

untersucht, ob und wie dynamische Ser-

veränderungen zur Lösung der genannten

Probleme (Überlastung bzw. Ausfall von

Systemkomponenten) sinnvoll verwendet

werden können. Interessanterweise hat

sich dabei herausgestellt, dass dynami-

sche Serveränderungen für die Behand-

lung von Ausfall- und Überlastsituatio-

nen nur bedingt geeignet sind. Der Haupt-

beitrag dieser Arbeit besteht darin, aufzu-

zeigen, warum dem so ist und welche

speziellen Schwierigkeiten mit einem

solchen Ansatz verbunden sind. Des Wei-

teren wird dargelegt, wie der Überlastung

und dem Ausfall von WfMS-Komponen-

ten durch alternative Verfahren, wie sie

das von uns entwickelte verteilte WF-

Ausführungsmodell ADEPTdistribution

(vgl. [Bau01, BD97, BRD01b]) bietet,

geeigneter begegnet werden kann.

Der vorliegende Beitrag unterschei-

det sich von unseren bisherigen Veröf-

fentlichungen zu verteiltem Workflow-

Management dadurch, dass die WF-Ser-

ver im ADEPTdistribution-Ausführungs-

modell den Aktivitäten bereits zur Mo-

dellierungszeit zugeordnet werden oder

diese Zuordnung zumindest vorgeplant

wird (vgl. [BD00]). Ziel dabei ist es pri-

mär, die Belastung des Kommunikations-

systems zu reduzieren. In diesem Beitrag

wollen wir untersuchen, welches Potenzi-

al in einer dynamischen Veränderung die-

ser Serverzuordnungen bei der Ausfüh-

rung der WF-Instanzen liegt.

Im nachfolgenden Abschnitt werden

wichtige Grundlagen für verteiltes WF-

Management skizziert. Sie sind für das

weitere Verständnis dieses Beitrags not-

wendig. Abschnitt 3 untersucht, in wel-

chen Zuständen einer WF-Instanz dyna-

mische Änderungen von Serverzuord-

nungen möglich und sinnvoll sind. Der

nachfolgende Abschnitt 4 widmet sich

der Behandlung von Überlastsituationen,

während Abschnitt 5 auf den Ausfall von

Komponenten des verteilten WfMS ein-

geht. Abschnitt 6 behandelt Alternativen

zu dynamischen Serveränderungen, mit

denen sich die beschriebenen Problem-

stellungen besser lösen lassen. Abschnitt

7 diskutiert verwandte Ansätze. Der Bei-

trag schließt mit einer Zusammenfassung

der gewonnenen Erkenntnisse.

2 Verteiltes Workflow-

Management

Wir betrachten im Folgenden unterneh-

mensweite oder -übergreifende WF-An-

wendungen (vgl. [DR99, WWW+96]) im

operativen Einsatz. In [KAGM96, SK97]

etwa werden Szenarien beschrieben, bei

denen die Zahl der Benutzer des WfMS

bis auf einige zehntausend anwachsen

kann oder mehrere zehntausend WF-In-

stanzen gleichzeitig im System ablaufen

können. Durch diese hohe Anzahl von

Benutzern und gleichzeitig ausgeführten

WF-Instanzen wird eine sehr große Last

für die WF-Server und das Kommunika-

tionssystem erzeugt. Als Folge können

Komponenten des WfMS überlastet wer-

den.

Zur Vermeidung von Überlastsituati-

onen wird von verschiedener Seite vorge-

schlagen, eine WF-Instanz nicht nur von

einem einzigen WF-Server kontrollieren

zu lassen, sondern ihren WF-Graphen ge-

eignet zu partitionieren und abschnitts-

weise von verschiedenen WF-Servern zu

steuern. Dieser Ansatz wird auch von

ADEPTdistribution (vgl. [Bau01, BD97]),

der verteilten Variante des von uns entwi-

ckelten ADEPT-WfMS (vgl. [DRK00,

RD98, RBFD01]), verfolgt (vgl. Abb. 1).

Wird nun bei der Ausführung einer

WF-Instanz eines bestimmten WF-Typs

das Ende einer Partition erreicht, wird

ihre Kontrolle an den nächsten WF-Ser-

ver weitergereicht. Um solche Migratio-

nen zu ermöglichen, muss jeweils eine

Beschreibung des Zustands der WF-In-

stanz (aktueller Ausführungszustand und

aktuelle Werte von Parameterdaten der

Aktivitätenprogramme) zu diesem Server

transportiert werden (vgl. [BRD01b]).

Wie bereits erwähnt, verwenden auch

andere Ansätze eine solche Partitio-

nierung von WF-Graphen zur Modellier-

zeit und die zugehörigen Migrationen

während der Ausführungszeit (z.B.

[CGP+96, MWW+98]). Einige dieser

Ansätze verfolgen zusätzlich das Ziel, die

Kommunikationskosten zu minimieren.

Konkrete Erfahrungen mit existierenden

WfMS haben gezeigt, dass zwischen ei-

nem WF-Server und seinen WF-Clients

sehr viel kommuniziert wird und zum

Teil auch große Datenmengen ausge-

tauscht werden (vgl. [Mar01]). Dies kann

dazu führen, dass das Kommunikations-

system überlastet wird. Deshalb wird in

ADEPTdistribution zur Modellierzeit für

jeden Aktivitätentyp automatisch derje-

nige WF-Server berechnet, durch dessen

Verwendung der Gesamtkommunikati-

onsaufwand minimiert wird (vgl. [BD97,

BD00]). In der Regel wird dabei der WF-

Server einer Aktivität so gewählt, dass er

im Teilnetz der Mehrzahl ihrer potenziel-

len Bearbeiter liegt. Allerdings wird bei

der Berechnung der Serverzuordnung

auch berücksichtigt, dass die Migratio-

nen selbst ebenfalls (Netzwerk-)Last ver-

ursachen (vgl. [BD97]).

ADEPTdistribution erfüllt darüber hin-

aus die Konsistenzbedingung, dass die

verteilte Ausführung von Workflows äqui-

valent (bzgl. der den Benutzern ermög-

lichten Aktionen) zu einer von einem zen-

tralen WF-Server gesteuerten WF-Aus-

führung ist (vgl. [Bau01, WW97]). Dabei

Abb. 1: a) Migration einer WF-Instanz und b) daraus resultierender Zustand der WF-Instanz

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

Datenbank-Spektrum 4/2002 61

ist die Systemarchitektur von ADEPTdis-

tribution so gestaltet, dass die verschiede-

nen WF-Server auf getrennten (jeweils lo-

kal platzierten) Datenbanken arbeiten. Die

Synchronisation und der Austausch von

Daten zwischen diesen WF-Servern (und

damit auch zwischen den Datenbanken)

erfolgt ausschließlich durch die schon er-

wähnten Migrationen. (Die Anwendungs-

daten werden, soweit dies möglich ist,

ebenfalls vom WfMS verwaltet, so dass

auch diese in Migrationen einbezogen

werden können.)

Die beschriebene Vorgehensweise ist

wesentlich effizienter (vgl. hierzu [BD97,

BD99, BRD01b])1 als etwa eine Replika-

tion der Daten auf Datenbankebene, da

hier zusätzlich Anwendungswissen ge-

nutzt werden kann. Aus demselben

Grund ist das WfMS besser in der Lage,

(durch eine geeignete Serverauswahl) die

Kommunikationslast zu reduzieren, als

dies durch eine tiefer liegende Schicht

(z.B. das Betriebssystem) möglich wäre.

Die WF-Clients sind mit mehreren WF-

Servern verbunden, ggf. sogar mit allen

WF-Servern des WfMS. Allerdings be-

findet sich normalerweise genau ein WF-

Server in ihrer Domäne. Zu diesem be-

steht, wegen dessen lokaler Lage, eine be-

sonders schnelle (und auch kostengünsti-

ge) Verbindung. Deshalb ist es vorteil-

haft, wenn die von einem WF-Client aus-

geführten Aktivitäteninstanzen vom lokal

gelegenen WF-Server kontrolliert wer-

den.

3 Realisierungsvarianten für dyn.

Serveränderungen

Die Art und Weise, wie dynamische Ser-

veränderungen durchgeführt werden, hat

großen Einfluss auf die entstehenden

Kosten und den resultierenden Nutzen. In

diesem Abschnitt untersuchen wir die ge-

nerellen Möglichkeiten zur Durchfüh-

rung von Migrationen, bei denen der Ziel-

server erst zur Ausführungszeit festgelegt

wird (dynamische Migration). Die dyna-

mischen Migrationen sollen dazu dienen,

ein für die Benutzer des WfMS günstiges

Verhalten zu erzielen (Quality of Ser-

vice).

1. In [BRD01b] wird ein Verfahren vorgestellt,

mit dem nicht der gesamte Datenkontext der

migrierten WF-Instanz übertragen werden

muss, sondern nur die tatsächlich für die wei-

tere WF-Ausführung noch benötigten Daten.

Es geht also darum, die Verfügbarkeit

und das Antwortzeitverhalten des WfMS

zu verbessern. Eine Erhöhung des

WfMS-Durchsatzes ist nicht unser Ziel,

da dies für die Benutzer des WfMS kei-

nen unmittelbaren Vorteil bringt. (Eine

Erhöhung des Durchsatzes lässt sich im

Falle von Überlastungen am einfachsten

durch die Suspendierung von WF-Instan-

zen erreichen, allerdings auf Kosten der

Antwortzeiten. Der für die Durchführung

von Migrationen notwendige Aufwand

kann den Gesamt-Systemdurchsatz na-

türlich nur verschlechtern.)

Damit die Reaktion auf die Überlas-

tung oder den Ausfall von WfMS-Kom-

ponenten möglichst zeitnah erfolgen

kann, sollte der WF-Server der aktuell zu

bearbeitenden Aktivität(en) modifiziert

werden. Um eine größere Wirkung zu er-

zielen und um unnötige Migrationen zu

verhindern, empfiehlt es sich dabei, stets

die Serverzuordnung der gesamten aktu-

ellen Partition zu verändern. Entschei-

dend ist hierbei der Zeitpunkt, zu dem

dies geschieht. Prinzipiell bestehen die

folgenden Möglichkeiten (vgl. Abb. 2):

Ansatz 1:

Dynamische Serveränderungen kön-

nen zu beliebigen Zeitpunkten erfolgen

Bei diesem Ansatz werden dynamische

Abweichungen von den zur Modellie-

rungszeit festgelegten Serverzuordnun-

gen zu beliebigen Zeitpunkten zugelas-

sen. Dies hat natürlich zur Folge, dass der

ursprünglich vorgesehene WF-Server alle

in die Bearbeitung der aktuellen Aktivität

involvierten WF-Clients über die Ände-

rung informieren muss. Dies wird not-

wendig, da Rückmeldungen zur aktuellen

Aktivität von den betreffenden WF-Cli-

ents ansonsten an den falschen (nämlich

veralteten) WF-Server gerichtet werden.

Außerdem wird mit diesem Ansatz bei

Serveränderungen meist eine zusätzliche

Migration notwendig.

Ansatz 2:

Dynamische Serveränderungen sind

für bereits aktivierte, aber noch nicht

selektierte Aktivitäten unzulässig

Bei dieser Vorgehensweise erfolgen kei-

ne dynamischen Migrationsentscheidun-

gen, wenn sich die Aktivität (des betrof-

fenen Ausführungszweigs) aktuell im

Zustand ACTIVATED befindet. In die-

sem Zustand wartet das WfMS darauf,

dass einer der (evtl. zahlreichen) potenzi-

ellen Bearbeiter der Aktivität diese aus

seiner Arbeitsliste auswählt und startet

(vgl. [Bau01, RD98]). Der Ausschluss

dynamischer Migrationen für diesen Fall

hat den Vorteil, dass dann noch maximal

ein Client (nämlich derjenige, der die Ak-

tivität tatsächlich bearbeitet) über die Ser-

veränderung informiert werden muss.

Ansatz 3:

Dynamische Serveränderungen sind

nur nach Beendigung von Aktivitäten

erlaubt

Sind dynamische Migrationen nur dann

möglich, wenn aktuell ein Übergang zwi-

schen zwei aufeinander folgenden Akti-

vitäten stattfindet, dann ist augenblick-

lich auch kein WF-Client in den

betrachteten Ausführungszweig der WF-

Instanz involviert. (Die abgeschlossene

Aktivität steht in keiner Arbeitsliste

mehr, wird also nicht mehr bearbeitet,

und für die nachfolgende Aktivität gibt es

noch keine Arbeitslisteneinträge.) Des-

halb muss auch kein WF-Client über die

dynamische Serveränderung informiert

werden; WF-Clients müssen bei Ansatz 3

nicht einmal wissen, dass solche Server-

änderungen zur Laufzeit möglich sind. Es

muss lediglich eine Migration durchge-

führt werden, um die dynamische Server-

änderung umzusetzen.

Ansatz 4:

Dynamische Serveränderungen sind

nur bei ohnehin vorgesehenen Migrati-

onen bzw. Partitionswechseln erlaubt

Werden dynamische Migrationsentschei-

dungen nur gefällt, wenn an der entspre-

chenden Stelle des WF-Graphen zur Mo-

dellierungszeit ohnehin eine Migration

vorgesehen worden ist, dann ist lediglich

der Zielserver der (anstehenden) Migrati-

on zu verändern. Bei dieser Vorgehens-

weise werden insbesondere keine zusätz-

lichen Migrationen notwendig.

Wir wollen nun untersuchen, wie effizient

die vier vorgestellten Varianten sind: Die

Ansätze 1 und 2 sind in ihrer Realisierung

wesentlich aufwendiger als die beiden an-

deren Ansätze, weil in die dynamische

Serveränderung evtl. WF-Clients einbe-

zogen werden müssen. Außerdem erfor-

dern sie mehr Kommunikation und sind

fehleranfälliger. Fehler können z.B. ent-

stehen, wenn ein WF-Client, der vor-

übergehend nicht erreichbar war, nun die

Ausgabedaten eines beendeten Aktivitä-

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

62 Datenbank-Spektrum 4/2002

tenprogramms an einen inzwischen veral-

teten WF-Server zurückgeben will.

Der Ansatz 3 erzeugt ebenfalls Kom-

munikationslast, da bei dynamischen Ser-

veränderungen zusätzliche Migrationen

durchgeführt werden müssen. Diese brin-

gen stets einen gewissen Aufwand mit

sich, insbesondere für das Kommunikati-

onssystem (vgl. [BD99]).

Nur der Ansatz 4 erfordert keine zu-

sätzliche Kommunikation und hat auch

keine Auswirkungen auf die WF-Clients.

Da keine Migrationen notwendig werden,

entspricht dieser Ansatz auch am ehesten

den Schedulingverfahren für Betriebssys-

temprozesse (vgl. [Gos91]). Bei diesen

wird normalerweise angenommen, dass

(noch) kein Prozesskontext existiert oder

dass dieser ohnehin auf allen beteiligten

Knoten vorhanden ist. Deshalb müssen

bei einem Prozessorwechsel (fast) keine

Daten übertragen werden. Hierzu ver-

gleichbar ist, dass bei einer dynamischen

Serverwahl kein Aufwand für eine zu-

sätzliche Migration anfällt.

Dynamische Migrationen sind aber

beim Ansatz 4 (aufgrund des geforderten

Bearbeitungszustands) für weniger WF-

Instanzen möglich. Der Grund dafür ist,

dass hier nur solche Instanzen migriert

werden können, bei denen gerade eine

(vorgeplante) Migration erfolgt. Dennoch

dürften sich bei diesem Ansatz weiterhin

genügend WF-Instanzen für dynamische

Migrationen eignen, da ein WF-Server in

dem eingangs beschriebenen Szenario zu

jedem Zeitpunkt sehr viele WF-Instanzen

kontrolliert. Dies gilt insbesondere für die

betrachteten Hochleistungs-WfMS. Ge-

nerell ist ohnehin nicht zu empfehlen, dy-

namische Serveränderungen für zu viele

WF-Instanzen auf einmal durchzuführen,

da dies zur Unterlastung des vormals

überlasteten Servers führen könnte, also

zu einem »Schwingen« der Last.

Um uns nicht unnötig einzuschrän-

ken, werden im Folgenden, trotz der er-

wähnten Schwächen bzw. Nachteile der

Ansätze 1 bis 3, jeweils alle Ansätze wei-

terverfolgt. Dabei wird untersucht, wel-

che Ansätze zur Lösung der jeweiligen

Problemstellung am besten geeignet sind.

4 Behandlung von

Überlastsituationen

Im Folgenden wird untersucht, inwieweit

die Ansätze 1 bis 4 geeignet sind, um eine

Überlastung bestimmter Komponenten

des WfMS zu kompensieren. Dabei wird

zuerst auf Überlastungen einzelner Kom-

ponenten des Kommunikationssystems

(Teilnetze, Gateways) und dann auf Über-

lastungen von WF-Servern eingegangen.

Im Anschluss daran werden Fragestellun-

gen diskutiert, die das Verhalten von dy-

namischen Serveränderungen im Allge-

meinen betreffen.

4.1 Überlastung von Komponenten des

Kommunikationssystems

Überlastung von Teilnetzen

Es wird das in Abbildung 3 dargestellte

Szenario unterstellt: Ein Teilnetz x des

WfMS ist augenblicklich überlastet, so

dass inakzeptable Antwortzeiten entste-

hen. Diese Überlastung soll behoben wer-

den, indem WF-Instanzen, die von dem

WF-Server dieses Teilnetzes kontrolliert

werden sollen, einem anderen WF-Server

zugeordnet werden.

Leider ist es durch dynamische Ser-

veränderungen nicht möglich, das Teil-

netz x zu entlasten, wenn der Großteil der

potenziellen Bearbeiter der anstehenden

Aktivitäten diesem Teilnetz angehört. Die

Kommunikation zwischen den WF-Cli-

ents dieser Benutzer und dem WF-Server

wird in einem solchen Fall weiterhin

durch das Teilnetz x laufen, da die Clients

in diesem Teilnetz angesiedelt sind. Des-

halb wird das überlastete Teilnetz nicht

signifikant entlastet.

Ungünstigerweise bildet die beschrie-

bene Bearbeiterverteilung aber den Re-

gelfall. Meist befindet sich ein Großteil

der potenziellen Bearbeiter im Teilnetz

desjenigen WF-Servers, welcher die ak-

tuelle Partition kontrolliert. Dieser Server

wurde – sinnvollerweise – gerade wegen

dieser Bearbeiterverteilung ausgewählt,

mit dem Ziel Kommunikationskosten

einzusparen (vgl. Abschnitt 2). Dieses

Ziel wird durch Einsatz dynamischer Mi-

grationen jedoch konterkariert.

Wird für die dynamische Serverände-

rung einer der Ansätze 1 bis 3 aus Ab-

schnitt 3 verwendet, so wird die Gesamt-

situation durch die zusätzlich notwendig

werdende Migration zunächst sogar noch

verschlechtert. Der Grund dafür ist, dass

eine Migration mit dem WF-Server des

Teilnetzes x als Quellserver immer auch

zu einer Belastung von Teilnetz x führt.

Eine Verwendung der Ansätze 1 oder 2

verschlechtert die Lastsituation weiter, da

hier die dynamische Serveränderung

auch noch zusätzliche Kommunikationen

mit Clients erforderlich macht.

Überlastung von Gateways

Ist ein Gateway (z.B. eine Fernkommuni-

kationsleitung) überlastet, so kann eine

ähnliche Vorgehensweise wie bei über-

lasteten Teilnetzen gewählt werden: WF-

Instanzen werden dynamisch zu einem

WF-Server migriert, dessen Teilnetz

nicht an dieses Gateway angeschlossen

ist. Allerdings ergeben sich bei dieser

Vorgehensweise ähnliche Probleme wie

im vorherigen Abschnitt beschrieben, so

dass sie als nicht empfehlenswert zu be-

trachten ist. Die erzielten Vorteile sind so-

gar geringer, da mit dem Teilnetz des ur-

sprünglich vorgesehenen WF-Servers

mehrere Gateways verbunden sind, die

durch die dynamische Migration alle ent-

lastet werden. Die Entlastung des Gate-

ways fällt dadurch nur anteilsmäßig aus.

4.2 Überlastung von WF-Servern

Von einem überlasteten WF-Server spre-

chen wir, wenn dieser die aktuell anste-

henden Aufgaben nicht mehr (vollstän-

dig) bewältigen kann. Ein solcher WF-

Server kann entlastet werden, indem WF-

Instanzen von ihm »wegmigriert« werden

bzw. WF-Instanzen, für deren Bearbei-

Abb. 2: Realisierungsvarianten für dynamische Serveränderungen

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

Datenbank-Spektrum 4/2002 63

tung er vorgesehen war, erst gar nicht zu

ihm transferiert werden.

Bei diesem Szenario führen dynami-

sche Serveränderungen schon eher zum

gewünschten Ziel, da der WF-Server tat-

sächlich weniger WF-Instanzen kontrol-

lieren muss. Allerdings wird ein überlas-

teter WF-Server bei den Ansätzen 1 bis 3

(vgl. Abschnitt 3) durch die zusätzliche

Migration weiter belastet. Da der Auf-

wand für die zusätzliche Migration (we-

gen der größeren Datenmenge) häufig

wesentlich größer ist als für eine reguläre

Aktivitätenausführung (siehe hierzu

[BRD01b]), kann sich das Verfahren so-

gar als nachteilig erweisen. Bei den An-

sätzen 1 und 2 kommen für den WF-Ser-

ver bei der dynamischen Serveränderung

auch noch Interaktionen mit den aktuel-

len Clients hinzu, was zusätzlichen Auf-

wand bedeutet. Außerdem verschlechtern

die im nachfolgenden Abschnitt beschrie-

benen generellen Nachteile dynamischer

Migrationen bei der Behebung von Über-

lastsituationen die Güte des diskutierten

Ansatzes weiter.

4.3 Allgemeine Betrachtungen

zu dynamischen Serveränderungen

in Überlastsituationen

Nachdem wir die Verfahren für dynami-

sche Migrationen bei Überlastung von

Komponenten des Kommunikationssys-

tems bzw. bei Überlastung von WF-Ser-

vern skizziert haben, wenden wir uns nun

generellen Schwierigkeiten der Verfahren

zu.

Wie alle Verfahren zur Lastbalancie-

rung erfordern auch die vorgestellten An-

sätze einen Austausch von Lastinformati-

on (in irgendeiner Form). Dabei ist irre-

levant, welches Verfahren konkret ver-

wendet wird. Vom verteilten Scheduling

von Betriebssystemprozessen sind hierzu

zahlreiche Varianten bekannt (vgl.

[Gos91]). So kann z.B. periodisch ein

Lastinformationsaustausch zwischen den

WF-Servern stattfinden oder bei einer an-

stehenden Migrationsentscheidung kann

bei potenziellen Zielservern nachgefragt

werden, wie stark diese aktuell belastet

sind. Bei all diesen Varianten trägt die

Verwendung von dynamischen Serverän-

derungen selbst zur Überlastung von

Komponenten des WfMS bei. Allerdings

kann dieser Nachteil durch die Verwen-

dung eines »Huckepack-Verfahrens«

(vgl. [Tan96]) abgeschwächt werden: Die

(relativ kleine) auszutauschende Last-

information wird bei anderen, ohnehin

notwendigen Kommunikationen mitüber-

tragen. Falls angenommen werden kann,

dass zwischen allen Paaren von WF-Ser-

vern ausreichend häufig solche Kommu-

nikationen (z.B. Migrationen) stattfinden,

dann werden für den Lastinformations-

austausch keine zusätzlichen Nachrichten

notwendig, sondern es wird lediglich das

zu übertragende Datenvolumen (gering-

fügig) erhöht.

Ein gravierenderer Nachteil lastab-

hängiger dynamischer Serveränderungen

resultiert aus den in der Praxis häufig auf-

tretenden langen »Pausen« bei der Abar-

beitung einzelner WF-Instanzen. Diese

Pausen können einerseits aus eventuellen

Prioritäten der Bearbeiter resultieren, an-

dererseits gibt es Workflows, bei denen

ein aktivierter Schritt für Tage oder gar

Wochen ruht, bevor er tatsächlich ausge-

führt wird. (Dieser Fall kann z.B. im me-

dizinischen Bereich bei lang andauernden

Therapieprozessen auftreten.) Eine zur

Entlastung einer Komponente dynamisch

migrierte WF-Instanz kann also längere

Zeit ruhen. Folglich wird in diesem Fall

kurzfristig überhaupt keine Entlastung er-

reicht. Die Entlastung der Komponente

findet erst viel später statt, zu einem Zeit-

punkt, an dem sie möglicherweise sogar

unterlastet ist. Bei Verwendung der An-

sätze 1 bis 3 ist die Situation noch

schlechter: Die Migration, die zur Entlas-

tung durchgeführt wird (und bei den An-

sätzen 1 und 2 auch die notwendig wer-

dende Interaktion mit den Clients), wird

sofort ausgeführt, weshalb zusätzlicher

Aufwand zu einem Zeitpunkt entsteht, an

dem die Überlastung noch andauert. Die-

ser negative Effekt ist bei WfMS wesent-

lich stärker ausgeprägt als beim Betriebs-

system-Scheduling, da WF-Instanzen

eine wesentlich größere Datenmenge

umfassen als übliche Betriebssystem-

prozesse. Außerdem werden beim Be-

triebssystem-Scheduling üblicherweise

ausschließlich noch nicht gestartete Pro-

zesse transferiert, so dass kein Prozess-

kontext zu übertragen ist.

4.4 Fazit

In Anbetracht der diskutierten Nachteile

sind dynamische Serveränderungen we-

nig geeignet, um der Überlastung von

Komponenten des Kommunikationssys-

tems begegnen zu können. Lediglich eine

Entlastung von WF-Servern ist theore-

tisch möglich, doch auch diese tritt erst

deutlich verzögert ein. Wird ein entspre-

chendes Verfahren gewählt, so sollte un-

bedingt der Ansatz 4 aus Abschnitt 3 ver-

wendet werden, um den WF-Server nicht

zusätzlich zu belasten. Dynamische Mig-

rationen haben sich in Überlastsituatio-

nen also als eher ungeeignet erwiesen.

5 Behandlung von

Ausfallsituationen

Um auf den Ausfall von WF-Servern,

Teilnetzen und Gateways reagieren zu

können, wird folgende Idee umgesetzt:

(Partitionen von) WF-Instanzen, die von

dem Ausfall betroffen und deshalb blo-

ckiert sind, werden dynamisch einem an-

deren WF-Server zugeordnet. Wie wir

noch sehen werden, spielt es dabei keine

Rolle, ob dadurch der Ausfall eines WF-

Servers oder einer Komponente des Kom-

munikationssystems kompensiert werden

soll. Deshalb werden diese Fälle im Fol-

genden gemeinsam betrachtet.

Abb. 3: Dynamische Änderung von Serverzuordnungen bei Überlastung eines Teilnetzes

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

64 Datenbank-Spektrum 4/2002

5.1 Eigenschaften des Verfahrens

Soll auf den Ausfall einer WfMS-Kom-

ponente durch dynamische Veränderung

von Serverzuordnungen reagiert werden,

ist es nicht möglich, die betroffenen WF-

Instanzen von ihrem aktuellen Server

»wegzumigrieren«. Das heißt, die Ansät-

ze 1 bis 3 scheiden aus. Eine solche Mig-

ration würde die Funktionsfähigkeit der

ausgefallenen Komponente voraussetzen.

Für WF-Server und Teilnetze ist diese

Aussage unmittelbar ersichtlich, da diese

Komponenten in einer entsprechenden

Migration stets direkt involviert sind. Der

Ausfall eines Gateways ist nur dann rele-

vant, wenn dies zu einer Partitionierung

des Netzwerkes führt. Andernfalls kann

jeder WF-Server jeden WF-Client weiter-

hin erreichen. Im Falle einer Netzparti-

tionierung wäre aber eine dynamische

Migration in den anderen Teil des Netz-

werkes notwendig, damit der WF-Server

die dort angesiedelten WF-Clients an-

schließend erreichen kann. Eine solche

Migration ist aber aufgrund des Ausfalls

der Kommunikationsverbindung ausge-

schlossen. Aus den erläuterten Gründen

bleibt im Zusammenhang mit der Kom-

pensation von Komponentenausfällen le-

diglich die Verwendung von Ansatz 4.

Für Benutzer, die aufgrund der Blockie-

rung einer WF-Instanz auf die Bearbei-

tung ihrer Aktionen warten müssen, ist

aber mit einem solchen Verfahren keine

Verbesserung zu erzielen. Sie können

weiterhin bestimmte, in ihrer Arbeitsliste

angebotene Aktivitäten nicht starten bzw.

von ihnen aktuell bearbeitete Aktivitäten

nicht beenden, da der zugehörige WF-

Server nicht erreichbar ist. Diese, für den

Anwender sichtbaren Probleme können

durch dynamische Serveränderungen

nicht behoben werden.

Die Verwendung von Ansatz 4 führt

in Ausfallsituationen lediglich dazu, dass

für eine noch anstehende Migration einer

WF-Instanz ein anderer Zielserver ge-

wählt wird. Dies ist aber nur von sehr be-

schränktem Nutzen, weil aktuell keine

Anwender auf die Ausführung einer zu

dieser WF-Instanz gehörenden Aktion

warten (die entsprechende WF-Instanz

befindet sich nämlich in einer Migration,

also unmittelbar vor der Aktivierung der

nachfolgenden Aktivität). Die im vorheri-

gen Absatz beschriebenen, gravierenden

Probleme treten hier also ohnehin nicht

auf. Da außerdem anzunehmen ist, dass

eine ausgefallene Komponente zeitnah

repariert wird, resultiert aus der entste-

henden, nach außen kaum sichtbaren Ver-

zögerung kein Problem, das den für das

vorgestellte Verfahren erforderlichen

Aufwand rechtfertigen würde.

5.2 Fazit

Wie die vorgestellte Analyse ergeben hat,

ist die dynamische Änderung von Server-

zuordnungen ein wenig geeignetes Ver-

fahren, um den Ausfall von Komponen-

ten des WfMS zu kompensieren. Hierfür

sind Verfahren wie die Verwendung von

Backup-Servern (vgl. [KAGM96]) we-

sentlich besser geeignet. Auf entspre-

chende Ansätze wird, ebenso wie auf

Verfahren zur Behandlung der Überlas-

tungsproblematik, kurz in Abschnitt 6

eingegangen.

Wegen der mangelnden Tauglichkeit

dynamischer Serveränderungen erübrigt

es sich hier, die skizzierten Verfahren for-

maler vorzustellen oder mögliche Reali-

sierungsvarianten miteinander zu verglei-

chen (z.B. mögliche Alternativen bei der

Auswahl des Zielservers einer dynami-

schen Migration, d.h. bei der Beantwor-

tung der Fragestellung, wie eine dyna-

misch festgelegte Serverzuordnung kon-

kret aussieht). Aus demselben Grund

macht es ebenfalls wenig Sinn, auf Ver-

fahren zum (effizienten) Erkennen von

Komponentenausfällen näher einzuge-

hen. (Dasselbe gilt für Verfahren zur effi-

zienten Realisierung des Lastinforma-

tionsaustauschs und für Kriterien, ab

wann und wie lange auf eine Überlastung

reagiert werden sollte.) Schließlich erüb-

rigt es sich, die Leistungsfähigkeit der

entsprechenden Verfahren durch eine

Modellrechnung oder Simulation zu eva-

luieren, da ihre Mängel offensichtlich

sind.

6 Alternative Vorgehensweisen

Da sich dynamische Serveränderungen

als wenig geeignet erwiesen haben, um

die Überlastungs- und Ausfallproblema-

tik in (verteilten) WfMS zu lösen, wen-

den wir uns im Folgenden kurz einigen

alternativen Verfahren zu.

Die Fragestellung, wie sich Überlas-

tungen des Kommunikationssystems ver-

meiden lassen, ist schon immer ein zen-

traler Aspekt von ADEPTdistribution ge-

wesen. Dazu haben wir verschiedene Ver-

fahren entwickelt, mit denen die in einem

(verteilten) WfMS zu kommunizierende

Datenmenge erheblich reduziert werden

kann. Diese Verfahren können auch in

Kombination miteinander verwendet

werden.

Das erste Verfahren (vgl. [BD97]) un-

terstützt den WF-Modellierer bei der Be-

stimmung optimaler Serverzuordnungen

für WF-Aktivitäten. Ziel dabei ist die Mi-

nimierung der bei der späteren WF-Aus-

führung entstehenden Gesamtkommuni-

kationskosten. Um dies zu erreichen,

wurden von uns Algorithmen entwickelt,

die ausgehend von dem Prozess- und Or-

ganisationsmodell und unter Verwendung

eines Kostenmodells die bei der WF-Aus-

führung entstehenden Kommunikations-

kosten abschätzen. Unter Nutzung dieser

Information werden dann (möglichst) op-

timale Serverzuordnungen automatisch

berechnet.

Der zweite Ansatzpunkt betrifft vari-

able Serverzuordnungen (vgl. [BD00]),

bei deren Verwendung sich Datenübertra-

gungen immer dann einsparen lassen

(vgl. [BD99]), wenn die potenziellen Be-

arbeiter einer Aktivität von Vorgängerak-

tivitäten abhängen (z.B. eine Aktivität

soll vom selben Benutzer bearbeitet wer-

den wie eine bestimmte Vorgängeraktivi-

tät). In diesen Fällen werden flexible Ser-

verzuordnungen verwendet, bei denen

der tatsächlich ausgewählte WF-Server

ebenfalls von Vorgängeraktivitäten ab-

hängig ist, sich also erst zur Ausführungs-

zeit der WF-Instanz ergibt.

Drittens wurden von uns Verfahren

entwickelt, mit denen die bei Migrationen

zu übertragende Datenmenge deutlich re-

duziert werden kann (vgl. [BRD01b]). So

wird verhindert, dass Zustandsinformati-

on einer WF-Instanz oder Parameterdaten

von Aktivitätenprogrammen durch wie-

derholte Migrationen zum selben WF-

Server mehrfach (redundant) an diesen

übertragen werden (z.B. in Verbindung

mit Schleifen).

Sollten all diese Maßnahmen immer

noch nicht ausreichen, um eine Überlas-

tung des Kommunikationssystems zu

verhindern, müssen kleinere Teilnetze ge-

bildet werden. Da dann von jedem Teil-

netz eine kleinere Anzahl von Benutzern

bedient werden muss, kann dessen Über-

lastung verhindert werden.

Auch die Problematik einer Überlas-

tung von WF-Servern wurde im ADEPT-

Projekt betrachtet. In [Bau01] wird ein

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

Datenbank-Spektrum 4/2002 65

Verfahren vorgestellt, durch das eine sol-

che Überlastung ausgeschlossen werden

kann. Dieses ermöglicht die Verwendung

von beliebig vielen WF-Servern in dem-

selben Teilnetz (Domain). Außerdem

kann die zu bewältigende Last in einem

beliebigen (vorzugebenden) Verhältnis

auf diese Server verteilt werden. Da das

Verfahren während der Steuerung von

WF-Instanzen keine zusätzliche Kommu-

nikation generiert, trägt es auch nicht zur

Überlastung des Kommunikationssys-

tems bei.

Dem Ausfall von Komponenten des

Kommunikationssystems oder von WF-

Servern begegnet man am günstigsten

durch den redundanten Einsatz von Hard-

ware, falls eine sehr hohe Verfügbarkeit

gefordert ist. So werden in [KAGM96]

Verfahren vorgestellt, die den Einsatz ei-

nes Backup-Servers erlauben. Die zur

Steuerung der WF-Instanzen notwendige

Information wird dann auch an diesen

Backup-Server ständig übermittelt, so

dass er im Falle eines Serverausfalls die

Kontrolle übernehmen kann. Der Ausfall

von Komponenten des Kommunikations-

systems wird am besten durch redundante

Kommunikationshardware kompensiert

(z.B. durch eine doppelte Ringbildung

wie bei FDDI [Tane96]).

7 Diskussion

Verfahren, die auf der Verwendung von

Lastinformation basieren, werden beim

Scheduling von Betriebssystemprozessen

seit langem mit großem Erfolg eingesetzt

(vgl. [CK88, Gos91]). Bei diesen Verfah-

ren wird (meist aufgrund der aktuellen

Lastsituation) festgelegt, welchem Pro-

zessor ein bestimmter Betriebssystem-

prozess zugeteilt werden soll. Allerdings

wird der entsprechende Prozessor norma-

lerweise schon beim Start eines Betriebs-

systemprozesses bestimmt (non-pre-

emptive Scheduling [CK88]), so dass kein

laufender Prozess transferiert werden

muss. (Dies würde einer Migration ent-

sprechen.)

Zu beachten ist in diesem Zusammen-

hang, dass in Bezug auf unsere Fragestel-

lung die Betriebssystemprozesse nicht

den Prozessinstanzen des WfMS entspre-

chen. Eine WF-Instanz besteht aus Akti-

vitäteninstanzen, die den WF-Servern zu-

geordnet werden sollen, ebenso wie eine

Anwendung aus Betriebssystemprozes-

sen besteht, die den Prozessoren zugeteilt

werden. Betriebssystemprozesse entspre-

chen also den Aktivitäteninstanzen. Bei

der Zuordnung von Aktivitäteninstanzen

zu WF-Servern besteht der Vorteil, dass

nützliche Metainformation zu den Aktivi-

täten zur Verfügung steht (z.B. die Bear-

beiterzuordnung oder die Verteilung der

Benutzer auf die Teilnetze), was bei Be-

triebssystemprozessen normalerweise

nicht der Fall ist. Deshalb ist es beim

Scheduling von WF-Instanzen möglich,

einen bzgl. des resultierenden Kommuni-

kationsverhaltens sehr viel günstigeren

WF-Server auszuwählen, als dies durch

reine Lastbalancierung möglich wäre.

Die Nutzung solcher Informationen ent-

spricht der Verwendung von statischen

Schedulingverfahren (vgl. [CK88]) in

Betriebssystemen anstelle der dort übli-

chen dynamischen Verfahren.

Wir möchten an dieser Stelle auf eine

ausführliche Darstellung von Ansätzen

für verteiltes WF-Management verzich-

ten, da sich eine solche z.B. in [Bau01,

BD99] findet. Die meisten Ansätze legen,

ebenso wie ADEPTdistribution, die Zuord-

nung der Aktivitäteninstanzen zu den

WF-Servern auf Basis des Prozess- und

des Organisationsmodells fest. So wird in

MENTOR [MWW+98] und WIDE

[CGP+96] der WF-Server nahe bei den

potenziellen Bearbeitern der aktuellen

Aktivität allokiert. Dasselbe gilt für MO-

BILE [HS96], wobei allerdings eine WF-

Instanz während ihrer gesamten Lebens-

dauer vom selben WF-Server kontrolliert

wird. Deshalb sind keine Migrationen not-

wendig. Allerdings können bei diesem

Ansatz Subprozesse von einem anderen

WF-Server kontrolliert werden (vgl.

[SNS99]). Dieser wird zur Laufzeit auf-

grund verschiedener Kriterien (z.B. Rech-

te, Gewichte) ausgewählt. Bei METEOR2

[DKM+97], CodAlf [SM96] und BPA-

Frame [SM96] wird der WF-Server stets

nahe bei der zur aktuellen Aktivität gehö-

renden Anwendung gewählt. Schließlich

finden sich in der Literatur auch noch voll

verteilte Ansätzen (z.B. Exotica/FMQM

[AMG+95] und INCAS [BMR96]), bei

denen jeweils der Rechner des aktuellen

Benutzers die Serverfunktionalität über-

nimmt. All diese Ansätze führen das

Scheduling der Aktivitäteninstanzen aber

unabhängig von der aktuellen Last- und

Ausfallsituation durch.

Dass es in WfMS auch möglich ist,

das Scheduling unabhängig von den Pro-

zess- und Organisationsmodellen zu rea-

lisieren, zeigt der Exotica/Cluster-Ansatz

(vgl. [AKA+94]). Bei diesem wird der

WF-Server (Cluster)1 für eine WF-In-

stanz bei deren Start zufällig ausgewählt.

In diesem Cluster verbleibt sie für ihre

gesamte Lebenszeit, es werden also keine

bereits gestarteten WF-Instanzen zu ei-

nem anderen Cluster migriert. Allerdings

verwendet auch dieser Ansatz für die

Auswahl des WF-Servers keine Lastin-

formation. (Er kann aber leicht dahinge-

hend modifiziert werden.) Außerdem

wurde in [Bau01, BD99] gezeigt, dass

sich wegen der fehlenden Nutzung von

Modellinformation bei diesem Ansatz ein

sehr ungünstiges Kommunikationsver-

halten ergibt.

In der WF-Literatur werden auch

CORBA-basierte Ansätze für verteiltes

WF-Management vorgestellt: WASA2

[Wes99] etwa realisiert eine verteilte WF-

Ausführung, indem die Aktivitäten als

CORBA-Objekte betrachtet werden, die

sich Zustandsänderungen signalisieren.

Da diese Objekte auf beliebigen Rechnern

platziert werden können, lässt sich so ein

verteiltes Workflow-Management reali-

sieren. Im MOKASSIN-Projekt wird die

Verteilung (vgl. [JH99]) ähnlich wie beim

vorherigen Ansatz realisiert: Die Aktivi-

täteninstanzen repräsentieren CORBA-

Objekte, die durch Ereignisse miteinander

kommunizieren und die auf beliebigen

Rechnern platziert werden können. Bei

diesen Ansätzen kann durch die CORBA-

Middleware prinzipiell jede beliebige

Verteilung realisiert werden. Dabei wäre

es auch möglich, dass die Verteilung so

vorgenommen wird, dass Last- und Aus-

fallinformation berücksichtigt wird. Al-

lerdings würden bei einer solchen Vor-

gehensweise die in dieser Arbeit disku-

tierten Schwierigkeiten auftreten.

8 Zusammenfassung

In diesem Beitrag haben wir untersucht,

inwieweit durch eine dynamische Verän-

derung von Serverzuordnungen auf Über-

lastsituationen und Komponentenausfälle

1. Genau genommen besteht bei dem in

[AKA+94] beschriebenen Ansatz ein Cluster

aus mehreren WF-Servern mit gemeinsamer

WF-Datenbank. Diese Server sind alle fähig,

die WF-Instanzen des Clusters zu steuern. Da

zwischen diesen Rechnern aber keine Migra-

tionen (in unserem Sinne) stattfinden, wollen

wir sie als einen einzigen WF-Server betrach-

ten.

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

66 Datenbank-Spektrum 4/2002

in einem verteilten WfMS reagiert wer-

den kann. Dabei hat sich gezeigt, dass die

Verfahren bei Überlastungen wenig ge-

eignet sind, da sie für Teilnetze und Gate-

ways häufig fast gar keine Entlastung er-

möglichen. Der für das jeweilige

Verfahren notwendige Zusatzaufwand

kann sogar dazu führen, dass sich die Ge-

samtsituation noch verschlechtert. Ledig-

lich eine Entlastung von WF-Servern ist –

allerdings sehr eingeschränkt – möglich.

Auch zur Kompensation von Ausfällen

einzelner WfMS-Komponenten sind dy-

namische Serveränderungen wenig ge-

eignet. Diejenigen Auswirkungen der

Ausfälle, die für den Endanwender wirk-

lich kritisch sind, können durch ihre Ver-

wendung nämlich nicht vermindert wer-

den, weil der Ausfall der Komponente die

Durchführung der dynamischen Migrati-

on verhindert. Insgesamt betrachtet ist

deshalb die Verwendung von dynami-

schen Serveränderungen nicht zu emp-

fehlen.

In diesem Beitrag wurden auch noch

Alternativen zu dynamischen Serverän-

derungen skizziert. Allerdings war es da-

bei nicht das Ziel, diese im Detail zu be-

handeln (dies erfolgte in anderen Publi-

kationen), sondern es sollten nur mögli-

che Alternativen zur Verwendung von

dynamischen Serveränderungen aufge-

zeigt werden. Mit diesen Verfahren ist es

möglich, sowohl Überlastsituationen von

Netzwerkkomponenten und WF-Servern

als auch Ausfällen dieser WfMS-Kompo-

nenten geeignet zu begegnen.

Zusammenfassend lässt sich also fest-

stellen, dass dynamische Migrationen

wenig geeignet sind, um die gegebenen

Problemstellungen zu lösen. Da es Alter-

nativen zu diesem Ansatz gibt, mit denen

die gewünschten Ziele durchaus erreicht

werden können, besteht auch keine Not-

wendigkeit, diese Verfahren einzusetzen.

Danksagung: Wir danken den anonymen Gutach-

tern für ihre hilfreichen Anregungen.

Literatur

[AH02]] van der Aalst, W. M. P.; van Hee, K.:

Workflow Management. MIT Press, 2002.

[AKA+94] Alonso, G.; Kamath, M.; Agrawal,

D.; El Abbadi, A.; Günthör, R.; Mohan, C.:

Failure Handling in Large Scale Workflow

Management Systems. Technischer Bericht

RJ9913, IBM Almaden Research Center, No-

vember 1994.

[AMG+95] Alonso, G.; Mohan, C.; Günthör, R.;

Agrawal, D.; El Abbadi, A.; Kamath, M.:

Exotica/FMQM: A Persistent Message-

Based Architecture for Distributed Workflow

Management. In: Proc. IFIP Working Conf.

on Information Systems for Decentralized

Organisations, Trondheim, August 1995.

[Bau01] Bauer, T.: Effiziente Realisierung unter-

nehmensweiter Workflow-Management-Sys-

teme. Dissertation, Universität Ulm, Fakultät

für Informatik, Februar 2001 (erschienen

beim Tenea-Verlag Berlin).

[BD97] Bauer, T.; Dadam, P.: A Distributed Exe-

cution Environment for Large-Scale Work-

flow Management Systems with Subnets and

Server Migration. In: Proc. 2nd Conf. on Co-

operative Information Systems, S. 99–108,

Kiawah Island, SC, Juni 1997.

[BD99] Bauer, T.; Dadam, P.: Verteilungsmodel-

le für Workflow-Management-Systeme –

Klassifikation und Simulation. Informatik

Forschung und Entwicklung, 14(4):203–217,

Dezember 1999.

[BD00] Bauer, T.; Dadam, P.: Efficient Distribut-

ed Workflow Management Based on Variable

Server Assignments. In: Proc. 12th Conf. on

Advanced Information Systems Engineering,

S. 94–109, Stockholm, Juni 2000.

[BMR96] Barbará, D.; Mehrotra, S.; Rusinkie-

wicz, M.: INCAs: Managing Dynamic Work-

flows in Distributed Environments. Journal of

Database Management, Special Issue on Mul-

tidatabases, 7(1):5–15, 1996.

[BRD01a] Bauer, T.; Reichert, M.; Dadam, P.:

Adaptives und verteiltes Workflow-Manage-

ment. In: Proc. Datenbanksysteme in Büro,

Technik und Wissenschaft, S. 47–66, Olden-

burg, März 2001.

[BRD01b] Bauer, T.; Reichert, M.; Dadam, P.:

Effiziente Übertragung von Prozessinstanz-

daten in verteilten Workflow-Management-

Systemen. Informatik Forschung und Ent-

wicklung, 16(2):76–92, Juni 2001.

[CGP+96] Casati, F.; Grefen, P.; Pernici, B.;

Pozzi, G.; Sánchez, G.: WIDE: Workflow

Model and Architecture. CTIT Technical Re-

port 96-19, University of Twente, 1996.

[CK88] Casavant, T. L.; Kuhl, J. G.: A Taxono-

my of Scheduling in General-Purpose Distri-

buted Computing Systems. IEEE ToSE,

14(2):141–154, Februar 1988.

[DKM+97] Das, S.; Kochut, K.; Miller, J.; Sheth,

A.; Worah, D.: ORBWork: A Reliable Distri-

buted CORBA-based Workflow Enactment

System for METEOR2. Technical Report

#UGACS-TR-97-001, Dept. of Comp. Sci-

ence, University of Georgia, Februar 1997.

[DR99] Dadam, P.; Reichert, M.: Proc. Work-

shop on Enterprise-Wide and Cross-Enterpri-

se Workflow-Management – Concepts, Sys-

tems, Applications. 29. Jahrestagung der

GI (Informatik’99), Paderborn, Oktober

1999.

[DRK00] Dadam, P.; Reichert, M.; Kuhn, K.:

Clinical Workflows – The Killer Application

for Process-oriented Information Systems?

In: Proc. 4th Int. Conf. on Business Informa-

tion Systems, S. 36–59, Posen, April 2000.

[Gos91] Goscinski, A.: Distributed Operating

Systems: The Logical Design. Addison-Wes-

ley, 1991.

[HS96] Heinl, P.; Schuster, H.: Towards a Highly

Scaleable Architecture for Workflow Ma-

nagement Systems. In: Proc. 7th Int. Work-

shop on Database and Expert Systems Ap-

plications, S. 439–444, Zürich, September

1996.

[JBS97] Jablonski, S.; Böhm, M.; Schulze, W.:

Workflow-Management: Entwicklung von

Anwendungen und Systemen; Facetten einer

neuen Technologie. dpunkt.verlag, 1997.

[JH99] Joeris, G.; Herzog, O.: Towards Flexible

and High-Level Modeling and Enacting of

Processes. In: Proc. 11th Int. Conf. on Advan-

ced Information Systems Engineering, S. 88–

102, Heidelberg, Juni 1999.

[KAGM96] Kamath, M.; Alonso, G.; Günthör,

R.; Mohan, C.: Providing High Availability in

Very Large Workflow Management Systems.

In: Proc. 5th Int. Conf. on Extending Databa-

se Technology, S. 427–442, Avignon, März

1996.

[LR00] Leymann, F.; Roller, D.: Production

Workflow – Concepts and Techniques. Pren-

tice Hall, 2000.

[Mar01] Martschat, U.: Vergleich und Bewer-

tung von Production-Workflow-Manage-

ment-Systemen. Diplomarbeit, Universität

Ulm, Fakultät für Informatik, 2001.

[MWW+98] Muth, P.; Wodtke, D.; Weißenfels,

J.; Kotz-Dittrich, A.; Weikum, G.: From Cen-

tralized Workflow Specification to Distribut-

ed Workflow Execution. Journal of Intelligent

Information Systems, Special Issue on Work-

flow Management Systems, 10(2):159–184,

März/April 1998.

[Obe96] Oberweis, A.: Modellierung und Aus-

führung von Workflows mit Petri-Netzen.

Teubner-Verlag, 1996.

[OMG95] OMG: The Common Object Request

Broker: Architecture and Specification. Tech-

nischer Bericht Revision 2.0, Object Manage-

ment Group, Juli 1995.

[RBFD01] Reichert, M.; Bauer, T.; Fries, T.; Da-

dam, P.: Realisierung flexibler, unterneh-

mensweiter Workflow-Anwendungen mit

ADEPT. In: Proc. Conf. Elektronische Ge-

schäftsprozesse, S. 217–228, Klagenfurt,

September 2001.

[RD98] Reichert, M.; Dadam, P.: ADEPTflex –

Supporting Dynamic Changes of Workflows

Without Losing Control. Journal of Intelli-

gent Information Systems, Special Issue on

Workflow Management Systems, 10(2):93–

129, März/April 1998.

[SK97] Sheth, A.; Kochut, K. J.: Workflow Ap-

plications to Research Agenda: Scalable and

Dynamic Work Coordination and Collabora-

tion Systems. In: Proc. NATO Advanced Stu-

dy Institute on Workflow Management Sys-

Dynamische Änderung von Serverzuordnungen in verteilten Workflow-Management-Systemen

Datenbank-Spektrum 4/2002 67

tems and Interoperability, S. 12–21, Istanbul,

August 1997.

[SM96] Schill, A.; Mittasch, C.: Workflow Ma-

nagement Systems on Top of OSF DCE and

OMG CORBA. Distributed Systems Engi-

neering, 3(4):250–262, Dezember 1996.

[SNS99] Schuster, H.; Neeb, J.; Schamburger, R.:

A Configuration Management Approach for

Large Workflow Management Systems. In:

Proc. Int. Joint Conf. on Work Activities Co-

ordination and Collaboration, S. 177–186,

San Francisco, Februar 1999.

[Tan96] Tanenbaum, A. S.: Computer Networks.

Prentice Hall, 1996.

[Wes99] Weske. M.: Workflow Management

Through Distributed and Persistent CORBA

Workflow Objects. In: Proc. 11th Int. Conf.

on Advanced Information Systems Enginee-

ring, Heidelberg, 1999.

[WW97] Wodtke, D.; Weikum, G.: A Formal

Foundation for Distributed Workflow Execu-

tion Based on State Charts. Proc. Int. Conf. on

Database Theory. Delphi, Januar 1997.

[WWW96+] Wodtke, D.; Weißenfels, J.; Weikum,

G.; Kotz-Dittrich, A.: The Mentor Project –

Steps Towards Enterprise-Wide Workflow

Management. Proc. 12th Int’l Conf. on Data

Engineering, S. 556-565, New Orleans, März

1996.

Dr. Thomas Bauer studierte Informatik in Ulm,

wo er 2001 auch promovierte. Der Titel seiner

Dissertation lautet »Effiziente Realisierung un-

ternehmensweiter Workflow-Management-Sys-

teme«. Seit Januar 2002 arbeitet Dr. Bauer im

DaimlerChrysler Forschungszentrum in Ulm im

Bereich Engineering Process Management.

Dr. Thomas Bauer

DaimlerChrysler Forschung

und Technologie

Abteilung RIC/ED

Postfach 2360

89013 Ulm

Thomas.TB.Bauer@DaimlerChrysler.com

http://www.daimlerchrysler.com

Dr. Manfred Reichert ist wissenschaftlicher As-

sistent in der Abteilung Datenbanken und Infor-

mationssysteme der Universität Ulm. Hier pro-

movierte er im Juli 2000 zum Thema

»Dynamische Ablaufänderungen in Workflow-

Management-Systemen«. Aktuelle Arbeitsgebie-

te sind unternehmensweite und -übergreifende

WF-Anwendungen sowie verschiedene Aspekte

von Workflow-Management-Systemen.

Dr. Manfred Reichert

Universität Ulm

Fakultät für Informatik

Abt. Datenbanken und Informationssysteme

James-Franck-Ring

89069 Ulm

reichert@informatik.uni-ulm.de

http://www.informatik.uni-ulm.de/dbis/