SOAP Basics

It has a clear purpose exchanging data over network ( via protocols like http , ftp , smtp etc ).

< ? xml version="1.0" encoding="UTF-8"? >

< soap : Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

  < soap:Header >

    < !- - Header blocks go here - - >

  < / soap:Header >

  < soap:Body >

    < !- - Application data goes here - - >

  < / soap:Body >

< / soap:Envelope >

The Header element can contain XML elements that describe security credentials, transaction IDs, routing instructions, debugging information, payment tokens, or any other information about the message that is important in processing the data in the Body element.

< ? xml version="1.0" encoding="UTF-8"? >

< soap : Envelope

 xmlns : soap="http://schemas.xmlsoap.org/soap/envelope/" >

  < soap : Body>

    < po : purchaseOrder orderDate="2003-09-22"

     xmlns : po=" http://www.Monson-Haefel.com/jwsbook/PO ">

      < po : accountName > Amazon.com< / po:accountName >

      < / po:purchaseOrder >

   </ soap : Body>

</ soap : Envelope >

Use of a name space 

1. basic thing like avoid collision

2. proper versioning

3. hence proper processing

4. As you can see from the previous examples, a SOAP message may contain many different namespaces, which makes SOAP messaging very modular. This modularity enables different parts of a SOAP message to be processed independently of other parts and to evolve separately.

5. Example :- The code that processes the element Envelope is independent of the code that processes the header blocks, which is independent of the code that processes application-specific data in the SOAP Body element

SOAP can be used with a variety of messaging systems (asynchronous, synchronous, RPC, One-Way, and others),

SOAP Over HTTP

It's possible to deliver SOAP messages using other protocols, such as SMTP and FTP as well, but details of these non-HTTP bindings are not specified by SOAP and are not supported by the BP

SOAP messages sent over HTTP are placed in the payload of an HTTP request or response.

There is nothing intrinsic to HTTP that limits it to requesting Web pages, but that's been its primary occupation for the past decade. Most HTTP traffic is composed of HTTP GET requests and HTTP replies. The HTTP GET request identifies the Web page requested and may include some parameters. An HTTP reply message returns the Web page to the requester as its payload.

While the HTTP GET request is perfectly suited for requesting Web pages, it doesn't have a payload area and therefore cannot be used to carry SOAP messages. The HTTP POST request, on the other hand, does have a payload area and is perfectly suited to carrying a SOAP message. HTTP reply messages, whether they are replies to GET or POST messages, follow the same format and carry a payload. Web services that use SOAP 1.1 with HTTP always use HTTP POST and not HTTP GET messages.

The HTTP POST message must contain a SOAPAction header field, but the value of this header field is not specified. The SOAPAction header field can improve throughput by providing routing information outside the SOAP payload. A node can then do some of the routing work using the SOAPAction, rather than having to parse the SOAP XML payload.

While the SOAPAction header field can improve efficiency, it's also the source of a lot of debate in the Web services industry. SOAP purists don't like the use of the SOAPAction HTTP header field because it expands the SOAP processing model to include the carrier protocol (in this case HTTP). They believe that all of the routing and payload should be contained in the SOAP document, so that SOAP messages are not dependent on the protocol over which they are delivered.

SOAP 1.2 will replace the SOAPAction header with the protocol-independent action media type (a parameter to the "application/soap+xml" MIME type), so dependency on this feature may result in forward-compatibility problems.

You may have noticed that the Content-Type is text/xml, which indicates that the payload is an XML document. The WS-I Basic Profile 1.0 prefers that the text/xml Content-Type be used with SOAP over HTTP. It's possible to use others (for example, SOAP with Attachments would specify multipart/related) but it's not recommended.

Http Reply

Http Response Code : Success code

200 : ok

202 : Accepted This response code means that the request was processed successfully but that there is no SOAP response data. This type of SOAP operation is similar to a Java method that has a return type of void.

Http Response Code : Error code

400 Bad Request This error code is used to indicate that either the HTTP request or the XML in the SOAP message was not well formed.

405 Method Not Allowed If a Web service receives a SOAP message via any HTTP method other than HTTP POST, the service should return a 405 Method Not Allowed error to the sender.

415 Unsupported Media Type HTTP POST messages must include a Content-Type header with a value of text/xml. If it's any other value, the server must return a 415 Unsupported Media Type error.

500 Internal Server Error This code must be used when the response message in a Request/Response MEP is a SOAP fault.