Verteilungsmodelle für Workflow-Management-Systeme - Klassifikation und Simulation [original]

Informatik Forsch. Entw. (1999) 14: 203–217

Springer-Verlag 1999

Verteilungsmodelle f¨

ur Workflow-Management-Systeme –

Klassifikation und Simulation

Thomas Bauer, Peter Dadam

Abteilung Datenbanken und Informationssysteme, Universit¨

at Ulm, Oberer Eselsberg, 89069 Ulm (e-mail: {bauer,dadam}@informatik.uni-ulm.de)

Eingegangen am 12. M¨

arz 1999 / Angenommen am 8. Oktober 1999

Zusammenfassung. In unternehmensweiten Workflow-Ma-

nagement-Systemen (WfMS) kann die von der WF-Engine

zu bew¨

altigende Last sehr groß werden. Außerdem werden

hohe Anforderungen an die Verf¨

ugbarkeit eines solchen Sy-

stems gestellt. Deshalb wurden in der Literatur zahlreiche

Architekturen f¨

ur skalierbare WfMS vorgeschlagen, die auf

unterschiedlichen Verteilungsmodellen f¨

ur die WF-Engine

basieren. Im vorliegenden Beitrag werden diese Verteilungs-

modelle analysiert, verglichen und klassifiziert. Aufbauend

auf diese Klassifikation wird f¨

ur zwei Beispielszenarien die

bei den verschiedenen Verteilungsmodellen entstehende Last

simuliert und verglichen.

Schl¨

usselw¨

orter: Workflow-Management, Architekturen,

verteilte Ausf¨

uhrung, Skalierbarkeit, Simulation

Abstract. In enterprise-wide workflow management systems

(WfMS) the workflow engine may have to cope with a very

high load. In addition, the availability of such a system must

be high. Many architectures for scalable WfMS have been

proposed in the literature, which are based on different dis-

tribution models of the workflow engine. These distribution

models are analyzed, compared, and classified. Based on this

classification, two example scenarios are used to simulate

and compare the load resulting for the different distribution

models.

Key words: Workflow management, architectures, distri-

buted execution, scalability, simulation

CR Subject Classification: H.4.1, H.1.0, C.2.4

1 Einleitung

WfMS erm¨

oglichen die rechnerunterst¨

utzte Ausf¨

uhrung von

Gesch¨

aftsprozessen in einer verteilten Systemumgebung.

Aufgrund von wirtschaftlichen Zw¨

angen ist das Interesse

an solchen Systemen in den letzten Jahren stetig gewach-

sen. Ihr entscheidender Vorteil ist, daß sie helfen, große An-

wendungssysteme ¨

uberschaubarer zu gestalten. Dazu wird

der applikationsspezifische Code der verwendeten Anwen-

dungen von der Ablauflogik (,,Prozeßlogik“) getrennt. An-

stelle eines großen monolithischen Programmpakets erh¨

alt

man nun, zumindest logisch gesehen, einzelne Anwendungs-

programme (,,Anwendungskomponenten“), welche die aus-

zuf¨

uhrenden Aktivit¨

aten repr¨

asentieren. Ihre Abfolge wird

in einer separaten Kontrollfluß-Definition festgelegt, welche

die Ausf¨

uhrungsreihenfolge (Sequenz, Verzweigung, Paral-

lelit¨

at, Schleifen) der einzelnen Aktivit¨

aten bestimmt. H¨

aufig

wird auch der Datenfluß zwischen den Aktivit¨

aten explizit

modelliert. Das WfMS sorgt daf¨

ur, daß nur solche Akti-

vit¨

aten ausgef¨

uhrt werden k¨

onnen, die der Ablauflogik zu-

folge zur Bearbeitung anstehen. Diese werden in die Arbeits-

listen autorisierter Bearbeiter eingef¨

ugt. Welche Benutzer zur

Bearbeitung einer bestimmten Aktivit¨

at autorisiert sind, wird

meist durch eine Rolle und evtl. zus¨

atzlich eine Organisati-

onseinheit (OE, z.B. Abteilung, Zweigstelle o.¨

a.) festgelegt,

welchen die entsprechenden Bearbeiter angeh¨

oren m¨

ussen.

Dabei ist es durchaus m¨

oglich, daß mehrere Benutzer er-

mittelt werden, die f¨

ur die Bearbeitung einer bestimmten

Aktivit¨

at in Frage kommen.

Wir gehen in dieser Arbeit von dem folgenden Re-

ferenzmodell f¨

ur WfMS aus: Ein WfMS besteht aus ei-

ner WF-Engine und den WF-Clients. Die WF-Engine steu-

ert die Ausf¨

uhrung der WF-Instanzen entsprechend dem

in den WF-Vorlagen modellierten Kontrollfluß und ver-

waltet die WF-Daten. Eine WF-Engine besteht aus einem

oder mehreren WF-Servern, die jeweils ¨

uber eine eigene

WF-Datenbank (WF-DB) verf¨

ugen. In dieser sind die fol-

genden WF-Daten gespeichert: die (weitgehend statischen)

WF-Vorlagen (Schemainformation), der aktuelle Zustand der

WF-Instanzen dieses Servers, die Werte der Datenelemente

dieser WF-Instanzen und evtl. Information ¨

uber alte Zu-

st¨

ande. Der WF-Client erm¨

oglicht einem Benutzer die zu-

geh¨

orige Arbeitsliste anzuzeigen. Wenn dieser daraus eine

Aktivit¨

ateninstanz ausw¨

ahlt, so wird das entsprechende Ak-

tivit¨

atenprogramm gestartet.

Im folgenden soll das zugrundegelegte Ausf¨

uhrungsmo-

dell erl¨

autert werden. Dabei wird nur auf Aspekte einge-

gangen, die f¨

ur das weitere Verst¨

andnis dieser Arbeit wich-

tig sind. Wir betrachten die Ausf¨

uhrung eines (Ausschnitts

eines) WF, der aus der Sequenz der Aktivit¨

aten A und B

204

A: AL

potentielle Bearb. für

A k t. A erm itte ln u n d

A u sw ah l d e s ta tsäch l.

B earbeiters steuern

A: Ausf

A k tiv itä te n -

p ro g ram m fü r

A k tiv ität A sta rten

WF-

Steuerung

(Server)

B: AL

potentielle B earb. für

A k t. B e rm itte ln u n d

A u sw ah l d e s ta tsäch l.

B earbeiters steuern

B: Ausf

A k tiv itä te n -

p ro g ram m fü r

A k tiv itä t B sta rte n

WF-

Bearbeitung

(C lie n t)

1 . A rb e itsliste n

a k tu a lisie re n u n d

B earbeiter fü r

Akt. A auswählen

3. Ü bertragung der

Eingabe- bzw .

A usgabeparam eter

v o n A k tiv ität A

5 . A rb e itsliste n

a k tu a lisie re n u n d

B earbeiter fü r

A k t. B a u sw äh len

7. Ü bertragung der

Eingabe- bzw .

A usgabeparam eter

v o n A k tiv ität B

2. 6.

M ü lle r

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem.

noch

o ffe n

M ü lle r

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem.

noch

o ffe n

A k tiv itä te n p ro g ra m m

AA k tiv itä te n p ro g ra m m

A rbeitslisten der potentiellen

B earbeiter von A ktivität A A rbeitslisten der potentiellen

B earbeiter von A ktivität B

1. M eier M iniskusoperation

2 . M ü lle r P a tien t au fk lä ren

3 . A d a m K n ie o p e ra to n

4. Schulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t au fk lä ren

3 . A d a m K n ie o p e ra to n

4. Schulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t au fk lä ren

3 . A d a m K n ie o p e ra to n

4. Schulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t au fk lä ren

3 . A d a m K n ie o p e ra to n

4. Schulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t au fk lä ren

3 . A d a m K n ie o p e ra to n

4. Schulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t au fk lä ren

3 . A d a m K n ie o p e ra to n

4. Schulze U ntersuchung

A u s w a h l > _ _ _

Abb. 1. Steuerung und Bearbeitung eines WF, der aus den Aktivit¨

aten A und B besteht

besteht. In Abb. 1 sind die hinsichtlich der sp¨

ateren Diskus-

sion interessanten Schritte aufgef¨

uhrt. Der WF-Server er-

mittelt die potentiellen Bearbeiter von Aktivit¨

at A und f¨

ugt

Aktivit¨

at A in deren Arbeitslisten ein. Ein Benutzer, der

diese Aktivit¨

at bearbeiten m¨

ochte, w¨

ahlt sie aus seiner Ar-

beitsliste aus; der WF-Server synchronisiert diesen Vorgang

(A: AL). Anschließend startet der WF-Server oder Client

das entsprechende Aktivit¨

atenprogramm f¨

ur diesen Benutzer

(A: Ausf). Dies findet i.d.R. zumindest f¨

ur den Client-Teil

des Programms auf dem Rechner dieses Bearbeiters statt.

Zum Starten m¨

ussen die Eingabedaten zu dem Programm

ubertragen werden. Nach Beendigung des Programms und

der ¨

Ubertragung der Ausgabedaten zum Server erfolgt der-

selbe Ablauf f¨

ur Aktivit¨

at B (B: AL und B: Ausf).

Im einfachsten Fall w¨

urden alle diese Aktionen auf dem-

selben Rechner ausgef¨

uhrt werden. Dieser Fall ist aber we-

nig sinnvoll, da die Benutzer des WfMS und die verwende-

ten Anwendungen meist r¨

aumlich verteilt sind. Deshalb fin-

det die WF-Bearbeitung in der Regel verteilt statt. Die Last

f¨

ur die WF-Engine ist bei großen (unternehmensweiten) An-

wendungen sehr groß, da nach Beendigung jeder Aktivit¨

nicht nur die Nachfolgeaktivit¨

aten bestimmt werden m¨

ussen,

sondern auch alle f¨

ur deren Bearbeitung geeigneten Benut-

zer. Dies erfordert einen hohen Aufwand, da zur Festlegung

der potentiellen Bearbeiter einer Aktivit¨

at i.d.R. komplexe

Auswahlpr¨

adikate verwendet werden k¨

onnen. F¨

ur jede Akti-

vit¨

ateninstanz und jeden Benutzer muß ein solcher Ausdruck

ausgewertet werden. Anschließend m¨

ussen auch noch die

Arbeitslisten der hierbei ermittelten Bearbeiter aktualisiert

werden. Der hierdurch entstehende Aufwand f¨

uhrt wegen

mangelnder Skalierbarkeit bei vielen der heute kommerziell

verf¨

ugbaren WfMS dazu, daß diese bereits bei relativ kleinen

Benutzerzahlen an ihre Leistungsgrenze stoßen [GHS95].

Um dem abzuhelfen, wird h¨

aufig auch die WF-Steuerung

verteilt, d.h., es werden mehrere WF-Server verwendet. Die

Art und Weise, wie die Aufgaben auf die verschiedenen

WF-Server verteilt werden, wird in diesem Beitrag als Ver-

teilungsmodell bezeichnet. Der Vergleich der verschiedenen

Verteilungsmodelle ist der zentrale Aspekt dieser Arbeit. Da

jede der in Abb. 1 dargestellten Aktionen potentiell auf ei-

nem anderen Rechner ausgef¨

uhrt werden kann, stellen die

Pfeile 1 bis 7 m¨

ogliche Kommunikationen dar. In [BD98a]

wurde f¨

ur einen Versicherungs-WF mit 150 Sachbearbeitern

und moderaten Annahmen ¨

uber Parametergr¨

oßen berechnet,

daß sich alleine schon durch den Parametertransfer zu und

von den Aktivit¨

atenprogrammen ein Datenvolumen von 8

Mbit/sec ergibt. Damit ist ein Ethernet-basiertes Local Area

Network (LAN) schon durch die Kommunikation zwischen

der WF-Engine und den Clients ¨

uberlastet. Ein ¨

ahnliches

Beispiel findet sich in [BD97]. Solche Lastprobleme tre-

ten vor allem dann auf, wenn die Parameterdaten der Ak-

tivit¨

atenprogramme sehr umfangreich sind (z.B. Multime-

diadaten wie Bilder und Videos, eingescannte Briefe, mit

Textverarbeitungssystemen erzeugte Dokumente), da diese

f¨

ur jede einzelne Aktivit¨

ateninstanz ¨

uber das LAN trans-

portiert werden m¨

ussen. Insbesondere bei Multimediadaten

k¨

onnen auch moderne Netzwerktechnologien an ihre Lei-

stungsgrenze stoßen. Deshalb wird im folgenden nicht nur

die Belastung der WF-Server, sondern auch die des Kommu-

nikationssystems betrachtet. Die Minimierung der Kommu-

nikationslast ist noch wichtiger, wenn das WfMS ¨

uber ein

Wide Area Network (WAN) weitr¨

aumig verteilt eingesetzt

wird. Durch ein geeignetes Verteilungsmodell kann dann

nicht nur die ¨

Uberlastung der WF-Server und des Kommuni-

kationssystems verhindert werden, sondern es k¨

onnen auch

die Antwortzeiten und die Verf¨

ugbarkeit verbessert werden.

Falls sich n¨

amlich der WF-Server ,,n¨

aher“ bei den Bear-

beitern der Aktivit¨

aten befindet, so ist die WF-Ausf¨

uhrung

weniger auf das WAN angewiesen.

Viele verschiedene Aspekte eines WfMS haben Einfluß

auf die erzeugte Last. Durch ein geeignetes Verteilungsmo-

dell ist es aber m¨

oglich, diese Last so aufzuspalten und auf

die einzelnen Systemkomponenten (Server, Teilnetze und

Gateways) zu verteilen, daß eine Skalierbarkeit des Gesamt-

systems durch Hinzuf¨

ugen und Einbeziehung entsprechender

Systemkomponenten erzielbar wird. Die folgenden Betrach-

tungen sind dabei im wesentlichen unabh¨

angig davon, wie

z.B. die Aktualisierung der Arbeitslisten und der Datenfluß

