Konzeption und Umsetzung eines Workflow Management Systems zur Entwicklung und Qualitätssicherung von Erkennungssystemen [original]

Universit¨

at Ulm

Fakult¨

at f¨

ur Ingenieurwissenschaften und Informatik

Institut f¨

ur Datenbanken und Informationssysteme

Konzeption und Umsetzung eines Workflow Management Systems zur

Entwicklung und Qualit¨

atssicherung von Erkennungssystemen

Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker

Diplomand: Johann Specht

Betreuer: Prof. Dr. Peter Dadam

Zweitkorrektor: Dr. Stefanie Rinderle-Ma

Abgabedatum: 11. Mai 2007

Danksagung

Ich m¨

ochte mich bei allen bedanken, die mich beim Erstellen meiner Diplomarbeit

unterst¨

utzt haben. Vor allem bei meinen Betreuern Matthias Oberl¨

ander und

Prof. Dr. Peter Dadam. Aber auch bei Tilo Schwarz f¨

ur seine hilfreichen Tipps

und bei Ulrich Kreher f¨

ur seine Unterst¨

utzung im Umgang mit ADEPT. Und ich

will mich bei meiner Schwester Tamara Specht daf¨

ur bedanken, dass sie fleißig

Rechtschreibfehler in dieser Arbeit korrigiert hat.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation............................... 1

1.2 AufbauderArbeit .......................... 2

1.3 Software................................ 2

2 Aufgabenstellung 3

2.1 Daten ................................. 4

2.1.1 Bild-Sequenzen . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 Label-Dokumente . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Arbeitsabl¨

aufe............................. 7

2.2.1 Bild-Sequenzen . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Markieren........................... 8

2.2.3 Testl¨

aufe............................ 10

2.3 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Zugriffsrechte . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Web-Interface . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Programmierschnittstelle . . . . . . . . . . . . . . . . . . . 13

2.4.3 Sonstiges............................ 13

3 Analyse 14

3.1 Daten ................................. 14

3.1.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2 Dateisysteme . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3 Datenbankmanagementsysteme . . . . . . . . . . . . . . . 16

3.1.4 Konkrete Daten . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.5 Verwaltungsdaten . . . . . . . . . . . . . . . . . . . . . . . 17

iii

iv INHALTSVERZEICHNIS

3.2 Prozesse ................................ 18

3.2.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2 Datenbankmanagementsystem . . . . . . . . . . . . . . . . 18

3.2.3 Workflow Management System . . . . . . . . . . . . . . . 19

3.3 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1 L¨

osungen ........................... 20

3.4 Sicherheit ............................... 21

3.4.1 Daten ............................. 21

3.4.2 API, Web-Interface . . . . . . . . . . . . . . . . . . . . . . 21

4 Technische Umsetzung 23

4.1 Architektur .............................. 23

4.2 Kommunikation............................ 24

4.2.1 UNIX Message Queues . . . . . . . . . . . . . . . . . . . . 26

4.2.2 XML-RPC........................... 31

4.2.3 Json .............................. 33

4.2.4 SSH .............................. 33

4.3 Web-Server .............................. 34

4.3.1 Apache HTTP-Server . . . . . . . . . . . . . . . . . . . . . 34

4.3.2 mod python.......................... 35

4.3.3 Integration .......................... 36

4.3.4 Session Management . . . . . . . . . . . . . . . . . . . . . 36

4.3.5 Python Server Pages . . . . . . . . . . . . . . . . . . . . . 36

4.4 DBMS-Server ............................. 37

4.4.1 Performance.......................... 38

4.5 WfMS-Server ............................. 40

4.5.1 ADEPT ............................ 41

4.5.2 ADEPT als Dienst . . . . . . . . . . . . . . . . . . . . . . 42

4.6 WfMS-Clients............................. 43

4.6.1 AbstractClient . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6.2 Login-Client.......................... 44

4.6.3 Verwaltungs-Client . . . . . . . . . . . . . . . . . . . . . . 45

4.6.4 Der allgemeine Client . . . . . . . . . . . . . . . . . . . . . 46

4.7 Glue-Server .............................. 48

4.7.1 DatabaseManager . . . . . . . . . . . . . . . . . . . . . . . 49

4.7.2 UserManager ......................... 49

INHALTSVERZEICHNIS v

4.7.3 WFMSManager . . . . . . . . . . . . . . . . . . . . . . . . 50

4.7.4 OtherManager . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.7.5 TestRunManager . . . . . . . . . . . . . . . . . . . . . . . 52

4.7.6 Logging ............................ 53

4.7.7 Glue-Server als Dienst . . . . . . . . . . . . . . . . . . . . 53

4.8 Web-Interface............................. 54

4.8.1 JavaScript........................... 55

4.8.2 Gestaltung........................... 56

4.9 Python-API.............................. 62

4.9.1 API-Architektur . . . . . . . . . . . . . . . . . . . . . . . 62

4.9.2 GlueServerInterface . . . . . . . . . . . . . . . . . . . . . . 63

4.9.3 DB-API ............................ 64

4.9.4 User Management API . . . . . . . . . . . . . . . . . . . . 67

4.9.5 WFMS-API.......................... 68

4.9.6 Other-API........................... 69

5 Modellierung der Daten und Prozesse 70

5.1 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2 Zugriffsrechte ............................. 72

5.2.1 Low-level DB-API . . . . . . . . . . . . . . . . . . . . . . 72

5.2.2 High-level DB-API . . . . . . . . . . . . . . . . . . . . . . 72

5.2.3 Benutzerverwaltungs-API . . . . . . . . . . . . . . . . . . 73

5.2.4 WFMS-API.......................... 73

5.2.5 Other-API........................... 73

5.3 Datenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3.1 SQL-Relationen . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3.2 Bild-Sequenzen . . . . . . . . . . . . . . . . . . . . . . . . 76

5.3.3 Label-Dokumente, Label . . . . . . . . . . . . . . . . . . . 80

5.3.4 Label-Auftr¨

age ........................ 84

5.3.5 Erkennungssysteme . . . . . . . . . . . . . . . . . . . . . . 85

5.3.6 Testl¨

aufe............................ 87

5.4 Workflow ............................... 90

6 Diskussion 92

7 Zusammenfassung 95

vi INHALTSVERZEICHNIS

Literaturverzeichnis 102

Erkl¨

arung 108

Kapitel 1

Einleitung

1.1 Motivation

Dem Thema Sicherheit im Straßenverkehr wird von der Automobilbranche eine

immer h¨

ohere Bedeutung beigemessen. Vor allem wird viel in Forschung und

Entwicklung von Technologien investiert, die helfen sollen die Zahl der Unf¨

alle

zu reduzieren und die Straßen sicherer zu machen. Und wie die Unfallstatistiken

zeigen ([Statis]), helfen diese Investitionen tats¨

achlich, Menschenleben zu retten.

Die Informationstechnik er¨

offnet hier neue M¨

oglichkeiten. Eine davon sind die

sogenannten “Erkennungssysteme”, die mit Hilfe von Kameras und intelligenter

Software den Fahrzeugen die F¨

ahigkeit zu “sehen” vermitteln. Damit kann ein

Fahrzeug einen Fußg¨

anger auf der Fahrbahn erkennen, oder Alarm schlagen, falls

es von der Straße abkommt.

An solchen Systemen wird bei DaimlerChrysler ([Daimler]) intensiv geforscht.

Dabei werden große Datenmengen erzeugt und verarbeitet: Bisher wurden et-

wa 1500 Bild-Sequenzen mit jeweils etwa 1200 Einzelaufnahmen aufgenommen,

dazu kommen etwa 1600 Label-Dokumente, welche Markierungen (Label) f¨

ur un-

terschiedliche Objekte enthalten (etwa 930000). All diese Daten m¨

ussen effizient

verwaltet und verarbeitet werden.

Von zentraler Bedeutung sind die Arbeitsabl¨

aufe oder auch der Workflow. Es

m¨

ussen immer wieder die gleichen Aufgaben erledigt werden, wobei nichts ver-

gessen werden darf und die Qualit¨

at der Ergebnisse am Ende stimmen muss. Von

2KAPITEL 1. EINLEITUNG

Fall zu Fall kann es aber auch Unterschiede geben, weshalb Flexibilit¨

at bei den

Arbeitsabl¨

aufen gefragt ist. Zu ber¨

ucksichtigen ist auch, dass es Prozesse gibt, die

ohne Interaktion mit dem Benutzer auskommen und solche, die mit dem Benut-

zer interagieren m¨

ussen. Es wird also ein System ben¨

otigt, welches automatisch

Aufgaben erledigen kann und dem Benutzer hilft seine Arbeit zu erledigen.

1.2 Aufbau der Arbeit

Im Kapitel 2 wird zuerst die Aufgabenstellung vorgestellt. Anschließend werden

im Kapitel 3 m¨

ogliche L¨

osungswege besprochen und diskutiert, allerdings ohne

auf bestimmte technische Umsetzungen einzugehen. Kapitel 4 besch¨

aftigt sich vor

allem mit der technischen Seite und stellt entsprechende L¨

osungen vor. Kapitel

5 geht auf weniger technische Fragestellungen ein.

1.3 Software

Entwickelt wurde unter SuSE Linux 9.3 ([SuSELi]) mit Python 2.4.4 [Python],

GCC 3.3.5 ([GNUGCC]), Java 1.3.1 ([Java13]), ADEPT 1 ([ADEPT]), Apache

2.2.4 ([Apache]), mod python ([modpy]), MochiKit ([MochiKit]), SCons 0.96.1

([Scons]), SWIG 1.3.21 ([SWIG]). Die Diagramme wurden mit Dia 0.96.1 ([Dia])

unter Linux erstellt.

Kapitel 2

Aufgabenstellung

Ein Erkennungssystem ist eine Software, die auf Bildern Objekte oder Menschen

erkennen kann. Es besteht aus einer ausf¨

uhrbaren Datei und einer oder mehreren

Konfigurationsdateien. Wichtig dabei ist, dass eine ¨

Anderung der ausf¨

uhrbaren

Datei oder der Konfiguration ein neues Erkennungssystem ergibt, da die ¨

Ande-

rung die Eigenschaften des Erkennungssystems beeinflusst. Die Erkennungssys-

teme, die bei DaimlerChrysler entwickelt werden, markieren erkannte Objekte,

indem sie Rechtecke um diese Objekte legen. Es k¨

onnen aber auch offene oder

geschlossene Polygone und Punkte sein.

Das System muss die M¨

oglichkeit bieten, die Erkennungssysteme zu verwalten,

also neue Erkennungssysteme zu definieren, vorhandene zu bearbeiten oder zu

l¨

oschen.

Um Erkennungssysteme zu entwickeln, braucht man vor allem folgende drei Din-

ge:

•Algorithmen und Verfahren

•Daten

•Tests

Dazu kommen einige Abl¨

aufe, die immerzu wiederholt werden m¨

ussen, wobei die

Qualit¨

at der Ergebnisse sichergestellt werden muss. In diesem Kapitel werden die

Daten, die Arbeitsabl¨

aufe und einige andere Anforderungen beschrieben.

4KAPITEL 2. AUFGABENSTELLUNG

2.1 Daten

Den mit Abstand gr¨

oßten Teil der Daten machen die Bild-Sequenzen und die

Label-Dokumente aus. Der Datenbestand hat bereits eine beachtliche Gr¨

oße er-

reicht und wird in Zukunft noch weiter wachsen. Es ist deswegen wichtig, die

Daten effizient zu verwalten und flexible und schnelle Abfragen anzubieten.

2.1.1 Bild-Sequenzen

Die Bild-Sequenzen bestehen aus Infrarot-Aufnahmen, die mit speziell ausger¨

uste-

ten Fahrzeugen aufgenommen werden. Meist besteht eine Bild-Sequenz aus meh-

reren Kan¨

alen (channel), wobei ein Kanal einer bestimmten Infrarot-Kamera ent-

spricht. Die Bild-Sequenzen werden in Verzeichnissen abgelegt, die das Aufnah-

Abbildung 2.1: Beispiel einer Infrarotaufnahme bei Nacht.

medatum als Namen haben. Jede Sequenz bekommt ihr eigenes Unterverzeichnis,

2.1. DATEN 5

welches das Aufnahmedatum und die Aufnahmezeit im Namen tr¨

agt, siehe Ab-

bildung 2.2. Auch die Kan¨

ale werden in eigenen Unterverzeichnissen gespeichert.

Abbildung 2.2: Speicherung der Bild-Sequenzen.

Im Beispiel liegen im Verzeichnis “060725” die Sequenzen, die am 25.07.2006 auf-

genommen wurden. Hier ist es nur eine einzige:

“2006y 07m 25d 20h 11m 41s 167972u.sgs”, die einen Kanal mit dem Namen

“Framegrabber/c0” enth¨

alt.

Die einzelnen Aufnahmen (Frames) werden als 16-Bit Graustufenbilder im Tiff-

Format [TIFF] im jeweiligen Kanal-Verzeichnis gespeichert.

Benutzt werden die Bild-Sequenzen f¨

ur zweierlei:

•Erkennungssysteme trainieren

•Erkennungssysteme testen

Die genauen Abl¨

aufe beim Testen der Erkennungssysteme werden weiter unten

beschrieben. Das Trainieren der Erkennungssysteme ist hier nicht weiter von Be-

deutung, nur soviel: es dient dazu, die Konfigurationen f¨

ur Erkennungssysteme

zu erstellen.

Die Sequenzen, Kan¨

ale und einzelnen Frames m¨

ussen mit Tags 1und Kommen-

taren versehen werden k¨

onnen.

Inzwischen wurden etwa 1400 Sequenzen aufgenommen, die durchschnittlich je

1200 Frames in mehreren Kan¨

alen enthalten. Ein Frame ist zwischen 30KByte

und 600KByte groß. Bei einer durchschnittlichen Frame-Gr¨

oße von 300KByte

(0.3MByte) ergibt sich eine Datenmenge von: 1400 ∗1200 ∗0.3 = 504000MByte.

1Oder auch Etikett, Marke. Dient der Auszeichnung mit zus¨

atzlichen Informationen.

6KAPITEL 2. AUFGABENSTELLUNG

2.1.2 Label-Dokumente

Ein Label-Dokument ist eine Textdatei, die eine Python-Datenstruktur enth¨

alt.

Diese Datenstruktur wiederum enth¨

alt zu jedem Frame die zugeh¨

origen Markie-

rungen (Label) von Objekten. Ein Label-Dokument bezieht sich immer auf eine

Bild-Sequenz und einen Kanal. Ein Label ist immer einem Frame zugeordnet und

ist ein geometrisches Objekt, meist ein Rechteck oder auch ein Punkt oder ein

geschlossenes/offenes Polygon. Die geometrische Form eines Labels wird als Typ

mitgespeichert, zum Beispiel “rect” f¨

ur Rechteck oder “point” f¨

ur Punkt. Jedes

Label bekommt eine Bezeichnung (track id), die sich aus dem Namen des mar-

kierten Objektes und einer fortlaufenden Nummer zusammen setzt (zum Beispiel:

“Car 1” f¨

ur ein PKW, oder “Pedestrian 3” f¨

ur einen Fußg¨

anger). Die Punkte ei-

nes Labels werden in zwei Listen gespeichert, eine f¨

ur die X-Koordinaten und

eine f¨

ur die Y-Koordinaten.

Abbildung 2.3: Label Beispiele: Rechtecke, Punkte und offene Polygone.

Neben den Labeln werden noch weitere Informationen in einem Label-Dokument

gespeichert:

2.2. ARBEITSABL ¨

AUFE 7

•Name der Bild-Sequenz und Kanal

•Name des Bearbeiters

•Erstellungsdatum

•die verwendete Konfiguration f¨

ur die Anwendung Lava, die zum Markieren

von Objekten eingesetzt wird (siehe 2.2.2)

Label-Dokumente enthalten auch Tags und Kommentare f¨

ur das Dokument selbst,

f¨

ur die Bild-Sequenz/Kanal, f¨

ur einzelne Frames und Label. Diese Tags und Kom-

mentare m¨

ussen ebenfalls gespeichert und verwaltet werden.

Es wird zwischen Soll- und Ist-Daten unterschieden. Erstere sind Label-Dokumente,

die beim manuellen Labeln (Markieren) entstanden sind. Sie werden benutzt, um

die G¨

ute eines Erkennungssystems zu pr¨

ufen. Dazu werden die Soll-Daten mit

den Ist-Daten, die von den Erkennungssystemen ausgegeben werden, verglichen.

Bis jetzt wurden ungef¨

ahr 1600 Label-Dokumente (Soll-Daten) erstellt, die zu-

sammen etwa 930000 einzelne Label enthalten. Bei gesch¨

atzten 46 Bytes/Label

in der Datenbank ergibt das 930000 ∗46 = 40,8MByte.

Es muss sicher gestellt werden, dass die Label-Daten schnell und flexibel abgefragt

werden k¨

onnen. Unter anderem m¨

ussen geometrische Anfragen m¨

oglich sein wie:

gib alle rechteckigen Label zur¨

uck, die eine Fl¨

ache von mindestens 100 Pixeln

haben.

2.2 Arbeitsabl¨

aufe

Die zweite wichtige Aufgabenstellung neben der Verwaltung der Daten, sind die

Arbeitsabl¨

aufe. Diese m¨

ussen nach M¨

oglichkeit automatisiert werden und wo es

nicht geht, muss das System den Benutzer unterst¨

utzen. Zu beachten ist dabei,

dass sich die Arbeitsabl¨

aufe durchaus ¨

andern k¨

onnen und zwar sowohl tempor¨

(also w¨

ahrend der Ausf¨

uhrung) als auch dauerhaft. Das System muss also eine

M¨

oglichkeit bieten die Arbeitsabl¨

aufe mit wenig Aufwand zu ¨

andern.

8KAPITEL 2. AUFGABENSTELLUNG

2.2.1 Bild-Sequenzen

Wie oben bereits erw¨

ahnt wurde, werden die Bild-Sequenzen mit speziell aus-

ger¨

usteten Fahrzeugen aufgenommen und auf der Festplatte des Fahrzeug-Rechners

zwischengespeichert. Danach werden die Sequenzen auf den NFS-Server der Ab-

teilung ¨

ubertragen. Wichtig dabei ist, dass die Sequenzen nach vorgegebenem

Muster abgelegt werden. In der Regel bedeutet die Aufnahme neuer Bild-Sequenzen,

dass neue Soll-Daten erstellt werden m¨

ussen (siehe Kapitel 2.2.2).

Das System muss die Bild-Sequenzen verwalten und die Benutzer beim Import

neuer Sequenzen unterst¨

utzen, indem diese automatisch an die richtige Stelle

kopiert werden.

2.2.2 Markieren

Vor den eigentlichen Arbeitsabl¨

aufen soll hier noch kurz eine Anwendung na-

mens “Lava” vorgestellt werden, die dazu benutzt wird, Soll-Daten zu erstellen

(siehe Abbildung 2.4). Lava ist in Python geschrieben und l¨

auft unter Windows

und Linux. Es kann Label-Dokumente lesen und schreiben und Bild-Sequenzen

mit 16-Bit Graustufen Bildern laden und anzeigen. Lava wird ¨

uber eine Konfi-

gurationsdatei konfiguriert und kann so auf die Label-Aufgabe angepasst werden

(indem zum Beispiel nur die ben¨

otigten Zeichenwerkzeuge angeboten werden oder

das richtige Konvertierungsverfahren von 16Bit zu 8Bit Graustufenbildern aus-

gew¨

ahlt wird).

Auf der Abbildung 2.4 sieht man ein Beispiel f¨

ur ein Label vom Typ “Rechteck”

mit der track id 2“Pedestrian 1”.

Die Aufnahme neuer Bild-Sequenzen l¨

ost normalerweise die Erstellung neuer

Soll-Daten f¨

ur diese Sequenzen aus. Dazu erstellt ein Betreuer f¨

ur jede Bild-

Sequenz/Kanal-Kombination, f¨

ur die Soll-Daten ben¨

otigt werden, ein Label-Do-

kument (Label-Auftrag, entspricht dem Label-Dokument aus Kapitel 2.1.2 aber

noch ohne Label), welches die ben¨

otigten Informationen (Sequenz, Kanal, Spei-

cherort der Sequenz und die Lava-Konfiguration) enth¨

alt. Der Name dieser Da-

tei besteht aus dem Namen der Sequenz, dem Namen des Kanals, dem Namen

2Eine, pro Objekt, eindeutige Bezeichnung einer Markierung in einem Label-Dokument.

Setzt sich aus dem Namen des markierten Objektes und einer fortlaufenden Nummer zusammen.

2.2. ARBEITSABL ¨

AUFE 9

Abbildung 2.4: Lava unter Windows.

10 KAPITEL 2. AUFGABENSTELLUNG

des Objekts, das markiert werden soll, und einer fortlaufenden Versionsnummer:

“2005y 07m 26d 21h 14m 19s 360587u IndigoCar;0.py”. Diese Datei wird dann

dem Bearbeiter (Labeler) zur Verf¨

ugung gestellt. Wobei zu beachten ist, dass es

auch externe Bearbeiter gibt (Studenten, Sch¨

uler). Zus¨

atzlich ben¨

otigt der Bear-

beiter die richtige Lava-Konfiguration.

Der Bearbeiter kann dann das Label-Dokument mit Lava ¨

offnen und bearbeiten.

Das ge¨

anderte Label-Dokument schickt der Bearbeiter entweder per EMail an

den Betreuer, oder legt es auf dem NFS-Server ab. Als n¨

achstes ¨

uberpr¨

uft der

Betreuer das Ergebnis und schickt es zur¨

uck an den Bearbeiter, falls es nicht

zufriedenstellend ist. Dabei kann er im Label-Dokument einen Kommentar mit

der Beschreibung des Problems unterbringen. Sobald das Ergebnis die Qualit¨

ats-

kontrolle passiert hat, wird es auf dem NFS-Server abgelegt und steht dann f¨

die Tests der Erkennungssysteme zur Verf¨

ugung.

Das System muss die Betreuer beim Anlegen neuer Label-Auftr¨

age unterst¨

utzen

und diese automatisch den richtigen Bearbeitern zur Verf¨

ugung stellen. Die Be-

arbeiter m¨

ussen die M¨

oglichkeit haben, die Ergebnisse an den Betreuer zu schi-

cken, wobei die Qualit¨

atskontrolle sichergestellt werden muss. Danach k¨

onnen die

Label-Dokumente als Soll-Daten abgespeichert werden.

2.2.3 Testl¨

aufe

Um zu ¨

uberpr¨

ufen wie gut ein Erkennungssystem bestimmte Objekte erkennen

kann, startet man einen Testlauf. Ein Testlauf wird definiert durch ein Erken-

nungssystem, Bild-Sequenzen und einen Rechner, auf dem das Erkennungssystem

ausgef¨

uhrt wird. Es werden einige Arbeitsplatzrechner benutzt, die unter Linux

laufen und einen Zugang ¨

uber SSH [OpenSSH] bieten. Ein Testlauf dauert meist

sehr lange, weswegen man ihn im Hintergrund mit niedriger Priorit¨

at laufen l¨

asst.

Die Dauer eines Testlaufs h¨

angt vom Erkennungssystem und der Zahl und der

Gr¨

oße der Bild-Sequenzen ab. Die Berechnungszeit pro Bild liegt zwischen Echt-

zeit und 5 Sekunden. Bei einer Bild-Sequenz mit 1200 Bildern (48 Sekunden bei

25 Bildern Pro Sekunde) und 5 Sekunden pro Bild ergiben sich 100 Minuten f¨

die Berechnung. Ablauf:

•Einen Rechner aussuchen, auf dem noch keine Berechnung l¨

auft

2.3. BENUTZERVERWALTUNG 11

•Erkennungssystem auf diesen Rechner kopieren (zum Beispiel mit scp

[OpenSSH]), die Bild-Sequenz kann direkt vom NFS-Server gelesen werden

•Auf dem Rechner direkt oder ¨

uber SSH einloggen

•Das Erkennungssystem starten

•Sobald die Berechnung abgeschlossen wurde, das Ergebnis abholen

Aus den Abweichungen der Soll- und Ist-Daten k¨

onnen Diagramme erstellt wer-

den, die die Abweichungen visualisieren.

Das System muss die Verwaltung der Testl¨

aufe unterst¨

utzen und diese auto-

matisch ausf¨

uhren. Es muss also m¨

oglich sein, einen neuen Testlauf zu definie-

ren, indem man ein Erkennungssystem, Bild-Sequenzen und Maschinen angibt.

Danach muss das System die Testl¨

aufe automatisch ausf¨

uhren. Dabei muss es

m¨

oglich sein, den Testl¨

aufen Priorit¨

aten zuzuordnen, damit zuerst h¨

oher priori-

sierte Testl¨

aufe ausgef¨

uhrt werden.

2.3 Benutzerverwaltung

Es wurden bereits zwei Typen von Benutzern erw¨

ahnt: Betreuer und Bearbeiter

(Labeler). Diese haben unterschiedliche Aufgaben und Rechte, was eine Benutzer-

verwaltung notwendig macht. Das System sollte Aufgaben an “Rollen” kn¨

upfen

und auch “F¨

ahigkeiten” kennen, die angeben, was der Benutzer kann. Folgende

Rollen sind denkbar:

•Verwalter von Sequenzen

•Verwalter von Label-Dokumenten

•Verwalter von Label-Auftr¨

agen

•Labeler 3

•Verwalter von Erkennungssystemen

•Verwalter von Testl¨

aufen

3Benutzer, die auf Infrarotaufnahmen Objekte markieren.

12 KAPITEL 2. AUFGABENSTELLUNG

M¨

ogliche F¨

ahigkeiten:

•Sequenzen importieren, l¨

oschen

