Einsatz von Mobilen Agenten und XML zur Angebotsrecherche im Business-to-Consumer-Commerce

1 Einf�hrung

1.1 Motivation

Die Teilnehmer im E-Commerce sehensich aufgrund des rasantenWachstums undder zunehmenden Komplexit�t der Kom-munikationsnetze einer gewaltigen F�llevon Informationen gegen�ber, die ohne ei-ne Kategorisierung bzw. automatischeVerarbeitung nicht mehr durch den Einzel-nen erschlossen werden kann. Die Anzahlder Firmen, die ihre Waren �ber Kom-munikationsnetze vertreiben, stieg in denletzten Jahren deutlich an. So enthielt einVerzeichnis vonOnline-Shops in Deutsch-land [Shop00] im September 2000 ca.22500 Eintr�ge in 500 Kategorien. Diehierdurch bedingte Intransparenz des elek-tronischen Marktes und eine oft unzurei-chendeNutzerunterst�tzung beim Erwerbvon Produkten �ber Kommunikationsnet-ze behindern die ganzheitliche Durchset-zung und Akzeptanz des Business-to-Consumer-Commerce (B2C).

Der Einsatz von Softwareagenten ver-einfacht die Interaktion auf elektronischenM�rkten, weil diese die Interessen vonK�ufern gegen�ber einer Vielzahl vonHandelspartnern vertreten und die Kom-plexit�t elektronischer M�rkte zumindestteilweise vor den Kunden verbergen k�n-nen [MGM98]. Untersuchungen �ber dasVerhalten von Kunden in der CBB-For-schung (Consumer Buying Behaviour) ha-ben verschiedene Phasen des Kaufvorgan-ges, wie beispielsweise die Bedarfsbestim-mung oder die Produkt- und H�ndleraus-wahl, identifiziert [RuSt87]. Erst durch dieVerwendung elektronischer Agenten k�n-nen K�ufer einige dieser Phasen �berhauptumfassend durchf�hren [GMM99].

Die vorliegende Arbeit befasst sich mitArchitekturen f�r Agenten zur Angebots-recherche. Diese Agenten unterst�tzen dieProduktauswahl, den seri�sen Angebots-vergleich und das Bestellen von Produktenbei verschiedenen Anbietern. Die Archi-tekturen werden auf der Grundlage defi-nierter Anforderungskriterien verglichenund es wird aufgezeigt, inwiefern durchden Einsatz mobiler Agenten und XML ei-ne erh�hte Flexibilit�t, leichtere Anpass-barkeit und eine einfachere Kommunikati-on mit den Anbietern erreicht werdenkann. Eine konkrete Implementierungzeigt die Umsetzbarkeit einer der vor-gestellten Ans�tze.

1.2 Inhalts�bersicht

Im folgenden Abschnitt werden die f�rdiese Arbeit grundlegenden Techniken so-wie themenverwandte Arbeiten vor-gestellt. Im Anschluss daran werden imAbschnitt 3 die Teilprobleme der Ange-botsrecherche er�rtert. Der Abschnitt 4f�hrt Entscheidungskriterien f�r die Ver-wendung mobiler Agenten auf. Die Archi-tekturen f�r die Produktrecherche werdenin Abschnitt 5 dargestellt. Der Zugriff aufdie Angebotsinformationen und die Inter-aktion mit verschiedenen H�ndlern wirdim darauffolgenden Abschnitt erl�utert.Letztendlich befassen sich die abschließen-den Abschnitte mit den Vorteilen vonXML, der Umsetzung einer konkreten Ar-chitektur und einem Ausblick auf weitereForschungsbem�hungen.

2 Grundlegende Konzepteund Forschungsumfeld

2.1 ForschungsumfeldDie Bedeutung von Agenten als Vermittlerim elektronischen Handel wurde in einer

Initiative am MIT untersucht [MGM98].Dabei sind eine Reihe von Forschungspro-totypen, wie z. B. Kashbah [ChMa96],Market Maker oder Tete-a-Tete [GMM99]entstanden. Der von der Firma AndersonConsulting entwickelte BargainFinder-Agent [Krul96] unterst�tzte Kunden beider H�ndlerauswahl w�hrend des CD-Kaufs. Die rein serverbasierte Abfrage derAngebotsinformationen und die fehlendeBereitschaft einiger H�ndler, einen Preis-vergleich zuzulassen, f�hrte jedoch zu ei-ner Blockade der von diesem Tool gene-rierten Anfragen. Es zeigte sich aber auch,

Dipl.-Inf. Frank Siegemund, Graduier-tenkolleg „Infrastruktur f�r den elektro-nischenMarkt“, Fachbereich Informa-tik, Technische Universit�t Darmstadt,Wilhelminenstr. 7, D-64283Darmstadt,E-Mail: [email protected]; Prof. Dr. ClemensH. Cap, Gef�rdert durch die Heinz-Nixdorf-Stiftung, Lehrstuhl f�r Infor-mations- und Kommunikationsdienste,Prof. Dr. Andreas Heuer, Lehrstuhl f�rDatenbank- und Informationssysteme,Universit�t Rostock, Albert-Einstein-Str. 21, D-18051 Rostock, E-Mail:{cap|heuer}@informatik.uni-rostock.de

Einsat z von mobilenAgenten und XML

zur Angebot srechercheim Bus iness-to-

Consumer-Commerce

Frank Siegemund, Clemens H. Cap, Andreas Heuer

WI – Schwerpunktaufsatz

WIRTSCHAFTSINFORMATIK 43 (2001) 2, S. 157–166 157

dass viele, vor allem kleinere Anbieter, aneiner Aufnahme in den Vergleichsprozessinteressiert und außerdem bereit waren, ih-re Systeme zu �ffnen. Das Tool Jango be-nutzt die Web-Browser der Anwender f�rdie Generierung der Anfragen und umgehtso �hnliche Gegenmaßnahmen.

Der Pocket BargainFinder [BrGo99],ist ein Kleinstger�t, welches einige der Vor-teile des elektronischenHandels auch beimtraditionellen Einkauf anbietet. AndersonConsulting spricht in diesem Zusammen-hang von „augmented commerce“. Der ander Universit�t von Washington ent-wickelte ShopBot-Agent [DEW97] zeigtauf, wie Methoden der KI bei der Zusam-menarbeit mit verschiedenen Online-Shops verwendet werden k�nnen.

Diese Arbeit konzentriert sich auf diezugrundeliegenden Infrastrukturen f�rden Einsatz von Agenten im B2C-Com-merce. Dazu werden verschiedene Archi-tekturkonzepte, von denen einige in obenaufgef�hrten Systemen benutzt wurden,einander gegen�bergestellt und der Vorteilneuerer Techniken, wie mobiler Agentenund XML, in diesem Anwendungskontextbeschrieben. Es wird argumentiert, dassdie zunehmende Durchsetzung von XMLzu einfacheren Interaktionsmustern mitden Anbietern f�hrt. Bei Letzteren kann essich um einzelne Online-Shops, virtuelleMarktpl�tze oder Konglomerate vonH�ndlern handeln, die �ber eine einzelnePlattform ihre Produkte vertreiben wollen.In diesem Fall wird auch die Bereitschaftgr�ßer sein, Angebotsinformationen preis-zugeben.

