Bakkalaureatsarbeit Webpage Analyzer WPA

Transkript

1 Bakkalaureatsarbeit Webpage Analyzer WPA Florian Wörter Christoph Spielmann

2 INHALT I Pflichtenheft II Spezifikation 1. Systemarchitektur Ein Überblick 2. Interfaces 3. Die wichtigsten Packages und Klassen 4. Das Schema für Konfigurationsfiles 5. Ein Beispiel für ein Konfigurationsfile III Die Applikation aus Benutzersicht 1. Übersicht über die einzelnen JSP Seiten 1.1Upload.jsp 1.2Start.jsp 2. Ein Konfigurationsfile hochladen und bearbeiten 3. Einen Crawlvorgang starten IV Der Crawlvorgang Ein Blick hinter die Kulissen 1. Workflow des Crawlings V Die Applikation aus Entwicklersicht 1. Ein kurzer Überblick 2. Die Architektur 3. Einfügen eines neuen Checks 4. Einfügen einer eigenen Ausgabeklasse 5. Javadoc aller Packages, Interfaces und Klassen VI Ein Blick in die Zukunft

3 I PFLICHTENHEFT Ziel des zu entwickelnden Systems Das Ziel dieses Projekts ist es, ein System zu planen und anschließend zu implementieren, mit dessen Hilfe man eine Web-Page analysieren kann. In weiterer Folge soll mit den, durch die Analyse gewonnenen Daten, eine Verbesserung der Positionierung der Web-Page in Suchserverern wie z.b. Google, Yahoo oder Altavista erreicht werden. Anforderungen Generell soll die Software mehrschichtig aufgebaut sein. Dadurch wird ein höherer Grad an Flexibilität erreicht und einzelne Module können ausgetauscht, ersetzt und/oder erweitert werden. Anforderung 1 Das System soll web-basiert sein, dass heisst es muss mit Hilfe eines Browsers bedient werden können. Anforderung 2 Um eine Web-Site analysieren zu können, muss es möglich sein, einen Crawling-Vorgang von einer bestimmten Ausgangs-URL zu starten. Für jede während des Crawlings besuchte Seite soll eine Analyse in Bezug auf Suchserver-spezifische Daten durchgeführt werden können (Beispiele dafür wären z.b. Seiten-Titel, Meta-Tags und statistische Informationen wie Anzahl der Wörter auf der Seite, Seitengröße, Häufigkeit bestimmter Keywords etc.). Generell soll beim Crawling, die in der robots.txt angegeben Richtlinien für Crawler für die jeweilige Site berücksichtigt werden. Weiters soll es möglich sein, den User-Agents des Crawlers frei einzustellen (Wichtig für robots.txt). Anforderung 3 Für jede besuchte Seite soll die Möglichkeit bestehen, dass die Suchserver-spezifischen Daten für diese, bez. eines gegebenen Parameters, überprüft werden können (Zum Beispiel werden die ersten dreihundert Worte der Seite auf das Vorkommen eines bestimmten Schlüsselwortes geprüft und wenn dieses zu selten vorkommt, wird dafür eine Warnung vermerkt). Weiters sollen die für die Überprüfungs-Funktionen benötigten Parameter mit Hilfe von System-Eigenschaften gesetzt werden können und es soll möglich sein, mehrere Überprüfungs-Funktionen pro besuchter Seite zu definieren (Bsp. Länge des Titels und Seitenlänge) bzw. soll es möglich sein, gewisse Check-Funktionen per Property-File auszuschalten.

