Entwurf und Implementierung eines verteilten Systems ... - copton.net

·
Entwurf und Implementierung eines verteilten
Systems mit Benutzerschnittstelle zur
Erstellung, Verteilung und Verwaltung von
Simulationen in der Kanalcodierung
Diplomarbeit
von
Stephanie Wist
· T E L E C O M M U N
I C A T
I O N S
A P P L
T H E O R Y
I E D
I N F O R M A T
I O N
Abteilung Telekommunikationstechnik
und Angewandte Informationstheorie
Universität Ulm
Mai 2006
D/2005/ST/1

Abteilung Telekommunikationstechnik
und Angewandte Informationstheorie
Universität Ulm
DIPLOMARBEIT
Entwurf und Implementierung eines verteilten Systems mit
Benutzerschnittstelle zur Erstellung, Verteilung und
Verwaltung von Simulationen in der Kanalcodierung
Erläuterungen:
Um in der Kanalcodierung theoretische Ergebnisse zu verifizieren, werden Simulationen
für die Berechnung der Restbit- und -blockfehlerraten verwendet. Dabei werden entweder
graphische Simulationstools wie „ML Designer“ verwendet oder es werden komplette
Simulationsumgebungen in einer Programmiersprache wie C/C++ oder „Matlab“ erstellt.
Beide Möglichkeiten haben ihre Vor- und Nachteile.
Bestehende Simulationstools sind meist recht umfangreich und dementsprechend unübersichtlich.
Die Einarbeitung nimmt daher oftmals viel Zeit in Anspruch. Desweiteren
handelt es sich bei diesen Tools häufig um kommerzielle Software, wodurch hohe
Lizenzkosten anfallen.
Auf der anderen Seite sind vom Anwender selbst geschriebene Simulationsumgebungen
zwar frei, haben aber den Nachteil, dass von anderen Benutzern sehr viel Progammierkenntnis
verlangt wird, um Modifikationen vornehmen zu können. Die komfortable
graphische Benutzeroberfläche kommerzieller Tools entfällt in diesem Fall.
Im Rahmen dieser Diplomarbeit soll daher ein verteiltes System zur Erstellung, Verteilung
und Verwaltungen von Simulationen in der Kanalcodierung entworfen und implementiert
werden. Dies sollte unter Verwendung eines Simulationsframeworks stattfinden,
welches Gegenstand einer weiteren Diplomarbeit ist. Das System sollte mehrbenutzerfähig
und in einem heterogenen Rechnernetz einsetzbar sein, sowie eine Schnittstelle zur
Verwaltung bereits laufender Simulationen bieten. Die Erstellung der an der Simulation
beteiligten Komponenten und der Simulation selbst sollte einfach und ohne tiefer
gehende Kenntnis der dahinter liegenden Mechanismen möglich sein.
Abgabetermin: 17. Mai 2006
Bearbeiter:
Betreuung:
Stephanie Wist
Prof. Dr.-Ing. M. Bossert
Prof. Dr.-Ing. F. J. Hauck
Dipl.-Ing. A. Hof
Dipl.-Inform. S. Schober
Katalognr.:
D/2005/ST/1

Erklärung
Ich versichere, dass ich die vorliegende Diplomarbeit selbständig und ohne unzulässige
fremde Hilfe angefertigt habe.
Ulm, den 16. Mai 2006
Stephanie Wist

Danksagung
Mein besonderer Dank an dieser Stelle gilt meinen Eltern, die mich während des Studiums
nicht nur finanziell unterstützt haben, sondern mir auch in schwierigen Situationen
immer beigestanden sind. Auch möchte ich allen Mitwirkenden der Universität Ulm
danken, die diese Arbeit ermöglicht und zu ihrem Gelingen beigetragen haben. Dies
sind speziell die Gutachter Prof. Dr.-Ing. Martin Bossert und Prof. Dr.-Ing. Franz J.
Hauck, sowie meine Betreuer Dipl.-Ing. Axel Hof und Dipl.-Inform. Steffen Schober.
Auch danke ich allen Korrekturlesern für ihre Mühen. Dies gilt besonders für meinen
Vater, sowie für Markus Schaber und Markus Wörle, die nicht müde wurden, die
Diplomarbeit immer und immer wieder nach Fehlern zu durchsuchen.
Für den Entwurf und die Implementierung des verteilten Systems wurde sehr viel freie
Software eingesetzt. Deshalb an dieser Stelle auch einen Dank an alle Entwickler und
Maintainer von freier Software, ohne deren Arbeit die Ergebnisse dieser Diplomarbeit
in ihrer jetzigen Form nicht möglich gewesen wären.
Abschließend möchte ich mich noch besonders bei Markus Wörle bedanken, der mich
immer wieder aufgebaut hat, wenn ich nicht mehr weiter wusste.

Inhaltsverzeichnis
Inhaltsverzeichnis
IX
1 Einführung 1
1.1 Aufteilung und Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Der Anwender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen 5
2.1 Simulationsprogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 XML-Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Reflection-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2 JDOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.3 Saxon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Systementwurf 13
3.1 Module und Simulationen . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Datentyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 Simulationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4 Simulationsauftrag . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Konzeption des verteilten Systems . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 Auswahl der Middleware . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Systemaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 Codeverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4 Benutzer- und Rechteverwaltung . . . . . . . . . . . . . . . . . . 20
3.2.5 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.6 Kommunikation zwischen Komponenten . . . . . . . . . . . . . . 26
3.2.7 Systemgröße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Simulationsablauf im verteilten System . . . . . . . . . . . . . . . . . . . 29
3.3.1 Entgegennahme und Verwaltung von Simulationsaufträgen . . . 29
3.3.2 Erstellen von Sicherungspunkten . . . . . . . . . . . . . . . . . . 30
IX

INHALTSVERZEICHNIS
3.3.3 Verteilen von Simulationen . . . . . . . . . . . . . . . . . . . . . 31
3.3.4 Ausführen von Simulationen . . . . . . . . . . . . . . . . . . . . . 31
3.3.5 Ende einer Simulation . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.6 Informationen über laufende Simulationen . . . . . . . . . . . . . 32
3.4 Überblick über die Dienste im verteilten System . . . . . . . . . . . . . 33
3.4.1 Umsetzung der Dienste . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Anwenderprogramme . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Implementierung 35
4.1 Wahl der Programmier- und Beschreibungssprachen . . . . . . . . . . . 35
4.1.1 Java versus C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Beschreibungssprache . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Module und Simulationen . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Erzeugen von Modulen . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Erzeugen von Simulationen . . . . . . . . . . . . . . . . . . . . . 40
4.2.3 Erstellen von Simulationsaufträgen . . . . . . . . . . . . . . . . . 40
4.3 Das verteilte System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Hinzufügen und Entfernen von Knoten . . . . . . . . . . . . . . . 43
4.3.2 Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.3 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.4 Codeverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.5 Dienste im verteilten System . . . . . . . . . . . . . . . . . . . . 47
4.4 Benutzeranwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1 Paketgenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.2 Ergebnisexportierer . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.3 Modulsuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.4 Die grafische Oberfläche . . . . . . . . . . . . . . . . . . . . . . . 51
5 Zusammenfassung und Ausblick 55
5.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Erfüllung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Lizenzbestimmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4 Probleme mit ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A Kommandozeilen-Tools 61
A.1 Simulationsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.3 Paketgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.4 Modulsuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.5 Ergebnisse exportieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
X

INHALTSVERZEICHNIS
B Installation und Wartung 65
B.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.1.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.1.2 zentrale Komponente . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.1.3 Simulationsknoten . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.1.4 Codeverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.2 Wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.2.1 Simulationsknoten hinzufügen . . . . . . . . . . . . . . . . . . . . 66
B.2.2 Simulationsknoten entfernen . . . . . . . . . . . . . . . . . . . . 66
B.2.3 Neue Codeverteilung hinzufügen . . . . . . . . . . . . . . . . . . 67
C Schnittstellen 69
C.1 Schnittstellen im verteilten System . . . . . . . . . . . . . . . . . . . . . 70
C.2 Schnittstellen der GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
D Software 75
D.1 verwendete Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
D.2 Inhalt der beigefügten CD . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Index 77
Literaturverzeichnis 79
XI

1 Einführung
Die Telekommunikation spielt in der modernen Gesellschaft eine zentrale Rolle. Egal
ob bei Steuerchips in Autos, Schiffen oder Flugzeugen, bei Signalprozessoren in Mobiltelefonen
oder bei Controllern von Bussystemen in Computern oder Industrieanlagen:
überall werden Informationen ausgetauscht und verarbeitet. Dabei steigen die Anforderungen
an Geschwindigkeit und Robustheit unter immer kritischeren Bedingungen
kontinuierlich an.
Forscher auf dem Gebiet der Informationstheorie sorgen seit Jahrzehnten immer wieder
für Lösungen, die den wachsenden Ansprüchen gerecht werden. Einer der zentralen
Schauplätze auf diesem Gebiet ist dabei die Kanalcodierung. Sie beschäftigt sich mit
der Frage, wie man den Informationsaustausch durch kontrolliertes Hinzufügen von möglichst
wenig Redundanz robust gegen Übertragungsfehler machen kann.
Die Komplexität der Systeme, die sich bei der Erforschung geeigneter Algorithmen
ergeben, ist ohne Hilfsmittel allerdings kaum in den Griff zu bekommen. So sind z.B.
nichtlineare Optimierungsprobleme keine Seltenheit. Deshalb ist die Simulation ein gern
verwendetes Hilfsmittel. Dabei berechnet ein Computer möglichst exakt, wie sich das
System bei einem echten Einsatz verhalten würde.
Es existiert also ein Markt für Simulationsprogramme und er wird reichlich bedient.
Doch keine der Lösungen schöpft die Möglichkeiten, die sich durch verteiltes Rechnen
ergeben, ausreichend aus. Und das, obwohl in den meisten Forschungseinrichtungen viele
Computer vorhanden sind. Deshalb bleibt es dem Anwender überlassen, die Probleme
zu lösen, die sich beim Einsatz in einem Netzwerk ergeben: Es gibt keine automatisierte
Verteilung, keine Ausfallsicherheit und keine zentrale Verwaltung für Ressourcen,
Simulationen und Benutzer.
Diese Arbeit behandelt den Entwurf und die Implementierung von Lethe 2 , einer Lösung
dieser Probleme. Lethe ist zum einen ein verteiltes System mit einem zentralen
Anwenderprogramm für die Erzeugung und Verwaltung von Simulationen. Neben der
automatisierten Verteilung ermöglicht Lethe es, Simulationen im laufenden Betrieb auf
andere Computer zu verlagern. Damit ist eine flexible Nutzung der zur Verfügung stehenden
Ressourcen möglich. Außerdem erstellt Lethe in regelmäßigen Abständen Sicherungspunkte
von Simulationen, die jederzeit auf einem beliebigen Computer fortgesetzt
werden können. Lethe kümmert sich damit um die transparente Behandlung von Systemausfällen.
Alle automatisierten Vorgänge können auch manuell gesteuert werden.
1 Die vorliegende Diplomarbeit wurde im Verbund mit der Diplomarbeit von Alexander Bernauer erstellt.
Dabei ist diese Einleitung in Gemeinschaftsarbeit erstellt worden und wird in beiden Arbeiten
verwendet.
2 Der Name Lethe stammt aus der griechischen Mythologie. Er bezeichnet dort den Fluß des Vergessens
im Reich von Hades, dem Gott der Unterwelt [21].
1

1 Einführung
Dabei sind Zugriffe auf das verteilte System durch ein Rechtesystem für Benutzer geschützt.
Zum anderen ist Lethe ein Framework für die Simulationen. Dazu gehören zwei Dinge:
eine Programmierschnittstelle und eine Laufzeitumgebung. Das wesentliche Kriterium
für die Gestalt dieses Frameworks ist die Unterstützung der oben beschriebenen
Besonderheiten von Lethe. Ermöglicht wird das vor allem durch eine Spezialisierung
auf Anwendungen in der Kanalcodierung. Ein anderes wichtiges Kriterium ist es, die
Wiederverwendbarkeit von Implementierungen zu maximieren. Dazu existiert ein Modulkonzept
mit einem Konfigurationssystem.
Lethe stellt an das Netzwerk, in dem es eingesetzt wird, fast keine Anforderungen. Es
benötigt lediglich POSIX kompatible Systeme, wobei die einzelnen Systeme im Netzwerk
verschieden sein dürfen. Außerdem steht Lethe unter der GNU General Public Licence
[19] der Free Software Foundation [17].
1.1 Aufteilung und Gliederung
Das Lethe Projekt ist zu umfangreich, um in einer einizgen Diplomarbeit ausreichend
behandelt werden zu können. Aus diesem Grund wird das Thema in zwei Diplomarbeiten
behandelt. Die vorliegende Arbeit deckt die Themen um das verteilte System und das
Anwenderprogramm ab, während sich die Arbeit von Alexander Bernauer sich um das
Framework kümmert. Die Schnittpunkte zwischen diesen beiden Teilen werden jeweils
aus der entsprechenden Perspektive in beiden Arbeiten behandelt.
Zum besseren Verständnis dieser Diplomarbeit ist Abschnitt 2.1 aus der Diplomarbeit
von Alexander Bernauer entnommen. Zusätzlich ist er mit einem klärenden Vermerk
über seinen Autor gekennzeichnet. Diese Einführung stammt von beiden Autoren
gemeinsam.
Beide Arbeiten besitzen den selben Aufbau: Das Kapitel „Grundlagen“ erklärt, welche
alternativen Lösungen existieren und warum diese den Anforderungen nicht gerecht
werden. Außerdem liefert dieses Kapitel kurze Einführungen in die für die Arbeit relevanten
Themengebiete und verweist dabei ggf. auf weiterführende Literatur.
Der Entwurf in Kapitel 3 diskutiert, wie die Anforderungen umgesetzt und die dabei
entstehenden Probleme gelöst werden. Das nachfolgende Kapitel über die Implementierung
beschäftigt sich damit, wie die Lösungen des Entwurfs tatsächlich umgesetzt
werden.
Trotz der Aufteilung in zwei Diplomarbeiten werden nicht alle Fragen geklärt, die sich
bei der Diskussion um Lethe ergeben. Kapitel 5 bietet einen Überlick über die Arbeit,
listet die offenen Fragen auf und erlaubt einen Ausblick auf eventuelle Folgearbeiten.
1.2 Anforderungen
Die folgenden Anforderungen werden an Lethe allgemein und speziell an das verteilte
System und die Anwenderprogramme gestellt:
• leichte Benutzbarkeit. Dazu zählt sowohl die Anbindung an das verteilte System,
als auch die Erweiterbarkeit des verteilten Systems um zusätzlich benötigte Kom-
2

1.3 Der Anwender
ponenten. Desweiteren soll das Hinzufügen und Entfernen von Knoten aus dem
verteilten System möglichst einfach durchzuführen sein.
• Mehrbenutzersystem. Lethe soll mehreren Benutzern gleichzeitig den Zugriff auf
das verteilte System erlauben. Ausserdem sollen unterschiedliche Benutzergruppen
mit verschiedenen Rechten und Prioritäten bezüglich der Simulationsdurchführung
unterstützt werden.
• automatische Ressourcenzuteilung. Verfügbare Ressourcen sollen automatisch und
möglichst gerecht an die Simulationen verteilt werden. Dabei sind die unterschiedlichen
Prioritäten der Benutzer zu beachten.
• Ausfallsicherheit. Das verteilte System soll möglichst robust gegen Knotenausfälle
sein und auf einen Ausfall angemessen reagieren.
• Zugriff auf laufende Simulationen. Dem Benutzer soll es erlaubt sein, während der
Ausführung auf seine Simulationen zuzugreifen. Dazu zählt im Besonderen: Anhalten
und Fortfahren von Simulationen, Abbrechen von Simulationen und Umziehen
von Simulationen auf andere Rechner.
• Ausgewogenheit. Die Anwenderprogramme für den Zugriff auf das verteilte System
sollen einerseites dem erfahrenen Benutzer einen schnellen Zugriff erlauben, andererseits
sollen sie dem unerfahrenen Benutzer den Einstieg erleichtern. Dazu zählt
insbesondere eine möglichst intuitive Bedienbarkeit der Programme.
• einfache Erstellung von Simulationen. Ein Modul soll einfach benutzbar sein und
den Benutzer nicht zwingen, sich vor dem Gebrauch mit der Implementierung
des Moduls auseinanderzusetzen. Im Idealfall sollen sich Simulationen vollständig
ohne Programmierkenntnisse erstellen lassen und Programmierkenntnisse nur für
die Erstellung und Programmierung eigener Module erfordern.
Das Lethe soll in der Abteilung TAIT 1 der Universität Ulm eingesetzt werden und
dort zu einfacheren und schnelleren Simulationen von Algorithmen zur Kanalcodierung
dienen. Um die vorhandene Rechenerstruktur möglichst gut nutzen zu können, soll Lethe
plattformunabhängig sein.
1.3 Der Anwender
Da es im Kontext von Lethe drei getrennte Rollen von Anwendern gibt, verwenden die
folgenden Kapitel die hier aufgelisteten Termini.
Entwickler Anwender, der einen neuen Algorithmus simulieren will und ihn deshalb
unter Verwendung der Programmierschnittstelle von Lethe implementiert.
Benutzer Anwender, der auf eine gegebene Menge von Algorithmen zurückgreift und
daraus eine Simulation erstellt, die Lethe ausführen soll.
1 Telekommunikationstechnik und Angewandte Informationstheorie
3

1 Einführung
Administrator Anwender, der das System betreut. Er verwaltet die Benutzer und ihre
Rechte. Er fügt neue Knoten in das verteilte System hinzu und entfernt alte.
4

2 Grundlagen
In diesem Kapitel soll dargestellt werden, welche Möglichkeiten für Simulationen in der
Kanalcodierung bereits existieren. Anschließend werden die Technologien erläutert, die
für das Verständnis der weiteren Arbeit notwendig sind.
Dazu wird im ersten Abschnitt zuerst auf bereits exisitierende Simulationsprogramme
eingegangen. Dieser Abschnitt ist komplett aus der Diplomarbeit von Alexander
Bernauer [7] übernommen worden und dient dem besseren Verständnis für die Anforderungen,
die an das verteilte System gestellt sind.
Im zweiten Abschnitt wird auf die Internet Communications Engine (ICE) eingegangen,
die für den Entwurf und die Implementierung des verteilten Systems in der
Diplomarbeit verwendet wird. Nach einem kurzen Überblick über das Framework werden
die einzelnen Dienste beschrieben, die ICE unterstützt.
Der dritte Abschnitt beschäftigt sich mit der Extensible Markup Language (XML), das
ein inzwischen weit verbreiteter Standard für Beschreibungssprachen ist. In Verbindung
mit XML wird die Grammatikbeschreibung XML-Schema sowie die Extensible Stylesheet
Language Transformation (XSLT) beschrieben.
Abschließend wird im vierten Abschnitt ein kurzer Überblick über die in der Implementierung
verwendete Programmiersprache Java, sowie auf die für die Diplomarbeit
wichtigen Bibliotheken gegeben.
2.1 Simulationsprogramme
dieser Abschnitt stammt vollständig aus der Diplomarbeit von Alexander Bernauer
Ein weitverbreitetes und sehr beliebtes Simulationsprogramm ist Matlab [29]. Dabei
ist es im eigentlichen Sinn kein Simulationsprogramm, sondern eine allgemeine Plattform
für numerische Berechnungen. Gründe für die Beliebtheit und die weite Verbreitung sind
sicherlich die mächtige Matlab Programmiersprache und die sehr umfangreichen Bibliotheken.
Damit ist es möglich, einfach und in kurzer Entwicklungszeit komplexe Berechnungen
durchzuführen. Mit etwas Programmieraufwand lassen sich diese Berechnungen
schließlich zu einer Simulation verknüpfen.
Ein großes Problem, das sich dem Einsatz von Matlab in den Weg stellt, ist der
hohe Preis für eine Lizenz. Je nach Lizenztyp kostet das Basispaket bis zu 1900 US
Dollar. Dazu kommen weitere Kosten für Zusatzpakete, die zwischen $ 400 und $ 5000
liegen (Stand 10. April 2006). Für den, der sich diese Ausgaben sparen möchte, besteht
die Möglichkeit, auf eine freie Alternative wie Scilab [46] oder mit eingeschränktem
Funktionsumfang auch GNU Octave [37] zurückzugreifen.
Die Unterstützung für verteiltes und paralleles Rechnen muss bei Matlab mit Hilfe
von Zusatzpaketen nachgerüstet werden. Die meisten dieser Pakete verwenden eine
5

2 Grundlagen
Implementierung des “Message Passing Interface” (MPI [35]) oder die “Parallel Virtual
Machine” (PVM [41]). Beides bedeutet, dass der Entwickler die Algorithmen zur
Verteilung von Hand implementieren muss. Letzteres zwingt sogar zum Einsatz einer
homogenen Hardwarelandschaft. Diesen Nachteil bringen auch die Pakete mit, die eine
transparente Verteilung bieten, da sie einen Cluster wie z.B. Beowulf [5] voraussetzen.
Scilab unterstützt die PVM von Haus aus. Für GNU Octave existiert ein MPI basierter
Klon namens Parallel Octave. Beide bringen jeweils die oben genannten Nachteile mit
sich.
Matlab und seine Alternativen bringen keine Unterstützung zum Migrieren von Simulationen
oder zum Erstellen von Sicherungspunkten mit. Auch die Verteilung der
Rechenkapazitäten im Netzwerk und die Durchsetzung von Interessen verschiedener Benutzergruppen
muss mit Mitteln der jeweiligen Systeme von Hand gemacht werden. Da
so etwas von einer Plattform für numerische Berechnungen auch nicht erwartet wird, ist
das nicht verwunderlich. Dennoch ist der Einsatz dieser Programme in einem Netzwerk
deshalb unkomfortabel und fehlerträchtig.
Wer dem oben erwähnten Programmieraufwand zur Erstellung einer Simulation entgehen
möchte, greift zu einem auf Simulationen spezialisierten Programm, wie z.B.
GoldSim [18]. Über eine graphische Benutzeroberfläche kann der Anwender dort seine
Simulation zusammenstellen und die einzelnen Komponenten konfigurieren. Dabei
kann er auf eine umfangreiche Menge von fertigen Kompontenten zurück greifen, so
dass er keine Programmierkenntnisse braucht. Am Ende der Simulation kann er sich
die Ergebnisse graphisch anzeigen lassen und mit Hilfe von mitgelieferten Werkzeugen
analysieren. Das ist alles sehr komfortabel. Inwiefern ein Anwender selbst neue Kompontenten
entwickeln kann, ist allerdings unklar. Die oben zitierte Internetseite schweigt
sich darüber aus. Die Lizenz für eine kommerzielle Nutzung von GoldSim kostet $ 3950
für das Basispaket. Für akademische Zwecke existiert eine kostenlose Version mit einem
etwas eingeschränkten Funktionsumfang. Für Zusatzpakete kommen allerdings auf jeden
Fall Kosten zwischen $ 1000 und $ 9000 hinzu (Stand 10. April 2006).
Bekannte Alternativen zu GoldSim sind z.B. MLDesigner [33], das “CoCentric Systems
Studio” [13] und das freie Ptolemy [39]. Obwohl die drei Programme jeweils einen
etwas anderen Einsatzzweck haben, ergeben sich für den Kanalcodierer dieselben Probleme.
So ist keines der Programme auf den Einsatz in der Kanalcodierung spezialisiert.
Das bedeutet, dass der Kanalcodierer eine geeignete Abbildung seines Problems auf
das Modell des Simulationsprogrammes finden muss. Das kann mitunter sehr aufwendig
und frustrierend sein. Dazu kommt, dass keines der Programme die in der Einführung
aufgelisteten Probleme beim Einsatz in Netzwerken löst. Der Anwender muss selbständig
verteilen und die einzelnen Simulationen verwalten. Simulationen migrieren oder
Sicherungspunkte erstellen ist überhaupt nicht möglich.
2.2 ICE
Die Internet Communications Engine (ICE) ist eine objektorientierte Middleware des
Softwareunternehmens ZeroC [23], das es sich zur Aufgabe gemacht hat, ein Framework
zu entwickeln, welches ebenso mächtig wie CORBA und dabei aber schlank und einfach
6

