On 14 February 2014 13:50, Fraser Adams <[email protected]>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 <[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 >>> >>> >>> >
