>>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.
>
>I wasted two days learning that Soap can't consume a JAX web service. Something about redirection, i.e. in the place where the parameter descriptors should be there's a local link to the file containing them. And even though I got those (manually), in the end I was still unable to even pass parameters to the call. Then discovered that they also offer FTP, for which I wrote a listener in just a few hours.

Simlar expierience here: they can configure how he security token is handled, downto mangling into different parts of head or body, which was not well received by Dotnet. Had to manually parse and build the XML, because Dotnet layer would have been acceptable to client, but adding Java via COM just as a communication endpoint with/for automatic parsing was considered to Goldbergian. So back to basics: XmlHttp handled directly from vfp, as Ricks vfp stuff back then did not handle security certificates easily - early this century... The redirection you wrote about probably was in one of those XML settings available to fine tune the thing server side: you can do a lot (including publishing most of the settings as well) but that is watched over by house policy.