2.2 ICE
zu bedienen ist. Dazu ermöglicht ICE eine orts- und plattformtransparente Kommunikation
zwischen Objekten auf verschiedenen Rechnern.
Außerdem unterstützt ICE eine breite Auswahl an Sprachen: Neben Java und
C++ auch C#, Python, VisualBasic und PHP. Weitere Sprachen können bei kommerziellem
Bedarf hinzukommen. ICE ist auch für viele Plattformen, darunter Windows
(98SE/ME/2000/XP), Linux (i386, x86_64), Solaris 9 (SPARC), HP-UX 11.11
(PA_RISC) sowie MacOS X (10.3 und 10.4, PPC), verfügbar. Da nicht jede Sprachumsetzung
von allen Plattformen unterstützt wird, können einzelne Sprachen unter
bestimmten Umständen nicht verwendet werden. Dies betrifft jedoch nicht die in der
Implementierung von Lethe verwendeten Sprachen Java und C++.
Im Folgenden wird auf die Funktionsweise von ICE eingegangen. Anschließend werden
die Dienste erläutert, die bei der Installation von ICE mitgeliefert werden. Die Beschreibung
weiterer bekannter Middleware-Systeme ist in Abschnitt 3.2.1 ausgelagert. Dies
geschah, um unnötige Wiederholungen zu vermeiden. Der interessierte Leser kann in
den Referenzen auf das jeweilige System zusätzliche Informationen finden.
2.2.1 Funktionsweise
In diesem Abschnitt wird erklärt, wie ICE die Kommunikation zwischen einem Client
und Server ermöglicht. Dabei sei der Server ein entferntes Objekt, das Dienste anbietet,
auf die das Client-Objekt zugreifen möchte.
Kommunikation
Die Kommunikation zwischen Client und Server findet über sogenannte Proxy-Objekte
statt. Dazu muss der Client einen lokalen Proxy des Servers besitzen auf den er zugreifen
will. Im Abschnitt Auffinden von Objekten wird beschrieben, wie der Client zu
einem Proxy gelangt. Möchte der Client eine Methode auf dem Server aufrufen, benutzt
er dazu das Proxy-Objekt, das den Aufruf entgegennimmt und entsprechend der
ICE-Spezifikation [31, Seite 881 ff.] transformiert, um anschliessend einen entfernten
Methodenaufruf auf den Server auszuführen.
Die Transformation der Methodenaufrufe und speziell der Methodenparameter in ein
spezifiziertes Format erlaubt ICE eine Abstraktion von der tatsächlich verwendeten
Plattform und ermöglicht die Unterstützung der zu Beginn dieses Abschnitts aufgezählten
Systeme.
Schnittstellendefinition
Slice ist die Schnittstellen-Beschreibungssprache von ICE. Mit ihr können neben Schnittstellen
auch eigene Klassen und Datenstrukturen definiert werden, die dann für die verteilte
Kommunikation oder zum Persistieren von Daten (vgl. Freeze) verwendet werden
können.
Um Sprachen wie VisualBasic zu unterstützen, die nicht zwischen Gross- und Kleinschreibung
in Bezeichnernamen unterscheiden, differenziert auch Slice nicht zwischen ihnen.
Allerdings muss eine einmal gewählte Schreibweise beibehalten werden. Außerdem
7

2 Grundlagen
wird der Namensraum für eigene Strukturen und Parameter durch die von ICE reservierten
Wortteile (ice, ptr, prx, helper) und dem Verbot des Unterstrichs eingeschränkt.
Diese Einschränkungen werden benötigt, um Namenskollisionen zwischen generierten
Hilfsklassen und Benutzercode zu verhindern.
Die Slice-Definitionen können mit speziellen Parsern, wie zum Beispiel slice2java oder
slice2cpp, in sprachspezifischen Code transformiert werden. Desweiteren können in der
Slice-Definition sprach- und ausführungsspezifische Details angegeben werden. Dazu
zählt zum Beispiel, ob eine Sequenz in ein Array oder eine Liste in Java übersetzt werden
soll, oder ein Methodenaufruf asynchron stattfindet. Diese Informationen werden
von den entsprechenden Parsern ausgewertet und umgesetzt.
Auffinden von Objekten
ICE verwendet einen Registry genannten Namensdienst, um Objekte im verteilten System
zu finden. Dazu müssen sich neue Objekte, die einen Dienst anbieten möchten, bei
dem Namensdienst anmelden. Wird dieser anschließend von einem Client nach einem
bei ihm angemeldeten Objekt gefragt, kann er einen Proxy auf das gesuchte Objekt
zurückgeben. Dieser Proxy enthält die Adresse des entfernten Objekts und wird vom
Client für Zugriffe auf das Objekt benutzt, solange dieses existiert und erreichbar ist.
Um den Lesefluss zu erleichtern, ist in den folgenden Kapiteln ausschließlich von einem
Namensdienst im verteilten System die Rede. Gemeint ist damit immer die Registry von
ICE.
Neben der Verwendung der Registry besteht bei ICE auch die Möglichkeit, entfernte
Objekte anhand ihres Namens und ihrer Adresse (IP-Adresse und Portnummer) zu
erreichen. Für ein größeres, verteiltes System birgt diese Vorgehensweise jedoch den
Nachteil, dass Objekte nicht transparent auf andere Rechner verlagert werden können.
Hierauf wird an dieser Stelle nicht näher eingegangen, weitere Informationen finden sich
in [31].
Synchrone und asynchrone Kommunikation
ICE erlaubt sowohl synchrone als auch asynchrone Methodenaufrufe. Während bei einem
synchronen Methodenaufruf der Client blockiert ist, bis er eine Antwort vom Server
erhält, wird die Programmausführung nach einem asynchronen Aufruf normal fortgesetzt
und eine spezielle Callback-Methode gerufen, wenn die Antwort vom Server verfügbar
ist.
Desweiteren bietet ICE auch eine serverseitige asynchrone Verarbeitung von Methodenaufrufen
an: Diese erlaubt es dem Server, eine Anfrage zu einem späteren Zeitpunkt
zu bearbeiten und eine entsprechende Antwort zu senden. Dafür stellt die ICE-
Umgebung dem Server für jeden Aufruf ein sogenanntes Caller-Objekt zur Verfügung,
das die Anfrage kapselt und erst nach entsprechendem Methodenaufruf den Rückgabewert
an den Client sendet.
Ob ein Methodenaufruf asynchron stattfindet oder auf Serverseite asynchron bearbeitet
werden soll, muss in der entsprechenden Schnittstellendefinition angegeben werden
(vgl. Schnittstellendefinition).
8

2.2 ICE
Fehlertoleranz
ICE erlaubt die Replikation eines Dienstes über mehrere Knoten hinweg, so dass bei einem
Knotenausfall auf einen Replikanten zugegriffen werden kann. Dieser Zugriff erfolgt
für den Entwickler transparent durch die ICE-Umgebung.
2.2.2 Dienste
Neben der eigentlichen Funktionalität werden auch verschiedene Dienste für die Kommunikation
von ICE-Objekten angeboten. Auf die für die Diplomarbeit wichtigsten
Dienste wird im Folgenden kurz eingegangen. Eine umfassendere Erklärung für jeden
Dienst findet sich in [31].
IceGrid Der Einsatz von IceGrid erlaubt eine einfache Konfiguration und Verwaltung
von verteilten Systemen. Ihr Aufbau und die am System beteiligten Knoten können
an einer zentralen Stelle angegeben und konfiguriert werden. Anschließend lassen
sich die Dienste auf den einzelnen Knoten zentral starten, beenden und aktualisieren.
Ebenso können Änderungen am System im laufenden Betrieb eingespielt
werden.
Zusätzlich werden Load-Balancing-Informationen über die einzelnen Knoten zur
Verfügung gestellt, so dass eine Auswahl der verwendeten Dienste anhand ihrer
Auslastung möglich ist.
Freeze Freeze erlaubt es, auf einfache Art und Weise zuvor in Slice definierte Strukturen
dauerhaft abzuspeichern. Dazu werden zwei verschiedene Möglichkeiten angeboten:
FreezeMap erzeugt eine assoziative Liste, die den Zugriff auf festgelegte
Strukturen über Schlüssel-Bezeichner erlauben. Die andere Möglichkeit ist die
Benutzung des Evictors: Er erlaubt das automatische Sichern und Starten von
Diensten. Da er in der weiteren Diplomarbeit nicht verwendet wird, sei für weitere
Informationen auf [31] verwiesen.
IcePatch Um Programmcode oder Daten zu synchronisieren, bietet ICE mit IcePatch
einen einfach zu benutzenden Dienst an. Er erlaubt eine checksummenbasierte,
inkrementelle Synchronisation von Verzeichnissen.
IceStorm IceStorm ist ein einfach zu bedienender Publisher-Subscriber-Dienst, mit dessen
Hilfe sich Sender und Empfänger entkoppeln lassen. Beliebig viele Empfänger
können sich bei IceStorm für ein spezielles Thema registrieren. Möchte eine Sender
zu diesem Thema Informationen verteilen, sendet er sie an den IceStorm-Dienst,
der wiederum die Zustellung an die entsprechenden Empfänger vornimmt.
IceSSL Genaugenommen ist IceSSL kein Dienst sondern ein Plugin von ICE. Es erlaubt
die Verwendung des Secure Sockets Layer (SSL) [3] als Übertragungsprotokoll, um
die Kommunikation abzusichern. Die Authentifizierung erfolgt dabei auf Basis von
signierten Zertifikaten. Die Verwendung von IceSSL lässt sich zu einem bestehenden
System sehr einfach hinzukonfigurieren, da es transparent für die Dienste
abläuft.
9

2 Grundlagen
Desweiteren gibt es noch (Stand: Mai 2006 ) IceBox und Glacier. IceBox dient im verteilten
System als Applikationsserver und erlaubt es, die benötigten Dienste selbständig
aus Bibliotheken oder Java-Klassen bei Bedarf nachzuladen. Da er für den Entwurf
und die Implementierung des verteilten Systems von Lethe nicht benötigt wird, wird an
dieser Stelle nicht weiter auf ihn eingegangen.
Glacier ist eine einfach zu konfigurierende Firewall und zugleich Router für ICE-
Objekte. Sie kann Clientanfragen authentifizieren und filtern, außerdem kann sie auch
zusammen mit einer herkömmlichen Firewall sinnvoll eingesetzt werden, damit nicht für
jeden Dienst ein Port freigeschaltet werden muss.
2.3 XML
Die Extensible Markup Language (XML) [11] ist ein mittlerweile sehr weit verbreiteter
Standard des World Wide Web Consortiums (W3C) [48] für die Beschreibung und
Strukturierung von Daten. XML ist eine Metasprache, mit deren Hilfe man anwendungsspezifische
Sprachen erstellen kann, jedoch spezifiziert sie weder die Grammatik noch
die Sprachelemente. Dies geschieht erst mit Hilfe einer sogenannten Schemabeschreibung
(vgl. Abschnitt 2.3.1).
Die Daten werden durch Paare sich öffnender und schließender spitzer Klammern
(Tags) strukturiert, wodurch XML-Dateien menschenlesbar sind. Desweiteren gibt es
durch die weite Verbreitung von XML mittlerweile sehr gute XML-Editoren, die Benutzern
bei der Erstellung von XML-Dateien zu Hand gehen.
Eine XML-Datei heisst wohlgeformt, wenn sie den Regeln für XML entspricht. Dies
bedeutet speziell, dass für jeden öffnenden Tag ein schließender Tag auf derselben hierarchischen
Ebene existiert. Desweiteren nennt man eine XML-Datei gültig oder valide,
wenn sie das für die Anwendung spezifizierte Schema einhält.
2.3.1 XML-Schema
Da eine reine XML-Beschreibung der Daten noch keine feste Grammatik besitzt, wird
eine Möglichkeit benötigt, die Struktur der Daten zu beschreiben. Dies ermöglicht eine
leichtere Verarbeitung der Daten durch verschiedene Applikationen, da sich die Programme
darauf verlassen können, dass eine valide XML-Datei ihrer Grammatik genügt.
Die Spezifikation der Grammatik kann dabei mit Hilfe von XML-Schema erfolgen,
einer Sprache, die wiederum selbst in XML beschrieben ist. Weitere Informationen dazu
finden sich in [16, 47, 8]. XML-Schema erlaubt – im Gegensatz zu ihrer Vorgängersprache,
der in XML integrierten Document Type Definition – eine sehr feingranulare
Beschreibung der Struktur, sowie eine Beschränkungsmöglichkeit der Element- und
Attributinhalte auf spezielle Typen, wie z.B. eine Datumsangabe oder einen Bytewert.
Damit erlaubt XML-Schema bereits bei der Validierung der XML-Datei eine Überprüfung
auf die Korrektheit der Daten.
10

2.4 Java
2.3.2 XSLT
Mit Hilfe einer Extensible Stylesheet Language Transformation (XSLT) [26] können die
Daten einer XML-Datei in ein anderes, in der Transformationsdatei direkt beschriebenes
Format umgewandelt werden.
Eine Transformation besteht dabei aus der wiederholten Anwendung einzelner Transformationsvorschriften.
Diese Transformationsvorschriften, Templates genannt, werden
dann auf die angegebenen Elemente angewandt und das Ergebnis der Transformationsvorschriften
ausgegeben.
Momentan ist XSLT 1.0 (Stand: Mai 2006 ) der offizielle Standard. XSLT 2.0 liegt
derzeit nur als Candidate Recommendation des W3Cs vor. Jedoch existieren bereits
einige XSLT-Prozessoren, die XSLT 2.0 unterstützen. Da die neue Version deutliche Erleichterungen
bei der Definition von Transformationsvorschriften im Vergleich zu XSLT
1.0 besitzt, wird für Lethe die neue Version benutzt.
Im Zusammenhang mit XSLT müssen auch XPath [6] und XQuery [9] erwähnt werden,
die beide von XSLT 2.0 unterstützt werden. XPath ist eine Anfragesprache, die die
Adressierung von Elementen und Attributen anhand der hierarchischen Struktur in einer
XML-Datei erlaubt. Dazu stehen Angaben wie child für die Kinder eines Elements oder
parent für den Vater eines Elements zur Verfügung. Alternativ lassen sich Elemente
auch durch relative oder absolute Pfade adressieren.
XQuery ist eine turingvollständige Programmiersprache, die im Verbund mit XPath
einfache Abfragen von Werten in XML-Dateien erlaubt. Diese lassen innerhalb der Sprache
sortieren, vergleichen und bearbeiten. Desweiteren erlaubt XQuery Variablen und
benutzerdefinierte Funktionen.
Zusammen stellen XPath und XQuery ein mächtiges Werkzeug für XSLT dar, um
Transformationsvorschriften zu beschreiben.
2.4 Java
Obwohl Java mittlerweile weit verbreitet ist, soll an dieser Stelle ein kurzer Überblick
gegeben werden. Speziell die in der Implementierung verwendete Reflection-API und
die JDOM - und Saxon-Bibliothek werden in den nächsten Abschnitten erläutert.
Java wurde 1995 offiziell von Sun Microsystems vorgestellt. Momentan liegt die Sprache
in Version 1.5 vor, für die Implementierung der Diplomarbeit wird jedoch aufgrund
der größeren Verbreitung noch die Vorgängerversion 1.4.2 verwendet.
Sie wurde mit dem Ziel entworfen, eine einfache, plattformunabhängige und objektorientierte
Sprache zu sein. Durch fehlende Pointerarithmetik, Einfachvererbung und
einen im System integrierten GarbageCollector zur Speicherbereinigung versucht sie
Tücken, die bei der Programmierung mit C++ auftreten können, zu vermeiden.
Die Plattformunabhängigkeit von Java-Programmen wird durch die Verwendung einer
plattformspezifischen Virtual Machine (VM) erreicht. Dazu wird der Quellcode vom
Übersetzer in Bytecode umgewandelt, der von der VM interpretiert wird. Dadurch wird
die Ausführung von Java-Programmen zwar langsamer als bei gleichwertigen, kompilierten
C++-Programmen, jedoch wird dieser Geschwindigkeitsvorteil von C++ durch
11

2 Grundlagen
Just-In-Time-Übersetzer [27] und die sogenannte HotSpot-Technologie, die während der
Laufzeit Teile der Programme in Maschinencode übersetzt, weitestgehend kompensiert.
2.4.1 Reflection-API
Java-Programme enthalten eine beachtliche Menge an Laufzeifzeitinformationen, die
dazu benutzt werden, den Zugriff auf Objekte zu verifizieren und aufzulösen [45]. Auf
diese Laufzeitinformationen kann auch mit Hilfe der Reflection-API [45, Seite 645 ff.] aus
dem Programm heraus zugegriffen werden. Damit lassen sich sämtliche Informationen
über ein Objekt auslesen: Sein Name, sein Typ, welche Methodenaufrufe es erlaubt
und welche Felder das Objekt besitzt. Desweiteren kann beliebig auf die Felder und
Methoden zugegriffen werden.
Außerdem ermöglicht es die Handhabung von Objekten, deren Typ zur Programmierund
Übersetzungszeit noch nicht feststeht. Im Zusammenhang mit Lethe ist das bei
der Erstellung von Simulationsaufträgen wichtig, da erst zur Laufzeit bekannt ist, aus
welchen Modulen die Simulation besteht und wie deren Parameter aussehen.
2.4.2 JDOM
JDOM [22] ist eine einfach zu verwendende API zum Erstellen und Parsen von XML-
Dokumenten. Dazu stellt es eine einfach zu verwendente Abbildung von XML-Elementen
in Java-Klassen zur Verfügung. Dies erlaubt eine einfache Traversierung der Baumstruktur
von XML. Weiterführende Dokumentationen zu JDOM finden sich in [22, 30].
2.4.3 Saxon
Um mit Hilfe von XSLT XML-Dateien zu transformieren, wird ein entsprechendes
Prozessor-Programm benötigt. Saxon [44] ist ein solcher Prozessor, der sich als Open-
Source Bibliothek in Java verwenden lässt. In der aktuellen Version 8.6.1 unterstützt
Saxon neben XSLT 2.0, XQuery 1.0 auch die Empfehlungen des W3Cs für XPath 2.0
(November 2005).
12

3 Systementwurf
Dieses Kapitel beschreibt Entwurf und Design des verteilten Simulationssystems und
der beteiligten Komponenten. Ziel des Entwurfs ist ein einfaches verteiltes System, in
dem verschiedene Benutzer ihre Simulationen durchführen können. Das Kapitel ist in
drei große Abschnitte untergliedert: den Grundlagen von Simulationen, ihre Integration
im verteilten System und dem Zusammenspiel der einzelnen Komponenten.
Der erste Abschnitt führt das Modulkonzept ein, beschreibt den Aufbau von Simulationen
generell und wie diese formal beschrieben werden müssen, damit sie plattformunabhängig
ausgeführt werden können.
Der zweite Abschnitt befasst sich mit dem grundlegenden Aufbau des verteilten Systems
im allgemeinen und speziell mit Fragen zur Codeverteilung im verteilten System
und der Benutzer- und Rechteverwaltung, sowie Fragen zur Sicherheit, die sich durch die
Verteilung der Simulationen ergeben. Der Abschnitt schließt mit einem Überblick über
die Kommunikation im verteilten System sowie Überlegungen zur Anzahl von Benutzern
und Simulationsknoten.
Der dritte Abschnitt beschreibt Details bei der Ausführung von Simulationen. Er
klärt, wie Simulationsaufträge in das verteilte System eingespeist werden und wie diese
auf die verfügbaren Simulationsknoten verteilt und ausgeführt werden. Desweiteren
beschäftigt sich der Abschnitt mit dem Ende von Simulationen, und was mit den Simulationsergebnissen
im verteilten System passiert.
Abschließend bietet der vierten Abschnitt einen Überblick über die Dienste, die im
verteilten System aktiv sein müssen. Desweiteren stellt er die Anwenderprogramme vor,
mit denen auf das verteilte System zugegriffen werden kann.
3.1 Module und Simulationen
Simulationen in der Kanalcodierung basieren typischerweise auf den Komponenten [10]
Quelle, Encodierer, Kanal, Decodierer und Senke, die folgendermaßen (vgl. auch Abbildung
3.1) zusammenarbeiten: die Quelle erzeugt Zufallszahlen, die ein Encodierer
mit genügend Redundanz versieht, um sie möglichst sicher über den Kanal zu übertragen,
wobei durch Störungen auf dem Kanal die übertragenen Daten verändert werden
können. Anschließend versucht der Decodierer, die ursprünglichen Daten wieder zu rekonstruieren.
Die Senke vergleicht, die rekonstruierten mit den gesendeten Daten.
Diese Komponenten werden in verschiedenen Ausprägungen für viele Simulationen
benötigt. Dazu können noch weitere Komponenten wie zum Beispiel ein Interleaver und
ein entsprechender Deinterleaver zum Schutz vor Bündelfehlern hinzukommen.
Um die Entwicklungszeit für Simulationen zu verkürzen, bietet es sich deshalb an, die
Implementierung der einzelnen Komponenten zu kapseln. Die Kapselung einer Komponente
wird im folgenden als Modul bezeichnet. Eine Simulation lässt sich dann als
13

3 Systementwurf
Quelle Encodierer Kanal Decodierer Senke
Abbildung 3.1: Gebräuchlicher Aufbau von Simulationen aus einzelnen Komponenten bzw.
Modulen.
Verknüpfung mehrerer Module definieren. Dies soll im folgenden Abschnitt näher untersucht
werden und zu einem Modulkonzept führen, das es ermöglicht, aus einzelnen
Modulen eine Simulation zu erstellen.
3.1.1 Module
Ein Modul lässt sich als schwarzer Kasten ansehen, der einen oder mehrere Algorithmen
in sich vereinigt. Die Anzahl der Ein- und Ausgänge eines Moduls hängt von seiner
Funktionsweise ab und kann stark variieren. Eine Simulation lässt sich dann als Verknüpfung
einzelner Module erstellen. Dabei müssen nur die Module neu programmiert
werden, die im verteilten System noch nicht vorhanden sind. Ansonsten kann auf bereits
existente Module zugegriffen werden.
Damit ein Modul in vielen Simulationen wiederverwendet werden kann, empfiehlt es
sich, die Module möglichst allgemein zu implementieren und mit Hilfe von Konfigurationsparametern
zu spezialisieren.
Die Wiederverwendung von Modulen durch verschiedene Benutzer führt aber zu Konflikten
mit der Anforderung an die einfache Erstellung von Simulationen (vgl. die Anforderungen
in 1.2). Deshalb wird eine Beschreibung des Moduls benötigt, mit deren Hilfe
ein Benutzer feststellen kann, wie und in welcher Weise sich Module verknüpfen lassen.
Außerdem muss die Beschreibung die für das entsprechende Modul benötigten Konfigurationsparameter
enthalten. Diese sollten mit sinnvollen Standardwerten vorbelegt sein,
um einem unbedarften Benutzer die Verwendung des Moduls zu erleichtern.
Dafür werden von der Beschreibung folgende Typen bereitgestellt:
• einfache Typen, speziell string, int, long, byte, float und boolean
• Enumerationen, die einen Wert aus einer Menge von Zeichenketten annehmen
können
• komplexe Typen, wie Arrays, Tabellen und Dictionaries sowie Klassen, die
wiederum alle Typen ausser sich selbst enthalten können.
Neue Datentypen können entweder innerhalb eines Moduls oder modulübergreifend
(siehe dazu Abschnitt 3.1.2) definiert werden.
Außerdem muss die Beschreibung die Art und Anzahl der Ein- und Ausgänge enthalten.
Die Art beschreibt dabei, welcher und wie viele Datentypen von dem Modulcode
gelesen beziehungsweise geschrieben werden. Dies ermöglicht eine Aussage darüber, ob
14

