Georg-August-Universität
Göttingen
Zentrum für Informatik
ISSN 1612-6793
Nummer ZFI-BM-2006-36
Masterarbeit
im Studiengang "Angewandte Informatik"
Entwurf und Implementierung einer
Ressourcen-Datenbank für das
Instant-Grid-Projekt der GWDG
Alexander Willner
am Lehrstuhl für
Praktische Informatik
Bachelor- und Masterarbeiten
des Zentrums für Informatik
an der Georg-August-Universität Göttingen
27. Oktober 2006

Georg-August-Universität Göttingen
Zentrum für Informatik
Lotzestraße 16-18
37083 Göttingen
Germany
Tel. +49 (5 51) 39-1 44 14
Fax +49 (5 51) 39-1 44 15
Email office@informatik.uni-goettingen.de
WWW www.informatik.uni-goettingen.de

Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst
und keine anderen als die angegebenen Quellen und Hilfsmittel verwen-
det habe.
Göttingen, den 27. Oktober 2006

Masterarbeit
Entwurf und Implementierung einer
Ressourcen-Datenbank für das
Instant-Grid-Projekt der GWDG
Alexander Willner
27. Oktober 2006
Erstgutachter Prof. Dr. Oswald Haan∗
Zweitgutachter Prof. Dr. Bernhard Neumair†
Betreuer Dr. Christian Boehme‡
Zentrum für Informatik
Georg-August-Universität Göttingen
∗Leiter der Arbeitsgruppe Anwendungs- und Informationssysteme der Gesellschaft für wissen-
schaftliche Datenverarbeitung mbH Göttingen.
†Geschäftsführer der Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen und
Inhaber des Lehrstuhls für Praktische Informatik an der Universität Göttingen.
‡Wissenschaftlicher Mitarbeiter der Arbeitsgruppe Anwendungs- und Informationssysteme der
Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen.

Gegenstand der vorliegendenArbeit ist der Entwurf und die Implementierung einer ein-
heitlichen Ressourcen-Datenbank für das Instant-Grid-Projekt1 der Gesellschaft für wis-
senschaftliche Datenverarbeitung mbH Göttingen2. Dieses wird innerhalb des Verbund-
vorhabens des D-Grid-Integrationsprojektes als Demonstrationsumgebung für Grid-Soft-
ware vom Bundesministerium für Bildung und Forschung finanziert.
Im Rahmen dieser Arbeit wird die automatische Erstellung einer Datenbank der im
Grid vorhandenen Hardware-Ressourcen mittels existierender Information-Provider er-
möglicht. Dazu ist eine entsprechende Erweiterung der Instant-Grid-Infrastruktur erfor-
derlich. Die gesammelten Informationen werden in ein einheitliches Datenformat über-
führt und eine Anbindung an das Instant-Grid-Portal implementiert. In diesem Zusam-
menhang werden Bedienelemente zur einheitlichen Benutzeroberfläche des Portals hinzu-
gefügt und so eine Benutzer-Schnittstelle zur Datenbank geschaffen.
„Man hält die Erzeugung von Information für ein Zeichen von Intelligenz,
während in Wirklichkeit das Gegenteil richtig ist: Die Reduktion, die Auswahl
der Information ist die viel höhere Leistung.“ [Heinz Zemanek, österreichischer
Informatiker]
1http://www.instant-grid.org
2http://www.gwdg.de

Inhaltsverzeichnis
1. Einleitung 1
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Grundlagen 4
2.1. Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Instant-Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Grid-Workflowmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Anforderungsanalyse 15
3.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Beschreibung der Systemidee und Zielsetzung . . . . . . . . . . . . . . . . . 15
3.3. Identifizierung der Anforderungsbeitragenden . . . . . . . . . . . . . . . . . 16
3.4. Identifizierung der Interessen der Anforderungsbeitragenden . . . . . . . . 16
3.5. Beschreibung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6. Konkretisierung der Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . 24
3.7. Beschreibung der Systemschnittstelle . . . . . . . . . . . . . . . . . . . . . . . 33
4. Design 36
4.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Anwendungsarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3. Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4. Klassenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. Implementierung und Test 46
5.1. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2. Statische Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3. Dynamische Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
i

Inhaltsverzeichnis
6. Zusammenfassung, Kritik und Ausblick 59
6.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2. Kritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A. Verwendete Konfiguration 61
A.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B. Dokumentation 63
B.1. Quelltexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.2. Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.3. GRDB-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.4. GRDB-Portletübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.5. D-GRDL-Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Glossar 80
Abbildungsverzeichnis 84
Tabellenverzeichnis 85
Literaturverzeichnis 86
ii

1. Einleitung
1.1. Motivation
Viele der weltweit verteilten, enormen Rechnerkapazitäten werden zu einem großen Teil
nicht verwendet. Die Idee, ungenutzte Hardware-Ressourcen für eigene Aufgaben einzu-
setzen, findet nicht nur schon seit längerem in Fachkreisen Anwendung (vgl. [1, 2, 3]),
sondern wird auch seit einigen Jahren in darüber hinaus bekannten Projekten (vgl. [4, 5])
umgesetzt. Hierbei handelt es sich fast ausschließlich um Techniken, bei denen ungenutzte
Rechenzyklen für einzelne Prozesse einer, auf mehrere Computer verteilten, Anwendung
genutzt werden, um ein gemeinsames Ergebnis einer speziellen Aufgabe zu berechnen.
Dies ist insbesondere bei vielen wissenschaftlichen Anwendungen notwendig, da die er-
forderliche Rechenleistung häufig nicht mehr von einem einzigen Computer oder einer
einzigen Einrichtung zur Verfügung gestellt werden kann.
Einen Schritt weiter gehen so genannte Grid-Systeme, die geforderte Dienste und Res-
sourcen unabhängig von ihrer räumlichen Entfernung transparent bereitstellen. Dabei ist
es gleichgültig, ob es sich wie oben genannt um Rechenleistung, Speicherkapazität oder
Softwareanwendungen handelt (s. Kap. 2.1). Der Aufbau und die Inbetriebnahme eines
Grids und der damit zusammenhängenden Komponenten kann jedoch sehr aufwendig
sein. Diesem Umstand hat das Instant-Grid-Projekt Rechnung getragen und eine selbst-
konfigurierende Grid-Umgebung geschaffen (s. Kap. 2.2). Die Demonstration der Anwen-
dungen im IG folgt jedoch sehr einfachen Mechanismen zur Verteilung von Rechenauf-
gaben und Identifizierung der im Netz verfügbaren Hardware-Ressourcen. Das Fraunho-
fer Institut für Rechnerarchitektur und Softwaretechnik (FIRST) widmet sich diesem The-
ma und entwickelt in diesem Zusammenhang ein Grid-Workflowmanagement-System (s.
Kap. 2.3). Die Bereitstellung und Visualisierung der hierfür benötigten Informationen sind
der Kern dieser Arbeit.
1.2. Zielsetzung
Das Ziel der vorliegenden Arbeit ist der Entwurf und die Implementierung einer Res-
sourcen-Datenbank für das Instant-Grid-Projekt. Das zu entwickelnde System hat zur Auf-
gabe, Informationen über im Netz vorhandene Hardware-Ressourcen zu sammeln und
diese in einer im System zugänglichen Datenbank zu speichern. In diesem Zusammen-
1

2. Grundlagen
2.1.4.2. Globus-Toolkit
Das Globus-Toolkit2 [23, 24] der Globus-Alliance3 ist eine Middleware für Grid-Systeme.
Obwohl es sich noch in der Entwicklung befindet, setzen, wie auch das Instant-Grid-
Projekt, fast alle größeren Grid-Projekte auf dieses Toolkit auf. Es wird daher als Referenz-
implementierung der OGSA-Spezifikation in diesem Zusammenhang kurz beschrieben.
Das Globus-Projekt entstand aus einer Zusammenarbeit der University of Chicago und
der University of Southern California unter Beteiligung von IBM und der NASA. Es basiert
unter anderem auf den Erfahrungen anderer, zur Grid-Technologie verwandter Projekte
wie Condor[25], Codine[26], Legion[27], Nimrod[28] und Unicore[29]. Das GT4 bietet alle
notwendigen Komponenten zur Umsetzung von Grid-Systemen. Dies beinhaltet Bereiche
der Sicherheit und der Daten-, Ressourcen- sowie Aufgabenverwaltung. Des Weiteren bie-
tet es Schnittstellen und Bibliotheken für gängige Programmierumgebungen (s. Abb. 2.2).
Abbildung 2.2.: Komponenten des Globus-Toolkit 4 [30]
Security. Dieser Bereich umfasst Maßnahmen zur Authentifikation und Autorisierung
2http://www.globus.org/toolkit
3http://www.globus.org/alliance
8

2. Grundlagen
von Benutzern und Ressourcen. Die Kommunikation zwischen den Beteiligten wird abge-
sichert, und Funktionen zur Verwaltung von Benutzer- und Gruppenrechten werden zur
Verfügung gestellt.
DataManagement.Module in diesemAbschnitt ermöglichen es, verteilte Daten imGrid
zu lokalisieren (RLS), zu verschieben (GridFTP, RFT, DRS) und zu verwalten (OGSA-DAI).
Execution Management. Die Werkzeuge zur Ausführungsverwaltung befassen sich mit
der Initialisierung, Beobachtung, Planung und Koordination von verteilten Aufgaben. Von
diesem Service (GRAM) machen die Scheduling-Mechanismen vom FIRST (s. Kap. 2.3) in-
tensiven Gebrauch.
Information Services. Der Informationsdienst (MDS4) und die zusammenhängenden
Komponenten dienen der Überwachung und der Identifikation von Ressourcen undDiens-
ten imGrid. Der Dienst wird als Informationsquelle vom zu entwickelnden System genutzt
(s. Kap. 4).
Common Runtime. Die allgemeine Laufzeitumgebung dient der plattformunabhängi-
gen Implementierung der oben genannten Dienste. Es werden Bibliotheken bereitgestellt,
die die Erstellung von Abstraktionsschichten vereinfachen und die Umsetzung von Funk-
tionalitäten auf Basis von Web-Services (WSRF ) bequem ermöglichen.
Die Installation und Konfiguration des GT4 erfordert aufgrund seiner Komplexität ein ho-
hes Maß an Fachkenntnis und einen deutlichen Zeitaufwand. Eine detaillierte Beschrei-
bung des Vorgangs findet sich unter anderem in [31, 32]. Einen einfachen Weg zur De-
monstration des Toolkits schlägt das Instant-Grid-Projekt ein.
2.2. Instant-Grid
2.2.1. Einleitung
Das Instant-Grid-Projekt der GWDG (nicht zu verwechseln mit [33]) ist ein Partnerpro-
jekt der D-Grid-Initiative4 und wird vom Bundesministerium für Bildung und Forschung
finanziert. Die Entwicklung erfolgt durch die Gesellschaft für wissenschaftliche Datenver-
arbeitung Göttingen. Unterstützt wird diese durch die Partner ed-media5, die FernUniver-
4http://www.d-grid.de
5http://ed-media.org
9

