.

NET Remoting 1
Introduction

Over a period of time, the perception of building applications is changing very rapidly whatever it may be,
either desktop applications, web applications, or distributed applications. Nowadays, it has become the
practice to build applications as a set of components that are distributed across a network of machines and
work together as if all the sets of components are available from the single machine. Traditionally, distributed
application logic known for DCOM, CORBA or RMI, laid a reliable and scalable platform to meet the growing
needs of applications. These component-based technologies work very well in an intranet environment. Only
thing is we cannot use this technology over the Internet because the technologies do not interoperate.

A pinch over Webservices Vs. Remoting

Browser-based Web applications, in contrast, are loosely coupled and remarkably interoperable. They
communicate using HTTP to exchange MIME-typed data in a wide range of formats. Web services adapt the
traditional Web programming model for use from all sorts of applications, not just browser based ones. They
exchange SOAP messages using HTTP and other Internet protocols. Because web services rely on industry
standards, including HTTP, XML, SOAP, and WSD, to expose applications' functionality on the Internet, they
are independent of programming language, platform, and device. Thanks to Microsoft inventing of ASP.NET
Web services and .NET Remoting. Web services infrastructure provides a simple API for Web services based
on mapping SOAP messages to method invocations. This is achievable by providing a very simple
programming model based on mapping SOAP message exchanges to individual method invocations. The
clients of Web services do not have to know anything about the platform, object model, or programming
language used to build them, and vice versa (i.e., the services also unaware of the clients sending them
messages). Only thing is both the parties should follow a protocol on the format of the SOAP message being
produced and consumed.

Remoting Architecture:

.NET Remoting provides an infrastructure for distributed objects. It exposes full object semantics of .NET to
remote processes using plumbing that is both flexible and extensible. .NET Remoting offers much more
complex functionality, including support for passing objects by value or by reference, callbacks, and multiple-
object activation and lifecycle management policies. In order to use .NET Remoting, a client needs to be built
using .NET. To put in simple words, using object references to communicate between server objects and
clients is the heart of Remoting. The Remoting architecture, however, provides the programmer with an even
simpler procedure. If anyone configures the client properly, we need only to create a new instance of the
remote object using the new keyword, then client receives a reference to the server object, and rest of the
things are as usual (like invoking methods) as though the object were in your process though it is running on
a separate computer. Suppose we have an application running on one computer, and we want to use the
functionality exposed by a type that is stored on another computer; below depicted is a typical Remoting
scenario:
.NET Remoting 2

Data Marshalling:

How the data is getting marshaled. We discuss the same in below:

Serialization and Metadata:

All distributed communication plumbing ultimately does two things:

1. Marshals instances of programmatic data types into messages that can be sent across the network, it
is accomplished using some form of serialization engine or marshaller.
2. Provides a description of what those messages look like, it is achieved through some form of
metadata.

For instance, for most DCOM interfaces, the serialization engine was the Type Library Marshaler and type
libraries provide the metadata. The key difference between ASP.NET web services and .NET Remoting is in
how they serialize data into messages and the format they choose for metadata.

How .NET Remoting Marshals Data

.NET Remoting relies on the pluggable implementations of the IFormat interface used by the
System.Runtime.Serialization engine to marshal data to and from messages. .NET Framework provides
two standard formatters:

1. System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
2. System.Runtime.Serialization.Formatters.Soap.SoapFormatter

The BinaryFormatter and SoapFormatter as the names suggest marshal types in binary and SOAP
format respectively. For metadata, .NET Remoting relies on the CLR assemblies, which contain all the relevant
information about the data types they implement, and expose it via reflection. The reliance on the assemblies
for metadata makes it easy to preserve the full runtime type-system reliability. As a result, when the .NET
Remoting marshals data, it includes all of a class’ public and private members. However, as we mentioned
above, relying on runtime metadata for marshalling also limits the reach of a .NET Remoting system - as
client has to understand .NET constructs in order to communicate with a .NET Remoting endpoint.

Channels

As an addition to the flavor, the .NET Remoting layer supports pluggable channels how messages are sent.
There are two standard channels for the message transfer, independent of format (i.e. Binary format or SOAP
format). Both TCP Channel and HTTP Channel provide an implementation for a sender-receiver channel that
uses the HTTP protocol to transmit messages.

.NET Remoting Objects

As mentioned above in the state management options, there are three types of objects that can be configured
to serve as .NET remote objects. Choose the type of object depending on the requirement of the application.

• Single Call: Single Call objects service one and only one request coming in. Single Call objects are
useful in scenarios where the objects are required to do a limited amount of work. Single Call objects
are not required to store state information; in fact, they cannot hold state information between
method calls.
• Singleton Objects: These objects service multiple clients and hence share data by storing state
information between client invocations. They are useful in cases in which data needs to be shared
explicitly between clients.
.NET Remoting 3
• Client-Activated Objects: These objects are server-side objects that are activated upon request
from the client. When the client submits a request for a server object using “new” operator, an
activation request message is sent to the remote application. The server then creates an instance of
the requested class and returns an ObjRef back to the client by using which proxy is then created.
These objects can store state information between method calls for its specific client. Each invocation
of “new” returns a proxy to an independent instance of the server type.

Life Time of Remote Object

