Tutorial zu SOAP-Webdiensten: Was ist das SOAP-Protokoll? BEISPIEL (2024)

Was ist SOAP?

SOAP ist ein XML-basiertes Protokoll für den Zugriff auf Webdienste über HTTP. Es verfügt über einige Spezifikationen, die für alle Anwendungen verwendet werden können.

SOAP ist als Simple Object Access Protocol bekannt, wurde später jedoch nur noch zu SOAP v1.2 verkürzt. SOAP ist ein Protokoll oder anders ausgedrückt eine Definition, wie Webdienste miteinander oder mit Client-Anwendungen kommunizieren, die sie aufrufen.

SOAP wurde als Zwischensprache entwickelt, damit Anwendungen, die auf verschiedenen Programmiersprachen basieren, problemlos miteinander kommunizieren können und der extreme Entwicklungsaufwand vermieden wird.

SOAP-Einführung

In der heutigen Welt gibt es eine große Anzahl von Anwendungen, die auf verschiedenen Programmiersprachen basieren. Beispielsweise könnte es eine Webanwendung geben, die in Java, ein weiteres in .Net und ein weiteres in PHP.

Der Datenaustausch zwischen Anwendungen ist in der heutigen vernetzten Welt von entscheidender Bedeutung. Der Datenaustausch zwischen diesen heterogenen Anwendungen wäre jedoch komplex. Dies gilt auch für die Komplexität des Codes, der diesen Datenaustausch ermöglicht.

Eine Methode zur Bekämpfung dieser Komplexität besteht darin, XML (Extensible Markup Language) als Zwischensprache für den Datenaustausch zwischen Anwendungen zu verwenden.

Jede Programmiersprache kann die XML-Auszeichnungssprache verstehen. Daher wurde XML als zugrunde liegendes Medium für den Datenaustausch verwendet.

Es gibt jedoch keine einheitlichen Vorgaben für den programmiersprachenübergreifenden Einsatz von XML für den Datenaustausch. Hier kommt die SOAP-Software ins Spiel.

SOAP wurde für die Arbeit mit XML über HTTP entwickelt und verfügt über eine Art Spezifikation, die in allen Anwendungen verwendet werden kann. In den folgenden Kapiteln werden wir uns das SOAP-Protokoll genauer ansehen.

Vorteile von SOAP

SOAP ist das Protokoll, das für den Datenaustausch zwischen Anwendungen verwendet wird. Nachfolgend sind einige Gründe aufgeführt, warum SOAP verwendet wird.

• Wenn Sie SOAP-basierte Webdienste entwickeln, benötigen Sie eine Sprache, die Webdienste für die Kommunikation mit Clientanwendungen verwenden können. SOAP ist das perfekte Medium, das entwickelt wurde, um diesen Zweck zu erreichen. Dieses Protokoll wird auch vom W3C-Konsortium empfohlen, dem Dachgremium für alle Webstandards.
• SOAP ist ein leichtgewichtiges Protokoll, das für den Datenaustausch zwischen Anwendungen verwendet wird. Beachten Sie das Schlüsselwort '!.' Da die SOAP-Programmierung auf der XML-Sprache basiert, die selbst eine leichte Datenaustauschsprache ist, fällt SOAP als Protokoll ebenfalls in dieselbe Kategorie.
• SOAP ist plattformunabhängig und betriebssystemunabhängig. Das SOAP-Protokoll kann also mit allen programmiersprachenbasierten Anwendungen auf beiden Plattformen verwendet werden. Windows und Linux Plattform.
• Es funktioniert mit dem HTTP-Protokoll – SOAP funktioniert mit dem HTTP-Protokoll, dem Standardprotokoll, das von allen Webanwendungen verwendet wird. Daher ist keine Anpassung erforderlich, um die auf dem SOAP-Protokoll basierenden Webdienste auszuführen und im World Wide Web zu funktionieren.

SOAP-Bausteine

Die SOAP-Spezifikation definiert etwas, das als „SOAP-Nachricht” was an den Webdienst und die Clientanwendung gesendet wird.