3.1 Module und Simulationen
zwei Module miteinander verknüpft werden können. Dies ist genau dann möglich, wenn
sie einen Ein- bzw. Ausgang mit demselben Datentyp besitzen.
Um ein Modul in Lethe zu verwenden, werden außer der Beschreibung noch andere
Dateien benötigt: Die modulspezifische Implementierung der Schnittstelle [7, Abschnitt
4.4.2] und der Ein- und Ausgabekanäle, sowie eine Slice-Definition der im Modul verwendeten
Parameter. Die Slice-Definitionen werden benötigt, um sprachunabhängig auf
die Parameter zugreifen zu können und sie transparent mit Hilfe von ICE im verteilten
System zu versenden. Zusätzlich gibt es ein zweites Beschreibungsformat für Module,
das es dem Benutzer erlaubt, die Standardwerte der Konfigurationsparameter einfach
zu ändern. Eine Diskussion über die Implementierung von Modulen findet sich in [7,
Abschnitt 4.4.2].
3.1.2 Datentyp
Die Definition eigener Typen innerhalb von Modulen ist in manchen Fällen unvorteilhaft:
Zum einen muss ein Typ in jedem Modul definiert werden, in dem er benötigt
wird, zum anderen können nur Module miteinander verküpft werden, die einen Einbzw.
Ausgabekanal mit demselben Datentyp besitzen. Dies ist jedoch nur möglich,
wenn der entsprechende Datentyp ausserhalb der Module definiert wird, da er sonst
modulspezifisch ist. Deshalb wird ein Beschreibungsformat für Datentypen benötigt,
das von den Modulen eingebunden werden kann. Um die Verwendung für den Benutzer
möglichst einfach zu halten ist es stark an das Beschreibungsformat der Module angelehnt.
Wie bei den Modulen muss der Datentyp vor einer Verwendung zuerst in weitere
Formate konvertiert werden. Dazu gehören: eine Implementierungsdatei Typname.h, eine
Slice-Definitionsdatei gen_Typname.ice, sowie verschiedene Ausprägungen mit einer
speziellen Schemabeschreibung.
3.1.3 Simulationen
Eine Simulation besteht aus der Verknüpfung verschiedener Module nach einem bestimmten
Schema. Dabei können Module ausschließlich über Ein- oder Ausgabekanäle
mit demselben Datentyp verbunden werden.
Im Gespräch mit den Betreuern wurde deutlich, dass in der Kanalcodierung häufig
eine Simulation mit verschiedenen Parametern durchgeführt wird. Dies geschieht zum
Beispiel, um die Auswirkung unterschiedlich stark gestörter Kanäle auf den Dekodiererfolg
eines Algorithmus zu testen. Dieser Sachverhalt wird von Lethe durch das Runden-Konzept
unterstützt, das die mehrfache Durchführung einer Simulation erlaubt.
Dazu müssen die Einstellungsparameter der Module in zwei Gruppen geteilt werden:
Konfigurationsparameter, die für alle Runden identisch sind, und Einstellungsparameter,
die sich in jeder Runde ändern können. Eine Generatormatrix (vgl. [10, Seite 21
ff.]) ist ein gutes Beispiel für einen Konfigurationsparameter eines Encodierer-Moduls.
Diese Generatormatrix wird dann in allen Runden zum Kodieren der Daten verwendet.
Die Rauschleistung des Kanals ist hingegen ein Einstellungsparameter, der sich in
den einzelnen Runden häufig unterscheidet. Prinzipiell kann man sagen, dass Einstellungsparameter
die Werte sind, in denen sich die einzelnen Ausführungen unterscheiden
15

3 Systementwurf
und anhand deren Auswirkung der Benutzer die Ausführungen miteinander vergleichen
möchte.
Da die einzelnen Runden einer Simulation unabhängig voneinander sind, versucht das
verteilte System, diese parallel auszuführen, wenn genügend Ressourcen zur Verfügung
stehen. Dadurch kann eine Simulation, die beispielsweise aus sieben Runden besteht,
theoretisch sieben mal schneller durchgeführt werden als wenn die einzelnen Runden
hintereinander ausgeführt werden.
Für spezielle Simulationen kann es nötig sein, dass die Kanäle zwischen den Modulen
mit Daten initialisiert sind. Aus diesem Grund kann eine Runde in mehrere Phasen
unterteilt werden, die z.B. zur Initialisierung und Ausführung verwendet werden können.
Die Anzahl der Phasen pro Runde, sowie die aktiven Ein- und Ausgänge der Module
müssen ebenfalls in der Simulationsbeschreibung angegeben werden.
Zusätzlich muss für jedes Modul angegeben werden, wo sich der Modulcode im verteilten
System befindet. Dies ist wichtig, da der Code für die Simulationsausführung
benötigt sind.
3.1.4 Simulationsauftrag
Ein Simulationsauftrag beinhaltet alle notwendigen Informationen, um eine Simulation
im verteilten System auszuführen. Dies umfasst:
• Den der Simulation zugrunde liegenden Hypergraph (vgl. [7, Abschnitt 3.1.2]),
der durch die Vernüpfung der einzelnen Module entsteht. Dieser beinhaltet eine
Beschreibung der verwendeten Module, wie sie konfiguriert und miteinander
verknüpft sind. Der Graph ist während der gesamten Simulationsdauer konstant.
• Eine Menge von Einstellungen für die einzelnen Module.
• Eine Liste der Codeverteilungsdienste (vgl. 3.2.3), die den benötigten Code zum
Erstellen der Simulation vorhalten.
Zusätzlich benötigt ein Simulationsauftrag Metainformationen für seine Verwaltung
im verteilten System.
Eine wichtige Information ist die des Besitzers. Der Besitzer eines Simulationsauftrages
ist immer der Benutzer, der sie gestartet hat. Er reguliert den Zugriff auf die
Simulation.
Desweiteren benötigt ein Simulationsauftrag eine eindeutige Kennung im verteilten
System. Diese Kennung erlaubt einen einfachen Zugriff auf die Simulationen, wie er zum
Beispiel für das Abbrechen oder Umziehen von Simulationen benötigt wird.
Um dem Benutzer die Wiedererkennung eines Simulationsauftrags zu erleichtern, besitzt
er zusätzlich einen vom Benutzer gesetzten Namen und eine möglichst aussagekräftige
Beschreibung. Diese Informationen werden vom verteilten System nicht benötigt,
jedoch unterstützen sie den Benutzer, wenn er mehrere aktive Simulationen hat.
16

3.2 Konzeption des verteilten Systems
3.2 Konzeption des verteilten Systems
Ziel dieser Diplomarbeit ist es, Simulationen nicht nur auf Einzelplatzrechnern ausführen,
sondern auch auf mehrere Rechner verteilen zu können. Dies erlaubt zum einen eine
bessere Ausnutzung vorhandener Rechenressourcen, da die Rechner zu jedem Zeitpunkt
möglichst gut ausgelastet werden können. Zum anderen kann es für die Ausführung einer
Simulation einen enormen Geschwindigkeitsvorteil bedeuten, da Teile der Simulation auf
verschiedenen Rechnern parallel ausgeführt werden können.
Dazu wird im folgenden ein verteiltes System entworfen, in dem die in Abschnitt
3.1.4 beschriebenen Simulationsaufträge ausgeführt werden können. Die Problematik,
neue Knoten in das System hinzuzufügen und andere daraus zu entfernen, wird durch
ICE gelöst und deshalb im Systementwurf nicht weiter behandelt. Sie wird in Abschnitt
4.3.1 angesprochen.
3.2.1 Auswahl der Middleware
Die Verwendung einer Middleware erleichtert eine plattformunabhängige Entwicklung
des verteilten Systems ungemein, da diese von der tatsächlichen Rechnerplattform abstrahiert,
und eine allgemeine Umgebung anbietet, während sie sich für die tatsächliche
Umsetzung in die jeweilige Systemarchitektur kümmert.
Derzeit gibt es mehrere Standards, die für ein objektorientiertes, verteiltes System in
Frage kommen:
• CORBA[14], das von der Object Management Group (OMG) [38] spezifiziert wurde
und seither regelmäßig erweitert und verbessert wurde
• SOAP[28], das sich speziell für Web-Anwendungen durchgesetzt hat
• RMI [20] für verteilte Java-Objekte
• sowie das von Microsoft entworfene .NET [32]-Framework, das sich in den letzten
Jahren großer Beliebtheit bei der Entwicklung verteilter Anwendungen auf
Windows-Plattformen erfreut.
Das .NET -Framework von Microsoft wurde für die Diplomarbeit nicht weiter in
Betracht gezogen, da im Gegensatz zu den anderen hier beschriebenen Middleware-
Systemen die Implementierung von Microsoft ausschließlich Windows-Plattformen unterstützt.
Zwar existiert mit Mono[34] mittlerweile auch eine zu .NET kompatible Umsetzung
des Frameworks für Linux-Systeme, jedoch ergibt die Nutzung von .NET im
Rahmen dieser Arbeit keinen Vorteil gegenüber z.B. CORBA.
Für ein verteiltes System, das ausschließlich in Java programmiert ist, bietet sich
die Verwendung von RMI an. Dies ist bei Lethe jedoch nicht der Fall. Zwar ist es
möglich, RMI in Verbindung mit CORBA zu benutzen. Allerdings ist es fraglich, ob
die Verwendung von zwei verschiedenen Middleware-Systemen sinnvoll ist, wenn Java
auch von CORBA- Implementierungen direkt unterstützt wird. Denn zumindest die
Schnittstellen, auf die auch mittels CORBA zugegriffen werden soll, müssen sowohl für
RMI als auch für CORBA definiert sein.
17

3 Systementwurf
SOAP wäre eine weitere Möglichkeit gewesen. Jedoch bietet SOAP für Lethe keinerlei
erkennbare Vorteile, sondern besitzt nur den Nachteil eines im Vergleich zu ICE und
CORBA aufgeblähten und langsamen Protokolls. Dies gilt insbesondere, da Lethe keine
webbasierte Anwendung ist, ansonsten wäre die Wahl der Middleware vermutlich auf
SOAP gefallen.
Obwohl sich CORBA sicherlich auch sehr gut für die Kommunikation im verteilten
System eignet, haben Alexander Bernauer und ich uns gegen CORBA und für die unbekanntere
Middleware ICE entschieden. Diese lässt sich leicht bedienen und beinhaltet
darüber hinaus zusätzliche Dienste, die den Entwurf und die Implementierung des verteilten
Systems erleichtern. Speziell zählen dazu der IceGrid-Dienst, das IceSSL-Plugin,
das eine sichere Kommunikation zwischen den Diensten ermöglicht, und der IcePatch-
Dienst, der eine einfache und schnelle Synchronisierung von Verzeichnissen ermöglicht.
Desweiteren erlaubt ICE sowohl den asynchronen Aufruf, als auch die asynchrone serverseitige
Verarbeitung von Funktionen. CORBA sieht zwar beide auch in der aktuellen
Spezifikation [14] vor, umgesetzt ist es jedoch erst in wenigen Implementierungen.
Ein weiterer Vorteil von ICE ist sein kompakter Aufbau. Es wurde von einem kleinen
Entwicklerteam entworfen, implementiert und unter der GPL frei verfügbar gemacht.
Im Gegensatz zu CORBA, das von der OMG [38] spezifiziert und anschließend von verschiedenen
Firmen implementiert wurde. Diese Implementierungen waren früher nicht
frei verfügbar und mussten teuer erworben werden. Mittlerweile gibt es jedoch auch freie
Implementierungen, wie z.B. [1, 40].
3.2.2 Systemaufbau
Prinzipiell gibt es für die Konzeption eines verteilten Systems zwei Möglichkeiten: Das
System basiert entweder auf einem Client-Server Modell und enthält einen zentralen
Koordinator, oder es ist autonom und alle Knoten sind gleichberechtigt (siehe dazu
Abbildung 3.2). Beide Systeme haben ihre Stärken und Schwächen:
Während ein Ausfall des zentralen Koordinators zu einem Totalausfall des gesamten
Systems führen kann, kann ein Ausfall im autonomen System transparent kompensiert
werden. Allerdings ist der Verwaltungs- und Programmieraufwand für ein solches System
ungleich höher: Um den Ausfall eines Knotens kompensieren zu können, muss dieser
fehlerhafte Knoten von allen korrekten Knoten im System zuverlässig erkannt werden.
Außerdem muss dafür gesorgt werden, daß die Simulationsaufträge rechtzeitig redundant
im System repliziert werden, um den Verlust von Aufträgen durch ausgefallenen Knoten
zu vermeiden. Bei der Verwaltung durch einen zentralen Koordinator lassen sich diese
Probleme größtenteils vermeiden.
ICE unterstützt zwar beide Modelle, setzt jedoch einen speziell ausgezeichneten zentralen
Knoten voraus, auf dem ein Namensdienst (vgl. Abschnitt 2.2.1) läuft. Dieser
Namensdienst lässt sich nicht replizieren, obwohl sein Ausfall die Benutzbarkeit des
Systems stark beeinträchtigen: Die ICE-Implementierung erlaubt zwar weiterhin den
Zugriff auf bereits bekannte verteilte Objekte, jedoch können neue Objekte ohne den
Nmanesdiensr nicht mehr gefunden werden. Dieser Nachteil von ICE – zusammen mit
dem höheren Aufwand für ein autonomes System – wiegt meiner Meinung nach schwerer,
18

3.2 Konzeption des verteilten Systems
a)
Zugangspunkt
b)
Zugangspunkt
zentraler Koordinator
Zugangspunkt
Zugangspunkt
Abbildung 3.2: a) verteiltes System mit zentralem Koordinator. Der Zugriff auf das System
erfolgt immer über den Koordinator. b) autonomes System mit gleichberechtigten
Knoten und mehreren Zugangspunkten in das verteilte System.
als die Nachteile eines zentralen Koordinators und ist ausschlaggebend für die Entscheidung
für das Client-Server-Modell.
Ein Nachteil des Client-Server Modells ist, dass der zentrale Koordinator zum Engpass
werden kann und die Ausführung im verteilten System dadurch verzögert wird.
Aufgrund der geringen Kommunikation zwischen den Knoten sollte dieser Fall verteilten
System von Lethe jedoch nicht eintreten, denn eine nachrichtenbasierte Kommunikation
zwischen den Simulationsknoten und dem zentralen Koordinator findet nur statt, um
einen Simulationsauftrag zu starten oder sein Ende bekannt zu geben.
Der Entwurf wurde daraufhin optimiert, möglichst wenige Nachrichten zu benötigen.
Das Starten einer Simulation erfordert zum Beispiel maximal drei Nachrichten: eine
Nachricht zum Erstellen eines Simulationsobjekts (siehe dazu: [7, Abschnitt 3.2.2]), eine
zweite Nachricht, um das Simulationsobjekt zu initialisieren und eine letzte Nachricht,
um die Simulation zu starten. Aufgrund der Struktur der Simulationsaufträge (vgl. 3.1.4)
ist die Aufgliederung in diese drei Nachrichten sinnvoll, da sie eine effiziente Wiederverwendung
der Simulationsobjekte erlaubt: Für die Simulation einer weiteren Runde
kann das einmal erstelle Simulationsobjekt mit Angabe der Rundennummer neu gestartet
werden (vgl. [7, Abschnitt 3.2.2]), die Nachrichten zum Erstellen und Initialisieren
des Simulationsobjekts entfallen.
Zusätzliche Kommunikation findet bei verwaltungsbedingten Zugriffen auf die Simulationen
statt. Dazu zählen das Anhalten und Fortführen von Simulationen, das Abbrechen
und das Erstellen von Sicherungspunkten. Da diese nur ein oder zwei Nachrichten
benötigen, und eher die Ausnahme als die Regel darstellen, sollten sie vernachlässigbar
sein.
Problematisch hingegen könnte der Rechenaufwand innerhalb des zentralen Koordinators
sein. Immerhin muss er die Anfragen der Benutzer bearbeiten, Simulationsaufträge
verwalten und Statusnachrichten der Simulationsknoten entgegennehmen. Sollte sich
19

3 Systementwurf
herausstellen, das diese Aufgaben den zentralen Koordinator spürbar verlangsamen, so
besteht in ICE die Möglichkeit, dem zentralen Koordinator mehrere Threads zur Verfügung
zu stellen. Speziell auf einer Mehrprozessor-Maschine sollte dies zu einer deutlichen
Beschleunigung führen.
3.2.3 Codeverteilung
Wird auf einem Knoten eine Simulation neu gestartet, so muss sie dort aus den Code-
Dateien neu erstellt werden (siehe [7, Abschnitt 3.2.2]). Dies setzt voraus, dass die
Modulimplementierungen auf den jeweiligen Knoten verfügbar sind, was aber dem Entwurfsziel
der leichten Wartbarkeit von Lethe widerspricht. Änderungen an den Implementierungen
einzelner Module würden dann ein Update der entsprechenden Implementierung
auf allen Knoten erfordern.
Dieses Problem lässt sich durch eine zentrale Codeverteilung umgehen. Sie muss Zugriff
auf die Beschreibung und Implementierung aller verwendbaren Module haben, und
diese bei Bedarf zur Verfügung stellen. Die Verteilung der Dateien kann idealerweise
über den IcePatch-Dienst von ICE erfolgen. Da IcePatch immer komplette Verzeichnisse
überträgt, muss allerdings für jede Simulation ein eigenes Verzeichnis mit den
benötigten Dateien angelegt werden.
Um die Codeverteilung zu nutzen, müssen vor dem Starten eines Simulationsauftrags
alle von der Simulation benötigten Module und Typen bei dem Codeverteilungsdienst
unter der Simulations-ID eingetragen werden. Anschließend kann der Generator von
diesem Dienst alle Ressourcen zu dieser ID anfordern. Dazu erhält er von der Codeverteilung
einen lokalen Proxy auf einen IcePatch-Server zugeteilt, über den er die zuvor
angemeldeten Ressourcen synchronisieren kann. Dabei tritt jedoch das Problem auf,
dass der Codeverteilungsdienst nicht wissen kann, wann ein Client seine Synchronisierung
beendet hat und er den entsprechenden IcePatch-Server stoppen kann. Dies kann
durch einen speziellen Aufruf des Clients bei der Codeverteilung gelöst werden, so dass
diese den IcePatch-Server anhalten kann. Ebenso muss eine Simulation ihr Ende der
Codeverteilung bekannt geben, damit diese die von der Simulation benötigten Ressourcen
wieder freigeben kann. Geschieht dies nicht, sammeln sich immer mehr unbenutzte
Verzeichnisse an, welche dann manuell gelöscht werden müssen.
Um nicht allen Benutzern des verteilten Systems die eigenen Module zur Verfügung
zu stellen (z.B. bei industriellen Entwicklungen oder zum Testen von unausgereiftem
Modulcode), besteht die Möglichkeit, verschiedene Dienste zur Codeverteilung zu verwenden
und sogar private Dienste zu starten, die alle Module enthalten, die der Benutzer
nicht weitergeben möchte. Dabei muss sichergestellt sein, dass die eigenen Dienste zur
Codeverteilung aktiv sind, während der Simulationsauftrag im verteilten System bearbeitet
wird, da bei jeder neuen Erzeugung eines Simulationsobjekts auf den Dienst
zugegriffen werden muss.
3.2.4 Benutzer- und Rechteverwaltung
Die gemeinsame Nutzung des Systems durch mehrere, nicht gleichberechtigte Benutzer
erfordert sowohl eine Benutzerverwaltung als auch ein entsprechendes Rechtesystem,
20

3.2 Konzeption des verteilten Systems
g = Obergruppe von g
g = Benutzer
Aktion für Benutzer/
Gruppe g verboten?
ja
nein
Aktion verboten
Aktion für Benutzer/
Gruppe g erlaubt?
ja nein
Aktion erlaubt
Existiert eine
Obergruppe von g?
ja nein
Aktion verboten
Abbildung 3.3: Schema zur Überprüfung, ob ein Benutzer oder eine Gruppe das Recht zur
Ausführung einer bestimmten Aktion hat.
welches den gemeinsames Zugriff auf die Simulationen in geeigneter Weise einschränkt.
Dafür bieten sich mehrere Möglichkeiten: Die Rechte können mit Hilfe von Access Control
Lists [49] durchgesetzt werden, wobei für jede Simulation Zugriffsrechte für verschiedene
Benutzer gespeichert werden können. Soll nun eine Aktion auf eine Simulation
ausgeführt werden, so kann in ihrer Zugriffsliste überprüft werden, ob die Aktion
zulässig ist. Dieses Verfahren hat den Nachteil, das für jede Simulation eine solche Liste
von erlaubten Aktionen geführt und gesichert werden muss.
Da anzunehmen ist, dass typischerweise mehr Simulationen ausgeführt werden als
Benutzer vorhanden sind und die Zugriffsrechte auf eine Simulation lediglich von dem
Benutzer und der Simulation abhängen, ist eine Verwaltung in Form einer Role Based
Access Control (RBAC) [15] sinnvoller. Dabei sind die Zugriffsrechte nicht Bestandteil
der Simulationen selbst, sondern Eigenschaften der Benutzer. Bei RBAC gehört jeder
Benutzer genau einer Gruppe an, welche selbst wieder Mitglied genau einer anderen
Gruppe sein kann. Dadurch ergibt sich eine baumähnliche Struktur mit Gruppen als
innere Knoten und den Benutzern als Blätter. Genaugenommen ist diese Struktur ein
Wald, da es mehrere unabhängige Bäume geben kann. Jedem Benutzer und jeder Gruppe
können beliebig viele Aktionen erlaubt oder verboten werden. Diese Rechte werden
jeweils auf alle Mitglieder einer Gruppe vererbt, so dass sich, wie in Abbildung 3.3
gezeigt, leicht bestimmen lässt, ob die Rechte für einen speziellen Benutzer vorhanden
sind oder nicht.
Die ersten beiden Entscheidungen (Benutzer oder Gruppe darf nicht bzw. darf die Aktion
durchführen) sind intuitiv verständlich. Ihre Reihenfolge stellt sicher, dass zuerst
die Verbote geprüft werden und erst dann die erlaubten Rechte. Die dritte Entschei-
21

3 Systementwurf
any
Gast
Student
Mitarbeiter
G1
St1
St2
Professor
Assistent
P A1 A2
Abbildung 3.4: Exemplarischer Aufbau einer Gruppenhierarchie, bestehend aus den Gruppen
Gast, Student, Mitarbeiter, Professor und Assistent, mit einem gemeinsamen
Ursprung. Tatsächliche Benutzer sind G1 (Gast), St1 und St2 (Student), P
(Professor) und A1 und A2 (Assistent). Hat die Gruppe Mitarbeiter das Recht,
Simulationen von Studenten anzuhalten, so könnte A1 eine Simulation von St2
anhalten.
dung anhand der Gruppenzugehörigkeit erlaubt die dynamische Vererbung von Rechten,
so dass sich eine Änderung an den Rechten einer Gruppe sofort auf ihre Mitglieder
auswirkt. Außerdem löst sie das Dilemma, wenn innerhalb der Gruppenhierarchie sich
widersprechende Rechte definiert sind. In diesem Fall hat das Recht Vorrang, das sich
am nächsten auf dem Weg vom Blatt zur Wurzel befindet.
Dieses Vorgehen erlaubt eine einfache und intuitive Rechteverwaltung, da Gruppen
für bestimmte Aktionen vordefiniert werden können und bei den einzelnen Benutzern
nur noch davon abweichende Rechte explizit angegeben werden müssen. Im universitären
Bereich böte sich beispielsweise folgende Gruppeneinteilung an: Die Gruppe Gast, deren
Mitglieder Simulationen starten und abbrechen dürfen; eine Gruppe der Studenten, die
zusätzlich Simulationen anhalten oder fortführen können; die Mitarbeiter, die zudem
in der Lage sind, Simulationen umzuziehen und weiter in Assistenten und Professoren
unterteilt sind. Dieser Aufbau ist in Abbildung 3.4 exemplarisch dargestellt.
Diese Vorgehensweise verhindert einen unbefugten Zugriff. Da es aber möglich sein
soll, unter Umständen auch auf fremde Simulationen zuzugreifen, müssen die Rechte und
Aktionen erweitert werden. Eine solche Situation tritt zum Beispiel ein, wenn ein Mitarbeiter
eine dringende Simulation durchführen will, alle Ressourcen jedoch von Studenten
belegt sind. In diesem Fall soll es möglich sein, das der Mitarbeiter die Simulationen
der Studenten anhalten kann, um seine Simulation durchzuführen. Andersherum sollen
Studenten jedoch keinen Zugriff auf die Simulation des Mitarbeiters erhalten. Deshalb
wird eine Erweiterung der Aktionen und Rechte benötigt, um die Information auf welche
Benutzergruppe ein Recht angewandt werden darf. Sind Benutzer und Besitzer der
22

