Webservices zur integration interaktiver elektronischer verhandlungen in elektronische marktplätze;...

1 Einleitung

Elektronische Verhandlungen sind seit ei-nigen Jahren Gegenstand von Forschungs-projekten [etwa deRa01; LeKa97; StCo99;TeWa99; TsGi97]. In der Zwischenzeit be-ruhren auch kommerzielle Entwicklungs-projekte von Softwareunternehmen diesenBereich [etwa Comm02; IBM02; Orac02].Insbesondere die kommerziellen Entwick-lungsvorhaben konzipieren elektronischeVerhandlungen als Bestandteile elektro-nischer Marktplatzanwendungen. Der der-zeitige Funktionsumfang elektronischerMarktplatzanwendungen – in der Regelkatalogbasierte Beschaffung, einattributiveAuktionen und Ausschreibungen – ist ausSicht der Unternehmenspraxis oft unbe-friedigend, da mit ihm nur ein kleinererTeil des Gesamtbeschaffungsvolumens ab-gedeckt werden kann. Weitergehende Ver-handlungsfunktionalitaten werden ver-misst.

Das Projekt MultiNeg, in dessen Rahmendieser Beitrag entstand, umfasst die Ana-lyse, Konzeption und Entwicklung dezen-traler, auf offenen Standards basierenderVerhandlungsfunktionalitaten [Mult03].Ziel ist auch eine Kopplung dieser Funk-tionalitaten mit elektronischen Marktplat-zen und damit ein Abbau der vorhandenenFunktionalitatsdefizite. Das Konzept derWebservices [FrWe02; Glas00; Kreg01;Stal02] verspricht die dazu notwendige Of-fenheit und Flexibilitat. Die entwickeltenAnwendungskomponenten sind, wenn-gleich an elektronische Marktplatze kop-pelbar, von diesen funktional und adminis-trativ unabhangig. Sie ermoglichen einem

Netzwerk gleichberechtigter Marktpartnerdie Aufnahme bilateraler elektronischerVerhandlungen spontan und ohne Ruck-griff auf eine zentrale Instanz. Dieser An-satz entspricht den Zielsetzungen von Peer-to-Peer-Anwendungen [Bark01; Oram 01;ScFi02]. Durch die entwickelten Anwen-dungskomponenten soll eine Beschleuni-gung von Verhandlungsprozessen beigleichzeitiger erhohter Qualitat der aus-getauschten Informationen erreicht wer-den. Dazu ist die enge Integration der Ver-handlungslosung in die ubergeordneteInformationskette – unter Einschluss derinternen operativen Systeme der beteiligtenUnternehmen – unerlasslich. Sicherheits-aspekte sind ebenfalls zu berucksichtigen;sie wurden bereits an anderer Stelle dis-kutiert [ReAm02] und werden daher indiesem Beitrag nicht weiter beleuchtet.

In diesem Beitrag berichten wir Aspekteder Konzeption und prototypischen Reali-sierung von Webservices zur Integrationvon dezentralen Verhandlungslosungenund elektronischen Marktplatzen. Auf-grund des integrativen und interorganisa-tionalen Charakters elektronischer Ver-handlungen ist der adaquate Umgang mitsyntaktischen und semantischen Bezugs-systemen (in der Regel in Form von Pro-zess- oder Dokumentenstandards) ein ent-scheidender Erfolgsfaktor fur Entwicklungund Einsatz entsprechender Systeme. Umdie innerhalb der Informationskette haufigauftretende semantische Vielfalt (semanticvariety), d. h. die Parallelverwendung un-terschiedlicher semantischer Bezugssyste-me, handhaben zu konnen, wird im hierberichteten Zusammenhang stellenweiseauf das Resource Description Framework

WIRTSCHAFTSINFORMATIK 45 (2003) 3, S. 293–306

Die Autoren

Michael RebstockMichael Lipp

Prof. Dr. rer. pol. Michael Rebstock,Michael Lipp,Institut fur Wirtschafts- undVerwaltungsinformatik,Universitat Koblenz-Landau,Universitatsstraße 1,D-56070 Koblenz,E-Mail: [email protected],E-Mail: [email protected]

Webservices zur Integrationinteraktiver elektronischerVerhandlungenin elektronische Marktplatze

WI – Schwerpunktaufsatz

(RDF) [LaSw99] als Metasprache zuruck-gegriffen.

Der Beitrag gliedert sich in funf Teile. ImAnschluss an die Einleitung werden zu-nachst die konzeptionellen und tech-nischen Grundlagen hinsichtlich elektro-nischer Markte und Verhandlungen,Webservices und RDF erlautert. Auch dieden Anwendungskomponenten zugrundeliegende Gesamtarchitektur wird vor-gestellt. Im anschließenden Kapitel wirdzunachst das Transaktionsszenario der Ser-vices vorgestellt und ein �berblick uberderen Zusammenspiel gegeben, dann wer-den die einzelnen Dienste erlautert. Auf-bauend darauf werden die ubermitteltenDokumente konzipiert und beschrieben.Eine Diskussion unserer Ergebnisse undbenachbarter Arbeiten sowie ein Ausblickschließen den Beitrag ab.

2 Grundlagen

2.1 Elektronische Verhandlungenund elektronische Markte

Eine elektronische Verhandlung ist ein aufgegenseitigem Informationsaustausch be-ruhender Prozess der Entscheidungsfin-dung zwischen zwei oder mehr Parteien,der in der Regel eine Einigung (in Form ei-nes Kontraktes) zum Ziel hat [ahnlichDaSm83; GuMa98; Zarn99]. Der Prozessbesteht aus einer Abgabe von Geboten undetwaigen Gegengeboten, so lange, bis dieEinigung erzielt oder die Verhandlung vonmindestens einem der beteiligten Partnerabgebrochen wurde. Die Zahl der am Ver-handlungsprozess beteiligten Partner sowiedie logischen und temporalen Prozess-strukturen hangen vom gewahlten Ver-handlungsprotokoll ab.

Ein zentrales Element der elektronischenGeschaftsabwicklung stellen elektronischeMarkte dar. Ein elektronischer Markt isteine auf elektronischen Kommunikations-diensten beruhende Anwendung, die einemarktmaßige Koordination wirtschaftlicherLeistungen ermoglicht [ahnlich Schm93].Dabei unterstutzen elektronische Markteim engeren Sinne alle, elektronische Markteim weiteren Sinne auch nur einzelne Pha-sen einer Markttransaktion [Schm93].Meist werden in diesem Zusammenhangvier [Schm99] bzw. funf [Rebs00] Phasenunterschieden:

& Wissens- bzw. Informationsphase: Dientder Akquisition des Wissens, das fur dieDurchfuhrung einer Transaktion not-wendig ist.

& Absichts- bzw. Entscheidungsphase:Fuhrt zum Entschluss, ob und in wel-cher Weise ein Gebot gegenuber Markt-partnern abgegeben wird.

& Vereinbarungsphase: Zielt auf die Eini-gung der Marktpartner und den Ab-schluss eines Kontrakts ab.

& Abwicklungsphase: Beinhaltet die Er-bringung der im Kontrakt beschriebe-nen Leistungen.

& Betreuungsphase: Umfasst Betreuungs-und Serviceleistungen nach Erbringungder im Kontrakt beschriebenen Leistun-gen.

Elektronische Verhandlungen sind damitmogliche Prozesse innerhalb der Verein-barungsphase einer elektronischen Markt-transaktion. Elektronische Markttrans-aktionen konnen zahlreiche weitere Akti-vitaten wie etwa Praferenzstrukturierungund -reprasentation, Nutzenanalyse undNutzenvergleich umfassen, die hier nichtGegenstand sind.

Elektronische Verhandlungen konnen nachden Merkmalen Protokollkategorie, Attri-butanzahl, Automatisierungsgrad, Positi-onsanzahl, Verhandlungsanzahl und Me-diationstyp kategorisiert werden [Rebs01c].Zur Charakterisierung der hier vorgestell-ten Anwendungskomponenten gegenuberanderen Ansatzen sind insbesondere dieersten beiden Merkmale relevant.

Die Protokollkategorie bezeichnet die Zahlder an der Verhandlung beteiligten Markt-partner auf der Anbieter- und auf der Ab-nehmerseite: Bilaterale Verhandlungen fin-den zwischen einem Anbieter und einemNachfrager statt. (Eine bilaterale elektro-nische Verhandlung ist dabei nicht zu kon-fundieren mit einem bilateral-monopolisti-schen elektronischen Markt, auf dem sichinsgesamt nur zwei Marktteilnehmer befin-den). Einseitig multilaterale Verhandlungenfinden zwischen einem Marktpartner aufder Angebotsseite und mehreren Partnernauf der Nachfrageseite (in diesem Fall han-delt es sich um eine Auktion) oder zwi-schen einem Marktpartner auf der Nach-frageseite und mehreren Partnern auf derAngebotsseite (in diesem Fall handelt essich um eine umgekehrte Auktion oderAusschreibung) statt. Beidseitig multilate-rale Verhandlungen erfolgen zwischenmehreren Partnern auf beiden Seiten; es

wird von Borsen oder doppelten Auktio-nen gesprochen [Rebs01c]. TraditionelleVerhandlungen mit Geschaftspartnern fin-den in aller Regel bilateral statt (was natur-lich parallele bilaterale Verhandlungen mitmehreren Geschaftspartnern nicht aus-schließt). Auch unser Ansatz bezieht sichauf bilaterale Verhandlungen.

