Management Guide - Organizing Structure

Phoenix Management separates the information on what should be managed from the implementation of the management agent. In order to maintain this separation, yet still allow the management interface to be rich and structured enough to be useful, it is necessary to impose an organizing strucuture on the management metadata. This structure will be common across all management interfaces, although the specifics of how it is exposed is up to the implementor.

Management information is stored in a structured format that contains both a functional definition of the actions (what can be done) and descriptive information about the actions (to help guide the user). It is composed of the following elements:

In Phoenix, each managed object belongs to a single Context The Context contains a list of managed components called Targets. In addition to the list of Targets, a Context can also have zero or more sub-Contexts.

This nested structure of Contexts is the principal organizing element for management data, and is the bridge between the management code embedded in Phoenix and the implementation of the management component. It is represented by the org.apache.avalon.phoenix.interfaces.SystemManager interface.

A target is a manageable object. Examples of Targets in Phoenix include the components, the applications and the blocks. Each target has one or more topics.

A topic is a logical grouping of attributes that can be get and/or set on the Target and a group of operations that can be called on it. It is intended that Topics group together a particular aspect of Targets manageability.

This diagram illustrates how this might be presented in a management GUI:

Phoenix
 |
 +--Components
 |   +-- Kernel
 |   +-- Deployer
 |   +-- etc.
 |
 +--Applications
     +--Hello World
     |    +-- Blocks
     |          +-- Block 1
     |          +-- Block 2
     |
     +-- Ftp Server
          +-- Blocks
                +-- Block 1
                +-- Block 2
      

In this example Phoenix, Components and Blocks are Contexts. Kernel, Deployer, Hello World, Block 1, etc are Targets. Each Target will then have one or more Topics. Topics might be Logging, Lifecycle, Deployer, etc.

In a jmx environment each topic would most likely be exported as its own mbean (so in the above example the jmx name would be 'Instance=Phoenix,Application=Hello_World,Block=Block_2,Topic=Logger'.

In a swing environment each topic might have its own tab.

In a command line environment, the syntax might be:

phoenix-mx.set( "Phoenix/Applications/Hello World/Logging/LogLevel", "DEBUG" );
phoenix-mx.describe( ""Phoenix/Applications/Hello World/Logging/LogLevel" );
      

Again, the point behind the 'Organizing Structure' is to keep the management specification separated from the management agent, while at the same time providing enough definition to keep a shared conceptual view between the two areas.

There is one remaining concept to cover, the proxy. It is a class that can be used to wrap access to the underlying target. Posible uses include the mapping of data types to a more friendly type, (eg. from Date to String and back), cleaning up method names, providing backwards compatibility with older versions, and exposing methods missing from the target class, but available to it via a reference.