Guidelines:
Active Server Page (ASP) Design
This material is provided courtesy of Applied Information
Sciences, Inc.
Topics
References and Resources 
Summary
These guidelines present basic concepts for using Active Server
Page (ASP) technology in the logical design of Windows DNA-based applications.
The purpose of these guidelines is to describe some of the logical design and
modeling considerations that software architects and designers should factor into the
Analysis and Design discipline activities when using ASPs. These guidelines also
describe some common design mechanisms that the designer should consider
applying in the design process of the ASPs.
These guidelines are not intended to provide a complete
treatment of all topics related to developing applications using ASPs. There are
many sources available on the Internet and in books that present detailed
information regarding the use of ASP technology. The References and Resources
section of these guidelines provides links to Microsoft Corporation Web sites
that contain additional information on the use of ASP technology.
The IIS component of the Microsoft Windows® 2000 operating
system provides Web server support for Windows DNA-based applications. IIS was
formerly a separate server product, Microsoft Internet Information Server®, for
the Microsoft Windows® NT operating system.
For Web-hosted Windows DNA-based applications, IIS provides a
scripting environment and technology support for developing server side
components that support the delivery of dynamic Web page content to the user.
These server side scripts are called Active Server Pages (ASPs).
ASPs are interpreted modules written typically in either Visual
Basic Scripting Language (VBScript) and/or in the JavaScript language (JScript).
ASPs can contain embedded Hyper-Text Markup Language (HTML) statements and can
invoke components and applications created using Component Object Model+ (COM+)
technology. ASP scripts may be grouped together in order to create an ASP
application, and multiple ASP applications can be managed by IIS. ASP scripts
may also invoke ActiveX Data Object (ADO) methods for accessing information in a
relational database management system (RDBMS) such as Microsoft SQL Server®.
In the standard three-layer architecture model for Windows
DNA-based applications, IIS and ASP technology provides support services for
building components in the presentation layer. In the context of these
guidelines, ASP “applications” will be considered as a part of the
presentation layer contained in an n-layer Windows DNA-based application. The
first figure below depicts the general areas in which IIS and ASP technology
apply in a sample Windows DNA-based application logical architecture pattern.
IIS/ASP Technology in Sample Windows DNA-based
Application Logical Architecture
The second figure below depicts a sample interaction between IIS
and ASP pages and COM+ components. In this example, the user requests Web
content by specifying a URL in their browser application (step 1). IIS receives
the Web page request and invokes the appropriate ASP page to service the request
(step 2). The ASP page may, in turn, invoke methods in one or more COM+
components to complete the required processing to service the request (step 3).
The COM+ components can, in turn, access data stores managed by a RDBMS such as
Microsoft SQL Server. Once the ASP page script receives the data from the COM+
component, it builds a client HTML page that is sent back to the user to view
with the browser application (steps 4, 5, and 6).
General IIS/ASP Concepts
The design process for defining the ASP pages in a Windows
DNA-based application may start in the Requirements
discipline as part of the Activity: Model the
User Interface. During this activity, the user interface designer may define
an initial set of ASP pages that build the client pages as part of storyboarding
the user interface design. Also, during the Activity:
Prototype the User Interface, the user interface designer may develop a
small subset of ASP pages to demonstrate the general appearance and operation of
the application to the users.
In general, most of the design effort for defining the ASP pages
and their interactions with the COM+ components that will comprise the Windows
DNA-based application is performed during the Activity:
Use Case Analysis, Activity: Use Case
Design, Activity: Class Design in the
Analysis and Design discipline.
As part of the use case analysis and design process, the
designer will define the dynamic behavior of the ASP pages and the COM+
component classes for each use case using interaction diagrams (sequence
diagrams and collaboration diagrams).
As described in the Guidelines: Building
Web Applications with UML, the server side ASP pages may be modeled as control classes
that manage the user interaction with the application. Refer to Guidelines:
Analysis Class for more information about using control classes. See the Tool
Mentor: Managing Sequence Diagrams Using Rational Rose and Tool
Mentor: Managing Collaboration Diagrams Using Rational Rose for more
information on creating these types of diagrams in Rational Rose.
As an alternative to the standard analysis class stereotypes,
the designer may use the Unified Modeling Language (UML) Web Application
Extensions (WAE) class stereotypes to model the ASP pages. The types of class
stereotypes that may be used to model ASP pages are the «Web
Server Page» class stereotype for server side
scripts or the «Web Client Page»
stereotype for client side scripts. Refer to the Rational Rose help topic “Rose
Web Modeler” for more detailed information about the WAE class stereotypes.
Examples of the some of the WAE class stereotypes are shown in the figure above
illustrating general IIS/ASP concepts.
As part of the Workflow
Detail: Design Components, the designer defines the static relationships
between ASP pages and COM+ components using class diagrams.
The UML WAE defines a set of stereotyped associations for
modeling the relationships between the design elements in Web applications. Two
of these relationship types that are useful for modeling ASP application designs
are: «build»
and «redirect».
The «build»
relationship depicts the action of a server-side ASP script building a client
Web page for display. The «redirect»
relationship can be used to show how user requests may be redirected between ASP
pages. Another useful relationship is the «includes»
dependency relationship. This relationship is used to model the use of include
files by a particular ASP page.
Rational Rose uses the WAE stereotypes when reverse engineering
ASP pages from an existing application. The Rational Rose help topic “Rose Web
Modeler” contains a complete description of the Web-specific stereotypes for
the relationships and a complete description on the ASP page reverse-engineering
capabilities of Rose.
The determination of how to apply IIS/ASP technology in the
development of a Windows DNA-based application is part of the design and
implementation mechanism decisions that the software architect role performs in the
Analysis and Design discipline. The initial analysis is made during the Workflow
Detail: Perform Architectural Synthesis during Inception.
The architectural decisions are refined in the Workflow
Detail: Define Candidate Architecture and Workflow
Detail: Refine the Architecture during Elaboration.
The software architect should develop any project level specific design
and coding guidelines for using ASPs as part of the Environment Workflow
Detail: Prepare Guidelines for an Iteration during either the last Inception
phase iteration or the first Elaboration phase iteration.
In making the decision on how to apply ASP technology, the
software architect should assess the application requirements for the following:
-
Client Browser Support
-
Performance
-
Scalability
-
Maintainability
The following sections of these guidelines focus on addressing
the items listed above from the perspective of the logical architecture view.
Refer to the Guidelines: Technical Infrastructure
Architecture for more information about performance and scalability design
considerations (including using Network Load Balancing (NLB), for ASP-based
applications from the deployment architecture view perspective).
A key architectural consideration in the design of the Windows
DNA-based application that uses ASP technology is whether or not the application
is required to support multiple browsers. If the application must support
multiple browser types, then the software architect must determine the common HTML
features that are supported by all browsers and design the ASP pages to render
client pages in a form that is supported by all browser types.
Components
A common approach to managing application performance
considerations using ASPs is to minimize the programming logic in an ASP and
have the ASP call methods provided by compiled COM+ components to perform any
detailed application processing and/or complex data retrieval functions. The ASP
page in this situation simply provides data format services for displaying the
results of the processing by the COM+ components. Partitioning an application
between the data presentation using the ASP script and the business logic using
COM+ components is a recommended design practice for using ASP technology in
building Windows DNA-based applications for the Web.
ISAPI DLLs
If there are specific areas of the application presentation
layer that involve CPU intensive operations, the software architect should consider using
an Internet Services Application Programming Interface (ISAPI) dynamic link
library (DLL) component, instead of an ASP page. ISAPI DLLs are compiled units
with their own runtime library that can be activated directly by IIS. ISAPI DLLs
are potentially able to provide better performance for CPU intensive operations.
The software architect must also factor scalability in the application
requirements. The ASP programming model includes support for defining several
built-in objects that can be associated with an ASP. These objects include the
following:
-
Session – manages state information about a specific user
session for the ASP application.
-
Server – provides access to server resources, including
COM+ components.
-
Application – manages information that must to be made
available to multiple users of the ASP application.
-
Request – provides access to information contained in page
requests.
-
Response – manages information sent in response to a page
request.
-
ObjectContext – provides support for using ASPs in
transactions.
-
ASPError – provides the ability to trap errors in the ASP
script processing.
One of the important architectural decisions related to
scalability that the software architect must make is how to store information about user
sessions. There are several strategies that can be applied depending upon the
scalability requirements of the application, including the use of the Session
object and/or cookies. Both of these approaches have limitations in terms of
scalability, especially the use of the Session object, since Session objects are
linked to the physical server on which they are created.
A recommended approach is to build in application logic for the
ASP application that uses a persistent data store, managed by a scalable
commercial database management system (DBMS) (such as Microsoft SQL Server) to
store and to manage information about user sessions.
Windows DNA-based applications can contain numerous ASP page
files. For ease of application maintenance and deployment, the software architect should
decide upon a strategy for managing these ASP pages. The ASP pages for a Windows
DNA-based application are typically stored on the same server machine as an IIS
directory structure. This structure should be well organized generally having
directories for images and include files under the root directory of the IIS Web
server. This allows for access to these objects easily through virtual path
links. A good directory structure will also simplify configuration management and
deployment of a Web site. The figure below shows a sample directory structure for
storing ASP pages.
Sample ASP Directory Structure
In the example in the figure above, the Content directory
contains all of the ASP pages of the application except the default or root
page. Subdirectories of this directory can be defined as needed to further
organize and manage the ASP pages.
The Graphics directory contains all of the graphical images used
in the display of client side pages.
The Include directory contains all of the ASP Include files,
which are, in turn, grouped into server side include files and client side
include files.
The following are just some of the common design mechanisms that
are recommended for using Active Server Pages to build Windows DNA-based
applications.
-
Component Scope
-
Include Files
-
Client/Server Traffic
-
Memory Management
-
Variable Declaration
-
Resource Management
Scope management refers to managing the lifecycle of variables
(objects) created by ASP page scripts and applications. There are several
different levels of scope that variables can be assigned in the ASP environment:
-
Procedure – variables declared and used within a
procedure, defined as part of an ASP page.
-
Page – variables with page scope that may exist only for
the time that the page is active.
-
Session – variables stored in the built-in ASP Session
object. Variables with session scope are global variables that are
accessible across the ASP pages used during a specific user session.
-
Application – variables stored in the built-in ASP
Application object. Variables with application scope may exist for the
entire lifetime that the ASP application is active, and are accessible
across user sessions.
A commonly recommended design practice is that COM+ components
in ASP applications should be accessed using page scope. This approach means
that when an ASP page accesses objects of a COM+ component, those objects should
be created, used and released within the execution scope of the ASP page. This
approach avoids many concurrency issues.
The ASP programming model provides support for using include
files in a page. This design mechanism allows the designer to partition out
functionality that is common to more than one ASP page into an include file.
During the processing of an ASP page script, the include files are treated as if
they are part of the script and interpreted in-line with the script.
To minimize the overall application processing load, it is
recommended that the designer consider defining the include files to contain the
minimum functionality essential to the operation of the scripts.
The ASP built-in objects provide services for managing flow
control between ASP pages. Whenever possible, the designer should use the
Transfer method on the built-in Server object to handle cases when the ASP page
needs to redirect the user request to another ASP page. The alternative
mechanism of using the Redirect method of the built-in Request object is not
recommended, since it requires that information be exchanged between the client
browser application and the Web server.
When building dynamic Web pages, strings are frequently used to
contain large sections of the Web page as they are being built. This approach
can be memory intensive if the Web pages are very large. It is recommended to
use fixed length strings when possible to minimize the dynamic reallocation of
memory for the strings.
Explicitly declaring variables is a recommended approach for
both increased performance and improved quality of ASP scripts. Using declared
variables provides better performance than using undeclared variables, since
declared variables require less processing by the ASP scripting engine.
It is a recommended practice to use COM+ components called from
ASP pages to access shared resources, such as databases.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Artifacts >
Analysis & Design Artifact Set >
Software Architecture Document >
Guidelines >
