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. Now a days it has
become the practice to build applications as 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 reliable and scalable
platform to meet the growing needs of applications.
technologies work very well in an intranet environment. Only thing is we cannot
use this technology over the internet because the technologies do not
pinch over Webservices Vs Remoting.
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.
.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 new keyword, then
client receives a reference to the server object and rest of the things are as
usual ( like invoking methods) as 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 typical
How the data is getting marshaled. We
discuss the same in below:
Serialization and Metadata:
communication plumbing ultimately does two things:
1. marshals instances
of programmatic data types into messages that can be sent across the network is
accomplished using some form of serialization engine or marshaller.
2. provides a
description of what those messages look like is achieved through some form of
For instance, for most DCOM interfaces, the serialization engine was the Type
Library Marshaler and type libraries provides 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.
.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:-
and SoapFormatter as the name 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's public andprivate 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.
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 provides an
implementation for a sender-receiver channel that uses the HTTP protocol to
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 object 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.
- 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 can be possible to filter inbound and outbound message, 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
we consider an example, the remote object which exposes two methods adding and
subtracting given two numbers.
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 in following:
- 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.
Public Class MathLibrary
: Inherits MarshalByRefObject
Private result As Integer
Public Function AddTwoNumber(ByVal num1 As Integer, ByVal num2 As Integer) As Integer
result = num1 + num2
Public Function SubtractTwoNumber(ByVal num1 As Integer, ByVal num2 As Integer) AsIntegerresult
= num1 - num2
End FunctionEnd Class
Store the above file as
MathLibrary.cs in your own directory. Compile this file as dll from the command
prompt as below:
/noconfig /t:library MathLibrary.cs.
Building a Host Application.
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
- 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.
remote configuration is done on a per-application-domain basis, the application
domain must be running to listen for requests.
important thing is that unlike COM, Remoting does not start the host or server
application by its own.
following code implements a simple MathLibrary host application domain that uses
a configuration file.
Public Class Listener
Public Shared Sub Main()
Console.WriteLine("Listening for requests. Press Enter to exit")
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:
Since the above code snippet
uses Listener.exe.config file to listen to it's remotable type we need to create
the Listener.exe.config file in the same directory where we created the Listener.exe.
<wellknown mode="Singleton" type="MathLibrary,
MathLibrary" objectUri="MathLibrary.rem" />
<channel ref="http" port="8989"/>
Building a Client Application:
now we have created MathLibrary, Host Application for the 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, forward them to the remote object, and return the
results to your client.
Public Class Client
Public Shared Sub Main()
'INSTANT VB NOTE: The
local variable lib was renamed since it is a keyword in VB:
Dim lib_Renamed As MathLibrary
= New MathLibrary
Dim num1 As String =
Dim num2 As String =
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:
/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
MathLibrary" url="http://localhost:8989/MathLibrary.rem" />
Now every thing
is ready to run your application:
the command prompt(from the directory where you created the Client.exe and
Listener.exe) type Listener.exe.
From the command prompt(from
the directory where you created the Client.exe and Listener.exe) type
sure that while you are running your Client, Listener should be running to
accept the requests from the client.