Working Without a WSDLWeb services may work without a WSDL file, and sometimes the user may be forced into a situation where a WSDL file is not available. It is possible to use this client without a WSDL. Although it is much more convenient to use with a WSDL file. In order to use the client without a WSDL it may be useful for the user to take a look at the SOAP specification. This is available at http://www.w3.org/TR/SOAP/. A user can invoke a web service using the InvokeServiceOperation. In order to properly invoke this function the user must provide a proper SOAP message. The ToServiceRequest function can be used to build a request message. In order to use this function, two parameters must be provided. The first parameter is a list of the parameter of the web service operation that will be invoked. The second parameter is a list of the header's of the web service operation that will be invoked. Both of these parameters should passed in as a list of rule syntax expressions or symbolic XML elements. It is necessary to pass the full definition of the parameters since a WSDL is not present to provide information. This includes the name, type, or any other information needed by the web service. The options are also very important to building the SOAP envelope. These are defined in the table here.
| Option | Description | | OperationName |  | | OperationStyle |  | | SOAPActionURI |  | | ReturnType |  | | TransportStyleURI |  | | EncodingStyle |  | | EncodingStyleURI |  | | HeaderEncodingStyleURI |  | | Username |  | | Password |  |
| Out[33]= |  |
The request message can then be invoked using the InvokeServiceOperation function. The first parameter of this function is the endpoint URI. The endpoint specifies where to send the request message. This URI is generally found in the WSDL.
| Out[34]= |  |
When using SOAP encoding, the client will add types to the elements in the parameters list passed to ToServiceRequest depending on the Mathematica type. Therefore, in this example it is not necessary to add type information because SOAP encoding is specified. The simple types supported are defined here. However, when the results are returned, if the types are not encoded in the data returned, the values will not be converted from strings.
| Mathematica Type | XML type | | String | {http://www.w3.org/1999/XMLSchema}string | | Integer | {http://www.w3.org/1999/XMLSchema}int | | Real | {http://www.w3.org/1999/XMLSchema}double | | True, False | {http://www.w3.org/1999/XMLSchema}boolean |
| Out[35]= |  |
| Out[36]= |  |
However, if the web service is expecting an XML type other than the type mapped from a Mathematica type, it may be necessary to add type information. For example, a real maps to a double, but a real also represents a float in Mathematica. If a real value is passed as a parameter, it will be encoded as a double. A web service expecting a float may not handle this correctly. To correct this the user should specify the type. It may also be necessary to specify the type for compound types. Compound types do not have an XML type automatically associated with them.
| Out[37]= |  |
| Out[38]= |  |
Once a web service function is called using InvokeServiceOperation the results come back in the form of a SOAP envelope. FromServiceResponse can be used to extract the results from the SOAP envelope. If the message uses SOAP encoding and provides types in the response message, the data will be deserialized into the proper Mathematica types. If not, the SOAP envelope wrappers will be stripped and the response will be deserialized into a rule syntax expression with string values.
| Out[39]= |  |
If a web service operation is used often, the operation can be installed more permanently using InstallServiceOperation. InstallServiceOperation installs the operation as a Mathematica function. The first argument specifies the function name. It is a Mathematica symbol. The second argument is the endpoint URI. The third argument is a list of parameters, and the fourth argument is a list of headers. These last two arguments work similarly to ToServiceRequest. The major difference between InstallServiceOperation and ToServiceRequest is how the parameters are passed. ToServiceRequest requires the values to be passed in the parameters. However, for InstallServiceOperation, the parameter values will be supplied later, when the function is called. Therefore, only the left side of the a parameter in rule syntax needs to be passed to InstallServiceOperation. Passing the left side specifies to the function what the parameter is. However, it also allows the user to omit this information when invoking the function. An example is provided here. It specifies the method getTemp, which requires a parameter called zipcode.
| Out[40]= |  |
| Out[41]= |  |
If the user wants to specify more information than just the name, that can be accomplished in a similar way. The user just needs to use the left side of the rule syntax.
| Out[42]= |  |
| Out[43]= |  |
| 
