Active Server Pages Architecture

Li Yi
South Bank University

Contents
1. Introduction ...................................................................................................................................... 2
1.1 Host-based databases ............................................................................................................... 2
1.2 Client/server databases ............................................................................................................ 2
1.3 Web databases........................................................................................................................... 3
2. Active Server Pages ........................................................................................................................ 5
2.1 ASP Components ...................................................................................................................... 6
2.2 ADO and Database................................................................................................................... 7
2.3 The steps of executing a query ............................................................................................. 11
3 ASP Attributes ................................................................................................................................ 12
References:.......................................................................................................................................... 13

1. Introduction
The development of databases always comes with the newer and better
hardware and the demand for applications that match the new hardware. In the
past 20 years, we have seen the development of databases not only in DBMS,
but also in the evolution of database connectivity, which is from centralised
computing to Client/Server computing. These client/server structure databases
have a great impact to the use of databases.

1.1 Host-based databases

The host-based databases are performed on one computer system with
attached unintelligent, "dumb," terminals. A limited number of users can only
connect to the databases running on the monolithic mainframe through the
dumb monitors. There is no friendly interface at all for the users. When the
users want to do queries, they must know schema of the databases clearly.
What they have typed in will send to the mainframe without any processing.
The application of databases will do everything. As a result, the users of the
databases will be limited because each user occupies resource of the
mainframe independently, even worse the mainframe will be easily overloaded
because it will do everything from any trivial things to complicated businesses
queries. The performance of the databases will be very poor when the users
climbs up to a certain number.

1.2 Client/server databases

When the number of users accessing a database grows too high or when too
many features are integrated into the database, it is increasingly possible that
the centralising database model fails. And with the proliferation of low-cost
hardware, especially the advent of cheap PCs, client/server databases have
gained popularity in the recent years.

Client/server has revolutionised the way of designing and building databases

applications. It splits the processing load between clients and servers to get the
best of both worlds. A database application is two-tier or three-tier based on
the separation of the application logic from the Graphic User Interface (GUI)
and the database.

In a two-tier client/server database, the application logic is buried either inside

GUI on the client (fat client) or within the database on the server (fat server)
or both. A user runs a GUI on the client, and then sends queries over a
network to a database server. The database server processes the request and
returns a result. Simplicity is a good feature of two-tier databases, the two-tier
databases are easier to develop than the three-tier or N-tier for small databases.
But the databases do not scale well. Many SQL statements are sent over the
network and selected data must be downloaded for analysis on the client.
When new and more stringent requirements must be introduced into databases,
two-tier databases become exponentially harder to develop and normally
failed. Three-tier was designed to meet this new challenge.

In a three-tier or N-tier (more than three tiers) client/server database, the

application logic (or process) lives in the middle-tier. Instead of interacting
with the database server directly, the client calls business logic on the server.
The business logic then accesses the database on the client's behalf. Only
service requests and responses are sent between the client and server, so it
performs much well than two-tier. It also provides better security by not
exposing the database schema to the client and by enabling more fine-grained
authorisation on the server.

1.3 Web databases

Web technology is a very special case in client/server computing world.
Almost every database vendor is rushing to support this technology at the
moment. There are two reasons to explain this, one is that enterprise web
servers need powerful databases to support, and the other reason is that

databases need to be extended their services to the biggest wide range group,
web group.

The typical web databases are three-tier or N-tier. The users run standard
browsers on the client side and the requests are transferred over the Internet to
HTTP servers. The HTTP servers then interact with database servers and
change the result into HTML files to send back to the browsers. Because
HTTP is a stateless connection protocol, web databases need find a way to
"remember" each user's operations. They also should have capability of
handling with enormous users concurrently. If the web databases support Java,
or ODBC/JDBC, they are platform independent because they can connect with
different web servers or the Internet directly. It does not need to care about
server platform, client platform and network protocol.

Performance is a big problem of web databases. Users concern the response

time of the databases and the web masters concern the throughput.
Optimisation is always used at web server. When a web server receives a
service request from a client, it first looks up a result in its cache to see if it is
there already. If it does, the result will send back to the client directly without
connecting to a database server. If it can not find the result in the cache, it will
connect to the database server and fetch the result. The result will normally
stored in the server cache and send back to the client. When there are more
than one user's request coming into the web server, a queue will be built on
web server and optimisation will make them use the server resource
reasonably.

Web databases can be two-tie, three-tie or N-tie. The two-tie web databases
are the simplest to develop and may gain some good performance from this
simple structure. However, they are lack of flexibility to deal with other web
things and normally they are vendor dependence. The three-tie or N-tie web
databases are powerful and flexible. But the middle tie may add the overhead
because the databases are not connected with the Internet directly.

2. Active Server Pages

