SOAP Simple Object Access Protocol Seminarvortrag SOAP Simple Object Access Protocol Julia Sannwald

Gliederung Was ist SOAP? SOAP und XML Nachrichten Datentypen bei SOAP SOAP Transporte RPCs über SOAP Sicherheit Fazit

Was ist SOAP? (1) SOAP: Simple Object Access Protocoll Entwickelt von: DevelopMentor, IBM, Microsoft Hauptautor: Don Box, einer der Autoren des XML Manifests Vom W3 Consortium unterstützter Standard Einfaches Protokoll, um Nachrichtenaustausch zw. verteilten Systemen zu ermöglichen

Was ist SOAP (2) Ziele: Einfachheit Erweiterbarkeit Einsatz auf verteilten Systemen, auch durch Firewalls hindurch Das Rad nicht neu erfinden, sondern aktuelle Standards (HTTP und XML) zu nutzen

Was ist SOAP? (3) basiert auf zwei bestehenden Standards: 1. HTTP: übernimmt Transport einer Nachricht 2. XML: Umschlag für die Nachricht Soap kann in einem weiten Einsatzfeld gebraucht werden, von einfachen Nachrichtensystemen bis hin zu Remote Procedure Calls (RMCs).

Gliederung Was ist SOAP? SOAP und XML Nachrichten Datentypen bei SOAP SOAP Transporte RPCs über SOAP Sicherheit Fazit

SOAP und XML SOAP ist XML Basiert auf XML Standards wie XML Schema und XML Namensräume. SOAP definiert zwei Namensräume vor: 1.xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 2.xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" Namensraumdeklarationen sind nur in Dokumenten, nicht in DTDs möglich

Gliederung Was ist SOAP? SOAP und XML Nachrichten Datentypen bei SOAP SOAP Transporte RPCs über SOAP Sicherheit Fazit

Nachrichten (1) Idee: zwei Applikationen tauschen Nachrichten aus, ungeachtet auf die jeweiligen Entwicklungsumgebungen. Programmiersprachen-, Betriebssystem- und Plattformunabhängig

Empfangen einer Nachricht Aktionen: 1. Identifikation aller Teile einer SOAP-Nachricht 2. Sicherstellen, dass die Anwendung auch die Nachricht versteht, wenn nicht wird die gesamte Nachricht verworfen. 3. Falls die Anwendung nicht der endgültige Empfänger der Nachricht ist: Entfernen aller durch Schritt 1. identifizierten Teile der Nachricht, bevor sie weitergeleitet wird.

Verarbeiten einer Nachricht SOAP-Prozessor muss über folgende Informationen verfügen: Das Muster des Nachrichtenaustauschs, das verwendet wird (Einweg, Frage/Antwort, Multicast) Seine Rolle in diesem Nachrichtenwechsel Einsatz von evtl. vorhandenen RPC-Mechanismen Die Datenrepräsentation und –kodierung Alle weiteren Semantiken, die zum korrekten Verarbeiten der Nachricht benötigt werden.

Aufbau SOAP-Nachricht besteht aus den drei Komponenten: -SOAP- Envelope -SOAP- Header (optional) und -SOAP- Body

SOAP Nachrichten Struktur SOAP envelope SOAP header Header block Header block SOAP body Message body

<SOAP-ENV:Envelope xmlns:s="http://schemas.xmlsoap.org/envelope/“ SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding "> <SOAP-ENV:Header> <m:transaction xmlns:m="soap-transaction" SOAP-ENV :mustUnderstand="true"> <transactionID>1234</transactionID> </m:transaction> </ SOAP-ENV :Header> < SOAP-ENV :Body> <n:purchaseOrder xmlns:n="urn:OrderService"> <from><person>Christopher Robin</person> <dept>Accounting</dept></from> <to><person> Pooh Bear</person> <dept>Honey</dept></to> <order><quantity>1</quantity> <item>Pooh Stick</item></order> </n:purchaseOrder> </ SOAP-ENV :Body> < SOAP-ENV :Envelope> Vor der Verwendung eines Namensraums muss dieser deklariert werden. Namensräume werden als Attribut xmlns:NR-Prefix eines Elements deklariert. Diese Deklaration gilt für dieses Element und all seine Unterelemente. Schemata dienen als Ersatz der DTDs. Sie haben größere Ausdruckskraft und sind mit Namensräumen kompatibel.

