Remoting in .NET

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

Independent Devices

Rules of Remoting:

1. There must be 2 independent devices. 
2. One have functionality and another will access that functionality. 
3. Functionality must be in running or active mode e.g. Television must be in running mode to work with remote
   An Example of remoting is that we have have SQL Server and SQL Server client edition. Here Client edition tool work as remote. Same with Oracle also.
   
   If we implement such functionality then we use Remoting. It could be 1-tier or other architectures.
   

Remoting process

When a call is made from the Client a Marshall object is created at the server.
Marshall Object: This is special type of object that catch request, analyze, execute functionality and reply Data/
Information back.

There are two type of Communication between Server and Client.
Singleton-    if SMO(Single Marshall Object) handles MR(Multiple Request).
Single Call- if MMO( Multiple Marshall Object)s Handles MR(Multiple Request).

In communication Server do not know about that where is client and same with client. this also do not know about
the server location. communication is not done directly it is done by proxy.

Proxy contain two parts
Stub- This implement the Skelton.
Skeleton- Contains Rules of Communication.

Server contain Skelton and Client contain Stub. Stub communicate with the Skeleton.

Three things required to implement the Remoting
Business Login – Marshall Object./
Skeleton at Server
Stub at Client

First Create Business Logic that served to the client:
create a class that inherits Class MarshalRefObject. To do this create new project and select class library as in Fig below.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace BusinessLogic

{

    public class BL:MarshalByRefObject

    {

        public string Greet(string strName)

        {

            return ("Hello" + strName);

        }

    }

}

Build the solution. after this it will create a library file (.dll) that you have to use in next step; in creation of the server.

2.  Server Code...

Create New project ..Select Console Application and Reference System.Runtime.Remoting as in Fig 2.

Now add BusinessLogic dll to your solution using add reference.

and write the following code:

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels.Tcp;

using System.Runtime.Remoting.Channels;

namespace Server

{

    class Program

    {

        static void Main(string[] args)

        {

            TcpChannel tc = new TcpChannel(8030);

            ChannelServices.RegisterChannel(tc, false);

            RemotingConfiguration.RegisterWellKnownServiceType(typeof(BusinessLogic.BL), "xyz", WellKnownObjectMode.SingleCall);

            Console.Write("Server is Ready!");

            Console.ReadKey();

        }

    }

}

.. Here you have to register the channel and get the type of information that travel on the channel is BusinessLogic's object.

Now move to the client's working.

Step 3: Client

Create a new project and select Windows Form Application with two text boxes and one Button as in Figure  6.

Here you have add a interface with the same name space as in the Business Logic and specify all the methods name

as it is in the Business Logic.

Here is code of that class file that contains the Interface.

namespace BusinessLogic

{

    public interface BL

    {

        string Greet(string strName);

    }

}

figure 6
and now write following code to communicate with the server.

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Tcp;

namespace Client

{

    public partial class Form1 : Form

    {

        public Form1()

        {

            InitializeComponent();

        }

        BusinessLogic.BL obj;

        private void Form1_Load(object sender, EventArgs e)

        {

            TcpChannel tc = new TcpChannel();

            ChannelServices.RegisterChannel(tc, false);

            object o = Activator.GetObject(typeof(BusinessLogic.BL), "tcp://Niranjan-PC:8030/xyz");

            obj = (BusinessLogic.BL)o;

        }

        private void btnSend_Click(object sender, EventArgs e)

        {

            txtReceivedMessage.Text = obj.Greet(txtMessage.Text);

        }

    }

}

here it get the object type of our interface structure and the server name is also specified and with there service
that we have placed on server named as xyz.

.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