10 Jan, 1997

LiveWire and Active Server Pages (ASP)

Through the CGI interface, programmers can develop applications for the Web Server in conventional programming language, using standard program services, without much additional training. However, generating a lot of HTML with standard "print" statements produces a fairly ugly program and bypasses all the new HTML editors designed to make that task simpler.

Having developed the idea of embedding simple script languages into HTML for execution by the Browser, the next obvious step was to develop scripts that the server runs on the pages before shipping out the response. Scripts are interpreted code, so programming errors cannot disrupt the server. The script interpreter can be loaded, initialized, and then each new request can be quickly processed with very little startup cost. The file in which the script logic is embedded provides the bulk of the HTML.

Both Netscape and Microsoft support Server-side scripts.

Netscape builds a JavaScript interpreter to execute scripts into all of its 2.0 Servers. The LiveWire product provides development tools. The author creates a subdirectory of HTML files containing embedded scripts. Collectively, these files are part of a single "application". They are then passed through a compiler that produces a library file from which the Server runs the application.
Microsoft added support for Server-side scripts into its Internet Information Server (IIS) 3.0 package. It calls this facility Active Server Pages (ASP). The programmer creates a subdirectory of HTML files with embedded scripts. Unlike Netscape, there is no compile step. The files are simply given an extension of *.asp instead of *.htm and IIS processes them as it reads them in.

As on the Browser, Microsoft support VBScript as well as JavaScript. Since there is no security problem with Server-side applications, as there is for downloaded Browser files, the OLE modularity is much more valuable. There is a version of Perl that supports the OLE script interface, and other popular programming languages are promised. So a programmer can use Perl as a conventional CGI language (and generate all the HTML with print statements), or he can mostly edit a plain HTML file and just add Perl logic where it is important.

Server-Side Script Syntax

Server-side scripts start with a basic HTML file. It will usually define the basic structure of the response (HEAD, TITLE, and BODY). It will also include the headers, footing material, and links that are not effected by the program logic. Server side scripts are identified in one of four ways:

<SERVER>limit=credit(custno);</SERVER>: Netscape introduced the <SERVER> tag with LiveWire. It is not part of the HTML standard, but since it doesn't actually leave the Server and flow on the network, Netscape is free to make up any syntax they choose.
VALUE=`getprodid(name)`: Netscape allows Server-side JavaScript to be enclosed in "backquote" or "accent" characters. Although it can be used in other contexts, this syntax was required when Server-side JavaScript is used to generate part or of an attribute value inside another HTML tag.
<SCRIPT RUNAT=SERVER LANGUAGE=JSCRIPT>limit=credit(custno);</SCRIPT>: Microsoft supports this syntax, which is more in line with the HTML 3.2 standard. The SCRIPT tag, of course, is also used to identify sections of Browser-side script code. The curious "RUNAT=SERVER" attribute identifies it as a Server-side script. The LANGUAGE attribute allows the script to be in JScript, VBScript, or any other installed language that supports OLE scripting.
<%limit=credit(custno);%>: Microsoft invented this compact notation for Server-side scripts. There is no attribute to specify language, so the script is assumed to be in whatever language was set to be the default. VBScript is the default unless a special statement at the beginning of the file selects another language.

This is clearly a mess, but it becomes even worse if you try to edit this file using any standard HTML editor. Few understand simple scripts, and none understand every combination of Client-side and Server-side scripts in all the possible languages.

Server-Side Object Model

Since the Server-side script is embedded in an HTML page, the client request is directed to a URL that appears at first glance to be an ordinary web page. However, the request can be accompanied by query information, such as that generated by an HTML form.

Both Netscape LiveWire and Microsoft Active Server Pages now process the contents of the HTTP request (the URL, query string, general headers, cookies, and any POST data) and create a set of "Objects" for the Server-Side scripts. These Objects are primarily data structures used to organize information:

The Request Object holds information about this particular HTTP request. Netscape has a relatively simple Request Object that holds the type of Browser, IP address of the client, and the value of each Form variable. Microsoft has a much more elaborate Request Object that includes the same information, and also Cookie data, a large number of probably useless variables about the Web Server, and information from any X.509 Client authetication Certification (if one was presented by the Browser).
The Client Object (Netscape) or the Session Object (Microsoft) provides Server-side scripts with a place to store information between user requests. A script can save any data under any variable name in the Client/Session Object. The Client Browser is sent a Cookie that acts as a key to locate the data when the next request is sent to the same page or another page in the same Server directory.
The Project Object (Netscape) or Application Object (Microsoft) provides the Server-side scripts with a set of common data objects shared by all of the pages and related to all of the Clients of a common application program. For this purpose, an application is the set of pages in a common subdirectory. This object can also be "locked", so sensitive information or special resources will be used by only one request at a time.
A Server Object exists on both systems. It represents features that are global to all applications hosted by the same Server. On the Netscape server, it can be locked and can hold global user data.

The Client/Session Object is the most important feature of this interface. It provides the necessary source of continuity so that a sequence of pages can behave as a reasonable dialog despite the semi-stateless nature of the HTTP protocol. Every other Web based application development system has to invent something to act as the Client Object. The LiveWire/ASP systems manage this problem automatically so the programmer doesn't have to reinvent basic infrastructure.

Script Programming Services

Both the Netscape and Microsoft Servers provide Server-side scripts with the ability to read or write ordinary disk files. Both provide access to databases.

However, the Netscape database support is so poorly documented as to prove almost unusable for complex programming. Is there one database object or many? Can a program call stored procedures? How long is a cursor valid? It comes as an unpleasant surprise, for example, to learn that since most database interface libraries are single threaded on Unix systems, LiveWire uses internal locks to ensure that only one database operation is being executed at a time.

Netscape provides documentation so a programmer can write C functions that can be called by a Server-side JavaScript program. However, this does not provide a rich enough interface to maintain sessions or database cursors. Persistent data should be saved in an Object of some sort.

ActiveX Data Objects (ADO) provides the Microsoft database support. This appears to be adequately documented and powerful enough for most purposes. It is important enough to attract the attention of all vendors.

More importantly, the Active Server Pages support for files and database are simply two examples of a general purpose Server-side extension facility. Microsoft provides full programmer documentation for adding new extensions, and provides examples in of such extensions written in C, Java, and (full) Visual Basic. Not surprisingly, such extensions use the ActiveX/OLE programming techniques on which the entire Microsoft strategy is based.

Continue Back PCLT