>With the wrapper approach you should be able to implement just about any solution without ever having to go stateful on your objects. I've never had a sceario where more state than an ID was required which you can possibly store in a Session variable (if you're using the ASP or WWWC SOAP implementations - that won't work with the ISAPI connector though).

Hi Rick.

As I understand them, most implementations of web services are used to "supplement" an application. for example, an on-line store has a web application that manages "shopping carts" has a database of inventory and a means of ordering items. Then, they may consume a web services published by the shipping company so that customers can track their shipments right from the on line store web application.

I'm hoping to do something a bit different. I am hoping to build a web service primarily for "private" use - that is, only my fat client applications will be using them. The service performed by the web service is data handling. In other words, I have a "Data Service" object on the server that "knows" how to communicate with my database (be it VFP, Oracle, Sybase, SQL server) Its exposed methods are Query, Insert, Delete, and Update. My vfp business objects use these 4 methods of the data service object - they never use the tables/views directly. My idea is to wrap this stateless "data service" object into a com server and eventually a web service.

Then, my fat client consumes this "data service" web service in order to Query, Insert, Delete and Update. The result: a distributed VFP client/server application that uses the internet to transfer data from client to server and vice-versa.

Does this seem like a reasonable application of a web service?