OASIS Advanced Message Queuing Protocol (AMQP) TC

Submitter's message All,

After the last TC meeting a number of us agreed to go away and try to make some progress on the various work streams that we have outstanding. One of the building blocks that a lot of the other streams were waiting on was a definition of how to do direct request-response messaging without requiring an intermediary.

After some discussions amongst the interested parties we came up with the idea of link pairing which is described in this document.

I have a number of other documents that I'll be putting out over the next week or two. Please send any comments/suggestions to this list. I'll aim to set up regular TC meetings once everybody's clocks are in sync again :-) -- Rob Godfrey Document Name : linkpair Description AMQP defines links as unidirectional transport for messages between a source and a target. A common messaging pattern is that of request-response , that is, two parties partaking in a bidirectional conversation using messages. This document defines a common pattern for pairing two unidirectional links to create a bidirectional message transport between two endpoints. Download Latest Revision Public Download Link Submitter : Rob Godfrey Group : OASIS Advanced Message Queuing Protocol (AMQP) TC Folder : Working Documents Date submitted : 2017-03-10 01:48:07

Hi Rob,   I read through it and I have some points which are not completely clear to me …   -           I was a bit surprised to see the introduction chapter talk about queues since the core spec doesn’t seem to use the term queue that much. Shouldn’t we stick with something more neutral like “node”? At the end you don’t need necessarily a queue to implement what you described there. Or is there some special reason why you used queue? -           Today, when you use temporary queues (well, I used queue term as well J ) to process the requests and responses, your service can use a plain AMQP client (e.g. Qpid JMS client) to receive the requests and respond to them. It is not clear to me how would this work with the link pairs. How would for example a simple client implement this? How will it accept the link pairs which it receives? -           In general, it is not really clear to me how would you implement even the requestor side for example in something like JMS. Do you and Robbie have already some idea? (not really needed to put it into the document, but might be useful for the discussion) -           In the chapter 2.1.2, you talk about the propagation across network. You expect that for every hop you create a separate link pair. That means that when you have a big network, all the link pairs will propagate up to the service which actually answers the request. That can result in quite a large number of links handled by the service. Sounds a bit inefficient to me. You have much more experience with actually writing the AMQP servers than I do … do you think that this is OK and will not cause any problems?   Thanks & Regards Jakub     From: amqp@lists.oasis-open.org [mailto:amqp@lists.oasis-open.org] On Behalf Of Rob Godfrey Sent: 10. brezna 2017 10:49 To: amqp@lists.oasis-open.org Subject: [amqp] Groups - linkpair uploaded   Submitter's message All, After the last TC meeting a number of us agreed to go away and try to make some progress on the various work streams that we have outstanding. One of the building blocks that a lot of the other streams were waiting on was a definition of how to do direct request-response messaging without requiring an intermediary. After some discussions amongst the interested parties we came up with the idea of "link pairing" which is described in this document. I have a number of other documents that I'll be putting out over the next week or two. Please send any comments/suggestions to this list. I'll aim to set up regular TC meetings once everybody's clocks are in sync again :-) -- Rob Godfrey Document Name : linkpair Description AMQP defines links as unidirectional transport for messages between a source and a target. A common messaging pattern is that of "request-response", that is, two parties partaking in a bidirectional conversation using messages. This document defines a common pattern for pairing two unidirectional links to create a bidirectional message transport between two endpoints. Download Latest Revision Public Download Link Submitter : Rob Godfrey Group : OASIS Advanced Message Queuing Protocol (AMQP) TC Folder : Working Documents Date submitted : 2017-03-10 01:48:07   ----------------------------------------- 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

