what's QMF?

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