Einsatz von Web Services im E-Commerce

Inhalt

Abbildungsverzeichnis

Abkürzungsverzeichnis

Abstrakt

1 Kollaborative Geschäftsprozesse

2 Web Services
2.1 Begriffsbestimmung
2.2 Funktionsweise

3 Web Services Standards
3.1 Technische Standards
3.1.1 XML
3.1.2 SOAP
3.1.3 UDDI
3.1.4 WSDL
3.2 ebXML – Mehrwert durch Semantik
3.3 Sicherheitsaspekte bei Web Services

4 Einsatzmöglichkeiten für Web Services
4.1 Einsatzfelder
4.1.1 Enterprise Application Integration (EAI)
4.1.2 Business to Business (B2B) Integration
4.1.3 Business to Consumer (B2C) Interaktion
4.2 Praxisbeispiel Impuls-Schuh-AG

5 Status Quo und Perspektiven
5.1 Status Quo
5.2 Perspektiven

Literatur

Eidesstattliche Erklärung

Abbildungsverzeichnis

Bild 1: Übersicht Komponentenmodelle

Bild 2: Web Service Architektur

Bild 3: Schichtenmodell für Webservices

Bild 4: Struktur einer XML Nachricht

Bild 5: Struktur einer SOAP Nachricht über HTTP (SOAP with Attachments)

Bild 6: SOAP Request und Response Paar

Bild 7: Aufbau einer UDDI Business Description

Bild 8: Syntax einer SOAP Anfrage am UDDI Inquiry API

Bild 9: UDDI.org Struktur

Bild 10: Beispiel einer Service Description in WSDL

Bild 11: Mögliches Kommunikationsverhalten von Web Services

Bild 12: ebXML Framework [in Anlehnung an ebXML2003c]

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abstrakt

Im Rahmen der Diskussion um kollaborative Szenarien der Geschäftsabwicklung werden Web Services seit geraumer Zeit als Allzweckwerkzeug für die Internet basierte Anbahnung und Abwicklung von Geschäftsprozessen propagiert.

Die folgende Arbeit stellt dar, was Web Services sind und welche heutigen und zukünftigen Einsatzmöglichkeiten bestehen bzw. denkbar sind. Insbesondere wird dabei auf den Aspekt der Standardisierung von Web Services eingegangen. Denn nur wo Standards definiert sind, kann die unternehmensübergreifende Kommunikation formalisiert und elektronisch abgebildet werden.

Dabei wird verdeutlicht, dass die Entwicklung technischer Standards wie XML, SOAP, WSDL und UDDI mittlerweile recht weit fortgeschritten ist. Die Standardisierung semantischer Formate, die eine zwingende Voraussetzung für die praktische Kollaboration von Unternehmen darstellt, ist bislang hinter der technischen zurückgeblieben. Entsprechende, semantische Ansätze, wie sie z.B. durch OASIS und diverse weitere Organisationen vorangetrieben werden, könnten dieses Defizit in Zukunft beseitigen. Aus den im EDI Bereich gewonnen Erfahrungen heraus ist jedoch nicht zu erwarten, dass sich kurzfristig branchenweite oder gar –übergreifende Standards am Markt etablieren werden.

1 Kollaborative Geschäftsprozesse

Seit Anfang der 80er Jahre stand die Optimierung innerbetrieblicher Prozesse und Informationsflüsse im Rahmen von MRP- (Material Resource Planning) und ERP-(Enterprise Resource Planning) Projekten im Fokus der meisten mittleren und größeren Unternehmen.

In den letzten Jahren hat sich jedoch die Erkenntnis durchgesetzt, dass die Optimierung unternehmensinterner Prozesse zwar eine notwendige, aber keinesfalls hinreichende Bedingung für die Wettbewerbsfähigkeit eines Unternehmens ist. In einer vernetzten, hochgradig arbeitsteiligen Wirtschaft konkurrieren eben nicht mehr einzelne Unternehmen, sondern komplette Wertschöpfungsketten aus Kunden, Zulieferern und Partnern miteinander. „Die Bildung von zwischenbetrieblichen Kooperationen wird für die beteiligten Akteure immer häufiger zum Instrument der Verbesserung ihrer Wettbewerbsposition in einer globalen Weltwirtschaft“ [BuKö00, S. V].

