Building Distributed Applications with .NET Remoting

Since the internet revolution, enterprise applications need to talk across networks to get information from different sources. This communication powers many business applications today, from business-to-business and business-to-consumer systems. It's become essential for building efficient distributed applications that work across platforms and handle complex business needs without rebuilding everything from scratch.

Building efficient distributed applications means designing for performance, robustness, flexibility, maintainability, reusability, and scalability. .NET Remoting gives you a solid framework to develop distributed applications with all these factors in mind.

Service Oriented Architecture Principles

.NET Remoting follows Service Oriented Architecture principles where client applications don't need to know how the server implements its services. This creates a transparent way for processes to communicate. When you change something on the server, you don't have to update the client. Microsoft created .NET Remoting to replace DCOM because DCOM couldn't support internet solutions properly.

The .NET framework lets you customize different stages of communication between client and remote objects to fit various scenarios. For example, you can plug in and replace the communication channel with TCP, HTTP, or any custom channel based on what you need. The rich class library helps you quickly create and use remote objects and web services. All configuration for communicating with remote objects uses XML files instead of registry-based settings like DCOM.

Understanding Activation Models

In a typical web service, object state on the server isn't maintained because the transport protocol uses HTTP. However, .NET Remoting gives you the option to maintain state or not by choosing the right activation model for your remote object, either Client-activated or Server-activated.

Every remote object has a distributed identity with state being either Singleton or SingleCall type. When you create a remote object in Singleton mode, one instance of the object services all clients that access it, and that object maintains its own state. With SingleCall type, a new instance gets created for every call from the client, and no state is maintained anywhere.

Remoting also lets the remote object on the server call asynchronous methods on the client, performing callbacks using delegates and events to achieve two-way communication.

How .NET Remoting Works

.NET Remoting uses the concept of Application Domains, which are boundaries where multiple applications run in the same process without affecting each other. Errors in one application domain won't impact another application domain in the same process.

The client in one Application Domain uses a proxy to call the remote object in the server in another Application Domain of a different process. Messages from the client get serialized using a formatter and sent to the client channel. The server channel deserializes the message using its formatter and calls the remote object to service the client.

// Server-side registration
TcpChannel channel = new TcpChannel(8080);
ChannelServices.RegisterChannel(channel, false);

// Register remote object as Singleton
RemotingConfiguration.RegisterWellKnownServiceType(
    typeof(RemoteObject),
    "RemoteObject",
    WellKnownObjectMode.Singleton
);

Console.WriteLine("Server started on port 8080");
Console.ReadLine();

// Client-side connection
TcpChannel channel = new TcpChannel();
ChannelServices.RegisterChannel(channel, false);

// Get remote object reference
RemoteObject obj = (RemoteObject)Activator.GetObject(
    typeof(RemoteObject),
    "tcp://localhost:8080/RemoteObject"
);

// Call remote method
string result = obj.GetData();
Console.WriteLine(result);

Channels and Formatters

Channels handle the transport of messages between client and server. You can choose between TCP channels for better performance in intranet scenarios or HTTP channels when you need to work through firewalls. Each channel works with formatters that serialize and deserialize messages.

// Using HTTP channel instead of TCP
HttpChannel channel = new HttpChannel(8080);
ChannelServices.RegisterChannel(channel, false);

// Configure binary formatter for better performance
BinaryServerFormatterSinkProvider provider = 
    new BinaryServerFormatterSinkProvider();
provider.TypeFilterLevel = TypeFilterLevel.Full;

HttpChannel binaryChannel = new HttpChannel(
    new Hashtable() { {"port", 8080} },
    null,
    provider
);

ChannelServices.RegisterChannel(binaryChannel, false);

XML Configuration Files

Instead of hardcoding remoting setup, you can use XML configuration files. This makes it easy to change channels, ports, and activation modes without recompiling your application.

<configuration>
  <system.runtime.remoting>
    <application>
      <service>
        <wellknown 
          mode="Singleton"
          type="MyNamespace.RemoteObject, MyAssembly"
          objectUri="RemoteObject"
        />
      </service>
      <channels>
        <channel ref="tcp" port="8080" />
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

// Load configuration from file
RemotingConfiguration.Configure("server.config");

Console.WriteLine("Server configured and ready");
Console.ReadLine();

Understanding the Limitations

Remoting expects both client and server to run Common Language Runtime, so it doesn't directly support different technology environments. To use it in mixed environments, you'll need Web Services through HTTP, which adds some overhead in development time and transaction speed. There's also no built-in security mechanism within the remoting framework, so you need to be careful when developing secured applications.

However, these limitations are outweighed by the benefits .NET Remoting provides. Using .NET Remoting features correctly can deliver maximum benefit to enterprise applications that address today's business needs.

Best Practices

When building distributed applications with .NET Remoting, keep these tips in mind. Choose TCP channels for intranet applications where performance matters most. Use HTTP channels when you need to traverse firewalls or work with proxy servers. Select Singleton activation when you need to share state across multiple clients, and SingleCall when each request needs isolated processing.

Always configure appropriate timeouts to prevent hanging connections. Implement proper error handling because network calls can fail. Consider using binary formatters instead of SOAP formatters when both endpoints are .NET applications, as binary formatting provides better performance.