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?
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.
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?
Thoughts?
Kind regards
John