|
|
|
|
Controller is a part of a larger system - hosting services provider's control panel. In the view of Controller successful functioning, it should be able to interact with other CP components, which can be generally outlined as follows:
For better understanding Controller, we distinguish the following Controller's functional parts:
Packages Repository Manager
Storing information about application packages that can be instantiated is the obligatory condition of the whole Controller functioning. We call such 'storage' of packages metadata a Repository, regardless of what form it can take in a particular Controller implementation. What's important is that a Controller must have such structural part capable of storing information about all instantiatable packages.
Besides information on instantiatable packages, the Repository should also store the following:
We call the Controller's functional part performing any operations on the Repository level the Packages Repository Manager. We refer to it when talking about actions that a Controller performs on application packages, as opposite to actions on application instances. Therefore, Packages Repository Manager must interact with control panel user interface. Refer to the Functions section for details on Controller actions.
Instances Processor
We call the Controller's functional part performing any operations on the hosting environment level the Instances Processor. We refer to it when talking about actions that a Controller performs on application instances, as opposite to actions on application packages performed by Packages Repository Manager. Refer to the Functions section for details on Controller actions.
Instances Manager should store the following information:
Instances Processor must interface into the hosting environment part responsible for managing sites and virtual machines, which we called Hosting Environment Manager just to designate the function. A Hosting Environment Manager is supposed to provide all control panel functionality related to hosting sites: creating and removing virtual hosts, setting limits on system resources used by hosts, enabling, configuring and disabling various services on sites, and so on.
Metadata Parser
Package Metadata Parser is the obligatory functional component of a Controller capable of parsing package metadata files, understanding and validating them in accordance with the rules of basic metadata format defined by the Specification, and then passing it for the following processing. The basic format of a package metadata file APP-META.xml is defined by the Specification in a set of RELAX NG XML schema files which should be used by Metadata Parser.
Metadata Parser is involved in all Controller operations and is invoked by either Packages Repository Manager or Instances Processor. This Controller component doesn't need any interactions with any control panel parts.
Aspects Parser
Aspects Parser is another Controller's obligatory functional component which is capable of analyzing aspects-specific data contained in the APP-META.xml files and passing it for the following processing back to Instances Processor, Repository Manager or a particular technology configurator. This is the data about application requirements, files handlers and permissions, and the configuration script interpreters. The Aspects Parser operates basing on the rules of data format defined by aspects.
Aspect is an additional specification that declares how a web application's specific need (technology) must be described in packages, and how these descriptions must be processed by Controllers. The aspects common for the most of web applications, such as PHP aspect, ASP.NET aspect, database aspect, etc., are included in the Specification in section 7. Common Aspects.
Aspects are considered as an open and extensible part of the Specification, since an application can use technologies other than those described by the common aspects. If an application uses such technologies, each must be defined by the corresponding additional aspect. So, when creating the Aspects Parser, consider making its 'knowledge base' easily expandable, considering that, later on, you Controller might deal with the packages that use some additional, unknown aspects, which must be painlessly and quickly added to the Aspects Parser's knowledge base.
