SOAP Web Services Tutorial: Was ist das SOAP-Protokoll? BEISPIEL

Was ist SOAP?

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

SOAP ist als Simple Object Access Protocol bekannt, wurde jedoch in späteren Zeiten nur auf SOAP v1.2 verkürzt. SOAP ist ein Protokoll oder mit anderen Worten eine Definition, wie Webdienste miteinander oder mit Clientanwendungen kommunizieren, die sie aufrufen.

SOAP wurde als Zwischensprache entwickelt, damit Anwendungen, die auf verschiedenen Programmiersprachen basieren, problemlos miteinander kommunizieren und den extremen Entwicklungsaufwand vermeiden können.

In diesem Tutorial zu SOAP-Webdiensten lernen Sie:

SOAP Einführung
Vorteile von SOAP
SOAP-Bausteine
SOAP-Nachrichtenstruktur
SOAP-Umschlagelement
SOAP-Kommunikationsmodell
Praktisches SOAP-Beispiel

SOAP Einführung

In der heutigen Welt gibt es eine Vielzahl von Anwendungen, die auf verschiedenen Programmiersprachen basieren. Beispielsweise könnte es eine Webanwendung geben, die in Java entwickelt wurde, eine andere in .Net und eine andere 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, um diesen Datenaustausch durchzuführen.

Eine der Methoden zur Bekämpfung dieser Komplexität ist die Verwendung von XML (Extensible Markup Language) als Zwischensprache für den Datenaustausch zwischen Anwendungen.

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

Es gibt jedoch keine Standardspezifikationen für die Verwendung von XML in allen Programmiersprachen 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 Spezifikation, die für alle Anwendungen verwendet werden kann. Wir werden in den folgenden Kapiteln weitere Details zum SOAP-Protokoll untersuchen.

Vorteile von SOAP

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

Wenn Sie SOAP-basierte Webdienste entwickeln, benötigen Sie eine Sprache, die für Webdienste verwendet werden kann, um mit Clientanwendungen zu kommunizieren. SOAP ist das perfekte Medium, das entwickelt wurde, um diesen Zweck zu erreichen. Dieses Protokoll wird auch vom W3C-Konsortium empfohlen, das das Leitungsgremium für alle Webstandards ist.
SOAP ist ein leichtes Protokoll, das für den Datenaustausch zwischen Anwendungen verwendet wird. Beachten Sie das Schlüsselwort " Licht" . 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 alle programmiersprachenbasierten Anwendungen sowohl auf der Windows- als auch auf der Linux-Plattform ausführen.
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 für die Arbeit im World Wide Web auszuführen.

SOAP-Bausteine

Die SOAP-Spezifikation definiert eine sogenannte " SOAP-Nachricht ", die 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 mit den folgenden Komponenten.

Ein Envelope-Element, das das XML-Dokument als SOAP-Nachricht identifiziert - Dies ist der enthaltende Teil der SOAP-Nachricht, mit dem alle Details in der SOAP-Nachricht gekapselt werden. 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önnen. Standardmäßig kann die SOAP-Nachricht Parameter enthalten, die einfache Typen wie Zeichenfolgen und Zahlen sein können, aber auch ein komplexer Objekttyp sein können.

Ein einfaches SOAP-Servicebeispiel eines komplexen Typs ist unten dargestellt.

Angenommen, wir möchten einen strukturierten Datentyp senden, der eine Kombination aus einem "Tutorial-Namen" und einer "Tutorial-Beschreibung" enthält, dann definieren wir den komplexen Typ wie unten gezeigt.

Der komplexe Typ wird durch das Element-Tag definiert. Alle erforderlichen Elemente der Struktur zusammen mit ihren jeweiligen Datentypen werden dann in der komplexen Typensammlung definiert.

Ein Body-Element, das Anruf- und Antwortinformationen enthält - Dieses Element enthält die tatsächlichen Daten, die zwischen dem Webdienst und der aufrufenden Anwendung gesendet werden müssen. Unten finden Sie ein SOAP-Webdienstbeispiel für den SOAP-Body, der tatsächlich mit dem im Header-Abschnitt definierten komplexen Typ arbeitet. Hier ist die Antwort des Tutorial-Namens und der Tutorial-Beschreibung, die an die aufrufende Anwendung gesendet werden, die diesen Webdienst aufruft.

