• Illustration: Web Server Technologies
• Sidebar: Browser Compatibility Proves Elusive
• Illustration: Web Client APIs

Since the introduction of Internet Explorer in 1995 and Internet Information Services (IIS) the following year, Microsoft's Web application platform has undergone major changes. The result is that developers face a large number of APIs and platforms on both the client and the server. Organizations that want to move existing Web applications forward, as well as those looking to build new applications, must examine the choices carefully.

Common Server Foundation

IIS, Microsoft's Web server, is the common foundation for all of Microsoft’s Web application efforts and provides two basic APIs for developers looking to build dynamic Web applications. (For a graphical overview of Microsoft's server-based Web development technologies and how they build on IIS, see the illustration "Web Server Technologies".)

Common Gateway Interface, or CGI, is an industry-standard API supported by virtually all Web servers on both Windows and Unix (including Linux). CGI enables a Web server to hand off a request to an external application and then pass that application's output back to the browser. This makes the CGI programming model very simple—CGI applications are console applications that receive the details of the request via standard text input and write the resulting page as standard text output. CGI applications can be written in almost any programming language, including C and C++, but are most commonly written in Perl—a language that combines the syntax of C with the text-handling features of a number of popular Unix utilities (sed and awk, most notably).

Although CGI’s widespread adoption makes it an attractive choice for Web applications that must run on a variety of Web servers and OSs, it has several drawbacks. First, Microsoft provides no tools that specifically support building CGI applications. Second, CGI’s reliance on external executables has performance implications on Windows. Unlike the case with Unix-based systems, spawning a new process on Windows is a relatively time-consuming operation. Although largely invisible in end-user scenarios, this overhead, when multiplied by the thousands or even millions of requests likely to be received by a high volume Web server, can become a significant limitation.

Internet Server API, or ISAPI,, is Microsoft’s attempt to eliminate the performance penalty associated with CGI on Windows. ISAPI essentially replaces CGI executables with DLLs and is supported by IIS and by the Windows version of the popular open-source Apache Web server. The similarity between CGI and ISAPI makes migrating CGI applications to ISAPI a fairly simple process. Migration is further helped by the availability of a free ISAPI implementation of Perl from ActiveState.

Moving from external programs to DLLs, however, has several implications. Most important, sharing the same process and memory-address space among IIS and the DLLs makes the Web server vulnerable to crashes or memory leaks from poorly written applications. When an ISAPI application crashes, it takes the Web server and any other running Web applications with it, and memory leaks in an ISAPI DLL can degrade the performance of a Web server over time, forcing an eventual reboot. With IIS 6.0, Microsoft introduced a new process-isolation model that greatly improves reliability, but IIS 6.0 is available only on Windows Server 2003.

CGI and ISAPI are core features of IIS and follow the same support schedule. IIS 5.0 is due to exit Mainstream support on June 30, 2005, and IIS 6.0 on June 30, 2008. Because both CGI and ISAPI are heavily used, they are unlikely to be removed from future versions of IIS. So, as long as organizations stay reasonably current in the version of IIS they use, support problems should be minimal.

Seeking "VB for the Web"

Although CGI and ISAPI provide the means for developers to build Web applications on IIS, in order to make Web application development accessible to the broadest possible number of developers, Microsoft and other Web server vendors realized they sorely needed an easy-to-use development environment: a "Visual Basic for the Web" that would provide developers working on Web server applications with a combination of an API framework and a drag-and-drop development tool.

In addition, although some developers are content to leave all processing to the server and limit themselves to basic HTML supported by all browsers, others want to build more sophisticated user interfaces. These developers needed a way to deal with the proliferation of client-side Web APIs and inconsistent support for standards across browsers, including different versions of Internet Explorer (IE), without having to hand-tune their sites for each browser. (For more details on browser APIs, see the sidebar "Browser Compatibility Proves Elusive".)

ASP