konkret realisiert sind (siehe [BD98a] f¨

ur eine ¨

Ubersicht),

ob Backup-Server zur Erh¨

ohung der Verf¨

ugbarkeit einge-

setzt werden (siehe z.B. [KAGM96]), welches Transaktions-

konzept [Elm92, Ley97] zugrunde gelegt wird und ob dy-

namische ¨

Anderungen an laufenden WF-Instanzen [RD98]

unterst¨

utzt werden oder nicht. Alle diese Aspekte schlagen

sich letztlich ,,nur“ in entsprechenden Kostenfaktoren in den

einzelnen Kostenmodellen nieder und werden im folgenden

deshalb nicht mehr explizit diskutiert.

Das n¨

achste Kapitel befaßt sich mit der Analyse und

Klassifikation von Verteilungsmodellen f¨

ur WfMS. Kapitel 3

beschreibt die Simulation der unter den verschiedenen Ver-

teilungsmodellen entstehenden Last. Kapitel 4 faßt die ge-

wonnenen Erkenntnisse zusammen.

205

WfMS mit

m ehreren Servern

Server sind

nahe bei der

Anwendung

S erv er w erd en

z u fä llig

gew ählt

Server sind

nahe bei den

B earbeitern

Exotica C luster C odA lf,

BPAFrame,

METEOR2

MOBILE,

M ENTOR,

WIDE,

ADEPT

kom m erzielle System e,

Panta Rhei,

WASA,

[DHL91]

IN C A S ,

Exotica/FM QM

WfMS mit

zentralem Server

v o ll v e rte ilte

WfMS

W fM S -V e rte ilu n g sm o d e lle

Abb. 2. Verteilungsmodelle f¨

ur WfMS und Einordnung entsprechender Systeme

2 Verteilungsmodelle

Skalierbarkeit und hohe Verf¨

ugbarkeit von WfMS wird durch

Replikation von Systemkomponenten und ihre geeignete

Verteilung auf mehrere Rechner und Teilnetze erreicht. Die

daf¨

ur m¨

oglichen Verteilungsmodelle werden im folgenden

beschrieben, klassifiziert und analysiert und ihnen konkrete

kommerzielle Systeme sowie Vorschl¨

age aus dem Bereich

der Forschung zugeordnet. Die Konzepte werden hierbei

bez¨

uglich ihres Leistungsverhaltens miteinander verglichen.

Dazu wird untersucht, wie sich die Last f¨

ur die Steuerung

der Prozeßschritte und das Aktualisieren der Arbeitslisten in

der Belastung der Server und der Teilnetze niederschl¨

agt.

In einem unternehmensweiten WfMS k¨

onnen diese Werte

sehr groß werden. Damit keine Komponente ¨

uberlastet wird,

muß ihre Belastung unter die jeweils vorgegebene Maximal-

kapazit¨

at der Komponente gedr¨

uckt werden k¨

onnen. Dies

ist z.B. dann gegeben, wenn die Last in jeder Kompo-

nente O(Gesamtlast/x) betr¨

agt, wobei xeine konfigurierbare

Gr¨

oße sein muß, wie etwa die Anzahl der Server-Replikate

im System. Ist diese Bedingung durch ein Verteilungsmodell

erf¨

ullt, so kann dieses als skalierbar bezeichnet werden.

Abbildung 2 zeigt eine Kategorisierung der Verteilungs-

modelle und die Einordnung konkreter Systeme. Die bei-

den Extrempunkte des Spektrums sind Systeme mit nur ei-

nem zentralen Server und voll verteilte Systeme, bei de-

nen jede Komponente Serveraufgaben wahrnimmt. Dazwi-

schen liegen Systeme, die mehr als einen Server verwenden,

aber trotzdem noch die Trennung zwischen Client und Ser-

ver aufrechterhalten, so daß es weniger Server als Clients

(Benutzerrechner) im System gibt. Die ¨

Uberg¨

ange zwischen

den Klassen sind fließend, und nat¨

urlich gibt es Systeme,

die Mischformen darstellen. Im folgenden werden die Ver-

teilungsmodelle aber in ihrer Reinform dargestellt, um die

Unterschiede deutlich herausarbeiten zu k¨

onnen.

2.1 WfMS mit zentralem Server

Systeme dieser Kategorie verwenden eine zentrale Server-

komponente (vgl. Abb. 3). Dies ist zumindest eine zentrale

WF-Datenbank mit nur einem DB-Server. Meist wird auch

nur ein WF-Server verwendet, es gibt aber auch Systeme,

bei denen sich mehrere WF-Server die zentrale Datenbank

teilen.

Die Leistungsf¨

ahigkeit eines solchen Systems ist im we-

sentlichen durch den zentralen Server bestimmt bzw. be-

schr¨

ankt, da der Server die volle Last f¨

ur die Ausf¨

uhrung

der Aktivit¨

aten und f¨

ur die Aktualisierung der Arbeitslisten

zu tragen hat. Entsprechend stark wird das Teilnetz des DB-

Servers belastet. Ein solches System ist deshalb nur f¨

ur eine

relativ kleine Anzahl von Benutzern (einige Dutzend) ge-

eignet. Werden mehrere WF-Server verwendet, so l¨

aßt sich

die Last zwischen ihnen aufteilen, das zentrale DBMS bleibt

aber weiterhin ein potentieller Flaschenhals.

Die Beseitigung bzw. Abmilderung dieses potentiellen

Engpasses erfordert relativ rasch den Einsatz von (teuren)

Hochleistungssystemen, z.B. in Form von Mehrprozessor-

systemen und von Mehrrechner-DBMS. Ob sich damit die

erforderliche Leistung erzielen l¨

aßt, h¨

angt stark davon ab,

inwieweit man die Steuerung der einzelnen WF-Instanzen

sowie deren Daten so auf die beteiligten Teilsysteme ver-

teilen kann, daß eine gute Lastbalancierung erreicht wird

und wenig Zugriffskonflikte auftreten. Dies f¨

uhrt zur sel-

ben Problemstellung wie die Verteilung der Gesamtlast auf

mehrere (dezentrale) WF-Server. Wir werden hierauf in Ab-

schnitt 2.2 n¨

aher eingehen. Aber selbst wenn man dadurch

unter g¨

unstigen Voraussetzungen vermeiden kann, daß der

zentrale WF-Server bzw. das zentrale DBMS zum Flaschen-

hals wird, so bleibt als Nachteil, daß das Teilnetz des (zentra-

len) Hochleistungssystems zum Engpaß werden kann. Hinzu

kommt, daß weit(er) entfernte Benutzer in der Regel mit

schlechteren Antwortzeiten bedient werden.

In die Kategorie ,,zentraler Server“ fallen viele kommerzielle Sy-

steme wie WorkParty [Sie95], ProMInanD [Kar94] oder FlowMark

[IBM96] bis Version 2.1. Sie verwenden einen zentralen WF-Server oder

zumindest eine zentrale WF-Datenbank (mit zentralem DB-Server), die zur

Ausf¨

uhrung jedes Teilschritts ben¨

otigt wird. Auch einige Forschungsans¨

atze

(z.B. Panta Rhei [EG96], WASA [WHKS98], [DHL91]) setzen eine zen-

trale Kontrollinstanz voraus.

FlowMark [IBM96] erm¨

oglicht ab Version 2.2, einen Subprozeß in

einem anderen FlowMark-System (Local Domain) ausf¨

uhren zu lassen. Da-

durch entsteht eine Mischform aus einer zentralen Architektur und einer Ar-

chitektur, bei der mehrere Server verwendet werden, die jeweils nahe bei

den jeweiligen Bearbeitern angesiedelt sind (siehe Abschnitt 2.2.2). Eine

solche Kooperation von zentralen WfMS ist n¨

utzlich, wenn ein Teil eines

Prozesses von anderen Bearbeitern bzw. in anderen OE ausgef¨

uhrt wird als

der Rest. Dieser Teil wird dann von dem anderen WfMS kontrolliert. Es

ist hierbei zu beachten, daß es sich bei den verschiedenen Local Domains

um getrennte Systeme handelt, die lediglich kooperieren. Dies zeigt sich

zum Beispiel daran, daß Benutzer, die Aktivit¨

aten in verschiedenen Ab-

schnitten eines solchen aufgespaltenen Prozesses ausf¨

uhren sollen, in allen

zugeh¨

origen Systemen bekannt gemacht werden m¨

ussen.

Im Optimalfall verteilt sich die Last gleichm¨

aßig auf alle beteiligten

(zentralen) Systeme. Auch der Aufwand f¨

ur das Aktualisieren der Arbeits-

listen wird aufgeteilt, wenn die Benutzer jeweils nur in wenigen Local

Domains aktiv und gleichm¨

aßig auf sie verteilt sind. Der Aufwand f¨

ur das

Andern einer Verteilung ist allerdings sehr groß, da entsprechende Teilpro-

zesse f¨

ur die einzelnen Teilsysteme modelliert werden m¨

ussen, d.h., das

WF-Modell ver¨

andert werden muß.

206

A: Ausf

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

A: AL B: Ausf

B: AL

WF-Server

Abb. 3. Ein zentraler WF-Server bearbeitet alle WF-Instanzen des WfMS

WF-Server

A: Ausf

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tien t a u fk lä ren

3 . A d a m K n ie o p e ra to n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

A: AL B: Ausf

B: AL

WF-Server

Abb. 4. Der Cluster f¨

ur eine WF-Instanz wird bei deren Start zuf¨

allig

gew¨

ahlt

2.2 WfMS mit mehreren Servern

Systeme, bei denen der WF-Server mehrfach und auf ver-

schiedene Maschinen verteilt vorhanden ist, bilden die im

folgenden beschriebene Kategorie. F¨

ur die Verteilung der

Server gibt es drei Ans¨

atze: Man w¨

ahlt den WF-Server nach

dem Zufallsprinzip oder man versucht, aus dem Ort des Ser-

vers Vorteile zu ziehen. Hier gibt es zwei M¨

oglichkeiten:

Man kann f¨

ur die Steuerung einer Aktivit¨

at den Server ver-

wenden, der sich bei den vorgesehenen Bearbeitern befindet

oder den, der sich auf dem Knoten der zugeh¨

origen Anwen-

dung befindet.

2.2.1 Server werden zuf¨

allig gew¨

ahlt

Bei diesem Ansatz wird der Server f¨

ur eine WF-Instanz

zuf¨

allig gew¨

ahlt (Abb. 4). Die Server sind identische Repli-

kate der WF-Engine und bestehen aus einer WF-Datenbank

und einem WF-Server (WF-Cluster). Alle Prozeßtypen k¨

on-

nen von jedem Cluster ausgef¨

uhrt werden; eine Prozeß-

instanz verbleibt in dem Cluster, in dem sie gestartet wurde.

Ein Cluster ist nicht an eine OE gebunden.

In der WF-Datenbank sind die replizierte Schemainfor-

mation, die Instanzen des Clusters und der diesen Cluster

betreffende Teil der Arbeitslisten aller Benutzer gespeichert.

Jeder Client muß eine Verbindung mit jedem Cluster auf-

bauen, da in jedem Cluster Auftr¨

age f¨

ur ihn vorhanden sein

k¨

onnen.

Durch die geeignete Wahl des Clusters beim Prozeßstart

(zuf¨

allig, zyklisch, lastabh¨

angig) kann eine Lastbalancie-

rung erreicht werden. Dadurch l¨

aßt sich die durch die Akti-

vit¨

atenausf¨

uhrung entstehende Last (Parametertransfer zum

Client) auf die WF-Datenbanken verteilen. Der Ausfall ei-

ner WF-Datenbank blockiert zwar alle Instanzen des zu-

geh¨

origen Clusters, die WF-Instanzen anderer Cluster sind

hiervon aber nicht betroffen. Da die Benutzer normalerweise

auch WF-Instanzen anderer Cluster bearbeiten, k¨

onnen i.d.R.

alle Benutzer, trotz des Ausfalls eines Clusters, zumindest

eingeschr¨

ankt weiterarbeiten.

F¨

ur das Aktualisieren der Arbeitslisten stellen die Clu-

ster ein potentielles Problem dar. Von einem Cluster werden

jeweils WF aller WF-Typen kontrolliert, weshalb alle Benut-

zer des WfMS f¨

ur diesen Cluster relevant sind. Deshalb muß

ein Cluster Teile der Arbeitslisten aller Benutzer verwalten,

weshalb er einen potentiellen Flaschenhals bildet. Die An-

zahl der zu verwaltenden Arbeitslisten kann also durch die

Verwendung mehrerer Cluster nicht verringert werden, was

bei sehr großen Benutzerzahlen ein Problem sein kann.

Ein anderes Problem ergibt sich durch die Belastung

des Netzwerks. Durch die Erh¨

ohung der Anzahl der Teil-

netze (auf welche die Cluster verteilt werden) l¨

aßt sich zwar

ihre Kommunikationslast senken, aber durch die zuf¨

allige

Wahl des Clusters beim Start einer Instanz werden auch

Cluster mit ung¨

unstiger Lage gew¨

ahlt. Dieses Problem ist

bei weitr¨

aumig verteilten Systemen besonders gravierend. So

kann die Bearbeitung eines Prozesses zwar geographisch be-

schr¨

ankt sein, aber durch die ungl¨

uckliche Wahl des Clusters

f¨

ur eine Instanz st¨

andige WAN-Kommunikation zur Steue-

rung notwendig werden.

Beim Exotica-Cluster-Ansatz [AKA+94] bestehen die Cluster aus je

einer WF-Datenbank und mehreren WF-Servern. Ein Client muß sich mit

nur einem WF-Server jedes Clusters verbinden, da durch die gemeinsame

WF-Datenbank alle Server eines Clusters ¨

uber alle notwendigen Informa-

tionen verf¨

ugen.

Die Verwendung mehrerer WF-Server in einem Cluster erh¨

oht die

Verf¨

ugbarkeit, da ein Client beim Ausfall eines WF-Servers einen anderen

Server dieses Clusters verwenden kann. Der Ausfall der WF-Datenbank

blockiert nat¨

urlich weiterhin den gesamten betroffenen Cluster. Die Ver-

wendung mehrerer WF-Server je Cluster reduziert die Last pro Server, die

durch die Aktivit¨

atenausf¨

uhrung und das Aktualisieren der Arbeitslisten

entsteht. Da die Server eines Clusters alle Benutzer bedienen m¨

ussen, bil-

det die WF-Datenbank beim Aktualisieren der Arbeitslisten aber weiterhin

einen Flaschenhals.

2.2.2 Server sind nahe bei den Bearbeitern

Die im folgenden beschriebenen Ans¨

atze versuchen aus der

gezielten Wahl des WF-Servers Vorteile zu ziehen. Dazu

wird jeweils der WF-Server verwendet, der nahe bei den Be-

arbeitern liegt. Dieser Ansatz basiert auf der Annahme, daß

die meisten Aktivit¨

aten von Benutzern ausgef¨

uhrt werden,

die (fast) alle derselben OE angeh¨

oren. Diese stellt somit

einen guten Ort f¨

ur den WF-Server dar. Eine OE kann jede

Art von organisatorischer Einheit sein. Allerdings wird in

diesem Zusammenhang gefordert, daß die OE geographisch

beschr¨

ankt ist.

Die Konzepte dieser Kategorie k¨

onnen danach unter-

schieden werden, ob eine Prozeßinstanz den WF-Server

wechseln kann, also eine Migration1m¨

oglich ist (Abb. 5b),

oder nicht (Abb. 5a). Eine solche Migration ist sinnvoll,

wenn es Prozesse gibt, die nacheinander in verschiedenen

OE bearbeitet werden. Man denke an einen Prozeß, der zu-

erst die Verkaufsabteilung durchl¨

auft und dann den Versand.

Sind diese weit voneinander entfernt, so ist es wesentlich

billiger, den gesamten Prozeß einmal zu migrieren, als die

WAN-Verbindung f¨

ur jeden weiteren Teilschritt zu verwen-

den. Bei den Ans¨

atzen, bei denen keine Migration m¨

oglich

ist, wird von der Annahme ausgegangen, daß ein komplet-

ter Prozeß weitgehend zu nur einer OE geh¨

ort. Aktivit¨

aten,

die in anderen OE ausgef¨

uhrt werden, werden ebenfalls von

diesem, dann nat¨

urlich nicht optimalen Server gesteuert.

1Bei einer Migration m¨

ussen alle Instanzdaten zum neuen Server ko-

piert werden, bevor dieser die Kontrolle ¨

uber die Instanz ¨

ubernehmen kann.

Dies sind zum einen die Parameterdaten und zum anderen die Zustandsin-

formation der Instanz (z.B. in Form einer Ablaufhistorie).

207

A: Ausf

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

A: AL B: Ausf

B: AL

A: Ausf

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

A: AL B: Ausf

B: AL

W F-Server W F-Server

WF-Server

d er W F -S erv er w ird b ei d en

B earbeitern des W F gew ählt

d er W F -S erv er w ird b ei d en

B earbeitern der A kt. A gew ählt

d er W F -S erv er w ird b ei d en

B earbeitern der A kt. B gew ählt

Abb. 5. WF-Server nahe bei den potentiellen Bearbeitern, Granularit¨

at: a

gesamter Prozeß (ohne Migration), beinzelne Aktivit¨

aten (mit Migration)

Wird die Anzahl dieser ,,entfernten“ Aktivit¨

aten zu groß,

so kann die durch ihre Ausf¨

uhrung erzeugte Kommunikati-

onslast sehr hoch werden.

Ist eine Migration von Prozeßinstanzen m¨

oglich, so kann

im Prinzip jede Aktivit¨

at von dem f¨

ur sie optimalen Server

kontrolliert werden. Allerdings gehen einige dieser Ans¨

atze

von der einschr¨

ankenden Annahme aus, daß alle potentiel-

len Bearbeiter einer Aktivit¨

at derselben OE angeh¨

oren. Die

Bearbeiteraufl¨

osung erfolgt dann nur lokal f¨

ur die Benut-

zer im Domain dieses WF-Servers, eine globale Bearbeiter-

aufl¨

osung findet nicht statt.

Wir analysieren zuerst die Variante ohne Migration. Die

Server sind jeweils f¨

ur verschiedene Prozeßtypen zust¨

andig.

Da deren Laufzeitdaten voneinander unabh¨

angig sind, ist

keine Synchronisation zwischen den WF-Servern notwen-

dig. Die Last f¨

ur die Steuerung der Aktivit¨

atenausf¨

uhrung

wird unter den Servern aufgeteilt. Das Verteilen der Last

ist etwas schwierig, da Prozesse nur als Ganzes einem Ser-

ver zugeordnet werden k¨

onnen. Sollte ein Prozeßtyp alleine

schon einen Server ¨

uberlasten, gibt es keine geeignete Ver-

teilung.

Auch wenn Migrationen m¨

oglich sind, teilt sich die Last

f¨

ur die Steuerung der Aktivit¨

atenausf¨

uhrung zwischen den

WF-Servern auf. Es kommen zwar die Migrationskosten

hinzu, aber die durch die Aktivit¨

atenausf¨

uhrung erzeugte

Kommunikationslast ist geringer, da durch die Migration f¨

jede Aktivit¨

at ein geeigneter WF-Server ausgew¨

ahlt werden

kann.

Zur Absch¨

atzung der Belastung der Server durch das Ak-

tualisieren der Arbeitslisten nehmen wir generell an, daß ein

Benutzer nicht in alle Prozeßtypen bzw. Aktivit¨

atentypen

involviert ist. Deshalb ist jeder Server nur f¨

ur einen Teil

der Benutzer zust¨

andig, weshalb er auch nur einen Teil der

Last bew¨

altigen muß. Erfolgt die Bearbeiteraufl¨

osung nur

lokal, d.h., ist der Server nur f¨

ur die Bearbeiter seines Do-

mains zust¨

andig, so erzeugt das Aktualisieren der Arbeitsli-

sten besonders wenig Last. Allerdings hat diese Variante den

Nachteil, daß beim Ausfall eines Servers alle seine Benut-

zer blockiert sind, da sie ihre Auftr¨

age nur von ihm erhalten.

Außerdem sind manchmal Aktivit¨

aten w¨

unschenswert, die in

mehreren OE bearbeitet werden k¨

onnen (z.B. Einholen einer

Unterschrift von einem beliebigen Abteilungsleiter). Diese

sind bei lokaler Bearbeiteraufl¨

osung nicht modellierbar. Des

weiteren schr¨

ankt dieses Konzept die Replikation der Server

ein. Bei ¨

Uberlastung eines Servers ist es nicht m¨

oglich, die

Last auf mehrere Server zu verteilen, da diese dann getrennte

OE mit disjunkten Benutzern darstellen w¨

urden.

MOBILE [HS96, Jab97] verfolgt das Ziel, durch Replikation der Ser-

ver und Partitionierung der Daten die Last f¨

ur die einzelnen Server zu

minimieren und dadurch eine m¨

oglichst hohe Gesamtlast zu bew¨

altigen.

Dazu werden die Aufgaben eines WF-Servers in sogenannte Aspekte zer-

legt, wie z.B. den funktionalen Aspekt, den Kontollfluß und den Datenfluß.

Jeder dieser Aspekte wird durch einen eigenen Server realisiert, die durch

einen Systemkern verbunden sind. Ist ein solcher Server ¨

uberlastet, so wird

er repliziert.

Das Synchronisationsproblem bei ¨

Anderung der Daten dieser Server

wurde folgendermaßen gel¨

ost: Statische Daten, wie z.B. Schemadaten, wer-

den repliziert. Die Server f¨

ur verschiedene Aspekte haben keine gemein-

samen Daten, außer der statischen WF-Id; diese wird repliziert. Die ande-

ren Daten lassen sich nach den Aspekten partitionieren. Die verschiedenen

Replikate eines Servers f¨

ur denselben Aspekt verwenden zwar dieselben

dynamischen Instanzdaten, aber jeder Workflow-Typ hat eine korrespon-

dierende OE und damit einen fest zugeordneten Server. Es werden also

gesamte Prozesse einem WF-Server zugeordnet, eine Migration ist nicht

vorgesehen. Entsprechend dieser Zuordnung lassen sich diese Daten parti-

tionieren.

Die Aufteilung in Aspekte bringt eine Reduktion der Last um besten-

falls einen Faktor, der der Anzahl der verschiedenen Aspekte entspricht. Da

dies aber ein kleiner (konstanter) Faktor ist (gem¨

aß [HS96]: 6), f¨

uhrt dies

zu keiner signifikanten Reduktion der Last. Daß sich die Last gleichm¨

aßig

auf die Aspekte-Server verteilt, ist zudem unrealistisch, da deren Aufga-

ben v¨

ollig unterschiedlichen Aufwand erfordern. Hinzu kommt, daß f¨

bestimmte Operationen (wie z.B. die dynamische Restrukturierung eines

Ablaufgraphen) fast alle Aspekte ben¨

otigt werden, so daß durch die Vertei-

lung auf mehrere Server ein zus¨

atzlicher Kommunikations- und Synchro-

nisationsaufwand entsteht.

In [SNS99] wurde der MOBILE-Ansatz noch erweitert. Beim Start ei-

nes (Sub-)WF, also zur Laufzeit, wird entschieden, von welchem WF-Server

dieser kontrolliert werden soll. Bei dieser Entscheidung werden Rechte, Ge-

wichte (gew¨

unschte Ressourcenzuordnung) und Kosten (Leistungsf¨

ahigkeit

von Rechnern und Kommunikationsverbindungen) ber¨

ucksichtigt. Es findet

allerdings keine Migration der Prozeßinstanz statt, sondern die Subprozesse

werden entfernt gestartet. Beim Start und bei der Beendigung jedes Sub-

WF muß deshalb mit dem Server des Vater-WF kommuniziert werden, auch

wenn der n¨

achste Sub-WF wieder vom selben Server kontrolliert wird.

Das MENTOR-System [WWWK96a, WWWK96b, WWK+97,

MWW+98] basiert auf einigen Standardkomponenten, wie dem Transak-

tionsmonitor TUXEDO [UNI92], CORBA [OMG95] und Statemate, einem

Werkzeug zur Modellierung und Ausf¨

uhrung von State-/Activitycharts. Da-

bei wird in einem Statechart der Kontrollfluß und in einem Activitychart

der zugeh¨

orige Datenfluß und der funktionale Aspekt eines Workflows mo-

delliert. Kernidee des in diesem Projekt verfolgten Ansatzes ist es nun,

die State-/Activitycharts so zu partitionieren, daß eine zum zentralen Fall

aquivalente verteilte Ausf¨

uhrung entsteht und jede Aktivit¨

at in einem zuvor

f¨

ur sie nach OE festgelegten ,,Processing Entity“ ausgef¨

uhrt wird. Der ent-

sprechende Server ist somit nur f¨

ur die ihm zugeordneten Aktivit¨

aten und

f¨

ur die seinem Processing Entity angeh¨

origen Benutzer zust¨

andig. Dies ist

einer der Ans¨

atze, die auf eine globale Bearbeiteraufl¨

osung verzichten.

An den Zerlegungspunkten des State-/Activitycharts erfolgt ein Wech-

sel des Servers, d.h., die komplette Prozeßinstanz migriert zu einem ande-

ren Server. Es werden nur globale Variablen verwendet, deren ¨

Anderungen

durch einen in jedem Server vorhandenen Communication-Manager pro-

pagiert werden. Alle Kommunikationen werden durch ein zwei-Phasen-

Commit-Protokoll (2PC) gesch¨

utzt, weshalb die verwendeten Anwendun-

gen das XA-Protokoll unterst¨

utzen m¨

ussen.

WIDE [CGP+96, CGS97] verfolgt einen ¨

ahnlichen Ansatz, allerdings

ist die Skalierbarkeit in diesem Projekt nur ein Teilaspekt. Es wird auch ein

Transaktionsmanagement auf verschiedenen logischen Ebenen (geschach-

208

telte Transaktionen f¨

ur Aktivit¨

aten bzw. Sagas f¨

ur Prozesse) angeboten. Mit

Hilfe von aktiven Regeln ist zudem eine Ausnahmebehandlung m¨

oglich.

Die Idee zur Verteilung ist analog zu MENTOR. Allerdings ist noch keine

Migration vorgesehen, sondern die Daten verbleiben an einem Ort, und

es wird entfernt mit Hilfe von CORBA-Diensten auf sie zugegriffen. Dies

kann zu den schon erw¨

ahnten hohen Kosten bei mehrfachem weit entfernten

Zugriff f¨

uhren.

In ADEPT [BD97, BD98b] wird außer den Servern auch die Netzstruk-

tur betrachtet, da auch Teilnetze durch zuviel Kommunikation ¨

uberlastet

werden k¨

onnen. Deshalb wird versucht, die Kommunikationskosten zu mi-

nimieren, indem f¨

ur jede Aktivit¨

at der optimale Server gew¨

ahlt wird. Dazu

wird eine Aktivit¨

at meist von dem Server kontrolliert, in dessen Teilnetz

sich die meisten Benutzer mit einer passenden Rolle befinden. Die Akti-

vit¨

at wird aber auch geeigneten Benutzern in anderen Teilnetzen angeboten

(globale Bearbeiteraufl¨

osung). – Es gibt Aktivit¨

aten, die bei verschiedenen

WF-Instanzen in unterschiedlichen OE (z.B. Abteilungen) ausgef¨

uhrt wer-

den, woraus sich jeweils ein anderer optimaler Server ergibt. Ein Beispiel

hierf¨

ur ist eine Aktivit¨

at ,,Patient f¨

ur die Operation vorbereiten“, die von

einer Pflegekraft der Station ausgef¨

uhrt wird, auf der der betroffene Patient

liegt. Deshalb wird in ADEPT f¨

ur solche Aktivit¨

aten der Server jeweils in

der zugeh¨

origen OE gew¨

ahlt (variable Serverzuordnung [BD98b, BD99]).

– Aufgrund von ¨

Uberlastung oder Ausfall eines Servers kann es vorteilhaft

sein, von der vorgeplanten Serverzuordnung dynamisch abzuweichen. Dies

wird realisiert, indem Serverbeschreibungen einzelner WF-Instanzen vom

WfMS zur Laufzeit ver¨

andert werden.

Um die Verteilung zu optimieren, werden Algorithmen verwendet, die

zur Modellierungszeit laufen, also die Server nicht zus¨

atzlich belasten. Die

Algorithmen berechnen eine Verteilung, durch welche die Kommunikati-

onskosten minimiert werden und analysieren die Last f¨

ur die einzelnen

Komponenten (WF-Server, Teilnetze und Gateways). Bei diesen Kosten

wird die Kommunikation f¨

ur das Aktualisieren der Arbeitslisten und f¨

den Parametertransfer bei der Aktivit¨

atenausf¨

uhrung ber¨

ucksichtigt. Aber

auch die Migrationskosten und die Kommunikationen von Anwendungen

mit externen Datenquellen werden mit einbezogen.

Die Belastung f¨

ur die WF-Server, WF-Datenbanken und Teilnetze wird

bei diesem Ansatz verteilt. Die Migrationskosten sind dabei niedriger als

bei MENTOR und WIDE, da nicht bei jedem Wechsel der OE migriert

werden muß.

2.2.3 Server sind nahe bei der Anwendung

Eine weitere M¨

oglichkeit, um aus der Wahl des Ortes des

WF-Servers Vorteile zu ziehen, ist ihn dort zu plazieren,

wo das Anwendungsprogramm der entsprechenden Aktivit¨

l¨

auft (Abb. 6). Diese Variante wird vor allem von Systemen

verwendet, die auf einer objektorientierten Infrastruktur (z.B.

CORBA) basieren. Die Anwendung ist dabei als Objekt ge-

kapselt, das an einem bestimmten Ort im verteilten System

allokiert ist. Das entsprechende Teilnetz oder sogar derselbe

Rechner wird auch f¨

ur den WF-Server der zugeh¨

origen Ak-

tivit¨

at gew¨

ahlt. Die Prozeßinstanz ist ein Objekt, das zu dem

jeweiligen WF-Server migriert. Eine andere M¨

oglichkeit ist,

daß lediglich Objektreferenzen zwischen den Servern wan-

dern und diese dann bei der Verwendung der zugeh¨

origen

Parameter entfernt auf die entsprechenden Objekte zugrei-

fen.Die durch die Aktivit¨

atenausf¨

uhrung erzeugte Last l¨

aßt

sich dadurch auf die einzelnen Server verteilen. Die bei

diesem Konzept entstehende Migrationslast ist allerdings

recht groß, da das Instanzenobjekt bei fast jedem Teil-

schritt migriert (selbst wenn er vom selben Bearbeiter wie

der Vorg¨

angerschritt ausgef¨

uhrt wird), weil gew¨

ohnlich eine

andere Anwendung verwendet wird. Falls vom WF-Server

entfernt auf die Daten zugegriffen wird, verringert dies

zwar die Migrationslast, aber die Last durch die Akti-

A: Ausf

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er at o n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

A: AL B: Ausf

B: AL

d er W F -S erv er w ird b eim

A nw endungsprogram m

d e r A k tiv itä t A g e w äh lt

d er W F -S erv er w ird b eim

A nw endungsprogram m

d e r A k tiv itä t B g ew ä h lt

Abb. 6. Der WF-Server wird nahe bei Anwendung plaziert

vit¨

atenausf¨

uhrung ist wesentlich gr¨

oßer, da die Anwendun-

gen mehrfach auf ein (evtl. weit) entferntes Objekt zugreifen.

Ein generelles Problem des Ansatzes ist, daß die Verteilung

der Last davon abh¨

angt, wie h¨

aufig die einzelnen Anwendun-

gen aufgerufen werden. Dies l¨

aßt sich nicht immer steuern.

Es ist schwierig, die Belastung der Server durch das Ak-

tualisieren der Arbeitslisten zu bestimmen. Ein Server muß

prinzipiell alle Benutzer bedienen, da die Verteilung nicht an

OE (z.B. Abteilungen) orientiert ist, sondern an Anwendun-

gen. Dadurch kann er zu einem Flaschenhals werden. Aller-

dings werden i.d.R. die meisten Benutzer nur wenige An-

wendungen aufrufen d¨

urfen, da sie ihre Rolle auf bestimmte

T¨

atigkeiten einschr¨

ankt. Da deshalb jede Anwendung nur

von bestimmten Benutzern verwendet wird, m¨

ussen nur de-

ren Arbeitslisten gewartet werden, was die Last f¨

ur den WF-

Server reduziert. Diese Annahme muß aber nicht gelten. Es

sind Szenarien denkbar, in denen es Abteilungen gibt, deren

Mitarbeiter zwar getrennte Prozesse bearbeiten, jedoch mit

denselben Anwendungen. In einem solchen Fall wird jede

Anwendung von jedem Benutzer aufgerufen, wodurch die

Skalierbarkeit eingeschr¨

ankt wird.

Dieser Ansatz geht zudem von der Annahme aus, daß

jede Anwendung einen eindeutig bestimmbaren Ort hat.

Das ist auch der Grund daf¨

ur, daß dieses Verteilungsmo-

dell vor allem von Ans¨

atzen verwendet wird, die auf ei-

ner objektorientierten Infrastruktur basieren. Da das Akti-

vit¨

atenprogramm dann als Objekt gekapselt ist, hat es stets

einen bestimmbaren Ort. Bei einer Datenbankanwendung

w¨

are dieser z.B. durch den Rechner bestimmt, auf dem das

DBS l¨

auft. Problematisch sind Anwendungen, die auf meh-

reren Rechnern installiert sind oder ¨

uber das Netzwerk ge-

startet werden, wie z.B. ein Editor, eine Textverarbeitung

oder eine Eingabemaske. Solche Anwendungen werden im-

mer auf dem Rechner des (a priori unbekannten) Benutzers

ausgef¨

uhrt, der die Aktivit¨

at bearbeitet. Da durch die An-

wendung kein Ort vorgegeben wird, ist dieser Ansatz nicht

ohne weiteres verwendbar, weil dann kein WF-Server f¨

die entsprechende Aktivit¨

at bestimmt werden kann. Man

k¨

onnte nun f¨

ur den WF-Server einen beliebigen Ort w¨

ahlen,

dies w¨

are aber bez¨

uglich der Kommunikationskosten sehr

ung¨

unstig. Es bietet sich an, den WF-Server in diesen F¨

allen

wie bei den Ans¨

atzen aus Abschnitt 2.2.2 so zu w¨

ahlen, daß

er nahe bei den Bearbeitern der Aktivit¨

at liegt. – In der

Regel werden Anwendungen wohl h¨

aufig auf Rechnern der

OE laufen, zu der ihre Bearbeiter geh¨

oren, so daß die letzten

beiden Verteilungsmodelle zu ¨

ahnlichen Ergebnissen f¨

uhren.

In [SM96] werden die verwandten Systeme CodAlf und BPAFrame

beschrieben, die auf unterschiedlicher objektorientierter Middleware basie-

ren. W¨

ahrend CodAlf eine objektorientierte Erweiterung des OSF DCE

[Sch93] verwendet, basiert BPAFrame auf CORBA [OMG95]. Wie oben

209

beschrieben, wird jede Anwendung in einem Objekt gekapselt. Ein sol-

ches Objekt hat einen festen Ort – an dem sich auch der zugeh¨

orige WF-

Server befindet – und wird als Runtime-System bezeichnet. Prozeßtypen

werden als Objekttypen implementiert, die Prozeßinstanzen sind somit als

Objekte realisiert. Sie enthalten außer den Anwendungsdaten auch noch die

Prozeßbeschreibung. Diese mobilen Objekte migrieren zum Ort des Anwen-

dungsobjektes der n¨

achsten Aktivit¨

at. Dieser Ort wird von einer Kompo-

nente (Trader) ermittelt, die als Directory Service dient (also angibt, wo

sich ein geeignetes Objekt befindet) und außerdem eine Lastverteilung vor-

nimmt. Der erforderliche entfernte Zugriff auf Daten wird durch die ver-

wendeten Middleware-Dienste realisiert. Dasselbe gilt f¨

ur den Zugriff der

Benutzer auf die entfernten Runtime-Systeme.

Wie oben bereits ausgef¨

uhrt wurde, h¨

angt bei diesem Ansatz die Last

eines WF-Servers davon ab, wie h¨

aufig die zugeh¨

orige Anwendung verwen-

det wird. Falls es aber m¨

oglich ist, den Anwendungsserver zu replizieren,

so sorgt der Trader f¨

ur eine Verteilung der Last.

METEOR2[DKM+97, MSKW96, SK97] verwendet einen Ansatz, der

dem eben beschriebenen sehr ¨

ahnlich ist. Er basiert ebenfalls auf CORBA.

Allerdings ist die Ablaufbeschreibung nicht in einem mobilen Instanzen-

objekt enthalten, sondern sie wird in ihre Teilschritte (jeweils mit Kanten

zu vorangehenden und nachfolgenden Aktivit¨

aten) zerlegt. Aus dieser In-

formation wird f¨

ur jede Aktivit¨

at ein Teil des WF-Servers (Taskmanager

genannt) erzeugt, der die Ausf¨

uhrung genau dieser Aktivit¨

at steuert. Ein

Taskmanager kann prinzipiell an einem beliebigen Ort allokiert werden,

allerdings wird auch hier der Ort der Anwendung vorgeschlagen. Im Ge-

gensatz zu den beiden letzten Ans¨

atzen migrieren keine Instanzenobjekte

zwischen den Taskmanagern. Statt dessen werden beim Weiterschalten des

Prozesses zur n¨

achsten Aktivit¨

at Referenzen auf die verwendeten Daten-

objekte ¨

ubergeben. Bei der Ausf¨

uhrung einer Aktivit¨

at muß dann auf die

i.d.R. entfernt liegenden Datenobjekte zugegriffen werden. Schließlich wird

in METEOR2der Ort der Anwendungen und der Taskmanager eindeutig

festgelegt, so daß die Aufgabe des Traders entf¨

allt. Dadurch ist aber auch

keine dynamische Lastbalancierung m¨

oglich.

Der Ansatz betrachtet auch noch weitere Aspekte, wie den Wie-

deranlauf nach Fehlern oder die effiziente Ermittlung des aktuellen Zu-

stands einer Prozeßinstanz. Zu diesem Zweck gibt es einen zentralen

Monitoring-Service, dem die Taskmanager ¨

Anderungen der Zust¨

ande mel-

den. Außerdem werden ihm Referenzen auf verwendete Daten geschickt,

um die Daten beim Wiederanlauf nach Fehlern rekonstruieren zu k¨

onnen.

Außer der Last der WF-Server ist bei diesem Ansatz auch noch die

Belastung des Monitoring-Services interessant. Da diese zentrale Kom-

ponente bei der Ausf¨

uhrung jeder Aktivit¨

at ¨

uber ¨

Anderungen informiert

werden muß, ist ihre Last proportional zu der Last, die durch die Ak-

tivit¨

atenausf¨

uhrung erzeugt wird. Sie ist allerdings nur ein sehr kleiner

Bruchteil dieser Last, da lediglich Referenzen auf Daten ¨

ubertragen und

nur einfache Lese- und Schreiboperationen durchgef¨

uhrt werden. Aus die-

sem Grund ist eine zentrale Komponente bis zu einer sehr hohen Systemlast

ausreichend. Etwas schlechter sieht die Analyse f¨

ur das Teilnetz aus, in dem

der Monitoring-Service angesiedelt ist. Es werden zwar nur kleine Pakete

ubertragen, daf¨

ur aber sehr viele. 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 vorge-

sehen, sie w¨

urde im Fall einer Netzpartitionierung auch nicht verhindern,

daß der abgeschnittene Teil (u.U. ist das der gr¨

oßere Teil) blockiert ist.

2.3 Voll verteilte WfMS

Ein WF-Server und das zugeh¨

orige Teilnetz sind potenti-

elle Engp¨

asse eines Systems. Diese k¨

onnen vermieden wer-

den, indem man auf (explizite) Server verzichtet und die

entsprechende Funktionalit¨

at in jedem Client realisiert. Die

komplette WF-Instanz migriert dann nach Beendigung ei-

ner Aktivit¨

at und der Ermittlung des n¨

achsten Bearbeiters

zu dessen Rechner (siehe Abb. 7). Das heißt, jeder Arbeits-

platzrechner fungiert quasi als ,,Mini-Server“ f¨

ur seine loka-

len Anwendungen. Beim Ermitteln dieses Bearbeiters wird

eine verteilte Synchronisation notwendig. Hierbei stellt sich

die Frage, woher ein Client alle angemeldeten Benutzer mit

A: Ausf

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

Müller

Adam

Schulz

Datum

3.2.98

7.5.97

Grad

120

Bem .

noch

offen

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er ato n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er ato n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er ato n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er ato n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er ato n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

1. M eier M iniskusoperation

2 . M ü lle r P a tie n t au fk lä re n

3 . A d a m K n ie o p er ato n

4. S chulze U ntersuchung

A u s w a h l > _ _ _

A: AL B: Ausf

B: AL

K ontrolle durch den R echner

d e s B ea rb e ite rs d er A k tiv itä t B

K ontrolle durch den R echner

d e s B ea rb e ite rs d er A k tiv itä t A

Abb. 7. WF-Kontrolle durch den Rechner des Benutzers, der die aktuelle

Aktivit¨

at ausf¨

uhrt

einer passenden Rolle f¨

ur die Nachfolgeaktivit¨

at kennt. Dies

ist notwendig, um einen entsprechenden Eintrag in deren

Arbeitslisten einf¨

ugen zu k¨

onnen. Dieses Problem wird von

manchen Systemen dadurch umgangen, daß man auf die Be-

arbeiteraufl¨

osung verzichtet und jeder Aktivit¨

at einen ein-

deutigen Bearbeiter zuordnet.

Die durch die WF-Ausf¨

uhrung entstehende Last verteilt

sich auf alle Arbeitsstationen des Systems. Hierdurch ist die

Last pro Komponente (,,Mini-Server“) kleiner als bei den

in Abschnitt 2.2 beschriebenen Systemen. Das ist auch not-

wendig, da die Arbeitsstationen keine leistungsstarken Ma-

schinen, sondern nur die Rechner der Benutzer sind. Die Mi-

grationslast ist bei voll verteilten Ans¨

atzen besonders hoch,

weil die Prozeßinstanz bei fast jedem Teilschritt migriert.

Der daf¨

ur erforderliche Aufwand teilt sich ebenfalls auf die

Arbeitsstationen aller Benutzer auf. Wird auf eine Bearbei-

teraufl¨

osung verzichtet, so wird der Aufwand f¨

ur die ver-

teilte Synchronisation vermieden. Dies stellt aber einen Ver-

lust an Funktionalit¨

at bzw. Flexibilit¨

at dar, der nicht bei

jeder Anwendung akzeptiert werden kann. Wird eine Be-

arbeiteraufl¨

osung durchgef¨

uhrt, so verteilt sich die dadurch

entstehende Last auf die vielen Arbeitsstationen der Benut-

zer, weshalb die Last f¨

ur eine einzelne Maschine klein ist.

Da es keine WF-Server gibt, bei denen sich die Kommuni-

kation konzentriert, gibt es keine Flaschenh¨

alse im Kommu-

nikationsnetzwerk. Die Belastung der Teilnetze stellt also

kein Problem dar, wenn die Arbeitsstationen auf ausrei-

chend viele Teilnetze verteilt werden. Problematisch ist, daß

die Zustandsinformation nicht in Servern verf¨

ugbar, sondern

uber die Benutzerrechner verteilt ist. Deshalb muß der WF

,,gesucht“ werden, wenn nach seinem aktuellen Zustand ge-

fragt wird, was zu einem hohen Aufwand f¨

uhrt.

INCAS [BMR96] ist ein System, das auf eine Bearbeiteraufl¨

osung

verzichtet. Der Name kommt von einem INformation CArrier, der jeweils

zur Arbeitsstation der n¨

achsten Aktivit¨

at migriert. Dieser INCA enth¨

alt den

gew¨

unschten Dienst, Regeln, die den Daten- und Kontrollfluß beschreiben,

die Daten der Instanz und Atomarit¨

atsanforderungen. Auch die Arbeitssta-

tionen verf¨

ugen ¨

uber Regeln, die mit denen des INCA zusammen verwendet

werden, um eine Aktivit¨

at auszuf¨

uhren und die n¨

achste Aktivit¨

at zu berech-

nen. F¨

ur diese Nachfolgeaktivit¨

at wird, ebenfalls anhand der Regeln, die

zugeh¨

orige Arbeitsstation berechnet. Es findet keine Bearbeiteraufl¨

osung

statt, somit ist auch keine Synchronisation zwischen den potentiellen Nach-

folgern notwendig. Bei jedem Weiterschalten zur n¨

achsten Aktivit¨

at wird

der INCA ver¨

andert. Er wird allerdings nicht modifiziert, sondern es wird

eine neue Version von ihm erzeugt, die zusammen mit der alten migriert. Da

dadurch die Prozeßinstanz sehr groß wird, ist die durch die Migration ver-

ursachte Last besonders hoch. Ein Vorteil dieser Vorgehensweise ist jedoch,

daß sich Regeln auch auf alte Versionen der Daten beziehen k¨

onnen. Das

gesamte System wird durch Regeln gesteuert. Die Regelmenge ist sogar

dynamisch, d.h., bei der Ausf¨

uhrung einer Aktivit¨

at k¨

onnen Regeln erzeugt

oder ver¨

andert werden. Auch die Transaktionssemantik der Aktivit¨

aten wird

210

mittels Regeln definiert. Allerdings ist eine große, verteilte und dazu noch

dynamische Regelmenge schwer zu durchschauen.

Bei Exotica/FMQM [AMG+95] wird nach Beendigung einer Aktivit¨

eine globale Bearbeiteraufl¨

osung durchgef¨

uhrt. Die Kommunikation findet

(gesichert) ¨

uber Persistent-Queues statt. Der Ablauf wird wie in FlowMark

durch einen Graphen mit Kontroll- und Datenkonnektoren beschrieben. Die-

ser Graph wird so auf die Knoten verteilt, daß jeder Knoten diejenigen Teile

des Graphen erh¨

alt, die Aktivit¨

aten mit den Rollen seiner Benutzer enthal-

ten. Ist die Bearbeitung einer Aktivit¨

at beendet, so werden Nachrichten an

alle Knoten geschickt, die f¨

ur Aktivit¨

aten verantwortlich sind, zu denen von

der aktuellen Aktivit¨

at aus Kontroll- oder Datenkanten f¨

uhren. Die Daten

werden bei dieser Methode schrittweise verteilt, sie migrieren nicht mit der

Prozeßinstanz.

Wegen der Bearbeiteraufl¨

osung kann eine Instanz nicht einfach an den

Knoten der nachfolgenden Aktivit¨

at gesendet werden, sondern dieser muß

erst ermittelt werden. Dazu informiert der Vorg¨

angerknoten alle potenti-

ellen Nachfolger ¨

uber die zu vergebende Aktivit¨

at, indem er die entspre-

chende Information in deren Message-Queues schreibt. Diese holen sich

dann die Instanz aus dessen Ausgabe-Queue, wenn sie die n¨

achste Aktivit¨

ausf¨

uhren wollen. Die Synchronisation erfolgt durch das Transaktionskon-

zept des Queueing-Systems. Durch die Auswertung der von einer Aktivit¨

ausgehenden Datenkonnektoren lassen sich aber lediglich die Aktivit¨

aten

ermitteln, die diese Daten potentiell ben¨

otigen. Es ist jedoch noch nicht

bekannt, an welchen Knoten diese sp¨

ater ausgef¨

uhrt werden, so daß die

Instanzdaten zu ihnen transportiert werden k¨

onnen. Die bei diesem Ansatz

erzeugte Last h¨

angt stark davon ab, wie effizient der persistente Message-

Queue-Dienst implementiert ist, insbesondere ob das entfernte Lesen (effi-

zient) unterst¨

utzt wird.

Tabelle 1 bietet eine ¨

Ubersicht ¨

uber die wichtigsten Ei-

genschaften der in diesem Kapitel diskutierten Verteilungs-

modelle. Im n¨

achsten Kapitel wird diese qualitative Analyse

durch quantitative Untersuchungen untermauert.

3 Simulation der Verteilungsmodelle

Um einen quantitativen Vergleich zu erm¨

oglichen, wurde

die WF-Ausf¨

uhrung f¨

ur folgende Verteilungsmodelle simu-

liert (vgl. Tabelle 2): Zentraler Server, zuf¨

allig gew¨

ahlter

Server (Cluster), Server nahe bei den Bearbeitern mit/ohne

Migration und mit/ohne globaler Bearbeiteraufl¨

osung, varia-

ble Serverzuordnung, Server bei der Anwendung und voll

verteiltes WfMS. Um einen wirklich objektiven Vergleich

der Verteilungsmodelle zu erhalten, w¨

are an sich die Si-

mulation sehr vieler Szenarien erforderlich. Da dies hier

aus Platzgr¨

unden nicht m¨

oglich ist, haben wir lediglich

zwei WF-Typen simuliert, hierbei aber darauf geachtet, daß

keine ,,unfairen Parameter“ verwendet werden. Das heißt,

die Szenarien wurden so ausgew¨

ahlt, daß die St¨

arken und

Schw¨

achen aller Verteilungsmodelle zum Tragen kommen.

Das verwendete Simulationsprogramm erm¨

oglicht es, die

WF-Ausf¨

uhrung unter verschiedenen Verteilungsmodellen

zu simulieren. Es berechnet f¨

ur die WF-Server, die Teil-

netze und Gateways die in einem realen WfMS durch die

WF-Ausf¨

uhrung entstehende Last. Dabei werden die Ko-

sten f¨

ur den Transfer von Parameterdaten zu und von den

Aktivit¨

atenprogrammen, f¨

ur das Aktualisieren der Arbeitsli-

sten und f¨

ur die Migrationen ber¨

ucksichtigt. Dem Simulati-

onsprogramm werden Beschreibungen der zu simulierenden

WF-Typen, die Anzahl der Instanzen und die Eigenschaften

der Benutzer (z.B. Rolle, Teilnetz) vorgegeben. Die kon-

kreten Zeitpunkte f¨

ur den Start der WF-Instanzen werden

zuf¨

allig im Simulationszeitraum gew¨

ahlt. Die Bearbeitungs-

zeiten der Aktivit¨

aten sind in einem vorgegebenen Zeitinter-

vall gleichverteilt. Nach Beendigung einer Aktivit¨

at durch

Tabelle 1. Die wichtigsten Eigenschaften der untersuchten Verteilungsmo-

delle

Modell Eigenschaften

WfMS mit zentralem Server:

•der WF-Server und dessen Teilnetz bilden potentielle Fla-

schenh¨

alse

•es gibt wenig M¨

oglichkeiten zur Optimierung der Lage des

WF-Servers

WfMS mit mehreren Servern

Server werden zuf¨

allig gew¨

ahlt:

•ist einfach zu realisieren, kein Zusatzaufwand durch Migra-

tionen

•keine Optimierung bzgl. Kommunikationskosten m¨

oglich

•jeder Cluster (WF-DB) muß Arbeitslisten aller Benutzer

verwalten

Server sind nahe bei den Bearbeitern:

•Last verteilt sich auf Server, gute Verteilung der Kommu-

nikationslast m¨

oglich

•ohne Migration: Server ist bzgl. einzelner Aktivit¨

aten nicht

optimal

•lokale Bearbeiteraufl¨

osung: eingeschr¨

ankte Funktionalit¨

•variable Serverzuordnungen: weitere Reduzierung der Kom-

munikationslast

Server sind nahe bei der Anwendung:

•erfordert, daß Aktivit¨

atenprogramme einen fest zugeordne-

ten Ort haben

•meist in Kombination mit objektorientierter Infrastruktur

verwendet

•ist h¨

aufig ¨

ahnlich wie das Verteilungsmodell ,,Server bei den

Bearbeitern“

voll verteilte WfMS:

•keine Flaschenh¨

alse im System vorhanden

•viele Migrationen (bei jedem Wechsel des Bearbeiters)

•problematisch: sehr hoher Grad an Verteilung der Informa-

tion

•h¨

aufig muß jede Aktivit¨

at einen fest zugeordneten Bearbei-

ter haben

einen Benutzer wird simuliert, daß dieser zuf¨

allig einen Ein-

trag aus seiner Arbeitsliste ausw¨

ahlt und die zugeh¨

orige Ak-

tivit¨

at ausf¨

uhrt.

Da f¨

ur das Simulationsergebnis der station¨

are Zustand

relevant ist, wurde mit dem Verfahren von Welch [Wel83,

Lan92] die Ausdehnung der Einschwingphase ermittelt, so

daß die zugeh¨

origen Werte verworfen werden konnten. Au-

ßerdem wurde die Simulation 10000 mal durchgef¨

uhrt und

die Ergebnisse gemittelt. Dadurch wurde erreicht, daß sich

die 90%-Konfidenzintervalle f¨

ur die Erwartungswerte mit

<±0,1% Abweichung um die jeweiligen Mittelwerte be-

wegen.

3.1 Simulation I

3.1.1 Modellannahmen

Zum Vergleich der Verteilungsmodelle wurde die Ausf¨

uhrung

des in Abb. 8 dargestellten (stark vereinfachten) Klinik-WF

simuliert. Wir beschreiben zun¨

achst die gew¨

ahlte Abbildung

auf die verschiedenen Verteilungsmodelle und erl¨

autern dann

die Simulationsergebnisse. Der WF beginnt damit, daß ein

Patient in die Ambulanz kommt, wo er untersucht und eine

Diagnose erstellt wird (Akt. 1-6). Dazu muß eine Blutprobe

im Labor untersucht werden (Akt. 5). Falls notwendig, wird

er auf einer von 3 m¨

oglichen Stationen aufgenommen, ver-

sorgt und behandelt (Akt. 7-14). Nach der Entlassung des

211

1Patientendaten

erfassen

MTA

2Blut

abnehm en

MTA

3Röntgenbild

erstellen

MTA

5Blutprobe

untersuchen

Laborassistent

4Röntgenbild

begutachten

Am bulanzarzt 6Diagnose

erstellen

Am bulanzarzt

7Pat.

auf Station

aufnehm en

Pflegekraft

8Patient

vorbereiten

Pflegekraft aus

O E w ie A k t. 7

9Patent

behandeln

Stationsarzt aus

O E w ie A k t. 7

10 Patient nach-

behandeln

Pflegekraft aus

O E w ie A k t. 7

11 Arztbrief

schreiben

selber Stations-

arzt w ie Akt. 9

12 Patient

überwachen

Pflegekraft aus

O E w ie A k t. 7

10%

90%

13 Patent

pflegen

Pflegekraft aus

O E w ie A k t. 7

14 Patient

entlassen

Pflegekraft aus

O E w ie A k t. 7

∅ 10 Iterationen

17 Kassenrech-

nung erstellen

Sachbearbeiter

18 Privatrech-

nung erstellen

Sachbearbeiter

16 Kosten

erfassen

Sachbearbeiter

15 restl. Patienten-

daten erfassen

Sachbearbeiter

19 Rechnung

versenden

Sachbearbeiter

20 Zahlungsein-

gang prüfen

Sachbearbeiter

21 Vorgang

a rc h iv ie re n

Sachbearbeiter

