text: In a typical Web services scenario, you normally let the tooling handle all the nuances of namespaces for you. But sometimes you have to deal with namespace issues yourself, particularly if you are constructing a SOAP message for a particular Web service using the SOAP with Attachments API for Java (SAAJ). This tip is meant for those of you who have to construct messages -- or parts of messages -- without the tooling's help.
  While namespaces might seem complicated, all you really have to know is a short list of rules:
  - If the WSDL style is RPC, then you look to the WSDL binding's
  wsdlsoap:bodyelement for the namespace.
  - If
  wsdlsoap:bodyhas a namespace attribute (and the Web Services Interoperability Orginzation's (WS-I) Basic Profile (see Resources) requires it for RPC-style), then that is the namespace of the operation element in the SOAP message.
  - If
  wsdlsoap:bodyhas no namespace, then the operation element is unqualified.
  - For data elements:
  - If the element is defined by a root element (not a root type), then its namespace is the namespace of that root element;
  - If the element is not defined by a root, the element is unqualified (for a caveat to this rule, see the discussion of elementFormDefault below).
  These are simple rules, but like most rules, they need a little explanation. The rest of this tip shows you various examples of these rules in action.
  There are two typical types of Web Services Description Language (WSDL) files: RPC/literal and document/literal wrapped. There are others, but in this tip, I cover only those two. (For details of the various types of WSDL, see the paper "Which style of WSDL should I use?" -- see Resources.)
  Listing 1 contains an RPC/literal WSDL which has three operations: op1, op2, and op3. Notice the various namespaces in the WSDL file, highlighted in bold.
  Listing 1. RPC/literal WSDL
  Take a look at the namespaces in the binding's
  wsdlsoap:body elements for each operation. op1 and op2 are examples of rule 1.1 (see below for the SOAP messages). op3 is an example of rule 1.2. op1 shows the conventional example of using the
  targetNamespace -- in this case "" -- as the operation's namespace, but this is merely a convention. op2 uses a namespace not used anywhere else in the WSDL. And op3 defines no namespace at all.
  Listings 2, 3, and 4 show the SOAP messages for calls to op1, op2, and op3, respectively. Note the namespaces within the messages, highlighted in bold.
  Listing 2. RPC/literal request/response SOAP messages for op1
  As mentioned, the SOAP messages in Listing 2 follow rule 1.1. op1 has the namespace "." These messages also follow rule 2.2. None of the parameter data is defined using a root element, only a root type -- data -- and its child elements. Since no root element is used, the elements are all unqualified.
  Listing 3. RPC/literal request/response SOAP messages for op2
  The only real difference between op1's and op2's messages (Listing 2 versus Listing 3) is that op2's messages show that you can use any namespace you choose; you do not have to use the WSDL definition's
  targetNamespace.
  Listing 4. RPC/literal request/response SOAP messages for op3
  op3 is quite different from the other operations. First, there was no namespace defined, so the <op3> and <op3Response> tags are unqualified. This follows rule 1.2. (Note: Remember that op3 is not WS-I compliant -- see WS-I compliance sidebar.)
  Secondly, the part named
  in1 refers to a root element, not a root type. Since it is an element part, the part name,
  in1, is ignored in favor of the element name,
  DataElem. And since you're using the element name, you must also use the element's namespace, "." This follows rule 2.1.
  Lastly, rule 2.1 is again invoked for the type element for
  in2, which is a reference to a root element:
  RefDataElem. This element is defined in yet another namespace: "."
  Wrapped document/literal WSDL
  The WSDL in Listing 5 is the equivalent to the WSDL in Listing 1. It is document/literal wrapped instead of RPC/literal. The Java APIs generated for this WSDL are identical to the Java APIs generated for the RPC/literal WSDL, but the SOAP messages are potentially somewhat different. Once again, the namespaces are highlighted in bold.
  Listing 5. document/literal wrapped WSDL
  For op1, the SOAP messages for the document/literal wrapped service are identical to the SOAP messages for the RPC/literal service (see Listing 2). This is the most common sort of document/literal wrapped operation. Be aware that you're now following rule 2.1, not rule 1.1; you're getting the namespace from an element, not from a
  wsdl:soapbody. Notice the convention in the WSDL that the wrapper elements are defined in the same namespace as the WSDL itself: "." They could have been defined in any namespace, but by following this convention, the wrapped messages are identical to the RPC/literal messages.
  op2's document/literal wrapped SOAP messages are in Listing 6.
  Listing 6. Document/literal wrapped request/response SOAP messages for op2
  The document/literal wrapped messages for op2 make it much more obvious that you're following rule 2.1 rather than rule 1.1. You're completely ignoring the namespace in the binding's
  wsdl:soapbody.
  Finally, let's compare the SOAP messages for the RPC/literal op3 (Listing 4) and the document/literal wrapped op3 (Listing 7). Like op2, the only difference is the namespace of op3. The RPC version has no namespace, but the document version does have a namespace; just like all the other document messages, it gets the namespace from the element's namespace: rule 2.1.
  Listing 7. Document/literal wrapped request/response SOAP messages for op3
  A comment about the default namespace
  The default namespace is the one that you use to eliminate the need for a prefix. For example, in Listing 8, both e and f are in the default namespace, which is defined here as
  urn:default; e is in it because the default namespace is defined on e, and f is in it because it's a child of e.
  Listing 8. Example of default namespace use
  Here's some advice: don't use the default namespace in instance data.
  - If you use the default namespace and you take something out of context -- for example,
  <f/>-- then you have no idea just by looking at it whether that element is unqualified or whether it is qualified by some ancestor.
  - If you really want a child to be unqualified, then you must introduce the blank namespace to do it. For instance, in Listing 9, e is in the
  urn:defaultnamespace and f is unqualified in a rather strange-looking manner.
  Listing 9. Example of an unqualified name inside a default namespace
  elementFormDefault="qualified"
  A schema attribute that has an affect on namespaces is
  elementFormDefault. The default setting for this attribute is "unqualified," which is what you've been seeing so far -- child elements are unqualified. But if you add
  elementFormDefault="qualified" to all of the schemas in the document/literal wrapped WSDL, then all elements in the messages would be qualified with their parent's namespace. For example, Listing 10 contains the document/literal wrapped messages for the op3 operation from the WSDL in Listing 5 when
  elementFormDefault is qualified. In general, you do not want to use
  elementFormDefault="qualified" because it bloats the messages, but a year or more ago there were interoperability issues between various vendors, and setting this attribute sometimes fixed the problems.
  Listing 10. Document/literal wrapped request/response SOAP messages for op1 with elementFormDefault="qualified"
  Under normal circumstances, you should never worry about namespaces in the SOAP message. But there are times when you must; for example, when you have to create your SOAP message by hand. In this case, you must have a thorough understanding of how WSDL maps to SOAP. If you follow the rules presented in this tip, you should have no problem hand-writing your SOAP messages with all the proper namespaces.
  - Read W3C's SOAP with Attachments specification.
  - Understand what document/literal wrapped is by reading the article "Which style of WSDL should I use?" (developerWorks, October 2003).
  - Read the Web Services Description Language (WSDL) 1.1, the specification of WSDL.
  - Learn more about IBM and WS-I.
  - Read the XML Schema Primer.
  - Browse the Web Services Interoperability (WS-I) organization's Web pages.
  - Java API for XML-Based RPC (JAX-RPC) Downloads & Specifications provides links to the JAX-RPC 1.1 specification.
  -.
  Russell Butek is an IBM Web services consultant. He was one of the developers of the IBM WebSphere Web services engine. He.