CVS: jcontainer/loom/site/xdocs/guide/mx index.xml,1.4,1.5 structure.xml,1.3,1.4
Peter Donald <pdonald-yCVjj/[email protected]> Wed, 3 Dec 2003 04:44:54 -0600
| Newsgroups | gmane.comp.java.jcontainer.cvs |
|---|---|
| Message-ID | <[email protected]> |
Update of /cvsroot/jcontainer/jcontainer/loom/site/xdocs/guide/mx
In directory hogshead.codehaus.org:/tmp/cvs-serv21491/site/xdocs/guide/mx
Modified Files:
index.xml structure.xml
Log Message:
Styled codebase
Index: index.xml
===================================================================
RCS file: /cvsroot/jcontainer/jcontainer/loom/site/xdocs/guide/mx/index.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- index.xml 15 Oct 2003 03:43:09 -0000 1.4
+++ index.xml 3 Dec 2003 10:44:51 -0000 1.5
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<document>
<properties>
- <title>Management Guide</title>
- <author email="[email protected]">Huw Roberts</author>
+ <title>Management Guide</title>
+ <author email="[email protected]">Huw Roberts</author>
</properties>
<body>
<section name="Introduction">
Index: structure.xml
===================================================================
RCS file: /cvsroot/jcontainer/jcontainer/loom/site/xdocs/guide/mx/structure.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- structure.xml 31 Jul 2003 20:29:39 -0000 1.3
+++ structure.xml 3 Dec 2003 10:44:51 -0000 1.4
@@ -1,12 +1,12 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<document>
- <properties>
- <title>Management Guide - Organizing Structure</title>
- <author email="[email protected]">Huw Roberts</author>
- </properties>
- <body>
- <section name="Introduction">
- <p>
+ <properties>
+ <title>Management Guide - Organizing Structure</title>
+ <author email="[email protected]">Huw Roberts</author>
+ </properties>
+ <body>
+ <section name="Introduction">
+ <p>
Loom 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
@@ -14,49 +14,49 @@
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.
- </p>
- </section>
- <section name="Elements">
- <p>
+ </p>
+ </section>
+ <section name="Elements">
+ <p>
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:
- </p>
- <subsection name="Context">
- <p>
+ </p>
+ <subsection name="Context">
+ <p>
In Loom, 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.
- </p>
- <p>
+ </p>
+ <p>
This nested structure of Contexts is the principal
organizing element for management data, and is the bridge between
the management code embedded in Loom and the implementation of the
management component. It is represented by the
- <code>org.apache.avalon.phoenix.interfaces.SystemManager</code>
+ <code>org.apache.avalon.phoenix.interfaces.SystemManager</code>
interface.
- </p>
- </subsection>
- <subsection name="Target">
- <p>
+ </p>
+ </subsection>
+ <subsection name="Target">
+ <p>
A target is a manageable object. Examples of Targets in Loom include the
components, the applications and the blocks. Each target has one or more topics.
- </p>
- </subsection>
- <subsection name="Topic">
- <p>
+ </p>
+ </subsection>
+ <subsection name="Topic">
+ <p>
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.
- </p>
- </subsection>
- </section>
- <section name="Hierarchy">
- <p>
+ </p>
+ </subsection>
+ </section>
+ <section name="Hierarchy">
+ <p>
This diagram illustrates how this might be presented in a management GUI:
- </p>
- <source>
+ </p>
+ <source>
Loom
|
+--Components
@@ -74,38 +74,38 @@
+-- Blocks
+-- Block 1
+-- Block 2
- </source>
- <p>
+ </source>
+ <p>
In this example Loom, 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.
- </p>
- <p>
+ </p>
+ <p>
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=Loom,Application=Hello_World,Block=Block_2,Topic=Logger'.
- </p>
- <p>
+ </p>
+ <p>
In a swing environment each topic might have its own tab.
- </p>
- <p>
+ </p>
+ <p>
In a command line environment, the syntax might be:
- </p>
- <source>
+ </p>
+ <source>
phoenix-mx.set( "Loom/Applications/Hello World/Logging/LogLevel", "DEBUG" );
phoenix-mx.describe( ""Loom/Applications/Hello World/Logging/LogLevel" );
- </source>
- <p>
+ </source>
+ <p>
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.
- </p>
- </section>
- <section name="Management Proxies">
- <p>
+ </p>
+ </section>
+ <section name="Management Proxies">
+ <p>
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.
- </p>
- </section>
- </body>
+ </p>
+ </section>
+ </body>
</document>