I don't know the internals of ODBC (I don't know how many people would be able to answer those questions) but here are the answers for some of your questions in teh Web Services column.

>a) Execution charactersitics like
>--- Where it actually runs

The Web Service itself runs on the server.

>--- Whether it uses Rushmore

If its written in VFP, yes.

>--- Within a VFP app., are it's buffers or caches separate or shared

Really depends on the Web Server and how its configred and administered.

>--- 'state' considerations

You shoudl be designing your applications to be stateless anyways. Thats the best way to make something scale (something Web Services are designed to do).

>--- Data format conversion requirements (like to/from XML)

Once again, it really depends on what your web service returns, you get to choose. Typically, Web Services use XML. If you can get away with something non-XML, you probably don't need web services. Just because we have Web Services, don't rule out the use of DCOM where appriopriate.

Remember, to VFP developers, creating a VFP Class, (D)COM server, or SOAP compatible web services is exactly the same jsut compile differently.

>b) Performance expectations like
>--- overhead per use (call)

Once again, the more calls, the more overhead (just like in COM where VFP needs to pass through the COM barrier, Web Services need to make an HTTP request every time you talk to the server). You should aim for stateless.

>--- volume of data over the wire

You can try it out. Whatever your web service needs as parameters and whatever it returns goes over the wire in Soap Envelopes.

>I'm confident that I understand 'regular' VFP considerations, thought that I had a handle about ODBC and really like the concept of Web Services best but have NO sense about it at all.

You should read the article at MSDN called "How to make Web Services with VFP7" or similar. Using The Wbe Service Publisher and Intellisense, creating a Web Service from a VFP Class takes 5 minutes.