Hosting and Deployment


As we’ve seen, a remoting object needs a host to expose it to the world. There are several types, each with its advantages and disadvantages. Your application’s success will depend in large measure on the type of host you choose. We will now discuss hosts.

Choosing a host is an important decision in remoting design.

We can use any old Windows Forms or console application as a remoting host, as I’ve done in these samples so far. These types of applications have the advantage that we’re in complete control of them. There isn’t any code inside them that we didn’t write. It’s very easy to run them in a debugger and look at the trace strings they output, set breakpoints, and so on. For development, this is probably the way that you need to at least start. However, in production, a system administrator would need to start and stop the host application every day, a human touch point we’d probably like to avoid. In addition, we don’t get any security or encryption services from our baseline application, which are important services if we don’t have control over all the clients as well as the servers.

Any application can be a remoting host, which is good during development.

We could write a Windows service, which is essentially a program that contains entry points that allow it to be automatically started and stopped by the service manager on the host computer, even without any logged-in user. Your system already contains many services that take advantage of this technique. Visual Studio contains a project type for a new service, so they aren’t hard to throw together. With a Windows service, we’d get automatic starting and stopping and a little easier administration, but we’d still be stuck with the security infrastructure problem.

You can host remoting objects in a system service.

In the end, we mostly find ourselves using Internet Information Services (IIS) as our host application, primarily because it’s the only way to get authentication and encryption at this stage of the .NET Remoting game, as I’ll describe in the next section. Unless you control the hardware environment and use hardware encryption and authentication, or your remoting clients and objects are on the same machine, you probably have to use IIS as your host. The drawbacks are that IIS requires the slower HTTP channel instead of TCP, and it adds some overhead of its own. You can regain some of this performance by specifying that the HTTP channel should use the available binary formatter instead of the default SOAP formatter, as I do in this example.

Your production host usually wants to be IIS.

I’ve written a sample program that demonstrates using IIS as a host. It’s in the \IISHost directory. You write your remoting object the same way you usually do; nothing changes here. You choose a physical directory on the disk and use the Internet Services manager to create a virtual directory that accesses it. You must perform your remoting configuration with a file instead of code because you don’t have control of IIS. The file must have the name web.config and must live in your virtual directory root, as we saw in Chapter 3. The config file entries are identical, except for two important differences, as shown in Listing 10-11.

An IIS hosting sample starts here.

Listing 10-11: Web.config file for IIS hosting.

start example
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <service> <wellknown mode = "Singleton" type="IISHostingObject.Class1, IISHostingObject" objectUri="IISHostingUriName.rem" /> </service> <channels> <channel ref="http"/> </channels> </application> </system.runtime.remoting> </configuration>
end example

First, you must use the HTTP channel, which means that you don’t have to specify a port; port 80 is assumed. Second, the URI name of the object must end in .rem or .soap (the former is shown). You place the actual component DLLs in a directory with the name \bin underneath the virtual directory root.

Writing a client is similarly easy. You make config file entries as shown in Listing 10-12. Note that we always use port 80 for HTTP, and the URI name ends in .rem as the server requires.

Listing 10-12: Client config file entries.

start example
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <channels> <channel ref="http" useDefaultCredentials="true" port="0"> <clientProviders> <formatter ref="binary" /> </clientProviders> </channel> </channels> <client> <wellknown type="IISHostingObject.Class1, IISHostingObject" url="http://localhost:80/RemotingIISHostVB/ IISHostingUriName.rem" /> </client> </application> </system.runtime.remoting> </configuration>
end example




Introducing Microsoft. NET
Introducing Microsoft .NET (Pro-Developer)
ISBN: 0735619182
EAN: 2147483647
Year: 2003
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net