In typical, for the objects that have object references that are transported outside the application, a lease is
created. The lease has a lease time; when the lease reaches zero, it expires and the object is disconnected
from the .NET Remoting Framework. Once all the references to the object within the AppDomain have been
freed, the object will be collected when the next garbage collection occurs. The lease controls the lifetime of
the object.

To sum up points:

• .NET Remoting favors the runtime type system and provides a more complex programming model with
much more limited reach.
• .NET Remoting gives the flexibility to host remote objects in any type of application including a
Windows Form, a managed Windows Service, a console application, or the ASP.NET worker process.
Both the channels (TCP and HTTP) provide communication between sending and receiving processes
using sockets.
• .NET Remoting infrastructure is extensible. It is possible to filter inbound and outbound messages,
control aspects of type marshaling and metadata generation. It is possible to implement custom
formatters and channels using .NET Remoting.
• .NET Remoting, hosted in IIS with ASP.NET, can leverage all the security features available to ASP.NET
Web Services. If we use TCP or HTTP channel hosted in processes other than aspnet_wp.exe, we have
to implement authentication, authorization and privacy mechanisms by our own.
• .NET Remoting supports a range of state management options (depends on object lifetime scheme:
SingleCall or Singleton objects).
• In terms of performance, .NET Remoting provides the fastest communication when we use TCP
channel and the binary formatter.

Building the sample application:

In the below example, the remote object exposes two methods for adding and subtracting given two
numbers. Building an application that uses .NET Remoting to communicate across application domain
boundaries is very straightforward:

1. You must have an implementation of a remotable type.

2. A listening or host application domain.
3. A client or calling application domain.
4. And you must configure the remoting system in each application domain to use remote activation for
the remotable type.

The above process applies no matter how complex or simple the remoting scenario becomes.
We discuss each of the above here:

Building Remotable Type

We discuss in brief about how to build the remotable type. To enable objects in other application domains to
use an instance of the class, the class must inherit from MarshalByRefObjet. The following code example
shows a simple object that can be created and invoked from objects executing in another application domain.
.NET Remoting 4
MathLibrary.cs

using System;
public class MathLibrary : MarshalByRefObject
{
private int result;

public int AddTwoNumber(int num1, int num2)

{
result = num1 + num2;
return result;
}

public int SubtractTwoNumber(int num1, int num2)

{
result = num1 - num2;
return result;
}
}

Store the above file as MathLibrary.cs in your own directory. Compile this file as a DLL from the command
prompt as below:

csc /noconfig /t:library MathLibrary.cs.

Building a Host Application

Our job is not over by simply creating MathLibrary. To create instances of this object remotely, you must
build a host or listener application which does two things:

• Choose and register a channel, which is an object that handles the networking protocols and
serialization formats.
• Register your type with the .NET Remoting system so that it can use your channel to listen for
requests for your type.

Since remote configuration is done on a per-application-domain basis, the application domain must be
running to listen for requests. One important thing is that unlike COM, Remoting does not start the host or
server application by its own. The following code implements a simple MathLibrary host application domain
that uses a configuration file.

Listener.cs

using System;
using System.Runtime.Remoting;

public class Listener

{
public static void Main()
{
RemotingConfiguration.Configure("Listener.exe.config");
Console.WriteLine ("Listening for requests. Press Enter to exit...");
Console.ReadLine();
}
}

Store the above code as Listener.cs in the same directory as where MathLibrary.dll is created. Compile
Listener.cs with reference to MathLibrary.dll as below:

csc /noconfig /r:MathLibrary.dll Listener.cs.

Since the above code snippet uses Listener.exe.config file to listen to its remotable type, we need to create
the Listener.exe.config file in the same directory where we created the Listener.exe.
.NET Remoting 5
Listener.exe.config:

<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
mode="Singleton"
type="MathLibrary, MathLibrary"
objectUri="MathLibrary.rem"
/>
</service>
<channels>
<channel ref="http" port="8989"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>

Building a Client Application:

Till now, we have created MathLibrary and the host application for Remoting. Our application must register
itself as a client for the remote object, and then invoke it as residing in the client application domain. The
.NET Remoting system intercepts the client calls, forwards them to the remote object, and returns the results
to your client.

Client.cs

using System;
using System.Runtime.Remoting;

public class Client

{
public static void Main()
{
RemotingConfiguration.Configure("Client.exe.config");
MathLibrary lib = new MathLibrary();
Console.WriteLine("Enter Number1:");
string num1 = Console.ReadLine();
Console.WriteLine("Enter Number2:");
string num2 = Console.ReadLine();
Console.WriteLine(lib.AddTwoNumber(Convert.ToInt16(num1),
Convert.ToInt16(num2)).ToString());
}
}

Store the above code as Client.cs in the same directory as where Client.exe is created. Compile Client.cs with
reference to MathLibrary.dll as below:

csc /noconfig /r:MathLibrary.dll Listener.cs

Since the above code snippet uses Client.exe.config file to listen to its remotable type, we need to create the
Client.exe.config file in the same directory where we created the Client.exe.
Client.exe.config

<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown
type="MathLibrary, MathLibrary"
url="http://localhost:8989/MathLibrary.rem"
/>
</client>
</application>
</system.runtime.remoting>
.NET Remoting 6
</configuration>