C# Remoting Architecture
The .NET Remoting framework facilitates interprocess communication between application domains by utilizing a robust Remoting Framework. This communication capability extends to applications residing on the same computer, different computers within the same network, or even across separate networks. With support for distributed object communications, .NET Remoting utilizes the TCP and HTTP channels to enable seamless data exchange.
The framework optionally uses the Binary or SOAP formatters to format the data to the structure which enables the stream to be transmitted efficiently and securely. Developers can evenly utilize the attributes of .NET Remoting to effortlessly create communication channels irrespective of how separate the application domains are within the system, physical position, or network configuration.
The main three components of a Remoting Framework are :
2. C# Remote Listener Application - (listening requests for Remote Object)
3. C# Remote Client Application - (makes requests for Remote Object)
The Remote Object is implemented in a class that derives from System.MarshalByRefObject .
The above figure illustrates the fundamental workflow of .NET Remoting. When a client initiates a call to a remote method, the client does not directly invoke the methods themselves. Instead, it receives a proxy to the remote object, which serves as an intermediary for invoking the method on the remote object. Once the proxy receives the method call from the client, it proceeds to encode the message using an appropriate formatter, such as the Binary Formatter or SOAP Formatter, as specified in the Configuration file. Subsequently, the proxy sends the method call to the server through the selected channel, which can be either the TcpChannel or HttpChannel. On the server side, the channel receives the request from the proxy and forwards it to the Remoting system on the server.
The Remoting system then locates and invokes the methods on the remote object. Upon completion of the remote method's execution, any resulting data or outcomes are sent back to the client in a similar manner. This comprehensive workflow demonstrates the intricate process of communication and interaction between clients and remote objects in the .NET Remoting framework.
Prior to accessing an object instance of a Remotable type, it is essential to create and initialize it through a process known as Activation. Activation encompasses two distinct models: Client-Activated Objects and Server-Activated Objects.
In the Client-Activated Objects model, the client initiates the activation process by requesting a new instance of the remote object. The remote object's lifetime is managed by the client, and each client interaction results in the creation of a separate object instance.
On the other hand, the Server-Activated Objects model places the responsibility of object activation on the server. The server activates the object upon receiving a client request, and subsequent client interactions with the remote object are directed to the same instance.
These activation models provide flexibility in managing the lifecycle and behavior of remote objects in the .NET Remoting framework, allowing developers to choose the most suitable approach based on their application requirements and design considerations.
The real difference between client-activated and server-activated objects is that a server-activated object is not really created when a client instantiates it. Instead, it is created as needed.
By default the .NET Framework ships with two formatters(Binary Formatter or SOAP Formatter ) and two channels(TcpChannel ,HttpChannel).
Formatters and Channel are configured by using Configuration files. It can be easily Configured by using XML-based files.
The .NET Remoting is easy to use and powerful, largely because it is based on the Common Type System (CTS) and the Common Language Runtime (CLR). From the following link , you can understand the .Net Remoting components in detail.