Web ServicesAll about web services

SOAP-Nachrichtenstruktur

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

Wenn eine Clientanwendung eine Methode im Webdienst aufruft, generiert der Webdienst automatisch eine SOAP-Nachricht, die die erforderlichen Details der Daten enthält, die vom Webdienst an die Clientanwendung 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 Fehlerelement (optional)

Schauen wir uns unten ein Beispiel für eine einfache SOAP-Nachricht an und sehen, welches Element tatsächlich funktioniert.

Wie aus der obigen SOAP-Nachricht ersichtlich, ist der erste Teil der SOAP-Nachricht das Hüllkurvenelement, mit dem die gesamte SOAP-Nachricht gekapselt wird.
Das nächste Element ist der SOAP-Body, der die Details der eigentlichen Nachricht enthält.
Unsere Nachricht enthält einen Webdienst mit dem Namen "Guru99WebService".
Der "Guru99Webservice" akzeptiert einen Parameter vom Typ 'int' und hat den Namen TutorialID.

Die obige SOAP-Nachricht wird nun zwischen dem Webdienst und der Clientanwendung übertragen.

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 verwendet wird.

SOAP-Umschlagelement

Das erste Stück des Bausteins ist der SOAP-Umschlag.

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

Das SOAP-Hüllkurvenelement 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.

Die folgenden Punkte können auf dem SOAP-Hüllkurvenelement vermerkt werden.

Jede SOAP-Nachricht muss ein Root-Envelope-Element haben. Für SOAP-Nachrichten ist es unbedingt erforderlich, ein Umschlagelement zu haben.
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 als erstes untergeordnetes Element des Envelope vor dem Body-Element angezeigt werden.
Der Umschlag ändert sich, wenn sich die SOAP-Versionen ändern.
Ein v1.1-kompatibler SOAP-Prozessor generiert einen Fehler beim Empfang einer Nachricht, die den v1.2-Hüllkurven-Namespace enthält.
Ein v1.2-kompatibler SOAP-Prozessor generiert einen Versionskonfliktfehler, wenn er eine Nachricht empfängt, die den v1.2-Umschlag-Namespace nicht enthält.

Unten finden Sie ein SOAP-API-Beispiel für Version 1.2 des SOAP-Hüllkurvenelements.

int

Die Fehlermeldung

Wenn eine Anfrage an einen SOAP-Webdienst gestellt wird, kann die zurückgegebene Antwort entweder zwei Formen haben, bei denen es sich um eine erfolgreiche Antwort oder eine Fehlerantwort handelt. Wenn ein Erfolg generiert wird, ist die Antwort vom Server immer eine SOAP-Nachricht. Wenn jedoch SOAP-Fehler generiert werden, werden diese als "HTTP 500" -Fehler zurückgegeben.

Die SOAP-Fehlermeldung besteht aus den folgenden Elementen.

- Dies ist der Code, der den Code des Fehlers angibt . Der Fehlercode kann einer der folgenden Werte sein
1. SOAP-ENV: VersionMismatch - In diesem Fall wird ein ungültiger Namespace für das SOAP-Envelope-Element festgestellt.
2. SOAP-ENV: MustUnderstand - Ein unmittelbares untergeordnetes Element des Header-Elements mit dem Attribut mustUnderstand auf "1" wurde nicht verstanden.
3. SOAP-ENV: Client - Die Nachricht wurde falsch gebildet oder enthielt falsche Informationen.
4. SOAP-ENV: Server - Es gab ein Problem mit dem Server, sodass die Nachricht nicht fortgesetzt werden konnte.
- Dies ist die Textnachricht, die eine detaillierte Beschreibung des Fehlers enthält.
(optional) - Dies ist eine Textzeichenfolge, die angibt, wer den Fehler verursacht hat.
(Optional) - Dies ist das Element für anwendungsspezifische Fehlermeldungen. Daher kann die Anwendung eine bestimmte Fehlermeldung für verschiedene Geschäftslogikszenarien haben.

Beispiel für eine Fehlermeldung

Ein Beispiel für eine Fehlermeldung ist unten angegeben. Der Fehler wird generiert, wenn der Client versucht, eine Methode namens TutorialID in der Klasse GetTutorial zu verwenden.

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

SOAP-ENV:ClientFailed to locate method (GetTutorialID) in class (GetTutorial)

Ausgabe:

Wenn Sie den obigen Code ausführen, wird der Fehler wie "Methode (GetTutorialID) in Klasse (GetTutorial) konnte nicht gefunden werden" angezeigt.

SOAP-Kommunikationsmodell

Die gesamte Kommunikation über SOAP erfolgt über das HTTP-Protokoll. Vor SOAP verwendeten viele Webdienste 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. In diesem Beispiel wird angenommen, dass der Server einen Webdienst hostet, der zwei Methoden als bereitstellt

GetEmployee - Hiermit werden alle Mitarbeiterdetails abgerufen
SetEmployee - Hiermit wird der Wert der Details wie Mitarbeiterabteilung, Gehalt usw. entsprechend festgelegt.

Bei der normalen Kommunikation im RPC-Stil würde der Client nur die Methoden in seiner Anforderung 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

Nicht sprachunabhängig - Der Server, auf dem die Methoden gehostet werden, befindet sich in einer bestimmten Programmiersprache, und normalerweise werden die Aufrufe des Servers nur in dieser Programmiersprache ausgeführt.
Nicht das Standardprotokoll - Wenn ein Anruf an die Remote-Prozedur getätigt wird, wird der Anruf nicht über das Standardprotokoll ausgeführt. Dies war ein Problem, da die gesamte Kommunikation über das Web über das HTTP-Protokoll erfolgen musste.
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 war viel Konfiguration 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

Der Client formatiert die Informationen zum Prozeduraufruf und alle Argumente in eine SOAP-Nachricht und sendet sie als Teil einer HTTP-Anforderung an den Server. Dieser Prozess der Kapselung der Daten in eine SOAP-Nachricht wurde als Marshalling bezeichnet.
Der Server würde dann die vom Client gesendete Nachricht auspacken, sehen, was der Client angefordert hat, und dann die entsprechende Antwort als SOAP-Nachricht an den Client zurücksenden. Das Auspacken einer vom Client gesendeten Anfrage wird als Demarshalling bezeichnet.

Praktisches SOAP-Beispiel

In diesem SoapUI-Tutorial sehen wir uns ein praktisches SOAP-Beispiel an:

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

In diesem Thema wird die Verwendung des Microsoft.Net-Frameworks zum Erstellen eines ASMX-Webdiensts behandelt. Diese Art von Webdienst unterstützt sowohl SOAP Version 1.1 als auch Version 1.2.

ASMX-Webdienste generieren automatisch das WSDL-Dokument (Web Service Definition Language). 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, mit dem eine Zeichenfolge an die Anwendung zurückgegeben wird, die den Webdienst aufruft.

Dieser Webdienst wird in einer Asp.Net-Webanwendung gehostet. Wir werden dann den Webdienst aufrufen und das Ergebnis sehen, das vom Webdienst zurückgegeben wird.

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

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

Stellen Sie sicher, dass für dieses Beispiel 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, zeigt Visual Studio ein weiteres Dialogfeld an, in dem Sie den Projekttyp auswählen und die erforderlichen Details des Projekts angeben können. Dies wird im nächsten Schritt erklärt.

Schritt 2) In diesem Schritt

Stellen Sie sicher, dass Sie zuerst die C # -Webvorlage der ASP.NET-Webanwendung auswählen. Das Projekt muss von diesem Typ sein, um ein SOAP-Serviceprojekt zu erstellen. Wenn Sie diese Option auswählen, führt Visual Studio die erforderlichen Schritte aus, um die erforderlichen Dateien hinzuzufügen, die für eine webbasierte Anwendung erforderlich sind.
Geben Sie einen Namen für Ihr Projekt an, der in unserem Fall als webservice.asmx angegeben wurde. Stellen Sie dann sicher, dass Sie einen Speicherort angeben, an dem die Projektdateien gespeichert werden.

Anschließend wird die in Ihrem Lösungs-Explorer in Visual Studio 2013 erstellte Projektdatei angezeigt.