Die Attributanzahl bezeichnet die Kardi-nalitat der elektronisch verhandelten Attri-bute eines Kontrakts und seiner Einzel-positionen. Bei einattributiven Verhand-lungen ist in der Regel der Preis dasalleinig verhandelte Attribut. Betrachtetman dagegen Prozesse der traditionellen,nicht-elektronischen Geschaftsabwicklung,so fallt auf, dass dort haufig eine Vielzahlvon Kontraktattributen wie Produktspezi-fikationen, Qualitaten, Mengen, Preise,Liefer-, Zahlungs- und Gewahrleistungs-bedingungen ausgehandelt werden. DieZusammensetzung der Attribute kann da-bei von Kontrakt zu Kontrakt variieren.Ein Projektziel im hier berichteten Zusam-menhang ist es, dieser multiattributivenund veranderlichen Natur von Verhand-lungsinhalten auch bei deren elektronischerAbbildung Rechnung zu tragen.

Beispielhafte Einsatzgebiete der im Rah-men des Projekts entwickelten Anwen-dungskomponenten sind damit komplexe-re Verhandlungen uber:

& Konfigurierbare Produkte mit variablenAttributen, wie etwa in der IT- (Infor-mationstechnologie-) oder der Auto-mobilbranche,

& Semistrukturierte Produkte, wie Sub-stanzen mit spezifischen Qualitatsgra-den in der Prozess- oder der Nahrungs-und Genussmittelindustrie,

& Rahmenvertrage, wie etwa in der Auto-mobil- oder Prozessindustrie sowie imHandel,

& Dienstleistungsvertrage aller Art, auchBau- oder Ingenieurleistungen,

& Vertrage uber kombinierte Guter- undDienstleistungsbundel, wie etwa in derIT-Branche (Hardware, Software, Ser-vices) oder im Maschinen- und Anlagen-bau.

2.2 Webservices

Webservice-Technologien als neuartige In-tegrationslosungen sind eine logische Folgedes in den letzten Jahren konsequent voran-


294 Michael Rebstock, Michael Lipp

getriebenen Internet-Standardisierungspro-zesses, der im Wesentlichen durch großeSoftwareunternehmen (wie Microsoft,IBM, Sun, Oracle u. a.) und das WorldWide Web Consortium [W3C02a] gestaltetwird. Ein Webservice ist im weitesten Sinneein Datendienst, der einem Service Reques-ter von einem Service Provider offeriertwird. Innerhalb der Webservice-Architek-tur erfolgt dabei die Vermittlung in der Re-gel uber einen Service Broker. Ein Webser-vice nutzt die Basistechnologien

& XML (Extensible Markup Language)[W3C02b],

& SOAP (Simple Object Access Protocol)[W3C02d],

& WSDL (Web Services Description Lan-guage) [W3C02c; ChCu01] und

& UDDI (Universal Description, Discov-ery and Integration) [UDDI02],

sowie als Transportinfrastruktur die Inter-netdienste HTTP (Hypertext Transfer Pro-tocol), SMTP (Simple Mail Transfer Pro-tocol) oder FTP (File Transfer Protocol)uber TCP/IP (Transmission Control Pro-tocol/Internet Protocol). Die Kurzformel„Webservices gleich XML plus HTTP plusSOAP plus WSDL plus UDDI“ [Vasu01]zeigt auf, dass diese Dienste in Bezug aufNetzinfrastruktur, Transportprotokoll undDatenaustauschformat auf vorhandeneTechnologien zuruckgreifen und eine evo-lutionare Weiterentwicklung derselben dar-stellen. Einer der Hauptaspekte der Ent-wicklung von Webservices ist dabei dieIntegration heterogener Anwendungsland-schaften [Stal02]. Obwohl das Forschungs-und Entwicklungsfeld der Webservices sicherst stabilisiert, kristallisieren sich einigeAspekte heraus, die allgemein als Merk-male von Webservices verstanden werden[FrWe02; Glas00; Kreg01]:

& Strukturiert beschrieben und interpre-tierbar: Die vollstandige Beschreibungeines Dienstes, seiner Autoren und derbenutzten Schnittstellen liefert alle In-formationen, die fur seinen Aufruf er-forderlich sind.

& Modular und interoperabel: Webserviceserfullen eine bestimmte Aufgabe bzw.Aufgabenmenge und sind eigenstandigoder in Kombination mit anderen Web-services einsetzbar, um auch komplexereTransaktionen auszufuhren. Mehrereeinzelne Webservices lassen sich also zueinem neuen Dienst zusammensetzen.Dieser tritt uber seine Schnittstellende-finition nach außen hin wiederum alseigenstandiger Webservice auf. (Die Da-

tenkommunikation uber Netzwerke legtdabei aufgrund des großen Kom-munikationsaufwands ein grobgranula-res Applikationsdesign, also großere In-formationspakete je Methodenaufruf,nahe).

& Plattformunabhangig: Aufgrund dertextbasierten Nachrichten des Aus-tauschprotokolls SOAP und der TCP/IP-basierten Transportinfrastruktur sindWebservices weitestgehend unabhangigvon der eingesetzten Hardware undSoftware.

2.3 Peer-to-Peer-Ansatz

Das wesentliche Merkmal des Peer-to-Peer-Konzepts ist eine dezentrale Struktur,die ohne Ruckgriff auf zentrale bzw. hie-rarchiegebende Instanzen funktioniert[Bark01; Oram01]. Zwischen gleichberech-tigten Knoten (Nodes) bestehen flexible,direkte Verbindungen, die unter Verwen-dung eines integrierten Registrier- und Lo-kalisierungsmechanismus beliebig auf-gebaut werden konnen. GleichberechtigtePartner (Peers) nutzen diese Infrastrukturzur Durchfuhrung dezentraler, selbst-koordinierter kollaborativer Prozesse.

In einem Peer-to-Peer-Netzwerk kann je-der Knoten Daten speichern, senden und

empfangen. Er ist damit in der Lage, so-wohl Client- als auch Serverfunktionalitatzu leisten. Im idealtypischen Fall sind alleKnoten gleichberechtigt und gleichwertig.Wenn zwei Knoten eines Netzwerkes di-rekt vernetzt sind, konnen sie in Echtzeitmiteinander interagieren. Es gibt keinezentrale Instanz, welche die Kommunikati-on verzogert oder filtert. Den Knoten einesPeer-to-Peer-Netzwerks kommt dabei Au-tonomie im Sinne der Eigenkontrolle ihrerAktivitaten zu [ScFi02].

Die Komplementaritat vonWebservice- undPeer-to-Peer-Ansatz wurde in der Literaturbereits aufgezeigt [Schn01; ScFi02]. Webser-vices sind dabei weniger ein Anwendungs-bereich von Peer-to-Peer-Technologie, alsvielmehr eine ihrer technologischen Ergan-zungs- oder Umsetzungsmoglichkeiten. DieGemeinsamkeiten der beiden Ansatze sindoffensichtlich: Beide zielen auf die verteilteBereitstellung von Diensten ab, die uber dasInternet erreichbar sind und die miteinanderkommunizieren konnen. Webservice-Tech-nologie und Peer-to-Peer-Paradigma kon-nen daher in ihrer Entwicklung wechselsei-tig voneinander profitieren: Die Implemen-tierung dezentraler Applikationsnetzwerkewird durch die Nutzung der offenen, XML-basierten Webservice-Standards hinsichtlichKomplexitat, Administrierbarkeit und Fle-xibilitat der Schnittstellen deutlich erleich-tert.


Kernpunkte fur das Management

& Ziel ist es, einem Netzwerk gleichberechtigter Marktpartner durch die Bereitstellung ge-eigneter Anwendungskomponenten die spontane Aufnahme interaktiver bilateraler elek-tronischer Verhandlungen zu ermoglichen.

& Die entwickelten Anwendungskomponenten konnen als dezentrale Erweiterungen vorlie-gender elektronischer Marktplatzanwendungen dienen und auf diese Weise das in derPraxis haufig beklagte Funktionalitatsdefizit dieser Applikationen abbauen. Sie sind je-doch auch eigenstandig einsetzbar.

& Die Webservices ubernehmen die Kommunikation zwischen den Anwendungen bzw. An-wendungskomponenten der beteiligten Parteien (Kaufer, Verkaufer, elektronischer Markt-platz und Verhandlungsanwendung).

& Innerhalb des Verhandlungsprozesses stellt die Verhandlungsanwendung den Integrati-onspunkt dar, an dem die einzelnen Webservices dynamisch zusammenlaufen.

& Zum Management der Verhandlungssemantik wird stellenweise auf RDF als Metasprachezuruckgegriffen.

Stichworte: Elektronische Verhandlungen, Webservices, Peer-to-Peer, RDF, ElektronischeMarkte, Elektronische Kataloge, Verhandlungsunterstutzungssysteme

Webservices zur Integration interaktiver elektronischer Verhandlungen 295

Bisherige Einsatzgebiete des Peer-to-Peer-Konzepts liegen in den eher technischenBereichen des Teilens von Systemressour-cen (Distributed Computing) und des Tei-lens von Daten (File Sharing). Es liegt na-he, das Peer-to-Peer-Prinzip auf das Teilenvon Anwendungen (Application Sharing)und schließlich auch auf das Teilen vonTransaktionen (Transaction Sharing) zuubertragen. Bei ausreichend weiter Defini-tion ist der Peer-to-Peer-Ansatz in diesemBereich in Form des EDI (Electronic DataInterchange) ohnehin seit langem etabliert[Merz02, 667]. Trotzdem behandeln bishernur wenige Beitrage Aspekte der Realisie-rung Peer-to-Peer-basierter elektronischerMarkttransaktionen; eine Ausnahme stelltetwa [GeBu02] dar.