SOAP-Envelope Jeder Envelope darf exakt nur ein Body-Element enthalten. Syntaxregeln: Der Name des Elements lautet „Envelope“. Das Element muss in jeder SOAP-Nachricht enthalten sein. Das Element darf zusätzliche Attribute enthalten.

Das encodingStyle- Attribut Wird gebraucht, um das Format (Datentypen) zu definieren,welches für das Dokument bzw. Nachricht verwendet wird. < SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding ">

SOAP-Header Jedes Element im Header bezeichnet man als „header block“. Enthält Informationen über die SOAP-Nachricht z.B.:Authentifizierungsangaben oder Routing-Informationen

Das actor-Attribut SOAP-Nachricht kann mehrere Zwischenstationen passieren. Zwischenstation: SOAP-Anwendung, die sowohl Nachrichten empfangen und verarbeiten als auch weiterleiten kann Zwischenstation und endgültige Empfänger werden durch URIs eindeutig identifiziert.

Das mustUnderstand-Attribut Mit dem mustUnderstand-Attribut wird festgelegt, ob der jeweilige Empfänger den Header-Entry verarbeiten muss oder nicht. Der aktuelle Wert kann dabei ‘‘true“ oder ‘‘false“ sein, wobei letztere der Default-Wert ist. Hier im Beispiel bedeutet dies für den Empfänger, dass er entweder den Semantiken des Elements Folge zu leisten hat oder im Verarbeiten der Nachricht versagt und einen Fehler zurückgeben muss. Siehe Skript

SOAP-Body Das Body-Element ist ein direktes Kindelement des SOAP-Envelopes, und steht damit entweder direkt nach dem Header-Element, oder ist das erste Kindelement. Alle direkten Kindelemente des Bodyelements werden als Body-Entries bezeichnet. Ein Body-Entry wird durch seinen Elementnamen, der aus dem Namespace und dem lokalen Namen besteht, eindeutig identifiziert.

XML Schemas und xsi:type SOAP definiert drei verschiedene Wege, um einen Datentyp eines Accessors zu beschreiben: 1 .Das xsi:type Attribut <person> <name xsi:type=‘‘xsd:string“>John Doe</name> </person>

XML Schemas und xsi:type (2) 2. Referenz auf ein XML Schema, welches den Datentyp definiert <person xmlns:“personschema.xsd“> <name>John Doe</name> </person> 3.Referenz auf irgend ein anderes Schema-Dokument <person xmlns=‘‘urn:some_namespace>

Gliederung Was ist Soap? Soap und XML Nachrichten Datentypen bei SOAP Soap Transporte RPCs über Soap Sicherheit Fazit

Datentypen bei SOAP Einfache Datentypen Zusammengesetzte Datentypen Direkt in XML verankert Zusammengesetzte Datentypen Strukturen Referenzen auf Werte Arrays

Einfache Datentypen Zeichenketten (strings) Fließkommazahlen (float, double) Boolsche Werte (boolean) Festkommazahlen (decimal) Zeit-Datumsangaben (TimeDuration) Binärdaten (binary) [Aufzählungstypen]

Zusammengesetzte Datentypen (1) Strukturen: Eine Struktur ist eine zusammengesetzte Variable, in welcher jedes Element einen unterschiedlichen Namen hat. <person> <firstname>Joe</firstname> <lastname>Miller</lastname> </person>

Referenzen auf Werte Jedes Element, dass auf ein anderes verweist, ist selbst leer und besitzt ein href-Attribut vom Typ ‘‘uri-reference“ (nach der XML-Schema-Spezifikation). <e:Buch> <autor href="#pDF"/> <titel> Java in a Nutshell </titel> </e:Buch> <titel> JavaScript- Das umfassende Referenzwerk </titel> <e:Person id ="pDF"> <name> David Flanagan</name> <adresse href"=#adrDF"/> </e:Person> <e:adresse id="adrDF"> <email>mailto:DavidF@hotmail.com</email> <www>http://www.davidf.com</www> </e:adresse>

Zusammengesetzte Datentypen (3) Arrays Ein Array ist eine zusammengesetzte Variable, in welcher jedes Element den gleichen Namen hat <people> <person name =‘joe miller‘/> <person name =‘sebastian sommer‘/> </people>

Gliederung Was ist SOAP? SOAP und XML Nachrichten Datentypen bei SOAP SOAP Transporte RPCs über SOAP Sicherheit Fazit

