SOAP

Simple Object Access Protocol (SOAP) is a way to structure data so that any computer program in any language can read SOAP and send messages in SOAP.  This is because it is XML based and language and platform independent.  SOAP supports any transport protocol and use Hyper Text Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) and Post Office Protocol 3 (POP3) to carry documents.

SOAP Message Structure

The SOAP message consists of three parts: an envelope, one or more headers and a body.  The following example message below shows how the Envelope, Header and Body are used to build a complete message.  The explanation of each of these follows after the following figure.

Figure 1

Envelope

It is the root element in SOAP message and is required for every SOAP message.  It identifies the following:

Message content

Desired recipients

Special processing information (if any)

The Schemas

Header

This is an optional part of the SOAP message.  It lets the application exchange information.  It even enables identification of the features in the message and explains whether a feature is optional or mandatory.  This also provides processing information and furnishing additional products for some specific tasks such as security or transaction management. (We can use SOAP header to pass along username and password information so that only the users we choose can access the service.)

Body

The Body is the most important part of a SOAP message; rather we may say that it is the mandatory part of the SOAP message.  If the SOAP message contains no header, it is the first element after the envelope.  It contains the XML information being exchanged.  In a Web Service interaction there is SOAP request message and SOAP response message.  In case of SOAP request message, the client sends a SOAP message to the server, invoking some method.  In SOAP response message the server returns a response which includes the return value of the method.  In SOAP request message, the SOAP Body contains the name of the method, along with the method's input parameters.  In SOAP response message, the server sends back in the body the return value of the method.  (Even if there is no return value, a message is still sent back to verify that the method executed.)  The SOAP Body is signified by the <soap:Body> element. There may be SOAP fault element in SOAP message -<soap:Fault> for reporting errors.

Web Services Description Language (WSDL)

Web Services Description Language (WSDL) is an open standard language used in conjunction with XML-based languages.  A WSDL file is an XML document that describes a set of SOAP messages and how the messages are exchanged.

Universal Description, Discovery, and Integration (UDDI)

Universal Description, Discovery, and Integration (UDDI) is an open, Internet-based specification that is the building block on which businesses may quickly and easily locate desired services and perform business with one another.

Transport Protocol for Web Service

Unless we specify otherwise, .NET will attempt to bind Web Services to three separate protocols: HTTP/POST, HTTP/GET, and SOAP.  Bindings for these three protocols will be included in the WSDL file automatically generated by .NET and consumer clients will have the option of choosing any one of them for communication with service.  However, GET and POST are limited to sending and receiving name/value pairs of data whereas we can use SOAP to serialize complex structure, such as ASP.NET DataSets, complex arrays, custom types and XML nodes.

We can easily remove these bindings by adding the followings as specified in Listing 1 to our web.config file as:

Listing 1

<webservices>
  <protocols>
    <remove name="HttpPost" />
    <remove name="HttpGet" />
  </protocols>
</webservices>

This section will tell the WSDL generator not to include bindings for HTTP/POST and HTTP/GET. The two remove sections specify that HttpPost and HttpGet should not be supported.  With regard to interoperability where SOAP is a widely-used standard for Web Service communication, HTTP/GET and HTTP/POST are not.  As a result, many automatic proxy generation tools were not designed to understand the HTTP/GET and HTTP/POST bindings included by default in a .NET-generated WSDL document.  If our service does not make use of these bindings, removing them can increase our service's interoperability.