Multimedia-Metacomputing - eine Perspektive für Peer-to-Peer-Architekturen

Digital Object Identifier (DOI) 10.1007/s00450-003-0128-2Informatik Forsch. Entw. (2003) 18: 1–10

© Springer-Verlag 2003

Multimedia-Metacomputing – eine Perspektive fur Peer-to-Peer-Architekturen

Ulrich Marder

Universitat Kaiserslautern, Fachbereich Informatik, AG DBIS, Postfach 3049, 67653 Kaiserslautern (e-mail: [email protected])

Eingegangen am 13. November 2002 / Angenommen am 14. Mai 2003

Zusammenfassung. Multimedia-Metacomputing ist einneuer Ansatz zur Verwaltung und Verarbeitung multimedialerDaten in Web-basierten Informationssystemen. Dabei wirdsowohl eine hohe Flexibilitat und Offenheit des Systems alsauch eine maximale Abschirmung der Anwendungen vonsysteminternen Gegebenheiten angestrebt. Ausgehend vonder Vision eines vollig offenen, global verteilten Multimedia-Informationssystems betrachten wir in diesem Aufsatz diehierfur erforderlichen Abstraktionskonzepte, insbesondereTransformationsunabhangigkeit, ein darauf abgestimmtessemantisches Modell sowie Realisierungsmoglichkeiten aufder Grundlage des bekannten Peer-to-Peer-Paradigmas.

Schlusselworter: Multimedia-Komponenten, verteiltesRechnen, Datenabstraktion

Abstract. Multimedia metacomputing is a new approach to themanagement and processing of multimedia data in web-basedinformation systems. It offers high flexibility and opennesswhile shielding the applications from any system internals.Starting with the vision of a completely open and globallydistributed multimedia information system, we consider therequired abstraction concepts, especially transformation inde-pendence, and an appropriate semantic model before focusingon architectural and realization-related aspects adopting thewell-known peer-to-peer paradigm.

Keywords: Multimedia components, Distributed computing,Data abstraction

CR Subject Classification: C.2.4, D.2.11, H.2.4, H.3.5

1 Einfuhrung

Multimediale Informationssysteme (MMIS) stellen die tech-nologische Grundlage bereit fur das, was heute oft als Info-tainment bezeichnet wird: die Integration von Information,Kommunikation und Entertainment. Wahrend MMIS fruhernur als „Inseln“, beispielsweise auf CD-ROMs oder in loka-len Netzwerken existierten, konnen wir uns heute dank des

��

��

��

��

��

��

Abb. 1. Heutige Nutzung des Internets als MMIS-Plattform

World Wide Web große, globale MMIS vorstellen, an denenMillionen von Benutzern teilhaben – in ihren Buros, zu Hau-se und unterwegs. Eine wesentliche Herausforderung bestehtdaher darin, all diesen Benutzern den bestmoglichen Nutzen– und Genuss – zu jeder Zeit, an jedem Ort und in jeder Um-gebung zu bieten.

Was dieses Problem so interessant macht, ist die Tatsa-che, dass in einem solch großen und komplexen System vielevariable Faktoren existieren, die die Planbarkeit von Aktio-nen zur Erfullung der Benutzerwunsche sehr erschweren. Dasbeginnt schon bei der großen Bandbreite potenzieller End-gerate, die praktisch alles vom einfachen Mobiltelefon biszum leistungsfahigen Multimedia-PC mit Breitbandanschlussumfasst. Der hohe Vernetzungsgrad sowie die schiere An-zahl potenzieller Serversysteme eroffnen indes auch seitensder Diensterbringer die Moglichkeit, flexibel und dynamischauf neue Anforderungen zu reagieren. So kann beispielswei-se dieselbe Funktion von verschiedenen Servern angebotenwerden, komplexe Operationen konnen auf mehrere Serververteilt werden und neue Server mit neuen Funktionen sindleicht und jederzeit in das System zu integrieren. In unter-schiedlichen Quellen, vorwiegend aus dem Bereich des Super-computing bzw. High-Performance Computing, werden ver-

2 U. Marder: Multimedia-Metacomputing

��

��

��

��

��

��

��

�

��

� ��

��

�

�

�

Abb. 2. Grundprinzip des Multimedia-Metacomputing

gleichbare Konzepte als Metacomputing [33], Peer-to-Peer-Computing (P2P) [13] oder auch Grid-Computing [6] bezeich-net. Andere ahnlich klingende Konzepte wie z. B. Metapro-gramming oder Generative Programming [3] sind hingegenhiermit nicht gemeint.

Die heutige Nutzung des Internets als Plattform fur MMISist hingegen noch sehr stark durch das „klassische“ Client/Server-Paradigma gepragt (vgl. Abb. 1). Medienobjekte (me-dia assets) werden von Servern verwaltet und konnen durcheine URL, die normalerweise die Adresse des Servers undeinen eindeutigen Identifikator fur das Medienobjekt enthalt,referenziert werden. In den allermeisten Fallen handelt es sichbei den Servern um normale Webserver. Daneben kommenauch spezielle Medienserver sowie Datenbanksysteme zumEinsatz. Die von diesen Servern angebotene Funktionalitat isti. d. R. auf das Abrufen (retrieval) und Publizieren von Me-dienobjekten beschrankt. Fur die inhaltsbasierte Suche nachMedienobjekten stehen meist nur Internet-Suchmaschinen zurVerfugung, mit denen nicht direkt nach Medienobjekten ge-sucht werden kann, sondern nach Textdokumenten, in denenMedienobjekte eingebettet sind oder referenziert werden. Teil-weise kann auch direkt nach den Medienobjekten gesucht wer-den, z. B. mit GoogleTM Bildsuche [8], wobei die Indexierungaber gewohnlich auf dem umgebenden Text oder speziellerMetainformation wie Bildunterschriften basiert. Die server-seitige Verarbeitung von Medienobjekten ist – in geringemUmfang – nur bei einigen neueren Datenbanksystemen vor-gesehen [10, 11, 17, 26].

Das Peer-to-Peer-Paradigma kennt im Gegensatz zumClient/Server-Paradigma ein Netzwerk von gleichrangigenServern, die zugleich auch Clients sind, sog. Peers. Peerskonnen funktional aquivalent sein, aber auch spezialisiertauf bestimmte Teilaufgaben innerhalb einer Anwendung. Siekonnen sich gegenseitig aufrufen (Delegation) und bei Bedarfersetzen (Redundanz). In der Regel gibt es auch eine Registra-tur oder einen Verzeichnisdienst, der es erlaubt, dynamischPeers in das Netzwerk zu integrieren oder daraus zu entfer-nen. Neuere Anwendungen wie beispielsweise die beliebtenInternet-Musiktauschborsen setzen bereits auf derartige Kon-zepte. Das wesentliche Ziel ist hierbei, eine verteilte Speiche-rung und Verwaltung der Medienobjekte mit inhaltsbasierten

Zugriffsmoglichkeiten wie der Suche nach Interpreten, Titelnetc. mit moglichst geringem Aufwand und wenigen zentra-len Komponenten zu realisieren. Anders als der Pionier aufdiesem Gebiet, Napster [24], kommen neuere Varianten wieGnutella [7] sogar ganz ohne zentrale Komponenten aus. Hiergenugt es fur den Client, einen beliebigen Server (Peer) zukennen, welcher bei Bedarf wiederum andere, ihm bekanntePeers kontaktiert, um die Benutzeranfrage weiter zu propagie-ren.

