[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [amqp] More questions/comments on the Management spec
The identity of an entity is immutable, but the name may change (i.e. some types may support renaming operations), by using the identity as the key a tool can
thus maintain history of an entity even if its name changes. I would also expect that entities which refer to other entities would track the id and not the name (for the same reason).
I agree, the READALL operation should specify the possibility of a 413.
Yes, there has been some discussion of this. Limit is not really enough in itself to support pagination,
and given that I don’t think we want to enforce any sort of notion of order I don’t personally see any sense in trying to support pagination directly at the management node. I’m not totally convinced that there is a lot of utility in limit, however the case
made is that it allows clients to ensure they are not accidentally overwhelmed by huge data sets.
Adding selectors adds a whole extra degree of complexity onto what a management node is being asked
to do. Where the node is managing a single broker executing selectors such as this might not be a problem, but where the queues are actually distributed across many physical instances in a worldwide network of AMQP containers, selectors which query properties
of entities probably don’t work so well. There has certainly been pushback against adding complexity to the core management specification. One solution that might work would be for third parties to add new management reporting node types which cache information
from the core management nodes and allow for querying and reporting (and pagination, etc)…
Tackling these in reverse order… The node $management is simply an entry point into the network of
management nodes within an AMQP network. Different AMQP providers may model their mapping between nodes and which nodes are used to manage them in different ways. For instance it may be that some suppliers decide that each individual queue has its own management
node, so to READ, UPDATE or DELETE a given queue you might need to address the specific management node for that queue (e.g. queue$management). A different supplier may decide to route all management operations through a single management node. As such,
on connection to an AMQP network, the management tooling will need to interrogate the system to find all of the management nodes, and which entities that each node manages.
The idea of REGISTER is to allow a third party device or process to insert itself into the management
network… One use case might be a legacy broker which does not allow for AMQP management – a third party might write a standalone management solution for that broker which translates between its management APIs and the AMQP management standard. This third
part application might then register itself as a management node on an AMQP network that does support AMQP management, thus allowing the management of the legacy broker through the common management network. Another use case might be simply adding a federated
broker into an existing network, or a non-broker AMQP device (the fabled AMQP management enabled toaster). Hope this helps, Rob From: amqp@lists.oasis-open.org [mailto:amqp@lists.oasis-open.org]
On Behalf Of Ted Ross Thanks Rob for the responses to my last question.
Thanks, -Ted This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]