Active Server Pages (ASP) is an Internet Server Application Programming
Interface (ISAPI) extension which builds on top of the ISAPI infrastructure to
provide a server-side application framework, making it even easier to build
dynamic Web applications. ISAPI is an alternative approach to Common
Gateway Interface (CGI) and is adopted by Internet Information Server (IIS)
because each CGI invocation of process is very resource intensive and a busy
Web server could have severe performance problems. If web technologies are
used to deal with database via HTTP, then the data and its state need to be
kept track of, as it flies around the world. ASP is an excellent tool to help
developers do that on the Windows NT world.

ASP is supplied with ActiveX Data Objects (ADO) that provides a high
performance interface to databases that are Open Database Connectivity
(ODBC) or OLE DB compliant. Fig. 1 shows the general structure of how
ASP to connect the databases.
Server: Windows NT
Internet Information Server
CGI
Client
Scripts

Internet

WWW

ASP
ADO

SQL
Server
Or
Oracle

ODBC

Browser

ActiveX

MTS

HTML
files

Fig. 1 The connectivity of ASP with the database on the web

*ADO is a high-level interface, which is a wrapper around OLE DB. OLE DB is a COMbased, low-level programming interface that provides access to data from all parts of an
organisation (relational, access, file).
* If there is a native OLE DB provider for the database, it does not have to go through ODBC
- the extra layer of processing.

2.1 ASP Components

Active Server Pages allows the developer to include VBScript or JScript code
in the HTML pages, which is executed on the server. ASP has its own object
model, which is exposed for the above scripting languages. Its built-in objects
give the way to integrate code with the requests sent from the browser, and the
web pages, or responses, sent back from the server.

There are six built-in objects provided by the Active Server Pages core engine.
These objects are Application, Session, Response, Request and ObjectContext.
They only relate to each other logically, not in a hierarchy object models. The
diagram below shows how these objects fit together.

Server
Object

Request

Client

Response

Server
Application

ObjectContext

Session

Fig. 2 The built-in objects of ASP

Application and Session objects
The Application object represents an entire Active Server Pages application.
This object is used to share information among all users of a given application.
A Session object is maintained for each user who requests a page. Variables
stored in the Session object are not discarded when the user jumps between

pages in the application; instead, these variables persist for the entire time the
user is accessing pages in the application.

Request and Responses objects

To be able to manage the way HTTP communications work, Active Server
Pages use a Request object to store the details of the browser, the request itself
and a whole host of other information. A Response object stores all the
information required for the server's response to the client and provides
methods and properties that can be used to create and modify what is returned
back to the client.

ObjectContext objects
The ObjectContext object is used by Microsoft Transaction Server (MTS)
initiated to commit or abort transactions.

These objects cover normal web server functions. But when a client request
needs to query a database, ADO will be needed.
2.2 ADO and Database

To develop a dynamic web site, web pages is needed to link with a database of
some kind. (It is not that kind of static pages translated from databases.) The
traditional way to do that is through Common Gateway Interface (CGI) or
Internet Server Application Programming Interface (ISAPI) directly. An easier
way is provided by ASP, which is supplied with a component called the
Database Access Component. The component is a whole hierarchy of objectscollectively known as the ActiveX Data Objects (ADO), which is the 'missing
link' between web pages and almost any kind of stored data.

ADO is powerful enough to achieve excellent results with a minimum amount

of work. It consists of just four objects and two collections. They are
Connection, Recordset, and Error object; Fields, and Parameters collection.
The relationship between them is as follows:

Connection
Command

Parameters

Parameter

Recordset

Fields

Errors

Error

Fig. 3 ADO objects

The object model is like a hierarchy structure, but not absolutely. One
command can be executed by different ways with different objects. The
following is a briefly introduction all of the objects and collections shown in
the figure.

The Connection Object

The Connection object represents the link to the data source. It can directly
execute statements against the data source, manage transactions.

The Command Object

The Command object is a query that can be issued against the data source. It
provides a means to access and modify data. It can be executed directly
against the data source, or it can be used in conjunction with a Recordset
object to retrieve data.

The Parameters Collection

The Parameters collection is a dependency of the Command object and can be
used in conjunction with a parameterised query (such as a SQL statement) or
stored procedure. Each of the query's (or procedure's) parameters is
represented by a Parameter object.

The Recordset Object

8

The Recordset object is the most intricate of the ADO objects. It supports
features such as data paging, disconnected recordsets, filtering, sorting, and
storing multiple data sets in a single Recordset object.

The Fields Collection

The Fields collection exists within the Recordset object, and represents a list
of fields (the columns of the recordset).

The Errors Object

The Errors collection consists of individual Error objects - an Error object is
created when an error occurs while accessing data.

ADO provides the following main features to run the databases.

Connection
Before we can access any part of a database, we need to establish a connection
to it. A predefined link between the consumer and the data provider can be
built by creating an instance of the Connection object, and placing information
in its properties.
The default ConnectionTimeOut is 15 seconds.

