Pourquoi un SOAP le message doit-il être envoyé via HTTP?
Vous trouverez ci-dessous un message de demande de démonstration SOAP:
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>
Et nous pouvons voir que ce message SOAP est codé comme s'il s'agissait d'une page Web. Pourquoi devons-nous utiliser le protocole HTTP? Le message SOAP n'est qu'un fichier XML. Pourquoi ne pas simplement utiliser XML comme protocole d'échange d'informations et supprimer les en-têtes HTTP (laissant ainsi HTTP seul).
Merci beaucoup.
Mise à jour - 1
HTTP n'est pas un protocole de niveau de transport. C'est juste un protocole au niveau de l'application. Cela n'a rien à voir avec les transports. En fait, ma question est la suivante: quel est le motif d'ajouter des éléments HTTP à un message SOAP?
SOAP peut être envoyé sur différents transports. HTTP est l'un d'entre eux.
Vue d'ensemble
SOAP est un protocole de messagerie et, en un mot, n'est qu'un autre langage XML.
Son objet est l'échange de données sur des réseaux. Son souci est l'encapsulation de ces données et les règles pour les transmettre et les recevoir.
HTTP est un protocole d'application et SOAP les messages sont placés en tant que charge HTTP.
Bien que HTTP présente un surcoût, il présente l’avantage de constituer un protocole ouvert aux pare-feu, bien compris et largement pris en charge. Ainsi, les services Web peuvent être consultés et exposés via une technologie déjà en place.
Les messages SOAP sont généralement échangés via HTTP. Bien qu’il soit possible d’utiliser d’autres protocoles (d’application), par exemple, SMTP ou FTP, les liaisons non HTTP ne sont pas spécifiées par les spécifications SOAP et ne sont pas prises en charge par WS-BP (spécifications d'interopérabilité). ) .
Vous pouvez échanger SOAP messages bruts TCP, mais vous disposerez alors de services Web non interopérables (non conformes à WS-BP).
De nos jours, le débat porte sur la raison pour laquelle le SOAP surcharge et ne pas envoyer de données via HTTP (RESTful WS).
Pourquoi utiliser HTTP pour SOAP?
J'essaierai d'aborder plus en détail la question dans l'OP en demandant pourquoi utiliser HTTP pour SOAP:
Tout d'abord, SOAP définit un format d'encapsulation de données et c'est tout.
Maintenant, la majorité du trafic sur le Web se fait via HTTP. HTTP est littéraire PARTOUT et est pris en charge par une infrastructure bien établie de serveurs et de clients (à savoir des navigateurs). De plus, c'est un protocole très bien compris.
Les personnes qui ont créé SOAP souhaitaient utiliser cette infrastructure prête à l'emploi et
- Les messages SOAP ont été conçus pour pouvoir être tunnelés via HTTP.
- Dans les spécifications, ils ne font référence à aucune autre liaison non HTTP, mais se réfèrent spécifiquement à HTTP comme exemple de transfert.
La mise en place de tunnels sur HTTP faciliterait et contribuerait à son adoption rapide. L'infrastructure HTTP étant déjà en place, les entreprises n'auraient pas à dépenser d'argent supplémentaire pour un autre type de mise en œuvre. Au lieu de cela, ils peuvent exposer et accéder à des services Web en utilisant la technologie déjà déployée.
Spécifiquement dans Java, un service Web peut être déployé en tant que noeud final de servlet ou en tant que noeud final d'EJB. Ainsi, tous les sockets réseau, threads, flux, transactions HTTP, etc. sous-jacents sont gérés par le conteneur et le développeur se concentre uniquement sur la charge XML.
Tomcat ou JBoss s'exécutent donc sur le port 80 et le service Web est également déployé et accessible. Aucun effort de programmation n'est effectué au niveau de la couche transport et le conteneur robuste gère tout le reste. .
Enfin, le fait que les pare-feu soient configurés pour ne pas restreindre le trafic HTTP est une troisième raison de préférer HTTP.
Etant donné que le trafic HTTP est généralement autorisé, la communication des clients/serveurs est beaucoup plus facile et les services Web peuvent fonctionner sans problèmes de bloqueurs de sécurité réseau dus au tunneling HTTP.
SOAP est XML = texte brut afin que les pare-feu puissent inspecter le contenu du corps HTTP et le bloquer en conséquence. Mais dans ce cas, ils pourraient également être améliorés pour rejeter ou accepter SOAP en fonction du contenu. Cette partie qui semble vous gêner n'est pas liée aux services Web ni à SOAP, et vous devriez peut-être commencer un nouveau fil concernant comment fonctionnent les pare-feu.
Cela dit, le fait que le trafic HTTP ne soit pas restreint pose souvent des problèmes de sécurité, car les pare-feu sont essentiellement contournés. C’est pourquoi les passerelles d’applications entrent en jeu.
Mais ce n’est pas lié à ce post.
Résumé
Donc, pour résumer les raisons d'utiliser HTTP:
- HTTP est populaire et réussi.
- L'infrastructure HTTP est en place, donc aucun coût supplémentaire pour déployer des services Web.
- Le trafic HTTP étant ouvert aux pare-feu, aucun problème de fonctionnement du service Web ne découle de la sécurité du réseau.
Le but de l'utilisation de HTTP était de passer à travers les pare-feu. La plupart des informaticiens de réseau n'autorisent pas l'ouverture de n'importe quel port, mais pour une raison quelconque, ils ont toujours laissé le port 80 ouvert pour les pages Web. Comme les serveurs Web ont été testés au fil des ans, il est "plus facile" de les sécuriser. En utilisant HTTP, vous disposez d’un ensemble d’outils permettant de gérer un protocole de communication.
vous pouvez aussi utiliser TCP et cela s'appelait .NET Remoting auparavant et maintenant sa part de WCF ...
SOAP ne doit pas nécessairement être envoyé via HTTP. Les développeurs utilisent le plus souvent HTTP et POST le soap comme s'il s'agissait d'un HTTP normal POST parce que nous sommes probablement plus familiarisés avec HTTP que d'autres protocoles tels que SMTP, ajoutez ceci au fait que nous implémentons déjà REST sur HTTP. Par exemple, voici comment nous envoyons SOAP sur le protocole de messagerie SMTP. Envoi de SOAP par SMTP
C'est une pratique courante d'utiliser HTTP
Une autre raison pourrait être que (si je me souviens bien), HTTP est également désigné comme un "standard de référence" pour la manière dont un protocole Internet est censé avoir l’air/le fonctionnement. Ainsi, si vous développiez un protocole propre, vous devriez monde idéal au moins) aboutissez à quelque chose de très similaire si vous suiviez tous les RFC. Par conséquent, pourquoi ne pas utiliser HTTP, l’un des protocoles les plus courants et les mieux compris du monde.
Il appartient au développeur de choisir la couche de transfert pour Simple Object Access Protocol. Le XML n'est pas un protocole de réseau, les données ne peuvent donc pas être transférées en utilisant simplement XML. Il doit être emballé dans quelque chose.
De manière générale, SOAP est la norme de services Web qui contient des descriptions du message, qui se présente sous la forme de XML. Cette structure de message sera transmise au moment du service Web appelé par le demandeur de service. Dans l'architecture SOA, l'une des caractéristiques les plus importantes est l'interopérabilité. Dans SOA SOAP, un rôle important est passé via HTTP/HTTPS et peut donc traverser les pare-feu, d'autres Une architecture telle que DCOM, CORBA et RPC ne traverse pas le pare-feu.