PUBLISH/SUBSCRIBE-SYSTEME IM DATA-WAREHOUSING: MEHR ALS NUR EINE RENAISSANCE DER BATCH- VERARBEITUNG

PUBLISH/SUBSCRIBE-SYSTEME IM DATA-WAREHOUSING: MEHR ALS NUR EINE RENAISSANCE DER BATCH- VERARBEITUNG W. Lehner, W. Hümmer, M. Redert, C. Reinhard Universität Erlangen-Nürnberg - Lehrstuhl für Datenbanksysteme Martensstr. 3, D-91058 Erlangen {lehner, huemmer, mlredert, cnreinha}@immd6.informatik.uni-erlangen.de Kurzfassung Der Erfolg von Data-Warehouse-Systemen weckt neue Anforderungen, die in künftigen Data-Warehouse-Architekturen berücksichtigt werden müssen. Dieses Papier motiviert die Erweiterung der klassischen Data- Warehouse-Architektur um eine Publish/Subscribe -Komponente, um eine nachrichtenzentrierte Informationsversorgung und eine angebotsgetriebene Informationsbereitstellung im Kontext eines integrierten Informationssystems zu ermöglichen. Um diesen Anspruch zu konkretisieren, wird als Beispiel eines Publish/Subscribe -Systems das PubScribe-Projekt vorgestellt. Dabei wird auf die logische Architektur, das Verarbeitungsmodell und die prototypische Realisierung eingegangen. Es zeigt sich, dass der PubScribe-Ansatz, basierend auf einem strikten Rollenkonzept in Kombination mit einer komplexen Verarbeitungslogik, als solider Baustein eines integrierten Informationssystems positioniert werden kann.

66 1. Einleitung 1 Einleitung Ein Data-Warehouse stellt - im wesentlichen - eine integrierte und historisierte Datenbasis über eine Vielzahl partizipierender Quellsysteme dar. Im Gegensatz zum query shipping - Ansatz im der Bereich der föderativen Datenbanksysteme ([Conr97]), erfolgt im Data-Warehouse-Ansatz eine physische Integration und Historisierung lokaler Datenbestände (Abbildung 1.1). Einem Benutzer zeigt sich aus funktionaler Perspektive ein Data-Warehouse-System aus folgenden Blickwinkeln: Systemzentrierte Informationsversorgung: Um Informationen aus dem Datenbestand abzuleiten, ist der Einsatz spezieller Analysewerkzeuge beispielweise für die interaktive Datenexploration Online Analytical Processing (OLAP) oder das Aufdecken von (Un-)Regelmäßigkeiten im Rahmen eines Data-Mining-Prozesses, etc. notwendig. Nachfragegetriebene Informationsbereitstellung: Da das klassische Data-Warehouse-Konzept eine explizite Integration von Quellsystemen in einen Data-Warehouse-Datenbestand vorsieht, werden neue Quellsysteme lediglich auf Wunsch bzw. Drängen der Benutzer hin integriert. Um der Vision einer umfassenden Informationsversorgung im Kontext der Next-Generation Data-Warehouse-Systeme ein Stück näher zu kommen, werden beide Perspektiven mit neuen Anforderungen und deren Auswirkungen konfrontiert: Benutzer Publish/ Subscribe - Komponente Öffnung des Data-Warehouse-Systems: Während die ursprüngliche Idee des Data Warehousing darin bestand, organisationsintern eine konsolidierte Datenbasis zur Entscheidungsfindung zu etablieren ([Inmo96]), wird der Dienst Data-Warehouse immer interessanter für weiter gefasste Benutzer- Auswertungsbezogene Datenbank (denormalisiert, Summendaten) Externe Datenquellen Basisdatenbank (normalisiert, Detaildaten) Datenbeschaffung (Extraktion, Transformation,...) Data-Warehouse-System Quellsysteme Abb. 1.1: Data-Warehouse-Architektur mit Publish/Subscribe -Komponente

1 Einleitung 67 gruppen, sowohl organisationsintern als auch als Gegenstand externer Vermarktung. Eine Öffnung insbesondere zum Internet wird in einer Explosion der Benutzerzahlen resultieren, die es bei gleichbleibender Dienstequalität zu versorgen gilt. Flexible Integration externer Datenquellen: Es ist zu erwarten, dass für komplexe Analysen im steigenden Maß auf externe Informationen beispielsweise zur Durchführung anwendungsspezifischer Vergleiche benötigt werden. Damit wird sich die Möglichkeit der dynamischen Integration externer Datenquellen, insbesondere Web-Seiten, als eine zentrale Anforderung ergeben. In diesem Beitrag schlagen wir die Erweiterung der klassischen Data-Warehouse-Architektur, wie sie in Abbildung 1.1 nach [BaGü00] skizziert ist, um eine Publish/Subscribe -Komponente vor und konkretisieren den Vorschlag am Beispiel des PubScribe-Projektes. Das Publish/Subscribe -Verarbeitungskonzept Allgemein bietet der Ansatz des Publish/Subscribe einen robusten und skalierbaren Mechanismus zur Kommunikation loose gekoppelter Systeme ([Birm93], [Powe96]). Publish/ Subscribe steht dabei im Gegensatz zum klassischen Verarbeitungskonzept des Request/ Response (Abbildung 1.2a). Im Request/Response -Ansatz wendet sich der Benutzer direkt an einen Diensterbringer, um einen gewissen Dienst anzufordern. Während der Bearbeitung ist der Dienstnehmer blockiert, so dass der Diensterbringer im allgemeinen auf ein effizientes Erbringen des Dienstes ausgerichtet ist. Die direkte Kommunikation zwischen Produzent und Konsument wird im Publish/Subscribe -Ansatz durch Einführung einer Vermittlungskomponente aufgeweicht. Produzenten ( Publisher ) publizieren Informationen aus eigenem Antrieb an das Subskriptionsmanagementsystem. Konsumenten ( Subscriber ) hinterlegen einmalig ihre Anforderungen in Form einer Subskription und werden über neue Publikationen gemäß spezifizierter Auslieferungsbedingungen unterrichtet. request response publish subscribe deliver Eine Anreicherung der klassischen Data-Warehouse-Architektur um eine Publish/Subscribe -Komponente verspricht eine solide Basis, die die zuvor aufgestellten Anforderungen ergänzend zu bestehenden Request/Response -Ansätzen in folgender Form zu erfüllen verspricht: Subskriptions- Produzenten Konsumenten Publisher Management- Subscriber System a) Request/Response -Ansatz b) Publish/Subscribe -Ansatz Abb. 1.2: Vergleich von Request/Response und Publish/Subscribe

