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: [email protected] For additional commands, e-mail: [email protected]
