1 Einleitung

Web Services werden haufig verstanden alsDienste, die auf dem losen Zusammenspielvon Standards wie XML, SOAP, WSDLund UDDI (s. u.) beruhen und somit alsGrundlage einer unternehmens- undanwendungsubergreifenden automatisier-ten System-zu-System-Kommunikationdienen. Die einfachste Form findet sich alsXML-RPC als Front-End an Legacy-Sys-temen. Gerne zitierte Beispiele fur einfacheWeb Services umfassen Informationsabfra-gen (z. B. Wechselkurse) und Dienste wieKonvertierungen (z. B. HTML in XML).Vor allem zukunftige Web Services als Teilesich spontan formierender dynamischerWertketten verlangen eine umfassende Ar-chitektur, damit sich Anbieter und Nutzervon Diensten automatisch finden und ihreProzesse aufeinander abstimmen konnen.Nachfolgend werden die wichtigsten Bau-steine einer solchen Web-Services-Archi-tektur sowie das ebXML-Projekt als mog-liches Rahmenwerk vorgestellt. Eineausfuhrlichere Darstellung mit vielen zu-satzlichen Ressourcen und Beispielen stehtin [BWWM02] und unter http://www.wi-wi.uni-frankfurt.de/~tweitzel/xml/webser-vice/ zur Verfugung.

2 Web Services

Web Services sind definiert als unabhangi-ge, „encapsulated, loosely coupled con-tracted functions offered via standardprotocols“ [WS1]. Mit Web Services wirddas Konzept der komponentenbasierten

Softwaresysteme weiterentwickelt hin zuin weltweiten Netzwerken verteilten undvollig voneinander losgelosten Anwendun-gen, die sich zur Erbringung einer Leistungdynamisch zu einer Wertschopfungskettezusammenschließen. Dabei andert sich dasParadigma von One-to-One-Beziehungen,wie sie ublicherweise im Rahmen der EAIumgesetzt werden, hin zu Many-to-Many-Netzwerken; die einzelnen Services inKomponentenbauweise konnen kurzfris-tig, dynamisch und simultan zu unter-schiedlichen neuen Super-Services inte-griert und auf die jeweiligen Bedurfnisseangepasst werden [WIJN2001]. Dabei istes notwendig, die Web Services vollig ge-kapselt zu implementieren und in einestandardisierte logische Infrastruktur ein-zubinden, die die automatische Lokali-sierung und Einbindung eines Dienstesdurch einen anderen Dienst zur Einbezie-hung in einen Leistungsprozess ermoglicht[SAIL2001]. Eine verlinkte �bersicht uberden aktuellen Entwicklungsstand der wich-tigsten Standards, die nachfolgend zusam-mengefasst werden, bietet [BWWK02].

2.1 Bestandteilevon Web Services

Transport: Fur asynchrone bzw. synchro-ne Kommunikation konnen bestehende In-ternetprotokolle (SMTP, MIME bzw.HTTP und HTTPR (reliable)) verwendetwerden. Das Web-Services-Konzept ist je-doch auch offen fur bestehende Middle-ware (z. B. IIOP, MQSeries) und fur neueInfrastrukturen wie mobile Technologienetc. [KREG01, 10–11].

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 277–280

Die Autoren

Daniel BeimbornStefan MintertTim Weitzel

Dipl.-Kfm. Daniel Beimborn,Institut fur Wirtschaftsinformatik,J. W. Goethe-Universitat,Mertonstraße 17,60054 Frankfurt am Main, E-Mail:beimborn@wiwi.uni-frankfurt.de;Dipl.-Inform. Stefan Mintert,Solution Architect bei derSorman Information GmbH, Hamburg,sowie XML-Trailblazer,E-Mail: stefan@mintert.com;Dipl.-Kfm. Tim Weitzel,Institut fur Wirtschaftsinformatik,J. W. Goethe-Universitat,Mertonstraße 17,60054 Frankfurt am Main,E-Mail: node1@xml-network.de

