Axional Studio is a
3-tier framework specifically designed
for the development of large-scale,
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.
RESTservices, to deploy
JAX-RS(JSR 311 & JSR 339) endpoints or clients.
SOAPservices, 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 grammarsfor Data Modeling Language (DML), a database-independent SQL sublanguage.
XML DDL grammarsfor Data Definition Language (DDL), a database-independent SQL sublanguage. Also used to compile business logic (procedures, functions, and triggers).
XML scriptingfor 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.
Axional Studio applications rely on database metadata for
their development, configuration (including business logic, scripts, etc.),
Axional Studio requires an Infrastructure metadata enviroment which includes, at minumum, 3 databases, all supporting
- 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
split into two dictionaries, named
scm, to split development of financial
and supply chain management applications.
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.
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.
webapps, WAR files are necessary to deploy applications in the container.
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.
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
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.
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
- Highly physically integrated (shared) -
A single database instance has a database schema for each tenant, all of which share application servers.
- Medium physical integration - Each tenant has its own database instance, but all tenants share application servers.
- Low physical integration (not shared) - Each tenant has its own database instance and its own application servers.
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.
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.
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.
Axional Studio supports a wide variety of database engines and multiple database topologies.
- For low-level JDBC functions,
Axional ServerJDBC pool implementation.
- For high-end database functions,
Studioprovides developers a wide set of
XMLscripting features and
SQLsyntax to make native code implementation more transparent.
XML to SQL grammarA key point of
Studiodesign is its ability to handle all
XMLsyntax, 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.
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
DDL & DML CompilerBuilt in
DML, compiler tools are included to either deploy or verify metadata definitions in a target database.
spatial supportis available for both spatial data types and spatial functions.
|IBM DB2 Linux|
|IBM DB2 400|
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.
Transaction handling is automatically handled by application infrastructure. Specific XSQL tags can be used to perform block commits.
An OLAP engine is integrated in the system and can be accessed either programmatically (using XSQL tags) or by user interface components.
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
read only, the operation will be redirected to a
read only replicated database pool.
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_confdatabase 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 OverviewLoading...
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)
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 Languaje (wic_table_object)
- Data Modeling Languaje (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)
This database stores metadata required to configure wic_conf database.
As described earlier,
Axional Studio relies on
metadata dictionaries to describe an application.
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.