Illustrated in Figure 5.1, “Theon Architecture (Private Installation)” is the architecture of a private installation of Theon. This would be where a user has Theon installed on their own personal desktop to manage their own databases for private use, or to manage private development instances of production databases for making and testing changes. With everything running on one host, and no authentication aspects to consider, the architectural overview is simpler to describe. A private installation like this is the "out of the box" configuration for Theon.

Figure 5.1. Theon Architecture (Private Installation)

The User Database running under PostgreSQL has a Schema defining it (and held in the PostgreSQL system catalog). TheonModel is used to maintain this Schema externally. This can be done manually or by importing changes made directly to the Schema in PostgreSQL, or more commonly both approaches. TheonModel has its own system catalog like database the Model Database (or XSDDB) also held in PostgreSQL. Since this also has a Schema of course TheonModel is used to maintain that within itself. TheonModel also holds information in its Model Database on how to present the content in the User Database via TheonUI and how to synchronize external data into the User Database via TheonCoupler. These are the meta data flows shown on the diagram (data for the Schema, TheonUI and TheonCoupler).

The internals of TheonModel itself are discussed in <<>>.

There is no significant architectural difference between a private installation and a live production multiuser service. The diagram below illustrates a production service. The only practical difference is that each aspect of the service runs on a different dedicated host, as does the user’s browser session (which runs on their own client) and the developer session (which also runs on their own client, with a snapshot of the data and live services to allow testing). The development version is then deployed onto the live services, usually via a packaged release.

Figure 5.2. Theon Architecture (Service Installation)

While the service architecture above shows all the services completely devolved onto individual hosts, this is not a requirement. Everything can run on a single host (except normally the user/developer client environment and browser) or separate dedicated hosts or any combination inbetween. Normally the PostgreSQL database service and TheonCoupler (the backends) would share a host and TheonUI (the frontend) if being used would share a host. The splitting of services across multiple hosts is done to enhance service performance, robustness and security, but this all depends on individual site requirements. The diagram below shows possible combinations - however all of them show the backends combined on one server.

Figure 5.3. Theon Architecture (Services Combinations)

Finally a simplified production service environment is shown in the next diagram. This illustrates support services that are not a core part of Theon but which would nevertheless be expected in a production environment. The only aspect of the service with master data is the live PostgreSQL database with user content.

Figure 5.4. Theon Architecture (Production Environment)

Note that Theon is only necessary for development. Site deployments of a model only require a simple packaged release of TheonTK and the model and the corresponding production services, they would not need the local development environment.