Programming Remoting Advanced knowledge
How to use IIS as an activation agent
One difference between. NET Remoting and DCOM is that the former does not support Autorun server processes. You need to manually start the server process to register the classes and listening requests that are used for remote activation. For DCOM, the server process is automatically run when the remote client invokes CoCreateInstanceEx or other activation APIs.
. NET Remoting provides two ways to avoid manually booting a server. The first is to implement the server application as a service. Can write a from
System.ServiceProcess.Service derived services that overload the key requirements such as OnStart and OnStop. The advantage of having a server as a service is that you can configure the service to run it automatically when the system starts.
The second method is to use IIS as the activation agent. IIS itself is a service that starts when most Web servers run. And IIS can respond to requests for client-activated objects by using the. NET remoting mechanism. There are several benefits to using IIS:
1. You no longer need to write a server that registers remotable classes and listening ports, and IIS is the server.
2, you can use IIS to authenticate remote callers, or you can use SSL to protect your data.
3, you can use IIS to manage ports. If two traditional application servers are deployed on one machine, you will need to ensure that the two servers use different ports. With IIS as the host, IIS can select ports, which simplifies publishing and administration.
IIS supports server-side activation objects and client-activated objects. You can register with the program (in Global.asax), or you can use the declaration registration (in web.config).
1, server-side Activation object
The following Web.config registers the clock classes that are activated using IIS:
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode= "SingleCall" type= "Clock, Clockserver" objecturi= "Clock.rem"/>
</service>
</application>
</system.runtime.remoting>
</configuration>
Pay attention to Clock's URI:Clock.rem. URIs registered with IIS must end with. rem OR. Soap, because the extension corresponds to the. NET Remoting subsystem in Aspnet_isapi.dll and Machine.config in the original data of IIS.
Using IIS to activate the object is to communicate with the client through the HTTP channel. The client must register the HTTP channel. Here is how a client creates a clock instance, assuming that clock is in a virtual directory called Myclock on the local machine.
HttpClientChannel channel = new HttpClientChannel ();
ChannelServices.RegisterChannel (channel);
Remotingconfiguration.registerwellknownclienttype
(typeof (Clock), "Http://localhost/MyClock/Clock.rem");
Clock Clock = new Clock ();
Note Both the server and the client do not specify a port and IIS chooses the port
2. Client-Activated Object
Web.config file Registration registers a client-activated object clock
<configuration>
<system.runtime.remoting>
<application>
<service>
<activated type= "Clock, Clockserver"/>
</service>
</application>
</system.runtime.remoting>
</configuration>
The following is the client's notation (still assuming clock is in the local machine Myclock virtual directory):
HttpClientChannel channel = new HttpClientChannel ();
ChannelServices.RegisterChannel (channel);
Remotingconfiguration.registeractivatedclienttype
(typeof (Clock), "Http://localhost/MyClock");
Clock Clock = new Clock ();
Note: You must have a remotable class in the virtual directory using IIS, and you must place the web.config in a separate virtual directory (for example, Myclock) and place the DLL in the bin subdirectory (Myclock\bin).
Second, how to pass the binary format data through the HTTP channel
One disadvantage of using IIS is that you can only use the HTTP channel. The HTTP channel encapsulates the call into a SOAP message, which increases the length of the message. IIS supports only HTTP channels, but it does not require the use of encapsulation of channel calls into SOAP messages. By default, HTTP uses SOAP because it uses soapclientformattersinkprovide and
Soapserverformattersinkprovider as a format for serializing and deserializing messages. You can use Binaryclientformattersinkprovider and
Binaryserverformattersinkprovder to replace them. Binary messages can be used to make good use of network bandwidth.
The following Web.config file registers a clock that can be activated by IIS, which replaces the default SOAP format with a binary.
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode= "SingleCall" type= "Clock, Clockserver"
objecturi= "Clock.rem"/>
</service>
<channels>
<channel ref= "http Server" >
<serverProviders>
<formatter ref= "binary"/>
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
The client is worded as follows:
HttpClientChannel channel = new HttpClientChannel
("Httpbinary", New Binaryclientformattersinkprovider ());
ChannelServices.RegisterChannel (channel);
Remotingconfiguration.registerwellknownclienttype
(typeof (Clock), "Http://localhost/MyClock/Clock.rem");
Clock Clock = new Clock ();
When using a configuration file, it is written as:
RemotingConfiguration.Configure ("Client.exe.config");
Clock Clock = new Clock ();
The contents of the configuration file are as follows:
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type= "Clock, Clockserver"
Url= "Http://localhost/MyClock/Clock.rem"/>
</client>
<channels>
<channel ref= "http Client" >
<clientProviders>
<formatter ref= "binary"/>
</clientProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Using the same method, you can also encapsulate messages in a TCP channel using the SOAP format. You can even insert your own formatting methods into an existing channel.
Iii. How to use events and proxies
Suppose you create a clock class that includes a Newhour event with the following code:
public delegate void Newhourhandler (int hour);
public class Clock:marshalbyrefobject
{
public event Newhourhandler Newhour;
...
}
The web.config files that are used on IIS are as follows:
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode= "Singleton" type= "Clock, Clockserver"
objecturi= "Clock.rem"/>
</service>
<channels>
<channel ref= "http"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Note the ref attribute, which causes the two-way httpcannel to replace the one-way httpserverchannel.
The client is worded as follows:
RemotingConfiguration.Configure ("Client.exe.config");
Clock Clock = new Clock ();
Clock. Newhour + = new Newhourhandler (onnewhour);
.
.
.
public void Onnewhour (int hour)
{
Newhour Event Received
}
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type= "Clock, Clockserver"
Url= "Http://localhost/MyClock/Clock.rem"/>
</client>
<channels>
<channel ref= "http" port= "0"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
The client also registers a two-way HttpChannel, and the specified port number is 0. A value of 0 allows the channel to listen for callbacks, of course. NET Framework to select the number of ports.
Iv. how to invoke a remotable object asynchronously
By default, calling remote objects is synchronous.
