Leseprobe
Inhalt
Abbildungsverzeichnis
Abkürzungsverzeichnis
1 Einleitung
2 Web Services
2.1 Begriffsabgrenzung
2.2 Architektur
2.3 Web Services Technologien und Standards
2.3.1 XML
2.3.2 SOAP
2.3.3 UDDI
2.3.4 WSDL
2.3.5 SAML
3 Einsatzmöglichkeiten für Web Services
3.1 Enterprise Application Integration (EAI)
3.2 Business to Business (B2B) Integration
3.3 Business to Consumer (B2C) Interaktion
4 Status Quo und Perspektiven
Literatur
Abbildungsverzeichnis
Bild 1: Web Service Architektur
Bild 2: Schichtenmodell für Webservices
Bild 3: Struktur einer SOAP Nachricht über HTTP (SOAP with Attachments)
Bild 4: UDDI.org Struktur
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
Stand seit Anfang der 80er Jahre 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, hat sich mittlerweile 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].
Im Rahmen dieser Überlegungen werden Web Services seit ungefähr 2 Jahren als Allzweckwerkzeug für die Internet basierte Anbahnung und Abwicklung von Geschäftsprozessen propagiert. Interoperabilität und Plattformunabhängigkeit sind verheißungsvolle Versprechungen der IT-Industrie, die mit dem Begriff der Web Services einhergehen und diese Technologie nicht nur für überbetriebliche, sondern auch innerbetriebliche Integrationsprojekte interessant machen. Neu sind diese Versprechungen allerdings nicht, ältere Komponentenmodelle wie DCE, CORBA, DCOM oder EJB sind teilweise mit ähnlichen Ansprüchen platziert worden, konnten sie letztendlich aber nicht erfüllen.
Mit Web Services soll sich das nun ändern, denn im Unterschied zu älteren Komponentenmodellen ist die Herstellerunterstützung bei Web Services wesentlich breiter, die Basistechnologie ist leichter zu beherrschen und vollkommen plattform- und programmiersprachenunabhängig.
Die folgende Fallstudie stellt dar, was Web Services sind und auf welchen Technologien und Standards sie basieren. Die praktische Bedeutung wird anhand der Anwendungsbereiche für Web Service Technologien aufgezeigt. Eine Zusammenfassung mit Ausblick auf zukünftige Entwicklungspotentiale schließt die Betrachtung ab.
2 Web Services
2.1 Begriffsabgrenzung
Web Services sind, wie der Name vermuten lässt, Dienste, die über das Internet (bzw. Internettechnologien) angeboten werden. 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].
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 entwickelt, beschrieben und stellen ihre Dienste über das Kommunikationsprotokoll SOAP zur Verfügung.
- Schnittstellen von Web Services werden über die standardisierte Schnittstellenbeschreibungssprache WSDL definiert.
- Damit Web Services durch potentielle Benutzer oder andere Web Services identifiziert werden können, werden sie in einem öffentlichen UDDI Verzeichnis registriert.
Da die Verwendung von WSDL und UDDI insbesondere bei unternehmensinternen Koppelungsprojekten nicht zwingend erforderlich ist, kann SOAP als Minimalstandardtechnologie für Web Services betrachtet werden.
Web Services sind modulare Dienste, die maschinell aufgefunden und genutzt werden können. Web Services Implementierungen nutzen minimal den Standard SOAP, ergänzt um WSDL und UDDI.
Wie die Technologien XML, SOAP, WSDL und UDDI zusammenspielen, wird nun verdeutlicht.
2.2 Architektur
Gekapselte Funktionalitäten und standardisierte Schnittstellen sind Voraussetzungen für die Interoperabilität von Web-Services. Nur so kann sichergestellt werden, dass ein Web Service maschinell gefunden und aufgerufen werden kann. Ein Funktions- bzw. Web-Service Aufruf wird durch das SOAP Protokoll realisiert. SOAP ist ein XML Dialekt, der es ähnlich konventionellen Remote Procedure Calls (RPCs) ermöglicht, Funktionsaufrufe auf entfernten Servern durchzuführen. Als Transportschicht wird HTTP (alternativ SMTP oder FTP) benutzt.
Die Funktionalität des Web-Service wird als definierte und in WSDL beschriebene Schnittstelle angeboten, die einen Input entgegennimmt und eine entsprechende Ausgabe zurückliefert. Die hinter dem Web-Service liegende technische Komponente ist nicht maßgeblich, allein die Kompatibilität des Web-Service bzw. dessen Schnittstelle ist entscheidend.
Damit Web Services von anderen Web Services gefunden werden können, werden sie im UDDI Verzeichnis publiziert. UDDI beschreibt alle registrierten Web-Services hinsichtlich ihrer Funktionalität und Schnittstelle in Form eines XML Datensatzes.
Folgende Beschreibung verdeutlicht die Architektur und das Zusammenwirken dieser Technologien:
Abbildung in dieser Leseprobe nicht enthalten
Bild 1: Web Service Architektur
1. Damit ein Web Service (Service Broker) von einem anderen Web Service (Service Requestor) lokalisiert werden kann, wird er im UDDI Verzeichnis registriert. Dazu wird der Web Service in WSDL beschrieben und die Beschreibung (Service Description) als XML Dokument über SOAP an das Directory übertragen. UDDI ist dabei selbst ein Web Service mit einer eigenen Service Description. 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 (Binding), in deren Ablauf der Web Service seine Dienstleistung erbringt.
2.3 Web Services Technologien und Standards
Standards spielen eine entscheidende Rolle bei der Gewährleistung der Kompatibilität und Interoperabilität von Web Services. Im Folgenden wird deshalb näher auf die oben erwähnten XML Dialekte SOAP, WSDL und UDDI eingegangen.
Der Aufbau des Web Service Protocol Stacks und die Aufgabenteilung der einzelnen Technologien geht aus dem folgenden Schichtenmodell für Web Services, ergänzt um die Transport- und Netzwerkschicht, hervor. Analog zum ISO / OSI Referenzmodell besteht der Web Service Protocol Stack aus von einander unabhängigen Schichten, die jeweils Funktionen für die darüber liegende Schicht erbringen und dennoch voneinander unabhängig sind:
Abbildung in dieser Leseprobe nicht enthalten
Bild 2: Schichtenmodell für Web Services [in Anlehnung an UDD2002a, S.4; Knut2002, S.97; Siem2003]
[...]