Perché un messaggio SOAP devono essere inviati tramite HTTP?

Question

Qui di seguito è una demo messaggio di richiesta 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> 

e si può vedere, questo messaggio SOAP è codificato come se si tratta di una pagina web. Perché dobbiamo usare il protocollo HTTP? messaggio SOAP è solo un po 'di XML, perché non usiamo XML come protocollo di scambio di informazioni e di sbarazzarsi delle intestazioni HTTP (quindi lasciare HTTP da solo).

Molte grazie.

Aggiornamento - 1

HTTP non è un protocollo di livello di trasporto. È solo un protocollo a livello di applicazione. Non ha nulla a che fare con il trasporto. In realtà, la mia domanda è: qual è il motivo per aggiungere elementi HTTP a un messaggio SOAP?

Answer 1

SOAP possono essere inviati su diversi tipi di trasporto. HTTP è solo uno di questi.

Answer 2

è possibile utilizzare il protocollo TCP troppo e che è stato chiamato .NET Remoting prima e ora parte della WCF sua ...

Answer 3

Spetta allo sviluppatore di scegliere il livello di trasferimento per Simple Object Access Protocol. L'XML non è un protocollo di rete, quindi i dati non possono essere trasferiti utilizzando solo XML. Deve essere confezionato in qualcosa.

Answer 4

Il motivo di utilizzare HTTP era quello di ottenere attraverso i firewall. Si vede la maggior parte delle persone di rete IT non consentono solo una porta di essere aperta, ma per qualche motivo hanno sempre permesso la porta 80 ad aprirsi per le pagine web. Poiché i server Web sono stati testati nel corso degli anni, è "più semplice" proteggerli. Usando HTTP hai un set esistente di strumenti per gestire un protocollo di comunicazione.

Answer 5

Panoramica

SOAP è un protocollo di messaggistica e in poche parole è solo un altro linguaggio XML.
Il suo scopo è lo scambio di dati su reti. La sua preoccupazione è l'incapsulamento di questi dati e le regole per trasmetterli e riceverli.

HTTP è un protocollo diapplicazione e messaggi SOAP sono posti come payload HTTP.
Sebbene esista un sovraccarico di HTTP, ha il vantaggio che si tratta di un protocollo aperto a firewall, ben compreso e ampiamente supportato. Pertanto, i servizi Web sono accessibili e esposti tramite la tecnologia già in uso.

I messaggi SOAP vengono generalmente scambiati tramite HTTP. Sebbene sia possibile utilizzare altri protocolli (applicativi), ad es. SMTP o FTP, i collegamenti non HTTP non sono specificati dalle specifiche SOAP e non sono supportati da WS-BP (interoperability spec).
È possibile scambiare messaggi SOAP su TCP non elaborato, ma i servizi Web non sono interoperabili (non conformi a WS-BP).

Al giorno d'oggi il dibattito è il motivo per cui l'overhead SOAP è del tutto privo di dati inviati tramite HTTP (RESTful WS).

Perché utilizzare HTTP per SOAP?

cercherò di affrontare in modo più dettagliato la questione nel PO, chiedendo perché utilizzare HTTP per SOAP:

Prima di tutto SOAP definisce un formato di dati incapsulamento e basta.
Ora la maggior parte del traffico nel web avviene tramite HTTP. HTTP è letterario OVUNQUE e supportato da un'infrastruttura consolidata di server e client (ovvero i browser). Inoltre è un protocollo molto ben compreso.

Le persone che hanno creato SOAP volevano utilizzare questa infrastruttura pronta e

1. messaggi SOAP sono stati progettati in modo che possano essere veicolato su HTTP
2. Nelle specifiche non si riferiscono a nessun altro non HTTP vincolante ma in particolare si riferisce a HTTP come esempio per il trasferimento.

Il tunneling su HTTP sarebbe stato utile nella sua rapida adozione. Poiché l'infrastruttura di HTTP è già presente, le aziende non dovrebbero spendere soldi extra per un altro tipo di implementazione. Invece possono esporre e accedere ai servizi Web utilizzando la tecnologia già implementata.