Das folgende Diagramm der SOAP-Architektur zeigt die verschiedenen Bausteine ​​einer SOAP-Nachricht.

Die SOAP-Nachricht ist nichts anderes als ein bloßes XML-Dokument, das die folgenden Komponenten enthält.

• Ein Envelope-Element, das das XML-Dokument als SOAP-Nachricht identifiziert – Dies ist der enthaltene Teil der SOAP-Nachricht und wird verwendet, um alle Details in der SOAP-Nachricht einzukapseln. Dies ist das Stammelement in der SOAP-Nachricht.
• Ein Header-Element, das Header-Informationen enthält – Das Header-Element kann Informationen wie Authentifizierungsdaten enthalten, die von der aufrufenden Anwendung verwendet werden können. Es kann auch die Definition komplexer Typen enthalten, die in der SOAP-Nachricht verwendet werden könnten. Standardmäßig kann die SOAP-Nachricht Parameter enthalten, die einfache Typen wie Zeichenfolgen und Zahlen, aber auch komplexe Objekttypen sein können.

Unten wird ein einfaches SOAP-Dienstbeispiel eines komplexen Typs angezeigt.

Angenommen, wir möchten einen strukturierten Datentyp senden, der eine Kombination aus einem „Tutorial-Namen“ und einem „Tutorial Description“, dann würden wir den komplexen Typ wie unten gezeigt definieren.

Der komplexe Typ wird durch das Element-Tag definiert In der komplexen Typsammlung werden dann alle benötigten Elemente der Struktur mit ihren jeweiligen Datentypen definiert.

<xsd:complexType> <xsd:sequence> <xsd:element name="Tutorial Name" type="string"/> <xsd:element name="Tutorial Description" type="string"/> </xsd:sequence></xsd:complexType>

• Ein Body-Element, das Aufruf- und Antwortinformationen enthält – Dieses Element enthält die eigentlichen Daten, die zwischen dem Webdienst und der aufrufenden Anwendung gesendet werden müssen. Unten sehen Sie ein SOAP-Webdienstbeispiel für den SOAP-Body, der tatsächlich mit dem im Header-Abschnitt definierten komplexen Typ funktioniert. Hier ist die Antwort des Tutorial-Namens und des Tutorials DescriptIonen, die an die aufrufende Anwendung gesendet wird, die diesen Webdienst aufruft.

<soap:Body> <GetTutorialInfo><TutorialName>Web Services</TutorialName> <TutorialDescription>All about web services</TutorialDescription> </GetTutorialInfo></soap:Body>

SOAP-Nachrichtenstruktur

Zu beachten ist, dass SOAP-Nachrichten normalerweise automatisch vom Webdienst generiert werden, wenn dieser aufgerufen wird.

Wenn eine Client-Anwendung eine Methode im Webdienst aufruft, generiert der Webdienst automatisch eine SOAP-Nachricht mit den erforderlichen Details der Daten, die vom Webdienst an die Client-Anwendung gesendet werden.

Wie im vorherigen Thema dieses SOAP-Tutorials erläutert, enthält eine einfache SOAP-Nachricht die folgenden Elemente:

• Das Envelope-Element
• Das Header-Element und
• Das Körperelement
• Das Fault-Element (optional)

Schauen wir uns unten ein Beispiel einer einfachen SOAP-Nachricht an und sehen, was das Element tatsächlich tut.

1. Wie aus der obigen SOAP-Nachricht hervorgeht, ist der erste Teil der SOAP-Nachricht das Umschlagelement, das zum Kapseln der gesamten SOAP-Nachricht verwendet wird.
2. Das nächste Element ist der SOAP-Text, der die Details der eigentlichen Nachricht enthält.
3. Unsere Nachricht enthält einen Webdienst mit dem Namen „Guru99WebService“.
4. Der „Guru99Webservice“ akzeptiert einen Parameter vom Typ „int“ und hat den Namen TutorialID.

Jetzt wird die obige SOAP-Nachricht zwischen dem Webdienst und der Clientanwendung weitergeleitet.