Durch Kombination der Webservice-Technologie mit Peer-to-Peer-Prinzipienlassen sich Anwendungskomponenten be-darfsgenau dynamisch miteinander kop-peln, um individuelle, anwendungsuber-greifende Geschaftstransaktionen durch-zufuhren. Innerhalb der so entstehendenflexiblen Informationskette konnen kom-plette Transaktionen durch phasenspezi-fisch dynamisch verknupfte Anwendungs-komponenten abgebildet werden. DieseKonzeption liegt dem hier berichteten Pro-jektzusammenhang zugrunde. Eine elek-tronische Markttransaktion wird dabei inihren einzelnen Phasen durch unterschied-liche Anwendungskomponenten unter-stutzt. Diese Komponenten werden spon-tan, bedarfsorientiert und automatisiertmiteinander verbunden. Die realisiertenVerhandlungskomponenten stellen dabeidas integrierende dezentrale Element derbetreffenden Informationskette dar(Bild 1).

2.4 Resource DescriptionFramework

Der W3C-Entwurf Resource DescriptionFramework (RDF) [LaSw99] beschreibtein Modell fur die Definition und Verarbei-tung von Metadaten im Internet. DessenGrundlage bilden logische Aussagen(Statements), die aus einem Bezeichner(Resource), einer Eigenschaft und einemzugewiesenen Wert bestehen. Mit diesenRDF-Tripels lassen sich Aussagen uberRessourcen im Netz formulieren, die eineserverubergreifende semantische Interope-rabilitat gewahrleisten sollen [Deva00].RDF stellt damit einen der Bausteine desSemantic Web [BeHe01] dar.

RDF kann einen semantischen �berbaufur individuell definierte XML-Strukturenliefern und kann somit auch fur die Web-service-Entwicklung genutzt werden. DieBeschreibungsfahigkeiten eines WSDL-Dokuments konnen z. B. durch RDF-Metainformationen sinnvoll erweitert wer-den [Ogbu00]. Ebenso lassen sich semanti-sche Lucken in der Beschreibungausgetauschter SOAP-Nachrichten mit RDFstatt reinem XML schließen [Ogbu02].Dieser Ansatz wird im hier berichteten Zu-sammenhang genutzt.

Fur das Design von RDF-Metadaten beno-tigt man ein Vokabular, das die Benennungder RDF-Objekte und ihrer Relationen er-laubt. Die RDF-Schema-Spezifikation[BrGu02] erganzt RDF in diesem Sinneund stellt gleichzeitig ein Grundvokabularfur das Erstellen von wiederverwendbarenSchemas bereit. Ein RDF-Schema ist einDokument, das RDF-Objekte und derenmogliche Beziehungen definiert. AusKlassenhierarchien und Relationen kon-nen Taxonomien (Klassifizierungen) gebil-det werden. Die Kombination von Klassi-

fizierungen mit leistungsfahigen Schluss-regeln bilden (Web-)Ontologien [Grub92;Fens01]. Gruber definiert Ontologie indiesem Zusammenhang als „set of definiti-ons of content-specific knowledge repre-sentation primitives: classes, relations,functions, and object constants‘‘ [Grub92].Ontologien fur ein breites Spektrum vonAnwendungsdomanen (von Ausbildunguber E-Commerce bis Geologie u. v. a. m.)werden derzeit erarbeitet [Fort02].

2.5 Gesamtarchitektur derAnwendungskomponenten

Die Anwendungsarchitektur des Gesamt-projekts wird hier nur in ihren Grund-zugen beschrieben. Sie wurde an andererStelle ausfuhrlicher erlautert [Rebs01a].

Zielsetzung war eine offene Anwendungs-architektur, welche die Integration inter-organisationaler und intraorganisationalerKomponenten erlaubt. Die konzipierteGesamtarchitektur unterscheidet drei An-wendungsebenen, die (1) Meta-Verhand-lungsebene, die (2) Verhandlungsebene und(3) die Kommunikationsebene. Jede derEbenen wird durch eine der drei Haupt-komponenten der Anwendungsarchitekturreprasentiert:

& „Business Object Framework Engine‘‘:Diese Komponente unterstutzt die Ver-waltung der anwendungsspezifischenObjekt- und Dokumentstrukturen(Business Object Framework) (Ebene 1)[Rebs01b].

& „Negotiation Engine‘‘: Diese Kom-ponente unterstutzt den eigentlichenProzess interaktiver, bilateraler multi-attributiver Verhandlungen (Ebene 2)[ReTh03].

& „Communication Engine‘‘: Diese Kom-ponente versorgt die anderen beidenKomponenten mit den zur Abwicklungdes Verhandlungsprozesses notwendi-gen Kommunikationsfunktionen. Ein-gehende und ausgehende Nachrichten(Dokumente) werden verwaltet, authen-tifiziert und gegebenenfalls ver- bzw.entschlusselt. Die Komponente stellt au-ßerdem grundlegende Workflow-Funk-tionalitat zur Einbindung in ubergeord-nete, organisationsubergreifende Work-flows zur Verfugung (Ebene 3). Diesicherheitsrelevanten Aspekte sind in[ReAm02] dargestellt.


Wissens-phase

Absichts-phase

Verein-barungs-

phase

Abwick-lungs-phase

Betreu-ungs-phase

Verhandlungs-plattform

ElektronischerMarktplatz

InterneSysteme

Bild 1 Transaktionsszenario einer integrierten Informationskette


Alle drei Anwendungselemente sind alsgrobgranulare Komponenten mit standar-disierten, XML-basierten Schnittstellenkonzipiert und setzen sich wiederum ausTeilkomponenten zusammen. AndereMarktfunktionalitaten wie allgemeine Ka-talogdienste, Anbieterverzeichnisse oderZahlungsdienste werden als eigenstandigeKomponenten verstanden und sind nichtTeil dieses Architekturmodells. DieDienste, uber die wir im Rahmen diesesBeitrags berichten, sind Bestandteile derCommunication Engine.

3 Konzeptionder Webservices

3.1 Transaktionsszenario

Das hier berichtete Zusammenspiel einerMarktplatzapplikation mit einer Verhand-lungsanwendung ist eingebettet in ein Ge-samtszenario, das auch als Dynamic Busi-ness Web bezeichnet wird [Arnd02]. Diebeteiligten Akteure und Anwendungen(Verkaufer, Kaufer, elektronischer Markt-

platz, interne Systeme und Verhandlungs-losung) werden dabei zu einer integriertenund gleichzeitig flexiblen Informationsketteverknupft. Bild 2 zeigt das diesem Beitragzugrunde liegende Szenario im�berblick:

(1) Ein Unternehmen vertreibt Produkteund Dienstleistungen internetbasiert undbietet in diesem Zusammenhang verschie-dene Webservices an. Hierzu zahlen dieVeroffentlichung eines elektronischen Ka-talogs in einem standardisierten XML-Format (z. B. BMEcat [ScKe01]) und eineLieferfahigkeitsauskunft uber im WSDL-Format definierte Schnittstellen. Das Un-ternehmen prasentiert sich unter Referen-zierung der WSDL-Definitionen in einemUDDI-Repository.

(2) Anbieter konnen dem Marktplatz ihreAngebote zur Aufnahme bekannt gebenoder werden aktiv vom Marktplatz identi-fiziert. Das offentlich zugangliche UDDI-Repository liefert die entsprechendenInformationen. Der Marktplatz speichertdie Webservice-Schnittstellen (WSDL-Be-schreibungen) der ausgewahlten Unterneh-men.

(3) Diejenigen Webservices, die fur denMarktplatz interessant sind (Dienste zuKatalogdaten und Lagerbestandsdaten),werden selektiert und die notwendigenWebservice-Clients werden implementiert.Die Katalogdaten werden in die Datenbank(Hyperkatalog) des Marktplatzes impor-tiert.

(4) Ein registrierter potentieller Kauferdurchsucht den Hyperkatalog des Markt-platzes und selektiert einen Anbieter sowiedie fur ihn interessanten Produktkategorien.

Bestehende Marktplatzanwendungen bie-ten dazu eine Warenkorbfunktionalitat an,uber die ausgewahlte Produkte anschlie-ßend ohne weitere Verhandlungen gekauftwerden konnen. Das dem Forschungspro-jekt zugrunde liegende Szenario sieht dage-gen – statt der bloßen �bernahme derProdukte in einen Warenkorb – die Mog-lichkeit der interaktiven bilateralen Aus-handlung der spezifischen Attribute derTransaktion (produktbezogene, finanzielleund logistische Attribute) vor.

(5) (6) Nach Aktivieren der Verhandlungs-funktionalitat wird dazu ein Katalogauszug(ahnlich der gewahlten Produkte eines Wa-renkorbs) generiert und mittels einer Web-service-Schnittstelle zur dezentralen Ver-


UDDI

Repository

Katalogdaten

TransaktionsdatenTransaktionsdaten

Produkte suchen

Veröffentlichen

Elektronischer

Marktplatz

Web Service Interface

Verkäufer Käufer

Verhandlungs-

Plattform

Web Service Interface

Web Service Interface ERP

Rechnung

WSDLWSDL

Anbieter suchen

ERP

Bestellung

1

2

3

4

10

Externe value-added Web Services

Verhandlungspartner

7 Verhandlung

Lagerbestandsdaten

6

5

8

9

10

8

Update selek. Katalog

selektiver Katalog

Lagerbestandsdaten

11 11

Bild 2 Transaktionsszenario einer integrierten Informationskette

Marktplatz-Server

Anbieter ERP

Inventory Visibility

Service

Init Negotiation

Service

Catalog Update

Service

Client Transaction

Receipt ServiceClient Tunnel


Service

Client Catalog

Update Service

Transaction

Receipt Service

Tunnel Inventory

Visibility Service

(zusätzl. Client)

Verhandlungs-Server

Client Init

Negotiation Service

Catalog Publish

Service

Bild 3 Deployment-Diagram – Webservice-Interaktion


handlungsanwendung ubertragen. Ebensowerden die Referenzinformationen derVerhandlungspartner (Anbieter und Nach-frager) automatisch eingestellt.