Schritt 3) In diesem Schritt

Wir werden unserem Projekt eine Webdienstdatei hinzufügen

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

Sobald Sie mit der rechten Maustaste auf die Projektdatei klicken, können Sie die Option "Hinzufügen-> Webdienst (ASMX)" auswählen, um eine Webdienstdatei hinzuzufügen. Geben Sie einfach einen Namen für den Lerndienstdienst für die Webdienstnamensdatei ein.

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

Code Erläuterung:

Diese Codezeile enthält einen Namen für Ihre Webdienstdatei. Dies ist ein wichtiger Schritt, da die Clientanwendung den Webdienst über den Namen des Webdienstes aufrufen kann.
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 bieten.
Hier ist [WebMethod] als Attribut bekannt, das eine Funktion beschreibt. Im folgenden Schritt wird eine Funktion mit dem Namen "Guru99WebService" erstellt. Durch die Einbeziehung 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.
Hier definieren wir eine Funktion namens 'Guru99WebService', mit der eine Zeichenfolge an die aufrufende Clientanwendung zurückgegeben wird. Diese Funktion ist ein Webdienst, der von jeder Clientanwendung aufgerufen werden kann.
Wir verwenden die return-Anweisung, um die Zeichenfolge "Dies ist ein Guru99-Webdienst" an die Clientanwendung zurückzugeben.

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

Ausgabe:

Die Ausgabe zeigt deutlich, dass der Name unseres Webdienstes "Guru99 Web Service" ist, was das Ergebnis der Angabe eines Namens für unseren Webdienst ist.
Wir können auch sehen, dass wir den Webdienst aufrufen können. Wenn wir auf die Schaltfläche "Aufrufen" klicken, wird im Webbrowser die folgende Antwort angezeigt.

Die obige Ausgabe,

Es zeigt deutlich, dass beim Aufrufen der Webmethode die Zeichenfolge "Dies ist ein Guru99-Webdienst" zurückgegeben wird.
In Visual Studio können Sie auch die SOAP-Nachrichtenanforderung und -antwort anzeigen, die beim Aufrufen des oben genannten Webdiensts generiert wird.

Die SOAP-Anforderung, die beim Aufrufen des Webdienstes generiert wird, wird unten angezeigt.

Code Erläuterung:

Der erste Teil der SOAP-Nachricht ist das Hüllkurvenelement, das in den vorherigen Kapiteln erläutert wurde. Dies ist das Kapselungselement, das in jeder SOAP-Nachricht vorhanden ist.
Der SOAP-Body ist das nächste Element und enthält die tatsächlichen Details der SOAP-Nachricht.
Der dritte Teil ist das Element, das angibt, dass der Dienst "Guru99WebService" aufgerufen werden soll.

string

Code Erläuterung:

Der erste Teil der SOAP-Nachricht ist das Hüllkurvenelement, das in den vorherigen Kapiteln erläutert wurde. Dies ist das Kapselungselement, das in jeder SOAP-Nachricht vorhanden ist.
Der SOAP-Body ist das nächste Element und enthält die tatsächlichen Details der SOAP-Nachricht.
Der interessante Teil, den Sie jetzt sehen werden, ist das Attribut 'string'. Dadurch wird der Clientanwendung mitgeteilt, dass der aufgerufene Webdienst ein Objekt vom Typ string zurückgibt. Dies ist sehr nützlich, da die Client-Anwendung, die sonst nicht wissen würde, was der Webdienst zurückgibt.

Zusammenfassung

SOAP ist ein Protokoll, mit dem Daten zwischen Anwendungen ausgetauscht werden, die auf verschiedenen Programmiersprachen basieren.
SOAP basiert auf der XML-Spezifikation und arbeitet mit dem HTTP-Protokoll. Dies macht es perfekt für die Verwendung in Webanwendungen.
Die SOAP-Bausteine bestehen aus einer SOAP-Nachricht. Jede SOAP-Nachricht besteht aus einem Hüllkurvenelement, einem Header und einem Body-Element.
Das Hüllkurvenelement 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 zu enthalten.
Das body-Element ist das Hauptelement, das die Definition der Webmethoden sowie gegebenenfalls Parameterinformationen enthält.