Post
Ask Question

Remoting Technology: Distributed Computing

Abstract

This article shows how cross-process and cross-machine interaction of applications are developed with the .NET Framework work. This snippet especially provides you with an in-depth understanding of the remoting capabilities that are built into the .NET framework. It presents some scenarios in which .NET Remoting can be employed and includes historical background on the progress and development of various remoting frameworks. These pieces get you started with your first remoting application by creating and configuring its corresponding server and client modules using HTTP, TCP, and IPC channels. At the end of this, you will be able to design and develop removable components under the CLR context.

Why Remoting?

Remoting was typically used for accessing a server's resources at the beginning of the Microsoft client/server era. Every file server or database is an implementation of some tactics that allows code to be executed remotely. Nowadays the building of distributed applications is feasible to distributed business logics among Perse machines to improve performance, maintainability, and scalability. There are a couple of other distributed architecture implementations introduced and used frequently such as Web Services, COM, COM+, DCOM, RMI, CORBA, and EJB. The following point poses the need for remoting technology and the advantages of such inherent technology.

Cross-platform Communication

You will typically encounter a heterogeneous combination of various platforms, such as Windows, LAMP, Mac programming languages like C++, PHP, cold fusion, and frameworks for instance .NET, Java in a larger or mid-size enterprise. So, the integration of these technologies could be a daunting task for system architects. Remoting technology like .NET Remoting, CORBA, and SOAP is an absolute necessity in large-scale enterprise application integrations for building scalable applications.

Centralized business logic

One of the key scenarios for implementing Remoting technology is the concentration of business logic on a central server that considerably simplifies the maintainability and operability of large-scale applications because we need to update one single server rather than a number of users separately. When this centralized architecture is shared among various applications, it reduces the huge programming labor.

Remoting Architecture

The .NET Remoting is a process of programs or components interacting across certain application domains. The communication between application domains can happen inside the same process, between processes on a single system, or between processes on different machines. It provides a faster format for communication between .NET applications on both the client and server side. All in all, .NET Remoting is a perfect paradigm that is only possible over a LAN (intranet), not the internet. In the .NET Framework, this technology provides the foundation for distributed computing; it simply replaces DCOM technology.

Remoting implementations typically distinguish between mobile objects and remote objects. The mobile objects provide the ability to execute methods on remote servers, passing parameters and receiving return values whereas the remote objects will always be located at the server and only a reference to it will be passed around among other machines.

The following figure depicts a simplified view of remoting technology. Whenever a client application holds a reference to a remote object, it would be represented by a TransparentProxy object, that masquerades as the destination object. This proxy will allow the entire target object instance methods to be called upon it. Whenever a method call is presented to the proxy, it will be converted into a message and the message will pass using various layers.

Remoting Architecture

Remoting characteristics

  • It gives you a flexible and extensible framework that allows for different transfer mechanisms such as HTTP and TCP, encoding (binary and SOAP), and security settings such as SSL and IIS security.
  • We can use this technology anywhere such as on console applications, Windows applications, COM components, or Windows services applications.
  • .NET Remoting enables to work with stateful objects.
  • When we use remote objects, the .NET automatically tracks where they originated. So a client can ask one server to create an object and safely pass this as methods parameters to another server.

Remoting in Action

The Remoting classes can be found in the namespace System.Runtime.Remoting and some of its core classes can be found in mscorlib.dll. When using remote objects, both the client and the server must have access to the same interface definitions and serializable objects that are passed by value. This leads to the general requirement that at least three assemblies are needed for any .NET Remoting project.

  • General Assembly (Class library project): it represents a shared assembly that contains the interface and serializable object.
  • Server Assembly (Console application): it contains the server-side implementation of MarshalByRefObjects.
  • Client Assembly (Console application): this consumes the general assembly methods implementations.

General Assembly (Interface Definition)

For the first step, create a C# base class library project where you must define the interface ICustManager that will be implemented by the server. In this interface, you'll define a single method. gust(), which returns a Customer object to the caller as in the following.

namespace Rem_GeneralLib
{
    public interface ICustManager
    {
        Customer getCust(int id);
    }
}

You now need to define the customer that will hold the customer data. This class must be serialized because its object needs to be passed as a copy. Here, we are declaring the Name, and address, and calculating the present age as in the following.

using System;