•Label-Dokumente erzeugen/l¨

oschen

•Label-Dokumente modifizieren

•Erkennungssysteme anlegen, bearbeiten, l¨

oschen

•Testl¨

aufe anlegen, abbrechen, l¨

oschen

2.3.1 Zugriffsrechte

Um absichtliches oder unabsichtliches L¨

oschen oder Ver¨

andern der Daten zu ver-

hindern, muss das System den Zugriff auf die Daten kontrollieren und anhand der

Zugriffsrechte zulassen oder ablehnen. Ein Labeler darf zum Beispiel keine Bild-

Sequenzen l¨

oschen oder lesend/schreibend auf die Erkennungssysteme zugreifen.

2.4 Benutzerschnittstelle

Von großer Bedeutung ist das Benutzerinterface, da die Benutzer, insbesondere

die Labeler, damit arbeiten m¨

ussen, und die Programmierschnittstelle, mit der

auf das System zugegriffen werden kann.

2.4.1 Web-Interface

Das Benutzerinterface soll Web-basiert sein, da dies einige Vorteile mit sich

bringt:

•keine Installation auf dem Client n¨

otig

•plattformunabh¨

angig

•von ¨

uberall zugreifbar

•zentrale Administration und Pflege

2.4. BENUTZERSCHNITTSTELLE 13

Wichtig ist hier, dass das Web-Interface mit allen g¨

angigen Browsern funktioniert,

also Internet Explorer, Firefox, Opera. Auch die Sicherheit darf nicht zu kurz

kommen, das System muss also zuerst den Benutzer zum Login auffordern und

ihn danach nur auf die Seiten lassen, auf die er zugreifen darf.

Normale GUI-Anwendungen sollten nur in Ausnahmef¨

allen benutzt werden (zum

Beispiel wird Lava weiterhin zum Labeln benutzt).

2.4.2 Programmierschnittstelle

Großer Wert wird auch auf die M¨

oglichkeit gelegt, das System m¨

oglichst vollst¨

andig

und einfach ¨

uber eine Programmierschnittstelle (API - Application Programming

Interface) ansprechen zu k¨

onnen. Da Python die beforzugte Programmiersprache

ist (siehe Kapitel 2.4.3), muss mindestens eine Python-API angeboten werden.

2.4.3 Sonstiges

Das System muss unter Linux laufen. Bevorzugte Programmiersprache ist Py-

thon. Es existiert ein lokales Netzwerk mit NFS-Freigaben, die Home-Verzeichnisse

der Benutzer werden ebenfalls ¨

uber NFS gemountet.

Kapitel 3

Analyse

Nachdem die Aufgabenstellung bereits vorgestellt wurde, wird in diesem Kapitel

untersucht, welche M¨

oglichkeiten f¨

ur die L¨

osung der Aufgaben zur Verf¨

ugung

stehen und was ihre Vor- und Nachteile sind. Es wird hier allerdings nicht auf

konkrete technische L¨

osungen eingegangen (dies wird in den Kapiteln 4 und 5

gemacht), sondern allgemeine Fragen er¨

ortert, zum Beispiel: wie k¨

onnen die Daten

verwaltet werden oder wie k¨

onnen die Arbeitsabl¨

aufe (Prozesse) vom System

unterst¨

utzt werden?

Wie man im vorigen Kapitel sehen konnte, gibt es vor allem zwei große Her-

ausforderungen: Datenverwaltung und Workflow. Aus diesem Grund werden im

Kapitel 3.1 zuerst die Datenverwaltung und im Kapitel 3.2 dann die Prozess-

Abl¨

aufe diskutiert. Anschliessend werden noch die Benutzerverwaltung und das

Thema Sicherheit er¨

ortert.

3.1 Daten

Die Daten k¨

onnen in zwei große Bereiche unterteilt werden:

•Konkrete Daten

–Bild-Sequenzen

–Label-Dokumente

3.1. DATEN 15

•Verwaltungsdaten

–Benutzerdaten

–Erkennungssysteme

–Testl¨

aufe

–Label-Auftr¨

age

Die konkreten Daten werden bereits im Dateisystem abgelegt. Die Verwaltungsda-

ten existieren entweder nicht explizit (Testl¨

aufe), werden nicht zentral gespeichert

(Erkennungssysteme) oder sind nur implizit vorhanden (Benutzerdaten, UNIX-

Benutzer, Windows-Benutzer).

F¨

ur die Verwaltung der Daten gibt es im Wesentlichen zwei M¨

oglichkeiten:

•Dateisystem

•Datenbankmanagementsystem (DBMS)

3.1.1 Anforderungen

Folgende Anforderungen werden an die Datenverwaltung gestellt:

•effiziente Verwaltung großer Datenmengen

•flexible Abfragen der Daten

•geometrische Datentypen

Die Menge der Daten sollte einen m¨

oglichst geringen Einfluss auf die Abfrage-

Geschwindigkeit haben. Die Abfragen selbst k¨

onnen sehr komplex sein und sind

nicht alle im Voraus zu bestimmen. Beispiel f¨

ur eine Abfrage: Gebe alle Label

zur¨

uck, die rechteckig und rot sind, deren Fl¨

ache mindestens 100 Pixel betr¨

agt

und die f¨

ur die Bild-Sequenz “xyz” erstellt wurden.

16 KAPITEL 3. ANALYSE

3.1.2 Dateisysteme

Jedes Betriebssystem bietet f¨

ur die Verwaltung der Daten mindestens ein Datei-

system an. Solch ein Dateisystem muss universell sein, da es alle m¨

oglichen Daten

speichern k¨

onnen muss (Textdateien, Bilder, Maschinencode usw.). Diese Univer-

salit¨

at bedeutet allerdings, dass viele Daten nicht optimal in einem Dateisystem

verwaltet werden k¨

onnen. Vor allem sind die M¨

oglichkeiten f¨

ur die Suche, Si-

cherstellung der Integrit¨

at der Daten und flexible Abfragen sehr eingeschr¨

ankt.

Allerdings braucht man all das nicht immer, so dass viele Daten tats¨

achlich im

Dateisystem verbleiben k¨

onnen und damit f¨

ur alle Anwendungen ohne Umwege

verf¨

ugbar bleiben.

3.1.3 Datenbankmanagementsysteme

Wesentlich mehr M¨

oglichkeiten bieten die Datenbankmanagementsysteme (DBMS):

schnelle Suche, Sicherstellung der Integrit¨

at, sehr flexible Abfrage-M¨

oglichkeiten

usw. Ein weiterer großer Vorteil von DBMS ist die M¨

oglichkeit, einen Teil der

Anwendungslogik zentral in der Datenbank so abzulegen (Trigger, Stored Pro-

cedures, referenzielle Integrit¨

at), dass diese Logik nicht von Anwendungen oder

Benutzern “vergessen” werden kann.

Viele Datenbankmanagementsysteme k¨

onnen auch mit geometrischen Daten um-

gehen (PostgreSQL, Oracle). Damit w¨

are auch die dritte Anforderung abgedeckt

(siehe 3.1.1).

Allerdings macht es nicht bei allen Arten von Daten Sinn, diese in einer Daten-

bank zu speichern, dazu geh¨

oren vor allem bin¨

are Daten: ausf¨

uhrbare Programme,

Bilder, Videos, Musik usw. Solche Daten sind aus Sicht des DBMS einfach Da-

tenbl¨

ocke, die nicht sinnvoll abgefragt werden k¨

onnen. Daten dieser Art k¨

onnen

im Dateisystem verbleiben, wobei bestimmte Informationen (Pfad, Tags, Kom-

mentare usw.) in die Datenbank geschrieben werden k¨

onnen.

3.1.4 Konkrete Daten

Die Bild-Sequenzen bestehen einerseits aus jeder Menge bin¨

arer Daten (Tiff-

Bilder), andererseits gibt es auch weitere Informationen, die verwaltet werden

3.1. DATEN 17

m¨

ussen (Tags, Kommentare). Aus diesem Grund scheint es hier sinnvoll zu sein,

die Daten auf Dateisystem und Datenbank zu verteilen: Die Bilder selbst verblei-

ben im Dateisystem, in die Datenbank wandern Daten wie Tags, Kommentare

und Pfad (Speicherort im Dateisystem). Das erm¨

oglicht zum einen flexible Ab-

fragen nach Tags und Kommentaren, zum anderen wird die Datenbank nicht mit

Bin¨

ardaten vollgestopft.

Die Label-Dokumente enthalten keinerlei bin¨

are Daten und k¨

onnen somit voll-

st¨

andig in der Datenbank gespeichert werden. So k¨

onnen s¨

amtliche Attribute

eines Label-Dokumentes leicht abgefragt werden.

3.1.5 Verwaltungsdaten

F¨

ur die Implementierung der Benutzerverwaltung gibt es drei M¨

oglichkeiten:

•eigene Implementierung

•vorhandene nutzen (zum Beispiel UNIX-Benutzerverwaltung)

•Workflow Management System, sollte eines eingesetzt werden, bringt bereits

eigene Benutzerverwaltung mit (siehe Kapitel 4.5)

Im ersten Fall k¨

onnen die Benutzerdaten in der Datenbank gespeichert werden.

Sollte der WfMS-Server bereits eine eigene Benutzerverwaltung enthalten, dann

ist die Speicherung der Benutzerdaten seine Aufgabe, ebenso beim Einsatz der

UNIX-Benutzerverwaltung.

Die Erkennungssysteme ¨

ahneln in ihrer Beschaffenheit den Bild-Sequenzen: Es

gibt sowohl bin¨

are Daten als auch solche, die sinnvoll in einer Datenbank gespei-

chert werden k¨

onnen.

Die Testl¨

aufe wiederum enthalten keine Bin¨

ardaten und k¨

onnen vollst¨

andig in

der Datenbank verwaltet werden. Das Gleiche gilt auch f¨

ur die Label-Auftr¨

age.

18 KAPITEL 3. ANALYSE

3.2 Prozesse

Die Prozess-Abl¨

aufe k¨

onnen grob in zwei Gruppen eingeteilt werden, mit viel

Benutzerinteraktion (Labeln) und mit wenig oder gar keiner Benutzerinterak-

tion (Testl¨

aufe). Benutzerinteraktion erfordert zus¨

atzlichen Aufwand, da einige

Aktivit¨

aten eines Prozesses den Benutzer involvieren m¨

ussen.

3.2.1 Anforderungen

Bei der Umsetzung der Prozess-Abl¨

aufe muss auf Folgendes geachtet werden:

•einfache Definition und ¨

Anderung der Prozesse

•Abweichungen w¨

ahrend der Ausf¨

uhrung

Die Prozesse d¨

urfen also nicht statisch sein, sondern leicht ¨

anderbar und anpass-

bar. Damit die ¨

Anderungen schnell und mit wenig Aufwand vorgenommen werden

k¨

onnen, sollten die Prozesse nicht fest in den Code eingebaut (also implizit), son-

dern von diesem klar getrennt werden. Zus¨

atzlich sollten die Prozesse explizit

modelliert werden, zum Beispiel grafisch oder textuell. Damit w¨

are es m¨

oglich,

die Prozesse jederzeit zu ¨

andern, ohne den Code anzufassen.

Die M¨

oglichkeit, Prozesse w¨

ahrend der Ausf¨

uhrung ¨

andern zu k¨

onnen, ist erw¨

unscht,

weil es oft vorkommt, dass irgend ein Schritt ausgelassen, oder ein zus¨

atzlicher

hinzugenommen wird. Zum Beispiel k¨

onnte unter Zeitdruck die Qualit¨

atskontrol-

le beim Labeln ausgelassen, oder aber bei besonders kritischen Daten eine weitere

Person als Pr¨

ufer hinzugenommen werden.

3.2.2 Datenbankmanagementsystem

Eine M¨

oglichkeit Prozesse zu verwalten und auszuf¨

uhren besteht darin, die Prozess-

Instanzen in einer Datenbank-Tabelle zu speichern und zu verwalten. In dieser

Tabelle k¨

onnen der Status und der n¨

achste Bearbeiter verzeichnet werden. Mit

Hilfe von Triggern und Stored Procedures k¨

onnen sogar viele Aktivit¨

aten auto-

matisch ausgef¨

uhrt werden.

3.2. PROZESSE 19

Diese L¨

osung bietet sich f¨

ur das Labeln an, das in Form von Label-Auftr¨

agen

abgewickelt werden kann. Dazu legt ein Betreuer einen Label-Auftrag an und

bestimmt den Bearbeiter. Neben anderen Daten enth¨

alt ein Label-Auftrag auch

einen Status. Sobald der Bearbeiter den Label-Auftrag abruft, wird der Status

automatisch in “in Bearbeitung” ge¨

andert (Trigger). Schickt er das Ergebnis ein,

andert sich der Status in “nicht gepr¨

uft” und nach erfolgreich bestandener Qua-

lit¨

atspr¨

ufung in ”Fertig”.

Dieses Verfahren kann zwar recht einfach implementiert werden, erf¨

ullt aber die

oben genannten Anforderungen nicht: Der Ablauf ist fest in die Datenbank “ein-

gebaut” und kann nicht so einfach ge¨

andert werden.

3.2.3 Workflow Management System

Einen anderen Weg gehen die so genannten “Workflow Management Systeme”

(WfMS). Diese bestehen aus einer “Workflow Execution Engine”, welche Prozess-

Graphen ausf¨

uhrt, und bieten eventuell weitere Komponenten (wie Benutzerver-

waltung) an. Das WfMS bestimmt die Aktivit¨

aten, die als n¨

achste ausgef¨

uhrt

werden k¨

onnen (Arbeitsliste), startet externe Programme, versorgt diese mit Ein-

gabeparametern und leitet der Ausgabeparameter weiter, bestimmt die m¨

oglichen

Bearbeiter usw.

Die Prozesse werden also explizit in Prozess-Graphen modelliert und k¨

onnen so-

mit jederzeit ge¨

andert werden ohne, dass der Code angepasst werden muss. So

gesehen stellen die Prozess-Graphen die Anwendungslogik dar und die den Akti-

vit¨

aten zugeordneten Programme erledigen die eigentliche Arbeit.

Man kann sagen, dass die Workflow Management Systeme f¨

ur den Workflow

das sind, was die Datenbankmanagementsysteme f¨

ur die Datenverwaltung sind:

Statt m¨

uhsam immer wieder die gleiche Arbeit zu erledigen wird diese einmal im

WfMS-Server gemacht. Danach kann man sich auf die eigentliche Aufgabe, die

Erstellung der Prozess-Graphen, konzentrieren.

Damit w¨

are die erste Anforderung (siehe Kapitel 3.2.1) erf¨

ullt, die zweite kann

von einigen Workflow Management Systemen erf¨

ullt werden (wie MQSeriesWork-

flow [MqWork], Staffware [Staffware] und ADEPT [ADEPT]), wobei ADEPT bei

dieser Anforderung wohl den gr¨

oßten Funktionsumfang bietet.

20 KAPITEL 3. ANALYSE

3.3 Benutzerverwaltung

Es werden viele Benutzer mit dem System arbeiten und dabei verschiedene Auf-

gaben erledigen m¨

ussen, wobei diese Aufgaben auch die Zugriffsrechte und die zur

Verf¨

ugung stehenden Werkzeuge definieren. Ein Labeler sollte also keine Testl¨

aufe

verwalten d¨

urfen und das Web-Interface sollte dem Benutzer nur die f¨

ur ihn re-

levanten Seiten anzeigen.

Naheliegend erscheint eine L¨

osung, bei der jedem Benutzer Rollen und F¨

ahigkei-

ten zugewiesen werden k¨

onnen, die seine Zugriffsrechte und Werkzeuge festlegen.

Dabei werden die F¨

ahigkeiten den Rollen untergeordnet, k¨

onnen aber auch ein-

zeln zugewiesen werden. Beispiel: Rolle “Labeler” enth¨

alt die F¨

ahigkeit “Labeln”.

Ein Benutzer, dem diese Rolle zugewiesen wurde, kann f¨

ur ihn bestimmte Label-

Auftr¨

age exportieren und sp¨

ater das Ergebnis importieren.

Neben den Rollen/F¨

ahigkeiten sollen f¨

ur einen Benutzer noch andere Daten an-

gegeben werden k¨

onnen: Passwort, E-Mail, Betreuer.

3.3.1 L¨

osungen

Im Kapitel 3.1.5 wurden bereits drei M¨

oglichkeiten erw¨

ahnt, um die Benutzer-

verwaltung zu implementieren. Die einfachste ist die Nutzung einer vom WfMS-

Server angebotenen L¨

osung (falls dieser eine solche mitbringt).

Die schwierigste L¨

osung d¨

urfte eine eigene Implementierung sein. F¨

ur die Speiche-

rung der Benutzerdaten kann auf die Datenbank zur¨

uckgegriffen werden, wobei

der Zugriff auf die entsprechenden Relationen nur dem System gestattet werden

darf. Die Passw¨

orter sollten nicht direkt, sondern als Hash gespeichert werden,

damit sie bei einem Einbruch nicht einfach ausgelesen werden k¨

onnen.

Noch eine denkbare L¨

osung ist die Nutzung der UNIX-Benutzerverwaltung. Diese

kennt allerdings nur Benutzer und Gruppen, also keine Rollen und F¨

ahigkeiten

und ist somit weniger interessant.

Bei den ersten beiden L¨

osungen ergibt sich noch ein Problem: falls ein Benutzer

Kommandozeilenwerkzeuge oder direkt die API in eigenen Scripten nutzt, weiß

das System erst einmal nicht, welcher Benutzer es ist. Entweder m¨

usste sich der

Benutzer zuerst authentifizieren, was aber unpraktisch ist, wenn ein Script im

3.4. SICHERHEIT 21

Hintergrund laufen soll. Oder aber das System erfragt den UNIX-Benutzernamen

des Benutzers und bildet diesen auf den System-Benutzer ab. Um das Ganze zu

vereinfachen, k¨

onnte man die beiden Namensr¨

aume auch vereinheitlichen, indem

grunds¨

atzlich die UNIX-Namen benutzt werden.

3.4 Sicherheit

Da man den Benutzern nicht immer trauen kann, sollte das System auch Zugriffs-

schutz bieten. Wobei zwischen dem Zugriff auf die Daten und der Nutzung der

Schnittstellen (API, Web-Interface) unterschieden werden muss.

3.4.1 Daten

Die Entscheidung, ob ein Zugriff gew¨

ahrt wird oder nicht, kann anhand der Rollen

und F¨

ahigkeiten des Benutzers getroffen werden. Beispiel: Ein Benutzer mit der

Rolle “Labeler” bekommt lesenden Zugriff auf alle Label-Auftr¨

age, die f¨

ur ihn

bestimmt sind, ein Benutzer mit der Rolle “LabelJobManager” kann dagegen

neue Label-Auftr¨

age anlegen und die von ihm angelegten Auftr¨

age bearbeiten

(also schreiben).

Diese L¨

osung ist zwar einfach, aber recht grob. Man kann zum Beispiel nicht sa-

gen: Dieser Benutzer hat zwar keinen Zugriff auf die Daten der Testl¨

aufe, aber den

Testlauf “xyz” soll er lesen k¨

onnen. Ein Ausweg w¨

are eine zus¨

atzliche Rechtever-

waltung in Form einer Datenbank-Tabelle, in der zu einem Objekt (eine Tabelle,

Datei usw.) Benutzer und deren Zugriffsrechte (lesen, schreiben, ausf¨

uhren) an-

gegeben werden k¨

onnen. Bei einem Zugriff w¨

urde das System neben den Rollen

und F¨

ahigkeiten auch diese Tabelle abfragen.

3.4.2 API, Web-Interface

Der Zugriff auf die einzelnen Seiten des Web-Interface kann mit Hilfe der Rollen

und F¨

ahigkeiten gesteuert werden. Zum einen kann man nur auf Seiten verlinken,

die dem jeweiligen Benutzer zur Verf¨

ugung stehen, zum anderen m¨

ussen aber auch

22 KAPITEL 3. ANALYSE

bei jedem Seitenaufruf die Zugriffsrechte gepr¨

uft werden, da die Adresse (URL)

auch direkt vom Benutzer angegeben werden kann.

Bei der Python-API verh¨

alt es sich ¨

ahnlich: Der Zugriff auf Funktionen kann

mit Hilfe der Rollen/F¨

ahigkeiten gesteuert werden, wobei auch feinere Steuerung

denkbar w¨

are. Die L¨

osung ist dabei die gleiche wie bei den Daten: Zu jeder Funk-

tion kann gespeichert werden, welcher Benutzer diese ausf¨

uhren kann (zus¨

atzlich

zu den Rollen/F¨

ahigkeiten). Zu bedenken ist nat¨

urlich, dass das Abfragen der

Datenbank-Tabelle mit den Zugriffsrechten bei jedem Aufruf einer Funktion die

Performance drastisch senken kann.

Kapitel 4

Technische Umsetzung

Im kapitel 3 wurden allgemeine Fragestellungen diskutiert und m¨

ogliche L¨

osungs-

wege er¨

ortert. In diesem Kapitel werden nun die entsprechenden technischen

M¨

oglichkeiten beschrieben, diskutiert und die gew¨

ahlte und umgesetzte L¨

osung

vorgestellt.

4.1 Architektur

Bevor es weiter gehen kann, muss noch kurz die Architektur des Gesamtsystems

vorgestellt werden, da sich aus dieser einige zus¨

atzliche Fragestellungen ergeben,

die im Kapitel 2 nicht erw¨

ahnt wurden, aber ebenfalls diskutiert werden m¨

ussen.

Die Begr¨

undung f¨

ur diese Architektur wird an dieser Stelle allerdings noch nicht

gegeben (siehe dazu Kapitel 4.2.1).

Die Abbildung 4.1 zeigt einen groben ¨

Uberblick. Man kann dem Bild entnehmen,

dass das System aus insgesamt vier Servern besteht (diese werden in eigenen

Kapiteln beschrieben):

•HTTP-Server (Kapitel 4.3)

•DBMS-Server (Kapitel 4.4)

•WfMS-Server (Kapitel 4.5)

•Glue-Server (Kapitel 4.7)

24 KAPITEL 4. TECHNISCHE UMSETZUNG

Abbildung 4.1: Architektur des Systems

Wozu die ersten drei Server ben¨

otigt werden, sollte klar sein: Der HTTP-Server

wird f¨

ur das Web-Interface ben¨

otigt, der DBMS-Server f¨

ur die Speicherung der

Daten und der WfMS-Server kontrolliert den Arbeitsablauf. Da sich die Notwen-

digkeit f¨

ur den Glue-Server aus der Kommunikation Python ←→ Java ergibt,

wird hier auf Kapitel 4.2.1 verwiesen.

Alle vier Server k¨

onnen auf eigenen Maschinen laufen, um so die Last zu ver-

teilen. Eine m¨

ogliche Vereinfachung der Architektur w¨

are die Zusammenlegung

des Webservers mit dem Glue-Server. Damit w¨

urde die netzwerkbasierte Kom-

munikation zwischen den beiden entfallen, was der Performance zugute kommen

w¨

urde. Dabei k¨

onnte auch der Apache HTTP-Server entfallen, da Python schon

einen einfachen HTTP-Server bietet. Aber zumindest eine Trennung in zwei Pro-

zesse macht Sinn, damit ein Absturz des Webservers nicht auch den Rest mit sich

zieht.

4.2 Kommunikation

Eine der zentralen Komponenten des Systems ist der Workflow-Server ADEPT

1 (siehe Kapitel 4.5). Dieser ist in Java geschrieben und bietet nur eine Java-

API an. Da der Rest des Systems aber in Python geschrieben ist, stellt sich die

Frage, ob die WfMS-Clients in Java oder in Python geschrieben werden sollen.

Da Python bevorzugt eingesetzt werden soll, wurde nach M¨

oglichkeiten gesucht,

die Clients in Python schreiben zu k¨

onnen.

4.2. KOMMUNIKATION 25

Ein in Python geschriebener WfMS-Client m¨

usste auf die Java-API von ADEPT

zugreifen k¨

onnen. Diese wiederum kommuniziert ¨

uber RMI (Remote Method In-

vocation [RMI]) mit dem ADEPT-Server. Leider existiert keine einfache Me-

thode, eine Java-API in Python zu benutzen, da sowohl Python- als auch Java-

Anwendungen in eigenen virtuellen Maschinen und somit in getrennten Adressr¨

aum-

en laufen. JNI (Java Native interface [JNI]) schafft hier auch keine Abhilfe, da

man damit zwar eine Bibliothek schreiben kann, die von einer Java-Anwendung

benutzt werden kann, es bleibt aber die Frage wie diese Bibliothek mit einer

Python-Anwendung kommunizieren soll.

Mit erheblich mehr Aufwand sind zwei m¨

ogliche L¨

osungen f¨

ur dieses Problem

verbunden:

•Jython ([Jithon])

•JPype ([JPype])

Jython ist eine Python-Implementierung in Java und hat somit auch Zugriff auf

die Java-Bibliotheken. Jython implementiert den Sprachumfang von Python 2.1

und bietet auch Teile der Standardbibliothek von Python 2.1. Allerdings ist Jy-

thon deutlich langsamer als das normale Python (CPython) und kann keine

CPython-Bibliotheken nutzen. Außerdem w¨

urde sich beim Einsatz von Jython

die Frage stellen, wie normale Python-Anwendungen mit Jython-Anwendungen

kommunizieren sollen. Man k¨

onnte also die WfMS-Clients in Jython schreiben,

das Problem der Kommunikation w¨

are dann aber immer noch nicht gel¨

ost.

JPype bietet einen anderen Ansatz als Jython: Es wird das normale CPython

benutzt, JPype bietet aber die M¨

oglichkeit, eine JVM zu starten und im Python-

