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 <[email protected]>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