4 Mögliche Checks: Analyse der Verzeichnistiefe (die maximale Tiefe soll über das Property-File definiert werden können) Analyse der Seitengröße (sowohl absolut in Bytes als auch in Anzahl der Tokens) Analyse, ob die Image-Tags auch über ein ALT-Tag verfügen Analyse, ob die Seiten mit einem bestimmten Tag beginnen (beispielsweise ein <h...>- Tag nach dem body tag folgt, da von manchen Web-Crawlern dies überprüft wird und als besonders wichtig angesehen wird) Suche nach Text, der mit einer zu kleinen Schriftgröße dargestellt wird (Parametrisierung der Schriftgröße soll wieder über das Property-File erfolgen.) Analyse, ob JavaScript oder CSS-Code direkt in den Seiten deklariert wurde oder in externen Dateien sind und nur verlinkt werden. Wenn der Code direkt in den Seiten gefunden wird, kann zum Beispiel eine Überprüfung der Codegröße vorgenommen oder ob man ein document.open() findet. Document.open kann verwendet werden um den Benutzer mit Popups zu überschwemmen. Als eine weitere Überprüfung könnte man eine Überprüfung auf JS-Links vornehmen (auch hiermit könnte der Benutzer mit Popups überschwemmt werden) Analyse des Änderungsdatums von Seiten (Manche Web-Crawler halten sich so etwas wie eine History von Seiten und wenn sich eine Seite oft ändert, weiss der Crawler, dass er diese Seite öfters besuchen und indizieren muss.) Die Schranken für das Änderungsdatum soll wieder mit eines Properties gesetzt werden können. Analyse der Content-Language und des Zeichensatzes (Bsp: ISO ) Analyse, ob DHTML auf den Seiten eingesetzt wird. Anforderung 4 Das Ergebnis der Analyse soll in einem Web-Formular dargestellt werden und zwar gruppiert nach den besuchten Seiten, Ausgabe der gewünschten Informationen und der Warnungen (siehe Anforderung 3) Anforderung 5 Die Architektur der Applikation soll modular sein. Diese Modularität bezieht sich erstens auf die Möglichkeit zur Erweiterung um weitere Site-Informationen, die dann pro besuchter Seite ausgewertet werden können, und zweitens soll es möglich sein, weitere Präsentationsformen (Beispielsweise XML-Export oder Speicherung in einer Datenbank) für das Resultat zu erstellen. Anforderung 6 Das System soll möglichst frei konfigurierbar sein (Starturl, Checkbedingungen, Anzeigeeigenschaften etc.). Die Konfiguration soll in einem Propertyfile gespeichert werden, um sie zu einem späteren Zeitpunkt wieder laden zu können.

5 Anforderung 7 Das Property-File, dass für die aktuelle Analyse verwendet werden soll, kann in der GUI (im Rahmen dieses Projekts, wird eine GUI auf Basis von HTML/JSP implementiert) ausgewählt werden. Desweiteren wird ein minimalistischer Editor für Property-Files in die Web-GUI eingebaut. Mit Hilfe dieses Editors kann man die auf dem Server gespeicherten Property-Files verändern bzw. ein neues Property-File erstellen und dieses anschließend auf dem Server abspeichern. Anforderung 8 Weiters soll es möglich sein, verschiedene Warning-Stufen für Checks im Property-File zu definieren. Die Definition betrifft erstens die Anzahl der Warning-Stufen und ob und wie gewisse Warning-Stufen im Ergebnis dargestellt werden. Beispiel: Es werden 3 Warning- Stufen deklariert. Warning-Stufe 1 für den Seitentitel liegt vor, wenn er mehr als 35 Wörter hat. Warning-Stufe 2 gilt wenn der Titel länger als 50 Wörter ist und Warning-Stufe 3 liegt vor wenn der Titel fehlt bzw. der Titel mehr als 80 Wörter hat. Desweiteren wird im Property-File angegeben, dass Warnings der Stufe 1 nicht angezeigt werden und Stufe 3- Warnings als Schwerwiegender Fehler im Resultatsformular markiert werden. Randbedingungen Die Software wird mit Hilfe von Java 1.4, JSP, Servlets auf einem AMD64 System mit einer Gentoo Linux (Kernel 2.6.9) Umgebung entwickelt. Als Entwicklungsumgebung wird Netbeans (Version 3.6) verwendet. Als Servlet-Engine wird während der Entwicklung Apache Tomcat in der Version 5 verwendet. Anforderungsliste Alle Anforderungen sind der Übersicht halber in einer Tabelle aufzulisten. Dies vereinfacht z.b. die Referenz auf Anforderungen aus anderen Dokumenten. Anforderungs-ID Anforderung 1 Anforderung 2 Anforderung 3 Anforderung 4 Anforderung Das System soll web-basiert sein Das System verwendet einen Web-Crawler zur Durchführung der Analyse ausgehend von einer Start-URL. Jede Seite wird bez. Suchserver-spezifischen Daten untersucht. Diese Daten sollen bez. gegebenen Parametern überprüft werden können. Das Ergebnis der Überprüfung soll in einem Web-Formular angezeigt werden.

