A few weeks ago, I started to use the Webservices Enhancements 2.0 for BizTalk 2004 as a newbie. Very quickly, I managed to generate a proxy-project based on an orchestration. Based on publicly available information (weblogs), I also realized a test client fairly easily.
Only recently, we started connectivity tests with the "consumer" of our webservice. We ran into the strange situation that both we as publisher and the consumer built their own test client in Visual Studio. They even looked the same. Our test client worked, and the consumer's client did not. Our test client did not work when used at the consumer's side.
A first analysis gave reason to assume that our test client somehow managed to access the webservice when run on the same LAN. When applied from outside the LAN, this special access would not be available.
In particular, a piece of the wsdl file (based on ashx in ASP.NET) that describes the BizTalk port was suspect. In the WSE 2.0 publishing wizard for BizTalk 2004, many things can be configured. After a few attempts, I was convinced that all settings were ok in the wizard. Still, the soap:address location of the port pointed to a unon-public url. The url had some sort of long host name of the machine it runs on, followed by the correct proxy virtual directory and ashx-file. No matter what I tried, I could not influence this.
The wsdl file that is shown when you request the ashx file is generated dynamically upon request. For this, the components of the proxy project (mostly compiled into a dll) are used. It is therefore not straighforward visible which setting causes this strange location name.
After a few hours of (unsuccesful) trying to change the soap:address location url of the port-section, I decided to try something else. I forced my webservice test client to acces the webservice from an "outside" (public) address. Whats struck me was that it was still working. A hardcoded proxy server reference assured that the client actually used the public address to access the webservice. I sent an updated test client to the consuming party and let them try. It worked over there as well.
Finally, they managed to find the cause of the problems with their own test client: the timeout-setting. This should be set to some 10 to 30 seconds. When too short, the timeouts that occur might lead to strange erros saying that the webservice url can not be resolved.