Axional Studio is a 3-tier framework specifically designed for the development of large-scale, multi-tenant enterprise OLTP web applications.

Axional Server is the base of the system, which provides core J2EE services including:

  • HTTP, for data transport.
  • JDBC, for connection pooling and transparent multiple database support.
  • REST services, to deploy JAX-RS (JSR 311 & JSR 339) endpoints or clients.
  • SOAP services, to deploy web service endpoints or clients.
  • Apache FOP, for business document rendering in either Pixel Perfect or Page Perfect form.
  • Apache Freemaker, for template processing.
  • Java Virtual Machine (JVM) services, for low-level operations such as in-memory compilation, async IO, file mapping, fast object serialization, and object caching.

Axional Studio adds high-level application services to this core. These include:

  • Server metadata, to describe server topology and resources.
  • Application metadata, to describe applications.
  • EJB cache, for fast access to application metadata.
  • XML DML grammars for Data Modeling Language (DML), a database-independent SQL sublanguage.
  • XML DDL grammars for Data Definition Language (DDL), a database-independent SQL sublanguage. Also used to compile business logic (procedures, functions, and triggers).
  • XML scripting for middle-tier database-independent logic.
  • WEB forms, or widgets for OLAP & transaction forms and executive dashboards.
  • WEB reporting, for either OLTP & or OLAP analysis.
  • PDF reporting, for operational business reports, Pixel Perfect reports, and Page Perfect reports.
  • OLAP processing, for multidimensional analysis of business data.

About This Guide

This document provides a big-picture overview of Studio architecture, and is oriented towards developers and IT managers.

1 Application Architecture

Axional Studio applications rely on database metadata for their development, configuration (including business logic, scripts, etc.), and deployment.

Axional Studio requires an Infrastructure metadata enviroment which includes, at minumum, 3 databases, all supporting different functions.

  • wic_conf: a database container for infrastructure definitions. This includes all system resources available for application, such as database servers, databases, users, roles, authentication mechanisms, devices, etc.
  • wic_admin: an application database with metadata to manage the wic_conf database.
  • wic_root: an application database with metadata to manage applications, including wic_admin, wic itself, or any new application.

As shown before, wic_root is the root dictionary for all application metadata, and wic_conf is the database where an organization places all resources managed by Axional Studio applications.

In the following example, we can see the relationship of a system with two applications. One includes the stores7 database (and a development instance). The other includes an ERP application split into two dictionaries, named fi and scm, to split development of financial and supply chain management applications.


2 Server Architecture

Our system relies on Axional Server Java J2EE architecture for enterprise scalability and core services such as JDBC connection pooling, cache provisioning, template processing, memory mapping, etc.

The Axional Studio artifact has some maven dependencies, as defined in its POM:

  • Axional Server core, core server implementation.
  • Axional Server SOAP, SOAP implementation for either server or client.
  • Axional Server console, optional Eclipse SWT server console implementation.
Additionally, for Axional Studio webapps, WAR files are necessary to deploy applications in the container.

Application View


2.1 Scalability

The system is designed for maximum scalability by adding nodes horizontally. The process to group multiple nodes acting as a cluster is simple, as each node has a minimum startup configuration and utilizes a centralized database for its specific configuration settings.

2.1.1 Overload Protection

The system closely monitors the execution of code or script and limits the amounts of CPU time used, memory consumed, queries and DML statements executed, calculations performed, outbound web service calls made, and much more.

Our system also has built-in features to minimize failure due to system overload, including:

  • Low memory warning trigger to release LRU caches when needed.
  • Memory overload protection for large data processors such as Excel or PDF generation.
  • JDBC connection pool limits per user or group.
  • SQL cancel/timeout for long-running queries.

2.2 Reliability

Our system is designed for consistency and reliability, specifically aiming to handle large database applications.

2.2.1 High-Availability Data Replication

HDR is used to guarantee data replication across database servers. HDR consists of a pair of servers — primary and HDR secondary — and supports both synchronous and asynchronous replication modes. In synchronous mode, transactions on the primary server will not commit until it receives an acknowledgement from the HDR secondary server. Thus, the HDR secondary is immediately ready to take the place of the primary server — what is called a "hot" standby. In asynchronous mode, only checkpoints are synchronized between primary and HDR secondary. One distinguishing characteristic of HDR is the use of a half-duplex communication protocol, and is thus sensitive to network latency.

2.2.2 Enterprise Replication

In some scenarios, it may be necessary to replicate data in multiple locations using a non-simple dual topology. ER works by users first defining the servers among which they would like data to be replicated. This creates a network topology — of root, leaf, and non-root, non-leaf nodes — that will transfer the data. Each ER node may be a single server or a cluster of servers, which this article further discusses below. All the interconnected nodes together are called an ER domain. The domain does not define what data will be transferred, just the paths or routes along which the data will flow.

2.2.3 Two-Phase Commit

Even two-phase commit protocol is related to database architecture, as Axional Studio is designed to automatically handle transaction and isolation modes for OLTP applications.

2.3 Multitenancy

Multitenant architecture is built in by design, which means systems are truly designed for multitenancy.

Multitenancy refers to the mode of software operation in which multiple independent instances of one or more applications operate in a shared environment. The instances (tenants) are logically isolated, but physically integrated. The degree of logical isolation must be complete, but the degree of physical integration will vary according to the underlying configuration of the server.

The tenants (application instances) may be representations of organizations that obtained access to the multitenant application (this is the scenario of an ISV offering application services to multiple customer organizations). The tenants may also be multiple applications competing for shared underlying resources.

2.3.1 Physical Integration Models

2.3.2 Metadata

