Remoting with Com+

from An inner mail from my team:

Remote Components

The class ServicedComponent contains MarshalByRefObject in its inheritance tree and therefore can be accessed from remote clients. There are many variations of how to expose serviced components remotely. Serviced components can be accessed remotely using:

  • The HTTP channel with serviced components called from or written in ASP.NET offers good security and encryption options, along with known scalability and performance. When used with SOAP, more interoperability options exist. Serviced components can be hosted in IIS/ASP.NET as a COM+ library application. If a COM+ server application is used, the IIS/ASP.NET host can access the components using DCOM.
  • An alternative way to expose a serviced component as a SOAP endpoint is discussed in COM+ Web Services: The Check-Box Route to XML Web Services.
  • DCOM when serviced components are hosted in Dllhost. This option offers optimal performance and security and the ability to pass service contexts cross-machine. The major design question when choosing a remoting technology should be whether or not the services need to flow across machines. For instance, within a server farm where a transaction is created on one machine and it is required for the transaction to continue on another machine, DCOM is the only protocol that can be used to achieve this. However, if clients need to simply call a remote ServicedComponent, then the HTTP channel or SOAP endpoint approaches are good alternatives.
  • A .NET remoting channel (for instance, a TCP or custom channel). To use the TCP channel you need a process listening on a socket. In general, a custom process is used to listen on a socket and then host serviced components either as a COM+ library or server application. Alternatively, Dllhost can be used as the listener. Either approach is least likely to be used and would require writing a custom socket listener with proven performance, scalability and security. Therefore, the ASP.NET or DCOM solutions are the best approaches for most projects.


           from the msdn::


Assuming the DeactivateOnReturn bit is set during each method call, the sequence of method calls would be: the class's constructor, Activate, the actual method call, Deactivate, Dispose(true)

Comments (0)

Skip to main content