What you need: ASP+ PDC Preview

Problems with ASP Today
Before I get into the new features I want to discuss a few of the shortcomings that you and I face daily with the existing implementation of ASP. If you have ever developed Web sites where you mix designers and developers together, you have faced the first limitation. ASP intertwines the code you write with the design of the page. Typically a designer will mock up the page and hand it off to a developer. The developer will implement the desired functionality and deploy the page. Then the designer will get back into the page to make some final design tweaks and totally break your ASP code as they move the HTML in the page around. This is one of the main problems that VB6 tried to solve with Web Classes. However, Web Classes had some serious limitations and never really caught on.

ASP's second limitation is that it only supports script languages. This leads many developers, after benchmarking their code, to move sections of the code into COM objects to get compiled and early bound support. Some developers start down this path in the first place, only to run into ASP's third limitation: deploying COM objects in an ASP 3.0 environment is brutal. ASP keeps the DLL loaded in memory, typically forcing you to do a "NET STOP IISADMIN /y," shut down all MTS packages, and hope you can replace the DLL. Sometimes it still requires a reboot of the server and another stop of IISADMIN before you can replace the DLL. Multiply that process by the number of servers in a Web farm and you can understand the reluctance of many developers to rely too heavily on COM objects.

Finally, ASP's fourth limitation was supposed to be one of its coolest features: session state. Programming in a stateless environment is tough; session state alleviates some of those problems by allowing you to maintain state information across requests, making programming easier. As Web traffic increased, however, and developers were forced to migrate their applications to Web farms, it soon became apparent that session state was a problem. It meant that a user had an implied affinity to the server that held their session state. This made it very difficult to accomplish true load balancing in a Web farm.

The Promise of ASP+
Now that I've discussed the ugly secrets harbored by every ASP developer, what has Microsoft done about it? ASP+ addresses all of the issues raised above and more. Unlike the minor changes from ASP 2.0 to 3.0, ASP+ represents a radical departure from the established platform. Unfortunately, this change doesn't come without a cost. Some of your code will break. Once you understand the reasons behind this—as well as look at what you get in return—I think you will agree that it's a necessary change. You'll soon want to dive into the new features. In a future article, I will address issues tied to migrating your existing code base to the new platform, as well as show you tips that you can use while writing code today to make sure that it migrates with as little trouble as possible. Some of the new features include compiled language support, an object model for the page, Server Controls, Web Services, xcopy deployment, new configuration features, new session state options, new caching, new authentication/authorization options, a new architecture, and improved availability. Let's drill into each of these areas a bit more in detail.

ASP+ Platform
The first thing to notice is that ASP+ pages have a variety of new extensions. A basic ASP+ page uses .aspx as the filename extension. A Web Service uses .asmx and a new construct called a "pagelet" uses .aspc. These new filename extensions are there for a reason. ASP+ runs side by side with the existing ASP infrastructure. They don't share session state, application state, or anything else, so they will peacefully coexist on the same server. These new filename extensions are therefore required so that IIS can call the appropriate ISAPI filter to handle processing.

	Figure 1 The ASP+ Platform Architecture.

Figure 1 shows the new ASP+ architecture. One of the things you may note is the distinction between managed and native code. Managed code is the term Microsoft uses for code that sits on top of the new .NET runtime. This code takes full advantage of the new .NET framework including garbage collection, simplified deployment, etc. One interesting thing to note here is that except for some host-specific code, almost all of the new ASP+ is written using the .NET runtime in a new language called C#.

The second thing you may notice in Figure 1 is that ASP+ supports multiple hosts. The first beta will only support IIS5 on Windows 2000. However, upon release it is expected to run on IIS4 on Windows NT 4.0 as well as in IE 5.5 using a new offline feature called My Web. Finally, you will notice the pluggable module and handler architecture. Using this architecture, it is quite easy for you, as the developer, to do most of the things that ASP+ does internally without having to go through the pain of starting from scratch writing your own ISAPI extension. (I plan to cover HTTP handlers and modules in detail in a future article.)

ASP+ Compiled Language Support
One of the biggest changes for ASP+ is that it now supports strongly typed compiled languages. VBScript is no longer needed to execute pages. Instead, you can use the full implementation of Visual Basic. In addition, Microsoft's new language, C#, combines the ease of use of VB with the flexibility of C++. Plus, over 20 other vendors have created language implementations for ASP+ and the .NET runtime, including Perl, Pyton, APL, Eiffel, and even Cobol!

What this means is that all ASP+ code is now compiled. There is no longer any interpreted execution, so you don't have to undergo the pain of compiling projects manually just to deploy a couple of simple ASP+ pages. Microsoft has done work with the loader in the .NET platform to force it to compile ASP+ pages dynamically on the fly. This allows you to maintain simple ASP-style authoring and deployment while taking advantage of fully compiled code.

The move to strongly typed languages also means that those days are gone when every variable was a variant! You can now declare strongly typed variables and objects and early bind to those objects. Calling objects with multiple interfaces is now possible from an ASP+ page.

Initial conservative indications show that these changes, along with other feature enhancements in ASP+, may yield a raw 250% performance increase!

Next: ASP+ Page Framework