68 1. Einleitung Übergang zu einer nachrichtenzentrierten Informationsversorgung: Im Kontext des Publish/Subscribe steht nicht mehr das Auswertesystem, sondern die Auswertungen in Form von Benachrichtungen im Zentrum des Interesses. Durch die registrierten Subskriptionen ist es dem System möglich, ähnliche Subskriptionen gemeinsam auszuwerten oder Subskriptionszustände inkrementell zu warten, so dass eine weitreichende Optimierung der Verarbeitung ermöglicht wird. * Übergang zu einer angebotsgetriebenen Informationsbereitstellung: Analog zu neuen Nachrichten, ist es dem Publish/Subscribe -Ansatz inhärent zu Eigen, dass neue Produzenten auftreten und am System partizipieren. Die explizite Integration von Datenquellen auf klassischem Weg wird entsprechend um angebotsgetriebene Datenlieferanten erweitert. Publish/Subscribe läßt sich in einer Vielzahl von Anwendungsszenarien auf unterschiedlichen Ebenen einer Dienstehierarchie einsetzen (Abschnitt 5). Im Kontext der Datenbanksysteme wurde Publish/Subscribe bisher deutlich vernachlässigt, erfreut sich jedoch einer immer breiteren Unterstützung sowohl im Bereich der Forschung (Continual Query Project, [PuLi98]) als auch auf dem Gebiet kommerzieller Systeme ([Orac99], [IBM00]). Bezogen auf das Anwendungsgebiet des Data Warehousing läßt sich feststellen, dass durch Einführung einer Subskriptionstechnologie bereits ein großer Teil des Informationsbedürfnisses der Data-Warehouse-Benutzer gestillt werden kann. Detaillierte und spezifische Analysen blieben weiterhin den Werkzeugen zur Exploration von Datenbasen vorenthalten. Das PubScribe-System Neben der Motivation von Publish/Subscribe -Systemen im Bereich des Data-Ware-housing im allgemeinen, beschäftigt sich dieser Beitrag im speziellen mit dem System PubScribe als konkrete Realisierung der zuvor aufgestellten Forderungen. PubScribe weist folgende Eigenschaften als Abgrenzung zu verwandten Arbeiten und Projekten auf: Rollenmodell: Der PubScribe-Ansatz befolgt ein striktes Rollenkonzept hinsichtlich Produzenten ( Publisher ) und Subskribenten ( Subscriber ). Jede am System partizipierende Komponente kann situationsbezogen eine Rolle annehmen, wodurch sämtliche Kommunikationsvorgänge zwischen Teilkomponenten auf Basis des Publish/Subscribe -Ansatzes modelliert und realisiert werden können. Komplexe Verarbeitungslogik und lokale Speicherung: Als Erweiterung der reinen Vermittlung (und ggf. Filterung) von Nachrichten zwischen Publisher und Subscriber ist das PubScribe-System mit einer vollständigen Verarbeitungslogik ausgestattet, so dass komplexe Analysen als Subskriptionen im System hinterlegt werden können. * Dem aufmerksamen Leser ist sicherlich nicht die im Titel beschworene Analogie zur Batch-Verarbeitung entgangen. Obwohl sich die Grundideen beider Ansätze auf hohem Abstraktionsniveau durchaus ähneln, hebt sich das Verfahren des Publish/Subscribe doch erheblich in der Qualität des Dienstes und der Methode der Diensterbringung gegenüber der einfachen Stapelverarbeitung ab.

2 Logische PubScribe Architektur 69 Inhalt XML-basierte Realisierung: Der Nachrichtenaustausch zwischen Komponenten und Modulen einzelner Komponenten ist XML-basiert realisiert, was eine flexible Erweiterung und Adaption ermöglicht. Im folgenden Abschnitt wird die logische Architektur des PubScribe-Systems vorgestellt, wobei auf die einzelnen Komponenten, unterschiedliche Subskriptionstypen und das Rollenkonzept eingegangen wird. Abschnitt 3 skizziert das Verarbeitungsmodell des PubScribe-Systems. Vorgestellt werden Sequenzoperatoren, die auf eingehende Nachrichten angewendet werden um so die jeweiligen Ausprägungen von Subskriptionen zu ermitteln. Abschnitt 4 schließlich reflektiert in aller gebotenen Kürze die Implementierungsarchitektur. Bevor der Beitrag mit einer Zusammenfassung und einer Darstellung aktueller und geplanter Arbeiten schließt, enthält Abschnitt 5 eine kurze Charakterisierung verwandter Arbeiten und Projekte. 2 Logische PubScribe Architektur Wie aus Abbildung 2.1 ersichtlich ist, basiert die logische Architektur des in diesem Beitrag vorgestellten PubScribe-Systems auf dem 3-Schema-Architekturmodell für Datenbanksysteme nach ANSI/SPARC ([TsKl78]), in welchem eine Datenunabhängigkeit und Datenneutralität zwischen den internen und externen Schemata durch Einführung eines einzigen konzeptionellen Schemas realisiert wird. Die einzelnen Komponenten, bzw. Rollen, die Komponenten annehmen können (Abschnitt 2.4), werden im folgenden jeweils einer Schicht zugeordnet und ausführlich beschrieben. Externe Schemata (subskriptionsspezifisch) XML XML XML XML Subscriber- Komponenten mit registrierten Subskriptionen Auslieferungskomponente Konzeptionelles Schema Publikationsmodul Broker-Kern Subskriptionsmodul Vermittungsund Verarbeitungskomponente Interne Schemata (kanalspezifisch) Timer Data-Warehouse WebSite Basisdatenbank Abb. 2.1: Logische Architektur des PubScribe-Systems Publisher- Komponenten mit publizierten Nachrichten

