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.

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.

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.

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.

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.

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.

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.

• Highly physically integrated (shared) - A single database instance has a database schema for each tenant, all of which share application servers.
  Loading...

  graph { graph [fontsize=10 fontname="Verdana" compound=true]; node [shape=record fontsize=10 fontname="Verdana" style="filled"]; edge [color=gray]; overlap=scale; splines=ortho; internet [fillcolor="red" shape="oval"] t1 [label="Tenant 2" fillcolor="#CDDC39" shape="circle"] t2 [label="Tenant 2" fillcolor="#CDDC39" shape="circle"] t3 [label="Tenant 3" fillcolor="#CDDC39" shape="circle"] s1 [label="Service" fillcolor="#FFC107"] s2 [label="Service" fillcolor="#FFC107"] s3 [label="Service" fillcolor="#FFC107"] application [label="application\nservers" fillcolor="#99ccff"] database [label="database\ninstance" fillcolor="#CFD8DC"] db1 db2 db3 t1 -- internet t2 -- internet t3 -- internet internet -- s1 internet -- s2 internet -- s3 s1 -- application s2 -- application s3 -- application application -- database database -- db1 database -- db2 database -- db3 application }
• Medium physical integration - Each tenant has its own database instance, but all tenants share application servers.
  Loading...

  graph { graph [fontsize=10 fontname="Verdana" compound=true]; node [shape=record fontsize=10 fontname="Verdana" style="filled"]; edge [color=gray]; overlap=scale; splines=ortho; internet [fillcolor="red" shape="oval"] t1 [label="Tenant 2" fillcolor="#CDDC39" shape="circle"] t2 [label="Tenant 2" fillcolor="#CDDC39" shape="circle"] t3 [label="Tenant 3" fillcolor="#CDDC39" shape="circle"] s1 [label="Service" fillcolor="#FFC107"] s2 [label="Service" fillcolor="#FFC107"] s3 [label="Service" fillcolor="#FFC107"] application [label="application\n servers" fillcolor="#99ccff"] database1 [label="database\ninstance 1" fillcolor="#CFD8DC"] database2 [label="database\ninstance 2" fillcolor="#CFD8DC"] database3 [label="database\ninstance 3" fillcolor="#CFD8DC"] t1 -- internet t2 -- internet t3 -- internet internet -- s1 internet -- s2 internet -- s3 s1 -- application s2 -- application s3 -- application application -- database1 application -- database2 application -- database3 application }
• Low physical integration (not shared) - Each tenant has its own database instance and its own application servers.
  Loading...

  graph { graph [fontsize=10 fontname="Verdana" compound=true]; node [shape=record fontsize=10 fontname="Verdana" style="filled"]; edge [color=gray]; overlap=scale; splines=ortho; internet [fillcolor="red" shape="oval"] t1 [label="Teenant 2" fillcolor="#CDDC39" shape="circle"] t2 [label="Teenant 2" fillcolor="#CDDC39" shape="circle"] t3 [label="Teenant 3" fillcolor="#CDDC39" shape="circle"] s1 [label="Service" fillcolor="#FFC107"] s2 [label="Service" fillcolor="#FFC107"] s3 [label="Service" fillcolor="#FFC107"] application1 [label="application\n server 1" fillcolor="#99ccff"] application2 [label="application\n server 2" fillcolor="#99ccff"] application3 [label="application\n server 3" fillcolor="#99ccff"] database1 [label="database\ninstance 1" fillcolor="#CFD8DC"] database2 [label="database\ninstance 2" fillcolor="#CFD8DC"] database3 [label="database\ninstance 3" fillcolor="#CFD8DC"] t1 -- internet t2 -- internet t3 -- internet internet -- s1 internet -- s2 internet -- s3 s1 -- application1 s2 -- application2 s3 -- application3 application1 -- database1 application2 -- database2 application3 -- database3 }

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.

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, 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.

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.

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 observed as 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_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.

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 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)

This database stores metadata required to configure wic_conf database.

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.