Web Services - Aufbau und Funktionsweise, Möglichkeiten und Grenzen


Seminararbeit, 2002

27 Seiten, Note: 2,7


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Aufbau und Funktionsweise von Web Services
2.1 Einführung
2.2 Architektur
2.3 Technologien
2.3.1 Simple Object Access Protocol: SOAP
2.3.2 Web Services Definition Language: WSDL
2.3.3 Universal Description, Discovery and Integration: UDDI
2.4 Einordnung in den Kontext der Entwicklung verteilter Anwendungen
2.4.1 Remote Procedure Calls: RPCs
2.4.2 Vergleich von Web Services mit alternativen Ansätzen

3 Möglichkeiten und Grenzen von Web Services
3.1 Einsatzgebiete
3.1.1 Innerbetriebliche Integration (A2A)
3.1.2 Zwischenbetriebliche Integration (B2B)
3.1.3 Kopplung zwischen Unternehmungen und Endanwendern (B2C)
3.2 Betrachtung der Stärken und Schwächen aus DV-technischer Sicht
3.3 Betrachtung der Stärken und Schwächen aus betriebswirtschaftlicher Sicht
3.4 Beispiel eines Web Service zur zwischenbetrieblichen Integration

4 Zusammenfassung und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2.2/1 : Web Services Architektur

Abbildung 2.3.1/1: Aufbau einer SOAP-Nachricht

Abbildung 2.4.1/1: RPC-Architektur

Abbildung 2.4.2/1: Vergleich von Middleware-Technologien

Abbildung 3.1/1 : Integration durch EAI

Abbildung 3.4/1 : Web Services Beispiel aus der Automobilbranche

1 Einleitung

Die vorliegende Arbeit befasst sich mit der Thematik der Web Services, die in jüngster Vergangenheit zu einem dominierenden Thema in der Informationstechnologie avancierten und von vielen großen Software-Unternehmen - insbesondere der im Middlewarebereich Aktiven - auf Basis gewisser Standards mit enormem Aufwand fokussiert werden.

Web Services dienen in erster Linie der Erleichterung der inner- und zwischenbetrieblichen Integration von Anwendungssystemen, also der komfortablen Entwicklung so genannter verteilter Anwendungen3. Der Begriff der zwischenbetrieblichen Integration ist als „ organisationsübergreifende Informationsverarbeitung “ zu interpretieren, „ die sich v. a. durch räumlich entfernte Aufgabenträger und Rechnersysteme auszeichnet4 “.

Ziel der Arbeit ist es demnach zunächst, den Aufbau und die Funktionsweise von Web Services inklusive der relevanten Technologien und Standards darzustellen, um sie in den Kontext der Entwicklung verteilter Anwendungen anhand gewisser Merkmale zu positionieren bzw. mit anderen Konzepten der Anwendungsintegration zu vergleichen. Hierbei wird bewusst von technischen Details abstrahiert, da lediglich eine kurze und überblickartige Verortung der Web Services Technologie im Gebiet der Anwendungsintegration erfolgen soll, die wiederum vornehmlich die Vergleichbarkeit mit bestehenden Konzepten zum Ziele hat.

Im zweiten Teil wird anschließend untersucht, inwieweit der Einsatz von Web Services neue Möglichkeiten bei der Entwicklung verteilter Anwendungen generiert, die neben technischen auch wirtschaftliche Nutzenpotentiale enthalten können. Nach der Darlegung der Möglichkeiten werden Grenzen und Probleme herausgearbeitet, die in Zusammenhang mit Web Services sicherlich noch bestehen, zumal es sich um eine relativ junge und demzufolge unausgereifte Technologie handelt, deren Standardisierung noch im Aufbau befindlich ist und durch Aktualisierungen und Erweiterungen häufigen Änderungen unterliegt.

Im Abschluss der Arbeit wird dann eine kritische Würdigung der Web Services Technologie dahingehend gewagt, in welchem Maße sie zwischenbetriebliche Integrationsbestrebungen zu unterstützen bzw. erleichtern weiß. In diesem Zusammenhang wird versucht, die (für die Zukunft relevanten) kritischen Erfolgsfaktoren für die Etablierung von Web Services darzulegen.

2 Aufbau und Funktionsweise von Web Services

2.1 Einführung

Web Services werden, wie bereits erwähnt, von einer Großzahl an Unternehmungen des Software- und im speziellen des Middlewaresektors mit erheblichen Aufwendungen vorangetrieben, so dass entsprechend viele Definitionen des Begriffs mit jeweils unterschiedlichen Schwerpunkten existieren, die nicht zuletzt die individuellen Unternehmensziele adressieren und somit oftmals mehr Marketingzwecken denn der Skizzierung klarer Charakteristika dienen. Dennoch sollen zur ersten Illustration der Thematik die Definitionen zweier maßgeblich an der Entwicklung der Technologie beteiligter Unternehmen wiedergegeben werden, um anschließend allgemein akzeptierte und die Technologie eindeutig definierende Merkmale zu nennen.

