Perspectives Subsystem

Ex. An Operator is logged in. Based on his/her role, a Perspective removes the Administration menu item, adds a Graph SLA Violations menu item, and adds to the resource tabs.

(click the image to zoom in)

Notables

• coreMenu.administration removed
• coreMenu.graphSLA added
  • presumably menu items as well
• resourceTab.auditHistory added
  • presumable subtabs as well
• new task pane in core UI
  • global tasks
  • resource tasks
  • help

What it is

The Perspectives Subsystem is an RHQ server side component that provides the ability to integrate custom user interface extensions on top of the Core RHQ UI. This means that a new perspective can define which parts or extension points within the Core UI are to be modified/enhanced and also what new content is to be applied in that area. For example, a perspective could be defined to replace the content of the Configuration tab with a task oriented view of configuration viewing/editing.

What it's not.

It is helpful to dispel a few misconceptions about perspectives that we've encountered as well:

• The perspective subsystem is NOT a UI widget engine where perspective developers can expect to provide raw data that is seamlessly translated into RHQ UI pages. Perspective developers should instead be thinking of how their new content will plug into the Perspective Subsystem to be displayed alongside/over Core UI components.
• The perspective subsystem will NOT provide a page or workflow component architecture for use by perspective developers. Each perspective developer must provide their own wizard/workflow architecture within the html views provided. Look-and-feel guidelines will be provided to leverage UI display themes common to the Core UI.

Goals/Constraints

• Provide extensible mechanism to integrate custom/enhanced UI components to the Core UI.
• Must not require integrators/enhancers to rewrite existing UIs in Core UI framework language.
• Enable the creation of task/action oriented UI experiences.
• Allow reuse of core UI to enable consistent user experience within UI.

Scope

As part of the custom UI enhancement aspect, Perspectives are also meant to allow the RHQ engine to support action/task based or non-resource focused views of the same management data. It is helpful to think of a few stereotypical users and some of the roles that may drive such task/role oriented UI experiences.

Users with Roles

The following five users have been identified as stereotypical users/roles that could drive perspective definitions. See Perspective Users/Roles for more details

1. Developer (Builds things, Makes code updates, is not concerned with monitoring)
2. Operations (24x7 - Is it up and running?) (Concerned with SLA monitoring and incident detection and capturing errors.)
3. App Support (find right person to fix incident, understands config, consistent means of deployment)
4. Infrastructure engineers and support ( configuration, makes boxes available, works with storage, fixes infrastructure problems )
5. Line of Business (Non-technical product managers who work with IT, Cares about reports a lot, reports status to others )

A few wireframes/mockups of potential perspective UIs

• Viewing your resources with applicable actions
• A few different potential perspectives

Implementation Details

With the definition and scope of perspectives outlined, it is important to understand what constraints and formats are available to the perspective developer to define their enhancements.

• Requirements and Guiding Principals identifies areas of technical implementation still under discussion.
• Extension Points breaks the Core UI into desired regions for enhancements.
• User-to-Perspective Association outlines how a logged in user is associated with a given perspective.
• Perspective Deployment outlines what artifacts constitute a given perspective.
• Conflict Resolution outlines what behavior the System integrator/administrator needs to understand to coordinate multiple perspective if conflicts are possible for the delivered user experience.

Requirements and Guiding Principals (Technical & Functional)

• Single sign on with co-located or external web applications, both external to rhq.ear
• API for accessing the metadata about the perspectives service functionality and metadata
• Link construction with parametrization (e.g. link to a resource given a specific resource id)
• Add new task pane to the core GUI (a pop-out pane along right hand side of dashboard, resource/group pages, and potentially other pages, which contains a list of task links)
• Define ability to replace sections of pages via the following extension
  points:
  • add tasks to the resource or group task panes, for certain resource types
  • add tasks to dashboard task pane
  • add, replace, or delete resource or group tabs, for certain resource types
  • add, replace, or delete resource or group subtabs, for certain resource types
  • add, replace, or delete menu items (headers or links)
  • replace resource or group pages, except perhaps the menu bar, for certain resource types

Possible Enhancements

• Add new context around workflows for specific users
  • Provide a new place to display global "perspective views"
  • UI layout updates to allow for custom perspective views (e.g virtualization manager, middleware software administrator)
  • Provide APIs for integration with default features (e.g. link to the default config edit from a custom UI screen)
• Add support for custom "information portals" to be shared between user interfaces...
  • e.g. add a custom section to the resource summary page
  • e.g. add custom portlets to dashboards or include built-in dashboard portlets in custom views
• Provide services for using built-in components in custom UI displays
  • e.g. display a metric chart in custom application

Extension Points

To leverage the Core UI it is necessary to classify existing regions or addressing points where enhancements/customizations can be applied to. These identified regions have been classified as Extension Points and are further detailed at this location. Draft of deployment descriptor

User-to-Perspective Association

Explicit Association

The proposal is to manage Role-Perspective association analogously to the way groups and users are associated in RHQ today. In short, the installed perspectives will be available to the security manager for association with defined roles. This will be available under Administration.

The available perspectives for each of a user's roles will be enabled and their effects will be cumulative for the user. See also Conflict Resolution.

In this way the perspective developer does not have or need knowledge of defined roles for an installation.

Perspective extensions will define the necessary filters (permissions, trait, etc) that can then be applied to the user's view at runtime to decide whether the particular extension is active. See also Extension Points and Perspective Descriptor. In this way a single, logical perspective can be defined with varying runtime effect, depending on the user's characteristics.

It is not thought to be an initial requirement to have users disable perspectives. Instead, users should as much as possible be unconcerned/unaware of perspectives affecting their GUI experience. (thoughts on this?)

We will most likely be adding a PerspectiveManagerBean/Local/Remote and the Remote API will be enhanced as needed to allow perspective manipulation as needed.

Implicit Association

There may not be any benefit to explicit association between roles and perspectives. In fact, there may be specific downside in that the extra step of association would be necessary after perspective deployment.

An alternative is to assume that all perspectives are associated with all roles. Initially it may seem that this could enable inappropriate perspectives to users. But, remember that extension points have defined filters to ensure they are applied only if the context is correct (plugin deployed/resource type in inventory/permissions available). This processing is necessary in the explicit model but perhaps renders that model unnecessary. Because that same processing could determine the applicable extension points across all perspectives.

One potential weakness is a situation with several global perspectives (i.e. perspectives that take over the start page). In this situation a conflict resolution may need to take place since no applicable filter can be applied at the top level. In this case explicit association could prevent the conflict.

Perspective Deployment

See Perspective Deployment.

Perspective Context

See Perspective Context.

Single Sign-On (SSO)

See Perspective Context.

Conflict Resolution

As perspectives can and will be developed by independent groups, the opportunity may arise that two different perspectives would both like to control the rendering for the same extension point. In practice the Administrator of the finished product should be aware of and ensure coordination for consistent and polished user experience. Nevertheless conflict resolution for the Perspective Subsystem are discussed in the following link
Further Details on Conflict Resolution

Glossary/Terms

Perspective Subsystem

Adds extensibility to the existing user interface (Core UI) of JON. Perspectives applied against the Core UI render a particular user experience. A Perspective describes the deltas from the core UI via hooks called extension points. When applied, perspectives act as a sort of lens, and the result of this is a modified UX. End users should not know about the perspective subsystem and should see a consistent UI experience.

Perspective developers can expect that the Perspective Subsystem will provide look-and-feel elements (guidelines, shared stylesheets and potentially provide HTML ids/hooks) with which perspective can reuse existing UI display elements from the Core UI.

It is also helpful to discuss here two things that the perspective subsystem is NOT:

• The perspective subsystem is NOT a UI widget engine where perspective developers can expect to provide raw data that is seamlessly translated into Jon UI pages.
• The perspective subsystem will NOT provide a page or workflow component architecture for use by perspective developers. Each perspective developer must provide their own wizard/workflow architecture within the html views provided.

Perspective

A perspective is something defined and applied which will alter the Core UI.

• Perspectives are associated with users via their roles.
• The result of applying one or more perspectives is what a user see on her screen - more than one perspective cumulatively can contribute to what is seen on a screen at any given time.
• Perspectives can alter the UI as soon as the user logs in.
• Perspectives can define a change as subtle as an additional global menu or as drastic as a full replacement of the entire UI.

Perspective Descriptor

Is an XML document defining the resources, rules, extension points and numerous other elements used by the 'Perspective developer' to create a new view leveraging the Core UI. The perspective descriptor will be consumed by the 'Perspective Subsystem' and must conform to an XSD(Xml Schema Definition) document defining/constraining possible perspective configurations.

Core UI

This term refers to the Jon 2.3 UI as being the default interface to RHQ. If no perspectives have been added then all resources will be displayed as they were in Jon 2.3 (with minor flow changes). The Core UI is also the central reference upon which all Extension Points are defined to identifying which areas will be modified by a perspective.

Extension point

An extension point is a spot in the UI where the perspective subsystem can introduce elements to the UI. A tab is an example of an extension point. An extension point may indicate one of three conditions with respect to the core UI - on, off, and replaced.