HTTP Remoting

I l @ ve RuBoard

The TCP channel provides basic reliable end-to-end communication and transmission of messages based on low-level sockets. It is ideally suited for use on a LAN. The HTTP channel, on the other hand, being based on the HTTP protocol, is ideal for transmitting data over longer distances. You can use many of the same techniques that you've already seen in this chapter, but the HTTP channel provides some additional functionality. Specifically, you can use IIS as a host server application and publish remote methods on the Web. The HTTP channel also provides better cross-platform interoperability.

Remoting Server Hosting

HTTP remoting uses the System.Runtime.Remoting.Channels.Http.HttpChannel class to transport messages between a client and a server. In a manner similar to TCP remoting, HTTP remoting has specialized HttpClientChannel and Http ­ServerChannel classes designed for the client or server. The HttpChannel provides the functionality required by an HTTP client and an HTTP server and is the variant that is used most often.

Using the HTTP channel in its simplest form is almost identical to using the TCP channel. (But be sure you don't use the same port as an existing TCP server.) The CakeServer.jsl sample file in the ServerActivatedHTTPCakeSizeServer project shows the basic CakeServer, which implements server-activated objects over the HTTP channel. Notice that this class now creates an HttpChannel and that the published URI has the suffix .soap , which is the convention when you use SOAP.

The changes necessary for the client are similar. Notice also that the URI requested by the Activator.GetObject method specifies the HTTP protocol. For completeness, the HTTP version of the basic CakeClient is available in CakeClient.jsl in the ServerActivatedHTTPCakeClient project.

As with TCP remoting, you can also use a configuration file to specify channel (use the ref="http" template in the <channel> element) and type information. Remote objects that are accessed using the HTTP channel and a custom host server application can be client-activated or server-activated.

By default, the HttpChannel inserts a System.Runtime.Serialization.Formatters.Soap.SoapFormatter object into the message sink chain to serialize requests as XML and add the necessary SOAP headers. (SOAP is covered in detail in Part V of this book.) This has some advantages over the BinaryFormatter used by the TCP channel. In particular, because the format emitted by the SoapFormatter follows the SOAP standard for remote procedure calls, a remoting client application based on the HTTP channel can interact with almost any server that accepts SOAP method calls. The server does not have to be written using Visual Studio .NET or even be running on a Microsoft platform. Most Web services are SOAP-based, and with a little care an HTTP remoting client can interoperate with a Web service. Microsoft supplies the SOAPSUDS tool (in the \Program Files\Microsoft Visual Studio .NET\FrameworkSDK\bin folder) for generating runtime assemblies that client applications can use to access Web services.

You should bear in mind, however, that the SoapFormatter has some disadvantages compared to the BinaryFormatter . Firstly, the size of a SOAP message is often bigger than its binary cousin. You'll especially notice this if a remote method takes object parameters, which brings us to the second drawback.

In Chapter 10, we looked at how binary and XML serialization work. Binary serialization writes the entire contents of a serializable object ”private as well as public data ”to a serialization stream. XML serialization, on the other hand, outputs only publicly accessible data (public data members and properties), and totally private data is not emitted. The same rule applies when you use the SoapFormatter class (which uses the XML serializer to do some of its dirty work). Hence, objects marshaled by value as parameters across an HTTP channel will have only their publicly accessible data transmitted. This will affect how you design and implement remote services over HTTP. This restriction does not apply to objects marshaled by reference because their data is not actually transmitted. (Only an ObjRef that is used to build a proxy at the server end is transmitted.)

Note

There is a small difference between XML serialization as described in Chapter 10 and the SoapFormatter . Classes serialized using an XmlSerializer object do not have to be tagged as serializable, but classes serialized as parameters using the SoapFormatter must be (if they are not marshal-by-reference types).

It is possible to combine the HttpChannel with binary serialization by changing the formatter used by the channel. This will still use HTTP as the transmission protocol, but the data sent will be binary rather than XML. The simplest way to do this is to use a configuration file and specify a <formatter> element as part of the channel. On the client side, this should be contained in a <clientProviders> element:

 <application> <channels> <channelref="http"> <clientProviders> <formatterref="binary"/> </clientProviders> </channel> </channels> </application> 

In a server configuration file, you should use a <serverProviders> element. The syntax is the same as the <clientProviders> element. Be sure that if you change the formatter at one end, you change it at the other end as well. (A binary formatter at the client does not mix well with a SOAP formatter at the server.)

Tip

You can also change the formatter when you use the TcpChannel . Use <formatter ref="soap"/> to switch to the SOAP formatter. The values binary and soap are actually templates defined in the machine.config file. (See the sidebar titled "Configuration File Schema Templates" earlier in this chapter.)

Hosting with IIS

If you're using the HTTP channel, an alternative to building a custom server application is to host remote objects using IIS. This enables you to make use of the security features that IIS exposes and reduces the amount of security checking you have to do in your own code (as described in the next section). Remote objects hosted by IIS must be server-activated. For the sake of response time, you should also minimize the use of events calling back to the client as well as the number of parameters that are marshaled by reference.

If you want to host remote objects in IIS, you must follow some fairly strict rules. First, you must create a virtual directory alias that refers to a physical folder. This folder holds the assembly that defines the remote object. You can do this from the Internet Information Services tree in the Computer Management console, under Administrative Tools in Control Panel. Use the default access permissions. You then create a folder called bin under the physical folder and place the assembly in that folder. Any other private assemblies used by your remote objects should also be placed in the bin folder. Finally, you must create a configuration file called Web.config and place it in the folder that corresponds to the virtual directory. (This will be the folder that holds the bin folder.) For example, to host the CakeUtils.dll assembly under IIS, you can use the following procedure. (You do not have to call the folder CakeUtils or the IIS virtual directory CakeServer, but these are the names we'll use in this section.)

1. Create a folder called C:\CakeUtils.

2. Create an IIS virtual directory called CakeServer that maps to this physical folder.

3. Create a folder called C:\CakeUtils\bin.

4. Copy CakeUtils.dll into C:\CakeUtils\bin.

5. Create the Web.config file in C:\CakeUtils.

The Web.config file is an ordinary server configuration file. The following example publishes the CakeInfo class of the CakeUtils assembly using the URI CakeInfo.soap , over an ordinary HTTP channel. No port is necessary because IIS will listen for incoming requests on port 80 by default, although you can specify a different port if you want to keep remote object traffic separate from ordinary Web traffic. (This will start a new thread in IIS that listens to the specified port, so if you use a different port for each application you might create many additional listener threads in IIS ”be aware of scalability issues.)

 <?xmlversion="1.0"?> <configuration> <system.runtime.remoting> <application> <service> <wellknowntype="CakeUtils.CakeInfo,CakeUtils" objectUri="CakeInfo.soap" mode="SingleCall"/> </service> <channels> <channelref="http" /> </channels> </application> </system.runtime.remoting> </configuration> 

A client can use a remote object hosted by IIS just as it can use any other server-activated object. The main requirements are that the client must register an HTTP channel and the URL specified must refer to the URI of the remote object in conjunction with the name and virtual directory of the remote server and the port it is listening on (port 80 by default).

The following configuration file is for the CakeClient class you saw earlier in this chapter. (You should replace localhost in the <wellknown> element with the name of the server that's running IIS.) The useDefaultCredentials attribute of the channel is a custom property that applies only to HTTP channels. It causes the credentials of the process that's executing the client application to be transmitted to IIS as part of the request. IIS can be configured to allow or deny access to the remote object based on this information. You might be denied access when you attempt to activate the remote object if you omit this attribute, depending on how IIS security is configured on your system.

 <?xmlversion="1.0"?> <configuration> <system.runtime.remoting> <application> <channels> <channelref="http" useDefaultCredentials="true"/> </channels> <client> <wellknowntype="CakeUtils.CakeInfo,CakeUtils" url="http://localhost:80/CakeServer/CakeInfo.soap"/> </client> </application> </system.runtime.remoting> </configuration> 

HTTP Remoting Security

The TCP channel provides almost no support for encrypting messages and authenticating method requests. On the other hand, the HTTP channel, when used with IIS to host remote objects, supports encryption using SSL as well as integrated Windows authentication and even Kerberos. You can implement these options using little or no code ”it's simply a matter of configuring IIS appropriately and ensuring that client applications transmit their credentials if required, as shown in the previous section.

The Web.config file in an IIS virtual directory can specify security information. The optional <system.web> child element, under <configuration> , can contain <authentication> and <authorization> elements. The <authentication> element indicates the authentication mode, which dictates how users should be authenticated (using forms-based security, Microsoft Passport, Integrated Windows security or no security). The <authorization> element determines which users and roles should be permitted or denied access.

The following example file is an extended version of the server Web.config file shown earlier. It configures IIS to use Integrated Windows security to authenticate users to permit access only to JSharp and ALongshaw from the WONDERLAND domain, and to deny access to everyone else (the unauthorized users will receive a 401 "Unauthorized" message from the server, which will be trapped by the remoting infrastructure as an exception).

 <?xmlversion="1.0"?> <configuration> <system.runtime.remoting> <application> <service> <wellknowntype="CakeUtils.CakeInfo,CakeUtils" objectUri="CakeInfo.soap" mode="SingleCall"/> </service> <channels> <channelref="http"/> </channels> </application> </system.runtime.remoting> <system.web> <authenticationmode="Windows"/> <authorization> <allowusers="WONDERLAND\JSharp,WONDERLAND\ALongshaw"/> <denyusers="*" /> </authorization> </system.web> </configuration> 

Many more configuration options are available with IIS, some of which will be covered in Part V of this book.

I l @ ve RuBoard