Visualisierung der Linkstruktur von Web

Visualisierung der Linkstruktur von Web-Dokumenten auf
Basis des Google Web APIs
Studienarbeit im Fach Informatik
Wintersemester 2005/2006
Universität Jena
vorgelegt von
Jens Fischer
20. März 2006
Abstract
Diese Studienarbeit beschäftigt sich mit der Untersuchung der Linkstruktur von HTMLkodierten Webdokumenten. Dazu werden eingehende und ausgehende Links von Webdokumenten mit Hilfe des entwickelten Servlets GLinks untersucht und dargestellt. Im
ersten Teil der Arbeit soll eine Übersicht der verwendeten Technologien gegeben werden. Dabei werden im Einzelnen Web Services und deren aktuell verwendeten Protokolle
betrachtet. Danach wird ein Überblick über den Google Web Service gegeben und die
Verwendung von Java Servlets kurz dargestellt.
Im zweiten Teil der Arbeit wird die Umsetzung dieser Technologien in einem Java Servlet unter Nutzung des Google Web Service betrachtet. Hierbei sollen eingehende sowie
ausgehende Links zu den jeweiligen Suchergebnissen ermittelt, angezeigt und mit einer komfortablen Navigation versehen werden. Zur Verdeutlichung der Funktionsweise
werden einige Testläufe der Anwendung durchgeführt.
1
Inhaltsverzeichnis
1 Einleitung
3
2 Web Services
2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Das Simple Object Access Protokoll - SOAP . . . . . . .
2.3 Die Web Service Description Language - WSDL . . . . . .
2.4 Universal Description, Discovery and Integration - UDDI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
. 5
. 7
. 10
. 12
3 Der Google Web Service
14
3.1 Allgemeines über Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Der Google Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Java Servlets
17
5 Das
5.1
5.2
5.3
5.4
20
20
20
21
21
GoogleLinks-Servlet
Zielstellung . . . . . .
Arbeitsumgebung . . .
Umsetzung . . . . . .
Implementierung . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Zusammenfassung und Ausblick
34
A WSDL-Dokument
36
B Einige UDDI-Server
38
C Exkurs: Das Hypertext Transfer Protocol - HTTP
39
D Glossar
42
E Wichtige Internetadressen
46
F Abkürzungen und Akronyme
46
Literaturverzeichnis
47
Index
50
2
1
Einleitung
Das derzeitige World Wide Web (WWW) stellt eine riesige, verteilte Wissensbasis dar.
Es besteht aus unzähligen HTML-Seiten, Dokumenten und sonstigen Informationsobjekten, die mit Hilfe von Suchmaschinen wie Google[1] durchsucht werden können. Die
Ergebnisse solcher Suchmaschinen werden im allgemeinen in Form einer Liste mit Verknüpfungen oder Verweisen (Hyperlinks) zu den jeweiligen Seiten dargestellt. Hyperlinks
entsprechen funktional einer Art Querverweis, sie können den Leser innerhalb des Dokumentes zu dem richtigen Textabschnitt bringen. Verweise können aber auch in andere
Dokumente führen. Im WWW gestattet die Hypertext Markup Language (HTML) [2]
die Verwendung von Hyperlinks innerhalb von Dokumenten. Mit einem Mausklick auf
den Link wird das entsprechende Dokument bzw. die entsprechende Stelle im Dokument
angezeigt. Diese Links sind unidirektional, d.h. dem Ziel des Links ist nicht bekannt, dass
ein Link auf ihn verweist. Wird das Zieldokument umbenannt oder gelöscht, kann der
Link im Normalfall, also ohne automatisierte Konsistenzprüfung oder ähnlichem, nicht
automatisch korrigiert werden und es entsteht ein toter Link der zu keinem Dokument
führt.
Während der letzten Jahre ist im WWW neben der Nutzung als Informationsquelle
ein weiteres Anwendungsgebiet entstanden. Es werden zunehmend vielfältige Arten von
geschäftlichen Transaktionen abgewickelt, sowohl mit privatem als auch mit kommerziellem Hintergrund. Neben dem herkömmlichen browserbasiertem Zugang stellt eine
stetig steigende Zahl von Dienstanbietern auch eine Programmierschnittstelle zur Anwendungsentwicklung bereit. Somit besteht die Möglichkeit, diese Dienste, genannt Web
Services, direkt aus einer Softwareanwendung heraus zu nutzen. Aktuelle Technologien
von Web Services basieren auf manuellen Verfahren zur Publikation, Auswahl und Integration in entsprechenden Anwendungen.
Suchmaschinen sind derzeitig die einzige Möglichkeit den riesigen Datenbestand des
WWWs zu durchsuchen. Sie verfügen über einen Webrobot (auch Crawler genannt, eine
Softwarekomponente) der eigenständig das WWW durchsucht und aktiv neue Webseiten
einliest. Der Crawler einer Suchmaschine kann Links in einem HTML-Dokument finden
und weiterverfolgen. Auf diese Weise können Dokumente gefunden werden, die noch
nicht im Datenbestand der Suchmaschine referenziert sind und werden entsprechend
hinzugefügt. Diese Links werden unter anderem auch zur Einordnung der Priorität des
Dokumentes verwendet. Grundsätzlich gilt: je mehr Links auf ein Dokument verweisen,
desto wichtiger ist es. Dementsprechend wird bei der Anzeige von Suchergebnissen ein
Dokument mit vielen eingehenden Links und somit hoher Priorität vor einem Dokument
mit niedrigerer Priorität und weniger eingehenden Links aufgeführt. Die Untersuchung
solcher Linkstrukturen von Dokumenten soll wesentlicher Bestandteil dieser Arbeit sein.
Dabei wird unter anderem der Datenbestand der Suchmaschine Google verwendet.
Im Laufe der Zeit hat sich Google zur weltweit bedeutendsten Suchmaschine entwickelt.
Verantwortlich hierfür war neben einer hohen Performance und einer einfachen Bedienung vor allem die gegenüber anderen Suchmaschinen überlegene Qualität der Sucher-
3
gebnisse. Der Web Service von Google, das Google Web API [3], stellt eine komfortable Schnittstelle zur Suchmaschine Google bereit. Es kann auf die Inhalte von Googles
Datenbestand in Form einer Suchanfrage zugegriffen werden. Die Ergebnisse können
entsprechend weiterverarbeitet werden, in diesem Fall soll die Linkstruktur der Suchergebnisse betrachtet werden. Dabei sollen eingehende und ausgehende Links zu den
jeweiligen Suchergebnissen ermittelt und in einer Webseite angezeigt werden.
Eine Möglichkeit zur Erzeugung dynamischer Webseiten stellen Java Servlets [4] dar.
Ein Servlet ist ein Programm, das von einem Browser eine Anfrage erhält und daraufhin
dynamisch eine Webseite erstellt und an den Browser sendet. Während dieser Arbeit
entstand ein solches Servlet, welches unter anderem den Google Web Service nutzt, um
die Linksstruktur von Webdokumenten zu untersuchen.
Die Inhalte dieser Arbeit gliedern sich folgendermaßen: Im ersten Kapitel werden die
Möglichkeiten von Web Services vorgestellt. Die dazu verwendeten Protokolle werden im
Einzelnen betrachtet und wesentliche Eigenschaften vorgestellt. Danach wird der Google
Web Service Bestandteil des folgenden Kapitels sein. Die Java Servlet Technologie ist
Gegenstand des vierten Kapitels. Im fünften Kapitel wird das entstandene Java Servlet
detailiert vorgestellt. Abschließend wird eine kurze Zusammenfassung gegeben.
4
2
Web Services
2.1
Allgemeines
A Web service is a software system identified by a URI [RFC 2396], whose public inter”
faces and bindings are defined and described using XML. Its definition can be discovered
by other software systems. These systems may then interact with the Web service in
a manner prescribed by its definition, using XML based messages conveyed by Internet
protocols [5].“
Das vorhergehende Zitat ist die offizielle Definition von Web Services des World Wide Web Consortium (W3C) [6]. Sinngemäß übersetzt sind Web Services also Softwareanwendungen, die mithilfe von XML-Nachrichten über das Internet kommunizieren.
Mittlerweile existiert eine Vielzahl an Diensten, die man als Web Service bezeichnen
kann (z.B. das Abfragen von Aktienkursen oder Suchmaschinenanfragen). Im Allgemeinen existieren bei den meisten momentanen Diensten nur eine Schnittstelle, die es dem
Benutzer erlaubt die benötigten Daten einzugeben. Dies erfolgt in der Regel über ein
HTML-Formular. Die Möglichkeit direkt aus einer Softwareanwendung auf den Web
Service zuzugreifen besteht vielmals noch nicht. Dabei ist gerade diese Zugriffsart von
zunehmender Bedeutung: Verschiedene Programme unterschiedlicher Unternehmen sollen unabhängig vom Betriebssystem kommunizieren können und die Abwicklung von
Geschäften und Dienstleistungen über das Internet ermöglichen. Genau diese Aufgaben
kann man mit Web Services realisieren.
Web Services beziehen sich also im engeren technischem Sinn auf die automatisierte
Kommunikation zwischen Anwendungen über das Internet und übernehmen eine Vermittlerrolle zwischen Client- und Serverapplikationen. Diese Vermittlerrolle ist nicht neu,
sondern wurde bisher durch den Einsatz von Middleware-Technologien wie die Common
Object Request Broker Architekture (CORBA) [7] übernommen. Durch die Verwendung
von Web Services wird es verschiedenen Anwendungen ermöglicht, Daten auszutauschen
und auf entfernten Rechner Funktionen aufzurufen (Remote Procedure Call - RPC).
Dafür werden die folgenden Informationen benötigt:
• eine komplette Übermittlung der Informationen (Simple Object Access Protocol SOAP [8])
• eine Beschreibung über den Aufbau der zu übermittelnden SOAP-Nachrichten
(Web Service Description Language - WSDL [9])
• ein Verzeichnis vorhandener Dienste (Universal Description, Discovery and Integration - UDDI[10])
Der in Abbildung 1 dargestellte Protokollstack zeigt die auf den zugehörigen Schichten
verwendeten Protokolle. Im Folgenden werden die verwendeten Schichten und deren
Bedeutung kurz vorgestellt:
• Service Discovery Layer (Dienst-Entdeckung-Schicht): Diese Schicht ist zuständig
für eine zentrale Führung einer Dienste-Liste.
5
• Service Description Layer (Dienst-Beschreibung-Schicht): Diese Schicht ist zuständig
für die einheitliche Beschreibung der Schnittstellen von Diensten.
• XML Messaging Layer (XML-Nachrichtenschicht): Diese Schicht ist zuständig für
Umwandlung bzw. Erstellung von Nachrichten in einheitlichem XML-Format.
• Service Transport Layer (Dienst-Transport-Schicht): An dieser Stelle wird der
Transport der Nachrichten zwischen den Anwendungen sowie das verwendete Protokoll festgelegt.
Abbildung 1: Protokollstack
Unter Verwendung dieser Technologien könnte eine Anfrage einer Anwendung zur Ermittlung eines Aktienkurses wie folgt ablaufen: Zunächst stellt der Client eine Anfrage
an einen UDDI-Verzeichnisserver. Dieser sucht einen Web Service aus seinem Datenbestand und sendet die zum Aufruf benötigten Informationen sowie die Adresse des
Dienstes in Form eines WSDL-Dokumentes an den Client zurück. Dieser verfügt nun
über die notwendigen Informationen zum Formulieren einer SOAP-Nachricht und kann
diese mit seinen eigenen Parametern versehen, in diesem Fall wäre dies zum Beispiel
die Wertpapierkennnummer (WKN). Der Web Service Anbieter kann beim Eintreffen
der Nachricht diese Parameter entsprechend auswerten und wird in diesem Beispiel den
aktuellen Aktienkurs in Form einer SOAP-Nachricht an den Client senden. Dieser kann
mit dem zugrunde liegendem WSDL-Dokument die erhaltenden Daten korrekt zuordnen
und verarbeiten. Das verwendete Transportprotokoll kann dabei beliebig gewählt sein,
meistens wird jedoch HTTP (Hypertext Transfer Protocol) [11] oder HTTPS (Hypertext
Transfer Protocol Secure) [12] gewählt um den Transport auch durch Firewalls [13] zu
gewährleisten. Die Grafik in Abbildung 2 soll den Vorgang verdeutlichen:
Im Folgendem sollen die verwendeten Protokolle im Einzelnen betrachtet und vorgestellt
werden.
6
Abbildung 2: Schema eines Web Service Aufrufes
2.2
Das Simple Object Access Protokoll - SOAP
Das Simple Object Access Protocol (SOAP) stellt einen einfachen Mechanismus zum
Austausch strukturierter und typisierter Informationen zur Verfügung. Es ist mittlerweile
in der Version 1.2 spezifiziert, allerdings findet sich auch noch die Version 1.1, welche im
Mai 2000 beim W3C eingereicht wurde, in Verwendung [14]. SOAP stellt eine einfache,
XML-basierte Möglichkeit zur Beschreibung der internen Semantik zur Verfügung. Eine
in SOAP verfasste Nachricht setzt sich aus 3 Teilen zusammen:
Abbildung 3: Aufbau einer SOAP-Nachricht
Der Envelope (Umschlag) ist ein alles umschließendes Element. Der Header ist ein optionaler Mechanismus zum Erweitern der Nachricht, der Body enthält die eigentliche
Nachricht.
Der SOAP-Envelope muss in jeder Nachricht enthalten sein und darf Deklarationen von
7
Namensräumen und zusätzlichen Attributen enthalten, sofern diese durch einen Namensraum qualifiziert sind. Mit ihm wird ein Regelwerk definiert, womit festgelegt wird, was
in der Nachricht steht, von wem die Nachricht wie zu verarbeiten ist und ob einzelne
Daten enthalten sein müssen oder optional sind.
Der Header stellt eine flexible Erweiterung der Nachricht zur Verfügung. Diese Erweiterungen können ohne vorherige Kenntnisnahme des Empfängers vorgenommen werden,
wie zum Beispiel Authentifizierungsmechanismen zur Vermeidung unberechtigter Aufrufe. Falls eine Nachricht auf dem Weg zum endgültigen Empfänger noch Zwischenstationen passiert, an denen schon Teile der Nachricht verarbeitet werden sollen, kann dies im
Header festgelegt werden. Da die Verarbeitung des Headers in SOAP optional ist, kann
die Verarbeitung für einzelne Empfänger durch Setzten des entsprechenden Attributes
(mustUnderstand-Attribut) erzwungen werden.
Der SOAP-Body beinhaltet die eigentliche Nachricht, also die Informationen die an
Empfängerseite zum Ausführen eines Verarbeitungsprozesses benötigt werden. Die Kodierung der zu übermittelnden Daten erfolgt in einem einfachen Typsystem: Die aktuellen Daten werden zusammen mit dem zugrunde liegendem Datenmodell in die SOAPNachricht übernommen. Auf Empfängerseite können diese somit entsprechend verarbeitet werden.
Um eine Nachricht korrekt verarbeiten zu können, benötigt eine SOAP-Anwendung die
folgenden Informationen:
• Die Form des Nachrichtenaustausches (Einweg, Frage/Antwort, Multicast)
• Die Rolle der Anwendung in diesem Nachrichtenwechsel (Ist diese Anwendung der
endgültige Empfänger?)
• Den eventuellen Einsatz von RPC-Mechanismen
• Die Datenrepräsentation und Datenkodierung
Beim Eintreffen einer SOAP-Nachricht beim Empfänger werden zunächst diejenigen Teile der identifiziert, die zur Verarbeitung an diesem Empfänger vorgesehen sind. Anschließend wird überprüft, ob der Empfänger auch in der Lage ist, die für ihn bestimmten
Nachrichtenteile korrekt zu verarbeiten. Falls nicht wird eine Fehlermeldung zurückgegeben und die Nachricht verworfen. Falls diese Anwendung nicht der endgültige Empfänger
der Nachricht ist, wird der für diese Anwendung bestimmte Nachrichtenteil entfernt bevor sie zum nächsten Empfänger weitergeleitet wird.
Als Transportprotokoll für die Nachricht wird vielmals HTTP verwendet. Die Verbindung von SOAP und HTTP bringt einige Vorteile mit sich, so wird die Flexibilität von
SOAP mit der Stabilität und der reichhaltigen Funktionalität von HTTP kombiniert.
SOAP folgt von sich aus dem HTTP-Request/Response (Frage/Antwort) Nachrichtenmodel: SOAP-Request-Parameter werden in einem HTTP-Request übermittelt, analog
8
werden SOAP-Response-Parameter in einem HTTP-Response transportiert. Das folgende Listing zeigt ein solches Request/Response-Schema am Beispiel des Zeitservice von
www.nanonull.com [16]:
POST /TimeService/TimeService.asmx HTTP/1.1
Host: www.nanonull.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://www.Nanonull.com/TimeService/getUTCTime"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getUTCTime xmlns="http://www.Nanonull.com/TimeService/" />
</soap:Body>
</soap:Envelope>
Listing 1: SOAP-Anfrage über HTTP
Wie hier zu sehen ist, besitzt diese Nachricht keinen Header. Mit SOAPAction wird das
Ziel der Nachricht definiert. Der Body der Nachricht beschreibt die Funktion getUTCTime.
Eine entsprechende Antwort ist in Listing 2 dargestellt:
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getUTCTimeResponse xmlns="http://www.Nanonull.com/TimeService/">
<getUTCTimeResult>120000</getUTCTimeResult>
</getUTCTimeResponse>
</soap:Body>
</soap:Envelope>
Listing 2: SOAP Antwort über HTTP
Bei der Funktion getUTCTimeRespone handelt es sich um die Antwort (Response) auf
eine Anfrage. Als Parameter wird die aktuelle Coordinated Universal Time (UTC), hier
9
12:00:00 Uhr, geliefert.
In Situationen mit erhöhtem Sicherheitsbedarf sollte folgendes berücksichtigt werden:
SOAP ist kein sicheres Protokoll, sämtliche Daten werden im Klartext versendet. Mechanismen der Verschlüsselung oder Authentifizierung sind nicht vorgesehen. Somit ist
nicht sichergestellt, das SOAP-Nachrichten nicht von Unbefugten gelesen oder mitgeschnittene SOAP-Requests sogar erneut ausgelöst werden können. Zurückzuführen ist
diese Unsicherheit darauf, dass Aspekte der Sicherheit kein primäres Designziel waren.
Angestrebt war die Entwicklung eines möglichst einfachen Protokolls, Sicherheitsaspekte wurden von vornherein an das Transportprotokoll oder die Anwendung delegiert. Ein
sicheres Transportprotokoll ist unter anderem HTTPS. HTTPS ist eine sichere Variante des HTT-Protokolls, die Daten verschlüsselt übertragen kann. Die Verschlüsselung
basiert dabei auf dem Secure Socket Layer (SSL) [15] und gewährleistet relativ sichere
Transaktionen. Auch wenn HTTPS als eigenständiges Protokoll angesehen wird, besteht es eigentlich aus HTTP-Paketen, die SSL-verschlüsselt übertragen werden. Daher
können generell alle Daten, die mittels HTTP übertragen werden können, auch mit
HTTPS übertragen werden. So kann mit relativ geringem Aufwand eine sichere Kommunikation erfolgen.
2.3
Die Web Service Description Language - WSDL
Nachdem im vorherigem Abschnitt eine kurze Übersicht über den Aufbau und die Funktion von SOAP-Nachrichten gegeben wurde, soll im Folgendem eine Möglichkeit zur
Beschreibung von Web Services mittels der Web Service Description Language vorgestellt werden.
Die erste Version von WSDL wurde im März 2001 beim W3C eingereicht [17]. Mittlerweile befindet sich das Protokoll in der Version 2. WSDL ist wie SOAP auch XML-basiert.
Mit WSDL ist es möglich, das Interface eines Web Service zu beschreiben. Es enthält
dabei gerade die Informationen, die ein Client benötigt um mit dem Web Service zu interagieren. Dies beinhaltet eine Beschreibung über den Aufbau der SOAP-Nachrichten und
die Art und Weise wie mit ihnen zu verfahren ist. Insbesondere wird eine Auflistung aller
möglichen ausführbaren Methoden geliefert, einschließlich der zum Aufruf benötigten Parameter sowie der zu erwartenden Rückgabewerte. Ein solches WSDL-Dokument kann
im Allgemeinen von einem UDDI-Verzeichnisserver, welcher Gegenstand des nächsten
Abschnitts ist, abgerufen werden.
Ein WSDL-Dokument ist in 6 Teile unterteilt und wird von dem Wurzelelement <definitions> umschlossen. Die Reihenfolge der in Abbildung 4 dargestellten Elemente ist
einzuhalten, da sich jeweils auf vorhergehende Elemente bezogen wird. Es folgt eine kurze Auflistung der Elemente mit ihrer Bedeutung:
import> Hier besteht die Möglichkeit, bereits bestehende WSDL-Dokumente einzubinden.
<
10
Abbildung 4: Aufbau eines WSDL-Dokumentes
11
types> Beschreibung der verwendeten Datentypen.
<
messages> Definition der Ein- und Ausgabeparamter.
<
portType> Zuordnung zu einzelnen Methoden, jede Methode ist dabei durch ein <operation>-Element definiert.
<
binding> An dieser Stelle wird das verwendete Trägerprotokoll festgelegt.
<
service> Hier wird der eigentliche Web Service definiert. Dabei handelt es sich um eine
Ansammlung von Endpunkten bzw. Adressen untern denen der Service zu erreichen ist.
Es ist weiterhin möglich an dieser Stelle mehrere Anschlüsse zu definieren, die entweder
ein anderes Trägerprotokoll verwenden oder sich an verschieden Endpunkten befinden.
Es muss jedoch in jedem Fall sichergestellt sein, das alle definierten Endpunkte sich
gleich verhalten und über die gleiche Funktionalität verfügen.
<
Im Anhang findet der interessierte Leser ein WSDL-Dokument welches den bereits
erwähnten Zeitservice von www.nanonull.com beschreibt.
Nachdem nun dargelegt wurde, wie ein Web Service beschrieben werden kann, ist das
Auffinden des Web Service Gegenstand des folgenden Abschnitts.
2.4
Universal Description, Discovery and Integration - UDDI
Der Universal Description, Discovery and Integration Standard befindet sich aktuell in
der Version 3.0, jedoch sind auch noch ältere Versionen in Verwendung.
Ein UDDI-Verzeichnisserver ist eine Ansammlung von Web Services und deren Anbieter.
Gern wird dieser Service auch mit den Gelben Seiten“ verglichen. Grundsätzlich können
”
3 verschiedene Informationstypen abgelegt werden:
• Zum einen sind dies Business-Informationen über Unternehmen und deren Kontaktpersonen. Dieser Informationstyp trägt den Namen White Pages“
”
• Die so genannten Yellow Pages“ enthalten den eigentlichen Service, der vom Un”
ternehmen angeboten wird. Vielmals bieten Unternehmen nicht nur einen Web
Service an, sondern mehrere. Dementsprechend ist es an dieser Stelle möglich, alle
Dienste des anbietenden Unternehmens abzufragen.
• Ein weiterer Informationstyp sind die Green Pages“, welche technische Informa”
tionen des Web Service enthalten. Technische Informationen sind in der Regel
WSDL-Dokumente.
Das XML-Schema eines UDDI-Eintrags ist in Abbildung 5 und Listing 3 dargestellt.
12
Abbildung 5: Aufbau eines UDDI-Eintrags
Es existieren 4 verschiedene Elementtypen in einem solchen Eintrag. <BusinessEntity> repräsentiert einen Eintrag in der Registry, wobei dieser mehrere Dienste umfassen kann, die jeweils als <BuisinessTemplate> deklariert sind. Jedes <BusinessService>Element besitzt ein <BindingTemplate>-Element, welches die Adresse des Web Service
enthält oder einen Verweis auf ein tModel. Ein tModel enthält Informationen zur technischen Beschreibung des Service, wie zum Beispiel ein WSDL-Dokument, das ebenfalls
die Adresse des Web Service beinhaltet.
<businessEntity businessKey="...">
<businessEntity businessKey="...">
<name> ... </name>
<description> ... </ description >
<contacts> ... </ contacts >
<businessServices>
<businessService serviceKey="...">
...
</businessService> ...
</businessServices>
</businessEntity>
Listing 3: XML-Schema eines UDDI-Eintrags
Um auf die Daten einer UDDI-Registry zuzugreifen oder neue Einträge hinzuzufügen,
wird im Allgemeinen stets SOAP über HTTP verwendet. Im Anhang ist eine Auflistung
13
einiger UDDI-Server zu finden. Einige der anbietenden Unternehmen gleichen ihre Inhalte in regelmäßigen Abständen untereinander ab. Nach dieser kurzen Vorstellung der
Web Service-Technologien wird nun ein konkreter Web Service vorgestellt.
3
Der Google Web Service
3.1
Allgemeines über Google
Die Firma Google Inc. mit Sitz in Mountain View (USA) ist Betreiber der Suchmaschine
Google. Am Tag der Firmengründung, dem 7. September 1998, ging die Suchmaschine
offiziell ans Netz. Seit dem verzeichnet die Suchmaschine zunehmende Nutzerzahlen, so
dass sie mittlerweile die populärste Suchmaschine sein dürfte.
Aus der Vielzahl der im allgemeinen werbefinanzierten und somit kostenlosen Dienstleistungen soll an dieser Stelle ein Auswahl der populärsten Dienste vorgestellt werden.
Ausführlichere Informationen zu allen Bereichen sind auf den Internetseiten von Google
[1] zu finden.
• Die Volltextsuche nach Textdokumenten im WWW ist die wohl bekannteste und
am häufigsten genutzte Dienstleistung. Google ist in der Lage, neben der für Webseiten üblicherweise verwendeten Sprache HTML andere Dokumententypen wie
etwa das Portable Document Format (PDF) von Adobe oder das Doc-Format
von Microsoft zu untersuchen. Neben dieser großen Vielfalt an untersuchten Dokumenten hat auch die Relevanz der Dokumente maßgeblich zu Googles Erfolg
beigetragen: Google schafft es im Vergleich zu anderen Suchmaschinen sehr gut,
die am meisten relevanten Dokumente einer Suchanfrage auf vorderen Positionen
anzuzeigen.
• Googles Bildsuche findet Bilddateien im WWW und verwendet dazu Wörter im
Dateinamen oder in HTML-Dokumenten, die ein Bild verwenden. Dabei werden
die zur Zeit gängigsten Grafikformate wie JPEG, PNG und GIF unterstützt. Eine
Suche nach Bildinhalten oder zu einem gegebenen Bild ähnlichen Bildern ist nicht
möglich.
• Google Groups ist ein umfangreiches Archiv von Newsgroup-Artikeln, die bis ins
Jahr 1981 zurückreichen. Innerhalb der verschiedensprachigen Diskussionsforen
kann nach Begriffen und Autoren gesucht werden. Zusätzlich wird das Anlegen
von eigenen Diskussionsforen unabhängig vom Usenet [18] angeboten.
• Das Webverzeichnis Google Directory bietet einen Überblick von Websites, die
manuell nach Themen katalogisiert wurden.
• Unter Googles Nachrichtendienst Google News werden regelmäßig die Seiten diverser Nachrichten-Webseiten mittels Really Simple Syndication - RSS [19] auf
Neuigkeiten untersucht. Die so gefundenen Artikel werden gruppiert nach Themen oder bestimmten Ereignissen dargestellt und auf den Ursprung der Artikel
verwiesen.
14
• Mit Froogle kann man nach bei Online-Händlern angebotenen Waren suchen und
einen Preisvergleich durchführen.
• Der E-Mail Service Gmail (in Deutschland Google Mail) ist Googles E-Mail-Dienst.
Er zeichnet sich durch eine einfache webbasierte Benutzerschnittstelle und überdurchschnittlich viel Speicherplatz aus.
• Googles Übersetzungsdienst bietet eine automatische Übersetzung zwischen einigen Sprachen für komplette Webseiten an. Zusätzlich können auch einzelne Wörter
ober Sätze eingegeben und übersetzt werden.
• Der Google Calendar ist ein von Google angebotener Onlinekalender. Er informiert unter anderen per E-Mail über bevorstehende Ereignisse und kann auch von
mehreren Benutzern verwaltet werden.
• Google Maps ist ein Dienst, mit dessen Hilfe Satellitenbilder angesehen werden
können. Weiterhin stehen Funktionen wie Hotel- und Adress-Suche zur Verfügung,
wobei die Ziele auf einem Satellitenbild entsprechend dargestellt werden.
• Personalisierte Suche: Seit Mai 2005 bietet Google seinen Benutzern die Möglichkeit, eine personalisierte Startseite zu erstellen, um verschiedene bereits vorhandene Google-Dienste zu personalisieren. Zusätzlich werden weitere Informationen
wie Wettervorhersagen und News angegeben.
Dies stellt nur eine Auswahl der von Google angebotenen Dienste dar. Das vollständige
Angebot ist auf den Webseiten von Google zu finden [1].
3.2
Der Google Web Service
Google stellt mit seinem Web Service eine einfache und komfortable Schnittstelle zum
Zugriff auf die Suchmaschine zur Verfügung.
Dabei stehen neben der von www.google.de bekannten Suche nach Internetdokumenten auch der Aufruf von Seiten aus dem Google Cache (Cache-Request, Cache = engl.
Zwischenspeicher) sowie die eine Rechtschreibprüfung zur Korrektur von Tippfehlern
(Spelling-Request) zur Verfügung. Im Folgendem soll die Verwendung als Suchmaschine
näher betrachtet werden.
Google stellt neben den bereits bekannten SOAP-Nachrichten weitere Möglichkeiten
zum Zugriff auf seinen Service zur Verfügung. Dies sind unter anderem vorgefertigte
Programmpakete bzw. Module, die für verschiedene Programmiersprachen Java [20] oder
Visual Basic .NET [21] zur Verfügung stehen. Diese verwenden allesamt selbst SOAPNachrichten, sind jedoch ohne Kenntnisse in SOAP oder WSDL einfach in bestehende
Programme zu integrieren.
Um den Service zu nutzen, wird ein Zugangsschlüssel (key) benötigt. Diesen erhält man
15
nach erfolgter Anmeldung beim Google Web Service. Mit dem Schlüssel ist man berechtigt, bis zu 1.000 Suchanfragen an Google zu stellen. Pro Anfrage werden höchstens 10
Ergebnisse geliefert. Unterstützt werden in der Suchanfrage alle Möglichkeiten, die auch
von Google’s Webseite bekannt sind. So ist es unter anderem Möglich, für ein Internetdokument alle bei Google bekannten eingehenden Links auflisten zu lassen, indem das
Präfix link: vor die Adresse des entsprechenden Dokumentes gesetzt wird.
Abbildung 6: Ausschnitt
http://www.uni-jena.de
einer
Google-Suche
16
nach
eingehenden
Links
für
4
Java Servlets
Ein Servlet ist eine Webkomponente, die von einem Servlet-Container verwaltet wird
”
und dynamischen Inhalt generiert. Servlets sind in der Regel kleine plattformunabhängige Java-Klassen. Ein Servlet kommuniziert“mit einem Webclient (z.B. einem Brow”
ser) über Anfrage- und Antwort-Objekte (Request und Response), die in einem ServletContainer implementiert sind. Diese Anfrage- und Antwort Objekte können sowohl protkollunabhängig sein, als auch auf dem Hypertext-Transfer-Protokoll (HTTP) basieren.
[22]“
Das vorhergehende Zitat stellt eine Definition von Servlets dar. Demzufolge ist ein Servlet ein kleines Programm, das eine Anfrage von einem Browser bekommt und darauf eine
Webseite dynamisch erstellt und an den Browser sendet. Dynamisch bedeutet in diesem
Zusammenhang, dass das Servlet individuell für jede Anfrage eine Seite anfertigt und diese an den Client sendet. Der dynamische Inhalt kann zum Beispiel aus einer Datenbank
stammen. Die folgende Grafik (Abbildung 6) stellt ein typisches Anwendungsszenario von
Servlets dar. Die wesentlichen Bestandteile eines Servlets sind die Schnittstellen ServletRequest und ServletRespone. Mittels ServletRequest ist es möglich Informationen vom
bzw. über den anfragenden Client zu erhalten. Analog können mit ServletResponse Informationen vom Server zum Client gesendet werden. Die für die Servlet-Programmierung
Abbildung 7: Typische Servlet-Konstellation
17
verwendeten Klassen befinden sich in den Paketen javax.servlet und javax.servlet.http.
Ausführliche Beschreibung dieser Pakete und deren Verwendung finden sich auf den Internetseiten der Herstellerfirma SUN Microsystems [23].
Nach einem kurzen Überblick über die Funktionsweise soll nun der bereits angesprochene Servlet-Container näher betrachtet werden. Der Servlet-Container übernimmt eine
Vermittlerrolle zwischen anfragendem Programm (z.B. Browser) und dem Servlet. Ein
Servlet-Container enthält mehrere Servlets und führt diese durch ihren Lebenszyklus
(siehe Lebenszyklus und Abbildung 8). Hierzu stellt der Container die Netzwerkservices
bereit, wie zum Beispiel für Anfragen und Antworten der Clients (z.B. Browser). Im
allgemeinen wird HTTP als Protokoll unterstützt, einige Servlet Container unterstützen
auch andere Protokolle wie HTTPS.
Abbildung 8: Servlet Lebenszyklus
Der Lebenszyklus eines Servlets läuft folgendermaßen ab: Die Instanziierung des Servlets, also die Erzeugung einer konkreten Instanz der Servlet-Klasse, wird vom ServletContainer übernommen. Dies kann entweder beim Start des Containers erfolgen oder
erst wenn eine konkrete Anfrage an das Servlet erfolgt. Nach dieser Instanziierung ist
es in der Lage, vom Container weitergeleitete Anfragen entgegenzunehmen und zu beantworten. Dies geschieht durch den Aufruf der Methode init(ServletConfig). Durch die
Initialisierung ist es möglich, auf die Konfigurationsdaten zuzugreifen und Operationen,
die nur einmal durchgeführt werden müssen wie zum Beispiel das Öffnen einer Datenbankverbindung, zu definieren. Nach Möglichkeit sollten hier also alle Aktionen, die nur
einmal durchgeführt werden, an dieser Stelle definiert werden.
Falls während der Initialisierung des Servlets eine Fehlermeldung auftritt, die besagt,
18
dass das Servlet nicht im aktiven Zustand gesetzt werden konnte, so geschieht dies in der
Regel durch die Ausgabe einer javax.servlet.UnavailableException oder javax.Servlet.ServletException. In beiden Fällen wird die destroy()-Methode zur Freigabe des Servlets
nicht aufgerufen. Wenn die Initialisierung erfolgreich beendet wurde, also ohne Ausgabe
einer Exception, ist das Servlet bereit um Anfragen zu beantworten. Dies geschieht mit
der service()-Methode.
Die service()-Methode kann für eine Instanz des Servlets beliebig oft vom ServletContainer aufgerufen werden. Außerdem können auch mehrere Instanzen eines Servlets parallel im Servlet-Container existieren um zum Beispiel die Anzahl der Anfragen, die beantwortet werden können, zu erhöhen. Auch während der Bearbeitung von
Anfragen kann das Servlet die beiden bereits erwähnten Fehlermeldungen ausgeben.
Dabei bedeutet die javax.Servlet.ServletException an dieser Stelle, das ein Fehler in
der Bearbeitung einer Anfrage hervorgerufen wurden und der Servlet-Container die erforderlichen Maßnahmen ergreift um die Anfrage zu beenden. Die Fehlermeldung javax.servlet.UnavailableException besagt, dass das Servlet kurzfristig oder permanent
nicht in der Lage ist, eine Anfrage zu bearbeiten. Im Falle einer permanenten Störung
wird die destroy()-Methode aufgerufen und die Instanz des fehlerhaften Servlets beendet, andernfalls wird bei kurzfristigen Störungen keine Anfrage seitens des ServletContainers mehr an dieses Servlet geleitet. Der Client erhält dann als Antwort den
HTTP-Statuscode 503 - Service unavailable“.
”
Der Servlet-Container ist verantwortlich für die Freigabe bzw. Beendigung der ServletInstanz. Dazu ruft er die Methode destroy() auf. In dieser Methode muss sichergestellt
werden, dass alle Daten gesichert werden und noch aktive Verbindungen, z.B. zu Datenbanken, korrekt beendet werden. In der Regel beendet der Servlet-Container eine Servlet
Instanz, wenn Speicher freigegeben werden soll, der Server heruntergefahren wird oder
längere Zeit keine Anfrage an das Servlet gestellt wurde. Nach Aufruf der destroy()Methode ist es nicht mehr möglich, Anfragen an das Servlet zu stellen.
Im folgendem Abschnitt soll das im Rahmen der Studienarbeit entstandene Servlet
GLinks“vorgestellt werden.
”
19
5
Das GoogleLinks-Servlet
5.1
Zielstellung
Das angestrebtes Ziel dieser Arbeit war die Entwicklung eines Servlets, mit dem es
möglich ist, die Linkstruktur von HTML-kodierten Internetdokumenten zu untersuchen.
Grundlage dafür ist das Google-API, mit dessen Hilfe die zu untersuchenden Webseiten
zunächst gesucht werden, aber auch eingehende Links mit der in Abschnitt 3 vorgestellten
Funktion gesucht werden können. Die Suche nach ausgehenden Links übernimmt das
Servlet selbst. Um eine einfache und intuitive Bedienung zu gewährleisten, ist das Design
an die Webseiten von Google angepasst, zusätzlich besteht jedoch für jeden Link die
Möglichkeit, nach eingehenden bzw. ausgehenden Links zu suchen und diese entsprechend
in übersichtlicher Form darzustellen.
5.2
Arbeitsumgebung
Zur Entwicklung und zum Betrieb des Servlets wurden folgende Programme eingesetzt:
• SUN NetBeans: NetBeans [24] ist eine Entwicklungsumgebung, die für Java
geschrieben wurde, aber grundsätzlich jede Programmiersprache unterstützt. NetBeans selbst ist vollständig in Java geschrieben und kann somit auf jeder beliebigen
Plattform mit einer Java 2 kompatiblen Virtual Machine eingesetzt werden. Verwendet wurde hier die Version 4.1, mittlerweile ist auch die Version 5 erschienen.
NetBeans ist kostenfrei erhältlich. Der Quellcode ist öffentlich verfügbar und unterliegt der SUN Public License (SPL) [25].
• Apache Tomcat: Apache Tomcat [26] ist im Rahmen des Jakarta Projektes
der Apache Software Foundation [27] entstanden und stellt eine Umgebung zur
Ausführung von Java-Code auf Webservern dar. Dabei handelt es sich um einen
Servlet-Container der neben Servlets auch Java Server Pages (JSP) ausführen kann.
Auch wenn Apache Tomcat einen Webserver integriert hat, so wird jedoch vielmals
der Apache2 Webserver mit Tomcat als Erweiterung eingesetzt. Die aktuelle Version ist 5.5.16 und ist kostenfrei erhältlich.
• Apache2 Webserver: [28] Der Apache Webserver ist ein Produkt der Apache
Software Foundation und der meistverbreitete Webserver im Internet. Zurückzuführen ist dies auf die breite Unterstützung verschiedener Betriebssysteme, so
werden neben Windows auch Unix, Linux, MacOS sowie weitere Systeme unterstützt. Die aktuelle Version ist 2.2.0 und ist kostenfrei erhältlich.
• Java2 Runtime Environment: Das Java Runtime Environment (JRE) ist eine
Java Laufzeitumgebung der Firma SUN. Bestandteile sind unter anderem die Java
Virtual Machine, welche zum Ausführen von Java-Anwendungen benötigt wird.
Die aktuelle Version ist 1.5.0 02-b09 und ist kostenfrei auf der Webseite von SUN
erhältlich.
• OpenOffice.org: OpenOffice.org ist ein umfangreiches Softwarepaket und bezeichnet sich selbst als Die freie Office-Suite“. Die aktuelle Version ist 2.0.2 und
”
20
steht auf der gleichnamigen Webseite kostenfrei zur Verfügung. Verwendet wurde
OpenOffice.org in erster Linie zur Erstellung und Bearbeitung von Grafiken.
Weiterhin wird zur Kommunikation mit dem Servlet eine Client-Software benötigt, normalerweise ein beliebiger Browser. Ebenso wird das Google API verwendet.
5.3
Umsetzung
Um eine möglichst einfache und intuitive Nutzung zu erlauben, ist der Ablauf bei Suchanfragen an den Ablauf einer herkömmlichen Google-Suche angepasst: Zentrales Element
der Startseite ist das Eingabefeld des Suchbegriffes. Weiterhin kann die Suche an dieser Stelle auf deutschsprachige Dokumente beschränkt werden. Da mit einem Zugangsschlüssel zum Google Web Sevice nur maximal 1.000 Anfragen pro Tag möglich sind,
gibt es an dieser Stelle die Möglichkeit zur Eingabe alternativer Zugangsschlüssel. Erfolgt
an dieser Stelle keine Angabe, so wird der dem Servlet zugeordnete Standardschlüssel
verwendet.
Für detaillierte Ergebnisse ist es an dieser Stelle schon möglich, zwischen einer normalen und detaillierten Ansicht zu wählen. Die detaillierte Ansicht untersucht automatisch
alle vom Google Web Service gelieferten Ergebnisse nach eingehenden und ausgehenden
Links. Als Voreinstellung ist die schnellere Normalansicht gewählt. Es kann zu jedem
Zeitpunkt zwischen den beiden Ansichten gewechselt werden. Nach Eingabe der Daten in das Formularfeld erfolgt der Aufruf des GoogleLinks-Servlet durch Betätigen der
Enter-Taste bzw. des Suchknopfes.
Die Formulardaten werden nun vom Servlet verarbeitet. Dieses stellt eine Anfrage an
den Web Service von Google um die benötigten Resultate, also die Suchergebnisse, zu
erhalten. Die Suchergebnisse werden nun dargestellt, wobei das Design sich ebenfalls an
einer typischen Google-Ergebnissseite orientiert. Falls die detaillierte Ansicht ausgewählt
wurde, werden an dieser Stelle bereits die Anzahl der ein- und ausgehenden Links für
alle Suchergebnisse angezeigt. Andernfalls steht für jedes Suchergebnis ein Link zum Erfragen der eingehenden Links sowie ein Link zum Erfragen der ausgehenden Links zur
Verfügung. Nach Aufruf einer dieser Links werden die Resultate an entsprechender Stelle
angezeigt.
5.4
Implementierung
Die Startseite index.html
Als Ausgangspunkt wird die Webseite index.html verwendet. In ihr wird neben des
verwendeten Zeichensatzes auch festgelegt, wer Empfänger der Formulardaten ist, in
diesem Fall also das Servlet GoogleLinks. Zum Übermitteln der Daten wird die HTTPMethode get verwendet. get fordert die Informationen eines Servers unter Angabe einer
Internetadresse (URL) an. Das heißt, die zu übertragenen Daten werden in der URL
übermittelt und entspricht folgendem Schema:
21
http://host/Servlet?Parameter1=Wert1?Parameter2=...
Alternativ kann die Übertragung mittels der HTTP Post-Methode erfolgen, wobei die
Daten hierbei nicht in der URL übermittelt werden sondern nicht sichtbar im HTTPHeader. Detaillierte Informationen zum HTTP-Standard sind im Anhang zu finden.
Listing 4:Auszug aus index.html
Das Servlet GoogleLinks
Die Klasse GLinks erbt von der abstrakten Klasse HttpServlet aus dem zugehörigen
Paket javax.servlet.http. Nach der Initialisierung des Servlets wird die Methode
doGet() aufgerufen. Alternativ kann auch die Methode doPost() verwendet werden,
beide übergeben Objekte der Klassen HttpServletRequest und HttpServletResponse
an die Methode ProcessRequest. Es werden bei jedem Aufruf des Servlets folgende Parameter übergeben: TextBox: Enthält den Suchbegriff bzw. die Suchbegriffe.
PushButton: Der Wert des Search“-Buttons
”
meta: Falls nur deutsche Webseiten gesucht werden sollen, wird dies hier festgelegt.
Page: Legt fest, welche Seite der Suchergebnisse angezeigt werden soll.
Item: Legt das zu untersuchende Element in der Ergebnissliste fest.
ItemPage: Legt fest, welche Operation für das in Item festgelegte Element ausgeführt
werden soll.
InOut: Legt fest, ob es sich um eingehende oder ausgehende Links handeln soll.
CheckBox: Legt die Form der Ansicht fest:detailiert oder kompakt.
key: der verwendete Zugangsschlüssel für das Google-API
UseCache: Legt fest, ob Daten aus dem Cache verwendet werden sollen.
Die beim Aufruf übergebenen Parameter werden vom Servlet-Container immer unter
einem Namen und dem dazugehörigen Wert gespeichert. Es ist möglich, das unter einem
Parameternamen mehrere Werte vorhanden sind. Um in einem Servlet auf diese Parameter zugreifen zu können, werden von der Schnittstelle javax.servlet.ServletRequest
folgende Methoden bereitgestellt:
• Die Methode getParamterNames() liefert ein Enumeration-Objekt (Auflistung)
der Namen aller verwendeten Parameter. Die Namen können der Reihe nach mit
enumeration.getNextElement() aus dem Objekt geholt werden. Mit der Methode
hasMoreElements() kann festgestellt werden, ob sich noch mehr Namen in der
Auflistung befinden.
• Mit der Methode getParamterValues(String name) wird ein Feld (Array) geliefert, welches zu den angegebenen Namen die entsprechenden Werte beinhaltet.
• Mit getParameter(String name) erhält man einen String, der den ersten Wert
enthält, den man mit getParamterValues(String name) erhalten würde.
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
22
res.setContentType("text/html; charset=UTF-8");
.
.
.
Enumeration parameterNamen = req.getParameterNames();
Enumeration parNames = req.getParameterNames();
.
.
.
}
Listing 4: Auszug aus GLinks.java
Die so eingelesenen Parameter (Listing 4) werden alle in einem Objekt der Klasse
ParameterValues verwaltet.
Aufruf des Google Web Service
Nachdem alle erforderlichen Parameter vorhanden sind, folgt im nächsten Schritt die
Anfrage an das Google-API. Dazu wird zunächst das Paket com.google.soap.search
eingebunden. Die wesentlichen Klassen des Google API sind dabei GoogleSearch und
GoogleSearchResult, wobei GoogleSearch die Suche unter Berücksichtung der gesetzten Parameter ausführt und als Ergebnis ein Objekt vom Typ GoogleSearchResult
liefert.
GoogleSearch s = new GoogleSearch();
s.setStartResult ((par.getPage() * 10));
s.setKey (par.getKey());
s.setLanguageRestricts (par.getLanguage());
s.setQueryString (par.getTextBox());
try {
GoogleSearchResult r = s.doSearch();
result = new SearchValueArray (r, par.getPage(),0, "base", par);
.
.
.
}catch (Exception e ) {System.out.println (e.toString());}
Listing 5: Auszug aus GLinks.java
Die vom Google Web Service gelieferten Suchergebnisse werden in das Objekt result
vom Typ SearchValueArray übernommen. Die Funktion dieser Klasse wird im Folgendem näher erläutert.
23
Die Klasse SearchValueArray
Die Klasse SearchValueArray ist zentrale Klasse des Servlets und stellt eine Vielzahl
von Operationen bereit. Sie enthält zum einen alle Ergebnisse der Google-Suche, zum
anderen die verwendeten Parameter. Wesentliches Element dieser Klasse ist die Datenstruktur: ein Feld (Array) vom Typ SearchValueType. In ihm werden die von Google
gelieferten Suchergebnisse sowie gegebenenfalls die ebenfalls von Google gelieferten Ergebnisse für eingehende Links auf Webseiten gespeichert, ebenso die selbst erzeugten
Ergebnisse für ausgehende Links.
Abbildung 9: Array vom Typ SearchValueType
Nach erfolgter Suche wird eine Google-typische Ergebnisseite angezeigt. Zusätzlich enthält
jeder Eintrag einen Link zum Erfragen der eingehenden Links (get Inbound Links) und
ausgehenden Links(get Outbound Links) sowie die Google-typischen Links für Cached
Pages (C) oder Similar Pages (S) (Abb. 10).
Abbildung 10: Beispiel für ein einzelnes Suchergebnis
An dieser Stelle beginnt die eigentliche Aufgabe des Servlets: Die Untersuchung der
Linkstruktur von Webseiten. Durch Aufruf des get Inbound Links-Link werden die zu
der entsprechenden Webseite eingehenden Links ermittelt. Dazu wird ebenfalls wieder
eine Anfrage an den Google Web Service getätigt, welcher die ihm bekannten eingehenden
24
Links übermittelt. Verwendet wird hierbei die bereits vorgestellte Funktion Link:URL
von Google.
void setSingleInboundLinks (int arrayID, int page, ParameterValues par) {
GoogleSearch f = new GoogleSearch ();
f.setKey (par.getKey());
f.setQueryString ("link:"+ this.result[arrayID].getURL());
f.setStartResult (page * 10);
try {GoogleSearchResult t = f.doSearch();
SearchValueArray temp = new SearchValueArray(t, page,
this.result[arrayID].getLevel()+1, "in");
...
this.insertArray (temp.result, arrayID);
} catch (Exception e) {System.out.println (e.toString());}
}//setSingleInboundLinks
Listing 6: Auszug aus der Methode setSingleInboundLindLinks
Um die Ergebnisse entsprechend in der Datenstruktur zu verwalten, sind in der Klasse
SearchValueArray einfache Feldoperationen wie das Einfügen und Löschen von Elementen an beliebigen Positionen implementiert. Auf diese Weise können die Ergebnisse einer
Anfrage nach eingehenden Links für eine Webseite an entsprechender Stelle eingefügt
werden. Um diese Elemente als eingehende Links für einen bestimmten Eintrag zu identifizieren, wird die Variable level gegenüber des zu untersuchenden Eintrags um eins
erhöht. Analog ist die Funktionsweise für Untersuchung auf ausgehende Links, jedoch
wird dazu nicht der Google Web Service verwendet sondern das Dokument eingelesen
und nach vorhandenen Links gescannt. Diese werden dann ebenfalls an entsprechender
Stelle in der Datenstruktur eingefügt. Weitere Methoden der Klasse SearchValueArray
werden nachfolgend in den entsprechenden Kapiteln vorgestellt.
Untersuchen von Webseiten nach ausgehenden Links
Nachdem das Vorgehen für die Suche nach eingehenden Links auf Webseiten bereits
mehrmals kurz erwähnt wurde, soll sich dieser Abschnitt mit der Suche nach ausgehenden Links beschäftigen. Dazu wird die zu untersuchende Webseite zeilenweise eingelesen
und nach allen möglichen Vorkommen von Links gescannt. Viele Webserver verweigern
den Zugriff auf ihre Dokumente, wenn dieser nicht über einen Browser erfolgt. Aus diesem
Grund ist es notwendig, das Sevlet als Browser auszugeben. Dazu wird der User-Agent
entsprechend gesetzt, hier Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0). Dennoch sind einige wenige Webserver in der Lage festzustellen, dass diese Anfrage nicht von
einem Browser kommt und reagieren mit einem entsprechenden Statuscode (403/404 siehe Anhang zum HTTP-Protokoll).
25
try {
URL v = new URL (this.result[arrayID].getURL());
URLConnection conn = v.openConnection();
conn.setRequestProperty("User-Agent",
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)");
Reader is = new InputStreamReader (conn.getInputStream());
BufferedReader in = new BufferedReader (is);
...
for ( String s; ( s = in.readLine() ) != null; ) {
...
} //for
...
this.insertArray(res, getNextLinkOnThisLevel (arrayID)-1);
...
} catch (Exception e) {System.out.println (e.toString());}
}
Listing 7: Auszug aus der Methode setSingleOutboundLinks
Nachdem alle Links der zu untersuchenden Webseite identifiziert wurden, werden diese
nun analog zu den eingehenden Links an entsprechender Stelle in der Datenstruktur
eingefügt. Für den Fall das die detaillierte Ansicht gewählt wurde, werden für alle Ergebnisse der Suche parallel die eingehenden und ausgehenden Links untersucht, jedoch
wird nur die Anzahl der Links angezeigt, nicht die Ergebnisse. Dazu wird ein Array
verwendet, welches für jeden zu untersuchenden Eintrag einen Thread enthält (Siehe
Listing 9).
Thread [] threadArray = new Thread [this.result.length];
GLinksOutThread[] outLinksArray = new GLinksOutThread[this.result.length];
try {
for (int i=0; i<=this.result.length-1; i++) {
outLinksArray[i] = new GLinksOutThread (this.result[i].getURL());
threadArray[i]=new Thread (outLinksArray[i]);
threadArray[i].start();
}
}catch (Exception e ) {System.out.println (e.toString());}
Listing 8: Auszug aus der Methode SetAllOutboundLinksNumber
Zwischenspeicherung (Caching)
Um bereits bekannte Ergebnisse nicht in jedem Schritt neu abfragen zu müssen, werden
diese zwischengespeichert. Dadurch werden erhebliche Geschwindigkeitsvorteile erzielt.
Weiterhin wird damit die Verwendung der Navigation innerhalb des Browsers (Vor- und
26
Zurück-Schaltflächen) ermöglicht, ohne das irgendwelche zeitintensiven Operationen ausgeführt werden müssen: Es wird lediglich das bereits gespeicherte Ergebnis erneut gesendet. Dazu wird muss jede Anfrage eindeutig identifiziert werden können. Um dies zu
ermöglichen, wird bei jeder Anfrage an das Servlet ein Zeitstempel gesetzt und dieser
zusammen mit den Daten gespeichert. Neben dem Zeitstempel sind auch der Suchbegriff und die angezeigte Seite relevant. Jede Suche wird dabei in einer einzelnen Datei
der Form tempXXX.ser im automatisch erzeugten Temp-Ordner gespeichert, wobei XXX
durch die entsprechende Speicherplatznummer ersetzt wird. Die Anzahl der zu speichernden Einträge kann individuell verändert werden, die jeweils älteste Anfrage wird durch
die aktuelle überschrieben. Eine Übersicht der gespeicherten Suchanfragen befindet sich
in der Datei tempIndex.ser, über welche die zu ladende bzw. die zu überschreibende
Datei identifiziert wird. Durch diese Form des Caching ist auch möglich, das mehrere
Nutzer das Servlet zur selben Zeit verwenden. Im folgendem soll anhand eines konkreten
Testlaufes die Arbeitsweise des Servlets noch einmal näher erläutert werden.
Testlauf
In diesem Abschnitt wird ein Testlauf für die Webseite der Universität Jena (http://www.uni-jena.de) durchgeführt. Dazu wird als Suchbegriff uni-jena verwendet. Alle anderen Optionen können bei den Standardeinstellungen belassen werden. Nach dem Ausführen
Abbildung 11: Die Startseite index.html
der Suche wird zunächst die Google-ähnliche Ergebnissseite angezeigt, wobei an erster
27
Stelle die Webseite der Universität Jena aufgelistet ist. Die Suche erfolgte wie bereits
beschrieben durch eine Anfrage an den Google Web Service, welcher die ersten 10 Ergebnisse zur Suche nach uni-jena wie erwartet geliefert hat. Die Suchergebnisse sind
identisch mit einer Google-Suche über die Google Webseite. Als Erstes soll eine Suche
Abbildung 12: Ergebnisseite für die Suche nach uni-jena
nach eingehenden Links durchgeführt werden. Dazu wird der entsprechende Link zum
Erfragen der Inbound-Links angewählt. Die erforderlichen Paramerter werden nun auf
die oben beschriebene Art und Weise an das Servlet weitergeleitet und verarbeitet. Zum
Erfragen der eingehenden Links einer Webseite wird ebenfalls auf den Google Web Service zurückgegriffen. Die Auflistung der angeforderten Links erscheint direkt unter der
untersuchten URL und hebt sich farbig vom restlichen Dokument ab. Auch hier kann für
jeden Eintrag nach ein- und ausgehenden Links gesucht werden. Um schnellstmöglich zu
dem angefordertem Ergebnis, also zu der Linkliste, zu gelangen, wird mittels gesetzter
Sprungmarken (Anker) direkt nach Aufruf die entsprechende Stelle im Webdokument
angezeigt. Hauptaugenmerk bei der Entwicklung des Servlets war eine einfache und in-
28
tuitive Navigation. So wird jede Linkliste, egal ob ein- oder ausgehend, farblich hinterlegt
und mit einer einfachen Navigation am Kopf der Liste versehen. Damit ist es möglich,
innerhalb einer Linkliste seitenweise zu blättern, die Anzahl der angezeigten Ergebnisse
in 10er-Schritten zu erweitern oder die Liste zu schließen. Wird ein Element der Linkliste wieder nach eingehenden oder ausgehenden Links untersucht, so erscheint eine neue
Linkliste, ebenfalls farblich hinterlegt, an entsprechender Position. Auf diese Art und
Weise ist es möglich, die Linkstruktur beliebig weit zu verfolgen.
Für ausgehende Links verfährt man analog. Wie bereits erwähnt wird hierbei die zu
untersuchende Webseite eingelesen und nach Links gescannt. Dabei werden neben den
herkömmlichen HTML-Links auch Links erfasst, die sich hinter Bildern befinden, ebenso Links innerhalb einer Image-Map, also einer Grafik, die in verschiedenen Bereichen
mit verschiedenen Links hinterlegt ist. Ein typisches Beispiel für eine Image-Map ist
eine Weltkarte, in der ein Kontinent oder ein Land durch anklicken mit der Maus ausgewählt wird. Falls die Links relativ zum Dokument gesetzt sind, also nicht vollständig
mit Serveradresse und eventuellen Verzeichnissen, so wird dies innerhalb der Linklisten
automatisch ergänzt.
Gegenstand der folgenden Betrachtung ist der Wechsel zwischen der kompakten Ansicht und der detaillierten Ansicht. Zwischen diesen beiden Ansichten kann jederzeit
gewechselt werden. In der detaillierten Ansicht werden zu jedem Eintrag der Linkliste
automatisch die Anzahl der eingehenden und ausgehenden Links angezeigt. Dies bring
natürlich eine größerer Zeitverzögerung gegenüber der Kompaktansicht mit sich, denn
für jeden Eintrag werden die eingehenden Links am Google Web Service erfragt, wobei
dort mit relativ konstanter Dauer der Anfragen zu rechnen ist.
Wesentlich weniger vorhersehbar ist die Dauer der Untersuchung nach ausgehenden
Links: Dazu wird jeder Eintrag einzeln eingelesen und nach Links untersucht. Je nach
Anbindung und Verfügbarkeit der jeweiligen Webserver sowie der Größe der zu untersuchenden Webseiten ist mit einer gewissen Verzögerung zu rechnen. Falls eine Webseite
nicht erreichbar ist, so wird nach einer gewissen Zeit der HTTP-Statuscode 403/403
ausgegeben (Siehe Anhang: Exkurs zum HTTP-Standard).
Falls Links hinter Bildern hinterlegt sind, so wird die durch die Anzeige Image-Link
kenntlich gemacht. Durch das Zeigen mit der Maus aus den Image-Link wird mittels
JavaScript eine Bildvorschau angezeigt.
29
Abbildung 13: Ausgehende Links für http://www.uni-jena.de
30
Abbildung 14: Eingehende Links für http://www.uni-jena.de
31
<script>
<!-tt = null;
document.onmousemove = updateTT;
function updateTT(e) {
x = (document.all) ? window.event.x + document.body.scrollLeft : e.pageX;
y = (document.all) ? window.event.y + document.body.scrollTop : e.pageY;
if (tt != null) {
tt.style.left = (x + 20) + "px";
tt.style.top = (y + 20) + "px";
}
}
function showTT(id) {
tt = document.getElementById(id);
tt.style.display = "block"
}
function hideTT() {
tt.style.display = "none";
}
//-->
</script>
.
.
.
<DIV class="tooltip" ID="29">
<P>
<img src="http://www.uni-jena.de/skin/unijena/images/unibund_small.jpg"
width="50%">
</P>
</DIV>
<a href="http://www.univerbund.de"ONMOUSEOVER="showTT(’29’)"
ONMOUSEOUT="hideTT()">&diams; Image-Link
</a>
Listing 9: Tooltip-Funktion mittels JavaScript
Mittels der Navigationsleiste oberhalb jeder Linkliste kann durch anwählen des X-Zeichen
jederzeit die Liste wieder geschlossen werden. Aufgrund der gewählten Datenstruktur
kann das Webdokument beliebig viele Einträge annehmen und verwalten.
32
Abbildung 15: Bildvorschau mittels JavaScript
33
6
Zusammenfassung und Ausblick
Das Servlet GLinks stellt eine einfache Möglichkeit zur Untersuchung der Linkstruktur
von Webdokumenten bereit. Dabei wird auf den Web Service von Google zur Untersuchung nach eingehenden Links zurückgegriffen. Für ausgehende Links werden die zu
untersuchenden Webseiten zeilenweise eingelesen und nach Links untersucht. Während
eine Anfrage an den Google Web Service in der Regel relativ schnell abläuft, so kann
es beim Einlesen und untersuchen nach ausgehenden Links teilweise zu Verzögerungen
durch langsame Server oder langsame Serveranbindung. Außerdem spielt auch die Größe
der zu untersuchenden Seite eine Rolle.
Standardmäßig wird die Kompaktansicht verwendet, welche gegenüber der Detailansicht
schneller arbeitet, aber auch weniger Informationen liefert, so wird Anzahl der ein- ausgehenden Links erst auf Anfrage geliefert. Um trotzdem schnellstmöglich die Ergebnisse
zu erhalten, wurden die Anfragen in Detailansicht parallelisiert. Um bereits bekannt Ergebnisse nicht mehrmals abzufragen, wurde eine einfache und effektive Caching-Strategie
verwendet.
Um eine bessere Anschaulichkeit zu bewirken, wäre es teilweise vorteilhaft die Ergebnisse grafisch darstellen zu können um einen besseren Überblick über die Verweistruktur
zu erlangen. Eine grafische Darstellung könnte dabei ähnlich wie in Abb. 16 aussehen.
Der Google Web Service stellt nur 1.000 Anfragen pro verwendeten Schlüssel bereit,
wobei jede Anfrage nur höchstens 10 Ergebnisse liefert. Durch parallele Abfragen wird
das zur Verfügung gestellte Kontigent schnell verbraucht, so dass ein eine unbeschränkte Anzahl von Suchanfragen wünschenswert wäre. Weiterhin wäre es denkbar, GLinks
selbst in Form eines Web Service bereitzustellen.
Die Verwendung des Google Web Service zur Untersuchung eingehender Links stellt eine
ausgereifte Möglichkeit dar, Google verfügt momentan über den größten Datenbestand
von Webseiten. Dennoch kann es vorkommen, das einige Einträge nicht mehr aktuell sind
oder unter anderen Adressen zu finden sind. Bei einem solchen Datenbestand können
die Einträge nur in gewissen Zeitabständen auf Erreichbarkeit bzw. Änderung untersucht werden. Trotz alledem stellt der Google Web Service eine zuverlässige Möglichkeit
zum Zugriff auf den Datenbestand einer Suchmaschine dar. Zudem ist er momentan der
einzige Service seiner Art und hervorragend geeignet für die Untersuchung nach eingehenden Links. Auch wenn er sich erst im Beta-Stadium befindet liefert er dennoch sehr
zuverlässig und in relativ kurzer Zeit die gewünschten Ergebnisse. Die zur Verfügung
gestellte API für verschiedene Programmiersprachen erlaubt es auch ohne tiefgründige
Kenntnisse in Web Service Technologien den von Google angebotenen Service zu verwenden. Generell sind Web Services ein relativ neuer Service, der sich jedoch zunehmender
Beliebtheit erfreut und sich auch in Zukunft weiter verbreiten wird.
34
35
Abbildung 16: Mögliche grafische Darstellung der Linkstruktur
A
WSDL-Dokument
WSDL-Dokument zur Beschreibung des Web Service von www.nanonull.com
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://www.Nanonull.com/TimeService/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://www.Nanonull.com/TimeService/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified"
targetNamespace="http://www.Nanonull.com/TimeService/">
<s:element name="getUTCTime">
<s:complexType />
</s:element>
<s:element name="getUTCTimeResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="getUTCTimeResult"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
</s:schema>
</wsdl:types>
<wsdl:message name="getUTCTimeSoapIn">
<wsdl:part name="parameters" element="tns:getUTCTime" />
</wsdl:message>
<wsdl:message name="getUTCTimeSoapOut">
<wsdl:part name="parameters" element="tns:getUTCTimeResponse" />
</wsdl:message>
<wsdl:portType name="TimeServiceSoap">
<wsdl:operation name="getUTCTime">
<wsdl:input message="tns:getUTCTimeSoapIn" />
<wsdl:output message="tns:getUTCTimeSoapOut" />
</wsdl:operation>
36
</wsdl:portType>
<wsdl:binding name="TimeServiceSoap" type="tns:TimeServiceSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<wsdl:operation name="getUTCTime">
<soap:operation SoapAction="http://www.Nanonull.com/TimeService/getUTCTime"
style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="TimeService">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">A sample Time service
</documentation>
<wsdl:port name="TimeServiceSoap" binding="tns:TimeServiceSoap">
<soap:address location="http://www.nanonull.com/TimeService/TimeService.asmx" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
37
B
Einige UDDI-Server
uddi.microsoft.com
Microsoft’s UDDI Business Registry Node
uddi.ibm.com
IBM’s UDDI Business Registry Node
uddi.sap.com
SAP’s UDDI Business Registry Node
www.ntt.com/uddi/index-e.html
NTT Com’s UDDI Business Registry Node
Weiterhin werden folgende Server zu Testzwecken vor dem eigentlichen Eintragen in
das UDDI-Verzeichnis zur Verfügung gestellt:
test.uddi.microsoft.com
Microsoft’s Test UDDI Registry.
uddi.ibm.com/testregistry/registry.html
IBM’s Test UDDI Registry.
udditest.sap.com
SAP’s Test UDDI Registry
38
C
Exkurs: Das Hypertext Transfer Protocol - HTTP
Im Folgendem soll eine kurze Übersicht über HTTP gegeben werden. Dieser Abschnitt
ist aus [22], Seite 369-370 übernommen.
Das Hypertext-Transfer-Protocol wurde 1989 von Tim Berners-Lee am CERN in Genf
entwickelt. Informationen, die über diesen Exkurs hinausgehen, können beim W3C unter
http://w3c.org/Protocols nachgelesen werden. Das HTTP ist dabei in RFC 2616 festgelegt.
Die aktuelle Version des Protokoll ist HTTP 1.1. Diese Version sollten auch alle ServletContainer unterstützen. Seine Funktion besteht grundlegend darin, Daten zu übertragen.
Dies geschieht mit Hilfe eines Anfrage/Antwort-Schemas. Eine HTTP-Antwort besteht
immer aus einem Kopf (Head), der unter anderem den Typ der Daten beschreibt. Dies
geschieht durch so genannte Multipurpose Internet Mail Extension (MIME), die in RFC
2045 festgelegt sind. Sie dienen dazu, einem Client anzuzeigen, um welchen Typ von Daten es sich handelt, und der Client somit die erforderlichen Maßnahmen einleiten kann,
um diese Daten zu verarbeiten. Ein Browser wird z.B. Daten vom Typ text/html anders
handhaben als Daten vom Typ html/pdf. [...] Ferner enthält ein Kopf z.B. Informationen zu [...] Status-Codes. Überdies kann eine Antwort einen Rumpf enthalten, der die
eigentlichen Daten enthält.
Die Befehle, die vom Client an den Server gestellt werden können sind folgende:
• OPTION : Dieser Befehl stellt eine Anfrage an den Server, der dem Client die
verfügbaren Kommunikations-Optionen des Servers zurückgibt.
• GET : GET fordert die Informationen eines Servers unter Angabe eines Uniform
Resource Identifiers (URI) an. Ein GET -Befehl wird zum Beispiel bei jedem Aufruf
einer Seite durch einen Browser gestellt. Dabei liefert der Server die Seite, deren
Quelle in einem URI ausgedrückt wird, an den Client.
• HEAD: Der HEAD-Befehl liefert ähnlich dem GET -Befehl die Informationen unter
Angabe eines URI. Allerdings ohne den Rumpf. Der Server liefert nur den Kopf.
• POST : Der POST -Befehl sendet Daten an einen bestimmten URI, worauf der
Server entweder ein Okay“sendet oder meldet, dass er zu diesen Daten keine Ant”
wort generieren kann: No Content“. Dies geschieht z.B. durch Absenden eines
”
HTML-Formulars aus dem Browser. Dabei werden die Informationen, die in Formularfelder und -auswahlstrukturen eingegeben bzw. ausgewählt wurden, an den
Server gesendet. Diese Informationen besitzen immer einen Namen und einen Wert.
Sie stehen im Kopf der Anfrage und heißen Parameter.
• PUT : Mit dem PUT -Befehl kann man beispielsweise eine Datei an einen bestimmten URI auf einem Server senden.
• DELETE : Der Befehl DELETE fragt beim Server an, ob die Quelle eines URI
gelöscht wird, allerdings ohne Garantie des Servers.
39
• TRACE : Der TRACE -Befehl erlaubt dem Client zu überprüfen, welche Daten
beim Server angekommen sind, um diese dann auszuwerten oder mithilfe dieser
Informationen Test durchzuführen.
• CONNECT : Dieser Befehl wird beim Gebrauch eines Proxies benutzt, der dynamisch zu einem Tunnel werden kann (z.B. SSL-Tunnel).
Die am häufigsten benutzten Befehle hiervon sind GET und POST. Mithilfe dieser
ist es möglich, Daten von einem Servlet zu holen (GET) oder Informationen an ein
Servlet zu senden (POST), das diese dann verarbeiten soll. Im Browser bedeutet
dies nichts anderes, als einen URI in die Adresszeile einzugeben. Der Server liefert
daraufhin die angeforderte Seite, die der Browser je nach MIME-Typ darstellt.
Jede Antwort des Servers enthält ferner einen so genannten Status Code (SC).
Statuscodes sind dreistellige Zahlen und können durch ihre erste Ziffer in folgende
Gruppen unterteilt werden: Statuscodes der Form 2xx bedeuten, dass die Anfrage
des Clients erfolgreich empfangen, verstanden und akzeptiert wurde (Successful).
Beispiele:
200 OK
204 No Content - Der Server hat die Anfrage verstanden, hat aber keinen Inhalt,
den er im Rumpf an den Client senden soll.
Statuscodes der Form 3xx bedeuten, dass weitere Maßnahmen vom Client eingeleitet werden müssen, um die Anfrage zu vervollständigen (Redirection).
Beispiele:
301 Moved Permanently - Der angefragte URI wurde dauerhaft an eine der mitgesandten URIs verlegt.
302 Not Modified - Die Seite wurde seit der letzten Anfrage nicht verändert und
es wird deshalb kein Rumpf mitgeliefert.
Statuscodes 4xx bedeuten einen Fehler beim Client.
Beispiele:
403 Forbidden - Der Server hat die Anfrage verstanden, verweigert aber, eine Seite
auszugeben.
404 Not Found - Der Server hat nichts Passendes zum angefragten URI gefunden.
Statuscodes der Form 5xx besagen einen Fehler beim Server.
Beispiele:
40
500 Internal Server Error - Der Server konnte unerwartet eine Anfrage nicht
erfüllen.
501 Not Implemented - Der Server unterstützt die Funktion der Anfrage nicht.
41
D
Glossar
API: Das Application Programming Interface (API) ist eine Schnittstelle zur Anwendungsprogrammierung, die von einem Betriebssystem oder von einem anderen Softwaresystem weiteren Programmen zur Verfügung gestellt wird. Dabei wird die
Verwendung der Schnittstellen auf Quelltextebene definiert.
Browser: Ein spezielles Programm, mit dem man über das WWW Zugang zu WWWServern erlangen und von diesem angeforderte Dokumente anzeigen kann.
Client: Bezeichnet ein Programm, dass einen Server kontaktiert und von diesem Informationen anfordert. Der im WWW eingesetzte Browser ist in diesem Sinne ein
Client. Aber es gibt auch andere Clients im WWW, die WWW-Server kontaktieren und Informationen von diesen herunterladen, wie z.B. Suchmaschinen oder
Agenten.
CORBA: Die Common Object Request Broker Architecture, kurz CORBA, ist eine
objektorientierte Middleware, die plattformübergreifende Protokolle und Dienste
definiert und von der Object Management Group (OMG) entwickelt wird. CORBA
vereinfacht das Erstellen verteilter Anwendungen in heterogenen Umgebungen.
Firewall: Eine Firewall (engl. Brandwand bzw. Brandschutzmauer) ist ein System aus
Software- und Hardwarekomponenten, das den Zugriff zwischen verschiedenen Rechnernetzen beschränkt, um ein Sicherheitskonzept umzusetzen. Hardwarekomponenten einer Firewall sind Rechner mit Netzwerkschnittstellen wie Router oder
Hosts; Softwarekomponenten sind beispielsweise Paketfilter oder Proxyserver. Ein
häufiger Einsatzzweck einer Firewall besteht darin, den Datenverkehr zwischen einem zu schützenden lokalen Netzwerk (LAN) und dem Internet zu kontrollieren.
Google: Google ist die Internet-Suchmaschine der Firma Google Inc. mit Sitz in Mountain View (USA). Die Firma wurde am 7. September 1998 von Larry Page und
Sergey Brin gegründet. Am gleichen Tag wurde eine erste Testversion des Programms auf den Markt gebracht. Noch im selben Jahr ging die Suchmaschine
offiziell ans Netz und ist mittlerweile eine der meistgenutzten Suchmaschinen im
WWW.
HTML: Hypertext Markup Language, das einheitliche Dokumentenformat für Hypermedia-Dokumente im WWW. Dokumente, die im WWW übertragen und vom
Browser dargestellt werden sollen, sind in HTML kodiert.
HTTP: Hypertext Transfer Protocol, das Protokoll, das die Kommunikation von Browsern und WWW-Servern im WWW regelt. Fordert ein Browser ein Dokument vom
WWW-Server an oder beantwortet der WWW-Server eine Anfrage, muß diese Anfrage den Konventionen des HTTP-Protokolls gehorchen.
42
HTTPS: HTTPS steht für Hypertext Transfer Protocol Secure und ist ein Netzwerkprotokoll, das eine gesicherte HTTP-Verbindung zwischen Rechnern ermöglicht.
Hyperlink: Als Hyperlink (auch kurz Link; aus dem Englischen für Verknüpfung, Verbindung, Verweis) bezeichnet man einen Verweis auf ein anderes Dokument in
einem Hypertext, der durch das Hypertextsystem automatisch verfolgt werden
kann.
Hypertext: Hypertext ist eine nicht-lineare Organisation von Objekten, deren netzartige Struktur durch logische Verbindungen (Verweise, Links) zwischen Wissenseinheiten (Knoten, z. B. Texten oder Textteilen) hergestellt wird (Verweis-KnotenKonzept). Die Begriffe Hypertext und Hypermedia werden meistens synonym benutzt; Hypertext betont dabei jedoch den textuellen Anteil, Hypermedia dagegen
mehr den multimedialen.
Java: Java ist eine objektorientierte Programmiersprache und als solche ein eingetragenes Warenzeichen der Firma Sun Microsystems. Java-Programme werden in einer
speziellen Umgebung, der Java-Laufzeitumgebung oder Java-Plattform ausgeführt,
deren wichtigster Bestandteil die Java Virtual Machine ist. Dazu werden JavaProgramme in Bytecode übersetzt, der von der virtuellen Maschine ausgeführt
wird. Java-Programme laufen in aller Regel ohne weitere Anpassungen auf verschiedenen Computern und Betriebssystemen.
JRE: JRE steht im engeren Sinne für Java Runtime Environment (deutsch Java-Laufzeitumgebung) des US-Unternehmens Sun Microsystems. Sie liefert unter anderem
die Java VM (Virtual Machine). Sie wird benötigt, um Java-Applikationen auszuführen. Die JRE kann in der jeweils neusten Version auf der Homepage von Sun
Microsystems heruntergeladen werden.
Namensdienst: (Naming Service), ein Netzwerkanwendungsprogramm, das logische,
leicht merkbare Namen einer Ressource oder einer Person auf numerische Netzwerkadressen abbildet.
Netzanwendung: Ein Anwendungsprogramm, dessen Ablauf den Zugriff auf Ressourcen einschließt, die nicht lokal auf dem ausführenden Rechner liegen, sondern auf
einem entfernten Rechner über das Netzwerk zugegriffen werden.
RFC: Die Requests for Comments (kurz RFC; zu deutsch Aufforderung zu Kommentaren) sind eine Reihe von technischen und organisatorischen Dokumenten des
RFC-Editor zum Internet (ursprünglich ARPANET), die am 7. April 1969 begonnen wurden. Bei der ersten Veröffentlichung noch im ursprünglichen Wortsinne zur
Diskussion gestellt, behalten RFC auch dann ihren Namen, wenn sie sich durch
allgemeine Akzeptanz und Gebrauch zum Standard entwickelt haben.
43
RPC: Remote Procedure Call, oder kurz RPC, ist ein Netzwerkprotokoll auf der Anwendungsschicht des TCP/IP Referenzmodells. Mit Hilfe von RPC können über
ein Netzwerk Funktionsaufrufe auf entfernten Rechnern durchgeführt werden.
RSS: RSS (Abkürzung für Really Simple Syndication, zu deutsch etwa echt einfache
”
Verbreitung“) ist eine Technologie, die es dem Nutzer ermöglicht, die Inhalte einer
Webseite –oder Teile davon –zu abonnieren.
Server: Bezeichnet einen Prozess, der von Clients kontaktiert wird, um diesen Informationen zurück zu liefern. Oft wird auch der Rechner, auf dem ein Server-Prozess
abläuft als Server bezeichnet.
Servlet: Als Servlets bezeichnet man Java-Klassen, deren Instanzen innerhalb eines
Webservers Anfragen von Clients entgegen nehmen und beantworten. Solche Klassen müssen immer die Schnittstelle javax.servlet.Servlet oder eine davon abgeleitete (normalerweise javax.servlet.http.HttpServlet) implementieren. Der
Inhalt der Antworten kann dabei dynamisch, also im Moment der Anfrage, erstellt
werden und muss nicht bereits statisch (etwa in Form einer HTML-Seite) für den
Webserver verfügbar sein.
SOAP: Das Simple Object Access Protocol (SOAP) ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls (RPC)
durchgeführt werden können. SOAP stützt sich auf die Dienste anderer Standards,
XML zur Repräsentation der Daten und Internet-Protokolle der Transport- und
Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination
ist SOAP über HTTP.
SPL:
SSL: Transport Layer Security (TLS) oder Secure Sockets Layer (SSL) ist ein Verschlüsselungsprotokoll für Datenübertragungen im Internet. TLS 1.0 und 1.1 sind
die standardisierten Weiterentwicklungen von SSL 3.0. Hier wird die Abkürzung
SSL für beide Bezeichnungen verwendet. Im OSI-Modell ist SSL oberhalb der
Transportschicht (z.B. TCP) und unter Applikationsprotokollen wie HTTP oder
SMTP angesiedelt. SSL arbeitet transparent, so dass es leicht eingesetzt werden
kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar, um Flexibilität und
Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten.
UDDI: Universal Description, Discovery and Integration (UDDI) bezeichnet einen Verzeichnisdienst, der die zentrale Rolle in einem Umfeld von dynamischen Web Services spielen soll.
44
W3C: Das World Wide Web Consortium, oder auch W3C, ist das Gremium zur Standardisierung das World Wide Web betreffender Techniken. Gründer und Vorsitzender des W3C ist Tim Berners-Lee. Es wurde 1994 gegründet.
Web Service: Ein Web Service ist eine Software-Anwendung, die mit einem Uniform
Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstellen
mit der Auszeichnungssprache XML definiert, beschrieben und gefunden werden
können. Ein Web Service unterstützt die direkte Interaktion mit anderen SoftwareAgenten unter Verwendung XML-basierter Nachrichten durch den Austausch über
internetbasierte Protokolle.
WSDL: WSDL - Die Web Services Description Language (WSDL) definiert einen plattform-, programmiersprachen- und protokollunabhängigen XML-Spezifikation zur
Beschreibung von Netzwerkdiensten (Web Services) zum Austausch von Nachrichten.
WWW: Das World Wide Web (kurz Web, WWW oder deutsch: Weltweites Netz, Weltweites Netzwerk; wörtlich: web = Gewebe, Netz) ist ein über das Internet abrufbares Hypertext-System. Das WWW wird im allgemeinen Sprachgebrauch oft mit
dem Internet gleichgesetzt, obwohl es jünger ist und nur eine mögliche Nutzung des
Internets darstellt (so wie im Gegenzug das Internet nur eine von verschiedenen
möglichem Serververbünden ist). Es gibt durchaus Internet-Dienste, die nicht in
das WWW integriert sind wie zum Beispiel E-Mail oder Telnet.
XML: XML - Abkürzung für Extensible Markup Language, eine 1998 vom World-WideWeb-Consortium standardisierte Sprache, mit der sich Auszeichnungssprachen definieren lassen. Insbesondere können bestimmte Teile von XML selbst definiert und
im gleichen Dokument auch genutzt werden. Dadurch werden der Seitenaufbau und
die Behandlung von Daten mit XML erheblich flexibler.
45
E
Wichtige Internetadressen
• Webseite des World Wide Web Consortium:
http://www.w3c.org/
• Homepage der Firma Sun Microsystems
http://www.sun.com/
• Homepage der Programmiersprache Java
http://www.java.com/
• Webseite des Google API
http://www.google.com/apis/
F
Abkürzungen und Akronyme
API
HTML
HTTP
HTTPS
JRE
RFC
RPC
RSS
SOAP
SPL
SSL
UDDI
W3C
WSDL
WWW
XML
Application Programming Interface
Hypertext Markup Language
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure
Java Runtime Environment
Request for Common
Remote Procedure Call
Really Simple Syndication
Simple Object Access Protocol
Sun Public License
Secure Socket Layer
Universal Description, Discovery and Integration
World Wide Web Community
Web Service Description Language
World Wide Web
Extensible Markup Language
46
Literatur
[1]
Homepage der Suchmaschine Google: www.google.de,
[2]
HTML Activity Page des W3C:
http://www.w3.org/MarkUp/ .
[3]
Homepage des Google Webservice:
http://www.google.com/api .
[4]
Java Servlet Homepage:
http://java.sun.com/products/servlet/ .
[5]
Web Service Architecture Requirement des W3C:
http://www.w3.org/TR/wsa-reqs/
[6]
Homepage des World Wide Web Consortium – W3C:
http://www.w3c.org/
[7]
CORBA Homepage der Object Management Group:
http://www.corba.org/
[8]
SOAP Homepage des W3C:
http://www.w3.org/TR/soap/
[9]
WSDL Homepage des W3C:
http://www.w3.org/TR/wsdl
[10]
UDDI Homepage von OASIS:
http://www.uddi.org/
[11]
HTTP Homepage des W3C:
http://www.w3.org/Protocols/
[12]
HTTPS Request for Common der Internet Engineering Task
Force:
http://www.ietf.org/rfc/rfc2818.txt
[13]
Firewalls - Internet Intern
M. Fordermaier, A. Stolz, erschienen bei Data Becker, 1. Auflage
2001
47
[14]
SOAP Submission Request to W3C:
http://www.w3.org/Submission/2000/05/
[15]
SSL/TLS Strong Encryption - An Introduction by Apache
Software Foundation:
http://httpd.apache.org/docs/2.0/ssl/ssl intro.html
[16]
Timeservice von www.nanonull.com (in Verantwortung von
Altova - www.altova.com):
http://www.nanonull.com/TimeService/TimeService.asmx
[17]
SOAP Submission Request to W3C:
http://www.w3.org/Submission/2001/07/
[18]
Usenet Newsgroup - RFC 1036 des W3C
http://www.w3.org/Protocols/rfc1036/rfc1036.html
[19]
RSS 2.0 Specification - Technology at Harvard Law
http://blogs.law.harvard.edu/tech/rss
[20]
Homepage der Programmiersprache Java (in Verantwortung von
SUN Microsystems - www.sun.com):
http://java.sun.com/
[21]
Homepage der Programmiersprache .Net (in Verantwortung von
Microsoft - www.microsoft.com):
http://www.microsoft.com/net/default.mspx
[22]
JavaServer Pages und Servlets - Internet Intern
M. Brantner, S. Schmidt, B. Wabnitz, D. Wabnitz, erschienen bei
Data Becker, 1. Auflage 2001
[23]
Java Servlet Homepage (in Verantwortung von SUN Microsystems - www.sun.com):
http://java.sun.com/products/servlet/
48
[24]
Homepage der Entwicklungsumgebung NetBeans:
http://www.netbeans.org
[25]
SUN Public License:
http://www.opensource.org/licenses/sunpublic.php
[26]
Homepage des Apache2 Webserver (in Verantwortung von [27]):
http://httpd.apache.org/
[27]
Homepage der Apache Software Foundation:
http://www.apache.org
[28]
Homepage von Tomcat (in Verantwortung von [27]):
http://tomcat.apache.org
49
Index
.NET, 15
RSS, 44
Abstract, 1
Apache Tomcat, 20
Apache2 Webserver, 20
API, 42
Server, 44
Servlet, 4, 17, 44
Servlet Exception, 19
Servlet Lebenszyklus, 18
Servlet-Container, 18
SOAP, 7, 44
SOAP-Body, 8
SOAP-Envelope, 7
SOAP-Header, 7
SPL, 20, 44
SSL, 10, 44
SUN, 20
SUN Microsystems, 18
Browser, 42
Cache, 15
Client, 42
CORBA, 5, 42
Firewall, 6, 42
Google, 3, 42
Google Web API, 4
Google Web Service, 14
Tomcat, 20
UDDI, 12, 44
HTML, 3, 42
HTTP, 6, 42
HTTP Exkurs, 39
HTTPS, 6, 43
Hyperlink, 43
Hypertext, 43
W3C, 5, 45, 46
Web Service, 45
Web Services, 5
Webserver, 20
WSDL, 10, 45
WWW, 3, 45, 46
Internetadressen, 46
XML, 45
Java, 15, 43
Java Runtime Environment, 20
JRE, 20, 43
MIME, 39
Namensdienst, 43
NetBeans, 20
Netzanwendungen, 43
Protokollstack, 5
Prozess, 44
Rechner, 43
Ressource, 43
RFC, 43
RPC, 5, 44
50
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Protokollstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schema eines Web Service Aufrufes . . . . . . . . . . . . . . . . . . . . . .
Aufbau einer SOAP-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau eines WSDL-Dokumentes . . . . . . . . . . . . . . . . . . . . . . .
Aufbau eines UDDI-Eintrags . . . . . . . . . . . . . . . . . . . . . . . . .
Ausschnitt einer Google-Suche nach eingehenden Links für http://www.unijena.de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typische Servlet-Konstellation . . . . . . . . . . . . . . . . . . . . . . . .
Servlet Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Array vom Typ SearchValueType . . . . . . . . . . . . . . . . . . . . . .
Beispiel für ein einzelnes Suchergebnis . . . . . . . . . . . . . . . . . . . .
Die Startseite index.html . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ergebinsseite für die Suche nach uni-jena . . . . . . . . . . . . . . . . . .
Ausgehende Links für http://www.uni-jena.de . . . . . . . . . . . . . .
Eingehende Links für http://www.uni-jena.de . . . . . . . . . . . . . .
Bildvorschau mittels JavaScript . . . . . . . . . . . . . . . . . . . . . . . .
Mögliche grafische Darstellung der Linkstruktur . . . . . . . . . . . . . . .
51
6
7
7
11
13
16
17
18
24
24
27
28
30
31
33
35