Users and Devs,
I'd like to make a proposal and start a discussion about the future of
QMF and Qpid broker management.
QMF (Qpid Management Framework) started out as a way to remotely manage
the Qpid C++ broker using AMQP messaging. There was an agent embedded
in the broker and a console API written in Python. It was then expanded
for more general purpose use when an agent library and API were
developed so developers could provide QMF manageability to their
software components.
There has been quite a bit of evolution including new APIs and even a
new protocol based on map/list-encoded messages. One of the important
changes that occurred with the new protocol (called qmf2) was that QMF
became purely layered over AMQP messaging. The original protocol
required the participation of the broker to assign addresses, to track
agents, and to cache schema information (didn't scale well, didn't work
in multi-broker environments, had multiple protocol issues, wreaked
havoc with clustering).
The QMF code is embedded in the "qpid" namespace because older versions
were tightly coupled to the broker code. Now that the coupling has been
reduced (consisting of the public messaging API), it is possible to move
QMF out of the "qpid" namespace and allow it to be a separate component,
with its own build and release artifacts.
I would like to propose that we:
1. move the C++ implementation of qmf2 out of the qpid tree and into
the "extras" subdirectory (where the Python implementation is),
2. move the swig bindings (Python, Ruby, etc.) into extras as well, and
3. deprecate the old qmf components.
The old components are in:
* cpp/{include,src}/console
* cpp/{include,src}/agent
* cpp/{include,src}/qmf/engine
* cpp/bindings/qmf
The last part of the proposal is to remove the dependency that the qpid
tools (qpid-config, qpid-stat, qpid-route, etc.) have on the Python QMF
library. If you haven't noticed, these tools run fairly slowly,
especially when grouped in large numbers in a script file. This is
because QMF (version 1) has a significant amount of handshake that
occurs on connection setup. Since the tools don't need agent-discovery
or schema-introspection, they can operate much more simply by sending
and receiving properly formatted messages to and from the broker agent.
I prototyped this with qpid-stat and found it to be visually
instantaneous in its response time. It also reduced the number of
queues and bindings related to the management session to one.
Fraser Adams has contributed a Java implementation of the new QMF
protocol. It makes sense to me that this should be included with the
C++ and wrapped components that I propose moving into "extras".
Thoughts?
Regards,
-Ted
