LOGO
Forgot password? | Register
Language icon English ▽


Architectural concepts

WEHIUS – is an Internet service, which changing the approach for building of various Internet and Intranet IT solutions. In opposite to the traditional CMS systems, where core CMS logic and entire business logic of the solution are combined together in one single bundle on single server (or on each of the servers from the farm), we are implementing and approach, where core CMS capabilities residing with one single point – the WEHIUS and your IT solution (web site or anything else) consists only of modules, required to manage business data (what not always a case of necessity) and present it to the data consumers (site visitor or some other IT system).

Let’s quickly compare how it works:

Phase Traditional CMS Our approach
0 Configure solution Done via administrative interface located on the same server. Each CMS has it's paradigm and you are basically limited with it. If you will need something more - you either dive into CMS code and basically "rewrite" it's core capabilities.After this (for clusterable CMS) - your configuration meta data is spread across similar servers, linked into one cluster. Done via single WEHIUS administration point, where you can immediately able to reuse all public templates, modules and dictionaries or just from your laptop (for files content, templates, etc.). All configurations are separated across logical environments (like development - testing - productive), which you create. WEHIUS kernel performs all possible pre-generations and automatically pushes on any number of your servers from particular environment pure business code, integrated with template part.
1.1 Parse request from the user Request usually received by single point-of-entry, which parses and analyzes it first. When it is determined which modules should take part in page preparations starts a complicated process of querying of configuration meta data from the database. Nothing here. It had already been done once.
1.2 Query data or perform other business logic On previous step set of required business logic procedures had been determined from the configuration meta data analysis. Now CMS is performing business logic and merging of template with business logic results. Entire process consists only of execution of business logic and pushing static content and dynamic business logic results back to the requestor.
2 Provide the result to the requestor Result flow of data is sent to the requestor based on server and network technology capabilities. Result flow of data is sent to the requestor based on server and network technology capabilities.

In order to get more understanding on particular approach aspect, it's advantages and disadvantage - you are welcome to read our help pages or send us a question.