Recently, I had problems with a Java-based Web Service for a mailing list application. To familiarize myself with the possibilities of the Web Service I created a sandbox .Net assembly with a reference to the Web Service and played around with it for a while, calling the different methods, testing the results, etc. No problem at all.
The problems began, when I added a reference to the Web Service in my BizTalk project. The project simply wouldn’t compile after adding the reference! Apparently, there was a naming clash between a part of the Web Service and some word restrictions imposed by BizTalk. It must be BizTalk specific, since a non-BizTalk project compiles perfectly well with the Web Service reference.
Actually, the error messages when compiling weren’t really helpful, so I can’t say exactly what the problem was. However, that’s not the point of this post anyway so never mind that.
The point of this post is to talk about what you could do if you for some reason want to use a Web Service in a BizTalk project without using the built-in feature in Visual Studio to generate a proxy.
You could choose to create some sort of wrapper or proxy for the Web Service yourself – it could be a less complex Web Service, or simply an assembly that could be called directly from an expression shape in an Orchestration. Both of these approaches would allow you to only implement support for the needed parts of the original interface, thus keeping the complexity to a minimum. This was desirable in my case, since the original Web Service had 30+ methods – try adding a couple of ports for such a Web Service in an Orchestration!
The obvious downside to this approach is that you actually have to code the wrapping of the Web Service yourself – with all the usual possibilities of introducing bugs. Also, if the Web Service interfaces changes you’ll have to update the wrapper code manually.
There’s also an automated approach that will create a wrapper class (proxy) for you. In the C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin folder you’ll find the command-line tool WSDL.exe. With this tool you can generate an assembly – or proxy if you will – that matches a specific Web Service. This is the approach I chose for my project.
Executing WSDL.exe from a command prompt will display all the functions of the tool. Some of the important ones are:
- First of all you have to specify a URL to an instance of the Web Service.
- /namespace - set the namespace of the generated code.
- /username and /password - set the credentials used to make a connection to the original Web Service.
- /out - set the ouput filename for the generated code.
- /urlkey - set the name of a config key to store the URL for the original Web Service.
Rather than having configuration information spread out on a number of config-files, I chose not to use the /urlkey option. Instead I added a key in the BtsNtSvc.exe.config to store the URL of the target Web Service and used this to set the URL runtime in the Orchestration – the generated proxy-code includes a method to set the URL for the target Web Service. I used the same approach to set the username and password for the target Web Service runtime as well.
The generated assembly of course needs to be strongly named.
You can read more about WSDL.exe on http://msdn2.microsoft.com/en-us/library/7h3ystb6(VS.80).aspx.
The tool also exists in a .Net 1.1 version.
No comments:
Post a Comment