Viele andere in jungerer Zeit entwickelte Konzepte fur dieverteilte Datenverarbeitung wie z. B. komponentenbasiertesMetacomputing [9], Web-Services [35] oder die im bekanntenSeti@Home-Projekt praktizierte Verteilung kleiner Verarbei-tungskomponenten auf tausende „unterbeschaftigter“ Rech-ner [14] wurden bisher jedoch nur wenig auf ihren Nutzenfur Web-basierte MMIS untersucht. Die bislang vor allem aufdie Clients konzentrierten Verarbeitungsfunktionen fur Medi-endaten lassen sich namlich nicht einfach auf derartige Ver-teilungskonzepte ubertragen, weil sie nicht darauf ausgelegtsind, Teilfunktionen dynamisch an andere Server zu delegie-ren oder gar neue Funktionen auf entfernten Systemen zu „ent-decken“ und zu nutzen. Dies gilt in kaum geringerem Maßeauch fur Multimedia-Datenbanksysteme, in denen Verarbei-tungsfunktionalitat realisiert wurde [10, 34, 36]. Obwohl hierzumindest im Bereich der Forschung einige Anstrengungenzur Entwicklung geeigneter abstrakter Datenmodelle gelei-stet wurden [28, 31], wurde doch stets von einem homogenenServersystem ausgegangen, bei dem folglich globale Vertei-lung, Heterogenitat, Redundanz, P2P, dynamische Erweite-rung usw. noch keine Rolle spielen. Diese Aspekte wurdenerst im Konzept der Transformationsunabhangigkeit [18, 19]berucksichtigt, welches weiter unten vorgestellt wird.

2 Zielsetzung

Die grundsatzliche Funktionsweise eines Web-basierten, of-fenen, heterogenen und dynamisch erweiterbaren MMIS lasstsich als Multimedia-Metacomputing [21] charakterisieren(vgl. Abb. 2). Die Abbildung zeigt ein typisches Anwendungs-szenario fur ein solches System:

Im ersten Schritt wird eine inhaltsbezogene Suchanfragean eine Suchmaschine gesendet ©1 . Die Suchmaschine wer-tet die Anfrage aus und liefert eine Liste von Referenzen aufrelevante Medienobjekte an die Anwendung zuruck. Der Auf-bau und die interne Arbeitsweise einer solchen Suchmaschineist ein aktueller Forschungsschwerpunkt im Bereich des In-formation Retrieval (IR), was jedoch in diesem Artikel nichtweiter vertieft werden soll. P2P-IR wird beispielsweise in [5]thematisiert.

Die Anwendung (bzw. der Benutzer) entscheidet nun, wasmit den gefundenen Medienobjekten geschehen soll, z. B.,ob und wie sie auf dem Client zu prasentieren sind. DieserWunsch wird in einer sog. Transform & Deliver-Anfrage be-schrieben und an den Metacomputing-Dienst weitergeleitet©2 .

Der Metacomputing-Dienst interpretiert die Transform &Deliver-Anfrage und fuhrt dann folgende Aufgaben aus ©3 :

• Lokalisierung der angefragten Medienobjekte (bzw. derenphysischer Reprasentationen),

U. Marder: Multimedia-Metacomputing 3

• Lokalisierung von Verarbeitungsressourcen, um die ange-forderten Medienoperationen auszufuhren,

• Erstellung eines optimalen Plans fur die Ausfuhrung derMedienoperationen,

• Instanzierung der Verarbeitungsressourcen und Herstel-lung der Datenverbindungen zwischen den einzelnen Ver-arbeitungseinheiten (Konnektierung).

Die Ausfuhrung der Medienoperationen startet entweder au-tomatisch nach dem Abschluss der Planungs- und Instanzie-rungsphase oder erst, wenn die Anwendung ein entsprechen-des Startsignal gibt. Nach einer gewissen Latenzzeit, bedingtdurch i. Allg. notwendige Zwischenpuffer vor bzw. nach deneinzelnen Verarbeitungsschritten, beginnt dann die Ausliefe-rung der transformierten Medienobjekte an den Client ©4 (oderwohin auch immer die Daten zu senden sind).

Das ganze Ausmaß der im Zuge der Realisierung einessolchen Systems zu erforschenden Fragestellungen lasst sichnoch gar nicht absehen. Allein in den Bereichen der Retrieval-Problematik und der verteilten Komponenten-Architekturengibt es derzeit viele Ansatze und Aktivitaten, sowohl im wis-senschaftlichen als auch im industriellen Umfeld. In diesemAufsatz soll indes eine andere Problemzone im Blickfeld ste-hen, namlich die „semantische Lucke“, die sich im obigenSzenario zwischen den sehr anwendungsorientierten Trans-form & Deliver-Anfragen und den im Wesentlichen anwen-dungsneutralen Basistechnologien wie Datenbanksystemen,Web- und Medienservern, Komponenten-basierter Middlewa-re usw. auftut. Diese Lucke muss durch ein integriertes Daten-und Verarbeitungsmodell geschlossen werden, das die im Fol-genden beschriebenen Probleme lost.

Spezifikation der Medientransformationen: Die Anwen-dung soll mit wenig bzw. unvollstandigem Wissen uber diephysische Beschaffenheit der Medienobjekte in die Lageversetzt werden, diese nach ihren Vorstellungen zu formen.Folglich mussen die Transform & Deliver-Anfragen auf ei-nem semantischen Modell basieren, das eine Spezifikationder auszufuhrenden Arbeitsschritte ohne Bezugnahme aufdie tatsachlich vorhandeneVerarbeitungssoftware oder andereverborgene Ressourcen wie z. B. alternative Reprasentationender Medienobjekte ermoglicht.

Dynamische Auswahl der Verarbeitungsfunktionen: DieAnwendung ist aufgrund ihres unvollstandigen Wissens nichtimstande, die fur dieVerarbeitung der Mediendaten benotigtenFunktionen direkt zu benennen. Im Allgemeinen konnen ver-schiedene der im gesamten MMIS vorhandenen Software-komponenten geeignet sein, die gewunschte Verarbeitungs-funktionalitat zu liefern. Es muss also eine – nicht notwendi-gerweise deterministische – Abbildung zwischen der deskrip-tiven Spezifikation der Medientransformation und den Verar-beitungsfunktionen geben. Eine wichtige Frage ist hierbei, wiedie von einer Komponente angebotene Verarbeitungsfunktio-nalitat formal beschrieben werden kann, so dass sich entschei-den lasst, ob sie die geforderte Transformation durchfuhrenkann oder nicht.

Dynamische Verbindung und Koordination von Verarbei-tungseinheiten: Komplexe Medientransformationen werdendurch mehrere Verarbeitungsfunktionen, die dynamisch mit-einander kombiniert werden, realisiert. Dieses Konzept, dasauch als coordinated joint processing bezeichnet wird, hat so-wohl eine logische als auch eine physische Ebene. Auf der

logischen Ebene mussen vor allem die funktionalen Eigen-schaften der Verarbeitungseinheiten betrachtet und ein Mo-dell gefunden werden, das dynamisch konstruier- bzw. verfei-nerbare komplexe Medientransformationen unterstutzt. Aufder physischen Ebene sind besonders die Aspekte der Ver-teilung und Heterogenitat zu beachten. Die Server, auf de-nen die zu kombinierenden Komponenten ausgefuhrt werden,mussen uber hinreichend zuverlassige und breitbandige Netz-werke miteinander verbunden sein, die Komponenten mussenuber gemeinsame Protokolle kommunizieren konnen und derAustausch der Mediendaten zwischen den Komponenten mussermoglicht und gegebenenfalls synchronisiert werden (z. B.,wenn zwei Mediendatenstrome in einer Komponente zusam-menlaufen).

