Remoting in ASP.Net

What You Should Already Know?

AppDomain: An AppDomain is an abstract construct for ensuring isolation of data and code, but not having to rely on operating system specific concepts such as processes or threads.

Process: A process can be a collection of Threads, virtual memory space, code, Data and System resources.

Thread: A thread is code that is to be serially executed with in a process. A processor executes threads and not process. Added to that a processor can run one thread at a time.

What is remoting in dotnet?

Every process or thread of an application will run in an exclusive area called AppDomain. If an object in a domain talks with other object in different domain for fulfilling the task, then process involved is called remoting. An object is considered local if it resides in the same AppDomain as the caller. If the object is not in the same AppDomain as the caller, then it is considered remote.

Why we need remoting?

In the application development life cycle, at some situations we may come across with a need of objects that are working in another AppDomain. For example, we wanted to display weather forecast in our web page. In that scenario we will use the object of that weather class. By doing like this, we can reduce the Lines Of Code (loc), increase the performance and many more benefits are there.

What is the Architecture of remoting in Dotnet?

Architecture

How remoting is implemented?
In .NET remoting, the remote object is implemented in a class that derives from System.MarshalByRefObject. The MarshalByRefObject class provides the core foundation for enabling remote access of objects across application domains. A remote object is confined to the application domain where it is created. In .NET remoting, a client doesn't call the methods directly; instead a proxy object is used to invoke methods on the remote object. Every public method that we define in the remote object class is available to be called from clients.

When a client calls the remote method, the proxy receives the call, encodes the message using an appropriate formatter, and then sends the call over the channel to the server process. A listening channel on the server AppDomain picks up the request and forwards it to the server remoting system, which locates and invokes the methods on the requested object. Once the execution is completed, the process is reversed and the results are returned back to the client.

Out of the box, the remoting framework comes with two formatters: the binary and SOAP formatters. The binary formatter is extremely fast, and encodes method calls in a proprietary, binary format. The SOAP formatter is slower, but it allows developers to encode the remote messages in a SOAP format. If neither formatter fits your needs, developers are free to write their own and plug it in as a replacement.

Different types of Remote Objects

The remoting infrastructure allows you to create two distinct types of remote objects.

Client-activated objects - A client-activated object is a server-side object whose creation and destruction is controlled by the client application. An instance of the remote object is created when the client calls the new operator on the server object. This instance lives as long as the client needs it, and lives across one to many method calls. The object will be subject to garbage collection once it's determined that no other clients need it.
Server-activated objects - A server-activated object's lifetime is managed by the remote server, not the client that instantiates the object. This differs from the client-activated object, where the client governs when the object will be marked for finalization. It is important to understand that the server-activated objects are not created when a client calls New or Activator.GetObject. They are rather created when the client actually invokes a method on the proxy. There are two types of server-activated objects. They are:
- Single call ï¿½ Single call objects handle one, and only one, request coming from a client. When the client calls a method on a single call object, the object constructs itself, performs whatever action the method calls for, and the object is then subject to garbage collection. No state is held between calls, and each call (no matter what client it came from) is called on a new object instance.
- Singleton - The difference in a singleton and single call lies in lifetime management. While single-call objects are stateless in nature, singletons are stateful objects, meaning that they can be used to retain state across multiple method calls. A singleton object instance serves multiple clients, allowing those clients to share data among themselves.

Ease of programming and deployment

In this section, we will consider a simple remoting object to understand the complexities involved in creating and consuming them. We will start off by creating a simple remote object.

Creating a remote object
Creating a remoting object is a simple process. To create a remote object, you need to inherit from MarshalByRefObject class. The following code shows a remotable class.

using System;

namespace RemoteClassLib

{

public class MyRemoteObject : System.MarshalByRefObject

{

public MyRemoteObject()

{

Console.WriteLine("Constructor called");

}

public string Welcome(string name)

{

Console.WriteLine("Welcome Called");

return "Welcome " + name;

}

The above code is very simple and straightforward. We start off by defining a class that inherits from MarshalByRefObject. After that we add code to the constructor of the class to write out a message to the console. Then we have a method named Welcome that basically takes a string argument and appends that with the string and returns the concatenated value back to the caller. Once the remote object is created, the next step is to create a host application that hosts the remote object. For the purposes of this article, we will create a console application that reads the details of the remote object from its configuration file.

using System;

using System.Runtime.Remoting;

namespace RemoteClassLibServer

{

class RemoteServer

{

[STAThread]

static void Main(string[] args)

{

RemotingConfiguration.Configure(

"RemoteClassLibServer.exe.config");

Console.WriteLine("Press return to Exit");

Console.ReadLine();

}

In the main method, we just read the configuration settings from the configuration file using the RemotingConfiguration.Configure method and wait for the client applications to connect to it.

The configuration file used by the above hosting application looks like the following. In the configuration file, we specify that we want to expose the remote object using the TCP channel by using the channel element.

<?xml version="1.0" encoding="utf-8" ?>

<system.runtime.remoting>

<wellknown mode="SingleCall"

type="RemoteClassLib.MyRemoteObject,RemoteClassLib"

objectUri="MyRemoteObject">

</wellknown>

</service>

</channels>

</application>

</system.runtime.remoting>
</configuration>

Once the hosting application is started, then client applications can start creating instances of the remote object and invoke its methods.

Conclusion

Both the .NET remoting is a powerful technology that provides a suitable framework for developing distributed applications. For those applications that require communications with other .NET components and where performance is a key priority, .NET Remoting is the best choice. In short, use .NET Remoting when sending and receiving data between .NET applications.

References:

This article is prepared based on a post of Thiru Thangarathinam. I have added my thoughts and understandings along with that.

Mr. Praveen N. Mulukutla - Software Engineer

I like to write articles on Programming languages. The idea of articles come from my own experiences while working in those areas and i like to share my knowledge on POP3 services with all others so that it might be helpful.

Service is my Motto & Knowledge is Divine

http://www.mulukutlas.blogspot.com