Life After ASP
Table of Contents
Architectural Comparison
To better understand ColdFusion it may help to discuss its architecture, and to compare it to that of ASP and ASP.NET.
ASP is implemented as an ISAPI extension (or application). ASP is a DLL (named asp.dll and usually found in one of the Windows system directories), and IIS maps ASP files to the asp.dll. In this way, the ASP engine processes all requests for ASP pages. Without this mapping and DLL, the server would return ASP code to the browser, rather than the generated results. ASP pages themselves are scripts, combining server-side instructions (usually VBScript) and client-side instructions (usually HTML and JavaScript). ASP pages are very loosely coupled, pages are essentially connected to each other through URL links or form submissions. ASP pages are stored in a directory on the server, typically under the web root, and are requested like any other URL; but unlike other URLs, ASP pages are first processed by the asp.dll before the results are sent to the client.
There is no special relationship between the IIS (the de facto Microsoft Windows web server) and ASP. ASP is connected to IIS through ISAPI, just as many other server extensions are, including ColdFusion. ColdFusion differs from ASP in that it is not a DLL loaded by IIS, rather, it is a high performance multi-threaded Windows service unto itself. ColdFusion is a much bigger application than ASP simply because it does so much more than ASP does, and so it is implemented as a Windows service. The service is always running and you may start or stop it from the Windows Services Control Panel like any other service to provide optimum performance. Like ASP pages, ColdFusion pages are loosely coupled scripts combining server-side instructions (in CFML) and client-side instructions (again, usually HTML and JavaScript). ColdFusion pages have a CFM extension. IIS uses that extension to route ColdFusion requests to ColdFusion through an ISAPI connector.
In other words, both ColdFusion and ASP relate to IIS in exactly the same way. The development model for both is identical (creating script files combining server-side logic and client-side presentation code). What differs is the file extension and the server-side scripting language used.
Figure 1. ColdFusion and ASP relate to IIS in exactly the same way.
From a coder's perspective, ASP and ColdFusion are not that different. But under the hood they are anything but alike. In fact, architecturally, ColdFusion has a lot more in common with ASP.NET than it does with ASP.
ASP.NET is designed to be used with the Microsoft .NET framework. Unlike ASP code, which an interpreter processes, ASP.NET code is just-in-time compiled into MSIL (Microsoft Intermediate Language) before being executed. The compiled ASP.NET code, usually C# or VB.NET code, is executed within a special environment called the CLR (Common Language Runtime). ASP.NET code uses objects, resources, and APIs exposed by the .NET framework all from within the CLR. The CLR manages execution, memory, threads, and more. ASP.NET is still bound to IIS through ISAPI, but instead of all processing occurring within that single DLL, requests are routed for execution within the CLR. Of course, for the most part, all of this is hidden from ASP.NET developers who write ASPX files and place them on the server to execute.
ColdFusion MX is architecturally similar. Instead of running on the Microsoft proprietary Windows-only .NET platform, it runs on the multi-vendor J2EE platform. ColdFusion is a compiler and CFML code is just-in-time compiled into Java bytecode before execution. The compiled code is executed within a special environment called the JVM, or Java Virtual Machine. ColdFusion code uses objects, resources, and APIs exposed by Java and J2EE all from within the JVM, and it is the JVM which manages execution, memory, threads, and more. Of course, for the most part, all of this is hidden from ColdFusion developers who write CFM files and place them on the server to execute. Read more about the compiler in Performance Under the Covers in ColdFusion MX 6.1 .
Figure 2. ASP.NET and ColdFusion process requests in a similar way.
As you can see, architecturally ASP.NET and ColdFusion MX are not that different. The primary difference (aside from the scripting language used) is that ColdFusion leverages J2EE and ASP.NET leverages .NET. However, ColdFusion Java guts are transparent to ColdFusion developers, they can (and do) leverage Java when they want to and can ignore it the rest of the time. In fact, ColdFusion developers are shielded from the application server internals far more than ASP.NET developers are, allowing them to concentrate on being productive within their own code. After all, whereas ColdFusion provides simple tag abstractions, ASP.NET requires that developers tinker with objects, and APIs at a much lower level (a lower level even than that of ASP).
What all this means is that ASP developers can feel quickly at home in ColdFusion, probably more so than they do in ASP.NET. ColdFusion allows developers to leverage an architecture similar to that of ASP.NET, a coding model similar to what they are used to from ASP, access to the vast world of Java and J2EE, while still retaining access to .NET services and web services. And coding in ColdFusion is far quicker, cleaner, and simpler than it is in ASP.NET (as will be demonstrated shortly).