6 Anforderung 5 Anforderung 6 Anforderung 7 Anforderung 8 Die Systemarchitektur soll um neue Site- Informationen und weitere Präsentationsformen des Ergebnisses erweiterbar sein. Das System soll möglichst frei konfigurierbar sein. Die Auswahl und die Erstellung/Bearbeitung von Property-Files kann in direkt in der GUI erfolgen. Es soll möglich sein, im Property-File eine beliebige Anzahl von Warning-Stufen zu deklarieren und wie/ob diese bei der Auswertung angezeigt werden.

7 II SPEZIFIKATION II.1 Systemarchitektur Ein Überblick Das System ist modular aufgebaut und besteht aus den beiden Hauptpackages servlets und businesslogic. Im Package servlets werden, wie der Name schon sagt, alle Servlets liegen, die die Anfragen der einzelnen.jsp Seiten befriedigen. Eine weitere Ebene darunter soll die Businesslogic liegen, die spezielle Aufgaben von den Servlets ausgliedert. Durch die Unterteilung in diese zwei Packages ist es einfacher nachträglich Änderungen am System vorzunehmen bzw. der Schichtenaufbau des Gesamtsystemes wird leichter erkennbar. Das Package businesslogic unterteilt sich in die Unterpackages businesslogic.xml, businesslogic.result, businesslogic.reports und businesslogic.checks. II.2 Interfaces businesslogic.resultinterface Dieses Interface muss jede Klasse implementieren, die ein Ergebnis anzeigen will. Standardmäßig implementiert die Klasse businesslogic.htmlresult dieses Interface. Diese Klasse generiert einen Html Report für den abgeschlossenen Crawlingvorgang und präsentiert die gesammelten Daten. Es ist jedoch gut denkbar, dass man Ergebnisse zum Beispiel direkt in eine Datenbank schreiben möchte und deshalb eine eigene Klasse implementiert, die das erledigt. Diese Klasse muss dann jedoch dieses Interface implementieren. businesslogic.checks.checkinterface Es gibt verschiedenste Überprüfungen, die auf einer Website durchgeführt werden können. Zum Beispiel kann man sie auf ihre Seitengrösse untersuchen. Um das zu bewerkstelligen muss man eine Klasse (in unseren Falle PageSizeCheck) implementieren, die diesen Check beschreibt. Man kann selber solche Checks in anderen Klassen implementieren, diese müssen dann jedoch das CheckInterface implementieren. II.3 Die wichtigsten Packages und Klassen servlets.uploadservlet Diese Klasse ist von HttpServlet abgeleitet und ist für den Upload eines neuen Configfiles verantwortlich. Der Benutzer sieht in der JSP Seite ein grosses Textfeld, in dem er ein Configfile bearbeiten kann. Ist er damit fertig, klickt er auf einen Button Upload und das UploadServlet validiert die Eingabe des Benutzers. Entspricht das vom Benutzer eingegebene Configfile nicht dem XML Schema wird eine entsprechende Fehlermeldung ausgegeben und der Uploadvorgang wird abgebrochen. Ist das Configfile valide wird es auf den Server geladen. servlets.controllerservlet Diese Klasse ist ebenfalls von HttpServlet abgeleitet und stellt den Controller im MVC Pattern dar. Das heisst, es stellt die oberste Ebene dieses Controllers dar, da es die eigentliche Arbeit an die Klasse businesslogic.controller weiterleitet. Dieses Servlet überprüft jedoch bevor es die Daten weiterleitet diese nochmal auf ihre Richtigkeit und das Configfile auf seine Validät. businesslogic.businesslogic

