C# Bible - Jeff Ferguson, Brian Patterson, Jason Beres

Table 36-4: System.Runtime.Remoting.Channels.Http Namespace

Up to this point, you can add the correct namespaces and code to register an HTTP channel and a TCP channel for the host application. Listing 36-2 shows how the host application should look after the channels are registered.

Listing 36-2: Registering Channels

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Tcp; using System.Runtime.Remoting.Channels.Http;

namespace Client

{

///<summary>

///Summary description for Class1.

///</summary>

class RemotingClient

{

[STAThread]

static void Main(string[] args)

{

TcpChannel chan1 = new TcpChannel(8085); ChannelServices.RegisterChannel(chan1);

HttpChannel chan2 = new HttpChannel(8086);

ChannelServices.RegisterChannel(chan2);

}

}

}

Note You do not need to use an HTTP channel and a TCP channel in the host application. If you are enabling clients to call on both channel types, you can register both channel types; normally, however, you use one formatter, TCP or HTTP, based on the type of clients that are accessing your remote object.

Activating the remote object

The last task to perform to host the remote object is to register the assembly with the remoting framework. In your host application, before you can activate the assembly that contains your methods, you first need to add a reference to the assembly. Right-click the References object in the Solution Explorer, which brings up the Add Reference dialog box. In the application you are writing here, you need to browse to the C:\cSharpRemoting\HostObject directory and

add the HostObject.dll assembly to your application. After you add this, you can add the HostObject namespace to your class file using the using statement, as the following snippet shows:

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Remoting.Channels.Tcp; using HostObject;

Now that you have added a reference to your remoting assembly created earlier, you can add the code that registers the object with the remoting framework. You can do this in one of two ways:

•Use the RegisterWellKnownServiceType() method of the RemotingConfiguration class to pass the type of the object that you are creating, the URI of the object, and the activation mode of the object.

•Use the Configure() method of the RemotingConfiguration class to pass a configuration file with the object activation details.

Each activation method works the same way, but storing your activation details in a configuration file gives you more flexibility if any of the activation details change, such as the port number of the channel you are using. You will consider both types of activation, but first examine the available methods and properties of the RemotingConfiguration class described in Table 36-5 and Table 36-6, respectively. Besides the activation methods described previously, you can use many helpful methods and properties in this class to discover information at runtime about your running objects.

Table 36-5: RemotingConfiguration class Methods

static void Main(string[] args)

{

TcpChannel chan1 = new TcpChannel(8085);

ChannelServices.RegisterChannel(chan1);

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(HostObject.Class1), "ReturnName",

WellKnownObjectMode.SingleCall);

Console.WriteLine("Press any key to exit");

Console.ReadLine();

}

}

}

Because the host application is a console application, you add the Console. ReadLine statement at the end so that the console window stays open while clients are using the remote object. The lifetime of the channel is the length of time that window happens to be open. After you close the console window, the channel is destroyed and the lease on that particular channel is expired in the remoting framework.

The WellKnownObjectMode enumeration contains two members that define how objects are created. If the WellKnownObjectMode is SingleCall, then each request from a client is serviced by a new object instance. This would be represented by the following pseudo-code:

Create Object X

Call Method of Object X

Return data back to caller

Destroy Object X

Garbage Collect

If the WellKnownObjectMode is Singleton, then each request from a client is serviced by the same object instance. This can be described in the following pseudo-code:

Create Object X

Call Method of Object X Return data back to caller Call Method of Object X Return data back to caller

... continue until channel destroyed

This loop continues until the channel with which this object is registered in the remoting framework is destroyed.

Depending on the type of application you are writing, you determine which activation mode to use by considering the following factors:

•Overhead: If creating the remote object consumes resources and takes time, then using the SingleCall mode may not be the most efficient way to create your object, as the object is destroyed after each client is done using it.

•State Information: If you are storing state data in your remote object, such as properties, you use Singleton objects, which are capable of maintaining state data.

Registering objects with the Configure method

If you need a more flexible way of maintaining the configuration data that the remoting framework needs to register your object, you can use the Configure() method of the RemotingConfiguration class. The configuration information that is stored in the file is the same information that you can use in the RegisterWellKnownServiceType() method. The benefit of using a configuration file is that if any of the settings for the object change, you can alter the configuration file, and not change any of your code. The schema for the configuration is shown in Listing 36-4, with the explanation of each element in Table 36-7.

Listing 36-4: Remoting Configuration File

<configuration>

<system.runtime.remoting>

<application>

<lifetime> <channels> (Instance)

<channel> (Instance) <serverProviders> (Instance)

<provider> (Instance) <formatter> (Instance)

<clientProviders> (Instance) <provider> (Instance) <formatter> (Instance)

<client>

<wellknown> (Client Instance) <activated> (Client Instance)

<service>

<wellknown> (Service Instance) <activated> (Service Instance)

<soapInterop>

<interopXmlType>

<interopXmlElement>

<preLoad> <channels> (Template)

<channel> (Template) <serverProviders> (Instance)

<provider> (Instance) <formatter> (Instance)

<clientProviders> (Instance) <provider> (Instance) <formatter> (Instance)

<channelSinkProviders> <serverProviders> (Template)

<provider> (Template) <formatter> (Template)

<clientProviders> (Template) <provider> (Template) <formatter> (Template)

<debug>

Although there are many options in the configuration file, you only need to use what your application requires. For example, the snippet of code in Listing 36-5 represents a configuration file for an HTTP-activated object that is a SingleCall mode object.

Listing 36-5: Configuration File Example

<configuration>

<system.runtime.remoting>

<application>

<client url="http://localhost/HostObject"> <wellknown type="HostObject.Class1,

ReturnName" url="http://localhost/HostObject/Class1.soap" />

</client>

<channels>

<channel ref="http" /> </channels>

</application>

</system.runtime.remoting>

</configuration>

After you create the configuration file, creating the host object is dramatically simpler than it is when registering an object with the RegisterWellKnownServiceType() method of the RemotingConfiguration class. The code in Listing 36-6 demonstrates how to register the object using the Configure() method.

Listing 36-6: Using a Remoting Configuration File in the Host Class

namespace Host

{

///<summary>

///Summary description for Class1.

///</summary>

class Class1

{

///<summary>

///The main entry point for the application.

///</summary>

[STAThread]

static void Main(string[] args)

{

RemotingConfiguration.Configure("Host.Exe.Config");

Console.WriteLine("Press any key to exit");

Console.ReadLine();

}

}

}