Enabling .NET Remoting Protocols
Before delving more deeply into the subject, a quick introduction is in order to explain some terms and show the steps required to activate each of these protocols.
DCOM was the only Microsoft ORPC available in the pre.NET era, available first with Windows NT 4. DCOM enabled remote communication among COM objects. Microsoft Transaction Server (MTS) and COM+ showed up later, MTS with the Windows Option Pack and COM+ with Windows 2000. MTS and COM+ introduced a new set of interception-based services that programmers could use when developing enterprise applications: object pooling, declarative transactions, and queued components, to name a few. To gain access to such services, COM components had to be deployed in COM+ applications (or MTS packages when running on Windows NT 4). COM+ applications came in two flavors: Library and Server applications. COM components deployed in a Server application can be created and invoked remotely using DCOM; all you need to do is run the Server application proxy MSI package on the client machine.
.NET components gain access to COM+ services if they inherit from the Framework-provided class named ServicedComponent, but they have to be registered in a COM+ Server or Library application as well to enable the required services (specified via .NET attributes). When the .NET component is deployed in a Server COM+ application, you can reach it remotely via DCOM by following the same export procedure required for COM-based components. Note, however, that you can use COM+ services (renamed Enterprise Services in .NET terminology) without bringing DCOM into the scene. This happens if you don't need interprocess/intermachine communication or if you choose .NET Remoting to make the ServicedComponent-derived object available across machine boundaries.
.NET Remoting is the new .NET remote protocol. Classes that must be made accessible over the network via .NET Remoting must inherit from the MarshalByRef class. The ServicedComponent class inherits from MarshalByRefObject. This is why you can expose a ServicedComponent class via Remoting. In this case, you obviously deploy the ServicedComponent in a Library application.
Web services use the Simple Object Access Protocol (SOAP) to invoke objects remotely. SOAP packages the messages going back and forth between the client and the server using XML. SOAP doesn't mandate a specific transport protocol, but the preferred one is HTTP 1.1. SOAP also doesn't cover issues such as security or transactions. Such specs are currently being developed by the W3C and WS-I.