Programm die Java-Bibliotheken zu nutzen. Dies sieht dann so aus (aus [JPypeEx]):

Listing 4.1: Beispiel f¨

ur JPype

from jpype import ∗

startJVM ( ”d :/ t ool s / j2sdk / j r e / bin / c l i e n t /jvm . d l l ” , ”−ea”)

java . lang . System . out . p r i n t l n ( ” h e l l o world ” )

shutdownJVM()

26 KAPITEL 4. TECHNISCHE UMSETZUNG

Die Kommunikation mit der JVM erledigt JPype ¨

uber JNI. Man kann also mit

CPython arbeiten und trotzdem auf Java-Bibliotheken zugreifen. Diesen Vorteil

erkauft man allerdings mit schlechterer Performance, da Konvertierungen der Da-

ten von Java nach Python bzw. umgekehrt notwendig sind und JNI zus¨

atzlichen

Aufwand verursacht.

Da die beiden vorgestellten L¨

osungen mit Nachteilen behaftet sind, wurde ent-

schieden, die WfMS-Clients in Java zu schreiben und sie mit dem Glue-Server

kommunizieren zu lassen. Der Vorteil ist offensichtlich: Die Clients werden ganz

normal in Java geschrieben, ohne, dass irgendwelche mehr oder weniger ausge-

reiften L¨

osungen ben¨

otigt werden, die Python und Java verbinden. Allerdings

laufen die Clients bei dieser L¨

osung als eigenst¨

andige Prozesse, so dass ein Weg

gefunden werden muss, diese mit dem Rest des Systems kommunizieren zu lassen.

F¨

ur die Kommunikation zwischen Prozessen gibt es grunds¨

atzlich zwei M¨

oglich-

keiten:

•IPC - Inter-Prozess Communication

•netzwerkbasierte Kommunikation

Die netzwerkbasierte Kommunikation hat den Vorteil, dass sie auch zwischen ein-

zelnen Rechnern funktioniert, was aber zus¨

atzlichen Aufwand verursacht und so

die Geschwindigkeit reduziert. Dagegen verzichtet IPC auf die F¨

ahigkeit zwischen

einzelnen Rechnern zu vermitteln und kann so sehr hohe Leistung bieten. Da der

Glue-Server und die WfMS-Clients auf der gleichen Maschine laufen k¨

onnen und

IPC Performance-Vorteile verspricht, fiel die Wahl auf IPC.

4.2.1 UNIX Message Queues

In der UNIX-Welt gibt es mehrere L¨

osungen f¨

ur Inter-Prozess Communication:

•Pipes

•Named Pipes

•Shared Memory

4.2. KOMMUNIKATION 27

•UNIX Message queues

Pipes (siehe [Hero99, Seite 717]) sind in diesem Kontext schwierig zu benutzen,

da hier der Vater-Prozess vor dem fork1-Aufruf die Pipe einrichten muss und

die beiden Seiten virtuelle Maschinen einsetzen. Wenn also ein Python-Script

eine Pipe einrichtet und dann mit fork und anschließendem exec2-Aufruf eine

Java-Anwendung startet d¨

urfte es f¨

ur letztere schwierig werden auf die Pipe zu-

zugreifen.

Named Pipes (siehe [Hero99, Seite 744]) w¨

aren einfacher als Pipes zu benutzen, da

hier nur der Name der Datei f¨

ur die Named Pipe bekannt sein muss. Allerdings

m¨

usste man f¨

ur jeden WfMS-Client eine Named Pipe einrichten und die Im-

plementierung eines Kommunikationsprotokolls mit Pipes oder Named Pipes ist

nicht gerade einfach (Datei lesen/schreiben Semantik, Parsen des Datenstroms).

Shared Memory (siehe [Hero99, Seite 780]) w¨

urde wohl die beste Performan-

ce bieten, da die Kommunikation direkt ¨

uber den Arbeitsspeicher abl¨

auft. Hier

trifft man aber auf das gleiche Problem wie bei den Pipes: Beide Kommunika-

tionspartner laufen in eigenen virtuellen Maschinen, woraus folgt, dass Shared

Memory nicht so einfach benutzt werden kann.

Bleiben noch die UNIX Message Queues (siehe [Hero99, Seite 756]), welche f¨

Nachrichtenaustausch zwischen Prozessen benutzt werden k¨

onnen und auf hohen

Durchsatz ausgelegt sind. UNIX Message Queues werden von den meisten UNIX-

Systemen angeboten. Die Schnittstelle ist ¨

uberschaubar (es sind 4 Systemaufrufe)

und die Funktionsweise einfach: Eine Message Queue ist eine Art verkettete Lis-

te, an die neue Eintr¨

age angeh¨

angt und aus der vorhandene Eintr¨

age entnommen

werden k¨

onnen. Auch ist es m¨

oglich einen Empf¨

anger zu adressieren, indem man

eine Integerzahl beim Versand und Empfang angibt. Beim Abruf der Nachrichten

wird immer die ¨

alteste Nachricht mit der angegebenen Adresse zur¨

uckgegeben. Es

ist nicht n¨

otig, eine Verbindung zwischen den Prozessen aufzubauen, und Versand

und Empfang k¨

onnen sowohl synchron (blockierend) als auch asynchron gesche-

hen. Wegen dieser Vorteile werden die Message Queues f¨

ur die Kommunikation

benutzt.

1UNIX Systemaufruf fork, siehe [Hero99, Seite 486].

2UNIX Systemaufruf exec, siehe [Hero99, Seite 520].

28 KAPITEL 4. TECHNISCHE UMSETZUNG

Damit die WfMS-Clients mit dem Rest des Systems kommunizieren k¨

onnen, wird

eine Weitere Komponente ben¨

otigt, welche ¨

uber UNIX Message Queues mit den

Clients und ¨

uber ein netzwerktransparentes Protokoll mit den anderen Kompo-

nenten kommuniziert. Diese Komponente ist der Glue-Server (Kapitel 4.7).

Da weder Python noch Java Message Queues unterst¨

utzen, wurde eine eigene

Bibliothek mit C++ geschrieben, die mit Hilfe der Systemaufrufe msgget,ms-

gsnd,msgrcv und msgctl (in “sys/msg.h”) eine Kommunikationsschicht zwischen

Glue-Server und WfMS-Clinets bildet. Dabei wurde darauf geachtet, dass diese

Bibliothek leicht durch eine andere ersetzt werden kann, falls man sich in Zu-

kunft f¨

ur ein anderes Verfahren entscheiden sollte. Der Code liegt im Verzeichnis

“GlueServer/messaging”.

Die Schnittstelle wird in der abstrakten Klasse “AbstractChannel” definiert (in

“abstract channel.h”). Sie besteht nur aus drei Methoden:

Listing 4.2: Methode “deleteChannel”

bool deleteChannel ( void )−Ressourcen wieder freigeben ,

Listing 4.3: Methode “sendMessage”

bool sendMessage (char∗data , long msgType , bool block )

Nachricht versenden

data −Daten , die versendet werden so l l e n

msgType −die Adresse

block −blockieren / nicht b lockier en

R¨

uckgabe : true bei Erfolg , false sonst

Listing 4.4: Methode “receiveMessage”

char∗receiveMessage ( long msgType , bool block )

Nachricht abholen

msgType −die Adresse

block −blockieren / nicht b lockier en

R¨

uckgabe : Zeiger auf die Daten , NULL sonst

Jede Implementierung, die diese Schnittstelle implementiert, sollte problemlos

benutzt werden k¨

onnen.

4.2. KOMMUNIKATION 29

Die vorhandene Implementierung (Klasse “MessageQueueChannel”) liegt in den

Dateien “mque channel.h” und “mque channel.cpp”, die zu “mque channel.o”

kompiliert werden (dazu wird SCons benutzt). Um die Bibliothek in Python und

Java benutzen zu k¨

onnen, wird zus¨

atzlich mit SWIG je ein Interface erzeugt:

•“GlueServer/messaging/python/ mque channel.so” f¨

ur Python

•“GlueServer/messaging/java/mque channel.so” f¨

ur Java

Listing 4.5 zeigt, wie das “mque channel”-Modul in einem Python-Script impor-

tiert werden kann.

Listing 4.5: Import des “mque channel”-Modules

from messaging . python . mque channel import ∗

Damit die WfMS-Clients die Bibliothek nutzen k¨

onnen, gen¨

ugt es den Inhalt des

“GlueServer/messaging/java” Verzeichnises in das Verzeichnis “client” zu kopie-

ren.

Eine Instanz der Klasse “MessageQueueChannel” kann in genau eine Message

Queue schreiben bzw. lesen (siehe Abbildung 4.2). Der Konstruktor bekommt als

Parameter einen Message Queue Schl¨

ussel, der eine Message Queue identifiziert,

maximale Gr¨

oße einer Nachricht und ein Verzeichnis f¨

ur die Nachrichten (siehe

unten).

Abbildung 4.2: Kommunikation ¨

uber eine Message Queue

Das Format der Nachrichten wurde folgendermaßen festgelegt: Die ersten 8 Bytes

sind f¨

ur den Header reserviert, danach kommt die eigentliche Nachricht. Der

Header besteht aus einer achtstelligen Hexadezimalzahl (Buchstaben A-F groß

geschrieben), die einen fortlaufenden Z¨

ahler darstellt. Mit dieser Zahl kann die

Reihenfolge der Nachrichten bestimmt werden.

Da eine Message Queue nicht beliebig viele Daten aufnehmen kann, werden gr¨

oße-

re Nachrichten nicht direkt in die Message Queue geschrieben. Stattdessen wird

30 KAPITEL 4. TECHNISCHE UMSETZUNG

der Inhalt der Nachricht in eine Datei geschrieben und nur der Header versen-

det. Vorher wird allerdings noch das oberste Bit im Header gesetzt, damit der

Empf¨

anger merkt, dass die Nachricht in einer Datei liegt. Der zweite Parameter

des Konstruktors legt fest, ab welcher Gr¨

oße eine Nachricht nicht direkt versendet

wird.

Der dritte Parameter des Konstruktors bestimmt, in welchem Verzeichnis die Da-

teien mit dem Inhalt der Nachrichten abgelegt werden. Der Name dieser Dateien

hat folgenden Aufbau:

Schl¨ussel_Adresse_Z¨ahler.msg

Beispiel: 10000_1_10.msg

Der Empf¨

anger kann also leicht herausfinden, welche Datei er lesen muss, da der

Z¨

ahler im Header steht. Nachdem der Empf¨

anger die Datei gelesen hat, l¨

oscht er

diese.

F¨

ur die Kommunikation mit den WfMS-Clients richtet der Glue-Server drei Mes-

sage Queues ein:

•eine f¨

ur die Richtung Glue-Server →Client

•eine f¨

ur die Richtung Client →Glue-Server

•eine f¨

ur unerwartete Nachrichten vom Client (z.B. wenn ein unerwarteter

Fehler auftritt)

Zus¨

atzlich werden drei weitere Message Queues eingerichtet, die dazu dienen, mit

einem speziellen WfMS-Client (ADEPTManager, zust¨

andig f¨

ur die Benutzerver-

waltung, siehe Kapitel 4.6) zu kommunizieren. Beim Beenden des Glue-Servers

werden s¨

amtliche Message Queues wieder freigegeben (nicht abgeholte Nachrich-

ten gehen verloren!).

Vor dem Starten eines neuen WfMS-Clients erzeugt der Glue-Server eine Adresse

f¨

ur diesen (es wird einfach eine Integer-Zahl hochgez¨

ahlt).

Die Parameter (Message Queue Schl¨

ussel, maximale Nachrichtengr¨

oße und das

Verzeichnis f¨

ur die Nachrichten) k¨

onnen in der Konfigurationsdatei “glue server.cfg“

eingestellt werden.

4.2. KOMMUNIKATION 31

Die Kommunikation ¨

uber Message Queues hat bis jetzt gut funktioniert. In Zu-

kunft sollte aber die Fehlerbehandlung ausgebaut werden, da die Nachrichten

solange in der Warteschlange verbleiben, bis sie entweder abgeholt werden oder

die Warteschlange gel¨

oscht wird. Nach einem Absturz und einem erneutem Start

kann es deswegen zu Inkonsistenzen kommen.

4.2.2 XML-RPC

Nachdem begr¨

undet wurde, warum der Glue-Server ben¨

otigt wird, soll in die-

sem Kapitel diskutiert werden, wie dieser mit dem HTTP-Server kommuniziert

(genauer: wie dieser mit den Python-Scripten kommuniziert, die im Kontext des

HTTP-Servers laufen, siehe Kapitel 4.3).

Zuerst muss aber noch eine Design-Frage gekl¨

art werden: Sollen der HTTP-Server

und der Glue-Server auf getrennten Maschinen laufen k¨

onnen oder sollen sie zu-

sammengelegt werden? Im letzteren Fall w¨

are das System-Design einfacher, da die

Python-Scripte im Kontext des HTTP-Servers direkt ¨

uber Message Queues mit

den WfMS-Clients kommunizieren und so den Glue-Server ¨

uberfl¨

ussig machen

w¨

urden. Dagegen muss beim Verteilen der beiden Server zus¨

atzlicher Aufwand

bei der Kommunikation betrieben werden.

An dieser Stelle soll noch etwas vorweg genommen werden: der Glue-Server dient

nicht nur der Kommunikation mit den WfMS-Clients, sondern verwaltet diese

auch (Starten, Beenden). Außerdem bildet er die Schnittstelle f¨

ur die Python-

API (die ja auch ¨

uber Rechner-Grenzen hinweg funktionieren muss).

Aus den oben genannten Gr¨

unden fiel die Entscheidung zugunsten der Verteilung

der beiden Komponenten. Es bleibt also noch zu kl¨

aren, wie die Kommunikation

ablaufen soll.

Wegen der Verteilung kommen nur Kommunikations-Mechanismen in Frage, die

netzwerktransparent sind. Hier stehen einige M¨

oglichkeiten zur Verf¨

ugung: von

low-level Mechanismen, wie Sockets, bis hin zu high-level Mechanismen, wie RPC

([RPC]) oder SOAP ([SOAP]). Da die Entwicklung mit low-level Protokollen auf-

wendig und fehlertr¨

achtig ist, wurden nur high-level Protokolle betrachtet. Großer

Wert wurde dabei auf gute Python-Integration gelegt. Schwergewichte wie SOAP

32 KAPITEL 4. TECHNISCHE UMSETZUNG

wurden weggelassen, da sie f¨

ur diese Aufgabe ¨

uberdimensioniert scheinen. In die

engere Wahl fielen so nur Twisted Spread ([twissp]) und XML-RPC ([XMLRPC]).

Twisted ist eine Python-Bibliothek f¨

ur Netzwerkprogrammierung und bietet mit

Twisted Spread auch einen RPC-Mechanismus. Beim Einsatz von Twisted Spread

gab es jedoch einige Probleme. So klappte die Verbindung zum Glue-Server oft

nicht, wenn man das Web-Interface nutzte, wobei die Ursache des Problems selbst

nach langer Suche nicht gefunden werden konnte (es hat vermutlich mit Multi-

threading zu tun, von dem Twisted massiven Gebrauch macht). Dazu kommt

noch eine merkw¨

urdige Einschr¨

ankung von Twisted Spread: Es kann maximal

600KByte große Daten (Strings) auf einmal ¨

ubertragen. Es ist zwar m¨

oglich, die-

se Einschr¨

ankung zu umgehen, die L¨

osung ist aber recht aufwendig und nicht

transparent (neben dem Server muss auch der Client angepasst werden).

Als weitaus unproblematischer erwies sich die XML-RPC Bibliothek, die mit

Python mitgeliefert wird. XML-RPC nutzt HTTP als Protokoll, wobei Python

daf¨

ur auch schon einen einfachen Server mitliefert ([PyHTTP]). Die Daten werden

in XML verpackt und verschickt. Unterst¨

utzt werden s¨

amtliche Datentypen von

Python: Zahlen, Strings, Listen, aber auch Datum und bin¨

are Daten. Instanzen

von Klassen (außer date) k¨

onnen leider nicht verschickt werden, was aber keine

große Einschr¨

ankung ist, da die Schnittstelle einfach gehalten ist.

Ein Nachteil der XML-RPC Implementierung von Python ist die Tatsache, dass

es nicht multithreaded ist und beim Verarbeiten einer Anfrage der Server keine

weiteren Anfragen annimmt. Es existiert allerdings eine einfache L¨

osung f¨

ur dieses

Problem: Statt der Klasse SimpleXMLRPCServer (die einen einfachen XML-RPC

Server implementiert) wird eine abgeleitete Klasse benutzt (siehe Listing 4.6, aus

[ThXMLRPC]).

Listing 4.6: Klasse AsyncXMLRPCServer

class AsyncXMLRPCServer ( SocketServer . ThreadingMixIn ,

SimpleXMLRPCServer ) :

pass

Damit wird erreicht, dass der Server jede Anfrage im eigenen Thread abarbeitet.

In [ThXMLRPC] wird allerdings behauptet:

“This implementation will probably have some scalability issues and it can’t

compete with the feature-set which for example Twisted has.”

4.2. KOMMUNIKATION 33

Das heißt, diese L¨

osung skaliert vermutlich nicht gut, was aber erst zum Problem

wird, wenn die Last groß wird, was aber zur Zeit nicht zu erwarten ist.

4.2.3 Json

Bei so vielen Kommunikationswegen stellt sich nat¨

urlich die Frage, in welchem

Format man die Daten austauscht. Neben Python-Scripten und Java-Clients gibt

es beim Web-Interface noch JavaScript ([JavaSc]), welches mit dem HTTP-Server

kommunizieren kann (z.B. um Daten anzufordern).

Im Zusammenhang mit JavaScript und Ajax ([AJAX]) f¨

allt oft der Begriff JSON

([Json]), welcher f¨

ur “JavaScript Object Notation” steht und ein Datenaustausch-

format beschreibt. Es dient dem selben Zweck wie XML, ist aber viel einfacher

aufgebaut und kann so schneller geschrieben bzw. gelesen werden. Wie man dem

Namen entnehmen kann, basiert es auf der JavaScript-Syntax und kann somit di-

rekt von JavaScript verarbeitet werden. Es existieren auch viele Implementierun-

gen f¨

ur viele Sprachen, f¨

ur Python ist vor allem CJson ([CJson]) empfehlenswert,

f¨

ur Java Json-Lib ([JsonLib]), welches auch das alte JDK 1.3.1 unterst¨

utzt.

F¨

ur die Kommunikation mit dem Glue-Server wird grunds¨

atzlich Json als Daten-

format benutzt, wobei dies von den Clients versteckt wird (siehe Kapitel 4.9.2).

4.2.4 SSH

Die Testl¨

aufe werden auf anderen Maschinen im Netzwerk ausgef¨

uhrt, deswegen

braucht das System eine M¨

oglichkeit, auf diese Maschinen zuzugreifen. Eine denk-

bare L¨

osung ist ein Dienst, der auf diesen Rechnern l¨

auft und auf Auftr¨

age wartet.

So ein Dienst m¨

usste aber auf jedem einzelnen Rechner eingerichtet werden und

w¨

urde dar¨

uber hinaus ein zus¨

atzliches Sicherheitsrisiko darstellen.

Besser w¨

are eine L¨

osung, die ohne zus¨

atzliche Dienste funktioniert. Und so einen

Dienst gibt es tats¨

achlich auf allen Rechnern im Netzwerk, die f¨

ur die Testl¨

aufe

zur Verf¨

ugung stehen: SSH - Secure Shell ([OpenSSH]).

Mit SSH kann man sich mit seinem Benutzernamen und Passwort auf einem

Rechner einloggen. Da aber das System schlecht ein Passwort in einer Shell

eingeben kann, wird ein Weg ben¨

otigt, sich ohne Passworteingabe anmelden zu

34 KAPITEL 4. TECHNISCHE UMSETZUNG

k¨

onnen. Auch daf¨

ur gibt es eine L¨

osung: der Public Key. Mit dem Kommando

“ssh-keygen” k¨

onnen zwei Schl¨

ussel generiert werden, ein privater Schl¨

ussel und

ein ¨

offentlicher Schl¨

ussel. Dies muss mit dem Benutzer gemacht werden, unter

dem das System sp¨

ater laufen soll. Anschließend muss der ¨

offentliche Schl¨

ussel

in die Datei “.ssh/authorized keys” im Home-Verzeichnis des Benutzers, der die

Testl¨

aufe ausf¨

uhren wird, eingef¨

ugt werden. Dank NFS-gemounteter Home- Ver-

zeichnisse muss dies nur einmal gemacht werden. Jetzt kann das System mit

scp FILE USER@MACHINE/DIR

die Datei “FILE” auf die Maschine mit dem Namen “MACHINE” in das Ver-

zeichnis “DIR” kopieren. Mit

ssh USER@MACHINE /home/USER/EXE

kann die ausf¨

uhrbare Datei “EXE” auf der Maschine “MACHINE” ausgef¨

uhrt

werden.

Damit gibt es einen Weg, die Testl¨

aufe auf andere Maschinen zu kopieren und zu

starten.

4.3 Web-Server

Im Kapitel 2.4.1 wurde bereits erw¨

ahnt, dass das Benutzerinterface Web-basiert

sein soll. Somit ist es notwendig, einen HTTP-Server f¨

ur die Generierung und

Auslieferung der Web-Seiten aufzusetzen.

4.3.1 Apache HTTP-Server

Da s¨

amtliche Komponenten des Systems unter Linux laufen m¨

ussen, kommen alle

HTTP-Server in Betracht, die unter Linux laufen. Neben dem wohl am meisten

benutzten HTTP-Server Apache, gibt es noch andere, kleinere HTTP-Server:

•lighttpd ([LightHTTP])

•LiteSpeed ([LiteSp])

4.3. WEB-SERVER 35

•CGIHTTPServer von Python ([PyHTTP])

Wegen der großen Verbreitung und der M¨

oglichkeit, den Python-Interpreter in

den Server zu integrieren, wird der Apache HTTP-Server benutzt.

4.3.2 mod python

Von zentraler Bedeutung f¨

ur ein Web-Interface ist die F¨

ahigkeit, dynamisch Web-

Seiten zu generieren, da ein Benutzerinterface im Allgemeinen nicht statisch ist.

Dazu gibt es heutzutage im wesentlichen drei M¨

oglichkeiten:

•CGI ([CGI])

•Fast-CGI ([FastCGI])

•in den Server integrierter Interpreter einer Scriptsprache

CGI ist recht langsam und verschwendet viel Arbeitsspeicher, da bei jedem Seiten-

Request der Interpreter geladen wird. Fast-CGI bietet eine bessere Performance,

ist aber schwieriger aufzusetzen und die vorhandenen L¨

osungen scheinen noch

nicht sehr ausgereift zu sein. Eine andere interessante Methode besteht darin, den

Interpreter der Scriptsprache in den HTTP-Server einzubauen. Damit entf¨

allt das

Laden des Interpreters bei einem Request und der Durchsatz steigt im Vergleich

zu CGI. Ein weiterer Vorteil dieser L¨

osung: Es ist einfach aufzusetzen (beim

Apache HTTP-Server muss ein Modul kompiliert und in der Konfigurationsdatei

aktiviert werden).

F¨

ur den Apache HTTP-Server existieren einige Module f¨

ur verbreitete Scriptspra-

chen, darunter Python: “mod python” ([modpy]). Es ist ausgereift, gut dokumen-

tiert und bietet einige weitere Funktionen wie Session-Menagement ([PySession])

oder PSP - Python Server Pages ([PSP]). Python-Scripte, die von mod python

ausgef¨

uhrt werden, k¨

onnen sowohl auf die gesamte Standardbibliothek von Py-

thon als auch auf die Internas des Apache HTTP-Servers zugreifen.

36 KAPITEL 4. TECHNISCHE UMSETZUNG

4.3.3 Integration

Beim Einsatz von mod python werden statt HTML-Seiten Python-Scripte expor-

tiert, die bei entsprechender Konfiguration von Apache an mod python ¨

ubergeben

und von diesem verarbeitet werden. Die Ausgabe dieser Scripte wird dann an den

Client ¨

ubermittelt.

F¨

ur das Web-Interface wurde auf dem HTTP-Server das Verzeichnis “htdocs/wfms”3

eingerichtet, welches die Python-Scripte enth¨

alt. Im Browser kann die Angabe der

Endung “.py” entfallen:

http://localhost:8000/wfms/login.py

oder einfach

http://localhost:8000/wfms/login

Die Python-Scripte kommunizieren mit dem Glue-Server ¨

uber XML-RPC, um

zum Beispiel die ben¨

otigten Daten anzufordern.

4.3.4 Session Management

Um die Clients zu identifizieren, wurde auf das Session Management von mod

python zur¨

uckgegriffen. Dieses benutzt Cookies ([Cookie]) um einen Browser zu

identifizieren. In diesen Cookies wiederum k¨

onnen weitere Daten, wie zum Bei-

spiel der Benutzername, hinterlegt werden. Dieser Benutzername wird von den

Python-Scripten benutzt um festzustellen, ob ein Benutzer Zugriff auf eine Seite

hat (siehe Kapitel 4.8.2). Eine Sitzung ist in der Standardeinstellung 30 Minuten

lang g¨

ultig.

4.3.5 Python Server Pages

Python Server Pages bieten eine M¨

oglichkeit, Python-Code in HTML-Daten un-

terzubringen, welcher vor der Auslieferung ausgef¨

uhrt wird, um die Seite mit

Inhalt zu f¨

ullen. Dabei steht dem Entwickler der gesamte Sprachumfang von

3htdocs ist das Verzeichnis, das der HTTP-Server Apache standardm¨

assig exportiert.

4.4. DBMS-SERVER 37

Python zur Verf¨

ugung (Schleifen, Bedingungen usw.). Dar¨