namespace Rem_GeneralLib
{
    [Serializable]
    public class Customer
    {
        public string Name;
        public int Age;
        public string Address;
        public DateTime dt;

        public Customer()
        {
            Console.WriteLine("Customer Object Created......");
        }

        public int getAge()
        {
            Console.WriteLine("-----Customer Data-----");
            Console.WriteLine(Name);
            Console.WriteLine(dt.ToShortDateString());
            Console.WriteLine(Address);

            TimeSpan ts = DateTime.Today.Subtract(dt);
            return ts.Days / 365;
        }
    }
}

Finally, compile this class library project, and its corresponding Rem_GeneralLib.dll file is created in the Bin folder that will be referenced in the Remoting Server project later.

Remoting Server Implementation

The Remoting server application would be a console-based application. On the server, you need to provide an implementation of ICustManager that will allow you to load a customer from a fictitious database. This implementation will only fill in the Customer object with static data.

To implement the server application, first, add the reference of Rem_GeneralLib.dll and System.Runtime.Remoting.dll files. Now add the following lines to the declaration as in the following.

using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

Thereafter, you will need to implement an ICustManager in an object derived from MarshalByRefObject. The method getCust() will just return a dummy Customer object. Finally, register an HTTP channel that listens on port 7861. This channel is registered in the Remoting system that will allow incoming requests to be forwarded to the corresponding object as in the following.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using Rem_GeneralLib;

namespace Rem_Server
{
    public class CustomerManager : MarshalByRefObject, ICustManager
    {
        public CustomerManager()
        {
            Console.WriteLine("Customer Manager Object Created......");
        }
        public Customer getCust(int id)
        {
            Customer cst = new Customer();
            cst.Name = "Ajay Yadav";
            cst.dt = new DateTime(1982, 10, 9);
            cst.Address = "India";
            return cst;
        }
    }
    class RemServer
    {
        static void Main(string[] args)
        {
            HttpChannel chn = new HttpChannel(7861);
            ChannelServices.RegisterChannel(chn, false);

            RemotingConfiguration.RegisterWellKnownServiceType(
                                                   typeof(CustomerManager),
                                                   "RemotingServer",
                                                   WellKnownObjectMode.Singleton);
            Console.ReadLine();
        }
    }
}

The class CustomerManager is registered as a WellKnownServiceType, which allows the client to remotely call its methods. The URL will be “RemotingServer”. The object mode is set to singleton to ensure that only one instance will exist at any given time.

Service Consuming (Client Implementation)

The Remoting client project will connect the server and ask for a Customer object. For the Client project, you also need to add a reference of System.Runtime.Remoting.dll and compile the Gen_Remoting.dll file again.

Therefore, you must register the channel, you don't need to specify the port number because client-side ports are assigned automatically. Then create a proxy class that will support the ICustManager that will be passed in the Activator class as a parameter and specify the URL to the server type. Finally, call the Customer class method in order to populate the Customer class data.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using Rem_GeneralLib;
namespace Remoting_Client
{
    class ClientStartup
    {
        static void Main(string[] args)
        {
            HttpChannel chn = new HttpChannel();
            ChannelServices.RegisterChannel(chn, false);

            ICustManager mgr = (ICustManager)Activator.GetObject(
                typeof(ICustManager),
                "http://localhost:7861/RemotingServer");
            Console.WriteLine("Connecting to Server.....\n\n");

            Customer cust = mgr.getCust(101);
            int age = cust.getAge();

            Console.WriteLine(age);
            Console.ReadLine();
        }
    }
}

After finishing with the coding, compile the client project. Remember one thing, first, run the server project console application that will listen on port 7861 then start the client console application that will produce the following output.

Note. The system firewall echoes an alert because initially, it won't allow any communication on port 7861 for security reasons. So allow an ad-hoc communication on port 7861.

Customer data

Notice at the server console, it will notify that the CustomerManager constructor has been called, right after displaying the output in the client project as in the following.

Customer Manager

We can also confirm whether or not the socket is created on port 7861 by encountering the netstat command as in the following.

Active connections

Summary

This article provided an introduction to .NET Remoting, one of the Distributed Computing technologies. We are now familiar with the various aspects in which .NET Remoting fits in and is applied. We dug deeper into remoting concepts and their advantages in detail. We also came to understand with a live example of remoting technology by creating three assemblies that encapsulated a general assembly, server program, and client application.


Similar Articles