Setting Up Remoting Communication

When your application is ready to access a class using marshal by reference and marshal by value across application domains, the remoting communication infrastructure must be prepared to handle the marshaling using the class RemotingConfiguration . The RemotingConfiguration class allows you to set up the communications for the remoting infrastructure programmatically or with configuration files. RemotingConfiguration also allows you to identify what class types are available for remoting. Well first show how to set up remoting communications programmatically and then well show how to set up remoting communications using configuration files.

Programmatic Set Up

Remoting communications have two sides, which are the client side (message sender) and the server side (message receiver). For a client to cross application domain boundaries and access the remotable class, a server must be available to sponsor the remoting infrastructure and communications.

Server

On the server side, youll need to select a remoting channel that will listen for communications from a client. The ChannelServices class allows you to select and register a channel programmatically by calling the RegisterChannel method. The RegisterChannel method accepts an instance of a remoting channel and registers the channel to the remoting infrastructure. Once a channel is registered, youll need to register class types that can be accessed on the server. Registering class types on the server can be accomplished by calling either RegisterActivatedServiceType or RegisterWellKnownServiceType . Both methods make a class type available to a remoting client. RegisterActivatedServiceType makes a class available as a simple class data type, while RegisterWellKnownServiceType registers a class as a Uniform Resource Identifier (URI) where the client has to specify a URI to access the type.

When a server registers a class type using RegisterWellKnownServiceType , the class type becomes server-activated , which means that the server side of the channel publishes the remoted class and makes an instance available to a client. By comparison, when RegisterActivatedServiceType is used, the class type becomes client-activated, which means that the client has to tell the server when to instantiate the class. Remoted classes that are server-activated can run in either singleton or in single-call mode. In singleton mode, all client calls to the remoted class type are handled by one instance of that object. This means that all client calls share a single instance of the remoted class. In single-call mode, a new instance of the class is created every time a call from the client comes in. When a class is client-activated, a new instance of the remoted class is created each time a call from the client arrives.

The following code sample shows how to set up the .NET Framework Transmission Control Protocol (TCP) channel to listen for remoting communication on TCP port 5150. The code also shows how to register the Demo.DemoClass presented earlier as a client-activated service type.

C#

 TcpChannelChannel=newTcpChannel(5150); ChannelServices.RegisterChannel(Channel); ActivatedServiceTypeEntryMyActivatedServiceTypeEntry= newActivatedServiceTypeEntry(typeof(Demo.DemoClass)); RemotingConfiguration.RegisterActivatedServiceType(MyActivatedServiceTypeEntry); 

Visual Basic .NET

 DimChannelAsTcpChannel=NewTcpChannel(5150) ChannelServices.RegisterChannel(Channel) DimMyActivatedServiceTypeEntryAs_ ActivatedServiceTypeEntry=_ NewActivatedServiceTypeEntry(_ GetType(Demo.DemoClass)) RemotingConfiguration.RegisterActivatedServiceType(_ MyActivatedServiceTypeEntry) 

Once this code runs, the TcpChannel will begin listening for remoting requests to access the DemoClass type. This code can be run from almost any type of application; for example, you could develop a Windows application that will host the TcpChannel . Or you could develop a simple console-style application that runs this code and waits for the user to stop the console application. The choice is yours. As long as the server-side application is running, the TcpChannel will continue to process remote requests.

Client

Accessing a remote class from the client side requires that you identify a class type to the client side remoting infrastructure as being available as a remote type. Two methods allow you to inform the remoting infrastructure that a class type is available as a remote type. They are RegisterActivatedClientType and RegisterWellKnownClientType . The RegisterActivatedClientType method will identify a remote class by type, while RegisterWellKnownClientType will identify a remote class as a URI. As discussed earlier, remote types on a remote server can be identified as simple types or as a URI depending how they are registered.

Once a class type has been identified as a type or as a URI to the client remoting infrastructure, your client application can begin accessing the class across a remoting channel. When your client application creates an instance of a registered class using the new operator, the client remoting infrastructure will set up a transparent proxy on the client that will be used to access methods and properties of the remote class on the server. The following code sample shows how to register the DemoClass described earlier as a client-activated type that will connect to a server using TcpChannel .

