RE: [amqp] Groups - linkpair uploaded

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. března 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. března 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

amqp message