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