Web applications basics

web application

is an application that is accessed by users over a network such as the

Internet or an intranet.[] The term may also mean a computer software
application that is coded in a browser-supported programming language
(such as JavaScript, combined with a browser-rendered markup language
like HTML) and reliant on a common web browser to render the
application executable.

Web applications are popular due to the ubiquity of web browsers, and
the convenience of using a web browser as a client, sometimes called a
thin client. The ability to update and maintain web applications without
distributing and installing software on potentially thousands of client
computers is a key reason for their popularity, as is the inherent support
for cross-platform compatibility.

A web server is a piece of software that enables a website to be viewed

using HTTP. HTTP (HyperText Transfer Protocol) is the key protocol for the
transfer of data on the web. You know when you're using HTTP because
the website URL begins with "http://" (for example,
"http://www.quackit.com").
You might be thinking "I always thought a web server was a special, high-
powered computer". Well, you'd be right too. Some high-powered
computers are referred to as web servers as they have been built with
web hosting in mind. But in most cases, when someone refers to a web
server, they are referring to a piece of software that you install on a
computer.

When a web browser talks to a web server, it uses something called a

universal remote identifier (URI). The URI has multiple components but
starts by telling the server the protocol that it wants to use. The protol
that a web server supports is http . Other protocols that could be
presented by a browser are ldap, ftp, and mailto. Unfortunately a web
server does not know how to handle these protocols and would return an
error.

The Role of IIS

IIS fulfills the role of the Web server, responding to requests for files from
Web clients such as IE, and logging activity.

IIS maintains information about the location of content files, what

security identities have access to those files, how content files are
separated into applications, and what URLs are mapped to those
applications. This information can be configured manually or
programmatically by using one of the IIS administration technologies.

IIS can communicate with software such as Microsoft SharePoint,

Microsoft Visual Studio.NET, and Web Distributed Authoring and
Versioning (WebDAV) to make Web content creation fast and easy.
Web content can be created to take advantage of one of the IIS
development technologies. The Role of IIS in the Client/Server
Relationship IIS 7
Web browser

web browser as a computer program used for accessing sites or

information on a network (as the World Wide Web). This is a simple, yet
accurate description. Web browsers come in many different styles, each
with their own nuances. However, the main reason a person utilizes a
web browser is to view web pages on the Internet,

Before delving into the details of building a Web-based

application, it might be helpful to review the architectural model
of the Web, and the roles of the browser and server in that
model.

The User Experience

Sharing information on the Internet is a simple process of a user
(or client) using a Web browser such as Internet Explorer (IE) to
request a file from a Web server such as IIS.

The Web server sends the browser a response that contains the
requested file as well as headers that contain connection
information. The Web browser uses the HTML tags in the file to
properly format and display the data in the file. A Web browser
that displays HTML has the capacity to mimic any user interface.

Static Files Compared to Dynamic Files

If the file that the Web browser receives looks the same as the
file that is stored on the Web server, the file is considered to be
static content. Static content does not allow for changes based
on variables like time or individual user data that is stored in a
database.

The following illustration shows the transmission of a static file

where the displayed date will never change.
Content can be generated dynamically, either on the side of the
Web client (using client-side scripting, DHTML, XML, or other
client applications) or on the side of the Web server
(using ASP, ASP.NET, COM components, ISAPI, or other server
interfaces).

The following illustration shows the transmission of dynamically

generated content where the displayed date reflects the date at
the time of the request.

The Role of IIS

IIS fulfills the role of the Web server, responding to requests for
files from Web clients such as IE, and logging activity.

IIS maintains information about the location of content files,

what security identities have access to those files, how content
files are separated into applications, and what URLs are mappe
Web Application Architecture

Web Sites

There is a subtle distinction between a web application and a web site. For
the purpose of this paper a web application is a web site where user input
(navigation through the site and data entry) effects the state of the business
(beyond of course access logs and hit counters). In essence a web application
uses a web site as the front end

Figure 1 Basic Web Application Architecture

The information made available by a web site is typically stored, already

formatted, in files. Clients request files by name, and when necessary
provide specific path information with the request. These files are termed
pages, and represent the content of a web site.

In some situations the content of a page is not necessarily stored inside the
file. It can be assembled at runtime from information stored in a database (or
other information repository) and formatting instructions in a file.
Alternatively it can come from the output of a load-able module (CGI or
ISAPI). The web server uses a page filter to interpret and execute the scripts
in the page. Web sites employing this strategy are called dynamic sites.
Figure 2 Dynamic Web Site Architecture

Dynamic web sites offer certain advantages to web site designers. They
make it easy to keep the content fresh and synchronized with data in a
database. The overall look and feel of the web site is defined by a set of
pages that contain code executed by the web server during a request for this
page. In this context the file can either be an plain text file with scripts
interpreted by the web server, or a compiled binary file that is executed by
the web server. In either case the code in the "page" references and utilizes
server resources which include databases, email services, file services, etc.

