1.1 Evolution: from COM to .NET

I am going to start by telling the story of how .NET came into being. Skip this section if you don't like history lessons.

1.1.1 The pioneers: COM, MTS and DCOM

Two significant Microsoft inventions to dominate the enterprise arena were MTS and COM technologies in the mid 90s.

If you are unsure of COM, you can just treat a COM module as a piece of software which has been written so that it is self-sufficient (properly encapsulated) and can be used by other classes without them knowing how the COM object is implemented internally. If this description reminds you of Javabeans, you are correct. A COM object is Microsoft's version of Javabeans. They are software components that can be bought off-the-shelf and integrated into your own applications. Talk about COM, and you might hear phrases such as 'reuse through interfaces' and 'component-based development'.

In theory, it doesn't matter which language is used to write COM components “ those written in Visual C++ can be used in the same way in Visual Basic codes and vice versa because COM interfaces ^[2] are used for communication.

^[2] Not to be confused with 'interfaces' as used in Java or C#, COM interfaces are more like the IDL files of CORBA. It describes the public methods of a COM component, so that external codes are able to invoke them.

MTS is a middle- tier (or middleware) server which takes care of issues like transactions and security. MTS is like an EJB container in J2EE terminology, but not as complex. MTS is a layer built on top of COM and DCOM. It provides plumbing services in very much the same way as your EJB container provides them to the enterprise beans living within.

Like enterprise beans, COM components live in the MTS, which also provides them with services such as transaction, connection pooling, security, thread pooling, synchronization, and an administrative user interface.

DCOM is a remote invocation protocol from Microsoft. Like Java's RMI, DCOM's usage has been limited due to its platform bias.

1.1.2 Distributed interNetwork Architecture

Then came what Microsoft's marketing team coined as Distributed interNetwork Architecture. DNA is built with Windows 2000 as the backend server operating system working together with other Microsoft servers, such as Exchange 5.5/2000, SQL Server 7/2000, Site Server (or the newer Commerce Server 2000), SNA Server (or the newer Host Integration Server 2000), and others. Besides emphasizing n -tiered architecting (separation of presentation, business logic, and data services), DNA also saw the merger of COM and MTS into what is known as COM+.

COM+ improves over COM and MTS through new features such as role-based security (at method level), object pooling (as opposed to thread pooling of MTS), queued components (to work with MSMQ) and COM events. COM events are services which provide a mechanism for COM components to publish or subscribe to events.

That's all old stuff today.

Originally named COM+ 2.0, .NET blew COM and COM+ away with an entirely new framework, new programming languages, new code libraries, and new ideas. Although it is still possible for .NET components to communicate with COM components and vice versa, ^[3] it seems that technologies like COM, DCOM and COM+will be labeled 'legacy' in the near future.

^[3] .NET treats COM components as legacy pieces of code. You can still use COM components in .NET applications by using a wrapper. COM components can also communicate with .NET codes via a wrapper. COM interoperation (or how to make legacy COM codes work with .NET codes) is an important topic in most C# and .NET books, but has been excluded in this one.