2. Grundlagen
werden (s. [35]).
D-GRDL. Die D-Grid Resource Description Language ist eine XML-Beschreibung von
Ressourcen innerhalb eines Grids. Ziel der Spezifikation ist eine gemeinsame Sprache zu
definieren, die es erlaubt Ressourcen unterschiedlicher Grid-Infrastrukturen mit einem
einzigen Formalismus zu beschreiben (s. Anhang B.5).
XML DB. Die XML-Datenbank dient als Container und Austauschmedium für die Be-
schreibungen der im Grid vorhandenen Ressourcen und der formulierten Prozesse.
Application Portlet. Das Portlet der jeweiligen Anwendung dient dem Benutzer als
Schnittstelle zur Applikation und generiert die notwendige Beschreibung der Prozessab-
läufe. Im Rahmen des Instant-Grids werden dies voraussichtlich Pov-Ray und ERAMAS16
sein.
GWUI. Das Grid Workflow User Interface unterstützt den Benutzer bei der Auswahl
von Diensten und der Erstellung komplexer Workflows für Grid-Anwendungen. Vorhan-
dene Prozessabläufe können visualisiert und komfortabel bearbeitet werden.
GWES. Der Grid Workflow Execution Service beinhaltet verschiedene Komponenten
unter anderem zur Analyse und Verifikation von Prozessabläufen und dient der Ausfüh-
rung von Programmen im Grid (s. [36]).
ResourceMatcher.Der ResourceMatcher sucht auf Grundlage der in der GWorkflowDL
angegebenen Eigenschaften passende Ressourcen zur Ausführung einer Anwendung aus.
Die jeweiligen Ressourcen, die zu überprüfen sind, wurden zuvor in der D-GRDL beschrie-
ben und befinden sich in der XML-Datenbank.
Scheduler. Der Scheduler optimiert auf Grundlage der Auslastungsinformationen aus
den D-GRDL-Beschreibungen der passenden Ressourcen und weiteren Angaben aus der
zugehörigen GWorkflowDL die Auswahl der Ressourcen für die Ausführung von Grid-
Anwendungen.
Der oben beschriebe Ansatz geht von bereits existierenden Beschreibungen der im Grid
vorhandenen Ressourcen aus. Diesem Teilaspekt widmet sich die vorliegende Arbeit und
ergänzt die vorhandene Architektur um weitere Komponenten (s. Abb. 2.4(b)). Eine detail-
lierte Beschreibung des Systems, im Weiteren als Grid Resource Database (GRDB) bezeich-
net, findet sich in den folgenden Kapiteln.
16http://www.eramas.de
14

3. Anforderungsanalyse
3.1. Einleitung
Gründe für das Scheitern von Software-Projekten gibt es viele. Empirische Untersuchun-
gen (siehe u.a. [37, 9]) haben ergeben, dass insbesondere unklare Anforderungen und die
fehlende Einbeziehung der Endnutzer zu den mit Abstand häufigsten Fehlern zählen. Die
Analyse, als Phase des Software-Entwicklungsprozesses, ist daher einer der wichtigsten
Schritte zum fertigen Produkt. Auch sorgen Ungenauigkeiten in den frühen Phasen des
Entwicklungsprozesses zu einem Summationseffekt, in dem sich Fehler fortpflanzen und
potenzieren. Die Dokumentation der Anforderungen dient daher allen an der Systement-
wicklung Beteiligten als Kommunikations-, Diskussions- und Argumentationsgrundlage.
Ihre Aufgabe ist es, das gemeinsame Verständnis und Wissen der Teammitglieder wider-
zuspiegeln (vgl. [10, 6]). Die Aufnahme und Erfassung der Anforderungen sollte vor allem
vollständig, verständlich und identifizierbar sein. Insbesondere die eindeutige Nummerie-
rung der Anforderungen und deren Qualifizierung helfen bei der Querreferenzierung und
der späteren Verifizierung und Abnahme des Produktes. Die Nummerierung erfolgt dabei
zunächst in Zehnerschritten, um ggf. zusätzliche Anforderungen nachtragen zu können.
Die Grundlagen der im Folgenden beschriebenenAnforderungen und Ziele ergaben sich
aus Interviews mit den jeweiligen Fachexperten, Anforderungsverantwortlichen und Sys-
tembetroffenen. Durch die Wahl eines inkrementellen Entwicklungsprozesses wurden Er-
weiterungen der Anforderungen im Laufe des Projektes unterstützt und auf Änderungen
konnte flexibel eingegangen werden.
3.2. Beschreibung der Systemidee und Zielsetzung
Die Formulierung der Systemidee ist das Ergebnis von Diskussionen innerhalb der Ar-
beitsgruppe für Anwendungssysteme der GWDG. Diese wurde im Laufe von Gesprächen
mit Mitgliedern der Projektgruppe des FIRST ergänzt.
Das zu entwickelnde System soll die existierende Instant-Grid-Infrastruktur dahingehend
erweitern, dass eine einheitliche Ressourcen-Datenbank zur Verfügung steht. Diese soll
automatisch mit Daten über die im Grid vorhandenen Hardware-Ressourcen mittels exis-
tierender Information-Provider aktualisiert werden. Die gesammelten Informationen sol-
len in ein einheitliches Datenformat überführt und insbesondere eine Anbindung an das
15

3. Anforderungsanalyse
FIRST−Entwickler
Portal−Anwender
IG−Entwickler
Ressourcen−Datenbank
Datenbank nutzen
ud: Stakeholder
Abbildung 3.1.: UML-Anwendungsfalldiagramm: ermittelte Stakeholder
Tabelle 3.1.: Projekt-Ansprechpartner
Verantwortliche Ansprechpartner
IG-Projektleiter Herr Dr. Ulrich Schwardmann von der GWDG
K-Wf-Grid-Projektleiter Herr Andreas Hoheisel vom Fraunhofer FIRST
Fachexperten Ansprechpartner
IG-Entwickler Herr Dr. Christian Boehme von der GWDG
FIRST-Entwickler Herr Andreas Hoheisel vom Fraunhofer FIRST
FIRST-
Beschreibungsentwickler
Herr Dr. Armin Wolf vom Fraunhofer FIRST
Systembetroffene Ansprechpartner
Portal-Anwender Herr Dr. Christian Boehme von der GWDG
17

3. Anforderungsanalyse
3.4.1. Ziele und Interessen
Die Dokumentation der Interessen bzw. der gewünschten Ziele der Anforderungsbeitra-
genden findet sich in den Tabellen 3.2, 3.3 und 3.4). Die Aussagen werden in diesem Zu-
sammenhang noch nicht bewertet, sondern lediglich schriftlich festgehalten. Die Formu-
lierungen dienen jedoch der Generierung einer Übersicht aller Anwendungsfälle, die das
Verhalten des Systems nach außenwiedergeben. Die detaillierten Beschreibungen aller An-
forderungen sind in Kapitel 3.5 aufgeführt.
Tabelle 3.2.: Interessen der Anforderungsbeitragenden (IG-Entwickler)
Kennzeichnung Verbindlichkeit Beschreibung
/Z10/ Pflicht Nahtlose Integration des Systems in die vor-
handene Struktur.
/Z11/ Pflicht Keinerlei Benutzerinteraktionen für die Aktua-
lisierung der Ressourcen-Informationen.
/Z20/ Pflicht Bereitstellung der Ressourcen-Informationen
für andere Anwendungen, wie etwa den Grid-
Portlets.
Tabelle 3.3.: Interessen der Anforderungsbeitragenden (FIRST-Entwickler)
Kennzeichnung Verbindlichkeit Beschreibung
/Z30/ Pflicht Erhebung von dynamischen Informationen
über Hardware-Ressourcen (insbes. Auslas-
tungsdaten).
/Z31/ Pflicht Bereitstellung einer Schnittstelle zur Kontrolle
der Informationsbeschaffung.
/Z32/ Pflicht Erhebung von Informationen über Software-
Ressourcen.
/Z40/ Pflicht Konformität der Datenbank zu XPath[38],
XQuery[39] und XUpdate[40].
/Z50/ Pflicht Datenaustausch mittels der vom FIRST spezifi-
zierten D-GRDL (siehe B.5).
/Z60/ Optional Verwendung der eXist XML-Datenbank.
18

3. Anforderungsanalyse
Tabelle 3.4.: Interessen der Anforderungsbeitragenden (Portal-Benutzer)
Kennzeichnung Verbindlichkeit Beschreibung
/Z70/ Pflicht Einfache Übersicht der existierenden
Hardware-Ressourcen.
/Z80/ Pflicht Anbindung an Workflow-Editor des FIRST.
/Z90/ Optional Graphische Darstellung der Auslastungsinfor-
mationen.
/Z100/ Pflicht Bereitstellung einer graphischen Schnittstelle
zur Kontrolle der Informationsbeschaffung.
3.4.2. Essenzielle Anwendungsfälle
Auf Grundlage der vorliegenden Informationen über die Ziele der Anforderungsbeitra-
genden (s. Kap. 3.4.1) können nun essenzielle Anwendungsfälle abgeleitet werden. Diese
beschreiben das zukünftige System vereinfacht, sehr abstrakt und grundsätzlich unabhän-
gig von konkreten Implementierungen. Die in der Abbildung 3.2 dargestellten Anwen-
dungsfälle beziehen sich daher weniger auf konkrete Rahmenbedingungen und technolo-
gische Gegebenheiten. Vielmehr konzentrieren sie sich auf die eigentliche fachliche Inten-
tion und werden im weiteren Verlauf konkretisiert. Zur späteren Referenzierung sind die
Anwendungsfälle mit einer eindeutigen Bezeichnung (z.B. "/U10/" ) gekennzeichnet.
<< actor >>
FIRST−Editor
<< actor >>
FIRST−Scheduler
<< actor >>
Grid Portlet
<< actor >>
Zeitsteuerung
<< actor >>
Information Provider
Ressourcen−Datenbank
Ressourceninformationenauswerten (/U40/)
Ressourceninformationenexportieren (/U30/)
Ressourceninformations−aktualisierung steuern (/U20/)
Ressourceninformationendarstellen (/U10/)
ud: Grundlegende Anwendungsfälle
Portal−Anwender
Abbildung 3.2.: UML-Anwendungsfalldiagramm: grundlegende Anwendungsfälle
19

3. Anforderungsanalyse
3.5. Beschreibung der Anforderungen
Die in Abbildung 3.2 dargestellten essenziellen Anwendungsfälle und in Kapitel 3.4.1 be-
schriebenen Ziele bieten einen guten Rahmen und Einstiegspunkt zur Analyse und Be-
schreibung der Anforderungen an das zu entwickelnde System. Methodische Richtlinien
und standardisierte Verfahren zur systematischen Anforderungsbeschreibung gibt es viele
(vgl. [41, 42, 43, 44]). Im Folgenden werden die Vorgaben aus dem Lehrbuch von Bernd
Oestereich[6] verwendet und durch weitere Angaben[10, 8, 45] ergänzt.
3.5.1. Probleme
Probleme des bestehenden Systems, die zu der Entwicklung des neuen Systems geführt
haben, sind in Tabelle 3.5 aufgeführt. Grundlage der formulierten Defizite sind die Er-
fahrungswerte der IG-Entwickler. Die Priorisierung, in wie fern das neue System diese
Probleme beheben soll, findet sich in der Angabe der Verbindlichkeit.
Tabelle 3.5.: Anforderungsbeschreibung: vorhandenen Probleme
Nr. Verbindlichkeit Beschreibung
/P10/ Pflicht Die Darstellung von Ressourcen-
Informationen ist z.Z. nicht einheit-
lich in das Portal integriert.
/P20/ Pflicht Eine Anbindung an Entwicklungen
des FIRST fehlt.
/P30/ Pflicht Es besteht z.Z. keine sinnvolle Ver-
wendung des MDS4.
/P40/ Optional Die Optionen zur Aktualisierung
von Ressourcen-Informationen
können derzeit nicht über eine
Webschnittstelle gesteuert werden.
/P50/ Optional Die derzeitige Umsetzung der
Aktualisierung von Ressourcen-
Informationen für die Grid-Portlets
könnte überarbeitet werden.
3.5.2. Funktionale Anforderungen
Die in Kapitel 3.4.1 beschriebenen Interessen ziehen funktionale Anforderungen an das
System nach sich. Diese beschreiben grundsätzlich die Interaktion eines technischen Sys-
tems mit seiner Umgebung. Die entsprechenden Anforderungen werden in Tabelle 3.6 auf-
gelistet, eindeutig gekennzeichnet, priorisiert und dem jeweiligen Ziel zugeordnet.
20

