This page describes the general architecture used when building modern web-based applications. The general architectures reviewed are applicable across technologies (e.g. Microsoft and Java). Other pages describe how the web architecture is implemented in specific technologies (e.g. using Java technology).
Two types of web architectures will be reviewed:
A modern web-based enterprise application has four layers, as shown in Figure 1:
The client layer of a web application is implemented as a web browser running on the user's client machine. Its job in a web-based application is to display data and let the user enter/update data. Broadly, one of two general approaches is used for building the client layer:
The semi-intelligent client approaches generally easier-to-use and requires fewer
written to work with later versions of mainstream versions (a typical requirement: must
have IE 4 or later or Netscape 4 or later). Since the browser market has gravitated to
Netscape and IE and the version 4 browsers have been available for 3 years, this
requirement is generally not too onerous. More and more websites are specifying the
"version 4 or later of IE/Netscape" browser requirement.
The presentation layer generates webpages and it includes dynamic content in the webpage. The dynamic content typically originates from a database (e.g. a list of matching products, a list of transaction conducted over the last month, etc.) The other major job of the presentation layer is to "decode" the webpages coming back from the client (e.g. find the user-entered data and pass that information onto the the business logic layer).
The tools provide methods that make it easy to embed dynamic content inside other static HTML in the webpage. They also provide tools that make it easy to parse a webpage coming back from the client to get the user-entered information.
The presentation layer is generally implemented inside a Web Server (like Microsoft
IIS, Apache WebServer, IBM Websphere, etc.) The Web Server can generally handle
requests for several applications as well as requests for the site's static webpages.
Based on its initial configuration, the web server knows which application to
forward the client-based request to (or which static webpage to serve up).
The bulk of the application logic is written in the business logic layer. Business logic includes:
In modern web applications, business logic is frequently built using:
The business logic layer is generally implemented inside an Application Server (like
Microsoft MTS, BEA WebLogic, IBM WebSphere, etc.) The Application
Server generally automates a number of services like like transactions, security,
persistence/connection pooling, messaging and name services. Isolating the business
logic from these house-keeping activities allowing the developer to focus on
building application logic while application server vendors differentiate their products
based on manageability, security, reliability, scalability and tools support.
The data layer is responsible for managing the data. In the simple case, a data layer may simply be a modern relational database. However, it may include data access procedures to other data sources like hierarchical databases, legacy flat files, etc. The job of the data layer is to provide the business logic layer with required data when needed and to store data when requested.
Generally speaking, the architect should aim to have little or no validation/business
logic in the data layer since that logic belongs in the business logic layer. However,
eradicating all business logic from the data tier is not always the best approach. Not
null constraints and foreign key constraints can be considered "business rules"
which should only be known to the business logic layer. Most would agree that it is
safer/better to include such simple constraints in the database (and to change them, as
the business rules evolve).
The 4-level model presented above is appropriate for enterprise applications where there are many webpages and a significant amount of business logic. The Enterprise Model provides a clear delineation between presentation logic and business logic (which improves maintainability). Also, separating the business logic from the presentation logic provides for much more scalability since the intense business logic can run on separate server(s) under the management of application server software.
For smaller web applications, it may be unnecessarily complex to have two separate layers in the middle tier (and specifically, it may be too much overhead to run a web server as well as an application server). While it is still advisable to develop business logic in separate modules, a smaller application may run both presentation logic and business logic inside the Web Server as shown in Figure 2.