|
|
|
|
Conditions
# The Control Panel has GUI.
# The Controller is implemented so that it fully validates packages when they are added to Repository, including that it checks if a package uses additional aspects unknown to the Controller, and so on.
# The Controller is implemented so that it stores all information on application package and its instances installed. It ensures access to application package for its instances while at least one instance exists.
# The Control Panel is implemented so that the directories tree rooted in a directory devoted to the web site content represents the URL structure of the site as it is accessible from the Internet.
Starting Point. User initiates instantiating a package on a particular site.
Step 1. The Controller parses application metadata file APP-META.xml extracts and organizes all information about the package. (Hereinafter, we will refer to this resulting information as to application information.):
Step 2. The Controller determines the service requirements and checks if the server and the site are capable of satisfying them.
Sub-step 2.1. Gets the information about service configuration script ("/service/provision/configuration-script/script-language") and checks if there is an appropriate interpreter in the system and it can be used on the site to run the configuration script. If the package contains no configuration script, instantiating continues normally.
Sub-step 2.2. Gets the information about the service size when it is installed ("/service/provision/url-mapping/installed-size/") and checks if the site has the amount of free disk space enough for installing the service.
Sub-step 2.3. Gets the list of service requirements ("/service/requirements") and checks if the current site hosting conditions allow satisfying all the requirements from the list (for example, if the scripts support is enabled for the site, if the usage of such databases is allowed on the site, etc.). On this step, the Controller does not satisfy any of the requirements and does not allocate any resources, it just checks if all these actions are possible.
Here, the Controller creates a list of application requirements and hosting capabilities matching. It processes the requirement elements, comparing them with the hosting capabilities one after another. For each requirement, the Controller creates a kind of block with the true|false values defining if the requirement can be satisfied. Then the Controller puts the resulting blocks into the logical expression, basing on the requirements structure within "/service/requirements", and computes it.
If the result is false, the Controller stops installing the application and returns to the user a list of requirements that cannot be satisfied.
If the result is true, the Controller creates a CHOICE_<id> variable for each requirements combination ("choice/requirements") which can be satisfied. If a requirements choice contains several satisfiable combinations, the Controller creates a variable for each, and groups them in order to give the user later a chance to choose which of these combinations to satisfy. For example, the application requires either MySQL or PostgreSQL database, and the hosting allows creating both. In such case, the Controller allows a user to choose what database he wants to be used by the application, see the Sub-step 4.2.
Step 3. The Controller checks if the service has an end-user license regulating the service usage ("/service/license"). If it has, the Controller creates a screen displaying the license text. If there is the must-accept= attribute in the application information, the screen contains the I agree to the license terms (...) checkbox and the submit and cancel buttons, and the Controller continues instantiating the package only if the user submits the selected checkbox. "true"
Step 4. The Controller generates the screen with the installation configuration form.
Sub-step 4.1. Gets the list of all service settings within the "/service/settings" element. The Controller then creates a list of elements that the form will contain so that the user could enter the required settings values. For each setting data type the Controller makes the corresponding form element (text box, drop-down menu, etc.), adds to each element a label and tooltip from the required locale, group the elements in field sets.
Sub-step 4.2. Selects from the requirements matching list the groups of satisfiable requirement combinations (if any) and creates the form elements (a drop-down list for each group) that allow the user to choose which of these combinations to satisfy.
Sub-step 4.3. Selects from the list of satisfied requirements ones that require additional data, and makes the form elements with which the user will specify parameters of the resource to be allocated. (For example, if an application requires a database, the configuration form contains text fields for entering database administrator's login, password, password confirmations, etc.)
Sub-step 4.4. Makes the form elements with which the user will specify the application installation directory (site root relatively).
Sub-step 4.5. Collects the information on all the form elements made on the previous sub-steps and generates the screen.
Step 5. As the user enters the required information and submits the form, the Controller gets the submitted application data and validates it.
Sub-step 5.1. Validates the block of requirements-related data. For example, if creating a database, the Controller checks if a databases with the name same as the entered one does not exist. If any of such checks fails, the Controller adds a message about it to the error stack.
Sub-step 5.2. Checks if the installation directory specified by the user does not exist. If the directory exists, the Controller adds a message about it to the error stack.
Sub-step 5.3. Validates each application setting value basing on the settings information from the package metadata. If an invalid value is set, the Controller adds a message about it to the error stack.
Sub-step 5.4. Checks the state of the error stack. If it contains any messages, the Controller returns to the Step 4: generates the installation form again adding to it the error stack's content. If the error stack is empty, the Controller continues to the next step.
Step 6. The Controller further processes the installation data entered by the user.
Sub-step 6.1. Satisfies the service requirements: enables scripting support on the site, allocates all the required resources, and stores the information about them (for the purpose of future deallocating or re-allocating).
Sub-step 6.2. Prepares all the necessary environment variables.
Step 7. The Controller deploys the application files to the site location defined by user, following the instructions defined in the "/service/provision/url-mapping". The Controller properly copies the files and performs the actions required to set URL handlers and permissions. While deploying the application, the Controller prepares the required mapping-related environment variables, and records the information on each directory where the application files are copied. When finished deployment, the Controller saves this information for the purpose of future application upgrade or removal.
Note: application web access is configured, but not activated.
Step 8. The Controller gets the application global configuration stored in the Repository, analyzes it and prepares global-configuration environment variables.
Step 9. The Controller invokes the service configuration script to configure the service instance.
Sub-step 9.1. Gathers all the information about environment variables prepared on the previous steps, and creates the variables basing on the rules defined in the Specification.
Sub-step 9.2. With the interpreter determined on the Sub-step 2.1., the Controller runs the configuration script in the environment where all the environment variables created on the previous sub-step are defined.
Sub-step 9.3. If the script invocation succeeds, the Controller displays to the user the screen with the successful instantiation message and congratulations.
Step 10. The Controller behavior on this step depends on whether the previous step was completed successfully.
Step 10.1. If the previous step was completed successfully, the Controller performs the following post-installation operations:
Step 10.2. If the previous step was completed with an error, the Controller rolls back all the changes it made to the system and the site, displays the error message to the user, and returns to Step 4. Rolling back the changes implies removing all application files copied to the site, and releasing all allocated resources.