SOAP-Transporte SOAP über HTTP Meist genutzte Protokoll, um Nachrichten zu versenden Kann man gleichsetzten mit SOAPs RPC-Vereinbarungen, da HTTP ein anfrage-/antwort-basiertes Protokoll ist. Request-Nachricht wird an den HTTP-Server gesendet und der Server gibt eine SOAP-Response zurück

SOAP Fehler (1) Fehler können während der Ausführung einer Nachricht auftreten Wenn ein solcher auf der Serverseite aufgetreten ist, dann enthält der Body einen <Fault>-Tag. Dieser ist in einen <faultcode>, <faultstring>, <faultactor>(op) und <detail>(op) aufgeteilt.

SOAP Fehler (2) Faultcode Variable, die vorgesehen ist, um den Fehlertyp aufzunehmen. SOAP bietet einige vordefinierte Werte, die das faultcode-Element annehmen kann. Sie muss in jedem Fault-Element vorkommen Faultstring Vorgesehen, um eine durch Menschen lesbare Fehlermeldung zu liefern. Auch dieses muss in jedem Fault-Element vorkommen.

SOAP Fehler (3) Faultactor Wird verwendet, wenn der Fehler in einer Anwendung aufgetreten ist, die nicht das Ziel der Nachricht gewesen ist. Detail Wird verwendet, wenn der Inhalt des Body-Elements der SOAP-Nachricht nicht verarbeitet werden konnte.

Vordefinierte SOAP-Fehlercodes Wert Name Bedeutung 100 VersionMismatch Aufruf wurde mit falscher SOAP-Version durchgeführt 200 MustUnderstand Element war mit mustUnderstand=‘‘true“ markiert und wurde vom Empfänger nicht verstanden. 300 Client Empfänger hat Anfrage nicht bearbeitet, weil sie falsch gestellt war oder von der Anwendung nicht bearbeitet werden kann 400 Server Es kam bei der Bearbeitung der Anfrage zu einem Fehler.

Ein möglicher Fehlerfall 200 OK Content-Type: text/xml Content-Length: 152 <SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/> <SOAP-ENV:Body> <SOAP-ENV:Fault> <SOAP-ENV:faultcode>200</ SOAP-ENV:faultcode> < SOAP-ENV:faultstring>Must Understand Error</ SOAP-ENV:faultstring> < SOAP-ENV:detail xsi:type= ‘‘Fault“> <errorMessage>Object not installed on server </errorMessage> </ SOAP-ENV:detail> </ SOAP-ENV:Fault> </SOAP-ENV:Envelope>

Gliederung Was ist SOAP? SOAP und XML Nachrichten Datentypen bei SOAP SOAP Transporte RPCs über SOAP Sicherheit Fazit

Was sind RPCs Seit 1984 Ansatz entfernter Funktionsaufrufe Von Birrell und Nelson entwickelt Der Client ruft Routinen auf einem Server auf Zwei Kernprobleme: Identifikation der entfernten Prozedur/Methode Transfer der Parameter und Ergebnisse

XML-RPCs Ist eine sehr einfache Realisierung des Konzepts ‘‘Fernaufruf“ : Identifikation durch Angabe des Servers mit Hilfe von IP-Adresse, Port, Objekt- und Methodenname Transfer der Daten als XML-Dokumente HTTP-Post als Transportmedium Zumeist Port 80, damit die Requests ungehindert durch Firewalls transportiert werden können.

RPCs mit SOAP Im Wesentlichen stellt SOAP ein verbessertes XML-RPC-Konzept dar Verwendung fortgeschrittener XML-Technologien (inkl. Schemata und Datenbeschreibung) Erweiterter HTTP-Header Verallgemeinerung:Nachrichtenkonzept statt RPC-Konzept

SOAP Request Enthält neben Protocol Header auch ein XML-Dokument, welches die aufzurufende Methode und Parameter enthält Die Spezifikation definiert nur die Verbindung von SOAP mit dem HTTP-POST-Request Als Content-Typ muss ‘‘text/xml“ angegeben werden

Der HTTP-Header Das SOAPAction-Feld im http-Header identifiziert den Zweck dieses SOAP-HTTP-Requests. Wert ist ein URI Ein HTTP-Client, der einen Request senden will, muss dieses Header-Feld benutzen Bsp.: SOAPAction: http://.... SOAPAction: “doit.exe“ SOAPAction: ““ SOAPAction:

Content-Type: text/xml Content-Length: 152 SOAPAction: "Some-URI" Objektendpunktkennung POST /Object HTTP/1.1 Host:www.sampleserver.com Content-Type: text/xml Content-Length: 152 SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOPA-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m"Some-URI"> <symbol>DEF</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Maschinenadresse Schnittstelle SOAP-Nutzlast

SOAP Response Ist in etwa gleich aufgebaut. Zuerst werden HTTP-Protokoll Informationen ausgegeben. Keine SOAP spezifischen Angaben im Header nötig, da nur eine Antwort zurückgesendet wird.

HTTP/1.1 200 OK Content-Type: text/xml Content-Length: 152 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOPA-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Gliederung Was ist SOAP? SOAP und XML Nachrichten Datentypen bei SOAP SOAP Transporte RPCs über SOAP Sicherheit Fazit

Sicherheit (1) Kein sicheres Protokoll, da Daten im Klartext übersandt werden. Sicherheit war kein Design-Ziel Keine Datenschutz-, Authentifizierungs- und Autorisierungs-Mechanismen. Funktionen müssen entweder die Übertragungsprotokolle abdecken oder die kommunizierenden Programme

Sicherheit (2) SOAP über HTTPS HTTPS nutzt den Secure Socket Layer (SSL) Relativ sichere Transaktionen Alle Daten, die über HTTP versendet werden, können auch mittels HTTPS übertragen werden SSL verwendet Verschlüsselung

Funktionale Vorteile von SOAP Programmiersprachenunabhängig Betriebssystemunabhängig Plattformunabhängig Keine Beeinträchtigung durch Firewalls Breite Unterstützung, weil viele große Firmen an der Entwicklung mitarbeiten. Definiert Standard, für den sich kostengünstig, einfach und schnell Anwendungen implementieren lassen.

Technische Vorteile von SOAP Einfache Technologie Erweiterbar Benutzt industrieweite Standards: XML, HTTP, SMTP, FTP Stellt die Trennung von Inhalt und Struktur sicher

Nachteile von SOAP SOAP ist äußerst unsicher Noch immer keine vollständige Interoperabilität Große Nachrichten, weil nur Werte gespeichert werden und keine Referenzen Geringere Performance als andere RPC SOAP ist (nur) ein Netzwerkprotokoll und keine komplette verteilte Objektarchitektur.

Zusammenfassung SOAP ist ein Kommunikations-Protokoll SOAP ist eine Erweiterung von XML-RPCs SOAP-Nachrichten müssen einen SOAP- Envelope-Element haben SOAP-Nachrichten können einen SOAP-Header haben SOAP-Nachrichten müssen einen SOAP-Body haben HTTP übernimmt den Transport einer Nachricht

Fazit Soap kann und will keinen völlig neuen Ansatz zur Datenübertragung zwischen zwei Systemen bieten. SOAP setzt auf existierender, standardisierter Internet-Technologie auf.

SOAP sollte nicht eingesetzt werden... In homogenen Umgebungen. In Umgebungen, die hohe Performance erfordern In Szenarios, die einen hohen Sicherheitsbedarf mit sich bringen. In Umgebungen, die von einer Person administriert werden.

SOAP empfielt sich einzusetzen... Wenn es um die Kommunikation verschiedener Systeme aus unterschiedlichen Umgebungen über das Internet geht. Einsatzmöglichkeiten sind uneingeschränkt Microsoft BizTalk Server 2000 Microsoft VisualStudio.NET Microsoft hat ein ToolKit herausgegeben, um bereits in VisualStudio 6 SOAP-Anwendungen zu schreiben Überall dort einsetzbar, wo DCOM und IIOP bereits jetzt ihren Dienst verrichten.

BizTalk Industrieinitiative unter der Führung von MS Ziel: Standards zur Kommunikation zwischen Anwendungen und Organisationen auf Basis aktueller XML-Technologien Anwendung: Austausch von Geschäftsnachrichten Techniken: aktuelle XML-Technologien und Standards (siehe www.biztalk.org)

Zukunft von Soap Microsoft:VisualStudio.Net erstellt fast auf Knopfdruck die Webservices IBM: erweitert XML Parsing Engin, um Soap-Nachrichten parsen zu können SUN:Enterprise Java Beans sollen in der Zukunft über SOAP kommunizieren können

Vielen Dank für Ihre Aufmerksamkeit!