3.2 Konzeption des verteilten Systems
Simulation identisch, so wird das ursprüngliche Verfahren beibehalten, ansonsten wird
das Verfahren, wie in Abbildung 3.5 dargestellt, erweitert.
Zu beachten ist die Änderung zu Beginn der Überprüfung: Sie bedeutet, das sich
Zugriffsrechte sowohl aus Benutzer- als auch Besitzersicht vererben. Solange keine explizites
Verbot oder eine explizite Erlaubnis vorliegen, wird in die Gruppenhierarchie
des Besitzers einer Simulation aufgestiegen, um zu prüfen, ob Rechte auf diese Gruppe
vorliegen.
Somit müsste der Mitarbeiter aus dem letzten Beispiel das Recht besitzen, zusätzlich
Simulationen von Benutzern aus der Gruppe der Studenten anhalten zu dürfen. Dies
ist auch dann möglich, wenn die Gruppe der Studenten weiter unterteilt wurde in Studentengruppen
für einzelne Abteilungen, sofern dem Mitarbeiter nicht der Zugriff auf
einzelne Abteilungsgruppen explizit verboten wurde.
Bisher wurde das Rechtesystem immer im Zusammenhang mit Simulationen betrachtet.
Das ist sicher auch der wichtigste Anwendungsbereich für die Rechteüberprüfung,
allerdings ist sie nicht darauf beschränkt. So wird das Rechtesystem auch zur Zugriffsbeschränkung
auf die Benutzerverwaltung selbst verwendet. Dies verhindert ein unbefugtes
Anlegen, Ändern und Löschen von Benutzern und Gruppen. Desweiteren können
die bereits definierten Aktionen einfach erweitert werden, um eine Rechteverwaltung für
zukünftige Aufgaben des verteilten Systems zu erlauben.
Für eine einfachere Benutzung können die Aktionen in Kategorien eingeteilt werden.
Damit ist es möglich, Benutzern und Gruppen den Zugriff sowohl auf einzelne Aktionen
als auch auf komplette Kategorien zu erlauben oder zu verbieten. Dabei entspricht eine
Kategorie der Menge aller in ihr definierten Aktionen.
3.2.5 Sicherheit
Das Thema Sicherheit im verteilten System muss unter verschiedenen Aspekten betrachtet
werden: Zum einen unter der Ausfallsicherheit, zum anderen darunter, wie sichergestellt
werden kann, dass keine unerlaubten Zugrifffe im verteilten System durchgeführt
werden können.
Die Ausfallsicherheit von Simulationsknoten wird dadurch gewährleistet, dass die auf
ihnen ausgeführten Simulationen von dem zentralen Koordinator gesichert werden. Fällt
ein Simulationsknoten aus, kann der Koordinator die entsprechende Simulation auf einem
anderen Knoten neu starten. Der zentrale Koordinator darf die Simulationsaufträge
jedoch nicht ausschließlich im Speicher halten, sondern muss sie auch gegen einen eigenen
Ausfall sichern, indem er sie zum Beispiel in einer Datenbank persistiert. Außerdem
muss er auch seinen internen Zustand sichern, um einen Ausfall kompensieren zu können.
Die Zugriffskontrolle auf das verteilte System ist wesentlich schwieriger zu gewährleisten,
da durch die Verwendung von ICE die Dienste im verteilten System theoretisch
jedem zugänglich sind, der die entsprechenden Schnittstellen kennt. Problematisch wird
dies bezüglich den Simulationen. Wenn jeder direkt auf die Simulationsobjekte zugreifen
und diese manipulieren kann, ist es schwierig, ein vernünftiges Rechte- und Verwaltungssystem
durchzusetzen. Jedes Simulationsobjekt muss dann selbst dafür sorgen,
dass keine unbefugten Zugriffe ausgeführt werden können. Da sich die Simulationsob-
23

3 Systementwurf
g' = Obergruppe von g'
g' = Gruppe des Besitzers
g = Benutzer
g = Obergruppe von g
Aktion für Benutzer/Gruppe g
auf Gruppe g' explizit verboten?
ja
nein
Aktion verboten
Aktion für Benutzer/Gruppe g
auf Gruppe g' explizit erlaubt?
ja
nein
Aktion erlaubt
Existiert eine
Obergruppe von g?
ja nein
Existiert eine
Obergruppe von g'?
ja
nein
Aktion verboten
Abbildung 3.5: Schema zur Überprüfung, ob ein Benutzer oder eine Gruppe das Recht zur Ausführung
einer bestimmten Aktion hat, wenn er nicht Eigentümer des Objektes
ist, auf das die Aktion ausgeführt werden soll.
24

3.2 Konzeption des verteilten Systems
Zone 1
nur Serverzertifikate
Zone 2
Client- und Serverzertifikate
Benutzer1
zentraler
Koordinator
Benutzer2
Simulationsknoten
Abbildung 3.6: Aufteilung des verteilten Systems in zwei Zonen mit unterschiedlicher Authentifizierung.
Die Pfeile geben die Richtung der Authentifizierung bei einem Verbindungsaufbau
an.
jekte ausschließlich auf die Simulation konzentrieren sollen, muss dieser Zugriff generell
verhindert werden.
ICE bietet dafür unter anderem eine leicht konfigurierbare und für die Simulationsobjekte
transparente Router- und Firewall-Lösung names Glacier an. Sie erlaubt es, eigene
Filterprogramme zu schreiben und mit Hilfe von Session-IDs den Zugriff auf bestimmte
Dienste zu verweigern. Allerdings muss der Zugriff über den Router in der Konfiguration
auf Benutzerseite angegeben werden und wäre damit leicht zu umgehen.
Um das zu verhindern, müssen sich sämtliche Simulationsknoten in einem privaten,
von den Benutzern nicht erreichbaren Netz befinden. In diesem Fall würde Glacier zwischen
den Benutzern und dem privaten Netz vermitteln und unbefugte Zugriffe abfangen.
Da dieser Ansatz ein eigenes Subnetz für die Simulationsknoten benötigt, wurde er
wieder verworfen.
Stattdessen wird mit Hilfe von IceSSL, einem weiteren Plugin von ICE, das verteilte
System in zwei Zonen aufgeteilt: In der einen Zone befinden sich die Benutzer, in der
anderen Zone die Simulationsknoten. Dazwischen gibt es Dienste wie den zentralen
Koordinator, die aus beiden Zonen erreicht werden können, wie Abbildung 3.6 zeigt.
Die Trennung der beiden Zonen erfolgt mit Hilfe von SSL und digitalen Zertifikaten:
In der Zone 1 müssen sich lediglich die Server mit gültigen Zertifikaten gegenüber den
Clients authentifizieren. Zone 2 hingegen erfordert zusätzlich gültige Client-Zertifikate,
ansonsten kann die SSL-Verbindung nicht aufgebaut werden.
Die generelle Verwendung von Server-Zertifikaten bei allen Diensten im verteilten
System verhindert auch eine andere Sicherheitslücke: Die Fälschung eines Dienstes. So
könnte ein Angreifer den Authentifizierungsdienst fälschen, um an die Zugangsdaten
der Benutzer von Lethe zu gelangen. Dies ist in einem SSL-geschützten Netzwerk nicht
mehr ohne weiteres möglich, da das benötigte Zertifikat fehlt. Um diese Angriffsart zu
verhindern, ist es notwendig, die Zertifikate möglichst gut zu schützen.
Eine Rechteverwaltung verhindert das Ausführen von unberechtigten Aktionen. Damit
ein Benutzer nicht unter fremdem Namen Aktionen ausführen kann, ist es wichtig,
25

3 Systementwurf
das sich jeder, der auf das verteilte System zugreifen möchte, sich zuvor dem System
gegenüber authentifiziert hat. Bei erfolgreicher Authentifikation erhält der Benutzer eine
Session-ID zugewiesen, die ihn fortan im Zusammenhang mit seinem Benutzernamen im
verteilten System ausweist und jederzeit von den einzelnen Komponenten überprüft werden
kann. Da die Session-ID nur innerhalb des verteilten Systems verwendet wird und
hier die Kommunikation geschützt ist, ist ein Diebstahl dieser ID durch einen Angreifer
höchst unwahrscheinlich. Dazu müsste er zuerst einen eigenen Dienst mit entsprechendem
Serverzertifikat in das verteilte System einbringen, den der Benutzer diesen Dienst
auch in Anspruch nimmt, damit der Angreifer an die Session-ID gelangt.
3.2.6 Kommunikation zwischen Komponenten
Die Verknüpfung der einzelnen Komponenten ergibt ein System, wie in Abbildung 3.7
zu sehen ist, mit folgenden Kommunikationspartnern:
• Die Benutzer kommunizieren mit dem zentralen Koordinator für den Zugriff auf
das verteilte System, und der Codeverwaltung, um die für eine Simulation benötigten
Module anzumelden. Zuallererst müssen sie sich jedoch bei dem Authentifizierungsdienst
am System anmelden.
• Der zentrale Koordinator kommuniziert mit den Simulationsknoten, um neue Simulationen
zu starten oder laufende Simulationen anzuhalten, abzubrechen oder
umzuziehen. Desweiteren prüft er bei der Rechteverwaltung, ob die Ausführung
einer Benutzeraktion erlaubt ist.
• Die Simulationsknoten konnektieren sich zu der Codeverteilung, wenn sie eine neue
Simulation erstellen möchten. Sie teilen dem zentralen Koordinator Fehler in der
Simulation oder das Ende der Simulation mit.
3.2.7 Systemgröße
Eine wichtige Frage bezüglich eines verteilten Systems ist die nach seiner Größe. Dabei
muss unterschieden werden zwischen der Anzahl der Benutzer, die zeitgleich auf das
verteilte System zugreifen können und der Zahl an Knoten im verteilten System, die
ohne empfindliche Geschwindigkeitseinbußen verwaltet werden können.
Wie man in Abbildung 3.7 sieht, wird der Hauptteil der Kommunikation über den
zentralen Koordinator durchgeführt. Besonders bei den Aufrufen wie dem Starten von
Simulationen auf Simulationsknoten, das bis zu mehreren Minuten dauern kann, ist es
deshalb wichtig, dass die Ausführung des zentralen Koordinators nicht blockiert wird.
Aus diesem Grund werden sowohl die Anfrage des Benutzers, als auch die Methodenaufrufe
zu den Simulationsobjekten im zentralen Koordinator asynchron ausgeführt.
Dadurch kann der Koordinator weitere Benutzeranfragen entgegennehmen, während er
z.B. auf die Erstellung eines Simulationsobjekts wartet.
Die Zahl der Benutzer, die gleichzeitig das verteilte System benutzen können, hängt
damit stark von dem Durchsatz im zentralen Koordinator ab. Für eine Benutzergröße
von 50 bis 70 Personen, wie sie in der Abteilung, in der Lethe eingesetzt werden soll,
26

3.2 Konzeption des verteilten Systems
Benutzer1
Benutzer2
Codeverteilung1
Authentifizierung
zentraler
Koordinator
Rechteverwaltung
Codeverteilung2
Simulationsknoten
Abbildung 3.7: Kommunikation im verteilten System zwischen den einzelnen Komponenten:
Benutzer, Simulationsknoten, zentraler Koordinator, Codeverteilung, Authentifizierung
und Rechteverwaltung.
zu finden ist, sollten diese Überlegungen keine Auswirkung auf die Benutzbarkeit haben.
Denn neben dem tatsächlichen Durchsatz des zentralen Koordinators stellt sich
auch die Frage nach dem typischen Benutzer: Da die Simulationen von Algorithmen zur
Kanalcodierung sehr zeitintensive Simulationen sind (vgl. dazu Abschnitt 3.3.1), wird
die Interaktion eines Benutzers mit dem verteilten System entsprechend sparsam ausfallen,
so dass Lethe eine weit höhere Benutzerzahl erlaubt, als der reine Durchsatz im
Koordinator vermuten lässt.
Die tatsächliche Obergrenze für die Benutzerzahl lässt sich jedoch nur in einem Feldversuch
feststellen. Sollte sich diese Obergrenze als zu niedrig erweisen, besteht die
Möglichkeit, dem zentralen Koordinator mehrere Ausführungseinheiten durch das ICE-
Framework zur Verfügung zu stellen.
Die Anzahl der Simulationsknoten im verteilten System wird durch ihre Verwaltung
im Koordinator begrenzt. ICE erlaubt theoretisch beliebig viele Knoten, jedoch spielt
die Anzahl der Simulationsknoten bei der Verteilung von Simulationen (siehe dazu Abschnitt
3.3.3) eine wichtige Rolle. Die im zentralen Koordinator verwendeten Algorithmen
haben eine Komplexität von maximal O(N log N). Dies kommt hauptsächlich durch
die Sortierung der Simulationsknoten nach ihrer momentanen Auslastung zustande. Für
eine realistische Anzahl von 50 bis 100 Knoten im verteilten System sollte die Sortierung
die Ausführung nicht behindern. Es gibt sicher eine Schwelle, bei deren Überschreiten
die Verwendung eines autonomen Systems zeitsparender ist. Dies wurde jedoch im Rahmen
der Diplomarbeit nicht nachgewiesen und stellt damit lediglich eine Vermutung
dar.
27

3 Systementwurf
Simulation starten
Benutzer:
zentrale Komponente:
Rechteverwaltung:
Generator:
Simulationsobjekt:
.starte Simulation
a / 1) .überprüfe Rechte
a / 1) .Aktion erlaubt
.erzeuge Simulation
b / 1) .erzeuge Objekt
.Simulation erzeugt od. Fehler
b / 1) .Objekt erzeugt
.Simulation angenommen / Fehler
Abbildung 3.8: Benötigte Kommunikation, um einen Simulationsauftrag in das verteilte System
einzuspeisen.
Der zentrale Koordinator muss jedoch nicht nur Benutzeranfragen bearbeiten, sondern
auch Statusmeldungen von den Simulationsobjekten entgegen nehmen. Deshalb
ist nicht nur die Anzahl der Benutzer, die gleichzeitig auf den Koordinator zugreifen
wollen, entscheidend für den Durchsatz, sondern auch die Zahl der Simulationsobjekte.
Die Simulationsobjekte kontaktieren den zentralen Koordinator, wenn die Durchführung
ihrer Simulation beendet ist. Dies kann durch einen Laufzeitfehler im verwendeten Modulcode
passieren oder durch das Ende der Simulation. Eine solche Nachricht löst beim
Koordinator meist weitere Nachrichten aus, da der Benutzer bei einem Fehler möglichst
sofort darüber informiert werden soll. Außerdem muss der Status des entsprechenden
Simulationsauftrages angepasst werden. Dennoch ist im praktischen Einsatz die Zahl
dieser Nachrichten gering, da sie immer das Ende einer Simulation kennzeichnen.
Die Schnittstellen im zentralen Koordinator sind auf eine minimale Anzahl an Nachrichten
optimiert. Deutlich wird das an folgenden drei Beispielen: dem Hinzufügen einer
neuen Simulation in das verteilte System, dem Abbrechen einer Simulation und dem
Umziehen einer Simulation auf einen anderen Simulationsknoten.
Abbildung 3.8 zeigt die benötigte Kommunikation, um einen neuen Simulationsauftrag
in das verteilte System einzubringen: Der Benutzer übergibt den Simulationsauftrag
an den zentralen Koordinator. Nach erfolgreicher Überprüfung, ob der Benutzer
überhaupt Simulationen starten darf, lässt der Koordinator die Simulation auf einem
beliebigen Simulationsknoten erzeugen. Dies hat einen einfachen Grund: Tritt beim Bauen
der Simulation ein Fehler auf, so kann der zentrale Koordinator den Benutzer sofort
darüber informieren. Konnte die Simulation hingegen erfolgreich erzeugt werden, so bestätigt
der Koordinator die Annahme des Simulationsauftrags gegenüber dem Benutzer
und kann ihn in die Warteschlange der auszuführenden Simulationen einreihen.
Abbildung 3.9 zeigt, wie eine Simulation im verteilten System abgebrochen werden
kann. Nachdem der zentrale Koordinator den Auftrag dazu vom Benutzer erhalten hat
28

Simulation abbrechen
3.3 Simulationsablauf im verteilten System
Benutzer:
zentrale Komponente:
Rechteverwaltung:
Simulationsobjekt:
.Simulation abbrechen
1) .überprüfe Rechte
1) .Aktion erlaubt
.Simulation abgebrochen
.Simulation abbrechen
Abbildung 3.9: Kommunikation, um eine laufende Simulation abzubrechen.
und dieser die entsprechenden Rechte zu einem Abbruch der Simulation besitzt, beendet
der Koordinator mit einer Nachricht das entsprechende Simulationsobjekt, sofern die
Simulation aktiv ist. Ist die Simulation zu diesem Zeitpunkt pausiert, entfällt diese
Nachricht, und der Simulationsauftrag wird direkt aus der Warteschlange gelöscht. Es
werden also entweder vier – dem Benutzer fehlen die entsprechenden Rechte oder die
Simulation ist pausiert – oder fünf Nachrichten benötigt.
Mehr Nachrichten sind nötig, um eine Simulation umzuziehen, wie in Abbildung 3.10
gezeigt wird. Ist die Simulation aktiv, so muss zuerst ein Sicherungspunkt von der Simulation
erzeugt und das Simulationsobjekt vom zentralen Koordinator beendet werden.
Anschließend wird auf dem neuen Simulationsknoten ein neues Simulationsobjekt erzeugt,
das gestartet und mit dem entsprechenden Sicherungspunkt für die Simulation
initialisiert wird.
3.3 Simulationsablauf im verteilten System
Dieser Abschnitt soll klären, wie die Simulationen im verteilten System tatsächlich ausgeführt
werden. Dazu zählt auch, wie Benutzer mit dem verteilten System interagieren
können, um zum Beispiel Informationen zu ihren laufenden Simulationen zu erhalten.
3.3.1 Entgegennahme und Verwaltung von Simulationsaufträgen
Zur Entgegennahme von Simulationsaufträgen wird eine spezifizierte Schnittstelle im
verteilten System benötigt. Um den Anforderungen an Lethe gerecht zu werden, muss
diese Schnittstelle Methoden für folgende Aktionen bereitstellen:
• Starten und Abbrechen von Simulationen
• Anhalten und Fortführen von Simulationen
• Verlagern von Simulationen auf andere Simulationsknoten
29

3 Systementwurf
Simulation umziehen
Benutzer:
zentrale Komponente:
Rechteverwaltung: Simulationsobjekt1:
Generator: Simulationsobjekt2:
.Simulation umziehen
a / 1) .überprüfe Rechte
.Simulation umgezogen
a / 1) .Aktion erlaubt
.Simulation anhalten
.Sicherungspunkt für Simulation
.Simulation beenden
.Simulationsobjekt erzeugen
.Simulationsobjekt erzeugt
.Simulation mit Sicherungspunkt starten
.Simulation gestartet
b / 1) .erzeuge Objekt
>
b / 1) .Objekt erzeugt
Abbildung 3.10: Notwendige Nachrichten, um eine Simulation von einem Knoten zum nächsten
umzuziehen. Dazu muss die Simulation auf einem Knoten abgebrochen, und
auf dem nächsten neu gestartet werden.
Bei der Annahme von Simulationsaufträgen müssen diese gleich gesichert werden.
Diese Vorgehensweise verhindert, dass Aufträge durch den Ausfall eines Knotens im
verteilten System verloren gehen können, da ein Auftrag alle Informationen beinhaltet
um eine Simulation zu starten.
3.3.2 Erstellen von Sicherungspunkten
Simulationen in der Kanalcodierung arbeiten oft mit sehr großen Datenmengen, um
statistische Fehler zu minimieren. Dies führt meist zu langen Rechenzeiten von mehreren
Tagen bis hin zu einigen Wochen. Deshalb ist es sinnvoll, in regelmäßigen Intervallen
Sicherungspunkte der Simulationen anzulegen und gemeinsam mit dem dazugehörenden
Simulationsauftrag zu speichern. Dabei muss ein Sicherungspunkt alle Informationen
enthalten, um die Simulation später an dieser Stelle fortsetzen zu können. Fällt dann
ein Simulationsknoten aus, auf dem eine Simulation läuft, kann diese auf einem anderen
Simulationsknoten von ihrem letzten Sicherungspunkt aus fortgesetzt werden. Das setzt
voraus, dass sich Sicherungspunkte von den Simulationen erstellen lassen können, wie
in [7, Absschnitt 3.1.9] diskutiert wird.
Sicherungspunkte können sowohl von den Benutzern veranlasst werden, als auch vom
zentralen Koordinator in regelmäßigen Abständen angefordert und abgespeichert werden.
Dies hat den Vorteil, dass sich die Abstände, in denen Sicherungspunkte angelegt
werden, an einer zentralen Stelle konfigurieren lassen. Standardmäßig fordert der zentrale
Koordinator nach jeder Stunde einen neuen Sicherungspunkt an, wenn der vorherige
Sicherungspunkt veraltet ist.
30

3.3 Simulationsablauf im verteilten System
Eine weitere Möglichkeit wäre gewesen, dass die Simulationsobjekte selbst dem zentralen
Koordinator mitteilen, wann sie bei der Simulationsausführung an einer Stelle
angelangt sind, an denen sich ein Sicherungspunkt effizient, also mit möglichst geringem
Datenvolumen, erstellen lässt. Dies hat jedoch den Nachteil, dass die Erstellung
von Sicherungspunkten abhängig von der Simulation ist: Es kann Simulationen geben,
die alle fünf Minuten in die Lage kommen, einen Sicherungspunkt zu erzeugen, und
Simulationen, die nie in diesen Zustand gelangen. Deshalb kann bei diesem Verfahren
nicht sichergestellt werden, dass Sicherungspunkte überhaupt in regelmäßigen Abständen
erzeugt werden, im Gegensatz zu der Vorgabe durch den zentralen Koordinator, der
regelmäßig Sicherungspunkte erzwingt.
3.3.3 Verteilen von Simulationen
Typischerweise sollen im Normalfall mehr Simulationsaufträge ausgeführt werden, als
Ressourcen im verteilten System vorhanden sind. Aus diesem Grund wird ein Kalkül
benötigt, das die Ressoucenzuteilung auf die Aufträge optimiert. Dabei muss das Kalkül
mehreren Anforderungen gerecht werden: Einerseits soll es möglich sein, Simulationen
mit Prioritäten zu versehen. Dabei sollen höherpriorisierte Simulationen bevorzugt ausgeführt
werden. Andererseits ist jedoch zu beachten, das niederpriorisierte Simulationen
nicht ausgehungert werden, d.h. wegen immer neuen höher priorisierten Simulationen
nie zur Ausführung kommen. Das ist am einfachsten zu erreichen, wenn auch das Alter
der Simulation im Kalkül berücksichtigt wird. Eine mögliche, in Lethe verwendete
Formel ist:
points = prio · age + α · finishedRounds + β · pausedRounds (3.1)
Dabei werden die Simulationen mit den höchsten Punktestand bei der Ressourcenzuteilung
bevorzugt. Außerdem können Gruppen und Benutzern eine Priorität zugewiesen
werden, die über prio direkt in den Punktestand einfließt. Das Alter der Simulation wird
durch age berücksichtigt. Damit soll verhindert werden, das Simulationen im verteilten
System aushungern können. finishedRounds sind zusätzliche Punkte für bereits beendete
Runden (vgl. 3.1.3) einer Simulation, gewichtet mit einem Faktor α; pausedRounds
sind zusätzliche, mit β gewichtete Punkte für vom Benutzer explizit angehaltene Runden
(vgl. Schnittstellenbeschreibung in Abschnitt 3.3.1) einer Simulation. Der Einfluß
von finishedRounds und pausedRounds erlaubt die bevorzugte Ausführung von fast vollständig
durchgeführten Simulationsaufträgen und belohnt Benutzer, die eigene Simulationsrunden
explizit angehalten haben und deren Simulationsauftrag dadurch weniger
Ressourcen belegen kann.
3.3.4 Ausführen von Simulationen
Um eine Simulation auszuführen, muss auf dem entsprechenden Simulationsknoten ein
dazugehörendes Simulationsobjekt für die Simulation vorhanden sein. Ansonsten muss
ein solches neu erzeugt werden. Diese Aufgabe übernimmt ein Generator, der aus den
entsprechenden Modulcodes ein Simulationsobjekt erzeugt, das mit dem Simulationsauftrag
initialisiert wird. Das Simulationsobjekt kann entweder mit einer neuen Simulation
31

