.NET Remoting - Easy Introduction

In Summary ...

This is a two parts tutorial in which we will explore together the world of .Net remoting. We will learn what remoting is, and for what purposes we typically need to use it. We will explore its architecture, its objects, and finally we will be building and running a .Net remoting application.

So, let's start now.......

What Is .NET Remoting?

As you may already know that application domains and processes are two mechanisms for isolation between applications. Processes are the main insulator between two different applications. Application domains is another extra isolation layer between different applications, but its main purpose is to isolate parts of code inside the same application. These parts will have the same isolation and restrictions as if they are different applications.

Now, what if for one reason or another we need to use a part of code located at different application domain running within the same application, located in different process running on the same machine, or located inside another process running on a different machine?. For uses like this, .Net remoting does exists.

Microsoft .Net Remoting is created to solve these problems. It provides a solution for communication between application domains and processes in a seamlessly and transparent way. This is due to the power of .Net remoting programming model and run time support.

When Microsoft developers designed .Net remoting framework, they have taken into consideration flexibility and customizability. This is done by separating the remotable object - in other words the object that you need to call remotely (located at another application domain or process) - from the client or server application domain and from any specific mechanism of communication. You can replace one communication protocol with a different one without the need to recompile the client or the server. Another flexibility related feature is that .Net remoting is a language independent framework, you can choose any application mode to communicate from. You can communicate using a web application, a console application, or a Windows Service. Any application can host a remoting object and provides its services to any client whether or not it is located within the same process boundaries, or in separate processes located on one machine or a set if disparate machines.

It is worth mentioning that objects in different application domains communicate using one of two techniques or methods. The first one is by transporting copies of objects across application domain boundaries. The second one is by using a proxy to exchange messages between them. .Net remoting framework uses the second technique.

.Net Remoting components

To allow an application located in different application domain or process to communicate with another one using .Net remoting technique, you have to just build the following:

• A remotable object. Which is an object that contain some properties and methods located in one application domain and you need to call its methods or properties from another application domain or process.

• A host application. This is the host of the remotable object. It is also called the server application. The main task of this host is to listen to requests for the hosted remotable object.

• A client application. This is the application which makes requests for the remotable object.

Types of Remotable Objects

There are 3 types of remotable objects that you can configure and choose from depending on the requirements of your application.

• Single Call: The remotable object is intended to be called from one client / one instance at a time.

• Singleton Call: Several clients / several instances of the remotable object can be utilized

• Activation: Richer than Singleton in the regard of other aspects.

How Does .NET Remoting Works?

As we mentioned previously you need to build a remotable type or object, a host or server application, and a client application to be able to communicate. In the client application you need only to create a new instance of the remotable object by using "New" or the instance creation function. When you do this the remoting system creates a proxy object that looks like the remote type to the client. When the client calls a method of the remotable type it actually call the method on the created proxy. The remoting system receives that call and routes it to the server process, it then processes the request, and returns the result to the client proxy, which in turn returns it to the client application. The client application will get the feeling of the remotable object as it is running inside the same process not inside another one. The proxy object is the system component that creates the impression that the server object is in the client's process not in a separate process or computer.

To get the above scenario to work perfectly, you actually need to know about two things: the first is channels, and the second is configuration.

Channels

If you try to build the remoting system yourself, you will need to learn network programming and a wide array of protocols and serialization formats. For purposes like that .NET remoting provides the concept of transport channel that represents the combination of the underlying technologies required to open a network connection and to use a particular protocol to send the bytes to the receiving application.

Channels are the transport media used to send / receive messages between applications across remoting boundaries (these boundaries can be between application domains, processes, or computers). A channel is an object that takes a stream of data, packages it according to a specific network protocol, and then sends the package to the other side. Channels can be categorized as channels which can send messages, channels which can receive messages, or channels which can perform both sending and receiving like the two .NET channels "HTTPChannel" and "TCPChannel".

By using the channel concept or technique you can plug in a wide range of protocols even if the common language runtime is not at the other end of the channel. You can also create your own channel object using whatever network protocol you prefer if it is not supported by the .NET framework.

You have to register at least one channel to use with the remoting infrastructure before being able to call the remotable type from the client application. You can register a channel in one of two ways: by calling "ChannelServices.RegisterChannel ", or by using a configuration file. You have to choose a specific port for your channel to listen on. If you are not sure whether a port is available or not, use 0 (zero) when you configuring your channel's port and the remoting system will choose an available port for you.

Configuration

The .NET remoting infrastructure needs specific information to work successfully and smoothly. That information is what we call configurations. You can choose one of the available two ways to configure your remotable types depending on your own preferences. The first way is by calling configuration methods directly from your server and client code, and this is what we call programmatic configuration. The second way is by creating an XML configuration file (.config file). To configure your remotable type properly whether by programmatic configuration or through a configuration file you have to provide the following information:

• The activation type of your remotable object.
• The name or address of the metadata that describes the remotable type.
• The kind of the registered channel and the port number.
• The URL that uniquely identifies the remotable type.

We will provide you a configuration file example in the second part of this tutorial.

For further information

Refer to the online copy of Microsoft Developers Network at http://msdn.microsoft.com or use your own local copy of MSDN.

Tutorial toolbar:  Tell A Friend  |  Add to favorites  |  Feedback  |