IBM:

Web services are self-describing, self-contained, modular applications that can be mixed and matched with other Web services to create innovative products, processes, and value chains. Web services are Internet applications that fulfill a specific task or a set of tasks that work with many other web services in a manner to carry out their part of a complex work flow or a business transaction. In essence, they enable justin-time application integration and these web applications can be dynamically changed by the creation of new web services.“

SUN:

A Web service is, simply put, application functionality made available on the World Wide Web. A Web service consists of a network-accessible service, plus a formal description of how to connect to and use the service. The language for formal description of a Web service is an application of XML. A Web service description defines a contract for how another system can access the service for data, or in order to get something done. Development tools, or even autonomous software agents, can automatically discover and bind existing Web services into new applications, based on the description of the service.5

Zusammenfassend lassen sich demzufolge Web Services als Dienstleistungen in Form von Applikationen einstufen, die u. a. anhand folgender Charakteristika beschrieben werden können:

- Selbstbeschreibend: Die abstrakte Beschreibung der in einem Web Service gekapselten Funktionalitäten samt einiger Metainformationen über bereitgestellte Schnittstellen - wie z.B. Funktionsbezeichnungen, zu übergebende Parameter, Rückgabetypen, Ports, Binding-Informationen, Kommunikationsprotokolle und Rechneradressen - werden in Form einer WSDL-Datei dokumentiert. WSDL steht hierbei für Web Services Definition Language und stellt eine XML-basierte Auszeichnungssprache dar, die in 2.3 kurz erläutert wird.

- In sich abgeschlossen: Web Services liefern eine durch eine WSDL-Datei klar umrissene Funktionalität, die sowohl die Erfüllung einer speziellen Aufgabe als auch einer Menge von Aufgaben umfassen kann. Einzelne (Teil-)Funktionalitäten können dann wiederum jeweils durch unterschiedliche Funktionsaufrufe angefordert werden. Die einzelnen Signaturen der Funktionen bilden die Schnittstelle zu einem Web Service, der quasi wie eine Blackbox genutzt werden kann.
- Modular: In sich abgeschlossene Web Services können miteinander gekoppelt werden, um bspw. verteilte Anwendungen zur Abbildung zwischenbetrieblicher Wertschöpfungsketten oder Workflows zu erzeugen.
- Netzwerkbasiert: Die Anforderung einer bestimmten Dienstleistung durch ggf. parametrisierte Funktionsaufrufe und die darauf folgende Antwort werden über ein Netzwerk gesendet. Sowohl der Funktionsaufruf als auch die Antwort basieren auf XML-Protokollen, wobei der Transport nicht durch XML selbst sondern TCP/IP-basierte Anwendungsprotokolle wie HTTP erfolgt. Die Verwendung von XML zum Funktionsaufruf als auch zur Kodierung der Rückgabewerte und der Einsatz von HTTP als Transportprotokoll haben zur Folge, dass Web Services sowohl eine internetfähige als auch eine plattform- und programmiersprachenunabhängige Technologie darstellen. Ein XML-basiertes Protokoll zur Integration entfernter Applikationen ist das in 2.3 beschriebene Simple Object Access Protocol (SOAP).
- Lose gekoppelt: Ein bestimmter Web Service ist nicht an den Aufruf desselbigen fest gekoppelt. So kann der an einen Aufruf gebundene Web Service jederzeit ersetzt werden, solange der alternative Dienst identische Schnittstellendefinitionen und natürlich identische Operationsergebnisse liefert. In einer geplanten späteren Phase der Standardisierung, die sich allerdings noch in der Entwicklung befindet und eher konzeptuellen Charakter besitzt, soll sogar „ erst zur Laufzeit, d.h. wenn ein Servicesuchender eine bestimmte Intention formuliert, ... ein entsprechender Service gesucht, gefunden und aufgerufen werden.6 “ Ziel ist es hierbei, den gesamten Such und Integrationsprozess zu automatisieren und in die Obhut so genannter Agenten zu legen.
- Automatisch auffindbar: Die lose Kopplung setzt voraus, dass Web Services mit entsprechend vergleichbarer Funktionalität (ggf. zur Laufzeit durch Agenten) gefunden und auf ihre Eignung für den aktuellen Kontext hin überprüft werden können. Realisiert wird diese Anforderung durch einen globalen, plattformunabhängigen und dezentral gepflegten Verzeichnisdienst namens Universal Description, Discovery and Integration (UDDI), der ebenfalls in 2.3 kurz beleuchtet wird.

