wake-up-neo.net

Warum macht a SOAP Nachricht muss über HTTP gesendet werden?

Unten ist eine Demo SOAP Anforderungsnachricht:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

    <SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
   <SOAP-ENV:Header>
       <t:SessionOrder
         xmlns:t="http://example.com"
         xsi:type="xsd:int" mustUnderstand="1">
           5
       </t:SessionOrder>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
       <GetStockQuote
         xmlns="http://someexample.com">
           <Price>MSFT</Price>
       </GetStockQuote>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Und wir können sehen, dass diese SOAP Nachricht so verschlüsselt ist, als wäre es eine Webseite. Warum müssen wir das HTTP-Protokoll verwenden? SOAP message ist nur eine XML-Datei. Warum verwenden wir nicht einfach XML als Protokoll für den Informationsaustausch und entfernen die HTTP-Header (lassen Sie HTTP also in Ruhe)?.

Danke vielmals.

Update - 1

HTTP ist kein Protokoll auf Transportebene. Es ist nur ein Protokoll auf Anwendungsebene. Es hat nichts mit Transport zu tun. Eigentlich ist meine Frage, was das Motiv ist, einer SOAP Nachricht HTTP-Inhalte hinzuzufügen?

19
smwikipedia

SOAP kann über verschiedene Transporte gesendet werden. HTTP ist nur eine davon.

22
Emil Vikström

Überblick

SOAP ist ein Messaging-Protokoll und in aller Kürze eine andere XML-Sprache.
Ihr Zweck ist der Datenaustausch über Netzwerke. Ihr Anliegen ist die Einkapselung dieser Daten und die Regeln für das Senden und Empfangen dieser Daten. 

HTTP ist ein Anwendungsprotokoll und SOAP -Nachrichten werden als HTTP-Nutzdaten platziert.
Obwohl HTTP ein Overhead ist, hat es den Vorteil, dass es ein Protokoll ist, das offen für Firewalls ist, gut verstanden und weitgehend unterstützt. So können Webservices über bereits vorhandene Technologie abgerufen und bereitgestellt werden. 

SOAP-Nachrichten werden normalerweise über HTTP ausgetauscht. Es ist zwar möglich, andere (Anwendungs-) Protokolle zu verwenden, z. SMTP oder FTP, die Nicht-HTTP-Bindungen werden nicht durch SOAP-Spezifikationen angegeben und nicht von WS-BP (Interoperabilitätsspezifikation) unterstützt ) .
Sie können SOAP -Nachrichten über das unformatierte TCP austauschen. In diesem Fall stehen jedoch Webdienste zur Verfügung, die nicht interoperabel sind (nicht WS-BP-konform). 

Heutzutage ist die Debatte der Grund, warum der SOAP-Overhead überhaupt besteht und keine Daten über HTTP gesendet werden (RESTful WS).

Warum HTTP für SOAP verwenden?

Ich werde versuchen, die Frage im OP genauer zu beantworten und zu fragen, warum HTTP für SOAP verwendet wird:

Zunächst einmal definiert SOAP ein Datenkapselungsformat und das ist es.
Der größte Teil des Datenverkehrs im Web findet nun über HTTP statt. HTTP ist ALLES literarisch und wird von einer etablierten Infrastruktur von Servern und Clients (insbesondere Browsern) unterstützt. Zusätzlich ist es ein sehr gut verstandenes Protokoll. 

Die Leute, die SOAP erstellt haben, wollten diese bereite Infrastruktur verwenden

  1. SOAP-Nachrichten wurden so konzipiert, dass sie über HTTP getunnelt werden können 
  2. In den Spezifikationen beziehen sie sich nicht auf eine andere Nicht-HTTP-Bindung, sondern ausdrücklich auf HTTP als Beispiel für die Übertragung. 

Das Tunneln über HTTP würde und würde bei seiner schnellen Einführung helfen. Da die Infrastruktur von HTTP bereits vorhanden ist, müssten Unternehmen kein zusätzliches Geld für eine andere Implementierung aufwenden. Stattdessen können sie mithilfe der bereits bereitgestellten Technologie Web-Services verfügbar machen. 

Speziell in Java kann ein Webdienst entweder als Servlet-Endpunkt oder als EJB-Endpunkt bereitgestellt werden. Daher werden alle zugrundeliegenden Netzwerk-Sockets, Threads, Streams, HTTP-Transaktionen usw. vom Container verarbeitet, und der Entwickler konzentriert sich nur auf die XML-Nutzlast.
Ein Unternehmen hat also Tomcat oder JBoss in Port 80 ausgeführt, und der Web-Service ist implementiert und ebenfalls verfügbar. Auf der Transportebene ist kein Programmieraufwand erforderlich, und der robuste Container erledigt alles andere .
Schließlich ist die Tatsache, dass Firewalls so konfiguriert sind, dass sie den HTTP-Verkehr nicht einschränkt, ein dritter Grund, HTTP vorzuziehen. 

