qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: New draft of OASIS AMQP Management specification uploaded
Date Wed, 12 Feb 2014 20:31:35 GMT
Hi Rob,
I'll take a look at draft 5 when I get a moment - I was looking at draft 
3 (which is the one that you linked when you posted on the 14th January).

What you are saying sounds a bit more promising. I hadn't realised that 
you were ahead of the curve with respect to implementing this stuff in 
the Java Broker, now you're just showing off :-D

Frase

On 12/02/14 19:21, Rob Godfrey wrote:
> Hi Fraser,
>
> not sure what version you are looking at, but working draft 5 (
> https://www.oasis-open.org/committees/download.php/52121/amqp-man-v1%200-wd05.pdf)
>   already specifies that attributes on QUERY is optional, and there is a
> GET-ATTRIBUTES operation as well.
>
> The create thing is a bit odd, I grant you... the subject of the create
> command does not yet exist, whereas for read, update and delete clearly the
> subject does already exist and the name (or identity) in the headers is
> pointing to it.
>
> After having implemented on my branch for the Java broker (and in fact
> landed on trunk now) personally I'd probably prefer dropping "name" from
> the headers and instead using ID as the only way to direct operations to
> objects (the name would still be a mandatory attribute).  For create the
> IDENTITY header must not be supplied (the name will be in the map of the
> attribute values).
>
> Hope this helps,
> Rob
>
>
> On 12 February 2014 19:40, Fraser Adams <fraser.adams@blueyonder.co.uk>wrote:
>
>> 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
>>
>>


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


Mime
View raw message