Hosting Remoting objects in IIS

I've long been an advocate of hosting Remoting objects in an application's own Windows Service.  However, I always knew that there was this "other way" of doing it in IIS (some would argue that I have this the wrong way round!).  A new MSDN article ".NET Remoting Architectural Assessment" has plenty to say on Remoting best practice. 

Of particular interest to those of you who tend to build there own services for hosting Remoting objects is this:

Hosting inside a system service

This possibility is more interesting, as the functionality is not so much provided by the Remoting infrastructure as by the notion of a system service itself. System services can be configured to start when the machine is started and to stay around until you tell them to go away, which is ideal for remote hosting. Note that IIS applications can also be configured to behave similarly by setting "High Isolation Mode" for the Virtual Application. This has a number of implications, however, which are not discussed in this article. Customers have asked some hard questions about this mechanism, which calls its usefulness into question. First, some advantages: We have already mentioned the benefits of a service itself. Furthermore, we do have full control over the activation of the host process—for example, we might elect to use dynamic publication or client activation. We don't need IIS, since we can get our user profile loaded and we get good performance with binary-encoded messages over TCP.

The disadvantages weigh pretty heavily, however. To start with, you need to build your own authentication and authorization mechanisms, should you require them. The article .NET Remoting Security Solution, Part 1: Microsoft.Samples.Security.SSPI Assembly provides a very full and detailed description of a security solution for .NET Remoting that " ... implements a managed wrapper around SSPI, providing the core functionality needed to authenticate a client and server as well as sign and encrypt messages sent between the two." This is definitely a great asset and provides a "façade" for adding this functionality in a useful way. The problem is that it is not a supported product but an "informal" attempt to supply missing functionality. Also, it's a little intimidating for a developer, as the solution relies on the extensible nature of formatters and channels. All this needs to be hidden and the functionality surfaced by just adding an entry to the Remoting configuration, which depicts, for example, the use of Windows NT Challenge/Response (NTLM). It is likely, however, that such security mechanisms will be incorporated into a future version of .NET Remoting.

A System Service would also need to be scalable and reentrant to be useful as a Remoting server, as these features will be required in a multitiered distributed application. Without IIS, for example, the hosting service would have to manage its own auditing and authorization, both of which come standard with IIS.

For these reasons the System Service hosting mechanism is of limited use, perhaps in a constrained environment where messages are queued to a single exchange, security is not an issue, or IPSec is available over TCP.