scieee Science in your language
[en] (orig)
Variable Migration von Workows in
AD E P T
Thomas Bauer, Peter Dadam
Abteilung Datenbanken und Informationssysteme
Universit
at Ulm
f
bauer, dadam
g
@informatik.uni-ulm.de
Zusammenfassung
Bei groen, unternehmensweiten Workow (WF)-Anwendungen k
onnen die Belastung der
WF-Server und das Kommunikationsaufkommen in den zugrundeliegenden Teilnetzen zum
Engpa werden. In diesem Beitrag wird gezeigt, wie eine verteilte WF-Steuerung dergestalt
realisiert werden kann, da die Belastung der b eteiligten Komp onenten zur Ausf
uhrungszeit
minimiert wird. Dazu kann die WF-Steuerung einer Instanz von einem WF-Server auf einen
anderen migrieren. Ausgehend von den Bearb eiterzuordnungen wird zur Mo dellierungszeit
f
ur alle Aktivit
aten jeweils der optimale WF-Server ermittelt. Da Bearb eiterzuordnungen von
vorangegangenen Aktivit
aten abh
angen k
onnen, ist eine statische Serverzuordnung nicht im-
mer angebracht. Deshalb werden sog. logische Serverzuordnungsausdr
uckeeingef
uhrt, durch
die eine dynamische Serverzuordnung ohne aufwendige Laufzeitanalysen m
oglich wird.
1 Motivation und Einf
uhrung
Workow-Management-Systeme (WfMSe) stellen eine vielversprechende Technologie f
ur die
Realisierung vorgangsorientierter, unternehmensweiter verteilter Anwendungssysteme dar
[LR97]. Durch die Separierung der Ablauf logik des Gesch
aftsprozesses (GP) vom eigentlichen
Applikationsco de lassen sich derartige Anwendungen in der Regel rascher und mit weniger
Fehlerrisiken b ehaftet erstellen, als dies mit konventioneller Implementierungstechnik m
oglich
ist, b ei der die Prozelogik
"
hart verdrahtet\ im Applikationsco de enthalten ist. Aus densel-
ben Gr
unden lassen sich WfMS-basierte Anwendungssysteme in der Regel sehr viel rascher
und kosteng
unstiger an
Anderungen des Gesch
aftsprozesses anpassen. WfMS-basierte Anwen-
dungssysteme weisen in den meisten F
allen die in Abb. 1 illustrierte Softwarearchitektur auf,
die auch wir im folgenden unterstellen wollen. Ein o der mehrere WF-Server verwalten den ak-
tuellen Status der laufenden Prozeinstanzen, sie aktualisieren unter anderem (entweder aktiv
Ulmer Informatik-Berichte, Nr. 98-09, September 1998
o der
"
on demand\ ) die Arb eitslisten der WF-Klienten und informieren die Klienten, welche
Anwendung (mit welchen Aufrufparametern) mit einem b estimmten Prozeschritt verbunden
ist. Der Aufruf einer Applikationsfunktion, d.h. eines Anwendungsprogramms bzw. einer b e-
stimmten Funktion eines Anwendungsprogramms, erfolgt in der Regel durch den jeweiligen
Klienten. Wie in Abb. 1 angedeutet,
"
kennt\nur der WF-Server den Prozeablauf. Die Kli-
enten rufen im wesentlichen nur einzelne Applikationsfunktionen auf.
Anderungen im Proze
schlagen daher, eine geeignete Implementierung der Prozeablaufsteuerung und Applikati-
onsfunktionen vorausgesetzt, nicht(odernur in geringem Mae) auf die Implementierung der
Klienten durch.
A1 A2 A3
A4 A5 A6
A7 A9
D atenhaltung
A nw endungen
D atenhaltung
WF-Server
W o rk flo w -
In stan z
Instanz-
status
ru ft
ist a sso z ie rt m it
nächster Schritt
A8
W orkflow -Server
A pplikationsfunktionen
Klient 1
Klient n
Abbildung 1
Aufbau eines WfMS-basierten Anwendungssystems.
Ab er nichtnur die raschere Realisierung und Anpassung vorgangsorientierter Anwendungs-
systeme sprechen f
ur den Einsatz eines WfMSs. Mo derne WfMSe erlaub en dar
ub er hinaus,
den einzelnen Prozeschritten auf sehr variable Weise geeignete Bearb eiter zuzuweisen, denen
der jeweilige Prozeschritt, wenn er zur Ausf
uhrung ansteht, durch das System zur Bearb ei-
tung angeb oten wird. So kann man zum Beispiel festlegen, da ein b estimmter Prozeschritt
gleichzeitig allen Personen angeb oten wird, welche eine b estimmte Funktion (
"
Rolle\ ) inne-
hab en, o der man kann etwa b estimmen, da es derselb e Bearb eiter sein soll, der auch den
vorherigen Schritt ausgef
uhrt hat, o der man kann das System anweisen, explizit eine ande-
re Person f
ur die Bearb eitung zu w
ahlen, etwaum ein
"
Vier-Augen-Prinzip\ zu realisieren.
Weitere Varianten ergeb en sichinVerbindung mit Vertretungsregelungen.
Die ob en skizzierte Funktionalit
at und Flexibili t
at hab en ab er auch ihren Preis. Sehr viele
Ausf
uhrungsentscheidungen, allen voran die Bestimmung der f
ur eine b estimmte T
atigkeit
zu einem b estimmten Zeitpunkt konkret in Frage kommenden Bearb eiter, k
onnen WfMS-
2
seitig in der Regel erst zur Laufzeit getroen werden. Dies b edeutet, da in der Mehrzahl
der F
alle f
ur jeden zur Ausf
uhrung anstehenden Arb eitsschritt Kommunikation zwischen Ser-
ver und Klient, in manchen F
allen sogar zwischen dem Server und allen seinen Klienten,
erforderlich wird. Der Durchsatz bzw. das Antwortzeitverhalten eines WfMS-basierten An-
wendungssystems wird daher ganz wesentlichvon der Leistungsf
ahigkeit bzw. der Belastung
der WF-Server und des Kommunikationsnetzes b estimmt. Insb esondere im Hinblick auf groe,
unternehmensweit ablaufende,
"
transaktionale\ WfMS-basierte Anwendungen mit vielleicht
hunderten von Benutzern und tausenden von aktiven WF-Instanzen m
ussen geeignete Kon-
zepte entwickelt werden, die sowohl eine
Ub erlastung der WF-Server als auch des Kommu-
nikationssystems vermeiden helfen. In diesem Beitrag wollen wir uns diesb ez
uglich auf den
Kommunikationsasp ekt konzentrieren.
Wir gehen im folgenden davon aus, da das Kommunikationsnetz, wie heute
ublich, aus
mehreren physischen Teilnetzen aufgebaut ist. Die Herausforderung b estehtnun darin, das
Kommunikationsaufkommen zwischen WF-Server(n) und WF-Klienten so auf die verschie-
denen Teilnetze zu verteilen, da kein Teilnetz
ub erlastet ist. Der grunds
atzliche Ansatz b e-
steht darin, die WFs derart in logische Abschnitte aufzuteilen und jeden dieser Abschnitte
durch einen geeigneten WF-Server so steuern zu lassen, da die Kommunikation zwischen
dem jeweils steuernden WF-Server und den f
ur diesen
"
WF-Abschnitt\ relevanten Klienten
m
oglichst innerhalb eines Teilnetzes abgewickelt werden kann. Es wird also angestrebt, teil-
netz
ub ergreifende Kommunikation m
oglichst zu vermeiden. Dies b edeutet, da die Steuerung
einer WF-Instanz unter Umst
anden abschnittsweise von verschiedenen WF-Servern wahrge-
nommen wird. Es ndet also eine
"
Migration\der
"
WF-Steuerung\ statt.
In [BD97] hab en wir ein Werkzeug bzw. ein Verfahren b eschrieb en, das dem WF-Mo dellierer
zu analysieren erlaubt, welche Abschnitte einer gegeb enen WF-Vorlage welchem WF-Server
zur Steuerung zugeordnet werden sollten, um sp
ater, b ei Ausf
uhrung von WF-Instanzen dieses
Typs, eine m
oglichst g
unstige Lastverteilung zu erhalten. Das Verfahren analysiert im Prinzip,
welche Rolle (Komp etenz) f
ur die Ausf
uhrung einer T
atigkeit
T
erforderlich ist und welche
Klienten in den Teilnetzen
L
1
und
L
2
diese Rolle aufweisen. Daraus werdendanndie Wahr-
scheinlichkei ten abgeleitet, mit denen Aufgab en vom Typ
T
von einem Klienten in Teilnetz
L
1
bzw. von einem Klienten in Teilnetz
L
2
ausgef
uhrt werden, und die erwarteten Kommu-
nikationskosten b estimmt. Im eigentlichen Optimierungsschritt wird dann die WF-Vorlage so
partitioniert und abschnittsweise den vorhandenen WF-Servern der Teilnetze zugeordnet, da
die Kommunikation zur Laufzeit zu einem (wahrscheinlich) hohen Grad jeweils lokal innerhalb
eines Teilnetzes abgewickelt werden kann. Der f
ur die Migration erforderliche Zusatzaufwand
wird b ei diesen Kostenabsch
atzungen nat
urlichber
ucksichtigt.
3
Das in [BD97]vorgestellte Verfahren f
uhrt diese Analyse und die Festlegung der WF-Server
vollst
andig zur Mo dellierungszeit durch. Das heit b ereits zum Mo dellierungszeitpunkt wird
die Entscheidung f
ur o der gegen eine b estimmte Partitionierung gef
allt und auch, welcher
WF-Server ggf. die jeweilige
"
Abschnittssteuerung\
ub ernimmt. Man kann deshalb auch
von einer
"
statisch denierten Migration\ , im folgenden kurz
"
statische Migration\ genannt,
sprechen. Die statische Migration f
uhrt dann zu guten Ergebnissen, wenn Bearb eiterzuord-
nungen der Art
"
Rolle
=
Ar z t
"
,
"
Rol l e
=
P f leg ekraf t
^
Abteil ung
=
C hir ur g ie
"
o der
"
Dr: B r ink mann
_
Dr:Frank
"
verwendet werden, da in diesen F
allen die Menge der Bear-
b eiter (als Voraussetzung f
ur die Berechnung der Wahrscheinlichkeiten (siehe ob en)) b ereits
zur Mo dellierungszei t ermittelt werden kann.
1
Es kann jedo chauch Bearb eiterzuordnungen
geb en, die von anderen Aktivit
aten abh
angen (abh
angige Bearb eiterzuordnungen). So kann
z.B. festgelegt sein, da derselb e Arzt, der einen Patienten untersucht hat (Aktivit
at
x
), auch
den zugeh
origen Arztbrief schreib en soll (Nachfolgeaktivit
at
k
0
), o der da ein Patientvon
einer Pegekraft derjenigen Abteilung versorgt werden soll (Aktivit
at
k
), auf der er zuvor
untersucht wurde (siehe Abb. 2). Erst nachdem Aktivit
at x ausgef
uhrt wurde, steht in diesem
Fall die Organisationseinheit (OE) der Bearb eiter der weiteren Aktivit
aten (
k
und
k
0
) fest.
x: Patient untersuchen k': A rz tb rie f sc h re ib e n
Bearb(x)
R o lle = A rzt
k: P a tie n t v e rso rg e n
R o lle = P fle g e k ra ft
Ù
OE = OE(Bearb(x))
Abbildung 2
Beispiele f
ur Bearb eiterzuordnungen, die von anderen Aktivit
aten abh
angig sind.
Abh
angige Bearb eiterzuordnungen lassen sich im Prinzip zwar mittels b edingter Wahrschein-
lichkeiten eb enfalls b eschreib en und k
onnten daher im Prinzip in analoger Weise b ehandelt
werden. Dies f
uhrt jedo ch aufgrund der statistisch gesehen kleinen Fallzahl, in Verbindung
mit einer meist groen kombinatorischen Vielfalt, in der Regel nicht zu wirklich brauchbaren
Resultaten. Das heit die Festlegung des WF-Servers zur Mo dellierungszeit wird in diesen
F
allen h
aug nichtzudengew
unschten optimalen Kommunikationskosten f
uhren. Eine Fest-
legung zur Laufzeit w
are hier g
unstiger. Die Unterst
utzung der Serverauswahl zur Laufzeit,
also von variablen Migrationen, ist das zentrale Thema dieses Beitrages.
Im n
achsten Abschnitt werden die Voraussetzungen f
ur die Anwendbarkeit des Verfahrens
gekl
art. Abschnitt 3 diskutiert die Problemstellung und m
ogliche L
osungsans
atze. Den Kern
des Beitrags bildet Abschnitt 4 mit der Beschreibung der Algorithmen zum Ermitteln ei-
ner optimalen Verteilung. In Abschnitt 5 werden verwandte Ans
atze diskutiert. Der Artikel
schliet mit einer Zusammenfassung und einem Ausblick auf weitere Arb eiten.
1
Wob ei vereinfachend unterstellt wird, da sich an den Gr
oenordnungen { und damit an den Wahrschein-
lichkeitsvertei l ung en { bis zur Ausf
uhrung von Instanzen dieses WF-Typs nichts wesentlich
andert.
4
2 Einb ettung und Rahmenb edingungen
Der nachstehend vorgestellte Ansatz b eschreibt, wie Lastverteilung mittels variabler Migra-
tion in
AD E P T
distr ibution
,der verteilten Variante des
AD E P T
-Systems [DKR
+
95, RD98],
realisiert wird. Um m
oglichst allgemeing
ultig zu bleib en, werden wir im folgenden jedo chvon
den sp eziellen Eigenschaften des
AD E P T
-Systems und den damit verbundenen sp eziellen
Herausforderungen, wie die Unterst
utzung von Ad-ho c-Abweichungen, abstrahieren. In der
weiteren Diskussion wird lediglichvon den folgenden Annahmen ausgegangen:
1. Das WfMS verf
ugt
ub er ein Organisationsmo dell, in dem sowohl Personen sowohl mit
OEen in der Aufbauorganisation als auch mit Rollen assoziiert werden k
onnen.
2. Die Zuordnung von Bearb eitern zu einem zur Bearb eitung anstehenden WF-Schritt (T
atig-
keit) erfolgt in der Regel zur Laufzeit mittels eines Auswahlpr
adikats, wie z.B.
"
Rol l e
=
Ar z t
^
O r g anisationseinheit
=
Radiol og ie
"
. Es wird angenommen, da sich, mit Aus-
nahme von abh
angigen Bearb eiterzuordnungen, der tats
achliche Bearb eiter einer Aktivit
at
unabh
angig von anderen Arb eitsschritten ergibt.
3. Das WfMS verwendet mehrere Teilnetze sowie mehrere WF-Server. Zur Vereinfachung der
Diskussion wird angenommen, da jedes b etrachtete Teilnetz
ub er einen (und nur einen)
eigenen WF-Server verf
ugt, und da jeder dieser WF-Server im Prinzip f
ur jeden WF-
Typ und jeden WF-Abschnitt zur Steuerung eingesetzt werden kann. Jeder Benutzer des
WfMSs (WF-Klient) hat ein fest zugeordnetes Teilnetz.
4. Jeder WF-Server kann alle b eim WfMS angemeldeten WF-Klienten b edienen, nichtnur
diejenigen, die sichinseinemTeilnetz (Domain) b enden.
5. Die p otentiell m
oglichen Bearb eiter f
ur einen gegeb enen WF-Schritt b enden sichnicht
notwendigerweise immer im selb en Teilnetz.
2
3 Problemstellung
Wie b ereits ob en erw
ahnt, ist es das Ziel unseres Ansatzes, Serverzuordnungen zu erhal-
ten, durchwelche die Kommunikationskosten minimiert werden. Dab ei soll insb esondere der
ob en b eschrieb ene Fall abh
angiger Bearb eiterzuordnungen b er
ucksichtigt werden. F
ur die Zu-
ordnung von WF-Servern zu Aktivit
aten gibt es im Prinzip mehrere Vorgehensweisen: Die
einfachste und am h
augsten verwendete Metho de ist, jeder Aktivit
at zur Mo dellierungszeit
o der b eim Start des WFs fest (statisch) einen Server zuzuordnen. F
ur WFs mit abh
angigen
2
W
are dies immer der Fall, dann w
are keine variable Migration erforderlich. Alle Entscheidungen k
onnten
b ereits zur Mo dellierung szei t getroen werden (statische Migration).
5
Bearb eiterzuordnungen, welche in der Praxis h
aug anzutreen sind, ist diese L
osung unbe-
friedigend. Die b esten Serverzuordnungen w
urde man nat
urlich erhalten, wenn jeweils nach
Beendigung einer Aktivit
at der WF-Server f
ur die Nachfolgeaktivit
at aktuell b estimmtwer-
den w
urde. F
ur diese Auswahl st
unden dann die kompletten und aktuellen Laufzeitdaten der
WF-Instanz zur Verf
ugung, so da der tats
achlich am b esten geeignete WF-Server b estimmt
werden k
onnte. Leider scheidet diese L
osung im allgemeinen aus Aufwandsgr
unden aus. Das
Durchf
uhren der notwendigen Analysen w
urden die WF-Server stark b elasten und damit die
Performanz des WfMSs b eeintr
achtigen.
3
In
AD E P T
distr ibution
wird deshalb eine Strategie verfolgt, welche eine statische Vorb erech-
nung (zur Mo dellierungszeit) mit dynamischen Asp ekten (Ber
ucksichtigung von Laufzeit-
daten) kombiniert und so im wesentlichen die Vorteile der b eiden Vorgehensweisen in sich
vereint. Anstelle einer festen WF-Server-Zuordnung werden b ei der Analyse, wo erforderlich
bzw. sinnvoll, logische Serverzuordnungsausdr
ucke (im folgenden kurz: Serverzuordnungen)
erzeugt, die Laufzeitdaten der WF-Instanz referenzieren und so auf einfache (und eziente)
Weise eine Festlegung des konkreten WF-Servers zur Laufzeit erm
oglichen. In dem in Abb. 2
dargestellten Beispiel ergeb en sich(variable) Serverzuordnungen der Art:
ServZuordn
(
k
)=
"
Server im Domain des Bearb eiters von Aktivit
at
x
"
.F
ur die Aktivit
at
x
hingegen wird der
Server weiterhin statischgew
ahlt. F
ur die Aktivit
aten
k
und
k
0
ist die OE ihrer Bearb eiter
nach Ausf
uhrung von Aktivit
at
x
bekannt, so da zur Ausf
uhrungszeit der optimale Server
gew
ahlt werden kann.
Die Frage ist nun, wie man zu geeigneten variablen Serverzuordnungen f
ur die Aktivit
aten
kommt. Eine M
oglichkeit w
are, da sie vom WF-Mo dellierer b ei der Mo dellierung einfach
vorgegeb en werden (analog zu den Bearb eiterzuordnungen). Das Problem hierb ei ist, da der
WF-Mo dellierer, ohne weitere Unterst
utzung bzw. Information, die durch die Verteilung ent-
stehende Last in den Teilnetzen in der Regel kaum wird absch
atzen k
onnen. Es ist deshalb
notwendig, da er b eim Ermitteln von geeigneten Serverzuordnungen seitens des WfMSs ak-
tiv unterst
utzt wird. Das heit, die WfMS-Mo dellierungskomp onente mu f
ur die in Betracht
gezogenen Serverzuordnungen die Belastung jeder Systemkomp onente (Server, Teilnetz, Ga-
teway) geeignet absch
atzen, so da m
ogliche
Ub erlastungen entdeckt und vermieden werden
k
onnen.
F
ur diese Lastanalyse wird ein Kostenmo dell b en
otigt, das es erm
oglicht auszurechnen, f
ur
welche Komp onenten welche Kosten (als gewichtete Summe von
Ub ertragungsmenge, Ver-
arb eitungsmenge etc.) b ei der jeweils b etrachteten WF-Server-Festlegung entstehen. Dieses
3
Zur Erinnerung: Wir b etrachten
"
Pro duktions-WfMSe\ mit p otentiell sehr vielen gleichzeitig aktiven WF-
Instanzen.
6
Kostenmo dell und die Bestimmung der Serverzuordnungen wird im n
achsten Abschnitt b e-
schrieb en.
4 Ermitteln der Serverzuordnungen
Im folgenden wird b eschrieb en, wie die optimale Verteilung der Aktivit
aten einer WF-Vorlage
auf WF-Server b erechnet werden kann. Insb esondere wird auf die Bestimmung der Kosten
und der Wahrscheinlichkeitsverteilun gen (WVen) eingegangen.
4.1 Kostenmo dell
Ein Kostenmo dell zur Berechnung der Kosten bzw. zur Bestimmung der Last f
ur die unter
Performanz-Asp ekten kritischen Komp onenten des WfMSs (Server, Teilnetz, Gateway) mu
zumindest die folgenden Kosten b er
ucksichtigen:
Kosten f
ur den Parametertransfer b eim Starten und Beenden von Aktivit
atenprogrammen
Kosten f
ur das Aktualisieren von Arb eitslisten
Migrationskosten
Kosten f
ur die Kommunikation von Aktivit
atenprogrammen mit externen Datenquellen
Zus
atzlich zu den b ereits im WF- und Organisationsmo dell vorhandenen Informationen wer-
den je WF-Typ die (gesch
atzte) H
augkeit von WF-Instanziierungen sowie je Aktivit
at die
im Mittel zu kommunizierende Datenmenge (z.B. die Gr
oe von Parametern)
4
ben
otigt.
Bezeichne im folgenden
pr ob
k
(
i; j
)die Wahrscheinlichkeit, da Aktivit
at
k
vom Server in Teil-
netz
i
kontrolliert und von einem Benutzer in Teilnetz
j
b earb eitet wird.
pr ob
0
k;l
(
i; j
) sei die
Wahrscheinlichkeit, da b eim
Ub ergang von Aktivit
at
k
nach
l
von Server
i
nach
j
migriert
werden mu. Diese Wahrscheinlichkeiten h
angen von den gew
ahlten Serverzuordnungen ab.
Wie sie b estimmtwerden k
onnen, wird sp
ater gezeigt. F
ur den Momentwollen wir sie als ge-
geb en b etrachten. Im folgenden werden Formeln entwickelt, die das anfallende bzw. zu trans-
p ortierende Datenvolumen f
ur jede Aktion (Aktivit
at ausf
uhren, Migration, . . . ) b eschreiben,
und zwar getrenntf
ur jede Komp onente des WfMSs. Diese Formeln werden anschlieend in
eine Gesamtformel eingesetzt, mit der die in einer Komp onente entstehende Last b erechnet
werden kann.
Der Erwartungswert f
ur das Datenvolumen (im folgenden kurz: Datenvolumen) b ei der Ak-
tivit
atenausf
uhrung (Transp ort der Ein- und Ausgab eparameterdaten) b erechnet sich damit
wie folgt: Das Datenvolumen, das an Server
i
f
ur die Ausf
uhrung von Aktivit
at
k
entsteht,
4
Es bietet sich an, diese Information b ei der Mo dellierun g gleich mitzuerfassen.
7
ergibt sichalsWahrscheinlichkeit, da Server
i
die Aktivit
at
k
kontrolliert, multiplizi ert mit
der zu transp ortierenden Datenmenge:
Vol
Ak t
S erver;i
(
k
)=
P
j
pr ob
k
(
i; j
)
(
in par ameter siz e
k
+
out par ameter siz e
k
)
Die Belastung f
ur die Teilnetze ergibt sich folgendermaen: Im Teilnetz
i
ndet Kommunika-
tion statt, wenn entweder der Server in
i
liegt o der wenn ein Bearb eiter aus Teilnetz
i
gew
ahlt
wird. Trit b eides zu, so wird die Kommunikation nur einmal gez
ahlt:
Vol
Ak t
TN;i
(
k
)=
P
j
pr ob
k
(
i; j
)+
P
j
6
=
i
pr ob
k
(
j; i
)
(
in par ameter siz e
k
+
out par ameter siz e
k
)
Das anfallende Datenvolumen am Gatewayvon Teilnetz
i
nach
j
(
i
6
=
j
) ergibt sich wie folgt:
Vol
Ak t
GW;i;j
(
k
)=
pr ob
k
(
i; j
)
in par ameter siz e
k
+
pr ob
k
(
j; i
)
out par ameter siz e
k
Die Datenvolumina f
ur das Aktualisieren der Arb eitslisten (
Vol
AL
(
k
)) und f
ur die Kommu-
nikation mit externen Datenquellen (
Vol
Ext
(
k
)) k
onnen auf
ahnliche Weise b erechnet werden
(f
ur Details siehe [BD98b]).
Von b esonderem Interesse sind in dem b etrachteten Kontext nat
urlich die Migrationskosten
b eim
Ub ergang von Aktivit
at
k
nach
l
. Hierb ei m
ussen sowohl ein- wie auch ausgehende
Migrationen b er
ucksichtigt werden. Das Datenvolumen f
ur den Server
i
ergibt sich wie folgt:
Vol
Migr
S erver;i
(
k; l
)=
P
j
6
=
i
pr ob
0
k;l
(
i; j
)+
pr ob
0
k;l
(
j; i
)
instance siz e
k;l
Dab ei ist zu b eachten, da keine Kommunikation stattndet, wenn die Server f
ur Aktivit
at
k
und
l
identisch sind (deshalb:
j
6
=
i
). Das durch die Migration verursachte Datenvolumen in
den b etroenen Teilnetzen ist genau so gro wie b ei den Servern:
Vol
Migr
TN;i
(
k; l
)=
Vol
Migr
Server;i
(
k; l
).
Die Gateways m
ussen hierb ei die folgenden Datenmengen transp ortieren:
Vol
Migr
GW;i;j
(
k; l
)=
pr ob
0
k;l
(
i; j
)
instance siz e
k;l
F
ur jede Systemkomp onente m
ussen diese Datenmengen no ch mit den Ausf
uhrungsh
aug-
keiten
5
der einzelnen Aktivit
aten
h
(
k
) bzw. der Migrationen
h
0
(
k; l
)multipliziert und f
ur alle
Aktivit
aten aller WF-Typ en aufaddiert werden, um die entsprechende Last dieser Komp o-
nente zu b estimmen. F
ur die Server ergibt sich die Last (
Load
TN;i
und
Load
GW;i;j
analog)
wie folgt:
Load
S erver;i
=
P
WF
P
k
2
WF
h
(
k
)
Vol
Ak t
S erver;i
(
k
)+
h
(
k
)
Vol
AL
Server;i
(
k
)
+
h
(
k
)
Vol
Ext
Server;i
(
k
)+
P
l
6
=
k
h
0
(
k; l
)
Vol
Migr
Server;i
(
k; l
)
Ein globales Kostenma erh
alt man, indem man die Last aller Komp onenten mit komp onen-
tensp ezischen Kostenfaktoren
C
Server;i
,
C
TN;i
und
C
GW;i;j
gewichtet und aufaddiert. Diese
5
Die Ausf
uhrungsh
augkeiten b erechnen sich aus den Starth
augkeiten der einzelnen WF-Typ en, der
Wahrscheinl ichkeit f
ur den entsprechenden Zweig b ei einem OR-Split und der durchschnittli che n Anzahl von
Durchl
aufen von Schleifen. Diese Daten m
ussen vom WF-Mo dellierer vorgegeb en werden.
8
Kostenfaktoren geb en an, wie teuer es ist, ein Byte
ub er den Server, das Teilnetz bzw. das Ga-
teway zu transp ortieren. Der Mo dellierer kann damit b eeinussen, wie stark jede Komp onente
b elastet werden soll. Durch einen groen Wert wird erreicht, da z.B. eine WAN-Verbindung
(Gateway) wenig verwendet wird. Die zu minimierende Zielfunktion ergibt sich damit als:
K
=
P
i
C
S erver;i
Load
Server;i
+
P
i
C
TN;i
Load
TN;i
+
P
i
P
j
6
=
i
C
GW;i;j
Load
GW;i;j
Im folgenden Abschnitt wird b eschrieb en, welche Serverzuordnungsausdr
uckef
ur die Akti-
vit
aten m
oglich sind. In Abschnitt 4.3 wird gezeigt, wie die Serverzuordnungen so gew
ahlt
werden k
onnen, da
K
minimal wird.
4.2 Serverzuordnungsausdr
ucke
Bei der statischen Migration werden als Serverzuordnungsausdr
ucke die Server-IDs von WF-
Servern verwendet. Im Fall variabler Serverzuordnungen sind, wie ob en b ereits erw
ahnt, als
Serverzuordnungen auch Ausdr
ucke erlaubt, die Laufzeitdaten der Instanz referenzieren. In
den meisten praktisch relevanten F
allen wird man sich hierb ei auf die Lokation des Servers
o der des Bearb eiters der vorangegangenen Aktivit
aten b eschr
anken. In Sonderf
allen k
onnen
auchweitere WF-interne Daten (z.B. der Startzeitpunkt einer Aktivit
at), b eliebige mathe-
matische Funktionen, logische Ausdr
ucke o der die Einb eziehung WfMS-externer Daten (z.B.
Parameterdaten von Aktivit
aten) Sinn machen. W
ahrend Serverzuordnungen der erstgenann-
ten Art (s.u.: 1. - 4.) systemseitig vom Mo dell abgeleitet werden k
onnen, m
ussen die Zuord-
nungsausdr
uckef
ur die Sonderf
alle (5.) explizit vom Mo dellierer vorgegeb en werden.
M
ogliche Serverzuordnungen:
1.
S er v Z uor dn
(
k
)=
S
i
Der Aktivit
at
k
wird der Server
S
i
fest (statisch) zugeordnet.
2.
S er v Z uor dn
(
k
)=
Server
(
x
)
Die Aktivit
at
k
soll vom selb en Server kontrolliert werden wie die Aktivit
at
x
.
3.
S er v Z uor dn
(
k
)=
D omain
(
B ear b
(
x
))
Der Aktivit
at
k
wird der Server zugewiesen, der sich im Domain des Bearb eiters b endet,
der die Aktivit
at
x
ausgef
uhrt hat. Ist Aktivit
at
k
derselb e Bearb eiter zugeordnet wie
Aktivit
at
x
, so ist der Server von Aktivit
at
k
durch diese Zuordnung stets optimal.
4.
S er v Z uor dn
(
k
)=
f
(
Server
(
x
)) o der
S er v Z uor dn
(
k
)=
f
(
D omain
(
B ear b
(
x
)))
Auf die Serverzuordnungen kann no ch eine Funktion
f
angewandt werden. Dies macht z.B.
Sinn, wenn Aktivit
at
k
der Chef des Bearb eiters von Aktivit
at
x
zugeordnet ist. Dieser
kann einem anderen Domain angeh
oren (z.B. wenn er einer anderen Abteilung zugeordnet
ist), so da
f
eine Abbildung vom Domain des Mitarb eiters zu dem des Chefs darstellt. Wie
9
eine optimale Funktion
f
automatisch erzeugt werden kann, ist in [BD98b]beschrieb en.
5.
S er v Z uor dn
(
k
) = b eliebiger vorgegeb ener Ausdruck
Wird vom Mo dellierer eine Serverzuordnung vorgegeb en, die vom WfMS nicht analy-
siert werden kann, so mu er auch die f
ur weitere Analysen b en
otigten WVen (siehe Ab-
schnitt 4.4) vorgeb en.
4.3 Bestimmung der optimalen Serverzuordnungen
Zum Ermitteln der optimalen Verteilung k
onnten im Prinzip nun f
ur alle Aktivit
aten und
alle m
oglichen Serverzuordnungen die Kosten analysiert und die optimale Variante ausgew
ahlt
werden. Da ein WF ab er durchaus #
Ak t >
100 Aktivit
aten umfassen kann, die jeweils alle ihre
Vorg
anger in der Serverzuordnung referenzieren k
onnen, scheidet diese Vorgehensweise wegen
ihrer Komplexit
at
O
(#
Ak t
#
Ak t
) im allgemeinen aus. Wir schlagen deshalb den nachfolgend
b eschrieb enen Algorithmus 1 vor, der ein p olynomiales Laufzeitverhalten hat. Er basiert auf
einem Greedy-Ansatz und liefert f
ur die praktischrelevanten F
alle das optimale Ergebnis
bzw. eines, das dicht an diesem Optimum liegt.
Algorithmus 1 b erechnet f
ur jede Aktivit
at die optimale Serverzuordnung und legt diese im
Array
S er v Z uor dn
ab. In der Phase 1 wird zun
achst eine zul
assige Ausgangl
osung b estimmt.
Diese b er
ucksichtigt no chkeine Migrationskosten. F
ur jede Aktivit
at werden alle m
oglichen
Serverzuordnungen ausprobiert.
P otS er v Z uor dn
(
k
) liefert die entsprechende Menge f
ur Ak-
tivit
at
k
. Dies sind alle denkbaren Ausdr
uckevom Typ 1 - 4 aus Abschnitt 4.2. F
ur Ser-
verzuordnungen vom Typ 1 wird die Menge der Server-IDs
f
S
1
;S
2
:::
g
geliefert und f
ur
Typ 2 - 4 Ausdr
ucke der Form (z.B. Typ 2):
f
Server
(
x
1
)
; S er v er
(
x
2
)
:::
g
,wob ei die
x
i
die
Vorg
angeraktivit
aten von
k
sind. Aus den p otentiell m
oglichen Serverzuordnungen wird die-
jenige ausgew
ahlt, die zu den minimalen Kosten f
ur die Ausf
uhrung dieser Aktivit
at f
uhrt
(
cal cul ate costs
verwendet hierzu das Kostenmo dell aus Abschnitt 4.1). Da die Aktivit
aten
isoliert b etrachtet werden, ergeb en sich i.d.R. auchnicht rentable Migrationen. In Phase 2
wird
ub erpr
uft, welche dieser Migrationen sinnvoll sind. Dazu wird ausgerechnet, ob es g
unsti-
ger ist, eine Grupp e von Aktivit
aten mit einer direkten Vorg
anger- o der Nachfolgergrupp e
zusammenzufassen, so da die Migration dazwischen entf
allt. Die Motivation daf
ur ist, da
es sichnicht lohnt, wegen wenigen Aktivit
aten die gesamte Prozeinstanz zu einem Server
hin und zur
uck zu migrieren. Der Algorithmus b etrachtet zuerst kleine zusammenh
angende
Teilgraphen
G
von Aktivit
aten, die alle vom selb en Server kontrolliert werden. Diese werden
mit Nachbar-Teilgraphen zusammengefat, wo durch immer gr
oere Grupp en von Aktivit
aten
gebildet werden, zwischen denen keinen Migrationen stattnden. Dies wird solange durch-
10
gef
uhrt, bis keine unrentablen Migrationen mehr vorhanden sind. Dieses Vorgehen reduziert
die zu kommunizierende Datenmenge b ei der Ausf
uhrung der WFs, da Grupp en von Akti-
vit
aten genau dann zusammengefat werden, wenn dies die Kommunikationskosten reduziert.
Algorithmus 1: Berechnung der Serverzuordnung f
ur einen WF-Typ (Prozevorlage)
Phase 1:
for
each Aktivit
at
k
2
Prozevorlage
(in partieller Ordnung entsprechend Kontrollu)
do
C ost
min
=
1
;
for
each
S ervZ uordn
(
k
)
2
P otS erv Z uor dn
(
k
)
do
C ost
=
cal cul ate costs
(
S er v Z uor dn; k
); /* Kosten nur f
ur Aktivit
at k b erechnen */
if
C ost < C ost
min
then
S er v Z uor dn
opt
(
k
)=
S er v Z uor dn
(
k
);
Cost
min
=
Cost
;
S er v Z uor dn
(
k
)=
S ervZ uordn
opt
(
k
);
Phase 2:
C ost
min
=
cal cul ate costs
(
S er v Z uor dn; al l
); /* Kosten gesamter WF (mit Migrationskosten) */
for
i
=1
to
#Aktivit
aten(Prozevorlage)
do
for
each
G
:
j
G
j
=
i; G
ist max. Teilgraph mit
8
l
1
;l
2
2
G
:
S erver
(
l
1
)=
Server
(
l
2
)
do
for
each
a
62
G
:
9
l
2
G
:
a=Vorg
anger(l)
_
a= Nachfolger(l)
do
for
each
l
62
G
do
ServZ uord
neu
(
l
)=
ServZ uordn
(
l
);
for
each
l
2
G
do
ServZ uord
neu
(
l
)=
ServZ uordn
(
a
);
C ost
neu
=
cal cul ate costs
(
ServZ uordn
neu
;all
);
if
C ost
neu
< C ost
min
then
for
each
l
2
G
do
S er v Z uor dn
(
l
)=
ServZ uordn
neu
(
l
);
C ost
min
=
Cost
neu
;
4.4 Berechnung der Wahrscheinlichkeitsverteilun gen
Nachdem erl
autert wurde, welche Serverzuordnungen f
ur eine Aktivit
at in Frage kommen
und wie die durch sie entstehenden Kosten b erechnet werden, bleibt die Frage, wie die WVen
pr ob
k
(
i; j
)und
pr ob
0
k;l
(
i; j
)f
ur eine zu untersuchende Verteilung b erechnet werden k
onnen.
Da Serverzuordnungen von Laufzeitdaten der Instanz abh
angen, kann dieselb e Aktivit
at
k
bei verschiedenen WF-Instanzen durchunterschiedliche Server kontrolliert werden. Die ent-
sprechende Wahrscheinlichkeit, da Aktivit
at
k
vom Server
S
kontrolliert wird, wird mit
P
S
k
b ezeichnet. Da sichverschiedene Instanzen in unterschiedlichen OEen b enden k
onnen
(und dab ei unterschiedliche Server verwenden k
onnen), kann die Bearb eiter-WV jeweils un-
terschiedlich sein. Der Anteil an den Bearb eitern von Aktivit
at
k
aus dem Domain
D
,f
ur
den Fall, da der Server
S
den Prozeschritt
k
kontrolliert, wird in
U
S;D
k
festgehalten. Das
Hauptproblem b ei der Kostenanalyse b estehtnun darin, f
ur eine gegeb ene Verteilung die
WVen
P
S
k
und
U
S;D
k
zu b erechnen. Sind diese erst b ekannt, so k
onnen
pr ob
k
(
i; j
) und damit
die Kosten f
ur die Aktivit
atenausf
uhrung b erechnet werden. Die Wahrscheinlichkeit, da der
Server
S
verwendet wird und ein Bearb eiter im Domain
D
die Aktivit
at
k
b earb eitet, b etr
agt
pr ob
k
(
S; D
)=
P
S
k
U
S;D
k
.Tab elle 1 fat die verwendeten WVen no ch einmal zusammen; wie
11
Name Bedeutung
pr ob
k
(
i; j
) Wahrscheinlichkeit, da Aktivit
at
k
vom Server des Teilnetzes
i
kontrolliert
und von einem Bearb eiter in Teilnetz
j
ausgef
uhrt wird
pr ob
0
k;l
(
i; j
) Wahrscheinlichkeit, da b eim
Ub ergang von Aktivit
at
k
nach
l
vom Teilnetz
i
zum Teilnetz
j
migriert werden mu
P
S
k
Wahrscheinlichkeit, da Aktivit
at
k
vom Server
S
(in Teilnetz
S
)kontrolliert
wird
U
S;D
k
Anteil der Bearb eiter im Domain (Teilnetz)
D
an der Gesamtheit der Bearb eiter
von Aktivit
at
k
,wenn Aktivit
at
k
vom Server
S
kontrolliert wird
S ervV ert
S
k
(
U
) Wahrscheinlichkeit, da Aktivit
at
k
vom Server
S
kontrolliert wird, wob ei der
Bearb eiter
U
dieser Aktivit
at vorgegeb en ist
Tab elle 1:
Ub ersicht
ub er die verwendeten Wahrscheinlichkeitsverteilungen.
pr ob
0
k;l
(
i; j
) b erechnet wird, wird in Abschnitt 4.5 erl
autert.
4.4.1 Berechnung der Server-Wahrscheinlichkeitsverteilung
P
S
k
einer Aktivit
at
Die Server-WV
P
S
k
f
ur die Aktivit
at
k
gibt an, mit welcher Wahrscheinlichkeit Server
S
der
Server von Aktivit
at
k
ist. Sie ergibt sich aus der Serverzuordnung
S er v Z uor dn
(
k
) und der
Server- bzw. Bearb eiter-WV der referenzierten Aktivit
at
x
. Diese WVen sind b ei der Analyse
von Aktivit
at
k
schon b ekannt, da
x
vor
k
ausgef
uhrt wird und die Prozevorlage in partieller
Ordnung durchlaufen wird. Die Berechnung der Server-WV wird nun f
ur die in Abschnitt 4.2
denierten Serverzuordnungen b eschrieb en. Der Fall 5 wird dab ei (und im weiteren) nicht
ber
ucksichtigt, da b ei dieser Serverzuordnung die WV vom Mo dellierer vorgegeb en werden
mu.
P
S
k
kann mit dem folgenden Algorithmus b erechnet werden:
Algorithmus 2: Berechnung der Server-Wahrscheinlichkeitsverteilung
P
S
k
case
S er v Z uor dn
(
k
)=
S
i
:
P
S
k
=
SS
i
6
/* Da die Aktivit
at
k
stets vom Server
S
i
kontrolliert wird, ist
P
S
k
=1 f
ur
S
=
S
i
und sonst = 0. */
case
S er v Z uor dn
(
k
)=
Server
(
x
):
P
S
k
=
P
S
x
/* F
ur Akt.
k
wird derselb e Server verwendet wie f
ur
x
,weshalb die Server-WVen gleichsind.
7
*/
case
S er v Z uor dn
(
k
)=
Domain
(
B ear b
(
x
)):
P
i
k
=
U
i
x
mit
U
D
x
=
P
S
U
S;D
x
P
S
x
/* Der Server von Aktivit
at
k
ist im Domain des Bearb eiter von Aktivit
at
x
angesiedelt. Deshalb
ergibt sich die Server-WV von
k
aus der Bearb eiter-WV von
x
. Da dab ei nicht relevantist,welcher
Server Aktivit
at
x
kontrolliert hat, wird eine vom Server unabh
angige Bearb eiter-WV
U
i
x
erzeugt,
indem die Bearb eiter-WVen der einzelnen Server gewichtet aufaddiert werden. */
case
S er v Z uor dn
(
k
)=
f
(
S erver
(
x
)):
P
S
k
=
f
(
P
S
x
)
/* Die Berechnung von
P
S
k
erfolgt wie b ei
S ervZ uordn
(
k
)=
Server
(
x
), wob ei auf das Ergebnis no ch
die Funktion
f
angewandt werden mu (f
ur Details siehe [BD98b]). */
6
Kroneckersymbol:
ij
= 1, falls
i
=
j
und
ij
= 0, falls
i
6
=
j
.
7
Dieser Aussage liegt die Annahme zugrunde, da es zwischen
x
und
k
keine Verzweigungen gibt, die
abh
angig von der Wahl der Servers sind. Da solche Zusammenh
ange kaum zu fassen sind, da sie Datenelemente
b etreen, hab en wir f
ur Verzweigungs- und Schleifenb edi ng ungen generell angenommen, da ihr Ergebnis nicht
vom aktuellen Server abh
angt, auer der Mo dellierer gibt dies explizit vor.
12
case
S er v Z uor dn
(
k
)=
f
(
D omain
(
Bearb
(
x
))):
P
S
k
=
f
(
U
i
x
) mit
U
D
x
=
P
S
U
S;D
x
P
S
x
/* wie Fall
S er v Z uor dn
(
k
)=
D omain
(
B ear b
(
x
)), dann auf das Ergebnis
f
anwenden */
4.4.2 Berechnung der Bearb eiter-Wahrscheinlichkeitsverteilung
U
S;D
k
Die WV der Bearb eiter
U
S;D
k
gibt an, mit welcher Wahrscheinlichkeit der Bearb eiter von Ak-
tivit
at
k
aus dem Domain
D
stammt, wenn sie vom Server
S
kontrolliert wird. Sie ist vom
konkret verwendeten Server
S
dieser Aktivit
at abh
angig. Als Beispiel stelle man sich ein Kran-
kenhaus mit 3 Abteilungen vor, die jeweils
ub er einen eigenen Server verf
ugen. F
ur Patienten
der Abteilung 1 sind ausschlielich Pegekr
afte von Abteilung 1 (Domain 1) zust
andig. Sinn-
vollerweise wird in diesem Fall auchServer1verwendet. Damit ergibt sich eine Bearb eiter-WV
U
1
;D
k
=(1
;
0
;
0). Analog ergibt sichf
ur Server 2 die WV
U
2
;D
k
=(0
;
1
;
0) und
U
3
;D
k
=(0
;
0
;
1)
f
ur Server 3. Die Bearb eiter-WV
U
S;D
k
kann durch den folgenden Algorithmus b estimmtwer-
den (
S erv V ert
(
k; U; OE
) liefert die Server-WV von Aktivit
at
k
unter der Voraussetzung, da
der Benutzer
U
aus der OE
OE
diese Aktivit
at b earb eitet, s.u.):
Algorithmus 3: Berechnung der Bearb eiter-Wahrscheinlichkeitsverteilung
U
S;D
k
B ear b
k
=
f
U
k
j
U
k
qualiziert sich als Bearb eiter von Aktivit
at
k
g
;
for
each
U
k
2
B ear b
k
do
D
=
D omain
(
U
k
);
OE
=
OE
(
U
k
);
S ervV ert
S
k
(
U
k
)=
ServV ert
(
k; U
k
;OE
);
for
each
S
do
U
S;D
k
=
U
S;D
k
+
ServV ert
S
k
(
U
k
);
normalisiere
U
S;D
k
zeilenweise, so da
8
S
:
P
D
U
S;D
k
=1;
Der Algorithmus durchl
auft alle Bearb eiter der Aktivit
at
k
und ermittelt jeweils den zu-
geh
origen Domain
D
(aus dem Organisationsmo dell). Auerdem b estimmt er den Server
S
,
der die Aktivit
at kontrolliert, falls dieser Bearb eiter sie ausf
uhrt. Dann wird der Bearb eiter
f
ur den entsprechenden Server
S
und Domain
D
in der Bearb eiter-WV
U
S;D
k
ber
ucksichtigt.
Die Berechnung von
U
S;D
k
erfolgt also entsprechend der Denition der Bearb eiter-WV (siehe
Abschnitt 4.4). Die Aktivit
at
k
kann trotz desselb en Bearb eiters durchunterschiedliche Server
{jeweils mit einer gewissen Wahrscheinlichkeit { kontrolliert werden. Diese Wahrscheinlich-
keiten werden b erechnet (s.u.) und im Vektor
S erv V ert
S
k
(
U
) gesp eichert. Der Bearb eiter wird
anteilig b ei jedem dieser Server b er
ucksichtigt. Ein Beispiel hierf
ur ist eine Aktivit
at, deren
Serverwahl von einer anderen Aktivit
at abh
angt (also mehrere Server m
oglich sind). Wenn
diese Aktivit
at immer vom selb en Bearb eiter erledigt wird, mu dieser anteilsm
aig b ei all
diesen Servern b er
ucksichtigt werden.
Die Berechnung der Server-WV
ServV ert
S
k
(
U
)f
ur einen b estimmten Bearb eiter geschiehtin
ahnlicher Weise, wie f
ur die b earb eiterunabh
angige WV
P
S
k
in Abschnitt 4.4.1 b eschrieb en.
Allerdings h
angt
S erv V ert
S
k
(
U
) nichtnur von der Serverzuordnung der betrachteten Aktivit
at
13
k
ab, sondern auchvon deren Bearb eiterzuordnung. Im folgenden werden einige Beispiele
b eschrieb en, eine vollst
andige Diskussion aller F
alle, die durchKombination der m
oglichen
Server- und Bearb eiterzuordnungen entstehen, ndet sich in [BD98b].
Ist die Serverzuordnung statisch(
ServZuordn
(
k
)=
S
i
), so ist die Berechnung trivial, da
der Server immer gleich ist:
ServV ert
S
k
(
U
)=
SS
i
.
Ist die Bearb eiterzuordnung unabh
angig von anderen Aktivit
aten (z.B.
Rol l e
=
Ar z t
),
so ist die Server-WV unabh
angig vom Bearb eiter
U
,weshalb die allgemeine Server-WV
ub ernommen werden kann:
S erv V ert
S
k
(
U
)=
P
S
k
.
In Abb. 3a wird Aktivit
at
k
vom selb en Arzt b earb eitet wie Aktivit
at
x
. Der Server wird
im Domain des Bearb eiters von Aktivit
at
x
allokiert. Es soll
S erv V ert
S
k
(
U
)f
ur
U
=Dr.
Brinkmann aus Domain 3 b erechnet werden. Wegen
B ear bZ uor dn
(
k
)=
Bearb
(
x
) hat Dr.
Brinkmann auch Aktivit
at
x
ausgef
uhrt. Deshalb ist der Server von Aktivit
at
k
im Domain
von Dr. Brinkmann angesiedelt. Da dies der Domain 3 ist, ergibt sich
S erv V ert
S
k
(
U
)=
(0
;
0
;
1).
Wird, wie in Abb. 3b dargestellt, nicht derselb e Bearb eiter verwendet, sondern lediglich
dieselb e OE, so ist das Verfahren etwas komplizierter. Es soll
S erv V ert
S
k
(
U
)f
ur Schwester
Hildegard aus der OE Abteilung 2 b erechnet werden. Dazu m
ussen alle Bearb eiter (dersel-
b en OE Abteilung 2) mit der Rolle Arzt durchlaufen werden, weil dies genau die Bearb eiter
sind, die die Aktivit
at
x
ausgef
uhrt hab en k
onnen, wenn Aktivit
at
k
von Schwester Hil-
degard ausgef
uhrt wird. F
ur jeden dieser
Arzte wird der Domain ermittelt, da er { falls
dieser Arzt die Aktivit
at
x
ausgef
uhrt hat { die Lokation des Servers b estimmt. Dieser Do-
main wird dann in
S erv V ert
S
k
(
U
)ber
ucksichtigt. Nach dem Durchlaufen aller p otentieller
Bearb eiter wird
S erv V ert
S
k
(
U
)noch so normalisiert, da
P
S
ServV ert
S
k
(
U
) = 1 gilt.
(a) ...
xk
Bearb(x)
D o m a in (B ea rb (x))
R o lle = A rzt
(b )
...
xk
R o lle = P fle g e k ra ft
Ù
OE = OE(Bearb(x))
D o m a in (B ea rb (x))
R o lle = A rzt
Abbildung 3
Beispiele zur Berechnung der Server-Wahrscheinlichkeitsverteilung
ServV ert
S
k
(
U
).
Zus
atzlich zu diesen Asp ekten ist zu b eachten, da es Benutzer gibt, die Teilzeit arb eiten,
o der die nur einen Teil eines Arb eitstags mit dem WfMS arb eiten, o der Benutzer die in
mehreren Domains jeweils einen Teil ihrer Arb eitszeit verbringen. Diese d
urfen nicht wie Be-
nutzer b ehandelt werden, die
"
full-time\ im selb en Domain arb eiten, da sie weniger Last
erzeugen. Ein solcher Sachverhalt l
at sichz.B.dadurch mo dellieren, da jedem Benutzer
U
14
des WfMSs ein Gewicht
Gew icht
(
U
) zugeordnet wird. Dieses wird in Algorithmus 3 verwen-
det, um
S erv V ert
S
k
(
U
) gewichtet zu addieren. Weitere Asp ekte von Bearb eiter-Gewichtungen
nden sich in [BD98b].
4.5 Migrationskosten
In Phase 1 von Algorithmus 1 werden nur die optimalen Serverzuordnungen der Aktivit
aten
b etrachtet, ohne die Migrationskosten zu b er
ucksichtigen. In Phase 2 werden auch diese Ko-
sten mit einb ezogen. Um sie b erechnen zu k
onnen, mu die Wahrscheinlichkeit
pr ob
0
k;l
(
i; j
)
b estimmtwerden, mit der der WF vom Server
i
zum Server
j
migriert wird.
Die Wahrscheinlichkeiten f
ur die Migrationen b eim
Ub ergang von Aktivit
at
x
nach
k
k
onnen
in Form einer
Migrationsmatrix
angegeb en werden. Der Eintrag der
i
-ten Zeile und
j
-ten
Spalte gibt an, wie gro die b edingte Wahrscheinlichkeit ist, da zum Server
j
migriert werden
mu, wenn Aktivit
at
x
vom Server
i
kontrolliert wird. Es gilt also:
M
i;j
(
x; k
) = P(Server
j
kontrolliert Aktivit
at
k
j
Server
i
kontrolliert Aktivit
at
x
)
Damit ergibt sich die Migrationswahrscheinlichkeit als:
pr ob
0
x;k
(
i; j
)=
P
i
k
M
i;j
(
x; k
)
Im folgenden wird b eschrieb en, wie diese Matrix
M
ermittelt wird.
Aus den Serverzuordnungen kann man ableiten, welche Mengen von Aktivit
aten einer WF-
Instanz stets vom selb en Server kontrolliert werden. Ist dies f
ur die Aktivit
aten
x
und
k
der Fall, so mu nie migriert werden, so da sich die 1-Matrix ergibt. Andernfalls bietet die
Nutzung der Server-WV
P
S
k
eine einfache M
oglichkeit zur Approximation der Migrations-
wahrscheinlichkeiten. Die Server-WV gibt an, mit welcher Wahrscheinlichkeit sich die Instanz
nach der Migration an Server
j
b endet. Die Migrationswahrscheinlichkeiten ergeb en sich
damit als:
8
i; j
:
M
i;j
(
x; k
)=
P
j
k
Bei dieser Berechnung wird allerdings die Annahme vorausgesetzt, da die Server der b eiden
Aktivit
aten unabh
angig voneinander gew
ahlt werden. Diese Annahme ist ab er h
aug unrea-
listisch, da in vielen F
allen die Server- und Bearb eiterzuordnungen der b eiden Aktivit
aten
jeweils von derselb en OE abh
angen werden. Dies kann wie folgt erkannt und b ehandelt wer-
den:
Mit Hilfe der Bearb eiterzuordnungen werden Klassen von Aktivit
aten gebildet, deren Bear-
b eiter stets derselb en OE angeh
oren (
OE-Klassen
). Dazu werden (einmal) alle Aktivit
aten
k
der Prozevorlage durchlaufen. Aktivit
at
k
geh
ort derselb en Klasse wie die von ihr referen-
zierte Aktivit
at
x
an, falls eine der folgenden Bearb eiterzuordnungen verwendet wird:
15
B ear bZ uor dn
(
k
)=
B ear b
(
x
)
B ear bZ uor dn
(
k
)=
OE
(
B ear b
(
x
))
^
...
Zur Berechnung der Migrationswahrscheinlichkeiten wird Algorithmus 4 verwendet, wenn die
Aktivit
at
k
und ihr Vorg
anger
x
in derselb en OE-Klasse liegen und in
ServZuordn
(
k
) eine
Aktivit
at dieser Klasse referenziert wird.
Algorithmus 4: Berechnung der Migrationswahrscheinlichkeiten (keine Unabh
angigkeit)
for
each
S
x
;S
k
do
M
S
x
;S
k
(
x; k
)= 0;
B ear b
x
=
f
U
x
j
U
x
qualiziert sich als Bearb eiter von Aktivit
at
x
g
;
Gesamtg ew icht
x
=
P
U
x
2
Bearb
x
Gew icht
(
U
x
);
for
each
U
x
2
B ear b
x
do
S ervV ert
S
x
(
U
x
)=
S ervV ert
(
x; U
x
;OE
(
U
x
)) ;
B ear b
k
(
U
x
)=
f
U
k
j
U
k
qualiziert sich als Bearb eiter von Aktivit
at
k
,wenn
U
x
Bearb eiter von
x
g
;
Gesamtg ew icht
k
(
U
x
)=
P
U
k
2
Bearb
k
(
U
x
)
Gew icht
(
U
k
);
for
each
U
k
2
B ear b
k
(
U
x
)
do
S ervV ert
S
k
(
U
k
)=
ServV ert
(
k; U
k
;OE
(
U
k
));
for
each
S
x
;S
k
do
M
S
x
;S
k
(
x; k
)=
M
S
x
;S
k
(
x; k
)+
Gew icht
(
U
x
)
Gesamtg ew icht
x
Gew icht
(
U
k
)
Gesamtg ew icht
k
(
U
x
)
ServV ert
S
x
x
(
U
x
)
ServV ert
S
k
k
(
U
k
)
;
normalisiere
M
i;j
(
x; k
) zeilenweise, so da
8
i
:
P
j
M
i;j
(
x; k
)=1;
Algorithmus 4 b erechnet die tats
achlichen Migrationswahrscheinlichkeiten, da er alle auf-
grund von
B ear bZ uor dn
(
k
) erlaubten Kombinationen von Bearb eitern f
ur die Aktivit
aten
x
und
k
durchl
auft, die Wahrscheinlichkeit ihres Auftretens b erechnet und die b ei diesem
Paar auftretende Migration in
M
ber
ucksichtigt. Die Wahrscheinlichkeit, da Benutzer
U
x
die Aktivit
at
x
bearbeitet, betr
agt
Gew icht
(
U
x
)
Gesamtg ew icht
x
. Die b edingte Wahrscheinlichkeit, da Be-
nutzer
U
k
unter dieser Voraussetzung Aktivit
at
k
bearbeitet, betr
agt
Gew icht
(
U
k
)
Gesamtg ew icht
k
(
U
x
)
.Mit
diesen Wahrscheinlichkeiten gewichtet geht die Migration in
M
ein. Dab ei werden (in den
for-Schleifen) alle F
alle b er
ucksichtigt, d.h. die Summe der Wahrscheinlichkeiten ergibt 1:
P
U
x
2
B ear b
x
P
U
k
2
Bearb
k
(
U
x
)
Gew icht
(
U
x
)
Gesamtg ew icht
x
Gew icht
(
U
k
)
Gesamtg ew icht
k
(
U
x
)
=
P
U
x
2
B ear b
x
Gew icht
(
U
x
)
Gesamtg ew icht
x
P
U
k
2
B ear b
k
(
U
x
)
Gew icht
(
U
k
)
Gesamtg ew icht
k
(
U
x
)
1
Gesamtg ew icht
x
X
U
x
2
Bearb
x
Gew icht
(
U
x
)
|{z }
Gesamtg ew icht
x
1
Gesamtg ew icht
k
(
U
x
)
X
U
k
2
B ear b
k
(
U
x
)
Gew icht
(
U
k
)
| {z }
Gesamtg ew icht
k
(
U
x
)
=1
Auerdem gilt
P
U
k
2
B ear b
k
(
U
x
)
Gew icht
(
U
k
)
Gesamtg ew icht
k
(
U
x
)
= 1, so da die Gewichtung des Bearb eiters
U
x
von Aktivit
at
x
nicht durch die Multiplikation mit
Gew icht
(
U
k
)
Gesamtg ew icht
k
(
U
x
)
beeintr
achtigt wird.
Ergibt die Berechnung von
ServV ert
S
x
(
U
x
)bzw.
ServV ert
S
k
(
U
k
)f
ur das b etrachtete Be-
arb eiterpaar
U
x
und
U
k
, da mehrere Server b etroen sind, so werden die Bearb ei-
ter anteilsm
aig b ei jedem dieser Server b er
ucksichtigt. Dadurch ergibt sich der Faktor
S erv V ert
S
x
x
(
U
x
)
S erv V ert
S
k
k
(
U
k
). Wegen
P
S
x
ServV ert
S
x
x
(
U
x
)=
P
S
k
ServV ert
S
k
k
(
U
k
)=1
16
gilt auch
P
S
x
P
S
k
S erv V ert
S
x
x
(
U
x
)
S erv V ert
S
k
k
(
U
k
) = 1, was b eweist, da das Gewicht des
Bearb eiterpaares durch diesen zus
atzlichen Faktor nicht b eeinut wird.
Der mit dem so eb en b eschrieb enen Algorithmus b ehandelte Fall ist in der Praxis sehr re-
levant, da WFs h
aug f
ur die Dauer mehrerer Aktivit
aten innerhalb derselb en OE verblei-
b en. Auerdem bilden die Benutzer einer OE oft exakt einen Domain. Werden in dem in
Abb. 2 dargestellten Beispiel die Serverzuordnungen
ServZuordn
(
k
)=
D omain
(
B ear b
(
x
))
und
S er v Z uor dn
(
k
0
)=
D omain
(
Bearb
(
k
)) verwendet, so kann aus diesen nichtgeschlossen
werden, da f
ur die b eiden Aktivit
aten stets derselb e Server verwendet wird. Werden zwei
Server jeweils mit der Wahrscheinlichkeit 0,5 verwendet, so ergibt sich durch die einfache
Approximation vom
M
durch
P
S
k
eine Migrationswahrscheinlichkeit von 50%. In Wirklichkeit
tritt ab er keine Migration auf. Der ob en b eschrieb ene Algorithmus b er
ucksichtigt dies, da
b ei allen Kombinationen von Bearb eitern f
ur die Aktivit
aten
k
und
k
0
jeweils derselb e Server
(n
amlich der in der OE dieser Bearb eiter) ermittelt wird, womit sich die 1-Matrix als Ergebnis
M
ergibt. Bendet sich lediglich der Groteil der Benutzer einer OE im selb en Domain, so
ergibt sichann
ahernd die 1-Matrix. In b eiden F
allen wird erkannt, da die Migrationskosten
wesentlich niedriger sind, als wenn Unabh
angigkeit angenommen worden w
are.
5 Diskussion
Dieser Abschnitt bietet einen
Ub erblick
ub er Architekturkonzepte f
ur skalierbare WfMSe und
stellt einige konkrete Ans
atze vor. F
ur eine detaillierte Diskussion m
ochten wir auf [BD98a]
verweisen. Das eine Extrem f
ur die Architektur eines WfMSs ist ein
zentraler Server
. Diesem
sind alle Aktivit
aten zugeordnet. Da er deshalb die gesamte Systemlast b ew
altigen mu, stellt
er einen p otentiellen Flaschenhals dar. Einige Forschungsprototyp en, die sich nicht prim
ar
um Skalierbarkeit k
ummern (z.B. Panta Rhei [EG96]), und die meisten kommerziellen Syste-
me fallen in diese Kategorie. Das andere Extrem sind Systeme, die
ub erhaupt keine Server
verwenden. Die WFs migrieren zwischen den Benutzern, die sie b earb eiten. Auch hier sind
keine Serverzuordnungen notwendig. Beispiele sind Exotica/FMQM [AMG
+
95] und INCAS
[BMR94].
Zwischen diesen b eiden Extremen liegen Ans
atze, b ei denen
mehrere WF-Server
verwendet
werden, ab er nicht jede Benutzermaschine gleichzeitig als Server fungiert. Da b ei diesen Sy-
stemen eine Strategie f
ur die Zuordnung der Server zu den Aktivit
aten notwendig ist, werden
sie nach diesem Kriterium klassiziert. In [AKA
+
94]werden identische Replikate (Cluster)
der WF-Engine verwendet. Eine WF-Instanz wird komplett von einem
zuf
al lig ausgew
ahl-
ten Cluster
kontrolliert. Deshalb sind keine Serverzuordnungen notwendig. In [SM96]werden
17
die Systeme Co dAlf und BPAFrame b eschrieb en, die den WF-Server einer Aktivit
at jeweils
bei der Anwendung
(z.B. b eim DBMS) allokieren. Stehen mehrere Anwendungsserver zur
Verf
ugung, so sorgt ein Trader f
ur eine Verteilung der Last. Ein
ahnlicher Ansatz wird von
METEOR
2
[DKM
+
97, MSKW96, SK97] verfolgt. Die Anwendungslogik wird zu sog. Task-
managern
ub ersetzt. F
ur jede Aktivit
at entsteht so ein Taskmanager, der b ei der zu dieser
Aktivit
at geh
orenden Anwendung plaziert wird. Generelle Nachteile dieses Vorgehens sind,
da zwischen dem WF-Server und den Bearb eitern u.U. eine weit entfernte Kommunikation
notwendig wird und nicht jede Anwendung einen vorgegeb enen Ort hat (z.B. ein Editor).
Die meisten Ans
atze versuchen, wie
AD E P T
distr ibution
, die
Server nahe bei den Bearbeitern
der jeweiligen Aktivit
at zu plazieren. Bei MENTOR [WWWK96a, WWWK96b, WWK
+
97,
MWW
+
98] werden State-/Activitycharts so partitioniert, da sich die
Aquivalenz der verteil-
ten Ausf
uhrung zum zentralen Fall formal zeigen l
at. Da alle Bearb eiter einer Aktivit
at dem-
selb en
"
Pro cessing Entity\ angeh
oren m
ussen, bietet es sich an, diesen Server auszuw
ahlen.
Dieselb e Verteilungsstrategie wird von WIDE [CGP
+
96, CGS97] verwendet, wob ei { anstelle
einer Migration { entfernte Ob jektzugrie mittels CORBA durchgef
uhrt werden. In MOBI-
LE [BHJ
+
96, HS96] werden die verschiedenen Asp ekte eines WFs von verschiedenen Servern
b ehandelt, mit dem Ziel deren Last zu reduzieren. Verschiedene WF-Typ en k
onnen von ver-
schiedenen Servern kontrolliert werden, es nden ab er keine Migrationen statt.
AD E P T
distr ibution
b eziehtindenVerteilungsalgorithmus die Kommunikationskosten mit ein
und b er
ucksichtigt damit, da das Kommunikationssystem zum Flaschenhals werden kann. Es
ist unseres Wissens der einzige Ansatz, b ei dem eine Lastanalyse durchf
uhrt wird, um durch
eine geeignete Verteilung die Kommunikationskosten zu minimieren. Bei den anderen Syste-
men gibt es keine variable Serverzuordnung, der Einu abh
angiger Bearb eiterzuordnungen
auf die Verteilung wird nichtber
ucksichtigt. Es gibt ab er Systeme, die b ei der Serverzu-
ordnung exib el sind [SM96], um eine Lastbalancierung zu erreichen o der den Ausfall von
Komp onenten zu komp ensieren. Dies ist in
AD E P T
distr ibution
eb enfalls vorgesehen, ist ab er
nicht Thema dieses Beitrags.
6 Zusammenfassung
WfMSe mit expliziter Proze- und Datenmo dellierung und der dynamischen Zuordnung von
Bearb eitern zu den auszuf
uhrenden T
atigkeiten sind eine vielversprechende Technologie f
ur
die Realisierung unternehmensweiter, vorgangsorientierter Anwendungssysteme. Die mit die-
sen Systemen erreichbare Flexibilit
at schl
agt sichjedoch in einem relativ hohen Kommu-
nikationsaufkommen zwischen den Steuerungskomp onenten, den WF-Servern, und den An-
18
wendungskomp onenten, den WF-Klienten, nieder. In unternehmensweiten WfMS-basierten
Anwendungssystemen, mit hunderten von WF-Klienten und tausenden von aktiven WF-
Instanzen spielt die daraus resultierende Belastung der WF-Server, ab er auch der zugrun-
deliegenden (Teil-)Netze eine wesentliche Rolle f
ur das Antwortzeitverhalten und damit f
ur
die Einsetzbarkeit
ub erhaupt.
Eine M
oglichkeit, um die Netzb elastung zu reduzieren, ist, die Kommunikation zwischen WF-
Servern und ihren WF-Klienten jeweils m
oglichst lokal innerhalb eines Teilnetzes zu halten,
d.h. teilnetz
ub ergreifende Kommunikation nachM
oglichkeit zu vermeiden. Dies ist dadurch
zu erreichen, da eine WF-Instanz nichtmehrkomplett von dem initiierenden WF-Server ge-
steuert wird, sondern da die Steuerung w
ahrend der Ausf
uhrung ggf. auf andere WF-Server
"
migriert\ . In [BD97] hab en wir eine Mo dellierungskomp onente und deren formale Grund-
lagen (vor allem die Bestimmung von Wahrscheinlichkeitsverteil ungen und Kostenformeln)
b eschrieb en, die b ei der Mo dellierung von WFs die Bestimmung geeigneter
"
WF-Abschnitte\
erlaubt, die dann jeweils von einem anderen WF-Server gesteuert werden. Hierb ei wurden die
"
Abschnittsserver\ zur Mo dellierungszei t ermittelt und festgelegt. Dies f
uhrt dann zu guten
Ergebnissen, wenn die m
oglichen Bearb eiter einer T
atigkeit z.B. allein durch ihre Rolle o der
ihre Organisationseinheit b eschrieb en sind.
In diesem Beitrag hab en wir untersucht, wie auchkomplizierte Bearb eiterzuordnungen durch
ein WfMS ad
aquat unterst
utzt werden k
onnen. Im Mittelpunkt standen hierb ei sog.
"
abh
angi-
ge\ Bearb eiterzuordnungen, b ei denen die in Frage kommenden Bearb eiter o der die Orga-
nisationseinheiten eines Arb eitsschrittes von in vorangegangenen getroenen Zuordnungen
abh
angen; ein praktisch sehr relevanter Fall. Wir hab en gezeigt, wie sich zum einen zur
Mo dellierungszei t geeignete Absch
atzungen durchf
uhren lassen, und wie zum anderen die
WF-Steuerung so realisiert werden kann, da zur Laufzeit b ei Bedarf dynamischentschie-
den werden kann, welcher WF-Server f
ur die Steuerung ausgew
ahlt werden soll. Hierzu hab en
wir sog. Serverzuordnungsausdr
uckesowie entsprechende Mo delle f
ur die Wahrscheinlichkeits-
und Kostenabsch
atzungen eingef
uhrt.
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
19
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 (http://www.informatik.uni-ulm.de/dbis/pap ers/).
[BD98a] T. Bauer und P. Dadam:
Architekturen f
ur skalierbare Workow-Management-
Systeme { Klassikation und Analyse
. Technischer Bericht 98-02, Univer-
sit
at Ulm, Fakult
at f
ur Informatik, Januar 1998 (http://www.informatik.uni-
ulm.de/dbis/pap ers/).
[BD98b] T. Bauer und P.Dadam:
Variable Migration von Workows und komplexe
Bearbeiterzuordnungen in
AD E P T
. Technischer Bericht, Universit
at Ulm,
Fakult
at f
ur Informatik, 1998 (erscheintdemn
achst).
[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:
7th International Workshop on Research Issues in
Data Engineering
, Birmingham, April 1997.
[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.
[DKR
+
95] P. Dadam, K. Kuhn, M. Reichert, T. Beuter und M. Nathe:
AD E P T
: Ein in-
tegrierender Ansatz zur Entwicklung exibler, zuverl
assiger kooperierender As-
sistenzsysteme in klinischen Anwendungsumgebungen
.In:
Proceedings GI/SI-
Jahrestagung
, S. 677{686, Z
urich, September 1995.
[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.
[HS96] P. Heinl und H. Schuster:
Towards a Highly Scaleable Architecture for Work-
ow Management Systems
. In:
Proceedings of the 7th International Workshop
on Database and Expert Systems Applications, DEXA'96
,S. 439{444,Z
urich,
September 1996.
20
[LR97] F. Leymann und D. Roller:
Workow-based Applications
. IBM Systems Jour-
nal, 36(1):102{123, 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
Systems, 10(2):159{184, M
arz/April 1998.
[RD98] M. Reichert und P. Dadam:
ADEPT
flex
{ Supporting Dynamic Changes
of Workows Without Loosing Control
. Journal of Intelligent Informati-
on Systems, Sp ecial Issue on Workow Management Systems, 10(2):93{129,
M
arz/April 1998.
[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, Istanbul, 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.
[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.
21