Introduced as part of IIS 3.0 in 1997, Active Server Pages (ASP), which built on ISAPI, was Microsoft’s first attempt to apply the VB programming model to Web applications. Like VB, which enabled developers to build client applications by using a relatively simple programming language to integrate prewritten Component Object Model (COM) components from Microsoft and third parties, ASP allowed server developers to use scripting languages on the server to integrate a set of prewritten COM components, such as the Session object, which allows developers to store information about a user’s preferences and have the information persist as the user navigates from page to page within a site. The key difference is that while VB code executed on the client, ASP code executed entirely on the server and produced HTML that was passed to the client and rendered in the browser.

Along with ASP, Microsoft introduced Visual InterDev, a development tool for ASP applications. With Visual InterDev, developers could visually design an HTML page and then insert script code that would run on the server. For example, a designer could lay out a region to be used for a rotating advertisement and then insert code that selects, at run time, an ad from a predefined set.

However, ASP did little to help developers write applications that work correctly across multiple browsers. As a result, developers tended to write "browser sniffing" code that determined the specific version of the browser being used and altered the output appropriately.

Although it proved successful among Web-savvy developers, several factors limited ASP's and Visual InterDev’s appeal. First, building reliable COM objects for use on a server turned out to be much more difficult than many people expected, and ASP’s use of ISAPI put it at risk for crashes or memory leaks in server-side COM objects.

Second, although VBScript and JScript are undeniably simpler than more full-featured languages, such as VB and C#, they also lack some important features that help developers organize their code and prevent common errors. Once the amount of code in a script exceeds a certain size (typically several pages of code), the difficulty in maintaining scripting code can exceed the benefits of a simpler language.

Finally, although Visual InterDev appealed to developers already proficient with HTML and scripting, the lack of higher-level components, such as data grids, made Visual InterDev difficult for the broader VB developer community to use.

Although recent versions of IIS support ASP and future versions are likely to continue to do so, ASP has been replaced by ASP.NET as Microsoft’s recommended Web application platform. In addition, Visual InterDev has been discontinued and its features incorporated into other Visual Studio tools. Extended support for Visual InterDev 6.0, the last version available, ended Sept. 30, 2004.

ASP.NET 1.0

ASP.NET is a complete rewrite of ASP and was a key component of the .NET Framework when it launched in 2002. The most significant architectural change in ASP.NET is the adoption of the .NET Framework and Common Language Runtime (CLR), which provide several key benefits, including the following:

• Support for languages such as VB.NET and C# in addition to VBScript and JScript
• Dramatically improved developer tools through Visual Studio .NET, including improved debugging.
• Increased reliability of the CLR compared with COM.

In addition, with ASP.NET, Microsoft finally took steps to accommodate all the different browsers and platforms available to users and the features supported by each combination. Server components in ASP.NET (which replace ASP’s primitive set of COM objects) are capable of rendering themselves in a number of ways, depending upon the capabilities of the browser being used. A calendar control, for example, might display itself as Dynamic HTML and script code when accessed from IE 5.0, allowing the user to scroll among months without making a round-trip request to the server, and as static HTML when accessed from IE 3.0 or another downlevel browser. ASP.NET automatically provided the "browser sniffing" code that Web developers previously had to write themselves.

However, the addition of languages such as VB and C# to ASP.NET led Microsoft to discontinue Visual InterDev as a separate product. Although Web development features are now built into each of the Microsoft developer languages, making Web development available to a broader set of developers, the discontinuation of Visual InterDev also means that Web-savvy developers must now contend with the complexity of Visual Studio. For example, Visual InterDev allowed developers to simply point the tool at a Web server to view and edit the files that make up an application. Visual Studio, on the other hand, requires a complex set of project and solution files for even the simplest Web applications, and while VB and C# developers may be comfortable with them, Web developers are not.

Although not compatible with ASP, ASP.NET applications can coexist with ASP applications on the same Web server. The added capabilities of ASP.NET, however, seem to outweigh the lack of backward compatibility, as evidenced by the success Microsoft has had in getting Web developers to migrate. In fact, ASP.NET has been by far the most successful element of Microsoft’s overall .NET strategy and is also the foundation for many of the company’s other server products, such as SharePoint Portal Server.

