Perspectives will be implemented as server-side plugins. As such the perspective will deploy as a JAR as required for a well formed SSP. Deployed as such the db persistence, version update and HA synchronizing will be handled by the Master SSP container (SSPC).

There will also be a Perspective SPC (PSPC) coupled with a Perspective SP Manager (PSPM) to for perspective-specific lifecycle event handling. The PSPM will handle load and unload of the perspective, handling the deploy or undeploy of associated webapps. Note that the PSPC and PSPM are RHQ code, part of the Perspective subsystem. They handle all deployed perspectives and are not provided by a perspective itself.

Currently there is no identified need for a SP listener, or for perspective Configuration. This could change as development continues.

The SSP JAR structure is simple, requiring only a server plugin descriptor. The perpective plugin descriptor imports and end extends the base SSP descriptor XSD. Additionally, the SSP JAR can contain any other artifacts required for deployment. For perspectives this includes optional WAR files that, when deployed, satisfy the request URLs defined for the perspective.

The structure looks like:

     META-INF
        manifest.mf
        rhq-serverplugin.xml  // the perpective descriptor)
     app1.war                 // optional apps
        ..
     appN.war
     classes                  // optional classes to support dynamic filtering (this is under consideration)

Major points:

• Every perspective defines a single perspective descriptor. This is an XML file describing the perspective, its extension points, etc.
  The file is named as defined by the SSP requirements, currently rhq-serverplugin.xml.

• Perspectives are delivered as a JAR file, named as defined by the SSP requirements, probably perspective-name-VERSION.jar.

• Perspectives JARs are deployed as defined by the SSP requirements, currently ../deploy/rhq.ear/rhq-serverplugins

• Analogous to agent plugins, perspectives are stored in the database and automatically distributed to HA Servers. Version handling is similar and deployment is live using a recurring server job.

• The perspective JAR file can optionally include one or more WAR files supporting the urls defined in the perspective descriptor. URLs referring to these apps will be relative. (e.g. /myperspective/foo).

  • The apps will be managed using the AS MainDeployer Mbean. They will be deployed on plugin load and undeployed on plugin unload. Other lifecycle events should be able to be supported as needed.

• The perspective JAR file can optionally include Java classes that cvan resolve dynamic extension point activation/filtering requests.

  • This is an active design topic

It is hoped that, unlike agent plugins, the perspective descriptor will not require db stored meta-data. The descriptor will be managed in memory by RHQ. This prevents meta-data update issues. But, it needs to be proven that necessary extension point activation (filter processing) can be performant without utilizing db-level querying. If not then the Perspective Handler will be responsible for managing the descriptor/db synchronization.

For applications referred to from the perspective that are not java, or not deployed in the way above, the urls will need to be fully qualified.

     META-INF
        manifest.mf
        rhq-serverplugin.xml         // the perpective descriptor)
     rhq-sample-perspective.war      // optional app (supports Custon Tag)