Explained: Remoting Architecture

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, and Alex Mackman



.NET remoting uses channels to communicate method calls between two objects in different application domains (AppDomains). Channels rely on formatters to create a wire representation of the data being exchanged. Figure 11.1 shows the main elements of the .NET remoting infrastructure.

image: RemotingArchitecture.gif

Figure 11.1: .NET remoting architecture

The following list briefly outlines the main components of the .NET remoting infrastructure:

  • Channels. .NET remoting provides two channel implementations:
    • HttpChannel
    • TcpChannel
  • Formatters. Each channel uses a different formatter to encode data on the wire. Two formatters are supplied:
    • BinaryFormatter. This uses a native binary representation.
    • SoapFormatter. This uses XML-encoded SOAP as the message format.
  • Sinks. The .NET remoting infrastructure supports an extensibility point called a sink. The BinaryFormatter and SoapFormatter classes are examples of system-provided sinks. You can create custom sinks to perform tasks such as data compression or encryption.
  • Proxy. Clients communicate with remote objects through a reference to a proxy object. The proxy is the representation of the remote object in the local application domain. The proxy shields the client from the underlying complexity of marshaling and remote communication protocols.
  • Host. This is the process that hosts the remoting endpoint. Possible hosts include Internet Information Services (IIS) or custom executables such as a Windows service. The choice of host affects the type of channel that can be used to communicate with the remote object. Possible hosts include:
    • A Windows service application.
    • IIS and ASP.NET.
    • A Windows application.
    • A console application.


A remotable type must be created and initialized before it can be accessed. This process is referred to as activation. .NET remoting supports two types of activation: server activation and client activation.

Server-Activated Objects

Server-activated objects (SAOs) are created at the server by one of two activation models:

  • Singleton. A single object instance services all client requests. Singletons guarantee that only one object instance is in memory at any time per application domain.
  • Single call. Each client call is serviced by a new object instance. No state management is provided by this model. This model is well suited for load balancing and increased scalability.

Client-Activated Objects

Client-activated objects (CAOs) are created on the server and initiated by the client. A new instance is created for each client call to new or Activator.CreateInstance. CAOs can be stateful.

Object Lifetime

Regardless of activation type, all remotable objects can be destroyed and freed from memory by the server. This is by design and allows the server to reclaim resources that are no longer in use or active. You can fine-tune the object lifetime semantics to meet the needs of your application and prevent the server from destroying or freeing an object from memory. For more information, see "Lifetime Considerations" later in this chapter.

Personal tools