AppThena - Architecture


This document assumes that you are an application developer who needs a rapid introduction to the way that AppThena works. It shows you how the system handles page requests from a web browser and which components are involved.

Please see Getting Started for more information about modifying components and customising AppThena.

AppThena in Context

Web Application Architecture

This diagram shows how AppThena fits within a standard enterprise web application architecture. The flow of control in the architecture is as follows:

  1. The browser sends a request for a resource of some kind to the web server.
  2. The web server decides what to do with the request.
    1. Static resources such as images, CSS and static web pages are read from disk and returned directly to the browser.
    2. Requests for dynamic resources such as an AppThena Edit screen are forwarded to an application server.
  3. The application server passes the request to the correct web application. e.g. AppThena.
  4. The web application constructs a response using data from the database server when necessary.
  5. The response is passed back up the chain to the browser.
  6. The browser displays the response.

The web, application and database servers are independent pieces of software which can be installed on the same computer or on different computers. This gives systems administrators a lot of flexibility when they deploy these systems. For example, a single database server can support the web application as well as other systems.

Note that the web server and the application server are often rolled together into one program. For example, Apache Tomcat™ can host web applications and serve static content as well.

The rest of this document concentrates on what happens within AppThena.

How AppThena Handles Page Requests

This section shows how AppThena handles standard page requests such as a user clicking on an "Action" button in the default AppThena web application. Other scenarios, such as JSPs that request data directly from AppThena's Model will be described later.

Note that the web and application servers are hidden in this illustration. It is assumed that they just pass requests and responses between the browser and AppThena without interfering in any way.

AppThena Architecture

The flow of control for a typical page request is:

  1. The Controller receives a page request.
  2. The Controller loads the Model and starts a database transaction.
  3. The Controller works out which Action should handle the request and passes it the request details.
  4. The Action does its work, reading and updating the database via the Model.
  5. The Action tells the Controller which object to use as the page object and which View should be used to render it.
  6. The Controller passes the page object to the View which is usually a JSP.
  7. The View creates an HTML document which is returned to the browser.

Main Variations


If a fatal exception occurs at any point then the Controller passes the exception to a View which generates an error page.

Follow on Actions and Redirects

Actions are not required to pass control to a View. They have two alternatives. First of all, they can ask the Controller to trigger another Action. These are referred to as "follow on actions". Secondly, the Action can ask the Controller to redirect the browser to another web page.

Redirects are not used very often as they move the user out of the web application and onto another website. Follow on actions are much more common. For example, the Delete action uses a follow on action if the user deletes the object they're currently viewing. This sends the user to the previous page in the bread crumb trail.

Event Handlers

This diagram doesn't show event handlers. As the name implies, event handlers are called in response to certain events. They are Java plugins which allow you to change the way the application works.

The Controller calls ActionEventHandlers before and after the Action does its work. Action event handlers allow you to modify the effects of an action. For example, you could use a customised view to display a particular type or override the sort order of a set of search results.

ObjectEventHandlers are called by the Model before and after it performs any database actions with an object. For example, you could update an employee's sales total every time they close a sale. You could also perform fine-grained security checks so that users in one department can't edit objects belonging to another department.

In many ways, object event handlers are a replacement for traditional business objects. They are a convenient way to write business rules for specific types that are triggered when objects are loaded, saved, created etc. The main advantage they have over business objects is that you don't have to create them for types that don't have any interesting business rules. Another advantage is that you can add a new event handler to an existing system even if you don't have the original source code.

Using the Model without the Controller

You don't need to use the AppThena Controller to get access to your data; just can just access the Model directly.

Using The Model Without The Controller

This design ignores the Actions, ActionEventHandlers and the standard views as well as the Controller. The ObjectEventHandlers will still be fired though. This means that you can use ObjectEventHandlers to enforce business rules whether you use AppThena's GUI or not.

Note that you can use this approach to connect other systems to the AppThena Model as well as JSPs. This is perfect for integrating AppThena with legacy systems or systems that aren't web applications.

Please see How To Load AppThena Objects in a JSP for an example of using a JSP to access the Model directly.