Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h1>Overview</h1> <p><em>SOAP</em> is a <strong>messaging protocol</strong> and in a nutshell is just another XML language.<br> Its purpose is the data exchange over networks. Its concern is the encapsulation of these data and the rules for transmitting and receiving them. </p> <p><em>HTTP</em> is an <strong>application protocol</strong> and SOAP messages are placed as the HTTP payload.<br> 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. </p> <p>SOAP messages are usually exchanged via <em>HTTP</em>. Although it is possible to use other (application) protocols, e.g. <em>SMTP</em> or <em>FTP</em>, the non-HTTP bindings are not specified by SOAP specs and are not supported by <a href="http://en.wikipedia.org/wiki/WS-I_Basic_Profile" rel="noreferrer">WS-BP (interoperability spec)</a>.<br> You could exchange SOAP messages over raw TCP but then you would have web services that are not interoperable (not compliant to WS-BP). </p> <p>Nowadays the debate is why have the SOAP overhead at all and not send data over HTTP (<em>RESTful WS</em>).</p> <h1>Why use <em>HTTP</em> for <em>SOAP</em>?</h1> <p>I will try to address in more detail the question in the OP, asking why use HTTP for SOAP:</p> <p>First of all SOAP defines a data encapsulation format and that's that.<br> 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. </p> <p>The people who created SOAP wanted to use this ready infrastructure and</p> <ol> <li>SOAP messages were designed so that they can be tunneled over HTTP </li> <li>In the specs they do not refer to any other non-HTTP binding but specifically refer to HTTP as an example for transfer. </li> </ol> <p>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. </p> <p>Specifically in <em>Java</em> 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.<br> 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.<br> Finally the fact that firewalls are configured not to restrict HTTP traffic is a third reason to prefer HTTP. </p> <p>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. </p> <p>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. </p> <p>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.<br> But this is not related to this post.</p> <h1>Summary</h1> <p>So to sum up the reasons for using HTTP: </p> <ol> <li>HTTP is popular and successful. </li> <li>HTTP infrastructure is in place so no extra cost to deploy web services. </li> <li>HTTP traffic is open to firewalls, so there are no problems during web service functioning as a result of network security.</li> </ol>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload