SOAP-Webdienste-Tutorial: Was ist das SOAP-Protokoll?

Was ist SOAP?

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

SOAP steht für Simple Object Access Protocol, wurde aber später einfach zu SOAP v1.2 abgekürzt. SOAP ist ein Protokoll oder, anders ausgedrückt, eine Definition dafür, wie Webdienste untereinander oder mit Clientanwendungen, die sie aufrufen, kommunizieren.

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 Vielzahl von Anwendungen, die auf verschiedenen Programmiersprachen basieren. Beispielsweise könnte eine Webanwendung in … entwickelt worden sein. 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 Spezifikationen für die Verwendung von XML in allen Programmiersprachen zum Datenaustausch. Hier kommt 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 entwickelnping Für SOAP-basierte Webdienste benötigen Sie eine Sprache, mit der Webdienste mit Clientanwendungen kommunizieren können. SOAP ist das ideale Medium, da es genau für diesen Zweck entwickelt wurde. Dieses Protokoll wird auch vom W3C-Konsortium empfohlen, dem Gremium, das alle Webstandards festlegt.
• SOAP ist ein leichtgewichtiges Protokoll, das für den Datenaustausch zwischen Anwendungen verwendet wird. Beachten Sie das Schlüsselwort 'leichtDa die SOAP-Programmierung auf der XML-Sprache basiert, die selbst eine leichtgewichtige Datenaustauschsprache ist, fällt SOAP als Protokoll ebenfalls in dieselbe Kategorie.
• SOAP ist plattform- und betriebssystemunabhängig konzipiert. Daher kann das SOAP-Protokoll mit Anwendungen jeder Programmiersprache auf beiden Systemen verwendet werden. Windows und Linux Plattformen.
• Es basiert auf dem HTTP-Protokoll – SOAP nutzt das HTTP-Protokoll, das Standardprotokoll aller Webanwendungen. Daher sind keine Anpassungen erforderlich, um auf dem SOAP-Protokoll basierende Webdienste im World Wide Web auszuführen.

SOAP-Bausteine

Die SOAP-Spezifikation definiert etwas, das als „SOAP-Nachricht“, was an den Webdienst und die Client-Anwendung 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.

• An Umschlag Das Element, das das XML-Dokument als SOAP-Nachricht kennzeichnet – dies ist der umschließende Teil der SOAP-Nachricht und dient dazu, alle Details der SOAP-Nachricht zu kapseln. Es handelt sich um das Wurzelelement der SOAP-Nachricht.
• A Kopfzeile Das Header-Element enthält Informationen wie Authentifizierungsdaten, die von der aufrufenden Anwendung verwendet werden können. Es kann auch Definitionen komplexer Datentypen enthalten, die in der SOAP-Nachricht verwendet werden. Standardmäßig kann die SOAP-Nachricht Parameter enthalten, die einfache Datentypen wie Zeichenketten und Zahlen sein können, aber auch komplexe Objekttypen.

Im Folgenden wird ein einfaches SOAP-Dienstbeispiel für einen komplexen Datentyp dargestellt. Angenommen, wir möchten einen strukturierten Datentyp senden, der eine Kombination aus einem „Tutorialnamen“ und einem „Tutorial“ enthält. DescriptWenn wir dann „ion“ verwenden, definieren wir den komplexen Typ wie unten gezeigt. Der komplexe Typ wird durch das Element-Tag definiert. Alle erforderlichen Elemente der Struktur sowie ihre jeweiligen Datentypen werden dann in der Sammlung komplexer Typen definiert.

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

A Korpus Element, das Aufruf- und Antwortinformationen enthält – Dieses Element enthält die eigentlichen Daten, die zwischen dem Webdienst und der aufrufenden Anwendung ausgetauscht werden müssen. Nachfolgend finden Sie ein Beispiel für den SOAP-Body eines SOAP-Webdienstes, der mit dem im Header definierten komplexen Datentyp arbeitet. Hier ist die Antwort für den Tutorialnamen und das Tutorial. 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 Abschnitt dieses SOAP-Tutorials erläutert, besteht eine einfache SOAP-Nachricht aus folgenden Elementen:

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

Schauen wir uns im Folgenden ein Beispiel einer einfachen SOAP-Nachricht an und sehen wir uns an, was jedes Element bewirkt.

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. Die vollständigeGuru99Webservice“ 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 erkennen, wie nützlich die obigen Informationen für die Clientanwendung sind. Die SOAP-Nachricht teilt der Clientanwendung den Namen des Webdienstes, die erwarteten Parameter und den jeweiligen Datentyp mit.

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 benötigt ein Wurzelelement namens „Envelope“. Das Vorhandensein eines Envelope-Elements ist für eine SOAP-Nachricht zwingend erforderlich.
• 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.

Nachfolgend ein SOAP-API-Beispiel der 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

Bei einer Anfrage an einen SOAP-Webdienst kann die Antwort entweder eine Erfolgsmeldung oder eine Fehlermeldung sein. Im Erfolgsfall antwortet der Server stets mit einer SOAP-Nachricht. Fehler hingegen werden als „HTTP 500“-Fehler zurückgegeben.

Die SOAP-Fehlermeldung besteht aus den folgenden Elementen.

1. <faultCode> – Dies ist der Code, der den Fehlercode angibt. Der Fehlercode kann einen der folgenden Werte annehmen:
   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

