.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.
|
