Robert Greig wrote:
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)?
Currently all apps using the agent API are in C++. A likely next
implementation for the API is Python to support non-integrated
management agents (i.e. scripts that query their targets rather than
being built into them).
I mentioned the possibility of a JMX => QMF bridge (the opposite of
QMan) which will make JMX-manageable apps accessible through QMF. This
is a possible strategy for the Java broker.
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")?
It might be more accurate to call the QMF broker the "QMF exchange"
since it is implemented as
a derivative of the topic exchange.
The QMF broker is fairly lightweight. Its responsibilities are as follows:
1) Manage and assign unique banks of object identifiers to the agents,
2) Cache schema information for consoles, and
3) Enforce access control (ACLs) tasks that involve fields from the
message bodies.
All of the message routing involved uses plain AMQP.
Currently the QMF broker functionality is present in all brokers and
every broker is a standalone
QMF "domain". If a deployment has multiple brokers, a console must
connect to all of the brokers to
manage the entire deployment.
It is desired that the QMF broker functionality be distributed such that
a console may make a single connection to its nearest broker to manage
the entire enterprise. This capability has not yet been implemented.
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?
That is correct. QMan exposes QMF content as JMX MBeans.
Is SNMP on your roadmap or integration with widely use enterprise
monitoring packages such as IBM Tivoli or Microsoft SCOM?
SNMP is not on *my* road map currently. I think that an SNMP bridge
(similar to the JMX one) would be very useful. One interesting aspect
is that QMF and JMX are self-describing whereas SNMP is not. There
would need to be a way to generate SNMP MIBs from QMF/JMX schemata. Or
alternatively a specification of a mapping from QMF/JMX to a MIB.
One thing that I am thinking about is generating Syslog events from QMF
events.
RG
-Ted
