scieee Science in your language
[en] (orig)
Adaptives und verteiltes Workflow-Management
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
Die Unterst¨
utzung unternehmensweiter und -¨
ubergreifender Gesch¨
aftsprozesse stellt f¨
ur ein Workflow-Ma-
nagement-System (WfMS) eine besondere Herausforderung dar. So sind Skalierbarkeit bei hoher Last und die
M¨
oglichkeit, zur Ausf¨
uhrungszeit eines Workflows (WF) dynamisch vom vormodellierten Ablauf abweichen zu
k¨
onnen, unbedingt erforderlich, damit ein WfMS f¨
ur ein breites Spektrum von Anwendungen eingesetzt werden
kann. Allerdings wurden diese beiden Aspekte in der WF-Literatur bisher weitestgehend getrennt betrachtet.
Dies ist ¨
außerst problematisch, da mit ihnen entgegengesetzte Anforderungen verbunden sind. So wird zur Er-
zielung einer guten Skalierbarkeit angestrebt, dass eine WF-Instanz von mehreren WF-Servern m¨
oglichst
unabh¨
angig voneinander kontrolliert werden kann, wohingegen f¨
ur dynamische WF- ¨
Anderungen eine (lo-
gisch) zentrale Kontrollinstanz ben¨
otigt wird, die den aktuellen und globalen Zustand der WF-Instanz kennt.
In diesem Beitrag werden Verfahren vorgestellt, die es erlauben, dynamische ¨
Anderungen in einem verteilten
WfMS durchzuf¨
uhren. Besonders bemerkenswert ist dabei, dass es gelungen ist, die volle aus dem zentralen
Fall bekannte Funktionalit¨
at zu realisieren, und trotzdem ein bzgl. der Kommunikationskosten ¨
außerst g¨
unsti-
ges Verhalten zu erreichen.
1 Einleitung
WfMS [JBS97, LR00, Obe96] erm¨oglichen die rechnerunterst¨utzte Ausf¨uhrung von Gesch¨aftspro-
zessen in einer verteilten Systemumgebung. Der entscheidende Vorteil solcher Systeme ist, dass sie
helfen, große vorgangsorientierte Anwendungssysteme ¨uberschaubarer zu gestalten. Dazu wird der
applikationsspezifische Code der verwendeten Anwendungen von der Ablauflogik des Gesch¨aftspro-
zesses getrennt. Anstelle eines großen monolithischen Programmpakets erh¨alt man nun einzelne Ak-
tivit¨aten, welche die Anwendungsprogramme repr¨asentieren. Ihre Ablauflogik wird in einer separaten
Kontrollflussdefinition festgelegt, welche die Ausf¨uhrungsreihenfolge (Sequenz, Verzweigung, Par-
allelit¨at, Schleifen) der einzelnen Aktivit¨aten bestimmt. Das WfMS sorgt zur Ausf¨uhrungszeit daf¨ur,
dass nur solche Aktivit¨aten einer WF-Instanz bearbeitet werden k¨onnen, die der Ablauflogik zufolge
zur Ausf¨uhrung anstehen. Diese werden in die Arbeitslisten autorisierter Bearbeiter eingef¨ugt. Wel-
che Benutzer zur Bearbeitung einer bestimmten Aktivit¨at autorisiert sind, wird meist durch eine Rolle
festgelegt, die auch den entsprechenden Bearbeitern zugeordnet ist.
Die Funktionalit¨at heutiger WfMS ist allerdings f¨ur viele der in der Praxis vorkommenden prozess-
orientierten Anwendungen nicht ausreichend. Ein Mangel ist insbesondere die unzureichende Ska-
lierbarkeit bei hoher Last. Der Forderung nach Skalierbarkeit kommen wir in ADEPT1dadurch nach,
dass ein WfMS aus mehreren WF-Servern besteht. Um ein g¨unstiges Kommunikationsverhalten zu
erzielen, kann eine WF-Instanz abschnittsweise von verschiedenen WF-Servern kontrolliert werden
1ADEPT steht f¨ur Application Development Based on Encapsulated Pre-Modeled Process Templates.
Ulmer Informatik-Berichte, Nr. 2000-10, September 2000
[BD97, BD00]. Eine ebenfalls erkannte Schwachstelleexistierender WfMS ist ihre unzureichende Ad-
aptivit¨at. In ADEPT ist es m¨oglich, eine laufende WF-Instanz bei Bedarf (z.B. in Ausnahmesituatio-
nen) dynamisch zu ver¨andern, so dass von dem vorgesehenen Ablauf abgewichen wird. Im Gegensatz
zu vielen anderen Ans¨atzen wird dabei die Konsistenz der WF-Instanz auch nach der ¨
Anderung garan-
tiert, d.h. Laufzeitfehler (z.B. Verklemmungen in Folge zyklischer Reihenfolgebeziehungen) sind aus-
geschlossen [RD98, Rei00]. In den bisherigen Ver¨offentlichungen zu ADEPT haben wir, ebenso wie
die anderen uns bekannten Gruppen, verteilte WF-Ausf¨uhrung und Adaptivit¨at nur getrennt betrachtet.
Das Zusammenspiel dieser beiden f¨ur ein WfMS essentiellen Aspekte wurde dabei nicht systematisch
untersucht. Dies ist problematisch, weil mit den beiden Aspekten entgegengesetzte Anforderungen
verbunden sind: Zur Durchf¨uhrung einer dynamischen ¨
Anderung wird eine zentrale Kontrollinstanz
ben¨otigt [RD98]. Die Existenz einer solchen konterkariert aber die durch verteilte WF-Ausf¨uhrung
erzielten Errungenschaften, da eine zentrale Komponente die Verf¨ugbarkeit des WfMS verschlech-
tert und den Kommunikationsaufwand erh¨oht. Ein Grund daf¨ur ist, dass sie ¨uber jede ¨
Anderung des
Zustands jeder WF-Instanz informiert werden muss. Der Zustand der zu modifizierenden WF-Instanz
wird n¨amlich ben¨otigt, um entscheiden zu k¨onnen, ob eine geplante ¨
Anderung ¨uberhaupt durchf¨uhrbar
ist [RD98].
Das Ziel des vorliegenden Beitrags ist es, dynamische ¨
Anderungen in einem verteilten WfMS zu
erm¨oglichen. Dabei soll die Adaptivit¨at gegen¨uber der zentralen WF-Ausf¨uhrung nicht eingeschr¨ankt
sein, d.h. jede f¨ur den zentralen Fall erlaubte dynamische ¨
Anderung muss im verteilten Fall weiterhin
zul¨assig sein. Die Unterst¨utzung solcher dynamischer Abweichungen darf die Effizienz der verteilten
WF-Steuerung aber keinesfalls beeintr¨achtigen. Insbesondere soll bei der normalen WF-Ausf¨uhrung
kein großer zus¨atzlicher Kommunikationsaufwand notwendig werden. Außerdem sollen in dem an-
gestrebten System (verteilte) dynamische ¨
Anderungen auf m¨oglichst effiziente Art und Weise durch-
gef¨uhrt werden k¨onnen.
Zur Behandlung dieser Anforderungen ist zu untersuchen (siehe auch [RBD99]), mit welchen Servern
des WfMS eine dynamische ¨
Anderung synchronisiert werden muss. Vermutlich m¨ussen dabei zumin-
dest die aktuell an der WF-Instanz beteiligten Server einbezogen werden, da sie die resultierende
Struktur und den Zustand der WF-Instanz (den sog. Ausf¨uhrungsgraphen) ben¨otigen, um diese kor-
rekt steuern zu k¨onnen. Deshalb wird ein Verfahren ben¨otigt, mit dem die Menge dieser Server ohne
großen Aufwand ermittelt werden kann. Außerdem ist zu kl¨aren, wie diesen und anderen Servern der
durch die ¨
Anderung resultierende Ausf¨uhrungsgraph der WF-Instanz ¨ubermittelt werden kann. Dabei
ist essentiell, dass kein inakzeptabel großer Kommunikationsaufwand verursacht wird.
Im nachfolgenden Abschnitt wird auf Grundlagen der verteilten WF-Ausf¨uhrung und der dynami-
schen ¨
Anderungen in ADEPT eingegangen, die f¨ur das weitere Verst¨andnis notwendig sind. Der Ab-
schnitt 3 besch¨aftigt sich mit der Durchf¨uhrung von dynamischen ¨
Anderungen in einem verteilten
WfMS. In Abschnitt 4 wird dann erl¨autert, wie auch zuvor ver¨anderte WF-Instanzen effizient gesteu-
ert werden k¨onnen. Eine Einordnung der beschriebenen Verfahren in die WF-Literatur findet sich in
Abschnitt 5. Der Beitrag schließt mit einer Zusammenfassung und einem Ausblick auf zuk¨unftige
Arbeiten.
2 Grundlagen
Im ADEPT-Projekt [DKR
95, DRK00, RD98] betrachten wir Anforderungen, die sich bei der Un-
terst¨utzung unternehmensweiter und -¨ubergreifender WF-basierter Anwendungen ergeben. Im vor-
2
liegenden Abschnitt fassen wir die hieraus hervorgegangenen Konzepte zur verteilten WF-Steuerung
und zu dynamischen WF- ¨
Anderungen kurz zusammen.
2.1 Verteilte Workflow-Ausf¨uhrung in ADEPT
Aufgrund der großen Anzahl von Benutzern und gleichzeitig aktiven WF-Instanzen resultiert in un-
ternehmensweiten Anwendungen eine sehr hohe Last.2Diese kann dazu f¨uhren, dass Komponenten
des WfMS ¨uberlastet werden. Deshalb wird in ADEPT