3. Anforderungsanalyse
/F110/ Optional /Z90/ Graphische Darstellung von
Auslastungsinformationen über
ein Zeitintervall innerhalb eines
Portlets.
3.5.3. Produktdaten
Zur Realisierung der zuvor herausgearbeiteten, funktionalenAnforderungen (s. Kap. 3.5.2)
ist die Speicherung und Verwaltung von zugehörigen Daten notwendig. Die langfristig zu
speichernden Informationen zur Erfüllung der funktionalen Anforderungenwerden in der
nachfolgenden Tabelle festgehalten.
Tabelle 3.7.: Anforderungsbeschreibung: zu speichernden Daten
Nr. Verbindlichkeit Funktion Beschreibung
/D10/ Pflicht /F21/ Name der Hardware-Ressource.
/D20/ Pflicht /F21/ IP der Hardware-Ressource.
/D30/ Pflicht /F50/ Freier Hauptspeicher der Hard-
ware-Ressource.
/D40/ Pflicht /F50/ CPU-Durchschnittsbelastung der
Hardware-Ressource.
/D50/ Pflicht /F51/ Installierte Software auf der Hard-
ware-Ressource.
/D60/ Abgrenzung /F51/ Installierte Software nicht dyna-
misch ermitteln.
/D70/ Optional /F50/ Anzahl der CPUs der Hardware-
Ressource.
/D80/ Optional /F50/ CPU-Takt der Hardware-
Ressource.
/D90/ Optional /F50/ Größe des Hauptspeichers der
Hardware-Ressource.
/D100/ Optional /F21/ Rechnerarchitektur der Hardware-
Ressource.
3.5.4. Randbedingungen
Als Randbedingungen werden Aspekte der Anforderungsanalyse bezeichnet, die nicht
funktionaler Natur sind. Sie vervollständigen die Spezifikation, wirken unterstützend auf
die konfliktfreie Kommunikation mit den Anforderungsbeitragenden und sind hilfreich
beim Entwurfsprozess des Softwaresystems. In den folgendenUnterkapitelnwerden nicht-
22

3. Anforderungsanalyse
3.6. Konkretisierung der Anwendungsfälle
Auf Basis der herausgearbeiteten Anforderungen an das System aus der Analyse in Ka-
pitel 3.5 gilt es nun, die bereits in Abbildung 3.2 skizzierten Anwendungsfälle weiter zu
konkretisieren und zu beschreiben. Aufbauend auf der erweiterten Abbildung der Anwen-
dungsfälle (s. Abb. 3.3) werden diese im Folgenden anhand einer semi-formalen Vorlage
(angelehnt an [46]) beschrieben und das zugehörige Ablaufmodell angegeben. Das jeweili-
ge Ablaufmodell dient zum einen der Beschreibung der gegebenen Vorgänge des Anwen-
dungsfalles, zum anderen werden die Aktionspfade der Modelle zur Testfallgenerierung
verwendet. Dies dient der Validierung der Anwendung gegenüber der Anforderungsspe-
zifikation (s. Kap. 5.3).
24

3. Anforderungsanalyse
Ressourcen−Datenbank
Ressourceninformationenhinzugügen (/U41/)
Ressourceninformationenaktualisieren (/U43/)
Ressourceninformationenentfernen (/U42/)
Resourceninformationenauslesen (/U31/) Resourceninformationenkonvertieren (/U32/)
Aktualisierungstarten (/U22/)Aktualisierungs−interval setzen (/U21/)
Information Providerauswählen (/U23/)
Ressourceninformations−
aktualisierung steuern (/U20/)
Ressourceninformationen
darstellen (/U10/)
Ressourceninformationen
auswerten (/U40/)
Ressourcedarstellen (/U12/)Übersichtdarstellen (/U11/)
<< invoke >>
Ressourceninformationen
exportieren (/U30/)
ud: Vollständiges Anwendungsfalldiagramm
Portal−Anwender
<< actor >>
FIRST−Editor
<< actor >>
FIRST−Scheduler
<< actor >>
Grid Portlet
<< actor >>
Zeitsteuerung
<< actor >>
Information Provider
Abbildung 3.3.: UML-Anwendungsfalldiagramm: Übersicht des zu entwickelnden Systems
25

3. Anforderungsanalyse
3.6.1. Anwendungsfall U10 (Ressourceninformationen darstellen)
3.6.1.1. Aktivitätsdiagramm

2. DB auslesen (/U11/)
Ressourceausgewählt


Fehler darstellenR.informationen darstellen
1. Mit DB verbinden

ad: U10 (R.informationen darstellen)
1.1 [OK]
3.2 [Fehler]
1.2 [Fehler]
[Ja][Nein]
2.1 [OK] 3.1 [OK]
2.2 {Fehler]3. R.information auslesen (/U12/)
Abbildung 3.4.: UML-Aktivitätsdiagramm: Anwendungsfall U10
3.6.1.2. Konkretisierung U11
Tabelle 3.10.: Anwendungsfall U10: Konkretisierung U11
Name: Übersicht darstellen
Kurzbeschreibung Es werden statische und dynamische Informa-
tionen über Hardware-Ressourcen dargestellt.
Akteure Portal-Nutzer.
Auslöser Der Nutzer öffnet eine entsprechende Seite des
Portals.
Eingehende Informationen
Ergebnisse Darstellung der Ressourcen-Information.
Ablauf 1. Nutzer öffnet entsprechende Portalseite.
2. Übersichtsseite wird dargestellt.
26

3. Anforderungsanalyse
3.6.1.3. Konkretisierung U12
Tabelle 3.11.: Anwendungsfall U10: Konkretisierung U12
Name: Ressource darstellen
Kurzbeschreibung Es werden statische und dynamische Infor-
mationen über eine spezifische Hardware-
Ressource dargestellt.
Akteure Portal-Nutzer.
Auslöser Der Nutzer öffnet eine entsprechende Seite des
Portals.
Eingehende Informationen Eindeutige Kennung der Ressource.
Ergebnisse Darstellung der Ressourcen-Information.
Ablauf 1. Nutzer öffnet entsprechende Portalseite.
2. Auswahl einer Ressource.
3. Auswahl bestätigen.
3.6.2. Anwendungsfall U20 (Ressourceninformationsaktualisierung steuern)
3.6.2.1. Aktivitätsdiagramm
Up
dat
e−S
ign
al



2. U
pda
te s
tart
en
(/U
22/
)

Inte
rva
l ni
cht
ge
set
zt

Ste
uer
ung
vo
llstä
ndi
g
1. M
it S
teu
eru
ng
ver
bin
den

ad:
U2
0 (R
.inf
orm
.ak
tua
lisie
run
g s
teu
ern
)
1.1
[O
K]
4.2
[Fe
hle
r]1.2
[Fe
hle
r]
[Up
dat
e s
tart
en]
[IP
aus
wä
hle
n]
[Int
erv
al s
etz
en]
2.2
[Fe
hle
r]
3.2
[Fe
hle
r]
3.1
[O
K]
2.1
[O
K]
2.1
[O
K]
4. I
nte
rva
l se
tze
n (/
U2
1/)
3. I
P a
usw
ähl
en
(/U
23/
)
Abbildung 3.5.: UML-Aktivitätsdiagramm: Anwendungsfall U20
27

3. Anforderungsanalyse
3.6.2.2. Konkretisierung U21
Tabelle 3.12.: Anwendungsfall U20: Konkretisierung U21
Name: Aktualisierungsintervall setzen
Kurzbeschreibung Änderung des Intervalls in dem die Daten der
Information-Provider ausgewertet werden.
Akteure Portal-Nutzer / Komponente des FIRST.
Auslöser Nutzer klickt auf ein entsprechendes Formular
/ Komponente ruft Funktion auf.
Eingehende Informationen Das neue Intervall in Sekunden.
Ergebnisse Setzen eines neuen Aktualisierungsintervalls.
Ablauf 1. Verbindungmit der Daemon-Steuerung (Por-
tal / Funktion).
2. Auswahl eines neuen Intervalls.
3. Aufruf des Schnittstellenelements (Portal /
Funktion).
3.6.2.3. Konkretisierung U22
Tabelle 3.13.: Anwendungsfall U20: Konkretisierung U22
Name: Aktualisierung starten
Kurzbeschreibung Die Daten des Information-Providers sollen so-
fort ausgewertet werden.
Akteure Portal-Nutzer / Komponente des FIRST.
Auslöser Nutzer klickt auf ein entsprechendes Formular
/ Komponente ruft Funktion auf.
Eingehende Informationen
Ergebnisse Einleitung der Aktualisierung der Daten und
Versenden eines Update-Signals an registrierte
Komponenten.
Ablauf 1. Verbindungmit der Daemon-Steuerung (Por-
tal / Funktion).
2. Aufruf des Schnittstellenelements (Portal /
Funktion).
28

3. Anforderungsanalyse
4. Löschen der Informationen aus der Daten-
bank.
3.6.4.4. Konkretisierung U43
Tabelle 3.19.: Anwendungsfall U40: Konkretisierung U43
Name: Ressourceninformationen aktualisieren
Kurzbeschreibung Aktualisierung der dynamischen Daten über
eine Hardware-Ressource.
Akteure Information-Provider.
Auslöser Zeitsignal.
Eingehende Informationen Eindeutige Bezeichnung der Hardware-
Ressource.
Ergebnisse Aktualisierung der Informationen der
Hardware-Ressource in der Datenbank.
Ablauf 1. Verbindung zum Information-Provider.
2. Konvertierung und Auswertung der Daten
des Information-Providers.
3. Verbindung zur Datenbank.
4. Aktualisierung der Informationen aus der
Datenbank.
3.7. Beschreibung der Systemschnittstelle
Nach der Analyse und Beschreibung der Anwendungsfälle können im nächsten Schritt
nun die Strukturelemente, die an der äußeren Systemgrenze liegen, identifiziert werden.
Dabei gilt es, die involvierten Schnittstellenelemente zu finden, die für Interaktionen des
zu entwickelnden Systems mit der Umgebung notwendig sind. In Tabelle 3.20 sind die
entsprechenden Schnittstellen für die herausgearbeiteten Anwendungsfälle aufgeführt.
Tabelle 3.20.: Zuordnung der involvierten Schnittstellen
Anwendungsfallschritt/-
aktivität
Involvierte Schnittstelle
/U10/ (Ressourceninformatio-
nen darstellen)
Dialog/Interface: Ressourcendarstellung I10
/U20/ (Ressourceninformati-
onsaktualisierung steuern)
Dialog/Interface: Steuerung I20
/U30/ (Ressourceninformatio-
nen exportieren)
Interface: Datenexport I30
33

3. Anforderungsanalyse
/U40/ (Ressourceninformatio-
nen auswerten)
Interface: Information-Provider-Treiber I40
3.7.1. Dialog/Interface I10 (Ressourcendarstellung)
Tabelle 3.21.: Dialog/Interface: Ressourcendarstellung I10
Name Ressourcendarstellung
Kurzbeschreibung Mit diesem Dialog kann der Benutzer eine Res-
source zur Darstellung auswählen.
Verwendung Zur Auswahl bei der Darstellung aller vorhande-
nen Ressourcen und als Verknüpfung über den
Fraunhofer Workfloweditor.
Eingabefelder Eindeutige Bezeichnung der Ressource (z.B. über
die URL).
Anzeigefelder Eindeutige Bezeichnungen aller Ressourcen.
Verzweigungsmöglichkeit Zurück zur Übersicht aller Ressourcen.
Aktionen Reduzierung der Anzeige auf eine Ressource.
3.7.2. Dialog/Interface I20 (Steuerung)
Tabelle 3.22.: Dialog/Interface: Steuerung I20
Name Steuerung
Kurzbeschreibung Steuerung der Datenverwertung.
Verwendung Als Einstellmöglichkeit für jeden Portal-Benutzer
und als Interface für Komponenten des FIRST.
Eingabefelder Aktualisierungsintervall in Sekunden, Name des
zu verwendenden Information-Providers und
Aktualisierungsfunktion
Anzeigefelder Derzeitiges Aktualisierungsintervall, Name des
Information-Providers und eine Aktualisierungs-
funktion.
Verzweigungsmöglichkeit Keine.
Aktionen Aktualisierung der Daten und Änderung des Ak-
tualisierungsintervalls und des Information Pro-
viders.
34