3 Alte und neue Abstraktionskonzepte

Eine wesentliche Anforderung, die sich aus der Zielsetzungableiten lasst, ist die vornehmlich von Datenbanksystemenbekannte Datenunabhangigkeit. Bei der Verwaltung von Me-diendaten wird gewohnlich noch zwischen der logischen undder physischen Datenunabhangigkeit unterschieden [27]. Er-stere wird durch eine vom konkreten Speicherungsformat derMediendaten unabhangige Modellierung und Verwaltung derMetadaten erreicht. Werden hierbei außer Registrierungsda-ten auch inhaltliche Merkmale, sog. Features, erfasst, so las-sen sich auch inhaltsbezogene Suchanfragen datenunabhangigrealisieren. Die physische Datenunabhangigkeit bezieht sichhingegen auf die physische Reprasentation der Mediendaten,die oft auch kurz als Format oder Kodierung (encoding) be-zeichnet wird. Wir sprechen deshalb synonym von Formatun-abhangigkeit, welche vor allem wegen der unterschiedlichenAnforderungen von Servern und Clients an die Medienformatenotwendig wird: Die Server benotigen verlustfreie, universel-le Formate, die eine hohe Datenqualitat garantieren und prak-tisch alle denkbaren Operationen bestmoglich unterstutzen,wahrend die Clients generell auf spezielle Aufgaben, z. B.Wiedergabe auf einem mobilem Endgerat, zugeschnittene For-mate bevorzugen, womit oftmals eine verlustbehaftete Daten-reduktion auf das gerade benotigte Maß verbunden ist.

Die praktische Umsetzung der Formatunabhangigkeit mitihren gegensatzlichen Zielsetzungen scheiterte jedoch bisherin aller Regel. Dieses sog. Formatunabhangigkeitsproblemberuht zum einen auf einem relativ schlechten Leistungsver-halten, welches durch viele erzwungene Formatkonvertierun-gen sowie nicht optimale Verarbeitungssequenzen verursachtwird. Zum anderen lauern hier versteckte, kaum kontrollier-bare und nicht von allen Anwendungen tolerierbare Datenver-luste.

Mit dem Transformationsunabhangigkeitskonzept [18,19] wird ein abstraktes Mediendatenmodell eingefuhrt, daseinen Weg aus dieser Problematik weist, indem es die bishe-rige datenzentrische Sichtweise zugunsten eines kombinier-ten statischen und dynamischen Modells aufgibt. Formatu-nabhangigkeit wird hierbei durch ein flexibles Materialisie-rungskonzept erreicht, in welchem die besonders geschutztenprimaren Materialisierungen jeglichem unbeabsichtigten Da-tenverlust vorbeugen. Gleichzeitig wird ein Verarbeitungs-konzept definiert, das die grundlegenden Anforderungen an


die Medienobjektoperationen festlegt, wie z. B. Seiteneffekt-freiheit und freie Kombinierbarkeit. Diesen Anforderungengenugende Operatoren werden als Medienfilter bezeichnet,eine beliebige Kombination davon als Transformationsan-frage und eine direkt ausfuhrbare Kombination als Medien-transformation. Die Grundidee ist hierbei, dass eine Trans-formationsanfrage moglichst genau die Anwendungsseman-tik reprasentiert, welche dann durch semantisch-heuristischeUmformung bzw. Optimierung in eine Medientransformationuberfuhrt wird, wobei vor der tatsachlichen Ausfuhrung nocheine kostenbasierte Optimierung erfolgen kann.

Eine weitere entscheidende Neuerung ist die dem Mo-dell inharente Generizitat, die durch die bestenfalls teilwei-se antizipierbare Vielgestaltigkeit – in formaler wie auch se-mantischer Hinsicht – der Mediendaten bedingt ist. Es istgerade diese Generizitat, die es nahezu unmoglich erschei-nen lasst, bestehende Mediendatenmodelle wie das MADT-Konzept [22] auf Transformationsunabhangigkeit zu „trim-men“, selbst wenn diese bereits Datenunabhangigkeit un-terstutzen. Es wurde daher ein auf generischen Konzepten auf-bauendes Mediendatenmodell von Grund auf neu entwickelt,das sich in allen wesentlichen Punkten an den oben beschriebe-nen Aspekten der Transformationsunabhangigkeit orientiert.

4 Das VirtualMedia-Modell

Das VirtualMedia-Modell setzt die wesentlichen Aspektedes Transformationsunabhangigkeitskonzepts in ein abstrak-tes Daten- und Verarbeitungsmodell fur multimediale Datenum. Das Modell ruckt die Transformierbarkeit als gemein-sames Merkmal aller Medienarten in den Mittelpunkt. Da-her unterscheidet es sich grundlegend von den meisten an-deren Multimedia-Datenmodellen, die gewohnlich eher die(vermeintlichen?) Unterschiede zwischen den verschiedenenMedienarten betonen. Oft geschieht dies durch die Bildungvon Medienobjektklassen wie Image, Audio, Video usw. ImVirtualMedia-Modell gibt es diese Klassen nicht, so dass derAnsatz dem einen oder anderen Leser zunachst ungewohnlicherscheinen mag. Die vollstandige formale Spezifikation desModells [20] ist indes so umfangreich, dass an dieser Stellenur eine knappe Zusammenfassung moglich ist.

Im VirtualMedia-Modell wird jeder Zugriff auf ein Me-dienobjekt, der zugleich auch beliebige Verarbeitungsschrittebeinhalten kann, als ein Filtergraph dargestellt (vgl. Abb. 3).Jeder Knoten in diesem Graph reprasentiert eine bestimmteVerarbeitungssemantik, welche zum einen durch die Graph-struktur (Anzahl der ein- und ausgehenden Kanten) und zumanderen durch zusatzliche Attribute am Knoten und an denKanten bestimmt wird. Diese Attribute bezeichnen wir allge-mein als Merkmale und fassen sie in Signaturen zusammen.Die Merkmale beschreiben charakteristische Eigenschaftenvon Medienobjekten (Format, Qualitat, Inhalt) und Medien-filtern (Funktion, Neutralitatseigenschaften, Vertauschbarkeitusw.).

Die auch als Kanale bezeichneten gerichteten Kanten imFiltergraph reprasentieren Medienobjekte, die von einem Me-dienfilter erzeugt und von einem anderen weiterverarbeitetwerden. Das Konzept der sog. magischen Kanale ermoglichtes nun, in Transformationsanfragen Medienoperationen de-klarativ zu spezifizieren, wodurch sich zahlreiche Optimie-

σc1

: σc2

:[Typespec] [Typespec]Maintype=Audio Maintype=TextSubtype=Waveform Subtype=PlainEncoding=WAV Encoding=UTF-8[Quality]Sampling_Frequency=44100Sample_Depth=16

f1: Transcript

p1: CNN_Vi-

deos/4711

c2: Transcr-

iptedSpeechσ

c2

c1: Speechσ

c1

Abb. 3. Beispiel eines VirtualMedia-Filtergraphen

rungsmoglichkeiten eroffnen. Erreicht wird dies durch die Zu-ordnung von zwei Signaturen, einer fur den Eingang und einerfur denAusgang des Kanals. Unterscheiden sich die beiden Si-gnaturen, dann verhalt sich der Kanal scheinbar wie ein Filter:Er ist „magisch“.