On 15 March 2017 at 14:55, Scholz Jakub < Jakub.Scholz@deutsche-boerse.com > wrote: Hi Rob,   I read through it and I have some points which are not completely clear to me …   -           I was a bit surprised to see the introduction chapter talk about queues since the core spec doesn’t seem to use the term queue that much. Shouldn’t we stick with something more neutral like “node”? At the end you don’t need necessarily a queue to implement what you described there. Or is there some special reason why you used queue? So, the introduction was really meant to talk about messaging in general until the diagram, after the diagram it moves to talking about AMQP mechanisms (where I use the term node).  -           Today, when you use temporary queues (well, I used queue term as well J ) to process the requests and responses, your service can use a plain AMQP client (e.g. Qpid JMS client) to receive the requests and respond to them. It is not clear to me how would this work with the link pairs. How would for example a simple client implement this? How will it accept the link pairs which it receives? Indeed - this mechanism is not designed to cater for writing the request/response "service" with a general client library - it requires a library that can deal with spontaneous incoming attaches. There is a second document coming which you will be able to use in combination with this mechanism such that the service application could connect to a sort of "response relay" node in the broker with a link pair, and as the incoming requests come through the broker, they will be annotated... the client would then have to reflect those annotations on the response message such that the broker would relay the response back down the correct "incoming" link pair.  -           In general, it is not really clear to me how would you implement even the requestor side for example in something like JMS. Do you and Robbie have already some idea? (not really needed to put it into the document, but might be useful for the discussion) There are definitely going to be issues in trying to access this (and any other mechanism which requires link properties or source/target capabilities) from JMS.  Robbie and I have discussed that we need a mechanism... we haven't yet worked out exactly what that will be though :-).   -           In the chapter 2.1.2, you talk about the propagation across network. You expect that for every hop you create a separate link pair. That means that when you have a big network, all the link pairs will propagate up to the service which actually answers the request. That can result in quite a large number of links handled by the service. Sounds a bit inefficient to me. You have much more experience with actually writing the AMQP servers than I do … do you think that this is OK and will not cause any problems? As above, there is a second document coming which will allow for intermediaries to funnel many paired links into a combined "outgoing" paired link... using annotations that the receiver will have to reflect back on their response, so that the intermediary can fan the responses back out to the correct requestor pair.   Hope this helps, Rob   Thanks & Regards Jakub     From: amqp@lists.oasis-open.org [mailto: amqp@lists.oasis-open. org ] On Behalf Of Rob Godfrey Sent: 10. brezna 2017 10:49 To: amqp@lists.oasis-open.org Subject: [amqp] Groups - linkpair uploaded   Submitter's message All, After the last TC meeting a number of us agreed to go away and try to make some progress on the various work streams that we have outstanding. One of the building blocks that a lot of the other streams were waiting on was a definition of how to do direct request-response messaging without requiring an intermediary. After some discussions amongst the interested parties we came up with the idea of "link pairing" which is described in this document. I have a number of other documents that I'll be putting out over the next week or two. Please send any comments/suggestions to this list. I'll aim to set up regular TC meetings once everybody's clocks are in sync again :-) -- Rob Godfrey Document Name : linkpair Description AMQP defines links as unidirectional transport for messages between a source and a target. A common messaging pattern is that of "request-response", that is, two parties partaking in a bidirectional conversation using messages. This document defines a common pattern for pairing two unidirectional links to create a bidirectional message transport between two endpoints. Download Latest Revision Public Download Link Submitter : Rob Godfrey Group : OASIS Advanced Message Queuing Protocol (AMQP) TC Folder : Working Documents Date submitted : 2017-03-10 01:48:07   ------------------------------ ----------- 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

Hi Rob,
 
Ok, I guess I will wait for the second document to see how it fits together.
 
Thanks & Regards
Jakub
 
From: amqp@lists.oasis-open.org [mailto:amqp@lists.oasis-open.org]
On Behalf Of Rob Godfrey
Sent: 15. brezna 2017 15:49
To: Scholz Jakub <Jakub.Scholz@deutsche-boerse.com>
Cc: amqp@lists.oasis-open.org
Subject: Re: [amqp] Groups - linkpair uploaded
 

 

 

On 15 March 2017 at 14:55, Scholz Jakub < Jakub.Scholz@deutsche-boerse.com > wrote:



Hi Rob,
 
I read through it and I have some points which are not completely clear to me …
 
-          
I was a bit surprised to see the introduction chapter talk about queues since the core spec doesn’t seem to use the term queue that much. Shouldn’t we stick with something
more neutral like “node”? At the end you don’t need necessarily a queue to implement what you described there. Or is there some special reason why you used queue?




 


So, the introduction was really meant to talk about messaging in general until the diagram, after the diagram it moves to talking about AMQP mechanisms (where I use the term node). 




-          
Today, when you use temporary queues (well, I used queue term as well
J ) to process the requests and responses, your service can use a plain AMQP client (e.g. Qpid JMS
client) to receive the requests and respond to them. It is not clear to me how would this work with the link pairs. How would for example a simple client implement this? How will it accept the link pairs which it receives?




Indeed - this mechanism is not designed to cater for writing the request/response "service" with a general client library - it requires a library that can deal with spontaneous incoming attaches. There is a second document coming which
you will be able to use in combination with this mechanism such that the service application could connect to a sort of "response relay" node in the broker with a link pair, and as the incoming requests come through the broker, they will be annotated... the
client would then have to reflect those annotations on the response message such that the broker would relay the response back down the correct "incoming" link pair. 




-          
In general, it is not really clear to me how would you implement even the requestor side for example in something like JMS. Do you and Robbie have already some idea? (not really
needed to put it into the document, but might be useful for the discussion)




 


There are definitely going to be issues in trying to access this (and any other mechanism which requires link properties or source/target capabilities) from JMS.  Robbie and I have discussed that we need a mechanism... we haven't yet worked
out exactly what that will be though :-).


 




-          
In the chapter 2.1.2, you talk about the propagation across network. You expect that for every hop you create a separate link pair. That means that when you have a big network,
all the link pairs will propagate up to the service which actually answers the request. That can result in quite a large number of links handled by the service. Sounds a bit inefficient to me. You have much more experience with actually writing the AMQP servers
than I do … do you think that this is OK and will not cause any problems?




 


 


As above, there is a second document coming which will allow for intermediaries to funnel many paired links into a combined "outgoing" paired link... using annotations that the receiver will have to reflect back on their response, so that
the intermediary can fan the responses back out to the correct requestor pair.


 


 


Hope this helps,


Rob




 
Thanks & Regards
Jakub
 
 
From:
amqp@lists.oasis-open.org [mailto: amqp@lists.oasis-open.org ]
On Behalf Of Rob Godfrey
Sent: 10. brezna 2017 10:49
To: amqp@lists.oasis-open.org
Subject: [amqp] Groups - linkpair uploaded


 
Submitter's message
All,

After the last TC meeting a number of us agreed to go away and try to make some progress on the various work streams that we have outstanding. One of the building blocks that a lot of the other streams were waiting on was a definition of how to do direct request-response
messaging without requiring an intermediary.

After some discussions amongst the interested parties we came up with the idea of "link pairing" which is described in this document.

I have a number of other documents that I'll be putting out over the next week or two. Please send any comments/suggestions to this list. I'll aim to set up regular TC meetings once everybody's clocks are in sync again :-)

-- Rob Godfrey





Document Name :

linkpair







Description
AMQP defines links as unidirectional transport for messages between a
source and a target. A common messaging pattern is that of
"request-response", that is, two parties partaking in a bidirectional
conversation using messages. This document defines a common pattern for
pairing two unidirectional links to create a bidirectional message
transport between two endpoints.
Download Latest Revision
Public Download Link







Submitter : Rob Godfrey
Group : OASIS Advanced Message Queuing Protocol (AMQP) TC
Folder : Working Documents
Date submitted : 2017-03-10 01:48:07




 



-----------------------------------------
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



 



----------------------------------------- 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

