Aufgabe 13 - SOAP von Hand: eine Anfrage bauen und die WSDL lesen

Aufgabe 13 - SOAP von Hand: eine Anfrage bauen und die WSDL lesen

Worum geht es?

Sie schicken einmal im Leben eine SOAP-Nachricht von Hand ab und lesen den Vertrag, der dahintersteht (siehe Kapitel Schnittstellen im Vergleich). Sie werden SOAP in Ihrem Jahresprojekt nicht verwenden. Sie sollen es aber gesehen haben, weil es in Banken, Versicherungen und Behörden läuft und weil der Vertragsgedanke dahinter das ist, was Sie sich mit OpenAPI zurückholen.

Was Sie dafür brauchen

• Kapitel Schnittstellen im Vergleich, Abschnitt SOAP.
• curl und einen Texteditor.
• Einen öffentlichen SOAP-Dienst zum Ausprobieren. Ihre Lehrkraft nennt Ihnen einen; sonst eignen sich frei zugängliche Testdienste mit einfacher Rechen- oder Länderabfrage.

Welche Kompetenzen Sie erwerben und zeigen

• Sie beschreiben den Aufbau einer SOAP-Nachricht und benennen die Rolle von Envelope, Header und Body.
• Sie lesen aus einer WSDL heraus, welche Operationen ein Dienst anbietet und welche Typen sie erwarten.
• Sie erklären den Unterschied zwischen Transportsicherheit und Nachrichtensicherheit.

Pädagogische Einordnung

• Reproduktion: die Bestandteile einer SOAP-Nachricht benennen und eine vorgegebene Anfrage absenden (Teil A).
• Reorganisation und Transfer: eine WSDL lesen und daraus eine eigene Anfrage bauen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: SOAP und REST gegenüberstellen und die Wahl begründen (Teil C).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Eine fertige Nachricht absenden

1. Kopieren Sie die SOAP-Nachricht aus dem Kapitel in eine Datei request.xml. Beschriften Sie in einer Kopie die drei Bestandteile Envelope, Header und Body mit Kommentaren.

2. Beantworten Sie in je einem Satz: Welcher der drei Bestandteile ist verpflichtend, welcher optional, und was steht üblicherweise im optionalen?

3. Schicken Sie die Anfrage an den Dienst, den Ihre Lehrkraft nennt:

   curl -X POST https://dienst.example.at/service \
     -H "Content-Type: application/soap+xml; charset=utf-8" \
     --data @request.xml

   Speichern Sie die Antwort in einer Datei und notieren Sie den HTTP-Statuscode.

4. Erzeugen Sie einen Fehler, indem Sie in Ihrer Anfrage einen Wert ungültig machen, etwa eine Zahl durch Text ersetzen. Schicken Sie sie erneut ab und speichern Sie die Antwort.

5. Sehen Sie sich beide Antworten nebeneinander an. Notieren Sie den HTTP-Statuscode der Fehlerantwort und die Stelle im XML, an der der Fehler steht. Erklären Sie in zwei bis drei Sätzen, warum ein Aufrufer bei SOAP den Rumpf lesen muss, um Erfolg von Misserfolg zu unterscheiden.

Teil B - Die WSDL lesen

1. Rufen Sie die WSDL des Dienstes ab, meist über die Adresse des Dienstes mit angehängtem ?wsdl. Speichern Sie sie als Datei.

2. Suchen Sie in der WSDL drei Dinge und notieren Sie zu jedem die Zeilennummer: die Liste der angebotenen Operationen, die Adresse, unter der der Dienst erreichbar ist, und die Definition eines Datentyps.

3. Legen Sie eine Tabelle der Operationen an, mit den Spalten Operation, Eingabe, Ausgabe. Drei Operationen genügen, wenn der Dienst mehr anbietet.

4. Wählen Sie eine Operation aus, die Sie in Teil A noch nicht aufgerufen haben. Bauen Sie die Anfrage dafür selbst, nur anhand der WSDL, und schicken Sie sie ab. Notieren Sie die Antwort.

5. Suchen Sie im Typteil der WSDL eine Einschränkung, also ein Pflichtfeld, einen Wertebereich oder eine Musterprüfung. Notieren Sie sie und beschreiben Sie in zwei Sätzen, was passiert, wenn Sie dagegen verstoßen. Probieren Sie es aus.

6. Beantworten Sie in drei bis vier Sätzen: Was leistet die WSDL, das eine Beschreibung in Prosa nicht leistet? Gehen Sie dabei auf die Codegenerierung ein.

Teil C - Einordnen und begründen

1. Übertragen Sie die Vergleichstabelle aus dem Kapitel in Ihre Unterlagen und füllen Sie in einer dritten Spalte für jede der neun Zeilen aus, wie sich der von Ihnen aufgerufene Dienst tatsächlich verhalten hat. Wo Sie es nicht prüfen konnten, schreiben Sie „nicht geprüft”.

2. TLS und WS-Security schützen beide etwas, aber nicht dasselbe. Zeichnen Sie eine Kette aus vier Systemen: Absender, zwei Zwischenstationen, Empfänger. Markieren Sie einmal, welche Abschnitte TLS schützt, und einmal, was WS-Security schützt. Erklären Sie den Unterschied darunter in vier bis fünf Sätzen.

3. Beschreiben Sie eine Situation aus Ihrem eigenen Umfeld, in der die Nachrichtensicherheit den Unterschied machen würde. Ein Zeugnis, das über drei Stellen weitergereicht wird, oder eine Überweisung, die ein Dienstleister weiterleitet, sind brauchbare Beispiele.

4. Nennen Sie drei Situationen, in denen SOAP die sachlich bessere Wahl ist als REST, und schreiben Sie zu jeder einen Satz Begründung.

5. Beantworten Sie in vier bis fünf Sätzen, warum SOAP für Ihr eigenes Jahresprojekt nicht in Frage kommt. Nennen Sie mindestens zwei konkrete Nachteile, die Sie in dieser Übung selbst bemerkt haben.

6. Schreiben Sie zum Schluss in drei Sätzen auf, was Sie aus SOAP für Ihre eigene Schnittstelle mitnehmen. Der Satz „SOAP ist alt” gilt dabei nicht als Antwort.

Wissenscheck

1. Aus welchen Teilen besteht eine SOAP-Nachricht, und welcher davon ist verpflichtend?
2. Wo steht bei SOAP der Fehler, und warum interessiert der HTTP-Statuscode dabei wenig?
3. Was beschreibt eine WSDL, und was lässt sich daraus erzeugen?
4. Was ist der Unterschied zwischen Transportsicherheit und Nachrichtensicherheit?
5. Warum funktioniert SOAP auch über andere Transportwege als HTTP?
6. Nennen Sie zwei Gründe, warum SOAP-Nachrichten größer sind als vergleichbare JSON-Antworten.
7. Was ist mit dem Vertragsgedanken gemeint, und wo taucht er in der REST-Welt wieder auf?

Abgabe

Eine Datei protokoll.md mit den beschrifteten Nachrichten, den gespeicherten Antworten aus Teil A, der Operationstabelle und der selbst gebauten Anfrage aus Teil B sowie der ausgefüllten Vergleichstabelle, der Skizze zur Nachrichtensicherheit und den Begründungen aus Teil C. Die verwendeten XML-Dateien liegen daneben.