It has been said that namespace pollution is the worst pollution in software engineering. Each organization has a different naming convention, so tools used to generate Web services stub code on another platform might have different interpretations of the namespace declarations in WSDL. Web Services Interoperability Organization (WS-I) specifications have made significant progress in eliminating the ambiguity in namespace declarations and in moving toward a uniform interpretation of the namespace, but there are still some gaps.
Consider two hypothetical .NET Web services in a retail banking branch and an investment branch of a large bank. One creates checking accounts for customers and another creates investment accounts:
Listing 3. A retail AccountService in .NET
namespace Retail
{
[WebService(Namespace="http://bigbank.com/retail")]
public class AccountService: WebService
{
public struct Customer {
public string name;
public string address;
}
[WebMethod]
public bool createCheckingAccount(Customer customer)
{
return true;
}
}
}
Listing 4. A investment AccountService in .NET
namespace Investment
{
[WebService(Namespace="http://bigbank.com/investment")]
public class AccountService: WebService
{
public struct Customer {
public string name;
public string address;
public int collatoral_amt;
}
[WebMethod]
public bool createInvestmentAccount(Customer customer)
{
return true;
}
}
}
The above two account services have the same domain, but different branches:
http://bigbank.com/retail and http://bigbank.com/investment.
Because of different requirements, the retail AccountService has a slightly different
Customer complex type than the one in the investment AccountService. Both
AccountService class files are named AccountService.asmx. This is fine and, in fact,
quite intuitive in .NET, because both account services are qualified by different URLs
that accurately reflect their domain name and branch names.
Now, if you are building a client project in Application Developer and trying to integrate the two Web services, the
situation changes. In Java code, when creating a Web services client, the package name is based
on the domain name of the namespace. Both http://bigbank.com/retail and
http://bigbank.com/investment have the same domain name:
http://bigbank.com. Therefore the generated complex data types and proxies for
both Web services will have the same package name: com.bigbank. Because we named
both .NET Web services as AccountService.asmx, and both have the same name for the
two different Customer struct types, the result is clear: when Application Developer generates proxy files, the generated stub files for the AccountService client (AccountService.java,
AccountServiceLocator.java, AccountServiceSoap.java,
AccountServiceSoapProxy.java and AccountServiceSoapStub.java) will overwrite the
files of the same name that were generated earlier. And there will be only one Customer
complex type instead of two, depending on which was generated later.
This naming conflict is a result of different naming conventions in .NET and Java technology. As
you see, a unique URL in the namespace declaration is still not safe from naming
conflicts. The solution is to qualify each Web service with a unique domain name. The
above two AccountService clients can use http://retail.bigbank.com and
http://investment.bigbank.com/ as the namespace qualifier, respectively, to
make the domain names unique.
If it is not practical to change the namespace declarations in the existing .NET Web services, the Web services client proxy generation wizard in Application Developer also provides an option to define custom mapping for namespace to package, as shown in Figure 1.
Figure 1. Define custom mapping for namespace to package in Application Developer
Comments