uber hinaus k¨

onnen

Python-Bibliotheken benutzt werden.

Die Dateien, die solch eine Mischung aus Python und HTML enthalten, haben

meist die Endung “.psp” und k¨

onnen, bei geeigneter Server-Konfiguration, di-

rekt im Browser aufgerufen werden. Dies wurde allerdings nicht benutzt, da es

besser ist, die PSP-Dateien als Vorlagen (Templates) zu benutzen. Solche Vorla-

gen k¨

onnen in Python-Scripten “ausgef¨

uhrt” werden, wobei Daten als Parameter

ubergeben werden k¨

onnen. Das Ergebnis (HTML-Seite) wird dann an den Client

geschickt. Die PSP-Dateien liegen im Verzeichnis “htdocs/wfms”.

4.4 DBMS-Server

Im Kapitel 3.1.3 wurde beschlossen, ein relationales Datenbankmanagementsys-

tem (DBMS) f¨

ur die Verwaltung der Daten zu benutzen. Es bleibt noch zu kl¨

aren,

welches von den vielen existierenden tats¨

achlich benutzt werden soll.

Der zu verwaltende Datenbestand hat zwar bereits eine beachtliche Gr¨

oße erreicht

(siehe 2.1.1 und 2.1.2), ist aber immer noch nicht so groß (und wird es wahrschein-

lich nicht werden), dass ein großes DBMS wie Oracle oder DB2 n¨

otig w¨

are. Die

Wahl kann also auf kleinere DBMS-Systeme beschr¨

ankt werden, die unter Linux

laufen und keine hohen Kosten verursachen. Hier bieten sich vor allem die freien

DBMS-Systeme wie Firebird ([Firebird]), MySQL ([MySQL]) oder PostgreSQL

([Postgre]) an. Von diesen drei wurde PostgreSQL gew¨

ahlt, da es einen beacht-

lichen Leistungsumfang ([PostAb]) hat (deckt zum Beispiel die SQL-Standards

besser ab als MySQL), schnell ist, geometrische Datentypen und dazu passen-

de Operatoren und Funktionen bietet (siehe [PostGeo] und [PostGeoFunk]) und

einfach in der Handhabung ist.

F¨

ur den Zugriff auf SQL-Datenbanken von Python aus existiert ein Standard

“Python Database API Specification v2.0” ([PyDB]). Diesen zu benutzen bringt

den Vorteil, dass man sp¨

ater mit wenig Aufwand auf eine andere Bibliothek,

die diesen Standard unterst¨

utzt, umsteigen kann. Aus diesem Grund wurden nur

die PostgreSQL-Schnittstellen in Betracht gezogen, die diesen Standard imple-

mentieren. Und davon gibt es einige: PyGreSQL ([PyGre]), PyPgSQL ([PyPg]),

psycopg ([Psyco]). Von diesen drei erschien psycopg (in Version 2) am ausge-

38 KAPITEL 4. TECHNISCHE UMSETZUNG

reiftesten: vollst¨

andige Unterst¨

utzung der “Python Database API Specification

v2.0”, ist Thread sicher (Level 2) und auf multithreaded Anwendungen ausgelegt.

F¨

ur den Zugriff auf die Datenbank wird ein Benutzer verwendet, der vollen Zugriff

auf die Daten hat. Die Zugriffskontrolle muss also weiter oben ansetzen (zum

Beispiel bei Funktionen wie “l¨

osche die Bild-Sequenz xyz”).

4.4.1 Performance

Bei dem bisherigen Datenbestand war die Performance bei den meisten Anfragen

sehr gut, allerdings ben¨

otigen einige (komplexere Anfragen) doch lange Laufzeit.

Deswegen sollen hier die M¨

oglichkeiten f¨

ur die Optimierung diskutiert werden.

Eine einfache M¨

oglichkeit, die Geschwindigkeit zu steigern, sind Indexe ([ElNa02,

Seite 186]) auf oft abgefragte Attribute in großen Relationen. Um zu sehen, wie

viel ein Index bringen kann wurde ein Test durchgef¨

uhrt. Listing 4.7 zeigt die

SQL-Query, die f¨

ur diesen Test benutzt wurde.

Listing 4.7: SQL-Query f¨

ur die Performancemessung

SELECT ∗

FROM l a b e l AS l

WHERE l . t r a c k i d = ’ Car 1 ’

Zum Zeitpunkt des Tests befanden sich insgesamt 930679 Labels in der Daten-

bank, von denen 58846 die WHERE-Clausel der Anfrage erf¨

ullten. Getestet wur-

de drei Mal ohne Index auf track id und drei Mal mit Index. Ausgef¨

uhrt wurde

der Test in einer virtuellen Maschine (VMWare Server 1.0.2 [vmware]) mit Gast-

System SuSE Linux 9.3 mit 768MB RAM, PostgreSQL 8.1.5 (Host-Rechner: 2.1

GHz AthlonXP, 2GB RAM, OpenSuSE 10.2 [openSUSE]). Mit folgender Kom-

mandozeile wurde der Test ausgef¨

uhrt:

$ time psql wfms -f seq3.sql > /dev/null

psql ist der PostgreSQL-Client, wfms der Name der Datenbank und mit “-f

seq3.sql” wurde die Datei mit der Anfrage angegeben. Die Tabelle 4.1 fasst die

Laufzeiten der drei L¨

aufe ohne Index zusammen (in Sekunden).

4.4. DBMS-SERVER 39

Lauf real user sys gesamt

1 2.840 0.566 0.334 3.740

2 2.818 0.566 0.329 3.713

3 2.821 0.570 0.308 3.699

Gesamt 11.152

Tabelle 4.1: Laufzeiten ohne Index.

Lauf real user sys gesamt

1 1.486 0.598 0.336 2.420

2 1.460 0.546 0.357 2.363

3 1.448 0.575 0.423 2.446

Gesamt 7.229

Tabelle 4.2: Laufzeiten mit Index.

Anschließend wurde Index auf das Attribut “track id” angelegt und der gleiche

Test drei Mal durchgef¨

uhrt (Tabelle 4.2).

Die Differenz der beiden Gesamtlaufzeiten betr¨

agt 3.923 Sekunden, also bringt

der Index in diesem Beispiel 35% k¨

urzere Laufzeit. Das ist zwar keine sehr große

Steigerung, aber bei komplizierteren Abfragen, bei denen mehrere Attribute mit

Indexen abgefragt werden, k¨

onnen sich solche Steigerungen aufsummieren.

Auch bei einigen anderen Relationen sind Indexe auf bestimmte Attribute denk-

bar:

•frame(name)

•label document(name)

•sequence(name)

•sequence channel(name)

Eine andere M¨

oglichkeit die Geschwindigkeit zu steigern ist die Optimierung der

Server-Konfiguration. Zu diesem Zweck kann die Datei “postgresql.conf” (meis-

tens im Datenbank-Verzeichnis) editiert werden. Vor allem die beiden Parameter

40 KAPITEL 4. TECHNISCHE UMSETZUNG

“shared buffers” und “max connections” sind in diesem Zusammenhang inter-

essant. Mit dem ersten kann PostgreSQL angewiesen werden, mehr Speicher zu

benutzen, und mit dem zweiten kann verhindert werden, dass zuviele gleichzeitige

Verbindungen den Server zu sehr ausbremsen. Im Rahmen dieser Arbeit konnte

aber keine signifikante Wirkung auf die Performance festgestellt werden.

4.5 WfMS-Server

Die Entwicklung eines eigenen Workflow Managemen Systems w¨

urde den Rahmen

dieser Arbeit deutlich sprengen. Außerdem ist es nich sinnvoll, da es schon viele

solche Systeme gibt, die zudem ausgereift und im Einsatz erprobt sind. Es sollte

also ein solches System gefunden und integriert werden.

Das “richtige” Workflow Management System f¨

ur eine bestimmte Problemstel-

lung zu finden ist nicht einfach, da es inzwischen viele Systeme mit teilweise sehr

unterschiedlichen Ans¨

atzen gibt. Die einfachsten Systeme arbeiten formularba-

siert und eignen sich eher f¨

ur kleinere und einfachere Aufgaben. Ein Beispiel f¨

so ein System ist Lotus Notes ([Lotus]).

Ahnlich funktionieren die dokumentenzentrierten Workflow-Systeme, bei denen

eine Art “Umlaufmappe” von einem Bearbeiter zum n¨

achsten weitergereicht wird.

Solche Systeme eignen sich for allem f¨

ur die Automatisierung der Arbeitsabl¨

aufe

in einem B¨

uro. Vertreter dieser Gattung sind zum Beispiel ProMInanD ([promin])

und Floware ([Floware]).

Leistungsf¨

ahiger und flexibler sind die so genannten “Production Workflows”, die

den Anwendungscode von der Prozesslogik trennen. Typische Vertreter dieser Art

von Workflow-Systemen sind MQ Workflow von IBM ([MqWork]) und Staffware

([Staffware]). Auch das an der Universit¨

at Ulm entwickelte ADEPT f¨

allt in diese

Kategorie.

ADEPT liegt eine eigene Notation zur Beschreibung von Prozess-Abl¨

aufen und

Datenfl¨

ussen zugrunde, die bedingte und unbedingte Verzweigungen und Schlei-

fen unterst¨

utzt. Auch zeitliche Aspekte werden unterst¨

utzt: F¨

ur jede Aktivit¨

k¨

onnen minimale und maximale Dauer sowie zeitliche Zusammenh¨

ange zwischen

einzelnen Aktivit¨

aten angegeben werden (zum Beispiel minimale und maximale

Abst¨

ande). Zur Zeit wohl einmalig (zumindest was den Leistungsumfang angeht)

4.5. WFMS-SERVER 41

ist die F¨

ahigkeit von ADEPT, w¨

ahrend der Ausf¨

uhrung einer Prozess-Instanz

dynamisch vom vorgegebenen Prozess-Ablauf abzuweichen.

Von ADEPT existiert zur Zeit ein Prototyp (ADEPT 1), welcher allerdings be-

reits produktiv eingesetzt wird (siehe [ADEPTHos]). ADEPT 2 befindet sich in

Entwicklung und soll in Zukunft die Basis von AristaFlow ([Arista]) bilden. Da-

mit ist sichergestellt, dass ADEPT weiter entwickelt wird. Aus diesen Gr¨

unden

wurde ADEPT 1 f¨

ur die Workflow-Komponente des Systems benutzt.

4.5.1 ADEPT

Neben dem Server, der die Prozess-Instanzen ausf¨

uhrt, bietet ADEPT noch einige

weitere Werkzeuge an:

•ADEPTClient

•ADEPTEditor

•ADEPTOrgManager

Mit dem ADEPTClient k¨

onnen Prozess-Instanzen erstellt und ausgef¨

uhrt werden.

ADEPTEditor dient der Erstellung der Prozess-Vorlagen und mit dem ADEP-

TOrgManager k¨

onnen Organisationsstrukturen, Rollen und Benutzer verwaltet

werden (siehe dazu Kapitel 5.1). Leider laufen diese Anwendungen trotz Java

nur unter Windows fehlerfrei, so dass eine Windows-Maschine ben¨

otigt wird, um

Prozess-Vorlagen zu erstellen oder Benutzer zu verwalten. Der ADEPT-Server

l¨

auft dagegen auch unter Linux, in diesem Fall klappt allerdings die Verbin-

dung von Windows-Client zum Server nicht. Als “work-around” kann auf dem

Windows-Rechner ein weiterer ADEPT-Server gestartet werden, der sich zum

gleichen Oracle-Server verbindet. Es w¨

are aber w¨

unschenswert, wenn die ADEPT-

Werkzeuge in Zukunft auch unter Linux/UNIX laufen w¨

urden.

Ein Nachteil von ADEPT ist die Tatsache, dass es nur mit dem Oracle Daten-

bankserver ([Oracle]) zusammenarbeiten kann (diesen nutzt ADEPT um Benut-

zerdaten, Prozess-Vorlagen usw. zu speichern). Da aber die kostenlose (auch f¨

kommerzielle Nutzung) Express Edition ([OracXE]) von Oracle ausreicht, entste-

hen keine zus¨

atzlichen Kosten.

42 KAPITEL 4. TECHNISCHE UMSETZUNG

Da auf den Oracle Datenbankserver nicht verzichtet werden kann, stellt sich

nat¨

urlich die Frage, ob nicht der PostgreSQL-Server weggelassen werden kann.

Der Funktionsumfang von Oracle Express Edition w¨

urde dem nicht im Wege

stehen (sie bietet auch die M¨

oglichkeit, geometrische Daten zu speichern). Pro-

blematisch sind eher die Einschr¨

ankungen dieser Oracle Version:

•Maximal 4 GB an Daten

•Nur 1 GB Ram

•Nur 1 Prozessor

Vor allem die Beschr¨

ankung auf 4GB Daten k¨

onnte in Zukunft problematisch

werden und den Kauf einer vollst¨

andigen Oracle Version erzwingen. Aus diesem

Grund wird PostgreSQL f¨

ur die Verwaltung der Daten und Oracle f¨

ur ADEPT

benutzt.

Ein weiterer wichtiger Punkt ist die ADEPT-API: diese ist beim Prototyp auf

Java beschr¨

ankt. Vor allem eine C++-API w¨

are n¨

utzlich, da man f¨

ur diese leicht

Wrapper f¨

ur Script-Sprachen wie Python erstellen kann.

4.5.2 ADEPT als Dienst

Server-Software l¨

auft normallerweise im Hintergrund als Dienst, bzw. Service

unter Windows oder Daemon unter UNIX/Linux. Ein Dienst wird meist beim

Starten des System aktiviert und beim Herunterfahren beendet.

Da ADEPT eine normale Java-Anwendung ist und trotzdem als Dienst laufen

muss, musste eine M¨

oglichkeit gefunden werden, dies zu bewerkstelligen.

Die einfachste L¨

osung, die ohne eine Anpassung von ADEPT auskommt, ist der

Einsatz eines Wrappers, der eine Java-Anwendung kapselt und sie als Dienst

laufen l¨

asst. Ein ausgereifter und leicht aufzusetzender Wrapper ist der “Java

Service Wrapper” ([JSW]). Mit Hilfe dieses Wrappers kann ADEPT mit

./adept.sh start

./adept.sh stop

./adept.sh restart

4.6. WFMS-CLIENTS 43

gestartet, gestoppt und neu gestartet werden.

4.6 WfMS-Clients

F¨

ur das Abrufen der Benutzerdaten, die Authentifizierung und das Ausf¨

uhren

von Prozess-Instanzen sind die drei WfMS-Clients vorgesehen, die im folgenden

beschrieben werden. Die Clients liegen im Verzeichnis “client”.

In Kapitel 4.2 wurde bereits diskutiert, ob die WfMS-Clients in Java oder Python

geschrieben werden sollen. Um m¨

oglichen Problemen aus dem Weg zu gehen,

werden die Clients in Java geschrieben.

Als erstes soll hier noch eine Frage beantwortet werden: Soll ein Client mehrere

Prozess-Instanzen gleichzeitig ausf¨

uhren k¨

onnen oder immer nur eine? Falls ein

Client mehrere Prozess-Instanzen gleichzeitig ausf¨

uhren kann, reduziert sich die

Zahl der Betriebssystem-Prozesse, die gleichzeitig laufen. Der klare Vorteil da-

bei ist der geringere Ressourcen-Verbrauch: F¨

ur jede laufende Java-Anwendung

wird eine Instanz der virtuellen Maschine (JVM) gestartet. Der Nachteil die-

ser L¨

osung ist die erh¨

ohte Komplexit¨

at des WfMS-Clients, er muss ja mehre-

re Prozess-Instanzen gleichzeitig verwalten k¨

onnen. Um dieser Komplexit¨

at aus

dem Weg zu gehen wurde entschieden, die L¨

osung mit einer Prozess-Instanz pro

WfMS-Client zu w¨

ahlen.

Wenn das System sp¨

ater weiterentwickelt und von vielen Benutzern verwendet

wird, k¨

onnte der Speicherverbrauch wegen der vielen JVMs deutlich steigen.

Deswegen soll hier noch eine dritte L¨

osung vorgeschlagen werden: Es wird ei-

ne Java-Anwendung geschrieben, die als Dienst im Hintergrund l¨

auft und s¨

amt-

liche WfMS-Clients verwaltet und ausf¨

uhrt. Diese Anwendung kann mit dem

Glue-Server ¨

uber Unix Message Queues kommunizieren. Dieser Ansatz hat den

Nachteil, dass bei einem Absturz dieser Anwendung erst einmal nichts mehr geht,

bis die Anwendung neu gestartet wurde.

Um die Arbeit zu verteilen und die einzelnen Clients einfacher zu halten, wurden

insgesamt drei WfMS-Clients geschrieben:

•Login-Client

•Verwaltungs-Client

44 KAPITEL 4. TECHNISCHE UMSETZUNG

•Client zur Ausf¨

uhrung der Prozess-Instanzen

Da diese drei Clients vieles gemeinsam haben, wurde eine abstrakte Basisklasse

geschrieben, von der sie abgeleitet werden (siehe Abbildung 4.3).

Abbildung 4.3: Hierarchie der WfMS-Client Klassen.

4.6.1 AbstractClient

Die abstrakte Basisklasse ist in der Datei “client/AbstractClient.java” definiert.

In Kapitel 4.7.3 ist beschrieben wie ein WfMS-Client gestartet wird. Wichtig ist

dabei, wie die Parameter ¨

ubergeben werden. Einige der Parameter werden als

Aufrufparameter an den Konstruktor von AbstractClient ¨

ubergeben. Die restli-

chen Parameter befinden sich in einer Konfigurationsdatei im Arbeitsverzeichnis,

die im Konstruktor eingelesen wird. Nach dem Einlesen der Konfigurationsda-

tei versucht der Konstruktor von AbstractClient eine Verbindung zum ADEPT-

Server aufzubauen. Im Erfolgsfall wird eine Nachricht mit dem Inhalt “OK” an

den Glue-Server geschickt, sonst lautet die Nachricht “FAILED”.

4.6.2 Login-Client

Die Klasse LoginClient (zu finden in “client/LoginClient.java”) dient dazu, einen

Benutzer zu authentifizieren. Dazu reicht es aus zu versuchen, mit den ¨

uberge-

benen Benutzernamen und Passwort eine Verbindung zum ADEPT-Server auf-

zubauen. Lehnt der Server diesen Versuch ab, liegt entweder ein Fehler vor oder

die Zugangsdaten stimmen nicht. Und genau so verf¨

ahrt der LoginManager: Die

eigentliche Arbeit erledigt der Konstruktor der Basisklasse. LoginManager trennt

nur noch die Verbindung und beendet sich.

4.6. WFMS-CLIENTS 45

Um einen Benutzer zu authentifizieren, startet der Glue-Server (genauer der

WfMSManager) den Login-Client und wartet auf die Antwort. Lautet diese “OK”,

wird der Benutzer akzeptiert, sonst nicht.

4.6.3 Verwaltungs-Client

Die Klasse “ADEPTManager” ist in der Datei “client/ADEPTManager.java”

definiert.

Der Verwaltungs-Client dient dem Abruf folgender Daten (die ja von ADEPT

verwaltet werden, siehe Kapitel 5.1):

•Benutzer

•Rollen

•F¨

ahigkeiten

•Abbildung F¨

ahigkeiten →Benutzer

•Abbildung Rollen →Benutzer

Damit der UserManager (siehe Kapitel 4.7.2) diese Daten vom Verwaltungs-Client

anfordern kann, wurden folgende Kommandos f¨

ur die Nachrichten definiert (eine

Mischung aus Englisch und Deutsch, da ADEPT die Bezeichnungen “Rolle” und

“Faehigkeit” benutzt):

•GET ALL FAEHIGKEITEN

•GET ALL USERS

•GET ALL ROLLEN

•GET FAEHIGKEIT TO USER

•GET ROLE TO USER

Der Verwaltungs-Client wird vom WfMSManager (Kapitel 4.7.3) beim Hochfah-

ren des Systems gestartet und vom UserManager (Kapitel 4.7.2) mit dem Kom-

mando “TERMINATE” zum Beenden gezwungen (nachdem dieser die Daten

ausgelesen hat).

46 KAPITEL 4. TECHNISCHE UMSETZUNG

4.6.4 Der allgemeine Client

Die Klasse “Client” ist in der Datei “client/Client.java” definiert.

Dieser WfMS-Client ist der komplexeste von den drei und dient dazu, neue

Prozess-Instanzen zu starten und auszuf¨

uhren. Der Name der Prozess-Vorlage,

die benutzt werden soll, wird ¨

uber die Konfigurationsdatei des Clients ¨

uberge-

ben.

Im ADEPTEditor (siehe Kapitel 4.5.1) kann jedem Knoten (Aktivit¨

at) eine ganze

Zahl (Anwendungs-ID) zugeordnet werden, ¨

uber die die auszuf¨

uhrende Anwen-

dung/Script identifiziert werden kann. Damit der Client weiß, welches Script wel-

cher Nummer zugeordnet ist, wird eine Datei verwaltet, in der diese Abbildung

festgehalten ist. Diese Datei heißt “command mapping.txt” und liegt im Ver-

zeichnis “clients”. Im gleichen Verzeichnis liegen auch die Python-Scripte (dies

kann in der Konfigurationsdatei “GlueServer/glue server.cfg” ge¨

andert werden).

Das Format der Mapping-Datei ist ganz einfach: Jede Zeile enth¨

alt eine Zahl,

der ein Script “zugewiesen” wird. Beispiel: 101 = getMachine.py. Die Nummern

<100 wurden f¨

ur Aktivit¨

aten reserviert, die der Java-Client intern ausf¨

uhren kann

(zum Beispiel auf eine Nachricht vom Glue-Server warten). Falls einer Aktivit¨

die Nummer 1 zugeordnet wurde, wird nichts gestartet und die Aktivit¨

at so-

fort als “ausgef¨

uhrt” dem ADEPT-Server gemeldet. Damit k¨

onnen die “leeren”

Knoten, die bei Verzweigungen und Schleifen entstehen, behandelt werden. Die

Mapping-Datei wird im Konstruktor der Client-Classe eingelesen. Das Starten

der Scripte ¨

ubernimmt der Client.

Diese Methode Anwendungen zu starten ist zwar sehr einfach, aber auch unbe-

quem und fehleranf¨

allig. Beim Entwerfen der Prozess-Abl¨

aufe im ADEPTEditor

muss der Benutzer wissen, welcher Anwendung welche Nummer zugeordnet ist,

oder er muss die Mapping-Datei anpassen. Besser w¨

are es, wenn ADEPT 1 belie-

bige Anwendungen starten k¨

onnte und zwar ¨

uber deren Namen (Pfad) und nicht

uber eine nichtssagende Nummer. Auch die automatische Weitergabe der Parame-

ter (Datenfl¨

usse) an die entsprechenden Anwendungs-Prozesse w¨

urde den Client

erheblich vereinfachen. Anscheinend kann ADEPT aber nur Java-Anwendungen

starten. Es w¨

are zwar m¨

oglich gewesen einen Java-Wrapper f¨

ur Python-Scripte

zu schreiben, welcher dann das eigentliche Script starten w¨

urde, das w¨

are aber

doch recht aufwendig.

4.6. WFMS-CLIENTS 47

Nach dem Erzeugen einer Instanz der Klasse Client wird die Methode run auf-

gerufen. Diese Methode sucht dann nach dem Template und erzeugt eine neue

Prozess-Instanz. Anschließend wird die Prozess-Instanz ausgef¨

uhrt, bis die Ar-

beitsliste leer ist.

Falls eine Aktivit¨

at das Starten eines Python-Skriptes erfordert, legt der Client im

Arbeitsverzeichnis (siehe Kapitel 4.7.3) ein Unterverzeichnis mit der Anwendungs-

ID als Namen an. In diesem Verzeichnis werden wiederum zwei weitere Unterver-

zeichnisse angelegt: “in” f¨

ur die Eingabeparameter und “out” f¨

ur die Ausgabe-

parameter. Anschließend werden die Eingabeparameter in das “in”-Verzeichnis

geschrieben, wobei jeder Eingabeparameter in einer eigenen Datei mit seinem

Namen landet. Zus¨

atzlich wird die Datei “param” (siehe Kapitel 4.7.3) in das

Arbeitsverzeichnis des Scriptes kopiert.

Jetzt wird das Python-Script in einem neuen Prozess gestartet, wobei der Cli-

ent auf die Beendigung dieses Prozesses wartet. Damit ist klar, dass der Client

in der derzeitigen Implementierung nicht in der Lage ist, mehrere Aktivit¨

aten

gleichzeitig auszuf¨

uhren. Das kann aber in einer zuk¨

unftigen Version nachgeholt

werden.

Wenn der neue Prozess sich beendet, wird sein Exit-Status ausgewertet um festzu-

stellen, ob das Script fehlerfrei ausgef¨

uhrt wurde. Danach werden die Ausgabepa-

rameter mit den Inhalten der gleichnamigen Dateien im “out”-Verzeichnis gef¨

ullt

(die Python-Scripte m¨

ussen also ihre Ausgabe in Dateien im “out”-Verzeichnis

schreiben).

Jetzt meldet der Client die Beendigung der Aktivit¨

at dem ADEPT-Server und

liest die Arbeitsliste neu ein.

Wenn die Prozess-Instanz komplett abgearbeitet wurde, schickt der Client eine

Nachricht an den Glue-Server mit dem Inhalt:

TERMINATE

Benutzername

Nummer des Clients

Diese Informationen nutzt der WfMSManager um das Arbeitsverzeichnis des Cli-

ents wieder zu l¨

oschen.

48 KAPITEL 4. TECHNISCHE UMSETZUNG

Die Implementierung ist noch nicht vollst¨

