Server-Side Data Flow (Windows Embedded CE 6.0)

1/6/2010

On the server side, the SOAP Toolkit provides two options for implementing a SOAP listener (the handler of incoming SOAP requests on the server):

• An Internet Server API (ISAPI) server
• An Active Server Pages (ASP) server

Note

SOAP is an industry-standard protocol. The SOAP Toolkit server can handle requests from SOAP clients implemented using a variety of technologies, as long as the messages transmitted by these technologies follow the SOAP protocol. Similarly, the SOAP Toolkit client can communicate with SOAP servers implemented using other technologies.

In the Web Services Description Language (WSDL) file, the URL identified as the server-side handler of the SOAP request determines how the SOAP request is handled on the server.

For instance, the following WSDL file syntax example identifies the URL (shown in bold) that invokes the ISAPI listener:

<definitions>
...
<service name='Calc' >
    <port name='CalcSoapPort' binding='wsdlns:CalcSoapBinding' >
      <soap:address location=' />
    </port>
  </service>
...
</definitions>

Reviewing the Server-Side Data Flow

Regardless of whether the SOAP request invokes an ISAPI or ASP listener, how the server handles the incoming and outgoing data is the same.

The SoapServer object, (accessed through the ISoapServer interface) receives the SOAP request from the client, processes that request, and forwards a call to the COM method that matches the requested operation.

In the following illustration, this is the call to the AddNum method. The method that was called then sends the result of the requested operation back to the SoapServer object, which then formulates this information into a SOAP response that the object sends back to the client.

The following diagram illustrates how SOAP handles data flow on the server.

Processing Inside the SoapServer Object

The ISoapServer and ISoapClient interfaces are considered part of high-level API. In your application you use the ISoapServer interface to process SOAP requests and the SoapServer object does several things internally.

The following diagram illustrates how the SoapServer object processes SOAP request message and formulates SOAP response messages.

Here is what happens:

1. Upon receiving a SOAP request from the client, the SoapReader object (accessed through the ISoapReader interface) loads the request message into one DOM structure; the WSDLReader object loads the WSDL and Web Services Meta Language (WSML) files into another DOM structure.
2. The WSDLReader parses the request and creates a WSDLOperation object for the requested operation.
3. The WSDLOperation object calls the WSDLOperation::GetOperationParts method, which returns from the WSDL/WSML DOM tree a collection of the parts defined for both the operation's input and output messages.
4. The SoapServer object creates SoapMapper objects for each of these parts and loads the values from the SOAP request into these SoapMapper objects.
5. The SoapServer object calls the COM method corresponding to the requested operation.
6. The COM method processes the parameters included in the call and returns the result to the SoapServer object, which maps the return value to the appropriate SoapMapper object.
7. The SoapServer object uses the SoapSerializer object (accessed through the ISoapSerializer interface) to build a SOAP response message for the result value.
8. The SoapServer object sends this SOAP response message to the client.

The WSDLReader, WSDLOperation and SoapReader objects, and so on, are considered part of the SOAP Toolkit low-level API. Instead of using the ISoapClient high-level API, you can use the low-level API in your application.

For more information about high-level and low-level APIs, see the Calc sample applications described in SOAP Samples.

See Also

Concepts

SOAP Application Development
Client-Side Data Flow
Specifying an ISAPI Listener
A Quick Introduction to WSDL
A Quick Introduction to WSML
SOAP Samples