1 Einleitung - Institut für Informatik
Werbung
Freie Universität Berlin Institut für Mathematik und Informatik Seminar „Active Data Management“ Prof. H. Schweppe, A. Hinze, T. Schlieder SoSe 2001 MONITORING VON WEB-DOKUMENTEN Ausarbeitung Name: Studiengang: Matrikelnr. Abgabe: Lasse Voß Informatik (M3) 3505701 30.06.2001 Inhaltsverzeichnis 1 Einleitung ........................................................................................................................... 1 2 Conquer .............................................................................................................................. 3 3 4 5 2.1 Systemarchitektur ....................................................................................................... 3 2.2 Abfragesprache........................................................................................................... 4 2.3 Datenquellen und Ereigniserkennung ........................................................................ 5 2.4 Algorithmus: Trigger Pattern Matching ..................................................................... 6 Xyleme ............................................................................................................................... 8 3.1 Systemarchitektur ....................................................................................................... 8 3.2 Abfragesprache........................................................................................................... 9 3.3 Datenquellen und Ereigniserkennung ...................................................................... 10 3.4 Algorithmus: Atomic Event Set ............................................................................... 12 Vergleich .......................................................................................................................... 14 4.1 Datenquellen und Ereigniserkennung ...................................................................... 14 4.2 Abfragesprache......................................................................................................... 15 4.3 Bewertung ................................................................................................................ 18 Literaturverzeichnis .......................................................................................................... 20 –i– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 1 Einleitung Das Internet hat das Anbieten und Abrufen von Informationen stark vereinfacht. Die automatische Suche und Auswertung über diesen ständig wachsenden, gewaltigen und stark dynamischen Datenbestand ist ein Problem von großer Bedeutung. Traditionelle PullTechnologien wie Suchmaschinen stoßen bei Kriterien wie Antwortzeiten, Umfang der Datengrundlage und Überwachung von Änderungen an Grenzen. Die beiden hier untersuchten Systeme verfolgen einen anderen Ansatz, um Zugriff auf große und dynamische Datenmengen zu ermöglichen. Anstatt auf Anfrage einen zuvor unspezifisch indizierten Datenbestand zu durchsuchen, benachrichtigen diese Systeme bei zuvor definierten Datenänderungen auf einer genau definierten Datenmenge. Über das Internet ist der Zugriff auf eine Vielzahl von Datenquellen möglich. Datenquellen im Internet stehen unter dem besonderen Aspekt der starken Heterogenität hinsichtlich Technologie, Schnittstellen, Struktur und Änderungsfrequenz. Daten liegen strukturiert in Datenbanken, halbstrukturiert als XML und unstrukturiert als HTML vor, d.h. mit Mischung von Daten und Repräsentation. Durch das Fehlen jeglicher semantischer Strukturierung ist die automatisierte Extraktion von Daten aus HTML-Dokumenten nur schwer realisierbar. Die Verwendung von XML verspricht eine Lösung dieser Problematik durch eine semantisch strukturierte, von der Repräsentation getrennte Formatierung. Im Rahmen der untersuchten Systeme spielt zwar auch der Zugriff auf Datenbanksysteme eine Rolle, wird aber nur am Rande behandelt. Der Schwerpunkt dieses Papiers liegt auf den Web-Dokumenten. Bei der Verarbeitung von Dokumenten aus dem WWW müssen also stark verteilte strukturierte, semistrukturierte und unstrukturierte Datenquellen gehandhabt werden. Ein weiteres Problem ist die Erkennung von Änderungsereignissen. Während bei vielen Datenbanksysteme eingebaute Trigger zur Erkennung von Änderungsereignissen genutzt werden können, existieren für http-Server keinerlei Benachrichtigungsmodelle nach dem Publish/Subscribe Modell. Hier kann lediglich durch regelmäßige Zugriffe auf die Datenquelle (Polling) und die kontinuierliche Durchwanderung der über Links verknüpften Dokumente (Crawling) eine Änderung der Dokumente erkannt werden. Dieses Papier stellt zwei Systeme vor (Conquer und Xyleme) und untersucht sie vergleichend. Der Fokus liegt dabei auf den Fähigkeiten verschiedenste Datenquellen anzusprechen und –1– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Ereignisse zu erkennen, Umfang und Mächtigkeit der Profildefinitionssprachen und die Skalierbarkeit der Systemen, d. h. die verwendete Systemarchitektur und Algorithmen. –2– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 2 Conquer Conquer [LPTH00] überwacht verteilte Datenquellen im WWW und sendet bei Veränderungen eine Benachrichtigung. Über quellenspezifische Wrapper wird auf verschiedenste strukturierte und semistrukturierte Daten zugegriffen und im System installierte Abfragen ausgeführt. Implementiert ist der Zugriff auf XML/HTML-Dokumente und relationale Datenbanken. Die Abfragen werden zeit- oder ereignisgesteuert wiederholt ausgeführt (Continual Query, CQ) und bieten durch Versionierung der Ergebnisse die Möglichkeit Veränderungen auszuwerten. Berichte über die Abfrageresultate werden dem Benutzer zeit- oder ereignisgesteuert per E-Mail zugesandt. 2.1 Systemarchitektur Abbildung 1: Conquer Systemarchitektur (ohne Client Tier) [LPTH00] Die Systemarchitektur von Conquer ist in drei Schichten (Tiers) aufgeteilt: Client, Server und Wrapper. Die Untersuchung des Clients ist nicht Bestandteil dieses Papiers und daher auch nicht in Abbildung 1 enthalten. Zusammenfassend gesagt kommuniziert der Client über das System Repository mit dem Server und stellt dem Benutzer eine Schnittstelle zum Verwalten von Abfragen zur Verfügung. Die untere Ebene ist die Wrapper Schicht. Sie besteht aus datenquellenspezifischen Adaptern, die eine einheitliche Schnittstelle zu den überwachten Daten realisieren und so Abfragen über –3– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. verschiedenste strukturierte und halbstrukturierte Daten ermöglicht. Ein Ereignisdetektor erkennt Datenänderungen und löst Benachrichtigungen aus. Hauptbestandteile des Conquer Servers sind der Continual Query Manager (CQM), der Trigger Condition Evaluation Manager (TCEM) und der Event Detection Manager (EDM). Der CQM koordiniert TCEM und EDM zur Erkennung von relevanten Datenveränderungen und verfolgt diese zu den entsprechenden Adaptern. Aufgabe des TCEM ist die Verarbeitung der vom EDM gemeldeten Ereignisse und Ermittelung betroffener CQs. Der EDM entscheidet wann und wie Ereignisse zu erkennen sind. Eine weitere wichtige Komponente ist der Transaction Manager zur Koordinierung nebenläufiger Prozesse. Alle drei Schichten können auf verschiedene Rechner verteilt werden. Das vorliegende Papier enthält keine näheren Informationen über Möglichkeiten der Verteilung, interessant wäre hierbei insbesondere, ob die Möglichkeit besteht, Schichten in mehreren nebenläufigen Instanzen auf verschiedenen Rechnern zwecks Loadbalancing zu betreiben. Conquer setzt Parallelverarbeitung und Nebenläufigkeit für verschiedene Prozesse ein. 2.2 Abfragesprache Conquer definiert eine eigene Abfragesprache. Jeder CQ ist ein Quadrupel bestehend aus einer Abfrage (Query Q), einem Trigger (Tcq) und einer Start- (Start) und Stopbedingung (Stop): CQ := (Q, Tcq, Start, Stop). Q ist eine SQL ähnliche Abfrage1, deren Ergebnis in der Benachrichtigung ausgeliefert wird. Sie wird ausgeführt, wenn die Bedingung Tcq wahr wird. Start und Stop beschreiben Zeitpunkte oder Bedingungen zur Steuerung der erstmaligen Auswertung und Beendigung des CQ. Nachdem ein CQ installiert ist, wird dieser entweder sofort (bei Weglassen von Start) oder beim Eintreffen der Startbedingung Start aktiv. Die konkrete Ausführung der Abfrage Q wird ausgelöst durch Tcq ¬Stop. Bei der erstmaligen Ausführung (erfolgt immer direkt nach Installation) wird das gesamte Ergebnis von Q zwischengespeichert und dient als Referenz für nachfolgenden Abfragen, die dann nur noch die Veränderungen zum vorherigen Ergebnis zurückliefern. 1 Syntax und Semantik werden in der verwendeten Literatur nicht näher erläutert –4– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Die Ereignisbedingungen für Tcq, Start und Stop können zeitbezogen, datenbezogen oder eine Kombination von beidem sein. Zeitbasierte Ereignisse sind: absolute Zeitangaben Zeitangaben relativ zu Ereignissen (x Sekunden nachdem Ereignis E eintritt) regelmäßige (alle x Tage) und unregelmäßige Intervalle (jeden ersten Tag des Monats) Datenbezogene Ereignisse sind: Prädikate auf Datenbankabfragen Beziehungen zwischen dem Ergebnis der vorherigen Abfrage und dem jetzigen Datenzustand (Trends, historische Daten) Externe Ereignisse Übergänge zwischen Status Conquer erlaubt die Eingrenzung der Zeitintervalle, in denen Q ausgeführt werden soll. Dies ermöglicht einen sparsamen Umgang mit Systemressourcen, zum Beispiel genügt bei der Überwachung von Aktienkurse der Zeitraum Montag bis Freitag während der Börsenöffnungszeiten. NotifyCondition legt den Zeitintervall für die Benachrichtigungen fest. Standardmäßig wird jedes Mal, wenn Q ausgeführt wird, eine Benachrichtigung erzeugt. Durch NotifyCondition kann ein Sammelbericht erzielt werden, zum Beispiel alle Lagerbestandsveränderungen eines Artikels innerhalb der letzten 24 Stunden. 2.3 Datenquellen und Ereigniserkennung Die Anbindung von Datenquellen wird durch quellenspezifische Wrapper realisiert. Diese Programme vermitteln zwischen der Datenquelle und dem Überwachungssystem. Es handelt sich dabei um verteilte Module, die am performantesten nahe an der zu überwachenden Datenquelle installiert werden. Sie abstrahieren die Datenquelle als Objektklassen, die in einer SQL ähnlichen Sprache wie Tabellen des relationalen Datenmodells abgefragt werden können. Des weiteren sind die Wrapper für die Installation des Ereignisdetektors zuständig, der Änderungen der Datenquelle an das System meldet. Durch die flexible WrapperArchitektur kann Conquer auf unterschiedlichste Datenquellen zugreifen. Neben XML/HTML Dokumenten handelt es sich um Datenbanksysteme oder externe Signalgeber (z.B. Temperatursensoren). Über das XWrap Werkzeug [LPH98] können Wrapper für XML, –5– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. HTML und Textdokumente erstellt werden, die durch Extrahierungs- und Transformierungsregeln aus den Quelldokumenten Daten gewinnen und semantisch eindeutig benannt zur Verfügung stellen. Jede Datenquelle mit den gleichen semantischen Dateninhalten gehört zu einer Objektklasse, zum Beispiel books für Objektklassen, die Informationen über Buchtitel zur Verfügung stellen. Jeder Wrapper ist auch über die genaue Adressierung per Name des Rechners, auf dem diese installiert ist, als einzelne Instanz der Objektklasse ansprechbar. [email protected] beschreibt die Objektinstanz von Buchinformationen des Onlinehändlers Amazon.com, [email protected] den Buchbestand der Bibliotheken der Freien Universität Berlin. In diesem Beispiel werden also Buchinformationen zweier sehr unterschiedlicher Systeme über eine einheitliche Schnittstelle mit definierten Datenfeldern bereitgestellt. Die Erkennung von Änderungsereignissen wird bei Datenbanksystemen über eine Kombination von Triggern und Polling realisiert, bei Quellen ohne eingebaute Benachrichtigungsmechanismen durch Polling. Der Event Detection Manager überwacht dabei nur genau diejenigen Ereignisse, die relevant für aktive CQs auf der überwachten Datenquelle sind. Aus den Abfragen werden die Datenfelder ermittelt, die zu überwachen sind. Sobald ein Änderungsereignis erkannt wird, findet eine Auswertung der beteiligten Trigger-Prädikate statt. Dabei ausgelöste Trigger werden an den Trigger Condition Evaluation Manager weitergeleitet, der die betroffenen CQs identifiziert. 2.4 Algorithmus: Trigger Pattern Matching Typischerweise wird nach der ersten Ausführung ein CQ nur dann ausgeführt, wenn der Trigger Tcq feuert. Die Auswertung der Trigger findet also ungleich öfter statt als die Abfrage Q und ist daher Ansatzpunkt für die Optimierung des Systems. Kritisch sind hierbei datenbasierte Ereignisse, da bei jeder regelmäßigen Auswertung der Bedingung ein Zugriff auf das Datenobjekt nötig ist. Da sich die Datenquellen üblicherweise auf anderen Rechner befinden, verursachen diese Zugriffe die größten Kosten. Es lässt sich beobachten, dass eine Vielzahl von CQs auf die gleichen Datenquellen zugreifen und sich oft für die gleichen Daten interessiert (z.B. der Kurs einer bestimmten Aktie auf einer Website mit Börseninformationen). Conquer gruppiert und indiziert gleichartige Trigger um die Anzahl der Zugriffe auf Datenquellen zu reduzieren. –6– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Dazu werden die atomaren Prädikate der Trigger-Bedingung (die WHEN Klausel) in die Konjunktive Normalform (KNF) gebracht, nach Datenquellen gruppiert und Operatoren und Konstanten durch generische Platzhalter ersetzt. Das resultierende generische Prädikat (Trigger Pattern), die Menge der referenzierten Datenquellen und die Ereignisse aus der ON EVENT Klausel (Zeitintervall und Update) bilden zusammen die Trigger Pattern Signature. Bei der Installation eines CQs wird nun zuerst überprüft, ob dessen Signatur bereits bekannt ist und diese ggf. neu registriert. Für alle CQs mit der selben Signatur wird nur ein Eintrag angelegt. Die konkreten Werte der durch Platzhalter ersetzten Operatoren und Konstanten der verschiedenen CQs werden in einer zusätzlichen Tabelle pro Signatur gruppiert. Alle Trigger der selben Gruppe können gemeinsam ausgewertet werden, der Zugriff auf die Datenquellen braucht lediglich einmal zu erfolgen. Zur weiteren Optimierung nutzt Conquer verschiedene Verfahren, um die Auswertung der Trigger-Signaturen zu verbessern. Dabei wird der Effekt ausgenutzt, dass viele unterschiedliche Signaturen gleiche Bestandteile enthalten. Bei rein konjunktiv verknüpften Prädikaten wird der „selektivste Term“ (most selective term) ermittelt. Dabei wird der Selektivitätsfaktor jedes atomaren Prädikats der Signatur betrachtet und dasjenige mit dem niedrigsten Faktor ausgewählt. Dabei hat der Gleichheitsoperator (=) die niedrigste Selektivität, übertroffen von den Bereichsoperatoren (≤, <, >, ≥) und dem Ungleichheitsoperator (<>). Für alle Signaturen desselben selektivsten Term wird dieser zuerst ausgewertet, erst danach folgt die Auswertung der verbleibenden Bestandteile der unterschiedlichen Signaturen. Tatsächlich wird also das Prinzip der Lazy Evaluation angewandt. Hierbei wird die Effektivität dadurch gesteigert, dass zuerst derjenige Term ausgewertet wird, bei dem die statistische Chance des Zutreffens am geringsten ist. Infolgedessen ist die Wahrscheinlichkeit am höchsten, die Auswertung frühzeitig abbrechen zu können. Als Ansatzpunkte für weitere Optimierungsmöglichkeiten werden kurz angerissen: die Auswertungsreihenfolge disjunktiv verknüpfter atomarer Prädikate und sehr teure Funktionen. –7– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 3 Xyleme Xyleme [NACP01] ist ein Warehousing-System für XML-Dokumente. Die Dokumente werden über das WWW aus externen Quellen eingelesen und in dem Repository eingelagert. Über den eingehenden Strom von Dokumenten und das Warehouse können sogenannte Abonnements (Subscriptions) installiert werden, die auf bestimmte Datenereignisse reagieren und Berichte im XML-Format erzeugen. Die Definition abstrakter Themenbereiche (Domains) und die automatische Zuordnung von Dokumenten in diese ermöglicht Abfragen über virtuelle Kataloge inhaltlich ähnlicher Daten. Das Laden und Überwachen von HTMLDokumenten ist ebenfalls möglich, diese werden aber nicht in das Warehouse eingelagert. 3.1 Systemarchitektur Abbildung 2: Architektur des Xyleme Abonnementsystems [NACP01] Gegenstand dieser Untersuchung ist das Abonnementsystem (Subscription System) des Xyleme Gesamtsystems. Dieses ist in generische (in Abbildung 2 innerhalb des Kastens) und für die Xyleme-Applikation spezialisierte Module aufgeteilt. Die generischen Module realisieren ein wiederverwendbares Überwachungssystem, das über spezialisierte Komponenten auf die konkrete Anwendung zugeschnitten wird. –8– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Die Alerter erkennen atomare Ereignisse in Dokumenten, wie zum Beispiel eine bestimmte URL, Schlüsselworte im HTML-Text oder in XML-Elemente. Der Monitoring Query Processor (MQP) empfängt die atomaren Ereignisse der Alerter und erkennt darin enthaltene zusammengesetzte Ereignisse (complex events), die zu einem Abonnement gehören. Die Trigger Engine löst zeit- oder ereignisgesteuerte Prozesse aus und realisiert die CQs. Aufgabe des Reporter ist die Verarbeitung der vom MQP erzeugten Benachrichtigungen über zusammengesetzte Ereignisse und Generierung entsprechender Berichte an die Nutzer, die entsprechende Abonnements über den Subscription Manager installiert haben. Die einzelnen Komponenten sind verteilbar, die Implementierung wurde auf einem LinuxCluster realisiert. Einige Module können zum Loadbalancing auf mehreren Maschinen laufen, z. B. Crawler, Loader und Reporter. 3.2 Abfragesprache Abonnements werden in einer SQL ähnlichen Sprache definiert und bestehen aus vier Bestandteilen: 1) Überwachungsabfrage über eingehende Dokumente (Monitoring Query, MQ) 2) Wiederholte Abfrage über Dokumente im Warehouse (Continual Query, CQ) 3) Definition des Inhalts und Formats der Benachrichtigung (Report) 4) Steuerung der Dokumentenaktualisierung (Refresh Statement) (1) und (2) sind in beliebigen Kombinationen möglich, jedoch muss mindestens eine Abfrage vorhanden sein. Die explizite Steuerung der Intervalle in denen ein Dokument von Xyleme eingelesen wird (4) ist nicht näher beschrieben. Standardmäßig werden Dokumente öfter eingelesen, die durch ein Abonnement überwacht werden. Über jedes eingehende Dokument wird die Überwachungsabfrage (1) ausgeführt. Sie ähnelt SQL und besteht aus der Definition der für den Bericht auszulesenden Daten (SELECT), der Datenquelle (FROM) und dem Prädikat (WHERE). Da immer nur genau ein Dokument betrachtet wird (self), ist FROM optional, kann aber zur Definition von Variablen auf Elementen des Dokuments genutzt werden. Berichte werden in XML ausgeliefert, daher definiert SELECT XML-Elemente, die entweder direkt aus dem Dokument stammen oder neu –9– MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. zusammengesetzt werden. Das Prädikat (WHERE) ist eine Konjunktion atomarer Prädikate, dabei können folgende Eigenschaften des Dokuments abgefragt werden: URL Präfix, gesamte URL, Dateiname interne Identifikationsnummern für DTD und Dokument, explizite DTD semantische Gruppe (Domain), in die Xyleme Dokumente intern klassifiziert Zeitpunkt der letzten Änderung, des letzten Zugriffs Dokumentenstatus (neu, ungeändert, geändert, gelöscht) Existenz einer Zeichenkette im ganzen Dokument oder in bestimmten XMLElementen oder Teilbäumen Veränderungen im XML-Baum (neue, geänderte, gelöschte Elemente) CQs (2) bestehen aus einer normalen Abfrage wie in (1) plus einer Bedingung, die den Zeitpunkt der Ausführung steuert. Als Datenquelle werden semantische Dokumentengruppen der im Warehouse eingelagerten Dokumente angegeben. Die Abfrage kann zeitgesteuert oder durch Ereignisse (Überwachungsabfragen) ausgelöst werden. Das Abfrageergebnis kann auf die Veränderung zum vorhergehenden Ergebnis eingeschränkt werden (Delta). Xyleme versieht diese Deltas mit internen Identifikationsnummern (XID), dadurch ist ein aktuelles Dokument durch Kombination einer alten Version plus der entsprechenden Deltas möglich. Benachrichtigungen werden mit (3) gesteuert. Es kann aus der Menge der für das Abonnement vorliegender Ereignisse ausgewählt, der Zeitpunkt der Benachrichtigung gesteuert und eine Archivierung für einen bestimmten Zeitraum veranlasst werden. Berichte können sofort beim Vorliegen eines Ereignisses, nach einer bestimmten Anzahl Ereignisse oder in Zeitintervallen erzeugt werden. Eine optionale Maximalanzahl von Ereignissen beschränkt den Umfang des Berichts. Die Bedingungen sind disjunktiv verknüpfungsfähig. 3.3 Datenquellen und Ereigniserkennung Datenquelle für MQs sind diejenigen XML- und HTML-Dokumente, die von dem System eingelesen werden. MQs werden hierbei jeweils über das einzelne Dokument zum Zeitpunkt des Einlesens ausgeführt. CQs werden hingegen über den gesamten Datenbestand des Warehouse ausgeführt, also nur XML-Dokumente. Steuerung ist durch Zeitintervalle oder ausgelöste Ereignisse (MQs) möglich. – 10 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Die Vorauswahl der eingelesenen Dokumente ist nicht direkt aus den Abfragen steuerbar. Möglich ist lediglich die Einschränkung auf bestimmte URLs, Dateinamen oder interne semantische Dokumentengruppen des Systems. Die Crawling-Strategie [MPAM01] ist hier also entscheidend für die Qualität der Abfrageergebnisse. Hierbei wird kurz gesagt die Erfassung des gesamten im Internet verfügbaren Bestands an XML-Dokumente angestrebt. XML-Dokumente werden durch die Verlinkungen untereinander gefunden, eingelesen und mit Gewichtungskennzahlen (s. u.) belegt, vergleichbar mit dem Suchalgorithmus der populären Internet-Suchmaschine Google [GOO]. Veränderungen werden also zu dem Zeitpunkt ermittelt, in dem das betreffende Dokument eingelesen wird. Die Einlesefrequenz wird durch drei Faktoren gesteuert: 1) Wichtigkeitsfaktor 2) Änderungsrate 3) Beteiligung an Abonnements. Je mehr Dokumente auf ein bestimmtes Dokument verweisen, desto höher ist der Wichtigkeitsfaktor des Dokuments. Dabei gilt der Verweis eines Dokuments mit einem höheren Wichtigkeitsfaktor mehr als der Verweis einer niedriger bewerteten Dokuments. HTML-Dokumente werden lediglich eingelesen, um Verweise auf XML-Dokumente zu finden. Daher ist hier der Wichtigkeitsfaktor entgegengesetzt definiert: Je größer die Anzahl der durch das Dokument referenzierten XML-Dokumente und je bedeutender deren Wichtigkeit, desto höher der Wichtigkeitsfaktor des Dokuments. HTML-Dokumente fungieren also lediglich als Quelle für Verweise auf XML-Dokumente und werden daher auch nicht eingelagert. Die Änderungsrate ist zuerst ein geschätzter Wert. Bei jedem Einlesen des Dokuments wird er dahingehend adaptiv korrigiert, die geschätzte Änderungswahrscheinlichkeit der vorgefundenen Veränderungsrate anzupassen. Dieser Ansatz unterstellt den Dokumenten im Internet eine gewisse Regelmäßigkeit in der Frequenz der Änderungen. Durch den dritten Faktor nehmen Abonnements Einfluss auf die Einlesefrequenz des Systems, entweder explizit über in der REFRESH Direktive genannte Dokumente mit einem Einleseintervall oder indirekt durch Referenzierung von Dokumenten oder URL-Präfixes in einem Abfrageprädikat. – 11 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 3.4 Algorithmus: Atomic Event Set Xyleme ist für die Auswertung mehrerer Millionen Abonnements auf einer ebenso großen täglich einzulesenden Dokumentenmenge ausgelegt. Die meisten Kosten entstehen hierbei durch die Erkennung atomarer und komplexer Ereignisse. Eine Analyse der Abonnements reduziert die Menge atomarer Ereignisse durch Zurückweisung von Abfragen, die zu unspezifische Prädikate enthalten: ausschließlich „schwache“ Ereignisse (Weak Events): Status neu und (un-)geändert Suche nach häufig vorkommenden Zeichenketten wie Artikel und Konjunktionen als URL-Präfix lediglich „http://“ (bezöge sich auf alle Dokumente) Zudem sind virtuelle Abonnements möglich, die auf Abfragen anderer Abonnements zugreifen. Diskutiert wird außerdem eine Analyse entweder a priori mittels eines geeigneten Kostenmodells oder a posteriori durch Untersuchung ausgeführter Abonnements. Die Zuordnung der durch ein Dokument ausgelösten atomaren Ereignisse (d.h. zutreffender Prädikate einer Überwachungsabfrage) zu den beteiligten Abonnements geschieht im Monitoring Query Processor (MQP). Der Algorithmus basiert auf einer Datenstruktur, die das Testen geordneter Mengen von atomaren Ereignissen optimiert. Verarbeitet wird die geordnete Menge durch ein Dokument ausgelöster atomarer Ereignisse. Es wird die Tatsache ausgenutzt, dass bestimmte atomare Ereignisse Bestandteil mehrerer komplexer sind. Abbildung 3 zeigt ein Beispiel der Struktur und ihrer Funktionsweise. Die Datenstruktur besteht aus mehreren Tabellen, die zur Optimierung als Hashtabellen implementiert sind. Alle Tabellen enthalten in geordneter Reihenfolge atomare Ereignisse ai. Diesem zugeordnet ist entweder ein komplexes Ereignis ci und/oder eine weitere Tabelle. Tabelle H ist Ausgangspunkt für den Algorithmus und enthält alle atomaren Ereignisse ai, die entweder für sich genommen schon für ein komplexes Ereignis stehen oder zusammen mit weiteren atomaren Ereignissen aj mit j > i Bestandteil eines komplexen Ereignisses sind. Im letzteren Fall zeigt das Element auf eine neue Tabelle Hj, für die aj das Präfix für alle darin enthaltenen atomaren Ereignisse ist. Der Aufbau dieser Tabellen Hw entspricht wiederum H, d.h. für enthaltene ak, die zusammen mit dem Tabellenpräfix Teil eines komplexen Ereignisses sind, wird ein Verweis auf eine entsprechende Tabelle eingetragen. – 12 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Abbildung 3: Ein Beispiel der verwendeten Datenstruktur Zum Auffinden der in der geordneten Menge A = {ai ... an} von atomaren Ereignissen eines Dokuments enthaltenen komplexen Ereignisse C – also Abfragen aus Abonnements – traversiert der Algorithmus die Baumstruktur rekursiv. Die Funktion Notif(T, S) liefert für jede Tabelle T und geordnete Ereignismenge S die Menge komplexer Ereignisse C: 1. C = {} 2. Für alle Elemente T[ak], ak S: a. ist T[ak] mit ci markiert, füge ci der Ergebnismenge C hinzu b. ist T[ak] mit einer Tabelle T’ verknüpft, füge Notif(T’, {ak+1 ... an}) der Ergebnismenge C hinzu Für eine Beispielmenge {a1, a3, a4} durchläuft der Algorithmus die Datenstruktur aus Abbildung 3 wie folgt: Notif(H, {a1, a3, a4}) = {c15} U Notif(H1, {a3, a4}) = {c15} U {c10} U Notif(H1,3, {a4}) = {c15} U {c10} U {c201} = {c10, c15, c201} Der Algorithmus hat laut [NACP01] eine Laufzeit in O(l * log k) mit der durchschnittlichen Anzahl atomarer Ereignisse pro komplexen Ereignis l und der durchschnittlichen Anzahl komplexer Ereignisse, die an dem selben atomaren Ereignis interessiert sind k. – 13 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 4 Vergleich In diesem Abschnitt werden die beiden Systeme miteinander verglichen. Ziel ist es herauszuarbeiten, welche Lösungsansätze und Funktionalitäten für das Monitoring verwendet werden. Behandelt werden Datenquellen/Ereigniserkennung und die Mächtigkeit der Abfragesprachen. Abschließend wird eine Bewertung der beiden Systeme vorgenommen. 4.1 Datenquellen und Ereigniserkennung Ein entscheidendes Merkmal eines Monitoring-Systems sind die Datenquellen, die angesprochen werden können. Wichtige Kriterien sind dabei die Art der ansprechbaren Quellen, die Abstraktion der jeweiligen Datenstruktur um eine einheitliche Abfragesprache einsetzen zu können und die Fähigkeit, Veränderungen der vorliegenden Daten effizient und zeitnah zu erkennen. Conquer bietet die Möglichkeit, neben Web-Dokumenten auch beliebige andere Datenquellen zu überwachen. Durch quellenspezifische Wrapper kann für semantisch zusammengehörige Objektklassen eine einheitliche Schnittstelle definiert werden. Wird der Wrapper mit dem Event Detection Manager nahe an die Quelle platziert, so können Ereignisse zeitnah erkannt werden. Der großen Flexibilität dieses Ansatzes hinsichtlich der Datenquellen stehen Einschränkungen gegenüber, die sich durch die tabellenähnliche Abstrahierung ergeben. Während dieser Ansatz für Datenbanken, Einzelwerte oder Dokumentsätze mit kleiner, uniformer Datenmenge pro Dokument bei großer Dokumentanzahl gleicher Struktur (z. B. Aktienkurse, Wettermeldungen) von Vorteil ist, so ist er ungeeignet für irreguläre, unstrukturierte Dokumente. Da pro Wrapper nur syntaktisch exakt passende Dokumente erfassbar sind, ist die überwachte Datenmenge von vornherein eingeschränkt. Die individuelle Generierung der Wrapper erfordert eine gute Kenntnis der Datenquelle und schnelle Reaktion auf strukturelle Änderungen. Xyleme hingegen ist im Grunde auf XML-Dokumente eingeschränkt, HTML-Dokumente können nur rudimentär überwacht werden. Während Conquer Datenquellen als Tabellen abstrahiert, geschieht dies bei Xyleme in der Form von XML-Bäumen. Vergleichbar dem Konzept der Objektklasse in Conquer ist hierbei die semantische Gruppe (Domains, Views). Diese ordnen XML-Dokumente mit ähnlichem Inhalt und Struktur einer abstrakten DTD zu. Dadurch sind einheitliche Abfragen über Mengen von XML-Dokumenten möglich, deren – 14 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. unterschiedliche DTDs dies eigentlich nicht zulassen. Diese Funktionalität hängt allerdings stark von der Qualität der automatischen Zuordnung ab.2 Die potentielle Erfassung des gesamten Bestands an XML-Dokumenten im Web bedeutet auf der einen Seite die Gefahr der Überflutung mit uninteressanten Dokumenten und die Verzögerung der Erkennung von Änderungsereignissen, auf der anderen Seite aber eine sehr flexible und umfassende Datenbasis. Da Xyleme nicht per Wrapper auf Datenquellen angepasst werden muss, werden auch Ereignisse an zuvor nicht bekannten Datenquellen erkannt. Zusammenfassend lässt sich also sagen, dass Conquer für zeitkritische Überwachung vorab definierter Datenquellen geeignet ist, während Xyleme die eigenständige Überwachung semantisch eindeutiger, kategorisierbarer aber nicht vorhersehbarer Mengen von XMLDokumenten unterstützt. Xyleme ist mehr Suchmaschine mit dem Nebeneffekt der Überwachung, während Conquer explizit für Überwachungsaufgaben ausgelegt ist. 4.2 Abfragesprache Das Profil3, mit dem der Nutzer seine Interessen gegenüber dem Benachrichtigungssystem ausdrückt, besteht aus mehreren Teilen, die im Nachfolgenden näher untersucht und verglichen werden: 1) Abfrage 2) Überwachte Ereignisse 3) Überwachungsstrategie (Zeitliche Granularität, Start/Stop, Einschränkungen) 4) Parameter zur Steuerung der Benachrichtigung Es gibt grundsätzliche Unterschiede zwischen den Profilen in den beiden untersuchten Systemen. Conquer arbeitet nur mit CQs. Profile in Xyleme enthalten neben den CQs auch Monitoring Queries (MQs), die den Strom der eingelesenen Dokumente überwachen. Ein MQ ist von einem CQ in einigen Punkten verschieden. Zum einen gibt es keine auslösenden Ereignisse. Wird ein Dokument eingelesen, so ist der Zeitpunkt gegeben, die Daten werden direkt über das Prädikat gefiltert. Des weiteren ist die Datenquelle, auf die sich die 2 In der verwendeten Literatur fanden sich keine näheren Erläuterung zu dem verwendeten Algorithmus. 3 Vgl. [H01]. Hier existieren verschiedene Terminologien: Xyleme verwendet den Begriff Abonnement (Subscription), Conquer kontinuierliche Abfrage (Continual Query). – 15 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Ereigniserkennung bezieht und aus der Daten gelesen und verarbeitet werden können, auf das aktuelle Dokument beschränkt. Während sich die CQs also auf eine Menge von Dokumenten bezieht, ist das MQ auf ein einzelnes beschränkt. In Xyleme entspricht der MQ syntaktisch dem CQ, bei Wegfall der Definition des auslösenden Ereignisses. Das aktuelle Dokument (self) muss nicht explizit angegeben werden, es können aber Elemente oder Teilbäume des XML-DOM zur Verbesserung der Übersichtlichkeit mit Namen belegt werden. Durch die einheitliche Abstraktion der Datenquellen als Tabellen entsprechend eines RDBMS entspricht die Abfrage in Conquer einer SQL Datenbankabfrage. Datenquellen sind Objektklassen und –instanzen, d. h. Wrapper von Datenquellen. Es können die von den Wrappern bereitgestellten Datenfelder ausgewählt und im Abfrageprädikat referenziert werden. Im Gegensatz zu Xyleme ist kein Zugriff auf Statusinformationen der Datenquellen möglich. Eine Abfrage nach allen Wertetupeln, die sich seit dem letzten Zugriff geändert haben, ist nicht möglich. Daher muss bei Conquer in dem Ereignisprofil, das die Abfrage auslöst, sehr genau spezifiziert sein, bei welchen zeitlichen und inhaltlichen Ereignissen die Abfrage ausgeführt wird. Bei Xyleme ist die Vorgehensweise etwas anders. Bei den MQs ist das Einlesen des Dokuments das primäre Ereignis und es werden in der Abfrage inhaltliche Ereignisse definiert, wie zum Beispiel das Vorliegen eines neuen XML-Elements. Die CQs werden zeit- oder durch MQs gesteuert ausgeführt. Xyleme erlaubt in CQs weiterhin die Angabe mehrerer Datenquellen (semantische Dokumentgruppen) entsprechend dem Join in SQL. Die Ergebnismengen der beiden Systeme sind entsprechend des jeweiligen Datenquellenmodells verschieden. Während Conquer alle Quellen als Tabellen behandelt und demgemäss Datentupel zurückgibt – also eine neue Tabelle –, liegen für Xyleme alle Daten in XML strukturierten Dokumente vor. Das Abfrageergebnis ist auch ein XML-Dokument, das Elemente und Teilbäume der Quelldokumente sowie neu zusammengesetzte Elemente enthalten kann. Durch das Schlüsselwort Delta kann Xyleme dazu veranlasst werden, nur die Veränderungen zur jeweils vorhergehenden Ergebnismenge als Ausgabe zu generieren. Dieses besteht aus den neu hinzugefügten, geänderten und gelöschten XML-Elementen versehen mit internen Identifikationsnummern (XID). Zusammenfassend lässt sich also sagen, dass die von Xyleme erzeugte Ergebnismenge besser für die Verfolgung von inhaltlichen Änderungen an Dokumenten geeignet ist, während – 16 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Conquer durch das Paradigma der tabellenartigen Datenquellen für die Benachrichtigung mit ausgewählten Werten ausgelegt ist. Grundsätzliche Unterschiede zwischen den Systemen bestehen in der Art der Ereignisse, die definiert werden können. Xyleme kann lediglich erkennen, dass sich Daten in einem Dokument geändert haben, nicht jedoch innerhalb welches Werterahmens. Das MQ wird bei Eintreffen eines Dokumentes ausgelöst und kann ermitteln, ob und welche Teile des Dokumentes sich geändert haben. Daraufhin ist es möglich, ein CQ auszulösen, das ein Delta relevanter Daten ermittelt. Es sind aber keine Prädikate möglich, die erkannte Änderungen auswerten und auf Trends reagieren. Bei Conquer gibt es hingegen Funktionen, die Veränderungen zwischen den aktuellen und vorhergehenden Werten auswerten, zum Beispiel prozentuale Abweichungen. Xyleme kann also Benachrichtigungen erzeugen, die Veränderungen der überwachten Dokumente historisch nachzeichnen, jedoch bleibt die inhaltliche Auswertung dem Benutzer überlassen. Eine weitere Einschränkung bei Xyleme ist die ausschließliche konjunktive Verknüpfung atomarer Ereignisse. Dies ergibt sich durch den verwendeten Algorithmus zur Erkennung komplexer Ereignisse. Beide Systeme sind nicht in der Lage passive Ereignisse [H01] zu erkennen, d. h. das Nichteintreten eines Ereignisses in einem bestimmten Zeitraum. Unter der Überwachungsstrategie versteht man Parameter zur Steuerung des Abfragezeitraums und der zeitlichen Granularität. Xyleme und Conquer ermöglichen beide die explizite Angabe eines Auffrischungsintervalls für Datenquellen, also die maximale Verzögerung, mit der Veränderungen erkannt werden. Bei Conquer können der Zeitpunkt der ersten Evaluation (Start) und eine Bedingung für die folgenden Ausführungen (Stop) festgelegt werden. Zusätzlich können zusätzliche Zeitfenster definiert werden (Calendar), in denen das CQ nicht ausgeführt werden soll. Die von den Systemen erzeugten Benachrichtigungen werden über mehrere Parameter gesteuert. Zur Zeit lediglich einfach implementiert aber prinzipiell als flexibel betrachtet werden Format und Protokoll für die Übertragung. Das Format beider Systeme ist XML, das per E-Mail versandt wird. Mechanismen zur zuverlässigen Auslieferung des Reports (Guaranteed Delivery) [HF99] sind nicht implementiert. Neben der sofortigen Benachrichtigung unterstützen beide Systeme die Verzögerung der Benachrichtigung bis zu einem wohldefinierten Zeitpunkt, es ist eine unabhängige Steuerung von Ereigniserkennung und Benachrichtigung möglich. Während Conquer lediglich Zeitintervalle erlaubt, kann – 17 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Xyleme zusätzlich beim Vorliegen einer bestimmten Anzahl von Ereignissen, also MQs mit nichtleeren Ergebnismengen, die Benachrichtigung auslösen. Diese auslösenden Ereignisse sind sowohl konjunktiv wie auch disjunktiv verknüpfbar. Eine Beschränkung der Datenmenge ist ebenfalls möglich. Die Inhalte der Benachrichtigung bestehen bei Xyleme aus der Menge der durch das Profil ausgelösten Ereignisse mit den jeweilig ausgewählten Daten. Es ist möglich, aus dieser Menge Elemente zu selektieren und in das gewünschte Format zu transformieren. Conquer unterstützt diese Funktionalität nicht. 4.3 Bewertung Aus Anwendersicht sind Conquer und Xyleme für unterschiedliche Szenarien geeignet. Betrachtet man die folgenden zwei Profile, so lässt sich feststellen, dass (1) nur durch Conquer und (2) nur durch Xyleme überwacht werden kann: 1) Benachrichtige mich Mo-Fr von 9-17h sofort über den aktuellen XETRA-Börsenkurs der Deutschen Telekom, insofern dieser um mehr als 5% gestiegen ist. 2) Überwache alle Dokumente, in denen das Element „author“ die Zeichenkette „T. C. Boyle“ enthält. Benachrichtige mich bei neuen Dokumente sofort, bei geänderten Dokumenten erst bei 20 vorliegenden Änderungen. Hier werden die grundsätzlichen Unterschiede deutlich, die durch das ungleiche Konzept der Datenquellen und die verschiedenen Möglichkeiten der Abfragesprachen entstehen. Für eine abschließende Bewertung lege ich den Fokus auf die Überwachung von Dokumenten, insbesondere XML. Der Ansatz von Conquer, die Heterogenität der Quellen durch Wrapper zu überwinden, schränkt die Einsatzmöglichkeiten für den Anwender auf vorgegebene Datenquellen ein, des weiteren kann die tabellenförmige, uniforme Abstrahierung der Daten die Baumstruktur von XML nicht abbilden. Xyleme hingegen ist ausdrücklich auf die Verarbeitung von XML und die Erfassung aller Dokumente des Internets ausgerichtet. Entscheidend für die Auswahl eines Systems ist also Form und Umfang, in dem die Daten vorliegen und die Frage, ob eine inhaltliche Auswertung erforderlich ist. Letzteres kann nur Conquer über die Trendfunktionen (DECBYPERC etc.) leisten. Aus softwaretechnischer Sicht betrachtet ist Conquer für die zeitkritische Überwachung vorab definierter Datenquellen geeignet. Eine Nutzung als Middleware (z. B. Lagerverwaltung) ist – 18 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. denkbar. Xyleme kann eigenständig die Überwachung von Mengen hochdynamischer XMLDokumenten und deren Kategorisierung leisten und bietet sich als Bestandteil eines Informationssystems an, z. B. einer Datenbank von wissenschaftlichen Arbeiten und Artikeln. – 19 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 5 Literaturverzeichnis [ACVW00] V. Aguilera, S. Cluet, P. Veltri, D. Vodislav und F. Wattez. Querying XML Documents in Xyleme. ACM-SIGIR2000 Workshop, 2000. [CQN] Conquer website. http://www.cse.ogi.edu/DISC/CQ/. [GOO] Google Search Technology. http://www.google.com/technology/. [H01] A. Hinze. Does Alerting have special Requirements for Query Languages? Tagungsband zum 13. GI-Workshop Grundlagen von Datenbanken. Fakultät für Informatik, Universität Magdeburg, Preprint Nr. 10, Juni 2001. [HF99] A. Hinze and D. Faensen. A Unified Model of Internet Scale Alerting Services. Technical Report, Number tr-b-99-15, Institut für Informatik, Freie Universität Berlin, 1999. [LPH98] L. Liu, C. Pu, W. Han. Xwrap: An XML-enabled Wrapper Construction System for Web Information Sources. Technical Report, ODI/CSE, October 1998. [LPTH00] L. Liu, C. Pu, W. Tang und W. Han. Conquer: A Continual Query System for Update Monitoring in the WWW. International Journal of Computer Systems, Science and Engineering, 2000. [LPT99] L. Liu, C. Pu und W. Tang. Continual Queries for Internet Scale EventDriven Information Delivery. IEEE Knowledge and Data Engineering, 1999. Special Issue on Web Technology. [LPT98] L. Liu, C. Pu und W. Tang. Conquer: An Architecture for a Distributed Push-enabled Data Management System. Technical Report, OGI/CSE, March 1998. [MPAM01] L. Mignet, M. Preda, S. Abiteboul, B. Amann und A. Marian. Acquisition and Maintenance of XML Data from the Web. Technical Report, – 20 – MONITORING VON WEB-DOKUMENTEN Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. 2001. [NACP01] B. Nguyen, S. Abiteboul, G. Cobena, M. Preda. Monitoring XML Data on the Web. SIGMOD Record, 2001. [SHF00] H.Schweppe, A. Hinze and D. Faensen. Event-based Notification in the WWW. Tutorial der 9th International World Wide Web Conference. Institut für Informatik, Freie Universität Berlin, 2000. [XYL01] Xyleme Research Group. A dynamic warehouse for XML data of the Web. IEEE Data Engineering Bulletin, 2001. [XYL] Xyleme websites. http://www.xyleme.com/, http://www-rocq.inria.fr/verso/xyleme/ – 21 –
