RE: [amqp] RE: AMQP Management Workstream

["Godfrey, Robert X" <robert.godfrey@jpmorgan.com>]

Hi Jakub,

My responses inline below:

> 1) According to 2.4, "This specification does not define the collection of supported
> Manageable Entity Types". Where will they be defined? I assume the entities org.amqp.*
> mentioned in 2.2 should be defined somewhere by the AMQP TCs. Together with the list
> of the entities, we might also include some recommended attribute names to avoid
> incompatibilities between implementations even for a basic stuff.

Yes - I expect us to work on defining standard entities and common attribute names / operations.  This should be work done by the core TC. I think that work should be separate from the definitions of the mechanisms that we have in the current draft however.


> 2) According to 3.3, the management node should respond with a message containing a 
> body with a map of the actual attributes. These attributed may differ from those 
> required. Does it mean that the management node can change any attribute as it wants
> and still return success? What should be the main benefit of giving such freedom to
> the management node?

The intention is more to allow default values to be inserted rather than radically different values to be used. I think on a type by type basis it should be defined which values can be changed by the management service from those requested.


> 3) What is the expected response if some of the operations in chapter 3 are not 
> supported for certain manageable entities? 501 Not Implemented?

If they are not supported then they should not appear in the set of supported operations returned by the discovery operations. However if an attempt is made to perform an operation that is not supported by the type, returning a 501 seems a reasonable idea.

> 4) For all defined operations, we say that the response must be empty in case 
> the request was unsuccessful. Shouldn't this be also part of the chapter 3.2 
> to enforce this rule also on any custom operations the builders may implement?

That seems reasonable.

> 5) As already mentioned by Rafael, some sort of handling for large data sets for READALL 
> and DISCOVER operations might be very useful

> 6) What is the difference between "All manageable entities" and "all ManageableEntities 
> on which Management Operations can be performed"? (READALL versus DISCOVER) How should 
> these terms be interpreted when the management node has some security layer which allows
> different users manage different entities / use only some selected operations?

I don't think that distinction was intended.  I think the second form probably came from me being ultra precise (there may be manageable entries that are managed from other management nodes, so the set we are talking about is only those on which operations can be performed through *this* management node)

> 7) The READALL and DISCOVER operations are partially overlapping. Maybe we can move the 
> first part of the DISCOVER functionality - "(a) the list of ManageableEntities on which
> Management Operations can be performed" - as one of the filtering possibilities for READALL.

I'm open to changes in this area - I think - as Rafi pointed out - there is definitely a difference between the listing of the names of manageable entries and the listing of the operations and types.

> 8) While the description of the DESCOVER-MGMT-NODES, REGISTER and DEREGISTER operations 
> is quite clear, I'm missing some kind of explanation what is their purpose.

Firstly not all entities may be accessible through a single global management node, different entities may be managed through different nodes.  Within a single broker/service this might mean something like having a management node for each queue.  REGISTER and DEREGISTER allow third parties to register management nodes that are not in-built into the broker or service - e.g. providing a way to put an AMQP Management façade onto legacy infrastructure and then expose that management node into your management node network.

> 9) The document describes only request/response processing. Is there some reasons why we do not want some sort of management broadcasts?

This is certainly an area which I think we should look at.

-- Rob



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.