Differences between Web Service Types

Consumption capabilities. Structured Web services have a WSDL that is customized for each stored process that is in the service. This enables client application developers to create proxies that can create and read the XML documents that are exchanged with the service. XMLA services are described in the Discover call, so proxies must be manually created by the developer for calling the service.

Attachments. XMLA Web services can process XML only. Structured Web Services can read and write binary information by using attachments when using the SOAP protocol and endpoints. For example, this means you can return graphs that are generated by ODS by using structured Web Services and SOAP.

Output parameters. The only allowed output from XMLA is the _WEBOUT stream. Structured Web Services can return output parameters, the _WEBOUT stream, packages, and data targets.

Deployment. To enable a stored process for XMLA execution, you must add the XMLA Web Service keyword to the stored process definition in metadata. By comparison, structured Web service access is available for all stored processes automatically by using a RESTful URL mapped to the metadata location of the stored process. Also, you can create new structured Web services by grouping stored processes by using the Deploy as Web Service wizard in the Folder view of SAS Management Console.

Input and output types. XML and SOAP messages support all stored process input and output types including prompts, XML data sources and targets, generic data sources and targets, data tables, output parameters, streams, and packages. JSON messages only support simple prompt types (ones that can be represented with a string) and output parameters.

Endpoint addresses. The plain XML, JSON, and SOAP versions of a structured Web service are available at three different endpoint URLs.

Description files. Only SOAP Web services expose a WSDL file that strictly defines the inputs and outputs and the endpoints for the Web service. You can use this description file to create plain XML message requests for use with the XML endpoint. JSON services donʼt have a file that describes their input messages, but an input message can be formed by specifying prompt name/value pairs in JSON.

Message format. SOAP and plain XML services both use XML to convey invocation and result information. However, namespaces might be omitted from plain XML invocations. JSON services use the Javascript Simple Object Notation format for messages.