andig, es fehlt vor allem eine gute Feh-

lerbehandlung (wenn zum Beispiel ein Client abst¨

urzt).

4.7 Glue-Server

Der Glue-Server befindet sich im Verzeichnis “GlueServer”, die Abbildung 4.4

zeigt seinen Aufbau. Die Klasse “ServerPerspective” ist der eigentliche Glue-

Abbildung 4.4: Interner Aufbau des Glue-Servers.

Server, alle ¨

offentlichen Methoden dieser Klasse werden ¨

uber XML-RPC expor-

tiert. Die meiste Arbeit verteilt der Glue-Server auf f¨

unf Hilfsklassen:

•DatabaseManager - Schnittstelle zum DBMS-Server

•UserManager - Abfrage der Benutzerdaten

•WFMSManager - Verwaltung der WfMS-Clients

•OtherManager - sonstiges

•TestRunManager - Verwaltung der Testl¨

aufe

4.7. GLUE-SERVER 49

Der Glue-Server verwaltet je eine Instanz dieser Klassen und leitet die Anfra-

gen entsprechend weiter. Um die Geschwindigkeit und die Antwortzeiten zu op-

timieren, w¨

are eine Aufteilung in sechs Prozesse denkbar: ein Prozess f¨

ur den

Glue-Server und je ein Prozess f¨

ur die f¨

unf Manager-Klassen.

4.7.1 DatabaseManager

Diese Klasse bildet die Schnittstelle zum PostgreSQL-Server und befindet sich

in der Datei “sql/DatabaseManager.py”. Der Zugriff auf die Datenbank erfolgt

uber psycopg2, die Einstellungen wie Benutzername und Passwort befinden sich

in der Konfigurationsdatei “sql/sql.cfg”.

DatabaseManager unterh¨

alt keine permanente Verbindung zum SQL-Server, statt

dessen wird bei jedem Aufruf eine Verbindung aufgebaut und am Ende wieder

abgebaut. Das ist zwar einfacher zu implementieren, hat aber auch Nachteile:

Aufbau und Abbau einer Verbindung kosten Zeit und bei vielen Anfragen in kur-

zer Zeit k¨

onnte die maximale Anzahl gleichzeitiger Verbindungen ¨

uberschritten

werden. Es w¨

are also besser, wenn DatabaseManager in Zukunft eine oder einige

wenige, permanente Verbindungen nutzen w¨

urde.

Bei der derzeitigen Implementierung wird jeder Aufruf von DatabaseManager in

einer eigenen Transaktion abgewickelt, auch wenn dabei nur eine einzige SELECT-

Anweisung ausgef¨

uhrt wird. Bei erfolgreicher Ausf¨

uhrung wird die Transaktion

mit einem Commit beendet, sonst wird sie mit einem Rollback abgebrochen.

4.7.2 UserManager

Der UserManager (zu finden in “GlueServer/UserManager.py”) wird benutzt,

um die Benutzerdaten von ADEPT abzufragen und f¨

ur eine sp¨

atere Nutzung

zwischenzuspeichern. Um auf ADEPT zuzugreifen, benutzt UserManager den

WfMS-Client “ADEPTManager” (siehe Kapitel 4.6.3). Nach dem Abruf der Be-

nutzerdaten werden diese f¨

ur einen schnelleren Abruf aufbereitet.

Zur Zeit werden folgende Daten zur Verf¨

ugung gestellt:

•Rollen

50 KAPITEL 4. TECHNISCHE UMSETZUNG

•F¨

ahigkeiten

•Benutzer

•Zuordnung der F¨

ahigkeiten zu Rollen

•Zuordnung der Rollen zu Benutzern

Die ersten drei k¨

onnen sowohl ¨

uber die ID als auch ¨

uber den Namen abgerufen

werden. Die beiden letzten k¨

onnen in beide Richtungen abgefragt werden.

Bei der derzeitigen Implementierung werden die Daten beim Erzeugen der User-

Manager-Instanz abgerufen und k¨

onnen somit veralten, wenn danach der Daten-

bestand ge¨

andert wird (zum Beispiel k¨

onnen Benutzer gel¨

oscht oder neue angelegt

werden). Es sollte also noch eine M¨

oglichkeit vorgesehen werden, den UserMa-

nager zum erneuten Einlesen der Daten zu veranlassen. Alternativ k¨

onnte der

UserManager die Daten erst bei Bedarf vom ADEPTManager anfordern, statt

sie einmal komplett einzulesen, was aber weniger performant ist.

4.7.3 WFMSManager

Die Klasse WFMSManager (zu finden in “GlueServer/WFMSManager.py”) ist

von großer Bedeutung, da sie die WfMS-Clients verwaltet.

Jeder WfMS-Client wird einem Benutzer zugeordnet und jeder Benutzer kann

mehrere Clients laufen lassen. Ein Client wird also ¨

uber den Benutzernamen und

eine fortlaufende Nummer adressiert.

Vor dem Starten eines neuen WfMS-Clients legt der WFMSManager ein neues

Verzeichnis an, das als Arbeitsverzeichnis f¨

ur den Client dient. Diese Arbeitsver-

zeichnisse liegen standardm¨

aßig im Verzeichnis “GlueServer/clients”, was aber

in der Konfigurationsdatei “GlueServer/glue server.cfg” ge¨

andert werden kann.

Der Name des Arbeitsverzeichnises setzt sich aus dem Benutzernamen und der

Nummer (wird mit jedem weiteren Client einfach hochgez¨

ahlt) des Clients zusam-

men. Anschließend wird in dieses Verzeichnis die Datei “client.cfg” geschrieben,

die einige Einstellungen enth¨

alt, die jeder Client ben¨

otigt (die Schl¨

ussel f¨

ur die

Message Queues, die Adresse f¨

ur diesen Client, den Namen der Prozess-Vorlage

usw.). Zus¨

atzlich wird noch eine Datei mit dem Namen “param” geschrieben,

4.7. GLUE-SERVER 51

die beliebige Parameter f¨

ur die Prozess-Instanz enth¨

alt (zum Beispiel welcher

Testlauf ausgef¨

uhrt werden soll). Die Adresse f¨

ur den Client wird ebenfalls vom

WFMSManager vergeben (es ist eine Integer-Zahl, die einfach hochgez¨

ahlt wird).

Jetzt erfolg ein fork-Aufruf und der Kind-Prozess startet den Client mit einem

execlp-Aufruf. Dabei werden noch einige Parameter an den Client ¨

ubergeben:

•Arbeitsverzeichnis

•Name der Konfigurationsdatei

•Vorname des Benutzers

•Name des Benutzers

•Passwort

Das Passwort sollte sp¨

ater besser ¨

uber die Konfigurationsdatei ¨

ubergeben werden,

da man dieses sonst mit einem

ps ax | grep java

auf der Kommandozeile einsehen kann.

Wenn sich ein WfMS-Client beendet, schickt er eine Nachricht an den Glue-Server

mit dem Inhalt “TERMINATE”, Benutzername und Adresse. Damit kann der

WFMSManager wieder aufr¨

aumen.

4.7.4 OtherManager

Die Klasse “OtherManager ist in der Datei “GlueServer/OtherManager.py” defi-

niert. Eine Instanz dieser Klasse benutzt der Glue-Server f¨

ur Funktionen, die kei-

nem anderen Manager zugeordnet wurden. OtherManager bietet folgende Funk-

tionalit¨

at:

•Lava-Konfigurationen verwalten

•Label-Dokumente f¨

ur Label-Auftr¨

age generieren

•Label-Dokumente exportieren

52 KAPITEL 4. TECHNISCHE UMSETZUNG

Die Lava-Konfigurationen werden in Verzeichnissen gesucht, die in der Konfigu-

rationsdatei “GlueServer/glue server.cfg” angegeben sind.

Da OtherManager f¨

ur seine Arbeit Daten aus der Datenbank lesen muss, be-

kommt er eine Referenz auf die DatabaseManager-Instanz. Damit die Kommu-

nikation mit dem DatabaseManager intern schneller ablaufen kann, stellt dieser

die Funktion callNoJson zur Verf¨

ugung, die auf Json verzichtet und so das En-

kodieren und Dekodieren der Daten ¨

uberfl¨

ussig macht.

4.7.5 TestRunManager

Die Klasse “TestRunManager” ist in der Datei “GlueServer/TestRunManager.py”

definiert. Der TestRunManager sorgt daf¨

ur, dass die Testl¨

aufe zum angegebenen

Zeitpunkt ausgef¨

uhrt werden. Dazu liest er beim Starten alle noch nicht gestarte-

ten Testl¨

aufe und definiert mit Hilfe des “sched”-Modules von Python ([Sched])

f¨

ur jeden Testlauf ein Event, das zum gegebenen Zeitpunkt eine Funktion auf-

ruft. Mit Hilfe des sched-Modules (event scheduler) kann zu einem bestimmten

Zeitpunkt eine Funktion aufgerufen werden.

Sobald ein solches Ereignis eintritt, wird mit Hilfe des WfMSManagers der Test-

lauf gestartet. Diese L¨

osung ist allerdings noch nicht vollst¨

andig, da beim Anlegen

von neuen Testl¨

aufen der TestRunManager erst einmal nichts davon mitbekommt.

Daf¨

ur gibt es zwei m¨

ogliche L¨

osungen: Die Methode “saveTestRun()” der Klasse

DatabaseManager, die einen neuen Testlauf in die Datenbank schreibt, kann den

TestRunManager benachrichtigen, oder aber es wird ein Trigger f¨

ur die Relation

“test run” definiert, der eine in Python geschriebene Stored Procedure aufruft,

die wiederum ¨

uber die API eine Nachricht an den Glue-Server schickt. Wegen der

Einfachheit fiel die Entscheidung auf die erste Variante.

Der DatabaseManager ruft also den TestRunManager auf und ¨

ubergibt ihm den

Namen des neuen Testlaufs, woraufhin dieser den neuen TestLauf einliest und ein

Event definiert.

Da TestRunManager auf die Datenbank und den WfMSManager zugreifen muss,

werden ihm Referenzen auf DatabaseManager und WfMSManager ¨

ubergeben.

4.7. GLUE-SERVER 53

4.7.6 Logging

Um Meldungen aller Art (Warnungen, Fehler usw.) zu protokollieren, wurde mit

Hilfe des “logging”-Modules von Python ([pylog]) ein Logger aufgesetzt (zu finden

in “api/specht/tools/Logger.py”), der auf die Standardausgabe schreibt (dazu

siehe Kapitel 4.7.7). Dieser Logger wird auch von den Hilfsklassen benutzt.

Es werden mehrere Typen von Meldungen unterschieden:

•DEBUG

•INFO

•WARNING

•ERROR

•CRITICAL

In der Konfigurationsdatei “GlueServer/glue server.cfg” kann angegeben werden,

welche Meldungen protokolliert werden sollen: Steht dort “WARNING”, werden

“DEBUG”- und “INFO”-Meldungen nicht protokolliert.

Neben dem Typ der Meldung wird noch das Datum, die Uhrzeit, die Python-

Datei und die Zeile in dieser Datei (in der die Meldung ausgegeben wurde) im

Log verzeichnet.

4.7.7 Glue-Server als Dienst

Der Glue-Server wurde so implementiert, dass er als Daemon (Dienst) laufen

kann, allerdings existiert noch keine einfache M¨

oglichkeit, diesen Daemon zu be-

enden, außer den Prozess mit

kill PID

(PID - die Prozess ID des Glue-Servers) zum Beenden zu zwingen (Glue-Server

f¨

angt das entsprechende Signal ab und f¨

ahrt dann sauber runter).

54 KAPITEL 4. TECHNISCHE UMSETZUNG

Die Standard-Ausgabe und die Standard-Fehlerausgabe werden in je eine Datei

umgeleitet, die in der Konfigurationsdatei “GlueServer/glue server.cfg” angege-

ben sind. Somit schreibt auch der Logger in die entsprechende Datei (Standard-

ausgabe).

4.8 Web-Interface

Das Web-Interface als Benutzerschnittstelle ist von großer Bedeutung und soll in

diesem Kapitel genauer beschrieben werden. Das Fundament des Web-Interface,

bestehend aus Apache HTTP-Server und mod python, wurde bereits im Kapitel

4.3.1 vorgestellt und wird hier nicht weiter vertieft.

Von großer Bedeutung f¨

ur das Web-Interface ist die Plattformunabh¨

angigkeit.

Darunter soll hier sowohl die Unabh¨

angigkeit vom Client-Betriebssystem als auch

vom verwendeten Browser verstanden werden. Um diese Unabh¨

angigkeit zu errei-

chen, wurde darauf geachtet, dass das Web-Interface mit den g¨

angigen Browsern

funktioniert:

•Internet Explorer 6 und 7

•Mozilla Firefox ab 1.0

•Opera ab 9.0

Bisher wurden allerdings nicht alle Browser/Betriebssystem-Kombinationen ge-

testet.

Da die Browser die Web-Standards nicht immer korrekt implementieren, be-

schr¨

ankt sich das Web-Interface derzeit auf folgende Technologien:

•HTML

•HTML-Formulare

•JavaScript

Sp¨

ater soll noch CSS - Cascading Style Sheets ([CSS])- hinzukommen, um die

Gestaltung des Web-Interface zentral verwalten zu k¨

onnen. Dabei muss besonders

auf Kompatibilit¨

at mit den Browsern geachtet werden.

4.8. WEB-INTERFACE 55

4.8.1 JavaScript

HTML und HTML-Formulare reichen nicht immer aus, um eine Web-basierte Be-

nutzerschnittstelle zu implementieren, da es keine Interaktivit¨

at bietet. Da man

aber oft auf Benutzereingaben reagieren und bestimmte Aktivit¨

aten ausf¨

uhren

muss, kommt man um JavaScript nicht herum. JavaScript ist eine objektba-

sierte Scriptsprache, deren Syntax der von Java ¨

ahnelt. JavaScript-Code kann

entweder direkt in eine HTML-Seite eingebaut oder als Verweis angegeben wer-

den (in diesem Fall wird der Code vom Browser nachgeladen). Ausgef¨

uhrt wird

JavaScript-Code im Webbrowser und hat ¨

uber DOM - Document Object Model

([W3CDOM]) - vollen Zugriff auf die Webseite.

Beispiel f¨

ur eine sinnvolle Anwendung von JavaScript: Der Benutzer w¨

ahlt eine

Bild-Sequenz aus und will alle Kan¨

ale angezeigt bekommen, die zu dieser Sequenz

geh¨

oren. Beim Generieren dieser Seite auf dem Server gibt es keine M¨

oglich-

keit, so etwas zu ber¨

ucksichtigen. Ohne JavaScript m¨

usste nach der Auswahl der

Bild-Sequenz die Seite neu geladen werden, was ein hohes Datenaufkommen und

Verz¨

ogerungen verursachen w¨

urde. Dagegen kann mit JavaScript nach der Selek-

tion der Bild-Sequenz die Liste der Kan¨

ale angefordert werden. Das kann sogar

asynchron geschehen - die Seite wird im Browser nicht blockiert.

Der gr¨

oßte Nachteil von JavaScript ist die Uneinheitlichkeit: Es gibt zwei un-

terschiedliche Implementierungen, eine von Microsoft (Internet Explorer) und

eine von Netscape. Das kann die Entwicklung vom JavaScript-Code erheblich

verkomplizieren. Zum Gl¨

uck gibt es inzwischen eine große Zahl an JavaScript-

Bibliotheken, die diese Unterschiede verbergen und so eine einheitliche Schnitt-

stelle zur Verf¨

ugung stellen.

MochiKit ([MochiKit]) ist eine solche Bibliothek (eine ebenfalls weit verbreitete

ist “prototype” [Prot]), die gut dokumentiert und im Einsatz erprobt ist. Aus

diesem Grund wurde MochiKit f¨

ur das Web-Interface benutzt. Vor allem zwei

Funktionen, die MochiKit anbietet, wurden oft benutzt. Die Funktion $(ID) gibt

das DOM-HTML-Object mit der Id == “ID” zur¨

uck und zwar unabh¨

angig vom

verwendeten Browser. Die zweite Funktion loadJSONDoc(URL) fordert asyn-

chron von der Adresse “URL” ein Json-Dokument an und dekodiert dieses auch

gleich zu einem JavaScript-Objekt.

56 KAPITEL 4. TECHNISCHE UMSETZUNG

MochiKit selbst besteht aus einer einzigen Datei “MochiKit.js”, die unter “ht-

docs/wfms/js” abgelegt wurde. In diesem Verzeichnis liegen noch weitere JavaScript-

Dateien, da der Großteil des JavaScript-Codes nicht direkt in die PSP-Dateien

(zu PSP siehe Kapitel 4.3.5) geschrieben, sondern in Dateien mit der Endung

“.js” untergebracht wurde. Das hat den Vorteil, dass man so den JavaScript-Code

leicht in andere PSP-Dateien importieren kann.

4.8.2 Gestaltung

Um mit dem Web-Interface arbeiten zu k¨

onnen, muss sich der Benutzer zuerst

authentifizieren. Dazu ruft er die Login-Seite “wfms/login” auf (oder jede andere

Seite, die ihn dann auf die Login-Seite umleitet). Falls die Anmeldung fehlschl¨

agt,

Abbildung 4.5: Login-Seite.

landet der Benutzer wieder auf der Login-Seite, die eine entsprechende Meldung

anzeigt (Abbildung 4.6).

Abbildung 4.6: Login-Failed-Seite.

Nach erfolgreicher Anmeldung landet der Benutzer auf der Startseite “wfms/in-

dex” (Abbildung 4.7). Die Anmeldung ist f¨

ur 30 Minuten g¨

ultig, danach wird

4.8. WEB-INTERFACE 57

Abbildung 4.7: Startseite.

man wieder auf die Login-Seite umgeleitet.

Der Inhalt der Startseite h¨

angt davon ab, welche Rollen dem Benutzer zugeordnet

wurden. Zum Beispiel fehlt der Link “Manage label jobs”, wenn dem Benutzer die

Rolle “LabelJobManager” fehlt. Da dieser “Zugriffsschutz” nicht ausreicht (man

kann die entsprechenden Seiten ja auch direkt in der Adressleiste des Browsers

angeben), wird bei jedem Zugriff auf eine Seite zuerst gepr¨

uft, ob der Benutzer

dazu berechtigt ist. Dazu wird ¨

uber den Glue-Server der UserManager kontak-

tiert, der anhand des Benutzernamens und der Rollen des Benutzers entscheidet,

ob der Zugriff gew¨

ahrt wird. Falls der Zugriff verweigert wird, erscheint eine ent-

sprechende Meldung. Zur Zeit ist die Zugriffskontrolle an die Rollen gekn¨

upft,

was nur einen recht groben Zugriffsschutz erlaubt. Sp¨

ater k¨

onnte man auch die

F¨

ahigkeiten hinzunehmen.

Der Click auf den Link “Label Documents” f¨

uhrt auf die Seite “Labeling” (Ab-

bildung 4.8). Um diese Seite aufrufen zu k¨

onnen, braucht der Benutzer die Rolle

“Labeler”. Von hier aus gelangt man auf die Seite f¨

ur den Import von Label-

Abbildung 4.8: Labeln.

58 KAPITEL 4. TECHNISCHE UMSETZUNG

Dokumenten (Abbildung 4.9). Die Rollen “Labeler” und “LabelDocumentMana-

ger” berechtigen einen Benutzer zum Aufruf dieser Seite. ¨

Uber den zweiten Link

Abbildung 4.9: Label-Dokument Import.

“View label jobs” gelangt man auf die Seite f¨

ur den Abruf der Label-Auftr¨

age

(Abbildung 4.10). Voraussetzung daf¨

ur ist die Rolle “Labeler”. Auf dieser Seite

Abbildung 4.10: Label-Auftr¨

age.

kann der Benutzer sowohl die Konfigurationsdatei f¨

ur Lava als auch das Label-

Dokument f¨

ur den Label-Auftrag herunterladen.

Der Link “Manage label jobs” auf der Startseite f¨

uhrt den Benutzer, vorausgesetzt

er verf¨

ugt ¨

uber die Rolle “LabelJobManager”, auf die Seite f¨

ur die Verwaltung

der Label-Auftr¨

age (Abbildung 4.11). Diese Seite besteht aus zwei Teilen: Oben

ist ein Filter, in dem man die Auswahl der unten angezeigten Label-Auftr¨

age ein-

schr¨

anken kann. Unten werden die Label-Auftr¨

age aufgelistet. Mit dem Button

“Delete” k¨

onnen die ausgew¨

ahlten Label-Auftr¨

age (siehe die Checkboxen links

neben den Auftr¨

agen) gel¨

oscht werden. Mit einem Click auf “New” gelangt man

auf die Seite zum Anlegen neuer Label-Auftr¨

age (Abbildung 4.12). Mit einem

4.8. WEB-INTERFACE 59

Abbildung 4.11: Verwaltung der Label-Auftr¨

age.

Abbildung 4.12: Einen neuen Label-Auftrag anlegen.

60 KAPITEL 4. TECHNISCHE UMSETZUNG

Doppelklick auf einen Label-Auftrag ruft man die Seite zum Editieren eines Auf-

trags (entspricht der Abbildung 4.12) auf. F¨

ur das Anlegen neuer Auftr¨

age sowie

das L¨

oschen und Editieren von bestehenden Auftr¨

agen wird ebenfalls die Rolle

“LabelJobManager” vorausgesetzt.

Der Link “Manage detection systems” auf der Startseite f¨

uhrt auf die Seite zum

Verwalten der Erkennungssysteme (Abbildung 4.13). Um diese Seite aufrufen zu

d¨

urfen, ben¨

otigt der Benutzer die Rolle “DetectionSystemManager”.

Abbildung 4.13: Verwaltung der Erkennungssysteme.

Mit “Manage test runs” gelangt man von der Startseite auf die Seite f¨

ur die

Verwaltung der Testl¨

aufe (Abbildung 4.14). Voraussetzung daf¨

ur ist die Rolle

“TestRunManager”.

Auf die Seite f¨

ur die Verwaltung der Bild-Sequenzen gelangt man ¨

uber den Link

“Manage Sequences” (Abbildung 4.15). Hierf¨

ur braucht man die Rolle “Sequence-

Manager”.

Als Letztes kann mit “Access Database” eine Seite aufgerufen werden, auf der

beliebige SQL-Queries abgesetzt werden k¨

onnen. Das Ergebnis wird auf der Seite

in Tabellenform dargestellt. Aus Sicherheitsgr¨

unden d¨

urfen nur Benutzer diese

Seite aufrufen, die ¨

uber die Rolle “DatabaseManager” verf¨

ugen

Den Abbildungen kann man entnehmen, dass das Web-Interface noch sehr schlicht

gehalten ist und kein einheitliches Aussehen hat.

4.8. WEB-INTERFACE 61

Abbildung 4.14: Verwaltung der Testl¨

aufe.

Abbildung 4.15: Verwaltung der Bild-Sequenzen.

62 KAPITEL 4. TECHNISCHE UMSETZUNG

Anzumerken ist noch, dass das Web-Interface nicht die gesamte Funktionalit¨

at ab-

deckt. Vor allem Lava und die ADEPT-Werkzeuge stellen normale GUI-Anwendung-

en dar, deren Funktionalit¨

at aber in Zukunft durchaus in das Web-Interface in-

tegriert werden k¨

onnte. Mit modernen Web 2.0 Technologien wie Ajax ([AJAX])

ist eine Web-basierte L¨

osung f¨

ur das Labeln durchaus denkbar.

4.9 Python-API

Die Python-API befindet sich im Verzeichnis “api/specht”.

Die Python-API kann in vier Bereiche unterteilt werden, die in eigenen Kapiteln

genauer beschrieben werden:

•“DATA” : Zugriff auf die Datenbank

•“USER” : Zugriff auf die Benutzerdaten

•“WFMS” : Zugriff auf die Workflow-Funktionalit¨

•“OTHER” : Sonstige Funktionalit¨

Bis auf eine Ausnahme (SQLObject, siehe Kapitel 4.9.3) kommunizieren alle API-

Komponenten mit dem Glue-Server ¨

uber XML-RPC. Damit kann der Rest des

Systems von den Client-Anwendungen versteckt werden: Diese wissen weder etwas

von PostgreSQL-Server noch “sehen” sie den ADEPT-Server oder die WFMS-

Clients. Auch die Zugriffskontrolle kann hier ansetzen und die Zugriffe filtern.

Es ist allerdings m¨

oglich, dass der Glue-Server in Zukunft zu einem “Flaschen-

hals” wird und so das System ausbremst. Um dem entgegen zu wirken, k¨

onnte

der Glue-Server sp¨

ater auf mehrere Prozesse verteilt werden (seihe Kapitel 4.7).

4.9.1 API-Architektur

Die einzige M¨

oglichkeit mit dem Glue-Server zu kommunizieren ist XML-RPC.

Daf¨

ur exportiert der Glue-Server die Funktion call, die zwei Parameter erh¨

alt:

eine Adresse und eine Liste (Array) mit Parametern. Die Adresse ist von zen-

traler Bedeutung, da dies die einzige M¨

oglichkeit ist, dem Glue-Server zu sagen,

4.9. PYTHON-API 63

an wen er die Anfrage weiterleiten soll. Der Aufbau der Adresse entspricht den

Pfadangaben in UNIX-Systemen: Die Wurzel ist “/”, danach folgt der “Name”

des Managers (eines der Werte “data” f¨

ur DatabaseManager, “other” f¨

ur Other-

Manager, “user” f¨

ur UserManager, “wfms” f¨

ur WFMSManager), der Rest h¨

angt

vom angesprochenen Manager ab (meist steht hier der Name einer Funktion). Die

einzelnen Bestandteile der Adresse werden mit “/” von einander getrennt. Bei-

