You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Rob Godfrey <ro...@gmail.com> on 2014/01/14 15:24:00 UTC
New draft of OASIS AMQP Management specification uploaded
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
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Rob Godfrey <ro...@gmail.com>.
To be fair it's a very rudimentary implementation... But on trunk at the
moment is a plugin where you can execute all of the management operations
except those relating to discovering other management nodes (since there
aren't any at the moment)... you can also also read, update, delete and
create queues and exchanges. I'm currently working on being able to expand
that to being able to create other entities that live within the virtual
host. Also I'll probably do a little work to make it easier to
send/receive messages management messages over AMQP 0-8/9/10 as well as
AMQP 1-0.
For things that live outside the virtualhost (which is quite a lot in the
Java broker), I'm thinking of creating a synthetic virtualhost which is
only used for management... but that's not much more than vague aspiration
at the moment.
Ideally I'd like to get a lot of this stuff in for 0.28, but it may slip a
bit beyond that (depending on when 0.28 actually gets cut) and obviously
it's rather at the mercy of changing specs at OASIS.
-- Rob
On 12 February 2014 21:31, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> 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
>
>
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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 <fr...@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
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 14/02/14 13:05, Rob Godfrey wrote:
>
> Good spot - you obviously know AMQP better that the authors :-)
I wish! TBH it's something that I'm fairly familiar with in JMS, so
non-primitives or String property values always trigger alarm bells with
me. I wondered initially if it was legal AMQP though not legal JMS so I
looked up the AMQP specification to check, so no I'm afraid I can't
*really* claim familiarity :-)
>
> We'll need to get that fixed up for WD06.
Cool.
Actually one other thing springs to mind (I'm sure I'll think of more
when I get back into it ;->) is it worth *explicitly* specifying that
the string type to be used should be
AMQP 1.6.20 string
A sequence of Unicode characters.
<type name="string" class="primitive">
<encoding name="str8-utf8" code="0xa1" category="variable" width="1"
label="up to 2^8 - 1 octets worth of UTF-8 Unicode (with no byte order
mark)"/>
<encoding name="str32-utf8" code="0xb1" category="variable" width="4"
label="up to 2^32 - 1 octets worth of UTF-8 Unicode (with no byte order
mark)"/>
</type>
A string represents a sequence of Unicode characters as defined by the
Unicode V6.0.0 standard [UNICODE6]
I know that it does say string in the Management Specification, but I
suspect that being explicit might not be a bad idea. The reason that I
mention this is that in C++ it's potentially more "natural" to assume a
"binary string", which in many cases can visually look the same but can
play havoc with interoperability. I've got plenty of memories where
binary strings cause ClassCastException and I ended up putting quite a
bit of defensive code in place in things like QMF code.
This request is possibly a little controversial, so it'd be good if
folks from the C++ side of the house could comment. In particular at the
moment the C++ broker Management Agent tends to populate string values
as binary (I think - it's been a while since I checked, I've definitely
had some C++ Agents passing binary strings), so this *might* have
implications for migration from QMF2 to AMQP 1.0 Management Spec. but
given that it's still in working draft we've got an opportunity to
specify out some potential ambiguity that can be a pain.
>
> Thanks for the correction!
No worries, glad to have done something useful today :-)
>
> Cheers,
> Rob
>
>
Re: OASIS AMQP Management specification wd06 comments
Posted by Rob Godfrey <ro...@gmail.com>.
On 28 February 2014 17:04, Rob Godfrey <ro...@gmail.com> wrote:
> Hi Fraser,
>
> wd07 took out all the language about the form of bodies in repsonses I
> think :-)
>
I meant language about the form of bodies in *error* repsonses.
>
> Jakub has already pointed out that the locales still used an illegal list
> (doh!).
>
> As to lists in the bodies... The JMS Mapping that Robbie is working on
> will define exactly how these get passed back. Given the nature of the
> data an ObjectMessage is probably going to be the only sane way of doing so
> (there's no guarantee that any of the data within the inner lists is going
> to be valid for JMS Map messages... e.g. one of the "attributes" might
> itself have a list value).
>
> I agree the attributes as a list on the message body inbound and the first
> row on the response message is a bit of a hack... I could personally live
> with a Map of { "attributes" -> <list of attributes>, "data" -> <list of
> lists> }, or having attributes be a comma separated String in the
> application-properties.
>
> I'll try to put out a WD08 shortly at least addressing the illegal locales
> thing.
>
> BTW WD07 can be downloaded here:
>
>
> https://www.oasis-open.org/committees/document.php?document_id=52286&wg_abbrev=amqp
>
> -- Rob
>
>
> On 28 February 2014 16:43, Fraser Adams <fr...@blueyonder.co.uk>wrote:
>
>> Sorry Rob,;
>> Just skimming it again (wd06) and noticed
>> Section 3.1
>> locales - list (of strings)
>>
>> TBH I'm not quite sure how exactly this is intended to be used it's only
>> actually mentioned in this table and it might be good to include an example
>> of the intended usage in the examples section.
>>
>> That aside I'm afraid that it's another "illegal" List in the
>> application-properties of a message.
>>
>> In 3.4.1.1
>> "The body MUST consist of an amqp-value section containing a list of
>> string elements"
>>
>> That's certainly not illegal however from past experience (in QMF) using
>> lists for bodies isn't *entirely* the most amount of fun for JMS based
>> clients. You'll probably recall me whining about this sort of thing a while
>> back (my personal preference has always been to use ObjectMessage for Maps
>> and Lists because Lists aren't supported by specific Message types and
>> MapMessage doesn't use the java.util.Map interface).
>>
>> As of 0.20 Lists can be exposed as a MapMessage!!??? the Object Keys are
>> the indices into the List. I personally loath and detest this (not least
>> because with MapMessage there's no way to get the number of elements so you
>> need to guess the size of the list if you want to actually return a real
>> java.util.List (plus you need to copy). In general it's all just a bit
>> Eeewww!
>>
>> So to be honest I'd say either the JMS binding to amqp/list gets sorted
>> (a good idea anyway) or we should avoid using lists.
>>
>> Clearly in this case the stuff we want to pass up is semantically a List
>> but perhaps having a Map body (which makes things consistent with the
>> bodies of the other request/responses) containing a property called
>> attributes of type List.
>>
>> FWIW I personally like the idea of request response bodies all being of a
>> consistent type e.g. Map this makes it a lot easier to recursively
>> deserialise into collections/Variants/whatever.
>>
>>
>> Similarly I'm not convinced by the use of a List in the Query response. I
>> also think that "The first element in the list serves as a header for the
>> result set. This provides the list of attribute names that are being
>> returned for each Manageable Entity. This first element is itself a list of
>> strings where each element represents an attribute name" feels a little bit
>> "hacky" to me. I don't really like the idea that the first element of the
>> list should have semantic significance - surely returning a Map containing
>> two properties "attributes" and "values" where attributes is a List of
>> Strings and Values is a List of Lists.
>>
>> Section 3.4.2.2
>> Similar comments about the use of List bodies - legal, but a bit of a
>> pain for Java in particular. In addition this section says "If the request
>> was unsuccessful then the body of the message MUST consist of an amqp-value
>> section containing a Map with zero entries" - so this is saying that if
>> successful a List gets returned but if unsuccessful a Map is returned -
>> ouch! I'm guessing that this isn't intentional but once again I point to to
>> my belief that it makes sense to consistently use Maps as the
>> request/response bodies with whatever else is required being properties of
>> said Maps. Making this consistent also makes things like JSON serialisation
>> say to WebApps a degree more straightforward.
>>
>> Section 3.4.3 and 3.4.4 seem to make more sense both returning Maps but
>> 3.4.5 goes back to returning a List (or a Map of failure).
>>
>> If I'm honest when I look through these sections the way the bodies have
>> been structured looks a bit, well, random to me. It doesn't really give me
>> huge confidence that the information model has been fully thought through.
>>
>> Section 3.4.6.1
>> Why does "Body" say "No information is carried in the message body
>> therefore any message body is valid and MUST be ignored." when for 3.4.7
>> the "Body" section says "The body of the message MUST be empty."? Seems
>> inconsistent to me.
>>
>>
>>
>> On 17/02/14 14:59, Rob Godfrey wrote:
>>
>>> Working Draft 6 has been uploaded, which addresses the point that the
>>> spec
>>> as previously written wasn't actually in compliance with the core AMQP
>>> standard as Fraser pointed out.
>>>
>>> https://www.oasis-open.org/committees/document.php?
>>> document_id=52237&wg_abbrev=amqp
>>>
>>> -- Rob
>>>
>>>
>>>
>>>
>>
>
Re: OASIS AMQP Management specification wd06 comments
Posted by Rob Godfrey <ro...@gmail.com>.
On 28 February 2014 18:43, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> On 28/02/14 16:04, Rob Godfrey wrote:
>
> Hi Fraser,
>
> wd07 took out all the language about the form of bodies in repsonses I
> think :-)
>
> Jakub has already pointed out that the locales still used an illegal list
> (doh!).
>
> As to lists in the bodies... The JMS Mapping that Robbie is working on will
> define exactly how these get passed back. Given the nature of the data an
> ObjectMessage is probably going to be the only sane way of doing so
> (there's no guarantee that any of the data within the inner lists is going
> to be valid for JMS Map messages... e.g. one of the "attributes" might
> itself have a list value).
>
> Yippee!!! You might recall this, but one of my - many :-) - soap-boxes
> relates to issues of encoding AMQP Maps let alone AMQP Lists into JMS
> Message types. I've attached a thread from a year past January that was
> precipitated by changes to List encoding in Qpid 0.20 in that I said:
>
> "Possibly the main reason using MapMessage is flawed though is because the
> JMS Spec says:
> "A MapMessage object is used to send a set of name-value pairs. The names
> are String objects, and the values are *primitive data types in the Java
> programming language*", that's right "primitive data types". To be fair it
> then goes on to include byte[] in the list and it *does* include a
> getObject() and setObject(), but the JavaDoc explicitly says "This method
> works only for the objectified primitive object types (Integer, Double,
> Long ...), String objects, and byte arrays. "
>
> If Robbie is looking at this it might be worth you guys looking through
> the whole thread "JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid
> 0.20 released" as it happens it was vaguely controversial and TBH I don't
> think at the time I was winning the ObjectMessage argument although what I
> was saying felt correct (to me).
>
> I'm kind of glad you guys appear to be reaching a similar conclusion but
> given the discussions around it back then it's probably worthwhile giving
> the others involved an opportunity to reiterate their position.
>
Yeah - basically to be JMS compliant you need to not have any fancy sort of
stuff in your list / map... So Our current thinking is probably that a
map/list that is intended to be seen as a JMS Map / Stream Message will
need to be carrying a specific message-annotation. We may additionally
want to allow people to set a property to allow their client to go
"off-spec" and have Map messages which contain Maps, Lists, etc... however
I think with JMS 2.0 this need is not as great... You can do getBody() and
get a Map bject back for a MapMessage and for an ObjectMessage that was
carrying a map...
>
> One slight AMQP 1.0 related niggle with ObjectMessages I *think* that the
> AMQP 1.0 spec states a preference for not setting content-type ("When using
> an application-data section with a section code other than data,
> content-type
> SHOULD NOT be set."). I mention this because Gordon mentioned "the
> preferred method of sending maps and lists is through an AmqpValue section
> with the type encoded in the bytes making up that section" (see second
> attached mail).
>
> Technically that would mean that according to the spec. for Map or List
> encoding the content-type should not be set. In itself it's probably not a
> big deal but I think that the implication is that one would need to use the
> slightly ugly (IMHO) instanceof in order to determine the actual type of
> the ObjectMessage.
>
>
I think what we'll probably do is set some sort of synthetic application
property on the JMS message when it has been received as a AMQP object,
both identifying that that is the case, and possibly additionally (a
separate attribute) the type of the object.
>
> This is one of those things that is likely to be "exciting" when trying to
> design applications that can interact with a range of broker versions. I
> already got bitten between 0.18 and 0.20 with the change of List
> representation then (and IIRC something changed between 0.8 and 0.10 too).
> It's fairly easy to get things working consistently on trunk and forget
> that many people have a mixed economy of versions - though retaining
> backwards compatibility is hard I'd agree :-/
>
>
>
The JMS Mapping will state clearly how a JMS client should handle any given
AMQP message.. and the Management specification should be clear on the
nature of the messages it sends. I definitely feel the pain however as I
am trying to get AMQP management to work over AMQP 0-9 and 0-10 in a way
which would be natural to the JMS client, and to other clients.... and the
List -> Map thing is gross :-)
>
> I agree the attributes as a list on the message body inbound and the first
> row on the response message is a bit of a hack... I could personally live
> with a Map of { "attributes" -> <list of attributes>, "data" -> <list of
> lists> }, or having attributes be a comma separated String in the
> application-properties.
>
> I personally think the Map suggestion is cleaner. I did wonder about the
> comma separated string and it's *fairly* easy to "parse" though unless you
> explicitly disallow whitespace the regex to split the values becomes more
> fiddly and aside from that it feels kind of hacky too.
>
>
Yeah... I'm fairly relaxed - I do think the current solution is a nasty
hack :-) Personally I kind of hate having to use the body for the
attribute list in the request message... which is why I ponder the comma
separated list solution... But that doesn't fill me with any great love...
>
> I'll try to put out a WD08 shortly at least addressing the illegal locales
> thing.
>
> BTW WD07 can be downloaded here:
> https://www.oasis-open.org/committees/document.php?document_id=52286&wg_abbrev=amqp
>
> -- Rob
>
> Cheers. Would you be able to post links to the working drafts when they
> get uploaded TBH I wasn't aware of WD07, the last link I saw was WD06 (or
> is there a top level link that shows all the WDs to date)
>
>
I think you can get an RSS feed of the mailing list through markmail:
http://markmail.org/atom/list:org%2Eoasis-open%2Elists%2Eamqp+order:date-backwardwhich
would allow you to see any new documents being uploaded, or other
comments on the list
-- Rob
> Regards,
> Frase
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: OASIS AMQP Management specification wd06 comments
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 28/02/14 16:04, Rob Godfrey wrote:
> Hi Fraser,
>
> wd07 took out all the language about the form of bodies in repsonses I
> think :-)
>
> Jakub has already pointed out that the locales still used an illegal list
> (doh!).
>
> As to lists in the bodies... The JMS Mapping that Robbie is working on will
> define exactly how these get passed back. Given the nature of the data an
> ObjectMessage is probably going to be the only sane way of doing so
> (there's no guarantee that any of the data within the inner lists is going
> to be valid for JMS Map messages... e.g. one of the "attributes" might
> itself have a list value).
Yippee!!! You might recall this, but one of my - many :-) - soap-boxes
relates to issues of encoding AMQP Maps let alone AMQP Lists into JMS
Message types. I've attached a thread from a year past January that was
precipitated by changes to List encoding in Qpid 0.20 in that I said:
"Possibly the main reason using MapMessage is flawed though is because
the JMS Spec says:
"A |MapMessage| object is used to send a set of name-value pairs. The
names are |String| objects, and the values are *primitive data types in
the Java programming language*", that's right "primitive data types". To
be fair it then goes on to include byte[] in the list and it *does*
include a getObject() and setObject(), but the JavaDoc explicitly says
"This method works only for the objectified primitive object types
(|Integer|, |Double|, |Long| ...), |String| objects, and byte arrays. "
If Robbie is looking at this it might be worth you guys looking through
the whole thread "JMS List support & QMF2 - was Re: [ANNOUNCE] Apache
Qpid 0.20 released" as it happens it was vaguely controversial and TBH I
don't think at the time I was winning the ObjectMessage argument
although what I was saying felt correct (to me).
I'm kind of glad you guys appear to be reaching a similar conclusion but
given the discussions around it back then it's probably worthwhile
giving the others involved an opportunity to reiterate their position.
One slight AMQP 1.0 related niggle with ObjectMessages I *think* that
the AMQP 1.0 spec states a preference for not setting content-type
("When using an application-data section with a section code other than
data, content-type
SHOULD NOT be set."). I mention this because Gordon mentioned "the
preferred method of sending maps and lists is through an AmqpValue
section with the type encoded in the bytes making up that section" (see
second attached mail).
Technically that would mean that according to the spec. for Map or List
encoding the content-type should not be set. In itself it's probably not
a big deal but I think that the implication is that one would need to
use the slightly ugly (IMHO) instanceof in order to determine the actual
type of the ObjectMessage.
This is one of those things that is likely to be "exciting" when trying
to design applications that can interact with a range of broker
versions. I already got bitten between 0.18 and 0.20 with the change of
List representation then (and IIRC something changed between 0.8 and
0.10 too). It's fairly easy to get things working consistently on trunk
and forget that many people have a mixed economy of versions - though
retaining backwards compatibility is hard I'd agree :-/
>
> I agree the attributes as a list on the message body inbound and the first
> row on the response message is a bit of a hack... I could personally live
> with a Map of { "attributes" -> <list of attributes>, "data" -> <list of
> lists> }, or having attributes be a comma separated String in the
> application-properties.
I personally think the Map suggestion is cleaner. I did wonder about the
comma separated string and it's *fairly* easy to "parse" though unless
you explicitly disallow whitespace the regex to split the values becomes
more fiddly and aside from that it feels kind of hacky too.
>
> I'll try to put out a WD08 shortly at least addressing the illegal locales
> thing.
>
> BTW WD07 can be downloaded here:
>
> https://www.oasis-open.org/committees/document.php?document_id=52286&wg_abbrev=amqp
>
> -- Rob
Cheers. Would you be able to post links to the working drafts when they
get uploaded TBH I wasn't aware of WD07, the last link I saw was WD06
(or is there a top level link that shows all the WDs to date)
Regards,
Frase
Re: OASIS AMQP Management specification wd06 comments
Posted by Rob Godfrey <ro...@gmail.com>.
Working Draft 8 has just been uploaded:
https://www.oasis-open.org/committees/document.php?document_id=52425&wg_abbrev=amqp
I think this addresses your comments about the return value from Query, as
well as locales still being lists...
This'll probably be the last update for a couple of weeks as I'm going to
be travelling as is the other main editor of the document. I'll update the
Java Broker to be compliant with this draft before Monday I hope.
-- Rob
On 28 February 2014 17:04, Rob Godfrey <ro...@gmail.com> wrote:
> Hi Fraser,
>
> wd07 took out all the language about the form of bodies in repsonses I
> think :-)
>
> Jakub has already pointed out that the locales still used an illegal list
> (doh!).
>
> As to lists in the bodies... The JMS Mapping that Robbie is working on
> will define exactly how these get passed back. Given the nature of the
> data an ObjectMessage is probably going to be the only sane way of doing so
> (there's no guarantee that any of the data within the inner lists is going
> to be valid for JMS Map messages... e.g. one of the "attributes" might
> itself have a list value).
>
> I agree the attributes as a list on the message body inbound and the first
> row on the response message is a bit of a hack... I could personally live
> with a Map of { "attributes" -> <list of attributes>, "data" -> <list of
> lists> }, or having attributes be a comma separated String in the
> application-properties.
>
> I'll try to put out a WD08 shortly at least addressing the illegal locales
> thing.
>
> BTW WD07 can be downloaded here:
>
>
> https://www.oasis-open.org/committees/document.php?document_id=52286&wg_abbrev=amqp
>
> -- Rob
>
>
> On 28 February 2014 16:43, Fraser Adams <fr...@blueyonder.co.uk>wrote:
>
>> Sorry Rob,;
>> Just skimming it again (wd06) and noticed
>> Section 3.1
>> locales - list (of strings)
>>
>> TBH I'm not quite sure how exactly this is intended to be used it's only
>> actually mentioned in this table and it might be good to include an example
>> of the intended usage in the examples section.
>>
>> That aside I'm afraid that it's another "illegal" List in the
>> application-properties of a message.
>>
>> In 3.4.1.1
>> "The body MUST consist of an amqp-value section containing a list of
>> string elements"
>>
>> That's certainly not illegal however from past experience (in QMF) using
>> lists for bodies isn't *entirely* the most amount of fun for JMS based
>> clients. You'll probably recall me whining about this sort of thing a while
>> back (my personal preference has always been to use ObjectMessage for Maps
>> and Lists because Lists aren't supported by specific Message types and
>> MapMessage doesn't use the java.util.Map interface).
>>
>> As of 0.20 Lists can be exposed as a MapMessage!!??? the Object Keys are
>> the indices into the List. I personally loath and detest this (not least
>> because with MapMessage there's no way to get the number of elements so you
>> need to guess the size of the list if you want to actually return a real
>> java.util.List (plus you need to copy). In general it's all just a bit
>> Eeewww!
>>
>> So to be honest I'd say either the JMS binding to amqp/list gets sorted
>> (a good idea anyway) or we should avoid using lists.
>>
>> Clearly in this case the stuff we want to pass up is semantically a List
>> but perhaps having a Map body (which makes things consistent with the
>> bodies of the other request/responses) containing a property called
>> attributes of type List.
>>
>> FWIW I personally like the idea of request response bodies all being of a
>> consistent type e.g. Map this makes it a lot easier to recursively
>> deserialise into collections/Variants/whatever.
>>
>>
>> Similarly I'm not convinced by the use of a List in the Query response. I
>> also think that "The first element in the list serves as a header for the
>> result set. This provides the list of attribute names that are being
>> returned for each Manageable Entity. This first element is itself a list of
>> strings where each element represents an attribute name" feels a little bit
>> "hacky" to me. I don't really like the idea that the first element of the
>> list should have semantic significance - surely returning a Map containing
>> two properties "attributes" and "values" where attributes is a List of
>> Strings and Values is a List of Lists.
>>
>> Section 3.4.2.2
>> Similar comments about the use of List bodies - legal, but a bit of a
>> pain for Java in particular. In addition this section says "If the request
>> was unsuccessful then the body of the message MUST consist of an amqp-value
>> section containing a Map with zero entries" - so this is saying that if
>> successful a List gets returned but if unsuccessful a Map is returned -
>> ouch! I'm guessing that this isn't intentional but once again I point to to
>> my belief that it makes sense to consistently use Maps as the
>> request/response bodies with whatever else is required being properties of
>> said Maps. Making this consistent also makes things like JSON serialisation
>> say to WebApps a degree more straightforward.
>>
>> Section 3.4.3 and 3.4.4 seem to make more sense both returning Maps but
>> 3.4.5 goes back to returning a List (or a Map of failure).
>>
>> If I'm honest when I look through these sections the way the bodies have
>> been structured looks a bit, well, random to me. It doesn't really give me
>> huge confidence that the information model has been fully thought through.
>>
>> Section 3.4.6.1
>> Why does "Body" say "No information is carried in the message body
>> therefore any message body is valid and MUST be ignored." when for 3.4.7
>> the "Body" section says "The body of the message MUST be empty."? Seems
>> inconsistent to me.
>>
>>
>>
>> On 17/02/14 14:59, Rob Godfrey wrote:
>>
>>> Working Draft 6 has been uploaded, which addresses the point that the
>>> spec
>>> as previously written wasn't actually in compliance with the core AMQP
>>> standard as Fraser pointed out.
>>>
>>> https://www.oasis-open.org/committees/document.php?
>>> document_id=52237&wg_abbrev=amqp
>>>
>>> -- Rob
>>>
>>>
>>>
>>>
>>
>
Re: OASIS AMQP Management specification wd06 comments
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Fraser,
wd07 took out all the language about the form of bodies in repsonses I
think :-)
Jakub has already pointed out that the locales still used an illegal list
(doh!).
As to lists in the bodies... The JMS Mapping that Robbie is working on will
define exactly how these get passed back. Given the nature of the data an
ObjectMessage is probably going to be the only sane way of doing so
(there's no guarantee that any of the data within the inner lists is going
to be valid for JMS Map messages... e.g. one of the "attributes" might
itself have a list value).
I agree the attributes as a list on the message body inbound and the first
row on the response message is a bit of a hack... I could personally live
with a Map of { "attributes" -> <list of attributes>, "data" -> <list of
lists> }, or having attributes be a comma separated String in the
application-properties.
I'll try to put out a WD08 shortly at least addressing the illegal locales
thing.
BTW WD07 can be downloaded here:
https://www.oasis-open.org/committees/document.php?document_id=52286&wg_abbrev=amqp
-- Rob
On 28 February 2014 16:43, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> Sorry Rob,;
> Just skimming it again (wd06) and noticed
> Section 3.1
> locales - list (of strings)
>
> TBH I'm not quite sure how exactly this is intended to be used it's only
> actually mentioned in this table and it might be good to include an example
> of the intended usage in the examples section.
>
> That aside I'm afraid that it's another "illegal" List in the
> application-properties of a message.
>
> In 3.4.1.1
> "The body MUST consist of an amqp-value section containing a list of
> string elements"
>
> That's certainly not illegal however from past experience (in QMF) using
> lists for bodies isn't *entirely* the most amount of fun for JMS based
> clients. You'll probably recall me whining about this sort of thing a while
> back (my personal preference has always been to use ObjectMessage for Maps
> and Lists because Lists aren't supported by specific Message types and
> MapMessage doesn't use the java.util.Map interface).
>
> As of 0.20 Lists can be exposed as a MapMessage!!??? the Object Keys are
> the indices into the List. I personally loath and detest this (not least
> because with MapMessage there's no way to get the number of elements so you
> need to guess the size of the list if you want to actually return a real
> java.util.List (plus you need to copy). In general it's all just a bit
> Eeewww!
>
> So to be honest I'd say either the JMS binding to amqp/list gets sorted (a
> good idea anyway) or we should avoid using lists.
>
> Clearly in this case the stuff we want to pass up is semantically a List
> but perhaps having a Map body (which makes things consistent with the
> bodies of the other request/responses) containing a property called
> attributes of type List.
>
> FWIW I personally like the idea of request response bodies all being of a
> consistent type e.g. Map this makes it a lot easier to recursively
> deserialise into collections/Variants/whatever.
>
>
> Similarly I'm not convinced by the use of a List in the Query response. I
> also think that "The first element in the list serves as a header for the
> result set. This provides the list of attribute names that are being
> returned for each Manageable Entity. This first element is itself a list of
> strings where each element represents an attribute name" feels a little bit
> "hacky" to me. I don't really like the idea that the first element of the
> list should have semantic significance - surely returning a Map containing
> two properties "attributes" and "values" where attributes is a List of
> Strings and Values is a List of Lists.
>
> Section 3.4.2.2
> Similar comments about the use of List bodies - legal, but a bit of a pain
> for Java in particular. In addition this section says "If the request was
> unsuccessful then the body of the message MUST consist of an amqp-value
> section containing a Map with zero entries" - so this is saying that if
> successful a List gets returned but if unsuccessful a Map is returned -
> ouch! I'm guessing that this isn't intentional but once again I point to to
> my belief that it makes sense to consistently use Maps as the
> request/response bodies with whatever else is required being properties of
> said Maps. Making this consistent also makes things like JSON serialisation
> say to WebApps a degree more straightforward.
>
> Section 3.4.3 and 3.4.4 seem to make more sense both returning Maps but
> 3.4.5 goes back to returning a List (or a Map of failure).
>
> If I'm honest when I look through these sections the way the bodies have
> been structured looks a bit, well, random to me. It doesn't really give me
> huge confidence that the information model has been fully thought through.
>
> Section 3.4.6.1
> Why does "Body" say "No information is carried in the message body
> therefore any message body is valid and MUST be ignored." when for 3.4.7
> the "Body" section says "The body of the message MUST be empty."? Seems
> inconsistent to me.
>
>
>
> On 17/02/14 14:59, Rob Godfrey wrote:
>
>> Working Draft 6 has been uploaded, which addresses the point that the spec
>> as previously written wasn't actually in compliance with the core AMQP
>> standard as Fraser pointed out.
>>
>> https://www.oasis-open.org/committees/document.php?
>> document_id=52237&wg_abbrev=amqp
>>
>> -- Rob
>>
>>
>>
>>
>
OASIS AMQP Management specification wd06 comments
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Sorry Rob,;
Just skimming it again (wd06) and noticed
Section 3.1
locales - list (of strings)
TBH I'm not quite sure how exactly this is intended to be used it's only
actually mentioned in this table and it might be good to include an
example of the intended usage in the examples section.
That aside I'm afraid that it's another "illegal" List in the
application-properties of a message.
In 3.4.1.1
"The body MUST consist of an amqp-value section containing a list of
string elements"
That's certainly not illegal however from past experience (in QMF) using
lists for bodies isn't *entirely* the most amount of fun for JMS based
clients. You'll probably recall me whining about this sort of thing a
while back (my personal preference has always been to use ObjectMessage
for Maps and Lists because Lists aren't supported by specific Message
types and MapMessage doesn't use the java.util.Map interface).
As of 0.20 Lists can be exposed as a MapMessage!!??? the Object Keys are
the indices into the List. I personally loath and detest this (not least
because with MapMessage there's no way to get the number of elements so
you need to guess the size of the list if you want to actually return a
real java.util.List (plus you need to copy). In general it's all just a
bit Eeewww!
So to be honest I'd say either the JMS binding to amqp/list gets sorted
(a good idea anyway) or we should avoid using lists.
Clearly in this case the stuff we want to pass up is semantically a List
but perhaps having a Map body (which makes things consistent with the
bodies of the other request/responses) containing a property called
attributes of type List.
FWIW I personally like the idea of request response bodies all being of
a consistent type e.g. Map this makes it a lot easier to recursively
deserialise into collections/Variants/whatever.
Similarly I'm not convinced by the use of a List in the Query response.
I also think that "The first element in the list serves as a header for
the result set. This provides the list of attribute names that are being
returned for each Manageable Entity. This first element is itself a list
of strings where each element represents an attribute name" feels a
little bit "hacky" to me. I don't really like the idea that the first
element of the list should have semantic significance - surely returning
a Map containing two properties "attributes" and "values" where
attributes is a List of Strings and Values is a List of Lists.
Section 3.4.2.2
Similar comments about the use of List bodies - legal, but a bit of a
pain for Java in particular. In addition this section says "If the
request was unsuccessful then the body of the message MUST consist of an
amqp-value section containing a Map with zero entries" - so this is
saying that if successful a List gets returned but if unsuccessful a Map
is returned - ouch! I'm guessing that this isn't intentional but once
again I point to to my belief that it makes sense to consistently use
Maps as the request/response bodies with whatever else is required being
properties of said Maps. Making this consistent also makes things like
JSON serialisation say to WebApps a degree more straightforward.
Section 3.4.3 and 3.4.4 seem to make more sense both returning Maps but
3.4.5 goes back to returning a List (or a Map of failure).
If I'm honest when I look through these sections the way the bodies have
been structured looks a bit, well, random to me. It doesn't really give
me huge confidence that the information model has been fully thought
through.
Section 3.4.6.1
Why does "Body" say "No information is carried in the message body
therefore any message body is valid and MUST be ignored." when for 3.4.7
the "Body" section says "The body of the message MUST be empty."? Seems
inconsistent to me.
On 17/02/14 14:59, Rob Godfrey wrote:
> Working Draft 6 has been uploaded, which addresses the point that the spec
> as previously written wasn't actually in compliance with the core AMQP
> standard as Fraser pointed out.
>
> https://www.oasis-open.org/committees/document.php?document_id=52237&wg_abbrev=amqp
>
> -- Rob
>
>
>
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Rob Godfrey <ro...@gmail.com>.
Working Draft 6 has been uploaded, which addresses the point that the spec
as previously written wasn't actually in compliance with the core AMQP
standard as Fraser pointed out.
https://www.oasis-open.org/committees/document.php?document_id=52237&wg_abbrev=amqp
-- Rob
On 14 February 2014 14:05, Rob Godfrey <ro...@gmail.com> wrote:
>
>
>
> On 14 February 2014 13:50, Fraser Adams <fr...@blueyonder.co.uk>wrote:
>
>> Hi Again Rob,
>> I've had a skim through wd05, the QUERY stuff looks a little more
>> complete now, so that's good.
>>
>> I've still got a few nagging concerns, one particular one relates to
>> things like:
>> para 3.4.1.1
>> para 3.4.1.1
>> para 3.4.2.1
>>
>> and a few other places.
>>
>> What I'm seeing is application-properties where the Value Type is a list
>> (usually a list of strings) I'm not convinced this is legal.
>>
>>
>> Looking at the AMQP 1.0 Specification: http://docs.oasis-open.org/
>> amqp/core/v1.0/amqp-core-complete-v1.0.pdf
>> Section 3.2.5 says:
>>
>> Application Properties
>> <type name="application-properties" class="restricted" source="map"
>> provides="section">
>> <descriptor name="amqp:application-properties:map"
>> code="0x00000000:0x00000074"/>
>> </type>
>> The application-properties section is a part of the bare message used for
>> structured application data. Intermediaries can use the data within this
>> structure for the purposes of filtering or routing. The keys of this map
>> are restricted to be of type string (which excludes the possibility of a
>> null key) and the values are restricted to be of simple types only, *that
>> is, excluding map, list, and array type*
>>
>
> Good spot - you obviously know AMQP better that the authors :-)
>
> We'll need to get that fixed up for WD06.
>
> Thanks for the correction!
>
> Cheers,
> Rob
>
>
>>
>> Even if it were legal AMQP it's a little dangerous because it would be
>> illegal for JMS too:
>>
>> Message Properties:
>> Property values can be |boolean|, |byte|, |short|, |int|, |long|,
>> |float|, |double|, and |String|.
>>
>> In addition to the type-specific set/get methods for properties, JMS
>> provides the |setObjectProperty| and |getObjectProperty| methods. These
>> support the same set of property types using the objectified primitive
>> values. Their purpose is to allow the decision of property type to made at
>> execution time rather than at compile time. They support the same property
>> value conversions.
>>
>> The |setObjectProperty| method accepts values of class |Boolean|, |Byte|,
>> |Short|, |Integer|, |Long|, |Float|, |Double|, and |String|. An attempt to
>> use any other class must throw a |JMSException|.
>>
>>
>> I might have misinterpreted the intent, but as written in wd05 it doesn't
>> look legal.
>> Cheers,
>>
>> 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
>>>>
>>>>
>>>>
>>
>
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Rob Godfrey <ro...@gmail.com>.
On 14 February 2014 13:50, Fraser Adams <fr...@blueyonder.co.uk>wrote:
> Hi Again Rob,
> I've had a skim through wd05, the QUERY stuff looks a little more complete
> now, so that's good.
>
> I've still got a few nagging concerns, one particular one relates to
> things like:
> para 3.4.1.1
> para 3.4.1.1
> para 3.4.2.1
>
> and a few other places.
>
> What I'm seeing is application-properties where the Value Type is a list
> (usually a list of strings) I'm not convinced this is legal.
>
>
> Looking at the AMQP 1.0 Specification: http://docs.oasis-open.org/
> amqp/core/v1.0/amqp-core-complete-v1.0.pdf
> Section 3.2.5 says:
>
> Application Properties
> <type name="application-properties" class="restricted" source="map"
> provides="section">
> <descriptor name="amqp:application-properties:map"
> code="0x00000000:0x00000074"/>
> </type>
> The application-properties section is a part of the bare message used for
> structured application data. Intermediaries can use the data within this
> structure for the purposes of filtering or routing. The keys of this map
> are restricted to be of type string (which excludes the possibility of a
> null key) and the values are restricted to be of simple types only, *that
> is, excluding map, list, and array type*
>
Good spot - you obviously know AMQP better that the authors :-)
We'll need to get that fixed up for WD06.
Thanks for the correction!
Cheers,
Rob
>
> Even if it were legal AMQP it's a little dangerous because it would be
> illegal for JMS too:
>
> Message Properties:
> Property values can be |boolean|, |byte|, |short|, |int|, |long|, |float|,
> |double|, and |String|.
>
> In addition to the type-specific set/get methods for properties, JMS
> provides the |setObjectProperty| and |getObjectProperty| methods. These
> support the same set of property types using the objectified primitive
> values. Their purpose is to allow the decision of property type to made at
> execution time rather than at compile time. They support the same property
> value conversions.
>
> The |setObjectProperty| method accepts values of class |Boolean|, |Byte|,
> |Short|, |Integer|, |Long|, |Float|, |Double|, and |String|. An attempt to
> use any other class must throw a |JMSException|.
>
>
> I might have misinterpreted the intent, but as written in wd05 it doesn't
> look legal.
> Cheers,
>
> 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
>>>
>>>
>>>
>
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Again Rob,
I've had a skim through wd05, the QUERY stuff looks a little more
complete now, so that's good.
I've still got a few nagging concerns, one particular one relates to
things like:
para 3.4.1.1
para 3.4.1.1
para 3.4.2.1
and a few other places.
What I'm seeing is application-properties where the Value Type is a list
(usually a list of strings) I'm not convinced this is legal.
Looking at the AMQP 1.0 Specification:
http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf
Section 3.2.5 says:
Application Properties
<type name="application-properties" class="restricted" source="map"
provides="section">
<descriptor name="amqp:application-properties:map"
code="0x00000000:0x00000074"/>
</type>
The application-properties section is a part of the bare message used
for structured application data. Intermediaries can use the data within
this structure for the purposes of filtering or routing. The keys of
this map are restricted to be of type string (which excludes the
possibility of a null key) and the values are restricted to be of simple
types only, *that is, excluding map, list, and array type*
Even if it were legal AMQP it's a little dangerous because it would be
illegal for JMS too:
Message Properties:
Property values can be |boolean|, |byte|, |short|, |int|, |long|,
|float|, |double|, and |String|.
In addition to the type-specific set/get methods for properties, JMS
provides the |setObjectProperty| and |getObjectProperty| methods. These
support the same set of property types using the objectified primitive
values. Their purpose is to allow the decision of property type to made
at execution time rather than at compile time. They support the same
property value conversions.
The |setObjectProperty| method accepts values of class |Boolean|,
|Byte|, |Short|, |Integer|, |Long|, |Float|, |Double|, and |String|. An
attempt to use any other class must throw a |JMSException|.
I might have misinterpreted the intent, but as written in wd05 it
doesn't look legal.
Cheers,
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 <fr...@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
>>
>>
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Rob Godfrey <ro...@gmail.com>.
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 <fr...@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
>
>
Re: New draft of OASIS AMQP Management specification uploaded
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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