Dieser Erkenntnis tragen verschiedene, neuere Begriffe und Konzepte, wie ERP II (Enterprise Ressource Planning 2nd Generation) [Gart00] oder C-Business (Collaborative Business) [Wett2003] Rechnung. Beiden Konzepten ist gemein, dass sie die Kooperationsfähigkeit von Unternehmen, d.h. die Fähigkeit zur Integration in kollaborative Geschäftsprozesse, betonen und das Internet als geeignetes Kommunikations- und Koordinationsinstrument betrachten. Hieraus lassen sich neue Anforderungen an Konzeption und Integration der diese Prozesse unterstützenden IT Systeme ableiten.

Standen zu Zeiten des ERP Booms monolithische Anwendungssysteme im Vordergrund, so fordern kollaborative Geschäftsprozesse modulare Softwarekomponenten, die ihre Funktionalitäten als Services gekapselt über standardisierte Internettechnologien zur Verfügung stellen. Einerseits sollen so ohne substantielle Schnittstellen- und Integrationsaufwände unternehmensinterne IT-Systeme gekoppelt werden. Andererseits soll die Kommunikation mit externen Systemen von Geschäftspartnern ermöglicht und so ganze Unternehmen fallweise zu virtuellen Wertschöpfungsketten kombiniert werden. Auf diesen Überlegungen basiert das Konzept der Web Services.

Die folgende Arbeit stellt dar, was sich hinter dem Begriff der Web Services verbirgt und auf welchen Standards Web Services aufbauen. Denn nur wo Standards definiert sind, kann die unternehmensübergreifende Kommunikation formalisiert und elektronisch abgebildet werden. Standardisierung ist demnach eine Kernanforderung für die praktische Einsatzfähigkeit von Web Services. Vorgestellt werden die technischen Basisstandards XML, SOAP, WSDL und UDDI. Mit ebXML wird ein weiterer, umfassender eBusiness Standard vorgestellt, der teilweise auf den technischen Basisstandards aufsetzt, aber darüber hinaus eine semantische Komponente zur Beschreibung von Geschäftsprozessen und Geschäftsnachrichten beinhaltet. Weiter wird beleuchtet, für welche Einsatzmöglichkeiten Web Services geeignet sind und wie zukünftigen Perspektiven von Web Services aussehen. Zur plastischen Darstellung der Einsatzmöglichkeiten wird das Beispiel der im Kurs behandelten Impuls-Schuh-AG herangezogen. Eine Bewertung des Status Quo mit Ausblick auf zukünftige Entwicklungen schließt die Arbeit ab.

2 Web Services

2.1 Begriffsbestimmung

Web Services sind, wie der Name vermuten lässt, Dienste, die über das Internet (bzw. Internettechnologien) angeboten werden können. Sie beinhalten gekapselte Funktionalitäten mit definierten und im Idealfall standardisierten Schnittstellen, welche die Interoperabilität, d.h. die Zusammenarbeit mit anderen Web Services, ermöglichen. Web Services sind plattform- und programmiersprachenunabhängig [HMD2003a] und können so zusammenarbeiten, unabhängig davon, auf welchem Server sie sich befinden und auf welcher Plattform sie implementiert wurden.

