Introduction

Remoting is a very vast and one of the most complex topics in .NET development. Entire books have been written to explain and demonstrate the concept of remoting. This article is an effort to demystify remoting in simple terms and put forth the basic concepts of remoting.

Distributed Application Development

Distributed applications allow objects to communicate or talk outside process boundaries and application domains. Enterprise applications benefit greatly from the distributed application architecture. Distributed application development or distributed computing in .NET is typically implemented using one of two approaches - .NET remoting or Web Services. .NET Remoting and XML Web services give developers a rich framework to create distributed applications.

But what is .NET Remoting? .NET Remoting allows client applications to instantiate components on remote computers and use them as though they were local objects. Remoting is a mechanism through which a .NET client application can interact with a .NET component that’s part of another application domain.

.NET remoting is used when both the client and server are under your control. XML web services are used when they are not. XML Web service objects are single use - they are created at the beginning of each call and destroyed at the end of each call. Remoting enables you to create and use stateful objects. Remoting also offers you great flexibility. Unlike Web services which mostly use SOAP messages to exchange information, remoting allows you to implement and use binary channels as well. Remoting is simple to configure and easy to scale. It’s ideal if you want to maintain state or you need to create a peer to peer application.

You should not however make use of distributed computing or remoting needlessly. If you are going to be create components that are going to be on the same computer, you don’t need remoting. If you are designing a small scale system that can work well without a distributed architecture then don’t use it just for the sake of it. The overhead would be too much.

Delving Deep

There are various actors on the stage of remoting.

Remotable Class

A remotable class can be invoked remotely. It is typically derived from MarshalByRefObject or a child class of MarshalByRefObject. All the public members of a remotable class can be invoked or used remotely. To use or invoke the remotable object on a client, you need a server. This server must be a dedicated one so that it can listen to client requests and create the remotable objects as and when necessary. The server can either be a console based application, a Windows Forms application with a GUI, or a Windows service.

Remotable objects, that is, instances of the remotable class, are classified into two types: Marshal By Value (MBV) and Marshal By Reference (MBR).

MBV objects are present on the server. MBV objects are copied and sent from the server application domain to client application domain. When a client calls a method on the MBV object, the object is serialized, transferred over the network and restored on the client as an exact copy of the server-side objects. Once this is done, the object becomes locally available to the client. MBV objects don’t need to be remotely activated because the MBV object itself is transferred to the client side.

MBR, on the other hand, are remote objects. They always reside on the server and all methods called on them are executed at the server side. In MBR, a proxy is used to access these objects on the client side. The client just holds a reference to object. The client uses a local proxy object holding the reference to the MBR object in order to call its methods.

When to use which?

Use MBV for faster performance and fewer network round trips. Use MBR for very large objects or when the functionality of the object is available only in the server on which it is created.

MBR objects are of two types: Server activated and client activated.

Server Activated Objects (SAO) have lifetimes controlled by the server. The remote object when requested by a client is instantiated or activated on the server only when a client calls a method on the proxy of the remote object that is created on the client side. Only the default constructor can be used to instantiate SAO. SAOs can be either Singleton SAO or Single Call SAOs.

• Singleton: Stateful but shared between every client. There is always only one remote object instance.
• Single Call: Stateless objects, automatically created with every method invocation, live only for the duration of the method call. Every call results in the creation of a new object.

You will use a Single Call approach when you don’t want an object to maintain state, when you expect many requests on the server and the overhead of creating an object is not important.

You will use Singleton objects when the object needs to retain state, many clients need to work on the same instance and when the overhead of creating the object is substantial.

To repeat, server activated objects are not created when the client instantiates them but instead created only when the first method call is made.

Remote objects activated as server activated objects are also called well-known objects.

Client Activated Objects (CAOs) are created as soon as the client instantiates them. Also, CAOs can use parameterized constructors.

The other actors in the remoting world are: a formatter and a transport channel.

A formatter packages client requests or server responses in the appropriate format. It can serialize a message into a binary or SOAP format before sending it. SOAP and Binary formatters are the commonly used ones. You can also create custom formatters if you wish.

