scieee Science in your language
[en] (orig)
Architekturen f
ur skalierbare Workow-Management-Systeme {
Klassikation und Analyse
Thomas Bauer, Peter Dadam
Abteilung Datenbanken and Informationssysteme
Universit
at Ulm
f
bauer, dadam
g
@informatik.uni-ulm.de
Zusammenfassung
In unternehmensweiten Workow-Management-Systemen (WfMS) kann die von der WF-
Engine zu b ew
altigende Last sehr gro werden. Auerdem werden hohe Anforderungen an
die Verf
ugbarkeit eines solchen Systems gestellt. Deshalb wurden in der Literatur zahlreiche
Architekturen f
ur skalierbare WfMSe vorgeschlagen, die auf unterschiedlichen Verteilungen
der WF-Engine basieren. Diese Architekturen werden in dem Beitrag verglichen und klas-
siziert. Des weiteren wird die Belastung der einzelnen Systemkomp onenten analysiert und
die Ans
atze werden auf Schwachstellen hin untersucht. Die gewonnenen Erkenntnisse wer-
den verwendet, um eine Entscheidungshilfe f
ur die Auswahl einer geeigneten Architektur f
ur
b estimmte Anwendungstyp en zu geb en.
1 Einleitung
WfMSe erm
oglichen die computergesteuerte Ausf
uhrung von Gesch
aftsprozessen in einer ver-
teilten Systemumgebung. Aufgrund von wirtschaftlichen Zw
angen, wie der Verschlankung von
Unternehmen, ist das Interesse an solchen Systemen in den letzten Jahren stetig gewachsen.
Ihr entscheidender Vorteil ist, da sie helfen, groe Anwendungssysteme
ub erschaubarer zu
gestalten. Dazu wird der applikationssp ezische Co de der verwendeten Anwendungen von der
Ablauf logik (
"
Prozelogik\ ) getrennt. Anstelle eines groen monolithischen Programmpakets
erh
alt man nun unabh
angige Anwendungsbausteine, deren Ablauf logik in einer separaten Pro-
zedenition festgelegt wird. Diese b estimmt die Ausf
uhrungsreihenfolge und -b edingungen
der einzelnen Anwendungen. F
ur die Ablaufdenition b edient man sich i.d.R. einer graphi-
schen Beschreibungssprache. Die Teilschritte werden hierb ei in der Regel als Knoten dar-
gestellt, w
ahrend die Ausf
uhrungsreihenfolge (der
"
Kontrollu\ ) und ggf. auch der Daten-
u mittels gerichteter Kanten mo delliert wird. Das WfMS sorgt daf
ur, da nur Aktivit
aten
ausgef
uhrt werden k
onnen, die der Ablauf logik zufolge zur Ausf
uhrung anstehen. Diese Teil-
schritte werden in die Arb eitslisten der autorisierten Bearb eiter eingef
ugt. Welche Bearb eiter
zur Bearb eitung b estimmter Aufgab en autorisiert sind, wird meist durch ein Rollenkonzept
festgelegt. Dab ei ist es durchaus m
oglich, da mehrere Benutzer ermittelt werden, die f
ur die
Bearb eitung einer b estimmten Aktivit
at geeignet sind.
Ulmer Informatik-Berichte, Nr. 98-02, Januar 1998
Die kommerziell verf
ugbaren WfMSe erf
ullen die Anforderungen, die durchunternehmenswei-
te Anwendungen gestellt werden, zur Zeit no ch nicht in ausreichendem Mae [GHS95]. Ein
wichtiger Asp ekt hierb ei ist die Skalierbarkeit des WfMSs. Warum sie durch die heutigen zen-
tralen Architekturen stark eingeschr
ankt ist, soll das folgende Zahlenb eispiel verdeutlichen.
Betrachten wir z.B. die Schadensb earb eitung in einer Versicherung mit 150 Sachb earb eitern,
die durchschnittlich je 5 min = 300 sec f
ur eine Aktivit
at b en
otigen. Damit mu das System im
Mittel 0,5 Teilschritte pro Sekunde ausf
uhren. Alle Dokumente eines Vorgangs sollen (z.B. via
Einscannen) in digitaler Form vorliegen. Pro Teilschritt fallen damit leicht Ein-/Ausgab edaten
im Umfang von 2 MB (o der mehr
1
)an
2
.Bei 0,5Teilschritten/sec m
ussen also 1 MB/sec (in
bits: 8 Mbps) alleine an Nutzdaten b ewegt werden, wo durch ein 10 Mbps-Ethernet b ereits
deutlich
ub erfordert w
are.
Das Aktualisieren der Arb eitslisten der Benutzer erzeugt eb enfalls Last. Da 0,5 Schritte/sec
b earb eitet werden, mu 1 mal pro Sekunde ein Eintrag in die Arb eitslisten eingef
ugt o der
herausgenommen werden. Da jeder der 150 Benutzer hiervon b etroen sein kann, mu der WF-
Server
3
150 Bearb eiterb eschreibungen pro Sekunde au
osen, was f
ur einen einzelnen Server
und die zugeh
orige WF-Datenbank eine hohe Last b edeutet. Nimmtmanweiter an, da
ein Benutzer alle 10 sec eine neue Arb eitsliste erh
alt, die ca. 1 kB umfat, so ergibt sich
in diesem Beispiel ein Kommunikationsaufwand von 15 kB/sec. Dieser ist zwar in diesem
Beispiel gegen
ub er dem Parametertransfer vernachl
assigbar, b ei gr
oeren Benutzerzahlen und
sehr kurzen Aktualisierungszeiten kann ab er auch durchdenTransp ort der Arb eitslisten ein
b etr
achtlicher Aufwand entstehen. | Schon dieses rechtkonservative Beispiel zeigt, da b ei
einem zentralen WfMS sowohl der WF-Server, wie auch dessen Teilnetz, zu einem Engpa
werden k
onnen. Sollte das WfMS sogar
ub er ein WAN (Wide Area Network) weitr
aumig
verteilt sein, so ist die Verringerung der Kommunikationslast no ch wichtiger.
Skalierbarkeit wird nun erreicht, indem man Systemkomp onenten repliziert und die Last so
auf sie verteilt, da keine Komp onente
ub erlastet ist. Die Art der Verteilung von Systemkom-
p onenten und ihre Zust
andigkeiten werden in diesem Artikel als Architektur eines WfMSs
b ezeichnet. Dies ist der in diesem Beitrag prim
ar b etrachtete Asp ekt, anhand dessen die
verschiedenen Ans
atze verglichen und die Belastung der einzelnen Komp onenten analysiert
werden. Eb enfalls Teil der Architektur sind Asp ekte, wie die Vorgehensweise b ei der Aktua-
lisierung der Arb eitslisten o der die Art des Datenusses. Diese hab en zwar keinen so starken
Einu auf die Verteilung der Last, von ihnen h
angt ab er ab, wieviel Last insgesamt erzeugt
wird. Deshalb werden sie im folgenden eb enfalls diskutiert. Nicht b etrachtet werden Architek-
turasp ekte, wie die Aufteilung eines Programms in Mo dule o der die Schnittstellen zwischen
Komp onenten.
1
Hier sind auchwesentlichgr
oere Datenmengen denkbar, z.B. f
ur Multimedia-Daten. Auerdem kann
auch eine wesentlichh
ohere Benuterzahl errreichtwerden. In [KAGM96, SK97 ] werden sogar Anwendungen
b eschrieb en, b ei denen die Zahl der Benutzer eines WfMSs bis auf einige zehntausend anwachsen kann o der
mehrere zehntausend WF-Instanzen gleichzeiti g im System sein k
onnen.
2
In vielen F
allen wird das WfMS nur eine Referenz auf die Datenob jekte an die Anwendungsschicht
ub erge-
b en. Die Au
osung dieser Referenz l
ost dann erst den eigentlichen Datentransp ort aus. Da die Gesamtmenge
an b ewegten Daten die gleiche ist, wollen wir im folgenden vereinfachend annehmen, da das WfMS direkt die
Datenob jekte transp ortiert.
3
Als WF-Server (o der kurz Server) werden die Komp onenten b ezeichnet, die die WF-Engine bilden, also
die Ausf
uhrung der Prozesse steuern. Die Komp onenten, mit denen die Benutzer arb eiten, stellen die Clients
dar. Diese erledigen Aufgab en wie die Darstellung der Arb eitslisten o der das Starten von Anwendungen.
2
Auer der Skalierbarkeit gibt es zahlreiche weitere relevante Asp ekte in unternehmensweiten
WfMSen. Aus Platzgr
unden werden sie hier nur kurz erw
ahnt. Ein f
ur ein Unternehmen oft
leb enswichtiger Asp ekt ist die Verf
ugbarkeit seines Informationssystems. Die auch in ande-
ren Bereichen oft verwendete L
osung ist der Einsatz von Backup-Servern, die b eim Ausfall
des Prim
ar-Servers die Ausf
uhrung der Prozesse
ub ernehmen [KAGM96]. Um die Konsi-
stenz der unternehmensweit verteilten Daten gew
ahrleisten zu k
onnen, b en
otigt das WfMS
ein Transaktionskonzept. Die Vorschl
age dazu reichen von der Kapselung eines o der einiger
weniger Aktivit
aten eines Workows zu einer Transaktion [Ley97] bis hin zur Verwendung
von erweiterten Transaktionsmo dellen [Elm92]. Bei der Ausf
uhrung von Prozessen kommt
es in Ausnahmef
allen vor, da vom vormo dellierten Schema abgewichen werden mu. Dazu
k
onnen z.B. Aktivit
aten zus
atzlich eingef
ugt o der ausgelassen werden. Das WfMS mu b ei
einer solchen Op eration pr
ufen, ob die verschiedenen Korrektheitsasp ekte (z.B. Versorgung
der Parameter nach einer dynamischen
Anderung) no chgew
ahrleistet sind [RD98].
Der Rest dieses Papiers ist wie folgt aufgebaut: In Kapitel 2 werden grundlegende Konzepte
f
ur die Architektur von WfMSen vorgestellt und analysiert. In die dab ei entstehende Klas-
sikation werden in Kapitel 3 kommerzielle Systeme und Vorschl
age aus dem Bereich der
Forschung eingeordnet. Diese Systeme werden b eschrieb en und auf Schwachstellen hin unter-
sucht. Kapitel 4 fat die gewonnen Erkenntnisse zusammen und bietet eine Entscheidungshilfe
b ei der Auswahl einer geeigneten Architektur f
ur verschiedene Anwendungsszenarien.
2 Grundlagen
In erster Linie wird Skalierbarkeit und hohe Verf
ugbarkeit von WfMSen durch die Replikation
von Systemkomp onenten und ihre Verteilung auf mehrere Rechner und Teilnetze erreicht. Die
daf
ur m
oglichen Realisierungsvarianten werden im folgenden b eschrieb en und analysiert. In
Kapitel 3 werden ihnen dann konkrete Systeme zugeordnet. Des weiteren gibt es no ch einzelne
grundlegende Gesichtspunkte von WfMSen, die Einu auf die erzeugte Gesamtlast hab en.
Auch sie werden in diesem Kapitel b eschrieb en.
Die im folgenden b etrachteten Konzepte sollen b ez
uglich ihres Leistungsverhaltens mitein-
ander vergleichen werden. Dazu wird b erechnet, wie sich die Gesamtsystemlast
Last
Strg
f
ur
die Steuerung der Prozeschritte und die Last f
ur das Aktualisieren der Arb eitslisten
Last
AL
in den einzelnen Komp onenten niederschl
agt. In einem unternehmensweiten WfMS k
onnen
sowohl
Last
Strg
als auch
Last
AL
sehr gro werden. Damit keine Komp onente
ub erlastet
wird, mu ihre Belastung unter die jeweils vorgegeb ene Maximal-Kapazit
at der Komp onente
gedr
uckt werden k
onnen. Dies ist z.B. dann gegeb en, wenn die Last in einer Komp onente
Last
Strg
+
Last
AL
x
betr
agt, wob ei
x
eine kongurierbare Gr
oe sein mu, wie etwa die Anzahl
der Server-Replikate im System. Ist diese Bedingung durch eine Architektur erf
ullt, so kann
diese als skalierbar b ezeichnet werden.
2.1 Verteilung der Systemkomp onenten
In diesem Abschnitt werden die verschiedenen Ans
atze f
ur die Replikation und Verteilung
von Systemkomp onenten verglichen und die b ei ihnen auftretende Last analysiert. Bei die-
3
ser Analyse wird die Belastung der Systemkomp onenten und des Netzwerks (soweit dar
ub er
Aussagen m
oglich sind) untersucht. In Kapitel 3 werden die in Abbildung 1 dargestellten
Realisierungsvarianten no chweiter verfeinert und ihnen dann konkrete Systeme zugeordnet.
W fM Se m it m ehreren Servern
Server nahe
bei A nw endung
Server sind
identische R eplikate
Server nahe
b e i B e a rb e ite r
W fM S e m it z e n tra le m S e rv e r v o ll v e rte ilte W fM S e
W fM S-A rchitekturen
Abbildung 1
Realisierungsvarianten f
ur die Verteilung von WfMSen
Die b eiden Extreme, die existieren, sind Systeme mit nur einem zentralen Server und voll
verteilte Systeme, b ei denen jede Komp onente Serveraufgab en wahrnimmt. Dazwischen liegen
Systeme, die mehr als einen Server verwenden, ab er trotzdem no ch die Trennung zwischen
Client und Server aufrechterhalten, so da es weniger Server als Clients (Benutzerrechner) im
System gibt.
2.1.1 WfMSe mit zentralem Server
Systeme der in Abbildung 2 dargestellten Kategorie verwenden eine zentrale Serverkomp o-
nente. Dies ist zumindest eine zentrale Datenbank mit nur einem DB-Server. Meist wird auch
nur ein WF-Server verwendet, es gibt ab er auch Systeme, b ei denen sich mehrere WF-Server
die zentrale Datenbank teilen.
Server
C lie n tC lie n tC lie n tC lie n tC lie n tC lie n t
Abbildung 2
Architektur eines WfMSs mit zentralem Server
Die Leistungsf
ahigkeit eines solchen Systems ist i.w. durch den zentralen Server b estimmt
bzw. b eschr
ankt. Der Server hat die volle Last f
ur die Ausf
uhrung der Aktivit
aten und f
ur
die Aktualisierung der Arb eitslisten
Last
Strg
+
Last
AL
zu tragen. Das Teilnetz des DB-Servers
wird genauso stark b elastet. Ein solches System ist deshalb nur f
ur eine relativ kleine Anzahl
von Benutzern (einige Dutzend) geeignet. Werden mehrere WF-Server verwendet (Anzahl:
#
Serv
), so ist ihre Last im b esten Fall je
Last
Strg
+
Last
AL
#
Serv
, das zentrale DBMS bleibt ab er
weiterhin ein Flaschenhals.
4
AuchdieVerwendung zentraler Ho chleistungssysteme (Mehrprozessor-Systeme, Mehrrechner-
DBMSe) l
ost die b eschrieb enen Probleme nicht. Bei einem lose gekopp elten System mu
eine passende interne Verteilung gefunden werden, die den Synchronisationsaufwand klein
h
alt. Dies f
uhrt zur selb en Problemstellung, wie die Verteilung auf mehrere WF-Server. Wird
ein eng gekopp eltes System verwendet, so b eschr
anken die gemeinsamen Komp onenten die
Skalierbarkeit. Beide Varianten hab en ab er den Nachteil, da das Teilnetz des (zentralen)
Ho chleistungssystems zum Flaschenhals wird und zu manchen Benutzern eine unn
otig weit
entfernte Kommunikation stattnden mu.
2.1.2 WfMSe mit mehreren Servern
Systeme, b ei denen der WF-Server mehrfach und auf verschiedene Maschinen verteilt vor-
handen ist, fallen in diese Kategorie (Abbildung 3). F
ur die Verteilung der Server gibt es drei
Ans
atze. Durch die reine Replikation des WF-Servers ergeb en sich identische Server, womit
jeder Teilschritt von jedem b eliebigen Server kontrolliert werden kann. Will man aus der Lo-
kation des Servers Vorteile ziehen, so gibt es zwei M
oglichkeiten. Man kann f
ur die Steuerung
eines Teilschrittes den Server verwenden, der sich auf dem Knoten der zugeh
origen Anwen-
dung b endet o der den, der sich b ei den vorgesehenen Bearb eitern der Aktivit
at b endet.
Diese Varianten werden im folgenden diskutiert.
C lie n tC lie n tC lie n tC lie n tC lie n tC lie n t
Server ServerServer
Abbildung 3
Architektur eines WfMSs mit mehreren Servern
2.1.2.1 Server sind identische Replikate
Beim ersten Ansatz werden identische Replikate der WF-Engine verwendet, die aus einer
WF-Datenbank und einem WF-Server b estehen. Alle Prozetyp en k
onnen von jedem dieser
Cluster ausgef
uhrt werden; eine Prozeinstanz verbleibt in dem Cluster, in dem sie gestartet
wurde. Die Cluster sind nicht an Gesch
aftsb ereiche gebunden.
In der WF-Datenbank sind die replizierte Schemainformation, die Instanzen des Clusters und
der diesen Cluster b etreende Teil der Arb eitslisten aller Benutzer gesp eichert. Jeder Client
mu eine Verbindung mit jedem Cluster aufbauen, da in jedem Cluster Auftr
age f
ur ihn
vorhanden sein k
onnen.
Durch die geeignete Wahl des Clusters b eim Prozestart (zuf
allig, zyklisch, lastabh
angig) kann
eine Lastbalancierung errreichtwerden. Dadurch b etr
agt die Last f
ur eine WF-Datenbank
Last
Strg
#
C luster
,wenn #
C l uster
Cluster verwendet werden. Der Ausfall einer WF-Datenbank
blo ckiert alle Instanzen des Clusters, die Instanzen anderer Cluster sind hiervon ab er nicht
5
b etroen. Da die Benutzer normalerweise auch Instanzen anderer Cluster b earb eiten, k
onnen
i.d.R. alle Benutzer, trotz des Ausfalls eines Clusters, zumindest eingeschr
ankt weiterarb eiten.
F
ur das Aktualisieren der Arb eitslisten stellen die Cluster einen Engpa dar. Da in der WF-
Datenbank Teile der Arb eitslisten aller Benutzer gesp eichert sind, mu jeder Server alle Be-
nutzer b edienen, woraus eine Last von
Last
AL
pro Server resultiert. Die Last f
ur das Aktuali-
sieren der Arb eitslisten kann also mit diesem Ansatz nichtverteilt werden, so da sehr groe
Benutzerzahlen nichtm
oglich sind.
Ein anderes Problem ergibt sich durch die Belastung des Netzwerks. Durch die Erh
ohung
der Anzahl der Teilnetze (auf die die Cluster verteilt werden) l
at sichzwar ihre Kommu-
nikationslast senken, ab er durch die zuf
allige Wahl des Clusters b eim Instanzstart werden
auch Cluster mit ung
unstiger Lage gew
ahlt. Dieses Problem ist b ei weitr
aumig verteilten
Systemen b esonders gravierend. So kann die Bearb eitung eines Prozesses zwar geographisch
b eschr
ankt sein, ab er durch die ungl
uckliche Wahl des Clusters f
ur eine Instanz st
andige
WAN-Kommunikation zur Steuerung notwendig werden.
2.1.2.2 Server nahe b ei Anwendung
Durch die Verwendung mehrerer identischer Server (Cluster) l
at sich die Last f
ur die
Ausf
uhrung der Workows auf diese Server verteilen, da die Instanzen gew
ohnlich unabh
angig
voneinander laufen. Das Problem b ei dieser reinen Replikation ist, da die Cluster alle diesel-
ben Benutzer hab en, so da jeder Server alle Benutzer b edienen mu. Nun ist die Situation
in unternehmensweiten WfMSen ab er meist nicht so, da alle Benutzer dieselb en Aufgab en
erledigen, sondern gewisse Anwendungen o der Teilschritte sind einer b estimmten Benutzer-
grupp e zugeordnet. Die dab ei entstehenden Grupp en sind nichtunb edingt disjunkt, ab er es
ist m
oglich, ihre Existenz im Sinne einer Clusterbildung auszunutzen, um eine geeignete Loka-
tion f
ur die Server zu w
ahlen. Da f
ur jeden Server jetzt nur no ch ein kleiner Teil der Benutzer
relevantist,mu er auch nicht mehr alle Arb eitslisten aktualisieren, was den Aufwand f
ur
diesen Vorgang erheblich reduziert. Bei der Verwendung von Polling (Abschnitt 2.2.1) ist al-
lerdings Vorsicht geb oten. Der Vorteil gehtverloren, wenn die Clients weiterhin alle Server
abfragen.
Bei diesem Konzept wird der Server dort plaziert, wo das Anwendungsprogramm der ent-
sprechenden Aktivit
at l
auft. Diese Variante wird vor allem von Systemen verwendet, die auf
einer ob jektorientierten Infrastruktur basieren. Die Anwendung ist dab ei als Ob jekt gekap-
selt, das an einem b estimmtenOrtimverteilten System allokiert ist. Dieser Ort wird auchf
ur
den WF-Server des zugeh
origen Teilschritts gew
ahlt. Die Prozeinstanz ist ein Ob jekt, das
zu dem jeweiligen WF-Server migriert. Eine andere M
oglichkeit ist, da lediglich Ob jektre-
ferenzen zwischen den Servern wandern und diese dann b ei der Verwendung der zugeh
origen
Parameter entfernt auf die entsprechenden Ob jekte zugreifen.
Sind #
Serv
WF-Server vorhanden, so b etr
agt die Last f
ur einen einzelnen Server-Knoten
b ei idealer Verteilung
Last
Strg
+
Last
Migr
#
Serv
. Die Migrationslast
4
Last
Migr
ist recht gro, da die
4
Bei der Migration m
ussen alle von zuk
unftigen Prozeschritten no chben
otigten Instanzdaten zum neuen
Server kopiert werden. Dies sind zum einen die Parameterdaten (die zusammen etliche MB umfassen k
onnen)
und zum anderen die Zustandsinformation der Instanz (z.B. in Form einer Ablaufhistorie ). Die konkrete Last
h
angt auer von der Gr
oe dieser Datenmenge auchvon der H
augkeit der Migrationen ab.
6
Ob jekte alle Instanzdaten enthalten. Auerdem migriert das Instanzenob jekt b ei jedem Teil-
schritt, selbst wenn er vom selb en Bearb eiter wie der Vorg
angerschritt ausgef
uhrt wird, da
gew
ohnlich eine andere Anwendung verwendet wird. Falls entfernt auf die Daten zugegrien
wird, entf
allt zwar
Last
Migr
,aber
Last
Strg
ist wesentlichgr
oer, da die Anwendungen mehr-
fach auf ein (evtl. weit) entferntes Ob jekt zugreifen. Ein generelles Problem des Ansatzes ist,
da die Verteilung der Last davon abh
angt, wie h
aug die einzelnen Anwendungen verwendet
werden. Dies l
at sich nicht immer steuern. Auerdem hat die Anwendung einen fest vorgege-
b enen Ort, der (unter Umst
anden weit) vom Bearb eiter entfernt ist. Dadurchentstehen hohe
Kommunikationskosten, da die gesamte Benutzerinteraktion
ub er das Netzwerk abgewickelt
werden mu.
Es ist schwierig, die Belastung der Server durch das Aktualisieren der Arb eitslisten zu b estim-
men. Ein Server mu prinzipiel l alle Benutzer b edienen, da die Verteilung nicht an Gesch
afts-
b ereichen (z.B. Abteilungen) orientiert ist, sondern an Anwendungen. Damit w
are die zu
bew
altigende Last
Last
AL
. Allerdings werden i.d.R. die meisten Benutzer nur wenige An-
wendungen verwenden d
urfen, da ihre Rolle sie auf b estimmte T
atigkeiten einschr
ankt. Die
Anzahl dieser Anwendungen sei durch eine kleine Konstante
k
beschr
ankt, so da f
ur jeden
Benutzer nur
k
Server relevant sind. Somit liegt die Last b ei
Last
AL
k
#
Serv
. Diese Annahme mu
ab er nicht gelten. Es sind Szenarien denkbar, in denen es zwar Abteilungen gibt, deren Mit-
arb eiter getrennte Prozesse b earb eiten, ab er mit denselb en Anwendungen. In einem solchen
Fall wird jede Anwendung von jedem Benutzer verwendet, womit keine Skalierbarkeit mehr
gegeb en ist.
Dieser Ansatz gehtvon der Annahme aus, da jede Anwendung einen eindeutig b estimmba-
ren Ort hat. Dies ist realistisch, wenn die Anwendung z.B. Datenbankzugrie macht. Dann
wird der Ort gew
ahlt, an dem die Daten physisch gesp eichert sind. Handelt es sich b ei der
Anwendung ab er um ein
ub erall verf
ugbares Programm, wie z.B. einen Editor, eine Textver-
arb eitung o der eine Eingab emaske, so wird durch die Anwendung kein Ort vorgegeb en. Die
Anwendung wird immer auf dem Rechner des (a priori unbekannten) Benutzers ausgef
uhrt,
der die Aktivit
at b earb eitet. Man k
onnte nun f
ur den WF-Server jeden b eliebigen Ort w
ahlen,
dies w
are ab er b ez
uglich der Kommunikationskosten sehr ung
unstig. Der n
achste Ansatz l
ost
dieses Problem.
2.1.2.3 Server nahe b ei Bearb eiter
Beim diesem Ansatz wird ein WF-Server verwendet, der nahe b ei den Bearb eitern liegt.
Dies ist m
oglich, da angenommen werden kann, da die meisten Aktivit
aten von Benut-
zern ausgef
uhrt werden, die alle derselb en Organisationseinheit angeh
oren. Damit ist deren
Gesch
aftsb ereich
5
eine gute Lokation f
ur den WF-Server.
Die Konzepte dieser Kategorie k
onnen danachunterschieden werden, ob eine Prozeinstanz
den WF-Server wechseln kann, also eine Migration m
oglich ist, o der nicht. Eine solche Mi-
gration ist sinnvoll, wenn es Prozesse gibt, die nacheinander in verschiedenen Organisations-
einheiten b earb eitet werden. Man denke an einen Proze, der zuerst die Verkaufsabteilung
5
Ein Gesch
aftsb ereichkann jede Art von organisatorischer Einheit (z.B. Abteilung, Zweigstelle o.
a.) sein.
Allerdings wird in diesem Zusammenhang gefordert, da der Gesch
aftsb ereichauch geographisch b eschr
ankt
ist.
7
durchl
auft und dann den Versand. Sind diese weit voneinander entfernt, so ist es wesent-
lich billiger, den gesamten Proze einmal zu migrieren, als die WAN-Verbindung f
ur jeden
weiteren Teilschritt zu verwenden. Ist keine Migration m
oglich, so wird von der Annahme
ausgegangen, da ein kompletter Proze weitgehend zu nur einem Gesch
aftsb ereich geh
ort.
Teilschritte, die in anderen Bereichen ausgef
uhrt werden, werden von dem nicht optimalen
Server gesteuert. Wird die Anzahl dieser Schritte zu gro, so kann
Last
Strg
sehr gro werden.
Ist eine Migration von Prozeinstanzen m
oglich, so kann jeder Teilschritt von dem f
ur ihn opti-
malen Server kontrolliert werden. Allerdings gehen einige dieser Ans
atze von der einschr
anken-
den Annahme aus, da alle p otentiellen Bearb eiter eines Teilschritts diesem Gesch
aftsb ereich
angeh
oren. Die Rollenau
osung erfolgt dann nur lokal f
ur die Benutzer dieses WF-Servers,
eine globale Rollenau
osung ndet nicht statt.
Wir analysieren zuerst die Variante ohne Migration: Angenommen von einem Server existieren
#
Serv
Replikate und die Last ist gleichm
aig zwischen ihnen verteilt. Da die Server f
ur
verschiedene Prozesse zust
andig sind, deren Daten unabh
angig voneinander sind, b etr
agt die
Last f
ur die Server und f
ur die WF-Datenbank
Last
Strg
#
Serv
.DasVerteilen der Last ist etwas
schwierig, da nur eine Zuordnung zwischen Prozetyp en und Gesch
aftsb ereichen m
oglich ist;
wegen der fehlenden Migrationsm
oglichkeit k
onnen Prozesse nur als Ganzes einem Server
zugeordnet werden. Sollte ein Prozetyp alleine schon einen Server
ub erlasten, gibt es keine
geeignete Verteilung.
Im Fall mit Migration ist die Einzellast in Idealfall
Last
Strg
+
Last
Migr
#
Serv
.Eskommen zwar die
Migrationskosten hinzu, ab er
Last
Strg
ist geringer, da durch die Migration f
ur jede Aktivit
at
ein geeigneter WF-Server ausgew
ahlt werden kann.
Die Belastung der Server durch das Aktualisieren der Arb eitslisten ist unabh
angig davon, ob
Migrationen m
oglich sind. Es ist sinnvoll anzunehmen, da ein Benutzer nicht in alle Proze-
typ en involviert ist. Deshalb ist jeder Server nur f
ur einen Teil der Benutzer zust
andig. Es
wird wieder angenommen, da f
ur jeden Benutzer nur
k
Server relevant sind. Der Aufwand
b etr
agt somit
Last
AL
k
#
Serv
. Erfolgt die Rollenau
osung nur lokal, so ist die Last nur
Last
AL
#
Serv
. Al-
lerdings hat diese Variante den Nachteil, da wenn ein Server ausf
allt, alle seine Benutzer
blo ckiert sind, da sie ihre Auftr
age nur von ihm erhalten. Auerdem sind manchmal Akti-
vit
aten w
unschenswert, die in mehreren Gesch
aftsb ereichen b earb eitet werden k
onnen (z.B.
Einholen einer Unterschrift von einem b eliebigen Abteilungsleiter). Diese sind b ei lokaler
Rollenau
osung nicht mo dellierbar. Des weiteren schr
ankt das Rollenkonzept die Replikation
der Server ein. Bei
Ub erlastung eines Servers ist es nichtm
oglich, die Last auf zwei Server
zu verteilen, da diese dann getrennte Gesch
aftsb ereiche mit disjunkten Benutzern darstellen
w
urden.
2.1.3 Voll verteilte WfMSe
Ein WF-Server und das zugeh
orige Teilnetz sind p otentielle Engp
asse eines Systems. Diese
k
onnen vermeiden werden, indem man (wie in Abbildung 4 dargestellt) v
ollig auf Server
verzichtet und die entsprechende Funktionalit
at in jedem Client realisiert. Die komplette
WF-Instanz migriert dann nach Beendigung einer Aktivit
at zum Rechner des n
achsten.
Dieser Ansatz f
uhrt zu einem hohen Aufwand b eim Ermitteln des Zustandes einer Instanz,
8
C lie n tC lie n tC lie n t
C lie n t
C lie n tC lie n t
Abbildung 4
Architektur eines voll verteilten WfMSs
da diese Information nicht mehr in einem o der einigen wenigen Servern steckt, sondern
ub er
das ganze System verteilt ist. Des weiteren wird b ei der Rollenau
osung eine verteilte Syn-
chronisation n
otig. Auch ist unklar, woher ein Client alle angemeldeten Benutzer mit einer
passenden Rolle f
ur den Nachfolgeschritt kennen soll. Dieses Problem kann dadurch umgangen
werden, da man auf die Rollenau
osung v
ollig verzichtet und jeder Aktivit
at einen eindeu-
tigen Bearb eiter zuordnet. Dies stellt ab er einen Verlust an Funktionalit
at bzw. Flexibilit
at
dar, der nicht b ei jeder Anwendung akzeptiert werden kann.
Die Last pro Knoten b etr
agt
Last
Strg
+
Last
Migr
#
Ben
. Da die Anzahl der Benutzer #
Ben
eines Sy-
stems viel gr
oer ist als die Anzahl der Server #
Serv
, ist dies ein viel b esserer Wert, als
b ei den in Abschnitt 2.1.2 b eschrieb enen Systemen. Das ist auchnotwendig, da die Arb eits-
stationen keine leistungsstarken Maschinen, sondern nur die Rechner der Benutzer sind. Die
Migrationslast ist b ei diesem Ansatz b esonders ho ch, weil die Prozeinstanz b ei fast jedem
Teilschritt migriert.
Der Aufwand je Clientf
ur das Aktualisieren der Arb eitslisten ist unabh
angig von der Anzahl
der Benutzer. Dies ist leicht einzusehen, wenn jeder Aktivit
at genau ein Bearb eiter zugeordnet
ist. Dies ist ab er auch dann der Fall, wenn eine globale Rollenau
osung durchgef
uhrt wird.
Die H
augkeit, mit der ein b estimmter Benutzer die Bearb eitung von Aktivit
aten b eendet, so
da er die Arb eitslisten der Nachfolger aktualisieren mu, ist unabh
angig von der Anzahl der
(anderen) Benutzer im System. Sie h
angt nur von der Zeit ab, die der Benutzer zum Bearb eiten
einer Aktivit
at b en
otigt. Nimmtman nun an, da i.d.R. wieder nur ein b estimmter Teil der
Benutzer von einem Arb eitslisten-Up date b etroen sind (n
amlich die eines Gesch
aftsb ereichs),
so entsteht dab ei ein konstanter Aufwand. Damit hat der Gesamtaufwand zum Aktualisieren
von Arb eitslisten f
ur jeden Benutzer eine konstante Gr
oe. Auch die Belastung der Teilnetze
stellt kein Problem dar, da es keine Flaschenh
alse im Netzwerk gibt. Die Arb eitsstationen
m
ussen allerdings auf ausreichend viele Teilnetze verteilt werden.
2.2 Arb eitslistenverwaltung
F
ur das Aktualisieren der Arb eitslisten gibt es prinzipiell zwei M
oglichkeiten. Entweder fragt
der WF-Client b eim Server nach
Anderungen in seiner Arb eitsliste nach(Polling) o der der
Server b enachrichtigt b ei
Anderungen die b etroenen Clients. Diese b eiden Metho den werden
im folgenden diskutiert.
2.2.1 Polling
Beim Polling wendet sich der Client an den Server, um seine aktuelle Arb eitsliste zu erhalten.
Dies kann auf die explizite Anforderung des Benutzers hin geschehen, in festen Zeitabst
anden
9
o der ereignisorientiert (z.B. b eim Beenden einer Aktivit
at). Dieses Verfahren wird z.B. im
System WorkParty [Sie95] verwendet. Unter der Annahme, da die #
Ben
Clients unabh
angig
voneinander p ollen, z.B. mit der festen Frequenz
freq
AL
, ist die durch das Aktualisieren der
Arb eitslisten erzeugte Last
Last
AL
=
freq
AL
#
Ben
.
2.2.2 Server aktualisiert die Arb eitslisten
Beim Aktualisieren der Arb eitslisten durchdenServer ist die Aufrufrichtung umgekehrt, d.h.
Client und Server tauschen ihre Rollen. Beim Polling kann es vorkommen, da ein Client eine
Aktualisierung seiner Arb eitsliste w
unscht, obwohl sie sich seit der letzten
Ub ertragung nicht
ge
andert hat
6
. Dies l
at sich nichtverhindern, da der Clientnicht
ub er die dazu notwendige
Information verf
ugt. Im Gegensatz dazu verf
ugt der Server
ub er diese Information. Er wei,
wann ein Eintrag in die Arb eitslisten eingef
ugt werden mu und wann er wieder entfernt
werden kann. Diese Information kann folgendermaen genutzt werden: der Server sendet einem
Clientnur dann eine neue Arb eitsliste, wenn sich diese ge
andert hat. Mit dieser Metho de
aktualisiert z.B. das System ProMInanD [Kar94] seine Arb eitslisten. Es ist auchm
oglich,
maximale Verz
ogerungszeiten f
ur das Erscheinen von Teilschritten in den Arb eitslisten der
Benutzer zu garantieren. Das Aktualisieren der Arb eitslisten durch den Server ist also die
geeignete Wahl, falls es Aktivit
aten mit hohem Aktualit
atsb edarf gibt.
Ein Problem dieses Verfahrens ist, da es zu einer sehr hohen Last f
uhrt, falls b ei jeder
Ande-
rung sofort alle b etroenen Arb eitslisten aktualisiert werden. Wenn dies ab er eine gewisse
Zeit verz
ogert wird und die
Anderungen geblo ckt
ub ertragen werden, so wird die Last auf
freq
AL
#
Ben
gedr
uckt, da es nun f
ur
Ub ertragungen zum selb en Benutzer einen Mindestab-
stand gibt. Die Last ist also so gro wie b eim p erio dischen Polling. Diese Optimierung ist in
dem Sinne exib el, da f
ur jeden Aktivit
atentyp eine maximale Verz
ogerungszeit deniert wer-
den kann, so da Anforderungen an den Aktualit
atsb edarf weiterhin erf
ullt werden k
onnen.
Im folgenden wird angenommen, da der Aufwand f
ur das Aktualisieren der Arb eitslisten
Last
AL
=
freq
AL
#
Ben
betr
agt, da sich dies b ei b eiden Verfahren realisieren l
at.
2.3 Datenu
Zwischen den Aktivit
aten eines Prozesses m
ussen Parameterdaten ausgetauschtwerden. Das
daf
ur verwendete Mo dell hat Auswirkungen auf den Umfang der zu transp ortierenden Daten.
So werden mehrfach gesp eicherte Daten unter Umst
anden b ei einer Migration auch mehrfach
ub ertragen o der Daten zu einer Aktivit
at transp ortiert, die gar nichtben
otigt werden. Das
Datenmo dell hat no ch andere Auswirkungen auf ein WfMS, z.B. auf die Mo dellierung. Auf
diese Asp ekte wird hier ab er nur am Rande eingegangen, da sie die Skalierbarkeit nichtbe-
treen. Bei den meisten der in Kapitel 3 b etrachteten Systeme ist nicht angegeb en, welches
Datenmo dell verwendet wird und es sind auchverschiedene denkbar, allerdings mit unter-
schiedlich hohen Kosten.
6
Dies ist insb esondere dann ein Problem, wenn das WfMS aus mehreren Servern b esteht, von denen die
Mehrzahl (fast) nie Aktivit
aten f
ur diesen Client hat, z.B. da sich der Client in einem anderen Gesch
aftsb ereich
b endet.
10
2.3.1 Ob jektmigrationsansatz
Elektronische Umlaufmapp en (Electronic Circulation Folders) [KRW90] werden vor allem in
dokumentenorientierten WfMSen wie ProMInanD [Kar94]verwendet. Dab ei wird die kom-
plette WF-Instanz zu dem Knoten, auf dem eine Aktivit
at ausgef
uhrt werden soll, kopiert.
Ein ECF enth
alt auer den Daten, die die Anwendungen b en
otigen (meist Dokumente), oft
auchnoch die komplette Schemainformation des Prozesses.
Da die WF-Instanz dem Bearb eiter einer Aktivit
at immer komplett zur Verf
ugung steht,
erm
oglicht dieses Mo dell eine hohe Flexibilit
at. So k
onnen von einer Aktivit
at auch Doku-
mente verwendet werden, die f
ur diesen Schritt eigentlich nichtvorgesehen waren. Auerdem
ist die komplette Prozeb eschreibung b ei jeder Instanz verf
ugbar, so da der Ablauf dieser
Instanz dynamischver
andert werden kann. Diesen Vorteilen stehen jedo chhohe Kommunika-
tionskosten und damit auch eine hohe Belastung f
ur die WF-Server gegen
ub er. Sie entstehen
dadurch, da auch nichtben
otigte Dokumente und die von den Anwendungen nichtverwen-
dete Ablaufb eschreibung vom Server zu den Clients und zur
uck transp ortiert werden.
Schwierigkeiten macht b eim Ob jektmigrationsansatz die Ausf
uhrung paralleler Zweige. Wird
derselb e ECF in mehreren Zweigen verwendet, so entsteht ein Problem am Synchronisations-
punkt. F
ur Dokumente, die in mehreren Zweigen ver
andert wurden, ist nichtentscheidbar,
welche Version verwendet werden soll. Dies kann zum Verlust von
Anderungen (lost up dates)
f
uhren.
2.3.2 Input-/Output-Container
In FlowMark [IBM96] werden die Ein- und Ausgab eparameter von Aktivit
aten aufeinander
abgebildet, d.h. f
ur jedes Eingab edatum eines Schrittes mu der Schritt und dessen Aus-
gab eparameter angegeb en werden, von dem der Wert
ub ernommen werden soll
7
. Auf diese
Weise wird der Datenu explizit mo delliert. Um nun in einem Schritt die Daten von schon
abgeschlossenen Aktivit
aten verwenden zu k
onnen, werden die Eingab econtainer aller Teil-
schritte physischgespeichert. Die Daten sind also redundantvorhanden, falls sie von mehreren
Teilschritten b en
otigt werden.
Der G
ultigkeitsb ereichvon Variablen ist immer auf einen Teilschritt b egrenzt, ihr Inhalt
kann lediglich b eim Schrittende anderen Variablen zuk
unftiger Schritte
ub ergeb en werden.
Da deshalb zwei Aktivit
aten nie eine gemeinsame Variable verwenden, k
onnen Synchronisa-
tionsprobleme nur dann auftreten, wenn der Datenu explizit so mo delliert wurde, da eine
Variable ihren Input von mehreren Schritten b ezieht. In diesem (leichterkennbaren) Fall ist
es die Aufgab e des WF-Designers, die gew
unschte Synchronisation sicherzustellen. Ein Nach-
teil dieses Ansatzes ist, da das Mo dellieren des kompletten Datenusses sehr aufwendig ist.
Des weiteren kann es notwendig werden, Daten durch eine Aktivit
at (d.h. durchdasAnwen-
dungsprogramm) durchzuschleussen, da f
ur Pr
adikate zur Beschreibung von Verzweigungen
nur die Daten aus dem Ausgab econtainer des unmittelbaren Vorg
angerschrittes verwendet
werden k
onnen.
7
Es ist auchm
oglich hier mehrere Aktivit
aten anzugeb en. Dies ist notwendig, um b ei Verzweigungen die Da-
ten aus dem jeweils durchlaufenen Zweig
ub ernehmen zu k
onnen. Werden mehrere Zweige parallel durchlaufen,
so kann dies allerding s zu lost up dates f
uhren.
11
Wird ein zentraler Server verwendet, so sind Input-/Output-Container sehr eektiv, da zu
einem Clientf
ur die Bearb eitung einer Aktivit
at nur die Daten transp ortiert werden m
ussen,
die (der Mo dellierung zufolge) wirklichben
otigt werden. Die Daten sind lediglich redundant
in der WF-Datenbank vorhanden, was keine groen Kosten verursacht. Anders sieht dies
aus, falls eine komplette Prozeinstanz zu einem anderen Server migriert werden soll. Dann
m
ussen die mehrfachvorhandenen Daten zum neuen Server kopiert werden, was sowohl den
Server als auch das Netzwerk b elastet. Eine Ausnahme bilden Subprozesse mit eigenem Input-
Container, die von einem entfernten WF-Server ausgef
uhrt werden sollen. Zu ihnen m
ussen
nur die wirklichben
otigten Daten dieses einen (zusammengesetzten) Schrittes transp ortiert
werden.
2.3.3 Globale Variablen
Das Konzept der prozeglobalen Variablen wird von WorkParty [Sie95 ] verwendet. F
ur einen
Proze k
onnen (wie die globalen Variablen in einem Programm) Variablen deniert werden.
F
ur jede Aktivit
at kann nun angegeb en werden, welche dieser Variablen sie liest bzw. schreibt.
Alle Variablen sind nur einfachvorhanden und zu einer Anwendung werden nur solche Daten
transp ortiert, die wirklichben
otigt werden. Bez
uglich der Kommunikationskosten ist dieser
Ansatz optimal. Allerdings k
onnen im Fall von parallelen Zweigen Zugriskonikte und lost
up dates auftreten. Diese lassen sich ab er z.B. dadurchverhindern, da die Variablen nur in
einem der parallelen Zweige geschrieb en werden k
onnen und in den anderen als read-only
Parameter mo delliert werden m
ussen.
3 Betrachtung konkreter Systeme
Entscheidend f
ur die Skalierbarkeit und Verf
ugbarkeit eines WfMSs ist die Art der Verteilung
seiner Komp onenten. Deshalb hab en wir im folgenden Systeme anhand des in Kapitel 2.1
eingef
uhrten Schemas klassiziert. Abbildung 5 zeigt die Systeme, die in diesem Kapitel
b eschrieb en und analysiert werden. Asp ekte, die unabh
angig vom Leistungsverhalten sind,
werden aus Platzgr
unden nur erw
ahnt. In Abschnitt 3.4 werden die b etrachteten WfMSe,
ihr Leistungsverhalten und ihre Besonderheiten zusammenfassend in tab ellarischer Form auf-
gef
uhrt.
3.1 Zentraler Server
Die meisten kommerziellen Systeme fallen in die in Abschnitt 2.1.1 b eschrieb ene Kategorie mit
einem zentralen Server. Einige dieser Systeme wurden so erweitert, da eine Zusammenarb eit
von mehreren Systemen desselb en Herstellers m
oglichist.
3.1.1 Prozeabwicklung durch ein einzelnes WfMS mit zentralem Server
In diese Kategorie fallen viele
kommerzielle Systeme
wie WorkParty [Sie95 ], ProMInanD
[Kar94] o der FlowMark [IBM96] bis Version 2.1. Sie verwenden einen zentralen WF-Server
12
WfMSe mit
m ehreren Servern
Server
nahe bei
Anwendung
id e n tisc h e
Replikate
Server
nahe bei
B earbeiter
Exotica
Cluster
CodAlf,
BPAFrame,
METEOR
2
MOBILE,
M ENTOR,
WIDE,
[B D 97]
kom m erzielle
System e,
Panta R hei,
[D H L 9 1 ]
Flow M ark
Domains
IN C A S Exotica/
FM Q M
WfMSe mit
zentralem Server
v o ll v e rte ilte
WfMSe
einzelnes
WfMS
koop.
WfMSe
keine
Rollen-
auflösung
globale
Rollen-
auflösung
W fM S-A rchitekturen
Abbildung 5
Klassikation der WfMSe nach der Art der Verteilung ihrer Komp onenten
o der zumindest eine zentrale WF-Datenbank (mit zentralem DB-Server), die zur Ausf
uhrung
jedes Teilschritts b en
otigt wird. Auch einige Forschungsans
atze (z.B.
Panta Rhei
[EG96],
[DHL91 ]
) setzen eine zentrale Kontrollinstanz voraus.
3.1.2 Prozeabwicklung durchko op erierende WfMSe mit zentralen Servern
Um h
ohere Benutzerzahlen zu erm
oglichen, hab en einige Hersteller ihre Systeme so erwei-
tert, da mehrere Server zusammenarb eiten k
onnen. Dadurchentsteht eine Mischform aus
einer zentralen Architektur und einer Architektur, b ei der mehrere Server verwendet wer-
den, die jeweils nahe b ei den jeweiligen Bearb eitern angesiedelt sind. Ein Beispiel hierf
ur ist
FlowMark
[IBM96] ab Version 2.2. Es wird erm
oglicht, einen Subproze in einem anderen
FlowMark System (Lo cal Domain) ausf
uhren zu lassen. Dies wird verwendet, wenn ein Teil
eines Prozesses von anderen Bearb eitern bzw. in anderen Gesch
aftsb ereichen ausgef
uhrt wird
als der Rest. Dieser Teil wird dann als Subproze mo delliert, mit der zus
atzlichen Angab e in
welchem System er ausgef
uhrt werden soll. Es ist zu b eachten, da es sich b ei den verschiede-
nen Lo cal Domains um getrennte Systeme handelt, die lediglichko op erieren. Dies zeigt sich
zum Beispiel daran, da Benutzer, die in b eiden Teilen des Prozesses angespro chen werden
sollen, auch in b eiden Systemen b ekanntgemachtwerden m
ussen.
Im Optimalfall wird die Last gleichm
aig auf alle #
Serv
Lo cal Domains verteilt und b etr
agt
damit wie b ei einem WfMS mit mehreren Servern
Last
Strg
#
Serv
. Sind die Benutzer in jeweils
k
Domains aktiv und gleichm
aig auf sie verteilt, dann ist der Aufwand f
ur das Aktualisie-
ren der Arb eitslisten
Last
AL
k
#
Serv
.Geh
ort ab er ein Groteil der Teilschritte zu einem einzigen
Gesch
aftsb ereich, so kann die Last in diesem Lo cal Domain bis auf
Last
Strg
+
Last
AL
an-
wachsen. Das System bietet keine Unterst
utzung f
ur das Zerlegen eines Domains, wie z.B. die
Identikation von Teilprozessen, die sichf
ur eine entfernte Ausf
uhrung eignen. Der Aufwand
f
ur das
Andern der Verteilung ist erheblich, da zuerst entsprechende Subprozesse gebildet
werden m
ussen, d.h. das WF-Mo dell ver
andert werden mu.
13
Ein solches System ist daher prim
ar dann geeignet, wenn die Verteilung oensichtlich ist, z.B.
weil getrennte Gesch
aftsb ereiche verwendet werden, zwischen denen die Benutzer weitgehend
disjunkt sind. Keiner dieser Gesch
aftsb ereiche darf jedo ch sogrowerden, da das lokale
System
ub erlastet ist. Besonders sinnvoll ist die Verteilung eines Prozesses, wenn Gesch
afts-
b ereiche weit voneinander entfernt sind, so da die Weitverkehrsverbindung nur b eim Starten
des Subprozesses, nicht ab er b ei jedem seiner Teilschritte b elastet wird.
3.2 WfMSe mit mehreren Servern
Im Gegensatz zu den eb en b eschrieb enen ko op erierenden Systemen mit je einem zentralen Ser-
ver wurden die Systeme dieser Kategorie als verteilte WfMSe konzipiert. Leider verf
ugen die
meisten von ihnen
ub er keine Werkzeuge, die den Mo dellierer b ei der Verteilung unterst
utzen
und die zu erwartende Last analysieren. Auch wird b ei den meisten Ans
atzen die Belastung
des Netzwerks nicht b etrachtet, so da Teilnetze
ub erlastet werden k
onnen.
3.2.1 Server sind identische Replikate
Der
Exotica-Cluster
-Ansatz [AKA
+
94] verwendet, wie in Abbildung 6 dargestellt, mehrere
identische Replikate des Servers, die sogenannten Cluster. Diese b estehen zwar wie in Ab-
schnitt 2.1.2.1 b eschrieb en aus je einer WF-Datenbank, enthalten ab er mehrere WF-Server.
Ein Clientmu sich mit nur einem WF-Server jedes Clusters verbinden, da durch die gemein-
same WF-Datenbank alle Server eines Clusters
ub er alle notwendigen Informationen verf
ugen.
WF-
DB
WF-
Server
WF-
Server
...
Cluster 1
...
C lie n t 1
C lie n t 2
...
C lie n t m
WF-
DB
WF-
Server
WF-
Server
...
Cluster n
Abbildung 6
Systemarchitektur b eim Exotica-Cluster-Ansatz
Die Verwendung mehrerer WF-Server in einem Cluster erh
oht die Verf
ugbarkeit, da ein Client
b eim Ausfall eines WF-Servers einen anderen Server dieses Clusters verwenden kann. Der
Ausfall der WF-Datenbank blo ckiert nat
urlichweiterhin den gesamten b etroenen Cluster.
Sind #
C l uster
und #
Serv
WF-Server je Cluster vorhanden, so b etr
agt die Last f
ur einen
Server
Last
Strg
#
C luster
#
Serv
. Da die Server eines Clusters alle Benutzer b edienen m
ussen, b etr
agt
14
die Last zum Aktualisieren der Arb eitslisten f
ur jeden Server
Last
AL
#
Serv
. Die WF-Datenbank
bildet hierb ei weiterhin einen Flaschenhals.
3.2.2 Server nahe b ei Anwendung
In diesem Abschnitt werden Systeme diskutiert, die auf dem im Abschnitt 2.1.2.2 b eschrieb e-
nen Konzept basieren, b ei dem der Ort des WF-Servers nahe dem Anwendungsob jekt gew
ahlt
wird.
In [SM96]werden die verwandten Systeme
Co dAlf
und
BPAFrame
beschrieb en, die auf un-
terschiedlicher ob jektorientierter Middleware basieren. W
ahrend Co dAlf eine ob jektorientier-
te Erweiterung des OSF DCE [Sch93]verwendet, basiert BPAFrame auf CORBA [OMG95].
Wie schon erw
ahnt, wird jede Anwendung in einem Ob jekt gekapselt. Ein solches Ob jekt hat
einen festen Ort, an dem sichauch der zugeh
orige WF-Server b endet, und wird als Runtime-
System b ezeichnet. Prozetyp en werden als Ob jekttyp en implementiert, die Prozeinstanzen
sind somit als Ob jekte realisiert. Sie enthalten auer den Anwendungsdaten auchnoch die
Prozeb eschreibung, es handelt sich also um einen Ob jektmigrationsansatz. Diese mobilen
Ob jekte migrieren zum Ort des Anwendungsob jektes der n
achsten Aktivit
at. Dieser Ort wird
ub er einer Trader ermittelt, der als Directory Service dient (also angibt, wosich ein geeigne-
tes Ob jekt b endet) und auerdem eine Lastverteilung vornimmt. Der erforderliche entfernte
Zugri auf Daten wird durchdieverwendeten Middleware-Dienste realisiert. Dasselb e gilt f
ur
den Zugri der Benutzer auf die entfernten Runtime-Systeme.
Wie schon erw
ahnt wurde, h
angt b ei diesem Ansatz die Last eines WF-Servers davon ab,
wie h
aug die zugeh
orige Anwendung verwendet wird. Falls es ab er m
oglich ist, den Anwen-
dungsserver zu replizieren, so sorgt der Trader f
ur eine Verteilung der Last.
METEOR
2
[DKM
+
97, MSKW96, SK97] verwendet einen Ansatz, der dem eb en b eschrieb e-
nen sehr
ahnlich ist. Er basiert eb enfalls auf CORBA. Allerdings ist die Ablaufb eschreibung
nicht in einem mobilen Instanzenob jekt enthalten, sondern sie wird in ihre Teilschritte (jeweils
mit Kanten zu vorangehenden und nachfolgenden Schritten) zerlegt. Aus dieser Information
wird f
ur jede Aktivit
at ein Teil des WF-Servers (Taskmanager genannt) erzeugt, der die
Ausf
uhrung genau dieses Teilschritts steuert. Ein Taskmanager kann prinzipiell an einem b e-
liebigen Ort allokiert werden, allerdings wird auch hier als geeignete Lokation der Ort der
Anwendung vorgeschlagen. Im Gegensatz zu den b eiden letzten Ans
atzen migrieren keine
Instanzenob jekte zwischen den Taskmanagern. Statt dessen werden b eim Weiterschalten des
Prozesses zum n
achsten Schritt Referenzen auf die verwendeten Datenob jekte
ub ergeb en.
Bei der Ausf
uhrung einer Aktivit
at mu dann auf die i.d.R. entfernt liegenden Datenob jekte
zugegrien werden. Schlielich wird in METEOR
2
der Ort der Anwendungen und der Task-
manager eindeutig festgelegt, so da die Aufgab e des Traders entf
allt. Dadurch ist ab er auch
keine dynamische Lastbalancierung m
oglich.
Der Ansatz b etrachtet auchnochweitere Asp ekte, wie das Recovery o der die h
auge Op era-
tion des Erfragens des aktuellen Zustands einer Prozeinstanz. Zu diesem Zweck gibt es einen
zentralen Monitoring-Service, dem die Taskmanager
Anderungen der Zust
ande melden. Au-
erdem werden ihm Referenzen auf verwendete Daten geschickt, um die Daten b eim Recovery
rekonstruieren zu k
onnen.
15
Auer der Last der WF-Server ist b ei diesem Ansatz auchnoch die Belastung des Monitoring-
Services interessant. Da diese zentrale Komp onente b ei der Ausf
uhrung jedes Teilschrittes
ub er
Anderungen informiert werden mu, ist ihre Last
Last
0
Strg
. Dab ei ist
Last
0
Strg
allerdings
viel kleiner als
Last
Strg
,danur Referenzen auf Daten
ub ertragen werden und nur einfa-
che Lese- und Schreib op erationen durchgef
uhrt werden. Aus diesem Grund ist diese zentrale
Komp onente bis zu einer sehr hohen Systemlast ausreichend. Etwas schlechter sieht die Ana-
lyse f
ur das Teilnetz aus, in dem der Monitoring-Service angesiedelt ist. Es werden zwar nur
kleine Pakete
ub ertragen, daf
ur ab er sehr viele. Dadurch wird der Zusatzaufwand, den das
Kommunikationsprotokoll verursacht, sehr gro.
Der Monitoring-Service stellt auch ein Problem f
ur die Verf
ugbarkeit dar. Da er f
ur das
Recovery notwendig ist, f
uhrt sein Ausfall zum Systemstillstand. Eine Replikation ist nicht
vorgesehen, sie w
urde im Fall einer Netzpartitionierung auchnichtverhindern, da der abge-
schnittene Teil (u.U. ist das der gr
oere Teil) blo ckiert ist.
3.2.3 Server nahe b ei Bearb eiter
Es gibt mehrere Systeme, die den in Abschnitt 2.1.2.3 b eschrieb enen Ansatz verfolgen, b ei dem
versucht wird, den WF-Server nahe b ei den p otentiellen Bearb eitern zu allokieren. Diese lassen
sich, wie in Tab elle 1 dargestellt, danach klassizieren, ob ein Proze den Server wechseln
kann. Der Zweck einer solchen Migration wurde schon erl
autert. Eine weitere Klassikation
ist danachm
oglich, ob ein System die Verteilung durch Analysen und Vorschl
age unterst
utzt,
o der ob diese Aufgab e dem Augenma des Mo dellierers
ub erlassen bleibt.
ohne Migration mit Migration
manuelle Verteilung
MOBILE MENTOR
WIDE
systemunterst
utzte Verteilung
| [BD97]
Tab elle 1:
Systeme, die die WF-Server in der N
ahe der jeweiligen Bearb eiter allokieren
MOBILE
[BHJ
+
96, HS96] verfolgt das Ziel, durchServerreplikation und Datenpartitionie-
rung die Last f
ur die einzelnen Server zu minimieren und dadurch eine m
oglichst hohe Ge-
samtlast zu b ew
altigen. Dazu werden die Aufgab en eines WF-Servers in sogenannte Asp ekte
zerlegt, wie z.B. einen funktionalen Asp ekt, den Kontollu und den Datenu. Jeder dieser
Asp ekte wird durch einen eigenen Server realisiert, die durch einen Kernel verbunden sind.
Ist ein solcher Server
ub erlastet, so wird er repliziert.
Das Synchronisationsproblem b ei
Anderung der Daten dieser Server wurde folgendermaen
gel
ost: Statische Daten, wie z.B. Schemadaten werden repliziert. Die Server f
ur verschiedene
Asp ekte hab en keine gemeinsamen Daten, auer der statischen WF-Id; diese wird repliziert.
Die anderen Daten lassen sich nach den Asp ekten partitionieren. Die verschiedenen Replika-
te eines Servers f
ur denselb en Asp ekt verwenden zwar dieselb en dynamischen Instanzdaten,
ab er jeder Workowtyp hat einen korresp ondierenden Gesch
aftsb ereich und damit einen fest
16
zugeordneten Server. Es werden also gesamte Prozesse einem WF-Server zugeordnet, eine
Migration ist nichtvorgesehen. Entsprechend dieser Zuordnung lassen sich diese Daten par-
titionieren.
Die Aufteilung in #
Asp
Asp ekte bringt b ei einer optimalen Verteilung der Last eine Reduktion
auf
Last
Strg
#
Asp
.Da#
Asp
ab er eine kleine Konstante ([BHJ
+
96]: 5 bis 7) ist, die angibt, in wieviele
logische Asp ekte man die Funktionalit
at eines WF-Servers aufteilen will, f
uhrt dies zu keiner
signikanten Reduktion der Last. Auch ist eine gleichm
aige Verteilung der Last zwischen den
Asp ekte-Servern unrealistisch, da deren Aufgab en v
ollig unterschiedlichen Aufwand erfordern.
Dazu kommt, da f
ur b estimmte Op erationen (wie z.B. die dynamische Restrukturierung eines
Ablaufgraphen) fast alle Asp ekte b en
otigt werden, so da durchdie Verteilung auf mehrere
Server ein zus
atzlicher Kommunikations- und Synchronisationsaufwand entsteht. Der durch
diese Metho de zus
atzlich erzielte Gewinn ist also fast vernachl
assigbar.
Das
MENTOR
-System [WWWK96a, WWWK96b, WWK
+
97, MWW
+
98] basiert auf ei-
nigen Standardkomp onenten, wie dem Transaktionsmonitor TUXEDO [UNI92], CORBA
[OMG95] und Statemate, einem Werkzeug zur Mo dellierung und Ausf
uhrung von State-/
Activitycharts. Dab ei wird in einem Statechart der Kontrollu und in einem Activitychart
der zugeh
orige Datenu und der funktionale Asp ekt eines Workows mo delliert. Kernidee
des Pro jektes ist es nun, die State-/Activitycharts so zu partitionieren, da eine zum zentralen
Fall
aquivalente verteilte Ausf
uhrung entsteht und jeder Teilschritt in einem zuvor f
ur ihn nach
Gesch
aftsb ereich festgelegten
"
Pro cessing Entity\ ausgef
uhrt wird. Der entsprechende Server
ist somit nur f
ur die ihm zugeordneten Teilschritte und f
ur die seinem Pro cessing Entity an-
geh
origen Benutzer zust
andig. Dies ist einer der Ans
atze, die auf eine globale Rollenau
osung
verzichten.
An den Zerlegungspunkten des State-/Activitycharts erfolgt ein Wechsel des Servers, d.h. die
komplette Prozeinstanz migriert zu einem anderen Server. Es werden nur globale Variablen
verwendet, deren
Anderungen durch einen in jedem Server vorhandenen Communication-
Manager propagiert werden. Alle Kommunikationen werden durch ein 2PC gesch
utzt, weshalb
die verwendeten Anwendungen das XA-Protokoll unterst
utzen m
ussen. Als Anwendungen las-
sen sichauchOverview-Panels generieren. Dies sind zentrale Komponenten, mit denen sich der
Zustand eines Prozesses verfolgen l
at. Ein Overview-Panel kann b ei sehr hohen Benutzerzah-
len zum Flaschenhals werden (vgl. METEOR
2
Monitoring-Service). Da das Overview-Panel
ab er nichtf
ur das Recovery verwendet wird und somit nichtunb edingt notwendig ist, ver-
schlechtert es die Verf
ugbarkeit nicht.
WIDE
[CGP
+
96, CGS97]verfolgt einen
ahnlichen Ansatz, allerdings ist die Skalierbarkeit
in diesem Pro jekt nur ein Teilasp ekt. Es wird auch ein Transaktionsmanagement auf ver-
schiedenen logischen Eb enen (Nested Transactions f
ur Teilschritte bzw. Sagas f
ur Prozesse)
angeb oten und mit Hilfe von aktiven Regeln ist eine Ausnahmeb ehandlung m
oglich. Die Idee
zur Verteilung ist analog zu MENTOR. Allerdings ist no chkeine Migration vorgesehen, son-
dern die Daten verbleib en an einem Ort und es wird entfernt mit Hilfe von CORBA auf sie
zugegrien. Dies kann zu den schon erw
ahnten hohen Kosten b ei mehrfachem weit entfernten
Zugri f
uhren.
In
[BD97]
wird auer den Servern auch die Netzstruktur b etrachtet, da auchTeilnetze durch
zuviel Kommunikation
ub erlastet werden k
onnen. Deshalb wird versucht, die Kommunikati-
17
onskosten zu minimieren, indem der Server f
ur jede Aktivit
at optimal gew
ahlt wird. Dazu wird
ein Teilschritt meist von dem Server kontrolliert, in dessen Teilnetz sich die meisten Benut-
zern mit einer passenden Rolle b enden. Die Aktivit
at wird ab er auch passenden Benutzern
in anderen Teilnetzen angeb oten, es ndet also eine globale Rollenau
osung statt.
Um das System zu optimieren, werden Algorithmen verwendet, die zur Mo dellierungszeit
laufen, also die Server nicht zus
atzlich b elasten. Die Algorithmen b erechnen eine Vertei-
lung durch die die Kommunikationskosten minimiert werden und analysieren die Last f
ur
die einzelnen Komp onenten (WF-Server, Teilnetze und Gateways). Bei diesen Kosten wird
die Kommunikation f
ur das Aktualisieren der Arb eitslisten und f
ur den Parametertransfer
b ei der Aktivit
atenausf
uhrung b er
ucksichtigt. Ab er auch die Migrationskosten und die Kom-
munikation von Anwendungen mit externen Datenquellen werden mit einb ezogen. Diese Al-
gorithmen b en
otigen nat
urlich gewisse Informationen, die b ei der Mo dellierung b ereitgestellt
werden m
ussen. Dies sind statistische Angab en, wie z.B. die H
augkeit der Ausf
uhrung einer
Instanz, die Belastbarkeit der Komp onenten o der die durchschnittliche Gr
oe der einzelnen
Parameterdaten.
Die Last f
ur WF-Server, WF-Datenbank und Teilnetz b etr
agt auch hier
Last
Strg
+
Last
Migr
#
Serv
. Die
Migrationskosten sind dab ei ab er niedriger als b ei MENTOR und WIDE, da nicht b ei jedem
Wechsel des Gesch
aftsb ereichs migriert werden mu
8
.
3.3 Voll verteilte WfMSe
Voll verteilte WfMSe, die v
ollig auf eine Rollenau
osung verzichten und damit einen Verlust
an Funktionalit
at akzeptieren, bilden die erste Unterkategorie. Es gibt ab er auch Beispiele
f
ur voll verteilte Systeme, die eine globale Rollenau
osung realisieren.
3.3.1 Systeme ohne Rollenau
osung
INCAS
[BMR94] ist ein System, das ohne Server auskommt und auf eine Rollenau
osung
verzichtet. Der Name kommtvon einem INformation CArrier, der einer elektronischen Um-
laufmapp e entspricht und jeweils zu der Arb eitsstation des n
achsten Schrittes migriert. Dieser
INCA enth
alt den gew
unschten Dienst, Regeln die den Daten- und Kontrollu b eschreib en,
die Daten der Instanz und Atomarit
atsanforderungen. Auch die Arb eitsstationen verf
ugen
ub er Regeln, die mit denen des INCA zusammen verwendet werden, um eine Aktivit
at aus-
zuf
uhren und den n
achsten Schritt zu b erechnen. F
ur diesen Nachfolgeschritt wird, eb enfalls
anhand der Regeln, die zugeh
orige Arb eitsstation b erechnet. Es ndet keine Rollenau
osung
statt, somit ist auchkeine Synchronisation zwischen den p otentiellen Nachfolgern notwendig.
Bei jedem Weiterschalten zum n
achsten Schritt wird der INCA ver
andert. Er wird allerdings
nicht mo diziert, sondern es wird eine neue Version von ihm erzeugt, die zusammen mit der
alten migriert. Regeln k
onnen sich damit auch auf alte Versionen von Daten b eziehen.
Es wird ein verl
aliches Kommunikationssystem verwendet, damit sich die Arb eitsstationen
nicht um Sicherheitsasp ekte b eim Transp ort des INCAs k
ummern m
ussen. Eine Besonder-
heit des Ansatzes ist, da das gesamte System durch Regeln gesteuert wird. Die Regelmenge
8
Es machtsicher keinen Sinn, wegen eines einzelnen Schrittes mit nur wenigen Bearb eitern und kleinen
Parameterdaten, die komplette Prozeinstanz zu einem anderen Server und zur
uckzukopieren.
18
ist sogar dynamisch, d.h. b ei der Ausf
uhrung einer Aktivit
at k
onnen Regeln erzeugt o der
ver
andert werden. Auch die Transaktionssemantik der Aktivit
aten wird mittels Regeln de-
niert. Allerdings ist eine groe, verteilte und dazu no ch dynamische Regelmenge schwer zu
durchschauen.
Die durch die Migration verursachte Last ist b ei diesem Ansatz b esonders ho ch, weil die
Prozeinstanz sehr gro ist, da sie die Ablaufb eschreibung und auchnoch die alten Versionen
der Daten enth
alt.
3.3.2 Globale Rollenau
osung
Exotica/FMQM
[AMG
+
95] ist eb enfalls ein voll verteilter Ansatz. Auch hier wird ein siche-
res Kommunikationssystem verwendet, n
amlichPersistent-Queues. Allerdings wird der Ablauf
nicht durch Regeln b eschrieb en, sondern wie in FlowMark durch einen Graphen mit Kontroll-
und Datenkonnektoren. Dieser Graph wird so auf die Knoten verteilt, da jeder Knoten dieje-
nigen Teile des Graphen erh
alt, die Schritte mit den Rollen seiner Benutzer enthalten. Ist die
Bearb eitung einer Aktivit
at b eendet, so werden Nachrichten an alle Knoten geschickt, die f
ur
Schritte verantwortlich sind, zu denen vom aktuellen Schritt aus Kontroll- o der Datenkanten
f
uhren. Die Daten werden b ei dieser Metho de schrittweise verteilt, sie migrieren nicht mit der
Prozeinstanz.
Exotica/FMQM siehtnach Beendigung einer Aktivit
at eine globale Rollenau
osung vor. Da-
mit kann eine Instanz nicht mehr einfach an den Knoten des nachfolgenden Schrittes gesendet
werden, sondern dieser mu erst ermittelt werden. Dazu informiert der Vorg
angerknoten alle
p otentiellen Nachfolger
ub er den zu vergeb enden Schritt, indem er die entsprechende Informa-
tion in deren Message-Queues schreibt. Diese holen sich dann die Instanz aus dessen Ausga-
b equeue, wenn sie die n
achste Aktivit
at ausf
uhren wollen. Die Synchronisation erfolgt durch
das Transaktionskonzept des Queueing-Systems. Dieses Verfahren f
uhrt zu einigen Schwierig-
keiten: Durch die Auswertung der von einem Schritt ausgehenden Datenkonnektoren lassen
sich lediglichdieSchritte ermitteln, die diese Daten b en
otigen. Es ist ab er no ch nichtbekannt,
an welchem Knoten diese Schritte sp
ater ausgef
uhrt werden. Deshalb m
ussen die Daten zu
allen p otentiellen Ausf
uhrungsknoten transp ortiert werden.
Auch b ei diesem Ansatz ist die Last gr
oer als b ei Ans
atzen mit Servern, allerdings aus ande-
ren Gr
unden als b ei INCAS. Diese sind zum einen die zu mehreren p otentiellen Nachfolgern
transp ortierten Daten. Ab er auchdie Verwendung von p ersistenten Message-Queues kann zu
einem Overhead f
uhren, da viele Systeme keine Op erationen ohne Transaktionsschutz zulas-
sen und somit ein in manchen F
allen unn
otiges 2PC erzwingen. Andere Systeme erlaub en
kein entferntes Lesen, so da dies durch mehrere andere Op erationen nachgebildet werden
mu. Des weiteren entsteht durchdie verteilte Rollenau
osung ein Synchronisationsaufwand.
3.4 System
ub ersicht
Tab elle 2 gibt einen
Ub erblick
ub er die in diesem Bericht b etrachteten Systeme. Er wer-
den der Aufwand eines Servers zur Ausf
uhrung der Aktivit
aten und zum Aktualisieren der
Arb eitslisten verglichen und die Besonderheiten der einzelnen Systeme zusammengefat.
19
Klasse System Last pro Komp onente Bemerkungen
Aktivit
atenausf. Arb eitsl.
zentraler
Server
kommerzielle
Systeme
Last
Strg
Last
AL
Daten zentral gesp eichert, meist nur 1
Server
Panta Rhei
Last
Strg
Last
AL
zentrales aktives DBMS
[DHL91]
Last
Strg
Last
AL
transaktionale Workows
FlowMark
Domains
Last
Strg
#
Serv
Last
AL
k
#
Serv
Subproze kann in anderem Domain aus-
gef
uhrt werden
mehrere
Server
Exotica Cluster
Last
Strg
#
C luster
Last
AL
identische Cluster, k
onnen alle Proze-
typ en ausf
uhren
Co dAlf,
BPAFrame
Last
Strg
+
Last
Migr
#
Serv
Last
AL
k
#
Serv
Anwendungen sind CORBA-Ob jekte,
WF-Server b ei Anwendung
METEOR
2
Last
Strg
#
Serv
Last
AL
k
#
Serv
CORBA-basiert, zentr. Monitoring-Serv.
MOBILE
Last
Strg
#
Serv
#
Asp
Last
AL
k
#
Serv
keine Migration
MENTOR
Last
Strg
+
Last
Migr
#
Serv
Last
AL
#
Serv
keine globale Rollenau
osung
WIDE
Last
Strg
#
Serv
Last
AL
#
Serv
siehe MENTOR, keine Migration
[BD97]
Last
Strg
+
Last
Migr
#
Serv
Last
AL
k
#
Serv
Verteilung u. Lastanalyse durch System
voll
verteilt
INCAS
Last
Strg
+
Last
Migr
#
Ben
konst.
keine Rollenau
osung
Exotica/FMQM
Last
Strg
+
Last
Migr
#
Ben
konst.
verteilte globale Rollenau
osung
Tab elle 2:
Vergleich der untersuchten WfMSe
4 Zusammenfassung und Ausblick
In diesem Beitrag wurden drei fundamentale Klassen von WfMS-Architekturen identiziert.
Dies sind zum einen Systeme mit einem zentralen Server. Da dieser einen p otentiellen Engpa
darstellt, mu b ei einer hohen Benutzerzahl ein entsprechend leistungsstarker und damit
teurer Rechner verwendet werden. Die daf
ur aktuell zur Verf
ugung stehende Technologie bildet
eine Ob ergrenze f
ur die Leistungsf
ahigkeit des WfMSs. Weitere Klassen bilden Systeme mit
mehreren Servern und Systeme ohne Server, b ei denen die Ablaufsteuerung vollst
andig verteilt
ist. Innerhalb dieser Klassen wurden jeweils no chUnterklassikationen vorgenommen. Einige
kommerzielle Systeme und Vorschl
age aus dem BereichderForschung wurden b ez
uglich dieser
Klassikation eingeordnet und auf ihre Skalierbarkeit hin untersucht.
Um eine geeignete WfMS-Architektur ausw
ahlenzuk
onnen, ist es notwendig, die jeweilige
Anwendung genau zu analysieren, um sie einem Anwendungsb ereich zuordnen zu k
onnen. In
Tab elle 3 wird f
ur verschiedene Anwendungsb ereiche eine geeignete Architektur vorgeschla-
gen. Diese Vorschl
age sind als
"
Tendenzaussagen\ und nicht als absolute Feststellungen zu
verstehen, da sich viele Anwendungen nicht eindeutig einem Bereich zuordnen lassen. Des
20
weiteren kann eine Anwendung auchnochweitere Eigenschaften hab en, die die Wahl der
Architektur b eeinussen (z.B. die Anforderung, da sicherheitsrelevante Schritte von dem
WF-Server der b earb eitenden Abteilung kontrolliert werden m
ussen).
Anwendungstyp empfohlene WfMS-Architektur
wenige Benutzer, wenig Last zentraler WF-Server (evtl. ko op erierend)
Arb eitsschritt wird jeweils von einer bzw. Server nahe b ei Bearb eiter
wenigen Organisationseinheiten b earb eitet
gesamter Proze in selb er Organisations- keine Migration
einheit
alle Bearb eiter eines Arb eitsschritts sind nur lokale Rollenau
osung
in selb er Organisationseinheit
Benutzer verwenden alle Arb eitsschritte, Server nahe b ei Anwendung
Anwendungen hab en festen Ort
Benutzer verwenden alle Arb eitsschritte identische Replikate des WF-Servers
und alle Anwendungen
Tab elle 3:
Geeignete Architekturen f
ur verschiedene Anwendungstyp en
Die Auswahl einer Architektur ist rechteinfach, falls eine Anwendung nur sehr wenige Be-
nutzer hat, keine hohe Last erzeugt und sichergestellt ist, da sich dies auch in Zukunft
nicht
andert. Dann f
allt die Wahl auf das einfachste Konzept, den zentralen Server. Im Fall
von unternehmensweiten WfMSen ist die Architektur am vorteilhaftesten, b ei der die WF-
Server nahe b ei den Bearb eitern allokiert werden. In diese Klasse fallen auch die meisten der
b etrachteten Systeme. Allerdings ist deren Verwendung nur m
oglich, wenn organisatorische
Einheiten identiziert werden k
onnen, denen jeweils b estimmte Prozeschritte zugeordnet
werden k
onnen. Ein solches System kann no ch optimiert werden, falls die Prozesse immer
fast vollst
andig einer Organisationseinheit zugeordnet werden k
onnen, o der falls immer alle
p otentiellen Bearb eiter eines Arb eitsschrittes derselb en Organisationseinheit angeh
oren. Ist
keine Zuordnung zwischen Organisationseinheiten und Arb eitsschritten m
oglich, ab er den An-
wendungen ist (fast) immer ein fester Ort zugewiesen, so kann dieses Optimierungsp otential
genutzt werden, indem dieser Ort als Lokation f
ur den WF-Server verwendet wird. Ist auch
diese Bedingung nichterf
ullt, so bleibt nur no ch die M
oglichkeit identische Replikate des Ser-
vers zu verwenden. Dab ei ist ab er zu b eachten, da die Belastung eines Clusters durch das
Aktualisieren der Arb eitslisten sehr gro werden kann. Die voll verteilte Architektur ist wegen
des hohen Grades an Verteilung der Information und der daraus resultierenden Nachteile (sie-
he Abschnitt 2.1.3) normalerweise nicht empfehlenswert. Lediglich in Ausnahmef
allen kommt
diese Variante in Frage. Ein Beispiel hierf
ur k
onnte ein extrem groes System sein, b ei dem
jede Aktivit
at direkt einem Bearb eiter zugeordnet ist.
Schlielich bleibt zu b emerken, da es no ch ein groes Potential f
ur die Entwicklung von Ar-
chitekturen f
ur unternehmensweite WfMSe gibt. Dab ei ist die Skalierbarkeit und Verf
ugbar-
keit ein wichtiger Asp ekt. Es ist ab er zu b eachten, da die Architektur auch Einu auf
die Funktionalit
at eines Systems hab en kann. F
ur die Performance ist es sicher von Vorteil,
21
die Prozeb eschreibungen zu kompilieren, zu zerteilen und die von einem Knoten b en
otigen
Fragmente hart in den Schedulern zu verdrahten (vgl. METEOR
2
[MSKW96]). Allerdings
macht dies dynamische Mo dikationen der Ablaufb eschreibung [RD98] nahezu unm
oglich.
Um b eispielsweise feststellen zu k
onnen, welche Eingab eparameter durch die Mo dikation
einer WF-Instanz (z.B. Auslassen eines Schrittes) nichtmehrversorgt sind, mu der gesamte
Prozegraph vorliegen und
Anderungen sind nur m
oglich, wenn der Prozegraph interpretiert
wird. Ab er auch andere Asp ekte, die in heutigen Systemen eb enfalls no ch nicht realisiert sind,
stellen gewisse Anforderungen an die Architektur. Beispiele hierf
ur sind das Zeitmanagement,
die Verwendung von Backup-Servern o der die Integration mobiler Clients.
Teil unserer zuk
unftigen Arb eit wird sein, den qualitativen Vergleich der Konzepte durch
quantitative Analysen zu erg
anzen. Dazu soll das Leistungsverhalten der einzelnen Ans
atze
f
ur verschiedene Anwendungsszenarien simuliert und die entstehende Last verglichen werden.
Literatur
[AKA
+
94] G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. G
unth
or und C. Mohan:
Failure Hand ling in Large Scale Workow Management Systems
.Technischer
Bericht RJ9913, IBM Almaden ResearchCenter, Novemb er 1994.
[AMG
+
95] G. Alonso, C. Mohan, R. G
unth
or, D. Agrawal, A. El Abbadi und M. Ka-
math:
Exotica/FMQM: A Persistent Message-BasedArchitecture for Distribu-
ted Workow Management
. In:
Proceedings of the IFIP Working Conference
on Information Systems for DecentralizedOrganisations
,Trondheim, August
1995.
[BD97] T. Bauer und P. Dadam:
A DistributedExecution Environment for Large-Scale
Workow Management Systems with Subnets and Server Migration
. In:
Second
IFCIS Conferenceon Cooperative Information Systems
, S. 99{108, Kiawah
Island, SC, Juni 1997.
[BHJ
+
96] C. Buler, P. Heinl, S. Jablonski, H. Schuster und K. Stein:
Architektur von
unternehmensweit einsetzbaren Workow-Management{Systemen
.In:
Procee-
dings of MobIS 96, Rundbrief des GI-Fachausschusses 5.2
, S. 73{77, Oktob er
1996.
[BMR94] D. Barbara, S. Mehrotra und M. Rusinkiewicz:
INCAS: A Computational Mo-
del for Dynamic Workows in Autonomous Distributed Environments
.Techni-
scher Bericht, Matsushita Information Technology Lab oratory, Princeton, NJ,
Mai 1994.
[CGP
+
96] F. Casati, P. Grefen, B. Pernici, G. Pozzi und G. Sanchez:
WIDE: Workow
Model and Architecture
.Technischer Bericht CTIT 96-19, UniversityofTwen-
te, 1996.
[CGS97] S. Ceri, P. Grefen und G. Sanchez:
WIDE { A DistributedArchitecture for
Workow Management
. In:
Seventh International Workshop on Research Is-
sues in Data Engineering
, Birmingham, April 1997.
22
[DHL91] U. Dayal, M. Hsu und R. Ladin:
ATransactional Model for Long-Running
Activities
.In:
Proceedings of the 17th International Conferenceon Very Large
Data Bases
, S. 113{122, Barcelona, September 1991.
[DKM
+
97] S. Das, K. Ko chut, J. Miller, A. Sheth und D. Worah:
ORBWork: A Relia-
ble Distributed CORBA-based Workow Enactment System for METEOR
2
.
Technischer Bericht #UGA-CS-TR-97-001, Department of Computer Science,
University of Georgia, Februar 1997.
[EG96] J. Eder und H. Groiss:
Ein Workow-Managementsystem auf der Basis aktiver
Datenbanken
. In: J. Becker, G. Vossen (Herausgeb er):
Gesch
aftsprozemodel-
lierung und Workow-Management
.International Thomson Publishing, 1996.
[Elm92] A.K. Elmagarmid:
Database Transaction Models for Advanced Applications
.
Morgan Kaufmann Publishers, 1992.
[GHS95] D. Georgakop oulos, M. Hornick und A. Sheth:
An Overview of Workow Ma-
nagement: From Process Modeling to Workow Automation Infrastructure
.
Distributed and Parallel Databases, 3(2):119{152, April 1995.
[HS96] P. Heinl und H. Schuster:
Towards a Highly Scaleable Architecture for Workow
Management Systems
. In:
Proceedings of the 7th International Conferenceand
Workshop on Database and Expert Systems Applications, DEXA'96
, S. 439{
444, Z
urich, September 1996.
[IBM96] IBM:
FlowMark { Modeling Workow, Version 2 Release 2, Document Num-
ber: SH19-8241-01
, 2. Auage, Februar 1996.
[KAGM96] M. Kamath, G. Alonso, R. G
unth
or und C. Mohan:
Providing High Availa-
bility in Very Large Workow Management Systems
.In:
Proceedings of the
5th International Conference on Extending Database Technology
, S. 427{442,
Avignon, M
arz 1996.
[Kar94] B. Karb e:
Flexible Vorgangssteuerung mit ProMInanD
. In: U. Hasenkamp,
S. Kirn, M. Syring (Herausgeb er):
CSCW { Computer SupportedCooperative
Work
, S. 117{133. Addison-Wesley, 1994.
[KRW90] B. Karb e, N. Ramsp erger und P.Weiss:
Support of Cooperative Work by Elec-
tronic Circulation Folders
. In:
Conference on Oce Information Systems,
IEEE Computer Society
, S. 109{117, Cambridge, MA, 1990.
[Ley97] F. Leymann:
Transaktionsunterst
utzung f
ur Workows
. Informatik Forschung
und Entwicklung, Themenheft Workow-Management, 12(2):82{90, 1997.
[MSKW96] J. A. Miller, A. P. Sheth, K. J. Ko chut und X. Wang:
CORBA-BasedRun-
Time Architectures for Workow Management Systems
. Journal of Database
Management, Sp ecial Issue on Multidatabases, 7(1):16{27, 1996.
[MWW
+
98] P. Muth, D. Wo dtke, J. Weienfels, A. Kotz-Dittrich und G. Weikum:
From
Centralized Workow Specication to Distributed Workow Execution
. Journal
of Intelligent Information Systems, Sp ecial Issue on Workow Management,
10(2), M
arz 1998.
23
[OMG95] OMG:
Object Management Architecture Guide
. John Wiley & Sons, 3. Auflage,
Juni 1995.
[RD98] M. Reichert und P.Dadam:
ADEPT
flex
{Supporting Dynamic Changes of
Workows Without Loosing Control
. Journal of Intelligent Information Sy-
stems, Sp ecial Issue on Workow Management, 10(2), M
arz 1998.
[Sch93] A. Schill:
DCE - Das OSF Distributed Environment, Einf
uhrung und Grund-
lagen
. Springer Verlag, 1993.
[Sie95] Siemens Nixdorf:
WorkParty { Benutzerhandbuch, Version 2.0
, August 1995.
[SK97] A. Sheth und K. J. Ko chut:
Workow Applications to Research Agenda: Sca-
lable and Dynamic Work Coordination and Col laboration Systems
.In:
Pro-
ceedings of the NATO Advanced Study Institute on Workow Management
Systems and Interoperability
, S. 12{21, Istambul, August 1997.
[SM96] A. Schill und C. Mittasch:
Workow Management Systems on Top of OSF
DCE and OMG CORBA
. Distributed Systems Engineering, 3(4):250{262, De-
zember 1996.
[UNI92] UNIX System Lab oratories:
TUXEDO System Release 4.1 { Product Overview
and Master Index
.Prentice Hall, 1992.
[WWK
+
97] G. Weikum, D. Wo dtke, A. Kotz-Dittrich, P. Muth und J. Weienfels:
Spezi-
kation, Verikation und verteilte Ausf
uhrung von Workows in MENTOR
.
Informatik Forschung und Entwicklung, Themenheft Workow-Management,
12(2):61{71,1997.
[WWWK96a] J. Weienfels, D. Wodtke, G. Weikum und A. Kotz-Dittrich:
The Mentor Ar-
chitecture for Enterprise-wide Workow Management
. In:
Proceedings of the
NSF Workshop on Workow and Process Automation in Information Systems
,
S. 69{73, Athens, Mai 1996.
[WWWK96b] D. Wodtke, J. Weienfels, G. Weikum und A. Kotz-Dittrich:
The Mentor Pro-
ject: Steps Towards Enterprise-Wide Workow Management
. In:
Proceedings
of the 12th IEEE International Conference on Data Engineering
, S. 556{565,
New Orleans, LA, M
arz 1996.
24