.NET Remoting and XML Web Services Revisited | MicrosoftВ® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting (Pro-Developer)

Stubs and interfaces both solve one of the key problems with distributed applications and .NET: deploying the metadata to the client. Without this metadata, the client can't interact with the remote object.

The .NET Remoting solution is quite different from the approach taken with XML Web services. With XML Web Services, the client retrieves the metadata as a human-readable WSDL document. This allows applications on other platforms to interact with XML Web services, and it allows .NET to create a proxy class without requiring the original remote object assembly or even an interface.

Interestingly enough, .NET blurs the distinction between XML Web services and .NET Remoting and enables you to use some XML Web service features with components over .NET Remoting. We'll look at two examples, one that uses WSDL description and one that uses ASP.NET hosting.

Soapsuds and WSDL Description

Here's the first surprise: XML Web services aren't the only server-side technology that uses WSDL. In fact, you can retrieve a WSDL document for a component that's exposed through .NET Remoting, provided the server is using the HTTP channel.

Consider the CustomerDB example we looked at in the preceding section. To test this, modify the component host to use the HTTP channel, start the application, and enter the object URL in a browser, with ?WSDL appended at the end:

 http://localhost:8080/SimpleServer/CustomerDB?WSDL

A complete WSDL document displays in the browser. Interestingly, this WSDL document isn't completely compatible with those generated by an XML Web service. If you try to use this URL to add a Web reference in Visual Studio .NET, the process fails.

However, you can use a dedicated command-line tool to create a proxy class using this document. The tool is called soapsuds.exe, and it plays the same role that wsdl.exe served for XML Web services. To dynamically create a proxy class for the CustomerDB object, use the url parameter to specify the URL and the gc parameter to instruct soapsuds to create a code file. It names the file according to the remote object's class name. The client can create the remote object using the generated class, which encapsulates all the .NET Remoting details.

 soapsuds  url:http://localhost:8080/SimpleServer/CustomerDB?WSDL -gc

Soapsuds can create a proxy only in compiled form or C# source code; it does not support Visual Basic. Therefore, before you can use it in a Visual Basic .NET project, you need to compile the proxy class using the csc.exe compiler.

Incidentally, you can retrieve the WSDL documents for all the remote objects in a component host by omitting the object name and specifying RemoteApplicationMetadata.rem instead:

 http://localhost:8080/SimpleServer/RemoteApplicationMetadata.rem?WSDL

This always works in Visual Studio .NET 2002. In Visual Studio .NET 2003, however, this option is restricted by default as a security measure. You will need to enable it by modifying the channel information in the configuration file as shown here:

 <channel ref="tcp client" remoteApplicationMetadataEnabled="true" />

Remember that this doesn't mean that .NET Remoting can assume the role played by XML Web services. .NET Remoting still provides fewer options for cross-platform interaction and assumes that both client and server are .NET applications. However, the soapsuds tool provides some interesting insight into how .NET Remoting can work and provides another approach for distributing metadata. Interface-based development is generally preferred, but the soapsuds utility gives the client the ability to create a proxy class independently, as long as the component host is running. The interface-based and stub-based approaches require the server developers to go to the extra work of distributing the interface or stub assembly.

Finally, remember that soapsuds and WSDL description work only if the object is exposed by an HTTP channel. However, you can freely use the Binary Formatter.

ASP.NET Hosting

WSDL isn't the only surprise with .NET Remoting. You also can host a remote component in Microsoft Internet Information Services (IIS) and ASP.NET just as easily as you can with an XML Web service. The only required change is a little bit of configuration file tweaking.

First, consider the long list of prerequisites and limitations:

As with XML Web services, you must create a virtual directory for your remote component.
You must use the HTTP channel. However, you're free to use the Binary Formatter for smaller message sizes and more efficient communication (which isn't an option with XML Web services).
You must use a SingleCall object. Client-activated and singleton objects are not supported by the ASP.NET infrastructure because the ASP.NET infrastructure periodically recycles processes.
You can't specify a specific port number for listening. IIS listens on all the HTTP ports you have configured in the IIS manager. Typically, this will be port 80.
The object URI must end with .rem or .soap. This curious requirement isn't found in any other hosting environment.
You can't directly debug the remote object in the Visual Studio .NET IDE. However, you can manually attach a debugger to the aspnet_wp.exe worker process. You use the same process we followed in Chapter 7 to attach a debugger to a Windows service.

Configuring a remote object to run under ASP.NET is an easy process. All you do is copy your remote object assembly to the \Bin subdirectory of a virtual directory on the server. Alternatively, you can place it in the Web server's GAC. Then you create a configuration file for the Web application. This file must be named web.config, which is the only file ASP.NET recognizes. Listing 11-15 shows an example that uses the Binary Formatter.

Listing 11-15 Configuring a remote object for ASP.NET

 <configuration>    <system.runtime.remoting>       <application>          <service>             <wellknown mode="SingleCall"               type="RemoteObjects.RemoteObject, RemoteObjects"                objectUri="RemoteObject.rem" />          </service>          <channels>             <channel ref="http">                <serverProviders>                   <formatter ref="binary"/>                </serverProviders>             </channel>          </channels>       </application>    </system.runtime.remoting> </configuration>

The configuration file is almost identical to the ones we created earlier. The only difference is that you can't specify the application name in the service attribute. Instead, the virtual directory name automatically becomes the application name. If the web.config file shown above is hosted in the virtual directory http://localhost/ASPHost, for example, the full URI is as follows:

 http://localhost/ASPHost/RemoteObject.rem

One advantage to this approach is that the remote object also gains the ability to use IIS authentication features (such as SSL) and the built-in ASP.NET objects. Add these features at your peril when you add ASP.NET-specific code, you give up the flexibility for other types of component hosts.

Keep in mind that hosting an object in ASP.NET doesn't make it an XML Web service. The same distinction still applies: If you need support for flexible discovery and description or cross-platform use, an XML Web service is best. If you can assume that all clients are written using languages supported by .NET, you can use .NET Remoting.