Web Services und ebXML

WI – Schlagwort

Messaging & Packaging: Der defacto-Standard zur Nachrichtenkapselung und-ubertragung ist SOAP (ehemals „SimpleObject Access Protocol“) [W3C1]. DieMessaging-Protokolle unterstutzen (nichtausschließlich) das Konzept der Request-Response-Kommunikation. Der Anwen-der sendet einen Aufruf (SOAP-Message)an einen Web Service, der die in SOAP ge-kapselten Eingabeparameter verarbeitetund in einer SOAP-Antwort das Ergebnisder Abfrage zurucksendet.

Describing & Processing: Um einen Ser-vice aufrufen zu konnen, muss die anfra-gende Instanz das notwendige Format desAufrufs (Eigenschaften der Parameter, Portetc.) und des Ruckgabedokuments kennen.Diese werden vom Service in einerWSDL-Datei (Web Services Description Language)veroffentlicht. WSDL ist der verbreitetsteXML-Standard zur Beschreibung von WebServices, insbesondere ihrer Schnittstellen[W3C2].

Discovery: Der angesprochene Wandel derApplication-to-Application-Beziehungenzu Many-to-Many-Netzwerken erfordertMechanismen zum Auffinden der WebServices. Dazu konnen die Services (inkl.Schnittstellenbeschreibung, Leistungsum-fang etc.) in zentralen Repositories regis-triert werden. Der dazu geschaffene Stan-dard und das gleichnamige globaleRepository ist UDDI (Universal Descrip-tion, Discovery and Integration) [UDDI1].Daneben existieren Modelle fur eine de-zentrale Organisation der notwendigen In-formationen.

Das Zusammenspiel der beschriebenenGrundbausteine des Web-Services-Kon-zeptes wird am Beispiel des folgenden Ge-schaftsvorganges deutlich: Eine Druckereimuss eine elektronische Materialbestellung,bevor sie an den Papierlieferanten gesendetwird, in ein von diesem unterstutztesEDIFACT-Format konvertieren lassen.Das SOAP-Interface des Materialmanage-mentsystems startet zunachst eine Such-anfrage an ein offentliches UDDI-Re-pository, um einen entsprechendenService-Anbieter im Netz zu identifizieren.Aus einem UDDI-Repository werden ge-maß den Anforderungen und Praferenzender Druckerei Kontaktinformationen, da-runter auch die WSDL-Datei, ubermittelt.Die Druckerei sendet nun gemaß derSchnittstellenbeschreibung einen entspre-chend aufgebauten SOAP-Aufruf mit derBestellung als Anhang an den Dienstean-

bieter, der diesen konvertiert und ebenfallsuber SOAP wieder zuruckgibt. Anschlie-ßend kann die Druckerei die korrekt for-matierte Bestellung an den Lieferantenubermitteln.

2.2 Probleme: Sicherheit undQualitatsgewahrleistung

Eine schwerwiegende Lucke sind derzeitklassische Sicherheitsprobleme bei derIdentifikation der Partner und der Nach-richtenubertragung. Daneben stellen sichfur Service-Kunden Fragen nach der Ge-wahrleistung der (qualitativ gesicherten)Erbringung der Leistung [KREG01, 29ff.].Dies gilt vor allem bei komplexerer Trans-aktionsunterstutzung wie (in Abanderungdes obigen Beispiels) der direkten Weiter-leitung der konvertierten Bestellung vomDienstanbieter an den Papierlieferanten.

2.3 Entwicklungspfadefur Web Services