Sie können sehen, wie nützlich die oben genannten Informationen für die Clientanwendung sind. Die SOAP-Nachricht teilt der Clientanwendung mit, wie der Webdienst heißt, welche Parameter er erwartet und welchen Typ jeder Parameter vom Webdienst übernimmt.

SOAP-Umschlagelement

Der erste Teil des Bausteins ist der SOAP-Umschlag.

Der SOAP-Umschlag wird verwendet, um alle notwendigen Details der SOAP-Nachrichten zu kapseln, die zwischen dem Webdienst und der Client-Anwendung ausgetauscht werden.

Das SOAP-Envelope-Element wird verwendet, um den Anfang und das Ende einer SOAP-Nachricht anzuzeigen. Dadurch kann die Clientanwendung, die den Webdienst aufruft, wissen, wann die SOAP-Nachricht endet.

Zum SOAP-Envelope-Element sind folgende Hinweise zu beachten.

• Jede SOAP-Nachricht muss über ein Root-Envelope-Element verfügen. Es ist unbedingt erforderlich, dass eine SOAP-Nachricht ein Umschlagelement enthält.
• Jedes Umschlagelement muss mindestens ein Seifenkörperelement haben.
• Wenn ein Envelope-Element ein Header-Element enthält, darf es nicht mehr als eines enthalten und muss als erstes untergeordnetes Element des Envelope vor dem Body-Element erscheinen.
• Der Umschlag ändert sich, wenn sich die SOAP-Versionen ändern.
• Ein v1.1-kompatibler SOAP-Prozessor generiert einen Fehler, wenn er eine Nachricht empfängt, die den v1.2-Envelope-Namespace enthält.
• Ein v1.2-kompatibler SOAP-Prozessor generiert einen Versionskonfliktfehler, wenn er eine Nachricht empfängt, die den v1.2-Envelope-Namespace nicht enthält.

Unten finden Sie ein SOAP-API-Beispiel für Version 1.2 des SOAP-Envelope-Elements.

<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle=" http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <Guru99WebService xmlns="http://tempuri.org/"> <TutorialID>int</TutorialID> </Guru99WebService> </soap:Body></SOAP-ENV:Envelope>

Die Fehlermeldung

Wenn eine Anfrage an einen SOAP-Webdienst gestellt wird, kann die zurückgegebene Antwort entweder zwei Formen annehmen: eine erfolgreiche Antwort oder eine Fehlerantwort. Wenn ein Erfolg generiert wird, ist die Antwort vom Server immer eine SOAP-Nachricht. Wenn jedoch SOAP-Fehler generiert werden, werden diese als „HTTP 2“-Fehler zurückgegeben.

Die SOAP-Fehlermeldung besteht aus den folgenden Elementen.

1. – Dies ist der Code, der den Code des Fehlers bezeichnet. Der Fehlercode kann einen der folgenden Werte haben
   1. SOAP-ENV:VersionMismatch – Dies ist der Fall, wenn ein ungültiger Namespace für das SOAP-Envelope-Element festgestellt wird.
   2. SOAP-ENV:MustUnderstand – Ein unmittelbar untergeordnetes Element des Header-Elements, dessen Attribut „mustUnderstand“ auf „1“ gesetzt ist, wurde nicht verstanden.
   3. SOAP-ENV:Client – ​​Die Nachricht war falsch formatiert oder enthielt falsche Informationen.
   4. SOAP-ENV:Server – Es gab ein Problem mit dem Server, daher konnte die Nachricht nicht fortgesetzt werden.
2. – Dies ist die Textnachricht, die eine detaillierte Beschreibung des Fehlers enthält.
3. (Optional)– Dies ist eine Textzeichenfolge, die angibt, wer den Fehler verursacht hat.
4. (Optional) – Dies ist das Element für anwendungsspezifische Fehlermeldungen. Daher könnte die Anwendung eine bestimmte Fehlermeldung für verschiedene Geschäftslogikszenarien haben.

Beispiel für Fehlermeldung

Nachfolgend finden Sie ein Beispiel für eine Fehlermeldung. Der Fehler wird generiert, wenn der Client versucht, eine Methode namens TutorialID in der Klasse GetTutorial zu verwenden.

Die folgende Fehlermeldung wird generiert, wenn die Methode in der definierten Klasse nicht vorhanden ist.

<?xml version='1.0' encoding='UTF-8'?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode> <faultstring xsi:type="xsd:string"> Failed to locate method (GetTutorialID) in class (GetTutorial) </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Ausgang:

Wenn Sie den obigen Code ausführen, wird ein Fehler wie „Fehler beim Auffinden der Methode (GetTutorialID) in der Klasse (GetTutorial)“ angezeigt.

SOAP-Kommunikationsmodell

Die gesamte Kommunikation per SOAP erfolgt über das HTTP-Protokoll. Vor SOAP viele Web-Services verwendete den Standard-RPC-Stil (Remote Procedure Call) für die Kommunikation. Dies war die einfachste Art der Kommunikation, hatte jedoch viele Einschränkungen.

Betrachten wir nun in diesem SOAP-API-Tutorial das folgende Diagramm, um zu sehen, wie diese Kommunikation funktioniert. Nehmen wir in diesem Beispiel an, dass der Server einen Webdienst hostet, der zwei Methoden bereitstellt:

• GetEmployee – Dadurch werden alle Mitarbeiterdaten abgerufen
• SetEmployee – Dadurch wird der Wert der Details wie Mitarbeiterabteilung, Gehalt usw. entsprechend festgelegt.

Bei der normalen Kommunikation im RPC-Stil würde der Client einfach die Methoden in seiner Anfrage aufrufen und die erforderlichen Parameter an den Server senden, und der Server würde dann die gewünschte Antwort senden.

Das obige Kommunikationsmodell weist die folgenden schwerwiegenden Einschränkungen auf

1. Nicht sprachunabhängig – Der Server, der die Methoden hostet, wäre in einer bestimmten Programmiersprache und normalerweise würden die Aufrufe an den Server nur in dieser Programmiersprache erfolgen.
2. Nicht das Standardprotokoll – Beim Aufruf der Remote-Prozedur erfolgt der Aufruf nicht über das Standardprotokoll. Dies war ein Problem, da größtenteils die gesamte Kommunikation über das Web über das HTTP-Protokoll erfolgen musste.
3. Firewalls – Da RPC-Aufrufe nicht über das normale Protokoll erfolgen, müssen auf dem Server separate Ports geöffnet sein, damit der Client mit dem Server kommunizieren kann. Normalerweise blockieren alle Firewalls diese Art von Datenverkehr und im Allgemeinen waren umfangreiche Konfigurationsschritte erforderlich, um sicherzustellen, dass diese Art der Kommunikation zwischen dem Client und dem Server funktioniert.

Um alle oben genannten Einschränkungen zu überwinden, würde SOAP dann das folgende Kommunikationsmodell verwenden

1. Der Client formatiert die Informationen zum Prozeduraufruf und etwaige Argumente in einer SOAP-Nachricht und sendet sie als Teil einer HTTP-Anfrage an den Server. Dieser Prozess der Kapselung der Daten in einer SOAP-Nachricht wurde als bezeichnet Marshalling.
2. Der Server entpackt dann die vom Client gesendete Nachricht, prüft, was der Client angefordert hat, und sendet dann die entsprechende Antwort als SOAP-Nachricht an den Client zurück. Die Praxis, eine vom Client gesendete Anfrage auszupacken, wird als bezeichnet Demarshalling.

Praktisches SOAP-Beispiel

Sehen wir uns nun in diesem SoapUI-Tutorial ein praktisches SOAP-Beispiel an:

Eine der besten Möglichkeiten, zu sehen, wie SOAP-Nachrichten generiert werden, besteht wahrscheinlich darin, einen Webdienst tatsächlich in Aktion zu sehen.

In diesem Thema geht es um die Verwendung von Microsoft.Net-Framework zum Erstellen eines ASMX-Webdienstes. Diese Art von Webdienst unterstützt sowohl SOAP Version 1.1 als auch Version 1.2.