, der verteilten Variante von ADEPT,
eine WF-Instanz nicht nur von einem einzigen WF-Server kontrolliert, sondern sie wird ggf. partitio-
niert und abschnittsweise von verschiedenen Servern gesteuert [BD97] (vgl. Abb. 1). Wird bei der
Ausf¨uhrung von Instanzen dieses WF-Typs das Ende einer Partition erreicht, so wird die Kontrolle
¨uber diesen WF an den n¨achsten WF-Server weitergereicht (Migration). Damit dies m¨oglich ist, muss
eine Beschreibung des Zustands der WF-Instanz zu diesem Server transportiert werden. Um unn¨oti-
gen Kommunikationsaufwand zwischen WF-Servern zu vermeiden, erfolgt in ADEPT die Steuerung
von parallelen Zweigen unabh¨angig voneinander. Im Beispiel aus Abb. 1 weiß der WF-Server

, der
gerade die Aktivit¨at
kontrolliert, nicht, wie weit die Bearbeitung im oberen Zweig der Parallelit¨at
fortgeschritten ist. Dies hat den Vorteil, dass keine Synchronisation zwischen WF-Servern notwendig
ist, die Aktivit¨aten paralleler Zweige steuern.
  !#"%$
  !#"'&
  !#")(
*
+ ,
- .
/
021#34)56 7#398:1#0<;3=1#6 6 >6 ?<@A@
8:1#0<;3=1#6 6 >6 ?2@A@)?0CBEDGF H#3=5C;F 1#0
I1#0KJML;F IF ;=NC;POQ0C5R2SUT
VPWXPY
ZP[
\C]
^C_
`#a
bKcd e
fUgih j
kKlnm o
pKqsr t
uAvxwy z{}| ~
uAvxwy ~
Abbildung 1 Partitionierung eines WF-Graphen und verteilte WF-Ausf¨uhrung.
Die Partitionierung von WF-Graphen und die verteilte WF-Steuerung werden auch in anderen
Ans¨atzen verwendet (z.B. [CGP
96, MWW
98]). Wir verfolgen in ADEPT zus¨atzlich das Ziel, die
Kommunikationskosten zu minimieren. Konkrete Erfahrungen mit existierenden WfMS haben ge-
zeigt, dass zwischen dem WF-Server und seinen Clients sehr viel kommuniziert wird und zum Teil
auch große Datenmengen ausgetauscht werden m¨ussen. Dies kann dazu f¨uhren, dass das Kommunika-
tionssystem ¨uberlastet wird. Deshalb werden in ADEPT die WF-Server der Aktivit¨aten so festgelegt,
dass der Gesamtkommunikationsaufwand minimiert wird. Dazu wird der WF-Server f¨ur eine Akti-
vit¨at in der Regel so gew¨ahlt, dass er im Teilnetz der Mehrzahl ihrer potentiellen Bearbeiter liegt.
Dadurch wird in vielen F¨allen eine teilnetz¨ubergreifende Kommunikation zwischen dem WF-Server
und seinen Clients vermieden. Außerdem werden die Antwortzeiten verbessert und die Verf¨ugbar-
keit erh¨oht, da bei der Ausf¨uhrung von Aktivit¨aten kein Gateway oder WAN (Wide Area Network)
zwischengeschaltet ist.
Bei diesem Ansatz wird also bereits zur Modellierungszeit eine (statische) Zuordnung von WF-
Servern zu den Aktivit¨aten vorgenommen. Es gibt aber auch F¨alle, in denen diese Vorgehensweise
nicht ausreichend ist, um gute Resultate zu erzielen. Dies ist der Fall, wenn bei der WF-Definition
abh¨
angige Bearbeiterzuordnungen (z.B. "selber Bearbeiter wie Aktivit¨at
") verwendet werden. Hier
h¨angen die potentiellen Bearbeiter einer Aktivit¨at vom Bearbeiter einer Vorg¨angeraktivit¨at ab. Da sich
2In [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.
3
Advertisement
die Menge der potentiellen Bearbeiter einer solchen Aktivit¨at erst im Verlauf der WF-Ausf¨uhrung er-
gibt, ist es vorteilhaft, ihren WF-Server erst zur Ausf¨uhrungszeit festzulegen. Der Server kann dann
in einem f¨ur die entsprechenden Bearbeiter g¨unstigen Teilnetz gew¨ahlt werden. Zu diesem Zweck
wurde f¨ur ADEPT
P
das Konzept der variablen Serverzuordnungen [BD99a, BD00] ent-
wickelt. Hierbei handelt es sich um Ausdr¨ucke (z.B. "Server im Teilnetz des Bearbeiters der Aktivit¨at
"), die zur Ausf¨uhrungszeit der WF-Instanz ausgewertet werden. Dadurch wird derjenige WF-Server
ermittelt, der die zugeh¨orige Aktivit¨ateninstanz kontrollieren soll.
2.2 Dynamische ¨
Anderungen
Um flexibel auf Ausnahmesituationen reagieren zu k¨onnen, muss der Ausf¨uhrungsgraph einer WF-
Instanz zur Ausf¨uhrungszeit modifiziert werden k¨onnen. Das ADEPT
P
-Kalk¨ul bietet z.B. die
M¨oglichkeit, Aktivit¨aten dynamisch einzuf¨ugen oder zu l¨oschen. Dabei sind auch sehr komplexe Ope-
rationen realisierbar, wie das Einf¨ugen einer Aktivit¨at, die erst nach der Beendigung einer beliebigen
Menge von Aktivit¨at ausf¨uhrbar sein soll und vor dem Starten einer anderen Menge von Aktivit¨aten
beendet sein muss. Auf die Verfahren zur Durchf¨uhrung einer solchen dynamischen ¨
Anderung wird
hier nicht n¨aher eingegangen, da dies f¨ur das weitere Verst¨andnis dieses Beitrags nicht notwendig ist
(f¨ur Details siehe [RD98, Rei00]).
Das WfMS bestimmt aus der Spezifikation einer ¨
Anderung automatisch eine Menge von Basisopera-
tionen (z.B. Aktivit¨at einf¨ugen, Kante einf¨ugen), die auf den Ausf¨uhrungsgraphen der entsprechenden
WF-Instanz angewandt werden. Wie in Abb. 2c dargestellt, werden diese Basisoperationen zusammen
mit der Spezifikation der ¨
Anderung in einer sog. ¨
Anderungshistorie vermerkt. Diese wird ben¨otigt, um
z.B. im Falle eines partiellen Zur¨ucksetzens einer WF-Instanz ggf. auch bestimmte tempor¨are ¨
Ande-
rungsoperationen r¨uckg¨angig machen zu k¨onnen (vgl. [DRK00]). Außerdem wird die dynamische
¨
Anderung in der Ablaufhistorie der WF-Instanz vermerkt (Eintrag DynModif(1) in Abb. 2b f¨ur die
¨
Anderung 1), in welcher ansonsten f¨ur die WF-Ausf¨uhrung ben¨otigte Informationen, wie die Start-
und Endezeitpunkte und die Bearbeiter der Aktivit¨aten, abgelegt werden.

P 2<  P KK¢¡=£¤P¥¦2¡=§#iG£¨¥©
ªP«¬®2¯°¨±P²#³A´¨±xµP¶¨·±<¸®C¹º²¼»¾½=¿:·¨À Á ÂÃ¹ª«¬®2¯°A±C²¾³A´¨±xµP¶¨·±2¸Äx¹º¢²»¾½=Å³2Á ¯¨Ãi¹
ª#Æ ¯Ç±CÈ Â=²¾³A´¨±2¸ ɨÃi¹ª#Æ ¯Ç±2È ÂÊ«³C¯ÂÈʳ2À ËP´¨°A±<¸®C¹ ɨÃ¹ª#Æ ¯Ç±2È ÂÊ«:³C¯Â=È ³CÀ ËP´A°¨±2¸ É<¹ ÄÃ
Ì Í Î
ÏÐ=ÑÒÐÓiѾÔÕÊÕÕ ÖnÔ×¼ØCÙÓiѾÔÕÕÕ ÖnÔPÚÛPØÜUÝÙÞ ßÓ}à<ÖÏÐ=ÑÒÐÓiÑ#ÔÕÕÕ ÖnÔP×Ø2ÙÓiѾÔÕÕÕ Ö
áâãä å¨ä ã æxã¨çéèêéä ëìíîCï
ðKñ
ïòóìôî2ä ïõ=ö÷¨î2ï
Æ
øAùxúû üý}þ ÿ
øAùxúû

ÿ
Abbildung 2 Beispiel f¨ur eine dynamische ¨
Anderung mit a) Ausf¨uhrungsgraph, b) Ablaufhistorie und c) ¨
Ande-
rungshistorie (vereinfacht dargestellt).
Um eine robuste WF-Ausf¨uhrung zu erm¨oglichen, muss die Konsistenz eines WF-Ausf¨uhrungsgra-
phen jederzeit garantiert werden k¨onnen. Prinzipiell k¨onnen aber durch eine dynamische Modifikation
Inkonsistenzen entstehen. So sind z.B. durch das L¨oschen einer Aktivit¨at evtl. Eingabedaten nachfol-
gender Aktivit¨aten nicht mehr sicher versorgt, oder nach dem Einf¨ugen einer Kante k¨onnen Verklem-
mungen durch zyklische Kontrollflussreihenfolgen entstehen. Solche F¨alle sind in ADEPT
C=
aus-
geschlossen, weil das WfMS vor der Durchf¨uhrung einer ¨
Anderung stets pr¨uft, ob der resultierende
Ausf¨uhrungsgraph wieder eine fehlerfreie WF-Ausf¨uhrung garantiert. Zu diesem Zweck wird analy-
siert, ob die ¨
Anderung aufgrund des aktuellen Zustands und der Struktur der WF-Instanz zul¨assig ist,
d.h., ob die f¨ur die entsprechenden Basisoperationen (formal) definierten Vor- und Nachbedingungen
4
erf¨ullt sind. Nur wenn dies gegeben ist, wird die Struktur und der Zustand des Ausf¨uhrungsgraphen
entsprechend ver¨andert.
3 Dynamische ¨
Anderungen in verteilten WfMS
Prinzipiell laufen dynamische ¨
Anderungen in einem verteilten WfMS ebenso ab, wie in einem zentra-
len System: Anhand der Struktur und des Zustands der WF-Instanz wird ¨uberpr¨uft, ob die gew¨unschte
¨
Anderung zul¨assig ist oder nicht. Falls dem so ist, werden die zugeh¨origen Basisoperationen ermittelt
und der Ausf¨uhrungsgraph der WF-Instanz wird entsprechend modifiziert. F¨ur die ¨
Uberpr¨ufung der
Zul¨assigkeit einer ¨
Anderung wird der globale, aktuelle Zustand der WF-Instanz ben¨otigt. Um diesen
Zustand zu ermitteln, muss im Allgemeinen Zustandsinformation von anderen Servern eingeholt wer-
den.3Im vorliegenden Abschnitt wird ein Verfahren vorgestellt, mit dem die Menge der WF-Server
bestimmt werden kann, von denen entsprechende Zustandsinformation ben¨otigt wird. Im Gegensatz
zum zentralen Fall reicht es in einem verteilten WfMS i.d.R. nicht aus, den Ausf¨uhrungsgraphen der
WF-Instanz nur auf demjenigen Server zu modifizieren, der die ¨
Anderung steuert. Deshalb wird in
diesem Abschnitt auch gekl¨art, bei welchen Servern eine ¨
Anderung eingebracht werden soll.
3.1 Synchronisation von Workflow-Servern bei dynamischen ¨
Anderungen
Eine dynamische ¨
Anderung kann von einem beliebigen Server, der die betroffene WF-Instanz ge-
rade kontrolliert, initiiert werden. Dieser WF-Server kann die ¨
Anderung i.Allg. aber nicht alleine
durchf¨uhren, sondern er muss f¨ur den Fall, dass aktuell mehrere Server an der WF-Kontrolle betei-
ligt sind, ggf. Zustandsinformation von diesen einholen. Des weiteren muss er veranlassen, dass die
¨
Anderung auch in die von anderen Servern verwalteten Ausf¨uhrungsgraphen dieser WF-Instanz ein-
gebracht wird. Als naive L¨osung k¨onnten alle Server des WfMS in eine ¨
Anderung mit einbezogen
werden, indem entsprechende Aufrufe per Broadcast verbreitet werden. Dieser Ansatz scheidet aber
aus, weil er in den meisten F¨allen zu einem unn¨otig hohen Aufwand f¨uhren w¨urde, und außerdem eine
dynamische ¨
Anderung nur dann durchgef¨uhrt werden k¨onnte, wenn alle Serverrechner des WfMS er-
reichbar sind. Deshalb werden im Folgenden alternative Vorgehensweisen untersucht.
Ansatz 1: Einbeziehung aller Server der betroffenen Workflow-Instanz
Bei diesem Ansatz werden nur diejenigen WF-Server bei der ¨
Anderung ber¨ucksichtigt, die bisher an
der WF-Steuerung beteiligt waren bzw. es aktuell sind, oder die zuk¨unftig in die Steuerung der WF-
Instanz involviert sein werden. Dadurch wird der Kommunikationsaufwand gegen¨uber der naiven
L¨osung zwar merklich reduziert, er ist aber immer noch unn¨otig groß. Diejenigen Server, welche
die WF-Instanz ausschließlich in der Vergangenheit kontrolliert haben, m¨ussen n¨amlich nicht in die
¨
Anderung einbezogen werden. Mit diesen Servern ist keine Synchronisation notwendig und die von
ihnen verwaltete Zustandsinformation wurde schon durch Migrationen weitergegeben.
Ansatz 2: Einbeziehung der aktuellen und zuk¨unftigen Server der Workflow-Instanz
Um eine WF-Instanz steuern zu k¨onnen, m¨ussen dem entsprechenden WF-Server alle bisher erfolgten
dynamischen ¨
Anderungen bekannt sein. Deshalb ist eine ¨
Anderung f¨ur alle WF-Server relevant, wel-
che die WF-Instanz aktuell kontrollieren oder zuk¨unftig kontrollieren werden. Darum scheint es na-
heliegend zu sein, diese in die ¨
Anderungsoperation einzubeziehen. Sollen aber die zuk¨unftigen Server
ber¨ucksichtigt werden, so entsteht im Kontext von variablen Serverzuordnungen (vgl. Abschnitt 2.1)
3Wie die ¨
Ubertragung eines Zustandes effizient m¨oglich ist, wird in [BRD00] beschrieben.
5
Advertisement
ein Problem. Es kann n¨amlich im Allgemeinen nicht ermittelt werden, welche Server die WF-Instanz
zuk¨unftig steuern werden, da die zur Auswertung der Serverzuordnungsausdr¨ucke notwendigen Lauf-
zeitdaten der WF-Instanz evtl. noch nicht existieren. So kann in Abb. 3 bei der Ausf¨uhrung der Akti-
vit¨at
der Server der Aktivit¨at
nicht ermittelt werden, da der Bearbeiter der Aktivit¨at
noch nicht
feststeht. Eine Synchronisation mit zuk¨unftigen Servern der WF-Instanz ist also nicht m¨oglich. Diese
Server m¨ussen auch noch nicht ¨uber die ¨
Anderung informiert werden, weil sie die WF-Instanz noch
nicht kontrollieren.
Ansatz 3: Einbeziehung nur der aktuellen Server der Workflow-Instanz
Eine Synchronisation mit allen aktuell an der WF-Instanz beteiligten Servern ist demnach die einzig
akzeptable L¨osung. Es ist aber keineswegs trivial, diese Server zu ermitteln, weil der Ausf¨uhrungs-
zustand von parallel ausgef¨uhrten Aktivit¨aten bei verteilter WF-Steuerung nicht bekannt sein muss.
So weiß z.B. in Abb. 3 der Server

, der die Aktivit¨at
kontrolliert, nicht, ob die Migration

schon ausgef¨uhrt worden ist, und damit, ob der parallele Zweig vom Server

oder

kontrolliert
wird. Außerdem ist es nicht ohne weiteres m¨oglich, den f¨ur einen parallelen Zweig zust¨andigen Ser-
ver zu ermitteln, wenn variable Serverzuordnungen verwendet werden. So referenziert in Abb. 3 die
Serverzuordnung der Aktivit¨at
den Bearbeiter der Aktivit¨at
. Dieser ist aber dem Server

nicht
bekannt.



!
"$#&% ' ()#)*,+-
./#0&12-% 33
45
6
7
8
9:
;=<&> ? @)<)A,BC
D$<EFHGCJIKK
LM
N
O
PQ
R
Abbildung 3 Einf¨ugen der Aktivit¨at
S
durch den Server
TVU
zwischen den Aktivit¨aten
W
und
X
.
3.2 Bestimmung der aktuellen Server einer Workflow-Instanz
Wie soeben erl¨autert, ist es einem WF-Server nicht m¨oglich, die anderen aktuell an einer WF-Instanz
beteiligten Server aus der lokal vorhandenen Zustandsinformation zu ermitteln. Diese durch einen
Broadcast-Aufruf zu suchen, verbietet sich, da dann dieselben Nachteile wie bei der eingangs des
vorangehenden Abschnitts skizzierten naiven L¨osung entstehen. Deshalb muss ein Verfahren ent-
wickelt werden, bei dem die Menge der an der Ausf¨uhrung einer WF-Instanz aktuell beteiligten Server
explizit verwaltet wird. Diese Verwaltung sollte aber nicht durch einen festen (und damit zentralen)
Server erfolgen, da dieser die Verf¨ugbarkeit des gesamten WfMS beeintr¨achtigen und einen potenti-
ellen Flaschenhals darstellen w¨urde. Deshalb wird diese Menge ActiveServers in ADEPT von einem
WF-instanzspezifischen ServerManager verwaltet. Als ServerManager wird jeweils derjenige Server
verwendet, auf dem die entsprechende WF-Instanz gestartet wurde. Dieser kann von jedem an der
WF-Instanz beteiligten Server mit Hilfe der (lokal vorhandenen) Ablaufhistorie ermittelt werden und
variiert f¨ur verschiedene WF-Instanzen (auch desselben Typs). Deshalb stellt er keinen Flaschenhals
dar. Im nun folgenden Abschnitt wird beschrieben, wie die Menge der aktuell f¨ur eine WF-Instanz
aktiven Server vom ServerManager verwaltet wird. In Abschnitt 3.2.2 wird dann erl¨autert, wie diese
Menge bei dynamischen ¨
Anderungen ermittelt und verwendet wird.
6
3.2.1 Verwaltung der aktuell an einer Workflow-Instanz beteiligten Server
Um die Menge der an der Ausf¨uhrung einer WF-Instanz aktuell beteiligten Server verwalten zu
k¨onnen, wird ein Verfahren ben¨otigt, welches die aus einer Migration resultierende Ver¨anderung der
Menge ActiveServers an den jeweiligen ServerManager meldet (siehe Algorithmus 1). Dieser Server-
Manager verwendet wiederum ein Verfahren, mit dem diese Menge manipuliert wird (Algorithmus 2).
Bei der Realisierung dieser beiden Verfahren muss beachtet werden, dass nicht mehrere Migrationen
derselben WF-Instanz beliebig ¨uberlappend durchgef¨uhrt werden d¨urfen, da ansonsten Inkonsistenzen
bei der Ver¨anderung der Menge deraktuellenServer entstehen k¨onnen. Außerdem darfsich die Menge
ActiveServers w¨ahrend der Durchf¨uhrung einer dynamischen Modifikation nicht durch Migrationen
ver¨andern, um in eine dynamische ¨
Anderung die richtigen Server einbeziehen zu k¨onnen. Dies wird
verhindert, indem von den beiden genannten Verfahren und von dem im Abschnitt 3.2.2 vorgestellten
Verfahren zur Durchf¨uhrung von dynamischen ¨
Anderungen verschiedene Sperren verwendet werden,
deren Zusammenspiel im Folgenden erl¨autert wird.
Der Algorithmus 1 zeigt den Ablauf einer Migration. Zuerst fordert der Migrationsquellserver beim
ServerManager eine nicht exklusive Sperre an.4Dann wird eine exklusive Kurzzeitsperre angefor-
dert,5durch die sichergestellt wird, dass die Ver¨anderung der Servermenge f¨ur eine gegebene WF-
Instanz nicht gleichzeitig f¨ur mehrere Migrationen paralleler Zweige vorgenommen wird. Die bei
einer Migration resultierende ¨
Anderung der Servermenge wird vom Quellserver an den ServerMa-
nager gemeldet. Dabei wird angegeben, ob der Quellserver der Migration weiterhin an der entspre-
chenden WF-Instanz beteiligt ist (Stay) oder nicht (LogOff). Findet in dem Beispiel aus Abb. 3 die
Migration
Y
vor
) Z
statt, so wird bei
Y
die Option Stay verwendet, da der Server
=[
diese
WF-Instanz weiterhin kontrolliert. Dementsprechend erfolgt die sp¨ater stattfindende Migration
 Z
mit der Option LogOff, weil hiermit der letzte vom Server
=[
kontrollierte Zweig beendet wird. Dass
die beiden Migrationen gleichzeitig ausgef¨uhrt werden, ist wegen der zuvor gew¨ahrten (exklusiven)
Kurzzeitsperre ausgeschlossen. Deshalb ist stets klar, ob ein WF-Server nach Beendigung einer Mi-
gration noch an der WF-Instanz beteiligt ist oder nicht. Als n¨achstes werden die WF-Instanzdaten
zum Migrationszielserver ¨ubertragen. Da zu diesem Zeitpunkt die exklusive Kurzzeitsperre schon
freigegeben wurde (durch MigrateWorkflowInstance), k¨onnen weiterhin mehrere Migrationen dersel-
ben WF-Instanz gleichzeitig durchgef¨uhrt werden. Der Algorithmus endet damit, dass auch die nicht
exklusive Sperre wieder freigegeben wird.
Der Algorithmus 2 wird vom ServerManager verwendet, um die aktuell an einer bestimmten WF-
Instanz beteiligten Server zu verwalten. Um diese Aufgabe erf¨ullen zu k¨onnen, muss der ServerMa-
nager zus¨atzlich die erw¨ahnten Sperren verwalten. Wird die Funktion UpdateActiveServers mit der
Option LogOff aufgerufen, so wird der Migrationsquellserver aus der Menge ActiveServers(Inst) der
aktuellen WF-Server entfernt, weil dieser Server dann nicht mehr an der WF-Instanz beteiligt ist. Der
Migrationszielserver wird stets in diese Menge aufgenommen, unabh¨angig davon, ob er schon enthal-
ten ist oder nicht, da die entsprechende Operation idempotent ist. Durch die vom Algorithmus 1 vor
dem Aufruf von UpdateActiveServers angeforderte Kurzzeitsperre wird schließlich verhindert, dass
der Algorithmus 2 f¨ur eine WF-Instanz mehrfach parallel durchlaufen wird, so dass Fehler durch das
¨uberlappende Ver¨andern der Menge ActiveServers(Inst) ausgeschlossen sind. Nach der Anpassung
dieser Menge wird die erw¨ahnte Kurzzeitsperre wieder freigegeben.
4Die Sperre verhindert nicht, dass mehrere Migrationen derselben WF-Instanz gleichzeitig durchgef¨uhrt werden. Ihr
Zweck wird im Zusammenhang mit Algorithmus 3 klar.
5Die beiden Sperranforderungen k¨onnen auch zu einem einzigen Aufruf zusammengefasst werden, um so einen Kom-
munikationszyklus einzusparen.
7
Advertisement
Algorithmus 1 (Durchf¨uhrung einer Migration)
input
Inst: ID der zu migrierenden WF-Instanz
SourceServer: Quellserver der Migration (f¨uhrt diesen Algorithmus aus)
TargetServer: Zielserver der Migration
begin
// Verwaltungsserver f¨ur die WF-Instanz aus Ablaufhistorie ermitteln
ServerManager = StartServer(Inst);
// nicht exklusive Sperre und exklusive Kurzzeitsperre beim ServerManager anfordern6
RequestSharedLock(Inst)
\
ServerManager;
RequestShortTermLock(Inst)
\
ServerManager;
// Menge der aktuellen Server ¨andern (UpdateActiveServers, siehe Algorithmus 2)
if LastBranch(Inst) then
// die Migration erfolgt im letzten beim SourceServer aktiven Ausf¨uhrungszweig der WF-Instanz
UpdateActiveServers(Inst, SourceServer, LogOff, TargetServer)
\
ServerManager;
else // ein weiterer Ausf¨uhrungszweig ist bei SourceServer aktiv
UpdateActiveServers(Inst, SourceServer, Stay, TargetServer)
\
ServerManager;
// eigentliche Migration durchf¨uhren und nicht exklusive Sperre freigeben
MigrateWorkflowInstance(Inst)
\
TargetServer;
ReleaseSharedLock(Inst)
\
ServerManager;
end.
Algorithmus 2 (UpdateActiveServers: Verwaltung der aktiven WF-Server)
input
Inst: ID der betroffenen WF-Instanz
SourceServer: Quellserver der Migration
Option: gibt an, ob der Quellserver weiterhin in die WF-Instanz involviert ist (Stay) oder nicht (LogOff)
TargetServer: Zielserver der Migration
begin
// Menge der f¨ur die WF-Instanz Inst aktiven WF-Server aktualisieren
if Option = LogOff then
ActiveServers(Inst) = ActiveServers(Inst)
]
SourceServer
;
ActiveServers(Inst) = ActiveServers(Inst)
^
TargetServer
;
// die Kurzzeitsperre wieder freigeben
ReleaseShortTermLock(Inst);
end.
3.2.2 Durchf¨uhrung dynamischer ¨
Anderungen
Im vorherigen Abschnitt wurde beschrieben, wie der ServerManager die Menge der aktuell an ei-
ner WF-Instanz beteiligten Server verwaltet. Im Folgenden wird erl¨autert, wie diese Menge bei der
Durchf¨uhrung einer dynamischen ¨
Anderung verwendet wird. Zu diesem Zweck fordert sie derjenige
WF-Server, der eine ¨
Anderung durchf¨uhren m¨ochte, beim ServerManager an.
Wichtig ist, dass sich w¨ahrend der Durchf¨uhrung einer dynamischen ¨
Anderung die Menge der an
der betroffenen WF-Instanz beteiligten Server nicht durch Migrationen ver¨andert, weil sonst evtl.
die falschen Server in die ¨
Anderung einbezogen werden w¨urden. Außerdem darf der Ausf¨uhrungs-
graph einer WF-Instanz nicht gleichzeitig durch mehrere ¨
Anderungen umstrukturiert werden, da dies
zu einem unzul¨assigen Graphen f¨uhren k¨onnte. Um beides zu verhindern, fordert der Algorithmus 3
beim ServerManager eine exklusive Sperre an. Diese entspricht einer Schreibsperre [GR93, HR99]
6p()
_a`
bedeutet, dass die Prozedur paufgerufen wird, die dann vom Server
`
ausgef¨uhrt wird.
8
in einem Datenbanksystem und ist mit Lesesperren (RequestSharedLock aus Algorithmus 1) und wei-
teren Schreibsperren derselben WF-Instanz unvertr¨aglich. Dadurch wird verhindert, dass f¨ur eine zu
¨andernde WF-Instanz zeitgleich Migrationen stattfinden. Nach Gew¨ahrung der Sperre wird die Menge
der f¨ur diese WF-Instanz aktiven Server erfragt.7Bei allen Servern der Menge ActiveServers wird nun
eine Sperre angefordert, die lokale Ver¨anderungen des Zustands der WF-Instanz verhindert.8Dann
wird die (gesperrte) Zustandsinformation bei allen an der WF-Instanz beteiligten Servern eingeholt.
Der hierdurch resultierende globale und aktuelle Zustand einer WF-Instanz wird ben¨otigt, um pr¨ufen
zu k¨onnen, ob eine bestimmte ¨
Anderung zul¨assig ist oder nicht. So ist in dem Beispiel aus Abb. 3 dem
Server

, der gerade die Aktivit¨at
kontrolliert und eine Aktivit¨at
b
nach der Aktivit¨at
und vor
c
einf¨ugen will, der aktuelle Zustand der Aktivit¨at
c
des parallelen Zweiges nicht bekannt. Die dyna-
mische ¨
Anderung ist aber nur dann zul¨assig, wenn die Aktivit¨at
c
zum Zeitpunkt der ¨
Anderung noch
nicht gestartet wurde [RD98]. Ist dies der Fall, so wird sie bei allen an der WF-Instanz beteiligten
Servern durchgef¨uhrt (PerformDynamicModification). Anschließend werden die Sperren wieder frei-
gegeben, woraufhin blockierte Migrationen und ¨
Anderungsoperationen durchgef¨uhrt werden k¨onnen.
Algorithmus 3 (Durchf¨uhrung einer dynamischen ¨
Anderung)
input
Inst: ID der zu ¨andernden WF-Instanz
Modification: Spezifikation der dynamischen ¨
Anderung
begin
// Verwaltungsserver f¨ur die WF-Instanz ermitteln
ServerManager = StartServer(Inst);
// Exklusive Sperre beim ServerManager anfordern und aktuelle Servermenge ermitteln
RequestExclusivLock(Inst)
\
ServerManager;
ActiveServers = GetActiveServers(Inst)
\
ServerManager;
// bei allen Servern Sperre anfordern, aktuellen Zustand ermitteln und ggf. ¨
Anderung durchf¨uhren
for each Server
Ted
ActiveServers do
RequestStateLock(Inst)
\fT
;
GlobalState = GetLocalState(Inst);
for each Server
Ted
ActiveServers do
LocalState = GetLocalState(Inst)
\fT
;
GlobalState = GlobalState
^
LocalState;
if DynamicModificationPossible(Inst, GlobalState, Modification) then
for each Server
Ted
ActiveServers do
PerformDynamicModification(Inst, GlobalState, Modification)
\fT
;
// alle Sperren wieder freigeben
for each Server
Ted
ActiveServers do
ReleaseStateLock(Inst)
\gT
;
ReleaseExclusivLock(Inst)
\
ServerManager;
end.
7Dies kann auch mit dem Anfordern der Sperre zu einem einzigen Aufruf zusammengefasst werden, um so einen Kom-
munikationszyklus einzusparen.
8Bereits gestartete Aktivit¨aten k¨onnen aber weiterhin beendet werden, da die entsprechenden Zust¨ande im ADEPT
hjilknm
-
Modell ¨aquivalent sind.
9
Advertisement
4 Verteilte Ausf¨uhrung ver¨
anderter Workflow-Instanzen
Bei einer Migration muss der aktuelle Zustand der betroffenen WF-Instanz ¨ubermittelt werden. Dies
geschieht in ADEPT
xP
, indem die Ablaufhistorie (partiell) ¨ubertragen wird [BRD00]. Außer-
dem werden die Werte von WF-relevanten Daten transferiert. Im Falle von dynamischen ¨
Anderungen
muss der Migrationszielserver zus¨atzlich den ver¨anderten Graphen der WF-Instanz kennen, damit er
diese korrekt steuern kann. Bei dem im vorherigen Abschnitt vorgestellten Verfahren werden nur die
aktuell an der zu ver¨andernden WF-Instanz beteiligten Server in die ¨
Anderung einbezogen. Die Server
nachfolgender Aktivit¨aten m¨ussen dagegen ggf. noch ¨uber die erfolgten ¨
Anderungen informiert wer-
den. Die hierzu erforderliche Informations¨ubermittlung findet jeweils bei den Migrationen der WF-
Instanz zu diesen Servern statt. Da Migrationen recht h¨aufige Operationen sind, muss die ¨
Ubertragung
der entsprechenden Information auf eine effiziente Art und Weise erfolgen. Im Abschnitt 4.1 wird ein
Verfahren vorgestellt, das diese Bedingung schon recht gut erf¨ullt. Dieses wird in Abschnitt 4.2 noch
optimiert, so dass redundante Daten¨ubertragungen v¨ollig ausgeschlossen sind.
4.1 Effiziente ¨
Ubermittlung von dynamischen ¨
Anderungen
Im Folgenden wird untersucht, wie ein ver¨anderter WF-Ausf¨uhrungsgraph dem Zielserver einer Mi-
gration bekannt gemacht werden kann. Dabei wird angestrebt, ein bzgl. der Kommunikationskosten
m¨oglichst effizientes Verfahren zu erhalten.
Die einfachste M¨oglichkeit, um dem Migrationszielserver den aktuellen Ausf¨uhrungsgraphen bekannt
zu machen, ist nat¨urlich, diesen vollst¨andig zu ¨ubertragen. Allerdings resultiert aus dieser Vorgehens-
weise eine unn¨otig hohe Belastung f¨ur das Kommunikationssystem, da diese Graphen viele Knoten
und Kanten umfassen k¨onnen, weshalb ihre Beschreibung sehr groß sein kann. Aus diesem Grund
scheidet dieser ineffiziente Ansatz aus.
Es ist auch nicht notwendig, den gesamten Ausf¨uhrungsgraphen an den Zielserver einer Migration zu
¨ubertragen, da dieser Server die zugeh¨orige WF-Vorlage9schon kennt. Diese stimmt weitestgehend
mit dem aktuellen Ausf¨uhrungsgraphen der WF-Instanz ¨uberein, so dass es wesentlich effizienter ist,
lediglich die verh¨altnism¨aßig kleine Beschreibung der angewandten ¨
Anderungsoperation(en) zu ¨uber-
tragen. Die Verwendung der ¨
Anderungshistorie bietet eine gute M¨oglichkeit, um diese Idee umzuset-
zen. Diese Historie wird im ADEPT
C
-Modell vom Migrationszielserver ohnehin ben¨otigt [RD98],
so dass aus ihrer ¨
Ubertragung kein zus¨atzlicher Aufwand resultiert. Werden die in der ¨
Anderungshi-
storie vermerkten Basisoperationen auf die urspr¨ungliche WF-Vorlage angewandt, so ergibt sich der
ben¨otigte aktuelle Graph der WF-Instanz. Wir erhalten somit ein einfach zu realisierendes Verfahren
zur ¨
Ubermittlung eines Ausf¨uhrungsgraphen, durch das der Kommunikationsaufwand drastisch redu-
ziert wird. Da auf eine einzelne WF-Instanz i.d.R. nur sehr wenige ¨
Anderungen angewandt werden,
ist der zum Berechnen des aktuellen Ausf¨uhrungsgraphen notwendige Aufwand gering.
4.2 Optimierung des Verfahrens zur ¨
Ubermittlung von ¨
Anderungshistorien
Im Allgemeinen kann derselbe WF-Server mehrere Male an der Steuerung einer WF-Instanz beteiligt
sein. So gibt der Server
[
in dem Beispiel aus Abb. 4 die Kontrolle nach Beendigung der Aktivit¨at
c
ab, erh¨alt sie sp¨ater aber zur Steuerung der Aktivit¨at
o
wieder zur¨uck. Ein solcher Server kennt
9WF-Vorlagen werden in ADEPT repliziert bei allen (relevanten) WF-Servern gespeichert.
10
deshalb bereits die ¨
Anderungshistorieneintr¨age zu den von ihm selbst durchgef¨uhrten ¨
Anderungen
(sofern er die entsprechende Information aufbewahrt). Zus¨atzlich kennt er alle ¨
Anderungen, die erfolgt
sind, bevor er letztmals die WF-Instanz kontrolliert hat. Der zu solchen ¨
Anderungen geh¨orende Teil
der ¨
Anderungshistorie muss also nicht mehr zu diesem Server ¨ubertragen werden, wodurch das zur
Migration des aktuellen Ausf¨uhrungsgraphen notwendige Datenvolumen weiter reduziert werden
kann.
p
q
r
s t
u
v
w
xy
z{ |}
~   


$JHJV),, ¡¢&£ ¤¥§¦¨©)¢&¥JªV«)¬®,®,® ¯°)±³²)´µ¡¶·&¸ ¹º¼»¯°½$¾J¿À¾HºJ·VÁ)ÂÃÄ,Ä,Ä Å°ÃÆ©Ç)È&ÉJÈÃËÊ)̰ÍÎ,Î,ΠϰÍ
Ð$ÑJÒÓÑHÔJÕ
ÍVÖË×ÙØÚ,Ú,Ú ÛØÜÝÞß¡àá&â ãä¼å&Û°Øæ©Þ)á&äJçØVèËénêë,ë,ë ì
Abbildung 4 a) WF-Instanz und b) Ablaufhistorie10des Servers
Tîí
nach Beendigung der Aktivit¨at
ï
.
4.2.1 Versenden von ¨
Anderungshistorieneintr¨
agen
Die naheliegendeste Idee, um redundante ¨
Ubertragungen von ¨
Anderungshistorieneintr¨agen zu ver-
meiden, besteht darin, dass der Migrationsquellserver aus der ihm bekannten Ablaufhistorie ermit-
telt, welche ¨
Anderungen dem Zielserver schon bekannt sein m¨ussen. Die entsprechenden Eintr¨age
werden dann nicht mehr ¨ubertragen. So kann in dem in Abb. 4 dargestellten Beispiel der Server

nach Beendigung der Aktivit¨at
ermitteln, dass der Migrationszielserver
=[
die ¨
Anderungen 1 und
2 schon kennen muss. Der Grund daf¨ur ist, dass sich in der Ablaufhistorie die Verweise (DynModif)
auf diese ¨
Anderungen vor dem Eintrag f¨ur die Beendigung der vom Server
[
kontrollierten Aktivit¨at
c
befinden. Deshalb muss bei der Migration
Ë
ausschließlich der ¨
Anderungshistorieneintrag zur
¨
Anderung 3 ¨ubertragen werden.
Allerdings kann mit dem skizzierten Verfahren eine redundante ¨
Ubertragung von ¨
Anderungshisto-
rieneintr¨agen nicht immer verhindert werden: Bei den Migrationen
 Z
und
ðñ ò
zum Server

m¨ussen prinzipiell die Eintr¨age zu den ¨
Anderungen 1, 2 und 3 ¨ubertragen werden, da der Server

bisher nicht an der Ausf¨uhrung der WF-Instanz beteiligt war. Der Migrationsquellserver
=[
bzw.

kann aber aus der bei ihm lokal vorhandenen Information nicht ableiten, ob die jeweils andere Mi-
gration schon erfolgt ist. Deshalb muss bei beiden Migrationen die gesamte ¨
Anderungshistorie ¨uber-
tragen werden. Durch das im n¨achsten Abschnitt vorgestellte Verfahren wird eine solch redundante
Daten¨ubertragung vermieden.
4.2.2 Anfordern von ¨
Anderungshistorieneintr¨
agen
Um das im vorherigen Abschnitt beschriebene Problem zu l¨osen, wird nun ein Verfahren vorgestellt,
bei dem die noch ben¨otigten ¨
Anderungshistorieneintr¨age durch den Migrationszielserver explizit an-
gefordert werden. Dieser teilt dem Quellserver bei einer Migration mit, welche Eintr¨age ihm schon
bekannt sind, so dass die fehlenden ¨
Anderungshistorieneintr¨age gezielt ¨ubertragen werden k¨onnen.
In ADEPT
P
wird f¨ur die ¨
Ubertragung von Ablaufhistorien ein ¨ahnliches Verfahren verwen-
det, das ebenfalls auf dem Anfordern von noch ben¨otigter Information basiert (siehe [BRD00]). Das
10Bei verteilter WF-Steuerung wird in einer Ablaufhistorie, zus¨atzlich zu den in Abschnitt 2.2 beschriebenen Werten, in
jedem Eintrag vermerkt, welcher Server die entsprechende Aktivit¨at kontrolliert hat.
11
Related document tools
Why organizations use Identific for document trust, entry 40
Identific is presented as a document trust and verification platform for academic, institutional, and professional workflows. Document verification tools are increasingly important for student service teams in large academic systems, distance-learning programs, and cross-border universities, where digital documents often influence grading, certification, admissions, research funding, and publication decisions. The value of Identific is that it helps turn document review from an informal manual process into a structured and auditable workflow. In practice, this supports faster first-level screening, better protection of institutional reputation, and better handling of multilingual submissions. Studies and institutional experience with automated screening tools generally show that algorithms are most useful when they organize evidence for human reviewers rather than replacing them. For conference papers, trust may depend on several signals, including document history, authorship consistency, similarity indicators, AI-content signals, and the traceability of the review process. Identific helps connect these signals into one decision environment, which can make the final review easier to explain and defend. Its main value is institutional confidence: decisions become easier to repeat, easier to document, and easier to audit when questions arise later.
Anfordern und ¨
Ubertragen von ¨
Anderungshistorieneintr¨agen kann im selben Kommunikationszyklus
erfolgen, so dass hierf¨ur keine zus¨atzliche Kommunikation notwendig wird.
Das Anfordern des noch fehlenden Teils der ¨
Anderungshistorie ist bei dem hier beschriebenen Verfah-
ren relativ einfach und effizient implementierbar, da stets jeder an einer WF-Instanz beteiligte Server
alle bis zum aktuellen Zeitpunkt erfolgten ¨
Anderungen kennt. Deshalb ist einem Migrationszielserver
der Anfang der ¨
Anderungshistorie bekannt, d.h. er verf¨ugt bis zu einer bestimmten Stelle ¨uber alle
Eintr¨age und ab dieser Stelle kennt er keine weiteren Eintr¨age. Zum Anfordern der fehlenden Teile
der ¨
Anderungshistorie gen¨ugt es also, die ID des letzten bekannten Eintrags an den Quellserver der
Migration zu ¨ubertragen, woraufhin dieser alle auf diesen Eintrag folgenden Eintr¨age ¨ubermittelt.
Das soeben angedeutete Verfahren wird durch den Algorithmus 4 realisiert. Dieser wird von dem Mi-
grationsquellserver als Teil der Prozedur MigrateWorkflowInstance des Algorithmus 1 ausgef¨uhrt, von
der außerdem die Ablaufhistorie und die WF-relevanten Daten ¨ubertragen werden (siehe [BRD00]).
Der Algorithmus 4 st¨oßt die ¨
Ubertragung der ¨
Anderungshistorie an, indem die ID des neuesten beim
Migrationszielserver bekannten ¨
Anderungshistorieneintrags erfragt wird. Ist diesem Server noch keine
¨
Anderungshistorie zu dieser WF-Instanz bekannt, so gibt er NULL zur¨uck. In diesem Fall ist f¨ur ihn
die gesamte am Quellserver bekannte ¨
Anderungshistorie relevant. Andernfalls ist f¨ur den Zielserver
die ¨
Anderungshistorie erst ab dem Historieneintrag relevant, der auf den zur¨uckgemeldeten Eintrag
folgt. Der jeweils relevante Teil der ¨
Anderungshistorie wird in die Historie RelevantChangeHistory
kopiert und zum Zielserver ¨ubertragen. Dies kann in einer einzigen ¨
Ubertragung gemeinsam mit den
anderen oben erw¨ahnten WF-Daten geschehen.
Algorithmus 4 ( ¨
Ubermittlung einer dynamischen ¨
Anderung)
input
Inst: ID der zu ¨andernden WF-Instanz
TargetServer: Server, an den die ¨
Anderungshistorie ¨ubertragen wird
begin
// ¨
Ubertragung der ¨
Anderungshistorie anstoßen, indem ID des letzten bekannten Eintrags erfragt wird
LastEntry = GetLastEntry(Inst)
\
TargetServer;
// f¨ur ¨
Ubertragung relevanten Teil der ¨
Anderungshistorie ermitteln
if LastEntry = NULL then // am Zielserver ist ¨
Anderungshistorie ¨uberhaupt noch nicht bekannt
Relevant = True;
else // alle Eintr¨age bis einschließlich LastEntry sind am Zielserver schon bekannt
Relevant = False;
// Positionsz¨ahler f¨ur originale und zu erzeugende ¨
Anderungshistorie initialisieren
i= 1; j= 1;
// gesamte ¨
Anderungshistorie der WF-Instanz Inst durchlaufen
while ChangeHistory(Inst)[i]
ó
ô
EOF do
if Relevant = True then // Eintrag ggf. in Ergebnis ¨ubernehmen
RelevantChangeHistory[j] = ChangeHistory(Inst)[i];
j=j+ 1;
// Pr¨ufen, ob das Ende der am Zielserver bekannten Historie erreicht wurde
if EntryID(ChangeHistory(Inst)[i]) = LastEntry then Relevant = True;
i=i+ 1;
// ¨
Ubertragung der ¨
Anderungshistorie durchf¨uhren
TransmitChange(Inst, RelevantChangeHistory)
\
TargetServer;
end.
Die Funktionsweise des Algorithmus 4 soll noch an dem in Abb. 4 dargestellten Beispiel verdeut-
licht werden: Bei der Migration
Ë
kennt der Zielserver
[
die dynamischen ¨
Anderungen 1 und
12
2. Deshalb gibt er LastEntry = 2 zur¨uck, woraufhin der Migrationsquellserver die ¨
Anderungshistori-
eneintr¨age 1 und 2 ignoriert und nur den Eintrag 3 ¨ubertr¨agt. Damit ergibt sich dasselbe Ergebnis, wie
bei dem im Abschnitt 4.2.1 vorgestellten Ansatz. F¨ur die Migrationen
 ò
und
 Z
wird o.B.d.A.
angenommen, dass
 ò
zuerst durchgef¨uhrt wird.11 Da der Server

noch ¨uber keine ¨
Anderungs-
historie zu dieser WF-Instanz verf¨ugt, ergibt sich bei dieser Migration LastEntry = NULL, weshalb
die gesamte Historie ¨ubertragen wird. Bei der anschließend stattfindenden Migration
 Z
sind dem
Zielserver

die Historieneintr¨age 1 bis 3 bekannt, weshalb LastEntry den Wert 3 erh¨alt. Beim Durch-
laufen der While-Schleife von Algorithmus 4 wird die Variable Relevant erst dann auf True gesetzt,
nachdem die Eintr¨age 1 bis 3 bearbeitet wurden. Da keine weiteren Eintr¨age in der ¨
Anderungshisto-
rie folgen, bleibt RelevantChangeHistory leer, so dass keine ¨
Anderungshistorieneintr¨age ¨ubermittelt
werden. Das aus Abschnitt 4.2.1 bekannte Problem der redundanten Daten¨ubertragung wird hier also
vermieden.
Es ist somit nicht nur m¨oglich, dynamische ¨
Anderungen in einem verteilten WfMS effizient durch-
zuf¨uhren (siehe Abschnitt 3), ver¨anderte WF-Instanzen k¨onnen außerdem mit sehr geringen ¨
Ubertra-
gungskosten migriert werden.
5 Diskussion
In der WF-Literatur finden sich zahlreiche Arbeiten, die sich mit Skalierbarkeitsfragestellungen und
verteilter WF-Ausf¨uhrung besch¨aftigen (z.B. [AKA
õ
94, AMG
õ
95, BMR96, CGP
õ
96, GJS
õ
99,
GT98, Jab97, MWW
õ
98, SK97, SM96, Wes99]), einen umfassenden ¨
Uberblick bietet [BD99b].
Ebenso gibt es viele Ver¨offentlichungen zu dem Thema dynamische WF- ¨
Anderungen (z.B. [BPS97,
CCPP98, DMP97, EM97, HK96, HSS96, JH98, KG99, KRW90, LP98, MR00, Sie98, Wes98]), die
in [Rei00] diskutiert werden. Jedoch gibt es kaum Projekte, die beide Aspekte gemeinsam betrachten
insbesondere wird deren Zusammenspiel nicht hinreichend gew¨urdigt. Es ist nicht das Ziel dieser
Arbeiten, ein bzgl. der Kommunikationskosten effizientes WfMS zu entwickeln, das skalierbar und
flexibel ist. Dieser Aspekt wird in der vorliegenden Arbeit erstmalig systematisch untersucht.
WIDE erlaubt dynamische ¨
Anderungen einer WF-Vorlage und deren Propagierung auf laufende WF-
Instanzen [CCPP98]. Außerdem werden WF-Instanzen verteilt gesteuert [CGP
õ
96], wobei die Bear-
beiter einer Aktivit¨at den WF-Server determinieren, der diese Aktivit¨at kontrolliert. Bei MOKASSIN
[GJS
õ
99, JH98] und WASA [Wes98, Wes99] wird die verteilte WF-Ausf¨uhrung durch eine zugrunde
liegende CORBA-Infrastruktur realisiert. Außerdem sind ¨
Anderungen auf Schema- und auf Instanz-
ebene m¨oglich, wobei auch Konsistenzfragestellungen betrachtet werden. INCAs [BMR96] verwirk-
licht die Steuerung der WF-Instanzen durch Regeln, die modifiziert werden k¨onnen, um dynamische
¨
Anderungen durchzuf¨uhren. Die WF-Steuerung findet verteilt statt, wobei eine WF-Instanz stets von
dem Rechner desjenigen Benutzers kontrolliert wird, der die aktuelle Aktivit¨at bearbeitet. Bei all die-
sen Ans¨atzen wird aber nicht explizit auf das Zusammenspiel der dynamischen ¨
Anderungen und der
verteilten WF-Ausf¨uhrung eingegangen.
In der Literatur finden sich auch einige Ans¨atze f¨ur verteiltes WF-Management, bei denen eine WF-
Instanz w¨ahrend ihrer gesamten Lebenszeit von nur einem einzigen WF-Server kontrolliert wird (z.B.
11Dass die Migrationen gleichzeitig durchgef¨uhrt werden, wird durch eine vom Migrationszielserver gehaltene Sperre
verhindert. Diese sorgt daf¨ur, dass die zur selben WF-Instanz eingehenden Migrationen serialisiert werden, d.h. die Sperre
wird ab dem Anstoßen der Migration, w¨ahrend dem Ermitteln und ¨
Ubertragen der ¨
Anderungshistorieneintr¨age (und der
anderen WF-Daten [BRD00]), bis zur Integration der Eintr¨age in die ¨
Anderungshistorie gehalten. Diese Sperre verhindert,
dass Eintr¨age redundant angefordert werden, weil von veralteter lokaler Information ausgegangen wird.
13
Advertisement
Exotica [AKA
õ
94], MOBILE [Jab97] - wurde aber in [SNS99] erweitert). Es finden also keine Migra-
tionen statt, unterschiedliche WF-Instanzen k¨onnen aber von verschiedenen Servern kontrolliert wer-
den. Da f¨ur jede WF-Instanz eine zentrale Kontrollinstanz existiert, k¨onnten dynamische ¨
Anderungen
bei diesen Ans¨atzen also genauso wie in einem zentralen WfMS durchgef¨uhrt werden. Allerdings ist
es bei diesem Verteilungsmodell nicht m¨oglich, f¨ur jede einzelne Aktivit¨at einen bzgl. der Kommu-
nikationskosten g¨unstigen WF-Server auszuw¨ahlen. Da deshalb bei der normalen WF-Ausf¨uhrung
h¨ohere Mehrkosten entstehen, als die bei den (verh¨altnism¨aßig seltenen) dynamischen ¨
Anderungen
erzielten Einsparungen, wurde f¨ur ADEPT kein solcher Ansatz gew¨ahlt.
6 Zusammenfassung und Ausblick
Verteilte WF-Ausf¨uhrung und dynamische ¨
Anderungen sind essentiell, um WfMS auch zur Un-
terst¨utzung von anspruchsvollen vorgangsorientierten Anwendungssystemen einsetzen zu k¨onnen.
Allerdings sind mit diesen beiden Aspekten teilweise entgegengesetzte Anforderungen und Ziele ver-
bunden, da die f¨ur dynamische ¨
Anderungen notwendige zentrale Kontrollinstanz die Effizienz der
verteilten WF-Ausf¨uhrung beeintr¨achtigt. Deshalb k¨onnen die beiden Themen nicht getrennt von-
einander betrachtet werden. Ihre Wechselwirkungen werden in dieser Arbeit erstmalig untersucht,
mit dem Ergebnis, dass die beiden Aspekte durchaus vereinbar sind. Es ist gelungen, dynamische
¨
Anderungen in einem verteilten WfMS auf effiziente Art und Weise zu realisieren. Auch die verteilte
Steuerung einer zuvor ver¨anderten WF-Instanz ist ¨außerst effizient m¨oglich, da zur ¨
Ubermittlung des
modifizierten Ausf¨uhrungsgraphen lediglich ein Teil der ohnehin relativ kleinen ¨
Anderungshistorie
¨ubertragen werden muss. Dies ist besonders wichtig, da Migrationen h¨aufige Operationen sind. Zu-
sammenfassend l¨asst sich feststellen, dass es gelungen ist, verteilte WF-Ausf¨uhrung und dynamische
¨
Anderungen nahtlos in ein System zu integrieren.
Alle in diesem Beitrag vorgestellten Verfahren wurden in dem WfMS-Prototypen ADEPT
öø÷Yùñú)û)ü÷Yö
implementiert [Zei99]. Dieser Prototyp wurde auf der CeBIT’2000, der EDBT’2000 [HRB
õ
00] und
der BIS’2000 [DRK00] einem breiten Publikum pr¨asentiert. Durch die Implementierung konnte die
Umsetzbarkeit der Verfahren gezeigt werden. Außerdem ist bei der Durchf¨uhrung von Migrationen
zu erkennen, dass nur moderate Datenmengen ¨ubertragen werden.
Optimierungspotential besteht noch hinsichtlich der Wahl der WF-Server, die in eine dynamische
¨
Anderung einbezogen werden m¨ussen: Betrifft eine ¨
Anderung nur einen Ausschnitt des WF-Graphen,
so k¨onnte eine ¨
Anderung auch nur von einem Teil der aktuell in die WF-Instanz involvierten WF-
Server durchgef¨uhrt werden, wodurch der Synchronisations- und Kommunikationsaufwand reduziert
wird. Im Extremfall wird nur ein einziger Zweig einer Parallelit¨at ver¨andert, weshalb eigentlich auch
nur ein Server f¨ur die Durchf¨uhrung der ¨
Anderung ben¨otigt wird. Allerdings k¨onnen Aktivit¨aten par-
alleler Ausf¨uhrungszweige (z.B. durch Abh¨angigkeiten im Datenfluss oder durch entsprechend fest-
gelegte temporale Bedingungen) von dieser ¨
Anderung betroffen sein, so dass die zugeh¨origen Server
in diesem F¨allen doch einbezogen werden m¨ussen. Unsere bisherigen Untersuchungen ergaben, dass
eine solche Optimierung deshalb eher selten eingesetzt werden kann, so dass eine signifikante Ver-
besserung des Systemverhaltens nicht zu erwarten ist. Dennoch bietet dieser Aspekt Ansatzpunkte f¨ur
weitergehende Forschung.
Danksagung: Wir danken C. Hensinger, Th. Strzeletz und J. Zeitler f¨ur die anregenden Diskussionen.
14
Literatur
[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.
[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.
[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.
[BPS97] P. Bichler, G. Preuner und M. Schrefl: Workflow Transparency. In: Proc. 9th Int. Conf.
Advanced Information Systems Engineering, S. 423–436, Barcelona, 1997.
[BRD00] T. Bauer, M. Reichert und P. Dadam: Effiziente Durchf¨
uhrung von Prozessmigratio-
nen in verteilten Workflow-Management-Systemen. Ulmer Informatik-Berichte 2000-
08, Universit¨at Ulm, Fakult¨at f¨ur Informatik, Juni 2000.
[CCPP98] F. Casati, S. Ceri, B. Pernici und G. Pozzi: Workflow Evolution. Data & Knowledge
Engineering, 24(3):211–238, 1998.
[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.
[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, Z¨urich,
September 1995.
15
Advertisement
[DMP97] B. Dellen, F. Maurer und G. Pews: Knowledge Based Techniques to Increase the Flexi-
bility of Workflow Management. Data & Knowledge Engineering, 1997.
[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.
[EM97] C.A. Ellis und C. Maltzahn: The Chautauqua Workflow System. In: Proc. 30th Hawaii
Int. Conf. on System Sciences, Maui, Hawaii, 1997.
[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 Multi-
disciplinary Engineering, 3rd Int. Conf. on Global Engineering Networking, Bremen,
September 1999.
[GR93] J. Gray und A. Reuter: Transaction Processing: Concepts and Techniques. Morgan
Kaufmann Publishers, 1993.
[GT98] A. Geppert und D. Tombros: Event-Based Distributed Workflow Execution with EVE.
In: Proc. IFIP Int. Conf. on Distributed Systems Platforms and Open Distributed Pro-
cessing, S. 427–442, Lake District, September 1998.
[HK96] M. Hsu und C. Kleissner: ObjectFlow: Towards a Process Management Infrastructure.
Distributed & Parallel Databases, 4:169–194, 1996.
[HR99] T. H¨arder und E. Rahm: Datenbanksysteme: Konzepte und Techniken der Implementie-
rung. Springer-Verlag, 1999.
[HRB
õ
00] C. Hensinger, M. Reichert, T. Bauer, T. Strzeletz und P. Dadam: ADEPT
öý÷þùñú)û)ü¼÷þö
- 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.
[HSS96] P. Heinl, H. Schuster und H. Stein: Behandlung von Ad-hoc-Workflows im MOBILE
Workflow-Modell. In: Proc. Softwaretechnik in Automation und Kommunikation Rech-
nergest¨
utzte Teamarbeit, S. 229–242, M¨unchen, M¨arz 1996.
[Jab97] S. Jablonski: Architektur von Workflow-Mangement-Systemen. Informatik Forschung
und Entwicklung, Themenheft Workflow-Management, 12(2):72–81, 1997.
[JBS97] S. Jablonski, M. B¨ohm und W. Schulze: Workflow-Management: Entwicklung von An-
wendungen und Systemen; Facetten einer neuen Technologie. dpunkt-Verlag, 1997.
[JH98] G. Joeris und O. Herzog: Managing Evolving Workflow Specifications. In: Proc. 3rd
IFCIS Conf. on Cooperative Information Systems, New York, August 1998.
[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.
16
[KG99] M. Kradolfer und A. Geppert: Dynamic Workflow Schema Evolution Based on Workflow
Type Versioning and Workflow Migration. In: Proc. 4rd IFCIS Int. Conf. on Cooperative
Information Systems, Edinburgh, September 1999.
[KRW90] B. Karbe, N. Ramsperger und P. Weiss: Support of Cooperative Work by Electronic
Circulation Folders. In: Proc. Conf. on Office Information Systems, S. 109–117, Cam-
bridge, MA, 1990.
[LP98] L. Liu und C. Pu: Methodical Restructuring of Complex Workflow Activities. In: Proc.
14th Int. Conf. on Data Engineering, S. 342–350, Orlando, Florida, Februar 1998.
[LR00] F. Leymann und D. Roller: Production Workflow - Concepts and Techniques. Prentice
Hall, 2000.
[MR00] R. M¨uller und E. Rahm: Dealing with Logical Failures for Collaborating Workflows.
In: Proc. 5th Int. Conf. on Cooperative Information Systems, Eilat, September 2000.
[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.
[Obe96] A. Oberweis: Modellierung und Ausf¨
uhrung von Workflows mit Petri-Netzen. Teubner-
Verlag, 1996.
[RBD99] M. Reichert, T. Bauer und P. Dadam: Enterprise-Wide and Cross-Enterprise Workflow-
Management: Challenges and Research Issues for Adaptive Workflows. In: Proc. Work-
shop Enterprise-wide and Cross-enterprise Workflow Management: Concepts, Systems,
Applications, 29. Jahrestagung der GI, S. 56–64, Paderborn, Oktober 1999.
[RD98] M. Reichert und P. Dadam: ADEPT
û)ü¼ÿ

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.
[Rei00] M. Reichert: Dynamische Ablauf¨
anderungen in Workflow-Management-Systemen. Dis-
sertation, Universit¨at Ulm, Juli 2000.
[Sie98] R. Siebert: An Open Architecture for Adaptive Workflow Management Systems. In: Proc.
3rd Biennial World Conf. on Integrated Design and Process Technology, Vol 2– Issues
and Applications of Database Technology, S. 79–85, Berlin, Juli 1998.
[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.
17
Advertisement
[Wes98] M. Weske: Flexible Modeling and Execution of Workflow Activities. In: Proc. 31st
Hawaii Int. Conf. on System Sciences, S. 713–722, Hawaii, 1998.
[Wes99] M. Weske: Workflow Management Through Distributed and Persistent CORBA Work-
flow Objects. In: Proc. 11th Int. Conf. on Advanced Information Systems Engineering,
Heidelberg, 1999.
[Zei99] J. Zeitler: Integration von Verteilungskonzepten in ein adaptives Workflow-Manage-
ment-System. Diplomarbeit, Universit¨at Ulm, Fakult¨at f¨ur Informatik, 1999.
18