70 2. Logische PubScribe Architektur 2.1 Ebene der Internen Schemata Auf der Ebene der internen Schemata finden sich die produzierenden Einheiten (Publisher) mit jeweils einem spezifischen, von ihnen frei gewählten Schema für die von ihnen publizierten Nachrichten. Eine Datenquelle muss sich vor der ersten Publikation bei der Vermittlungskomponente registrieren und sowohl das Schema der zukünftigen Publikationen als auch die maximale Veröffentlichungsfrequenz angeben. Weiterhin gibt ein Publisher an, ob er Initialauswertungen ermöglicht. Initialauswertungen sind bei ex-nunc-subskriptionen erforderlich und werden im nachfolgenden Abschnitt 2.2 erläutert. Die Registrierung selbst erfolgt durch ein XML-Dokument, welches der Vermittlungskomponente übergeben wird. Diese validiert die Anforderungen gemäß der entsprechenden DTD und eröffnet einen neuen Informationskanal für diesen Publisher. Ein Publisher ist nun dafür verantwortlich, bei Bedarf Nachrichten zu publizieren. Dazu formuliert die Vermittlungskomponente zu einer oder mehreren bei ihr eingegangenen Benutzersubskriptionen eine generische Subskription an diesen Produzent. Diese Methode, wie sie nur das in Abschnitt 2.4 eingeführte Rollenkonzept ermöglicht, verhindert eine Resourcenverschwendung für den allgemein in Publish/Subscribe -Systemen ungünstigen Fall, dass Nachrichten publiziert werden, ohne, dass Abnehmer für diese Nachrichten existieren. Das generelle Verfahren der bedarfsgesteuerten Publikationen ist detailliert unter dem Begriff der Communication Patterns in [LeHR00] beschrieben und wird in Rahmen dieses Beitrags nicht weiter vertieft. 2.2 Ebene der Externen Schemata Die Ebene der Externen Schemata reflektiert die im System registrierten (Benutzer-) Subskriptionen, wobei sich eine Subskription aus vier beliebig komplexen Operatorengraphen zur Repräsentation folgender Subskriptionskomponenten zusammensetzt: Rumpf der Subskription ( subscription body ) Startbedingung ( opening condition ) Stoppbedingung ( closing condition ) Auslieferungsbedingung ( delivery condition ) Ein Operatorengraph in PubScribe ist ein azyklischer Graph, dessen Knoten Operatoren und Kanten Sequenzen von Nachrichten widerspiegeln. Die Blattknoten eines Operatorengraphen repräsentieren die im System vorhandenen Informationskanäle, die von angemeldeten Publisher-Komponenten versorgt werden (Abschnitt 2.1). 1 Startbedingung erfüllt Stoppbedingung nicht erfüllt Auslieferungsbedingung 2 erfüllt 3 Auslieferungsbedingung nicht erfüllt 4 Stoppbedingung nicht erfüllt Stoppbedingung erfüllt Abb. 2.2: Zustände und Zustandsübergänge einer 5 Stoppbedingung erfüllt

2.2 Ebene der Externen Schemata 71 Der Lebenszyklus einer Subskription ist in Abbildung 2.2 in Form eines Zustandsübergangsdiagramms visualisiert. Nach dem Eintreffen einer Subskription wird der Operatorengraph für die Startbedingung dem globalen Operatorengraph des Systems hinzugefügt. Ist die Startbedingung erfüllt, so wird sie aus dem System entfernt und die Auslieferungs- und Stoppbedingung instantiiert. Wird durch das Eintreffen neuer Nachrichten die Auslieferungsbedingung erfüllt, so wird der Rumpf der Subskription ausgewertet; tritt die Stoppbedingung ein, so wird die Subskription vollständig aus dem System entfernt. Ein weiterer Aspekt, den es im Kontext von Subskriptionen im PubScribe-Projekt auf Ebene der Externen Schemata zu adressieren gilt, ist die Klassifikation von Subskriptionen. Grundsätzlich werden in PubScribe drei Arten von Subskriptionen unterschieden: Snapshot -Subskriptionen: Eine Snapshot-Subskription kann erfüllt werden, indem immer nur auf die aktuell gültige, d.h. die neueste Nachricht eines Publishers Bezug genommen wird. Die Anforderungen an den Publisher sind für diese Art von Subskriptionen minimal. Ex-Nunc -Subskriptionen: Wie die nachfolgenden Ex-Tunc-Subskriptionen, beziehen sich Subskriptionen vom Typ Ex-Nunc auf eine Menge von Nachrichten eines Kanals. Dabei wird das Sammeln der Nachrichten zu Beginn der Subskription begonnen. Der anfangs leere Arbeitsbereich füllt sich mit eintreffenden Nachrichten, über die dann jeweils der Rumpf der Subskription ausgewertet wird. Die Speicherung der gesammelten Informationen kann entweder vom Publisher oder vom Subskriptionssystem übernommen werden. Ex-Tunc -Subskriptionen: Ex-Tunc-Subskriptionen erfordern, dass die Menge der zur Beantwortung der Subskription erforderlichen Nachrichten bereits nach der erfüllten Startbedingung vollständig vorliegt, d.h. das Sammeln von Informationen muss bereits vor Subskriptionsstart begonnen haben. Um dies zu ermöglichen, muss der Publisher einen Rückgriff auf historisierte Datenbestände ermöglichen. Somit ist in diesem Fall der Anspruch an den Publisher am höchsten. Für Ex-Tunc -Subskriptionen wird eine Initialauswertung in Form einer Synchronisierungssubskription von der Vermittlungskomponente an den entsprechenden Publisher formuliert um die zur Auswertung notwendigen historischen Datenbestände zu ermitteln. Eine Synchronisierungssubskription kennzeichnet sich dadurch aus, dass ihre Start-, Stopp- und Auslieferungsbedingung wahr sind und der Rumpf sofort nach der Registrierung ausgewertet, die resultierende Nachricht ausgeliefert und die Subskription wieder aus dem System entfernt wird.

72 2. Logische PubScribe Architektur 2.3 Ebene des Konzeptionellen Schemas Das Äquivalent zum konzeptionellen Schema im 3-Schema-Architekturmodell nach ANSI/ SPARC ist im Kontext der logischen Architektur des PubScribe-Systems in der Vermittlungsund Verarbeitungskomponente zu sehen. Aus konzeptioneller Sichtweise spiegelt diese Komponente die zentrale Einheit wider, die die Entkopplung von Produzent (Publisher) und Konsument (Subscriber) realisiert. Analog zur logischen und physischen Datenunabhängigkeit, wird hier eine Unabhängigkeit der Datenproduktion und des Datenkonsumierens erzielt. Um das nachfolgend beschriebene Rollenkonzept realisieren zu können, ist diese Komponente zusätzlich in weitere Module unterteilt: Broker-Kern ( core broker ): Der Core Broker ist die zentrale Kontroll- und Verarbeitungskomponente einer PubScribe-Instanz. Beim Eintreffen einer neuen Publikation koordiniert der Core Broker die Auswertung der abhängigen Bedingungen registrierter Subskriptionen. Die physische Implementierung des Core Broker, insbesondere die Transformationsschritte von eingehenden XML-Dokumenten auf eine SQL-Repräsentation einer eines relationalen Datenbanksystems werden in Abschnitt 4 skizziert. Publikationsmodul ( publisher handler ): Der Publikationsmodul nimmt Registrierungen und Publikationen von Publisher- Komponenten entgegen, validiert diese gegen die vorgeschriebene DTD, wandelt das XML-Dokument in interne Datenstrukturen um und leitet sie an den Core Broker zur weiteren Verarbeitung weiter. Subskriptionsmodul ( subscription handler ): Der Subscription Handler nimmt sowohl neue Subskriptionen als auch Modifikations- und Löschaufforderungen des Benutzers wiederum in Form von XML-Dokumenten entgegen. Eingegangene Anforderungen werden wiederum hinsichtlich Validität und Ausführbarkeit, wie beispielsweise auf die Existenz und Einhaltung der maximal verfügbaren Publizierungsfrequenz der angesprochenen Publisher-Komponenten, überprüft. Auslieferungsmodul ( delivery component ): Die Auslieferung von instantiierten Subskriptionen in Form von XML-Dokumenten wird vom Core Broker initiiert und von der Auslieferungskomponente durchgeführt. Verschiedene Module realisieren das Ausliefern, wobei das Verschicken als Anhang einer EMail, das Hinterlegen auf einem Web-Server und das direkte Schreiben in einen TCP-Socket als Auslieferungsmodi aktuell realisiert sind. 2.4 Das strikte Rollen- und Kanalkonzept Eine fundamentale Erweiterung des PubScribe-Ansatzes gegenüber klassischen Publish/Subscribe -Ansätzen ist, dass Publisher und Subscriber nicht einzelne, unterschiedliche Komponenten eines Systems, sondern Rollen beschreiben. So ist jeder Kommunikationsvorgang in

2.4 Das strikte Rollen- und Kanalkonzept 73 PubScribe als Publikation, d.h. als Antwort auf eine zuvor formulierte Subskription modelliert und realisiert. Beispielsweise tritt die Vermittlungskomponente einerseits als Subscriber auf, indem sie (eine Vielzahl) eingehender Benutzersubskriptionen auf eine einzelne generische Subskription an eine Publisher-Komponente abbildet. Die Vermittlungskomponente nimmt andererseits jedoch auch die Rolle eines Publishers ein, indem sie Nachrichten nach einer entsprechenden Verarbeitung an den Benutzer ausliefert, d.h. publiziert. Das Rollenkonzept ermöglicht unter anderem eine nahtlose Integration folgender systeminternen Komponenten: Systemzeit: Die Systemzeit ist als eigene Publisher-Komponente realisiert, die jeweils die aktuelle Zeit publiziert. Analog zu regulären Publisher-Komponenten, werden nur dann Nachrichten erzeugt, wenn auch darauf registrierte Subskriptionen existieren, d.h. dass die Systemzeitkomponente nur dann die Systemzeit publiziert, wenn es die registrierten Subskriptionen erfordern (z.b. alle 5 Minuten). Dieses Verfahren erweist sich als vorteilhaft, da die Ereignisbehandlung nicht für zeit- und datengetriebene Ereignisse getrennt (wie es beim CQ-Projekt der Fall ist; Abschnitt 5), sondern einheitlich vorgenommen werden kann. Metadaten: Als Metadaten werden Informationen über die registrierten Publisher-Komponenten und Subskriptionen gesammelt und ebenfalls als ein eigener Informationskanal modelliert. So erfolgt beispielsweise beim Eintreffen einer neuen Subskription ein Publikationsvorgang von der Vermittlungskomponente in den Metadaten-Kanal, um die Metadaten entsprechend zu aktualisieren. Durch eine Subskription auf diesen Metadaten- Kanal wird jede Systemkomponente, die Wissen über Metadaten benötigt (z.b. der Subskriptionsmodul zur Überprüfung der Existenz eines im Rahmen einer Subskription angeforderten Informationskanals) über Änderungen informiert. Systemzustandsdaten: Damit das System nach einen Neustart mit der jeweils zuletzt gültigen Konfiguration von Publishern und Subscribern aufsetzen kann, publiziert jede Systemkomponente, die auf Persistenz angewiesen ist, jeden Zustandswechsel in einen expliziten Persistenzkanal. Bei einem Wiederanlauf formulieren die Systemkomponenten Subskriptionen auf diesen Kanal und erhalten ihren zuletzt publizierten Zustand. Das Rollenkonzept hat sich bei der Realisierung des PubScribe-Systems als fundamentale Erleichterung erwiesen, da systeminterne Vorgänge analog zu Vorgängen auf Anwendungsebene behandelt werden können und keine spezielle Behandlung benötigen. Die Kehrseite dieses strikt durchgehaltenen Rollenkonzeptes liegt jedoch darin, dass eine einzelne Aktion eine Vielzahl von impliziten Reaktionen mit sich bringt. So resultiert eine eingehende Publikation in einer weiteren Publikation zur Aktualisierung der Metadaten. Eine neu zu registrierende Subskription impliziert neben der Publikation zur Aktualisierung der Metadaten sogar weitere Publikationen, in denen die beteiligten Systemmodule ihre Zustandsänderungen durch Publikationen in den Persistenzkanal protokollieren.

