Semi-automatische Generierung von REST

Transcription

Gottfried Wilhelm
Leibniz Universität Hannover
Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Software Engineering
Semi-automatische Generierung von
REST-Services aus Webseiten
Masterarbeit
im Studiengang Informatik
von
Alexander Fomin
Prüfer: Prof. Dr. Kurt Schneider
Zweitprüfer: Prof. Dr. Matthew Smith
Betreuer: M. Sc. Leif Singer
Hannover, 14. April 2010
Danksagung
An dieser Stelle möchte ich mich bei all denen bedanken, die mich bei der Entstehung
dieser Arbeit unterstützt haben.
Ein besonderer Dank geht an Herrn M. Sc. Leif Singer für eine hervorragende Betreuung
während dieser Arbeit.
Zusammenfassung
Viele Webseiten enthalten wertvolle Informationen, stellen jedoch keine maschinenlesbaren Schnittstellen zur Verfügung. Meist müssen die Daten über Formulare angefragt und
ggf. auf mehreren Webseiten einer Website gesammelt werden. Oft besteht aber Bedarf,
Informationen ohne mühsame Aufbereitung durch Benutzer in strukturierter Form zu
erhalten, um sie in anderen Anwendungen verwenden zu können.
Eine Abhilfe schaffen sogenannte Web-Scraper – Programme zur Datenextraktion aus
Webseiten. Diese müssen jedoch programmiert werden, was zusätzliche Zeit und technische Kenntnisse erfordert. Es gibt Werkzeuge auf dem Markt, die es auch Benutzern ohne
Programmierkenntnisse ermöglichen, Daten aus Webseiten zu extrahieren. Sie beschränken sich jedoch entweder auf eine oder mehrere Webseiten, die gleichstrukturierte Informationen – beispielsweise über viele Webseiten aufgeteilte Suchergebnisse einer Anfrage
– enthalten. Allerdings befinden sich Informationen über ein Objekt (z. B. eine Publikation) häufig auf mehreren Webseiten (Zusammenfassung, Informationen über Autoren,
verwandte Publikationen etc.). Außerdem gibt es Objekte (z. B. Autoren und Publikationen) auf einer Webseite, die miteinander in Beziehung stehen. Momentan verfügbare
Werkzeuge können derartige Informationen und deren Beziehungen nicht extrahieren.
Die vorliegende Arbeit adressiert diese Probleme. Hier werden ein Konzept und ein
Werkzeug namens DisRESTractor vorgestellt. Mit dessen Hilfe kann ein Benutzer ohne technische Kenntnisse einen Web-Scraper erzeugen, indem er die für ihn relevanten
Daten im Dialog mit dem System visuell definiert. Dabei werden die Informationen
als Ressourcen extrahiert, die über mehrere Webseiten verteilt sein und in Beziehung
miteinander stehen können. Der erzeugte Web-Scraper ist dabei nach Prinzipien des
Architekturstils REST aufgebaut.
Inhaltsverzeichnis
1. Einleitung
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Grundlagen
2.1. Struktur von Webseiten . . . . . . . . . .
2.2. Web-Services . . . . . . . . . . . . . . . .
2.3. Mashups . . . . . . . . . . . . . . . . . . .
2.4. REST . . . . . . . . . . . . . . . . . . . .
2.4.1. Grundprinzipien . . . . . . . . . .
2.4.2. Ressourcen . . . . . . . . . . . . .
2.4.3. Unterschiedliche Repräsentationen
2.4.4. Verknüpfungen/Hypermedia . . . .
2.4.5. Standardmethoden . . . . . . . . .
2.4.6. Zustandslosigkeit . . . . . . . . . .
2.4.7. Service-Dokumentation . . . . . .
2.5. Web-Scraping . . . . . . . . . . . . . . . .
1
1
2
2
.
.
.
.
.
.
.
.
.
.
.
.
4
4
7
8
10
10
11
12
14
14
16
16
17
3. Abgrenzung zu anderen Arbeiten
3.1. Wissenschaftliche Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Kommerzielle Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
20
21
4. Das Konzept von DisRESTractor
4.1. Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Beschreibung des Szenarios und Motivation . . . . . . . . . . . .
4.1.2. Aufruf und Benutzeroberfläche von DisRESTractor . . . . . . . .
4.1.3. Auswahl relevanter Informationen und Hinzufügen einer Ressource
4.1.4. Erfassung von Beziehungen zwischen Ressourcen . . . . . . . . .
4.1.5. Navigation auf der Website . . . . . . . . . . . . . . . . . . . . .
4.1.6. Hinzufügen eines mehrwertigen Attributes . . . . . . . . . . . . .
4.1.7. Erzeugen eines Service . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Beschreibung des Konzeptes . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1. Metamodell für extrahierte Daten . . . . . . . . . . . . . . . . . .
4.2.2. Ablauf der Datenextraktion mit DisRESTractor . . . . . . . . . .
4.2.3. Generierter Service . . . . . . . . . . . . . . . . . . . . . . . . . .
26
26
26
27
28
30
31
32
32
34
34
36
41
5. Evaluation des Konzeptes
5.1. Planung und Durchführung von Interviews . . . . . . . . . . . . . . . . .
44
44
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
5.2. Auswertung von Ergebnissen . . . . . . . . . . . . . . . . . . . . . . . .
6. Entwurf und Implementierung
6.1. Technische Plattform . . . . . . . . . . . . . . . . . . . . .
6.2. Architektur von DisRESTractor . . . . . . . . . . . . . . .
6.3. Same origin policy . . . . . . . . . . . . . . . . . . . . . .
6.4. Dialog mit DisRESTractor zur Definition von Ressourcen
6.5. Generierung und Installation des Service . . . . . . . . . .
6.6. Architektur des Service . . . . . . . . . . . . . . . . . . . .
45
.
.
.
.
.
.
47
47
48
49
50
54
54
7. Zusammenfassung und Ausblick
7.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
59
A. Anhang
A.1. Ant-Skript zur Generierung und Installation des Service . . . . . . . . .
A.2. WADL-Dokumentation zum generierten Service . . . . . . . . . . . . . .
61
61
62
Abkürzungsverzeichnis
63
Literaturverzeichnis
67
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1. Einleitung
1.1. Motivation
Viele Webseiten und -anwendungen enthalten dynamische Inhalte mit wertvollen Informationen, stellen jedoch keine maschinenlesbaren Services, sondern nur Anfrageformulare und Suchmasken zur Verfügung, die zur Bedienung durch menschliche Benutzer gedacht sind. In Unternehmen besteht aber Bedarf, relevante Informationen aus
Web-Shops, Börsen-, Nachrichten- und anderen Webportalen abzufragen und diese ohne Suche und Aufbereitung durch Mitarbeiter in strukturierter Form automatisiert zu
erhalten. Dafür soll die Extraktion der Daten in einem Web-Service gekapselt werden.
Anwendungsgebiete sind beispielsweise die Lieferantenbewertung und das Preismonitoring. Eine semi-automatische Erstellung eines solchen Service könnte wie folgt aussehen.
Ein Benutzer geht auf die Webseite eines Online-Shops und sucht nach einem oder mehreren Produkten. Durch eine Markierung der Suchergebnisse teilt er dem Programm
mit, welche Teile der Seite für ihn interessant sind. Durch geschicktes Nachfragen findet das Programm heraus, welche Informationen (im Folgenden Ressourcen genannt)
der potentielle Service verwalten soll. So könnte die Markierung einer Tabellenzeile –
eines Suchergebnisses – auf die ganze Ergebnismenge hinweisen. Mit Hilfe des erstellten
Service kann der Benutzer nächstes Mal aktuelle Preise erhalten, ohne die Webseite des
Online-Shops aufrufen, die Suchanfrage in die Maske eingeben und weitere Webseiten
für jedes Ergebnis besuchen zu müssen.
Es gibt bereits Werkzeuge, die es den Benutzern ohne Programmierkenntnisse ermöglichen, gewünschte Daten aus einer Webseite in viele Ausgabeformate wie XML1 , RSS2
oder HTML3 zu übertragen. Diese Werkzeuge beschränken sich jedoch entweder auf eine
oder mehrere Webseiten, die gleichstrukturierte Informationen – beispielsweise per Paginierungsmechanismus 4 aufgeteilte Suchergebnisse – enthalten. Die Informationen über
eine Ressource sind aber oft über die ganze Website5 verteilt. So zeigen beispielsweise Suchergebnisse meistens nur eine kurze Zusammenfassung einer Ressource an, deren
detailliertere Beschreibung sich auf anderen Webseiten befinden kann. Andererseits können mehrere relevante Ressourcen vorhanden sein, die miteinander in Beziehung stehen.
Derartige Ressourcen und ihre Beziehungen lassen sich aber mit der zurzeit verfügbaren
Software nicht extrahieren.
1
XML steht für Extensible Markup Language.
RSS steht für Really Simple Syndication (Version 2.0).
3
HTML steht für Hypertext Markup Language.
4
Paginierung ist die Aufteilung von umfangreichen Inhalten auf mehrere gleichstrukturierte (nummerierte) Webseiten.
5
Unter einer Website wird hier die Menge aller Webseiten verstanden, die dieselbe Domain (z. B.
example.org) haben.
2
1
1. Einleitung
Für die technische Realisierung der Informationsextraktion stehen verschiedene Möglichkeiten zur Verfügung. Der Extraktionsprozess kann in einer eigenständigen Anwendung
durchgeführt oder in einem Web-Service gekapselt werden. Es gibt wiederum mehrere Möglichkeiten, Web-Services zu entwickeln. In dieser Arbeit wird der Ansatz der
REST-konformen Web-Services verfolgt. Representational State Transfer (REST) ist ein
Softwarearchitekturstil für verteilte Informationssysteme und zeichnet sich durch seine
Einfachheit und die Verwendung von reifen Standards wie HTTP und URI6 aus, die bereits
seit Jahren verfügbar sind.
1.2. Aufgabenstellung
Im Rahmen dieser Arbeit soll ein Konzept entwickelt werden, das einen Benutzer ohne Programmierkenntnisse befähigt, einen REST-konformen Web-Service im Dialog mit
dem System visuell zu erstellen. Dieser Web-Service soll die Extraktion der über mehrere Webseiten verteilten Daten und ggf. deren Beziehungen ermöglichen. Das Konzept
soll in Form einer Webanwendung prototypisch implementiert werden. Dabei sollen die
Daten zuerst auf ein abstraktes Modell abgebildet werden, damit die Zielplattform –
z. B. JAX-RS7 – leicht geändert werden kann. Dies entspricht einer Trennung der semiautomatisch erhobenen Anforderungen an den Service von seiner konkreten Implementierung. Die implementierte Anwendung wird im Folgenden mit DisRESTractor8 bezeichnet.
1.3. Gliederung
Kapitel 1 beinhaltet die Problemstellung und Zielsetzung dieser Arbeit.
In Kapitel 2 werden grundlegende Begriffe definiert. Weiterhin wird die Struktur von
Webseiten beschrieben. Ebenso wird der Architekturstil REST präsentiert. REST- und
SOAP-basierte Web-Services werden verglichen.
Kapitel 3 gibt einen Überblick über verwandte wissenschaftliche Arbeiten und stellt die
auf dem Markt verfügbare Software zur Extraktion von Daten vor.
In Kapitel 4 wird das in dieser Arbeit entwickelte Konzept von DisRESTractor präsentiert. Zuerst wird es anhand eines Anwendungsszenarios exemplarisch vorgestellt.
Danach werden ein Modell für extrahierte Daten und das entsprechende Metamodell erläutert. Dann wird der Dialog mit dem Benutzer in DisRESTractor erklärt. Schließlich
werden generierte Services beschrieben.
Vor der Implementierung wurden Interviews mit potentiellen Benutzern von DisRESTractor durchgeführt, um die Eignung und Bedienbarkeit des Konzeptes für Benutzer
6
URI steht für Uniform Resource Identifier.
JAX-RS ist eine Spezifikation von Java-Programmierschnittstellen für die Entwicklung von WebServices entsprechend dem Architekturstil REST.
8
DisRESTractor steht für Distributed Resources Extractor.
7
2
1. Einleitung
ohne Programmierkenntnisse anhand von Mockups 9 in Form von statischen Webseiten
zu testen und erhaltene Verbesserungsvorschläge in die Implementierung einzubeziehen.
In Kapitel 5 werden diese Interviews zur Evaluation des Konzeptes vorgestellt.
Kapitel 6 beinhaltet den Entwurf und die Implementierung der Webanwendung DisRESTractor, die das in Kapitel 4 beschriebene Konzept prototypisch umsetzt, also die
Daten in ein Modell abbildet und schließlich einen fertigen Web-Service generiert. Dabei
wird zuerst die technische Plattform für die Entwicklung von DisRESTractor und die
Generierung von Services beschrieben. Dann wird die Architektur von DisRESTractor
vorgestellt. Nach der Beschreibung des Ablaufs bei der Arbeit mit DisRESTractor wird
die Architektur von generierten Services präsentiert.
Kapitel 7 fasst die vorliegende Arbeit zusammen und gibt einen Ausblick über die Möglichkeiten, das Konzept und die Implementierung einzusetzen und weiterzuentwickeln.
9
Ein Mockup ist ein Prototyp der Benutzeroberfläche einer zu entwickelnden Software ohne weitere
Funktionalität.
3
2. Grundlagen
Das Internet stellt große Mengen von Informationen zur Verfügung, die (meist unstrukturiert) durch HTML-Seiten repräsentiert werden. Dabei ist der Zugriff von Menschen über
Webbrowser gedacht. Web-Services sollen den verteilten Anwendungen die Kommunikation ohne Browser ermöglichen, um gewünschte Daten automatisiert zu bekommen oder
bestimmte Aktionen auf entfernten Rechnern durchzuführen. Wenn Webseitenbetreiber
keine Web-Services anbieten, wird versucht, relevante Informationen durch sogenanntes
Web-Scraping zu extrahieren.
Dieses Kapitel vermittelt Grundlagen für das Verständnis von Web-Scraping und stellt
den Architekturstil REST vor. Am Ende wird Web-Scraping definiert, und oft verwendete
Extraktionstechniken werden beschrieben.
2.1. Struktur von Webseiten
Webseiten sind HTML-Dokumente im World Wide Web (WWW), die in einem Webbrowser
unter Angabe eines URL (s. Abschnitt 2.4.2) abrufbar sind. Hypertext Markup Language
(kurz HTML) ist eine Auszeichnungssprache zur Beschreibung der Struktur von Webseiten. HTML ist in [RHJ99] spezifiziert und wird von W3C 1 weiterentwickelt.
In Listing 2.2 ist die allgemeine Struktur eines HTML-Dokumentes dargestellt.
1
2
3
4
5
6
7
8
9
10
11
<!DOCTYPE HTML PUBLIC "−//W3C//DTD␣HTML␣4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Titel der Webseite</title>
<!−− Evtl. weitere Kopfinformationen −−>
</head>
<body>
Inhalt der Webseite
</body>
</html>
Listing 2.1: Struktur eines HTML-Dokumentes
Mit Hilfe von sogenannten Tags wie title, body etc. werden einzelne Teile einer Webseite beschrieben. Die erste Zeile im Listing definiert einen Dokumenttyp, der die Syntaxregeln für dieses Dokument festlegt.
1
Das World Wide Web Consortium (W3C) ist das Gremium zur Standardisierung der Technologien
für das World Wide Web.
4
2. Grundlagen
Wie man im Listing sieht, haben Webseiten eine baumartige Struktur (s. Abbildung
2.1). Um auf alle Elemente dieser Struktur zugreifen zu können, wurde von W3C das
Document Object Model (kurz DOM) spezifiziert. Das ist eine Schnittstelle, die eine Navigation im Baum und Manipulationen mit Knoten ermöglicht. DOM wird insbesondere
dafür verwendet, um eine Webseite während der Anzeige im Browser mit Hilfe einer
Skript-Sprache wie JavaScript dynamisch zu verändern.
html
head
title
body
...
...
...
Abbildung 2.1.: Baumstruktur eines HTML-Dokumentes
Für die Formatierung von Webseiten werden Cascading Style Sheets (CSS) verwendet.
Mit CSS kann man festlegen, wie der Inhalt innerhalb eines Tags dargestellt werden soll.
CSS können unter anderem in einer separaten Datei abgelegt und in HTML eingebunden
werden. Dies dient einer besseren Trennung des Inhalts von der optischen Gestaltung.
Aufgrund einer großen Verbreitung von XML wurde eine weitere Auszeichnungssprache XHTML spezifiziert, die sich von HTML derart unterscheidet, dass der Quellcode von
Webseiten Syntaxregeln von XML erfüllt. Dies ist für die vorliegende Arbeit von großer
Bedeutung, da es zahlreiche Techniken und Werkzeuge gibt, die es ermöglichen, XMLDokumente zu verarbeiten.
Heutzutage werden viele Webseiten nicht mehr von Menschen in HTML manuell verfasst,
sondern automatisch generiert. Dabei werden Teile des Dokumentes durch den Quellcode
einer Programmiersprache ersetzt, der die Inhalte beispielsweise aus einer Datenbank
lädt und als HTML ausgibt. Auf diese Weise sind z. B. die meisten Online-Shops aufgebaut,
deren Produktlisten dynamisch geladen werden. Dadurch ändern sich die Inhalte von
Webseiten, die Struktur bleibt jedoch immer gleich. Dies ist eine wichtige Voraussetzung
für eine erfolgreiche Informationsextraktion.
Immer häufiger wird Asynchronous JavaScript and XML (kurz AJAX) für asynchrone
Datenübertragung zwischen einem Webbrowser und einem Server eingesetzt. Per AJAX
kann ein Client eine Anfrage an den Server senden und anhand der erhaltenen Daten
bestimmte Teile der Webseite ändern, ohne die Webseite komplett neu zu laden. Das
verringert die Wartezeiten des Clients und ermöglicht es, Benutzerinteraktionen dynamischer zu gestalten.
5
2. Grundlagen
AJAX wird beispielsweise in der Suchmaschine von Google 2 (s. Abbildung 2.2) verwendet.
Bei der Eingabe der ersten Zeichen eines Suchbegriffes in das entsprechende Eingabefeld
erscheint eine Liste mit möglichen Suchbegriffen. Diese Liste wird beim Eingeben oder
Entfernen jedes Zeichens angepasst. Auf der technischen Ebene wird bei jeder Änderung
im Eingabefeld eine Anfrage mit dem eingegebenen Teilwort an den Server gesendet.
Daraufhin sendet der Server eine Liste mit Vorschlägen an den Client zurück, und der
Client bindet sie per JavaScript in die Webseite ein.
Abbildung 2.2.: AJAX am Beispiel von Google
AJAX-Anfragen werden per JavaScript abgesetzt. Momentan gibt es viele JavaScriptFrameworks wie jQuery 3 oder Dojo Toolkit 4 , die die Arbeit mit AJAX erleichtern.
Wenn Informationen auf der Webseite per AJAX nachgeladen werden, bleibt der URL5 der
Webseite gleich. Dies hat zur Folge, dass diese Informationen nicht wieder erscheinen,
wenn dieselbe Webseite über ein Lesezeichen oder den Zurück-Button im Webbrowser
aufgerufen wird.
Eine nützliche Möglichkeit, die momentan fast alle Webbrowser zur Verfügung stellen,
ist die Ausführung von JavaScript in der aktuellen Webseite über eine besondere Art
von Lesezeichen – so genannte Bookmarklets. Das folgende Bookmarklet ändert z. B. die
Hintergrundfarbe der aktuell geöffneten Webseite:
javascript:document.body.style.backgroundColor="green"
Im Rahmen dieser Arbeit werden Bookmarklets für das Starten von DisRESTractor
verwendet. Dies wird in Kapiteln 4 und 6 beschrieben.
2
http://www.google.de/
http://jquery.com/
4
http://dojotoolkit.org/
5
Ein Uniform Resource Locator (URL) gibt an, wo eine Webseite im Netz zu finden ist und über welches
Datenübertragungsprotokoll sie angefordert werden kann.
3
6
2. Grundlagen
2.2. Web-Services
Die Extraktion von Daten wird im Rahmen der vorliegenden Arbeit in einem RESTbasierten Web-Service gekapselt. Bevor der Architekturstil REST vorgestellt wird, werden
Web-Services zuerst allgemein definiert. Dann wird ein sehr verbreiteter Ansatz bei der
Entwicklung von Web-Services kurz beschrieben, und sein Unterschied zu REST wird
erklärt.
Definition 2.1 (Service nach [Lüb08]) Ein Dienst (Service) ist eine im Netzwerk
verfügbare, lose gekoppelte Softwarekomponente, welche wohldefinierte Schnittstellen implementiert und mit standardisierten Protokollen aufgerufen werden kann.
Da die Entwicklung von Web-Services durch service-orientierte Architekturen (SOA)
stark geprägt wurde, werden sie meist mit den folgenden Standards in Verbindung gebracht:
• WSDL (Web Services Description Language) zur Beschreibung der Schnittstellen –
also der Methoden, die ein Web-Service zur Verfügung stellt sowie deren Parameter.
• SOAP (ursprünglich Simple Object Access Protocol) oder XML-RPC (Remote Procedure Call) zur Kommunikation.
• UDDI (Universal Description, Discovery and Integration) als Verzeichnisdienst zur
Registrierung von Web-Services.
Alle drei Standards basieren auf XML – einer Sprache, die plattform- und technologieunabhängig ist. Das ist sehr wichtig, da Interoperabilität das Grundprinzip bei der
Entwicklung von Web-Services ist.
Das W3C bietet mehrere Definitionen von Web-Services an. Eine davon ist:
Definition 2.2 (Web-Service nach [HB04]) 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 SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction
with other Web-related standards.
Das geplante Haupteinsatzgebiet von Web-Services liegt im Bereich von Geschäftsprozessen. Dabei werden zwei Ziele verfolgt. Einerseits kann man häufig verwendete Geschäftsfunktionen (z. B. Währungsumrechnungen) in neuen Web-Services kapseln, um
diese in verschiedenen Anwendungen wiederverwenden zu können. Andererseits können
Geschäftsfunktionen aus vorhandenen Web-Services (z. B. mit Hilfe von BPEL6 ) in einem
größeren Geschäftsprozess zusammengestellt werden.
6
BPEL (Business Process Execution Language) ist eine Modellierungssprache für Geschäftsprozesse.
7
2. Grundlagen
Auf den Ansatz der Generierung von prozess-orientierten Web-Services auf Basis von
SOAP, WSDL und UDDI wird in dieser Arbeit nicht näher eingegangen. Weiterführende Informationen zur Generierung von Web-Services im SOAP-Stil liefert [LHVL05]. Die vorliegende Arbeit beschäftigt sich mit Web-Services auf Basis von REST, da REST leichtgewichtig und ressourcen-orientiert ist und somit zum Konzept dieser Arbeit besser passt.
Der Architekturstil REST wird in Abschnitt 2.4 vorgestellt und detailliert beschrieben.
2.3. Mashups
Im Rahmen von Web 2.0 stellen immer mehr Internet-Portale keine Web-Services auf
Basis von SOAP und WSDL zur Verfügung, sondern bieten sogenannte Web-APIs (auch
Web-Service-APIs genannt) an, die häufig REST-basiert sind. Eine API (Application
Programming Interface) ist eine Programmierschnittstelle, die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird.
Über Web-APIs wird eine maschinelle Verwendung von Ressourcen und Funktionen eines Webportals ermöglicht. In der Dokumentation von Web-APIs wird die Struktur
von HTTP-Anfrage-Nachrichten sowie von zugehörigen Antwort-Nachrichten definiert,
die nicht zwingend im XML-Format übertragen werden, sondern z. B. JavaScript Object
Notation (s. Abschnitt 2.4.3) verwenden können.
Die folgenden bekannten Webseitenbetreiber bieten offene Schnittstellen für ihre Ressourcen und Dienste an:
Google 7 stellt für seine Websuche nach Webseiten, Bildern, Büchern, Nachrichten etc.
die Google AJAX Search API 8 zur Verfügung. Außerdem erlaubt Google die
Verwendung seiner digitalen Karten über die Google Maps API 9 .
Yahoo 10 ermöglicht wie Google die Verwendung seiner Dienste wie Suche nach Webseiten, Personen und Telefonnummern etc.
Amazon erlaubt über seine Amazon Web services 11 die Suche nach Produkten und
bietet unter anderem Speicher- und Bezahlungsdienste an.
Flickr 12 ermöglicht die Suche nach und Verwaltung von Bildern über die API auf
seinem Fotoportal.
Web-APIs werden in einer neuen Art von webbasierten Anwendungen – sogenannten
Mashups eingesetzt.
Definition 2.3 (Mashup) Als Mashups werden Webanwendungen bezeichnet, die auf
der Kombination von bestehenden Inhalten aus verschiedenen Quellen basieren.
Als Beispiel für einen Mashup dient die in Abbildung 2.3 dargestellte Webseite Houston Crime Maps 13 . Dieser Mashup stellt in einer Karte dar, an welchen Orten der
8
http://code.google.com/apis/ajaxsearch/
http://www.google.com/apis/maps/
11
http://aws.amazon.com
13
http://houstoncrimemaps.com
9
8
2. Grundlagen
US-amerikanischen Stadt Houston vor kurzer Zeit Verbrechen begangen wurden. Dafür
verwendet er das Kartenmaterial von Google – Google Maps API – und die Meldungen
der Polizei Houstons14 . Die Webseite http://www.programmableweb.com/ gibt einen
großen Überblick über die im Netz verfügbaren Web-APIs und Mashups. Derzeit werden dort 1886 APIs und 4743 Mashups15 gelistet.
Abbildung 2.3.: Die Webseite von Houston Crime Maps
Mashups müssen nicht zwangsläufig direkt in einem Webbrowser laufen. Google Earth 16
stellt einen Mashup als eine eigenständige Anwendung dar, in der digitale Karten mit
externen Quellen – z. B. geokodierten Fotos oder Wikipedia17 -Einträgen – kombiniert
werden.
Obwohl viele Mashups in Unterhaltungsportalen eingesetzt werden, gewinnen sie auch
in Unternehmen immer mehr an Bedeutung. So machen sich Immobilienanbieter digitale
Karten zu Nutze, um ihre Objekte anzuzeigen. Produktkataloge verschiedener Anbieter
werden kombiniert, um beste Angebote zu finden.
Für die Erstellung von Mashups gibt es zurzeit zahlreiche Werkzeuge – sogenannte
Mashup-Editoren, die auch für Benutzer ohne Programmierkenntnisse zugeschnitten
14
http://www.houstontx.gov/police/cs/stats2.htm
Stand: 14.04.2010
16
http://earth.google.com/intl/de/
17
http://de.wikipedia.org/
15
9
2. Grundlagen
sind. Yahoo! Pipes 18 ermöglicht es, Inhalte aus verschiedenen Quellen über die grafische
Benutzeroberfläche zu kombinieren, diverse Filter anzuwenden und ein Ausgabeformat
zu bestimmen.
Mashups kommen oft in sogenannten situationsbezogenen Anwendungen (engl. situational Applications) zum Einsatz, die dafür erstellt werden, um ein dringendes, spezielles
Geschäftsproblem zu lösen. Sie werden häufig von kleinen Benutzergruppen und für eine
kurze Zeit verwendet, z. B. für die Überwachung von Angeboten eines bestimmten Produktes. Der Erstellungsprozess solcher Anwendungen wird oftmals von den Benutzern
selbst durchgeführt und ist im Vergleich zum klassischen Softwareentwicklungsprozess
viel schneller.
Eine gute Übersicht von Mashup-Technologien in Unternehmen gibt [Ger08]. Detailliertere Informationen liefern [CCHZ08], [Hoc08] und [TSK08].
2.4. REST
In Abschnitt 2.2 wurden Web-Services im SOAP-Stil vorgestellt, der Prozesse in den
Mittelpunkt stellt. In diesem Abschnitt wird ein anderer Ansatz bei der Entwicklung
von Web-Services beschrieben, nämlich Representational State Transfer (REST).
REST ist ein Architekturstil, der zum ersten Mal im Jahr 2000 in der Dissertation von Roy
Thomas Fielding ([Fie00]) vorgestellt wurde. HTTP19 funktioniert nach REST-Prinzipien
und das WWW auch. Das zentrale Konzept von REST sind Ressourcen, die durch URIs
eindeutig identifizierbar sind und eine oder mehrere Repräsentationen haben.
2.4.1. Grundprinzipien
Die Grundprinzipien von REST sind:
• Ressourcen mit eindeutiger Identifikation (Adressierbarkeit),
• Verknüpfungen/Hypermedia,
• Standardmethoden,
• Unterschiedliche Repräsentationen,
• Zustandslose Kommunikation.
Die folgenden Abschnitte gehen auf die einzelnen Prinzipien detailliert ein.
18
19
http://pipes.yahoo.com/
HTTP (Hypertext Transfer Protocol ) ist ein Protokoll zur Übertragung von Daten – insbesondere von
Webseiten im World Wide Web – über ein Netzwerk und wird in [FGM+ 99] spezifiziert.
10
2. Grundlagen
2.4.2. Ressourcen
Das W3C definiert das WWW folgendermaßen:
Definition 2.4 (World Wide Web nach [JW04]) The World Wide Web (WWW,
or simply Web) is an information space in which the items of interest, referred to as
resources, are identified by global identifiers called Uniform Resource Identifiers (URI).
Im Mittelpunkt stehen also adressierbare Ressourcen. Beispiele für Ressourcen sind
HTML-Dokumente, Bilder, Videos, temporäre Dienste wie z. B. die Wettervorhersage etc.
Eine Ressource muss aber nicht immer individuell sein und kann auch eine Menge von
Elementen – z. B. eine Liste von Produkten – repräsentieren.
Das ursprüngliche Ziel des WWW war es, Informationen (Ressourcen) auf eine einfache Art
auszutauschen und Verbindungen dazwischen zu erstellen. Dafür müssen die Ressourcen
adressierbar sein. Das wird durch URI s erreicht - ein einheitliches Konzept für die
Vergabe von eindeutigen Schlüsseln. URIs bilden einen globalen Namensraum und stellen
sicher, dass Ressourcen weltweit eindeutig identifiziert werden können. Das Beispiel für
einen URI, der die Eingangsseite einer Website adressiert, ist:
http://example.org/index.html
URIs bringen auch zusätzliche Vorteile mit sich. So können Ressourcen auf Webseiten
verlinkt, als Lesezeichen per E-Mail verschickt oder im Cache eines Webbrowsers gespeichert werden.
Obwohl es keine zwingende Forderung von REST und W3C gibt, ist es sinnvoll URIs
beschreibend zu benennen, so dass eine Ressource und ihr URI intuitiv zusammenpassen.
Hier sind einige Beispiele für sinnvoll benannte URIs:
• http://example.org/products/123: ein Produkt mit der ID 123
• http://example.org/software/xyz/releases/1.2.3.zip: die Version 1.2.3 eines Softwaresystems xyz
• ftp://example.org/aDirectory/aFile.pdf: die im Verzeichnis aDirectory abgelegte Datei aFile.pdf
• http://example.org/products: die Menge aller Produkte
• http://example.org/software/xyz/releases/: die Menge aller Versionen
• ftp://example.org/aDirectory: die Menge aller Dateien im Verzeichnis aDirectory
Jede Ressource muss also mindestens einen URI besitzen. Es ist aber erlaubt, mehrere
URIs – so genannte URI aliases – einer Ressource zuzuweisen.
Ein URI ist entweder ein URL (Uniform Resource Locator) oder ein URN (Uniform Resource Name). Ein URL lokalisiert eine Ressource über den Domainnamen (z. B: example.org)
und gibt über das Netzwerkprotokoll (z. B. HTTP oder FTP) an, wie auf die Ressource zugegriffen werden kann. Ein URL kann sich ändern, wenn die Ressource auf einen anderen
11
2. Grundlagen
Server verschoben wird. Im Gegensatz dazu ist ein URN unabhängig vom Server und Protokoll und soll die Ressource auch dann identifizieren, wenn sie nicht auf einem Server
erreichbar ist. Der folgende URN identifiziert die Spezifikation von HTTP ([FGM+ 99]):
urn:ietf:rfc:2616
Ein entsprechender URL derselben Ressource lautet20 :
http://www.ietf.org/rfc/rfc2616.txt
2.4.3. Unterschiedliche Repräsentationen
Repräsentationen sind Darstellungen einer Ressource in einem definierten Format. Eine
Ressource kann mehrere Repräsentationen haben. Für eine Ressource „Person“ könnten
untern anderen eine einfache textuelle Repräsentation, eine HTML-Darstellung und ein
Bild im JPEG-Format existieren.
In HTTP ist bei der Kommunikation zwischen einem Server und einem Client die sogenannte Content Negotiation, also eine Aushandlung von Inhaltsformaten, vorgesehen,
bei der ein bestimmtes Format angefordert werden kann. Dieses Format wird im AcceptFeld der HTTP-Anfrage angegeben. Eine typische HTTP-Anfrage sieht wie folgt aus:
GET /wiki/Http HTTP/1.1
Host: en.wikipedia.org
User-Agent: Mozilla/5.0 ... Firefox/3.5.5 ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
...
In dieser Anfrage fordert der Webbrowser Mozilla Firefox die Ressource /wiki/Http
(einen Wikipedia-Artikel über HTTP) vom Server en.wikipedia.org. Im Accept-Feld
teilt der Webbrowser dem Server über den Parameter q=0.9 mit, dass er die Formate
HTML, XHTML und XML bevorzugt. Andere Formate (*/*) werden auch akzeptiert. Der
Parameter q gibt also an, welche Formate bevorzugt werden. Werte von q liegen zwischen
0 (inakzeptabel) und 1 (am meisten bevorzugt).
Wenn mehrere Formate mit der gleichen Gewichtung (wie in diesem Beispiel) angegeben
werden, bestimmt die Reihenfolge die Priorität einzelner Formate. Der Browser erwartet
also vom Server im Idealfall ein HTML-Dokument (text/html).
Als Antwort wird folgende Nachricht geliefert:
HTTP/1.0 200 OK
Date: Sat, 21 Nov 2009 10:42:36 GMT
Content-Type: text/html; charset=utf-8
...
20
Stand: 14.04.2010
12
2. Grundlagen
Der sogenannte Statuscode 200 OK gibt an, dass die Anfrage erfolgreich bearbeitet wurde. Im Feld Content-Type steht, dass eine HTML-Repräsentation der Ressource geliefert
wurde. Die Zeichenkodierung der Nachricht ist dabei UTF-821 .
Bei der Entwicklung steht oft die Frage, welche Repräsentationen für eine Ressource
angeboten werden. Je allgemeingültiger das Format ist, desto mehr potenzielle Clients
können es verstehen.
Folgende Repräsentationen kommen am häufigsten zum Einsatz:
• XML ist neben (X)HTML am meisten verbreitet, da es eine einfache Definition eines
eigenen Formates ermöglicht.
• (X)HTML hat den Vorteil, dass es von jedem Webbrowser verstanden wird und
diverse Möglichkeit bietet, die Daten zu formatieren. Nachteilig kann aber die
Vermischung von Form und Inhalt angesehen werden. Wegen vieler Tags für die
Formatierung kann HTML die Dokumentgröße erhöhen. Außerdem sagt HTML nichts
über die Semantik der z. B. in div- oder span-Tags, also in allgemeinen Containern
untergebrachten Daten.
• Das CSV-Format (Comma Separated Values) wird häufig eingesetzt, da es sehr
einfach zu benutzen ist und sich gut eignet, tabellarische Daten zu präsentieren.
Es lässt sich in vielen Tabellenkalkulationsprogrammen bearbeiten.
• JSON (JavaScript Object Notation) stammt aus dem JavaScript-Umfeld, wird aber
zurzeit in fast jeder Programmiersprache unterstützt. JSON eignet sich aufgrund
einer kompakten Syntax sehr gut für die Übertragung von Datenstrukturen. Der
Datenvolumen ist dabei geringer als bei XML. Außerdem kann JSON direkt in JavaScript verarbeitet werden, wobei XML geparst werden muss. Deswegen ist JSON
insbesondere im Zusammenhang mit AJAX-Aufrufen22 verbreitet. Im Vergleich zu
XML gibt es in JSON aber keine Möglichkeit, Namensräume zu definieren und ein
Dokument anhand seines Schemas zu validieren.
• RSS und Atom sind XML-Formate für eine einfache und strukturierte Veröffentlichung von Änderungen auf Webseiten. In diesen Formaten werden Nachrichten
präsentiert, die unter anderem ein Veröffentlichungsdatum und eine Kurzbeschreibung enthalten.
• Binäre Formate: Druckformate wie PDF oder PostScript, Bildformate wie JPEG,
GIF oder PNG, Archivformate wie TAR, JAR oder ZIP sowie Audio und Video.
• Microformate dienen zur Speicherung von Kalendereinträgen (hCalendar oder
iCalendar), Adressdaten (hCard) oder Produktbeschreibungen (hProduct).
• Text ohne definierte Sturktur (text/plain) wird manchmal zusätzlich zu anderen
oben genannten Formaten für den Fall angeboten, dass der Client andere Formate
nicht bearbeiten kann.
21
UTF-8 steht für 8-bit Unicode Transformation Format. und ist die am weitesten verbreitete Kodierung
für Unicode-Zeichen.
22
AJAX (Asynchronous JavaScript and XML) ist ein Konzept der asynchronen Datenübertragung
zwischen einem Browser und dem Server.
13
2. Grundlagen
2.4.4. Verknüpfungen/Hypermedia
Hypermedia beruht auf dem Konzept von Verknüpfungen (Links). Diese sind vor allem
aus HTML bekannt und ermöglichen dem Benutzer, im Web zu navigieren oder eingebundene Daten wie PDF-Dokumente zu öffnen. Sie sind aber auch maschinell bearbeitbar.
So folgen Suchmaschinen-Roboter den Links, um weitere Inhalte zu finden.
Es folgt ein Beispiel, wie Links in XML eingebunden werden können:
1
2
3
4
5
6
<order href="http://example.org/customers/1234"<>
<amount>10</amount>
<product ref="http://example.com/products/4554"/>
<customer ref="http://example.org/customers/1234"/>
<link rel="cancel" href="./cancellations"/>
</order>
Listing 2.2: Verknüpfungen in XML
Eine Applikation kann also den Links in product- und customer-Tags folgen, um weitere Informationen zu bekommen. Der Vorteil des Hypermedia-Ansatzes ist es, dass Verknüpfungen anwendungsübergreifend (http://example.com und http://example.org)
sind.
Ein weiterer Vorteil der Verknüpfungen ist die Möglichkeit, den Applikationszustand
zu steuern. Durch Hinzufügen und Entfernen von Links kann der Server dem Client
mitteilen, welche Aktionen als nächstes ausführbar sind. Im obigen Beispiel kann der
Server seinen Zustand ändern, indem er den Tag link (s. Zeile 5) entfernt und somit
keine Stornierung mehr erlaubt. Andererseits kann der Client den Zustand des Servers
ändern, indem er diesem (noch verfügbaren) Link folgt und den Auftrag storniert.
2.4.5. Standardmethoden
In HTTP besitzt jede Ressource eine einheitliche Schnittstelle, indem sie folgende Standardmethoden implementiert:
GET liefert eine Repräsentation einer Ressource.
POST erstellt eine neue Ressource.
PUT verändert eine bestehe Ressource oder erstellt eine neue, falls diese noch
nicht existiert.
DELETE löscht eine Ressource.
HEAD liefert Metadaten einer Ressource.
OPTIONS prüft, welche der obigen fünf Methoden unterstützt werden.
GET ist die am häufigsten verwendete Methode. Das Aufrufen einer Webseite im Browser
oder das Folgen eines Links löst immer eine GET-Operation aus.
GET ist in der HTTP-Spezifikation als sicher („save“) definiert, d. h. bei einem mehrmaligen
Ausführen dieser Methode wird der Zustand des Servers nicht verändert, also als ob die
14
2. Grundlagen
Methode nie ausgeführt worden wäre. Das Gegenteil kann nur dann passieren, wenn die
Methode nicht zweckgemäß – also nicht für das Lesen von Daten – zur Verfügung gestellt
wird. Ein Beispiel dafür ist ein Link zum Löschen einer Ressource. SuchmaschinenRoboter können diesem Link folgen und so die Ressource unabsichtlich löschen. GET ist
also nur zum Abrufen von Ressourcen gedacht. Daher dürfen bei der Entwicklung von
Webanwendungen keine unsicheren Aktionen per GET ansprechbar sein.
Die Methode GET ist außerdem idempotent. Das bedeutet, dass ein mehrmaliges Aufrufen
die gleichen Seiteneffekte bewirkt wie ein einmaliges. Der Ressourcen-Zustand bleibt wie
nach dem ersten Aufrufen.
Aufgrund ihrer Verbreitung wurde die Operation GET optimiert und unterstützt ein
effizientes Caching. Das bedeutet, dass Daten bei einem mehrmaligen Aufrufen gar nicht
gesendet werden müssen, wenn sie seit der letzten Anfrage nicht verändert wurden. Dies
erlaubt das Feld If-Modified-Since des HTTP-Headers, das den Zeitpunkt der letzten
Anfrage enthält. Wenn die Daten nicht verändert wurden, gibt der Server lediglich eine
Nachricht HTTP/1.0 304 Not Modified zurück.
Die Methode POST wird auf zwei Weisen verwendet. Zum einen können damit neue Ressourcen angelegt werden. Zum anderen wird diese Methode benutzt, um eine Aktion
durchzuführen, für die keine der Standardmethoden passt. Dafür ist gerade POST geeignet, da diese Operation weder sicher noch idempotent ist und nicht im Cache gespeichert
wird. So erwartet der Client keine Garantien beim Ausführen dieser Methode.
PUT aktualisiert eine Ressource, falls diese vorhanden ist, oder erzeugt andernfalls eine
neue. Das ist eine idempotente Methode und erzeugt beim mehrfachen Ausführen keine
neuen Instanzen derselben Ressourcen.
Die Operation DELETE ist für das Löschen von Ressourcen vorgesehen. Sie ist idempotent, da eine mehrmals gesendete DELETE-Anfrage nur beim ersten Mal eine Ressource
entfernt. Diese Methode kann auch für logisches Löschen eingesetzt werden, wobei z. B.
eine Bestellung nicht aus der Datenbank entfernt, sondern als storniert markiert wird.
Die Operation HEAD ist eine abgekürzte Variante von GET. Sie liefert lediglich die Metadaten – also den Header einer Ressource – und nicht die komplette Repräsentation.
Dies kann nützlich sein um herauszufinden, ob eine Ressource noch existiert, wann sie
zuletzt geändert wurde oder wie groß sie ist. Laut der HTTP-Spezifikation muss die HEADMethode genau die gleichen Metadaten wie GET liefern. Wie GET ist HEAD sicher und
idempotent.
Die Methode OPTIONS liefert auch Metadaten über eine Ressource, enthält aber ein
zusätzliches Feld Allow. Dieses gibt an, welche Operationen eine Ressource unterstützt.
Der folgende Beispiel-Header bedeutet, dass die Ressource nur lesend ansprechbar ist.
Allow: GET, HEAD
Mit Hilfe der oben beschriebenen Standardmethoden und eines geeigneten Ressourcenmodells lässt sich eine Vielzahl von Anwendungsszenarien umsetzen.
15
2. Grundlagen
2.4.6. Zustandslosigkeit
Nach dem REST-Prinzip muss jede Anfrage völlig unabhängig von den anderen Anfragen
sein. Das heißt, dass ein Client alle relevanten Informationen in der Anfrage an einen
Server übertragen muss, damit diese verstanden werden kann, ohne den Kontext auf
dem Server zu speichern.
Einerseits hat das eine große Bedeutung für die Skalierbarkeit der Anwendung. Andererseits können verschiedene Server nacheinander folgende Anfragen eines Clients bearbeiten. So werden die Verfügbarkeit bei Ausfällen einzelner Server und die Performance
durch eine geschickte Aufteilung der Anfragen an die Server sichergestellt.
2.4.7. Service-Dokumentation
Damit durch einen Service angebotene Ressourcen von Benutzern und Entwicklern verwendet werden können, müssen die Schnittstellen dokumentiert werden. Dafür gibt es
zum einen für Menschen gedachte Beschreibungen im Klartext und zum anderen die
maschinenlesbaren Beschreibungssprachen WSDL und WADL (s. weiter unten).
In [Til09] wird die Möglichkeit betrachtet, keine explizite Dokumentation zur Verfügung
zu stellen. Das kann dadurch begründet werden, dass Ressourcen in HTTP selbstbeschreibend sind. Damit ist Folgendes gemeint. Angenommen, es wird für eine durch einen URI
definierte Ressource die Beschreibung ihrer Schnittstelle gesucht. Als Erstes kann der
Host-Anteil (z. B. http://example.org) der URI extrahiert und eine HTTP-HEAD-Anfrage
an diesen Server gesendet werden. In der Antwort-Nachricht bekommt man viele Metadaten – unter anderen auch den Medientyp, z. B. text/xml. Offiziell registrierte Medientypen werden schon in ihrer Spezifikation beschrieben. Bei XML-Dokumenten kann man
das Schema-Element auslesen und auf diese Weise das Format erhalten. Problematisch
wird es für XML-Dokumente ohne Schemaangaben und für proprietäre Medientypen.
Häufig wird eine API im Klartext – meistens in HTML – beschrieben. In [Til09] wird
empfohlen, die Dokumentation in die HTML-Repräsentation einer Ressource zu packen
und diese ähnlich mit der toString()-Methode in Java immer anzubieten.
Es gibt auch maschinenlesbare Sprachen für die Beschreibung von Schnittstellen. Das
sind WSDL und WADL.
Web Services Description Language (WSDL) ist eine Empfehlung von W3C (s. [BL07])
und wird vor allem für die Beschreibung von Web-Services im SOAP-Stil (s. Abschnitt 2.2)
eingesetzt. WSDL definiert eine Menge von verfügbaren Methoden und deren Parameter.
Diese Tatsache passt nicht zum REST-Konzept, in dem Standardoperationen (GET, PUT
etc.) festgelegt sind. Außerdem lässt WSDL nur XML als Nachrichtenformat zu. In REST
gibt es jedoch keine Einschränkungen bezüglich des Nachrichtenformats. Dennoch wird
in [Man08] gezeigt, dass die Beschreibung eines REST-basierten Service mittels WSDL
(auch wenn nur eingeschränkt) möglich ist.
Web Application Description Language (WADL) ([Had09]) wurde speziell für die Beschreibung von HTTP-basierten Anwendungen – also REST-konformen Web-Services – entwickelt. Das Beispiel einer codeWADL-Dokumentation findet man im Anhang in Abschnitt
A.2.
16
2. Grundlagen
Der Vorteil der maschinenlesbaren Beschreibungssprachen liegt darin, dass mit Hilfe
entsprechender Werkzeuge aus einer Schnittstellenbeschreibung ein Client automatisch
generiert werden kann.
Mehr zu REST gibt es in [Fie00], [RR07], [Til09].
2.5. Web-Scraping
Da nicht alle Webseitenbetreiber offene Schnittstellen für ihre Inhalte anbieten, müssen
Informationen extrahiert und in strukturierte Form gebracht werden.
Definition 2.5 (Web-Scraping, Web-Scraper) Der Prozess der Informationsextraktion aus Webseiten oder anderen Anwendungen wird als Web-Scraping oder ScreenScraping bezeichnet. Entsprechende Software-Werkzeuge werden Screen-Scraper oder
Wrapper genannt.
Im Allgemeinen führt jeder Screen-Scraper die folgenden drei Schritte bei der Informationsextraktion:
1. Herunterladen der Webseite(n) mit relevanten Daten.
2. Extraktion der Daten mit Hilfe einer Extraktionssprache.
3. Ausgabe in einem definierten Format.
Bei der Programmierung von Wrappern wurden früher reguläre Ausdrücke verwendet,
die bestimmte Teile einer Webseite lieferten. Reguläre Ausdrücke können die zu extrahierenden Daten präzise beschreiben, sind aber insbesondere bei einem großen Detailgrad
sehr lang und kaum lesbar. Der folgende reguläre Ausdruck soll alle E-Mail-Adressen
finden:
[a-z0-9!#$%&’*+/=?^_‘{|}~-]+(?:\.[a-z0-9!#$%&’*+/=?^_‘{|}~-]+)*
@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?
Da immer mehr Webseiten XHTML-konform23 sind, werden XML-Parser benutzt, die heutzutage fast für jede Programmiersprache verfügbar sind. Weiterhin gibt es Abfragesprachen für XML wie XPath und XQuery, um Teile eines XML-Dokumentes zu adressieren.
Wenn eine Webseite nicht XHTML- oder sogar nicht HTML-konform ist, können Werkzeuge wie HTMLTidy 24 eingesetzt werden, die Syntax-Fehler von Webseiten korrigieren
und valides (X)HTML liefern. Eine gute Übersicht über die Möglichkeiten, XQuery in der
Programmiersprache Java für die Informationsextraktion einzusetzen, gibt [Goe05].
Einige Web-Scraping-Werkzeuge verwenden eigene Extraktionssprachen. In Abschnitt
3.2 wird eine solche Sprache namens Elog vorgestellt, die im Werkzeug Lixto Visual
Developer 25 benutzt wird.
23
XHTML-Dokumente genügen den Syntaxregeln von XML.
http://tidy.sourceforge.net/
25
http://www.lixto.de/lixto_visual_developer/
24
17
2. Grundlagen
Einerseits bieten gängige Programmiersprachen wie Java, PHP und Perl entsprechende
Funktionalitäten und Bibliotheken an, um Web-Scraper möglichst einfach zu programmieren. Andererseits gibt es Software-Werkzeuge wie Dapper, die für Benutzer ohne
Programmierkenntnisse gedacht sind. Einige davon werden im nächsten Kapitel vorgestellt.
Web-Scraping hat einige Nachteile. Bei jeder Strukturänderung einer Webseite, aus der
Informationen extrahiert werden, muss der entsprechende Screen-Scraper entweder angepasst oder gar neu programmiert werden. Da Inhalte aus Webseiten meist ohne vertragliche Vereinbarung mit dem Daten-Anbieter genutzt werden, können Benutzer solche
Änderungen nicht vermeiden.
In vielen Fällen muss die Benutzung von Inhalten aus urheberrechtlichen Gründen vom
Daten-Anbieter genehmigt werden. Einige Webseitenbetreiber verbieten das automatische Auslesen von Daten auch explizit in den Nutzungsbedingungen. Im Punkt 5.4.3 der
allgemeinen Geschäftsbedingungen des Portals StudiVZ 26 steht untern anderem folgendes:
Untersagt ist insoweit auch der Einsatz von Computerprogrammen zum automatischen
Auslesen von Daten ...
Einige Webseitenbetreiber versuchen, sich mit technischen Mitteln gegen Screen-Scraper
zu wehren. Die erste Möglichkeit besteht darin, dem Benutzer eine Navigationsreihenfolge zu erzwingen, indem Sitzungsparameter im Webbrowser gesetzt und bei der Navigation kontrolliert werden. Damit ist ein direktes Laden einer bestimmten Webseite
nicht möglich. Diese Strategie verwendet beispielsweise eBay 27 .
Eine andere Möglichkeit, Screen-Scraping zu verhindern, ist die Verwendung von CAPTCHA28 – eines Tests, der sicherstellen soll, dass die Webseite von einem Menschen und
nicht von einer Anwendung geöffnet wird. Dabei muss der Benutzer eine Aufgabe lösen, bevor er zur gewünschten Webseite gelangt. Dies kann eine kleine Rechenaufgabe
oder die Erkennung eines Textes in einem verzerrten Bild (s. Abbildung 2.429 ) sein. Als
Gegenmittel werden hierbei Mustererkennungsprogramme verwendet.
Abbildung 2.4.: Ein verzerrtes Bild für CAPTCHA
Oft werden E-Mail-Adressen als eine Maßnahme gegen Spam verschleiert. Dabei stehen
sie nicht direkt im Quellcode einer Webseite, sondern werden per JavaScript geladen.
Solche E-Mail-Adressen können durch Screen-Scraper meist nicht extrahiert werden.
26
http://www.studivz.net
http://www.ebay.de/
28
CAPTCHA steht für Completely Automated Public Turing test to tell Computers and Humans Apart.
29
Dieses Bild stammt aus einem Screenshot der Webseite http://recaptcha.net
27
18
2. Grundlagen
Schließlich präsentieren viele Webseitenbetreiber ihre Inhalte (komplett oder teilweise)
in Flash. Adobe Flash 30 ist eine integrierte Entwicklungsumgebung zur Erstellung multimedialer, interaktiver Inhalte, der so genannten Flash-Filme. Flash bietet viele Möglichkeiten an, Webseiten ansprechend zu gestalten, ermöglicht den Zugriff auf Datenbanken
und Interaktivität ohne weiteres Laden der Webseite. Allerdings können Flash-Inhalte
nicht extrahiert werden.
Diese Aspekte werden in der vorliegenden Arbeit nicht behandelt. Es wird davon ausgegangen, dass sich die Struktur der Webseiten nicht ändert, alle extrahierten Daten
frei verwendet werden dürfen und keine der genannten Abwehrmaßnahmen gegen WebScraping getroffen wird.
30
http://www.adobe.com/de/products/flash/
19
Web-Scraping ist kein neues Gebiet mehr. Daher sind viele Datenextraktion-Techniken
bekannt und entsprechende Tools verfügbar. In diesem Kapitel werden einige davon
vorgestellt. Dabei werden jeweils Unterschiede zur vorliegenden Arbeit erklärt.
3.1. Wissenschaftliche Arbeiten
In [Völ03] wurde ein Werkzeug namens d2c zur Extraktion von XML aus HTML-Seiten im
Rahmen einer Masterarbeit an der Universität Karlsruhe (TH) entwickelt. Mit seiner
Hilfe können Benutzer ohne Programmierkenntnisse Web-Scraper visuell erstellen.
d2c verwendet XSLT1 als Extraktionssprache. Es transformiert die vom Benutzer visuell
definierten Teile einer Webseite in ein XML-Dokument.
Abbildung 3.1 stellt den Ablauf einer Anfrage im Screen-Scraper dar. Die Anfrage wird
nicht direkt an den Server gestellt, sondern dem Modul surf übergeben. Dieses Modul
agiert als Proxy und lädt die Webseite vom Server.
In d2c wird berücksichtigt, dass viele Webseiten nicht HTML-valide sind. Das hat zur Folge, dass die Extraktion von Daten wegen Syntax-Fehlern im HTML-Code gestört werden
kann. Im Modul clean wird ein DOM-Baum (s. Abschnitt 2.1) aufgebaut und validiert.
Alle Syntax-Fehler werden dabei korrigiert.
Das Modul extract wandelt den DOM-Baum mit der gegebenen XSLT-Transformation
und sendet das Ergebnis der Extraktion als XML zurück an den Aufrufer.
Produktionssystem
Job-Name
1
XML
6
extract
clean
2 HTTP-Anfrage-Objekt
XML
5
XH
Webserver
surf
HTTP-Anfrage
PH
HTTP-Antwort
3
4
Abbildung 3.1.: Ablauf einer Anfrage im Screen-Scraper von d2c
1
XSLT steht für Extensible Stylesheet Language Transformation und ist eine Sprache zur Transformation
von XML-Dokumenten.
20
d2c läuft komplett in einem Webbrowser und stellt keine Bedienelemente in der Webseite
zur Verfügung. Alle Aktionen wie Aufruf von d2c, Auswahl von Daten auf einer Webseite
sowie Erzeugen eines Screen-Scrapers erfolgt über Bookmarklets (s. Abschnitt 2.1).
d2c stellt keine Möglichkeit zur Verfügung, die Bedeutung von extrahierten Informationen zu definieren. Lediglich der generierte Web-Scraper lässt sich benennen. d2c erlaubt
es nicht, Informationen von mehreren Webseiten in einem Service zu kapseln.
In [YWH09] wird ein Werkzeug namens Grubber präsentiert. Wie d2c verwendet es
XML für die Ausgabe von extrahierten Daten. Es erlaubt, einzelne Teile der Webseite zu
beschriften und somit eine Bedeutung zuzuweisen. Ein Schwerpunkt dieses Werkzeuges
liegt unter anderem darauf, dass ein Benutzer nur ein Muster für die Definition der Daten
vorgibt, indem er einzelne Teile der Webseite – z. B. den Preis des ersten Produktes einer
Liste im Web-Shop – anklickt. Grubber versucht dabei, weitere Elemente – Preise aller
auf der Webseite verfügbaren Produkte – anhand der Struktur der Webseite zu finden
und dem Benutzer vorzuschlagen.
Das angeklickte Element wird anhand folgender Kriterien mit den vorgeschlagenen verglichen:
• HTML-spezifische Merkmale wie Tag-Name und Attribute im Tag.
• Layout-spezifische Merkmale wie Größe und Position auf der Webseite.
• Text-spezifische Merkmale wie die Länge des Textes, ggf. Typ und Bedeutung
anhand der Form (URL, E-Mail-Adresse, Preisangabe, Datum etc.) sowie Kleinund Großschreibung.
Außerdem wird bei Grubber die Ausgabe des künftigen Screen-Scrapers zur Laufzeit
angezeigt. Das erlaubt dem Benutzer, eine falsch getroffene Auswahl ähnlicher Elemente
vor dem Erzeugen des Screen-Scrapers zu korrigieren.
Wie d2c ist Grubber für die Datenextraktion nur aus einzelnen Webseiten geeignet.
Wenn Informationen auf der ganzen Website verteilt sind, kann deren Zusammenhang
nicht definiert werden.
3.2. Kommerzielle Produkte
Eines der bekanntesten kommerziellen Werkzeuge auf dem Markt ist Visual Developer
von Lixto2 . Dies ist eine integrierte Entwicklungsumgebung, die speziell auf die visuelle
Entwicklung von Web-Scrapern ausgerichtet ist. Es besitzt eigene Mustererkennungsalgorithmen und Qualitätssicherungsmechanismen sowie Heuristiken und Regeln zur
robusten Erkennung von Webobjekten. Es unterstützt offene Standards wie XML, HTML,
CSS und XPath. Abbildung 3.2 zeigt die grafische Benutzeroberfläche von Lixto Visual
Developer 3 .
2
3
http://www.lixto.com/lixto_visual_developer
Abbildungen 3.2 und 3.3 stammen aus [BGH09].
21
Abbildung 3.2.: Grafische Benutzeroberfläche von Lixto Visual Developer
Visual Developer
Application
Logic
Web Applications
Runtime
Parameters
VD
Runtime
VD
Runtime
Wrapper
Creation
Mozilla
Eclipse IDE
Data Model
Wrapper
VD
Runtime
Application
Designer
Wrapper
Lixto Hydra (Thread
Pool of VD runtimes)
Lixto TS
Abbildung 3.3.: Die Architektur von Lixto Visual Developer
22
Abbildung 3.3 zeigt die Architektur4 von Lixto Visual Developer. Es setzt auf dem
Eclipse IDE 5 Framework auf und integriert die Webbrowser-Engine von Mozilla 6 , um
Benutzerinteraktionen wie Klicks überwachen und den DOM-Baum (s. Abschnitt 2.1)
manipulieren zu können.
Als erstes erstellt ein Anwendungsentwickler ein neues oder importiert ein vorhandenes
Datenmodell in XML. Das Datenmodell beschreibt dabei die Struktur von Informationen,
die extrahiert werden müssen. Dann definiert er relevante Daten, indem er entsprechende Elemente auf der Webseite anklickt, Formulare ausfüllt etc. Der Entwickler klickt
dabei nur einzelne Elemente – z. B. eine Tabellenzeile – an, und das System erweitert
seine Auswahl automatisch, indem z. B. alle Zeilen in der Tabelle markiert werden. Das
System zeichnet alle Aktionen auf und zeigt ständig ein visuelles Feedback mit den bisher extrahierten Informationen an. Der Entwickler kann diverse Filter zum Aussortieren
irrelevanten Daten definieren.
Nach der Extraktion wird eine Menge von Wrappern erzeugt. Die extrahierten Daten
werden gegen das Datenmodell validiert. Die Wrapper und das Datenmodell werden
auf einen Server hochgeladen und etweder in einem Web-Service im SOAP-Stil gekapselt
oder zum Zugriff per Java RMI 7 zur Verfügung gestellt. Es ist möglich, den Wrappern Parameter (z. B. Formulardaten) zu übergeben. Lixto Visual Developer bietet viele
Ausgabeformate – unter anderen JSON, RSS, Atom (s. Abschnitt 2.4.3) – für extrahierte
Informationen an.
Lixto Visual Developer verwendet eine eigene deklarative Extraktionssprache namens
Elog, die auf regulären Ausdrücken und XPath basiert. Elog beschreibt HTML-Elemente
durch Prädikate. In Listing 3.1 wird ein Beispiel einer Anfrage in Elog gegeben:
1
2
3
4
5
6
record(X0, X1) :−
root(_, X0), subelem(X0,
(/html/body/div[3]/lixto:nearest(table)/tr ,
[( "class", "midCol", substring)]) , X1),
before(X1, ../ tr/td [2], [( "text",
"^Search.∗", regexp)]) , 0, 100, X2, X3).
Listing 3.1: Anfrage in Elog
Das Prädikat record wird erfüllt, wenn die Prädikate root, subelem und before erfüllt
werden. Das vordefinierte Prädikat root liefert eine Menge von Elementen X0. Im Prädikat subelem wird auf jedes X0 ein XPath-Ausdruck angewendet, und Ergebnisse werden
in X1 gespeichert. Das Prädikat before schränkt diese Menge mittels eines weiteren
XPath-Ausdrucks und eines regulären Ausdrucks ein.
Lixto Visual Developer ist eines der mächtigsten Werkzeuge auf dem Markt. Es kann
nicht nur Muster bei der Auswahl der Daten auf einer Webseite, sondern auch Muster
in der Navigation des Benutzers auf einer Website erkennen. Es kann also über mehrere
4
http://www.lixto.com/lixto_visual_developer_architecture/
http://www.eclipse.org/
6
http://www.mozilla.org/
7
RMI steht für Remote Method Invocation und erlaubt den Aufruf einer Methode eines entfernten
Java-Objektes.
5
23
Webseiten verteilte Informationen extrahieren. Leider ist Lixto Visual Developer nur
für Entwickler mit Erfahrung in Eclipse und den verwendeten Technologien wie XML,
XPath etc. gedacht. Für Benutzer ohne technischen Hintergrund ist dieses Werkzeug
ungeeignet.
Eine detaillierte Beschreibung der Architektur und der Extraktionssprache dieses Werkzeugs ist in [BFG01], [BGH09] und [CB10] zu finden.
Einige Mashup-Editoren enthalten Mechanismen zur Datenextraktion. Das in Abschnitt 2.3 erwähnte Werkzeug Yahoo! Pipes bietet zwei Module (Fetch Page und Regex ) an, um Informationen aus Webseiten zu extrahieren. Sie setzen jedoch Kenntnisse
in HTML und regulären Ausdrücken aus, was sie für Benutzer ohne diese Kenntnisse
ungeeignet macht.
Ein Werkzeug für Benutzer ohne Programmierkenntnisse ist z. B. Dapper 8 (Data Mapper). Mit seiner Hilfe kann man Daten extrahieren und in verschiedenen Formaten wie
XML, RSS, JSON, iCalendar (s. Abschnitt 2.4.3) ausgeben lassen. Dapper ist eine webbasierte Anwendung. Um einen Service (einen sogenannten Dapp) zu erstellen, muss
der URL der gewünschten Webseite eingegeben werden. Danach öffnet sich ein virtueller
Webbrowser innerhalb der Dapper -Webseite, und alle weiteren Aktionen wie Klicks und
das Ausfüllen von Formularen werden aufgezeichnet. Wenn der Benutzer die Webseite
mit relevanten Daten gefunden hat, legt er sie in einen sogenannten Basket. Möchte er
Daten aus mehreren Seiten einer Website (ohne Beziehungen) in einem Service kapseln,
öffnet er einen neuen Tab im virtuellen Browser und navigiert zur gewünschten Webseite. Nach der Auswahl der Webseiten markiert er einzelne relevante Elemente (wie
Tabellenzellen, Bilder etc.). Daraufhin schlägt Dapper ähnliche Elemente (wie weitere
Tabellenzellen) vor. Wenn der Benutzer mit der vorgeschlagenen Menge zufrieden ist,
kann er sie benennen und in einem Feld speichern. Den gleichen Prozess kann er auch
mit anderen Elementen wiederholen, bis alle Daten erfasst wurden. Zum Schluss können
die Felder gruppiert werden.
Dapper hat jedoch einige Nachteile. Gruppiert werden dürfen nur diejenigen Felder, die
sich auf derselben Webseite befinden. D. h. es ist nicht möglich, Daten von verschiedenen
Webseiten in Beziehung zu setzen. Außerdem kann der Typ des Feldes nicht angegeben
werden.
Andere Dapper ähnliche Wrapper sind z. B. Mozenda 9 (s. Abbildung 3.5) und openkapow 10 .
Alle oben genannten Werkzeuge verfolgen eine Extraktion von Daten, unabhängig von
ihrem Typ und deren Beziehungen. Daten auf verschiedenen Webseiten werden nicht
als zugehörig zueinander erkannt. Im Rahmen dieser Master-Arbeit soll ein Konzept
entwickelt werden, wie Informationen als Ressourcen mit typisierten Attributen sowie
Beziehungen zwischen diesen Ressourcen extrahiert werden können. Dabei dürfen die
Ressourcen auf mehreren Webseiten verteilt vorliegen. Der erstellte Service soll nach
REST-Prinzipien (s. Abschnitt 2.4) aufgebaut werden.
8
http://www.dapper.net
http://www.mozenda.com
10
http://openkapow.com
9
24
Abbildung 3.4.: Benutzeroberfläche von Dapper
Abbildung 3.5.: Benutzeroberfläche von Mozenda
25
Im Rahmen dieser Arbeit soll ein Konzept für die Erstellung von Web-Services entwickelt
werden, die die Extraktion von über mehrere Webseiten einer Website verteilten Daten
(Ressourcen) und ggf. deren Beziehungen durchführen. Dabei werden Benutzer ohne
Programmierkenntnisse vorausgesetzt.
In diesem Kapitel wird dieses Konzept zuerst anhand eines Beispielszenarios exemplarisch vorgestellt. Anschließend folgt eine allgemeine Beschreibung des Konzeptes. Es
wird das Metamodell für ein Datenmodell definiert, in das extrahierte Daten abgebildet
werden. Dann wird der Ablauf einer Datenextraktion mit DisRESTractor erklärt. Zum
Schluss wird der generierte Service beschrieben.
4.1. Anwendungsszenario
Anmerkung: Um die Benutzerfreundlichkeit von DisRESTractor zu verbessern und die
Verständlichkeit des Konzeptes für Benutzer ohne Programmierkenntnisse zu erhöhen,
wurden die Begriffe Ressource und Attribut durch Objekt und Merkmal ersetzt. In diesem
Kapitel werden sie synonym verwendet.
Nach der Herleitung des in den nächsten Abschnitten folgenden Konzeptes wurde überlegt, wie die Abläufe in eine Webanwendung abzubilden sind. Das folgende Szenario
präsentiert das Konzept.
4.1.1. Beschreibung des Szenarios und Motivation
Ein Reiseveranstalter bietet Stadtführungen in Hannover an. Um seine Werbung regelmäßig zu aktualisieren, braucht er häufig neue Fotos von der Stadt. Da der Maschsee
eine wichtige Sehenswürdigkeit von Hannover ist, möchte der Reiseveranstalter nach Bildern vom Maschsee suchen. Dafür verwendet er das Webportal Flickr 1 , das eine große
Auswahl an Bildern hat. Informationen über ein Foto befinden sich aber auf mehreren Webseiten. So enthält die Webseite mit Suchergebnissen einer Anfrage lediglich eine
Kleinvorschau und den Benutzernamen des Besitzers zu jedem Bild. Um das Aufnahmedatum, zugeordnete Schlagwörter und Informationen über den Besitzer zu bekommen,
müssen noch drei Webseiten für jedes Bild besucht werden. Daher möchte der Reiseveranstalter diese Informationen mit Hilfe von DisRESTractor extrahieren2 und sich so
nicht nur die aufwändige Navigation, sondern auch die Suchanfrage ersparen.
1
Flickr ist ein Webportal von Yahoo!, das es Benutzern erlaubt, digitale Bilder auf der Webseite
anderen Nutzern zur Verfügung zu stellen.
2
Tatsächlich stellt Flickr offene Schnittstellen zur Verfügung. Es wird aber angenommen, dass es sie
nicht gäbe.
26
Mit Hilfe eines Mashup-Editors für Benutzer ohne Programmierkenntnisse wie Yahoo!
Pipes (s. Abschnitt 3.2) könnte der Reiseveranstalter einen Mashup bauen, in dem der
generierte Service verwendet wird. So könnte er alle Bilder mit dem Schlagwort „Party“
aussortieren, da auf solchen Bilder meistens Personen zu sehen sind, was diese Bilder
aus rechtlichen Gründen für eine Werbung unbrauchbar macht. Danach könnte er alle
gebliebenen Bilder nach Datum sortieren und als RSS-Feed (s. Abschnitt 2.4.3) ausgeben
lassen. So könnte er neueste Bilder inklusive Kontaktinformationen über deren Besitzer
ohne Suche und Navigation auf der Website erhalten.
4.1.2. Aufruf und Benutzeroberfläche von DisRESTractor
Als erstes öffnet der Reiseveranstalter die Webseite von Flickr in seinem Webbrowser
und führt eine Suche nach dem Wort Maschsee durch. Da er nur nach lizenzfreien
Bildern suchen möchte, muss er eine weitere Webseite mit Suchoptionen besuchen. Von
der Webseite mit Suchergebnissen kann der Reiseveranstalter DisRESTractor über ein
Bookmarklet 3 starten.
Abbildung 4.1.: DisRESTractor nach dem Start
Abbildung 4.1 zeigt die graphische Benutzeroberfläche von DisRESTractor. Den größten Teil nimmt die ursprüngliche Flickr -Webseite ein, von der Informationen extrahiert
werden müssen. Darüber wird der URL dieser Flickr -Webseite angezeigt. So hat der Benutzer einen virtuellen Webbrowser in seinem momentan verwendeten Webbrowser. Auf
3
Bookmarklets sind eine Art Lesezeichen in Webbrowsern, die die Ausführung von JavaScript-Code in
der aktuell geöffneten Webseite erlauben.
27
der linken Seite des Fensters (weiter als Ressourcen-Panel bezeichnet) werden später Informationen (Ressourcen und deren Attribute) angezeigt, die der Benutzer extrahieren
möchte. Ganz oben befindet sich eine interaktive Hilfe (weiter als Info-Leiste genannt),
die dem Benutzer kurz beschreibt, was er als nächstes tun kann. Durch das Anklicken
des Fragezeichen-Symbols oben rechts in der Info-Leiste erscheint eine detaillierte Dokumentation zu DisRESTractor.
4.1.3. Auswahl relevanter Informationen und Hinzufügen einer Ressource
Als erstes fordert DisRESTractor über die Info-Leiste den Benutzer auf, ein Element
(ein Bild oder ein Textstück) anzuklicken, um dieses als Attribut einer neuen Ressource
hinzuzufügen. Alle Links auf der Webseite werden dabei ausgeschaltet, so dass der Benutzer jedes Element anklicken kann, ohne auf eine andere Webseite zu gelangen. Auf
der ersten Webseite lassen sich zwei Arten von Ressourcen erkennen, und zwar Foto
und Fotograf. Als erstes klickt der Benutzer das erste Bild in der Ergebnismenge an.
Daraufhin bekommt dieses einen grünen Rand. Gleichzeitig schlägt DisRESTractor andere Bilder vor, die dem Angeklickten „ähnlich“ (s. nächsten Abschnitt) sind, indem sie
durch einen gelben Rand hervorgehoben werden. Diese Situation ist in Abbildung 4.2
zu sehen.
Abbildung 4.2.: DisRESTractor: Auswahl der ersten Ressource
In diesem Fall hat DisRESTractor einen richtigen Vorschlag gemacht. Allgemein können
aber falsch vorgeschlagene Elemente (mit dem gelben Rand) abgewählt und nicht vorgeschlagene (ohne Rand) durch Anklicken ausgewählt werden. In der Info-Leiste wird
die Anzahl momentan ausgewählter Elemente angezeigt und immer aktualisiert.
28
Falls der Benutzer mit der Auswahl zufrieden ist, kann er eine Ressource erstellen. Dafür
drückt er die Schaltfläche Objekt aufnehmen, was das Öffnen des in Abbildung 4.3a dargestellten Dialoges auslöst. Hier muss der Benutzer die neue Ressource und das gerade
ausgewählte Attribut benennen und optional beschreiben. Er gibt Foto als Ressourcennamen und Vorschau als Attributnamen sowie jeweils eine kurze Beschreibung ein. Für
das Attribut muss zusätzlich der Typ angegeben werden, der vom System vorgeschlagen
wird. Mögliche Typen werden im nächsten Abschnitt beschrieben. Das aktuelle Attribut
hat den Typ Bild.
Abbildung 4.3.: DisRESTractor: Dialog Objekt aufnehmen
Nach der Bestätigung der Angaben durch die Schaltfläche speichern, wird die Ressource
hinzugefügt. Alle gerade ausgewählten Bilder (mit einem grünen oder gelben Rand) im
virtuellen Browser werden durch einen blauen Rand hervorgehoben und dürfen somit
nicht mehr ausgewählt werden, was von DisRESTractor kontrolliert wird. Informationen
über die Ressource erscheinen im Ressourcen-Panel (s. Abbildung 4.3b). Neben dem
Namen der Ressource befinden sich drei Symbole4 :
4
Die Icons sind auf dem Webportal http://www.gettyicons.com verfügbar und dürfen frei verwendet
werden.
29
zeigt die vom Benutzer eingegebene Beschreibung einer Ressource als Tooltip
an; das Symbol wird ausgegraut, falls keine Beschreibung vorhanden ist.
ermöglicht das Umbenennen einer Ressource oder die Änderung deren Beschreibung.
ermöglicht das Löschen einer Ressource.
Neben jedem Attribut können auch bis zu fünf Symbole aus der folgenden Menge stehen:
zeigt die vom Benutzer eingegebene Beschreibung eines Attributs als Tooltip
an; das Symbol wird ausgegraut, falls keine Beschreibung vorhanden ist.
ermöglicht das Umbenennen eines Attributs oder die Änderung dessen Beschreibung.
ermöglicht das Löschen eines Attributs.
öffnet die Webseite mit dem Attribut im virtuellen Browser von DisRESTractor.
gibt an, dass das Attribut mehrmals für jede Ressource vorkommen kann.
gibt an, dass das Attribut eine Ressource ist; die oben beschriebenen Symbole
stehen dann neben der Ressource, auf die das Attribut verweist.
Jedes Symbol wird durch jeweils einen Tooltip beschrieben, wenn der Benutzer mit der
Maus darüber fährt.
Wenn mindestens eine Ressource existiert, kann der Benutzer schon den ganzen Prozess
abschließen und einen Service generieren lassen. Da es in diesem Fall nicht sinnvoll ist,
eine Ressource mit einem einzigen Attribut zu extrahieren, setzt der Benutzer seine
Arbeit fort.
4.1.4. Erfassung von Beziehungen zwischen Ressourcen
In der Info-Leiste wird der Benutzer gefragt, ob er weitere Attribute (auch einer neuen
Ressource) auf dieser Webseite hinzufügen oder die Webseite wechseln möchte. Da die
Ressource Fotograf für den Reiseveranstalter (z. B. aus rechtlichen Gründen) interessant
ist, klickt er den ersten Link zum Fotografen (Mathias M ) an. Wie beim Foto erweitert
DisRESTractor seine Auswahl automatisch. Jetzt hat der Benutzer drei Möglichkeiten:
1. Er kann den momentan markierten Benutzernamen des Fotografen als Text-Attribut von Foto hinzufügen, indem er die Schaltfläche Merkmal hinzufügen im
Bereich von Foto betätigt und als Attributtyp Text auswählt.
30
2. Er kann den momentan markierten Benutzernamen als Attribut einer neuen Ressource Fotograf hinzufügen, die unabhängig von Foto ist, indem er die Schaltfläche
Objekt aufnehmen drückt.
3. Er kann den momentan markierten Benutzernamen als Attribut einer neuen Ressource Fotograf hinzufügen, die wiederum ein Attribut von Foto ist. Somit kann
er die beiden Ressourcen in Beziehung miteinander stellen.
Der Reiseveranstalter entscheidet sich für die dritte Variante, da der Fotograf weitere Attribute wie E-Mail-Adresse, Website etc. haben kann. Er betätigt den Button
Merkmal hinzufügen und wählt als erstes den Attributtyp Objekt aus, woraufhin sich
der Dialog – wie in Abbildung 4.4 gezeigt – ändert.
Abbildung 4.4.: DisRESTractor: Dialog Attribut als Ressource hinzufügen
Der Benutzer gibt Informationen über die Ressource Fotograf und deren erstes Attribut Benutzername ein und bestätigt die Eingaben durch die Schaltfläche speichern.
Die entsprechenden Elemente im virtuellen Browser werden durch einen blauen Rand
hervorgehoben. Im Ressourcen-Panel (s. Abbildung 4.5) wird Fotograf zum einen als
Attribut vom Foto, zum anderen als eine eigenständige Ressource hinzugefügt.
4.1.5. Navigation auf der Website
In der Info-Leiste wird der Benutzer wieder gefragt, ob er die Webseite wechseln möchte, was er durch den Button navigieren bestätigt. Daraufhin werden alle Links im
virtuellen Browser wieder aktiviert. Zusätzlich kann der Benutzer das Globus-Symbol
neben den Attributen als Link verwenden, um zur Webseite mit dem Attribut zu kommen. Da sich die beiden hinzugefügten Attribute auf der aktuellen Webseite befinden,
31
Abbildung 4.5.: DisRESTractor: Zwei Ressourcen, die miteinander in Beziehung stehen
sind diese Links inaktiv und das Symbol ist ausgegraut. Der Benutzer klickt das erste
Bild an und gelangt auf die Webseite mit mehr Informationen darüber. Nach dem oben
beschriebenen Prinzip fügt er das Aufnahmedatum als Attribut vom Typ Datum hinzu.
4.1.6. Hinzufügen eines mehrwertigen Attributes
Als nächstes fügt er das Attribut Schlagwort hinzu. Wie in Abbildung 4.6 zu sehen
ist, gibt es zum Bild mehrere Schlagwörter. Dabei handelt es sich um ein mehrwertiges
Attribut. Daher steht im Ressourcen-Panel neben dem Attribut Schlagwort ein StapelSymbol.
4.1.7. Erzeugen eines Service
Als Letztes navigiert der Reiseveranstalter zur Profil-Webseite des Besitzers eines Fotos
(s. Abbildung 4.7), auf der weitere Informationen wie Beitrittsdatum, Heimatstadt etc.
verfügbar sind. Den Reiseveranstalter interessieren mehr die Kontaktdaten, daher fügt
er das Attribut Website hinzu.
Die gesammelten Informationen reichen ihm nun, und er betätigt die Schaltfläche Service erstellen. Daraufhin erscheint ein Dialog (s. Abbildung 4.8), in dem der Benutzer
den Namen (Maschsee-Bilder) und die Beschreibung des Service eingibt. Nach der
Bestätigung wird ein Service generiert und auf dem Server installiert. DisRESTractor
wird automatisch geschlossen, und der Benutzer wird auf die „Eingangsseite“ des Service
umgeleitet, auf der der generierte Service (auch technisch) beschrieben ist.
32
Abbildung 4.6.: DisRESTractor: Mehrwertiges Attribut
Abbildung 4.7.: Profilseite des Besitzes eines Bildes bei Flickr
Ab jetzt kann der Reiseveranstalter Informationen über Bilder vom Maschsee über den
generierten Service abrufen. In einem Mashup-Editor kann er diese Informationen ggf.
filtern und mit anderen Quellen kombinieren.
33
Abbildung 4.8.: DisRESTractor: Dialog Service erstellen
4.2. Beschreibung des Konzeptes
Im vorigen Abschnitt wurde das Konzept anhand eines Beispielszenarios vorgestellt.
Dabei wurde ein Web-Scraper für das Webportal Flickr mithilfe von DisRESTractor
erstellt, der Informationen über Bilder vom Maschsee in Hannover und deren Besitzer liefert. Im Folgenden wird dieser Prozess einschließlich aller Sonderfälle allgemein
beschrieben.
Da in dieser Arbeit der REST-Ansatz verfolgt wird, bei dem Ressourcen im Mittelpunkt
stehen, sollen mit DisRESTractor Informationen in Form von Ressourcen extrahiert werden. Um Ressourcen strukturiert verwalten zu können, wird ein Datenmodell erstellt, in
das extrahierte Daten abgebildet werden. Außerdem kann dadurch eine Unabhängigkeit
von der technischen Zielplattform des generierten Service erreicht werden.
4.2.1. Metamodell für extrahierte Daten
In einem Datenmodell werden alle Ressourcen eines Service abgebildet. Wie Ressourcen
im Rahmen dieser Arbeit definiert sind, zeigt das Metamodell in Abbildung 4.9.
Nach dem REST-Prinzip wird die Schnittstelle IReadOnlyResource definiert. Wie jede
Ressource im HTTP besitzt sie einen URI, der sie eindeutig identifiziert. Unter diesem URI
wird die Ressource im später generierten Service verfügbar sein. Da die meisten Webportale nur einen lesenden Zugriff auf ihre Daten erlauben, werden im Rahmen dieses
Konzeptes ebenfalls nur lesende Operationen mit Ressourcen behandelt. Das sind die
HTTP-Methoden GET, HEAD und OPTIONS. Ein Service liefert Informationen über mindestens eine Ressource.
Jede Ressource (Resource) implementiert die Schnittstelle IReadOnlyResource und hat
einen Namen und eine Beschreibung. Der Name jeder Ressource wird in der Ausgabe
von extrahierten Daten stehen. Die Beschreibung dient einem besseren Verständnis der
Daten, die eine Ressource repräsentiert. Dabei ist die Beschreibung optional, da der
Name schon aussagekräftig genug sein kann. Außerdem wird die Beschreibung von Ressourcen nicht in ihren Repräsentationen, sondern nur in der Dokumentation zum Service
enthalten sein.
34
IReadOnlyResource
Service
+URI: String
+name: String
+description: String
+GET()
+HEAD()
+OPTIONS()
1
1..*
Resource
+name: String
1
1
1..*
Attribute
*
1
Type
*
List
+name: String
+name: String
+value: Type
+URI: String
+XPath: String
Abbildung 4.9.: Metamodell für extrahierte Daten
Um über mehrere Webseiten verteilte Informationen über eine Ressource strukturiert
definieren zu können, wird der Begriff Attribut (Attribute) eingeführt. Jede Ressource
setzt sich dabei aus einer nicht leeren Menge von Attributen zusammen. Jedes Attribut
enthält folgende Informationen:
Name beschreibt das Attribut und wird in den Repräsentationen von Ressourcen stets angegeben.
Beschreibung ist optional und gibt eine detaillierte Auskunft über das Attribut und
steht nur in der Dokumentation zum Service.
URI adressiert die ursprüngliche Webseite, auf der dieses Attribut vorkommt.
XPath-Audruck gibt eine exakte Position des Attributes auf der ursprünglichen Webseite.
Typ gibt den Datentyp des Attributs an.
Value enthält den extrahierten Wert des Attributes.
Der Datentyp von Attributen dient zum einen einer besseren Definition des Attributs
und kann zum anderen später in einem Maschup nützlich sein, um beispielsweise alle
Bilder nach dem Aufnahmedatum zu sortieren. Da für DisRESTractor Benutzer ohne
Informatik-Kenntnisse vorausgesetzt werden, ist es nicht möglich, sämtliche Datentypen
35
von z. B. XML-Schema5 zur Verfügung zu stellen. Eine automatische Erkennung des Datentyps ist häufig auch nicht möglich. Daher wurden die Datentypen in DisRESTractor
auf die folgenden beschränkt:
Datentyp in DisRESTractor
Text
Zahl
Datum
Bild
Entsprechender Datentyp in XML-Schema
string
decimal
date
string (img-Tag des entsprechenden Bildes)
Tabelle 4.1.: Datentypen in DisRESTractor
Jedes Attribut kann auch eine Liste von Werten – wie das Attribut Schlagwort aus dem
Abschnitt 4.1 – liefern.
Ein Attribut kann auch eine Ressource sein. In DisRESTractor kann man das durch
den Datentyp Objekt angeben. Dadurch kann eine Beziehung zwischen zwei Ressourcen
hergestellt werden.
4.2.2. Ablauf der Datenextraktion mit DisRESTractor
Wie im Abschnitt 4.1 gezeigt wurde, definiert der Benutzer im Dialog mit DisRESTractor, welche Informationen extrahiert werden müssen. Das Aktivitätsdiagramm in
Abbildung 4.10 zeigt den allgemeinen Ablauf einer Datenextraktion mit DisRESTractor.
Als erstes muss der Benutzer eine Webseite mit den für ihn relevanten Informationen in
seinem Webbrowser öffnen. Der URL6 dieser Webseite wird als nächstes an DisRESTractor übergeben.
Nach dem Start von DisRESTractor dürfen keine Daten über Formulare angefordert
werden. Eine Übergabe von Formularparametern an den künftigen Service ist ebenfalls
nicht möglich. Der Benutzer muss vor dem Aufruf von DisRESTractor zur Ergebnisseite
gelangen. Aber selbst wenn er dies gemacht hat, ist eine Datenextraktion nicht immer
möglich. Problematisch ist es in dem Fall, wenn Formular-Daten per POST (s. Abschnitt
2.4.5) abgeschickt werden. Dabei unterscheidet sich der URL der Ergebnisseite nicht vom
URL der ursprünglichen Webseite mit dem noch nicht ausgefüllten Formular. Wenn dieser
URL an DisRESTractor übergeben wird, wird in seinem virtuellen Browser die Webseite
mit dem leeren Formular ohne Ergebnisse geöffnet. Dieses Problem kann aber nur durch
eine vollständige Aufzeichnung aller Benutzerinteraktionen (insbesondere des Absendens
des Formulares) inklusive Browser-Cookies 7 in DisRESTractor gelöst werden. Im Rahmen dieser Arbeit wird das nicht gemacht, weil das bereits in anderen Anwendungen –
z. B. in Lixto Visual Developer (s. Kapitel 3) – gelöst wurde. Der technische Aufwand
wäre daher nicht zu rechtfertigen. Außerdem erlaubt DisRESTractor nur das Lesen von
Daten, und alle lesenden Anfragen über Formulare sollten aber nach einer Empfehlung
von W3C ([Jac04]) die GET-Methode verwenden.
5
XML-Schema ist eine Empfehlung des W3C zum Definieren von Strukturen für XML-Dokumente.
Der Unterschied zwischen einem URL und einem URI wird in Abschnitt 2.4.2 erklärt.
7
Browser-Cookies oder HTTP-Cookies sind clientseitig gespeicherte Daten.
6
36
Aufruf der Webseite
mit relevanten Inhalten
Aufruf von DisRESTractor
relevante Daten auf der
aktuellen Webseite vorhanden
Navigation auf der gesamten Website
ja
nein
Hinzufügen eines Attributs
auf der aktuellen Webseite
nein
alle relevanten Daten
sind gesammelt
ja
Service generieren
Abbildung 4.10.: Ablauf der Datenextraktion mit DisRESTractor
DisRESTractor kann von der Webseite mit gewünschten Daten über ein Bookmarklet
aufgerufen werden. Bookmarklets sind eine Art Lesezeichen in Webbrowsern, die die Ausführung von JavaScript-Code in der aktuell geöffneten Webseite erlauben. In diesem
Fall führt das Bookmarklet zwei Schritte durch:
1. Im URL der aktuellen Webseite werden alle nicht erlaubten Zeichen wie „?“ und
„&“ in eine geeignete Form umgewandelt.
2. Die aktuelle Webseite wird zum DisRESTractor umgeleitet, dem der bearbeitete
URL übergeben wird.
Die Benutzeroberfläche von DisRESTractor ist in Abbildung 4.11 dargestellt. In der
Lesezeichen-Symbolleiste des Webbrowsers (1) befindet sich das Bookmarklet mit dem
Titel Start DisRESTractor, das das Starten von DisRESTractor ausgelöst hat. Visuell
besteht DisRESTractor aus den folgenden Bereichen:
Info-Leiste (2) befindet sich ganz oben und weist den Benutzer permanent
an. Ganz rechts in der Leiste steht ein Fragezeichen-Symbol,
über das eine detaillierte Dokumentation zum DisRESTractor angefordert werden kann.
37
Adress-Leiste (3) zeigt den URL der aktuellen Webseite an. Die Eingabe eines
anderen URL ist im Gegenteil zum herkömmlichen Webbrowser nicht möglich.
Virtueller Browser (4) stellt Webseiten dar, aus denen der Benutzer Informationen
extrahieren will.
Ressourcen-Panel (5) enthält Informationen über die bereits hinzugefügten Ressourcen. Nach dem Start von DisRESTractor enthält dieser
Bereich nur zwei Schaltflächen: Objekt aufnehmen zum Hinzufügen einer Ressource und Service erstellen zum Generieren eines Web-Scrapers.
Ressourcen-Bereiche (6, 7) enthalten Informationen über Attribute und jeweils einen Button zum Hinzufügen eines weiteren Attributs.
Abbildung 4.11.: Benutzeroberfläche von DisRESTractor
Die Idee der Trennung des Browser-Fensters in mehrere Teile – Info-Leiste, RessourcenPanel und virtuellen Browser in DisRESTractor – wurde aus anderen Werkzeugen wie
Dapper (s. Abschnitt 3) übernommen. Sie bringt den Vorteil, dass der Benutzer bei der
Arbeit mit DisRESTractor einerseits den Überblick über bereits hinzugefügte Ressourcen behält und andererseits ständig über weitere mögliche Aktionen informiert wird.
Allerdings nimmt bei Dapper (s. Abbildung 3.4 auf Seite 25) eine detaillierte Hilfe einen
großen Teil des Fensters ein. Dieser relativ große Bereich wird in DisRESTractor für
die Darstellung von Ressourcen (Ressourcen-Panel) verwendet, weil sie insbesondere bei
langen Ressourcen- oder Attributnamen viel Platz in der Benutzeroberfläche benötigen.
38
Eine ausführliche Hilfe kann über das Fragezeichen-Symbol in der Info-Leiste angefordert
werden. Dabei wird davon ausgegangen, dass der Benutzer nur beim Erstellen von ersten
Services eine detaillierte Hilfe braucht. Nachdem er sich mit DisRESTractor vertraut
gemacht hat, sollten ihm Hinweise in der Info-Leiste ausreichen.
Viele Werkzeuge wie Dapper oder Grubber (s. Abschnitt 3.1) bieten noch ein visuelles
Feedback an, in dem bereits extrahierte Daten angezeigt werden. Darauf wird in DisRESTractor verzichtet, da Ressourcen in dieser Arbeit über mehrere Webseiten verteilt
sein dürfen, was zur Folge hat, dass die Extraktion zu lange dauert und somit zur
Laufzeit nicht möglich ist. Im dem Beispielszenario aus dem Abschnitt 4.1 müssten z. B.
51 Webseiten besucht werden, um alle Werte (jeweils einen für jedes Bild) des Attributes
Aufnahmedatum zu erhalten. Anhand mehrerer Zeitmessungen wurde festgestellt, dass
die Extraktion des Attributes Aufnahmedatum im Schnitt 4 Sekunden8 dauert. Diese
Zeit setzt sich aus der Ladezeit der Webseite mit Bildinformationen, auf der sich das
Attribut befindet und der Zeit der Extraktion mittels XPath. Die Ladezeit der Webseite
mit Suchergebnissen, auf der die Navigation beginnt, wurde nicht berücksichtigt. Wenn
ein visuelles Feedback für dieses Attribut in DisRESTractor verfügbar wäre, müssten
alle Werte knapp dreieinhalb Minuten (51 * 4 = 204 Sekunden) geladen werden. So
lange Wartezeiten würden die ganze Anwendung unbrauchbar machen.
Bei der Arbeit mit DisRESTractor steht dem Benutzer immer wieder eine der folgenden
zwei Aktionen zur Verfügung:
1. Wenn die aktuelle Webseite relevante Daten enthält, kann der Benutzer ein neues
Attribut einer bestehenden oder neuen Ressource hinzufügen. Dabei werden alle
Links im virtuellen Browser sowie neben den Attributen deaktiviert. Eine Navigation ist also nicht möglich und kann über die Schaltfläche navigieren in der
Info-Leiste freigegeben werden.
2. Der Benutzer kann innerhalb der gesamten Website navigieren. Alle Links sind
aktiv. Wie bereits oben erwähnt, dürfen dabei keine Formulare verwendet werden.
Zusätzlich zu Hyperlinks auf der aktuellen Webseite kann der Benutzer über Links
neben jedem Attribut im Ressourcen-Panel navigieren, die zur Webseite führen,
auf der sich dieses Attribut befindet. So kann der Benutzer auf eine schon besuchte
Webseite zurückkehren, um die Navigation von dort aus fortzuführen.
Der Benutzer kann Daten definieren, indem er einzelne entsprechende Elemente wie
Bilder, Tabellenzellen, Links oder Textstücke anklickt. Das erste angeklickte Element
dient dabei als Muster, nach dem DisRESTractor „ähnliche“ Elemente markiert. Markierte Bilder bekommen einen farblichen Rand, und sonstige markierte Elemente werden
durch einen farblichen Hintergrund hervorgehoben. Das angeklickte Element wird grün
und die vorgeschlagenen werden gelb markiert. Die automatische Auswahl wird anhand
der Position im HTML-Dokument und von CSS-Klassen9 des angeklickten Elements getroffen. Als „ähnlich“ werden diejenigen Elemente betrachtet, die im DOM-Baum10 möglichst
auf einer Ebene stehen und möglichst gleiche CSS-Klassen haben. Für die Berechnung
der Ähnlichkeit wurde ein vorhandenes Werkzeug namens SelectorGadget 11 eingesetzt.
8
Die Tests wurden bei einer Übertragungsrate der Internetverbindung von 32 MBit/s durchgeführt.
CSS steht für Cascading Style Sheets und ermöglicht das Formatieren von HTML-Elementen.
10
DOM steht für Document Object Model und ist eine Spezifikation für den Zugriff auf HTML-Dokumente.
11
http://www.selectorgadget.com/
9
39
Nicht immer können semantisch ähnliche Elemente anhand der Struktur bestimmt werden. Daher kann der Benutzer die Auswahl anpassen, indem ein vorgeschlagenes Element (mit der gelben Markierung) nochmals anklickt. Daraufhin wird dieses Element
rot markiert und alle ihm ähnlichen Elemente werden aus der Auswahl entfernt. In diesem Prozess vom Auswählen und Abwählen kann der Benutzer eine optimale Menge der
Elemente definieren, die im später generierten Service geliefert werden.
Für die angepasste Menge der Elemente wird ein XPath-Ausdruck berechnet, der die
genaue Position der Elemente auf der Webseite angibt. Im später generierten Service
werden also nicht unbedingt dieselben Elemente geliefert wie in der aktuellen Auswahl, sondern alle Elemente, die demselben Muster entsprechen. Somit können neue
Ressourcen-Instanzen – wie z. B. neue Bilder bei Flickr – in die Ergebnismenge des
Web-Scrapers einbezogen werden.
Es kann vorkommen, dass mehrere Instanzen derselben Ressource per Paginierungsmechanismus auf verschiedene Webseiten aufgeteilt werden. Im Rahmen dieses Konzeptes
wird das nicht behandelt, da dies bereits in anderen Werkzeugen gelöst wurde. Der
Schwerpunkt dieser Arbeit basiert auf Ressourcen, die über mehrere Webseiten mit verschiedener Struktur (also nicht wegen einer Paginierung) verteilt sind.
Wenn der Benutzer die Menge von Elementen festgelegt hat, kann er diese als Attribut
hinzufügen. Dabei sind folgende drei Fälle zu unterscheiden:
1. Der Benutzer fügt ein Attribut einer neuen Ressource hinzu. Dafür drückt er den
Button Objekt aufnehmen oben im Ressourcen-Panel. Daraufhin erscheint der in
Abbildung 4.12a dargestellte Dialog. Der Benutzer gibt den Namen und ggf. die
Beschreibung der Ressource und des Attributes ein und wählt einen Attributtyp
aus der Tabelle 4.1 auf Seite 36. Nach der Bestätigung wird im Ressourcen-Panel
ein neuer Bereich für die Ressource erstellt. Der Typ Objekt ist in diesem Fall
nicht erlaubt, weil Attribute auf der technischen Ebene über andere vorhandene
Attribute identifiziert werden. Wenn eine Ressource, die noch kein Attribut besitzt,
eine weitere Ressource als ihr erstes Attribut hinzufügt, kann dieses Attribut nicht
identifiziert werden. Eine ausführlichere Beschreibung liefert Abschnitt 6.4.
2. Er fügt ein Attribut einer vorhandenen Ressource hinzu. Dafür betätigt er die
Schaltfläche Merkmal hinzufügen aus dem Bereich der entsprechender Ressource
(s. Abbildung 4.11). Im Dialog aus der Abbildung 4.12b gibt der Benutzer den
Namen und ggf. die Beschreibung des Attributes und wählt einen Typ aus der
Tabelle 4.1 auf Seite 36. Nach der Bestätigung wird das Attribut im Bereich der
entsprechenden Ressource angezeigt.
3. Er fügt ein Attribut einer neuen Ressource hinzu, die wiederum ein Attribut einer
vorhandenen Ressource ist. Somit kann er die beiden Ressourcen in Beziehung
zueinander setzen. Dafür drückt er die Schaltfläche Merkmal hinzufügen aus dem
Bereich der vorhandenen Ressource (s. Abbildung 4.11). Im Dialog aus der Abbildung 4.12b wählt er den Attributtyp Objekt aus, woraufhin sich der Dialog wie in
Abbildung 4.12c ändert. Dort gibt er die Daten wie unter Punkt 1 ein und drückt
speichern. Im Bereich der vorhandenen Ressource erscheint ein neues Attribut
mit dem Titel der neuen Ressource. Zusätzlich wird ein weiterer Bereich für die
neue Ressource erstellt.
40
Abbildung 4.12.: Aufnahme von Attributen in DisRESTractor
Neben jeder Ressource und jedem Attribut im Ressourcen-Panel sind Symbole abgebildet, die es erlauben:
• die vom Benutzer eingegebene Beschreibung anzuzeigen,
• eine Ressource oder ein Attribut umzubenennen oder zu löschen,
• zur Webseite mit dem Attribut zu navigieren.
Diese Symbole wurden im Abschnitt 4.1 auf Seite 30 bereits beschrieben.
Sobald eine Ressource vorhanden ist, kann der Benutzer jederzeit einen Service generieren lassen. Dafür betätigt er die Schaltfläche Service erstellen im Ressourcen-Panel.
Im erscheinenden Dialog benennt er den Service und gibt ggf. eine Beschreibung ein.
Anschließend wird der Service generiert und auf dem Server installiert, und der Benutzer
wird auf die Webseite mit der Beschreibung des Service umgeleitet. Dort findet er Informationen, wie der Service verwendet werden kann. Dies wird im nächsten Abschnitt
beschrieben.
4.2.3. Generierter Service
Über den Service können alle extrahierten Informationen angefordert werden. Dafür
wurde XML als Repräsentation von Ressourcen ausgewählt. Mit XML lassen sich beliebige
Ressourcen strukturiert darstellen. Im Rahmen dieses Konzeptes sieht eine BeispielRessource wie folgt aus:
41
1
2
3
4
5
6
7
8
9
10
<?xml version="1.0" encoding="UTF−8"?>
<resource name="Ressource1">
<attribute name="Attribut1" type="image"
href="http://example.org/musterportal/xyz.html">
<img src="http://example.org/musterportal/images/xyz.jpg"
width="20" height="10" alt="tooltip"/>
</attribute>
<attribute name="Ressource2" type="resource"
href="http://example.org/Web−Scraper/service/Ressource2/5"/>
</resource>
Listing 4.1: XML-Repräsentation einer Ressource
Das resource-Element enthält den Titel der Ressource. Jedes Kindelement repräsentiert
ein Attribut, für das der Titel und der Typ angegeben werden. Als Inhalt enthalten
Attribute die aus der ursprünglichen Webseite extrahierten Daten. Falls der AttributInhalt auf der ursprünglichen Webseite verlinkt ist, wird der entsprechende Hyperlink
im href-Attribut des attribute-Elementes gespeichert (Zeile 4).
Falls ein Attribut auf eine andere Ressource verweist (Zeile 8), wird der Titel und der
URL der Ressource angegeben. Das type-Attribut resource weist darauf hin, dass es
sich um ein Ressourcen-Attribut handelt. Hier wird also dem REST-Prinzip Hypermedia
gefolgt.
Die Gestaltung von URLs einer Ressource erfolgt ebenfalls nach entsprechenden RESTPrinzipien. URLs haben das folgende Format:
http://Domainname/Service-Name/service/Ressourcen-Name/Ressourcen-Nummer
Verfügbare Ressourcen-Nummern kann man über die entsprechende Listen-Ressource
(s. weiter unten) bekommen.
Zusätzlich wird für jede Ressource die Liste aller Instanzen in XML-Repräsentation geliefert. Eine beispielhafte Listen-Ressource ist in Listing 4.2 zu sehen. Es wird eine Menge
von resource-Elementen angegeben, die jeweils einen URL und einen Titel der Ressource
enthalten. URLs zu Listen-Ressourcen sehen wie folgt aus:
http://Domainname/Service-Name/service/Ressourcen-Name
1
2
3
4
5
6
<resources>
<resource href="http://example.org/Web−Scraper/service/Ressource1/1" name="
Ressource1"/>
...
<resource href="http://example.org/Web−Scraper/service/Ressource1/n" name="
Ressource1"/>
</resources>
Listing 4.2: XML-Repräsentation einer Listen-Ressource
42
Wie in [Til09] empfohlen, wird für den generierten Service eine Dokumentation in Prosa
als HTML-Repräsentation geliefert. Diese besteht aus folgenden Teilen:
• Bezeichnung und Beschreibung des Service
• Auflistung von Ressourcen und deren Attributen
Für jede Ressource werden neben dem Titel und der Beschreibung (falls vorhanden) auch
der URL der entsprechenden Listen-Ressource sowie das URL-Schema von RessourcenInstanzen angegeben. Für jedes Attribut werden der Titel, die Beschreibung und der
Typ aufgelistet. Wie in Abschnitt 6.6 später gezeigt wird, wird für den Service auch
eine maschinenlesbare Dokumentation in WADL (s. Abschnitt 2.4.7) erzeugt.
In diesem Kapitel wurde das Konzept vorgestellt, das es Benutzern ohne Programmierkenntnisse erlaubt, über mehrere Webseiten verteile Informationen und ggf. deren
Beziehungen über die grafische Benutzeroberfläche von DisRESTractor in einem Service
zu kapseln. Im nächsten Kapitel folgt nun eine Evaluation, in der das Konzept auf seine
Eignung für Endbenutzer überprüft wird.
43
Um das Konzept vor der Implementierung auf die Bedienbarkeit zu prüfen, wurden
Interviews mit fachfremden Personen durchgeführt. Dabei sollte geprüft werden, ob das
Konzept für Benutzer ohne Programmierkenntnisse verständlich ist. Nach den Interviews
kamen die Teilnehmer zum Schluss, dass das Konzept von DisRESTractor erfolgreich
eingesetzt werden könnte. Es wurden sogar weitere Anwendungsszenarios entworfen.
Während der Interviews kamen viele Verbesserungsvorschläge, die vorher nicht bedacht
wurden und nach der Evaluation ins Konzept aufgenommen wurden.
5.1. Planung und Durchführung von Interviews
Für die Interviews wurden Personen ausgesucht, die einerseits keine tiefgreifenden Informatikkenntnisse haben und andererseits das Internet in ihrem Arbeitsalltag nutzen und
somit in der Lage sind, die Idee von Mashups und Web-Scraping schnell zu verstehen.
Für jedes Interview wurden 45 Minuten eingeplant. Alle Interviews wurden isoliert mit
jeweils einer Person durchgeführt, damit die Anderen kein Vorwissen haben.
Als Interview-Teilnehmer waren folgende Personen eines mittelständischen Unternehmens eingeladen:
• PR- & Marketing-Referentin
• Projektingenieur im Bereich Logistik
• Projektingenieur im Bereich Produktionstechnik
• Projektingenieur im Bereich Informationssysteme
• Sekretärin
Der Ablauf von Interviews sah folgendermaßen aus:
Motivation Zunächst wurden Mashups und der Zweck von Web-Scrapern an Beispielen
erklärt. Es wurden Möglichkeiten der Einbindung von Informationen in digitale Karten wie bei Houston Crime Maps 1 (s. Abschnitt 2.3) anhand von
vorgefertigten Screenshots gezeigt. Es wurde berichtet, dass es auch MashupEditoren gibt, die für Benutzer ohne Programmierkenntnisse gedacht sind.
Web-Scraping wurde anhand von Beispielen der Extraktion von Informationen über Kunden, Produkte und Publikationen erläutert. Schließlich wurde
auch erklärt, dass per Web-Scraping extrahierte Daten mit anderen Quellen
in einem Mashup kombiniert, gefiltert und geordnet werden können.
1
http://houstoncrimemaps.com
44
Konzept Nachdem der Benutzer die Idee von Web-Scraping verstanden hat, wurde
ihm das Konzept dieser Arbeit vorgestellt. Es wurde erklärt, dass es darum
geht, über mehrere Webseiten einer Website verteilte Informationen und ggf.
deren Beziehungen zu extrahieren. Dabei wurde das Modell mit Ressourcen
und Attributen umgangssprachlich erläutert.
Szenario Das in Abschnitt 4.1 beschriebe Szenario wurde vorgestellt und anhand
von Mockups 2 durchgegangen. Die Mockups wurden davor für den gesamten Prozess als statische HTML-Webseiten ohne weitere Funktionalität erstellt. Dabei sollte der Benutzer laut denken und Anmerkungen, Kritik und
Verbesserungsvorschläge bezüglich der Bedienelemente und Formulierungen
machen.
Abschluss Der Benutzer berichtete, welchen Gesamteindruck er bekommen hat und
welche Änderungen er sich wünscht. Es wurde gefragt, ob sich der Benutzer vorstellen kann, DisRESTractor in seinem Berufsalltag oder für private
Zwecke einzusetzen.
5.2. Auswertung von Ergebnissen
Alle Personen konnten den Prozess bei der Arbeit mit DisRESTractor verstehen und
fanden die Idee des Konzeptes sehr nützlich. Ein Interview-Teilnehmer hat berichtet,
dass er oft auf der Website http://www.vdi.de3 nach Veranstaltungen wie Tagungen,
Seminaren und Konferenzen sucht. Dabei werden auf der entsprechenden Webseite mit
Suchergebnissen jeweils nur der Titel, der Veranstalter, der Ort und das Datum angezeigt. Der Interview-Teilnehmer möchte sich auch die Teilnahmegebühren sowie das
komplette Programm von Veranstaltungen anschauen. Dafür muss aber für jede Veranstaltung eine weitere Webseite besucht werden. Für diese Situation fand er den Einsatz
von DisRESTractor möglich.
Wenn man diese Idee weiterentwickelt, wäre eine zusätzliche Extraktion der Veranstaltungsinformationen auch von der Website http://www.vdma.org4 und eine spätere
Kombinationen der beiden Quellen in einem Mashup denkbar.
Ähnliche Ideen kamen von anderen Interview-Teilnehmern, die oft nach wissenschaftlichen Publikationen auf verschiedenen Websites suchen.
Der wichtigste Wunsch von allen fünf Teilnehmern war, die Begriffe Ressource und
Attribut in Objekt und Merkmal umzubenennen. Ebenfalls wurde die Formulierung
„andere Instanzen dieser Ressource“ nicht verstanden und nun in „weitere Objekte/Merkmale der gleichen Kategorie“ umbenannt.
Nicht alle Teilnehmer haben das Verhältnis zwischen einer Ressource und einem Attribut in DisRESTractor sofort verstanden. Deswegen wurde ein Hilfe-Dialog mit einer
2
Ein Mockup ist ein Prototyp der Benutzerschnittstelle einer zu entwickelnden Software ohne weitere
Funktionalität.
3
Verein Deutscher Ingenieure e.V.
4
Verband Deutscher Maschinen- und Anlagenbau e.V.
45
ausführlichen Erklärung und begleitenden Beispielen erstellt, der über das FragezeichenSymbol in der Info-Leiste jederzeit (auch gleich nach dem Start von DisRESTractor)
abrufbar ist. Dies soll insbesondere für diejenigen Benutzer hilfreich sein, die zum ersten
Mal mit DisRESTractor arbeiten.
Beim Auswählen von Daten auf einer Webseite haben sich die Teilnehmer eine Übersicht gewünscht, wie viele Elemente momentan markiert sind. Diese wird nun in der
Info-Leiste gegeben, falls die Auswahl nicht leer ist. Das vermeidet Situationen, in denen falsche Elemente markiert, aber in der aktuellen Ansicht nicht zu sehen sind, weil
die Webseite zu lang ist und zur Stelle mit falschen Elementen noch gescrollt werden
soll. Ohne diese Übersicht der markierten Elemente könnte man nicht relevante Informationen extrahieren.
Beim Hinzufügen von Ressourcen und Attributen haben die Probanden stets jeweils das
Feld Beschreibung ausgefüllt, obwohl sie das in einigen Fällen nicht für sinnvoll hielten,
da Ressourcen- und Attributennamen schon aussagekräftig genug waren. Deswegen wird
nun in Dialogen darauf hingewiesen, dass diese Felder optional sind.
Einige Formulierungen in der Info-Leiste wurden angepasst. Die Phrase „automatisch
getroffene Auswahl“ soll nun deutlich machen, dass sich das System richtig verhält,
indem weitere („ähnliche“) Elemente nach dem ersten Anklicken markiert werden. Die
Formulierung „zu einer anderen Seite dieser Site navigieren“ weist darauf hin, dass der
Benutzer z. B. von der Webseite mit Informationen über ein Foto zur Webseite mit
Besitzer-Informationen wechseln kann, aber auf dem Flickr -Portal bleiben soll.
Alle oben genannten Anmerkungen wurden berücksichtigt und umgesetzt. Im Beispielszenario aus Abschnitt 4.1 wurden diese Änderungen schon vorgenommen.
46
In diesem Kapitel wird es vorgestellt, wie das Konzept technisch umgesetzt wurde.
Zuerst wird die technische Plattform vorgestellt, die für die Implementierung von DisRESTractor verwendet wurde. Anschließend wird die Architektur von DisRESTractor
beschrieben. Dann wird der Ablauf der Arbeit mit DisRESTractor auf der technischen
Ebene vorgestellt. Schließlich wird der Aufbau des generierten Service gezeigt.
6.1. Technische Plattform
Nach der Aufgabenstellung muss DisRESTractor in Form einer Webanwendung implementiert werden. Dafür gibt es unter anderen zwei große Plattformen, und zwar Java
EE und .NET. Java EE steht für Java Platform, Enterprise Edition und ist eine Spezifikation der Softwarearchitektur für in Java programmierte (Web-)Anwendungen. .NET
ist ein Framework der Firma Microsoft und erlaubt mit seiner serverseitigen Technologie
ASP.NET die Entwicklung von Webanwendungen.
Die Beiden Plattformen sind sehr mächtig und haben verschiedene Vorteile und Nachteile. In dieser Arbeit wird Java EE v. 6 verwendet, weil es hersteller- und plattformunabhängig ist. .NET ist im vollen Umfang nur für Windows verfügbar und entsprechende
Werkzeuge werden nur von Microsoft bereitgestellt.
Java EE bietet viele Programmierschnittstellen an, insbesondere JAX-RS ([HS08]) für die
Entwicklung von REST-basierten Web-Services. Java EE-Applikationen erfordern einen
Applikationsserver als Laufzeitumgebung. Dafür gibt es viele Alternativen. In dieser
Arbeit wird der Open-Source-Server Apache Tomcat 1 v. 6.0.25 verwendet.
Zwei folgende Komponenten sind ein wichtiger Bestandteil der meisten Webanwendungen in Java EE:
Servlets sind Java-Klassen, deren Instanzen innerhalb eines Applikationsservers Anfragen von Clients entgegennehmen und beantworten.
JSP (Java Server Pages) sind HTML-Seiten, deren dynamische Teile durch den eingebetteten Java-Code erzeugt werden.
Eine gründliche Erklärung dieser Technologie gibt [Bri05].
Als Entwicklungsumgebung wird Eclipse IDE 2 eingesetzt. Sie unterstützt den Entwickler unter anderem beim Programmieren in Java und beim Erstellen von Webseiten und
erleichtert die Arbeit mit dem Applikationsserver, indem sie Webanwendungen automatisch auf dem Server installiert und bei jeder Änderung aktualisiert.
1
2
http://tomcat.apache.org/
47
Um die Benutzeroberfläche von DisRESTractor interaktiv zu gestalten sowie die Struktur von Webseiten im virtuellen Browser zu analysieren, wird JavaScript mit einem
Framework namens jQuery 3 eingesetzt. jQuery stellt sehr viele hilfreiche Funktionen
zur Verfügung, insbesondere:
• schnellere und leichtere Navigation im DOM-Baum von Webseiten
• Manipulation von Elementen im Dokument
• erweitertes System zur Ereignisbehandlung
• asynchrone HTTP-Anfragen per AJAX (s. Abschnitt 2.1)
• zahlreiche Plug-ins, unter anderem für die Erstellung von anspruchsvollen Benutzeroberflächen
Eine detaillierte Übersicht von Funktionen gibt [CS10]. In [Wel09] werden Plug-ins für
verschiedene Oberflächen-Komponenten wie Dialoge, Kalender, Tabs usw. beschrieben.
Für die Realisierung aller Dialoge in DisRESTractor zur Aufnahme, Änderung und Entfernung von Attributen und Ressourcen wurde der Plug-in jQuery UI Dialog 4 verwendet.
6.2. Architektur von DisRESTractor
Wie in Kapitel 4 bereits beschrieben wurde, muss ein Benutzer vor dem Start von
DisRESTractorzur Webseite mit gewünschten Inhalten gelangen. Nachdem er die entsprechende Webseite (ggf. mit Suchergebnissen) geöffnet hat, startet er DisRESTractor
über ein Bookmarklet (s. Abschnitt 2.1). Dieses führt den folgenden JavaScript-Code in
der aktuellen Webseite aus:
javascript:location.href=’http://example.org/DisRESTractor/?url=’
+escape(document.location.href)}
Es nimmt zuerst den URL der aktuellen Webseite (document.location.href), ersetzt
dessen Sonderzeichen (escape()) und leitet die aktuelle Webseite zu DisRESTractor
um, dem der grade modifizierte URL übergeben wird.
Die Ersetzung von Sonderzeichen ist unter anderem erforderlich, damit die URL-Parameter
der Webseite mit relevanten Daten richtig übertragen werden. Wenn der URL der Webseite z. B. http://example.com/musterportal/?param1=abc&param2=xyz lautet, würde DisRESTractor ohne escape-Funktion den url-Parameter als http://example.com/
musterportal/?param1=abc interpretieren, da das „&“-Zeichen zur Trennung von Parametern im URL eingesetzt wird. Somit würde im virtuellen Browser von DisRESTractoreine falsche Webseite geöffnet.
Abbildung 6.1 zeigt ganz grob die Architektur von DisRESTractor. Ein Benutzer definiert relevante Daten in DisRESTractor und lässt einen Web-Scraper generieren. Der
erzeugte Web-Scraper ist eine eigenständige Webanwendung, die unabhängig vom DisRESTractor läuft.
3
4
http://jquery.com/
http://docs.jquery.com/UI/Dialog
48
JSP
SelectorGadget
Datenmodell
DisRESTractor
Proxy
Ressource-Manager
C
l
i
e
n
t
S
e
r
v
e
r
Web-Scraper
Datenmodell
Abbildung 6.1.: Architektur von DisRESTractor
Auf der Client-Seite wird die grafische Benutzeroberfläche von DisRESTractor als JSP
in einem Webbrowser angezeigt. Ebenfalls auf der Client-Seite wird ein Datenmodell
erstellt, in das alle vom Benutzer hinzugefügten Ressourcen einfließen. Die Komponente SelectorGadget ermöglicht, die Auswahl des Benutzers automatisch zu erweitern
und für markierte Elemente einen XPath-Ausdruck zu ermitteln. Dies wird in weiteren
Abschnitten ausführlichen beschrieben.
Auf der Server-Seite hat DisRESTractor im Wesentlichen zwei Komponenten, die durch
Servlets realisiert werden:
Proxy lädt die Webseite mit gewünschten Inhalten (s. Abschnitt 6.3)
Ressource-Manager empfängt das im Client erstellte Datenmodell und generiert einen
Web-Scraper
Nachdem ein Service erstellt wurde, kann der Benutzer Informationen über ihn anfordern. Dabei enthält der Service das Datenmodell, das in DisRESTractor erzeugt wurde.
Gemäß diesem Datenmodell werden Informationen aus Webseiten extrahiert.
Im nächsten Abschnitt wird ein Problem beschrieben, das ganz am Anfang der Implementierung aufgetreten ist und die Verwendung eines Proxy erforderlich macht.
6.3. Same origin policy
Die Benutzeroberfläche von DisRESTractor wird durch eine JSP-Seite repräsentiert. Der
in Kapitel 4 beschriebene virtuelle Browser wird mit Hilfe eines Inlinefames innerhalb
der JSP-Seite realisiert. Ein Inlineframe ist ein HTML-Element, das es erlaubt, innerhalb
einer Webseite Inhalte einer anderen Webseite als selbstständiges HTML-Dokument einzubinden.
49
Alle Benutzeraktionen wie Klicks auf relevante Daten und Navigation werden im virtuellen Browser per JavaScript überwacht. Außerdem wird JavaScript für die Anpassung
der Oberfläche – z. B. für die Markierung der Elemente und (De-)Aktivierung von Links
im virtuellen Browser – eingesetzt.
Allerdings wird die Verwendung von JavaScript in im Zusammenhang mit Inlineframes durch die sogenannte Same Origin Policy – die Richtlinie der gleichen Herkunft –
untersagt. Diese Richtlinie wird in allen heutigen Webbrowsern angewendet und stellt
sicher, dass keine Kommunikation per JavaScript oder andere Script-Sprachen zwischen
Webseiten stattfindet, wenn diese nicht der gleichen Herkunft sind. Dies betrifft auch
die Kommunikation zwischen einer übergeordneten (DisRESTractor) und einer (im virtuellen Browser) eingebetteten Webseite.
Die Herkunft einer Webseite wird über die Kombination aus Protokoll (z. B. HTTP),
Domain (z. B. example.org) und Port (z. B. 8080) im URL definiert. So kann z. B. von
der Webseite http://example.org auf keine der folgenden Webseiten per JavaScript
zugegriffen werden:
• https://example.org
• http://example.com
• http://example.org:8080
Ein Zugriff von http://example.org/1.html auf http://example.org/2.html und
http://example.org/xyz/3.html ist aber durchaus möglich.
Diese Richtlinie verhindert, dass z. B. Login-Daten über fremde Skripte gestohlen werden. Diese Richtlinie steht aber vielen Entwicklern im Wege, insbesondere im Zusammenhang mit Mashups, in denen verschiedene Quellen kombiniert werden. In [DKBS+ 08]
wird ein Modell vorgestellt, dass die Kommunikation zwischen zwei Domains erlaubt,
die einander vertrauen. Das wird in DisRESTractor nicht erfüllt, da es keine Ansprüche
erheben kann, von irgendeinem Portal wie Flickr freigegeben zu werden. Außerdem lässt
dieses Modell keinen Zugriff auf die DOM-Struktur von Webseiten zu. In DisRESTractor
ist das aber eine der wichtigsten Voraussetzungen, da die Struktur der Webseiten sowie
die Navigation auf der Website überwacht und analysiert werden, um die Position von
relevanten Daten zu ermitteln.
Um die Same Origin Policy umzugehen, wurde in DisRESTractor ein Proxy-Servlet
erstellt, das die Original-Webseite lädt und diese an DisRESTractor weitergibt, so dass
im Webbrowser die beiden Webseiten – DisRESTractor und die im virtuellen Browser
eingebettete Webseite – die gleiche Herkunft haben.
6.4. Dialog mit DisRESTractor zur Definition von
Ressourcen
Das Sequenzdiagramm in Abbildung 6.2 zeigt den Ablauf der Arbeit in DisRESTractor
und verfeinert das Aktivitätsdiagramm aus dem Abschnitt 4.2.2 auf Seite 37.
50
Web-Browser
Benutzer
loop
[solange noch relevante Daten auf der gesamten Website vorhanden]
loop
[solange noch relevante Daten
auf der aktuellen Webseite vorhanden]
Element wählen()
ähnliche Elemente vorschlagen()
Attribut hinzufügen()
Datenmodell erweitern()
Benutzerobefläche aktualisieren()
opt
ProxyServlet
Link anklicken()
Webseite anfordern(URL)
relative URLs in absolute
umwandeln()
html
SelectorGadget in neue Webseite laden()
RessourcenManagementServlet
Service erzeugen()
Service erzeugen(Datenmodell)
URL des erzeugten Service
zur Service-Dokumentation umleiten()
Abbildung 6.2.: Sequenzdiagramm mit dem Ablauf in DisRESTractor
51
Solange es relevante Daten auf der gesamten Website gibt, wiederholt der Benutzer eine
der folgenden zwei Aktionen:
• Auswahl und Hinzufügen von Attributen (einer neuen oder vorhandenen Ressource), solange es Informationen auf der aktuellen Webseite gibt,
• Navigation zu einer anderen Webseite dieser Website.
Bei der Navigation werden alle Benutzeraktionen abgefangen. Wenn der Benutzer einen
Link im virtuellen Browser anklickt, wird ein normales Verhalten im Browser, also eine HTTP-Anfrage an den entsprechenden Server abgebrochen und an Proxy-Servlet
umgeleitet. Dieses lädt die angeforderte Webseite vom Server herunter und gibt den
Quellcode an den Webbrowser weiter. Dabei werden alle relative URLs in Links und
Pfaden zu Bildern in absolute umgewandelt.
Wie man im Diagramm sieht, wird die Selektion von Elementen, die Vorhersage ähnlicher
Elemente und die Aufnahme von Attributen im Webbrowser ohne Kommunikation mit
dem Server durchgeführt. Dieser Teil wird in JavaScript mit jQuery programmiert. Das
beschleunigt vor allem die Arbeit mit DisRESTractor, indem unnötige Wartezeiten auf
die Antwort des Servers vermieden werden.
Wenn der Benutzer ein Element anklickt, wird eine Menge ähnlicher Elemente vorgeschlagen und deren Position wird in einem XPath-Ausdruck erfasst. Das ist ein aufwändiger Prozess, daher wurde dafür nach einer vorhandenen Lösung gesucht. Ein Werkzeug,
das diese Funktionen übernimmt, heißt SelectorGadget 5 . Es wurde dafür entwickelt,
einen Selektor für eine Menge von Elementen anhand deren CSS-Klassen und Position
im DOM-Baum zu ermitteln. Dieser Selektor kann in einen XPath-Ausdruck umgewandelt
werden.
SelectorGadget wurde ursprünglich als ein eigenständiges Werkzeug programmiert, das
(wie DisRESTractor) über ein Bookmarklet gestartet werden kann. Für DisRESTractor
wurde es angepasst und wird jetzt in jede Webseite im virtuellen Browser automatisch
eingebunden.
Alle Informationen, die der Benutzer als Attribute hinzufügt, werden in ein Datenmodell gemäß dem Metamodell aus dem Abschnitt 4.2.1 abgebildet. Dieses Modell wird
zuerst auf der Client-Seite in JavaScript erstellt. Die Datenstruktur einer Ressource
bleibt gleich. Die entsprechende Datenstruktur eines Attributes enthält dabei folgende
Informationen:
• Name, Beschreibung, Typ, URL und XPath wie im Metamodell definiert.
• id ein eindeutiger Identifikator des Attributes.
• path enthält den Pfad zur Webseite, auf der sich das Attribut befindet.
• isMultiple gibt an, ob dieses Attribut für eine Ressourcen-Instanz mehrmals
vorkommt (wie das Attribut Schlüsselwort aus dem Beispielszenario).
• links die Menge aller Links (Attributwerte), die bei der Arbeit mit DisRESTractor gefunden wurden, wenn dieses Attribut überhaupt verlinkt ist.
• isRemoved gibt an, ob das Attribut vom Benutzer entfernt wurde.
5
http://www.selectorgadget.com/
52
Alle Bestandteile dieser Datenstruktur sind nötig, um die Navigation des Benutzers
später im Service rekonstruieren zu können. So ermöglichen es IDs, die Reihenfolge zu
speichern, in der einzelne Attribute hinzugefügt wurden. Das Feld path enthält den Pfad
zur Webseite mit dem Attribut, der möglichst über andere Attribute definiert wird. Der
Pfad enthält eine Menge von sogenannten Attribut-Links. Jeder Attribut-Link enthält
folgende Daten enthält:
pageOfAttribute: int id des Attributes, das auf der aktuellen Webseite vorhanden
ist, und -1, falls sich kein vorhandenes Attribut auf der Webseite befindet.
linkOfAttribute: int id des verlinkten Attributes, das angeklickt wurde, um zur
aktuellen Webseite zu gelangen, und -1 andernfalls.
url: string URL der aktuellen Webseite.
contentOfUrl: string Inhalt des Elementes, das diese Webseite verlinkt.
Der Pfad wird bei jedem Webseiten-Wechsel zu einer noch nicht besuchten Webseite um
einen Attribut-Link erweitert. Beim Hinzufügen eines Attributes wird der Pfad im pathFeld dieses Attributes gespeichert und die entsprechende Datenstruktur wird wieder
zurückgesetzt. Der Pfad zum nächsten Attribut beginnt also auf der Webseite des zuletzt
hinzugefügten Attributes.
So enthält das erste Attribut Foto aus dem Anwendungsszenario in Abschnitt 4.1 nur
den URL im Attribut-Link, da es noch keine anderen Attribute vorhanden sind und kein
Link existiert ist, der zur aktuellen Webseite führt.
Wenn man das zweite Attribut (Fotograf ) auf derselben Webseite einträgt, enthält das
entsprechende Attribut-Link die id des ersten Attributes im pageOfAttribute-Feld. So
kann man später im Service feststellen, dass die beiden Attribute auf derselben Webseite
sind, und die Webseite nicht doppelt geladen werden muss. Wenn man im allgemeinen
Fall über das Globus-Symbol neben Attributen im Ressourcen-Panel navigiert, wird das
Feld pageOfAttribute im Attribut-Link sofort gesetzt.
Wenn man das erste Attribut Foto (das erste Bild in der Ergebnismenge der Bilder)
nun anklickt, um zur Webseite zu gelangen, auf der sich das potenzielle Attribut Aufnahmedatum befindet, wird der Pfad um einen Attribut-Link erweitert, der die id des
ersten Attributes im linkOfAttribute enthält. Hätte man nur den URL dieser Webseite
gespeichert, wüsste man nicht mehr, wie man zum Aufnahmedatum des zweiten Bildes
kommt. Eine Alternative wäre, die URLs der beiden Attribute zu analysieren und Gesetzmäßigkeiten darin zu finden. Das ist aber nicht immer möglich. Deswegen wird die
Navigation des Benutzers später im Service über Klicks auf vorhandenen Attributen
verfolgt.
Wenn ein Link angeklickt wurde, der in keinem vorhandenen Attribut enthalten ist,
wird bei der Verfolgung im Service versucht, einen Link mit dem gleichen Inhalt zu
finden. Bei Flickr heißen die Links, die vom Foto aus über eine weitere Webseite zu
Informationen über den Benutzer führen, immer Profil. Wenn man den Text aller Links
auf der vorherigen Webseite analysiert, kommt man auf die gewünschte Webseite.
Es kann aber auch sein, dass mehrere Links auf einer Webseite gleich heißen, z. B.
Beschreibung einer Ware in der Ergebnisliste in einem Online-Shop. Dann müssen URLs
analysiert werden und anhand weiterer Kriterien wie Position auf der Webseite ermittelt
werden.
53
6.5. Generierung und Installation des Service
Wenn der Benutzer alle relevanten Informationen erfasst hat, kann er einen Web-Scraper
generieren lassen. Dabei werden als erstes die in JavaScript erstellten Datenstrukturen
vom Webbrowser an Ressource-Management-Servlet übermittelt. Auf der Server-Seite
werden die gleichen Datenstrukturen in Java erzeugt.
Der Vorteil daran, dass man zuerst das Datenmodell in JavaScript erstellt, besteht darin,
dass man gesammelte Informationen generell einem beliebigen Server übergeben kann,
der sie behandelt. Das könnte im Allgemeinen auch ein Server der .NET-Plattform sein.
Auf dem Server befindet sich innerhalb von DisRESTractor ein nicht kompiliertes Projekt des künftigen Service. Wenn DisRESTractor das fertige Datenmodell vom Webbrowser bekommen hat, initialisiert es das Datenmodell des Service mit den erhaltenen
Informationen, kompiliert dieses Projekt und installiert es auf demselben Server. Dieses eingebettete Projekt bleibt immer erhalten. Nur das Datenmodell wird vor jedem
Erzeugen eines Web-Scrapers neu geladen.
Eine Kompilierung und Installation des neuen Projektes DisRESTractorzur Laufzeit
macht das Werkzeug namens Apache Ant 6 möglich. Es ist zur Automatisierung beliebiger Abläufe bei der Software-Entwicklung (vor allem im Java-Umfeld) gedacht. Diese
Abläufe müssen in einer Skript-Datei im XML-Format definiert werden. Standardmäßig
heißt sie build.xml. Das entsprechende Skript für die Kompilierung und Installation
des Service aus dem DisRESTractor findet man im Anhang in Abschnitt A.1.
6.6. Architektur des Service
Der generierte Service ist eine Webanwendung, die nach REST-Prinzipien aufgebaut ist.
Abbildung 6.3 zeigt die Klassenstruktur des Service. Die Getter- und Setter- sowie Hilfsmethoden werden übersichtlichkeitshalber nicht angezeigt.
Das Paket structures enthält die Datenstrukturen, die auch auf der Client-Seite von
DisRESTractor erzeugt und mit Informationen gefüllt werden.
Das Paket scraping enthält folgende Klassen:
• ResourcesInitializer: der Quellcode dieser Klasse wird von DisRESTractor generiert. Die Klasse baut die Datenstrukturen auf, die in DisRESTractor erzeugt
wurden.
• Wrapper: extrahiert Informationen aus Webseiten gemäß dem Datenmodell, das
die Klasse ResourcesInitializer bereitstellt.
Die Klasse Wrapper hat drei wichtige Methoden:
• getResourceList bekommt einen Ressourcennamen als Parameter und liefert eine
Listenressource im XML-Format (wie in Listing 4.2 auf Seite 42).
6
http://ant.apache.org/
54
service
structures
AttributeLink
ResourcePresentation
+getResourceList(resourceName:String): String
+getResourceByNumber(resourceName:String,
number:int): String
+getServiceDescription(): String
-pageOfAttribute: int
-linkOfAttribute: int
-url: String
-linkContent: String
1..*
Attribute
scraping
Wrapper
-resources: Resource[]
+getResourceList(resourceName:String): String
+getResourceByNumber(resourceName:String,
number:int): String
+getServiceDescription(): String
ResourcesInitializer
-id: int
-name: String
-description: String
-type: String
-xpath: String
-multiple: boolean
-removed: boolean
-value: String
1..*
Resource
+serviceName: String
+serviceDescription: String
-resources: Resource[]
-id: int
-name: String
-description: String
-url: String
-attributeOf: int
+getResources(): Resource[]
Abbildung 6.3.: Klassenstruktur des generierten Service
• getResourceByNumber erhält einen Ressourcennamen sowie eine Nummer und gibt
die entsprechende Ressource im XML-Format (wie in Listing 4.1 auf Seite 42) zurück.
• getServiceDescription liefert eine Beschreibung des Service als HTML.
Um Webseiten mit relevanten Informationen herunterzuladen und Informationen daraus zu extrahieren, wird das Werkzeug namens HtmlUnit 7 verwendet. Dieses ist für die
Modellierung von HTML-Dokumenten gedacht. Es erlaubt, Webseiten herunterzuladen,
darin zu navigieren, Links anzuklicken etc. Insbesondere können XPath-Ausdrücke verwendet werden, um das Dokument anzufragen. HtmlUnit erleichtert es, die Navigation
des Benutzers gemäß dem erzeugten Datenmodell zu rekonstruieren.
Die Methode getResourceList sammelt lediglich das erste Attribut einer Ressource,
um die Anzahl der Instanzen zu ermitteln. Anhand dieser Anzahl wird eine ListenRessource als XML erzeugt, die Links zu den einzelnen Ressourcen enthält (s. Listing 4.2
auf Seite 42). Dieses XML-Dokument wird als String zurückgegeben.
In der Methode getResourceByNumber wird die Navigation des Benutzers verfolgt, um
alle Informationen zu extrahieren. Als Antwort liefert die Methode ein XML-Dokument
im String-Format.
Die Methode getServiceDescription lädt keine Webseiten herunter, sondern erzeugt
eine Dokumentation (in Prosa) zum Service gemäß einem vorhandenen Datenmodell.
7
http://htmlunit.sourceforge.net/
55
Diese liefert ein HTML-Dokument, zu dem der Benutzer nach dem Abschluss der Arbeit
mit DisRESTractor umgeleitet wird.
Das Paket service enthält eine einzige Klasse ResourcePresentation, die die HTTPAnfragen von Clients entgegennimmt und beantwortet. Dafür ruft sie die gleichnamigen
Methoden der Klasse Wrapper auf. Diese Klasse macht den Service REST-konform. Hier
werden Pfade im URL definiert und Ressourcen im einem bestimmten Format geliefert.
Das wird mittels des Frameworks Jersey8 realisiert. Die Methode getResourceByNumber ist im folgenden Listing zu sehen:
1
2
3
4
5
6
7
8
@GET
@Path("/{resourceName}/{number}")
@Produces("application/xml")
public String getResourceByNumber(
@PathParam("resourceName") String resourceName,
@PathParam("number") int number) {
return wrapper.getResourceByNumber(resourceName, number);
}
Listing 6.1: Die Methode getResourceByNumber()
Die Annotation GET gibt an, dass diese Methode auf GET-Anfragen reagiert, dessen URL
mit dem Muster /resourceName/number endet. Teile des URL werden zu Parametern
der Methode. Die Annotation @Produces(“application/xml“) definiert ein AusgabeFormat – in diesem Fall XML.
Eine weitere Funktionalität des Jersey-Frameworks ist eine automatische Erzeugung
von WADL-Dokumentation zum Service. Abgefragt kann diese über die HTTP-Methode
OPTIONS an den Service. Die WADL-Dokumentation zum im Anwendungsszenario in Abschnitt 4.1 erstellen Service kann im Anhang in Abschnitt A.2 gefunden werden.
8
https://jersey.dev.java.net/
56
7.1. Zusammenfassung
Im Rahmen dieser Arbeit wurde ein Konzept entwickelt, das einen Benutzer ohne Programmierkenntnisse befähigt, Web-Services zur Datenextraktion aus Webseiten, auch
Web-Scraper genannt, im Dialog mit DisRESTractor – der Webanwendung, die dieses
Konzept implementiert – visuell zu erstellen. In Anlehnung an den Architekturstil REST,
nach dessen Prinzipien das World Wide Web aufgebaut ist, werden Informationen in
Form von Ressourcen extrahiert. Das durch diese Arbeit adressierte Hauptproblem ist
die Tatsache, dass Ressourcen über mehrere Webseiten innerhalb einer Website verteilt
sein und in Beziehung miteinander stehen können.
Am Anfang der Arbeit wurde gezeigt, welche Vorteile eine automatische Datenextraktion
bringt und warum eine visuelle Erstellung von Web-Scrapern wichtig ist. Anschließend
wurde die Aufgabe vorgestellt.
In Kapitel 2 wurde die Struktur von Webseiten beschrieben. Dabei wurden unter anderem das Document Object Model, CSS und AJAX erklärt, die für eine Datenextraktion
von enormer Bedeutung sind.
Anschließend wurden Mashups vorgestellt, bei deren Entwicklung immer häufiger RESTServices verwendet werden. Daraufhin wurde REST vorgestellt – ein Architekturstil für
verteilte Webanwendungen, der insbesondere für die Erstellung leichtgewichtiger ressourcen-orientierter Web-Services geeignet ist. Dabei wurden die wichtigsten REST-Prinzipien erklärt. Weiterhin wurde ein Vergleich der Ansätze bei der Entwicklung von RESTbasierten Services und Web-Services im SOAP-Stil durchgeführt.
Am Ende des Kapitels 2 wurde Web-Scraping definiert, und verschiedene Extraktionstechniken wurden vorgestellt.
Kapitel 3 hat einige wissenschaftliche Arbeiten auf dem Gebiet der Informationsextraktion vorgestellt. Anschließend wurden kommerzielle Produkte präsentiert. Unter anderen
wurde Lixto Visual Developer 1 – eines der mächtigsten Werkzeuge für die visuelle Erzeugung von Web-Scrapern – beschrieben. Es unterstützt offene Standards wie XML, HTML,
CSS und XPath, bietet eine ansprechende Entwicklungsumgebung, die auf dem Eclipse
IDE 2 Framework basiert und die Webbrowser-Engine von Mozilla 3 integriert. Es besitzt
eine eigene Extraktionssprache und ermöglicht eine Ausgabe von extrahierten Daten in
vielen Formaten. Allerdings erfordert Lixto Visual Developer entsprechende technische
Kenntnisse und ist somit nicht für Benutzer ohne Programmierkenntnisse geeignet.
1
http://www.lixto.de/lixto_visual_developer/
3
http://www.mozilla.org/
2
57
Dann wurde ein anderes Werkzeug namens Dapper vorgestellt, das für Benutzer ohne
technischen Hintergrund gedacht ist, aber im Vergleich zu Lixto Visual Developer nicht
annähernd so mächtig ist.
In Kapitel 4 wurde das Konzept von DisRESTractor beschrieben. Zuerst wurde ein
Beispielszenario entworfen, in dem eine Person mit Hilfe von DisRESTractor einen WebScraper erstellt. Um die im Dialog mit DisRESTractor erhobenen Anforderungen an den
Web-Scraper von dessen Implementierung zu trennen, wird während der Arbeit mit DisRESTractor ein Datenmodell erstellt. Ein Metamodell für solche Datenmodelle wurde
ebenfalls in diesem Kapitel vorgestellt. Anschließend wurden der Ablauf bei der Arbeit
mit DisRESTractor sowie generierte Services beschrieben. Jeder erzeugte Service wird in
einer benutzerfreundlichen Form auf einer Webseite dokumentiert. Als Ausgabeformat
für extrahierte Daten wurde XML gewählt, da es ermöglicht, Informationen einfach zu
strukturieren.
Um das entwickelte Konzept vor der Implementierung auf seine Bedienbarkeit und Eignung für Benutzer ohne Programmierkenntnisse zu testen, wurde eine Evaluation in
Form von Interviews durchgeführt. Als Teilnehmer wurden Personen ausgewählt, die
zwar keine technischen Kenntnisse besitzen, aber das Internet in ihrem Arbeitsalltag
nutzen und somit in der Lage sind, Vorteile der Datenextraktion zu verstehen. Alle Teilnehmer fanden das Konzept verständlich und konnten sich vorstellen, DisRESTractor
einzusetzen. Es wurden sogar weitere Anwendungsszenarios entworfen. Während der Interviews wurden viele Verbesserungsvorschläge gemacht, die vorher nicht bedacht und
nach der Evaluation ins Konzept einbezogen wurden. Die Evaluation und ihre Ergebnisse
sind in Kapitel 5 beschrieben.
Kapitel 6 hat die Implementierung des entwickelten Konzeptes in Form einer Webanwendung vorgestellt. Als technische Plattform wurde Java Platform, Enterprise Edition
gewählt, da sie nicht nur betriebssystemunabhängig ist, sondern viele Programmierschnittstellen zur Verfügung stellt – unter anderem für die Bearbeitung von XML, die
Entwicklung von REST-basierten Services sowie das Kompilieren anderer Anwendungen
zur Laufzeit und deren Installation auf einem Web-Server.
Anschließend wurde die Architektur von DisRESTractor beschrieben. Dann wurde auf
ein Problem eingegangen, das am Anfang der Implementierung aufgetreten ist, und zwar
die Same Origin Policy – die Richtlinie der gleichen Herkunft. Diese Richtlinie verhindert eine Kommunikation zwischen zwei Webseiten, die von verschiedenen Domains
stammen. Somit können keine Interaktionen des Benutzers mit Webseiten, aus denen
Informationen extrahiert werden müssen, innerhalb von DisRESTractor überwacht werden. Weiterhin kann die Struktur dieser Webseiten nicht analysiert werden, was jedoch
für Web-Scraping unabdingbar ist. Als Lösung wurde ein Proxy programmiert, der die
vom Benutzer angeforderten Webseiten herunterlädt und an DisRESTractor in der Form
weitergibt, als ob diese von DisRESTractor selbst stammen.
Danach wurde der Dialog mit DisRESTractor technisch beschrieben, und die Generierung und Installation des Service auf dem Web-Server erklärt. Zum Schluss wurde die
Architektur des generierten Service präsentiert. Dank der Verwendung des Frameworks
Jersey war die Beschreibung des Service im maschinenlesbaren Format WADL möglich.
58
7.2. Ausblick
Im Folgenden wird beschrieben, welche Vorteile DisRESTractor gegenüber anderen
Werkzeugen bring und wie es eingesetzt werden kann. Anschließend werden Probleme genannt, die im Rahmen dieser Arbeit nicht gelöst wurden. Zu diesen Problemen
werden Erweiterungsmöglichkeiten des Konzeptes diskutiert.
Das in dieser Arbeit entwickelte Konzept und seine Implementierung erweitern die in
Kapitel 3 beschriebenen Konzepte und die zurzeit auf dem Markt verfügbaren Werkzeuge wie Dapper, indem Informationen in Form von Ressourcen mit einer Semantik
aus mehreren Webseiten inklusive ihrer Beziehungen extrahiert werden können. Eine
derartige webseitenübergreifende Extraktion war bisher nur in Lixto Visual Developer
möglich und somit einem Benutzer ohne technische Kenntnisse nicht zugänglich. DisRESTractor eignet sich gut für Szenarien, die in Abschnitten 4.1 und 5.2 vorgestellt
wurden.
Leider kann nicht immer sichergestellt werden, dass der erzeugte Service richtige Informationen liefert, da die Position von Elementen einer Webseite nicht immer exakt
ermittelt werden kann. Das verwendete Werkzeug SelectorGadget erzeugt oft XPathAusdrücke, die überflüssige Informationen liefern, die der Benutzer explizit abgewählt
hat. Für solche Fälle wäre eine zusätzliche Beschreibung mit Verwendung von regulären
Ausdrücken denkbar. Da jedoch Benutzer ohne technische Kenntnisse vorausgesetzt werden, muss es untersucht werden, in welcher Form reguläre Ausdrücke für Endbenutzer
zugänglich gemacht werden könnten. Es kommt auch vor, dass manche XPath-Ausdrücke
zu spezifisch sind und Informationen anhand von CSS-IDs beschreiben, was oft zur Folge
hat, dass keine Informationen aus anderen Webseiten nach dem vom Benutzer vorgegebenen Muster extrahiert werden können.
Im Rahmen dieser Arbeit generierte Services liefern Daten aus Webseiten, ohne diese zu
filtern oder zu erweitern. Es kommt aber vor, dass einerseits extrahierte Informationen
auch nicht relevante Daten enthalten, und andererseits wäre eine Möglichkeit von Vorteil,
die Informationen durch eigene Inhalte zu ergänzen. Man könnte also den Web-Service
so erweitern, dass auch das Hinzufügen, Aktualisieren und Löschen von Daten möglich
wären. Inhalte der ursprünglichen Webseite dürfen bzw. können dabei oft nicht geändert
werden, daher könnte dies virtuell über einen Proxy erfolgen.
Das in dieser Arbeit erstellte Konzept sieht keine Möglichkeit vor, erzeugte Web-Scraper
zu ändern. Somit können diese unbrauchbar werden, wenn sich die Struktur der ursprünglichen Webseite(n) ändert. Dieser Punkt kann weiter untersucht werden, um erstellte Services gegenüber solchen Änderungen flexibel zu machen.
Das Konzept behandelt die Extraktion von Daten, die beim ersten Laden einer Webseite
zur Verfügung stehen. Es können aber weitere Informationen per AJAX4 nachgeladen
werden. So erscheinen bei Flickr 5 weitere Informationen über ein Foto, wenn man mit
der Maus über einen bestimmten Bildbereich fährt. Andere Werkzeuge wie Mozenda
können auch solche Informationen extrahieren.
4
5
AJAX steht für Asynchronous JavaScript and XML
http://www.flickr.com
59
Bei der Implementierung des Konzeptes wurde die Paginierung nicht berücksichtigt.
Eine Parameterübergabe an die Suchformulare der Quell-Webseiten ist ebenfalls nicht
realisiert. Somit ist die Extraktion von Daten aus einer Webseite, die eine Anmeldung
erfordert, nicht möglich. Das wurde in anderen Werkzeugen bereits implementiert und
ist nicht der Teil dieser Arbeit.
Einerseits bietet DisRESTractor einem Benutzer ohne Programmierkenntnisse gute Möglichkeiten, Daten zu extrahieren. Andererseits ist damit eine präzise Definition von zu
extrahierenden Daten in vielen Fällen nicht möglich. Das Gebiet der semi-automatischen
Generierung von Web-Scrapern kann weiter untersucht werden, um eine volle Kontrolle
über die zu extrahierenden Informationen zu haben, ohne dabei technische Kenntnisse
zu besitzen.
60
A. Anhang
A.1. Ant-Skript zur Generierung und Installation des
Service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<project name="serviceProject" default="war" basedir=".">
<property name="webInfDir" value="./WEB−INF" />
<property name="classesDir" value="./WEB−INF/classes" />
<property name="libDir" value="./WEB−INF/lib" />
<target name="clean" description="entfernt␣das␣classes−Verzeichnis␣und␣
vorhandene␣war−Dateien">
<delete includeEmptyDirs="true">
< fileset dir="${classesDir}" includes="∗∗/∗" />
< fileset dir=".">
<include name="∗.war" />
</ fileset >
</delete>
</target>
<target name="init" description="erstellt␣das␣classes−Verzeichnis">
<mkdir dir="${classesDir}" />
</target>
<target name="compile" depends="clean" description="kompiliert␣alle␣java−
Dateien">
<javac srcdir="src" destdir="${classesDir}" debug="true" deprecation="true">
<classpath>
<pathelement path="${java.class.path}" />
< fileset dir="${libDir}">
<include name="∗∗/∗.jar" />
</ fileset >
</classpath>
</javac>
</target>
<target name="war" depends="compile" description="erzeugt␣eine␣war−Datei">
<war destfile="${warFileName}.war" webxml="${webInfDir}/web.xml">
<lib dir="${libDir}">
<include name="∗∗/∗.jar" />
</lib>
<classes dir="${classesDir}" />
</war>
61
A. Anhang
34
35
36
37
38
</target>
<target name="install" depends="war" description="installiert␣den␣Service␣auf␣
dem␣Tomcat−Server">
<copy file="${warFileName}" todir="${tomcatAppDir}"/>
</target>
</project>
Listing A.1: Ant-Skript zur Generierung und Installation des Service
A.2. WADL-Dokumentation zum generierten Service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<?xml version="1.0" encoding="UTF−8" standalone="yes"?>
<application xmlns="http://research.sun.com/wadl/2006/10">
<doc xmlns:jersey="http://jersey.dev.java.net/" jersey:generatedBy="Jersey:␣1.1.5
␣01/20/2010␣03:55␣PM" />
<resources base="http://localhost:8080/Maschsee−Bilder/">
<resource path="service/">
<method name="GET" id="getServiceDescription">
<response>
<representation mediaType="text/html" />
</response>
</method>
<resource path="/{resourceName}">
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" type="xs:string"
style ="template" name="resourceName" />
<method name="GET" id="getResourceList">
<response>
<representation mediaType="application/xml" />
</response>
</method>
</resource>
<resource path="/{resourceName}/{number}">
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" type="xs:int"
style ="template" name="number" />
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" type="xs:string"
style ="template" name="resourceName" />
<method name="GET" id="getResourceByNumber">
<response>
<representation mediaType="application/xml" />
</response>
</method>
</resource>
</resource>
</resources>
</application>
Listing A.2: WADL-Dokumentation zum generierten Service
62
Abkürzungsverzeichnis
AJAX
Asynchronous JavaScript and XML
API
Application Programming Interface
ASP
Active Server Pages
BPEL
Business Process Execution Language
CAPTCHA
Completely Automated Public Turing test to tell Computers and Humans Apart
CSS
Cascading Style Sheets
CSV
Comma Separated Values
DisRESTractor
Distributed Resources Extractor
DOM
Document Object Model
FTP
File Transfer Protocol
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
Java EE
Java Platform, Enterprise Edition
JAX-RS
Java API for RESTful Web Services
JSON
JavaScript Object Notation
JSP
JavaServer Pages
REST
Representational State Transfer
RSS
Really Simple Syndication in Version 2.0
SOA
Service-orientierte Architekturen
SOAP
Ursprünglich Simple Object Access Protocol
UDDI
Universal Description, Discovery and Integration
URI
Uniform Resource Identifier
63
A. Anhang
URL
Uniform Resource Locator
URN
Uniform Resource Name
UTF-8
8-bit Unicode Transformation Format
W3C
World Wide Web Consortium
WADL
Web Application Description Language
WSDL
Web Services Description Language
WWW
World Wide Web
XHTML
Extensible HyperText Markup Language
XML
Extensible Markup Language
XML-RPC
XML Remote Procedure Call
XPath
XML Path Language
XQuery
XML Query Language
XSLT
Extensible Stylesheet Language Transformation
64
[BFG01]
Baumgartner, Robert ; Flesca, Sergio ; Gottlob, Georg: Visual Web
Information Extraction with Lixto. In: VLDB VLDB 2001, Proceedings of
27th International Conference on Very Large Data Bases, September 11-14,
2001, Roma, Italy, 2001, 119-128
[BGH09]
Baumgartner, Robert ; Gottlob, Georg ; Herzog, Marcus: Scalable
Web Data Extraction for Online Market Intelligence. In: PVLDB 2 (2009),
Nr. 2, 1512-1523. http://www.vldb.org/pvldb/2/vldb09-1075.pdf. –
Zuletzt abgerufen am 14.04.2010
[BL07]
Booth, David ; Liu, Canyang K.: Web Services Description Language (WSDL) Version 2.0 Part 0: Primer. World Wide Web Consortium,
Recommendation REC-wsdl20-primer-20070626. http://www.w3.org/TR/
2007/REC-wsdl20-primer-20070626. Version: June 2007. – Zuletzt abgerufen am 14.04.2010
[Bri05]
Bridgewater, David: Sun Certified Web Component Developer Study
Guide (Exams 310-081 & 310-082) (Oracle Press). 1. McGraw-Hill Osborne
Media, 2005. – ISBN 9780072258813
[CB10]
Ceri, Stefano ; Brambilla, Marco: Search Computing: Challenges and
Directions (Lecture Notes in Computer Science / Information Systems and
Applications, incl. Internet/Web, and HCI). 1st Edition. Springer, 2010. –
ISBN 9783642123092
[CCHZ08]
Carl, Denny ; Clausen, Jörn ; Hassler, Marco ; Zund, Anatol: Mashups
programmieren. 1. O’Reilly, 2008. – ISBN 9783897217584
[CS10]
Chaffer, Jonathan ; Swedberg, Karl: jQuery 1.4 Reference Guide. Packt
Publishing, 2010. – ISBN 9781849510042
[DKBS+ 08] De Keukelaere, Frederik ; Bhola, Sumeer ; Steiner, Michael ; Chari,
Suresh ; Yoshihama, Sachiko: SMash: secure component model for crossdomain mashups on unmodified browsers. In: WWW ’08: Proceeding of the
17th international conference on World Wide Web. New York, NY, USA :
ACM, 2008. – ISBN 978–1–60558–085–2, S. 535–544
[FGM+ 99] Fielding, R. ; Gettys, J. ; Mogul, J. ; Frystyk, H. ; Masinter, L.
; Leach, P. ; Berners-Lee, T.: RFC 2616: Hypertext transfer protocol –
HTTP/1.1. http://www.ietf.org/rfc/rfc2616.txt. Version: 6 1999. –
[Fie00]
Fielding, Roy T.: Architectural Styles and the Design of Network-based
Software Architectures, University of California, Irvine, Diss., 2000. http:
65
//www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. – Zuletzt
abgerufen am 14.04.2010
[Ger08]
Gerhardt, Chris: Enterprise Mashups. Ein Beitrag zum Seminar „Social
Software Engineering“. http://sse08.pbworks.com/f/gerhardt_sse08_
final.pdf. Version: 2008. – Zuletzt abgerufen am 14.04.2010
[Goe05]
Goetz, Brian: Java theory and practice: Screen-scraping with XQuery. http://www.ibm.com/developerworks/java/library/j-jtp03225.
html. Version: March 2005. – Zuletzt abgerufen am 14.04.2010
[Had09]
Hadley, Marc: Web Application Description Language. World Wide Web
Consortium. http://www.w3.org/Submission/wadl/. Version: 2009. – Zuletzt abgerufen am 14.04.2010
[HB04]
Haas, Hugo ; Brown, Allen: Web Services Glossary. World Wide Web
Consortium. http://www.w3.org/TR/ws-gloss/. Version: 2004. – Zuletzt
abgerufen am 14.04.2010
[Hoc08]
Hochreiter, Martin: Mashups und ihre praktischen Anwendungen. Hagenberg, Austria, Digitale Medien; FH Oberösterreich – Fakultät für Informatik, Kommunikation und Medien, Diplomarbeit, 2008
[HS08]
Hadley, Marc ; Sandoz, Paul: JAX-RS: Java API for RESTful
Web Services. http://jcp.org/aboutJava/communityprocess/final/
jsr311/index.html, 9 2008 Zuletzt abgerufen am 14.04.2010
[Jac04]
Jacobs, Ian: URIs, Addressability, and the use of HTTP GET and
POST. World Wide Web Consortium. http://www.w3.org/2001/tag/
doc/whenToUseGet.html. Version: 2004. – Zuletzt abgerufen am 14.04.2010
[JW04]
Jacobs, Ian ; Walsh, Norman:
Architecture of the World
Wide Web, Volume One.
World Wide Web Consortium, Recommendation REC-webarch-20041215. http://www.w3.org/TR/2004/
REC-webarch-20041215. Version: December 2004. – Zuletzt abgerufen am
14.04.2010
[Lüb08]
Lübke, Daniel: An Integrated Approach for Generation in SOA Projects.
Verlag Dr. Kovac, ISBN: 978-3-8300-3649-4, 2008
[LHVL05]
Lu, Yi-Hsuan ; Hong, Yoojin ; Varia, Jinesh ; Lee, Dongwon: Pollock: Automatic Generation of Virtual Web Services from Web Sites. http:
//pike.psu.edu/publications/sac05.pdf. Version: 2005. – Zuletzt abgerufen am 14.04.2010
[Man08]
Mandel, Lawrence:
Describe REST Web services with WSDL
2.0. http://www.ibm.com/developerworks/db2/library/techarticle/
dm-0606martin/index.html. Version: May 2008. – Zuletzt abgerufen am
14.04.2010
[RHJ99]
Raggett, Dave ; Hors, Arnaud L. ; Jacobs, Ian:
HTML 4.01
Specification. W3C Recommendation. http://www.w3.org/TR/html4.
Version: December 1999. – Zuletzt abgerufen am 14.04.2010
66
[RR07]
Richardson, Leonard ; Ruby, Sam: RESTful Web Services. illustrated
edition. O’Reilly Media, Inc., 2007. – ISBN 9780596529260
[Til09]
Tilkov, Stefan: REST und HTTP: Einsatz der Architektur des Web für
Integrationsszenarien. 1., Aufl. dpunkt Verlag, 2009. – ISBN 9783898645836
[TSK08]
Tuchinda, Rattapoom ; Szekely, Pedro ; Knoblock, Craig A.: Building
Mashups by example. In: IUI ’08: Proceedings of the 13th international
conference on Intelligent user interfaces. New York, NY, USA : ACM,
2008. – ISBN 978–1–59593–987–6, 139–148
[Völ03]
Völkel, Max: Extraktion von XML aus HTML-Seiten. Das WYSIWYGWerkzeug d2c, Universität Karlsruhe (TH), Masterarbeit, 2003. http://
xam.de/2003/05-wal/Extraktion%20von%20XML%20aus%20HTML-Seiten%
20-%20Das%20WYSIWYG-Werkzeug%20d2c%20-%20Ausarbeitung.pdf.
–
[Wel09]
Wellman, Dan: jQuery UI 1.7: The User Interface Library for jQuery.
Packt Publishing, 2009. – ISBN 9781847199720
[YWH09]
Yang, Shaohua ; Wang, Guiling ; Han, Yanbo: Grubber: Allowing EndUsers to Develop XML-Based Wrappers for Web Data Sources. In: APWeb/WAIM ’09: Proceedings of the Joint International Conferences on Advances in Data and Web Management. Berlin, Heidelberg : Springer-Verlag,
2009. – ISBN 978–3–642–00671–5, S. 647–652
67
Abbildungsverzeichnis
2.1.
2.2.
2.3.
2.4.
Baumstruktur eines HTML-Dokumentes .
AJAX am Beispiel von Google . . . . . .
Die Webseite von Houston Crime Maps
Ein verzerrtes Bild für CAPTCHA . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
9
18
3.1.
3.2.
3.3.
3.4.
3.5.
Ablauf einer Anfrage im Screen-Scraper von d2c . . . .
Grafische Benutzeroberfläche von Lixto Visual Developer
Die Architektur von Lixto Visual Developer . . . . . . .
Benutzeroberfläche von Dapper . . . . . . . . . . . . . .
Benutzeroberfläche von Mozenda . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
22
22
25
25
. . . .
. . . .
. . . .
. . . .
stehen
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
28
29
31
32
33
33
34
35
37
38
41
6.1. Architektur von DisRESTractor . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Sequenzdiagramm mit dem Ablauf in DisRESTractor . . . . . . . . . . . . .
6.3. Klassenstruktur des generierten Service . . . . . . . . . . . . . . . . . . . .
49
51
55
4.1. DisRESTractor nach dem Start . . . . . . . . . . . . . . . . . .
4.2. DisRESTractor: Auswahl der ersten Ressource . . . . . . . . .
4.3. DisRESTractor: Dialog Objekt aufnehmen . . . . . . . . . . .
4.4. DisRESTractor: Dialog Attribut als Ressource hinzufügen
4.5. DisRESTractor: Zwei Ressourcen, die miteinander in Beziehung
4.6. DisRESTractor: Mehrwertiges Attribut . . . . . . . . . . . . . .
4.7. Profilseite des Besitzes eines Bildes bei Flickr . . . . . . . . . .
4.8. DisRESTractor: Dialog Service erstellen . . . . . . . . . . .
4.9. Metamodell für extrahierte Daten . . . . . . . . . . . . . . . . .
4.10. Ablauf der Datenextraktion mit DisRESTractor . . . . . . . . .
4.11. Benutzeroberfläche von DisRESTractor . . . . . . . . . . . . .
4.12. Aufnahme von Attributen in DisRESTractor . . . . . . . . . .
68
Erklärung der Selbstständigkeit
Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbständig und ohne fremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenen Quellen und
Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keinem
anderen Prüfungsamt vorgelegen.
Hannover, den 14. April 2010
Alexander Fomin

Semi-automatische Generierung von REST

Transcription

Similar documents

Automotive Safety und Security aus Sicht eines Zulieferers

Tendenz 1/2010

Volume P-210(2012) - Mathematical Journals

Produktkatalog PDF

transfer - Insius Inmap

XEDAQ X5 Webmarketing

Der Vertrag über die Nutzung virtueller Welten

Deutsches Ressourceneffizienzprogramm II