As of today SOAP encoding only exists due to some historical reasons non of the standard web service framework supports for SAOP encoding that includes Axis2, Metro and CXF. Some people still tend to use SAOP encoding without knowing why WS frameworks discourage to use it or some have to use it when they implement web service clients. Usually I can see number of such queries on axis2-user list time to time. Here I discuss few workarounds useful when you dealing with SAOP encoding.
What is SOAP encoding
When authors of SOAP specification write it for first time they wanted to define a common way to describe messages but at that time XMLSchema was not completed and not in main stream too. Hence they came up with idea of SOAP Encoding as an extension of the SOAP specification that defines how a data value should be encoded in an XML.
SOAP encoding define it's own namespace as http://schemas.xmlsoap.org/soap/encoding/ and set of rules to follow. SOAP encoding introduced number of interoperability and validation issues. Tim Ewald described some of those issues in his article
here.WS-I also highly discourage to use encoding systems in their basic profile.
SAOP encoding in server side
If you use code first approach there is nothing to worry
Axis2 runtime generate WSDL that does not use SOAP encoding at all. But if you use contract first approach you need to make sure that you don't use SOAP encoding in your service contract instead XMLSchema provides very powerful type system for your messages.
SOAP encoding array concept is still used by many people, if you have such legacy WSDL file you could easily redesign your types using XMLSchema. Following example describes one such scenario.
First let's see SAOP encoding sample.
<complexType name="ArrayOfStrings">
<complexContent>
<restriction base="SOAP-ENC:Array">
<attribute ref="SOAP-ENC:arrayType"
wsdl:arrayType="xsd:string[]"/>
</restriction>
</complexContent>
</complexType>
Now same thing can be easily rewritten using XMLSchema as follows.
<complexType name="ArrayOfStrings"
<element name="item" type="xsd:string" maxOccurs="20"/>
</complexType>
SOAP encoding in client side
Sometimes it is required to access services that has service description with SOAP encoding constructs. By default Axis2 code generation tool called
WSDL2JAVA fail on generating codes for such WSDL files. But as a workaround you could use
XMLBeans data binding to generate clients codes for above WSDLs. XMLBeans simply generate Java beans for all the types available on schema . In this case it generate beans for all the types available on SOAP encoding schema
here.
You can invoke code generation tool with XMLbeans data binding as follows.
wsdl2java.sh -uri service.wsdl -d xmlbeans
Conclusion
As we discussed the best practice is avoid use of SOAP encoding when you design web services.In case if you are a consumer of service that use SAOP encoding in their WSDL, Axis2 XMLBeans data binding provide a great solution for you.
