Concept | Properties | Login | Demo | Contact


The software is an HTTP 1.1 application server. In a traditional three tier application server environments the software is a part of a middle tier. Software was programmed as a native program. Fast program saves server resources and uses for example process isolation to improve security. Every request renews the executing program process. The session attributes are stored in a separate session database. Each request starts three individual processes communicating with each other and each exits at the end of the request.


The application server has a property to add modules. The database connections are separate modules with the type integrity checking modules. Modules may be developed in different purposes and languages. The demo pages lists some available modules. These include a relational database module, SMTPS module to send email, a file module used to read a file, a tag module to write output to a file, and a security log module to write events in a log for example.



The consistency of the relational database attributes are ensured with a configuration file reproducing the relational model of the relational database schema. Attribute and the attributes it is dependent on are checked automatically by the software before the transactions to ensure the consistency of the database.


The application configuration of the attributes may be the same or similar of the relational database management systems. Usually the attributes have to be configured in more depth than in the relational database schema. Applications still have to be developed.



Authentication produces different roles to distinguish the end users of the application and this information is saved in a session database. These are the role -attributes and the roles can be used to allow and restrict the transactions of the application giving a possibility to group users into roles.


Error messages from integrity verification

The application sends error messages from the consistency and integrity verification: entity, dependency, type and role -integrity checks. The user can be helped to fill in the needed attributes and write the value of the attribute in the needed form of the attribute type with the messages.




Unicode contains the characters in the world. The 32 bit long UCS character codes can be transferred in UTF-8, UTF-16 and UTF-32 in big endian and little endian formats. Unicode provides enough support to internationalize the applications in all of the worlds languages. Additionally to these, the program has one byte presentation compatible with Latin ISO-8859-1 and ISO-8859-15. Scandinavian character encodings are possible if a one byte representation has to be configured. The type integrity tests can be used verify the content. The users who need to restrict the application to use only a one byte character system is able to do this. As a two and four byte representations additionally ISO-10646-UCS-Basic, ISO-10646-UCS-2 and ISO-10646-UCS-4 are available.

Constant encoding conversion

The program constantly converts character encoding from HTTP input encoding or if not set or known, from the program configured input encoding to the set database encoding. The result data character encoding is converted to the set output encoding or if otherwise requested in the HTTP request headers, to the requested encoding if it was found from the program capabilities.


MIME type

Output reports to a text file of one MIME type: HTML, XML, JSON or any.

Attribute values

Attribute values are added to the output text files with tags to mark the space in the output file. Either a tabular chart reporting can be used or printing of individual attributes with optional repeating as many times attribute values are available from the database transaction. Please see the user manual for more information.


Type checking

A custom type checking can be added to the configuration file of the attributes to check specific attribute value types before they are used in the database transactions. This ensures the attribute value integrity and keeps the relational database data consistent. Different types can be added with additional type modules.


Database connectivity

Different databases including the authentication of the users can be configured by adding a software module to the configuration file.

Access to multiple databases

Access to multiple databases are provided within the application URL:s. In an URL, multiple transactions may be configured in multiple data sources. The URL:s are configured in the transaction configuration file. A single transaction is supported or a series of transactions to the same database or to different databases at a time.


Authentication modules are added similarly. They should additionally authenticate and provide the role attributes for the application to know the authentication has been granted. The roles are added in the transaction configuration file. They are the results of the database transactions.


Use in parallel

Software can be installed in parallel in different server environments. Since the NoSQL -databases can be used to save the session data, the software can be used in parallel and serve heavy duty applications.

Software writable configuration files

Software is configurable with the known file format to automate the software deployment and the development in the cloud environments.

Encrypted session data

Session data is identifiable across different applications and different servers. The cloud may have different applications using the same session databases. The software uses cryptography internal to the program to encrypt the session attributes. This provides a more secure server network operation.


Atomic data stores

In some cases where the relational database is not available, or the relational database does not have a good design conforming to the normal forms of the relational database management systems or if the scope of the data is across multiple databases, the application software can be used to model the relational model of the attributes of the application and be used to replace the missing relational model of the information system.




Intel and AMD x86 processor family is well supported. ARM64 -computers are a native development environment and well supported. Other servers may be supported by an additional workload in porting the software.


The application server uses HTTP 1.1. The software may be used as is in embedded systems to create web user interfaces with a session database for example. Some information system installations may include more components like firewalls and secure socket layer web -servers and proxies.

HTTP or a reverse proxy

The software has HTTP support. To use HTTPS or other protocols (HTTP/3 or HTTP/2 for example) a reverse proxy (a proxy HTTP server) serving other web content and providing secure sockets layer to the application server may be needed in installations with the application server. The solution is modular and extensible. The application server is an HTTP application server.

Operating system support

The software may be ported in most UNIX operating systems. The application server was developed using FreeBSD operating system to provide good support in most UNIX systems (in AMD 64 bit, Intel 32 bit and ARM64 64 bit processors).

The versions available are Linux and FreeBSD versions. From FreeBSD 12 to the current version, Linux with Musl-C -library (Alpine Linux for example) or with normal Linux C-library (the most used Linux distributions). IPv6 address support is added and available in the future in the application and the application modules. In installations IPv6 may be available from the web proxy service.


Applications have to be developed by adding the attribute descriptions, SQL-statements and URL-definitions with web-pages and other content.

Domain integrity

The application programmer has to ensure the domain integrity of the attributes. This is usually done in the SQL statement WHERE clause (the join operation). The application programmer may use the role attributes to ensure the identity of the user and the web browser the user is using to identify the attributes. Different modules may provide the role attributes, database module for example or a separate authentication module.

Uniqueness of the keys

The uniqueness of the keys have to be provided by the application developer. The keys are the identifying attributes or the roles in the session database identifying the attributes, for example the user of the application.


Atomic transactions

The data storage should provide atomic transactions. The transaction should consist of attributes of only one table and the attributes should be in a relation to each other as in the relational model. A relational database is needed.


Session database connection

Session attributes are encrypted in the session database of the software concept using Threefish 512 bit encryption algorithm. Still a firewall or other computational method may be required in between the session database and the application server to protect the data or the service especially if the service is critical.



© Copyright 2016. All Rights Reserved.