Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of rob.j.godfrey@gmail.com
 designates 209.85.216.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52FBC007.9000505@blueyonder.co.uk>
References: 
 <CACsaS95PFRCS4f3L8UN47NMC56e2kd_mcLAk5AeMy+E5HOuewA@mail.gmail.com>
	<52FBC007.9000505@blueyonder.co.uk>
Date: Wed, 12 Feb 2014 20:21:23 +0100
Message-ID: 
 <CACsaS95n03Swsry8EiV-Oh4JzbdeDftagR4zHr-ospPr0J+hWw@mail.gmail.com>
Subject: Re: New draft of OASIS AMQP Management specification uploaded
From: Rob Godfrey <rob.j.godfrey@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=001a11c1ef6c76cf0a04f23a7a64

--001a11c1ef6c76cf0a04f23a7a64
Content-Type: text/plain; charset=ISO-8859-1

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
>
>

--001a11c1ef6c76cf0a04f23a7a64--