In the previous examples, we used "TCP Channel" to communicate the remote object in the server machines. Also, we have the reference to the server project in the client development projects. Giving the code to the client is not advisable as the client can go ahead and strip the given to know some of the implementation details.
In this article, we will look at how do we use the "Http channel" for communication and how do we create the Metadata proxy from the server deployed remote objects using the "SoapSuds" command line utility. OK. Let us start. The explanation is reduced here. Read my first article on Dot.Net remoting link for basic details on remoting.
2. The Http remote Server
1) The server is a C# console application. It has a simple remote object called RServer. Please note that the namespace name also RServer. It is not good having namespace and class name in the same name. So I would recommend separating the class name from the Server namespace. As usual, our RServer class is derived from the MarshalByRefObject class to make it a remote object. Below is the code for it:
//Server 01: Required Declarations
//Server 02: Http based Server
class RServer : MarshalByRefObject
public void TestObject()
Console.WriteLine("Object Test. Test Object Function called" + Environment.NewLine);
In the constructor, we are just printing some message so that we can ensure whether server object is created or not just by looking at the console window of the server. Also, note that this time we are going to use the HTTP channel and hence included the channels.http (using System.Runtime.Remoting.Channels.Http;)
2) In the server application main, we are creating http channel and then registering the remote object as a SingleCall object. As the basic example (First article on DotNet remoting) has all the required explanation, I am skipping those repeated details here. Below is the code:
static void Main(string args)
//Server 03: Create a http channel for soap and register it.
HttpChannel httpchnl = new HttpChannel(7212);
// Server 04: Register the server object
// Server 05: Make the server running
Console.WriteLine("Server Started" + Environment.NewLine);
3. Generating MetaData dll to share with client
Once the server is ready we are all set to go ahead and create the Metadata assembly that can be shared with the client piece code. Remember in the previous example when I used the TCP communication channel, I usually add whole server project as the reference. The alternate technique to that is having the declaration in a separate assembly (dll) and shipping that to the client. Here we are going to generate separate metadata dll for our server and going to ship that dll to the client.
To generate the Metadata dll, first, run the server project or Exe. When the server is in the running state, launch the Dot net command prompt and access the "SoapSuds" utility. Below is the option switches used to generate the metadata assembly for our server example:
SoapSuds –oa:<OutputName>.dll –Url:http://Localhost:<PortNo>/<RemoteObject>?Wsdl
In the above command,
oa - option specified the output path and name of the dll
-URL – option specifies the http url to the remote object for which we want to create the meta data dll
Creating the DLL is shown in the below video.
4. Consuming the metadata dll in the client
The client is also Visual C# console application. Once the client project is created, after giving the reference to dotnet remoting, the reference to the metadata dll is given using the browse tab of the add reference dialog box. Once the reference is given, we have access to the remote object and we can create it using the new operator.
Getting the reference to the metadata dll in the client project is shown in the below video.
5. Accessing the Remote object through Http
Once you created the reference to the Meta dll formed on the server machine using soapsuds, you can simply access the remote object using the new operator just like you create normal objects. Below is the explanation for the code:
1) RServer is the namespace in the server. Note that in the server implementation the Remote class name, as well as the namespace name both are same.
//Client 01: Use the Meta data dll.
2) The remote object is created using the new operator. But, in the background, through the Meta data DLL, we are making a call to the wrapped assembly to get the proxy. This proxy object actually calls the real object at the server end. And it knows the communication protocol, server address and port number of the communication.
//Client 02: As we have proxy to the remote as wrapped meta data, you can use new oprator
// to create the object
Console.WriteLine("Creating the Instance of Remote object\n");
RServer.RServer RemoteObj = new RServer.RServer();
3) The remaining lines of code are simple as it just makes a call to the function exposed by the above-created object. In user perspective, it is just an object. But, the function call is executed on the server. You can observe that by looking at the server machine’s console window. Below is the piece of code that does not require much explanation:
//Client 03: Calling the Remote method
Console.WriteLine("Press any key to Make a call to Remote function\n");
Console.WriteLine("Press any key to Close");
Source Code : Download
Note: The sample is created using the VS2005 IDE.