2.2 Mobile Agenten

Mobile Agenten sind intelligente Soft-wareagenten mit der Eigenschaft, in einem

heterogenen Rechnernetz zwischen ver-schiedenen Knotenpunkten migrieren zuk�nnen. Ein mobiler Agent ist also bei derL�sung einer Aufgabe nicht an einen ein-zelnen Rechner gebunden, sondern kanndie Dienste unterschiedlichster Rechnerdirekt in Anspruch nehmen. Dazu wirdder gesamte Zustand des Agenten, seinCode einschließlich aller lokalen Daten�ber das Netzwerk transferiert. MobileAgenten k�nnen mit anderen Agenten aufAgentenplattformen interagieren und da-bei Informationen austauschen [BZW98,Klus99, Matt98, RoPo97].

Grundlegende Eigenschaften intelli-genter Softwareagenten sind Autonomie,Kommunikation, Reaktivit�t und Proakti-vit�t [BZW98]. Ein Agent heißt intelligent,wenn er in der Lage ist, sich im Rahmen ei-ner vorgegebenen Problemstellung sinn-voll zu verhalten. Er zieht durch die Beob-achtung seiner Umgebung Schl�sse undleitet daraus ein Verhalten ab, das ihm derL�sung des zugrundeliegenden Problemsn�herbringt. Dabei kann er seine Umge-bung durch sein Verhalten aktiv beeinflus-sen [RuNo95,Weis00].

2.3 Methoden zur Darstellungund Verarbeitung vonAngebotsinformationen

Die Hypertext Markup Language(HTML) ist die vorherrschende Spracheim World Wide Web (WWW). Sie eignetsich hervorragend f�r die Beschreibungder visuellen Darstellung von Informatio-nen, nicht jedoch f�r deren automatischeVerarbeitung.

Im Gegensatz dazu erm�glicht dieExtensible Markup Language (XML)[XML00] eine Differenzierung zwischen

Layout und Anwendungsdaten. Das f�hrtzu einer vereinfachten Verarbeitung der imjeweiligen Anwendungskontext relevantenDaten. So k�nnen z. B. Angebotsinforma-tionen in einem eigenst�ndigen XML-Do-kument dargestellt und deren visuelle In-terpretation durch Extensible StylesheetLanguage Transformations (XSLT)[XSLT00] beschrieben werden. Die Struk-tur von XML-Dokumenten kann durchDocument Type Definitions (DTDs) oderXML Schemata [XMLS00] beschriebenwerden. Hierdurch wird es m�glich, unter-nehmens�bergreifende Vokabularien zudefinieren, welche die Interoperabilit�tbeim Informationsaustausch zwischen ver-schiedenen Anwendungen sicherstellen[CXML00]. Bild 1 zeigt, wie Angebots-informationen durch XML-Dokumentedargestellt werden k�nnen.

Das Document Object Model (DOM)[DOM00] erm�glicht eine einfache Ver-arbeitung von HTML- und XML-Doku-menten und den gezielten Zugriff auf In-formationen �ber definierte, sprachen-�bergreifende Schnittstellen. Das DOM istein Objektmodell. Es zeigt auf, wie Doku-mente durch Objekte und logische Bezie-hungen zwischen den Objekten repr�sen-tiert werden k�nnen. Die Manipulationder Dokumente erfolgt durch Methodender Objekte, die Darstellung der Datendurch deren Attribute.

Neben HTML und XML k�nnte auchdas Resource Describtion Format (RDF)bei der Darstellung von Angebotsinforma-tionen durch die Anbieter Verwendungfinden.

3 Angebotsrecherche

3.1 Identifizierbare TeilproblemeDas Ziel der Angebotsrecherche ist dieeinheitliche Interaktion von Kunden miteiner Vielzahl von H�ndlern. Sie erm�g-licht potenziellen K�ufern die Produktaus-wahl, den Angebotsvergleich sowie dieProduktbestellung �ber H�ndlergrenzenhinweg. Kunden werden dadurch Kauf-entscheidungen erleichtert, K�ufer beimEinkauf unterst�tzt und die Transparenzdes elektronischenMarktes erh�ht.

Folgende Teilprobleme m�ssen bei derAngebotsrecherche gel�st werden:

, Extraktion der Angebotsinformationenvon Online-Shops, da diese im All-

Bild 1 XML-Dokument mit Angebotsinformationen f�r Prozessoren


158

gemeinen nicht an einem Vergleich ih-rer Angebote mit denen anderer H�nd-ler interessiert sind,

, Realisierung von Nutzungsoberfl�chenf�r die Spezifikation von Suchkriterien,den Vergleich und die Gegen�berstel-lung von Angeboten,

, Suche und Akkumulation von Ange-botsinformationen, die den von den Be-nutzern spezifizierten Suchkriterienentsprechen,

, Schaffung einer Schnittstelle f�r das Be-stellen in verschiedenenOnline-Shops.

Die Architekturen zur Angebotsrecherchem�ssen die L�sung dieser Teilproblemedurch ihre Strukturierung widerspiegeln.

3.2 Anforderungen

Die Angebotsrecherche findet in einem �u-ßerst heterogenen Umfeld statt. Online-Shops unterscheiden sich hinsichtlich derangebotenen Produkte, der Pr�sentationdes Produktkataloges und der gesamtenAblauforganisation. Sie selbst stellen kom-plexe Softwareprodukte dar, die ihrerseitseine gewisse Ausfallwahrscheinlichkeitund Fehleranf�lligkeit besitzen. Anwen-dungen zur Angebotsrecherche m�ssendaher auf Unerreichbarkeit der Anbieterund auf �nderungen der Pr�sentations-und Seitenstruktur ad�quat reagieren.

Architekturen zur Angebotsrecherchem�ssen ein H�chstmaß an Fehlertoleranz,Robustheit und Flexibilit�t gew�hrleisten.Eine gute Erweiterbarkeit, wie z. B. anneue Produktarten und Online-Shops, istw�nschenswert. Ein großer potenziellerBenutzerkreis kann nur dann erreicht wer-den, wenn sich die Applikationen zur An-gebotsrecherche durch einfache Bedie-nung, intuitiven Umgang und einen nurminimalen Administrationsaufwand aus-zeichnen. Weiterhin m�ssen die Anwen-dungen Interaktivit�t und damit geringeReaktionszeiten bei Anfragen gew�hrleis-ten. Die bei der Recherche ermittelten An-gebote m�ssen konsistent sein, d. h. aktuellg�ltige Angebote der Online-Shops dar-stellen.

4 Entscheidungskriterien f�rden Einsatz mobiler Agentenbei der Angebotsrecherche

In diesem Abschnitt werden die Vor- undNachteile mobiler Agenten beim Einsatzf�r die Angebotsrecherche aufgef�hrt. DieMehrheit der hier besprochenen Punkte istauch in anderen Anwendungskontexteng�ltig.

4.1 Nachteile, F�r die Abarbeitung mobiler Agenten

muss eine ausreichende Infrastrukturvon Agentenplattformen vorhandensein.

, Der Einsatz mobiler Agenten auf nichtvertrauensw�rdigen Rechnern bedeutetein Sicherheitsproblem, da die Agentensowohl ihren Code als auch ihre Datenvollst�ndig diesen Rechnern �bergeben[FGS96;Matt98].

, Der Code mobiler Agenten sollte nichtzu umfangreich sein.

4.2 Vorteile, Der Einsatz mobiler Agenten erfordert

keine st�ndig aktive Netzwerkverbin-dung zwischen den beteiligten Rech-nern, weil sie weitgehend autonom aufden entfernten Plattformen agierenk�nnen.

, Im Vergleich zum typischen Client-Ser-ver-Ansatz kann die Verwendung mo-biler Agenten bei vorgegebenenSchnittstellen auf Seiten der Server zueiner deutlichen Verringerung derNetzwerklast f�hren. Server stellen imAllgemeinen eine vorgegebene Anzahlvon Diensten bereit, die eine bestimmteErgebnismenge zur�ckliefern. Typi-scherweise wird dieses Ergebnis in sei-ner Gesamtheit zum Client transferiert.Mobile Agenten haben dieM�glichkeit,die Ergebnismenge noch vor der �ber-tragung zu evaluieren, einzuschr�nkenoder umzuformen. Daf�r muss dieFunktionalit�t des Servers nicht ver-�ndert werden. �bertragen werden beidiesem Ansatz nur noch die einge-schr�nkte Ergebnismenge und derAgent selbst. Mobile Agenten habendieM�glichkeit, die Menge der relevan-ten Angebote schon auf den Agenten-plattformen der Anbieter einzuschr�n-ken. Dadurch ergibt sich ein erheblichesEinsparpotenzial im Umfang der zu�bertragenden Daten.

, Der Einsatz mobiler Agenten erh�htdie Flexibilit�t von Anwendungen imVergleich zu Techniken, bei denen festvorgegebene Funktionen anderer Rech-ner �ber ein Netzwerk benutzt werden.Mobile Agenten k�nnen eine VielzahlunterschiedlicherAufgaben auf den ent-fernten Rechnern ausf�hren. NeuartigeAgenten erfordern nicht zwingend An-passungen des Servers [BZW98].

Kernpunkte f�r dasManagement:

Der Beitrag befasst sich mit Architekturen zur Angebotsrecherche im Business-to-Consumer-Commerce, die zu einer erh�hten Benutzerfreundlichkeit und�bersichtlichkeit beim virtuellen Einkauf beitragen. Die Kernaussagen sind:, Der Einsatz von Agenten als Vermittler im elektronischen Handel zum

Zwecke einer weitgehenden Nutzerunterst�tzung und der Vertretung unter-schiedlichster Anwenderinteressen ist dringend erforderlich.

, Ein umfassender Angebotsvergleich ist ohne explizite Zustimmung der Anbie-ter m�glich und wird durch die Verwendung von XML vereinfacht.

, Der Einsatz mobiler Agenten f�hrt zu einer erh�hten Flexibilit�t und einereinfachen Erweiterbarkeit der Anwendungen zur Angebotsrecherche.

, Die Repr�sentation von Angebotsinformationen in XML-Dokumenten erleich-tert deren Transport, Austausch undWeiterverarbeitung und vermindert denImplementierungsaufwand.

Einsatz von mobilen Agenten und XML zur Angebotsrecherche

159

, Im Umfeld der Angebotsrecherche er-m�glicht der Einsatz mobiler Agentendie Verwirklichung von Verhandlungs-phasen mit den Anbietern. Sie k�nnendie Ergebnisse der Interaktion mit An-bietern direkt bei Verhandlungen mitanderen nutzen, wenn sie die H�ndlersequenziell nacheinander besuchen. Siesind nicht an eine vorgegebene Reihen-folge beim Besuch von Anbietern ge-bunden. Die F�higkeit der Agenten, au-tonom mit andern Agenten auf den un-terschiedlichen Plattformen zu intera-gieren, erm�glicht dynamische Anpas-sungen im Vorgehen der Agenten undden Austausch von Angebotsinforma-tionen unter den Agenten.

5 Architekturenzur Angebotsrecherche

5.1 GrobstrukturBei den im Folgenden dargestellten Archi-tekturen wird stets zwischen Front- undBack-End differenziert. Das Front-Endbesteht aus einem Client f�r die Interakti-on mit dem Benutzer und Schnittstellenzwischen Client und Server. Im Front-Endwird die Benutzungsoberfl�che realisiert,die den Anwendern die Spezifikation vonAnforderungskriterien und den Vergleichvon Ergebnissen erm�glicht. Die Verarbei-tung der Anwenderdaten sowie der Zugriffauf Datenbanken und Online-Shops er-folgt im Back-End. Es besteht aus einemServer und architekturabh�ngig aus wei-teren Bestandteilen, wie z. B. Datenbankenundmobilen Agenten.

5.2 Das Front-End

F�r die Umsetzung der Interaktion zwi-schen Client und Anwender k�nnenHTML-Formulare und Java-Applets inVerkn�pfung mit Web-Browsern oder ei-genst�ndige, vonWeb-Browsern unabh�n-gige Applikationen benutzt werden. Beider Verwendung von HTML-Formularenben�tigt der Anwender lediglich einen ru-diment�ren Web-Browser f�r die Inter-aktion mit der Anwendung. Die Formular-daten werden �ber das Hypertext TransferProtocol (HTTP) an den Server �bertra-gen, der in diesem Fall ein Web-Server ist.Bei der Gestaltung von Oberfl�chen durchHTML bzw. HTML-Formulare bestehenstarke Restriktionen bei der Auswahl vonOberfl�chenelementen.

Die Verwendung von Java erm�glichtdie Gestaltung komplexerer Oberfl�chen.Die Benutzung von nicht vertrauensw�r-digem Code – den Java-Applets ohneZweifel darstellen – ist f�r die Verwendungin E-Commerce-L�sungen jedoch proble-matisch und reduziert das Vertrauen in sol-che Anwendungen. Von Web-Browsernunabh�ngige Applikationen bedeuten er-h�hten Administrationsaufwand f�r dieAnwender, weil die Programme explizitinstalliert werden m�ssen. Dies wider-spricht der bereits weiter oben festgelegtenAnforderung an einen geringen Adminis-trationsaufwand.

5.3 Architekturenf�r das Back-End

In diesem Abschnitt wird davon ausgegan-gen, dass die Interaktion zwischen demAnwender und der Applikation �ber einenWeb-Client erfolgt. Der zentrale Server istdamit ein Web-Server, dessen Funktionali-

t�t durch anwendungsspezifische Skripte,wie Servlets, ASP- (Active Server Page)oder CGI-Skripte, erweitert wird. Der Be-nutzer legt durch Verwendung des Clientsdie Anforderungskriterien an zu ber�ck-sichtigende Angebote, wie z. B. eine Preis-spanne oder Lieferbedingungen, fest. Da-raufhin werden diese Daten an den Server�bertragen und dort durch serverseitigeSkripte verarbeitet. Diese ermitteln die zuden festgelegten Anforderungskriterienpassenden Angebote und betten sie in einHTML/XML-Dokument ein, welches andenWeb-Client gesandt und dort demAn-wender dargestellt wird. Bei der Bestellungvon Angeboten kontaktieren die Skriptedirekt dasWarenkorbsystem der Anbieter.

