qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: New draft of OASIS AMQP Management specification uploaded
Date Fri, 14 Feb 2014 12:50:13 GMT
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:

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: 
Section 3.2.5 says:

Application Properties
<type name="application-properties" class="restricted" source="map" 
<descriptor name="amqp:application-properties:map" 
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.

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

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