80%

20%

99%

Ambulanz

Labor

Station 1 - 3

Verwaltung

Abb. 8. F¨

ur die Simulation verwendeter WF: Aktivit¨

aten mit Bearbeiterzuordnung

Patienten wird der WF in der Verwaltung fortgesetzt und

schließlich beendet (Akt. 15-21). F¨

ur die Bearbeitung wur-

den 35 Benutzer veranschlagt (2 Ambulanz¨

arzte, 3 MTA, je

Station 2 ¨

Arzte und 6 Pflegekr¨

afte, 4 Sachbearbeiter, 2 La-

borassistenten). Jede Station, die Ambulanz, die Verwaltung

und das Labor bilden jeweils ein eigenes Teilnetz. W¨

ahrend

der Simulationsdauer von 20 Tagen werden 500 Instanzen

des Klinik-WF simuliert. Die konkreten Gr¨

oßen der Para-

meterdaten sind aus Platzgr¨

unden und zur Erh¨

ohung der

Ubersichtlichkeit nicht angegeben. Da Lastangaben im fol-

genden immer relativ zum zentralen Fall erfolgen, haben sie

auch keinen Einfluß auf das Simulationsergebnis. Eine Ver-

doppelung der Datenmenge f¨

uhrt bei allen Verteilungsmo-

dellen zu einer Verdoppelung der Last und beeinflußt damit

deren Vergleich nicht.

Die Abbildung des Klinik-WF auf die verschiedenen

Verteilungsmodelle erfolgt wie in Tabelle 2 dargestellt.

Modell 1: Zentraler Server. Der WF-Server befindet sich

im Teilnetz der Ambulanz. M¨

ogliche Alternativen hierzu

werden sp¨

ater diskutiert.

Modell 2: Server zuf¨

allig. Der Server f¨

ur eine gesamte

WF-Instanz wird zuf¨

allig ausgew¨

ahlt.

Modell 3: Keine Migration. Das optimale Teilnetz f¨

ur den

WF-Server ist das der Verwaltung.

Modell 4: Keine globale Bearbeiteraufl¨

osung. Ohne glo-

bale Bearbeiteraufl¨

osung m¨

ussen die Stationen 1-3 einen ge-

meinsamen Domain (ein Teilnetz mit nur einem WF-Server)

bilden, damit die Aktivit¨

aten 7-14 von den Benutzern aller 3

OE bearbeitet werden k¨

onnen. Deshalb verteilt sich die Ge-

samtlast bei diesem Ansatz auf insgesamt nur 4 Domains.

Modell 5: Migration und globale Bearbeiteraufl¨

osung. Bei

diesem Verteilungsmodell werden die Aktivit¨

aten 7-11 und

14 vom Server der Verwaltung kontrolliert und nicht von

dem einer Station, um Kommunikationskosten einzusparen.

Modell 6: Variable Serverzuordnung. Variable Serverzu-

ordnungen erm¨

oglichen, daß die Aktivit¨

aten 8-14 vom Ser-

ver der Station kontrolliert werden, aus der die Bearbeiter

stammen. Aktivit¨

at 7 wird vom Server der Ambulanz ge-

steuert, da vor ihrer Ausf¨

uhrung die betroffene Station noch

nicht bekannt ist.

Tabelle 2. Zuordnung der Aktivit¨

aten zu den WF-Servern bei den simulier-

ten Verteilungsmodellen

Verteilungsmodell Anzahl Zuordnung der WF-Server

Serv. Teiln. zu den Aktivit¨

aten

1. zentraler Server 1 6 Akt. 1–21: Ambulanz

2. Server zuf¨

allig 6 6 zuf¨

alliger Server f¨

ur gesamte Instanz

3. keine Migration 6 6 Akt. 1–21: Verwaltung

4. keine globale Be-

arbeiteraufl¨

osung 4 4 Akt. 1–4, 6: Ambulanz, Akt 5: La-

bor, Akt. 7–14: Station, Akt. 15–21:

Verwaltung

5. Migration und

glob. Bearbeiter-

aufl¨

osung

6 6 Akt. 1–6: Ambulanz, Akt. 12–13: Station

1, Akt. 7–11, 14–21: Verwaltung

6. variable Server-

zuordnung 6 6 Akt. 1–7: Ambulanz, Akt. 8–14: Station

des Bearbeiters von Akt. 7, Akt. 15–21:

Verwaltung

7. bei der Anwen-

dung 6 6 Akt. 2–4, 6: Ambulanz, Akt. 5: Labor,

Akt. 7–14: Station 1, Akt. 1, 15–21:

Verwaltung

8. voll verteilt 35 6 Akt. 1–21: Rechner des Bearbeiters der

Aktivit¨

Modell 7: Bei der Anwendung. F¨

ur jede Aktivit¨

at muß

festgelegt werden, wo die zugeh¨

orige Anwendung angesie-

delt ist. Dabei wurde – wann immer m¨

oglich – angenom-

men, daß die Anwendung im Teilnetz der zugeh¨

origen Be-

arbeiter liegt. Andernfalls ergibt sich eine wesentlich h¨

ohere

Belastung f¨

ur die Teilnetze. Allerdings ist diese Annahme

nicht f¨

ur alle Aktivit¨

aten m¨

oglich. Die Aktivit¨

aten 1 und 15

(Patientendaten erfassen) verwenden dieselbe Anwendung,

werden aber in unterschiedlichen OE bearbeitet. Aktivit¨

at 4

wurde (entsprechend ihrer Bearbeiter) dem Labor zugeord-

net. Um unn¨

otige Migrationen zu vermeiden, wurde ange-

nommen, daß die Anwendungen der Aktivit¨

aten 7-14 alle

auf dem Server derselben Station installiert sind.

Modell 8: Voll verteilt. Da es keine expliziten Server gibt,

sind die in Tabelle 2 angegebenen 35 Server die Rechner

der 35 Benutzer, die die WF-Steuerung ¨

ubernehmen.

Bei der Auswahl des Prozesses f¨

ur die Simulation wurde

darauf geachtet, daß alle f¨

ur die Verteilungsmodelle rele-

vanten Aspekte ber¨

ucksichtigt sind und eine ausgewogene

Mischung erreicht wird. W¨

urden bestimmte Aspekte feh-

len (z.B. die M¨

oglichkeit zur Migration), so w¨

urden ver-

schiedene Verteilungsmodelle zusammenfallen. Wenn hinge-

212

gen bestimmte Aspekte dominieren w¨

urden (z.B. st¨

andiger

Wechsel der OE), so w¨

aren die Ergebnisse nicht sehr aussa-

gekr¨

aftig. Deshalb wurde ein WF gew¨

ahlt, dessen Bearbei-

ter in verschiedenen OE angesiedelt sind (Ambulanz, Labor,

Stationen, Verwaltung). Außerdem gibt es Aktivit¨

aten (7–

14), die je nach Instanz in unterschiedlichen OE (Station

1-3) bearbeitet werden. Schließlich enth¨

alt der Prozeß Ver-

zweigungen, Parallelit¨

at und Schleifen, und die Belastung

der Bearbeiter ist nur so groß, daß ihre Arbeitslisten nicht

,,¨

uberlaufen“.

3.1.2 Ergebnis der Simulation I

F¨

ur jedes Verteilungsmodell werden in Abb. 9 die Gesamt-

last aller WF-Server, die Last pro WF-Server und die durch-

schnittliche Belastung der Teilnetze angegeben. F¨

ur die Ga-

teways wird nicht die Belastung pro Gateway, sondern die

insgesamt umgesetzte Last angegeben, weil letztere der ggf.

uber ein WAN zu kommunizierenden Datenmenge (und da-

mit den entstehenden Kosten) entspricht. Da absolute Last-

angaben (in Bytes/sec) wenig aussagekr¨

aftig sind, wird f¨

die Lastangaben die Last des zentralen Falls als Vergleichs-

wert (100) verwendet und die anderen Ergebnisse werden re-

lativ zu diesem Wert angegeben. Ein Wert von 100 bedeutet

dabei ,,dieselbe Last wie im zentralen Fall“ und nicht etwa

,,100% Auslastung der Komponente“. Es soll die bei den

verschiedenen Verteilungsmodellen entstehende Last vergli-

chen und nicht die ¨

Uberlastung einer konkreten Komponente

gepr¨

uft werden. Aus diesem Grund betrachten wir Lastsum-

men und -mittelwerte. In verteilten WfMS sind alle WF-

Server, Teilnetze und Gateways ,,logisch“ gleichartig, und

es werden stets verschiedene WF-Typen gleichzeitig aus-

gef¨

uhrt. Deshalb gibt es keinen Grund, warum zwischen

den Komponenten signifikante Ungleichbelastungen auftre-

ten sollten. Eine Ausnahme davon bilden zentrale WfMS,

weil es bei diesen genau ein Teilnetz mit einem WF-Server

gibt. Da dieses besonders stark belastet ist, wird es im fol-

genden gesondert betrachtet.

Bei den Verteilungsmodellen ohne Migration (2. und 3.)

ist die Servergesamtlast identisch mit dem zentralen Fall,

ansonsten ist sie h¨

oher. Dabei f¨

allt auf, daß sie bei einem voll

verteilten WfMS (8.) extrem hoch ist. Die Last pro Server

ist bei den Ans¨

atzen2-8viel kleiner als f¨

ur den zentralen

Server. Die durchschnittliche Teilnetzlast ist meist ¨

ahnlich

zum zentralen Fall, nur durch variable Serverzuordnungen

(6.) wird sie deutlich reduziert. Die Belastung der Gateways

ist bei Ans¨

atzen mit der M¨

oglichkeit zur Migration (4.-8.)

generell niedriger.

3.1.3 Diskussion der Ergebnisse der Simulation I

Modell 1: Zentraler Server. Die durchschnittliche Teilnetz-

last h¨

angt davon ab, in welchem Teilnetz der WF-Server an-

gesiedelt ist. Konkret ergibt sich beim Teilnetz der Ambulanz

die Last 100, bei den Stationen 101,1, bei der Verwaltung

98,6 und beim Labor 111,2. Es wurde also mit der Ambulanz

ein ,,recht guter Fall“ ausgew¨

ahlt (da es im zentralen Fall

nur einen WF-Server im System gibt, kann dessen Lage nicht

f¨

ur einzelne WF-Typen optimiert werden). Die Last im Teil-

netz des WF-Servers ist unabh¨

angig von dieser Wahl stets

334,6. Diese hohe Last f¨

uhrt schnell zur ¨

Uberlastung dieses

Teilnetzes. Die Belastung des WF-Servers ist unabh¨

angig

davon, in welchem Teilnetz er angesiedelt ist. Da es nur

einen Server im System gibt, ist die Gesamtlast der Server

identisch mit der Last pro Server. Diese Gesamtlast kann

von anderen Verteilungsmodellen nicht unterboten werden,

da im zentralen Fall keine Kommunikation zur Synchroni-

sation (z.B. Migrationen) notwendig ist. Die Gateway-Last

wird bei diesem Verteilungsmodell alleine von den 5 Gate-

ways umgesetzt, die das Teilnetz des WF-Servers mit denen

von Bearbeitern verbinden. Um die Belastung der Teilnetze

mit jener der Gateways vergeichen zu k¨

onnen, sei noch an-

gemerkt, daß die von den Gateways umgesetzte Datenmenge

44,3% der in den Teilnetzen insgesamt kommunizierten Da-

tenmenge entspricht.

Modell 2: Server zuf¨

allig. Hier ist ebenfalls keine Syn-

chronisation zwischen den WF-Servern notwendig, da die

Instanzen unabh¨

angig voneinander ausgef¨

uhrt werden und

eine Instanz komplett von einem Server kontrolliert wird.

Deshalb erreicht die Gesamtlast den optimalen Wert 100.

Diese Last verteilt sich gleichm¨

aßig auf die 6 WF-Server.

Wegen der zuf¨

alligen Wahl des Servers findet keine Opti-

mierung seines Ortes statt, weswegen sich f¨

ur die Netz- und

Gatewaylast sogar ein schlechterer Wert als im zentralen Fall

ergibt.

Modell 3: Keine Migration. Wird der Server bei den Be-

arbeitern plaziert und sind keine Migrationen m¨

oglich, so

erreicht die Serverlast den minimalen Wert 100. Da f¨

verschiedene WF-Typen unterschiedliche Server verwendet

werden k¨

onnen, verteilt sich diese Last auf die 6 Server. In

der Simulation f¨

allt die gesamte Last nat¨

urlich f¨

ur den Ser-

ver der Verwaltung an, da nur ein WF-Typ simuliert wird.

Trotz der niedrigen Gesamtlast ist das Ergebnis f¨

ur die Netz-

last nicht besonders gut, da der Ort des WF-Servers nur f¨

die gesamte WF-Instanz und nicht f¨

ur einzelne Aktivit¨

aten

optimiert werden kann. Deshalb liegt der Server f¨

ur die Ak-

tivit¨

aten 1-14 im falschen Teilnetz.

Modell 4: Keine globale Bearbeiteraufl¨

osung. Weil zum

Teilnetz der Bearbeiter jeder Aktivit¨

at migriert werden muß,

entstehen nicht rentable Migrationen (z.B. wegen Aktivit¨

5 ins Labor). Deshalb resultiert eine recht hohe Gesamtlast.

Da sich diese auf nur 4 Server verteilt, ergibt sich bei diesem

Ansatz die h¨

ochste Last pro Server. Aus denselben Gr¨

unden

entsteht auch eine hohe Last pro Teilnetz. Prinzipiell w¨

are

zwar vorstellbar, f¨

ur den ,,zusammengesetzten Domain“ der

Stationen 3 Teilnetze zu verwenden, es entst¨

unde aber keine

Verbesserung f¨

ur das Teilnetz des Servers. Dieses Teilnetz

w¨

urde mit der gesamten Kommunikation des Domains be-

lastet, da der WF-Server an jeder Kommunikation des Do-

mains beteiligt ist. Der Grund daf¨

ur ist, daß die Clients der

3 Teilnetze ausschließlich mit diesem Server kommunizie-

ren (wegen der lokalen Bearbeiteraufl¨

osung), und daß der

Server die gesamte Kommunikation mit anderen Teilnetzen

(Migrationen) abwickelt. Die Gesamtlast der Gateways ist

bei diesem Ansatz besonders niedrig, da die 3 Stationen ein

gemeinsames Teilnetz verwenden, so daß zwischen ihnen

keine Kommunikation ¨

uber ein Gateway stattfindet. Diese

213

Abb. 9. Ergebnis der Simulation I

Last wird aber von nur 6 – und nicht wie bei den anderen

Verteilungsmodellen 15 – Gateways umgesetzt.

Modell 5: Migration und globale Bearbeiteraufl¨

osung. Die

erzeugte Gesamtlast ist kleiner als beim letzten Ansatz, da

auf nicht rentable Migrationen verzichtet werden kann. Dies

sind die Migration zur Aktivit¨

at 5 und die zu einer Station

wegen den Aktivit¨

aten 7-11 und 14. Daß letztgenannte Ak-

tivit¨

aten der Verwaltung zugeordnet werden, spart f¨

ur einen

Großteil der Instanzdaten eine zus¨

atzliche Migration. F¨

ur die

(mehrfach ausgef¨

uhrten) Aktivit¨

aten 12 und 13 ist es hinge-

gen rentabel, sie vom Server einer Station kontrollieren zu

lassen, da dann in 1/3 der F¨

alle die Bearbeitung auf die-

ses Teilnetz beschr¨

ankt ist. Die Migrationskosten f¨

ur den

entsprechenden Teil der Instanzdaten sind niedriger, als die

durch die st¨

andige Verwendung des falschen Servers entste-

henden Kosten. Durch die Migrationen ist die Gesamtlast

der Server nat¨

urlich gr¨

oßer als bei den Ans¨

atzen 1, 2 und 3.

Daraus ergibt sich eine h¨

ohere Last pro Server als bei verteil-

ten Modellen ohne Migration. Sie ist aber deutlich niedriger

als beim vorherigen Ansatz. Die Netzlast wird durch diesen

Ansatz reduziert; die Last pro Teilnetz ist niedriger als bei

den bisher beschriebenen Verteilungsmodellen.

Modell 6: Variable Serverzuordnungen. Weil alle Instanz-

daten zus¨

atzlich zum Server der entsprechenden Station

migrieren m¨

ussen (Aktivit¨

at 8-14), ist die Gesamtlast und

die Last pro Server gr¨

oßer als bei statischer Serverzuord-

nung. Da keine nicht rentablen Migrationen ausgef¨

uhrt wer-

den, sind diese Werte aber immer noch besser als bei den

Ans¨

atzen 4 und 7. Durch die variable Serverzuordnung er-

gibt sich das beste Ergebnis f¨

ur die Belastung der Teilnetze.

Das Ergebnis bei statischer Serverzuordnung (5.) ist 18%

schlechter, alle anderen Ans¨

atze erzeugen mindestens 24%

mehr Last. Dies zeigt, daß variable Serverzuordnungen und

das Ermitteln der optimalen Verteilung ad¨

aquate Mittel sind,

um die Netzlast zu reduzieren.

Modell 7: Bei der Anwendung. Die unrentablen Migratio-

nen (z.B. nach Aktivit¨

at 1) f¨

uhren – verglichen mit den ande-

ren Ans¨

atzen, bei denen die Server geeignet gew¨

ahlt werden

– zu der h¨

ochsten Gesamtlast. Der Wert f¨

ur die Netzlast ist

nicht ganz so schlecht, da f¨

ur die meisten Aktivit¨

aten der op-

timale Server verwendet wird. Allerdings wirken sich auch

hier die hohen Migrationskosten negativ aus.

Modell 8: Voll verteilt. Da es keine (expliziten) Server

gibt, ist die in Abb. 9 f¨

ur die Server angegebene Last die Ge-

samtlast aller Arbeitsstationen der Benutzer (,,Mini-Server“).

Dieser Wert ist viel gr¨

oßer, als bei den bisher diskutierten

Verteilungsmodellen, da die komplette WF-Instanz nach je-

der Aktivit¨

at migriert (außer sie wird vom selben Benutzer

wie ihr Vorg¨

anger bearbeitet). Diese Gesamtlast verteilt sich

auf die Arbeitsstationen der 35 Benutzer. Die Last pro Rech-

ner ist kleiner als bei den Ans¨

atzen mit Servern. Da aber

die Arbeitsplatzrechner der Benutzer und nicht leistungs-

starke Server damit belastet werden, ist der Wert vergleichs-

weise hoch. Die Belastung der Gateways ist ziemlich nied-

rig, da ein WF stets in das Teilnetz der Station migriert

wird (Aktivit¨

at 7-14), zu der die entsprechenden Bearbei-

ter geh¨

oren (vgl. variable Serverzuordnungen). Migrationen

zwischen Bearbeitern derselben OE finden lokal in einem

Teilnetz statt, was die Gateways nicht belastet, aber zu der

h¨

ochsten Belastung der Teilnetze f¨

uhrt.

3.2 Simulation II

3.2.1 Modellannahmen

F¨

ur die Simulation II wurde ein Prozeß gew¨

ahlt, wie er

f¨

ur viele Umgebungen typisch ist. W¨

ahrend in der Simu-

lation I kaum Abh¨

angigkeiten zwischen den Bearbeitern der

einzelnen Aktivit¨

aten unterstellt werden, wird nun der in

der Praxis h¨

aufig auftretende Fall betrachtet, daß derartige

Abh¨

angigkeiten bestehen. Es wird hier unterstellt, daß die

OE des Bearbeiters der Startaktivit¨

at die OE (Station 1-6) f¨

9 darauf folgende Aktivit¨

aten bestimmt. Jede Station verf¨

ugt

uber ein eigenes Teilnetz. Jeweils nach 3 bzw. 6 dieser Ak-

tivit¨

aten wird eine einzelne Aktivit¨

at im Labor ausgef¨

uhrt,

wegen der sich eine Migration nicht lohnt. Insgesamt ergibt

sich die folgende Aktivit¨

atenabfolge:

214

Abb. 10. Ergebnis der Simulation II

Startaktivit¨

at, 3×Station i,1×Labor, 3×Station i,1×

Labor, 3×Station i

3.2.2 Ergebnis der Simulation II

Bei dem in Abb. 10 dargestellten Simulationsergebnis wurde

die Last des zentralen Falls wieder als Vergleichswert 100

verwendet. Auff¨

allig ist die hohe Last bei Verteilungsmo-

dellen, die unrentable Migrationen erzwingen (4., 7. und 8.).

Die Kommunikationslast ist nur bei variablen Serverzuord-

nungen niedriger als im zentralen Fall.

3.2.3 Diskussion der Ergebnisse der Simulation II

Modell 1: Zentraler Server. Es wurde der (optimale) Server

von Station 1 gew¨

ahlt. Befindet sich der Server bei einer an-

deren Station, so ergibt sich dasselbe Ergebnis, beim Labor

ergibt sich eine Teilnetzlast von 109,1. Die Last im Teilnetz

des Servers betr¨

agt bei allen F¨

allen 381,8. Bei diesem Sze-

nario liegt die insgesamt von den Gateways zu bew¨

altigende

Kommunikationslast bei 45,5% der Gesamtlast der Teilnetze.

Modell 2: Server zuf¨

allig. Auch hier ergibt sich die Ge-

samtlast 100, da keine Migrationen stattfinden. Diese ver-

teilt sich gleichm¨

aßig auf die 7 WF-Server. Die Belastung

des Netzwerks ist etwas gr¨

oßer als bei 1, da in 1/7 der

F¨

alle der Server des Labors gew¨

ahlt wird. Da dieser Server

sehr ung¨

unstig ist, muß h¨

aufig ¨

uber Teilnetzgrenzen hinweg

kommuniziert werden.

Modell 3: Keine Migration. Die Gesamtlast ist identisch

mit der des zentralen Falls. Diese Last verteilt sich rechne-

risch auf die 7 WF-Server des Systems. Auch die Belastung

der Teilnetze ist so groß wie im zentralen Fall.

Modell 4: Keine globale Bearbeiteraufl¨

osung. Aus den in

Abschnitt 3.1 geschilderten Gr¨

unden m¨

ussen die Stationen

bei lokaler Bearbeiteraufl¨

osung einen gemeinsamen Domain

bilden. Die unrentablen Migrationen zum Server des Labors

f¨

uhren zu einer hohen Gesamtlast. Da sich diese auf nur 2

WF-Server bzw. 2 Teilnetze verteilt, ist auch deren Last sehr

groß.

Modell 5: Migration und globale Bearbeiteraufl¨

osung. Es

ergibt sich die gleiche Verteilung und damit dasselbe Ergeb-

nis wie bei 3., da die in Frage kommenden Migrationen zum

Labor unrentabel sind.

Modell 6: Variable Serverzuordnung. Die Startaktivit¨

wird (statisch) vom Server der Station 1 kontrolliert. Alle

weiteren Aktivit¨

aten werden vom Server der betroffenen Sta-

tion gesteuert, weil sich Migrationen ins Labor nicht lohnen.

Da – außer der auf die Startaktivit¨

at folgenden (billigen) Mi-

gration – keine Migrationen stattfinden, ist die Gesamtlast

der Server nicht meßbar gr¨

oßer als im zentralen Fall. Damit

erreicht die Last pro Server den optimalen Wert 100. Die

Kommunikationslast liegt bei 54,6. Werte unter 50 sind nicht

m¨

oglich, da 50 bedeutet, daß jede Kommunikation anstelle

von 2 Teilnetzen im zentralen Fall (Server und Client) nur

noch ein Teilnetz belastet. Wie wichtig die richtige Wahl

des Servers ist, zeigt sich auch an der von den Gateways

umgesetzten Datenmenge. Diese betr¨

agt hier nur 0,1 und ist

damit wesentlich kleiner als bei allen anderen Verteilungs-

modellen.

Modell 7: Bei der Anwendung. Die Migrationen zum Ser-

ver des Labors wirken sich negativ aus. Wie bei der Simu-

lation I wurde wieder wohlwollend angenommen, daß sich

aufeinanderfolgende Anwendungen im selben Teilnetz be-

finden, so daß zwischen den Aktivit¨

aten einer Station keine

Migrationen notwendig sind.

Modell 8: Voll verteilt. Durch die st¨

andigen Migrationen

ergibt sich eine sehr hohe Gesamtlast f¨

ur die WF-Server. Wie

bei der Simulation I schl¨

agt sich diese in der Belastung der

Teilnetze und nicht so sehr in der Belastung der Gateways

nieder.

215

4 Zusammenfassung

In diesem Beitrag wurden drei fundamentale Klassen von

Verteilungsmodellen f¨

ur WfMS identifiziert. Dies sind zum

einen Systeme mit einem zentralen Server. Da dieser einen

potentiellen Engpaß darstellt, muß bei einer hohen Benut-

zerzahl ein entsprechend leistungsstarker und damit teurer

Rechner verwendet werden. Die daf¨

ur aktuell zur Verf¨

ugung

stehende Technologie bildet eine Obergrenze f¨

ur die Lei-

stungsf¨

ahigkeit des WfMS. Weitere Klassen bilden Systeme

mit mehreren Servern und Systeme ohne Server, bei denen

die Ablaufsteuerung vollst¨

andig verteilt ist. Innerhalb die-

ser Klassen wurden noch Unterklassifikationen vorgenom-

men. Einige kommerzielle Systeme und Vorschl¨

age aus dem

Bereich der Forschung wurden bez¨

uglich dieser Klassifika-

tion eingeordnet und auf ihre Skalierbarkeit hin untersucht.

Mit Hilfe einer Simulation wurden die verschiedenen Ver-

teilungsmodelle quantitativ verglichen.

Um ein geeignetes Verteilungsmodell f¨

ur ein WfMS in

einem konkreten Anwendungsfall ausw¨

ahlen zu k¨

onnen, ist

es notwendig, die jeweilige Anwendung genau zu analysie-

ren. Ggf. sollten die verschiedenen Verteilungsmodelle dazu

durch eine Simulation dieser Anwendung verglichen wer-

den. Generell ist ein zentrales WfMS nur f¨

ur Anwendungen

geeignet, bei denen die Anzahl der Benutzer beschr¨

ankt ist.

Voll verteilte Ans¨

atze f¨

uhren wegen ihrem hohen Grad an

Verteilung der Information zu Nachteilen. Sie eignen sich

eigentlich nur, wenn fast jeder Aktivit¨

at eindeutig ein Be-

arbeiter zugeordnet ist. Haben Sequenzen von Aktivit¨

aten

denselben Bearbeiter, so ergibt sich ein ¨

ahnliches Verhalten

wie bei variablen Serverzuordnungen: der WF migriert ein-

mal zum Rechner dieses Bearbeiters (in der entsprechenden

OE) und verbleibt dort f¨

ur die Ausf¨

uhrung mehrerer Akti-

vit¨

aten. Da sich der WF sogar auf dem richtigen Rechner

(nicht nur in der richtigen OE) befindet, entf¨

allt dann sogar

die Kommunikation f¨

ur den Transfer der Parameterdaten des

Aktivit¨

atenprogramms.

F¨

ur unternehmensweite Anwendungen ist aber meist ein

Verteilungsmodell mit mehreren Servern am geeignetsten.

Bei diesem kann die Last auf eine ¨

uberschaubare und ge-

eignet gew¨

ahlte Anzahl von WF-Servern verteilt werden. Es

empfiehlt sich normalerweise nicht, den WF-Server zuf¨

allig

zu w¨

ahlen, da dann kein Vorteil aus dessen Wahl gezogen

werden kann. Den Server nahe bei der Anwendung zu pla-

zieren ist schwierig, da f¨

ur Anwendungen h¨

aufig kein Ort

vorgegeben ist. Außerdem kann diese Strategie zu schlech-

ten Antwortzeiten f¨

uhren, falls der WF-Server durch diese

Festlegung weit von den Clients entfernt liegt. Deshalb ist es

f¨

ur das Kommunikationsverhalten i.d.R. am g¨

unstigsten, den

Server nahe bei den Bearbeitern der Aktivit¨

aten zu w¨

ahlen.

Ob mittels variabler Serverzuordnungen weitere Verbesse-

rungen erreicht werden k¨

onnen, h¨

angt von der betrachte-

ten Anwendung ab. Dies ist immer dann der Fall, wenn

die Bearbeiter der Aktivit¨

aten von den Bearbeitern anderer

Aktivit¨

aten abh¨

angen. Durch eine Einschr¨

ankung der Funk-

tionalit¨

at eines WfMS ist ebenfalls eine Verringerung der

Kommunikationskosten m¨

oglich. Werden z.B. in der zu rea-

lisierenden Anwendung die Prozesse fast komplett innerhalb

nur einer OE ausgef¨

uhrt, so kann auf Migrationen verzichtet

werden. Geh¨

oren alle Bearbeiter einer Aktivit¨

at jeweils zur

selben OE, so ist keine globale Bearbeiteraufl¨

osung notwen-

dig.Eine geeignete Verteilung eines WfMS erh¨

oht dessen

Skalierbarkeit und Verf¨

ugbarkeit. Aber auch f¨

ur andere An-

forderungen an ein WfMS ist dessen Verteilung eine wich-

tige Voraussetzung:

–Eine OE wird durch einen eigenen WF-Server vom Re-

chenzentrum unabh¨

angiger und kann deshalb flexibler

agieren.

–Bei einem weltweit verteilten Unternehmen wird der Ein-

satz eines WfMS durch die Verwendung mehrerer WF-

Server ¨

uberhaupt erst erm¨

oglicht.

–Ein WfMS und damit die zugeh¨

orige Organisation kann

durch das Hinzuf¨

ugen von Servern dynamisch wachsen.

–Durch die Integration von Kunden in ein WfMS kann

eine bessere Kundenorientierung erreicht werden.

Es bleibt noch zu bemerken, daß es noch ein großes

Potential f¨

ur die Entwicklung von Architekturen f¨

ur un-

ternehmensweite WfMS gibt. Dabei ist aber zu beachten,

daß die Architektur auch Einfluß auf die Funktionalit¨

at ei-

nes Systems haben kann. F¨

ur die Leistungsf¨

ahigkeit ist es

sicher von Vorteil, die Prozeßbeschreibungen zu zerteilen

und zu kompilieren, so daß f¨

ur jeden Knoten ein eigener

Scheduler entsteht (vgl. METEOR2[MSKW96]). Allerdings

macht dies dynamische Modifikationen der Ablaufbeschrei-

bung [RD98, RBD99] nahezu unm¨

oglich. Diese setzen fak-

tisch eine interpretierende Ausf¨

uhrung des Prozeßgraphen

voraus. Um beispielsweise feststellen zu k¨

onnen, ob irgend-

welche Eingabeparameter durch die Modifikation einer WF-

Instanz (z.B. Auslassen einer Aktivit¨

at) nicht mehr versorgt

sind, muß zudem der gesamte Prozeßgraph vorliegen oder

mit vertretbarem Aufwand konstruierbar sein. Aber auch an-

dere Aspekte, die in heutigen Systemen ebenfalls noch nicht

realisiert sind, stellen gewisse Anforderungen an die Archi-

tektur. Beispiele hierf¨

ur sind das Zeitmanagement, die Ver-

wendung von Backup-Servern oder die Integration mobiler

Clients.

Danksagung. Wir danken unseren Kollegen Manfred Reichert und Cle-

mens Hensinger sowie den anonymen Gutachtern und dem Herausgeber

f¨

ur ihre hilfreichen Anregungen.

References

[AKA+94] G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. G¨

un-

th¨

or, C. Mohan. Failure Handling in Large Scale Workflow

Management Systems. Technical Report RJ9913, IBM Al-

maden Research Center, November 1994

[AMG+95] G. Alonso, C. Mohan, R. G¨

unth¨

or, D. Agrawal, A. El Ab-

badi, M. Kamath. Exotica/FMQM: A Persistent Message-

Based Architecture for Distributed Workflow Management.

In: Proceedings of the IFIP Working Conference on Informa-

tion Systems for Decentralized Organisations, Trondheim,

August 1995

[BMR96] D. Barbar´

a, S. Mehrotra, M. Rusinkiewicz. INCAs: Ma-

naging Dynamic Workflows in Distributed Environments.

Journal of Database Management, Special Issue on Multi-

databases, 7(1):5–15 (1996)

[BD97] T. Bauer, P. Dadam. A Distributed Execution Environment

for Large-Scale Workflow Management Systems with Sub-

nets and Server Migration. In: Proc. Second IFCIS Confe-

216

rence on Cooperative Information Systems, S. 99–108, Kia-

wah Island, SC, Juni 1997

[BD98a] T. Bauer, P. Dadam. Architekturen f¨

ur skalierbare Work-

flow-Management-Systeme – Klassifikation und Analyse.

Ulmer Informatik-Berichte 98-02, Universit¨

at Ulm, Fakult¨

f¨

ur Informatik, Januar 1998

[BD98b] T. Bauer, P. Dadam. Variable Migration von Workflows

in ADEPT. Ulmer Informatik-Berichte 98-09, Universit¨

Ulm, Fakult¨

at f¨

ur Informatik, September 1998

[BD99] T. Bauer, P. Dadam. Efficient Distributed Control of

Enterprise-Wide and Cross-Enterprise Workflows. In: Pro-

ceedings Workshop Enterprise-wide and Cross-enterprise

Workflow Management: Concepts, Systems, Applications,

29. Jahrestagung der GI (Informatik ’99), S. 25–32, Pader-

born, Oktober 1999

[CGP+96] F. Casati, P. Grefen, B. Pernici, G. Pozzi, G. S´

anchez.

WIDE: Workflow Model and Architecture. CTIT Technical

Report 96-19, University of Twente, 1996

[CGS97] S. Ceri, P. Grefen, G. S´

anchez. WIDE – A Distributed

Architecture for Workflow Management. In: 7th Interna-

tional Workshop on Research Issues in Data Engineering,

Birmingham, April 1997

[DKM+97] S. Das, K. Kochut, J. Miller, A. Sheth, D. Worah.

ORBWork: A Reliable Distributed CORBA-based Work-

flow Enactment System for METEOR2. Technical Re-

port #UGA-CS-TR-97-001, Department of Computer Sci-

ence, University of Georgia, Februar 1997

[DHL91] U. Dayal, M. Hsu, R. Ladin. A Transactional Model for

Long-Running Activities. In: Proceedings of the 17th Inter-

national Conference on Very Large Data Bases, S. 113–122,

Barcelona, September 1991

[EG96] J. Eder, H. Groiss. Ein Workflow-Managementsystem auf

der Basis aktiver Datenbanken. In J. Becker, G. Vossen, ed.,

Gesch¨

aftsprozeßmodellierung und Workflow-Management.

San Francisco, CA: International Thomson Publishing, 1996

[Elm92] A.K. Elmagarmid. Database Transaction Models for Ad-

vanced Applications. Los Altos, CA: Morgan Kaufmann,

1992

[GHS95] D. Georgakopoulos, M. Hornick, A. Sheth. An Overview of

Workflow Management: From Process Modeling to Work-

flow Automation Infrastructure. Distributed and Parallel

Databases 3(2):119–152 (1995)

[HS96] P. Heinl, H. Schuster. Towards a Highly Scaleable Archite-

cture for Workflow Management Systems. In: Proceedings

of the 7th International Workshop on Database and Expert

Systems Applications, DEXA’96, S. 439–444, Zurich, Sep-

tember 1996

[IBM96] IBM. FlowMark – Modeling Workflow, Version 2 Release

2, Document Number: SH19-8241-01, 2. edition, Februar

1996

[Jab97] S. Jablonski. Architektur von Workflow-Mangement-Sys-

temen. Informatik Forsch. Entw., Themenheft Workflow-

Management, 12(2):72–81 (1997)

[KAGM96] M. Kamath, G. Alonso, R. G¨

unth¨

or, C. Mohan. Providing

High Availability in Very Large Workflow Management Sy-

stems. In: Proceedings of the 5th International Conference

on Extending Database Technology, S. 427–442, Avignon,

M¨

arz 1996

[Kar94] B. Karbe. Flexible Vorgangssteuerung mit ProMInanD. In

U. Hasenkamp, S. Kirn, M. Syring, editor, CSCW – Com-

puter Supported Cooperative Work, S. 117–133. Reading,

MA: Addison-Wesley 1994

[Lan92] H. Langend¨

orfer. Leistungsanalyse von Rechensystemen:

Messen, Modellieren, Simulation. M¨

unchen: Carl Hanser

1992

[Ley97] F. Leymann. Transaktionsunterst¨

utzung f¨

ur Workflows. In-

formatik Forsch. Entw., Themenheft Workflow-Management

12(2):82–90 (1997)

[MSKW96] J. A. Miller, A. P. Sheth, K. J. Kochut, X. Wang. CORBA-

Based Run-Time Architectures for Workflow Management

Systems. J. Database Management, Special Issue on Multi-

databases 7(1):16–27 (1996)

[MWW+98] P. Muth, D. Wodtke, J. Weißenfels, A. Kotz-Dittrich,

G. Weikum. From Centralized Workflow Specification to

Distributed Workflow Execution. J. Intell. Inform. Syst.,

Special Issue on Workflow Management Systems 10(2):159–

184 (1998)

[OMG95] OMG. Object Management Architecture Guide. New York:

Wiley 1995

[RBD99] M. Reichert, T. Bauer, P. Dadam. Enterprise-Wide and

Cross-Enterprise Workflow-Management: Challenges and

Research Issues for Adaptive Workflows. In: Proceedings

Workshop Enterprise-wide and Cross-enterprise Workflow

Management: Concepts, Systems, Applications, 29. Jahres-

tagung der GI (Informatik ’99), S. 56–64, Paderborn, Okto-

ber 1999

[RD98] M. Reichert, P. Dadam. ADEPTflex – Supporting Dynamic

Changes of Workflows Without Losing Control. J. Intell. In-

form. Syst., Special Issue on Workflow Management Systems

10(2):93–129 (1998)

[Sch93] A. Schill. DCE – Das OSF Distributed Environment,

Einf¨

uhrung und Grundlagen. Berlin Heidelberg New York:

Springer-Verlag 1993

[SM96] A. Schill, C. Mittasch. Workflow Management Systems on

Top of OSF DCE and OMG CORBA. Distrib. Syst. Eng.

3(4):250–262 (1996)

[SNS99] H. Schuster, J. Neeb, R. Schamburger. A Configuration

Management Approach for Large Workflow Management

Systems. In: Proceedings of the International Joint Con-

ference on Work Activities Coordination and Collaboration,

San Francisco, Februar 1999

[SK97] A. Sheth, K. J. Kochut. Workflow Applications to Research

Agenda: Scalable and Dynamic Work Coordination and Col-

laboration Systems. In: Proceedings of the NATO Advanced

Study Institute on Workflow Management Systems and Inte-

roperability, S. 12–21, Istanbul, August 1997

[Sie95] Siemens Nixdorf. WorkParty – Benutzerhandbuch, Version

2.0, August 1995

[UNI92] UNIX System Laboratories. TUXEDO System Release 4.1

– Product Overview and Master Index. Englewood Cliffs,

NJ: Prentice Hall 1992

[WWK+97] G. Weikum, D. Wodtke, A. Kotz-Dittrich, P. Muth, J. Wei-

ßenfels. Spezifikation, Verifikation und verteilte Ausf¨

uhrung

von Workflows in MENTOR. Informatik Forsch. Entw.,

Themenheft Workflow-Management 12(2):61–71 (1997)

[WWWK96a] J. Weißenfels, D. Wodtke, G. Weikum, A. Kotz-Dittrich.

The Mentor Architecture for Enterprise-wide Workflow Ma-

nagement. In: Proceedings of the NSF Workshop on Work-

flow and Process Automation in Information Systems,S.69–

73, Athens, Mai 1996

[Wel83] P.D. Welch. The Statistical Analysis of Simulation Results.

In S.S. Lavenberg, editor, Computer Performance Modeling

Handbook, S. 267–329. London: Academic Press 1983

[WHKS98] M. Weske, J. H¨

undling, D. Kuropka, H. Schuschel. Objekt-

orientierter Entwurf eines flexiblen Workflow-Management-

Systems. Informatik Forsch. Entw. 13(4):179–195 (1998)

[WWWK96b] D. Wodtke, J. Weißenfels, G. Weikum, A. Kotz-Dittrich.

The Mentor Project: Steps Towards Enterprise-Wide Work-

flow Management. In: Proceedings of the 12th IEEE In-

ternational Conference on Data Engineering, S. 556–565,

New Orleans, LA, M¨

arz 1996

217

Thomas Bauer studierte Informatik

in Ulm. Seit seinem Diplom 1995 ist er

wissenschaftlicher Mitarbeiter der Uni-

versit¨

at Ulm, Abteilung Datenbanken

und Informationssysteme. Seine Interes-

sen liegen in den Bereichen Workflow-

Management und Skalierbarkeit.

Peter Dadam ist seit 1990 Professor

f¨

ur Informatik an der Universit¨

at Ulm

und Leiter der Abteilung Datenbanken

und Informationssysteme. Davor war er

Leiter der Abteilung Advanced Infor-

mation Management am Wissenschaft-

lichen Zentrum der IBM in Heidelberg.

Seine aktuellen Arbeitsgebiete sind: Ver-

teilte, kooperative Informationssysteme,

Workflow-Management, Datenbanktech-

nologie und deren Anwendungen in an-

spruchsvollen medizinischen und tech-

nisch/wissenschaftlichen Anwendungs-

gebieten.