Axional uses a runtime engine that materializes all application data from metadata — data about the data itself. In a metadata-driven architecture, there is a clear separation of the compiled runtime database engine (kernel), tenant data, and the metadata that describes each application. These distinct boundaries make it possible to independently update the system kernel and tenant-specific applications and schemas, with virtually no risk of one affecting the others.

When you define a new application object or write some procedural code, Axional does not create an actual table in a database or compile any code. Instead, the system simply stores metadata that the system’s engine can use to generate the virtual application components at runtime. When you need to modify or customize something about the application schema, like modify an existing field in an object, all that’s required is a simple non-blocking update to the corresponding metadata.

Metadata Cache

Because metadata is a key ingredient of Axional applications, the system’s runtime engine must optimize access to metadata; otherwise, frequent metadata access would prevent the service from scaling. With this potential bottleneck in mind, Axional uses massive and sophisticated metadata caches to maintain the most recently used metadata in memory, avoid performance-sapping disk I/O and code recompilations, and improve application response times.

2.4 Clustering

As servers are designed for low physical integration (not shared), and all critical server data is kept on a database node, the system relies on High Availability Data Replication to cluster database data. Thus, when a group of servers are configured as a cluster, they share a single configuration database; any user can connect to any server to access applications.

Automatic load balancing can be added by using software like HA proxy or specialized hardware from F5, Cisco, etc.

2.4.1 Session Replication

Even a cluster sharing a single configuration database session is not replicated unless specified. Each server can be set up to replicate its sessions into a configuration database.

3 Database Architecture

Axional Studio supports a wide variety of database engines and multiple database topologies.

  • For low-level JDBC functions, Studio relies on Axional Server JDBC pool implementation.
  • For high-end database functions, Studio provides developers a wide set of XML scripting features and SQL syntax to make native code implementation more transparent.

XML to SQL grammar

A key point of Studio design is its ability to handle all SQL operations using XML syntax, translated during runtime execution to the target database's native language. This technology also possesses a significant advantage with regard to user security runtime code injection, which we will discuss in depth later.

3.1 Engines

Our system supports a range of features, from maximum to minimum, according to database architecture.

  • Development support to target multiple database engines is built on top of XML-to-SQL grammars for DDL (Data Definition Language), DML (Data Modeling Language), SPL (Stored Procedure Language) and Triggers.

    DDL & DML Compiler

    Built in DDL and DML, compiler tools are included to either deploy or verify metadata definitions in a target database.
  • Built-in spatial support is available for both spatial data types and spatial functions.
Database-Supported Features by Engine Type
Engine DDL DML SPL Triggers Spatial
High end
IBM IDS          
IBM DB2 Linux          
IBM DB2 400          
Middle end
Low end

3.2 Database transparency

Any server can handle transparently concurrent connections to multiple database architecture. Application requests are translated (except for raw native SQL calls) to the appropiate database agent. Then, send to JDBC connection pool.


3.3 OLTP support

Transaction handling is automatically handled by application infrastructure. Specific XSQL tags can be used to perform block commits.

3.4 OLAP support

An OLAP engine is integrated in the system and can be accessed either programmatically (using XSQL tags) or by user interface components.

3.5 Write on primary read on secondary

Axional Studio allows split database reads to replicated databases to increase performance and availability. By using this features, database replicas may be used actively to increase overall system capacity.

The system determines from an applications object being executed may require or not transactions and if it's observed as read only, the operation will be redirected to a read only replicated database pool.


4 Infrastructure metadata

Axional Servers usually work in groups of two or more configured in HA. Each server has a specific configuration file referred as config.xml with basic information to startup java instance like:

  • Http parameters to setup http connectors
  • Nexus maven repository location and parameters to setup auto updates
  • Logs parameters to setup logging level
  • Fop parameters to setup FOP processor
  • Specific application values

Moreover, each server has no direct knowledge of enterprise data or applications. We can imagine servers as stateless computers that will load it's OS from a remote device.

When started, a server will take the URL, username and password of a central configuration database to boot from it. The bootstrap steps are:

  • Acquire a connection to wic_conf database on primary database server.
  • Startup primary context and it's services.
  • Startup REST services
  • Startup soap context if enabled
  • Startup cron tasks
  • Setup the login procedure according with configuration.
  • Keep waiting for user access or automatic jobs.

System Metadata Overview


4.1 Configuration database (wic_conf)

Each server loads all application specific information from a centralized database, commonly named wic_conf. This information contains:

  • Application users and it's roles (wic_user, wic_user_roles, wic_user_groups)
  • Database users (wic_database_group)
  • Database servers (wic_database_server)
  • Databases on each database server (wic_database_object)

4.2 Root application dictionary database (wic)

Axional Studio it's built on a metadata driven architecture. Metatada is stored in a set of database tables we call a dictionary. Each application has it's own dictionary database. And the application to manage application design it's a dictionary itself.

The root dictionary it's called wic and contains the application development environment. The usually contains:

  • Data Defintion Language (wic_table_object)
  • Data Modeling Language (wic_xudf_object, wic_xudp_object, wic_trig_object)
  • Business process logic (wic_xsql_object)
  • Application objects (wic_jrep_object, ...)
  • Application panels and menus (wic_jtab_object, wic_jmnu_object)

4.3 Configuration application dictionary (wic_admin)

This database stores metadata required to configure wic_conf database.

5 Application metadata

As described earlier, Axional Studio relies on metadata dictionaries to describe an application. A database dictionary is a group of tables that stores the metadata of an application. Every logical database object that Axional exposes is internally managed using metadata. Objects, (tables in traditional relational database parlance), fields, stored procedures, and database triggers are all abstract constructs that exist as metadata.

  • This metadata will be materialized during application deployment so physical database structures will be created, database business logic will be compiled.
  • During runtime, the application description metadata will be used to materialize application views, forms or reports.