On 14/01/14 14:24, Rob Godfrey wrote:
All,
for those interested in emerging OASIS AMQP specifications, a new draft of
the AMQP Management spec was uploaded yesterday:
https://www.oasis-open.org/committees/document.php?document_id=51948&wg_abbrev=amqp
Cheers,
Rob
Rob et. al. it's been a while since I looked at this in anger, but I've
just had a look at the latest draft linked above and thought I'd share
the following. Perhaps you or others can reassure me - or perhaps this
might prompt people who are currently used to using QMF to read the AMQP
1.0 Management Spec. and give Rob their own comments (the following will
probably only make any sense if you've looked at the Spec.).
I'm still quite nervous of the AMQP 1.0 Management stuff if I'm honest,
I have to confess that I don't find the way that the specification is
written the easiest to follow - for example section 3 says "All
manageable entities SHOULD support standard manageable entity operations
such as CREATE, READ, UPDATE, and DELETE." but 2.4 for example says " A
Manageable Entity MAY be an addressable Node (e.g., a queue) ". That
conceptually feels odd to me - applying CRUD methods to something that
may not actually exist. I guess what it's *really* suggesting is that
the CRUD methods are class methods (in UML terms) but it feels weird -
especially as later in section 5.2 it says:
// transfer a request message
requestLink.sendTransfer(
Message(
properties: {
correlation-id: 1,
to: "$management",
reply-to: "/myaddress"
},
application-properties:{
"name"->"newQueue",
"operation" -> "CREATE",
"type" -> "org.example.queue"
},
application-data:AmqpValue(
Map(
//typespecificproperties
"max_size"->"2000Mb"
)
)
)
)
To my mind that looks like it's sending a message to "$management", so
I'd personally interpret that in my own mind as actually invoking a
CREATE method on the management *node* e.g. create an
"org.example.queue" called "newQueue"which TBH is pretty close to what
the broker object currently does in QMF.
I might be reading too much into things, but it does leave me properly
confused.
Though I'm a lot more concerned by the apparent lack of a mechanism to
be able to retrieve all objects of a given type. So a READ mechanism
exists to retrieve the attributes of a given Manageable Entity. And
there's a GET-TYPES to retrieve the available Manageable Entity types
but the QUERY method still doesn't seem to cut it for me.
What I mean is that QUERY has a *mandatory* Attributes Key and an
optional entityTypes. What that means is that it's possible to filter on
say "org.example.queue", but you have to specify the " set of attributes
of the Manageable Entities being requested. ". Firstly it doesn't say
the form of the set of attributes other than a string - so if more than
one what's the separator (I'd assume comma separated, but it doesn't
say). But TBH I'd much prefer the Attributes bit to be optional so if I
specified "org.example.queue" I'd get back the complete object (e.g.
like the QMF getObjects).
It's certainly good to be able to ask for specific attributes and I'm
not suggesting that shouldn't be possible too, but I don't like getting
forced to. At the moment I can essentially introspect the retrieved
objects and the GUI can actually be quite agnostic if new attributes get
added (give or take a few cases where you might want to represent things
in a particular way such as references). It's actually worse than I'm
making out because a GET-OPERATIONS method has been specified, but no
GET-ATTRIBUTES, so I actually end up having to know a whole bunch of
things a-priori that I don't currently do.
"getObjects" is TBH is pretty much *the* core use case of all of the
current QMF based tools? Knowing all of the attributes a-priori doesn't
appeal, but retrieving objects individually by repeated calls to READ
*really* doesn't appeal.
I'd definitely like QUERY (or similar) to have Attributes as optional
and if it's not sent to return a List of Maps of properties and their
keys (like getObjects and like READ does for a single Object) rather
than a List of Lists of values. As I say I'd agree that the latter is
useful too, but the former is incredibly useful and having it would
certainly make migration from QMF2 to AMQP 1.0 Management a whole lot
more straightforward.
Best Regards,
Frase
