Microsoft® .NET
Remoting provides a rich and extensible framework for objects living in
different AppDomains, in different processes, and in different machines to
communicate with each other seamlessly. .NET Remoting offers a powerful yet
simple programming model and runtime support for making these interactions
transparent. In this article we will take a look at the different building
blocks of the Remoting architecture, as well as explore some of the common
scenarios in which .NET Remoting can be leveraged.
.NET
Remoting provides a
way for application in different machines/domains to communicate with each
other. Remoting provides a powerful yet an easy way to communicate with object
in different app domains. Any object which executes outside the app domain can
be considered as Remote.
Any Distributed
Communications involves ultimately two things
1.
It marshals an
instance of programmatic data types into messages that can be sent across
network or different Application Domains. Any marshalling Engine or Marshaller
can do this marshalling.
2.
Providing a
description of what those messages look like. This is achieved through some
metadata that describes the messages in data format
some important
objects involved in .NET remoting.
1.
CLR Common
Language Runtime is an Execution Environment in .NET.
2.
The process of
Packaging and unpacking and sending the method calls across the different
application domains via serialization and deserialization is called as
Marshalling.
3.
Marshalling is
done by the object called sink. Sink is an object that allow custom processing
of messages during remote invocation.
4.
Channels are
objects used to transport the messages through the network or across different
application domains
5.
Application
Domain is the Logical construct of the CLR that is the unit of Isolation for an
application which guarantees, Each Application can be Independently stopped, An
application can not directly access code or resource of the other application,
a fault in one application will not effect the other application CLR allows
multiple applications in a single Process by Implementing Application Domains.
There r really 7
steps that r mainly involved in understanding the .NET Remoting
1.
When a Client
object wants to create an instance of the server object (to access the remote
object) the remoting System Framework will create a proxy (Transparent Proxy)
of the server object on the Client side, that contains list of all classes, as
well as interface methods of the remote object. The TransparentProxy class gets
registered with the CLR.
2.
The Proxy object
behaves just like the remote object, this leaves the client with the impression
that the server object is in the client's process
3.
When a Client
object calls a method on the server object, the proxy passes the call
information to the remoting Framework on the client. This remoting System
(Remoting Framework) in turn sends the call over the channel to the remoting
System on the server
4.
The Remoting
system on the server receives the call information and on the basis of it, it
invokes the method on the actual object on the server creating object if
necessary
5.
Then the remoting
system on the server collects all the results of the invocation and passes
through the channel to the remoting System on the client.
6.
The remoting
System on the client receives the response of the server and passes the results
to the client object through the proxy
7.
The process of
Packaging and unpacking and sending the method calls across the different
application domains via serialization and deserialization is called as Marshalling.
They are basically
two types of remotable objects
1.
Marshall-By-Value(MBV)
This objects are copied and passed over the server application domain to the
client application domain
2.
Marshall-By-Reference
(MBR) this objects are accessed on the client side by using a proxy. Client
just holds the reference of this object which in on server-side.
Channels
Channels are the objects that transport messages across
remoting boundaries such as application domains, processes and computers.
There are two
possible activation modes for server activated objects
1.
Single-call
activation mode
2.
Singleton
activation mode
Single call activation Mode: (object per call)
In the single call
activation mode an object is instantiated for the sole purpose of responding to
just one client request. After the request is fulfilled the .NET remoting
Framework deletes the object and reclaims the memory.
Singleton Activation Mode
In the Singleton
activation mode at most (Minimum) there will be one instance of the remote
object regardless of the no. Of clients accessing it.
Creating Server application
namespace InterfaceLayer
{
public interface
IControl
{
string getadata();
}
}
using InterfaceLayer;
namespace DataLayer
{
public class
ServerClass : MarshalByRefObject , IControl
{
public ServerClass(){}
public string getadata()
{
return "success";
}
}
}
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using
System.Runtime.Remoting.Channels.Tcp;
using DataLayer;
static void
Main(string[]
args)
{
TcpChannel ch=new
TcpChannel(8085);
ChannelServices.RegisterChannel(ch);
RemotingConfiguration.RegisterWellKnownServiceType(typeof
(ServerClass),"Abc",WellKnownObjectMode.Singleton);
Console.WriteLine("Sever is Ready........");
Console.ReadLine();
}
Creating Client application
using System.Runtime.Remoting;
using
System.Runtime.Remoting.Channels;
using
System.Runtime.Remoting.Channels.Tcp;
using
InterfaceLayer;
private void
button1_Click(object sender, System.EventArgs
e)
{
TcpClientChannel objchannel = new
TcpClientChannel();
ChannelServices.RegisterChannel(objchannel);
IControl objcontrol;
string str;
try
{
objcontrol = (IControl)Activator.GetObject(typeof(IControl), "tcp://localhost:8085/Abc");
str = objcontrol.getadata();
MessageBox.Show(str);
}
catch{}
}
No comments:
Post a Comment