OASIS Advanced Message Queuing Protocol (AMQP) TC

  • 1.  AMQP management

    Posted 09-12-2018 16:51
      |   view attached
    Hi Ted,   I just started giving AMQP Management the required makeover and I’d like to simplify a few aspects. Rob said that you’ll be most interested in any changes I might have in mind.   First, I’d like to reduce the conceptual framework {entity type, type, type annotation} down to the simple notion that entity metadata set/updated via management is just a map of attributes with a handful of mandatory common attributes (identity and type) that must exists for any entity.  Except for annotations, whose practical purposes don’t reveal themselves to me in the spec, the wire impact of simplifying that should be minimal.   Second, I’m planning to change all operations to use request/response over link pairing as a preference. Correlated request/response should still work, nevertheless.   Regarding operations, I’m interested in which operations are currently in active use in the RH/Apache projects.   Thank you Clemens   Clemens Vasters Messaging Platform Architect Microsoft Azure È +49 151 44063557 *   clemensv@microsoft.com     European Microsoft Innovation Center GmbH  Gewürzmühlstrasse 11  80539 Munich Germany Geschäftsführer/General Managers: Keith Dolliver, Benjamin O. Orndorff  Amtsgericht Aachen, HRB 12066    


  • 2.  Re: AMQP management

    Posted 09-13-2018 18:47
      |   view attached
    Hi Clemens, I'm very much in favor of simplification of the conceptual framework as you've described. In RH/Apache-Qpid (I don't speak for the Qpid Java Broker project, however), we don't use any of the type-inheritance/annotations features of the draft specs. We do use the four CRUD operations and QUERY. We implement the introspection operations as well but I don't know how much use they get. We've added an extension to dump the entire management schema for use of a general-purpose browser. This is due to the fact that we have some schema features that are not supported in the GET-ATTRIBUTES operation (optional/mandatory; default-value; graphable; data-type; etc.). We do not support the REGISTER or DEREGISTER operations but we do support GET-MGMT-NODES. One of the things we are looking at presently is an event-subscribe capability like we discussed in one of our face-to-face meetings. This would allow an endpoint to establish a link to an entity-type in the agent, receive a dump of the current state and track the state for the remainder of the lifecycle of the link. -Ted On Wed, Sep 12, 2018 at 12:50 PM, Clemens Vasters < clemensv@microsoft.com > wrote: Hi Ted, I just started giving AMQP Management the required makeover and I d like to simplify a few aspects. Rob said that you ll be most interested in any changes I might have in mind. First, I d like to reduce the conceptual framework {entity type, type, type annotation} down to the simple notion that entity metadata set/updated via management is just a map of attributes with a handful of mandatory common attributes (identity and type) that must exists for any entity. Except for annotations, whose practical purposes don t reveal themselves to me in the spec, the wire impact of simplifying that should be minimal. Second, I m planning to change all operations to use request/response over link pairing as a preference. Correlated request/response should still work, nevertheless. Regarding operations, I m interested in which operations are currently in active use in the RH/Apache projects. Thank you Clemens Clemens Vasters Messaging Platform Architect Microsoft Azure à +49 151 44063557 * clemensv@microsoft.com European Microsoft Innovation Center GmbH GewÃrzmÃhlstrasse 11 80539 Munich Germany GeschÃftsfÃhrer/General Managers: Keith Dolliver, Benjamin O. Orndorff Amtsgericht Aachen, HRB 12066