Closing the Connection

The resources that were being used to support the connection on the serverside are released when a connection is closed. But the object can only be
removed from the memory by setting it to Nothing.
.
Connection Pooling
When a connection is closed, it is placed in the connection pool and waits to
be reused by any others. The connection itself is only closed if it is not reused
within a certain period time. Otherwise it is reused exactly the same as the
cached connection. This process saves overhead by reducing the number of
times we need to physically go through the connection process because
opening and closing connections can be resource-hungry for Web server.
Certainly, one can cancel the usage of connection pooling.
9

Cursor types, Cursor locations and Lock types

A cursor is a pointer to a record in a database or recordset. To get good
performance from the concurrent environment, the users need to define these
three parameters carefully. ..

Filtering
The Filter property of the Recordset object can reduce the number of records
that users can see in a recordset based upon their filter criteria. All the
information is still there in the recordset - it is just hidden from view until the
users clear the filter. By applying the filter, the users only get a subset of all
the rows.

Paging
This is a good way to look at data one 'page' at a time. It would not take any
custom programming to implement this.

Indexing
Indexing will reduce processing time when performing searching for a record
and sorting a recordset. But the index itself resides in the client-side cursor
that ADO provides. That means it is not indexing the database itself, it is
indexing the Recordset object.

Execute SQL
It is important to define a right execute method for executing SQL code
against the data provider. For example, if the adExecuteNoRecords is not
defined in the execution of a SQL statement which does not need to return any
record, ADO will generate a recordset of no records, which takes up extra
memory and time and is essentially a waste of resources.

Stored procedures
To use a stored procedure within a database can get much better performance
than to running a dynamic query because the stored procedure is already

10

compiled on the server and a dynamic query must be syntax-checked and

compiled before it is executed.

Transactions
ADO has a number of methods and properties to support transactions.

Disconnected Recordset
ADO gives us disconnected and remote-able recordsets, which in turn allows
for better functionality in the stateless environment of the WWW.

A disconnected recordset is a standard ADO recordset without an associated

connection to a database. If the web server-side code opens a recordset and
disconnects it from the database server from within that server-side script, the
web server is playing the role of 'client' to the database server. The client only
receives web pages that are generated on the web server, not the actual
recordset.

2.3 The steps in executing a query

The following are steps to execute a very basic SQL command.
1. The web server starts an application to provide services for querying the
database. Application object is started. All users can share variables at this
application level.
2. A user uses a browser to visit a web page that contains a SQL query
service. The user then inputs some data by customising the query and
submits it by "Get" or "Post" method to the server through HTTP protocol.
3. The web server then may create a session for the user to remember the
"client" when the user gives a query next time.
4. The query is interpreted and the cache is checked to see if the query can be
completed on site. If yes, the web server produces a dynamic result web
page to send back to the user.
5. If no, the web server connects to the database server. Before doing that, it
checks if the wanted connection is already existed in the Connection Pool.

11

If yes, it will use that to connect to the database server. If no, it will create
a new connection.
6. After setting up the connection, the Command object will tell the database
server what should be done. This command goes through ODBC or OLE
DB and is changed to a language that the database can understand.
7. The Recordset object will get the result and then manipulate it to produce
the web page.
8. When there is no need to interact with the database server, the connection
to the database will be closed and the connection will be thrown in the
connection pool.
9. The resulting web page is sent back to the user, and the data fetched from
the database server will be left in the cache.

3 ASP Attributes
Performance
ASP is a script language, which means the web server needs to read each line
of the ASP file and then run it. Microsoft Transaction Server (MTS) can be
used to improve the performance of ASP. MTS is viewed as an object broker
and uses COM to map client applications to services resident in software
components (objects). It is designed to reduce the time and complexity in the
development of N-tier applications by supplying much of the infrastructure to
provide a robust, scalable, high performance and distributed architecture.

Portability
ASP is originally designed to run on Windows environment. However,
Chili!Soft Inc. (http://www.chilisoft.net/) have implemented an ASP scripting
engine for many non-Microsoft Web Servers and they claim that this is
functionally equivalent to the Microsoft implementation. This means that ASP
does not force vendor lock-in and your Web applications can now be freely
ported to other platforms (like Unix) without code change.

Powerful

12

ASP can not only run some scripts and connect different databases through
ODBC, but also do other things through ActiveX server components.

Scalability
Future versions of MTS will work with the Cluster Server technologies to
provide dynamic load balancing, scalability and high availability.

Learning curve
It is easy to learn because it is just a script language and it uses Visual Basic
syntax.

References:
Scott M.

Lewandowski

(1998)

"Frameworks

for

Component-Based

Client/Server Computing", ACM Computing Surveys, Vol. 30, No. 1, March

1998, pp. 4-27.

13