[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: AMQP management
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>
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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]