Technische und semantische Standards, die den Web Services zugrunde liegen, werden von nahezu allen IT- und Softwareherstellern unterstützt. Dies war bei anderen Komponentenmodellen, mit ähnlichen Zielsetzungen hinsichtlich Interoperabilität und Plattformunabhängigkeit, wie DCE (Distributed Computing Environment), CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) oder EJBs (Enterprise Java Beans) nicht oder nicht in dem Ausmaß der Fall. Darüber hinaus ist das den Web Services zugrunde liegende Kommunikationsprotokoll SOAP (Standard Object Access Protocol) wesentlich weniger komplex und so einfacher zu beherrschen. In der Praxis bringen DCE-, DCOM- oder CORBA-Implementierungen eine Reihe weiterer Nachteile mit sich, da sie die Verwendung von Sprachen und Werkzeugen teilweise stark einschränken und praktisch nur in Intranet Umgebungen funktionieren [Knut2002, S. 14].

Abbildung in dieser Leseprobe nicht enthalten

Bild 1: Übersicht Komponentenmodelle

Web Service Definitionen gibt es hinreichend, fast jeder Anbieter oder Autor hat seine eigene mehr oder weniger ausgeprägte Auffassung, was unter einem Web Service zu verstehen ist [vgl. exemplarisch Bitz2002, S. 217; UDD2002a, S.2; HMD2003a; FiMa2003; RaVo2002, S.293f]. Um eine Abgrenzung zu weiteren, über das Internet angebotenen Diensten und insbesondere zu den o.g. Komponentenmodellen zu schaffen, wird häufig von XML Web Services gesprochen, die folgende Gemeinsamkeiten haben (in Anlehnung an [FiMa2003]):

- Web Services werden in der Metasprache XML (eXtensible Markup Language) entwickelt und beschrieben und stellen ihre Dienste über das Standard Protokoll SOAP zur Verfügung.
- Schnittstellen von Web Services werden über die standardisierte Schnittstellenbeschreibungssprache WSDL (Web Service Description Language) definiert.
- Damit Web Services durch potentielle Benutzer oder andere Web Services identifiziert werden können, werden sie in einem öffentlichen Verzeichnis (UDDI: Universal Description, Discovery and Integration) oder auf der Website des Bereitstellers (über WSI: Web Services Inspection) registriert.

Da die Verwendung von WSDL und UDDI im Rahmen bei einigen Projekten (z.B. bei innerbetrieblichen Integrationsprojekten) relativ zu vernachlässigen ist, kann SOAP als Minimalstandardtechnologie für Web Services betrachtet werden.

Im Folgenden wird unter einem Web Service ein modularer Dienst verstanden, der maschinell aufgefunden und genutzt werden kann. Web Services Implementierungen nutzen minimal den Standard SOAP, ergänzt um WSDL und UDDI.

Wie diese Technologien zusammenwirken, wird nun dargestellt.

2.2 Funktionsweise

Kapselung von Funktionalitäten und standardisierte Schnittstellen sind Voraussetzungen für Web-Services. Web-Services ermöglichen Komponentenaufrufe, als wenn die Komponente Bestanteil der eigenen Anwendung wäre. Der eigentliche Funktions- bzw. Web-Service Aufruf wird durch das SOAP Protokoll realisiert. SOAP ist ein XML basiertes Protokoll, das es, ähnlich konventionellen Remote Procedure Calls (RPCs), ermöglicht, Funktionsaufrufe auf entfernten Servern durchzuführen. Als Transportschicht wird dabei das Hypertext Transport Protocol (HTTP) oder alternativ SMTP (Simple Mail Transfer Protocol) bzw. FTP (File Transfer Protocol) benutzt.

Die Funktionalität des Web-Services wird als definierte und beschriebene Schnittstelle angeboten, die einen bestimmten Input verlangt und ggf. dafür eine entsprechende Information als Ausgabe zurückliefert. Die hinter dem Web-Service liegende technische Komponente ist nicht maßgeblich, allein die Kompatibilität des Web-Service bzw. dessen Schnittstellen ist entscheidend.

Schnittstellen von Web-Services lassen sich mit der XML basierten WSDL standardkonform beschreiben. Zur Publikation der Web-Service Beschreibung werden Verzeichnisse, Web-Service Directories, genutzt, die alle verfügbaren Web-Services hinsichtlich ihrer Funktionalität und Schnittstelle als XML Datensatz beschreiben. UDDI ist ein solches globales, branchenübergreifendes und öffentliches Web-Service Directory. Soll ein Web Service nicht öffentlich publiziert werden, kann er alternativ mittels WSI auf dem eigenen Server registriert und dort angeboten werden.