3. Anforderungsanalyse
3.7.3. Interface I30 (Datenexport)
Tabelle 3.23.: Interface: Datenexport I30
Name Datenexport
Kurzbeschreibung Export der in der Datenbank vorhandenen Daten.
Betroffene Systeme Komponente zur Anbindung der Grid-Portlets
und Komponenten des FIRST.
Eingabedaten Registrierungsinformationen zur Benachrichti-
gung.
Ausgabedaten Update-Signal und Datenbankinhalte.
3.7.4. Interface: I40 (Information-Provider-Treiber)
Tabelle 3.24.: Interface: Information-Provider-Treiber I40
Name Information-Provider-Treiber
Kurzbeschreibung Komponente zur Umwandlung und Strukturie-
rung von Daten eines Information-Providers.
Betroffene Systeme Information-Provider und eine Zeitsteuerung.
Eingabedaten Update-Signal und Daten des Information Provi-
ders.
Ausgabedaten Strukturierte Daten des Information-Providers.
35

4. Design
dung benötigte Fremdsysteme sind hierbei dunkel hinterlegt. Die jeweiligen Bausteine
greifen ausschließlich auf festgelegte Schnittstellen anderer Komponenten zu und sind
getrennt voneinander zu betrachten. Die Kommunikation erfolgt in der Regel über Da-
tentransferobjekte, die die notwendigen Informationen einheitlich und zur vereinfachten
Handhabung kapseln. Die Aufgaben der jeweiligen Schicht und ihrer Komponenten wer-
den im Folgenden kurz erläutert und anschließend in Form von Klassen- und Schnittstel-
lenbeschreibungen weiter detailliert.
4.3. Komponenten
4.3.1. Präsentationsschicht
Die Komponenten der Präsentationsschicht haben zur Aufgabe, dem Benutzer eine gra-
phische Benutzeroberfläche zur Verfügung zu stellen. Dies beinhaltet unter anderem die
Erstellung einer Übersicht von Hardware-Ressourcen (/Z70/) und die Steuerung der Infor-
mationsbeschaffung (/P50 /Z100/).
Portalsystem. Technische Grundlage für die Realisierung der graphischen Oberfläche ist
der Einsatz des Apache Tomcat Servers und das GridSphere Portal-Systems (/A20 /A21
/F90/). Bei der Umsetzung des Systems wird jedoch ausschließlich auf die jeweiligen stan-
dardisierten Schnittstellen JSR-154[50] und JSR-168[51] zugegriffen. Dies ermöglicht den
einfachen Austausch der eingesetzten Portallösung durch alternative Systeme.
GRDB-Portlet / GRDB-Servlet. Die Integration in das vorhandene Portalsystem (/P10 /Z10/)
erfolgt durch die Erweiterung der jeweiligen Servlet- und Portlet-Schnittstellen. Für die
Darstellung von erfassten Informationen (/F21 /F80 /F90 /I10/) ist der lesende Zugriff auf
die gespeicherten Daten über eine definierte Schnittstelle notwendig. Die Steuerung der
Informationsaktualisierung (/P40 /Z100 /F30 /I20/) bedingt den Zugriff auf Schnittstellen
der Kontrollschicht.
4.3.2. Kontrollschicht.
Die Kontrollschicht stellt den organisatorischen Kern der Anwendung dar. Eingehende
Benutzereingaben und Informationen der Information-Provider werden ausgewertet und
der notwendige Kontrollfluss gesteuert.
GRDB-Daemon. Der GRDB-Daemon steuert den Datenfluss des Systems und hat eine
Vielzahl von Aufgaben. Insbesondere werden erhobene Daten der Information-Provider
ausgelesen und eine Überführung der Informationen in die Datenbank veranlasst. Des
38

4. Design
Ada
pter
−Pa
ttern
Obs
erve
r−Pa
ttern
<<
inter
face
>>
Grd
bD
aem
onL
iste
ner
+up
date
():vo
id
Ga
ngl
iaC
onn
ect
or
<<
inter
face
>>
Grd
bD
aem
onI
nte
rfac
e
+se
tInte
rval
(inte
rval
:int)
:void
+ge
tInte
rval
():in
t
+ge
tDriv
er(
):Str
ing
+se
tDriv
er(d
river
:Stri
ng)
:void
+up
date
():vo
id
+qu
ery
(que
ry:S
tring
):Do
cum
ent
+ad
dLis
tene
r(lis
tene
r:G
rdbD
aem
onL
isten
er)
:void
+re
mov
eLis
tene
r(li
sten
er:G
rdbD
aem
onL
isten
er)
:void
+no
tifyL
isten
ers
():vo
id
Ab
stra
ctG
rdb
Co
nne
cto
r
+ge
tGrd
lDoc
ume
nt(
):Do
cum
ent
#se
tGrd
lDoc
ume
nt(
docu
men
t:D
ocu
me
nt):
void
+u
pda
te(
):vo
id
Grd
bD
aem
on
cd:
Pak
et−Ü
bers
icht:
dae
mon
iPro
vide
r
−
<<im
plem
ents
>>
liste
ners
−
subj
ect
obse
rver
ada
pter
ada
pter
targ
et
clien
t
Md
sCo
nne
cto
r
Abbildung 4.4.: UML-Paketdiagramm: org.instantgrid.grdb.daemon
4.4.3. Paket: org.instantgrid.grdb.portlet
Die Klassen für die graphische Oberflächengestaltung (/I10 /I20/) finden sich im Paket
org.instantgrid.grdb.portlet (s. Abb. 4.5). Zur einfachen Trennung von XHTML-Ober-
flächenbeschreibungen und Java-Quelltexten wird die Klasse Template genutzt. Diese öff-
net entsprechende GUI-Dateien und ersetzt gegebene Zeichenketten durch Ergebnisse der
Klasse GrdbPortlet. Diese Klasse erweitert das GenericPortlet und hat damit Zugriff
auf alle Daten und Funktionen, die für die Benutzerinteraktion notwendig sind.
4.4.4. Paket: org.instantgrid.grdb.servlet
Zur Generierung von graphischen Auswertungen von Ressourcen-Informationen wird in
dem Paket org.instantgrid.grdb.servlet (s. Abb. 4.6) mit Hilfe der Klasse GrdbServlet
ein entsprechender Servlet-Service zur Verfügung gestellt. Diese Klasse wird in der graphi-
schenOberfläche des Portlets als Graphik verknüpft und erhält Daten zumNamen der aus-
gewählten Ressource und der darzustellenden Informationen. Die zuständige Werkzeug-
Klasse zur Generierung der Abbildungen ist die GridResourceChartFactory.
43

4. Design
GenericPortlet
Template
<< create >> + Template ():Template
<< create >> + Template (templateFile :String ):Template
+ open (templateFile :String ):void
+ toString ():String
+ set(tagString :String ,replaceString :String ):void
GrdbPortlet
<< create >> + DaemonController ():void
+ doView (request :RenderRequest ,response :RenderResponse ):void
+ init (config :PortletConfig ):void
+ processAction (request :ActionRequest ,response :ActionResponse ):void
Paket−Übersicht: portlet
template−
Abbildung 4.5.: UML-Paketdiagramm: org.instantgrid.grdb.portlet
HttpServlet
<< utility >>
GridResourceChartFactory
<< create >> −GridResourceChartFactory ():GridResourceChartFactory+ createFsChart (resource :GridResource ,outputStream :OutputStream ):void+ createMemoryChart (resource :GridResource ,outputStream :OutputStream ):void+ createLoadChart (resource :GridResource ,outputStream :OutputStream ):void
GrdbServlet
+ doGet (req :HttpServletRequest ,res:HttpServletResponse ):void−writeChart (request :HttpServletRequest ,response :HttpServletResponse ):void
cd: Paket−Übersicht: servlet
Abbildung 4.6.: UML-Paketdiagramm: org.instantgrid.grdb.servlet
44

5. Implementierung und Test
5.1. Implementierung
Die erfolgte Implementierung des in Abschnitt 4 entworfenen Systems soll kurz erläu-
tert werden. Dazu wird auf die beiden Hauptkomponenten, das GRDB-Portlet und den
GRDB-Daemon, eingegangen und die Integration in die vorhandene Systemstruktur des
IG beschrieben.
5.1.1. Integration
Die Installation der entwickelten Anwendung erfolgt, wie im IG für Zusatzapplikatio-
nen vorgesehen, über das Einspielen eines Debian-Pakets mit jeweiligen vor- und nach-
geschalteten Installationsskripten (/Z10/F10/F20/). Die Änderungen, die das Paket an der
Verzeichnis- und Dateistruktur der CD-ROM des Instant-Grid-Projektes vornimmt, wer-
den im Weiteren beschrieben. Die Schilderung jeder einzelnen Datei würde den Rahmen
dieser Arbeit jedoch sprengen, daher werden Inhalte weniger relevanter Verzeichnisse aus-
gespart.
Verzeichnis: /etc/
• Datei: ./init.d/grdbd Link zum Startskript „grdbd.init.debian“ (s.u.).
• Datei: ./ig-software.xml D-GRDL-Beispielbeschreibungen von Softwarekomponen-
ten. Diese Datei wird vom GRDB-Daemon eingelesen und der Inhalt regelmäßig in
die Datenbank überführt (/F51/).
Verzeichnis: /usr/local/instant-grid-tomcat5/init
• Datei: ./grdbd-init.sh Link zu der Konfigurationsdatei „grdbd.config“ (s.u.) zur In-
itialisierung der notwendigen Umgebungsvariablen.
Verzeichnis: $CATALINA_HOME/webapps/grdb
• Verzeichnis: ./css Cascading-Stylesheet-Angaben für das Portlet und die Übersichts-
seite.
46

5. Implementierung und Test
Verzeichnis: $CATALINA_HOME/webapps/grdb/shell
• Datei: ./grdbd.config Umgebungsvariablen für Portlet und Daemon.
• Datei: ./grdbd.import-cert.sh Skript zur Unterstützung des Imports der Grid-Zerti-
fikate zum Java-Zertifikatscontainer. Der Import ist notwendig, um auf abgesicherte
WSRF-Dienste wie MDS4 zugreifen zu können. Dies wird im Rahmen des IG jedoch
nicht benötigt.
• Datei: ./grdbd.init.debian.sh GNU/Linux-Init-Skript für Debian Systeme.
• Datei: ./grdbd.init.suse.sh GNU/Linux-Init-Skript für SuSE Systeme.
• Datei: ./grdbd-lokal.sh Skript zur Unterstützung des manuellen Aufrufs des GRDB-
Daemons.
• Datei: ./grdbd.sh Start-Skript des GRDB-Daemons.
• Datei: ./queryDpkg.sh Skript zur Konvertierung von Debian-Paketmanagementin-
formationen in eine XML-Darstellung.Wird im Rahmen des IG jedoch nicht benötigt.
5.1.2. Daemon
Der GRDB-Daemon ist ein Kernstück des entwickelten Systems. Er wird während des
Startvorgangs des IG initialisiert und geht imHintergrund seinen Tätigkeiten nach (/Z11/).
Die Hauptaufgabe des Daemons ist die Abfrage eines Information-Providers zu Daten von
im Grid vorhandenen Hardware-Ressourcen und die Speicherung dieser Informationen in
der Datenbank (s. Kap. 4).
Neben Programmierschnittstellen zur Steuerung und Nutzung des Dienstes existiert ei-
ne Kommandozeilenschnittstelle die es dem Anwender erlaubt, das Verhalten des Dae-
mons beim Start zu beeinflussen (s. Listing 5.1). Die notwendigen Skripte zur Ausführung
der Komponente finden sich im Verzeichnis $CATALINA_HOME / webapps / grdb /
shell.
knoppix@server:shell > ./grdbd -lokal.sh --help
usage: class org.instantgrid.grdb.daemon.GrdbDaemon
-d,--driver <arg > The driver for the Information -Provider
-h,--help This help
-i,--interval <arg > The interval in seconds for polling the
Information -Provider
-n,--no -loop Runs the daemon only once (i.e. for
debugging and testing)
-p,--port <arg > The listener port for the daemon
Listing 5.1: Kommandozeilenschnittstelle des Daemons
48

