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
"itself")?

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

RG

Mime
View raw message