Software Development Resources
Create account | Log in | Log in with OpenID | Help

Web application

From DocForge

A web application, or web app, is a program which interacts with users through a web browser over a network. While a web server can respond to requests with static files, a web application typically handles requests dynamically by programatically building the response. Web applications are the foundation of interactive web sites. They are sometimes referred to less accurately as a rich internet applications.


[edit] Components

Web applications consist of several components or tiers. Each is often thought of as a layer, with one built on top of another. At a bare minimum there are two tiers: the client (web browser) and the server (web application). All components, of course, must run on some form of operating system, and therefore the OS is generally not counted as a layer. Here the various possible web application tiers are described from the bottom up.

[edit] Database

Most web applications are built with dynamic data. This data is usually stored in a database server, or sometimes another form of long-term storage. Some data is expected to change often, such as in a shopping cart or discussion board. Other data may change less frequently, such as maps or or help documentation. The type of data storage chosen is dependent on the format of the data, the frequency of its change, and how it's going to be used.

Web applications with large amounts of data often find the database to be the primary server-side bottleneck. The selection and configuration of database servers have a large impact on performance and scalability. Distributed and cached data storage are often good choices for web sites which expect high growth.

[edit] Web Application Server

The core of a web application is the application server. The server handles requests from the web browser and builds the appropriate response. A web application can directly listen for HTTP requests. More often, however, a generic web server, such as Apache's httpd, listens for requests and hands them to the appropriate application. Today, the server component of web applications are most often written in Java, Perl, PHP, Python, or .NET.

Web applications themselves can be built of multiple layers. Complex systems might separate business logic and transaction servers from the content display components. This is often the case with workflow and financial transaction systems. An added benefit of separate business logic or other core servers is their use for other systems. A workflow transaction system, for example, might be shared between a web site and rich client application. This promotes code reuse and allows developers to focus on specific tasks.

Some runtime environments, such as Java's web containers and Python, allow web applications to run indefinitely. Others, such as PHP, treat each request independently with a completely new environment. This greatly affects web application architecture, in that some components may be persisted by the environment and shared by requests.

[edit] Web Browser

The top layer of most web applications is the web browser, which directly interacts with the user. This is the one component over which web application developers have the least control, as on a public web server any version of any web browser may try to connect and interact. Therefore standards for public web sites are extremely important. Browsers need to support common standards so they can all be used with the widest range of web sites. And web applications need to support common standards so they don't alienate any segment of potential users.

Today most web applications serve HTML or XHTML to the web browser. They often send JavaScript and/or Flash to make the content dynamic and more interactive.

[edit] Benefits & Drawbacks

Web applications have some benefits over other types of systems, such as desktop applications:

  • Web applications can be upgraded and updated without distributing software to every user. Each visitor to a web app is getting the latest version immediately when they request each web page.
  • People can find web apps over the internet through referrals and search engines and immediately use them. There is zero distribution necessary, only discovery, to start using them.

Web apps also have some drawbacks over other types of applications:

  • To support every visitor a web app must be compatible with every commonly used web browser. Browser compatibility is a major development concern because there are important differences between browsers. The open standards for the web allow for flexibility in browser implementations.

[edit] Interaction

Between the layers there are various protocols and libraries used to communicate. The web server connects a database locally, often through sockets, or over a network between computers. Web servers might interact with each other or with application servers through basic networking, like TCP/IP, or higher level protocols like RPC. Web servers communicate with web browsers using the HTTP protocol.

[edit] State

While a typical client application can retain its state while continually waiting for user input, web applications are inherently stateless due to the HTTP protocol. Each request from any user is handled independently. To overcome this limitation cookies are often used to keep track of user sessions. With each page request the active session can be checked to get user-specific information.

[edit] Best Practices

[edit] Design Patterns

[edit] Security

Main article: Web application/Security

Web applications which exist on the public internet should never trust user input, or any input from the client application. Malicious code may connect to a web application server from any other computer, with or without the owner's knowledge. Any layer of an application may be a security risk, and any input may be an attack vector:

  • HTTP request headers may attempt to manipulate a web server or application runtime.
  • Unexpected requests for files may download source code or secure files.
  • HTML form submissions may contain executable code.

[edit] Performance

Performance can be tweaked on a case by case basis. But there are general best practices and things to typically consider:

  • Cache dynamically generated content when possible. Pages that rarely change, for example, don't need to be regenerated on every request. Consider caching earlier in the request handling when possible, such as at the web server layer or earlier using a proxy server. Also set the cache values of the HTTP headers to inform web browsers and intermediate servers what they may cache.
  • Leverage features of the HTTP protocol, such as expiration headers. Client browsers, proxy servers, and web accelerators can use this information to optimize performance.
  • Make as few requests to the web application as possible. Ideally it will only process requests that are necessary, such as content updates. Images, JavaScript, and other page content can be combined together into few requests. A proxy server or web accelerator can help with this process if not done directly by the web application.
  • Compress network traffic when possible, such as with gzip. When implemented properly this will often be transparent to custom programming and to users. Apache httpd, for example, has a module which will automatically compress files by MIME type.
  • Consider spreading requests across multiple servers, i.e. load balancing. A simple round-robin approach might be sufficient in many situations, and can be implemented with a simple generic web server. An advanced load balancer will monitor the load of each server and distribute it appropriately.
  • Consider specialized servers for certain requests, such as multimedia.
  • Consider database replication. See programming for database replication for additional considerations.
  • Run tasks which don't need to execute during a page load in the background. This is most often accomplished with scheduled tasks, such as cron jobs. Offloading background tasks to secondary servers can additionally enhance performance.
  • Leverage platform and language performance characteristics
  • Generate optimized web pages, as the performance of page rendering factors into the perceived performance of web applications.

[edit] Case Studies

[edit] Examples

Obviously there are too many web applications to list and analyze. A few notable web apps include