5.3.1 Architekturenohne mobile Agenten

In dieser ersten Architekturvariante er-folgt die Extraktion der Angebotsinforma-tionen von den Anbietern direkt nachdemein Nutzer Suchparameter spezifiziert hat.Ein serverseitiges Skript kontaktiert se-quenziell die zu durchsuchenden Online-Shops und erh�lt daraufhin XML- bzw.HTML-Dokumente, in denen die Datenzu aktuellen Angeboten eingebettet sind.Aus diesen Dokumenten m�ssen die An-gebotsinformationen extrahiert und auf�bereinstimmung mit den Suchkriterienhin �berpr�ft werden (siehe Kap. 6). AlsResultat generiert das Skript ein HTML-bzw. XML-Dokument mit den Suchergeb-nissen und sendet es zur�ck an den Web-Client. Dieser interpretiert das gesandteDokument und stellt die Ergebnisse demBenutzer dar.

Da die Angebotsdaten unmittelbarnach der Formulierung einer Suchanfragedurch direkten Zugriff auf die Online-Shops gewonnen werden, spiegeln dieseInformationen stets die aktuell g�ltigenAngebote wider. Die Konsistenz der demNutzer pr�sentierten Daten ist dadurchgew�hrleistet. Es wird außerdem nur aufdie Angebotsdaten zugegriffen, die tat-s�chlich ben�tigt werden und im gegen-w�rtigen Kontext relevant sind.

In der Tatsache, dass die Extraktion derAngebotsinformationen erst zu dem Zeit-punkt stattfindet, zu dem ein Anwenderdie Suchanfrage stellt, liegt jedoch auch einwesentlicher Nachteil dieser Methode be-gr�ndet. Da der Vorgang der Extraktionrelativ viel Abarbeitungszeit in Anspruchnimmt, wird ein Anwender mit hohen Re-

Client

Web-Server

CGI-Skripte,ASP, Servlets

Online-Shop 1

Online-Shop 2

Online-Shop n

...Bild 2 Architektur zur Angebotsrecherche ohne mobile Agenten


160

aktionszeiten konfrontiert. Die Interakti-vit�t kann deshalb bei diesem Ansatz nichtgew�hrleistet werden.

5.3.2 Zugriff aufAngebotsinformationenmit mobilen Agenten

Diese Architektur hat �hnlichkeit mitdem zuvor dargestellten Ansatz. Die Ak-kumulation der Angebotsinformationenerfolgt hierbei jedoch durch mobile Agen-ten, die von den imWeb-Server residieren-den Skripten generiert werden. Eine Vo-raussetzung dabei ist, dass die Online-Shops eine Agentenplattform f�r die Abar-beitung dieser Agenten bereitstellen, in de-nen die Agenten z. B. durch Kommunika-tion mit Informationsagenten der Anbieteraktuelle Angebote ermitteln k�nnen. An-bieter stellen zurzeit solche Agentenplatt-formen nicht zur Verf�gung. Im heutigenUmfeld ist diese Architektur daher nichtdirekt umsetzbar. In der Zukunft k�nntensolche Ans�tze jedoch verwendet werden,wenn die Systeme der Anbieter z. B. f�rVerhandlungsphasen um Kaufkonditionenge�ffnet werden. Solche Funktionen sindam ehesten durch Verhandlungen zwi-schen Agenten umsetzbar, die ihrerseitsunterschiedliche Parteien vertreten.

5.3.3 Ablagevon Angebotsinformationenin lokalen Datenbanken

Anwendungen zur Angebotsrecherche be-schr�nken sich im Allgemeinen auf einefestgelegte Anzahl von Produktarten. F�rdiese Produktgruppen existieren Formula-re f�r die Spezifikation von Anforde-rungskriterien an Angebote und die Gene-rierung von Suchanfragen. Nun ist esm�glich, in regelm�ßigen, m�glichst kur-zen Abst�nden, die Anbieter zu kontak-tieren und s�mtliche Angebote der be-trachteten Produktkategorien zu ermittelnund in einer zum Server lokalen Daten-bank abzulegen. Die Abfrage der Ange-botsinformationen erfolgt im Hintergrundunabh�ngig von konkreten Anfragen. Da-durch vereinfacht sich die Wirkungsweisedes serverseitigen Skriptes f�r die Behand-lung von Nutzeranfragen, weil es lediglichdie Anforderungen des Benutzers in eineDatenbankanfrage transformieren muss.Diese Vorgehensweise impliziert k�rzereAntwortzeiten und sichert damit die In-

teraktivit�t beim Umgang mit der Anwen-dung.

Bild 3 zeigt schematisch den Aufbau ei-ner solchen Architektur, wobei hier dieAkkumulation der Angebotsinformatio-nen durch mobile Agenten erfolgt. Dabeihandelt es sich um eine klassische 3-tier-Architektur, erweitert um den Einsatz mo-biler Agenten. [EdVo97] beschreibt, wieN-tier-Architekturen im Zusammenhangmit großen, skalierbaren, webbasiertenSystemen Verwendung finden k�nnen.

Ein Problem bei diesem Ansatz bestehtdarin, die Konsistenz zwischen den in derDatenbank abgelegten und den imOnline-Shop dargestellten Angeboten sicher-zustellen. Finden sich in der Datenbankveraltete Daten, dann kann das zu Fehler-situationen bei der Zusammenarbeit mitden Online-Shops f�hren. Der Online-Shop Alternate beispielsweise reagiertbeim Versuch, einen nicht mehr in der Pro-duktpalette enthaltenen Artikel zu bestel-len, mit einem �berlauf beim Wert desWarenkorbs. Die Angebotsdaten derH�ndler m�ssen daher in regelm�ßigen,verh�ltnism�ßig kurzen Abst�nden abge-fragt werden.

F�r die Ermittlung der Angebote vonden H�ndlern k�nnen mobile Agenteneingesetzt werden. Ebenso ist es m�glich,die Online-Shops direkt zu kontaktieren.

5.3.4 Akkumulation der Angebotevon mehreren Servern

Die bisher vorgestellten, auf mobilenAgenten basierenden Architekturen sindf�r den Einsatz im heutigen E-Commerce-

Umfeld wenig praktikabel, da die Online-Shops keine Plattformen f�r die Abarbei-tung mobiler Agenten bereitstellen. Dienun einzuf�hrende Architektur integriertAgentenplattformen in die Anwendungzur Angebotsrecherche selbst. MobileAgenten werden dabei f�r die flexible Ak-kumulation und den Austausch der Ange-botsdaten eingesetzt. Die Architektur rea-lisiert einen verteilten Ansatz.

Die Grundidee ist, dass verschiedene imInternet verteilte Server in regelm�ßigenAbst�nden die aktuellen Angebote unter-schiedlicher Anbieter ermitteln. Diese An-bieter k�nnen Online-Shops sein; prinzi-piell kann es sich bei ihnen aber auch umMarktpl�tze f�r Auktionen o.�. handeln.So k�nnte beispielsweise ein Rechner inNew York die Angebote New Yorker On-line-Shops ermitteln, w�hrend ein zweiterin Rostock die Angebote RostockerTauschb�rsen untersucht. Die Ergebnissedes Extraktionsprozesses werden dann inrelativ zu den jeweiligen Rechnern lokalenDatenbanken abgespeichert. Die Rechnerstellen Agentenplattformen f�r die Abar-beitung mobiler Agenten bereit. Der Zu-griff auf die Angebotsinformationen derH�ndler erfolgt durch direkte Kontaktie-rung der Online-Shops (siehe Kap. 6).

Als Reaktion auf eine Anfrage generie-ren die Skripte des Web-Servers mobileAgenten, die zu den entfernten Rechnernmigrieren. Dort ermitteln sie zu den spezi-fizierten Anforderungskriterien passendeAngebote, indem sie mit anderen AgentenDaten austauschen und Anfragen an dieDatenbanken stellen. Dies kann auf unter-schiedliche Weisen erfolgen. Mobilen

Client

Web-Server


Online-Shop 1

Agentenplattform

Online-Shop 2

Agentenplattform

Online-Shop n

Agentenplattform

...

Datenbank

Bild 3 Einsatz mobiler Agenten f�r die Interaktion mit den Anbietern


161

Agenten selbst sollte der Zugriff auf dieDatenbanken nicht gestattet sein, da sie f�rdie entfernten Rechner nicht vertrauens-w�rdigen Code darstellen. Sinnvoll ist indiesem Zusammenhang die Verwendungstation�rer Agenten mit weitreichenderenRechten in den jeweiligen Plattformenzum Zugriff auf die Datenbanken. Damiterfolgt die Akkumulation der Daten aufeinheitliche Weise: durch Interaktion mitanderen Agenten. Letztendlich kehrt dermobile Agent zu dem Server zur�ck, aufdem er erzeugt wurde.

Flexibilit�t, gute Erweiterbarkeit undSkalierbarkeit zeichnen diesen Ansatz aus.Hohe Flexibilit�t ist dadurch gew�hrleis-tet, dass das Verhalten der mobilen Agen-ten dynamisch in Abh�ngigkeit von denErgebnissen der Kommunikation mit an-derenAgenten angepasst werden kann. Be-finden sich beispielsweise von verschiede-nen Benutzern generierte Agenten in einerPlattform, so k�nnen die Agenten unter-einander Angebotsinformationen derH�ndler austauschen. Unter Umst�ndenmuss ein Agent bestimmte Server dann garnicht besuchen, weil die von ihm gesuch-ten Angebote in der Ergebnismenge ande-rer Agenten bereits enthalten waren. Zu-s�tzliche Rechner, die weitere Anbieteruntersuchen, k�nnen problemlos in einesolche Architektur integriert werden. Da

die Interaktion mit den Anbietern unab-h�ngig von konkreten Anfragen erfolgt,wird interaktives Arbeiten unterst�tzt.

5.4 Minderung derFehleranf�lligkeit beim Einsatzmobiler Agenten

Bei den bisher vorgestellten Architekturenf�hrte die Verwendung mobiler Agentenzu einer erh�hten Fehleranf�lligkeit. Beieinem Ausfall einzelner Agentenplattfor-men eines Anbieters oder bei Netzwerk-fehlern, die zu einem Verlust des mobilenAgenten f�hrten, konnte kein einziges Er-gebnis zum Client transferiert werden.D. h., ein einziger Fehlerpunkt f�hrte zumFehlschlagen gesamter Anfragen.

Ein erster L�sungsvorschlag f�r diesesProblem besteht darin, Zwischenergebnis-se des Agenten nach dem Besuch einerfestgelegten Anzahl von Anbietern an denServer zu �bertragen. Geht der Agent imNachhinein verloren, so k�nnen zumin-dest die bis dahin erhaltenen Ergebnissedem Anwender dargestellt werden. Eben-so ist es m�glich, durch das serverseitigeSkript mehrere Agenten zu generieren, dieverschiedene Agentenplattformen besu-chen.

Der Vorgang der Migration mobilerAgenten erfordert, dass deren gesamterCode und Zustand in ein Format transfor-miert werden kann, welches in einemNetzwerk �bertragbar ist. Dieses Formatkann auch verwendet werden, um dieAgenten und die mit ihnen assoziierten In-formationen auf einem Datentr�ger abzu-legen. Damit kann der Agent �ber einefestgelegte Zeitspanne zwischengespei-chert und im Ausnahmefall reaktiviertwerden.

Eine weitere Architekturvariation be-steht in der Erzeugung zweier Agenten,die einander mit der Verz�gerung von ei-ner Agentenplattform folgen. Verl�sst dererste Agent eine Plattform, so kontaktierter den zweiten Agenten, der daraufhinebenfalls die n�chste Agentenplattform be-sucht. Das ist die, die der erste Agent gera-de verl�sst. Trifft kein Signal zum Verlas-sen der Plattform in einer vordefiniertenZeitspanne ein, wird der zweite Agentdupliziert und der neu erzeugte Agent�bernimmt die Rolle des ersten. Dabeiwird vom Verlust des ersten Agenten undvon einer Fehlersituation in der entspre-chenden Plattform ausgegangen. DiesePlattform wird durch den zweiten Agen-ten nicht noch einmal besucht. Analog ver-h�lt sich der erste Agent bei Verlust deszweiten.

6 Interaktion mitden Online-Shops

6.1 Zugriff auf die Funktionalit�tder AnbieterBei der Beschreibung der Architekturenzur Angebotsrecherche wurde schonmehrfach auf die notwendige Zusammen-arbeit mit den Online-Shops hingewiesen.Stellen Anbieter Agentenplattformen be-reit, dann kann die Kommunikation mitihnen direkt �ber die von der Agenten-plattform bereitgestellten Schnittstellen er-folgen. Ein solcher Ansatz ist z. B. im Zu-sammenhang mit auf Agenten basierendenMarktpl�tzen denkbar, bei der Strukturheutiger Online-Shops jedoch nicht prak-tikabel. Wie das Beispiel BargainFinder[Krul96] zeigt, sind einige Anbieter an ei-nem Vergleich ihrer Angebote nicht inte-ressiert und werden Anwendungen zurAngebotsrecherche keine erweiterten Zu-

Client

Web-Server


Server 1

Agentenplattform

Server n

Agentenplattform

Daten-bank

Daten-bank

Online-Shop 1

Online-Shop 2

Online-Shop A

Online-Shop B

......

...

Bild 4 Akkumulation der Produktdaten durch mobile Agenten


162

griffsm�glichkeiten auf ihre Daten gew�h-ren.