74 3. Verarbeitungsmodell 3 Verarbeitungsmodell Neben dem Rollenkonzept hebt sich das PubScribe von anderen Publish/Subscribe -Ansätzen (Abschnitt 5) ab, indem nicht nur eine Vermittlung, sondern auch eine Verarbeitung der eingehenden Nachrichten dem Benutzer angeboten wird. Dieser Abschnitt führt exemplarisch das Verarbeitungsmodell basierend auf Sequenzen von Nachrichten ein, verzichtet aber gleichzeitig auf die formale Beschreibung der zu Grunde liegenden Algebra ([LeHR00]). Nachrichten und Sequenzen von Nachrichten Wie bereits angesprochen, muss ein Publisher im Zuge seiner Registrierung das Schema seiner zu publizierenden Nachrichten dem Publikationsmodul der Vermittlungskomponente mitteilen. Da die Publikation von Nachrichten eine inhärente zeitliche Ordnung mit sich bringt, werden im System alle Datenströme als Sequenzen von Nachrichten modelliert. Das Schema einer Nachricht bzw. einer Sequenz von Nachrichten Q besteht aus zwei Attributmengen zur Beschreibung des Identifikatons- und des Informationsteils (Q = (ID, C) = ([ID 1,..., ID n ], [C 1,..., C m ])). Als Beispiel möge an dieser Stelle ein Produzent von Börseninformation dienen, der entweder direkt Daten aus dem Internet (Abschnitt 4.2) oder aus einem vorgelagerten Data Warehouse extrahiert. Der Identifikationsteil besteht dabei aus der Wertpapierbezeichnung, dem Handelsplatz und der Uhrzeit. Der Informationsteil enthält den jeweiligen Kurs sowie das Handelsvolumen: ([(Wertpapier, string), (Handelsplatz, string), (Zeit, datetime) ], [(Kurs, float), (Volumen, integer) ]) // Name des Wertpapiers // Name der Börse, z.b. FWB // Datum und Uhrzeit // Kurs des Wertpapiers // Zahl der gehandelten Aktien Beispielausprägung: [([ ORACLE, FWB, 29.8.2000 9:30 ], [ 96,70, 53 ]), ([ ORACLE, BER, 29.8.2000 9:33 ], [ 96,50, 21 ]), ([ ORACLE, HAM, 29.8.2000 9:07 ], [ 97,00, 8 ]), ([ ORACLE, FWB, 29.8.2000 9:58 ], [ 97,10, 23 ]), ([ IBM, BER, 29.8.2000 9:17 ], [ 145,30, 37 ]), ([ IBM, STU, 29.8.2000 9:30 ], [ 144,20, 12 ]) ] Es sei an dieser Stelle angemerkt, dass der Identifikationsteil auch eine leere Menge von Attributen umfassen kann (z.b. zur Darstellung der aktuellen Systemzeit). Definitionsgemäß ist dann nur eine einzige Nachricht erlaubt. Weiterhin gilt für den Identifikationsteil die Primärschlüsseleigenschaft mit der Einschränkung, dass auf Minimalität verzichtet wird.

3 Verarbeitungsmodell 75 Operatoren auf Sequenzen von Nachrichten Das PubScribe-System stellt eine Vielzahl von Operatoren auf Sequenzen von Nachrichten zur Verfügung. Nachfolgend werden die Operatoren kurz skizziert und am Beispiel erläutert. Auf eine formale Beschreibung wird wiederum verzichtet. Selektion: Der Selektionsoperator liefert nur diejenigen Nachrichten, die eine angegebene Selektionsbedingung erfüllen. Eine Selektion ist nur auf Attribute des Identifikationsteils erlaubt. Verbundoperation: Zur Kombination von Nachrichten aus unterschiedlichen Kanälen dient ein Natürlicher Verbund über die Schnittmenge der Attributmengen der beiden Verbundpartner. Skalaroperator: Die Anwendung eines Skalaroperators erlaubt die Modifikation des Informationsteils einer Queue durch Skalarfunktionen. Eine Skalarfunktion erhält die Attribute sowohl des Informations- als auch des Identifikationsteils als Parameter. Die Menge der Skalarfunktionen umfasst neben arithmetischen und boolschen Funktionen auch Kalenderfunktionen zur Bearbeitung von Zeitangaben. Beispiel: Das Schema ([ID], [Tag=day(Zeit), Kurs=id(Kurs), Umsatz=mult(Kurs, Volumen)]) zeigt die Anwendung von drei Skalarfunktionen zur Berechnung des Tages, der unveränderten Übernahme des Aktienkurses und der Berechnung des Umsatzes. Der Inhalt wird somit um das Attribut für den aktuellen Tag erweitert. Shift-Operator: Der Shift-Operator erlaubt das Verschieben eines Attributes aus dem Inhalt in den Identifikationsbereich. Die Eindeutigkeit der Identifikation wird dadurch nicht behindert. Beispiel: Aus dem vorangegangenen Beispiel wird die Tagesangabe (zusätzlich zur Uhrzeit) in den Identifikationsteil übernommen: ([ID {Tag}], [Kurs, Umsatz]) Gruppierung: Der Gruppierungsoperator erzeugt für explizit spezifizierte Identifikationsattribute Partitionen mit gleichen Attributwerten und bestimmt auf dieser Menge entweder die Summe, das Minimum oder das Maximum. Identifikationsattribute über die aggregiert wird, fallen weg; die Eindeutigkeit bleibt erhalten. Beispiel: Das folgende Schema spiegelt das Ergebnis eines Gruppierungsoperators wider, der eine tagesweise Summation über die Umsätze vornimmt: ([{Aktie, Tag}], [Gesamtumsatz=SUM(Umsatz)]) Diese Einschränkung kann jedoch durch eine Kombination von Skalaroperator und Shift-Operator relativiert werden.