Hi Rob,   I think the document looks good.   A couple of minor comments:   1)       In section 1 you discuss some of the problems that lead us to link-pairs.    One important design consideration was the need for a system that worked with signed message (content/properties including the reply-to).  I wonder if there is value bringing this out in section 1 too. 2)       We don’t state the behaviour if the reply-to property is something other than $me. Would requests messages carrying an arbitrary reply-to addresses (or no reply-to addresses) be permitted on paired links?  I can’t find a reason to disallow them, but think it should be explicit.     3)       Footer – I note that the date in the footer is inconsistent with the front page.   Kind regards, Keith.   From: amqp@lists.oasis-open.org [mailto:amqp@lists.oasis-open.org] On Behalf Of Rob Godfrey Sent: Friday, March 10, 2017 9:49 AM To: amqp@lists.oasis-open.org Subject: [amqp] Groups - linkpair uploaded   Submitter's message All, After the last TC meeting a number of us agreed to go away and try to make some progress on the various work streams that we have outstanding. One of the building blocks that a lot of the other streams were waiting on was a definition of how to do direct request-response messaging without requiring an intermediary. After some discussions amongst the interested parties we came up with the idea of "link pairing" which is described in this document. I have a number of other documents that I'll be putting out over the next week or two. Please send any comments/suggestions to this list. I'll aim to set up regular TC meetings once everybody's clocks are in sync again :-) -- Rob Godfrey Document Name : linkpair Description AMQP defines links as unidirectional transport for messages between a source and a target. A common messaging pattern is that of "request-response", that is, two parties partaking in a bidirectional conversation using messages. This document defines a common pattern for pairing two unidirectional links to create a bidirectional message transport between two endpoints. Download Latest Revision Public Download Link Submitter : Rob Godfrey Group : OASIS Advanced Message Queuing Protocol (AMQP) TC Folder : Working Documents Date submitted : 2017-03-10 01:48:07   This message is confidential and subject to terms at: http:// www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

Thanks Keith, I have (as you may have seen) raised JIRAs for these issues. -- Rob On 23 March 2017 at 11:39, Wall, Keith < keith.wall@jpmorgan.com > wrote: Hi Rob,   I think the document looks good.   A couple of minor comments:   1)       In section 1 you discuss some of the problems that lead us to link-pairs.    One important design consideration was the need for a system that worked with signed message (content/properties including the reply-to).  I wonder if there is value bringing this out in section 1 too. 2)       We don’t state the behaviour if the reply-to property is something other than $me. Would requests messages carrying an arbitrary reply-to addresses (or no reply-to addresses) be permitted on paired links?  I can’t find a reason to disallow them, but think it should be explicit.     3)       Footer – I note that the date in the footer is inconsistent with the front page.   Kind regards, Keith.   From: amqp@lists.oasis-open.org [mailto: amqp@lists.oasis-open. org ] On Behalf Of Rob Godfrey Sent: Friday, March 10, 2017 9:49 AM To: amqp@lists.oasis-open.org Subject: [amqp] Groups - linkpair uploaded   Submitter's message All, After the last TC meeting a number of us agreed to go away and try to make some progress on the various work streams that we have outstanding. One of the building blocks that a lot of the other streams were waiting on was a definition of how to do direct request-response messaging without requiring an intermediary. After some discussions amongst the interested parties we came up with the idea of "link pairing" which is described in this document. I have a number of other documents that I'll be putting out over the next week or two. Please send any comments/suggestions to this list. I'll aim to set up regular TC meetings once everybody's clocks are in sync again :-) -- Rob Godfrey Document Name : linkpair Description AMQP defines links as unidirectional transport for messages between a source and a target. A common messaging pattern is that of "request-response", that is, two parties partaking in a bidirectional conversation using messages. This document defines a common pattern for pairing two unidirectional links to create a bidirectional message transport between two endpoints. Download Latest Revision Public Download Link Submitter : Rob Godfrey Group : OASIS Advanced Message Queuing Protocol (AMQP) TC Folder : Working Documents Date submitted : 2017-03-10 01:48:07   This message is confidential and subject to terms at: http:// www.jpmorgan.com/ emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.