OASIS Advanced Message Queuing Protocol (AMQP) TC

Thank you, Ted.
 
In
my draft I already tossed the annotations out.
 
The new Manageable Type Metatype (names all TBD), is effectively an _expression_ of an AMQP composite type definition as an AMQP composite type, and with that you ll get able to get
the full fidelity schema for all supported entity types with GET-TYPES, including optional/mandatory, type, etc.   GET-ATTRIBUTES will still give you a plain map, but the Metatype will tell you what is what.

 
On the discovery/navigation front, I ve already laid some of the foundation for how to deal with entities that have internal substructures, like our Service Bus topics with their dependent
subscriptions, or our Event Hubs with dependent consumer groups:
 
The top-level $management node inside a container only provides access to top-level constructs and their types, e.g. it only knows about Queues and Topics and Event Hubs in our world.
To get at the internal substructure of a Topic or Event Hub, you ll find the address of that entity s local management node in its entity attributes. That management node is then what you interact with for getting at a Topic s subscriptions or its entity-level
access control rules. The model can obviously nest.
 
With that structure, it should then obviously also be possible to do a deep or shallow GET/QUERY, so that the client doesn t need to walk the graph step-by-step, but it should have the
option if it wants to show master/detail UX, for instance.
 
The key reason for having this nested model is versioning and side-by-side coexistence of different versions of the same entity through long lifecycles. I should be able to have a Topic
V7 and a Topic V8 coexist in the same system, with Topic V8 s substructure being somewhat different from Topic V7, but yet I don t want to force clients to learn about a wholly new top-level entity type if they don t care about those particular niche capabilities.
Therefore I don t want to version the whole graph as one.
 
However, I will assume that the Metatype model isn t going to be terribly dynamic for any given server/service at any given point in time, and therefore GET-TYPES should also be able
to return all types for the full graph in one shot into a reference cache.
 
I m going to work on the operations tomorrow. The observer capability we discussed would tie up nicely to CNCF CloudEvents I think the best way to make these things compose well
is for AMQP Management to have hooks where we say which events are being raised and what they carry when something happens, i.e. when an entity is created or changed, and then we write a spec that uses those hooks and defines how those events map to CloudEvents
and another spec that defines how events can be forwarded as plain AMQP messages if CloudEvents isn t what you want.
 
Cheers
Clemens
 
 
 
 
Von: Ted Ross <tross@redhat.com>

Gesendet: Donnerstag, 13. September 2018 20:47
An: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp@lists.oasis-open.org
Betreff: Re: AMQP management
 


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





 

 




 

The discovery mechanism that you describe is superior to our tactical schema-dump extension. It will work much better in a dynamic and multi-tenant environment. We will transition without complaining to the standard mechanism when the time comes. -Ted On Thu, Sep 13, 2018 at 3:40 PM, Clemens Vasters < clemensv@microsoft.com > wrote: Thank you, Ted. In my draft I already tossed the annotations out. The new Manageable Type Metatype (names all TBD), is effectively an _expression_ of an AMQP composite type definition as an AMQP composite type, and with that you ll get able to get the full fidelity schema for all supported entity types with GET-TYPES, including optional/mandatory, type, etc. GET-ATTRIBUTES will still give you a plain map, but the Metatype will tell you what is what. On the discovery/navigation front, I ve already laid some of the foundation for how to deal with entities that have internal substructures, like our Service Bus topics with their dependent subscriptions, or our Event Hubs with dependent consumer groups: The top-level $management node inside a container only provides access to top-level constructs and their types, e.g. it only knows about Queues and Topics and Event Hubs in our world. To get at the internal substructure of a Topic or Event Hub, you ll find the address of that entity s local management node in its entity attributes. That management node is then what you interact with for getting at a Topic s subscriptions or its entity-level access control rules. The model can obviously nest. With that structure, it should then obviously also be possible to do a deep or shallow GET/QUERY, so that the client doesn t need to walk the graph step-by-step, but it should have the option if it wants to show master/detail UX, for instance. The key reason for having this nested model is versioning and side-by-side coexistence of different versions of the same entity through long lifecycles. I should be able to have a Topic V7 and a Topic V8 coexist in the same system, with Topic V8 s substructure being somewhat different from Topic V7, but yet I don t want to force clients to learn about a wholly new top-level entity type if they don t care about those particular niche capabilities. Therefore I don t want to version the whole graph as one. However, I will assume that the Metatype model isn t going to be terribly dynamic for any given server/service at any given point in time, and therefore GET-TYPES should also be able to return all types for the full graph in one shot into a reference cache. I m going to work on the operations tomorrow. The observer capability we discussed would tie up nicely to CNCF CloudEvents I think the best way to make these things compose well is for AMQP Management to have hooks where we say which events are being raised and what they carry when something happens, i.e. when an entity is created or changed, and then we write a spec that uses those hooks and defines how those events map to CloudEvents and another spec that defines how events can be forwarded as plain AMQP messages if CloudEvents isn t what you want. Cheers Clemens Von: Ted Ross < tross@redhat.com > Gesendet: Donnerstag, 13. September 2018 20:47 An: Clemens Vasters < clemensv@microsoft.com > Cc: amqp@lists.oasis-open.org Betreff: Re: AMQP management 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

