SOAP formats supported by OpenEdge Web services
- Last Updated: March 30, 2020
- 1 minute read
- OpenEdge
- Version 12.2
- Documentation
SOAP messages can be formatted using different SOAP message styles and encoding combinations. The style indicates how the SOAP message is structured. The encoding describes how data values are represented. The following table lists the SOAP message formats that OpenEdge supports. You should choose the format with which your intended clients work well.
| Format | Notes |
|---|---|
| Document/Literal (Doc/Lit) | The entire message is defined as a single entity and the messages are
represented literally using XML Schema standards. This is the recommended format for
OpenEdge Web services. It works well for ABL and .NET clients. OpenEdge Web services use the wrapped document literal (Wrapped Doc/Lit) convention (developed by Microsoft). Wrapped Doc/Lit is a convention using Doc/Lit that wraps all request parameters for an operation into one input XML complex type and wraps all response parameters into a separate output XML complex type. |
| RPC/Literal | Each parameter is defined as a separate entity and the formatting of
the messages is represented literally using XML Schema standards. Use this format for clients that do not support Doc/Literal. |
| RPC/Encoded | An earlier standard. Each parameter is defined as a separate entity and the messages to be encoded are formatted according to a set of encoding rules. This format is not recommended. The Web Services Interoperability Organization recommends against this format in their Basic Profile Version 1.0. |
In practical terms, there is little difference between using RPC or Document style when exchanging request/response messages. The most significant difference between the supported formats is between RPC/Encoded (SOAP encoding) and Doc/Lit. Doc/Lit messages have the advantage that they can be validated by XML Schema. While SOAP encoding allows for a simpler representation of complex, object-oriented data structures than is possible with Literal encoding, this advantage usually does not offset the increased complexity needed to handle RPC/Encoded.