Specificamente in Java un servizio Web può essere distribuito come endpoint servlet o come endpoint EJB. Quindi tutti i socket di rete sottostanti, i thread, i flussi, le transazioni HTTP ecc. Vengono gestiti dal contenitore e lo sviluppatore si concentra solo sul payload XML.
Quindi un'azienda ha Tomcat o JBoss in esecuzione nella porta 80 e il servizio Web è distribuito e accessibile pure. Non c'è nessuno sforzo per programmare il livello di trasporto e il robusto contenitore gestisce tutto il resto.
Infine, il fatto che i firewall siano configurati per non limitare il traffico HTTP è una terza ragione per preferire HTTP.

Poiché il traffico HTTP è solitamente consentito, la comunicazione di client/server è molto più semplice e i servizi Web possono funzionare senza problemi di blocco della sicurezza di rete a seguito del tunneling HTTP.

SOAP è XML = testo normale in modo che i firewall possano ispezionare il contenuto del corpo HTTP e bloccare di conseguenza. Ma in questo caso potrebbero anche essere migliorati per rifiutare o accettare SOAP a seconda dei contenuti. Questa parte che sembra disturbare non è correlata ai servizi Web o ai SOAP e forse dovresti iniziare una nuova discussione su come funzionano i firewall.

Detto questo, il fatto che il traffico HTTP è senza restrizioni è spesso causa di problemi di sicurezza in quanto i firewall sono sostanzialmente by-passati, ed è per questo applicative-gateway sono disponibili in.
Ma questo non è legato a questo post.

Sommario

Quindi, per riassumere le ragioni per l'utilizzo di HTTP:

1. HTTP è popolare e di successo.
2. L'infrastruttura HTTP è disponibile, quindi nessun costo aggiuntivo per l'implementazione di servizi Web.
3. Il traffico HTTP è aperto ai firewall, quindi non ci sono problemi durante il funzionamento del servizio web a causa della sicurezza della rete.

Answer 6

Tutti i browser supportano HTTP per compatibilità e sono il protocollo Internet più utilizzato. SOAP è un protocollo di comunicazione che specifica il formato per l'invio di messaggi. RPC e CORBA hanno problemi di compatibilità e sicurezza, mentre HTTP è compatibile con tutti i browser. Ora che HTTP comunica su TCP/IP. Un metodo SOAP è una richiesta HTTP/risposta HTTP che viene compilata con le regole di codifica SOAP. utilizzando SOAP, un protocollo inviato ai dati W3C può essere racchiuso in XML e trasmesso utilizzando un numero qualsiasi di protocolli Internet.

Answer 7

Un altro motivo potrebbe essere che (se non ricordo male) HTTP è anche designato come "gold standard" per come un protocollo internet dovrebbe apparire/funzionare, quindi se dovessi sviluppare un protocollo personale, dovresti fondamentalmente (almeno in un mondo ideale) si finisce con qualcosa di molto simile se si seguono tutte le RFC. Pertanto, perché non utilizzare HTTP, uno dei protocolli più comuni e ben conosciuti al mondo.

Answer 8

Fondamentalmente SOAP è lo standard dei servizi Web che contiene le descrizioni del messaggio che sotto forma di XML. La struttura del messaggio verrà trasmessa al momento del servizio web chiamato dal richiedente del servizio. Nell'architettura SOA una delle caratteristiche più importanti è l'interoperabilità, in SOA SOAP gioca un ruolo enorme che passa attraverso HTTP/HTTPS e quindi può attraversare i firewall, altre architetture come DCOM, CORBA e RPC non attraversano il firewall.

Answer 9

SOAP non deve essere inviato su HTTP. Gli sviluppatori utilizzano più frequentemente HTTP e POST il sapone come se fosse un normale POST HTTP perché probabilmente abbiamo più familiarità con HTTP di altri protocolli come SMTP, aggiungendo questo al fatto che implementiamo REST su HTTP. Ad esempio, ecco come si invia il protocollo di posta elettronica SOAP su SMTP. Sending SOAP over SMTP

E 'solo una pratica comune utilizzare HTTP