Anwendungen zur Angebotsrecherchem�ssen sich daher wie normale Kundenverhalten, um an Angebotsinformationenzu gelangen und Produkte zu bestellen.Hierbei wird der prinzipielle Aufbau vonOnline-Shops ausgenutzt, zu deren we-sentlichen Komponenten die Pr�sentati-onskomponente sowie Datenbanken mitAngebots- und Kundeninformationenz�hlen [Merz99]. Zum Online-Shop geh�-rende Skripte verarbeiten die von den Be-nutzern eingegebenen Daten und nehmendie Umsetzung der in den Datenbankenabgelegten Informationen in HTML- bzw.XML-Dokumente vor (siehe Bild 5). BeimAnbieter Avitos verrichten Active ServerPages (ASP) diese T�tigkeiten. Online-Shops wie Alternate und Mix verwendenin Perl realisierte CGI-Skripte. Kontak-tiert ein Kunde mit seinem Web-Browsereinen Online-Shop, bl�ttert durch den an-gebotenen Produktkatalog oder f�gt Pro-dukte einem Warenkorb hinzu, so werdenbei fast jedem dieser Schritte Skripte desAnbieters kontaktiert.

Die Kommunikation mit den Skriptender Online-Shops, die im Normalfall �berHTML-Formulare erfolgt, muss in derAnwendung zur Produktrecherche nach-gebildet werden. Dazu m�ssen folgendePunkte untersucht werden:

, Funktionalit�t der Skripte. Zun�chststellt sich die Frage, welche Programmeein Online-Shop �berhaupt zur Ver-f�gung stellt und was diese Skripteletztendlich bewirken. Dazu muss zu-meist der Quellcode der von dem On-line-Shop generierten HTML-/XML-Dokumente untersucht werden. Ins-besondere die dort beinhalteten Formu-lare sollten beachtet werden, da sie z. B.zul�ssige Parameter f�r die Skripte fest-legen. Die Funktionalit�t im Einzelfallh�ngt von den spezifizierten Parame-tern ab.

, �bertragungsart der Formulardaten.Der form-Tag von HTML-Dokumen-ten gibt Aufschluss dar�ber, welche�bertragungsart im Hypertext TransferProtocol f�r die Parameter verwendetwird.

, Identifikation zul�ssiger Parameterund Parameterwerte. Letztendlichm�ssen die von den Skripten verarbeit-baren Parameternamen und -werte be-stimmt werden. Die Parameternamen

sind die Namen der Elemente einesHTML-Formulars. Bei Auswahlboxenund versteckten Elementen sind die zu-l�ssigen Parameterwerte sofort klar,weil sie im HTML-/XML-Dokumentangegeben sind. Bei Eingabefeldern er-geben sie sich aus demKontext.

Es existieren Werkzeuge, welche die Un-tersuchung solcher Formulare verein-fachen [W4F00].

6.2 Extraktion vonAngebotsinformationen

Erfolgt die Interaktion mit den Anbieterndurch den externen Zugriff auf derenSkripte, dann erzeugt das Katalogsystemder Anbieter im Allgemeinen HTML-/XML-Dokumente, in denen die Ange-botsinformationen eingebettet sind. F�rdie automatische Weiterverarbeitung m�s-sen die relevanten Daten aus diesen semis-trukturierten Dokumenten extrahiert wer-den.Werkzeuge wie derWrappergeneratorW4F [W4F00] oder JEDI [Huck00] ver-einfachen diesen Vorgang. Als Ergebnisdes Extraktionsprozesses werden XML-Dokumente mit aktuellen Angebotsinfor-mationen erzeugt.

Bei jedem Anbieter besitzen die Doku-mente mit den Angebotsinformationen ei-ner Produktkategorie implizit eine ge-meinsame Struktur, weil sie automatischdurch das gleiche Skript erzeugt werden.Dies wird im Extraktionsprozess aus-genutzt.

Folgende Ans�tze k�nnen bei der Ex-traktion aus HTML-/XML-Dokumentenunterschieden werden:

, Durch einen �bersetzer werden dieDokumente in ein internes Modell�berf�hrt, �ber dessen Methoden derZugriff auf relevante Bestandteile er-folgt. Das kann beispielsweise durch ei-ne Transformation in eine DOM-Re-pr�sentation vollzogen werden. Die�berf�hrung des gesamten Dokumentsin eine interne Darstellung ist aufwen-dig, wenn nur einzelne Teile des Doku-ments betrachtet werden.

, F�r bestimmte Klassen von Dokumen-ten werden kontextfreie Regeln unddiesen Regeln zugeordnete semantischeAktionen formuliert, welche den Auf-bau des Ergebnisdokuments beschrei-ben. Dieser Ansatz wurde in der Refe-renzimplementierung realisiert.

, Stellen die Anbieter XML-Dokumentemit Angebotsinformationen bereit, sok�nnen XSLT (Extensible StylesheetLanguage Transformations) [XSLT00]f�r die �berf�hrung in das Zielformatbenutzt werden, das ja wiederum XMList. Einigen sich die Anbieter auf eineinheitliches Format zur Darstellungder Angebotsinformationen, dann kannauf die Transformation ganz verzichtetwerden!

7 Verwendung von XML

Die Verwendung von XML ist in verschie-denen Phasen der Angebotsrecherchesinnvoll. Es wurde bereits beschrieben,wie XML als Ergebnisformat bei der An-gebotsdatenextraktion benutzt wird. Derwesentliche Vorteil ist dabei eine verein-

Web-Browser

Formulardaten

HTML-Dokumente

Online-Shop

Datenbank mitAngebots- undKundendaten

…

Shop-Funktionalität(CGI-Skripte, ASP, Servlets)

Warenkorb

Produktkatalog

Suchfunktionen

Bild 5 Typischer Ablauf einer Anfrage bei Online-Shops


163

fachte Verarbeitung und �bertragung vonAngebotsinformationen. In der Referen-zimplementierung (siehe Kap. 8) werdendie Angebotsdaten in XML-Dokumentendargestellt. Das DOM, von dem es vielefreie Implementierungen gibt, wird da-raufhin verwendet, um auf einzelne XML-Elemente zuzugreifen, diese in einer rela-tionalen Datenbank abzulegen oder in an-dere Formate zu transferieren. Ebenso w�-re es m�glich, die Daten der DOM-Repr�-sentation in einer objektorientierten Da-tenbank abzuspeichern; das DOM selbstist ja ein Objektmodell. Da die Daten-extraktion in diesem Fall formal als eineAbbildung semistrukturierter Daten aufXML-Dokumente angesehen werdenkann, ergeben sich einfachere Transforma-tionen besonders dann, wenn die Online-Shops XML- statt HTML-Dokumente er-zeugen. Eine solche Entwicklung hin zurVerwendung von XML auf Seiten der An-bieter ist zu erwarten [BeMi98]. In diesemFall k�nnen XSLT f�r die Transformationzwischen verschiedenen Formaten ver-wendet werden. Der Einsatz von XMLverbessert damit die Zusammenarbeit mitden Anbietern, weil die Datenextraktioneinfacher und bei der Verwendung gleicherVokabularien sogar �berfl�ssig wird. Dasimpiziert eine vereinfachte Erweiterbar-keit der Anwendungen zur Angebots-recherche. XML-Dokumente k�nnen sehrflexibel in andere Formate transformiertoder in Datenbanken abgelegt werden[KlMe99].

