It is often the case that customers will want to integrate with RHQ in an external fashion. RHQ will need to expose a subset of its server-side features set to handle the use cases associated with external integration. RHQ will provide two types of remote client integration:
A command line interface for script based integration. For more see Design-CLI.
An API for language-independent programmatic integration. For more see Integration APIs.
Very briefly, the API will be a WebService implementation based on JBossWS. The WS API will back the CLI, so the scripting front end will communicate to the RHQ server via WS behind the scenes. The CLI will be java based and therefore a Java WS client. It may require a Java6 JRE (Java5 is still a high want). A co-located CLI client will still go through the WS API.
RHQ will provide a single remote-client distribution in zip format. Something like rhq-client.zip. The zip will provide what's needed for executing the CLI or building a WS client. The zip will build a fairly standard directory structure. Assuming no licensing issues it may package the jbossws native stack (another zip or possibly exploded). It will include the generated endpoints for a Java client, also used by the CLI.
Similar to the RHQ Agent the Client distribution will be packaged with the server and downloadable via the GUI. Unlike the Agent it will probably be a versioned zip file name because there is no auto-update.
The RHQ Administration pages will offer a new section for Remote Client, offering the download and remote client enable/disable. If disabled the web services will not be deployed in order to speed server startup. WS will be disabled by default. It is not yet known whether a server restart will be required at enable-time, hopefully not.
Enable/Disable is not yet determined to be global or server-granular. It may depend on ease of impl or overhead of running enabled.
It will be required that the RHQ Client be versioned the same as the RHQ Server. This should be fairly easy as the proper Client distribution can be downloaded from the server.
Although the versioning should match, the remote API and Script commands must remain backward compatible.
The CLI will perform a version check at connect time, performed probably via a new getVersion() service of the SubjectManager. On version mismatch a connection will not be allowed.
The WS API can not perform a built-in version handshake but the application can access the getVersion() service as desired to perform its own check or report server version.