qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: The future of Qpid Management.
Date Tue, 25 Feb 2014 10:28:09 GMT
On 02/23/2014 05:04 PM, Fraser Adams wrote:
> Obviously the Management Models of the C++ and Java Brokers have
> diverged somewhat over time as indeed have the capabilities of the two
> brokers
> the divergent Management Models means that
> there is different *semantics* between the two Brokers
> The good news is that there is a significant amount of overlap and the
> QMF plugin for the Java Broker that I put together covers a decent
> number of the core use cases, but each Broker does offer some additional
> capabilities.

While convergence and standardisation around an expanding set of 
capabilities is certainly a good thing, it isn't a prerequisite to 
making progress on a common schema in which such capabilities - whether 
overlapping or specific to a broker - can be described.

The core AMQP 1.0 protocol provides a good starting point for a taxonomy 
of interesting entities. We have connections, session, links and nodes. 
Nodes can support different distribution modes and different filter 
types. Nodes may store messages pending the availability of consumers or 
they may drop them. They may support different capabilities in their 
associated terminii. etc etc.

> It would be really nice to be able to put together some tooling that is
> reasonably agnostic of some of the differences.

I agree. It would I think be very useful to be able to list the various 
entities above for any 1.0 compliant broker, and to create or delete a 
'queue' or 'topic' node (or indeed even BrokerX's 'foo-type' node).

There will be differences in offered capabilities and detailed 
semantics, but that would not I think mean that a tool that could 
provide a uniform overview of brokers would have no value.

I think your work provides a good example of what can be achieved by 
adapting different management schemas (and mechanisms) to a common view. 
It's certainly an approach I would like to pursue further.

> there are some really awkward areas such as how one
> represents relationships between Management Objects - in QMF we have
> references e.g queueRef and exchangeRef in Binding

'Object references' are one of the uglier aspects of QMF IMHO. You only 
need the queue or exchange name in your example to identify the correct 
object. Though this is the only real information you need when using 
QMFv2, you have to wrap it up in a slightly non-intuitive way (again, 
IMO!). Keeping things as simple as possible makes a big difference.

> Similarly neither QMF nor AMQP 1.0 Management
> provide a way to introspect Method formal parameters. So you can get
> hold of the available Method names for sure, but arguments/parameters??

I think you can get this over QMF. For example, using qpid-tool you can 
type: schema queue, and that gives you all the methods as well as their 
parameters including types and a basic description.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message