Web Services Interoperability between J2EE and .NET - Part 3

Page 2 of 4
  1. Introduction
  2. Unique namespace URIs sharing common domain names
  3. Namespaces and sharing XSD schemas
  4. Conclusion

Unique namespace URIs sharing common domain names

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

You might also like...

Comments

About the author

Wangming Ye United States

Wangming Ye is an IBM Certified Enterprise Developer and a Sun Certified Enterprise Architect for J2EE Technology. He began as a developer in the DCE/DFS department at Transarc Corporation (late...

Interested in writing for us? Find out more.

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“There are 10 types of people in the world, those who can read binary, and those who can't.”