MAF vs. COM

OK, I know I said my next post would be an in depth treatment of IContract, but I remembered I wanted to fininsh something I started with my earlied post Addins in .NET. I noted there that .NET currently was still analogous to the LoadLibrary\GetProcAddress era of Win32. In other words, it didn't have the analog of COM for .NET yet. Well, of course, MAF is the begininng of COM analog for .NET -- it provides the base infrastructure to begin to make addin models, and any dynamic component model, easier.

What MAF provides is the managed analogs of IUnknown, IDispatch, ITypeInfo, IMarshal, IEnumXXX and CoCreateInstance . IContract, which really will be covered in depth in my next post, is the managed analog of IUnknown. And in essence it covers IMarshal as well, because all contracts must be written to allow remoting -- we don't *require* that each addin be isolated or remoted, but the system has to allow it so that all addins *may* be isolated and remoted.

IRemoteObjectContract and IRemoteTypeContract (and friends) are the analogs of IDispatch and ITypeInfo and the COM type library stuff. It is important to note that *analog* is very operative here: the MAF system is quite different from the COM system due to the fact that managed code is quite different from native code, for one, and that the object-oriented nature of .NET is quite different from the procedural nature of old Win32. I will of course have extensive articles on all of these contracts in the weeks to come.

MAF also provides a set of collection contracts. Besides providing standard collection definitions, they also provide the notion of a MarshalByRef collection, something missing from the .NET framework right now -- and necessary for MAF as you will see. And analog is operative here, because the MAF collection contracts very closely resemble the .NET Collection paradigms as opposed to the IEnumXXX style of COM.

Finally, the AddinLoader provides the analog of CoCreateInstance. In other words it is the helper that wraps up all the complexity of securely activating the addins or dynamic components. Of course in MAF we do even more work that COM because we have AppDomains and the CLRs Code Access Security system to make MAF even more robust.

Stay tuned, more details than you may even want will be forthcoming.

Comments

• Anonymous
  September 16, 2005
  what about marshalling overhead when communicating with the addin host?
  
  As I understand addins will reside in their own app domains, then there will be performance issue...
  
  IMHO old time paradigm of LoadLibraryGetProcAddress like .NET addins has greater performance if used in the environment, where we have managed host & addin...
• Anonymous
  September 19, 2005
  The comment has been removed