Verteilte Informationsstrukturen zur modernen - Das IICM

Transcription

Verteilte Informationsstrukturen zur
modernen Wissensauffindung im Internet
Untersuchungen und Testimplementierung von
standardisierten Übertragungsmechanismen für das
xFIND System
Wilfried Lackner
Verteilte Informationsstrukturen zur
modernen Wissensauffindung im Internet
Untersuchungen und Testimplementierung von
standardisierten Übertragungsmechanismen am xFIND System
Diplomarbeit
an der
Technischen Universität Graz
vorgelegt von
Wilfried Lackner
Institut für Informationssysteme und Computer Medien (IICM)
Technische Universität Graz
A-8010 Graz, Österreich
Dezember 2004
© Copyright 2004, Wilfried Lackner
Diese Arbeit ist in deutscher Sprache verfasst.
Begutachter: o.Univ.-Prof. Dr. Dr.h.c.mult. Hermann Maurer
Betreuer: Dipl.-Ing. Dr.tech. Christian Gütl
Distributed Informationstructure of Modern
Information Retrieval Systems
Analysis and Testimplementation of standardised
Datatransfermechanism for the xFIND System
Master’s Thesis
at
Graz University of Technology
submitted by
Wilfried Lackner
Institut for Information System and Computer Media (IICM)
Graz University of Technology
A-8010 Graz, Austria
December 2004
© Copyright 2004, Wilfried Lackner
This Thesis is written in german language.
Advisor: o.Univ.-Prof. Dr. Dr.h.c.mult. Hermann Maurer
Supervisor: Dipl.-Ing. Dr.tech. Christian Gütl
Kurzfassung
Wissensauffindung im Internet kann grundsätzlich über verschiedene Möglichkeiten
realisiert werden. Der Zugriff auf das verteilte Wissen erfolgt jedoch meist unstrukturiert
unter Nutzung verschiedener Suchfunktionen. Im WWW erfolgt die Suche nach
Information mit Hilfe von Suchmaschinen. Aufgrund des stetig steigenden
Datenvolumens können herkömmliche Suchmaschinen oft keine brauchbaren Antworten
mehr liefern. Ein großer Anteil des Wissens steckt zudem im nicht indizierten DeepWeb.
Information in verschiedenen Formaten, Medien oder Sprachversionen erschweren
zudem die Suche. Um nun gezielt nach Informationen suchen zu können, bedarf es
deshalb zusätzlicher Aufwände. Das Anreichern der Information mit Metadaten
erleichtert z.B. eine spezifische Datensuche. Das xFIND System versucht insbesondere in
diesem Bereich der Informationsauffindung mögliche Problembereiche zu verbessern.
xFIND ist eine verteilte Sucharchitektur mit der vordefinierte Quellen, themenspezifisch
durchsucht werden können. Die xFIND Kommunikations-schnittstellen sind nicht
standardisiert und besitzen kein modernes Sicherheitskonzept. Ziel dieser Arbeit ist es,
Vorschläge zur Verbesserung der xFIND Kommunikationsschicht im Bereich der
Datenübertragung, Modulanbindung und Verwaltung mit Hilfe standardisierter Protokolle
und Methoden zu erstellen.
Im Untersuchungsteil dieser Arbeit werden Problembereiche verteilter Informationsstrukturen und verteilter Anwendungen dargestellt. Vor- und Nachteile verschiedener
verteilter Topologien liefern zusätzliche Informationen für eine eingehende Analyse
verteilter Architekturen. Neue Ideen und konzeptionelle Ansätze können aus
Architekturformen wie z.B. offenen und dezentralen Peer-to-Peer Netzwerken, die sich
verstärkt im Internet verbreiten, gewonnen werden. Viele bestehende Lösungen aus dem
Bereich der Middleware Applikationen setzen vorwiegend standardisierte Schnittstellen
ein. Eine Analyse diverser standardisierter Dienste und Transportprotokolle für verteilte
Suchsysteme bildet die Basis für weitere Untersuchungen an der xFIND
Übertragungsschicht.
Um Vorschläge zur Verbesserung der xFIND Kommunikationsschnittstellen erstellen
zu können, wird im Gestaltungsteil eine eingehende Analyse der xFIND
Systemarchitektur durchgeführt. Zu Testzwecken wird das Übertragungsverhalten einer
xFIND Client-Server Kommunikation unter Nutzung einer Testimplementierung
simuliert. Mit diesem Simulationsaufbau werden Benchmarkwerte erstellt, um
vergleichbare Analyseergebnisse mit anderen Technologien zu gewinnen. In weitere
Folge werden zwei Technologien näher untersucht und Prototypen für eine verbesserte
Kommunikationsarchitektur für das xFIND System implementiert. So findet BEEP im
Bereich der Datenübertragung und das JXTA Protokollframework für den Bereich der
automatisierten Verwaltung im Gestaltungsbereich seine Anwendung. Mit Hilfe dieser
Prototypen werden spezifische Kennwerte der jeweiligen Technologien erstellt und mit
den Ergebnissen von xFIND verglichen. Den Abschluss des Gestaltungsteiles bildet eine
Übersicht an möglichen Vorschlägen und neuen Ideen zur Verbesserung bzw.
Erweiterung des xFIND Systems.
Abstract
Information retrieval in the Internet can in principle be realized in miscellaneous
ways. However, access to distributed knowledge often occurs in unstructured fashion
through the use of different search methods. In case of the WWW, the search for
information is carried out by means of search engines. Because of the constantly rising
quantity of data, conventional search engines often provide no useful answers.
Furthermore, a large portion of knowledge resides in the un-indexed DeepWeb.
Information storage in different formats, media or language versions additionally
complicate the retrieval process. In order to be able to look for purposeful information
additional methods are required. For example, providing information with metadata
facilitates a specific data search. The xFIND system introduced in this work tries to
present some solutions as to how these problems of information retrieval could be
prevented. xFIND is a distributed search architecture which enables a topic-specifical
search in pre-defined resources. The xFIND communication interfaces are not
standardized and have no modern security concept. The goal of this thesis is to find some
suggestions for the improvement of the xFIND communication layer in the range of the
data communication, the module binding and the module administration with the help of
standardized protocols and methods.
The theoretical section of this thesis tries to present problem areas of distributed
information structures and distributed applications. Pro and cons of different distributed
topologies give additional information for a detailed analysis of distributed architectures.
New ideas and conceptional approaches can be extracted from new architecture forms
such as open and decentralized peer-to-peer networks which increasingly spread in the
Internet. Many existing solutions from the area of middleware applications use
predominantly standardized interfaces. An analysis of various standardized services and
transport protocols for distributed searching systems forms the base for further
investigations at the xFIND communication layer.
In order to be able to provide suggestions concerning the improvement of the xFIND
communication interfaces, a detailed analysis of the xFIND architecture is accomplished
in the practical section of this thesis. In order to get comparable results of the xFIND
transient characteristic a simulation test of the xFIND Client Server communication has
been implemented. With this test simulation, benchmark values are provided for future
analysis. Furthermore, two technologies are closely investigated and implemented as
prototypes to achieve improvements for the xFIND communication architecture. In this
way, BEEP will be tested in the practical section in the area of data communication and
the JXTA protocol framework in the range of automated administration. With the help of
special test implementations, the characteristic values of the respective technologies are
provided and compared with the results of the xFIND system. The conclusion of the
practical section is an overview of possible suggestions and new ideas for the
improvement and extension of the xFIND search system.
Ich versichere hiermit, diese Arbeit selbständig verfasst, andere als die angegebenen
Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfs-mittel
bedient zu haben.
I herby certify that the work presented in this thesis is on my own and the work performed
by others is appropriately cited.
Danksagung
Mein Dank gilt den Mitarbeitern des IICM um Herrn Prof. Dr. Dr. hc. mult. Hermann
Maurer für die Unterstützung in administrativen Angelegenheiten, sowie meinen
Kollegen in der Web Application Group (WAG) die mich stets ermutigt haben und von
deren Wissen ich sehr viel profitieren konnte.
Insbesondere danken möchte ich meinem Diplomarbeits Betreuer, Herrn Dipl.-Ing.
Dr.tech. Christian Gütl, der mich durch zahlreiche Anregungen, Ratschläge und viel
Geduld bei der Erstellung dieser Arbeit unterstützt hat.
Der größte Dank gilt meiner Frau Anita, die mich auch in schwierigen Zeiten immer
motiviert hat und mir vor allem beim Korrekturlesen eine große Hilfe war.
Schon ein Sprichwort sagt:
"Ein Mann muss in seinem Leben einen Sohn (Clemens & Paul) zeugen, ein Haus bauen,
einen Baum pflanzen und ein Buch schreiben."
Ich habe diese Reihenfolge strikt eingehalten, was sich naturgemäß auf die
Erstellungsdauer der vorliegenden Arbeit niedergeschlagen hat. Die Bedeutung hinter
diesem Sprichwort sagt aber doch viel mehr aus.
"Gib das Leben, das du ohne dein Zutun empfangen hast weiter und sorge zusätzlich
dafür, dass dein Kind ein Dach über dem Kopf hat. Arbeite nicht nur für dich und deine
Familie, sondern tue etwas für die Zukunft der Allgemeinheit. Du weißt zwar nicht, wer in
200 Jahren unter deinem Baum sitzen wird, aber mit dem Pflanzen des Baumes tust du
etwas für deine Nachwelt. Behalte deine Gedanken nicht für dich, sondern schreibe sie
auf. Du weißt zwar nicht, wer dein Buch einmal lesen wird, aber du hast etwas
hinterlassen, was ein Baustein im Denken eines anderen Menschen sein könnte." von
Armin Assmann aus dem Buch „der Erntewagen“
Danke Annemarie und Ferdinand, dass ich all die eben erwähnten Dinge ohne größere
Probleme vollbringen konnte.
Inhaltsverzeichnis:
1. Einleitung...................................................................................................................... 1
1.1.
1.2.
Motivation......................................................................................................................... 1
Strukturierung der Arbeit .................................................................................................. 3
I Untersuchungsbereich ........................................................5
2. Einführende Betrachtungen........................................................................................ 7
2.1.
2.2.
2.3.
2.4.
Einleitung.......................................................................................................................... 7
Informationsaufkommen im Internet ................................................................................ 7
Resource Discovery ........................................................................................................ 10
Schlussbemerkung .......................................................................................................... 11
3. Verteilte Informationsstrukturen............................................................................. 13
3.1.
3.2.
3.3.
3.4.
3.5.
Einleitung........................................................................................................................ 13
Begriffsbestimmungen .................................................................................................... 13
Architekturen verteilter Informationsstrukturen ............................................................. 15
3.3.1. Anforderungen an verteilte Informationsstrukturen: ......................................... 17
3.3.2. Anwendungen für verteilte Datenverwaltung.................................................... 18
Remote Procedure Call in der Kommunikationsschicht ................................................. 20
4. Verteilte Anwendungen ............................................................................................. 25
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
Einleitung........................................................................................................................ 25
Topologien verteilter Anwendungen............................................................................... 26
Transaktionen.................................................................................................................. 30
Verteiltes Dateisystem .................................................................................................... 33
4.4.1. Network File System NFS................................................................................. 33
4.4.2. Andrew File System .......................................................................................... 33
Objektorientiertes verteiltes System - Komponentenarchitektur..................................... 36
Client-Server versus Peer-To-Peer.................................................................................. 41
Middleware als Basiskomponente für verteilte Anwendungen....................................... 43
4.7.1. Allgemeine Betrachtung .................................................................................... 44
4.7.2. DCE ................................................................................................................... 45
4.7.3. COM.................................................................................................................. 48
4.7.4. DCOM ............................................................................................................... 51
4.7.5. .NET .................................................................................................................. 54
4.7.6. mono::................................................................................................................ 56
4.7.7. Java 2 Plattform - J2EE ..................................................................................... 56
4.7.8. Open Net Environment - ONE .......................................................................... 59
4.7.9. Dino - Dinopolis ................................................................................................ 62
Web Service Architektur (WSA) .................................................................................... 66
4.8.1. UDDI ................................................................................................................. 67
4.8.2. WSDL................................................................................................................ 69
5. Transport Protokolle ................................................................................................. 73
5.1.
5.2.
5.3.
5.4.
Standardisierung ............................................................................................................. 73
Allgemeines .................................................................................................................... 76
Z39.50 ............................................................................................................................. 77
XML-Grundlagen ........................................................................................................... 79
5.4.1. DOM.................................................................................................................. 79
5.4.2. SAX ................................................................................................................... 80
5.4.3. DTD................................................................................................................... 80
5.4.4. XML-Schema .................................................................................................... 80
5.4.5. XSLT - Stylesheets............................................................................................ 81
5.4.6. XML Verknüpfungstechnologien: XLink / XPointer / XPath ........................... 81
5.4.7. XHTML............................................................................................................. 81
5.5. BEEP............................................................................................................................... 82
5.6. XML-RPC....................................................................................................................... 84
5.7. ebXML............................................................................................................................ 85
5.8. SOAP .............................................................................................................................. 86
5.9. Jabber .............................................................................................................................. 89
5.10. JXTA Protokolle ............................................................................................................. 92
5.11. Schlussbemerkung .......................................................................................................... 94
6. Verteilte Suchsysteme................................................................................................ 97
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
Freenet ............................................................................................................................ 97
FASD ............................................................................................................................ 100
JXTA............................................................................................................................. 101
Harvest .......................................................................................................................... 105
xFIND ........................................................................................................................... 106
Schlussbemerkung ........................................................................................................ 109
II Gestaltungsbereich ..........................................................111
7. xFIND Kommunikationsarchitektur...................................................................... 113
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
7.7.
7.8.
Einleitung...................................................................................................................... 113
xFIND Konfiguration.................................................................................................... 114
xFIND Kommunikation ................................................................................................ 115
xFIND Datenübertragung ............................................................................................. 119
Beschreibung der xFIND QCF-Datenpakete ................................................................ 120
Testimplementierung – Client-Server Simulation......................................................... 121
xFIND Benchmark Tests .............................................................................................. 122
8. Analyse des Protokolls BEEP ................................................................................. 127
8.1.
8.2.
8.3.
8.4.
8.5.
8.6.
Aufbau der BEEP Kommunikation............................................................................... 127
BEEP Testimplementierung.......................................................................................... 131
BEEP Benchmark Tests ................................................................................................ 132
xFIND Objekte in BEEP serialisieren........................................................................... 136
BEEP im Vergleich mit der xFIND-Kommunikationsschicht ...................................... 137
9. Analyse des JXTA Protokoll-Frameworks ............................................................ 141
9.1.
9.2.
9.3.
9.4.
9.5.
Beschreibung der JXTA-Core Protokolle ..................................................................... 142
9.1.1. Peer Discovery Protokoll (PDP)...................................................................... 144
9.1.2. Information Protokoll (PIP)............................................................................. 145
9.1.3. Pipe Binding Protokoll (PBP).......................................................................... 146
9.1.4. Peer Resolver Protokoll (PRP) ........................................................................ 148
9.1.5. Rendezvous Protokoll (RVP) .......................................................................... 149
9.1.6. Endpoint Routing Protokoll (ERP).................................................................. 149
Aufbau von JXTA Advertisements ............................................................................... 151
9.2.1. Peer Advertisement ......................................................................................... 152
9.2.2. Peer Group Advertisement .............................................................................. 152
9.2.3. Module Class Advertisement........................................................................... 153
9.2.4. Module Specification Advertisement .............................................................. 153
9.2.5. Module Implementation Advertisement .......................................................... 154
9.2.6. Implementierung von Advertisements............................................................. 155
Einsatz von JXTA Services........................................................................................... 156
xFIND JXTA Testimplementierung ............................................................................. 156
10. Verbesserungsvorschläge für das xFIND System ................................................. 163
10.1.
10.2.
10.3.
10.4.
10.5.
xFIND Konfiguration.................................................................................................... 163
xFIND interne Kommunikation .................................................................................... 164
xFIND externe Kommunikation ................................................................................... 165
xFIND Architektur........................................................................................................ 166
11. Zusammenfassung.................................................................................................... 169
III Anhang ..............................................................................173
12. QCF-Spezifikation ................................................................................................... 175
12.1. Allgemeines .................................................................................................................. 175
12.2. Übersicht über die QCF-Keys....................................................................................... 177
13. xQMS Spezifikation ................................................................................................. 190
14. Profiling Analyse Ergebnisse .................................................................................. 191
14.1.
14.2.
14.3.
14.4.
14.5.
Call Graph xFIND Client.............................................................................................. 191
Call Graph xFIND Manager.......................................................................................... 191
Call Graph BEEP Client N-N ....................................................................................... 192
Call Graph BEEP Daemon N-N.................................................................................... 192
Call Graph BEEP Client N-TLS ................................................................................... 193
15. Verzeichnisse ............................................................................................................ 194
15.1.
15.2.
15.3.
15.4.
15.5.
Tabellenverzeichnis ...................................................................................................... 194
Listingverzeichnis ......................................................................................................... 194
Abbildungsverzeichnis.................................................................................................. 195
Numerische Aufzählung von RFC Referenz Dokumenten ........................................... 197
Literatur und Quellenverzeichnis.................................................................................. 198
Seite 1
Kapitel 1
1.
Einleitung
1.1.
Motivation
Information wird immer stärker zu einem entscheidenden Wettbewerbsfaktor mit
strategischer Dimension. Dennoch entspricht Information nicht zugleich auch Wissen.
Nur wer Zugriff auf Informationen zum richtigen Zeitpunkt und am richtigen Ort hat,
kann daraus Wissen ableiten bzw. Wissen erzeugen. Dies kann schon auf jeden Einzelnen
in seinem persönlichen Umfeld zutreffen und wirkt sich insbesondere auf
Unternehmenseinheiten und Organisationen aus. Wer klare Strategien verfolgen kann, um
aus abrufbarer Information Wissen zu erzeugen, kann auch den nötigen Vorsprung in der
Informationsgesellschaft erzielen.
In der Studie „How Much Information1“ von Peter Leyman und Hal R. Varian wird
die derzeitig verfügbare Informationsmenge2 mit 12 Exabyte beziffert. Pro Jahr3 werden
laut der Studie ca. 1.5 Exabyte an neuen Daten (ohne Duplikate) produziert. Die Studie
besagt auch, dass 99,97% des jährlichen Informationsaufkommens in digitaler Form
produziert wird. In der heutigen Informationsgesellschaft wird der Einsatz des Internet als
Informationsträger und als Informationsvermittler (Transportmedium) vermehrt
eingesetzt. Der Zugriff auf die Informationen kann über synchrone und asynchrone
Vermittlungsmethoden erfolgen. Eine Unterscheidung in der Informationsaufbereitung
erfolgt auch aufgrund verschiedener Anforderungen der Zielgruppen, Mensch oder
Maschine. Dabei steht der einfache Zugriff auf die Informationen dem Problem der
Informationsflut gegenüber. Das World Wide Web (WWW) bietet mit dem Erscheinen
der Studie Zugriff auf mehr als 2.5 Milliarden Dokumenten an und wächst um 7.3
Millionen Seiten täglich. Dabei wird unterschieden zwischen quasi statischen
Informationen (Surface Web) und dynamischen Informationen (Hidden Web), die durch
Interaktion durch einen Benutzer erstellt werden (z.B. Eingabeformular, als Resultat
dynamische Ergebnisseite).
1
2
3
siehe http://www.sims.berkeley.edu/how-much-info
Die Informationen sind auf verschiedenen Medien gespeichert: Papier (Bücher, Zeitschriften, Statistiken, Office
Dokumente), Film (Foto, Zelluloid, Röntgenbilder), Optisch (Musik CD, Daten CD, DVD), Magnetisch (Datenbänder,
Festplatten)
Die Studie ist aus dem Jahr 2000. Entsprechend sollen die Zahlen nur die Größenordnungen darstellen [Anmerkung
des Autors]
Seite 2
Kapitel 1 - Einleitung
Information wird durch Medien und Telekommunikationsgeräten produziert,
empfangen und verarbeitet. Über entsprechende Verteilungsmechanismen ist es ein
Leichtes, Informationen technisch einem breiten Anwenderkreis zur Verfügung zu
stellen. Zudem stellt der Wunsch einer kontinuierlichen Informationsvermittlung
(Mobile,Wearable-Computing)
auch
neue
Anforderungen
an
die
Informationsbereitsteller. Die „richtige“ Information im „richtigen“ Umfang zu
vermitteln sind eine große Herausforderung und teilweise ungelöste Probleme bei der
Informationsauffindung und der Informationsvermittlung.
Eine Informationsüberflutung verursacht neben größerem Verwaltungsaufwand auch
häufig negativen Stress4. Um der Informationsüberflutung Einhalt gebieten zu können, ist
es wichtig, systematisches Wissensmanagement zu betreiben. Um aus der Vielzahl von
Informationen gezielt Wissen gewinnen zu können, müssen spezielle Verfahren mit Hilfe
von Filter-Mechanismen strukturiert und selektiv eingesetzt werden. Metadaten als
zusätzliche Entscheidungskriterien werden z.B. in personalisierten Nachrichtendiensten
oder gängigen Metasuchmaschinen ausgewertet.
„Die Informationsexplosion ist nicht das Problem; streng genommen gibt es keine
Informationsflut, sondern nur eine der Medienwirklichkeit unangemessene
kulturtechnische Praxis.“ [Hartmann 1999]
Die Aussage von Frank Hartmann bringt eine weitere Problematik zu Tage. Es werden
jegliche Informationen digitalisiert und zumeist unstrukturiert abgelegt. Hauptsache die
Daten sind irgendwo und in irgendeiner Form gespeichert. Dass man aber gleichzeitig
einen gezielten Zugriff auf die Daten zur Verfügung stellt, ist dabei leider oft nicht von
Relevanz. D.h. die technologischen Voraussetzungen zur Datenerzeugung,
Datenspeicherung und Datenauffindung sind bereits vorhanden, jedoch fehlt es am
notwendigen Verantwortungsbewusstsein die Technologien entsprechend ihrer
Einsatzbereiche zu nutzen.
Die Speicherung und Verbreitung von großen Datenmengen ist in der heutigen Zeit
problemlos möglich. Problembereiche wie die stetige Wachstumsrate des
Datenvolumens, eine gemeinsame Nutzung von freien und kostenpflichtigen Diensten,
die Verteiltheit (Informationen oder allgemein Ressourcen), der Einsatz verschiedener
Medien, verschiedene Sprachen, verschiedene Benutzerkreise (geschützter Zugriff) und
diverse Kombinationen erschweren jedoch den schnellen Zugriff auf diese Datenmengen.
In weiterer Folge ist auch eine gezielte Suche nach relevanten Informationen für den
Einzelnen nur unter gewissen Rahmenbedingungen möglich. Mögliche Lösungen wären
eine Adaption der Suchdienste hinsichtlich ihrer Informationsabdeckung
(themenspezifische Auswahl) und eine Anpassung in der Suchmethodik. Einen weiteren
Problembereich stellt das „Vertrauen in die Information“ bzw. deren Gültigkeit oder
Aktualität dar. [Gütl 2002]
Die Verarbeitung der vielfältigen Informationen in unterschiedlichsten
Repräsentationen ist aus genannten Gründen nicht mehr von zentralen Stellen aus zu
bewältigen. Vielmehr sind intelligente Suchsysteme gefragt, die verteilte Dienste und
Applikationen verschiedener Hersteller nutzen können. Dabei geht es nicht immer nur um
herkömmliche Suchdienste in den gegenwärtig bekannten Formen. Vermehrt sollen auch
Übersetzungsdienste, Klassifizierungsdienste und weitere Dienste aus andern Bereichen
4
Stress ist für den Organismus nicht immer nur als negativ zu bewerten. In der Stressforschung wird zwischen
positivem, vitalisierendem, lebensnotwendigem Stress (Eustress) und negativem, schädlichem, Lebens zerstörendem
Stress (Distress) unterschieden [http://www.moreee.de/info_auswirkung.html].
Seite 3
zur verbesserten Informationsauffindung zum Einsatz kommen. So ist unter anderem
auch die Zusammenarbeit oder die Kombination von kommerziellen und nicht
kommerziellen Diensten als weiteres Ziel eines selektiven Datenzugriffs wünschenswert
und möglich. [Gütl 2002]
Die Zusammenarbeit verschiedener Dienste im Allgemeinen, kann jedoch nur erreicht
werden, wenn die anzusprechenden Systemteile über bekannte, standardisierte
(technologisch
anerkannt,
siehe
dazu
Abschnitt
5.1
Standardisierung)
Kommunikationsschnittstellen verfügen. Die Auswahl aus einem Pool an speziellen
Systemdiensten könnte auch bestimmten Benutzerkreisen einen speziellen thematischen
Zugriff auf die Informationen in geregeltem Umfang ermöglichen; siehe auch [Gütl
2002]. Zusätzliche Intelligenz zum automatisierten Auffinden möglicher geeigneter
Dienste erleichtert den strategischen Zugriffsprozess auf die Daten für einen größeren
Anwenderbereich. Dies beinhaltet die Suche nach entsprechenden Diensten und
Komponenten anhand deren spezifischer Eigenschaften. Systeme könnten ihrerseits die
Dienste anhand charakteristischer Eigenschaften gezielt in einer Umgebung anbieten.
Eine Erweiterung der Kommunikationsschicht würde die Anbindung dieser Dienste
ermöglichen. Sicherheitsaspekte in der Übertragung der Daten spielen neben einem
automatisierten Datenzugriff eine weitere wichtige Rolle. Eine verteilte Umgebung bietet
mehr Angriffsmöglichkeiten als zentral verwaltete Systeme. Datenkonsistenz in
Verbindung mit sicheren Übertragungsmechanismen sind weitere wichtige
Anforderungen an moderne Übertragungstechnologien. [Gütl 2002]
Ziel dieser Arbeit ist es, geeignete Übertragungsmechanismen für verteilte
Informationssysteme zu finden. Insbesondere gilt das Augenmerk auf die Unterstützung
standardisierter Übertragungsprotokolle bei der modernen Wissensauffindung. Hierzu
werden Mechanismen der Informationsübertragung und Informationsauffindung für
verteilte Systeme untersucht. Basierend auf diesen Erkenntnissen wird eine geeignete
Auswahl getroffen, um die Übertragungsschicht des xFIND Suchsystems erweitern und
verbessern zu können.
1.2.
Strukturierung der Arbeit
Die vorliegende Arbeit gliedert sich in einen Untersuchungsbereich und einem
Gestaltungsbereich auf. Im Untersuchungsbereich werden in den Kapiteln 2 bis 6 verteilte
Informationsstrukturen zur modernen Wissensauffindung im Internet diskutiert. Die
Thematik reicht von der Darstellung grundlegender Problematiken des stetig steigenden
Informationsaufkommens und deren Verarbeitung bis hin zu modernen Lösungsansätzen
der verteilten Datenverarbeitung. Im Gestaltungsbereich werden geeignete Technologien
zur Erweiterung des xFIND Suchsystems anhand diverser Testimplementierung
analysiert. Mit der Erweiterung der Transportschicht will man einerseits eine breitere
Akzeptanz erreichen und andererseits bestehende Dienste nutzen bzw. in weiterer Folge
auch Dienste über das Internet anbieten.
Um ein Grundverständnis für die Wissensauffindung im Internet zu bekommen, wird
im Kapitel 2 das Informationsaufkommen im Internet und deren Verbreitung über
Netzwerke untersucht. Des Weiteren werden mittels Möglichkeiten von Ressource
Discovery Systemen die Verarbeitung verteilter Informationen mit Webbasierten
Technologien beschrieben
Seite 4
Kapitel 1 - Einleitung
In Kapitel 3 wird näher auf konzeptionelle Ansätze der Datenverwaltung, wie verteilte
Informationsstrukturen und Architekturansätze eingegangen. Ausgehend von
Begriffsbestimmungen verteilter Informationsstrukturen werden allgemein gültige
Anforderungen an verteilte Architekturen abgeleitet. Zum Abschluss des Kapitels wird
eine Basistechnologie der verteilten Informationsübertragung, Remote Procedure Calls
(RPC), vorgestellt.
Zu Beginn des Kapitels 4 werden Topologie–Formen vorgestellt, um verteilte
Informationsstrukturen und Architekturen theoretisch abbilden zu können. In weiterer
Folge werden verschiedene Möglichkeiten zur Umsetzung von Topologie-Formen
beschrieben. Dazu gehören funktionale Ansätze, objektorientierte Ansätze, den Einsatz
von Komponenten Architektur und Peer-to-Peer (P2P) Technologien. Die theoretischen
Ansätze verteilter Informationsverarbeitung werden im Anschluss in einem Überblick
über Middleware Lösungen näher untersucht.
Ausgehend von Erkenntnissen aus dem Überblick Middleware Lösungen) wird in
Kapitel 5 eine Auswahl an standardisierten Übertragungsprotokollen vorgestellt, die
„historische“ Protokolle (z.B. Z39.50) und moderne XML-basierte Ansätze (z.B. SOAP)
enthält. Als einleitender Abschnitt des Kapitels 5 wird das Thema Standardisierung für
Hilfestellungen bei der Entwicklung von Software behandelt.
Kapitel 6 gibt einen Überblick über verteilte Suchsysteme und bildet den Abschluss
des Untersuchungsteiles. In Rückschluss auf Kapitel 5 werden die geeignetsten
Technologien zur Erweiterung des xFIND-Suchsystems ausgewählt und im
Untersuchungsbereich näher analysiert.
In Kapitel 7 wird die xFIND Kommunikationsarchitektur analysiert. Dabei werden vor
allem
die
vorhandenen
Problembereiche
aufgezeigt.
Eine
Benchmark
Testimplementierung wird zur Gewinnung von Performancedaten herangezogen. Diese
Testdaten
dienen
als
Ausgangsbasis
für
Vergleiche
mit
anderen
Übertragungstechnologien.
Kapitel 8 analysiert das Datenübertragungsprotokoll BEEP. Dabei wird näher auch
den technischen Aufbau und der Datenübermittlung eingegangen. In einer
Testimplementierung werden wiederum Benchmark Tests zur Gewinnung von
Performancedaten eingesetzt. Der direkte Vergleich von BEEP mit xFIND zeigt die
Vorteile und Nachteile beider Technologien auf.
Als zweite Technologie wird das JXTA Protokoll Framework in Kapitel 9 näher
untersucht. Insbesondere gilt die Aufmerksamkeit der selbstorganisierenden Eigenschaft
dieser Peer-to-Peer Technologie. Anhand von zwei Testimplementierungen wird die
einfache Verwendung der JXTA Module aufgezeigt.
Im letzten Kapitel des Gestaltungsteiles werden Vorschläge zur Verbesserung des
xFIND Systems erstellt. Um eine Differenzierung zu erreichen werden die Vorschläge
thematisch getrennt in Konfiguration, Kommunikation und Architektur.
Im Anhang ist die xFIND QCF und XQMS Spezifikation beigefügt. Zusätzlich sind
Profiling Daten der xFIND und BEEP Benchmarktests ersichtlich. Auch die Aufzählung
der referenzierten RFC-Dokumente, sowie ein Abbildungsverzeichnis und ein
Tabellenverzeichnis sind im Anhang ersichtlich. Abschließend ist eine vollständige
Literaturliste in alphabetischer Reihenfolge enthalten.
Seite 5
I
Untersuchungsbereich
Seite 6
Seite 7
Kapitel 2
2.
Einführende Betrachtungen
2.1.
Einleitung
Ziel des Kapitels ist es, Problembereiche der verteilten Informationsverarbeitung im
Hinblick auf Erzeugung, Verbreitung und Auffindung von Information und Diensten
darzustellen. Die ständig wachsende Informationsflut und die Verteilung der Information
bringen an sich bereits viele Probleme mit sich. Zudem werden die Informationseinheiten
oft dynamisch erzeugt und liegen in verschiedenen Formaten bzw. Medien oder
Sprachversionen vor. Entsprechend müssen geeignete Werkzeuge und Mechanismen zur
Informationsverarbeitung und Informationsauffindung bereitgestellt werden.
Im Bereich der Informationsauffindung kommt es einerseits darauf an, gezielt nach
bestimmten Informationsbereichen zu suchen bzw. zuzugreifen und andererseits möchte
man gleichzeitig auch weitere unterstützende Dienste (z.B. Übersetzungsdienste,
Klassifizierungsdienste) nutzen. Dies setzt jedoch voraus, dass Dienste und
Anwendungen über geeignete Kommunikationsschnittstellen verfügen. Liegen diese etwa
standardisiert vor, ist es möglich, einzelne Dienste zu koppeln bzw. diese einem größeren
Anwendungsbereich zur Verfügung zu stellen.
Im ersten Abschnitt dieses Kapitels soll der große Problembereich des
Informationsaufkommens im Internet beschrieben werden. In Überleitung zu
Möglichkeiten der verteilten Informationsverarbeitung im Internet wird im Abschnitt
Resource Discovery der Zusammenhang von Informations-Diensten mittels WebServices dargestellt
2.2.
Informationsaufkommen im Internet
In den vergangenen Jahren gab es eine rasche Zunahme der Anzahl an PCs und
Workstations in Local-Area und Wide-Area Netzwerken. Ebenso nahm die Anzahl an
Mobile Computing Geräten rasant zu. Dies bewirkte neben dem steigenden
Informationsaufkommen auch eine Änderung in der Datenspeicherung, der
Datenverteilung, der Datenpräsentation sowie in der Auffindung von relevanten Daten
und Diensten. Netze, die die Grundlage der Kommunikation darstellen, sind nur Teil
eines vollständigen Distributed Computing Environment. Die Bedeutung von verteilten
Systemen stieg in erster Linie aufgrund der Senkung von Produktionskosten im
Hardwarebereich (Speicherkomponenten und Prozessoren) und dem Ausbau der
weltweiten Netzwerkverbindungen. [Cailliau 1995] [Leiner et al. 2000]
Seite 8
Kapitel 2- Einleitung
Neue Entwicklungen im Bereich der Netzwerktechnologie (z.B. ATM5, ADSL6,
XDSL7) lassen eine bessere Verfügbarkeit und eine Erzielung höherer Bandbreiten zu.
Die technischen und materiellen Fähigkeiten der Zusammenarbeit (Interoperabilität) in
solchen verteilten Systemen ermöglichen den Zugriff auf Daten unabhängig von Ort und
Zeit.
Das
Internet
als
multifunktionale
und
weltweit
verfügbare
Kommunikationsplattform hat sich sowohl im Business-to-Consumer-Bereich (B2C) als
auch im Business-to-Business-Bereich (B2B) durchgesetzt. Die Nachrichtenvermittlung
erfolgte in den Anfängen des Internets über gezielte Zugriffe (browsen, E-Mail, etc.) auf
Datenbestände (Standort), die von speziellen Informationsdiensten bereitgestellt wurden.
[Cailliau 1995] [Leiner et al. 2000]
Ein wesentliches Merkmal des Internet ist, dass es nicht von einem Betreiber zentral
organisiert und betrieben wird, sondern aus einer Vielzahl von dezentral verwalteten, aber
untereinander verbundenen Teilnetzen besteht. Sehr streng müssen hierbei die weltweit
eindeutigen Adressierungsvorschriften sowie die TCP/IP Protokollspezifikationen
eingehalten werden, um die Kompatibilität sicher zu stellen. Hieraus resultieren neben
den Vorteilen der Internationalität und geringen Kosten auch die Nachteile einer sehr
heterogenen Netzqualität (z.B. Performance und Sicherheit). Die Einsatzbereiche reichen
dabei von der simplen Bereitstellung multimedialer Unternehmens spezifischer
Informationen und die Verwendung von E-Mail als Nachrichtendienst bis hin zu OnlineShopping-Systemen und anderen Web basierten Diensten. Als geeignete Maßnahmen
gegen Sicherheitslücken in der Internet-Architektur, insbesondere beim Austausch
sensibler Daten, werden verschiedene Verschlüsselungs-Mechanismen, elektronische
Unterschrift oder die Verwendung von Firewalls eingesetzt. Das stetige Wachstum der
Netzwerke bzw. die damit aufkommende Informationsflut (siehe Abbildung 2.1 und
Tabelle 2.1) bereitet herkömmlichen zentralen Ansätzen in der Informationsverarbeitung
(Software) immer mehr Probleme. Die weltweite Vernetzung von Computern und deren
Anbindung an das Internet, impliziert auch eine Vernetzung der gespeicherten Daten.
[Zakon 2002]
Abbildung 2.1: Wachstum des Internet (Anzahl an Webseiten) [Zakon 2002]
5
6
7
ATM steht für Asynchronous Transfer Mode und basiert auf Punkt-zu-Punkt-Verbindungen. Vorteile sind eine gute
Skalierbarkeit, Datenübetragung in Echtzeit und gut kontrollierbare Datenströme.
ADSL steht für Asymmetric Digital Subscriber Line und ist eine Breitbandtechnologie. ADSL benutzt die
herkömmlichen Kupferdrähte des Telefonnetzes trennt Sprache von Daten. Die Datenübermittlung erfolgt
asymmetrisch.
XDSL ist der Oberbegriff für Technologien, die Telefonkabel für den digitalen Datenverkehr nutzen. X ist eine Variable
und kann statt "A" auch beispielsweise für ein "S" (Symmetrical Digital Subscriber Line) stehen.
Seite 9
January 2002 December 2002
Growth
Hostnames
36,689,008
35,543,105
-3.12%
Active Sites
14,134,142
16,629,876
17.66%
3,801,101
4,007,918
5.44%
IP Addresses with Scripting Languages
612,420
931,468
52.10%
SSL Servers
153,072
174,745
14.16%
IP Addresses
Tabelle 2.1: Internet Wachstumsrate Jahr 2002 (http://www.netcraft.com/survey)
Die Wandlung des Internet vom Status des reinen „Informationsbereitsteller“ zu einem
interaktiven Medium bezeugen Schlagworte wie B2C, B2B oder auch Web-Services.
Speziell das Angebot an verteilten Diensten nimmt in letzter Zeit aufgrund der
Entwicklung neuer Technologien rasant zu. Die Informationsauffindung im WWW wird
durch Suchmaschinen wesendlich erleichtert. Entsprechend müssen auch die Wege der
Informationsauffindung, im Speziellen die Suche, den neuen Gegebenheiten angepasst
werden. Suchdienste die nur reine Textinhalte indizieren und filtern sind veraltet und
können gegenwärtige und künftige Anforderungen nicht mehr abdecken. Multimediale
Suchfähigkeiten oder Ähnlichkeitssuche (unter Verwendung von z.B. Word Stemming8)
bzw. Spracherkennung (Language Guessing) und Anforderungen aus dem Bereich
Resource Discovery, erfordern neben Adaptionen in der Suchmethodik (verteilte Suche,
mobile Agenten, Peer-to-Peer) auch eine Anpassung der Übertragungsprotokolle. [Gütl
2002]
Insbesondere im Bereich Verteilter Suchsysteme ist der Einsatz standardisierter
Übertragungsprotokolle von großer Bedeutung, So können Dienste verschiedener
Suchsysteme kombiniert werden, um deren spezielle Eigenschaften nutzen zu können.
Ein wichtiger Grund Suchsysteme bzw. deren Dienste zu verteilen ist, eine bessere
Skalierbarkeit bezüglich gezielter themenspezifischen oder medienspezifischer
Informationen zu erlagen. Nur ein Bruchteil aller verfügbaren Informationen kann von
einem Suchsystem abgedeckt werden. Die durchschnittliche Lebensdauer (Veränderung,
Ortswechsel, dynamischer Inhalt) einer Webseite von weniger als 70 Tage bringt
zusätzliche Probleme. Weiters ist ein Großteil des Datenbestandes in Datenbanken
gespeichert und nur über dynamische Datenaufbereitung mittels Interaktion abrufbar.
Hier scheitern gängige Suchsysteme zur Gänze. Web Archive stellen auch keine Lösung
für dieses Problem dar (siehe auch [Lackner et al. 2001]). Der Zugang zu diesen
Datenbeständen über Web-Services wäre eine Möglichkeit diese Datenbestände auch
allgemein nutzbar zu machen. In weiterer Folge kann mit Hilfe von Web-Services auch
die Migration von Systemumgebungen erleichtert werden. Anwendungen die dieser
Themenzuordnung genügen, werden dem Bereich Resource Discovery zugeordnet, auf
welche speziell im nächsten Abschnitt eingegangen wird. [Gütl 2002]
8
berücksichtigt verschiedene grammatische Formen und Schreibweisen eines Suchbegriffes
Seite 10
2.3.
Resource Discovery
Informationsverarbeitung im Sinne von Resource Discovery bedeutet das Anbieten
von Informationen bzw. Diensten und das Konsumieren von Informationen bzw.
Diensten. Resource Discovery Systeme aus dem Internetbereich stehen oft in
Zusammenhang mit informations- verarbeitenden Systemen des WWW. Die
identifizierten Problembereiche, die aus dem stetig steigenden Informationsaufkommen
entstehen, sollen mit Hilfe geeigneter Maßnamen minimiert werden. Dazu gehören unter
anderem die gezielte Auffindung von Information bzw. Diensten oder das Anbieten von
gekapselter Informationsbereiche und entsprechender Dienste. [Gütl 2002]
Der Begriff Resource Discovery im Generellen umfasst Bereiche wie das Auffinden,
Verwalten und Abrufen von Ressourcen in verteilten Systemumgebungen. Als Ressource
werden alle realen oder abstrakten Objekte bezeichnet, die in irgendeiner Form Daten
sowie Informationen verarbeiten können. Der Begriff Discovery im Speziellen beschreibt
Mechanismen, die das Auffinden und Abrufen von Ressourcen ermöglichen. In
Abbildung 2.2 wird Discovery als Vermittler zwischen Informations-Produzent und
Konsument dargestellt. Produzenten oder Informationsanbieter werden als Content
Provider dargestellt, Informationskonsumenten sind mit Content Seeker bezeichnet, die
Rolle des Vermittlers stellen Discovery Services zur Verfügung. Somit ist ein
kontinuierlicher gerichteter Informationsfluss gegeben. [Gütl 2002]
Abbildung 2.2: Discovery vermittelt zwischen Dienstleister und Konsument [Ianella 1997]
Beispiele für Discovery Services wären spezielle Such-Agenten (eigenständig
handelnde Dienste), die im Netzwerk unabhängig voneinander Daten bzw. Informationen
sammeln und diese dem Auftraggeber zur Verfügung stellen. Es geht aber nicht immer
nur um die Auffindung von Daten bzw. Informationen, sondern auch um das zur
Verfügung stellen unterstützender Dienste. Dazu gehören etwa Hintergrundbibliotheken,
Übersetzungsdienste oder aktive Dienste die persönliche Profile erarbeiten. Der in
Discovery Services bezeichnete Informationsfluss stellt eine Art Informationsaustausch
zwischen den beteiligten Gruppierungen dar. Soll der Informationsaustausch über das
Internet standardisiert abgewickelt werden, müssen so genannte Web-Services geeignete
Schnittstellen und Zugänge zu den Ressourcen bereitstellen. Durch das Zusammenführen
themenspezifisch ähnlicher Dienste, kann eine Spezialisierung in verschiedene
Fachbereiche erfolgen. Seit dem kommerziellen Erfolg des MP3 Dienstes Napster, mit
dem der Austausch von Musikdaten über das Internet über spezielle Clients und
Webseiten ermöglicht wurde, wird die Entwicklungsarbeit von Peer-to-Peer
Technologien stetig forciert. Die Problematik der Copyright und Nutzungsverletzungen
privater und kommerzieller Informationen werden durch den Einsatz gängiger
Seite 11
Datenaustauschsysteme zusätzlich verschärft. Die Erarbeitung von Sicherheitsaspekten
und die Unterstützung in der Auffindung und Indizierung multimedialer Daten stellen
weitere Anforderungen an neue Entwicklungen. [Gütl 2002]
Als Resultat dieser Forschungen und Entwicklungsarbeit setzten sich vermehrt WebFrameworkansätze durch. Einerseits wird durch den Einsatz von WebFrameworkansätzen die Entwicklungsarbeit „schlanker“ netzwerkfähiger Dienste
erleichtert und andererseits erreicht man eine bessere Skalierbarkeit des Gesamtsystems.
Dies bezeugen nicht zuletzt Entwicklungen wie .NET von Microsoft oder ONE (Open
Network Environment) von SUN Microsystems. Dabei wird versucht, auf
Standardprotokolle und Standarddienste aufzubauen, um neben Portabilität und
Akzeptanz auch eine weite Verbreitung der Applikationen und Dienste zu erreichen. Um
eine Kombination von kommerziellen Diensten und nicht kommerziellen Diensten zu
ermöglichen, muss gewährleistet sein, dass Standards verwendet und eingehalten werden.
[Weber 1998]
2.4.
Schlussbemerkung
Mit der Zunahme an diversen Endgeräten und dem Netzwerkausbau steigerte sich
auch das Informationsaufkommen im Internet. Zudem liegt eine große Verteiltheit der
Informationen vor. Diese Problematiken führen zu erschwerter und nicht zielgerechter
Informationsauffindung. Gängige Suchsysteme können einerseits kaum das ganze
Informationsspektrum abdecken und andererseits liefern sie sehr viele, zum Teil
unbrauchbare Informationen. Gegen diesen Trend arbeiten spezifisch angepasste
Suchsysteme, die gezielt nur thematisch oder medienspezifisch eingeschränkte
Informationsbereiche abdecken. Jedoch unterstützen diese Systeme keine allgemein
gültigen Abfragemechanismen oder verfügen über keine entsprechend standardisierten
Kommunikations-Schnittstellen. Der Mangel an Unterstützung standardisierter
Technologien verhindert auch die Kombination diverser Systeme. Ohne Security Checks,
Echtheitszertifikate oder auf bestimmte Benutzer eingeschränkte Zugriffe, ist es
ungewiss, ob die gelieferten Informationen vertrauenswürdig sind. Nicht immer ist es
erforderlich bestehende Technologien zu verwerfen. Im Migrationsprozess kann in einem
ersten Schritt die Kommunikationsschicht dahingehend erweitert werden, dass z.B.
Dienste über so genannte Web Services angeboten werden. In weiterer Folge kann durch
zusätzliche Maßnahmen das automatisierte Aufsuchen und Anbieten diverser Dienste
erfolgen.
Aus diesen Erkenntnissen ergeben sich folgende Schlussfolgerungen: Die
Kommunikationsschnittstelle muss an die entsprechend eingesetzte Technologie
angepasst werden. Die Kommunikationsschnittstelle sollte recht allgemein entworfen
werden, sodass verschiedene Standards unterstützt werden können. In Bezug auf die zu
übertragenen Daten (medienabhängig) sollten auch Performance Aspekte beim Entwurf
miteinbezogen werden. Um die Echtheit der Daten gewährleisten zu können, müssen
entsprechende Datenschutz Mechanismen, bzw. die Unterstützung einer
Zugriffskontrolle integriert werden.
Verschiedene Frameworkansätze bieten hierzu bereits viele Basisfunktionalitäten an.
In Anlehnung und Ausnützung dieser Technologien und unter Berücksichtigung bereits
bewährter Middleware Lösungen bzw. Multi-Tier Architekturen können einfache,
schlanke und skalierbare Schnittstellen erzeugt werden. Die Einhaltung von Standards
führt nicht zuletzt neben einer besseren Portabilität auch zu größerer Akzeptanz.
Seite 12
In den nun folgenden Kapiteln wird versucht, Eigenschaften von verteilten Systemen
zu charakterisieren. Anhand dieser Eigenschaften sollen bestehende Modelle evaluiert
werden und geeignete Vorschläge zur Verbesserung bzw. Erweiterung der
Kommunikationsschicht des xFIND-Suchsystems gefunden werden. Die interessantesten
Vorschläge werden im Gestaltungsteil beispielhaft umgesetzt und einander gegenüber
gestellt.
Seite 13
Kapitel 3
3.
Verteilte Informationsstrukturen
3.1.
Einleitung
Allgemeine Problembereiche in der Informations-Aufbereitung, der InformationsVerteilung, der Informations-Übertragung und insbesondere bei der Suche nach
Informationen und Diensten wurden im vergangenen Kapitel aufgezeigt. Um
Lösungsansätze in Teilbereichen der Kommunikations- und Informationsübertragung
analysieren zu können, werden in diesem Kapitel Merkmale von verteilten
Informationsstrukturen und verteilten Systemen vorgestellt.
Mit Hilfe von Begriffsbestimmungen wird versucht abstrakte Begriffe wie
Information
bzw.
Informationsstruktur
mit
Anwendungsmöglichkeiten
zu
veranschaulichen. In der folgenden Analyse steht deshalb nicht die Funktionalität der
Kommunikation bzw. der Informationsübertragung im Sinne der Analyse, sondern die
Art und Weise bzw. wie und mit welchen Modellen Information abgebildet werden kann.
Eine Form der Abbildung kann mit Hilfe von Architektur-Modellen erfolgen. In
weiterer Folge werden entsprechend verschiedene Architektur-Modelle beschrieben bzw.
deren Vor und Nachteile aufgezeigt. Anhand von Beispielen werden mögliche
Realisierungen verteilter Informationsstrukturkonzepte vorgestellt. Aus den gesammelten
Erkenntnissen können wichtige Anforderungen für den Entwurf einer neuen
Kommunikationsschicht für das xFIND-Suchsystem abgeleitet werden. Auch soll diese
Diskussion weitere Rückschlüsse zum Vergleich mit dem Architekturansatz des xFINDSuchsystems geben.
Am Schluss des Kapitels wird in einem kurzen Überblick die als Referenz geltende
Remote Procedure Call Technologie vorgestellt. Die RPC Technik wird als
Basistechnologie der Datenübertragung in der Kommunikationsschicht angesehen und
gilt als Ausgangspunkt vieler Entwicklungen im Bereich der Informationsübertragung in
verteilten Systemen.
3.2.
Begriffsbestimmungen
Einführend möchte der Autor der vorliegenden Arbeit mit Hilfe von
Begriffsbestimmungen grundlegende Eigenschaften der Informationsverarbeitung
darstellen. Dabei stützen sich diese Definitionen auf Aussagen im Bereich der
Datenverarbeitung, die logische Zusammenhänge und funktionelle Abläufe abdecken.
Weiterführend sollen aber auch die Begriffe unter Berücksichtigung semantischer
Aspekte neue Sichtweisen liefern. Insbesondere die semantischen Aspekte liefern nötige
Schlussfolgerungen für den Zusammenhang der abstrakten Definition und den möglichen
Einsatzbereichen.
Seite 14
Kapitel 3 - Verteilte Informationsstrukturen
Daten sind nach DIN 44300 Zeichen (Buchstaben, Zahlen oder Symbole) oder
kontinuierliche Funktionen, die zum Zweck der Verarbeitung Information aufgrund
bekannter oder unterstellter Abmachungen darstellen. Diese können korrekt oder falsch
sein. Bei Informationen zum Zwecke der Verarbeitung wird zwischen digitalen und
analogen Daten unterschieden. Im Zuge diese Arbeit wird von Daten gesprochen, die in
daten- verarbeitenden Anlagen automatisiert verarbeitet werden können. Die Definition
setzt Zeichen mit Funktionen gleich. Zeichen und Funktionen werden jedoch von
Strukturen beschrieben. Nach Mackeprang sind Daten „Strukturen physikalischer
Wirkungen, die zur Ableitung von Informationen dienen oder diese Informationen
darstellen". Eine Struktur wird durch mathematische Funktionen beschrieben, die als
Anordnung in Zeit und Raum zu sehen ist. [Dreßler 2002]
Der Begriff Information wird in unserem Informationszeitalter in verschiedenen
Bereichen unterschiedlich ausgelegt und genutzt. 1948 verfasste Cloude E Shannon nach
Arbeiten von Nyquist und Hartley eine mathematische Theorie der Kommunikation, die
zur Formulierung einer allgemeinen Informationstheorie führte: die Nachrichtentheorie.
Diese besitzt auch heute noch Gültigkeit, wobei Shannon bei seiner Theorie die
Übertragung elektrischer Signale in den Vordergrund stellte. Die Betrachtung von
Shannon kann jedoch nicht allgemein für die Datenübertragung angewandt werden, da
die Übertragung und Verarbeitung von Daten von weiteren wichtigen Faktoren anhängt.
Um den Begriff der Information für den Bereich der Informationsverarbeitung nutzbar zu
machen, werden semantische Aspekte benötigt. Siegfried Wendt weicht in seinem Buch
„Nichtphysikalische Grundlagen der Informationstechnik“ von der klassischen
Shannontheorie ab und definiert Begriffe wie Information und Informationsstruktur aus
Sicht der Informationsvisualisierung. Siegfried Wendt verknüpft die logische Abstraktion
mit möglichen Nutzungsinhalten. Dabei bezeichnet er Information als "Information ist
alles Wissbahre. Information kann man speichern, transportieren und verarbeiten".
Hingegen definiert Wend den Begriff Informationsstruktur ohne semantische Aspekte
"Eine Informationsstruktur ist eine Relation, die die Beziehung zwischen
Informationsobjekten9 beschreibt". [Wendt 1991]:
Um den Nutzungsgrad der bisherigen Begriffsbestimmungen von Information und
Informationsstruktur hervorheben zu können, ist es auch wichtig, Daten als gekapselte
Objekte, die nicht nur rein statischer Natur sind, zu sehen. Nachdem nun Begriffe wie
Information und Informationsstruktur erklärt wurden, sind weiterführende Betrachtungen
im Rahmen dieser Arbeit speziell für den Bereich der verteilten Informationssysteme und
der Informationsverteilung notwendig.
Michael Weber definierte in seinem Buch „Verteilte Systeme“ zwei weitere
Begriffsbestimmungen. Eine verteilte Anwendung ist aus der Sicht von Weber „[...] eine
Anwendung, die auf mehreren Rechnern bzw. Prozessoren abläuft und unter diesen
Informationen austauscht". [Weber 1998]
Hingegen sieht Weber den Unterschied von verteilter Anwendung zu verteilten
Systemen darin, dass ein verteiltes System dann als solches bezeichnet wird, wenn „[...]
mehrere Rechner bzw. Prozessoren im System vorhanden sind und auf denen mindestens
eine verteilte Anwendung lauffähig installiert ist". [Weber 1998]
Von diesen Definitionen ausgehend können bereits Minimalanforderungen verteilter
Systeme abgeleitet werden. Eine Anwendung soll verteilbar sein bzw. auf verschiedenen
Architekturen lauffähig sein. Diese Minimalanforderungen sollen im folgenden Abschnitt
9
Ein Informationsobjekt entspricht der Kapselung von informationsrepräsentierenden Daten. [Wendt 1991]
Seite 15
Grundlagen der Software Architektur verifiziert und gegebenenfalls ergänzt werden. Es
werden Eigenschaften von Informationsstrukturen definiert, entsprechende Komponenten
der Architekturen erläutert, auf die Vorteile und Nachteile von verteilten Ansätzen
eingegangen und anhand verschiedener Modelle die Architektur verteilter
Informationsstrukturen erklärt.
3.3.
Architekturen verteilter Informationsstrukturen
Der folgende Abschnitt beschreibt Eigenschaften und Merkmale von verteilten
Informationsstrukturen. Weiters werden Informationsstrukturen in verschiedene Bereiche
unterteilt, um so dem Leser zentrale Ansatzpunkte zum Entwurf verteilter Strukturen
liefern zu können. In weiterer Folge werden Anforderungen an verteilte
Informationsstrukturen ermittelt, die anhand Beispiele der verteilten Dateiverwaltung
belegt werden.
Die zentrale Architektur ist ein bekanntes und weit verbreitetes System. Neue
Anforderungen, wie im vorigen Kapitel erwähnt, führen zu einem vermehrten Einsatz
von verteilten Konzeptansätzen. Dies beginnt im Hardwarebereich (Zentrale
Rechnerarchitekturen werden vermehrt von vernetzten Rechnerarchitekturen abgelöst)
und endet bei der Ablöse herkömmlicher Software, um verteilte Systemansätze
verwirklichen zu können. Weit verbreitet sind auch verteilte Anwendungen mit einer
Client-Server Architektur, die vor allem in den Anfängen der vermehrten
Netzwerknutzung große und komplexe Netzwerkdienste abgelöst haben. Die
Kommunikationsschicht als Basistechnologie der Softwarearchitektur spielt dabei eine
große Rolle. [Weber 1998]
Die grundlegendsten Elemente verteilter Informationsstrukturen werden bereits auf
Betriebssystemebene in dessen Kommunikationsschicht integriert. Um den Mechanismus
des Kommunikations-Aufbaus vereinfachen und vereinheitlichen zu können, ist es
wichtig, diese Architekturkomponenten in mehrere Schichten aufzuteilen. Daraus folgen
neue Entwicklungen im Bereich netzwerkfähiger Dienste und Applikationen, die eine
Aufteilung der Dienste und Applikationen in eigenständige Untereinheiten durchführen.
Diese werden als so genannte Web-Services im Internet zur Verfügung gestellt. [Stallings
1998]
In der nachfolgenden Übersicht werden zunächst Merkmale und Eigenschaften von
verteilten Informationsstrukturen erläutert, um ein besseres Verständnis für mögliche
Architekturansätze bekommen zu können [Schlichter 2000]:
• Mehrfachexistenz: In sich abgeschlossene Funktionseinheiten können mehrfach
auftreten und so eine Möglichkeit der „parallelisierten“ Datenverarbeitung sein.
• räumliche Verteilung: logische Funktionseinheiten können auf verschiedene
Komponenten einer verteilten Architektur aufgeteilt werden.
• keine Abhängigkeiten: eine Kapselung logischer Funktionseinheiten muss möglich
sein, um sie unabhängig voneinander einsetzen zu können.
• Vereinheitlichung und Integration der Kontrolle: logische Funktionseinheiten sollen
plattformübergreifend10 entwickelt werden, um Komponenten unabhängig zur
verwendenden Betriebssystemumgebung nutzen zu können.
10
platformunabhängig ist eine vom Betriebssystem unabhängige Funktionsweise
Seite 16
• Datentransparenz: durch die Aufteilung der Informationsstrukturen in Untereinheiten
(Userinterface, Kommunikation, Datenverwaltung, etc.) wird für Benutzer eine
Verringerung der Komplexität erreicht.
• standardisierte Schnittstellen: die Datentransparenz wird bei Verwendung von
standardisierten Schnittstellen und standardisierten Protokollen gewährleistet.
• Skalierbarkeit: durch die Aufteilung einer Informationsstruktur in Untereinheiten
erreicht man auch eine bessere Skalierbarkeit des Gesamtsystems. Dabei steht aber die
Skalierbarkeit der Informationsstruktur in indirektem Zusammenhang der
verwendeten Hardwarearchitektur.
Weiters kann eine Architektur untergliedert werden, indem die zuvor definierten
Merkmale und Eigenschaften auch in den Teilbereichen angewandt werden. Eine
Untergliederung erfordert neben der jeweils für sich verteilten Verarbeitung auch eigene
Verwaltungseinheiten im jeweiligen Bereich. Ein Bereich kann dabei durchaus
Hardwareressourcen beinhalten und beschränkt sich dementsprechend nicht nur rein auf
das Verteilten von Daten und Informationen. Die folgende Gliederung einer
Architektureinheit stützt sich auf die Arbeit von [Schlichter 2000]:
• Ressourcen: Dies entspricht der Verteilung der Informationen auf verschiedene
Ressourcen. Das können z.B. mehrere Fileserver, externe Datenbanksysteme oder
andere periphere Geräte sein.
• Last-Verteilung: Informationen (Daten) können aufgrund einer erweiterten
Rechnerarchitektur auf mehrere Prozessoren und mehrere unabhängige
Speichereinheiten effizient verteilt werden.
• Verteilung der Kontrolle: Die Datenverteilung erfolgt auf Betriebssystemebene und
nützt entweder eine mögliche Lastverteilung der entsprechenden Rechnerarchitektur
aus, oder versucht einen Systemaufruf auf mehrere Prozesse aufzuteilen, um so einen
größeren Datendurchsatz zu erhalten.
• Daten: Die Verteilung der Daten auf mehrere Prozessverarbeitungsmechanismen,
impliziert eine mögliche Variante eines verteilten Datenbankkonzeptes. Daten können
von mehreren Datenbankservern redundant gehalten werden, um einerseits die
Datensicherheit gewährleisten und andererseits die Zugriffsgeschwindigkeiten auf
bestimmte Datensätze erhöhen zu können.
• Verarbeitung: Datensysteme können mittels verteilter Anwendungen aufgebaut,
strukturiert und gewartet werden. Das kann z.B. eine Client-Server-Anwendung sein,
in der mehrere Clients und mehrer Server zu einem gemeinsamen
Datenverwaltungssystem zusammengefasst werden.
Seite 17
Die Untergliederung der Architektur in Teilbereiche entspricht einem verteilten
Architekturansatz. Da der verteilte Ansatz nicht nur Vorteile mit sich bringt, sondern
auch einige Problemstellen und Nachteile besitzt, werden nun die wichtigsten
Problembereiche verteilter Informationsstrukturen dargestellt. Die Nachteile von
verteilten Informationsstrukturen liegen bei einigen wenigen zentralen Punkten
[Schlichter 2000]:
• Netzwerk: Das Verteilen von Informationen ist abhängig von der Kapazität und
Zuverlässigkeit der Netze. Es ist zusätzlich eine Kommunikationslogik11 erforderlich,
die entsprechende Fehlerbehandlungsalgorithmen beinhaltet.
• Sicherheit: Es besteht ein erhöhtes Sicherheitsrisiko, da durch die Verteilung von
Komponenten das System mehr Angriffspunkte bietet. Das System wird
verwundbarer.
• Komplexität: Mit der Verteilung steigt auch die Komplexität in der
Kommunikationsschicht. Ebenfalls wird auch das Testen eines verteilten Systems
schwieriger und komplexer.
Nachdem die Merkmale und Eigenschaften von verteilten Informationsstrukturen,
diverse Bereiche der Kontrolle und Verwaltung sowie Problemstellen aufgezeigt wurden,
werden nun wesentliche Anforderungen an verteilte Architekturen erläutert.
3.3.1.
Anforderungen an verteilte Informationsstrukturen:
Entsprechend der Problemstellungen werden an verteilte Informationsstrukturen
verschiedene Anforderungen gestellt. Diese Anforderungen sollen als ReferenzAnforderungen für den Entwurf verteilter Softwarekomponenten gelten. Der Entwurf
eines verteilten Informationssystems wirft somit im Gegensatz zu Einzelrechnersystemen
neue und mehrere Probleme auf und liefert auch entsprechend neue Anforderungen. In
der nun folgenden Auflistung werden Referenz-Anforderungen an eine verteilte
Informationsarchitektur erläutert, die generell für den Entwurf von verteilten
Softwarekonzepten gelten [Weber 1998]:
• Transparenz: Die verteilte Informationsstruktur soll sich dem User als ein
Gesamtsystem präsentieren. Dem User soll die Struktur „hinter“ dem System
verborgen bleiben. Ein User erhält so transparenten Zugriff auf lokale und entfernte
Ressourcen (Zugriffstransparenz). Aufgrund der verborgenen Struktur weiß der
Benutzer nicht, wo sich die Ressourcen befinden (Ortstransparenz). Die Ressourcen
werden über entsprechende Namensdienste angesprochen. Der Name einer Ressource
oder eines Objekts darf keine Informationen über den Ort enthalten. Dementsprechend
können Ressourcen auch „verschoben“ werden, ohne die Zugriffsmechanismen
verändern zu müssen (Migrationstransparenz). Zusammenfassend wird die Zugriffsund Ortstransparenz als Netzwerktransparenz betrachtet. Benutzer können auf
replizierte Objekte zugreifen, als ob sie nur einmal vorhanden wären
(Replikationstransparenz). Entsprechend der Architektur können auch mehrere User
gleichzeitig auf eine Ressource zugreifen ohne sich gegenseitig zu beeinflussen
(Nebenläufigkeits- oder Paralleltransparenz). Aufgrund der Replikate wirkt sich ein
Ausfall einer Teilkomponente nicht auf die Konsistenz des Gesamtsystems aus. Der
Zugriff auf die Daten und Ressourcen bleibt erhalten (Fehlertransparenz). Bei
11
Kommunikationslogik integriert Schnittstellen, Übertragungsprotokolle, Fehlerbehandlung, Datensicherheit, etc.
[Schlichter 2000]
Seite 18
Einhaltung der Leistungstransparenz ist eine Verbesserung der Performance über eine
dynamische Anpassung des Systems an Lastgegebenheiten möglich. Dies impliziert
auch eine mögliche Erweiterung oder Wartung (Skalierungstransparenz) des Systems,
ohne Einfluss auf die Architektur des Systems oder der Komponenten zu nehmen.
• Skalierbarkeit, Flexibilität, Dynamik: Die beliebige Erweiterbarkeit des Systems
entspricht auch der Wartbarkeit eines Systems. Die erweiterte oder veränderte
Architektur soll weiterhin für den Benutzer als auch für die Software
(Informationsstruktur) transparent bleiben. Es soll daher beim Entwurf eines Systems
auf zentrale Komponenten verzichtet werden. Diese könnten im Zuge der Erweiterung
einen Engpass darstellen und so unverhofft zu Problemen führen. Mit der Zunahme
der Skalierbarkeit (Erhöhung des Kommunikationsaufwandes) können analog zur
zentralen Verwaltung von Daten ebenfalls Probleme auftauchen.
• Offenheit: Rechnerarchitekturen mit verschiedenen Betriebssystemen und
verschiedener Software müssen die Schnittstellen der Hard- und Software
Komponenten offen legen, um stetig gleich bleibende Zugriffsmechanismen für ein
Gesamtsystem zur Verfügung stellen zu können.
• Zuverlässigkeit, Effizienz: Die Zuverlässigkeit und Effizienz von verteilten Systemen
ist gegenüber monolithischen Systemen weit überlegen, wenn die oben erwähnten
Punkte beim Entwurf berücksichtigt und bei der Entwicklung eines verteilten Systems
eingehalten wurden. Die Steigerung der Effizienz hängt im Allgemeinen von der
Parallelisierbarkeit der Problemstellung und in weiterer Folge vom Entwurf geeigneter
Algorithmen ab.
3.3.2.
Anwendungen für verteilte Datenverwaltung
Nachdem im letzten Abschnitt die Anforderungen an verteilte Architekturen erläutert
worden sind, folgt als Beispiel zur näheren Erklärung verteilter Konzepte ein kurzer
Überblick über mögliche Basiskomponenten von Betriebssystemen (BS). Weiterführende
Informationen über den Entwurf, den Aufbau und dem Design verschiedener
Betriebssysteme sind im Buch „Operating Systems Internals and Design Principles“ von
Stallings nachzulesen [Stallings 1998]. Von besonderem Interesse sind DesignVergleiche verschiedener BS. Viele erläuterten Anforderungen an verteilte
Informationsstrukturen sind in diversen BS-Konzepten zum Teil bereits umgesetzt, bzw.
waren bereits angedacht [Weber 1998]:
• Verteilte Betriebsumgebung über lokalen Betriebssysten: Jeder Rechner besitzt ein
eigenständiges Betriebssystem, das über Rechnernetzwerke miteinander
kommuniziert. Die Kommunikationsschicht liegt über der BS–Umgebung und stellt
die Verbindung zu der Anwendungskomponente dar. Die verteilte
Informationsstruktur ist in diesem Modell auf mehrere Rechner logisch aufgeteilt. In
Abbildung 3.1 wird ein verteilter Systemansatz ohne Unterstützung des
Betriebssystems gezeigt. Das Betriebssystem dient lediglich der Datenverwaltung und
der Kommunikation.
Seite 19
Abwendungs-Komponente
Verteilte Betriebsumgebung
Kommunikation
Verteilte Anwendung
Kommunikation
Lokales Betriebssystem
Rechner 1
Rechner n
Netzwerk
Abbildung 3.1: Verteiltes System ohne Betriebssystemunterstützung [Weber 1998]
• Netzwerkbetriebssystem: Bei einem Netzwerkbetriebssystem ist die Kommunikation
bereits im Betriebssystem integriert. Die Konfiguration entspricht einem Netzwerk
von Anwendungsrechnern. Server stellen Netzwerk Services oder Applikationen zur
Verfügung (z.B. File-Server, Drucker–Management). Jeder Computer besitzt
wiederum ein eigenständiges BS. Die Kommunikation mit Servern oder anderen
Rechnern wird durch die Integration der Kommunikationsschicht in die
Betriebssystemumgebung erleichtert. Dem Benutzer ist dabei jedoch nicht bewusst,
dass sich Architektur des BS aus verteilten Netzwerk-Rechnern zusammensetzt. In
Abbildung 3.2 ist eine vereinfachte Version dieser Architektur (ohne
Serververbindungen) dargestellt.
Verteilte Anwendung
NetzwerkBetriebssystem
Kommunikation
Kommunikation
Rechner 1
Rechner n
Netzwerk
Abbildung 3.2: Netzwerkbetriebssystem [Weber 1998]
• Verteiltes Betriebssystem: In einem verteilten Betriebssystem sind sowohl die
Kommunikationsschicht als auch die Verteilungsmechanismen vollständig in das BS
integriert. Diese Art von Netzwerk-Architektur präsentiert sich als Gesamtheit, d.h.
Zusammenschluss oder Verbund unabhängiger Rechner. Die Architektur erlaubt dem
Benutzer transparenten Zugriff auf bestimmte Ressourcen wie Services, Applikationen
und Systemkomponenten verschiedener Rechner. Der Benutzer weiß in der Regel
nicht wo die Ressourcen sind oder wer die Ressourcen bereitstellt. In Abbildung 3.3
ist ein vereinfachtes Bild der Architektur eines verteilten Betriebssystems dargestellt.
Verteilte Anwendung Abwendungs-Komponente
Verteiltes Betriebssystem
Rechner 1
Rechner n
Netzwerk
Abbildung 3.3: Verteiltes Betriebssystem [Weber 1998]
Seite 20
3.4.
Remote Procedure Call in der Kommunikationsschicht
Im vergangenen Unterabschnitt 3.3.2 bilden die vorgestellten Betriebssystemgrundelemente die Basis für verteilte Anwendungen. Der RPC-Ansatz gilt in der
Kommunikationsschicht als Referenz für den Entwurf verteilter Datenobjekte und der
Entwicklung verteilter Funktionseinheiten. Viele Middlewarelösungen (siehe Abschnitt
4.7) und Spezifikationen von Übertragungsprotokollen (siehe Kapitel 5) setzen auf den
RPC Ansatz auf. Des Weiteren stellt RPC Möglichkeiten zur Verfügung verteilte Dienste
und verteilte Funktionalität zu nutzen. Der RPC Ansatz stellt weiters eine mögliche
Umsetzung des Konzepts der verteilten Informationssysteme auf objektorientierter Ebene
dar.
RPC stellt eine Erweiterung für den Bereich der Kommunikationsschicht in verteilten
Informationsstrukturen zur Verfügung. Das RPC Protokoll soll die Entwicklung von
verteilten Anwendungen erleichtern, indem sich die verteilten Komponenten einer
Anwendung nicht um Netzwerkdetails kümmern müssen. Dadurch ist nicht nur eine
räumliche Verteilung der Funktionalitäten möglich, sondern auch die nötige Kapselung
der Funktionseinheiten oder der funktionalen Objekteinheiten. Die ursprünglichen
Kommunikations- Primitive im Verbindungsaufbau bzw. der Datenübertragung (Ein–
Ausgabe) wie "send" und "receive", wurden durch direkte Funktionsaufrufe mit
Parameterübergabe erweitert. Dabei wird eine entfernte Prozedur oder Funktion so
angesprochen, als ob sie auf dem lokalen Rechner installiert wäre. Die Kommunikation
erfolgt zwischen einem "Client", der die Prozedur anfordert und dem "Server", der die
entsprechende Prozedur oder Funktion zur Verfügung stellt. Abbildung 3.4 zeigt die
Funktionsweise eines RPC Systems. Der Aufruf von Prozeduren auf entfernten Rechnern
erfolgt dabei in synchroner12 Weise. Der aufrufende Client bleibt solange in einem
blockierten Zustand, bis entweder der Server den Funktionsaufruf abgearbeitet hat, oder
ein Fehler aufgetreten ist. Diese zusätzliche Kommunikationsschicht zwischen Client und
Server beinhaltet auch zusätzliche Fehlerquellen. Entsprechend erfordert dies auch die
Implementierung eigener Fehlerbehandlungsalgorithmen. Dies bringt zusätzlichen
"Overhead" und geht zu Lasten der Performance. Ebenfalls zu Lasten der Performance
wirkt sich die Übertragung der Daten über ein Netzwerk aus. Da es keinen gemeinsamen
Speicher-Adressraum für die verteilten Objekte gibt, muss bereits beim Entwurf einer
RPC-Funktion auf diese Problematik eingegangen werden. So ist etwa eine
Sonderbehandlung für Pointerstrukturen notwendig. Beim RPC wird der Call am Client
an einen lokalen Stub13 weitergegeben. Dieser Stub (Prozedur) stellt nun die übergebenen
Parameter mit dem Call zu einer gemeinsamen Nachricht zusammen. Die Nachricht wird
im Client-Stub serialisiert und über das Netzwerk zum Stub des Servers übertragen. Der
Stub des Servers zerteilt die Nachricht entsprechend dem Serialisierungsprotokoll und
gibt den Call (Parameter) an die Serverprozedur weiter. Der Prozess des Serialisieren und
Deserialisieren wird Marshalling14 genannt Der Call wird von der Serverprozedur
abgearbeitet und das Ergebnis in derselben Weise zum Client zurückgesandt. Bei der
12
synchron: Der Client bleibt durch den synchronen RPC Call (Thread) solange blockiert, bis der RPC-Aufruf durch den
zugehörigen Server Thread abgeschlossen ist. Ein asynchroner RPC Aufruf ist eine Erweiterung des synchronen RPC
Calls. Dabei blockt der aufrufende RPC Call den Client nicht mehr, sondern gibt sie Steuerung an den Client für
andere Tasks wieder frei.
13
Stub: sind kleine vorkompilierte Programmroutinen, die das eigentliche Programm (Funktion) teilweise ersetzen. Ein
Stub übernimmt Kommunikationsaufgaben und fungiert als Schnittstelle zwischen Client und Server.
14
Marshalling: sammeln von Daten von Applikationen und nichtzusammenhängenden Sourcen; zusammenfassen dieser
Daten zu einer Message und Bereitstellen der Message inklusive möglicher Sprachkonvertierungen (Protokolle,
Formate, etc.)
Seite 21
Parameterübergabe unterscheidet man grundsätzlich [Weber 1998] [Schlichter 2000]:
• Call by Value: Es reicht bei einfachen Variablen nur den Wert selbst an die RemoteProzedur weiterzugeben. Wenn Datenfelder übertragen werden müssen, müssen alle
Werte des Feldes serialisiert und zu einer Nachricht verpackt werden.
• Call by Reference: Bei Verwendung von Bäumen als Datenstrukturen oder Pointer auf
Arrays genügt es nicht nur die Wurzel oder den Startzeiger einer Datenstruktur zu
übertragen. Die Datenstruktur muss vielmehr als ganzes Wertepaket (Objekt) zur
Remote-Prozedur übertragen werden. Dabei ändert sich aber bei der Übertragung die
Bedeutung von „Call by Reference“ zu „Call by Copy“. Bei der Rückübertragung
muss mit „Call by Restore“ die vorgegebene Datenstruktur neu aufgebaut werden.
Eine andere Möglichkeit wäre, notwendige Parameter dynamisch nachzuladen. Nur in
diesem Fall können dynamische Datenstrukturen tatsächlich realisiert werden.
Abbildung 3.4: RPC - Funktionsweise [Weber 1998]
Nachdem der grundsätzliche Kommunikationsaufbau erklärt wurde, werden
nachfolgend die Aufgaben des Client-Stub und des Server-Stub erklärt [Schlichter 2000]:
• Aufgaben des Client-Stub: Der Client-Stub muss die Spezifikation (Schnittstelle) der
aufgerufenen Prozedur festlegen. Weiters muss der Call (Aufruf der Prozedur) einem
Zielrechner zugeordnet werden. Die Übergabeparameter müssen entsprechend in das
Zielformat (Übertragungsformat) umgesetzt werden. Die Beschreibung dieser
Parameter wird Signatur genannt und beinhaltet auch eventuelle Möglichkeiten, um
auf Fehlerfälle reagieren zu können. Nach dem Aufruf muss der Stub die
empfangenen Daten dekodieren und an den Client zurückgeben. Zum Schluss muss
der Stub noch die Blockierung des Clients aufheben.
• Aufgaben des Server-Stub: Der Server-Stub muss den Call und die Parameter des
Client-Stub dekodieren und die entsprechende Aufrufadresse der Prozedur bestimmen.
Anschließend erfolgt der Prozeduraufruf mit den dekodierten Übergabeparametern.
Der Stub kodiert nach Abarbeitung der Prozedur die Ergebnisse und die
Aufrufkennung und sendet die kodierten Daten über das Netzwerk zum Client Stub.
Grundlegende Eigenschaften eines RPC – Systems werden charakterisiert durch
[Schlichter 2000]:
• eine einheitliche Aufrufsemantik
• ein type-checking
• volle Parameterfunktionalität
• eine Optimierung der Antwortzeit
Seite 22
Das RPC-Modell kann auch als so genanntes OSI15-Schichtenmodell, wie in
Abbildung 3.5 ersichtlich, dargestellt werden und setzt dabei auf das entsprechende
Transportprotokoll auf. Dabei gibt es wieder verschiedene Möglichkeiten der Anbindung
an das Transportsystem [Schlichter 2000].
Client – Server Model
RPC Mechanismus
Serialisierung, Nachrichtenaustausch
Transportsystem (TCP/UDP)
OSI Schicht 7
OSI Schicht 6
OSI Schicht 5
OSI Schicht 4
application layer
presentation layer
session layer
transport layer
Abbildung 3.5: RPC - OSI Schichtenmodell [Schlichter 2000]
Die RPC Transport Anbindung kann in symmetrischer oder asymmetrischer Form
erfolgen. Bei der symmetrischen Datenübertragung werden alle Übergabeparameter in ein
bestimmtes kanonisches Format übersetzt. Das setzt voraus, dass sowohl der Client als
auch der Server eigene Konvertierungsalgorithmen besitzen. Beim asymmetrischen
Verfahren schicken die Clients die Übergabeparameter jeweils in einem eigenen Format.
Der Server muss bei n verschiedenen Clients n verschiedene Konvertierungsalgorithmen
besitzen. Weiters stellt das RPC Protokoll keine Möglichkeiten der sicheren
Datenübertragung (Verschlüsselung bzw. Identifikation) zur Verfügung und bietet keine
Kontrollmöglichkeit bei Ausfall von Server oder Client. D.h. es muss zusätzlich noch
eine Kontrollschicht eingefügt werden, um eine Fehlerbehandlung durchführen zu
können. Der Serverprozess muss im Client-Fehlerfall benachrichtigt werden, der Client
muss bei Serverausfall benachrichtigt werden. [Weber 1998] [Schlichter 2000]
Für die Entwicklung bzw. Festlegung der Signaturen und Schnittstellen wurden
spezielle Schnittstellenbeschreibungssprachen entwickelt. Es kommen so genannte RPCCompiler zum Einsatz, die für verschiedene Konzepte entwickelt wurden. Bei CORBA16
ist es z.B. IDL (Interface Definition Language). Bei der Entwicklung von verteilten
Anwendungen kommen auch RPC Generatoren zum Einsatz. Diese erzeugen die
Schnittstellenparameter und legen die Datentransformation der Stubs fest. RPC
Generatoren erleichtern somit den Entwicklungsprozess durch Reduzierung des
Zeitaufwandes, der Implementierung und die Verwaltung der Teilkomponenten. Weiters
ist die Schnittstellenbeschreibung leichter wartbar, erweiterbar und in der Folge daraus
weniger fehleranfällig. [Schlichter 2000]
Mit dem RPC Protokoll ist es nun möglich, auf einfache Weise Applikationen und
entsprechend verteilte Netzwerkdienste zu implementieren. Die entwickelten RPC
Modelle wie Sun RPC17 oder DCE RPC18 wurden von der ISO zu einem gültigen
Standard (ISO RPC) vereint, jedoch gibt es bis heute keine kommerziell erfolgreiche
Umsetzung des ISO RPC. Zur Definition des ISO RPC wurde auch eine eigene Interface
Definition Notation (IDN) definiert, mit der RPC Applikationen erzeugt werden können.
[Schlichter 2000]
15
OSI: Open Systems Interconnection
CORBA: Common Object Request Broker Architecture, wurde 1991 von der Object Management Group (OMG), einem
Standardisierungsgremium mit mehr als 700 Mitgliedern definiert. Das Kommunikationsprotokoll zwischen Object
Request Brokern (ORB) verschiedener Hersteller, welches den Meldungsaustausch über das Internet ermöglicht, wird
Internet Inter-ORB Protocol (IIOP) genannt. ORBs sind die technischen Implementierungen des CORBA Standards.
17
Sun RPC: von Sun umgesetzt; heute sind zwei gängige Modelle bekannt: ONC RPC - Open Network Computing
(Linux) und TI RPC – transport independent (Solaris), Programmierung über RPCL, drei mögliche AuthentifizierungsSchemata
18
DCE RPC: Distributed Computing Environment, Programmierung über IDL, Authentifizierung über Kerberos (Network
Authentication Protocoll); siehe Abschnitt 4.7.2
16
Seite 23
3.5.
Schlussbemerkung
Der Entwurf und Einsatz von verteilten Informationsstrukturen birgt Vor und
Nachteile in sich. Durch die Aufteilung der Informationsstrukturen in einzelne
Unterbereiche erreicht man einerseits eine bessere Wartbarkeit und Erweiterbarkeit,
zugleich erfordert aber diese Aufteilung auch einen größeren Verwaltungsaufwand und
Anpassungen beim Entwurf der Kommunikationsschicht. Das Ziel beim Entwurf einer
geeigneten Kommunikationsschicht ist nicht immer das Erreichen einer hohen Effizienz.
Sicherheitsaspekte und das Streben einer breiteren Akzeptanz gehen oft zu Lasten der
Datendurchsatzrate.
Bei näherer Betrachtung verschiedener Architekturkonzepte kann man Vorteile und
Problembereiche von verteilten Strukturen erkennen. Minimalanforderungen wie eine
Anwendung soll verteilbar sein, auf verschiedenen Architekturen lauffähig sein und in
mehrere Schichten aufteilbar sein, impliziert auch die Vorgaben, die eine
Kommunikationsschnittstelle erfüllen muss. Ebenso müssen beim Entwurf der
Kommunikationsschicht
Eigenschaften
von
verteilten
Informationsstrukturen
berücksichtigt werden. Dazu gehören die räumliche Verteilung der Information,
Mehrfachexistenz, das Ausschließen von Seiteneffekten, Abbildung diverser
Transparenzeigenschaften,
Skalierbarkeit
und
Verwendung
standardisierter
Schnittstellen. Neben diesen vielfältigen Eigenschaften, die zum Teil auch
Anforderungen
an
moderne
Informationsstrukturen
sind,
soll
eine
Kommunikationsschicht zusätzlich noch erweiterbar und zuverlässig sein.
RPC als Basistechnologie liefert wichtige technische Erkenntnisse die zum Entwurf
von Kommunikationsschnittstellen in verteilten Systemen notwendig sind. Die
Einführung eines Schichtenmodells unterbindet direkte Funktionsaufrufe durch die
Kapselung funktionaler Einheiten in Stubs. Das Schichtenmodell erweist sich vor allem
für Applikation von Vorteil, da sich diese nicht mehr um Basisdienste wie Transport bzw.
Netzwerkdetails kümmern müssen. Werden in den jeweiligen Schichten wiederum
standardisierte Datenaustauschmechanismen verwendet, können Anforderungen wie
Sicherheit und Offenheit einfach realisiert werden.
Um den abstrakten Begriff verteilte Informationsstrukturen zu konkretisieren, wird im
nächsten Kapitel untersucht, wie verteilte Informationsstrukturen bzw. Architekturen in
verteilten Anwendungen umgesetzt werden können. Speziell werden auch gängige
Middlewarelösungen untersucht, die wichtige Aufschlüsse bezüglich der verwendeten
Technologien liefern. Im Kontext der vorliegenden Arbeit werden eingesetzte
Übertragungsmechanismen untersucht und in weiterer Folge eine geeignete Auswahl zur
weiteren Untersuchung getroffen.
Seite 24
Seite 25
Kapitel 4
4.
Verteilte Anwendungen
4.1.
Einleitung
In den vorangegangenen Kapiteln wurden grundlegende Begriffsbestimmungen erklärt
sowie Methoden zur verteilten Informationsverwaltung beschrieben. Dieses Kapitel
beschäftigt sich mit Problemen und Lösungsvorschläge der verteilten
Informationsverarbeitung. Steigendes Informationsaufkommen, Migration, Verfügbarkeit
und Transparenz sind auch Problembereiche, die beim Entwurf von Anwendungen stets
zu berücksichtigen sind. Die Entwicklung in der Softwarebranche geht einher mit der
Entwicklung in der Hardwarebranche. Zentralistische Systeme werden vermehrt durch
Client-Server Strukturen abgelöst. Durch die Erhöhung der Rechenleistung wurde auch
die Software immer komplexer. Nimmt man als Beispiel Office-Produkte, so besitzen
diese sehr viele Funktionen die im allgemeinen Gebrauch nur selten benötigt werden oder
gänzlich unbekannt sind. Die Wartung und Erweiterung komplexer Software gestaltet
sich entsprechend schwierig. Aus diesem Grund wird vermehrt auch versucht Software in
Module zu unterteilen und bei entsprechenden Möglichkeiten diese Module auch zu
verteilen. Wird die Software als Modulkonzept (das aufteilen in Module impliziert keine
zwingende Verteilung der Module) ausgelegt, müssen auch die Mechanismen der
Datenübertragung und die Auffindung von Diensten und Informationen entsprechend den
Anforderungen angepasst werden.
Ziele verteilter Anwendungen sind entfernte Funktionalitäten zu nutzen oder entfernte
Daten lokal oder quasi-lokal (remote) verarbeiten zu können. Eine Verteilung von
Information hat nicht immer eine Verteilung der anwendbaren Funktionen zur Folge.
Umgekehrt gilt dasselbe. Zentrale Funktionalitäten greifen einerseits auf verteilte
Information zu und andererseits werden Funktionen verteilt, um möglichst nahe an den
Datenbeständen zu sein (siehe unter anderem auch Architektur des xFIND-Suchsystems
in Abschnitt 6.5).
Am Beginn dieses Kapitels werden Topologien verteilter Anwendungen vorgestellt,
um mögliche Verteilungsmechanismen für Anwendungen charakterisieren zu können.
Zur unterstützenden Erklärung einiger Topologie-Ansätze werden mögliche Lösungen,
Daten zu verteilen, anhand verschiedener Beispiele verteilter Dateisysteme, dargestellt.
Der Informationsaustausch in verteilten Systemen soll, wie bereits mehrmals erwähnt, mit
standardisierten Möglichkeiten realisiert werden. Dazu gehören transaktionsbasierte
Ansätze und die Berücksichtigung objektorientierter Technologien um eventuell auch
eine Widerverwertbarkeit von Softwaremodulen gewährleisten zu können.
Das Problem der automatisierten Identifizierung von Diensten wird von den bisher
vorgestellten Methoden (z.B. RPC) nicht abgedeckt. Im Hinblick auf die Erweiterbarkeit
der Kommunikationsschicht des xFIND-Suchsystems bezüglich Services (oder auch
Seite 26
Kapitel 4 - Verteilte Anwendungen
Web-Services) wird die herkömmliche Client-Server Technologie dem Peer-to-Peer
Ansatz gegenübergestellt und analysiert.
In weiterer Folge wird eine Auswahl an Middleware-Technologien vorgestellt, um
Aufschlüsse für die Untersuchung der Kommunikationsschicht und deren unterstützten
Übertragungsprotokolle zu erhalten. Als Basismodell wird dabei näher auf DCE
eingegangen, das in seiner Ursprungsform grundlegende Anforderungen aus dem Bereich
verteilte Informationsstrukturen abdeckt. Aus den modernen Ansätzen wie .NET, ONE
oder J2EE werden wichtige Erkenntnisse für die darauf folgenden Kapitel
Transportprotokolle (Kapitel 5) und verteilte Suchsysteme (Kapitel 6) gewonnen. Zum
Abschluss des Kapitels wird ein Einblick in die Webservice Architektur gegeben. Mit
Hilfe dieser Technologie ist es möglich, standardisiert Dienste anzubieten und zu finden.
4.2.
Topologien verteilter Anwendungen
Topologieformen finden in technischen Bereichen ein großes Anwendungsfeld.
Ausgehend von vier Basis-Typen, werden in weiterer Folge Hybrid-Systeme vorgestellt.
Sollen beim Entwurf von Software Informationen verteilt verarbeitet werden, kommen
topologische Betrachtungen schon in der Designphase der Softwareentwicklung zur
Anwendung. In weiterer Folge leiten sich auch entsprechende Übertragungsmechanismen
von der zugrunde liegenden Topologie des verwendeten Systems ab.
Der Begriff Topologie im Kontext der Informationsverarbeitung bedeutet laut Duden
„die Anordnung und Vernetzung von einzelnen Computer und Terminals innerhalb eines
Datenverbundes“. Zurzeit sind vier gängige Topologien gebräuchlich, die auch für
Anwendungen im Bereich des Internet Anwendung finden: Zentrale, dezentrale,
hierarchische und Ring basierte Systeme. Diese Topologien treten nicht nur in ihrer
eigenständigen Form auf, sondern auch in diversen Kombinationen, den so genannten
Hybrid-Systemen. Topologieüberlegungen können in verschieden Bereichen der
Informationsverarbeitung Einfluss nehmen: physikalisch (Hardwarearchitektur), logisch
(programmtechnisch),
verbindungsorientiert
(Informationsfluss),
organisatorisch
(funktionell). Eine gute Übersicht verschiedener Topologien bietet Tabelle 4.1. In dieser
Gegenüberstellung der Eigenschaften der vorgestellten Topologien stellen die Knoten in
den Graphen einzelne Computer bzw. Anwendungen dar. Die Kanten im Graphen
(Verbindungen bzw. Links) stellen Datenkanäle dar. Sie sind nicht gerichtet und stellen
den Informationsfluss dar. Dieser Abschnitt orientiert sich an den Arbeiten von [Minar
2001] [Minar 2002].
Name
Zentral
Dezentral Hierarchisch
gut
gut
schlecht
schlecht
schlecht
gut
schlecht
schlecht
gut
gut
vielleicht
schlecht
Ring
ZentralRing
ZentralDezentral
ZentralZentral
gut
gut
schlecht
gut
gut
gut
gut
gut
schlecht
gut
gut
gut
schlecht
partiell
gut
gut
partiell
schlecht
gut
partiell
partiell
schlecht
schlecht
gut
Typ
Wartbarkeit
Kohärenz
Erweiterbarkeit
Fehlertoleranz
Skalierbarkeit
Sicherheit
Partiell
Partiell
Partiell
Partiell
gut
Schlecht
Tabelle 4.1: Übersicht über Topologien verteilter Anwendungen nach [Minar 2001][Minar 2002]
Seite 27
In der nachfolgenden Auflistung werden vier gängige Topologien einander gegenüber
gestellt und in einer allgemeinen Betrachtungsweise vorgestellt. Weiters werden drei
hybride Systeme vorgestellt, welche die Vorteile der vier Basistypen vereinen. Bei der
Gegenüberstellung soll die verbindungsorientierte Ebene im Vordergrund stehen:
• Zentrale Topologie: Zentral basierte Systeme stellen nach wie vor die am häufigsten
eingesetzte Topologieform dar. Der große Vorteil liegt in der Einfachheit dieser
Topologie. Alle Daten werden an einer zentralen Stelle gehalten und gewartet. Es gibt
keine Probleme bezüglich der Konsistenz oder der Kohärenz diverser Replikate. Der
Vorteil alle Daten zentral speichern zu können ist auch zugleich der größte Nachteil
der zentralen Topologie. Fällt der Server aus, kann kein Client auf die Daten
zugreifen. Die Erweiterbarkeit dieses Systems ist gering und neue Ressourcen können
nur an einer zentralen Stelle eingefügt werden. Zentral verwaltete Systeme gelten im
Allgemeinen als schlecht skalierbar. Die Skalierbarkeit zentraler Systeme ist jedoch
leicht messbar und steht zumeist in unmittelbaren Zusammenhang mit der
Performance des Systems. Die Skalierbarkeit und die Performance des Systems kann
nur erhöht werden, in dem die zentrale Stelle erweitert wird, bzw. mehr Ressourcen
zur Verfügung gestellt bekommen.
Beispiel: Typische Anwendungen sind Client-Server Architekturen (aus Sicht der
Software) die in Datenbankanwendungen, Internet-Diensten und anderen einfachen
verteilten Anwendungen eingesetzt werden (z.B. Suchaufbau in Napster19 oder der
Anmeldevorgang von Instant-Messaging Diensten wie z.B. ICQ20). Viele Clients
kommunizieren mit einem Host bzw. einer Hostdatenbank. Im Gegensatz zu den
genannten
Vorteilen
gibt
es
auch
einen
entscheidenden
Vorteil.
Sicherheitsvorkehrungen können einfach realisiert werden.
• Dezentrale Topologie: Dezentrale Topologien besitzen in den meisten Fällen
gegensätzliche Eigenschaften zu zentralen Systemen. Die verstreute Anordnung lässt
vermuten, dass dezentrale Systeme schwer zu verwalten und unsicher sind. Der größte
Vorteil von dezentralen Systemen ist deren gute Erweiterbarkeit. Auch hat der Ausfall
einer Teilkomponente nur geringe bis keine Auswirkung auf das Gesamtsystem
(Erreichbarkeit, Datentransfer). Sie neigen deshalb fehlertoleranter und unangreifbarer
gegenüber Rechtsstreitigkeiten zu sein. Die Skalierbarkeit von dezentralen Systemen
lässt sich nur schwer messen. Wenn der Kommunikationsaufwand mit der Größe des
Systems stetig zunimmt, spricht man auch von einem schlecht skalierbaren System.
Beispiel: Beispiele für den Einsatz dezentraler Topologien wären Internet Routing21,
Gnutella22, und Freenet23. In der Theorie wird behauptet, dass ein Netzwerk umso
leistungsfähiger wird, desto mehr Server eingesetzt werden. In der Praxis zeigt sich
jedoch, dass eine Steigerung der Serveranzahl auch mehr Kommunikationsaufwand
erzeugt. Dies liefert einen Overhead um Datenbestände kohärent halten zu können.
• Hierarchische Topologie: Hierarchische Systeme gehören geschichtlich gesehen zu
den ältesten eingesetzten Systemen im Internet. Aus heutiger Sichtweise werden
hierarchische Topologien als ausgezeichnete verteilte Systeme angesehen.
Entsprechend dem Top-Down Prinzip entspricht der topologische Graph einer
19
Napster: http://www.napster.com/
ICQ: http://web.icq.com/
21
Internet Routing Protokoll: http://www.faqs.org/ftp/rfc/rfc1264.txt [RFC 1264]
22
Gnutella: http://www.gnutella.com
23
Freenet: http://freenetproject.org
20
Seite 28
Baumstruktur. Hierarchische Systeme sind leicht wartbar, da die Verbindungen bzw.
dessen Aktionen klar definiert sind. Teiläste der Bäume dürfen nicht entarten (Baum
geht in die Breite, kann zu zentralem System entarten), ansonsten können Ausfälle von
Teilknoten zu Problemen führen. Mit entsprechenden Caching-Mechanismen kann
man auf effiziente Weise Datenkohärenz erreichen. Hierarchische Strukturen sind in
der Regel gut erweiterbar. Die Ebene legt zumeist die Regeln bezüglich der
Datenverwaltung fest. Hierarchische Systeme sind fehlertoleranter als zentral
gesteuerte Systeme, mit der Ausnahme der Wurzel der Baumstruktur. Je mehr Knoten
ein System besitzt, desto schwieriger wird es auch Sicherheit im Gesamtsystem
gewährleisten zu können. Der größte Vorteil von hierarchischen Systemen ist die
überragende Skalierbarkeit des Systems. Für jede Ebene kann man durch hinzufügen
von Knoten die Teilperformance erhöhen und Lasten besser verteilen.
Beispiel: Eines der am weitest verbreiteten und bekanntesten Systeme ist das Domain
Name-Service (DNS24) im Internet zur Bestimmung von Host-IP-Adressen bzw. zum
Abbilden von Host-Namen auf Host-IP. Die Hierarchie folgt einem Top-Down Prinzip
mit Root Name-Server für die Top-Level Domain Hosts bis zu den Third-Level
Servern die die jeweiligen registrierten Informationen ihrer Domain kennen. Weitere
Beispiele für den Einsatz hierarchischer Topologien wären NTP25 und Usenet26. Eine
gute Skalierbarkeit beweißt das schon erwähnte DNS System, das in 15 Jahren von ein
paar tausend Hosts auf mehrere hundert Millionen Hosts weltweit skaliert werden
konnte. Das exponentielle Wachstum des Internet beruht auch auf der einfachen und
offenen Struktur hierarchischer Systeme.
• Ring Topologie: In einem Ring basierten System sind alle beteiligten Hosts
unmittelbar in einer geschlossene Kette miteinander verbunden. Um die Überlastung
eines einzelnen Hosts zu vermeiden wird stattdessen ein Host-Cluster eingesetzt. Dies
entspricht einem Load-Balancing und in weiterer Folge verfügen Ring Topologien
über eine größere Ausfallssicherheit gegenüber zentralen Topologien. Viele Vorteile
zentraler Systeme treffen auch auf Ringtopologien zu. Wartbarkeit, Datenkohärenz
und Sicherheit sind die großen Stärken. Ebenso wie zentrale Systeme sind auch
ringartige Systeme nur schwer erweiterbar.
• Hybride Systeme: Verteilte Anwendungen lassen sich nicht immer auf die vier
vorgestellten Grundtypen abbilden. Bestimmte Anforderungen erfordern eine
Kombination der Grundtypen. Knoten verfügen dabei typischerweise über mehrere
Funktionalitäten die der Topologie entsprechende Interaktionen hervorrufen. Hybride
Systeme entstehen auch durch Zusammenführen bestimmter Teile von Systemen. Man
will damit die Vorzüge der Einzelsysteme nutzen, ohne dabei deren Nachteile in Kauf
nehmen zu müssen. Dass das aber nicht gelingt ist offensichtlich. Vielmehr kommt es
auf die richtige Mischung an und Kompromisse zwischen Skalierbarkeit, Sicherheit
etc. zu finden. Nachfolgend werden nun drei hybride Topologien vorgestellt:
~ Zentral – Ring: Hier erweist sich der Einsatz einer Ringstruktur als zentrales
Element vorteilhaft, um Lastverteilung und Ausfallssicherheit zu ermöglichen. Diese
Vorteile erkauft man sich mit der Replizierung von Datenbeständen. Die Erzeugung
und Aufrechterhaltung (Kohärenz) der Redundanzen erfordert entsprechenden
Aufwand. Das Gesamtsystem vereint so die Vorteile zentraler und ringbasierter
24
DNS: http://www.ietf.org/rfc/rfc1035.txt [RFC 1035]
NTP: http://www.ntp.org [RFC 1305]
26
Usenet: http://www.usenet.org [RFC 822] [RFC 850] [RFC 977] [RFC 1036] [RFC 1123] [RFC 1153] [RFC 2076]
25
Seite 29
Systeme. Die Einfachheit und die Robustheit dieser Kombination werden auch im
vielfachen Einsatz bei hoch frequentierten Web Servern im Internet und
Datenbankservern bestätigt. Viele Clients können so Daten eines Serververbundes
anfordern, ohne große Performanceeinbusen befürchten zu müssen. Ein weiterer
wichtiger Aspekt ist die gute Skalierbarkeit. Reicht die Performance nicht aus, wird
das Ringsystem um Komponenten erweitert.
~ Zentral – Dezentral: Systeme, die dieser Kombination genügen, folgen meist dem
Prinzip, dass Knoten dezentral miteinander im Verbund stehen und gleichzeitig auch
als zentrale Anlaufstelle auftreten. Diese Kombination bietet den Vorteil guter
Erweiterbarkeit bzw. Fehlertoleranz. Die partielle Zentralisierung liefert dem System
eine bessere Datenkohärenz als ein rein dezentrales System, aber die Wartbarkeit und
Sicherheit wird dadurch nicht erheblich verbessert. Noch immer sind verschiedene
Hosts für sich und deren Content selbst verantwortlich. Zu beachten ist dabei, dass
zentrale Knoten nicht notwendigerweise auch der Einstiegspunkt in die Struktur
darstellen. Der größte Vorteil, der sich aus diesem hybriden System ergibt, ist die
überragende Skalierbarkeit des Systems.
Beispiel: Der Email Versand per Internet fällt in diesen Bereich und skaliert für
mehrere hundert Millionen Benutzer immer noch zufrieden stellend. Gerade im
Bereich der Peer-to-Peer Anwendungen bietet dieser hybride Ansatz ungeahnte
Möglichkeiten. JXTA27 mit seiner World Peer Group und Gnutella machen sich so
genannte „Supernodes“ zu Nutze, über die Identifikation, Suche, und andere Dienste
laufen. Der Datenaustausch erfolgt dann meist von Client zu Client auf direktem
Wege.
~ Zentral – Zentral: Bei diesen Systemen wird versucht, die Repräsentationsschicht
von der Funktionalen- bzw. der Datenschicht zu trennen. Dies ermöglicht eine
getrennte Weiterentwicklung der verschiedenen Einzelsysteme. Ebenso fällt es
dadurch leichter andere Systeme (Dienste) an das Gesamtsystem anzukoppeln. Es
macht also durchaus Sinn entsprechende Architekturen einzusetzen um einerseits
Performanceverbesserung zu erreichen und um das System besser erweitern zu
können. Die schlechte Skalierbarkeit bleibt dabei zumeist als Nachteil dieses hybriden
Systems erhalten.
Beispiel: Ein Server in einer zentralen Topologie kann auch selbst wieder als
Ausgangspunkt einer zentralen Architektur sein. Man denke dabei an so genannte
„Multi-Tier“ Architekturen, wo Requests von einem Server angenommen werden und
diese an die Middleware (siehe Abschnitt 4.7) und an weitere Applikationen (siehe
Kapitel 6), die durchaus auf anderen Hosts laufen können, weiterleiten. Eine weitere
interessante Möglichkeit wäre die Anbindung von Web Services über entsprechende
Gateways.
Zum Entwurf der passenden Topologie gehört auch eine entsprechende Abschätzung
bezüglich der Anforderungen, wie Erweiterbarkeit und Skalierbarkeit einer verteilten
Anwendung. Ein dezentrales System ist nicht von vornherein besser oder schlechter als
das einfache zentrale System. Wählt man die Skalierbarkeit als Kriterium, dann wird man
relativ schwer ein passendes Modell finden, da dieses wiederum nur schwer messbar bzw.
zu bewerten ist. In der Theorie bietet sich das dezentrale Modell an, in der Praxis jedoch
kann man eine gute Skalierbarkeit jedoch nur erreichen, wenn auf andere Vorteile
teilweise verzichtet wird. Der Entwurf Hybrider Systeme kann durchaus einen möglichen
27
JXTA: http://www.jxta.org (Abschnitt 5.10)
Seite 30
Lösungsweg bieten, zumal hybride Systeme die Vorteile einzelner Topologien vereinen.
Der Nachteil hybrider Systeme ist mit Sicherheit deren Komplexität. Während
bestehende zentrale Systeme oder Zentral-Ring basierte Systeme häufig im Einsatz sind,
bieten dezentrale Systeme und deren Kombinationen mehr Entwicklungspotential.
Das xFIND-Suchsystem (siehe Abschnitt 6.5) kann je nach Anordnung der
Systemkomponenten in den Bereich Zentral-Dezentral oder in den Bereich ZentralZentral eingeordnet werden. Die derzeitige Verknüpfung der Systemteile erfolgt starr
aufgrund vorgegebener Konfigurations-Dateien. Eine Erhöhung der Skalierbarkeit ist
entsprechend
nur
mit
größerem
Administrationsaufwand
verbunden.
Sicherheitsmechanismen in der Datenübertragung wurden bisher nicht berücksichtigt. Da
vor allem das Entwicklungspotential der Hybrid-Systeme recht groß eingeschätzt wird,
werden auch in weiterer Folge Systeme dieser Kategorien näher untersucht.
Die vorgestellten Topologien sind einfache und nützliche Werkzeuge, um
Architekturen verteilter Anwendungen darstellen und entwerfen zu können. Ausgehend
von den vier Grundtypen der erläuterten Topologien, folgen in den nächsten Abschnitten
Erklärungen zu Funktionsweisen verteilter Anwendungen Es wird dabei auf
Basisbestandteile verteilter Anwendungen wie Transaktionen, Datentransfer und
Kommunikation (RPC, siehe Abschnitt 3.4) eingegangen und in weiterer Folge werden
Eigenschaften von verteilten Anwendungen erklärt. Hybride Topologien sind
Ausgangspunkt für moderne Middleware-Ansätze, die in die allgemeine Betrachtung von
Abschnitt 4.7 einfließen.
4.3.
Transaktionen
Die Übertragung von Daten und in weiterer Folge der Informationstransfer wird durch
verschiedene Mechanismen zur Verfügung gestellt. Die Übertragung der Daten aus Sicht
des OSI-Schichtenmodelles wird in verschiedenen Strukturebenen realisiert.
Fehlererkennung bei der Datenübertragung wird je nach Bedarf den einzelnen Schichten
überlassen. Zum Einsatz kommen einfache Fehlererkennungs-Strategien oder aber auch
Fehler korrigierende Verfahren. Die Fehlererkennung bzw. die Fehlerkorrektur allein ist
im Zuge der modernen Datenverarbeitung jedoch zuwenig. Wenn ein Fehler auftritt kann
das unter Umständen weit reichende Folgen auf verschiedene Systembereiche haben.
Wünschenswert wäre eine Art Benachrichtigung oder Synchronisation verschiedener
Systembereiche. Diese Anforderung wird aber in jedem Fall in der Applikationslogik
umzusetzen sein. Für reine Übertragungsprotokolle scheint diese Forderung zu komplex
zu sein. Im Hinblick auf diese Arbeit ist jedoch auch dieser Aspekt recht interessant, da
verteilte Systeme durchaus in der Lage sein sollten, diese Anforderungen zu erfüllen.
Eine Möglichkeit diese Anforderungen umzusetzen, ist mit dem Einsatz von
Transaktionen gegeben. Eine Transaktion hat eine spezielle Bedeutung im Bereich der
Computerwissenschaften. Eine Transaktion wird als eine Reihe oder Abfolge von
Datentransfer
Mechanismen
bezeichnet.
Dies
könnten
Datenbank
Manipulationsoperationen sein sowie Mechanismen, in denen ein Datenaustausch
zwischen Komponenten erfolgt. Dabei wird als Transaktion die Gesamtheit dieser
Abfolge von Datentransferoperationen bezeichnet. [TechTarget 1999c]
Zum Beispiel könnte man eine Warenbestellung (über das Web) als Transaktion
sehen. Ein Konsument bestellt eine Ware, indem er ein entsprechendes Formular ausfüllt
und absendet. Das Bestellsystem überprüft in den nächsten Schritten die Verfügbarkeit
der bestellten Produkte anhand von Datenbankabfragen, berechnet Preis und Lieferzeit,
Seite 31
sowie Zahlungsmodalitäten. Das System stellt die Abfrage-Ergebnisse zu einer
Antwortseite zusammen und retourniert sie dem Konsumenten. Erst wenn der Konsument
die Antwortseite bestätigt (zahlt, etc.) und er auf diese Bestätigung eine gültige
Rückmeldung vom System erhält, ist die Transaktion abgeschlossen. Tritt in dieser
Abfolge ein Fehler auf, Übertragungsfehler, Clientfehler, Serverfehler, logistische Fehler
etc., müssen alle zuvor getätigten Datenbankmanipulationen wieder korrigiert werden
(roll back). Um Transaktionen verwalten und überwachen zu können, werden so genannte
Transaktionsmanager oder Transaktions-Monitore eingesetzt. Diese Programme
verwenden ein so genanntes Two-Phase-Commit (2PC) Protokoll. [TechTarget 1999a]
[Schlichter 2000]
Eine verteilte Transaktion ist die Gesamtheit aller nicht lokalen Transferoperationen
innerhalb einer Transaktion. Eine verteilte Transaktion bedient sich dabei verschiedener
Dienste und Einrichtungen. Eine verteilte Transaktion muss der ACID28 Eigenschaft
genügen [Chen 1995]. Atomicity funktioniert nach dem alles oder nichts Prinzip. Es
werden entweder alle Daten gesichert bzw. übertragen oder gar keine. Consistency
(Konsistenz) muss nach jeder Transaktion gewährleistet sein. Es darf kein undefinierter
Zustand auftreten. Eine Transaktion führt ein System von einem konsistenten Zustand
wieder in einen konsistenten Zustand über. Transaktionen die unabhängig voneinander
ausführbar sind (parallel, ohne Abhängigkeiten) genügen der Isolations-Eigenschaft. Ist
eine Transaktion abgeschlossen, sind die Daten dauerhaft gespeichert und durch
Systemfehler nicht zerstörbar (Durability – Permanenz - Haltbarkeit). Davon
ausgenommen sind Hardwarefehler wie Festplatten Crashs etc. Das ACID Konzept einer
Transaktion wird im ISO29 Standard ISO/IEC 10026 beschrieben, wo jede der vier
genannten Eigenschaften mittels Benchmark Tests überprüft werden kann. Das
Transaction Processing Service (TPS) wird von Transaktions-Monitoren oder
Transaktions-Manager verwendet. [TechTarget 1999c] [Schlichter 2000]
Das 2PC Protokoll erlaubt es, in einem verteilten System Transaktionen zu
synchronisieren, eine Sicherstellung abzugeben wenn eine Transaktion erfolgreich
getätigt worden ist und einen Rollback-Mechanismus im Fehlerfall einer Transaktion
auszulösen. Der Transaktionsmanager koordiniert alle Transaktionen der beteiligten
Computer, indem er die Transaktions-Requests verteilt. Jeder teilnehmende Server
verwaltet für sich selbst eine Transaktions-Logdatei und sendet ein „Ready-To-Commit“
Signal an den Transaktionsmanager. Erst wenn der Transaktionsmanager von allen
beteiligten Servern das „Ready-To-Commit“ Signal bekommen hat, gilt die Transaktion
als abgeschlossen. Der Transaktionsmanager benachrichtigt nun alle beteiligten Server,
28
29
ACID: Atomicity, Consistency, Isolation, Durability
ISO: International Organisation for Standardization:
ISO/IEC 10026-2:1998
Distributed Transaction Processing -- Part 2: OSI TP Service
ISO/IEC 10026-3:1998
Distributed Transaction Processing -- Part 3: Protocol specification
ISO/IEC 10026-4:1995
Distributed Transaction Processing: Protocol Implementation Conformance Statement
(PICS) proforma
ISO/IEC 10026-5:1998
Distributed Transaction Processing -- Part 5:
Application context proforma and guidelines when using OSI TP
ISO/IEC 10026-6:1995
Distributed Transaction Processing -- Part 6: Unstructured Data Transfer
ISO/IEC 13244:1998
Open Distributed Management Architecture
ISO/IEC 14750:1999
Open Distributed Processing -- Interface Definition Language
ISO/IEC 14752:2000
Open Distributed Processing -- Protocol support for computational interactions
ISO/IEC 14753:1999
Open Distributed Processing -- Interface references and binding
ISO/IEC 14769:2001
Open Distributed Processing -- Type Repository Function
ISO/IEC 14771:1999
Open Distributed Processing -- Naming framework
ISO/IEC 14834:1996
Distributed Transaction Processing -- The XA Specification
Seite 32
dass die Transaktion abgeschlossen ist. Die Server können ihre Logdateien abschließen
und gelockte Ressourcen wieder freigeben. Im Fehlerfall können dann die Server anhand
ihrer eigenen Logdateien selbständig mit dem Rollback das System wieder in einen
konsistenten Zustand bringen. Die drei wesentlichen Signale im Two-Phase-Commit
Protokoll sind BEGINN, COMMIT und ROLLBACK im Fehlerfall. [Bjorklund 1997]
[TechTarget 1999b]
Weiters baut das Transaction Processing Service auf CCR30 und ACSE31 auf.
Aufgrund verschiedener Synchronisationsmöglichkeiten erlaubt das CCR Service
Applikationen bestimmte Vorgänge (funktionale Abläufe) als atomar zu betrachten. Diese
Vorgänge müssen wiederum der ACID Eigenschaft genügen. CCR verwendet dabei das
„Three-Phase-Commit“ Paradigma, das drei Teilnehmer zu einer Gemeinschaft vereint.
Dabei übernimmt ein Teilnehmer Kontrollfunktionen und die beiden anderen stellen die
Transaktionspartner dar. Der Kontrolleur besitzt Aufgaben wie die Transaktionspartner
zu benachrichtigen, dass sie ihre Transaktionsbereitschaft anbieten, Transaktionspartner
auffordern eine Transaktion zu beginnen, Transaktionspartner auffordern ihren Rollback
Mechanismus für eine Aktion zu starten, oder einen Wiederherstellungs- Mechanismus
bei Datenverlust in Folge von Kommunikationsproblemen oder Programmfehlern
durchzuführen. Die Transaktionspartner müssen ihre Transaktionsbereitschaft dem
Kontrolleur mitteilen, den Kontrolleur benachrichtigen wann ein Rollback Mechanismus
beendet worden ist, oder einen Wiederherstellungs- Mechanismus bei Datenverlust in
Folge von Kommunikationsproblemen oder Programmfehlern zu starten. [IFLANET
1995]
ACSE ist ein Service das Applikations-Gemeinschaften gründen und auflösen kann.
Diese Gemeinschaften werden auch als Applikations-Service Elemente bezeichnet. Diese
Service Elemente können auch untereinander in verbindungsloser (Connection-Less)
Weise oder in verbindungsorientierter (Connection-Oriented) Weise kommunizieren. Der
verbindungslose Modus besteht aus einem einfachen Daten Service, deren Requests nicht
bestätigt werden. Im Fehlerfall gehen Daten ohne Benachrichtigung der Teilnehmer
verloren. Der verbindungsorientierte Modus besteht aus zwei bestätigten Diensten
(Establishment und Release), die mittels Request und Response ihre Daten übertragen
bzw. abgleichen und einem unbestätigten Service (Abort). Mit diesen drei Diensten ist es
möglich, applikationsabhängige Daten wie Namen, Adressen, Kontext auszutauschen,
eine Authentifizierung durchzuführen, Requests anzunehmen oder abzulehnen.
[IFLANET 1995]
Im nächsten Abschnitt werden Modelle erklärt, welche Daten verteilt halten und
verwalten können. Dabei handelt es sich nicht um Datenbankmodelle, sondern um
bestehende Technologien im Bereich verteilter Dateisysteme. Anhand dieser
Technologien, soll dem Leser ein erster Einblick auf bestehende Lösungen sowie auf
Teilproblematiken wie Namensvergabe, Replikation und Transparenz gegeben werden.
30
CCR: Commitment, Concurrency, and Recovery (CCR) service (ISO 9804 and 9805)
Das ACSE Service ist im ISO 8649 Standard definiert, das ACSE Protokoll ist im ISO 8650 Standard spezifiziert.
31
ACSE: Association Control Service Element (definition: ISO 8649; specification: ISO 8650)
Seite 33
4.4.
Verteiltes Dateisystem
Verteilte Dateisysteme sind weit verbreitet, besitzen eine große Akzeptanz und setzten
bewährte Technologien ein. Weitere Vorteile sind deren Datensicherheit und die
Verwendung standardisierter Kommunikationsschnittstellen. Des Weiteren verfügen sie
über entsprechende Identifikationsmechanismen die auf verteilte Applikationen
anwendbar sind. Der Autor möchte deshalb in diesem Abschnitt einen kurzen Überblick
über verschiedene Möglichkeiten der verteilten Datenspeicherung geben. Da es eine
große Anzahl verschiedener Spezifikationen und entsprechende Implementierungen gibt,
wird im Rahmen dieser Arbeit lediglich eine Auswahl von interessanten Modellen
erwähnt. Einen guten Überblick erhält man auch in [Mullender 1993].
4.4.1.
Network File System NFS
Dieses wurde von Sun für Unix Systemumgebungen entwickelt. NFS ist eines der
bekanntesten und am weitest verbreiteten verteilte Dateisystem. Das NFS verteilt zwar
selbst keine Daten, sondern bietet die Möglichkeit über eine entsprechende Client-Server
Architektur auf Datenbestände von verschiedenen Speichereinheiten zugreifen zu
können. Die Zugriffe auf einen entfernten Datenbestand bleiben so für den Benutzer
Transparent (Location). NFS erlaubt entsprechend der Rechtevergabe für die Objekte den
schreibenden und lesenden Zugriff. Die Zugriffsrechte beschränken sich allerdings auf
lokal existierende Benutzer und Gruppen, was die Anbindung von Dateisystemen
außerhalb des Administrationsbereiches des NFS Systems unmöglich macht. Diese
Einschränkung verbietet einen global geschützten Zugriff auf verteilte Datenbestände auf
Basis von NFS. [Neubauer et al. 1998]
Backup in einem NFS System funktioniert über diverse Backup-Prozeduren der
vernetzten lokalen Dateisysteme. Ein Backup im NFS System ist so wiederum als
Gesamtheit der Einzelbackups zu sehen. Es entstehen keine zusätzlichen Kosten
bezüglich des Verwaltungsaufwandes, da das Backup eigenständig von dem jeweiligen
System durchgeführt wird. Aus diesem Grund ist auch eine komplette Rekonstruktion des
NFS Datenbestandes möglich. [Neubauer et al. 1998]
Wie schon erwähnt basiert das NFS auf einer Client-Server Architektur. Die
Kommunikationsschicht bildet das NFS Protokoll. Dieses wurde im [RFC 1094]
spezifiziert. Das NFS Protokoll setzt auf RPC Aufrufen auf und ist prinzipiell an kein
Transportmedium oder Transportprotokoll gebunden. Jedoch implizieren die RPC
Aufrufe eine vordefinierte Transportarchitektur. Dies schließt wiederum den Einsatz
verschiedener Transportprotokolle nebeneinander aus. Weiters wird das Quality of
Service32 der RPC Implementierung überlassen.
4.4.2.
Andrew File System
Das Andrew File System (AFS) baut auf der Basis Technologie einer weltweit
verteilten Client-Server-Architektur auf. Das ASF soll sich so gegenüber dem User als
eine große virtuelle Festplatte oder einem gigantischen Verzeichnis, das sich aus
Unterverzeichnissen auf der ganzen Welt zusammensetzt, präsentieren. Entwickelt wurde
das AFS an der Carnegie Mellon University33 und wird von Transarc Corporation34
32
Quality of Service (Dienstgüte): Zusammenfassung verschiedener Kriterien, die die Güte eines Dienstes im Netz
hinsichtlich Geschwindigkeit und Zuverlässigkeit beschreiben. Weiters gilt dies für die Bereitstellung einer garantierten
Dienstgüte und die Fähigkeit eines Datennetzes eine entsprechende Dienstgüte anfordern zu können.
33
Carnegie Mellon University: http://www.cmu.edu
Seite 34
weiterentwickelt und kommerziell vertrieben. Der Zusammenschluss (mounten) von
mehreren AFS Servern erlaubt einen transparenten Zugriff (Orts- und
Zugriffstransparenz) auf die gespeicherten Daten. Des Weiteren bietet das AFS System
auch eine Erweiterung der Ortstransparenz für den User selbst. Die Eindeutigkeit der File
Namen und Filegruppen ist unabhängig vom Speicherort und Zugriffsort des Users
(globaler Filename). Dies macht den Filetransfer mittels verschiedenster Protokolle (ftp,
kermit, etc.) überflüssig und so ist es in einem AFS möglich, File-Sharing mit
individuellen AFS Usern bzw. mit ausgezeichneten Gruppen von AFS Usern zu betreiben
[OSF 1991a]. Diese Form des File-Sharing ermöglicht ein gemeinschaftliches Arbeiten
an verschiedenen Dokumenten. Weiters ist ein gemeinsamer Zugriff auf verteilte
Softwarekomponenten möglich sowie der Zugriff auf dezentrale Anwendungssoftware
und Datenbankbestände. Bestimmte Untereinheiten des AFS Systems werden mit volume
bezeichnet. Die Datenübertragungsprotokolle sind für Datenübertragung in Wide-AreaNetwork (WAN) ausgelegt. Client-Caching Mechanismen reduzieren die Netzwerk- und
Serverbelastung. Die Datenübertragung selbst erfolgt über AFS RPC. Um die
Übertragungseffizienz zu steigern, werden die Daten bei der Übertragung in RPC Streams
gepackt. [OSF 1991b] [Transarc et al.]
Für die Datensicherheit ist im AFS System ein auf Kerberos35 basierender
Authentifizierungsmechanismus vorgesehen. Entsprechend muss sich ein User vor der
Nutzung der AFS Dienste am AFS System anmelden. Ist ein User ordnungsgemäß am
System angemeldet, steuern AFS Access Control Lists (ACLs) den Zugriff auf die Daten
und Ressourcen. Diese ACLs werden für jede Ressource eigenständig verwaltet und
geben Usern und Gruppen differenzierte Möglichkeiten auf Datenbestände und andere
Ressourcen (periphere Geräte) zuzugreifen. Als Beispiele der Rechteverwaltung für
verteilte Ressourcen über ACLs können die Erlaubnis Dateien auszudrucken oder
Datenbestände in Datenbanken zu bearbeiten genannt werden. [OSF 1991d]
AFS Datenbankbestände und Applikationen werden mehrfach auf File Servern
repliziert36 um einerseits Ausfallssicherheit und Zuverlässigkeit des Systems
gewährleisten zu können und andererseits die Serverlast oder auch die Netzwerklast
verteilen zu können. In Abbildung 4.1 ist eine mögliche AFS Struktur ersichtlich. Die
grau skizzierten Bereiche werden als Volume bezeichnet. Ähnlich einem Directory
Service (z.B. X.50037, LDAP38) in verteilten Computer Systemen wurde auch die
hierarchische Namensvergabe gewählt. [OSF 1991c] [Transarc 1996]
34
Transarc Corporation: http://www.transarc.com
Kerberos ist ein Authentifizierungsprotokoll für Netzwerkumgebungen und wurde am MIT entwickelt für strenge
Authentifizierung in Client/Server Anwendungen unter Verwendung von secret-key cryptography. Siehe auch
http://web.mit.edu
36
Eine Gruppe von Servern und Clients wird als cell bezeichnet.
37
X.500: ISO/IEC 9594-1:1993 Standard. Siehe auch http://www.dante.net/np/ds/osi/9594-1-X.500.A4.ps
38
LDAP: Lightweight Directory Access Protocol (v3) [RFC 2551]
35
Seite 35
Abbildung 4.1: Struktur in einem AFS System mit eindeutiger Namensgebung [Transarc 1996]
Eine Weiterentwicklung des AFS stellt das DFS (Distributed File System) von der
Open Software Foundation (OSF39) im Rahmen des Distributed Computing Environment
(DCE) dar. Das OSF/DCE System spezifisiert eine Reihe von Diensten- wie Directory
Service, Security Service, Backup Service und anderen Diensten-, angelehnt an Standards
und Quasistandards (siehe auch Abschnitt 4.7.2). Einige wesentliche Unterschiede
zwischen AFS/DFS Systemen zu NFS werden in der nachfolgenden Tabelle 4.2
dargestellt. [Transarc 1996]
AFS/DFS
File Server und Clients einer logischen Einheit bilden einen
Verbund (cell).
Globale Namensvergabe für alle Ressourcen.
Die Administration
erfolgt über Sammlungen von
Datenbeständen (volumes).
Übertragungsprotokolle sind zustandsbehaftet.
Datei besitzt Kenntnis vom Client.
Filereplizierung ermöglicht Lastverteilung.
Gute Performance in Wide-Area-Netzwerken.
System ist gut skalierbar.
Administration von jedem Client möglich.
User definierbare Gruppenrechte.
Wechselseitige Authentifizierung bei Systemprozessen
und Datenbanken. Stets Verwendung von sicheren RPC.
Keine eignen Fileserver notwendig zur Anbindung
verschiedener Rechnerarchitekturen unter Verwendung
verschiedener BS.
NFS
Jeder File Server wird eigenständig verwaltet.
Keine konsistente und allgemein gültige Namensvergabe.
Administration erfolgt für individuelle Datenbestände.
Übertragungsprotokoll ist zustandslos, keine Lock
Operationen möglich.
Keine Möglichkeiten der Lastverteilung.
Ineffizient in Wide-Area Konfiguration.
Arbeitet effizient in kleiner bis mittlere Konfiguration.
Administration über Telnet oder von ausgezeichneten
Maschinen.
Gruppenrechte werden vom Systemadministrator
vergeben.
Verwendung von Sicheren und unsichern RPC.
Zugriff von UNIX fremden Systemen nur über spezielle
Clients möglich, oder über die Anbindung an geeignete
File Server (Samba).
Tabelle 4.2: Unterschiede zwischen NFS und AFS/DFS – Systemen [Transarc 1996].
Die beiden dargestellten Möglichkeiten verteilter Dateiverwaltung stellen die
momentan gängigsten Modelle dar und decken von ihren Grundprinzipien den größten
Bereich anderer Entwicklungen ab. Weitere Entwicklungen wären das MDFS40, EDFS41,
CDFS42 die von [Kon 1996] ausführlich beschrieben bzw. miteinander verglichen wurden
39
OSF: http://www.opengroup.org
MDFS: Microsoft Distributed File System;
http://www.microsoft.com/ntserver/nts/downloads/winfeatures/NTSDistrFile/default.asp
41
EDFS: ECHO Distributed File System; ftp://ftp.cag.lcs.mit.edu/dm/papers/birrell:echo.ps.gz
42
CDFS: CODA Distributed File System; http://www.coda.cs.cmu.edu
40
Seite 36
und SFS43 das in [Gütl 2002] kurz beschrieben wird. Schon aus den Konzepten der beiden
vorgestellten Systeme NFS und AFS geht hervor, dass es in Zukunft aufgrund der
schnelllebigen Informationswelt Informationsstrukturen geben muss, die leicht skalierbar,
einfach wartbar, ortsunabhängig, und migrierbar sein müssen.
4.5.
Objektorientiertes verteiltes System - Komponentenarchitektur
Die in den vorangegangenen Abschnitten vorgestellten verteilten Systeme, basieren
zumeist auf einfache funktionale Ansätze in der Datenübermittlung. Diese funktionalen
Ansätze werden nun durch die der Integration des Objektmodells in ihrer Performanz,
Anpassungsfähigkeit und im weitesten Sinne auch in der Funktionalität erweitert. Der
folgende Abschnitt soll einen kurzen Einblick in Konzepte und den Entwurf von
verteilten Systemen auf objektorientierter Ebene liefern. Des weiteren wird versucht,
anhand von Anforderungen an verteilte Objektsysteme und deren Eigenschaften, diese zu
charakterisieren.
Die rasante Entwicklung im Bereich der verteilten Systeme führt zu immer
komplexeren monolithischen Softwarearchitekturen, die entsprechend viele Probleme
aufwerfen (z.B. Widerverwendbarkeit,). Die momentanen Anforderungen an ein
verteiltes System setzten jedoch auf kleine, selbständige Client-Server Lösungen
(vermehrt in Peer-to-Peer Technologien entwickelt), die auf einen Objektbasierten Ansatz
beruhen.
Die
Festlegung
und
die
Verwendung
standardisierter
Kommunikationsschnittstellen sind dabei ein wichtiger Aspekt. Sind diese Schnittstellen
bekannt und werden diese auch dem festgelegten Standard entsprechend eingehalten, ist
eine separierte Weiterentwicklung, die Migration und der Einsatz von Teilkomponenten
in heterogenen Systemen möglich. Die Zusammenfassung von Teilkomponenten zu
einem Framework erleichtert auch die Administration und Wartung. Diese
Zusammenfassung bestimmter Teilkomponenten (auch von verschiedenen Herstellern)
wird auch als Componentware bezeichnet. Die Vorteile der Softwareentwicklung mittels
Componentware liegen vor allem in der hohen Anpassungsfähigkeit der Teilmodule und
deren raschen Entwicklungszeit. [Fähnrich 2001]
Grundgedanken des Objektorientierten Ansatzes und die Entwicklung von
Teilkomponenten sind die mögliche Verwendung von Standard-Komponenten
unterschiedlicher Hersteller zum Einsatz in einem Gesamtsystem wie auch eine
Widerverwertbarkeit von Softwaremodulen. Dies deckt sich mit den Anforderungen an
verteilte Systemdienste, bzw. stellt erste Lösungsansätze für den Problembereich
Steigerung der Akzeptanz zur Verfügung. Weiters verlagert sich die Entwicklung weg
von der Programmierung zu einer Montage verschiedener Komponenten. Eine Definition
von Softwarekomponenten gibt Szyperski wie folgt an:
„Softwarekomponenten bezeichnet die Zusammenfassung von Modulen, die streng
kontextabhängig mit fix vordefinierter Spezifikation des Interface entwickelt werden.
Softwarekomponenten können unabhängig voneinander eingesetzt werden und stellen
Grundelemente der Softwareentwicklung dar“ [Szyperski 1998] 44.
Grundlegende Eigenschaften von Architektur-Komponenten sind eine funktional und
technisch abgeschlossene Einheit, deren unabhängige Entwicklung, das Anbieten bzw.
43
44
SFS: Semantic File System; http://www.objs.com/survey/OFSExt.htm
“A software component is a unit of composition with contractually specified interfaces and explicit context
dependencies only. A software component can be deployed independently and is subject to composition by third party”
[Szyperski 1998].
Seite 37
die Suche nach Diensten und die Kommunikation über definierte Schnittstellen. Ein
weiterer wichtiger Aspekt bei der Entwicklung von Softwarekomponenten ist die
Granularität (entspricht der Differenziertheit und Komplexität) der abgeschlossenen
Einheit (Endprodukt). Über den Grad der Granularität einer abgeschlossenen Einheit ist
eine Qualitätsbeurteilung des Softwareprodukts möglich. Komponenten mit geringer
Granularität besitzen wenige Schnittstellen und geringe Funktionalität. Sie sind leicht
gegebenen Anforderungen anzupassen, erfordern aber einen hohen Verwaltungsaufwand,
da mehrere Komponenten benötigt werden, um die Anforderungen zu erfüllen.
Komponenten mit hoher Granularität besitzen eine Vielzahl von Schnittstellen und
umfangreiche Funktionalität. Der Verwaltungsaufwand ist geringer, jedoch können
Anpassungen aufgrund der größeren Funktionalität komplex und aufwändig werden.
Komponentensoftware können, wie schon erwähnt, kategorisch unterteilt werden
bezüglich der Granularität. In Abbildung 4.2 wird ein Überblick über
Komponentenbasierte Softwareentwicklung in Zusammenhang mit der Granularität45 der
Architektur-Komponenten gegeben. Dieser Überblick zeigt auch den Zusammenhang
zwischen Abstraktion bzw. Unterteilung und dem Schichtaufbau der KomponentenArchitektur. [Fähnrich 2001]
Abbildung 4.2: Granularität in Komponentenbasierter Softwareentwicklung [Fähnrich 2001]
Wie schon einleitend erwähnt bezeichnet man die Zusammenfassung von
Einzelmodulen als Softwarekomponente (Componentware bzw. Applikation). Die
Module selbst kann man als eigenständige Objekte auffassen. In der folgenden Auflistung
werden Eigenschaften und Anforderungen von verteilten Objekten bzw. Module
festgelegt, um eine mögliche Basis zur Erstellung von Applikationen und
Softwarekomponenten bereitstellen zu können. Anhand dieser Eigenschaften kann auch
überprüft werden, welche Möglichkeiten der Erweiterung es für das vorliegende xFINDSuchsystem gibt. [Schmaranz 2001]:
• Transparenz: Transparenzeigenschaften können weiters unterteilt werden in:
~ Netzwerktransparenz: Die Applikation weiß nicht, ob das referenzierte Objekt lokal
vorhanden ist oder von einem anderen System zur Verfügung gestellt wurde.
~ Protokolltransparenz: Die Applikation muss sich nicht mehr darum kümmern, wie
ein Objekt angesprochen wird. Diese wichtige Anforderung wird dabei an die
Adressierung von Objekten gestellt, um bei einem möglichen Systemwechsel
45
Granularität: ist der Grad der Untergliederung in einzelne Module
Seite 38
(Protokolländerung)
auch
wiederum
eine
gültige
Objektreferenzierung
bewerkstelligen zu können.
~ Schematransparenz: Es darf bei der Adressierung von Objekten kein
Adressierungsschema des Zielsystems gespeichert werden. Dies ist aus Performanceund Skalierungsgründen eine notwendige Anforderung.
~ Instanztransparenz: Eine Adresse muss für Applikationen verschiedener Systeme
und zu verschiedenen Zeiten stets auf das gleiche Objekt verweisen.
~ Transparente Replikation: Adressen müssen unabhängig vom jeweiligen Objektort
sein um einerseits transparente Replikate von Objekten erzeugen zu können und um
andererseits bessere Skalierbarkeit und Performance bieten zu können. Dies setzt
wiederum spezielle Synchronisationsmechanismen zwischen den replizierten Objekten
voraus.
~ Plattformtransparenz: Applikationen sollen Objekte ansprechen können, die auf
verschiedenen Zielplattformen laufen (Unix, Windows, Apple, etc.) und in
verschiedenen Implementierungen vorliegen (Java, C++, etc.). Diese Forderung
impliziert die Ausnützung der jeweiligen Vorteilte von Hardware und der darauf
laufenden Software. In Java geschriebene Programme unterstützen z.B. dynamisches
Classloading zur Laufzeit. C++ Programme sind direkt für ihr Zielsystem kompiliert.
Um der Anforderung der Plattformunabhängigkeit gerecht werden zu können, bedarf
es der Festlegung und Verwendung von High-Level Protokollen. Objekte
unterschiedlicher Architekturen unterhalten sich dann über so genannte Wrapper
Objekte, die ihrerseits die High-Level Protokolle implementieren und so die
Schnittstellen des eigentlichen Objektes festlegen.
~ Applikationstransparenz: Eine Applikation, die ihrerseits aus Objekten besteht, soll
nicht das Endstadium in der Programmentwicklung sein, sondern selbst wiederum als
Objekt referenzierbar sein. Die Betrachtung einer Applikation als Objekt führt so zur
Erzeugung kleiner funktionaler Einheiten, die Teil eines Gesamtsystems sind. Die
Komplexität des Gesamtsystems (Programm) teilt sich so auf die Komplexität der
Bestandteile auf. So muss jedes Objekt für sich den Eigenschaften und Anforderungen
genügen.
• Stabilität: Die Stabilität ist neben der Anforderung bezüglich der Transparenz von
Adressen eine wichtige Eigenschaft in verteilten Objektsystemen. Wird der Zugriff
auf ein Objekt verändert, z.B. löschen eines Objektes oder Adressänderung auf Grund
eines Ortswechsel, muss klar definiert sein, wie Adressen als Objektreferenzierung
weiterhin Gültigkeit besitzen. Adressen müssen robust gegen Verschiebung (auch
löschen) und robust gegen unbeabsichtigten Austausch sein (ein beabsichtigter
Austausch wäre das Modifizieren eines Objektes).
• Verteiltheit: Ein Objekt repräsentiert sich als logische Einheit, das aus vielen
Teilobjekten von verschiedenen Systemen gebildet werden kann. Dabei kann es auch
in den verschiedenen Systemen vorkommen, dass Daten nicht zentral gehalten
werden, sondern wiederum verteilt im System liegen. Das Objektsystem selbst muss
geeignete Mechanismen vorsehen, um der Anforderung bezüglich der Betrachtung
eines virtuellen verteilten Objekts als logische Einheit gerecht werden zu können.
Entsprechend dieser hochgradigen Verteiltheit von Objekten werden auch spezielle
Anforderungen
an
Sicherheitsund
Zugriffmechanismen
gestellt.
Zugriffsmechanismen müssen dabei auch die Steuerung von Datenreplikaten
bewerkstelligen. Um eine gute Lastverteilung bewerkstelligen zu können, soll der
Zugriff auf die Daten bzw. die Replikate möglichst geographisch nahe zum
Netzwerkknoten erfolgen.
Seite 39
• Objektbegriff: Als Objekt in einem verteilten Objektsystem bezeichnet man eine
Einheit die über eine eindeutige Adresse referenzierbar ist. Ein Objekt hat die Aufgabe
Inhalte zu kapseln. Inhalte können Daten im herkömmlichen Sinne sein (Datenbanken,
Filesystem, etc.) oder aber auch verschiedene externe Ressourcen. Aus der Forderung
der Applikationstransparenz folgt, dass Objekte zu einer Objekthierarchie
zusammengefügt werden können. Dabei ist jedes Teilobjekt der Objekthierarchie
eindeutig über eine entsprechende Adresse referenzierbar. Ein Objekt kann über
beschreibende Metadaten charakterisiert werden. Entsprechend den zuletzt
beschriebenen Eigenschaften müssen Objekte auch Möglichkeiten (Interface) bieten,
einfach auf Inhalte und den Metadaten zugreifen zu können. Der Zustand von
Objekten ist abhängig von dessen Aufgabe bzw. von dessen Kontext. Objekte können
statisch Eigenschaften besitzen, d.h. rein nur Daten speichern, liefern oder
modifizieren, oder aber auch aktiv sein. Aktive Objekte führen verschiedene
eigenständige Aktionen in Abhängigkeit des Auftraggebers aus. In diese Kategorie
fallen z.B. mobile Agenten diverser Suchmaschinen. Objekte müssen auch
Möglichkeiten bieten, ihre Funktionalität bzw. deren Verwendung abfragen zu
können. Dies ist insbesondere bei aktiven Objekten von großer Wichtigkeit.
• Navigation im Objektraum: Die Transparenz- und Stabilitätseigenschaft auf der einen
Seite und die Eigenschaften von Objekten auf der anderen Seite sagen nichts über die
Problematik aus, wie man zu den Objekten gelangt, bzw. wie Objekte gefunden
werden können. Die entscheidende Frage ist also, wie man die Adresse von einem
Objekt erhält und wie man von diesem Objekt aus weitere Objekte befragen bzw.
referenzieren kann. Zurzeit gibt es zwei gängige Navigationsmöglichkeiten im
verteilten Objektraum.
~ Hierarchische Navigation: Bei der hierarchischen Navigation erfolgt der Zugriff auf
Objekte über einen definierten Einstiegspunkt. Von diesem aus gelangt man nach dem
Top-Down Prinzip zu dessen logischen „Kindern“, usw. Dabei ist die Reihenfolge der
Aufrufe entsprechend der Hierarchie vorgegeben.
~ Graphennavigation: Eine Navigation in diesem Sinne erfolgt über direkte
Referenzen. Ziele werden direkt angesprungen. Dabei stehen die Objekte nicht
unmittelbar miteinander in wechselseitiger Beziehung. D.h. es ist der Weg „zurück“
zum Ausgangspunkt unter Umständen nicht eindeutig.
Um von beiden oben genannten Navigationsmöglichkeiten profitieren zu können,
müssen Objekte an bestimmte Relationen gebunden werden. Über eine bidirektionale
Relation ist der Weg in der Graphennavigation auch rückverfolgbar. Objektorientierte
Datenbankmodelle verfolgen dieses Ziel mit ähnlichen Modellen. Das Linksystem in
Hyperwave46 etwa definiert immer eine „Parent to Children“ Beziehung als
gemeinsame Relation beider Objekte. Des Weiteren verhindern bidirektionale
Relationen sogen. „dead Links“. Das sind Referenzen die ins “Nichts” führen.
Relationen sollen auch Metainformationen halten können. Eine Klassifizierung von
Objekten und in weiterer Folge die Suche ist so über diese Relationen möglich. Aus
diesem Grund ist es auch wichtig, dass Relationen nicht typisiert sind. Diese Ansätze
bieten auch verschiedene Möglichkeiten der Navigation. Statische Varianten können
so um dynamische Varianten (aktive Objekte) erweitert werden.
Bei all den vorgestellten Navigationsvarianten darf aber nie im Adressraum selbst
navigiert werden. Würde man eine systemgebundene Adressierungsstruktur mit einer
logischen Navigationsstruktur vermischen, kommt es mit großer Wahrscheinlichkeit
46
Hyperwave: http://www.hyperwave.com
Seite 40
zu Inkonsistenzen. Die Skalierbarkeit der Adressierung geht so auf Kosten der
Navigation verloren.
• Einbettung und Kombination von Fremdsystemen: Eine große Problematik ergibt sich
bei der Einbettung von Fremdsystemen und deren Datenbeständen. Meist ist eine
Reorganisation des Datenbestandes von Nöten. Diese Migration des Datenbestandes
verursacht neben dem hohen Verwaltungsaufwand auch enorme Kosten. Aufgrund
dieser Tatsache ist die Akzeptanz, Datenbestände an neue Systeme und
Systemumgebungen anzupassen, sehr gering. Deshalb neigt man meist zur Schaffung
neuer Systemumgebungen, die den Anforderungen des alten Systems entsprechen.
Diese Neuentwicklungen widersprechen aber der Widerverwendbarkeit von Objekten
und Softwarekonstrukten. Die Neuentwicklungen gehen oft auch auf Kosten der
Funktionalität.
Verschiedene Anforderungen von unterschiedlichen Systemen zu kombinieren
erfordern standardisierte Modelle. Diese Modelle müssen auch Änderungen der
Anforderungen in Betracht ziehen. Als Beispiel wäre hier die Anforderung ein
Filesystem mit Datenbankabfragen bzw. deren Datenbestände mit den
Metainformation, die über eine externe Suchmaschine klassifiziert werden, zu
kombinieren. Meist wird als Lösung diese Anforderung auf ein bestimmtes
Datenbankmodell abzubilden, angeboten. Die Erweiterbarkeit des Datenbankmodelles
ist dann jedoch beschränkt, da das Modell zumeist nur von einem Anbieter gewartet
und erweitert wird. Günstig wäre es die Funktionalität anderer Systeme nutzen bzw.
diese in das bestehende System integrieren zu können.
• Skalierbarkeit: Skalierbarkeit impliziert eine komfortable Erweiterbarkeit des
Gesamtsystems. Dabei dürfen die bereits aufgezeigten Anforderungen bezüglich
Transparenz, Stabilität, Verteiltheit und Navigation nicht verloren gehen. Aspekte der
Skalierbarkeit von verteilten Objektsystemen sind:
~ gleichzeitige Benutzer: Das Objektsystem muss eine „vernünftige“ Anzahl von
gleichzeitigen Benutzern bedienen können.
~ Aufenthalt des Benutzers: Der Zugang zum System darf nicht nur über einen
bestimmten Einstiegspunkt ermöglicht werden.
~ Replikation von Content: Contentreplikate sind bei hohem Nutzungsgrad zur
Verringerung der Netzwerklast erforderlich. Dabei ist darauf zu achten, dass eine
Änderungsweitergabe erfolgt. Darum müssen alle Replikate mit dem Originalobjekt
synchronisiert werden. In diesem Zusammenhang ist auch an die Möglichkeit des
verteilten Sperrens von Daten (Daten werden manipuliert) zu denken.
~ Objektverwaltung: Die Verwaltung der Objekte und der Relationen bzw. der
Adressen darf nicht auf Kosten der Performance gehen. Diverse Algorithmen zur
Verwaltung müssen robust gegenüber der Veränderung der Objektanzahl und
gegenüber der Veränderung der Größe von Objekten sein.
~ Serververwaltung: Die Serveranzahl eines Systems und deren Kombination dürfen
keinen Engpass bezüglich der Skalierung bewirken. Ebenso ist beim Entwurf der
Serverstruktur (Topologie) darauf zu achten, dass die Kommunikation bei der
Replikation und der Synchronisation möglichst gering gehalten wird.
Es gibt zurzeit noch kein System, das alle oben erwähnten Eigenschaften und
Anforderungen erfüllt. Es gibt stattdessen Lösungen zu den verschiedenen
Teilproblematiken. Jedoch ist nicht gewährleistet, dass Teillösungen auch eine adäquate
Lösung für ein Gesamtsystem ergeben. Lösungen in Teilbereichen könnten wiederum mit
Lösungen anderer Teilbereiche im Widerspruch stehen. Da der Zusammenschluss von
Seite 41
Teillösungen nicht unmittelbar zum Ziel führt, muss man Kompromisse eingehen, d.h.
die Vor- und Nachteile der Teilsysteme ermitteln, miteinander vergleichen und
entsprechende Anpassungen bezüglich des Zielsystems vornehmen. [Schmaranz 2001]
Verbesserungen in der Architektur des xFIND-Suchsystems sind zwar nicht Teil
dieser Arbeit, jedoch spielen auch viele Eigenschaften bei der Erweiterung bezüglich
beim Entwurf der Kommunikationsschicht eine wichtige Rolle. Etwa die Einhaltung
Protokolltransparenz zielt darauf ab, standardisierte Schnittstellen anzubieten, um beim
Einsatz von Übertragungsprotokollen möglichst flexibel zu sein. In weiterer Folge ist
man dadurch auch unabhängiger von der zu verwendeten Hardwareumgebung
(Plattformtransparenz). Was bisher im Architekturansatz von xFIND gänzlich
unberücksichtigt blieb, ist das automatische Auffinden von möglichen Diensten oder das
Anbieten von Ressourcen. Mechanismen die durch Navigation im Objektraum
(Graphennavigation) beschrieben wurden, werden teilweise von Systemen wie JXTA als
dynamische Varianten umgesetzt.
Ein passendes Zitat als Abschluss der Abstrakten Betrachtungen formulierte Antoine de
Saint-Exupery (1900-1944) mit: Perfektion ist nicht erreicht, wenn nichts mehr
hinzugefügt werden kann, sondern wenn nichts mehr übrig ist, was man weglassen kann.
Nachdem Konzepte und Eigenschaften bzw. Anforderungen von objektorientierten
verteilten Systemen vorgestellt wurden, wird nun näher auf eine zukunftsträchtige
Technologie (Peer-to-Peer) eingegangen, die insbesondere den Anforderungen bezüglich
Transparenz, Verteiltheit und Skalierbarkeit Rechnung trägt.
4.6.
Client-Server versus Peer-To-Peer
Die bisher vorgestellten Softwarearchitekturen legen zumeist das Client-Server
Prinzip als Grundlage fest. Eine Erweiterung dieser einfachen Architektur bezüglich
Kommunikation und Verwaltung stellt der Peer-to-Peer (P2P) Ansatz dar. Im Gegensatz
zu reinen Client-Server-Lösungen, wo die Zuordnung der Software zu Client und Server
auch die Rollenverteilung festlegt, fällt diese Zuordnung bzw. die Rollenverteilung im
P2P-Ansatz. In der Informationsauffindung spielt diese Rollenverteilung eine wichtige
Rolle. Die Ergebnismenge ist abhängig von den zur Verfügung stehenden Diensten. Es ist
auch nicht klar, wer die Information schlussendlich findet bzw. in weiterer Folge wer die
Ergebnisse liefert. Gleiche Suchanfragen können zu unterschiedlichen Ergebnissen
führen, in Abhängigkeit der eingesetzten Dienste und der Rollenverteilung im Netzwerk.
Bei P2P-Architekturen werden die Komponenten als „Applikationen“ bezeichnet, die
unter gewissen Voraussetzungen als gleichberechtigt angesehen werden können. Diese
Betrachtung der Softwarekomponenten setzt auf ein stetes Geben und Nehmen
verschiedenster Dienste. Um ein besseres Verständnis für diesen Abschnitt zu
bekommen, wird zuerst nochmals die Client-Server Technologie in Bezug auf die
Kommunikationseigenschaften erklärt. Diesen Erklärungen folgen Erläuterungen zu P2P
als Technologischer Ansatz. Dem Leser werden dabei spezielle Eigenschaften bzw.
charakteristische Anforderungen des P2P-Ansatzes näher gebracht.
Reine Client-Server-Architekturen bieten nur einen streng hierarchischen
Datentransport-Mechanismus. Ein Client fordert Daten mittels eines Servercalls von
einem bestimmten Server an. Dieser reagiert auf die Anfrage des Client, sammelt die
Daten, stellt die Daten zur Verfügung und sendet diese dem anfragenden Client als
Antwort in einem definierten Format. In dieser strengen Hierarchie gibt es spezielle
Server, die Anfragen entgegen nehmen und Antworten verschicken. Clients können nur
Seite 42
Anfragen stellen und müssen auf Antworten des Servers warten. Bei dieser
Vorgehensweise ergeben sich bereits die ersten Probleme. Die Zuverlässigkeit und
Geschwindigkeit hängt zumeist von der Verfügbarkeit eines Servers oder eines
Serververbundes ab. [Möller 2001c]
P2P-Modelle hingegen vereinen oft beide Möglichkeiten, treten einerseits als Server
und andererseits als Client auf. In weiterer Folge können Peers lediglich auch nur
Vermittler sein, die anhand bestimmter Entscheidungskriterien Anfragen an weitere
Dienste weiterleiten. Dabei lassen sich schon die Vorteile des P2P Konzepts ableiten:
Bessere Skalierbarkeit, da die Anzahl der Peers nicht festgelegt bzw. beschränkt ist und
bessere Wartbarkeit durch kleinere Softwarekomponenten bzw. deren Unabhängigkeit.
Dadurch ist eine bessere Verteilung von Ressourcen möglich. [Möller 2001c]
Durch den Einsatz der Peers in einer verteilten Umgebung ist auch eine Entkopplung
der Übertragungsschicht von der funktionalen Schicht möglich. Dadurch wird wie schon
erwähnt die Anpassung an zusätzliche Dienste erleichtert und die Erweiterung der
jeweiligen Schicht vereinfacht. Mögliche Erweiterungen können einerseits zum leichteren
Datenaustausch als Konsument oder Dienstleister beitragen, andererseits bieten
Erweiterungen sowohl in der Kommunikationsschicht als auch in der Applikationslogik
neue Anwendungsmöglichkeiten. Z.B. funktionale Erweiterungen in Suchsystemen bieten
die Möglichkeit, Informationen verteilt zu sammeln bzw. zu verarbeiten. Weiters ist auch
Ressourcensharing in Bezug auf Rechenleistung mittels P2P Technologie möglich. Dabei
steht aber immer wieder die Informationsfreiheit im Widerspruch zum Schutz geistigen
Eigentums. Diese Problematik führte auch zum Zusammenbruch vom Filesharing Tool
„Napster“47. Abwandlungen von Napster und Erweiterungen im Bereich der
Transportprotokolle führen zu getarntem Datentransfer. Es werden so genannte
steganographische48
Protokolle
eingesetzt,
um
einerseits
Zensuren
und
Abhörmechanismen zu umgehen und um andererseits Zugriff auf geschützte Bereiche
(Firewall)
zu
erlangen.
Der
Ansatz
steganographische
Protokolle
als
Sicherheitsmechanismus in der Übertragungseinheit einzusetzen, fällt somit für die
Erweiterung der Übertragungsschicht des xFIND-Suchsystems völlig aus. Es geht nicht
darum, Daten mittels Trägerdateien zu verschleiern, sondern „echte“
Verschlüsselungsstrategien bei der Übertragung sensibler Daten einzusetzen. [Möller
2001d] [Puder et al. 2000]
Im Gegensatz zu Client-Server Anwendungen sind momentane P2P-Lösungen nur
schwer administrierbar. Der Grund liegt im „Wesen“ eines Peers selbst. Ein Peer wurde
entwickelt, um gleichberechtigt und autonom handeln zu können. Da diese entsprechend
der Einsatzmöglichkeit auch verteilt über das Internet vorliegen, erfolgt auch die
Administrierung dezentral und liegt im Verwaltungsbereich des jeweiligen Anbieters.
Ansätze, Peers auch zentral verwalten und administrieren zu können, gibt es bereits. Im
Open Source Projekt JXTA49 (siehe auch Abschnitt 5.10) werden sogen. „Peer47
Napster: System auf Basis P2P zum Austausch von MP3 Musikdaten; www.napster.com
Steganographie: Ein steganographisches Verfahren verheimlicht, daß überhaupt geheime Daten existieren. Der
Gedanke dahinter: Wo niemand geheime Daten vermutet, wird sie auch niemand suchen. Steganographie-Software
versteckt die geheime Datei in einem anderen Dokument. Als so genannte Trägerdateien dienen in der Regel meist
Bilder, Sound-, Video- oder Textdateien. Dieses Verfahren kann nicht nur zum Schutz von Daten benutzt werden
sondern wird auch zur Kenntlichmachung von Urheberrechten verwendet. Wer von der Verschlüsselung nichts weiß,
nutzt die betreffende Trägerdatei ohne Einschränkungen mit der passenden Anwendung. Nur wer über die
Verschlüsselung informiert ist und zudem den Zugriff auf den verwendeten Kodierungs-Schlüssel hat, kann die in der
Trägerdatei enthaltenen Informationen entschlüsseln und für sich nutzbar machen. [Glossar 2003]
49
JXTA steht für juxtapose. JXTA wurde von SUN entwickelt und als Open Source Projekt freigegeben;
http://www.jxta.org
48
Seite 43
Monitoring Hooks“ eingesetzt, um Peers zentral verwalten zu können. Die Aktualität der
Daten ist abhängig von der notwendigen Synchronisation. Mehr Replikate bewirken eine
größere Ausfallsicherheit das Gesamtsystem. Jedoch führt dies auch zu größerem
Aufwand bei Änderungsweitergaben und bei schlechten Abgleichmechanismen
unweigerlich zu einer Erhöhung der Netzwerklast. [Möller 2001c] [Möller 2001d]
Um Sicherheit in P2P-Anwendungen gewährleisten zu können, müssen im Gegensatz
zu Client-Server-Anwendungen größere Anstrengungen unternommen werden. Durch das
Bereitstellen mehrerer Dienste ist auch die Verwundbarkeit gegenüber Angriffen
ungleich höher. Das Problem liegt in der dezentralen Verwaltung der Anwendungen.
Jedes Peer-Produkt ist selbst für die Sicherheit in seiner Applikation verantwortlich und
muss auch entsprechend Vorkehrungen treffen. Indem diese Verantwortung nicht von
Zentraler
Stelle
aus
gesteuert
wird,
müssen
P2P-Systeme
sichere
Synchronisationsmechanismen vorsehen, oder in als gesichert geltenden
Vertrauensnetzen arbeiten. Die Echtheit der Daten bzw. deren Verifizierung lässt sich
durch an Namen gebundene Prüfsummen verwirklichen (siehe z.B. Webs of Trust50 oder
Freenet51). Ebenso bewirken digitale Signaturen weiteren Schutz vor Hackerangriffen.
Ein weiteres Sicherheitsrisiko birgt der Missbrauch vieler Peers als Ausgangspunkt für
einen verteilten Denial of Service. Tausende Requests, Suchanfragen, Suchergebnisse
können damit Zielrechner zum Absturz bringen. [O’Reilly 2001] [Möller 2001c]
[Freismuth 2002]
Dieser Abschnitt hat gezeigt, dass im Gegensatz zum recht unflexiblen Client-Server
Prinzip der P2P Ansatz gerade in verteilten Systemumgebungen Vorteile bringt. Den P2P
Ansatz aber zur Gänze auf das xFIND-Suchsystem abzubilden, wäre sicherlich keine
adäquate Lösung. Das xFIND-Suchsystem besteht in seiner Architektur bereits aus
einzelnen unabhängigen Komponenten. Das Problem bisher ist die recht starre
„Verdrahtung“ der Komponenten. So sind auch die Verwaltung, die Skalierbarkeit und
die Erweiterbarkeit mit größerem Administrationsaufwand verbunden. Anforderungen
wie „ich biete an“, „ich suche“, „sichere Verbindung“, „synchrone Verbindung“, „wer
kann was“ sind teilweise in bestehenden P2P Lösungen umgesetzt. Es gilt nun die
jeweiligen Mechanismen zu analysieren um Lösungsvorschläge für das xFINDSuchsystem zu finden. Beim Auffinden der Lösungen soll aber immer auch ein Vergleich
mit bestehenden standardisierten Technologien durchgeführt werden. Deshalb bietet der
nächste Abschnitt einen Überblick über Middleware-Technologien um eine geeignete
Vorauswahl von standardisierten Übertragungstechniken treffen zu können.
4.7.
Middleware als Basiskomponente für verteilte Anwendungen
Jede Applikation nutzt verschiedene Ressourcen eines Rechners. Das jeweilige
Betriebssystem bietet den Zugriff auf die Rechenleistung des Prozessors, den Speicher,
den Bildschirm, den Drucker oder andere Dienste im System. Die Verwaltung dieser
Ressourcen kann entsprechend für die meisten Applikationen gleich gestaltet werden.
Das Betriebssystem bietet den Zugriff auf die Ressourcen über entsprechende
Schnittstellen an. In einer verteilten Systemumgebung kommen zusätzlich noch weitere
Aufwände für die Applikationen hinzu. Sie müssen Dienste bereitstellen, sie müssen mit
50
Webs of Trust: Benutzer sind anonym bzw. pseudonym und bewerten Dienste nach ihrem Ermessen. Anhand des
Pseudonyms (bekannt) oder der Bewertung eines Peers erfolgt der Datenaustausch trotzdem auf eigene Gefahr;
http://www.w3.org/Consortium/Offices/Germany/sieben.html
51
Freenet: http://freenetproject.org
Seite 44
anderen Applikationen kommunizieren, sie müssen Daten dynamische verteilen können
und Applikationen müssen unabhängig voneinander wartbar sein. All diese
Anforderungen müssten speziell in jeder Applikation umgesetzt werden. Um diesen
Aufwand zu minimieren, bzw. den Entwurf verteilter Applikationen zu erleichtern wurde,
die „Middleware“ entwickelt.
Dieser Abschnitt soll dem Leser bestehende Technologien bzw. Vorschläge aus dem
Bereich Middleware vorstellen. Für den Autor der vorliegenden Arbeit steht aber die
Analyse von Standardwerkzeugen und standardisierten Übertragungsprotokollen im
Vordergrund. Die vorgestellten Technologien stellen keinen Anspruch auf
Vollständigkeit. Es wird lediglich eine spezielle Auswahl dargestellt, die einerseits
Basisfunktionalitäten für weitere Entwicklungen darstellen und andererseits MiddlewareLösungen konkurrierender Entwicklerfirmen bzw. Gremien sind.
Zu Beginn wird jedoch ein allgemeiner Überblick über die Grundfunktionalitäten und
Anwendungsbereiche von Middleware-Lösungen gegeben. Dieser allgemeinen
Betrachtung folgt eine Auflistung von ausgewählten Middleware-Technologien. Die
Reihenfolge dieser Einteilung gibt auch Zusammenhänge bezüglich Entwicklungsschritt
der Technologie und Firmenstrategien vor. Zu Beginn wird DCE (4.7.2) als allgemeiner
Ansatz zum Entwurf verteilter Anwendungen unter Verwendung standardisierter
Werkzeuge und Technologien analysiert. In weiterer Folge werden die Entwicklungen
COM (4.7.3; Datenaustausch über OLE), DCOM (4.7.4; Öffnung des COM Ansatzes für
weitere Plattformen) und .NET (4.7.5; Framework für webbasierte Dienste mit der
Unterstützung verschiedener Programmiersprachen) von Microsoft eingehend betrachtet.
Im Gegensatz zu den Ansätzen von Microsoft wird mono:: (4.7.6) als Open Source
Implementierung des .NET Ansatzes vorgestellt. Zur weiteren Analyse werden JavaLösungen von SUN die Multi-Tier Architektur J2EE (4.7.7) und ONE (4.7.8;
Spezifikation eines Frameworks zur Ausnützung offener Kommunikationsstandards)
diskutiert.
4.7.1.
Allgemeine Betrachtung
Nachfolgende Absätze orientieren sich an Arbeiten von [Lamersdorf 1996] [Puder et
al. 2000] und [Nehmer et al. 1998].
Middleware bezeichnet man allgemein als Kommunikationssoftware. Die Middleware
siedelt sich als Zwischenschicht (Softwareschicht) zwischen der Betriebssystemebene
und der Applikationsebene an. Diese Zwischenschicht ist eine Art Dienstleister, der
einerseits den Zugang zu den Betriebssystemdiensten bereit stellt und andererseits auch
die Verteilung von Applikationen auf mehrere Rechner im Netzwerk ermöglicht. Diese so
genannte Middlewareschicht stellt eine Sammlung verschiedener Technologien und
Dienste dar, die auf verschiedenen Plattformen zur Verfügung stehen. Wesentlich bei
Entwicklungen verteilter Systeme und dem Einsatz einer Middlewaretechnologie ist, dass
die Migration bereits bestehender Daten möglichst effizient und kostengünstigst
bewerkstelligt werden kann.
Durch die Integration von Applikationskomponenten in die Middleware kann der
Entwickler unabhängig von der spezifischen Kommunikations-Infrastruktur verteilte
Systeme entwerfen. Middleware als Bindeglied zwischen der Systemplattform und den
Anwendungen soll einerseits auf Standard-Schnittstellen und -Protokollen in der
Transportschicht (z.B. TCP/IP, ISO-OSI-Stack) aufsetzen sowie andererseits auch
standardisierte Benutzerschnittstellen wie DCE-RPC zur Vereinheitlichung von
Benutzoberflächen ermöglichen. Aufgaben, wie die Verwaltung von Transaktionen (siehe
Seite 45
Abschnitt 4.3), die Synchronisation (siehe Abschnitt 4.5), die Namensvergabe(siehe
Abschnitt 4.2) und die bereits erwähnte Kommunikation (siehe Abschnitt 3.4) in
verteilten heterogenen Systemumgebungen gehören zu den Grundanforderungen von
Middleware-Lösungen. Die folgende Auflistung ergänzt die eben erwähnten
Grundanforderungen um mögliche allgemeine Verteilungsbasierte Dienste:
• Kommunikations-Dienste: RPC, Message Queuing, elektronische Post, elektronischer
Datenaustausch
• System-Dienste: Event Notification, Konfigurationsmanagement, SoftwareInstallation,
Fehler-Erkennung,
Recovery-Koordination,
Authentifizierung,
Verschlüsselung, Zugriffskontrolle
• Informations-Dienste: Directory Server, Log Manager, File und Record Manager,
Anbindung
an
relationales
Datenbanksystem
bzw.
Objektorientiertes
Datenbanksystem, Repository Manager
• Ablaufkontroll-Dienste: Masken- und Grafikverarbeitung, Drucker-Verwaltung,
Hypermedia-Verbindungen, Multimedia-Aufbereitung
• Berechnungs-Dienste: Sortieren, mathematische Berechnungen, Internationalisierung,
Datenkonversion,
Die nachfolgenden Abschnitte beschreiben verschiedene Middleware Plattformen und
Technologien. Es wird dabei, wie schon zu Beginn dieses Abschnittes erwähnt,
besonderen Wert auf die verwendeten Kommunikationsmechanismen gelegt. Weiters
wird immer wieder der Aspekt der Standardisierung berücksichtigt.
4.7.2.
DCE
1988 gründeten über 400 Firmen die Organisation Open Software Foundation (OSF52).
Ziel der OSF war es, Lösungen für verteilte Systeme zu evaluieren, zu standardisieren
und eine Sammlung von Werkzeugen und Diensten zur einfachen Entwicklung verteilter
Anwendungen zur Verfügung zu stellen. Mitglieder wie Sun Microsystems, DEC und HP
forcierten bereits standardisierte Teilbereiche wie NFS, DNS, und RPC Komponenten.
Die OSF hat 1990 aus den evaluierten Systemen das Distributed Computing Environment
(DCE) entwickelt und 1992 erstmals vorgestellt. Großer Wert wurde dabei auf
Standardisierung zur breiten Unterstützung und Akzeptanz verschiedener
Softwarehersteller gelegt. Die OSF bietet auch selbst eine Referenzimplementierung an,
die in der aktuellsten Version 1.2.2 vorliegt und von der OSF kostenlos für Forschungsund Lehrzwecken zur Verfügung gestellt wird. [Lamersdorf 1996]
DCE ist eine “Cross-Platform”, die einen integrierten Satz an Diensten zur
Entwicklung und Wartung von verteilten Anwendungen zur Verfügung stellt. Als Basis
dient eine Architektur bzw. Kommunikationsumgebung, die einen einfachen
Informationsfluss in sämtliche Richtungen gewährleistet. Dabei wird auch versucht, die
Komplexität des Systems sowohl für die Anwendungsentwickler und Systemverwalter als
auch für die Endbenutzer möglichst transparent zu halten. Die DCE-Architektur ist ein
Referenzmodell bestehend aus einem Satz von acht Technologien. Diese reichen vom
Einsatz grundlegenden Technologien wie der Betriebssystemanbindung bis hin zu der
Anbindung an verschiedene Konsumentendienste (Anbindung an Applikationsebene).
Sicherheits- und Managementdienstleistungen werden dabei in allen Bereichen angeboten
und sind essentieller Bestandteil der DCE Umgebung. Der Applikationsschicht
52
OSF: http://www.osf.org
Seite 46
präsentiert sich DEC als eine logische Systemeinheit, die in zwei Teilsystemen
organisiert ist, dem DCE Secure Core und den DEC Data Sharing Diensten. Die
Architektur der DCE Umgebung ist in Abbildung 4.3 ersichtlich. Als
Programmschnittstellen (Basisdienste) für Anwendungen stehen im DCE das ThreadService, Remote Procedure Call, Time-, Directory- und Security-Service zur Verfügung.
Als höhere Dienste bezeichnet man in der DCE Umgebung das Global Directory Service,
Distributed File System, Diskless Support und die PC Integration. Diese werden dem
Anwender direkt an der Betriebssystemschnittstelle angeboten. [Nehmer et al. 1998]
[Transarc 1999]
Abbildung 4.3: Architektur der DCE Systemumgebung [Nehmer et al. 1998]
Eine DCE-Umgebung ist entsprechend der Architektur in acht Zellen (grau hinterlegte
Blöcke in Abbildung 4.3) aufgeteilt. Jede dieser Zellen fasst eine Menge von Diensten als
organisatorische Einheit zusammen. Aufgrund dieser Zellenbasierten Aufteilung der
Dienste können etwa Aufgaben, wie z.B. die Namensverwaltung und Zugriffskontrolle,
effizienter realisiert werden als durch Interaktion verschiedener Zellen. Dadurch ist das
Gesamtsystem skalierbar. Durch die Gruppierung der Dienste kann die Effizienz des
Gesamtsystems gezielt optimiert werden. Zum DCE Secure Core gehören Dienste wie
[Transarc 1999]:
• Thread Service: DCE unterstützt Multi-Threaded agierende Anwendungen, so
genannte Portable Implementierungen von leichtgewichtigen Prozessen basierend auf
dem POSIX53 threading Standard
• Remote Procedure Call (RPC): Das DCE-RPC stellt die grundlegendste
Kommunikationseinheit im System dar. Sie erlaubt lokale Prozeduraufrufe (innerhalb
einer Netzdomain), wobei der aufrufende Prozess als Client und der aufgerufene
Prozess als Server bezeichnet werden. Es gibt Möglichkeiten von synchronen und
asynchronen RPC. Die RPC Zelle bietet Transparenz in heterogenen Systemen
bezüglich der Daten Repräsentationen auf verschiedenen Hardwarearchitekturen.
• Directory Services: Das DCE Cell Directory Service (CDS) ermöglicht das logische
Ansprechen von Komponenten über einen eindeutigen Namen innerhalb einer Zelle
(Gruppe von Clients und Server). Dabei werden die logischen Namen auf
physikalische Adressen abgebildet. DCE Zellen können jedoch auch weltweit mittels
DNS über das DCE Global Directory Service (GDS) angesprochen werden.
• Security Service: Das DCE Security Service stellt Mechanismen zur Verfügung, um
die Entwicklung einer sicheren Kommunikation zwischen Client und Server
ermöglichen zu können. Bei der Identifikation erhält ein Benutzer vom PrivilegeServer ein Privilege Attribute Certificate (PAC). Mit diesem PAC wird die
Ausführung von Prozessen auf verschiedenen Rechnern erlaubt. Auch das Ermitteln
des Authorisierungsstatuses von Benutzern und das Versenden von verschlüsselten
53
POSIX: http://www.knosof.co.uk/posix.html
Seite 47
Nachrichten im Netzwerk kann benutzerabhängig ermöglicht werden. Unberechtigter
Zugriff auf Daten einer Übertragung über einen längeren Zeitraum (Client und Server)
kann verhindert werden, indem die Überprüfung des PAC für jedes Datenpaket
verlangt wird. Fünf Sicherheitsklassen erlauben eine Wahl bezüglich Sicherheit und
Performance.
• Distributed Time Service (DTS): Das DCE DTS synchronisiert die Taktgeber der
unterschiedlichen Zellen im Netzwerk. Dabei verfügt jede Zelle über mindestens einen
Time Server.
• Audit Service: Das DCE Audit Service stellt Möglichkeiten zum Erkennen und
Verwalten von kritischen Prozessen in verteilten Anwendungen zur Verfügung. Dabei
können zur leichteren Administration unterschiedliche kritische Prozesse anhand
Klassifikationsmechanismen logisch gruppiert und Status bzw. Prüfberichte mit
gelogged werden.
• Naming Gateway: Das DCE Naming Gateway ermöglicht Windows basierten Clients
das Ansprechen von verschiedenen Servern über das DCE Naming Service, ohne
explizite DCE Software auf den Clients installieren zu müssen.
Neben den DCE Core Services gibt es auch weitere wichtige DCE Data Sharing
Services, die einen leichteren Zugriff auf Datenbestände ermöglichen. Das Distributed
File System (DFS) ist ein leistungsstarkes, gut skalierbares und sicheres System zur
Datenverwaltung. Dabei stehen wiederum Aspekte der Transparenz im Vordergrund, um
dem Benutzer Zugriff auf Daten unabhängig vom Zugriffs- und Speicherort zu
ermöglichen. Im Gegensatz zu gewöhnlichen File Systemen bietet das DFS neben der
Skalierbarkeit auch den sicheren Transfer und die sichere Verwaltung der Daten im
gesamten Netzwerk. Zu den DCE Data Sharing Services gehören [Transarc 1999]:
• Distributed File System Client: Mit dem DFS Client ist ein effizienter Zugriff auf die
Daten mittels „caching“ möglich. Dabei werden über spezielle Protokolle File Updates
transparent an die Clients weitergereicht, so dass allen Benutzern derselbe
Datenbestand zur Verfügung steht.
• Base Files Service: Das BFS stellt Verbindungen zu diversen lokalen Filesystemen
her. Über diesen Dienst werden Datenbestände von DFS Dateisystemen, CD-ROMs
und anderen physikalischen Dateisystemen den DFS Clients zur Verfügung gestellt.
• Enhanced File Service: Das EFS ermöglicht Datenbestände zu replizieren, zu sichern,
zu verschieben ohne den DFS Dienst für die Endbenutzer unterbrechen zu müssen.
Durch die Verwendung von Copy-on-Write Technologie ermöglicht der EFS Dienst
Onlineverfügbarkeit der gespeicherten Daten. Das DFS Web Tool kombiniert
Replikate (eindeutige Namensvergabe) mit Sicherheit und Skalierbarkeit um
wachsende Anfragen von Webdiensten befriedigen zu können. Das EFS erlaubt
weiters den Zugriff auf die Datenbestände über Access Control Lists (ACL) und
verwaltet ein effizientes, log-basierendes physikalische File, mit dem ein schneller
Start der Server möglich ist.
• DCS NFS-to-DFS Secure Gateway: Sichere Anbindung und sicherer Zugang von NFS
Clients zu DFS Daten.
Seite 48
Eine DCE Basis Systemkonfiguration besteht aus Laufzeitbibliotheken, welche die
DCE-Client-Funktionalität bereitstellen. Jede Zelle verfügt über mindestens einen Cell
Directory Service, einen Security Service und einen Distributed Time Service. Das DCE
wurde unter Berücksichtung vieler formaler- und de facto Standards entwickelt. Einige
dieser Standards sind [Transarc 1999]:
•
•
•
•
•
Internet TCP/IP Protokolle
POSIX 1003.4a Thread Management Entwurf und POSIX 1003.6 ACL Entwürfe
CCITT X.500/ISO 9594 Directory Service
Internet DNS und Network Time Protokolle (NTP) Standards
X/Open Directory Service (XDS) und X/Open Object Management (XOM)
Applikationsspezifische Programmierinterfaces
• Internet GSS API
4.7.3.
COM
COM ist eine von Microsoft entwickelte Technologie, die eine Kommunikation
voneinander unabhängig entwickelter Windows-Applikationen ermöglicht. Beliebige
Daten können zwischen verschiedenen Anwendungen, z.B. über die Zwischenablage,
transportiert werden. Auch an eine Erweiterung Dokumentzentrierter Ansätze wurde
gedacht. Das Einbetten einer Excel-Tabelle in ein Word-Dokument wäre als Beispiel zu
nennen. Bei Doppelklick auf eingebettete Objekte startet die zugehörige Applikation
automatisch im Hintergrund. Bewerkstelligt wird dies mit dem Object Linking &
Embedding (OLE) System. Über diese standardisierte Schnittstelle ist eine
Kommunikation zweier unabhängig voneinander entwickelter Applikationen möglich.
Das OLE System wurde in seiner ersten Phase für Dokumentzentrierte Anwendungen
entwickelt.
Die Kommunikationsschicht (Dynamic Data Exchange - DDE) von COM war recht
komplex, langsam und unflexibel. Anforderungen wie die Unterstützung verschiedener
Programmiersprachen, die Einführung eines Objektorientierten Ansatzes und die
Einhaltung von Transparenzeigenschaften, führten zu einer Weiterentwicklung von OLE
auf OLE2, das auf dem Component Object Model (COM) basiert. Mit dem neuen Modell
ist nun eine einheitliche Interaktion beliebiger Komponenten möglich. Ziel des neuen
Modells ist unter anderem auch die Widerverwendbarkeit von Komponenten
bewerkstelligen zu können. Komponenten liegen in binärer Form als dynamische
Bibliothek (DLL) oder ausführbares Programm (EXE) vor. COM standardisiert
Mechanismen und Schnittstellen, wie beispielsweise Klassen zu implementieren und
anzusprechen sind. Die Grundarchitektur basiert auf dem Client–Server Modell, bei dem
das aufrufende Programm als Client bezeichnet wird und der Server eine entsprechende
Funktionalität über eine binäre Bibliothek zur Verfügung stellt. Über die Definition der
Schnittstellen mittels einer eigenen Beschreibungssprache (Microsoft Interface Definition
Language – MIDL) wird auch die Funktionsweise einer Komponente festgelegt [Röder
1999].
Objekte in der „COM-Welt“ stellen ihre Funktionalität über Schnittstellen zur
Verfügung. Für ein COM-Objekt können auch mehrere Schnittstellen definiert werden,
wobei jede Schnittstelle eine bestimmte Gruppe an Methoden zur Verfügung stellt. Ein
direkter Zugriff auf COM Objekte ist nicht möglich. Der Zugriff auf Methoden erfolgt
nur indirekt über eigene Schnittstellenzeiger. Mit diesen Schnittstellenzeigern ist eine
Kapselung der Daten und der Funktionalität möglich. Schnittstellenzeiger verweisen
Seite 49
ihrerseits wiederum auf eine Tabelle von Methodenzeigern (siehe Abbildung 4.4).
Dadurch können auch Funktionen, wie transparentes Routing (auch durch Firewalls),
implementiert werden. In COM gibt es eine universelle Basisschnittstelle IUnknown,
von der alle COM-Klassen abgeleitet werden. COM-Objekte implementieren diese
Schnittstellen und stehen so als Instanzen der Klassen zur Verfügung. COM-Klassen
können auch von mehreren Schnittstellen abgeleitet werden. Schnittestellen garantieren
für erwartetes Verhalten eines Objekts, d.h. dass die Methoden auf funktionale und
semantische Weise, gemäß der Schnittstellen-Definition, implementiert wurden. Die OLE
Unterstützung mit Drag-and-Drop ist ein bekanntes Beispiel für diese Gewährleistung.
[Stal 1998]
Abbildung 4.4: COM Schnittstelle: Schnittstellenzeiger, Methodenzeiger [Stal 1998]
COM Objekte treten in drei verschiedenen Varianten (Server) auf [Stal 1998]:
• In-Process-Server: COM-Objekte liegen als DLL Dateien vor und werden zur
Laufzeit in den Clientprozess geladen. Somit können Funktionsaufrufe vom Client
zum Server auf direktem Weg erfolgen, was ein günstiges Laufzeitverhalten
impliziert.
• Local-Server: COM-Objekte liegen als ausführbare Dateien vor, die in einem eigenen
Prozess laufen. Die Kommunikation zwischen Client und Server erfolgt über
Marshalling, das von einem Proxy/Stub Modul zur Verfügung gestellt wird.
• Remote-Server: COM-Objekte liegen verteilt im Netzwerk. Diese benötigen bei
Ausführung ebenfalls einen eigenen Prozess und entsprechen bereits dem erweiterten
Ansatz DCOM (siehe Abschnitt 4.7.4). Das Proxy/Stub Modul setzt die
Funktionsaufrufe in RPC um und ermöglicht so die Kommunikation zwischen Client
und Server über das Netzwerk.
Abbildung 4.5 zeigt den Aufbau eines COM-Servers und den schematischen Vorgang
bei einem Aufruf eines Interfaces. Im ersten Schritt stellt der Client eine Anfrage mit dem
entsprechenden Identifikator an COM (Create Object). Daraufhin durchsucht COM seine
Registry nach dem entsprechenden Interface und dem zugehörigen Server (Check
Registry). Der COM Classloader versucht nun das COM-Objekt zu referenzieren (Locate
Implementation) indem er den Zeiger auf das Interface an den Client weiterleitet. Danach
ist die Verbindung zwischen Client und Server hergestellt und der Client kann seine
Funktionsaufrufe tätigen [Koch 1998].
Seite 50
Abbildung 4.5: Schematischer Verbindungsaufbau im COM-Objektmodell [Koch 1998]
Der schematische Vorgang funktioniert für den Zugriff auf lokale COM Objekte. Will
man jedoch auch Objekte anderer Prozesse und entfernter Rechner ansprechen, geschieht
dies unter zu Hilfenahme von so genannte Proxies. Dabei stellt ein Proxy die exakt
gleichen Schnittstellen wie die zu referenzierenden Objekte zur Verfügung. Eine Client
Anfrage wird so über den Proxy „getunnelt“ an das eigentliche Objekt weitergeleitet
(Marshalling der Daten, weiterleiten von Anfragen und Antworten). Der Proxy spricht
jedoch das COM Objekt nicht direkt an, sondern verwendet dazu einem dem COM
Objekt vorgeschaltenen Stub. Die Aufgabe des Stub ist der Verbindungsaufbau mit dem
Client und die Datenübertragung (Demarshalling, Aufruf des COM Objekts). Dieser
Ansatz besitzt nun Gültigkeit für Objektreferenzierung am gleichen Server und entfernten
Servern. Der Unterschied liegt in der Kommunikationsschicht zwischen Proxy und Stub.
Sind Proxy und Stub am selben Rechner, werden COM LRPCs (Lightweight Remote
Procedure Calls) eingesetzt, die aufgrund der gemeinsamen Speicherverwaltung zu guten
Performancewerten führen. Wenn Proxy und Stub auf verschiedenen Rechnern laufen,
werden die herkömmlichen RPC Aufrufe verwendet. In Abbildung 4.6 wird der
Zusammenhang zwischen In-Process Server und Local-Process Server bzw. Remote
Prozess Server dargestellt. Die Interprozess Kommunikation über LRPC und RPC
geschieht dabei völlig transparent für den Programmierer [Williams et al. 1994].
Abbildung 4.6: COM Objektreferenzierung mittels Proxy/Stub Technologie [Williams et al. 1994]
Wenn ein Client den Versuch unternimmt, ein COM Objekt zu referenzieren, so muss
er den entsprechenden Identifikator kennen. Alle COM Objekte besitzen eine weltweit
eindeutige Identifikation, den Global Unique Identifier (GUID). Dieser GUID (128-bit
Zahl) wird von einem speziellen Algorithmus, der Parameter wie die aktuelle Uhrzeit,
Ethernet-Adresse und eine Zufallszahl berücksichtigt, generiert. Eine Unterscheidung der
Seite 51
GUID gibt es für Objekt Klassen (CLSID-Class Identifier), Schnittstellen (IDD-Interface
Identifier) und Typenbibliotheken (LIBID-Library Identifier). Nachdem jede GUID für
sich eindeutig ist, gibt es auch keine zwei gleichen Schnittstellen. Erweiterung oder
Änderung einer Schnittstelle bedeuten unweigerlich, dass eine neue Schnittstelle definiert
werden muss. Dies bringt aber auch einen entscheidenden Vorteil mit sich. Clients
können niemals in Konflikt mit bereits bestehenden Objekten geraten. Die Entwicklung
von COM Objekten erfolgt mit der Microsoft Interface Definition Language (MIDL).
Diese wurde vom DCE Standard übernommen (siehe Abschnitt 4.7.2), erweitert, um
COM Schnittstellen, COM Klassen und Typenbibliotheken erstellen zu können. Mit
speziellen IDL-Compilern werden die Definitionen in die gewünschte Zielsprache (z.B.
C++) und anschließend in das binäre Format übersetzt. Die COM Klassen (CLSID)
müssen noch in einer hierarchisch organisierten Datenbank eingetragen werden (Win32 Systemregistry), um lokalisiert bzw. adressiert werden zu können. Das COMLaufzeitsystem kann aufgrund der Relationen in der Registrierdatenbank eine Zuordnung
von COM Objekt zu seiner binären Repräsentation herstellen und den Clients zur
Verfügung stellen. [Williams et al. 1994]
4.7.4.
DCOM
Die COM Entwicklung unterstützte ursprünglich nur die Kommunikation von
Komponenten auf einem Rechner. Mit der Entwicklung von CORBA54 erweiterte
Microsoft den COM Ansatz, um auch Objekte verschiedener Rechner ansprechen zu
können. Alle gängigen Microsoft-Technologien wie OLE, ActiveX oder Dynamic
InterNet Applications (DNA) basieren auf dem COM/DCOM Ansatz. Es wurde auch
versucht, den DCOM Ansatz auf andere Plattformen wie UNIX zu portieren, um wie mit
dem CORBA Standard, plattformübergreifend agieren zu können. DCOM ist Teil der
Win32 Betriebssysteme und unterstützt so eben nur Win32-APIs. In Benchmarktests
stellte sich jedoch heraus, dass DCOM Applikationen weniger performant und schlechter
skalierbar sind, als etwa gleichwertige Applikationen in CORBA. [Stal 1998]
Die DCOM Architektur wird in Abbildung 4.7 dargestellt. Um Objekte auf anderen
Rechnern ansprechen und erzeugen zu können, muss man dem Service Control Manager
(SCM) nur den Rechnernamen und die CLSID der Objektschnittstelle übergeben.
Abbildung 4.7: Architektur des DCOM Ansatzes [MS 1996]
54
CORBA: Common Object Request Broker Architecture, wurde 1991 von der Object Management Group (OMG), einem
Standardisierungsgremium mit mehr als 700 Mitgliedern definiert. Das Kommunikationsprotokoll zwischen Object
Request Brokern (ORB) verschiedener Hersteller, welches den Meldungsaustausch über das Internet ermöglicht, wird
Internet Inter-ORB Protocol (IIOP) genannt. ORBs sind die technischen Implementierungen des CORBA Standards.
Seite 52
Der Mechanismus der Objektreferenzierung wurde bereits im vorigen Abschnitt
detailliert erklärt. Nachdem DCOM lediglich eine Erweiterung des COM Ansatzes
darstellt, wird nun versucht, die wesentlichen Unterschiede bzw. Erweiterungen zum
COM Ansatz in einer kurzen Auflistung darzustellen [MS 1996]:
• Sprachenunabhängigkeit: Dem Programmierer einer DCOM Komponente bleibt die
Wahl der Programmiersprache offen. Unterstützt werden z.B. Java, Microsoft Visual
C++®, Microsoft Visual Basic®, Delphi, PowerBuilder und Micro Focus COBOL.
Dies vereinfacht die Entwicklung von DCOM Komponenten, da bereits bekannte und
im Einsatz befindliche Entwicklungstools verwendet werden können. Ebenso können
bestehende Testumgebungen benutzt werden. Weiters ist auch denkbar, Mechanismen
wie Prototyping zur Softwareentwicklung einzusetzen, indem man erste Prototypen
mit high-level Programmiersprachen entwickelt und DCOM Eigenschaften wie
multithreading und thread pooling in einer weiteren Phase mittels C++ oder Java
integriert.
• Connection Management: Überwachung der Verbindung inkludiert auch ein
Errorhandling bei Ausfall eines Clients, Netzwerk oder Hardewarefehlers. DCOM
verwaltet auch die Referenzzähler der DCOM Objekte. Der ÜberwachungsMechanismus basiert auf einem Ping-Protokoll, indem DCOM periodisch die Clients
nach deren Status befragt. Eine Verbindung in DCOM gilt als abgebrochen, wenn auf
mehr als drei Ping-Anfragen in Folge keine Rückmeldung vom Client erfolgt. In
diesem Fall wird der entsprechende Referenzzähler dekrementiert. Dies impliziert
auch einen verteilten Garbage Collection Mechanismus, der völlig transparent für die
Applikationen abläuft. In DCOM ist eine bidirektionale Kommunikation möglich.
Dabei stehen sich Client und DCOM Objekt gleichermaßen als Provider und
Konsument gegenüber. In DCOM ist auch ein symmetrischer Verbindungsaufbau über
Netzwerkgrenzen möglich. Diese Eigenschaften bieten außer bei der Entwicklung
reiner Client/Server Lösungen auch bei Entwicklungen von P2P Anwendungen
genügend Entwicklungspotential.
• Skalierbarkeit: Verteilte Anwendungen sollen auch bei steigender Anzahl von
Benutzern noch performant ihre Funktionalität zur Verfügung stellen. In DCOM wird
die Skalierbarkeit mit Symmetric Multiprocessing (SMP) und Flexible Deployment
gewährleistet. Bei SMP werden Win32 Architekturkonzepte wie Multiprocessing auf
BS-Ebene ausgenutzt. DCOM teilt die Prozesse auf verschiedene Threads auf, die von
einem Thread Pool generiert werden, der wiederum optimiert zur Unterstützung von
Mehrprozessor Maschinen eingesetzt werden kann. Auch das Thread Management
geschieht völlig transparent für die Entwickler und den Applikationen. Die
Möglichkeit des „Flexible Deployment“ ermöglicht auch die Skalierung auf mehrere
Rechner. Aus Kostengründen ist es durchaus sinnvoller, statt einer teuren
Multiprozessormaschine, mehrere billigere Einzelrechner zu verwenden. Damit man
aber Objekte auch ohne weiteres auf mehrere Rechner verteilt einsetzten kann, müssen
diese auch entsprechend dafür ausgelegt werden. Zugriff auf eine gemeinsame
Datenbank, oder diverse Abgleichmechanismen sind nur zwei wichtige
Anforderungen, damit vernünftig skaliert werden kann. Dies muss bereits in der
Designphase in die Entwicklung einfliesen. Kritische Prozesse, die bei der Skalierung
Flaschenhälse darstellen, können in einer späteren Phase auf einen eigenen Rechner
ausgelagert werden.
Seite 53
Abbildung 4.8: Isolierung Kritischer Prozesse und Auslagerung auf eigene Server [MS 1996]
• Optimize Network Round-Trips: Ein allgemeines Problem in verteilten Systemen stellt
die ungleiche Lastverteilung auf Komponenten dar. Eine gängige Technik, um
ungleiche Lastverteilung zu vermeiden, wäre ein gesteuertes Multiplexing der Client
Anfragen. DCOM versucht diese Technik aufzugreifen, indem das Connection
Management günstige Verbindungen sucht, oder auch neue Objekte im Bedarfsfall
referenziert. Ein „Broker“ verwaltet die Referenzen gleicher Komponenten und
bestimmt deren Benutzerlast. Fordert ein Client ein Objekt von DCOM an, kann über
diesen Brokermechanismus die Referenz mit der geringsten Benutzerlast an den Client
übermittelt werden.
Abbildung 4.9: Lastverteilung mittels Brokermechanismus in DCOM [MS 1996]
Der DCOM Ansatz erlaubt auch die Inkludierung anderer Protokolle, um Objekte und
Komponenten „außerhalb“ der DCOM Welt ansprechen zu können. Ein
entsprechendes
Proxyobjekt
dient
dabei
als
Bindeglied,
um
den
Marshallingmechanismus des neuen Protokolls verwenden zu können. Der Einsatz
von Proxyobjekten und effizienteren Techniken wird oft aus performanten Gründen
gewählt. Ein Beispiel wäre die Anbindung an diverse Datenbanken über
entsprechende Driver.
• Sicherheit: DCOM verwaltet ähnlich zum NT Filesystem Access Control Lists (ACL)
für die Objekte. In diesen ACLs sind die Zugriffsrechte für Benutzer und Gruppen
festgelegt. Die ACLs können mit einem DCOM Konfigurations-Tool (DCOMCNFG)
oder über die Windows Registry verwaltet werden. Ist ein Benutzer am BS
angemeldet, garantiert dies für Authentifizierung. DCOM leitet bei Client Anfrage den
Benutzernamen zum Ziel-Rechner oder zum Ziel-Prozess weiter. DCOM führt die
Authentifizierung anhand des Benutzernamens am Ziel-Rechner durch und überprüft
die Zugriffsrechte auf das Objekt anhand dessen ACL.
Seite 54
4.7.5.
.NET
.NET ist eine Produktentwicklung von Microsoft, die als Plattform strategisch Webbasierte Dienste und Applikationen vereint. .NET stellt eine Weiterentwicklung von
Windows DNA2000 (Distributed interNet Applications Architecture) dar. Ziele von
.NET sind der Einsatz in verteilten Web-basierten Diensten, mit der Unterstützung
verschiedener Programmier-sprachen bei der Produktentwicklung. Die .Net Plattform
berücksichtigt
bei
der
Produkt-Entwicklung
die
Anbindung
von
Betriebssystemkomponenten bis hin zur Anbindung an Backoffice Produkten. Nach einer
Aussage von Bill Gates war die Motivation zur Entwicklung von .NET die Wandlung des
Internets als reine Informationsquelle hin zur Basis von Geschäftsmodellen und
Geschäftsaktivitäten. Die Möglichkeit, den Web-Browser als Transportmittel für den
Informationsaustausch unterschiedlicher Medien nutzen zu können, spielt dabei eine
entscheidende Rolle für den Anwenderbereich. Um aber nicht nur den Web-Browser als
einziges Werkzeug zur Informationsverarbeitung nutzen zu können, versucht der .NET
Ansatz über diverse Benutzerschnittstellen die Anbindung an beliebige Endgeräte zu
ermöglichen. Im Bereich Datentransport setzt .NET auf XML Lösungen auf. [Vawter et
al. 2001]
Die .NET Umgebung basiert auf dem Common Language Runtime (CLR)
Environment. Alle zur Verfügung stehenden Dienste und Komponenten werden im
selben Runtime ausgeführt. Dabei werden neben der Umsetzung von Aspekten der
Transparenz und Sicherheit auch automatische „Garbage Collection“, Exception
Handling und Debugging von verschiedenen Versionen derselben .NET Komponenten
unterstützt. Die Verwendung verschiedener Programmiersprachen im .NET-Ansatz
erlaubt etwa auch Vererbungs-mechanismen von Komponenten verschiedener
Programmiersprachen. CLR ist eine streng typisierte Systemumgebung. Verschiedene
Programmiersprachen werden entsprechend nur dann unterstützt, wenn geeignete
Compiler die Programmcodes entsprechend der CLR- Direktive umsetzen. Die
Entwicklungsumgebung Visual Studio.NET verfügt über vier CLR-taugliche Compiler.
Dabei werden die Programmiersprachen C# (sprich: C sharp), Visual Basic.NET,
JScript.NET und C++ direkt unterstützt. Zusätzlich gibt es Compiler für mehr als 20
weitere Programmiersprachen. [Löwy 2001]
Die Gemeinsamkeit bei der Entwicklung von .NET Komponenten in verschiedenen
Programmiersprachen liegt in der Verwendung gemeinsamer Basisklassen, der CLR
Typisierung und denselben CLR Vorgaben. .NET unterstützt die Verwendung von
„Namespaces“ als Separation von Klassendefinitionen. Ähnlich wie in C++ werden
Unterscheidungen des Namespaces über Präfixe von Produktnamen und Firmenname
realisiert. Der wohl wichtigste Ansatz im Bereich von Componentware, nämlich der
Entkoppelung des Programmcodes über Interfaces, erlaubt in .NET Polymorphie
bezüglich verschiedener Implementierungen eines Interfaces. .Net Applikationen werden
in einem Container zusammengefasst. Dieser Container beherbergt neben Transaktions-,
Messaging- und Security- Services auch eine Middle-Tier Schicht (Business Layer),
welche die eigentliche Logik bezüglich Verwaltung der .Net Objekte enthält. Über Active
Data Objects (ADO.NET) kommuniziert die Middle-Tier Schicht mit externen
Datenbanken. Weiters gibt es eine Anbindung externer Produkte über standardisierte
Web-Services Technologien wie SOAP (siehe Abschnitt 5.8), UDDI (siehe Abschnitt
4.8.1) und WSDL (siehe Abschnitt 4.8.2). Für die Erzeugung von dynamischen
Webseiten wird ASP.NET eingesetzt. Das Entwicklungsmodell zur Erstellung von .NET
basierten Web-Services ist in Abbildung 4.10 dargestellt [Vawter et al. 2001] [Löwy
2001].
Seite 55
Abbildung 4.10: Entwicklung von Web-Services mit .NET Component Ware [Vawter et al. 2001]
Die Umsetzung von Programmcode in ausführbaren Code, wird in der .NETArchitektur in zwei Phasen unterteilt. Im ersten Schritt wird der High-Level Code in
einen generischen Maschinen Code, der intermediate language (IL – anlog zum Java
Bytecode) genannt wird, umgesetzt. Beim erstmaligen Aufruf von Teilen aus dem IL
Code, wird dieser IL Code vom .NET Runtime Environment in einen nativen Code
umgewandelt und exekutiert. Der native Code (binäres Objekt) steht dann für die gesamte
„Lebensdauer“ eines Programms zur Verfügung. Gleiche Programm-Konstrukte aus
verschiedenen Programmiersprachen sollen so zum selben nativen Code führen. Dies
impliziert weiters, das alle .NET „tauglichen“ Programmiersprachen gleich performant
sind und leicht bzw. komfortabel zu entwickeln sind. Unterschiede gibt es lediglich in der
Art und Weise wie der Programmcode erzeugt wird. Eine persönliche Bevorzugung einer
bestimmten Programmiersprache liegt zumeist in Zusammenhang mit der verwendeten
Entwicklungsumgebung und der Kenntnis des Entwicklers.
Im Gegensatz zu COM (siehe Abschnitt 4.7.4) gibt es keine kanonische Basisklasse
(IUnknown) von der alle weiteren Klassen abgeleitet werden. .Net unterstützt keine
Klassenfabriken und keine Objektreferenz-Zähler. Der inkludierte Garbage Collection
Mechanismus erkennt nicht mehr gebrauchte Objekte und entfernt diese aus dem
Speicher. Es existiert keine Schnittstellen-Beschreibungssprache wie IDL. Die
Beschreibung der Schnittstellen wird direkt im Source Code eingetragen. Compiler
übersetzen diese Beschreibung in ein definiertes Format, den so genannte Metadaten
(Typenlibrary). Diese Metadaten beinhalten Information über das Interface, der
Klassenvererbung, der Signatur von Methoden, Datentypen, Events, Membervariablen
und weiterer verwendeten Attributen. Die Metadaten werden gemeinsam mit dem ByteCode in einer Datei gespeichert. [Löwy 2001].
Seite 56
4.7.6.
mono::
mono::55 ist eine Open Source Common Language Infrastructure Implementation der
.NET Entwicklungsplattform, in Unterstützung von GNOME56. Das GNOME Projekt
verfolgt die Idee, fehlende Technologien für die UNIX-Welt anzupassen bzw. für die
UNIX-Welt umzusetzen. Ein weiteres Ziel von GNOME ist die Unterstützung von
sprachenunabhängigen Applikationen. Ziel des mono:: Projekts von Ximian57 ist, die
.NET Plattform auf frei verfügbare Systeme zu portieren. Sämtliche Information zum
mono:: Projekt, wurde von der Homepage http://www.go-mono.com bezogen.
Folgende Technologien sind derzeit in mono:: umgesetzt, bzw. in mono:: inkludiert:
• Einen C#-Compiler, der in Zukunft für weitere Common Language Runtime (CLR)
taugliche Programmiersprachen erweitert wird. .NET unterstützt derzeit folgende
Programmiersprachen: C++, Java Script, Eiffel, Component Pascal, APL, Cobol, Perl,
Python, Scheme, Smalltalk, Standard ML, Haskell, Mercury und Oberon.
• Eine Common Language Infrastructure (CLI) Virtual Machine mit einem Just in Time
Compiler (JIT), der momentan nur für die x86 Architektur erhältlich ist, Garbage
Collector, Class Loader, eine Threading Engine. Das Runtime Environment und das
IO Model ist stark an die Win32 API angelehnt.
• Implementierungen aus der .NET Klassen-Bibliothek und Entwicklungswerkzeuge die
als CLR tauglich gelten.
Das CLR und das Common Type System (CTS) erlaubt den Zugriff auf Byte-Code
verschiedener Implementierungen (Programmiersprachen) von Applikationen und
Bibliotheken. Als Beispiel währe die Verwendung einer C#-Klasse als Subklasse in einer
Applikation, die mit C++ erstellt wurde.
4.7.7.
Java 2 Plattform - J2EE
Die Java 2 Plattform Enterprise Edition (J2EE) ist eine Multi-Tier Architektur, deren
Applikationslogik in mehrere Komponenten aufgeteilt ist. Dabei wird zwischen
funktionalen- und applikationsspezifischen Komponenten unterschieden, die auf
unterschiedlichen Rechnern installiert sein können. J2EE beinhaltet Client-TierKomponenten, Web-Tier-Komponenten, Business-Tier-Komponenten und EnterpriseInformation-System-Komponenten (EIS-Tier). In Abbildung 4.11 werden zwei
Möglichkeiten für J2EE Multi-Tier Applikationen gegeben. Alle J2EE Applikationen
bestehen zumindest aus drei Tier-Schichten. Der Client Schicht, dem J2EE Server und
der Datenbankschicht. Die Erweiterung zum klassischen Two-Tier Ansatz (Client-Server)
stellt die Mittelschicht dar, die ihrerseits als Bindeglied und Vermittler zwischen Client
und Datenbank „multithreaded“ arbeitet. Die J2EE Architektur basiert auf der
Programmiersprache Java. Schon alleine diese Basis soll den Ansatz,
plattformübergreifenden Code zu erzeugen, garantieren. Entwickler schreiben JavaSourcecode. Dieser wird in den Java Bytecode umgewandelt und vom Java Runtime
Environment interpretiert und zur Laufzeit ausgeführt.
J2EE Applikationen bestehen wie schon erwähnt aus mehreren Komponenten. Eine
Komponente ist als eigenständige, abgekapselte funktionale Einheit zu verstehen, die
über geeignete Mechanismen mit anderen Komponenten kommuniziert und den
55
http://www.go-mono.com
GNOME: http://www.gnome.org/
57
Ximian: http://www.ximian.com
56
Seite 57
Datenaustausch durchführt. Zur Kategorie der funktionalen Komponenten gehören WebKomponenten wie Java Servlets, JavaServer Pages und Enterprise JavaBeans auf der
Serverseite. Auf der Clientseite treten applikationsspezifische Komponenten in Form von
Java Applets und anderen nicht Webbasierten Clientanwendungen auf. J2EE
Komponenten werden auf dieselbe Weise wie reine Java Applikationen entwickelt. Im
Gegensatz zum Applikationsansatz müssen einzelne Komponenten der J2EE
Spezifikation genügen und stehen unter der Verwaltung von J2EE Servern. [Bodoff et al.
2002]
J2EE
Application 1
J2EE
Application 2
Application
Client
Dynamic
HTML Pages
Client
Tier
JSF Pages
Web
Tier
Enterprise
Beans
Enterprise
Beans
Business
Tier
Database
Database
EIS
Tier
Client
Machine
J2EE
Server
Machine
Database
Server
Machine
Abbildung 4.11: J2EE Multi-Tier Applikationen [Bodoff et al. 2002]
Ein weitere Motivation für den J2EE Ansatz war die Einführung einer serverseitigen
Java basierten Technologie. Thin Clients58 lagern komplexe und sicherheitskritische
Operation auf Enterprise Java Beans (EJB) aus. Diese Enterprise Java Beans werden auf
der Serverseite ausgeführt und nutzen dabei die Performance des J2EE Servers und deren
Funktionalität (siehe Übersicht Mechanismen und Funktionalität) aus. Ein weiterer
Aspekt in der Entstehungsgeschichte von J2EE war das Anbieten von webbasierten
Diensten (Web-Services). Diese Web-Services sollen nicht nur mit J2EE Diensten
Datenaustausch betreiben können, sondern auch Dienste anderer Plattformen zur
Verfügung stellen und nutzen können. Gerade in diesem speziellen Fall wurde im Bereich
des Business-Layer großen Wert auf standardisierte Übertragungs-Mechanismen Wert
gelegt. SOAP (siehe Abschnitt 5.8), UDDI (siehe Abschnitt 4.8.1), WSDL (siehe
Abschnitt 4.8.2) und ebXML (siehe Abschnitt 5.7) kommen hier als
Übertragungsprotokolle, Definitions- und Beschreibungssprachen zum Einsatz.
Herkömmliche, als „Thick-Clients“ bezeichnete Anwendungen wie Applets und Java
Applikationen, bieten meist ein spezielles User Interface (UI) und können über das
Internet Inter-ORB Protokoll (IIOP) direkt mir dem EJB-Layer kommunizieren.
JavaServer Pages (JSPs) setzen die Daten in HTML, XHTML oder WML taugliche
Informationen um, die wiederum von Web Browser und „Mobile-Clients“ interpretiert
und dargestellt werden. In Abbildung 4.12 ist die Entwicklung von webbasierten
Diensten und der Zusammenhang von Client-Tier, Web-Service Container und der
Datenbankschicht ersichtlich. Gut erkennbar ist, dass spezielle Applikationen auf der
Clientseite (eigenes GUI) über Java Servlets und proprietären Protokollen (JDBC)
einerseits und Applets und Applikationen als Thick-Client über IIOP direkt mit
verschiedenen Datenbanken kommunizieren können [Bodoff et al. 2002].
58
Schlanker Web-Client der keine direkten Datenbankabfragen und andere komplexe Funktionen ausführt.
Seite 58
Abbildung 4.12: Entwicklung von Web-Services mittels J2EE [Vawter et al. 2001]
Bevor Komponenten vom Java Runtime Environment ausgeführt werden können,
müssen diese über einen so genannten Assemblierungs-Prozess in Plattformspezifische
Funktionen umgesetzt werden. Die assemblierten Komponenten werden in J2EE
Container (siehe Abbildung 4.13) integriert und stellen ihre Funktionalität über geeignete
Interfaces zur Verfügung. J2EE eigene Interfaces bieten Mechanismen zum Transaction
Management an, eine Objektreferenzierung über das Java Naming and Directory Interface
(JNDI), remote connectivity und Sicherheitsmechanismen. In der folgenden Übersicht
werden die eben beschriebenen Punkte näher erläutert [Bodoff et al. 2002]:
• Über das J2EE Sicherheitsmodell können nur autorisierte Benutzer Web
Komponenten, Enterprise Beans und System Ressourcen benutzen.
• Das J2EE Zugriffsmodell kapselt über vordefinierte Relationen mehrere Methoden als
eine gemeinsame Einheit und behandelt diese transaktionsbasierend (ACID).
• Mittels JNDI können Komponenten Naming und Directory Services abrufen.
• Der J2EE Remote Connectivity Container verwaltet die Kommunikation zwischen
Client und Enterprise Beans. Dabei kommen Transparenzeigenschaften von verteilten
Applikationen zum Tragen. Der Client kann Methodenaufrufe remote durchführen, als
würden diese in derselben Virtual Machine aufgerufen.
Seite 59
Abbildung 4.13: J2EE Server und Container [Bodoff et al. 2002]
Die J2EE Architektur unterstützt konfigurierbare Dienste in Form von verschiedenen
Implementierungen eines Interfaces. So genannte J2EE Applikations-Container verwalten
aber auch nicht konfigurierbare Dienste wie die Kontrolle von Servletumgebungen,
Datenbankzugriffen, Ressource pooling, Daten Persistenz und Zugriff auf das J2EE API.
J2EE erlaubt auch das Überladen von nicht konfigurierbaren Diensten in eigenen
Applikationen. Dazu müssen die entsprechenden Codesegmente im eigenen EnterpriseBean inkludiert werden und den Anforderungen angepasst werden. So können etwa
eigene Such Methoden erzeugt werden, Connection Pooling zu Datenbanken und Cache –
Mechanismen implementiert werden. Die speziellen J2EE Applikations-Container
gliedern sich aufgrund ihrer Eigenschaften und Kontrollmechanismen in Client-Container
und Server-Container auf. Der J2EE Server beinhaltet das Runtime Environment, den
EJB-Container und den Web-Container. Der EJB-Container verwaltet und führt EJB aus.
Der Web-Container verwaltet Servlet- bzw. Web-Komponenten und generiert JSP Seiten.
Auf der Client-Maschine werden der Application-Client-Container (dieser verwaltet
Client Komponenten) und der Applet Container (verwaltet Applets) installiert. Der
Application-Client-Container unterstützt die direkte Kommunikation mit den EJB. Der
Applet-Container besteht aus einem Webbrowser und dem Java Plugin. In diesen
Container werden Applets integriert und die Kommunikation zwischen Applet und
Servlet verwaltet [Bodoff et al. 2002].
4.7.8.
Open Net Environment - ONE
Open Net Environment (ONE) wurde als offene Softwarearchitektur von Sun
Microsystems entwickelt. ONE stellt keine Applikation oder Sammlung von
Applikationen oder Tools dar, sondern ist eine Spezifikation die unter Mitwirkung von 23
verschiedenen Firmen erstellt wurde. Ziel ist der Entwurf möglichst „schlanker“
Applikationen unter Ausnutzung offener Kommunikationsstandards, Technologien und
Protokollen. Weiters soll mit ONE eine möglichst einfache Portierung bereits bestehender
Systeme (Programme, Datenbanken, Dienste) in ein neues Zielsystem unter
Berücksichtigung der Möglichkeiten der verteilten Architekturkonzepte ermöglicht
werden. Die ONE Architektur beinhaltet ein Entwicklungsmodell, indem Richtlinien zum
Entwurf von Web-Services vorgegeben werden. [SUN 2001]
Die Entwickler von ONE legen keinerlei Einschränkungen beim Entwurf bezüglich
Entwicklungs-Umgebung, Systemplattform und Programmiersprache fest. Jedoch darf
eine Bevorzugung von Java nicht verschwiegen werden, denn Beispielapplikationen und
Beschreibungen sind nur als JAVA Source erhältlich. Beim Entwurf der ONE Architektur
wurden zusätzlich auch einige neue Standards definiert und eingeführt. Diese werden von
Initiativen wie W3C, OASIS, IETF und anderen gefördert bzw. weiterentwickelt. Durch
Seite 60
die Ausnützung bereits bestehender Technologien möchte man eine möglichste breite
Akzeptanz erreichen. Zum Architekturkern gehören XML Initiativen und Standards,
verschiedene Java Technologien und standardisierte Übertragungsprotokolle. Eine
Übersicht über unterstützte Kern-Standards in der ONE Architektur zeigt Tabelle 4.3.
XML Standards
und Initiativen
Java
Technologien
Core
infrastructure
standards
•
Core W3C XML Recommendations (XML, DOM, XML Namespaces, XSLT, XPath, XLink,
and XPointer)
•
Development community XML parser, SAX
•
Presentation formats (XHTML, WML, and VoiceXML)
•
XML schema systems (DTD, XML Schema, RELAX, and TREX)
•
XML messaging systems (XMLP, SOAP, SwA, and ebXML Message Service)
•
XML registries and repositories (UDDI Business Registry, ebXML Registry and Repository,
and OASIS xml.org)
•
XML service description languages (WSDL and ebXML Specification Schema)
•
XML management information interchange frameworks (DMTF CIM and WBEM)
•
B2B XML frameworks (ebXML)
•
XML security systems (W3C XML Signature, W3C XML Encryption, and OASIS SAML)
•
Java 2 Platform, Enterprise Edition (J2EE™), Java 2 Platform, Standard Edition (J2SE™),
and Java 2 Platform, Micro Edition
(J2ME™)
•
Mobile Information Device Profile (MIDP)
•
Java Card™ API, Java Servlet, and JavaServer Pages™ (JSP™) technology
•
Java API for database access (JDBC™ API)
•
Java APIs for XML (Java API for XML Processing, Java API for XML Data Binding, Java
API for XML Registries, Java API for XML Messaging, and Java APIs for XML-based
RPC)
•
Lightweight Directory Access Protocol (LDAP)
•
Secure Sockets Library (SSL)
•
Hypertext Transfer Protocol (HTTP)
Tabelle 4.3: Übersicht der von ONE unterstützten Kernstandards [SUN 2001]
Die ONE Architektur kann als lebendiges System angesehen werden, das stets durch
neue Technologien in seiner Funktionalität erweitert werden kann. Der Entwurf von
Web-Services steht dabei im Vordergrund. Ein Web-Service wird bei der Entwicklung in
verschiedene diskrete Service-Komponenten aufgeteilt, um Inhalte, Applikationslogik,
Transport und Sicherheitsmechanismen voneinander trennen zu können. Der Entwurf von
Web-Services gliedert sich zwei Phasen auf.
Im ersten Schritt werden die diskreten Teile des Services entwickelt. Im zweiten
Schritt werden die als Micro-Services bezeichneten Komponenten zu größeren Einheiten
zusammengefügt (Macro-Services). Die Entwicklung der Micro-Services erfolgt mittels
gängigen Entwicklungsumgebungen, Editoren, Code-Generatoren und anderen Authoring
Werkzeugen. Um die Micro-Services zusammenfassen (assembly) zu können, kommen
„Process-Modelling Tools“, „Workflow Tools“, „Scripting Engines“ und andere
Werkzeuge zum Einsatz. In der zweiten Phase, dem Zusammenbau der diskreten
Komponenten, werden auch Anforderungen bezüglich Sicherheit und Verwaltung
integriert. Nachträglich können die Micro-Services zu jeder Zeit modifiziert,
weiterentwickelt und von neuem in die Macro-Services integriert werden.
Einen funktionellen Überblick der wichtigsten Komponenten einer Web-Service
Architektur und die Möglichkeit der Verteilung der Services, ist in Abbildung 4.14
ersichtlich. Der Block „Service Delivery“ beinhaltet Basiskomponenten wie
Seite 61
Verbindungssteuerung, Nameservice und einen Kommunikationsdienst, damit Benutzer
(z.B. über das Web und Wireless Communication) auf Dienste des Portals zugreifen
können. Jeder einzelne Block wird in einen zugehörigen Container integriert. Die
Container selbst beinhalten das Runtime Environment. Die gesamte Umgebung
(Container) läuft entsprechend auf einer geeigneten Plattform (z.B. J2EE), um
Systemaufrufe des Betriebssystems wie Fileservice, Datenbankanbindung und
Nachrichtendienste nutzen zu können [SUN 2001].
Abbildung 4.14: Web-Service Architektur in der ONE Plattform [SUN 2001]
ONE bietet nicht nur für Neuentwicklungen ein gute Plattform, sondern versucht mit
seiner Architektur auch bereits bestehende Anwendungen und Datenbestände als „Service
on Demand“ einzurichten. Für den Bereich der Integration bestehender Daten und
Applikationen versucht ONE anhand des DART (Daten, Applikationen, Reports,
Transaktionen) Modells einen effizienteren Entwurf von online verfügbaren Diensten zu
erzielen (siehe Abbildung 4.15).
Abbildung 4.15: ONE DART Modell zum effizienten Entwurf online basierter Dienste [SUN 2001]
Seite 62
Über eine entsprechende Datenarchitektur muss ein personalisierter Zugang, unter
Berücksichtigung der jeweiligen Benutzerrechte, von den gewünschten Zielsystemen aus
möglich sein. Applikationen beinhalten die Geschäftslogik. Diese auf Basis Java zu
implementieren, ermöglicht eine gute Skalierbarkeit bei entsprechender Verwendung
eines geeigneten Applikations-Servers. Applikations-Server werden von verschiedensten
Herstellern angeboten. Lediglich einige wenige kommerzielle Produkte bieten wichtige
Features wie Clustering und Lastverteilung. Allein den Online Zugang zu
Datenbeständen über angepasste Applikationen zu entwickeln wäre wohl zu wenig.
Vielmehr kommt es auch darauf an, die Verfügbarkeit und Auslastung von Diensten über
geeignete Auswerteverfahren (Reports) bewerkstelligen zu können. Die Gewährleistung
von Sicherheitsaspekten spielt vor allem im Bereich B2C und B2B eine große Rolle. Die
Einhaltung von Sicherheitsanforderungen können über spezielle transaktionsbasierte
Dienste realisiert werden. [SUN 2001]
4.7.9.
Dino - Dinopolis
Das Dino Projekt (Distributed Interactive Network Objects) ist eine MiddlewarePlattform, die seit 1997 am IICM als Open-Source System für verteilte Component
Software entwickelt wird. Auf der CeBit 1999 in Hannover wurde DINO in der Version
2.0 (Dinopolis) als Core System der Medical Telematics Plattform (MTP) in
Zusammenarbeit mit dem German Aerospace Center (DLR) als weltweit erstes verteiltes
virtuelles Patientendaten Verwaltungssystem vorgestellt. Die folgende Beschreibung des
Dino-Projektes stützt sich auf die Arbeit von [Schmaranz 2002].
Anforderungen wie Unabhängigkeit bezüglich der eingesetzten Technologie und der
eingesetzten Plattform sind bereits in die Designphase von Dinopolis eingeflossen.
Dinopolis ist ein schlankes, erweiterbares Middleware-System, dass verschiedene
Fremdsysteme integrieren, verbinden bzw. miteinander kombinieren kann. Dies kann die
Anbindung an verschiedene Datenbanken und Web-Server sein, oder aber auch die
Integration von diversen Diensten, wie z.B. Kommunikationsdiensten.
Das verteilte Komponenten-Modell wird als Kern von Dinopolis bezeichnet. Objekte
und Komponenten können beliebig im Netzwerk verteilt werden. Es ist ein spezieller
Adressierungsmechanismus vorgesehen, der eindeutige und global gültige ObjektReferenzen verwendet. Der Adressierungsmechanismus ist unabhängig vom
Aufenthaltsort der Objekte bzw. Komponenten, d.h. eine Adresse ist robust gegenüber
Verschiebungsoperationen. Im Dinopolis Modell ist weiters ein frei definierbarer
Linkmechanismus integriert, der n:m Wechselbeziehungen zwischen Objekten bzw.
Komponenten, respektive Teile davon erlaubt. Auch der Sicherheitsaspekt spielt im
Dinopolis Modell eine zentrale Rolle. Das adaptive Sicherheitskonzept in Dinopolis
erlaubt einen Rollenbasierten Zugriff auf die Objekte und Komponenten. Um den Kern
möglichst schlank halten zu können, sind Kern-Module dynamisch nachladbar, bzw. ist
der Kern quasi „on demand“ administrierbar.
Um ein möglichst universell einsetzbares System entwickeln zu können, wurde bereits
in der Designphase ein einfaches weit umfassendes, erweiterbares Objektmodell definiert.
Eigenschaften wie Inhalt, Meta-Daten, Wechselbeziehungen Operationen und Services
geben klare Trennlinien in der Objektdefinition vor. In der folgenden Auflistung werden
die wichtigsten Objekteigenschaften zusammengefasst:
• Jedes Dinopolis Objekt ist im System eindeutig adressierbar.
• Ein Dinopolis Objekt kann aus mehreren Dinopolis Objekten zusammengesetzt
werden
Seite 63
• Ein Dinopolis Objekt kapselt Inhalte. Als Inhalt werden sowohl passive Daten wie
z.B. Dokumente, als auch aktive wie z.B. „Data Streaming“ bezeichnet.
• Für jedes Dinopolis Objekt können spezifische Meta-Daten festgelegt werden. MataDaten werden im Dinopolis Projekt repräsentiert als baumartige Container Strukturen
mit hierarchischen Schlüsseln und streng typisierten Wertemengen. Die Hierarchie ist
nicht vordefiniert, d.h. eine Erweiterung der Schlüssel und der Wertemengen (Typen)
ist für jedes Objekt möglich.
• Für ein Dinopolis Objekt sind willkürliche n:m Wechselbeziehungen definierbar. Es
können ganze Objekte als „Entity“ referenziert werden, oder aber auch nur spezifische
Teile davon (z.B. Content, Meta-Daten).
• Operationen bilden frei definierbare Funktionen für ein Dinopolis Objekt ab.
• Im Gegensatz zu Operationen bilden Services Funktionen ab, die eine
Userinteraktivität erfordern.
• Ein entsprechend standardisiertes Interface bietet Zugang zu Dinopolis Objekt
Eigenschaften.
Nachdem die Eigenschaften eines Dinopolis Objekte festgelegt wurden, zeigt
Abbildung 4.16 die Struktur eines einfachen Dinopolis Objektes. Ein Dinopolis Objekt
selbst kann laut Definition aus mehreren Dinopolis Objekten gebildet werden. Die
Kombination mehrerer Dinopolis Objekte wird einerseits über die Definition von n:m
Wechselbeziehungen ermöglicht, andererseits kann der Verbund von Objekten auch
programmtechnisch (objektorientierte Programmiersprachen vorausgesetzt) über
verschiedene Vererbungsmechanismen hergestellt werden.
Abbildung 4.16 Ein einfaches Dinopolis Objekt [Schmaranz 2002]
Die Vererbung von Objekteigenschaften ist jedoch nicht die einzige Möglichkeit um
interne Verbunde herzustellen. Mechanismen wie „inclusion“, „delegation“ und
„hooks“59 sind einfach modellierbar. Eine genauere Beschreibung welche Kombinations
Möglichkeiten es gibt, ist in Kapitel 8 von [Schmaranz 2002] nachzulesen.
59
Begriffe wie Inclusiuon, Delegation und Hooks, sind in diversen Design Patterns definiert [Anmerkung des Autors]
Seite 64
Die sorgfältige Analyse des Datenflusses und des Kontrollablaufs von verschiedenen
Use-Cases, in Zusammenhang mit den Anforderungen und Eigenschaften eines Dinopolis
Objektes, führte zum Entwurf einer modularen System Architektur. Das Ziel beim
Entwurf der Architektur war es, wie schon zu Beginn erwähnt, ein möglichst schlankes
und maximal erweiterbares System zu kreieren. Weitere Projektvorgaben wie
Plattformunabhängigkeit und Programmiersprachenunabhängigkeit sind entsprechend
berücksichtigt worden. Die Dinopolis Systemarchitektur, wie sie in Abbildung 4.17 zu
sehen ist, wurde vom IICM in Zusammenarbeit mit dem German Aerospace Center
(DLR) entwickelt.
Die Pfeile stellen den Datenfluss und den Kontrollablauf dar; die verschiedenen
Kästchen repräsentieren die verschiedenen Module. Die Funktionalität von Dinopolis
wird über diverse APIs zur Verfügung gestellt. Aus Sicht der Softwareentwicklung ist ein
API (Application Programming Interface) der „View“ im „Model-View-Controller“
Paradigma. Im Sinne von Dinopolis als Middleware stellen die APIs deshalb auch keine
Funktionen für die Visualisierung bereit. Das Interessante an den verschiedenen APIs ist
jedoch die Art und Weise, wie auf die Objekteigenschaften und Funktionen zugegriffen
werden kann. Nur über so genannte „Proxies“, die vom Kernel Access Modul zur
Verfügung gestellt werden, ist ein kontrollierter (Security Checks) Zugang zu den
Objektdaten bzw. Funktionen oder Module möglich. Das Kernel Access Modul stellt eine
Art „sichere Barriere“ zum Kernel dar, da sämtliche Requests über das Kernel Access
Modul laufen. Um Multi-User Operationen bewältigen zu können, laufen sämtliche
Applikationen in einem eigenen applikationsspezifischen Kontext ab.
Im strichlierten Bereich in Abbildung 4.17 sind die einzelnen Kernel Module
dargestellt, wobei diese zur Laufzeit und bei Bedarf vom Kernel Modul Management
Tool dynamisch geladen werden. Zusätzlich werden beim Ladeprozess auch
Sicherheitschecks durchgeführt, um mögliche Angriffe von „Vieren“ oder „Trojanischen
Pferden“ vom System Kernel fernhalten zu können.
Das Kernel Management Modul ist verantwortlich für das Laden, Instantieren und
Löschen von Kernel Modulen. Weiters muss auch beim Instantieren und Löschen das
Security Modul verständigt werden. Das Security Modul ist Teil des Kernel und für die
Existenz des Kernels zwingend erforderlich. Für spezielle Applikationen, die
beispielsweise in einer gesicherten Umgebung laufen, kann das Security Modul auch
entsprechend angepasst werden.
Seite 65
Abbildung 4.17 Dinopolis System Architektur [Schmaranz 2002]
So genannte „Embedders“ sind als Hybride Module ausgeführt und trennen den
Kernel Bereich vom Benutzerbereich. Der Pfeil von den Embedders zum Kernel AccessModul beschreibt wiederum den geschützten Datenzugriff durch das Kernel Access
Modul. Im Unterschied zu den Kernel Modulen haben Embedders keinen direkten Zugriff
auf Funktionalitäten innerhalb der Kernels. Embedders können auch als spezielle Driver
angesehen werden, die ein Minimum an notwendigen Funktionen anbieten müssen
(lesender Zugriff). Das Adresshandling selbst bleibt wiederum dem System überlassen.
Für schreibende Zugriffe wird ein eigenes Interface zur Verfügung gestellt. Das
Entwerfen von Embedders kann nach denselben Richtlinien wie zum Entwurf der
Objekte verwendet werden. Durch den Einsatz von Operations, Services, Hooks,
Observern, Delegater und Events können Embedders als voll funktionsfähige Teile in das
Dinopolis System integriert werden.
Das Netzwerk Modul ist zwar als eigenständiges Modul ausgeführt, jedoch ist es fest
in den System Kernel integriert. Als Aufgabe für das Netzwerk Modul sind sämtliche
Verteilungsaspekte in Dinopolis vorgesehen. Eingehende und ausgehende Requests sind
nur über das Kernel Access Modul aufrufbar um wiederum Security Checks durchführen
zu können. Die wichtigste Aufgabe des Netzwerk Moduls ist jedoch die
Aufrechterhaltung der Netzwerktransparenz. D.h. innerhalb von Dinopolis Systemen sind
alle Objekte gleich anzusprechen, egal ob sie physisch lokal oder in externen Dinopolis
Systemen existieren.
Das Bootstrapping und Configuration Modul ist zuständig für die Erstinitialisierung,
quasi dem „Booten“ des Systems. Als erste Aktion wird das Kernel Access Modul
instantiert und danach mittels verschiedener Protokolle die anderen Module geladen. Um
auch die Sicherheit beim Booten gewährleisten zu können, wird zu Beginn ein minimales
Security Modul geladen, dass später vom eigentlichen Security Modul ersetzt wird.
Die Aufgaben des Objekt Management Moduls sind in zwei verschiede
Aufgabenbereiche unterteilt. Interne Verwaltungsaufgaben und quasi „externe“
Verwaltungsaufgaben. Zu den internen Verwaltungsaufgaben gehören das Erzeugen,
Seite 66
Laden, Speichern, Löschen und Verändern der Objekte. Weiters fallen interne
Operationen wie das Verwalten des Objekt-Content, der Meta-Daten und das Verwalten
der n:m Wechselbeziehungen in dessen Aufgabenbereich. Der externe Aufgabenbereich
umfasst alle Operationen die das Verteilen der Objekte in den verschiedenen virtuell
verteilten Dinopolis Systemen vornehmen. Dies unter der Berücksichtigung der
jeweiligen Persistenz der Objekte bezüglich Quelle-Ziel.
Das Adress Management Modul ist ähnlich wie das Objekt Management Modul in
zwei Aufgabenbereiche unterteilt. Der erste Aufgabenbereich kümmert sich wiederum
um die interne, lokale Adressierung und stellt den Zugang zu den physischen
Objektreferenzen her. Weiters bietet das lokale Adress Management Modul die Stubs für
das Globale Adress Management Handling an. Das Globale Adress Management ist im
Gegensatz zum Lokalen Adress Management Modul nicht innerhalb des Kernels
angesiedelt. Es läuft als eigener Netzwerkdienst, da es auf einen für Dinopolis neu
entwickelten, allgemein einsetzbaren globalen Referenzierungsmechanismus basiert. Der
Adressierungsalgorithmus namens DOLSA (Distributed Lookup Service Algorithm) wird
von einer separaten Architektur gesteuert. Weiterführende Informationen können in
Kapitel 7 „The Address Management Module“ von [Schmaranz 2002] nachgelesen
werden.
Das Interrelation Management Modul verwaltet alle möglichen Wechselbeziehungen
zwischen Objekten. Eine Wechselbeziehung ist ihrerseits eine Repräsentation eines
Dinopolis Objektes. Deshalb ist die Beziehung zwischen Objekt Management Modul und
Interrelation Management Modul in Abbildung 4.17 bidirektional dargestellt.
Mit dem Virtual System Management Modul kann man verschiedene Objekte, auch
von externen Systemen miteinander kombinieren. Diese virtuelle Kombination entspricht
einem neuen Dinopolis Objekt und kann entsprechend auch mit denselben Möglichkeiten
bearbeitet werden. Denkbar wäre z.B. die Verknüpfung von Objekten, die Daten aus dem
Filesystem und einer Datenbank (Meta-Informationen) kombinieren und die als
gemeinsame Instanz ansprechbar sind.
Das External System Management Modul verwaltet alle Embedders und deren
Laufzeitumgebung. Diese müssen beim External System Management Modul registriert
sein und können on demand bei Bedarf instantiert werden. Wie bereits erwähnt sind
Requests von Embedders immer auch dem Security Check des Kernel Access Moduls
unterworfen. Embedders werden auch in einem eigenen, unabhängigen Kernel Bereich
ausgeführt, der keinen direkten Zugriff auf den Kernel Bereich zulässt. Somit können
externe Systeme nur über diese Möglichkeit sicher an das System angebunden werden.
4.8.
Web Service Architektur (WSA)
Der Begriff Webservice ist in dieser Form recht allgemein gehalten und beschreibt
Dienste, die über das Web zur Verfügung gestellt werden. Dies kann z.B. ein einfacher
Webserver sein, der nur HTML Seiten liefert (Nachrichtendienst, Börsenkurse, etc.), oder
aber auch ein spezieller Dienst, der über definierte Schnittstellen den Zugriff auf die
gespeicherten Daten ermöglicht. Schon an diesen beiden Beispielen kann man erkennen,
dass der Begriff Webservice oft falsch verwendet wird bzw. missverstanden wird.
Weiters gibt es viele verschiedene Implementierungen auf unterschiedlichen Plattformen,
die zueinander nicht kompatibel sind. Zusätzlich ist das Auffinden von Webservices
meist nicht automatisiert möglich. Darum gab es vom W3C eine Initiative den Begriff
Webservice und die damit verbundene Architektur zu spezifizieren bzw. zu
standardisieren.
Seite 67
Im W3C Vorschlag wird der Begriff Webservice definiert mit: „Ein Webservice ist ein
Softwaresystem, das entwickelt wurde um Interaktionen über ein Netzwerk zwischen zwei
Maschinen abwickeln zu können. Es unterstützt ein spezielles, maschinell verarbeitbares
Interface (WSDL). Verschiedene Systeme können unter Einhaltung der Spezifikation
SOAP-Messages an das Webservice stellen. Typischerweise werden Messages in XMLserialisierter Form mit HTTP oder anderen Web spezifischen Standards übertragen. 60
[Booth et al. 2003]
Der Datenaustausch bei der WSA erfolgt in XML Notation (siehe Abschnitt 5.4).
Durch die Wahl von XML als Transportmedium ist Plattformunabhängigkeit und
Programmiersprachen-unabhängigkeit gegeben. XML ist standardisiert, weit verbreitet
und es gibt viele Werkzeuge um einfach XML Dokumente erzeugen zu können. Eine
einfache Web Service Architektur besteht aus Provider – Broker – Client. Ein Provider
meldet seinen Dienst bei einem Broker an. Um einen gewünschten Dienst zu suchen,
wendet sich ein Client an einen Broker. Dieser dient dabei als Vermittler zwischen Client
und Provider. Ist ein Dienst gefunden, kann vom Provider im ersten Schritt die
Spezifikation der Schnittstellen angefordert werden, und danach der Dienst in Anspruch
genommen werden. Ein Standard zur Registrierung von Webservices bei Brokern ist
UDDI, siehe Abschnitt 4.8.1. UDDI ist ebenfalls in XML definiert und gliedert die
registrierten Einträge wie eine Art Webverzeichnis. Als Schnittstellen Spezifikation in
WSA ebenfalls wird das standardisiert WSDL Format verwendet, siehe Abschnitt 4.8.2.
WSDL beschreibt im wesendlichen das Interface und legt Funktionen bzw. Definitionen
zu Parameter und Rückgabewerten fest. [Booth et al. 2003]
4.8.1.
UDDI
Die Abkürzung UDDI bedeutet Universal Description, Discovery and Integration.
UDDI ist standardisiert und in XML spezifiziert. Mit UDDI können Business Registries
für Webservices aufgebaut werden. Die UDDI Registry unterscheidet zwischen drei
Informationstypen: „White Pages“, „Green Pages“ und „Yellow Pages“. In White Pages
werden Business Informationen gespeichert. Dies können Kontaktinformationen oder
sonstige Unternehmensspezifische Daten sein. Mit Hilfe von White Pages kann man
gezielt nach Unternehmens spezifischen Diensten bzw. Daten suchen. Green Pages
enthalten vorwiegend technische Informationen zu einem Dienst. Dies kann z.B. auch
eine Spezifikation der Schnittstelle des Dienstes sein (WSDL). Green Pages erlauben so
die gezielte Suche nach technischen Merkmalen. In den Yellow Pages werden Dienste
nach standardisierten Taxonomien abgelegt bzw. stellen den Zugang zu den Diensten her.
Abbildung 4.18 gibt einen Überblick über die UDDI Registry und deren Einträgen.
[UDDI 2000]
Abbildung 4.18: UDDI Business Registry [Sleeper 2001]
60
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface
described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its
description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
[Booth et al. 2003]
Seite 68
UDDI besteht aus vier Hauptspezifikationen: Die Spezifikation der Datenstruktur von
Registry Einträgen wird mit XML-Schema festgelegt. Die UDDI API Spezifikation legt
fest, wie Einträge in der Registry verwaltet werden (read, insert, delete). Die Replikations
Spezifikation legt fest, wie Registry Einträge verschiedener UDDI-Anbieter miteinander
abgeglichen werden können. Die Spezifikation für UDDI-Anbieter legt Formalismen fest,
die eingehalten werden müssen, um standardisiert einen UDDI Server betreiben zu
können. Weiters wird in Folge zwischen drei verschiedenen Registry-Typen
unterschieden. Öffentliche Registries (Public) sind frei zugänglich und über das Internet
erreichbar. Semi-private Registries bieten über das Extranet (eigens verbundene
Netzwerke) beschränkten Zugriff. Private Registries gelten als Isoliert und sind nur lokal
über das Intranet erreichbar. Eine grafische Übersicht dieser Registry Typen und deren
Interaktionen gibt Abbildung 4.19. [Stencil 2002]
Abbildung 4.19: Konzept möglicher UDDI Register Typen und deren Interaktionen [Stencil 2002]
Das UDDI XML-Schema definiert vier Typen um Dienste in einer UDDI Registry
eintragen zu können. Dies sind Business Information (businessEntity), Service
Information (businessService), Binding Information (bindingTemplate) und Service
Specification Information (tModel). Als erstes Element in eines Registry Eintrages steht
das businessEntity Element. Im businessEntity Element werden einerseits Key
Identifier abgelegt wie z.B. Name, Beschreibung und Kategorien (Yellow Pages),
andererseits sind auch die Definitionen der Dienste (businessService) als
Unterelemente abgelegt. Das businessService ist eine Art Container und gruppiert
Webservices anhand spezifischer Kategorien Als zweite Substruktur der Business
Information ist das bindingTemplate Element. Im bindingTemplate Element werden
die technischen Merkmale eines Webservice vermerkt. Zusätzlich zu den technischen
Merkmalen sind Referenzen zu den jeweiligen technischen Spezifikationen eines
Webservice abgelegt, den tModel Elementen. tModel Elemente stellen eine Art
„technische Fingerabdruck“ des Webservices dar. In der tModel Struktur wird
festgehalten welche Protokolle unterstützt werden, welche Sicherheitsaspekte erfüllt
werden müssen, wie Übergabeparameter definiert sind und welche Rückgabewerte zu
erwarten sind. Einen Überblick über das UDDI Register Schema gibt Abbildung 4.20.
[UDDI 2000] 61
61
Für weiterführende Informationen zu UDDI sei auf folgende Quellen verwiesen:
http://www.uddi.org; http://www.uddi.org/whitepapers.html; http://www.stencilgroup.com
Seite 69
Abbildung 4.20: UDDI Register Schema [UDDI 2000]
4.8.2.
WSDL
Wie bei der Einführung in WSA schon erwähnt, ist WSDL (Web Service Description
Language) eine auf XML basierende Sprache, mit der die Funktionsweise von Netzwerk
Diensten (Webservices) beschrieben werden können. Eine WSDL Beschreibung stellt
eine Art Kochrezept dar, mit der Applikationen automatisiert miteinander kommunizieren
zu können. Die Funktionsweise eines Webservices legt den Datenaustausch zweier
Endpunkte in einem Netzwerk fest. Der Datenaustausch kann einerseits
nachrichtenorientiert sein, oder prozessorientiert. Es wird eine abstrakte Definition der
Operationen bzw. Nachrichten erstellt (types, message, operation, portType) und diese
dann an bestehende Datenformate und Protokolle gebunden (binding, service).
Zusätzlich kann in WSDL eine Beschreibung des Message Formates und des
Übertragungsprotokolles angegeben werden. Grundsätzlich ist die WSDL Spezifikation
offen gegenüber künftigen Nachrichtenformaten und Übertragungsprotokollen. Jedoch
werden in der vorliegenden Form (WSDL 1.1) nur Nachrichten im MIME-Format mit
SOAP (siehe Abschnitt 5.8) oder HTTP übertragen. [W3C WSDL 2001]
Ein WSDL Dokument ist grundsätzlich in mehrere Bereiche aufgeteilt [W3C WSDL
2001] [Cerami 2002]:
• definitions: Es ist das erste Element in einem WSDL Dokument, legt den Namen
des Webservice fest, definiert den Namespace des Dokumentes und beschreibt alle
notwendigen Service-Elemente.
• types: Stellt eine Sammlung von Datentypen zur Verfügung die die Funktionen des
Webservice verwenden. WSDL besitzt keine eigene Typen-Spezifikation, sondern
verwendet bestehende Typensysteme wie XSD.
• message: Beschreibt eingehende bzw. ausgehende Nachrichten bzw. deren Parameter.
• operation: Hier werden die Funktionsköpfe eines Webservice deklariert. Neben dem
Funktionsnamen werden Übergabeparameter und Rückgabewerte beschrieben.
• portType: Ermöglicht die Kombination mehrerer Messages bzw. Operations und legt
den Typ (Übertragungs- Primitiv) fest. Dabei wird unterschieden ob die Nachricht
vom Typ „One-Way“ (Client informiert Server), „Request/Response“ (Client erhält
Rückantwort vom Server), „Solicit/Response“ (Server fordert Information vom Client)
oder „Notification“ (Server informiert Client) ist.
Seite 70
• binding: In diesem Bereich werden die abstrakten Port Typen an konkrete
Übertragungsprotokolle gebunden. Es wird jeweils das Kommunikations- Protokoll
(SOAP), das Träger Protokoll (HTTP) und das Nachrichtenformat (MIME) festgelegt.
• port: Ein Port weist den zuvor definierten Bindings physikalische Netzwerkadressen
zu.
• service: Der Bereich service fasst die port Definitionen zusammen.
• documentation: Es kann in jedem Bereich beliebig oft ein Dokumentation eingefügt
werden.
• import: Es ist möglich WSDL Dokumente modular zu gestalten, indem das WSDL
Dokument in mehrere Teile gesplittet wird. Damit erreicht man einerseits eine
Trennung der Definitionen und die Möglichkeit der Widerverwendbarkeit ist gegeben.
import Statements können wiederum in jedem Teilbereich eingebunden werden.
4.9.
Schlussbemerkung
Grundlegende Basisfunktionalitäten und Eigenschaften von verteilten Systemen wie
Transparenz, Stabilität, Skalierbarkeit, Verteiltheit und Transaktionen sind wichtige
Bausteine verteilter Anwendungen. Das nicht immer alle Vorgaben realisiert werden
können, beruht in der Tatsache, dass einige Bereiche zueinander in Konkurrenz stehen.
Neue Ansätze wie Peer-to-Peer bieten jedoch auch nur Teillösungen, sind aber im
Gegensatz zu Client-Server Modellen im Vorteil bezüglich Skalierbarkeit und
Erweiterbarkeit. Mehrschichtige Architekturen erweitern den reinen Client-Server
Ansatz, indem Sie die unmittelbare Verbindung von Client zu Server auftrennen, und eine
Zwischenschicht anbieten. Diese Zwischenschicht stellt die Bindung von verteilten
Informationen zu verteilten Funktionen her. Der Client muss nicht wissen, wie und woher
er seine Informationen bekommt. Für die vorliegende Arbeit ist aber nicht der Multi-Tier
Ansatz als solcher von Interesse, sondern der Kommunikationsablauf und der
Datenaustausch zwischen den Schichten.
Im Gegensatz zum Multi-Tier Ansatz bietet die P2P Technologie Vorteile aufgrund
reduzierter Funktionalität einzelner Peers. Insbesondere beim Entwurf verteilter
Suchsysteme kann dieser Ansatz durchaus Vorteile bringen, indem verschiedene Peer
Groups spezielle Aufgaben erfüllen; z.B. sammeln von Daten, indizieren der Daten,
erstellen von statistischen Auswertungen, durchführen von Übersetzungsaufgaben. Des
Weiteren bietet der P2P Ansatz Lösungen zum automatisierten Auffinden von Diensten.
Der objektorientierte Ansatz und die Verwendung von Komponenten Architektur bringen
viele Vorteile mit sich. Softwaremodule können einfach und effizient erstellt werden. Die
Widerverwendbarkeit von Komponenten bzw. Modulen verringert die Entwicklungszeit.
Einfachheit und Widerverwendbarkeit bewirken auch eine kostengünstigere Entwicklung.
Die Unterstützung von Standards bringt neben einer breiteren Akzeptanz auch den
Vorteil der steten Weiterentwicklung, wenn auf offene und erweiterbare Protokolle bzw.
Dienste gesetzt wird.
Die untersuchten Lösungen DCE, COM und DCOM gelten als Vorläufer moderner
Middleware Technologien. Diese verwenden eigene Transport und Kommunikationsmechanismen. Die Weiterentwicklung von COM und DCOM mündet in der .NET
Plattform. Die Microsoft-Entwicklung setzt dabei auf offene XML Protokolle (SOAP)
und unterstützt die Registry über Webservices UDDI in Verbindung mit WSDL. Die
J2EE Architektur ist mittlerweile weit verbreitet, da sie einerseits plattformunabhängig ist
und sehr viele Standards unterstützt.
Seite 71
Ebenso setzt J2EE auf SOAP zur Datenübertragung und WSDL bzw. UDDI als
Anbieter für Webservices. Zusätzlich wird noch das B2B Verteilungsframework ebXML
unterstützt. Als Repräsentationsschicht bzw. zur Anbindung an verschiedenste Geräte
wird auch XHTML und WML unterstützt. ONE SUN’s Gegenstück zu .NET von
Microsoft setzt zur Gänze auf XML basierende Standards. Dazu gehören XML
Transportmechanismen wie XML-RPC, SOAP oder ebXML um nur eine kleine Auswahl
zu nennen. Zur Authentifizierung kann LDAP verwendet werden. Ebenso wird wiederum
auf die UDDI / WSDL Webservice Registry gesetzt um Dienste anbieten bzw.
konsumieren zu können.
Aus den Analysen moderner Middlewaretechnologien geht klar hervor, dass der Weg
in der Datenübertragung und in der Kommunikation über XML basierende Technologien
abgewickelt wird. Diese sind erweiterbar, großteils standardisiert und verfügen über eine
breite Akzeptanz. Entsprechend wird im nächsten Kapitel eine Auswahl standardisierter,
XML basierter Protokolle näher untersucht.
Zusätzlich sollen, neben dem Aspekt der Standardisierung auch die Unterstützung von
Sicherheitsaspekten sowie die Art des Datentransfers bzw. welcher Art die zu
übertragenen Daten sein können, untersucht werden. Als Überleitung zum Kapitel 5 steht
jedoch weiterhin das Schlagwort „Standardisierung“. Zu Beginn des folgenden Kapitels
wird der Begriff Standardisierung erläutert. Danach wird eine Reihe von
Übertragungsprotokollen untersucht, die unter dem Gesichtpunkt einer möglichen
Verwendbarkeit als Transportmedium in verteilen Suchsystemen eingesetzt werden
können.
Seite 72
Seite 73
Kapitel 5
5.
Transport Protokolle
Die Ansätze von verteilten Anwendungen und die vorgestellten Technologien des
Abschnittes Middleware aus dem vorigen Kapitel legen oft eigene Transportprotokolle
fest. Eine unglaubliche Vielfalt an Entwicklungen führt auch immer wieder zu
Inkompatibilitäten bei der Kommunikation oder der Anbindung von Fremdsystemen.
Gerade deshalb ist es wichtig, sich auf bestehende Standards zu stützen, um einerseits
eine breite Akzeptanz zu erhalten und um andererseits die Gewährleistung der steten
Weiterentwicklung von Transport- und Kommunikationsschicht zu bekommen. Ziel
dieses Kapitels ist, durch die Analyse verschiedener Kommunikationsprotokolle eine
Auswahl an geeigneten Übertragungs-protokollen für verteilte Suchesysteme finden zu
können.
Werden Standardprotokolle unterstützt, so können auch Fremdsysteme leicht integriert
bzw. angebunden werden. Probleme stellen jedoch immer wieder Erweiterungen
verschiedener Protokolle dar und die Tatsache, dass es aus kommerzieller Sicht besser ist,
die Kommunikationsschicht zu verschleiern. Diese Problematik lässt sich nicht nur
anhand bestehender Systeme im Bereich Instant Messaging aufzeigen, sondern auch
anhand vieler anderer Produkte, die bewusst nicht auf Standards setzen [Anmerkung des
Autors].
In den nun folgenden Abschnitten wird näher auf standardisierte und quasi
standardisierte Transportprotokolle eingegangen. John Larmouth definiert62 in seinem
Buch ASN.1 Complete, Computer Protokolle als „wohl definierte Menge an Nachrichten
mit
definiertem
semantischen
Inhalt
bzw.
Regeln
zur
strukturierten
Nachrichtenübertragung“. Bevor die Funktionsweise der verschiedenen Protokolle
erklärt wird, bildet eine Analyse des Standardisierungs-prozesses den Einstieg in das
Kapitel.
5.1.
Standardisierung
Standardisierungsvorschläge werden durch Organisationen, wie der International
Organisation for Standardization (ISO63) oder durch einige seiner nationalen
Mitgliedskörper wie z.B. der ANSI64 geprüft, genehmigt und gelten dann als anerkannte
allgemein gültige Standards. Industriestandards hingegen werden von diversen Firmen
festgelegt, die zwar durchaus weit verbreitet sein können, aber nicht allgemein anerkannt
62
John Larmouth, Definition des Begriffs Computer Protokoll: “A well-defined set of messages (bit-patterns or increasingly today - octet strings) each of which carries a defined meaning (semantics), together with the rules
governing when a particular message can be sent” [Larmouth 1999].
63
ISO; siehe http://www.iso.ch
64
ANSI (American National Standards Institute); siehe http://www.ansi.org
Seite 74
Kapitel 5 - Transport Protokolle
sind. Gerade im Bereich des Internets, wo es rasante Entwicklungen verschiedenster
Technologien gibt, wird das Wort Standard sehr häufig im Zusammenhang mit dem so
genannten Industriestandard verwendet. Einer der Gründe ist, dass der allgemein gültige
Normierungsprozess in einem sich schnell entwickelnden Bereich, wie z.B. der InternetProtokolle, viel zu langsam sein würde und deshalb den Entwicklungsfortschritt im
Internetbereich bremsen würde. Zwischen „allgemein gültigen Standards“ und
"Industriestandards" gibt es eine breite Palette von so genannte „quasi Standards". Nur
einige Internet-Standards besitzen den Status der allgemeinen Gültigkeit, der bedeutet,
dass sie überall im Internet angewendet werden. Andere Internet-Standards gelten als
quasi Standard und es wird empfohlen sich auch an diese aus Kompatibilitätsgründen zu
halten. Die allgemein gültigen Standards definieren meistens die grundlegenden
Protokolle, die für den Betrieb des Internets unentbehrlich sind. In eigens geschaffenen
Foren werden ausschließlich Technologien, die sich auf den Internet-Bereich beziehen,
geprüft und festgelegt. [Korpela 1999]
Das RFC65 - Forum fällt hierbei in diese Kategorie dieser Foren und wird dabei
zumeist in Zusammenhang mit Internet-Standard verwendet. Dies ist jedoch nur teilweise
korrekt, da RFS’s eine Reihe von Dokumenten beschreiben, die durch das IETF66 geprüft
und offiziell zur Verfügung gestellt werden. Diese Dokumente beschreiben
praxisbezogene Vorschläge, zumeist Protokoll-Spezifikationen. Protokolle sind für die
Interoperabilität der Systeme unumgänglich. Programme, die Daten versenden, müssen
auf bestimmte Vereinbarungen basieren, d.h. das Format der Daten und das Format der
Übertragung muss definiert sein. Nur ein kleiner Teil der RFC-Dokumente sind auch
allgemein als gültiger Standard anerkannt. Das RFC Archiv bietet zusätzlich zu den
allgemein gültigen Internet-Standards eine breite Vielfalt an Themen an. [RFC 2026]
Ein allgemein gültiger Internet-Standard besitzt zusätzlich zu einer RFC-Nummer eine
STD-Nummer67, die sich nicht ändert, selbst wenn sich die RFC-Nummer ändert. Z.B.
wird das IP-Protokoll von [STD 5] definiert. Im RFC liegt das IP-Protokoll zurzeit mit
der Nummer [RFC 791] auf. Eine RFC-Nummer ist zwar eindeutig, jedoch unterliegen
die Protokolle zumeist einem steten Entwicklungsprozess. Sobald ein Dokument zur
Veröffentlichung freigegeben wird, bekommt das Dokument eine entsprechende RFCNummer. Liegt das gleiche Dokument in einer verbesserten oder erweiterten Version vor,
wird es erneut geprüft, mit einer neuen RFC-Nummer versehen und veröffentlicht.
Deshalb muss man bei Recherchen immer die aktuellste RFC-Nummer eines Dokumentes
suchen, um für neue Entwicklungen auch die aktuellste Spezifikation verwenden zu
können [RFC 2026][RFC 3000]. Eine Beschreibung über den Aufbau des RFC-Systems
ist in [STD 1][ RFC 3000] ersichtlich. Weiters ist in diesem Dokument auch eine
Auflistung momentan gültiger Internet-Standard Protokolle enthalten, die die Protokolle
nach folgenden Kriterien sortiert angeben:
•
•
•
•
65
Standard Protokolle sortiert nach STD
Standard Protokolle sortiert nach RFC
Best Current Practice sortiert nach BCP68
Best Current Practice sortiert nach RFC
RFC (Request For Comment)
IETF (Internet Engineering Task Force); siehe http://www.ietf.org/
67
STD steht für Standard, STD ist ein Unterbereich der RFC Serie. Die STD Nummer kennzeichnet speziell für die
Internet Community die als mit „Standard“ bezeichneten RFC-Dokumente aus. [STD 1] [RFC 1311]
68
BCP steht für Best Current Practice, BCP ist wiederum ein Unterbereich der RFC Serie [RFC 1818] [BCP 1]
66
Seite 75
Es gibt im RFC zusätzlich zum STD und BCP auch noch eine weitere ausgezeichnete
Untergruppe namens FYI (For Your Information). Diese kennzeichnen jedoch nur
bestimmte RFC Dokumente im Bereich der RFC Serie. Die FYI Reihe wurde als
Informationszentrale für Dokumente aller Art, die sich auf das Internet beziehen,
festgelegt. Themen des FYIs reichen von historischen Memos bis hin zu Antworten auf
allgemein gestellte Fragen zum Bereich Internet. Entsprechend ist das FYI Archiv auch
für ein breites Publikum bestimmt. Ein FYI Dokument kann von jedermann eingereicht
werden. Im Dokument [RFC 1150] wird näher auf diesen Unterbereich eingegangen. Im
[RFC 2500] (Internet Official Protocol Standards) sind die momentan gültigen Internet
Protokolle aufgegliedert in:
•
•
•
•
•
•
•
•
•
Standard Protocols
Network-Specific Standard Protocols
Draft Standard Protocols
Proposed Standard Protocols
Experimental Protocols
Current Applicability Statements
Non-Standard Protocols
Informational Protocol
Historic Protocols
RFC Dokumente entstehen durch Einreichen neuer Entwürfe in entsprechenden
Gremien. Diese Entwürfe gelten bis zur Annerkennung und Veröffentlichung als
inoffiziell. Die Entwürfe entstehen oft als Ergebnis umfangreicher Entwicklungsarbeit
vieler beteiligter Personen oder Organisationen und bedürfen der Prüfung von RFC
Mitgliedern.
Diese Drafts69 sollen jedoch nicht als Quelle oder Referenz für neue Entwicklungen
verwendet werden, obwohl es durchaus vorkommen kann, dass ein Draft nach kleinen
oder gar keinen Änderungen akzeptiert wird und Gültigkeit erlangt. Jedoch können diese
Drafts durchaus bei Forschungszwecken und Recherchen sehr nützlich sein, zumal sie
meist neuartige Technologien betreffen. Solche Drafts für den Internet Bereich kann man
über die Seite http://sunsite.cnlab-switch.ch/cgi-bin/search/standard/nph-findstd suchen
und abrufen. Die Ziele des Internet Standardisierungs-prozesses sind nach [Korpela
1999]:
•
•
•
•
•
Gewährung technisch hervorragender Leistung
überprüfen bestehender Implementierungen
erstellen freier, kurzer und leicht verständlicher Unterlagen
Offenheit und Gerechtigkeit bezüglich der Antragsteller
Gewährleistung einer schnellen Fertigstellung
Geeignete Verfahren bieten eine angemessene, offene und objektive Grundlage für das
Entwickeln, das Auswerten und das Festlegen von Internet-Standards. In jedem Stadium
des Standardisierungsprozesses wird eine Spezifikation wiederholt besprochen, in z.B.
öffentlichen Sitzungen und/oder in Mailing-Listen. So muss ein Draft mehrfach auf
korrekte Funktionsweise und Interoperabilität durch unabhängige Mitglieder geprüft
werden, bevor der Draft als Internet-Standard angenommen werden kann. In der Praxis
erreicht jedoch nur ein kleiner Teil von Spezifikationen das Niveau als Standard
zugelassen zu werden.
69
RFC-Drafts; siehe http://sunsite.cnlab-switch.ch/cgi-bin/search/standard/nph-findstd
Seite 76
Ein Grund dafür ist, dass der Entwicklungsprozess häufig Verbesserungen und
Änderungen unterworfen ist. Außerdem werden Standardisierungen auch von anderen
Organisationen durchgeführt. Zum Beispiel ist die HTML-Sprachversion 2.0 im [RFC
1866] definiert, aber die Weiterentwicklung der Sprache wird von der Organisation
W3C70 durchgeführt. Das Standardisierungssystem von RFC Dokumenten ist aber nicht
so rigoros wie man es eigentlich von so einer Organisation erwarten dürfte.
Z.B. definiert das [RFC 1036] Dokument aus dem Jahr 1987 Standardprotokolle zum
Austausch von Informationen in USENET Systemen, die für die Funktionalität von
USENET wesentlich sind. Dieses RFC ist aber kein vorgeschlagener Standard gemäß
dem [STD 1]. Die Organisation IANA71 verzeichnet das RFC sogar mit dem Status
„unbekannt“. Abschließend soll noch angeführt werden, welche Organisationen hinter der
RFC Reihe stehen [Korpela 1999]:
•
•
•
•
•
IAB IANA IETF IRTF ISOC -
5.2.
Internet Architecture Board:
Internet Assigned Numbers Authority:
Internet Engineering Task Force:
Internet Research Task Force:
Internet Society:
http://www.iab.org
http://www.iana.org
http://www.ietf.org
http://www.irtf.org
http://www.isoc.org
Allgemeines
Die in der Einleitung angeführte Definition von John Larmouth sieht Computer
Protokolle in erster Linie als Transportmittel, das durch eine vereinbarte Logik Inhalte
zeitlich gesteuert überträgt. Die Spezifikation der Syntax und der Semantik legt implizit
das Datenformat fest. Protokolle besitzen aber weitaus mehr Eigenschaften, als nur dem
Transport zu dienen. Eine grobe Unterscheidung kann zwischen Transport- und
Kommunikationsprotokollen vorgenommen werden. Während Erstere entworfen wurden
um Daten von Ort A zu Ort B zu transportieren, kümmern sich
Kommunikationsprotokolle vorwiegend um das Verbindungsmanagement. Weiters wird
unterschieden ob ein Protokoll verbindungsorientiert oder verbindungslos arbeitet. Daten
können nachrichtenbasierend synchron bzw. asynchron über unidirektionale oder
bidirektionale Verbindungen transferiert werden. In vielen Fällen stehen jedoch
Protokolle in direkter Verbindung zur darunter liegenden Trägerschicht. Entsprechend
sind oft auch die Eigenschaften der Protokolle vorgegeben. Neben Transport und
Kommunikation werden in Protokollen auch spezifische Funktionalitäten abgebildet.
Protokolle dienen als Vermittler (Routing), Informationsbereitsteller, Verteiler
(Broadcasten), oder handeln Sicherheitskriterien zur Übertragung aus bzw. bieten
Möglichkeiten zur Authentifizierung an. [Anmerkung des Autors]
Die nun folgende Analyse ausgewählter Protokolle versucht deren Eigenschaften und
Anwendungsmöglichkeiten herauszufinden. Von besonderem Interesse sind Aspekte wie
die Art und Weise der Datenübertragung, Standardisierungsbemühungen, Erweiterbarkeit
und Akzeptanz.
70
W3C (World Wide Web Consortium); W3C ist ein Forum für Information, Handel, Kommunikation und
Kollektivverständnis im Bereich Internet. Das W3C entwickelt interoperable Technologien (Spezifikationen, Richtlinien,
etc.) um das volle Potential des Internet ausschöpfen zu können; siehe http://www.w3.org/
71
IANA (Internet Assignment Number Authority); IANA ist eine zentrale Stelle zur Verwaltung und Koordination globaler
Internet spezifischer Funktionen und Eigenschaften; siehe http://www.iana.org/
Seite 77
5.3.
Z39.50
Das Z39.50 Protokoll wird vorwiegend im Bereich Information Retrieval in
bibliothekarischen Informationssystemen eingesetzt. Die aktuellste Version des Z39.50
Standards (Information Retrieval Z39.50-1995: Application Service Definition and
Protocol Specification) kann von der Library of Congress (loc72) unter der URL:
http://lcweb.loc.gov/z3950/agency/document.html abgerufen werden. Weiters werden an
dieser Stelle Verweise zum äquivalenten ISO Standard 23950:1998 und Z39.50-1995 von
NISO angegeben. Im ISO/OSI Schichtenmodell ist Z39.50 im „application layer“
(Schicht 7) angesiedelt. [Gottswinter 1996]
Zur Beschreibung des Protokollmodelles wird das abstrakte Konzept des ServiceUser, Service-Provider und Service-Primitive angewandt. Die Architektur basiert auf dem
Client-Server Modell. Dabei werden Teile des Clients als Z39.50 Origin und Teile des
Servers als Z39.50 Target bezeichnet. Der Origin ist eine Instanz des Client und generiert
Anfragen. Der Target stellt eine Instanz des Servers zur Verfügung, der Anfragen
akzeptiert. Der Service-User ist Teil des Clients bzw. des Servers und erzeugt Requests
für den Origin und den Target. Der Kommunikationspfad zwischen Client und Server
wird als Service-Primitive bezeichnet. Das abstrakte Protokollmodell ist in Abbildung 5.1
ersichtlich.
Abbildung 5.1: Darstellung des abstrakten Protokollmodells [Gottswinter 1996]
Eine Service-Primitive stellt eine Interaktion zwischen Service-User und ServiceProvider dar. Es gibt vier Primitiv-Typen: Request, Indication, Response und
Confirmation. Der Datenaustausch kann in sechs Schritten zusammengefasst werden
[Gottswinter 1996]:
1.
2.
3.
4.
5.
6.
Request Primitive von Origin Service-User an Service-Provider
Protokollnachricht von Origin an Target
Indication Primitive von Service-Provider an Target Service-User
Response Primitive von Target Service-User an Service-Provider
Protokollnachricht von Target an Origin
Confirmation Primitive von Service-Provider an Origin Service-User
Das Protokoll ist zustandsbehaftet und nachrichtenbasierend. Es setzt auch eine
permanente Verbindung zwischen Client und Server voraus, wobei die meisten
Implementierungen mittels TCP/IP kommunizieren. Ein Z39.50 Server bietet über drei
Hauptaufgaben seine Dienste dem Client zur Verfügung [Gottswinter 1996]:
• Die Protokollfunktionen verwalten, bearbeiten und behandeln eingehende Requests
und senden Ergebnisse bzw. Antworten als Nachricht an den Client. Dabei werden die
eingehenden Anfragen in Datenbank spezifische Anforderungen umgesetzt.
72
loc (Library of Congress); siehe http://lcweb.loc.gov/
Seite 78
• Kontrollfunktionen des Servers beinhalten neben der Zugriffskontrolle und
Entscheidungshilfen (Verteilungsfunktionen) auch Cache-Mechanismen, um die
Performance des Systems steigern zu können.
• Die Datenbankfunktionen stellen die Kernfunktionalität des Servers dar und führen
neben der Auswertung der Suchanfrage auch die Formatierung (zusammenstellen der
Nachricht) der Suchergebnisse durch.
In der nun folgenden Auflistung werden die in Z39.50-1995 (Version 3) spezifizierten
Dienste kurz beschrieben [Gottswinter 1996]:
• Initialize Service – Initialisierungsrequest: Im Initialisierungsvorgang werden Werte
wie die Protokollversion, die bevorzugte Größe der zu übertragenen Nachrichten, oder
die zu unterstützenden Dienste zwischen Client und Server ausgehandelt.
• Search Service (Suchrequest): Das Suchservice bietet dem Client neben der
Möglichkeit in einer einfachen Suchanfrage mittels eines Suchkriteriums auch eine
Auswahl an möglichen Suchsystemen an. Weiters werden z.B. auch die ÜbertragungsFormate in der Suchanfrage festgelegt. Der Server sendet dem Client als Suchantwort
jedoch nicht die Datenrecords, sondern lediglich die Anzahl der gefundenen
Datensätze. Der Server cached das Suchergebnis, das vom Client aus über einen
bestimmten Namen ansprechbar ist.
• Present Service (Übertragungsrequest): Mit diesem Dienst wird der gezielte Zugriff
auf die Datenrecords am Server ermöglicht. Dabei kann der Client festlegen, welche
Informationen er aus einem Record beziehen möchte oder ob der gesamte Record
übertragen werden soll. Die eigentliche Übertragung der Suchrecords erfolgt in
mehreren Schritten, wiederum nachrichtenbasierend.
• DeleteResultSet Service (Löschrequest): Über diesen Dienst kann der Client
Suchergebnisse am Targetsystem löschen.
• Access Control Service (Authentifizierungsrequest): Das Targetsystem kann über
diesen Dienst den Origin auffordern sich explizit auszuweisen. Dies wird über
Authentisierungskontrolle, Passwortkontrolle und weiteren Mechanismen realisiert.
• Resource Control Service (Statusrequest): Der Server kann über diesen Dienst
Statusmeldungen (Ressourcegrenzen, Unterbrechung einer Aktion) dem Client
mitteilen.
• Trigger Resource Control Service (Triggerrequest): Über diesen Dienst kann der
Client vom Targetsystem einen Statusrequest anfordern (innerhalb einer aktiven
Operation).
• Resource Report Service (Reportrequest): Dieser Dienst ermöglicht es dem Client
Ressource Reports zu bestimmten Aktionen des Targetsystem anfordern zu können.
• Sort Service (Sortrequest): Der Client fordert über diesen Dienst das Tartgetsystem
auf mehrere Suchergebnisse zu mischen bzw. die Suchergebnisse anhand geforderter
Kriterien zu sortieren.
• Scan Service (Iterationsrequest): Dieser Dienst erlaubt es dem Client gezielt
(Startpunkt und Schrittweite) Suchrecords vom Targetsystem anzufordern.
• Extended Search Service (erweiteter Suchrequest): Über diesen Dienst können Task
Packages erzeugt, geändert, gelöscht oder in Aktionen eingebunden werden. Diese
Task Packages definieren eine Reihe von Anweisungen, die bei Bearbeitung der
Aktionen ausgeführt werden.
Seite 79
• Termination Service (Closerequest): Sowohl das Origin-, als auch das Targetsystem
verwendet diesen Dienst zum Beenden aller aktiven Operationen. In weiterer Folge
wird mit diesem Request die Verbindung vom Client zum Server abgebrochen.
5.4.
XML-Grundlagen
XML bedeutet Extensible Markup Language. Diese erweiterbare Sprache wurde nicht
neu definiert, sondern stellt eine Untermenge der SGML Sprache dar, die schon seit 1986
standardisiert ist. Durch die große Akzeptanz von XML wurden viele neue
Anwendungsmöglichkeiten geschaffen. Der wichtigste Aspekt von XML ist die
Vereinheitlichung von Datentransport und Datenspeicherung. Ein weiterer Vorteil von
XML ist die Fähigkeit sowohl von Maschinen als auch von Menschen einfach
verarbeitbar zu sein. XML bildet Daten syntaktisch und logisch in einfachen Strukturen
ab. Einfach erklärt enthält XML Entitäten die auf andere Entitäten verweisen können.
Dabei spielt es keine Rolle ob eine zu referenzierende Entität im Dokument selbst liegt
oder entfernt über das Web zugreifbar ist. Die Syntax von XML gibt bereits die logische
Struktur eines XML Dokumentes vor. Die XML-Syntax beschreibt die Elemente,
Deklarationen, Kommentare und Verarbeitungsweisen der Sprache. Der breiten
Akzeptanz von XML ist es zu verdanken, dass man XML Dokumente bereits sehr einfach
mit speziellen Werkzeugen erstellen kann. [Scribner et al. 2001]
Um die Syntax von XML wiederum einfach validieren zu können, gibt es
verschiedenste Ansätze. Validieren bedeutet den XML-Code einerseits auf korrekte
Syntax zu überprüfen, und andererseits auch logische Strukturen gegenüber Vorgaben zu
testen. Die Syntax von XML Dokumenten kann mit speziellen XML-Parsern überprüft
werden. Logische Strukturvorgaben werden z.B. mit Hilfe von DTD’s oder XMLSchemata überprüft. Die nun folgenden Unterpunkte geben einen kurzen Überblick über
die wichtigsten XML-Grundlagen. Der nachfolgende Überblick orientiert sich zum
Großteil an der Arbeit von [Scribner et al. 2001]. Spezifische Verweise zu
Spezifikationen sind an den jeweiligen Stellen vermerkt.
5.4.1.
DOM
Das Document Object Model (DOM) gehört in die Kategorie der XML-Parser. Beim
DOM Ansatz wird eine XML Datei beim Parsen zur Gänze als Objektbaum in den
Speicher geladen. Eine Validierung der XML-Struktur ist deshalb auch nur zu Beginn
beim Laden der XML Datei möglich. Entsprechend ist auch die gesamte XML Datei zur
Gänze in der Applikation verfügbar. Eine explizite Fehlererkennung und Steuerung ist
nach dem Laden der XML Datei nicht mehr möglich. Entsprechend wird DOM bei
effizienten Verarbeitungsroutinen kaum eingesetzt. Der Vorteil im DOM Ansatz liegt
darin, dass er sehr einfach aufgebaut ist und bereits für Webanwendungen von neueren
Browserversionen (ab IE5.0, ab Mozilla 1.5) Clientseitig unterstützt wird. Eine geparste
und validierte XML Datei wird in DOM als Baumstruktur abgelegt. Jeder XML-Tag wird
als eigener Knoten im DOM-Baum (Node) abgebildet. Als Node-Eigenschaften
(Knotenelemente) werden z.B. Attribute als Liste abgelegt. Zusätzlich ist auch eine
Referenz zu den Kinderknoten gespeichert. Über eine spezielle API ist die Navigation in
diesem DOM Baum möglich. Mit speziellen Methoden kann man weiters auf Textinhalte
und Kommentare zugreifen. Je nach Implementierung des DOM-Ansatzes wird auch die
Manipulation der Knoten, bzw. Unterobjekte erlaubt. 73
73
Document Object Model (DOM) Level 1 Specification: http://www.w3.org/TR/REC-DOM-Level-1
Seite 80
5.4.2.
SAX
Das Simple API for XML, kurz SAX, gehört ebenfalls in die Kategorie der XMLParser. Im Gegensatz zum DOM Ansatz ist SAX ein ereignisgesteuerter Parser. Z.B. wird
bei jedem öffnendem und schließendem Tag ein Ereignis (Treiber) ausgelöst und
verarbeitet (durch einen Handler). Der Treiber ist der eigentliche Parser, der Handler legt
die Programmlogik fest. So kann für die gesamte XML Datei eine eigene Datenstruktur
implementiert werden. Man ist nicht an bestimmte Vorgaben gebunden. Aus diesem
Grund können Performancevorteile erzielt werden, da weniger Ressourcen in Gebrauch
sind. Da für die XML Daten-Repräsentation, wie bereits erwähnt, der jeweilige
Programmierer verantwortlich ist, stehen auch keine allgemein gültigen
Modifikationsfunktionen zur Verfügung. Dafür können diverse Parserroutinen
zielorientiert erstellt werden und erlauben so eine effiziente Abarbeitung des
Datenstromes. Will man hingegen Routinen entwerfen, die leicht erweiterbar sein sollen,
oder unabhängig von der XML-Notation, muss man gegnerische Verfahren einsetzen die
jedoch wiederum zu Lasten der Performance gehen. Zur Datenübertragung ist ein SAX
Parser wesentlich besser geeignet als etwa der DOM Parser, da bereits beim Parsen
entsprechend dem Ereignis verschiedene Callbackfunktionen aufgerufen werden können.
Eine Validierung der XML Daten erfolgt entsprechend zur Laufzeit beim Parsen. Ebenso
wie die Tag-Analyse kann so ein eigenes Error-Handling umgesetzt werden.
5.4.3.
DTD
DTD (Dokument Type Definition) beschreibt eine Grammatik mit der XML
Dokumente validiert werden können. Ein XML Dokument ist wohlgeformt wenn die
korrekte Syntax des Dokumentes durch einen Parser bestätigt wird und wird als gültig
angesehen, wenn das XML Dokument einer DTD-Spezifikation genügt. Die DTD
Grammatik ist an und für sich recht einfach aufgebaut und legt fest, welche Elemente und
Attribute in einem XML-Dokument verwendet werden dürfen. Elemente werden
definiert, indem alle Unterelemente deklariert werden (Inhaltsmodell). Im Inhaltsmodell
wird festgelegt, in welcher Reihenfolge die Elemente auftreten müssen, und die Anzahl
an erlaubten Wiederholungen. Weiters werden alle gültigen Attributdefinitionen eines
Elementes deklariert. Die Definition der Attribute erfolgt jedoch untypisiert. Weitere
Informationen zur Syntax und deren Anwendung kann in der Spezifikation vom W3C
nachgelesen werden.
5.4.4.
XML-Schema
XML-Schemata werden ebenfalls zur Validierung von XML-Daten eingesetzt.
Ähnlich wie bei DTD beschreibt ein XML Schema eine abstrakte Grammatik, die jedoch
mächtiger als die der DTD-Definition ist. Durch eine typisierte Attribut Definition und
der Möglichkeit von Ableitung können komplexe Attribut-Definition erstellt werden.
Neben der Typisierung ist weiters auch ein definiertes Eingabeformat über reguläre
Ausdrücke und ein deterministisches Inhaltsmodell über so genannte „Delimitors“
(minOccurs, maxOccurs) spezifizierbar. Die Spezifikation des XML Schema besteht aus
drei Teilen. Dem Primer, der Definition von Strukturen und der Deklaration von
Datentypen. Das Dokument „XML Schema Part 0: Primer“ beschreibt die formale Syntax
des XML Schemata anhand von kurzen Beispielen.
Das Dokument „XML Schema Part 1: Structures“ beschreibt die formale Syntax eines
XML Dokumentes und den strukturellen Aufbau eines XML Schema. Im Dokument
„XML Schema Part 2: Datatypes“ sind alle verwendbaren Datentypen festgelegt. Es muss
an dieser Stelle darauf hingewiesen werden, dass die Definition des XML Schema im
Seite 81
W3C noch nicht abgeschlossen ist, und deshalb nur bedingt einsetzbar ist. Jedoch
unterstützen bereits jetzt schon die neuesten XML-Parser und Browserversionen die
Validierung gegen XML-Schema. 74
5.4.5.
XSLT - Stylesheets
Mit XSL (Extensible Style Language) können XML-Dokumente z.B. in HTMLNotation umgewandelt werden. Eine XSLT (XSL-Transformation) kann aber nicht nur
XML in HTML umwandeln, sondern eine Transformation in verschiedene XMLspezifische Notationen durchführen. Mit dem Einsatz von XSLT können z.B.
verschiedene Protokoll Versionen miteinander verbunden werden. Dabei wird XSLT als
Art Sprachübersetzer oder Sprachumformer eingesetzt. Die Verknüpfung von z.B. SOAP
mit XML-RPC benötigt lediglich die Erstellung geeigneter XSLT-Dokumente. Wird
XSLT entsprechend zur Validierung von XML Dokumenten eingesetzt, kann im XSLT
Dokument die Validierungslogik umgesetzt werden um in einem DTD Dokument die
Gültigkeit der Element und Attribute überprüft werden. Die genaue Definition von XSLT
ist am W3C erhältlich. 75
5.4.6.
XML Verknüpfungstechnologien: XLink / XPointer / XPath
In XML ist es bisher nicht möglich, Elemente innerhalb eines Dokumentes zu
referenzieren oder aus XML andere Dokumente zu verknüpfen. Mit Hilfe von XLink
lassen sich Elemente und Dokumente multidirektional verbinden. Mit Hilfe einer
speziellen XML-Syntax werden Linkstrukturen erzeugt. Die Angabe des Linktyps
(simple, extended) unterscheidet den Aufrufmechanismus. Weiters wird zwischen
„Inline-Links“ und „Out-of-line-Links“ unterschieden. Inline-Links verweisen direkt auf
eine Ressource. Out-of-line-Links können auf Inhalte verweisen, die Ihrerseits die
Referenz zu einer externen Ressource herstellt. XPointer werden verwendet um
bestimmte Elemente eines XML-Dokumentes ohne Beschränkungen adressieren zu
können. Aus Dokumentensicht gesehen stellen XPointer Möglichkeiten zu internen
Verknüpfungen von Elementen zur Verfügung. Folgende Ressource-Typen können mit
XPointer miteinander verknüpft werden: text/xml, application/xml, text/xml-externalparsed-entity, application/xml-external-parsed-entity. Auch XPath ermöglicht eine
Adressierung von XML-Elementen innerhalb eines Dokumentes oder Teilen eines
Dokumentes. XPath wird implizit von XPointer und XSL Transformationen genutzt. Die
Notation von XPath ist ähnlich regulärer Ausdrücke und erlaubt einen direkten,
typenabhängigen Zugriff auf XML- Elemente. 76
5.4.7.
XHTML
XHTML ist eine XML konforme Spezifikation für den Standard HTML 4.0. XHTML
liegt derzeit in der Version 1.0 vor und wird vom W3C weiterentwickelt. XHTML ist
syntaktisch völlig kompatibel zu anderen standardisierten XML-Sprachen wie z.B.
74
XML Schema Part 0: Primer: http://www.w3.org/TR/xmlschema-0/; XML Schema Part 1: Structures:
http://www.w3.org/TR/xmlschema-1/; XML Schema Part 2: Datatypes: http://www.w3.org/TR/xmlschema-2/
75
XSL Transformations (XSLT): http://www.w3.org/TR/xslt
76
XML Linking Language (XLink): http://www.w3.org/TR/xlink/; XML Pointer Language (XPointer):
http://www.w3.org/TR/xptr/; XML Path Language (XPath): http://www.w3.org/TR/xpath
Seite 82
SVG77, MathML78, SMIL79, RDF80 oder WML81. Dadurch kann XHTML als „Dateninsel“
bezeichnet werden und einfach in anderen Sprachen eingebunden werden. Ebenso einfach
ist es in XHTML andere XML-basierte Sprach-Dateninseln zu integrieren. Ein weiterer
Vorteil von XHTML liegt in der Vereinheitlichung von Script Sprachen. Mit dem DOMModell wird ein einheitlicher Zugriff auf XML-basierte Datenbestände ermöglicht. Der
größte Vorteil von XHTML liegt jedoch in der Erweiterbarkeit der Sprache. So sind
einerseits alle Elemente von HTML 4.0 im Sprachumfang von XHTML enthalten,
andererseits ist es aufgrund der XML Basis der Sprache relativ einfach möglich neue
Elemente oder Sprachkonstrukte zu definieren. [XHTML 2002]
XHTML wird bereits von gängigen Browserversionen unterstützt. Z.B. ab MS IE5.x /
Netscape 6.x wird XHTML auch entsprechend wie HTML 4.0 gerendered. Während die
MS-Browser Versionen das Rendering von XHTML nur in Kombination mit Stylesheets
unterstützen (ansonsten wird der XML Strukturbaum angezeigt), interpretieren die
Netscape-Browser automatisch XHTML-Dateien. Für XHTML wurden auch neue MimeTypes (text/xml oder application/xml) und File-Extensions (.xhtml) eingefügt. Wird
ein Dokument mit der Endung .htm oder .html in einen Browser geladen, dann
versuchen die Browser die Datei mit einem HTML Parser zu rendern. Wird jedoch eine
Datei mit der Endung .xhtml in den Browser geladen, wird der XML-Parser versuchen
das Dokument zu verarbeiten. Die Konsequenz daraus ist, dass ein XHTML Dokument
syntaktisch korrekt sein muss, um auch korrekt angezeigt werden zu können. Die XMLParser zeigen bei Syntaxfehlern lediglich Fehlermeldungen an. Im Gegensatz dazu
versuchen HTML-Parser auch eine syntaktisch nicht korrekte Datei zu rendern. [XHTML
2002]
5.5.
BEEP
BEEP steht für Blocks Extensible Exchange Protocol und beschreibt ein generisches
Protokoll-Framework,
mit
dem
ein
asynchroner,
verbindungsorientierter
Nachrichtenaustausch umgesetzt werden kann. Kernfunktionalitäten von BEEP sind die
einfache Handhabung des Verbindungsmechanismus, der Authentifizierung, eine
einfache Nachrichtenübertragung, eine einfache Fehlerbehandlung und die
Widerverwendbarkeit. Elemente wie Authentifikation, Verschlüsselung oder
Datenkompression werden in einzelne Module verpackt und im Framework zur
Verfügung gestellt. In vielen anderen Übertragungsprotokollen, in denen z.B. TCP/IP als
Trägerschicht eingesetzt wird, müssen sämtliche erwähnten Funktionalitäten stets neu
implementiert werden. Einen guten Vergleich im Designunterschied von BEEP zu
Protokollen wie z.B. HTTP zeigt Abbildung 5.2. [RFC 3080]
77
SVG: Scalable Vector Graphics, Beschreibung 2-dimensionaler Vectorgrafiken; http://www.w3.org/Graphics/SVG
MathML: Mathematical Markup Language, Beschreibung technisch-wissenschaftlicher Inhalte anhand einer
mathematischen Formelsprache; http://www.w3.org/Math
79
SMIL: Synchronized Multimedia Integration Language, Beschreibung von selbst ablaufenden Präsentationen für
verschiedenste Medienelemente wie Text, Bilder, Video und Audio; http://www.w3.org/AudioVideo
80
RDF: Resource Description Framework, Beschreibung von Metadaten zu Dokumenten; http://www.w3.org/RDF
81
WML: Wireless Markup Language, Beschreibungssprache für Displayinhalte von mobilen Geräten, ähnlich wie HTTP
bei Browsern; http://www.wapforum.org
78
Seite 83
Abbildung 5.2: Designvergleich des BEEP Protokolls zu herkömmlichen Protokollen [RR 2002]
BEEP wurde von Marshall Rose im [RFC 3080] spezifiziert und im [RFC 3081] auf
TCP/IP als Trägerschicht abgebildet. Dabei wurden folgende Ziele verfolgt:
Verbindungsorientierung, Nachrichtenorientierung und Asynchronität. Durch die
Asynchronität des Frameworks gibt es keine ausgezeichneten Client oder Server. Ähnlich
zu P2P Protokollen gibt es bei BEEP einen Initiator, der eine Anfrage stellt, und einen
Listener, der die Anfrage beantwortet. Dabei wird die Kommunikation zwischen den
beiden Partnern nicht auf einfache Request-Response Statements beschränkt, sondern
eine asynchrone bilaterale Kommunikation zwischen zwei gleichberechtigten
Endpunkten erlaubt. Dabei wird für jede Kommunikation eine Verbindung aufgebaut,
über diese dann die Nachrichtenübermittlung kodiert erfolgt. Eine Trennung der
Nachrichten erfolgt aufgrund der Verwendung strukturierter Frames. Bei der
Nachrichtenübertragung wird neben der Fehlerbehandlung auch das Multiplexen der
Datenkanäle unterstützt. [RFC 3080] [RFC 3081]
In BEEP sind drei Übertragungsarten spezifiziert: message/replay, message/error
und message/answer. Die beiden ersten Übertragungsarten sind One-to-One
Austauschformate. Antworten werden vom Server jeweils mit einer Replay-Message oder
einer Error-Message beantwortet. Beim dritten Austauschformat One-to-Many wird
entweder Null oder eine bzw. mehrere Antworten zurückgeschickt. Dieses Format ist
z.B. für Suchanfragen oder Streaming von Daten verwendbar. Die Nachrichtentypen
werden mit dem MIME Format spezifiziert. Eine Nachricht wird in ein Frame gepackt,
das nicht notwendigerweise in weitere Frames unterteilt werden muss. Ein Frame besteht
aus dem Frame-Header, der Nutzlast und einem Trailer. Im Header werden verschiedene
Übertragungsparameter festgelegt. Dies sind der Mime-Type, der Kommunikationskanal
(nicht-negative Zahl im Intervall von [0…231-1]), eine Nachrichten Nummer (wichtig für
Replay), ein Fortsetzungsindikator (letztes Frame oder es folgen noch Frames), eine
Sequenznummer für die Identifizierung der Nutzlast (erstes Datenpaket in der Nutzlast)
und einer Größenangabe für die Anzahl an Datenpaketen im Frame. Die Nutzlast besteht
aus einem oder mehreren Datenpaketen, die in Oktetts zusammengefasst werden. Jedes
Oktett ist einer Sequenznummer zugeordnet, wobei das erste Oktett mit der kleinsten
Zahl kodiert ist und im Header des Frames speziell markiert wird. Der Trailer bildet wie
bereits erwähnt den Abschluss eines Frames und wird speziell mit END <CR> <LF>
kodiert. In Listing 5.1 ist ein einfaches Beispiel für eine Anfrage eines Client an einen
Server dargestellt. Dabei wird im Header der Kanal 0 und der Messagenumber 1
festgelegt. Die Nachricht besteht lediglich aus einem Frame. Das erste Datenpaket besitzt
die Sequenznummer 52 und die Nutzlast besteht aus 120 Datenpaketen (Oktetts) [RFC
3080]
Seite 84
MSG 0 1 . 52 120
Content-Type: application/beep+xml
<start number=’1’>
<profile uri=’http://iana.org/beep/SASL/OTP’ />
</start>
END
Listing 5.1: Beispiel einer BEEP Anfrage an einen Server [RFC 3080]
Um eine BEEP Session zu starten, muss ein Verbindungsaufbau über den Kanal 0
erfolgen. Der Kanal 0 ist zuständig für die Sitzungsverwaltung. Über diesen Kanal
werden neben dem Starten und Schließen einer Verbindung auch verschiedene Profile
ausgehandelt. Die Nachrichtenübertragung erfolgt im Klartext. Entsprechend müssen
auch für Authentifizierung und Sicherheit spezielle Profile ausgehandelt werden. Ein
Profil legt fest (Syntax und Semantik), welche Nachrichten über einen Kanal übertragen
werden dürfen. Die Angabe eines Profils wird mit einem URI definiert. BEEP unterstützt
z.B. das TLS82 und SASL83 Protokoll. Ist beim Verbindungsaufbau Transportsicherheit
oder Authentifizierung gefordert, werden alle bisher zum Prozess gehörenden Kanäle
geschlossen und der Verbindungsaufbau erneut unter Verwendung von TLS oder SASL
Protokollen durchgeführt. Weiters kann mit einem speziellen Profil, dem BEEPTUNNEL84, die Weiterleitung von Daten über eine Kette von Proxies erfolgen. Mit
diesem Profil ist unter der Verwendung von TLS oder SASL Profilen (um
Sicherheitsaspekte gewährleisten zu können) das Überbrücken von Firewalls möglich.
[RFC 3080]
Wie man bereits am Beispiel in Listing 5.1 erkennen kann, erfolgt die Notation einer
Message im XML-Format. Es gibt entsprechend auch eine DTD um die XML-Notation
validieren zu können. Es ist z.B. das Kanalmanagement mit einer speziellen DTD85
spezifiziert. Ebenso gibt es für das TLS-Profil eine DTD Spezifikation86, sowie eine DTD
für das SASL-Protokoll87. Aufgrund der XML Notation der Message und der Profile liegt
es auch nahe, BEEP als Trägerschicht für verschiedene XML-Protokolle zu verwenden.
So gibt es bereits Spezifikationen zur Verwendung von XML-RPC in BEEP [RFC 3529]
oder einer Spezifikation zur SOAP Anbindung zu BEEP [RFC 3288]. [RFC 3080]
5.6.
XML-RPC
XML-RPC ist ein einfaches, leichtgewichtiges Protokoll, das RPC-Requests und RPCResponses in ein XML-Dokument serialisiert. Als Transportschicht kann z.B. HTTP
verwendet werden, siehe Abbildung 5.3. Eine XML-RPC Message wird als HTTP-Post
Request vom Client zum XML-RPC Server geschickt. Für den Post Request muss ein
gültiger HTTP-Header angegeben werden, der User-Agent und Host, bzw. als Content
Type text/xml und eine gültige Content Länge beinhaltet. Der Serialisierungsvorgang
der RPC-Anfrage (HTTP -Body, XML) ist dabei relativ einfach. Für jeden
Aufrufparameter einer Methode gibt es ein entsprechendes XML-Element in dem der
82
TLS: Transport Layer Security; Dieses Protokoll ist im [RFC 2246] beschrieben und verschlüsselt Nachrichten mit z.B.
symmetrischen Verschlüsselungsverfahren wie DES (Data Encryption Standard) oder durch Secure Hash Funktionen
wie SHA (Secure Hash Algorithm) oder MD5 (Message Digest Version 5).
83
SASL: Simple Authentication and Security Layer; Dieses Protokoll ist im [RFC 2222] beschrieben und legt Methoden
zur sicheren Authentifizierung für verbindungsorientierte Protokolle fest. SASL basiert auf Kerberos Version 4.
84
BEEP-TUNNEL : http://iana.org/beep/tunnel
85
http://xml.resource.org/profiles/BEEP/beep.dtd
86
http://xml.resource.org/profiles/TLS/tls.dtd
87
http://xml.resource.org/profiles/sasl/sasl.dtd
Seite 85
Parametertyp und dessen Wert abgebildet werden. Als Parameter können z.B. Skalare,
numerische Werte, Strings, Datumsformate, List Strukturen oder andere komplexe
Datenstrukturen übergeben werden. Spezielle Tags (Elemente) kennzeichnen einen
Methodenaufruf. Als einleitender Tag kapselt <methodCall> den gesamten
Methodenaufruf. Der Methodenname wird innerhalb des Tags <methodName> angegeben.
Als kleines Beispiel veranschaulicht die XML-Notation eines XML-RPC Calls in Listing
5.2 die Einfachheit der Serialisierung. Die Spezifikation88 von XML-RPC ist nur wenige
Seiten lang und auf der Homepage von Userland erhältlich. [Userland]
Abbildung 5.3: XML-RPC Datenfluss [Userland]
<xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>41</i4></value>
</param>
</params>
</methodCall>
Listing 5.2: Beispiel eines serialisierten XML-RPC Aufrufes [Userland]
5.7.
ebXML
ebXML wird als Electronic Business XML bezeichnet. Protokolle von ebXML
werden vorwiegend in der Industrie als Nachrichtenübermittler eingesetzt. XML dient
hier wiederum als Trägermedium um verschiedene Geschäftssysteme miteinander
verbinden zu können. Ziel von ebXML ist es, Dienste verschiedener Systeme nutzen zu
können. Als Daten werden vorwiegend Nachrichten in definierter Form übertragen.
Eigenschaften von ebXML sind eine zuverlässige Nachrichtenübertragung und
Fehlerbehandlung, sowie Nachrichten-Routing, Unterstützung von Sicherheitsaspekten,
bestimmen von Quality of Services und Plattform-unabhängigkeit. Die ebXML
Architektur sieht eine zentrale Registry vor, bei der notwendige Informationen über die
Geschäftspartner gespeichert sind. Diese Informationen sind über spezielle Dokumente
(Collaboration Protocol Profiles) abrufbar. Dienste und Geschäftsprozesse von
Unternehmen werden über spezielle Strukturen abgebildet. In diesen Strukturen sind
technische Informationen über Nachrichten- und Transportprotokolle, sowie
Netzwerkadressen der Dienste und allgemeine Kontaktinformationen eines
Unternehmens enthalten. Als eigentlicher Dienst (Geschäft) wird der Austausch von
Dokumenten angesehen. [Hofstetter et al. 2003]
Die Transaktion der Daten kann dabei zwischen zwei Geschäftspartner (Binary
88
http://www.xmlrpc.com/spec
Seite 86
Collaboration) oder mehreren Geschäftspartnern (Multipart Collaboration) erfolgen. Der
Dokumentenaustausch erfolgt nach einem gesicherten Handshake Prinzip und wird über
das Message Service (ebMS) abgewickelt. Das ebMS basiert auf SOAP mit Attachments
im MIME Format. Ein Vorteil des ebMS ist, dass grundlegende Eigenschaften bereits
standardisierter Mechanismen genutzt werden, um so offen für Erweiterungen zu sein.89
[Hofstetter et al. 2003]
5.8.
SOAP
Das Simple Object Access Protokoll (SOAP) definiert ein "leigthweight" Protokoll
zum vereinfachten Informationsaustausch zwischen verteilten Informationsstrukturen.
Der Datenaustausch erfolgt dabei strukturiert und typisiert zwischen Applikationen.
SOAP ist keine eigene Programmiersprache, sondern definiert einfache Ausdrücke die
mittels XML zum Datenaustausch dienen. Entsprechend ist es einfach als
Kommunikationspfad z.B. das HTTP Protokoll zu nützen. SOAP definiert ein Framework
in dem festgelegt wird, wie eine "Message" auszusehen hat, wie diese "Message" zu
handhaben ist und was optionale bzw. vorgeschriebene Parameter sind. Weiters legt
SOAP Regeln für die sichere Datenübertragung mittels serialisieren fest und gibt
Möglichkeiten vor Remote Procedure Calls zu verwenden. Vorrangige Ziele im Design
von SOAP sind die Einfachheit und die Erweiterbarkeit des Protokolls. [Scribner et al.
2001]
SOAP Nachrichten, Mitteilungen und Funktionsaufrufe sind wohlgeformte,
serialisierte, XML-kodierte Datenpakete, die unidirektional vom Sender zum Empfänger
gerichtet sind. SOAP ist ein Netzwerkprotokoll und als solches in einer Multilayer
Architektur einsetzbar. SOAP ist laut seiner Spezifikation auch nicht an eine bestimmte
Übertragungstechnologie gebunden. Als Transportschicht kann z.B. HTTP oder BEEP
eingesetzt werden. SOAP ist hierbei als Netzwerkprotokoll anzusehen und nicht als
Architektur für verteilte Objekte. Der Vorteil der Bindung an HTTP liegt in der Tatsache,
dass auch auf Objekte und Informationen hinter Firewalls zugegriffen werden kann. Der
Nachteil an diese Anbindung ist, dass mit SOAP über HTTP keine bidirektionale
Kommunikation (Callback) möglich ist. [Scribner et al. 2001]
Eine SOAP Anwendung identifiziert empfangene Nachrichten anhand des SOAP
"Headers", überprüft alle als "zwingend" deklarierten Attribute. Im Fehler Fall, wird ein
SOAP Fehler generiert und die Nachricht abgelehnt. Die als optional deklarierten
Attribute werden an dieser Stelle der Identifikation ignoriert. Im nächsten
Identifikationsschritt wird überprüft, ob die aktuelle Applikation die "letzte Instanz"
(höchste Instanz) des Zieles für die entsprechende Nachricht ist. Ist dies nicht der Fall,
werden die vorher beschriebenen Identifikationsschritte (Attribute) aus der Nachricht
entfernt und die Nachricht erst dann an die nächste Instanz weitergeleitet. SOAP
serialisiert Daten und keine Objektreferenzen. Dies kann unter Umständen zu
Inkonsistenzen des gleichen Objekts an verschiedenen Orten führen, da es keine
geeigneten Synchronisationsmechanismen gibt. [Scribner et al. 2001]
Die so genannte SOAP „Nutzlast“ ist in einem eigenen SOAP Bereich eingebettet.
Dieser SOAP Bereich ist selbst wiederum Teil der Nutzlast des jeweiligen
Transportprotokolles. Der Nutzlastbereich von SOAP besteht aus dem optionalen SOAPHeader und dem SOAP-Rumpf, der die serialisierten Daten und Funktionsaufrufe enthält.
Im Header gibt es mehrere Elemente die Metainformationen zu einem Funktionsaufruf
89
Für weiterführende Informationen zu ebXML sei auf folgende Quelle verwiesen: http://www.ebxml.org
Seite 87
speichern. Die Daten werden als Kombination von XML-Elementen und Attributen
festgelegt. Wird SOAP auf das statuslose HTTP-Protokoll aufgesetzt, ist die
Grundvoraussetzung einer guten Skalierbarkeit bereits vorgegeben. Natürlich wird durch
die Einführung der XML-Notation des Funktionsaufrufes ein Overhead erzeugt, Keys
müssen geparst werden, Daten entsprechend extrahiert werden, jedoch hält man sich
dabei an einen erprobten und sehr weit verbreiteten Standard. Dieser Overhead liegt
jedoch allen Textbasierten Übertragungsprotokollen zugrunde. Dafür erhält man den
Vorteil einer breiten Unterstützung und großen Interoperabilität. Entsprechend fallen
auch bei Anbindungen an Fremdsysteme geringere Aufwände bei der Konvertierung der
Daten an. Das SOAP Protokoll bietet keine Möglichkeit zur Statusverwaltung von
Objekten. Weiters ist in SOAP nicht festgelegt wie die Speicherbereinigung von
verteilten Systemen (Objekten) abläuft. SOAP spezifiziert Übertragungsprotokolle und
kümmert sich nicht um objektorientierte Architekturkomponenten. D.h. Garbage
Detection und Garbage Collection muss vom Objekt bzw. von der Anwendung die das
SOAP Protokoll implementiert selbst durchgeführt werden. SOAP sieht in seiner
Spezifikation keine eigenen Sicherheitsmechanismen vor. Vielmehr verlässt sich SOAP
dabei auf seine Trägerschicht. Bei HTTP etwa über die Verbindung mit HTTPS, SSL
oder sicheren Sockets. Damit kein ungehinderter Datenfluss durch Firewalls stattfinden
kann, empfiehlt SOAP im Header das Attribut SOAPAction festzulegen. Anhand dieses
Attributes können Firewalls SOAP-Methodenaufrufe filtern oder zur Gänze ablehnen.
[Scribner et al. 2001]
Vorteile von SOAP sind nicht zuletzt deren Unabhängigkeit, Flexibilität und
Erweiterbarkeit, sondern auch eine breite Interoperabilität durch den Einsatz
standardisierter
Definitionsmechanismen.
SOAP
unterstützt
z.B.
die
Schnittstellenvalidierung durch XML-Schemata (siehe Abschnitt 5.4.4). Schemata sind
als XML-Beschreibungssprachen anzusehen. Mit Schemata können auf neutrale,
programmiersprachenunabhängige Weise Schnittstellen, Typen und diverse Funktionen
definiert werden. Als Komponentenbeschreibungssprache (Component Description
Language) unterstützen Schemata sowohl primitive als auch benutzerdefinierte
Datentypen. Um komplexere Informationsstrukturen abbilden zu können, wird der
Einsatz von Aliase, Schnittstellenvererbung, Arrays und Strukturdefinitionen ermöglicht.
SOAP schreibt nicht zwingend vor Schemata einzusetzen, jedoch erleichtert es vor allem
die Validierung der Daten. Von Prinzip aus könnte man auch Dokumenttypdefinitionen
(DTDs, siehe Abschnitt 5.4.3) aus XML verwenden. Jedoch erlauben diese keine
Konstrukte, keine Vererbung oder die Definition komplexerer Datentypen. Mittels XSLT
(Extensible Style Language Transformation, siehe Abschnitt 5.4.5) können XMLFormate einfach in ein entsprechendes Zielformat umgewandelt werden. Mit XSLT kann
HTML-Code für Webinhalte erzeugt werden, oder als „Übersetzer“ zwischen
verschiedenen SOAP Protokollversionen (z.B. SOAP v0.9, SOAP v1.2) oder
Protokolltypen (z.B. XML-RPC, XMOP, ebXML) eingesetzt werden. [Scribner et al.
2001]
Um einen Datenaustausch zwischen zwei Systemen ermöglichen zu können, müssen
zu übertragende Argumente normalisiert werden. Zeiger auf Daten bzw. Objekte müssen
dereferenziert und in eine Normalform gebracht werden. Dieser Prozess wird allgemein
als Marshalling oder Serialisierung bezeichnet. Nachdem die normalisierten Daten zum
Zielsystem übertragen wurden, werden die Argumente mittels Deserialisieren in den
neuen Adressbereich übernommen. SOAP serialisiert Daten, Objekte und Funktionen
mittels XML-Statements. Serialisieren kann man jedoch nur Werte, nicht aber
Referenzen. In Abbildung 5.4 ist beispielhaft ein Objektmethodenaufruf in SOAP
Seite 88
Kapitel 5 - Transport
ransport Protokolle
grafisch dargestellt. Hier wird beispielhaft ein Druckaufruf an ein externes System
weitergeleitet. Das Lokale System serialisiert Druckdaten in ein XML-Dokument und
übergibt den normierten Datenstrom an das HTTP-Protokoll. Die HTTP-Pakete werden
mittels TCP/IP über das Internet übertragen und vom Zielsystem in der umgekehrten
Reihenfolge interpretiert. Die SOAP Implementierung löst die XML-Nutzlast aus dem
HTTP-Datenstrom heraus und führt die Deserialisierung durch. [Scribner et al. 2001]
Prozessadressraum des Aufrufers
(lokales System)
Abbildung 5.4: Objektmethodenaufruf in SOAP über HTTP [Scribner et al. 2001]
Das verwenden von Namensräumen in SOAP erweist sich als vorteilhaft, wenn man
gleichzeitig Zugriff auf Objektdaten und Schnittstellenmethoden benötigt. Ein
Namensraum wird über bestimmte Bezeichner abgebildet. Diese Bezeichnet, auch als
URI (Uniform Resource Identifier) genannt, verweisen auf eine bestimmte Entität oder
Ressource im Web. Eine URI ist global eindeutig und wird in unterschiedlichen
Ausprägungen wie z.B. URN (Uniform Resource Name) oder URL (Uniform Resource
Location) verwendet. Während über eine URL bestimmte ortsabhängige Ressourcen im
WWW angesprochen werden können, verweisen URN auf Ressourcen und Objekte
unabhängig vom Ort. Elemente eines XML-Namensraumes werden über URIs
angesprochen. Die Deklaration eines Namenraumes in XML erweitert Element und
Attributnamen zu voll qualifizierten Bezeichnern. Voll qualifizierte Bezeichner vermeidet
Namenskonflikte auch ermöglicht die Wiederverwendung von Bezeichnergruppen. Ein
Namensraum wird deklariert, indem ein Namensraum-Präfix mit einem URI verknüpft
wird. Über dieses Präfix werden nun Attribute und Elemente mit dem Namensraum
verbunden. [Scribner et al. 2001]
Eine SOAP Nachricht besteht aus drei spezifischen Bereichen. Dem Umschlag
(envelope), einer optionalen Nachrichtenkopf (header) und dem Nachrichteninhalt
(body). Das Element envelope stellt das Wurzelelement einer SOAP Nachricht dar und
kapselt die XML-Daten in serialisierter Form. Der optionale header wird verwendet, um
Seite 89
zusätzliche Metadaten (Transaktionsdaten, Authentisierungsdaten, Sicherheitsdaten, etc.)
bezüglich der Nachrichtenübertragung angeben zu können. Wird ein header angegeben,
muss dieser als erstes in der SOAP Nachricht deklariert werden. Zusätzlich ist die
Einführung eines separaten Namensraums für den header vorgeschrieben. Der SOAP
body enthält die serialisierten Methodenaufrufe, Ergebnisse oder transportiert
Fehlerinformationen. Für jeden Methodenaufruf wird ist ein eigenes Element vorgesehen.
Methodenparameter und Rückgabewerte sind Unterelemente der Methodennamen. Ein
SOAP Fehler ist eine spezielle Nachricht, die einen Fehlercode und eine
Fehlerbeschreibung enthält. In SOAP wird zwischen einfachen und zusammengesetzten
Datentypen unterschieden. Einfache Datentypen sind Integer bzw. Fließkommawerte,
Strings, Boolean etc. Einfache Datentypen werden zum einen direkt aus der XML
Definition übernommen, zum anderen sind in SOAP selbst einfache Datentypen definiert.
Zusammengesetzte Datentypen (Akzessoren) werden als Verbunde (Structs) oder Arrays
abgebildet. Während ein Array eine Liste gleicher Datentypen speichert, kann mit einem
Verbund eine Sammlung unterschiedlichster Datentypen aufgebaut werden. Akzessoren
sprechen ihre Elemente mit Referenzen an. Diese müssen beim Serialisieren erzeugt
werden. Mit der XLink bzw. XPath Technologie kann Referenzierung abgebildet werden.
[Scribner et al. 2001].
5.9.
Jabber
Jabber stellt eine Sammlung offener XML basierter Protokolle im Bereich Instant
Messaging zur Verfügung. Mit diesen Protokollen werden mittels XML-Streaming RealTime
Messaging,
Notifizierung,
Datei-Transfer,
Chat-Option,
Authentifizierungsverfahren und Invisibility-/Unavailibility-Modes ermöglicht. Der
Sicherheitsaspekt wird dabei auch nicht außer Acht gelassen. Die Kommunikation kann
über verschlüsselte Verbindungen laufen. Die Transportprotokolle werden von der Jabber
Software Foundation gewartet und weiterentwickelt. Mehr als 1500 Jabber Mitglieder
arbeiten an der Weiterentwicklung der Jabber Communication Plattform und anderen
laufenden Jabber Projekten. Projekte wie Whiteboarding, Anbindung an andere
Nachrichtendienste wie SMS und die Erweiterung der Protokolle zur Unterstützung
mobiler Geräte sind Pläne für die Zukunft. Über verschiedene Plugins (Gateways) wird
das Jabber Protokoll erweitet, um auch mit Benutzer aus anderen Instant Messaging (IM)
Anwendungen wie ICQ-, AIM-, MSN, Yahoo kommunizieren zu können. [Saint-Andre
2002]
Die Architektur entspricht einer Mischung aus Client-Server und P2P Kombination.
Die Benutzer verfügen über einen Client, mit dem sie sich an einem (kein bestimmter)
Jabber Server anmelden. Die vielen verteilten Server tauschen die Nachrichten mit einem
"XML-Stream" untereinander aus und leiten diese zum Empfänger weiter. Die Clients
können aber auch direkt mit anderen Jabber Clients kommunizieren. Der
Verbindungsaufbau vom Jabber-Client zu einem IM-Dienst erfolgt immer nach
folgendem Prinzip: Der Jabber-Client meldet sich bei einem Jabber-Server an, dieser
leitet dann die Nachricht über ein entsprechendes Gateway an den IM-Dienst weiter. Mit
Stand Dezember 2001 gab es laut Jabber mehr als 50.000 Jabber-Server und mehr als
200.000 Jabber Benutzer. Im engeren Sinne ist Jabber also nichts anderes als ein XMLRouter. Dafür sprechen auch die Server Routing Protokolle bzw. Dienste die Jabber
bietet. Folgende Dienste werden von der Jabber Communications Plattform angeboten
[Jabber 2001a]:
• XML Routing: Im Gegensatz zum herkömmlichen Datentransfer im Internet laut
Seite 90
Abbildung 5.5 erfolgt die Nachrichtenweiterleitung in Jabber mittels XML-Streaming
(Abbildung 5.6) auf bidirektionale Weise. Ähnlich zum Internet Emaildienst über
SMTP erfolgt die Zustellung über das Netzwerk mittels DNS in optimierter Weise,
damit eine möglichst gute Auslastung des Systems auch Übertragungen in Real Time
zulässt.
Abbildung 5.5: Herkömmlicher Datentransfer im Internet, Seriell, fest verbunden [Jabber 2001a]
Abbildung 5.6: Jabber Datentransfer: XML-Streaming, asynchron, lose gekoppelt [Jabber 2001a]
• Instant Messaging Dienst: Dienste wie Chat, Text Conferencing oder Roster
(personalisierte Mitgliederlisten), werden unter Einhaltung verschiedenster
Sicherheitstechnischen Aspekten ermöglicht. Dazu gehören Client-Server
Verbindungen mittels SSL, die Unterstützung von Sicherheits-Profilen (Privacy online
Präsenz nur für ausgewählte Benutzer, Nachrichteneingang sperren, etc.) und
Verbindungen über spezielle Ports mittels Outbound Requests (Firewall siehe
Abbildung 5.7). Die Jabber-Architektur bietet Multiple Logins, User Search, Offline
Store, Offline Request und History.
Abbildung 5.7: Jabber in Zusammenhang mit Firewall geschütztem Zugriff [Jabber 2001a]
Verschiedene
Skaliermöglichkeiten
bieten
genügend
Ansatzpunkte,
um
die
Seite 91
Performance des Gesamtsystems steuern zu können. In der folgenden Aufzählung werden
die Möglichkeiten kurz beschrieben [Jabber 2001a]:
• Load Balancing: Aufteilen von Lasten und Isolation von Systemfehlern.
• Parallel Processing: Unterstützung von multiple Prozessor Architekturen, Parallel
Processing und Processor Multi-threading.
• Connection Multiplexing: Ein Client Connection Manager leitet eingehende
Verbindungen mittels multiplexing unter Verwendung von TCP Sockets zu einer
Ausgangsverbindung weiter.
• Optimized Message Routing: Verwendung von optimierten Algorithmen bei
Interpretation und Weiterleitung der XML Nachrichten.
• Throughput Performance: Ein kommerzieller Jabber Server wurde in einem
Testszenario von mehr als 200.000 gleichzeitigen Benutzern, und 8.000 Nachrichten
in der Sekunde getestet.
Datenschutz und Sicherheitsmechanismen werden durch sessionbasierte Protokolle
zwischen Client und Server, in Verbindung mit SSL-Encryption der Datenübertragungen,
realisiert. Passwörter werden mittels SHA1 Encryption von den Jabber Servern
gespeichert. Weiters schützt ein „Subscription Control“ Mechanismus vor Zugriff auf
private Informationen, wie Onlinestatus etc. Mit einem „Server-to-Server Dial Back“
(eine Art Handshake) wird versucht eine Nachricht über eine gültige Jabber Serverstrecke
zu senden. Erst wenn eine gültige (sichere, nicht notwendigerweise über SSL) Strecke
gefunden wurde, wird die Verbindung tatsächlich aufgebaut und die Nachricht
übertragen. Die Suche nach Benutzer wird über versteckte Benutzer IP Adressen
bewerkstelligt. [Jabber 2001b]
Die Jabber Communication Plattform (JCP90) besteht aus vielen einzelnen
Komponenten, die über Router bzw. Gateways miteinander verbunden werden. Es wird
unterschieden zwischen internen Komponenten oder externen Komponenten, die über
XMPP (Extensible Messaging and Presence Protocol) angebunden werden. In Abbildung
5.8 wird die vereinfachte Architektur der Jabber Communication Plattform dargestellt.
Abbildung 5.8: Vereinfachte Architektur91 der Jabber Comm. Plattform [Saint-Andre 2003]
XMPP ist ein offenes erweiterbares auf XML-basierendes Protokoll. Es ist das
Kommunikationsprotokoll im Jabber Framework um XML-Datenströme in nahezu
Echtzeit zu transportieren. Standardisierungsbemühungen laufen mit dem IETF um die
Technologie weiter vorantreiben zu können. Die Spezifikation von XMPP geht aus den
Requirements des [RFC 2779] hervor. Ein XML-Datenstrom wird als Container
bezeichnet der XML Elemente über ein Netzwerk transferiert. Der Datenstrom selbst ist
durch spezifische XML Elemente (<stream> </stream>) eingeschlossen. In einem
90
JCP:
http://www.jabber.org/ietf/draft-miller-jabber-00.html;
http://www.jabber.com/pdf/Jabber_Messaging_Web_Services.pdf
91
Abkürzungen: C1-C3 XMPP Client; S1, S2 XMPP Server, G1 Gateway (Übersetzer zwischen XMPP und anderen
Protokollen); FN1 fremdes IM Netzwerk
Seite 92
Datenstrom können beliebig viele Datenpakete übertragen werden. Der XML Datenstrom
ist unidirektional. Wird vom Client ein „initial stream“ gestartet, antwortet der Server mit
einem „response stream“. Beim Aufbau der Datenströme werden zusätzlich
Übertragungsparameter ausgehandelt. Dazu gehören Sicherheitsanforderungen (TLS) und
Authentifizierungsmechanismen (SASL). Datenpakete innerhalb eines Datenstromes
werden „XML stanza“ bezeichnet. XML stanza sind gekennzeichnet durch ihre Position
innerhalb des Datenstromes und durch ihre Bezeichner. XML stanza müssen direkt in der
ersten Ebene eines Streams definiert werden. Als Bezeichner sind lediglich <presence>,
<message> und <iq> zugelassen. In einem XML stanza ist die Datenstruktur bzw. eine
Message mit Hilfe von Kinderelementen, Attributen und Daten (CDATA-Sektion)
abgebildet. Zur nähren Erklärung weiterer Elemente wie z.B. Verhandlungsparameter
oder Errorhandling sei auf die Literatur verwiesen92. [Saint-Andre 2003]
5.10. JXTA Protokolle
JXTA stellt eine Plattform-unabhängige Technologie zum Aufbau von P2P
Netzwerken dar. JXTA ist Programmiersprachen- und Geräte-unabhängig (obwohl es
zurzeit nur eine JAVA Implementierung des JXTA Core gibt). Die JXTA Architektur
trennt den JXTA-Core (Auffinden von Peers, Routing, Kommunikationsmanagement,
etc.) von den JXTA-Diensten (Suchen, Datenaustausch, Indizieren, Authentifikation, etc.)
und den JXTA-Applikationen (IM, Tauschbörsen, Filesharing, etc.). JXTA sieht kein API
vor mit der die Funktionalität angesprochen werden kann, stattdessen propagiert JXTA
eine Sammlung von Protokollen, mit deren Hilfe P2P Netzwerke aufgebaut werden
können. Die Protokolle sind nachrichtenorientiert und basieren auf XML. Im Design der
Protokolle wurde berücksichtigt, dass die Nachrichten sehr effizient mit möglichst wenig
Overhead auch in unzuverlässigen und veränderbaren Netzwerken transportieren sollen.
JXTA Protokolle sind grundsätzlich offen für verschiedene Transportprotokolle, setzen
aber in der gegenwärtigen Implementierung auf TCP/IP auf. Die Protokolle werden
einerseits für Kommunikation und Resourcen-Sharing zwischen Applikationen und
Services genutzt, andererseits ermöglicht es den Peers sich selbst zu organisieren ohne
die Netzwerkstruktur zu kennen. Insgesamt sind im JXTA Core sechs voneinander
unabhängige Protokolle definiert: Peer Discovery Protocol (PDP), Peer Information
Protocol (PIP), Pipe Binding Protocol (PBP), Endpoint Routing Protocol (ERP) und
Rendezvous Protocol (RVP). Ein JXTA Peer muss zumindest zwei dieser Protokolle
(PRP und ERP) unterstützen um als JXTA Peer adressierbar zu sein. In Abbildung 5.9 ist
die Protokollstruktur von JXTA abgebildet. [Duigou 2003]
92
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence: http://www.ietf.org/internetdrafts/draft-ietf-xmpp-im-19.txt
Extensible Messaging and Presence Protocol (XMPP): Core: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core20.txt
End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP):
http://www.ietf.org/internet-drafts/draft-ietf-xmpp-e2e-06.txt
Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging
(CPIM):
http://www.ietf.org/internet-drafts/draft-ietf-xmpp-cpim-03.txt
Seite 93
Peer Information
Peer Information
Peer Rendezvous
Peer Rendezvous
Pipe Binding
Pipe Binding
Peer Discovery
Peer
Peer Discovery
Peer
Peer Resolver
Peer Resolver
Endpoint Routing
Endpoint Routing
Endpoint
Endpoint
Transport (TCP/IP)
Abbildung 5.9: JXTA Core Protokollstruktur [Duigou 2003]
• Peer Resolver Protocol (PRP): Das PRP stellt ein Query/Response Protokoll dar.
Queries können an alle Peer Groups oder an spezielle Peer Groups über einen
Mulitcast gerichtet werden. Auf eine Query antworten jedoch nur Peers, die über eine
entsprechende Behandlungsprozedur verfügen. Deshalb kann ein Peer auch mehrere
Antworten auf eine Query erhalten. Eine Response-Massage ist stets nur an den Peer
gerichtet, der eine Query ausgesandt hat. Im Massage-Body einer Query ist eine
Unique-Id enthalten, über die jeder Peer eindeutig adressierbar ist. Zum Verbreiten
einer Query wird das Rendezvous-Service angesprochen. Zum Einsatz kommt das
Protokoll bei Filesharing Diensten oder erweiterten Suchdiensten.
• Peer Discovery Protocol (PDP): PDP beschreibt einen Mechanismus mit dem Peers
eigene Dienste und Ressourcen veröffentlichen sowie Dienste und Ressourcen anderer
Peers (Peer Groups, Services, Pipes und anderen Peers) in Anspruch nehmen können.
Jede Peer-Ressource wird mit einem „Advertisement“ (Metadaten in XML-Notation)
beschrieben. Zum Aufsuchen bzw. Veröffentlichen der Ressourcen wird das PRP
verwendet.
• Peer Information Protocol (PIP): Mit dem PIP ist eine Statusabfrage von JXTA Peers
möglich. Peers müssen auf einen PIP Request nicht antworten. Zu den
Statusinformationen gehören z.B. Traffic Load (Auslastung, Anzahl eingehender und
ausgehender Requests, sowie Zeit des letzten eingehenden und ausgehenden Requests)
oder Uptime (wie lange ein Peer aktiv ist).
• Pipe Binding Protocol (PBP): Pipes sind abstrakte, eindeutige (unique id)
unidirektionale Kommunikationskanäle die wiederum durch Advertisements
beschrieben werden. Mit dem PIP ist es möglich Peer-Pipes miteinander zu verbinden.
Aus Sicht der Endpunkte wird ein sendender Peer als Outputpipe und ein
empfangender Peer als Inputpipe bezeichnet. Mit der Hilfe des Discovery Service
kann das Binding zur Laufzeit durchgeführt werden. Die direkte Verbindung zweier
Peers wird als „Point-to-Point-Pipe“ bezeichnet. Ist eine Outputpipe mit mehreren
Inputpipes verbunden, spricht man von einer „Propageted-Pipe“ oder „Multicast-Pipe.
• Endpoint Routing Protocol (ERP): Das ERP wird eingesetzt um Routing
Informationen (Folge von Router-Endpunkten) zum Nachrichtenversand zu erstellen.
Der Nachrichtenversand zwischen Peers erfolgt unabhängig zu ihren physikalischen
Standorten. Um eine Nachricht an ein Ziel Peer zu versenden, versucht ein Peer lokal
gespeicherte Routing Informationen auszuwerten. Sind keine Routing Daten
gespeichert, oder die Daten veraltet, hilft das ERP die Nachricht über alternative Wege
an das Ziel zu bringen. Mit dem ERP können z.B. Peers unterschiedlicher
Netzwerkprotokolle verbunden werden, oder Nachrichten über Firewalls geschleust
Seite 94
werden. Jeder Router markiert das Erreichen seines Endpunktes in der Nachricht. Mit
Hilfe dieser Informationen können lokale Routing Informationen upgedatet werden
und Irrläufe von Nachrichten vermieden werden.
• Rendezvous Protocol (RVP):Das RVP kann einerseits zur Weiterleitung von
Nachrichten an Rendezvous-Peer eingesetzt werden und andererseits zur Kontrolle der
Nachrichtenverbreitung dienen, indem es das Weiterleiten von bereits gesendeten
Nachrichten verhindert. Außerdem werden Nachrichten verworfen, deren „Time-tolife“ abgelaufen ist. Das RVP wird unter anderem vom PRP und PBP genutzt.
5.11. Schlussbemerkung
In diesem Kapitel wurde eine Auswahl von sieben Transport-, Nachrichten- und
Netzwerkprotokollen analysiert. Die Protokollauswahl reicht dabei vom quasi
„historischen“ Z39.50 Protokoll, bis hin zu modernen P2P Protokoll Frameworks wie
Jabber oder JXTA. Die Analyse zeigt deutlich die Tendenz zur Unterstützung von XMLbasierten Technologien. Diese sind großteils standardisiert, einfach aufgebaut, leicht
erweiterbar, „human-readable“, „machine-readable“ und sehr weit verbreitet. Es
existieren viele Werkzeuge zur Erstellung und Validierung von XML-Dokumenten. Als
Parser kommen DOM-Parser oder SAX-Parser zum Einsatz. Im Zuge der
Datenübertragung werden jedoch meist nur SAX-Parser eingesetzt. Diese arbeiten
effizient und sind nicht starr an ein bestimmtes Schema gebunden. Die gängigsten
Möglichkeiten zur Validierung sind DTD, XML-Schema und XSLT. XML bildet Daten
als klar strukturierte Elemente ab. Beziehungen zwischen Elementen und Dokumenten
können mit XLink, XPath und XPointer hergestellt werden.
Das Protokoll Z39.50 gilt als Standard im Bereich Information Retrieval. Es basiert
auf einer Client/Server Architektur mit verschiedenen Request/Response Messages. Das
Z39.50 Protokoll wird einerseits zur Suche verwendet andererseits bietet Z39.50 auch
Kontrollfunktionen und Datenbankfunktionen an.
BEEP stellt ein Protokoll Framework dar. Es ist als Modulkonzept ausgelegt, verfügt
über generische und einfache Protokolle, die eine Widerverwendbarkeit der Module
ermöglichen. Die BEEP Architektur (P2P) erlaubt das multiplexen von Datenkanälen um
mehrere gleichberechtigte Endpunkte miteinander verbinden zu können. Die
Kommunikation erfolgt asynchron und bilateral. Nachrichten werden im MIME Format
übertragen und halten sich so an einen bewährten Standard. Durch die Unterstützung von
Sicherheitsprofilen, die gesicherte Datenübertragung und Authentifikation erlauben, ist
auch ein Proxy-Tunneling oder das Überbrücken von Firewalls möglich. BEEP kann
HTTP als missbräuchliche Verwendung in Anwendungsprotokollen ersetzen.
XML-RPC gilt als leichtgewichtiges Protokoll, dass auf eine Client/Server Architektur
mit einfachen Request/Response Messages basiert. Die Methoden werden in XMLNotation serialisiert und die Methodenargumente bzw. Rückgabewerte anhand der
standardisierten XML-Typenspezifikation übergeben. Die XML-RPC Syntax ist zwar
flexibel und einfach, jedoch könnte XML-RPC auch durch SOAP-Statements umgesetzt
werden. Einfache XML-Datentypen können zu Strukturen oder komplexen Datentypen
zusammengefasst werden.
Das Ziel von ebXML ist EDI im Bereich B2B zu modernisieren bzw. mit dem Web zu
verknüpfen. Ähnlich zur Web Service Architektur bietet ebXML eine eigene zentrale
Registry an, um Geschäftspartner bzw. deren Dienste zielorientiert veröffentlichen zu
können. Zum Austausch von Geschäftsdokumenten werden standardisierte Protokolle
Seite 95
eingesetzt; SOAP in Verbindung mit MIME typisierten Attachments. Mit ebXML ist der
Aufbau von Mehrfachverbindungen möglich (ein Provider - mehrere Consumer;
Multipart Collaboration).
SOAP gilt als leichtgewichtiges Protokoll, das vor allem zum Einfachen
Informationsaustausch eingesetzt wird. SOAP gilt als Netzwerkprotokoll und ist keine
Architektur für verteilte Objekte. Mit SOAP ist keine bidirektionale Kommunikation
möglich. SOAP bietet selbst keine Sicherheitsmechanismen bzw. Möglichkeiten zur
Authentifizierung an und stellt keine Konzepte zur Speicherverwaltung zur Verfügung.
SOAP stützt sich dabei einerseits auf die Transporteinheit (HTTP-SSL, BEEP) oder
verlagert die Komplexität hin zur Applikation (Speichermanagement). Dafür gibt es eine
Reihe
von
Validierungsmöglichkeiten
der
XML-Daten
und
einfache
Transformationsmöglichkeiten (XSLT) der Daten um verschieden Zielformate zu
unterstützen. Das Datenmodell setzt das standardisierte XML-Typenschema ein.
Jabber bietet eine Sammlung offener Protokolle, die vorwiegend im Bereich Instant
Messaging eingesetzt werden. Die Jabber Protokolle sind nicht standardisiert, werden
aber laufend von der Jabber-Foundation weiterentwickelt. Jabber unterstützt Plugins um
Fremdsysteme einfach ankoppeln oder miteinander verbinden zu können. Die JabberArchitektur ist eine Mischung aus Client/Server und P2P. Daten werden mittels XMLStreaming übertragen. Jabber bietet Sicherheitskonzepte für Transport und
Authentifikation an und kann für XML-Message Routing eingesetzt werden. Weiters sind
Loadbalancing, Parallel Processing sowie das Multiplexen von Datenkanälen zur
Steigerung der Performance möglich.
In JXTA sind sechs grundlegende Protokolle definiert. Die JXTA P2P Architektur
trennt Applikationen von Diensten und dem JXTA Core. Mit JXTA können
selbstorganisierende P2P Netzwerke aufgebaut werden. Die sechs Core Protokolle
verwenden ein minimales XML-Subset und einen limitierten Namespace. Der spezielle
leichtgewichtige DOM-Parser validiert keine XML-Daten. Aus diesem Grund kann
JXTA auch in unzuverlässigen und veränderbaren Netzwerken noch hohe Bandbreiten
erreichen93. Ein Peer muss nicht alle Core Protokolle unterstützen. Entsprechend sind
auch die Aufgaben eines Peers unterschiedlich. Ein Peer kann als Provider, Consumer,
Router, Resolver, Hub oder Registry eingesetzt werden.
Um einen besseren Überblick über die vorgestellten Protokolle und Technologien zu
bekommen, werden die jeweiligen charakteristischen Eigenschaften der einzelnen
Protokolle einander gegenübergestellt. Dieser Vergleich soll Ausgangspunkt für die
weiteren Analysen sein bzw. Vorschläge zur Verbesserung der Kommunikationsschicht
des xFIND Suchsystems liefern. In Tabelle 5.1 sind die wichtigsten Eigenschaften der
untersuchten Protokolle zusammengefasst dargestellt.
93
Diese Aussagen stützen sich auf Angaben von: http://www.jxta.org
Seite 96
94
Eigenschaften
Erweiterbarkeit
Datentransport
Widerverwendbar
Errorhandling
standardisiert
Sicherheit
Authentifikation
Z 39.50
BEEP
NO, VO, ZB
schwer
AS, NO, VO
einfach (XML)
MIME
ja
ja
ja
nein
ja
ja
Zugriffskontrolle
ja
Besonderheiten
große
Akzeptanz
Einsatzgebiete
Query
Protokoll,
Information
Retrieval
XML-RPC
ebXML
SOAP
VO, ZB
NO, ZB
NO
einfach (XML) einfach (XML) einfach (XML)
XML
MIME + XML
XML
ja
ja
ja
ja
nein
ja/nein
ja
Jabber
JXTA
AS, BD, NO
einfach (XML)
S/MIME
AS, NO
einfach (XML)
MIME
ja
ja
ja
eingereicht
eingereicht
TLS, PTLS
nein
ja
nein
TLS, SSL
Groups
SASL
nein
ja
nein
SHA1, SASL
LDAP, JAAS
P2P, Routing,
Kanalmultiplexing,
Framework,
P2P, Load
Überbrückung
Sicherheitsprofile,
Routing,
einfach, weit Balancing, Parallel von Firewalls,
Überbrückung von
unterstützt
verbreitet
Processing,
eigenständige
Firewalls
UDDI
Kanalmultiplexing Organisation
der Peers
Anbindung an
Filesharing,
Trägerschicht für
verschiedene IM
EDI (Elektronic
Indexing,
verschiedene
Einsatz für
Standard für
Dienste auf
Data
Searching,
XML Protokolle, Webservices
Datentransfer unterschiedlichsten
Interchange)
Aufbau von
HTTP-Ersatz
Plattformen und
Netzwerken
Geräten
Tabelle 5.1: Eigenschaften von Transport Protokollen
Nachdem in diesem Kapitel ausführlich auf die Datenübertragung und die
Kommunikation in verteilten Architekturen eingegangen worden ist, muss zum Abschluss
des Untersuchungs-teiles der Einsatz diverser Protokolle in verteilten Suchsystemen
untersucht werden. Diesbezüglich werden nur Suchsysteme vorgestellt, die in ihrer
Architektur verteilte Konzepte umgesetzt haben.
94
AS: asynchron, BD: bidirektional, NO: nachrichtenorientiert, VO: verbindungsorientiert, ZB: zustandsbehaftet
Seite 97
Kapitel 6
6.
Verteilte Suchsysteme
Die Informationsauffindung im Internet bereitet herkömmlichen Index- oder MetaSuchmaschinen vermehrt Probleme. Auf der einen Seite können die verschiedenen
Suchmaschinen nur willkürlich spezifische Teile im Internet abdecken und auf der
anderen Seite bietet eine gezielte Suche nach speziellen thematisch gegliederten Inhalten
auch nur einen Eingeschränkten Zugriff auf die verteilten Informationsinhalte. Zudem
liefern die Suchmaschinen viele oft für den Benutzer unbrauchbare Resultate. Des
weiteren können diese Suchmaschinen nur statische Informationen absuchen. Der größte
Teil der Informationen ist aber im so genannten „Deep Web“ (nur über Linkverfolgung
erreichbare Datenbankinhalte) gespeichert. Der Zugriff auf diese Datenbestände kann nur
von lokal installierten Diensten ermöglicht werden. Um diese Dienste auch
Suchmaschinen zur Verfügung stellen zu können, wird der Einsatz von geeigneten
standardisierten Schnittstellen bzw. Abfragemechanismen benötigt.
Ziel beim Entwurf von verteilten Suchsystemen ist meist ein möglichst offener
Architekturansatz, um eine gute Skalierbarkeit und einfache Erweiterbarkeit des Systems
erreichen zu können. Verteilte Suchsysteme können die Netzwerklast durch lokale
Verarbeitung bzw. Vorverarbeitung der Daten verringern und eine Spezialisierung auf
bestimmte Themengebiete vornehmen. Die Anreicherung der Datenbestände mit manuell
erstellten Metadaten führt zur Auffindung qualitativ hochwertigeren Ergebnismengen.
Der Einsatz von automatisierten Klassifizierungsdiensten, diversen Filtern und
statistischen Analyseverfahren liefert zusätzliche Entscheidungshilfen bei den
Recherchen.
In diesem Kapitel werden verschiedene Architekturansätze für verteilte Suchsysteme
vorgestellt und analysiert. Moderne verteilte Ansätze aus dem Bereich Peer-to-Peer
werden dabei den verteilten Modellen wie z.B. Harvest und xFIND, gegenüber gestellt.
Die nun folgenden Abschnitte sollen aufgrund der Analyse der jeweiligen
charakteristischsten Eigenschaften der verschiedenen Architekturen die notwendigen
Erkenntnisse zur Verbesserung der xFIND Kommunikationsschicht liefern.
6.1.
Freenet
Freenet ist ein skalierbares, selbstorganisierendes, fehlertolerantes P2P Netzwerk. Die
Architektur ist zur Gänze dezentralisiert aufgebaut und wird vorwiegend als
kollaboratives, virtuelles File System eingesetzt. Die Architektur von Freenet sieht
Datenredundanzen vor, um die Erreichbarkeit der Daten gewährleisten zu können. Zu den
Grundelementen der Freenet Technologie gehören Nodes, Dokumente und Interaktionen.
Nodes verwalten die Routing-Tabellen, dienen als Datenspeicher und speichern
Dokumentinhalte mehrfach und erzeugen so bewusst Datenredundanzen. Dokumente
werden über Search Keys (Keyword Signed Key, Content Key) identifiziert und in Form
Seite 98
Kapitel 6 - Verteilte Suchsysteme
von Byte Strings gespeichert. Als Interaktionen oder Transaktionen werden NetworkJoins sowie das Einfügen und Suchen von Dokumenten bezeichnet. [Clark et al. 2002]
Jeder Node ist mit einer Menge an Nachbar-Nodes verbunden. Die Routing-Tabellen
bestehen aus Paaren von Search Key zu Node Einträgen. Jeder Node verfügt über einen
lokalen Cache, auf den die Freenet Funktionen angewandt werden. In diesem lokalen
Speicher sind die Routing Tabellen und die Dokumente gespeichert. Sowohl der
Dokumentspeicher als auch die Routing Einträge werden nach dem LRU95-Prinzip
gewartet. Das Löschen eines Dokumentes aus dem Speicher wirkt sich nicht auf die
Einträge der Routing-Tabellen aus. Routing-Tabellen werden unabhängig zu den
Dokumentbeständen gewartet. [Clark et al. 2002]
Um zu verstehen, wie die verteilte Suche in Freenet funktioniert, wird zuerst der
Dokument Insert Algorithmus erklärt. Zuerst wird der eindeutige File-Key erzeugt.
Daraufhin sendet der erzeugende Node eine Message mit dem File-Key und einem HopsTo-Live (HTL) Zähler an sich selbst, um den Einfügeprozess zu starten. Der erzeugende
Node überprüft die eigenen Routing-Tabellen, ob der File-Key bereits gespeichert ist. Ist
bereits ein entsprechender Eintrag vorhanden, wird das File an den Initiatorprozess
retourniert, ein neuer File-Key erzeugt und erneut der Einfügeprozess gestartet. Wenn der
File-Key im erzeugenden Node noch nicht eingetragen ist, dann sucht er den
bestmöglichen benachbarten Node, sendet ihm die Einfügenachricht und erniedrigt den
HTL-Zähler. Dieser Vorgang wiederholt sich solange für jeden einfügenden Node, bis
entweder der HTL-Zähler auf null ist, oder eine Kollision erkannt wurde. Eine Kollision
kommt zustande, wenn ein gesuchter File-Key bereits in einer lokalen Routing-Tabelle
eingetragen ist. Tritt eine Kollision auf, wird das entsprechende File zu den jeweiligen
Initiatoren zurückgeschickt. Dabei speichert jeder Node das File lokal bei sich in seinem
Daten-Cache. Zusätzlich wird der Eintrag auch in den lokalen Routing-Tabellen
vermerkt. Wird das Dokument gefunden, sendet der entsprechende Node eine „All Clear“
Message an den Initiator zurück. Auf demselben Weg retour wird auch das entsprechend
gefundene File geschickt. Am Weg retour zum Initiator speichern nun alle Nodes dieses
File und erzeugen einen neuen Eintrag in ihrer lokalen Routing-Tabelle. [Clark et al.
2002]
Der Search Algorithmus96 verhält sich ähnlich zum Dokument-Insert Algorithmus. Ein
Node schickt wiederum eine Message mit einem File-Key und einem HTL-Zähler an sich
selbst. Der Node vergleicht den File-Key mit seiner Routing-Tabelle. Wenn die Datei
lokal gespeichert ist, kann der Suchrequest beendet werden. Ist die Datei nicht lokal bei
einem Node gespeichert, wird die Suchanfrage zum nächst besten Node (mit dem
ähnlichsten File-Key) weitergeleitet und der HTL-Zähler erniedrigt. Ist bei einem Node
die Datei lokal vorhanden, gilt die Suchanfrage als beendet und die gefundene Datei wird
retour zum anfragenden Node geschickt. Beim Weg retour speichert wiederum jeder
besuchte Node die Datei lokal bei sich und fügt einen neuen Eintrag in seiner RoutingTabelle ein. Falls eine Anfrage in eine Sackgasse läuft oder ein Node schon einmal
besucht wurde, schickt der letzte besuchte Node eine Error-Message an den
Einsprungspunkt der Sackgasse. Verschiedene Afragezyklen oder Schleifen werden als
Fehler erkannt. Dieser Node beauftragt dann den Zweitbesten Node mit der Suchanfrage
und so weiter. Dieser Rekursive Algorithmus läuft solange, bis entweder die Datei
gefunden wurde, alle Nodes besucht wurden oder der der HTL-Zähler ausläuft (gleich
95
LRU: Last Recently Used; Ist kein Platz für neue Einträge vorhanden, werden solange die am längsten unbenutzten
Einträge gelöscht, bis wieder genügend Platz vorhanden ist.
96
Sleepest-ascent hill-climbing search; effiziente Ähnlichkeitssuche nach lokalen Maxima
Seite 99
null zeigt). In diesem Fall wird der Anfrage Node eine Error-Message geschickt. Eine
grafische Darstellung einer typischen Suchanfrage zeigt Abbildung 6.1. Der Suchrequest
wird von Node zu Node weitergereicht: Bei Schritt 3 wird eine Sackgasse erkannt und bei
Schritt 7 eine Schleife erkannt. Gefunden wird die Datei in Schritt 10 und von Node d
über Node e und Node b an den Initiator a geschickt. [Clark et al. 2002]
Abbildung 6.1: Freenet Search Algorithmus [Clark et al. 2002]
Das Designziel von Freenet in Zusammenhang mit den GUID97 strebt eine
symmetrische Aufteilung der Dokumente auf die Nodes an. Die völlig verteilte Kontrolle
erlaubt Prozesse zu parallelisieren (verschiedene Nodes können zur selben Zeit suchen,
einfügen, etc.). Performancetests sind bisweilen nur durch Simulationen durchgeführt
worden. Diese zeigen ein annähernd konvergentes Verhalten der Path-Länge (Länge des
Suchweges) bezüglich der Suchdauer. Bei linear steigender Nodeanzahl skaliert die PathLänge logarithmisch. Bezüglich Fehlertoleranz wurde bei einer Ausfallsquote von 30%
bei 1000 Nodes eine durchschnittliche Path-Länge von 20 ermittelt. [Clark et al. 2002]
Ein Problem von Freenet ist, dass die Suche lediglich auf Dokumentinhalte beschränkt
ist. Es gibt bereits Bestrebungen zur Unterstützung von Metadaten, um noch effizienter
suchen zu können. Weitere Schwächen zeigt das System beim Verbindungsaufbau. Da
jeder Node gleichberechtigt im System verankert ist, schlägt sich die
Verbindungscharakteristik der Nodes auf die Fehlertoleranz nieder (Nodes mit
leistungsschwachen Anbindungen verringern die Effizienz). Auch diesbezüglich gibt es
bereits Erweiterungen in den Verbindungsprotokollen, indem Aspekte wie Qualitiy of
Services berücksichtigt werden. Weitere Entwicklungen98 im Suchaufbau bietet etwa die
Arbeit von Omprakash D Gnawali. Dabei werden Keywords aus dem Dokument
extrahiert, mit Metadaten angereichert und in Indexlisten gespeichert.
97
98
GUID: Global Unique IDentifier; ortsunabhängig, nach SHA-1 ermittelt
[Gnawali 2002]: A Keyword-Set Search System for Peer-to-Peer Networks ;
http://www.pdos.lcs.mit.edu/papers/chord:om_p-meng.pdf
[Harren et. al]: Complex Queries in DHT-based Peer-to-Peer Networks;
http://www.cs.rice.edu/Conferences/IPTPS02/191.pdf
[Ng et. al]: PeerDB: A P2P-based System for Distributed Data Sharing;
http://www.cs.cornell.edu/courses/cs732/2003sp/papers/Ng2003.pdf
[Yang et. al]: Efficient Search in Peer-to-Peer Networks;
http://www.cs.utexas.edu/users/browne/CS395Tf2002/Papers/GarciaMolina-showDoc.pdf
Seite 100
6.2.
FASD
Die Beschreibung des FASD-Projektes stützt sich auf die Arbeit von [Kronfol 2002].
FASD (A Fault-tolerant, Adaptive, Scalable, Distributed Search Engine) ist eine
komplett verteilte Sucharchitektur, die auf dem selbstorganisierenden P2P-Ansatz von
Freenet aufsetzt. Aufgrund dieser Eigenschaft ist FASD hoch skalierbar und
fehlertolerant. Gegenüber Freenet, das Dokumente anhand von eindeutigen GUID’s
semantikfrei im Netzwerk verteilt, versucht FASD die Dokumente beim Einfügen in das
Netzwerk näher zu analysieren und charakterisieren. FASD generiert aus den
Dokumenten eine Menge von genannten „Metadata-Keys“. Das ist eine Liste von
Termini, die den Inhalt des Dokumentes beschreibt. Diese Liste wird in Form eines
Vektors gespeichert, wobei die Worthäufigkeiten von Schlüsselwörtern in Dokumenten
das ausschlaggebende Merkmal sind. Schlüsselwörter werden in Lexika festgehalten.
Jeder Vektor besitzt eine Referenz auf das Originaldokument. Die Berechnung des
Vektors basiert auf dem TFIDF99 Prinzip. Dieser Ansatz berücksichtigt die Anzahl der
Dokumente für einen Term in einem Knoten und verknüpft diesen Wert mit der
Häufigkeit des Auftretens des Terms in einem Dokument.
Ein weiterer wichtiger Aspekt in FASD ist die Erkennung von Ähnlichkeiten zweier
Dokument-Vektoren. Die Ähnlichkeit der Vektoren wird als Schlüsselabstand bezeichnet
und kommt bereits beim Einfügen von Dokumenten in das Netzwerk zur Anwendung.
Andererseits müssen die Vektoren bei der Suche mit den Suchanfragen verglichen
werden, um eine Ergebnismenge liefern zu können. Wie bei der Generierung des Vektors
setzt FASD bei der Bestimmung des Schlüsselabstandes auf ein standardisiertes
Gewichtungsverfahren, dem Cosinus-Korrelationswert. Der Cosinus-Korrelationswert
kennzeichnet den Winkel zwischen zwei mehrdimensionalen Dokument-Vektoren. Dabei
gilt, je größer dieser Wert ist, desto größer ist auch die indirekte Ähnlichkeit100 zweier
Dokumente. Nachdem Vektoren die Inhalte der Dokumente repräsentieren, müssen auch
Suchanfragen in eine vergleichbare vektorielle Form gebracht werden. Filteranfragen101
können relativ einfach in einen Vektor transformiert werden, indem die Suchwort-Skalare
auf 1 gesetzt werden. Komplexere Suchanfragen werden in die disjunktive Normalform102
gebracht. So ergibt sich eine Reihe von ODER-Verknüpfungen, die als eigene
Suchanfragen gewertet werden.
Bei der Suchanfrage setzt FASD einen eigenen Routing-Algorithmus (PROCESSQUERY) ein. Dieser Algorithmus liefert die besten n Treffer (Anzahl n DokumentVektoren die am ähnlichsten zum Suchanfrage-Vektor sind). Der FASD RoutingAlgorithmus
berücksichtigt
neben
Cachingmöglichkeiten
auch
diverse
Sicherheitsaspekte. Im Gegensatz zum Freenet Routing-Algorithmus wird solange
gesucht, bis ein HTL-Counter den Wert ‚null’ erreicht hat. Der Grund dafür liegt in der
Tatsache, dass nicht vorhersagbar ist, wann eine Lösungsmenge optimal ist. Unter der
Verwendung von eindeutigen Bezeichnern ist eine Zyklenerkennung möglich. Tritt ein
Zyklus auf, wird der Suchrequest zum Initiator-Node zurückgesandt. Auf diesem Weg
zurück werden alle gefundenen Dokument-Vektoren in einem „Least-Recently-Used“Cache vermerkt. Nachdem der HTL-Wert direkten Einfluss auf die Objektivität der
99
TFIDF: Term Frequency x Inverse Document Frequency
Werden Stemming-Algorithmen oder Stopwortlisten bei der Analyse eingesetzt, steigt auch die Wahrscheinlichkeit
der gänzlichen Übereinstimmung zweier Dokumentvektoren.
101
Filteranfragen: Suchworte werden logisch UND verknüpft
102
Bsp.: x1 ODER (x2 UND x3) ODER (x4 UND x5 UND x6)
100
Seite 101
Ergebnismenge und auf die Suchzeit hat, ist es wichtig, bei der Konfiguration einen
Kompromiss zwischen diesen beiden konträren Objektgrößen zu finden. Je größer der
HTL-Wert, desto ähnlichere Dokument-Vektoren werden geliefert. Kleinere HTL-Werte
haben eine kürzere Suchzeit zur Folge. Um die Suche möglichst effizient durchführen zu
können, speichert jeder Knoten zusätzlich einen invertierten Dokument-Vektor-Index.
Die Suchzeit von Standard Algorithmen bei der Suche in invertierten Indizes ist
proportional zur Länge der Suchquery.
Wie bereits erwähnt, sind in FASD verschiedene Sicherheitsaspekte umgesetzt. In
FASD wird „Zensur“ durch den Routing-Alogrithmus ausgeschlossen. Durch Umgehung
von „vermeintlich“ zensurierten Knoten mittels HTL, können wiederum ähnliche
Dokumente gefunden werden. Da beim Einfügen und bei den Suchprozessen die
Dokument-Vektoren gecached werden, kann ein Dokument auch immer über Umwege
(vergrößern von HTL) gefunden werden. Im derzeitigen Projektstand sind nur
unverschlüsselte Vektoren umgesetzt. Für die Zukunft ist aber auch daran gedacht, dass
neben der Dokumentverschlüsselung (wie in Freenet) auch die Vektoren verschlüsselt
werden. Somit ist dann auch gewährleistet, dass bestimmte Dokumente nur unter
Kenntnis der kryptografischen Merkmale (private, public keys) von Dokument-Vektoren
gefunden werden. Zusätzliche Sicherheit bei die Suche gegenüber einer „Denial of
Service“ Attacke bietet die verschlüsselte Speicherform der Dokumente103. Weiters sagt
der Schlüsselabstand nichts über die Qualität des Suchergebnisses aus. Der
Schlüsselabstand ist ein rein objektiver Wert, die Qualität ein subjektiver Wert (von
Benutzer abhängig). Aufgrund der verschlüsselten Speicherform der Dokumente ist
zurzeit auch keine automatisierte Qualitätsbewertung104 möglich.
6.3.
JXTA
JXTA ist ein Projekt, mit dem über eine geeignete Plattform mittels P2P-Technologie
verteilte Anwendungen entwickelt werden können. JXTA steht für „juxtapose“ quasi dem
Aneinanderreihen von Rechnern in einem Netz. Die JXTA Architektur besteht aus dem
JXTA Core, den JXTA Services und den JXTA Applications. Abbildung 6.2 zeigt den
schematischen Aufbau der JXTA Software Architektur. Der JXTA Core stellt die
grundlegende Kommunikation (Erzeugung von Peer Groups) zur Verfügung. Über die
JXTA Services ist zum Beispiel das verteilte Suchen, eine verteilte Dateiverwaltung oder
das Übersetzen verschiedener Protokolle (Anbindung an Fremdsysteme). Die JXTA
Applications stellen die eigentlichen Anwendungen dar, wie z.B. Email-Client und
Content-Management. Der Nachrichtenaustausch innerhalb von JXTA Komponenten
erfolgt anhand einfach erweiterbarer XML basierender Protokolle. Die JXTA Protokolle
wurden bereits in Kapitel 5 Transport Protokolle im Abschnitt 5.9vorgestellt und näher
untersucht. [Gong 2002]
103
Das FASD Netzwerk müsste mit Dokumenten überflutet werden, die einen ähnlichen Dokument-Vektor besitzen, wie
das zu attackierende Dokument. Dies kann aufgrund der verschlüsselten Dokumentform nur schwer erreicht werden.
104
Zur Bewertung der Qualität könnten z.B. die Anzahl der Suchtreffer für ein Dokument, die Updatefrequenz eines
Dokumentes oder zusätzliche beschreibende Metadaten herangezogen werden.
Seite 102
Abbildung 6.2: JXTA Software Architektur [Gong 2002]
Wie bereits erwähnt, sieht die JXTA Architektur als P2P Ansatz die Kommunikation
zwischen Peers vor, die in so genannten Peer Groups zusammengefasst werden können.
Als Peer wird jede Komponente bezeichnet, die zumindest einen Minimalsatz der JXTA
Protokolle einsetzt. Ein Peer ist durch eine eindeutige ID gekennzeichnet und sucht
automatisiert nach anderen Peers im Netz. Werden Peers zu Peer Groups zusammen
geschlossen, so können diese Services einen besseren Lastenausgleich garantieren, durch
Redundanzen eine höhere Ausfallssicherheit bieten und verschiedene Sicherheitsaspekte
umsetzen. Ein Peer ist jedoch nicht an eine bestimmte Gruppe gebunden. Die
Kommunikation der Peers und Peer Groups erfolgt über spezielle strukturierte
Nachrichten, die mittels Pipes unidirektional oder bidirektional übertragen werden. [Gong
2002]
Für diese Arbeit ist jedoch das verteilte Suchkonzept von JXTA von besonderem
Interesse. JXTA Search entstand im Jahre 2000 aus dem InfraSearch-Projekt, das mittels
Web-Clients den Zugriff auf eine Menge an verteilten Servern unter Verwendung des
Gnutella Protokolls ermöglichte. Die Idee des InfraSearch-Projektes, Suchanfragen an
verschiede Networkpeers zu verteilen, wurde dabei übernommen. JXTA Search
unterscheidet sich gänzlich von herkömmlichen Web-Crawler oder Meta-Suchmaschinen.
Es werden keine Indizes von statischen Seiten generiert, sondern die Suchanfragen in
Echtzeit abgearbeitet. Daraus ergibt sich der Vorteil, keine Dead-Links oder veraltete
Informationen zu erhalten. Der Einsatz von JXTA Search eignet sich besonders gut bei
sich stark ändernden Inhalten oder bei dynamischen Inhalten. Weiters ist es möglich,
mittels JXTA Search Informationsbereiche thematisch zu kapseln, um die Effizienz der
Suche steigern zu können. Nachdem als Austauschformat XML Protokolle zum Einsatz
kommen die das MIME-Format unterstützen, können auch beliebige Datentypen wie z.B.
Text, Bilder oder Audio übertragen werden. [Waterhouse 2001]
Mit JXTA Search ist sowohl eine Tiefensuche, als auch eine Breitensuche möglich.
Bei der Breitensuche wird eine Suchanfrage an möglichst viele Peers weitergeleitet. Peers
sind in Gruppen organisiert, die thematisch, geographisch, content spezifisch oder
applikations-spezifisch orientiert ihre Dienste anbieten beziehungsweise Suchanfragen
bearbeiten. Kann eine Suchanfrage nicht verarbeitet werden, wird diese an eine weitere
Peer-Gruppe weitergeleitet. Bei der Tiefensuche werden hingegen die Technologien von
herkömmlichen Web-Crawler Diensten oder Datenbank Diensten eingesetzt. Eine
Suchanfrage wird entsprechend aufbereitet und kann an diverse Dienste weitergeleitet
werden. Diese Dienste müssen jedoch im JXTA Netzwerk registriert sein. Weiters
werden die Ergebnisse gesammelt und an den Initiator der Suchanfrage zurückgesandt.
Die Vorteile daraus sind ein größerer Neuigkeitsgehalt der Resultate, der Zugriff auf
nicht statische Inhalte in Datenbanken und eine höhere Effizienz durch strukturierte
Seite 103
Request- und Response-Messages. Die Visualisierung der strukturierten Ergebnismenge
wird vom Client erzeugt. [Waterhouse 2001]
Die JXTA Search Architektur basiert auf dem JXTA Framework. In Abbildung 6.3 ist
die Architektur von JXTA Search grafisch dargestellt. Es wird dabei zwischen folgenden
Diensten unterschieden: [Waterhouse 2001]
• Consumer-Service: sendet Suchanfragen an das Netzwerk (Hub, Provider)
• Provider-Service: rufen entsprechende Interfaces der eigentlichen Provider auf und
verarbeitet Suchanfragen. Es werden nur die Antworten generiert und keine Indizes.
• Registrier-Service: speichert Registrierdaten der Provider und sendet diese an die
Hubs.
• Hub-Service: leitet eine Suchanfrage entsprechend an die verschiedenen Provider
weiter. Ein Router verwaltet Suchanfragen, leitet diese weiter an andere Hubs/Router,
vergleicht die Ergebnisse und leitet diese an die Consumer weiter.
• Resolver: löst Suchanfragen auf, vergleicht diese mit den Registrierdaten der Provider,
verteilt entsprechend die Suchanfrage.
Um eine verteilte Suche effizient gewährleisten zu können, sollen Hubs, wie bereits
erwähnt, Informationsbereiche kapseln bzw. trennen, indem Peer Groups gleichen
Inhaltbereiches über Hubs miteinander verbunden werden. In JXTA ist jedoch nicht
spezifiziert wie Hubs miteinander verbunden werden, um z.B. multible Hubs erzeugen zu
können. Jedoch spielt die Query Lifetime eine entscheidende Rolle, um zu gültigen
Resultaten zu kommen. Die Zuordnung der Dienste zu Hubs geschieht aus der Analyse
der Registrierdaten der verschiedenen Provider. In Abbildung 6.4 ist ein einfaches Modell
für eine verteilte JXTA Suche skizziert. [Waterhouse 2001]
Abbildung 6.3: Netzwerk Architektur von JXTA Search [Waterhouse 2001]
Seite 104
Abbildung 6.4: Verteilte Suche in JXTA Search [Waterhouse 2001]
Die Suchanfrage selbst ist strukturiert aufgebaut, an eine bestimmte (erweiterbare)
XML Notation gehalten und muss zumindest zwei Bedingungen erfüllen, die in den
Registrierdaten abgelegt sind: [Waterhouse 2001]
• Queryspaces sind eindeutige Bezeichner für eine abstrakte Menge möglicher
Resultate. Ähnlich zu einem XML-Namespace kapseln JXTA Queryspaces
Informationsbereiche ab. Die Trennung wird erreicht durch eine spezielle
Datenstruktur und einer eigenen Datensemantik. Die Datenstruktur wird über eine
DTD oder ein XML Schema definiert. Die Datensemantik gibt Auskunft über die Art
der Daten. Weiters ist in einem Queryspace festgelegt, wie Resultate in einem
„Ranking“ verwendet werden können.
• Query Predicates sind ein Satz von Boolschen Ausdrücken, die Query-Node-Patterns
miteinander kombinieren Query-Node-Patterns sind XML Fragmente die den Typ, das
Format, und eine Beschreibung festlegen. Dieser Satz an Prädikaten wird vom
Registrierservice indiziert und zur Analyse der Suchanfragen herangezogen.
Durch die Analyse der Registrierdaten erfolgt dynamisch eine Ähnlichkeitserkennung
von Providern. Diese Daten werden in einer Ähnlichkeitsmatrix des Resolvers
gespeichert. Suchanfragen werden von Routern an die Resolver weitergeleitet. Anhand
der Ähnlichkeitsmatrix versuchen Resolver Routeranfragen einer Menge „ähnlicher“
Provider ID’s zu zuordnen. Die Router verbinden nun die Suchanfrage mit jedem Eintrag
der vom Resolver generierten Provider Menge. Dabei wenden die Router einen
Seite 105
exponentiellen „Back-Off“ Algorithmus an, um einerseits schlechte oder „tote“
Verbindungen umgehen zu können und um andererseits das Spamming105 möglichst klein
halten zu können. Wenn ein Provider die geforderten Timeout-Kriterien nicht erfüllt,
werden die Resolver von den jeweiligen Routern benachrichtigt. Diese Provider werden
bei einer nächsten Anfrage an den Resolver nicht mehr berücksichtigt. Durch all diese
Maßnahmen kann effizient nach Informationen und Daten gesucht werden. [Waterhouse
2001]
6.4.
Harvest
Das Harvest-Suchsystem ist eine Architektur zur Sammlung und zur
Verfügungstellung von verteilten Daten über ein Webinterface. Insbesondere wurde auf
einen modularen Aufbau der Einzelkomponenten der Harvest-Architektur Wert gelegt.
Dieser modulare Aufbau ermöglicht neben der flexiblen Anwendung der Sucharchitektur
auch eine bessere Erweiterbarkeit und Wartbarkeit der Module. Die beiden Hauptmodule
von Harvest sind die Gatherer zur Datenbeschaffung und die Broker, die Suchanfragen
beantworten. Mehrere Gatherer können zur gleichen Zeit verschiedene Datenquellen
abfragen und geeignete Informationen sammeln. Broker kommunizieren mit Gatherer und
stellen so die Verbindung der Suchanfrage zu den Datenquellen her. Als
Informationsquellen kommen Daten in Frage, die über HTTP, FTP, NNT, dem lokalen
Dateisystem, CD-Dateisystem oder über File-Server erreichbar sind. [Bowman et al.
1995]
Die Hauptaufgabe eines Gatherer ist die Extraktion indizierbarer Informationen der
gesammelten Daten. Diese Extraktion wird in einem speziellen SOIF106-Format den
Brokern zur Verfügung gestellt. Der Gatherer kann einerseits direkt am Hostrechner, oder
andererseits auch auf Remote-Rechnern laufen, um mehrere Datenquellen untersuchen zu
können. Durch die lokale Installation wird eine größere Effizienz bei der
Datenbeschaffung durch den direkten Zugriff auf das lokale Filesystem erreicht. Das
Gathern der Daten geschieht periodisch zu konfigurierbaren Harvesting-Zeiten. Beim
Gathern wird für jede Datenquelle ein SOIF-Objekt erzeugt. [Hardy et al. 2002]
Die Aufgaben des Brokers sind das Indizieren der Daten in Form von SOIF-Objekten,
das Filtern von Informationen bzw. das Weiterleiten von Informationen an andere Broker
und das Anbieten eines entsprechenden Suchinterfaces für den Benutzer. Die Zuordnung
von Broker zu Gatherer wird in einem Konfigurationsfile festgelegt. Broker befragen
Gatherer in regelmäßigen Abständen nach Änderungen oder Neuerungen der
gesammelten Informationen ab. Die SOIF-Objekte werden wie bereits erwähnt vom
Broker indiziert und verwaltet. Zum Indizieren der Seif-Objekte werden externe
Werkzeuge wie Glimpse107, Swish108 oder Zebra109 eingesetzt. [Hardy et al. 2002]
Durch das strukturierte Zusammenschalten dieser beiden Module, ist ein effizientes
Auffinden bzw. Aufbereiten der Daten möglich. Broker können z.B. Informationen von
mehreren Gatherer beziehen. Broker können Informationen lediglich auch untereinander
austauschen. Abbildung 6.5 zeigt eine mögliche Harvest-Struktur, in der ein Benutzer
105
Als Spamming bei einer Suche bezeichnet man falsche Angaben bei der Registrierung in diversen Suchmaschinen.
SOIF: Das Harvest Summary Object Interchange Format besteht aus Attribut-Wert Paaren, die aus dem Textinhalt
der Daten extrahiert werden.
107
Glimpse: http://webglimpse.org/
108
Swish: http://swish-e.org/
109
Zebra: http://www.indexdata.dk/zebra/
106
Seite 106
implizit über einen Broker strukturiert Zugriff auf die Daten von Websites erhält. Die
hierarchische Aufgliederung von Brokern und Gatherer sieht neben hierarchisch
organisierten Cache-Mechanismen (Reduktion von Netz- und Serverbelastung), auch
geeignete Replikationssysteme vor. Bei der Replikation werden die Brokerverzeichnisse
in zeitlich vorgegebenen Abständen miteinander abgeglichen und repliziert. [Bowman et
al. 1995]
Abbildung 6.5: Verteilte Architektur eines Harvest Suchsystems [Bowman et al. 1995]
6.5.
xFIND
xFIND steht für Extended Framework for Information Discovery und wird in erster
Linie zur modernen Wissensauffindung in verteilten Umgebungen eingesetzt.
Problembereiche gängiger Suchdienste sind z.B. die hohe Netzwerklast durch Spider
bzw. Web Crawler oder die Verwaltung einer zentralen Indexdatenbank. Diese
Problembereiche zu verbessern, war die ursprüngliche Motivation zur Entwicklung eines
offenen und verteilten Konzeptansatzes. Dieses Konzept baut in den grundlegenden
Elementen auf Ansätze aus Harvest (siehe Abschnitt 6.4) auf. xFIND ist aufgrund des
Einsatzes von Java (das UI ist in Perl bzw. PHP umgesetzt) plattformunabhängig. Der
modulare Aufbau erlaubt eine einfache Erweiterbarkeit der Funktionseinheiten, das
Austauschen diverser Funktionseinheiten, die Anbindung an existierende Fremdsysteme
und die Integration von xFIND in andere Informationsplattformen. Ein weiteres Ziel bei
der Entwicklung von xFIND war eine Erhöhung der Trefferrelevanz. Die Erhöhung der
Trefferrelevanz wird erreicht durch eine bessere Unterstützung der Benutzer bei der
Suche durch die Miteinbeziehung personalisierter Daten. Durch die Bewertung der
Suchergebnisse mit Qualitätsaspekten oder Merkmalen wie z.B. die Zuverlässigkeit einer
Informationsquelle wird die Ergebnismenge eingeschränkt und eine Verbesserung der
Treffergenauigkeit erzielt. Insbesondere letztere Merkmale garantieren einen
zuverlässigen und vertrauenswürdigen Informationsaustausch. [Gütl 2002] [Hoffmann
2002] [Aichriedler et al. 2000]
Die xFIND Architektur setzt sich im Wesentlichen zusammen aus Gatherer, Indexer
und Broker. Um die Übertragung der Daten zwischen den Modulen möglichst effizient
betreiben zu können, wird ein eigens entwickeltes Übertragungs-Protokoll und
Datenaustauschformat xQCF (xFIND Query Communication Format) eingesetzt. In
Abbildung 6.6 ist die verteilte hierarchische Architektur des xFIND Suchsystems grafisch
dargestellt. In dieser Abbildung wird insbesondere die flexible Konfiguration der
einzelnen Funktionseinheiten hervorgehoben. Gatherer können direkt (Local) oder
Remote auf die Datenbestände zugreifen. Indexer können ihre Informationen von
mehreren Gatherer beziehen. Broker nehmen Suchanfragen entgegen und greifen
ihrerseits wiederum auf die Daten verschiedener Indexer zu. Aufgrund dieser verteilten
Architektur ist eine Spezialisierung bzw. eine Kapselung von Informationsbereichen
möglich. [Gütl 2002]
Seite 107
Abbildung 6.6: Verteilte Architektur des xFIND Suchsystems [Gütl 2002]
Gatherer, wie in Abbildung 6.6 ersichtlich, gathern in konfigurierbaren Abständen
Daten von Webservern oder aus Filesystemen. Der Gather-Prozess an sich gleicht einer
Analyse des Informationsinhaltes. Dabei wird versucht, aus z.B. textuellen Inhalten,
verschiedene relevante Merkmale (Metainformationen) zu extrahieren. Durch die offenen
Schnittstellen des Gatherer können verschiedenste Filter zur Dokumentanalyse
herangezogen werden (Text, HTML, Bildformate, Audio, Video, PDF, Word, etc.). Bei
HTML Dokumenten werden z.B. spezielle Diskriminatoren (Tag-Names) angewandt, um
etwa die Bedeutung verschiedener Textstrukturen bewerten zu können. So werden etwa
der Titel, Schlüsselwörter, Hyperlinks, eingebettete Multimediaobjekte extrahiert und als
beschreibende Merkmale in einem eigenen Dokument zusammengefasst. Automatisiert
werden auch systemspezifische Metadaten wie z.B. Medientyp, Dateigröße, Erstellungsund Bearbeitungszeitpunkt generiert. Bei Bedarf werden zusätzlich allgemeine
Metadaten-Sets wie DC110 und DDC111 oder auch fachspezifische Metadaten-Sets, wie
ACM ACC112 oder LOM113, zur näheren qualitativen Beschreibung der Dokumente
herangezogen. Zur Themenklassifikation werden in xFIND DDC und ACM eingesetzt.
Statistische Auswertungen, wie die durchschnittliche Antwortzeit der Server oder die
Anzahl der Dokumente, können automatisiert erstellt werden. Der Einsatz spezieller
Bewertungsverfahren, wie automatische Spracherkennung oder Themenklassifikation,
liefern zusätzliche Informationen, um bei der Suche die Trefferquote verbessern zu
können. Der größte Vorteil dieser Extraktion bzw. der Dokumentbeschreibung anhand
standardisierter Metadaten ist die Reduktion der Netzwerklast bei der anschließenden
Weiterverarbeitung der Beschreibungs-Objekte. [Knögler 1999] [Gütl 2002] [Hoffmann
2002]
110
DC: Dublin Core
DDC: Dewey Decimal Classification
112
ACM ACC: Association for Computing Machinery Computing Classification System
113
LOM: Learning Object Metadata
111
Seite 108
Der Indexer selbst besitzt eine „dünne“ Adaptionsschicht, über der verschiedene
Indexer angebunden werden können. D.h. der Indexer muss selbst nicht unmittelbar
indizieren. Er kann sich über diese Adaptionsschicht fremder Indexersysteme bedienen,
oder aber auch Rohdaten verschiedener Datenbanken anbinden. Aus Sicht von xFIND gilt
der Indexer als Schnittstelle zwischen den Informationsbrokern und den Gatherer. Der
Indexer verarbeitet die von einem Gatherer zur Verfügung gestellten SOIF-Objekte,
indiziert diese und legt die indizierten Daten in einer Datenbank ab ( z.B. MySQL,
PostGres, Oracle). Es werden jedoch ausschließlich nur neue oder veränderte
Beschreibungs-Objekte im Index aktualisiert. Dies garantiert einen möglichst hohen
Neuigkeitsgehalt der Informationen. Zusätzlich zu den Beschreibungs-Objekten werden
noch spezielle Metadaten-Objekte im xFIND eigenen xQMS-Format gespeichert. Durch
die offenen Schnittstellen können verschiedene Indizier-Werkzeuge eingesetzt werden.
Der Indexer wertet die Suchanfragen im xQCF114 Format der Broker aus. Die xFIND
Suche unterstützt herkömmliche Such-Funktionen, wie Volltextsuche, Ähnlichkeitserkennung oder Schlüsselwortsuche. Zusätzlich kann aber auch nach den beschreibenden
Metainformationen gesucht bzw. die verschiedenen Suchen miteinander verknüpft
werden. Dem entsprechend werden bei der Darstellung der Suchergebnisse auch diese
zusätzlichen Metainformationen mit angezeigt. Der Indexer verfügt über
Replikationsmechanismen, um eine höhere Ausfallssicherheit gewährleisten zu können.
Caching Funktionalität steigert die Effizienz bei der Bearbeitung von Suchanfragen. Vom
Gatherer erzeugte „Fingerprints“ sichert die Eindeutigkeit und Echtheit der
Informationen. Ein Indexer kann auf einen bestimmten Themenbereich spezialisiert sein,
oder aber auch geographisch diversen Projektgruppen zugeordnet sein. Durch die
Datenbereitstellung der Gatherer ist auch ein Indizieren von lese-geschützten Daten
möglich. [Gütl 2002] [Hoffmann 2002] [Aichriedler et al. 2000]
Der Broker nimmt die Suchanfragen der Benutzer entgegen und leitet diese an einen
oder mehrere Indexer weiter. Die erhaltenen Resultate werden gesammelt, gecached,
entsprechend zur Ausgabe aufbereitet und zum Client zurückgeschickt. Nachdem der
Broker „seine“ Indexer kennt, ist auch eine Separation von Wissensbereichen möglich.
Die Suchanfragen der Clients werden vom Broker in das xQCF-Format umgesetzt und in
dieser Form als Anfrage an die Indexer weitergeleitet. Neben den Indexern können auch
externe Quellen, die über das xFIND-API an das System angeschlossen sind (z.B.
Altavista Indexer), abgefragt werden. Sind mehrere Indexer bei einer Anfrage
eingebunden, können Duplikate in Suchergebnissen ausgefiltert und ein Ranking der
Ergebnismenge durchgeführt werden. Über den Broker ist auch die Wartung der
Serverbereiche möglich. Neue Seiten können über die Broker angemeldet und die
Seitenbeschreibungen verändert und verwaltet werden. Eine Seitenbeschreibung wird
über ein Webinterface von xFIND Benutzern erfasst. Diese Seitenbeschreibung wird im
xQMS Format gespeichert und zur weiteren Begutachtung an verschiedene Experten
weitergeleitet. Diese hierarchisch gegliederte Begutachtung der Seitenbeschreibungen
führt zu qualitativen und zuverlässigen Zusatzinformationen. Ist eine Seitenbeschreibung
bzw. ein neuer Serverbereich zur Suche freigegeben, werden entsprechend die Indexer
und in weiterer Folge die Gatherer benachrichtigt. In der vorliegenden xFIND Version
müssen die Einträge für die Indexer und die Gatherer manuell konfiguriert werden. [Gütl
2002[Hoffmann 2002] [Aichriedler et al. 2000]
114
xQCF: xFIND Query Communication Format; Definition siehe Anhang Abschnitt 12
Seite 109
6.6.
Schlussbemerkung
Das Architekturkonzept des xFIND-Suchsystems sieht Module vor, die verteilt auf
verschiedenen Rechnern installiert werden können. Die Kommunikation erfolgt bisher
über einen recht einfachen Mechanismus. Der Kommunikationsaufbau und die
Informationsübertragung werden über Sockets realisiert. Das Datenaustauschformat
xQCF (xFIND Query Communication Format) ist ein xFIND-spezifisches Format und
nicht standardisiert. Es ist deshalb nur sehr schwer möglich, Ergebnisse anderer
Suchdienste einzubinden bzw. andere Dienste zu integrieren.
Weiters kann mit der xFIND Kommunikationsschnittstelle kein standardisierter Dienst
zur Verfügung gestellt werden, der etwa von anderen Applikationen genutzt werden
kann. Eine automatisierte Suche nach entsprechenden Diensten oder eigenen
Systemkomponenten ist im xFIND Architekturkonzept nicht vorgesehen. Im derzeitigen
Stand des xFIND-Suchsystems sind zudem keine Sicherheitsaspekte in der
Kommunikationsschicht bzw. in den verschiedenen Modulen integriert. Das xFINDSuchsystem ist zwar ein in mehrere Komponenten aufgeteiltes System, aber die
Koppelung bzw. die Verbindung der verschiedenen Systemteile ist jedoch strikt
vorgegeben. Diese starre Koppelung der xFIND-Module könnte mit den Ansätzen zur
automatisierten Auffindung diverser Dienste über P2P Modelle aufgelöst werden. Freenet
und FASD als selbstorganisierende P2P Netzwerke bieten dafür geeignete Methoden.
Durch die Ausnützung der Redundanzen in P2P Netzwerken kann z.B. die
Ausfallssicherheit einzelner Module erhöht werden.
JXTA bietet zudem die Möglichkeit Module thematisch in Gruppen zu organisieren.
Innerhalb dieser Gruppen können spezielle Sicherheitsaspekte umgesetzt werden.
Nachdem JXTA sowohl die Tiefensuche als auch die Breitensuche unterstützt, kann der
Zugriff auf Datenbankinhalte (Deep Web) geschützt erfolgen. Unter Berücksichtigung
von Quality-Of-Service Aspekten kann eine größere Durchsatzrate der verteilten Module
erzielt werden. Die Auswertung von Registrierdaten kann zur thematischen
Ähnlichkeitsbestimmung der Module herangezogen werden. Dadurch wäre eine
automatisierte themenspezifische Suche nach Informationsinhalten möglich. In Freenet
sind die Daten grundsätzlich verschlüsselt gespeichert. Das trifft für die
Informationsinhalte im WWW zum Großteil jedoch nicht zu. Das auf Freenet basierende
Suchsystem FASD setzt zudem Dokument-Vektoren zur Ähnlichkeitserkennung und
Auffindung der Informationsinhalte ein. Werden diese Dokument-Vektoren verschlüsselt
bzw. mit einem Fingerprint versehen, ist auch ein gesicherter Kommunikationsfluss
gewährleistet. Zudem bietet FASD den Vorteil, dass mit der Dokument-Vektoren
Methode eine Denial of Service Attacke bei der Suche nur sehr schwer möglich ist.
Die Gegenüberstellung von P2P Ansätzen und xFIND liefert eine Vielfalt an
möglichen Verbesserungen für die xFIND Kommunikationsschicht bzw. viele
Erweiterungen für die Architektur selbst. Ziel ist es jedoch im Gestaltungsteil dieser
Arbeit lediglich ausgewählte Übertragungsprotokolle zu überprüfen. Diese sollen einen
standardisierten, effizienten und sicheren Informationsaustausch bewerkstelligen können.
Zusätzlich werden Vorschläge erstellt, um weitere Verbesserungen in der
Kommunikationsschicht in zukünftigen Projekten einfach umsetzen zu können.
Seite 110
Seite 111
II Gestaltungsbereich
Seite 112
Seite 113
Kapitel 7
7.
xFIND Kommunikationsarchitektur
Im Laufe der Jahre entstand der Bedarf die Kommunikationseinheit von xFIND zu
erneuern, bzw. diese zu standardisieren. Zusätzlich soll die verteilte Verwaltung
zentralisiert und vereinfacht werden. Insbesondere Kapitel 5 und Kapitel 6 liefern
wichtige Erkenntnisse für die Erweiterung und Verbesserung der xFIND
Kommunikationsarchitektur. Die Ziele des Gestaltungsteiles ergeben sich so aus den
Problemfeldern und den Verbesserungspotentialen von xFIND. Um die Problemstellen
verbessern zu können, sollen vor allem Technologien zum Einsatz kommen, die einen
möglichst geringen Aufwand in der Umsetzung erfordern.
Um diesen Forderungen gerecht zu werden, wird im ersten Teil des Gestaltungsteiles
die xFIND Kommunikationsarchitektur eingehend analysiert. Mit Hilfe einer
Testimplementierung wird eine Simulation der xFIND Client-Server Kommunikation
durchgeführt. Die aus einem Benchmark Test gewonnen Kennwerte, sind als
Referenzdaten für weitere Analysen in verschiedenen Projekten anzusehen.
Aus dem Untersuchungsteil geht weiters hervor, dass insbesondere das
Datenübertragungsprotokoll BEEP und das Protokollframework JXTA am geeignetsten
erscheinen, um eine Verbesserung der Problembereiche in xFIND zu erzielen. Diverse
Testimplementierungen geben Aufschlüsse über den Einsatzbereich und die
Verwendbarkeit der verschiedenen Technologien. Den Abschluss des Gestaltungsteiles
bildet ein Überblick über die Realisierung der geforderten Ziele. Zusätzlich sind Ideen
und Verbesserungsvorschläge für künftige Projekte gesondert vermerkt.
7.1.
Einleitung
xFIND entstand als Teil eines durch das Österreichische Wissenschaftsministerium
geförderte Forschungsprojekt am IICM. xFIND und xFIND Module wurden
prototypenhaft in den Jahren 1997 bis 2000 entworfen. Seit mehr als vier Jahren wird nun
xFIND als Open Source Projekt von der Web Community unterstützt und
weiterentwickelt. Die generelle Architektur und Arbeitsweise von xFIND wurden bereits
eingehend im Untersuchungsteil in Abschnitt 6.3 beschrieben. Im Gestaltungsteil wird
nun näher auf die technischen Details eingegangen. Insbesondere wird versucht,
Problembereiche der xFIND Kommunikationsschicht eingehend zu analysieren.
Die Probleme die sich in der Entwicklung ergaben, führten zu einer Reihe von xFIND
spezifischen Neuentwicklungen. So gab es für die Konfiguration der verschiedenen
Module noch keine standardisierten Möglichkeiten. XML war zu dieser Zeit zwar schon
standardisiert, doch geeignete Parser boten in den Entwicklungsanfängen von xFIND nur
unzureichende Qualität. Auf ähnliche Probleme stieß man beim Entwurf der
Kommunikationsschicht. Standardisierte Protokolle für verteilte Umgebungen gab es
Seite 114
Kapitel 7 - xFIND Kommunikationsarchitektur
noch nicht, ebenso wenig wie geeignete Abfragesprachen. So wurde entsprechend viel
Ehrgeiz und Arbeit in die Entwicklung einer schlanken und performanten
Kommunikationsschicht gelegt.
Diese Kommunikationsschicht ist jedoch nach heutigem Stand nicht einfach
erweiterbar, birgt zudem Sicherheitslücken und unterstützt keine gültigen Standards. Um
einen Vergleich mit modernen standardisierten Übertragungs-Technologien erstellen zu
können, wurde zu Testzwecken eine eigenständige Client-Server Umgebung entwickelt,
in der die xFIND Kommunikations-Technologie integriert wurde. Die nun folgenden
Unterabschnitte beschreiben nun eingehend die technischen Aspekte der xFIND
Kommunikationsarchitektur und orientieren sich dabei an den Arbeiten von [Maurer et al.
2000] [Gütl 2002] [Knögler 1999] [Heber 2000] [xFIND 2003].
7.2.
xFIND Konfiguration
Die xFIND-Module werden über eine Reihe von Konfigurationsdateien verwaltet und
gesteuert. Die Syntax ist für alle Konfigurationsdateien einheitlich, jedoch xFIND
spezifisch. xFIND sieht dafür einen speziellen XFConfigReader vor. Verschiedene
Bereiche werden ähnlich zu XML in einer bestimmten Notation voneinander getrennt. So
sind auch verschachtelte Bereiche und Subbereiche erlaubt. Ebenso können Kommentare
in der Datei vermerkt werden. Zudem ist die Syntax recht einfach gehalten.
Der Beginn eines Bereiches wird mit [Sectionname] und das Ende eines Bereiches mit
[/Sectionname] vermerkt. Subbereiche müssen den jeweiligen Elternpfad als Präfix
angeführt haben [Sectionname.Subsection]. Unter anderem gibt es die Möglichkeit,
zusätzliche xFIND Konfigurationsdateien über ein spezielles Kommando zu inkludieren.
Dadurch können die Konfigurationsdateien schlanker und übersichtlicher gestaltet
werden.
Der XFConfigReader parst die Sections und liefert anhand von speziellen Methoden,
einen ganzen Bereich als Stringwert inklusive Subbereiche zurück. Mitunter kann man
einen Bereich auch Filtern. Dann werden alle Kommentare, Newlines und Subbereiche
für diesen Bereich ignoriert. Liegt eine spezielle Form der Einträge vor, kann automatisch
eine Hash-Table als Key-Value Map für einen Bereich angefordert werden.
Folgende Konfigurationsdateien werden in xFIND eingesetzt:
• xFIND.cfg: Konfiguration für den xFIND-Manager. Hier werden generelle Dinge
festgelegt wie das Logformat, Loglevel, welche Module loggen und die
Verbindungsparameter zwischen den Modulen.
• Gatherer.Config.cfg: Im Gatherer Konfig werden die globalen Gatherparameter
festgelegt. Dazu gehören die Pfadtiefe, maximale Anzahl an besuchten Hosts bzw.
Urls und die Urleinträge selbst. Diese können kategorisch nach der Häufigkeit ihrer
Aktualisierung zu verschiedenen Zeitpunkten abgesucht werden.
• Gatherer.Retriever.cfg: Definiert die Zugehörigkeit von Retriever-Typen zu ihren
jeweiligen Javaklassen (Factory). Weiters werden in dieser Konfigurationsdatei FileExtensions
MIME-Media
Typen
zugeordnet.
Zusätzlich
können
die
Verbindungsparameter zu einem Proxyserver festgelegt werden.
• Gatherer.Log.cfg: Einstellungen für das Logging äquivalent zu xFIND.cfg
eingeschränkt auf das xFIND Gatherer-Modul.
• Gatherer.Filter.cfg: Einstellungen für den Gatherer Filter wie Klassenname (Factory),
Spracherkennung, etc.
Seite 115
• Gatherer.Database.cfg: Einstellungen zur Anbindung des Gatherer an die Datenbank.
Name der Datenbank, Driver-Name, Driver-URL, DB-User, DB-Password, SQL
Quote Character und SQL Escape Character.
• Gatherer.Converter.cfg: Bildet die MIME Typen auf die verschiedenen
Converterklassen (Factory) ab. Legt spezielle Eigenschaften für verschiedene MIME
Typen fest (HTML-Tags, Image Abmessungen, etc.).
• Gatherer.Authorize.cfg: Legt Zugangsdaten für den Retriever fest. Hosteinträge, Ports,
Passwörter, etc.
• Gatherer.AllowDeny.cfg: Dieses Konfig File regelt die Zugangsrichtlinien für den
Retrieval Prozess. Anhand von Regulären Ausdrücken wird festgelegt welche
Protokolle, Dateien oder Hosts erlaubt sind oder ausgeschlossen werden.
• broker.cfg: Hier werden Logging Parameter äquivalent zu xFIND.cfg eingeschränkt
auf den xFIND Broker festgelegt. Weiters wird der Broker-Cache verwaltet und
zusätzlich werden die Broker-DB Verbindungsattribute vermerkt.
• manager.cfg: Die Konfiguration für den xFIND-Manager entspricht von den
Grundelementen denen von xFIND.cfg. Deshalb weist diese Datei redundante
Informationen auf. Jedoch sind in xFIND.cfg die meisten Bereiche auskommentiert.
Wesentlich ist hier, dass die DB-Verbindung des Indexer über dieses File konfiguriert
wird.
• XFLog.cfg: Generelle Einstellungen für Logging.
• XFAVFilterFactory.cfg: Spezielles Filter Mapping für abstrakte Filterklassen.
• XFAllowDeny.cfg: Zugangsrichtlinien für Urls, vergleichbar mit
Gatherer.AllowDeny.cfg.
7.3.
xFIND Kommunikation
Die Kommunikation zwischen den verschiedenen xFIND-Modulen wird über Java
TCP/IP Socket Verbindungen durchgeführt. Auf diesem TCP/IP Socket wird ein eigens
definiertes Transportprotokoll aufgesetzt. Dieses Protokoll wird sowohl bei lokalen als
auch externen Modul-Anbindungen eingesetzt. D.h. sind mehrere Module (xFINDGatherer, xFIND-Indexer und xFIND-Broker) auf einem Server integriert,
kommunizieren diese Module stets über dieses proprietäre Protokoll. Aufgrund der
Komplexität bei der Übertragung wurde auf den Entwurf eines eigenen lokalen Protokolls
verzichtet. Das so eingesetzte xFIND Kommunikations-Protokoll besteht aus fünf
verschiedenen Bereichen:
1. Server-Ticket: Wenn der Server eine Verbindung akzeptiert oder ablehnt, wird ein
entsprechendes Server-Ticket zur Authentifizierung vom Server generiert und an den
Client geschickt. Die Gültigkeitsdauer des Server-Tickets ist an die SocketVerbindung geknüpft. Das Server-Ticket beinhaltet Statusinformationen über die
Verbindung, eine Server-Message zur Identifikation des Servers, den „public-key“ des
Servers und ein String-Array, in dem weitere Server-Daten abgelegt sind.
Seite 116
2. Service-Request: Wird vom Client generiert, um verschiedene Module abfragen zu
können. Dieser spezielle Request beinhaltet wie das Server-Ticket
Statusinformationen über die Verbindung, den Namen des abzufragenden Moduls, ein
Authentikation-Ticket und in einem String-Array die Query-Argumente für das
jeweilige Modul. Über einen speziellen Request ist das Schließen einer Verbindung
ohne zusätzliche Parameter möglich.
3. Data-Header: Ein Data-Header wird vom Server an den Client aufgrund einer ClientAnfrage geschickt. Der Data-Header gibt Aufschluss, ob die Anfrage angenommen
oder abgelehnt wurde. In weiterer Folge werden über den Data-Header nur mehr
Statusinformationen ausgetauscht (granted, reject). Zusätzlich kann eine nicht näher
spezifizierte Nachricht im Header mitübertragen werden.
4. Data: Im Datenbereich werden Zeichen, Zahlen oder Strings übertragen. Eine
Datengruppierung erfolgt mit einem „End Of Block“ (EOB) Indikator. Wird ein EOBIndikator erkannt, beantwortet der jeweilige Dienst dies mit einer „ackEOB“ Message.
Im Fehlerfall wird eine I/O Exception erzeugt. Das Ende des Datenstromes wird mit
„End Of Data“ (EOD) markiert. Auch EOD muss entsprechend den Vorgaben mit
„ackEOD“ bestätigt werden.
5. Data-Footer: Der Data-Footer wird nach einer Datentransaktion vom Server zum
Client gesandt. Der Data-Footer beinhaltet wiederum Statusinformationen über die
Verbindung und eine Message. In der Statusinformation wird dem Client signalisiert,
ob die Socket-Verbindung geschlossen werden kann, oder noch für weitere
Transaktionen offen bleiben soll. Falls der Client einen Data-Header verschickt, muss
er auch entsprechend einen Data-Footer schicken.
Zu beachten ist, dass die Module nicht unbedingt antworten müssen bzw. Header oder
Footer Daten verschicken müssen. Wenn eine Verbindung geöffnet ist, können auch
weiterführende Sub-Verbindungen zu anderen Modulen aufgebaut werden. Wichtig dabei
ist, dass jeder Request komplett abgearbeitet werden muss. Verschachtelte oder
ineinander greifende Requests sind nicht erlaubt. Der Close-Request erzeugt lediglich
einen default-Header bzw. default-Footer und beendet die Verbindung.
Dem Client-Server Prinzip zu Folge lauscht jeweils ein Server pro Modul auf
eingehende Requests. Die Modul Clients versenden die Suchanfragen. Ein Server kann
maximal 255 (default-Wert) gleichzeitige Verbindungen halten. Wenn dieser
konfigurierbare Wert überschritten wird, lehnt der Server die Suchanfrage ab. Wird eine
Suchanfrage akzeptiert, antwortet, wie bereits erwähnt, der Server mit einem ServerTicket. Gleichzeitig wird ein „Worker-Thread“ erzeugt, der die erzeugte SocketVerbindung überwacht und auf Service-Requests wartet.
Der Initiator Client wartet auf die Serverantwort (Server-Ticket) und überprüft diese
nach dem Eintreffen. Im Falle einer Ablehnung durch den Server wird der entsprechende
Client-Prozess beendet. Ansonsten versucht nun der Client anhand von Service-Requests,
Daten vom Server anzufordern. Zur Vereinfachung des doch komplexen
Verbindungsaufbaues, bzw. der Datenübertragung, zeigt Abbildung 7.1 eine bildliche
Darstellung der Client-Server Kommunikation in einem Datenflussdiagramm.
Seite 117
Abbildung 7.1: Datenfluss der xFIND Kommunikation zwischen Client und Server [xFIND 2003]
Jedes Modul in xFIND muss eigens einen Client und Server starten, um miteinander
kommunizieren zu können. So startet z.B. der Gatherer über die Klasse
XFGathererCommunication den Gatherer-Server, um Requests vom xFIND IndexerClient entgegen nehmen zu können. Der xFIND Indexer startet hingegen mit der Klasse
Seite 118
die Kommunikationsschnittstelle am Indexer. Der Indexer
schickt eine Such-Anfrage im QCF-Format an den Gatherer. Der Gatherer extrahiert
resultierend der Suchanfrage die entsprechenden Daten aus seiner internen Datenbank.
Der XFGathererMaster stellt die zentrale Schaltstelle zwischen der Datenbank und der
Kommunikationseinheit dar. Der XFGathererMaster initialisiert alle notwendigen
Bereiche und stellt die Datenbankverbindung dem XFGathererCommunication zur
Verfügung.
XFIndexGathererClient
Die Module selbst (Indexer und Gatherer) können auch „remote“ über den globalen
gestartet und miteinander verknüpft werden. Die verschiedenen notwendigen
Parameter wie z.B. Portadressen, Host- bez. Server-Namen sind konfigurierbar
ausgeführt.
Der
Datenaustausch
zwischen
der
Datenbank
und
dem
XFGathererCommunication erfolgt über das XFDBObject. Die Datenobjekte werden nach
Indexer Anfragen, von der Gatherer Kommunikationseinheit in das QCF-Format
transformiert und an den Indexer-Client zurückgesandt. Um den Kommunikationsfluss
einfacher beschreiben zu können, sind in Abbildung 7.2 alle beteiligten Komponenten in
einer Blockdarstellung zusammengefasst.
XFManager
Internet
Database
XFIndexer
XFManager
XFGathererMaster
XFGathererCommunication
XFDatabase
XFDBObjectEnumerator
XFDBObject
Abbildung 7.2: Blockdarstellung der xFIND Indexer-Gatherer Kommunikation [xFIND 2003]
Die Kommunikation zwischen xFIND Broker und xFIND Indexer erfolgt auf ähnliche
Weise. Der Broker startet einen Client über die Klasse XFIndexerQuery. Auf der Indexer
Seite wird der entsprechende Server über die Klasse XFIndexerSearchQueryComm
erzeugt. Da bei dieser Kommunikation keine zusätzlichen Transformationen stattfinden
besteht der Datenaustausch hauptsächlich aus verschiedenen QCF Datenpaketen. Im
Gegensatz zur Kommunikation zwischen Indexer und Gatherer, werden bei der
Kommunikation zwischen Broker und Indexer mehrere Header- und Footer- Blocks
sowie Result-Objekte ausgetauscht. Zusätzlich zu den Suchresultaten werden noch
Statusinformationen und Indexer-Informationen als Resultat übertragen. In Abbildung 7.3
sind die beteiligten Komponenten bei einer Suchanfrage vom Broker an einen Indexer
schematisch dargestellt. Die eigentliche Kommunikation ist in dieser Darstellung als
einfache Verbindung zwischen Broker und Searcher skizziert. Der Searcher hat in einem
Anfrageprozess mehrere Aufgaben zu bewältigen. Die QCF-Suchanfrage wird von einer
Postfix-Notation in eine Infixnotation umgewandelt. Damit kann einfacher in der Indexer
Datenbank gesucht werden. Zusätzlich bildet der Searcher die Suchanfrage auch für die
„Site-Description Registry“ auf. In dieser Registry werden beschreibende xQMS115
Metadaten für Indexereinträge vermerkt. Nähere Informationen zu den xQMS Elementen
können im Anhang B in Kapitel 13 nachgelesen werden.
115
xQMS: xFIND Quality Metadata Scheme beschreibt ein xFIND eigenes Klassifikationsschema, dass sich an DDC
(Dewey Decimal Classification code) und LOM (Learning Object Metadata) orientiert bzw. diese unterstützt.
Seite 119
Abbildung 7.3: Blockdarstellung einer Broker-Indexer Suchanfrage [xFIND 2003]
7.4.
xFIND Datenübertragung
Wie im vorigen Unterabschnitt bereits erwähnt, wird die Kommunikation zwischen
xFIND-Modulen über Java TCP/IP Socket Verbindungen realisiert. Die
Datenübertragung über diese Sockets basiert auf dem eigens für xFIND definierten QCFFormat. QCF steht für Query Communication Format. QCF ist vom Prinzip her ein
einfaches Format, dass lediglich einfache Key/Value Paare abbildet. Ein QCF-Key ist
eindeutig und kann aus einem oder mehreren Teilbereichen gebildet werden. Die QCFKeys sind hierarchisch aufgebaut. Die Abstraktion bzw. Verallgemeinerung erfolgt von
rechts nach links (umgekehrt zum DNS Prinzip). Im textbasierten QCF-Format erfolgt die
hierarchische Gliederung oder Abstraktion anhand des Trennzeichens ‚.’.
In QCF sind 14 Basis-Bereiche definiert:
1. VERSION – Section: spezifiziert die Versionsdaten der xFIND Versionierung
2. AUTH – Section: beinhaltet benutzerrelevante Informationen. Kann zur
Authentifikation herangezogen werden
3. ERROR – Section: beinhaltet diverse Fehlermeldungen und Fehlerbeschreibungen
4. GATHERER – Section: definiert alle für den Gatherer relevanten Keys zur
Kommunikation
5. OBJECT – Section: Basis Keys zur Beschreibung aller vorhandenen xFIND-Objekte
6. COMPARATOR – Section: definiert die Vergleich-Keys
7. MARK – Section: dient zur internen Verwendung, zum Erkennen von Klammern
8. OPERATOR – Section: Basis Operatoren (AND, OR, …) und spezielle Operatoren für
interne Bereiche
9. QUERY – Section: beinhaltet eine Suchanfrage, wird stets auch bei der Kommunikation
zwischen xFIND-Modulen verwendet
10. RESULT – Section: Antwort auf eine Suchanfrage
11. SITE-DESCRIPTION – Section: beinhaltet die Metadaten einer Web-Site
12. STATISTIC – Section: beinhaltet statistische Daten
13. URL – Section: definiert verschiedene Bereiche einer URL
14. WARNING – Section: beinhaltet Warnhinweise für die Kommunikationsteilnehmer
Kommentare können mit „#“ vermerkt werden. Es gibt spezielle Platzhalter für Zahlen
und Zeichenketten in diversen Formaten. Eine Query muss in einer speziellen Syntax
verfasst sein. Die QCF-Syntax ist im Anhang A Kapitel 12 (QCF-Spezifikation) näher
Seite 120
beschrieben. Bei der Definition der Query können zusätzlich spezielle optionale
Parameter deklariert werden.
Eine xFIND-Query besteht aus drei Teilbereichen:
1. Query: enthält die Suchanfrage bestehend aus Key/Value Paaren und Verknüpfungsoperatoren
2. Query-Attribute: optionale Randbedingungen wiederum als Key/Value Paare (default
config)
3. Return-Attribute: Keys, die bei der Suche erwartet werden; Key/Value Paare mit
leeren Values
Eine xFIND Antwort besteht ebenfalls aus drei Teilbereichen:
1. Statistics: statistische Informationen über die Suche in Key/Value Paaren
2. Resultat: Alle in der Query geforderten Attribute werden, falls vorhanden bzw.
gefunden, mit Werten belegt
3. Resultat-Footer: Status Informationen, Warnmeldungen, Fehlermeldungen ebenfalls
als Key/Value Paare
7.5.
Beschreibung der xFIND QCF-Datenpakete
In Abschnitt 7.3 wurden bereits die fünf verschiedenen Bereiche in der
Kommunikationsschicht kurz erwähnt. Um die Requests von xFIND mit anderen
Übertragungsmechanismen vergleichen zu können, bedarf es einer nähren Aufstellung
der jeweiligen Datenpaketgröße. Grundsätzlich muss erwähnt werden, dass die QCF
Datenpakete als String serialisiert werden. Diese Strings werden zusätzlich UTF-8 codiert
übertragen. Ein UTF-8 String in Java wird mit zwei führenden bytes gekennzeichnet.
Diese beiden bytes geben die Contentlänge des UTF-8 Strings an. Daraus ergibt sich eine
maximale Contentlänge von 16 kB für einen UTF-8 String. Die Methodik des Schreibens
sieht jedoch vor, Strings zu zerteilen und nacheinander als Stream zu übertragen. Nach
jedem UTF-8 String kennzeichnet ein byte, ob ein String komplett übertragen wurde,
oder ob noch weitere String-Teile folgen.
Ein Server-Ticket besteht aus mindestens 14 bytes:
Head
‚Tick’
4 byte
Status Flags
int
4 byte
Message
String
3-X bytes
Public Key
String
3-X bytes
Arguments
String Array
0-X bytes
Tabelle 7.1: Datenpaket des xFIND Server-Ticket
Ein Service-Request besteht aus mindestens 25 bytes:
Head
‚ReqS’
4 byte
Status Flags
int
4 byte
Service Name
String
3-X bytes
Arguments
String Array
0-X bytes
Tabelle 7.2: Datenpaket des xFIND Service-Requests
Server-Ticket
XFTicket
14-X bytes
Seite 121
Ein Data-Header besteht aus mindestens 11 bytes:
Head
‚Head’
4 byte
Status Flags
int
4 byte
Message
String
3-X bytes
Tabelle 7.3: Datenpaket des xFIND Data-Header
Ein Data-Footer besteht aus mindestens 11 bytes:
Head
‚Foot’
4 byte
Status Flags
int
4 byte
Message
String
3-X bytes
Tabelle 7.4: Datenpaket des xFIND Data-Footer
Ein Request Datenpaket ist abhängig vom jeweiligen Datentyp. Ein Request selbst
wird in der zuvor beschriebenen QCF-Syntax erstellt. Auf einen Socket serialisiert
werden vier Basis-Datentypen: Byte, Int, Long und String. Will man komplexere Objekte
mit der xFIND Kommunikationsschicht übertragen, müssen diese auf die vier
vorliegenden Basis-Datentypen abgebildet werden. So können mit dieser Methode auch
binäre Daten (der Gatherer verarbeitet binäre Daten, wie z.B. Images zur Generierung
von Thumbnails) recht einfach übertragen werden.
7.6.
Testimplementierung – Client-Server Simulation
Um einen Vergleich der gegenwärtigen xFIND Übertragungstechnologie mit anderen
standardisierten Technologien herstellen zu können, bedarf es gleichartiger bzw.
vergleichbarer Testumgebungen und Testimplementierungen. Zur Erstellung eines
anschließenden Benchmark Tests, wurde die xFIND Kommunikationsschicht erweitert
und angepasst. Für den Simulationsaufbau (einfache Client-Server Umgebung) wurden
einige xFIND Systemklassen aus dem xFIND Source extrahiert. Die Erweiterungen und
die dafür notwendigen Klassen wurden in einem eigenen Package comm_test
zusammengefasst.
Als Basis für die Testumgebung dient der aktuellste Stand von xFIND 0.96b aus dem
xFIND-CVS Source Repository. Nachdem, ab der Java-Version 1.3, z.B. standardmäßig
auch Reguläre Ausdrücke im Java-Core enthalten sind, gab es auch unabhängig vom
Release-Wechsel Änderungen im xFIND Source.
Das benannte comm_test Package beinhaltet folgende drei Dateien:
•
•
•
XFTestManager.java:
Gilt als Provider für die Socketverbindungen zwischen Client
und Server. Der Manager erzeugt implizit den Server-Socket, nimmt alle Requests
entgegen und leitet sie entsprechend ihrer Abstraktion an den entsprechenden Server
weiter.
XFTestServer.java: Der xFIND-Server erhält bei der Initialisierung durch den
Manager die entsprechende Socket-Verbindung zum Client und den Client AnfrageRequest.
XFTestClient.java: Fordert vom XFTestManager eine xFIND-Socket Verbindung
an und initialisiert die Kommunikation mit dem XFTestServer.
Seite 122
XFTestManager
XFTestClient
XFTestServer
Abbildung 7.4: Blockdiagramm der xFIND Client-Server Simulation
In Abbildung 7.4 ist der grundsätzliche strukturelle Aufbau der Testimplementierung
ersichtlich. Die Klasse XFTestClient wird mit der Hostadresse und der Portnummer des
XFTestManager initialisiert. Um eine Verbindung mit dem herstellen zu können, fordert der
XFTestClient vom xFIND Service Request Dienst eine neue xFIND Socketverbindung zum
XFTestServer an. Um die Datengröße für den Simulationsaufbau steuern zu können, wird
zusätzlich zu den xFIND spezifischen Request Parametern, noch die zu erwartenden Contentlänge
übergeben (dazu mehr im Abschnitt 7.7). Der XFTestServer implementiert das
XFRequestHandlerIfc und wird über den xFIND Service Request Dienst initialisiert. Eine
spezielle Methode erzeugt willkürliche Character-Streams mit der vom Client geforderten Länge.
Der Server sendet zur Initialisierung den Header, die Daten und den Footer. Um einen erneuten
Kommunikationshandshake zu vermeiden, wird das KeepAlive Flag gesetzt.
7.7.
xFIND Benchmark Tests
Um einen automatisierten Testablauf für einen Benchmarktest bewerkstelligen zu
können, wurde im Package edu.iicm.xfind.common.comm.XFServiceRequest die
Klasse XFServiceRequest.java um einige Methoden erweitert. Der automatisierte
Testablauf wird vom Client aus gesteuert. Der Client initialisiert zu Beginn die
Socketverbindung und fordert vom Server mit einem entsprechend angepasstem Ticket
wiederholt Datenpakte einer bestimmten Größe an. Die Größe des Datenpaktes wird
hiebei beim Anfrage-Request an den Server als Initialisierungswert mit angegeben.
Beim automatisierten Testablauf werden im Client zwei verschachtelte Schleifen
abgearbeitet. Die erste (äußere) Schleife, legt die zu übertragene Datenmenge fest. Die
Größe dieser Datenmenge ist der Initialwert für den Server. Am Server werden die
Datenpakete von einer speziellen Funktion generiert. Als Datenpakete werden
willkürliche Zeichenfolgen (Strings) mit der Länge des Initialwertes erzeugt. Um einen
guten Überblick über die Leistungsfähigkeit der Kommunikationsschicht zu erhalten,
steigert der Client die Datenanforderung in logarithmischen Schritten; 1kB – 5MB.
Die zweite (innere) Schleife iteriert zehn Mal. D.h. ein Datenpaket einer bestimmten
Größe wird zehn Mal in Folge vom Server angefordert und übertragen. Damit wird eine
Homogenisierung der Messwerte erreicht, bzw. Messtoleranzen und Störgeinflüsse
werden verringert. Die so erhaltenen Werte werden pro Datenmengeneinheit gemittelt
und in einer Tabelle vermerkt. Da die xFIND-Komponenten sowohl lokal, als auch in
verteilten Umgebungen über denselben Mechanismus miteinander kommunizieren,
wurden die Benchmark Tests auf drei verschieden Rechner-Umgebungen durchgeführt.
Der erste Architektur-Aufbau setzt eine einfache lokale Verbindung zwischen Client
und Server voraus. Die nun folgende Beschreibung der drei verschiedenen
Testarchitekturen gilt für alle durchgeführten Benchmark Tests im Gestaltungsteil. In
weiterer Folge wird auf diese drei Rechnerarchitekturen referenziert (PC1, PC2, PC3).
Seite 123
Die Kennwerte der ersten Testumgebung sind (PC1):
•
•
•
•
Prozessor: AMD Athlon(TM), XP 2400+ 2.00GHz
Speicher: 256MB Ram
Betriebssystem: Win XP-Home SP2
Java-Version: java version "1.4.2_04"; Java(TM) 2 Runtime Environment, Standard
Edition (build 1.4.2_04-b05); Java HotSpot(TM) Client VM (build 1.4.2_04-b05,
mixed mode)
Die zweite Architektur setzt ebenfalls eine einfache lokale Verbindung zwischen Client
und Server voraus. Die Kennwerte der zweiten Testumgebung sind (PC2):
•
•
•
•
Prozessor: Intel Pentium(3) 866MHz
Speicher: 768MB Ram
Betriebssystem: Win 2000 Server SP4
mixed mode)
Im dritten Aufbau wurden der Client und der Server auf zwei verschiedenen Rechnern
installiert. Die Clients laufen stets auf PC2 und die Server auf der dritten Testumgebung
(PC3). Die Kennwerte von PC 3 sind:
•
•
•
•
Prozessor: Intel Pentium(3) 733MHz
Speicher: 512MB Ram
Betriebssystem: Win 2000 Profesional SP3
mixed mode)
localhost PC2
Remote
Client PC2
Server PC3
Profiler PC1
Size
localhost PC1
bytes
ms
ms
ms
ms
1k
5
11
299
14
2k
8
11
300
16
5k
6
12
301
22
10k
8
14
301
28
20k
16
29
316
50
50k
50
96
595
106
100k
116
213
703
189
200k
247
364
996
333
500k
477
809
1644
567
1M
789
1438
2505
909
2M
1359
2791
4231
1564
5M
3581
7929
11115
4195
Tabelle 7.5: Benchmark-Test Übertragungszeit xFIND Kommunikationsschicht
Seite 124
Bis zu einer Datengröße von ca. 10kB sind alle Werte annähernd gleich. D.h. ein
UTF-8 codierter String kann in voller Länge übertragen werden. Ab einer Datengröße
von ca. 20kB steigt der Wert kontinuierlich an. Da, wie bereits in Abschnitt 7.5 erwähnt,
die UTF-8 Datenpakete (Testfall) maximal 16kB groß sein können, müssen diese in
mehrere
Pakete
zerteilt
werden.
Dies
erfordert
einen
zusätzlichen
Kommunikationsaufwand. Sowohl bei der Umgebung PC1 als auch bei der Umgebung
PC2 kann man in der Tabelle 7.5 ablesen, dass der Zeitbedarf bis zu einer Datengröße
von 2MB annähernd linear verläuft.
Gut zu erkennen ist die annähernd lineare Übertragungszeit in Abbildung 7.5 und
Abbildung 7.6. Aufgrund der Zerteilung großer Datenmengen in kleine Pakete, ist die
Steigung nicht konstant. Kommen, wie bei der Kennlinie „remote PC2-PC3“,
Netzwerkparameter als Randbedingung hinzu, ist der lineare Verlauf nur phasenweise
gegeben. Ab einer Datengröße von ca. 1MB wird die Steigung jedoch erheblich größer
und es ist so kein linearer Verlauf bei großen Datenmengen zu erwarten.
Benchmark Test: xFIND Kommunikation: 1K - 200K
localhost PC2
localhost PC1
remote PC2-PC3
Profiler PC1
1200
1000
Zeit in ms
800
600
400
200
0
1k
2k
5k
10k
20k
50k
100k
200k
übertragene Bytes
Abbildung 7.5: Kennlinien für Benchmark-Test xFIND Client-Server 1kB-200kB
Benchmark Test: xFIND Kommunikation: 200K - 5M
localhost PC2
localhost PC1
remote PC2-PC3
Profiler PC1
12000
10000
Zeit in ms
8000
6000
4000
2000
0
200k
500k
1M
2M
5M
übertragene Bytes
Abbildung 7.6: Kennlinien für Benchmark-Test xFIND Client-Server 200kB-5MB
In Tabelle 7.5 ist eine spezielle Spalte „Profiler“ vermerkt. Diese ist ebenfalls in den
Kennlinien laut Abbildung 7.5 und Abbildung 7.6 visualisiert. Die Profiler Spalte wurde
lediglich zu informativen Zwecken bei einer Profiling-Analyse aufgezeichnet. Anhand
der Kennlinie soll gezeigt werden, dass das Profiling keinen wesentlichen Einfluss auf die
Seite 125
Messwerte bzw. auf die Messumgebung nimmt. Die Ergebnisse der Profiling Analyse
werden im Abschnitt 8.5 näher erläutert.
Grundsätzlich zeigt dieser Benchmark Test, dass die xFIND Kommunikationsschicht
speziell für kleine Datenpakete annähernd gleich bleibende Werte für die
Datenübertragung erzielt. Aufgrund der geringen Datenmengen, die beim
Verbindungsaufbau ausgetauscht werden, fallen diese auch bei Transaktionen kleiner
Datenpakte kaum ins Gewicht. Eine Anforderung an die xFIND Kommunikationsschicht
ist, eine möglichst kleine Antwortzeit auf erste Anfragen zu erreichen. Weitere Daten
werden iterativ angefordert. Diese Anforderung kann anhand dieses Tests als erfüllt
angesehen werden.
Sind xFIND Komponenten über ein Netzwerk miteinander verbunden, müssen die
Datenmengen ohnehin gering gehalten werden. Das zeigt eindeutig die Kennlinie des
remote-Tests. Hier ist eine Antwortzeit unter 300ms kaum zu erreichen. Für den
Benchmark Test muss jedoch berücksichtigt werden, dass die Verbindung jedes Mal
erneut aufgebaut werden muss. D.h. eine Mehrfachverbindung ist in xFIND bisher nicht
vorgesehen.
7.8.
Schlussbemerkung
xFIND setzt von der Konfiguration bis hin zur Datenübertragung eigene
Entwicklungen ein. Der Grund liegt zum einen darin, dass es zu Beginn der Entwicklung
von xFIND noch keine geeigneten standardisierten Werkzeuge oder entsprechenden
Module bzw. Protokolle gab. Zum anderen wurden standardisierte Möglichkeiten im
Bereich der Metadaten den gegebenen Anforderungen (Bewertung von Referenzen)
angepasst bzw. erweitert.
Im Bereich der Konfiguration existieren im derzeitigen Stand einige Redundanzen.
Verschiedene
Files
decken
oft
dieselben
Konfigurationsbereiche
oder
Konfigurationswerte ab. Diese Problematik entstand durch den modularen Aufbau von
xFIND und den verschiedenen Entwicklungsstufen in den Modulen. Jede Komponente
setzt eigene Konfigurations-Dateien ein. Eine Verbesserung hinsichtlich der
Verwendbarkeit ist durch einen Umbau der Konfigurationssyntax in eine XML-Notation
erreichbar. Damit sollte die Konfiguration sowohl „machine-readable“ als auch „humanreadable“ sein. Zudem soll versucht werden, die Redundanzen der verschiedenen
Konfigurationsdateien zu entfernen und dafür weniger aber klar strukturierte und für
xFIND allgemein gültige Konfigurations-Dateien zu entwerfen.
Im Bereich der Datenübertragung wird eine Authentifikation und gesicherte
Datenübertragung bisher nicht unterstützt. Es erfolgt lediglich eine Anmeldung des
Clients beim Server anhand eines Tickets. Der Server kann das Ticket akzeptieren oder
ablehnen. Der Zugriff auf die Daten ist für jedermann gleichberechtigt. Es ist in xFIND
keine Rechteverwaltung vorgesehen. In weiterer Folge ist es so auch nicht möglich,
kommerzielle Aspekte zu berücksichtigen. Da eine gesicherte Datenübertragung nicht
unterstützt wird, gibt es auch keine Möglichkeit die Echtheit der Daten zu überprüfen.
Vom Prinzip her ist das Datenübertragungsformat QCF ein recht effizientes Format.
Doch kann es durchaus Engpässe bei der Anzahl an Verbindungen geben. Diese Anzahl
ist zurzeit auf 255 beschränkt. In xFIND ist keine bidirektionale Verbindung zweier
Module möglich. Die Kommunikationsschicht arbeitet nach dem Client-Server Prinzip
auf synchrone Weise. Sie ist nicht offen zur Anbindung an verschiedene Fremdsysteme,
bzw. bietet intern keine einfachere Möglichkeit des Datenaustausches an.
Seite 127
Kapitel 8
8.
Analyse des Protokolls BEEP
Der generelle Aufbau des BEEP Protokolls wurde bereits in Abschnitt 5.5 eingehend
beschrieben. Als Einführung zur näheren technischen Analyse des Protokolls, werden
nochmals kurz zusammengefasst die wichtigsten Kernpunkte von BEEP erwähnt.
BEEP ist verbindungsorientiert, arbeitet asynchron und wird als Protokoll-Framework
zur Datenübertragung eingesetzt. Das Framework beinhaltet verschiedene, wieder
verwendbare Module. Module werden in BEEP als Profile bezeichnet. Über diverse
Profile kann man etwa die Authentifikation, eine Datenverschlüsselung,
Datenkompression oder eine Fehlerbehandlung realisieren.
Die Aufgabe von BEEP gilt rein der Datenübertragung. BEEP setzt dabei auf die
Transportschicht TCP/IP auf. Daten oder Nachrichten werden vor dem Versenden in
Frames unterteilt und mit den verschiedenen Austauscharten zwischen zwei BEEPPartnern übertragen. Die Kodierung der Daten erfolgt im XML-Format. So ist auch die
Unterstützung verschiedener XML basierender Datenaustauschformate möglich. Es
existieren bereits Profile für SOAP und XML-RPC. Da BEEP gleichberechtigte Partner
im Datenaustausch vorsieht, kann BEEP in Peer-to-Peer Netzwerken oder zum
Datenaustausch zwischen zwei Server eingesetzt werden. Ein weiterer Vorteil von BEEP
liegt in der Mehrfachausnutzung von Verbindungen.
Um den Nutzen des BEEP Protokolls für den Einsatz in der xFIND
Kommunikationsarchitektur bewerten zu können, wurde zu Testzwecken eine Java
Referenzimplementierung des BEEP Protokoll entsprechend angepasst. Zusätzlich wurde
diese Referenzimplementierung erweitert, um den Einfluss von Transportsicherheit und
Authentifikation auf den Datendurchsatz ermitteln zu können. Die Testumgebung, die
Testarchitektur und der Testablauf aus dem Benchmark Test in Abschnitt 7.6, wurden
ebenfalls bei der Erweiterung der Referenzimplementierung als Basis miteinbezogen.
Die Ergebnisse aus den xFIND Benchmarktests und den BEEP Benchmarktests
werden einander gegenübergestellt und miteinander verglichen. Die daraus resultierenden
Erkenntnisse sind in einem eigenen Unterpunkt zusammengefasst. Weiters werden
Vorschläge erstellt, wie die xFIND Datenpakete mit dem BEEP-Protokoll effektiv
übertragen werden können.
8.1.
Aufbau der BEEP Kommunikation
In BEEP sind drei verschiedene Möglichkeiten für den Datenaustausch vorgesehen.
Der Name bzw. der Typ der Austauschart, ergibt sich aus dem Server-Antwort Verhalten.
Dabei wird unterschieden zwischen „One-to-One Exchange“ und „One-to-Many
Exchange“. Bei One-to-One Verbindungen wird für jeden Client-Request ein Server-
Seite 128
Kapitel 8 - Analyse des Protokolls BEEP
Response generiert. Bei One-to-Many Verbindungen kann der Server auf eine Anfrage
mehrere Antworten an den anfragenden Client schicken.
Die Kommunikation erfolgt asynchron. D.h. bei One-to-Many Verbindungen muss der
Client dafür sorgen, dass es zu keinen Abhängigkeiten oder Kollisionen zwischen den zu
erwartenden Datenpakten geben kann.
•
message/reply:
Der Client schickt eine Anfrage an den Server. Der Server wertet
die Anfrage aus und schickt eine positive Antwort (MSG) an den Client zurück; „Oneto-One“.
message/error: Der Client schickt eine Anfrage an den Server. Dieser wertet die
Anfrage nicht aus und schickt in diesem Fall eine negative Antwort (RPY) an den
Client zurück; „One-to-One“.
message/answer: Der Client schickt eine Anfrage an den Server. Dieser wertet die
Anfrage aus und schickt keine (null), oder mehrere Antworten (ANS) an den Client
zurück. Durch eine spezielle gekennzeichnete Nachricht wird der “One-to-Many“
Datenstrom abgeschlossen.
•
•
Wie bereits eingangs des Kapitels erwähnt, können Nachrichten bzw. Daten in
mehrere Frames unterteilt werden. Jede Nachricht kann mit einem Header beginnen, der
den Inhalt der Nachricht beschreibt (z.B. MIME-Type). Als Defaultwert für den
Inhaltstyp wird der MIME-Type „application/octet-stream“ festgelegt. Der Defaultwert
für das „Content-Transfer-Encoding“ ist „binary“. Eine Nachricht ist in XML-kodiert und
kann beliebig lang sein. Das Frame selbst wird wiederum in drei Bereiche unterteilt. Die
Untereilung erfolgt in Header, Nutzlast (Payload) und abschließenden Trailer. Header
und Trailer enden jeweils mit der Zeichenkette „CRLF“. Die BEEP Frame Syntax wurde
im [RFC 3080] in ABNF-Notation116 wie folgt definiert:
frame
data
header
msg
rpy
ans
err
nul
common
channel
msgno
more
seqno
size
ansno
payload
trailer
mapping
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
data | mapping
header payload trailer
msg | rpy | err | ans | nul
"MSG" SP common
CR LF
"RPY" SP common
CR LF
"ANS" SP common SP ansno CR LF
"ERR" SP common
CR LF
"NUL" SP common
CR LF
channel SP msgno SP more SP seqno SP size
0..2147483647 (1-10byte)
0..2147483647 (1-10byte)
"." | "*"
(1byte)
0..4294967295 (1-10byte)
0..2147483647 (1-10byte)
0..2147483647 (1-10byte)
*OCTET
(*byte)
"END" CR LF
(5byte)
;; each transport mapping may define additional frames
Abbildung 8.1: BEEP Frame Syntax [RFC 3080]
Der Header bestimmt den Typ des Nachrichtenaustausches. Der Header-Typ ist eine
3-byte lange Zeichenkette; MSG- message, RPY-reply, ANS-answer, ERR-error, NULterminator.
Channel
entspricht
der
Kanalnummer,
über
welchen
der
Nachrichtenaustausch erfolgt. Die Kanalnummer muss im Bereich von 0 – 231-1 liegen.
Die Kanalnummer 0 ist jedoch für das Kanalmanagement reserviert. D.h. zum
Datenaustausch müssen Kanalnummern größer 0 verwendet werden. Die Message116
ABNF: Augmented Backus Naur Form. Diese wurde im [RFC 2234] beschrieben und stellt Erweiterungen der
„normalen“ BNF für die Beschreibung von Spezifikationen (RFC’s) zur Verfügung.
Seite 129
Number muss ebenfalls im Bereich von 0 – 231-1 liegen. Sie gilt für eine Anfrage und alle
darauf erstellten Antworten. Aufgrund von möglichen Mehrfachantworten muss die
Message-Number eindeutig sein und darf innerhalb einer Transaktion (Nachricht wird mit
ERR, RPL oder NUL abgeschlossen) nicht wieder verwendet werden. More gibt an, ob die
aktuelle Nachricht vollständig ist, oder ob noch weitere Frames folgen. Der
Fortsetzungsindikator More wird mit den Zeichen „.“ (Nachricht ist vollständig) und „*“
(es folgen noch Frames) beschrieben und belegt somit 1byte. Die Sequence-Number
definiert das erste Oktett in der Nutzlast. Diese muss im Bereich von 0 – 232-1 liegen. Size
beinhaltet die Anzahl zu übertragender Oktetts117 in der Nutzlast. Diese muss im Bereich
von 0 – 231-1 liegen. Sämtliche Zahlenfolgen wie z.B. channel oder msgno werden als
Bytestreams geschrieben. Dies bedeutet, die Länge der Zeichenkette entspricht der
Ziffernanzahl (1-10byte).
Die Nutzlast der BEEP Nachricht liegt zwischen Header und Trailer. Die Länge der
Nutzlast kann 0 oder mehrere Oktetts umfassen. Auch jede Antwort auf einen Request
wird mit einer Answer-Number gekennzeichnet. Diese muss wie die seqno im Bereich
von 0 – 232-1 liegen. Den Abschluss einer BEEP-Nachricht bildet der Trailer. Dieser wird
mit der Zeichenfolge „END“ und „CRLF“ (dies entspricht 5bytes) definiert. BEEP wird
auf die Transportschicht TCP/IP aufgesetzt. Um Nachrichten mittels mehreren Frames
übertragen zu können, wird statt eines einfachen Daten-Frames ein Sequence-Frame
erzeugt. Die Syntax des BEEP Sequence-Frames ist im [RFC 3081] wie folgt in ABNFNotation definiert:
seq
ackno
window
; channel,
= "SEQ" SP channel SP ackno SP window CR LF
= seqno
= size
seqno, and size are defined in Section 2.2.1 of [RFC 3080].
Abbildung 8.2: BEEP Sequence Frame Syntax [RFC 3081]
Eine Sequence wird mit dem Sequence-Marker “SEQ” (3byte) eingeleitet. Channel
entspricht der ausgehandelten Kanalnummer. Die Acknowledgement-Number
kennzeichnet den Wert der nächsten Sequence-Number im Datenstrom. Die
Kennzeichnung Window entspricht der Size im gewöhnlichen Data-Frame. Sie gibt die
Größe des darauf folgenden Paylodes als Oktett-Wert an. Eine Sequence wird mit der
Zeichenfolge „CRLF“ abgeschlossen. Um eine bessere Übersicht über die Frame-Syntax
bzw. der Struktur einer BEEP Message zu bekommen, sind die möglichen
Kombinationen in Abbildung 8.3 nochmals vereinfacht grafisch dargestellt.
117
Oktett: leitet sich vom lateinischen Wort Octo = Acht (Ziffer 8) ab. Ein Octet sind 8 binäre digits oder 1byte.
Insbesondere ist der Begriff Octet bei der Datenübertragung gebräuchlich.
Seite 130
seq-frame
message
data-frame
header
data-frame
header
payload
type
SP
channel
SP
seqno
SP
size
SP
trailer
msgno
SP
more
SP
LF
ansno
SP
peload
OCTET
trailer
seq-frame
"SEQ"
SP
END
channel
CR
SP
LF
ackno
SP
window
CR
LF
Abbildung 8.3: Grafische Darstellung der BEEP Frame-Syntax
Wie bereits einleitend erwähnt ist in BEEP die Mehrfachausnutzung von
Verbindungskanälen möglich. D.h. ist eine Verbindung zwischen zwei Teilnehmern
geöffnet, können auch weitere Kanäle für dieselbe Verbindung erzeugt werden. Diese
werden dann über dieselbe Verbindung mittels Multiplexen118 gemeinsam verwendet. Ist
eine Verbindung aufgebaut, werden Nachrichten in Form von fünf verschiedenen
Grundtypen ausgetauscht: greeting, start, close, ok und error. An dieser Stelle
wird aber nicht näher auf die Verwendung der verschiedenen Möglichkeiten dieser
Grundtypen eingegangen. Diese sind detailliert im [RFC 3080] beschrieben.
118
Multiplexen: Unter Multiplexen versteht man die feste Zuteilung eines Teils der gesamten Bandbreite einer
Verbindung.
Seite 131
Als Beispiel für eine erfolgreiche Initialisierung einer Verbindung zwischen Client (C)
und Server (S) dient folgender Codeauszug:
C:
C:
C:
C:
C:
C:
C:
C:
C:
S:
S:
S:
S:
S:
S:
S:
MSG 0 1 . 52 158
<start number='1'>
<profile uri='http://iana.org/beep/TLS'>
<![CDATA[<ready />]]>
</profile>
</start>
END
RPY 0 1 . 110 121
<profile uri='http://iana.org/beep/TLS'>
<![CDATA[<proceed />]]>
</profile>
END
Listing 8.1: BEEP Initialisierungsvorgang zwischen Client und Server [RFC 3080]
Eine Nachricht (Massage-Typ start) wird vom Client zum Server geschickt, um einen
Kanal zu öffnen. Der Zielkanal ist Kanal 0 (Kanalmanagement) mit der
Nachrichtnummer 1. Die Nachricht besteht aus einem Frame mit der Sequenznummer 52.
Die Anzahl der Oktette in der Nutzlast beträgt 158. Der Server antwortet mit einer
gültigen replay Nachricht und bestätigt das vom Client angeforderte TLS Profil.
Mit Profilen wird die Art der Datenübertragung festgelegt. Neben der
Authentifizierung und Transportsicherheit wird die Syntax und Semantik zugelassener
Nachrichten definiert. Authentifizierung über SASL und Transportsicherheit über TLS
sind bereits fix integrierte Bestandteile in BEEP. Diese können bei Bedarf bei der
Erstellung eines Kanals mit angegeben werden. Will man spezifischen Anforderungen
bezüglich Syntax oder Semantik bei der Datenübertragung gerecht werden, muss dafür
ein geeignetes Profil erstellt werden und wiederum beim Kanalaufbau übertragen werden.
8.2.
BEEP Testimplementierung
Als Grundlage der Testimplementierungen wurde das Open Source Projekt „beepcore
eingesetzt. Es existieren zwar auch andere Java Implementierungen des
BEEP-Protokolls (permaBEEP-java-0.8 und beeplite_092), jedoch hat sich bei ersten
Tests herausgestellt, dass die Referenzimplementierung von beepcore recht einfach und
verständlich aufgebaut ist und sich einfach erweitern lässt. Aufgrund der Open Source
Aktivitäten und der guten Basisfunktionalität, wurde die beepcore Implementierung in
weiterer Folge für die anschließenden Benchmark Tests in Abschnitt 8.3 als Basis
Implementierung des BEEP-Protokolls herangezogen.
v0.9.08“119
Für die Benchmark Tests wurde die „Example“ Beispielapplikation von beepcore
erweitert, um neben der Transportsicherheit TLS auch eine Authentifikation mittels
Anonymous SASL und SASL-OTP120 durchführen zu können. Die Beispielapplikation
von beepcore verfügt über einen Server-Deamon (Beepd.java), der generisch alle Profile
über dynamisches Class-Loading referenziert. Die Definition der Profile ist über ein
XML-File konfigurierbar. Die verschiedenen eingesetzten Profile sind von beepcore
119
beepcore: http://www.beepcore.org/, biete eine Basis Java Implementierung für [RFC 3080] und [RFC 3081] an
OTP: OTP steht für One Time Password. Das Passwort ist nur für eine Verbindung gültig und wird aus einer OTPDatenbank ausgelesen.
120
Seite 132
Kapitel 8 - Analyse
alyse des Protokolls BEEP
ebenfalls in XML-Files121 spezifiziert.
Der generische BEEP Daemon wurde für die Testimplementierung ohne
Veränderungen übernommen. Die XML-Definitionsdatei der zu unterstützenden Profile
wurde entsprechend um das SASL und SASLOTP Profil ergänzt. Das beepcore example
sieht in seiner ursprünglichen Form für jeden Request eine eigene Authentifizierung vor.
Um die One-to-Many Eigenschaft von BEEP simulieren zu können, wurden die
Beispielimplementierung von beepcore dahingehend erweitert. In den Benchmark Tests
sind verschiedene Kombinationen bezüglich Transportsicherheit und Authentifikation zu
durchzuführen. Aus diesem Grund wurde die Client Klasse in zwei verschiedenen
Versionen umgesetzt.
Die erste Version des BEEP Clients inkludiert alle Test Fälle für einen stetigen
Kommunikationsaufbau. Als Inititalisierungsparameter gelten dabei die zu verwendende
Transportsicherheit und die zu verwendende Authentifikation. Dieselben
Initialisierungsparameter werden auch vom zweiten Versuchs Client ausgewertet. Im
zweiten Fall wird versucht, bei mehreren Datenübertragungen nur einen Kanal zu
erstellen und über diesen mehrere Transaktionen durchzuführen.
beepd-config.xml
Bing
Beepd
BingNewSession
Abbildung 8.4: Blockdiagramm des BEEP Client-Server Testaufbaus
8.3.
BEEP Benchmark Tests
Zur Überprüfung der Performance des BEEP-Protokolls bezüglich der
Datenübertragung in lokalen und verteilten Umgebungen, wurden wiederum drei
Benchmark Tests durchgeführt. Die verwendeten Rechnerarchitekturen entsprechen den
in Abschnitt 7.6 beschriebenen Architekturen und werden mit PC1-PC3 bezeichnet.
Neben der grundsätzlichen Eigenschaft der Datenübertragung, wird explizit auch die
Zeitverzögerung bei der Authentifikation und bei Aktivierung der Transportsicherheit
ermittelt.
Als Transport Profil wurde das einfachste ECHO-Profil verwendet. Der Beep-Daemon
wird gestartet, und nimmt alle eingehende Anfragen und Daten von Clients entgegen. Als
Antwort auf die Anfragen, werden dieselben Daten unverändert wieder an den Client
zurückgeschickt. Entsprechend ist dies ein sehr einfaches und effizientes Profil. Weiters
wurden folgende Testbedingung festgelegt:
121
BEEP-Profile Spezifikationen:
http://iana.org/beep/TLS;
http://xml.resource.org/profiles/NULL/ECHO;
http://iana.org/beep/SASL/ANONYMOUS;
http://iana.org/beep/SASL/OTP
Seite 133
Grundsätzliche Vorgaben (gleich wie in Abschnitt 7.6 xFIND Benchmark Tests)
•
•
•
•
•
•
Datenpakete in Größen von 1KB in logarithmischen Schritten bis 5MB.
Die Datenpakete werden 10 Mal in Folge übertragen.
Es wird die Zeitdifferenz vom Senden bis zum Empfangen der Daten ermittelt.
Die Folge von 10 Paketen wird gemittelt und in eine Tabelle eingetragen.
Verbindungsaufbau: nur einmal für ein Paketfolge (Bing.java) oder stets jedes Mal
neu für alle Pakete (BingNewSession.java).
Der BEEP-Deamon ist am selben Rechner wie der Client (localhost) oder über ein
Netzwerk erreichbar (remote).
Spezielle Vorgaben angepasst an die erweiterten Möglichkeiten zur Authentifizierung
und Datenverschlüsselung.
•
•
•
•
Fall 1: keine Transportsicherheit und keine Authentifikation
Fall 2: Transportsicherheit TLS und keine Authentifikation
Fall 3: Transportsicherheit TLS und Authentifikation mit SASL
Fall 4: Transportsicherheit TLS und Authentifikation mit SASLOTP
Erklärung zur Legende: Authentifizierung-Transportsicherheit- Verbindungsaufbau
N-N-1
N-TLS-1
SASL-TLS-1
SASLOPT- TLS-1
N-N-X
N-TLS-X
SASL-TLS-X
SASLOTP-TLS-X
none, none, einmal
none, TLS, einmal
SASL, TLS, einmal
SASLOTP, TLS, einmal
none, none, jedes mal
none, TLS, jedes mal
SASL, TLS, jedes mal
SASLOTP, TLS, jedes mal
In der Wertetabelle und in der anschließenden Analyse ist die Variable X als Iterator
für den Verbindungsaufbau anzusehen. Dies bedeutet, dass z.B. im Fall N-N-1 zwar 10mal die Datenpakete verschickt wurden, jedoch der Verbindungsaufbau (Client-Server
Handshake) nur einmal durchgeführt wurde. Im Fall N-N-X ist die Variable X
entsprechend mit dem Wert 10 belegt.
Seite 134
Size
N-N-1
bytes
ms
N-TLS-1
SASLTLS-1
ms
ms
SASLOPT
-TLS-1
N-N-X
N-TLS-X
SASLTLS-X
ms
ms
ms
ms
SASLOTP
-TLS-X
ms
1k
3
3
3
2
27
235
103
1.715
2k
5
6
5
5
27
241
95
1.705
5k
8
11
8
6
30
233
94
1.702
10k
22
30
13
11
32
256
114
1.708
20k
31
61
25
22
53
267
130
1.741
50k
202
244
144
164
234
444
225
1.884
100k
375
472
367
433
378
717
536
1.945
200k
684
1.058
753
619
738
1.233
759
2.208
500k
1.483
1.953
1.625
1.741
1.337
2.453
1.634
3.334
1M
2.770
4.489
2.816
3.131
3.019
4.392
3.058
4.828
2M
5.202
8.523
5.380
5.375
5.495
8.730
5.055
7.639
5M
12.839
19.711
14.327
13.764
12.625
21.744
12.536
15.216
Tabelle 8.1: Benchmark-Test BEEP ECHO-Profil, localhost PC1
Die Analyse der Messwerte zeigt, dass bei sehr kleinen Datenpaketen der
Verbindungsaufbau die Kenngröße für die Performance vorgibt. So kann man bei Paketen
bis ca. 1kB die Größe der Datenpakete vernachlässigen. Der Verbindungsaufbau mit 10
Datenpaketen benötigt im Testfall N-N-1 ca. 3ms. Der Verbindungsaufbau mit 10
Datenpaketen benötigt im Testfall N-N-X ca. 30ms (X=10). Wird hingegen die
Transportsicherheit gefordert oder eine Authentifikation durchgeführt, verschieben sich
hier die Kennlinien, die in Abbildung 8.5 ersichtlich sind, recht deutlich und vermindern
eindeutig die Datendurchsatzrate.
B e nc hm a rk : B e e p E c ho ; S e rv e r/ C lie nt a uf lo c a lho s t
N-TLS-1
N-TLS-X
SASLOTP-TLS-X
SASL-TLS-1
100.000
10.000
N-N-1
N-N-X
SASLOPT-TLS-1
SASL-TLS-X
1.000
100
10
1
1k
2k
5k
10k
20k
50k
100k
200k
500k
1M
2M
5M
übe r t r a ge ne B y t e s
Abbildung 8.5: Kennlinien für Benchmark-Test BEEP ECHO-Profil, localhost-PC1
Die Ergebnisse sind bis zu einer Paketgröße von ca. 50kB relativ unabhängig von der
Speicherauslastung des Test-Systems. Daraus resultiert die annähernd gleichbleibende
Zeitdifferenz zwischen einmaligem und stetigem Verbindungsaufbau. Ab einer
Paketgröße von ca. 500kB weichen die Differenzwerte teilweise stark vom jeweiligen
Seite 135
Mittelwert ab. Die Analyse des Speicherbedarfes zeigt, dass eine BEEP-Integration in die
Kommunikationsschicht der Komponenten in lokalen Umgebungen nicht zielführend ist.
Zur lokalen Kommunikation sollten andere Technologien eingesetzt werden.
Man sieht jedoch anhand der logarithmischen Skala, dass ab ca. 50kB die Zeit für die
Datenübertragung annähernd linear steigt. D.h. der Zeitaufwand für die Authentifizierung
und dem Austausch der BEEP eigenen Protokollparameter sind ab diesem Wert
vernachlässigbar.
Können mehrere Datenpakete in einer Session übertragen werden, ist die Zeit des
Verbindungsaufbaues vernachlässigbar. Die nun verbleibende Restzeit wird zum
Austausch der BEEP-Parameter bei der Initialisierung der Sockets beim Schreib- und
Lesevorgang verbraucht. In diesem Fall ist eine annähernde Linearisierung im
Zeitbereich schon bei kleinen Datenpaketen gegeben. Dies gilt für alle Testszenarien in
den diversen Benchmark Tests.
Der dritte Test wurde auf ähnliche Weise durchgeführt. Der Unterschied zum ersten
bzw. zweiten Test ist, dass der BEEP-Deamon auf einem eigenen Rechner (PC3) läuft
und der Client am Rechner-PC2. Somit nehmen sich Client und Server keine Ressourcen
weg und können unabhängig voneinander die Verbindungen und die Ressourcen nützen.
Der sich ergebene Vorteil wirkt sich insbesondere bei der Übertragung von großen
Datenpaketen aus. Die beiden Fälle mit Authentifizierung wurden hier in diesem Test
nicht mehr berücksichtigt.
Size
bytes
1k
2k
5k
10k
20k
50k
100k
200k
500k
1M
2M
5M
N-N-1
ms
3
6
12
43
33
96
158
303
670
1280
2531
6490
N-TLS-1
ms
3
6
15
37
40
112
202
454
883
1693
3350
7982
N-N-X
ms
871
861
821
831
861
951
1012
1221
1589
2107
3623
7957
N-TLS-X
ms
1314
1386
1261
1352
1332
1472
1541
1659
2151
2860
4427
9153
Tabelle 8.2: Benchmark-Test BEEP ECHO-Profil, remote (Client-PC2, Deamon-PC3)
Aus den Kennwerten für kleine Datenpakete laut Tabelle 8.2, kann man erkennen,
dass das BEEP Protokoll auch in einer Netzwerkumgebung sehr effizient arbeitet. Nimmt
man als Vergleich die Kennwerte von xFIND in einer verteilten Umgebung her, kann
man hier kaum einen Unterschied zur lokalen Anwendung erkennen. Der
Kennlinienverlauf ist hier noch linearer ausgeprägt, als in der lokalen Testumgebung.
Seite 136
Benchmark: Beep Echo; Server/Client über Netzwerk verbunden
N-TLS-1
N-N-1
N-TLS-X
N-N-X
10000
1000
Z e it in m s
100
10
1
1k
2k
5k
10k
20k
50k
100k
200k
500k
1M
2M
5M
übertragene Bytes
Abbildung 8.6: Kennlinien für Benchmark-Test BEEP ECHO-Profil, remote (Client-PC2,
Deamon-PC3)
Wird aber Transportsicherheit gefordert, ist auch hier mit erheblich schlechteren
Antwortzeiten122 schon bei sehr kleinen Datenmengen zu rechnen. Interessant ist jedoch,
wie auch schon in der lokalen Testumgebung ersichtlich, die annähernd gleich bleibende
Antwortzeit von Datenpaketen bis ca. 100kB.
8.4.
xFIND Objekte in BEEP serialisieren
Um xFIND Objekte mit BEEP übertragen zu können, müssen diese entsprechend
serialisiert werden. Man kann hierzu den Stream-basierten Ansatz wie er in Abschnitt 7.4
beschrieben wurde aber nur zum Teil einsetzen. Es ist darauf zu achten, dass nur die
Datenpakete selbst serialisiert werden. D.h. Kommunikationselemente wie Server-Ticket,
Service-Request, Data-Header und Data-Footer sind hier nicht mehr zu berücksichtigen.
xFIND serialisiert, wie bereits beschrieben, vier Basis-Datentypen. QCF-Objekte,
Gatherer-Datenpakete (SOIF-Format), Indexer-Datenpakete und die Daten-Pakete des
Brokers müssen auf die vier Basis-Typen abgebildet werden. Binäre Daten wie Bilder etc.
werden als reiner Byte-Stream behandelt.
BEEP benötigt als Datentyp für den Message Payload einen String. Dieser wird
standardmäßig UTF-8 codiert. Zusätzlich kann für den Mime-Header der Content-Type
und das Transfer-Encoding angegeben werden. Im Falle der einfachen Serialisierung auf
String-Basis wird der Default Mime-Header erzeugt, „application/octet-stream“. Als
Transfer-Encoding wird als Defaultwert „binary“ festgelegt. Für den einfachsten Fall, der
Übertragung von binären Daten, ist diese Möglichkeit passend geeignet.
Im Falle von Suchanfragen von Broker zu Indexer oder Indexer zu Gatherer würde
diese Möglichkeit ausreichen. Ebenso könnten die entsprechenden Antworten von
Indexer oder Gatherer mittels byte-Stream übertragen werden. Die notwendige
Technologie, um ein QCF-Objekt in einen byte-Stream umzuwandeln und ein QCFObjekt aus einem byte-Stream zu generieren, existiert bereits.
122
Zeit zwischen Request-Beginn und Response-Ende.
Seite 137
Eine andere Möglichkeit wäre es, die QCF-Objekte in eine XML-Struktur abzubilden.
Die dafür notwendige Abstraktion bzw. hierarchische Gliederung ist bei QCF-Keys
bereits gegeben. D.h. es sollte recht einfach möglich sein, aus dem derzeitigen Textbasierten QCF-Format ein gleichwertiges XML-basiertes Format zu generieren. Dies
bringt den Vorteil der einfachen Erweiterbarkeit. Zusätzlich sind XML-basierte Ansätze
sowohl Human- als auch Machine-Readable. Zusätzlich sollte neben der Umwandlung
der QCF-Syntax in eine XML-Notation ein eigenes QCF-Profil erstellt werden. Die
Validierung kann über eine geeignete DTD erfolgen.
Denkbar ist aber auch ein anderer Ansatz. Nachdem innerhalb der xFIND-Module
Datenpakete über Suchanfragen und entsprechenden Antworten ausgetauscht werden, ist
auch an die Möglichkeit zur Unterstützung von SOAP oder XML-RPC zu denken. Diese
beiden Möglichkeiten vereinen Datentransport und Funktionalität. In QCF sind neben
reinen Daten-Keys vor allem viele verschiedene Funktionale-Keys definiert. Eine
Abbildung der Funktionalität auf XML-RPC und des Datenbereiches auf SOAP wäre
eine neue interessante Möglichkeit, um auch die Anbindung an Fremdsysteme zu
erleichtern. Dieser Schritt ist jedoch mit enormem Aufwand verbunden, da doch
sämtliche internen funktionalen Einheiten mit den QCF-Objekten arbeiten.
8.5.
BEEP im Vergleich mit der xFIND-Kommunikationsschicht
Wird BEEP in der Kommunikationsschicht eingesetzt muss man sich im Klaren sein,
dass dadurch mehr Overhead beim Verbindungsaufbau entsteht. Der recht einfache
Aufbau der xFIND-Kommunikation mit den fünf verschiedenen Bereichen Server-Ticket,
Service-Request, Data Header, Data und Data-Footer ist auf jeden Fall performanter als
der BEEP-Ansatz. Dies zeigt der unmittelbare Vergleich bezüglich der Datenmengen, die
beim Verbindungsaufbau ausgetauscht werden.
Für einen Vergleich der Datenmengen beim Kommunikationsaufbau wurde zwischen
Client und Server ein „Sniffer“ quasi als Proxy dazwischen geschaltet. Die Auswertung
der eingehenden und ausgehenden Daten decken sich mit den Erklärungen aus der
technischen Analyse von xFIND in Abschnitt 7.5 und Abschnitt 7.6 bzw. BEEP aus
Abschnitt 8.1. Es wird deshalb an dieser Stelle explizit darauf verzichtet, diese
Ergebnisse entsprechend dokumentarisch anzuführen.
Um die Echtheit der Daten gewährleisten zu können, oder verschiedene Angriffe oder
Attacken abwehren zu können, ist es unumgänglich mehr Energie in die Entwicklung von
Sicherheitsvorkehrungen zu investieren. Insbesondere im Punkt Sicherheit bietet xFIND
im derzeitigen Stand wenige bis keine Lösungen an. Allein schon aufgrund des verteilten
Ansatzes der xFIND-Module wird Sicherheit immer wichtiger. Im BEEP
Architekturkonzept ist die Authentifikation und/oder Transportsicherheit bereits fixer
Bestandteil und kann wahlweise durch die Aktivierung über diverse Profile eingesetzt
werden.
Ziel von xFIND ist es, insbesondere die Gatherer lokal bei den Informations-Quellen
zu installieren. Dadurch kann die Netzwerk-Last verringert werden und eine Vorselektion
der Datenbestände erfolgen. Durch die Vorselektion und einer Vorabanalyse der Daten
kann auch die zu übertragene Datenmenge verringert werden. Welche Vorteile und
Nachteile dies bringt, zeigt der Vergleich der Kennwerte des Datendurchsatzes von
xFIND und BEEP. Die Kennwerte wurden aus den jeweiligen Benchmark-Tests von
Abschnitt 7.6 und 8.2 übernommen und in Tabelle 8.3 einander gegenüber gestellt.
Seite 138
Size
bytes
1k
2k
5k
10k
20k
50k
100k
200k
500k
1M
2M
5M
xFIND
localhost
PC1
ms
5
8
6
8
16
50
116
247
477
789
1359
3581
BEEP
localhost
PC1
ms
27
27
30
32
53
234
378
738
1.337
3.019
5.495
12.625
xFIND
remote
PC2-PC3
ms
299
300
301
301
316
595
703
996
1644
2505
4231
11115
BEEP
remote
PC2-PC3
ms
871
861
821
831
861
951
1012
1221
1589
2107
3623
7957
BEEP
localhost
N-N-1
ms
3
5
8
22
31
202
375
684
1.483
2.770
5.202
12.839
BEEP
remote
N-N-1
ms
3
6
12
43
33
96
158
303
670
1280
2531
6490
Tabelle 8.3: Vergleich des Datendurchsatzes der Kommunikation von xFIND und BEEP
Um xFIND und BEEP direkt miteinander vergleichen zu können, wurde bei BEEP als
Vergleichsspalte die Testvariante N-N-X gewählt. Dies bedeutet, dass bei BEEP die
Verbindung jedes Mal erneut aufgebaut wurde und die Daten ohne Authentifikation und
ohne Transportsicherheit übertragen wurden. Als zusätzliche informative Vergleichswerte
wurden noch die Spalten N-N-1 hinzugefügt.
Tabelle 8.3 zeigt nun die Unterschiede zwischen xFIND und BEEP recht deutlich. In
der Tabelle sind die Tests für die lokalen und verteilten Umgebungen von xFIND und
BEEP jeweils einander gegenüber gestellt. Bei kleinen Datenmengen zeigen sowohl
xFIND als auch BEEP bis ca. 10kB annähernd gleichbleibende Werte. Aufgrund des
größeren Handshake Bedarfes von BEEP, steigt bei größeren Datenmengen auch der
Kommunikationsaufwand. Interessant ist, dass im verteilten Prinzip bei größeren Werten
in xFIND zunehmend schlechtere Werte ermittelt wurden. Die Übertragungszeiten von
BEEP bleiben hingegen annähernd proportional zur Datenmenge.
Wird BEEP allerdings im Modus N-N-1 betrieben, d.h. es wird nur eine Verbindung
für viele Transaktionen aufgebaut (One-to-Many), skaliert BEEP hingegen schon bei
kleinen Datenmengen annähernd linear. Im Vergleich zur verteilten Umgebung weist
BEEP durchaus erstaunliche Werte auf. Hier zeigt sich eindeutig die Effizienz von BEEP
in einer verteilten Umgebung. Der Verbindungs-Handshake muss nur einmal
durchgeführt werden.
In Abschnitt 7.6 wurde kurz der Profiling Test erwähnt. Mittels Profiling kann auf
einfache Art und Weise das Zeitverhalten von Klassen bzw. Methoden und der
Speicherbedarf von Datenstrukturen ermittelt werden. Java bietet hiefür bereits geeignete
Klassen an. Für die Entwicklungsumgebung „Eclipse“ gibt es ein frei verfügbares
Profiling Plugin123. Dieses Plugin wurde für die folgende Analyse des GesamtSpeicherbedarfes von xFIND und BEEP während der Datenübertragung eingesetzt. Der
Profiling-Test wurde auf der PC1-Architektur (localhost) durchgeführt.
123
Eclipse Profiler Plugin: Version 0.5.30; http://eclipsecolorer.sourceforge.net; CPL License version 1.0
Seite 139
Abbildung 8.7: Profiling-Test, Speicherauslastung von xFIND (links) und BEEP (rechts)
Die beiden Speicherabbildungen in Abbildung 8.7 weisen auch hier deutliche
Unterschiede auf. Insbesondere bei größeren Datenmengen verfügt BEEP über eine
bessere Ausnutzung des Arbeitsspeichers. Zusätzlich wurde in Abbildung 8.8 der
Speicherbedarf und die CPU Belastung von xFIND und BEEP im gleichen Testdurchlauf
mit dem Taskmanager von Windows aufgezeichnet. Auch hier ist der größere
Speicherbedarf von xFIND deutlich ersichtlich.
Abbildung 8.8: CPU Belastung und Speicherabbild von Windows Taskmanager für xFIND und
BEEP
Bezüglich der CPU Belastung (obere Kennlinie) gibt es kaum Unterschiede. xFIND
benötigt von Beginn an zwischen 90% und 100% der CPU. BEEP weist zu Beginn eine
ca. 75% CPU-Last auf. Der Speichbedarf (untere Kennlinie) bewegt sich bei xFIND
zwischen 0 und 150 MB. BEEP bleibt bei diesem Test zwischen 0 und 100MB.
Weiters wurden aus der Profiling Analyse der verschiedenen Testdurchlaufe die „CallTrees“ extrahiert. Diese sind gesondert im Anhang C Kapitel 14 ersichtlich und zeigen
schematisch den strukturellen Ablauf des Datentransportes.
Seite 140
8.6.
Schlussbemerkung
BEEP ist ein asynchrones verbindungsorientiertes Protokoll. Daten und Nachrichten
werden XML kodiert und können in Frames zerteilt werden. Dadurch ergibt sich ein
flexibler Datenaustausch. Die Syntax und Semantik der Datenübertragung wird mit
Profilen festgelegt. Diese sind ebenfalls in XML Notation erstellt und können bei Bedarf
selbst erstellt werden. Entsprechende Profile für SOAP und XML-RPC existieren bereits.
Zusätzlich sind im BEEP-Core Standard-Profile für die Transportsicherheit und die
Authentifikation enthalten. BEEP ermöglicht auch die mehrfache Ausnutzung einer
Verbindung durch Kanal-multiplexen.
Die Effizienz von BEEP gegenüber der xFIND Kommunikationsschicht ist im
Allgemeinen schlechter. Negativ wirkt sich dieser Unterschied jedoch nur bei sehr
kleinen Datenpaketen und oftmaligem Verbindungsaufbau aus. Aber die Vorteile des
modulbasierten Profil Ansatzes von BEEP sollten an dieser Stelle mehr Gewicht haben.
Zumal man die Grundeigenschaften von BEEP wie Asynchronität, einen bidirektionalen
Verbindungsaufbau und die Mehrfachausnutzung von Verbindungen gezielt einsetzen
kann. Der Aufwand zum Auf- und Abbauen einer BEEP-Verbindung ist konstant (gleiche
Profile vorausgesetzt). Dadurch steigt die Effizienz von BEEP, wenn auf eine Anfrage
viele Ergebnisse geschickt werden oder die Datenmenge steigt.
Speziell für den verteilten Architektur-Ansatz von xFIND bietet der flexible Aufbau
von BEEP mit den optionalen Erweiterungen und des besseren Datendurchsatzes neue
interessante Möglichkeiten. In BEEP sind Sicherheitsaspekte und der gleichberechtigte
Datenaustausch bereits fixer Bestandteil. BEEP wurde als Anwendungsprotokoll für den
Datentransport entwickelt und ist auch entsprechend als solches einzusetzen.
Seite 141
Kapitel 9
9.
Analyse des JXTA Protokoll-Frameworks
Neben der Standardisierung und Verbesserung der Datenübertragung in xFIND, ist zu
Beginn dieser Arbeit, als weiteres Ziel eine einfachere Kommunikation bzw. eine bessere
Verwaltung der xFIND Module festgelegt worden. Im Untersuchungsteil dieser Arbeit
wurden schon bei der Analyse von Peer-to-Peer Netzwerken dessen Vorteile und
Nachteile erarbeitet. Speziell moderne Ansätze in der verteilten Suche bieten im Bereich
der Verwaltung von Ressourcen, neue und interessante Möglichkeiten.
Die Problembereiche wie z.B. Inkompatibilität, schlechte Erweiterbarkeit,
hervorgerufen aufgrund des proprietären Ansatzes vieler Produkte, führten zur
Entwicklung eines generischen Protokoll Frameworks. Mit JXTA soll nun der Versuch
unternommen werden, im Bereich P2P quasi standardisiert die Suche nach Diensten oder
Ressourcen zu bewerkstelligen. Zusätzlich soll über diese Methoden die Verwaltung der
Peer und Peer Gruppen automatisiert erfolgen.
Aufgrund dieser beiden grundlegenden Eigenschaften von JXTA, wird diese
Technologie nun näher untersucht. Es wird bei der Untersuchung besonderen Wert auf
technische Details gelegt, da diese unumgänglich für die Erstellung von
Verbesserungsvorschlägen zur Erweiterung des xFIND Systems sind.
JXTA ist ein generisches Protokoll-Framework, dass in Peer-to-Peer Netzwerken
eingesetzt werden kann. Die abstrahierte Kommunikationsschicht ist plattform- und
programmiersprachen- unabhängig. Aus diesem Grund können sich Entwickler mehr auf
die Kernfunktionalität von verteilten Anwendungen konzentrieren. JXTA arbeitet
nachrichtenorientiert. Der Datenaustausch erfolgt asynchron und folgt einer XMLformatierten Syntax. Der Nachrichteninhalt mittels MIME-Type Format spezifiziert kann
textorientiert sein oder als binärer Datenstrom Base64 codiert werden. Damit ist die
Vermittlung der gängigsten Daten-Typen mit JXTA möglich.
JXTA Protokolle und Dienste sind nicht standardisiert. Aufgrund des „freien“
Architekturansatzes ist es jedoch ohne größere Probleme möglich, Dienste wie z.B.
WSDL (siehe Abschnitt 4.8.2) oder PEEP (siehe Abschnitt 8) in der Transportschicht zu
unterstützen. Die JXTA Architektur wurde bereits in Abschnitt 6.3 kurz beschrieben.
Bevor aber näher auf die technischen Details eingegangen wird, sollen die
interessantesten Merkmale von JXTA nochmals kurz zusammengefasst werden.
JXTA ist grob in drei Schichten unterteilt. Auf dem JXTA-Core setzen die JXTAServices auf und auf diesen wiederum die JXTA-Anwendungen. Der JXTA-Core bildet
mit sechs Protokollen die Basis des Frameworks und deckt die grundlegendsten
Mechanismen wie Such- und Transportfunktionen sowie Sicherheitsrichtlinien ab. Die
JXTA-Dienste bieten erweiterte Funktionalitäten wie z.B. die Authentifizierung, das
Erstellen von Peers und Peer Groups oder Index- und Suchdienste an. Eine JXTA
Seite 142
Kapitel 9 - Analyse des JXTA Protokoll-Frameworks
Anwendung wie z.B. Filesharing, Chatsystem oder verteilte Suchsysteme, setzen direkt
auf diese Services auf.
In der JXTA Community124 existieren mittlerweile mehr als 140 verschiedene
Projekte, die sechs differenzierten Bereichen zugeordnet sind. Ca. je ein Fünftel der
Projekte sind im Applikationsbereich und im Servicebereich angesiedelt. Interessante
Service-Projekte sind unter anderem „do“ (distributed objects), „jxta-wire“ (Provide a set
of tools to allow many to many JXTA pipes), „jxtaspaces“ (A Distributed Shared
Memory Service for JXTA), „networkservices“ (Integrate Web Services Concepts into
JXTA), „soap“ (JXTA SOAP bindings), „xmlrpc“ (XML-RPC for JXTA) und „search“
(Distributed search service for JXTA and Web content and services).
Das JXTA-Search Projekt setzt den generischen Gedanken von JXTA fort, indem die
Grundfunktionalität der verteilten Suche als JXTA-Service implementiert wurde.
Suchanfragen und Antworten in JXTA-Search werden ebenfalls mit einem eigenen XMLbasiertem Protokoll realisiert. Das Query Routing Protocol (QRP) spezifiziert den
Nachrichtentyp, das Nachrichtenformat und die Message-Rounting Regeln, die von den
JXTA-Search Peers verarbeitet werden müssen.
9.1.
Beschreibung der JXTA-Core Protokolle
Wie bereits einleitend erwähnt, besteht der JXTA-Core aus sechs XML-notierten
Protokollen. Mit Hilfe dieser sechs Basis Protokolle versucht JXTA quasi „standardisiert“
Peers und Peer Gruppen zu verwalten, Ressourcen zu finden und zur Verfügung zu
stellen, sowie die interne Kommunikation und Überwachung bereitzustellen. Die JXTAProtokolle arbeiten unidirektional und asynchron. Die Protokolle sind „Semiunabhängig“. Dies bedeutet, dass ein Peer nicht alle Protokolle unterstützen muss, um
bestimmte Aufgaben erledigen zu können. Zwar setzten einige Protokolle andere voraus,
aber es ist dennoch möglich diverse Protokollschichten gegebenenfalls selbst zu
implementieren.
Die Protokolle sind in einem Protokoll-Stack hierarchisch angeordnet. So gibt es
sowohl auf der lokalen Seite eines Peers, als auch auf der Remote-Seite eines Peers
dieselbe Hierarchie. Im Unterschied zum ISO/OSI Schichtenmodell, sind die Schichten in
dieser Hierarchie nicht abstrahiert, sondern sie erfüllen unteschiedliche Aufgaben. Dies
zeigt auch Abbildung 9.1 recht deutlich. Aufgrund der Semi-Unabhängigkeit ist eine
Spezialisierung diverser Peers möglich. D.h. diese Peers übernehmen dann nur
spezifische Aufgaben. Dies könnte z.B. ein Query-Router oder ein Rendezvous Peer sein.
124
JXTA: http://www.jxta.org/servlets/ProjectList
Seite 143
Abbildung 9.1: JXTA Protokoll Stack [Wilson 2002]
Die Services und Protokolle werden anhand von so genannten „Advertisements“
beschrieben. Advertisements sind strukturierte Metadaten, die die Eigenschaften und
Funktionen der verschiedenen Ressourcen definieren. Wird ein Peer oder Dienst gesucht,
erfolgt dies implizit nach der Suche dieser Advertisements. Da die Notation der
Beschreibung wiederum XML ist, können recht einfach neue Advertisements erstellt
werden. Damit ist auch ein sprachneutrales, geräteunabhängiges und leicht
interpretierbares Austauschformat gegeben.
Aus dem JXTA Protokoll Stack in Abbildung 9.1 sind auch die sechs Protokolle und
ihre diversen Abhängigkeiten gut ersichtlich. Diese wurden in Abschnitt 5.10 schon
beschrieben. Zusammengefasst sind die Aufgaben der jeweiligen Protokolle:
1. Peer Discovery Protokoll (PDP): Beschreibt wie Peers, Peer Groups, Services oder
andere Ressourcen gefunden bzw. veröffentlicht werden. Allgemeiner formuliert
kann mit dem PDP alles veröffentlicht bzw. gefunden werden, was anhand eines
Advertisement Dokumentes beschrieben wurde.
2. Peer Information Protokoll (PIP): Mit dem PIP können Statusinformationen, wie
z.B. der Datendurchsatz oder angebotene Dienste anderer Peers erfragt werden.
Damit sind Überwachungsfunktionen im verteilten Netzwerk möglich.
3. Pipe Binding Protokoll (PBP): Beschreibt wie virtuelle Kommunikationskanäle
(Pipes) zwischen Peers erzeugt werden können.
4. Peer Resolver Protokoll (PRP): Beschreibt den Nachrichten-Austausch mittels
Query-Messages. Jede Ressource, die mit dem PRP veröffentlich wurde, kann so
auch wieder mittels PRP gefunden werden.
Seite 144
5. Rendezvous Protokoll (RVP): Legt fest, wie Nachrichten an andere Peers in
unterschiedlichen Peer Groups vermittelt werden können. Dies kann z.B. auch das
Überbrücken von Firewalls sein.
6. Endpoint Routing Protokoll (ERP): Mit dem ERP wird das Auffinden von
Transportwegen zwischen zwei Ressourcen ermöglicht.
Die nun folgende technische Beschreibung der einzelnen Protokolle ist auszugsweise
der JXTA Protokoll Spezifikation v2.0 [JXTA v2.0] entnommen. Die Definitionen der
Protokolle basieren auf XML-Schema Definitionen. Da dieses Format einfach lesbar ist,
wird keine detaillierte Erklärung zu den jeweiligen Keys und Properties gegeben. Diese
können bei Bedarf in der Spezifikation nachgelesen werden. Ein weiterer Vorteil der
XML-Schema Definitionen ist, dass diese direkt zur Validierung der Nachrichten
herangezogen werden können.
9.1.1.
Peer Discovery Protokoll (PDP)
Im JXTA Stack ist ersichtlich, dass das PDP zum Veröffentlichen und Suchen der
Advertisements das PRP einsetzt. Über das PRP werden Queries abgesetzt und auch
Ergebnisse empfangen. Wenn nach Advertisements in JXTA gesucht wird, muss über
PDP eine Discovery Query Message abgesetzt werden. Um ein Peer bzw. eine Peer
Gruppe finden zu können, schickt ein Peer eine Discovery Query Message an alle ihm
lokal bekannten Peers und Rendezvous Peers. Ein „normaler“ Peer wertet die Anfrage
aus, indem er in seinem lokalen Cache nach dem Advertisement sucht. Ist das gesuchte
Advertisement lokal gespeichert, antwortet der Peer mit einer Discovery Response
Message direkt dem Anfrage Peer. Rendezvous Peers hingegen benachrichtigen
zusätzlich alle bei ihm registrierten Peers, die dann wiederum ihrerseits direkt dem
Anfrage Peer antworten. Beim PDP handelt es sich kurz gesagt um einen
Suchmechanismus, der Informationen über das P2P Netzwerk liefert. Listing 9.1 zeigt
den Aufbau der Discovery Query Message anhand des XML Discovery Query Schema.
<xs:element name="DiscoveryQuery" type="jxta:DiscoveryQuery"/>
<xsd:simpleType name="DiscoveryQueryType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/> 
<xsd:enumeration value="1"/> 
<xsd:enumeration value="2"/> 
</xsd:restriction>
</xsd:simpleType>
<xs:complexType name="DiscoveryQuery">
<xs:sequence>
<xs:element name="Type" type="jxta:DiscoveryQueryType"/>
<xs:element name="Threshold" type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="Attr" type="xs:string" minOccurs="0"/>
<xs:element name="Value" type="xs:string" minOccurs="0"/>
<xs:element name="PeerAdv" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Listing 9.1: JXTA Discovery Query Schema [JXTA v2.0]
In Listing 9.2 ist die Discovery Response Message anhand des XML Discovery
Response Schema beschrieben. Discovery Response Message sind Antworten auf
Discovery Query Messages.
Seite 145
<xs:element name="DiscoveryResponse" type="jxta:DiscoveryResponse"/>
<xs:complexType name="DiscoveryResponse">
<xs:sequence>
<xs:element name="Type" type="jxta:DiscoveryQueryType"/>
<xs:element name="Count" type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="Attr" type="xs:string" minOccurs="0"/>
<xs:element name="Value" type="xs:string" minOccurs="0"/>
<xs:element name="PeerAdv" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Expiration" type="xs:unsignedLong"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:entry>
<xs:element name="Response" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Expiration" type="xs:unsignedLong"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:entry>
</xs:sequence>
</xs:complexType>
Listing 9.2: JXTA Discovery Response Schema [JXTA v2.0]
Das PDP garantiert nicht, dass für jede Anfrage eine Antwort zu erwarten ist, da nicht
zwingend auf jede Anfrage geantwortet werden muss. Auch können auf eine Antwort
beliebig viele Antworten generiert werden. Beim Eintreffen der Antworten ist darauf zu
achten, dass die Kommunikation asynchron erfolgt und deshalb keine definierte
Reihenfolge vorliegt. Nachdem die Discovery Query Messages im Broadcast-Prinzip
versand werden, können auch redundante Antworten auftreten.
Um Ressourcen mittels Advertisements publizieren zu können, wird das Versenden
von Discovery Response Messages, ohne eine Anfrage erhalten zu haben, ermöglicht.
PDP wird von JXTA auch als Service bereitgestellt. Das eigentliche Versenden der
Messages wird vom Resolver Service durchgeführt.
9.1.2.
Information Protokoll (PIP)
Das PIP dient, wie einleitend erwähnt zum Übertragen von Statusinformationen. Diese
Informationen werden mittels PIP Response Message an den Initiator aufgrund einer PIP
Query Message übertragen. Das Protokoll ist optional und dient lediglich der
Überwachung, bzw. es können aufgrund dieser Informationen (Traffic Load, Uptime,
Current Connection, …) Alternativhandlungen abgeleitet werden. Erhält ein Peer eine
PIP Query Message, überprüft dieser die Zieladresse (Peer-ID). Stimmt diese mit der
eigenen Peer-ID überein (Peer ist der Empfänger der PIP Query Message), antwortet der
Peer mit einer PIP Response Message. Peers müssen auf eine PIP Query Message keine
Antwort erzeugen. Die Anfrage kann zusätzlich auch als Broadcast erfolgen.
Entsprechend können auf eine Anfrage auch mehrere Responses generiert werden. Wenn
keine speziellen Request-Keys bei der Anfrage angegeben sind, antwortet ein Peer mit
einem vordefinierten Set an Statusinformationen. In Listing 9.3 ist die Syntax einer PIP
Query Message anhand einer XML-Schema Definition beschrieben.
Seite 146
<xs:element name="PeerInfoQueryMessage" type="jxta:PeerInfoQueryMessage"/>
<xs:complexType name="PeerInfoQueryMessage">
<xs:sequence>
<xs:element name="sourcePid" type="jxta:JXTAID"/>
<xs:element name="targetPid" type="jxta:JXTAID"/>
<xs:element name="request" type="xs:anyType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Listing 9.3: JXTA PIP Query Message Schema [JXTA v2.0]
Die PIP Response Message beschreibt spezifische Informationen über den aktuellen
Status eines Peers. Dazu gehören: Uptime, die Anzahl von eingehenden und ausgehenden
Messages, der Zeitpunkt der letzten erhaltenen Nachricht und der Zeitpunkt der letzten
übertragenen Nachricht. In Listing 9.4 ist die Syntax der PIP Response Message
ersichtlich.
<xs:element name="PeerInfoResponse" type="jxta:PeerInfoResponse"/>
<xs:complexType name="PeerInfoResponseMessage">
<xs:sequence>
<xs:element name="sourcePid" type="jxta:JXTAID"/>
<xs:element name="targetPid" type="jxta:JXTAID"/>
<xs:element name="uptime" type="xs:unsignedLong" minOccurs="0"/>
<xs:element name="timestamp" type="xs:unsignedLong" minOccurs="0"/>
<xs:element name="response" type="xs:anyType" minOccurs="0"/>
<xs:element name="traffic" type="jxta:piptraffic" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="piptraffic">
<xs:sequence>
<xs:element
name="lastIncomingMessageAt"
type="xs:unsignedLong"
minOccurs="0"/>
<xs:element
name="lastOutgoingMessageAt"
type="xs:unsignedLong"
minOccurs="0"/>
<xs:element name="in" type="jxta:piptrafficinfo" minOccurs="0"/>
<xs:element name="out" type="jxta:piptrafficinfo" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="piptrafficinfo">
<xs:sequence>
<xs:element name="transport" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:unsignedLong">
<xs:attribute name="Expiration" type="xs:anyURI"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
Listing 9.4: JXTA PIP Response Message Schema [JXTA v2.0]
9.1.3.
Pipe Binding Protokoll (PBP)
Das PBP wird zur Kommunikation zwischen verschiedenen Peers verwendet. Es
arbeitet wie alle anderen JXTA Protokolle asynchron und verwendet zur
Datenübertragung JXTA Pipes. Die JXTA Pipes werden auch als virtuelle Verbindungen
bezeichnet. Pipes haben lediglich die Aufgabe, zwei Endpunkte (Peers) mit einander zu
verbinden. Das PBP beschreibt wie eine Pipe an einen physikalischen Kanalendpunkt
gebunden werden kann. Das PIP kümmert sich nicht um den Datentransport. Dafür
bedient es sich am PRP Service. Beschrieben wird eine Pipe mit dem PipeAdvertisement. Eine Pipe kann auch als abstrakte Message Queue angesehen werden.
Seite 147
Operationen wie Create, Bind, Unbind, Send und Recieve gelten als Basisfunktionen. Zur
Beschreibung der Syntax des PIP wird als erstes in Listing 9.5 das Pipe Advertisement
Schema vorgestellt. Dieses wird benötigt, um eine Pipe zu erzeugen.
Im JXTA-Core gibt es zurzeit drei verschiedene Möglichkeiten Pipes zu erzeugen und
einzusetzen. JXTA-Unicast ist eine Eins-zu-Eins Verbindung ohne jegliche
Sicherheitsmerkmale. JXTA-Unicast-Secure stellt Transportsicherheit mittels TLS zur
Verfügung. JXTA-Propagate sind Eins-zu-N Verbindungen.
Um Nachrichten über JXTA-Pipes zu übermitteln, kann ein Peer eine Pipe für den
Leseprozess (Pipe-Advertisement) anfordern. Diese wird als Input-Pipe bezeichnet. Das
Erzeugen einer Pipe für den Schreibprozess wird als Output-Pipe (Pipe-Advertisement)
bezeichnet. Stimmen diese Pipe-Advertisements überein (Kommunikation erfolgt über
Pipe Binding Query Message), kann die Verbindung zwischen zwei Peers hergestellt
werden. Unter anderem können etwa mehrere Peers Input-Pipes desselben PipeAdvertisement erzeugen und so gleichzeitig von einer Output-Pipe lesen (propagatePipe). Im JXTA-Core sind zur Zeit keine bidirektionalen, synchronen oder streaming
Pipes integriert. Hierzu gibt es aber eine Reihe von Projekten, die bei Bedarf
entsprechende Lösungen anbieten.
<xs:element name="PipeAdvertisment" type="jxta:PipeAdvertisment"/>
<xs:complexType name="PipeAdvertisement">
<xs:sequence>
<xs:element name="Id" type="jxta:JXTAID"/>
<xs:element name="Type" type="xs:string"/>
<xs:element name="Name" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Listing 9.5: JXTA Pipe Advertisement Schema [JXTA v2.0]
Um eine Verbindung über PIP herstellen zu können sind, wiederum zwei MessageTypen notwendig. Diese werden zusammengefasst als Pipe Resolver Message bezeichnet.
Die Unterscheidung zeigt Listing 9.6, indem im ersten Teil der XML-Schema Definition
der PipeResolverMsgType definiert wird.
<xs:element name="jxta:PipeResolver" type="jxta:PipeResolver"/>
<xs:simpleType name="PipeResolverMsgType">
<xs:restriction base="xs:string"> 
<xs:enumeration value="Query"/> 
<xs:enumeration value="Answer"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType
<xs:sequence>
<xs:element
<xs:element
<xs:element
name="PipeResolver">
name="MsgType" type="jxta:PipeResolverMsgType"/>
name="PipeId" type="jxta:JXTAID"/>
name="Type" type="xs:string"/>

<xs:element name="Cached" type="xs:boolean" default="true" minOccurs="0"/>
<xs:element name="Peer" type="jxta:JXTAID" minOccurs="0"/>

<xs:element name="Found" type="xs:boolean"/>

<xs:element name="PeerAdv" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Listing 9.6: JXTA Pipe Resolver Message Schema [JXTA v2.0]
Seite 148
9.1.4.
Peer Resolver Protokoll (PRP)
Das PRP ist zuständig für das Verteilen von generischen Messages an einen oder
mehrere Message-Handler. Weiters muss das PRP eingehende Nachrichten identifizieren.
Eine Message ist aufgrund seiner Semantik mit bestimmten Handlern verknüpft und nicht
wie erwartet mit bestimmten Peers. Diese generieren auch die Antwort auf diverse Query
Messages.
Wiederum ist es möglich, dass mehrere Handler dieselben Nachrichten lesen können.
Um Nachrichten versenden zu können setzt, PRP auf das RVP auf. Mit Hilfe des RVP
wird eine Nachricht an alle Peers einer Gruppe verteilt. Wie auch schon bei den vier
Protokollen zuvor, besteht das PRP aus einer Query Message und einer Response
Message. Diese sind in Listing 9.7 und Listing 9.8 anhand ihrer jeweiligen XML-Schema
Definitionen beschrieben.
Die Resolver Query Message wird eingesetzt, um eine Anfrage an bestimmte
vorgegebene Handler125 zu senden. Die Suchanfrage wird als String serialisiert und von
diversen Handlern ausgewertet. Jede Query besitzt eine eindeutige Id, um auch die
Antworten entsprechend einer Anfrage zuordnen zu können. Beim Verteilungsprozess
wird eine Resolver Query Message an alle lokal bekannten Peers und Rendezvous Peers
geschickt. Ähnlich zum PDP suchen „normale“ Peers im lokalen Cache nach geeigneten
Handlern. Rendezvous Peers propagieren die Message zusätzlich zu allen registrierten
Peers. Jeder Peer, der einen geeigneten Handler im lokalen Cache findet, antwortet mit
einer PRP Response Message.
<xs:element name="ResolverQuery" type="jxta:ResolverQuery"/>
<xs:complexType name="ResolverQuery">
<xs:all>
<xs:element ref="jxta:Cred" minOccurs="0"/>
<xs:element name="SrcPeerID" type="jxta:JXTAID"/>
<xs:element name="HandlerName" type="xs:string"/>
<xs:element name="QueryID" type="xs:string"/>
<xs:element name="HC" type="xs:unsignedInt"/>
<xs:element name="Query" type="xs:anyType"/>
</xs:all>
</xs:complexType>
Listing 9.7: JXTA Resolver Query Message Schema [JXTA v2.0]
<xs:element name="ResolverResponse" type="ResolverResponse"/>
<xs:complexType name="ResolverResponse">
<xs:all>
<xs:element ref="jxta:Cred" minOccurs="0"/>
<xs:element name="HandlerName" type="xs:string"/>
<xs:element name="QueryID" type="xs:string"/>
<xs:element name="Response" type="xs:anyType"/>
</xs:all>
</xs:complexType>
Listing 9.8: JXTA Resolver Response Schema [JXTA v2.0]
Auch beim PRP ist eine Antwort auf eine Anfrage nicht zwingend erforderlich.
Handler müssen die Suchanfrage126 auch verstehen können. Wenn ein Handler mit einer
Suchanfrage nichts anfangen kann, wird er auch keine Antwort erzeugen. Doch ein
mögliches Szenario wäre es, als Problemlösung dem Initiator ein Beispielformat für eine
gültige Suchanfrage zu übermitteln. Dies impliziert einen Lerneffekt der Handler um
gültige Antworten generieren zu können.
125
126
Ein Handler kann für einen oder mehrere Peers zuständig sein, bzw. von diesen verwendet werden.
Suchanfrage in PRP: Ist ein serialisierter String, der auch in einem eigene Definitions-Format erstellt sein kann.
Seite 149
9.1.5.
Rendezvous Protokoll (RVP)
Mit dem RVP ist es möglich, Peers aus anderen Peer Groups anzusprechen. Dazu
verwenden Rendezvous Peers Unicast oder Broadcast Rendezvous Propagate Messages
(siehe Listing 9.10). Um Endlosschleifen bzw. nichtdeterministische Suchen vermeiden
zu können, überprüft jeder Rendezvous Peer seine erhaltenen Anfragen. Die Anfragen
sind mit einem Time-to-Life (TTL) Counter ausgestattet, welcher vom Initiator gesetzt
wird. Bei jedem Durchlauf einer Nachricht durch einen Rendezvous Peer, wird der TTL
Counter dieser Nachricht dekrementiert. Ist dieser Counter bei 0 angelangt, wird die
Nachricht verworfen. Rendezvous Nachrichten sind mit einer eindeutigen ID
gekennzeichnet. Damit können Loopback Detection oder ähnliche Kontrollfunktionen
realisiert werden.
Eine Eigenheit des RVP ist es, dass ein Peer beim Verbindungsaufbau erst beim RVP
Dienst „quasi“ um einen Suchauftrag anfragen muss. Dies ist eine Art Handshake Prinzip,
indem der Peer einem RVP Dienst ein Rendezvous Advertisement (Lease Request)
schickt. Erlaubt der RVP Dienst die Anfrage, schickt er dem Initiator Peer einen Lease
Granted Request zurück. Erst dann kann der eigentliche Verbindungsaufbau zu
entfernten Peers erfolgen. Dieser Handshake trägt zur Aufrechterhaltung der
Netzwerkstabilität bei, indem so nicht benötigte Verbindungen wieder geschlossen
werden können.
Der RVP Dienst schreibt dem Initiator Peer auch vor, in welchem Zeitrahmen er eine
Verbindung benutzen darf. Reicht dieser Zeitrahmen nicht aus, muss der Initiator Peer
den Lease vor dem Ablauf erneuern. Der Lease kann sowohl von Seiten des Peers, als
auch vom RVP Dienst abgebrochen werden. Das Rendezvous Advertisement Schema ist
in Listing 9.9 ersichtlich. Das Rendezvous Advertisement beschreibt einen Rendezvous
Peer für eine bestimmte Peer Group. Aufgrund dieser Information können Rendezvous
Peers lokalisiert werden.
<xs:element name="RdvAdvertisement" type="jxta:RdvAdvertisement"/>
<xs:complexType name="RdvAdvertisement">
<xs:sequence>
<xs:element name="RdvGroupId" type="jxta:JXTAID"/>
<xs:element name="RdvPeerId" type="jxta:JXTAID"/>
</xs:sequence>
</xs:complexType>
Listing 9.9: JXTA Rendezvous Advertisement Schema [JXTA v2.0]
<xs:element name="RendezVousPropagateMessage" type="jxta:RendezVousPropagateMessage"/>
<xs:complexType name="RendezVousPropagateMessage">
<xs:element name="MessageId" type="xs:string"/>

<xs:element name="DestSName" type="xs:string"/>
<xs:element name="DestSParam" type="xs:string"/>
<xs:element name="TTL" type="xs:unsignedInt"/>
<xs:element name="Path" type="xs:anyURI" maxOccurs="unbounded"/>
</xs:complexType>
Listing 9.10: JXTA Rendezvous Propagate Message Schema [JXTA v2.0]
9.1.6.
Endpoint Routing Protokoll (ERP)
P2P Netzwerke wie, mit JXTA realisiert, können oft spontan ihre Struktur ändern.
Router-Peers werden zu beliebigen Zeiten dem Netzwerk hinzugefügt, bzw. vom
Netzwerk entfernt. Dies führt zu nicht deterministischen Routing Problemen. Weitere
Probleme stellen Firewalls dar. Diese können zwar von innen nach außen direkt
überbrückt werden, aber nicht umgekehrt, da die Verbindungen unidirektional sind.
Seite 150
Das ERP stellt eine Reihe von Request und Response Messages zur Verfügung, um
das Message Routing zwischen zwei Endpunkten im Netzwerk zu ermöglichen. Wenn ein
Peer eine Verbindung zu einem anderen Endpunkt aufbauen möchte, wird zuerst der
lokale Cache nach einer entsprechenden Route durchsucht. Wenn keine Route vorhanden
ist, sendet das ERP eine Route Query Message (siehe Listing 9.12) an alle benachbarten
(mit dem Peer direkt verbundenen Peers) Router-Peers. Die JXTA Spezifikation erlaubt
dabei die Verwendung verschiedener Transportprotokolle, wie z.B. TCP/IP, UDP, TLS,
HTTP oder BEEP.
Wenn nun ein Router-Peer eine Route zum Endpunkt bei sich lokal im Cache hat,
sendet er diese in Form einer Route Response Message (siehe Listing 9.13) retour zum
Initiator Peer. Die Antwort enthält eine Auflistung aller Routing-Peers, die die
Verbindung vom Initiator-Peer zum Endpunkt herstellen. Findet ein Router-Peer lokal bei
sich keine entsprechende Route zum Endpunkt, verschickt dieser wiederum eine Route
Query Message an seine benachbarten Router-Peers usw. bis entweder eine Route
gefunden wurde oder die Nachricht ungültig wird. Wurde eine passende Route gefunden,
kann die Message anhand der Route Query Message entlang der vorgeschlagenen Route
verschickt werden. Dabei wird jeder Durchlauf einer Nachricht bei Peers in der Nachricht
vermerkt. Mit diesen Informationen kann man Loop-Detection realisieren oder
rücklaufende Nachrichten verwerfen. Zusätzlich sind diese „Marker“ hilfreich bei der
Erstellung diverser Routing Daten.
Das ERP stellt nur einfache Routing Dienste zur Verfügung. Will man intelligentere
Router implementieren, müssen diese in einer höheren Schicht angesiedelt werden. JXTA
stellt Basisdienste für das Erstellen und Verwalten von Routing Daten bereit. Die Routing
Daten werden wiederum als Advertisements ausgetauscht. In Listing 9.11 ist das Route
Advertisement Schema ersichtlich. Wie lange eine Route gültig ist, bestimmt der HopsTo-Life (HTL) Counter. Dieser wird vom Initiator gesetzt.
<xs:element name="APA" type="jxta:APA"/>
<xs:complexType name ="jxta:APA">
<xs:sequence>
<xs:element name="EA" type="jxta:JXTAID" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="RA" type="jxta:RA"/>
<xs:complexType name ="jxta:RA">
<xs:sequence>
<xs:element name="DstPID" type="xs:anyURI"/>
<xs:element ref="jxta:RA"/>
<xs:element name="Hops" minOccurs="0">
<xs:sequence>
<xs:element ref="jxta:APA" maxOccurs="unbounded"/>
</xs:sequence>
</xs:element>
</xs:sequence>
</xs:complexType>
Listing 9.11: JXTA Route Advertisement Schema [JXTA v2.0]
<xs:element name="ERQ" type="jxta:ERQ"/>
<xs:complexType name ="jxta:ERQ">
<xs:sequence>
<xs:element name="Dst" type="jxta:JXTAID"/>
<xs:element name="Src">
</xs:element>
</xs:sequence>
</xs:complexType>
Listing 9.12: JXTA Route Query Message Schema [JXTA v2.0]
Seite 151
<xs:element name="ERR" type="jxta:ERR"/>
<xs:complexType name ="jxta:ERR">
<xs:sequence>
<xs:element name="Dst">
</xs:element>
<xs:element name="Src">
</xs:element>
</xs:sequence>
</xs:complexType>
Listing 9.13: JXTA Route Response Message Schema [JXTA v2.0]
9.2.
Aufbau von JXTA Advertisements
Wie bereits einleitend in diesem Kapitel erwähnt, sind Advertisements strukturierte
Meta-Daten Dokumente. Diese werden von den jeweiligen JXTA Protokollen verwendet,
um verschiedene Ressourcen zu beschreiben. Als Ressource werden z.B. Peers, Peer
Groups, Pipes, Services und andere Typen angesehen. Die Dokument Struktur kann als
Baum abgebildet werden. Die Notation der Struktur ist in XML gehalten. Jedes Element
kann reine Daten beinhalten oder auch der Knoten für eine Unterstruktur sein. Zusätzlich
können bei Elementen (Knoten) auch spezifische Attribute (Key-Value String Paare)
deklariert werden. Diese Attribut Key-Value Paare stellen die eigentlichen Metadaten dar.
Mit diesen Metadaten wird die Dateninformation (Semantik) der Elemente näher
beschrieben.
Durch die XML-Notation der Advertisement Struktur ergeben sich viele Vorteile. Die
gemeinsame Präsentation von Inhalt und Metainformationen mit einem universellen
standardisierten Format (XML) ist dabei ein positiver Nebeneffekt. Neben den bekannten
Vorzügen von XML wie z.B. der Programmiersprachen- bzw. Plattformunabhängigkeit,
die selbst beschreibende Notation, dem streng typisierten Inhalt und der korrekten Syntax
(DTS, Schema), liegt der größte Vorteil von XML in der einfachen Portierbarkeit des
Codes. So können verschiedene Encodings wie HTML oder WML eingesetzt werden, um
verschiedenste Komponenten den Zugriff auf die Advertisements zu gewähren.
Ressourcen müssen nicht zwingend XML verstehen.
Ein veröffentlichtes Advertisement besitzt eine bestimmte Gültigkeitsdauer. Während
dieser Zeit darf das Advertisement nicht verändert werden. Soll ein Advertisement
verändert werden, muss es neu veröffentlicht werden. Im JXTA Core sind fünf
verschiedene Basis Advertisement Typen definiert. Services können bei Bedarf spezielle
Subtypen ableiten oder gänzlich neue erstellen. Die JXTA Basis Advertisement Typen
sind:
•
•
•
•
•
Peer Advertisement
Peer Group Advertisement
Module Class Advertisement
Module Specification Advertisement
Module Implementation Advertisement
Seite 152
9.2.1.
Peer Advertisement
Das Peer Advertisement beschreibt ein Peer und die einer Peer Group zur Verfügung
gestellten Ressource. Wie alle Advertisements besteht die Beschreibung aus einem
eindeutigen Identifier <PID>, der Group-ID <GID>, einem optionalen Namen <Name> und
einer informativen Beschreibung <Desc>. Diese Information kann bei der Suche nach
einem Advertisement hilfreich sein, indem diese Informationen (Keywords) entsprechend
indiziert werden. Zusätzlich können noch Randbedingungen (Service Section) <Svc> für
spezielle Dienste (z.B. Rendezvous-Peer) definiert werden. In Listing 9.14 ist die
Definition eines Peer Advertisement anhand des zugehörigen XML Schema dargestellt.
<xs:element name="PA" type="jxta:PA"/>
<xs:complexType name="PA">
<xs:sequence>
<xs:element name="PID" type="JXTAID"/>
<xs:element name="GID" type="JXTAID"/>
<xs:element name="Desc" type="xs:anyType" minOccurs="0"/>
<xs:element
name="Svc"
type="jxta:serviceParams"
maxOccurs="unbounded"/>
<xs:sequence>
</xs:complexType>
minOccurs="0"
Listing 9.14: JXTA Peer Advertisement Schema [JXTA v2.0]
9.2.2.
Peer Group Advertisement
Um Peer Groups ansprechen zu können, wird entsprechend nach Peer Group
Advertisements gesucht. Im Peer Group Advertisement sind die Ressourcen (Services,
Eigenschaften, etc.) einer Peer Group beschrieben. Die Peer Group-ID <GID> ist weltweit
eindeutig und kanonisch aufgebaut. Eine Peer Group stellt implizit ein Service dar.
Entsprechend muss für diesen Service eine Peer Group Specification ID angegeben
<MSID> werden. Diese ID ist eine abstrakte Referenz für die eigentliche Modul
Spezifikation. Die Modul Spezifikation und dessen Implementierung wird über eigene
Advertisements (ModuleSpecAdvertisement und ModuleImplAdvertisement) näher
beschrieben. Neben dem optionalen Namen <Name>, der die Peer Group benennt, ist die
nähere Beschreibung der Peer Group in einer eigenen optionalen Description <Desc>
festgelegt. In der Service Section <Svc> können wiederum spezifische Randbedingungen
zur Verwendung der diversen Dienste (z.B. Membership Service zur Authentifikation)
festgelegt werden. In Listing 9.15 ist die Definition des Peer Group Advertisement
anhand dem zugehörigen XML Schema dargestellt.
<xs:element name="PGA" type="jxta:PGA"/>
<xs:complexType name="PGA">
<xs:sequence>
<xs:element name="GID" type="jxta:JXTAID"/>
<xs:element name="MSID" type="jxta:JXTAID"/>
<xs:element
name="Svc"
type="jxta:serviceParam"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Listing 9.15: JXTA Peer Group Advertisement Schema [JXTA v2.0]
minOccurs="0"
Seite 153
9.2.3.
Module Class Advertisement
JXTA Module kapseln die funktionalen Einheiten mit einfachen spezifischen
Interfaces. Um Module unabhängig von ihrer Funktionalität verwalten zu können
(initialisieren, starten, beenden), müssen alle Module ein bestimmtes JXTA Interface
implementieren. Will man die Funktionalität eines Moduls nutzen, muss erstens die
Funktionalität eines Moduls bekannt sein, und zweitens muss das Modul zur Laufzeit
auffindbar sein. Module können sich im Laufe der Zeit ändern. D.h. es können
verschiedene Versionen einer Modulklasse existieren. Da das JXTA Framework
Plattform- und Programmiersprachen unabhängig entwickelt wurde, können Module auch
in technologisch unterschiedlichen Implementierungen vorliegen. Um die
Aufgabenbereiche von Modulen erfragen zu können, bedarf es ebenfalls unabhängiger
Mechanismen. Diese wichtigen Anforderungen werden mit Hilfe von drei speziellen
Modul Advertisements abgedeckt.
Das Module Class Advertisement ist eine recht einfache formale Beschreibung eines
JXTA Moduls. Es beschreibt lediglich die Aufgaben der Modulklasse. Vorwiegend wird
es zur Gruppierung verschiedener Module eingesetzt. Es wird das lokale Verhalten der
Klasse definiert und die Schnittstellen für das JXTA API vorgegeben. Jedoch ist die
Verwendung des Module Class Advertisement optional. Es gibt keine Vorschreibung wie
die Schnittstellen-beschreibung des Moduls aussieht. Die Beschreibung ist entsprechend
formal gehalten. Das Module Class Advertisement (implizit jedes Modul) wird mit einer
eindeutigen Module Class ID <MCID> gekennzeichnet. Über diese Module Class ID kann
ein Namensraum für gleichartige Modulklassen geschaffen werden. Neben dem
optionalen Namen <Name>, kann optional auch die bereits erwähnte formale Modul
Beschreibung <Desc> angegeben werden. In Listing 9.16 ist die Definition eines Module
Class Advertisement anhand des zugehörigen XML Schema dargestellt.
<xs:element name="MCA" type="jxta:MCA"/>
<xs:complexType name="MCA">
<xs:sequence>
<xs:element name="MCID" type="jxta:JXTAID"/>
<xs:element name="Name" type="xs:string" minOccurs="0"/?
</xs:sequence>
</xs:complexType>
Listing 9.16: JXTA Module Class Advertisement Schema [JXTA v2.0]
9.2.4.
Module Specification Advertisement
Das Module Specification Advertisement kapselt die Funktionalität eines Moduls vom
Übertragungsformat und kann so als Modulinterface angesehen werden. Weiters ist im
Module Specification Advertisement festgelegt, wie ein Modul aufgerufen werden muss,
und wie das Modul zu verwenden ist. Weiters legt das Module Specification
Advertisement fest, wie eine Peer Group gekennzeichnet werden muss, um ein
entsprechendes Modul anbieten zu können. Alle im JXTA Core enthaltenen Services
(z.B. Discovery-, Membership-, Resolver-Service) sind solche ausgezeichneten Module.
Ein Modul kann auf verschiedene Weise verwendet werden. Direkte Instanzierung oder
remote über Pipes, um z.B. über ein Proxy Modul Firewalls überbrücken zu können. Für
die zweite Variante (Kapselung mittels Pipe) muss zusätzlich ein Module Specification
Advertisement für das Proxy Modul erstellt werden.
Ein Module Specification Advertisement besitzt eine eindeutige ModuleSpecID
<MSID> und eine Versionsnummer <Vers>. Optional sind wiederum der Advertisement
Name <Name> und eine formale Beschreibung <Desc> für das Advertisement. Zusätzliche
Seite 154
Metainformationen, wie Creator <Crtr> oder Specification Url <SURI> (verweist auf die
eigentliche Dokumentspezifikation) und frei wählbare Parameter <Parm>, können im
Advertisement definiert werden. Um eine Verbindung mit dem Modul herstellen zu
können, wird mit <jxta:PipeAdvertisement> eine Input Pipe anhand eines Pipe
Advertisement (siehe Abschnitt 9.1.3) festgelegt. Optional kann ein Modul auch als
Proxy ausgelegt werden <Proxy> oder Authentifikation <Auth> fordern. Die beiden
letzten Optionen können jedoch rekursive Deklarationen bewirken. In Listing 9.17 ist die
Definition eines Module Specification Advertisement anhand des zugehörigen XML
Schema dargestellt.
<xs:element name="MSA" type="jxta:MSA"/>
<xs:complexType name="MSA">
<xs:sequence>
<xs:element name="Vers" type="xs:string"/>
<xs:element name="Crtr" type="xs:string" minOccurs="0"/>
<xs:element name="SURI" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Parm" type="xs:anyType" minOccurs="0"/>
<xs:element ref="jxta:PipeAdvertisement" minOccurs="0"/>
<xs:element name="Proxy" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Auth" type="jxta:JXTAID" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Listing 9.17: JXTA Module Specification Advertisement Schema [JXTA v2.0]
9.2.5.
Module Implementation Advertisement
Das Module Implementation-Advertisement beschreibt die konkrete Implementierung
einer Modul Spezifikation. Identifiziert wird eine Modul Implementierung über die
eindeutige Module Specification ID <MSID>. D.h. eine Modul Implementierung besitzt
selbst keine eigene ID. Die Modul Compatibility (Environment, in dem das Modul
ausgeführt werden kann) <Comp> beschreibt den Zugriff auf das Modul und den
Ladevorgang des Moduls. Der eigentliche Code des Moduls wird mit <Code> deklariert.
Ist das Modul als Java Klasse ausgeführt, beinhaltet dieses Element den voll
qualifizierten Klassennamen und die Schnittstellenbeschreibung der Klasse. In anderen
Fällen kann der Code auch direkt enthalten sein. Zusätzlich zur Codedeklaration kann
optional auch eine Packagedeklaration für den Code mit einer Url <PURI> angegeben
werden. Das kann z.B. ein zusätzliches downloadbares Package sein. Weitere optionale
Elemente sind die Angabe des Providers der Implementierung <Prov>, eine zusätzliche
Beschreibung <Desc> und eventuelle Übergabeparameter <Parm>, die vom Code
ausgewertet werden können. In Listing 9.18 ist die Definition eines Module
Implementation-Advertisement anhand des zugehörigen XML Schema dargestellt.
<xs:element name="MIA" type="jxta:MIA"/>
<xs:complexType name="MIA">
<xs:sequence>
<xs:element name="Comp" type="xs:anyType"/>
<xs:element name="Code" type="xs:anyType"/>
<xs:element name="PURI" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Prov" type="xs:string" minOccurs="0"/>
<xs:element name="Parm" type="xs:anyType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Listing 9.18: JXTA Module Implementation Advertisement Schema [JXTA v2.0]
Seite 155
9.2.6.
Implementierung von Advertisements
Advertisements sind strukturierte Dokumente. Der Dokument-Typ wird mit der
Angabe des MIME-Type festgelegt. Die Funktionalität bzw. die Behandlung dieser
Dokumenttypen wird in separaten Klassen durchgeführt. Zurzeit existieren im JavaPackage net.jxta.impl.document des JXTA Core die Klassen BinaryDocument,
DOMXMLDocument, LiteXMLDocument, PlainTextDocument, TextDocumentCommon,
XMLDocumentCommon. Neben den fünf zuvor beschriebenen Basis-Advertisements
existieren zusätzlich bereits elf weitere spezifische Advertisements:
net.jxta.impl.protocol.AccessPointAdv
net.jxta.impl.protocol.DiscoveryConfigAdv
net.jxta.impl.protocol.HTTPAdv
net.jxta.impl.protocol.PipeAdv
net.jxta.impl.protocol.PlatformConfig
net.jxta.impl.protocol.PSEConfigAdv
net.jxta.impl.protocol.RdvAdv
net.jxta.impl.protocol.RdvConfigAdv
net.jxta.impl.protocol.RouteAdv
net.jxta.impl.protocol.SignedAdv
net.jxta.impl.protocol.TCPAdv
Die unterstützten Advertisements sind in der Datei config.properties des JavaPackage net.jxta.impl eingetragen. Die Advertisements können von der
Advertisement-Factory bei Bedarf zur Laufzeit angefordert werden. Zur Erzeugung von
Advertisements bietet die Klasse net.jxta.document.AdvertisementFactory vier
statische Methoden an. Aufgrund des offenen Typen-Ansatzes für Advertisements, im
Unterschied zu ID-Factory (sechs fixe Typen), ist die Advertisement-Factory generisch
aufgebaut. Die Art des Advertisements wird vom MIME/Type und vom Quellcode des
Advertisements bestimmt.
Die Advertisement-Factory erzeugt entsprechend auch ein allgemeines abstraktes
Advertisement. Um ein spezifisches Advertisement verwenden zu können, überschreiben
die Sub-Advertisement-Klassen entsprechend die abstrakten Methoden. Die abstrakte
Advertisement Klasse liefert mit der Methode getAdvertisementType den
entsprechenden Advertisement-Typ, für den anschliesenden notwendigen Type-Cast. Die
Unterscheidung in der JXTA-Package Struktur erfolgt anhand der Zwischenebene impl.
D.h. sämtliche Definitionen und abstrakte Klassen sind im JXTA Core API-Source-Baum
(api/src/net/jxta) enthalten. Die entsprechenden Implementierungen sind im ImplSource-Baum (impl/src/net/jxta/impl) enthalten.
Um Advertisements suchen und veröffentlichen zu können, bedient man sich dem
Discovery Service. Die abstrakte Definition bzw. das Interface für das Discovery Service
ist wiederum im API-Source-Baum enthalten
(net.jxta.discovery.DiscoveryService). Die entsprechende Implementierung ist im
Package net.jxta.impl.discovery.DiscoveryServiceImpl enthalten. Diese Klasse
enthält zwei wichtige Methoden. Mit der Methode publish() kann ein Advertisement
im lokalen Cache abgelegt werden. Um ein Advertisement auch verbreiten zu können,
kann mit der Methode remotePublish() das Advertisement in der bekannten Umgebung
mittels Broadcast bekannt gemacht werden. Für beide Methoden kann als zusätzlicher
Parameter eine LifeTime angegeben werden.
Seite 156
Der Defaultwert für den lokalen Cache ist auf 1 Jahr festgelegt:
DEFAULT_LIFETIME=1000L*60L*60L*24L*365L.
Der Defaultwert für den Broadcast ist auf 2 Stunden festgelegt:
DEFAULT_EXPIRATION=1000L*60L*60L*2L.
Die Suche nach Advertisements kann über zwei verschiedene Möglichkeiten realisiert
werden. Bei einer aktiven Suche nach Advertisements muss der lokale Cache oder der
Cache der bekannten Peer Groups durchsucht werden. Wie schon beim Veröffentlichen
von Advertisements bietet das Discovery Service auch hier zwei geeignete Methoden an;
getLocalAdvertisement und getRemoteAdvertisement. Bei der zweiten Methode
erfolgt die Suche implizit nach dem Observer-Pattern. Hierzu meldet man beim
Discovery Service spezielle Discovery-Listener an. Diese benachrichtigen die
Implementierungs-Klasse des Discovery-Listener über alle eintreffenden Advertisements.
9.3.
Einsatz von JXTA Services
Die JXTA Services sind in der JXTA Framework Architektur zwischen den JXTA
Applikationen und dem JXTA Core angesiedelt (siehe dazu Abbildung 6.2).
Grundsätzlich wird versucht mit Hilfe der Services den JXTA Core für Applikationen
einfach zugänglich zu machen. Dieser Weg ist jedoch nicht zwingend vorgeschrieben. So
können etwa JXTA Core Elemente, wie z.B. Pipes, auch direkt von Applikationen
verwendet werden. Services erweitern im eigentlichen Sinne lediglich die
Aufgabenbereiche. Einige JXTA Standard Dienste wurden bereits kurz erwähnt. Zu den
JXTA Core Diensten gehören das Discovery Service, das Pipe Service, das Membership
Service, das Peer Info Service, das Resolver Service, das Rendezvous Service und das
Endpoint Service.
Services hängen unmittelbar mit ihren jeweiligen Modulen zusammen. Implizit sind
Services erweiterte Module. Die Erweiterung bezieht sich jedoch lediglich auf die
Modulschnittstelle. Die drei allgemein gültigen Methoden zur Verwaltung der Module
(init, start, stop) gelten so auch für Services. Über zwei zusätzliche Methoden kann ein
Modul-Implementation-Advertisement (getImplAdvertisement) angefordert werden
bzw. eine neue Objekt Referenz der Service Implementierung (getInterface) erzeugt
werden.
Wie einleitend in Abschnitt 9.2.2 beschrieben, sind Services in Peer Groups integriert.
Jedoch kann man bereits bestehende Peer Groups nicht mit neuen Services erweitern. Es
muss dazu eine neue Peer Group erzeugt werden, die zusätzlich zu den bereits
vorhandenen Services die neuen Services integriert. Dazu muss lediglich das
entsprechende Peer Group Advertisement kopiert und erweitert werden. Mit diesem
neuen Peer Group Advertisement kann so eine neue Peer Group erzeugt und
veröffentlicht werden.
9.4.
xFIND JXTA Testimplementierung
Im Zuge der Analyse des JXTA Protokoll-Frameworks wurden zwei
Testimplementierungen erstellt. In der ersten Testimplementierung wird ein einfacher
Nachrichtenaustausch über JXTA-Pipes zwischen einem Server-Peer und einem ClientPeer realisiert. Dieser Nachrichtenaustausch wird anhand des Blockdigrammes in
Abbildung 9.2 vereinfacht visualisiert. In der zweiten Testimplementierung erfolgt der
Seite 157
Nachrichtenaustausch über die Vermittlung eines eigens generierten Services zwischen
zweier gleichberechtigten Peers.
Für beide Testimplementierungen gilt, dass für das Veröffentlichen der verschiedenen
Advertisements und der Services das Discovery Service eingesetzt wird. Services werden,
wie in Abschnitt 9.3 beschrieben, in Peer Groups integriert. Deshalb muss zu Beginn das
entsprechende JXTA Environment geladen bzw. gestartet werden. Hierzu wird von der
PeerGroupFactory die NetPeerGroup angefordert. Jede Peer Group ist zumindest auch
dieser NetPeerGroup oder der WorldPeerGroup bekannt. Nach der Erzeugung bzw.
Anforderung der NetPeerGroup, wird über die Methode getDiscoveryService() das
Discovery Service der NetPeerGroup angefordert. Zusätzlich können auch verschiedene
Advertisements geladen werden. Diese grundlegenden Schritte sind exemplarisch in
Listing 9.19 kurz zusammengefasst dargestellt.
public void startJxta() {
try {
// create, and Start the default jxta NetPeerGroup
netPeerGroup_ = PeerGroupFactory.newNetPeerGroup();
} catch (PeerGroupException e) {
System.out.println("startup error: NetPeerGroup creation failed");
System.exit(0);
}
discoveryService_ = netPeerGroup_.getDiscoveryService();
}
Listing 9.19: JXTA Framework starten
NetPeerGroup
Advertisements
Client
Pipe
Server
Abbildung 9.2: Blockdiagramm der JXTA Client-Server Testimplementierung
Will man nur grundlegende JXTA Dienste oder Module testen, kann man ohne
weiteres mit der NetPeerGroup oder der WorldPeerGroup arbeiten. Dieser einfache
Aufbau wurde auch in der ersten Testimplementierung für eine einfache Client-Server
Anwendung
herangezogen.
Der
Client
fordert
vom
Server
ein
ModuleSpecAdvertisement an, das vom Server entsprechend veröffentlicht wurde. Der
Server bedient sich, wie eingangs des Abschnittes erwähnt, am Discovery Service. Das
ModuleSpecAdvertisement
wird
mit
der
Discovery
Service
Methode
discoveryService_.publish(mds_adv) lokal gespeichert. Im Broadcast-Verfahren
wird mittels der Methode discoveryService_.remotePublish(mds_adv) das
ModuleSpecAdvertisement im Peer-Netzwerk verbreitet.
Anschließend wird über das Pipe-Service der NetPeerGroup eine Input-Pipe mit
einem
eigenen
Pipe-Advertisement
angefordert.
Nachdem
das
ModuleSpecAdvertisement veröffentlicht und die Input-Pipe vom JXTA Pipe-Service
Seite 158
gebunden wurde, wartet der Server auf eingehende Messages. Der Service-Client
versucht als Erstes über die aktiven Such-Methoden des Discovery Service
getLocalAdvertisement
und
getRemoteAdvertisement
das
entsprechende
ModuleSpecAdvertisement (JXTASPEC:XFIND-JXTA-Server) zu finden. Nach der
Referenzierung des ModuleSpecAdvertisement wird eine Output-Pipe vom JXTA PipeService erzeugt. Das dafür notwendige Pipe-Advertisement wird mit
mds_adv.getPipeAdvertisement() von der ModuleSpecAdvertisement Referenz
angefordert. Über diese Output-Pipe wird anschließend eine Nachricht vom Client zum
Server gesandt.
Abbildung 9.3 zeigt das Klassendiagramm für die beiden Beispielanwendungen.
Ausgegraut dargestellt sind die Diagramme und Packages der Testimplementierung eins.
Die Klasse CreatePeerGroup und GenerateID wird von beiden Testimplementierungen
genutzt, und wird deshalb an einer zentralen Position dargestellt.
Abbildung 9.3: Klassendiagramm der xFIND JXTA Testimplementierung
Seite 159
Um die Funktionalität der JXTA Dienste ausnutzen zu können, müssen neue Peer
Groups erzeugt werden und alle benötigten Dienste bei diesen neuen Peer Groups
eingetragen werden. Unter zu Hilfenahme der IDFactory wird eine neue Peer Group ID
angefordert. Mit dieser eindeutigen Peer Group ID wird eine neue Peer Group in der
NetPeerGroup eingefügt.
PeerGroupID peer_group_id = IDFactory.newPeerGroupID();
PeerGroup new_group = netPeerGroup_.newGroup(…, peer_group_id,…)
Damit die neue Peer Group auch auffindbar ist, muss sie wiederum mit dem Discovery
Service veröffentlicht werden. Hierzu wird von der neuen Peer Group das
PeerGroupAdvertisement angefordert und lokal bzw. remote verbreitet.
PeerGroupAdvertisement pg_adv = new_group.getPeerGroupAdvertisement();
discoveryService_.publish(pg_adv);
discoveryService_.remotePublish(pg_adv);
Im nächsten Schritt wird ein neues Service erzeugt und anschließend in der neuen Peer
Group integriert. Das Erzeugen von JXTA Services kann nach einer Art Kochrezept
erstellt werden. Der Ablauf zur Erzeugung eines neuen JXTA Dienstes sieht wie folgt
aus:
•
•
•
•
•
•
•
Der Algorithmus eines Dienstes wird in einer neuen Klasse eingebettet.
Diese Klasse muss das JXTA Interface net.jxta.service.Service implementieren.
Zusätzlich soll für diese neue Klasse ein eigenes Interface erstellt werden.
Dieses spezielle Interface wird dann beim Kommunikationsaufbau ausgetauscht und
bietet die eigentliche Service-Funktionalität über diese Schnittstelle an.
Um ein Service veröffentlichen zu können, müssen noch einige verschiedene
Advertisements erzeugt werden.
Die erzeugten Advertisements müssen mit dem Discovery Service veröffentlicht
werden.
Das neue Service wird beim Erstellen einer neuen Peer Group als
ModuleImplAdvertisement registriert.
In der zweiten Testimplementierung wird das neue Service, wie in Listing 9.20
zusammengefasst, erzeugt. Das impl_adv wird als eine Art Mustervorlage für das
eigentliche ModuleImplAdvertisement von der NetPeerGroup angefordert. Um die drei
notwendigen Advertisements erstellen zu können, bedient man sich der in Abschnitt 9.2.6
beschriebenen AdvertisementFactory. Um ein zusätzliches Service für eine Peer Group
erstellen zu können, muss man auch die bereits vorhandenen Services der NetPeerGroup
(gilt nur für die Testimplementierung) kennen. Dazu werden StdPeerGroupParamAdv
Parameter erzeugt und die bereits vorhandenen Services angefordert. Diese Services sind
in einer Hashtable abgelegt. Anschließend wird das neue Service in dieser Hashtable
eingetragen und erneut im ModuleImplAdvertisement der NetPeerGroup vermerkt. Alle
drei Advertisements werden anschließend sowohl lokal als auch remote über das
Discovery Service veröffentlicht.
Nachdem das Service kreiert wurde, muss es noch einer neuen Peer Group
hinzugefügt werden. Dazu wird beim Erzeugen der neuen Peer Group das erweiterte
ModuleImplAdvertisement der NetPeerGroup als Initialwert übergeben und
anschließend veröffentlicht. Listing 9.20 zeigt diesen grundsätzlichen Ablauf im Detail.
Seite 160
public void createPeerGroup() throws Exception, PeerGroupException {
String name = "xFINDPeerGroup";
String descr = "An example xFIND peer group";
ModuleImplAdvertisement group_impl_adv = netPeerGroup_
.getAllPurposePeerGroupImplAdvertisement();
ModuleClassAdvertisement module_class_adv = createModuleClassAdv();
ModuleSpecAdvertisement module_spec_adv = createModuleSpecAdv();
ModuleImplAdvertisement module_impl_adv =
createModuleImplAdv(group_impl_adv, module_spec_adv);
StdPeerGroupParamAdv params = new StdPeerGroupParamAdv(group_impl_adv.getParam());
// Get the services from the parameters.
Hashtable services = params.getServices();
services.put(module_class_adv.getModuleClassID(), module_impl_adv);
params.setServices(services);
group_impl_adv.setParam((StructuredDocument) params
.getDocument(new MimeMediaType("text", "xml")));
group_impl_adv.setModuleSpecID(PEER_GROUP_SPEC);
// Publish the Module Class and Specification Advertisements.
discoveryService_.publish(module_class_adv);
discoveryService_.remotePublish(module_class_adv);
discoveryService_.publish(module_spec_adv);
discoveryService_.remotePublish(module_spec_adv);
discoveryService_.publish(group_impl_adv);
discoveryService_.remotePublish(group_impl_adv);
newGroup_ = netPeerGroup_.newGroup(PEER_GROUP_ID, group_impl_adv, name, descr);
PeerGroupAdvertisement groupAdv = newGroup_.getPeerGroupAdvertisement();
discoveryService_.publish(groupAdv);
discoveryService_.remotePublish(groupAdv);
}
Listing 9.20: Erstellen eines neuen JXTA Service
Das Auffinden des neuen Service bzw. des neuen Moduls erfolgt wie in Abschnitt
9.2.6 beschrieben implizit über die Suche nach den Advertisements. In diesem Fall wird
von der neuen Peer Group das Lookup-Service aktiviert. Als Suchparameter wird die
ModulClassID des neuen Service angegeben. Das Lookup-Service liefert das ServiceInterface. Bei diesem Service kann ein Service-Listener angemeldet werden, der bei
Erhalt von Anfragen und Nachrichten benachrichtigt wird (die vorgesehene Listener
Methode wird ausgeführt).
xFINDTestService xfind_test_service = (xFINDTestService) newGroup_
.lookupService(MODUL_CLASS_ID);
xfind_test_service.addListener(the_xfind_service_listener);
Eine genauere Beschreibung der Testimplementierung ist über die Java
Dokumentation des Java Quellcodes ersichtlich. Der Java Quellcode ist, wie auch der
Java Quellcode der anderen Testimplementierungen, auf der beiliegenden CD-ROM
gespeichert.
Seite 161
9.5.
Schlussbemerkung
Grundsätzlich ist zu sagen, dass der Transfer Overhead von XML-basierten
Protokollen natürlich auch auf JXTA zutrifft. So soll man auch die Basis Funktionalität
die JXTA bietet entsprechend ausnutzen. Eine reine Client-Server Architektur
aufzubauen, wie in der ersten Testimplementierung aus Abschnitt 9.4 ersichtlich, führt
sicherlich zu keinen vernünftigen Ergebnissen. Vielmehr gilt es die Vorzüge des offenen
Peer-to-Peer Ansatzes zu nutzen. Bestehende Applikationen können einfach erweitert
werden, um als JXTA Peer zu fungieren, oder einen speziellen Dienst über das JXTA
Netzwerk anzubieten. Für die xFIND Architektur bedeutet dies, das JXTA nicht in der
Datenübertragung einzusetzen ist. Dies zeigt der Vergleich von xFIND mit BEEP im
Abschnitt 8.5. BEEP ist standardisiert und ein reines Datenübertragungsprotokoll
spezifiziert. JXTA ist dafür nicht entwickelt oder ausgelegt worden.
Speziell für den Bereich Information Retrieval bietet JXTA jedoch einfache Lösungen
an, um Ressourcen in verteilten, dezentralisierten Umgebungen auffinden und nutzen zu
können. Der Vorteil der JXTA Protokollspezifikation liegt eindeutig in der offenen und
unabhängigen Entwicklung bezüglich zugrunde liegender Plattform und
Programmiersprache. Es existiert zurzeit zwar nur eine Java Referenz Implementierung,
jedoch wird bereits an einer JXTA Entwicklung für C++, C# oder Perl gearbeitet. Zudem
gibt es bereits den Versuch einer Anbindung mittels JXMEShare127 über JXTA J2ME128
an mobile Endgeräte. JXTA ist auch an keine bestimmte Übertragungstechnologie wie
z.B. TCP/IP gebunden. JXTA abstrahiert in gewisser Weise den Kommunikationsaufbau
und die Datenübertragung.
Diese Abstraktion ist einer der Gründe, warum JXTA die Entwicklung von Peer-toPeer nahen Applikationen vereinfacht. Die Widerverwendbarkeit der Core Module lassen
schnelle und einfach zu realisierende Lösungen zu. Der Kommunikationsaufbau und die
Organisation der verschiedenen Module werden durch den Einsatz von JXTA
vereinfacht. Somit kann bei der Produktentwicklung mehr Wert auf die Entwicklung der
Produktfunktionalität von verteilten Anwendungen gelegt werden.
Mit Hilfe der JXTA Protokolle wird der Versuch unternommen, grundlegende
Methoden wie die Verwaltung von Peer und Peer Gruppen, sowie die Suche und das
Anbieten verschiedener Ressourcen in P2P Netzwerken, zu standardisieren. Jedoch sind
die JXTA Protokolle zum Zeitpunkt der Erstelleung der vorliegenden Arbeit nicht
standardisiert. Der offene Frameworkansatz von JXTA bietet aber zusätzlich
Möglichkeiten an, bereits standardisierte Technologien zu verwenden. So kann anstatt der
JXTA Such Dienste auch WSDL (siehe Abschnitt 4.8.2) oder statt des HTTP Daten
Transportes das BEEP Protokoll (siehe Abschnitt 8) in der Übertragungseinheit eingesetzt
werden. XML wird einerseits als Beschreibungssprache für Advertisements eingesetzt
und andererseits wird XML bei der Kommunikation und bei der Datenübertragung
verwendet. XML ist ein funktionierender Standard mit vielerlei Vorzügen. Dazu gehören
die einfache Lesbarkeit der Struktur und der Daten, sowie die einfache Entwicklung und
Wartung des Inhaltes. Zudem ist mit der Angabe des Zeichensatz-Encodings und der
Inhaltsdeklarierung über die MIME-Type Spezifikation einerseits eine textbasierte
Nachrichtenübermittlung möglich, andererseits können auch Daten im Binärformat
übertragen werden.
127
JXMEShare: M. Kubek; Realisierung einer mobilen P2P-Anwendung mittels JXTA für J2ME; Technische Universität
Ilmenau
128
JXTA for J2ME: JXTA Projekt http://jxme.jxta.org/
Seite 162
Neben den vielen Vorzügen von JXTA gibt es natürlich auch einige Nachteile. Die
große Flexibilität des Protokollframeworks schlägt sich entsprechend auf die Effizienz im
Datendurchsatz wieder. Im Rahmen dieser Arbeit wurden explizit keine JXTA
Performance-Messungen durchgeführt. So kann bezüglich der Performance von JXTA
nur auf diverse Quellen verwiesen werden, wie z.B. die Arbeit ‚JXTA Pipes
Performance’ von Jean-Marc Seigneur. Es existieren für JXTA auch diverse Projekte der
JXTA-Community, in denen verschiedene JXTA Core Bereiche bezüglich Performance
untersucht wurden. Dazu gehört unter anderem das JXTA Projekt ‚bench’129. Dieses
Projekt gilt als zentrales Projekt für Benchmarktests verschiedener JXTA Bereiche.
129
bench: http://bench.jxta.org/
Seite 163
Kapitel 10
10. Verbesserungsvorschläge für das xFIND
System
Nach dem in den vorangegangenen Kapiteln eingehend neue technologische Ansätze
zur Erweiterung der xFIND Kommunikationsarchitektur analysiert wurden, wird in
diesem Kapitel speziell auf die Integration dieser Technologien in das xFIND System
eingegangen.
In Kapitel 7 wurde die xFIND Kommunikationsarchitektur näher analysiert und ein
Benchmarktest der Datendurchsatzrate in der Übertragungsschicht erstellt. Der Vergleich
mit anderen Benchmark Tests brachte dabei wesentliche Aufschlüsse für Verbesserungsmöglichkeiten. Auch eine Problemanalyse der xFIND Kommunikationsarchitektur zeigt
die derzeitigen Schwächen im verteilten Konzeptansatz.
10.1. xFIND Konfiguration
Nachdem die xFIND Module von verschiedenen Personen entwickelt wurden, gibt es
auch entsprechend viele verschiedene Konfigurationsmöglichkeiten der einzelnen
Module. Die Module können „standalone“ betrieben werden und sind so auch separat zu
verwalten. In xFIND wird zwar einheitlich ein Konfiguration-Manager eingesetzt, doch
ersetzt dieser Manager weder die vielen verschiedenen Konfigurationsdateien noch fasst
er diese zusammen.
In Abschnitt 7.3 sind die verschiedenen Module und deren Konfiguration kurz
beschrieben. Speziell die Konfiguration des xFIND Managers beinhaltet viele
Redundanzen, wenn mehrere Module auf einem Rechner installiert sind. Die
Konfiguration der verschiedenen Module hat durchaus seine Berechtigung, wenn
Gatherer, Indexer oder Broker auf verschiedenen Rechnern installiert sind, und diese
nicht auf eine gemeinsame Konfigurationsreferenz zugreifen können.
Um den Mechanismus der Konfiguration vereinfachen zu können, wird
vorgeschlagen, nur eine Konfigurationsdatei zu verwenden. Diese sollte unabhängig von
den verschiedenen Komponenten abgelegt werden. xFIND beinhaltet das Package
edu.iicm.xfind.common.config. Dieses Package könnte als zentrale Stelle für die
Verwaltung einer allgemeinen Konfigurationsdatei dienen. Es gibt z.B. auch ein
grafisches UI für die Gatherer-Konfiguration. Dieses wurde im Rahmen eines
Studentenprojektes erstellt. Entsprechend könnte diese Idee aufgegriffen werden und ein
allgemeineres Konfig-UI für das Gesamtprojekt entworfen werden.
Eine weitere Verbesserungsmöglichkeit ergibt sich aufgrund der gewählten xFIND
Konfigurationssyntax. Die xFIND Konfiguration wurde speziell für die Anforderungen
von xFIND konzipiert. Die xFIND Syntax ist nicht standardisiert, nicht kompatibel zu
Seite 164
Kapitel 10 - Verbesserungsvorschläge für das xFIND System
anderen Standards und deshalb nicht mit standardisierten Werkzeugen lesbar oder
transformierbar. Die Konfigurations-Syntax sieht einerseits hierarchische Strukturen vor,
kann verschiedene Ressourcen einbinden bzw. bietet andererseits das Überladen von
Einträgen an. Diese Funktionalität wird mittlerweile auch mit der XML-Technologie zur
Gänze abgedeckt. Siehe dazu Abschnitt 5.4 XML-Grundlagen. Die XML-Technologie
war während der Entwicklungsphase von xFIND bereits als Standard vom W3C
anerkannt. Doch allein die syntaktische Notation ohne erweiterte Funktionalität, wie z.B.
XPath oder XLink, war für die Bedarfsanforderung zu gering. Zudem gab es nur wenig
geeignete Parser und diese in unzureichender Qualität.
Mittlerweile ist aber XML weit verbreitet. Vor allem gibt es eine Reihe neuer XMLbasierender Standards. Auf Grund der XML-Konformität, eine richtige Syntax wird
vorausgesetzt, sind alle XML-Spezifikationen zueinander kompatibel. D.h. jede XMLStruktur lässt sich leicht in eine andere XML-Struktur umformen. Zudem gibt es eine
Vielzahl an speziellen XML-Editoren, die das Erstellen und Verwalten von XML-Dateien
vereinfachen.
Da das Konfigurations-Package edu.iicm.xfind.common.config in xFIND bereits
existiert, braucht zur Erweiterung der xFIND Konfiguration auf Basis XML nur ein
zusätzlicher XML-Reader erstellt werden. Der bestehende XFConfigReader sollte aus
Gründen der Rückwärtskompatibilität weiterhin unverändert bleiben. Die xFIND
Konfigurationssyntax ist XML ähnlich aufgebaut. Deshalb ist eine problemlose
Transformation in eine XML-Notation mit geringem Aufwänd möglich.
Ein großer Problembereich stellt jedoch die manuelle Konfiguration von Gatherer und
Indexer für neue, über das Registrier Modul erstellte Quellen dar. Die Registrier
Komponente sieht die Anmeldung von neuen Web-Quellen über ein Web-basiertes UI
vor. Auf das Registrier Modul wurde in dieser Arbeit nicht näher eingegangen. Weitere
Informationen dazu sind in der Arbeit von Robert Hoffmann [Hoffmann 2002] in
Abschnitt 8.2.1 Ressourcenanmeldung ersichtlich.
Die Registrierdaten werden zurzeit im Filesystem in einem speziellen Ordner
abgelegt. Die Quelle muss jedoch manuell im Gatherer-Konfigfile eingetragen werden.
Insbesondere dieser Umstand erfordert deshalb eine laufende Wartung der Gatherer
Konfiguration. Um dies vermeiden zu können, müsste das Registrier Modul direkten
Zugriff auf die entsprechende Konfigurationsdatei haben.
10.2. xFIND interne Kommunikation
Was bedeutet „interne Kommunikation“. Für den folgenden Abschnitt wird als interne
Kommunikation der Datenaustausch zwischen zwei xFIND-Modulen bezeichnet, wenn
diese auf derselben Rechnerarchitektur laufen. D.h. die Module teilen sich sämtliche
verfügbaren Ressourcen.
Hinsichtlich
der
internen
Kommunikation
konnten
nur
wenige
Verbesserungspotentiale identifiziert werden. Die Kommunikation setzt intern wie auch
extern auf Java Sockets auf. In xFIND wurde mit QCF (siehe Abschnitt A Kapitel 12) ein
eigenes Kommunikations- und Datenaustauschformat erstellt. Die einzelnen Module
kommunizieren entsprechend über diese Socket-Verbindungen. Zudem ist QCF nicht an
einen Standard angelehnt, sodass der xFIND Client und der xFIND Server nur schwer an
Fremdsysteme anzubinden sind. Nachdem der Datentransport auf TCP/IP aufbaut,
müssen die verschiedenen xFIND Datenobjekte beim Sender serialisiert und beim
Empfänger wieder deserialisiert werden.
Seite 165
Diesen Umweg kann man sich ersparen, indem ein eigenes lokales Austauschformat
entwickelt wird. Die Datenübertragung in xFIND ist zwar effizient, doch ist gerade in
diesem Bereich Verbesserungspotential vorhanden. Da die xFIND Module sehr spezifisch
sind und die Hierarchie klar vorgegeben ist (Gatherer-Indexer-Broker), liegt es nahe, auch
entsprechend spezifische Austauschformate zu definieren. Eine Verallgemeinerung an
dieser Stelle würde nicht viel bringen, da wiederum Transformationen und
Rücktransformationen zu erwarten sind.
Die Entwicklung könnte auch in eine andere Richtung gehen. Sofern gewährleistet
werden kann, dass keine Seiteneffekte zu erwarten sind, können die Module über lokale
Schnittstellen direkt auf die verschiedenen Ressourcen anderer Module zugreifen. Auch
eine einfachere Synchronisation gleicher Module (z.B. Datenabgleich oder Cacheupdate)
wäre somit möglich.
Der Entwurf eines lokalen Austauschformates, oder der Zugriff über spezielle lokale
Schnittstellen erfordert auch keine Modifikation bezüglich Sicherheit und
Authentifikation. In einer gesicherten Umgebung, und davon kann bei einem einzelnen
Rechner ausgegangen werden, brauchen Sicherheitsaspekte nicht speziell implementiert
werden.
10.3. xFIND externe Kommunikation
Mehr Verbesserungspotential liegt in der externen Kommunikationseinheit. Die
xFIND Kommunikation ist, wie bereits öfters erwähnt, nicht standardisiert. Auch gibt es
zurzeit keine Möglichkeit standardisierte Technologien anzubinden. Der einfache
Kommunikationsaufbau und die Authentifikation sind sehr effizient umgesetzt. Jedoch
bietet insbesondere die Authentifikation ohne Zertifikat und ohne Encryption keinerlei
Sicherheit gegenüber Angriffen. Auch die Datenübertragung erfolgt ungeschützt.
Textbasierte Daten werden UTF8-codiert in Plaintext übertragen. Binäre Daten werden
Base64 codiert und wiederum unverschlüsselt vermittelt.
Bezüglich der Authentifikation und der Datenübertragung ist mit BEEP ein
Übertragungsprotokoll vorhanden, dass recht einfach in xFIND zu integrieren ist. Zudem
kann BEEP mit TLS und SASL betrieben werden und würde so die vorhandenen
Schwachstellen im Bereich Sicherheit beheben. Ein weiterer Vorteil von BEEP ist der
asynchrone Verbindungsansatz. Es gibt in BEEP keine ausgezeichneten Rollen mehr. So
können neben einfachen Client-Server Lösungen auch Server-zu-Server Verbindungen
geschaffen werden. Dies impliziert die Erstellung von Peer-to-Peer Architekturen mit den
xFIND-Modulen.
Aus Performancegründen wird in xFIND eine Antwort auf eine Suchanfrage in
mehrere kleine aufeinanderfolgende Antworten zerteilt. Diese Antwort Sequenzen
könnten recht einfach über die One-to-Many Eigenschaft von BEEP erzeugt werden. Der
Vorteil der BEEP-Asynchronität kann insbesondere genutzt werden, indem Suchanfragen
quasi im Broadcast-Prinzip an mehrere Indexer bzw. Gatherer gerichtet werden. Die
Effizienz von BEEP gegenüber der xFIND Kommunikation ist teilweise nur geringfügig
schlechter. Dies bedingt natürlich durch den XML-basierten Datenaustausch.
Erwähnenswert ist, dass mit BEEP, aufgrund der Datendeklarierung mittels MIME-Type,
alle in xFIND vorhandenen Datentypen übertragen werden können.
Um jedoch den Overhead beim Verbindungsaufbau einer BEEP Session verringern zu
können, kann die BEEP-Eigenschaft des Kanal-multiplexen ausgenutzt werden.
Datenpakete könnten „quasi-parallel“ übertragen werden. Wird dieser Gedanke weiter
Seite 166
Kapitel 10 - Verbesserungsvorschläge für das xFIND System
verfolgt, muss darauf geachtet werden, dass es keine Abhängigkeiten zwischen den
Datenpakten gibt. Aufgrund der BEEP-Asynchronität könnten sonst Dateninkonsistenzen
oder Dead-Locks entstehen bzw. unvorhergesehene Verzögerungen auftreten. Bevor also
daran gedacht wird, diese Funktionalität einzusetzen, muss eine Daten-Laufzeitanalyse
erstellt werden. Kritische Bereiche sind bei möglichen auftretenden Konflikten zu
modifizieren.
Weiters sind in xFIND keine Vorkehrungen getroffen, um auch Fremdsystemen
Zugriff auf die spezifischen Daten zu ermöglichen. Eine Möglichkeit ist die Erstellung
von Web-Services über UDDI und WSDL. Eine funktionelle Anbindung über andere
standardisierte Technologien, wie z.B. SOAP oder XML-RPC ist denkbar.
10.4. xFIND Architektur
Die xFIND Architektur ist aufgrund der verschiedenen Entwicklungsstadien recht lose
miteinander verbunden. Es existiert lediglich eine Verbindung über Java Sockets. Die
Verbindungsdaten,
Host-IDs
und
Portadressen
werden
über
diverse
Konfigurationsdateien eingestellt. Somit wird dieser lose Modul-Verbund aufgehoben
und starr an ein bestimmtes Konfigurationsschema gebunden.
Der xFIND-Manager als zentrale Ansprechstelle, verteilt Anfragen an Gatherer und
Indexer. Er steuert und verwaltet auch die entsprechenden Sockets. So kann ein Server
maximal 255 Verbindungen halten. Auch muss jedes Modul einen eigenen Server und
Client zur Kommunikation bereitstellen.
Die Recherche von selbst organisierenden Peer-to-Peer Lösungen für verteilte
Suchsysteme aus dem Kapitel 6, bietet insbesondere für diesen Bereich interessante
Lösungen an. Aus diesem Grund wurde in Kapitel 9 das JXTA Protokoll Framework
analysiert. Mit JXTA ist durch den Austausch von Metadaten (Advertisements) eine recht
einfache Möglichkeit gegeben, um verschiedene Ressourcen in einem Netzwerk
anzubieten und diese auch aufzufinden.
Es denkbar, dass z.B. verteilte Gatherer, die thematisch ähnliche Bereiche absuchen,
zu gemeinsamen Themengruppen zusammengefasst werden. Das eigentliche Ziel,
Gatherer direkt bei den Informationsquellen zu installieren, bietet sich in diesem Fall sehr
gut an. Indexer könnten ebenfalls themenspezifisch in Gruppen zusammengefasst
werden. Themenselektive Suchanfragen könnten so mittels Broadcast innerhalb der
Themengruppen verteilt werden. Indexer müssen „ihre“ Gatherer nicht kennen, bzw. die
Verbindung zu Gatherer muss nicht starr sein. Eine Suche innerhalb des P2P Netzwerks
nach entsprechenden Gatherer-Advertisements würde ausreichen, um relevante Daten zu
erhalten.
Dasselbe Prinzip ist natürlich auch auf die Broker-Indexer Schnittstelle anwendbar. In
xFIND werden über das Web-UI drei verschiedene Suchinterfaces angeboten; Einfache
Suche, Erweiterte Suche und Profi Suche. Wenn speziell themenspezifische Filter nach
DDC oder ACM eingestellt sind, kann der Broker bereits eine Vorselektion von Indexer
durchführen, indem er spezifisch nur themenrelevante Indexer befragt. Die Selektion
erfolgt dabei über die Suche nach themenspezifischen Indexer-Advertisements.
Auch sind verschiedene Suchmechanismen denkbar. Sowohl eine Breitensuche als
auch die Tiefensuche ist realisierbar. Verschiedene Broker könnten untereinander
kommunizieren und gecachte Suchergebnisse austauschen. Die Suche innerhalb
themenspezifischer Gruppen (Indexer und Broker) entspricht dabei der Breitensuche.
Seite 167
Werden Suchanfragen an andere Themengruppen weitergeleitet, kann die Tiefensuche
realisiert werden. Jedoch erforder diese Erneuerung auch die Erweiterung der
Systemmodule. Mögliche auftretende Antwortduplikate müssten an verschiedenen Stellen
ausgefiltert werden.
10.5. Schlussbemerkung
Wie aus den vorangegangenen Abschnitten dieses Kapitel ersichtlich ist, gibt es eine
Reihe an Verbesserungsmöglichkeiten für die xFIND Sucharchitektur. Nicht nur der
notwendige Umbau der Kommunikationsschicht aufgrund sicherheitsrelevanter
Überlegungen, sondern auch eine verbesserte Konfiguration und implizit die
eigenständige Verwaltung der xFIND Module, könnte mit einfachen Mitteln realisiert
werden.
In einer ersten Phase sollte jedoch lediglich die Kommunikationsschicht angepasst und
modernisiert werden. Der Einsatz von BEEP als Datenübertragungsprotokoll zeigt sich
als vernünftige Alternative zum bestehenden Ansatz und sollte nicht allzu großen
Aufwand in der Umsetzung erfordern. Im Zuge des Umbaus könnte zu Versuchszwecken
auch an die Realisierung lokaler Schnittstellen gedacht werden, um die Effizienz der
lokalen Kommunikation steigern zu können.
In einer zweiten Umsetzungsphase sollte die Konfiguration vereinheitlicht und
verbessert werden. Der Einsatz von XML als Definitionssprache bietet zudem auch viele
Vorteile. XML-Editoren, Validierung mittels DTD oder XML-Schema sind nur einige
wenige Vorteile, die damit automatisch auf xFIND übertragen werden können.
Der Einsatz von JXTA oder einer ähnlichen Technologie, um die Verwaltung bzw. die
Konfiguration zu erleichtern, könnte in einer dritten Ausbaustufe erfolgen. Dabei sei aber
zu erwähnen, dass JXTA nicht in der Datenübertragung einzusetzen ist. JXTA sollte
lediglich der automatisierten Verwaltung der Module dienen. Die Datenübertragung muss
effizient bleiben. Auch sind die JXTA Protokolle noch nicht standardisiert. JXTA bietet
zumindest im Bereich Peer-to-Peer das größte Entwicklungspotential.
Seite 168
Seite 169
Kapitel 11
11. Zusammenfassung
Wissensauffindung im Internet ist ein Prozess, der meist über Suchsysteme
abgewickelt wird. Ein Benutzer stellt seine Anfragen an diese Suchsysteme und erhält
eine Reihe an Antworten. Der Prozess kann verallgemeinert auch als Information
Retrieval (IR) bezeichnet werden. Dieser IR Prozess läuft in seiner ursprünglichen Form
in einer gewöhnlichen Client-Server Beziehung ab. Der Client sucht Informationen, der
Server erzeugt die Antworten. Dies ist wiederum verallgemeinert, die Schwachstelle des
reinen Client-Server Paradigma.
Im Alltagsleben impliziert eine Suche die Fragestellung an einen Experten. Der
Experte liefert mehr oder weniger brauchbare Antworten. Das Wissen ist jedoch nicht
zentral bei einem Experten vorhanden, sondern liegt verteilt vor. Um auf den
Wissensstand anderer Experten zugreifen zu können, bedarf es eines angepassten,
verteilten IR Prozesses. Diese Feststellung trifft natürlich auch auf die Wissensauffindung
im Internet wieder. Die Quellen liegen geographisch verteilt vor und können nicht von
einem zentralen System verwaltet oder durchsucht werden.
Zudem steigt das Informationsaufkommen im Internet stetig. Die momentan
gängigsten Suchmaschinen wie z.B. Google oder Yahoo, arbeiten nur effizient bei
statischen und sich langsam ändernden Inhalten. Die grundsätzliche Idee von xFIND ist,
nur themenspezifische Quellen anzubieten. Der Vorteil des xFIND Ansatzes liegt in der
Einbeziehung von dynamischen Größen, wie z.B. die Lebensdauer einer Seite. Zudem
kann mit speziellen Methoden auch der Inhalt des Deep-Web zur Suche angeboten
werden. Über weitere Module kann z.B. eine automatisierte Themenklassifizierung
durchgeführt werden. Zudem bietet xFIND die Möglichkeit, Quellen mit zusätzlichen
Metainformationen zu bewerten.
Der Vergleich zentraler Ansatz zu verteiltem Ansatz zeigt doch deutliche
Unterschiede auf. Vorteile und Nachteile der jeweiligen Architekturen können aus diesen
Unterschieden einfach abgeleitet werden. Speziell für den verteilten Ansatz gibt es jedoch
viele unterschiedliche Topologie Formen. Um die Problembereiche identifizieren zu
können, werden grundlegende Elemente verteilter Ansätze untersucht. Aktuelle
Middleware Technologien liefern wichtige Erkenntnisse, sowie einige Lösungen. Der
zentrale Ansatz ist einfach, effizient, jedoch schlecht erweiterbar und schlecht skalierbar.
Der verteilte Ansatz ist hingegen fehlertolerant, ausfallsicherer, gut erweiterbar, je nach
Technologie hoch skalierbar, erfordert dafür aber auch einen höheren
Verwaltungsaufwand
und
verursacht
meist
einen
Overhead
in
der
Kommunikationseinheit.
Das Ziel dieser Diplomarbeit, die Kommunikationsschnittstellen von xFIND zu
verbessern, führte zu einer näheren Analyse bereits bestehender Lösungen. Insbesondere
wurde der Fokus auf standardisierte Technologien gelegt, die in verteilten Anwendungen
Seite 170
Kapitel 11 - Zusammenfassung
einsetzbar sind. Gründe für die Forderung nach Standards sind die größere Akzeptanz, die
Widerverwendbarkeit, die einfache Erweiterbarkeit, die Modularisierung und eine bessere
Wartbarkeit der Softwareprodukte. Die Analyse gängiger Middleware Technologien in
diesem Bereich liefert auch für diesen Untersuchungsbereich viele interessante
Ergebnisse. Als wohl wichtigste Erkenntnis aus diesem Untersuchungsbereich geht
hervor, dass sowohl in der Datenübertragung, als auch im Kommunikationsbereich XML
basierte Technologien bevorzugt eingesetzt werden.
XML ist eine heterogene Beschreibungssprache. XML ist standardisiert, weit
verbreitet, einfach verarbeitbar, human-readable bzw. machine-readable und einfach zu
erweitern. Dies sind nur einige Vorzüge von XML. Aus diesem Grund wurden speziell
XML-basierte Transport- und Übertragungsprotokolle in einem eigenen
Untersuchungsbereich vorgestellt und analysiert. Um einen besseren Überblick über die
Ergebnisse dieser Untersuchung zu erlangen, wurden die wichtigsten Eigenschaften der
analysierten Protokolle in tabellarischer Form zusammengefasst. Wichtige Kernpunkte
dieser Gegenüberstellung sind: Erweiterbarkeit, Datentransport, Widerverwendbarkeit,
Fehlerbehandlung, Standardisierung, Sicherheit, Authentifikation und das Einsatzgebiet.
Um eine Vorauswahl für eine spezifischere Analyse geeigneter Protokolle zur
Verbesserung der xFIND Kommunikationsschicht treffen zu können, wurden bestehende
Ansätze zur verteilten Suche im Internet vorgestellt. Neben den beiden Modul basierten
Systemen Harvest und xFIND liefern insbesondere moderne Peer-to-Peer (P2P) Ansätze
wie Freenet, FASD oder JXTA interessante Verbesserungsmöglichkeiten für die xFIND
Systemarchitektur.
Von Beginn an war der verteilte Modul Ansatz fixer Bestandteil in der xFIND System
Architektur. Einzelne Module wie Gatherer oder Indexer können auf verschiedenen
Rechnern installiert werden. Die Kommunikation, bzw. der Datenabgleich erfolgt über
das proprietäre xQCF Format. xQCF ist weder standardisiert, noch ist es kompatibel zu
anderen gängigen Formaten. Um diese Schwachstellen verbessern zu können, wurde eine
eingehende technische Analyse der xFIND Kommunikationsschicht durchgeführt. In
einer Testapplikation wurden anhand Benchmark Tests, Kennwerte zum Vergleich mit
anderen Technologien erstellt.
Als Ergebnis der verschiedenen Untersuchungen zeigte sich, dass das
Übertragungsprotokoll BEEP als geeignetste alternative Technologie im Bereich der
Datenübertragung für xFIND einzusetzen ist. In weiterer Folge wurde das Protokoll
BEEP einer näheren technischen Analyse unterzogen. Kenndaten der BEEP Architektur
konnten mit Hilfe spezieller Testimplementierungen und diversen Benchmark Tests
gewonnen werden. Diese Kenndaten wurden für einen direkten Vergleich mit der xFIND
Technologie
herangezogen.
BEEP
bietet
aufgrund
seiner
Spezifikation,
Sicherheitsaspekte wie Transportsicherheit und Authentifikation bereits in seiner
Basisfunktionalität an. Diese Basiseigenschaften und die Analyse der Ergebnisse aus den
Benchmark Tests, bzw. der Vergleich mit xFIND zeigt, dass BEEP aufgrund des
einfachen Aufbaus ohne großen Aufwand in die xFIND Architektur zu integrieren ist.
Aus der eingehenden technischen Analyse der xFIND System Architektur,
kristallisierte sich noch ein weiterer großer Problembereich heraus. Durch den verteilten
Architekturansatz ist auch die Verwaltung und Konfiguration der Module recht
kompliziert und umfangreich. Zudem erfordert diese Verwaltung enormes Spezialwissen.
Verschiedene verteilte Suchsysteme auf Basis P2P bieten hinsichtlich der Verwaltung
neue Ideen und Lösungsansätze. Die Selbstverwaltung und Selbstorganisation dieser P2P
Netzwerke könnte Ansatzweise auch auf die xFIND Architektur übertragen werden.
Seite 171
Die verschiedensten Analysen haben gezeigt, dass das JXTA Protokollframework für
diese Architekturerweiterung am besten geeignet ist. Die wichtigsten Erkenntnisse aus
einer eingehenden technischen Analyse und Testphase sind:
• Es werden keine speziellen Clients oder Server benötigt.
• Die Module sind über Advertisements (Metadatenbeschreibungen) virtuell
miteinander verbunden.
• Alle beteiligten Stellen (Module) sind gleichberechtigt.
• Die Grundkonfiguration der Module kann weitestgehend unverändert bleiben.
• Eine „echte“ verteilte Suche ist über die Bildung mehrerer themenspezifischer
Gruppierungen möglich.
• Dies implizit eine P2P Lösung für die xFIND Module.
JXTA auf xFIND abgebildet erfordert jedoch einen geringen Umbau im xFIND
Design. Zum einen müssen einige Schnittstellen erweitert werden und zum anderen
werden neue Algorithmen benötigt, die z.B. auftretende Datenredundanzen vermeiden.
Mit diesen neuen Schnittstellen sind die Aufgaben der jeweiligen Module zusätzlich auch
als offene Services ansprechbar. Gleichartige Module können aufgrund der JXTA Peer
Group Eigenschaft, recht einfach zu stärkeren Verbunden vereint werden.
Der Größte Vorteil ergibt sich aber aus der automatisierten Verwaltung der Module.
Anhand zweier Testimplementierungen wird gezeigt, dass die Suche nach spezifischen
Diensten anhand einfacher Prinzipien erstellt werden kann. Eine Integration der JXTA
Technologie in xFIND bzw. eine Anpassung der xFIND Module erfordert jedoch einigen
zusätzlichen Testaufwand. Deshalb wird vorgeschlagen, spezielle Testimplementierungen
für Folgeprojekte vorzubereiten.
Sämtliche Verbesserungsvorschläge zur Erweiterung des xFIND Systems wurden
eigens in einer thematisch getrennten Übersicht zusammengefasst. In dieser Übersicht
werden konkrete Vorschläge zur Erweiterung der internen und der externen
Kommunikationsschicht gegeben. Für eine einheitlichere Konfiguration bzw. Verwaltung
wurden Ideen und Lösungsansätze erstellt. Folgeprojekte könnten die Ansätze und Ideen
der automatisierten Modulverwaltung umsetzen. Da diese Vorschläge die
Systemarchitektur erweitern, bedarf es deshalb eigener Testphasen vor der eigentlichen
Umsetzung.
Der Autor dieser Arbeit hofft, dass die gesammelten Daten, gewonnenen Erkenntnisse
und Vorschläge, als Basis und Nachschlagewerk für künftige Projekte zur Verbesserung
des xFIND Suchsystems dienlich sein können.
Seite 172
Seite 173
III Anhang
Seite 174
Seite 175
Anhang A
12. QCF-Spezifikation
12.1. Allgemeines
12.1.1. QCF Platzhalter
•
•
•
•
•
%d: for numbers in decimal format (in JAVA: Integer)
%x: for numbers in hexadecimal format (in JAVA: Integer)
%o: for numbers in octal format (in JAVA: Integer)
%f: for numbers in floating point format (in JAVA: Float)
%s: for strings (in JAVA: String)
12.1.2. QCF WildCards
•
•
•
•
<&QCF-KEY-Name>: a defined QCF-Key
<&REQUEST-KEY-Name>: a key that was sent to "me"
<&DOCTAG-Name>: a "TAG" like a META-TAG in HTML from the document content
<&ID-Number>: a number for the keys
12.1.3. QCF-Keys
•
•
•
•
•
•
•
•
•
[xFIND.QCF.<&QCF-KEY-Name>]: a simple QCF-Key. It contains all sub-fields of this key. that
means it has no visible data itself only other nested "sections"
[xFIND.QCF.<&QCF-KEY-Name>.QCFExplanation]: a short explanation in simple words. It could be
shown to the user/administrator as well if desired. Multiple lines are possible.
[xFIND.QCF.<&QCF-KEY-Name>.QCFMapping]: this key will be mapped to all listed QCF-Keys.
QCF-KEYs separated by NewLines (NL). If a mapped key is NOT defined by an own "section" the
current key is rejected by the system. Multiple lines are possible.
[xFIND.QCF.<&QCF-KEY-Name>.QCFExample]: a short example in simple words to describe a QCFKey. Multiple lines are possible.
[xFIND.QCF.<&QCF-KEY-Name>.QCFAllowedSections]: the "place" or "location" where the key may
be mentioned. If "location" is followed by [QCF-Key=="Value"] then the key xFIND.QCF.<&QCFKEY-Name> can only occur at this "location" when QCF-Key has this "Value". If "location" is followed
by [QCF-Key!="Value"] then the key xFIND.QCF.<&QCF-KEY-Name> must not occur at this
"location" when QCF-Key has this "Value". Multiple lines are possible.
[xFIND.QCF.<&QCF-KEY-Name>.QCFValues]: a set of possible values for this key. If the system
receives a value which is not included in this set, it has to reject this key. Multiple lines are possible.
[xFIND.QCF.<&QCF-KEY-Name>.QCFDefaultValue]: this value can be placed in the "value" of this
very key. It ia a single line.
[xFIND.QCF.<&QCF-KEY-Name>.QCFRequiredOperators]: for defineing dependencies. If keys need
operators they have to be placed in this section. QCFAllowedSections has to be set to: InternalUse.
Multiple lines are possible.
[xFIND.QCF.<&QCF-KEY-Name>.QCFAllowedSubKeys]: a list of all keys that can match the <&QCFKEY-Name>-Wildcard name. A Unix wild card (*) is allowed in the specified names. E.g.: Object.*
everything starting with Object matches. Multiple lines are possible.
Seite 176
Anhang A - QCF-Spezifikation
12.1.4. QCF Syntax
Items" on the left-hand side can only be followed by one of the "Items" on the right-hand side.
All "Items" are introduced in this file further down.
QCF-Key implies a Key/Value pair, where either Key or Value may be omitted.
QCF-SubKeys has type of: Object.*.Content.*
QUERY-START (^):
MARK( | QCF-Key
QUERY-END ($):
MARK) | QCF-Key | COMP | MOD)
QCF-Key:
QCF-SubKeys | OP | COMP | MARK) | MOD)
OP:
QCF-Key | MARK( | MOD | MOD(
COMP:
OP | MARK) | MOD(
MARK(:
QCF-Key | MARK(
MARK):
OP | MARK) | MOD(
MOD:
QCF-Key
MOD(:
QCF-Key
MOD):
OP | MARK)
12.1.5. QCF Request zwischen Client und Server (Machine readable)
{MARK}{(}{Object.Title}{Graz}{OP}{ANDNOT}{}{Karten}
{MARK}{)}{OP}{OR}
{Site.Title}{Landesregierung}{OP}{AND}{Object.LastModified}{931178718}
{COMP}{>=}{OP}{OR}
{MARK}{(}
{Object.Body}{Stadtverwaltung}{OP}{OR}{Object.Keyword}{Stadtverwaltung}
{MARK}{)}
{MOD}{(}
{Object.Weight.Keyword}{3}{Object.Weight.Body}{5}
{MOD}{)}
Query Attributes (default from the Indexer-Server, Broker-Server or local configfile):
{Object.Body.CharLimit}{1000}{Object.Body.ResultLimit}{3}
{Object.Body.FirstChars}{500}{Object.Keywords.ResultLimit}{}
{Object.Keywords.Percent}{1}{Object.Weight.Keyword}{9}
Return Attributes (default from the Indexer-Server, Broker-Server or local configfile):
{Object.Body}{}{Object.Title}{}
{Object.Body.URL}{}{Object.Keywords}{}
{Object.Weight.Keyword}{}
12.1.6. QCF Request zwischen Client und Server (Human readable)
((Object.Title=Graz) (OPERATOR=ANDNOT) (DEFAULT=Karten))
(OPERATOR=OR)
(Site.Title=Landesregierung) (OPERATOR=AND)
(Object.LastModified >= 931178718)
(OPERATOR=OR)
(MODIFY:
((Object.Body=Stadtverwaltung) (OPERATOR=OR)
(Object.Keyword=Stadtverwaltung) )
(Object.Weight.Keyword=3 AND Object.Weight.Body=5))
Query Attributes (default from the Indexer-Server, Broker-Server or local configfile):
Object.Body.CharLimit=1000 Object.Body.ResultLimit=3
Object.Body.FirstChars=500 Object.Weight.Keyword=9
Object.Keywords.ResultLimit=DEFAULT Object.Keywords.Percent=1
Return Attributes (default from the Indexer-Server, Broker-Server or local configfile):
Object.Body, Object.Body.URL, Object.Keywords,
Object.Title, Object.Weight.Keyword
Seite 177
12.1.7. QCF Request zwischen Server und Client
Statistics:
• (Error | Warning).<&REQUEST-Name>.Count or even more common like.
• (Error | Warning).Count tells how many errors or warnings occurred.
• The data itself is transmitted in the Footer later on.
• In a panic situation it is possible that the "Data-Part" of the errors/warnings is dropped!
• Stats.Hits | Stats.Costs | Stats.Error.Count | Stats.Warning.Count |
• Stats.SearchWord.<ID> | Stats.SearchWord.<ID>.Count |
• Stats.OldestObject | Stats.NewestObject | Stats.Language.Count |
• Stats.DifferentWebAreas
Results:
• are requested in the ReturnLayout field.
• results are returned as "OBJECTS"
• each object includes a set of SOIF-Attributes which consist of Key / Value pairs.
• additional QCF-KEYS could take place in an "OBJECT" as well.
ResultsFooter:
• possible main status could be: OK | Overload | Panic | Deny
• fields that were ignored or not understood from the search query are sent back.
• (here represented with <&REQUEST-Name>) in the following format
• (this format is easily extensible regarding additional messages, counters, IDs, explanations aso.):
12.2. Übersicht über die QCF-Keys
Die nachfolgende Aufstellung wurde aus der Programmers Dokumentation für xFIND
entnommen und entsprechend zusammengefasst. Die Einteilung der QCF-Keys erfolgt
anhand der 14 verschiedenen QCF-Sections. [xFIND 2003]
12.2.1. VERSION – Section
xFIND.QCF.Version.Major
xFIND.QCF.Version.Minor
xFIND.QCF.Version.PatchLevel
12.2.2. AUTH – Section
xFIND.QCF.Auth
xFIND.QCF.Auth.QCFExplanation
xFIND.QCF.Auth.QCFExample
xFIND.QCF.Auth.QCFAllowedSections
xFIND.QCF.Auth.SectionVersionNumber
xFIND.QCF.Auth.SectionVersionNumber.QCFExplanation
xFIND.QCF.Auth.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Auth.SectionVersionNumber.QCFValues
xFIND.QCF.Auth.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Auth.Host
xFIND.QCF.Auth.Host.QCFExplanation
xFIND.QCF.Auth.Host.QCFAllowedSections
xFIND.QCF.Auth.Host.QCFValues
xFIND.QCF.Auth.Host.QCFDefaultValue
xFIND.QCF.Auth.Port
xFIND.QCF.Auth.Port.QCFExplanation
xFIND.QCF.Auth.Port.QCFAllowedSections
xFIND.QCF.Auth.Port.QCFValues
xFIND.QCF.Auth.Port.QCFDefaultValue
Seite 178
xFIND.QCF.Auth.Realm
xFIND.QCF.Auth.Realm.QCFExplanation
xFIND.QCF.Auth.Realm.QCFAllowedSections
xFIND.QCF.Auth.Realm.QCFValues
xFIND.QCF.Auth.Realm.QCFDefaultValue
xFIND.QCF.Auth.Protocol
xFIND.QCF.Auth.Protocol.QCFExplanation
xFIND.QCF.Auth.Protocol.QCFAllowedSections
xFIND.QCF.Auth.Protocol.QCFValues
xFIND.QCF.Auth.Protocol.QCFDefaultValue
xFIND.QCF.Auth.Username
xFIND.QCF.Auth.Username.QCFExplanation
xFIND.QCF.Auth.Username.QCFAllowedSections
xFIND.QCF.Auth.Username.QCFValues
xFIND.QCF.Auth.Username.QCFDefaultValue
xFIND.QCF.Auth.Password
xFIND.QCF.Auth.Password.QCFExplanation
xFIND.QCF.Auth.Password.QCFAllowedSections
xFIND.QCF.Auth.Password.QCFValues
xFIND.QCF.Auth.Password.QCFDefaultValue
xFIND.QCF.Auth.Account
xFIND.QCF.Auth.Account.QCFExplanation
xFIND.QCF.Auth.Account.QCFAllowedSections
xFIND.QCF.Auth.Account.QCFValues
xFIND.QCF.Auth.Account.QCFDefaultValue
xFIND.QCF.Auth.Secure
xFIND.QCF.Auth.Secure.QCFExplanation
xFIND.QCF.Auth.Secure.QCFAllowedSections
xFIND.QCF.Auth.Secure.QCFValues
xFIND.QCF.Auth.Secure.QCFDefaultValue
xFIND.QCF.Auth.Type
xFIND.QCF.Auth.Type.QCFExplanation
xFIND.QCF.Auth.Type.QCFAllowedSections
xFIND.QCF.Auth.Type.QCFValues
xFIND.QCF.Auth.Type.QCFDefaultValue
12.2.3. ERROR - Section
xFIND.QCF.Error.SectionVersionNumber
xFIND.QCF.Error.SectionVersionNumber.QCFExplanation
xFIND.QCF.Error.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Error.SectionVersionNumber.QCFValues
xFIND.QCF.Error.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Error.Key.<&REQUEST-KEY-Name>
xFIND.QCF.Error.Key.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Error.Key.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Error.Key.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Error.Key.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Error.Explanation.<&REQUEST-KEY-Name>
xFIND.QCF.Error.Explanation.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Error.Explanation.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Error.Explanation.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Error.Explanation.<&REQUEST-KEY-Name>.QCFValues
Seite 179
xFIND.QCF.Error.Message.<&REQUEST-KEY-Name>
xFIND.QCF.Error.Message.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Error.Message.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Error.Message.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Error.Message.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Error.ID.<&REQUEST-KEY-Name>
xFIND.QCF.Error.ID.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Error.ID.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Error.ID.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Error.ID.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Error.Type.<&REQUEST-KEY-Name>
xFIND.QCF.Error.Type.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Error.Type.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Error.Type.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Error.Recover.<&REQUEST-KEY-Name>
xFIND.QCF.Error.Recover.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Error.Recover.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Error.Recover.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Error.Recover.<&REQUEST-KEY-Name>.QCFValues
12.2.4. GATHERER – Section
xFIND.QCF.Gatherer.SectionVersionNumber
xFIND.QCF.Gatherer.SectionVersionNumber.QCFExplanation
xFIND.QCF.Gatherer.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Gatherer.SectionVersionNumber.QCFValues
xFIND.QCF.Gatherer.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Gatherer.Attributes
xFIND.QCF.Gatherer.Attributes.QCFExplanation
xFIND.QCF.Gatherer.Attributes.QCFAllowedSections
xFIND.QCF.Gatherer.Attributes.QCFValues
xFIND.QCF.Gatherer.Attributes.QCFDefaultValue
xFIND.QCF.Gatherer.Stats
xFIND.QCF.Gatherer.Stats.QCFExplanation
xFIND.QCF.Gatherer.Stats.QCFAllowedSections
xFIND.QCF.Gatherer.Stats.QCFValues
xFIND.QCF.Gatherer.Stats.QCFDefaultValue
xFIND.QCF.Gatherer.Timestamp
xFIND.QCF.Gatherer.Timestamp.QCFExplanation
xFIND.QCF.Gatherer.Timestamp.QCFAllowedSections
xFIND.QCF.Gatherer.Timestamp.QCFValues
xFIND.QCF.Gatherer.Timestamp.QCFDefaultValue
xFIND.QCF.Gatherer.URL
xFIND.QCF.Gatherer.URL.QCFExplanation
xFIND.QCF.Gatherer.URL.QCFAllowedSections
xFIND.QCF.Gatherer.URL.QCFValues
xFIND.QCF.Gatherer.URL.QCFDefaultValue
xFIND.QCF.Gatherer.WebAreas
xFIND.QCF.Gatherer.WebAreas.QCFExplanation
xFIND.QCF.Gatherer.WebAreas.QCFAllowedSections
xFIND.QCF.Gatherer.WebAreas.QCFValues
xFIND.QCF.Gatherer.WebAreas.QCFDefaultValue
Seite 180
12.2.5. OBJECT – Section
xFIND.QCF.Object.SectionVersionNumber
xFIND.QCF.Object.SectionVersionNumber.QCFExplanation
xFIND.QCF.Object.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Object.SectionVersionNumber.QCFValues
xFIND.QCF.Object.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Object.Cost
xFIND.QCF.Object.Cost.QCFExplanation
xFIND.QCF.Object.Cost.QCFAllowedSections
xFIND.QCF.Object.Cost.QCFValues
xFIND.QCF.Object.Body.Word
xFIND.QCF.Object.Body.Word.QCFExplanation
xFIND.QCF.Object.Body.Word.QCFAllowedSections
xFIND.QCF.Object.Body.Word.QCFValues
xFIND.QCF.Object.Body.Phrase
xFIND.QCF.Object.Body.Phrase.QCFExplanation
xFIND.QCF.Object.Body.Phrase.QCFAllowedSections
xFIND.QCF.Object.Body.Phrase.QCFValues
xFIND.QCF.Object.Body.CharSurroundLimit
xFIND.QCF.Object.Body.CharSurroundLimit.QCFExplanation
xFIND.QCF.Object.Body.CharSurroundLimit.QCFAllowedSections
xFIND.QCF.Object.Body.CharSurroundLimit.QCFValues
xFIND.QCF.Object.Body.CharSurroundLimit.QCFDefaultValue
xFIND.QCF.Object.Body.MatchWord.Prepend
xFIND.QCF.Object.Body.MatchWord.Prepend.QCFExplanation
xFIND.QCF.Object.Body.MatchWord.Prepend.QCFAllowedSections
xFIND.QCF.Object.Body.MatchWord.Prepend.QCFValues
xFIND.QCF.Object.Body.MatchWord.Prepend.QCFDefaultValue
xFIND.QCF.Object.Body.MatchWord.Append
xFIND.QCF.Object.Body.MatchWord.Append.QCFExplanation
xFIND.QCF.Object.Body.MatchWord.Append.QCFAllowedSections
xFIND.QCF.Object.Body.MatchWord.Append.QCFValues
xFIND.QCF.Object.Body.MatchWord.Append.QCFDefaultValue
xFIND.QCF.Object.Body.ResultLimit
xFIND.QCF.Object.Body.ResultLimit.QCFExplanation
xFIND.QCF.Object.Body.ResultLimit.QCFAllowedSections
xFIND.QCF.Object.Body.ResultLimit.QCFValues
xFIND.QCF.Object.Body.ResultLimit.QCFDefaultValue
xFIND.QCF.Object.Body.FirstChars
xFIND.QCF.Object.Body.FirstChars.QCFExplanation
xFIND.QCF.Object.Body.FirstChars.QCFAllowedSections
xFIND.QCF.Object.Body.FirstChars.QCFValues
xFIND.QCF.Object.Body.FirstChars.QCFDefaultValue
xFIND.QCF.Object.Keyword
xFIND.QCF.Object.Keyword.QCFExplanation
xFIND.QCF.Object.Keyword.QCFAllowedSections
xFIND.QCF.Object.Keyword.QCFValues
xFIND.QCF.Object.Keywords.ResultLimit
xFIND.QCF.Object.Keywords.ResultLimit.QCFExplanation
xFIND.QCF.Object.Keywords.ResultLimit.QCFAllowedSections
xFIND.QCF.Object.Keywords.ResultLimit.QCFValues
xFIND.QCF.Object.Keywords.ResultLimit.QCFDefaultValue
Seite 181
xFIND.QCF.Object.Keywords.PercentageLimit.Minimum
xFIND.QCF.Object.Keywords.PercentageLimit.Minimum.QCFExplanation
xFIND.QCF.Object.Keywords.PercentageLimit.Minimum.QCFAllowedSections
xFIND.QCF.Object.Keywords.PercentageLimit.Minimum.QCFValues
xFIND.QCF.Object.Keywords.PercentageLimit.Minimum.QCFDefaultValue
xFIND.QCF.Object.Keywords.PercentageLimit.Maximum
xFIND.QCF.Object.Keywords.PercentageLimit.Maximum.QCFExplanation
xFIND.QCF.Object.Keywords.PercentageLimit.Maximum.QCFAllowedSections
xFIND.QCF.Object.Keywords.PercentageLimit.Maximum.QCFValues
xFIND.QCF.Object.Keywords.PercentageLimit.Maximum.QCFDefaultValue
xFIND.QCF.Object.Meta
xFIND.QCF.Object.Meta.QCFExplanation
xFIND.QCF.Object.Meta.QCFAllowedWildcards
xFIND.QCF.Object.Meta.<&DOCTAG-Name>
xFIND.QCF.Object.Meta.<&DOCTAG-Name>.QCFExplanation
xFIND.QCF.Object.Meta.<&DOCTAG-Name>.QCFAllowedSections
xFIND.QCF.Object.Meta.<&DOCTAG-Name>.QCFValues
xFIND.QCF.Object.Meta.<&DOCTAG-Name>.QCFDefaultValue
xFIND.QCF.Object.Quality
xFIND.QCF.Object.Quality.QCFExplanation
xFIND.QCF.Object.Quality.QCFAllowedSections
xFIND.QCF.Object.Quality.QCFValues
xFIND.QCF.Object.Quality.QCFDefaultValue
xFIND.QCF.Object.Quality.Abstract
xFIND.QCF.Object.Quality.Abstract.QCFExplanation
xFIND.QCF.Object.Quality.Abstract.QCFAllowedSections
xFIND.QCF.Object.Quality.Abstract.QCFValues
xFIND.QCF.Object.Quality.Abstract.QCFDefaultValue
xFIND.QCF.Object.Quality.Body
xFIND.QCF.Object.Quality.Body.QCFExplanation
xFIND.QCF.Object.Quality.Body.QCFAllowedSections
xFIND.QCF.Object.Quality.Body.QCFValues
xFIND.QCF.Object.Quality.Body.QCFDefaultValue
xFIND.QCF.Object.Quality.Target
xFIND.QCF.Object.Quality.Target.QCFExplanation
xFIND.QCF.Object.Quality.Target.QCFAllowedSections
xFIND.QCF.Object.Quality.Target.QCFValues
xFIND.QCF.Object.Quality.Target.QCFDefaultValue
xFIND.QCF.Object.ResultLimit
xFIND.QCF.Object.ResultLimit.QCFExplanation
xFIND.QCF.Object.ResultLimit.QCFAllowedSections
xFIND.QCF.Object.ResultLimit.QCFValues
xFIND.QCF.Object.ResultLimit.QCFDefaultValue
xFIND.QCF.Object.Title
xFIND.QCF.Object.Title.QCFExplanation
xFIND.QCF.Object.Title.QCFAllowedSections
xFIND.QCF.Object.Title.QCFValues
xFIND.QCF.Object.Title.QCFDefaultValue
xFIND.QCF.Object.DC.Title
xFIND.QCF.Object.DC.Title.QCFExplanation
xFIND.QCF.Object.DC.Title.QCFMapping
xFIND.QCF.Object.DC.Title.QCFDefaultValue
Seite 182
xFIND.QCF.Object.LOM.Title
xFIND.QCF.Object.LOM.Title.QCFExplanation
xFIND.QCF.Object.LOM.Title.QCFAllowedSections
xFIND.QCF.Object.LOM.Title.QCFMapping
xFIND.QCF.Object.LOM.Title.QCFDefaultValue
xFIND.QCF.Object.URL
xFIND.QCF.Object.URL.QCFExplanation
xFIND.QCF.Object.URL.QCFAllowedSections
xFIND.QCF.Object.URL.QCFValues
xFIND.QCF.Object.URL.QCFDefaultValue
xFIND.QCF.Object.URL.Text
xFIND.QCF.Object.URL.Text.QCFExplanation
xFIND.QCF.Object.URL.Text.QCFAllowedSections
xFIND.QCF.Object.URL.Text.QCFValues
xFIND.QCF.Object.URL.Text.QCFDefaultValue
xFIND.QCF.Object.Weight
xFIND.QCF.Object.Weight.QCFExplanation
xFIND.QCF.Object.Weight.QCFAllowedSections
xFIND.QCF.Object.Weight.QCFValues
xFIND.QCF.Object.Weight.QCFDefaultValue
xFIND.QCF.Object.Weight.Body
xFIND.QCF.Object.Weight.Body.QCFExplanation
xFIND.QCF.Object.Weight.Body.QCFAllowedSections
xFIND.QCF.Object.Weight.Body.QCFValues
xFIND.QCF.Object.Weight.Body.QCFDefaultValue
xFIND.QCF.Object.Weight.Keyword
xFIND.QCF.Object.Weight.Keyword.QCFExplanation
xFIND.QCF.Object.Weight.Keyword.QCFAllowedSections
xFIND.QCF.Object.Weight.Keyword.QCFValues
xFIND.QCF.Object.Weight.Keyword.QCFDefaultValue
xFIND.QCF.Object.Weight.Meta.<&DOCTAG-Name>
xFIND.QCF.Object.Weight.Meta.<&DOCTAG-Name>.QCFExplanation
xFIND.QCF.Object.Weight.Meta.<&DOCTAG-Name>.QCFAllowedSections
xFIND.QCF.Object.Weight.Meta.<&DOCTAG-Name>.QCFValues
xFIND.QCF.Object.Weight.Meta.<&DOCTAG-Name>.QCFDefaultValue
xFIND.QCF.Object.Weight.Title
xFIND.QCF.Object.Weight.Title.QCFExplanation
xFIND.QCF.Object.Weight.Title.QCFAllowedSections
xFIND.QCF.Object.Weight.Title.QCFValues
xFIND.QCF.Object.Weight.Title.QCFDefaultValue
xFIND.QCF.Object.LastModificationTime
xFIND.QCF.Object.LastModificationTime.QCFExplanation
xFIND.QCF.Object.LastModificationTime.QCFAllowedSections
xFIND.QCF.Object.LastModificationTime.QCFRequiredOperators
xFIND.QCF.<&QCF-KEY-Name>
xFIND.QCF.<&QCF-KEY-Name>.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content
xFIND.QCF.<&QCF-KEY-Name>.Content.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.QCFAllowedSections
Seite 183
xFIND.QCF.<&QCF-KEY-Name>.Content.Type
xFIND.QCF.<&QCF-KEY-Name>.Content.Type.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.Type.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.Type.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.Type.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.Type.QCFDefaultValue
xFIND.QCF.<&QCF-KEY-Name>.Content.Language
xFIND.QCF.<&QCF-KEY-Name>.Content.Language.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.Language.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.Language.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.Language.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.Language.QCFDefaultValue
xFIND.QCF.<&QCF-KEY-Name>.Content.MIME
xFIND.QCF.<&QCF-KEY-Name>.Content.MIME.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.MIME.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.MIME.QCFExample
xFIND.QCF.<&QCF-KEY-Name>.Content.MIME.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.MIME.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.MIME.QCFDefaultValue
xFIND.QCF.<&QCF-KEY-Name>.Content.MIMEVersion
xFIND.QCF.<&QCF-KEY-Name>.Content.MIMEVersion.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.MIMEVersion.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.MIMEVersion.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.MIMEVersion.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.MD5
xFIND.QCF.<&QCF-KEY-Name>.Content.MD5.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.MD5.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.MD5.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.MD5.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.MD5.QCFDefaultValue
xFIND.QCF.<&QCF-KEY-Name>.Content.Length
xFIND.QCF.<&QCF-KEY-Name>.Content.Length.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.Length.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.Length.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.Length.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.Length.QCFDefaultValue
xFIND.QCF.<&QCF-KEY-Name>.Content.Encoding
xFIND.QCF.<&QCF-KEY-Name>.Content.Encoding.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.Encoding.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.Encoding.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.Encoding.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.Encoding.QCFDefaultValue
xFIND.QCF.<&QCF-KEY-Name>.Content.Compression
xFIND.QCF.<&QCF-KEY-Name>.Content.Compression.QCFAllowedSubKeys
xFIND.QCF.<&QCF-KEY-Name>.Content.Compression.QCFExplanation
xFIND.QCF.<&QCF-KEY-Name>.Content.Compression.QCFAllowedSections
xFIND.QCF.<&QCF-KEY-Name>.Content.Compression.QCFValues
xFIND.QCF.<&QCF-KEY-Name>.Content.Compression.QCFDefaultValue
Seite 184
12.2.6. COMPARATOR – Section
xFIND.QCF.COMP.SectionVersionNumber
xFIND.QCF.COMP.SectionVersionNumber.QCFExplanation
xFIND.QCF.COMP.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.COMP.SectionVersionNumber.QCFValues
xFIND.QCF.COMP.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.COMP
xFIND.QCF.COMP.QCFExplanation
xFIND.QCF.COMP.QCFExample
xFIND.QCF.COMP.QCFAllowedSections
xFIND.QCF.COMP.QCFValues
xFIND.QCF.COMP.QCFDefaultValue
12.2.7. MARK - Section = Parenthesis
xFIND.QCF.MARK.SectionVersionNumber
xFIND.QCF.MARK.SectionVersionNumber.QCFExplanation
xFIND.QCF.MARK.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.MARK.SectionVersionNumber.QCFValues
xFIND.QCF.MARK.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.MARK
xFIND.QCF.MARK.QCFExplanation
xFIND.QCF.MARK.QCFExample
xFIND.QCF.MARK.QCFAllowedSections
xFIND.QCF.MARK.QCFValues
xFIND.QCF.MARK.QCFDefaultValue
12.2.8. OPERATOR – Section
xFIND.QCF.OP.SectionVersionNumber
xFIND.QCF.OP.SectionVersionNumber.QCFExplanation
xFIND.QCF.OP.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.OP.SectionVersionNumber.QCFValues
xFIND.QCF.OP.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.OP
xFIND.QCF.OP.QCFExplanation
xFIND.QCF.OP.QCFExample
xFIND.QCF.OP.QCFAllowedSections
xFIND.QCF.OP.QCFValues
xFIND.QCF.OP.QCFDefaultValue
12.2.9. QUERY – Section
xFIND.QCF.Query.SectionVersionNumber
xFIND.QCF.Query.SectionVersionNumber.QCFExplanation
xFIND.QCF.Query.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Query.SectionVersionNumber.QCFValues
xFIND.QCF.Query.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Query
xFIND.QCF.Query.QCFExplanation
xFIND.QCF.Query.QCFAllowedSections
xFIND.QCF.Query.QCFValues
xFIND.QCF.Query.QCFDefaultValue
xFIND.QCF.Query.Costs
xFIND.QCF.Query.Costs.QCFExplanation
xFIND.QCF.Query.Costs.QCFAllowedSections
Seite 185
xFIND.QCF.Query.Costs.QCFValues
xFIND.QCF.Query.Costs.QCFDefaultValue
xFIND.QCF.Query.Costs.QCFRequiredOperators
xFIND.QCF.Query.Evaluation
xFIND.QCF.Query.Evaluation.QCFExplanation
xFIND.QCF.Query.Evaluation.QCFAllowedSections
xFIND.QCF.Query.Evaluation.QCFValues
xFIND.QCF.Query.Evaluation.QCFDefaultValue
xFIND.QCF.Query.Results.Min
xFIND.QCF.Query.Results.Min.QCFExplanation
xFIND.QCF.Query.Results.Min.QCFAllowedSections
xFIND.QCF.Query.Results.Min.QCFValues
xFIND.QCF.Query.Results.Min.QCFDefaultValue
xFIND.QCF.Query.Results.Max
xFIND.QCF.Query.Results.Max.QCFExplanation
xFIND.QCF.Query.Results.Max.QCFAllowedSections
xFIND.QCF.Query.Results.Max.QCFValues
xFIND.QCF.Query.Results.Max.QCFDefaultValue
xFIND.QCF.Query.Results.Offset
xFIND.QCF.Query.Results.Offset.QCFExplanation
xFIND.QCF.Query.Results.Offset.QCFAllowedSections
xFIND.QCF.Query.Results.Offset.QCFValues
xFIND.QCF.Query.Results.Offset.QCFDefaultValue
xFIND.QCF.Query.Results.ID
xFIND.QCF.Query.Results.ID.QCFExplanation
xFIND.QCF.Query.Results.ID.QCFAllowedSections
xFIND.QCF.Query.Results.ID.QCFValues
xFIND.QCF.Query.Results.ID.QCFDefaultValue
12.2.10. RESULT – Section
xFIND.QCF.Result.SectionVersionNumber
xFIND.QCF.Result.SectionVersionNumber.QCFExplanation
xFIND.QCF.Result.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Result.SectionVersionNumber.QCFValues
xFIND.QCF.Result.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Result
xFIND.QCF.Result.QCFExplanation
xFIND.QCF.Result.QCFAllowedSections
xFIND.QCF.Result.Object
xFIND.QCF.Result.Object.QCFExplanation
xFIND.QCF.Result.Object.QCFAllowedSections
xFIND.QCF.Result.Object.Body
xFIND.QCF.Result.Object.Body.QCFExplanation
xFIND.QCF.Result.Object.Body.QCFAllowedSections
xFIND.QCF.Result.Object.Body.QCFValues
xFIND.QCF.Result.Object.Body.QCFDefaultValue
xFIND.QCF.Result.Object.Number
xFIND.QCF.Result.Object.Number.QCFExplanation
xFIND.QCF.Result.Object.Number.QCFAllowedSections
xFIND.QCF.Result.Object.Number.QCFValues
xFIND.QCF.Result.Object.Number.QCFDefaultValue
Seite 186
xFIND.QCF.Result.Object.Title
xFIND.QCF.Result.Object.Title.QCFExplanation
xFIND.QCF.Result.Object.Title.QCFAllowedSections
xFIND.QCF.Result.Object.Title.QCFValues
xFIND.QCF.Result.Object.Title.QCFDefaultValue
xFIND.QCF.Result.Object.URL
xFIND.QCF.Result.Object.URL.QCFExplanation
xFIND.QCF.Result.Object.URL.QCFAllowedSections
xFIND.QCF.Result.Object.URL.QCFValues
xFIND.QCF.Result.Object.URL.QCFDefaultValue
xFIND.QCF.Result.Object.Quality
xFIND.QCF.Result.Object.Quality.QCFExplanation
xFIND.QCF.Result.Object.Quality.QCFAllowedSections
xFIND.QCF.Result.Object.Quality.QCFValues
xFIND.QCF.Result.Object.Quality.QCFDefaultValue
xFIND.QCF.Result.Object.Keywords
xFIND.QCF.Result.Object.Keywords.QCFExplanation
xFIND.QCF.Result.Object.Keywords.QCFExample
xFIND.QCF.Result.Object.Keywords.QCFAllowedSections
xFIND.QCF.Result.Object.Keywords.QCFValues
xFIND.QCF.Result.Object.Keywords.QCFDefaultValue
xFIND.QCF.Result.Hits
xFIND.QCF.Result.Hits.QCFExplanation
xFIND.QCF.Result.Hits.QCFAllowedSections
xFIND.QCF.Result.Hits.QCFValues
xFIND.QCF.Result.Hits.QCFDefaultValue
xFIND.QCF.Result.Hits.Returned
xFIND.QCF.Result.Hits.Returned.QCFExplanation
xFIND.QCF.Result.Hits.Returned.QCFAllowedSections
xFIND.QCF.Result.Hits.Returned.QCFValues
xFIND.QCF.Result.Hits.Returned.QCFDefaultValue
xFIND.QCF.Result.Site
xFIND.QCF.Result.Site.QCFExplanation
xFIND.QCF.Result.Site.QCFAllowedSections
xFIND.QCF.Result.Site.Body
xFIND.QCF.Result.Site.Body.QCFExplanation
xFIND.QCF.Result.Site.Body.QCFAllowedSections
xFIND.QCF.Result.Site.Body.QCFValues
xFIND.QCF.Result.Site.Body.QCFDefaultValue
xFIND.QCF.Result.Site.Quality
xFIND.QCF.Result.Site.Quality.QCFExplanation
xFIND.QCF.Result.Site.Quality.QCFAllowedSections
xFIND.QCF.Result.Site.Quality.QCFValues
xFIND.QCF.Result.Site.Quality.QCFDefaultValue
xFIND.QCF.Result.Site.Title
xFIND.QCF.Result.Site.Title.QCFExplanation
xFIND.QCF.Result.Site.Title.QCFAllowedSections
xFIND.QCF.Result.Site.Title.QCFValues
xFIND.QCF.Result.Site.Title.QCFDefaultValue
xFIND.QCF.Result.Site.URL
xFIND.QCF.Result.Site.URL.QCFExplanation
xFIND.QCF.Result.Site.URL.QCFAllowedSections
Seite 187
xFIND.QCF.Result.Site.URL.QCFValues
xFIND.QCF.Result.Site.URL.QCFDefaultValue
xFIND.QCF.Result.ReturnLayout
xFIND.QCF.Result.ReturnLayout.QCFExplanation
xFIND.QCF.Result.ReturnLayout.QCFAllowedSections
xFIND.QCF.Result.ReturnLayout.QCFValues
xFIND.QCF.Result.ReturnLayout.QCFDefaultValue
12.2.11. SITE-DESCRIPTION – Section
xFIND.QCF.Site.SectionVersionNumber
xFIND.QCF.Site.SectionVersionNumber.QCFExplanation
xFIND.QCF.Site.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Site.SectionVersionNumber.QCFValues
xFIND.QCF.Site.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Site.Body
xFIND.QCF.Site.Body.QCFExplanation
xFIND.QCF.Site.Body.QCFAllowedSections
xFIND.QCF.Site.Body.QCFValues
xFIND.QCF.Site.Body.QCFDefaultValue
xFIND.QCF.Site.Title
xFIND.QCF.Site.Title.QCFExplanation
xFIND.QCF.Site.Title.QCFAllowedSections
xFIND.QCF.Site.Title.QCFValues
xFIND.QCF.Site.Title.QCFDefaultValue
xFIND.QCF.Site.URL
xFIND.QCF.Site.URL.QCFExplanation
xFIND.QCF.Site.URL.QCFAllowedSections
xFIND.QCF.Site.URL.QCFValues
xFIND.QCF.Site.URL.QCFDefaultValue
xFIND.QCF.Site.Quality
xFIND.QCF.Site.Quality.QCFExplanation
xFIND.QCF.Site.Quality.QCFAllowedSections
xFIND.QCF.Site.Quality.QCFValues
xFIND.QCF.Site.Quality.QCFDefaultValue
12.2.12. STATISTIC – Section
xFIND.QCF.Stats.SectionVersionNumber
xFIND.QCF.Stats.SectionVersionNumber.QCFExplanation
xFIND.QCF.Stats.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Stats.SectionVersionNumber.QCFValues
xFIND.QCF.Stats.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Stats.Hits
xFIND.QCF.Stats.Hits.QCFExplanation
xFIND.QCF.Stats.Hits.QCFAllowedSections
xFIND.QCF.Stats.Hits.QCFValues
xFIND.QCF.Stats.Hits.QCFDefaultValue
xFIND.QCF.Stats.Object.Hits
xFIND.QCF.Stats.Object.Hits.QCFExplanation
xFIND.QCF.Stats.Object.Hits.QCFAllowedSections
xFIND.QCF.Stats.Object.Hits.QCFValues
xFIND.QCF.Stats.Object.Hits.QCFDefaultValue
Seite 188
xFIND.QCF.Stats.Site.Hits
xFIND.QCF.Stats.Site.Hits.QCFExplanation
xFIND.QCF.Stats.Site.Hits.QCFAllowedSections
xFIND.QCF.Stats.Site.Hits.QCFValues
xFIND.QCF.Stats.Site.Hits.QCFDefaultValue
xFIND.QCF.Stats.Costs
xFIND.QCF.Stats.Costs.QCFExplanation
xFIND.QCF.Stats.Costs.QCFAllowedSections
xFIND.QCF.Stats.Costs.QCFValues
xFIND.QCF.Stats.Costs.QCFDefaultValue
xFIND.QCF.Stats.Error.Count
xFIND.QCF.Stats.Error.Count.QCFExplanation
xFIND.QCF.Stats.Error.Count.QCFAllowedSections
xFIND.QCF.Stats.Error.Count.QCFValues
xFIND.QCF.Stats.Error.Count.QCFDefaultValue
xFIND.QCF.Stats.Warning.Count
xFIND.QCF.Stats.Warning.Count.QCFExplanation
xFIND.QCF.Stats.Warning.Count.QCFAllowedSections
xFIND.QCF.Stats.Warning.Count.QCFValues
xFIND.QCF.Stats.Warning.Count.QCFDefaultValue
xFIND.QCF.Stats.DifferentWebAreas
xFIND.QCF.Stats.DifferentWebAreas.QCFExplanation
xFIND.QCF.Stats.DifferentWebAreas.QCFAllowedSections
xFIND.QCF.Stats.DifferentWebAreas.QCFValues
xFIND.QCF.Stats.DifferentWebAreas.QCFDefaultValue
xFIND.QCF.Stats.SearchWord.<&ID-Number>
xFIND.QCF.Stats.SearchWord.<&ID-Number>.QCFExplanation
xFIND.QCF.Stats.SearchWord.<&ID-Number>.QCFAllowedSections
xFIND.QCF.Stats.SearchWord.<&ID-Number>.QCFValues
xFIND.QCF.Stats.SearchWord.<&ID-Number>.QCFDefaultValue
xFIND.QCF.Stats.SearchWord.<&ID-Number>.Count
xFIND.QCF.Stats.SearchWord.<&ID-Number>.Count.QCFExplanation
xFIND.QCF.Stats.SearchWord.<&ID-Number>.Count.QCFAllowedSections
xFIND.QCF.Stats.SearchWord.<&ID-Number>.Count.QCFValues
xFIND.QCF.Stats.SearchWord.<&ID-Number>.Count.QCFDefaultValue
xFIND.QCF.Stats.OldestObject
xFIND.QCF.Stats.OldestObject.QCFExplanation
xFIND.QCF.Stats.OldestObject.QCFAllowedSections
xFIND.QCF.Stats.OldestObject.QCFValues
xFIND.QCF.Stats.OldestObject.QCFDefaultValue
xFIND.QCF.Stats.NewestObject
xFIND.QCF.Stats.NewestObject.QCFExplanation
xFIND.QCF.Stats.NewestObject.QCFAllowedSections
xFIND.QCF.Stats.NewestObject.QCFValues
xFIND.QCF.Stats.NewestObject.QCFDefaultValue
xFIND.QCF.Stats.Language.Count
xFIND.QCF.Stats.Language.Count.QCFExplanation
xFIND.QCF.Stats.Language.Count.QCFAllowedSections
xFIND.QCF.Stats.Language.Count.QCFValues
xFIND.QCF.Stats.Language.Count.QCFDefaultValue
Seite 189
12.2.13. URL – Section
xFIND.QCF.URL.SectionVersionNumber
xFIND.QCF.URL.SectionVersionNumber.QCFExplanation
xFIND.QCF.URL.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.URL.SectionVersionNumber.QCFValues
xFIND.QCF.URL.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.URL
xFIND.QCF.URL.QCFExplanation
xFIND.QCF.URL.QCFAllowedSections
xFIND.QCF.URL.QCFValues
xFIND.QCF.URL.QCFDefaultValue
xFIND.QCF.URL.QCFRequiredOperators
12.2.14. WARNING – Section
xFIND.QCF.Warning.SectionVersionNumber
xFIND.QCF.Warning.SectionVersionNumber.QCFExplanation
xFIND.QCF.Warning.SectionVersionNumber.QCFAllowedSections
xFIND.QCF.Warning.SectionVersionNumber.QCFValues
xFIND.QCF.Warning.SectionVersionNumber.QCFDefaultValue
xFIND.QCF.Warning.Key.<&REQUEST-KEY-Name>
xFIND.QCF.Warning.Key.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Warning.Key.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Warning.Key.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Warning.Key.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Warning.Explanation.<&REQUEST-KEY-Name>
xFIND.QCF.Warning.Explanation.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Warning.Explanation.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Warning.Explanation.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Warning.Explanation.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Warning.Message.<&REQUEST-KEY-Name>
xFIND.QCF.Warning.Message.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Warning.Message.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Warning.Message.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Warning.Message.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Warning.ID.<&REQUEST-KEY-Name>
xFIND.QCF.Warning.ID.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Warning.ID.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Warning.ID.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Warning.ID.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Warning.Type.<&REQUEST-KEY-Name>
xFIND.QCF.Warning.Type.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Warning.Type.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Warning.Type.<&REQUEST-KEY-Name>.QCFValues
xFIND.QCF.Warning.Recover.<&REQUEST-KEY-Name>
xFIND.QCF.Warning.Recover.<&REQUEST-KEY-Name>.QCFExplanation
xFIND.QCF.Warning.Recover.<&REQUEST-KEY-Name>.QCFExample
xFIND.QCF.Warning.Recover.<&REQUEST-KEY-Name>.QCFAllowedSections
xFIND.QCF.Warning.Recover.<&REQUEST-KEY-Name>.QCFValues
Seite 190
Anhang B - xQMS Spezifikation
Anhang B
13. xQMS Spezifikation
xQMS steht für xFIND Quality Metadata Scheme. xQMS liegt zurzeit in der Version
V1.0 vor. Die vorliegende Version umfasst 34 Elemente die in zwei grobe
Unterkategorien unterteilt werden. Beschreibende Attribute und bewertende Attribute.
Die beschreibenden Attribute bzw. Elemente sind an den DDC und LOM Standard
angelehnt. Für die bewertenden Attribute sind diese Standards erweitert worden, um ein
„Rating“ der Quellen durch eine qualifizierte Person oder Organisation zu ermöglichen.
[Heber 2000]
Beschreibende Attribute:
xQMS.Creator.Person
xQMS.Creator.Organisation
verantwortlich ist
xQMS.Creator.Publisher
xQMS.Tech.Ident
xQMS.Tech.Scope
Webbereich)
xQMS.Tech.Signature
xQMS.Content.Type
xQMS.Content.Title
xQMS.Content.Topic
xQMS.Content.Alt_Topic
Schema
xQMS.Content.Alt_Classident
xQMS.Content.Keywords
xQMS.Content.Description
xQMS.Content.Quotation
xQMS.Content.Language
xQMS.Version.Number
xQMS.Version.Prev
xQMS.Version.Next
xQMS.Version.Create
xQMS.Version.Last_modified
Person, die den Inhalt der Ressource verfasst hat
Organisation, die für die Erstellung des
Inhaltes
Person, Organisation etc., die die Ressource zugänglich macht
Ort der Ressource (z.B. URL, URN, URI oder DOI)
Gültigkeitsbereich der Beschreibung (z.B. Webpage,
Checksumme für Kontrollzwecke
Art des Inhaltes der Ressource (z.B. Text, Audio)
Name der Ressource
Thema des Inhaltes der Ressource nach Dewey
zusätzliches Thema entsprechend dem nach genannten
zusätzlich verwendetes Klassifikationsschema
frei wählbare Schlüsselwörter zum Inhalt der Ressource
Zusammenfassung des Inhaltes der Ressource
Art und Weise, wie die Ressource zitiert werden soll
Sprache, in der Inhalt der Ressource verfasst ist
Versionsnummer der beschriebenen Ressource
Referenz der vorherigen Version, Angabe der URL
Referenz der folgenden Version, Angabe der URL
Datum der Erstellung
Datum der letzten Aktualisierung
Bewertende Attribute:
xQMS.Myop.Diction
xQMS.Myop.Audience.Age
xQMS.Myop.Audience.Knowledge
xQMS.Myop.Authority
xQMS.Myop.Accuracy.Depth
xQMS.Myop.Accuracy.Width
xQMS.Rating.Creator.Person
xQMS.Rating.Creator.Organisation
xQMS.Rating.Creator.Publisher
xQMS.Rating.Content.Language
xQMS.Rating.Version.Last_modiefied
xQMS.Rating.Version.Time_to_live
xQMS.Rating.Tech.Signature
Ausdruck, Stil der Sprache (z.B. einfach, anspruchsvoll)
empfohlenes Mindestalter der Zielgruppe
vorausgesetztes Vorwissen der Zielgruppe
Bewertung nach wissenschaftlichem Ansehen
Informationstiefe
Informationsbreite
Person, die die Bewertung durchführt
Bewertungsagentur
Organisation, die die Bewertung zugänglich macht
Sprache, in der die Bewertung verfasst ist
Datum der letzten Aktualisierung der Bewertung
Lebensdauer der Bewertung
verschlüsselte Signatur der Bewertung
Seite 191
Anhang C
14. Profiling Analyse Ergebnisse
Aus der Profiling Analyse wurden für die verschiedenen Testdurchlaufe die „CallTrees“ extrahiert. Diese zeigen Schematisch den strukturellen Ablauf des
Datentransportes. Aus Platzgründen bez. der Darstellung ist nur die Minimaldarstellung
der jeweiligen Call-Trees abgebildet. Vergrößerungen dieser Call-Trees sind auf der
beiliegenden CD-ROM enthalten.
14.1. Call Graph xFIND Client
Abbildung 14.1: xFIND-Client Call Graph Main Thread
Abbildung 14.2: xFIND-Client Call Graph Sender Thread
14.2. Call Graph xFIND Manager
Abbildung 14.3: xFIND-Manager Call Graph Main Thread
Seite 192
Anhang C - Profiling Analyse Ergebnisse
14.3. Call Graph BEEP Client N-N
Abbildung 14.4: Beep-Client Call Graph Main Thread
Abbildung 14.5: Beep-Client Call Graph Worker Thread 1
14.4. Call Graph BEEP Daemon N-N
Abbildung 14.6: Beep-Daemon Call Graph Worker Thread 1
Seite 193
Abbildung 14.9: Beep-Daemon Call Graph TCP Thread 1
14.5. Call Graph BEEP Client N-TLS
Abbildung 14.10: Beep-Client Call Graph TLS Main Thread
Abbildung 14.11: Beep-Client Call Graph TLS Worker Thread 1
Seite 194
Anhang D - Verzeichnisse
Anhang D
15. Verzeichnisse
15.1. Tabellenverzeichnis
Tabelle 2.1: Internet Wachstumsrate Jahr 2002 (http://www.netcraft.com/survey) ...........................................9
Tabelle 4.1: Übersicht über Topologien verteilter Anwendungen nach [Minar 2001][Minar 2002]................26
Tabelle 4.2: Unterschiede zwischen NFS und AFS/DFS – Systemen [Transarc 1996]. ..................................35
Tabelle 4.3: Übersicht der von ONE unterstützten Kernstandards [SUN 2001] ..............................................60
Tabelle 5.1: Eigenschaften von Transport Protokollen ....................................................................................96
Tabelle 7.1: Datenpaket des xFIND Server-Ticket ........................................................................................ 120
Tabelle 7.2: Datenpaket des xFIND Service-Requests .................................................................................. 120
Tabelle 7.3: Datenpaket des xFIND Data-Header.......................................................................................... 121
Tabelle 7.4: Datenpaket des xFIND Data-Footer........................................................................................... 121
Tabelle 7.5: Benchmark-Test Übertragungszeit xFIND Kommunikationsschicht ......................................... 123
Tabelle 8.1: Benchmark-Test BEEP ECHO-Profil, localhost PC1 ................................................................ 134
Tabelle 8.2: Benchmark-Test BEEP ECHO-Profil, remote (Client-PC2, Deamon-PC3) .............................. 135
Tabelle 8.3: Vergleich des Datendurchsatzes der Kommunikation von xFIND und BEEP ........................... 138
15.2. Listingverzeichnis
Listing 5.1: Beispiel einer BEEP Anfrage an einen Server [RFC 3080] ..........................................................84
Listing 5.2: Beispiel eines serialisierten XML-RPC Aufrufes [Userland] .......................................................85
Listing 8.1: BEEP Initialisierungsvorgang zwischen Client und Server [RFC 3080] .................................... 131
Listing 9.1: JXTA Discovery Query Schema [JXTA v2.0] ........................................................................... 144
Listing 9.2: JXTA Discovery Response Schema [JXTA v2.0] ...................................................................... 145
Listing 9.3: JXTA PIP Query Message Schema [JXTA v2.0] ....................................................................... 146
Listing 9.4: JXTA PIP Response Message Schema [JXTA v2.0].................................................................. 146
Listing 9.5: JXTA Pipe Advertisement Schema [JXTA v2.0] ....................................................................... 147
Listing 9.6: JXTA Pipe Resolver Message Schema [JXTA v2.0].................................................................. 147
Listing 9.7: JXTA Resolver Query Message Schema [JXTA v2.0]............................................................... 148
Listing 9.8: JXTA Resolver Response Schema [JXTA v2.0] ........................................................................ 148
Listing 9.9: JXTA Rendezvous Advertisement Schema [JXTA v2.0] ........................................................... 149
Listing 9.10: JXTA Rendezvous Propagate Message Schema [JXTA v2.0].................................................. 149
Listing 9.11: JXTA Route Advertisement Schema [JXTA v2.0]................................................................... 150
Listing 9.12: JXTA Route Query Message Schema [JXTA v2.0] ................................................................. 150
Listing 9.13: JXTA Route Response Message Schema [JXTA v2.0] ............................................................ 151
Listing 9.14: JXTA Peer Advertisement Schema [JXTA v2.0] ..................................................................... 152
Listing 9.15: JXTA Peer Group Advertisement Schema [JXTA v2.0] .......................................................... 152
Listing 9.16: JXTA Module Class Advertisement Schema [JXTA v2.0]....................................................... 153
Listing 9.17: JXTA Module Specification Advertisement Schema [JXTA v2.0] .......................................... 154
Listing 9.18: JXTA Module Implementation Advertisement Schema [JXTA v2.0] ...................................... 154
Listing 9.19: JXTA Framework starten ......................................................................................................... 157
Listing 9.20: Erstellen eines neuen JXTA Service......................................................................................... 160
Seite 195
15.3. Abbildungsverzeichnis
Abbildung 2.1: Wachstum des Internet (Anzahl an Webseiten) [Zakon 2002]..................................................8
Abbildung 2.2: Discovery vermittelt zwischen Dienstleister und Konsument [Ianella 1997]..........................10
Abbildung 3.1: Verteiltes System ohne Betriebssystemunterstützung [Weber 1998]......................................19
Abbildung 3.2: Netzwerkbetriebssystem [Weber 1998] ..................................................................................19
Abbildung 3.3: Verteiltes Betriebssystem [Weber 1998].................................................................................19
Abbildung 3.4: RPC - Funktionsweise [Weber 1998]......................................................................................21
Abbildung 3.5: RPC - OSI Schichtenmodell [Schlichter 2000] .......................................................................22
Abbildung 4.1: Struktur in einem AFS System mit eindeutiger Namensgebung [Transarc 1996]...................35
Abbildung 4.2: Granularität in Komponentenbasierter Softwareentwicklung [Fähnrich 2001].......................37
Abbildung 4.3: Architektur der DCE Systemumgebung [Nehmer et all 1998]................................................46
Abbildung 4.4: COM Schnittstelle: Schnittstellenzeiger, Methodenzeiger [Stal 1998] ...................................49
Abbildung 4.5: Schematischer Verbindungsaufbau im COM-Objektmodell [Koch 1998]..............................50
Abbildung 4.6: COM Objektreferenzierung mittels Proxy/Stub Technologie [Williams et all 1994] .............50
Abbildung 4.7: Architektur des DCOM Ansatzes [Horstmann 1997]..............................................................51
Abbildung 4.8: Isolierung Kritischer Prozesse und Auslagerung auf eigene Server [MS 1996]......................53
Abbildung 4.9: Lastverteilung mittels Brokermechanismus in DCOM [MS 1996] .........................................53
Abbildung 4.10: Entwicklung von Web-Services mit .NET Component Ware [Vawter et al. 2001] ..............55
Abbildung 4.11: J2EE Multi-Tier Applikationen [Bodoff et al. 2002] ............................................................57
Abbildung 4.12: Entwicklung von Web-Services mittels J2EE [Vawter et al. 2001] ......................................58
Abbildung 4.13: J2EE Server und Container [Bodoff et al. 2002]...................................................................59
Abbildung 4.14: Web-Service Architektur in der ONE Plattform [SUN 2001]...............................................61
Abbildung 4.15: ONE DART Modell zum effizienten Entwurf online basierter Dienste [SUN 2001] ...........61
Abbildung 4.16 Ein einfaches Dinopolis Objekt [Schmaranz 2002]................................................................63
Abbildung 4.17 Dinopolis System Architektur [Schmaranz 2002]..................................................................65
Abbildung 4.18: UDDI Business Registry [Sleeper 2001]...............................................................................67
Abbildung 4.19: Konzept möglicher UDDI Register Typen und deren Interaktionen [Stencil 2002]..............68
Abbildung 4.20: UDDI Register Schema [UDDI 2000] ..................................................................................69
Abbildung 5.1: Darstellung des abstrakten Protokollmodells [Gottswinter 1996]...........................................77
Abbildung 5.2: Designvergleich des BEEP Protokolls zu herkömmlichen Protokollen [RR 2002] ................83
Abbildung 5.3: XML-RPC Datenfluss [Userland]...........................................................................................85
Abbildung 5.4: Objektmethodenaufruf in SOAP über HTTP [Skribner et all 2001] .......................................88
Abbildung 5.5: Herkömmlicher Datentransfer im Internet, Seriell, fest verbunden [Jabber 2002a] ................90
Abbildung 5.6: Jabber Datentransfer: XML-Streaming, asynchron, lose gekoppelt [Jabber 2002a] ...............90
Abbildung 5.7: Jabber in Zusammenhang mit Firewall geschütztem Zugriff [Jabber 2002a]..........................90
Abbildung 5.8: Vereinfachte Architektur der Jabber Communication Plattform [Saint-Andre 2003] .............91
Abbildung 5.9: JXTA Core Protokollstruktur [Duigou 2003]..........................................................................93
Abbildung 6.1: Freenet Search Algorithmus [Clark et al. 2002]......................................................................99
Abbildung 6.2: JXTA Software Architektur [Gong 2002]............................................................................. 102
Abbildung 6.3: Netzwerk Architektur von JXTA Search [Waterhouse 2001] ............................................... 103
Abbildung 6.4: Verteilte Suche in JXTA Search [Waterhouse 2001]............................................................ 104
Abbildung 6.5: Verteilte Architektur eines Harvest Suchsystems [Bowman et al. 1995] .............................. 106
Abbildung 6.6: Verteilte Architektur des xFIND Suchsystems [Gütl 2002].................................................. 107
Abbildung 7.1: Datenfluss der xFIND Kommunikation zwischen Client und Server [xFIND 2003] ............ 117
Abbildung 7.2: Blockdarstellung der xFIND Indexer-Gatherer Kommunikation [xFIND 2003] .................. 118
Abbildung 7.3: Blockdarstellung einer Broker-Indexer Suchanfrage [xFIND 2003]..................................... 119
Abbildung 7.4: Blockdiagramm der xFIND Client-Server Simulation .......................................................... 122
Seite 196
Abbildung 7.5: Kennlinien für Benchmark-Test xFIND Client-Server 1kB-200kB...................................... 124
Abbildung 7.6: Kennlinien für Benchmark-Test xFIND Client-Server 200kB-5MB .................................... 124
Abbildung 8.1: BEEP Frame Syntax [RFC 3080] ......................................................................................... 128
Abbildung 8.2: BEEP Sequence Frame Syntax [RFC 3081] ......................................................................... 129
Abbildung 8.3: Grafische Darstellung der BEEP Frame-Syntax ................................................................... 130
Abbildung 8.4: Blockdiagramm des BEEP Client-Server Testaufbaus ......................................................... 132
Abbildung 8.5: Kennlinien für Benchmark-Test BEEP ECHO-Profil, localhost-PC1................................... 134
Abbildung 8.6: Kennlinien für Benchmark-Test BEEP ECHO-Profil, remote (Client-PC2, Deamon-PC3) . 136
Abbildung 8.7: Profiling-Test, Speicherauslastung von xFIND (links) und BEEP (rechts)........................... 139
Abbildung 8.8: CPU Belastung und Speicherabbild von Windows Taskmanager für xFIND und BEEP ..... 139
Abbildung 9.1: JXTA Protokoll Stack [Wilson 2002] ................................................................................... 143
Abbildung 9.2: Blockdiagramm der JXTA Client-Server Testimplementierung ........................................... 157
Abbildung 9.3: Klassendiagramm der xFIND JXTA Testimplementierung .................................................. 158
Abbildung 14.1: xFIND-Client Call Graph Main Thread .............................................................................. 191
Abbildung 14.2: xFIND-Client Call Graph Sender Thread ........................................................................... 191
Abbildung 14.3: xFIND-Manager Call Graph Main Thread.......................................................................... 191
Abbildung 14.4: Beep-Client Call Graph Main Thread ................................................................................. 192
Abbildung 14.5: Beep-Client Call Graph Worker Thread 1 .......................................................................... 192
Abbildung 14.6: Beep-Daemon Call Graph Worker Thread 1....................................................................... 192
Abbildung 14.9: Beep-Daemon Call Graph TCP Thread 1............................................................................ 193
Abbildung 14.10: Beep-Client Call Graph TLS Main Thread ....................................................................... 193
Abbildung 14.11: Beep-Client Call Graph TLS Worker Thread 1 ................................................................ 193
Seite 197
15.4. Numerische Aufzählung von RFC Referenz Dokumenten
[RFC 791] [STD 5]
[RFC 822]
[RFC 850]
[RFC 977]
[RFC 1035]
[RFC 1036]
[RFC 1094]
[RFC 1123]
[RFC 1150] [FYI 1]
[RFC 1153]
[RFC 1264]
[RFC 1305]
[RFC 1311]
[RFC 1813]
[RFC 1818] [BCP 1]
[RFC 1866]
[RFC 2026]
[RFC 2076]
[RFC 2141]
[RFC 2223]
[RFC 2234]
[RFC 2251]
[RFC 2500]
[RFC 2629]
[RFC 2779]
[RFC 3000] [STD 1]
[RFC 3080]
[RFC 3081]
[RFC 3288]
[RFC 3529]
Internet Protocol DARPA Internet Program Protocol Specification
Standard for the format of ARPA INTERNET Text Messages
Standard for Interchange of USENET Messages
Network News Transfer Protocol
Domain Names - Implementation and Specification
Standard for Interchange of USENET Messages
NFS: Network File System Protocol Specification [RFC 1813]
Requirements for Internet Hosts -- Application and Support
F.Y.I. on F.Y.I.; Introduction to the F.Y.I. Notes
Digest Message Format
Internet Routing Protocol Standardization Criteria
Network Time Protocol (Version 3)
Introduction to the STD Notes
NFS Version 3 Protocol Specification
Best Current Practices
Hypertext Markup Language - 2.0
The Internet Standards Process -- Revision 3
Common Internet Message Headers
URN Syntax
Instructions to RFC Authors
Augmented BNF for Syntax Specifications: ABNF
Lightweight Directory Access Protocol (v3)
Internet Official Protocol Standards
Writing I-Ds and RFCs using XML
Instant Messaging / Presence Protocol Requirements
The Blocks Extensible Exchange Protocol Core
Mapping the BEEP Core onto TCP
Using SOAP in BEEP
Using XML-RPC in BEEP
[STD 1] [RFC 3000]
[STD 5] [RFC 791]
Internet Protocol DARPA Internet Program Protocol Specification
Seite 198
15.5. Literatur und Quellenverzeichnis
[Aichriedler et al. 2000] Aichriedler, T.; Gütl, C.; Forstinger, H.; Heber, J.; Knögler, B.; Maurer, H.; Neussl,
D.; Reif, G.; Weizer, J.: WWW-Wissensorganisation, Forschungsbereicht an der
Technischen Universität Graz, IICM, Februar 2000, Last Visit: 01.04.2001;
http://www2.iicm.edu/cguetl/papers/km_www/wissen_end_v08.htm
[Balzert 2001]
Balzert, H.: Lehrbuch der Softwaretechnik – Softwareentwicklung, Verlag
Spektrum, April 2001, Band 1, 2. Auflage, S 858 - 870
[Birrel et al. 1993]
Birrel, D. A.; Hisgen, A.; Jerian, C.; Mann, T.; Swart, G.: The Echo
Distributed File System, digital SystemsResearch Center, 10.9.1993
[Bjorklund 1997]
Bjorklund G.: Transaction Logging Concepts, Engine Crew Monograph No.4,
Progress Software Corporation, Last Update: 20.07.1997 Last Visit: 07.10.2001;
http://www.peg.com/techpapers/monographs/logging/logging.html
[Bodoff et al. 2002]
Bodoff, S.; Green, D.; Haase, K.; Jendrock, E.; Pawlan, M.; Stearns, B.:
The J2EE Tutorial, Addison-Wesley, März 2002, S 1 – 20
[Booth et al. 2003]
Booth D.; Haas H.; McCabe F.; Newcomer I.; Champion M.; Ferris C.; Orchard
D.: Web Services Architecture, W3C Working Draft, August 2003, last Visit:
04.01.2004, last Update 08.08.2003; http://www.w3.org/TR/ws-arch/
[Bowman et al. 1995]
Bowman, C. M., Danzig, P. B.; Hardy, D. R.; Manber, U.; Schwartz, M. F.;
Wessels, D. P.: Harvest: A Scalable, Customizable Discovery and Access System,
Technical Report CU-CS-732-94, Department of Computer Science University of
Colorado - Boulder, März 1995, Last Visit: 30.05.2004;
http://www.codeontheroad.com/papers/Harvest.Jour.pdf
[Cailliau 1995]
Cailliau, R.: A Little History of the World Wide Web, from 1945 to 1995, W3C,
Last Update: 24.11.2001, Last Visit: 30.12.2002;
http://www.w3.org/History.html
[Cerami 2002]
Cerami E.: Web Services Essentials, O’Reilly, O’Reilly Online Catalog, Februar
2002, Kapitel 6 WSDL Essentials
[Chen 1995]
Chen G.: Distributed Transaction Processing Standards and their applications; CiTR
Technical Journal Volume 1 1996, Seiten 41-51; Computer Standards and Interfaces
17 1995, Seiten 363-373.
[Clark et al. 2002]
Clark. I.; Miller, S.: Protecting Free Expression Online with Freenet, IEEE
INTERNET COMPUTING,
[Dreßler 2002]
Dreßler S.: Daten - Information - Wissen – Bildung, Friedrich Nauman Stiftung,
Arbeitskreis Bildung der Stipendiaten; Last Update: 17.04.2002,
Last Visit: 20.03.2003; http://surjo.bei.t-online.de/seb.htm
[Duigou 2003]
Duigou M.: JXTA v2.0 Protocols Specification, draft-jxta-protocols-03, IETF,
15. Oktober 2003, Last Visit: 08.01.2003, Last Update: 15.10.2003;
http://spec.jxta.org/nonav/v1.0/docbook/JXTAProtocols.txt
[Fähnrich 2001]
Fähnrich, K. P.: Vorlesung Componentware, Universität Leipzig für Institut für
Informatik, Wintersemester 2001/2001, Last Visit: 07.10.2001 ;
http://pcai007.informatik.uni-leipzig.de
[Freismuth 2002]
Freismuth, D.: Peer-to-Peer Eintagsfliege oder Zukunftsmodell, IICM, Februar 2002
[Glossar 2003]
ARCHmatic – Alfons Oebbeke; ARCHmatic-Glossar und –Lexikon;
Lat Update: 07.03.2003, Last Visit: 20.03.2003;
http://www.glossar.de/glossar/z_verschluessel.htm
[Gong 2002]
Gong. L.: Project JXTA: A Technology Overview, Sun Microsystems, Inc., 29.
Oktober 2002, Last Visit: 15.10.2003;
http://www.jxta.org
Seite 199
[Gottswinter 1996]
Gottswinter, E.: Praktischer Einsatz einer SR-Testumgebung Projektbericht: Das
SR/Z39.50—1995 Protokoll, Universitätsbibliothek Karlsruhe, 12.01.1996,
http://www.ubka.uni-karlsruhe.de/dfg/bericht/node29.html
[Gütl 2002]
Gütl, C.: Ansätze zur modernen Wissensauffindung im Internet, Dissertation
an der Technischen Universität Graz, IICM, 09.2002, Last Update:
29.11.2002, Last Visit: 30.12.2002;
http://www.iicm.edu/thesis/cguetl_diss/diss_cguetl.pdf
[Hamilton 1997]
Hamilton, G.: JavaBeans API specification, Sun Microsystems, version 1.01,
http://java.sun.com/products/javabeans
[Hardy et al. 2002]
Hardy, D. R.; Schwartz, M. F.; Wessels, D.; Lee, K.: Harvest User's Manual,
Version 1.8, University of Edingburgh, 29. Oktober 2002, Last Visit: 30.05.2004;
http://harvest.sourceforge.net/harvest-1.8/doc/html/manual.html
[Hartmann 1999]
Hartmann, F.: Cyber.Philosophy, Medientheoretische Auslotungen, PassagenVerlag, unveränderte Neuauflage von 1996, Seiten 141-143
[Heber 2000]
Heber, J.: Knowledge Discovery Broker-Entwicklungsarbeiten für das xFINDSuchsystem, Diplomarbeit an der Technischen Universität Graz, IICM, 07.2000,
http://www.iicm.edu/thesis/jheber
[Hoffmann 2002]
Hoffmann, R.: Entwicklung einer benutzerunterstützten automatisierten
Klassifikation von Web – Dokumenten, Diplomarbeit an der Technischen
Universität Graz, IICM, Dezember 2002, Last Update: 13.03.2003, Last Visit:
14.06.2003; http://www.iicm.edu/thesis/rhoff
[Hofstetter et al. 2003]
Hofstetter S., Ilg A.: Einführung in ebXML, Bericht zum Fachseminar Information
und Kommunikation, Inst. f. Informationssysteme ETH Zürich, 25 Juni 2003, Last
Update: 25.06.2003, Last Visit: 02.01.2004;
http://n.ethz.ch/student/jodaniel/37-310/reports/ebxml-bericht_Ilg&Hofstetter.pdf
[Ianella 1997]
Ianella, R.: The Resource Discovery Poroject, Ariadne, März 1997,
http://www.ariadne.ac.uk/issue8/resource-discovery
[IFLANET 1995]
IFLANET: Models for Open System Protocol Development; UDT Series on Data
Communication Technologies and Standards for Libraries, International Federation
of Library Associations and Institutions, Last Update: 06.03.2003, Last Visit:
12.12.2004; http://www.ifla.org/VI/5/reports/rep6/68.htm
[Jabber 2001a]
Jabber: Jabber Communications Platform 1.2, Document J112, Product Guide,
Dezember 2001, Jabber Inc., Last Visit: 20.02.2003;
http://www.jabber.com/pdf/JCP_ProductGuide.pdf
[Jabber 2001b]
Jabber: Jabber Communications Platform Architecture Description, A technical
white paper, Dezember 2001, Jabber Inc., Last Visit: 20.02.2003
http://www.jabber.com/pdf/Jabber_Architecture.pdf
[Jabber 2002a]
Jabber: Jabber for Web Services: Extensible Messaging to Executable Internet,
Jänner 2002, white paper, Jabber Inc., Last Visit: 20.02.2003
http://www.jabber.com/pdf/Jabber_Messaging_Web_Services.pdf
[Jabber 2002b]
Jabber: Advantages of Jabber as a Platform for Developing Collaborative
Applications, Mai 2002, Jabber Inc., Last Visit: 20.02.2003
http://www.jabber.com/pdf/Jabber_Advantages.pdf
[JXTA v2.0]
JXTA v2.0 Protocols Specification, 2001-2002 SUN Microsystems, 2002-2003 The
Internet Society, Letzte Überarbeitung am 15. Oktober 2003, Revisionsnummer
2.1.1, Last Visit: 06.11.2004; http://spec.jxta.org/
[Knögler 1999]
Knögler, B.: Lokale Suchmaschine und Informationsaufbereitung für externe
Suchdienste, IICM TU-Graz, September 1999, Last Update: 02.10.2000, Last Visit:
16.06.2003; http://www.iicm.edu/thesis/knoegler
Seite 200
[Koch 1998]
Koch, K.: Softwaretechnik für Ingenieuranwendungen: MFC COM ATL ActiveX
Tutorial, Bauhaus Universität Weimar, 1998
[Kon 1996]
Kon, F.: Distributed File Systems Past, Present and Future A Distributed File
System for 2006, Systems Software Research Group of Department of Computer
Science University of Illinois at Urbana-Champaign, 6 März 1996, Last Visit:
20.10.2001; http://choices.cs.uiuc.edu/~f-kon/publications.html
[Korpela 1999]
Korpela, J.: What are RFC’s, Dezember 1999, irt.org, Last Update: 03.12.2001,
Last Visit: 30.07.2002; http://tech.irt.org/articles/js197
[Kronfol 2002]
Kronfol, A.Y.: FASD: A Fault-tolerant, Adaptive, Scalable, Distributed Search
Engine, Princeton University, 6 Mai 2002, Last Visit: 31.05.2004;
http://www.cs.princeton.edu/~akronfol/fasd/
[Kunze et al. 1995]
Kunze, J. A.; Rodgers, R. P. C.: Z39.50 in a Nutshell (An Introduction to Z39.50),
Lister Hill National Center for Biomedical Communications National Library of
Medicine, Juli 1995, Last Update: 04.10.1996, Last Visit: 02.08.2001;
http://www.informatik.tu-darmstadt.de/VS/Infos/Protocol/Z39.50/z39.50-nutshell.html
[Lackner et al. 2001]
Lackner, W.; Gütl, C.: WebSave - Archiving the Web for Scholar Work, IICM TUGraz, Last Update: 21.02.2001, Last Visit: 31.12.2002;
http://www2.iicm.edu/0x811bc833_0x00638735
[Lamersdorf 1996]
Lamersdorf, W.: Middleware – Ein Überblick, Vorlesungsunterlagen, Universität
Hamburg, Arbeitsgruppe verteilte Systeme, 1996,
http://avs-www.informatik.uni-hamburg.de/teaching/ss-96/ss-96.html
[Lamport 1989]
Lamport, L.; Lynch, N.: Distributed Computing, Feber 1989, Seiten 2-10
[Larmouth 1999]
Larmouth, J.: ASN.1 Complete, October 1999, Morgan Kaufmann Publishers
[Leiner et al. 2000]
Leiner B.; M., Cerf V. G.; Clark D.; Kahn R., E.; Kleinrock L.; Lynch D., C.;
Postel J.; Roberts L., G.; Wolff S.: A Brief History of the Internet, Internet Society,
http://www.isoc.org/internet/history/brief.shtml
[Löwy 2001]
Löwy, J.: COM and .NET, Component Services, Erste Ausgabe, September 2001,
O’Reilly
[Maurer et al. 2000]
Maurer, H; Aichriedler, T.; Gütl, C.; Forstinger, H.; Heber, Knögler, B.; Neussl, D.;
Reif, G.; Weitzer, J: WWW-Wissensorganisation, Februar 2000, Forschungsbericht,
IICM TU-Graz,
[Minar 2001]
Minar, N.: Distributed Systems Topologies: Part 1, O’Reillys Open Source
Convention, Dezember 2001, Last Visit: 12.12.2004;
http://www.openp2p.com/lpt/a//p2p/2001/12/14/topologies_one.html
[Minar 2002]
Minar, N.: Distributed Systems Topologies: Part 2, O’Reillys Open Source
Convention, Juli 2002, Last Visit: 12.12.2004;
http://www.openp2p.com/lpt/a//p2p/2002/01/08/p2p_topologies_pt2.html
[Möller 2001a]
Möller, E.: Treffen unter Gleichen, Teil I: Napster, SETI, Freenet, Gnutella, espra
und Groove, Bericht von der O’Reilly Peer-to-Peer-Konferenz in San Francisco, 1416. Februar 2001, Telepolis, Heise Verlag, Februar 2001,
Last Updatet: 25.02.2002, Last Visit: 15.03.2003;
http://www.heise.de/tp/deutsch/inhalt/te/7008/1.html
[Möller 2001b]
Möller, E.: Treffen unter Gleichen oder die Zukunft des Internets, Teil II: JXTA,
Slashdot, Open-Source-Cola und Metadaten, Telepolis, Heise Verlag,
[Möller 2001c]
Möller, E.: Sicherheit in Peer-to-Peer-Netzen, Telepolis, Heise Verlag, Juni 2001,
Seite 201
[Möller 2001d]
Möller E.: Das Netz der Nutzer, Peer-to-Peer Netze auf dem Vormarsch, Juni 2001,
c’t, Heise Verlag, Last Updatet: 08.03.2001, Last Visit: 15.03.2003;
http://www.heise.de/ct/01/06/080
[Mullender 1993]
Mullender, S.: Distributed Systems, 1993, second Edition, M. Satyanarayanan –
Distributed File Systems Seiten 353-380, Addison-Wesley
[MS 1996]
Microsoft Corporation: DCOM Technical Overview, November 1996, Last Visit:
20.02.2003;
http://msdn.microsoft.com/library/en-us/dndcom/html/msdn_dcomtec.asp
[Nehmer et al. 1998]
Nehmer, J.; Sturm, P.; Schmitt. T: Middleware: Betriebssysteme der Zukunft,
Gemeinsames Seminar der AG Systemsoftware und Verteilte Systeme, Universität
Kaiserslautern, Universität Trier, Juni-Juli 1998, Last Visit: 15.03.2003;
http://bowmore.uni-trier.de/systemsoftware/Download/Seminare/Middleware/middleware.book.html
[Neubauer et al. 1998]
Neubauer, B.; Stoinski, F.: F@N - Ein verteiltes Dateisystem mit CORBA, Institut
für Informatik Humboldt-Universität zu Berlin, Diplomarbeit, 4 August 1998,
Seiten 6 – 12, http://www.hu-berlin.de/deutsch/stu_d.htm
[O’Reilly 2001]
O’Reilly, T.: Peer to Peer oder das Netz als Computer, O’Reilly Verlag, Deutsche
Übersetzung von Reinhard Gantar, 2001, Last Update: 02.07.2002, Last Visit:
12.12.2004; http://www.oreilly.de/artikel/peer_to_peer.html
[OSF 1991a]
OSF: File Systems in a Distributed Computing Environment, Open
Software Foundation, 1991, white paper;
http://www.transarc.ibm.com/Library/whitepapers/OSF_Whitepapers/dfs.ps
[OSF 1991b]
OSF: Remote Procedure Call in a Distributed Computing Environment, Open
Software Foundation, 1991, white paper;
http://www.transarc.ibm.com/Library/whitepapers/OSF_Whitepapers/rpc.ps
[OSF 1991c]
OSF: Directory Services for a Distributed Computing Environment, Open Software
Foundation, 1991, white paper;
http://www.transarc.ibm.com/Library/whitepapers/OSF_Whitepapers/directory.ps
[OSF 1991d]
OSF: Security in a Distributed Computing Environment, Open Software
Foundation, 1991, white paper;
http://www.transarc.ibm.com/Library/whitepapers/OSF_Whitepapers/security.ps
[Puder et al. 2000]
Puder, A.; Römer, K.: Middleware für verteilte Systeme, depunkt Verlag, Dezember
2000, Seiten 7-34 (verteilte Systeme, Middleware), Seiten 37ff (CORBA)
[Röder 1999]
Röder, L.: Komponentenentwicklung mit dem Component Object Model,
Objektspektrum Nr3, SIGS Conferences GmbH Juni 1999, Seite 18-25
[RR 2002]
RoadRunner: BEEP - Blocks Extensible Exchange Protocol, CodeFactory AB,
Last Update 2002, Last Visit: 04.01.2004; http://rr.codefactory.se/beep.php
[Saint-Andre 2002]
Saint-Andre P.; Jabber FAQ, 1 März 2002, Last Visit: 10.06.2002;
http://www.jabber.org/faq.htm
[Saint-Andre 2003]
Saint-Andre P.; Extensible Messaging and Presence Protocol (XMPP), XMPP
Working Group, Jabber Software Foundation, 20. November 2003, Last Update:
20.11.2003, Last Visit: 07.01.2004;
http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-20.txt
[Schlichter 2000]
Schlichter, J.: Verteilte Anwendungen;
München, Institut für Informatik, SS 2000
[Schmaranz 2001]
Schmaranz, K.: Softwareentwicklungen in Inter- und Intranetumgebungen, IICM,
Oktober 2001, Vorlesungsunterlagen
[Schmaranz 2002]
Schmaranz, K.: Dinopolis - A Massively Distributable Componentware System,
IICM, Juni 2002, Habilitation Thesis
Vorlesungs
Skript
der
TU-
Seite 202
[Scribner et al. 2001]
Scribner, K.; Stiver, M.: SOAP developer’s guide, spezifikation, xml, BizTalkServer,
deutsche
Übersetzung
Petra
Alm,
2001,
Markt+Technik;
authorisierte Übersetzung der amerikanischen Originalausgabe: Understandig
SOAP – The autoritative Solution /2000/Sams Publishing
[Sleeper 2001]
Sleeper B.: Why UDDI Will Succeed, Quietly, The Stencil Group, April 2001, Last
Visit: 20.12.2002, Last Update: 04.2001;
http://www.stencilgroup.com/ideas_scope_200104uddi.html
[Stal 1998]
Stal, M.: COMmunication everywhere - Microsoft DCOM im Überblick,
Objektspektrum, SIGS Datacom, Ausgabe 01/1998
[Stallings 1998]
Stallings, W.: Operating Systems Internals and Design Principles, third
edition, Prentice-Hall International 1998, Seiten 543-576
[Stencil 2002]
The Stencil Group, The Evolution of UDDI, UDDI.org White Paper, 19. Juli 2002,
The Stencil Group, Inc., Last Visit: 06.01.2004, Last Update: 19.07.2002;
http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf
[SUN 2001]
SUN microsystems; Open Net Environment (ONE) Software Architecture,
Copyright 2001 Sun Microsystems Inc., 901 San Antonio Road, Palo Alto,
California 94303 U.S.A.,
[Szyperski 1998]
Szyperski, A. C.: Component Software: Beyond Object-Oriented
Programming, Addison-Wesley / ACM Press, first edition,
[Tanenbaum 1992]
Tanenbaum, A.: Modern Operating Systems, Prentice-Hall International Editions,
1992, Seiten 362-462, 549-587
[TechTarget 1999a]
TechTarget: ACID, 23.09.1999, TechTarget Enterprise IT, Last Visit: 17.04.2001;
http://iroi.seu.edu.cn/books/whatis/acid.htm
[TechTarget 1999b]
TechTarget: two/phase/commit 2pc, 13.10.1999, TechTarget Enterprise IT, Last
Visit: 17.04.2001; http://iroi.seu.edu.cn/books/whatis/2pc.htm
[TechTarget 1999c]
TechTarget: transaction, 29.11.1999, TechTarget Enterprise IT, Last Visit:
17.04.2001: http://iroi.seu.edu.cn/books/whatis/transac.htm
[Transarc 1996]
Transarc: The AFS File System In Distributed Computing Environments, Transarc
Corporation, white paper, Mai 1996, Last Visit: 17.04.2001;
http://www.transarc.ibm.com/Product/EFS/AFS/afswp.html
[Transarc 1999]
Transarc: DCE Product Overview, Transarc Corporation, 1999, last Last Visit:
17.04.2001
http://www.transarc.ibm.com/Product/DCE/DCEOverview/dceoverview.html
[Transarc et al.]
Transarc and IBM: Enterprise File Systems Strategy Paper, white paper, Last Visit:
17.04.2001; http://www.transarc.ibm.com/Library/whitepapers/efs_strategy.html
[UDDI 2000]
UDDI Technical White Paper, OASIS, 6. September 2000, Last Visit: 20.12.2002,
Last Update: 06.09
.2000; www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf
[Userland]
XML-RPC Home Page: Last Update: 02.01.2004, Last Visit: 02.01.2004
http://www.xmlrpc.com/spec
[Vawter et al. 2001]
Vawter, C.; Roman, E.: J2EE vs. Microsoft .NET, a comparsion of building XMLbased web services, Sun Microsystems Inc. The Middleware Company, Juni 2001,
Last Visit: 02.01.2004; http://www.middleware-company.com
[Weber 1998]
Weber, M.: Verteilte Systeme; Spektrum
Hochschultaschenbuch, Seiten 1-18, 76-90
[W3C SOAP 2000]
Box, D.; Ehnebuske D.; Kakivaya G.; Layman A.; Mendelsohn N.;
Frystyk Nielsen H.; Thatte S.; Winer D.: Simple Object Access Protocol
(SOAP) 1.1, W3C Note, may 2000, Last Visit: 15.03.2001;
http://www.w3.org/TR/SOAP/
Akademischer
Verlag,
1998,
Seite 203
[W3C WSDL 2001]
Web Services Description Language (WSDL) 1.1, Ariba, International Business
Machines Corporation, Microsoft, W3C Note, 15. März 2001, Last Visit:
06.01.2004, Last Update: 15.03.2001; http://www.w3.org/TR/wsdl
[Waterhouse 2001]
Waterhouse, S.: JXTA Search: Distributed Search for Distributed Networks, Sun
Microsystems, Inc., 29 Mai 2001, Last Visit: 06.11.2004;
http://search.jxta.org
[Wendt 1991]
Wendt,
S.:
Nichtphysikalische
zweite Auflage, Springer 1991
[Williams et al. 1994]
Williams, S.; Kindel, C.: The Component Object Model: A Technical Overview,
Developer Relations Group Microsoft Corporation, MSDN Library, Microsoft
Corporation, Oktober 1994, Last Visit: 20.02.2003;
http://msdn.microsoft.com/library/en-us/dncomg/html/msdn_comppr.asp
[Wilson 2002]
Wilson, B.: JXTA, New Riders Publishing; 1 Ausgabe, 15 Juni 2002, Last Visit:
06.11.2004; http://www.brendonwilson.com/projects/jxta/
[xFIND 2003]
xFIND Programmers Documentation, IICM TU-Graz, Version 0.96c;
http://xfind.iicm.edu
[XHTML 2002]
W3C: XHTML 1.0: The Extensible HyperText Markup Language, Last Update:
01.08.2002, Last Visit: 02.01.2004; http://www.w3.org/TR/xhtml1
[Zakon 2002]
Zakon, R., H.: Hobbes' Internet Timeline, Hobbes' Internet Timeline Copyright (c)
1993-2002, Version: 5.6, Last Update: 01.04.2002, Last Visit: 30.12.2002;
http://www.zakon.org/robert/internet/timeline
Grundlagen
der
Informationstechnik,

Verteilte Informationsstrukturen zur modernen - Das IICM

Transcription

Similar documents

Internet-Technologien Sommersemester 2004 - rum

Spiel- und Lernsoftware pädagogisch beurteilt

Peer-to-Peer