First we describe the overall architecture and the data flow in a Wolframe application.
Wolframe is a 3-tier application server.
The presentation tier of Wolframe is implemented as a thin client. It maps the presentation of the application from the request answers it gets from the server. For some clients the data describing this mapping can also be loaded from the server when connecting to it. The whole processing ot the application is made by the server.
The logic tier of Wolframe defines the processing of application server requests and the rules for access control with the configurable mechanisms for authorization.
A client that logs in to the system passes an authentication procedure. The resulting authentication defines the privileges to execute functions or accessing resources (authorization). The chapter AAAA (Authentication,Authorization,Auditing and Accounting) will introduce the several aspects covered by Wolframe besides data processing.
A client that passed authentication can send application server requests to the server. A request consists of a command name plus a structured content also called document. The server returns a single document to the presentation tier as answer. Many different programming/scripting languages are supported to define the input/output mapping between the layers. Wolframe introduces three concepts as data processing building blocks for handling the server requests:
Filters: Filters are transforming serialized input data (XML,JSON,CSV,etc.) to a unified serialization of hierarchically structured data and to serialize any form of processed data for output. Filters are implemented as loadable modules (e.g. XML filter based on libxml2, JSON filter based on cJSON) or as scripts based on a filter module (XSLT filter script for rewriting input or output)
Forms: Forms are data structures defined in a data definition language (DDL). Forms are used to validate and normalize input (XML validation, token normalization, structure definition). The recommended definition of a command in the logic tier has a form to validate its input and a form to validate its output before returning it to the caller.
Functions: Functions delegate processing to the data tier (transactions) or they are simple data transformations or they serve as interface to integrate with other environments (e.g. .NET). Functions have a unique name and are called with a structure as argument and a structure as result. Functions can call other functions for delegation, e.g. a transaction definition can call a .NET function for preprocessing its input or a .NET function can call a Python function to do parts of the processing.
The chapter data processing will describe these building blocks.
The data tier of Wolframe defines the interface to the databases of the application. A transaction description is passed as a complete data structure to the database that returns the result of the transaction. The logic tier builds the result data structure out of this result and completes other actions defined as part of the transaction (like audit) before invoking the completion of the transaction in the data tier with a commit or rollback. All databases of the data tier are integrated with the same interface into the server. Nevertheless there is no unified database language involved and transactions can use proprietary language constructs of the underlying database. Wolframe supports many databases like for example PostgreSQL, Sqlite and Oracle and others can be added by just implementing the database interface as a loadable module.