Um Transformationsanfragen so umformen zu konnen,dass sie keine magischen Kanale mehr enthalten, werden eineReihe von semantischen Umformungsregeln benotigt. Die-se werden als Aquivalenzrelationen auf einer Graphalgebradefiniert und nutzen diverse eindeutig bestimmbare Eigen-schaften von Medienfiltern aus: Neutralitat gegenuber demFormat, der Qualitat oder dem Inhalt von Medienobjekten,Komposition bzw. Dekomposition von Medienobjekten so-wie Vertausch- und Umkehrbarkeit. Dazu gesellt sich nochdas Konzept der semantischenAssimilation, das festlegt, unterwelchen Umstanden ein Medienfilter durch einen semantischahnlichen ersetzt werden kann.

Wir betrachten jede Medientransformation, die man durchdie Anwendung einer beliebigen Folge von Graphtransforma-tionsregeln erhalt, als eine Losung des Anfrageverarbeitungs-problems. Sucht man nun eine optimale Losung, z. B. eineMedientransformation mit minimaler Anzahl von Medienfil-tern, so fuhrt dies zu einem NP-schwierigen Problem. Um sol-che Probleme algorithmisch zu losen, werden ublicherweiseHeuristiken herangezogen, mit denen sich beispielsweise dieGute einer gefundenen Losung bzw. die Distanz zur optimalenLosung beurteilen lasst. Wir fuhren zwei solche Heuristikenein. Mit der ersten wird die Große eines atomaren Problems,d. h. eines Problems, das nur eine Kante oder einen Knoten be-trifft, bewertet („a priori“ Heuristik). Mit der zweiten wird dieGute eines kompletten Graphen bewertet („a posteriori“ Heu-ristik). Daruber hinaus ist eine heuristische Priorisierung dereinzelnen Graphtransformationsregeln moglich, welche be-reits genugt, um einen einfachen, nach dem Greedy-Prinziparbeitenden Algorithmus zu formulieren.

Durch entsprechende Evaluierungsstrategien konnen ver-schiedene Eigenschaften der Anfrageverarbeitung untersucht


und auch verbessert werden. Die Qualitat der geliefertenLosungen kann hierbei zum einen durch die Berechnung derDifferenz zum Optimum (im Sinne des dem Algorithmus zu-grunde gelegten Optimalitatskriteriums) bewertet werden (ob-jektive Evaluierung). Steht daruber hinaus bereits ein komplettrealisiertes System zur Verfugung, ist zudem eine subjekti-ve Evaluierung in Form eines Vergleichs zwischen der An-wendungspragmatik und der gelieferten Losung („leistet sie,was der Anwender will?“) denkbar. Schließlich konnen auchMessungen des Leistungsverhaltens zur Bevorzugung oderVerbesserung eines Anfrageverarbeitungsalgorithmus fuhren(quantitative Evaluierung).

5 Architekturkonzept

Heutige DBS-basierte Ansatze fur medienspezifische Daten-typen und -modelle – wie beispielsweise E-ADTs [31],AMOS[10, 17, 28] und kommerzielle ORDBS [11, 26] – unterstutzenjeweils nur einige Aspekte der Datenunabhangigkeit. Alleindas VirtualMedia-Modell unterstutzt derzeit das Transforma-tionsunabhangigkeitskonzept. Daher weist ein direkter Ver-gleich fur das VirtualMedia-Modell erwartungsgemaß deut-liche Vorteile bei den Aspekten Optimierung, Erweiterbar-keit und Abstraktionsgrad aus. Dem steht jedoch eine deut-lich weniger nahtlose Integrierbarkeit in traditionelle DBS alsNachteil gegenuber. Auch wenn eine solche Integration prin-zipiell moglich ist [15], steht doch zweifelsfrei fest, dass dasKomponenten-basierte Multimedia-Metacomputing [21] alsdie geeignetere Architektur anzusehen ist. In einer solchenArchitektur konnen auch die Vorteile heutiger Multimedia-Komponenten-Frameworks wie dem Java Media Framework[12] oder Microsoft DirectShowTM [4], die uber ein mit Vir-tualMedia vergleichbares Verarbeitungsmodell verfugen (je-doch auf einem niedrigeren Abstraktionsniveau), optimal aus-genutzt werden. Im Folgenden soll daher dieserAnsatz genau-er vorgestellt werden.

5.1 Komponenten-basiertes Multimedia-Metacomputing

Wir greifen an dieser Stelle die Uberlegungen aus dem 2. Ab-schnitt zur Entwicklung einer Multimedia-Metacomputing-Architektur wieder auf und schlagen einen Komponenten-basierten Ansatz mit dynamischer Konfiguration und Op-timierung vor. Diese Art von Multimedia-Metacomputing-Umgebung besteht im Wesentlichen aus den folgenden Be-standteilen:

• Mechanismen zum Speichern, Verwalten und AuffindenvonVerarbeitungskomponenten fur die Manipulation bzw.Transformation von Medienobjekten,

• eine Verarbeitungs- und Kommunikationsinfrastruktur furden Plattform-ubergreifenden Austausch von Medienob-jekten zwischen Verarbeitungskomponenten,

• ein Kontrollsystem, das die Aufgaben der globalen Res-sourcenverwaltung und -planung wahrnimmt und die dy-namische Migration von Verarbeitungskomponenten steu-ert,

• und ein semantisches Modell, das die Beschreibung vonMultimedia-Verarbeitungsaufgaben unabhangig von kon-kreten Verarbeitungskomponenten, Optimierungsstrate-

�� !��"�� #��$%&�'()�*�$+,%-�� #�*��"�� .�!��"�� *��"�� !�� "�"��)&��,)��*��

��

��

��

��

Abb. 4. Beschreibung einer Komponente durch eine Komponenten-signatur

gien und den diversen Materialisierungsformen von Me-dienobjekten unterstutzt.

Als semantisches Modell soll das oben beschriebene Virtual-Media-Modell zum Einsatz kommen. Die erstgenannten dreiAspekte werden nachfolgend noch etwas detaillierter erortert.

5.2 Bereitstellung und Verwaltungvon Medienverarbeitungskomponenten

Nach der in der UML-Spezifikation [25] zu findenden De-finition reprasentiert eine Komponente ein physisch zu im-plementierendes Stuck eines Softwaresystems. Eine Kom-ponente beinhaltet folglich Code in Quell-, Binar- oder di-rekt ausfuhrbarer Form oder etwas Vergleichbares wie bei-spielsweise ein Skript. Einer Komponente werden zudem ei-ne oder mehrere Schnittstellen zugeordnet, welche die vonder Komponente angebotenen und intern implementiertenDienste nach außen reprasentieren. Die Nutzung dieser Dien-ste durch andere Komponenten ist ausschließlich uber dieseoffentlichen Schnittstellen gestattet. Seit einigen Jahren wirddie sog. Komponenten-basierte Softwareentwicklung [2], d. h.die Konstruktion von Software aus fertigen, wiederverwen-deten bzw. wiederverwendbaren Komponenten sehr favori-siert, da sie Zeit- und Kostenersparnis sowie eine hohere Qua-litat verspricht. Die derzeit popularsten Technologien fur dieKomponenten-basierte Softwareentwicklung sind die Enter-prise JavaBeans [29] sowie COM+ [32].

Unter einer Medienverarbeitungskomponente verstehenwir demzufolge eine Komponente, die eine oder mehrereArtenvon Medientransformationen implementiert und als Diensteanbietet. Medienverarbeitungskomponenten sind nicht gene-rell auf eine Technologie festgelegt, jedoch muss naturlich furjede einzelne Komponente eine entsprechende Wahl getroffenwerden. Eine Komponente ist daher nur einsetzbar (deploya-ble), wenn eine ihrer Technologie entsprechende Plattformaufgefunden werden kann, was durch geeignete Komponen-tenbeschreibungen zu unterstutzen ist.


Beschreibung von Komponenten