5. Implementierung und Test
http :// server :8080/ gridsphere/gridsphere /?cid=grdbtab&resourceID=RESOURCE_ID
Listing 5.2: Auswahl einer Ressource über die URL
5.1.3.3. Visualisierung der Auslastungsinformationen
Um einen schnellen und intuitiv begreifbaren Überblick über den Status der Hardware-
Ressourcen im Grid zu erhalten (/P10 /Z90 /F90/), werden auf der rechten Seite der Ober-
fläche ausgewählte Auslastungsinformationen graphisch aufbereitet dargestellt (s. Abb.
5.2). Grundlage dieser Daten ist entweder die gebildete Summe bzw. der Durchschnitt aller
Ressourcen-Informationen oder die Daten einer zuvor ausgewähltenHardware-Ressource.
(a) CPU-Auslastung (b) Hautspeicher-Auslastung (c) Festplatten-Auslastung
Abbildung 5.2.: Screenshots: Graphische Auswertung der Auslastungsinformationen
5.1.3.4. Steuerung des GRDB-Daemons
Neben der Anzeige von Ressourcen-Informationen kann über die graphische Oberfläche
auch der GRDB-Daemon gesteuert werden (s. Abb. 5.3). In dem Feld „Daemon control-
ler“ wird der Zugriffspfad auf den GRDB-Daemon angegeben und aktuelle Daten können
angefordert werden. DesWeiteren ist es möglich, das Intervall für die automatische Aktua-
lisierung der Ressourcen-Informationen anzugeben. Als dritter Punkt wird eine Auswahl
verschiedener Information-Provider (derzeit Ganglia und MDS4) gegeben zu denen im
laufenden Betrieb gewechselt werden kann (/P40 /I20 /P40 /F31/).
Abbildung 5.3.: Screenshot: Daemon-Controller im Portlet
50

5. Implementierung und Test
5.1.3.5. Auflistung der Details
Die Darstellung der Informationen basiert auf Daten, die in der Datenbank in Form der
D-GRDL gespeichert sind. Eine der wichtigsten Eigenschaften der verwendeten Beschrei-
bungssprache ist ihre Erweiterbarkeit. Auf der Oberfläche können, auch aufgrund der
Übersichtlichkeit, daher nicht alle Informationen graphisch wiedergegeben werden. Das
Feld „XML result“ stellt dem interessierten Benutzer daher die verwendeten Eingabedaten
für die Oberflächengenerierung zur Verfügung (s. Abb. 5.4). Wurde zuvor eine Hardware-
Ressource zur Darstellung ausgewählt, so werden lediglich Informationen über diese auf-
gelistet (/I30/F80/).
Abbildung 5.4.: Screenshot: XML-Details im Portlet
5.2. Statische Testverfahren
Werkzeuggestützte Quelltextanalysen können sehr erfolgreich zur Qualitätssteigerung von
Software-Projekten eingesetzt werden. Das Ziel der Untersuchungen ist die Ermittlung
von potentiellen Fehlern und Verstößen gegen vorhandene Spezifikationen. Mängel und
Abweichungen sollen hierbei so früh wie möglich erkannt werden, noch bevor sie im wei-
teren Verlauf der Softwareentwicklung zum Tragen kommen (vgl. [52, 53]). Im Rahmen
dieser Arbeit kamen daher verschiedene Analysewerkzeuge zum Einsatz, um die Qualität
des zu entwickelnden Systems gewährleisten zu können.
5.2.1. Kodierungsrichtlinien
Einleitung
Fehler, die ein Programmierer während der Implementierung macht, sind häufig auf Ei-
genheiten der menschlichen Wahrnehmung zurückzuführen. Mit dieser Thematik haben
51

5. Implementierung und Test
von möglichen Deadlocks. Des Weiteren beinhaltet das Programm Analysen für Abhän-
gigkeiten von Threads innerhalb einer Applikation.
PMD. Die Funktionsweise von PMD5 entspricht grundsätzlich der von FindBugs und
JLint, jedoch ohne Datenflussanalyse. PMD untersucht den Quelltext aber zusätzlich nach
Kodierungsrichtlinien, die ebenfalls eine fehlerhafte, oder aber zumindest eine unsaubere
Programmierung vermuten lassen.
Lint4J. Auch Lint4J6 untersucht den Quelltext und Bytecode nach Problemen bzgl. der
Performance, Skalierbarkeit und Threadsicherheit, analysiert den Datenfluss und erstellt
Blockierungsgraphen. Die durchgeführten Analysen basieren laut Aussagen des Herstel-
lers auf Erfahrungswerten, die während der Implementierung von Performance- und si-
cherheitskritischen Anwendungen gewonnen wurden.
Neben diesen Programmen existieren weitere Überprüfungssysteme wie z.B. Bandera7[62]
und ESC/Java8[63], welche jedoch deutlich weitergehende Ansätze verfolgen. Diese ba-
sieren auf Beweisen von zuvor bestimmten, formalen Vor- und Nachbedingungen (vgl.
[64, 65]) und Verifikation von Zustandsmodellen. Aufgrund der hohen Komplexität und
des wissenschaftlichen Schwerpunkts dieser Möglichkeiten wurde von deren Nutzung im
Rahmen dieser Arbeit abgesehen.
5.2.3. Bewertung
Der Einsatz statischer, automatisierter Analyseverfahren hat deutlich zur Lesbarkeit und
Qualität der geschriebenenQuelltexte beigetragen. Insbesondere die Integration in die Ent-
wicklungsumgebung erleichterte den Umgang wesentlich und Hinweise konnten sofort
umgesetzt werden. Diese Hinweise waren aufgrund der hohen Zahl an formalisierten Er-
fahrungen zu weit verbreiteten und häufig gemachten Fehlern sehr zahlreich und führ-
ten zu einem ständigen Lernprozess während der Entwicklung. So wurden insbesondere
robustere und effizientere Lösungen implementiert, deren Funktionsweise im Anschluss
durch dynamische Testfälle überprüft werden konnten.
Es liegt jedoch in der Natur der Sache, dass nicht alle Meldungen zu Quelltextabschnit-
ten auf existierende Probleme oder Fehler hinweisen. Je nach Kontext sind verschiedene,
gleichwertige Lösungsansätze möglich und Falschmeldungen sind nicht gänzlich zu ver-
meiden.
5http://pmd.sourceforge.net
6http://www.jutils.com
7http://bandera.projects.cis.ksu.edu
8http://secure.ucd.ie/products/opensource/ESCJava
54

5. Implementierung und Test
5.3. Dynamische Testverfahren
5.3.1. Einleitung
Unter dynamischen Testverfahren wird das Testen von Software durch Ausführung von
Testobjekten beschrieben. Dabei wird ein Teil der Software über definierte Schnittstellen
mit vorgegebenen Eingaben ausgeführt und das Ergebnis mit zuvor spezifizierten Erwar-
tungswerten verglichen. Das Ziel des dynamischen Testens ist der Nachweis der Erfüllung
von festgelegten Anforderungen durch das implementierte Programmstück und die Auf-
deckung von eventuellen Abweichungen und Fehlerwirkungen (vgl. [52, 53]). Dynami-
sche Testverfahrenwerden ebenfalls bei der inkrementellen Softwareentwicklung benötigt.
Während der Überarbeitung der Programmstruktur als Reaktion auf neue Anforderungen,
darf sich das Verhalten der restlichen Funktionen nicht ändern. Um dies gewährleisten zu
können, sind entsprechende Testverfahren erforderlich.
Im Gegensatz zu automatisierten Quelltextanalysen ist ein vollständiger Test der An-
wendung im Allgemeinen jedoch nicht möglich. Die Überprüfung aller in Frage kommen-
den Eingabedaten und deren Kombinationen, unter Berücksichtigung jeder Randbedin-
gung, ergäben eine nahezu unbegrenzte Anzahl an Möglichkeiten (vgl. [66]). Daher be-
schränken sich Tests auf eine systematisch festgelegte Teilmenge der Eingabewerte. Die
Testergebnisse des entwickelten Systems finden sich in Anhang B.2.
5.3.2. Testverfahren
Um eine sinnvolle Teilmenge der möglichen Eingabewerte zu bestimmen, bieten sich bei
der Testfallgenerierung je nach Verfügbarkeit der Quelltexte drei systematische Verfahren
an. Von diesen wurde in der vorliegenden Arbeit jeweils Gebrauch gemacht; sie werden
im Folgenden kurz beschrieben. Eine ausführlichere Schilderung der Verfahren ist im Rah-
men dieser Arbeit nicht möglich, daher sei auf die einschlägige Fachliteratur verwiesen
(vgl. [67, 68, 66]).
Blackbox-Verfahren. Bei Blackbox-Verfahren ist der innere Aufbau der Testobjekte nicht
bekannt. Sinnvolle Werte für Testbeschreibungen werden aus Spezifikationen ermittelt
und anhand verschiedener Methoden geprüft. So werden Eingabewerte, bei denen davon
ausgegangen wird, dass sich das Testobjekt jeweils gleich verhält, in Äquivalenzklassen
eingeteilt. Da Fehlerzustände in Programmen häufig an Grenzbereichen dieser Äquiva-
lenzklassen auftreten, werden in der Grenzwertanalyse die äußersten Werte der Klassen
einer Prüfung unterzogen. Zusätzlich können viele Testobjekte unterschiedliche Zustände
annehmen, die z.B. von Funktionsaufrufen ausgelöst werden. Daher werden häufig eben-
falls zustandsbezogene Tests durchgeführt. Die Grundlage zur Anwendung von Blackbox-
Verfahren bieten in diesem Zusammenhang unter anderem die Aktivitätsdiagramme aus
55

5. Implementierung und Test
Emma. Emma11 analysiert ebenso wie Coverlipse die Quelltextüberdeckung der verwen-
deten Testfälle. Der Schwerpunkt liegt bei Emma jedoch weniger in der Integration in die
Entwicklungsumgebung als vielmehr in der Erstellung übersichtlicher Ergebnisberichte
(siehe B.2).
5.3.5. Bewertung
Die entwickelten, automatisierten Testfälle für das System unterstützten insbesondere die
Umstrukturierung der Quellen und vereinfachten die Fehlerbehebung. Für Komponenten,
für die Testfälle existierten, musste während aufwändiger Fehleranalysen mit Abstand am
wenigsten Zeit investiert werden. Ebenso konnte Programmcode früher Prototypenmittels
geeigneter Testfälle weiterverwendet und einfach in neue Quelltexte integriert werden.
Die Entwicklung von Testfällen zu existierendemCode oder noch zu schreibenden Funk-
tionen verlangt jedoch ein wenig Selbstdisziplin, da sich deren Nutzen erst im Laufe der
späteren Entwicklung erschließt. Des Weiteren eigneten sich nicht alle Komponenten im
gleichen Maß zum automatisierten Testen. Speziell Komponenten zur Benutzerinteraktion
mussten manuell in regelmäßigen Abständen überprüft werden.
11http://emma.sourceforge.net
58

