>
>Well, the problem is that working with Web Services in VFP is a bit of - uh, pain. It works and you can hack your way through it, but it's a lot of work to deal with incoming data and convert it.
>
>It works reasonably well if you go VFP to VFP. It doesn't work all that well if you do VFP -> .NET/Java and back because VFP lacks the type infastructure to effectively deal with the various datatypes. For example, the SOAP Toolkit doesn't support any strongly typed data or datasets without dropping into raw XML mode. Even tools like wwSOAP which are much better at parsing results are hampered by VFP's inability to easily generate properly typed schema capable XML from objects.
>
>You can see the issues described here:
>http://www.west-wind.com/presentations/foxpronetwebservices/foxpronetwebservices.asp
>
>The best choice for VFP clients is probably to use a .NET front end for your Web Service and use COM Interop - either on the client or server or both and deal with the Web Service abstraction that way. It sure is easier than using the SOAP Toolkit if the data has anything but plain simple types being passed back and forth.
>
>Also it depends on what you're really talking about. SOA is much more than Web Services, it's a message based architecture. Designing these distributed systems that deal with asynchronous messages is difficult enough without having to fight the infrastructure, IMHO.

Rick,

Thank you very much for your input and for the link to the article. I will read it.