Architecture for a layered Enterprise Web Application

A modern web-based enterprise application has four layers (see the figure)
  • a client layer which renders webpages
  • a middle tier which includes:
  • a Presentation Layer which generates webpages, including their dynamic content. It interprets webpages submitted from the client.
  • a Business Logic Layer which enforces validations and which handles interaction with the database
  • a data layer which stores data between transactions

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:

  1. a "dumb" HTML-only client: with this approach, virtually all the intelligence is placed in the middle tier. When the user submits the webpages, all the validation is done in the middle tier and any errors are posted back to the client as a new page.
  2. a semi-intelligent HTML/Dynamic HTML/JavaScript client: with this approach some intelligence is included in the webpage which runs on the client. For example, the client will do some basic validations (e.g. ensure mandatory columns are completed before allowing the submit, check numeric columns are actually numbers, do simple calculations, etc.) The client may also include some dynamic HTML (e.g. hide fields when they are no longer applicable due to earlier selections, rebuild selection lists according to data entered earlier in the form, etc.) Note: client intelligence can be built using other browser scripting languages
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:

  1. the Microsoft solution using Active Server Pages (ASP) which may be generated by Visual InterDev OR
  2. the Java solution using some combination of Servlets and JavaServer Pages (JSP)
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:

  1. performing all required calculations and validations
  2. managing workflow (including keeping track of session data)
  3. managing all data access for the presentation tier
In modern web applications, business logic is frequently built using:
  1. the Microsoft solution where COM object are built using with Visual Basic or C++ OR
  2. the Java solution prescribed by Sun has been to build the business logic layer with Enterprise Java Beans (EJB). However, in time this has evolved to building the business layer using Plain Old Java Objects (POJOs) while implementing data persistence with simple JDBC or using various persistence frameworks like Hibernate or Java Data Objects (JDOs). Hetrogeneous back-end systems frequently provide additional logic and these applications are often accessed through a message oriented middleware via JMS in Java.
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)

  1. Reference 1
  2. Reference 2