Some of you might have read the ASP Review UPDATE newsletter (which ceased publishing in 2001), which discussed a combination of inhouse server-based computing and outsourced application hosting and delivery. If you read that newsletter, then you’re familiar with the ways you can deploy a hosted application so that it’s managed from a central location but accessible from a client computer. Two of the most popular approaches are running applications from a terminal session hosted by a server using Windows 2000 Server Terminal Services with or without Citrix MetaFrame supplementing it, and hosting applications in a Web browser. Keeping applications on a central server is great for application installation and maintenance, but not so great when the network fails, because without the network the client can’t get to the hosting server—and thus to the application. Hosting applications in a Web browser limits you to the controls that the browser supports—which, as you might have seen for yourself, are pretty limited.
What about an option that, to present applications, uses the same UI as the one you’d see if you were running applications locally, and that launches applications from a central server yet caches the application code locally so that applications will still run even if the network’s down? The .NET platform was designed to provide such capability. I’ve alluded to this capability before, but now let's look in more detail about how it actually works.
Three elements are necessary to this functionality. First, on the client is a stub application that is small enough for users to conveniently download from a Web site or to receive through email. Second, and also on the client, is a storage space called an "application download cache." Third, on the server is the code required to run any particular application, and a copy of Microsoft IIS.
The application stub is just smart enough to point to a server. When a user starts up the application stub (which uses the same UI as a "normal" application), the stub requests the loading of classes from assemblies (the executable code that .NET applications use) that do not yet exist on the client, and points to the server hosting those classes. The server downloads this code—which can be pretty small—to the client’s application download cache, and the code runs from there.
The upshot here is fourfold. First, getting the stub piece to the client machine is really easy—no complicated installation and configuration is necessary, as it sometimes can be with graphical clients. (Configuring graphical clients is simpler in the Win32 environment than in UNIX, although even the very simple RDP client requires some setup.) Second, when you update the code on the Web server hosting the assemblies, then the client code is also updated as long as the client machine has a network connection to the server. Third, because the application launches from the download cache, the application will run even if the network is down when the client starts the stub, as long as the stub previously downloaded the assemblies. Fourth, because the application runs locally, it isn’t impacted by a shortage of network bandwidth and doesn't compete with other applications running on a shared server.
The catch to this functionality, of course, is that you sacrifice interoperability for the advantages of running an application locally. But when you consider that many clients that use any kind of server-based application are running Win32 OSs, you see that as more clients run a .NET-compatible OS, interoperability won’t always be necessary. The .NET platform isn’t going to instantly replace today’s server-based computing any more than PC-based applications replaced the mainframe. If nothing else, using .NET to serve centrally managed applications locally requires both rewriting applications and a compatible client OS. But .NET offers one more mechanism for supporting centrally maintained applications.