C#

 TcpChannelChannel=newTcpChannel(); ChannelServices.RegisterChannel(Channel); ActivatedClientTypeEntryMyActivatedClientTypeEntry= newActivatedClientTypeEntry(typeof(Demo.DemoClass), "tcp://MyServer:5150"); //RegisterDemoClassontheclientendsothatit //canbeactivatedontheserver. RemotingConfiguration.RegisterActivatedClientType(MyActivatedClientTypeEntry); //ActivatetheDemoClassasaremoteobject Demo.DemoClassTryDemo=newDemo.DemoClass(); 

Visual Basic .NET

 DimChannelAsTcpChannel=NewTcpChannel() ChannelServices.RegisterChannel(Channel) DimMyActivatedClientTypeEntryAs_ ActivatedClientTypeEntry=_ NewActivatedClientTypeEntry(GetType(DemoClass),_ "tcp://MyServer:5150") 'RegisterDemoClassontheclientendsothatit 'canbeactivatedontheserver. RemotingConfiguration.RegisterActivatedClientType(_ MyActivatedClientTypeEntry) 'ActivatetheDemoClassasaremoteobject DimTryDemoAsDemoClass=NewDemoClass() 

In this example, specific parameters such as remote channel port information and class type information are hard-coded for the remoting configuration. Hard-coded parameters do not make the application very flexible, especially if the application is designed to run in different operating environments. As an alternative, in this code we could have supported command-line parameters and set up the remoting communication. However, the RemotingConfiguration class offers a better way to configure the remoting infrastructure parameters by using configuration files.

Configuration File Setup

The most flexible way to set up communications in .NET remoting is by using XML configuration files on both the client and server to activate class types. A configuration file enables you to control every aspect of setting up remoting channels and object-activation activities without having to change your application directly. In this section well show how to set up a remoting channel that uses TCP to communicate over the network so a client can access the remotable class named Demo.DemoClass described earlier.

Setting up remoting communications on both the client side and server side requires calling the RemotingConfiguration.Configure method and passing an XML file that describes remoting settings for each side of a channel. An XML configuration file should have tags that describe specific remoting settings such as what classes you are remoting and what communications channel you plan to use. There are many tags consult the .NET Framework software development kit (SDK) for a complete listing.

Client

Setting up a remoting client requires constructing a client-configuration XML file and passing the file name to RemotingConfiguration.Configure . The following code fragment demonstrates how to set up client remoting using an XML file named client.config .

C#

 RemotingConfiguration.Configure("client.config"); 

Visual Basic .NET

 RemotingConfiguration.Configure("client.config") 

In the earlier discussion of programmatically configuring a remoting client, we configured the Demo.DemoClass to use the TCP remoting channel. The following XML script performs the same settings using an XML file.

 <configuration> <system.runtime.remoting> <applicationname="DemoClient"> <clienturl="tcp://localhost:5150"> <activatedtype="Demo.DemoClass,Demo"/> </client> </application> </system.runtime.remoting> </configuration> 

As this example shows, configuring settings such as channel information by means of XML configuration files allows you to make changes to your remoting applications behavior without changing any code.

Server

The server side is as easy to configure as the client side. In your application you also must invoke the RemotingConfiguration.Configure method and pass a server configuration XML file. Using the programmatic server configuration example described earlier, the following XML script shows how to register the demo class as an activated client type and use the TCP channel. The sample also tells the remoting server to listen for TCP communication on port 5150.

 <configuration> <system.runtime.remoting> <application> <service> <activatedtype="Demo.DemoClass,demo"/> /> </service> <channels> <channel ref="tcp" port="5150" /> </channels> </application> </system.runtime.remoting> </configuration> 

In the configuration examples provided so far, we selected the TCP remoting channel to use across application domains. We also called out specific parameters such as port settings. The next section describes all the available remoting channels in the .NET Framework that are used to sponsor communications between application domains. As we describe each channel, we also will list its configuration properties.

In the downloadable book samples there is a sample named RemotingExample that shows how to use marshal by reference and marshal by value as well as how to programmatically control remoting configurations.