On Thu, 13 Sep 2018 at 21:40, Clemens Vasters < clemensv@microsoft.com > wrote: Thank you, Ted. In my draft I already tossed the annotations out. So the rationale for the annotations is to allow for some simplified way for a user to do something like "create a queue" without having to know which provider they are talking to (presuming the name of the actual object being created is different across different vendors). This is the single most common "requirement" of management that I see from users. Without something like annotations I think we either all need to agree on a completely common schema across different (never going to happen), come up with some sort of alternative, or simply not meet the requirement. Thoughts? -- Rob The new Manageable Type Metatype (names all TBD), is effectively an _expression_ of an AMQP composite type definition as an AMQP composite type, and with that you ll get able to get the full fidelity schema for all supported entity types with GET-TYPES, including optional/mandatory, type, etc. GET-ATTRIBUTES will still give you a plain map, but the Metatype will tell you what is what. On the discovery/navigation front, I ve already laid some of the foundation for how to deal with entities that have internal substructures, like our Service Bus topics with their dependent subscriptions, or our Event Hubs with dependent consumer groups: The top-level $management node inside a container only provides access to top-level constructs and their types, e.g. it only knows about Queues and Topics and Event Hubs in our world. To get at the internal substructure of a Topic or Event Hub, you ll find the address of that entity s local management node in its entity attributes. That management node is then what you interact with for getting at a Topic s subscriptions or its entity-level access control rules. The model can obviously nest. With that structure, it should then obviously also be possible to do a deep or shallow GET/QUERY, so that the client doesn t need to walk the graph step-by-step, but it should have the option if it wants to show master/detail UX, for instance. The key reason for having this nested model is versioning and side-by-side coexistence of different versions of the same entity through long lifecycles. I should be able to have a Topic V7 and a Topic V8 coexist in the same system, with Topic V8 s substructure being somewhat different from Topic V7, but yet I don t want to force clients to learn about a wholly new top-level entity type if they don t care about those particular niche capabilities. Therefore I don t want to version the whole graph as one. However, I will assume that the Metatype model isn t going to be terribly dynamic for any given server/service at any given point in time, and therefore GET-TYPES should also be able to return all types for the full graph in one shot into a reference cache. I m going to work on the operations tomorrow. The observer capability we discussed would tie up nicely to CNCF CloudEvents I think the best way to make these things compose well is for AMQP Management to have hooks where we say which events are being raised and what they carry when something happens, i.e. when an entity is created or changed, and then we write a spec that uses those hooks and defines how those events map to CloudEvents and another spec that defines how events can be forwarded as plain AMQP messages if CloudEvents isn t what you want. Cheers Clemens Von: Ted Ross < tross@redhat.com > Gesendet: Donnerstag, 13. September 2018 20:47 An: Clemens Vasters < clemensv@microsoft.com > Cc: amqp@lists.oasis-open.org Betreff: Re: AMQP management 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 -- ______________________________ ______________________________ _________________ Red Hat GmbH, www.de.redhat.com , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill