The DIB server components

The main server components of the DIB core platform is visualised below:

DIB contains a number of servers where some are singletons meaning then can only be installed once on a server (virtual or physical) environment. Others can be installed several times depending upon the need a specific setup needs to serve. Shortly each server can be described as follows:

Server Description
Autorunner The autorunner server starts all the other DIB-servers. In case a specific DIB server stops e.g. due to infinity use of CPU the autorunner will automatically restart that server. Also it will output information from the specific server potentially having problems. It will also show information from servers just running smoothly. It also means that in case a customer of DIB wants to have the DIB system included as a service (in windows) or a crontab job (Unix) it is only needed to call the autorunner. The DIN-installer program can handle up to 5 autorunners:
  • Autorunner: This is starting up what we call production servers including the the Portal and the proxy, which both are singletons
  • Autorunner1: This starts test servers.
  • Autorunner2: This starts demo servers
  • Autorunner3: Open for use
  • Autorunner4: Open for use
Autorunner is a web-aplications and a typical screen looks like the following:
There can be as many autorunners configured as needed, but the DIB install program only handles up to 5.
Proxy Each DIB server is configured to run on a different port, but the outside DNS will only points to the IP address without the port. The proxy is redirecting the request to the appropriate port. E.g. distributo.domain.com could be redirected to http://localhost:50030. Normally we say that ports between 50000-50500 are reserved for use to DIB stuff. More about this is found under installation of DIB. The proxy is a singleton meaning only one instance can run on the server
Portal The portal is the first screen a user sees to login to DIB environment. The portal authenticates the user and most likely the portal is connected to a LDAP server. We also provides authentication services through Google and Facebook. There is basically only two screens in the portal - the login screen and the screen showing which other DIB servers the user have been configured. Which is based upon which organisation/group he/she is a member of.
. The proxy is also a singleton meaning only one instance can run on a server (virtual or physical) .
Architect The architect is the DIB design tool of inapp and related server applications for when inapp submissions are received. For storage the architect uses mongoDB as well as the filesystem. In principle you can as many architect servers installed as you like, but in general is tha only DIB-Architect is installed. The archiect is always connected to one processing, which normally in an installation is called the DIB-procarch processing server. The processing is generating all the output that is needed for the builder as well as distributor. Below screensshot is the main screen of the DIB-architect.
Builder The builder is sometimes also named the compiler of the DIB environment.This is where the user points to a specific set of data to be build. This data is normally XM and JSON based content. Then the builder outputs what we refer to as an inAPP which is an HTML5 based application which either can be executed in WEBbrowser or it can run within the DIB app. The builder relies on an Open Source product callled DITA-OT. This product is the key component and is configured to handle content coming from the DIB-Architect or potantially from other sources. And because there currently is 3 different versions of DITA-OT and builder can only connects to one the builder is normally named Builder1, Builder2 or Builder3. The configuration of the DITA-OT are tied into a package we name DIBOT1, DIBOT2 or DIBOT3. A typical screen shot from the builder:
If builder returns no errors after compilation the user can verify the result in the builder and in case he/she likes what seen they can promote the inAPP to one or more distribution servers.
Distributor The Distributor is a key server, because it is the one that is commicating with DIB-APP or with browser based inApps. The Distributor is also connected to a processing server we normall call ProcDist, which is processing all incoming data coming from the mobile/remote applications. Also it is the Distributor that is sending notifications to mobile devices. Below is a screen show from the Distributor showing data for one inApp.
The Distributor is using Mongo database.
Warroom The Warroom is closely connected with Distributor because it is a data aggregation for data collected in the Distributor. It is a server which can render data on large monitors as an example. Below is example of data rendition within the warroom.
Mapping The mapping server is a program which can generate recipes to convert Excel into inAPP json files. Besides being able to specify the recipe it is also possible to let the mapping execute the conversion.
IOT server The IOT (Internet Of Things) server is enabling IOT devices to interact with the DIB enviroment.
ATA Stager ATA stager is server that is able to convert Aerospace technical content into data to be ready to be build into mobile InApp within Builder2. This server does not have any interface and is normally started via the processing through the watcher or it is just started manually.

The servers within the DIB environment can be setup and configured in many different ways so it is accommodate specific needs a host must have. The following topic show different setups.