qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject Re: QPID Management Update
Date Wed, 01 Oct 2008 18:51:02 GMT
2008/9/30 Ted Ross <tross@redhat.com>:
> 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.

Thanks, this is a very useful summary.

> 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.

So, if the Java broker wanted to become a agent, it would be necessary
to develop the equivalent of the Agent API in C++?

Are all the existing agent-aware apps currently written in C++ (I presume so)?

> 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.

You mean that if I run a qpid c++ message broker, it acts as a QMF
broker (in the same process)? Is the idea that an org will have a
small number of QMF brokers? Is it possible to configure qpid c++
message brokers to use a specified QMF broker (i.e. other than

> 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.

Is this a console in QMF terms, that in turn exposes QMF managed
objects over JMX?

> 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.

Is SNMP on your roadmap or integration with widely use enterprise
monitoring packages such as IBM Tivoli or Microsoft SCOM?


View raw message