>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?

I do the same thing. In fact, my wwBusiness object has a datamode that retrieves data over the Web in addition to standard Fox and SQL Server datamodes. This mechanism doesn't use Web Services, but pure xml or raw data transfers to a specific URL on the server which is generic. There's really no need in htis scenario for the overhead of the SOAP wrapper, especially since the 'protocol' is essentially implemented by the data service.

The same is true of something like SQL Server's Web SQL service provided through IIS.

SOAP and Web Services however make sense if you have

* an exposed API (ie many different kinds of methods to call)
* need access by different platform clients
* need an open access interface that conforms to standards

I would distinguish between a data service and Web Service where a Web Service is more like a remote API, whereas a data service is more like data backend.

This is my view on it, but you can implement either mechanism the other way around and that would work too. But I think for private apps especially, SOAP may be overkill and actually hinder performance and get in the way of streamlined development.


There are a million different ways you can use Web Services and XML Services and there never is any rules on what's right or wrong. As with everything it entriely depends on the application.