On 25 February 2014 20:38, Fraser Adams <[email protected]>wrote:
> On 25/02/14 10:28, Gordon Sim wrote: > >> >> [...] >> >>> Similarly neither QMF nor AMQP 1.0 Management >>> provide a way to introspect Method formal parameters. So you can get >>> hold of the available Method names for sure, but arguments/parameters?? >>> >> >> I think you can get this over QMF. For example, using qpid-tool you can >> type: schema queue, and that gives you all the methods as well as their >> parameters including types and a basic description. >> >> I *thought* that schema information was only available from QMFv1 (where > it was necessary because QMF1 wasn't "self describing"). TBH it has been a > while since I looked, but back in the day when I was testing my Java QMF2 > stuff the C++ broker didn't return useful things for most of the schema > query methods. It *might* have been updated since then, but I sort of doubt > it (because schema stuff is generally not needed in QMF2) I actually put > together a patch along with a Jira *ages* ago (I think it was ~0.12 > timeframe) that took the QMF1 schema stuff and mapped it into QMF2 Map > Messages, but nobody seemed especially interested (again I guess because > the schema stuff isn't essential for QMF2) so I didn't particularly pursue > it. I've attached the patch for interest though clearly things have moved > on a bit since then. > > It's certainly not available from AMQP 1.0 Management though :-/ > > > Schema stuff is one of those interesting things that you kind of don't > miss until you miss it :-) I think that QMF1 was a bit of a pain because > you needed to have it, so I quite like that you can live without it with > QMF2 and AMQP 1.0 Management, but OTOH if you want to put together any > platform agnostic tooling it turns out to be kind of handy :-) > > That said, I've got no great love of the mechanism QMF2 adopted for schema > retrieval, I guess it allows one to retrieve a bit at a time, but I'm not > clear why you'd want to do that, if you actually care about schema you'd > *probably* want the whole thing in which case you wind up with a whole > bunch of network calls. In this day and age I'd personally opt for a simple > call that can return a Container's Management Schema as a JSON object (or > perhaps an AMQP Map might be more appropriate). > > Rob I'd be interested in your thoughts, the AMQP 1.0 Management > Specification certainly allows partial schema information given GET-TYPES, > GET-ATTRIBUTES and GET-OPERATIONS and I think if the latter two are > specified without an entityType they will return all attributes and methods > (the returned map has entityType as a key) but GET-OPERATIONS only returns > the method names, there's nothing that describes arguments, which is I > think a limitation. > > As I say my gut feeling is that returning the entire schema in something > JSON like is: > a) Likely to be the most useful thing to do from the perspective of users > of the Management system > b) Is likely to be the easiest thing to implement - as it stands you end > up with some slightly fiddly code and you almost certainly have to encode > your schema information in some slightly unnatural way, whereas it's likely > to be pretty simple to create say a JSON document (or even string in the > code) to describe the Management Schema and either simply return the JSON > or encode it as AMQP Map/List etc. (and both the C++ and Java brokers > already have code to do that 'cause that's pretty much what the Address > Parser does). > > I'm interested to understand the logic behind the current thinking 'cause > the more I think about it the more I think it's not as useful as it could > be. > > So I think the thought process was actually that having the meta data about the arguments for an operation doesn't really help all that much. Most times there are other more complicated data validation rules / constraints... etc and just knowing the names and types doesn't really help you to build a meaningful UI. The point of the GET-OPERATIONS operation is not really to inform the user of new operations that they wouldn't otherwise be aware of, but to implicitly make them aware of the restrictions of which operations are not available. In terms of meta-data about types and operations, I think the approach of the AMQP 1.0 group was that the types and operations meta data would be defined externally in a query-able repository in a known format (XML or JSON or whatever). For really useful tooling you'd need to know the definitions up front - and have read the descriptive text which will be the only true way to convey all the semantics... however for a tool that was just trying to operate generically on the meta data, it could do so. One of the goals of the AMQP group is to have a single definition for each type rather than each implementation (or each release of each implementation) changing the properties and operations of types in incompatible ways (not that we would ever do that). Does the above help? -- Rob Frase > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