Der Einsatz von XML ist jedoch nichtnur auf die Extraktionsphase beschr�nkt.

Auch die mobilen Agenten k�nnen XMLals Format f�r den Informationsaustauschbenutzen.

8 Schn�ppchenj�ger –ein webbasiertes Systemzur Angebotsrecherche aufder Basis mobiler Agenten

8.1 FunktionsumfangDie Anwendung Schn�ppchenj�ger reali-siert die in Abschnitt 5.3.4 eingef�hrteArchitektur. Durch die Applikation wer-den die Angebote der Online-Shops Al-ternate, Mix und Avitos miteinander ver-glichen. Exemplarisch wurden die Pro-duktgruppen Motherboards, Prozessorenund Monitore f�r eine Gegen�berstellungausgew�hlt. Auf die aktuellste Version derAnwendung kann �ber folgende URLzugegriffen werden: http://gkpc14.rbg.informatik.tu-darmstadt.de/schnaeppchen.

In einem typischen Anwendungsszena-rio entscheidet sich der Anwender f�r dieRecherche in einer Produktgruppe und hatdaraufhin die M�glichkeit, Anforderungenan Angebote in dieser Kategorie zu spezi-fizieren. Dazu steht ihm jeweils ein For-mular zu Verf�gung. Die Anforderungs-kriterien sind vielf�ltig: in der KategorieProzessoren k�nnen u.a. der Prozessortyp,eine Produktbezeichnung, der gew�nschteHersteller und eine Preisspanne angegebenwerden. Wie in Abschnitt 5.3.4 beschrie-

ben, werden auf der Grundlage dieser Da-ten zugeh�rige Angebote der betrachtetenH�ndler ermittelt und dem Benutzer in ei-ner Ergebnisliste dargestellt.

Da diese bei einer großen Anzahl vonElementen un�bersichtlich wirkt, hat derBenutzer die M�glichkeit, interessanteAngebote auf eine Preisliste zu setzen.Diese Liste kann jederzeit aufgerufen wer-den. Auf ihr werden die wichtigsten Infor-mationen zu den Angeboten zusammenge-fasst. Durch direkte Kontaktierung derAnbieter ist es m�glich, n�here Informa-tionen zu ausgew�hlten Produkten zu be-kommen. Weiterhin hat der Anwender dieOption, ein Produkt aus der Anwendungheraus zu bestellen. Dabei wird das aus-gew�hlte Produkt dem Einkaufskorb beimjeweiligen Anbieters hinzugef�gt.

8.2 Implementierungsdetails

Der Client f�r die Interaktion mit demAnwender wurde als HTML-Oberfl�cherealisiert, wobei die Nutzereingaben inHTML-Formularen verarbeitet werden.Damit ist f�r die Benutzung des Program-mes lediglich ein Web-Browser erforder-lich. Eine Installation oder Administrationder Anwendung durch den Benutzer ent-f�llt dadurch.

Bei der Implementierung des Back-Ends wurde darauf Wert gelegt, die Pro-grammiersprache Java m�glichst durch-g�ngig zu verwenden, weil sich dadurchdie Kommunikation zwischen den einzel-nen Teilkomponenten vereinfacht. Alszentraler Server wird ein Tomcat-Webser-ver verwendet. Servlets erweitern dieFunktionalit�t dieses Servers und verarbei-ten die Nutzereingaben. Sie wurden unterVerwendung des Java Servlet Develop-ment Kit (JSDK) implementiert. Tomcatist direkt in der Lage, Servlets zu verarbei-ten.

Zus�tzlich zum zentralen Web-Serverexistieren weitere im Internet verteilte Ser-ver. Sie stellen jeweils eine Plattform f�rmobile Agenten bereit, die unter Benut-zung des Aglet Software Development Kit(ASDK) von IBM erstellt wurden. Jedemdieser Server sind bestimmte Online-Shops zugeordnet, deren Angebote allezwei Stunden abgefragt werden. Die Ex-traktionsregeln wurden mit der Skript-sprache von JEDI [Huck00] formuliert.F�r jeden Shop gibt es ein �bergeordnetesSkript, das allgemeine Regeln f�r die Ver-

Bild 6 Ergebnisliste mit Angeboten verschiedener H�ndler


164

arbeitung von Preisangaben, Tabellenspal-ten usw. enth�lt. Die Skripte f�r die Pro-duktgruppen werden dadurch sehr ein-fach. Als Ergebnis des Extraktionsprozes-ses entstehen XML-Dokumente mit denaktuellen Angebotsinformationen auf die�ber das DOM zugegriffen wird. JAXP(Java API for XML Parsing) erm�glichtdiese Art der Verarbeitung. Die Angebots-informationen werden in einer zu den Ser-vern lokalen Datenbank abgespeichert.Dazu dient zurzeit eine PostgreSQL-Da-tenbank, auf die �ber JDBC (Java Databa-se Connectivity) zugegriffen wird. In je-dem der Server residieren station�re Agen-ten, die den Datenbankzugriff vornehmen.Mobile Agenten k�nnen nicht direkt aufdie Datenbank zugreifen, sondern m�ssendaf�r mit den station�ren Agenten kom-munizieren.

Bei der Angebotsrecherche werden sei-tens der Servlets mobile Agenten generiert,welche die von den Servern bereitgestelltenAgentenplattformen besuchen. Dort akku-mulieren sie durch Interaktion mit den an-deren Agenten aktuelle Angebotsinforma-tionen und kehren letztendlich zum Web-Server zur�ck.

9 Schlussfolgerungenaus der Implementierung

In der Praxis treten teilweise unvorherseh-bare Fehlerbedingungen auf. Der Online-Shop Mix bot beispielsweise gleiche Pro-dukte zu unterschiedlichen Preisen an; dieSkripte des Anbieters Alternate generier-ten, indem sie den abschließenden<html>-Tag unterschlugen, keine vollst�n-digen HTML-Dokumente. �ber die vonden H�ndlern generierten semistrukturier-tenDokumente sollten daher so wenig An-nahmen wie m�glich getroffen werden. Indiesem Zusammenhang hat sich der Ein-satz von JEDI f�r die Angebotsextraktionbew�hrt. Selbst wenn unvorhersehbar Re-geln nicht angewandt werden k�nnen,wird im Nachhinein weiterhin versucht,Ersetzungsregeln anzuwenden. Dies ist einsehr fehlertolerantes Vorgehen [Huck00].

Flexibilit�t und der einfache Austauschvon Informationen mit anderen Anwen-dungen ist in einem hohen Maße durch dieVerwendung von XML gew�hrleistet. Eswar �berraschend, welche Vielfalt an gr�ß-tenteils frei verf�gbaren Werkzeugen die

