qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: QPID Management Update
Date Tue, 30 Sep 2008 14:02:55 GMT
Ted Ross wrote:
> 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.
>
> The Qpid Management Framework (QMF as we've been calling it) is an 
> extensible framework for managing the components of QPID and for using 
> QPID as a general-purpose management infrastructure for third-party 
> software components.  This framework is implemented in the QPID C++ 
> broker (on the trunk, post-M3).
>
> QMF is composed of three parts:  The broker, the console, and the agent.
>
> Consoles are consumers and controllers of management data.  They are 
> GUIs, CLI utilities, event collectors, and programmatic scripts that 
> interact with management data.  There is a Python console API for 
> users who wish to write their own console applications.  I have it on 
> good authority that a Ruby API is being developed as well.
>
> 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.
>
> 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.
>
> 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.
>
> Some interesting features of QMF:
>
>     * QMF is inherently asynchronous for efficiency and throughput. 
>       The console API has both asynchronous and synchronous operations
>       to support complex applications as well as very simple (even
>       interactive) operation.
>     * QMF is based on QPID messaging for secure, efficient, and
>       scalable data transfer.  Event and status distribution is
>       provided using the publication-subscription model for efficient
>       multicasting.
>     * QMF cleanly handles the coexistence of agents with different
>       versions of the same management schema.  This allows for
>       flexible, staged upgrade of software packages.
>
> 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.
>
> -Ted
>

pics did not come through, maybe post them on the wiki and provide a links

Carl.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message