Fur das Multimedia-Metacomputing reichen die bei JavaBe-ans oder COM+ ublichen Schnittstellendefinitionen als Kom-ponentenbeschreibungen nicht aus. Um eine Komponente er-folgreich als geeignete Implementierung einer gewunschtenMedientransformation identifizieren zu konnen, ist vielmehreine weitergehende formale Beschreibung der von der Kompo-nente unterstutzten Operationen erforderlich. Diese Beschrei-bung beinhaltet u. a. die Signaturen der akzeptierten Eingabe-objekte und der erzeugten Ausgabeobjekte sowie der Opera-tionen einschließlich der Zuordnung von Ein- undAusgabeob-jekten und der Spezifikation von Parametern. Ein (gekurztes)Beispiel einer solchen auch als Komponentensignatur be-zeichneten Beschreibung zeigt Abb. 4. Die Syntax ist eng andie VirtualMedia Markup Language [20] angelehnt, d. h., eshandelt sich bei den Komponentensignaturen um eine spe-ziell auf das VirtualMedia-Modell abgestimmte Erweiterungder gewohnlichen Schnittstellendefinitionen. Da die gangigenKomponententechnologien derartige Signaturen noch nichtunterstutzen, mussen die Komponenten und ihre Signatu-ren getrennt voneinander gespeichert werden. Die Verwal-tung der Komponentensignaturen und der Beziehungen zuden jeweiligen Komponenten gehoren daher zu den Aufgabendes Kontrollsystems bzw. diesem untergeordneter speziellerKomponenten-Repositories.

Abhangigkeiten zwischen Komponenten (-versionen)

Oftmals existieren zwischen den Komponenten Abhangig-keiten oder verschiedene Kooperationsmoglichkeiten, welcheebenfalls in Form von Beziehungen verwaltet werden sollen.Beispielsweise ist es denkbar, dass eine Komponente zwar dieAusfuhrung einer bestimmten Medientransformation anbietet,hierfur jedoch wieder auf die Dienste bzw. Verfugbarkeit ei-ner anderen Komponente angewiesen ist. Das Kontrollsystemmuss uber diese Information verfugen, so dass es gegebenen-falls alle beiden Komponenten gemeinsam in einer passendenLaufzeitumgebung einsetzt.

Es ist denkbar, dass ein abstrakter Filter auch (oder nur)durch eine bestimmte Kombination konkreter Filter realisiertwird. Dies bezeichnen wir dann als eine Filterkonfigurati-on. Abbildung 5 zeigt mogliche Realisierungen des im Bei-spiel (Abb. 3) vorkommenden abstrakten Transkriptionsfiltersals Kooperation zwischen mehreren verschiedenen Kompo-nenten. Wie dieses Beispiel nahe legt, kann es auch meh-rere verschiedene Versionen einer Komponente, in unseremBeispiel der Komponente „Text Generation“, geben. Diesesind wiederum oftmals von unterschiedlichen Komponentenabhangig, beispielsweise im einen Fall von der Komponen-te „Speech Recognition“ und im anderen Fall von der Kom-ponente „Optical Recognition“ (vgl. Abb. 6). Es muss daherin den Komponenten-Repositories eineVersionskontrolle [16]angeboten werden, um verschiedene Versionen von Kompo-nenten und ihre Abhangigkeiten zu beschreiben.

Mit dieser flexiblen Verwaltung von Filterkonfigurationenund -versionen kann in Verbindung mit dem VirtualMedia-Modell abstrakte Semantik automatisch an den gegebenenKontext (z. B. den Typ des Eingabemediums) angepasst unddurch die jeweils am besten geeigneten Komponenten (z. B.optische Zeichenerkennung, wenn die Eingabe ein Bild ist)realisiert werden.

Speicherung der Medienverarbeitungskomponenten

Aufgrund der hohen Anforderungen hinsichtlich der Verwal-tung von Metadaten zur Unterstutzung der Suche nach ge-eigneten Medienverarbeitungskomponenten sowie der Ver-waltung von gultigen Konfigurationen reichen die Leistun-gen eines gewohnlichen Dateisystems zur Speicherung derKomponenten offensichtlich nicht aus. Die genannten Anfor-derungen verlangen vielmehr nach speziellen Komponenten-Repositories, welche auf einem DBMS basieren und somitbereits prinzipiell uber ein machtiges Datenmodell, eine de-skriptive Anfragesprache, Sichten, Integritatskontrolle usw.verfugen [1]. Uber diese Grundfunktionalitat hinaus ist jedochnoch eine effiziente Suche nach Komponenten, basierend aufder in den Komponentensignaturen enthaltenen semantischenInformation sowie die oben beschriebene Versions- und Kon-figurationskontrolle zu unterstutzen.

Der dem Multimedia-Metacomputing zugrunde liegen-den Idee der verteilten Verarbeitung von Mediendaten fol-gend, muss nun auch das Komponenten-Repository verteiltsein, um Komponenten an verschiedenen Orten bereitstellenzu konnen (s. Abb. 7). Hierbei ist jedoch zwischen Speicherortund Ausfuhrungsort der Komponenten zu unterscheiden, wel-che i. Allg. nicht identisch sind. Der wesentliche Vorteil vonverteilten Repositories besteht darin, dass unabhangige Provi-der von Medienverarbeitungskomponenten diese nur in ihremeigenen, lokalen Repository, welches als Teil des virtuellenglobalen Repository registriert ist, bereitstellen mussen.

Eine offene Frage ist, wie die Aufgaben zwischen derzentralen Metadatenbank, die die Beschreibungen der Filtergemaß dem hierarchisch strukturierten Generalisierten Filter-modell (GFM) [20] enthalt, und den verteilten Komponenten-Repositories zu verteilen sind. Das fur die Verarbeitung derTransform & Deliver-Anfragen benotigte GFM beschreibt dieunterschiedlichen Aspekte von Medienfiltern auf insgesamtfunf Hierarchieebenen. Die hochste Ebene (0) charakterisiertjeden Filter als Blackbox mit funktionalem Verhalten (d. h.,Ausgabedaten werden ohne Anderung des Zustands der Ein-gabedaten erzeugt). Die Ebene (1) beschreibt grundsatzlichesemantische Eigenschaften wie Neutralitat, Reversibilitat usw.Die Ebene (2) fugt Ein- und Ausgabedatenstrome hinzu, diemittels Mediensignaturen naher charakterisiert sein konnen.Auf der Ebene (3) muss es fur jeden konkret existierendenFilter genau eine eindeutig zugeordnete Filterbeschreibunggeben, wahrend die unterste Ebene (4) die Filterkonfigura-tionen beschreibt. Die Information der beiden unteren Ebenen(3) und (4) ist bereits im Komponenten-Repository enthal-ten. Die Beschreibungen der Ebenen (1) und (2) mussen nachderzeitigem Stand durch einen menschlichen „Integrator“ er-zeugt werden. Da neue Filter jederzeit uber die Registrierungeiner entsprechenden Komponente in einem der lokalen Re-positories, also dezentral verfugbar gemacht werden konnen,erscheint es aber lohnend, uber eine spatere Automatisierungdieses Prozesses nachzudenken.

Im P2P-Netz soll jeder Peer Transform & Deliver-An-fragen bearbeiten konnen. Es ist daher sinnvoll, die hierfuram haufigsten benotigten Metadaten, d. h. die GFM-Ebenen(0) bis (2) auf allen Peers zu replizieren. Die volumenmaßiggroßeren Ebenen (3) und (4) konnen prinzipiell mittels Anfra-gen an das Komponenten-Repository realisiert werden. EineReplikation dieser Information zur Steigerung der Leistung