(7) Die Verhandlungsanwendung wird akti-viert. Die Verhandlungsanfrage wird aufBasis der ubertragenen Daten dynamischvorkonfiguriert eingestellt. Die eigentlicheVerhandlung erfolgt nun zwischen Anbie-ter und Nachfrager ohne weiteren Ruck-griff auf eine zentrale Koordinationsinstanzunter Nutzung der dezentralen Anwen-dungskomponenten, deren eigene Dienstedurch externe Webservices erganzt werden.Bei bereits bestehenden Geschaftsbezie-hungen konnen die Verhandlungen auchunmittelbar, ohne vorherige EinschaltungdesMarktplatzes, aufgenommen werden.

(8) (9) Zur Beurteilung der laufenden Ver-handlungssituation ermittelt ein entspre-chender Webservice die aktuelle Verfugbar-keit der verhandelten Produkte. Bei

Bedarf, also auch wahrend der Verhand-lung, konnen die Beteiligten den eingestell-ten Katalogauszug uber eine weitere Web-service-Schnittstelle aktualisieren.

(10) (11) Nach erfolgreicher Verhandlungwerden die ausgehandelten Transaktions-daten mittels einer weiteren Webservice-Schnittstelle an die internen Systeme derbeteiligten Parteien ubermittelt. Bei dieseninternen Systemen handelt es sich in derRegel um ERP-Applikationen (EnterpriseResource Planning). Die internen Systemeder Verhandlungspartner verarbeiten dieTransaktionsdaten und erstellen daraus dienotwendigen internen Belege (wie etwa Be-stellungen, Auftrage, Rechnungen oderLieferavise).

Innerhalb des integrierten Verhandlungs-prozesses fungiert die Verhandlungs-anwendung als dezentraler Datenschnitt-punkt, an dem die verschiedenenWebservices dynamisch zusammenlaufen.

Designziel der hier beschriebenen Webser-vice-Entwicklung war es dabei, moglichstschmale Schnittstellen mit geringen Abhan-gigkeiten zwischen den beteiligten Appli-kationen zu konzipieren.

3.2 Diensteubersicht

Nach Analyse des Verhandlungsszenarioswurden die zur Unterstutzung notwendi-gen Dienste konzipiert. Die Kollaborationintegriert verschiedene Webservices derbeteiligten Parteien bzw. Anwendungen. Inder hier beschriebenen Version basieren dieWebservices auf RPC (Remote ProcedureCall), sind jedoch strukturgleich mit nach-richtenbasierten Webservices und warenebenfalls als solche zu realisieren. Dieswurde durch die Verwendung von Opera-tionen (Methoden) erreicht, die nur eineneinzigen String-Parameter – das zu uber-tragende XML-Dokument selbst – erfor-


Elektronischer Marktplatz

Verhandlungsplattform

Init

Negotiation

Service

Anbieter

ERP

Tunnel

Inventory

Visibility

Service

(als Service)

Catalog

Update

Service

Client

Tunnel

Inventory

Visibility

Service

Client

Catalog

Update

Service

Client

Init

Negotiation

Service

Transaction

Receipt

Service

Inventory

Visibility

Service

Client

Transaction

Receipt

Service

<SOAP-XML>

OK

</SOAP-XML>

<SOAP-XML>

Negotiation

Request

</SOAP-XML>

<SOAP-XML>

Selective

Catalog

Update

</SOAP-XML>

<SOAP-XML>

Produkt-

identifi-

kations-

nummern

</SOAP-XML>

<SOAP-XML>

Produkt-

identifi-

kations-

nummern

</SOAP-XML>

<SOAP-XML>

Lager-

bestands-

daten

</SOAP-XML>

<SOAP-RDF>

Trans-

action

Receipt

</SOAP-RDF>

<SOAP-XML>

Produkt-

identifi-

kations-

nummern

</SOAP-XML>

<SOAP-XML>

Lager-

bestands-

daten

</SOAP-XML>

<SOAP-XML>

Firmen-

Identi-

fikation

</SOAP-XML>

1

2 1 1

2 2

2

2

1

1

Tunnel

Inventory

Visibility

Service

(als Client)

Bild 4 �bersicht der ausgetauschten Webservice-Nachrichten


dern. Verwendet wurde das SOAP-Pro-tokoll in der Version 1.2 [W3C02d]; fur dieSchnittstellenbeschreibung diente dieWSDL Spezifikation 1.1 [ChCu01]. DasUML-Deployment-Diagram in Bild 3 gibteinen �berblick uber die beteiligten Kom-ponenten.

Die zwischen den konzipierten Webser-vices und den jeweiligen Webservice-Clients ausgetauschten Nachrichten zeigtBild 4. Im Folgenden gehen wir auf diewichtigsten der Dienste kurz ein.

3.3 Inventory Visibility Service

Die Anbieterorganisation bietet uber denInventory Visibility Service die Moglich-keit an, aktuelle Lagerbestandsdaten direktaus den internen (ERP-) Systemen abzuru-fen. Dieser Webservice ist der Backend-Service fur den Service Tunnel InventoryVisibility Service des elektronischen Markt-platzes. Bild 5 zeigt – beispielhaft, denn aufeine Darstellung weiterer WSDL-Beschrei-bungen wird aus Grunden des Umfangsund der �bersichtlichkeit im Folgenden

verzichtet – Auszuge aus der WSDL-Schnittstellenbeschreibung InventoryInter-face.wsdl.

3.4 Tunnel Inventory VisibilityService

Dieser Webservice ubernimmt innerhalbdes Integrationsszenarios eine Doppelrolle.Er fungiert fur das Backend des Marktplat-zes als SOAP-Client, der den InventoryVisibility Service des Anbieters aufruft.Gleichzeitig dient er als aggregierenderTunnel-Dienst fur die Aufrufe des TunnelInventory Visibility Service-Clients derVerhandlungsanwendung (Bild 6).

3.5 Init Negotiation Service

Die Initialisierungsdaten fur eine neue Ver-handlungsanfrage werden uber den InitNegotiation Service der Verhandlungs-anwendung transferiert. Das NegotiationRequest wird dabei als String-Parametervom Init Negotiation Service-Client des

Marktplatzes an die Webservice-OperationinitNegotiationRequest() ubergeben.

3.6 Catalog Update Service

Der Aktualisierungsprozess eines Katalog-auszugs der Verhandlungsanwendung wirduber den Catalog Update Service desMarktplatzes gesteuert. Der Catalog Up-date Service-Client der Verhandlungs-anwendung liest dazu die eindeutigen Pro-duktidentifikationsnummern aller Katalog-positionen aus und ubergibt sie an dieWebservice-Operation UpdateSelectiveCa-talog(). Anhand der Ident-Nummern gene-riert das Backend des Marktplatzes einenaktuellen Katalogauszug und gibt dasXML-Dokument Selective Catalog Updatevia Webservice als String-Parameter an dieVerhandlungsanwendung zuruck.

3.7 Transaction Receipt Service

Die Transaktionsdaten einer erfolgreich ab-geschlossenen Verhandlung werden den in-


<binding name="InventoryVisibilityServiceSoapBinding" type="tns:Inventory"><soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="checkInventory">

<soap:operationsoapAction="http://localhost:6080/supplier/services/InventoryVisibilityService"/>

<input name="checkInventoryRequest"><soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:checkInventory" use="encoded"/></input><output name="checkInventoryResponse">

<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="urn:checkInventory" use="encoded"/>

</output></operation>...

</binding>

<service name="InventoryVisibilityService"><documentation>Inventory Visibility Service of Dacopa GmbH Darmstadt / Germany.</documentation><port binding="tns:InventoryVisibilityServiceSoapBinding"

name="InventoryVisibilityService"><soap:address location="http://localhost:6080/supplier/services/

InventoryVisibilityService"/></port>

</service>...

Bild 5 WSDL-Schnittstellenbeschreibung InventoryInterface.wsdl


ternen Anwendungen der beteiligten Par-teien uber den Transaction Receipt Serviceder Verhandlungsanwendung bereitgestellt.Um eine externe, automatisierte Datenver-arbeitung zu ermoglichen, ist eine semanti-sche Spezifikation des Webservice erfor-derlich. Hierzu wurde auf RDF-Konstruk-te zuruckgegriffen. Die Struktur desDokuments wird unter Verwendung einesRDF-Schemas mit Metainformationen ver-sehen, die eine semantisch eindeutige Be-schreibung der SOAP-Nachricht gewahr-leisten sollen. Transaction Receipt wirddaher im Unterschied zu NegotiationRequest und Selective Catalog Updatenicht als reine XML-Nachricht, sondernals RDF-XML-Serialisierung ubertragen[Ogbu02].

4 Datenmodellierung

In diesem Kapitel werden die von den be-schriebenen Webservices ausgetauschtenXML-Dokumente vorgestellt. Es handeltsich um die Dokumente Negotiation Re-quest, Selective Catalog Update und Trans-action Receipt.

Die primaren Ziele des Designs der XML-Strukturen waren Einfachheit, Flexibilitatund Eindeutigkeit. Alle drei Dokumenteweisen dieselbe Grundstruktur auf, beste-hend aus einem qualifizierenden Wurzel-element, einem Kopfelement und einer Po-sitionsliste. Aus Grunden der �bersicht-lichkeit und Performanz wurden dieStrukturen moglichst flach angelegt. Flexi-bilitat ergibt sich aus der Verwendung gene-rischer Datenstrukturen, die einen pro-

dukt- und branchenunabhangigen Einsatzermoglichen. Die marktplatzseitige Schnitt-stelle der Verhandlungsanwendung ist so-mit grundsatzlich auf das Ankoppeln ver-schiedener elektronischer Marktanwen-dungen ausgelegt. Eindeutigkeit beziehtsich neben der Beschreibung der erlaubtenElementdatentypen mittels XML-Schemavor allem auf die Semantik des Dokuments.Bei der Benennung einzelner Elementewurde teilweise auf die ebXML-Core-Components-Spezifikation [ebXM01] zu-ruckgegriffen. Die semantische Haupt-komponente bildet jedoch ein eigens ent-wickeltes RDF-Schema.

