>For years I've convinced that MSSoap Toolkit was indispensable *on the server side* for answering Soap requests,
...
>So now I don't understand what part was playing the Soap Toolkit on the server, if it is not necessary for the web-service to function, and don't unserstand the DLL that .net generates automatically based on mine on VFP9.

No opinion on that, I am glad NOT to have to make that work. If an answer is sorely needed, probavly Rick is the best guy to ask around here - or at his site, if time is of the essence ;-)

>and lately I've been searching on the web about how to keep using existent web-services without it, replacing it with something else.

In Javaland there is Axis. Did not have to implement such, but had to consume some - and ran into a few things considered standard there but not available with MS tools (even Dotnet) at first, but later Dotnet consuming layers could be generated almost automatically as well. Sat through some essions on the tool chain - quite a bit of configuration files, back then about half of them equipped with optional GUI in the process.

They ALWAYS offered great bundled testbeds (usually full fledged Apache with the WS runing on it) including working and well documented examples.
This could be generated as well.
ther
Personal POV: Java is getting better, but C# IMO still is more elegant for a statically typed language. Do not argue with your customers, get it done in the environment they want. No high magic, but perhaps some listening on the wire to the XML needed if arcane security options are clicked together.

BTW: if you run across some well oiled tool chain for Node.Js, drop a link - never looked, but I am a voracious reader

;-)

regards

thomas

>On the client I know that web-services can be consumed using MSXML2.ServerXMLHTTP, but I'm talking about server side.
>
>Today I've uninstalled the soap toolkit from a virtual Windows Server 2003 SP2, and for my annoyance, the web-services keep working, so... Can somebody explain what component is answering the soap requests and passing the parameters to the components?
>
>-- Update ---
> I'm testing this, and found that when I configure COM+ to use Soap (I've using this article: http://www.kehm.de/henrik/blog/files/a5019da836d29c3cee972f5f62b5a8bd-19.html), then every time I replace the component on COM+ console (test_service.dll), a new dll is generated on a .net framework directory, inside the Windows directory (test_serviceSoapLib.dll), then the .net platform is receiving the Soap message and is calling my VFP9 MTDLL component. Awesome!
>
>So now I don't understand what part was playing the Soap Toolkit on the server, if it is not necessary for the web-service to function, and don't unserstand the DLL that .net generates automatically based on mine on VFP9.
>
>Did anybody know that? It's something new to me, totally unexpected. Up to now I've believed that for .net answering soap messages, then a .net web-service was necessary.
>
>Next week I'll try to reproduce this in a 2K12 virtual server (on which Soap Toolkit can't be installed), and if this works, I will report back.