A transport channel transmits the information using the appropriate protocol. HTTP and TCP channels are the commonly used ones. You can also create custom channels if you wish.

The System.Runtime.Remoting namespace is the core for implementing .NET remoting architecture.

This namespace provides classes and interfaces that allow developers to create and configure distributed applications.

In addition, other commonly used namespaces for implementing remoting are:

• System.Runtime.Remoting.Activation
• System.Runtime.Remoting.Channels
• System.Runtime.Remoting.Messaging

We shall now see an example to understand remoting. Consider that you are running a jewelry manufacturing company named Ark Jewelries and that you have offices scattered all over the globe. Buyer details and product details are stored in a centralized database. You now want to develop a distributed system that will enable an end user in one location to access information from the database using a server present in another location.

Consider that you will supply the buyer id through a user interface (in a Windows Forms application) and you need to retrieve the phone number of the buyer based on the id. You wish to make use of remoting for all the advantages that it has to offer.

The ideal course of action would be to have a database logic class that will act as a remotable class, and create a remotable server and client. Finally, invoke an instance of the remotable class in the client. The first step will be to create the remotable class. We shall create this as a class library so that it compiles into a DLL.

Launch Visual Studio 2008 and select File-> New Project. Choose Visual C# as the language and Class Library as the project type. Rename the class library as ArkLibrary.

Rename the default Class1 class to ArkClass.

Replace the default code in the class with the code given below:

What was done in the above class is summarized briefly here:

• A boolean variable is declared to keep track of the server, whether it is running or has been stopped.
• The class contains 2 user-defined methods: GetPhoneNumber() and GetData().
• Within GetPhoneNumber, the database connection is created and opened.
• An SQL query is constructed to retrieve the phone number and the data that is returned after executing the query is sent back to the calling program.
• Within GetData, the database connection is created and opened.
• An SQL query is constructed to retrieve the buyer id and name and the data that is returned after executing the query is stored in an ArrayList and returned back to the calling program.

Next, create a new Windows Forms project in the same solution by right clicking on the Solution and then selecting Add and New Project.

Rename the project to ArkMain. Add a Project Referece to System.Runtime.Remoting. Add a reference to the dll created in the previous step – ArkLibrary.dll.

Create the user interface for the server as shown in the Figure 3.

Replace the default code in the Form with the following code:

What was done in the above code is summarized below:

• There are 2 event handlers and one user-defined method.
• The event handlers are for the btnRun and btnShutDown respectively. They start and stop the server. The user-defined method contains the logic to start the server. It creates and registers a channel and then specifies that the remotable object will be of type Singleton. Therefore, we have created the code for a server that will register the remotable object as a server activated object in the Singleton mode.

The next action would be to create the client. Create a new Windows Forms project in the same solution named ArkBuyer. Again, add References to ArkLibrary.dll and System.Runtime.Remoting. Create a user interface with a combobox and a button and a text box as shown in the Figure.

Replace the default code with the following code:

What was done in the above code is summarized briefly:

When the client is loaded, the combo box has to be populated with the buyer ids and names. To retrieve this data, the GetData() method of the remotable object has to be invoked. Hence, the client creates and registers a channel. Then it registers the remotable object as a well-known type and creates an instance of it. The method GetData() is then invoked and the data is populated into the combo box. When the end user selects a buyer id, the corresponding phone number has to be retrieved. To do this, the GetPhoneNumber() method of the remotable object is invoked and the relevant data is finally retrieved and displayed.

As this was an MBR, the methods will be executed at the server side. And because this is a Singleton mode, the object will retain state.

Build each of the projects. To run each project, select “Debug-> Start new instance” from the Context menu. Some dummy data has been entered into the database. The output of the client is seen in the Figure:

Summary

You’ve learned what is remoting, what are its advantages, what are the different terms used in remoting, and also explored an example that demonstrated remoting in action.

About Medusa M

Medusa loves experimenting with technology trends, especially that of Microsoft. This author has published 14 articles on DotNetSlackers. View other articles or the complete profile here.