Presentation Layer: Three different approaches. Database Access Layer: same as above.

• Overview of web application development

• Overview of ASP

• HTTP request/response processing

• State management of the script logic

• Microsoft Scripting Runtime library

• Remote Scripting

• Presentation Layer: Three different approaches

– ASP mostly

– COM-based DLL using ASP as the glue – WebClass

• Business Logic Layer:

– COM-based DLL using ASP as the glue

– Run the DLL within MTS (Microsoft Transaction Server)

• Accept input that the user has entered in

HTML forms.

• Interpret its users' requests and run

whatever commands are appropriate.

• Generate HTML that contains page content

and layout details and send it back to the

• Puts all the presentation-tier code along with the layout details inside ASP.

• Upsides:

– Productivity is high due to WYSIWYG nature of the page editor (InterDev)

– It’s fast and easy to change pages on a production site.

• Downside:

– Slow (interpretative mode)

• Uses ASP script as little as possible.

• Puts all presentation-tier code inside one or more COM-based DLLs.

• Generates all page content and layout details dynamically.

– Data-driven approach: DLLs using content and layout as input parameters.

• Upside: it avoids all downsides of ASP approach • Downside:

• Uses the same approach as COM fanatic, but uses the

WebClass framework as a starting point instead of starting from scratch.

• WebClasses represent a framework for data-driven approach built on top of ASP.

• Downsides:

– Your preferred approach may differ from that of the WebClass architects

– You must understand well the WebClass architecture. – WebClasses does not understand MTS.

• Start with ASP to find out how others write

codes to perform the presentation tasks.

• Graduating from ASP coding, pick up skill

in data-driven approach by using

WebClasses.

• As an experienced, career Web

programmer, build your own framework

using your own COM-based DLLs.

• What is an ASP Page:

– A file with .asp suffix

– A combination of HTML statements and script logic for execution on the server side

• Script logic

– written as Jscript or Vbscript

– Access to Microsoft Scripting Runtime library

– Enclosed in <% …%> for processing by ASP.DLL which results in HTML primitives.

• Programming Constructs:

– Intrinsic, pre-built and custom-built objects – Global.asa

• HTTP request/response processing

• State management of the script logic

• Transaction management

Client Request Object Response Object ObjectContext Object Server Object Sesson Object Application Object Server

• Each Web Application has at most one file, Global.asa to store executable objects.

• The file is executed by IIS (not asp.dll) • Contents of Global.asa:

– Scripts to process Application and Session events – <OBJECT> declaration

• <object runat=server scope=session ID=abc>…..</object>

• User Beware!

• Much of the info is communicated to ASP by IIS through ServerVariables: e.g.

– Request.ServerVariables(“http_user_agent”) – Request.ServerVariable(“last_modified”)

• Input values entered by the user are stored in Form and QueryString collections

• File posted by the user is read using BinaryRead

• Caching directives: – Response.CacheControl – Response.Expire, Response.ExpireAbsolute • Contents: – Response.ContentType, Response.Charset • Return-code – Response.Status • Re-direction: – Response.redirect www.cs.sfu.ca • Output – Response.write(firstname)

• By default, ASP in IIS 4.0 does not buffer output – info is sent as it is made available

– Consequence: all header info (e.g. cookie &

redirection) must first be generated before the body.

• As an option, response.buffer may be set to

true, which means more control how response is sent:

– clear (empty the content without sending)

– flush _{(send the current content in the buffer)} – end (stop response processing)

• Send partial info early

• Avoid errors while using cookies and

redirection.

• Trap errors which may cause modification

of output

• Send dynamic contents by flushing the

buffer regularly.

• HTTP is a stateless protocol:

– each browser request to IIS is independent, and – IIS retains no memory of browser’s past request

• Client-server applications are inherently stateful, i.e. client and server enter into a dialogue containing

multiple requests/responses.

– e.g. On-line shopping

• Page-scope: information on the HTML page e.g. variable values.

• Session-scope: information needed to conduct a dialogue – e.g. adding items to the shopping cart

• Application-scope: information that is global in nature and needs to be shared between all active sessions.

– e.g. Number of sales today

– Concurrency consideration (Application.Lock/.Unlock)

• External-scope: information managed by another

• Pass-by-content: Move the state info back and forth on each request/response, using hidden

HTML fields, HTTP cookies, or the (WebClass) URLData property.

• Pass-by-reference:

– Use objects on the server to store state information between client requests.

• objects: WebClass, ASP Session/Application Objects or VB COM objects (?!)

– Database may be used to store state information between requests.

<FORM NAME=frmEmployee METHOD=POST ACTION=process.asp>

[...]

<INPUT TYPE="Hidden" NAME="ExtraInfo"> </FORM>

<SCRIPT Language="VBScript"> Function frmEmployee_onsubmit

document.frmEmployee.ExtraInfo = time End Function

• Originated by Netscape, the concept of cookie was formalized by the IETF standard RCF2109 (Feb. 1997)

• HTTP cookies provide the server with a

mechanism to store and retrieve state information on the client application's system, e.g.

– client preference – registration

• A cookie has six attributes: – Name – Value – Domain – Path – Expiry Time – Security

• Creation by server: command on the set-cookie header: <name>=<value>, …

• The client may reject the set-cookie header

• The client will send the stored cookie via a cookie header if the the incoming set-cookie header has the same cookie ID, and valid expiry time.

• The stored cookie with the client will be updated if set-cookie header is updated by the server.

• Start of a session

• End of a session

• Use of cookie

• Usual ways to begin a session:

– New user requests a URL that identifies an .asp file, and the Global.asa _{file for that}

application includes a Session_OnStart

procedure

– Server receives a request that does not contain a valid SessionID cookie

• An event will be triggered, invoking the

• Session timeout (20 minutes by default)

– Option: <% Session.Timeout = 5 %>

• Session abandoned by client or server

– <% Session.Abandon %>

• All variables remains until session_end _event

• SessionID is generated when the user request an .asp file for the first time.

• SessionID is sent to the user in the set-cookie header, with no expiry date.

• SessionID is sent to the server in the cookie

header in subsequent requests in the same session. • SessionID is used as a key to state information

stored in the contents variables of sessionID or in the database.

ASP Session-Aware Load-Balancing

• In load-balancing (e.g. round-robin), the

server may rotate within a session

• One solution:

– When the session is first created, the designated server runs a re-direct request to the specific

server, e.g.

• ADO • Ad Rotator • Browser Capabilities • Content Linking • Content Rotator • Page Counter • Permission Checker • Counters • MyInfo • Tools • FileExists • ProcessForm • Random

• It contains the following types of scripting

objects:

– Directory objects

• system-managed hashed tables

– FileSystemObject objects

• file management functions

– TextStream objects