Answer Posted / venky

http://venkysnotebook.blogspot.com/2008/10/net-remoting.html

What is .NET Remoting?

.NET Remoting is an enabler for application communication.
It is a generic system for different applications to use to
communicate with one another. .NET objects are exposed to
remote processes, thus allowing interprocess communication.
The applications can be located on the same computer,
different computers on the same network, or even computers
across separate networks.
.NET Remoting versus Distributed COM

In the past interprocess communication between applications
was handled through Distributed COM, or DCOM. DCOM works
well and the performance is adequate when applications exist
on computers of similar type on the same network. However,
DCOM has its drawbacks in the Internet connected world. DCOM
relies on a proprietary binary protocol that not all object
models support, which hinders interoperability across
platforms. In addition, have you tried to get DCOM to work
through a firewall? DCOM wants to communicate over a range
of ports that are typically blocked by firewalls. There are
a ways to get it to work, but they either decrease the
effectiveness of the firewall (why bother to even have the
firewall if you open up a ton of ports on it), or require
you to get a firewall that allows support for binary traffic
over port 80.

.NET Remoting eliminates the difficulties of DCOM by
supporting different transport protocol formats and
communication protocols. This allows .NET Remoting to be
adaptable to the network environment in which it is being used.
.NET Remoting versus Web Services

Unless you have been living in a cave, or are way behind in
your reading, you have probably read something about Web
services. When you read the description of .NET Remoting it
may remind you a lot of what you're read about Web services.
That is because Web services fall under the umbrella of .NET
Remoting, but have a simplified programming model and are
intended for a wide target audience.

Web services involve allowing applications to exchange
messages in a way that is platform, object model, and
programming language independent. Web services are stateless
and know nothing about the client that is making the
request. The clients communicate by transferring messages
back and forth in a specific format known as the Simple
Object Access Protocol, or SOAP. (Want to get some funny
looks in the hallway? Stand around in the hallway near the
marketing department with your colleagues and discuss the
benefits of using SOAP).

The following list outlines some of the major differences
between .NET Remoting and Web services that will help you to
decide when to use one or the other:

* ASP.NET based Web services can only be accessed over HTTP.
.NET Remoting can be used across any protocol.

* Web services work in a stateless environment where each
request results in a new object created to service the
request. .NET Remoting supports state management options and
can correlate multiple calls from the same client and
support callbacks.

* Web services serialize objects through XML contained in
the SOAP messages and can thus only handle items that can be
fully expressed in XML. .NET Remoting relies on the
existence of the common language runtime assemblies that
contain information about data types. This limits the
information that must be passed about an object and allows
objects to be passed by value or by reference.

* Web services support interoperability across platforms and
are good for heterogeneous environments. .NET Remoting
requires the clients be built using .NET, or another
framework that supports .NET Remoting, which means a
homogeneous environment.


Channels

Remote objects are accessed through Channels. Channels
physically transport the messages to and from remote
objects. There are two existing channels TcpChannel and
HttpChannel. Their names give away the protocols that they
use. In addition, the TcpChannel or HttpChannel can be
extended, or a new channel created if you determine the
existing channels do not meet your needs.
Create a Remotable Object
A remotable object is nothing more than an object that
inherits from MarshalByRefObject. The following sample
demonstrates a simple class to expose the omnipresent hello
world. This object exposes a single method HelloWorld that
will return a string. The only values that can be returned
from methods are the classes in the .NET Framework that are
serializable such as string and DataSet. In addition, if you
need to return a user-defined object then the object needs
to be marked as serializable.

Create a new C# class library project. Add a class called
SampleObject and put in the following code. Add a reference
to System.Runtime.Remoting in the project, otherwise the
TcpChannel will not be found. Compile the class to make sure
you have everything correct.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace CodeGuru.Remoting
{
///
/// Sample object to demonstrate the use of .NET Remoting.
///
public class SampleObject : MarshalByRefObject
{
///
/// Constructor
///
public SampleObject()
{
}

///
/// Return a hello message
///
/// Hello world message
public string HelloWorld()
{
return "Hello World!";
}
}
}

Create a Server To Expose the Remotable Object

We need to create a server object that will act as a
listener to accept remote object requests. For this example
we will use the TCP/IP channel. We first create an instance
of the channel and then register it for use by clients at a
specific port. The service can be registered as
WellKnownObjectMode.SingleCall, which results in a new
instance of the object for each client, or as
WellKnownObjectMode.Singleton, which results in one instance
of the object used for all clients.