4.1 Negotiation RDF Schema

Das Negotiation RDF Schema definiert ei-ne Taxonomie (Klassifizierung) von Ob-jekten innerhalb der ausgetauschten XML-Nachrichten, die von den einzelnenElementen (Tags) der Dokumente repra-sentiert werden. An dieser Stelle wird dieBeschreibung des Transaction Receipt be-trachtet. In einem Szenario, das die Anbin-dung verschiedener elektronischer Markt-platze an die Verhandlungsanwendungvorsieht, konnte das Negotiation RDFSchema jedoch auch fur das NegotiationRequest und das Selective Catalog Updateals semantische Basis verwendet werden.

Mittels des Grundvokabulars der RDF-Schema-Spezifikation [BrGu02] lassen sichRelationen zwischen Objekten und daraufaufbauende Hierarchien beschreiben. DasNegotiation RDF Schema verwendet aus-schließlich die grundlegenden RDF-Klas-

sen resource, class und propertysowie die RDF-Properties subClassOf,subPropertyOf, comment, label,domain, range und seeAlso. Die Defi-nition weiterer, individueller Beschrei-bungsvokabeln ist mit RDF-Schema mog-lich. Die Metainformationen uber dasSchema sind unter Verwendung der Ele-mente des Dublin Core [Dubl99] in RDFspezifiziert. Jedes Objekt des Schemas erhaltfur die eindeutige Referenzierung ein ID-Attribut, auf das Elemente von RDF-XML-Dokumenten verweisen konnen. Zudemwirdmit einem label und einem commentdie Bedeutung eines Objekts expliziert und,falls angebracht, in mehreren Sprachen be-schrieben. Mittels range und domain las-sen sich die Eigenschaften bestimmten Klas-sen zuordnen. Bild 7 zeigt Auszuge aus demNegotiation RDF Schema.

Die auf diese Weise entstehende Web-On-tologie ermoglicht es RDF-Schema-Pro-zessoren, ein Transaction Receipt inhaltlichzu analysieren. Die im Schema formulier-ten Relationen und Hierarchien liefern In-formationen, die als Grundlage fur ein se-mantisch korrektes Aufeinanderabbildenvon Objekten („Mapping‘‘) zweier Appli-kationen herangezogen werden konnen.Ein ERP-System wird somit in die Lageversetzt, die durch das Negotiation RDFSchema definierte Beschreibung einesTransaction Receipt zu interpretieren undin eine eigene interne Struktur zu uberset-zen. Die fur die logische Analyse und an-schließende automatisierte Objektzuord-nung notwendigen Werkzeuge befindensich noch in der Planungs- oder Realisie-rungsphase. Im Rahmen des Projektes wirdderzeit gepruft, ob ein RDF-Schema-Pro-zessor selbst entwickelt werden soll. Dadas frei lesbare Negotiation RDF Schemajedoch auch manuell auswertbar ist und sosemantische Unklarheiten beseitigen hilft,sind Vorteile gegenuber einer Verwendungvon reinem XML als Austauschformat be-reits heute vorhanden.

4.2 Negotiation Request

Das UML-Klassendiagramm in Bild 8zeigt den grundsatzlichen Aufbau desNegotiation-Request-Dokuments, das uberden Init Negotiation Service der Verhand-lungsanwendung ubergeben wird. EinKopfelement <header> enthalt Informa-tionen zu den beteiligten Parteien und wei-tere Informationen zum Management der


Marktplatz-ServerVerhandlungs-Server

Tunnel Inventory

Visibility Service

(zusätzl. Client)

Anbieter ERP n-1


Service n-1

Anbieter ERP 1


Service 1

Anbieter ERP n


Service n

Client Tunnel


Service

Bild 6 Komposition verschiedener Inventory Visibility Services


Verhandlung. Die verhandelten Positionen<item> sind einem Katalogauszug<item_list> zugeordnet. Eine Positionwird durch eine beliebige Menge Attribute<item_attribute> beschrieben. (DieUML-Klassendiagramme lassen sich struk-turgleich in XML-Dokumente ubersetzen;auf eine Darstellung des XML-Codes wur-de fur dieses und das folgende Dokumentwiederum aus Grunden des Umfangs ver-zichtet).

4.3 Selective Catalog Update

Wie aus Bild 9 ersichtlich ist, stellt das Se-lective Catalog Update eine Teilmenge desNegotiation Request dar, bestehend wie-derum aus Kopfinformationen <header>und einer Positionsliste <item_list>,die den zu aktualisierenden Katalogauszugenthalt.

4.4 Transaction Receipt

Das Transaction-Receipt-Dokument repra-sentiert als RDF-Struktur den Kontrakt,d. h. das Ergebnis einer erfolgreich abge-schlossenen Verhandlung (Bild 10).

Wie oben beschrieben, bildet das Trans-action-Receipt-Dokument die Ausgangs-basis fur die Generierung weiterer Belege


...<rdf:RDF xml:lang="en"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://localhost:5080/multineg/xml/mn_rdf_schema/"><dc:title xml:lang="en">MultiNeg Element Set namespace</dc:title><dc:publisher xml:lang="en">MultiNeg Ltd.</dc:publisher><dc:description xml:lang="en">MultiNeg Element Set namespace provides URIs for the

MultiNeg Transaction Receipt, Selective Catalog Update and Negotiation RequestEntries declared using RDF Schema language to support RDF applications.

</dc:description><dc:language xml:lang="en">English</dc:language><dc:source rdf:resource="http://localhost:5080/multineg/xml/mn_rdf_schema/"/>

</rdf:Description>...

<rdf:Description ID="transaction_receipt"><rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property" /><rdfs:label xml:lang="en">transaction_receipt</rdfs:label>

<rdfs:comment>Root tag of a transaction receipt which is the resultof a successful negotiation.</rdfs:comment>

<rdfs:isDefinedBy rdf:resource="" /></rdf:Description>

...<rdfs:Class rdf:ID="parties">

<rdfs:label xml:lang="en">parties</rdfs:label><rdfs:comment>Collection of all participants of a transaction or

transaction to be.</rdfs:comment><rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>

</rdfs:Class>...

<rdfs:Class rdf:ID="supplier_party"><rdfs:label xml:lang="en">supplier_party</rdfs:label><rdfs:comment>Supplier who offers products or services to a buyer party.</rdfs:comment><rdfs:subClassOf rdf:resource="#parties"/>

</rdfs:Class>...

<rdfs:Class rdf:ID="item_list"><rdfs:label xml:lang="en">item_list</rdfs:label><rdfs:comment>List of products or services negotiated.</rdfs:comment><rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>

</rdfs:Class>

<rdfs:Class rdf:ID="item"><rdfs:label xml:lang="en">item</rdfs:label><rdfs:comment>Product or service negotiated.</rdfs:comment><rdfs:subClassOf rdf:resource="#item_list"/>

</rdfs:Class>...

Bild 7 Negotiation RDF Schema


in internen Systemen. Hierzu notwendigeReferenzinformationen sind im <trans-action_receipt_info>-Element ent-halten. Allgemeine Verhandlungsattribute(z. B. Versicherung, Transportvereinbarun-gen etc.) werden innerhalb der<general_attribute_list> be-schrieben. Den rechtlichen Status einesKaufvertrages erhalt das Dokument durchdie elektronischen Signaturen der beidenVerhandlungspartner, die in den Elementen<signature_supplier> bzw.<signature_buyer> enthalten sind.Bild 11 zeigt Ausschnitte aus einer Bei-spielauspragung des Transaction-Receipt-Dokuments.

5 Diskussion und Ausblick

An dieser Stelle resumieren wir unsere Er-gebnisse und stellen unseren Ansatz in Re-

lation zu anderen Arbeiten. Wir habenAspekte der Konzeption und prototypi-schen Realisierung der Kommunikations-dienste einer Anwendung zur Unterstut-zung interaktiver elektronischer Verhand-lungen berichtet. Die konzipiertenWebservices erlauben es einem Netzwerkgleichberechtigter Marktpartner, bilateraleelektronische Verhandlungen spontan auf-zunehmen. Die entwickelten Anwen-dungskomponenten zur Unterstutzungelektronischer Verhandlungen konnen alsfunktionale Erweiterung elektronischerMarkte dienen, sind jedoch konzeptionellund administrativ von diesen unabhangigund ebenso ohne diese nutzbar. Webser-vices ubernehmen die Kommunikationzwischen den einzelnen Anwendungenoder Anwendungskomponenten der betei-ligten Parteien. Innerhalb des integriertenVerhandlungsprozesses fungiert die Ver-handlungslosung als Datenschnittpunkt, an

dem die Informationsflusse der einzelnenWebservices dynamisch zusammenlaufen.

Der im Rahmen des Projekts MultiNegentwickelte Prototyp wurde in seinenKernelementen implementiert. Der Pro-jektverlauf zeigt bereits deutlich, dass dieWebservice-Integration von Anwendungenin einem schlanken Entwicklungsprozessmoglich ist. Das erzielte Ergebnis stellt ei-nen Beweis fur die Machtigkeit des Web-service-Paradigmas in Verbindung mitPeer-to-Peer-Anwendungsprinzipien imBereich elektronischer Markttransaktionendar. Die nachsten Schritte beinhalten dieEntwicklung von in der Gesamtarchitekturbereits vorgesehenen, weiteren Webser-vices. Die Implementierung der Webser-vices unter Nutzung von RDF hat auch dieMachtigkeit dieses Konzepts und den Nut-zen seiner praktischen Anwendung ge-zeigt. Als großer Aufgabenbereich beste-hen bleibt die Entwicklung von Verfahrenzur automatisierten Interpretation der aufRDF beruhenden Dokumente.

