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