A user interacts with a web site via a browser. A browser is an application

that runs on a client machine, that connects to a server on a network and
requests a page of information. Once the page request has been fulfilled the
connection terminates. The browser knows how to communicate (via HTTP)
to a web server, and how to render formatted information returned by the
web server. Most pages of information contain links to other pages (possibly
on other servers), which the browser user may easily request. Users navigate
the web by clicking on links and requesting pages from web servers.

Web Applications

The distinction between web sites and web applications is subtle, and relies
on the ability of a user to effect the state of the business logic on the server.
Certainly if no business logic exists on a server, the system should not be
termed a web application. For those systems where the web server (or an
application server that uses a web server for user input) allows business
logic to be effected via web browsers, the system is considered a web
application. For all but the simplest web applications the user needs to
impart more than just navigational request information, typically web
application users enter a varied range of input data. This data might be
simple text, check box selections, or even binary and file information.

The distinction becomes even more subtle in the case of search engines,
where users do enter in relatively sophisticated search criteria. Search
engines that are web sites, simply accept this information, use it in some
form of database SELECT statement and return the results. When the user
finishes using the system there is no noticeable change in the state of the
search engine (except of course in the usage logs and hit counters). This is
contrasted with web applications that, for example accept on-line
registration information. A web site that accepts course registration
information from a user has a different state when the user finishes using the
application.

The overall architecture of a web application is identical to that of a web

site. It can however, become significantly more elaborate. The rest of this
section will attempt to gradually build on the web site architecture to
eventually reach that of a fairly complete and complex one. Given the
history of this industry, this classification of fairly complete may not even
last by the time this paper is completed. Regardless it will contain most of
the concepts and components that are expected to be the cornerstones of web
applications for the next several years.

Pages

By far the most fundamental component of a web application is the page.

Browsers request pages (or conceptual pages) from servers. Web servers
distribute pages of information to browsers. The makeup and organization of
a web pages in essence make up the user interface for the application. In web
applications the browser acts as a generalized user interface container with
specific user interfaces being defined by each page’s content.

In web application development environments like Microsoft’s Active

Server Pages or Allaire’s Cold Fusion, the pages are a combination of static
HTML formatted pages, and dynamic scripted pages. The scripted pages
contain code that is executed by the web server (actually it is more likely to
be delegated to a scripting engine or page filter) that accesses server
resources to ultimately build an HTML formatted page. The newly formatted
page is sent back to the browser that requested it.

Server Scripting
It is important to note that the connection between the client and server only
exists during a page request. Once the request is fulfilled the connection is
broken. All activity on the server (as effected by the user) occurs during the
page request. This represents a very significant distinction between
traditional client server applications. Business logic on the server is only
activated by the execution of scripts inside the pages requested by the
browser.

Depending upon the specific scripting engine, scripted pages can contain
user defined variables, sub routines and functions. Some scripting engines
even permit the definition and interaction of objects.

The ultimate result of this server processing is to;

1. update the business state of the server, and

2. prepare an HTML formatted page (user interface) for the requesting
browser.

An important and subtle part of web application design is understand and

accommodating of this paradigm of client and server interaction. Business
objects are not always accessible when handling individual user interface
requests. For example a common user interface (and business feature) in
many client server applications is the automatic population of city and state
fields in a US postal address when a zip code is entered. Assuming that all
three fields are located on the same page in a browser this feature would
require an additional server page request to happen immediately after the zip
code was entered. For most web applications this carries with it an
unacceptable performance burden. For most web applications page requests
are fulfilled in an order of seconds instead of milliseconds.

Client Scripting

The server is not the only component in a web application that executes
scripts. The browser itself can execute scripted code in a page. When the
browser executes a script, however, it does not have direct access to server
resources. Typically scripts running on the client augment the user interface
as opposed to defining and implementing core business logic.
client scripts should not be confused with client side components such as
Java Applets or ActiveX controls. These components are a separate category
of component in the overall web application architecture and are discussed
in more detail later. The client scripts discussed here are JavaScript (or
VBScript) code embedded in the HTML formatted page. The code is
executed in response to browser generated events (document loaded, button
pressed, etc.). With the acceptance of the new Dynamic HTML
specification, client scripts can access and control nearly every aspect of the
page’s content. Additionally it further opens up access to the browser object
model itself, enabling client side scripts to interact with other browser
resources.

When an HTML web page is rendered in a browser it is first parsed and

divided up into elements. When dynamic HTML is employed each of the
elements can be named or assigned an ID, which could be referenced by
client side scripts. Some common element types include anchors (links to
other pages), tables, font specifications, etc. The elements making up the
content of the page have an object interface defined by the Document Object
Model (http://www.w3.org/DOM/). The browser also has an accessible
interface, yet differing brands of browsers may have subtle differences.

Client scripts, like their server side counterparts, may contain variable
declarations, sub routines and functions. The only major conceptual
difference is server side scripts contained in a page are inherently
procedural, while client side scripts are inherently event driven