6. Zusammenfassung, Kritik und Ausblick
6.3. Ausblick
Projekte dieser Größenordnung bieten genügend Potential für weitere Entwicklungen. Die
Dynamik und Evolution von zusammenhängenden Softwaresystemen stellen zukünftige
Herausforderungen dar. So steht etwa die JSR-286-Portletspezifikation[71] kurz vor ihrer
Veröffentlichung, undDatenbanksysteme, die sowohl relationale auch XML basierte Daten
verwalten, werden dedizierte Systeme vermutlich ablösen.
Dies führt auch zu Optimierungsmöglichkeiten innerhalb des Instant-Grid-Projektes.
Insbesondere der Speicheraufwand der für den Betrieb zweier unabhängiger Datenbank-
systeme notwendig ist, könnte so reduziert werden. Aufgrund des hohen Speicherbedarfs
von Java Anwendungen innerhalb einer virtuellen Maschine, ist ebenfalls eine Umsetzung
des GRDBD als native Anwendung denkbar. Ansätze, Java Bytecode in nativen Code zu
überführen, gibt es schon seit längerem[72], und aktuelle Projekte wie der GNU Compiler
für Java1 könnten eine Umstellung vereinfachen. Ebenso kann eine eingehende Analyse
der vorausgesetzten, technischen Anforderungen (s. Abs. 3.5.4.1) zu einer Herausbildung
von möglichen Alternativen führen.
Ein weiterer Aspekt sind Analysen der Performanz des entwickelten Systems in Bezug
auf die Anzahl der existierenden Hardware-Ressourcen, der Menge an Software-Beschrei-
bungen und des Aktualisierungsintervalls des GRDB-Daemons und der Information-Pro-
vider. Diese Ergebnisse haben einen direkten Einfluss auf die Struktur der Datenbank und
dem Zusammenspiel des GRDBD, der IP und des GWES (/T50/T60/). Ebenso könnenMög-
lichkeiten der automatisierten Ermittlung von Software-Ressourcen untersucht werden
(/D60/ F51/).
Darüber hinaus sind Erweiterungen der Benutzeroberfläche denkbar. So können zur Ge-
staltung der Interaktionsstruktur Punkte der ISO 134072 herangezogen werden und die
einschlägige Literatur[73, 74] für das Design der Oberfläche berücksichtigt werden. Auch
sind weitere Auswertungen der gesammelten Daten in Betracht zu ziehen, wie etwa die
graphische Darstellung von Auslastungsdaten innerhalb eines gesetzten Zeitintervalls -
eine Erweiterung der Datenbankstruktur zur Speicherung von Zeitinformationen voraus-
gesetzt (/F110/). Als letzte Punkte sind eine mögliche Internationalisierung des Portlets
und die Einbindung eines Editors zur Bearbeitung von Software-Beschreibungen zu nen-
nen.
1http://gcc.gnu.org/java
2Benutzer-orientierte Gestaltung interaktiver Systeme
60

A. Verwendete Konfiguration
A.1. Hardware
Die Entwicklung des Systems erfolgte abwechselnd auf zwei unterschiedlichen Arbeits-
platzrechnern. Durch diese Maßnahme werden unter anderem unvollständige Teilpakete
des zu entwickelnden Systems frühzeitig erkannt und mögliche Inkompatibilitäten recht-
zeitig aufgedeckt.
Tabelle A.1.: Verwendete Hardware
Kategorie Arbeitsplatzrechner 1 Arbeitsplatzrechner 2
Bezeichnung Dell Precision 380 Fujitsu-Siemens A7600
Architektur 64 Bit (EM64T) 32 Bit (x86)
Prozessor Intel Pentium 4HT Mobile AMD Athlon 2000+
Taktung 3,00 GHz 1,60 GHz
Speicher 1024 MB 512 MB
Betriebssystem SuSE Linux 10.1 (Kernel 2.6.12) SuSE Linux 10.1 (Kernel 2.6.16)
A.2. Software
Nachfolgend sind alle relevanten Software-Pakete aufgeführt, die zum Aufbau eines, zur
verwendeten Entwicklungsumgebung identischen, Arbeitsumfeldes dienen.
Tabelle A.2.: Verwendete Software
Kategorie Name Version URL
Dokumentation Auriga 0.1b www.aurigalogic.com
Dokumentation Poseidon for UML 4.2.1 (CE) www.gentleware.com
Dokumentation Xref 1.6.8 www.xref-tech.com
Dynamisches Testen Coverlipse 0.9.5.2 http://coverlipse.sf.net
Dynamisches Testen Emma 2.0.5312 emma.sf.net
Dynamisches Testen JUnit 3.8.1 junit.sf.net
Entwicklungsumgebung Ant 1.6.5 ant.apache.org
Entwicklungsumgebung Eclipse SDK 3.2 www.eclipse.org
61

A. Verwendete Konfiguration
Entwicklungsumgebung GridSphere Portal 2.2.5 www.gridsphere.org
Entwicklungsumgebung Instant-Grid 0.4nb www.instant-grid.org
Entwicklungsumgebung Java SDK 1.5.0_07 java.sun.com
Entwicklungsumgebung Linux Kernel 2.6.12 www.kernel.org
Entwicklungsumgebung Tomcat 5.0.28 tomcat.apache.org
Entwicklungsumgebung Subversion 1.3 subversion.tigris.org
Entwicklungsumgebung VMWare 5.5.1 http://www.vmware.com/
Quelltextanalyse Checkstyle 4.2 checkstyle.sf.net
Quelltextanalyse FindBugs 1.1.0 findbugs.sf.net
Quelltextanalyse Lint4J 0.9.11 www.jutils.com
Quelltextanalyse PMD 3.7 pmd.sf.net
62

B. Dokumentation
B.1. Quelltexte
Aus Platzgründen befinden sich die Quelltexte auf der beigefügten CD-ROM oder kann
unter grid.alexanderwillner.de heruntergeladen werden.
B.2. Testergebnisse
Die Übersicht der getesteten Quelltextabschnitte befindet sich auf den Seiten 64ff.
B.3. GRDB-API
Aus Platzgründen befindet sich die Dokumentation der API auf der beigefügten CD-ROM
oder kann unter grid.alexanderwillner.de heruntergeladen werden.
B.4. GRDB-Portletübersicht
Die Übersichtsgraphik des GRDB-Portlets befindet sich auf Seite 66.
B.5. D-GRDL-Spezifikation
Die Spezifikation der D-GRDL befindet sich auf den Seiten 67ff.
63

16
.
0
.
26
f
il
e:
/h
ome
/
aw
il
ner
/S
o
f
t
ware
3/
gr
id
sp
.
ap
/d
ocs
/
verag
/
_
f
il
es
/
ovr
i
ew
.
h
t
m
l #1
E
MA
C
vrg
R
pr
t
(
nra
t
e
W
e
S
p
2
71
0
:
23
:
1
CE
S
T
206)
[all classes]
O
V
E
RAL
CO
V
E
RA
G
E
S
UMARY
name
c
l
as
,
%
me
t
h
o
d
,
%
b
l
o
c
k
,
%li
ne
,
%
all classes 100%(12/12) 100%(88/88) 91%(1458/1606) 91%(441/486)
O
V
E
RAL
S
TA
S
UMARY
totalpackages: 3
totalexecutablefiles: 12
totalclasses: 12
totalmethods: 88
totalexecutablelines: 486
CO
V
E
RA
G
E
BRAKD
O
WNBYPA
C
K
G
E
name
c
l
as
,
%
me
t
h
o
d
,
%
b
l
o
c
k
,
%li
ne
,
%
org.instantgrid.grdb.daemon 100%(4/4) 100%(32/32) 82%(586/715) 84%(194/231)
org.instantgrid.grdb.model 100%(6/6) 100%(51/51) 98%(817/836) 97%(234/242)
org.instantgrid.grdb.config 100%(2/2) 100%(5/5) 100%(55/55) 100%(13/13)
[all classes]
EMMA2.0.5312(C)VladimirRoubtsov
E
MA
C
v
eage
R
pr
t
(
genra
t
e
d
W
e
dS
p
2
71
0
:
23
:
1
CE
S
T
206)
[all classes]
CO
V
E
RA
G
E
S
UMARYF
O
RPA
C
K
G
E
[
o
rg
.
i
ns
t
a
t
gr
id
.
gr
b
.
d
aemon
]
name
c
l
s
,
%
t
h
,
%
b
l
o
c
k
,
%li
ne
,
%
org.instantgrid.grdb.daemon 100%(4/4) 100%(32/32) 82%(586/715) 84%(194/231)
CO
V
E
RA
G
E
BRAKD
O
WNBY
S
O
UR
CE
FIL
E
name
c
l
as
,
me
t
h
o
d
,
b
l
o
c
k
,
li
ne
,
GangliaConnector.java 100%(1/1) 100%(4/4) 81%(79/98) 81%(30/37)
GrdbDaemon.java 100%(1/1) 100%(21/21) 81%(449/556) 84%(145/173)
MdsConnector.java 100%(1/1) 100%(3/3) 94%(44/47) 87%(13/15)
AbstractGrdbConnector.java 100%(1/1) 100%(4/4) 100%(14/14) 100%(6/6)
[all classes]
EMMA2.0.5312(C)VladimirRoubtsov
E
MA
C
v
eage
R
pr
t
(
genra
t
e
d
W
e
dS
p
2
71
0
:
23
:
1
CE
S
T
206)
[all classes]
CO
V
E
RA
G
E
S
UMARYF
O
RPA
C
K
G
E
[
o
rg
.
i
ns
t
a
t
gr
id
.
gr
b
.
mo
d
e
l
]
name
c
l
s
,
%
e
t
h
,
%
b
l
o
c
k
,
%li
ne
,
%
org.instantgrid.grdb.model 100%(6/6) 100%(51/51) 98%(817/836) 97%(234/242)
CO
V
E
RA
G
E
BRAKD
O
WNBY
S
O
UR
CE
FIL
E
name
c
l
as
,
me
t
h
o
d
,
b
l
o
c
k
,
li
ne
,
XmlTransformer.java 100%(1/1) 100%(3/3) 91%(74/81) 83%(20/24)
GridResourceFactory.java 100%(1/1) 100%(2/2) 96%(139/145) 95%(37/39)
XmlDB.java 100%(1/1) 100%(13/13) 98%(293/299) 98%(80/82)
GridResource.java 100%(1/1) 100%(20/20) 100%(223/223) 100%(66/66)
GridResourceSimpleProperty.java 100%(1/1) 100%(11/11) 100%(80/80) 100%(27/27)
ResourceNotFoundException.java 100%(1/1) 100%(2/2) 100%(8/8) 100%(4/4)

16
.
0
.
26
f
il
e:
/h
ome
/
aw
il
ner
/S
o
f
t
ware
3/
gr
id
sp
.
ap
/d
ocs
/
verag
/
_
f
il
es
/
ovr
i
ew
.
h
t
m
l #2
[all classes]
EMMA2.0.5312(C)VladimirRoubtsov
E
MA
C
v
eage
R
pr
t
(
genra
t
e
d
W
e
dS
p
2
71
0
:
23
:
1
CE
S
T
206)
[all classes]
CO
V
E
RA
G
E
S
UMARYF
O
RPA
C
K
G
E
[
o
rg
.
i
ns
t
a
t
gr
id
.
gr
b
.
c
on
fi
g
]
name
c
l
s
,
%
me
t
hd
,
%
b
l
o
c
k
,
%li
ne
,
%
org.instantgrid.grdb.config 100%(2/2) 100%(5/5) 100%(55/55) 100%(13/13)
CO
V
E
RA
G
E
BRAKD
O
WNBY
S
O
UR
CE
FIL
E
name
c
l
as
,
%
me
t
h
o
d
,
b
l
o
c
k
,
li
ne
,
Config.java 100%(1/1) 100%(3/3) 100%(26/26) 100%(7/7)
I18N.java 100%(1/1) 100%(2/2) 100%(29/29) 100%(6/6)
[all classes]
EMMA2.0.5312(C)VladimirRoubtsov

