Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Since Composable Architecture Platform has the ability to dynamically apply software updates without requiring a restart of the application server, and with different users using different versions of the same application; there are some unusual considerations with regards to the console’s deployment structure.
Firstly, the web application installed under the application server path is purely an application loader. The application loader in turn finds all of the required files and executable code under a folder designated as the file location in the web.xml file for the console application.
The file location referenced is typically under the Composable Architecture Platform console home folder in an Applications sub-folder. Below that folder in turn, you can find multiple builds (as they are installed by the update server). Those builds largely conform to a typical web application structure.
The system requirements for an installation of Composable Architecture Platform vary depending on the load and uptime requirements.
The minimum requirements for any console server are:
1GB of memory (2GB recommended)
1 GHz+ processor (3GHz dual-core recommended)
10GB of free disk space
The minimum browser requirement for any client attached to the administration console is:
Microsoft Internet Explorer version 11.0 or later
Microsoft Edge version 20 or later
Mozilla Firefox version 40 or later
Google Chrome (any version)
Other browsers may work but may encounter issues.
The minimum requirements for any application server using the in-line filter installation are:
A Servlet Specification 2.3 (or later) compliant servlet engine
JDK 6.0 or later.
Note: You can install more than one X Engine on a single piece of equipment. You only need one instance of an application server and database for each installation.
The minimum requirements for a feed server are:
1GB of memory (2GB recommended)
1 GHz+ processor (3GHz dual-core recommended)
10GB of free disk space
The minimum requirements for a built in forwarding proxy are:
1GB of memory (2GB or at least 10% of protected server capacity recommended)
1 GHz+ processor (2GHz or at least 20% of protected server capacity recommended)
50GB of free disk space
The Composable Architecture Platform Server installation is a complete product set including sample applications. At times you may wish to remove components that you don’t use in a given installation. The easiest way to do this is by changing the server type in the console setup:
You can only change the server type once as it involves deleting several components in the server structure. There are 5 different Console types to select from as shown below:
The effect of changing the Console type is as follows:
Type
Effect
Demo Server
None
Console only
All applications (including the forwarding proxy) are removed from the server. The only items left are the console itself and the test server.
Forwarding Proxy with console
All demo applications are removed. The only remaining items are the console, the proxy and the test server.
Forwarding Proxy without console
All demo applications as well as the console and the test server are removed. The only remaining active item is the proxy.
Cluster Slave Console
All demo applications and the forwarding proxy are removed. All repositories are removed, and the data folder is cleaned.
A cluster slave instance has a number of unique properties, the most significant of which is that no repositories are allowed.
To set up a cluster slave console, install a clean Composable Architecture Platform instance and start it up. Log in as admin and click on the Console setup function:
Change the Console type to Cluster Slave Console. You will receive a warning:
Click on OK to accept the change. There is now a new Slave tab showing:
Enter the URL that you would normally use to access the master console (we recommend using HTTPS). You also need to enter the ID by which the slave console is going to be defined in the master console and the password:
Then click on Save:
You will receive a further warning:
Click on OK. An information box appears:
Click on OK. Your console will go gray and the slave console server will terminate. Make sure you restart it to complete the process. Restarting it will result in applications (such as Qwerty, the Test Server and so on) being removed from the installation.
You can verify that the slave console installed correctly by logging into it as normal. You should see a cut down console with the ID of the slave console shown in the header:
At this point you can now turn to the master console and create a new Cluster Node definition as described earlier in this manual. If the cluster shows up as available in the master console and you can maintain it from there, then you should now log out of the slave console and reset the passwords for all of the built in user accounts (admin, super and security) using the forgot password feature. There is no need to have normal user access to a slave console.
The next step is to create a new server definition for each server that is attached to the slave. The slave will automatically detect the status of each of those servers and will ensure that the rules are synchronized with the master and that the X Engine state (started/stopped) follows the desired state as decided in the master console.
Whenever a change is made to the source repository in the master console, those changes are automatically deployed to the slaves and subsequently to the servers defined within each slave.
If it is intended to co-locate master and slave consoles on the same server (by using different ports), then you MUST create an individual server name for each slave. The best way to achieve this is to set an entry in the systems HOSTS
file for each slave. Failure to follow this step will result in the transfer from the master console to the slave console causing a log-out on the master console.
This document describes how to run Composable Architecture Platform using the Tomorrow-Software-Server-2021-noJRE-10.0.0.zip
distribution for a macOS environment. This example is using macOS Catalina 10.15 and JAVA JDK 14.
macOS capable of running JAVA JDK 11+
JAVA JDK 11+
Tomorrow-Software-Server-2021-noJRE-10.0.0.zip (or other approved) distribution for Composable Architecture Platform
Chrome browser
Root user access permissions
JAVA environment - Composable Architecture Platform requires Java v11+ JDK Runtime Environment to run so check if Java is installed and the Java running version.
The Composable Architecture Platform installation uses the open source Jetty application server.
Enable macOS root user - To run Composable Architecture Platform on macOS, the "root" user needs to be enabled. If the root user has previously been enabled, the root user password will be required. To enable the root user, please follow the instructions at the following Apple support page:
https://support.apple.com/en-us/HT204012
Will either return “command not found” when no Java installation has been installed or display the current Java installation details.
e.g. Java version details