RHQ 4.9
Agent Plugin Components
Discovery and Inventory
There are two types of plugin components that are provided by the plugin developer, a Discovery Component and a Resource Component. To manage a resource that is discoverable (i.e. can be automatically found) the developer writes a Discovery Component that searches for local clues to the existence of one or more of the resources that match the type. There is always one instance of a Discovery Component per defined resource type, however it is possible to reuse Discovery Components between types. The Plugin Container provides native process scan support, allowing the Discovery Component to receive a cross-platform search of processes that meet the provided query. The Discovery Component can also utilize access to its the parent component and often does so in the case of detailed services so that one connection context can be maintained across several types that are supported by a complex managed resource. The Discovery Component will return a list of discovered resources that will be synchronized with the server.
Upon import into inventory, the Inventory Manager will create a Resource Component instance for each resource. These components are started in sequence according to their place in the resource tree and may again utilize the services of parent components in order to perform their capabilities. Each instantiated resource component represents a connection to one resource in the inventory. The resource component supports the ability to start and stop the connection between the plugin and the underlying resource. Additionally, the resource component provides a means for the platform to retrieve the availability of the underlying resource as well.
Facets
A plugin may optionally support zero or more of the provided plugin container features, such as monitoring or content handling, for additional aspects of management. The plugin provides the implementation of these features by implementing a series of "facet interfaces". Each subsystem has a corresponding facet interface that must be implemented in order to provide support for a particular resource type. Through this mechanism, the plugin developer does not have to worry at all about how information is received from or sent to the server, nor about the synchronization of inventory or configuration, but maintains a simple and limited interface with the Plugin Container.
For example, a plugin may choose to provide the ability to configure resources of a particular type. The resource component for that particular type would then implement the ConfigurationFacet (additionally, metadata about the configuration must be specified in the plugin descriptor, but this will be covered elsewhere in the documentation). The implementation of this interface will understand how to communicate with the underlying resource in order to perform configuration related functions, such as loading the resource's configuration values or updating the configuration with new values.
To reiterate, the use of separate interfaces allows a plugin developer to selectively choose what features to support for a given resource type.
Supported Facets
AvailabilityFacet
This is the one required facet and is required simply by implementing the ResourceComponent interface. This facet provides the method used to check if the managed resource is available (i.e. UP or DOWN).
MeasurementFacet
Provides the ability to report measurement values for a particular resource. The definition of what values are reported is provided by the plugin developer on a per resource type basis, allowing each resource type to provide custom, domain specific measurement data.
OperationFacet
Provides the ability to execute user initiated actions on a particular resource. The definition of what operations can be executed is provided by the plugin developer on a per resource type basis. Additionally, the plugin developer can specify a set of parameters (along with validation rules that can be executed on the server) that the user should enter when executing the operation.
ConfigurationFacet
Provides the ability to load the resource's current configuration and push changes out to the resource. In the plugin descriptor, the plugin developer will indicate the set of configuration properties that will be used for a particular resource type. This configuration definition includes metadata about each property, including a description of what the property represents and any validation constraints that should be run server-side whenever the user attempts to change the property.
ContentFacet
Provides a way to query a resource to determine what packages are installed on it. This facet also provides a means to deploy and delete packages from a resource. The types of packages that may be discovered and deployed on a resource are defined as part of the descriptor when defining a resource type.
CreateChildResourceFacet
Indicates a resource is capable of creating new child resources (as defined by the resource type hierarchy). Calls into this interface will result in new, functioning resources being created on the machine.
DeleteResourceFacet
Indicates a resource can be deleted through the plugin. It is up to the plugin's implementation of this interface to determine how to go about physically deleting the resource from the machine. The net effect of calls to this interface is that the resource will no longer function on the machine nor will be reported through agent discoveries.
SnapshotReportFacet
Mainly for troubleshooting a managed resource, the snapshot report facet allows the component to take a runtime "snapshot" of the managed resource, including configuration files, log files, data files and any other additional files or content deemed appropriate by the plugin developer.