Things are complicated enough when Web pages are simply displaying static information. Add the need to generate content dynamically, and things get really complicated. Dynamic content is normally generated from one or more data sources located on the server. In most situations, the application developer will not want clients to connect directly to these data sources. One reason, of course, is that per-client connections don't scale very well. But more important are the security issues involved with giving some random Internet user access to company databases. Therefore, Internet applications are usually structured so that some server-side application is used to generate HTML pages containing the data to be displayed. Whenever the Web client needs more data, a new request is sent to the Web server, and a new page is generated by the server-side application.
With the advent of Java applets, ActiveX Controls, and DHTML, it is now possible to write client-side Web applications that maintain some connection to a server. Instead of forcing a new page to be generated whenever more data is needed, data is transferred directly between client-side components or script code and a server-side application. Internal data sources do not need to be exposed to the outside world because they are accessed only by the server-side applications.
Traditionally, server-side Internet applications have been developed using a gateway interface, such as the Common Gateway Interface (CGI) or the Internet Server Application Programming Interface (ISAPI). One disadvantage of gateway interfaces is that content is essentially embedded within a compiled program. If content authors want to change the format of a page, they need to wade through program source code and locate the statements that generate HTML output. Once changes are made, the program probably needs to be rebuilt. This can make it difficult to maintain server-side applications. CGI programs have an additional disadvantage in that each time a CGI program is called, it runs as a separate process, so these applications might not scale well.
ASP addresses all of these issues. An ASP page mixes server-side scripts and client-side content, as shown in the following code:
<%@ LANGUAGE = VBScript %> <% Option Explicit %> <HTML> <HEAD><TITLE>Sample ASP</TITLE></HEAD> <BODY bgcolor="white" topmargin="10" leftmargin="10">
<!-- Display Header --> <font size="4" face="Arial, Helvetica"> <b>Sample ASP</b></font><br> <hr size="1" color="#000000"> This script uses a component that comes with IIS to generate a random number. The random number determines what text is displayed on the rest of the page. <br> <% Dim example, aNumber ' Instantiate component on the server. Set example = Server.CreateObject("MSWC.Tools") aNumber = example.Random() %> <P>The random number is <%=aNumber%>.</P> <% ' Use a conditional statement to decide what message to return. If (aNumber mod 2 = 0) Then Response.Write("<P>This is an even number.</P>") Else Response.Write("<P>This is an odd number.</P>") End If %> </BODY> </HTML>
When an ASP page is accessed, the server-side script is executed on the server. As the script is executed, an HTTP response is generated and sent back to the client. Normally, this response is an HTML page. The server-side script can control which HTML statements coded in the ASP file are included in the response, or it can generate HTML statements on the fly. This technique provides a straightforward way to deal with differing browser capabilities. The ASP developer can determine what features the requesting client supports and adjust the HTTP response accordingly.
Server-side scripts can use Automation objects. ASP provides some standard Automation components to help with common Web tasks, such as determining browser characteristics, parsing parameters and cookies included in a page request, or sharing information between pages in the application. This capability makes it relatively easy to write pages to process HTML forms. In addition, complex operations can be coded one time in custom components and then reused in many server-side applications.
In general, server-side ASP code should defer complex algorithms to COM components. Script code is interpreted at run time. The less interpretation needed, the better your performance. In addition, script code can use only the IDispatch interface to access Automation-aware components. Code that simply calls a lot of other COM objects to perform work should be placed in a COM component. Components are compiled and can usually take advantage of vtable-binding, providing better overall performance. These components can be reused in other applications as well.
One of the major advantages of ASP is the familiarity of its programming model. Content authors work in a medium familiar to them—HTML—augmented with scripting. Scripts can be written in any language, as long as a scripting engine is available. IIS includes scripting engines for VBScript and Microsoft JScript. Developers who implement complex business logic can encapsulate the logic within COM components written using their favorite development tool, instead of having to learn HTML and scripting.
Because ASP pages are interpreted, it's easy to update an ASP application as necessary—particularly when cosmetic changes to the HTML statements are needed. And since ASP runs on the Web server and controls exactly what gets sent back to the Web client, your intellectual property—data or code—is protected. Client machines will not be able to tell how the HTML was generated or where the data is coming from.