>Yeah, Web Services does look like a good approach for some things. However, those who already have VFp COM servers written as middle-tier components would love to see them interoperating with .NET at screaming speed, so they don't have to be rewritten as Web Services.

COM components don't have to be rewritten to be Web services. What makes them different to component is something that you don't have to deal with: the underneath plumming. VS.NET and VFP will take care of this for you. Also, the web services toolkit does this also for you today.

Here are some specifics:
The typelib is converted into an XML file that describes the component (VFP will do this work). The client will ping the server for the web services and understand the representation of the typelib so it knows what are the methods that are exposed as web services.

How do you consume it? a VS.NET Web form, Windows Form, or the Intellisense Manager code that Randy showed at the keynote, or the SOAP classes that Rick Strahl created, does an http method call to the component in the web server. The underneath plumming will activate the component, execute the method, and send the result back to the client. The result is sent back as XML. So, in other words: if the component returns an integer, when it's exposed as a web service it will return an XML file with a result tag that wraps the integer. (You don't have to create the XML yourself. The ASP or ISAPI server will do this for you as the response to the http request). The client will then do the work to interpret the XML and extract the result.

I can get into more detail, but the bottom line is that the component is a web service when it can be called by http rather than through COM. No rewriting necessary.

Makes sense? more details or explanation necessary? We should provide a white paper for people to understand this in detail for Beta 1.