Web-Services-Technologien werden zu-nachst innerhalb von Sicherheits- undQoS-unempfindlicheren Unternehmensnetzwer-ken quasi als Middleware-Schicht zurLosung von EAI-Problemen eingesetzt, umheterogene Anwendungen miteinander zukoppeln [HAMM01, 23]. Durch Prozess-beschreibungssprachen wie die Web Ser-vice Flow Language [LEYM01] wird derWeg zur Modellierung und Umsetzungkomplexer Serviceketten uber zahlreicheDiensteanbieter hinweg geebnet. Eine Dy-namisierung dieser explizit ausmodelliertenProzesse zu sich selbstandig aufbauendenSupply Webs (vom static binding zum dy-namic binding [KREG01, 8]) erfordert je-doch weitere komplexe Mechanismen, dieinsbesondere okonomische (wie Beprei-sungs- und Abrechnungsmodelle) undrechtliche Rahmenbedingungen (wie dieKontraktfahigkeit von Services) beruck-sichtigen mussen. Hier nahert sich dasKonzept der Web Services dem Konzeptvirtueller Agenten an.

Parallel zur Entwicklung im B2B-Umfeldexistieren auch Initiativen zur Adaptionvon Web Services fur den auf Endkundenorientierten Dienstleistungsbereich. Stan-dardisierte Schnittstellen fur die Interaktionmit menschlichen Akteuren werden u. a.mit der WSUI-Spezifikation (Web Service

User Interface) bereitgestellt, die Web Ser-vices als komplexe Endnutzer-Anwendun-gen beschreibt, die einfach in Webseiteneingebettet werden konnen [WSUI1].

3 ebXML

Die unter dem Namen „Electronic Busi-ness XML“ (www.ebXML.org) laufendeInitiative hat von ihrer ursprunglichenZielsetzung her nicht zwangslaufig mitWeb Services zu tun: „Die Vision vonebXML ist es, einen globalen elektro-nischen Marktplatz zu ermoglichen, aufdem sich Unternehmen jeder Große undjeder geographischen Lage treffen konnen,um uber den Austausch XML-basierterNachrichten miteinander ins Geschaft zukommen.“ [ebXML1] Wichtig ist hier derFokus auf den gesamten Geschaftsprozess,also das Zueinanderfinden der Partner unddas Ausfuhren von Geschaftsprozessenaufgrund von XML-Dokumenten. Zur Er-lauterung erweitern wir das obige Beispielder Druckerei und betrachten zusatzlichnoch den Papierhersteller.

3.1 Partnersuche mit ebXML

Um auf einem ebXML-Markplatz auf-zutreten, muss der Papierhersteller zu-nachst sein eigenes Profil in einem Colla-boration Protocol Profile (CPP)beschreiben [ebXML2] und dieses in einemebXML-konformen Repository ablegenund in der zugehorigen Registry registrie-ren. Die Profilbeschreibung enthalt z. B.die Angabe, welche Geschaftprozesse (et-wa Kaufen, Verkaufen, Ausliefern etc.) derPapierhersteller unterstutzt und welcheRolle(n) er dabei einnimmt (Kaufer, Ver-kaufer, Lieferant etc.); in diesem Fall durftedas vor allem der Prozess „Papier kaufen/verkaufen“ in der Rolle „Verkaufer“ sein.Das Zueinanderfinden besteht darin, dassdie Druckerei eine Suche nach dem ge-wunschten Dienst im ebXML-Repository/in der Registry durchfuhrt. Stoßt sie dabeiauf den Papierhersteller, so mussen sichbeide darauf einigen, wie sie den Prozess„Papier kaufen/verkaufen“ abwickeln wol-len; d. h. wer ubernimmt welche Rolle,welche Teilprozesse sind erforderlich, wel-che Geschaftsdokumente werden dabeiausgetauscht etc. Eine Einigung zwischenden angehenden Geschaftspartnern wirdim ebXML-Szenario im CollaborationProtocol Agreement (CPA) niedergelegt.

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 277–280

278 Daniel Beimborn, Stefan Mintert, Tim Weitzel