Ein Beispiel für eine Fehlermeldung ist unten aufgeführt. Der Fehler tritt auf, wenn der Client versucht, die Methode „TutorialID“ der Klasse „GetTutorial“ aufzurufen. Die folgende Fehlermeldung wird generiert, falls die Methode in der definierten Klasse nicht existiert.

<?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 eine Fehlermeldung wie „Methode (GetTutorialID) in Klasse (GetTutorial) konnte nicht gefunden werden“ 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.

In diesem SOAP-API-Tutorial betrachten wir das folgende Diagramm, um die Funktionsweise dieser Kommunikation zu verstehen. In diesem Beispiel gehen wir davon aus, dass der Server einen Webdienst mit zwei Methoden bereitstellt:

• GetEmployee – Dadurch würden alle Mitarbeiterdaten abgerufen.
• SetEmployee – Dadurch würden die Werte der Details wie Abteilung, Gehalt usw. eines Mitarbeiters 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 oben beschriebene Kommunikationsmodell weist folgende gravierende Einschränkungen auf:

1. Nicht sprachunabhängig – Der Server, auf dem die Methoden gehostet werden, ist in einer bestimmten Programmiersprache geschrieben, und normalerweise erfolgen die Aufrufe an den Server ausschließlich in dieser Programmiersprache.
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 unten beschriebene Kommunikationsmodell verwenden.

1. Der Client formatierte die Informationen zum Prozeduraufruf und etwaigen Argumenten in eine SOAP-Nachricht und sendete diese als Teil einer HTTP-Anfrage an den Server. Dieser Prozess der Datenkapselung in eine SOAP-Nachricht wurde als SOAP-Verknüpfung bezeichnet. Rangieren.
2. Der Server würde dann die vom Client gesendete Nachricht entpacken, die Clientanfrage prüfen und die entsprechende Antwort als SOAP-Nachricht an den Client zurücksenden.ping Eine vom Client gesendete Anfrage wird als … bezeichnet. Abgrenzung.

Praktisches SOAP-Beispiel

Jetzt hier SoapUI In diesem Tutorial sehen wir uns ein praktisches SOAP-Beispiel an. Am besten versteht man die Generierung von SOAP-Nachrichten, indem man einen Webdienst in Aktion beobachtet.

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 einen String an die aufrufende Anwendung zurückgibt. Dieser Webdienst wird in einem 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 an, die zwischen dem Webdienst und der aufrufenden Anwendung ausgetauscht wird. Die erste Voraussetzung für die Einrichtung unserer Webdienstanwendung kann durch Befolgen der folgenden Schritte erfüllt werden. Bitte 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, ö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 für ASP.NET-Webanwendungen. Dieses Projekt muss von diesem Typ sein, um ein SOAP-Dienstprojekt zu erstellen. Bei Auswahl dieser Option führt Visual Studio die notwendigen Schritte zum Hinzufügen der für jede webbasierte Anwendung erforderlichen Dateien aus.
2. Geben Sie Ihrem Projekt einen Namen, in unserem Fall webservice.asmx. Stellen Sie anschließend sicher, dass Sie einen Speicherort für die Projektdateien angeben.

Nach Abschluss des Vorgangs wird die erstellte Projektdatei im Projektmappen-Explorer von Visual Studio 2013 angezeigt.

Schritt 3) In diesem Schritt fügen wir unserem Projekt eine Webdienstdatei hinzu.

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

2. 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 der Webdienstdatei einfach den Namen „Tutorialdienst“ an.

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

Code Erläuterung:

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 nächsten Schritt wird eine Funktion namens „Guru99WebService“, aber durch das Hinzufügen des Attributs [WebMethod] wird sichergestellt, dass diese Methode von einer Clientanwendung aufgerufen werden kann. Fehlt dieses Attribut, kann die Methode von keiner Clientanwendung aufgerufen werden.
4. Hier definieren wir eine Funktion namens 'GuruDie Funktion „99WebService“ gibt eine Zeichenkette an die aufrufende Clientanwendung zurück. Es handelt sich um einen Webdienst, der von jeder Clientanwendung aufgerufen werden kann.
5. Wir verwenden die return-Anweisung, um die Zeichenkette „Dies ist ein Guru99 Webdienst“ an die Clientanwendung.

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“, 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 „Aufrufen“ klicken, erhalten wir die folgende Antwort im Webbrowser.

Die obige Ausgabe:

• Es zeigt deutlich, dass durch Aufruf der Webmethode die Zeichenkette „Dies ist ein GuruEs wird „99 Webdienst“ zurückgegeben.
• 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 Erläuterung:

1. Der erste Teil der SOAP-Nachricht ist das Envelope-Element, das bereits in den vorherigen Kapiteln besprochen wurde. Es handelt sich um das umschließende Element, 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 mit dem Namen „“ aufrufen möchten.Guru99WebService'.

<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 Erläuterung:

1. Der erste Teil der SOAP-Nachricht ist das Envelope-Element, das bereits in den vorherigen Kapiteln besprochen wurde. Es handelt sich um das umschließende Element, 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. Das Interessante daran ist nun das Attribut „string“. Dieses teilt der Clientanwendung mit, dass der aufgerufene Webdienst ein Objekt vom Typ „string“ zurückgibt. Das ist sehr nützlich, da die Clientanwendung sonst nicht wüsste, was der Webdienst zurückgibt.

Häufig gestellte Fragen