Using Web Services for Remoting over the Internet.

2022-07-15 80酷酷网 80kuku.com

　　Introduction
This article describes a design and implementation (C#) of the Remoting over Internet using the Web Service as a gateway into the Remoting infrastructure. The Web Service Gateway (Custom Remoting Channel) allows to enhance the remoting channel over Internet and its chaining with another heterogeneous channel. Consuming a remote object over Internet is full transparently and it doesn't require any special implementation from the remoting via intranet. The Web Service Gateway enables to create a logical model of the connectivity between the different platforms and languages. Before than we will go to its implementation details, let's start it with usage and configuration issue. For some demonstration purpose I will use a MSMQ Custom Remoting Channel (MSMQChannelLib.dll), which I described in my previously article []]. I am assuming that you have a knowledge of the .Net Remoting and Web Service.
Usage
Consuming a remote object over Internet using the Web Service Gateway is very straightforward and it actually requires only to install the following assemblies:

, this is a Custom Remoting Channel on the client side to forward a remoting message to the Web Service Gateway over Internet (outgoing message).
, this is a Web Service (gateway) to listen an incoming message from the client side and forward it to the local remoting infrastructure (incoming message).

Note that the above assemblies have to be installed (into the GAC) both on the server and client sides when a remote callback is used.
The next step is to configure a server and client host sides. Their configuration are depended from the actually application. Let me assume, we want to call a remote object driven by MSMQ custom channel over internet. Their config files might look like the following snippets:
server.exe.config
<configuration>
<system.runtime.remoting>
  <application >
   <service>
    <wellknown mode="Singleton" type="MyRemoteObject.RemoteObject, MyRemoteObject"
               objectUri="endpoint" />
   </service>
   <channels>
   <channel type="RKiss.MSMQChannelLib.MSMQReceiver, MSMQChannelLib"
            listener=".\ReqChannel"/>
   <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting"
            port="8090" />
   </channels>
  </application>
</system.runtime.remoting>
</configuration>
The above server config file will register two channels to listen an incoming message for the remote well known singleton object.
client.exe.config
This is an example of the client config file to register our Custom Remoting Channel.
<configuration>
<system.runtime.remoting>
  <application>
   <client >
    <wellknown type="MyRemoteObject.RemoteObject, RemoteObject"
               url="ws://localhost/WebServiceListener/Listener.asmx;
               tcp://localhost:8090/endpoint/RemoteObject" />
   </client>
   <channels>
    <channel type="RKiss.WebServiceChannelLib.Sender, WebServiceChannelLib" mode="soap"/>
   </channels>
  </application>
</system.runtime.remoting>
</configuration>
The ws is a Custom Remoting Client channel to dispatch an IMessage over internet using a binary respectively soap mode formatter. Note that the mode is a CustomChannelProperty and its default value is binary.
web.config
This is a Web Service config file. The following snippet is its part. The Web Service gateway is also a local remoting client, therefore a client (sender) channel is requested to be registered. The following snippet shows a configuration of the two channels - Tcp and MSMQ.
<system.runtime.remoting>
<application >
  <channels>
   <channel type="System.Runtime.Remoting.Channels.Tcp.TcpChannel, System.Runtime.Remoting"/>
   <channel type="RKiss.MSMQChannelLib.MSMQSender, MSMQChannelLib"
            respond=".\RspChannel" admin=".\AdminChannel" timeout="30" priority="10"/>
  </channels>
</application>
</system.runtime.remoting>
Activating a remote object
The well known remote object (WKO) is activated by its consumer using the GetObject method mechanism. The proxy is created based on the remote object metadata assembly installed in the GAC (see an argument objectType). The remoting channel is selected by the objectUrl argument. The url address in this solution has two parts :

connectivity to the Web Service gateway over internet
connectivity to the Remote object over intranet within the Web Service gateway

Between the primary and secondary addresses is a semicolon delimiter as it is shown the below:
string objectUrl = "ws://localhost/WebServiceListener/Listener.asmx; msmq://./reqchannel/endpoint";
Using this objectUrl design pattern allows an easy selection of the web service gateways on the Internet. Note that the ws custom remoting channel will trim this primary address and forward only its secondary part. In this solution, the objectUrl represents a physical path of the logical connectivity between the consumer and remote object regardless of how many channels are needed. In this example, the Web Service gateway resides on the localhost and it should be replaced by the real machine name.
Finally, the following code snippet shows an activation of the remote object:
// activate a remote object
Type objectType = typeof(MyRemoteObject.RemoteObject);
string objectUrl = "ws://localhost/WebServiceListener/Listener.asmx; msmq://./reqchannel/endpoint";
RemoteObject ro = (RemoteObject)Activator.GetObject(objectType, objectUrl);
Note that a metadata (assembly) of the remote object must be installed into the GAC in the places such as client, Web Service gateway and server host.
That's all for the client/remoteObject plumbing issue over the Internet.
The following pictures shows this connectivity:

Now, to understand how the message flows between the heterogeneous channels over the Internet, have a look at the following paragraphs: