By way of defining in more detail what a web framework is, a list of functional requirements is presented here. These are all things that web frameworks should enable their users to do or deal with.
Contents
Presentation
Presentation is perhaps the simplest and best understood functional requirement for which a web framework should provide. It is the first requirement recognised---early web frameworks focussed exclusively on presentation.
Presentation entails everything a web application needs to do in order to render its user interface in a client's browser, using HTML or a similar markup language. Typically, in order to facilitate re-use, each page is not merely seen as a web page---it is viewed rather as a window in a GUI, composed of different UI components.
The difference between the UI components in a web page and those used in a GUI is that the latter are usually available as re-usable programming language components with behaviour linked to their presentation; the former are mere low-level representations. The low-level representations on a web page not only lack behaviour, but more complicated compositions of them cannot be made for re-use.
To appreciate the difference between GUI programming and web programming, consider this (for example): a GUI programmer can usually create a new kind of component which can be re-used in programs and contain other widgets supplied in a standard widget library (like a tree browser component). Web programmers cannot do this with (say) HTML: it is not possible to, for example, create a special labelled input component which consists of some HTML text, followed by a colon, followed by an HTML text input. Instead, web programmers are forced to stay on the level of abstraction provided by HTML.
What a framework can do, though, is to provide a different language with which a page can be specified and from which the lower-level HTML will be generated.
Form handling
User input on the web takes place through HTML forms that are submitted to the web server by a browser. Forms are submitted to a particular URL on a web server, as an HTTP request. Form handling is a term often used to describe various tools which a programmer can use to deal with forms---and especially to deal with the user input that has been received as part of submitted forms.
For example: when user input is received via an HTTP request, it comes in the form of named text strings. These can be marshalled to more useful typed programming language objects. Errors can occur during this process which need to be reported to the end user.
Forms can also be submitted as a result of different buttons being clicked on the form. As part of form handling, a program needs to determine which button caused the submission and needs to take appropriate action, depending on that information.
A web framework should provide tools to help a programmer deal with form handling tasks.
Validation
Validation is also related to user input and is often seen as part of form handling. Validation usually refers to checking user input against some constraints (a number may be required to be within a certain range, or a string representing an email address can be required to match a regular expression). However, validation might also be dependent on more sophisticated domain knowledge which might have to be checked in a back-end system on another tier in a multi-tier architecture (where domain-specific knowledge typically resides).
Provision needs to be made by a web framework for a programmer to easily specify what validations need to be checked, how validation errors will be reported to the user, and what influence such errors will have on the dynamic behaviour of the presented UI.
Event handling
Frameworks also need to react in response to events signalled from the browser (or the user).
An incoming request from a browser signifies that the user has triggered an event of some kind---either by submitting a form, or by having clicked on a link. Such a request can be interpreted in many ways. For example, it can be seen as notification that a UI event occurred, or a batch of UI events can be derived from it. The design of a web framework determines what constitutes an event, how events are triggered, how events relate to HTTP requests, and how custom program code will be invoked in response to events.
Sometimes a request is simply mapped to a method call, for example. Other frameworks have more complicated programming models for dealing with events.
Page flow
Page flow is a description of the possible ways in which a user can traverse the different logical locations (web pages) in a web based UI. It is to locations (or pages) in a web UI what control flow is to statements in a programming language.
Often, page flow is implicitly specified in web pages or code that is invoked upon an HTTP request. Such implicit links between pages is reminiscent of goto statements. Its very flexible, but difficult to visualise and makes it possible to write complex programs that are difficult to maintain.
The implementation of page flow has implications for the client browser: typically, a browser is based on the premise that a URL denotes such a location on a web site. The browser adds functionality, such as the ability to bookmark a location and to go backwards and forwards along the path traversed by the user, based on the identification of locations with URLs.
Frameworks should provide a means by which page flow can easily be specified.
Session state
HTTP is a stateless protocol: it provides little support for relating a particular request to others in a lengthy conversation. Web applications, though, need some way of relating all the requests from a particular user during a user session in order to be able to store information between requests for a single user session. The information stored in the scope of a user session is referred to as session state.
Session state is used, for example, when a user has provided input for several input items on a form, has submitted the form and then expects that her input will subsequently still to be shown on the form, even in the event of a validation error requesting her to change some of the information. Such an interaction may span several requests to the web server. The information supplied at the beginning in the submission of the form is needed to render, for example, a half-completed form later on (possibly with an error message added).
Authentication
Authentication is related to session state. Web applications often need users to authenticate themselves, for example, by means of a user name and password. Once authenticated, the web application can modify its UI based on who the user is. Authentication, though, is something that most web application designers prefer to happen only once during a user session---to be stored by the application for the duration of the session.
Of course, authentication needs to be implemented in a secure way---and in this case, neither the client nor the transport mechanism can necessarily be trusted.
The HTTP protocol provides more than one authentication mechanism, which can be further augmented with the use of HTTP over SSL. However, the problem is exacerbated by the fact that many web browsers implement the standard incorrectly---leading to complexities for a web server that has to cater for all browsers.
A web framework should provide an abstraction to its users for easily dealing with authentication issues.
Concurrency
Web-based applications are, almost by their very nature, accessed concurrently by several users. Since servicing a single request may take a long time (causing others to wait), a web framework needs to provide a mechanism by which concurrent requests can be served simultaneously. This can be done by maintaining a pool of processes, or a pool of threads in a single process, or even a pool of machines with pools of processes on them.
Some servers also have an asynchronous model---they kick off processing (typically on a back-end system) for each request as it is received, without blocking to wait for the processing (which is often IO intensive) to complete. The system can then alternatively poll for results from such processing (and quickly send a response) or start more processing for incoming requests (see http://www.nightmare.com/medusa/medusa.html, for example).
The particular concurrency model chosen has quite an impact on how many other requirements can be implemented. A naïve implementation of session state, for example, could be to keep some information for a user in memory. But, generally, memory cannot be shared between processes or machines, posing a problem in circumstances where subsequent requests from the same user could be routed to another machine, or another process.
When using multi-threaded approaches, care needs to be taken that the programs and libraries involved are all thread-safe.
Back-end integration
Usually, web applications are built using a multi-tier architecture, with their presentation tier being web based. Web frameworks are concerned with such web-based presentation tiers.
In a degenerate case, this web tier would need some way of accessing a local database. More often, it would need access to a remote database or application server. Such back-end systems often need to be accessed within the boundaries of a single database transaction or security realm.
A web framework should provide abstractions for a programmer that automatically deal with these low-level technical concerns in a sensible way. Apart from the fact that web programmers do not want to have to think about such low-level, complex, technical issues, many UI programmers are not well versed in such matters.
Resource usage
A common thread running through many implementation discussions for web frameworks has to do with the economical use of resources. Several scarce or expensive resources are used by web applications or web frameworks. Frameworks have to take care to use resources such as the following in ways that remain performance efficient when scale-up occurs:
File descriptors
- File descriptors are in limited supply on a machine, and web serving software uses them for writing to log files, in writing to temporary files for persisting session state, and the like.
Sockets (or TCP/IP ports)
- Sockets are also limited on each machine---limiting the number of network connections that can be maintained at one time.
Connections
- Connections to databases or other back-end systems are often only allowed in a limited number, and creating a connection typically involves a performance overheads too large to incur on every HTTP request. Thus, connections to back-end systems might not be created for each request. Instead, a pool of connections is usually maintained so that the total number of connections is centrally managed, and an already created connection can quickly be allocated to the servicing of one request.
Memory
- Memory cannot remain allocated to each particular user for the duration of her session, given the number of concurrent users that has to be serviced.
Processes and threads
- Processes (and, to a lesser degree, threads) involve overheads to create and destroy. Thus, they also are typically created in advance in a pool from which existing processes or threads can be allocated to requests.
Miscellaneous
Miscellaneous requirements may be added to the important set explained thus far. For example, web applications often need special support to enable them to be presented in different languages, to work with different locales, or to use different character encodings used for web pages.