ASP.NET 1.0 is supported on IIS running on Windows 2000 Server Service Pack 2 (or later), Windows XP Professional, Windows XP 64-Bit Edition, and Windows 2003 Server, and requires the Microsoft Data Access Components (MDAC) 2.7 or later. The exact version of IIS will vary with the OS—5.0 or 5.1 on Windows 2000 and XP, and 6.0 on Windows Server 2003.

ASP.NET 1.0 and Visual Studio .NET are in Mainstream support through June 30, 2007, making them safe choices for new Web development. (ASP.NET 1.1, a minor update, was released along with Visual Studio .NET 2003 and won’t exit Mainstream support until Sept. 30, 2008.)

ASP.NET 2.0

ASP.NET 2.0, which will ship with Visual Studio 2005 in the first half of 2005, is a major upgrade to ASP.NET and appears poised to build on the success of its predecessor. In addition to addressing known weaknesses in ASP.NET and Visual Studio, such as eliminating the need for project and solution files for Web development, ASP.NET 2.0 also introduces a number of important building block services that dramatically reduce the amount of custom code developers must write.

Some of the new capabilities of ASP.NET 2.0 include the following:

• Membership and personalization, including a built-in "log-on" control and the ability to customize an application based on end-user preferences
• Master pages, which allow Web developers to ensure that all pages on a site have a consistent look, and to change that look by simply editing a master page
• Adaptive rendering, which extends ASP.NET’s support for downlevel browsers to include mobile devices, such as Pocket PCs or browser-equipped cell phones that use languages other than HTML (such as the Wireless Application Protocol).

The new features of ASP.NET 2.0 make it an easy upgrade for existing ASP.NET developers. ASP.NET 2.0 is backward-compatible with ASP.NET 1.0 and 1.1, so existing applications can be brought into ASP.NET 2.0 and begin to take advantage of its features. In addition, ASP.NET 2.0 can run side-by-side with previous versions, so a single Web server can host old and new applications at the same time. The only caveat is that developers who have already implemented some of ASP.NET’s new features (such as personalization) with custom ASP.NET 1.0 or 1.1 code will need to change their code to take advantage of the built-in versions.

ASP.NET 2.0 is supported on Windows 2000, Windows 2003 Server, and Windows XP. With previous versions of ASP.NET, Microsoft has made available a "Go Live" license that allows developers to deploy applications on a beta release of ASP.NET, provided they agree to upgrade to the final version within 15 days of its release. At the time of this report, the beta of ASP.NET 2.0 does not include a Go Live license but one is expected to be offered with a later beta.

In addition to the full Visual Studio product, a new set of tools targeted at beginners and hobbyists is now in beta, including Visual Web Developer Express. This makes ASP.NET programming more suitable for Web-savvy programmers not familiar or comfortable with Visual Studio.

ATL Server Misses .NET Strategy

Although the eventual success of ASP.NET may seem a foregone conclusion, at the time of its introduction, skeptics (both inside and outside Microsoft) wondered about the viability of building high-performance server applications with managed code. To hedge its bets in case ASP.NET performance turned out to be worse than expected, Microsoft introduced with Visual C++ .NET a native-code framework for building Web services and applications. This framework, ATL Server, offers a programming model built around C++ templates. (The "ATL" in ATL Server derives from the ActiveX Template Library, a C++ template library for building COM objects and ActiveX controls. But ATL itself does not require COM or ActiveX and is built on top of ISAPI.) Several factors make ATL Server a nonstrategic library and a poor choice for new projects. First, because it is built around a complex language feature of an already complex language, ATL Server is not for the casual developer and is only appropriate for experienced C+ developers who, for whatever reason, are unable to use ASP.NET in their application.

Second, Microsoft is building many of its own server products on top of ASP.NET and is strongly motivated to fix any ASP.NET problems that might arise in the future, whereas there are no groups inside of Microsoft known to be using ATL Server, making further development unlikely.

Third, the performance questions that skeptics raised about ASP.NET have failed to appear: ASP.NET is used to host many large-scale applications and, in some scenarios, performs better than similar native code, due to its caching capabilities. This means that there is little benefit in ATL Server that offsets the risks associated with its lack of strategic importance.