��

��

��

��

��

��

��

Abb. 5. Komponentenabhangigkeiten und -kooperation

und Zuverlassigkeit einzelner Peers ist aber ohne weiteresmoglich.

5.3 Verarbeitungs- und Kommunikationsinfrastruktur

Die Verarbeitungs- und Kommunikationsinfrastruktur ermog-licht es, verteilt bereitgestellte Ressourcen fur die Medienver-arbeitung zu lokalisieren, Daten von und zu diesen Ressourcenzu transferieren und somit einen verteilt ablaufenden Medien-verarbeitungsprozess zu initiieren.

Diese Verarbeitungsressourcen stellen demnach eine spe-zielle Laufzeitumgebung (Plattform) zur Verfugung, in derMedienverarbeitungskomponenten, die auf dieser speziellenPlattform ablauffahig sind, eingesetzt werden konnen (deploy-ment). Die Laufzeitumgebungen werden wie die Komponen-ten selbst durch Signaturen charakterisiert (vgl. Abb. 8), sodass sich durch einen Abgleich von Komponenten- und Lauf-zeitumgebungssignaturen auf deren Kompatibilitat schließenlasst. Auf diese Weise kann eine nahezu beliebige, heterogeneMenge vonVerarbeitungsressourcen, wie sie heute im Internetjederzeit anzutreffen ist, genutzt werden. Diese Vielfalt ent-spricht also der heutigen Normalitat und ist oftmals sogar vonVorteil, weil unterschiedliche Plattformen eben unterschied-liche Starken besitzen. Um dies auszunutzen und dabei den-noch eine reibungslose Zusammenarbeit zu erzielen, ist einbestimmtes Maß an Interoperabilitat zwischen den einzelnenPlattformen zu fordern.

Die Realisierung von Interoperabilitat ist folglich nebendem eigentlichen Datentransfer die Hauptaufgabe der Kom-munikationsinfrastruktur. Hierfur eignen sich daher primarstandardisierte und weit verbreitete Protokolle wie HTTP, RTP[30] und SOAP [23]. Wenn eine Verarbeitungsressource beimKontrollsystem registriert wird, mussen neben dem Plattform-typ deshalb auch die unterstutzten Protokolle angegeben wer-den. Außer mindestens einem Standardprotokoll sind hier-bei ebenfalls speziellere proprietare Protokolle denkbar, wennsie beispielsweise eine effizientere Kommunikation zwischengleichartigen Verarbeitungsressourcen erlauben.

Das Zusammenspiel aller Elemente der Komponenten-basierten Architektur fur das Multimedia-Metacomputing be-trachten wir nun im folgenden Abschnitt, in dem das Kontroll-system im Mittelpunkt steht (s. Abb. 8).

��

��

��

��

��

��

��

��

Abb. 6. Konfigurations- und Versionsverwaltung

5.4 Kontrollsystem

Das Kontrollsystem muss auf jedem Peer installiert sein, derselbstandig Transform & Deliver-Anfragen ausfuhren soll,und beinhaltet zunachst einmal die zentralen Komponen-ten des VirtualMedia-Systems: Anfrageubersetzung, Anfrage-transformation, Materialisierungsverwaltung und Instanzier-ungsservice. Eine spezielle Anpassung an die Komponen-ten-basierte Multimedia-Metacomputing-Architektur mussenhierbei nur die dem Instanzierungsservice untergeordnetenDienste – Ressourcenverwaltung und Ressourcen-spezifischeOptimierung – erfahren.

Die Ressourcenverwaltung wird im Wesentlichen durchdie Moglichkeit, verschiedene Laufzeitumgebungen dyna-misch zu registrieren, gepragt. Diese Laufzeitumgebungenkonnen, wie im vorangehenden Abschnitt dargelegt, hetero-gen sein, mussen aber eine Anzahl von Funktionen bzw. Pro-tokollen in einheitlicher Weise unterstutzen. Die wichtigstensind:

• dynamisches Deployment von Komponenten (erforder-lich),

• Abfrage von Statusinformation, z. B. Lastinformation (er-forderlich),

• Zulassungskontrolle (optional),• Ressourcenreservierung bzw. -vorreservierung (optional),• Bereitstellung statistischer Daten (optional) und• Kostenerfassung fur die Abrechnung kostenpflichtiger

Dienste (optional).

Das Komponenten-Deployment ist ein mehrphasiger Vor-gang, der auch das Komponenten-Repository mit einbezieht(vgl. Abb. 8). Das Kontrollsystem nutzt hierbei die Anfra-gemoglichkeiten des Repository, um zu den in der Metadaten-bank verwalteten Filtersignaturen die passenden Komponen-ten zu finden, welche die Filter implementieren. Zu den gefun-denen Komponenten werden mithilfe von deren Komponen-tensignaturen anschließend geeignete Laufzeitumgebungenausfindig gemacht. Von diesen wird dann eine allgemeine Sta-tusinformation angefordert, um die generelle Verfugbarkeit zuprufen. Fallt dieser Test positiv aus, werden anschließend nochdie Zulassungskontrolle und Ressourcenreservierung durch-gefuhrt, falls von der Laufzeitumgebung unterstutzt. Erst dann


wird der Komponentencode zur Laufzeitumgebung transfe-riert und initialisiert (Aktivierung), wobei hier prinzipiellauch Caching-Mechanismen vorstellbar sind, um wiederholteUbertragungen derselben Komponente zu vermeiden. Wennsamtliche fur eine Medientransformation erforderlichen Me-dienverarbeitungskomponenten auf diese Art instanziert sind,mussen noch die Kommunikationskanale zwischen den ein-zelnen Komponenten aufgebaut werden.

Wahrend und nach dem Abschluss der Medientransfor-mation sammelt das Kontrollsystem statistische Daten, diebei der Ressourcen-spezifischen Optimierung helfen konnen.Da bisher noch keine praktischen Erfahrungen mit einer sol-chen Multimedia-Metacomputing-Architektur vorliegen, gibtes noch keine detaillierten Uberlegungen, welche Daten zusammeln und wie sie genau zu nutzen sind. Denkbar ist z. B.,dass auf diese Weise gut bzw. weniger gut zusammenarbeiten-de Laufzeitumgebungen zu identifizieren sind. Die Ursachenfur derartige Phanomene konnen verschieden sein: besondersgute bzw. schlechte Kommunikationsverbindungen, mangel-hafte lokale Ressourcenverwaltung in einer Laufzeitumge-bung, fehlerhaft implementierte Komponenten oder Protokol-le usw. Diese lassen sich aus den Statistiken normalerweisenicht ermitteln, jedoch konnen bei signifikanten Korrelatio-nen auch ohne genaue Kenntnis der Ursachen entsprechendeKonsequenzen gezogen werden, z. B., indem bestimmte Kom-ponenten in bestimmten Laufzeitumgebung nicht mehr bzw.bevorzugt zum Einsatz kommen.

5.5 Peer-Architektur

Im Gegensatz zu den klassischen Client/Server-Architekturenwird bei P2P-Architekturen ein weitgehender Verzicht aufzentrale Komponenten, die zu Engpassen werden konnten,angestrebt. Das heißt, jeder Peer soll alle Arten von Anfragenbearbeiten konnen, und zwar entweder mithilfe eigener Res-sourcen oder durch moglicherweise kaskadierte Unteranfra-gen an andere Peers. Um dies zu ermoglichen, muss die bishergenerisch beschriebene Architektur auf eine Peer-Architekturabgebildet werden (s. Abb. 9). Hierbei wird das Kontrollsy-stem zur zentralen Komponente eines Peers. Es unterstutztdrei Arten von Anfragen:

• Transform & Deliver-Anfragen: Diese kommen i. d. R.von einer lokal laufenden Anwendung. Der entsprechendeAnfrageverarbeitungsalgorithmus ist im Kontrollsystemrealisiert. Im Laufe der Verarbeitung werden Anfragen andie lokale Metadaten- und Ressourcenverwaltung gestellt.Konnen diese die gewunschte Information bzw. Ressour-ce nicht liefern, wird die Anfrage an einen entfernten Peerweiter gereicht.

• Repository-Anfragen: Diese kommen gewohnlich von an-deren Peers. Das Kontrollsystem delegiert diese Anfragenzunachst an die lokale Metadatenverwaltung. Im Fall ei-ner negativen Antwort gibt es anschließend die Anfrage aneinen weiteren Peer weiter, sofern die maximale Kaska-dierungstiefe noch nicht erreicht ist. Auf ahnliche Weisewerden auch Aktualisierungen der GFM-Metadaten pro-pagiert. Dies ist prinzipiell auch per Piggy-backing, alsoAnhangen an „normale“ Repository-Anfragen moglich.

• Ressourcen-Anfragen: Auch diese kommen normalerwei-se von anderen Peers. Es handelt sich hierbei zum einen

��

��

��

��

�� !��

"��

��

��

��

��

Abb. 7. Verteiltes Repository fur Medienverarbeitungskomponenten

um Zugriffe auf Medienobjekte, die auf dem Peer lokalverwaltet werden. Zum anderen kann der Peer als entfern-te Ausfuhrungsumgebung fur eine Medienverarbeitungs-komponente „gebucht“ werden. Diese Komponente befin-det sich entweder bereits im lokalen Repository oder wirdzusammen mit der Ressourcen-Anfrage geliefert, falls dielokalen Sicherheitsrichtlinien dies zulassen.

Mit dieser Architektur wird jeder Peer zu einer autono-men Einheit, die Multimedia-Metacomputing vollkommen ei-genstandig realisiert. Zugleich ist es moglich, auf beliebigviele gleichartige Peers zuzugreifen, was sowohl den Funk-tionsumfang als auch die Menge der nutzbaren Ressourcenvervielfacht.

Fallt ein Peer unvorhergesehen aus, so betrifft dies nur ak-tuell laufende Medientransformationen, die gerade Ressour-cen dieses Peers nutzen. Da das zugrunde liegende VirtualMe-dia-Modell kein Update-in-place kennt, fuhren solche Fehlerjedoch nicht zu einem inkonsistenten Zustand der Multime-diaobjekte. Andere Peers konnen weiterhin Transform & De-liver-Anfragen bearbeiten, solange keine Ressourcen benotigtwerden, die sich exklusiv auf dem ausgefallenen Peer befin-den. Eine derartige Situation kann und sollte vermieden wer-den, da prinzipiell alle Ressourcen replizierbar sind, so dassfast immer ein anderer Peer fur einen ausgefallenen einsprin-gen kann.

6 Zusammenfassung und Ausblick

Der hier betrachtete Ansatz zur Realisierung und Nutzung desMultimedia-Metacomputing zielt auf die Internet-weite Kol-laboration von Medienservern, -clients und -verarbeitern nachdem Prinzip des Peer-to-Peer-Computing. Da ein solches Sy-stem nur durch die gemeinsamen Anstrengungen vieler un-abhangiger Dienstanbieter aufzubauen ist, muss hier unbe-dingt auf maximale Offenheit gesetzt werden. Das heißt, eswird eine Plattform geschaffen, die es autonomen Anbieternvon Medienkomponenten erlaubt, diese uber einen automa-tisierten Registrierungsprozess in das Gesamtsystem zu inte-grieren, und die es Clients erlaubt, neu bereitgestellte Kompo-nenten automatisch in ihren Prozessen zu nutzen. Wesentliche


��

��

��

��

��

�� !��"��#� � ��$��%�� &� � ��

'�� $��%��

� � ��

��

��

