>>Just wanted to bring up the other side of calling VFP components that you guys don't talk about too much: web services. If you expose your VFP components as web services then the CLR will never treat them as COM components. You have the web server where the component is called sending out XML and responding to an http method call. The CLR will consume and process XML and not talk to COM. Again, we have no complete data on performance in that scenario but we believe it will be a key way for VFP developers to expose components in .NET apps.
>>
>
>Ricardo,
>
>There's an interesting implication here if I read you correctly - with the new XMLToCursor and CursorToXML capabilities, it would seem that we can hop right in and play, with the XML actually surfacing our interface for us -

The SOAP toolit already 'surfaces' the interface for you by reading your typelib and generating an SDL file that describes the interface in XML. An SDL aware client (like ROPE) can build a proxy for you that exposes a copy of your interface. This proxy, and its counterpart, the Listener.asp do all the XML translation for you. No need for any native XML functionality like CURSORTOXML.


>I'd originally thought in terms of a BizTalk environment for this, but in fact it's providing a really simple mechanism to let us surface a complex interface without the need to build individual custom COM components - a couple of classes that can surface and sink XML streams, and as long as we don't need to subclass the VFP wrappers internally using a CLR language, we can develop VFP components and use them inside .NET modularly.

If Web Services are the new way, .NET won't know and won't care what sort of component the server is, and vice versa. Their only interface happens through SOAP.

>A couple of questions arise from this, though. The biggest concern to me is that, if an XML stream is used to 'publish' our interface, how exactly do we inform .NET of changes to the interface?

Through a new version of the SDL (or SCL, as it will soon be). The contract won't be broken unless previously used functionality was used by existing clients. Because of the nature of XML, extra interface features won't break anything. With Web Services, there is no concept of early or late binding because its not COM. The client knows no details about the service except its URL, and the names and parameters of its methods (ok, a little like late binding). VFP objects will use VFPRope.dll to generate the calling XML, and unmarshall the return XML into its return value. You can already do all of this with Rope.dll and the Rope.WireTransfer object, but VFP7 will have built in support both for creating web services and using Web remote services in your projects.

>Will there be a mechanism to publish an XML interface document, similar in concept to what we do now in publishing a typelib, so that we can let other, non-VFP-aware things query the capabilities of our interface?

That's what the SDL/SCL file does. With Typelibs, the location of the Typelib is published in the registry, with Web Services, instead of a TypeLib reference in your project, you use the URI of the SDL/SCL.

>This approach is ideal for an environment like BizTalk - it's clear that we'll be able to write components for BizTalk using VFP, a very good think from my POV.

WE can _almost_ do this now. We can certainly write client BizTalk components, and the only thing holding us back is the lack of ability to inherit an interface (BizTalk requires that you implement IBTS_ something or other).