3 Systementwurf
beginnen, oder eine ältere Simulation weiterführen. Da die Ausführung von Simulationen
Thema der Diplomarbeit von Alexander Bernauer ist [7], soll an dieser Stelle nicht
näher darauf eingegangen werden.
3.3.5 Ende einer Simulation
Ist eine Simulation beendet, möchte der Benutzer üblicherweise auf die Ergebnisse der
Simulation zugreifen. Hierfür muss eine entsprechende Abfragemöglichkeit im verteilten
System vorhanden sein.
Ein schwieriger Konflikt ergibt sich allerdings bei der Frage, zu welchem Zeitpunkt
Simulationsaufträge und ihre Ergebnisse im verteilten System gelöscht werden. Eine
dauerhafte Speicherung der Ergebnisse ist nur dann sinnvoll, wenn die Ergebnisse über
einen längeren Zeitraum und für mehrere Benutzer interessant sein können. Löscht man
die Ergebnisse jedoch gleich nach Abruf durch den Besitzer, können andere Nutzer
überhaupt nicht mehr auf diese zugreifen. Für Lethe wurde ein Kompromiss gefunden:
Ergebnisse werden zusammen mit den Simulationsaufträgen gesichert, bis sie von einem
dazu berechtigten Benutzer gelöscht werden.
3.3.6 Informationen über laufende Simulationen
Um den Benutzer über den Fortschritt seiner Simulationen zu informieren, wird eine
weitere Schnittstelle benötigt. Sie muss entsprechende Informationen über eine Simulation
bereitstellen, um dem Benutzer einen Überblick über ihren Status zu ermöglichen.
Dazu zählen speziell folgende Punkte:
• Ausführungszeit. Die Zeit, die die Simulation schon lief. Dabei wird unterschieden
zwischen: realer Ausführungszeit, d.h. die Zeit, die die Simulation auf einem
Simulationsknoten ausgeführt wurde, absoluter Ausführungszeit und verbrauchte
Rechenzeit. Die absolute Ausführungszeit ist größer oder gleich der realen Ausführungszeit,
und gibt die Zeitspanne an, in der die Simulation bereits im verteilten
System ist. An der Differenz zwischen absoluter und realer Ausführungszeit kann
der Benutzer erkennen, wie ausgelastet das verteilte System ist und notfalls seine
Simulation pausieren.
• Fortschritt der Simulation. Um einen aussagekräftigen Wert für den Fortschritt
einer Simulation zu erhalten, muss mindestens ein in der Simulation verwendetes
Modul eine Aussage über den Fortschritt machen können. Ist dies der Fall, so
kann der Benutzer daran ablesen, wie weit die Ausführung seiner Simulation bereits
ist. Dieser Fortschritt erlaubt jedoch nur eine bedingte Abschätzung über die
verbleibenden Simulationsdauer, da im Normalfall keine Aussage darüber gemacht
werden kann, wie lange und in welcher Reihenfolge die Simulationen ausgeführt
werden (vgl. 3.3.3).
• Status der Simulation. Da im Normalfall mehr Simulationen ausgeführt werden
sollen, als Ressourcen auf den Simulationsknoten zur Verfügung stehen, ist es für
den Benutzer interessant zu wissen, wie es um seine Simulation steht. Der Status
32

3.4 Überblick über die Dienste im verteilten System
der Simulation zeigt an, ob eine Simulation gerade auf einem Simulationsknoten
ausgeführt wird, ob sie in der Warteschlange auf eine Zuteilung wartet, ob ein
Fehler aufgetreten ist oder ob sie bereits vollständig ausgeführt wurde.
Um den Kommunikationsaufwand im verteilten System zu verringern, werden Statusänderungen
über IceStorm direkt dem Benutzer mitgeteilt, so dass eine regelmäßige
Statusabfrage durch den Benutzer entfallen kann.
• Fehlermeldung. Ist bei der Ausführung der Simulation ein Fehler aufgetreten, so
muss der Benutzer darüber informiert werden, damit dieser entsprechend auf den
Fehler reagieren kann, indem er z.B. die fehlerhafte Simulation abbricht, ausbessert
und als neue Simulation startet.
3.4 Überblick über die Dienste im verteilten System
Dieser Abschnitt fasst die in den letzten Abschnitten entworfenen Dienste zusammen
und beschreibt kurz, wie sie umgesetzt werden können. Im nächsten Kapitel wird dann
ausführlicher auf die Umsetzung der einzelnen Dienste eingegangen. Abschließend werden
die für den Betrieb von Lethe benötigten Anwenderprogramme aufgelistet.
3.4.1 Umsetzung der Dienste
Die in Abschnitt 3.2 entworfenen Dienste können – wie in Abbildung 4.2 gezeigt – in
einzelne Komponenten umgesetzt werden.
• Der Manager übernimmt die Rolle des zentralen Koordinators und damit auch
die Verwaltung und Verteilung von Simulationsaufträgen. Um den Verlust von
Simulationsaufträgen zu verhindern, werden die Aufträge mit Hilfe von Freeze,
dem Persistierungsdienst von ICE, in einer Datenbank gesichert.
• Die Benutzerverwaltung vereinigt die Benutzerauthentifikation und die Rechtevewaltung.
Sie werden als zwei getrennte, aber auf dem gleichen Knoten laufende
Dienste implementiert, die auf eine gemeinsame Benutzerliste zugreifen.
• Die Codeverteilung wird vom Codeverteilungsdienst vorgenommen. Die Modulbeschreibungen
werden über den Synchronisierungsdienst IcePatch den Simulationsknoten
zur Verfügung gestellt.
• Der Generator erstellt auf den Simulationsknoten aus einem Simulationsauftrag
ein Simulationsobjekt.
• Das Simulationsobjekt führt die Simulation auf den Simulationsknoten aus. Dazu
stellt es die Schnittstelle in Abbildung C.2 aus dem Anhang bereit, um Zugriffe
auf die Simulation zu ermöglichen. Die sich daraus ergebenden Probleme werden
– wie auch der Generator – in [7] diskutiert.
33

3 Systementwurf
3.4.2 Anwenderprogramme
Eine wichtige Anforderung an Lethe ist, dass die Benutzeranwendungen flexibel genug
sind, um sich den Bedürfnissen der Benutzer anpassen zu können. Deshalb werden die
Anwenderprogramme in kleine, unabhängige Kommandozeilenprogramme gekapselt:
• Den Paketgenerator, der aus einer Modul- oder Typbeschreibung das entsprechende
Paketformat generiert.
• Die Simulationsverwaltung, die dem Benutzer Zugriff auf das verteilte System ermöglicht,
indem er mit ihrer Hilfe Simulationsaufträge starten, abbrechen, pausieren
und umziehen kann. Desweiteren zeigt sie ihm den Status der aktuell ausgeführten
Simulationen an.
• Den Ergebnisexportierer, der die Simulationsergebnisse in ein XML-Format umwandelt,
so dass sie leichter von anderen Programmen weiterverwendet werden
können.
• Die Benutzerverwaltung, die dem Administrator erlaubt, Benutzer und Gruppen
neu anzulegen, zu bearbeiten oder zu löschen, ohne dass er in direkten Kontakt
mit der XML-Beschreibung kommt.
• Die Modulsuche, die es dem Benutzer erlaubt, fertige Module und Typen im verteilten
System zu finden und für eigene Simulationen zu benutzen.
Zusätzlich zu den Kommandozeilenprogrammen werden die wesentlichen Aufgaben
zum Erstellen und Ausführen von Simulationen über eine intuitiv zu bedienende graphische
Oberfläche (GUI) angeboten. Desweiteren soll sie dem Entwickler bei der Erstellung
von neuen Modulen zu Hand gehen.
34

4 Implementierung
In den folgenden Abschnitten werden wichtige und interessante Aspekte aus der Implementierung
des verteilten Systems herausgegriffen und näher beleuchtet. Dabei wird
speziell auf Fälle eingegangen, in denen der Entwurf unterschiedliche Implementierungen
zugelassen hätte oder sich unerwartete Probleme durch die Verwendung von ICE
ergeben haben.
Der erste Abschnitt befasst sich mit der Auswahl der geeignetsten Programmier- und
Beschreibungssprache. Der zweite Abschnitt beschäftigt sich mit der Realisierung und
der Umsetzung von Modulbeschreibungen und Simulationsaufträgen in Objekte.
Der dritte Abschnitt behandelt die Umsetzung und Implementierung der in Abschnitt
3.2 skizzierten Dienste. Dazu wird zuerst ein Überblick über die entstandenen Klassen
gegeben und anschließend ihre Implementierung näher beschrieben. Dabei wird auch
auf die Probleme eingegangen, die sich bei der Umsetzung ergaben. Desweiteren wird
kurz beschrieben, wie neue Knoten in das verteilte System eingefügt und alte Knoten
aus dem System entfernt werden.
Im vierten Abschnitt werden die Anwenderprogramme erklärt, die es dem Benutzer
ermöglichen, seine Simulationen in Lethe auszuführen. Abschließend wird noch auf die
grafische Oberfläche eingegangen.
4.1 Wahl der Programmier- und Beschreibungssprachen
Für die Umsetzung des Systementwurfs wird sowohl eine Programmiersprache für die
Implementierung der einzelnen Dienste benötigt, als auch eine Beschreibungssprache,
mit der Module und Simulationen beschrieben werden können. Im Folgenden wird versucht,
die optimale Sprache für die jeweilige Aufgabe zu finden.
4.1.1 Java versus C++
Ein ausschlaggebendes Kriterium für in Frage kommende Programmiersprache ist, dass
ICE sie vollständig unterstützen muss. Dies trifft momentan (Stand: April 2006 ) ausschließlich
auf Java und C++ zu.
Ich habe mich für Java entschieden, weil die Sprache gegenüber C++ speziell bei
der Implementierung der Benutzerprogramme viele Vorteile bietet: Java ermöglicht eine
plattformunabhängige Programmierung einer grafischen Benutzeroberfläche und eine für
den Benutzer leicht durchzuführende Installation, da der von Java erzeugte Bytecode
durch die Verwendung einer Virtual Machine (VM) plattformunabhängig ist. Eine VM
für Java befindet sich inzwischen bereits auf vielen Rechnern oder lässt sich zumindest
einfach nachinstallieren.
35

4 Implementierung
Desweiteren erlaubt die Verwendung der Reflection-API von Java einen einfachen
Zugriff auf dynamische, zur Entwicklungszeit unbekannte Strukturen, wie sie zum Beispiel
bei den Konfigurationsparametern von Modulen entstehen. Ein dazu vergleichbares
Konzept ist mir bei C++ nicht bekannt, so dass die Verwendung von C++ an dieser
Stelle entweder die Umsetzung des Entwurfs stark eingeschränkt oder die Entwicklung
eines entsprechend mächtigen Parsers benötigt hätte. Java erlaubt es, ähnlich wie C++
mit dynamischen Bibliotheken, Klassen während der Ausführung anhand ihres Namens
nachzuladen. Dies ermöglicht die Bereitstellung einer einfachen und intuitiven Erweiterungsschnittstelle.
Durch immer bessere Übersetzungsprogramme und einem Just-in-Time-Konzept
[27], das den Bytecode während der Ausführung in Maschinencode übersetzt, haben
C++-Programme auch ihren Geschwindigkeitsvorteil gegenüber entsprechenden Java-
Programmen mittlerweile größtenteils eingebüßt.
4.1.2 Beschreibungssprache
Bei der Wahl der Beschreibungssprache war wichtig, dass sowohl die Sprache als auch
das Format möglichst einfach und strukturiert ist. Es soll möglich sein, die Modul- und
Simulationsbeschreibungen ohne spezielle Vorkenntnisse, langer Einarbeitungszeit oder
speziell dafür benötigten Programmen zu erstellen beziehungsweise zu ändern.
Dazu bieten sich mehrere Möglichkeiten an: Zum einen kann ein eigenes Beschreibungsformat
entworfen werden, das speziell auf die Bedürfnisse von Lethe zugeschnitten
ist. Dies hat jedoch neben dem zusätzlichen Aufwand, einen Parser dafür zu entwickeln,
den Nachteil, das sich Benutzer und Entwickler erst in das Format einarbeiten müssen,
bevor sie es benutzen können. Diese Schwierigkeit lässt sich durch die Verwendung von
Schlüssel-/Werte-Listen – wie zum Beispiel den .ini-Dateien unter Windows – umgehen.
Jedoch können diese bei größeren, hierarchisch strukturierten Daten sehr unübersichtlich
werden.
Schlussendlich fiel meine Wahl auf XML, das eine einfache Darstellung hierarchisch gegliederter
Daten erlaubt. Seine Struktur aus öffnenden und schließenden Tags, zwischen
denen die entsprechenden Daten stehen, ist zum einen leicht erlernbar und zum anderen
lassen sich die Daten mit Hilfe von Schemabeschreibungen einfach validieren. Die Verwendung
von Schemabeschreibungen, die den Aufbau und die Struktur einer XML-Datei
beschreiben, erleichtern sowohl dem Benutzer das Erstellen der XML-Dateien, als auch
der Anwendung die Verarbeitung der Daten, da mit ihrer Hilfe die formale Korrektheit
der XML-Dateien geprüft werden kann. Da XML ein weit verbreiteter Standard ist,
existieren für die meisten Plattformen bereits spezielle Editoren, die das Erstellen und
Konfigurieren von XML-Dateien erleichtern und die Dateien anschließend validieren.
Die Validierung von XML-Dateien verlangsamt zwar das Parsen von XML-Dateien
merklich, jedoch wird dies dadurch ausgeglichen, das die Anwendung die Daten nicht
mehr selbst überprüfen muss. Desweiteren findet bei Lethe der Einsatz von XML-
Dateien ausschließlich auf Benutzerseite statt, so dass sich eine längere Einlesezeit nicht
negativ auf die Ausführung des Gesamtsystems auswirkt.
36

4.2 Module und Simulationen
Ausgangsbeschreibung
modul.xml
modul.xml
spezielle Modulbeschreibung
modul.xsd
Schema für
spezielle Modulbeschreibung
modul.h gen_adapter.xml gen_modul.ice
Modulcode Code für Ein- und Ausgänge Slice-Definition
Abbildung 4.1: Aus der Modulbeschreibung werden verschiedene Dateien in unterschiedlichen
Formaten erzeugt.
Außerdem existieren für XML freie Parser in Java, die einfach in eigene Programme
eingebunden werden können. Damit entfällt die Entwicklung eines speziell für Lethe
ausgerichteten Parsers.
Für die Transformation der XML-Dateien in die benötigten Formate bietet es sich an,
das speziell für solche Aufgaben entwickelte XSLT zu verwenden. XSLT erlaubt es, das
Ausgabeformat direkt in die Transformationsbeschreibung einzufügen. An den Stellen,
die von XML-Daten abhängen, lassen sich mit Hilfe von XPath und XQuery die benötigten
Daten aus der XML-Datei extrahieren und entsprechend aufbereitet einfügen.
Dies erlaubt eine kompaktere und übersichtlichere Beschreibung einer Transformation
als sie zum Beispiel mit Java möglich wäre.
4.2 Module und Simulationen
Im Folgenden wird dargelegt, wie Module und Simulationen aus ihrer Beschreibung erstellt
werden und welche speziellen Probleme hierbei zu berücksichtigen sind. Anschließend
wird beschrieben, wie aus einer Simulationsbeschreibung ein Simulationsauftrag
erstellt wird, der im verteilten System ausgeführt werden kann.
4.2.1 Erzeugen von Modulen
Ein Modul im verteilten System besteht aus mehreren Dateien mit unterschiedlichen
Formaten. Abbildung 4.1 zeigt die für ein Modul benötigten Datein. Diese werden mit
Hilfe von XSLT aus der Modulbeschreibung erzeugt. Dabei gibt es für jedes Format eine
eigene Transformationsdatei. XSLT 2.0 unterstützt zwar die Ausgabe in verschiedene
Formate, jedoch ist die Verwendung von separaten Dateien bei Lethe übersichtlicher.
37

4 Implementierung
Die hier beschriebenen Transformationen gelten in gleicher Weise für die Erzeugung
von modulübergreifenden Datentypen. Allerdings wird für diese keine Benutzerimplementierung
benötigt, da sie keine Ein- und Ausgabekanäle besitzt.
Spezielle Modulbeschreibung
Für die spezielle Modulbeschreibung wird die ursprüngliche XML-Beschreibung lediglich
umgeformt. Zweck der speziellen Modulbeschreibung ist es, dem Benutzer die Verwendung
eines Moduls zu erleichtern: Daten, die er ändern kann, sollen sich zwischen einem
Paar sich öffnender und schließender Tags befinden; Daten, die er nicht verändern darf,
als Attribute in den entsprechenden, sich öffnenden Tags. Ändern darf der Benutzer
die Werte der Konfigurations- und Einstellungsparameter, fest sind die Parametertypen
und die Ein- und Ausgabekanäle eines Moduls.
Die entsprechende Transformationsdatei liest die Modulbeschreibung ein und wandelt
die Daten um, indem sie die Beschreibung der Parameter und Kanäle entsprechend
umstellt.
Neben dieser Transformation muss eine weitere Transformation der ursprünglichen
Modulbeschreibung in eine speziell an die Modulbeschreibung angepassten XML-
Schema-Beschreibung durchgeführt werden. Diese wird benötigt, da der Aufbau einer
speziellen Modulbeschreibung von dem Aufbau der Modulbeschreibung abweicht. Die
Schemabeschreibung muss sicherstellen, dass in der neuen Modulbeschreibung alle benötigten
Parameter und Kanäle vorhanden sind, dass die Attribute nicht verändert wurden
und die Parameterwerte sich in definierten Schranken befinden. Diese Beschreibung lässt
sich ebenfalls aus der allgemeinen Modulbeschreibung erstellen, da sie ausser dem Aufbau
des Moduls keine weiteren Informationen benötigt. Dabei werden der Reihe nach die
einzelnen Parameter eines Moduls durchgegangen und eine entsprechende Beschreibung
erzeugt.
Slice-Definition
Neben der speziellen Modulbeschreibung wird auch die Slice-Definition mittels XSLT
erzeugt. Dabei muss die Modulbeschreibung in eine ICE-Struktur gebracht werden. Um
Namenskonflikte mit anderen Modulen zu vermeiden, wird jedem Modul ein Namensraum
in der Form Extensions.Modules..Lethe zugewiesen. In diesem
Namensraum werden Strukturen für die Parameter, die Ergebnisse und den Zustand des
Moduls entsprechend ihrer Definition in der Modulbeschreibung erzeugt. Dabei werden
die Typen folgendermaßen auf ICE-Strukturen abgebildet:
• Die einfachen Typen string, int, long, byte, float und double haben eine
gleichnamige Entsprechung in ICE. Der Typ boolean wird in bool umbenannt.
• Enumerationen werden in eine entsprechende enum-Struktur abgebildet, die in Slice
folgendermaßen aussieht: enum {string1, string2, ... , stringN}
• Klassen werden in eine eigene Struktur abgebildet, die mit den Klassenfeldern
gefüllt wird: struct { ; ; ... ;
}
38

4.2 Module und Simulationen
• Listen werden auf Sequenzen abgebildet, die in den entsprechenden Strukturen
verwendet werden. Dies entspricht sequence < >
• Tabellen dienen dem Komfort der Benutzer und werden in eine Sequenz von
Sequenzen abgebildet. Damit dies transparent stattfinden kann, wird für die
innere Sequenz das dem Benutzer verbotene 1 Präfix icegen benutzt. Damit
sieht die Umsetzung einer Tabelle wie folgt aus: sequence <
> icegenarray; sequence < icegenarray >
• Assoziative Listen werden auf den Typ dictionary abgebildet. Um die Benutzung
einer assoziativen Liste in der Modulbeschreibung möglichst einfach zu halten,
sind die Schlüssel auf Werte des Typs string beschränkt. Dies stellt allerdings
keine allzu große Einschränkung für die Entwickler von Modulen dar, da es im
Normalfall möglich ist, beliebige Typen durch eine Zeichenkette zu repräsentieren.
Die Abbildung von assoziativen Listen erfolgt folgendermaßen: dictionary
< , >
Bei diesen einfachen Regeln zur Umsetzung der Typen treten jedoch Probleme im
Zusammenhang mit Slice auf: So können in Slice Strukturen nur verwendet werden,
wenn sie vor ihrer Verwendung bereits definiert sind. Eine Vorwärtsdefinition wie sie
zum Beispiel in C möglich ist, wird von Slice nicht unterstützt. Dies ist speziell für
Klassen, Listen, Tabellen und assoziativen Listen ein Problem, die nicht ausschließlich
aus einfachen Typen bestehen. Deshalb müssen für die Erstellung der Slice-Definitionen
die verwendeten Typen nach ihrem Auftreten sortiert werden. Dazu werden zwei Mengen
verwendet: Die Menge U enthält alle noch zu definierenden Typen, die Menge V bereits
definierte Typen. Zu Beginn der Sortierung enthält V ausschließlich die einfachen Typen,
wie string oder int. Anschließend wird U nach folgendem Algorithmus durchsucht, bis
|U| = 0 oder kein entsprechender Typ mehr gefunden wurde:
1. Finde einen Typ t ∈ U, so dass t entweder eine Enumeration ist oder ausschließlich
von Typen aus V abhängt.
2. Definiere t nach obigen Regeln.
3. Entferne t aus U und füge t in V ein.
Gilt |U| = 0 so konnte eine Ordnung auf den verwendeten Typen gefunden werden,
die sicherstellt, dass kein Typ definiert wird, bevor nicht alle von ihm verwendeten
Typen definiert wurden. Andernfalls gibt es Typen, die entweder auf unbekannten Typen
basieren oder eine zirkuläre Abhängigkeit besitzen. In diesem Fall kann keine Slice-
Definition erzeugt werden.
Eine weitere Schwierigkeit ergibt sich daraus, dass leere Strukturen nicht erlaubt sind.
Das wird zu einem Problem, wenn zum Beispiel ein Modul keine Ergebnisse erzeugt oder
keine Konfigurationsparameter benötigt. Die dafür benötigte Struktur muss trotzdem
1 icegen ist für den Benutzer wegen des Präfix ice verboten.
39

4 Implementierung
erzeugt werden, um die Programmierschnittstelle für den Modulcode einheitlich zu gestalten.
In diesem Fall wird der Struktur eine Boolsche Variable namens icegenDUMMY
als Platzhalter hinzugefügt. Durch das Präfix ice, das für benutzerdefinierte Bezeichner
verboten 2 ist, kann diese Variable nicht mit benutzerdefinierten Typen kollidieren.
Modulcode
Damit ein Modul sinnvoll verwendet werden kann, muss der Entwickler die Simulations-
API aus [7, Abschnitt 3.1.10] implementieren. Dazu stellt ihm Lethe ein Grundgerüst
bestehend aus den Methodenrümpfen und den Modulparametern bereit. Desweiteren
werden aus den Ein- und Ausgängen eines Moduls Hilfsfunktionen zum Schreiben und
Lesen für die Modulimplementierung erzeugt.
4.2.2 Erzeugen von Simulationen
Eine Simulationsbeschreibung enthält alle Informationen, um aus ihr einen Simulationsauftrag
erstellen zu können. Trotzdem wird für jede Simulationsbeschreibung eine spezielle
Schemabeschreibung erstellt. Dieses Vorgehen erleichtert es dem Benutzer, selbst
eine Simulationsbeschreibung zu erzeugen. Damit aus der Simulationsbeschreibung nämlich
ein Auftrag generiert werden kann, muss für jeden verwendeten Modulparameter
Zusatzinformationen wie Typ, Klassenname oder Standardwert angegeben werden. Diese
Zusatzinformationen können jedoch auch bei der Transformation automatisch aus
den entsprechenden Modulbeschreibungen ausgelesen und in die Schemabeschreibung
aufgenommen werden. Der Parser fügt dann beim Validieren der Simulation selbständig
die Zusatzinformationen aus der Schemabeschreibung ein, wenn sie nicht vorhanden
sind. Da die benötigten Zusatzinformationen von den verwendeten Modulen abhängen,
benötigt normalerweise jede Simulation eine eigene Schemabeschreibung. Bei der
Simulationsbeschreibung selbst muss lediglich der Verweis auf die zu verwendende Schemabeschreibung
geändert werden, da sonst weiterhin die allgemeine Beschreibung für
Simulationen verwendet wird.
4.2.3 Erstellen von Simulationsaufträgen
Simulationsaufträge werden aus Simulationsbeschreibungen erstellt, indem die einzelnen
Daten geparst und dem Simulationsobjekt zugewiesen werden. Im einfachsten Fall
geschieht dies wie bei den Feldern name und description über eine gleichnamige Entsprechung
in der Simulationsbeschreibung. Das Feld owner wird auf den aktuellen Benutzernamen
gesetzt, der Wert des Feldes jobId muss hingegen von der zentralen Komponente
im verteilten System abgefragt werden, da sie im gesamten System eindeutig
sein muss.
Komplizierter ist die Erstellung des Hypergraphen und der Einstellungsparameter
für die einzelnen Runden. Ein Knoten im Graphen entspricht einer Modulinstanz und
besitzt einen eindeutigen Namen. Eine mögliche Anwendung dafür wäre zum Beispiel
2 Die Benutzung ist tatsächlich nicht erlaubt, kann aber durch die Übersetzung der Definitionsdatei
mit - -ice umgangen werden.
40

