>For me accessing Python (CPython, which cery likely will be encountered in examples, as well as IronPython/Dotnet) from vfp via COM was a breeze - VB6 might have been minimally easier as "the" COM language, but VB has other warts ;-)

I'm sure it's possible but requires that you have a working setup of those environments. .NET is pretty much baked into Windows or at the very least a single well defined upgrade away. Python on a Windows is not exactly a smooth setup path especially if you've never done it. Most people that do python tend to stay away from using it on Windows due to perf and config issues last I checked.

>Java/COM bridging is not easy, but if you have a working template you can get by, esp. if you only pass strings (might include XML data)


>Perhaps your extensive expirience with Dotnet colours your perception a bit in that area, making it seem easier for you ;-)

No doubt but I mainly point in that direction because essentially that's the built-in solution that Windows provides out of box.


>>All that said, just this week I ran into 2 services that .NET (or anything but SOAPUI!) couldn't handle either. The variety of crap Web services (this one was implemented in PHP) that exist is tremendous and there are no 100% automated solutions although in my experience between using .NET Web Service CLient (WSDL.exe) or WCF my success rate tends to be around 95% which I suppose is decent.
>
>More than decent IMO ;-)
>
>But the above is the reason I argue for wrapping the example often offered by the service provider, even if it means having a Java, DotNet and Python wrapper if some of the services needed are created from these languages ***and*** a default client is provided. Chances are that the example given out in the language used to ćreate the service has highest probability to work after changes. ;-)

No argument there - if you can make a proxy generator of any kind work, you're miles ahead of manual parsing, both for maintenance and ease of use - especially if the service is complex and includes massive responses (which most services tend to do).

>Setup programming cost is higher at start, but after that you can use the example provided with the change often with no or minimal changes (unless provider changes the language...) as some toolsets automatically create the fitting client side code for the language in question when generating the new version

That depends - if you have a clean service definition (ie. a reasonably well defined WSDL document) a decent proxy generator should give you a working service client in a couple of minutes. After that it's just a matter of properly navigating the service's interface contract (which is usually the more difficult part as documentation tends to be sparse or incomplete on most services). I find the biggest issues are always EXACTLY figuring out what values you have to feed the inputs and then dealing with odd data formatting issues for string data :-)

It's always amazing to me how much effort can be wasted on implementing client proxies to call services. Over my years of working with SOAP I can't count how many times I've run into issues with services where the hosted service did some flagrant violation of common sense operations in WSDL that made it extremely difficult to get a stock proxy solution to work. Usually related around a) namespaces or b) security and nonces (which are insanely time consuming to solve).

Plain HTTP ('REST') services are so much easier to deal with to avoid the data formatting issues that XSD and WSDL contracts have wrought. Yet SOAP seems to make no effort to be dying off. :-(


+++ Rick ---