Eine Abgrenzung zu anderen Ansatzenlasst sich aus der Zielsetzung des Gesamt-projekts ableiten. Ziel unserer Entwicklungsind (1) dezentrale Anwendungskom-ponenten zur (2) elektronischen Unterstut-zung (3) bilateraler (4) multiattributiverVerhandlungen in einem (5) interorganisa-tionalen Kontext, in dem es die verschiede-nen beteiligten Anwendungen zu integrie-ren gilt.

(1) Wie bereits erwahnt, sind dezentraleAnsatze zur elektronisch unterstutztenKoordination von Markttransaktionen bis-her die Ausnahme [GeBu02]. Die meistenEntwicklungsprojekte im Forschungs- wieim kommerziellen Bereich konzipierenund realisieren zentrale Anwendungen.Die Projekterfahrungen bestatigen, dasseine Kombination des Peer-to-Peer- unddes Webservices-Ansatzes fur die Realisie-rung dezentraler Komponenten zur Unter-stutzung elektronischer Markttransaktio-nen geeignet ist.

(2) Ziel im berichteten Zusammenhang istnicht die Vollautomatisierung von Ver-handlungsvorgangen, sondern deren elekt-ronische Unterstutzung. Wahrend durch-aus einzelne Teilaufgaben automatisiertwerden konnen, wird das Verhandlungs-ergebnis durch elektronisch gestutzte,strukturierte Interaktion menschlicher Ak-teure ermittelt. Eine uberwiegende Zahl


negotiation_request

header

negotiation_request_info

item_list

parties

intermediate_party

supplier_party

buyer_party

item

1

1

1..*

1

1

1

1

1 1

11

1

1

1

item_attributes

0..1

1

Bild 8 Class-Diagram Negotiation Request

selective_catalog

header item_list

item

1

1

1..*

1

1

1

1

1

selective_catalog_info

item_attributes

0..1

1

Bild 9 Class-Diagram Selective Catalog Update


von Forschungsprojekten zu elektro-nischen Verhandlungen stellt demgegen-uber die vollstandige Automatisierung desVerhandlungsvorgangs in ihren Mittel-punkt; einen �berblick dazu gibt [Pete00].Diese Projekte konzipieren und entwickelngroßtenteils agentenbasierte Systeme[Kirn01] zur automatisierten Durchfuh-rung von Auktionen; so etwa [BeRo01;CaOl01; ChLe99; ChDr97; ItFu01]. Weni-ge, nicht auf Vollautomatisierung abzielen-de Ansatze mit unterschiedlichem Hinter-grund finden sich dagegen bei [BeKe00;KeNo97; Kers98; ScQu01]. Die Frage, inwelchem Umfang die vollstandige Auto-matisierung von Verhandlungsvorgangenmoglich und sinnvoll ist, wird nach wie vorkontrovers diskutiert [BeSe99; KeNo99;PrCo01], soll aber an dieser Stelle nichtweiter thematisiert werden.

(3) Die Mehrzahl der Ansatze zu elektro-nischen Verhandlungen befasst sich mit

einseitig oder beidseitig multilateralen Ver-handlungen, d. h. Auktionen oder Borsen[etwa BeRo01; BiSe98; CoTs98; ItFu01;TeWa99]. Einige der bekanntesten Anwen-dungen der neunziger Jahre waren Kasbah[ChMa96] und AuctionBot [WuWe98].Kommerziell entwickelte Verhandlungs-anwendungen decken meist lediglichnicht- oder teilautomatisierte Auktionen(inklusive umgekehrter Auktionen) ab[etwa SAP02; Orac02]. Bilaterale Verhand-lungen werden dagegen seltener analysiertund implementiert; Ausnahmen sind etwa[deRa01; KeNo97; Kers98; ScQu01].

(4) Die im Unternehmensbereich anfallen-den Beschaffungsentscheidungen lassensich in den meisten Branchen nicht auf rei-ne Preisfragen reduzieren. Dies bedeutet,dass elektronische Anwendungen zur Un-terstutzung dieser Verhandlungen die Ver-waltung multipler Attribute erlauben mus-sen. Solche multiattributive Verhandlungen

werden bisher selten untersucht; Ausnah-men sind etwa [BaLo01; BiKl00; TeKu02].Um eine moglichst breite Anwendbarkeitder Entwicklungen zu erzielen, gilt esauch, generische Kontraktstrukturen zuentwickeln, die in verschiedenen Branchenund von unterschiedlichen Unternehmens-typen nutzbar sind. Diese Zielsetzung un-terscheidet den hier berichteten Ansatzvon der Großzahl der vorliegenden Kon-zepte, die in der Regel nur auf eine Brancheoder einen Anwendungsfall hin zuge-schnitten sind; so etwa [AdAl00; CoTs98;vaRi98; TeKu02].

(5) Der interorganisationale Kontext elekt-ronischer Verhandlungen weist rechtliche,organisatorische und technische Aspekteauf, die von den wenigsten Beitragen bisherbefriedigend berucksichtigt werden. Infor-mationen, die von elektronischen Markt-transaktionen benotigt oder von diesen er-zeugt werden, werden im Unternehmens-


transaction_receipt

header

transaction_receipt_info

item_list

parties

intermediate_party

supplier_party

buyer_party

item

1

1

1..*

1

1

1

1

1 1

11

1

1

1

RDF

Description

resource: anyURI

ID: string

ID: string

ID: string

general_attribute_list

comment

supplier_trade_conditionsID: string

ID: string

ID: string

ID: string

ID: string

ID: string

1

ID: string

ID: string

ID: string

0..1

0..1

1

1

1

11

item_attributes

ID: string

0..1

1

Bild 10 Class-Diagram Transaction Receipt


bereich von einer Anzahl weiterer Anwen-dungen gespeichert und weiterverarbeitetund sind damit an diese zu ubermitteln.Dies betrifft neben elektronischen Markt-platzen und Katalogen insbesondere inter-ne betriebswirtschaftliche Anwendungs-systeme, d. h. in der Regel ERP-Systeme.In technischer Hinsicht zielen zwar die un-ter dem Begriff Enterprise Application In-tegration (EAI) bekannt gewordenen Kon-zepte auf eine Integration der Backend-Systeme von Unternehmen ab. UnsereAusfuhrungen zu Bild 1 haben jedoch ge-zeigt, dass eine wirklich integrierte Infor-mationskette deutlich komplexer seinkann. Eine „flexible Formalisierung‘‘ von

Nachrichten erscheint in diesem Zusam-menhang notwendig, um die Integrationvon heterogenen Anwendungen erreichenzu konnen. Dieser Anforderung lasst sichmit der beschriebenen Anwendung vonXML und RDF unter gleichzeitiger Zu-grundelegung von Standards wie ebXML[Elec02] weitgehend entsprechen. Die An-passbarkeit von Prozessen und Dokument-strukturen bleibt aber notwendig, wennAnforderungen aus spezifischen Anwen-dungssituationen, Branchen oder Unter-nehmensgroßen zu berucksichtigen sind.Unser Ansatz lost das Dilemma zwischenFlexibilisierung und Formalisierung eingutes Stuck weit auf, indem er generische

Prozess- und Dokumentstrukturen vor-sieht, die in einer spontanen dezentralenKollaboration auf unterschiedliche Kon-textanforderungen eingestellt werden kon-nen.

Literatur

[AdAl00] Addis, Matthew; Allen, P.; Surridge, M.:Negotiating for Software Services. In: Tjoa,A. M. et al. (Hrsg.): Proceedings of the 11th In-ternational Workshop on Database and ExpertSystems Applications. IEEE Computer Society,Los Alamitos 2000, S. 1039–1043.


...<rdf:RDF encodingStyle="http://rdfinference.org/rdfws/soap-encoding"xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns:mn="http://localhost:5080/multineg/xml/mn_rdf_schema#"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemalocation="http://localhost:5080/multineg/xml/transaction_receipt.xsd"><rdf:Description rdf:resource="http://localhost:5080/multineg/xml/mn_rdf_schema#">

<mn:transaction_receipt rdf:ID="transaction_receipt">...

<mn:transaction_receipt_id rdf:ID="transaction_receipt_id">6</mn:transaction_receipt_id><mn:language rdf:ID="language">EN</mn:language><mn:transaction_theme rdf:ID="transaction_theme">

Laptops and Serverhardware</mn:transaction_theme><mn:price_amount_total rdf:ID="price_ total">2,682.99</mn:price_total><mn:currency rdf:ID="currency">USD</mn:currency>

</mn:transaction_receipt_info><mn:parties rdf:ID="parties">

...<mn:signature_supplier>signature of supplier party</mn:signature_supplier>...<mn:signature_buyer>signature of buyer party</mn:signature_buyer>

...</mn:header><mn:general_attribute_list rdf:ID="general_attribute_list"><mn:general_attribute rdf:ID="generalAttribute">

<mn:general_attribute_name rdf:ID="general_attribute_name">Incoterms</mn:general_attribute_name>

<mn:general_attribute_value rdf:ID="general_attribute_value">FOB New York</mn:general_attribute_value>

...<mn:item rdf:ID="item">...<mn:item_attributes rdf:resource="item_attributes">

<mn:attribute_name rdf:resource="attribute_name">Colour</mn:attribute_name><mn:attribute_value rdf:resource="attribute_value">black</mn:attribute_value><mn:attribute_name rdf:resource="attribute_name">Warranty</mn:attribute_name><mn:attribute_value rdf:resource="attribute_value">1 yr</mn:attribute_value>

...<mn:item rdf:resource="item">

...

Bild 11 Beispiel Transaction Receipt


[Arnd02] Arndt, T.: Erfolgreich auf B2B-Markplat-zen. Galileo Press, Bonn 2002.

