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. This peices 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 remotable 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 diverse 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 over 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, integration of these technologies could be a daunting task for system architects. Remoting technology like .NET Remoting, CORBA and SOAP are 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 program 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 objects 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 characteristics

• It gives you a flexible and extensible framework that allows for different transfer mechanism such as HTTP and TCP, encoding (binary and SOAP) and security setting such as SSL and IIS security.
  
  
• We can use this technology anywhere such as on console application, Windows application, COM components or Windows services applications.
  
  
• .NET Remoting enable 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. getCust(), that 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 Name, 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 these 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 a 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, that 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.



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:



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



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