Ted Ross wrote:
There's been a lot of progress lately on QPID management that I would
like to bring to the attention of the QPID user and developer communities.
The Qpid Management Framework (QMF as we've been calling it) is an
extensible framework for managing the components of QPID and for using
QPID as a general-purpose management infrastructure for third-party
software components. This framework is implemented in the QPID C++
broker (on the trunk, post-M3).
QMF is composed of three parts: The broker, the console, and the agent.
Consoles are consumers and controllers of management data. They are
GUIs, CLI utilities, event collectors, and programmatic scripts that
interact with management data. There is a Python console API for
users who wish to write their own console applications. I have it on
good authority that a Ruby API is being developed as well.
Agents are producers and maintainers of management data. They are
software components like the messaging broker, a plugin store module,
or external third-party software packages. Agents provide a schema
for their management model that describes object and event classes.
Object classes may have methods with arbitrary sets of input and
output parameters for very flexible and powerful management
capability. An agent API is provided in C++ along with an XML-based
schema compiler to get agent developers up and running quickly.
The QMF Broker is co-located with the QPID messaging broker and it
handles the efficient routing of management data and meta-data to the
places it needs to be.
Many thanks to Andrea Gazzarini who has contributed a QMF/JMX bridge
(QMan) to the project. This allows Java JMX consoles to natively
access all of the management data in an entire QMF enterprise. I've
attached a pair of screen shots of a JMX console viewing QMF data
through Andrea's tool.
Some interesting features of QMF:
* QMF is inherently asynchronous for efficiency and throughput.
The console API has both asynchronous and synchronous operations
to support complex applications as well as very simple (even
interactive) operation.
* QMF is based on QPID messaging for secure, efficient, and
scalable data transfer. Event and status distribution is
provided using the publication-subscription model for efficient
multicasting.
* QMF cleanly handles the coexistence of agents with different
versions of the same management schema. This allows for
flexible, staged upgrade of software packages.
Future project work for QMF:
* API support for other languages. In particular, a C++ console
API and a Python agent API are desired.
* A JMX agent, the opposite of QMan, that uses JMX to access
MBeans and exposes those MBeans across the QMF network. Such a
tool would provide secure, wide area access to JMX-manageable
software. It also would provide Python/Ruby/C++ access to JMX
MBeans.
* QMF support in the Java broker.
-Ted
pics did not come through, maybe post them on the wiki and provide a links
Carl.
