qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: New draft of OASIS AMQP Management specification uploaded
Date Fri, 14 Feb 2014 13:05:31 GMT
On 14 February 2014 13:50, Fraser Adams <fraser.adams@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
>>>
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message