Auszug aus der D-GRDL fu¨r das InstantGrid-Projekt 2
1 Ziele und Grenzen
Ein Ziel dieser Spezifikation ist es, eine (Ziel-)Sprache D-GRDL zu definieren,
die mo¨glichst vielen der bestehenden (und teilweise im Umbruch befindlichen)
Ressourcenbeschreibungen gerecht wird. U¨bersetzer zwischen bestehenden Spra-
chen und D-GRDL kann es von unserer Seite innerhalb des jetzigen Projekts
aufgrund des damit verbundenen Aufwands nicht geben. Es gilt mit D-GRDL
eine gemeinsame Sprache zu haben, die es erlaubt, Ressourcen unterschiedlicher
Grid-Infrastrukturen mit einem einzigen Formalismus zu beschreiben. Daru¨ber
hinaus soll Software zu deren Verarbeitung bereit gestellt werden, z. B. um
Ressourcen u¨ber Infrastrukturgrenzen zu verwalten und aufzufinden. Die so ge-
wonnene Information kann dann bei und mit der jeweiligen Infrastruktur mit
ihren individuellen Spezifika weiter verarbeitet werden.
In diesem Dokument wird deshalb nicht nur die D-Grid-
Ressourcenbeschreibungssprache, im Folgenden kurz ”D-GRDL“ genannt,formal spezifiziert und anhand von Beispielen erla¨utert. Es werden erga¨nzend
auch Konzepte, Methoden und Verfahren festgelegt, um Beschreibungen von
Grid-Ressourcen zu pru¨fen, zu speichern, zu aktualisieren und abzufragen.
Ihre Umsetzung und Implementierung soll eine zentrale Aufgabe im Grid-
Computing unterstu¨tzen, na¨mlich das Resource-Matching. Dabei geht es darum,
beschriebene Ressourcen anhand zu erfu¨llender Eigenschaften aufzufinden,
d. h. Ressourcen zu finden, die gegebenen Anforderungen genu¨gen, so dass
ein Job prinzipiell/potentiell auf einer Grid-Infrastruktur ausfu¨hrbar ist: seine
Ressourcenbedarfe (requests) mu¨ssen durch passende Angebote (matching bids)
erfu¨llt sein. Dieses Zuordnungsproblem gilt es zu lo¨sen: jeder Nachfrage ist ein
Angebot oder einer Menge (alternativer) passender Angebote zuzuordnen.
Diese Zuordnung erfolgt anhand von Ressourcen-Eigenschaften, die generell sta-
tischer Natur sind. Dynamische Eigenschaften der Ressourcen, wie z. B. aktuelle
Prozessor- oder Speicherauslastungen bleiben dabei unberu¨cksichtigt. Diese Da-
ten werden erst bei der anschließenden Einlastung des Jobs bei der Auswahl
konkreter Ressourcenangebote aus den passenden ermittelt und eingesetzt. Die
konkrete Einlastung der Jobs auf passende Ressourcen wird Resource-Mapping
bezeichnet und ist nicht Gegenstand der folgenden U¨berlegungen.
Die D-GRDL und die sie unterstu¨tzenden Implementierungen ist daher so
ausgelegt, dass in Ressourcenbeschreibungen grundsa¨tzlich nur auf absehba-
re Zeit konstante Informationen repra¨sentier- und verarbeitbar ist. Die un-
mittelbare Repra¨sentation zeitlich kontinuierlicher oder feingranular diskreti-
sierter Informationen ist in der D-GRDL nicht mo¨glich. Jedoch bietet die D-
GRDL mit ihrem offenen Mechanismus zur Definition von Eigenschaften (pro-
perties) die Mo¨glichkeit der indirekten Repa¨sentation solcher Informationen:
Damit ko¨nnen Referenzen auf Dienste festgelegt werden, die einen Zugriff auf
zeit-kontinuierliche Informationen erlauben (z. B. Zugriff auf ein Monitoring-
System). Somit lassen sich Doppelungen separater Formalismen fu¨r dynamische
Ressourcen-Informationen, deren Semantik mit der D-GRDL u¨berlappen mu¨ss-
te, vermeiden, ohne dass sofort den Ressourcenbeschreibungen die gesamte Last
aller dynamischen Informationen aufgebu¨rdet wird.

Auszug aus der D-GRDL fu¨r das InstantGrid-Projekt 4
Beispiel: Als Beispiel seien im folgenden die Produktionen einer Grammatik
mit Startsymbol Id angegeben, die die Bezeichner einer Programmiersprache
in u¨blicher Form beschreibt, na¨mlich als nichtleere Folgen von Buchstaben und
Ziffern, die mit einem Buchstaben beginnen:
Id −> Let te r ( Le t t e r | Dig i t )∗
Let te r −> ’ a ’ | . . . | ’ z ’ | ’A’ | . . . | ’Z ’
D ig i t −> ’ 0 ’ | ’ 1 ’ | . . . | ’ 9 ’
Da sich unmittelbar aus den Produktionen die Nichtterminale und Terminale
der Grammatik ergeben, werden wir im Folgenden auf eine explizite Angabe
dieser Mengen und des Quadrupels G = (N,T, P, S) verzichten.
2.2 XML und XML-Schema sowie XPath
Die D-GRDL ist eine Teilmenge der eXtended Markup Language (XML)1, die
einem XML-Schema2 genu¨gt, wobei wir der Einfachheit halber im Folgenden
die Sprache mit Hilfe einer kontextfreien Grammatik formulieren, jedoch auch
ein entsprechendes XML-Schema angeben, dass u. a. zur Evaluierung oder zu
korrekten Konstruktion von D-GRDL-Konstrukten eingesetzt werden kann.
Um die Semantik der D-GRDL z.B. mittels einzuhaltender Bedingungen zu
formulieren, nutzen wir die Sprache XPath3, mit der man auf Teilkonstrukte
einer XML-Sprachkonstrukts referenzieren kann.
Eine Beschreibung dieser Formalismen ist nicht Gegenstand dieses Dokuments.
Detaillierte Definitionen und Spezifikationen dieser Formalismen finden sich in
der einschla¨gigen und vielfa¨ltig verfu¨gbaren Literatur.
3 Beschreibungssprache
3.1 Bezeichner
Bezeichner in D-GRDL-Beschreibungen sind Uniform Resource Identifier
(URI), die im Allgemeinen durch Element-Attribute wiedergegeben werden. Als
URI du¨rfen beliebige zula¨ssige Bezeichner anyURI verwendet werden, wobei
ga¨ngige aber auch eigene Konventionen zu deren Strukturierung umsetzbar sind.
Diese Konventionen sind nicht Bestandteil der D-GRDL und somit durch die
Nutzer der Sprache festzulegen.4
URI −> ’ u r i =”’ anyURI ’ ” ’
1siehe http://de.wikipedia.org/wiki/XML zur U¨bersicht mit weiterfu¨hrenden Verweisen,
u. a. zu den offiziellen Dokumenten des W3C.
2siehe http://de.wikipedia.org/wiki/XML_Schema zur U¨bersicht mit weiterfu¨hrenden
Verweisen, u. a. zu den offiziellen Dokumenten des W3C.
3siehe http://de.wikipedia.org/wiki/XPath zur U¨bersicht mit weiterfu¨hrenden Verwei-
sen, u. a. zu den offiziellen Dokumenten des W3C.
4siehe http://de.wikipedia.org/wiki/Uniform_Resource_Identifier zur U¨bersicht u¨ber
den Aufbau und die Struktur von URIs.

Auszug aus der D-GRDL fu¨r das InstantGrid-Projekt 8
wobei
ICsimplePropUnique(R, $P ) ≡ {
∀x ∀α ∀β : (x ∈ R
∧ α ∈ x/$P/simpleProperty
∧ β ∈ x/$P/simpleProperty
∧ α/@ident = β/@ident)
=⇒ α = β }
sei, d. h. die eigentlichen Bedingungen sich durch Substitution des Parameter
$P durch resource ergeben.5
Die mo¨glichen Werte einer einfachen Eigenschaftsdefinition wird durch ihren
Typ eingeschra¨nkt, d. h. wenn dieser Typ ein Basistyp ist, so gilt fu¨r eine Menge
von Ressourcenbeschreibungen R
ICsimplePropBtype(R, resource, ’int’, Integer)
∧ ICsimplePropBtype(R, resource, ’float’,Decimal)
∧ ICsimplePropBtype(R, resource, ’bool’,Boolean)
∧ ICsimplePropBtype(R, resource, ’string’, String)
∧ ICsimplePropBtype(R, resource, ’uri’, anyURI)
∧ ICsimplePropBtype(R, resource, ’date’,Date)
∧ ICsimplePropBtype(R, resource, ’time’,Time)
∧ ICsimplePropBtype(R, resource, ’dateTime’,DateTime) ,
wobei
ICsimplePropBtype(R, $P, $T, $S) ≡ {
∀x ∀α : (x ∈ R ∧ α ∈ x/$P/simpleProperty[@type = $T ])
=⇒ α/text() ∈ $S }
sei. Das heißt, alle Werte einfacher Eigenschaftsbedinungen mu¨ssen dem definier-
ten Typ entsprechen. Die eigentlichen Bedingungen ergeben sich auch hier durch
Substitution des Parameters, wobei Integer, Decimal, String, anyURI, Date, Time
sowie DateTime die Mengen mo¨glicher Werte (syntaktische Konstrukte) seien,
die durch die Produktionen der gleichnamigen Nichtterminale definiert sind.
Formale Semantik: Einfache Eigenschaftsdefintionen innerhalb von Ressour-
cenbeschreibungen legen entsprechend benannte, typisierte und quantifizierte
Eigenschaften der Ressourcen fest. Da diese viel mit mit Feldern (engl. fields)
von Objekten gemein haben, verwenden wir die gleiche Schreibweise wie in ob-
jektorientierten Programmiersprachen (z. B. Java):
∀x : x ∈ R =⇒ evalSimpleProperties(x) ,
wobei bei einer gegebenen Menge von Verbundtypen T und Erfu¨llung der In-
tegrita¨tsbedingungen die einfachen Eigenschaftsdefinitionen der Struktur y fu¨r
5Wir benutzen diese abku¨rzende Schreibweise, um im weiteren Verlauf der Sprachdefinition
eine explizite Auflistung von Bedingungen, die sich von den hier vorgestellten nur in wenigen
Bezeichern unterscheiden, zu vermeiden.

Auszug aus der D-GRDL fu¨r das InstantGrid-Projekt 11
gelten, wobei
ICprovidesExists(R, $P ) ≡ {
∀x ∀α ∃y : (x ∈ R ∧ y ∈ R
∧ α ∈ x/resource/provides/$P )
=⇒ α/@uri = y/resource[1]/@uri }
sei.
Formale Semantik: Wie besagt, definiert die Aggregation eine bina¨re Rela-
tion provides auf Ressourcen: Ist eine Menge von Ressourcenbeschreibungen R
gegeben, dann gilt
∀x : x ∈ R =⇒ evalProvides(x) ,
wobei
evalProvides(x)
:=
∧
α∈x/resource/provides/resourceRef
evalSimpleProvides(x, α)
und
evalSimpleProvides(x, y) := x/resource[1]/@uri provides y/@uri
sei.
Beispiel: Zur Semantik der Relation provides ein erla¨uterndes Beispiel, bei dem
drei Ressourcenbeschreibungen gegeben sind:
h ≡
<r e s ou r c e u r i=”ha r l e k in ”>
<o fC l a s s u r i=”urn :dgrd l :hardware : in t e lPC ”/>
<name>ha r l e k in</name>
<d e s c r i p t i o n>
ha r l e k in PC at Fraunhofer FIRST in room 128
</ d e s c r i p t i o n>
<prov ide s>
<r e sou rceRe f u r i=”cat ”/>
<r e sou rceRe f u r i=”xyz ”/>
</ prov ide s>
</ r e s ou r c e>
c ≡
<r e s ou r c e u r i=”cat ”>
<o fC l a s s u r i=”u rn :d g rd l : s o f twa r e ”/>
<name>cat</name>
<d e s c r i p t i o n>
the cat program
</ d e s c r i p t i o n>
</ r e s ou r c e>

