I'm working on a project where I already have WSDL. The WSDL has three Web method. The first Web method is HTTP-GET only. The other two Web methods are SOAP only. So I use wsdl.exe to get a
server, not client, proxy. Well, wsdl.exe only allows you to create proxies, based on a single protocol. Ok, I will just run it twice. Once to get the HTTP-GET server proxy, once to get the SOAP server proxy, and finally merge the two files
Now I make a few adjustments, like remove "must override", return dummy values from the methods and compile. Success? Nope. When I take my newly created Web service, tack on ?wsdl and look at the WSDL generated, I see that all
three Web methods are accessible via both HTTP-GET and SOAP. Conclusion:
So I investigate whether I can magically sprinkle some attributes on my Web methods so the correct WSDL is generated. After looking a WebMethodAttribute, SoapDocumentMethodAttribute, etc. it looks to me that it is impossible to create a Web service in .NET
where the Web methods are attached only to a specific protocol regardless of what is specified in Web.config. Web.config allows you to specify what protocols are allowed to be generated for the .asmx?wsdl. However, there is nothing to tie your individual
Web methods to a specific protocol. They will inherit all protocols defined in Web.config.
To take the original scenario, if my Web.config contains:
and Web method1 is only HTTP-GET and Web method2 and Web method3 are only SOAP, and I remove the <add name="HttpSoap"/> then .asmx?wsdl should generate WSDL that contains only Web method1 in it. It doesn't quite work that way since all your Web methods inhert
all protocols. So when the <add name="HttpSoap"/> is removed, we get WSDL generated that contains Web method1, method2, and method3 associated with HTTP-GET.
The purpose of the original WSDL was to have a single Web service where some Web methods are
only accessible via REST (HTTP-GET) and other Web methods are only accessible via SOAP. The WSDL make this clear, but .NET cannot follow the directions.
Any .NET gurus out there who can solve this problem or is this a gapping hole in .NET Web services development?
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.