RE: [amqp] RE: AMQP Management Workstream

[Jakub.Scholz@deutsche-boerse.com]

Hi Rob,

Thanks for the answers. I think they made it a lot more clear for me.

Thanks & Regards
Jakub



|-----------------------------+--------------------------------------------------------------------------------------------------------->
|"Godfrey, Robert X"          |                                                                                                         |
|<robert.godfrey@jpmorgan.com>|                                                                                                         |
|Sent by:                     |                                                                                                       To|
|<amqp@lists.oasis-open.org>  |        "amqp@lists.oasis-open.org" <amqp@lists.oasis-open.org>                                          |
|                             |                                                                                                       cc|
|                             |                                                                                                         |
|21/05/2013 16:40             |                                                                                                  Subject|
|                             |        RE: [amqp] RE: AMQP Management Workstream                                                        |
|                             |                                                                                                         |
|                             |                                                                                                         |
|                             |                                                                                                         |
|                             |                                                                                                         |
|                             |                                                                                                         |
|-----------------------------+--------------------------------------------------------------------------------------------------------->
  >---------------------------|
  |                           |
  >---------------------------|




Hi Jakub,

My responses inline below:

> 1) According to 2.4, "This specification does not def ine 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.



----------------------------------------------------------------------------

Deutsche Börse Services s.r.o.
Managing Directors/Geschäftsführung:
Michael Gassmann, Mats Andersson.
Limited liability company with registered office at
Sokolovská 662/136B, CZ-186 00 Prague 8
recorded in the Commercial Register IC: 275 77 015.
Maintained by the city court in Prague,
Sec. C, File No. 116874.

-----------------------------------------
Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren
dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen
ist nicht gestattet.

The information contained in this message is confidential or protected by
law. If you are not the intended recipient, please contact the sender and
delete this message. Any unauthorised copying of this message or
unauthorised distribution of the information contained herein is prohibited.

Legally required information for business correspondence/
Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
http://deutsche-boerse.com/letterhead