Just as a Java package used for qualifying a Java class allows the Java class to reside under a distinct hierachical namespace and to avoid naming conflicts between classes, methods, and so on, an XML namespace serves the same purpose for Web services. It qualifies the name for an XML element or attribute and helps avoid naming conflicts. XML namespaces are based on the need that URLs should be universally unique. However, the way that URLs are interpreted and mapped in the native code differs between platforms. The differences are usually subtle, but if they are not bridged from the beginning, they can turn out to be very difficult to fix in the end.
I will discuss several interoperability issues in relation to namespaces in the following sections, including:
- The use of relative URI references
- The use of distinct and unique URIs sharing common domain names
- The namespace issue in array types
Relative URI reference as a namespace declaration in WSDL
Relative URI references are not strictly banned in namespace declaration, but specifications offer no interpretation for them. This is usually not a problem if a WSDL file is generated from a J2EE Web service, because the target namespace is derived from the Java package names and the tool (for example, Java2WSDL) automatically qualifies them with the schemes. But in Microsoft .NET Web services implementations, if you allow the .NET framework to generate the WSDL file, the target namespace comes directly from what you have defined in the code. You might often see scenarios where the namespace attribute is assigned a relative URI. Listing 1 shows a .NET Web service coded in C# to retrieve a list of products from an inventory.
Listing 1. An inventory Web service with a relative namespace URI[WebService(Namespace="services.inventory")]
public class GetProductsService: WebService
{
public struct Product {
public string name;
public int qty;
public float price;
}
[WebMethod]
[XmlInclude(typeof(Product))]
public Product[] listProducts()
{
// getInventory() is a private method
// to retrieve all products
Product[] products = getInventory();
return products;
}
}
In Listing 1, the attribute Namespace="services.inventory" results in a
targetNamespace="services.inventory" in the WSDL file. As a result, all of the
locally-defined elements, types and attributes are scoped under a namespace with the
relative URI services.inventory. The following shows the schema part of the WSDL
document:
<xmlns:s0="services.inventory"
<types>
<s:schema elementFormDefault="qualified"
targetNamespace="services.inventory"
xmlns:s="http://www.w3.org/2001/XMLSchema">
<s:complexType name="ArrayOfProduct">
<s:sequence>
<s:element maxOccurs="unbounded" minOccurs="0"
name="Product" type="s0:Product"/>
<s:sequence>
</s:complexType>
<s:complexType name="Product">
<s:sequence>
<s:element maxOccurs="1" minOccurs="0" name="name"
type="s:string"/>
<s:element maxOccurs="1" minOccurs="1" name="qty"
type="s:int"/>
<s:element maxOccurs="1" minOccurs="1" name="price"
type="s:float"/>
</s:sequence>
</s:complexType>
<s:element name="ArrayOfProduct" nillable="true"
type="s0:ArrayOfProduct"/>
</s:schema>
</types>
The elementFormDefault="qualified" attribute ensures that the targetNamespace qualifies all of the locally-declared elements, including
the complex type Product. Suppose a second organization
implements a similar Product type with the same relative namespace. Both schemas are
imported into a WSDL document to form a common schema, as is often done using wsdl:import and xsd:import when integrating the Web service into a business process
using the IBM® WebSphere® Studio Application Developer Integration Edition (Application Developer) BPEL designer in order to leverage the common complex types
from different partner links.
In this scenario, it is highly likely that a naming conflict will occur if both imported schemas have the same target namespace. The tools used to build the integration on another platform must qualify the relative URI based on the base URI in the document tree according to RFC2396. However, in a WSDL document, the base URI is not well-defined; the interpretation of the default base URI hinges upon applications. The best practice is to always make the namespace unique by qualifying it with its own organization domain name.
Comments