Design

Tammi's architecture is compliant with JMX (Java Management Extensions). Applications are formed by independent components plugged into Tammi, and configured dynamically during startup and run-time with scripting engines, such as DynamicJava. Application components share common services and communicate with each other through a location-independent object registry server acting as an IoC (Inversion of Control) container. Both common framework services and application specific components are either implemented or adapted as MBeans (Manageable Beans). They are registered to and looked up from the MBean Server when needed based on their exposed MBean interface according to the IoC design pattern. The components may be distributed in the network when applicable, but they can as well reside on the local host.

Applications follow the MVC (Model-View-Controller) design pattern, which aims at separating presentation from content within applications:

• Model - content producer components implemented as MBeans
• View - one of the template engines parsing a user interface template
• Controller - a filter chain selecting the template and content producers for each of the client requests

Tammi facilitates concurrent programming and all of its components are thread-safe when appropriate.

Development Framework for MBeans

To integrate independent components and dynamic configuration to a working system, a framework must be provided around them. The framework is a set of interfaces, helper classes, and services that support development of MBean based components, and define guidelines on how to write code that plugs into the framework. The framework allows:

1. Partition of shared functionality into generic MBeans that are used through their public interfaces and not through their actual implementations
2. Reduced effort in MBean development since they become plug-ins for the framework and share functionality provided by other MBeans
3. Creation of a common server for all MBeans included in the framework
4. Centralized configuration management

The components included in Tammi are controlled through the lifecycle interfaces of their MBeans, which define their common lifecycle.

User Interface

The user interface of plug-in applications is based on the page-building model of Apache Turbine. The user interface page is typically formed by a static portion described with a markup language in a user interface template, and a dynamic portion provided by content producer components of the application.

The selection of the template for a client request is based on a template parameter included in the request URL or the body of the request. If such a parameter is not specified or not found, the default template will be applied. Templates are parsed by template engines. The three currently supported template engines are Velocity, FreeMarker and JSP, but support for others, such as WebMacro, can be added. Stand-alone applications may support JFC or SWT based user interfaces as well.

The framework supports development of international user interfaces, which adapt to different devices and user agents, and can be customized effectively. Tools for validating user input without need for client side scripting are included.

Filter Chain

The filter chain pattern is described in the Servlet API v. 2.3 specification. Tammi extends the filter chain mechanism by implementing a set of configurable filters defining the basic application behavior. In Tammi, filters are grouped into pipes which are collections of consecutive filters executed in the configured order. Pipes can form larger systems, within which branching filters control the request flow.

View a sample Pipe Collaboration Diagram.

Persistence

Tammi's persistence layer is based on the approach that maps objects to persistence mechanisms in such a manner that simple changes to the relational schema do not affect the object model. This approach makes objects independent on the persistence layer allowing development of large-scale, mission critical applications. The disadvantage is somewhat slower performance when compared to more straightforward solutions.

The implementation of the persistence layer is derived from the persistence broker API of the Apache Object/Relational Bridge (OJB). In addition to OJB, the persistence layer currently supports Castor XML Binding Framework.

Deployment

Tammi provides a run-time container for executing Java components installed under Tammi as plug-in applications. The framework itself may be installed as a web application running as a filter chain or servlet under some servlet container, or it may be installed as a stand-alone system. The stand-alone system can be configured to provide HTTP and HTTPS services via socket connectors. Plug-in applications are packaged into a deployment file, which is extracted to the framework file hierarchy.

Dynamic Configuration

Tammi starts up as an empty run-time container that is configured for a specific application domain and purpose with configuration scripts. The configuration model has been adopted from that of the servlet technology, by extending it to cover all aspects of internal components of Tammi, applications plugged into Tammi during startup, and run-time configuration of both new and loaded components.

The goal of dynamic configuration is to exploit efficiently common functionality provided by the framework without a need to develop, build and maintain several versions of the framework. This is especially useful in application domains where requirements, specifications, applications and components are changing frequently, but the overall architecture remains the same.

Java property files and Apache BSF scripts are applied to Tammi configuration.

View a sample Configuration Diagram.

Persistence

Tammi's persistence layer is based on an approach that maps objects to persistence mechanisms in such a manner that simple changes to the relational schema do not affect the object model. This approach makes objects independent on the persistence layer allowing development of large-scale, mission critical applications.

Configuration of the mapping between the object model and the database schema can be configured either directly or via XML files. The configuration may take place both at startup and during run-time. The mapping is defined between named application classes and relational database tables. In addition to a static mapping between the classes and tables, Tammi supports Variables, which can dynamically adapt to hold any number of new attributes of specified types. The classes corresponding to a particular set of attributes may also be created and loaded during run-time. By applying run-time Variables makes it possible to develop extremely dynamic persistence solutions.

The most dynamic persistence approach supported by Tammi is based on the Common Warehouse Model defining a generic relational meta model of any SQL based relational database schema.

View a sample Common Warehouse Model.

By designing and implementing the data model of the application through the relational meta model and Variables, the persistence of business objects can be fully managed during run-time allowing dynamic changes to the model without application rebuild, too.

View a sample Run-time Meta Variables.