spiel: “/other/getLavaConfigs” ruft OtherManager.getLavaConfigs() auf. Welche

Eintr¨

age der zweite Parameter enth¨

alt, h¨

angt vom Manager/Funktion ab.

Die vier Manager haben die gleiche Schnittstelle wie der Glue-Server: Jeder von

ihnen hat nur eine nach außen sichtbare Funktion: call. Wenn die call-Methode

des Glue-Servers aufgerufen wird, entfernt diese den Namen des Managers aus

der Adresse und ¨

ubergibt den Rest an die call-Methode des Managers. Der zweite

Parameter wird unver¨

andert weitergegeben. Beispiel:

GlueServer.call(’/other/getLavaConfigs’, param) →

OtherManager.call(’/getLavaConfigs’, param)

Die R¨

uckgabe des Managers wird vom Glue-Server unver¨

andert an den Client

zur¨

uckgegeben.

Alle vier Manager geben grunds¨

atzlich einen Tupel zur¨

uck (als JSON-String en-

kodiert), welcher aus zwei Komponenten besteht: True/False und das eigentliche

Ergebnis oder Fehlermeldung. Falls an erster Stelle False steht, ist ein Fehler

aufgetreten und an der zweiten Stelle steht dann die Fehlermeldung. Ansons-

ten steht an der zweiten Stelle das Ergebnis (das kann eine beliebige Python-

Datenstrucktur sein). Listing 4.8 zeigt ein Beispiel daf¨

ur, wie eine Fehlermeldung

zur¨

uckgegeben wird.

Listing 4.8: R¨

uckgabe einer Fehlermeldung

( False , ’Unknown function ” getLListResult ”! ’ )

4.9.2 GlueServerInterface

Die zentrale Komponente der Python-API ist die Klasse “GlueServerInterface”

(in “api/specht/GlueServerInterface.py”). Mit dieser Klasse kann auf einfache Art

und Weise auf den Glue-Server zugegriffen werden. Einfach eine Instanz erzeu-

gen und entweder die Methode call(param) oder callJson(param) aufrufen. Das

64 KAPITEL 4. TECHNISCHE UMSETZUNG

Besondere an diesen beiden Funktionen ist die Tatsache, dass man mit einem

Aufruf mehrere Anfragen schicken kann. Dazu legt man ein Python-Dictionary

an und erzeugt f¨

ur jeden Aufruf einen Eintrag:

Listing 4.9: Nutzung des GlueServerInterface

g s i = Glu eS er verIn terf ace ( )

param = {’ r e s u l t 1 ’ : [ ’ / data / g et L is tR es ul t / getColorByID ’ ,

{’ id ’ : 1}] ,

’ r e s u l t 2 ’ : [ ’ / other /getLabelDocumentByName ’ ,

{’name ’ : ’NAME’ }]}

r e s u l t = g s i . c a l l ( param)

In diesem Beispiel werden zwei Aufrufe abgesetzt: eine Farbe ¨

uber die ID lesen

und ein Label-Dokument exportieren. Mit den beiden Schl¨

usseln “result1” und

“result2” (die frei gew¨

ahlt werden k¨

onnen) kann das jeweilige Ergebnis gelesen

werden: result[’result1’] oder result[’result2’]. Die Methode call gibt also ein Dic-

tionary zur¨

uck mit den Schl¨

usseln, die im Parameter ¨

ubergeben wurden. Jeder

Schl¨

ussel identifiziert die R¨

uckgabe der jeweiligen Remote-Funktion. Also: result1

identifiziert die R¨

uckgabe der Funktion getColorByID und result2 die R¨

uckga-

be von getLabelDocumentByName. Man kann an diesem Beispiel auch erkennen,

dass meistens ein Dictionary an die Remote-Funktion ¨

ubergebenen wird:

{’id’ : 1}

Die Methode call() kehrt erst zur¨

uck, wenn alle Aufrufe abgearbeitet wurden.

Neben call gibt es noch die Methode callJson, die das Ergebnis als JSON-String

zur¨

uckgibt (wird f¨

ur das Web-Interface ben¨

otigt). Beide verpacken den Parameter

vor dem Verschicken als JSON-String.

4.9.3 DB-API

Die DB-API befindet sich im Verzeichnis “api/specht/db” und kann in zwei Be-

reiche unterteilt werden: die low-level API und die high-level API.

Die low-level API entspricht dem, was oben beschrieben wurde und kann somit

mit Hilfe der GlueServerInterface-Klasse benutzt werden (die Adresse beginnt

4.9. PYTHON-API 65

mit “/data”). Es gibt insgesamt drei M¨

oglichkeiten, auf den DatabaseManager

zuzugreifen:

•SQL-Query wird direkt ¨

ubergeben

•es wird der Name der Datei mit der Query ¨

ubergeben

•es wird eine Methode aufgerufen

Um eine beliebige Query auszuf¨

uhren, steht die Methode getRawResultForQuery

zur Verf¨

ugung. Diese bekommt als Parameter ein Dictionary mit dem Schl¨

ussel

“query” und einen String mit der Query als Wert:

Listing 4.10: Aufruf von getRawResultForQuery

g s i = Glu eS er verIn terf ace ( )

param = {’ r e s u l t ’ : [ ’ /data /getRawResultForQuery ’ ,

{’ query ’ : ’SELECT ∗FROM co lor ’ }]}

r e s u l t = g s i . c a l l ( param)

Es ist klar, dass der Zugriff auf diese Funktion eingeschr¨

ankt werden sollte, da

sonst jeder beliebige Anfragen (auch DELETE) an den SQL-Server schicken kann.

Zum Beispiel k¨

onnte das Recht, diese Funktion auszuf¨

uhren, an die Rolle “Data-

baseManager” gebunden werden.

Die am meisten benutzte Methode mit dem DatabaseManager zu kommunizieren

besteht darin, den Namen einer Datei anzugeben, welche die Query enth¨

alt. Dies

geht allerdings nur indirekt:

Listing 4.11: Aufruf einer Query-Datei

g s i = Glu eS er verIn terf ace ( )

param = {’ r e s u l t ’ : [ ’ /data / g etLi st Re sul t / g etAllCo lors ’ ]}

r e s u l t = g s i . c a l l ( param)

In diesem Beispiel lautet der Name der Datei “getAllColors” (die Endung “.sql”

muss nicht angegeben werden). Die Funktion getListResult ist eine der drei Funk-

tionen, welche die Ergebnis-Tupel aufbereiten:

•getListResult: Ergebnis als Liste von Listen zur¨

uckgeben

66 KAPITEL 4. TECHNISCHE UMSETZUNG

•getDictResult: Ergebnis als Liste von Dictionaries zur¨

uckgeben (jedes Ergebnis-

Tupel ist ein Dictionary mit Attribut-Namen als Schl¨

ussel)

•getRawResult: Ergebnis unver¨

andert zur¨

uckgeben (Liste mit zwei Eintr¨

agen:

der erste Eintrag enth¨

alt die Angaben zu den Attribut-Namen und der zwei-

te die Ergebnis-Tupel)

Die Query-Dateien befinden sich standardm¨

aßig im Verzeichnis “sql/queries”,

dies kann aber ¨

uber die Konfigurationsdatei “sql/sql.cfg” ge¨

andert werden. Die-

ser Ansatz bietet den Vorteil, neue Query-Dateien hinzuf¨

ugen oder vorhandene

anpassen zu k¨

onnen, ohne das System neu starten zu m¨

ussen.

Der Zugriff auf die Query-Dateien kann leicht vom DB-Manager ¨

uberwacht wer-

den, indem f¨

ur jede Datei angegeben wird, welche Rollen/F¨

ahigkeiten den Zugriff

gestatten.

Die dritte M¨

oglichkeit auf den DB-Manager zuzugreifen, besteht darin, eine vor-

gefertigte Funktion aufzurufen. Einige Beispiele: insertNewLabelJob,getAllLabel-

JobsForUser,saveDetectionSystem,saveTestRun.

Neben dieser low-level Schnittstelle, die haupts¨

achlich f¨

ur das Web-Interface be-

nutzt wird, existiert noch eine (noch nicht vollst¨

andige) high-level API. Diese

basiert auf SQLObject ([SQLObj]), einem objektrelationalen Wrapper f¨

ur Py-

thon. SQLObject bildet eine Schicht ¨

uber der SQL-Datenbank und versteckt so

SQL vom Entwickler. Dabei werden Relationen als Klassen repr¨

asentiert und

Tupel als Instanzen dieser Klassen. Dabei wird der Großteil der Flexibilit¨

at der

SQL-Queries bewahrt, so dass man weitgehend auf SQL verzichten kann. Einige

Abstriche muss man aber doch machen: SQLObject unterst¨

utzt keine geometri-

schen Datentypen und greift direkt auf die Datenbank zu. Wenn man also die

Geometrie-Daten der Label verarbeiten will, muss man den Weg ¨

uber die low-

level API gehen.

Wegen SQLObject wurde bei s¨

amtlichen Relationen in der Datenbank ein Prim¨

ar-

schl¨

ussel mit dem Namen “id” vom Typ Integer definiert, der von PostgreSQL

automatisch hochgez¨

ahlt wird. Der Grund daf¨

ur ist, dass SQLObject bei allen Re-

lationen einen einfachen (also nicht aus mehreren Attributen zusammengef¨

ugten)

Prim¨

arschl¨

ussel vom Typ Integer erwartet. Zus¨

atzlich m¨

ussen Fremdschl¨

ussel mit

“id” enden, zum Beispiel “frame id”.

4.9. PYTHON-API 67

Der direkte Zugriff von SQLObject auf die Datenbank (¨

uber psycopg) stellt ein

ernstes Problem dar, da keine Zugriffskontrolle realisiert werden kann. Als Kom-

promiss wurde beschlossen, f¨

ur SQLObject einen Datenbank-Benutzer anzulegen,

der nur lesenden Zugriff auf die Relationen hat. S¨

amtliche Schreibzugriffe wer-

den als Methoden implementiert, die ¨

uber die low-level API auf die Datenbank

zugreifen, wo die Zugriffskontrolle stattfinden kann (siehe Kapitel 5.2.2).

Eine ¨

Ubersicht ¨

uber die high-level API gibt die Abbildung 4.16.

Abbildung 4.16: SQLObject: Integration.

4.9.4 User Management API

F¨

