How SOAP server process the requests

  1. The SOAP server receives the request from the client as an HTTP request.

  2. The request is passed to the HTTP request handler that redirects the request to the appropriate SOAP servlet. This SOAP servlet is responsible for decoding the HTTP request.

  3. The SOAP servlet directs the request to the HTTP/SOAP decoder. The decoder extracts the original service call from the HTTP request.

  4. The request is processed by the SOAP server, and the result is passed to the HTTP/SOAP encoder.

  5. The HTTP/SOAP encoder wraps the result in an HTTP response and passes it back to the SOAP servlet.

  6. The SOAP servlet, in turn, passes the response to the client.

Explain SOAP messaging model

  1. The client application discovers a server application by using its discovery document and makes a service call to the server application by invoking its appropriate method.

  2. The SOAP serializer converts the invocation by the client application to a SOAP request.

  3. The SOAP serializer sends the SOAP request to an HTTP encoder, which wraps the SOAP request in an HTTP request, because the request needs to be sent from the client to the SOAP server as an HTTP request.

  4. The response from the server is received in the HTTP format by the HTTP decoder module.

  5. The HTTP decoder module decodes the HTTP response and extracts the SOAP message from the response. The SOAP message is sent to the SOAP deserializer.

  6. The SOAP deserializer decodes the SOAP message and passes the result to the client application.

Explain SOAP messaging model

  1. The client application discovers a server application by using its discovery document and makes a service call to the server application by invoking its appropriate method.

  2. The SOAP serializer converts the invocation by the client application to a SOAP request.

  3. The SOAP serializer sends the SOAP request to an HTTP encoder, which wraps the SOAP request in an HTTP request, because the request needs to be sent from the client to the SOAP server as an HTTP request.

  4. The response from the server is received in the HTTP format by the HTTP decoder module.

  5. The HTTP decoder module decodes the HTTP response and extracts the SOAP message from the response. The SOAP message is sent to the SOAP deserializer.

  6. The SOAP deserializer decodes the SOAP message and passes the result to the client application.

What are SOAP attribtutes

A client can use SOAP attributes to specify how SOAP messages should be processed.

SOAP attributes are generally used to specify the serialization rules to indicate the recipient of the Header element of the SOAP message.

Attributes also indicate whether or not the recipient should process certain header entries.

example1:

The mustUnderstand attribute states whether or not the SOAP processor should process the header information. The usage of this attribute is given below:

soap:mustUnderstand = "true"

After the mustUnderstand attribute is set to true, the SOAP toolkit needs to compulsorily process the statement. If the toolkit is unable to process the statement, it should return a fault code signifying that there was an error in interpreting the statement.

example 2:

The actor attribute of a SOAP message specifies URI to indicate who should receive the Header element of the SOAP message. If no URI is specified, it is assumed that the ultimate SOAP receiver should receive the SOAP message.

The actor attribute has the following syntax:

soap:actor="URI"

What is SOAP fault

SOAP defines a Fault element that is used to indicate errors that might be raised when the SOAP message is processed. The Fault element is defined below:

<soap:Fault>
   <faultcode>SOAP-ENV:Server.BadTargetObjectURI</faultcode>
   <faultstring>Unable to resolve target object: 
   HelloWorld</faultstring>
</soap:Fault>

After you include the Fault element described above, every time the target URI is irresolvable, the application will return a fault packet.

Why SOAP header is optional

Tthe Header element is optional in a SOAP message. If the Header element is present in a SOAP message, it should be the first child element of the Envelope element.

To understand why a SOAP header element is optional, consider a scenario in which you want to invoke a Web method of a Web service by using the SOAP protocol. The Web method might expect three parameters. However, to ensure that the call to the Web method is secure, you might have to encrypt the request that is sent to the Web service.

The Web method is not concerned with the encrypted information. Instead, the Web method only expects three parameters to process business logic. To have the call to the Web method decrypted before the method is executed, you can add the necessary encoded information in the Header element.

However, if the request to the Web method is sent in an unencrypted form, you might not need the Header element.

Explain different Web Services communication Models

RPC-Based Communication Model

The RPC-based communication model defines a request/response-based synchronous communication. When the client sends a request, the client waits until a response is sent back from the server before continuing any operation. Typical to implementing CORBA or RMI communication, the RPC-based Web services are tightly coupled and are implemented with remote objects to the client application.

 

Messaging-Based Communication Model

The messaging-based communication model defines a loosely coupled and document-driven communication. The service requestor invoking a messaging-based service provider does not wait for a response.