Skip to content

SOAP 1.2 Support

Server Support for SOAP 1.2

This requires 17.1.10.0 web app executables and lib\DefaultWebServiceMethodPage.xslt and lib\DefaultWebServiceDescription.xslt. All of our server-side web services will support both SOAP 1.1 and SOAP 1.2. There is no extra programming required to make this work. When you make a web service request, our web service module detects if a call is SOAP 1.1 or SOAP 1.2 by looking at its media type. If it is text/xml, it is SOAP 1.1. If it is application/soap+xml, it is SOAP 1.2.

Note: We considered adding an option to allow you to select if you want a service to be 1.1 or 1.2, but it really serves no point and requires extra work on everyone's part.

Client Support for SOAP 1.2

This requires a new class to support SOAP 1.2, which is cClientWebService12. It also requires that the Studio knows how to recognize and support SOAP 1.1 and SOAP 1.2 services. The WebClientHelper.vw view that allows you to inspect web services has been brought up to date so it supports both SOAP 1.1 and SOAP 1.2.

cClientWebService12

This is the new class that is used to support SOAP 1.2 services. If you are using SOAP 1.1, you still use cClientWebService. cClientWebService12 is a subclass of cClientWebService. The interface is pretty identical. A number of methods were augmented to support SOAP 1.2, but these changes are private (or NoDoc).

The cClientWebService class and, therefore, SOAP 1.1 services should be unchanged. However, some changes were made to cClientWebService, which made SOAP 1.2 subclass support easier. All of these changes should be transparent. This will be true if:

  1. They were coded properly.
  2. The developer has not made changes in private interfaces of cClientWebService.

If a developer changed private interfaces, it is their responsibility to ensure they bring their code up to date. This should be very easy to do. We changed the following methods:

  • XmlToValueTree
  • ValueTreeToXml
  • TransferErrorDescription
  • DoInvokeService

If a developer augmented these but forwarded them, everything should be okay. If a developer replaced these methods, they should bring these replacements up to date. The replacements will probably continue to work with SOAP 1.1, but probably would not work with SOAP 1.2.

There is one new property that has been added to cClientWebService, peSOAPVersion. It supports the values svSOAP1.1 and svSOAP1.2. This is primarily a read-only property. In cClientWebService, it must return svSOAP1.1. In cClientWebService12, it will return svSOAP1.2, unless you change it. You can change this to svSOAP1.1, and the cClientWebService12 object will generate a SOAP 1.1 XML. However, the more straightforward way to do this is just to use the cClientWebService superclass.

The other change in classes is in SOAP fault handling. The SOAP fault structure was changed in SOAP 1.2. In SOAP 1.1, we enclosed fault information in the properties psFaultCode and psFaultString. In SOAP 1.2, more fault information is provided, which we encapsulate in the new properties psFaultCodeValue, psFaultSubCodeValue, and psFaultReason. Even with SOAP 1.2, you can continue to use the superclass psFaultCode (which will contain code + ":" + subcode) and psFaultString (which currently contains the fault reason).

The reason we created a new class for SOAP 1.2 instead of modifying the existing class is to leave room for future change.

Studio Changes

The Studio will now recognize and support SOAP 1.2 as well as SOAP 1.1 services. Very often, a service that supports SOAP 1.2 also supports the same service in SOAP 1.1. When you have a choice of versions, you will be offered the choice of generating SOAP 1.1, SOAP 1.2, or both. You will be given this choice after you've parsed the WSDL, when you click the "Generate Class" button. The dialog for selecting the classes and saving has changed to let you select what version to generate. If you choose to generate both, two classes will be created in the same package file. Normally, there is no need to generate both classes, and we recommend against this. Supporting both versions in a client class adds extra code to your packages and complicates the naming scheme for the classes.

The primary advantage of having SOAP 1.2 client web service support is that it allows you to access services that do not offer a SOAP 1.1 version.

A Little Bit About SOAP 1.2

For most usage, the XML generated for SOAP 1.1 and SOAP 1.2 is quite similar. The biggest difference is that each version uses different namespace URIs for the SOAP Envelope, Headers, and Body, which means that the XML documents are not really interchangeable. The SOAP fault naming specifications have changed considerably. In addition, there are other small changes that were added to clarify certain SOAP 1.1 ambiguities.

Originally, a new WSDL specification was going to be used for SOAP 1.2, which is defined as WSDL 2.0. This specification was a big change and it does not seem to be used by anyone. Instead, some extensions were defined for WSDL 1.1 (which is the WSDL version used by SOAP 1.1), and that is what everyone is using. These extensions make it easy to use a single WSDL document for both SOAP 1.1 and SOAP 1.2. This is what we support in DataFlex.

Here are some SOAP 1.2 references if you want to know more:

See Also

  • What's New in DataFlex 2012 - 17.1