Discovery

Shortly after importing a JBossAS server into your inventory, a content discovery will be performed. This goes out to the application server instance and interrogates it for the list of jars which compose it's runtime dependencies. Using this features, you can survey your enterprise and determine whether some server instance passes a compliance audit or not; if it does, you'll know specifically which instance needs upgrading as well as the exact nature of the failure.

Deployment

Some resources in inventory, namely the JBossAS and Tomcat servers, support pushing out pieces of content as children services. Most often this takes the form of ears and wars. RHQ supports deployment, redeployment (reloading an ear or war), as well as undeployment. All actions are recorded in the audit trail of the system, and each redeployment is automatically versioned by the system so as to give uniqueness to the audit trail entries.

Delivery

For simple deployments a user can upload an ear or war from their local file system. However, for organizations that require or desire a better centralized solution, RHQ offers a mechanism through which to uniformly deliver content to the various resources in inventory. Content is found by pinging "content sources" and is delivered to resources through conduits called "channels". Using this mechanism, multiple resources can be simultaneously informed of a new version of some ear or war, and an administrator would come along and push the deploy button to finish that workflow.

Resource Type

A managed resource represents a software or hardware component that can be managed with RHQ. A Resource Type identifies the kind of managed resource it is. Resource types are defined by agent plugins (also called "Resource Type Plugins" or "Product Plugins"). Examples of resource types are "JBossAS Server" and "Linux" - a resource whose resource type is "JBossAS Server" represents a JBoss application server instance; a resource whose resource type is "Linux" represents a Linux machine.

Resource Type Plugin

All resource types are defined inside agent plugins. A Resource Type Plugin represents the name of the agent plugin whose plugin descriptor defines a particular resource type. Examples of resource type plugins are "JBossAS" and "Platform".

Package Type

Analogous to the same way a resource type defines a kind of resource, a Package Type defines a kind of Package. Each Resource Type can define many different types of packages. A package type does not identify any individual piece of content, but what it does is define a family of packages that may, for example, follow a specified format or syntax. One thing to remember about package types is a package type is only valid for the resource type that defined it. Examples of package types are "cumulative patch" or "rpm".

Package

A Package provides a definition for related but arbitrary pieces of content that is inventoried in the system. A package definition can be created by either a Server-side Content Source Plugin (on the RHQ Server) or by discovery performed by a Resource Type Plugin on the RHQ Agent. A package is always of one particular Package Type and can have one or more Package Versions associated with it. Examples of packages are "Hibernate" or "libc".

Package Version

Note that a Package, as described above, does not specify any specific version, it only describes some kind of content without mentioning any specific architecture or version (e.g. the "Hibernate" jar or the "libc" library). One particular version of a package is known as a Package Version and can be associated with a specific version (e.g. 1.0.0-beta) and with a specific architecture (e.g. "amd64" or "noarch" for architecture-independent packages). For example, the package "Hibernate" could have three associated package versions - "Hibernate v2.0", "Hibernate v3.0" and "Hibernate v3.5". Another example is the package "libc" having three associated package versions that provide architecture information too - "libc v2.0 amd64", "libc v2.0 i386" and "libc v3.3 amd64".

Note that a package version does not, however, represent a specific piece of content that is installed or deployed in any resource (that's the job of Installed Package). A package version simply refers to a particular package that can be installed on applicable resources. Package versions can be created by either a Server-side Content Source Plugin (on the RHQ Server) or by discovery performed by a Resource Type Plugin on the RHQ Agent. Package versions can be placed in one or more channels so resources can later subscribe to those channels and install different versions of the package.

Package Bits

The actual content of a Package Version - literally the bytes or text that make up the content - are known as its Package Bits. A package version's bits can be stored in the server by either file uploading them, having a RHQ Agent auto-discover them or having a Server-side Content Source Plugin download them from a remote repository.

Installed Package

Everywhere that a Package Version is installed in your environment is represented by an Installed Package. An installed package is simply a package version that is installed on a particular resource. One package version can have more than one installed package associated with it - for example, if "Hibernate v3.5" is installed on three JBossAS server resources somewhere in your environment, you will have three installed packages associated with the one "Hibernate v3.5" package version.

Content Source

A Content Source is a local or remote repository that can provide both the metadata and the Package Bits for content. More specifically, a content source is a place where the actual bytes of Package Versions can be downloaded. Content sources can be remote Yum repositories (e.g. to provide RHEL rpm packages), an HTTP server (e.g. the RSS feed from the JBoss CSP to provide JBossAS patches), Maven repositories (e.g. to provide Java libraries) or even a mounted CD-ROM or NFS mount that locally provides Linux installation RPMs. You can even write your own Server-side Content Source Plugin if you wish to support your own kind of content source.

Repository

A Repository is an aggregator of Package Versions. Users define repositories and associate package versions with their repositories. A repository can also be automatically injected into the system via content server side plugins. A package version is associated with a repository by either file-uploading the package version content directly or by having a Server-side Content Source Plugin download the package version information from a content source repository and placing it in the repository. Note that you can associate package versions that came from different content sources to the same repository. Once you have filled repositories with package version content, you can then subscribe resources to one or more repositories, thus giving those resources access to the content found in those repositories. This allows users to determine which package versions a resource can view and install.

Server-side Content Source Plugin

There are many different kinds of content source repositories - yum repositories, maven repositories, RSS feeds, NFS mounts and any thing else you can think of. Because of the many different places content can come from, RHQ provides an extension mechanism that allows you to plug in different Server-side Content Source Plugin implementations to help it understand how to grab content from any remote repository. Out of box, RHQ provides content source plugins to access yum repositories, local or remote disk/NFS mounted repositories and the JBoss Customer Support Portal (CSP) repository.