The RHQ Platform provides infrastructure for the development and integration of management functionality for products. The primary design is a core abstracted inventory model and several subsystems for integration of product specific elements in a standardized model. The platform also includes infrastructure for these subsystems and broader extensions into unspecified areas of functionality. By utilizing a common model and inventory the platform delivers more possibilities for integration between products and better efficiency in the development of common functions.
The primary goal is to provide the necessary elements of management that typical independent management products reproduce repeatedly. Elements such as the management of remote communication, management of agent processes, security, auditing, installation and upgrades and other features are provided while allowing for completely custom feature development. Common management elements such as product administration, configuration, monitoring and delivery are supported in a rich core model that includes a lot of out-of-the-box functionality. When product support is written in these models the user will experience a standard experience across products for basic features. Support for the integration of custom application interfaces allows for the necessary flexibility in creating unique features and the optimized user experience for other features.
The first step in developing new product support is to define the inventory types that will be used. This is done through the deployment of an AMPS plugin with associated metadata. Inventory types can represent any abstract item to be acted on and can be modeled in a hierarchy that may span between plugins. Common inventory elements are physical devices, operating system process and logical elements of product infrastructure. The hierarchy implies a logical deployment and execution model such as Process X runs on an Operating System Y.
Interaction with managed products also typically happens through plugin infrastructure. Plugins may provide component implementations that can execute custom code for discovering and establishing connections to resources for management as well as optional interfaces for the common core services. Thus, an Apache plugin developer would specify the Apache server resource type, perhaps sub-types such as virtual host services, provide code for the discovery of running apache servers and code that may use SNMP to communicate with Apache for collecting monitoring information via the monitoring core service.
Developers may also provide custom application user interfaces tailored to specific products or non-core management services. A developer, could, for example provide a custom web interface to managing the configuration of an Apache server. This custom interface can utilize the configuration core service model to support storage, auditing, history and access control included in that service or interact more directly with plugin code via generic operations (messages) that could be written to execute arbitrary commands. Where possible, the use of common core services will provide tighter integration to the overall platform and other common services to accomplish things like notification of configuration changes through the alerts and notification subsystem. Custom application user interfaces are integrated into a platform deployment by executing in their own operating environment and utilizing perspectives service information to define the links between it, the core platform user experience and other custom applications. Custom applications may also be written as parallel deployed JEE EJB and web applications that may make more direct access to included core platform interfaces such as the feature rich, data-driven configuration editing screens.
Finally, developers may implement custom content source plugins to the server to provide access to external repositories with arbitrary content. This can incorporate software repositories into the content system for installation, provisioning and upgrades of deployed software or other types of content. The plugins once again define metadata about this content to the core inventory model. Apache once again serves as example where a theoretical repository of apache modules would reside in an external repository and be provided to the user as available for installation. The custom plugin support for this content might include installation, registration and configuration of the module.