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