A Simple Facade for .Net Remoting

• Download the sample code for this article - 21.24 KB

Introduction

This article and the accompanying source code demonstrate how to implement .Net Remoting using each of the combinations of formatters, channel protocols and activation modes. For this purpose, I have implemented a Facade for the .Net Remoting API. You might want to use the source code as a learning and experimentation tool to help understand how each remoting mode works through side by side comparison of the way each is implemented.

Background

There are many excellent articles on .Net Remoting on the net.
This one, by Juval Lowy, provides an excellent overview of the technology. I recommend you read it before continuing.
The implementation of Client Activated objects in the Facade makes use of the Factory pattern as described here in the MSDN. .

The basic idea behind this pattern is to implement Client Activation by implementing Server Activation of a factory object and by then calling the factory method to create the remoted object on the server (and the proxy on the client). This strategy provides the functionality of Client Activation without the liability of having to copy remote object assembly onto each client location. As Juval explains in his article, Client Activation allows clients to instantiate a remote object for each activating client and to control the lifetime of that object.

Using the code

The purpose of this sample solution is to add any two integers using a remote calculator object.

The solution contains 4 assemblies:

Server.exe		is a console application that implements and hosts the calculator object.
Client.exe		is a console application that obtains a proxy to a remote calculator object and calls it's Add method, printing the result.
RemotingFacade.dll		is a class library providing a Facade that exposes the basic functionality of .Net Remoting to Client.exe and Server.exe.
CalculatorInterface.dll		is a class library that contains the interface of the calculator class with no executing code.

Server.exe references CalculatorInterface.dll in order to derive the concrete Calculator object from this interface. It also references RemotingFacade.dll and uses its RemotingServer object to register the Calculator class for the server side of remoting.

Client.exe references CalculatorInterface.dll in order to cast the reference to the remote calculator object to this interface. It also references RemotingFacade.dll and uses its RemotingClient object in the RemotingFacade.dll to obtain a proxy that references a remote Calculator.

Points of Interest

It is important to note that of all 4 assemblies, only RemotingFacade.dll references System.Runtime.Remoting and uses its namespaces. Server.exe and Client.exe have no knowledge of .Net Remoting APIs.

Conversely, RemotingFacade.dll has no knowledge of the Calculator object or even of its ICalculator interface.

From the deployment point of view, Server.exe and Client.exe reside at different location, including on two different computers. Both locations will have copies of the CalculatorInterface.dll and RemotingFacade.dll assemblies. Having said this, the client location will not have a copy of Server.exe which implements the addition operation.
This is an important benefit because it means that we are not required to expose our core "add" technology to any client machine where it might be hacked or copied.

History

Version 1.0