[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [amqp-comment] John O'Hara comments on Management Spec...
|
Hi John, Thanks for your comments… my personal responses (and not a considered collective TC response
J ) below Legally required information for business correspondence/Gesetzliche Pflichtangaben für Geschäftskorrespondenz:
From: John O'Hara [mailto:john@rjohara.com]
Chaps Reading management, looks good, looks practical. A couple of important notes: 1) In the proposed request/reply pattern, the response messages do not “stand alone” rather they require access to the original correlated request message to understand what the request relates to. This is not very “messaging” like! But the issue is that conversational state needs to be retained in the requestor and available to the recipient of the response (which should not have to be the requestor). Why not put the name of the thing that was modified in the responses so they can stand alone? Yep – I think that’s a good idea. We already echo back parameters in some places, no reason not to echo back the stuff in the request in general. 2) Related to the above, a system may not want responses to come back to the requestor on a reply queue. Why might a sophisticated system forward those responses somewhere else by providing an appropriately named target? E.g.
replies might to go “audit-recorder”, who knows. This gets into a bit of the addressing discussion we’ve been having. Basically I think the current position is something like “every ‘service’ node – that
is a node which itself generates responses and uses reply-to on incoming messages to determine where to send such responses – MUST be able to route messages based on correlation of the remote target of already attached outbound links. A service node MAY additionally
be able to route to other valid addresses (either directly or by using the routing capabilities of the container within which the service node resides). A service node SHOULD reject requests containing reply-to addresses which it knows it will be unable to
route to.” In essence we want to preserve the legality of simple service nodes / containers that do not have to build in full global address resolution functionality.
Personally I agree that there is utility in redirecting responses to a third party or intermediary, and would recommend that all vendors allow for such routing – however I understand that there are significant technical impacts of allowing this (and indeed
it was discussion of how to avoid having to create temporary queues for replies that ultimately kicked off the request/response addressing discussion).
3) The address for specifying entities is interesting; do we have sub-node addressing? /myqueue$management implies all kinds of things. Notably, it may imply that the thing being managed is in the same container as the management connection. Also, it at least doubles the size of the container name space – do subscription type addresses have the same thing? We have the parameters: name, identity and operation in other CRUD requests. Perhaps we should use these similarly here? We currently do not specify any sort of hierarchy of management nodes, or relationship of management nodes to entities. Certainly I imagine that such a model
will be used for certain implementations, but in general it should not be relied upon and is unlikely to be standardized. Even where it is used I think that conceptually /myqueue and /myqueue$management are separate addresses (rather than on being an instance
of sub-node addressing). As an aside, I think for sub-addresses a more correct syntax might be /myqueue/$management). An alternative model is to allow management of all addressable entities within a container through a single management node. Tooling should make no assumptions
about the mapping of manageable entities (addressable or not) to management node, and should instead simply traverse the set of discoverable management nodes within the container to find which entities can be managed and through which management nodes. Thoughts? Kind regards John 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]