4.2 Module und Simulationen
die Verwendung von zwei Quellen: Quelle1 und Quelle2, die beide Instanzen des Moduls
Quelle sind.
Ein Graph besteht also aus einer Menge von Knoten und einer Menge von Verbindungskanten.
Um die Verbindungskanten korrekt zuordnen zu können, benötigt er außerdem
eine Liste mit Ein- und Ausgängen der einzelnen Knoten. Da sich die Verbindungen
während der Ausführung in den Phasen ändern können, benötigt er auch noch die jeweils
aktiven Ein- und Ausgänge pro Phase. Damit das Simulationsobjekt später entscheiden
kann, wann eine Phase beendet ist, benötigt es auch noch eine Liste von Knoten, die
Ergebnisse produzieren oder selbst aktiv entscheiden können, wann eine Phase beendet
ist. Desweiteren kann für jede Phase angegeben werden, ob ein Eingang zu Beginn der
Phase auf den im Kanal vorhandenen Daten weiterarbeiten möchte oder nicht.
Desweiteren muss für jeden Knoten im Graphen dessen Konfigurationsparameter instantiiert
werden. Daraus ergibt sich das Problem, wie die in den einzelnen Modulen
verwendeten Parameter ausgelesen und im verteilten System versendet werden können.
Um die Parameter über das ICE-Framework verschicken zu können, bedarf es einiger
Kniffe. Zuerst muss ein Verfahren gefunden werden, das es sowohl Java- als auch C++-
Programmen erlaubt, plattformunabhängig die Parameter zu lesen und zu schreiben.
Hierzu bietet es sich an, die Parameter in Slice, der Schnittstellenbeschreibungssprache
von ICE, als Konfigurationsobjekt zu definieren. Diese Definition kann anschließend in
Java- oder C++-Klassen umgewandelt werden, so dass sowohl die Anwenderprogramme
als auch die Simulationsobjekte auf die Konfigurationsparameter zugreifen können.
Diese Parameter können jedoch nicht direkt als Konfigurationsobjekt im verteilten
System verschickt werden. Andernfalls müsste die zentrale Komponente über dieses
spezielle Objekt in Form einer speziellen Slice-Definition für den gesamten Simulationsauftrag
Bescheid wissen. Dies ist jedoch nicht mit vertretbarem Aufwand möglich, da
sonst für jeden Simulationsauftrag neue Slice-Definitionen an den zentralen Koordinator
geschickt werden müssen, aus denen dieser dann Java-Klassen erzeugen und während
der Laufzeit nachladen kann.
Eine weitere Möglichkeit wäre die Verwendung von Klassen statt Strukturen für die
Konfiguration. Für Klassen erlaubt Slice eine Vererbung, so dass alle Konfigurationsobjekte
von einer gemeinsamen Oberklasse abgeleitet sein können. In diesem Fall kann
die zentrale Komponente problemlos die verschiedenen Simulationsaufträge annehmen.
Möchte die zentrale Komponente jedoch den Simulationsauftrag sichern, tritt sogenanntes
Slicing [31, Seite 121 – 124] auf. Dies bedeutet, dass nicht das komplette Konfigurationsobjekt
gespeichert wird, sondern lediglich die Felder, die der zentralen Komponente
aus der Oberklasse für Konfigurationsobjekte bekannt sind.
Deshalb wird eine Möglichkeit benötigt, das Konfigurationsobjekt an den zentralen
Koordinator zu senden, und zwar derart, dass es einerseits nicht verstümmelt wird und
andererseits ohne Aufwand empfangen werden kann. Die Lösung für dieses Problem liegt
in der Verwendung von sogenannten Strömen, die die Daten des Konfigurationsobjekts
enthalten. ICE erlaubt, ICE-Objekte in Byteströme umzuwandeln und sie aus diesen
wieder zu rekonstruieren. Aus dem Konfigurationsobjekt wird also ein Bytestrom in
Form eines byte-Arrays erzeugt, der problemlos versandt und von der zentralen Komponente
gesichert werden kann. Simulationsobjekte wiederum können auf die Parame-
41

4 Implementierung
ter sehr einfach zugreifen, indem sie den Bytestrom wieder in ein Konfigurationsobjekt
überführen.
Es stellt sich nun die Frage, wie dieser Bytestrom erzeugt und initialisiert werden kann.
Eine Möglichkeit wäre es, die Parameter durchzugehen und mit Hilfe der Serialisierungs-
API von ICE Feld für Feld in den Bytestrom zu schreiben. Dies kann auch durch XSLT
geschehen, das durch eine Transformation die Parameterwerte in einen der Spezifikation
in [31, Abschnitt 33.2] entsprechenden Strom umwandelt. Besonders die zweite Vorgehensweise
ist jedoch sehr von der ICE-internen Serialisierungsvorschrift abhängig, und
muss bei Änderungen in der Spezifikation entsprechend angepasst werden.
Deswegen erzeugt Lethe einen der Konfiguration entsprechenden Objektgraphen, den
es dann als ganzes von ICE serialisieren lässt. Eine elegante Möglichkeit, um aus den
Konfigurationsdateien die entsprechenden Objektstrukturen aufzubauen, wäre sicher die
direkte Erzeugung eines generierenden Javacodes via XSLT. Da diese Idee jedoch im
Laufe der Implementierung zu spät aufkam, verwendet Lethe die Java Reflection-API
zum Aufbau der Datenstruktur. Dazu müssen die Slice-Definitionen zuerst mit Hilfe
von slice2java in Java-Code umgewandelt werden. Die somit in der Java-VM verfügbaren
Klassen werden nun mittels der Reflection-API instantiiert, und die entsprechenden
Attribute und Referenzen gesetzt. Der Fall, dass ein Knoten keine Konfigurationsparameter
besitzt, kann durch die Verwendung des Platzhalter-Feldes (vgl. Abschnitt 4.2.1)
nicht eintreten, und muss deshalb nicht berücksichtigt werden. Die Umsetzung erfolgt
dabei ähnlich wie bei der Abbildung von XML-Beschreibung zu Slice-Definition:
• Die einfachen Typen (string, int, long, byte, float, double, bool) werden
direkt in ihre Entsprechung in Java umgesetzt und mit dem angegebenen Wert
belegt.
• Für Enumerationen (enum) werden durch den Aufruf von slice2java spezielle Hilfsklassen
erzeugt, die dynamisch nachgeladen, instantiiert und mit dem angegebenen
Wert belegt werden.
• Ebenso werden für Klassen (struct) eigene Hilfsklassen angelegt. Diese werden,
wie bei den Enumerationen, nachgeladen und instantiiert. Anschließend werden
nach den selben Regeln die einzelnen Felder der Klassen erzeugt.
• Listen und Tabellen werden als ein- bzw. zweidimensionale Listen des entsprechenden
Typs angelegt. Die Größe der Listen hängt dabei von der jeweiligen Anzahl
der Elemente ab. Anschließend werden die einzelnen Elemente erzeugt und entsprechend
ihrer Definition in der Simulationsbeschreibung belegt.
• Assoziative Listen werden als HashMap angelegt und anschließend wie bei den
Listen mit entsprechenden Schlüssel-/Wertepaaren gefüllt.
Die Einstellungsparameter werden wie die Konfigurationsparameter eingelesen und gespeichert.
Dabei wird die Anzahl der Runden implizit mit den Einstellungsparametern
gesichert: Für jeden Knoten stehen genauso viele Byteströme mit Einstellungsparametern
zur Verfügung, wie es Runden gibt.
42

4.3 Das verteilte System
4.3 Das verteilte System
Im Folgenden wird zuerst auf die Problematik eingegangen, wie Knoten in das verteilte
System eingefügt bzw. daraus entfernt werden können. Anschließend befasst sich dieser
Abschnitt mit der Umsetzung der in Abschnitt 3.4 entworfenen Dienste. Abschließend
werden Überlegungen zu der Ausführung der einzelnen Dienste gemacht. Dies betrifft
speziell die Frage, welche Dienste auf welchen Knoten ausgeführt werden.
4.3.1 Hinzufügen und Entfernen von Knoten
Das Hinzufügen und Entfernen von Knoten im verteilten System läuft für Lethe vollkommen
transparent ab, da es mit Hilfe von IceGrid gelöst wird. IceGrid benötigt eine
Konfiguration des Systems in einem XML-Format, das angibt, welche Knoten im verteilten
System vorhanden sind, und was für Dienste auf ihnen ausgeführt werden. Mit
dieser Information erlaubt IceGrid, Dienste zu starten, zu beenden und ihren Status
abzufragen.
Um einen neuen Simulationsknoten im System hinzuzufügen, muss auf diesem Knoten
ein icegridnode gestartet werden und die Konfigurationsdatei des verteilten Systems
um den entsprechenden Knoten erweitert werden. Anschließend müssen die Änderungen
dem verteilten System mitgeteilt werden. Dies geschieht am einfachsten durch den Aufruf
von icegridadmin -e ’application update lethe.xml’. Dabei ist zu beachten,
dass die Namen der einzelnen Knoten im verteilten System eindeutig sein müssen. Eine
Möglichkeit, das zu gewährleisten, ist, die Knoten fortlaufend durchzunumerieren, oder
ihnen den Namen des Rechners zu geben, auf dem sie ausgeführt werden.
Um einen Knoten aus dem verteilten System zu entfernen, kann einfach der Rechner
vom Netz genommen werden oder die icegridnode auf dem entsprechenden Rechner
beendet werden. Im ersten Fall wird der Knoten wieder dem Netz zugeführt sobald
eine icegridnode darauf gestartet wird. Soll der Knoten jedoch dauerhaft aus dem
verteilten System entfernt werden, so muss er aus der Konfigurationsdatei gelöscht, und
die Änderung im verteilten System mit Hilfe von icegridadmin -e ’application
update lethe.xml’ propagiert werden.
4.3.2 Manager
Der Manager dient als Ansprechpartner für Benutzer und Vermittler von Systemressourcen.
Die Simulationsobjekte melden ihm, wenn sich am Status ihrer Ausführung
etwas ändert. Dies kann durch einen Laufzeitfehler im Simulationsprogramm geschehen
oder durch das Ende der Simulation. Da der Zugriffsschutz im verteilten System
durch die Einführung von Sicherheitszonen (vgl. siehe auch: 3.2.5) gewährleistet wird,
sind die Schnittstellen des zentralen Koordinators in zwei voneinander getrennte Teile
aufgeteilt, wie man am Klassendiagramm in Abbildung C.1 im Anhang sieht: die Benutzerschnittstelle,
auf die aus Zone 1 zugegriffen werden kann, und die Schnittstelle
für Simulationsobjekte, die aus Zone 2 auf den zentralen Koordinator zugreifen. Die
explizite Trennung der Schnittstellen ist notwendig, da ICE sonst keine Unterscheidung
bezüglich des Zugriffs machen kann.
43

4 Implementierung
Verwalten von Simulationen
Die Simulationsaufträge im verteilten System werden mit Hilfe von eindeutigen IDs
(Simulations-ID) verwaltet. Soll ein neuer Auftrag gestartet werden, bekommt er vom
zentralen Koordinator eine eindeutige ID zugeteilt. Diese setzt sich aus dem Benutzernamen
und einer für jeden Benutzer durchlaufenden Nummer zusammen. Ebenso werden
auch die Runden der einzelnen Simulationen mit einer eindeutigen ID versehen: Sie leitet
sich aus der Simulations-ID und der Rundennummer ab. Diese ID wird zum Ansprechen
und Sichern der einzelnen Runden benötigt.
Um die Simulationsaufträge bei einem Ausfall zu schützen, sichert die zentrale Komponente
diese nach dem Empfang unter seiner ID in einer FreezeMap. Desweiteren speichert
er für jede Simulationsrunde ab, ob sie bereits einen Sicherungspunkt hat. Ist dies
der Fall, wird der Sicherungspunkt mitgespeichert. Da für den zentralen Koordinator
keine Möglichkeit besteht, Simulationsobjekte im verteilten System gezielt zu finden,
speichert er für jede aktive Runde das Zugriffsobjekt auf das Simulationsobjekt.
Verteilen von Simulationen
Damit eine möglichst gerechte Ausführung der Simulationen stattfindet, wird für die
Zuteilung ein Zeitscheibenverfahren verwendet. Das bedeutet, dass Simulationen nach
Ablauf eines konfigurierbaren Intervalls angehalten werden, um anderen Simulationen
Ressourcen zur Verfügung zu stellen. Dieses Verhalten hat einen weiteren Vorteil, da
von der Simulation automatisch ein Sicherungspunkt erzeugt wird, bevor sie angehalten
wird. Dadurch ist bei einem Knotenausfall die Rechenzeit von maximal einer Zeitscheibe
verloren. Der Verteilungsalgorithmus von Simulationen läuft wie folgt ab:
1. Bestimme die Menge S aller aktiven Simulationen, deren Zeitscheibe abgelaufen
ist.
2. Erzeuge für jede Simulation s ∈ S einen Sicherungspunkt und pausiere s.
3. Erstelle eine nach ihrer Systemauslastung sortierte Liste L von verfügbaren Simulationsknoten.
Kann ein Simulationsknoten mehrere Simulationen gleichzeitig
ausführen, wird er entsprechend oft in die Liste aufgenommen.
4. Sortiere die auf ihre Ausführung wartenden Simulationen nach ihrem Punktestand
(vgl. Funktion 3.1) und weise ihnen der Reihe nach Simulationsknoten aus L zu.
Dabei soll einer Simulation bevorzugt ein Knoten zugewiesen werden, auf dem
bereits ein entsprechendes Simulationsobjekt vorhanden ist.
5. Ist einer Simulation s ein Simulationsknoten k zugewiesen worden, muss geprüft
werden, ob ein für s passendes Simulationsobjekt auf k bereits vorhanden ist.
Ansonsten muss es neu erzeugt werden. Anschließend wird die Simulation s auf
dem Simulationsobjekt ausgeführt.
Die Reihenfolge, in der Simulationen ausgeführt werden, ist von ihrer Sortierung abhängig.
In Lethe wird das Verfahren nach Sainte-Laguë [43] verwendet, das sich in den
44

4.3 Das verteilte System
Untersuchungen von [4] als das exakteste proportionale Zuteilungsverfahren erwiesen
hat. Dabei werden die Simulationsknoten aus L den einzelnen Simulationen verhältnismäßig
zu deren Punktezahl im Vergleich zu den anderen zugeteilt. Diese Zuweisung ist
konfigurierbar, andere Algorithmen lassen sich verwenden, wenn sie das Interface aus
Abbildung C.6 im Anhang implementieren. Dabei sind jobs Simulationsaufträge, die
auf ihre Ausführung warten, und seats ist die Anzahl der zur Verfügung stehenden Simulationsknoten.
Der Rückgabewert ist eine sortierte Liste der Simulations-IDs, wobei
eine ID mehrfach enthalten sein kann.
Umziehen von Simulationen
Die Möglichkeit zur Laufzeit Simulationen auf andere Knoten umziehen zu können, ist
eine wichtige Anforderung an das verteilte System, die auch vom Manager unterstützt
werden muss. Prinzipiell lässt sich eine aktive Simulation sehr einfach umziehen: Man
erstellt einen Sicherungspunkt der Simulation, erzeugt auf dem neuen Simulationsknoten
ein entsprechendes Simulationsobjekt und startet dieses mit den Daten aus dem
Sicherungspunkt.
Probleme ergeben sich jedoch in der Ausführung: Zum einen müssen dem Benutzer
sowohl der Rechnername bekannt sein, auf dem seine Simulation gerade ausgeführt wird,
als auch der Rechnername, auf den er die Simulation übertragen möchte. Zum anderen
ist es unwahrscheinlich, dass auf dem Zielknoten noch Kapazitäten frei sind, wenn sich
zu dem Zeitpunkt, an dem eine Simulation umgezogen werden soll, bereits sehr viele
Simulationsaufträge im System befinden. Dennoch soll die Simulation auf dem Knoten
weiterlaufen. Aus diesem Grund ignoriert der Manager beim Umziehen einer Simulation
die angegebene, maximale Kapazität des Zielknotens. So kann es passieren, dass auf
einem Simulationsknoten mehr Simulationen ausgeführt werden als angegeben. Dies ist
jedoch ein temporärer Zustand, der zum einen nur durch das Umziehen von Simulationen
auftreten kann, und zum anderen nach dem Ablauf der aktuellen Zeitscheibe vom
Manager automatisch behoben wird.
Es werden jedoch – wenn auch nur für eine beschränkte Zeit – andere Simulationen
in ihrer Ausführung benachteiligt. Deshalb sollten nur ausgewählte Benutzergruppen
in der Lage sein, Simulationen umzuziehen. Durch die automatische Erstellung von Sicherungspunkten
ist außerdem der Informationsverlust bei einem Knotenausfall sehr
gering, so dass es sich selbst bei geplanten Knotenausfällen, wie sie zum Beispiel durch
Stromabschaltungen auftreten können, nicht mehr lohnen kann, eine Simulation aktiv
umzuziehen. Eine Alternative zum Umziehen ist auch das manuelle Erstellen von Sicherungspunkten,
die jedem Benutzer zur Verfügung steht, der Simulationen im verteilten
System starten darf.
Bei dem Umziehen von Simulationen muss dem Benutzer bewusst sein, dass diese
transparent für die Knotenverteilung abläuft. Dadurch kann es passieren, das der
Manager die Simulation im nächsten Zeitschlitz wieder auf dem ursprünglichen Knoten
startet. Aus diesem Grund ist es sicher sinvoll, Simulationen Knotengruppen zuweisen zu
können, denen sie ausschließlich zugeteilt werden. Desweiteren wäre es praktisch, Simulationen
in logische Gruppen eingeteilen zu können, die dann z.B. gemeinsam umgezogen
werden können. Vorstellbar ist z.B. eine Gruppe aller Simulationen eines Benutzers oder
45

4 Implementierung
einer Benutzergruppe, sowie eine Gruppe aller auf einem Knoten laufenden Simulationen.
Diese Punkte konnten jedoch wegen Zeitmangels nicht mehr implementiert werden.
4.3.3 Benutzerverwaltung
Die Benutzerverwaltung kümmert sich um die Authentifizierung, die Rechteverwaltung
und das Hinzufügen und Löschen von Benutzern und Gruppen. Dabei sind die Informationen
bezüglich der Benutzer und Gruppen in den entsprechenden Klassen gekapselt.
Die Rechteverwaltung implementiert die in Abschnitt 3.2.4 beschriebenen Algorithmen,
weshalb an dieser Stelle nicht mehr näher darauf eingegangen wird. Die Benutzerauthentifizierung
erfolgt bei Lethe mit Hilfe einer Benutzername/Passwort-Liste, da sie
durch den Administrator einfach zu handhaben ist. Desweiteren lassen sie sich auch
von dem Authentifizierungsprogramm einfach verwenden. Diese Listen haben jedoch
einen großen Nachteil: Fallen sie den falschen Personen in die Hände, können sie sich
unter falschem Namen am System anmelden. Lethe umgeht dieses Problem, indem es
die Passwörter nicht im Klartext, sondern nur ihren MD5-Hashwert [42] speichert. Um
sicherzustellen, das das Passwort bei der Anmeldung mit dem gespeicherten Hashwert
übereinstimmt, wird das Benutzerpasswort im Klartext zum Authentifizierungsdienst
gesendet. Dieses Vorgehen ist insofern unproblematisch, da die Verbindung mittels SSL
geschützt ist (vgl. Abschnitt 3.2.5). Andernfalls wäre es bedenklich, die Passwörter im
Klartext im verteilten System zu versenden, da sie potentiell von Anderen mitgelesen
werden können.
4.3.4 Codeverteilung
Die Codeverteilung selbst ist ein sehr einfach gehaltener Dienst, der über ein Erweiterungssystem
auf unterschiedlich gespeicherte Daten zugreifen kann. Die Funktionsweise
des Erweiterungssystems wird im nächsten Abschnitt beschrieben. Die Synchronisierung
findet dabei, wie im Entwurf in Abschnitt 3.2.3 beschrieben, mit Hilfe von Ice-
Patch statt. ICE beinhaltet ein Kommandozeilenprogramm, das einen IcePatch-Server
implementiert, auf den die Clients zugreifen können.
Bei der Implementierung der Codeverteilung ergeben sich jedoch Probleme, wenn der
Dienst mehrere IcePatch-Server starten muss. Dies ist der Fall, wenn Simulationsknoten
zur gleichen Zeit die Daten von verschiedenen Simulationsaufträgen anfordern. Damit
die Simulationsknoten auf den Server zugreifen können, muss die Codeverteilung den
Knoten mitteilen, unter welchem Namen und auf welchem Port die Server erreicht werden
können. Da die Server mit Hilfe eines eigenständigen Kommandozeilenprogramms
gestartet wurden, benötigt jeder Server einen eigenen Port.
Im Normalfall wird das dadurch gelöst, indem das Betriebssystem dem Server einen
zufälligen Port zuweist. Diese einfache Lösung kommt aber für Lethe nicht in betracht,
da die Codeverteilung wissen muss, an welchem Port ein Server aktiv ist. Daher ist es
erforderlich, dass die Portnummer nicht vom Betriebssystem, sondern von der Codeverteilung
zugewiesen wird. Allerdings benötigt dieses Vorgehen eine komplizierte Konfiguration,
da die Codeverteilung Kenntnis davon haben muss, aus welchem Intervall sie
46

4.3 Das verteilte System
Portnummern vergeben darf. Dabei stellt sich jedoch die Frage nach der Größe dieses
Intervalls: Ist es zu klein gewählt, können keine neuen Server mehr gestartet werden.
Letztendlich habe ich mich für eine eigene Implementierung des IcePatch-Servers in
Java entschieden, da es bei ICE nur eine Implementierung in C++ gibt. Dadurch können
die IcePatch-Server als normale Dienste durch die Codeverteilung gestartet werden und
über den selben Port angesprochen werden, auf dem auch die Codeverteilung läuft. Diesen
Port kann die Codeverteilung beim Starten eines neuen IcePatch-Servers abfragen
und entsprechend an die Simulationsknoten weitergeben.
Erstellen neuer Zugriffsverfahren
Momentan unterstützt die Codeverteilung bei Lethe den Zugriff auf Subversion-
Repositories (SVN-Repositories) [12] und auf das lokale Dateisystem. Um weitere Zugriffsarten
wie zum Beispiel HTTP oder FTP zu ermöglichen, müssen folgende Punkte
beachtet werden:
1. Für das neue Verfahren muss eine Java-Klasse geschrieben werden, die die
SourceController-Schnittstelle (C.5 im Anhang) implementiert. Diese Schnittstelle
besteht aus einer Methode, um die benötigten Dateien in ein Verzeichnis zu
kopieren.
2. Es wird eine Slice-Definition für die Beschreibung der neuen Zugriffsart benötigt.
Bei SVN ist dies die sogenannte Revisionsnummer, die URL zum Repository sowie
der Pfad im Repository zu den entsprechenden Verzeichnissen. Im lokalen Dateisystem
ist dies lediglich der entsprechende Pfad zu den Verzeichnissen. Bei HTTP
wäre es die Adresse. Diese Definition muss von der leeren Klasse SourceDesc
abgeleitet sein, damit sie über die bestehenden Methoden im verteilten System
versandt werden kann.
3. Damit der Benutzer auch die neue Zugriffsart benutzen kann, muss eine entsprechende
Definition in der Simulationsbeschreibung erstellt werden.
4. Schlussendlich muss der Paketgenerator oder vielmehr die Klasse
xml.JobSpecification so erweitert werden, dass sie aus der XML-Beschreibung
das entsprechene ICE-Objekt erstellen und belegen kann.
4.3.5 Dienste im verteilten System
Abschließend ist zu klären, welche Dienste auf welchen Knoten ausgeführt werden. Dazu
lassen sich die Knoten im System in vier Gruppen aufteilen:
1. Die zentrale Komponente im verteilten System: Auf ihm läuft der Namensdienst
von ICE, der Manager, die Benutzerverwaltung und der Logging-Dienst Breeze 3 .
Außerdem wird auf ihm der standardmäßig benutzte Dienst zur Codeverteilung
ausgeführt.
3 Breeze ist ein zentraler Logging-Dienst im verteilten System. Er wurde von Alexander Bernauer in
[7] entworfen und deshalb hier nicht weiter diskutiert.
47

