UEAS Architecture

Index

The UEAS architecture is mainly based on three main components:

• The template rendering system.
• The pipeline through which all the requests go.
• The database access layer.

The pipeline is internally used by the application and allows the programmer to build flexible yet powerful constructions. It is based on the idea that every single HTTP requests is pushed through the pipeline, where different filters exist. Every filter will perform an operation on the request (such as detect and set the platform, logging, statistics, etc) and any of the objects can stop the sequence at any time issuing an error value. When the request exits the pipeline, it means that there are no more objects that want to perform an operation on the request and the result is sent back to the client. This pipelining capability is pushed to the maximum in several parts of the code, where it can be seen how powerful this mechanism is.

The database access layer takes care of accessing the database to load user and account information. It was designed to be as small and simple as possible, but it was not optimized for speed or performance. Should those be critical areas in the future of UEAS, then the code for the database layer will be revised.

Top

The template system is what makes UEAS so powerful and capable of virtually serving any kind of device under the sun. It is possible to effortlessly add code for new devices without modifying any line of the Java code. The template system is built on top of the Velocity template engine, a great tool provided by the Jakarta project. Therefore, some knowledge about Velocity code would be necessary in order to be able to develop templates. The Velocity User Guide is a good place to start.

Once an HTTP request comes to the application, it is pushed into the pipeline (see point number 2 for more information on the pipeline), where several operations will be performed on that request. One of the first objects that we find in the pipeline is the SetPlatform object. This object takes care of detecting the platform of the client by having a look at the User-Agent and Accept HTTP headers. The outcome of this process will later determine which set of templates will be used to render the content. The behaviour of the SetPlatform object is determined by the terminal.properties configuration file, and the settings in that file can be ignored when specifying the platform=xxx parameter in the HTTP request like in this sample URL: http://myhost:8080/ueas/?platform=vxml.

Once we know which set of templates we have to use, the request continues its way through the pipeline until it reaches the Client object. That object basically performs the operations on the user mailboxes, such as login, show the inbox, change folder, view a message and so on. It is very important to know that it is in the Client object where a template is chosen. Templates will be chosen according to something that has been defined as "events". The set of available events is defined in the file renderer.properties and every event has been assigned a template file. From inside the Java code, a call to the Renderer object needs a reference to an event, therefore we have to be really careful and not delete any of the already defined events (but new events can be added anytime)

Having a look at an specific event of the renderer.properties file, it looks something like this:

event_index.template=index.${platform}.template

event_index is the name of the event that will be used within the Java code every time we want to show the main index page (the one where the user is asked to key in his or her user name and password), while the .template property is used to define the template that will be used.

Knowing about the SetPlatform object is good because now we must know that the ${platform} variable substitution will be carried out based on what that object decided (or on what we forced him to do!) In our case, if we got a request for an HTTP client then we will get the following result:

index.html.template.

Once the name of the template file that will be used is known, we can relay the task of rendering the template to the Velocity engine. It will put all the required object in the template context (again, please refer to the Velocity user guide for more information about this) and will make the template go through its rendering engine. After the rendering process, the result will be put back into the pipeline until there are no more objects/filter, the request comes out and it is sent back to the client as a result.

Velocity uses the velocity.properties file to determine where the template files are located. By default they are under:

• webapps/ueas/templates/html
• webapps/ueas/templates/wml
• webapps/ueas/templates/vxml

If there is a need to develop templates for a new platform that is not included in the default distribution, then the necessary steps to add templates for that platform would be:

1. Add the following settings to the terminal.properties
   terminals.list=html,vxml,wml,new_platform
   ...
   terminal.new_platform.mimetype=some/mime_type
   terminal.new_platform.useragent=.*regexp_for_useragent_header.*
   terminal.new_platform.accept=.*regexp_for_accept_header.*
   terminal.new_platform.platformid=new_platform
   ...
   
   
2. Create the ueas/templates/new_platform folder and place there all the templates, following the standard naming policy: template_name.<platform_name>template. For example the template file used for the main login screen would be called in our case index.new_platform.template .
   
   
3. Add a the following line to the velocity.properties file:
   file.resource.loader.path = path_to_tomcat/webapps/ueas/templates/new_platform
   
   

Top

not yet

Top

not yet

Top

not yet

Top

not yet

Top