During the first half of the ’90s, Microsoft almost single-handedly ushered in the graphical user interface on the PC, as Windows became the de facto OS and its GUI became the default interface for new corporate applications.
But two opposing forces, occurring simultaneously, created a “perfect storm” that threatened to wash Microsoft out of its dominant market position. Microsoft itself, oddly enough, created the first force: Despite the flexibility of the Windows environment, it was very difficult to distribute and maintain Windows-developed applications. At the height of the client-server era, companies were spending as much time trying to determine how to get a set of Windows applications to work together on a common corporate desktop as they were developing the applications themselves.
Best online Microsoft MCTS Training, Microsoft MCITP Training at certkingdom.com
Microsoft was then accused by the Department of Justice of trying to dominate the second force: the Internet. The allure of dynamic application loading and no desktop footprint other than the browser gave birth to several server-centric technologies, including Java, the thin client, and terminal services. Companies began to envision a future where all applications were delivered from Web servers with client-side components delivering the rich GUI elements using Sun’s Java or Microsoft’s ActiveX.
In this article, we’ll look at some steps Microsoft has taken with .NET to bring Web-based rich application distribution a little closer to reality.
The fork in the road
Instead of a mass exodus to the server, corporate customers now faced a difficult dilemma: to develop applications with wide reach using HTML and other server-centric technologies or to continue to use Windows technologies to create rich client experiences and live with the associated deployment hassles.
Although Sun and Oracle have made a valiant effort to convert customers to their server-centric world, users are reluctant to give up legacy Microsoft client-centric technologies. During the Internet boom, it appeared that server-centric technologies would win outside the firewall, and client-centric technologies would continue to dominate inside. But Microsoft hopes to maneuver customers back to a common development platform with its network-centric .NET platform.
How .NET solves the deployment problem
Most of the press around Microsoft’s .NET initiative focuses on new languages (C#) and a new set of conspiracy theories suggesting that somehow Microsoft will take over the Internet using W3C standards. What’s missing in these analyses is that Microsoft has made significant strides toward uniting the Web and Windows development models into a single, unified development platform. One of the most significant problems Microsoft has solved is that of rapidly deploying rich applications.
Applications developed to execute on the .NET platform can be deployed three different ways. First, companies can continue to use standard setup programs to install applications on local machines. But .NET applications don’t suffer from the same DLL contention problems that plagued earlier Windows applications. A .NET application deployed with a setup program closely defines the companion assemblies necessary for it to operate in the new Global Assembly Cache (GAC). The GAC allows applications to use different versions of assemblies (the .NET version of the DLL) on the same machine—a feat not possible in the COM programming model.
The second deployment model involves a simple XCOPY of program files into a local or network directory. Programs executing from this directory only use the files copied into the directory or its subdirectories. Although this deployment method creates the potential to have several duplicate copies of the same assemblies spread out over a machine, it does eliminate the common “DLL Hell problem” found in COM applications that compete for a single shared DLL that may not be the correct version for one of the applications.
The third deployment model is not only the most interesting, but it holds the most promise for making rich applications available to Internet users. In this model, a user navigates to an installation directory with the browser. The .NET runtime downloads the forms and the support files required to run the application into the browser cache, and then it executes the program. Subsequent attempts to run the application will load it from the cache and not require additional downloads.
But if the developer updates the application, the client system needs only to download the changed components. This download occurs automatically without requiring users to respond to a series of dialog boxes seen now on Java applet or ActiveX downloads. But this doesn’t mean that there is no security for downloads. In fact, not only is the security model more robust than the current one, but the applications are executed in a “sandbox” that prevents them from using any local resources (like the hard drive) unless permitted by the security settings. By using this deployment scenario, companies can write rich applications, yet still use the standard “reach” platform (the browser) for deployment with a URL.
What’s the catch?
There is a caveat attached to all the benefits. Microsoft first has to overcome two significant roadblocks before Web-based rich application distribution can become a reality.
First, systems running applications developed for .NET need the runtime installed in order to execute the downloaded programs. As of now, Microsoft doesn’t have a strategy for getting the 17-MB .NET runtime installed on client machines. The second problem is endemic to the current state of the Internet. Client machines downloading applications need sufficient bandwidth to allow an acceptable download time the first time a program is executed. Although this won’t be a problem for most corporate desktops inside the firewall, it will limit the technology’s viability in remote offices and Internet-connected clients.
But as these problems fade throughout the next few years, Microsoft’s .NET technology will provide a powerful development platform that unites not only the “rich” and the “reach” programming models, but eliminates the barriers to effectively distributing the applications as well.