CMS Ametys consists of 3 applications:
The 3 applications can coexist on the same server, and each can also be installed on a different hardware platform.
The back-office application is accessed by contributors for modifications to the various content managed by Ametys. It takes the form of a web application deployed on a Apache Tomcat application server.
The front-office application is accessed by visitors to websites. It takes the form of a web application deployed on a Apache Tomcat application server. Its main function is to manage a cache of all resources requested by users. Resources not present in the cache are requested from the back-office application.
The indexing and search application, based on the Apache Solrtool, is started up independently of the other applications. It is not accessed directly byAmetys users, but in the background by the back-office application.
The Tomcat servers are usually accessed via a reverse proxy, often set up in conjunction with the Apache HTTPD server.
Page requests from users are received by Apache. Apache serves static files such as CSS, images, non-dynamic pages... and redirects other requests to Tomcat.
Back-office and front-office communication is carried out in both directions via web-services:
If the back-office and front-office are installed on the same server, they can be run either on a single server Tomcat or on two Tomcat separate servers.
CMS Ametys manages several "data sources". A standard installation follows the following architecture:
Databases are not necessarily located on the same server as applications. However, for performance reasons, it may be advisable to have at least the JCR repository placed on the same machine as CMS.
The CMS application references at least two data sources:
The front office can use one or two databases SQL :
Users and groups
Whether in the front or back office, the location of users and groups depends on the implementations chosen.
CMS Ametys allows you to choose other implementations, for example LDAP.
In the background is the Solr application, in which all data is indexed. This application enables efficient searches with multiple criteria and faceted management.
Only the back office uses this application.
A request (page request or search) launched on the front-office (site) follows the following flow:
When modifications made on the back-office side (CMS) have an impact on site pages, the site sends a request to the front-office to partially or fully invalidate the cache.
The back office uses the followingURL schemes to talk to the front office:
_invalidate-site/*
_invalidate-page/*/**
_invalidate-images/**
where * = any character except '/' and ** = any character including '/'.
So if you want to prevent a component outside the application from clearing the cache, there are two solutions:
Notes and Recommendations
- The recommended HTTP server is Apache HTTPD.
- The recommended J2EE servlet engine is Apache Tomcat .
- The JCR implementation used internally is Apache JackRabbit .
- The recommended SQL database is MySQL. However, Oracle and Derby are also supported (PostgreSQL is incompletely supported at present).