4 Implementierung
Benutzer
Client
privater Rechner
zentrale Komponente
Manager
Breeze
Simulationsobjekt
Namensdienst
Codeverteilung
Benutzerverwaltung
Simulationsknoten
Generator
Codeverteilung
Abbildung 4.2: Dienste im verteilten System, gruppiert nach den Knoten, auf denen sie ausgeführt
werden.
2. Die Gruppe der Simulationsknoten: Auf ihnen läuft ein Generator, der bei Bedarf
Simulationsobjekte für diesen Knoten erzeugt.
3. Knoten, auf denen private Codeverteilungsdienste laufen, die von den einzelnen
Benutzern gestartet wurden.
4. Die Benutzerknoten, die auf das verteilte System zugreifen.
Diese Gruppeneinteilung, wie sie auch in Abbildung 4.2 gezeigt wird, ist fliessend. So
lassen sich alle Gruppen zu Testzwecken auch auf einem einzigen Knoten ausführen, und
private Codeverteilungsdienste werden in der Praxis vermutlich auch auf Benutzerknoten
oder Simulationsknoten laufen, statt einen eigenen Knoten zu verwenden.
Auf der zentralen Komponente müsste im Grunde lediglich der Namensdienst laufen,
da er eine feste Adresse benötigt, an der er von den anderen Objekten gefunden
werden kann. Verwaltungstechnisch ist es jedoch einfacher, auch den Manager, die Benutzerverwaltung,
den standardmäßig verwendeten Codeverteiltungsdienst und Breeze
auf demselben Rechner auszuführen. Damit besitzt das verteilte System lediglich einen
Single-Point-of-Failure, bei dessen Ausfall nicht mehr auf das System zugegriffen werden
kann. Andernfalls würden auch die Knoten, auf denen der Manager oder die Benutzerverwaltung
laufen, zu Problemknoten, da ICE eine Replikation des Managers zur Zeit
noch nicht unterstützt. Eine Replikation der Benutzerverwaltung wäre möglich, ist aber
momentan nicht vorgesehen, um den Aufwand bei Änderungen an den Benutzern oder
Gruppen möglichst gering zu halten.
Bei dem Manager und der Benutzerverwaltung ergibt sich zusätzlich ein gravierender
Geschwindigkeitsvorteil, wenn die Dienste auf demselben Knoten ausgeführt werden, auf
dem auch der Namensdienst läuft: Für die Verteilung der Simulationen auf Simulationsknoten
werden viele Informationen über das verteilte System benötigt, wie die Anzahl
der verfügbaren Knoten und deren Last. Da der Manager und der Namensdienst auf
demselben Rechner ausgeführt werden, müssen diese Anfragen nicht über das Netzwerk
48

4.4 Benutzeranwendungen
gestellt werden, sondern werden von ICE lokal weitergeleitet. Ähnlich ist es mit der
Benutzerverwaltung: Da die meisten Anfragen bezüglich Benutzerrechten vom Manager
ausgehen, ist es sinnvoll, beide Dienste auf derselben Maschine zu betreiben.
4.4 Benutzeranwendungen
Im Folgenden wird näher auf die Implementierung einiger in Abschnitt 3.4.2 beschriebenen
Anwenderprogramme – im speziellen dem Paketgenerator, dem Ergebnisexportierer
und der Modulsuche – eingegangen. Die Simulationsverwaltung und die Benutzerverwaltung
werden nicht näher erklärt, da sie hauptsächlich eine Benutzerschnittstelle zum
verteilten System anbieten und ihr Gegenpart im System die hauptsächliche Arbeit übernimmt.
Um einen Simulationsauftrag zu starten, bedient sich die Simulationsverwaltung
dem in Abschnitt 3.3.1 beschriebenen Verfahren.
Abschließend werden die Erweiterungsmöglichkeiten der grafische Benutzerschnittstelle
(GUI) beschrieben. Eine ausführlichere Beschreibung der einzelnen Elemente der GUI
würde jedoch den Rahmen der Diplomarbeit sprengen, so dass lediglich die Grundfunktionen
und die Erweiterungsmöglichkeiten dargestellt werden.
4.4.1 Paketgenerator
Der Paketgenerator erstellt, wie oben beschrieben, aus Modul- oder Typbeschreibungen
die entsprechenden Modul- bzw. Typpakete. Dazu verwendet er Saxon (vgl. 2.4.3),
um die entsprechenden Dateien über einzelne XSLT-Transformationen zu erzeugen. Um
den Modulnamen auszulesen, muss der Paketgenerator zuerst die Beschreibung mit dem
XML-Parser JDOM (siehe: 2.4.2) einlesen, um den Modulnamen auszulesen. Saxon
ermöglicht es, auf die bereits im Speicher liegende Beschreibung verschiedene Transformationen
in Folge anzuwenden, so dass die Beschreibungsdatei nicht jedesmal neu
eingelesen werden muss. Die einzelnen Dateinamen werden, wie im Paketformat spezifiziert,
anhand des Modulnamens erzeugt, wobei bereits bestehende Dateien überschrieben
werden. Davon ausgenommen ist die Modulimplementierung: Existiert bereits eine
Implementierungsdatei, wird diese zuerst umbenannt und dadurch nicht überschrieben.
Dieses Vorgehen hat den Vorteil, dass kein Code durch die Generierung der Implementierungsdatei
verloren gehen kann. Hat der Entwickler Teile des Moduls schon programmiert,
kann er den Programmcode in die neu erzeugte Datei kopieren. Angedacht war
auch eine inkrementelle Transformation für die Modulimplementierung, die ausschließlich
die notwendigen Teile in der Datei ändert. Dies hätte jedoch einen Parser für die
Modulimplementierung vorausgesetzt, und den Rahmen dieser Diplomarbeit gesprengt.
4.4.2 Ergebnisexportierer
Ist eine Simulation beendet, können die Ergebnisse entweder automatisch oder vom Benutzer
selbst abgeholt (vgl. Abschnitt 3.3.5) und in einer lokalen Datenbank gesichert
werden. Die Ergebnisse liegen dort allerdings in Form mehrerer Byteströme vor, die das
selbe Format haben, wie auch die Parameter in einem Simulationsauftrag (vgl. Abschnitt
4.2.3). Um diese Parameter in ein menschenlesbares Format zu überführen, bedarf es
49

4 Implementierung
des Ergebnisexportierers, der aus den Ergebnissen eine XML-Beschreibung erzeugt. Die
Konvertierung erfolgt dabei umgekehrt zu der Parametererzeugung im Simulationsauftrag:
Zuerst werden aus dem Simulationsauftrag die beteiligten Modulknoten bestimmt.
Anschließend wird für jeden Modulknoten überprüft, ob ein Ergebnis vorhanden ist. Ist
dies der Fall, wird mit Hilfe einer modulspezifischen Slice-Hilfsklasse der Bytestrom in
ein Objekt transformiert. Anschließend werden durch die Reflection-API die einzelnen
Felder im Ergebnis-Objekt durchgegangen und in entsprechende XML-Elemente umgewandelt.
Zusätzlich zu den Ergebnissen werden auch noch die Konfigurations- und Einstellungsparameter
nach dem gleichen Schema in die XML-Beschreibung aufgenommen.
Dies erlaubt es dem Benutzer, die Simulationsergebnisse in Abhängigkeit der Parameter
darzustellen. Ein Beispiel dafür wäre das Auftragen der Ergebnisse in Abhängigkeit der
Rauschleistung des Kanals.
Ursprünglich war geplant, die Ergebnisse direkt in ein Format abzuspeichern, in dem
die einzelnen Werte durch Kommata getrennt sind (CSV ). Durch die Verwendung beliebiger
Ergebnistypen stellte sich dieses Vorhaben jedoch als beinahe unmöglich heraus, da
Anzahl und Größe der Felder von den Ergebnistypen abhängig sind. Die Beschreibung
der Ergebnisse in XML stellt einen Kompromiss dar, da es mit Hilfe von XSLT oder kleinen
Programmen ohne großen Aufwand möglich ist, ausgewählte Teile der Ergebnisse
in CSV oder ein beliebiges anderes Format zu konvertieren.
4.4.3 Modulsuche
Die Modulsuche wird benötigt, um Benutzern den Zugriff auf Module und Typen im
verteilten System zu erleichtern. Sie fragt dafür eine Menge von Codeverteilungsdiensten
nach den angebotenen Modulen und Typen an, und präsentiert diese Liste dem Benutzer.
Dieser kann daraus auswählen, welche Module und Typen er für seine Simulation
verwenden möchte und ihre Beschreibung auf seinen lokalen Rechner herunterladen
lassen. Die Synchronisierung erfolgt dabei ähnlich zu der Synchronisierung bei den Simulationsknoten
(vgl. 3.2.3), jedoch wird nicht anhand einer Simulations-ID, sondern
direkt nach den Modulnamen synchronisiert.
Dabei trat in der Implementierung ein ärgerliches Problem auf: Damit eine Modulbeschreibung
validiert werden kann, benötigt sie die Angabe, wo sich die dazugehörige
Schemabeschreibung findet. Zunächst wurde das Problem dadurch gelöst, dass bei der
Modulerstellung der absolute Pfad zu der Schemabeschreibung angegeben wurde. Dies
hatte jedoch den großen Nachteil, dass der Pfad meist nur auf dem Rechner des Modulentwicklers
gültig ist. Möchte ein anderer Benutzer dieses Modul verwenden, so stimmt
höchstwahrscheinlich der Pfad nicht mehr und das Modul kann nicht benutzt werden,
wenn der Benutzer die Pfade nicht manuell ändert. Als Lösung boten sich relative Pfade
an: Eine relative Adressierung erlaubt das Finden der Schemabeschreibung ausgehend
von dem Ort, an dem die Modulbeschreibung liegt. Dieses Vorgehen setzt nur voraus,
dass die hierarchische Dateistruktur beim Entwickler und dem Benutzer gleich ist, d.h.
dass in beiden Fällen die Schemabeschreibung mit der gleichen relativen Pfadangabe
gefunden werden kann. Dies ist jedoch insofern unbefriedigend, weil für die Transformationen
verschiedene relative Pfadangaben zu den einzelnen Beschreibungen benötigt
werden und man den Überblick bei der Konfiguration leicht verlieren kann. Aus die-
50

4.4 Benutzeranwendungen
sem Grund werden letztendlich doch wieder absolute Pfade verwendet. Jedoch passt die
Modulsuche die Pfade nach der Synchronisierung automatisch an die lokale Umgebung
an.
4.4.4 Die grafische Oberfläche
Die grafische Oberfläche (GUI) dient der leichteren Bedienbarkeit von Lethe. Sie kapselt
die Zugriffsmöglichkeiten auf das verteilte System und präsentiert sie angemessen
aufbereitet dem Benutzer. Momentan unterstützt die GUI das Erstellen, Starten und
die Verwaltung von Simulationen. Außerdem unterstützt sie den Entwickler bei der Erstellung
von Modul- und Typbeschreibungen. Dem Benutzer geht sie bei der Erstellung
von Simulationsaufträgen zur Hand.
Damit die GUI leicht erweiterbar ist, stellt sie ein Framework zur Verfügung, um beliebige
Funktionen einbinden zu können. Tatsächlich sind bis auf die Authentifizierung alle
unterstützten Benutzeranwendungen als Erweiterung realisiert. Die GUI selbst stellt das
Basisfenster bereit mit einer Buttonleiste, die einen Wechsel der verschiedenen Funktionen
erlaubt. Außerdem stellt sie die Schnittstellen aus Abbildung C.7 im Anhang für
die Verwendung der Buttonleiste, des Hauptfensters und einer Konfigurationsdatei bereit.
Auch gibt es für Erweiterungsprogramme die Möglichkeit, sich für Menüeinträge zu
registrieren, so dass sie bei einer entsprechenden Benutzerauswahl aufgerufen werden.
Eine Erweiterung muss unterhalb des Verzeichnisses plugins im Dateisystem abgelegt
sein oder in den Klassenpfad von Java aufgenommen werden. Ansonsten kann die
GUI nicht auf die Erweiterung zugreifen. In die GUI kann es entweder über den Menüpunkt
others → plugins → add oder manuell durch Bearbeiten der Einstellungsdatei
properties.xml hinzugefügt werden.
In Abbildung 4.3 und 4.4 werden die Fenster zur Simulationsverwaltung und die
Simulationserstellung gezeigt. Beide sind über das Erweiterungs-Framework in die GUI
eingebunden. Gut zu sehen ist die erweiterungsspezifische Buttonleiste links oben. Über
die Buttons rechts oben lassen sich weitere Erweiterungen auswählen.
51

4 Implementierung
Abbildung 4.3: Screenshot von der Simulationsverwaltung in der GUI. Momentan sind 2 Simulationsaufträge
mit jeweils fünf Runden aktiv.
52

4.4 Benutzeranwendungen
Abbildung 4.4: Screenshot von der Simulationserstellung in der GUI. Gezeigt wird die Standardbelegung
für die Einstellungsparameter der Runden einer Simulation.
53

5 Zusammenfassung und Ausblick
Dieses Kapitel erlaubt einen Überblick über die gesamte Diplomarbeit. Dazu wird sie
im ersten Abschnitt kurz zusammengefasst.
Anschließend wird diskutiert, ob und wie die in Abschnitt 1.2 gestellten Anforderungen
tatsächlich erfüllt wurden. Der nächste Abschnitt beschäftigt sich mit der Frage
nach den Lizenzbedingungen, unter der das verteilte System und die Anwenderprogramme
stehen. Diese ist insbesondere bei einer kommerziellen Weiterentwicklung von Lethe
zu berücksichtigen.
Im vierten Abschnitt wird diskutiert, ob die Entscheidung für ICE und gegen CORBA
in Abschnitt 3.2.1 gerechtfertigt war.
Abgeschlossen wird das Kapitel mit dem fünften Abschnitt, der Ideen präsentiert, die
während des Entwurfs und der Entwicklung des verteilten Systems aufgekommen sind.
Diese Ideen konnten wegen Zeitmangels nicht umgesetzt werden, stellen aber interessante
und nützliche Aspekte für zukünftige Weiterentwicklungen von Lethe dar.
5.1 Zusammenfassung
Ziel dieser Diplomarbeit war der Entwurf und die Entwicklung eines verteilten Simulationssystems,
um das in der Diplomarbeit von Alexander Bernauer erstellte Framework
auf verteilten Rechnern automatisiert auszuführen und anzusteuern.
Entstanden ist ein Simulationssystem mit einem Mehrbenutzersystem, einer automatisierten
Codeverteilung und einem Sicherungskonzept, das Knotenausfälle ausreichend
kompensiert. Das verteilte System erlaubt eine automatisierte Ressourcenzuteilung
und damit eine optimale Auslastung vorhandener Rechenkapazitäten. Desweiteren
kann durch die Aufteilung von Simulationen in unabhängige Runden die Rechendauer
für eine Simulation spürbar gesenkt werden, indem die einzelnen Runden parallel
ausgeführt werden.
Neben dem verteilten System wurde auch ein Modulkonzept verwirklicht, das eine
einfache Wiederverwendung von Modulen im verteilten System ermöglicht. Dazu wurde
eine Sprache entworfen, die die einzelnen Bestandteile eines Moduls beschreibt. Mehrere
Module lassen sich dann zu einer Simulation verknüpfen, die mit weiteren Informationen
versehen, im verteilten System ausgeführt werden kann. Damit Module beliebige
Parameter für ihre Konfiguration und ihren internen Zustand verwenden können, musste
eine Lösung gefunden werden, um zur Laufzeit Objekte aus den Modulbeschreibungen
zu erstellen.
Außerdem wurden verschiedene Anwenderprogramme erstellt, um dem Benutzer den
Zugriff auf das verteilte System und auf seine laufenden Simulationen zu erleichtern. Desweiteren
unterstützen diese ihn bei der Erstellung von Modulen und Simulationen. Um
55

5 Zusammenfassung und Ausblick
die Verwendung von Lethe möglichst einfach zu gestalten, wurde neben den konsolenbasierten
Anwenderprogrammen auch eine grafische Oberfläche entworfen und entwickelt,
die eine möglichst intuitive Benutzung der angebotenen Möglichkeiten erlaubt.
5.2 Erfüllung der Anforderungen
Die Anforderung an eine einfache Bedienbarkeit des verteilten Systems ist durch die
Verwendung von ICE und dem IceGrid-Dienst erfüllt (vgl. Abschnitt 4.3.1).
Ein Mehrbenutzerbertrieb wird durch die Rechte- und Benutzerverwaltung unterstützt
und gewährleistet (siehe auch: Abschnitt 3.2.4, 3.2.5 und 4.3.3).
Die Ausfallsicherheit des verteilten Simulationssystems wird durch die Erstellung von
Sicherungspunkten (siehe Abschnitt 3.3.1) gewährleistet, solange nicht der zentrale Knoten
im verteilten System ausfällt. Dieser Ausfall ist im Entwurf und der Implementierung
des zentralen Koordinators ausreichend berücksichtigt, so dass das Wiederanlaufen des
zentralen Knotens und somit des Simulationsbetriebs ohne Verluste möglich ist.
Die geforderte automatische Ressourcenzuteilung findet im Manager (vgl. Abschnitt
4.3.2) gemäß den derzeitigen Erkenntnissen statt. Sollte es sich in der Praxis ergeben,
das eine andere Zuteilung besser geeignet ist, lässt sie sich sehr einfach austauschen
(siehe dazu Abschnitt 4.3.2).
Module und Simulationen lassen sich über die GUI einfach und ohne XML-Kenntnisse
erstellen. Desweiteren können die meisten Anwenderprogramme wahlweise über die GUI
bedient oder über die Kommandozeile ausgeführt werden (vgl. Abschnitt 4.4).
Damit sind die in Abschnitt 1.2 spezifizierten Anforderungen im verteilten System
und den Anwenderprogrammen erfüllt und umgesetzt. Die Implementierung in Java
bietet zusätzlich eine leicht verwendbare, plattformunabhängige Umsetzung des Systementwurfs.
5.3 Lizenzbestimmungen
Das verteilte System und die Benutzeranwendungen basieren auf bereits bestehende
Produkte. Diese müssen bei der Frage nach den Lizenzbestimmungen für Lethe berücksichtigt
werden. Diese Produkte sind:
ICE Das verteilte Simulationssystem basiert auf ICE, das unter der GNU General Public
Licence (GPL) [19] veröffentlicht ist. Damit stehen alle Programme und Anwendungen,
die auf das verteilte System zugreifen oder anderen darüber Dienste zur
Verfügung stellen, automatisch ebenfalls unter der GPL. Auf Nachfrage werden
von der Firma ZeroC [23] jedoch auch kommerzielle Lizenzen vergeben.
JDOM Verschiedene Anwenderprogramme greifen auf JDOM zu, das unter der freizügigen
Lizenz der Apache-Foundation [2] steht. Sie erlaubt die Weitergabe von
Binärpaketen ohne den Quelltext zur Verfügung zu stellen.
Saxon Das zur XSLT-Transformation verwendete Saxon ist unter der Mozilla Public
License [36] veröffentlicht, die ebenfalls eine uneingeschränkte Weitergabe von
proprietärem Code erlaubt.
56

5.4 Probleme mit ICE
Die Verwendung von JDOM und Saxon stellt damit keine Einschränkung für eine
kommerzielle Nutzung des verteilten Systems und der Benutzeranwendungen von Lethe
dar. Ist dies gewünscht, müssen allerdings von ZeroC kommerzielle Lizenzen für
ICE angefordert werden. Ansonsten steht Lethe – mit Ausnahme von JDOM und Saxon
– unter der GPL. Dies bedeutet insbesondere, das bei Änderungen an Lethe und
anschließender Weitergabe auch der geänderte Quellcode zur Verfügung gestellt werden
muss.
Ein weiteres lizenzrechtliches Problem kann sich bei der Entwicklung eigener Module
ergeben, wenn Bibliotheken eingebunden werden. Dies wird aber in [7, Abschnitt 5.3]
diskutiert, so dass hier nicht näher darauf eingegangen werden muss.
5.4 Probleme mit ICE
Die Verwendung von ICE als Middleware hat einige Probleme nach sich gezogen, die
zu Beginn der Arbeit noch nicht abzusehen waren. Die Schwierigkeiten ergaben sich
speziell im Umgang mit der Beschreibungssprache Slice :
• Um Sprachen wie VisualBasic zu unterstützen, die zwischen Groß- und Kleinschreibung
nicht unterscheideen, macht auch Slice solche Differenzierungen nicht.
Eine einmal getroffene Schreibweise muss allerdings eingehalten werden, d.h. es
ist verboten, eine Struktur namens Foo zu definieren und sie dann als FOO zu
benutzen.
• ICE reserviert sich einen verhältnismäßig großen Bereich im Namensraum für
Bezeichner. Sie dürfen nicht mit ice beginnen, oder mit helper, holder, prx oder
ptr enden. Diese Einschränkung gilt nach obigem Punkt auch für alle denkbaren
Schreibweisen, wie zum Beispiel Ice oder ICE. Desweiteren dürfen die Bezeichnernamen
keinen Unterstrich enthalten. Diese Regeln müssen deshalb bei Lethe auch
von den Modulentwicklern bei der Wahl von Bezeichnern strikt beachtet werden.
• Slice unterstützt Vorwärtsdeklarationen ausschließlich für Klassen und Schnittstellen.
Dies führt dazu, dass Strukturen sich nicht selbst enthalten dürfen. Auch
dürfen sie keine Strukturen enthalten, die wiederum sie enthalten.
• Um Definitionen aus anderen Dateien zu unterstützen, benutzt Slice das Include-
Konzept mit Hilfe des Präprozessors von C. Damit sind zyklische Abhängigkeiten
von einzelnen Dateien verboten, da sie der Präprozessor nicht auflösen kann.
Weitere Schwierigkeiten traten mit der Konfiguration von IceSSL und der Bereitstellung
von IcePatch-Servern auf. Diese Probleme, sowie die Schwierigkeiten mit Slice,
konnten alle gelöst oder umgangen werden. Jedoch sind sie sehr ärgerlich, speziell was
die Benennung von Variablen betrifft.
Dennoch ist ICE eine gute Wahl für ein in sich abgeschlossenes System wie Lethe: ICE
lässt sich problemlos auf verschiedenen Plattformen installieren und unterstützt Java,
C++ und Python. Letztere werden in der Implementierung von Alexander Bernauer
verwendet. Demgegenüber ließ sich für CORBA keine freie Implementierung finden, die
57

5 Zusammenfassung und Ausblick
alle drei Sprachen unterstützt. Außerdem sollte man die Dienste und Plugins, die ICE
anbietet, nicht unterschätzen, da sie die Entwicklungszeit von neuen Anwendungen stark
verkürzen können. Lethe verwendet selbst viele der angebotenen Dienste: Einerseits um
die Wartung des Systems zu erleichtern; andererseits, um Dienste wie die Codeverteilung
einfach und plattformunabhängig anbieten zu können. Ohne diese Dienste hätte die
Entwicklung von Lethe sicher mehr Zeit in Anspruch genommen.
5.5 Ausblick
Aufgrund der Größe der Aufgabe und der beschränkten Zeit konnten nicht alle Ideen
umgesetzt werden. Im Folgenden wird deshalb auf mögliche Erweiterungen eingegangen.
Außerdem muss bewusst sein, dass die im Rahmen der Diplomarbeit erstellten Programme
lediglich den Charakter von Prototypen haben. Sie wurden während der Implementierung
fortlaufend getestet, speziell zugeschnittene Testabläufe fehlen jedoch.
Auch muss die GUI noch mit aussagekräftigeren Fehlermeldungen versehen werden,
um den Benutzer bei Problemen mit der Erstellung von Simulationen zu unterstützen.
1. Erweiterungen für das verteilte System:
• Ein autonomes System mit gleichberechtigten Knoten würde sowohl die Wartbarkeit
als auch die maximale Größe des verteilten Systems erhöhen. Allerdings
muss geprüft werden, ob es den zusätzlichen Programmieraufwand
tatsächlich lohnt.
• Neue Zugriffsmöglichkeiten für die Codeverteilung. Dabei stellt sich die Frage,
ob ein Zugriff auf Web- oder FTP-Server benötigt wird.
• Eine Einführung von Simulationsgruppen, um Aktionen auf mehrere Simulationen
gleichzeitig ausführen zu können.
• Es muss geprüft werden, ob das Umziehen von Simulationen durch die automatische
und regelmäßige Erstellung von Sicherungspunkten noch benötigt
wird. Ist dies der Fall, wäre es von Vorteil, Simulationen Knotengruppen zuzuweisen,
auf denen sie ausschließlich ausgeführt werden, um ein erneutes
Ausführen der Simulationen auf den Ursprungsknoten zu verhindern (vgl.
letzter Absatz von Abschnitt 4.3.2).
2. Erweiterungen auf Benutzerseite:
• Anzeigen von Resultaten und Statistiken in der Anwendung selbst. Dies kann
zum Beispiel mit Hilfe der Open Source API JFreeChart von JFree [24] geschehen.
• Eine erleichterte Zusammenstellung von Simulationen durch einen graphischen
Editor in der Anwendung. Dazu bietet sich die JUNG API [25] an, die
bereits über verschiedene Werkzeuge zur Darstellung von Graphen verfügt.
Sie unterstützt auch das für den Simulationsgraphen benötigte Konzept des
Hypergraphen. Zur Darstellung sollte er aber in einen gewöhnlichen Graphen
mit Hilfsknoten umgewandelt werden.
58