Folgendes Schaubild verdeutlicht Architektur und Zusammenwirken dieser Elemente:

Abbildung in dieser Leseprobe nicht enthalten

Bild 2: Web Service Architektur

1. Damit ein Web Service (Service Broker) von einem anderen Web Service (Service Requestor) gefunden werden kann, muss er in einem UDDI (oder WSI) Directory registriert werden. Dazu wird der Web Service in WSDL beschrieben und die Beschreibung (Service Description) als XML Dokument über SOAP an das Directory übertragen. Der Web Service ist damit registriert. UDDI ist dabei selbst ein Web Service und wird über eine in WSDL beschriebene Schnittstelle angesprochen. Die Service Descriptions der registrierten Web Services werden als XML Dokumente in einer Datenbank abgelegt.
2. Der Service Requestor greift, um einen geeigneten Web Service zu identifizieren, mit einem SOAP Aufruf auf das Directory zu. Dieser SOAP Aufruf enthält die Parameter des gesuchten Web Services. Wird über die Suche ein geeigneter Web Service identifiziert, sendet das Directory über SOAP das Ergebnis der Suche zurück an den Service Requestor.
3. Der Service Requestor ist nun in der Lage, den gesuchten Web Service zu adressieren und eine Kommunikation aufzubauen. Geschäftsdaten werden dabei innerhalb der SOAP Protokolls als XML Nachrichten (Payload) ausgetauscht. Die Schnittstelle des Service Brokers verarbeitet die Payload nach dem Black-Box Prinzip und gibt das Ergebnis der Verarbeitung wiederum als Payload über SOAP an den Service Requestor zurück.

Prinzipiell lassen sich Web-Services so zu lose gekoppelten Anwendungen kombinieren, die eine Implementierung von Collaborative Commerce Business darstellen können. Voraussetzung hierfür ist, dass die Web Service Implementierungen den im Folgenden dargestellten Standards entsprechen.

3 Web Services Standards

Standards spielen eine entscheidende Rolle bei der Gewährleistung der Kompatibilität und Interoperabilität von Web Services. Sie betreffen zum einen die technische Ebene, welche die Kommunikation von Web Services definiert und zum anderen die semantische Ebene, welche Inhalt und Struktur der kommunizierten Geschäftsdaten definiert. Für beide Ebenen haben sich bereits Standards herauskristallisiert bzw. werden z.Zt. Standards definiert oder weiterentwickelt.

3.1 Technische Standards

Mit Ausnahme der Standardisierung von UDDI werden nahezu alle technischen Standards für Web Services vom W3C (World Wide Web Consortium) vorangetrieben. Diese, 1994 etablierte Organisation, verfolgt die- Zielsetzung, die Potentiale des WWW durch die Definition von einheitlichen Standards zu entfalten. Das W3C konzentriert sich dabei weitestgehend auf horizontale, d.h. branchenübergreifende und somit meist technische Standards wie XML, SOAP und WSDL. Erst im Oktober 2003 wurde eine Interessengruppe gegründet, die sich mit der Integration semantischer (hier: betriebswirtschaftlicher) Aspekte, wie sie z.B. ebXML bietet, in die technischen W3C Standards beschäftigt [W3C2003j]. Ein Überblick über die für Web Services relevanten Standardisierungsaktivitäten des W3C findet sich unter [W3C2003c].

Das Zusammenwirken der genannten Web Services Standards geht aus dem folgenden Schichtenmodell für Web Services hervor:

Abbildung in dieser Leseprobe nicht enthalten

Bild 3: Schichtenmodell für Webservices [in Anlehnung an UDD2002a, S.4; Knut2002, S.97; Siem2003]

[...]