8 Wenn ein Crawling-Vorgang gestartet wird, wird eine Instanz dieser Klasse angelegt, sie ist im Grunde dafür zuständig das gewählte Konfigurationsfile noch einmal auf Validität zu überprüfen, die Umgebung für den Crawler bereitzustellen, den Crawler zu starten und nach Beendigung des Crawling-Vorgangs das Result zu verarbeiten. businesslogic.htmlresult HtmlResult bereitet die während des Crawlingvorganges gesammelten und in ReportList eingetragenen Daten für einen Html-Report auf und zeigt diesen in einen neuen Browserfenster an. Sie implementiert logischerweise businesslogic.resultinterface. businesslogic.xml.configfileparser Diese Klasse untersucht ein Configfile auf seine Validät und speichert (falls das File zum XML Schema config.xsd valide ist) die Konfiguration im ConfigurationBean. Die wichtigste Methode dieser Klasse heisst void parse(). Diese erledigt die gerade beschriebene Arbeit. Sie wirft eine Exception (SAXParseException) falls das Configfile nicht valide ist. Dadurch kann der genaue Fehlertext in der entsprechenden JSP Seite angezeigt werden. businesslogic.reports.reportlist Während des Crawlingvorganges werden für jede Seite diverse Tests (Checks) durchgeführt. Das Ergebnis dieser wird in eine ReportList eingetragen und kann später zum Erzeugen des Reports wieder verwendet werden. Die wichtigsten Methoden sind init (zum Initialisieren der Liste, sprich alle Einträge (falls vorhanden) löschen und ersten Eintrag (Timestamp + Crawling started - Meldung) erstellen), add (Hinzufügen eines neuen Eintrages) und removeall (zum Löschen aller Einträge). businesslogic.reports.reportlistentry Diese Klasse stellt einen Eintrag in der ReportList dar. Sie besitzt die Felder timestamp, warninglevel, page und text. businesslogic.checks.checkattribute CheckAttribute stellt einen Wert dar, auf den verglichen werden soll. Das ist nötig, um generische Checks erstellen zu können. Wenn zum Beispiel ein Check überprüft, ob die Seitengrösse kleiner als 100kb ist, so benötigt dieser ein CheckAttribute, das wie folgt aussieht: als Compareable: Integer Objekt mit Wert 100 als operator String: LESS_THAN. businesslogic.checks.pagesizecheck Diese Klasse überprüft eine gecrawlte Seite auf ihre Grösse. Das ist nur ein Beispielcheck. Es können praktisch eine unbegrenzte Anzahl von Checks als Klassen implementiert werden, die das Interface businesslogic.checks.checkinterface implementieren.

9 II.4Das Schema für Konfigurationsfiles <?xml version="1.0" encoding="utf-8"?>  <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="analysis"> <xs:annotation> <xs:documentation>wurzelelement fã¼r die Konfiguration einer Analyse</xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="warning" nillable="false"> <xs:complextype> <xs:attribute name="levels" type="xs:positiveinteger" use="required"/>  <xs:attribute name="errorlevel" type="xs:positiveinteger" use="optional"/>  <xs:attribute name="ignorelevel" type="xs:positiveinteger"/>  </xs:complextype> </xs:element> <xs:element name="check" nillable="false" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="classname" type="xs:string" nillable="false"/>  <xs:element name="options">  <xs:complextype> <xs:sequence> <xs:element name="option" maxoccurs="unbounded">  <xs:complextype> <xs:sequence> <xs:element name="warning">  <xs:complextype> <xs:sequence> <xs:element name="text" type="xs:string"/> </xs:sequence> <xs:attribute name="level" type="xs:positiveinteger" use="required"/> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="varname" type="xs:string" use="required"/>  <xs:attribute name="operator" type="xs:string" use="required"/>  <xs:attribute name="value" type="xs:string" use="required"/>  <xs:attribute name="vartype" use="required"/>  <xs:attribute name="content-type" type="xs:string" use="required"/>  <xs:attribute name="extension" type="xs:string" use="required"/>  </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="result"> <xs:complextype> <xs:sequence> <xs:element name="classname" type="xs:string" nillable="false"/>  <xs:element name="options"> <xs:complextype> <xs:sequence> <xs:element name="option" minoccurs="0" maxoccurs="unbounded"> <xs:complextype/> </xs:element> </xs:sequence> </xs:complextype>