Sowohl ein CPP als auch ein CPA liegt inXML-Notation vor. Die etablierte Ge-schaftsverbindung kann dann praktisch et-wa wie folgt aussehen: (1) Die Druckereifordert ein Angebot in einem definiertenFormat an, etwa FordereAngebot.xsd(XML-Strukturbeschreibung: XML Sche-ma Definition [W3C4]). (2) Der Papierher-steller antwortet mit Angebot.xml, gemaßAngebot.xsd. (3) Die Druckerei bestellt ge-maß dem Format Bestellung.xsd. (4) DerHersteller liefert die Ware und schickt eineRechnung.xml gemaß Rechnung.xsd.

Dieses offensichtlich stark vereinfachte Bei-spiel ließe sich leicht erweitern. Die Rolledes bisher nicht berucksichtigten Lieferan-ten erlaubt unmittelbar die Einbeziehungeiner dritten Partei; weitere Ausdehnungensind vorstellbar. Jedoch zeigt auch schondas einfache Beispiel, wie sich Web Servicesbzw. die zuvor dargestellten Techniken imRahmen von ebXML nutzen lassen bzw.damit konkurrieren.

3.2 ebXMLund/oder Web Services?

Da ist zunachst einmal die ebXML-Regis-try zu nennen. Sun und IBM empfehlenund beschreiben die Verwendung vonUDDI, um eine Registry uberhaupt ersteinmal zu finden: „The purpose of thisdocument is to present a case study show-ing how to use UDDI Business Registry tosearch for ebXML Registry/Repository“[ebXML3]. Die Suche nach einem Dienstin einem Repository regelt die RegistryService Specification [ebXML4].

Der Service selbst, also das was im Falleder Web Services mit WSDL beschriebenwird, ist im Fall von ebXML ein „BusinessProcess“, der gemaß dem Business ProcessSpecification Schema beschrieben wird[ebXML5]. Der Business Process ist jedochmehr als ein WSDL-Service, da er z. B.auch noch die Rollen der Beteiligten dekla-riert [IRAN01].

Wie eingangs erwahnt, setzt ebXML vollauf den Austausch XML-basierter Nach-richten. Fur den Austausch ist der „Mes-sage Service“ zustandig [ebXML6]. Dieserbasiert auf SOAP und SOAP Messageswith Attachments [W3C3]. Im Gegensatzzu Registry Service und Business ProcessSpecification Schema, die zumindest teil-weise mit UDDI bzw. WSDL konkurrie-ren, baut der Nachrichtenaustausch aufSOAP auf und wahlt keinen neuen Ansatz.Eine Annaherung von UDDI und ebXMList nicht zuletzt wegen des oben zitiertenPapiers absehbar.

Fur die zuvor bei den Web Services in Aus-sicht gestellten Many-to-Many-Netzwerkebringt ebXML einige Voraussetzungen mit.Samtliche Dokumente werden formalisiert(in XML) beschrieben und sind damit ma-schinenlesbar. Eine in Teilen definierte Se-mantik unterstutzt den Ad-hoc-Aufbauvon Geschaftsbeziehungen noch weiter. Imo. g. Szenario des Papierkaufens konnte

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 277–280

Web Services und ebXML 279

z. B. nach tagesaktuellen Preisen ein Liefe-rant automatisch ausgewahlt werden. Wah-rend die Techniken SOAP, WSDL undUDDI Bausteine fur den Aufbau von Ge-schaftsstrukturen sein konnen, adressiertebXML den elektronischen Geschaftsver-kehr als Ganzes. Dass dabei auch die Fragenach der Sicherheit in all seinen Erschei-nungsformen nicht unbeantwortet bleibendarf, zeigt sich zum Beispiel im RegistrySecurity Proposal [ebXML7]. Von der Fer-tigstellung ist ebXML noch einige Schritteentfernt; die Implementierung dessen wasspezifiziert wurde, ist noch in den Kinder-schuhen.

Literatur

