Remoting advanced knowledge
First, how to use IIS as an activation agent
One difference between .NET Remoting and DCOM is that the former does not support automatic running server processes. It is necessary to manually start the server process to register classes and listening requests for remotely activation. For DCOM, the server process is automatically run when the remote client calls CoCreateInstanceex or other activation API.
.NET Remoting provides two ways to avoid artificial starting servers. The first is to implement the server application as a service. Can write a
System.ServiceProcess.service derived service, overloading the key required method such as onstart and onstop. The benefit of making a server as a service is that you can configure the service to automatically run the service when the system starts.
The second method is to use IIS as an activation agent. IIS itself is a service, which will start at most Web Servers. Moreover, IIS can respond to client activation of objects by using the .NET Remoting mechanism. Use IIS has the following benefits:
1. No longer need to write a server for registering a remote class and listening port, IIS is the server.
2, you can use IIS to identify the remote caller, or you can use SSL to protect the data.
3, you can use IIS to manage ports. If you deploy two traditional application servers on a machine, you need to guarantee that both servers use different ports. Using IIS as a host, IIS can select a port, which simplifies publishing and management.
IIS supports server-side activation objects and client activation objects. You can use program registration (in Global.asax), you can also use a declaration registration (in Web.config).
1, server-side activation object
The following Web.config registers the CLOCK class that uses IIS activation:
Note Clock's URI: Clock.Rem. Uri registered with IIS must end with .rem or. SoAP because the extension corresponds to the ASPNET_ISAPI.DLL and Machine.config in the IIS original data. Net Remoting subsystem.
Using IIS activation objects are communicated with the client via HTTP channels. The client must register an HTTP channel. Here is how a client creates a CLOCK instance, assumes that the clock is on 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 that both the server and the client are not specified port, IIS selection this port
2, client activation object
Web.config file registration registration a client activation object Clock
Below is the client's writing (still assumed that the 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: Use IIS must have a remote class in the virtual directory, and Web.config must be placed in a separate virtual directory (such as MyClock), put the DLL in the bin subdirectory (MyClock / bin).
Second, how to pass binary format data via HTTP channel
One disadvantage of using IIS is that only HTTP channels can be used. The HTTP channel will call the package into a SOAP message, which increases the length of the message. IIS only supports HTTP channels, but it does not require the use of encapsulating channel calls into SOAP messages. By default, HTTP uses SOAP because it uses SOAPCLIENTFORMATTERSINKPROVIDE and
SOAPSERVERFORMATTERSINKPROVIDER is used as a format for serialization and deserialization messages. BinaryClientFormattersinkProvider and
BinaryServerFormattersinkProvder replaces them. Binary messages can be used with network bandwidth.
The following web.config file registers a Clock that can be activated by IIS, which replaces the default SOAP format with binary.
Objecturi = "clock.rem" /> The client is written 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 the configuration file, the Wait is: RemotingConfiguration.configure ("Client.exe.config"; Clock clock = new clock (); The configuration file content is as follows: URL = "http://localhost/myclock/clock.rem" /> With the same way, you can also use SOAP format package messages in the TCP channel. You can even insert your formatting method into the existing channel. Third, how to use events and agents Suppose you have created a Clock class, including a NewHour event, the code as follows: Public Delegate Void NewHourceler (Int Hour); Public Class Clock: MarshalByrefObject { Public Event NewHOURHANDLER NEWHOUR; ... } The web.config file used on IIS is as follows: Objecturi = "clock.rem" /> Note that the REF property, the HTTP value makes TW-WAY HTTPCANNEL instead of One-Way HttpserverChannel. The client is written as follows: RemotingConfiguration.configure ("Client.exe.config"; Clock clock = new clock (); Clock.newHour = New NewHOURHANDLER (OnnewHour); . . . Public void OnnewHour (int Hour) { // NewHour Event Received } URL = "http://localhost/myclock/clock.rem" /> The client also registered a TWO-WAY HTTPCHANNEL, and the specified port number is 0.0 values such that the channel monitors callback, of course, can also allow the .NET framework to select the number of ports. Fourth, how to call a remote object asynchronously By default, the calling remote object is synchronized.
