Effiziente Durchf¨
uhrung von Prozessmigrationen
in verteilten Workflow-Management-Systemen
Thomas Bauer, Manfred Reichert, Peter Dadam
Universit¨at Ulm, Abteilung Datenbanken und Informationssysteme
bauer, reichert, dadam
@informatik.uni-ulm.de,http://www.informatik.uni-ulm.de/dbis
Zur Unterst¨
utzung von unternehmensweiten und -¨
ubergreifenden Gesch¨
aftsprozessen muss ein Workflow-
Management-System (WfMS) eine große Anzahl von Workflows (WF) steuern k¨
onnen. Dadurch resultiert eine
hohe Last f¨
ur die WF-Server und das zugrunde liegende Kommunikationssystem. Ein verbreiteter Ansatz zur
Bew¨
altigung der Last ist es, die WF-Instanzen verteilt durch mehrere WF-Server zu kontrollieren. Beim Wechsel
der Kontrolle zwischen zwei WF-Servern werden dann Migrationen notwendig, bei denen Daten der jeweiligen
WF-Instanz vom Quell- zum Zielserver ¨
ubertragen werden m¨
ussen, um dort mit der Steuerung fortfahren zu
k¨
onnen. Deshalb belasten Migrationen das Kommunikationssystem zus¨
atzlich. In diesem Beitrag werden Ver-
fahren entwickelt, mit denen die bei Migrationen entstehende Kommunikationslast reduziert werden kann, so
dass die Skalierbarkeit des WfMS signifikant verbessert wird. Falls Gesch¨
aftsbereiche nur ¨
uber langsame Kom-
munikationsverbindungenangebunden sind, wird dadurch der Einsatz eines WfMS ¨
uberhaupt erst erm¨
oglicht.
1 Einleitung
WfMS erm¨oglichen die rechnerunterst¨utzte Ausf¨uhrung von Arbeitsabl¨aufen (engl. Workflows) in ei-
ner verteilten Systemumgebung [LR00]. Ein entscheidender Vorteil des Einsatzes von WfMS ist, dass
sie helfen, große Anwendungssysteme ¨uberschaubarer zu gestalten. Dazu wird der applikationsspe-
zifische Code der Anwendungen, die zur Ausf¨uhrung einzelner Prozessschritte verwendet werden,
von der Definition und Steuerung der Ablauflogik des Gesch¨aftsprozesses getrennt. Anstelle eines
großen monolithischen Programmpakets erh¨alt man einzelne Aktivit¨aten, welche die Anwendungs-
programme repr¨asentieren. Ihre Ablauflogik wird in einer separaten Kontrollflussdefinition festge-
legt, welche die Ausf¨uhrungsreihenfolgen und -bedingungen der einzelnen Aktivit¨aten vorgibt. Zur
Ausf¨uhrungszeit sorgt das WfMS daf¨ur, dass diese Aktivit¨aten entsprechend der festgelegten Ablauf-
logik zur Bearbeitung kommen.
Bei unternehmensweiten und -¨ubergreifenden prozessorientierten Anwendungssystemen entsteht we-
gen der großen Benutzerzahl eine hohe Last f¨ur das WfMS.1Um diese bew¨altigen zu k¨onnen, erfolgt
bei vielen Ans¨atzen (z.B. [AKA
94, CGP
96, DKM
97, Jab97, MWW
98, SM96]) eine Aufteilung
auf mehrere WF-Server. Dabei kann eine WF-Instanz oftmals (abschnittsweise) von verschiedenen
WF-Servern gesteuert werden, d.h., die Kontrolle ¨uber eine WF-Instanz wechselt zur Ausf¨uhrungszeit
zwischen den Servern. Ein solcher Wechsel erfordert eine sog. Migration, bei der die Daten der WF-
Instanz an den Zielserver ¨ubertragen werden, bevor dort mit der Kontrolle fortgefahren wird. Dadurch
1In [KAGM96, SK97] werden Anwendungen beschrieben, bei denen die Zahl der Benutzer des WfMS bis auf einige
zehntausend anwachsen kann oder mehrere zehntausend WF-Instanzen gleichzeitig im System sein k¨onnen.
kann bei verteilter WF-Steuerung dasselbe logische Verhalten wie im zentralen Fall erreicht wer-
den, obwohl mehrere WF-Server nacheinander oder gleichzeitig an der Ausf¨uhrung einer WF-Instanz
beteiligt sind. Bei den meisten der in der Literatur diskutierten Ans¨atze werden bei einer solchen Mi-
gration alle Laufzeitdaten der WF-Instanz zum Zielserver transferiert. Dies f¨uhrt im Allgemeinen aber
zu einer redundanten ¨
Ubertragung von Daten. So kann der Zielserver einer Migration bereits fr¨uher
einmal an der entsprechenden WF-Instanz beteiligt gewesen sein, so dass ihm gewisse Instanzdaten
schon bekannt sind. In diesem Fall ist es unn¨otig, bereits vorhandene Daten nochmals zu ¨ubertragen.
In diesem Beitrag werden zur Ausf¨uhrungszeit der WF-Instanzen zur Anwendung kommende Ver-
fahren vorgestellt, die solche und ¨ahnliche F¨alle ausschließen, wodurch das Kommunikationsaufkom-
men bei Migrationen reduziert wird. Die Ausnutzung des existierenden Optimierungspotentials ist
insbesondere f¨ur unternehmensweite und -¨ubergreifende Anwendungen unverzichtbar, da bei den ent-
sprechenden Systemen die Kommunikation h¨aufig (zumindest teilweise) ¨uber ein WAN (Wide Area
Network) oder eine sonstige langsame Verbindung (Internet, ISDN) abgewickelt wird. Dennoch gibt
es unseres Wissens bisher keine Arbeiten, die systematisch untersuchen, wie Migrationen effizient
realisiert werden k¨onnen.
Die Verbesserung der Skalierbarkeit von WfMS ist aber nur eine von vielen Anforderungen, die
sich im unternehmensweiten Einsatz stellen. Um WfMS f¨ur ein breites Spektrum von Anwendun-
gen einsetzbar zu machen, m¨ussen auch Konzepte, wie die dynamische Ab¨anderbarkeit laufender
WF-Instanzen (z.B. das Einf¨ugen von Aktivit¨aten) [KDB98, RD98], die Spezifikation und ¨
Uberwa-
chung von Zeitbedingungen (z.B. zeitliche Minimal- und Maximalabst¨ande zwischen Aktivit¨aten)
[MO99, Gri97], das (partielle) Zur¨ucksetzen von WF-Instanzen [Ley97, RD98] oder die Verwendung
komplexer (abh¨angiger) Bearbeiterzuordnungen [BF99, Kub98] unterst¨utzt werden. Deshalb darf man
die verteilte WF-Steuerung nicht isoliert von solchen Anforderungen betrachten. Bei der Entwicklung
der in dieser Arbeit vorgestellten Verfahren wird darauf geachtet, dass diese mit fortschrittlichen WF-
Konzepten vereinbar sind.
Im nachfolgenden Abschnitt werden grundlegende Aspekte der zentralen und verteilten WF-Ausf¨uh-
rung er¨ortert. Außerdem werden die Problemstellungen untersucht, die sich im Zusammenhang mit
der effizienten Realisierung von Migrationen ergeben. Im Abschnitt 3 werden m¨ogliche Vorgehens-
weisen zur Migration von WF-Kontrolldaten (z.B. Information zum Status einer WF-Instanz) vorge-
stellt und ein geeignetes Verfahren n¨aher untersucht. Dabei m¨ogliche weitergehende Optimierungen
werden im Abschnitt 4 diskutiert. Die Migration von durch WF-Aktivit¨aten gelesenen bzw. geschrie-
benen Parameterdaten wird in Abschnitt 5 betrachtet. Abschnitt 6 diskutiert verwandte Ans¨atze. Der
Beitrag schließt mit einer Zusammenfassung.
2 Grundlagen und Problemstellung
In diesem Abschnitt fassen wir kurz einige f¨ur das weitere Verst¨andnis des Beitrags relevante Grund-
lagen zusammen. So werden das im Folgenden verwendete WF-Metamodell und die verteilte WF-
Ausf¨uhrung vorgestellt. Danach untersuchen wir detailliert die im Zusammenhang mit der effizienten
Verwirklichung von Migrationen zu l¨osenden Problemstellungen.
2.1 Das Workflow-Metamodell
Um einen Arbeitsprozess zu spezifizieren, wird in einem WfMS ¨ublicherweise eine WF-Vorlage mo-
delliert (oberer Teil von Abb. 1). Eine solche Vorlage legt die Ausf¨uhrungsreihenfolge und -bedin-
2
gungen (Kontrollfluss) der einzelnen Prozessschritte (Aktivit¨
aten) fest. Bei vielen WfMS kann dar¨uber
hinaus auch der Datenfluss zwischen den Aktivit¨aten definiert werden. Aus Abb. 1 zum Beispiel ist
ersichtlich, welche Aktivit¨aten die Prozessvariable
lesen bzw. schreiben. F¨ur einzelne Aktivit¨aten
wird festgelegt, ob sie automatisch gestartet oder manuell bearbeitet werden sollen. F¨ur manuelle Ak-
tivit¨aten muss zur Modellierungszeit zus¨atzlich eine Bearbeiterzuordnung angegeben werden, welche
die zur Bearbeitung der Aktivit¨at berechtigten Benutzer festlegt. Eine solche Bearbeiterzuordnung
spezifiziert ¨ublicherweise die Rolle, die potentielle Bearbeiter einnehmen, oder die Organisationsein-
heit, der sieangeh¨oren sollen. Es sind aberauch komplexere Ausdr¨ucke m¨oglich. Ausgehend von einer
solchen WF-Vorlage k¨onnen zur Ausf¨uhrungszeit WF-Instanzen erzeugt werden, die dann ¨uber ihre
komplette Lebenszeit vom WfMS gesteuert werden. Wenn eine manuelle Aktivit¨at zur Bearbeitung
ansteht, so wird sie in die Arbeitslisten der entsprechenden Benutzer eingetragen. Nachdem einer von
ihnen die Aktivit¨at zur Bearbeitung ausgew¨ahlt hat, wird das zugeh¨orige Aktivit¨
atenprogramm gestar-
tet, so dass er die Aktivit¨at bearbeiten kann. Nach dessen Beendigung schaltet das WfMS zur n¨achsten
Aktivit¨at weiter, die dann bearbeitet werden kann.
!"# # $&%
'( ) *,+*.-0/213( 4 567 7 8&9
:<; =,> ?0@A B,@CEDF@3GC BH
IKJ
@MLONQP
J R.J
P S.PTG
UWVXEYQZ[\V]^X_`a b
cedf2gMhikj lFmno
cedfp qr3s2lqTtnqo uwvyx{z |}3~E~
{ y&
{ & M
{M OMK
{¢¡£F¤F¥F§¦¨¡y©
Kª§¡£F¤¥F§¦¨¡©
«¬ ® ¯
°±F² ³´3µ§¶F· ¸3¹ º»¢· ¼½ ¾F¿ ÀÁ ¿  ÀÄÃ3ÅMÆÇ ÆÁ2Ã0ÈTÉEÊ ËÍÌQÎEÏ ÐkÑ Ò Ò Ò Ó2Ô
ÕÖ,×Ø Ù
Ô0ÚTÛEÜ ÝEÜ3ÞßÝ.à á¢â ã ã ã ä åFæ çè æ é çÄê.ë{ì3í í îè2ê0ï.ðñ ò óô õ§ö ÷ ÷ ÷ ø
Abbildung 1 Modellierung von WF-Vorlagen und Ausf¨uhrung von WF-Instanzen.
Um in diesem Beitrag konkrete Algorithmen f¨ur Migrationen angeben zu k¨onnen, wird ein formales
WF-Metamodell ben¨otigt. Wir verwenden das Metamodell [RD98] von ADEPT2[DKR
95, RD98],
die gewonnenen Erkenntnisse sind aber auch auf andere WF-Modelle ¨ubertragbar. Bei ADEPT k¨onnen
zur Spezifikation des Kontrollflusses u.a. die KonstrukteSequenz, bedingte und parallele Verzweigung
und Schleife verwendet werden. Zur Festlegung des Datenflusses wird angegeben, welche prozessglo-
balen Variablen (Datenelemente) von welchen Aktivit¨aten gelesen bzw. geschrieben werden. Wie in
Abb. 1 dargestellt, k¨onnen Bearbeiterzuordnungen nicht nur Rollen referenzieren (z.B. Aktivit¨at
ù
),
sondern es werden auch die in der Praxis h¨aufig ben¨otigten abh¨
angigen Bearbeiterzuordnungen un-
terst¨utzt.
Im unteren Teil von Abb. 1 sind zur Ausf¨uhrungszeit erzeugte WF-Instanzen dargestellt. Damit der
WF-Server die f¨ur eine bestimmte WF-Instanz aktuell zur Ausf¨uhrung anstehenden Aktivit¨atenin-
stanzen ermitteln kann, ben¨otigt er entsprechende Zustandsinformation. In ADEPT werden dazu den
Knoten und Kanten des Ausf¨uhrungsgraphen einer WF-Instanz sog. Zustandsmarkierungen zugeord-
net. F¨ur ihre Festlegung bzw. Ver¨anderung (und die damit zusammenh¨angende Aktivierung von Ak-
tivit¨aten) gibt es wohldefinierte Regeln. Der Zustand einer Aktivit¨at ist initial NOT ACTIVATED.
Er geht, wenn alle Vorbedingungen (Signalisierung der eingehenden Kanten) erf¨ullt sind, in AC-
TIVATED ¨uber, was bedeutet, dass die Aktivit¨at gestartet werden kann. Bei manuell ausgef¨uhrten
Aktivit¨aten ermittelt der WF-Server (mit Hilfe des Organisationsmodells) dann die potentiellen Bear-
beiter und erzeugt die entsprechenden Arbeitslisteneintr¨age. Wenn die Aktivit¨at von einem Benutzer
ausgew¨ahlt wurde, wird sie aus den entsprechenden Arbeitslisten der anderen potentiellen Bearbeiter
2ADEPT steht f¨ur Application Development Based on Encapsulated Pre-Modeled Process Templates.
3
wieder entfernt. Nachdem die Datenelemente f¨ur die Versorgung der Eingabeparameter des Akti-
vit¨atenprogramms an den entsprechenden WF-Client ¨ubertragen wurden, kann dieses gestartet wer-
den (Zustand RUNNING). Nach dessen Beendigung werden die Ausgabeparameter zum WF-Server
transportiert und in entsprechenden Datenelementen persistent gespeichert. Dann geht der Zustand
der Aktivit¨at in TERMINATED ¨uber, woraufhin die ausgehenden Kanten signalisiert werden. Dies
wiederum f¨uhrt zur Berechnung der Zustandsmarkierung der Nachfolgeraktivit¨aten.
F¨ur die Unterst¨utzung fortschrittlicher WF-Konzepte, wie dynamische ¨
Anderungen, ¨
Uberwachung
von Zeitbedingungen und Realisierung abh¨angiger Bearbeiterzuordnungen, reicht die Zustandsin-
formation der Knoten und Kanten alleine noch nicht aus. Hier wird zus¨atzlich eine Ablaufhistorie
ben¨otigt, in welcher beim Starten und Beenden einer Aktivit¨ateninstanz ein entsprechender Eintrag
erzeugt wird. Wie in Abb. 1 (vereinfacht) dargestellt, enthalten solche Eintr¨age Information zum
tats¨achlichen Bearbeiter und zum Start- bzw. Endezeitpunkt der Aktivit¨at. Auf Basis dieser Ablaufhi-
storie ist es dann z.B. m¨oglich, abh¨angige Bearbeiterzuordnungen auszuwerten oder Zeitpl¨ane f¨ur die
Ausf¨uhrung der WF-Instanz zu erstellen, da aus ihr die Bearbeiter und die Start- und Endezeiten der
Aktivit¨aten hervorgehen.
2.2 Verteilte Workflow-Ausf¨uhrung
Wie bei zahlreichen Ans¨atzen (siehe [BD99b]) besteht bei ADEPT
úÄûü,ýÿþû
ýÿû
, der verteilten Variante
des ADEPT-WfMS,die M¨oglichkeit, eine WF-Instanz nicht nur durch einen einzigen WF-Server kon-
trollieren zu lassen, sondern ihre Ausf¨uhrung verteilt durch mehrere Server zu steuern [BD97]. Dazu
wird die zugeh¨orige WF-Vorlage bei der Modellierung in Partitionen unterteilt, die zur Ausf¨uhrungs-
zeit von unterschiedlichen Servern kontrolliert werden k¨onnen (vgl. Abb. 2). Wird bei der Ausf¨uhrung
einer Instanz dieses WF-Typs eine Aktivit¨at beendet und geh¨ort ihr Nachfolger einer anderen Parti-
tion an, so migriert die Kontrolle ¨uber diesen WF vom Server der aktuellen Partition (Quellserver
der Migration) zum Server der Nachfolgerpartition (Zielserver). Dabei muss eine Beschreibung des
Zustands der WF-Instanz zum Zielserver transportiert werden, um dort mit der Kontrolle fortfahren
zu k¨onnen. Da eine Migration die ¨
Ubertragung der vom Quellserver verwalteten WF-Kontrolldaten,
WF-relevanten Daten und Anwendungsdaten (vgl. [WMC99]) der WF-Instanz erfordert, verursacht
sie aber Kommunikationskosten. Um hier keinen unn¨otigen Aufwand zu generieren, kommunizieren
WF-Server in ADEPT ausschließlich bei Migrationen, d.h., Partitionen parallel ausgef¨uhrter Akti-
vit¨aten (z.B. Partition 2 und 4 in Abb. 2) werden von den entsprechenden WF-Servern unabh¨angig
voneinander kontrolliert. Bei der Aktivit¨atenausf¨uhrung findet dementsprechend keine Synchronisa-
tion oder Kommunikation zwischen diesen WF-Servern statt, weshalb einem Server der Zustand von
parallel ausgef¨uhrten Aktivit¨aten i.d.R. nicht bekannt ist. So weiß der WF-Server der Partition 4 zum
Beispiel nicht, ob die parallel ausgef¨uhrte Aktivit¨at
schon beendet worden ist oder nicht. Die ver-
schiedenen an einer WF-Instanz beteiligten WF-Server verf¨ugen also ¨uber (teilweise) unterschiedliche
Zustandsinformation und dementsprechend ¨uber unterschiedliche Ablaufhistorien.
Eine Partitionierung des WF-Graphen und die dadurch notwendig werdenden Migrationen zur
Ausf¨uhrungszeit werden auch von einigen anderen in der Literatur diskutierten Ans¨atzen unterst¨utzt
(z.B. [MWW
98, CGP
96]). ADEPT verfolgt zus¨atzlich das Ziel, die Kommunikationskosten eines
derart verteilten Ansatzes zu minimieren. Unsere Erfahrungen mit existierenden WfMS, Modellrech-
nungen und Simulationen [BD97, BD98, BD99b, BD00] haben gezeigt, dass zwischen einem WF-
Server und seinen Klienten zahlreiche Nachrichten und große Datenmengen ausgetauscht werden.
Mit steigender Anzahl von Benutzern und WF-Instanzen kann dies dazu f¨uhren, dass das Kommuni-
kationssystem ¨uberlastet wird. Aus diesem Grund wird in ADEPT der WF-Server f¨ur jede Aktivit¨at
4
!"!
!"! #%$
&' (% *)
+-,. )/ 0%/12%#3465
&879 :
;*<>= ?
@6ACB D
EGFHIFHJ EKFHIFHL
EGFHIFHKM
EGFHIFHON EKFHIFH#N
EKFHIFHP
Q R
S T
U V
W
XGYZ[YZK\
]_^
Z`a `a bcd
e6fg h
i_jklm lm no*p
qsr t u
vwxyz yz {|}
~_ 8
s
O%
O .
Abbildung 2 Partitionierung eines WF-Graphen und verteilte WF-Ausf¨uhrung.
so gew¨ahlt, dass die zu ¨ubertragende Gesamtdatenmenge minimiert wird. Dazu wird – vereinfacht
ausgedr¨uckt – der WF-Server einer Aktivit¨at so festgelegt, dass er in dem Teilnetz liegt, dem die
Mehrzahl ihrer potentiellen Bearbeiter angeh¨ort. Dadurch gelingt es uns weitgehend, teilnetz¨uber-
greifende Kommunikation zwischen einem WF-Server und seinen Klienten zu vermeiden. Außerdem
werden die Antwortzeiten verbessert und die Verf¨ugbarkeit erh¨oht, da bei der Ausf¨uhrung von Akti-
vit¨aten kein Gateway oder WAN ben¨otigt wird (f¨ur Details und die zugeh¨origen Algorithmen siehe
[BD97]).
Die Zuordnung von WF-Servern zu Aktivit¨aten (bzw. Partitionen) ist in ADEPT
úÄûü,ýÿþû
ýÿû
sowohl
statisch als auch dynamisch m¨oglich, abh¨angig von den f¨ur die einzelnen Schritte definierten Be-
arbeiterzuordnungen. Werden die Bearbeiter einer Aktivit¨at direkt durch ihre Rolle und Organisa-
tionseinheit festgelegt, so werden statische Serverzuordnungen verwendet. F¨ur viele Anwendungen
werden zus¨atzlich abh¨angige Bearbeiterzuordnungen ben¨otigt (z.B. selber Bearbeiter wie Aktivit¨at
). Da der entsprechende Bearbeiter erst im Verlauf der WF-Ausf¨uhrung feststeht, ist es in solchen
F¨allen vorteilhaft, den WF-Server dieser Aktivit¨ateninstanz erst zur Ausf¨uhrungszeit festzulegen. F¨ur
diesen Fall ist es m¨oglich, den WF-Server so auszuw¨ahlen, dass er sich in der Organisationseinheit
der entsprechenden Bearbeiter befindet. Zu diesem Zweck wurde f¨ur ADEPT
úÄûü,ýÿþû
ýÿû
das Kon-
zept der variablen Serverzuordnungen [BD99a, BD00] entwickelt, bei denen der tats¨achliche Server
einer Aktivit¨ateninstanz erst nach Beendigung der Vorg¨angeraktivit¨aten festgelegt wird. Auch bei
einigen anderen Ans¨atzen kann ein WF-Server dynamisch zur Ausf¨uhrungszeit festgelegt werden
[AMG
95, BMR96, SM96].
2.3 Problemstellung und Beitrag
Bei Migrationen von WF-Instanzdaten zwischen WF-Servern entstehen hohe Kosten. Das Ziel die-
ser Arbeit ist es, Verfahren zu entwickeln, mit denen dieses Datenvolumen reduziert werden kann.
W¨ahrend wir in bisherigen Ver¨offentlichungen zu ADEPT
úEûÿü.ýÿþû
ýÿû
[BD97, BD99a, BD00] Ver-
fahren zur Reduzierung der Kommunikationslast betrachtet haben, die auf der Vorberechnung von
geeigneten Serverzuordnungen zur Modellierungszeit basieren, werden bei den in der vorliegenden
Arbeit vorgestellten Verfahren die Kommunikationskosten durch zur Ausf¨
uhrungszeit durchgef¨uhrte
Optimierungen weiter reduziert. Dies wird erreicht, indem nicht alle f¨ur die betroffene WF-Instanz
verf¨ugbaren Daten zum Migrationszielserver ¨ubertragen werden, sondern nur diejenigen, die die-
ser Server tats¨achlich f¨ur die korrekte WF-Ausf¨uhrung ben¨otigt und die er noch nicht besitzt. Ein
WF-Server kann beispielsweise bereits ¨uber Daten verf¨ugen, wenn er fr¨uher an der Kontrolle der
WF-Instanz beteiligt war, oder wenn ihm bestimmte Informationen bei vorausgehenden Migrationen
¨ubermittelt worden sind. Da die Migrationen durch entsprechende Maßnahmen ”billiger“ werden,
k¨onnen sie ggf. h¨aufiger und damit auch f¨ur kleinere Prozessfragmente durchgef¨uhrt werden. Die
WF-Steuerung erfolgt dementsprechend meist im Teilnetz derjenigen Benutzer, welche die Aktivit¨at
5
bearbeiten, so dass sich die Antwortzeiten und die Verf¨ugbarkeit des WfMS verbessern.
Um einen Eindruck zu vermitteln, welche Art von Optimierungen im Zusammenhang mit der
Durchf¨uhrung von Prozessmigrationen im Einzelnen m¨oglich sind, wollen wir anhand von Abb. 2
einige Beispiele betrachten:
Die Zustandsinformation (inkl. Ablaufhistorie) zu den Aktivit¨aten
ù
und
wird bei herk¨ommli-
chen Migrationen ¨uber beide parallele Zweige zur AND-Join-Aktivit¨at
transportiert. Das heißt,
sie w¨urde sowohl bei der Migration
ú
als auch bei
¡%
zum Server 5 ¨ubertragen werden. Wie
man leicht sieht, kann eine dieser beiden (redundanten) ¨
Ubertragungen eingespart werden.
Angenommen, die Aktivit¨at
schreibt einen Ausgabeparameter in ein Datenelement, auf das
von der Aktivit¨at
lesend zugegriffen wird (nicht aber von
). Dann ist es wenig sinnvoll, das
Datenelement entlang des Kontrollflusses vom Server 2 ¨uber den Server 3 zum Server 5 zu ¨uber-
tragen. Eine Optimierung w¨are es, das Datenelement direkt vom Server 2 zum Server 5 zu ¨uber-
tragen. Dies ist besonders rentabel, wenn sehr große Datenelemente (z.B. Multimediadaten wie
Videos, Bitmaps, ...) betroffen sind.
Wird von der Aktivit¨at
ein Datenelement ben¨otigt, das von der Aktivit¨at
ù
geschrieben und
von
und
gelesen wurde, dann kann der Wert dieser Variablen von den WF-Servern 1, 2 und
3 bezogen werden. Es existiert insofern Optimierungspotential, als dass das Datenelement von
demjenigen Server bezogen werden kann, zu dem die leistungsf¨ahigste Kommunikationsverbin-
dung besteht. In jedem Fall sollte eine redundante ¨
Ubertragung vermieden werden. Angenommen
die Server 1 und 3 sind mitdem Server 5 nur ¨uber eine ISDN-Verbindung verbunden. Der Server 2
liege aber in einem zum Server 5 benachbarten Teilnetz mit einer Verbindung ¨uber ein schnelles
Gateway. Dann ist es wesentlich g¨unstiger, wenn das (große) Datenelement vom Server 2 bezogen
wird.
Die Beispiele zeigen, dass bei ”naiver“ Realisierung Daten unn¨otigerweise zu einer Partition ¨uber-
tragen werden k¨onnen. Eine solch redundante ¨
Ubertragung sollte auf alle F¨alle vermieden werden.
Im Folgenden werden Verfahren vorgestellt, mit denen Migrationen effizient durchgef¨uhrt werden
k¨onnen, indem die entstehenden Migrationskosten minimiert werden. Dazu werden im Einzelnen Ver-
fahren zur Migration der Kontrolldaten einer WF-Instanz (Zustand, Ablaufhistorie) und Verfahren zur
optimalen und redundanzfreien ¨
Ubertragung von Datenelementen vorgestellt.
3 M¨
oglichkeiten zur Migration von Workflow-Kontrolldaten
In diesem Abschnitt untersuchen wir, wie die Zustandsinformation einer WF-Instanz (WF-Kontroll-
daten nach [WMC99]) migriert werden soll. Dazu analysieren wir zuerst die prinzipiell m¨oglichen
Vorgehensweisen und beschrieben anschließend ein ausgew¨ahltes Verfahren.
3.1 Auswahl eines geeigneten Verfahrens
Im Folgenden werden alternative Ans¨atze zur Migration der Kontrolldaten einer WF-Instanz (Zustand
und Ablaufhistorie) diskutiert3:
Ansatz 1: Minimall¨
osung
Die ¨
Ubertragung der Zustandsinformation ist mit minimalem Kommunikationsaufwand m¨oglich,
3Bei einer Migration wird zus¨atzlich zu der explizit aufgef¨uhrten Information stets auch die WF-Instanz-ID transferiert.
6
wenn dem Zielserver lediglich die Quell- und Zielaktivit¨at der Migration mitgeteilt wird. Damit weiß
er, um welche Migration es sich handelt, und somit, an welcher Stelle im WF-Ausf¨uhrungsgraphen er
die Abarbeitung fortsetzen muss.
Der Nachteil dieses einfachen Ansatzes ist das Fehlen jeglicher Zusatzinformation aus der Ablauf-
historie. Dadurch k¨onnen die meisten der eingangs genannten fortschrittlichen WF-Konzepte nicht
realisiert werden. Die fehlende Information zu Bearbeitern von Vorg¨angeraktivit¨aten etwa schließt
die Verwendung von abh¨angigen Bearbeiterzuordnungen aus.
Ansatz 2: ¨
Ubertragung der aktuellen Zust¨
ande
Um das Problem fehlender Zustandsinformation zu l¨osen, k¨onnen bei einer Migration alle Zust¨ande
der Aktivit¨aten und Kanten des Ausf¨uhrungsgraphen an den Migrationszielserver ¨ubertragen werden.
Bei Synchronisationspunkten (z.B. Zusammenf¨uhrung paralleler Zweige) werden von verschiedenen
Migrationsquellservern dann ggf. unterschiedliche Zustandsinformationen zu denselben Aktivit¨aten
geliefert, da diese f¨ur nicht von ihnen selbst kontrollierte Aktivit¨aten evtl. nur veraltete Zustands-
information besitzen. Damit stellt sich das Problem, zu entscheiden, welches der aktuelle Zustand
einer Aktivit¨at ist, da dies nicht immer der am weitesten fortgeschrittene Zustand sein muss. So kann
z.B. beim Zur¨ucksetzen der Zustand einer Aktivit¨at von TERMINATED nach NOT ACTIVATED
¨ubergehen. Werden nun bei verschiedenen Migrationen unterschiedliche Zust¨ande f¨ur diese Aktivit¨at
empfangen, so kann nicht ohne Weiteres entschieden werden, welches der aktuell g¨ultige ist.
Zwar ist bei diesem Ansatz die Zustandsinformation verf¨ugbar, allerdings fehlt auch hier jegliche
Zusatzinformation (z.B. zu Bearbeitern oder Ausf¨uhrungszeitpunkten der Aktivit¨aten).
Ansatz 3: ¨
Ubertragung der Zust¨
ande und der Ablaufhistorie
Um das letztgenannte Problem zu l¨osen, kann die gesamte zu dieser WF-Instanz gespeicherte Informa-
tion (inkl. Ablaufhistorie) ¨ubertragen werden. Werden an Synchronisationspunkten unterschiedliche
Zust¨ande f¨ur eine Aktivit¨at empfangen, so muss wie beim Ansatz 2 der aktuellste Zustand bestimmt
werden.
Da bei diesem Ansatz alle Kontrolldaten der WF-Instanz migriert werden, treten die oben beschriebe-
nen Probleme nicht auf. Der Nachteil ist aber, dass Ausf¨uhrungsinformationen redundant ¨ubertragen
werden, da sich z.B. die Information, dass eine Aktivit¨at beendet wurde, sowohl in der Ablaufhistorie
als auch in den Aktivit¨atenmarkierungen widerspiegelt.
Ansatz 4: ¨
Ubertragung (nur) der Ablaufhistorie
Die gesamte von Nachfolgeraktivit¨aten ben¨otigte Information zu einer WF-Instanz findet sich in ihrer
Ablaufhistorie wieder. Deshalb kann, ausgehend von der (auf den Servern repliziert vorhandenen)
WF-Vorlage, durch das ”Nachspielen“ der in der Ablaufhistorie vermerkten Aktionen der Zustand der
WF-Instanz rekonstruiert werden. Die Zustandsinformation einer WF-Instanz kann somit ¨ubertragen
werden, indem ausschließlich die Ablaufhistorie transferiert wird.
Bewertung
Ein gravierender Nachteil der Ans¨atze 1 und 2 ist das Fehlen von Zusatzinformation zur WF-Instanz.
Sollen bei Zugrundelegung dieser Ans¨atze fortschrittliche WfMS-Konzepte realisiert werden, muss
h¨aufig Information nachtr¨aglich angefordert werden. Dies f¨uhrt dazu, dass eine große Anzahl von
¨
Ubertragungen stattfindet, da die Kontrolldaten, die bei den anderen Ans¨atzen auf einmal ¨ubertragen
werden, nun durch mehrere Anforderungen besorgt werden m¨ussen. Im Extremfall m¨ussen von allen
Vorg¨angeraktivit¨aten Daten nachgefordert werden, z.B. wenn die Start- und Endzeitpunkte aller Akti-
vit¨aten ben¨otigt werden, um Zeitpl¨ane f¨ur die nachfolgenden Aktivit¨aten zu berechnen [DRK00]. Das
Nachfordern von Kontrolldaten beeintr¨achtigt außerdem die Verf¨ugbarkeit des WfMS, da die Bear-
beitung eines WF nur fortschreiten kann, wenn die Server, von denen Informationen ben¨otigt werden,
7
gerade verf¨ugbar sind. Aus diesen Gr¨unden scheiden die Ans¨atze 1 und 2 aus.4Der Ansatz 3 disquali-
fiziert sich wegen des großen Umfangs der zu transferierenden Datenmenge. Abgesehen davon resul-
tiert aus den zus¨atzlich ¨ubertragenen Daten kein Vorteil gegen¨uber dem Ansatz 4. Der letztgenannte
Ansatz stellt einen guten Kompromiss dar, da hier die Datenmenge in einem vern¨unftigen Rahmen
bleibt und alle ben¨otigte Information vorhanden ist. Im Folgenden wird dieser Ansatz deshalb n¨aher
untersucht.
3.2 Migration der Ablaufhistorie
Nachdem sich gezeigt hat, dass die g¨unstigste Variante zur Migration von Zustandsinformation darin
besteht, die Ablaufhistorie zu ¨ubertragen, betrachten wir nun diesen Ansatz etwas detaillierter. Von
Interesse ist dabei vor allem, wie an Synchronisationspunkten des Ausf¨uhrungsgraphen (AND-Join)
die Ablaufhistorien der verschiedenen Vorg¨angeraktivit¨aten zusammengef¨uhrt werden.
Bei einem WF ohne parallele Verzweigungen ist der Ablauf des Verfahrens denkbar einfach: Da eine
Ablaufhistorie stets von nur einer Vorg¨angeraktivit¨at empfangen wird, kann die lokal evtl. schon vor-
handene Historie5durch diese ersetzt werden. Durch das ”Nachspielen“ der in der Ablaufhistorie
vorhandenen Eintr¨age erh¨alt man dann den aktuellen Zustand des Ausf¨uhrungsgraphen.
Interessanter ist der Fall, dass parallele Zweige unterschiedlicher Server zusammengef¨uhrt werden
m¨ussen (z.B. bei der AND-Join-Aktivit¨at
in Abb. 2), da dann zwei unterschiedliche Versionen der
Ablaufhistorie aufeinander treffen. Beim Zusammenf¨uhren von Historieninformation verschiedener
WF-Server muss gew¨ahrleistet sein, dass das Ergebnis wieder eine korrekte Historie darstellt, d.h.,
dass eine Ablaufhistorie entsteht, die auch auf einem zentralen System mit nur einem einzigen WF-
Server entstanden sein k¨onnte. Es m¨ussen sich also alle im WF-Graphen definierten Reihenfolge-
beziehungen von Aktivit¨aten in der Ablaufhistorie widerspiegeln, auch wenn diese Aktivit¨aten von
unterschiedlichen Servern kontrolliert wurden. Außerdem soll ein WF-Server stets den vollst¨andigen
f¨ur ihn relevanten Zustand einer von ihm kontrollierten WF-Instanz kennen. Das heißt, ein WF-Server,
der gerade die Aktivit¨ateninstanz
ù
kontrolliert, kennt stets alle Historieneintr¨age (und damit den Zu-
stand) der Vorg¨angeraktivit¨aten von
ù
, weil diese bei Migrationen zu ihm weitergereicht wurden. ¨
Uber
die Historieneintr¨age von parallel zu
ù
ausgef¨uhrten Aktivit¨aten muss dieser Server im Allgemeinen
aber nicht verf¨ugen.
Die bei einer Migration empfangene und die auf diesem Server schon lokal vorhandene (bzw. davor
empfangene) Ablaufhistorie m¨ussen zu einer einzigen Ablaufhistorie zusammengef¨uhrt werden. Dies
geschieht, indem die Historieneintr¨age ”gemischt“ werden. Wie dieses Mischen erfolgt, wollen wir
am Beispiel der in Abb. 3 dargestellten AND-Join-Aktivit¨at
¢
betrachten. Wenn sich eine Aktivit¨aten-
instanz (z.B.
ù
) im Kontrollfluss vor einer anderen Aktivit¨at (z.B.
) befindet, so m¨ussen auch die zu
ihr geh¨orenden Eintr¨age in der resultierenden Historie vor den Eintr¨agen der anderen Aktivit¨at ein-
sortiert werden. Die Reihenfolge von Historieneintr¨agen parallel ausgef¨uhrter Aktivit¨aten (z.B.
und
) kann dagegen beliebig gew¨ahlt werden. Man kann zeigen, dass bei einer Migration empfangene
Historieneintr¨age, die dem Zielserver noch nicht bekannt sind, einfach an die lokal schon vorhandene
Ablaufhistorie angeh¨angt werden k¨onnen [Zei99], um diesen Bedingungen zu gen¨ugen (vgl. Abb. 3).
4In Abschnitt 4 wird ein Verfahren vorgestellt, das mit der ¨
Ubertragung derselben Information wie der Ansatz 1 beginnt
(WF-Instanz-ID, Quell- und Zielaktivit¨at der Migration). Anschließend wird die zus¨atzlich ben¨otigte Information ange-
fordert und (auf einmal) ¨ubertragen. Da das Verfahren auf der ¨
Ubertragung von Ablaufhistorien basiert, wird es aber als
Optimierung des Ansatzes 4 betrachtet.
5Dieser Fall ist gegeben, wenn der Migrationszielserver bereits fr¨uher einmal eine Partition des Ausf¨uhrungsgraphen
dieser WF-Instanz kontrolliert hat.
8
Die Position schon vorhandener Eintr¨age bleibt unver¨andert. Dieses Verfahren arbeitet korrekt, weil
f¨ur alle Aktivit¨aten gilt: Wenn ein Historieneintrag zu einer Aktivit¨at am Zielserver bekannt ist, dann
sind auch die Historieneintr¨age zu allen Vorg¨angeraktivit¨aten bekannt (siehe oben). Deshalb kann es
sich bei einer Aktivit¨ateninstanz, von der erstmalig ein Eintrag empfangen wird (z.B.
), nicht um eine
Vorg¨angeraktivit¨at von schon bekannten Aktivit¨aten (
ù
,
und
) handeln. Diese Aktivit¨at kann also
nur parallel zu diesen Aktivit¨aten oder nach diesen ausgef¨uhrt worden sein. Deshalb ist es korrekt,
den erstmalig empfangenen Historieneintrag am Ende der Ablaufhistorie zu platzieren. Dabei darf
die Reihenfolge neuer Eintr¨age untereinander (z.B.
und
£
) nat¨urlich nicht ver¨andert werden. Durch
dieses Vorgehen ergibt sich ein ¨außerst effizienter Algorithmus.
¤#¥ ¦.§ ¨K©ª¬«©ªG
® ¯
°K±²³±²K´
µ/¶ ·.¸
µ/¶¹¸
µ/¶ º»¸
¼
½K¾¿À¾¿KÁ
Â#Ã Ä.Å
Â#Ã ÆÅ
Â#Ã Ç.Å
Â#Ã È.Å
É
ÊKËÌÍËÌÎ
ÊKËÌÍËÌKÏ
Ð
Ñ/Ò Ó.Ô
Ñ/Ò ÕÔ
Ñ/Ò Ö.Ô
Ñ/Ò ×.Ô
Ñ#Ò Ó.Ô
Ñ#Ò ÕÔ
Ñ#Ò Ø»ÔÚÙ Û
Ü/Ý Þ.ß
Ü/Ýàß
Ü/Ý á»ß
Ü/Ý â.ß
Ü/Ý ã.ß
Ü/Ý Þ.ß
Ü/Ý àß
Ü/Ý á»ß
Ü/Ý â.ß
Ü/Ý ã.ß
Ü/Ý äß
å8æç è ésêìë í
î/ï ð.ñ
î/ïòñ
î/ï ó.ñ
ô
õKö÷øö÷ù
úû üý þ ÿ
þ
>ý û
û ý
ý
ü
û ü
ý ÿ.ü
ÿ
ÿ
û
ý
.þ û
ÿ
Abbildung 3 Beispiel f¨ur das Zusammenf¨uhren von Ablaufhistorien.
4 Optimierte ¨
Ubertragung von Workflow-Kontrolldaten
Der im vorherigen Abschnitt diskutierte Ansatz 4 ist am besten f¨ur die ¨
Ubertragung der Kontrollda-
ten einer WF-Instanz geeignet, da er das g¨unstigste Kommunikationsverhalten aufweist. Bei dem in
Abschnitt 3.2 skizzierten Verfahren kann es allerdings zu redundanten Daten¨ubertragungen kommen.
So werden bei dem in Abb. 3 dargestellten Beispiel die Historieneintr¨age der Aktivit¨aten
ù
und
bei
der Migration
zum Server 1 ¨ubertragen, obwohl sie diesem schon bekannt sind. Im dem nun fol-
genden Abschnitt werden verbesserte Verfahren vorgestellt, bei denen zum Zielserver nur die wirklich
noch ben¨otigten Historieneintr¨age ¨ubertragen werden.
4.1 Versenden von Ablaufhistorieneintr¨
agen
Die nahe liegendste Idee zur Reduzierung des Datenvolumens beim ¨
Ubertragen von WF-Kontroll-
daten besteht darin, nur den ben¨otigten Ausschnitt der Ablaufhistorie und nicht die komplette Ablauf-
historie an den Migrationszielserver zu senden. Aus Platzgr¨unden verzichten wir hier auf eine formale
Beschreibung dieses Verfahrens. Stattdessen erl¨autern wir nur das Grundprinzip und diskutieren die
entstehenden Nachteile. In Abschnitt 4.2 wird dann ein verbessertes Verfahren vorgestellt, das diese
Nachteile vermeidet.
Um bei einer Migration nicht immer die gesamte Ablaufhistorie einer WF-Instanz ¨ubertragen zu
m¨ussen, berechnet der Quellserver, welcher Teil dieser Historie vom Zielserver f¨ur die weitere
Ausf¨uhrung noch ben¨otigt wird. Dementsprechend wird nur dieser Ausschnitt bei der Migration ¨uber-
tragen. Dazu sucht der Quellserver in der Historie nach Eintr¨agen, deren zugeh¨orige Aktivit¨atenin-
stanz vom Zielserver kontrolliert wurde (sofern vorhanden). Bei der ¨
Ubertragung der Ablaufhistorie
k¨onnen diese Eintr¨age dann weggelassen werden. Dasselbe gilt f¨ur Historieneintr¨age, die sich auf Vor-
g¨angeraktivit¨ateninstanzen (bzgl. des Kontrollflusses) dieser Aktivit¨ateninstanzen beziehen, da auch
9
diese Historieneintr¨age dem Zielserver schon bekannt sind. Der Grund daf¨ur ist, dass ein WF-Server
alle Historieneintr¨age kennt, die zu Vorg¨angeraktivit¨aten der von ihm kontrollierten Aktivit¨ateninstan-
zen geh¨oren (vgl. Abschnitt 3.2).
Durch dieses Verfahren werden Historieneintr¨age, von denen der Quellserver einer Migration sicher
weiß, dass sie auf dem Zielserver schon bekannt sind, an diesen nicht mehr ¨ubertragen. So werden
bei dem in Abb. 4 dargestellten Beispiel einer parallelen Verzweigung die Historieneintr¨age zu den
Aktivit¨ateninstanzen
ù
und
weder bei der Migration
noch bei
û
an den Server 2 ¨ubertragen,
da dieser bereits die Aktivit¨at
kontrolliert hat und deshalb die zu Aktivit¨at
und zur Vorg¨angerakti-
vit¨at
ù
geh¨orenden Historieneintr¨age schon kennt.
"!$#&%!'#"( "!$#&%!'#)
*!'#&%!$#"(
"!$#&%!'#"( *!'#&%!$#+)
*!'#&%!$#)
, -
! .
/ 0
1
"!$#&%!'#"(
2435 6
7
8"9$:&;9':<
=
8"9$:&;9':">
?A@CB D E"F$G&HF'G$I
J KML N O
PAQCR S
T4UWV X
Abbildung 4 Beispiel f¨ur die Migration von WF-Kontrolldaten.
Bei dem oben beschriebenen Verfahren kann es aber immer noch zur redundanten ¨
Ubertragung von
Historieninformation kommen. Das Problem des Verfahrens ist, dass der Quellserver einer Migration
nicht exakt weiß, welche Historieneintr¨age beim Zielserver schon vorhanden sind. Nehmen wir in
dem Beispiel aus Abb. 4 an, dass die Migration
vor
û
ausgef¨uhrt wird. Dann m¨ussen bei der
Migration
¡%
die Historieneintr¨age der Aktivit¨aten
und
¨ubertragen werden. Bei der sp¨ater aus-
gef¨uhrten Migration
Y
û
kann der Quellserver 1 aber nicht wissen, dass die entsprechenden Eintr¨age
dem Zielserver 2 schon bekannt sind. Diese nicht vorhandene Information f¨uhrt dazu, dass er die
Eintr¨age unn¨otigerweise ¨ubertr¨agt. Das vorgestellte Verfahren erm¨oglicht also zwar eine Reduzierung
der zu ¨ubertragenden Datenmenge, redundante Daten¨ubertragung l¨asst sich damit aber nicht v¨ollig
ausschließen.
4.2 Anfordern von Ablaufhistorieneintr¨
agen
Die redundante ¨
Ubertragung von Ablaufhistorieneintr¨agen kann ausgeschlossen werden, wenn der
Zielserver einer Migration dem Quellserver Information dar¨uber liefert, welche Historieneintr¨age
ihm bereits bekannt sind.6Ein Verfahren hierf¨ur, wird nun vorgestellt. Dabei kann eine redundante
¨
Ubertragung von Historieneintr¨agen nur dann ausgeschlossen werden, wenn f¨ur eine WF-Instanz nie
mehrere Migrationen zeitlich ¨uberlappend bei demselben WF-Server eingehen. Ansonsten kann der
Zielserver nicht wissen, welche Historieneintr¨age noch durch die anderen gleichzeitig ablaufenden
Migrationen geliefert werden. Deshalb verwendet der Zielserver einer Migration Sperren, um sicher-
zustellen, dass zu jedem Zeitpunkt f¨ur eine WF-Instanz maximal eine Migration eingehen kann, d.h.
er blockiert ggf. kurzfristig die weitere Bearbeitung einer eingehenden Migration.
Das im Folgenden vorgestellte Verfahren basiert auf der Idee, dass der Zielserver der durchzuf¨uhren-
den Migration beim Quellserver diejenigen Teile der Ausf¨uhrungshistorie anfordert, die bei ihm noch
nicht vorhanden sind. Das Verfahren gliedert sich in 3 Phasen:
6Eine Alternative dazu w¨are, dass die anderen Server des WfMS Information dar¨uber austauschen, welche Histori-
eneintr¨age schon zu diesem Zielserver migriert wurden. Da ein solches Verfahren aber sehr komplex w¨are und außerdem
nicht weniger Kommunikation erfordern w¨urde, wird dieser Ansatz nicht weiter verfolgt.
10
1. Der Quellserver informiert den Zielserver ¨uber die anstehende Migration. Dazu ¨ubertr¨agt er ihm
außer der ID der zu migrierenden WF-Instanz jeweils die ID der Quell- und Zielaktivit¨aten der
Migration. F¨ur das Beispiel der Migration
¡%
aus Abb. 4 ergibt sich also die ¨
Ubertragung:
Z
WF-Inst-ID,
¢
,
\[
2. Der Zielserver der Migration fordert nun beim Quellserver den noch fehlenden Teil der Ablaufhi-
storie an. Dazu muss er ihm mitteilen, ¨uber welche Historieneintr¨age er bereits verf¨ugt. Die ein-
fachste L¨osung, die IDs aller zugeh¨origen Aktivit¨ateninstanzen zu ¨ubertragen, w¨are aber unn¨otig
aufwendig. Sind die Historieneintr¨age einer Aktivit¨ateninstanz dem Zielserver bekannt, so kennt
er n¨amlich auch die Eintr¨age zu Vorg¨angeraktivit¨aten dieser Aktivit¨ateninstanz. Deshalb gen¨ugt
es, die Menge
]
ù
'^`_ba
c_de+d_d
£
^
zu ¨ubertragen, welche die IDs derjenigen Aktivit¨ateninstanzen
enth¨alt, von denen dem Zielserver keine Historieneintr¨age zu Nachfolgeraktivit¨aten bekannt sind.
Dies sind sozusagen die ”letzten dem Zielserver bekannten Aktivit¨aten“ der WF-Instanz. Es kann
vorkommen, dass die Menge
]
ù
$^`_a
c_ded_d
£
`^
mehrere Aktivit¨aten enth¨alt, da der Zielserver einer
Migration Historieneintr¨age zu Aktivit¨aten besitzen kann, die verschiedenen parallelen Zweigen
angeh¨oren. Dann muss die jeweils letzte bekannte Aktivit¨at jedes Zweiges in
]
ù
$^`_a
c_ded_d
£
`^
enthalten sein.
Mit dem Algorithmus 1 kann der Zielserver einer Migration die Menge
]
ù
$^_ba
c_de+d_d
£
^
berech-
nen. Dazu reduziert er die lokal bei ihm vorhandene Ablaufhistorie
fhg
0
+ijd^`_klnm
der WF-Instanz
auf die Vorg¨angeraktivit¨aten der Migrationsquellaktivit¨at, da nur dieser Teil der WF-Instanz f¨ur
die Migration relevant ist. Dadurch ergibt sich die Ablaufhistorie
o
£
`g
£
pe
{ù
_biqd^`_bklnm
. Der hin-
terste Eintrag
]
von
o
£
`g
£
e
{ù
_ijd^`_klnm
geh¨ort zur einer Aktivit¨ateninstanz
g
, deren Histori-
eneintr¨age am Zielserver bekannt sind. Da der Zielserver auch ¨uber die Historieneintr¨age aller
Vorg¨angeraktivit¨aten von
g
verf¨ugt, entfernt er diese aus der Ablaufhistorie
o
£
`g
£
e
{ù
_ijd^`_klnm
.
Die Aktivit¨ateninstanz
g
wird in
]
ù
$^_ba
r_ded_d
£
`^
aufgenommen, weil die Vorg¨angeraktivit¨aten
von
g
(inkl.
g
) am Zielserver bekannt sind, nicht aber die Nachfolgeraktivit¨aten. Der gesamte
Vorgang wird solange wiederholt, bis in der Historie
o
£
`g
£
pe
{ù
_biqd^`_bklnm
keine Eintr¨age mehr exi-
stieren. Ist dies erreicht, so wurde die vollst¨andige Menge
]
ù
'^`_a
c_de+d_d
£
`^
ermittelt. Im Beispiel
der Migration
aus Abb. 4 ergibt sich
]
ù
'^`_a
c_de+d_d
£
`^tsvu
O
`w
, weil der Zielserver (Server 2)
nur ¨uber Information zu den Aktivit¨aten
ù
und
verf¨ugt (
wurde vom Server 2 kontrolliert). Da
ù
eine Vorg¨angeraktivit¨at von
ist, wird
ù
nicht in
]
ù
'^`_ba
c_de+d_d
£
^
aufgenommen.
3. Nachdem der Quellserver der Migration die Menge
]
ù
$^_ba
r_ded_d
£
`^
empfangen hat, kann er mit
Algorithmus 2 die zu ¨ubertragende Ablaufhistorie
xd
+lyijd^_bklnm
berechnen. Dazu reduziert er
die bei ihm vorhandene Ablaufhistorie
]zk
ù
'gWijd^`_klnm
auf Vorg¨anger der Quellaktivit¨at der Mi-
gration (wie der Zielserver in Algorithmus 1). Anschließend entfernt er alle Eintr¨age zu Ak-
tivit¨ateninstanzen
g|{}]
ù
$^`_a
c_ded_d
£
`^
und zu deren Vorg¨angern aus
~d
lnijd^`_klnm
, so dass
sich die zu ¨ubertragende Ablaufhistorie ergibt. Betrachten wir nochmals das oben angesprochene
Beispiel der Migration
¡%
, bei dem in Schritt 2 die Menge
]
ù
$^_ba
c_de+d_d
£
^su
O
`w
ermittelt
wurde. In Schritt 3 werden dann die Eintr¨age zu den Aktivit¨ateninstanzen
ù
und
aus der lo-
kal vorhandenen Historie (mit Eintr¨agen zu den Aktivit¨aten
ù
,
,
,
,
£
,
¢
) entfernt, so dass die
Historieneintr¨age der Aktivit¨aten
,
,
£
,
¢
¨ubertragen werden.
Wird nach der oben beschriebenen Migration
die Migration
Y
û
zum selben Zielserver 2 durch-
gef¨uhrt7, so kennt dieser Server die Eintr¨age zu den Aktivit¨aten
ù
,
,
,
,
£
und
¢
bereits. Durch
Anwendung von Algorithmus 1 ergibt sich somit die Menge
]
ù
$^`_a
c_ded_d
£
`^su
y
w
. Algorithmus 2
entfernt dementsprechend die Eintr¨age zu den Aktivit¨aten
ù
,
,
und
aus der f¨ur diese Migration
7Wie zu Beginn dieses Abschnitts erl¨autert wurde, ist die ¨uberlappende Ausf¨uhrung von Migrationen ausgeschlossen.
Wird in dem Beispiel die Migration
c
vor
b
ausgef¨uhrt, so ergibt sich dasselbe Verhalten.
11
Algorithmus 1 (Zielserver: Anfordern von Ablaufhistorieneintr¨
agen)
input
*p
: Quellaktivit¨ateninstanz der Migration
: am Zielserver bekannter Teil der Ablaufhistorie
output
¢¡
z
£
: Menge von Aktivit¨ateninstanzen, bis zu denen die Ablaufhistorie dem Zielserver
bekannt ist
begin
¢¡
z
£
¥¤§¦
;
// f¨ur Migration sind nur Vorg¨angeraktivit¨ateninstanzen der Quellaktivit¨at (inklusive) relevant
¨
£
¡©
c
¤
|ª
y«
©
¬
*'c
¢®°¯
c
¬
*'pz±±
;
while
¨
£
¡©
c²
¤¦
do
//
ist der hinterste Eintrag der Historie
¨
£
¡©
,
die zugeh¨orige Aktivit¨ateninstanz
¤
¢¡
«
©
¬
¨
£
¡©
³±
;
´¤
z
£
nµ
©
¡©
¬
±
;
¶¡
£
¥¤
¶¡
£
®¸·
¹
;
// entferne Eintr¨age zu
und aller Vorg¨anger bzgl. Kontrollfluss aus Ablaufhistorie
¨
£
¡©
¤
¨
£
¡©
Yº
y«
©
¬
·
¹
®°¯
p
¬C
±±
;
end.
Algorithmus 2 (Quellserver: Anfordern von Ablaufhistorieneintr¨
agen)
input
*p
: Quellaktivit¨ateninstanz der Migration
¢¡
z
£
: Menge der letzten am Zielserver bekannten Aktivit¨ateninstanzen
p
¡
»
: am Quellserver vorhandene Ablaufhistorie
output
¼
C½
c
: der bei der Migration zu ¨ubertragende Teil der Ablaufhistorie
begin
// f¨ur Migration sind nur Vorg¨angeraktivit¨aten der Quellaktivit¨at relevant
¼
C½
c
¤
p
¡
ª
n«
©
¬
·
*p
¹
®¾¯
p
c
¬
*'pz±±
;
// Eintr¨age zu bekannten Aktivit¨ateninstanzen aus Ablaufhistorie entfernen
for each
"¿
¢¡
z
£
do
// Eintr¨age zu
und Vorg¨angern von
aus Historie streichen
¼
W½
¤
¼
W½
º
y«
©
¬
·
¹
®°¯
p
¬
±±
;
end.
relevanten Historie (mit Eintr¨agen zu
ù
,
,
,
À
und
Á
), so dass nur die Historieneintr¨age der Aktivit¨at
Á
¨ubertragen werden. Da bei der Migration
Historieneintr¨age zu den Aktivit¨aten
,
À
,
£
und
¢
¨ubermittelt wurden (s.o.), findet also keine redundante Informations¨ubertragung statt. Im Allgemeinen
ist die redundante ¨
Ubertragung von Historieneintr¨agen bei dem beschriebenen Verfahren stets ausge-
schlossen: Ist ein Historieneintrag zu einer Aktivit¨at
am Zielserver der Migration bereits bekannt,
so wird dieser in der Schleife von Algorithmus 1 aus
ftgWÀiqd^_bklm
entfernt (sonst w¨are die Schleife
noch nicht verlassen worden). Deshalb wird der entsprechende Eintrag beim Durchlaufen der Schleife
von Algorithmus 2 auch aus
xd
+lyijd^_bklnm
entfernt und damit nicht ¨ubertragen.
5¨
Ubertragung von Datenelementen
Nachdem wir in den Abschnitten 3 und 4 untersucht haben, wie die Kontroll- bzw. Statusdaten einer
WF-Instanz bei Migrationen effizient ¨ubertragen werden k¨onnen, wenden wir uns nun der Versor-
12
gung und ¨
Ubernahme der Parameterdaten von Aktivit¨atenprogrammen zu ([WMC99]: WF-relevante
Daten und Anwendungsdaten). In ADEPT werden diese Daten als globale Prozessvariablen (sog. Da-
tenelemente) verwaltet (siehe [BD98]). Die im Folgenden beschriebenen Verfahren lassen sich aber
auch bei anderen Realisierungsformen f¨ur die Modellierung von Datenfl¨ussen anwenden (z.B. bei
Ein- und Ausgabencontainern wie in MQSeries Workflow [LR00]). Bei den in der Literatur diskutier-
ten Verfahren zur Migration von Datenelementen werden beim ¨
Ubergang zwischen zwei Partitionen
¨ublicherweise die Werte aller Datenelemente zur Nachfolgerpartition ¨ubertragen. Dies f¨uhrt zu einer
starken Belastung des Kommunikationssystems, insbesondere dann, wenn sehr große Datenelemente
(z.B. multimediale Dokumente) verwendet und vom WfMS nicht nur Referenzen auf diese Daten ver-
waltet werden.8Im Folgenden werden Verfahren vorgestellt, mit denen die bei der ¨
Ubertragung von
Datenelementen entstehende Belastung des Kommunikationssystems deutlich reduziert werden kann.
Bei der Entwicklung dieser Verfahren muss beachtet werden, dass von einem WfMS sowohl recht
kleine als auch sehr große Datenelemente verwaltet werden k¨onnen, und dass nicht jedes Verfahren
f¨ur beide F¨alle gleich gut geeignet ist. Zus¨atzliche Schwierigkeiten ergeben sich aus der Tatsache,
dass die Verfahren nicht auf den Fall statischer Serverzuordnungen beschr¨ankt sein d¨urfen, sondern
auch bei Verwendung variabler Serverzuordnungen anwendbar sein m¨ussen.
5.1 Datenhistorie
Der Wert eines globalen Datenelements kann sich im Verlauf der Ausf¨uhrung einer WF-Instanz
ver¨andern. Da die ”¨uberschriebenen“ Werte evtl. sp¨ater bei einem eventuellen (partiellen) Zur¨uck-
setzen noch f¨ur die Ausf¨uhrung von Kompensationsaktivit¨aten einer WF-Instanz ben¨otigt werden,
werden sie in ADEPT bis zu deren Beendigung aufbewahrt. Zu jedem Datenelement existiert eine
Historie von Werten (zu denen jeweils auch die ID der schreibenden Aktivit¨ateninstanz verwaltet
wird). Beim Lesen des Datenelements ist nur der zuletzt von einer Vorg¨angeraktivit¨at des Lesers ge-
schriebene Wert9g¨ultig.10 Um das Datenvolumen bei Migrationen zu reduzieren, wird bei allen im
Folgenden vorgestellten Verfahren nur der jeweils aktuellste Wert ¨ubertragen. Im Falle einer (selten
auftretenden) Kompensation muss der bei der Ausf¨uhrung der zu kompensierenden Aktivit¨at g¨ultige
Wert des Datenelements verwendet werden. Dieser Wert ist noch auf demjenigen Server vorhanden,
welcher die Aktivit¨at kontrolliert hat.
5.2 Kleine Datenelemente
Viele der von einem WfMS verwalteten Datenelemente, wie Integer-Werte oder kurze Strings, sind
relativ ”klein“, so dass f¨ur sie die im nachfolgenden Abschnitt vorgestellten Optimierungen nicht loh-
nend sind. Hier macht es keinen Sinn, die ohnehin bereits geringe Datenmenge noch weiter zu redu-
zieren und dabei zu riskieren, dass zus¨atzliche Kommunikationszyklen notwendig werden. In diesem
Abschnitt wird ein Verfahren vorgestellt, das keine zus¨atzlichen Kommunikationszyklen erfordert, das
ohne großen Berechnungsaufwand auskommt und das vermeidet, dass ein kleines Datenelement von
mehreren Quellservern an den Zielserver einer Migration ¨ubertragen wird. Die (durchschnittliche)
Gr¨oße, bis zu der ein Datenelement als klein gilt, kann vom Administrator des WfMS konfiguriert
8Die Nachteile, die sich ergeben, wenn ein WfMS nur Referenzen auf Daten verwaltet, werden in Abschnitt 6 ausf¨uhrlich
diskutiert.
9Da in ADEPT das Schreiben eines Datenelements durch Aktivit¨aten paralleler Zweige nicht erlaubt ist (Vermeidung
von Lost Updates), ist dieser Wert eindeutig identifizierbar.
10ADEPT verfolgt bzgl. Datenkontextmanagement einen ¨ahnlichen Ansatz wie z.B. ConTracts [RS95].
13
werden, so dass sich ein m¨oglichst g¨unstiges Laufzeitverhalten ergibt. In der Regel ist es sinnvoll,
ein Datenelement der Menge der großen Datenelemente
]Â+l
G£
`ÃÄÂ_bžg
£
Æ
£
_^
zuzuordnen, wenn es
mehrere Netzwerkpakete ausf¨ullt. Andernfalls wird es der in diesem Abschnitt betrachteten Menge
Ç
ÆÈÂ'ggWÃ\Â_Â'ÅÉg
£
pÆ
£
Ê*_b^
zugeordnet.
Die Menge, der bei einer Migration
ËÌ+ÍÎ`ÏbÐ Ñ ÐÒÓ ÔÖÕÏ× ÒÑÐÒ
zusammen mit den Ablaufhistorieneintr¨agen
ËxdØ+lyiqd^_bklm
zu ¨ubertragenden kleinen Datenelemente (
ËxdØ+lyÃÄÂ_bžg
£
Æ
£
pÊ*_^
), kann mit Al-
gorithmus 3 ermittelt werden. Er basiert auf der folgenden Idee: F¨ur alle Datenelemente
ÀÙ{
Ç
ÆÈÂ'ggWÃ\Â_Â'ÅÉgÚpÆqÚÊ*_b^
kann diejenige Aktivit¨ateninstanz
Â
bestimmt werden, die den f¨ur das Mi-
grationsziel (d.h. den f¨ur die Zielaktivit¨at
ÛÜÂlØ$Úp_baÜÝc_
der Migration) g¨ultigen Wert von
À
geschrieben
hat. Diese Aktivit¨ateninstanz kann unter Verwendung der WF-Vorlage und der Ablaufhistorie der
WF-Instanz ermittelt werden. Das Datenelement
À
wird bei der betrachteten Migration genau dann
¨ubertragen, wenn der Historieneintrag f¨ur die Beendigung der Aktivit¨at
Â
in der bei der Migration
¨ubertragenen Ablaufhistorie
ËxdØ+lyijd^_bklnm
enthalten ist (siehe Abschnitt 4.2). Da sichergestellt ist,
dass ein solcher Historieneintrag h¨ochstens einmal zu jedem Server ¨ubertragen wird, gilt dies auch f¨ur
jede Version eines Datenelements. Bei dem vorgestellten Verfahren ist eine redundante ¨
Ubertragung
von Datenelementen somit ausgeschlossen. Des weiteren wird kein zus¨atzlicher Kommunikations-
zyklus ben¨otigt, da die Datenelemente der Menge
Ë~dØlnÃ\Â_Â'ÅÉgÚpÆqÚÊ*_b^
zusammen mit der Menge
der Historieneintr¨age
ËxdØ+lyijd^`_klnm
zum Migrationszielserver ¨ubertragen werden. Es kann aber vor-
kommen, dass Datenelemente zu diesem Server ¨ubertragen werden, obwohl sie dort ¨uberhaupt nicht
ben¨otigt werden. Da die hier betrachteten Datenelemente klein sind, ist dies akzeptabel. Ein Verfah-
ren, bei dem solche unn¨otigen ¨
Ubertragungen ausgeschlossen sind, wird im folgenden Abschnitt f¨ur
große Datenelemente vorgestellt.
Algorithmus 3 ( ¨
Ubertragung kleiner Datenelemente)
input
Þ¡
½
cz
: Zielaktivit¨ateninstanz der Migration
"ß
¡
Cà
¡
¡
«
cß
©
: Menge der am Quellserver bekannten kleinen Datenelemente
¼
C½
c
: der zu ¨ubertragende Teil der Ablaufhistorie (von Algorithmus 2 ermittelt)
output
¼
C½
à
¡
¡
«
cß
©
: bei der Migration zu ¨ubertragende kleine Datenelemente
begin
¼
C½
à
¡
¡
«
cß
©
¥¤Y¦
;
for each
t¿
"ß
¡
à
¡
¡
«
cß°
©
do
//
¡
hat diejenige Version von
geschrieben, die f¨ur
Þ¡
½
r
g¨ultig ist
¡
¤
¶¡
áâ
c
‹
Þ¡
½
c±
;
// der zu
¡
geh¨orende Ende-Historieneintrag wird bei der betrachteten Migration ¨ubertragen
if
«åä
໬
¡
ãææræ
±
¿
¼
W½
then
¼
W½
à
¡
¡
«
cß°
©
ç¤
¼
C½
à
¡
¡
«
cß
©
®¸·
+¹
;
end.
Angenommen bei dem in Abb. 5 dargestellten Beispiel wird die Migration
ËYè Ó é
vor
ËÐbÓ é
ausgef¨uhrt.
Dann werden bei Verwendung des in Abschnitt 4.2 beschriebenen Verfahrens bei der Migration
Ëè Ó é
die Historieneintr¨age der Aktivit¨aten
Â
und
ê
zum Server 2 ¨ubertragen. Damit wird das von Aktivit¨at
Â
geschriebene kleine Datenelement
Àìë
bei dieser Migration ebenfalls ¨ubertragen. Bei der Migration
ËÐbÓ é
werden die Historieneintr¨age von Aktivit¨at
Ý
¨ubertragen, weshalb auch das von
Ý
geschriebene
Datenelement
À+í
¨ubertragen wird. Das Datenelement
Àìë
wird bei dieser Migration aber nicht (redun-
dant) an den Server 2 ¨ubertragen.
14
î$ïðòñïð$ó
ô
õ
ö'÷nøúù÷ø$û
ö$÷øúù÷nøü
ý
þ ÿ
!
"# $&% ')(
*,+ -. /0
1,2 34
1,2 54 67
8,9 :;
8,9 <&; =>
?)@
AB CD
ABFED
AB G&D
AB HD
HJI
K&L
Abbildung 5 Migration kleiner Datenelemente (Migration
¼
NM
O P
wird vor
¼
Q
O P
ausgef¨uhrt).
5.3 Große Datenelemente
Da f¨ur die ¨
Ubertragung großer Datenelemente meist mehrere Netzwerkpakete ben¨otigt werden, ist
eine zus¨atzliche Kommunikation akzeptabel. Es ist außerdem sehr rentabel, wenn ein solches Da-
tenelement bei einer Migration nicht zum Zielserver transportiert werden muss, falls dieser es nicht
ben¨otigt. In dem Beispiel aus Abb. 6 wird das Datenelement
Àìë
von der Aktivit¨at
Â
geschrieben und
von
Ý
gelesen (aber nicht von
ê
). Deshalb k¨onnen Kommunikationskosten eingespart werden, wenn
das Datenelement
Àë
direkt vom Server 1 zum Server 3 transportiert wird (ohne den Umweg ¨uber den
Server 2 der Aktivit¨at
ê
). Um dies zu erm¨oglichen, wird im Folgenden ein Verfahren entwickelt, bei
dem nicht nur die redundante ¨
Ubertragung von Datenelementen ausgeschlossen wird, sondern auch
nur solche Datenelemente zu einem Server transportiert werden, die von diesem tats¨achlich ben¨otigt
werden. Dies ist insbesondere deshalb nicht trivial, weil im Falle von bedingten Verzweigungen im
Voraus nicht feststeht, welche Aktivit¨aten der Zielpartition einer Migration tats¨achlich ausgef¨uhrt wer-
den, und damit, welche Datenelemente ben¨otigt werden.
R
S
T
U
V
W
TX
Y
Z\[]_^[]\`
Za[]_^[]\`
Za[]_^[]cb Z\[]_^[]d
Z\[]_^[]ce Z\[]_^[]ce
Z\[]_^[]f
g
h
Z\[]_^[]f
Za[]_^[]f
ijlknmFopq r s ij,knm tvur w xcynmFonp)q r s xzym tvur w
Abbildung 6 ¨
Ubertragung von großen Datenelementen bei Migrationen.
5.3.1 Versenden von Datenelementen
In [Zei99] wird ein Verfahren beschrieben, bei dem – nach Ausf¨uhrung der ”letzten“ Aktivit¨at einer
Partition – ein in dieser Partition geschriebenes Datenelement an die WF-Server derjenigen Partitio-
nen gesendet wird, in denen dieses Datenelement potentiell gelesen wird. In dem Beispiel aus Abb. 6
w¨urde das Datenelement
Àë
also (nach Beendigung der letzten Aktivit¨at
Â
) vom Server 1 zum Server 3
gesendet werden, da es in dessen Partition von
Ý
gelesen wird. Dieses Verfahren weist allerdings einige
Nachteile auf: So lassen sich F¨alle konstruieren, in denen (ebenso wie beim Versenden der Ablaufhi-
storie) redundante ¨
Ubertragungen auftreten. Außerdem ist das Verfahren bei variablen bzw. dynami-
schen Serverzuordnungen nicht einsetzbar. Der Grund daf¨ur ist, dass zum Zeitpunkt des Versendens
eines Datenelements, der Server der im Ablauf evtl. erst viel sp¨ater folgenden Zielpartition noch gar
nicht bekannt ist. Schließlich weist dieses Verfahren ein schlechteres Kommunikationsverhalten auf,
15
als der im nachfolgenden Abschnitt beschriebene Ansatz, da ein Datenelement ausschließlich von
demjenigen WF-Server bezogen werden kann, auf dem es geschrieben wurde.
5.3.2 Anfordern von Datenelementen
Um die gesamte bei der Aktivit¨atenausf¨uhrung vorhandene Zustandsinformation nutzen zu k¨onnen, ist
es vorteilhaft, große Datenelemente bei einer Migration nicht zu versenden, sondern sie anzufordern.
Um dies zu realisieren, sind zwei Verfahren denkbar: (1) Alle von einer Partition ben¨otigten Daten-
elemente werden bei ihrer Aktivierung angefordert. (2) Vor dem Start jeder Aktivit¨ateninstanz werden
die von ihr ben¨otigten Datenelemente angefordert. Im Zusammenhang mit bedingten Verzweigungen
f¨uhrt das 1. Verfahren zu Problemen, da zu Beginn einer Partition evtl. noch nicht feststeht, welche
Datenelemente tats¨achlich ben¨otigt werden. Im Folgenden gehen wir deshalb auf das 2. Verfahren
n¨aher ein.
Eine Aktivit¨ateninstanz kann in ADEPT erst dann aktiviert werden, wenn alle eingehenden Kanten
signalisiert wurden. Zu diesem Zeitpunkt sind alle Vorg¨angeraktivit¨aten beendet. Deshalb kann ein
Datenelement prinzipiell vom WF-Server jeder Aktivit¨at angefordert werden, welche es geschrieben
oder gelesen hat. Im Beispiel aus Abb. 6 kann das von der Aktivit¨at
Á
ben¨otigte Datenelement
Àë
vom Server der Aktivit¨at
Â
und von den Servern der parallel ausgef¨uhrten Aktivit¨aten
Ý
bzw.
Ú
und
{
angefordert werden. Im Allgemeinen k¨onnen die WF-Server, die ¨uber eine bestimmte Version ei-
nes Datenelements verf¨ugen, mit Hilfe der zu diesem Zeitpunkt schon ¨ubertragenen Ablaufhistorie
(siehe Abschnitt 4.2) ermittelt werden. Das Datenelement wird dann von demjenigen WF-Server an-
gefordert, zu dem die beste Netzwerkverbindung besteht. Um diesen Server bestimmen zu k¨onnen,
wird eine ”Kommunikationskosten-Matrix“ vorgegeben, so dass ggf. WAN-Kommunikation vermie-
den werden kann.
Bevor f¨ur eine Aktivit¨ateninstanz Datenelemente angefordert werden, wird das in Abschnitt 4.2 be-
schriebene Verfahren zur Migration von Zustandsinformation f¨ur alle Vorg¨angeraktivit¨aten abge-
schlossen (sofern diese ¨uberhaupt von einem fremden WF-Server kontrolliert wurden). Somit ist
die relevante Ablaufhistorie f¨ur die zu aktivierende Aktivit¨at
|
Ý
~}
Â
z|
Ý
}
bekannt. Mit dem Algorith-
mus 4 kann dann ermittelt werden, welche der von dieser Aktivit¨at noch ben¨otigten Datenelemente
(
tÚ
&
³ÚÀ+Ã\Â
z}
Â'Å
ÚpÆqÚÊ
a}
) von welchem WF-Server angefordert werden sollen. Dazu wird f¨ur je-
des Datenelement
À
dieser Menge die Aktivit¨ateninstanz
bestimmt, von welcher die f¨ur
|
Ý
}J
ÖÂ
|
ÜÝ
~}
g¨ultige Version des Datenelements geschrieben wurde. Die Aktivit¨at
ist also der ”letzte“ Vorg¨anger
von
|
Ý
}J
ÖÂ
|
ÜÝ
~}
, der das Datenelement
À
geschrieben hat. Vom WF-Server dieser Aktivit¨at k¨onnte das
Datenelement nun angefordert werden. Dar¨uber hinaus verf¨ugen auch die Server aller Aktivit¨atenin-
stanzen
N
, welche diese Version des Datenelements gelesen haben, ¨uber dessen aktuellen Wert.
Diese Aktivit¨aten
sind diejenigen, welche lesend auf
À
zugegriffen haben und außerdem im
Kontrollfluss auf
folgen. Das Datenelement
À
kann also vom WF-Server der Aktivit¨at
und von
den Servern der Aktivit¨aten
angefordert werden. Von diesen Servern
Ç
yÝpÚ
,
wird derje-
nige ausgew¨ahlt, der die beste Kommunikationsverbindung zu dem Server aufweist, der
|
Ý
}J
ÖÂ
|
ÜÝ
~}
kontrolliert und damit der Empf¨anger der Datenelemente ist.
Bei dem vorgestellten Verfahren k¨onnten Datenelemente redundant ¨ubertragen werden, wenn durch
einen WF-Server f¨ur mehrere parallele Zweige dasselbe Datenelement angefordert werden w¨urde.
Dies wird verhindert, indem Datenelemente derselben WF-Instanz nicht ¨uberlappend angefordert wer-
den. Dann kann es zu keiner redundanten ¨
Ubertragung mehr kommen, da nur Versionen von Daten-
elementen angefordert werden, die auf dem Zielserver noch nicht vorhanden sind. So wird in dem
16
Algorithmus 4 (Anfordern großer Datenelemente)
input
v
: die aktuell auszuf¨uhrende Aktivit¨ateninstanz
½
à
&¡
ß
~¢
)£
: Menge der großen Datenelemente
¥¤
à
l&¡
ß
~¢
)£
: Menge der auf dem lokalen Server schon vorhandenen Datenelemente
output
¦¨§c)©
ª
£
: Menge von Tupeln
«¬
ã
£®
, die angeben, von welchem Server
£
das große
Datenelement
¬
angefordert werden soll
begin
¦¨§c)©
ª
£°¯²±
;
// Menge der von der Aktivit¨ateninstanz
³v´
gelesenen großen Datenelemente
µ
¶
·
¬
à
&¡
ß
¢
)£¸¯
·
~¬
¿
½
¹
cà
l&¡
ß
~¢
)£º
¬
¿
µ
¬
©
»´v)¼
¹
;
// schon auf dem lokalen Server vorhandene Datenelemente nicht mehr anfordern
µ
¶
·
¬
à
&¡
ß
¢
)£¸¯
µ
~¶
·
¬
à
&¡
ß
~¢
)£
º
½¤
à
&¡
ß
~¢
)£
;
for each
¬
¿
µ
¶
z·
¬
à
&¡
ß
~¢
)£
do
//
¾
hat diejenige Version von
¬
geschrieben, die f¨ur
v³
g¨ultig ist
¾
¯
¹£
á
¿·
¹»
¬
ã
v)¼
;
//
µ
enth¨alt diejenigen Aktivit¨ateninst., die das von
¾
geschriebene Datenelement
¬
gelesen haben
µ
¯
·
˼
¾
¿
ÂÁ
¬
££
¤
£l»¼ÃÄ
¿
µ
¬
¹»
¬
¼
¹
;
//
£
¤
§c
ist der bzgl. der Kommunikationskosten vom lokalen Server aus am g¨unstigsten erreichbare
// Server, von dem
¬
bezogen werden kann
©
¤
zn
£³¯
·
©
ª
»
¾
¼
¹
Å
·
©
ª
¹»Æ¼º
¿
µ
¹
;
w¨ahle
£
¤
§c
¿
©
¤
zn
£
mit
Ç
¤
ß°ß
ÂÈ°»´©
ª
¹»³v´)¼
ã
£
¤
§c)¼
ist minimal;
¦¨§z)©
ª
£É¯Ê¦¨§c)©
ª
n£
Å
·
l«¬
ã
£
¤
§z½
¹
;
end.
Beispiel aus Abb. 6 bei der Aktivierung der Aktivit¨at
{
das Datenelement
Àë
nicht angefordert, weil
es von der Aktivit¨at
Ú
gelesen wurde und deshalb auf diesem Server schon vorhanden ist. Ein Da-
tenelement wird erst bei der Aktivierung derjenigen Aktivit¨at angefordert, welche es liest. Dies hat
den Vorteil, dass es nur dann ¨ubertragen werden muss, wenn diese Aktivit¨at auch tats¨achlich aktiviert
wird. Wird in dem Beispiel aus Abb. 6 der Zweig mit der Aktivit¨at
Á
nicht gew¨ahlt, so ben¨otigt der
Server 5 das Datenelement
Àë
nicht. Bei dem vorgestellten Verfahren wird
Àë
durch den Server 5 dann
auch nicht angefordert. Der Algorithmus 4 wird n¨amlich f¨ur
|
Ý
~}
Â
z|
Ý
}¡Ë
Á
niemals ausgef¨uhrt, da
die Aktivit¨at
Á
nicht aktiviert wird.
Dass große Datenelemente f¨ur jede Aktivit¨ateninstanz einzeln angefordert werden, f¨uhrt zu einer
Verz¨ogerung bei der Aktivierung dieser Aktivit¨ateninstanz. Da die Aktivit¨at zu diesem Zeitpunkt
noch nicht in die Arbeitslisten der Benutzer eingetragen wurde, bemerken sie diese Verz¨ogerung
nicht, weshalb sie unkritisch ist. Ist ein WF-Server, von dem ein Datenelement angefordert werden
soll, f¨ur l¨angere Zeit nicht erreichbar, so kann dies die Verf¨ugbarkeit des WfMS verschlechtern. Um
dem entgegenzuwirken, sollte das Datenelement in diesem Fall (falls m¨oglich) von einem anderen
Server aus der Menge
Ç
yÝpÚ
,
angefordert werden. Da die von einer Aktivit¨at ben¨otigen Datenele-
mente erst bei ihrer Aktivierung angefordert werden, entsteht ein Problem, wenn disconnected Clients
[AGK
Ì
96] verwendet werden. Diese realisieren selbst einen WF-Server und sollen evtl. mehrere Ak-
tivit¨aten ausf¨uhren k¨onnen, ohne mit anderen WF-Servern zu kommunizieren. Deshalb m¨ussen die
Datenelemente, die von den im Disconnected-Modus auszuf¨uhrenden Aktivit¨aten ben¨otigt werden,
schon vor dem Verbindungsabbau angefordert werden. Dabei muss in Kauf genommen werden, dass
auch Datenelemente f¨ur m¨oglicherweise nicht ausgef¨uhrte Aktivit¨aten (z.B. Aktivit¨at
Á
aus Abb. 6)
angefordert werden m¨ussen. Dieser Nachteil tritt aber auch bei klassischen Verfahren zur Migration
17
von Datenelementen auf, dann aber nicht nur im Disconnected-Modus.
6 Diskussion
In dieser Arbeit verzichten wir aus Platzgr¨unden auf einen ausf¨uhrlichen ¨
Uberblick zu verteilten
WfMS (siehe hierzu [BD98, BD99b]). Stattdessen diskutieren wir, wie bzw. welche WF-Daten bei
den anderen in der Literatur diskutierten Verteilungsans¨atzen ¨ubertragen werden und welche Auswir-
kungen dies auf die entstehenden Migrationskosten hat. Auf zentrale WfMS (z.B. Panta Rhei [EG96],
WASA [WHKS98], [DHL91]) und verteilte Ans¨atze, bei denen eine WF-Instanz stets nur von einem
einzigen WF-Server kontrolliert wird (z.B. Exotica/Cluster [AKA
Ì
94], MOBILE [Jab97]), gehen wir
nicht weiter ein, da hier keine Daten¨ubertragung zwischen den WF-Servern stattfindet.
In der Literatur werden verteilte WfMS beschrieben, bei denen die Laufzeitdaten einer WF-Instanz bei
einer Migration vollst¨andig ¨ubertragen werden: So wird bei CodAlf und BPAFrame (siehe [SM96])
eine WF-Instanz als Objekt repr¨asentiert (inkl. internem Zustand, Datenelementen und der Definition
des zugeh¨origen WF-Typs), welches zwischen den WF-Servern migriert. Auch bei INCAS [BMR96]
wurde ein solcher Objektmigrationsansatz gew¨ahlt, allerdings erfolgt die WF-Definition hier durch
Regeln. Da zus¨atzlich zu den schon genannten Daten auch noch die alten Versionen der Datenele-
mente (vgl. Datenhistorie aus Abschnitt 5.1) im migrierten Objekt enthalten sind, muss bei jeder
Migration eine sehr große Datenmenge ¨ubertragen werden, was zu einem extrem hohen Kommu-
nikationsaufkommen f¨uhren kann. Es gibt aber auch Ans¨atze, die nicht nur bei Migrationen Daten
¨ubertragen: Bei Exotica/FMQM [AMG
Ì
95] werden die von einer Aktivit¨ateninstanz geschriebenen
Datenelemente an diejenigen Systemkomponenten versendet, die Aktivit¨ateninstanzen kontrollieren,
welche diese Datenelemente lesen (vgl. ”Versenden von Datenelementen“ in Abschnitt 5.3.1). Die
verteilte WF-Ausf¨uhrung in MENTOR [WWK
Ì
97] basiert auf der Partitionierung von State- und
Activitycharts. Um eine zum zentralen Fall ¨aquivalente verteilte Ausf¨uhrung garantieren zu k¨onnen,
m¨ussen, nach der Beendigung von parallel ausgef¨uhrten Aktivit¨aten, Synchronisationsnachrichten und
Datenelemente ausgetauscht werden. Da dies einen großen Kommunikationsaufwand erfordert, wer-
den in [MWW
Ì
98] Verfahren vorgestellt, mit denen dieser Aufwand reduziert werden kann. Es wird
also nicht das Ziel verfolgt, den Kommunikationsaufwand bei Migrationen zu reduzieren, sondern der
Aufwand f¨ur die Synchronisation der WF-Server bei parallel ausgef¨uhrten Aktivit¨aten wird begrenzt.
Eine solche Synchronisation der WF-Abarbeitung ist in ADEPT nicht notwendig, da die Bearbeitung
paralleler Zweige unabh¨angig voneinander fortschreiten kann.
Einige Ans¨atze verwenden keine Partitionierung und Migrationen im eigentlichen Sinn, sondern star-
ten Subprozesse auf einem entfernten WF-Server. Bei einer Erweiterung von MOBILE [SNS99] wird
zur Ausf¨uhrungszeit der WF-Instanzen entschieden, welcher WF-Server einen Sub-WF kontrollieren
soll. Auch WIDE [CGP
Ì
96] erreicht Verteilung durch die entfernte Ausf¨uhrung von Subprozessen.
Diese Vorgehensweise hat den Vorteil, dass an einen Sub-WF nur die von ihm potentiell ben¨otig-
ten Daten ¨ubergeben werden m¨ussen, anstatt dass alle Daten der WF-Instanz migriert werden. Dies
f¨uhrt zu einem ¨ahnlichen Effekt, wie bei den in dieser Arbeit vorgestellten Optimierungen. Eine aus-
schließlich auf Subprozessen basierende Verteilung wurde f¨ur ADEPT allerdings nicht gew¨ahlt, weil
die WF-Kontrolle nach Beendigung jedes Sub-WF zum Server des Super-WF zur¨uckkehren w¨urde
(auch wenn dies eigentlich nicht erw¨unscht ist) und die Ver¨anderung einer Verteilung aufwendiger
w¨are (weil dazu eine andere Aufteilung in Subprozesse ben¨otigt wird).
Bei WIDE [CGP
Ì
96] werden Datenelemente nicht direkt an andere WF-Server ¨ubergeben, sondern
nur Referenzen auf sie. Diese Vorgehensweise ist h¨aufig bei solchen Systemen zu finden, die wie
18
WIDE auf einer objektorientierten Systeminfrastruktur (z.B. CORBA) basieren, da diese den ort-
stransparenten Zugriff auf die eigentlichen Datenelemente erlaubt. Bei METEOR
í
[DKM
Ì
97] steu-
ert ein sog. ”Taskmanager“ die Ausf¨uhrung eines bestimmten Aktivit¨atentyps und signalisiert den
Taskmanagern der Nachfolgeraktivit¨aten deren Beendigung. Zugriffe auf Datenelemente erfolgen
ortstransparent durch CORBA. Dasselbe gilt f¨ur die Systeme METUFlow [GAC
Ì
97], MOKASSIN
[GJS
Ì
99], und WASA
í
[Wes99], bei denen eine Aktivit¨ateninstanz jeweils durch ein CORBA-Objekt
repr¨asentiert wird. Da bei all diesen Ans¨atzen lediglich Referenzen auf die Datenelemente migriert
werden, wird zwar die Belastung des WfMS reduziert, aber nicht die des Kommunikationssystems.
Ein großes Datenelement wird dann nicht nur einmal (durch eine Migration) in das Teilnetz trans-
portiert, in dem es ben¨otigt wird, sondern muss bei jedem einzelnen Zugriff eines Aktivit¨atenpro-
gramms ¨ubertragen werden. Dies f¨uhrt, insbesondere in einer weitr¨aumig verteilten Umgebung, zu
einer h¨oheren Belastung des Kommunikationssystems.
Eine Fragestellung, die mit der Migration von Zustandsinformation in einem verteilten WfMS ver-
wandt ist, wird von CoAct [WK96] untersucht: Mehrere Personen ver¨andern verteilt und parallel
dasselbe Dokument, so dass mehrere g¨ultige ¨
Anderungshistorien entstehen. Diese werden (wie die
Ablaufhistorien in ADEPT) wieder zu einer einzigen Historie zusammengef¨uhrt (sog. History Merge).
Ebenso wie bei ADEPT wird dabei die jeweilige Semantik der Historieneintr¨age ausgenutzt.
Zusammenfassend l¨asst sich feststellen, dass in der Literatur zahlreiche Ans¨atze f¨ur verteiltes WF-
Management vorgestellt werden. Allerdings werden bei keinem von ihnen die bei Migrationen an-
fallenden Kommunikationskosten – wie bei den in diesem Beitrag vorgestellten Verfahren – mini-
miert. Die Ans¨atze ignorieren weitgehend die in einem verteilten WfMS anfallenden hohen Kom-
munikationskosten. Manche der Ans¨atze treffen aber Entwurfsentscheidungen, die auch Einfluss auf
die entstehenden Kommunikationskosten haben: (1) Bei Migrationen werden nur Referenzen auf Da-
tenelemente ¨ubergeben. Dies f¨uhrt zu den in diesem Abschnitt schon diskutierten Nachteilen. (2) Bei
Migrationen wird keine explizite Zustandsinformation ¨ubergeben (es werden lediglich die Nachfolger-
aktivit¨aten ¨uber die Beendigung der Aktivit¨ateninstanz informiert). Dies f¨uhrt dazu, dass keine Infor-
mation ¨uber beendete Aktivit¨aten verf¨ugbar ist, was die Realisierung fortschrittlicher WF-Konzepte,
wie abh¨angige Bearbeiterzuordnungen und die ¨
Uberwachung von Zeitbedingungen, beeintr¨achtigt.
7 Zusammenfassung
Durch die Verwendung von WfMS kann die Entwicklung von unternehmensweiten und -¨ubergrei-
fenden prozessorientierten Anwendungssystemen erheblich erleichtert werden, da der Programmcode
einzelner Anwendungsfunktionen von der Prozesslogik getrennt wird. Dadurch wird die Entwicklung
von solchen Anwendungssystemen mit vertretbarem Aufwand ¨uberhaupt erst m¨oglich. Bei zahlrei-
chen Anwendungen muss die WF-Steuerung verteilt realisiert werden, weil ein zentraler WF-Server
¨uberlastet w¨are. Abgesehen davon lassen sich durch eine geeignete Verteilung der WF-Ausf¨uhrung
die Kommunikationskosten reduzieren, indem ein WF-Server ”nahe“ bei den Bearbeitern der aktu-
ellen Aktivit¨at gew¨ahlt wird [BD97, BD99a, BD00]. Allerdings entstehen durch die bei der verteil-
ten WF-Ausf¨uhrung notwendigen Migrationen gewisse Kommunikationskosten, die reduziert werden
m¨ussen, um ein effizientes verteiltes WF-Management zu erm¨oglichen.
In diesem Beitrag wurden Verfahren vorgestellt, mit denen das bei Migrationen zu ¨ubertragende Da-
tenvolumen drastisch reduziert werden kann. Mit diesen Verfahren wird sowohl die redundante ¨
Uber-
tragung interner Zustandsinformation, als auch der Parameterdaten von Aktivit¨atenprogrammen ver-
hindert. Kleine Datenelemente werden anders behandelt als große, welche stets von demjenigen WF-
19
Server bezogen werden, zu dem die beste Kommunikationsverbindung besteht. Die Verfahren sind
f¨ur statische und f¨ur variable Serverzuordnungen gleichermaßen geeignet und ber¨ucksichtigen alle
Konstrukte des ADEPT-Modells (z.B. bedingte und parallele Verzweigungen, Schleifen). Sie sollten
deshalb auch auf andere Modelle ¨ubertragbar sein. Insbesondere im Zusammenhang mit Schleifen
kann die Belastung des dem WfMS zugrunde liegenden Kommunikationssystems drastisch reduziert
werden, weil mehrere Instanzen einer Aktivit¨at vom selben Server kontrolliert werden, so dass bereits
viel Information lokal vorhanden ist. Allerdings haben die vorgestellten Optimierungen auch ihren
Preis: Die Anwendung der vorgestellten Verfahren erfordert zus¨atzlichen Rechenaufwand. Sie soll-
ten deshalb nur in Umgebungen eingesetzt werden, in denen dieser Aufwand durch die Entlastung
des Kommunikationssystems gerechtfertigt wird. F¨ur weitr¨aumig verteilte Anwendungen ist dies si-
cherlich der Fall. Die vorgestellten Verfahren reduzieren die zu ¨ubertragende Datenmenge durch die
Nutzung von Wissen ¨uber schon transferierte Daten. Dadurch l¨asst sich eine deutlich st¨arkere Re-
duktion der Datenmenge erreichen, als mit klassischen Komprimierungsverfahren. Selbstverst¨andlich
kann mit diesen die zu ¨ubertragende Datenmenge aber noch weiter reduziert werden.
Die in diesem Beitrag beschriebenen Verfahren wurden in dem Prototypen ADEPT
Í
ÍÏ
ÎnÏnÐ
òÍ
Í
[HRB
Ì
00] implementiert. ADEPT
Í
ÍÏ
ÎnÏnÐ
Í
Í
wurde auf der CeBIT’2000, der EDBT’2000 und der
BIS’2000 demonstriert. Durch die Implementierung konnte die Machbarkeit der Verfahren gezeigt
und ihr Zusammenspiel mit andern Konzepten (z.B. dynamischen WF- ¨
Anderungen) studiert werden.
Anhand der tats¨achlich bei Migrationen einer WF-Instanz ¨ubertragenen Datenmenge ist außerdem zu
erkennen, dass die Belastung des Kommunikationssystems deutlich reduziert werden kann.
Danksagung: Wir danken Clemens Hensinger und Jochen Zeitler f¨ur die anregenden Diskussionen.
Literatur
[AGK
Ì
96] G. Alonso, R. G¨unth¨or, M. Kamath, D. Agrawal, A. El Abbadi und C. Mohan: Exo-
tica/FMDC: A Workflow Management System for Mobile and Disconnected Clients.
Distributed and Parallel Databases, 4(3):229–247, Juli 1996.
[AKA
Ì
94] G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. G¨unth¨or und C. Mohan: Failure
Handling in Large Scale Workflow Management Systems. Technischer Bericht RJ9913,
IBM Almaden Research Center, November 1994.
[AMG
Ì
95] G. Alonso, C. Mohan, R. G¨unth¨or, D. Agrawal, A. El Abbadi und M. Kamath: Exo-
tica/FMQM: A Persistent Message-Based Architecture for Distributed Workflow Ma-
nagement. In: Proc. IFIP Working Conf. on Information Systems for Decentralized
Organisations, Trondheim, August 1995.
[BD97] T. Bauer und P. Dadam: A Distributed Execution Environment for Large-Scale Workflow
Management Systems with Subnets and Server Migration. In: Proc. 2nd IFCIS Conf. on
Cooperative Information Systems, S. 99–108, Kiawah Island, SC, Juni 1997.
[BD98] T. Bauer und P. Dadam: Architekturen f¨
ur skalierbare Workflow-Management-Systeme –
Klassifikation und Analyse. Ulmer Informatik-Berichte 98-02, Universit¨at Ulm, Fakult¨at
f¨ur Informatik, Januar 1998.
20
[BD99a] T. Bauer und P. Dadam: Efficient Distributed Control of Enterprise-Wide and Cross-
Enterprise Workflows. In: Proc. Workshop Enterprise-wide and Cross-enterprise Work-
flow Management: Concepts, Systems, Applications, 29. Jahrestagung der GI, S. 25–32,
Paderborn, Oktober 1999.
[BD99b] T. Bauer und P. Dadam: Verteilungsmodelle f¨
ur Workflow-Management-Systeme – Klas-
sifikation und Simulation. Informatik Forschung und Entwicklung, 14(4):203–217, De-
zember 1999.
[BD00] T. Bauer und P. Dadam: Efficient Distributed Workflow Management Based on Variable
Server Assignments. In: Proc. 12th Conf. on Advanced Information Systems Enginee-
ring, S. 94–109, Stockholm, Juni 2000.
[BF99] E. Bertina und E. Ferrari: The Specification and Enforcement of Authorization Cons-
traints in Workflow Management Systems. ACM Transactions on Information System
Security, 2(1):65–104, Februar 1999.
[BMR96] D. Barbar´a, S. Mehrotra und M. Rusinkiewicz: INCAs: Managing Dynamic Workflows
in Distributed Environments. Journal of Database Management, Special Issue on Mul-
tidatabases, 7(1):5–15, 1996.
[CGP
Ì
96] F. Casati, P. Grefen, B. Pernici, G. Pozzi und G. S´anchez: WIDE: Workflow Model and
Architecture. CTIT Technical Report 96-19, University of Twente, 1996.
[DHL91] U. Dayal, M. Hsu und R. Ladin: A Transactional Model for Long-Running Activities.
In: Proc. 17th Int. Conf. on Very Large Data Bases, S. 113–122, Barcelona, September
1991.
[DKM
Ì
97] S. Das, K. Kochut, J. Miller, A. Sheth und D. Worah: ORBWork: A Reliable Distributed
CORBA-based Workflow Enactment System for METEOR
í
. Technical Report #UGA-
CS-TR-97-001, Department of Computer Science, University of Georgia, Februar 1997.
[DKR
Ì
95] P. Dadam, K. Kuhn, M. Reichert, T. Beuter und M. Nathe: ADEPT: Ein integrierender
Ansatz zur Entwicklung flexibler, zuverl¨
assiger kooperierender Assistenzsysteme in kli-
nischen Anwendungsumgebungen. In: Proc. GI/SI-Jahrestagung, S. 677–686, Zurich,
September 1995.
[DRK00] P. Dadam, M. Reichert und K. Kuhn: Clinical Workflows - The Killer Application for
Process-oriented Information Systems? In: Proc. 4th Int. Conf. on Business Information
Systems, S. 36–59, Posen, April 2000.
[EG96] J. Eder und H. Groiss: Ein Workflow-Managementsystem auf der Basis aktiver Daten-
banken. In: J. Becker, G. Vossen (Herausgeber): Gesch¨
aftsprozeßmodellierung und
Workflow-Management. Int. Thomson Publishing, 1996.
[GAC
Ì
97] E. Gokkoca, M Altinel, I. Cingil, E.N. Tatbul, P. Koksal und A. Dogac: Design and
Implementation of a Distributed Workflow Enactment Service. In: Proc. 2nd IFCIS
Conf. on Cooperative Information Systems, S. 89–98, Kiawah Island, SC, Juni 1997.
21
[GJS
Ì
99] B. Gronemann, G. Joeris, S. Scheil, M. Steinfort und H. Wache: Supporting Cross-
Organizational Engineering Processes by Distributed Collaborative Workflow Mana-
gement - The MOKASSIN Approach. In: Proc. 2nd Symposium on Concurrent Mulit-
disciplinary Engineering, 3rd Int. Conf. on Global Engineering Networking, Bremen,
September 1999.
[Gri97] M. Grimm: ADEPT
Ò
ÒÑÔÓ³Õ
: Temporale Aspekte in flexiblen Workflow-Management-Sys-
temen. Diplomarbeit, Universit¨at Ulm, Fakult¨at f¨ur Informatik, 1997.
[HRB
Ì
00] C. Hensinger, M. Reichert, T. Bauer, T. Strzeletz und P. Dadam: ADEPT
Í
ÍÏ
ÎnÏnÐ
Í
Í
- Ad-
vanced Workflow Technology for the Efficient Support of Adaptive, Enterprise-wide Pro-
cesses. In: 7th Int. Conf. on Extending Database Technology, Software Demonstrations
Track, S. 29–30, Konstanz, M¨arz 2000.
[Jab97] S. Jablonski: Architektur von Workflow-Mangement-Systemen. Informatik Forschung
und Entwicklung, Themenheft Workflow-Management, 12(2):72–81, 1997.
[KAGM96] M. Kamath, G. Alonso, R. G¨unth¨or und C. Mohan: Providing High Availability in Very
Large Workflow Management Systems. In: Proc. 5th Int. Conf. on Extending Database
Technology, S. 427–442, Avignon, M¨arz 1996.
[KDB98] M. Klein, C. Dellaroca und A. Bernstein (Herausgeber): Workshop Towards Adaptive
Workflow Systems, Conf. on Computer-Supported Cooperative Work, Seattle, WA, No-
vember 1998.
[Kub98] M. Kubicek: Organisatorische Aspekte in flexiblen Workflow-Management-Systemen.
Diplomarbeit, Universit¨at Ulm, Fakult¨at f¨ur Informatik, 1998.
[Ley97] F. Leymann: Transaktionsunterst¨
utzung f¨
ur Workflows. Informatik Forschung und Ent-
wicklung, Themenheft Workflow-Management, 12(2):82–90, 1997.
[LR00] F. Leymann und D. Roller: Production Workflow - Concepts and Techniques. Prentice
Hall, 2000.
[MO99] O. Marjanovic und M. Orlowska: On Modeling and Verification of TemporalConstraints
in Production Workflows. Knowledge and Information Systems, 1(2):157–192, Mai
1999.
[MWW
Ì
98] P. Muth, D. Wodtke, J. Weißenfels, A. Kotz-Dittrich und G. Weikum: From Centralized
Workflow Specification to Distributed Workflow Execution. Journal of Intelligent In-
formation Systems, Special Issue on Workflow Management Systems, 10(2):159–184,
M¨arz/April 1998.
[RD98] M. Reichert und P. Dadam: ADEPT
ÏnÐÖÕ)×
– Supporting Dynamic Changes of Workflows
Without Losing Control. Journal of Intelligent Information Systems, Special Issue on
Workflow Management Systems, 10(2):93–129, M¨arz/April 1998.
[RS95] A. Reuter und F. Schwenkreis: ConTracts - A Low-Level Mechanism for Building
General-Purpose Workflow Management-Systems. IEEE Computer Society, Bulletin
of the Technical Committee on Data Engineering, 18(1):4–10, M¨arz 1995.
22
[SK97] A. Sheth und K. J. Kochut: Workflow Applications to Research Agenda: Scalable and
Dynamic Work Coordination and Collaboration Systems. In: Proc. NATO Advanced
Study Institute on Workflow Management Systems and Interoperability, S. 12–21, Istan-
bul, August 1997.
[SM96] A. Schill und C. Mittasch: Workflow Management Systems on Top of OSF DCE and
OMG CORBA. Distributed Systems Engineering, 3(4):250–262, Dezember 1996.
[SNS99] H. Schuster, J. Neeb und R. Schamburger: A Configuration Management Approach for
Large Workflow Management Systems. In: Proc. Int. Joint Conf. on Work Activities
Coordination and Collaboration, San Francisco, Februar 1999.
[Wes99] M. Weske: Workflow Management Through Distributed and Persistent CORBA Work-
flow Object. In: Proc. 11th Int. Conf. on Advanced Information Systems Engineering,
Heidelberg, 1999.
[WHKS98] M. Weske, J. H¨undling, D. Kuropka und H. Schuschel: Objektorientierter Entwurf ei-
nes flexiblen Workflow-Management-Systems. Informatik Forschung und Entwicklung,
13(4):179–195, 1998.
[WK96] J. W¨asch und W. Klas: History Merging as a Mechanism for Concurrency Control in
Cooperative Environments. In: Proc. 6th Int. Workshop on Research Issues in Data
Engineering – Interoperability of Nontraditional Database Systems, S. 76–85, New Or-
leans, Februar 1996.
[WMC99] Workflow Management Coalition: Terminology & Glossary, Document Number
WFMC-TC-1011, Document Status - Issue 3.0, Februar 1999.
[WWK
Ì
97] G. Weikum, D. Wodtke, A. Kotz-Dittrich, P. Muth und J. Weißenfels: Spezifikation, Ve-
rifikation und verteilte Ausf¨
uhrung von Workflows in MENTOR. Informatik Forschung
und Entwicklung, Themenheft Workflow-Management, 12(2):61–71, 1997.
[Zei99] J. Zeitler: Integration von Verteilungskonzepten in ein adaptives Workflow-Manage-
ment-System. Diplomarbeit, Universit¨at Ulm, Fakult¨at f¨ur Informatik, 1999.
23
