Try OpenEdge Now
skip to main content
Web Services
Creating OpenEdge SOAP Web Services : Exposing AppServer Applications as OpenEdge SOAP Web Services : Deciding how to expose your application : SOAP message formats : SOAP formats supported by OpenEdge Web services
 
SOAP formats supported by OpenEdge Web services
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.
Table 16. SOAP message formats
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.