Home
What's New
Dev Tools
Services
Feedback
Site Map
Architecture

General Web Architecture

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:

Architecture for an Enterprise Web Application

A modern web-based enterprise application has four layers, as shown in Figure 1:

Figure 1: Architecture for an Enterprise Web-based Application

General Web Architecture

The Client Layer

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 dumb client approach tends to be more cumbersome for end-users because it must go back-and-forth to the server for the most basic operation.  Also, because lists are not built dynamically, it is easier for the user to inadvertently specify invalid combinations of inputs (and only discover the error on submission).  The first argument in favour of the dumb client approach is that it tends to work with earlier versions of browsers (including non-mainstream browsers).  As long as the browser understand HTML, it will generally work with the dumb client approach. The second argument in favour of the dumb client approach is that it provides a better separation of business logic (which should be kept in the business logic tier) and presentation (which should be limited to presenting the data).  Including Dynamic HTML and JavaScript in the Presentation (so it can run on the client) mixes the tiers.

The semi-intelligent client approaches generally easier-to-use and requires fewer communications back-and-forth from the server. Generally, Dynamic HTML and JavaScript is 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

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 Presentation layer can be built in a number of different tools.  The presentation layer for early websites were built as CGI or Common Gateway Interface programs.  Netscape also had server-side JavaScript for websites.  Most modern websites presentation layers are either built using:

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 Business Logic Layer

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

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).

Simplified Model for Smaller Web Applications

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.

Figure 2: Architecture Alternative for a Smaller Web-based Application

Alterntative for Smaller Web Arch

... back to Architecture Topics  or  Java Topics 


Copyright 1997-2017, Woodger Computing Inc.