2008/9/30 Ted Ross <[EMAIL PROTECTED]>: > 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
