Entwicklung einer Abstraktionsschicht f ur regelbasierte Expertensysteme am CERN Grid-Cluster - Fachbereich Elektrotechnik und Informatik ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fachbereich Elektrotechnik und Informatik
Bachelorarbeit
Entwicklung einer Abstraktionsschicht für
regelbasierte Expertensysteme am CERN
Grid-Cluster
Frank Iker
19. September 2008
Betreuer: Prof. Dr. rer. nat. Nikolaus Wulff
Danksagung
Mein besonderer Dank gilt Herrn Prof. Dr. rer. nat. Nikolaus Wulff, ohne dessen Un-
terstützung dieses Projekt nicht zu Stande gekommen wäre.
Des Weiteren bedanke ich mich bei Dipl. Physiker Tobias Henß, der mir stets mit konstruk-
tiver Kritik helfend zur Seite stand.
Auch möchte ich mich im Besonderen bei meinen Eltern Margarete und Otto Kremer für
ihre Unterstützung bedanken.
Abschließend danke ich meinem guten Freund Christoph Zuleger für das Korrekturlesen
meiner Arbeit.
i
Inhaltsverzeichnis
Danksagung i
1 Einleitung 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Die Expertensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Pixel Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 GridXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Aufgabenstellung 8
2.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Grundlagen 10
3.1 Regelbasierte Expertensysteme . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 JBoss Rules/Drools . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Sichere Kommunikation im Internet . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Kryptographische Hashfunktionen . . . . . . . . . . . . . . . . . . . 14
3.2.2 Asymmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . 14
3.2.3 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.4 Der X.509 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.5 Authentisierung und verschlüsselte Kommunikation durch SSL . . . 17
4 Entwurf 22
4.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Anwendungsfälle und Detailanforderungen . . . . . . . . . . . . . . . . . . 22
5 Implementierung 26
5.1 Die SSL Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1 Trust- und KeyManager . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Das Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1 Die Nachrichtenklassen . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Der Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.1 Der ClientHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ii
5.3.2 Der Sendecache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Der Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6 Anpassung des GridXP Expertensystems an die UnifiedXP Architektur 36
7 Fazit und Ausblick 39
Eidesstattliche Erklärung ii
Abkürzungsverzeichnis iv
Literaturverzeichnis vi
1
1 Einleitung
Im Rahmen dieser Arbeit wird die Entwicklung einer Client-Server Architektur als Teil
eines Expertensystems beschrieben, die eine beidseitige Authentisierung und verschlüsselte
Kommunikation bietet.
1.1 Motivation
An der Universität Wuppertal wurden die beiden Expertensysteme Pixel Advisor und
GridXP zunächst voneinander unabhängig entwickelt. Obwohl deren Einsatzgebiete un-
terschiedlich sind, gab es einige grundlegende Gemeinsamkeiten, die die Überlegung nahe-
legten, eine vereinte Softwarebasis für beide Systeme zu entwickeln.
Zusammen mit den beiden ursprünglichen Entwicklern arbeiteten mein Kommilitone Den-
nis Huning und ich an dieser Aufgabe. Während der Schwerpunkt meiner Arbeit in der Ent-
wicklung der Client-Server Architektur und des Netzwerkprotokolls lag, entwickelte Dennis
Huning im Rahmen seiner Bachelorarbeit die GUI1 Applikation, die wiederum meine Client
Komponente zur Kommunikation mit dem Server benutzt.
1.2 Aufbau
Zunächst folgt eine kurze Einführung in den Kontext, in dem diese Arbeit entstanden
ist, sowie eine Beschreibung der Funktionsweise und Einsatzgebiete der beiden Experten-
systeme Pixel Advisor und GridXP. Im Kapitel Grundlagen“ wird die für diese Arbeit
”
wichtige Klasse der regelbasierten Expertensysteme genauer betrachtet. Anschließend wird
die Rule Engine JBoss Rules/Drools vorgestellt, die ein wesentlicher Bestandteil der bei-
den oben genannten Systeme ist. Danach wird dargestellt, wie eine sichere Kommunikation
1
Graphical User Interface
2
zwischen einem Client und Server innerhalb eines Netzwerkes mit Hilfe des SSL Proto-
kolls ermöglicht werden kann. Im Kapitel Entwurf“ werden die Detailanforderungen an
”
die Softwarekomponenten und der Architekturentwurf beschrieben. Die Umsetzung dessen,
sowie eine ausführliche Funktionsbeschreibung der Komponenten folgt im Kapitel Im-
”
plementierung“. Im Anschluss daran wird auf die Anpassung des GridXP an die neuen
Softwarekomponenten eingegangen, welches letztlich die Anwendung der erarbeiteten, Uni-
fiedXP genannten, Architektur bedeutet. Der letzte Teil bildet ein persönliches Fazit und
ein Ausblick auf mögliche Erweiterungen des Systems.
1.3 Kontext
Das in der Nähe von Genf in der Schweiz gelegene, europäische Kernforschungszentrum
CERN1 beschäftigt ca. 2500 Mitarbeiter. Darüber hinaus arbeiten etwa 8000 Gast-Wissen-
schaftler an den Experimenten zur Erforschung physikalischer Grundlagen.
Das CERN besitzt den weltweit größten Teilchenbeschleuniger LHC2 . Er liegt 100 Meter
unter der Erde und besteht zum größten Teil aus einem Ring von supraleitenden Magne-
ten. Der Umfang des Ringes beträgt 27 km. Wenn der LHC im September 2008 seinen
Betrieb aufnimmt, werden dort entweder Protonen oder Bleikerne auf gegenläufigen Bah-
nen beschleunigt und nach erreichen einer Energie von 7 TeV bzw. 575 TeV zur Kollision
gebracht. An jedem Kollisionspunkt befindet sich ein Detektor, der die durch den Aufprall
entstehenden Teilchen registriert. Es gibt vier Hauptdetektoren, ALICE3 , ATLAS4 , CMS5
und LHCb6 , sowie zwei kleinere, TOTEM7 und LHCf8 .
Der größte Detektor ist ATLAS (Abbildung 1.1). Er ist 45 m lang, 25 m hoch und hat ein
Gewicht von 7000 Tonnen.[9] Sein Aufbau besteht im Wesentlichen aus vier Komponen-
ten:
• Innerer Spurdetektor zur Messung des Impulses geladener Teilchen
• Kalorimeter zur Messung der Teilchenenergie
1
Conseil Européen pour la Recherche Nucléaire (Europäische Organisation für Kernforschung)
2
Large Hadron Collider
3
A Large Ion Collider Experiment
4
A Toroidal LHC ApparatuS
5
Compact Muon Solenoid
6
Large Hadron Collider beauty
7
TOTal Elastic and diffractive cross section Measurement
8
Large Hadron Collider f orward
3
• Myon Detektor zur Identifizierung von Myonen
• Magnet System zur Krümmung der Teilchenbahnen
Abbildung 1.1: Der ATLAS Detektor [1]
In unmittelbarer Nähe zum Teilchenstrahl befindet sich ein Halbleiter Pixeldetektor. Er ist
1,3 m lang und hat einen Durchmesser von 30 cm. Der Pixeldetektor wurde maßgeblich
an der Universität Wuppertal von der Gruppe Prof. Dr. Mättig entwickelt. Er besteht
aus drei tonnenförmigen Lagen um die Strahlachse herum, sowie aus drei Scheiben an
beiden Enden senkrecht zur Achse. Auf den Lagen und Scheiben befinden sich Module, die
Siliziumsensoren enthalten. Diese Sensoren registrieren durch sie hindurchfliegende geladene
Teilchen, wodurch dann deren Flugbahn bestimmt werden kann. Der Detektor besitzt ca.
80 Millionen dieser sogenannten Pixel.[9]
Die von den Detektoren erzeugten Datenmengen stellen auf Grund ihrer Größe eine beson-
dere Herausforderung an die Computerinfrastruktur dar. Nach seiner Inbetriebnahme wird
der LHC etwa 15 Millionen Gigabyte pro Jahr an Daten erzeugen. Das entspricht einer
Menge von 1,7 Millionen DVDs jährlich. Anstatt ein einziges zentrales Rechenzentrum zu
verwenden, um diese Daten auszuwerten, wurde beim LHC ein anderer Ansatz gewählt. Bei
diesem als Grid-Computing bezeichneten Verfahren werden Großrechner an verschiedenen
Orten so verbunden, dass sie von den Benutzern wie ein einziger Supercomputer verwendet
werden können. Der Benutzer meldet sich an einem als Interface fungierendem Rechner an
und übermittelt an diesen seine Berechnungsaufgaben1 . Der Resource Broker2 entscheidet
1
Ein einzelner Auftrag für eine Berechnung wird auch mit dem englischen Begriff Job“ bezeichnet.
2 ”
Der Begriff entspricht dem in der Grid Middleware verwendeten englischen Nomenklatur und wird hier
4
Abbildung 1.2: Der Pixeldetektor [1]
dann, wo im Grid Verbund die Berechnungen ausgeführt werden.
1.4 Die Expertensysteme
Die für den Pixeldetektor und das LHC Grid entwickelten Expertensysteme wurden in
der Programmiersprache Java implementiert. Sie gehören zu den sogenannten regelbasier-
ten Systemen, d.h. ihr Kernbestandteil ist eine Regelmaschine1 , die eingegebene Daten an
Hand von Wenn-Dann Regeln verarbeitet. Diese liegen in textueller Form, getrennt vom
übrigen Programmcode vor. Beide Systeme verwenden die Open Source Rule Engine JBoss
Rules/Drools und besaßen in ihrer ursprünglichen Form nur eine rudimentäre GUI.
1.4.1 Pixel Advisor
Pixel Advisor ist das Expertensystem für den ATLAS Pixeldetektor. Die Entscheidung ein
Expertensystem zu verwenden wurde auf Grund von zwei Faktoren getroffen:
• Ein Datenverlust durch Fehler im Detektorsystem ist zu minimieren. Fehler müssen
darum möglichst schnell behoben werden.
darum nicht übersetzt.
1
englisch Rule Engine“
”
5• Ein auf das jeweilige Fachgebiet spezialisierter Experte ist aber in der Regel nicht
schnell verfügbar. Das Expertensystem kann unmittelbar erste Ratschläge und Hilfe-
stellungen zur Ursachenbehebung geben.
Abbildung 1.3: Datenquelle Pixel Advisor
Automatisch gesteuert und überwacht wird der Detektor durch die auf PVSS1 basierende
Pixel FSM2 . Die Kommunikation zwischen Pixel Advisor und PVSS erfolgt mit dem am
CERN entwickelten Netzwerkprotokoll DIM3 , für das auch eine Java Bibliothek (JDIM)
existiert. Die Bandbreite an Daten, die über den PVSS-DIM Server ausgetauscht werden
können, ist auf ca. 5000 Werte pro Sekunde beschränkt. Das Expertensystem muss sich diese
Bandbreite mit anderen Nutzern der DIM Infrastruktur teilen, so dass es nicht möglich ist,
gleichzeitig alle, der fast 32000 Parameter des Detektors als Datenquelle zu nutzen. Um den
Datenfluss zu minimieren bedient es sich der Tatsache, dass die Bestandteile des Detektors
hierarchisch in einer Baumstruktur angeordnet sind. Es überwacht zuerst nur die Zustände
der obersten drei Hauptbestandteile. Im Fehlerfall fragt der Pixel Advisor rekursiv die
Zustände der darunterliegenden Komponenten ab und traversiert den Baum solange, bis er
das Ende eines Pfades erreicht, an dem sich ein Modul befindet, das einen physikalischen
Messwert wie z.B. eine Temperatur oder Spannung liefert. Diese Messwerte werden dann
wieder vom Expertensystem verarbeitet und als Basis für die an den Benutzer ausgegeben
Lösungsvorschläge und Hinweise genutzt.
1
Von der ETM professional control GmbH entwickeltes Prozessvisualisierungs- und Steuerungssystem
2
Finite State Machine
3
Distributed Information Management
61.4.2 GridXP
GridXP ist das Expertensystem für das LHC Grid. Es dient dazu, dem Grid Benutzer Infor-
mationen über nicht erfolgreich beendete Jobs zu liefern. Ohne GridXP erhält der Benutzer
keine näheren Anhaltspunkte vom Grid Interface, warum ein Job fehlschlägt. GridXP hin-
gegen kann Gründe für das Fehlschlagen benennen, Fehlermeldungen erklären, Ratschläge
erteilen und Lösungsvorschläge bieten. Als Datenquelle dient die R-GMA1 Datenbank. Das
ist eine verteilte Datenbank, die von dem ebenfalls an der Universität Wuppertal entwickel-
ten Job Execution Monitor (JEM) befüllt wird. Der in der Programmiersprache Python
geschriebene JEM ersetzt dazu den ursprünglichen Job durch einen Wrapper“. Dieser
”
führt dann den eigentlichen, in der Regel aus einem Bash- oder Python-Skript bestehen-
den Job zeilenweise aus. JEM kann dadurch als Zwischenschicht zwischen der WorkerNode2
und Job fungieren und hat dadurch die Möglichkeit, detailliert dessen Ausführung hinsicht-
lich gesetzter Umgebungsvariablen, der Rückgabewerte einzelner Befehle und des verfügba-
ren Speichers etc. zu protokollieren. Neben den vom JEM gelieferten Daten kann GridXP
zusätzlich die zentrale SAM3 Datenbank am CERN abfragen und sich Informationen über
die im Grid angebotenen Dienste verschaffen.
Abbildung 1.4: Datenquellen GridXP
1
Relational Grid Monitoring Architecture
2
Bezeichnung für einen einzelnen Rechner im Cluster-Verbund
3
Service Availability Monitoring
72 Aufgabenstellung
Hauptziel ist, das durch die Verwendung einer gemeinsamen Softwarebasis beide Systeme
langfristig profitieren werden. Die Wartung wird erheblich vereinfacht, da mit der Einar-
beitung in die Funktionsweise eines der Expertensysteme auch schon Kenntnis über selbige
des anderen erlangt wird. Außerdem wirkt sich eine Erweiterung des Funktionsumfanges
auf beide Systeme aus.
2.1 Anforderungen
Einige der Anforderungen an die Client/Server-Komponenten ergeben sich aus dem Funkti-
onsumfang und Eigenschaften der ursprünglichen Expertensysteme. Diese müssen natürlich
auch nach der Umstellung auf die neue Softwarearchitektur gewährleistet sein. Zusätzliche
Funktionalität wird einerseits durch die Anforderungen der neuen GUI, andererseits durch
den hinzugekommenen und vorher nicht vorgesehen Sicherheitsaspekt bestimmt. Dieser for-
dert eine sichere Identifikation des Servers und der Clients (bzw. Benutzer). Ausserdem ist
eine verschlüsselte Kommunikation erforderlich.
Architektur
• Die Serverkomponente muss so modular aufgebaut sein, das ein Austausch der Daten
entnehmenden Komponente einfach möglich ist. Dadurch ist eine universelle Nutzung
für verschiedene Expertensysteme gewährleistet.
• Das Netzwerkprotokoll und dessen Verarbeitung ist so zu gestalten, das zukünftige
Erweiterungen der Funktionalität einfach zu realisieren sind.
8Produktfunktionen
• Sicherheit: Gegenseitige Authentisierung von Client und Server, sowie Verschlüsselung
der Kommunikation.
• Benutzergruppen: Erweiterte Funktionalität für Administratoren.
• Netzwerkbasierte Wartungs- und Steuerungsfunktionen.
Technische Produktumgebung
• Software: Installierte Java 5 (oder höher) Laufzeitumgebung.
• Produktschnittstellen:
– X.509 Zertifikate und Schlüsseldateien im PEM Dateiformat.
– Werden Client- und Serverkomponente auf verschiedenen Rechnern betrieben,
dann ist für den Server eine Netzwerkverbindung mit einem freien Port für ein-
gehende TCP Verbindungen, für den Client eine Netzwerkverbindung für aus-
gehende TCP Verbindungen erforderlich.
Entwicklungsumgebung
• Java JDK 5 oder höher
• Eclipse 3.3.2 mit SVN PlugIn
• OpenSSL (Für die Erzeugung von Test-Zertifikaten)
Benutzungsoberfläche
Für die Serverkomponente ist keine GUI vorgesehen, sie wird über die Kommandozeile
gestartet. Die Clientkomponente ist keine eigenständige Software, sondern wird von der
separat entwickelten GUI Applikation verwendet.
93 Grundlagen
3.1 Regelbasierte Expertensysteme
Ein Expertensystem ist eine Software die versucht, das Wissen und die Erfahrung eines Ex-
perten zur Verfügung zu stellen. Das Expertensystem soll dem Anwender bei der Lösung
konkreter Probleme oder der Einschätzung einer Situation helfen. Dabei ist die Kompetenz
der Software, genauso wie die eines menschlichen Experten, auf eine bestimmte Wissens-
domäne eingeschränkt. Die Hauptprobleme bei der Realisierung der Software liegen in der
Akquirierung und Formalisierung des Wissens, so das es durch Softwarealgorithmen re-
präsentiert werden kann.
Zur Modellierung des Expertenwissens können dabei verschiedene Ansätze gewählt werden.
Etwa in Form einer Falldatenbank. Das System versucht dabei, ein dem Problem möglichst
ähnlichen Fall auszuwählen und eine Lösung abzuleiten. Eine weitere Möglichkeit wäre die
Repräsentation des Wissens als Entscheidungsbaum. Durch die Beantwortung von Fragen
zum vorliegenden Problem, durchläuft das Programm einen Pfad des Baumes und gelangt
schliesslich zu einem Endknoten, der dem aktuellen Fall entspricht.
Eine weitere große Klasse, zu denen auch Pixel Advisor und GridXP gehören, bilden die re-
gelbasierten Expertensysteme. Abbildung 3.1 zeigt die Bestandteile eines solchen Systems,
dessen Kern die Inferenzmaschine1 bildet. Die Datennahme liefert eine Beschreibung des zu
lösenden Problems bzw. der aktuellen Situation in Form von, als Fakten bezeichnete Daten.
Diese werden mit Hilfe der Regelbasis, die das Expertenwissen als sogenannte Produktions-
oder Geschäftsregeln formuliert enthält, verarbeitet. Die Inferenzmaschine versucht zu einer
Schlussfolgerung zu gelangen, die schließlich dem Anwender von der Benutzerschnittstelle
präsentiert wird.
1
Inferenz [(lat. infero; hineintragen, folgern, schließen); (engl. inference; Rückschluss, Folgerung)]
10Abbildung 3.1: Bestandteile eines regelbasierten Expertensystems
113.1.1 JBoss Rules/Drools
JBoss Rules/Drools ist eine in Java geschriebene und unter der Apache Software License
veröffentlichte Rule Engine, deren Architektur in Abbildung 3.2 dargestellt ist:
• RuleBase: Enthält die Regeln.
• WorkingMemory: Speichert die Fakten.
• PatternMatcher: Überprüft die gespeicherten Fakten auf Übereinstimmung mit den
Bedingungsteilen der Regeln.
• Activation: Komposition aus zutreffender Regel und den dafür verantwortlichen Fak-
ten.
• Agenda: Enthält die Liste der Activations und entscheidet über deren Ausführungs-
reihenfolge.
Abbildung 3.2: Die JBoss Rules/Drools Architektur
Im Folgenden soll die Benutzung der Rule Engine JBoss Rules/Drools veranschaulicht
werden. Abbildung 3.3 zeigt den Inhalt der verwendeten Regeldatei rules.drl“, die für
”
dieses einfache Beispiel nur eine Regel enthält, sowie das Klassendiagramm der als Fakt
benutzten Klasse. Damit die Rule Engine Fakten verarbeiten kann, müssen deren Klassen
die Java Beans Spezifikation bezüglich der Getter und Setter Methoden erfüllen.
Zuerst liest der PackageBuilder die Regeln aus der Datei:
P a c k a g e B u i l d e r b u i l d e r = new P a c k a g e B u i l d e r ( ) ;
b u i l d e r . addPackageFromDrl (new F i l e R e a d e r ( " rules .drl" ) ) ;
Es wird eine neue Regelbasis erzeugt und die zuvor gelesenen Regeln werden hinzugefügt:
RuleBase r u l e B a s e = RuleBaseFactory . newRuleBase ( ) ;
r u l e B a s e . addPackage ( b u i l d e r . getPackage ( ) ) ;
12Die StatefulSession1 bildet das Interface zum WorkingMemory. Jetzt können beliebig Fak-
ten hinzugefügt, entfernt, oder das Feuern der Regeln ausgelöst werden:
S t a t e f u l S e s s i o n workingMemory = r u l e B a s e . n e w S t a t e f u l S e s s i o n ( ) ;
workingMemory . i n s e r t (new Fact ( 0 , "abc" ) ) ;
workingMemory . i n s e r t (new Fact ( 1 , "def" ) ) ;
workingMemory . i n s e r t (new Fact ( 2 , "ghi" ) ) ;
workingMemory . f i r e A l l R u l e s ( ) ;
Wie erwartet haben zwei Fakten den Bedingungsteil der Regel erfüllt und der Java Pro-
grammcode wird für beide ausgeführt. Die Ausgabe lautet:
number = 1 t e x t = d e f
number = 0 t e x t = abc
Abbildung 3.3: Beispiel für eine Regeldatei und UML Diagramm der verwendeten Klasse
Eine ausführliche Dokumentation über die Rule Engine findet sich unter [4].
3.2 Sichere Kommunikation im Internet
Im Folgenden werden einige Grundlagen und Verfahren erklärt, die eine sichere Kommuni-
kation in Computer-Netzwerken ermöglichen. Sicherheit umfasst hierbei eine gegenseitige
Authentisierung der Kommunikationspartner und Erhaltung der Vertraulichkeit und Inte-
grität der übermittelten Nachrichten. Zunächst werden die Eigenschaften kryptographischer
1
Alternativ lässt sich auch eine StatelessSession erzeugen, der alle Fakten auf einmal in Form einer Col-
lection übergeben werden. Das Einfügen und Feuern der Regeln wird dann nacheinander für jedes
Element ausgeführt. Nach Abarbeitung der Liste bleiben keine Referenzen auf die Fakten zurück. Eine
StatelessSession hat also im Gegensatz zur StatefulSession kein Gedächtnis“.
”
13Hashfunktionen, asymmetrische Verschlüsselung mit öffentlichen und privaten Schlüsseln
und digitale Zertifikate erklärt. Danach wird die Funktionsweise des SSL1 Protokolls dar-
gestellt.
3.2.1 Kryptographische Hashfunktionen
Eine Hashfunktion h(x) ist ein Abbildung, die Informationen beliebiger Länge einen Wert
fester Länge zuordnet. An eine kryptographische Hashfunktion werden dabei zusätzliche
Anforderungen gestellt:
• 1. Einwegeigenschaft: Zu gegebenem h(x) ist es unmöglich2 ein x0 zu finden, so dass
gilt: h(x) = h(x0 )
• 2. Einwegeigenschaft: Zu gegebenen x darf kein x0 6= x gefunden werden können, so
dass gilt: h(x) = h(x0 )
• Kollisionsfreiheit: Es ist unmöglich zwei beliebige x und x0 mit x 6= x0 zu finden, so
dass gilt: h(x) = h(x0 )
Bekannte und häufig verwendete kryptographische Hashfunktionen sind z.B. MD53 (Hash-
wertlänge 128 Bit) und SHA-14 (Hashwertlänge 160 Bit).
3.2.2 Asymmetrische Verschlüsselung
Im Gegensatz zu symmetrischen Verschlüsselungsverfahren, bei denen beide Kommunika-
tionspartner den gleichen geheimen Schlüssel benutzen um eine Nachricht zu ver- und ent-
schlüsseln, kommen beim asymmetrischen Verfahren verschiedene Schlüsselpaare zum Ein-
satz. Beide Kommunikationspartner besitzen ein eigenes Schlüsselpaar, das aus einem pri-
vaten (Private Key) und einem öffentlichen Schlüssel (Public Key) besteht. Der öffentliche
Schlüssel darf jedem zugänglich gemacht werden, der dem Besitzer des privaten Schlüssels
eine verschlüsselte Nachricht schicken möchte. Die Nachricht wird mit diesem öffentlichen
1
Secure Sockets Layer
2
Unmöglich bedeutet hierbei, das es in der Praxis unmöglich ist, d.h. die Wahrscheinlichkeit eine Lösung
zu erraten ist vernachlässigbar klein bzw. der Rechenaufwand alle Möglichkeiten auszuprobieren ist zu
groß.
3
Message-Digest Algorithm 5
4
Secure Hash Algorithm-1
14Schlüssel verschlüsselt und nur der Besitzer des privaten Schlüssels kann die Nachricht wie-
der entschlüsseln. Dabei Verhalten sich die Schlüssel eines Schlüsselpaares symmetrisch zu
einander: Ebenso kann eine mit dem privaten Schlüssel verschlüsselte Nachricht nur mit
dem zugehörigen öffentlichen Schlüssel wieder entschlüsselt werden.
Im Bereich der Internet-Security spielt das, nach seinen Entwicklern Ron Rivest, Adi
Shamir und Leonard Adleman benannte, asymmetrische Verschlüsselungsverfahren RSA
eine wichtige Rolle.[10]
3.2.3 Zertifikate
Im Zusammenhang mit asymmetrischer Verschlüsselung und Authentisierung dienen Zer-
tifikate dazu, einen öffentlichen Schlüssel eindeutig einem Eigentümer zu zuordnen. Der
Eigentümer wird mit seinem sogenannten DN1 identifiziert, der aus Angaben wie dem Na-
men, Land, Organisation (Firma) oder Emailadresse besteht. Die Zuordnung wird von einer
dritten vertrauenswürdigen Instanz zertifiziert. Dazu nimmt die Zertifizierungsinstanz, auch
CA2 genannt, den öffentlichen Schlüssel des Eigentümers, den zu diesem Schlüssel zu zuord-
nenden DN, sowie weitere verfahrenstechnische Angaben und errechnet den Hashwert aller
Daten. Dieser Hashwert wird dann von der CA mit ihrem privaten Schlüssel verschlüsselt.
Der verschlüsselte Hashwert bildet damit eine sogenannte digitale Signatur. Die ursprüng-
lichen Daten und die Signatur werden in der Zertifikatsdatei gespeichert und können an
die Kommunikationspartner weitergegeben werden. Zur Verifikation entschlüsselt der Kom-
munikationspartner die Signatur mit dem öffentlichen Schlüssel der CA und gelangt damit
an den ursprünglichen Hashwert. Danach errechnet er selbst den Hashwert dieser Daten
und vergleicht, ob beide Werte übereinstimmen. Abbbildung 3.4 macht den Vorgang etwas
anschaulicher und zeigt, wie das von der Certificate Authority für Kommunikationspartner
A erstellte Zertifikat durch B verifiziert wird.
Eine CA übernimmt damit eine Aufgabe, vergleichbar mit einer Behörde, die Ausweise
ausstellt. Die zu signierenden Daten entsprechen den persönlichen Daten des Ausweisinha-
bers, seinem Foto und seiner Unterschrift. Die Signatur wäre in diesem Fall der Stempel
der Behörde.
Ein Zertifikat kann auch nacheinander von verschiedenen Stellen signiert werden. Jede
zusätzliche Signatur bestätigt die Authentizität der direkt vorherigen. Dadurch entsteht ei-
1
Distinguished Name
2
Certificate Authority
15Abbildung 3.4: Verifizierung eines Zertifikats
ne sogenannte Zertifikatskette (Certificate Chain). Entscheidend ist, das am Ende der Kette
eine vertrauenswürdige Instanz steht. Zur Authentifizierung der ursprünglichen Daten ist
es notwendig, alle Signaturen dieser Kette in umgekehrter Reihenfolge zu verifizieren. Da
das CA Zertifikat am Ende der Kette steht, ist es von der CA selbst signiert. Die be-
sondere Funktion der CA Zertifikate macht es wichtig, diese auf einem sicheren Weg zu
erhalten. Zertifikate bekannter kommerzieller CAs wie z.B. Thawte oder VeriSign sind in
den Installationsdateien SSL fähiger Applikationen wie z.B. Internetbrowser enthalten.
3.2.4 Der X.509 Standard
X.509 ist ein von der ITU-T1 entwickelter Standard, der eine Infrastruktur zur Ausstel-
lung, Verteilung und Prüfung digitaler Zertifikate beschreibt. Außerdem spezifiziert er
einige Standard Zertifikatsformate. Für den Austausch der Zertifikate gibt es wiederum
verschiedene Dateiformate. Abbildung 3.5 zeigt ein Zertifikat im PEM2 Format, in dem
sich alle im vorherigen Abschnitt angesprochenen Elemente wiederfinden: Der DN wird in
einem X.509 Zertifikat mit Subject“ bezeichnet, der öffentliche Schlüssel folgt auf die Be-
”
zeichnung Subject Public Key Info“ und die Signatur der CA befindet sich zwischen den
”
Markern —–BEGIN CERTIFICATE—–“ und —–END CERTIFICATE—–“. Sie ist Ba-
” ”
se64 codiert. Base64 dient dazu, binäre Daten in sicher druckbaren Zeichen zu übertragen.
Dazu werden jeweils drei Bytes nebeneinander zusammengefasst und in vier Einheiten zu
1
International Telecommunication Union - Telecommunication Standardization Sector
2
Privacy Enhanced Mail
16je sechs Bits aufgeteilt. Dann wird jeder dieser Einheiten einer von 64 möglichen ASCII1
Zeichen zugeordnet.
Ein weiterer bekannter und von dem gleichnamigen Programm verwendeter Zertifikatsstan-
dard ist PGP2 . Er wird vor allem in der E-Mail Kommunikation genutzt. Im Gegensatz
zum X.509 Standard, bei der die Vertrauenswürdigkeit eines Zertifikates auf einer streng
hierarchischen Struktur mit einer zentralen Zertifizierungsinstanz basiert, benutzt PGP das
Prinzip des Web of Trust“, also ein Netz von sich gegenseitig vertrauenden Instanzen. Je-
”
der Knoten des Netzes besitzt einige wenige andere, denen er direkt vertraut. Indirektes
Vertrauen zu allen restlichen Knoten entsteht dadurch, das er diese auf einem Pfad von
sich direkt vertrauenden Knoten erreichen kann.
3.2.5 Authentisierung und verschlüsselte Kommunikation durch SSL
Das 1995 von der Netscape Communications Corporation eingeführte Sicherheitsprotokoll
SSL dient dazu, eine sichere Verbindung zwischen zwei Endpunkten im Internet herzustellen.[8]
Häufig werden die Begriffe TLS3 und SSL synonym verwendet, tatsächlich ist TLS aber
eine Weiterentwicklung des älteren SSL Protokolls. Beide erfüllen folgende Merkmale:
1. Parameterabsprache zwischen Client und Server
2. Gegenseitige Authentisierung durch X.509 Zertifikate
3. Geheime Kommunikation durch symmetrische Verschlüsselung
4. Schutz der Daten vor Manipulation durch Bildung kryptographischer Hashwerte
Wie man in Abbildung 3.6 sieht, ist SSL innerhalb des Internet Schichtenmodells zwischen
der Anwendungs- und Transportschicht einzuordnen4 . Die Authentisierung des Clients ist
optional und wird häufig nicht verwendet oder über andere Methoden wie etwa Passwor-
teingaben realisiert. Meistens möchte man nur sicherstellen, das eine im Internetbrowser
aufgerufene URL auch tatsächlich dem erwarteten Eigentümer gehört. Da innerhalb der
UnifiedXP Architektur die Identifizierung und Authentisierung des Benutzers ebenfalls
über Zertifikate erfolgt, seien im Folgenden die Vorgänge während eines SSL Handshake
1
American Standard Code for Information Interchange
2
Pretty Good Privacy
3
Transport Layer Security
4
Für gewöhnlich besteht das Internet Schichtenmodel nur aus der Anwendungs-, Transport-, Internet-
und Netzzugangsschicht. Manche Darstellungen lassen auch letztere weg. In diesem Fall wurde die
Sicherheitschicht nur der Übersicht wegen zusätzlich eingefügt.
17mit gegenseitiger Authentisierung beschrieben. Dazu lässt sich ein SSL Handshake grob in
vier Phasen unterteilen:
Phase 1 - Festlegung der Sicherheitsparameter
Client und Server verhandeln untereinander die zu verwendenden kryptographischen Algo-
rithmen. Die Menge der Algorithmen wird mit dem engl. Begriff Cipher Suite“ bezeichnet.
”
Der Client schickt zuerst eine ClientHello Nachricht mit folgendem Inhalt: SSL Versions-
nummer, vom Client unterstützte Cipher Suites, eine Session ID und eine Zufallszahl RNC1 ,
die sich aus einem 32-Bit-Wert für Zeit und Datum nach UNIX-Format und einem 28-Byte-
Zufallswert zusammensetzt. Der Server antwortet mit einer ServerHello Nachricht. Diese
beinhaltet: Die höchste von Client und Server unterstützte SSL Versionsnummer, vom Ser-
ver gewählte Cipher Suite, eine Session ID und eine Zufallszahl RNS2 , analog der vom
Client generierten.
Phase 2 - Server Authentifizierung und Schlüsselaustausch
Der Server schickt sein Zertifikat an den Client und verlangt von diesem mit einer Certifi-
cateRequest Nachricht ebenfalls die Zusendung des Client Zertifikats. Der Client verifiziert,
ob das Serverzertifikat von einer von ihm akzeptierten CA ausgestellt wurde. Eine Server-
HelloDone Nachricht des Servers schließt diese Phase ab.
Phase 3 - Client Authentifizierung und Schlüsselaustausch
Der Client schickt sein Zertifikate, welches vom Server verifiziert wird. Dieses Zertifikat
wird nochmal vom Client signiert geschickt. Dadurch kann der Server nachprüfen, das
der Client auch im Besitz des zugehörigen privaten Schlüssels ist. Schließlich generiert
der Client eine weitere Zufallszahl, das sogenannte Pre-Master-Secret (PMS). Es wird mit
dem öffentlichen Schlüssel des Server verschlüsselt und zu diesem gesendet. Aus dem Pre-
Master-Secret und den vorher ausgetauschten Zufallszahlen berechnen Client und Server
das Master-Secret (MS). Es bildet den gemeinsamen Schlüssel für die darauffolgende sym-
metrisch verschlüsselte Kommunikation.
1
Random Number Client
2
Random Number Server
18Phase 4 - Beendigung des Handshake
Abschließend senden beide Parteien eine ChangeCipherSpec und Finished Nachricht. Damit
signalisieren sie sich gegenseitig, das sie jetzt auf symmetrische Verschlüsselung wechseln.
Die Finished Nachrichten sind verschlüsselt und enthalten die in vorherigen Nachrichten
ausgetauschten MACs1 , sowie einen Hashwert. Nach der Entschlüsselung können die Hash-
werte jeweils vom Client und Server verifiziert werden.
1
Message Authentication Code
19Abbildung 3.5: Beispiel eines X.509 Zertifikats im PEM Dateiformat
20Schicht Protokoll
Anwendung HTTP, FTP, DNS
Sicherheit SSL
Transport TCP
Internet IPv4, IPv6
Netzzugang Ethernet
Abbildung 3.6: SSL im Internet Protokollstapel
Abbildung 3.7: SSL Handshake mit Client- und Server-Authentifizierung [11]
214 Entwurf
4.1 Architektur
Jedes Expertensystem benutzt eigene Klassen zur Repräsentation der Fakten. Um eine
universelle Basis zu schaffen, wurde die Klasse StoreableObject eingeführt, von denen sich
diese Klassen ableiten müssen. Diese Abstraktion ist notwendig, da außer der Daten er-
zeugenden Komponente (innerhalb der UnifiedXP Architektur DataTaking genannt) und
der Rule Engine, alle anderen Systembestandteile (inkl. der GUI) keine Kenntnis über
faktenspezifische Eigenschaften besitzen. Zu den gemeinsamen Eigenschaften aller Fakten
zählen:
• Zugehörigkeit zu einem bestimmten Benutzer
• Zeitstempel, der den Zeitpunkt der Erzeugung festhält
• eindeutiger, systeminterner Bezeichner
• boolescher Wert, der festlegt, ob das Objekt innerhalb der GUI angezeigt wird
• Bezeichnung des Objekts innerhalb der GUI
Als Bindeglied zwischen DataTaking und Rule Engine dient eine Instanz der als Single-
ton implementierten StoreableObjectsSet Klasse. Sie besitzt einen eigenen Speicher, um
zusätzlich benötigte Funktionalität zu ermöglichen. Dazu gehört z.B. das Selektieren aller
StoreableObjects eines Benutzers. Zwischen dem StoreableObjectsSet und der Rule Engine
besteht eine bidirektionale Verbindung: Einerseits werden Objekte von dem Set in das Wor-
kingMemory eingefügt oder entfernt, andererseits können Regeln neue Objekte erzeugen,
die zum Set hinzugefügt werden müssen.
4.2 Anwendungsfälle und Detailanforderungen
• Für die Netzwerkkommunikation wird das SSL Protokoll mit gegenseitiger Authenti-
sierung durch Zertifikatsdateien benutzt.
22Abbildung 4.1: Die UnifiedXP Architektur
• Client und Server akzeptieren nur Verbindungen mit Zertifikaten, die von einer ihnen
vertrauenswürdigen Zertifizierungsstellen signiert worden sind. Die zur Überprüfung
notwendigen Zertifikate der Zertifizierungstellen müssen sich in einem, in den Kon-
figurationsdateien festgelegtem Verzeichnis befinden. Zur Identifikation der Benutzer
wird der in den Zertifikaten eingetragene DN genutzt.
• Zur Unterstützung des Login Mechanismus der GUI stellt der Client Funktionen
bereit, um den DN eines Zertifikats auszulesen und um das Passwort einer privaten
Schlüsseldatei zu überprüfen.
• Es gibt eine als Administratoren ausgezeichnete Benutzergruppe, für die die GUI
zusätzliche Funktionen bietet. Ein Benutzer wird vom System als Administrator er-
kannt, wenn der DN seines Zertifikates in der Liste der Administratoren in der Ser-
verkonfigurationsdatei eingetragen ist. Es können aber nicht mehrere Benutzer gleich-
zeitig als Administrator mit dem System verbunden sein. Ist schon ein Benutzer als
Administrator angemeldet, so werden alle weiteren als normale Benutzer behandelt.
• Werden von der Daten liefernden Komponente neue Fakten zur Faktenbasis der Rule
23Engine hinzugefügt, so informiert der Server die Clients darüber. Dabei wird zwischen
Fakten unterschieden, die für alle Clients bestimmt sind, und solchen, die nur an den
jeweils betroffenen Client geschickt werden dürfen. Lösen Fakten die Aktivierung einer
Regel aus, dann werden die Clients ebenfalls darüber informiert.
• Der Client kann vom Server die aktuelle Regelbasis anfordern.
• Der Client kann dem Server eine neue Regelbasis schicken und veranlassen, das diese
gegen die alte ausgetauscht wird. Das Sequenzdiagramm in Abbildung 4.3 zeigt die
dazu nötigen Vorgänge aus Sicht des Servers.
• Der Client kann den Server veranlassen, sich zu beenden.
Abbildung 4.2: Sequenzdiagramm zum Senden einer Nachricht
24Abbildung 4.3: Sequenzdiagramm zum Austausch der Regelbasis aus Sicht des Servers
255 Implementierung
Die UnifiedXP Implementierung besteht aus zwei getrennten Softwarekomponenten: Zum
einen dem Server, der mit dem Daten liefernden Modul und der Rule Engine den eigent-
lichen Kern der Anwendung bildet, und zum anderen aus dem Client, der von der GUI
Applikation für die Kommunikation mit dem Server genutzt wird. Diese stellt die Benut-
zerschnittstelle dar.
5.1 Die SSL Infrastruktur
Zu den Elementen einer auf SSL basierten Kommunikation, gehören neben dem eigentli-
chen Kommunikationsprotokoll auch die zur Authentisierung notwendigen Zertifikate und
privaten Schlüssel. Die Trust- und KeyManager Klassen bilden die Schnittstelle zu den
Zertifikats- und Schlüsseldaten.
5.1.1 Trust- und KeyManager
Standardmäßig nutzt Java zur Speicherung der Zertifikate und privaten Schlüssel jeweils
ein eigenes Dateiformat. Die vertrauenswürdigen Zertifikate werden aus der als TrustStore
bezeichneten Datei gelesen, das eigene Zertifikat und der dazugehörige private Schlüssel
sind in der sogenannten KeyStore Datei hinterlegt. Um die Nutzung von Zertifikats- und
Schlüsseldateien im PEM Dateiformat zu ermöglichen, war es notwendig eigene Imple-
mentierungen des Trust- und KeyStore zu verwenden. Die Klasse, die die Verwaltung der
vertrauenswürdigen Zertifikate übernimmt, muss dazu das X509TrustManager Interface im-
plementieren. Für die Bereitstellung der privaten Schlüsseldaten ist das X509KeyManager
Interface verantwortlich. Für das Lesen der PEM Dateien habe ich die unter einer Pu-
blic Domain Lizenz veröffentlichte Bouncy Castle Crypto Library verwendet.[5] Das ist
eine in Java und C# geschriebene Bibliothek, die neben der eigenen Implementierung ver-
schiedenster kryptographischer Algorithmen, zusätzlich Unterstützung bei der Erzeugung
26Abbildung 5.1: Die Trust- und KeyManager Klassen
und Verarbeitung von X.509 Zertifikaten bietet. In Javas Kryptographie Architektur wer-
den diese Algorithmen in einem Cryptographic Service Provider zusammengefasst und zur
Verfügung gestellt. Die Bouncy Castle Crypto Library macht von der Möglichkeit Ge-
brauch, den Standard Service Provider gegen eine eigene Implementierung auszutauschen.
Dazu sind aber einige Konfigurationen in der Java Installation vorzunehmen, für die der
Nutzer der UnifiedXP Architektur möglicherweise nicht die nötigen Rechte besitzt. Da die
PEMReader Klasse den eigenen Provider nutzt, war es notwending, eine in diesem Punkt
veränderte Version zu implementieren, die auf den Java Standard Provider zurückgreift.
5.2 Das Kommunikationsprotokoll
Um ein Netzwerkprotokoll zu implementieren gibt es vielfältige Möglichkeiten. Die Pro-
grammiersprache Java bietet dazu mit seinen Systembibliotheken Unterstützung auf ver-
schiedenen Abstraktionsleveln. Im folgenden Abschnitt werden zunächst mögliche Alterna-
tiven dargestellt, um dann die tatsächliche Realisierung zu beschreiben.
Wenn die Anforderungen ein möglichst kompaktes Format erfordern, bei dem zur Struktu-
rierung der Nutzdaten nur wenige zusätzliche Bytes erforderlich sind, dann bietet sich die
27Codierung im TLV1 Format an. Dabei wird zuerst eine konstante Anzahl Bytes übertragen,
die den Typ und die Länge der nachfolgenden Daten angeben, gefolgt von einer variablen
Anzahl Bytes, die die eigentlichen Nutzdaten beinhalten. Die Java Input-/OutputStream
Klassen bieten dafür Methoden, mit denen Bytearrays direkt gelesen bzw. geschrieben
werden können. Dieses Format ist sehr einfach zu parsen und lässt sich auch problemlos er-
weitern. Nicht benötigte oder unbekannte Datenblocktypen können mit Hilfe der Angaben
in den Längenfeldern sehr einfach übersprungen werden. Ein Nachteil ist, das dieser Parser
selbst implementiert werden muss. Ausserdem ist dieses Format für Menschen nicht leicht
zu lesen, was im Fall der Fehlersuche ein weiter Nachteil ist. Dazu müssten dann zusätzliche
Debuggingtools geschrieben werden, etwa in Form von PlugIns für den Netzwerk Protokoll
Analyzer Wireshark.
Abbildung 5.2: TLV Dateiformat
Ist die Optimierung des Verhältnisses von Nutz- zu Gesamtdaten kein primäres Ziel und
steht die Lesbarkeit der übertragenen Daten im Vordergrund, so bietet sich das XML2
Format an. Abbildung 5.3 zeigt ein Beispiel für eine solche Datei. Java unterstützt dieses
Format mit den DocumentBuilder und Document Klassen aus dem javax.xml.parsers und
org.w3c.dom Packages. XML Dateien werden durch Instanzen der Document Klasse re-
präsentiert, die ein komfortables Auslesen und Manipulieren der Datenstruktur ermöglicht.
Zum Lesen der Daten, aus dem Netzwerk oder einer Datei, kann der parse() Methode
der DocumentBuilder Klasse eine InputStream Instanz übergeben werden. Zurückgeliefert
wird ein Document Objekt im XML Format. Für das Serialisieren und Schreiben in einen
OutputStream sorgt die XMLSerializer Klasse. XML zur Strukturierung der Daten eines
Netzwerkprotokolls zu verwenden ist sicherlich eine gute Wahl, wenn es eine enge Verzah-
nung zwischen der Netzwerkkommunikation und Dateiaustausch mit anderen Programmen
gibt. XML ist ein häufig genutzter Industriestandard für den es viele Tools zur Dateierzeu-
gung und Verarbeitung gibt.
Die einfachste und letztendlich gewählte Methode, Netzwerkkommunikation in den Pro-
1
Type Length Value
2
eXtensible Markup Language
28Abbildung 5.3: Beispiel XML Datei
grammfluss zu integrieren, bieten die Klassen ObjectOutputStream und ObjectInputStream.
Sie sorgen für die Serialisierung bzw. Deserialisierung eines Java Objektes, wodurch dieses
direkt geschrieben bzw. gelesen werden kann. Einzige Anforderung an das Objekt ist, das
seine Klasse und rekursiv alle Klassen der Membervariablen das Marker-Interface Serializ-
able implementieren.
5.2.1 Die Nachrichtenklassen
Die Oberklasse aller Netzwerknachrichten ist die Message Klasse. Sie ist sehr einfach ge-
halten und enthält als Membervariablen nur einen String und den Aufzählungstypen Com-
mand. Letzterer gibt die Semantik der Nachricht an, an Hand dessen im Programmfluss
entschieden werden muss, ob auf eine Unterklasse zu casten ist. Die Klassenhierarchie ist
in Abbildung 5.4 dargestellt.
29Abbildung 5.4: UML Klassenhierarchie Messages
Im Folgenden werden alle Nachrichtenklassen mit ihren möglichen Command Werten auf-
gelistet und die daraus resultierende Bedeutung und Verwendungszweck erklärt:
30Message
INFO CONNECTED AS ADMIN Informiert den Client, das er als Admin verbunden
ist. Der Server vergleicht dazu, ob der DN des Cli-
ents in der Konfigurationsdatei in der Liste der Ad-
mins steht. Außerdem darf nicht schon ein anderer
als Admin angemeldet sein. Sollte das der Fall sein,
so wird er als normaler Benutzer behandelt.
INFO CONNECTED AS USER Informiert den Client, das er als normaler Benutzer
verbunden ist.
SHUTDOWN SERVER Wird vom Client (Admin) gesendet, um den Server
herunterzufahren.
CLIENT DISCONNECT Client hat die Verbindung getrennt. Ist eine interne
Nachricht, die nicht über das Netzwerk geschickt
wird.
SERVER DISCONNECT Server hat die Verbindung getrennt. Ist eine interne
Nachricht, die nicht über das Netzwerk geschickt
wird.
GET EDITED RULES Client (Admin) fordert alle editierten Regeln an.
GET ACTIVATIONS Client fordert alle Aktivierungen an.
GET UPDATE ALL Diese Nachricht wird nach der Anmeldung oder ei-
nem Server-Reset vom Client geschickt. Damit si-
gnalisiert er, das er alle bis dahin gesammelten Da-
ten geschickt bekommen möchte.
GET UPDATE Nach einer GET UPDATE ALL Nachricht werden
hiermit alle neuen Daten angefordert. Sie wird re-
gelmäßig vom Client geschickt.
GET RULE BASE Client (Admin) fordert die aktuelle Regel Basis an.
RESET Mit dieser Nachricht informiert der Server die Cli-
ents darüber, das sich etwas substanziell wichtiges
geändert hat, wie etwa die Regel Basis. Alle Clients
müssen dann nochmal die selbe Prozedur wie bei
einer Anmeldung durchlaufen.
31ActivationsMessage
ACTIVATIONS Antwort des Servers auf eine GET ACTIVATIONS Nachricht.
Enthält alle Aktivierungen in Form einer Liste von SimpleAc-
tivationAbstraction Objekten.
DataMessage
UPDATE ALL Antwort des Servers auf eine GET UPDATE ALL Nachricht.
Enthält Daten in Form eines StoreableObject Vektor.
UPDATE Antwort des Servers auf eine GET UPDATE Nachricht.
Enthält Daten in Form eines StoreableObject Vektor.
RulesMessage
Nicht verwendet. Dient als Basisklasse für EditedRulesMessage, EditedRule-
BaseMessage und RuleBaseMessage. Enthält eine Liste von
SimpleRuleAbstraction Objekten.
EditedRulesMessage
EDITED RULES Wird vom Server und Client benutzt, um editierte Regeln zu
senden.
EditedRuleBaseMessage
EDITED RULE BASE Client (Admin) sendet die editierte Regel Basis.
RuleBaseMessage
RULE BASE Server sendet die aktuelle Regel Basis. Enthält zusätzlich die
Regeln separiert nach WENN und DANN Teil (LHS-/RHS
Statements).
SalienceMessage
UPDATE SALIENCE Wird vom Client (Admin) an den Server geschickt. Enthält den
neuen Salience Wert für eine Regel.
325.3 Der Server
Abbildung 5.5: UML Server und ClientHandler
5.3.1 Der ClientHandler
Die ClientHandler Klasse repräsentiert jeweils eine bestehende Verbindung zu einem Client.
Über sie werden Nachrichten zum Server geschickt und empfangen. Das Empfangen der
Nachrichten geschieht dabei in einem eigenen Thread.
5.3.2 Der Sendecache
Im Zusammenspiel mit der GUI ergab sich beim Pixel Advisor das Problem, das zu viele
neue Daten vom Server geschickt wurden, bevor die alten von der GUI verarbeitet und
dargestellt waren. Es wurde erforderlich, von einer asynchronen auf eine synchrone Sende-
strategie zu wechseln. Der Server schickt neue Daten nur, wenn der Client diese explizit
anfordert. Zusätzlich wurde der Datenverkehr reduziert.
Der Sendecache wird von der MessageSendQueue Klasse realisiert. Grundsätzlich besteht
sie aus einer, in einem eigenen Thread laufenden run() Methode und den Listen der zu
sendenden Nachrichten. Es gibt zwei Arten von Listen: Eine für die Update Nachrichten
(das sind DataMessage Objekte mit Command Attribut auf UPDATE gesetzt) und eine
33für alle anderen. Diese Aufteilung ist notwendig, da die Update Nachrichten, im Gegensatz
zu den anderen, nicht einfach an die Liste der noch zu sendenden Nachrichten angehängt
werden. Es wird erst verglichen, ob sich eine Update Nachricht im Cache befindet, dessen
StoreableObject den gleichen Key hat. Ist das der Fall, so wird das alte StoreableObject
mit den Werten des neuen aktualisiert. Nur wenn sich keine Daten mit dem gleichen Key
finden, wird die neue Nachricht an die Liste angehängt.
Damit der Sendevorgang und das Hinzufügen neuer Nachrichten von einander entkoppelt
ist, gibt es jede Nachrichtenliste zweimal. Sobald der Thread alle ausstehenden Nachrichten
verschickt hat, schaltet er um. Die alte Warteliste wird zur neuen Sendeliste und umge-
kehrt. Gäbe es jede Liste nur einmal, dann könnte ein langsamer Empfänger, bei einem
synchronisierten Zugriff auf eine Liste, den Server blockieren.
Jeder Zyklus bestehend aus Abarbeiten/Verschicken wartendender Nachrichten und Um-
schalten zwischen den Listen beinhaltet auch die Akquirierung einer Semaphore. Über
diesen Mechanismus wird der Thread blockiert, wenn sich keine Nachrichten in den War-
teschlangen befinden.
345.4 Der Client
Die Client Klasse ist die Schnittstelle zwischen der GUI Applikation und dem Netzwerk. Sie
ist für das Herstellen der Verbindung und die Kommunikation mit dem Server zuständig.
Das Empfangen der Server Nachrichten läuft in einem eigenen Thread, der von der inneren
Klasse MessageReceiver erzeugt wird. Diese wird bei jeder Verbindung zum Sever neu
erzeugt. Das ist notwending, da Java Threads nicht beendet und dann wieder gestartet
werden können.
Abbildung 5.6: UML Client
356 Anpassung des GridXP
Expertensystems an die UnifiedXP
Architektur
Die von GridXP verarbeiteten Fakten werden durch die Klassen Job, Error und Solution
repräsentiert. Sie bilden durch ihre Bedeutung in der realen“ Welt eine Baumstruktur, die
”
sich auch in den Klassen wiederspiegelt:
• Ein Job kann aus mehreren Gründen fehlschlagen ⇒ eine Job Instanz kann mehrere
Error Referenzen besitzen.
• Zur Behebung eines Fehlers gibt es unter Umständen vielfältige Lösungsvorschläge
⇒ eine Error Instanz kann mehrere Solution Referenzen besitzen.
Diese Datenstruktur wird von den StoreableObjects durch die Methoden get-/setParent(),
addChild() und getChildren() unterstützt, mit denen sich die Objekte zueinander in Bezie-
hung setzen lassen. Dieser Mechanismus ist auch die einzige Möglichkeit die GUI darüber zu
informieren, wie die Daten in der Darstellung angeordnet werden sollen, da sie die Exper-
tensystem spezifische Domäne bzw. die speziellen Eigenschaften ihrer Faktenklassen nicht
kennt.
Die Klassen Job, Error und Solution besitzen zusätzliche Membervariablen, deren Werte
von der GUI dargestellt werden sollen. Um das zu realisieren, müssen die Werte in Form
eines StoreableObject über die addChild() Methode an das Elternobjekt“ angehängt wer-
”
den. Abbildung 6.1 zeigt die Darstellung eines Jobs in der GUI. Man sieht die Member-
variablen VO, UI, WMS, CE, sowie ein Error Objekt, das wiederum ein Description und
zwei Solution Objekte besitzt.
Die für die Membervariablen erforderlichen StoreableObjects müssen erzeugt, verknüpft
und in das StoreableObjectsSet eingefügt werden. Das Einfügen der Kinder“ sollte möglichst
”
erst nach dem Einfügen der Eltern“ erfolgen. Um die Verantwortung für diese Vorgänge
”
innerhalb der entsprechenden Klasse zu behalten, entschied ich mich für die Anwendung
36Abbildung 6.1: UnifiedXP GUI Client
des Visitor-Pattern durch eine insert() Methode. Um eine spezialisierte Implementation
in abgeleiteten Klassen zu garantieren, muss diese abstrakt sein. Das Erweitern der Klas-
se StorableObject um diese abstrakte Methode hätte eine unnötige Anpassung sämtlicher
Unterklassen bedeutet, weshalb ich die Einführung einer weiteren Klasse ExtendedStora-
bleObject beschloss, siehe Abbildung 6.2.
Abbildung 6.2: UML GXDataTaking
Um GridXP auf die Benutzung der UnifiedXP Architektur umzustellen, waren folgende
Schritte durchzuführen:
37• Ableiten der Klassen Job, Error und Solution von ExtendedStoreableObject und im-
plementieren der jeweiligen insert() Methoden.
• Innerhalb der RGMAConsumer Basisklasse musste die insertItem() Methode geändert
werden, so dass neu erzeugte Job Objekte durch ihre insert() Methode in das Storeable-
ObjectsSet eingefügt werden.
• Anpassung der Regeln, die für das Erstellen der Error und Solution Instanzen verant-
wortlich sind, damit diese ebenfalls mit Hilfe der insert() Methode in das Storeable-
ObjectsSet gelangen.
387 Fazit und Ausblick
Rückblickend ist das im Rahmen meiner Bachelorarbeit entstandene Softwareprodukt als
voller Erfolg anzusehen. Es konnten alle der gestellten Anforderungen erfüllt werden. Den-
noch sind auch nach Fertigstellung des Projekts noch vielfältige Ergänzungen des Systems
denkbar:
• Erweiterte Benutzergruppenverwaltung
• Implementation eines Statistikmoduls zur Auswertung von Serverauslastung, Da-
tenübertragungsraten etc.
• Unterstützung zusätzlicher Zertifikatsdateiformate
• Entwicklung eines GUI Client als Java Applet
Die Tatsache, dass diese Erweiterungen überhaupt in Betracht gezogen werden können,
basiert auf der gut durchdachten Konzeption und sorgfältigen Implementation. Dafür Aus-
schlag gebend war beispielsweise eine exakte Analyse der Gemeinsamkeiten der zu ver-
einheitlichenden Systeme, sowie der allgemeingültig ausgelegte Aufbau der Komponenten.
Somit wird erst durch eine einfach gehaltene Schnittstelle zwischen der UnifiedXP Archi-
tektur und den Daten erzeugenden Komponenten eine Ausweitung des Einsatzgebietes auf
andere Fachdomänen möglich.
Zusätzlich zu den fachlichen Aspekten stellen die während der Realisierung des Projekts
gemachten Erfahrungen auch eine persönliche Bereicherung dar. Meine Bachelorarbeit bot
mir die Möglichkeit, Einblick in die Anwendungsfelder der beiden Expertensysteme zu
nehmen. Durch GridXP habe ich die Welt des Grid Computing kennengelernt, über den
Einsatzbereich des Pixel Advisor in der Experimentalphysik konnte ich sogar direkt vor
Ort, während meines Aufenthalts am CERN, mehr erfahren.
39Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit und die zugehörige Implementierung
selbstständig angefertigt und dabei nur die angegebenen und bei Zitaten kenntlich gemach-
ten Quellen und Hilfsmittel benutzt habe.
Steinfurt, 19. September 2008
Unterschrift
iiAbbildungsverzeichnis
1.1 Der ATLAS Detektor [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Der Pixeldetektor [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Datenquelle Pixel Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Datenquellen GridXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Bestandteile eines regelbasierten Expertensystems . . . . . . . . . . . . . . . . . . 11
3.2 Die JBoss Rules/Drools Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Beispiel für eine Regeldatei und UML Diagramm der verwendeten Klasse . . . . . 13
3.4 Verifizierung eines Zertifikats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Beispiel eines X.509 Zertifikats im PEM Dateiformat . . . . . . . . . . . . . . . . . 20
3.6 SSL im Internet Protokollstapel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 SSL Handshake mit Client- und Server-Authentifizierung [11] . . . . . . . . . . . . 21
4.1 Die UnifiedXP Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Sequenzdiagramm zum Senden einer Nachricht . . . . . . . . . . . . . . . . . . . . 24
4.3 Sequenzdiagramm zum Austausch der Regelbasis aus Sicht des Servers . . . . . . . 25
5.1 Die Trust- und KeyManager Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 TLV Dateiformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Beispiel XML Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 UML Klassenhierarchie Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5 UML Server und ClientHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6 UML Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1 UnifiedXP GUI Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 UML GXDataTaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
iiiAbkürzungsverzeichnis
ALICE . . . . . . . . . . . . . . . . A Large Ion Collider Experiment
ASCII . . . . . . . . . . . . . . . . American Standard Code for Information Interchange
ASL . . . . . . . . . . . . . . . . . . Apache Software License
ATLAS . . . . . . . . . . . . . . . A Toroidal LHC ApparatuS
CA . . . . . . . . . . . . . . . . . . . Certificate Authority
CERN . . . . . . . . . . . . . . . . Conseil Européen pour la Recherche Nucléaire (Europäische Organisa-
tion für Kernforschung)
CMS . . . . . . . . . . . . . . . . . . Compact Muon Solenoid
DIM . . . . . . . . . . . . . . . . . . Distributed Information Management
DN . . . . . . . . . . . . . . . . . . . Distinguished Name
FSM . . . . . . . . . . . . . . . . . . Finite State Machine
GUI . . . . . . . . . . . . . . . . . . Graphical User Interface
ITU-T . . . . . . . . . . . . . . . . International Telecommunication Union - Telecommunication Standar-
dization Sector
JEM . . . . . . . . . . . . . . . . . . Job Execution Monitor
LGPL . . . . . . . . . . . . . . . . . Lesser General Public License
LHC . . . . . . . . . . . . . . . . . . Large Hadron Collider
LHCb . . . . . . . . . . . . . . . . . Large Hadron Collider beauty
LHCf . . . . . . . . . . . . . . . . . Large Hadron Collider f orward
MAC . . . . . . . . . . . . . . . . . Message Authentication Code
MD5 . . . . . . . . . . . . . . . . . . Message-Digest Algorithm 5
MS . . . . . . . . . . . . . . . . . . . Master-Secret
PEM . . . . . . . . . . . . . . . . . . Privacy Enhanced Mail
PGP . . . . . . . . . . . . . . . . . . Pretty Good Privacy
PMS . . . . . . . . . . . . . . . . . . Pre-Master-Secret
PVSS . . . . . . . . . . . . . . . . . Prozessvisualisierungs- und Steuerungssystem
R-GMA . . . . . . . . . . . . . . . Relational Grid Monitoring Architecture
RNC . . . . . . . . . . . . . . . . . . Random Number Client
RNS . . . . . . . . . . . . . . . . . . Random Number Server
RSA . . . . . . . . . . . . . . . . . . Ron Rivest, Adi Shamir und Leonard Adleman
SAM . . . . . . . . . . . . . . . . . . Service Availability Monitoring
SHA-1 . . . . . . . . . . . . . . . . Secure Hash Algorithm-1
SSL . . . . . . . . . . . . . . . . . . . Secure Sockets Layer
TLS . . . . . . . . . . . . . . . . . . Transport Layer Security
TLV . . . . . . . . . . . . . . . . . . Type Length Value
ivTOTEM . . . . . . . . . . . . . . TOTal Elastic and diffractive cross section Measurement
XML . . . . . . . . . . . . . . . . . . eXtensible Markup Language
vLiteraturverzeichnis
[1] CERN: The ATLAS Experiment. http://atlas.ch/photos/index.html, 2008.
[2] Free Software Foundation Inc.: GNU Lesser General Public License Version 3. http:
//www.gnu.org/licenses/lgpl.html, 2007.
[3] ITU-T, Telecommunication Standardization Sector of ITU: Recommendati-
on X.509. http://www.itu.int/rec/dologin.asp?lang=e&id=T-REC-X.509-200508-I!
!PDF-E&type=items, 2005.
[4] jboss.org: JBoss Rules/Drools Documentation. http://www.jboss.org/drools/
documentation.html, 2008.
[5] Legion of the Bouncy Castle: The Bouncy Castle Crypto Library. http://
bouncycastle.org/index.html, 2008.
[6] Schneier, Bruce: Applied Cryptography: Protocols, Algorithms, and Source Code in C.
John Wiley & Sons, Inc., Zweite Auflage, 1996.
[7] Sun Microsystems Inc.: Java Object Serialization Specification Version 1.5.0. http://
java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/protocol.html, 2004.
[8] Tanenbaum, Andrew S.: Computer Networks. Prentice Hall, Vierte Auflage, 2003.
[9] The ATLAS Collaboration: The ATLAS Experiment at the CERN Large Hadron Colli-
der. http://www.iop.org/EJ/abstract/1748-0221/3/08/S08003, 2008.
[10] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest: Introduction To Al-
gorithms. The MIT Press, Erste Auflage, 1993.
[11] Wikipedia: Transport Layer Security — Wikipedia, Die freie Enzyklopädie. http://de.
wikipedia.org/w/index.php?title=Transport_Layer_Security&oldid=49754929, 2008.
[Online; Stand 20. August 2008].
viSie können auch lesen