[BWWM02] Beimborn, D.; Weitzel, T.; Wendt, O.;Mintert, S.: Infrastrukturen fur neue Geschafts-szenarien. Working Paper 2002-05, J. W. Goethe-Universitat, Frankfurt, http://www.wiwi.uni-frankfurt.de/~tweitzel/xml/webservice/.

[ebXML1] ebXML – Quality Review Team:ebXMLDocumentation Roadmap v0.93.23. 04. 2001,http://www.ebxml.org/specs/qrROAD.pdf.

[ebXML2] ebXML – Trading Partners Team: Col-laboration-Protocol Profile and Agreement Spe-

cification v1.0.http://www.ebxml.org/specs/ebCPP_print.pdf.

[ebXML3] ebXML Registry Project Team: UsingUDDI to Find ebXML Reg/Reps. 08. 05. 2001,http://www.ebxml.org/specs/rrUDDI.pdf.

[ebXML4] ebXML – Registry Team: Registry Ser-vices Specification v1.0. 10. 05. 2001,http://www.ebxml.org/specs/ebRS_print.pdf.

[ebXML5] ebXML – Business Process Team: Busi-ness Process Specification Schema v1.01.11. 05. 2001,http://www.ebxml.org/specs/ebBPSS_print.pdf.

[ebXML6] ebXML – Transport, Routing & Packa-ging Team: Message Service Specification v1.0.11. 05. 2001,http://www.ebxml.org/specs/ebMS_print.pdf.

[ebXML7] ebXML – Technical Architecture Secur-ity Team: Registry Security Proposal.11. 05. 2001,http://www.ebxml.org/specs/secREG_print.pdf.

[HAMM01] Hammer, K.: Web Services and Enter-prise Integration. In: eaiJournal 11/2001,http://www.eaijournal.com.

[IRAN01] ebXML and Web Services: The Way toDo Business. Part 2, http://www.webservices-architect.com/content/articles/irani03.asp.

[KREG01] Kreger, H.: Web Services ConceptualArchitecture (WSCA 1.0). 2001, http://www-4.ibm.com/software/solutions/webservices/pdf/WSCA.pdf.

[LEYM01] Leymann, F. (IBM): Specification derWeb Services Flow Language 1.0. 05/2001,http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

[SAIL2001] Sailer, M.: Anforderungen, Entwick-lung und Trends im Bereich Enterprise Applica-tion Integration (EAI), Online-Artikel aufwww.competence-site.de (2001),http://www.competence-site.de/eaisysteme.nsf/D544A36C8611C335C1256A5A00472B5C/$File/text_sailer_sercon.pdf.

[UDDI1] Website der Universal Description, Dis-covery and Integration Initiative.http://www.uddi.org.

[WIJN2001] Wijnhoven, F.: Models of InformationMarkets: Analysis of Markets, Identification ofServices, and Design Models. In: InformingScience – Special Series on Information Ex-change in Electronic Markets, Vol. 4, 2001,http://inform.nu/Articles/Vol4/indexv4n4.htm.

[WS1] Informationsportal der Web Services Solu-tions Ltd. http://www.webservices.org.

[WSUI1] Web Services User Interface Specification– Working Draft 1.0. 11. 02. 2002,http://wsui.org/doc/20020211/WD-wsui-20020211.html.

[W3C1] Website der Web Services Activity Groupdes World Wide Web Consortium.http://www.w3.org/2002/ws/.

[W3C2] Spezifikation der Web Services Descrip-tion Language. Version 1.1, 15. 03. 2002,http://www.w3c.org/TR/wsdl/.

[W3C3] SOAP Messages with Attachments. W3CNote vom 11. 12. 2000,http://www.w3.org/TR/SOAP-attachments.

[W3C4] XML Schema Definition. Specificationsvom 02. 05. 2001,http://www.w3.org/XML/Schema.

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 277–280

280 Daniel Beimborn, Stefan Mintert, Tim Weitzel