[BaLo01] Barbuceanu, Mihai; Lo, W.-K.: Multi-at-tribute Utility Theoretic Negotiation for Elec-tronic Commerce. In: Dignum, F. et al. (Hrsg.):Agent-Mediated Electronic Commerce III. Cur-rent Issues in Agent-Based Electronic Com-merce Systems (LNCS Vol. 2003). Springer, Ber-lin 2001, S. 15–30.

[Bark01] Barkai, David: Peer-to-Peer Computing.Technologies for Sharing and Collaboration onthe Net. Intel Press, Santa Clara 2001.

[BeSe99] Beam, C.; Segev, A.; Bichler, M. et al.: OnNegotiations and Deal Making in ElectronicMarkets. In: Information Systems Frontier 1(1999) 3, S. 241– 258.

[BeRo01] Bejar, Javier; Rodrıguez-Aguilar, JuanA.: To Bid or Not To Bid – Agent Strategies inElectronic Auction Games. In: Dignum, Franket al. (Hrsg.): Agent-Mediated Electronic Com-merce III. Current Issues in Agent-Based Elec-tronic Commerce Systems (LNCS Vol. 2003).Springer, Berlin 2001, S. 173–191.

[BeKe00] Benyoucef, Morad; Keller, Rudolf K.: AConceptual Architecture for a Combined Nego-tiation Support System. In: Tjoa, A. M. et al.(Hrsg.): Proceedings of the 11th InternationalWorkshop on Database and Expert Systems Ap-plications. IEEE Computer Society, Los Alami-tos, CA 2000, S. 1015–1019.

[BeHe01] Berners-Lee, Tim; Hendler, J.; Lassi-la, O.: The Semantic Web. In: Scientific Ameri-can, May 2001.

[BiKl00] Bichler, Martin; Klimesch, Rainer: Simula-tion multivariater Auktionen – Eine Analyse desOTC-Handels mit Finanzderivaten. In: Wirt-schaftsinformatik 42 (2000) 3, S. 244–252.

[BiSe98] Bichler, Martin; Segev, Arie; Beam, Car-rie: An Electronic Broker for Business-to-Busi-ness Electronic Commerce on the Internet. In:International Journal of Cooperative Informa-tion Systems 7 (1998) 4, S. 315–330.

[BrGu02] Brickley, D.; Guha, R.: RDF VocabularyDescription Language 1.0: RDF Schema, W3CWorking Draft 30 April 2002,http://www.w3.org/TR/rdf-schema/, Abruf am2002-09-19.

[CaOl01] Cardoso, Henrique Lopes; Oliveira, Eu-genio: A Platform for Electronic Commercewith Adaptive Agents. In: Dignum, Frank et al.(Hrsg.): Agent-Mediated Electronic CommerceIII. Current Issues in Agent-Based ElectronicCommerce Systems (LNCS Vol. 2003). Springer,Berlin 2001, S. 96–107.

[ChLe99] Chan, Nicholas T.; LeBaron, Blake; Lo,Andrew W. et al.: Agent-Based Models of Finan-cial Markets: A Comparison with ExperimentalMarkets. http://ebusiness.mit.edu/research/agents.pdf, Abruf am 2001-05-23.

[ChDr97] Chavez, Anthony; Dreilinger, Daniel;Guttman, Robert H. et al.: A Real-Life Experi-ment in Creating an Agent Marketplace.http://guttman.www.media.mit.edu/people/guttman/research/pubs/paam97.pdf, Abruf am2001-05-23.

[ChMa96] Chavez, Anthony; Maes, Pattie: Kas-bah: An Agent Marketplace for Buying and Sell-ing Goods. In: Crabtree, B.; Jennings, N.(Hrsg.): Proceedings of the First InternationalConference on the Practical Application of Intel-ligent Agents and Multi-Agent Technology(PAAM’96). The Practical Application Com-pany Ltd, Blackpool 1996, S. 75–90.

[ChCu01] Christensen, E.; Curbera, F.; Meredith,G.; Weerawarana, S.: Web Services DescriptionLanguage (WSDL) 1.1, W3C Note 15 March2001, http://www.w3.org/TR/wsdl, Abruf am2002-09-11.

[CoTs98] Collins, John; Tsvetovatyy, Maksim; Mo-basher, Bamshad et al.: MAGNET: A Multi-Agent Contracting System for Plan Execution.In: Proceedings of Workshop on Artificial Intel-ligence and Manufacturing: State of the Art andState of Practice, August 1998, S. 63–68.

[Comm02] CommerceOne, Inc.: Solutions.http://www.commerceone.com/solutions/,Abruf am 2002-10-01.

[DaSm83] Davis, R.; Smith, R.G.: Negotiation as aMetaphor for Distributed Problem Solving. In:Artificial Intelligence 20 (1983) 1, S. 63–109.

[Deva00] Decker, Stefan; van Harmelen, Frank;Broekstra, Jeen et al.: The Semantic Web – Onthe Respective Roles of XML and RDF.http://www.ontoknowledge.org/oil/downl/IEEE00.pdf, 2000, Abruf am 2001-06-11.

[deRa01] de Paula, Gustavo E.; Ramos, FranciscoS.; Ramalho, Geber L.: Bilateral NegotiationModel for Agent-Mediated Electronic Com-merce. In: Dignum, Frank et al. (Hrsg.): Agent-Mediated Electronic Commerce III. Current Is-sues in Agent-Based Electronic Commerce Sys-tems (LNCS Vol. 2003). Springer, Berlin 2001, S.1–14.

[Dubl99] Dublin Core Meta Data Initiative: Du-blin Core Metadata Element Set, Version 1.1:Reference Description DC-Vocabulary,http://www.dublincore.org/documents/dces/,Abruf am 2002-09-19.

[ebXM01] ebXML Core Components Team. CoreComponent Overview, Version 1.05, 2001.http://www.ebxml.org/specs/ccOver.pdf, Abrufam 2002-02-12.

[Elec02] Electronic Business XML Joint Coordina-tion Comitee: ebXML – Enabling A GlobalElectronic Market. http://www.ebxml.org, Ab-ruf am 2002-04-17.

[Fens01] Fensel, Dieter: Ontologies. A Silver Bulletfor Knowledge Management and ElectronicCommerce. Springer, Berlin 2001.

[Fort02] Forth – Institute of Computer Science:RDF Schema Registry,http://139.91.183.30:9090/RDF/Examples.html,Abruf am 2002-09-26.

[FrWe02] Fremantle, Paul; Weerawarana, S.; Kha-laf, R.: Enterprise Services. In: Communicationsof the ACM 45 (2002) 10, S. 77–82.

[GeBu02] Gehrke, Nick; Burghardt, M.; Schu-mann, M.: Ein Peer-to-Peer basiertes Modell zurDezentralisierung elektronischer Marktplatze.In: Weinhardt, Christof; Holtmann, C. (Hrsg.):E-Commerce. Netze – Markte – Technologien.Physica, Heidelberg 2002, S. 101–116.

[Glas00] Glass, Graham: The Web Services (R)evo-lution, Part 1. Applying Web Services to Appli-cations. http://www-106.ibm.com/developerworks/library/ws-peer1.html, Novem-ber 2000, Abruf am 2002-10-01.

[Grub92] Gruber, T. R.: Ontolingua: A Mechanismto Support Portable Ontologies, Technical Re-port KSL-91-66 (Final revision June 92), Knowl-edge Systems Laboratory, Stanford University.ftp://ksl.stanford.edu/pub/KSL_Reports/./KSL-91–66.ps.gz, Abruf am 2001-05-23.

[GuMa98] Guttman, R. H.; Maes, P.: Cooperativevs. Competitive Multi-Agent Negotiations in

Retail Electronic Commerce. In: Proceedings ofthe Second International Workshop on Coop-erative Information Agents (CIA’98), Paris 1998.

[IBM02] IBM: SilkRoad project.http://www.zurich.ibm.com/csc/ebizz/silkroad.html, Abruf am 2002-10-01.

[ItFu01] Ito, T.; Fukuta, N.; Shintani, T. et al.: Bid-dingBot: A Multiagent Support System for Co-operative Bidding in Multiple Auctions.http://www.cs.cmu.edu/~softagents/papers/itota-icmas00-poster.pdf, Abruf am 2001-05-23.

[Kers98] Kersten, Gregory E.: Negotiation SupportSystems and Negotiating Agents. INR02/98.http://interneg.carleton.ca/interneg/research/papers/1998/02.pdf, Abruf am 2001-05-23.

[KeNo97] Kersten, Gregory E.; Noronha, S. J.:Supporting International Negotiation with aWWW-Based System. INR05/97.http://interneg.org/interneg/research/papers/1997/05.pdf, Abruf am 2001-05-23.

[KeNo99] Kersten, Gregory E.; Noronha, S. J.: Ne-gotiations in Electronic Commerce: Methodolo-gical Misconceptions and a Resolution. INR02/99. http://interneg.org/interneg/research/papers/1999/02.pdf, Abruf am 2001-05-23.

[Kirn01] Kirn, Stefan: Agententechnologie – Ko-operierende Softwareagenten im betrieblichenEinsatz. In: Wirtschaftsinformatik 43 (2001) 2, S.120–121.

[KoGr00] Koetsier, M.; Grefen, P.; Vonk, J.: Con-tracts for Cross-Organizational Workflow Man-agement. In: Bauknecht, Kurt et al. (Hrsg.): Elec-tronic Commerce and Web Technologies.Springer, Berlin 2000, S. 110–121.

[Kreg01] Kreger, Heather: Web Services Concep-tual Architecture (WSCA 1.0).http://www.alphaworks.ibm.com/tech/webservicestoolkit, May 2001.Abruf am 2002-10-01.

[LaSw99] Lassila, O.; Swick, R.: Resource Descrip-tion Framework (RDF) Model and Syntax Spe-cification, W3C Recommendation 22 February1999, http://www.w3.org/TR/REC-rdf-syntax/,Abruf am 2002-09-26.

[LeKa97] Lee, J. G.; Kang, J. Y.; Lee, E. S.: ICO-MA: An Open Infrastructure for Agent-BasedIntelligent Electronic Commerce on the Internet.In: Proceedings of the International Conferenceon Parallel and Distributed Systems (CPADS1997). IEEE Computer Society, Los Alamitos1997, S. 648–655.

[Merz02] Merz, Michael: E-Commerce undE-Business, 2. Aufl., dpunkt-Verlag, Heidel-berg 2002.

[Mult03] MultiNeg Consortium: MultiNeg ProjectWeb Site. http://www.fbw.fh-darmstadt.de/multineg, Abruf am 2003-01-15.

[Ogbu02] Ogbuji, U.: Using RDF with SOAP,IBM developerWorks: Web Services,http://www-106.ibm.com/developerworks/webservices/library/ws-soaprdf/,Abruf am 2002-09-19.

[Ogbu00] Ogbuji, U.: Supercharging WSDL withRDF, IBM DeveloperWorks: Web Services,http://www-106.ibm.com/developerworks/library/ws-rdf/, Abruf am 2002-09-26.

[Orac02] Oracle Corporation: Exchanges.http://www.oracle.com/appsnet/products/exchanges/content.html, Abruf am 2002-10-01.

[Oram01] Oram, Andy (Hrsg.): Peer-to-Peer: Har-nessing the Benefits of a Disruptive Technology.O’Reilly, Sebastopol 2001.



[Pete00] Peters, Ralf: Elektronische Markte undautomatisierte Verhandlungen. In: Wirtschafts-informatik 42 (2000) 5, S. 413–421.

[PrCo01] Pradella, Matteo; Colombetti, Marco: AFormal Description of a Practical Agent for E-Commerce. In: Dignum, Frank et al. (Hrsg.):Agent-Mediated Electronic Commerce III. Cur-rent Issues in Agent-Based Electronic Com-merce Systems (LNCS Vol. 2003). Springer, Ber-lin 2001, S. 84–95.

[Rebs00] Rebstock, Michael: Elektronische Ge-schaftsabwicklung, Markte und Transaktionen –eine methodische Analyse. In: HMD Praxis derWirtschaftsinformatik 37 (2000) 215, S. 5–15.

[Rebs01a] Rebstock, Michael: An Application Ar-chitecture for Supporting Interactive BilateralElectronic Negotiations. In: Bauknecht, K.; Ma-dria, S. K.; Pernul, G. (Hrsg.): Electronic Com-merce and Web Technologies. Proceedings of theEC-Web 2001. Springer, Berlin 2001, S. 196–205.

[Rebs01b] Rebstock, Michael: Efficiency and Flex-ibility of Multi-Attribute Negotiations – TheRole of Business Object Frameworks. In: Tjoa,A. M.; Wagner, R. R.; Al-Zobaidie, A. (Hrsg.):Proceedings of the 12th International Workshopon Database and Expert Systems Applications.IEEE Computer Society, Los Alamitos 2001, S.742–746.

[Rebs01c] Rebstock, Michael: Elektronische Unter-stutzung und Automatisierung von Verhandlun-gen. In: Wirtschaftsinformatik 43 (2001) 6, S.609–617.

[ReAm02] Rebstock, Michael; Amirhamzeh Ta-freschi, Omid: Secure Interactive Electronic Ne-gotiations in Business-to-Business Marketplaces.In: Wrycza, Stanislaw (Hrsg.): Proceedings ofthe Xth European Conference on InformationSystems (ECIS2002). Universitat Gdansk,Gdansk 2002, S. 564–572.

[ReTh03] Rebstock, Michael; Thun, Philipp: Inter-active Multi-Attribute Electronic Negotiationsin the Supply Chain: Design Issues and an Ap-plication Prototype. In: Sprague, R. H. (Hrsg.):Proceedings of the 36th Annual Hawaii Interna-tional Conference on Systems Sciences, 6–9 Jan-uary 2003, Big Island, Hawaii. IEEE ComputerSociety, Los Alamitos 2003.

[Rung00] Runge, A.: Die Rolle des ElectronicContracting im elektronischen Handel. Diss.,Universitat St. Gallen 2000.

[SAP02] SAP AG: mySAP Marketplace.http://www.sap.com/solutions/marketplace/,Abruf am 2002–11-26.

[Schm93] Schmid, Beat: Elektronische Markte. In:Wirtschaftsinformatik 35 (1993) 5, S. 465–480.

[Schm99] Schmid, Beat: Elektronische Markte –Merkmale, Organisation und Potentiale. In:Hermanns, A.; Sauter, M. (Hrsg.): Management-Handbuch Electronic Commerce. Vahlen, Mun-chen 1999, S. 31–48.

[ScKe01] Schmitz, Volker; Kelkar, Oliver; Pas-toors, Thorsten et al.: Spezifikation BMEcat Ver-sion 1.2. http://www.bmecat.org,Abruf am 2001-05-26.

[Schn01] Schneider, Jeff: Convergence of Peer andWeb Services. http://www.openp2p.com/pub/a/p2p/2001/07/20/convergence.html,Abruf am 30.07.2001.

[ScFi02] Schoder, Detlef; Fischbach, K.: Peer-to-Peer. Anwendungsbereiche und Herausforde-rungen. In: Schoder, D. et al.: Peer-to-Peer.Springer, Heidelberg 2002, S. 3–21.

[ScQu01] Schoop, M.; Quix, C.: DOC.COM: a fra-mework for effective negotiation support in elec-tronic marketplaces. In: Computer Networks 37(2001) 2, S. 153–170.

[Stal02] Stal, Michael: Web Services: Beyond Com-ponent-Based Computing. In: Communicationsof the ACM 45 (2002) 10, S. 71–76.

[StCo99] Steinmetz, Erik; Collins, John; Jamison,Scott et al.: Bid Evaluation and Selection in theMAGNET Automated Contracting System. In:Agent Mediated Electronic Trading, LectureNotes in Artificial Intelligence (LNAI) 1571.Springer, Berlin 1999, S. 105–125.

[TeWa99] Teich, Jeffrey; Wallenius, Hannele; Wal-lenius, Jyrki et al.: A Multiple Unit Auction Al-gorithm: Some Theory and a Web Implementa-tion. In: EM – Electronic Markets 9 (1999) 3, S.199–205.

[TeKu02] Teuteberg, Frank; Kurbel, K.: Simulationdes Agentenverhaltens auf einem elektronischenMarktplatz zur Personalakquisition. In: Wein-hardt, Christof; Holtmann, C. (Hrsg.): E-Com-merce. Netze – Markte – Technologien. Physica,Heidelberg 2002, S. 253–271.

[TsGi97] Tsvetovatyy, Maksim; Gini, Maria; Mo-basher, Bamshad et al.: MAGMA: An Agent-Based Virtual Market for Electronic Commerce.In: Journal of Applied Artificial Intelligence 6(1997)

[UDDI02] UDDI: UDDI Version 3.0 PublishedSpecification, 19 July 2002. http://uddi.org/pubs/ uddi_v3.htm, Abruf am 2002-10-10.

[vaRi98] van Heck, Eric; Ribbers, Pieter M.: Intro-ducing electronic auction systems in the dutchflower industry – a comparsion of two initia-tives. In: Wirtschaftsinformatik 40 (1998) 3, S.223–231.

[Vasu01] Vasudevan, V.: A Web Services Primer,http://www.xml.com/pub/a/2001/04/04/webservices, Abruf am 2002-09-09.

[W3C02a] W3C World Wide Web Consortium,http://www.w3c.org, Abruf am 2002-10-01.

[W3C02b] W3C World Wide Web Consortium:Extensible Markup Language (XML).http://www.w3c.org/XML,Abruf am 2002-10-01.

[W3C02c] W3C Web Services Description Work-ing Group: Web Services Description Language(WSDL) Version 1.2. W3C Working Draft 9 July2002. http://www.w3.org/TR/wsdl12, Abruf am2002-10-01.

[W3C02d] W3C XML Protocol Working Group:SOAP Version 1.2 Part 0: Primer. W3C WorkingDraft 26 June 2002. http://www.w3.org/TR/soap12-part0/, Abruf am 2002-10-01.

[WuWe98] Wurman, P. R.; Wellman, M. P.; Walsh,W. E.: The Michigan Internet AuctionBot: AConfigurable Auction Server for Human andSoftware Agents. In: Sycara, K. P.; Wooldridge,M. (Hrsg.): Proceedings of the 2nd Interna-tional Conference on Autonomous Agents(Agents’98). ACM Press, New York 1998, S.301–308.

[Zarn99] Zarnekow, Rudiger: Softwareagenten undelektronische Kaufprozesse. Gabler, Wiesbaden1999.


Abstract

Integrating interactive bilateral electronic negotiations with electronic marketplaces usingweb services

We analyze and develop web services for the integration of spontaneous interactive bilat-eral multi-attribute electronic negotiations into electronic marketplaces. Conceptual andtechnical foundations of electronic markets and electronic negotiations, of web services andof RDF are discussed. The overall architectural design of the negotiation application and ofthe underlying transaction scenario is described. The information flow between the servicesis explained and their functionalities, as well as the documents exchanged, are developed.Finally, our results and related work are discussed and an outlook is given.

Keywords: electronic negotiations, web services, Peer-to-Peer, RDF, electronic markets, elec-tronic catalogs, negotiation support systems


Webservices zur integration interaktiver elektronischer verhandlungen in elektronische marktplätze;...

Documents

Transcript of Webservices zur integration interaktiver elektronischer verhandlungen in elektronische marktplätze;...