XML Web Service Wire Formats
Binary protocols such as DCOM consist of a method request layer riding on top of a proprietary communication protocol. Such protocols are not conducive to creating universally available XML Web services. This does not preclude you from using such protocols in an XML Web service scenario, but the drawback of using them is that such protocols depend on the specific architectures of their underlying systems and therefore limit the spectrum of potential clients.
Alternatively, you can construct XML Web services to work with one or more open protocols, such as a combination of HTTP and SOAP. As you would expect, the infrastructure required to support different protocols will vary.
XML Web services are not limited to providing remote procedure call (RPC) access. They can also be built to exchange structured information, such as purchase orders and invoices, and can be used to automate and connect internal and external business processes.
HTTP-GET and HTTP-POST
HTTP-GET and HTTP-POST are standard protocols that use HTTP (Hypertext Transfer Protocol) verbs for the encoding and passing of parameters as name/value pairs, along with the associated request semantics. Each consists of a series of HTTP request headers that among other things define what the client is requesting from the server, which responds with a series of HTTP response headers and the requested data if successful.
HTTP-GET passes its parameters in the form of urlencoded text using the MIME type application/x-www-form-urlencoded, which is appended to the URL of the server handling the request. Urlencoding is a form of character encoding that ensures that the passed parameters consist of conforming text, such as encoding a space as %20. The appended parameters are also referred to as a query string.
Similar to HTTP-GET, HTTP-POST parameters are also urlencoded. However, instead of being passed as part of the URL, the name/value pairs are passed inside the actual HTTP request message.
SOAP
SOAP is a simple, lightweight XML-based protocol for exchanging structured and type information on the Web. The overall design goal of SOAP is to keep it as simple as possible, and to provide a minimum of functionality. The protocol defines a messaging framework that contains no application or transport semantics. As a result, the protocol is modular and very extensible.
By traveling over standard transport protocols, SOAP is able to leverage the existing open architecture of the Internet and gain easy acceptance by any arbitrary system capable of supporting the most basic Internet standards. You could view the infrastructure required to support a SOAP-compliant XML Web service as rather simplistic, yet powerful, since it adds relatively little to the existing infrastructure of the Internet and still facilitates universal access to the services built with SOAP.
The SOAP protocol specification consists of four main parts. The first part defines a mandatory extensible envelope for encapsulating data. The SOAP envelope defines a SOAP message and is the basic unit of exchange between SOAP message processors. This is the only mandatory part of the specification.
The second part of the SOAP protocol specification defines optional data-encoding rules for representing application-defined data types and directed graphs, and a uniform model for serializing non-syntactic data models.
The third part defines an RPC-style (request/response) message exchange pattern. Each SOAP message is a one-way transmission. Although SOAP's roots are in RPC, it is not limited to being a request/response mechanism. XML Web services often combine SOAP messages to implement such patterns, but SOAP does not mandate a message exchange pattern and this part of the specification is also optional.
The fourth part of the specification defines a binding between SOAP and HTTP. However, this part is also optional. You can use SOAP in combination with any transport protocol or mechanism that is able to transport the SOAP envelope, including SMTP, FTP, or even a floppy disk.
For the SOAP specification, see the W3C Web site (http://www.w3.org/TR/soap).