Verarbeitung von XML vereinfachen. Mitdiesen Tools k�nnen XML-Dokumenteeinfach in eine DOM-Repr�sentation�berf�hrt, in andere Formate transfor-miert oder in Datenbanken abgelegt wer-den. Dies reduziert signifikant den Imple-mentierungsaufwand. Sollten die H�ndlerin der Zukunft XML-Dokumente mit An-gebotsinformationen erzeugen und derenvisuelle Darstellung z. B. durch Stylesheetsbeschreiben, dann wird die Kommunikati-on mit den Anbietern sehr einfach. Damitunterst�tzt XML die Durchsetzung vonAgenten im E-Commerce.

Das ASDK erm�glichte die komforta-ble Realisierung der mobilen Agenten undder zugeh�rigen Plattformen. Durch denverteilten Ansatz und den Einsatz mobilerAgenten ist insbesondere die Integrationweiterer Anbieter einfach m�glich.

10 Zusammenfassungund Ausblick

Diese Arbeit befasste sich mit der Ange-botsrecherche im B2C-Commerce als eineM�glichkeit, die Transparenz des elektro-nischen Marktes zu erh�hen und poten-ziellen K�ufern weitgehende Unterst�t-zung beim Erwerb von Produkten �berKommunikationsnetze zu geben. Es wur-de beschrieben, wie XML und mobileAgenten in Architekturen zur Angebots-recherche eingesetzt werden k�nnen undwelche Vorteile sich daraus gegen�ber an-deren Ans�tzen ergeben.

Durch die Verwendung mobiler Agen-ten kann neuartige Funktionalit�t inE-Commerce-L�sungen integriert wer-den, die f�r die weitere Entwicklung indiesem Bereich von großer Bedeutung seinwird. Dazu z�hlen beispielsweise die Rea-lisierung von Verhandlungen beimOnline-Shopping. In anschließenden Forschungs-arbeiten soll ein Online-Shop entwickeltwerden, der eine Agentenplattform bereit-stellt und so Kunden die M�glichkeit zudirekter Interaktion mit dem Anbieter er-m�glicht. Es lohnt sich zu untersuchen,wie z. B. Verhandlungen oder Beratungenzwischen Kunden und Verk�ufern hierbeibeschrieben und realisiert werden k�nnen.Weiterhin soll betrachtet werden, ob einVerbund solcher Shops, z. B. in einem vir-tuellen Kaufhaus, den Komfort beim Ein-kauf erh�ht.

Literatur

[BeMi98] Behme, H.; Mintert, S.: XML in derPraxis, Professionelles Web-Publishing mit derExtensible Markup Language. Addison-Wes-ley, Bonn 1998.

[BrGo99] Brody, A.B.; Gottsmann, E.J.: PocketBargainFinder: A Handheld Device for Aug-mented Commerce. In: Gellersen, Hans-W.(Hrsg.): Handheld and Ubiquitous Comput-ing. Springer-Verlag, Berlin 1999, S. 44–51.

[BZW98] Brenner, W.; Zarnekow, R.; Wittig, H.:Intelligente Softwareagenten, Grundlagen undAnwendungen. Springer-Verlag, Berlin 1998.

[ChMa96] Chavez, A.; Maes, P.: Kashbah: AnAgent Marketplace for Buying and SellingGoods. In: Proceedings of the First Internatio-nal Conference on the Practical Application ofIntelligent Agents and Multi-Agent Technolo-gy. London 1996.

[CXML00] cXML.org:Commerce XML Resour-ces. http://www.cxml.org, Abruf am 2000-07-10.

[DEW97] Doorenbos, R.; Etzioni, O.; Weld, D.:A scalable comparision-shopping agent for theworld wide web. In: Proceedings of the FirstInternational Conference on AutonomousAgents. Marina del Rey 1997. S. 39–48.

[DOM00] World Wide Web Consortium: Docu-ment Object Model Level 1 Specification.http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/cover.html, Abruf am:2000-08-10.

[EdVo97] Edwards, J.; de Voe, D.: 3-Tier Client/Server At Work. Wiley Computer Publishing,NewYork 1997.

[FGS96] Farmer, W.M.; Guttmann, J.D.; Sarup,V.: Security for Mobile Agents: Issues and Re-quirements. In: Proc. 19th National Informa-tion Systems Security Conf. 1996, S. 591–591.

[GMM99] Guttman, R.; Moukas, A.; Maes, P.:Agents as Mediators in Electronic Commerce.In: Klusch, Matthias (Hrsg.): Intelligent Infor-mation Agents. Springer-Verlag, Berlin 1999,S. 131–152.

[Huck00] Huck, G.: The Jedi Tutorial.http://www.darmstadt.gmd.de/~huck/jedi/tutorial/tutorial.html, Abruf am: 2000-07-03.

[KlMe99] Klettke, M.; Meyer, H.: ManagingXML documents in object-relational databa-ses. Universit�t Rostock 1999.

[Klus99] Klusch, M. (Hrsg.): Intelligent Informa-tion Agents: Agent-Based Information Dis-covery and Management on the Internet. 1.Aufl., Springer-Verlag, Berlin 1999.

[Krul96] Krulwich, B.: The BargainFinder agent:Comparision price shopping on the internet.In: Willliams, J. (Hrsg.): Bots and Other Inter-net Beasties. SAMS.NET, 1996.

[Merz99] Merz, M.l: Electronic Commerce,Marktmodelle, Anwendungen und Technolo-gien. dpunkt-Verlag, Berlin 1999.

[Matt98] Mattern, F.: Mobile Agenten. In: it+ti –Informationstechnik und Technische Informa-tik. 1998, S. 12–17.

[MGM98] Moukas, A.; Guttman, R.; Maes, P.:Agent-mediated Electronic Commerce: AMIT Media Laboratory Perspective. MIT Me-dia Laboratory 1998.


165

[RuNo95] Russel, S.J.; Norvig, P.:Artificial Intel-ligence: A Modern Approach. Prentice Hall,London 1995.

[RuSt87] Runyon, K.; Stewart, D.:Consumer Be-havior. 3. Aufl., Merrill Publishing Company,1987.

[RoPo97] Rothermel, K.; Popescu-Zeletin(Hrsg.): Mobile Agents, First InternationalWorkshop,MA 97. Berlin 1997.

[Shop00] Shop.de:Verzeichnis vonOnline-Shops.http://www.shop.de, Abruf am: 2000-08-15.

[W4F00]World Wide WebWrapper Factory Web-site: http://db.cis.upenn.edu/W4F, Abruf am:2000-07-16.

[Weis00] Weiss, G. (Hrsg.): Multiagent Systems:A Modern Approach to Distributed ArtificialIntelligence. 2. Aufl., MIT Press, Cambridge(Massachusetts) 2000.

[XML00]World Wide Web Consortium: Extensi-bleMarkup Language 1.0. http://www.w3.org/TR/1998/REC-xml-19980210, Abruf am:2000-08-10.

[XMLS00] World Wide Web Consortium: W3CArchitecture Domain, XML Schema. http://www.w3.org/XML/Schema.html, Abruf am:2000-08-10.

[XSLT00] World Wide Web Consortium: XSLTransformations 1.0. http://www.w3.org/TR/xslt/, Abruf am: 2000-08-10.


166

Documents

Einsatz von Mobilen Agenten und XML zur Angebotsrecherche im Business-to-Consumer-Commerce