A few interesting bits from c2.com’s “ComIsLove”, of all places…

“The problem is the definition of COM. Here is a summary of how COM/COM+ are affected by the .Net Framework.

COM and COM+ are many different things. It is a low level API based infrastructure that consists of APIs like CoSetProxyBlanket, AddRef, Release, QueryInterface, etc. It is a programming model that revolves around creating objects and calling methods on those objects (procedure oriented). And it is a set of services that sit on top of both of these things that apply and provide behavior to the objects such as synchronization, pooling, transactions, etc.

Over time, the .Net framework will replace the underlying goo. Everybody agrees that this is good.

However, the programming model is here to stay. The way it is implemented might change – for example, the procedural programming model might be built on top of a messaging layer, which programmers also might have access to. I believe the installed base of applications that depend on this type of programming (e.g. VBScript for Office, ASP pages, etc.) and the familiarity that programmers have with it means that this is here to stay.

The services are definitely here to stay. The requirements for them are not going to go away – anybody who writes a business app will likely need to use these services when they use the .NET framework. Our goal is to make accessing the services from the .Net framework as seamless and as easy as possible. We’ve made great strides for this in V1 of the .Net framework – there are custom attributes for virtually all of the services, we do automatic registration when unregistered components are created, etc. We plan to make this even better in subsequent releases of the products. We recognize that some of the benefits of the .Net Framework (like XCOPY install/uninstall, automatic memory management, etc) are currently reduced when using some of the COM+ services inside the .Net Framework. However this is a function of schedule and not intent. We will be working diligently to integrate these services with the .Net infrastructure and create a seamless experience for our customers to use the whole of the .Net platform.

It is important to understand that we are not throwing out the old and bringing in the new. We are refocusing our platform to empower the next generation of the web. In doing so we are leveraging all of the assets we currently have and the existing COM+ features are key to this platform. The DCOM protocol is an interesting issue. Clearly our story for the Internet is HTTP and SOAP. Some intranet scenarios will use this too because there is increasing use of firewalls to partition corporate Internets. That said, DCOM is a high performance binary remoting protocol and is valuable in some tightly-coupled scenarios. In fact the common language runtime object remoting services use DCOM for some remoting. We will have to see how this evolves in the future, but there will likely always be a need to a higher performance protocol than HTTP and XML.”