Re: AMQP management

[Ted Ross <tross@redhat.com>]

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

Â

Â

Â