Calling SOAP Methods

It is beyond the scope of this document to teach how to create SOAP Web Service clients. But here is a brief overview: a Web Service client on your computer system reads a Web Services Description Language (WSDL) file on one of the SBA’s computers. This specifies how to format a “SOAP envelope” for a remote procedure call to one of the SBA methods (below). The SOAP envelope is a special format of XML understood by Web Service clients and servers. (See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ ) The Web Services client encodes the request into a SOAP envelope and sends it to the chosen method. The return value of the remote procedure call will also be encoded into a SOAP envelope, which the client can then decode.

The net result is to call a procedure on a remote server as if it resided locally on the client computer.

Legacy (Separate Inputs, Names Individually Defined in the WSDL)

This is the traditional way of coding SOAP Web Services. Each input to the service is described in the WSDL file, as is the service’s output.

Some development environments require the use of a tool to read the WSDL file and generate source code that correctly encodes the SOAP envelope. The generated source code has a slang term, a “stub”. Development environments that use this approach treat the stub as the client’s local representation of the service. The rest of the client is “coded to the stub”, as if it were a local procedure.

When an SBA Web Service uses this legacy style of coding, its inputs and output will be described in this manner:

SOAP Component (URL of WSDL file)
SOAP Method (Method Name)
Inputs in the WSDL:
  • Input 1 name
    		•  (Mandatory/Optional). (Description)
  • Input 2 name
    		•  (Mandatory/Optional). (Description)
  • etc.
    		•
    Output in the WSDL:
    (Description)