2.2 Architektur

Der Aufbau einer durch Web Services unterstützten, verteilten Anwendung wird zunächst durch drei elementare Rollen bestimmt. Folgende Übersicht illustriert die verschiedenen Rollen und den Einsatz der mit ihnen verbundenen Technologien:

1. Service Anbieter
2. Service Nachfrager
3. Service Verwalter

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2/1: Web Services Architektur

Ein Web Service wird zunächst von einem Service Anbieter mit der Intention erstellt, einen oder mehrere Teile seiner Geschäftsanwendung für andere Applikationen über das Internet verfügbar zu machen. Diese Anforderung wird von ihm realisiert, in dem er eine neue Anwendung implementiert oder eine bestehende Applikation erweitert und entsprechend anpasst. Neben der eigentlichen

Anwendungslogik muss dieser v. a. eine über das Internet verfügbare Schnittstelle (z.B. auf Basis von SOAP) integrieren, über die die Dienstleistung später von einem Nachfragenden eingebunden werden kann. Neben der eigentlichen Erstellung muss außerdem eine den Web Service formal beschreibende Dokumentation in Form eines WSDL-Dokuments7 erzeugt werden. Anschließend kann der Web Service vom Anbieter bei einem zentralen Verzeichnisdienst, dem Service Verwalter in Form von UDDI, registriert und veröffentlicht werden.

Nach der Veröffentlichung eines Dienstes kann ein Interessent nach diesem und natürlich allen anderen offerierten Diensten der UDDI suchen und diese jeweils anhand des WSDL-Dokuments auf Eignung hin überprüfen. Ist ein passender Service gefunden, so kann dieser auf Basis des SOAP-Protokolls in eine Applikation eingebunden werden.

2.3 Technologien

Nachdem die grundsätzliche Architektur einer auf Web Services aufbauenden Anwendungsentwicklung in Zusammenhang mit den drei verwendeten Schlüsseltechnologien dargelegt wurde, sollen eben diese Technologien näher beleuchtet werden.

2.3.1 Simple Object Access Protocol: SOAP

Das Simple Object Access Protocol (SOAP) ist ein XML-basiertes Protokoll8 zur Einbindung heterogener, entfernter Applikationen. Es ist mittlerweile ein vom W3C gepflegter, offizieller Standard, dessen aktuelle Version 1.2 den Status eines W3C Working Drafts besitzt (Stand: Mai 2002).

SOAP basiert auf dem Paradigma so genannter Remote Procedure Calls (RPCs), dem Aufruf von Funktionen auf entfernten Rechnern, die auf eben diesen zur Ausführung gebracht werden und entsprechende Operationsergebnisse an den Aufrufenden zurückliefern. Um auf Basis der RPC-Idee den Aufruf von Funktionen und den Empfang entsprechender Datenstrukturen realisieren zu können, bedarf einer allseits akzeptierten Verabredung über die Art und Weise des Informationsaustauschs zwischen den entfernten und möglicherweise heterogenen Applikationen. Da vom W3C diesbezüglich protokollunabhängig propagiert wird, existieren neben SOAP noch eine Reihe weiterer XML-Protokolle, die auf Basis des RPC-Ansatzes die Einbindung entfernter Anwendungen reglementieren, wie z.B. XML-RPC.

Allerdings bildet sich SOAP als zu präferierender Standard in letzter Zeit mehr und mehr heraus, v. a. aufgrund seiner im Vergleich zu anderen XML-Protokollen stärker ausgeprägten Flexibilität. So ist es bspw. bei XML-RPC (im Gegensatz zu SOAP) nicht möglich, eigene XML-Datenstrukturen zu transportieren. Außerdem ist SOAP beim Transport der Daten grundsätzlich an kein spezielles Anwendungsprotokoll gebunden, so dass neben http z.B. auch FTP zum Einsatz kommen könnte. Neben den technischen Vorteilen führt aber auch die klare Bevorzugung von SOAP durch die Web Service-Entwicklungen vorantreibenden Softwareunternehmen (Microsoft, IBM) zur einer klaren Vormachtstellung jenes Ansatzes im Bereich der Bindungsprotokolle.

Die Inanspruchnahme eines Web Service - sprich der Aufruf einer entfernten Funktion und das Empfangen der zugehörigen Rückgabewerte - mittels SOAP funktioniert in der Art und Weise, dass der Service-Nachfragende ein spezielles (den SOAP-Regeln gehorchendes) XML-Dokument über ein Anwendungsprotokoll (z.B. HTTP) an den Service-Anbieter übermittelt, welcher nach Ausführung der durch das Aufrufdokument angeforderten Funktion ein nach identischen Regeln aufgebautes XML-Dokument über das gleiche Protokoll zurückliefert. Der Aufbau dieser SOAP- Aufrufe und -Antworten gliedert sich grundsätzlich in drei Komponenten:

