Beginning Active Server Pages (ASP)
Hypertext Markup Language (HTML) and the World Wide Web have evolved into a medium of information sharing that rivals television and radio. It did not, however, begin that way. Originally, HTML was intended as a mechanism for physicists to share the papers they’d written electronically over the inter-university network that the academic world inherited from the government. In the beginning, HTML was a simple language that described the parts of a document normally found in an academic paper. It focused on the structure of the document – not its presentation – as text was the only thing being encoded.
The release of the first graphical browser by Netscape in the early 1990s changed everything. The first versions of Netscape included a means for Web Developers to include images in their documents. Developers quickly took advantage of the new capabilities inherent in the graphical browser and made the leap to broadening the scope of the web. All of a sudden, web pages could be designed much as printed pages –albeit with some serious limitations.
Not to be outdone, Microsoft introduced its own graphical browser, Internet Explorer, and launched what was known as the browser war. The browser war pitted Netscape against Microsoft in the struggle to increase the number of users of their own software. During the browser war, each company implemented their own extensions to HTML to entice developers to target a particular browser. It was hoped that if developers created pages for a specific browser then users would want to get the browser necessary to actually view the page.
This strategy worked well for Netscape through the mid 1990s. Microsoft altered the playing field, however, when it began shipping their browser with the Windows operating system. Given that most casual users run Windows and given that the browser came as part of the package, users no longer needed to download (and pay for) Netscape’s browser. The result, of course, is that today’s browser landscape is dominated by Microsoft Internet Explorer (IE).
Users clearly benefited from the browser war. They were continually presented with better and faster software that enabled them to take advantage of all the Web had to offer. Developers benefited as well –the browser had become ubiquitous. The downside to the browser war, from a developer's perspective, was that developers had no guarantee which browser the user had nor which version of the browser was running. This lack of control made writing programs that executed on the client in browsers far more difficult than it needed to be.
Programming the server was the logical choice for eliminating browser disparities. Developers could exercise much more control over the server and its execution environment. Programming the server has evolved as well over the past decade from separate, standalone programs to embedding instructions in web pages for the server to process dynamically. Active Server Pages is a technology that evolved out of the need for developers to gain control. It is a plug-in technology that allows developers to intercept requests to a Web server and process them before a response is sent back by the server.
We use the term “navigate” all the time whenever we discuss how the web works. We say things like “Go to this site” in our casual conversations about surfing the web. Netscape is partially responsible for this metaphor – it named its original browser Netscape Navigator. The problem is that navigation implies some sort of movement and, although the appearance of movement may be felt, there is, in fact, no movement made by the browser.
At its heart, the Web is a request/response mechanism. Users send out
requests to resources stored on servers, servers process those requests and
respond back to the requesting agent. Of course that’s a gross
oversimplification but you get the idea. Underlying the request/response
mechanism is a protocol called Hypertext Transfer Protocol (HTTP)
HTTP is a complex topic worthy of an entire book on its own so I won’t go over the details. HTTP, however, does have an impact on Web Development: HTTP is a “stateless” protocol. What that means is that after a user makes a request via HTTP to a server, the server processes the request and then immediately forgets about the request. This anonymity is what makes writing Web Applications so difficult. Without some sort of help on the server, you can’t even keep track of data in between requests.
Let’s see if we can break the request/response cycle of the Web into its constituent parts:
1. The author of the page writes instructions for how the page displays its data and stores it in a publicly accessible Server as a file
2. The User requests the file through the browser via HTTP
3. The Server locates the file
4. The Server processes the file’s instructions to create HTML
5. The Server returns an HTML stream to the browser
6. The browser processes the HTML and displays the file
It may have surprised you to see that the request for the resource is not the first item in the cycle. It makes perfect sense though when you consider that there’s got to be something to request before the request is made! In fact, step 1 represents what Web Developers actually do – they write code. When the code is written (and thoroughly tested) it is stored in a publicly accessible place so that requests can be made for the file.
Steps 2 through 6 mirror the request/response mechanism. Each of the steps has its own potential for failure ranging from the server being down in step 2 to unforeseen complications with the code due to an erroneous (and untested) configuration of the browser in step 6. The fact of the matter is that, other than writing the best code possible, Web Developers simply can’t plan for all of the potential failures of the Web.
Client-side script is executed in step 6 in the above model. You’ve probably experienced some of the negative aspects of doing client-side Web programming. We’ve already discussed the fact that multiple browsers exist and that each of them interprets script a little differently. We’ve also discussed the fact that the HTTP protocol is stateless so any code executed on the browser can only affect the page on which it is written. Did you know that users can simply turn off the browser’s ability to execute script on a page? It’s true, and the World Wide Web Consortium (W3C) currently reports that upwards of 10% of all surfers do not have scripting enabled in their browsers. To get current Browser Statistics, surf over to the W3C’s stats page: http://www.w3schools.com/browsers/browsers_stats.asp.
Programming on the server occurs in step 4 above. By executing code on the server, Web Developers gain far greater control over the final response sent back to the browser. In the case of Active Server Pages, here’s how it works:
When a request is made for an Active Server Page, the server passes the request off to the Active Server Pages engine. On Windows machines the ASP engine is a DLL file that is plugged in to the server. In fact the DLL is automatically installed when you install Internet Information Server (IIS) or Personal Web Server (PWS) so you don’t have to worry about actually plugging it in. The ASP engine then processes the instructions on the page and returns an HTML stream back to the server for forwarding back to the browser.
From the user’s perspective, the request for an Active Server Page is identical to that of any other Web resource. The key to the request, however, is that the file requested must end with the .asp extension. You must keep this in mind when writing your own Active Server pages. If you fail to include the extension, the server won’t be notified to pass off the request to the ASP engine. The reponse returned is exactly like any other response – it is pure HTML to be interpreted by the browser.
Active Server pages is a technology intended to allow Web Developers to execute script on a web server. It was invented by Microsoft. Microsoft intended it to become an easy way for Web Developers to gain control of the process by which their pages is executed. Although invented by Microsoft, it is, in fact, an open technology. That is, Active Server Pages can be written in any language for which an ASP engine exists. By default, asp.dll supports JavaScript and VBScript.
VBScript is a language invented by Microsoft to serve the many Visual Basic (VB) developers that exist. It was Microsoft’s intention to make developing Active Server Pages as appealing as possible to the widest audience possible. VBScript consists of a subset of of the Visual Basic language. It’s syntax and structures are close enough to Visual Basic that VB programmers should have few problems when faced with writing ASPs.
So why did Microsoft support JavaScript as well? That one’s easy. Just as there is a large audience of VB developers, so there is a large audience of Web Developers well versed in the syntax and constructs of JavaScript. Microsoft recognized that there was a huge audience of potential ASP Developers who, after discovering that they could use the skills they already possess, would target Microsoft Server technologies. Quite frankly, it was a brilliant move.
For the record, JavaScript was invented by Netscape as the client-side technology to script elements on a web page. It is not a subset of the Java programming language as is often believed. Java is a full-ledged programming language invented by Sun Microsystems and does not need the browser to execute as JavaScript does. The syntax of JavaScript, however, is close to that of Java (but even closer to the C programming language) so Java Developers generally find JavaScript easier to learn.
During the browser war, Microsoft was forced to implement its own version of JavaScript, called JScript, to keep up with the features offered by Netscape. In short, Microsoft recognized that it had a JavaScript implementation readily available and a broad audience of developers who already knew the language. At that point, creating the ability to support JavaScript as well as VBScript was just a matter of effort.
One of the premises of this book is that you have at least some knowledge of JavaScript as a client-side scripting language. I’ll assume that you fall into the latter half of the target audience for Active Server Pages identified by Microsoft. You know how to write JavaScript and you are ready to migrate the processing of your scripts from the client to the server.
Active Server Pages is not the only server-side technology available to Web Developers. Following is a list of some of alternatives to ASP.
CGI programs are the grandfather of server-side technologies. These programs are usually written in Perl or C and they are executed on the server. Technically speaking, CGI is a specification that allows for the passing of data between a web server and a user requesting a resource from the server. There are two problems with CGI programs – one obvious and one not so obvious. The obvious problem is that you might have to learn a new programming language to create them. Compound that with the added complexity of installing the programs and the required run time libraries and you can see that CGI programs have a steep learning curve.
The second, not so obvious problem deals with the way CGI programs are executed on the server. CGI programs are just like programs that exist on the client. If you need to create a written document you might start up your word processor, create the document, save, and print it. When you were finished, you’d close the word processor. Later, if you needed to create another document, you’d need to start the program again and complete the cycle by closing the word processor when you were finished. And that’s the problem with CGI programs. Each time their services are requested, the server must start a new process for the CGI program, process the request, then shut down the program. When the number of users increases, especially if it increases dramatically, I hope you can see that CGI programs don’t scale too well. I suppose you could just throw more and faster hardware at the problem but that sounds like an expensive proposition to me.
Server Side Includes are instructions that are embedded within HTML pages which are evaluated while the HTML page request is processed. They allow you to include dynamic content inside an existing page without having to serve the entire page from a CGI program. On the surface, SSI sounds like a good idea. Digging a little deeper reveals some problems: SSI requires the knowledge of the template-based language necessary to create them as well as the configuring of the server to recognize their presence. Interestingly enough, the best use of SSI is the embedding of static files within other static files. SSI makes it easy to include a footer on every page for example. In order to embed dynamic content, you must first invoke a dynamic resource, such as a CGI program, then embed the stream returned from the process. In short, SSI doesn’t really buy you much in terms of dynamically creating web content.
Java Servlets are a server side technology invented by Sun Microsystems designed to be a replacement for CGI programs. The chief benefits of Servlets are the ability to use Java as the programming language to create servlets and the fact that servlets, once executed, continue to run on the server until explicitly shut down. So, you get to use a full-fledged, object oriented programming language to create servlets and they are scalable as new processes don’t have to be started and stopped for subsequent requests. Sounds great, and it is.
Of course, all of the power of Java Servlets comes with a price. You must have at least a moderate knowledge of Java to create them. In fact, unlike ASP, servlets may only be created with Java – you don’t get a choice. Further, as you may or may not know, Java is an interpreted language. This means that all Java Programs, including servlets, require a run time component – called a virtual machine – in order to execute. In the case of servlets, this means that a servlet container must be installed, configured, and running and that comes with a pretty steep learning curve.
Java Server Pages (JSP) were developed on the tails of the Java Servlet technologies. The engineers at Sun recognized the difficulties in creating servlets as well as the benefits of ASP when they were designed. JSPs are a direct competitor to ASP – don’t let anyone tell you otherwise! In essence, JSPs allow developers to embed Java commands, to be executed by the virtual machine on the server, inside HTML pages. In fact, JSPs, on first request, are actually compiled into Java Sevlets by the servlet container and the resulting servlet is then used to process requests to the JSP. The fact of the matter is that JSPs are Java Servlets in disguise. They are marginally less difficult to write than servlets but they share the problems that servlets possess.
Macromedia’s ColdFusion is yet another server-side technology. ColdFusion is a tag and template based application that requires the ColdFusion Server to execute. When writing ColdFusion pages, you include pre-defined ColdFusionMarkup Language (CFML) tags in your documents. These tags are then interpreted by the ColdFusion Server during the request/response process. Like other server-side technologies, you must first learn the CFML tags and how they work and then make sure the ColdFusion Server is configured correctly before executing CFML scripts.
Before we come up with a definition for a Web Application, let’s first examine the architecture of the Web. In General, applications that cooperate either execute on a client or on a server. The client application makes requests from the server, and the server responds to requests. Early client-server applications were developed to access large databases, and the rules used to manipulate the data were integrated within the user interface of the client application. The server's job was simple: process as many as possible.
This type of client-server application, often called a two-tier applications does many of the things that client-side programs do: They show a user interface, process user input, request services from a data store, and report the status of the request. This sequence can happen as often as necessary. In this scenario, the client is responsible for all of the processing. The server merely provides data access.
The problem with traditional client-server applications is one of scalability. Since the server may be processing requests from multiple clients, as the number of clients increases, so does the load placed on the server. Also, since the rules for manipulating the data are stored in the client-side application, any changes to the rules for manipulation quickly becomes a maintenance nightmare. In short, if one rule changes, ALL of the clients must change. Obviously, something better is called for.
In order to address the two shortcomings of traditional client-server applications mentioned above, today’s Web Applications do things a little differently. First, to address the issue of scalability, the processing of a Web Application is distributed between multiple tiers. Second, to address the maintenance dilemma, the processing rules for a Web Application are separated from the client and the server. The result is a multi-tiered, or n-tier, application.
Multi-tier Web Applications generally present three different categories of programs: the user interface, the business rules, and the data store. The user interface tier in a Web Application is handled by the browser. It allows users to make requests and view the results of those requests. The business rules tier in a Web Application governs the processing and results of user requests. It acts as a broker between the user and the data. The data store tier remains largely unchanged from the traditional client-server model. It handles access to the data. In the case of a multi-tier application, however, those request for access come from the business logic tier rather than the user interface tier.
In a Web Application that utilizes Active Server Pages, the architecture might look something like this: [[from Microsoft ]]
In the above model, note that the only tier that has multiple
components is the middle tier. In fact, the middle tier is really the only
place to add components. Sure, you can write middle tier components that access
multiple data stores or respond to multiple clients as in a chat application.
The difference between the middle tier and the other two is that the user
interface and the data store are atomic – they exist as a single entity.
Given today’s landscape, a Web Application can be defined as an application that makes use of the browser to provide the user interface, a Web Server to process user requests, and, optionally, a server plug-in technology like ASP and/or data store. This still leaves the definition of a Web Application pretty vague. Using the above definition, a collection of static web pages stored on a server connected to the Web and publicly accessible is a Web Application. Great – you’ve already doen those! For our purposes, we’ll be a bit more insistent that the Web Applications we create include ASP as the server-side technology to process user requests.
In order for you to test your Active Server Pages, you’ll need access to a web server that knows how to handle ASPs. As of this writing, you have three options:
Microsoft Internet Information Services (IIS)
IIS comes built in to Windows XP Professional and Windows 2000 Professional.
If you don’t possess either of these you can purchase (?) IIS directly from
Microsoft. Alternatively, you could set up web space with an Internet Service
Provider (ISP) that runs IIS. To test your ASPs you’s have to upload them to
the ISP server rather than test them locally.
Microsoft Personal Web Server (PWS)
Personal Web Server is a scaled-down version of IIS that you can install
locally on any (?) version of Windows. Instructions for downloading and
installing PWS can be found here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/office97/html/settinguppersonalwebserver.asp
Sun ONE Active Server Pages
Sun ONE ASP is an Active Server Pages engine suitable for connecting to any
web server. You can get detailed information about Sun ONE ASP here:
http://wwws.sun.com/software/chilisoft/
Once you have installed ASP capabilities, it should suffice to place your ASP pages in a public directory inside the web server and then access the pages in your browser. For IIS and PWS the root public folder is InetPub/wwwroot. The public directory for Sun ONE ASP varies – consult your web server documentation for details.
It’s important to remember that you must use the HyperText Transport Protocol (HTTP) to view your ASPs. That means you must use a URL to access your files:
http://localhost/myFolder/myFile.asp
Simply opening a file from within the browser or double clicking an ASP in a file explorer such as My Computer WILL NOT WORK.
There are Web Host providers that offer free web hosting packages for hosting ASPs. Do a search on the Internet for “free ASP hosting” to get a list of such providers. I (and my previous students) have used Brinkster.com (www.brinkster.com) in the past. Their general account is free, doesn’t pop up any ads, and allows for 25MB of space. It has proven more than sufficient. If you have chosen a provider other than Brinkster, please make sure that it supports ASP. If it doesn't, sign up with a provider that does support ASP, and send me the link. It is your responsibility to make sure that I can view your work online. If your provider doesn't support ASP, then there's no way I can do that!