10 </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="crawler"> <xs:complextype> <xs:sequence> <xs:element name="start-url" type="xs:string" nillable="false"/>  <xs:element name="user-agent" type="xs:string" nillable="false"/>  </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema>

11 II.5Beispiel für ein Konfigurationsfile <?xml version = '1.0' encoding = 'UTF-8'?> <!--Sample XML file generated by XMLSpy v2005 U ( <ANALYSIS xsi:nonamespaceschemalocation="c:\program Files\Apache Software Foundation\Tomcat 5.5\webapps\wpa\WEB-INF\configfiles\config.xsd" xmlns:xsi=" > <WARNING levels="2" errorlevel="3" ignorelevel="1" /> <CHECK> <CLASSNAME>businesslogic.checks.PageSizeCheck</CLASSNAME> <OPTIONS> <OPTION vartype="java.lang.long" operator="greater_equals" value="1024" varname="size" content-type="text/html" extension=".html"> <WARNING level="4" > <Text>The size of this Page is greater than 1024 Bytes</Text> </WARNING> </OPTION> <OPTION vartype="java.lang.long" operator="less_than" value="20" varname="size" contenttype="text/html" extension="*"> <WARNING level="1" > <Text>String</Text> </WARNING> </OPTION> </OPTIONS> </CHECK> <RESULT> <CLASSNAME>businesslogic.result.HTMLResult</CLASSNAME> <OPTIONS/> </RESULT> <CRAWLER> <START-URL> <USER-AGENT>googlebot (+ </CRAWLER> </ANALYSIS>

12 III DIE APPLIKATION AUS BENUTZERSICHT III.1Übersicht über die einzelnen JSP Seiten Das Frontend von WPA setzt sich aus den Dateien start.jsp und upload.jsp zusammen. II.1.1Upload.jsp Abbildung 1: Screenshot upload.jsp Mit Hilfe der Datei upload.jsp können Sie Konfigurationsdateien von Ihren Rechner auf den WPA Server hochladen oder am Server befindliche Konfigurationsfiles bearbeiten. Wählen Sie dazu aus der Dropdown Liste ein Konfigurationsfile aus und klicken Sie auf den Button Laden. Der Inhalt der Datei wird in das grosse Textfeld geladen, wo er dann von Ihnen bearbeitet werden können. Mit Klick auf Upload wird die Datei auf den Server zurückgeschrieben. Wollen Sie ein eigenes Konfigurationsfile hochladen, so klicken Sie bitte auf den Button Durchsuchen und wählen die Datei auf Ihrer Festplatte aus. Klicken Sie nun auf Upload und die Datei wird auf den Server geladen. Egal ob Sie eine bestehende Konfigurationsdatei bearbeiten oder eine neue hochladen, so wird, bevor die Datei auf dem Server gespeichert wird, die Datei natürlich einer Überprüfung und Validierung unterzogen. Sie erhalten eine Fehlermeldung, falls die Datei nicht valide sein sollte. Bemerkung: Das von Ihnen erstellte Konfigurationsfile bleibt so lange auf dem Server

13 gespeichert, bis es von Ihnen ausdrücklich wieder gelöscht wurde. II.1.2Start.jsp Nun, da eine Konfiguration hochgeladen wurde, kann mit start.jsp der eigentliche Crawlvorgang gestartet werden. Abbildung 2: Screenshot start.jsp Zum Starten wählt man einfach ein sich auf dem Server befindendes Konfigurationsfile aus der Dropdownliste aus und klickt anschließend auf den Button Starten. Während des Crawlvorganges bleibt das Fenster unverändert. Ist dieser abgeschlossen, so erscheint im gleichen Fenster eine Zusammenfassung des Crawls. Bemerkung: Es kann je nach Umfang der zu crawltenden Site(s) unter Umständen sehr lange dauern bis ein Crawl abgeschlossen ist.

14 II.1.2 Ein Konfigurationsfile hochladen und bearbeiten Zum Bearbeiten oder Hochladen einer Konfiguration, wechseln Sie bitte auf die Adresse Wie unter Punkt II.1.1 beschrieben, können Sie auf dieser Website eine neue Serverkonfiguration hochladen bzw. eine bestehende Konfiguration bearbeiten. Bemerkung: Der Eintrag für xsi:nonamespaceschemalocation im Element ANALYSIS des auf den Server zu ladenden XML-Files MUSS 'config.xsd' lauten, da bevor das File wirklich auf dem Server gespeichert wird, der Pfad zum Schema der Konfigurationsdatei für den Server gesetzt wird! II.1.3 Einen Crawlvorgang starten Zum Starten eines Crawlvorganges wechseln Sie bitte auf die Adresse Wie unter Punkt II.1.2 beschrieben, können Sie auf dieser Website einen neuen Crawlvorgang starten.

15 IV DER CRAWLVORGANG EIN BLICK HINTER DIE KULISSEN IV.1Workflow des Crawlings Die Abbildung der einzelnen Schritte finden Sie auf der nächsten Seite. 1 In diesem Schritt wird das ControllerServlet vom Benutzer aufgerufen, wenn er auf den Submit-Button der Seite start.jsp der Web-Applikation klickt. Wenn ein gültiger Eintrag (jeder Eintrag der mit.xml endet ist ein gültiger Eintrag) in der Combobox ausgewählt wurde, bevor das Formular abgeschickt wurde, geht es weiter mit Schritt 2. 2 In Schritt 2 wird eine neue Instanz der Klasse BusinessLogic angelegt und anschließend die Methode executecrawler der Klasse BusinessLogic ausgeführt. 3 In der Methode executecrawler wird zuerst das in Schritt 1 ausgewählte XML-File mit Hilfe des ConfigFileParsers geparst. Während des Parsens wird ein ConfigurationBean-Objekt 4 initialisert. Ein Feld der Klasse ConfigurationBean (checks) enthält die Liste mit den, in dem XML-File definierten, Checks. Ein weiteres wichtiges Feld der Klasse ConfigurationBean ist result. Dieses Feld enthält eine Instanz einer von ResultInterface abgeleiteten Klasse. Nachdem die XML-Datei vollständig und fehlerfrei geparst wurde, wird die Check-Liste serialisiert und die Umgebung für den Web-Crawler eingerichtet. Es wird die Basis- Crawl-Order -Datei (=diese Datei ist die Konfigurationsdatei für Heritrix) geöffnet, der User-Agent-Eintrag und der Name des Seed-Files (enthält die von Heritrix zu verarbeitenden URLs) angepasst und unter einem neuen Namen abgespeichert (dies ist nötig, damit die Basis- Crawl-Order -Datei, base.xml, weiter erhalten bleibt und auch bei zukünftigen Analysen wieder verwendet werden kann). Anschließend wird das Verzeichnis des Jobs in ein Wurzel-Verzeichnis des Dateisystems verschoben (/ unter Linux und z.b. C:\ wenn sich Tomcat auf der Partition mit der Bezeichnung C befindet), dies wurde vor allem deshalb gemacht, um etwaigen Fehlern vorzubeugen (z.b. wenn versucht wird gleichzeitig zwei verschiedene Jobs zu crawlen, oder wenn zwei Benutzer zur gleichen Zeit versuchen eine Seite zu analysieren). Wenn alle vorher genannten Schritte fehlerfrei durchgeführt werden konnten, wird anschließend Heritrix mit Hilfe eines ProcessBuilder-Objekts als seperater Prozess gestartet. 5 Bei der Initialisierung von Heritrix wird auch ein WPAProcessor-Objekt initialisiert und als Post-Processor in die Post-Processor-Chain (für genauere Informationen bez. Heritrix siehe eingehängt. Die Aufgabe dieses Processors ist es, bei jeder gecrawlten URI die in Schritt 3 erstellte Check-Liste durchzugehen und die ReportList zu erstellen. Bevor der Heritrix-Prozess beendet wird, wird die vom WPAProcessor erstellte ReportList auf die Festplatte serialisiert. 6 Der vorletzte Schritt des Crawling-Vorgangs ist der Aufruf der Methode printresult(httpservletresponse) des, während des Parsens der Konfigurationsdatei ( 3 ) instantiierten, ResultInterface-Objekts. Diese Methode deserialisiert die im vorherigen Schritt serialisierte ReportList und verarbeitet das Resultat des Crawlings. Abschließend werden noch die Logfiles des Crawls in ein neu erstelltes Verzeichnis verschoben, um eine spätere Analyse der Logfiles zu ermöglichen bzw. zu erleichtern. (Wenn man dies nicht machen würde, würde einfach die Logging-Ausgaben des nächstens Crawls an die alten Logs angehängt!)

16 Abbildung 3: Graphische Darstellung des Workflows

17 V DIE APPLIKATION AUS ENTWICKLERSICHT V.1Ein kurzer Überblick Das gesamte Projekt wurde in Java entwickelt. Es sollten daher natürlich in dieser Richtung Vorkenntnisse vorhanden sein, damit man den Aufbau des Systemes nachvollziehen kann. Basistechnologie waren Java Server Pages und Servlets. Ausserdem wurde das Projekt nach dem MVC (Model View Controller) Pattern entwickelt. Die View stellen die einzelnen Java Server Pages dar. Der Controller ist in der Klasse servlets.controllerservlet implementiert. Die Konfigurationsfiles und daher auch der Konfigurationsfileparser arbeiten auf der Basis von XML. Das Schema von Konfigurationsfiles (Config.xsd) und ein Beispiel für eine valide Konfigurationsdatei finden Sie unter den Punkten II.4 und II.5 dieser Dokumentation. Ein Ziel dieses Projektes war es, den Analyzer möglichst flexibel und modular aufzubauen. Es ist also mit vergleichsweise wenig Arbeit verbunden einen neuen Check zu implementieren und in das bestehende System einzufügen. Auch ist es möglich eine neue Ausgabeklasse zu implementieren, die zum Beispiel die Ergebnisse des Crawlvorganges in eine Datenbank schreibt. Als Entwicklungsumgebung können wir Eclipse ( weiter entfehlen. V.2 Die Architektur Abbildung 4: Klassendiagramm

18 Für eine genaue Erklärung der Packages, Interfaces und Klassen werfen Sie bitte einen Blick in die Spezifikation (Punkt II dieses Dokumentes). V.3 Einfügen eines neuen Checks Das Einfügen eines neuen Checks gestaltet sich auf den ersten Blick etwas kompliziert. Wenn man aber erst einmal weiss wie, dann ist das auch kein großes Problem mehr. Prinzipiell muss eine neue Check-Klasse implementiert werden, die von der abstrakten Klasse AbstractCheck abgeleitet sein muss. Ist der Check fertig implementiert, so muss er noch in der Methode innerprocess der Klasse businesslogic.wpaprocessor eingefügt werden. Bitte schauen Sie sich hierzu den Sourcecode der Klassen businesslogic.wpaprocessor und businesslogic.checks.pagesizecheck etwas näher an, er ist an betreffenden Stellen gut dokumentiert. V.4 Erstellen einer neuen Ausgabeklasse Das Implementieren einer eigenen Ausgabeklasse gestaltet sich etwas einfach er als das Erstellen eines neuen Checks. Die Ausgabeklasse muss das ResultInterface und somit die Methode printresult(httpservletresponse res) implementieren. In dieser Methode können Sie nun die Ausgabe implementieren. Um die Klasse dann endgültig in das System einzuhängen, müssen sie in der Controller Klasse (businesslogic.businesslogic) noch an gegebener Stelle kleine Änderungen vornehmen. Sie dürfen auch nicht vergessen ein Feld des Typs ReportList in die Ausgabeklasse einzufügen, und dieses von businesslogic.businesslogic aus zu setzen. Dann sollte die Ausgabe eigentlich schon funktionieren ;o) V.5 Javadoc aller Packages, Interfaces und Klassen Die Dokumentation finden Sie hier.

19 VI EIN BLICK IN DIE ZUKUNFT 1. Entwicklung weiterer Checks: Dies ist natürlich der erste Ansatzpunkt für Erweiterungen dieses Projekts. Mögliche Beispiele für weitere Checks sind im Teil I dieser Dokumentation. Als Prove-ofconcept wurde im Rahmen dieses Projekts ein Check zur Überprüfung der gecrawlten Seiten auf die Seitengröße in Bytes implementiert. 2. Anzeige des Fortschritts während des Crawlvorgangs in der Web-Applikation: Dies hat meiner Meinung nach die höchste Priorität, da im Moment der Benutzer der Applikation keine Rückmeldung über den Fortschritt des Crawlingvorgangs erhält. Wenn der Crawler abstürzen sollte, bekommt der Benutzer das nicht mit. Deshalb sollte so eine Art Fortschrittsbalken implementiert werden, der den Fortschritt darstellt. Desweiteren wäre es vorteilhaft wenn man die Logs während des Crawlens anzeigen könnte, damit sich der Benutzer über etwaige Fehlermeldungen während des Crawlens informieren kann. Weiters zu überlegen wäre es, dem Benutzer eine Möglichkeit einzuräumen, den von ihm gestarteten Heritrix-Prozess zu beenden. 3. Implementierung eines eigenen Frontiers ( : Wenn man sich das XML-Schema für das Konfigurationsfile genauer ansieht, fallen einem zwei Attribute des Elements 'OPTION' auf: content-type und extension. Diese Attribute werden verwendet um definierte Content-Types bzw. Fileerweiterungen von der Analyse auszuschließen. Aus Zeitgründen wurde im Projekt in der Methode innerprocess (wird für jede gecrawlte URI aufgerufen) der Klasse WPAProcessor einfach jene URIs von der Analyse ausgeschlossen, die nicht den im Konfigurationsfile angegebenen Content-Type(s) UND Fileextension(s) entsprechen. Dass heisst, dass die URIs gecrawlt werden, aber eigentlich nichts mit ihnen gemacht wird. Deshalb wäre es besser, wenn diese URIs einfach überhaupt nicht von Heritrix besucht werden würden und dass kann mittels einem eigens implementierten Frontier erreichen werden. 4. Erhöhung der Geschwindigkeit des Crawlings: Im Moment läuft Heritrix mit den Standardeinstellungen. Dass bedeutet, dass Heritrix sich sehr brav verhält und die gecrawlten Site(s) nicht mit Requests zupflastert. Dies bedingt aber auch automatisch, dass das Crawling eher langsam abläuft. Verbessern kann man dies indem man den Wert der folgende Optionen in der Basis- Crawl- Order -Datei verkleinert (wenn diese Optionen auf 0 gesetzt werden, erhält man den besten Speed-up): delay-factor, max-delay-ms und min-delay-ms. Es könnten z.b. 3 verschiedene Basis-Konfigurations-Dateien erstellt werden (Standart, Schneller, Hammer). Man könnte dann in der Konfigurationsdatei einstellen, welche man für das Crawling dieser Analyse einsetzen will.

20 5. Verbesserung des Benutzerinterfaces: Zusätzlich zu den Maßnahmen, die in Punkt 2 schon angesprochen wurden, würde die Möglichkeit bestehen, das Benutzeroberfläche generell zu verbessern. Es könnte zum Beispiel mittels JSF (=Java Server Faces) das vorhandene Textarea-Tag in dem JSP- File für den Upload/die Bearbeitung (upload.jsp) durch ein eigens programmiertes JSF- Tag ersetzt werden, dass zum Beispiel Syntax-Hervorhebung und Code-Komplettierung unterstützt.