5.5 Ausblick
• Eine automatische Überprüfung der durch den Benutzer eingegebenen Parameter
bei der Erstellung von Simulationen. Diese muss mit möglichst aussagekräftigen
Fehlermeldungen verbunden sein, wenn sich die vorgenommene
Eingabe mit der Spezifikation der Parameter in der Modulbeschreibung widerspricht.
• Mit Hilfe von ICE-E ist es möglich, ICE auf Smartphones und PDAs zu installieren.
Das ermöglicht es, verschiedene Benutzerprogramme zum Zugriff
auf das verteilte System auf mobile Endgeräte zu portieren. Denkbar ist damit
zum Beispiel eine mobile Lösung, um den Status von Simulationen zu
überwachen.
3. Messungen: Interessante Messungen im verteilten System kamen leider zu spät
auf, um sie mit der angemessenen Sorgfalt durchzuführen. Interessante Messungen
speziell im Zusammenhang mit der Diplomarbeit von Alexander Bernauer sind
folgende:
• Simulation starten: Wieviel Zeit vergeht, bis eine Simulation tatsächlich gestartet
ist? Dazu gehört vor allem die benötigte Zeit, um ein neues Simulationsobjekt
zu erstellen und zu initialisieren. Diese Dauer sollte im Bereich
von wenigen Minuten liegen und spielt eine wichtige Rolle bei der Wahl der
Zeitscheibengröße (vgl. Abschnitt 4.3.2). Die Standardgröße der Zeitscheibe
beträgt 1h und sollte damit ausreichend groß gewählt sein, dass die Erstellungszeit
des Simulationsobjekts nicht die Ausführung dominiert.
• Simulationen verteilen: Hier stellt sich die Frage, wieviel Zeit der Verteilungsalgorithmus
(vgl. Abschnitt 4.3.2) benötigt, um den Simulationen Knoten zur
Ausführung zuzuteilen. Diese Dauer beschränkt das verteilte System sowohl
in der Anzahl der Simulationsknoten als auch in der Benutzerzahl, da während
dieses Zeitraums keine Simulationen ausgeführt werden. Für den Einsatzzweck
von Lethe in einer einzelnen Abteilung sollten diese Überlegungen
jedoch unerheblich sein, da ein Großteil der benötigten Zeit für die Bewertung
und Sortierung von Simulationsaufträgen aufgewendet wird und nicht
zu erwarten ist, dass im verteilten System massenhaft Simulationsaufträge
zur selben Zeit ausgeführt werden sollen.
59

Anhang A
Kommandozeilen-Tools
A.1 Simulationsverwaltung
Die Simulationsverwaltung startet neue Simulationsaufträge und ermöglicht dem Benutzer
Zugriff auf bereits gestartete Simulationen.
Kommando: simulationManagement [-u ] [-p ] [-l | -s
| [-a | -p | -r | -g] | -m ]
-l Listet die Simulationen des Benutzers auf.
-s Startet den in beschriebenen Simulationsauftrag.
-a Bricht den Simulationsauftrag oder die Runde, die in angegeben
ist, ab.
-p Pausiert den Simulationsauftrag oder die Runde, die in angegeben
ist.
-r Fügt einen pausierten Simulationsauftrag oder eine pausierte Runde mit
der ID wieder in die automatische Verteilung ein.
-m Verschiebt die Simulation mit der ID auf den Simulationsknoten
.
-g Holt die Ergebnisse der Simulation mit der ID aus dem verteilten
System und speichert sie lokal ab.
-u Der zur Authentifizierung am System verwendete Benutzernamen. Wird
kein Benutzernamen angegeben, verwendet simulationManagement den in der
Konfigurationsdatei unter config.Authentication.user gespeicherten Benutzer.
-p Das zur Authentifizierung am System verwendete Passwort. Wird kein
Passwort angegeben, verwendet simulationManagement das in der Konfigurationsdatei
unter config.Authentication.passwd gespeicherte Passwort.
A.2 Benutzerverwaltung
Die Benutzerverwaltung erlaubt dem Administrator das einfache Anlegen und Löschen
von Benutzern und Gruppen. Desweiteren können bestehende Benutzer und Gruppen
mit ihren Rechten angezeigt werden.
61

Anhang A Kommandozeilen-Tools
Kommando: userManagement [-u ] [-p ] [-lu [] |
-lg [] | -lp | -au [-x priority] -g | -ag
[-x ] [-g ] | -du | -dg | -su
[-x ] -g | -sg [-x ] [-g

A.4 Modulsuche
-i Erzeugt eine Slice-Definitionsdatei aus .
-c Erzeugt Hilfsmethoden und ein Gerüst zur Modulimplementierung aus
.
-s Erzeugt eine neue Schema-Beschreibung aus .
-d Erzeugt eine neue spezielle Modul-/Typ-Beschreibung aus .
-x Kopiert zusätzlich in das erstellte Paket.
-m Erzeugt die Datei , in der modulspezifische Übersetzungsanweisungen
stehen können.
-j Erzeugt eine neue Schema-Datei aus , wenn eine
Simulationsbeschreibung ist.
A.4 Modulsuche
Die Modulsuche erlaubt es dem Benutzer, Moduldefinitionen im verteilten System zu
finden und lokal zu nutzen.
Kommando: moduleFinder [-l | -m .. | -t
.. ] [-p ]
-l Listet alle verfügbaren Module und Datentypen der Codeverteilung unter address
auf.
-m .. Synchronisiert die Modulbeschreibungen
.. mit den Beschreibungen der Codeverteilung unter .
-t .. Synchronisiert die Datentypbeschreibungen
.. mit den Beschreibungen der Codeverteilung unter
.
-p Verwendet für die Anfrage an die Codeverteilung nicht den dafür vorgesehenen
Standardport, sondern die Portnummer port.
A.5 Ergebnisse exportieren
Der Ergebnisexportierer exportiert Simulationsergebnisse aus einer speziellen Datenbank
nach XML.
Kommando: resultExporter [-l | -e ]
-l Listet alle verfügbaren Ergebnisse auf.
-e Exportiert die Ergebnisse der Simulation mit ID in
die Datei .
63

Anhang B
Installation und Wartung
B.1 Installation
Die Installation der einzelnen Komponenten läuft momentan über ein make-System.
Anpassungen müssen dabei im Hauptverzeichnis in der Datei config.mak vorgenommen
werden.
B.1.1 Client
Die Anwenderprogramme lassen sich durch das im Hauptverzeichnis eingegebene Kommando
make client installieren. Im Verzeichnis client/bin liegen Skripte, um die
einzelnen Programme zu starten.
B.1.2 zentrale Komponente
Um die Dienste auf der zentralen Komponente zu installieren, muss im Hauptverzeichnis
das Kommando make center ausgeführt werden. Anschliessend werden der Manager, die
Benutzerverwaltung und die Codeverteilung erzeugt. Breeze ist in Python geschrieben
und braucht deshalb nicht übersetzt zu werden.
Um die zentrale Komponente im verteilten System zu starten, müssen folgende Dienste
im Verzeichnis grid gestartet werden:
• icegridregistry - -Ice.Config=registry.cfg startet den Namensdienst.
• icegridadmin - -Ice.Config=center.cfg ’-e application add lethe.xml’
liest die Konfigurationsdatei für das verteilte System ein und trägt die am System
beteiligten Knoten in eine Liste ein.
• icegridnode - -Ice.Config=center.cfg fügt den Knoten als zentrale Komponente
dem verteilten System hinzu.
B.1.3 Simulationsknoten
Ein Simulationsknoten lässt sich durch den Aufruf von make node im Hauptverzeichnis
erstellen.
Anschliessend muss der Knoten in das verteilte System hinzugefügt werden. Dies
geschieht durch:
• icegridnode - -Ice.Config=node.cfg
65

Anhang B Installation und Wartung
B.1.4 Codeverteilung
Die Codeverteilung wird durch den im Hauptverzeichnis ausgeführten Aufruf make
sourceservice erstellt.
Anschliessend muss der Knoten in das verteilte System hinzugefügt werden. Dies
geschieht durch:
• sourceservice/run [-p]
Dabei ist die Portnummer, an der der Dienst eingehende Anfragen annimmt.
Fehlt die Angabe der Portnummer, wird versucht, stattdessen Port 10.000 zu benutzen.
B.2 Wartung
B.2.1 Simulationsknoten hinzufügen
Um einen neuen Simulationsknoten hinzuzufügen, muss die Datei grid/lethe.xml um
einen neuen Simulationsknoten erweitert werden. Dies geschieht durch folgenden Eintrag:
Anschliessend muss die Konfiguration im verteilten System aktualisiert werden. Dies
geschieht lokal von dem Rechner, auf dem die zentrale Komponente läuft mit:
• icegridadmin –Ice.Config=center.cfg ’-e application update
lethe.xml’
Wenn auf dem Rechner noch keine Knoteninstanz ausgeführt wird, muss zusätzlich
noch mit:
• icegridnode –Ice.Config=node.cfg
eine Instanz gestartet werden. Anschliessend ist der Knoten im System aufgenommen.
B.2.2 Simulationsknoten entfernen
Um einen Knoten aus dem verteilten System zu entfernen, muss der entsprechende
Eintrag für den Knoten in der Datei grid/lethe.xml gelöscht werden. Anschliessend
muss diese Änderung im System propagiert werden. Dies verläuft analog zum Hinzufügen
eines Simulationsknotens.
66

B.2 Wartung
B.2.3 Neue Codeverteilung hinzufügen
Eine neue Codeverteilung wird in das verteilte System hinzugefügt, indem eine neue
Knoteninstanz mit dem Befehl:
• sourceservice/run [-p]
gestartet wird. Um diesen Dienst zu nutzen, müssen die Adresse und der Port, falls er
angegeben wurde, in die Simulationsbeschreibung mit aufgenommen werden.
67

Anhang C
Schnittstellen
Im Folgenden sind die wichtigsten Schnittstellen im verteilten System abgebildet. Dies
sind im speziellen:
• Die Schnittstelle des Managers zur Annahme und Verwaltung von Simulationen,
sowie seine Schnittstelle mit den Simulationsobjekten.
• Die Schnittstelle des Generators zum Erzeugen von neuen Simulationsobjekten
sowie die Schnittstelle des Simulationsobjekts selbst.
• Die Schnittstelle der Benutzerverwaltung und -authentifikation und der Rechteverwaltung.
• Die Schnittstelle für die Codeverwaltung.
Außerdem ist die Schnittstelle zur Sortierung, und damit der Festlegung der Verteilungsreihenfolge,
von Simulationsaufträgen angegeben, sowie die zur Erweiterung der
GUI bereitgestellten Schnittstellen.
69

Anhang C Schnittstellen
C.1 Schnittstellen im verteilten System
Klassendiagramm_3
Manager
>
Comm.Manager.PublicInterface
+getNextId():String
+startSimulation(job:Comm.Job.Specification):void
+pauseSimulation(jobId:String):void
+restartSimulation(jobId:String):void
+abortSimulation(jobId:String):void
+moveSimulation(jobId:String,host:String):void
>
Comm.Manager.ProtectedInterface
+onSimulationFinished(jobId:String,suffix:String,results:Comm.Simulation.Results):void
+onSimulationError(jobId:String,suffix:String,error:String,abort:boolean):void
Abbildung C.1: Schnittstellen des Managers. Die Aufteilung in zwei Schnittstellen erfolgte wegen
dem 2-Zonen-Sichereitssystem.
70

C.1 Schnittstellen im verteilten System
Klassendiagramm_2
Simulationsobjekt
Comm.Simulation.Interface
+init(job:):void
+start(round:int):void
+resume(checkpoint:Comm.Simulation.Checkpoint):void
+stop():void
+suspend(out checkpoint:Comm.Simulation.Checkpoint,job:):void
Abbildung C.2: Schnittstelle des Simulationsobjekts. Auf diese greift ausschließlich der Manager
zu.
Klassendiagramm_5
Generator
Generator
+createSimulation(job:,suffix:String,buildOnly:boolean):Comm.Simlation.InterfacePrx
Abbildung C.3: Schnittstelle des Generators. Der Manager greift darauf zu, um Simulationsobjekte
zu erstellen.
71

Anhang C Schnittstellen
Klassendiagramm_6
Benutzerverwaltung
>
Comm.AuthenticationService.PublicInterface
+authenticate(user:String,password:String):String
+logout(user:String):void
>
Comm.AuthenticationService.ProtectedInterface
+userExists(user:int,sessionId:String):boolean
+getPriority(user:String):int
+hasPermission(user:String,owner:String,permission:String):boolean
+hasPermissions(user:String,owner:String,permissions:String[]):boolean
>
Comm.AuthenticationService.UserManagement
+getUser(user:String):User
+getGroup(group:String):Group
+getAllUsers():User[]
+getAllGroups():Group[]
+addUser(u:User,password:String):void
+addGroup(g:Group):void
+deleteUser(user:String):void
+deleteGroup(group:Group):void
+setUser(name:String,u:User):void
+setPassword(user:String,password:String):void
+setGroup(name:String,g:Group):void
Abbildung C.4: Schnittstellen der Benutzer- und Rechteverwaltung. Zusätzliche Schnittstelle
zur Authentifizierung der Benutzer.
72

C.1 Schnittstellen im verteilten System
Klassendiagramm_7
Codeverteilung
>
Comm.SourceService.PublicInterface
+announce(jobId:String,files:String[],f:Filter,source:SourceDesc):void
+getAvailableModules():String[]
>
Comm.SourceService.ProtectedInterface
+startSourceService(jobId:String):String
+stopSourceService(jobId:String):void
>
SourceController
+getSource(source:SourceDesc,files:String[],directory:String):void
+getSourceList(source:SourceDesc,directory:String):String[]
Abbildung C.5: Schnittstelle zur Codeverteilung. Die eine Schnittstelle wird ausschließlich von
den Benutzern genutzt, um Ressourcen für Simulationen anzumelden. Die andere
dient der Synchronisierung von Modulcode im verteilten System.
Klassendiagramm_4
Simulationsverteilung
>
SortingAlgorithm
+sort(jobs:Collection,seats:int):List
+init(manager:Manager):void
Abbildung C.6: Schnittstelle, um einen eigenen Zuteilungsalgorithmus zu implementieren. Der
verwendete Algorithmus muss in der Konfigurationsdatei angegeben werden.
73

Anhang C Schnittstellen
C.2 Schnittstellen der GUI
Klassendiagramm_1
GUI
>
Pluggable
+init():void
+release():void
+show():JPanel
+hide():void
>
Personalizable
+setSettings(settings:Element):void
+getSettings():Element
+getDefaultSettings():Element
>
ToolbarUsable
+getShowButton():JButton
+addToToolbar():List
Abbildung C.7: Schnittstellen für das Erweiterungsframework der GUI. Plugins sollten zumindest
die Schnittstelle Pluggable implementieren. Die anderen Schnittstellen
dienen der automatischen Speicherung von internen Zuständen und der Benutzung
der Buttonleiste in der GUI.
74

Anhang D
Software
D.1 verwendete Software
• Eclipse zur Entwicklung der Java-Programme
• EditiX zum Erstellen von XML-Beschreibungen, XML-Schema und XSLT-
Vorschriften
• Poseidon zum Erstellen von UML-Diagrammen
• SubEthaEdit zum Erstellen der Diplomarbeit
• SVN zur Versionskontrolle
• LATEX zur Textformatierung für die Diplomarbeit
• GNU make als Build-System
D.2 Inhalt der beigefügten CD
• Diplomarbeit im LATEX-Format, sowie das daraus erstellte pdf-Dokument.
• Implementierung der Diplomarbeit (client, manager, authservice, sourceservice)
• Dokumentation zu ICE 3.0.1
• Benötigte Programme (hauptsächlich ICE) zum Ausführen von Lethe sowohl als
kompiliertes Paket als auch die Source-Dateien
• Beispiele für Modul- und Datentypbeschreibungen, sowie Beispielsimulationen.
75

Index
.NET, 17
asynchroner Methodenaufruf, 8
Ausfallsicherheit, 23
Authentifizierung, 46
autonomes System, 18
C++, 7, 35
Client-Server Modell, 18
Codeverteilung, 20, 46–47
CORBA, 6, 17
Datentyp, 15
Freeze, 9
Glacier, 10, 25
Graph, 16, 40–42
Sicherheitszonen, 25
Sicherungspunkte, 30, 45
Simulation, 15–16, 31–33
Simulations-ID, 16, 44
Simulationsauftrag, 16, 29, 40–42
Slice, 7, 38–41, 47, 50, 57
SOAP, 17
Transformation, 11, 38–40
XML, 10, 36
XML-Schema, 10
XPath, 11
XQuery, 11
XSLT, 11, 37
Zugriffskontrolle, 23
ICE, 6
IceGrid, 9, 43
IcePatch, 9, 20, 46
IceSSL, 9, 25
IceStorm, 33
Java, 7, 11, 35
JDOM, 12, 56
Kommunikation, 26
Kommunikationsaufwand, 19, 28
Modul, 13–15, 37–40
Namensdienst, 8, 18, 48
Rechteverwaltung, 20–23
Reflection-API, 12, 36, 42, 50
RMI, 17
Saxon, 12, 56
Session-ID, 26
77

Literaturverzeichnis
[1] The ACE ORB (TAO). http://www.theaceorb.com, May 2006.
[2] Apache Licence. http://apache.org/licenses/LICENSE-2.0.html, May 2006.
[3] Alan O. Freier, Philip Karlton, Paul C. Kocher: The SSL Protocol —
Version 3.0. Internet Draft, Transport Layer Security Working Group, November
1996.
[4] Benoit, Kenneth: Which Electoral Formula Is the Most Proportional? A New
Look with New Evidence. Political Analysis, 8(4), 2000.
[5] Beowulf. http://www.beowulf.org/, April 2006.
[6] Berglund, Anders, Scott Boag, Donald D. Chamberlin, Mary F.
Fernández, Michael Kay, Jonathan Robie und Jérôme Siméon: XML Path
Language (XPath) 2.0. World Wide Web Consortium, Candidate Recommendation
CR-xpath20-20051103, 2005.
[7] Bernauer, Alexander: Entwurf und Implementierung eines Frameworks für Simulationen
in der Kanalcodierung. Diplomarbeit, University of Ulm, April 2006.
[8] Biron, Paul V. und Ashok Malhotra: XML Schema Part 2: Datatypes Second
Edition. World Wide Web Consortium, Recommendation REC-xmlschema-
2-20041028, 2004.
[9] Boag, Scott, Donald D. Chamberlin, Mary F. Fernández, Daniela Florescu,
Jonathan Robie und Jérôme Siméon: XQuery 1.0: An XML Query
Language. World Wide Web Consortium, Candidate Recommendation CR-xquery-
20051103, 2005.
[10] Bossert, M.: Channel Coding for Telecommunications. John Wiley & Sons, New
York, 1. Auflage, 1999.
[11] Bray, Tim, Jean Paoli, C. Michael Sperberg-McQueen, Eve Maler und
François Yergeau: Extensible Markup Language (XML) 1.0 (Third Edition).
World Wide Web Consortium, Recommendation REC-xml-20040204, 2004.
[12] Budszuhn, Frank: Subversion. Galileo Press, 1. Auflage, 2005.
[13] CoCentric System Studio. http://www.synopsys.com/, April 2006.
[14] The Common Object Request Broker Architecture (CORBA/IIOP), 2004.
79

LITERATURVERZEICHNIS
[15] David F. Ferraiolo, D. Richard Kuhn, Ramaswamy Chandramouli: Role-
Based Access Control. Artech House, April 2003.
[16] Fallside, David C. und Priscilla Walmsley: XML Schema Part 0: Primer
Second Edition. World Wide Web Consortium, Recommendation REC-xmlschema-
0-20041028, 2004.
[17] Free Software Foundation. http://www.fsf.org/, April 2006.
[18] GoldSim. http://www.goldsim.com/, April 2006.
[19] GNU General Public Licence. http://www.gnu.org/copyleft/gpl.html, April 2006.
[20] Haase, Oliver: Kommunikation in verteilten Anwendungen. Oldenbourg, 2001.
[21] Howatson, M.C.: Reclams Lexikon der Antike. Reclam, 2006.
[22] Hunter, Jason: JDOM 1.0. Java Specification Request (JSR) 102, 2001.
[23] The Internet Communication Engine. http://www.zeroc.com/, April 2006.
[24] JFree software projects. http://jfree.org/index.php, May 2006.
[25] Java Universal Network/Graph Framework. http://jung.sourceforge.net, May 2006.
[26] Kay, Michael: XSL Transformations (XSLT) Version 2.0. World Wide Web
Consortium, Candidate Recommendation CR-xslt20-20051103, 2005.
[27] Kazuaki Ishizaki, Motohiro Kawahito, Toshiaki Yasue et al.: Design,
Implementation, and Evaluation of Optimizations in a Just-In-Time Compiler. In:
Proceedings of the ACM 1999 conference on Java Grande. Java Grande Conference,
ACM Press, June 1999.
[28] Kennard Scribner, Mark C. Stiver: Soap. Markt + Technik Verlag, 2001.
[29] Matlab. http://www.mathworks.com/, April 2006.
[30] McLaughlin, Brett: Java and XML. O’Reilly & Associates, 1. Auflage, 2000.
[31] Michi Henning, Mark Spruiell: Distributed Programming with Ice.
http://www.zeroc.com/download/Ice/3.0/Ice-3.0.1.pdf, May 2006.
[32] Microsoft: .NET. http://www.microsoft.com/germany/msdn/netframework,
May 2006.
[33] MLDesigner. http://www.mldesigner.com/, April 2006.
[34] Mono Project. http://www.mono-project.com/, May 2006.
[35] Message Passing Interface. http://www.mpi-forum.org/, April 2006.
[36] Mozilla Public License, Version 1.0. http://www.mozilla.org/MPL/MPL-1.0.html,
May 2006.
80

LITERATURVERZEICHNIS
[37] GNU Octave. http://www.octave.org/, April 2006.
[38] The Object Management Group. http://omg.org/, May 2006.
[39] Ptolemy. http://ptolemy.eecs.berkeley.edu/, April 2006.
[40] Puder, Arno und Kay Römer: MICO is CORBA: A CORBA 2.2 Compliant
Implementation. 2nd Auflage, 1999.
[41] Parallel Virtual Machine. http://www.csm.ornl.gov/pvm/, April 2006.
[42] Rivest, Ronald L.: The MD5 Message-Digest Algorithm. Internet informational
RFC 1321, April 1992.
[43] Sainte-Laguë, André: Les réseaux. E. Privat, 1924.
[44] Saxon, the XSLT and XQuery Processor. http://saxon.sourceforge.net/, May 2006.
[45] Schildt, Herbert: Java Ent-packt. MITP-Verlag GmbH, Bonn, 1. Auflage, 2001.
[46] Scilab. http://www.scilab.org/, April 2006.
[47] Thompson, Henry S., David Beech, Murray Maloney und Noah Mendelsohn:
XML Schema Part 1: Structures Second Edition. World Wide Web Consortium,
Recommendation REC-xmlschema-1-20041028, 2004.
[48] World Wide Web Consortium. http://w3c.org, May 2006.
[49] William Tolone, Gail-Joon Ahn, Tanusree Pai Seng-Phil Hong: Access
Control in Collaborative Systems. ACM Computing Surveys, 37(1), March 2005.
81