76 4. PubScribe Implementierung Windowing-Operator: Im Gegensatz zum Gruppierungsoperator bestimmt der Windowing-Operator für jede Nachricht eine gemäß vorgegebener Reihenfolge explizit spezifizierte Partition, auf die dann Aggregationsfunktionen angewendet werden. Beispiel: Folgendes Schema zeigt das Ergebnis eines Windowing-Operators, der für jeden Tag den Drei-Tages-Gesamtumsatz aus dem vorangegangen, dem aktuellen und dem nachfolgenden Umsatzwert, angegeben durch (-1,1) in der Operatorparametrisierung berechnet: ([ID], [ DreiTagesUmsatz=SUM(Umsatz:(-1,1)) ]) Angemerkt sei an dieser Stelle, dass der Windowing-Operator im Gegensatz zum Gruppierungsoperator keine Verdichtung vornimmt, sondern für jede eingehende Nachricht eine Ergebnisnachricht produziert. Die Menge der Operatoren ist abgeschlossen und erhält die eindeutige Identifizierbarkeit. Neben klassischen Operatoren wie Selektion und Verbund bieten insbesondere die Gruppierung- und Windowing-Operatoren ein mächtiges Hilfsmittel, um Anforderungen aus dem Data-Warehouse-Bereich befriedigen zu können. 4 PubScribe Implementierung In diesem Abschnitt wird näher auf die prototypische Implementierung von PubScribe eingegangen. Pubscribe basiert auf Oracle8i und ist vollständig in Java in Form einer Zusatzebenenarchitektur realisiert. Der aktuelle Prototyp stellt bereits die volle Funktionalität einer Vermittlungskomponente zur Verfügung. Mangels geeignetem Benutzerinterface zur freien Spezifikation von Subskriptionen wird in Abschnitt 4.2 ein eingeschränktes Demonstrationsszenario über Subskriptionstemplates vorgestellt. 4.1 Schichtenarchitektur des Kernsystems Wie bereits in Abschnitt 2.3 beschrieben, besteht eine Vermittlungskomponente aus mehreren Modulen, wie Subskriptions-, Publikations- und Auslieferungsmodul. Die zentrale Komponente des Kernsystems übernimmt die Verwaltung des gesamten Lebenszyklus einer Subskription. Abbildung 4.1 zeigt im Überblick das Kernsystem aus Abbildung 2.1 untergliedert in die nachfolgend beschriebenen Schichten, die eine Abbildung der XML-Nachrichten und in XML-spezifizierten Subskriptionen auf ein relationales Datenbanksystem vornehmen. Data Processing Unit Registriert ein Subscriber eine neue Subskription am Subscriptionsmodul, so veranlasst das Kernsystem, dass in der Data Processing Unit (DPU) ein entsprechender Operatorenbaum, wie in Abschnitt 3 erläutert, für die Startbedingung eingerichtet und in den bereits bestehenden globalen Subskriptions-DAG integriert wird. Dabei wird versucht, die einzelnen Sub-

4.1 Schichtenarchitektur des Kernsystems 77 skriptionsbäume möglichst effizient, d.h. redundanzfrei, bei einem hohen Wiederverwendungsgrad zu integrieren. Aktuell werden sowohl direkte Übereinstimmungen von Teilbäumen als auch Situationen erkannt, in welchen Kompensationsoperationen notwendig sind, um eine vollständige Substituierbarkeit zu erzielen ([ZCL+00]). Als Wächter über den globalen Operatorengraph des Systems entscheidet die DPU weiterhin, welche der Knoten physisch realisiert, d.h. materialisiert (z.b. größter Fanout), und welche lediglich virtuell implementiert werden. Per Definition wird jeder Zielknoten, der das Ergebnis eines Subskriptionsrumpfes reflektiert materialisiert, so dass beispielsweise eine Auslieferung an den Subscriber erfolgen kann. Operation Clustering Unit und Staging Area Die DPU reicht jeden zu materialisierenden Operatorenknoten zusammen mit dem anhängigen Unterbaum an die tiefere Operation Clustering Unit (OCU) weiter. Diese Schicht faßt möglichst viele der virtuellen Knoten zu einem einzigen Operator, der direkt auf SQL abgebildet werden kann, zusammen. Für jeden dieser zusammengesetzten Operatoren legt die darauf folgende Staging Area genau eine Sicht im Datenbanksystem an. Broker-Kern RDBMS Kommunikation zwischen den Komponenten und Ihrer Module Erfährt der Broker-Kern über den Publikationsmodul von einer neuen Publikation, so ver- Abb. 4.1: Schichtenarchitektur des PubScribeanlaßt er das Einbringen der neuen Informationen in die entsprechenden Relationen der Staging Area. Die so aufgenommen Nachrichten werden auf Datenbankebene durch einen Triggermechanismus im Operatorengraphen nach oben propagiert, wobei in erster Linie die Teilbäume der Subskriptionen ausgewertet werden, die Subskriptionsbedingungen repräsentieren (Abschnitt 3). Ist beispielsweise die Auslieferungsbedingung erfüllt, wird auch der zugehörige Datenteil der Subskription ausgewertet, indem die dazu korrespondierenden Tabellen aktualisiert werden. Auslieferungskomponente Publikationsmodul Subskriptionsmodul Data Processing Unit Operation Clustering Unit Staging Area Der Informationsaustausch zwischen den einzelnen PubScribe Komponenten als auch der oben beschriebenen Module erfolgt ausschließlich über das Simple Object Access Protocol (SOAP, [BEK+00]). Dieses realisiert eine Verteilfähigkeit des Systems sowohl auf Komponenten-, als auch auf Modulebene. SOAP stellt eine Möglichkeit dar, basierend auf XML ([Tolk99]) und HTTP einen Fernaufruf zu ermöglichen, ohne - wie bei anderen Übertra- In der tatsächlichen Realisierung kann per Compileroption auf SOAP zwischen den Modulen einer Komponente verzichtet und auf direkten Prozeduraufruf umgeschalten werden.