Literaturverzeichnis
[12] I. Foster and C. Kesselman, “The grid: Blueprint for a new computing infrastructure,”
Morgan Kaufmann, Tech. Rep., 1999.
[13] I. Foster, C. Kesselman, and S. Tuecke, “The Anatomy of the Grid: Enabling Scalable
Virtual Organizations,” International Journal of High Performance Computing Applicati-
ons, vol. 15, no. 3, pp. 200–222, 2001.
[14] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke, “The physiology of the grid,” IBM
Corporation, Poughkeepie, NY 12601, Tech. Rep., June 2002.
[15] I. Foster, “What is the grid? a three point checklist,” July 2002.
[16] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke, “A security architecture for
computational grids,” in ACM Conference on Computer and Communications Security,
1998, pp. 83–92, fetched on the 13rd of August 2006. [Online]. Available:
http://citeseer.ist.psu.edu/foster98security.html
[17] M. Humphrey and M. Thompson, “Security implications of typical grid computing
usage scenarios,” in Proceedings of Intl Symposium on High Performance Distributed Com-
puting. (HPDC), San Francisco, CA., August 2001, pp. 7–9.
[18] C. Catlett, “In search of gigabit applications,” Communications Magazine, IEEE, vol. 30,
no. 4, pp. 42–51, 1992.
[19] T. DeFanti, I. Foster, M. Papka, R. Stevens, and T. Kuhfuss, “Overview of the i-way:
Widearea visual supercomputing,” in International Journal of Supercomputer Applicati-
ons, vol. 10, 1996, pp. 123–130.
[20] CERN - European Organization for Nuclear Research, “Gridcafé - a brief
explanation of the grid,” fetched on the 21st of September 2006. [Online]. Available:
http://gridcafe.web.cern.ch/gridcafe
[21] I. Foster, “The Grid: A New Infrastructure for 21st Century Science,” Physics Today,
vol. 55, no. 2, pp. 42–47, 2002.
[22] P. Janson, J. Dayka, A. Nadalin, N. Nagaratnam, F. Siebenlist, V. Welch, I. Foster, and
S. Tuecke, “The security architecture for open grid services,” IBMCorporation, Zurich
Research Lab, Switzerland and Mathematics and Computer Science Division, Argon-
ne National Laboratory, Argonne, Tech. Rep., July 2002.
[23] I. Foster and C. Kesselman, “Globus: A metacomputing infrastructure toolkit,”
The International Journal of Supercomputer Applications and High Performance Computing,
vol. 11, no. 2, pp. 115–128, Summer 1997, fetched on the 21st of September 2006.
[Online]. Available: http://citeseer.ist.psu.edu/article/foster96globu.html
87

Literaturverzeichnis
[24] I. Foster, “A globus primer,” An Early and Incomplete Draft, August 2005.
[25] M. Litzkow, M. Livny, and M. Mutka, “Condor-a hunter of idle workstations,” Distri-
buted Computing Systems, 1988., 8th International Conference on, pp. 104–111, 1988.
[26] W. Gentzsch et al., “Sun Grid Engine: Towards Creating a Compute Power Grid,”
Proceedings of the First IEEE/ACM International Symposium on Cluster Computing and the
Grid, 2002.
[27] A. Natrajan, A. Nguyen-Tuong, M. Humphrey, M. Herrick, B. Clarke, and A. Grims-
haw, “The Legion Grid Portal,” Concurrency and Computation: Practice and Experience,
vol. 14, no. 13-15, pp. 1365–1394, 2002.
[28] R. Buyya, D. Abramson, and J. Giddy, “Nimrod/g: An architecture for a resource
management and scheduling system in a global computational grid,” in Proceedings
of the HPC ASIA2000, the 4th International Conference on High Performance Computing in
Asia-Pacific Region, Beijing, China. IEEE Computer Society Press, USA, 2000.
[29] D. Erwin et al., “UNICORE: A Grid computing environment,” Concurrency and Com-
putation: Practice and Experience, vol. 14, no. 13-15, pp. 1395–1410, 2002.
[30] Globus Documentation Project, “The Globus Toolkit 4 Programmer’s Tutorial,”
fetched on the 21st of September 2006. [Online]. Available: http://gdp.globus.org/
gt4-tutorial
[31] ——, “GT4 Admin Guide,” fetched on the 22nd of September 2006. [Online].
Available: http://www.globus.org/toolkit/docs/4.0/admin/docbook
[32] Leibniz-Rechenzentrum der Wissenschaften, “Installationsanleitung für Globus
Toolkit 4.0.1,” fetched on the 22nd of September 2006. [Online]. Available:
http://www.grid.lrz.de/de/mware/globus/GT4InstallGuide1-0.html
[33] R. Ho, K. Yin, D. Lee, D. Hung, C. Wang, and F. Lau, “InstantGrid: A Framework for
On-Demand Grid Point Construction,” LECTURE NOTES IN COMPUTER SCIENCE,
pp. 911–914, 2004.
[34] Instant-Grid-Projekt, “Vorträge und Publikationen,” fetched on the 21st of September
2006. [Online]. Available: http://instant-grid.de/?q=de/node/80
[35] H.-W. P. Martin Alt, Andreas Hoheisel and S. Gorlatch, “Using High Level Petri-Nets
for Describing and Analysing Hierarchical Grid Workflows,” in Proceedings of the Co-
reGRID Integration Workshop, 2005.
88

Literaturverzeichnis
[36] A. Hoheisel, “Grid Workflow Execution Service (GWES),” 2006,
fetched on the 21st of September 2006. [Online]. Availa-
ble: http://www.gridwork\begingroup\let\relax\relax\endgroup[Pleaseinsert\
PrerenderUnicode{ïnˇC´}intopreamble]ow.org/kwfgrid/gwes/docs
[37] P. C. Group, “Studie zur effizienz von projekten in unter-
nehmen,” Offizielle Fallstudien, 2004, fetched on the 20th of June
2006. [Online]. Available: http://www.paconsultinggroup.com/NR/rdonlyres/
408B35CB-1C45-49BF-8A71-2F608C1D7196/0/2003_EffizienzStudie_final.pdf
[38] W3C, “XML Path Language (XPath) - Recommendation,” November 1999, fetched
on the 20th of June 2006. [Online]. Available: http://www.w3.org/TR/xpath
[39] ——, “XQuery 1.0: An XML Query Language - Candidate Recommendation,” June
2006, fetched on the 20th of June 2006. [Online]. Available: http://www.w3.org/TR/
xquery/
[40] L. M. Andreas Laux, “XUpdate Working Draft,” September 2000, fetched on the
20th of June 2006. [Online]. Available: http://xmldb-org.sourceforge.net/xupdate/
xupdate-wd.html
[41] IEEE, “Ieee std 830-1998,” IEEE Computer Society Press, USA, Tech. Rep., 1988,
fetched on the 21st of September 2006. [Online]. Available: http://ieeexplore.ieee.
org/xpl/tocresult.jsp?isNumber=15571
[42] M.Meisinger, A. Rausch,M. Deubler, M. Gnatz, U. Hammerschall, I. Küffer, and S. Vo-
gel, “Das V Modell 200x - ein modulares Vorgehensmodell,” in 11. Workshop der Fach-
gruppe WI-VM der Gesellschaft für Informatik e.V. (GI) zur Akzeptanz von Vorgehensmodel-
len, R. Kneuper, R. Petrasch, and M. Wiemers, Eds. Shaker Verlag, 2004.
[43] A. Rausch, C. Bartelt, T. Ternité, and M. Kuhrmann, “The V-Modell XT Applied -
Model-Driven and Document-Centric Development,” in 3rdWorld Congress for Softwa-
re Quality, VOLUME III, Online Supplement, no. 3-9809145-3-4. International Software
Quality Institute GmbH, sep 2005, pp. 131 – 138.
[44] U. D. of Defense, “Software Requirements Specification, DI-MCCR-80025A,” Feb
1988.
[45] H. Partsch, Requirements-Engineering systematisch. Springer-Verlag Berlin, 1998.
[46] A. Cockburn, Writing Effective Use Cases. Addison-Wesley, 2001.
[47] C. Alexander, S. Ishikawa, M. Silverstein, et al., A pattern language. Oxford Univ. Pr.,
1977.
89

Literaturverzeichnis
[48] R. J. Erich Gamma, RichardHelm and J. Vlissides,Design Patterns - Elements of Reusable
Object-Oriented Software. Addison-Wesley, 2004.
[49] P. Avgeriou and U. Zdun, “Architectural patterns revisited–a pattern language,” 10th
European Conference on Pattern Languages of Programs (EuroPlop 2005), Irsee, Germany,
July, 2005.
[50] Java Community Process, “JSR-154 Servlet Specification,” Mai 2006, fetched on the
20th of June 2006. [Online]. Available: http://jcp.org/aboutJava/communityprocess/
final/jsr154
[51] ——, “JSR-168 Portlet Specification,” October 2003, fetched on the 20th of June 2006.
[Online]. Available: http://jcp.org/aboutJava/communityprocess/final/jsr168
[52] A. Spillner and T. Linz, Basiswissen Softwaretest. dpunkt-Verl., 2004.
[53] W. E. Perry, Software testen. mitp, 2003.
[54] G. Weinberg, The psychology of computer programming. Van Nostrand Reinhold Co.
New York, NY, USA, 1988.
[55] B. Schneiderman, “Software Psychology,” Winthrop, Cambridge, Mass, 1980.
[56] T. Grams, Denkfallen und Programmierfehler. Springer, 1990.
[57] E. Allen, Bug patterns in Java. Apress, 2002.
[58] J. S. F. Nick Rutar, Christian B. Almazan, “A Comparison of Bug Finding Tools for
Java,” University of Maryland, College Park, 2004, fetched on the 20th of June 2006.
[Online]. Available: http://www.cs.umd.edu/~jfoster/papers/issre04.pdf
[59] D. Hovemeyer andW. Pugh, “Finding Bugs Is Easy,” 2003, fetched on the 28th of June
2006. [Online]. Available: http://findbugs.sourceforge.net/docs/oopsla2004.pdf
[60] R. Crew et al., “ASTLOG: A language for examining abstract syntax trees,” Proceedings
of the USENIX Conference on Domain-Specific Languages, pp. 229–242, 1997.
[61] C. Artho, “Finding faults in multi-threaded programs,” 2001, master’s thesis, ETH
Zürich.
[62] J. C. Corbett, M. B. Dwyer, J. Hatcliff, S. Laubach, C. S. Pasareanu, Robby, and
H. Zheng, “Bandera: Extracting finite-state models from java source code,” in In Pro-
ceedings of the 22nd International Conference on Software Engineering, Limerick Ireland,
2000, p. 439–448.
90

Danksagung
An dieser Stelle möchte ich mich herzlich bei Herrn Prof. Dr. Neumair bedanken, der mir
die Anfertigung der Arbeit an der GWDG ermöglichte. Besonderer Dank gilt Prof. Dr.
Haan und meinem Betreuer Dr. Boehme für ihre fachliche und persönliche Unterstützung
während der letzten sechs Monate. Bedanken möchte ich mich auch bei allen Mitarbeitern
der „Arbeitsgruppe A“ für die wöchentlichen Diskussionsrunden und das angenehme Ar-
beitsklima.
Nicht zuletzt bedanke ichmich bei meiner Familie undmeiner Freundin. Ihr Verständnis
und ihre Unterstützung haben maßgeblich am Erfolg der Arbeit beigetragen.
92