Web application architecture

As a way of keeping my knowledge of web applications fresh in my mind, this is a quick post on the architecture of common web applications, taking into account the varied scale of such applications.

While I’ll refer in particular to the Java Enterprise Edition based (J2EE) solutions, the principles of structuring an application are the same in other development platforms.

So from a high level perspective, the following components are common to most web apps:

Server Side Components

Permanent data store: Most usually a relational database (RDBMS), which can be interacted with through SQL. This can take any form of interaction; from other parts of the application simply manually connecting and running SQL statements to quite complex persistence management components which automatically update and query the database using the objects in the system.

Data model: An abstraction of the information that the application needs to manipulate, generally always defined as classes in an Object Oriented manner in the relevant programming language. They may for example mirror members of a particular web-site and their member details, or items in a catalogue. These model classes take varying levels of complexity; in Java they may be Plain Old Java Objects (POJOs) or more complex Enterprise Java Beans which can directly linked to the database using a persistence management component.

Persistence manager – A layer which acts as a middle-man between the data model classes and the data source.

Interaction controller: The controller manipulates the data model based on the interaction the user carries out in the user interface. This can be a very thin layer, but it’s existence is important to act as the entry point to the server side components – seperating business/application logic from the user interface. In Java web development this is usually a servlet.

Client Side Components

User interface: A full blown application or website that is run on the client machine, most often in a web browser. There are a variety of technologies which may be used here. It could simply be a HTML page using HTML forms or it could incorporate an AJAX-style language that uses javascript, or converts its code into javascript. The primary reason for using javascript as a client side run time technology is the convenience provided by the incorporation of javascript interpreters into nearly all web browsers, meaning users needn’t first download anything to use the application. Often as far as a user is concerned a web-app is simply another web-page offering more interactivity than is usually available. The complexity of this layer depends on the complexity of the UI components required.

The separation as to where certain code and features of an application should go is an important business issue, as there are certain issues relating how thin the client side is. Generally it should be as simple as possible, as it is harder to maintain client side code and carry out complex processes there.

Anyway that’s a very straightforward summary of the common structure of web applications. The specific technologies used to implement web app solutions vary incredibly and there is no right or wrong mixture of technologies. It is important not lose sight of the overall architecture of web apps and not get bogged down with doing too much with one very specific technology and try to do everything in that space (which you might do if your very familiar with it or like it better than another). The fact is that development is a process of breaking down problems into ever smaller chunks which often require different approaches to solve.

- Originally a blog post I decided to make this a proper article on the blog site, as looking back this is one of the most useful things I’ve written about web applications so far! In the future I plan to produce a similar guide to web apps from an end-user perspective with less technical jargon for casual observers to learn about the structure of web based software.