Are you testing the Web service from the test page, or invoking it from a Windows Form client? When you run the Web service from VS.NET in debug mode, you are presented with a test page that can invoke methods on your Web service using HTTP POST. This is possible if the Web method receives simple types, as opposed to complex types, as parameters. Regardless, this invocation is not using SOAP protocol it uses HTTP POST protocol.
There is very little use in supporting HTTP POST and HTTP GET protocol for your Web services. First of all, it removes the ability to deal in complex types, secondly, only SOAP protocol can leverage built-in Web services support for the .NET Framework, such as that provided by SOAP extensions. I recommend you disable HTTP GET and POST protocols in the <protocols> section of the web.config (or machine.config) as follows:
<system.web>
<webServices>
<protocols>
<add name="HttpSoap1.2" />
<add name="HttpSoap" />
<remove name="HttpPost"/>
<remove name="HttpGet"/>
<remove name="HttpPostLocalhost" />
<add name="Documentation" />
</protocols>
</webServices>
</system.web>
Once you do this, you will not be able to test your Web services through the test form, but who cares? Now, what you want to do is create a Web service proxy from the WSDL contract of your service. Sounds more complicated than it is. Just create add a Web reference to your client application (such as a Windows Forms application) to the service address, for example: http://www.mydomain.com/ServicesDirectory/Service1.asmx which invokes the wsdl.exe utility to generate a C# or VB.NET class that inherits HttpSoapClientProtocol under the hood. This class, you will use to invoke the service using SOAP protocol, which will result in ASP.NET loading applicable SOAP extensions in its path.
It is very important that you turn off HTTP Post and GET protocol so that SOAP protocol is the only supported protocol for your services. Aside from supporting your own SOAP extensions, the WSE 1.0/2.0 plug-in to Visual Studio.NET are deployed as SOAP extensions as well. Without enforce messages to be processed by the Web services extension pipeline, an important step such as checking for digital signatures and decryption using WS-Security standards could be side-stepped...not a good outcome.
|
