Innomatic supports multi-tenancy by architecture and there is a separation between Root mode and the single tenants mode.
In particular, the root mode is when Innomatic is executed without starting a tenant (eg. when administering applications and tenants in the root desktop).
The main strategy for separating tenants in Innomatic is multi tenancy at code level and single tenancy at database/data access level (a database for each tenant, plus a centralized root database). By default, inside Innomatic there are no hard coded limit at how many tenants can be created.
However, when used as an enterprise application platform for a single company, multi tenancy may not be a requirement. In that case, Innomatic is still suitable as an application platform with its enterprise level features and there is no need to create different databases for Innomatic root and the single tenant.
Multi tenancy can be disabled during Innomatic setup, so that a single database is created. When in single tenant edition, Innomatic allows the creation of a single tenant. Also, installed applications are automatically enabled to the unique tenant (this is different from the multi tenant edition, where applications must be manually enabled to each desired tenant).
Once installed, there's no way to change the single/multi tenancy setting without consequences.
This graph displays the platform internal organization and packages, from the lowest level to the higher one. It doesn't show the applications and domains organization and relations, shown in the following graphs.
The surface area (the one visible to the users) is the Innomatic Desktop, built over the web application handler and some of the common application frameworks (widgets, themes, MVC and dispatching, all part of the WUI = Web User Interface).
Web Application Server
General application server flow
General flows of a web app in Innomatic, among the various tiers (web, business logic, integration), and how it should be organized:
Innomatic Desktop application server flow
Specific flows of the Innomatic Desktop:
Applications and Tenants
This graph shows the relations between the Root Container, the Innomatic Container, the Tenants (also called Domains), the Applications and the Web Apps.
An Innomatic Application is an application deployed inside the Innomatic Web App by the Innomatic administrator. Innomatic Applications may define dependencies with other Applications. Once installed, an Innomatic Application is not useful if it is not enabled to one or more Tenants, with the exception of Applications enhancing in some ways the Innomatic platform or providing root administration panels.
An application bundle is an archive containing multiple applications archives bundled together.
Applications may support options that are enabled/disabled at tenants level.
A Tenant is a virtual set of applications that are enabled to a particular organizational entity (that may be your own company, a customer, etc.) legally or in another manner conventionally separated by the other entities. You can have more than a Tenant inside a Innomatic installation, if you have chosen the Multi Tenant Edition during the Innomatic setup, while in the Single Tenant Edition you can create a single Tenant only (useful if you use Innomatic for your company only).
Each directory inside the Root Container is a Web App, that is a set of files that, through the Web Application Server, are served to the web users. Web Apps are handled by the Web App Handlers. Each Web App must have a web.xml file defining the mappings between the HTTP requests and the Web App Handlers (a Web App may use more than a Web App Handler, eg. one for AJAX requests, one for standard requests, etc.).
The Web App directory is WWW public and can be thought as a web site document root. It contains a “core” subdirectory, that is WWW private, with the Web App web.xml file.
A Web App is not required to be a Innomatic Tenant, it may take advantage of the Web Application Server component only, but for each Innomatic tenant a Web App is always created with the same name of the tenant.
A Web App is the feature most similar to a common PHP framework.
Tenant Web Apps
As already stated, tenants are not web sites, nor the tenant Desktop is one. However, a public frontend to a tenant (just like a web site) could be made available through the tenant Web App, created inside the Innomatic Root for each tenant.
When creating a tenant, you are asked to define a Web App structure: Innomatic provides the “Default”, “Customized” and “PHP” predefined structures, but other Applications may provide new Web App structures. A Web App structure is a Web App directory skeleton with a predefined web.xml file already mapped to certain Web App Handlers. You can also use external frameworks as Web App handler and, thanks to the Web App handler mappings, you can also use multiple frameworks inside the same tenant Web App.
The “Default” structure is only able to serve static HTML files; the “Customized” one lets the Web App developer to define itw own structure without it being overwritten by Innomatic; the “PHP” one is able to serve standard PHP files.
A more powerful usage of the concept is, for example, the one provided by Innomatic based content management systems. An ideal CMS, like Innopublish, would provide the administrative panels for the site management inside the tenant Desktop, while, through its own Web Application Handlers, would serve the WWW public pages inside the related tenant Web App.
Innomatic Web App
The Innomatic Web App is a particular one, because it contains the whole platform code and always exists. The Root Container and the Web Application Server code are phisically located inside the Innomatic Web App. You can refer to the previous graph to get an idea of how Innomatic Web App code is organized.
Inside the Innomatic Web App you can manage Innomatic tenants and Innomatic Applications.