Below is a demo SOAP request message:

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="ht开发者_如何转开发tp://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>

And we can see, this SOAP message is encoded as if it is a web page. Why do we have to use the HTTP protocol? SOAP message is just some XML, why not we just use XML as the information exchange protocol and get rid of the HTTP headers (thus leave HTTP alone).

Many thanks.

Update - 1

HTTP is not a transport level protocol. It is just a application-level protocol. It has nothing to do with transport. Actually, my question is what's the motive of adding HTTP stuff to a SOAP message?

Overview

SOAP is a messaging protocol and in a nutshell is just another XML language.
Its purpose is the data exchange over networks. Its concern is the encapsulation of these data and the rules for transmitting and receiving them.

HTTP is an application protocol and SOAP messages are placed as the HTTP payload.
Although there is the overhead of HTTP, it has the advantage that it is a protocol that is open to firewalls, well-understood and widely-supported. Thus, web services can be accessed and exposed via technology already in-place.

SOAP messages are usually exchanged via HTTP. Although it is possible to use other (application) protocols, e.g. SMTP or FTP, the non-HTTP bindings are not specified by SOAP specs and are not supported by WS-BP (interoperability spec).
You could exchange SOAP messages over raw TCP but then you would have web services that are not interoperable (not compliant to WS-BP).

Nowadays the debate is why have the SOAP overhead at all and not send data over HTTP (RESTful WS).

Why use HTTP for SOAP?

I will try to address in more detail the question in the OP, asking why use HTTP for SOAP:

First of all SOAP defines a data encapsulation format and that's that.
Now the majority of traffic in the web is via HTTP. HTTP is literary EVERYWHERE and supported by a well-established infrastructure of servers and clients(namely browsers). Additionally it is a very well understood protocol.

The people who created SOAP wanted to use this ready infrastructure and

1. SOAP messages were designed so that they can be tunneled over HTTP
2. In the specs they do not refer to any other non-HTTP binding but specifically refer to HTTP as an example for transfer.

The tunneling over HTTP would and did help in it's rapid adoption. Because the infrastructure of HTTP is already in-place, companies would not have to spend extra money for another kind of implementation. Instead they can expose and access web services using technology already deployed.

Specifically in Java a web service can be deployed either as a servlet endpoint or as an EJB endpoint. So all the underlying network sockets, threads, streams, HTTP transactions etc. are handled by the container and the developer focuses only on the XML payload.
So a company has Tomcat or JBoss running in port 80 and the web service is deployed and accessible as well. There is no effort to do programming at the transport layer and the robust container handles everything else.
Finally the fact that firewalls are configured not to restrict HTTP traffic is a third reason to prefer HTTP.

Since HTTP traffic is usually allowed, the communication of clients/servers is much easier and web services can function without network security blockers issues as a result of the HTTP tunneling.

SOAP is XML=plain text so firewalls could inspect the content of HTTP body and block accordingly. But in this case they could also be enhanced to reject or accept SOAP depending on the contents.This part which seems to trouble you is not related to web services or SOAP, and perhaps you should start a new thread concerning how firewalls work.

Having said that, the fact that HTTP traffic is unrestricted often causes security issues since firewalls are essentially by-passed, and that is why application-gateways come in.
But this is not related to this post.

Summary

So to sum up the reasons for using HTTP:

1. HTTP is popular and successful.
2. HTTP infrastructure is in place so no extra cost to deploy web services.
3. HTTP traffic is open to firewalls, so there are no problems during web service functioning as a result of network security.

SOAP can be sent over different transports. HTTP is just one of them.

For example: SMTP, TCP/IP

The motive of using HTTP was to get through firewalls. You see most network IT people do not allow just any port to be open, but for some reason they always allowed port 80 to be open for web pages. Because web servers have been tested over the years it is "easier" to secure them. By using HTTP you have an existing set of tools for dealing with a communications protocol.

you can use TCP too and that was named .NET Remoting before and now its part of WCF...

SOAP doesn't have to be sent over HTTP. Developers most frequently use HTTP and POST the soap as if it were a normal HTTP POST because we are most probably more familiar with HTTP than other protocols like SMTP, add this to the fact that we already implement REST over HTTP. For example here is how we send SOAP over SMTP email protocol. Sending SOAP over SMTP

It's just a common practice to use HTTP

It is up to developer to choose the transfer layer for Simple Object Access Protocol. The XML is not a network protocol so the data cant be transfered using just XML. It has to be packed into something.

Another reason might be that (if I remember correctly) HTTP is also designated as a "gold standard" for how an internet protocol is supposed to look/work, so if you were to develop an own protocol, you'd basically (in an ideal world at least) end up with something very similar if you followed all the RFCs. Therefore, why not use HTTP, one of the worlds most common and well understood protocols.

Basically SOAP is the web services standard that contains descriptions of the message which in the form of XML. That message structure will passed at time of web service called by service requester. In SOA architecture one of the most important characteristic is interoperability, in SOA SOAP play massive role that passed via HTTP/HTTPS and therefore can cross the firewalls, other architecture like DCOM, CORBA and RPC does not cross the firewall.

All the browsers supports HTTP for compatibility and its the most widely used Internet Protocol. SOAP is a communication protocol that specifies the format for sending messages. RPC and CORBA has compatibility and security issues, whereas HTTP is compatible with all the browsers. Now that HTTP communicates over TCP/IP. A SOAP method is an HTTP request/HTTP response that compiles with the SOAP encoding rules. using SOAP, a protocol submitted to the W3C data can be enclosed in XML and transmitted using any number of Internet Protocols.