1. Umschlag (Envelope)
2. Kopfteil (Header)
3. Hauptteil (Body)

Der SOAP-Umschlag dient als Mantel um die eigentliche Nachricht und besitzt mit dem SOAP-Header und dem SOAP-Body zwei grundsätzliche Kindelemente. Im optionalen SOAP-Header werden Metainformationen (z.B. eine Transaktions- oder Session-ID - siehe Abb. 2.3.1/1) über die Kommunikation ausgetauscht, während im SOAP-Body die eigentliche zu übermittelnde Nachricht codiert wird. Sie besteht im Falle eines Aufrufs im Wesentlichen aus dem Methodennamen und den zu übergebenden Parametern, die in Form einer XML-Struktur (der Name der Struktur ist gleich dem Namen der aufzurufenden Methode) mit eigenem Namensraum9 - der über eine URI spezifiziert wird - übermittelt werden. Bei einer Antwort bildet die Struktur das zurückgegebene Objekt oder entsprechende Fehlermeldungen in XML Notation ab, wobei der Strukturname gleich dem Methodennamen mit dem Zusatz „Response“ ist.

Vervollständigt wird eine SOAP-Nachricht durch das so genannte SOAP-HTTP- Binding, welches sich in den ersten Zeilen wieder findet. Es besteht aus einem HTTP-Header, der durch den Parameter SOAPAction erweitert wird. Definiert werden in diesem Fragment die verwendete HTTP-Methode (POST), der Name des Ziel-Hosts und das Zielobjekt, in dessen Verbindung eine bestimmte Methode ausgeführt werden soll. Dabei legt der bereits erwähnte Parameter SOAPAction über einen URI das Zielobjekt eindeutig fest. Bei der zugehörigen Antwort erscheinen in diesem Bereich außerdem entsprechende RESPONSE-Codes, die eine Aussage über Erfolg oder ggf. Misserfolg der verlangten Operation zulassen.

Abb. 2.3/1 zeigt exemplarisch den Aufbau einer SOAP-Nachricht mit Aufruf auf der linken und der zugehörigen Antwort auf der rechten Seite. Der Umschlag ist bei beiden Kommunikationsrichtungen identisch:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3.1/1: Aufbau einer SOAP-Nachricht

2.3.2 Web Services Definition Language: WSDL

Die Schnittstelle zu einem Web Service wird durch ein zugehöriges WSDL- Dokument formal beschrieben. Die Web Service Definition Language ist ebenfalls

[...]


3 Verteilte Anwendungen sind Softwaresysteme, die aus einzelnen Komponenten bestehen, welche wiederum auf verschiedenen, untereinander vernetzten Rechnern ablaufen. Nähere Erläuterungen siehe 2.4

4 vgl. Doch (1992), S. 3-17

5 zu den Definitionen von IBM und Sun: vgl. Jeckle (2002)

6 vgl. Knuth (2002), S. 12-13

7 Die Generierung einer WSDL-Datei kann i. d .R. entsprechenden Entwicklungsumgebungen (z.B. Microsoft Visual Studio .Net, IBM Websphere Studio 4.0) überlassen werden, nachdem ein Web Service mit ihrer Hilfe implementiert wurde.

8 Als Protokoll bezeichnet man in der Informatik „ die Menge aller Regeln, die notwendig sind, um einen kontrollierten und indeutigen Verbindungsaufbau, Datenaustausch und Verbindungsabbau gewährleisten zu können.“ Vgl. Krüger (1999), S. 811 7

9 SOAP-Nachrichten dürfen keine Document Type Definitions enthalten, sondern die zugrunde liegende Grammatik wird über Namensräume referenziert. Das erlaubt das Verwenden von Elementen unterschiedlicher Grammatiken.

Ende der Leseprobe aus 27 Seiten

Details

Titel
Web Services - Aufbau und Funktionsweise, Möglichkeiten und Grenzen
Hochschule
Georg-August-Universität Göttingen  (Institut für WI2)
Veranstaltung
Hausarbeitsseminar: Realisierung innovativer Informationssysteme
Note
2,7
Autor
Jahr
2002
Seiten
27
Katalognummer
V4749
ISBN (eBook)
9783638129022
Dateigröße
522 KB
Sprache
Deutsch
Schlagworte
Informatik, Wirtschaftsinformatik
Arbeit zitieren
Timo Runge (Autor:in), 2002, Web Services - Aufbau und Funktionsweise, Möglichkeiten und Grenzen, München, GRIN Verlag, https://www.grin.com/document/4749

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Web Services - Aufbau und Funktionsweise, Möglichkeiten und Grenzen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden