>>I've heard this several times now, so I wondered if .NET is intended to replace COM completely for the developer. I can see it possibly replacing COM for ActiveX, multi-language projects, and Web Services. Is there a mechanism in .NET to replace COM for Automation? Also, if you want to split up processes among several computers on the server side, wouldn't COM+ be a better choice? Or should we expect that all components will "evolve" to Web Services? Personally, I don't think I would want to expose everything, and I could probably do without the extra overhead of Web Services and IIS where they are not needed. What's your take on this?
>
>COM and automation are the same thing... Automation is just a special interface (IDispatch). I think Microsoft is working hard to expose all the COM interfaces that were exposed via IDispatch via the .NET framework. Things like Office DMO surely will be accessible through .Net in the future, but not right now.
>

So, does that mean that .NET applications will be able to expose interfaces by means of "self-describing components"? Without distributing source code? I assume it does this without the extra overhead associated with COM. Would VFP be able to access these interfaces through the COM interop layer, in the same way it can get to the .NET Framework?

>Breaking up processes: .Net will handle that and Web Services is one way that you can accomplish that and it will be more stable than the current DCOM based mechanisms that are used which are quite frankly - crap. Today distributed COM+ works only with hideous configuration and security issues and Web Services promise a much easier path to distributed computing even if there's more overhead and slower performance. But if properly designed additional overhead may not be as excessive as you think. As far as exposing goes - no different that DCOM. If you hide the Web Services properly then there's really not much threat of unwanted interference. Plus there will be security support in the next version of SOAP (which probably won't make the initial relase of .NET though).
>

My concerns about performance and overhead come from the understanding that Web Services always communicate over http by means of XML messaging. Is that correct? I think that would mean that each server hosting a Web Service would require IIS or some other web server, and there would be additional overhead creating/consuming the XML. To be honest, I have no idea how this compares to the overhead associated with DCOM. Like you said, other factors may outweigh performance in this area.

>+++ Rick ---
Balance?

BTW, looking forward to your sessions at DevCon. Thanks.