ASMX-Webdienste generieren automatisch die Web Service Definition Language (WSDL) dokumentieren. Dieses WSDL-Dokument wird von der aufrufenden Clientanwendung benötigt, damit die Anwendung weiß, wozu der Webdienst in der Lage ist.

In unserem Beispiel erstellen wir einen einfachen Webdienst, der verwendet wird, um eine Zeichenfolge an die Anwendung zurückzugeben, die den Webdienst aufruft.

Dieser Webdienst wird in einem gehostet Asp.Net Internetanwendung. Anschließend rufen wir den Webdienst auf und sehen das Ergebnis, das vom Webdienst zurückgegeben wird.

Visual Studio zeigt uns auch die SOAP-Nachricht, die zwischen dem Webdienst und der aufrufenden Anwendung übergeben wird.

Die erste Voraussetzung für die Einrichtung unserer Webdienstanwendung ist die Befolgung der folgenden Schritte.

Stellen Sie für dieses Beispiel sicher, dass Visual Studio 2013 auf Ihrem System installiert ist.

Schritt 1) Der erste Schritt besteht darin, eine leere ASP.Net-Webanwendung zu erstellen. Klicken Sie in Visual Studio 2013 auf die Menüoption Datei->Neues Projekt.

Sobald Sie auf die Option „Neues Projekt“ klicken, öffnet Visual Studio ein weiteres Dialogfeld, in dem Sie den Projekttyp auswählen und die erforderlichen Projektdetails eingeben können. Dies wird im nächsten Schritt erläutert.

Schritt 2) In diesem Schritt

1. Stellen Sie sicher, dass Sie zuerst Folgendes auswählen C# Webvorlage einer ASP.NET-Webanwendung. Das Projekt muss von diesem Typ sein, um ein SOAP-Dienstprojekt zu erstellen. Wenn Sie diese Option wählen, führt Visual Studio die erforderlichen Schritte aus, um die erforderlichen Dateien hinzuzufügen, die von jeder webbasierten Anwendung benötigt werden.
2. Geben Sie Ihrem Projekt einen Namen, in unserem Fall webservice.asmx. Stellen Sie dann sicher, dass Sie einen Speicherort für die Projektdateien angeben.

Sobald dies erledigt ist, sehen Sie die erstellte Projektdatei in Ihrem Lösungs-Explorer in Visual Studio 2013.

Schritt 3) In diesem Schritt

Wir werden unserem Projekt eine Webdienstdatei hinzufügen

1. Klicken Sie zunächst mit der rechten Maustaste auf die Projektdatei, wie unten gezeigt

2. Sobald Sie mit der rechten Maustaste auf die Projektdatei klicken, haben Sie die Möglichkeit, die Option „Hinzufügen->Webdienst (ASMX)“ auszuwählen, um eine Webdienstdatei hinzuzufügen. Geben Sie einfach den Namen „Tutorial Service“ für die Webdienst-Namensdatei an.

Schritt 4) Fügen Sie Ihrer Tutorial Service-ASMX-Datei den folgenden Code hinzu.

Code-Erklärung:

1. Diese Codezeile stellt einen Namen für Ihre Webdienstdatei bereit. Dies ist ein wichtiger Schritt, da er der Clientanwendung die Möglichkeit gibt, den Webdienst über den Namen des Webdiensts aufzurufen.
2. Normalerweise wird eine Klassendatei verwendet, um die Funktionalität eines Webdienstes zu kapseln. Die Klassendatei enthält also die Definition aller Webmethoden, die der Clientanwendung einige Funktionen bereitstellen.
3. Hier wird [WebMethod] als Attribut bezeichnet, das eine Funktion beschreibt. Im darauffolgenden Schritt wird eine Funktion mit dem Namen „Guru99WebService“ erstellt. Durch das Hinzufügen dieses Schritts zum Hinzufügen eines [WebMethod]-Attributs wird jedoch sichergestellt, dass diese Methode von einer Clientanwendung aufgerufen werden kann. Wenn dieses Attribut nicht vorhanden ist, kann die Methode niemals von einer Clientanwendung aufgerufen werden.
4. Hier definieren wir eine Funktion namens „Guru99WebService“, die verwendet wird, um eine Zeichenfolge an die aufrufende Clientanwendung zurückzugeben. Bei dieser Funktion handelt es sich um einen Webdienst, der von jeder Clientanwendung aufgerufen werden kann.
5. Wir verwenden die Return-Anweisung, um die Zeichenfolge „Dies ist ein Guru99-Webdienst“ an die Clientanwendung zurückzugeben.

Wenn der Code erfolgreich ausgeführt wird, wird die folgende Ausgabe angezeigt, wenn Sie Ihren Code im Browser ausführen.

Ausgang:

• Die Ausgabe zeigt deutlich, dass der Name unseres Webdienstes „Guru99 Web Service“ lautet, was das Ergebnis der Namensgebung für unseren Webdienst ist.
• Wir können auch sehen, dass wir den Webdienst aufrufen können. Wenn wir auf die Schaltfläche „Invoke“ klicken, erhalten wir die folgende Antwort im Webbrowser.

Die obige Ausgabe,

• Es zeigt deutlich, dass durch den Aufruf der Webmethode die Zeichenfolge „Dies ist ein Guru99-Webdienst“ zurückgegeben wird.
• Visual Studio ermöglicht Ihnen außerdem die Anzeige der SOAP-Nachrichtenanforderung und -antwort, die generiert wird, wenn der oben genannte Webdienst aufgerufen wird.

Die SOAP-Anfrage, die beim Aufruf des Webservices generiert wird, ist unten dargestellt.

Code-Erklärung:

1. Der erste Teil der SOAP-Nachricht ist das Umschlagelement, das in den vorherigen Kapiteln besprochen wurde. Dies ist das Kapselungselement, das in jeder SOAP-Nachricht vorhanden ist.
2. Der SOAP-Body ist das nächste Element und enthält die eigentlichen Details der SOAP-Nachricht.
3. Der dritte Teil ist das Element, das angibt, dass wir den Dienst namens „Guru99WebService“ aufrufen möchten.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <Guru99WebServiceResponse xmlns="http://tempuri.org/"> <Guru99WebServiceResult>string</Guru99WebServiceResult> </Guru99WebServiceResponse> </soap:Body></soap:Envelope>

Code-Erklärung:

1. Der erste Teil der SOAP-Nachricht ist das Umschlagelement, das in den vorherigen Kapiteln besprochen wurde. Dies ist das Kapselungselement, das in jeder SOAP-Nachricht vorhanden ist.
2. Der SOAP-Body ist das nächste Element und enthält die eigentlichen Details der SOAP-Nachricht.
3. Der interessante Teil, den Sie jetzt sehen werden, ist das Attribut „String“. Dies teilt der Client-Anwendung mit, dass der aufgerufene Webdienst ein Objekt vom Typ „String“ zurückgibt. Dies ist sehr nützlich, da die Client-Anwendung sonst nicht wüsste, was der Webdienst zurückgibt.

Zusammenfassung

• SOAP ist ein Protokoll, das zum Datenaustausch zwischen Anwendungen verwendet wird, die auf unterschiedlichen Anwendungen basieren Programmiersprachen.
• SOAP basiert auf der XML-Spezifikation und arbeitet mit dem HTTP-Protokoll. Dies macht es ideal für den Einsatz in Webanwendungen.
• Die SOAP-Bausteine ​​bestehen aus einer SOAP-Nachricht. Jede SOAP-Nachricht besteht aus einem Envelope-Element, einem Header und einem Body-Element.
• Das Umschlagelement ist das obligatorische Element in der SOAP-Nachricht und wird verwendet, um alle Daten in der SOAP-Nachricht zu kapseln.
• Das Header-Element kann verwendet werden, um Informationen wie Authentifizierungsinformationen oder die Definition komplexer Datentypen aufzunehmen.
• Das Body-Element ist das Hauptelement, das die Definition der Webmethoden sowie bei Bedarf alle Parameterinformationen enthält.