78 4. PubScribe Implementierung Abb. 4.2: Registrierung der Stockwatch-Subskription gungsformaten, wie etwa CORBA - spezielle Ports freigeben zu müssen. Damit werden SOAP-Nachrichten insbesondere nicht von Firewalls aufgehalten. Im Fall von PubScribe ist auch die Nutzinformation selbst in XML formuliert, was eine ausführliche Semantik erlaubt, die den Betrieb eines Subskriptionssystems enorm vereinfacht. Es besteht weiterhin die berechtigte Hoffnung, daß XML sich in der Industriewelt weit verbreiten wird und damit quasi als Esperanto der Informationsbranche dient. 4.2 Stockwatch Demonstration Die in diesem Aufsatz vorgestellten Konzepte und die Architektur sind in Form eines Prototypen implementiert, der unter http://www.pubscribe.org/ mehrere mögliche Szenarien anbietet. Als Beispiel für eine Subskription auf einer Datenbank werden die Logeinträge eines Webservers in einem Oracle8i System aufgezeichnet. Subscriber können sich somit über die Zugriffshäufigkeit auf gewisse Webseiten informieren lassen. Eine komplexere Demonstration ist die Stockwatch-Subskription, deren Einrichtung in Abbildung 4.2 zu sehen ist: im Bildhintergrund muss zuerst ein Token angegeben werden, welches den Anwender identifiziert **. Die Startbedingung ist nicht gesetzt, daher tritt die Subskription sofort in Kraft. Als Stoppbedingung ist ein Datum Ende September gesetzt. Im ** Solche Tokens sind kostenlos auf der Webseite erhältlich und dienen nur dem Schutz des Anwenders.

5 Verwandte Arbeiten und Projekte 79 Bildvordergrund wird als Lieferbedingung alle 24 Stunden gesetzt. Von den drei möglichen Anfragemustern wurde die mittlere, die eine Window-Anfrage über die IBM-Aktie enthält, ausgewählt. Der Anwender kann die in diesem Formular erstellte Subskription von jedem Webbrowser abschicken und wird dann entsprechend seinen Wünschen per Mail informiert. Ausgaben auf (WAP-)Mobiltelefone, d.h. eine Umsetzung von XML auf WML, ist leicht vorstellbar. 5 Verwandte Arbeiten und Projekte Dieser Abschnitt gibt einen kurzen Überblick über die im Kontext des hier vorgestellten Systems verwandte Notifikations- und Informationsverteilungsdienste, die im Zusammenhang mit Publish/Subscribe stehen. Dabei wird allerdings bewußt nur auf inhaltsbasierte Systeme eingegangen, weshalb vor allem die im Internet beliebten, themenorientierten Dienste, wie PointCast, Marimba oder BackWeb entfallen. Für einen genaueren Überblick sei etwa auf [Hack97] verwiesen. Bei den vorgestellten Ansätzen wird zwischen systemnahen und applikationsnahen Ansätzen unterschieden. 5.1 Systemnahe Ansätze Der Event Service ist einer von vielen CORBA-Diensten (COSS, [OMG00]). Wie bei COR- BA-Spezifikationen üblich, ist seine Definition sehr allgemein und damit flexibel gehalten. Anbieter und Nachfrager tauschen Ereignisse miteinander aus und folgen dabei einer Push-, einer Pull- oder einer gemischten Semantik ([AcFZ97]). CORBA erlaubt je nach Implementierung der Ereignisnachrichten sowohl inhalts- als auch themenorientierte Subskriptionen. Die Scalable Internet Event Notification Architektur (SIENA, [Birm93]) realisiert einen skalierbaren Eventdienst für hochgradig verteilte Systeme. Notifikationen sind Mengen von Attributen jeweils bestehend aus Bezeichner, Datentyp und dem tatsächlichen Wert. Subskriptionen sind in SIENA Kombinationen von Prädikaten (Ereignisfiltern) auf Attributen. Das Elvin-System ([FMK+99]) besteht nur aus Servern: Publisher sind spezielle Server, die den Subskriptionsapparat nicht benutzen, während Subskribenten Server sind, die jegliche Subskriptionsanfragen ignorieren. Subskriptionen werden als boolsche Ausdrücke in einer speziell entwickelten Sprache formuliert, die u.a. reguläre Ausdrücke unterstützt. Beispielanwendungen von Elvin sind Tickertape, ein konfigurierbarer News-Ticker, oder Breeze, ein ereignisgesteuertes Workflow-Management-System.

80 6. Zusammenfassung und Ausblick 5.2 Applikationsnahe Ansätze Im Gegensatz zu den eben angeführten Ansätzen auf Systemebene sind die vollwertigen Publish/Subscribe -Applikationen eher mit dem hier vorgestellten PubScribe vergleichbar. Das Stanford Information Filtering Tool (SIFT, [YaGa95]) beispielsweise ist ein großflächig angelegter Informationszustelldienst, der Volltextfilterung zulässt und sich im Informationsgewinnungsbereich ([FoDu92]) platziert. Subskriptionen werden durch Festlegen eines Informationsprofils mit diversen Parametern bezüglich Wiederholungsfrequenz oder Informationsmenge spezifiziert. Zwei unterschiedliche Filtermodelle berechnen den Relevanzwert neuer Nachrichten und liefern diese aus, falls ein definierter (Relevanz-)Schwellwert überschritten ist. Gryphon ([SBC98]) ist ein skalierbares Nachrichtenverteilungssystem von IBM, das ähnlich wie PubScribe Subskriptionen anhand des Informationsflusses in einem Filtergraphen evaluiert. Dabei konzentriert sich das Gryphon-Projekt insbesondere auf die Optimierung dieses Graphen und die Verteilung des zentralen Brokers auf mehrere Instanzen. Das Continual Query Projekt (CQ, [PuLi98]) ist ein Publish/Subscribe -System zur Verarbeitung verteilter, heterogener Informationsquellen. Eine Subskription besteht aus einer SQL-Anfrage, angereichert um eine zeit- bzw. ereignisgesteuerte Auslieferbedingung und eine Stoppbedingung. Subskriptionen über mehrere Quellen sind möglich, was von einigen anhängigen Projekten ausgenutzt wird. 6 Zusammenfassung und Ausblick Das Ziel dieses Beitrags ist es, auf der einen Seite die Notwendigkeit eines Subskriptionssystems im Kontext eines Data-Warehouse-Systems aufzuzeigen, in dem zukünftige Anforderungen adressiert und mögliche Lösungsansätze durch den Publish/Subscribe -Ansatz aufgezeigt werden. Auf der anderen Seite wird in diesem Beitrag das PubScribe-Projekt als ein Beispiel eines Publish/Subscribe -Systems vorgestellt. Die logische Architektur basiert dabei auf dem 3-Schichten-Architekturmodell. Das strikt durchgehaltene Rollenmodell, in welchem physische Komponenten situationsbezogen unterschiedliche Rollen annehmen können, erlaubt eine einheitliche Modellierung und Umsetzung sowohl anwendungsorientierter als auch systeminterner Abläufe. Das PubScribe-System ist als Prototyp implementiert. Aktuelle Arbeiten am PubScribe-Kern beschäftigen sich mit der Erweiterung des Rollenkonzeptes in einer vollständig verteilten Umgebung. Weitere Arbeiten beziehen sich auf die Datenbereitstellungsseite und die Entwicklung eines Benutzerwerkzeuges zur Spezifikation von beliebigen