Da in der Regel HTTP-Datenverkehr zugelassen wird, ist die Kommunikation von Clients/Servern wesentlich einfacher und Web-Services können ohne Probleme mit Netzwerksicherheitsblockern als Ergebnis des HTTP-Tunnelns arbeiten. 

SOAP ist XML = Nur-Text, sodass Firewalls den Inhalt des HTTP-Texts prüfen und entsprechend blockieren können. In diesem Fall könnten sie jedoch auch erweitert werden, um SOAP abhängig vom Inhalt abzulehnen oder zu akzeptieren. Dieser Teil, der Sie zu stören scheint, hat nichts mit Web Services oder SOAP zu tun, und vielleicht sollten Sie einen neuen Thread in Bezug auf starten wie Firewalls funktionieren 

Die Tatsache, dass der HTTP-Verkehr uneingeschränkt ist, führt jedoch häufig zu Sicherheitsproblemen, da Firewalls im Wesentlichen umgangen werden. Aus diesem Grund kommen Application-Gateways zum Einsatz.
Aber das hat nichts mit diesem Beitrag zu tun.

Zusammenfassung

Um die Gründe für die Verwendung von HTTP zusammenzufassen: 

  1. HTTP ist beliebt und erfolgreich. 
  2. Die HTTP-Infrastruktur ist vorhanden, sodass keine zusätzlichen Kosten für die Bereitstellung von Webdiensten anfallen. 
  3. Der HTTP-Datenverkehr ist für Firewalls offen, sodass während des Netzwerkdienstes keine Probleme auftreten.
43
Cratylus

Die Verwendung von HTTP hatte zum Ziel, Firewalls zu durchdringen. Die meisten Netzwerk-IT-Mitarbeiter lassen nicht zu, dass jeder Port offen ist, aber aus irgendeinem Grund haben sie immer zugelassen, dass Port 80 für Webseiten geöffnet ist. Da Webserver im Laufe der Jahre getestet wurden, ist es "einfacher", sie abzusichern. Durch die Verwendung von HTTP verfügen Sie über eine Reihe von Tools zum Umgang mit einem Kommunikationsprotokoll. 

6

sie können auch TCP verwenden, und das wurde früher .NET Remoting genannt und ist jetzt Teil von WCF ...

2
Numenor

SOAP muss nicht über HTTP gesendet werden. Die Entwickler verwenden am häufigsten HTTP und POST als Seife, als wäre es ein normales HTTP POST, da wir höchstwahrscheinlich HTTP besser kennen als andere Protokolle wie SMTP Wir implementieren bereits REST über HTTP. Zum Beispiel, wie wir SOAP über das SMTP-E-Mail-Protokoll senden. Senden von SOAP über SMTP

Es ist nur eine gängige Praxis, HTTP zu verwenden

0
Sudip Bhandari

Ein anderer Grund könnte sein, dass (wenn ich mich recht erinnere) HTTP auch als "Goldstandard" bezeichnet wird, wie ein Internetprotokoll aussehen soll/funktionieren soll. Wenn Sie also ein eigenes Protokoll entwickeln würden, würden Sie (in einem Zumindest die ideale Welt) enden mit etwas sehr ähnlichem, wenn Sie alle RFCs befolgt haben. Warum also nicht HTTP verwenden, eines der bekanntesten Protokolle der Welt. 

0
Stuggi

Der Entwickler muss die Übertragungsschicht für das Simple Object Access-Protokoll auswählen. XML ist kein Netzwerkprotokoll, daher können die Daten nicht nur mit XML übertragen werden. Es muss in etwas gepackt werden. 

Grundsätzlich ist SOAP der Webservice-Standard, der Beschreibungen der Nachricht enthält, die in Form von XML vorliegt. Diese Nachrichtenstruktur wird zum Zeitpunkt des Web-Service durch den Serviceanforderer übergeben. In der Architektur von SOA ist Interoperabilität eines der wichtigsten Merkmale. In SOA SOAP spielt die gewaltige Rolle eine Rolle, die über HTTP/HTTPS übergeben wurde und daher die Firewalls überqueren kann Architektur wie DCOM, CORBA und RPC überqueren nicht die Firewall.

0
yogesh wanjari