It is not necessary to create the server listener if you are
planning to use IIS. For obvious reasons, IIS only supports
the use of the HttpChannel. Create a virtual directory for
your application and then put code to register your service
in the Application_Start event.

For our example, we'll go ahead and create a server listener
in case you don't have IIS. Since the service needs to be
bound to an available port, for our example I chose 8080,
which is a port that I know to be unused on my computer. You
may need to choose a different port depending upon what
ports you have available. To see a list of the used ports on
your computer open a command prompt and issue the command
"netstat --a". It may produce a long listing so make sure
the command prompt buffer sizes are set to allow scrolling.
Compile the class to make sure you have everything correct.

Create a new C# console application project. Add a class
called SampleServer and paste in the following code. Add a
reference to System.Runtime.Remoting in the project,
otherwise the TcpChannel will not be found. In addition, add
a reference to the project containing the SampleObject,
otherwise the code will not compile because it won't know
how to find a reference to SampleObject.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace CodeGuru.Remoting
{
///
/// Sample server to demonstrate the use of .NET Remoting.
///
public class SampleServer
{
public static int Main(string [] args)
{
// Create an instance of a channel
TcpChannel channel = new TcpChannel(8080);
ChannelServices.RegisterChannel(channel);

// Register as an available service with the name HelloWorld
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(SampleObject),
"HelloWorld",
WellKnownObjectMode.SingleCall );

System.Console.WriteLine("Press the enter key to exit...");
System.Console.ReadLine();
return 0;
}

}
}

Create a Client To Use the Remotable Object

Now that we have our remotable object and a server object to
listen for requests, let's create a client to use it. Our
client will be very simple. It will connect to the server,
create an instance of the object using the server, and then
execute the HelloWorld method.

Create a new C# console application project. Add a class
called SampleClient and paste in the following code. Add a
reference to System.Runtime.Remoting in the project,
otherwise the TcpChannel will not be found. In addition, add
a reference to the project containing the SampleObject,
otherwise the code will not compile because it won't know
how to find a reference to SampleObject. Compile the class
to make sure you have everything correct.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace CodeGuru.Remoting
{
///
/// Sample client to demonstrate the use of .NET Remoting.
///
public class SampleClient
{
public static int Main(string [] args)
{
// Create a channel for communicating w/ the remote object
// Notice no port is specified on the client
TcpChannel chan = new TcpChannel();
ChannelServices.RegisterChannel(chan);

// Create an instance of the remote object
SampleObject obj = (SampleObject) Activator.GetObject(
typeof(CodeGuru.Remoting.SampleObject),
"tcp://localhost:8080/HelloWorld" );

// Use the object
if( obj.Equals(null) )
{
System.Console.WriteLine("Error: unable to locate server");
}
else
{
Console.WriteLine(obj.HelloWorld());
}
return 0;
}
}
}

Test the Remoting Sample

Once you have created the projects and successfully compiled
each of them you are ready to try it out. Assuming you chose
a free TCP/IP port for the service, start the server
executable. After the server successfully starts it will
result in a console window being displayed with the message
"Press the enter key to exit". The server is listening so
you are now ready to run the client. Executing the client
should result in "Hello World!" being displayed in a
separate console window. The client window will then close
while the server remains open and available.

If you have multiple computers available to you on a network
you could execute the server on one machine and the client
on another just to prove to yourself that it really is
remoting. In order to run on separate machines you would
need to change the reference to localhost in the sample
client to point to the appropriate location.
Summary

.NET Remoting is a powerful way to enable interprocess
communication. It is more complicated to program against
than Web services. You need to decide for yourself whether
your standard architecture is to use .NET Remoting or Web
services.
Future Columns

The next column will be on the use of encryption in the .NET
framework. We'll take a look at some of the encryption
algorithms available in the framework and ways to use them.

What are static assemblies?

625

---

Difference between .net remoting versus distributed com?

661

---

define client activated objects (cao)?

708

---

Explain serialization formatters in .net remoting

630

---

What are the difference between static assemblies and dynamic assemblies?

648

---

---

Explain how does assembly versioning in .net prevent dll hell?

630

---

Explain threading types?

723

---

What is the Difference between CAO and SAO in Remoting.

644

---

What are the types of remoting?

629

---

When should we choose .net remoting over .net web services?

620

---

What are the information required to configure remote objects?

581

---

Explain the difference between the registerwellknownservicetype(), registerwellknownclienttype(), registeractivatedservicetype() and registeractivatedclienttype() in .net?

615

---

Explain when we use web service and when we use remoting?

612

---

What is Remoting?

735

---

How do you directly call a native function exported from a DLL?

6832

---