�� (��

Abb. 8. Verbindung und Steuerung von Laufzeitumgebungen durchein Kontrollsystem. Die nummerierten Aktionen charakterisieren die„normale“ Abarbeitung einer Benutzeranfrage; die ubrigen werdennur bei Bedarf angestoßen

aktivierteKomp.

LaufzeitumgebungMedienobjekte

Ressourcenverwaltung

GFM-Metadaten

(0) – (2)(3) – (4)

LokalesKomponenten-

Repository

MetadatenverwaltungKon

trollsystem

Peer

Ressourcen-Anfrage Repository-Anfrage

Transform&Deliver-Anfrage


aktivierteKomp.

LaufzeitumgebungMedienobjekte

Ressourcenverwaltung

GFM-Metadaten

(0) – (2)(3) – (4)

LokalesKomponenten-

Repository

Metadatenverwaltung

GFM-Metadaten

(0) – (2)(3) – (4)

LokalesKomponenten-

Repository

MetadatenverwaltungKon

trollsystem

Peer


Transform&Deliver-Anfrage


Abb. 9. Architektur eines Peers

Bestandteile dieser Architektur sind verteilte Komponenten-Repositories mit standardisierten Schnittstellen, eine auf ge-normten Protokollen wie z. B. SOAP basierende Kommuni-kationsinfrastruktur, sowie ein auf allen Peers bereitgestelltesKontrollsystem, das als globaler Service Provider fur die Cli-ents fungiert.

Die Realisierung einer solch neuartigen Multimedia-Me-tacomputing-Architektur als P2P-Architektur kann naturlichnur schrittweise erfolgen und muss von Evaluierungen be-gleitet werden. Gleichzeitig soll ein solches System aber auchmoglichst von Beginn an produktiv einsetzbar und mit ver-tretbarem Aufwand zu entwickeln sein. Ein diesbezuglichbedeutender Vorteil dieser Architektur ist, dass jeder Peerbereits ein vollstandiges, autonom betreibbares Multimedia-Metacomputing-System darstellt. Durch seine offenen An-frageschnittstellen kann dieses System leicht zu einem P2P-Netzwerk ausgebaut werden, das umso leistungsfahiger undvielseitiger wird, je mehr unabhangige Dienstanbieter daranteilhaben.

Die Weiterentwicklung dieser Architektur wird zweifel-los auch die Integration einer Suchkomponente in die Peer-Architektur in Betracht ziehen. Aus wissenschaftlicher Sichtbesonders interessant und noch weitgehend unerforscht isthierbei die Frage, wie das Metacomputing-Prinzip in Zukunftdirekt fur das Information Retrieval genutzt werden kann.

Literatur

1. Bernstein, P. A., Dayal, U.: An Overview of Repository Tech-nology. In: Proc. 20th Intl. Conf. on Very Large Data Bases,VLDB’94 (Santiago, Chile, Sept.), 1994, pp. 705–713.

2. Brown, A. W.: Large Scale Component Based Development,Upper Saddle River, NJ: Prentice Hall, 2000.

3. Czarnecki, K., Eisenecker, U.: Generative Programming, Rea-ding, Massachusetts: Addison-Wesley, 2000.

4. DirectShow Documentation, MSDN Library, Microsoft Corpo-ration, 2002, http://msdn.microsoft.com/library/

5. Eisenhardt, M., Henrich, A.: Probleme und Losungsansatze furP2P-IR-Systeme. In: Proc. Informatik 2002 - 32. Jahrestagungder Gesellschaft fur Informatik, Workshop "Web InformationRetrieval"(Dortmund, 30. Sep.–3. Okt.), Oktober 2002.

6. Foster, I., Kesselman, C. (Eds.): The Grid: Blueprint for a NewComputing Infrastructure, San Francisco, California: MorganKaufmann Publishers, Inc., 1998.

7. Gnutella, Gnutella Website, Gnutella.com, 2002,http://www.gnutella.com

8. Google Bildsuche, Google Website, Google, 2002,http://images.google.de

9. Hawick, K. A., James, H. A., Silis, A. J., Grove, D. A., Patten,C. J., Mathew, J. A., Coddington, P. D., Kerry, K. E., Hercus,J. F., Vaughan, F. A.: DISCWorld: An Environment for Service-Based Metacomputing, Future Generation Computer Systems15 (5-6), 1999, pp. 623–635.

10. Hollfelder, S., Schmidt, F., Hemmje, M., Aberer, K., Steinmetz,A.: Transparent Integration of Continuous Media Support intoa Multimedia DBMS. In: Proc. 3rd Biennial World Conf. onIntegrated Design and Process Technology (IDPT), Issues andApplications of Database Technology (IADT’98) (Berlin, 6–9July, Vol. 2), 1998, pp. 192–199.

11. Informix Digital Media Solutions: The Emerging Industry Stan-dard for Information Management, Informix Software, Inc.,1997.

12. Java Media Framework API Guide, Sun Microsystems, Inc,1999.

13. Kant, K., Iyer, R., Tewari, V.: On the Potential of Peer-to-PeerComputing, Manuskript eingereicht zurVeroffentlichung, 2001.

14. Korpela, E., Werthimer, D., Anderson, D., Cobb, J., Lebofsky,M.: SETI@home - Massively Distributed Computing for SETI,Computing in Science & Engineering 2001 (1), January 2001,pp. 78–83.

15. Lindner, W., Marder, U.: Advancing Query Capabilities for Di-gital Libraries, Manuskript in Vorbereitung, 2003.

16. Mahnke, W., Ritter, N., Steiert, H.-P.: Towards GeneratingObject-Relational Software Engineering Repositories. In: Proc.8. GI-Fachtagung ’Datenbanksysteme in Buro, Technik undWissenschaft’, BTW ’99 (Freiburg, 1.–3. Marz 1999), 1999,pp. 251–270.

17. Malsy, M., Hollfelder, S., Steinmetz, A., Aberer, K.: Un-terstutzung des strukturierten Zugriffs auf MPEG Videos in ei-nem Multimedia-Datenbankmanagementsystem. In: Proc. GI-Workshop “Inhaltsbezogene Suche von Bildern und Videose-quenzen in digitalen multimedialen Archiven”, KI’98 (Bremen,16.–17. Sept.), 1998, pp. 27–34.

18. Marder, U.: Medienspezifische Datentypen fur objekt-relation-ale DBMS: Abstraktionen und Konzepte. In: Proc. 8. GI-Fachtagung ’Datenbanksysteme in Buro, Technik und Wissen-schaft’ BTW ’99 (Freiburg, 1.–3. Marz 1999), 1999, pp. 210–231.

19. Marder, U.: On Realizing Transformation Independence inOpen, Distributed Multimedia Information Systems. In: Proc. 9.


GI-Fachtagung „Datenbanksysteme in Buro, Technik und Wis-senschaft“, BTW ’2001 (Oldenburg, 7.–9. Marz), Heuer, A.,Leymann, F., Priebe, D. (Hrsg.), Springer, Heidelberg, Berlin,2001, pp. 424–433.

20. Marder, U.: Multimedia-Metacomputing in Web-basierten mul-timedialen Informationssystemen, Berlin: Logos Verlag, 2003,ISBN 3-8325-0151-7; zugl.: Dissertation, Fachbereich Infor-matik, Universitat Kaiserslautern, Dez. 2002.

21. Marder, U., Kovse, J.: Multimedia Metacomputing. In: Proc. 7thIntl. Workshop on Multimedia Information Systems, MIS 2001(Capri, Italy, 7–9 November), 2001, pp. 173–182 (erscheintauch in: ACM SIGMOD Digital Symposium Collection 2001).

22. Meyer-Wegener, K.: Multimedia-Datenbanken, Stuttgart: B. G.Teubner, 1991.

23. Mitra, N. (Ed.): SOAP Version 1.2, W3C Working Draft, De-zember 2001.

24. Napster, Napster Website, Napster, Inc., 2002,http://www.napster.com

25. Object Management Group: Unified Modeling Language Spe-cification, version 1.3, OMG Document ad/00-03-01, March2000.

26. Oracle8i interMedia Audio, Image, and Video User’s Guide andReference, Oracle Corporation, 2000.

27. Pruckler, T., Schrefl, M.: An Architecture of a HypermediaDBMS Supporting Physical Data Independence. In: Proc. 9thERCIM Database Research Group Workshop on MultimediaDatabase Systems (Darmstadt, 18–19 March), 1996, pp. 45–57.

28. Rakow, T. C., Klas, W., Neuhold, E. J.: Abstractions for Multi-media Database Systems. In: Proc. 2nd Intl. Workshop on Mul-timedia Information Systems (West Point, NewYork, USA, 26–28 Sept.), 1996, pp. 41–46.

29. Roman, E.: Mastering Enterprise JavaBeans, New York: JohnWiley & Sons, Inc., 1999.

30. Schulzrinne, H., et al. (Ed.): RTP: A Transport Protocol forReal-Time Applications, IETF RFC 1889, January 1996.

31. Seshadri, P.: Enhanced abstract data types in object-relationaldatabases, The VLDB Journal 7 (3), August 1998, pp. 130–140.

32. Sessions, R.: COM+ and the Battle for the Middle Tier, NewYork: John Wiley & Sons, Inc., 2000.

33. Smarr, L., Catlett, C. E.: Metacomputing, Comm. ACM 35 (6),June 1992, pp. 44–52.

34. Speegle, G. D., Wang, X., Gruenwald, L.: A Meta-Structure forSupporting Multimedia Editing in Object-Oriented Databases.In: Proc. Advances in Databases, 16th British National Confe-rence on Databases, BNCOD 16 (Cardiff, Wales, U. K., 6–8July), 1998, pp. 89–102.

35. Tsur, S.: Are Web Services the Next Revolution in E-Commer-ce? In: Proc. 27th Intl. Conf. on Very Large Data Bases, VLDB2001 (Rome, 11–14 September), 2001, pp. 614–617.

36. Wagner, M., Holland, S., Kießling, W.: Towards Self-tuningMultimedia Delivery for Advanced Internet Services. In: Proc.1st Intl. Workshop on Multimedia Intelligent Storage and Re-trieval Management (MISRM ’99) in conjunction with ACMMultimedia Conf. (Orlando, Florida, Oct.), 1999.

Ulrich Marder. Geb. 1967 in Kassel;Informatik-Studium an der Friedrich-Alexander-Universitat Erlangen-Nurnberg; 1994 Abschluss als Diplom-Informatiker; 1994 (Dez.) bis 1998 (Feb.)wissenschaftlicher Mitarbeiter der Profes-sur fur Datenbanken an der TechnischenUniversitat Dresden; seit 1998 (Marz)wissensch. Mitarbeiter der ArbeitsgruppeDatenbanken und Informationssystemeder Universitat Kaiserslautern; zugl. Mit-arbeiter des Sonderforschungsbereichs

501 „ Entwicklung großer Systeme mit generischen Methoden“: 2002(Dez.) Promotion mit dem Thema „ Multimedia-Metacomputing inWeb-basierten multimedialen Informationssystemen“.

Documents

Multimedia-Metacomputing - eine Perspektive für Peer-to-Peer-Architekturen