6 Zusammenfassung und Ausblick 81 Literatur AcFZ97 Acharya, S.; Franklin, M.; Zdonik, S.: Balancing Push and Pull for Data Broadcast. In: SIGMOD Conference 1997, S. 183-194 AHLS00 Albrecht, J.; Hümmer, W.; Lehner, W.; Schlesinger, L.: Adaptive Praeaggregation in multidimensionalen Datenbanksystemen. In: 8. GI-Fachtagung Datenbanksysteme in Büro, Technik und Wissenschaft (BTW'99, Freiburg, 1.-3. März 2000), S. 97-114 BaGü00 Bauer, A.; Günzel, H.: Data Warehouse Systeme. dpunkt-verlag, Heidelberg, 2000 Birm93 Birman, K.P.: The Process Group Approach to Reliable Distributed Computing. In: Communicatons of the ACM, 36(1993)12, S. 36-53 BEK+00 Box,D.; Ehnebuske, D.; Kakivaya, G.; Layman, A.; Mendelsohn, N.; Nielsen, H.F.; Thatte, S.; Winer, D.: SOAP: Simple Object Access Protocol, 2000 (Elektronisch verfügbar unter: http://msdn.microsoft.com/workshop/xml/general/soapspec.asp) Conr97 Conrad, S.: Föderierte Datenbanksysteme. Konzepte der Datenintegration, Springer Verlag, Berlin, Heidelberg, 1997 FMK+99 Fitzpatrick, G.; Mansfield, T.; Kaplan, S.; Arnold, D.; Phelps, T.; Segall, B.: Instrumenting and Augmenting the Workaday World with a Generic Notification Service called Elvin. In: ECSCW99 Workshop on Community Knowledge, 1999 FoDu92 Foltz, P.W.; Dumais, S.T.: Personalized Information Delivery: An Analysis of Information Filtering Methods. In: Communications of the ACM, 35(1992)12, pp. 51-60 Hack97 Hackathron, R.: Publish or Perish. In: Byte Magazin, September 1997 (Elektronisch verfügbar unter: http://www.byte.com/art9709/sec6/art1.htm) Inmo96 Inmon, W.H.: Building the Data Warehouse, 2. Auflage. John Wiley & Sons, New York, Chichester, Brisband, Toronto, Singapur, 1996 OMG00 N.N.: Event Service, Version 1.0. In: Corba Services Specifications, Object Management Group, 2000 IBM00 N.N.: MQSeries: Message Oriented Middleware. Whitepaper (Elektronisch verfügbar unter: http://www.ibm.com/software/ts/mqseries/library/whitepapers/ mqover/) Orac99 N.N.: Oracle 8i Application Developer s Guide - Advanced Queuing. In: Oracle 8i Server Dokumentation, 1999 Powe96 Powell, D.: Group Communication. In: Communications of the ACM 39(1996)4, S. 59-97 PuLi98 Pu, C.; Liu, L.: Update Monitoring: The CQ Project. In: The 2nd International Conference on Worldwide Computing and Its Applications, 1998, S. 396-411 SBC98 Strom, R.; Banavar, G.; Chandra, T.; Kaplan, M.; Miller, K.; Mukherjee, B.; Sturman, D.; Ward, M.: Gryphon: An Information Flow Based Approach to Message Brokering. In: International Symposium on Software Reliability Engineering '98, Fast Abstract, 1998 TGNO92 Terry, D.B.; Goldberg, D.; Nichols, D.; Oki, B.M.: Continuous Queries over Append-Only Databases. In: SIGMOD Conference 1992, pp. 321-330 Tolk99 Tolkersdorf, R.: XML und darauf basierende Standards. Die neue Auszeichnungssprache des Web. In: Informatik Spektrum, 22(1999)6, S. 407-421 TsKl78 Tsichritzis, D.C.; Klug, A.: The ANSI/X3/SPARC DBMS framework report of the study group on database management systems. In: Information Systems 3(1978)3, S. 173-191 LeHR00 Lehner, W.; Hümmer, W.; Redert, M.: Building An Information Marketplace using a Content and Memory based Publish/Subscribe System. Technischer Bericht, Institut für Informatik, Universität Erlangen-Nürnberg, eingereicht zur Veröffentlichung, 2000 YaGa95 Yan, T.W.; Garcia-Molina, H.: SIFT - a Tool for Wide-Area Information Dissemination. In: USENIX Winter 1995, S. 177-186 ZCL+00 Zaharioudakis, M.; Cochrane, R.; Lapis, G.; Pirahesh, H.; Urata, M.: Answering Complex SQL Queries Using Automatic Summary Tables. In: SIGMOD Conference 2000, S. 105-116