Java Reference
In-Depth Information
sumers to automatically redirect based on receipt of this status, however, as many services
could be participating in automated processes.
SOAP fault messages should indicate HTTP 500 Internal Server Error. You probably
won't have to deal with the HTTP return types directly, unless you are using SAAJ to cre-
ate responses from scratch.
Cookies
Cookies
Cookies may be used, but this is not encouraged, and services should not break for con-
sumers who don't understand cookies. Because cookies are out of band for SOAP, they
probably aren't a great idea. I can't think of a really strong case for using them in a service,
especially if you are still conforming with the Basic Profile's mandate that your clients
don't break if they don't support cookies.
Use XML 1.0
Use XML 1.0
XML 1.0 is the only version that the BP supports for XML Schema and WSDL.
Use UTF-8 or UTF-16 encoding
This should be self-explanatory.
No namespace coercion
This means that the targetNamespace indicated by the WSDL definitions element that is
being imported must be the same as the namespace of the WSDL you're importing.
Do not require support for WSDL extensions
This means that indicating “required=true” for WSDL elements is discouraged:
<wsaw:UsingAddressing required="true"/>
It's best to define requirements in policies where possible. If you decide to require certain
items, then consumers that don't support those items must fail processing.
Beware of arrays
Usage of the array types in WSDL 1.1, section 2.2 has left proper usage somewhat unclear,
leading to a variety of interpretations regarding how they should be used. WSDLs must
not extend or restrict the soapenc:Array type, or use a wsdl:ArrayType in their types
section. Likewise, SOAP envelopes must not include the soapenc:arrayType attribute.
See Dealing with Arrays for a workaround.
Search WWH ::




Custom Search