ur den Zugriff auf die Benutzerdaten steht der “Adressraum” “/user/*” zur

Verf¨

ugung. Der Aufruf einer Funktion erfolgt genauso wie bei der low-level DB-

API.

Die User-API bietet folgende Funktionen an:

•getAllLabeler - gibt alle zum Labeln berechtigte Benutzer zur¨

uck

•getAllLabelManager - gibt alle Benutzer zur¨

uck, die Label-Auftr¨

age verwal-

ten d¨

urfen

68 KAPITEL 4. TECHNISCHE UMSETZUNG

•getAllRolesForUser - gibt alle Rollen f¨

ur den angegebenen Benutzer zur¨

uck

•canAccess* - eine Reihe von Funktionen, die pr¨

ufen, ob ein Benutzer Zugriff

auf bestimmte Funktionalit¨

at hat

Die canAccess* -Funktionen:

•canAccessLabelJobManagement

•canAccessDetectionSystemManagement

•canAccessTestRunManagement

•canAccessMachineManagement

•canAccessLabelDocumentManagement

•canAccessDatabaseManagement

•canAccessSequenceManagement

Diese Funktionen werden zum Beispiel vom Web-Interface benutzt um zu pr¨

ufen,

ob ein Benutzer eine bestimmte Seite aufrufen darf.

4.9.5 WFMS-API

Die WFMS-API besteht derzeit aus einer einzigen Funktion: sendMessageTo. Mit

dieser Funktion kann eine Nachricht an einen WfMS-Client geschickt werden.

Wichtig ist dabei die Adressierung: “/wfms/sendMessageTo/USERNAME/CLI-

ENTNUMMER”, also zum Beispiel “/wfms/sendMessageTo/Johann Specht/1”.

Als Parameter erwartet sendMessageTo ein Dictionary mit zwei Eintr¨

agen: Typ

der Nachricht und die Nachricht selbst. Beispiel:

Listing 4.12: Parameter f¨

ur sendMessageTo

{’msgType ’ : ’ERROR’ ,

’msg ’ : ’ Configuration f i l e not found ! ’ }

4.9. PYTHON-API 69

Neben “ERROR” gibt es noch “FAILED”, “TERMINATE” (zwingt einen WfMS-

Client sich zu beenden), “RESULT” und “CMD” als Nachrichtentyp. Mit “CMD”

k¨

onnen Kommandos wie “START CLIENT” (wird intern benutzt) verschickt

werden, “RESULT” wird angegeben wenn das Ergebnis eines Testlaufs einge-

schickt wird.

4.9.6 Other-API

F¨

ur die Funktionalit¨

at, die keinem anderen Manager zugeordnet ist, steht der

OtherManager zur Verf¨

ugung. Er bietet folgende vier Funktionen an:

•getLavaConfigs - gibt eine Liste mit allen bekannten Lava-Konfigurationen

zur¨

uck

•getLavaConfigurationByPath - liefert die angeforderte Lava-Konfiguration

•getLabelJobDocumentById - generiert ein Label-Dokument f¨

ur einen Label-

Auftrag

•getLabelDocumentByName - liefert das angeforderte Label-Dokument

Kapitel 5

Modellierung der Daten und

Prozesse

In diesem Kapitel wird es vor allem um die Modellierung der Daten (Kapitel 5.3)

und der Prozesse (Kapitel 5.4) gehen, zuerst aber werden noch die Benutzerver-

waltung (Kapitel 5.1) und die Zugriffsrechte (Kapitel 5.2) behandelt.

5.1 Benutzerverwaltung

Das als WfMS-Server eingesetzte ADEPT bringt bereits eine eigene Benutzerver-

waltung mit, die in diesem Kapitel kurz vorgestellt werden soll.

Genau genommen bietet ADEPT mehr als nur Benutzerverwaltung. Man kann

n¨

amlich auch Organisationsstrukturen, F¨

ahigkeiten, Rollen und Beziehungen zwi-

schen Mitarbeitern verwalten. Die Abbildung 5.1 zeigt Entities der Benutzerver-

waltung und deren Beziehungen untereinander.

Der Organisationstyp gibt an, um was f¨

ur eine Organisationseinheit es sich han-

delt, einige Beispiele: “Abteilung” oder “Niederlassung”. Die Organisationsein-

heit ist dann eine bestimmte Auspr¨

agung eines Organisationstyps, zum Beispiel

“Abteilung Informationssysteme“ oder “Niederlassung Ulm”. Der Organisations-

typ kann neben einem Namen noch ¨

uber Rollen verf¨

ugen. F¨

ur eine Organisations-

einheit kann eine Stelle angegeben werden, die den Leiter dieser Einheit definiert.

5.1. BENUTZERVERWALTUNG 71

Abbildung 5.1: Organisation der Benutzerverwaltung.

Die n¨

achst kleinere Einheit ist die Stelle. Eine Stelle kann einer Organisations-

einheit zugeordnet werden, dar¨

uber hinaus kann eine Rolle angegeben werden.

Eine Stelle kann einen disziplinarischen und einen fachlichen Vorgesetzten haben.

Wichtig ist auch die M¨

oglichkeit, eine Stelle mit einem Mitarbeiter zu besetzen

oder von einem Mitarbeiter vertreten zu lassen.

Ein Mitarbeiter kann mehrere F¨

ahigkeiten und Rollen besitzen und eine Stel-

le besetzen oder vertreten. Einer Rolle k¨

onnen mehrere F¨

ahigkeiten zugeordnet

werden, wobei die Zuweisung einer Rolle auch die entsprechenden F¨

ahigkeiten

vererbt.

Damit verf¨

ugt ADEPT bereits ¨

uber eine recht leistungsf¨

ahige Benutzerverwal-

tung. Es fehlt allerdings die M¨

oglichkeit, Projekte zu definieren und diesen Mit-

arbeiter zuzuordnen.

Im Kapitel 3.3.1 wurde bereits die Frage diskutiert, wie man auf der Kommando-

zeile feststellen kann, um welchen Benutzer es sich handelt. Dazu muss das System

den UNIX-Namen des Benutzers auf den ADEPT-Namen abbilden k¨

onnen. Die

sicherste L¨

osung w¨

are die Angabe des UNIX-Namens beim Anlegen des Benut-

zers in ADEPTOrgManager. Das einzige Attribut, das daf¨

ur in Frage kommt, ist

wohl das Eingabefeld “Beschreibung des Mitarbeiters”, das eigentlich f¨

ur einen

Kommentar gedacht ist.

Eine vermutlich bessere L¨

osung ist die Nutzung des gleichen Namens f¨

ur beide

Namensr¨

aume, was auf den UNIX-Namen hinausl¨

auft. Dazu gibt man im Feld

72 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

“Name” beim Anlegen eines neuen Benutzers den UNIX-Namen an und das Feld

f¨

ur den Vornamen bleibt leer.

5.2 Zugriffsrechte

Wie die Zugriffskontrolle f¨

ur das Web-Interface realisiert wurde, ist bereits in

Kapitel 4.8.2 besprochen worden. Hier soll die Zugriffskontrolle auf dem Level

der Python-API thematisiert werden.

5.2.1 Low-level DB-API

Die Implementierung der low-level DB-API wurde im Kapitel 4.9.3 besprochen.

Vor allem wurden dort die drei M¨

oglichkeiten vorgestellt, auf die Daten zuzugrei-

fen. Die gef¨

ahrlichste Methode ist die ¨

Ubergabe der SQL-Query an das System.

Der Zugriff auf diese Methode sollte auf die Rolle “DatabaseManager” beschr¨

ankt

werden.

Die zweite M¨

oglichkeit auf die Daten zuzugreifen besteht darin, den Namen einer

Datei mit der Query anzugeben. Hier kann der Zugriff sehr fein eingeschr¨

ankt

werden, indem f¨

ur jede Datei angegeben wird, welche Rollen oder F¨

ahigkeiten

ein Benutzer besitzen muss, um die Datei benutzen zu d¨

urfen. Man k¨

onnte sogar

einzelnen Benutzern Zugriff gew¨

ahren. Es l¨

auft also auf ACL (Access Control

List) hinaus. Die Zugriffsrechte k¨

onnen problemlos in der Datenbank gespeichert

werden.

Das Gleiche gilt auch f¨

ur die dritte Methode: Aufruf von Methoden der Klasse

DatabaseManager. Nur sind hier die Methoden die Entities, f¨

ur die Zugriffsrechte

definiert werden.

5.2.2 High-level DB-API

Die high-level DB-API baut auf SQLObject ([SQLObj], siehe Kapitel 4.9.3) auf,

welches direkt auf die Datenbank zugreift. Dieser direkte Zugriff stellt ein ernstes

Problem dar, weil damit jeder Benutzer automatisch vollen Zugriff auf die Da-

5.2. ZUGRIFFSRECHTE 73

ten bekommt. Da aber nicht auf SQLObject verzichtet werden kann, muss eine

L¨

osung gefunden werden.

Eine M¨

oglichkeit w¨

are eine Art Proxy, welcher zwischen SQLObject und Post-

greSQL geschaltet wird und auf SQL-Ebene die Zugriffe filtert. Diese L¨

osung ist

allerdings nicht praktikabel, da es viel zu aufwendig ist, auf SQL-Ebene zu filtern.

Als Kompromiss wurde folgende L¨

osung gew¨

ahlt: SQLObject verwendet einen

Benutzer, der nur lesenden Zugriff auf s¨

amtliche Daten hat. Alle Operationen,

die Schreibzugriff erfordern, werden als Methoden der entsprechenden Klassen

implementiert, die den Weg ¨

uber die low-level API gehen.

5.2.3 Benutzerverwaltungs-API

Der Zugriff auf die Benutzerverwaltungs-API (oder kurz User-API) ist auf das

System beschr¨

ankt, da die Benutzer keinen Zugriff ben¨

otigen. Wenn allerdings

in einer sp¨

ateren Implementierung die Benutzerverwaltung in das Web-Interface

und in die API integriert wird, muss der Zugriff auf die Funktionen der User-API

kontrolliert werden. Dies kann auf die gleiche Art geschehen, wie bei der DB-API.

5.2.4 WFMS-API

Die einzige Funktion, die diese API zur Zeit bietet, ist sendMessageTo, mit der

Nachrichten an einen WfMS-Client geschickt werden k¨

onnen. Das Versenden von

Nachrichten sollte sinnvollerweise dem Benutzer erlaubt sein, dem dieser Client

geh¨

ort. Das kann der WfMSManager leicht pr¨

ufen.

5.2.5 Other-API

Diese API bietet folgende vier Funktionen an:

•getLavaConfigs

•getLavaConfigurationByPath

•getLabelJobDocumentById

74 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

•getLabelDocumentByName

Die ersten beiden Funktionen sind nicht kritisch, da sie nur lesenden Zugriff bieten

und keine sensitiven Daten liefern.

Die anderen beiden Funktionen bieten zwar ebenfalls nur lesenden Zugriff, aber es

sollte trotzdem nicht jeder alle Label-Dokumente bzw. Label-Jobs lesen d¨

urfen.

Der Zugriff auf die Label-Jobs kann auf den Betreuer und den Bearbeiter be-

schr¨

ankt werden. Bei Label-Dokumenten ist es etwas komplizierter: Die Bear-

beiter k¨

onnen auf jeden Fall lesenden Zugriff bekommen. Zus¨

atzlich bekommt

der jeweilige Betreuer auch Schreibzugriff genauso wie Benutzer mit der Rolle

“LabelDocumentManager”.

5.3 Datenverwaltung

Als erstes wird in diesem Kapitel beschrieben, nach welchen allgemeinen Regeln

die Relationen angelegt wurden. Danach wird analysiert, welche Daten genau ver-

waltet werden m¨

ussen und wo sie am sinnvollsten untergebracht werden k¨

onnen.

Und schließlich werden die Relationen vorgestellt.

5.3.1 SQL-Relationen

Da SQL nicht zwischen Groß- und Kleinschreibung unterscheidet, werden die Na-

men der Relationen und der Attribute klein geschrieben. Bei zusammengesetz-

ten Namen wird zwischen den einzelnen W¨

ortern ein Unterstrich gesetzt: “se-

quence channel” oder “sequence channel id”. Nur englische Bezeichnungen wer-

den benutzt. Es wird Wert darauf gelegt, Attribute oder Attribut-Kombinationen,

deren Werte nur einmal pro Relation vorkommen k¨

onnen, mit “UNIQUE” zu

kennzeichnen: “UNIQUE (category id, sequence id)”. Damit werden mehrfache

Vorkommen eines Wertes verhindert und der Datenbankserver kann eventuell

zus¨

atzliche Optimierungen vornehmen.

Bei schwachen Entities wird immer “ON DELETE CASCADE” f¨

ur die Fremd-

schl¨

ussel der ¨

ubergeordneten Relationen angegeben, damit keine Inkonsistenzen

entstehen. Bei sonstigen Fremdschl¨

usseln wird immer “ON DELETE SET NULL”

5.3. DATENVERWALTUNG 75

angegeben, damit immer entweder ein g¨

ultiger Fremdschl¨

ussel oder NULL im ent-

sprechenden Attribut steht.

Fremdschl¨

ussel bekommen den Namen der Relation und des Attributs, auf den

sie verweisen: “frame id”. Jede Relation hat als prim¨

aren Schl¨

ussel das Attribut

mit dem Namen “id” vom Typ “SERIAL” (wird automatisch hochgez¨

ahlt). Es

gibt somit keine zusammengesetzten Prim¨

arschl¨

ussel. Dies wurde vor allem im

Hinblick auf SQLObject so festgelegt (siehe 4.9.3).

Es wurde Wert auf die Einhaltung der ersten drei Normalformen ([ElNa02, Ka-

pitel 14.3.2 bis 14.3.4]) gelegt (1NF, 2NF, 3NF) um Anomalien wie “Einf¨

uge-

Anomalie”, “L¨

osch-Anomalie” oder “¨

Anderungs-Anomalie” und Inkonsistenzen

zu vermeiden. F¨

ur die ersten zwei Normalformen ist dies auch gew¨

ahrleistet,

da die Relationen keine mehrwertigen Attribute haben und alle Prim¨

arschl¨

ussel

nicht zusammengesetzt sind. Die Einhaltung der 3NF wird an entsprechenden

Stellen in diesem Kapitel diskutiert. An dieser Stelle noch kurz die Definition der

“Transitiven Abh¨

angigkeit” (siehe [ElNa02, Seite 524]), die ben¨

otigt wird, um die

Einhaltung der 3NF zu beurteilen:

“ Eine funktionale Abh¨

angigkeit X →Y in einem Relationsschema R ist eine

transitive Abh¨

angigkeit, wenn es eine Attributmenge Z enth¨

alt, die weder ein

Kandidatenschl¨

ussel noch eine Teilmenge eines Schl¨

ussels von R ist, und wenn

sowohl X →Z als auch Z →Y gilt. ” Beim Vorliegen einer transitiven Abh¨

angig-

keit ist eine Relation nicht in der dritten Normalform.

F¨

ur einige Attribute (wie Farbe, Priorit¨

at, Tag) wurden eigene Relationen an-

gelegt, die die m¨

oglichen Werte aufnehmen. Die anderen Relationen verweisen

uber den Fremdschl¨

ussel auf diese Werte. Damit soll erzwungen werden, dass nur

dem System bekannte Werte angegeben werden k¨

onnen. Man kann zum Beispiel

keine Priorit¨

at f¨

ur einen Testlauf angeben, die nicht in der Tabelle “priority”

existiert. Um das noch zu versch¨

arfen, kann der Schreibzugriff auf diese Relatio-

nen eingeschr¨

ankt werden. Alle diese Tabellen bestehen nur aus zwei Attributen:

Prim¨

arschl¨

ussel “id” und “name” als String, damit sind sie in der 3NF. Der

Nachteil dieser L¨

osung ist allerdings die erh¨

ohte Komplexit¨

at der SQL-Queries,

da zus¨

atzliche Joins ben¨

otigt werden (wenn zum Beispiel die Farbe eines Labels

im Ergebnistupel erscheinen soll), und somit auch eine l¨

angere Laufzeit. Da aber

alle diese Tabellen nicht viele Tupels enthalten, f¨

allt das nicht sehr ins Gewicht.

76 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

5.3.2 Bild-Sequenzen

Den mit Abstand gr¨

oßten Teil der Daten stellen die Bild-Sequenzen dar (siehe

2.1.1). Der eigentliche Inhalt, die Bilddaten der Tiff-Bilder, ist aus Sicht eines

Datenbankmanagementsystems ein Strom von Bin¨

ardaten. Sinnvolle Abfragen

dieser Daten mit SQL-Queries w¨

aren nur m¨

oglich, wenn man diese Daten inter-

pretieren w¨

urde, was aber kein DBMS kann. Man m¨

usste also vor dem Import

der Bilddaten diese auswerten und dann in die Datenbank importieren. Dazu

k¨

onnen die Tags, die in den Tiff-Bildern enthalten sein k¨

onnen, herausgelesen

und in die DB geschrieben werden, was SQL-Abfragen die M¨

oglichkeit geben

w¨

urde, diese Tags abzufragen. Die eigentlichen Pixel-Daten k¨

onnten als BLOB

in die DB geschrieben werden, was aber nicht sinnvoll ist, da Bin¨

ardaten nicht

sinnvoll abgefragt werden k¨

onnen.

Als Kompromiss wurde eine gemischte L¨

osung gew¨

ahlt: Die eigentlichen Bilder

verbleiben im Dateisystem und Verwaltungsinformationen wandern in die DB.

Die Tags wurden nicht ausgewertet, was aber in Zukunft durchaus nachgeholt

werden kann.

Bild-Sequenzen k¨

onnen zu Gruppen zusammengefasst werden, wobei eine Se-

quenz mehreren Gruppen angeh¨

oren und eine Gruppe mehrere Sequenzen ent-

halten kann (die Kardinalit¨

at ist also n:m). Beim Import von Bild-Sequenzen wird

automatisch das sechsstellige Aufnahmedatum (siehe Abbildung 2.2) als Grup-

pe genommen. Die Gruppen (oder auch Kategorien, “group” ist ein reserviertes

Wort in SQL) werden in der Tabelle “category” gespeichert (3NF):

Listing 5.1: Relation “category”

CREATE TABLE category (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(256) UNIQUE NOT NULL )

Die Zuordnung einer Bild-Sequenz zu Kategorien erfolgt in der Relation “se-

quence category” (3NF):

5.3. DATENVERWALTUNG 77

Listing 5.2: Relation “sequence category”

CREATE TABLE sequence category (

id SERIAL NOT NULL PRIMARY KEY,

ca t egory id INTEGER REFERENCES category ( id )

ON DELETE CASCADE,

sequence id INTEGER REFERENCES sequence ( id )

ON DELETE CASCADE,

UNIQUE ( category id , sequence id ) )

Das Paar “category id, sequence id” ist ein Kandidatenschl¨

ussel und deswegen als

unique markiert. Diese Relation ist in der 3NF, da es keine transitive Abh¨

angig-

keiten gibt.

Folgende Informationen sind bei Bild-Sequenzen wichtig: Name, Pfad und Zeit-

punkt des Imports. Daraus ergibt sich eine einfache Tabelle:

Listing 5.3: Relation “sequence”

CREATE TABLE sequence (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(256) UNIQUE NOT NULL,

path VARCHAR(1024) ,

imported TIMESTAMP DEFAULT CURRENTTIMESTAMP )

Wie man sehen kann kann der Zeitpunkt des Imports (Attribut “imported”) au-

tomatisch von PostgreSQL gesetzt werden. Attribut “name” ist hier ein Schl¨

ussel-

kandidat, da eindeutig. Diese Relation ist ebenfalls in der 3NF.

Die Kan¨

ale der Bild-Sequenzen werden in der Relation “sequence channel” ge-

speichert (in 3NF wie auch die restlichen Relationen in diesem Kapitel):

Listing 5.4: Relation “sequence channel”

CREATE TABLE sequence channel (

id SERIAL NOT NULL PRIMARY KEY,

sequence id INTEGER REFERENCES sequence ( id )

ON DELETE CASCADE,

name VARCHAR(256) NOT NULL,

UNIQUE( sequence id , name) )

78 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

Die Kardinalit¨

at hier ist 1:n, da ein Kanal immer zu einer Sequenz geh¨

ort und

eine Sequenz beliebig viele Kan¨

ale enthalten kann. Das Paar “sequence id, name”

ist ein Kandidatenschl¨

ussel und deswegen unique.

Die Informationen zu einzelnen Bildern/Frames werden in der Relation “frame”

abgelegt (3NF):

Listing 5.5: Relation “frame”

CREATE TABLE frame (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(256) NOT NULL,

time stamp TIMESTAMP DEFAULT NULL )

Bisher wurde hier nur der Name des Frames und Zeitpunkt der Aufnahme (mi-

krosekunden genau) gespeichert. Letzterer wird beim Import einer Bild-Sequenz

aus dem Frame-Namen extrahiert und kann sp¨

ater in Queries benutzt werden.

Die Zuordnung der Frames zu Kan¨

alen erfolgt ¨

uber die Relation “frame to channel”

(3NF):

Listing 5.6: Relation “frame to channel”

CREATE TABLE frame to channel (

id SERIAL NOT NULL PRIMARY KEY,

frame id INTEGER REFERENCES frame ( id )

ON DELETE CASCADE,

sequence channel id INTEGER

REFERENCES sequence channel ( id )

ON DELETE CASCADE,

UNIQUE ( frame id , sequence channel id ) )

Der Grund f¨

ur diese zus¨

atzliche Relation, ist der Wunsch ein Frame auch mehre-

ren Kan¨

alen bzw. Sequenzen zuordnen zu k¨

onnen. Damit kann man zum Beispiel

“virtuelle” Bild-Sequenzen zusammenstellen, die Frames mit bestimmten Eigen-

schaften enthalten. Daraus ergibt sich eine Kardinalit¨

at von n:m.

Dar¨

uber hinaus existieren noch einige Relationen, die die Tags und Kommentare

f¨

ur Bild-Sequenzen, Kan¨

ale und Frames aufnehmen (Kardinalit¨

at 1:n). Es ist klar,

dass Tags und Kommentare schwache Entities sind.

5.3. DATENVERWALTUNG 79

Listing 5.7: Relation “sequence tag”

CREATE TABLE sequence tag (

id SERIAL NOT NULL PRIMARY KEY,

sequence id INTEGER REFERENCES sequence ( id )

ON DELETE CASCADE,

tag id INTEGER REFERENCES tag ( id )

ON DELETE CASCADE,

UNIQUE ( sequence id , t a g i d ) )

Listing 5.8: Relation “sequence comment”

CREATE TABLE sequence comment (

id SERIAL NOT NULL PRIMARY KEY,

sequence id INTEGER REFERENCES sequence ( id )

ON DELETE CASCADE,

comment VARCHAR(1024) )

Die nachfolgenden Relationen enthalten einen Fremdschl¨

ussel mit dem Namen

“label document id”. Der Grund daf¨

ur ist, dass die Tags und Kommentare f¨

Kan¨

ale und Frames aus Label-Dokumenten stammen k¨

onnen und somit die Not-

wendigkeit besteht, das entsprechende Label-Dokument zu referenzieren. Die Kar-

dinalit¨

at hier ist ebenfalls 1:n (Label-Dokument kann h¨

ochstens einmal angegeben

werden).

Listing 5.9: Relation “sequence channel tag”

CREATE TABLE sequence channel tag (

id SERIAL NOT NULL PRIMARY KEY,

sequence channel id INTEGER

REFERENCES sequence channel ( id )

ON DELETE CASCADE,

tag id INTEGER REFERENCES tag ( id )

ON DELETE CASCADE,

label document id INTEGER REFERENCES label document ( id )

ON DELETE SET NULL,

UNIQUE ( sequence channel id , label document id , tag id ) )

80 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

Listing 5.10: Relation “sequence channel comment”

CREATE TABLE sequence channel comment (

id SERIAL NOT NULL PRIMARY KEY,

sequence channel id INTEGER

REFERENCES sequence channel ( id )

ON DELETE CASCADE,

label document id INTEGER REFERENCES label document ( id )

ON DELETE SET NULL,

comment VARCHAR(1024) )

Listing 5.11: Relation “frame tag”

CREATE TABLE frame tag (

id SERIAL NOT NULL PRIMARY KEY,

frame id INTEGER REFERENCES frame ( id )

ON DELETE CASCADE,

label document id INTEGER REFERENCES label document ( id )

ON SET NULL,

tag id INTEGER REFERENCES tag ( id )

ON DELETE CASCADE,

UNIQUE ( frame id , label document id , ta g id ) )

Listing 5.12: Relation “frame comment”

CREATE TABLE frame comment (

id SERIAL NOT NULL PRIMARY KEY,

frame id INTEGER REFERENCES frame ( id )

ON DELETE CASCADE,

label document id INTEGER REFERENCES label document ( id )

ON DELETE SET NULL,

comment VARCHAR(1024) )

5.3.3 Label-Dokumente, Label

F¨

ur die Speicherung der Label-Dokumente ist die Relation “label document” vor-

gesehen:

5.3. DATENVERWALTUNG 81

Listing 5.13: Relation “label document”

CREATE TABLE label document (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(256) ,

sequence channel id INTEGER REFERENCES

sequence channel ( id )

ON DELETE SET NULL,

c f g f i l e m d 5 CHAR(32) NULL,

c f g f i l e n a m e VARCHAR(256) NULL,

c f g f i l e p a t h VARCHAR(1024) NULL,

p r e v l a b e l f i l e m d 5 CHAR(32) NULL,

p r e v l a b e l f i l e n a m e VARCHAR(256) NULL,

p r e v l a b e l f i l e p a t h VARCHAR(1024) NULL,

user name VARCHAR(64) NULL,

app version INTEGER NULL,

app name VARCHAR(32) NULL,

format version INTEGER NULL,

format name VARCHAR(32) NULL,

document date TIMESTAMP

DEFAULT CURRENTTIMESTAMP )

Wie man sieht wird ein Label-Dokument nicht als schwache Entity (abh¨

angig vom

Kanal) gespeichert. Damit wird verhindert, dass beim L¨

oschen der zugeh¨

origen

Bild-Sequenz/Kanals das Label-Dokument auch gel¨

oscht wird. Das macht inso-

fern Sinn, als dass die Bild-Sequenz noch im Dateisystem vorhanden sein kann

und Label-Dokumente nicht ungefragt gel¨

oscht werden d¨

urfen. Das Attribut “do-

cument date“ nimmt das Datum, welches im Label-Dokument gespeichert ist,

auf. Es enth¨

alt also nicht den Zeitpunkt des Imports.

Die Label-Daten werden in der Relation “label” gespeichert:

82 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

Listing 5.14: Relation “label”

CREATE TABLE l a b e l (

id SERIAL NOT NULL PRIMARY KEY,

parent id INTEGER REFERENCES l a be l ( id )

ON DELETE CASCADE,

t r a c k i d VARCHAR(64) NOT NULL,

label document id INTEGER REFERENCES label document ( id )

ON DELETE CASCADE,

frame id INTEGER REFERENCES frame ( id )

ON DELETE SET NULL,

l a b e l t y p e i d INTEGER REFERENCES l a b e l t y p e ( id )

ON DELETE SET NULL,

c o l o r i d INTEGER REFERENCES color ( id )

ON DELETE SET NULL,

point data POINT DEFAULT NULL,

box data BOX DEFAULT NULL,

path data PATH DEFAULT NULL,

polygon data POLYGON DEFAULT NULL )

Da ein Label-Dokument beliebig viele Label enthalten kann und ein Label immer

zu einem Label-Dokument geh¨

ort, ergibt sich eine Kardinalit¨

at von 1:n.

Wichtig bei dieser Relation sind vor allem die vier Attribute “point data”, “box

data”, “path data” und “polygon data”, die alle der Aufnahme der geometrischen

Daten dienen. Eigentlich w¨

urde daf¨

ur ein Attribut reichen (wenn man “POLY-

GON” als Datentyp nimmt), allerdings w¨

urde man dabei die Label alle gleich

behandeln, unabh¨

angig davon ob es Rechtecke, Punkte oder Polygone sind. Post-

greSQL bietet aber f¨

ur alle diese Datentypen spezifische Operationen und Funk-

tionen an. Zum Beispiel kann mit dem Operator “&&” gepr¨

uft werden, ob sich

zwei Rechtecke schneiden. Mit area(object) kann die Fl¨

ache eines Rechtecks be-

rechnet werden. Aus diesem Grund gibt es vier Attribute, die folgendermaßen

benutzt werden:

•“point data” f¨

ur Punkte

•“box data” f¨

ur Rechtecke

5.3. DATENVERWALTUNG 83

•“path data” f¨

ur offene Polygone und Freihandwerkzeug

•“polygon data” f¨

ur geschlossene Polygone

Diese Unterscheidung erschwert leider das Schreiben von Queries, da man bei je-

dem Tupel wissen muss, welches dieser vier Attribute das richtige ist. Es erm¨

oglicht

aber die Nutzung des gesamten Vorrats an Operatoren und Funktionen. Um fest-

zustellen von welchem Typ ein Label ist, kann das Attribut “label type id” ab-

gefragt werden.

Auch Label-Dokumente und Label k¨

onnen mit Tags und Kommentaren versehen

sein (beides steht im Label-Dokument), welche in diesen Relationen gespeichert

werden (schwache Entities, 1:n, 3NF):

Listing 5.15: Relation “label document tag”

CREATE TABLE label document tag (

id SERIAL NOT NULL PRIMARY KEY,

label document id INTEGER REFERENCES label document ( id )

ON DELETE CASCADE,

tag id INTEGER REFERENCES tag ( id )

ON DELETE CASCADE,

UNIQUE ( label document id , t ag id ) )

Listing 5.16: Relation “label document comment”

CREATE TABLE label document comment (

id SERIAL NOT NULL PRIMARY KEY,

label document id INTEGER REFERENCES label document ( id )

ON DELETE CASCADE,

comment VARCHAR(1024) )

84 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

Listing 5.17: Relation “label tag”

CREATE TABLE l a b e l t a g (

id SERIAL NOT NULL PRIMARY KEY,

l a b e l i d INTEGER REFERENCES l a be l ( id )

ON DELETE CASCADE,

tag id INTEGER REFERENCES tag ( id )

ON DELETE CASCADE,

UNIQUE ( l a b e l i d , t ag i d ) )

Listing 5.18: Relation “label comment”

CREATE TABLE label comment (

id SERIAL NOT NULL PRIMARY KEY,

l a b e l i d INTEGER REFERENCES l a be l ( id )

ON DELETE CASCADE,

comment VARCHAR(1024) )

Alle vier Relationen enthalten schwache Entities, die automatisch gel¨

oscht wer-

den, wenn das zugeh¨

orige Label-Dokument oder Label gel¨

oscht wird.

5.3.4 Label-Auftr¨

age

F¨

ur die Speicherung der Label-Auftr¨

age (oder auch Label-Jobs) ist die Relation

“label job” vorgesehen:

5.3. DATENVERWALTUNG 85

Listing 5.19: Relation “label job”

CREATE TABLE l a b e l j o b (

id SERIAL NOT NULL PRIMARY KEY,

sequence channel id INTEGER

REFERENCES sequence channel ( id )

ON DELETE SET NULL,

l a b e l e r VARCHAR(256) NOT NULL,

manager VARCHAR(256) NOT NULL,

l a v a c o n f i g u r a t io n VARCHAR(2048) ,

deadline DATE,

p r i o r i t y i d INTEGER REFERENCES p r i o r i t y ( id )

ON DELETE SET NULL,

j o b s t a t e i d INTEGER REFERENCES j o b s t a t e ( id )

ON DELETE SET NULL,

comment VARCHAR(4096) ,

label document id INTEGER REFERENCES label document ( id )

ON DELETE SET NULL )

Ein Label-Auftrag bezieht sich immer auf genau ein Kanal und f¨

ur ein Kanal

k¨

onnen mehrere Label-Auftr¨

age existieren, es ist also eine 1:n Beziehung.

Das Attribut “labeler” nimmt den Namen des Bearbeiters auf und das Attri-

but “manager” den Namen des Betreuers. Das Attribut “deadline” gibt an, bis

wann der Bearbeiter fertig sein muss. Zus¨

atzlich kann ein Auftrag priorisiert wer-

den (“priority id”). Der Status eines Auftrags wird im Attribut “’job state id”

gespeichert. Wenn der Bearbeiter das Ergebnis einschickt, wird die ID des ent-

sprechenden Label-Dokuments im Attribut “label document id” gespeichert.

5.3.5 Erkennungssysteme

Im Kapitel 2 wurde bereits erw¨

ahnt, dass ein Erkennungssystem durch eine

ausf¨

uhrbare Datei und eine/mehrere Konfigurationsdateien definiert wird. Erste-

re enth¨

alt Bin¨

arcode und ist somit aus Sicht eines DBMS ein BLOB. Die Kon-

figurationsdateien haben leider keine einheitliche Struktur und k¨

onnen deswegen

schlecht auf Relationen abgebildet werden. Aus diesem Grund werden sowohl

die ausf¨

uhrbaren Dateien als auch die Konfigurationsdateien nicht direkt in der

86 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

Datenbank abgelegt. Stattdessen wird f¨

ur jedes Erkennungssystem ein Unterver-

zeichnis in einem System-Verzeichnis (ist ¨

uber die Konfigurationsdatei “sql/s-

ql.cfg”einstellbar) erstellt. Anschließend werden die Dateien dorthin kopiert und

MD5-Summen f¨

ur diese berechnet. Am Schluss werden die Namen der Dateien

zusammen mit den MD5-Summen in der Datenbank abgelegt.

Die MD5-Summen sind dazu da, ¨

Anderungen an den Dateien festzustellen. Die

Notwendigkeit daf¨

ur leitet sich aus der Feststellung ab (Kapitel 2), dass jede

Anderung eines Bestandteils eines Erkennungssystems ein neues Erkennungssys-

tem hervorbringt. Falls also eine solche ¨

Anderung festgestellt wird , kann sie vom

System gemeldet werden.

F¨

ur die Speicherung der Erkennungssysteme sind folgende Relationen vorgesehen

(dsystem steht f¨

ur “Detection System”):

Listing 5.20: Relation “dsystem”

CREATE TABLE dsystem (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(256) UNIQUE,

path VARCHAR(1024) ,

executable name VARCHAR(1024) ,

executable md5 VARCHAR(32) ,

d e s cr i p t i o n VARCHAR(1024) ,

imported TIMESTAMP DEFAULT CURRENTTIMESTAMP )

Listing 5.21: Relation “dsystem config file”

CREATE TABLE d s y s t e m c o n f i g f i l e (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(64) NOT NULL,

path VARCHAR(1024) ,

md5 VARCHAR(32) ,

dsystem id INTEGER REFERENCES dsystem ( id )

ON DELETE CASCADE,

UNIQUE(name , dsystem id ) )

5.3. DATENVERWALTUNG 87

Da ein Erkennungssystem mehrere Konfigurationsdateien haben kann und eine

Konfigurationsdatei zu genau einem Erkennungssystem geh¨

ort, ergibt sich eine

Kardinalit¨

at von 1:n.

Jedes Erkennungssystem bekommt einen eindeutigen Namen. Im Attribut “path”

wird der vollst¨

andige Pfad zu dem Verzeichnis gespeichert, in dem sich die Dateien

befinden. “executable name” gibt den Namen der ausf¨

uhrbaren Datei an und

“executable md5” die MD5-Summe.

Die Informationen ¨

uber die Konfigurationsdateien eines Erkennungssystems wer-

den in der Tabelle “dsystem config file” als schwache Entities gespeichert.

5.3.6 Testl¨

aufe

Die Daten, welche die Testl¨

aufe definieren, werden ebenfalls in der Datenbank

gespeichert. Ein Testlauf wird durch folgende Angaben definiert:

•Name (eindeutig)

•Erkennungssystem (ID)

•Startzeit

•Priorit¨

•Status

•Beschreibung

•Bild-Sequenzen

•Maschinen auf denen es ausgef¨

uhrt werden kann

Dar¨

uber hinaus k¨

onnen Nachrichten (Messages), die ein Testlauf verschickt, ge-

speichert werden.

Die Maschinen werden in einer eigenen Relation verwaltet:

88 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

Listing 5.22: Relation “machine”

CREATE TABLE machine (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(256) UNIQUE NOT NULL,

machine state id INTEGER REFERENCES machine state ( id )

ON DELETE SET NULL )

Listing 5.23: Relation “machine state”

CREATE TABLE machine state (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(32) UNIQUE NOT NULL )

Mit “machine state id” wird der Status der Maschine angegeben: “frei”, “reser-

viert”, “belegt”.

Die zentrale Relation bei den Testl¨

aufen ist “test run”:

Listing 5.24: Relation “test run”

CREATE TABLE t est run (

id SERIAL NOT NULL PRIMARY KEY,

name VARCHAR(64) UNIQUE,

dsystem id INTEGER REFERENCES dsystem ( id )

ON DELETE SET NULL,

st art tim e TIMESTAMP DEFAULT CURRENTTIMESTAMP,

p r i o r i t y i d INTEGER REFERENCES p r i o r i t y ( id )

ON DELETE SET NULL,

t e s t r u n s t a t e i d INTEGER REFERENCES t e s t r u n s t a t e ( id )

ON DELETE SET NULL,

d e s cr i p t i o n VARCHAR(1024) )

Da f¨

ur einen Testlauf mehrere Maschinen angegeben werden k¨

onnen (von denen

eine ausgew¨

ahlt wird), wird eine weitere Relation ben¨

otigt:

5.3. DATENVERWALTUNG 89

Listing 5.25: Relation “test run to machine”

CREATE TABLE test run to machine (

id SERIAL NOT NULL PRIMARY KEY,

t e s t r u n i d INTEGER REFERENCES test r un ( id )

ON DELETE CASCADE,

machine id INTEGER REFERENCES machine ( id )

ON DELETE CASCADE,

UNIQUE ( test run id , machine id ) )

Eine Maschine kann durchaus bei mehreren Testl¨

aufen gleichzeitig angegeben

werden (also eine n:m Beziehung), die Testl¨

aufe “konkurieren” dann um diese

Maschine.

Ahnlich ist es bei den Bild-Sequenzen: Ein Testlauf kann mehrere Sequenzen

verarbeiten und eine Sequenz kann von mehreren Testl¨

aufen verarbeitet werden.

Also wird eine weitere (n:m) Relation ben¨

otigt:

Listing 5.26: Relation “test run channel”

CREATE TABLE t est r un channel (

id SERIAL NOT NULL PRIMARY KEY,

t e s t r u n i d INTEGER REFERENCES test run ( id )

ON DELETE CASCADE,

sequence channel id INTEGER

REFERENCES sequence channel ( id )

ON DELETE CASCADE,

UNIQUE ( t est r un i d , sequence channel id ,

label document id ) )

Bleiben noch die Nachrichten. Eine Nachricht geh¨

ort immer zu einem Testlauf und

dieser kann beliebig viele Nachrichten haben, damit ergibt sich eine 1:n Beziehung:

Listing 5.27: Relation “test run message”

CREATE TABLE test run message (

id SERIAL NOT NULL PRIMARY KEY,

t e s t r u n i d INTEGER REFERENCES test r un ( id )

ON DELETE CASCADE,

message VARCHAR(1024) )

90 KAPITEL 5. MODELLIERUNG DER DATEN UND PROZESSE

5.4 Workflow

Die Abbildung 5.2 zeigt die Prozess-Vorlage f¨

ur das Ausf¨

uhren von Testl¨

aufen

(ohne die leeren Knoten f¨

ur die Verzweigung). Diese Vorlage ist bisher einfach

gehalten, kann aber durchaus noch sinnvoll erweitert werden, indem zum Beispiel

der Empfang der Nachrichten in einer Schleife erfolgt um mehr als eine Nachricht

empfangen zu k¨

onnen. Die durchgezogenen Pfeile zeigen den Prozess-Fluss und

die gestrichelten Pfeile den Datenfluss. Die Aktivit¨

at “GetMachine” holt die Liste

Abbildung 5.2: Implementierung der Testl¨

aufe.

der Maschinen f¨

ur diesen Testlauf, sucht aus dieser eine aus, die nicht belegt ist,

und gibt diese als Ausgabeparameter “machine” aus. Zus¨

atzlich wird die freie

Maschine nun als belegt markiert. Das sollte nicht in einer eigenen Aktivit¨

5.4. WORKFLOW 91

passieren, da sonst Mehrfachbelegung wahrscheinlicher wird (sollte also m¨

oglichst

atomar passieren). Diese Aktivit¨

at kehrt erst zur¨

uck, wenn eine freie Maschine

gefunden wurde. Wenn noch keine Maschine verf¨

ugbar ist, wird der Status des

Testlaufs in “not ready” ge¨

andert. Sobald eine Maschine zur Verf¨

ugung steht,

andert sich der Status in “ready”.

Nachdem nun eine freie Maschine gefunden wurde, k¨

onnen die ben¨

otigten Daten

auf diese Maschine kopiert werden: “CopyData”. Dieser Kopiervorgang erfolgt

mit Hilfe des Kommandos “scp” (siehe Kapitel 4.2.4). Den Namen der Maschine

gibt CopyData wieder als Ausgabeparameter weiter. Vor dem Kopieren wird der

Status des Testlaufs in “starting” ge¨

andert.

Die n¨

achste Aktivit¨

at, “StartTestRun”, startet nun den Testlauf (mit Hilfe von

SSH siehe Kapitel 4.2.4) und ¨

andert den Status des Testlaufs in “running”.

Die Aktivit¨

at “Receive” wartet (blockierend) auf eine Nachricht. Sobald eine

Nachricht eintrifft, wird der Inhalt in den Ausgabeparameter “data” geschrieben.

F¨

ur die Auswertung der Nachricht ist die Aktivit¨

at “ProcessInput” zust¨

andig.

Falls der Typ der Nachricht “ERROR” lautet, wird zur Aktivit¨

at “Error” ver-

zweigt, die die Nachricht in die Datenbank schreibt und den Status des Testlaufs

in “error” ¨

andert. Ansonsten wird die Aktivit¨

at “Success” ausgef¨

uhrt, die das

Ergebnis (in der Nachricht enthalten) in die Datenbank schreibt und den Status

in “done” ¨

andert.

Neben Testl¨

aufen wurden leider keine weiteren Prozesse mit ADEPT abgewickelt.

Der Import der Bild-Sequenzen erfolgt ¨

uber die Methode importFromDirectory

der Klasse “Sequence” der DB-API. F¨

ur den Import von Label-Dokumenten exis-

tiert mit “sql/importLabels.py” ein Kommandozeilenwerkzeug.

Kapitel 6

Diskussion

In den Kapiteln 3, 5 und 4 wurden m¨

ogliche L¨

osungen besprochen und das imple-

mentierte System vorgestellt. In diesem Kapitel soll das Ergebnis dieser Arbeit

im Hinblick auf Vollst¨

andigkeit und Richtigkeit der getroffenen Entscheidungen

diskutiert werden.

Eines der ausgereiftesten Teile des Gesamtsystems ist die Verwaltung der Da-

ten. S¨

amtliche Daten (abgesehen von den Teilen, die im Dateisystem verbleiben)

werden in der Datenbank verwaltet und ¨

uber die DB-API (Kapitel 4.9.3) zur

Verf¨

ugung gestellt. Was hier vor allem noch fehlt, ist die Zugriffskontrolle. Die-

se ist nur bei der SQLObject-Integration teilweise gegeben und sollte noch bei

Schreibzugriffen implementiert werden. Dies ist auch gleich der n¨

achste Punkt:

Die Integration von SQLObject ist noch nicht vollst¨

andig, es fehlen vor allem

noch die Methoden f¨

ur den Schreibzugriff. Ansonsten deckt SQLObject s¨

amtli-

che Relationen ab. Die Nutzung von SQLObject bringt außerdem noch ein an-

deres Problem mit sich: fehlende Unterst¨

utzung der geometrischen Datentypen.

Um geometrische Daten zu verarbeiten, muss man sich zur Zeit noch auf die

SQL-Ebene begeben. Es ist allerdings m¨

oglich, dass eine k¨

unftige Version von

SQLObject auch geometrische Datentypen unterst¨

utzt.

PostgreSQL hat sich als ein ausgereiftes und schnelles DBMS mit guter Anbin-

dung an Python herausgestellt. SQLObject ist ein vielversprechender, objektrela-

tionaler Wrapper mit beachtlichem Leistungsumfang und guter Dokumentation.

Die Workflow-Funktionalit¨

at ist noch nicht vollst¨

andig, von den vorhandenen

Prozessen wird einzig die Ausf¨

uhrung eines Testlaufs vom Workflow-Server be-

werkstelligt. Auch andere Prozesse, wie Import von Label-Dokumenten oder Bild-

Sequenzen, m¨

ussen noch integriert werden. Abgesehen von der Ausf¨

uhrung der

Prozesse wird auch die Benutzerverwaltung des Workflow-Servers (ADEPT 1)

benutzt, die der Aufgabenstellung sehr nahe kommt. Nur die Unterst¨

utzung von

Projekten fehlt noch.

Der Eindruck von ADEPT 1 als Workflow-Server f¨

allt unterschiedlich aus, was

aber vor allem seinem Prototypen-Status zuzuschreiben ist. Problematisch erwies

sich die teilweise sehr knapp gehaltene Dokumentation der ADEPT-API. Auch

der Betrieb von ADEPT unter Linux f¨

uhrte zu Komplikationen. Zwar l¨

auft der

ADEPT-Server unter Linux, aber die GUI-Werkzeuge von ADEPT k¨

onnen sich

nicht zum Server verbinden wenn sie unter Windows laufen. Und unter Linux

funktionieren diese Werkzeuge nicht richtig - sie starten zwar, lassen sich aber

nicht richtig bedienen (zum Beispiel sind die Dialoge auf wenige Bildpunkte redu-

ziert und lassen sich nicht vergr¨

oßern). Da sie aber in Java geschrieben sind sollte

sich der Aufwand f¨

ur eine Portierung auf Linux in Grenzen halten. Auch eine C

oder C++ API w¨

are w¨

unschenswert, da man damit leicht Script-Sprachen, wie

Python, unterst¨

utzen kann. Und die F¨

ahigkeit, externe Anwendungen zu starten,

ist bei ADEPT ebenfalls noch ausbauf¨

ahig (siehe dazu Kapitel 4.6.4).

Positiv ist dagegen die Benutzerverwaltung aufgefallen (siehe oben). Auch die

F¨

ahigkeit von ADEPT, w¨

ahrend der Ausf¨

uhrung die Prozess-Abl¨

aufe ¨

andern zu

k¨

onnen, kann sp¨

ater sehr n¨

utzlich werden (wurde aber aus Zeitgr¨

unden noch

nicht im System integriert). Insgesamt kann man sagen, dass die Entscheidung

f¨

ur ADEPT durchaus richtig war, zumal mit ADEPT 2 in Zukunft eine weiter-

entwickelte Version zur Verf¨

ugung stehen wird.

Das Web-Interface bietet bereits f¨

ur die meisten Aufgaben entsprechende Seiten

an und sch¨

utzt diese auch vor unerlaubtem Zugriff. Diese Seiten sehen allerdings

noch sehr schlicht aus und es fehlt ein einheitliches Look-and-Feel. Beides kann

sp¨

ater mit Hilfe von CSS - Cascading Style Sheets - nachgeholt werden. Neben der

Unvollst¨

andigkeit und dem schlichten Aussehen ist noch die mangelnde Fehelerto-

leranz bei Benutzereingaben zu erw¨

ahnen (zum Beispiel werden Datumsangaben

nicht auf ihre Korrektheit hin gepr¨

uft). Dagegen werden bereits Fehler, die vom

System gemeldet werden, in dem Web-Interface angezeigt.

94 KAPITEL 6. DISKUSSION

Techniken wie PSP und Session Management von mod python haben gute Dienste

geleistet und st¨

utzen somit die Entscheidung mod python und somit auch Apa-

che HTTP-Server einzusetzen. Ein Verzicht auf Apache (Python bringt bereits

einen HTTP-Server mit) w¨

urde zwar die Architektur des Systems vereinfachen,

daf¨

ur m¨

usste man aber andere L¨

osungen f¨

ur das Session Management und die

Webseiten-Vorlagen finden und integrieren.

Ein Wegfall von Apache HTTP-Server w¨

urde auch den Glue-Server nicht ¨

uber-

fl¨

ussig machen, da dieser nicht nur mit mod python Scripten kommuniziert, son-

dern auch eine Schnittstelle f¨

ur die API bietet und die Workflow-Clients verwal-

tet. Somit ist weiterhin die Berechtigung f¨

ur den Einsatz von XML-RPC gegeben:

Dieses ist das Kommunikationsmedium f¨

ur die API (die ¨

uber Rechnergrenzen hin-

weg funktionieren muss). XML-RPC hat sich auch im Einsatz bew¨

ahrt: Es gab

keine Auff¨

alligkeiten oder Probleme.

Die Entscheidung ¨

uber UNIX Message Queues mit den Workflow-Clients zu kom-

munizieren hat sich ebenfalls als richtig erwiesen (was nat¨

urlich nicht heißt, dass

es keine besseren L¨

osungen gibt): Es hat bis jetzt zuverl¨

assig und schnell funk-

tioniert. Was allerdings noch verbesserungsw¨

urdig ist, ist die Fehlertoleranz: Bei

einem Absturz verbleiben nicht abgeholte Nachrichten in der Warteschlange und

k¨

onnen sp¨

ater f¨

alschlicherweise von anderen Clients abgeholt werden (die Adres-

sen beginnen nach einem Neustart wieder bei 1). Außerdem unterst¨

utzt die ak-

tuelle Implementierung den Versand von Nachrichten an “alle” (Adresse 0) noch

nicht.

Die Benutzerverwaltung ist dank ADEPT bereits recht ausgereift, es fehlt nur

die Unterst¨

utzung f¨

ur Projekte. Zur Zeit wertet die API den Benutzernamen

nicht aus und bietet somit noch keinen Zugriffsschutz. M¨

ogliche L¨

osungen daf¨

wurden allerdings im Kapitel 5.1 diskutiert.

Die API bietet bereits Zugriff auf die meisten Daten/Funktionen. Sie ist aller-

dings, abgesehen von der DB-API, noch nicht objectorientiert. Dies sollte eine

k¨

unftige Version nachholen, indem alle System-Komponenten, die ¨

uber die API

zug¨

anglich sein sollen, als Klassen in der API abgebildet werden.

Kapitel 7

Zusammenfassung

Das Ziel dieser Arbeit war die Konzeption und die Implementierung eines Work-

flow Management Systems zur Entwicklung und Qualit¨

atssicherung von Erken-

nungssystemen. Neben dem Workflow muss das System auch große Datenbest¨

ande

verwalten, ein Web-basiertes Benutzerinterface bieten und ¨

uber eine Program-

mierschnittstelle (API) zug¨

anglich sein. Zus¨

atzlich sollte auch Zugriffsschutz gew¨

ahr-

leistet sein.

Daf¨

ur wurde der Prototyp des Workflow Management Systems ADEPT 1 einge-

setzt, welcher somit den Rahmen vorgab. Die Notation f¨

ur die Beschreibung der

Prozesse, die Werkzeuge f¨

ur das Erstellen von Prozess-Vorlagen und die Verwal-

tung der Benutzer, sowie die Benutzerverwaltung wurden von ADEPT ¨

ubernom-

men.

Um Prozess-Instanzen ausf¨

uhren zu k¨

onnen, wurde ein eigener Client in Java

geschrieben, der ¨

uber die ADEPT-API mit dem ADEPT-Server interagiert, wo-

bei die eigentliche Arbeit externe Python-Scripte erledigen, die von dem Client

aufgerufen werden.

Die Datenverwaltung ¨

ubernimmt das Datenbankmanagementsystem PostgreS-

QL, welches frei verf¨

ugbar und leistungsf¨

ahig ist. Die Daten werden ¨

uber eine

objektorientierte API zug¨

anglich gemacht, wobei auch die M¨

oglichkeit besteht

uber SQL-Anfragen die Daten zu benutzen.

96 KAPITEL 7. ZUSAMMENFASSUNG

Dem Web-basierten Benutzerinterface liegen der HTTP-Server Apache und mod

python zugrunde. Letzteres ist f¨

ur die Generierung der Web-Seiten zust¨

andig und

kann ¨

uber die API mit dem Rest des Systems kommunizieren.

Teilweise wurde auch der Zugriffsschutz realisiert. Am vollst¨

andigsten ist dieser

beim Benutzerinterface, zum Teil wurde er auch beim Zugrif auf die Daten ¨

uber

die API realisiert.

Insgesamt ist das umgesetzte System noch in einem Prototypen-Stadium.

Abbildungsverzeichnis

2.1 Beispiel einer Infrarotaufnahme . . . . . . . . . . . . . . . . . . . 4

2.2 Speicherung der Bild-Sequenzen . . . . . . . . . . . . . . . . . . . 5

2.3 Beispiele f¨

urLabel .......................... 6

2.4 Lava .................................. 9

4.1 Architektur des Gesamtsystems . . . . . . . . . . . . . . . . . . . 24

4.2 Kommunikation ¨

uber Message Queues . . . . . . . . . . . . . . . 29

4.3 WfMS-Client Klassen . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Interner Aufbau des Glue-Servers . . . . . . . . . . . . . . . . . . 48

4.5 Web-Interface: Anmeldeseite . . . . . . . . . . . . . . . . . . . . . 56

4.6 Web-Interface: Anmeldeseite, fehlgeschlagen . . . . . . . . . . . . 56

4.7 Web-Interface: Startseite . . . . . . . . . . . . . . . . . . . . . . . 57

4.8 Web-Interface: Labeln-Seite . . . . . . . . . . . . . . . . . . . . . 57

4.9 Web-Interface: Label-Dokument Import . . . . . . . . . . . . . . . 58

4.10 Web-Interface: Label-Jobs . . . . . . . . . . . . . . . . . . . . . . 58

4.11 Web-Interface: Verwaltung der Label-Auftr¨

age........... 59

4.12 Web-Interface: Neuen Label-Auftrag erstellen . . . . . . . . . . . 59

4.13 Web-Interface: Verwaltung der Erkennungssysteme . . . . . . . . 60

4.14 Web-Interface: Verwaltung der Testl¨

aufe .............. 61

98 ABBILDUNGSVERZEICHNIS

4.15 Web-Interface: Verwaltung der Bild-Sequenzen . . . . . . . . . . . 61

4.16 SQLObject: Integration . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Testlauf: Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Tabellenverzeichnis

4.1 Laufzeiten ohne Index . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Laufzeiten mit Index . . . . . . . . . . . . . . . . . . . . . . . . . 39

Listings

4.1 Beispiel f¨

urJPype .......................... 25

4.2 Methode “deleteChannel” . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Methode “sendMessage” . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Methode “receiveMessage” . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Import des “mque channel”-Modules . . . . . . . . . . . . . . . . 29

4.6 Klasse AsyncXMLRPCServer . . . . . . . . . . . . . . . . . . . . 32

4.7 SQL-Query f¨

ur die Performancemessung . . . . . . . . . . . . . . 38

4.8 R¨

uckgabe einer Fehlermeldung . . . . . . . . . . . . . . . . . . . . 63

4.9 Nutzung des GlueServerInterface . . . . . . . . . . . . . . . . . . 64

4.10 Aufruf von getRawResultForQuery . . . . . . . . . . . . . . . . . 65

4.11 Aufruf einer Query-Datei . . . . . . . . . . . . . . . . . . . . . . . 65

4.12 Parameter f¨

ur sendMessageTo . . . . . . . . . . . . . . . . . . . . 68

5.1 Relation “category” . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2 Relation “sequence category” .................... 77

5.3 Relation “sequence” . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.4 Relation “sequence channel”..................... 77

5.5 Relation “frame” . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.6 Relation “frame tochannel”..................... 78

100

LISTINGS 101

5.7 Relation “sequence tag” ....................... 79

5.8 Relation “sequence comment” .................... 79

5.9 Relation “sequence channel tag” . . . . . . . . . . . . . . . . . . . 79

5.10 Relation “sequence channel comment” . . . . . . . . . . . . . . . 80

5.11 Relation “frame tag”......................... 80

5.12 Relation “frame comment”...................... 80

5.13 Relation “label document”...................... 81

5.14 Relation “label” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.15 Relation “label document tag” . . . . . . . . . . . . . . . . . . . . 83

5.16 Relation “label document comment” . . . . . . . . . . . . . . . . 83

5.17 Relation “label tag” ......................... 84

5.18 Relation “label comment” ...................... 84

5.19 Relation “label job” ......................... 85

5.20 Relation “dsystem” . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.21 Relation “dsystem configfile” .................... 86

5.22 Relation “machine” . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.23 Relation “machine state”....................... 88

5.24 Relation “test run”.......................... 88

5.25 Relation “test run to machine” . . . . . . . . . . . . . . . . . . . 89

5.26 Relation “test runchannel” ..................... 89

5.27 Relation “test runmessage” ..................... 89

Literaturverzeichnis

[ElNa02] Ramez Elmasri, Shamkant B. Navathe:Grundlagen von Daten-

banksystemen. Dritte Auflage, Pearson Studium, 2002

[Wenz07] Christian Wenz:JavaScript und AJAX. Siebte Auflage, Galileo

Computing, 2007

[Lubk06] Mark Lubkowitz:Webseiten programmieren und gestalten. Zweite

Auflage, Galileo Computing, 2006

[Lutz06] Mark Lutz:Programming Python. Third Edition, O’Reilly, 2006

[Krug02] Guido Kr¨

uger:Handbuch der Java-Programmierung. Dritte Auflage,

Addison-Wesley, 2002

[Hero99] Helmut Herold:Linux-Unix Systemprogrammierung. Zweite Aufla-

ge, Addison-Wesley, 1999

[Statis] Statistisches Landesamt Baden-W¨

urttemberg, Stutt-

gart:Straßenverkehrsunf¨

alle und dabei verungl¨

uckte Perso-

nen in Baden-W¨

urttemberg seit 1970. http://www.statistik-

bw.de/UmweltVerkehr/Landesdaten/MUnfaelle.asp. [Stand: 09.05.2007].

[Daimler] DaimlerChrysler:Homepage.

http://www.daimlerchrysler.com/dccom de

[SuSELi] Novell:SUSE Linux 9.3. http://www.novell.com/de-

de/products/linuxprofessional. [Stand: 09.05.2007].

[openSUSE] openSUSE:openSUSE 10.2. http://de.opensuse.org/Stabile Version.

[Stand: 09.05.2007])

102

LITERATURVERZEICHNIS 103

[Python] Python:Release 2.4.4.

http://www.python.org/download/releases/2.4.4

[GNUGCC] GCC - GNU Compiler Collection:Release 3.3.5.

http://gcc.gnu.org/gcc-3.3

[Java13] Java:Release 1.3.1. http://java.sun.com/j2se/1.3/download.html

[ADEPT] Universit¨

at Ulm Institut f¨

ur Datenbanken und Informa-

tionssysteme:ADEPT. http://www.informatik.uni-ulm.de/dbis. [Stand:

09.05.2007].

[Apache] Apache:Release 2.2.4. http://httpd.apache.org

[modpy] mod python:Homepage. http://www.modpython.org. [Stand:

09.05.2007].

[W3CDOM] W3C:DOM - Document Object Model. http://www.w3.org/DOM.

[Stand: 09.05.2007].

[MochiKit] MochiKit:Homepage. http://mochikit.com. [Stand: 09.05.2007].

[Scons] SCons - Open Source software construction tool:Homepage.

http://www.scons.org. [Stand: 09.05.2007].

[SWIG] SWIG - Simplified Wrapper and Interface Generator:Home-

page. http://www.swig.org. [Stand: 09.05.2007].

[Dia] live.gnome.org:Dia - Illustrationsprogramm und UML-Werkzeug.

http://live.gnome.org/Dia

[MqWork] IBM:IBM WebSphere MQ Workflow. http://www-

306.ibm.com/software/integration/wmqwf

[Staffware] Staffware:Homepage. http://www.staffware.com

[TIFF] Adobe Systems:TIFF 6.0 Specification.

http://partners.adobe.com/public/developer/tiff/index.html

[OpenSSH] OpenSSH:Homepage. http://www.openssh.org

[RMI] Sun Developer Network:RMI - Remote Method Invocation.

http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp

104 LITERATURVERZEICHNIS

[Jithon] The Jython Project:Homepage.

http://www.jython.org/Project/index.html

[JPype] JPype:Homepage. http://jpype.sourceforge.net

[JPypeEx] JPype:Anwendungsbeispiel. http://jpype.sourceforge.net/doc/user-

guide/userguide.html#using

[JNI] Sun Microsystems:JNI - Java native Interface.

http://java.sun.com/j2se/1.4.2/docs/guide/jni/index.html

[RPC] IETF:Remote Procedure Call Protocol Specification Version 2.

http://tools.ietf.org/html/rfc1831

[SOAP] W3C:SOAP Specifications. http://www.w3.org/TR/soap

[twissp] Twisted:Twisted Spread.

http://twistedmatrix.com/projects/core/documentation/howto/pb.html.

[Stand: 09.05.2007].

[XMLRPC] XML-RPC:Homepage. http://www.xmlrpc.com

[PyXMLRPC] Python Dokumentation:XML-RPC.

http://www.python.org/doc/2.4/lib/module-xmlrpclib.html

[ThXMLRPC] ActiveState Programmer Net-

work:Simple Threaded XML-RPC Server.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/425043.

[Stand: 09.05.2007].

[JavaSc] Ecma International:ECMAScript Language Specification.

http://www.ecma-international.org/publications/files/ecma-st/ECMA-

262.pdf. [Stand: 09.05.2007].

[AJAX] Mozilla Developer Center:AJAX - Asynchronous JavaScript and

XML. http://developer.mozilla.org/de/docs/AJAX. [Stand: 09.05.2007].

[Json] JSON:Homepage. http://www.json.org. [Stand: 09.05.2007].

[CJson] CJson:Homepage. http://cheeseshop.python.org/pypi/python-cjson.

[Stand: 09.05.2007].

LITERATURVERZEICHNIS 105

[JsonLib] Json-Lib:Homepage. http://json-lib.sourceforge.net. [Stand:

09.05.2007].

[LightHTTP] lighttpd:Homepage. http://lighttpd.net

[LiteSp] LiteSpeed Web Server:Homepage. http://litespeedtech.com

[PyHTTP] Python Dokumentation:CGIHTTPServer - CGI-capable

HTTP request handler. http://www.python.org/doc/2.4/lib/module-

CGIHTTPServer.html

[CGI] CGI - Common Gateway Interface:RFC Project Page. http://cgi-

spec.golux.com

[FastCGI] Fast-CGI:Homepage. http://www.fastcgi.com

[PySession] mod python Dokumentation:Session Management.

http://www.modpython.org/live/current/doc-html/pyapi-sess.html. [Stand:

09.05.2007].

[PSP] mod python Dokumentation:PSP - Python Server Pages.

http://www.modpython.org/live/current/doc-html/pyapi-psp.html. [Stand:

09.05.2007].

[Cookie] IETF:Cookie - RFC2965. http://tools.ietf.org/html/rfc2965

[Firebird] Firebird:Homepage. http://www.firebirdsql.org

[MySQL] MySQL:Homepage. http://www.mysql.com

[Postgre] PostgreSQL:Homepage. http://www.postgresql.org

[PostAb] PostgreSQl:About. http://www.postgresql.org/about. [Stand:

09.05.2007].

[PostGeo] PostgreSQL Dokumentation:Geometrische Datentypen.

http://www.postgresql.org/docs/8.2/interactive/datatype-geometric.html.

[Stand: 09.05.2007].

[PostGeoFunk] PostgreSQL Dokumentation:Funktio-

nen und Operatoren f¨

ur geometrische Datentypen.

http://www.postgresql.org/docs/8.2/interactive/functions-geometry.html.

[Stand: 09.05.2007].

106 LITERATURVERZEICHNIS

[PyDB] Python:Python Database API Specification v2.0.

http://www.python.org/dev/peps/pep-0249. [Stand: 09.05.2007].

[PyGre] PyGreSQL:Homepage. http://www.pygresql.org

[PyPg] PyPgSQL:Homepage. http://pypgsql.sourceforge.net

[Psyco] Psycopg2:Homepage.

http://initd.org/tracker/psycopg/wiki/PsycopgTwo. [Stand: 09.05.2007].

[Lotus] IBM:Lotus Notes. http://www-306.ibm.com/software/de/lotus

[promin] iABG:ProMInanD. http://www.iabg.de/index en.php

[Floware] SER:Floware. http://www.ser.de

[ADEPTHos] ADEPT:Process-Management in Hos-

pital Environments. http://www.informatik.uni-

ulm.de/dbis/01/forschung/projects/adept/partners/ClinFlow.htm. [Stand:

09.05.2007].

[Arista] AristaFlow Project:Homepage. http://www.aristaflow.de

[Oracle] Oracle:Oracle Database. http://www.oracle.com/database/index.html

[OracXE] Oracle:Oracle Database 10g Express Edition.

http://www.oracle.com/technology/products/database/xe/index.html.

[Stand: 09.05.2007].

[JSW] Java Service Wrapper:Homepage.

http://wrapper.tanukisoftware.org/doc/english/introduction.html. [Stand:

09.05.2007].

[CSS] W3C:Cascading Style Sheets. http://www.w3.org/Style/CSS. [Stand:

09.05.2007].

[Sched] Python Dokumentation:sched - Event scheduler.

http://www.python.org/doc/2.4/lib/module-sched.html

[Prot] Prototype:Homepage. http://www.prototypejs.org

[SQLObj] SQLObject:Homepage. http://www.sqlobject.org/index.html.

[Stand: 09.05.2007].

LITERATURVERZEICHNIS 107

[SCP] Secure Shell:scp - Secure Copy. http://www.uni-

koeln.de/rrzk/netze/ssh/sshscp.html

[vmware] VMWare:VMWare Server 1.0.2. http://register.vmware.com/content/eula102.html

[pylog] Python Dokumentation:logging - Logging facility for Python

http://www.python.org/doc/2.4/lib/module-logging.html

Erkl¨

arung

Ich erkl¨

are hiermit, dass ich diese Diplomarbeit selbst¨

andig verfasst, noch nicht

anderweitig f¨

ur andere Pr¨

ufungszwecke vorgelegt, keine anderen als die angege-

benen Quellen und Hilfsmittel ben¨

utzt sowie w¨

ortliche und sinngem¨

aße Zitate als

solche gekennzeichnet habe.

Ulm, den 11. Mai 2007

108